【事件の表示】
　特願２００９−　１０２５０「情報処理装置，情報システム，プログラム及びプログラムを実行する計算機の決定方法」拒絶査定不服審判事件〔平成２２年　８月　５日出願公開，特開２０１０−１７０２１４〕について，次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２１年１月２０日を出願日とする出願であって，平成２３年１２月６日付けで審査請求がなされ，平成２５年５月１５日付けで拒絶理由通知（同年５月２１日発送）がなされ，これに対して平成２５年７月２２日付けで意見書が提出されたが，同年９月１２日付けで拒絶査定（同年９月１７日謄本送達）がなされたものである。　
　これに対して，「原査定を取り消す，本願は特許をすべきものであるとの審決を求める。」との請求の趣旨で，平成２５年１２月１６日付けで審判請求がなされると共に同日付けで手続補正がなされ，平成２６年２月２１日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされた。　
　
第２　平成２５年１２月１６日付けの手続補正についての補正却下の決定　 
　
 ［補正却下の決定の結論］ 
　
　平成２５年１２月１６日付けの手続補正を却下する。
　
 ［理由］ 
　
 １．補正の内容
　
　平成２５年１２月１６日付けの手続補正（以下，「本件補正」という。）の内容は，平成２１年１月２０日付けの願書に最初に添付した特許請求の範囲の請求項１乃至９の記載
　
「【請求項１】
　所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイルにアクセス可能であり，
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたプログラムの中から選択したプログラムを実行可能な仕様を有する計算機を判別し，該計算機に，前記プログラムの実行を指示する判別手段を備えた情報処理装置。
【請求項２】
　前記各計算機から，各計算機のアドレスと，仕様情報とを取得して前記マップファイルに登録するマップ登録手段を備えた請求項１に記載の情報処理装置。
【請求項３】
　前記マップファイルが，前記所定の共有ファイル領域に保持されている請求項１又は２に記載の情報処理装置。
【請求項４】
　前記複数の計算機が，クラスタシステムを構成する計算ノードであり，クラスタシステムのフロントエンドノードとして機能する請求項１乃至３いずれか一に記載の情報処理装置。
【請求項５】
　プログラムを保持する共有ファイル領域にアクセス可能な複数の計算機と，請求項１乃至３いずれか一に記載の情報処理装置とを含む情報システム。
【請求項６】
　プログラムを保持する所定の共有ファイル領域にアクセス可能な複数の計算機と，請求項２に記載の情報処理装置とを含む情報システムであって，
　前記情報処理装置が２以上配置され，一の情報処理装置のマップ登録手段が故障した場合に，他の情報処理装置のマップ登録手段が前記マップファイルへの登録を行う情報システム。
【請求項７】
　複数の計算機がクラスタシステムを構成する計算ノードであり，
　前記情報処理装置が，クラスタシステムのフロントエンドノードとして機能する請求項５又は６に記載の情報システム。
【請求項８】
　所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイルにアクセス可能なコンピュータに実行させるプログラムであって，
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたプログラムの中から選択したプログラムを実行可能な仕様を有する計算機を判別し，該計算機に，前記プログラムの実行を指示する判別処理を前記コンピュータに実行させるプログラム。
【請求項９】
　所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイルを作成するステップと，
　前記マップファイルにアクセス可能なコンピュータが，前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたプログラムの中から選択したプログラムを実行可能な仕様を有する計算機を判別するステップと，を含むプログラムを実行する計算機の決定方法。」（以下，この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
　
を，
　
「【請求項１】
　所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持された
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
【請求項２】
　前記各計算機から，各計算機のアドレスと，仕様情報とを取得して前記マップファイルに登録するマップ登録手段を備えた請求項１に記載の情報処理装置。
【請求項３】
　前記マップファイルが，前記所定の共有ファイル領域に保持されている請求項１又は２に記載の情報処理装置。
【請求項４】
　前記複数の計算機が
，ク
【請求項５】
　
ロードモジュール
【請求項６】
　
ロードモジュール
　前記情報処理装置が２以上配置され，一の情報処理装置のマップ登録手段が故障した場合に，他の情報処理装置のマップ登録手段が前記マップファイルへの登録を行う情報システム。
【請求項７】
　複数の計算機がクラスタシステムを構成する計算ノードであり，
　前記情報処理装置が，クラスタシステムのフロントエンドノードとして機能する請求項５又は６に記載の情報システム。
【請求項８】
　所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持された
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
【請求項９】
　所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
　前記マップファイルにアクセス可能なコンピュータが，前記マップファイルを参照して，前記所定の共有ファイル領域に保持された
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
　
に補正するものである。
　
　そして，本件補正は，願書に最初に添付した明細書，特許請求の範囲又は図面に記載した事項の範囲内においてなされており，特許法第１７条の２第３項の規定に適合している。
　
　
２．目的要件
　
　本件補正が，特許法１７条の２第５項の規定を満たすものであるか否か，すなわち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。　
　
　本件補正は，補正前の請求項１に記載した発明を特定するために必要な事項である「所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイル」を「所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
　補正前の請求項５，６に，記載した発明を特定するために必要な事項である「プログラム」を「
ロードモジュール
　補正前の請求項８に記載した発明を特定するために必要な事項である「所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイル」を「所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
　補正前の請求項９に記載した発明を特定するために必要な事項である「所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイル」を「所定の共有ファイル領域にアクセス可能な複数の計算機
を含んで構成されるクラスタシステムの前記複数の計算機
ロードモジュール
ユーザによって選択されたロードモジュール
ロードモジュール
　また，本件補正によっても，補正前の請求項に記載された発明とその補正後の請求項に記載される発明の産業上の利用分野及び解決しようとする課題は同一であることは明らかである。
　
　したがって，本件補正は，特許法第１７条の２第５項第２号に掲げる特許請求の範囲の減縮を目的とするものに該当することから，特許法１７条の２第５項の規定を満たすものである。
　
　
３．独立特許要件
　
　以上のように，本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）は，補正前の請求項１に対して，限定的減縮を行ったものと認められる。そこで，本件補正発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）以下に検討する。
　
（１）本件補正発明
　
　本件補正発明は，上記平成２５年１２月１６日付け手続補正書により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。　
　
「所定の共有ファイル領域にアクセス可能な複数の計算機を含んで構成されるクラスタシステムの前記複数の計算機の仕様情報を記憶するマップファイルにアクセス可能であり，
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたロードモジュールの中からユーザによって選択されたロードモジュールを実行可能な仕様を有する計算機を判別し，該計算機に，前記ロードモジュールの実行を指示する判別手段を備えた情報処理装置。」　
　
　
（２）引用文献
　
　本願出願前に頒布され，原審の拒絶査定の理由である上記平成２５年５月１５日付けの拒絶理由通知において引用された，特開２００５−１０８２１４号公報（平成１７年４月２１日出願公開，以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「【００１８】
　
本発明は，分散コンピューティング・システムのプラグ可能スケジューリング・ポリシのフレームワークを提供する。膨大なさまざまな異なるジョブの要件に応じて，異なるプラグ可能スケジューリング・ポリシを，システム内に実施して，所与のシステム・リソースの最も効率的な使用を提供することができる。
【００１９】
　
本発明の好ましい実施形態によれば，処理リソースのグリッド内のある処理リソースへのジョブの割当が，スケジューラ・フレームワークによって処理される。スケジューリング・フレームワークは，さまざまな異なるスケジューリング・ポリシにアクセスできる。ジョブ要件および選択されたスケジューリング・ポリシに従って，スケジューリング・ポリシによって，実行のためにジョブが送られる単一のまたは複数の処理リソースが決定される。
【００２０】
　単一のデータ処理リソースは，そのシステム状況および構成に関する必要な情報をデータベースに送る。スケジューラは，まず，ジョブ要件に一致するデータ処理リソースを識別するために，グリッドのデータ処理リソースのデータベース照会（query）を実行する。
【００２１】
　
次のステップで，スケジューラは，別個のジョブ要件に一致するデータ処理リソースを含むリストを作成する。ジョブ要件には，一致するデータ処理リソースの作成されるリストに適用されなければならない，あるスケジューリング・ポリシに関する情報も含まれる。
【００２２】
　
選択されたスケジューリング・ポリシを一致するデータ処理リソースのリストに適用することによって，次のステップでジョブがサブミットされる単一のまたは複数のデータ処理リソースが決定される。この形で，別個のジョブの効果的な処理ならびにグリッド内の処理作業の効果的な分配が保証される。
　
Ｂ　「【００２３】
　本発明の好ましい実施形態によれば，ジョブ要件によって，グリッドのデータ処理リソースが，ジョブを処理できるようになるために提供しなければならないプロパティが指定される。ジョブ要件では，通常は，別個のデータ処理リソースが提供しなければならない記憶容量または計算能力が記述される。ジョブは，さらに，別個のオペレーティング・システムを必要とする場合があり，ジョブは，さらに，別個のソフトウェア製品，ソフトウェアまたはプログラムについて指定される場合がある。
…（中略）…　
【００２５】
　
本発明のもう１つの好ましい実施形態によれば，グリッドの単一のデータ処理リソースが，適当なシステム仕様をデータベースに供給する。データ処理リソースのシステム仕様およびジョブ要件は，スケジューラによって直接に比較されなければならないので，システム仕様に，計算容量，記憶容量，オペレーティング・システム，ソフトウェア構成に関する情報，または別個のリソースの可用性に関するスケジューラの追加情報あるいはこの両方が含まれる。
【００２６】
　
本発明のもう１つの好ましい実施形態によれば，グリッドの各データ処理リソースの単一のシステム仕様が，中央データベースに収集される。中央データベースは，必要な情報をスケジューラに提供する。この形で，中央データベースに，グリッド全体のシステム仕様が保管される。
　
Ｃ　「【００３４】
　図１に，スケジューリング・フレームワーク１０８に渡されるジョブ１００を概略的に示す。スケジューリング・フレームワーク１０８は，スケジューリング・ポリシＡ１０２，スケジューリング・ポリシＢ１０４，およびスケジューリング・ポリシＣ１０６にアクセスできる。データ処理リソース１１０，１１２，および１１４は，中央データベース１１６にリンクされ，中央データベース１１６は，スケジューリング・フレームワーク１０８に接続される。
【００３５】
　
たとえば，複数のジョブ要件を有するジョブ１００が，スケジューリング・フレームワーク１０８に入る時に，スケジューラは，そのシステム仕様がジョブ要件と一致する少なくとも１つのデータ処理リソース１１０，１１２，および１１４を識別するために，照会を実行する。データ処理リソース１１０，１１２，および１１４は，定期的な時間間隔または要求時のいずれかに（プッシュまたはプル），そのめいめいのシステム仕様を中央データベース１１６に送る。所望のシステム仕様が，中央データベース１１６に保管され，照会に基づいてスケジューリング・フレームワーク１０８にサブミットされる。
【００３６】
　スケジューリング・フレームワーク１０８は，データベース１１６によって供給される情報を，ジョブ要件と比較する。さらに，スケジューリング・フレームワーク１０８は，そのシステム仕様がジョブ１００の要件と一致するデータ処理リソースのリストを作成する。たとえば，ジョブ１００によって，スケジューリング・ポリシＡ１０２も指定される時に，スケジューリング・フレームワーク１０８は，そのスケジューリング・ポリシＡ１０２が必要とする情報を収集し，その情報および一致するデータ処理リソースのリストを，スケジューリング・ポリシＡ１０２にサブミットする。
【００３７】
　スケジューリング・ポリシＡ１０２が，一致するデータ処理リソースのリストに適用される時に，スケジューリング・ポリシ１０２によって，ジョブ１００がスケジューリング・ポリシ１０２によってサブミットされなければならない単一のまたは複数のデータ処理リソース１１０，１１２，および１１４が決定される。その後，ジョブ１００は，決定されたデータ処理リソースによって処理されまたは実行される。」　
　
Ｄ　「【００３９】
　
図２は，本発明のスケジューリング方法を表す流れ図の例である。ステップ２００で，スケジューラが，オペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどのジョブ要件と共にジョブを受け取る。ステップ２０２で，スケジューラが，グリッドのすべてのデータベース・リソースへの照会を実行する。照会に応答して，スケジューリング・フレームワークが，すべてのデータ処理リソースのシステム仕様を入手する。ステップ２０４で，スケジューラが，データ処理リソースの入手された仕様を，ジョブの要件と比較する。その結果，スケジューラが，ジョブ要件と一致する処理リソースのリストを作成する。
【００４０】
　ステップ２０６で，スケジューラが，ジョブによって指定されたスケジューリング・ポリシを，一致するリソースのリストに適用する。この形で，別個のデータ処理リソースが，一致するリソースのリストから選択される。
最後に，ステップ２０８で，ジョブを，スケジューリング・ポリシから，選択されたデータ処理リソースへサブミットする。その後，選択されたデータ処理リソースが，ジョブを実行する。
　
　ここで，上記引用文献１に記載されている事項を検討する。　
　　
（ア）上記Ａの「本発明の好ましい実施形態によれば，処理リソースのグリッド内のある処理リソースへのジョブの割当が，スケジューラ・フレームワークによって処理される。スケジューリング・フレームワークは，さまざまな異なるスケジューリング・ポリシにアクセスできる。ジョブ要件および選択されたスケジューリング・ポリシに従って，スケジューリング・ポリシによって，実行のためにジョブが送られる単一のまたは複数の処理リソースが決定される。」，「次のステップで，スケジューラは，別個のジョブ要件に一致するデータ処理リソースを含むリストを作成する。ジョブ要件には，一致するデータ処理リソースの作成されるリストに適用されなければならない，あるスケジューリング・ポリシに関する情報も含まれる。…（中略）…　選択されたスケジューリング・ポリシを一致するデータ処理リソースのリストに適用することによって，次のステップでジョブがサブミットされる単一のまたは複数のデータ処理リソースが決定される。この形で，別個のジョブの効果的な処理ならびにグリッド内の処理作業の効果的な分配が保証される。」との記載からすると，引用文献１における「スケジューラ・フレームワーク」，「スケジューラ」はいずれも「スケジューリング・フレームワーク」を意味していることは自明であり，「スケジューリング・フレームワーク」がグリッド・コンピューティング・システム内のデータ処理リソースへのジョブの割当を行うことを目的として，ジョブ要件に一致するデータ処理リソースのリストを作成し，選択されたスケジューリング・ポリシに従って，実行ジョブをサブミットする単一のまたは複数のデータ処理リソースを決定すると解される。また，上記Ｄの「最後に，ステップ２０８で，ジョブを，スケジューリング・ポリシから，選択されたデータ処理リソースへサブミットする。その後，選択されたデータ処理リソースが，ジョブを実行する。」との記載からすると，「スケジューリング・フレームワーク」はジョブをスケジューリング・ポリシから決定されたデータ処理リソースにサブミットさせる手段を備えていることが読みとれるから，引用文献１には，
「ジョブ要件と一致するデータ処理リソースのリストを作成し，選択されたスケジューリング・ポリシに従って，実行ジョブをサブミットする単一のまたは複数のデータ処理リソースを決定し，前記ジョブを前記スケジューリング・ポリシから決定された前記データ処理リソースにサブミットさせる手段を備えたスケジューリング・フレームワーク」
が記載されていると解される。
　
（イ）上記（ア）での「スケジューリング・フレームワーク」によるジョブ要件と一致するデータ処理リソースのリスト作成に関し，上記Ｂの「本発明のもう１つの好ましい実施形態」は，上記Ａの「本発明の好ましい実施形態」を更に詳細に記載した実施形態であることは明らかである。　
　そして，上記Ｂの「本発明のもう１つの好ましい実施形態によれば，グリッドの単一のデータ処理リソースが，適当なシステム仕様をデータベースに供給する。データ処理リソースのシステム仕様およびジョブ要件は，スケジューラによって直接に比較されなければならないので，システム仕様に，計算容量，記憶容量，オペレーティング・システム，ソフトウェア構成に関する情報，または別個のリソースの可用性に関するスケジューラの追加情報あるいはこの両方が含まれる。」との記載，上記Ｄの「図２は，本発明のスケジューリング方法を表す流れ図の例である。ステップ２００で，スケジューラが，オペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどのジョブ要件と共にジョブを受け取る。ステップ２０２で，スケジューラが，グリッドのすべてのデータベース・リソースへの照会を実行する。照会に応答して，スケジューリング・フレームワークが，すべてのデータ処理リソースのシステム仕様を入手する。ステップ２０４で，スケジューラが，データ処理リソースの入手された仕様を，ジョブの要件と比較する。その結果，スケジューラが，ジョブ要件と一致する処理リソースのリストを作成する。」との記載からすると，「スケジューリング・フレームワーク」はジョブ要件と一致するデータ処理リソースのリストを作成するために，データ処理リソースのシステム仕様とジョブ要件とを比較することが読みとれ，ジョブ要件はオペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどの情報を含むと解されることから，引用文献１には，
「オペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどのジョブ要件と共にジョブを受け取り，すべてのデータ処理リソースのシステム仕様を入手し，前記データ処理リソースのシステム仕様と前記ジョブ要件とを比較し，前記ジョブ要件と一致するデータ処理リソースのリストを作成」する「スケジューリング・フレームワーク」
が記載されていると解される。
　
（ウ）上記（イ）での「スケジューリング・フレームワーク」によるデータ処理リソースのシステム仕様の入手に関し，上記Ａの「本発明の好ましい実施形態」を更に詳細に記載した実施形態として，上記Ｂに「本発明のもう１つの好ましい実施形態」について記載されているところ，上記Ｂの「本発明のもう１つの好ましい実施形態によれば，グリッドの各データ処理リソースの単一のシステム仕様が，中央データベースに収集される。中央データベースは，必要な情報をスケジューラに提供する。この形で，中央データベースに，グリッド全体のシステム仕様が保管される。」との記載，上記Ｃの「たとえば，複数のジョブ要件を有するジョブ１００が，スケジューリング・フレームワーク１０８に入る時に，スケジューラは，そのシステム仕様がジョブ要件と一致する少なくとも１つのデータ処理リソース１１０，１１２，および１１４を識別するために，照会を実行する。データ処理リソース１１０，１１２，および１１４は，定期的な時間間隔または要求時のいずれかに（プッシュまたはプル），そのめいめいのシステム仕様を中央データベース１１６に送る。所望のシステム仕様が，中央データベース１１６に保管され，照会に基づいてスケジューリング・フレームワーク１０８にサブミットされる。」との記載からすると，「スケジューリング・フレームワーク」がジョブ要件と比較するデータ処理リソースのシステム仕様は，複数のデータ処理リソースを含むグリッド・コンピューティング・システム全体のデータ処理リソースについて中央データベースに保管されていることが読みとれ，「スケジューリング・フレームワーク」および複数のデータ処理リソースは中央データベースにアクセス可能であることは明らかであることから，引用文献１には，
「中央データベースにアクセス可能な複数のデータ処理リソースを含むグリッド・コンピューティング・システム全体のデータ処理リソースのシステム仕様を保管する中央データベースにアクセス可能」である「スケジューリング・フレームワーク」　
が記載されていると解される。
　
　以上，（ア）乃至（ウ）で指摘した事項から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「中央データベースにアクセス可能な複数のデータ処理リソースを含むグリッド・コンピューティング・システム全体のデータ処理リソースのシステム仕様を保管する中央データベースにアクセス可能であって，　
　オペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどのジョブ要件と共にジョブを受け取り，　
　すべてのデータ処理リソースのシステム仕様を入手し，前記データ処理リソースのシステム仕様と前記ジョブ要件とを比較し，前記ジョブ要件と一致するデータ処理リソースのリストを作成し，　
　選択されたスケジューリング・ポリシに従って，実行ジョブをサブミットする単一のまたは複数のデータ処理リソースを決定し，前記ジョブを前記スケジューリング・ポリシから決定された前記データ処理リソースにサブミットさせる手段を備えたスケジューリング・フレームワーク。」　
　
　
（３）参考文献　
　
　本願出願前に頒布された，特開２００７−１３３６６５号公報（平成１９年５月３１日出願公開，以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｅ　「【００２２】
　次に，図２を参照して，実施の形態の計算機の機能構成の概略を説明する。
この計算機100は，クラスタシステム200（図１参照）内の計算機100同士で共有している共有ディスク125に接続している。この共有ディスク125には，計算機100上で実行する業務プログラム101等の各種アプリケーションプログラムが格納されている。つまり，この共有ディスクは，ネットワーク201上の前記した補助記憶装置に該当する。そして，クラスタシステム200（図１参照）での業務は，各計算機100が業務プログラム101を共有ディスク125から読み出して図示しない主記憶装置にローディングして順に実行することにより実現する。
　
Ｆ　「【００２５】
　また，この計算機100は，図示しないCPUが図示しない主記憶装置にローディングした図示しない分散処理プログラムを実行することにより，業務要求受信手段116と，業務負荷分散計算機判別手段117と，業務要求転送手段118として機能するようになっている。業務要求受信手段116は，ネットワーク201上のクライアント202等から計算機100に送信された業務要求を受信する。…（中略）…
【００２７】
　
また，この計算機100は，業務プログラム起動手段124として機能することにより，図示しないCPUが，共有ディスク125（補助記憶装置）から図示しない主記憶装置に業務プログラム101をローディングして起動して業務処理を実行させるようになっている。
　
　
（４）対比
　
　本件補正発明と引用発明とを対比する。
　
（４−１）引用発明の「スケジューリング・フレームワーク」は，「グリッド・コンピューティング・システム」におけるコンピュータで実現されることは明らかであり，「ジョブ」をサブミットする「データ処理リソース」を決定することから，引用発明の「スケジューリング・フレームワーク」，「データ処理リソース」はそれぞれ，本件補正発明の「情報処理装置」，「計算機」に相当するといえる。
　
（４−２）引用発明の「中央データベース」は，グリッド・コンピューティング・システム全体のデータ処理リソースのシステム仕様を保管しており，引用発明の「グリッド・コンピューティング・システム」と本件補正発明の「クラスタシステム」とは，分散処理システムという上位概念において共通するといえ，引用発明の「中央データベース」は複数のデータ処理リソースがアクセス可能な共有データ領域であるといえることから，引用発明の「中央データベースにアクセス可能な複数のデータ処理リソースを含むグリッド・コンピューティング・システム全体のデータ処理リソースのシステム仕様」と本件補正発明の「所定の共有ファイル領域にアクセス可能な複数の計算機を含んで構成されるクラスタシステムの前記複数の計算機の仕様情報」とは，“共有データ領域にアクセス可能な複数の計算機を含んで構成される分散処理システムの前記複数の計算機の仕様情報”である点で共通しているといえる。
　また，複数のデータ処理リソースのシステム仕様を保管する引用発明の「中央データベース」と，本件補正発明の複数の計算機の仕様情報を記憶する「マップファイル」とは，アクセス可能な“仕様情報データベース”という上位概念で共通しているといえる。
　そうすると，引用発明の「中央データベースにアクセス可能な複数のデータ処理リソースを含むグリッド・コンピューティング・システム全体のデータ処理リソースのシステム仕様を保管する中央データベースにアクセス可能であって」と，本件補正発明の「所定の共有ファイル領域にアクセス可能な複数の計算機を含んで構成されるクラスタシステムの前記複数の計算機の仕様情報を記憶するマップファイルにアクセス可能であり」とは，後記する点で相違するものの，“共有データ領域にアクセス可能な複数の計算機を含んで構成される分散処理システムの前記複数の計算機の仕様情報を記憶する仕様情報データベースにアクセス可能”である点で共通しているといえる。　
　
（４−３）引用発明では「すべてのデータ処理リソースのシステム仕様を入手」するが，「スケジューリング・フレームワーク」が「中央データベース」を参照して入手していることは自明であり，入手した「データ処理リソースのシステム仕様」と，実行のために選択されたジョブのジョブ要件とを比較するなどの処理を経て，当該ジョブを実行可能なデータ処理リソースを判別しているといえる。ここで，引用発明の「ジョブ」がどのような記憶領域に保持され，どのように選択されるか不明ではあるが，本件補正発明の「前記所定の共有ファイル領域に保持されたロードモジュールの中からユーザによって選択されたロードモジュール」とは，“選択されたプログラム”である点で共通することから，引用発明の「前記データ処理リソースのシステム仕様と前記ジョブ要件とを比較し，前記ジョブ要件と一致するデータ処理リソースのリストを作成し，選択されたスケジューリング・ポリシに従って，実行ジョブをサブミットする単一のまたは複数のデータ処理リソースを決定し」と本件補正発明の「前記所定の共有ファイル領域に保持されたロードモジュールの中からユーザによって選択されたロードモジュールを実行可能な仕様を有する計算機を判別し」とは，“選択されたプログラムを実行可能な仕様を有する計算機を判別”する点で共通しているといえる。
　また，引用発明では，「ジョブを前記スケジューリング・ポリシから決定された前記データ処理リソースにサブミットさせる」が，「スケジューリング・フレームワーク」は，スケジューリング・ポリシを介して間接的に，決定されたデータ処理リソースに対してジョブの実行を指示しているといえる。
　そうすると，引用発明の「オペレーティング・システム，メモリ，ソフトウェア仕様，および別個のスケジューリング・ポリシなどのジョブ要件と共にジョブを受け取り，すべてのデータ処理リソースのシステム仕様を入手し，前記データ処理リソースのシステム仕様と前記ジョブ要件とを比較し，前記ジョブ要件と一致するデータ処理リソースのリストを作成し，選択されたスケジューリング・ポリシに従って，実行ジョブをサブミットする単一のまたは複数のデータ処理リソースを決定し，前記ジョブを前記スケジューリング・ポリシから決定された前記データ処理リソースにサブミットさせる手段」と，本件補正発明の「前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたロードモジュールの中からユーザによって選択されたロードモジュールを実行可能な仕様を有する計算機を判別し，該計算機に，前記ロードモジュールの実行を指示する判別手段」とは，後記する点で相違するものの，“前記データベースを参照して，選択されたプログラムを実行可能な仕様を有する計算機を判別し，該計算機に，前記プログラムの実行を指示する判別手段”である点で共通しているといえる。　
　
　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点） 
　
「共有データ領域にアクセス可能な複数の計算機を含んで構成される分散処理システムの前記複数の計算機の仕様情報を記憶する仕様情報データベースにアクセス可能であり，
　前記仕様情報データベースを参照して，選択されたプログラムを実行可能な仕様を有する計算機を判別し，該計算機に，前記プログラムの実行を指示する判別手段を備えた情報処理装置。」　
　
（相違点１）　
　
　複数の計算機が構成する分散処理システムの種別に関し，本件補正発明は，所定の共有ファイル領域にアクセス可能な複数の計算機を含んで構成されるクラスタシステムであるのに対して，引用発明は，中央データベースにアクセス可能な複数のデータ処理リソースを含むグリッド・コンピューティング・システムである点。
　
（相違点２）　
　
　複数の計算機の仕様情報を記憶する仕様情報データベースに関し，本件補正発明では情報処理装置がアクセス可能なマップファイルが仕様情報を記憶するのに対して，引用発明ではスケジューリング・フレームワークがアクセス可能な中央データベースがシステム仕様を保管している点。
　
（相違点３）　
　
　実行を指示するプログラムの保持に関して，本件補正発明は，クラスタシステムの所定の共有ファイル領域に保持されたロードモジュールであるのに対して，引用発明では，選択されるジョブがどのような記憶領域に保持されるかについては特に言及がない点。
　
（相違点４）　
　
　実行を指示するプログラムの選択に関して，本件補正発明は，ロードモジュールをユーザが選択するのに対して，引用発明は，ジョブがどのように選択されるかについては特に言及がない点。
　
　
（５）当審の判断
　
　上記相違点１乃至４について検討する。
　
（５−１）相違点１及び相違点３について
　
　引用文献１の上記Ａの「本発明は，分散コンピューティング・システムのプラグ可能スケジューリング・ポリシのフレームワークを提供する。膨大なさまざまな異なるジョブの要件に応じて，異なるプラグ可能スケジューリング・ポリシを，システム内に実施して，所与のシステム・リソースの最も効率的な使用を提供することができる。」との記載からすると，引用発明は，さまざまな異なるジョブに対して効率的にシステム・リソースを割り当てることを課題としていると解されるが，このような課題は引用発明のような分散処理システムの一つの態様であるグリッド・コンピューティング・システムに限られるものではなく，さまざまなプログラムを仕様の異なる複数のコンピュータで処理を実行する分散処理システム一般の課題であることは，当業者にとっては自明の事項である。
　また，分散処理システムの態様として，複数のコンピュータがアクセス可能な共有データ領域を有し，該共有データ領域に保持されたプログラムを選択されたコンピュータが処理するクラスタシステムは，例えば参考文献１（上記Ｅ，Ｆ参照）に記載されているように，本願出願前には周知技術であった。
　そして，引用発明において，上記周知技術を適用し，グリッド・コンピューティング・システムで実行されるジョブに代えて，適宜，クラスタシステムの共有データ領域に保持されたプログラムに対して処理を実行するデータ処理リソースを選択すること，すなわち，相違点１及び相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点１及び相違点３は格別なものではない。　
　
（５−２）相違点２について
　
　システム内のハードウェア，ソフトウェア資源を特定のファイルで管理することは，本願出願前には当業者にとっての常套手段であった。　
　そして，引用発明において，中央データベースでシステム仕様を保管することに代えて，適宜，マップファイルでシステム全体のデータ処理リソースのシステム仕様の情報を管理すること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点２は格別なものではない。　
　
（５−３）相違点４について
　
　複数のコンピュータが分散して処理を実行する分散処理システムにおいて，ユーザが選択したプログラムの処理をシステム内のコンピュータに割り付けて実行する旨の技術は，例えば，特開２００６−１６３４８２号公報（段落【００１０】〜【００１３】，図１，２参照）に記載されているように，本願出願前に当該技術分野において普通に実施されていた周知技術であった。
　そして，引用発明において，実行ジョブの選択をユーザが行えるようにして，システム内の決定されたデータ処理リソースに選択されたジョブを実行させること，すなわち，相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点４は格別なものではない。　
　
（５−４）小括
　
　上記で検討したごとく，相違点１乃至４は格別のものではなく，そして，本件補正発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。
　
　
４．むすび 
　
　以上のように，本件補正は，上記「３．独立特許要件」で指摘したとおり，補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，特許法第１７条の２第６項の規定において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって，上記補正却下の決定の結論のとおり決定する。
　
　
第３　本件審判請求の成否について  
  
