【事件の表示】
　特願２００５−１１７４０４「トポロジを意識したジョブ・スケジューリングとバックフィルとをＨＰＣ環境において行うシステム及び方法」拒絶査定不服審判事件〔平成１７年１１月　４日出願公開、特開２００５−３１０１３９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成１７年４月１４日（パリ条約による優先権主張２００４年４月１５日　アメリカ合衆国）の外国語書面出願であって，
　平成１７年６月１３日付けで特許法第３６条の２第２項の規定による明細書，請求の範囲の日本語による翻訳文が提出されると共に審査請求がなされ，平成１９年１０月１５日付けで審査官により拒絶理由が通知され，これに対して平成２０年１月２３日付けで意見書が提出されると共に手続補正がなされたが，平成２１年３月３０日付けで審査官により拒絶査定がなされ，これに対して同年８月７日付けで審判請求がなされると共に手続補正がなされ，平成２２年１月８日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，同年１１月３０日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２３年４月７日付けで回答書が提出され，
　平成２３年８月２６日付けで当審により平成２１年８月７日付けの手続補正が却下されると共に拒絶理由が通知され，平成２４年２月２９日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２．本願発明について
　本願の請求項に係る発明は，平成２４年２月２９日付けの手続補正（以下，「本件手続補正」という）よって補正された，請求項１乃至請求項２９に記載の次の事項により特定されるものである。
　
「　　【請求項１】
　ＨＰＣ環境においてジョブを管理する方法であって，
　実行する対象のＨＰＣジョブを，ソートされたジョブ・キューから管理プロセッサによって選択する工程と，
　前記選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程であって，前記ＨＰＣノードそれぞれが統合ファブリックを備え，前記複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する工程と，
　前記仮想ノード・クラスタの少なくとも一部分を用いて前記選択されたＨＰＣジョブを実行する工程とを備えることを特徴とする方法。
　　【請求項２】
　請求項１記載の方法であって，前記ＨＰＣジョブを選択する工程が：
　前記ＨＰＣジョブを前記ジョブ・キューから優先度に基づいて選択する工程を備え，
　前記選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備えることを特徴とする方法。
　　【請求項３】
　請求項２記載の方法であって，前記ＨＰＣジョブを前記ソートされたジョブ・キューから優先度に基づいて選択する工程が，
　ジョブ・キューをジョブ優先度に基づいてソートする工程と，
　第１ＨＰＣジョブを前記ソートされたジョブ・キューから選択する工程と，
　前記仮想ノード・クラスタの前記トポロジによって前記第１ＨＰＣジョブの寸法を判定する工程と，
　前記第１ＨＰＣジョブの前記寸法が前記仮想ノード・クラスタの前記トポロジよりも大きいことに応じて，第２ＨＰＣジョブを前記ソートされたジョブ・キューから選択し，前記仮想ノード・クラスタの再構成を待って，前記第１ＨＰＣジョブを前記ソートされたジョブ・キューに戻す工程とを備えることを特徴とする方法。
　　【請求項４】
　請求項３記載の方法であって，前記第１ＨＰＣジョブの前記寸法が：
　１つ又は複数のジョブ・パラメータと，関連ポリシーとに基づくことを特徴とする方法。
　　【請求項５】
　請求項２記載の方法であって，
　前記選択されたＨＰＣジョブの前記寸法に基づいて前記仮想ノード・クラスタからジョブ空間を動的に割り当てる工程を更に備え；
　前記選択されたＨＰＣジョブを実行する工程が：
　該動的に割り当てられたジョブ空間を用いて前記選択されたＨＰＣジョブを実行する工程；
　を備えることを特徴とする方法。
　　【請求項６】
　請求項１記載の方法であって，
　前記複数のＨＰＣノードが第１の複数のノード及び第２の複数のノードを備え，前記第１の複数のノードは前記仮想ノード・クラスタと関連付けられ，
　前記選択されたＨＰＣジョブの寸法が前記第１の複数のノードのトポロジよりも大きい旨を判定する工程と，
　１つ又は複数のＨＰＣノードを前記第２の複数のノードから選択する工程と，
　前記第２の複数のノードからの前記選択されたＨＰＣノードを前記仮想ノード・クラスタに付加して前記選択されたＨＰＣジョブの前記寸法を満たす工程とを備えることを特徴とする方法。
　　【請求項７】
　請求項６記載の方法であって，
　前記選択されたＨＰＣノードを前記第２の複数のノードに戻す工程を更に備えることを特徴とする方法。
　　【請求項８】
　請求項１記載の方法であって，
　前記仮想ノード・クラスタの外部の複数のＨＰＣノードに対して実行されていた第２ＨＰＣジョブに障害が起こった旨を判定する工程と，
　前記仮想ノード・クラスタの外部の前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加する工程と，
　前記障害が起こった第２ＨＰＣジョブを前記ソートされたジョブ・キューに追加する工程とを更に備えることを特徴とする方法。
　　【請求項９】
　ＨＰＣ環境においてジョブを管理するシステムであって，
　実行する対象のＨＰＣジョブをソートされたジョブ・キューから選択する手段と，
　前記ＨＰＣジョブに基づいた所定のポリシーによって複数のＨＰＣノードから仮想クラスタを判定する手段であって，前記ＨＰＣノードそれぞれが統合ファブリックを備え，前記複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する手段と，
　前記仮想ノード・クラスタの少なくとも一部分を用いて，前記選択されたＨＰＣジョブを実行する手段とを備えることを特徴とするシステム。
　　【請求項１０】
　請求項９記載のシステムであって，
　前記ＨＰＣジョブを選択する手段は，前記ＨＰＣジョブを前記ソートされたジョブ・キューから優先度に基づいて選択する手段を含み，前記選択されたＨＰＣジョブは，前記仮想ノード・クラスタのトポロジ以下の寸法を備えることを特徴とするシステム。
　　【請求項１１】
　請求項１０記載のシステムであって：
　前記ＨＰＣジョブを前記ソートされたジョブ・キューから優先度に基づいて選択する手段は，
　ジョブ・キューをジョブ優先度に基づいてソートする手段と，
　第１ＨＰＣジョブを該ソートされたジョブ・キューから選択する手段と，
　前記仮想ノード・クラスタの前記トポロジによって前記第１ＨＰＣジョブの寸法を判定し，前記第１ＨＰＣジョブの前記寸法が前記仮想ノード・クラスタの前記トポロジよりも大きい場合に応じて，第２ＨＰＣジョブを前記ソートされたジョブ・キューから選択し，前記仮想ノード・クラスタの再構成を待って，前記第１のＨＰＣジョブを前記ソートされたジョブ・キューに戻す手段とを含むことを特徴とするシステム。
　　【請求項１２】
　請求項１１記載のシステムであって，前記第１ＨＰＣジョブの前記寸法が：
　１つ又は複数のジョブ・パラメータと，関連ポリシーとに基づくことを特徴とするシステム。
　　【請求項１３】
　請求項１０記載のシステムであって，
　前記選択されたＨＰＣジョブの前記寸法に基づいて前記仮想ノード・クラスタからジョブ空間を動的に割り当てる手段を更に備え，
　前記選択されたＨＰＣジョブを実行する手段は，前記動的に割り当てられたジョブ空間を用いて前記選択されたＨＰＣジョブを実行する手段を含むことを特徴とするシステム。
　　【請求項１４】
　請求項９記載のシステムであって，
　前記複数のＨＰＣノードは第１の複数のノード及び第２の複数のノードを含み，前記第１の複数のノードは前記仮想ノード・クラスタと関連付けられ，
　前記選択されたＨＰＣジョブの寸法が前記第１の複数のノードのトポロジよりも大きい旨を判定する手段と，
　１つ又は複数のＨＰＣノードを前記第２の複数のノードから選択する手段と，
　前記第２の複数のノードからの前記選択されたＨＰＣノードを前記仮想ノード・クラスタに付加して，前記選択されたＨＰＣジョブの前記寸法を満たす手段とを更に備えることを特徴とするシステム。
　　【請求項１５】
　請求項１４記載のシステムであって，
　前記選択されたＨＰＣノードを前記第２の複数のノードに戻す手段を更に備えることを特徴とするシステム。
　　【請求項１６】
　請求項９記載のシステムであって，
　前記仮想ノード・クラスタの外部の複数のＨＰＣノードに対して実行していた第２ＨＰＣジョブに障害が起こった旨を判定する手段と，
　前記仮想ノード・クラスタの外部の前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加する手段と，
　前記障害が起こった第２のＨＰＣノードを，前記ソートされたジョブ・キューに追加する手段とを更に備えることを特徴とするシステム。
　　【請求項１７】
　ＨＰＣ環境においてジョブを管理するシステムであって，
　統合ファブリックをノードそれぞれが含む複数のＨＰＣノードであって，エッジレス・トポロジを備えた３次元グリッドを形成するＨＰＣノードと，
　管理ノードであって，
　実行する対象のＨＰＣジョブを，ソートされたジョブ・キューから選択し，
　前記選択されたＨＰＣジョブに基づいて所定のポリシーによって前記複数のＨＰＣノードから仮想ノード・クラスタを判定し，
　前記仮想ノード・クラスタの少なくとも一部分を用いて，前記選択されたＨＰＣジョブを実行するよう機能する管理ノードとを備えることを特徴とするシステム。
　　【請求項１８】
　請求項１７記載のシステムであって，前記管理ノードは，優先度に基づいて，前記ソートされたジョブ・キューから前記ＨＰＣジョブを選択することによって前記ＨＰＣジョブを選択し，前記選択されたＨＰＣジョブは，前記仮想ノード・クラスタのトポロジ以下の寸法を備
えることを特徴とするシステム。
　　【請求項１９】
　請求項１８記載のシステムであって，
　ジョブ優先度に基づいてジョブ・キューをソートし，
　第１のＨＰＣジョブを前記ソートされたジョブ・キューから選択し，
　前記第１のＨＰＣジョブを前記仮想ノード・クラスタの前記トポロジによって判定し，　前記第１のＨＰＣジョブの前記寸法を前記仮想ノード・クラスタの前記トポロジによって判定し，
　前記第１のＨＰＣジョブの前記寸法が前記仮想ノード・クラスタの前記トポロジよりも大きいことに応じて，第２のＨＰＣジョブを前記ソートされたジョブ・キューから選択し，前記仮想ノード・クラスタの再構成を待って，前記第１のＨＰＣジョブを前記ソートされたジョブ・キューに戻すことによって，
　前記管理ノードは，前記ＨＰＣジョブを前記ソートされたジョブ・キューから優先度に基づいて選択することを特徴とするシステム。
　　【請求項２０】
　請求項１９記載のシステムであって，前記第１ＨＰＣジョブの前記寸法が：
　１つ又は複数のジョブ・パラメータと，関連ポリシーとに基づくことを特徴とするシステム。
　　【請求項２１】
　請求項１８記載のシステムであって，前記管理ノードは，
　前記ＨＰＣジョブの前記寸法に基づいて前記仮想ノード・クラスタからジョブ空間を動的に割り当て，
　前記動的に割り当てられるジョブ空間を用いて前記選択されたＨＰＣジョブを実行することによって，前記選択されたＨＰＣジョブを実行することを特徴とするシステム。
　　【請求項２２】
　請求項１７記載のシステムであって，
　前記複数のＨＰＣノードが，第１の複数のノード及び第２の複数のノードを備え，前記第１の複数のノードが前記仮想ノード・クラスタと関連付けられ，
　前記管理ノードは，
　前記選択されたＨＰＣジョブの寸法が前記第１の複数のトポロジよりも大きい旨を判定し，
　１つ又は複数のＨＰＣノードを前記第２の複数のノードから選択し，
　前記第２の複数のノードからの前記選択されたＨＰＣノードを前記仮想ノード・クラスタに追加して，前記選択されたＨＰＣジョブの前記寸法を満たすよう機能することを特徴とするシステム。
　　【請求項２３】
　請求項２２記載のシステムであって，前記管理ノードが，
　前記選択されたＨＰＣノードを前記第２の複数のノードに戻すことを特徴とするシステム。
　　【請求項２４】
　請求項１７記載のシステムであって，更に前記管理ノードが：
　前記仮想ノード・クラスタの外部にある複数のＨＰＣノードに対して実行されていた第２のＨＰＣジョブに障害が起きた旨を判定し，
　前記仮想ノード・クラスタの外部にある前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加し，
　前記障害が起きた第２のＨＰＣジョブを，前記ソートされたジョブ・キューに追加するよう機能することを特徴とするシステム。
　　【請求項２５】
　請求項１７記載のシステムであって，前記管理ノードは：
　第２のＨＰＣジョブを前記ソートされたジョブ・キューから選択し，
　前記第２のＨＰＣジョブの最適な形状を判定し，
　前記第２のＨＰＣジョブを実行するために十分な数の利用可能なノードを前記仮想クラスタが有しているか否かを前記第２のＨＰＣジョブの前記最適な形状によって判定することを特徴とするシステム。
　　【請求項２６】
　請求項２５記載のシステムであって，前記管理ノードは：
　前記第２のＨＰＣジョブを実行する対象のノードを，前記十分な数の利用可能なノードから割り当てることを特徴とするシステム。
　　【請求項２７】
　請求項２６記載のシステムであって，前記管理ノードは：
　前記割り当てに応じて，前記仮想ノード・クラスタにおける利用可能なノードの数を再計算する
ことを特徴とするシステム。
　　【請求項２８】
　請求項２６記載のシステムであって，前記管理ノードが，
　前記第２のＨＰＣジョブを前記割り当てられたノードに対して実行することを特徴とするシステム。
　　【請求項２９】
　請求項２５記載のシステムであって，前記管理ノードは，
　前記第２のＨＰＣジョブを実行するために利用可能なノードを十分な数，前記仮想クラスタが有していないことに応答して，第３のＨＰＣジョブを前記ソートされたジョブ・キューから選択し，
　前記第３のＨＰＣジョブの最適な形状を判定し，
　前記第３のＨＰＣジョブの前記最適な形状によって前記第３のＨＰＣジョブを実行するために十分な利用可能なノードを前記仮想ノード・クラスタが有するか否かを判定することを特徴とするシステム。」
　
第３．当審拒絶理由
　当審による平成２３年８月２６日付けの拒絶理由（以下，これを「当審拒絶理由」という）は，概略以下のとおりである。
　
「第３．拒絶の理由  
 【理由】この出願は，特許請求の範囲の記載が，下記の点で特許法第３６条第６項第１号及び第２号に規定する要件を満たしていない。 
 　 
 　 　 　　　　　　　　　　　　記  
 　 
 （１）請求項１について 
 （１−１）請求項１記載の「選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程」について，単に達成したい機能の願望が記載されているに過ぎず，「所定のポリシー」とは，具体的にどのような内容を含むポリシーであるのか不明であり，さらに，管理プロセッサは，選択されたＨＰＣジョブに関するどのような情報に基づいて，前記所定のポリシーのどのような情報をどのように利用して，複数のＨＰＣノードから具体的にどのような仮想ノード・クラスタの何を，「選択されたＨＰＣジョブ」とのどのような関係を，どのように判定するのか，不明であり，発明が明確でない。 
 　さらに，前記「判定」対象となる「仮想ノード・クラスタ」は，いつ，どのようにして作成されるのか，不明であり，発明が明確でない。 
 　 
 （１−２）請求項１記載の「選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程であって，前記ＨＰＣノードそれぞれが統合ファブリックを備え，前記複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する工程」において，「選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程」と「前記ＨＰＣノードそれぞれが統合ファブリックを備え，前記複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する工程」との論理的関係及び順序関係が不明であり，発明が明確でない。 
 　 
 （１−３）＜省略＞ 
 　 
 （１−４）＜省略＞
　
