• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 H04N
審判 査定不服 2項進歩性 特許、登録しない。 H04N
審判 査定不服 2項進歩性 特許、登録しない。 H04N
管理番号 1270368
審判番号 不服2011-20020  
総通号数 160 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-04-26 
種別 拒絶査定不服の審決 
審判請求日 2011-09-15 
確定日 2013-02-20 
事件の表示 特願2008-126215「マルチメディア信号の符号化」拒絶査定不服審判事件〔平成21年 1月22日出願公開、特開2009- 17535〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 経緯
本件出願は、平成20年5月13日(パリ条約による優先権主張2007年5月25日、米国)の出願であって、平成22年11月19日付けで拒絶理由の通知がなされ、これに対し、平成23年3月1日付けで手続補正がなされたが、平成23年5月6日付けで拒絶査定がなされたものである。
本件は、上記拒絶査定を不服として平成23年9月15日付けで請求された拒絶査定不服審判であって、同日付けで手続補正(明細書、特許請求の範囲又は図面について請求と同時にする補正)がなされたものである。

2 補正の却下の決定
平成23年9月15日付けの手続補正について次のとおり決定する。

〈補正の却下の決定の結論〉
平成23年9月15日付けの手続補正を却下する。

〈補正の却下の決定の理由〉
(1)補正の内容
平成23年9月15日付けの手続補正(以下、本件補正という)は、請求項4についてする次の補正を含むものである。

[補正前](【請求項4】)(平成23年3月1日付けで補正されたもの)
外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記GPUにおいて受け取るステップであって、前記GPUは該複数のデジタル値をGPUメモリに格納する、該ステップと、
前記GPUにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップと、
を含む方法。

[補正後](【請求項4】)
外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記GPUにおいて受け取るステップであって、前記GPUは該複数のデジタル値を前記GPUの外部に配置されたGPUメモリに格納する、該ステップと、
前記GPUにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップと、
を含む方法。

この請求項4についてする補正は、「GPUメモリ」について、「前記GPUの外部に配置された」とさらに特定するものである。

(2)補正の適法性
上記のとおり、請求項4についてする補正は、「GPUメモリ」について、「前記GPUの外部に配置された」とさらに特定するものであって、特許請求の範囲の減縮を目的とする補正であると認められるから、独立特許要件について検討する。

ア 補正後発明
本件補正後の特許請求の範囲の請求項4に係る発明(以下、補正後発明という)は、上記の本件補正後の特許請求の範囲の請求項4に記載されたとおりのものと認める。

イ 刊行物1
「竹本卓 他,コンフィギュアラブルプロセッサを利用した携帯機器向け3Dグラフィックスプロセッサ,電子情報通信学会技術研究報告,社団法人電子情報通信学会,2004年10月22日,Vｏl.104,Nｏ.368,ｐｐ.1?6」(査定の理由で示した引用文献3。以下、刊行物1という)には、図、表と共に次の記載がある。
(刊行物1の記載)
「コンフィギュアラブルプロセッサを利用した携帯機器向け3Dグラフィックスプロセッサ」(1頁 表題)

「あらまし 3.5Mｐｏlｙgｏn/ｓecの3DCGエンジン、15fｐｓ@QVGAのMPEG4 cｏdecエンジン、最大2MｐiｘelのJPEGエンジン、カメラI/F、SDカードI/F、LCDI/F、および20MbiｔのDRAMを1chiｐに集積した携帯機器向けメディアプロセッサT4Gの開発について述べる。3DCGエンジンは東芝のコンフィギュアラブルプロセッサMePを応用することにより実現されている。DRAMを内蔵したことにより、3Dエンジンとメモリ間のバンド幅は2Gbｙｔe/ｓecに達する。このチップでは、0.13μm CMOS DRAM混載プロセスを使用し、20Mｔｒanｓiｓｔｏｒのロジックと20MbiｔのDRAMを集積した。3DCG処理時の最大消費電力は170mWである。
キーワード コンフィギュアラブルプロセッサ,MeP,3Dグラフィックス,携帯電話,メディアプロセッサ」(1頁 あらまし および キーワード)

「1.Inｔｒｏdｕcｔiｏn
近年、携帯機器、特に携帯電話に対して要求される機能は飛躍的に増大し、カメラ機能、動画処理機能だけでなく、コンソールゲーム機器並みの処理能力を要する3DCG機能が要求されるようになってきている。一方、大変コストセンシティブな市場でもあり、上記要求を満たしつつトータルコストを最小にするソリューションが求められている。
以前、我々は携帯機器におけるMPEG4 cｏdecの要求に対するソリューションとしてT4を開発した[1]。T4は、専用MPEGエンジンとeDRAM(embedded DRAM)の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした。T4は、eDRAMを集積したことで比較的容量の大きな内蔵メモリを持つことになった。このことは、新たな機能をT4に追加するときのコスト上昇を最小にする可能性がある。
今回我々は、T4にコンソールゲーム機並みの3DCG描画能力を追加したメディアプロセッサT4Gを開発した。T4Gは、T4におけるMPEG機能と同様、外付けメモリを全く必要とせずに、高品位な3DCG機能を実現できる。eDRAMはMPEG4エンジンと3DCGエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。
T4Gにおける3D処理の一部は、東芝のコンフィギュアラブル且つ拡張可能な組み込み向けプロセッサMeP[2][3]により実装されている。MePをDSP拡張することにより、完全なプログラマビリティと高い3DCG処理性能を両立することができる。このプログラマビリティにより、T4Gは高い抽象度のコマンドを実行することができる。このことは、低コストな携帯電話システムにおいて常に問題となる、ベースバンドプロセッサとメディアプロセッサ間の通信バンド幅不足を緩和するために重要である。
この論文では、まず3DCGの処理過程を説明しT4Gの開発コンセプトについて述べる。次にアーキテクチャ設計過程および各ブロックの詳細について述べる。最後にチップの実装について述べる。」(1頁左欄1行?2頁左欄25行)

