【事件の表示】
　特願２０００−２０３１７３「並列処理装置、及び、並列処理方法」拒絶査定不服審判事件〔平成１４年　１月２５日出願公開、特開２００２−　２４１９５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯・本願発明 
　本願は、平成１２年７月５日の出願であって、平成１６年１１月４日付けで拒絶理由通知がなされ、平成１７年１月６日付けで手続補正がなされたが、同年５月２４日付けで拒絶査定がなされ、これに対し、同年６月２７日に審判請求がなされるとともに同年７月２６日付けで手続補正がなされたものである。
　 
第２．平成１７年７月２６日付けの手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
　平成１７年７月２６日付けの手続補正を却下する。 
　 
［理由］ 
１．補正後の本願発明 
　本件手続補正により、特許請求の範囲は、 
　 
「　【請求項１】複数のノードと、
　前記複数のノードの間を非同期にノード間通信する相互通信網とを含み、
　前記ノードは、
　複数のＣＰＵと、
　前記ノード間通信を制御する通信制御ユニットとを備え、
　前記通信制御ユニットは、前記ＣＰＵから送付される非同期通信リクエストを非同期通信リクエストバッファに記録し、
　前記通信制御ユニットは、前記非同期通信リクエストバッファがｆｕｌｌであるかどうかに基づいて、前記非同期通信リクエストを受理するか受理しないかの受理・不受理について受理・不受理リプライを前記ＣＰＵに返却し、
　前記ＣＰＵは、返却された前記受理・不受理リプライをチェックし不受理リプライであった場合は、前記非同期通信リクエストを前記通信制御ユニットに再送する
　並列処理装置。
　　【請求項２】
　前記通信制御ユニットは、前記受理・不受理のうちの不受理に対応する前記非同期転送リクエストを廃棄する
　請求項１の並列処理装置。
　　【請求項３】前記ＣＰＵは、返却された前記受理・不受理リプライをチェックし受理リプライであった場合は、他の後続処理を実行する
　請求項１の並列処理装置。
　　【請求項４】前記通信制御ユニットは、
　前記非同期転送リクエストを受け付ける非同期転送リクエスト受付ユニットと、
　前記非同期転送リクエストを受理するかどうかを判定するリクエスト受理判定ユニットと、
　前記リクエスト受理判定ユニットで前記受理が可能であると判断された前記非同期転送リクエストを保持するリクエスト管理ユニットとを備える
　請求項１の並列処理装置。
　　【請求項５】前記非同期通信リクエストバッファは、前記リクエスト管理ユニットに属している
　請求項４の並列処理装置。
　　【請求項６】前記通信制御ユニットは、
　ノード間通信実行制御部を更に備え、
　前記リクエスト管理ユニットは、前記ノード間通信実行制御部からリクエスト送付要求を受けるまで、前記非同期通信リクエストを保持する
　請求項５の並列処理装置。
　　【請求項７】前記リクエスト受理判定ユニットは、複数の前記ＣＰＵから同時的に複数の非同期転送リクエストを受信した場合は、前記複数の非同期転送リクエストを順次に選択的に前記リクエスト判定ユニットに送付する
　請求項６の並列処理装置。
　　【請求項８】前記リクエスト受理判定ユニットは、前記リクエスト管理ユニットが保持する前記非同期通信リクエストの存在に基づいて、前記受理・不受理を判定する
　請求項７の並列処理装置。
　　【請求項９】前記通信制御ユニットは、
　リプライ返却ユニットを更に備え、
　前記リクエスト受理判定ユニットは、前記受理・不受理を判定した場合、前記受理・不受理に対応する受理信号・不受理信号を前記リプライ返却ユニットに対し通知する
　請求項８の並列処理装置。
　　【請求項１０】前記リクエスト受理判定ユニットは、前記受理・不受理のうちの不受理を判定した場合、前記不受理に対応する前記非同期転送リクエストを廃棄する
　請求項９の並列処理装置。
　　【請求項１１】前記リプライ返却ユニットは、前記受理・不受理に対応する受理通知・不受理通知を前記受理・不受理に対応する前記非同期転送リクエストを発行したＣＰＵに前記受理・不受理リプライ情報を返却する
　請求項９の並列処理装置。
　　【請求項１２】前記ＣＰＵは、
　命令発行制御部と、
　リプライ受信レジスタとを備え、
　前記命令発行制御部は、前記非同期転送リクエストを発行して非同期通信命令を前記通信制御ユニットに送出する
　請求項１の並列処理装置。
　　【請求項１３】前記命令発行制御部は、前記リプライ受信レジスタに前記通信制御ユニットから前記受理・不受理リプライ情報が戻るまで、前記非同期通信命令の発行の完了を待つ完了待ち状態に入る
　請求項１２の並列処理装置。
　　【請求項１４】前記完了待ち状態に入った前記命令発行制御部は、前記ＣＰＵ上のプロセス切り替えを抑止するために割り込み禁止状態に入る
　請求項１３の並列処理装置。
　　【請求項１５】それぞれに複数のＣＰＵと通信制御ユニットを含む複数のノードの間で非同期に通信すること、
　前記ＣＰＵから送付される非同期通信リクエストを通信制御ユニットの非同期通信リクエストバッファで記録すること、
　前記通信制御ユニットの中で前記非同期通信リクエストバッファがｆｕｌｌであるかどうかを判定することとを含み、
　前記通信制御ユニットは、前記非同期通信リクエストを受理するか受理しないかの受理・不受理について受理・不受理リプライを前記ＣＰＵに返却し、
　前記ＣＰＵは、返却された前記受理・不受理リプライをチェックし不受理リプライであった場合は、前記非同期通信リクエストを前記通信制御ユニットに再送する
　並列処理方法。
　　【請求項１６】前記ＣＰＵは、返却された前記受理・不受理リプライをチェックし受理リプライであった場合は、他の後続処理を実行する
　請求項１５の並列処理方法。
　　【請求項１７】前記通信制御ユニットは、複数の前記ＣＰＵから同時的に複数の非同期転送リクエストを受信した場合は、前記複数の非同期転送リクエストの受理・不受理を順次に選択的に判定する
　請求項１５の並列処理方法。
　　【請求項１８】前記通信制御ユニットは、前記受理・不受理のうちの不受理を判定した場合、前記不受理に対応する前記非同期転送リクエストを廃棄する
　請求項１７の並列処理方法。
　　【請求項１９】前記ＣＰＵは、前記受理・不受理リプライが戻るまで、前記非同期通信リクエストの発行の完了を待つ完了待ち状態に入る
　請求項１８の並列処理方法。
　　【請求項２０】前記完了待ち状態に入った前記ＣＰＵは、前記ＣＰＵ上のプロセス切り替えを抑止するために割り込み禁止状態に入る
　請求項１９の並列処理方法。」 
　 
と補正された。 
　 
２．新規事項の有無、補正の目的要件  
　本件手続補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第１７条の２第３項規定に適合し、かつ、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものである。 
　
３．独立特許要件  
　本件手続補正は特許法１７条の２第４項第２号の特許請求の範囲の減縮を目的とすることから、本件手続補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）以下に検討する。  
　  
（１）補正後の発明
　本件手続補正により、本願補正発明は、前記「１．補正後の本願発明」の「【請求項１】」に記載されたものと認められる。 
　
（２）引用文献 
　原査定の拒絶の理由に引用された、特開平１１−１３４３０９号公報（以下、「引用文献」という。）には以下の事項が記載されている。（注意：下線は便宜上、当審にて付与したもの。） 
　 
（ア）「【０００８】
【発明の実施の形態】以下、本発明の実施形態を図面に用い説明する。図１は本発明の
並列計算機システム
複数のノード
ノード間でメッセージを転送するネットワーク７
【０００９】ノード０（９００）は、ＯＳやユーザアプリケーションを実行する
プロセッシングノード（以降ＰＵ）
ネットワークインタフェースアダプタ
　・・・（中略）・・・
【００１１】図１に戻り、
ＮＩＡ３は
ネットワーク７にメッセージを送出するセンダ５、ネットワーク７からのメッセージを受信するレシーバ６から成る。
【００１２】次に、センダ５の構成例を図３で説明する。
センダ５は
送出要求キュー制御部４１
送出要求キュー４５と
　 
（イ）「【００２６】
メッセージ送出処理を開始する場合、ＰＵ１は仮想ポート番号をメッセージ送出要求としてＮＩＡ３に渡す。
送出要求キュー制御部４１は、送出要求キュー４５に空きエントリがあるか否かを判定して
空エントリがあれば
メッセージ送出要求（仮想ポート番号）をキューイング
空エントリがなければ
キューイングしない
送出要求キュー制御部４１は、メッセージ送出要求をキューイングしたか否かを
ＰＵ１へ伝える。
　 
（ウ）「【００４２】　・・・（中略）・・・　本実施の形態に於いては送出要求キュー４５を４面と仮定しており、図４では信号線２６９は４の値で示している。該メッセージ送出要求数と送出要求キュー４５の面数が一致した場合、つまり
送出要求キュー４５がＦＵＬＬの場合に比較器２２０の出力は“１”となる。
受付結果レジスタ
ＰＵ１からのメッセージ送出要求に対し、該受付結果レジスタ２００を送出要求受付結果として信号線２３、バス制御部４を介してＰＵ１へ伝える。
　 
　上記（ア）における記載「図１は本発明の並列計算機システムの一実施形態の全体構成図である。本システムは、計算などの処理を行う複数のノード０〜３（９００〜９０３）をノード間でメッセージを転送するネットワーク７を介し信号線１４〜１８で接続した構成である。」からすると、
　引用文献には、複数のノードと、前記複数のノードの間をメッセージのノード間通信するネットワークとを含む、並列計算機システムが記載されている。
　また、（ア）における記載「ノード０（９００）は、ＯＳやユーザアプリケーションを実行するプロセッシングノード（以降ＰＵ）１、データを格納するための主記憶２、ネットワーク７とノード０（９００）とのインタフェースを司るネットワークインタフェースアダプタ（以降ＮＩＡ）３、ＰＵ１と主記憶２とＮＩＡ３とを接続するシステムバス１０、システムバス１０とＰＵ１とを接続する信号線１１、システムバス１０と主記憶２とを接続する信号線１２、システムバス１０とＮＩＡ３とを接続する信号線１３とから成る。」からすると、前記ノードは、プロセッシングノードと、前記ノード間通信を制御するネットワークインタフェースアダプタとを備えている。
　同じく、（ア）における記載「ＮＩＡ３は、・・・（中略）・・・ネットワーク７にメッセージを送出するセンダ５、・・・（中略）・・・から成る。　・・・（中略）・・・　センダ５は、・・・（中略）・・・送出要求キュー制御部４１と、・・・（中略）・・・送出要求キュー４５と、・・・（中略）・・・からなる。」からすると、前記ネットワークインタフェースアダプタは、送出要求キュー制御部と送出要求キュー４５とを備えている。
　そして、（イ）における記載「メッセージ送出処理を開始する場合、ＰＵ１は仮想ポート番号をメッセージ送出要求としてＮＩＡ３に渡す。・・・（中略）・・・　送出要求キュー制御部４１は、送出要求キュー４５に空きエントリがあるか否かを判定して、空エントリがあれば、信号線７０を介して送出要求キュー４５へライトアドレスとライトイネーブルを伝えて、信号線２１上の該メッセージ送出要求（仮想ポート番号）をキューイングし、空エントリがなければ、該メッセージ送出要求をキューイングしない。」及び（ウ）における記載「送出要求キュー４５がＦＵＬＬの場合に比較器２２０の出力は“１”となる。本実施の形態に於いては、受付結果レジスタ２００の値は、メッセージ送出要求が受け付けられた場合を“０”、メッセージ送出要求が受け付けられなかった場合を“１”とする。ＰＵ１からのメッセージ送出要求に対し、該受付結果レジスタ２００を送出要求受付結果として信号線２３、バス制御部４を介してＰＵ１へ伝える。」からすると、
　前記ネットワークインタフェースアダプタは、前記プロセッシングノードから送付されるメッセージ送出要求を送出要求キューに記録し、前記ネットワークインタフェースアダプタは、前記送出要求キューがｆｕｌｌであるかどうかに基づいて、前記メッセージ送出要求を受け付けるか受け付けないかの送出要求受付結果を前記プロセッシングノードに返却すると解される。
　 
　したがって、引用文献には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。 
　 
　複数のノードと、
　前記複数のノードの間をメッセージのノード間通信するネットワークとを含み、
　前記ノードは、
　プロセッシングノードと、
　前記ノード間通信を制御するネットワークインタフェースアダプタとを備え、
　前記ネットワークインタフェースアダプタは、前記プロセッシングノードから送付されるメッセージ送出要求を送出要求キューに記録し、
　前記ネットワークインタフェースアダプタは、前記送出要求キューがｆｕｌｌであるかどうかに基づいて、前記メッセージ送出要求を受け付けるか受け付けないかの送出要求受付結果を前記プロセッシングノードに返却する
　並列計算機システム。
　 
（３）対比 
　ここで、本願補正発明と引用発明とを比較する。 
　引用発明の「ネットワーク」、「プロセッシングノード」、「ネットワークインタフェースアダプタ」、「受け付けるか受け付けないか」、「送出要求受付結果」、及び「並列計算機システム」は、それぞれ、本願補正発明の「相互通信網」、「ＣＰＵ」、「通信制御ユニット」、「受理するか受理しないか」、「受理・不受理について受理・不受理リプライ」、及び「並列処理装置」に対応する。 
　
　そして、引用発明の「メッセージ送出要求」と本願補正発明の「非同期通信リクエスト」とは、ともに、通信リクエストである点で一致する。
　同様に、引用発明の「送出要求キュー」と本願補正発明の「非同期通信リクエストバッファ」とは、ともに、通信リクエストバッファである点で一致する。
　
　よって、本願補正発明と引用発明とは、以下の点で一致し、また、相違している。 
　 
（一致点） 
　 
　複数のノードと、
　前記複数のノードの間をノード間通信する相互通信網とを含み、
　前記ノードは、
　ＣＰＵと、
　前記ノード間通信を制御する通信制御ユニットとを備え、
　前記通信制御ユニットは、前記ＣＰＵから送付される通信リクエストを通信リクエストバッファに記録し、
　前記通信制御ユニットは、前記通信リクエストバッファがｆｕｌｌであるかどうかに基づいて、前記通信リクエストを受理するか受理しないかの受理・不受理について受理・不受理リプライを前記ＣＰＵに返却する
　並列処理装置。
　 
（相違点１） 
  本願補正発明は、複数のノードの間を非同期にノード間通信するのに対して、引用発明は、複数のノードの間を非同期にノード間通信するかどうか、明らかでない点。
　