（２）請求項２について 
 （２−１）請求項２記載の「前記ＨＰＣジョブを選択する工程が： 
 　前記ＨＰＣジョブを前記ジョブ・キューから優先度に基づいて選択する工程を備え， 
 　前記選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備える前記選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備える」からすると，「前記選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備える」ためには，前記ＨＰＣジョブを選択する工程の前に，前記仮想ノード・クラスタが判定されていなければならないと解される。 
 　しかしながら，請求項１の記載によると，「ＨＰＣジョブを選択する工程」の後に，「前記選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程」が続いていると解される。 
 　よって，請求項１記載の発明と請求項２記載の発明とは，その構成において矛盾するものであり，この点で，請求項２記載の発明は，不明であり，発明が明確でない。 
 　 
 （２−２）さらに，「選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備える」における，「仮想ノード・クラスタのトポロジ以下の寸法」とは，具体的に，「選択されたＨＰＣジョブ」に関するどのような情報を意味するのか，不明であり，発明が明確でない。 
 　また，「選択されたＨＰＣジョブが，前記仮想ノード・クラスタのトポロジ以下の寸法を備える」とは，単に願望を記載したに過ぎず，具体的に，どのような構成でどのようにして，選択されたＨＰＣジョブは，前記仮想ノード・クラスタのトポロジ以下の寸法であるようにされるのか，不明であり，発明が明確でない。 
　
