【事件の表示】
　特願２００８−５３３４９４「プロセッサにおけるタスクおよびデータ管理」拒絶査定不服審判事件〔平成１９年　４月　５日国際公開、ＷＯ２００７／０３８４５６、平成２１年　３月１２日国内公表、特表２００９−５１０６１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　　
　本願は，２００６年９月２５日（パリ条約による優先権主張外国庁受理２００５年９月２７日　アメリカ合衆国）を国際出願日とする出願であって，
平成２０年３月２６日付けで特許法第１８４条の５第１項の規定による書面が提出され，
平成２０年５月２６日付けで特許法第１８４条の４第１項の規定による請求の範囲，明細書，図面，要約書の日本語による翻訳文が提出されとともに，審査請求がなされ，
平成２３年５月２日付けで拒絶理由通知がなされ，
同年７月１５日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，
平成２４年１月５日付けで拒絶査定がなされ，
同年４月１７日付けで審判請求がされるとともに，同日付けで手続補正がなされ，
同年６月８日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，
平成２５年１月２４日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされたが，これに対する回答はなされなかったのであって，
その請求項１に係る発明は，平成２４年４月１７日付け手続補正書によって補正された特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下，「本願発明」という。）
　
「プロセッサのコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも，大きいメモリ空間を必要とするプロセッサイベントを，プロセッサが，前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである２以上のセグメントに分割するステップと，
　前記２以上のセグメントを，プロセッサが，前記プロセッサの１以上のコプロセッサエレメントにおいて処理し，対応する２以上の出力を生成するステップと，
　プロセッサが，前記２以上の出力を関連づけて１以上のグループとするステップとを備え，
　各グループのデータサイズは，各グループを入力として用いる次のプロセスのためのターゲット入力データサイズ以下であるプロセッサのタスクおよびデータ管理方法。」
　
　
２．引用文献
（１）引用文献１
　これに対して，本願の第１国出願前に頒布され，平成２３年５月２日付けで通知した拒絶の理由に引用した，特開平１０−４０４１４号公報（以下，「引用文献１」という。）には，図面とともに次の事項が記載されている（当審注：下線は，参考のために当審で付与したものである。以下，同じ。）。
　
　Ａ「【０００５】マルチプロセッサでデータを均等に分割分配し負荷を分散させ，各プロセッサでそのデータに対してのみ処理を行なう方式では，各プロセッサに分割後のデータすべてを格納できるサイズ分のメモリがあることが条件であり，任意の１つのプロセッサが他の処理でローカルメモリを用いていた場合など，分割デ−タがロ−カルメモリに格納しきれない時の事は考えられていない。また，３次元数値デ−タには描画処理が参照しないデ−タも多くあり，その分のデ−タ転送は処理のオーバヘッドとなる。さらに他のプロセッサのデータを使用する場合にはプロセスを移す必要があるが，視点角度によっては何度も行なわなくてはならず，通信のオーバヘッドが多くなりかえって時間がかかる可能性がある。また，トレースを用いた方式では，データの内容や表示条件によっては視点角度が違うと参照するデータが異なるため，事前に得たトレース情報が役に立たない場合が多い。さらに常に高速に実行するためにはあらゆる条件に対するトレース情報を収集し管理しておく必要があり，この情報量は無視できない大きさになる。」
　
　Ｂ「【００１１】
【発明の実施の形態】以下，本発明の実施の形態の一例を詳細に説明する。図１は，
本発明を適用するシステム
ルートプロセッサ１−１はユーザからの描画要求を受け付けると，３次元数値データ１−７−１とデータの構成とデータ参照パターンに関する情報１−７−２を共有メモリ１−７へ格納し，描画条件の取得し，処理の分配を行なう機能１−１−５，を実行する。分割した処理に関する情報は，ルートプロセッサからバス１−９を経由して複数のプロセッサ群１−２〜３にデ−タ転送する。
各プロセッサ内では描画処理に先立ち，計算時の参照デ−タの配置情報とバッファサイズを求める処理１−１−１，１−２−１，１−３−１を実行し，ローカルメモリ１−４〜６内にバッファ１−４−１，１−５−１，１−６−１を確保する。
その後，描画処理１−１−２，１−２−２，１−３−２で分担した処理を実行して２次元画像を生成する
　
　Ｃ「【００１２】
バッファ確保処理時，ロ−カルメモリが不足して確保できない場合には，他プロセッサとの通信処理１−１−３，１−２−３，１−３−３を用いて，ル−トプロセッサ１−１に通知する。ル−トプロセッサは任意プロセッサからの通信を受け取ると，接続されているプロセッサの稼働状況情報１−４−３を参照し，処理を再分割して任意複数プロセッサへ分配送信する処理１−１−４を実行する。各プロセッサ１−１〜３で生成した２次元画像の値１−１１−１はフレームバッファ１−１１へ格納し，表示処理プロセッサ１−１２へ渡った表示命令を表示処理機能１−１２−１で処理した時に，画面１−１３へ表示する。
　
　Ｄ「【００１４】
各プロセッサに割り当てられた描画対象領域の情報として，各プロセッサの処理担当領域の個数２−７と，その領域の開始位置のｘ座標２−８，２−１０，開始位置のｙ座標２−９，２−１１を持つ。これらは並列処理を行なうための情報であり，各プロセッサの処理担当部分は１以上の領域から成り，それらの位置を示すすべてのｘ座標とｙ座標の情報を持つ。分割はルートプロセッサが行ない，描画命令と一緒に通知されてきたこれらの情報を各プロセッサの管理情報テーブルに格納する。
　
　Ｅ「【００２６】図１０は，各プロセッサでの処理において，対象３次元数値データを格納するバッファをローカルメモリに確保する処理の流れを示したものである。ユーザからの要求があると描画処理であるかを判定し（１０−１），描画処理でないならば対応する処理を実行する（１０−２）。描画処理ならばルートプロセッサは処理の分割を行ない（１０−３），分担処理の情報・描画条件情報・３次元数値データの全体サイズ・構成情報等を付加した描画要求を各プロセッサに渡し（１０−４），各プロセッサは要求を受け取る（１０−５）。次に管理情報テ−ブルのバッファサイズ２−１７が０かを判定し（１０−６），０であれば１回目のボクセル計算でバッファのサイズを算出する（１０−７）。ローカルメモリの空き領域サイズを入手し（１０−８），バッファサイズを算出してバッファを確保する（１０−９）。その後確保したバッファを用いて描画処理を行なう（１０−１０）。
【００２７】図１１は，バッファの使用制御の処理の流れである。
各プロセッサは割り当てられた画素を求めるのに参照するデータ
　
　Ｆ「【００２８】図１２は，描画計算処理中に，計算に必要なローカルメモリが確保できない場合のプロセッサにおける処理の流れである。バッファサイズ削減の有無を識別する削減フラグを用意し０で初期化する（１２−１）。ロ−カルメモリの空き領域を求め（１２−２），現在の指定されたバッファサイズでバッファが確保できるかを判断し（１２−３），可能であれば確保して（１２−４），描画処理を実行する（１２−５）。現在のバッファサイズで確保できない場合はロ−カルメモリの空き領域サイズと規定した最少バッファサイズとを比較し（１２−６），最少バッファサイズよりも大きい場合は最少バッファサイズと空き領域サイズとの間の値でバッファサイズを求めバッファを確保する（１２−７）。この時求めたバッファのｘ，ｙ，ｚ方向サイズは管理情報テ−ブルに再登録し（１２−８），削減フラグに１を代入する（１２−９）。得たバッファを使って描画処理を実行する（１２−５）。ロ−カルメモリの空き領域サイズが最少バッファよりも小さい場合には処理の分割を行なっているル−トプロセッサにその旨を通知し（１２−１０），処理を終了する。
ルートプロセッサでは通知を受けると（１２−１１），該当するプロセッサの担当処理を稼働可能なプロセッサ数で分割し（１２−１２），稼働可能なプロセッサに再分配する（１２−１３）。ル−トプロセッサも処理を分担し描画処理を行なう（１２−１４）。
　
　以下に，引用文献１の記載事項について検討する。
　
（ア）引用文献の上記Ｂ及びＣの記載は，システムを実行させる方法の発明について説明するものであり，
　上記Ｂの「ルートプロセッサ１−１はユーザからの描画要求を受け付けると，３次元数値データ１−７−１とデータの構成とデータ参照パターンに関する情報１−７−２を共有メモリ１−７へ格納し，描画条件の取得し，処理の分配を行なう機能１−１−５，を実行する。分割した処理に関する情報は，ルートプロセッサからバス１−９を経由して複数のプロセッサ群１−２〜３にデ−タ転送する。・・・各プロセッサ内では描画処理に先立ち，計算時の参照デ−タの配置情報とバッファサイズを求める処理１−１−１，１−２−１，１−３−１を実行し，ローカルメモリ１−４〜６内にバッファ１−４−１，１−５−１，１−６−１を確保する。・・・その後，描画処理１−１−２，１−２−２，１−３−２で分担した処理を実行して２次元画像を生成する。」との記載，及び，上記Ｃの「各プロセッサ１−１〜３で生成した２次元画像の値１−１１−１はフレームバッファ１−１１へ格納し，表示処理プロセッサ１−１２へ渡った表示命令を表示処理機能１−１２−１で処理した時に，画面１−１３へ表示する。」との記載から，
　引用文献１に記載の方法は，
“ルートプロセッサが，ユーザからの描画要求を受け付けると，３次元数値データとデータの構成とデータ参照パターンに関する情報を共有メモリへ格納し，描画条件の取得し，処理の分配を行なう機能を実行する”ことと，
“分割した処理に関する情報を，ルートプロセッサからバスを経由して複数のプロセッサ群にデ−タ転送する”ことと，
“各プロセッサ内で，描画処理に先立ち，計算時の参照デ−タの配置情報とバッファサイズを求める処理を実行し，ローカルメモリ内にバッファを確保する”ことと，
“描画処理において分担した処理を実行して２次元画像を生成する”ことと，
“各プロセッサで生成した２次元画像の値をフレームバッファへ格納し，表示処理プロセッサへ渡った表示命令を表示処理機能で処理した時に，画面へ表示する”ことと，を有することがよみとれる。
　
（イ）上記（ア）における“・・・バッファを確保する”ことに関し，
　上記Ｃの「バッファ確保処理時，ロ−カルメモリが不足して確保できない場合には，他プロセッサとの通信処理１−１−３，１−２−３，１−３−３を用いて，ル−トプロセッサ１−１に通知する。ル−トプロセッサは任意プロセッサからの通信を受け取ると，接続されているプロセッサの稼働状況情報１−４−３を参照し，処理を再分割して任意複数プロセッサへ分配送信する処理１−１−４を実行する。」との記載，及び，上記Ｆの「ルートプロセッサでは通知を受けると（１２−１１），該当するプロセッサの担当処理を稼働可能なプロセッサ数で分割し（１２−１２），稼働可能なプロセッサに再分配する（１２−１３）。ル−トプロセッサも処理を分担し描画処理を行なう（１２−１４）。」との記載から，
　引用文献１に記載の方法は，“各プロセッサ内で，描画処理に先立ち，計算時の参照デ−タの配置情報とバッファサイズを求める処理を実行し，ローカルメモリ内にバッファを確保するとともに，ロ−カルメモリが不足して確保できない場合には，ル−トプロセッサが，該当するプロセッサの担当処理を稼働可能なプロセッサ数で分割し，稼働可能なプロセッサに再分配する”ことを有することがよみとれる。
　
　以上，（ア）及び（イ）を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
　ルートプロセッサが，ユーザからの描画要求を受け付けると，３次元数値データとデータの構成とデータ参照パターンに関する情報を共有メモリへ格納し，描画条件の取得し，処理の分配を行なう機能を実行することと，
　分割した処理に関する情報を，ルートプロセッサからバスを経由して複数のプロセッサ群にデ−タ転送することと，
　各プロセッサ内で，描画処理に先立ち，計算時の参照デ−タの配置情報とバッファサイズを求める処理を実行し，ローカルメモリ内にバッファを確保するとともに，ロ−カルメモリが不足して確保できない場合には，ル−トプロセッサが，該当するプロセッサの担当処理を稼働可能なプロセッサ数で分割し，稼働可能なプロセッサに再分配することと，
　描画処理において分担した処理を実行して２次元画像を生成することと，
　各プロセッサで生成した２次元画像の値をフレームバッファへ格納し，表示処理プロセッサへ渡った表示命令を表示処理機能で処理した時に，画面へ表示することと，を有する，
　システムを実行させる方法。
　
（２）引用文献２
　本願の第１国出願前に頒布され，平成２３年５月２日付けで通知した拒絶の理由に引用した，近藤伸宏，「ＣＥＬＬプロセッサに見るアーキテクチャ　―次世代デジタルホームに向けて」，東芝レビュー，２００５年７月１日，第６０巻，第７号，ｐｐ．４８−５１（以下，「引用文献２」という。）には，図とともに次の事項が記載されている（当審注：下線は，参考のために当審で付与したものである。以下，同じ。）。
　
　Ｇ「
ＣＥＬＬプロセッサ
８個のＳＰＥ
各ＳＰＥは
ローカルストアを持っている
ＳＩＭＤ型演算は，一つの命令で複数のデータを同時に処理する演算
　
（３）引用文献３
　本願の第１国出願前に頒布され，平成２３年５月２日付けで通知した拒絶の理由に引用した，「＜設計思想をひも解く＞　埋め込まれた遺伝子で変幻自在に進化」，日経エレクトロニクス，日経ＢＰ社，２００５年２月２８日，第８９４号，ｐｐ．１００−１０９（以下，「引用文献３」という。）には，図とともに次の事項が記載されている（当審注：下線は，参考のために当審で付与したものである。以下，同じ。）。
　
　Ｈ「
各ＳＰＥ
ローカル・ストア
　
同時に動作する複数のＳＰＥの演算性能
チップ全体を管理する機能もＣｅｌｌ
　Ｃｅｌｌでは，
チップ全体を管理する役割をＰｏｗｅｒアーキテクチャに基づくＣＰＵコアのＰＰＥが担う
　
３．対比　
　
　本願発明と引用発明とを対比する。
　
（１）引用発明の「複数のプロセッサ」は，本願発明の「１以上のコプロセッサエレメント」に相当するとともに，引用発明の「ローカルメモリ」は，本願発明の「ローカルストレージ」に相当する。
　また，引用発明の「ルートプロセッサ」及び「複数のプロセッサ」はシステムに含まれるものであるところ，それはプロセッサシステムと呼べるものであり，一方，本願発明の「プロセッサ」も「１以上のコプロセッサエレメント」を有することから，上位概念において，プロセッサシステムといえ，よって，両者は，“プロセッサシステム”である点で共通する。
　
（２）引用発明の「処理の分配を行なう機能を実行すること」から「稼働可能なプロセッサに再分配すること」までの一連のステップが，本願発明の「分割するステップ」に対応するものであるが，
　引用発明において「分割」されるものとは，上記Ｄの「各プロセッサに割り当てられた描画対象領域の情報として，各プロセッサの処理担当領域の個数２−７と，その領域の開始位置のｘ座標２−８，２−１０，開始位置のｙ座標２−９，２−１１を持つ。これらは並列処理を行なうための情報であり，各プロセッサの処理担当部分は１以上の領域から成り，それらの位置を示すすべてのｘ座標とｙ座標の情報を持つ。分割はルートプロセッサが行ない，描画命令と一緒に通知されてきたこれらの情報を各プロセッサの管理情報テーブルに格納する。」との記載，及び上記Ｅの「各プロセッサは割り当てられた画素を求めるのに参照するデータ・・」との記載から，実際に分割され描画処理に用いられるのは「処理」のために参照される対象データであるといえる。
　一方，本願発明の「分割」され「処理」される「プロセッサイベント」とは，本願発明の詳細な説明の段落【００３２】「・・ＣＴＤＭプログラム１０２は，所与のＳＰＥにおいて使用可能なメモリ空間よりも多くのメモリ空間を必要とする大きいタスク（処理イベント１０４という）を，より小さいサイズの塊(chunk)であるセグメント１０６に分割する。」との記載によれば「タスク」が対応するものと解されるが，同じく段落【００６２】〜【００６６】「例として，ＣＴＤＭは，以下の計算に基づいてデータのセグメントを生成してもよい。
SPUIOBufferSize = 51200 バイト;(50 * 1024バイト)(  ＳＰＵ入力+出力バッファサイズ) 
InputElementSize = 32 バイト;(上記の項目４;)
OutputElementSize = 48 バイト;( 上記の項目５)
//初めに，一のバッファ入力+出力に，幾つの完全なエレメントが収まるか見出す必要がある。
・・・（中略）・・・
ActualSegmentSize = 50k (すなわち 51200バイト) ;
NbrOfSegments = TotalDataSize / ActualSegmentSize;
NbrOfSegments = 1*1024バイト*1024バイト/ 51200バイト;
NbrOfSegments = 20; //これは，整数の変数である。余りは切り捨てられる。
//もしも余りがあるならば，その余りを処理するために，さらに一のセグメントを加えなければならない。以下のコードは，余りがあるか否か判定し，その余っているデータに，さらに一のセグメントを加える。
if ( TotalDataSize % ActualSegmentSize )
//%は，モジュラスと呼ばれ，整数の割り算の余りを返す。
NbrOfSegments = NbrOfSegments + 1;
NbrOfSegments = 21;
　ＣＴＤＭがＳＰＵ上で１メガバイトのデータを動的に処理するためには，上記のＳＰＵの構成と，入力および出力のデータサイズを所与として，２１（実際には２０．４８）個のデータセグメントが必要である。」との記載によれば，分割単位である「セグメント」のサイズは，ＳＰＵに対し入出力されるデータのサイズをもとに計算されており，当該ＳＰＵに対し入出力されるデータとは，タスクにおける処理の対象データに他ならないことから，「プロセッサイベント」に対応するタスクのうち分割される対象は，タスクによる処理の対象データであるといえ，よって，引用発明の「処理」の対象データと，本願発明の「プロセッサイベント」との間に，実質的な差異はない。
　してみると，引用発明の上記一連のステップにおいて「処理」における対象データを「複数のプロセッサ」のために分割することと，本願発明の「プロセッサのコプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも，大きいメモリ空間を必要とするプロセッサイベントを，プロセッサが，前記ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズである２以上のセグメントに分割するステップ」とは，ともに，“プロセッサイベントを，プロセッサシステムが，２以上のセグメントに分割するステップ”である点で共通する。
　
（３）引用発明の「複数のプロセッサ」において「分担した処理を実行して」各々「生成」した「２次元画像」データは，「フレームバッファ」に対し格納されるのであるから複数の出力データであるといえ，よって，引用発明の「複数のプロセッサ」において「分担した処理を実行して」各々「生成」した「２次元画像」データは，本願発明の「１以上のコプロセッサエレメントにおいて処理し」て「生成」した「対応する２以上の出力」に相当する。
　してみると，引用発明における「複数のプロセッサ」において「分担した処理を実行して」各々「２次元画像」データを「生成」することと，本願発明の「前記２以上のセグメントを，プロセッサが，前記プロセッサの１以上のコプロセッサエレメントにおいて処理し，対応する２以上の出力を生成するステップ」とは，ともに，“前記２以上のセグメントを，プロセッサシステムが，前記プロセッサシステムの１以上のコプロセッサエレメントにおいて処理し，対応する２以上の出力を生成するステップ”である点で共通する。
　
（４）引用発明である「システムを実行させる方法」は，「処理」に関する「３次元数値データとデータの構成とデータ参照パターンに関する情報」等のデータを扱うとともに，タスクに対応する「処理」を分配し実行するものであることから，本願発明である「プロセッサのタスクおよびデータ管理方法」と，“プロセッサシステムのタスクおよびデータ管理方法”である点で共通する。
　
　すると，両者は，
「プロセッサイベントを，プロセッサシステムが，２以上のセグメントに分割するステップと，
　前記２以上のセグメントを，プロセッサシステムが，前記プロセッサシステムの１以上のコプロセッサエレメントにおいて処理し，対応する２以上の出力を生成するステップとを備えた，
　プロセッサシステムのタスクおよびデータ管理方法。」
　
　である点で一致し，次の点で相違する。　
　
（相違点１）プロセッサシステムに関し，
　本願発明は，「プロセッサ」であるのに対し，
　引用発明は，複数のプロセッサを有するシステムが「プロセッサ」と呼べる構成とはなっていない点。
　
（相違点２）プロセッサイベントのセグメントへの分割に関し，
　本願発明は，「コプロセッサエレメントのローカルストレージにおいて利用可能であるメモリ空間よりも，大きいメモリ空間を必要とする」プロセッサイベントを，「ローカルストレージにおいて利用可能であるメモリ空間の大きさ以下のセグメントサイズ」のものに分割することであるのに対し，
　引用発明は，「処理」の対象データを「複数のプロセッサ」での分担処理のために分割するものであるものの，分割前後の対象データの大きさと，「複数のプロセッサ」の利用可能な「ローカルメモリ」の大きさの関係について，明確には言及していない点。
　
（相違点３）
　本願発明は，「プロセッサイベントを，プロセッサシステムが，２以上のセグメントに分割するステップ」を行って，「前記２以上のセグメントを，プロセッサシステムが，前記プロセッサシステムの１以上のコプロセッサエレメントにおいて処理し，対応する２以上の出力を生成するステップ」を行うこととしているのに対し，
　引用発明は，「処理」の対象データの分割が，明確に，２次元画像を生成することに先だって行われているとは，言及していない点。
　
（相違点４）
　本願発明は，「プロセッサが，前記２以上の出力を関連づけて１以上のグループとするステップ」を有するのに対し，
　引用発明は，そのようなステップを有するかは明りょうでない点。
　
（相違点５）
　本願発明は，「各グループのデータサイズは，各グループを入力として用いる次のプロセスのためのターゲット入力データサイズ以下である」としているのに対し，
　引用発明は，その点について明確にしていない点。
　
４．当審の判断　
　
　上記相違点１ないし５について検討する。
　
（相違点１）について
　ローカルストアを備えたコプロセッサエレメントであるＳＰＥを複数備え，当該ＳＰＥにおけるデータ転送及び演算処理を管理することで複数処理を並行して行うＣｅｌｌプロセッサの構成は，本願第１国出願時において周知（例えば，引用文献２の上記Ｇの記載，引用文献３の上記Ｈの記載を参照）であり，引用発明のタスク及びデータ管理の方法を，上記周知の構成における処理及びデータ管理に適用すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易になし得ることである。
　よって，相違点１は格別なものではない。
　
（相違点２）及び（相違点３）について
　一般にプロセッサ要素において演算等のデータ処理を行う際に，内蔵メモリにデータを読み込んで処理を行うことは常套手段であるところ，データを分割した上で処理を行う際に，処理に必要なメモリ容量を，内蔵メモリの利用可能容量以下になるようにデータ分割することは，上記常套手段を勘案すれば，必然的に行う事項である。
　また，メモリの利用可能な容量値として，構成として既知のメモリ容量値をそのまま用いたり，一部処理の実行結果により得られる算出値を用いたりすることは，いずれもよく知られた慣用手段であり，これより，上記内蔵メモリの利用可能容量として，構成情報から既知であるメモリ容量値を用いるか，それとも，一部処理を実行した結果から得られる算出値を用いるようにするかは，必要により適宜選択して行う設計的事項である。
　してみると，引用発明の「処理」の対象データを分割する際に，プロセッサのローカルメモリにおいて利用可能であるメモリ空間よりも，大きいメモリ空間を必要とする「処理」の対象データを，ローカルメモリにおいて利用可能であるメモリ空間の大きさ以下のサイズのものに分割するとともに，当該分割を，２次元画像生成に先だって行うようにすること，すなわち，上記相違点２及び３に係る構成とすることは，当業者が容易になし得ることである。
　よって，相違点２及び３は格別なものではない。
　
（相違点４）及び（相違点５）について
　引用発明は，「各プロセッサで生成した２次元画像の値をフレームバッファへ格納し，表示処理プロセッサへ渡った表示命令を表示処理機能で処理した時に，画面へ表示する」ものであるところ，画面表示を行うための一画面分の画像データを記憶するフレームバッファは，例示するまでもなく周知の構成であり，当該周知構成のフレームバッファを採用する際に，フレームバッファに格納する複数の２次元画像データを１つのグループとして扱うこと，及び，当該複数の２次元画像データのサイズを次のプロセスに利用される上記フレームバッファに格納可能なサイズとすることは，画像表示処理を行う上で当然に行うことである。
　してみると，引用発明における出力データ処理において，上記周知構成を適用し，その際に画像表示処理上当然に行うこととして，「プロセッサが，前記２以上の出力を関連づけて１以上のグループとするステップ」を有し，「各グループのデータサイズは，各グループを入力として用いる次のプロセスのためのターゲット入力データサイズ以下である」ようにすること，すなわち，上記相違点４及び５に係る構成とすることは，当業者が容易になし得ることである。
　よって，相違点４及び５は格別なものではない。
　
（本願発明の作用効果について）
　そして，本願発明の構成によってもたらされる効果も，引用発明及び周知技術から当業者が容易に予測することができる程度のものであって，格別のものとはいえない。　
　
５．むすび
　
　以上のとおり，本願発明は，上記引用発明及び周知技術に基いて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は，拒絶されるべきものである。
　
　よって，結論のとおり審決する。