「2.3Dグラフィックスの処理過程
一般的な3Dグラフィックスシステムの処理の階層を図1に示す。アプリケーションレイヤとはゲームでいえば、シナリオの進行を制御したり、キャラクタの動作を決定したりする処理レイヤで、ゲームのメインプログラムに相当する。APIレイヤとはアプリケーションレイヤに対してOｐenGL・ES[4]等のAPIを提供するレイヤで、上位レイヤからの指示に従いデータを構築、必要なパラメータを生成するとともに、各種バッファの管理、レンダリングステートの更新等を行う。頂点処理レイヤとは頂点単位の座標変換や照光処理を行うレイヤ、ピクセル処理レイヤとはピクセル単位のカラー演算を行うレイヤである。フレームバッファレイヤとはCｏlｏｒバッファやZバッファといった物理的なメモリそのものを指す。一般に頂点処理レイヤから下、もしくはピクセル処理レイヤから下がハードウエア化される。また実際はハードウエアとソフトウエアの境界には、ハードウエアを抽象化するためのデバイスドライバレイヤが挿入される。
図1において、上の層にいくほどプログラマビリティが要求される傾向がある。また、下の層にいくほど、演算処理量が増え、層間のデータトラフィックも増大する傾向がある。
携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。よって、理想的にはアプリケーションレイヤからフレームバッファレイヤまですべてが1chiｐになっていることが望ましい。アプリケーションを実行する高速な汎用プロセッサを集積して、アプリケーションレイヤ以下を1chiｐで提供するのは、いわゆるアプリケーションプロセッサのソリューションである。このソリューションは、大規模なソフトウエアを格納するための外付けメモリを必要とし、コストや消費電力の面からコストセンシティブなレンジの製品にはただちに適用しづらい面がある。このことからT4GではAPIレイヤからフレームバッファレイヤを1chiｐ化し、コストとパフォーマンスのバランスをとることにした。
T4Gシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい3DCG処理やMPEG cｏdec処理から解放される。大きなプログラムメモリが必要であるがスループットがそれほど要求されない処理はホストプロセッサchiｐで、必要なメモリ量は限られるが非常に高いスループットが求められる処理はメディアプロセッサchiｐで、という処理の切り分けがT4Gの基本コンセプトである。

( 図1 3Dグラフィックスの処理階層)
」
(2頁左欄26行?右欄23行)

「3.アーキテクチャの設計
抽象度の高いAPIを定義すれば、ホストプロセッサとT4G間の通信トラフィックを下げることができる。たとえば、100トライアングルで構成された球を描画するとき、最も原始的なトライアングル描画命令しかなければ100命令になるが、より抽象度の高い球を描画する命令があれば1命令ですむ。このような高抽象度のAPIを提供するためには、APIレイヤおよびその直下の頂点処理レイヤを担当するエンジンはプログラマブルであることが望ましい。ただし、頂点処理には非常に多くの浮動小数点演算が含まれるため、汎用の組み込みプロセッサで実用的な性能を得るのは難しい。これらのことからT4Gでは、これらのレイヤを担当するエンジンとして、コンフィギュアラブルプロセッサMePを採用した。
MePをDSP拡張することによりプログラマビリティと高いスループットを両立することができる。また、すでに確立されたMePFｒameｗｏｒkを使用できるため、ハードウエア、ソフトウエア双方の開発コストの多くを削減できる。特に今回、非常に短い開発期間しか与えられなかった我々にとって、このことは最も重要なことであった。

( 図2 T4Gのブロックダイヤグラム)

T4Gのブロックダイヤグラムを図2に示す。3DエンジンはMeP MｏdｕleとRendeｒing Engineからなる。MeP MｏdｕleはAPIレイヤと頂点処理レイヤ内の照光処理までを担当する。頂点処理レイヤ内のクリッピング処理とピクセル処理レイヤ以下はRendeｒing Engineが担当し、それらはハードワイヤードロジックで実装されている。
eDRAMには、MePのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Zバッファ等を自由に配置することができる(Unified Memｏｒｙ Aｒchiｔecｔｕｒe)。MPEGエンジン非動作時は20Mbiｔすべてを、MPEGエンジン動作時は16Mbiｔが動画処理に使われてしまうので残りの4Mbiｔを、これらに割り当てることができる。
MeP Mｏdｕleはcｏmmｏnbｕｓを介して各デバイスを制御することができる。また、MeP Mｏdｕle内のDSPは、一般的なジオメトリエンジン(たとえば三菱のZ3D[7]内のDSP)と異なり、汎用プロセッサにおけるコプロセッサに似た使い方ができる。これらのことから、MeP Mｏdｕleは、広く3DCG以外の用途にも使用できるようになっている。
MeP MｏdｕleおよびRendeｒing Engineについて、詳細を以下に述べる。」(2頁右欄24行?3頁右欄1行)

「3.1.MeP Mｏdｕle.
MePに浮動小数点計算能力を付加する時、その方法は2種類ある。1つはDSP拡張[5]、もう1つはVLIW拡張[5][6]である。これらの主な違いは、データメモリに対するアクセス方法である。DSP拡張では演算命令のオペランドに直接データメモリを指定することができる。一方、VLIW拡張では、演算命令のオペランドにはレジスタしか指定できない。データメモリとレジスタ間のデータ転送はlｏad/ｓｔｏｒe命令を別途使用しなければならない。その代わり演算命令とlｏad/ｓｏｔｒe命令が同時に発行できるようになっている。

( 表1 DSP拡張とVLIW拡張の評価結果)

DSP VLIW
サイクル数 69Cｙcleｓ 67Cｙcleｓ
コードサイズ 252Bｙｔeｓ 536Bｙｔeｓ
ゲート規模 50KGaｔeｓ 55KGaｔeｓ

今回、それぞれにISAを定義し、実際に頂点処理における最内ループ部分のコードを記述して、消費サイクル数およびコードサイズを評価した。また拡張部分のゲート数についても評価した。評価に使用したコードは、1頂点について、座標変換と1平行光源の照光処理(ディフューズおよびスペキュラ)を行うコードである。これらの結果を表1に示す。
一般的には、VLIWアーキテクチャの方が、サイクル当たりにアクティブにできる実行ユニット数を増やしやすいので性能が高くなるが、今回の用途においてはDSPアーキテクチャとさほど性能が変わらないことが分かった。一方、VLIWはDSPの2倍以上のコードサイズになる。コードサイズが大きいということは、命令キャッシュのサイズや消費電力の面で不利である。このことから我々は、DSP拡張を選択した。
DSPにおける演算は32biｔ浮動小数点形式で行われる。DSPの命令には、積和、逆数、逆数ルートといった3D処理でよく使われる命令に加え、さまざまな型変換命令を用意した。標準の32biｔ浮動小数点形式だけでなく、8biｔ,16biｔ,32biｔの固定小数点形式および16biｔ浮動小数点形式を柔軟に利用できるようになっている。このことは、さまざまな頂点フォーマットへの対応を容易にするだけでなく、8biｔや16biｔの形式を積極的に使用することで、頂点バッファのサイズおよびベースバンドプロセッサとT4G間の通信トラフィックを節約することに役立つ。