１．本願発明の認定 
  
　平成２５年１２月１６日付けの手続補正は上記のとおり却下されたので，本件補正後の請求項１に対応する本件補正前の請求項に係る発明（以下，「本願発明」という。）は，平成２１年１月２０日付けの願書に最初に添付した特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「所定の共有ファイル領域にアクセス可能な複数の計算機の仕様情報を記憶するマップファイルにアクセス可能であり，
　前記マップファイルを参照して，前記所定の共有ファイル領域に保持されたプログラムの中から選択したプログラムを実行可能な仕様を有する計算機を判別し，該計算機に，前記プログラムの実行を指示する判別手段を備えた情報処理装置。」　　
　
２．引用文献に記載されている技術的事項及び引用発明の認定 
　
　原査定の拒絶の理由に引用された，引用発明は，前記「第２　平成２５年１２月１６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献」に記載したとおりである。
　
３．対比・判断  
　
　本願発明は，前記「第２　平成２５年１２月１６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」で検討した本件補正発明の「所定の共有ファイル領域にアクセス可能な複数の計算機を含んで構成されるクラスタシステムの前記複数の計算機の仕様情報を記憶するマップファイル」から「を含んで構成されるクラスタシステムの前記複数の計算機」を削除し，「前記所定の共有ファイル領域に保持されたロードモジュールの中からユーザによって選択されたロードモジュールを実行可能な仕様を有する計算機を判別し」を「前記所定の共有ファイル領域に保持されたプログラムの中から選択したプログラムを実行可能な仕様を有する計算機を判別し」とし，「該計算機に，前記ロードモジュールの実行を指示する」を「該計算機に，前記プログラムの実行を指示する」としたものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，前記「第２　平成２５年１２月１６日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献」乃至「（５）当審の判断」に記載したとおり，引用発明及び当該技術分野の周知技術に基づいて当業者が容易に発明をすることができたものであるから，上記特定の限定を省いた本願発明も同様の理由により，引用発明及び当該技術分野の周知技術に基づいて，当業者が容易に発明をすることができたものである。 
　
４．むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。