（３）請求項３について 
 （３−１）請求項３記載の「前記ＨＰＣジョブを前記ソートされたジョブ・キューから優先度に基づいて選択する工程が， 
 　… 
 　第１ＨＰＣジョブを前記ソートされたジョブ・キューから選択する工程と， 
 　前記仮想ノード・クラスタの前記トポロジによって前記第１ＨＰＣジョブの寸法を判定する工程」を含むことからすると，「前記選択された第１ＨＰＣジョブの寸法が，前記仮想ノード・クラスタの前記トポロジによって判定するためには，前記第１ＨＰＣジョブを選択する工程の前に，前記仮想ノード・クラスタが判定（または選択）されていなければならないと解される。 
 　しかしながら，請求項１の記載によると，「ＨＰＣジョブを選択する工程」の後に，「前記選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを前記管理プロセッサによって判定する工程」が続いていると解される。 
 　よって，請求項１記載の発明と請求項３記載の発明とは，その構成において矛盾するものであり，この点で，請求項３記載の発明は，不明であり，発明が明確でない。 
 　 
 （３−２）さらに，「前記仮想ノード・クラスタの前記トポロジによって前記第１ＨＰＣジョブの寸法を判定する」における，「第１ＨＰＣジョブの寸法」とは，具体的に，「選択された第１ＨＰＣジョブ」に関するどのような情報を意味するのか，不明であり，発明が明確でない。 
 　また，「前記仮想ノード・クラスタの前記トポロジによって前記第１ＨＰＣジョブの寸法を判定する」とは，単に願望を記載したに過ぎず，具体的に，前記仮想ノード・クラスタの前記トポロジのどのような情報によって，どのような構成でどのようにして，選択された第１ＨＰＣジョブの寸法を判定するのか，不明であり，発明が明確でない。 
　
（４）請求項４について 
 　請求項４記載の「第１ＨＰＣジョブの前記寸法が： 
 　１つ又は複数のジョブ・パラメータと，関連ポリシーとに基づく」について，「関連ポリシー」とは具体的にどのようなポリシーを意味するのか，不明であるとともに，「第１ＨＰＣジョブの前記寸法」に係る情報とジョブ・パラメータと，関連ポリシーとの情報との関係が不明であり，発明が明確でない。 
　
（５）請求項８について 
 　請求項８記載の「仮想ノード・クラスタの外部の複数のＨＰＣノードに対して実行されていた第２ＨＰＣジョブに障害が起こった旨を判定する工程と， 
 　前記仮想ノード・クラスタの外部の前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加する工程」からすると，請求項８記載の発明は，障害が発生した外部の複数のＨＰＣノードを仮想ノード・クラスタに追加する態様を含む。 
 　しかし，そのような態様は，発明の詳細な説明に記載したものでない。 
 　よって，この点で，請求項８記載の発明は，発明の詳細な説明に記載したものでない。
 　 
 （６）請求項９〜請求項１２及び請求項１６について 
 　請求項９〜請求項１２及び請求項１６記載の発明は，請求項１〜請求項４及び請求項８記載の発明をシステムの観点で記載したものであり，「（１）請求項１について」〜「（４）請求項４について」及び「（５）請求項８について」で指摘した同様の事項が，それぞれ，請求項９〜請求項１２及び請求項１６に適用される。 
　
（７）請求項１７〜請求項２０及び請求項２４について 
 　請求項１７〜請求項２０及び請求項２４記載の「管理ノード」は，請求項９〜請求項１２及び請求項１６記載の各「手段」に相当するものであり，実質的に同じ内容を有している。 
 　よって，「（６）請求項９〜請求項１２及び請求項１６について」で指摘した同様の事項が，それぞれ，請求項１７〜請求項２０及び請求項２４に適用される。 
　