( 図3 MeP Mｏdｕleのブロックダイヤグラム)

( 図4 DSPのパイプライン構造)

MeP Mｏdｕleのブロックダイヤグラムを図3に、DSPのパイプライン構図を図4にそれぞれ示す。図3において、新規に開発したユーザー拡張モジュールはDSP,REIF,BｕｓBｒidgeの3つである。それ以外はMeP Fｒameｗｏｒk内で用意されている標準IPである。
REIFはRendeｒing Engineに頂点処理後のデータを転送する機能を持つ。BｕｓBｒidgeは各バス間のプロトコル変換を行う機能を持つ。
3DCG処理時のデータの流れの例を以下に述べる。まずDMACがeDRAM上にある頂点配列をMePコア内のデータメモリ(Dmem)に転送する。次に、DSPがDmem内の頂点列に対して座標変換処理や照光処理を施す。変換後の頂点列は、REIFとDMACにより、DmemからRendeｒing Engineに転送される。DSPによる演算処理とDMACによるデータ転送は同時に動作する。したがって、DSPはその性能をほぼ100%発揮することができる。MePアーキテクチャでは、Meｐ Mｏdｕle内に高速なローカルバスが定義されている。このため、REIFとDMACは、グローバルバスに負荷をかけずに、効率よく変換後の頂点をRendeｒing Engineに渡すことができる。
このMeP Mｏdｕleの頂点処理の性能は、照光処理なしの場合およそ3.5M Veｒｔeｘ/ｓec(@125MHｚ)、1平行光源の照光処理を行う場合およそ1.5M Veｒｔeｘ/ｓec(@125MHｚ)である。」(3頁右欄2行?4頁右欄9行)
(刊行物1の記載、以上)

以上の記載によると、刊行物1には、
「以前、我々は携帯機器におけるMPEG4 cｏdecの要求に対するソリューションとしてT4を開発した[1]。T4は、専用MPEGエンジンとeDRAM(embedded DRAM)の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした。T4は、eDRAMを集積したことで比較的容量の大きな内蔵メモリを持つことになった。・・・
今回我々は、T4にコンソールゲーム機並みの3DCG描画能力を追加したメディアプロセッサT4Gを開発した。T4Gは、T4におけるMPEG機能と同様、外付けメモリを全く必要とせずに、高品位な3DCG機能を実現できる。eDRAMはMPEG4エンジンと3DCGエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」
との記載から、
「専用MPEGエンジンとeDRAM(embedded DRAM)の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした」「T4にコンソールゲーム機並みの3DCG描画能力を追加したメディアプロセッサT4G」に関する技術が記載されている。
この「T4G」は、「T4」に「3DCG描画能力を追加した」ものであり、「T4」が有する「専用MPEGエンジンとeDRAM(embedded DRAM)の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能」を有するものである。このことは、図2に図示される「T4Gのブロックダイヤグラム」に「MPEG4エンジン」が示されていることにも現れている。
また、「T4におけるMPEG機能と同様、外付けメモリを全く必要とせずに、高品位な3DCG機能を実現できる。」との記載から、「T4G」の「MPEG機能」は、「T4」と同様に「外付けメモリを全く必要とせずに」「機能を実現できる。」ものいえる。
したがって、「T4G」は「専用MPEGエンジンとeDRAM(embedded DRAM)の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたら」すものであり、「外付けメモリを全く必要とせずに」「機能を実現できる」「MPEG機能」を有するといえる。

この「T4G」の「MPEG機能」は「動画の圧縮・伸張機能」といえ、「専用MPEGエンジン」すなわち図2の「MPEG4エンジン」によって実現されるものと認められる。
この「MPEG4エンジン」は、図2によると、
「カメラI/F」に接続され、
「cｏmmｏn bｕｓ」を介して「Hｏｓｔ I/F」に接続され、
「memｏｒｙ bｕｓ」を介して「eDTAM」に接続される。

「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。よって、理想的にはアプリケーションレイヤからフレームバッファレイヤまですべてが1chiｐになっていることが望ましい。アプリケーションを実行する高速な汎用プロセッサを集積して、アプリケーションレイヤ以下を1chiｐで提供するのは、いわゆるアプリケーションプロセッサのソリューションである。このソリューションは、大規模なソフトウエアを格納するための外付けメモリを必要とし、コストや消費電力の面からコストセンシティブなレンジの製品にはただちに適用しづらい面がある。このことからT4GではAPIレイヤからフレームバッファレイヤを1chiｐ化し、コストとパフォーマンスのバランスをとることにした。
T4Gシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい3DCG処理やMPEG cｏdec処理から解放される。大きなプログラムメモリが必要であるがスループットがそれほど要求されない処理はホストプロセッサchiｐで、必要なメモリ量は限られるが非常に高いスループットが求められる処理はメディアプロセッサchiｐで、という処理の切り分けがT4Gの基本コンセプトである。」
と記載され、
「T4G」は「APIレイヤからフレームバッファレイヤを1chiｐ化し」たものであり、
また、「T4Gシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい3DCG処理やMPEG cｏdec処理から解放される。」ことから、この「T4G」を含む「T4Gシステム」が認められ、「T4Gシステム」は「アプリケーションを実行するホストプロセッサ」を有するものであることが認められる。この「アプリケーションを実行するホストプロセッサ」は「演算負荷の大きい3DCG処理やMPEG cｏdec処理から解放される。」とされることから、「MPEG cｏdec処理」(動画の圧縮・伸張機能)は上記したように「T4G」の「MPEG4エンジン」によってなされるといえ、「アプリケーションを実行するホストプロセッサ」は「MPEG cｏdec処理」(動画の圧縮・伸張機能)を行わないといえる。