（相違点２） 
　「通信リクエスト」に関して、本願補正発明は、「非同期通信リクエスト」であるのに対して、引用発明の「メッセージ送出要求」が非同期「メッセージ送出要求」であるかどうか、明らかでない点。
　
（相違点３）
　「通信リクエストバッファ」に関して、本願補正発明は、「非同期通信リクエスト」に対する「バッファ」であるのに対して、引用発明の「送出要求キュー」が、非同期「メッセージ送出要求」に対する「キュー」であるかどうか、明らかでない点。
　
（相違点４） 
　本願補正発明は、ノードが複数のＣＰＵを備えているのに対して、引用発明は、ノードが複数のプロセッシングノード（「ＣＰＵ」に相当）を備えていない点。
　
（相違点５）
　本願補正発明は、「前記ＣＰＵは、返却された受理・不受理リプライをチェックし不受理リプライであった場合は、前記非同期通信リクエストを前記通信制御ユニットに再送するのに対して、引用発明が、プロセッシングノード（「ＣＰＵ」に相当）は、返却された前記送出要求受付結果（「受理・不受理リプライ」に相当）をチェックし受け付けられなかった結果であった（「不受理リプライであった」に相当）場合は、前記メッセージ送出要求（「非同期通信リクエスト」に対応）を前記ネットワークインタフェースアダプタ（「通信制御ユニット」に相当）に再送するかどうか、明らかでない点。
　 
（４）判断 
　まず、相違点１〜相違点３について検討する。
　本願の出願日前である平成１年１１月２４日に頒布された刊行物である、特開平１−２９２５５９号公報に、
　「〔従来の技術〕
　・・・（中略）・・・
　並列計算機のプロセッサ間通信においては、並列性の効果が大きく、並列処理による速度向上も得られることから、非同期通信方式が採られることが多い。」（２頁左下欄９行目〜１２行目。）と記載されているように、
　並列計算機のプロセッサ間通信において、並列処理による速度向上を得るために、非同期通信方式を採用することは、当業者にとって周知の常套技術である。
　そして、引用発明が並列計算機に関する発明であることから、当業者であれば、当然非同期通信方式を採用するものと認められる。
　してみれば、引用発明の「ノード間通信」において、本願補正発明のように「複数のノードの間を非同期にノード間通信する」構成とすることは、当業者であれば、適宜なし得たことである。
　その際に、引用発明における「メッセージ送出要求」が非同期「メッセージ送出要求」であること、及び「送出要求キュー」が非同期メッセージ送出要求に対する「送出要求キュー」であることは、論理的に明らかである。
　よって、相違点１〜相違点３は格別のものではない。 
　
　次に相違点４について検討する。
　本願の出願日前である平成１２年４月２１日に頒布された刊行物である、特開２０００−１１２９１２号公報に、
　「【０００４】図１を参照すると、分散メモリ型並列計算機は、複数の計算ノード１／２　・・・（中略）・・・と、それらを結ぶＮｅｔｗｏｒｋ３を有している。計算ノード１は、ＣＰＵ（中央演算装置：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１、ＭＭＵ（主記憶装置：Ｍａｉｎ  Ｍｅｍｏｒｙ  Ｕｎｉｔ）１２、ＲＣＵ（遠隔制御装置：Ｒｅｍｏｔｅ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）１３で構成される。」及び
　「【００４０】４．１つの計算ノード内は１つのＣＰＵで構成されるとして説明したが、これらの数に制限はない。つまり、ノード内はマルチＣＰＵによる共有メモリ型でもよい。」と記載されているように、
　並列計算機のノードが複数のＣＰＵを備えることは、当業者にとって周知の技術である。
　してみれば、引用発明の「ノード」が、本願補正発明のように「複数のプロセッシングノード（「ＣＰＵ」に相当）を備え」る構成とすることは、当業者であれば、適宜なし得たことである。
　よって、相違点４は格別のものではない。
　
　最後に相違点５について検討する。
　本願の出願日前である平成９年５月２日に頒布された刊行物である、特開平９−１１４７２７号公報に、
　「【０００２】
【従来の技術】　・・・（中略）・・・　ライトバッファがフル（ｆｕｌｌ）状態になった後のライトリクエストに対しては、メモリ制御部においてライトバッファ内に溜ったライトトランザクションが終了し、ライトバッファに後続のライトリクエストを受け付けることの可能な空きができるまで、システムバス上で
リトライ応答を行う
【０００３】
【発明が解決しようとする課題】しかしながら、従来の方式では、ライトバッファのフル状態、すなわち、メモリが
ライトバッファのビジーによりライトアクセスを受け付けることができない場合に、リクエスタはライトリクエストを繰り返す
　リクエスト時において、バッファがフルでリクエストを受け付けられなかった場合に、該リクエストをリトライ（すなわち、再送）することは、当業者にとって周知の常套手段である。
　してみれば、引用発明の「メッセージ送出要求」（「リクエスト」に対応）時において、キュー（「バッファ」に対応）がフルで前記「メッセージ送出要求」を受け付けられなかった場合において、前記周知技術を適用することで、本願補正発明のように、プロセッシングノード（「ＣＰＵ」に相当）は、返却された前記送出要求受付結果（「受理・不受理リプライ」に相当）をチェックし受け付けられなかった結果であった（「不受理リプライであった」に相当）場合は、前記メッセージ送出要求（「非同期通信リクエスト」に対応）を前記ネットワークインタフェースアダプタ（「通信制御ユニット」に相当）に再送する構成とすることは、当業者であれば、適宜なし得たことである。
　よって、相違点５は格別のものではない。
　
　上記で検討したごとく、相違点１〜相違点５はいずれも格別のものではなく、そして、本願補正発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、本願補正発明は上記引用発明、及び周知技術に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
（５）請求人の主張について
　請求人は、当審より平成１９年１０月１８日付けで通知した審尋に対して、同年１１月１４日に提出した、回答書において以下の主張をしている。
　
　「審査官殿は、拒絶査定の備考において、「また、引用文献１に記載の発明において、送信要求キュー制御部は空エントリが無ければメッセージ送信要求はキューイングしないことから、キューイングしないメッセージ送信要求を廃棄しているものと認められる。」と指摘しています。 
  しかし、「不受理リプライであった場合は、非同期通信リクエストを通信制御ユニットに再送し、且つ、不受理に対応する非同期転送リクエストを廃棄する構成 」は、引用文献１には開示されていません。更に、引用文献１には、本願発明における非同期通信処理、特にハンドシェーク方式の非同期通信処理に特有の問題点（段落０００５参照）は一切開示も示唆もされておりません。」
 　