（８）請求項２５について 
 　請求項２５記載の「前記第２のＨＰＣジョブの最適な形状を判定し，」における，「第２のＨＰＣジョブの最適な形状」とは，具体的に，「選択された第２ＨＰＣジョブ」に関するどのような情報を意味するのか，不明であり，発明が明確でない。 
 　また，「前記第２のＨＰＣジョブを実行するために十分な数の利用可能なノードを前記仮想クラスタが有しているか否かを前記第２のＨＰＣジョブの前記最適な形状によって判定する」について，「十分な数の利用可能なノード」有しているか否かを前記「最適な形状」のどのような情報によって判定するのか，不明であり，発明が明確でない。 
 　 
 （９）＜省略＞  
 　 
 （１０）請求項２９について 
 　請求項２９記載の「前記第３のＨＰＣジョブの最適な形状を判定し，」における，「第３のＨＰＣジョブの最適な形状」とは，具体的に，「選択された第３ＨＰＣジョブ」に関するどのような情報を意味するのか，不明であり，発明が明確でない。 
 　また，「前記第３のＨＰＣジョブを実行するために十分な数の利用可能なノードを前記仮想クラスタが有しているか否かを前記第２のＨＰＣジョブの前記最適な形状によって判定する」について，「十分な数の利用可能なノード」有しているか否かを前記「最適な形状」のどのような情報によって判定するのか，不明であり，発明が明確でない。」
　