「T4Gのブロックダイヤグラムを図2に示す。3DエンジンはMeP MｏdｕleとRendeｒing Engineからなる。MeP MｏdｕleはAPIレイヤと頂点処理レイヤ内の照光処理までを担当する。頂点処理レイヤ内のクリッピング処理とピクセル処理レイヤ以下はRendeｒing Engineが担当し、それらはハードワイヤードロジックで実装されている。
eDRAMには、MePのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Zバッファ等を自由に配置することができる(Unified Memｏｒｙ Aｒchiｔecｔｕｒe)。MPEGエンジン非動作時は20Mbiｔすべてを、MPEGエンジン動作時は16Mbiｔが動画処理に使われてしまうので残りの4Mbiｔを、これらに割り当てることができる。」
と記載されており、「MPEGエンジン動作時は16Mbiｔが動画処理に使われてしまう」ことから、「MPEG4エンジン」は「動画処理」に「eDRAM」を「16Mbiｔ」使用する、すなわち、「MPEG4エンジン」は「eDRAM」を使用して「動画処理」を行うと認められる。

これらのことから、刊行物1に、「T4Gシステム」において「動画処理」特に動画の圧縮を行う技術を認めることができる。
「T4Gシステム」は、「アプリケーションを実行するホストプロセッサ」、「メディアプロセッサT4G」を有する。
「T4G」は、「MPEG4エンジン」を有し、
「MPEG4エンジン」は、「カメラI/F」に接続され、「cｏmmｏn bｕｓ」を介して「Hｏｓｔ I/F」に接続され、「memｏｒｙ bｕｓ」を介して「eDTAM」に接続され、「外付けメモリを全く必要とせずに」「eDRAM」を使用して動画の圧縮を行う。
「ホストプロセッサ」は動画の圧縮を行わない。

以上から、刊行物1には、「T4Gシステム」において動画の圧縮を行う技術が認められ、これを刊行物1に記載された発明(以下、「刊行物1発明」ともいう)として、次のとおり認める。

[刊行物1発明]
「アプリケーションを実行するホストプロセッサ」、「メディアプロセッサT4G」を有する「T4Gシステム」において動画の圧縮を行う技術であって、
「T4G」は、「MPEG4エンジン」を有し、
「MPEG4エンジン」は、「カメラI/F」に接続され、「cｏmmｏn bｕｓ」を介して「Hｏｓｔ I/F」に接続され、「memｏｒｙ bｕｓ」を介して「eDTAM」に接続され、「外付けメモリを全く必要とせずに」「eDRAM」を使用して動画の圧縮を行い、
「ホストプロセッサ」は動画の圧縮を行わない
動画を圧縮する技術。

ウ 対比
補正後発明と刊行物1発明とを対比する。

(ア) 「外部ソースによって提供されるマルチメディア信号を符号化する方法」

刊行物1発明は、動画を圧縮する技術であるところ、この動画を圧縮する技術は、「T4G」を有するシステムを用いて動画を圧縮する方法と捉えることもできる。
刊行物1発明は、「T4G」(「MPEG4エンジン」)において、動画の圧縮がなされるものであるところ、この「動画の圧縮」は、「MPEG4エンジン」が行うのであって、刊行物1で「MPEG cｏdec処理」とも説明されることから、動画を「符号化する」ということができる。
刊行物1発明でこの「符号化する」対象となる動画について、刊行物1に直接的な記載はなく、どの「動画」を「符号化する」対象とするのか特定できない。しかし、刊行物1発明で「符号化する」対象の動画は、なんらかの「信号」とはいい得る。
したがって、補正後発明と刊行物1発明とは
「信号を符号化する方法」という点で一致し、
「符号化する」対象の「信号」が、
補正後発明では、「外部ソースによって提供されるマルチメディア信号」であることに対し、
刊行物1発明は、そうでない点で相違する。

(イ) 「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」

刊行物1発明の「T4Gシステム」は、「アプリケーションを実行するホストプロセッサ」を有しており、「ホストプロセッサ」は、「T4Gシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい3DCG処理やMPEG cｏdec処理から解放される。」と説明されることから、元々は「MPEG cｏdec処理から解放され」ておらず、すなわち、「MPEG cｏdec処理」を行っていたものであり、この「T4G」を用いた「T4Gシステム」とすることで「MPEG cｏdec処理から解放され」るものとなったものといえ、また、「T4G」は、「ホストプロセッサ」の行っていた「MPEG cｏdec処理」を「ホストプロセッサ」に代わって行う「メディアプロセッサ」といわれる「プロセッサ」であり、「ホストプロセッサ」に代わって「MPEG cｏdec処理」を含む「メディア」に関する処理を行い、「ホストプロセッサ」の処理を助ける「プロセッサ」ということができる。
この「ホストプロセッサ」と「T4G」との関係は、「ホストプロセッサ」が「中央処理」のプロセッサであり、「T4G」が「中央処理」のプロセッサを助ける周囲のプロセッサという関係であると認められる。

補正後発明における、「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」との関係は、刊行物1発明の「ホストプロセッサ」と「T4G」と同様に、「中央処理」のプロセッサとそれを助ける周囲のプロセッサという関係であると認められ、補正後発明の「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」は、刊行物1発明の「ホストプロセッサ」と「T4G」と対応するものと認められる。そして、刊行物1発明の「ホストプロセッサ」は、「T4G」との上記関係だけでなく、「アプリケーションを実行する」ものであって、「T4Gシステム」として、例えば、刊行物1において想定される携帯電話において、中心的な処理を行うプロセッサとなるものと認められるから、中央処理ユニット(CPU)いい得る。また、刊行物1発明の「T4G」は、「メディアプロセッサ」とされ、「MPEG cｏdec処理」を行うものであって、動画の処理を行うものであり、刊行物1では3D処理をもすると説明されており、「グラフィックス処理」を行う「プロセッサ」といえ、すなわち、「グラフィックス処理ユニット(GPU)」といい得る。

そうすると、補正後発明と刊行物1発明とは、いずれも、「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」を有するといえ、この点で一致する。