　そこで、前記主張を検討する。
　引用文献１においても、段落【００４２】に記載されているように、ネットワークアダプタにおいて、送信要求キュー制御部は、送出要求キューがＦＵＬＬの場合は、メッセージ送出要求を受け付けない、送出要求キューに記録しないことからすると、該メッセージ送出要求は廃棄されていることは、当業者にとって明らかである。
　
　また、本願発明における非同期通信処理、特にハンドシェーク方式の非同期通信処理に特有の問題点について、段落【０００５】を参照すると、
「このハンドシェーク方式では、図８と図９とに示されるように、ＣＣＵ１０１のリクエストバッファ（非同期通信リクエストバッファ）がｆｕｌｌ状態になると、リクエストバッファのエントリが空くまで、ＣＣＵ１０１はＣＰＵ１０２に対してハンドシェークリプライを返却しないことになって（ステップＳ１０２，１０３，１０４）、ＣＰＵは非同期通信命令の発行が完了しないため、割り込み禁止状態が解除できないので、ＣＰＵの使用効率を著しく低下する問題があった。」と記載されている。
　したがって、本願発明における非同期通信処理、特にハンドシェーク方式の非同期通信処理に特有の問題点とは、「リクエストバッファのエントリが空くまで、ＣＣＵ１０１はＣＰＵ１０２に対してハンドシェークリプライを返却しない」というハンドシェーク方式の処理に起因すると認められる。
　しかしながら、引用文献１記載の発明は、送出要求キュー（「リクエストバッファ」に相当）のエントリがＦＵＬＬの場合には、ネットワークインタフェースアダプタ（「ＣＣＵ１０１」に相当）はプロセッシングノード（「ＣＰＵ１０２」に相当）に対して受け付けない旨の送出要求受付結果（「ハンドシェークリプライ」に対応）を返却するものであることから、明らかに、本願発明におけるハンドシェーク方式の処理に特有の問題点（すなわち、「リクエストバッファのエントリが空くまで、ＣＣＵ１０１はＣＰＵ１０２に対してハンドシェークリプライを返却しない」点）については、解決されていると認められる。
　なお、引用文献１記載の発明において、「非同期通信処理」とする点、及び「不受理リプライであった場合は、非同期通信リクエストを通信制御ユニットに再送する」点は、前記「（４）判断」で検討したとおり、当業者にとって適宜なし得たことである。
　以上のように、請求人の前記主張は採用することはできない。
　 
４．むすび 
　以上のとおり、本件手続補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件手続補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　 
第３．本願発明について 
　平成１７年７月２６日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１７年１月６日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。 
　 
　「複数のノードと、
　前記複数のノードの間を非同期にノード間通信する相互通信網とを含み、
　前記ノードは、
　複数のＣＰＵと、
　前記ノード間通信を制御する通信制御ユニットとを備え、
　前記通信制御ユニットは、前記ＣＰＵから送付される非同期通信リクエストを非同期通信リクエストバッファに記録し、
　前記通信制御ユニットは、前記非同期通信リクエストバッファがｆｕｌｌであるかどうかに基づいて、前記非同期通信リクエストを受理するか受理しないかの受理・不受理について受理・不受理リプライを前記ＣＰＵに返却し、
　前記ＣＰＵは、前記受理・不受理リプライのうちの不受理リプライに基づいて、前記非同期通信リクエストを前記通信制御ユニットに再送する
　並列処理装置。」 
　 
（１）引用文献 
　原査定の拒絶の理由に引用された、引用文献およびその記載事項は、前記「第２．平成１７年７月２６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献」に記載したとおりである。 
　 
（２）対比・判断 
　本願発明は、前記「第２．平成１７年７月２６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（１）補正後の発明」に記載された本願補正発明から本願発明を特定するために必要な事項である
「前記ＣＰＵは、返却された前記受理・不受理リプライをチェックし不受理リプライであった場合は、前記非同期通信リクエストを前記通信制御ユニットに再送する」において、「返却された前記受理・不受理リプライをチェックし不受理リプライであった場合は、」から「返却された」及び「チェックし」を省き、「前記受理・不受理リプライのうちの不受理リプライに基づいて」とすることで、「前記ＣＰＵは、前記受理・不受理リプライのうちの不受理リプライに基づいて、前記非同期通信リクエストを前記通信制御ユニットに再送する」としたものである。
　そうすると、本願発明の構成要件を全て含み、さらに特定の構成要件に限定要件を付加したものに相当する本願補正発明が、前記「第２．平成１７年７月２６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（４）判断」に記載したとおり、引用発明、及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明、及び周知技術に基づいて、当業者が容易に発明をすることができたものである。 
　 
（３）むすび 
　以上のとおり、本願発明は、引用発明、及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　よって、結論のとおり審決する。