第４．当審の判断
１．“（１）請求項１について”の（１−１），及び，（１−２） に関して
　本件手続補正における補正内容において，請求項１については，平成２０年１月２３日付けの手続補正（以下，「原審拒絶理由応答時補正」という）により補正された請求項１に記載の内容から変更はない。
　ここで，原審拒絶理由応答時補正により補正された請求項１に係る発明は，当審拒絶理由における“（１）請求項１について”の（１−１）〜（１−４）に指摘の事項を根拠として，「明確でない」とされたものである。
　よって，本件手続補正によって，補正された請求項１に係る発明が，原審拒絶理由応答時補正により補正された請求項１に係る発明と同一のものである以上，当審拒絶理由において，請求項１に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，審判請求人（以下，「請求人」という）は，平成２４年２月２９日付けの意見書（以下，「意見書」という）において，
（１）当審拒絶理由の“（１）請求項１について”の（１−１）に対して，
「例えば本願明細書段落００２１及び００２２等に記載の通り，「所定のポリシー」には，考えられる障害についてノードを監視することが含まれ，管理プロセッサは，少なくとも部分的に，ジョブ，ユーザ又はユーザ群に関連した所定のポリシー，並びに，投入ジョブ・パラメータ及び関連パラメータに基づいて，適切な仮想ノード・クラスタを判定します。
　仮想ノード・クラスタは，例えば本願明細書段落００２５等に記載の通り，変動するリクエスト，デマンド，及び状況に，例えば，含まれるノードの障害に応じて動的に作成されます」と主張しているが，
　本願明細書の段落【００２１】には，「次に，クラスタ管理エンジン１３０は，グリッド１１０の種々の部分を１又は複数の仮想クラスタ２２０に，
例えば，所定のポリシーに基づいて動的に割り当てる
　「一実施例では，クラスタ管理エンジン１３０は，考えられる障害についてノード１１５を継続して監視し，ノード１１５のうちの１つに障害が起こったということを判定すると，種々の回復手法のうちの何れかを用いて障害を効果的に管理する」，
　という記載があるが，該記載中には，一切，ポリシーの関連は述べられておらず，該記載の内容は単に，“クラスタ管理エンジンの障害対策”に関するものであるに過ぎない。
　更に，「ポリシー」に関連する記載として，同段落【００２１】に，
「クラスタ管理エンジン１３０は，
関連ポリシーによって，かつ優先度などのクラスタ間ポリシーによってノードを仮想クラスタ２２０から動的に加算する
　という記載，及び，本願明細書の段落【００２２】に，
「クラスタ管理エンジン１３０は
ジョブ投入，関連パラメータ，及び，ジョブ１５０，ユーザ又はユーザ群と関連した何れかの所定のポリシーを処理する
　という記載が存在するが，これらの記載を加味しても，本願の請求項１に記載の「所定のポリシー」はどのようなものであるか，不明である。
　また，上記引用の記載の他，本願明細書の発明の詳細な説明において，「ＨＰＣジョブ」と，「ポリシー」との関連を示す記載としては，本願明細書の段落【０００９】に，「ＨＰＣジョブ１５０」との記載があることから，「ジョブ１５０」は全て「ＨＰＣジョブ」であるとすると，本願明細書の段落【００２６】に，
「実行ジョブ１５０毎に１つのジョブ空間２３０が存在し，逆もあてはまるが，本願の開示の範囲を逸脱することなく，ジョブ空間２３０はノード２１５を共有し得る。ジョブ空間２３０の寸法は，ユーザ又は管理者によって，手作業で入力してもよく，ジョブ・パラメータ，ポリシー，及び／又は何れかの別の適切な特性に基づいて動的に判定してもよい」，
　同段落【００４６】に，
「スケジューラ５１５は，
ジョブ１５０によって提示される種々の課題の選択と実行とに関するポリシー５０２を実施する方法
　同段落【００５２】に，
「ポリシー・テーブル５２４は１つ又は複数のポリシーを含む。ポリシー・テーブル５２４とポリシー５２４を適宜，同義に用い得るということが分かるものである。
ポリシー５２４は一般的に，ジョブ１５０及び／又は仮想クラスタ２２０に関する処理情報及び管理情報を記憶している。例えば，ポリシー５２４は，問題サイズ，問題実行時間，時間スロット，横取り，ノード１１５又は仮想クラスタ２２０のユーザ割り当て率などを含む何れかの数のパラメータ又は変数を含み得る
　同段落【００６１】に，
「
クラスタ管理エンジン５００は，ジョブ１５０のパラメータ又はポリシー５２４のパラメータとして記憶される配置重みを利用し得る
配置重みは，大規模のジョブ１５０の枯渇を妨げてＨＲＣシステム１００のジョブ・スループットを確保するために，資源予約などの管理ポリシー５２４をオーバライドするものでない
　同段落【００６３】に，
「バッチ・ジョブ投入を受信し，ジョブ・パラメータと，関連ポリシー５２４との基づいてノード１１５をジョブ空間２３０に動的に割り当て，割り当て空間を用いてジョブ１５０を実行する方法６００を表す」，
　同段落【００６４】に，
「次に，工程６２５で，クラスタ管理エンジン１３０は，ジョブ１３０（当審注；「ジョブ１５０」の誤記である）の投入に基づいてポリシー５２４を取り出す。一実施例では，クラスタ管理エンジン１３０は，ユーザ，ジョブ１５０，又は何れかの別の適切な基準に関連した適切なポリシー５２４を判定し得る。クラスタ管理エンジン１３０は更に，工程６３０で，ジョブ１５０の寸法を判定するか別の方法で計算する。適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性を含み得るということは分かるものである」，
　同段落【００６５】に，
「クラスタ管理エンジン１３０は，工程６５０で，利用可能なノード１１５から最適な部分集合２３０を動的に判定する。最適な部分集合２３０は，最高速処理時間，最高の信頼度のノード１１５，物理位置若しくは仮想位置，又は最初に利用可能なノード１１５を含む何れかの適切な基準を用いて判定し得るということが分かるものである。・・・次に，工程６６０で，クラスタ管理エンジン１３０は，選択部分集合２３０を用いてジョブ１５０に選択ノード１１５を割り当てる。一実施例によれば，クラスタ管理エンジン１３０は，仮想ノード・リスト５２２におけるノード１１５の状態を「非割り当て」から「割り当て」に変更し得る。部分集合２３０が適切に割り当てられると，
クラスタ管理エンジン１３０は工程６６５で，ジョブ・パラメータ，取り出したポリシー５２４，及び何れかの別の適切なパラメータに基づいて割り当て空間を用いてジョブ１５０を実行する
　同段落【００７１】に，
「工程８３５では，クラスタ管理エンジン１３０は，ポリシー５２４と，工程８２５での強制終了ジョブ１５０のパラメータとを取り出す。クラスタ管理エンジン１３０は更に，工程８４０で，取り出したポリシー５２４及びジョブ・パラメータに基づいて，仮想クラスタ２２０におけるノード１１５の最適部分集合２３０を判定する」，
　という記載が存在し，特に，段落【００５２】から引用した記載中には，「ポリシー５２４」が含み得る「パラメータ」，又は，「変数」について言及されているが，
　これら引用の記載を総合勘案しても，本願の請求項１に係る発明における「管理プロセッサ」が，「ＨＰＣジョブ」の“何”に基づいて，「所定のポリシー」に含まれる“どのような情報”をどのように用いることで，「複数のＨＰＣノード」から「仮想ノード・クラスタ」の“何”を判定しているのか，依然として不明である。
（２）請求人は，また，当審拒絶理由の“（１）請求項１について”の（１−２）に対して，
「「判定する工程」には，「前記ＨＰＣノードそれぞれが統合ファブリックを備える」という構成，及び，「前記複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する」という構成が含まれます」と主張しているが，
　本願の請求項１に記載の内容からは，
“選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードがら仮想ノード・クラスタを管理プロセッサと判定する工程”と，
“ＨＰＣノードそれぞれがファブリックを備え，複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する工程”との関係は読み取れず，
　この点に関して，本願明細書を参照しても，本願明細書の段落【００１０】〜【００１２】，【００２１】，【００２３】，【００２４】，【００２７】，【００２８】，【００３４】，【００３８】〜【００４１】，【００４６】，【００５３】，【００５９】，【００６６】，【００６７】，【００６９】に，「グリッド」に関連する記載が存在するが，これらの記載内容を総合勘案しても，本願の請求項１に係る発明における，“選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードがら仮想ノード・クラスタを管理プロセッサと判定する工程”が，“ＨＰＣノードそれぞれがファブリックを備える”という構成と，“複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する”構成を含むことが読み取れるものではなく，本願の請求項１に係る発明における，“選択されたＨＰＣジョブに基づいて所定のポリシーによって複数のＨＰＣノードから仮想ノード・クラスタを管理プロセッサと判定する工程”と，“ＨＰＣノードそれぞれがファブリックを備え，複数のＨＰＣノードが，エッジレス・トポロジを備えた３次元グリッドを形成する工程”との関係は，依然として不明である。
　以上のとおりであるから，請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項１に係る発明は，依然として，明確でない。
　
２．“（２）請求項２について”の（２−１），及び，（２−２） に関して
　本件手続補正により，本願の請求項２に記載の内容は，原審拒絶理由応答時補正により補正された請求項２に記載の内容と同一の内容に補正された。
　したがって，本願の請求項２に係る発明は，当審拒絶理由における“（２）請求項２について”の（２−１），及び，（２−２）に指摘の事項を根拠として，「明確でない」とされたものと同じ発明であるから，当審拒絶理由において，請求項２に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，請求人は，意見書において，
（１）当審拒絶理由の“（２）請求項２について”の（２−１）に対して，
「（例えば，図７の工程７２０に対応する）ジョブの寸法の判定は，（例えば，図７の工程７３０に対応する）仮想ノード・クラスタの判定に先行します」と主張しているが，
　本願の【図７】には，「７１０　仮想クラスタにおける利用可能ノード数を判定する」，「７２０　選択ジョブの最適形状を動的に判定する」と記載されており，更に，本願の【図６】には，明確に，「６２０　グループに基づいて仮想クラスタを選択する」，「６３０　ジョブの寸法を判定する」と記載されている。本願の請求項２に係る発明が，上記引用の記載を根拠にするものであるとすると，本願の請求項２が引用する，本願の請求項１に係る発明と，その構成において矛盾することは明らかである。
（２）また，請求人は，“（２）請求項２について”の（２−２）に対して，
「ジョブの寸法には，例えば本願明細書段落００６４等に記載の通り，長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性が含まれます」と主張している。
　確かに，上記でも引用したように，本願明細書の段落【００６４】には，
「工程６３０で，ジョブ１５０の寸法を判定するか別の方法で計算する。適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性を含み得るということは分かるものである」，
　と記載され，該「寸法」に関しては，上記引用記載の他，本願明細書中に，上記で引用した同段落【００２６】の記載，同段落【００６４】の，
「これらの寸法は仮想クラスタ２２０内の適切なジョブ空間２３０（又はノード１１５の部分集合）を判定するのに用いられる」，
　という記載，同段落【００６７】の，
「７２０で，クラスタ管理エンジン１３０は，選択ジョブ１５０の最適な形状（又は別の寸法）を動的に判定する」，
　という記載が存在している。
　しかしながら，本願の請求項２における「ジョブ」とは，物理的に実測可能な形状を有するものでないことは，当業者にとって自明の事項であり，そのような，一種の仮想な存在である「ジョブ」の「寸法」の「長さ」，「幅」，「高さ」といったものが，上記引用の記載からも明らかなように，本願明細書中に何ら定義されておらず，該「ジョブの寸法」なるものが，どのようなものを表現したものであるか，当業者に周知の事項でもない以上，単に，「ジョブの寸法」として，本願明細書の発明の詳細な説明に記載された，「適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性」という説明を根拠としただけでは，当審拒絶理由の，“（２）請求項２について”の（２−２）において指摘した不明である点は解消しない。
　以上のとおりであるから，請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項２に係る発明は，依然として，明確でない。
　
３．“（３）請求項３について”の（３−１），及び，（３−２） に関して
　本件手続補正により，本願の請求項３に記載の内容は，原審拒絶理由応答時補正により補正された請求項３に記載の内容と同一の内容に補正された。
　したがって，本願の請求項３に係る発明は，当審拒絶理由における“（３）請求項３について”の（３−１），及び，（３−２）に指摘の事項を根拠として，「明確でない」とされたものと同じ発明であるから，当審拒絶理由において，請求項３に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，請求人は，意見書において，
（１）当審拒絶理由の“（３）請求項３について”の（３−１）に対して，
「（例えば，図７の工程７２０に対応する）ジョブの寸法の判定は，（例えば，図７の工程７３０に対応する）仮想ノード・クラスタの判定に先行します」と主張しているが，この点に関しては，上記２．の（１）で指摘したとおりである。
（２）また，請求人は，“（３）請求項３について”の（３−２）に対して，
「ジョブの寸法には，例えば本願明細書段落００６４等に記載の通り，長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性が含まれます」と主張しているが，この点に関しては，上記２．の（２）で指摘したとおりである。
　以上のとおりであるから，請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項３に係る発明は，依然として，明確でない。
　
４．“（４）請求項４について”に関して
　本件手続補正により，本願の請求項４に記載の内容は，原審拒絶理由応答時補正により補正された請求項４に記載の内容と同一の内容に補正された。
　したがって，本願の請求項４に係る発明は，当審拒絶理由における“（４）請求項４について”に指摘の事項を根拠として，「明確でない」とされたものと同じ発明であるから，当審拒絶理由において，請求項４に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，請求人は，意見書において，
（１）当審拒絶理由の“（４）請求項４について”に対して，
「「関連ポリシー」には，例えば本願明細書段落００５１等に記載の通り，必要性，時間が含まれます。ジョブの寸法，ジョブ・パラメータ，及び関連ポリシーにより，各グループが，資源をめぐって競合することなく個々の処理空間を有することが可能になります」と主張しているが，本願明細書の段落【００５１】には，「関連ポリシー」に関する記載はない。しかしながら，同段落【００５２】に上記に引用したように，
「例えば，ポリシー５２４は，問題サイズ，問題実行時間，時間スロット，横取り，ノード１１５又は仮想クラスタ２２０のユーザ割り当て率などを含む何れかの数のパラメータ又は変数を含み得る」，
　という記載が存在し，“ジョブの寸法”に関しては，上記で引用した，同段落【００６４】の，
「ジョブ１５０の寸法を判定するか別の方法で計算する。適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性を含み得る」，
　という記載が存在しているが，「関連ポリシー」と，“ジョブの寸法”との関係については，上記で引用した同段落【００２６】に，
「ジョブ空間２３０の寸法は，ユーザ又は管理者によって，手作業で入力してもよく，ジョブ・パラメータ，ポリシー，及び／又は何れかの別の適切な特性に基づいて動的に判定してもよい」，
　という記載が，同じく，上記で引用した同段落【００６４】に，
「一実施例では，クラスタ管理エンジン１３０は，ユーザ，ジョブ１５０，又は何れかの別の適切な基準に関連した適切なポリシー５２４を判定し得る。クラスタ管理エンジン１３０は更に，工程６３０で，ジョブ１５０の寸法を判定するか別の方法で計算する。適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性を含み得るということは分かるものである」，
　という記載が存在するが，段落【００２６】に記載の内容からは，「ジョブ空間」が，「ジョブ・パラメータ」，「ポリシー」，或いは，「何れかの別の適切な特性に基づいて動的に判定」されることが読み取れるが，該「ジョブ空間」は，同【００２６】に，
「一般的には，ジョブ空間２３０は，受信ジョブ１５０を完了するよう動的に割り当てられる仮想クラスタ２２０内のノード２１５の群である。通常実行ジョブ１５０毎に１つの受部空間が存在」するという記載から，明らかなように，「ジョブ空間」と，「ジョブ」とは別のものであり，仮に，「ジョブ空間」が，前記したように，「ジョブ・パラメータ」，「ポリシー」に「基づいて動的に判定」されるとしても，「ジョブ」が，「複数のジョブ・パラメータ」と，「関連ポリシー」に基づくものであることを示唆するものでないことは明らかである。
　また，上記引用の同段落【００６４】の記載からは，「適切なポリシーの判定を行うこと」，及び，「ジョブの寸法を判定する」ことについては記載されているが，「適切なポリシーの判定」と「ジョブの寸法の判定」との関係は示されておらず，また，該「ジョブの寸法」は，「別の方法で計算する」とも記載されていて，このことから，同段落【００６４】の記載から，該「ジョブの寸法」は，「適切なポリシー」に関係なく計算で求められることも示されていることから，本願明細書の発明の詳細な説明の記載内容からは，「ジョブの寸法」が，「ポリシー」に基づくものであるか否かは特定できない。
　よって，請求人の主張，及び，本願明細書の発明の詳細な説明を総合勘案しても，「第１ＨＰＣジョブの前記最適な形状」と，「ジョブ・パラメータ」，「関連ポリシー」との関係は依然として不明である。
　以上のとおりであるから，請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項４に係る発明は，依然として，明確でない。
　
５．“（５）請求項８について”に関して
　本件手続補正により，本願の請求項８に記載の内容は，原審拒絶理由応答時補正により補正された請求項８に記載の内容と同一の内容に補正された。
　したがって，本願の請求項８に係る発明は，当審拒絶理由における“（５）請求項８について”に指摘の事項を根拠として，「発明の詳細な説明に記載したものでない」とされたものと同じ発明であるから，当審拒絶理由において，請求項８に対して指摘した拒絶理由が解消していないことは明らかである。
　即ち，本願の請求項８には，
「請求項１記載の方法であって，
　前記仮想ノード・クラスタの外部の複数のＨＰＣノードに対して実行されていた第２ＨＰＣジョブに障害が起こった旨を判定する工程と，
　前記仮想ノード・クラスタの外部の前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加する工程と，
　前記障害が起こった第２ＨＰＣジョブを前記ソートされたジョブ・キューに追加する工程とを更に備えることを特徴とする方法。」
　と記載されていて，この記載内容にしたがえば，
「仮想ノード・クラスタの外部の複数のＨＰＣノードに対して実行されていた第２ＨＰＣジョブに障害が起こった旨を判定する」という記載から，本願の請求項８に係る発明においては，「第２のジョブ」が実行されているのは，「仮想ノード・クラスタ」の外部にある「複数のＨＰＣノード」であり，該“仮想ノード・クラスタの外部のＨＰＣノード”で実行されている「第２のＨＰＣジョブ」に障害が発生したことを判定している。
　つまり，本願の請求項８に係る発明では，“仮想ノード・クラスタの外部のＨＰＣノード”で障害が発生していることになる。
　そして，「仮想ノード・クラスタの外部の前記複数のＨＰＣノードを前記仮想ノード・クラスタに追加する」ことから，本願の請求項８に係る発明においては，“障害の発生している外部の複数のＨＰＣノード”を“仮想ノード・クラスタ”に追加するものと解される。
　更に，「障害が起こった第２ＨＰＣジョブを前記ソートされたジョブ・キューに追加する」という記載から，“障害の起こった第２ＨＰＣジョブをソートされたジョブ・キューに追加する”ものと解される。
　一方，請求人が，意見書において，本願の請求項８の補正の根拠に挙げている，本願明細書の段落【００２５】に，
「例えば，仮想クラスタ２２０は，動的に変動させて，先行時点ではクラスタ２２０の部分であった第２ノード２１５の障害に応じて自動的に割り当てられる第１のノード２１５を含み得る。特定の実施例では，クラスタ２２０は，ノード２１５を処理の要求に応じて共有し得る」，
　と記載されていて，それに先行する本願明細書の段落【００２４】の，
「仮想クラスタ２２０は，何れかの形状であり得るものであり，グリッド２１０内に何れかの数のノード２１５を含み得る。実際に，図示する仮想クラスタ２２０が複数の物理的に隣接しているノード２１５を含んでいるが，クラスタ２２０は，ジョブ１５０を処理するよう動作可能な論理的に関連したノード２１５の分散クラスタであり得る」，
　という記載，及び，上記で引用した本願明細書の段落【００２５】の「例えば，仮想クラスタ２２０は・・・共有し得る」という記載に先行する同段落【００２５】の，
「例えば，変動する，サーバ１０２のニーズに基づいて動的に割り当ててもよい。更に，仮想クラスタ２２０は経時的にその形状とサイズを変えて，変動するリクエスト，デマンド，及び情報にすばやく対応し得る」，
　という記載から，本願明細書の発明の詳細な説明には，
“複数のノードを有する仮想クラスタは，グリッドに含まれ，該グリッドは，仮想クラスタに含まれるノードに加え，仮想クラスタの外部にもノードを有し，該仮想クラスタは，自クラスタ内でジョブを実行しているノードに障害が発生した場合に，該グリッドが有する，自クラスタの外部に存在するノードを取り込む”構成が記載されていることは読み取れる。
　しかしながら，上記の本願明細書の記載からは，
“障害の発生している，グリッドが有する仮想クラスタ外部のノードを，仮想クラスタに追加する”構成を読み取ることはできない。
　そして，本願明細書の他の記載，及び，図面を参照しても，
“障害の発生している，グリッドが有する仮想クラスタ外部のノードを，仮想クラスタに追加する”という構成は記載されておらず，本願明細書の記載内容から，そのような構成が示唆されているとも認められない。
　以上検討したとおりであるから,本願の請求項８に係る発明は，発明の詳細な説明に記載されたものではない。
　
６．“（６）請求項９〜請求項１２及び請求項１６について”に関して
　本件手続補正によって，補正前の請求項１０に記載の「仮想クラスタ」が，「仮想ノード・クラスタ」に補正されたが，
　実質的には，本件手続補正により，本願の請求項９〜請求項１２及び請求項１６に記載の内容は，原審拒絶理由応答時補正により補正された請求項９〜請求項１２及び請求項１６に記載の内容と同一の内容に補正された。
　したがって，本願の請求項９〜請求項１２及び請求項１６に係る発明は，当審拒絶理由における“（６）請求項９〜請求項１２及び請求項１６について”に指摘の事項を根拠として，本願の請求項９〜請求項１２に係る発明は，「明確でない」とされ，本願の請求項１６に係る発明は，「本願明細書の発明の詳細な説明に記載されたものではない」とされたものと同じ発明であるから，当審拒絶理由において，請求項９〜請求項１２及び請求項１６に対して指摘した拒絶理由が解消していないことは明らかである。
　これに対して，請求人は，意見書において，
「（６）（１）乃至（５）と同様です」と主張している。
　本願の請求項請求項９〜請求項１２及び請求項１６は，当審拒絶理由で指摘したとおり，「請求項１〜請求項４及び請求項８記載の発明をシステムの観点で記載したもの」であるから，上記第４の項目１〜５に指摘したとおり，意見書における請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項９〜請求項１２に係る発明は，依然として，明確でなく，本願の請求項１６に係る発明は，本願明細書の発明の詳細な説明に記載されたものではない。
　
７．“（７）請求項１７〜請求項２０及び請求項２４について”に関して
　本件手続補正によって，補正前の請求項１７〜請求項１９に記載の「仮想クラスタ」が，「仮想ノード・クラスタ」に補正されたが，
　実質的には，本件手続補正により，本願の請求項１７〜請求項２０及び請求項２４に記載の内容は，原審拒絶理由応答時補正により補正された請求項１７〜請求項２０及び請求項２４に記載の内容と同一の内容に補正された。
　したがって，本願の請求項１７〜請求項２０及び請求項２４に係る発明は，当審拒絶理由における“（７）請求項１７〜請求項２０及び請求項２４について”に指摘の事項を根拠として，本願の請求項１７〜請求項２０に係る発明は，「明確でない」とされ，本願の請求項２４に係る発明は，「本願明細書の発明の詳細な説明に記載されたものではない」とされたものと同じ発明であるから，当審拒絶理由において，請求項１７〜請求項２０及び請求項２４に対して指摘した拒絶理由が解消していないことは明らかである。
　これに対して，請求人は，意見書において，
「（７）（１）乃至（５）と同様です」と主張している。
　本願の請求項請求項１７〜請求項２０及び請求項２４は，当審拒絶理由で指摘したとおり，「請求項１７〜請求項２０及び請求項２４記載の「管理ノード」は，請求項９〜請求項１２及び請求項１６記載の各「手段」に相当するものであり，実質的に同じ内容を有している」から，上記第４の項目６に指摘したとおり，意見書における請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項１７〜請求項２０に係る発明は，依然として，明確でなく，本願の請求項２４に係る発明は，本願明細書の発明の詳細な説明に記載されたものではない。
　
８．“（８）請求項２５について”に関して
　本件手続補正により，本願の請求項２５に記載の内容は，原審拒絶理由応答時補正により補正された請求項２５に記載の内容と同一の内容に補正された。
　したがって，本願の請求項２５に係る発明は，当審拒絶理由における“（８）請求項２５について”に指摘の事項を根拠として，「明確でない」とされたものと同じ発明であるから，当審拒絶理由において，請求項２５に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，請求人は，意見書において，
「ジョブの最適な形状は，例えば本願明細書段落００６４等に記載の，長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性が含まれるジョブの最適な寸法を指します。例えば本願明細書段落００５６等に記載の通り，２ｘ２ｘ８のボックスは，垂直方向又は水平方向に，利用可能な物理ノード内に割り当てることができます」と主張しているが，
　「第２のＨＰＣジョブの最適な形状」の説明として，請求人が挙げている，上記で引用している,本願明細書の段落【００６４】には，
「ジョブ１５０の寸法を判定するか別の方法で計算する。適切な寸法の長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性を含み得るということは分かるものである」，
　という記載が存在するが，該記載内容からは，「第２のＨＰＣジョブの最適な形状」がどのようなものであるか，そして，それを，どのようにして判定しているか不明である。
　また，「十分な数の利用可能なノード」を有しているかを，“ジョブの最適な形状”から判定する点については，請求人が根拠に挙げている，本願明細書の段落【００５６】には，
「特定の，２次元（ｘ，ｙ）又は３次元（ｘ，ｙ，ｚ）。ノード１１５を割り当て，タスクを特定の次元で順序付けして，それによって，効率的な，近隣同士の通信を確保する場合がある。特定のトポロジは，物理的な通信トポロジが問題トポロジに一致して，ジョブ１５０の協調タスクが近隣のタスクと頻繁に通信することを可能にするということが望ましい種々のジョブ１５０を管理する。例えば，２ｘ２ｘ２次元（２，２，２）における８つのタスクの要求は立方体に割り当てられることになる。最善のフィットの目的では，２Ｄの割り当ては，効率的な近隣同士の通信を確保する一方で（図２Ｄに記載するように）３次元に「フォールディング」することが可能である。クラスタ管理エンジン５００は，特定の次元の形状を何れかの向きで自由に割り当てることができる場合がある。例えば，２ｘ２ｘ８のボックスは，垂直方向又は水平方向に，利用可能な物理ノード内に割り当て得る」，
　という記載が存在し，それに引き続く段落には，
「【００５７】
　最善のフィットの立方体。クラスタ管理エンジン５００は，Ｎのノード１１５を立方体の体積において割り当てる。このトポロジはジョブ１５０を効率的に処理し，それによって，協調タスクが，何れかの２つのノード１１５間での距離を最小にすることによって，何れかの別のタスクとデータを交換することを可能にする。
　【００５８】
　最善のフィットの球体。クラスタ管理エンジン５００は，Ｎのノード１１５を球体の体積において割り当てる。例えば，第１タスクが球体の中心ノード１１５に配置され，残りのタスクが中央ノード１１５を取り囲むノード１１５上に配置される場合がある。残りのタスクの配置順序は通常重要でないということが分かるものである。このトポロジは，第１タスクと全ての別のタスクとの間の距離を最小にする場合がある。このことは，タスク２乃至Ｎが第１タスクと通信するが，お互いには通信しない大規模の問題クラスを効率的に処理する。
　【００５９】
　任意。クラスタ管理エンジン５００がＮのノード１１５を割り当てるが，ノード１１５が論理的に位置特定されるか物理的に位置特定されることに対する考慮の度合いは低くなっている。一実施例では，このトポロジはバックフィル目的でのグリッド１１０の積極的な利用を奨励し，別のジョブ１５０への影響はわずかなものである」
　という記載が存在していて，上記引用の段落【００５６】〜【００５８】に記載されている内容からは，「ジョブ」を割り当てる“ノードによって構成される最適なクラスタの形状”を判定して，「ジョブ」を割り当てることが読み取れるが，“「十分な数の利用可能なノード」を有しているかを，“ジョブの最適な形状”から判定する”ことが記載されているとは認められない。
　ここで，本願明細書には，“「十分な数の利用可能なノード」を有しているかを，“ジョブの最適な形状”から判定する”に関連する記載として，
　本願明細書の段落【００６１】に，
「この例では，０の値は最適なストラテジ（又は次元）が考えられる場合のみノード１１５を配置させることを表し，１の値は，要求を処理するのに十分な，空き状態のノードが存在するか，別のかたちで利用可能なノード１１５が存在する限り，直ちにノードを配置させることを表す」，
　という記載，及び，同段落【００６５】に，
「判定工程６３５では，クラスタ管理エンジン１３０は，既に確立されているパラメータを用いて，所望のジョブ空間２３０を割り当てるのに十分利用可能なノードが存在しているかを判定する。ノード１１５が十分存在していない場合には，工程６４０で，クラスタ管理エンジン１３０が仮想クラスタ２２０におけるノード１１５の最も早く利用可能な部分集合２３０を判定する・・・利用可能なノード１１５が十分になると，クラスタ管理エンジン１３０は，工程６５０で，利用可能なノード１１５から最適な部分集合２３０を動的に判定する。最適な部分集合２３０は，最高処理時間，最高の信頼度のノード１１５，物理的位置若しくは仮想位置，又は最初に利用可能なノード１１５を含む何れかの適切な基準を用いて判定し得るということが分かるものである」，
　という記載が存在するが，上記引用の段落【００６１】に記載された事項からでは，「要求を処理するのに十分な，空き状態のノード１１５が存在するか」を，どのようにして判定しているか不明であり，よって，「空き状態のノード」と，「ジョブの形状」との関係についても何ら読み取ることはできない。また，同じく上記引用の段落【００６５】に，「既に確立されているパラメータを用いて，所定のジョブ空間２３０を割り当てるのに十分利用可能なノードが存在するか判定する」とあるが，「ジョブ空間」と，「ジョブの形状」との関係については，本願明細書中には記載されておらず，仮に，「ジョブ区間」が，「ジョブの形状」と関連するものであっても，「十分利用可能なノードが存在しているか」の判定は，「既に確立されているパラメータを用いて」行われるのであるから，このとき，「ジョブ空間」に関する何らかの情報が関連することを，上記引用の段落【００６５】の記載から読み取ることはできない。
　そして，上記に引用した以外の，本願明細書の記載内容を参酌しても，「第２のＨＰＣジョブの最適な形状」とは何か，及び，“「最適な形状」のどのような情報によって，「十分利用可能なノード」を有しているかを判定するか”という点が明確になるものではない。
　以上のとおりであるから，請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項２５に係る発明は，依然として，明確でない。
　
９．“（１０）請求項２９について”に関して
　本件手続補正によって，補正前の請求項２９に記載の「仮想クラスタ」が，「仮想ノード・クラスタ」に補正されたが，
　実質的には，本件手続補正により，本願の請求項２９に記載の内容は，原審拒絶理由応答時補正により補正された請求項２９に記載の内容と同一の内容に補正された。
　したがって，本願の請求項２９に係る発明は，当審拒絶理由における“（１０）請求項２９について”に指摘の事項を根拠として，「明確でない」とされたものと同じ発明であるから，当審拒絶理由において，請求項２９に対して指摘した拒絶理由が解消していないことは明らかである。
　この点に関して，請求人は，意見書において，
「ジョブの最適な寸法は，例えば本願明細書段落００６４等に記載の，長さ，幅，高さ，又は何れかの別の適切なパラメータ若しくは特性が含まれるジョブの最適な形状を指します。例えば本願明細書段落００５６等に記載の通り，２ｘ２ｘ８のボックスは，垂直方向又は水平方向に，利用可能な物理ノード内に割り当てることができます」，
　と，本願の請求項２５に対する拒絶理由に対する主張と同一の主張を展開しているが，この点に関しては，上記第４の項目８で指摘したとおりであるから,
　請求人の主張，及び，本願明細書の発明の詳細な説明に記載の内容を総合勘案しても，本願の請求項２９に係る発明は，依然として，明確でない。
　
　以上検討したとおり，平成２４年２月２９日付けの手続補正により補正された請求項１乃至請求項４，請求項９乃至請求項１２，請求項１７乃至請求項２０，及び，請求項２５，並びに，請求項２９に係る発明は，依然として,明確でなく，請求項８，及び，請求項１６，並びに，請求項２４に係る発明は，発明の詳細な説明に記載されたものではない。
　
第５．むすび
　したがって，本願は，特許法第３６条第６項第１号，及び，第２号に規定する要件を満たしていない。
　
　よって，結論のとおり審決する。