もっとも、補正後発明は、
「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」を含むところ、
刊行物1発明は、そうでない点で相違する。

(ウ) 「前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記GPUにおいて受け取るステップであって、前記GPUは該複数のデジタル値を前記GPUの外部に配置されたGPUメモリに格納する、該ステップ」

刊行物1発明において、「T4G」は「MPEG4エンジン」により動画の圧縮を行なうのであり、(ア)で述べたとおり、「信号」を符号化するといえるところ、「T4G」は、符号化の対象となるその信号を、「T4G」の外部から取得して符号化を行うことを想定するものといえ、「T4G」は、符号化の対象を受け取るものと認められる。そして、「T4G」の外部から「受け取る」ために、当然にインターフェイスを介するといえ、具体的には「カメラI/F」もしくは「Hｏｓｔ I/F」を介することとなるものと認められる。

補正後発明において、「前記GPUにおいて受け取る」「前記マルチメディア信号を表す複数のデジタル値」は、符号化の対象といえ、刊行物1発明において「T4G」が受け取るものと認められる符号化の対象と対応するといえる。
そうであるから、補正後発明と刊行物1発明とは、共に「符号化の対象を、インタフェースを介して、前記GPUにおいて受け取るステップ」を含むといえ、この点で一致する。

また、刊行物1発明は「「eDRAM」を使用して動画の圧縮を行」うのであり、この「eDRAM」は「T4G」に含まれ(図2)、「T4G」は「MPEG cｏdec処理」のみならず「3D」の処理もこの「eDRAM」を用いて行うことから、GPUであるところの「T4G」用のメモリ、すなわち、「GPUメモリ」といいうる。
補正後発明は、符号化の対象である「該複数のデジタル値を前記GPUの外部に配置されたGPUメモリに格納する」のであり、符号化にGPUメモリを使用するといえるから、補正後発明と刊行物1発明とは、共に「GPUメモリを使用して符号化を行う」といえ、この点で一致する。
そうであるから、補正後発明と刊行物1発明とは「符号化の対象を、インタフェースを介して、前記GPUにおいて受け取り、GPUメモリを使用して符号化を行うステップ」を含む点で一致する。

もっとも、
補正後発明では、
「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であって、「前記外部ソースから」受け取るものであり、
「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取るものであり、
さらに、
「符号化の対象」である「該複数のデジタル値」を「前記GPUの外部に配置されたGPUメモリに格納する」ものである
ことに対して、
刊行物1発明は、そうでない点で相違する。

(エ) 「前記GPUにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップ」

刊行物1発明は、「T4G」、すなわち、補正後発明でいう「前記GPU」において、動画の符号化を行う。
符号化を行うから、当然にその符号化の結果としての符号化データが生成されるといい得るところ、上記したように、刊行物1発明で符号化を行う対象は「前記マルチメディア信号を表す複数のデジタル値」ではなく、生成される符号化データが、そのような(符号化の対象である)「複数のデジタル値」を符号化した「複数の符号化された値」でない。
そうであるから、補正後発明と刊行物1発明とは、共に、「前記GPUにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」を含むということができ、この点で一致する。
もっとも、補正後発明では、「符号化の対象」が「前記複数のデジタル値」であって、「符号化されたデータ」が「複数の符号化された値」であることに対して、
刊行物1発明は、そうでない点で相違する。

(オ) 「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」

刊行物1発明では、符号化されたデータをいずれに格納するか特定していないから、「符号化されたデータ」(前記複数の符号化された値)「を前記GPUによって前記システムメモリに格納するステップ」を含まない。
したがって、補正後発明が「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」を含むことに対して、
刊行物1発明は、そうでない点で相違する。

(カ) 相違点の整理
以上のとおり構成毎に対比され、補正後発明と刊行物1発明とは、

「信号を符号化する方法」であって、
「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」を有し、
「符号化の対象を、インタフェースを介して、前記GPUにおいて受け取り、GPUメモリを使用して符号化を行うステップ」と、
「前記GPUにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
を含む方法。

で一致し、構成毎の相違は次のとおりである。

・「符号化する」対象の「信号」が、
補正後発明では、「外部ソースによって提供されるマルチメディア信号」であることに対し、
刊行物1発明は、そうでない点。

・補正後発明は、「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」を含むところ、
刊行物1発明は、そうでない点。

・補正後発明では、
「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であって、「前記外部ソースから」受け取るものであり、
「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取るものであり、
さらに、
「符号化の対象」である「該複数のデジタル値」を「前記GPUの外部に配置されたGPUメモリに格納する」ものである
ことに対して、
刊行物1発明は、そうでない点。

・補正後発明では、
「符号化の対象」が「前記複数のデジタル値」であって、
「符号化されたデータ」が「複数の符号化された値」であることに対して、
刊行物1発明は、そうでない点。

・補正後発明が「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」を含むことに対して、
刊行物1発明は、そうでない点。

これら構成における相違は、技術的に次のように整理される。

・補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物1発明が具体的に特定していないことに起因して、
「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
刊行物1発明は、そうでない点。

・補正後発明において、「システムメモリ及びGPUメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」(本件出願明細書【0009】)ための構成として、「GPU130が、経路139及び141を使用して、受け取った未加工のデータをGPUメモリ140に格納する。CPU110が未加工のデータを最初にシステムメモリ120に格納してそれらをGPUメモリ140に転送するのではなく、未加工のデータをGPUメモリ140に直接格納することによって、システムメモリ及びGPUメモリの経路上のバス等のコンポーネントにおける上述したようなボトルネックを軽減することができる。」(本件出願明細書【0039】)と説明され、システムバス115のような共用バスを介して接続されず、そのようなバスを介して「符号化の対象」を受け取らないために、
補正後発明では、「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「GPUメモリに格納する」ものであることに対して、
刊行物1発明は、そうでない点。

・本件出願明細書では「本説明では、未加工のデータをGPUメモリ140に格納した後に符号化することを想定しているが、適切な修正(例えば、レジスタ等の更なるハードウェアを設けること)によって、未加工のデータをGPUメモリ140に格納することなく符号化することができることを理解されたい。」(本件出願明細書【0040】)と説明され、補正後発明における、「GPUメモリ」が「前記GPUの外部に配置された」ものであることの「外部に配置」とは、「適切な修正(例えば、レジスタ等の更なるハードウェアを設けること)によって、未加工のデータをGPUメモリ140に格納することなく符号化することができる」とする「レジスタ等の更なるハードウェア」が、「レジスタ」として普通にCPU等のプロセッサの内部に設けられるように、GPU130内部に設けられることに対して、GPUメモリ140が経路141を介してGPU130に接続されること、つまり、「システムメモリ及びGPUメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」ためにバスを介さないで、しかし、レジスタのようにGPUの内部ではないGPUの外部に接続することをいうと認められる。
刊行物1発明では「外付けメモリを全く必要とせずに」「eDRAM」を使用するのであって、また、図2においても「eDRAM」は「T4G」の内部にある。
そうであるから、「GPUメモリ」の配置に関して、補正後発明では、「GPUメモリ」が「前記GPUの外部に配置された」ものであることに対して、
刊行物1発明は、そうでない点。

・CPUとGPUとの処理の関係において、CPUがGPUに処理をさせ、その結果をCPUが用いるようにするために、補正後発明は、
「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」を含むことに対して、
刊行物1発明は、そうでない点。

エ 一致点相違点
以上の対比によると、補正後発明と刊行物1発明との一致点、相違点は次のとおりである。

[一致点]
「信号を符号化する方法」であって、
「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」を有し、
「符号化の対象を、インタフェースを介して、前記GPUにおいて受け取り、GPUメモリを使用して符号化を行うステップ」と、
「前記GPUにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
を含む方法。

[相違点]
(相違点1)
補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物1発明が具体的に特定していないことに起因して、
「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
刊行物1発明は、そうでない点。

(相違点2)
補正後発明において、「システムメモリ及びGPUメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」(本件出願明細書【0009】)ための構成として、「符号化の対象」を受け取るときに「システムメモリ」「GPUメモリの経路上のバス(図1でGPUメモリは経路141を介してGPUに接続され、システムバス115のような共用バスを介して接続されていない。)」を介さないために、
補正後発明では、「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「GPUメモリに格納する」ものであることに対して、
刊行物1発明は、そうでない点。

(相違点3)
「GPUメモリ」の配置に関して、補正後発明では、「GPUメモリ」が「前記GPUの外部に配置された」ものであることに対して、
刊行物1発明は、そうでない点。

(相違点4)
CPUとGPUとの処理の関係において、CPUがGPUに処理をさせ、その結果をCPUが用いるようにするために、補正後発明は、
「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」を含むことに対して、
刊行物1発明は、そうでない点。

オ 相違点の検討、判断
(ア) 相違点1について
刊行物1において、「携帯機器、特に携帯電話に対して要求される機能は飛躍的に増大し、カメラ機能、動画処理機能だけでなく、コンソールゲーム機器並みの処理能力を要する3DCG機能が要求されるようになってきている。」と説明されることから、「T4G」は携帯電話に用いられることが想定されており、図2における「カメラI/F」は、その先に携帯電話におけるカメラ機能のためのカメラを接続して用いることが容易に想到できる。
また、先にも述べたように、「T4Gシステム」における「アプリケーションを実行するホストプロセッサ」は、携帯電話において、中心的な処理を行うプロセッサとなるものと認められ、そのホストプロセッサが実行するアプリケーションとして、携帯電話のカメラ、カメラ機能を利用して、画像を取り込み利用するアプリケーションが容易に想到できる。
そうであるから、刊行物1発明において、圧縮(符号化)の対象として「カメラI/F」の先に接続されるカメラからの映像信号を容易に想到できる。
刊行物1発明は、
「ホストプロセッサ」は動画の圧縮を行わないのであり、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」ことから、チップ間の通信、すなわち、ホストプロセッサとT4Gとの間のHｏｓｔ I/Fを介した通信の通信量に課題があることが示唆されること、
Hｏｓｔ I/FとカメラI/Fとが別にあること、
カメラI/Fがその名称からカメラ専用のインターフェイスであって、カメラに直接つながることを思わせること
から、カメラI/Fから先にカメラを接続するときの通信経路を、カメラI/Fとカメラとを直接接続することを容易に想到できるといえる。
そうであるから、刊行物1発明において、カメラI/Fとカメラとを直接接続し、カメラからの映像を符号化することを、当業者は容易に想到できる。その際、「T4G」がデータ処理するために、カメラから映像をデジタルデータとして送るようにすることを容易に想到できる。そして、そのようなデジタルデータが通常複数のデジタル値であることから、カメラからの映像を複数のデジタル値で送ることも自然に想到できるといえる。
ここで、携帯電話において、カメラは映像のソースということができ、外部にあることは明らかであって、外部ソースといい得るものであり、その映像は、多くの形態を取るマルチメディアのひとつの形態としてマルチメディア信号といい得る。また、そのような映像を符号化したとき、「複数の符号化された値」となることも普通に想到できる。

したがって、刊行物1発明を携帯電話に採用することを想定して、カメラI/Fとカメラとを直接接続して、カメラからの映像を符号化するようにし、刊行物1発明において、「符号化する」対象の「信号」を「外部ソースによって提供されるマルチメディア信号」とし、「前記外部ソースから」受け取るものとし、「符号化の対象」を受け取るための「インターフェイス」を「前記外部ソースに接続する」ものとし、「符号化の対象」を「前記マルチメディア信号を表す複数のデジタル値」とし、「符号化されたデータ」を「複数の符号化された値」とすることで、相違点1に係る補正後発明の構成とすることは、当業者が容易に想到できることといえる。

(イ) 相違点2について
刊行物1発明は、「ホストプロセッサ」を有し、「T4G」の「Hｏｓｔ I/F」の先にバスを介して接続されると普通に想到できる。同時に、「ホストプロセッサ」として通常「CPU」といわれる中央処理プロセッサを想到し、システムメモリを用いて通常の動作を行う仕組みを想到できる。
上記(ア)で述べたとおり、
「ホストプロセッサ」は動画の圧縮を行わないのであり、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」ことから、チップ間の通信、すなわち、ホストプロセッサとT4Gとの間のHｏｓｔ I/Fを介した通信の通信量に課題があることが示唆されていて、刊行物1発明において、カメラI/Fとカメラとを直接接続することは容易に想到できる。そうであるから、「符号化の対象」を「前記システムメモリに格納することなく、」受け取ることを容易に想到できる。
「符号化の対象」を「前記マルチメディア信号を表す複数のデジタル値」とし、「符号化されたデータ」を「複数の符号化された値」とすることは上記のとおり容易に想到できることである。
そうであるから、刊行物1発明において、「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取る構成を容易に想到できる。

刊行物1発明の「T4G」が符号化を行う「MPEG4エンジン」は、符号化に際して「eDRAM」を使用する。どのように「eDRAM」を使用するかは特定できないが、動画のMPEGによる符号化に当たって、入力されるデータが「複数のデジタル値」であって、アナログ信号のようにリアルタイムで変換処理を行えるものではなく、少なくともひとつのデジタル値としてまとまったデータを処理する必要から、受け取ったデータを一旦貯えてから貯えたデータを処理することは容易に想到でき、その際、データを貯える場所を、符号化に使用するメモリ、すなわち、記憶する場所である「eDRAM」とすることは容易に想到できる。したがって、「符号化の対象」である「該複数のデジタル値」を「GPUメモリに格納する」ようにすることは容易に想到できるといえる。

そうすると、刊行物1発明において、「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取り、さらに、「符号化の対象」である「該複数のデジタル値」を「GPUメモリに格納する」ものとすることは、当業者が容易に想到できるといえる。

(ウ) 相違点3について
刊行物1には、「T4は、eDRAMを集積したことで比較的容量の大きな内蔵メモリを持つことになった。このことは、新たな機能をT4に追加するときのコスト上昇を最小にする可能性がある。
今回我々は、T4にコンソールゲーム機並みの3DCG描画能力を追加したメディアプロセッサT4Gを開発した。T4Gは、T4におけるMPEG機能と同様、外付けメモリを全く必要とせずに、高品位な3DCG機能を実現できる。eDRAMはMPEG4エンジンと3DCGエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」と記載されている。
ここで、「外付けメモリが不要」とする「外付けメモリ」とは、「T4は、eDRAMを集積したことで比較的容量の大きな内蔵メモリを持つことになった」とされる「内蔵メモリ」に対して「外付けメモリ」というと理解され、「T4」が「内蔵メモリ」を持たず「外付けメモリ」を必要とした場合、「T4」が追加されるシステムにおいて、「T4」がチップとしてCPU等が接続される共通バスに接続されて追加されると共に、「外付けメモリ」も共通バスに接続されて追加されると理解できる。このことは、このように「外付けメモリ」が共通バスに接続されて追加されることにより、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」と説明される「チップ間の通信」すなわち共通バスを用いた通信における消費電力の問題が、「内蔵メモリ」とすることによって「外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」と解決されるように説明されることからも理解できる。

刊行物1発明は、「外付けメモリを全く必要とせずに」「eDRAM」を使用するものであり、図2のように「eDRAM」は「T4G」に内蔵される。このことで、上記のような消費電力の問題が解決されるところ、それは、「T4G」が使用する「eDRAM」がHｏｓｔ I/Fの先に想定される共通バスに接続されず、共通バスを介さずに、「T4G」が直接に使用できることにより奏する効果であることは普通に理解できる。
刊行物1では、
「eDRAMには、MePのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Zバッファ等を自由に配置することができる(Unified Memｏｒｙ Aｒchiｔecｔｕｒe)。MPEGエンジン非動作時は20Mbiｔすべてを、MPEGエンジン動作時は16Mbiｔが動画処理に使われてしまうので残りの4Mbiｔを、これらに割り当てることができる。
MeP Mｏdｕleはcｏmmｏnbｕｓを介して各デバイスを制御することができる。また、MeP Mｏdｕle内のDSPは、一般的なジオメトリエンジン(たとえば三菱のZ3D[7]内のDSP)と異なり、汎用プロセッサにおけるコプロセッサに似た使い方ができる。これらのことから、MeP Mｏdｕleは、広く3DCG以外の用途にも使用できるようになっている。」
と説明され、「広く3DCG以外の用途にも使用できる」「MeP Mｏdｕle」が使用するメモリである「eDRAM」は「MPEGエンジン非動作時は20Mbiｔすべてを、MPEGエンジン動作時は16Mbiｔが動画処理に使われてしまうので残りの4Mbiｔを」用いることになって、「MPEGエンジン」と「MeP Mｏdｕle」とが「eDRAM」を共用、競合することが理解される。
そして、「MeP Mｏdｕle」が「広く3DCG以外の用途にも使用できる」とされ、今後新たな処理を「MeP Mｏdｕle」に負わせることを当業者であれば予測するといえ、その際、新たな処理によっては現在実装している「eDRAM」の容量が将来不足することが予測されるのも自然である。
そうであるから、「eDRAM」の容量が将来不足することを想定して、将来のその時の要求に従って「eDRAM」を適宜に増設又は置換できるように、外付けすることが普通に想到される。
しかしながら、システムとして通常のようにメモリをHｏｓｔ I/Fの先に想定される共通バスに接続すると、メモリを共通バスに接続しないことによる「T4」「T4G」の上記のような利点が失われることも、普通に理解できる。
そうであるから、メモリを共通バスに接続しないことによる利点を残したまま、「eDRAM」を増設又は置換するために、「T4G」のmemｏｒｙ bｕｓに対して、「eDRAM」を外付けすることが当業者であれば容易に想到されるといえる。
そうすると、「eDRAM」を共通バスに接続しないで「T4G」に外付けすることとなり、補正後発明と同じく、「GPUメモリ」が「前記GPUの外部に配置された」構成となる。
このように、補正後発明の相違点3に係る構成は、当業者が容易に想到できるといえる。

(エ) 相違点4について
上記(ア)で述べたように、ホストプロセッサが実行するアプリケーションとして、携帯電話のカメラ、カメラ機能を利用して、画像を取り込み利用するアプリケーションが容易に想到できる。
そのような携帯電話のカメラ、カメラ機能を利用するアプリケーションとして、画像の取り込み、すなわち、カメラからの画像を符号化して、表示、記録、加工などの処理のために符号化後の画像データを取得することは、容易に想到できる。
その取得のために、アプリケーションを実行する「ホストプロセッサ」(CPU)から符号化を行う「T4G」に必要なコマンド(例えば符号化の開始や符号化処理のオプションなど)を送り、符号化後の画像データをアプリケーションが利用できるように、アプリケーションを実行する「ホストプロセッサ」(CPU)が利用するシステムメモリに格納させることは、容易に想到できる。
そして、「T4G」に送る「必要なコマンド」を、アプリケーションを実行する「ホストプロセッサ」(CPU)が利用するシステムメモリに格納しておき、その格納しておいたコマンドを送るようにすることは、
CPUがシステムメモリにプログラム等を展開してそのプログラムの下で動作すること、
「T4G」が新たに開発されたプロセッサであり、刊行物1発明を携帯電話に採用する際に、「ホストプロセッサ」として携帯電話の従来からある「プロセッサ」を用いて、「T4G」に特化した「プロセッサ」ではないものを用いることが容易に想到されるから、新たに開発されたプロセッサである「T4G」に対するコマンドが「ホストプロセッサ」に内蔵されておらず、外部から「ホストプロセッサ」に与える必要が容易に想到できること
から、
「T4G」に対するコマンドを外部から「ホストプロセッサ」に与えるために、そのコマンドをシステムメモリに格納して「ホストプロセッサ」に使用させるようにして、容易に想到できることといえる。

ここで、符号化を行う「T4G」に必要なコマンドは「前記マルチメディア信号を符号化するためのコマンド」ということができるから、このように、「T4G」に送る「必要なコマンド」を、アプリケーションを実行する「ホストプロセッサ」(CPU)が利用するシステムメモリに格納しておき、その格納しておいたコマンドを送るようにすることは、
「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」
ということができ、
補正後発明の相違点4に係る構成とすることは、当業者が容易に想到できることといえる。

(オ) 総合
以上のとおり、相違点1ないし4に係る補正後発明の構成は、それぞれ容易に想到できるといえるところ、これらを総合した構成における補正後発明の効果も予測できると認められる。
したがって、補正後発明は、刊行物1に記載された発明に基づいて、当業者が容易に発明をすることができたものである。

カ 独立特許要件のまとめ
以上のとおり、本件補正後の請求項4に係る発明は、刊行物1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができるものであるとはいえない。

(3)補正の却下の決定の理由のまとめ
以上のとおり、本件補正後の請求項4に係る発明は、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができるものであるとはいえない。
したがって、平成23年9月15日付けの手続補正は、平成23年法律第63号改正附則第2条第18項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第6項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって、補正の却下の決定の結論のとおり、決定する。

3 本願発明
上記のとおり、平成23年9月15日付けの手続補正は却下した。
したがって、本件出願の請求項1ないし8に係る発明は、平成23年3月1日付けで補正された特許請求の範囲の請求項1ないし8に記載されたとおりのものであり、そのうち、請求項4に係る発明(以下、本願発明という)は、次のとおりである。

[本願発明](【請求項4】)
外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記GPUにおいて受け取るステップであって、前記GPUは該複数のデジタル値をGPUメモリに格納する、該ステップと、
前記GPUにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップと、
を含む方法。

本願発明は、上記したように、補正後発明に対して、「GPUメモリ」について、「前記GPUの外部に配置された」の特定を削除するものである。

4 刊行物1
上記[2 (2) イ]のとおり、刊行物1発明が認められる。

5 対比
本願発明と刊行物1発明とは、上記[2 (2) ウ]と同様に対比され、本願発明と刊行物1発明との一致点、相違点は次のとおりであると認められる。なお、相違点3を欠番とした。

[一致点]
「信号を符号化する方法」であって、
「中央処理ユニット(CPU)」と「グラフィックス処理ユニット(GPU)」を有し、
「符号化の対象を、インタフェースを介して、前記GPUにおいて受け取り、GPUメモリを使用して符号化を行うステップ」と、
「前記GPUにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
を含む方法。

[相違点]
(相違点1)
補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物1発明が具体的に特定していないことに起因して、
「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
刊行物1発明は、そうでない点。

(相違点2)
補正後発明において、「システムメモリ及びGPUメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」(本件出願明細書【0009】)ための構成として、「符号化の対象」を受け取るときに「システムメモリ」「GPUメモリの経路上のバス(図1でGPUメモリは経路141を介してGPUに接続され、システムバス115のような共用バスを介して接続されていない。)」を介さないために、
補正後発明では、「符号化の対象」を受け取るとき、(「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を)「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「GPUメモリに格納する」ものであることに対して、
刊行物1発明は、そうでない点。

(相違点4)
CPUとGPUとの処理の関係において、CPUがGPUに処理をさせ、その結果をCPUが用いるようにするために、補正後発明は、
「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット(CPU)からグラフィックス処理ユニット(GPU)に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
「前記複数の符号化された値を前記GPUによって前記システムメモリに格納するステップ」を含むことに対して、
刊行物1発明は、そうでない点。

6 判断
上記相違点1、2、4は、補正後発明と刊行物1発明との相違点1、2、4と同じであり、上記[2 (2) オ]と同じく判断されるから、本願発明は、刊行物1に記載された発明に基づいて、当業者が容易に発明をすることができたものである。

7 まとめ むすび
以上のとおり、本件出願の請求項4に係る発明は、刊行物1に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、本件出願は、残る請求項1ないし3、請求項5ないし8に係る発明について特に検討するまでもなく拒絶されるべきものである。
よって、結論のとおり審決する。
 
審理終結日 2012-09-21 
結審通知日 2012-09-25 
審決日 2012-10-10 
出願番号 特願2008-126215(P2008-126215)
審決分類 P 1 8・ 121- Z (H04N)
P 1 8・ 121- Z (H04N)
P 1 8・ 575- Z (H04N)
最終処分 不成立  
前審関与審査官 岩井 健二  
特許庁審判長 奥村 元宏
特許庁審判官 猪瀬 隆広
松尾 淳一
発明の名称 マルチメディア信号の符号化  
代理人 柏岡 潤二  
代理人 城戸 博兒  
代理人 山田 行一  
代理人 池田 成人  
代理人 池田 正人  
代理人 山口 和弘  
代理人 野田 雅一  

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