【事件の表示】
　特願２００４−１７３１９１「コンピューティング環境の作業負荷を均衡させる方法およびシステム」拒絶査定不服審判事件〔平成１７年　３月　３日出願公開、特開２００５−　５６３９１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１６年６月１０日（パリ条約による優先権主張２００３年８月５日、米国）の出願であって、出願後の手続きの経緯は次のとおりである。
拒絶理由通知　　　　　　平成１８年６月９日
意見書　　　　　　　　　平成１８年９月１１日
手続補正　　　　　　　　平成１８年９月１１日
拒絶査定（起案）　　　　平成１８年１２月７日
拒絶査定（送達日）　　　平成１８年１２月１２日
審判請求　　　　　　　　平成１９年３月８日
手続補正　　　　　　　　平成１９年３月８日
　
２．平成１９年３月８日付の手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１９年３月８日付の手続補正を却下する。
　
［理由］
（１）本件補正
　本件補正（平成１９年３月８日付の手続補正を、以下「本件補正」という。）により、次のとおり補正された。
[補正前］
「　【請求項１】
　コンピューティング環境の作業負荷を均衡させる方法であって、
　前記グリッド・コンピューティング環境のマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、
　取得した前記情報の少なくとも一部を用いて前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップとを備えた方法。
　…（中略）…
　　【請求項７】
　コンピューティング環境の作業負荷を均衡させるシステムであって、
　前記グリッド・コンピューティング環境のマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得する手段と、
　取得した前記情報の少なくとも一部を用いて前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させる手段とを備えたシステム。
…（中略）…
　　【請求項１３】
　コンピューティング環境の作業負荷を均衡させるプログラムであって、
　コンピュータに、
　前記グリッド・コンピューティング環境のマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、
　取得した情報の少なくとも一部を用いて前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップとを実行させるプログラム。
…（後略）…」
　
[補正後］
「　【請求項１】
　グリッド・コンピューティング環境の作業負荷を均衡させる方法であって、
　前記グリッド・コンピューティング環境を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられたマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、
　取得した前記情報の少なくとも一部を用いて、前記マネージャ・デーモンが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップとを備えた方法。
　…（中略）…
　　【請求項７】
　グリッド・コンピューティング環境の作業負荷を均衡させるシステムであって、
　前記グリッド・コンピューティング環境を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられたマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得する手段と、
　取得した前記情報の少なくとも一部を用いて前記マネージャ・デーモンが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させる手段とを備えたシステム。
…（中略）…
　　【請求項１３】
　グリッド・コンピューティング環境の作業負荷を均衡させるプログラムであって、
　コンピュータに、
　前記グリッド・コンピューティング環境を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられたマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、
　取得した情報の少なくとも一部を用いて前記マネージャ・デーモンが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップとを実行させるプログラム。
…（後略）…」
　
（２）補正の適否の判断
（２．１）本件補正は、請求項１、請求項７、請求項１３における、
（あ）「コンピューティング環境」を「グリッド・コンピューティング環境」に、
（い）「グリッド・コンピューティング環境のマネージャ・デーモンによって、」を「前記グリッド・コンピューティング環境を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられたマネージャ・デーモンによって、」に、
（う）「取得した情報の少なくとも一部を用いて前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させる」を「取得した前記情報の少なくとも一部を用いて前記マネージャ・デーモンが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させる」に補正するものである。
　前記請求項１、７、１３の補正は、願書に最初に添付した明細書又は図面（「当初明細書」という。）の［０００７］〜［００１０］、および［００１２］〜［００１６］段落の記載に基づいており、この補正は、当初明細書に記載した事項の範囲内においてされたものと認められる。
　したがって、本件補正は、当初明細書に記載した事項の範囲内においてしたものであるから、特許法第１７条の２第３項の規定に適合する。
（２．２）また、前記（１）ないし（３）に係る補正は、特許請求の範囲の減縮を目的とするものと認められるから、特許法第１７条の２第４項の規定に適合する。
　
（２．３）独立特許要件について
　本件補正後の前記請求項１に記載された発明（以下、「本件補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について検討する。
　
（２．３．１）本件補正後の請求項１に係る発明（以下、「本件補正発明」という。）は本件補正後の特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
「グリッド・コンピューティング環境の作業負荷を均衡させる方法であって、 
　前記グリッド・コンピューティング環境を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられたマネージャ・デーモンによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、 
　取得した前記情報の少なくとも一部を用いて、前記マネージャ・デーモンが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップと 
 を備えた 
 方法。 」
　
（２．３．２）引用刊行物
　原審の拒絶の理由に引用された、本願優先権主張日前頒布された刊行物である、特表２００２−５１００７７号公報（以下、「刊行物１」という。）には、図面とともに次の事項が記載されている。
Ａ．「     【００１３】
  したがって、上述の技術より正確なロードバランシングを与えることが可能であり、保存（キャッシュ）されたサーバのアドレスや「保持された」ウェッブブラウザーアドレスに関わらず正確なロードバランシングが実施でき、情報源のネックや単体の故障個所にならず、かつ、電子商業取引を完了するために必要な状態情報を保持するためにクライアントとサーバとの間の関係を保持することが可能である、ロードバランシング技術に対する必要性が存在する。 」
Ｂ．「     【００１４】
    （発明の要約）
  本発明は、１つの側面として、ピアツーピアベースの（ピアツーピアに基づいて）ロードバランシングを直接扱う複数のネットワークサーバを与えることにより、上述の要求に対処する。したがって、サーバのどれかが要求を受信したとき、それらのそれぞれの負荷及び（／または）要求の内容に基づいて、サーバは要求を処理するか、または、それらのピア（同等の物、すなわち、サーバ等）の１つに要求を送る。サーバ上でロードバランシングを直接実施することにより、専用のロードバランシングハードウェアは、それらによって引き起こされる不都合な点と共に減らされる。したがって、例えば、各サーバはロードバランシングを実行する能力を持っているので、サーバによって管理されるウェッブサイトへのアクセスは単体の故障個所によって影響を受けない。さらに、リモートＤＮＳやリクエスタによりキャッシュされたＩＰアドレスの札を付けられた要求は他の要求と同様に（すなわち、ロードバランシング可能なサーバ間でルーティング（または、経路制御）されることにより）、扱われる。
      【００１５】
  本発明の関連した側面によるネットワークサーバは、それらのそれぞれの負荷に関して、それのピアと情報を交換する。交換は、サーバのピア間で、質問／応答、または、非請求マルチキャストに基づいて実施され、暗号化されてもよいし、私設通信回線（private communication channel）上で行われてもよい。交換は定期的に行われてもよいし、要求の入力等のネットワークイベントによって引き起こされてもよい。本発明の好まれる実施例において、一定の間隔（例えば、５００ｍｓ）で、各サーバはそれの負荷情報をそれのピアにマルチキャストする。この期間は事前に設定され、その後にユーザーにより再設定される。特定の実施例では、マルチキャストメッセージは、負荷情報の交換と、送信中のサーバがまだオンライン中であることの確認の二重の目的で使用される。
      【００１６】
  前述の長所により、さらに、サーバ自身の作業負荷に関するほとんど即時の情報を持ったサーバの長所により、サーバは実質的に最新の情報に基づいたルーティング（経路制御）の決定をすることが可能である。最も重要な決定、すなわち、ルーティングを検討するかどうかは、好まれるものとして、最も現在有効な情報に基づいて（すなわち、サーバ内からいかなる待ち時間も無く、ほとんど即時に与えられるローカルサーバの負荷に基づいて）、なされる。
      【００１７】
  本発明のさらなる側面において、サーバの負荷が第１の予め決められたレベル以下であるとき、または、その負荷が第１の予め決められたレベルより大きいが、サーバのピアのそれらが第２予め決められたレベルより大きいとき、サーバは受信した要求を直接処理する。その他の場合、サーバは要求をそれのピアの１つに転送する。サイトをこの種の複数のサーバで装備することにより、１つのサーバが要求により圧倒され、もう１つの同等または同一の能力のサーバが比較的空いている状態になる可能性を減少させる。」
Ｃ．「     【００２９】
    （第１の実施例）
  図２は、受信されたネットワーク要求のロードバランシングのための本発明の処理ステップを示す。最初に、ステップＳ２０１では、ネットワーク要求が、図３に示されるサーバ７のようなサーバで受信される。この要求は、キャッシュされたＩＰアドレス（例えば、要求１、２、３、及び４）をベースにしたインターネット上のリモートＤＮＳにより分解できるか、或いは、前記要求はローカルラウンドロビンＤＮＳ４（例えば、要求５）により分解される。次に、ステップＳ２０２では、サーバ７が、現在処理中であり処理能力が存続している負荷（例えば、ネットワーク要求の数及び/又は複雑性）を決定する。
      【００３０】
  ステップＳ２０３は、サーバ７で現在処理中の負荷が第１の予め定められたレベルを越えたかどうかを決定する。本発明の好ましい実施例では、この予め定められたレベルは５０％であり、サーバ７が５０％の処理能力で作動していることを意味する。もちろん、本発明は、前記第１の予め定められたレベルとして５０％を使用することに限定されない。この点に関して、前記第１の予め定められたレベルに対する値はサーバ７のメモリに記憶することができ、定期的に書き換えることができる。
      【００３１】
  ステップＳ２０３がサーバ７は前記第１の予め定められたレベルを越える負荷を処理していないと決定した場合、フローはステップＳ２０４へ進む。ステップＳ２０４では、前記ネットワーク要求がサーバ７で処理され、それに対する応答が適当なチャネルを経由して出力される。反対に、ステップＳ２０３がサーバ７は前記第１の予め定められたレベルを越える負荷を処理していると決定した場合、フローはステップＳ２０５へ進む。
      【００３２】
  ステップＳ２０５は、サーバ７のピア（例えば、図３に示されるサーバ９、１０）により現在処理中の負荷を確定する。更に詳細には、ステップＳ２０５では、ロードバランシングモジュール１７は、ロードバランシングモジュール１９、２０により提供された最新の負荷情報を有する現在の負荷情報から成る。これらロードバランシングモジュールは継続的に各負荷に関する情報を交換するので、この情報は比較のために直ちに利用可能である。図３に示される実施例では、ロードバランシングモジュール１９はサーバ９により現在処理中の負荷に関する情報を提供し、ロードバランシングモジュール２０はサーバ１０により現在処理中の負荷に関する情報を提供する。
      【００３３】
  ステップＳ２０６では、ロードバランシングモジュール１７は、サーバ７のピアにより現在処理中の負荷が、第２の予め定められたレベルを越える差だけサーバ７上の負荷よりも小さいかどうかを決定する。本発明の好ましい実施例では、この第２の予め定められたレベルは２０％であり、サーバ９又は１０がサーバ７より少なくとも自らの利用可能な処理能力より２０％以上高い処理能力を有するかどうかを評価する手段を提供する。もちろん、本発明は前記第２の予め定められたレベルとして２０％を使用することに限定されない。この点に関して、上記のように、前記第２の予め定められたレベルに対する値はサーバ７のメモリに記憶することができ、定期的に書き換えることができる。
      【００３４】
  ステップＳ２０６が、サーバ７のピア（即ち、サーバ９、１０）は自らの利用可能な処理能力の２０％より高い処理能力を有しないと決定した場合、フローはステップＳ２０４へ進む。ステップＳ２０４では、前記ネットワーク要求がサーバ７で処理され、それに対する応答が適当なチャネルを経由して出力される。反対に、ステップＳ２０６がサーバ７のピアの少なくとも１つが前記第２の予め定められたレベルだけサーバ７の負荷よりも小さな負荷を処理していると決定した場合、フローはステップＳ２０７へ進む。
      【００３５】
  ステップＳ２０７は、もしあるならば、どのウェブサイト１のサーバがオフラインであるか、例えば、ステップＳ２０５の負荷情報交換（又は、その欠如）に基づいて決定する。サーバは、多くの理由によりオフラインになる。例えば、前記サーバは電源を切られるかもしれないし、動作不良になるかもしれない。そのような場合、前記サーバのロードバランシングモジュールは、ロードバランシングモジュール１７からの要求に応答できないか、又は情報の交換に参加できず、それによってそれらのサーバがオフラインであることを示す。加えて、本発明の好ましい実施例では、前記ロードバランシングモジュールは、各サーバで診断プログラムを実行できる。そのような診断プログラムは、前記サーバの動作をテストする。サーバが正常に動作していない場合、前記サーバのロードバランシングモジュールは、ネットワーク要求がそのサーバにルーティングされるべきではないことをロードバランシングモジュール１７に指示する。
      【００３６】
  次に、ステップＳ２０８がオンラインサーバからの負荷情報を解析して、どのオンラインサーバが最小の負荷を処理しているか決定する。ステップＳ２０８は、他のサーバ９、１０（両方ともオンラインであると仮定する）により処理されている種々の負荷を比較することにより、これを行う。次に、ステップＳ２０９が、前記ネットワーク要求を最小負荷を現在処理している前記サーバまでルーティングする。本発明では、ロードバランシングモジュール１７からリクエスタまで、前記リクエスタに指示されたサーバへ要求を送信することを指示する命令を送信することにより、ルーティングは実行される。従って、ルーティングは前記リクエスタソフトウェアにより自動的に処理され、実際のインターネットユーザには事実上見えない。
      【００３７】
  その後、そのサーバがステップＳ２１０で要求を処理する。しかし、現時点で、本発明が最小負荷を処理しているサーバへ要求をルーティングすることに限定されないことに注意しなければならない。むしろ、本発明は前記要求を、予め定められた処理能力と同じかそれ以下、又は（限定されないが）ラウンドロビンハンドオフローテーションに類似した何れのサーバにもルーティングできるように構成される。」
Ｄ．「     【００３８】
  図３は、本発明による負荷分散を示す。更に詳細には、上記のように、サーバ７（更に詳細には、ロードバランシングモジュール１７）は、ネットワークＤＮＳ２１で分解された要求１、２、３、及び４、並びにローカルＤＮＳ４を経由して要求５を受信する。同様に、サーバ１０は、ローカルＤＮＳ４を経由して要求６（即ち、キャッシュされた要求）を受信する。これらの要求の何れも「ブックマークされた」要求であり、１つのサーバに対して特にアドレス指定されたことを意味する。いったん各ロードバランシングモジュールが要求を受信したら、各ロードバランシングモジュールは、関連するサーバでその要求を処理するか、又はその要求を他のサーバにルーティングするかを決定する。これは、図２に示される方法で行われる。図２に示される処理のおかげで、ロードバランシングモジュール１７、１９、及び２０が要求を分配するので、サーバ７は要求１、２を処理し、サーバ９は要求３、５を処理し、サーバ１０は要求４、６を処理する。 」
　
（Ａ）コンピューティング環境とは、コンピュータを使うときに関係する、ハードウェア、ソフトウェア、ネットワークなど全部であり、図３には、コンピューティング環境を構成する、インターネット、ネットワークＤＮＳ、ロードバランシングモジュールを備えたウェブサーバ等が示されている。また、刊行物１は、発明の名称「ネットワークサーバ間の負荷を平衡（バランス）させるためのシステム」からも明らかなように、ネットワークサーバ間の負荷を平衡（バランス）させる発明に係り、これと図２のロードバランシングのための処理フローから、負荷を平衡させる方法がみてとれる。
（Ｂ）Ｃ．によれば、サーバ７が、現在処理中であり処理能力が存続している負荷（例えば、ネットワーク要求の数及び/又は複雑性）を決定し、また、サーバ９は、ロードバランシングモジュール１９から現在処理中の負荷に関する情報が提供され、サーバ１０は、ロードバランシングモジュール２０から現在処理中の負荷に関する情報が提供される。 サーバ７のロードバランシングモジュール１７は、ロードバランシングモジュール１９、２０により提供された最新の負荷情報を有する現在の負荷情報から成り、これらロードバランシングモジュールは継続的に各負荷に関する情報を交換する。
（Ｃ）Ｂ．Ｄ．によれば、最も現在有効な情報に基づいて（すなわち、サーバ内からいかなる待ち時間も無く、ほとんど即時に与えられるローカルサーバの負荷に基づいて）、サーバは実質的に最新の情報に基づいたルーティング（経路制御）の決定をする。
　サーバの負荷が第１の予め決められたレベル以下であるとき、または、その負荷が第１の予め決められたレベルより大きいが、サーバのピアのそれらが第２の予め決められたレベルより大きいとき、サーバは（更に詳細にはサーバ７のロードバランシングモジュール１７が図２に示された方法で）受信した要求を直接処理し、その他の場合、サーバは要求をそれのピアの１つに転送し、これにより１つのサーバが要求により圧倒され、もう１つの同等または同一の能力のサーバが比較的空いている状態になる可能性を減少させる。
　
　Ａ．と（Ａ）〜（Ｃ）の点をふまえると、刊行物１には、正確なロードバランシングが実施でき、情報源のネックや単体の故障個所にならず、かつ、電子商業取引を完了するために必要な状態情報を保持するために、クライアントとサーバとの間の関係を保持することを可能とした次の発明（以下「刊行物１の発明」という。）が示されている。
　
　コンピューティング環境のネットワークサーバ間の負荷を平衡（バランス）させる方法であって、 
　前記コンピューティング環境を構成する複数のサーバのうち少なくとも１つのサーバ（７）に備えられたロードバランシングモジュール（１７）によって、前記複数のサーバのうちの少なくとも１つのサーバ（７、９又は１０）に関する現在処理中の負荷に関する情報を、当該サーバ（７、９又は１０）のロードバランシングモジュール（１７、１９、２０）から提供されるステップと、
　提供された前記情報の少なくとも一部を用いて、サーバは実質的に最新の情報に基づいたルーティング（経路制御）の決定をし、サーバの負荷が第１の予め決められたレベル以下であるとき、または、その負荷が第１の予め決められたレベルより大きいが、サーバのピアのそれらが第２の予め決められたレベルより大きいとき、サーバは受信した要求を直接処理し、その他の場合、サーバは要求をそれのピアの１つに転送し、１つのサーバが要求により圧倒され、もう１つの同等または同一の能力のサーバが比較的空いている状態になる可能性を減少させるステップと 
 を備えた 
 方法。 
　
　同じく、原査定において示された、本願優先権主張日前頒布された刊行物である、日経インターネットテクノロジー第５９号、日経ＢＰ社、２００２．０５．２２（１４頁、１５頁参照）（以下「刊行物２」という。）には、次の事項が記載されている。
ａ．「グリッド・コンピューティングとは，地理的に分散した複数のコンピュータを１台の仮想コンピュータとして扱う技術。処理に適したハードウェアやソフトウェアを保持するコンピュータをネットワーク経由で検出し，分散処理する。…（中略）…マスタ・サーバはジョブの実行に適したコンピュータを探すために，各コンピュータの情報を利用する。例えば，プロセッサの負荷，メモリーやハード・ディスクの空き容量，過去の処理実績などである。使用率の低いコンピュータに優先して処理を割り当てることで，ジョブの実行が効率化する。」（１４頁中欄４行〜１５頁左欄１３行）
ｂ．図１には、グリッド・コンピューティングが示され、クラスタに参加するノードの負荷状況や適正に応じて，ジョブを割り当てる、と記載されている。
ｃ．表１には、異なるクラスタに処理を振り分ける・・・Ｇｌｏｂｕｓ　Ｔｏｏｌｋｉｔを使用する旨記載され、関連して、「グリッド・コンピューティングの基盤となるミドルウェア（表１）。クラスタの管理機能，ジョブの振り分け／実行機能，・・・このミドルウェア上に，実際のアプリケーションを作り込む。」（１５頁左欄末行〜中欄６行）と記載されている。
　
　同じく、原査定において示された、本願優先権主張日前頒布された刊行物である、ＪＡＶＡ　ＰＲＥＳＳ　ＶＯＬ．３０、（株）技術評論社、２００３．６．１５（頁８４−頁９４参照）（以下「刊行物３」という。）には、次の事項が記載されている。
あ．「このように異機種で分散した環境の下でも，ＯＳの上にメタＯＳのようなミドルウェアを置いて…（中略）…同じグリッドの技術は，特にビジネスのコンピューティングの流れで，そういった異機種で分散した環境でも図７のような，主に高可用性や，高負荷への対応といったＱｏＳを実現するシステム管理の仕組みを実現するシステム管理の仕組みを実現する土台…（中略）…となるメタＯＳの機能は今まさにオープンスタンダードで標準化され…（中略）…オープンソースのＧｌｏｂｕｓツールキッド」（８７頁右欄３行〜２１行）
い．図７には「負荷分散機能」と記載されている。
う．ＣＯＬＵＭＮ欄には、「サーバにＧｌｏｂｕｓを搭載し、その上に高速のスケジューラを搭載したグリッド環境」が記載されている。（８８頁下欄）
（２．３．３）対比・判断
　本件補正発明と刊行物１の発明とを対比すると
（ア）刊行物１の発明の「コンピューティング環境」は「グリッド・コンピューティング環境」とまでは言えないまでもコンピューティング環境であり、一方、本件補正発明の「グリッド・コンピューティング環境」は、上位概念ではコンピューティング環境であるから、この点で刊行物１の発明の前記環境と共通する。
　刊行物１の発明の「ネットワークサーバ間の負荷を平衡させる方法であって」と、本件補正発明の「グリッド・コンピューティング環境の作業負荷を均衡させる方法であって」とは「コンピューティング環境の作業負荷を均衡させる方法であって」で実質的な差異はない。
（イ）刊行物１の発明の「コンピューティング環境を構成する複数のサーバ」は、「グリッド・」コンピューティング環境を構成する複数の「異質の」システムとまでは言えないまでも、コンピューティング環境を構成する複数のサーバ（システム）であり、一方、本件補正発明の「グリッド・コンピューティング環境を構成する複数の異質のシステム」も上位概念では「コンピューティング環境を構成する複数のシステム」であるから、「コンピューティング環境を構成する複数のシステム」では共通する。また、刊行物１の発明の「サーバ（７）に備えられたロードバランシングモジュール（１７）」「サーバ（９又は１０）のロードバランシングモジュール（１９、２０）」は、それぞれ、システムに備えられた「マネージャ・デーモン」「スケジューラ」とまでは言えないまでも、サーバ（システム）に備えられたモジュールであり、一方、本件補正発明のシステムに常駐する「マネージャ・デーモン」「スケジューラ」も、上位概念ではサーバ（システム）に備えられたモジュールである。これらをふまえると、刊行物１の発明の「コンピューティング環境を構成する複数のサーバのうち少なくとも１つのサーバ（７）に備えられたロードバランシングモジュール（１７）によって、前記複数のサーバのうちの少なくとも１つのサーバ（７、９又は１０）に関する現在処理中の負荷に関する情報を、当該サーバ（７、９又は１０）のロードバランシングモジュール（１７、１９、２０）から提供されるステップ」と本件補正発明とは、「コンピューティング環境を構成する複数のシステムのうち少なくとも１つのシステムに備えられたモジュールによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのモジュールから取得するステップ」を有する点で共通する。
（ウ）刊行物１の発明の「提供された前記情報の少なくとも一部を用いて、サーバは実質的に最新の情報に基づいたルーティング（経路制御）の決定をし、サーバの負荷が第１の予め決められたレベル以下であるとき、または、その負荷が第１の予め決められたレベルより大きいが、サーバのピアのそれらが第２予め決められたレベルより大きいとき、サーバは（更に詳細にはサーバ７のロードバランシングモジュール１７が図２に示された方法で）受信した要求を直接処理し、その他の場合、サーバは要求をそれのピアの１つに転送し、１つのサーバが要求により圧倒され、もう１つの同等または同一の能力のサーバが比較的空いている状態になる可能性を減少させるステップ」は、当該「サーバ７のロードバランシングモジュール１７」はマネージャ・デーモンとまでは言えないまでも上位概念ではモジュールであり、一方、本件補正発明の「マネージャ・デーモン」も上位概念ではモジュールであり、且つ、本件補正発明は「コンピューティング環境のネットワークサーバ間の負荷を平衡（バランス）させる方法」に係るので、刊行物１の発明の前記事項と本件補正発明とは、「取得した前記情報の少なくとも一部を用いて、前記モジュールが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップ」を有する点で共通する。
　
（ア）〜（ウ）をふまえると、刊行物１の発明と本件補正発明とは、次の事項を有する発明である点で一致し、そして、次の点で相違する。
〈一致点〉
　コンピューティング環境の作業負荷を均衡させる方法であって、 
　前記コンピューティング環境を構成する複数のシステムのうち少なくとも１つのシステムに備えられたモジュールによって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのモジュールから取得するステップと、 
　取得した前記情報の少なくとも一部を用いて、前記モジュールが前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップと 
 を備えた 
 方法。
　
〈相違点１〉コンピューティング環境と、コンピューティング環境を構成する複数のシステムが、本件補正発明は、「グリッド」・コンピューティング環境であり、「異質のシステム」であるのに対し、刊行物１の発明は、そのような記載はない点。
〈相違点２〉モジュールによって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのモジュールから取得するステップが、本件補正発明は、「マネージャ・デーモン」によって、前記複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムの「スケジューラ」から取得するに対し、刊行物１の発明は、サーバ（７）のロードバランシングモジュール（１７）が、サーバ（９又は１０）のロードバランシングモジュール（１９、２０）から取得する点。
〈相違点３〉少なくとも２のシステムの作業負荷を均衡させるモジュールが、本件補正発明は、「マネージャ・デーモン」であるのに対し、刊行物１の発明は、サーバ（７）のロードバランシングモジュール（１７）である点。
　
〈当審判断〉
〈相違点１〉について
　コンピューティング環境と、コンピューティング環境を構成する複数のシステムが、グリッド・コンピューティング環境であり、異質のシステムである技術は、刊行物２ないし刊行物３にみられるように本願優先権主張日前周知の技術にすぎない。即ち、刊行物２ないし３にはグリッド・コンピューティング環境が示され（刊行物２の図１、刊行物３の図７参照）、刊行物２のａ．には、地理的に分散した複数のコンピュータを１台の仮想コンピュータとして扱い、処理に適したハードウェアやソフトウェアを保持するコンピュータをネットワーク経由で検出して分散処理する旨記載されており、刊行物３には、グリッドコンピューティングについて異機種で分散した環境の下でＯＳの上にメタＯＳのようなミドルウェアを置いた環境が記載されており、一方、「異質なシステム」とは、本願明細書【０００８】【００１２】段落に、「多くの場合、グリッド・コンピューティング環境のシステムは異質なシステムである。すなわち、グリッド・コンピューティング環境の複数のシステムのうちの少なくとも１つのシステムは当該環境の少なくとも１つの他のシステムとは異なるハードウェアおよび／またはソフトウェアを備えている。さらに、あるいはまたは、システムは互いに地理的に離れている。」「 一例ではグリッド・コンピューティング環境のシステムは異質であるから、…（中略）…Ｇｌｏｂｕｓと呼ばれているツールキットを用いてシステム間の通信を容易にしている。」と記載されていることから、前記刊行物２ないし３の事項は、グリッド・コンピューティング環境であり、異質のシステムであることを示している。
　刊行物１の発明における、コンピューティング環境と、コンピューティング環境を構成する複数のシステムを、グリッド・コンピューティング環境であり、異質のシステムであるとすることは、前記技術を参酌することにより当業者が容易になし得ることである。
〈相違点２〉について
　モジュールによって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのモジュールから取得するステップについて、「マネージャ・デーモン」によって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムの「スケジューラ」から取得する技術は、本願優先権主張日前周知の技術にすぎない。即ち、例えば、特開２００１−１４２８６号公報３頁左欄４４行〜５０行には、スケジューラ当該計算機上の負荷監視デーモンがリソースの使用率などの負荷情報を負荷情報管理デーモン１２０に報告すること、及び、各計算機の任意のソフトウエアが動作開始後、本システムに実行要求のあったプロセス及びジョブはスケジューラデーモン１１０が負荷情報を参照し、負荷の低い計算機に順に実行処理を行わせることが記載されており、この記載によれば、少なくとも１つの計算機システムに関する負荷情報を、当該計算機システムの負荷監視デーモンから報告されるステップが、「負荷情報管理デーモン」によって、複数の計算機システムのうちの少なくとも１つの計算機システムに関する負荷情報を、当該システムの「スケジューラ当該計算機上の負荷監視デーモン」から報告される技術が読み取れる。前記「負荷情報管理デーモン」「スケジューラ当該計算機上の負荷監視デーモン」は、それぞれ本件補正発明の「マネージャ・デーモン」「スケジューラ」と実質的な差異はない。
　刊行物１の発明において、モジュールによって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのモジュールから取得するステップが、「マネージャ・デーモン」によって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムの「スケジューラ」から取得すると成すことは、前記周知の技術を参酌することにより当業者が容易になし得ることである。
〈相違点３〉について
　少なくとも２のシステムの作業負荷を均衡させるモジュールが、「マネージャ・デーモン」である技術は、本願優先権主張日前周知の技術にすぎない。即ち、例えば、前記特開２００１−１４２８６号公報【発明が解決しようとする課題】の項には全計算機の負荷情報に加えて、インストールされたソフトウェア情報も管理し、プロセス及びジョブの割り振りだけでなく、負荷の集中要因のソフトウェアを他計算機へ移動・分散する負荷分散制御に係る旨記載され、３頁右欄７行〜３５行には「負荷情報管理デーモン１２０は、全計算機の負荷情報を元に相対的に負荷の高い計算機を抽出し、その計算機名及び負荷状況等の負荷情報６００をインストール情報デーモン１３０に伝える。以下の内容は図５に示す。インストール情報デーモン１３０は、通知された計算機のインストール情報５００及び負荷情報６００を参照し、リソース使用率が高いプロセスが属するソフトウエアを特定する。そしてインストール情報５００から、共存可能数、当該ソフトウエア及び関連ソフトウエアのディスク所要量等を調べ、本ソフトウエアの移動（または複写）先計算機をサーチする。…（中略）…移動先（または複写先）計算機上でのインストールを行うためのインストールスクリプトを作成し、該当計算機上のインストールデーモンに実行することを司令する。…（中略）…そして、上記のソフトウエアの移動（または複写）に伴い、関連計算機のインストール情報５００を書き換え、その旨をスケジューラデーモン１１０に通知する。」と記載されており、前記全計算機の負荷情報を元にソフトウエアの移動（または複写）を行う負荷分散制御に係る「負荷情報管理デーモン及びインストール情報デーモン」のプロセスは、少なくとも２の計算機（システム）の作業負荷を均衡させるモジュールが、「マネージャ・デーモン」である技術に相当する。
　刊行物１の発明において、サーバ７のロードバランシングモジュール１７のプロセスである、少なくとも２のシステムの作業負荷を均衡させるモジュールを、「マネージャ・デーモン」であると成すことは、前記周知の技術を参酌することにより当業者が容易になし得ることである。
　
　そして、本件補正発明により奏する効果も、刊行物１に記載された発明、刊行物２、３に記載された発明及び前記周知技術から当業者が予測できる範囲内のものにすぎない。
　したがって、本件補正発明は、刊行物１に記載された発明、刊行物２、３に記載された発明及び前記周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
（４）小結
　以上のとおり、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願請求項１の発明について
（１）平成１９年３月８日付の手続補正は前記のとおり却下されたので、本願の請求項１に係る発明（以下、「請求項１の発明」という。）は、平成１８年３月６日付けの手続補正書における特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
　
　コンピュータ環境の作業負荷を均衡させる方法であって、
　グリッド・コンピューティング環境のマネージャ・デーモンによって、複数のシステムのうちの少なくとも１つのシステムに関する情報を、当該システムのスケジューラから取得するステップと、
　取得した前記情報の少なくとも一部を用いて前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップとを備えた方法。
　
（２）引用刊行物
　引用刊行物とその記載事項、及び周知技術は、前記（２．３．２）（２．３．３）〈当審判断〉に記載したとおりである。
 　
（３）対比・判断
　本願発明は、前記（２）．乃至（３）．で検討した本件補正発明における発明特定事項である、
「グリッド」・コンピューティング環境、
グリッド・コンピューティング環境「を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられた」マネジャ・デーモン、
「前記マネージャ・デーモンが」前記複数のシステムのうちの少なくとも２のシステムの作業負荷を均衡させるステップ
から、前記「グリッド」、前記「を構成する複数の異質のシステムのうち少なくとも１つのシステムに備えられた」、前記「前記マネージャ・デーモンが」なる構成を省いたものである。
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本件補正発明が、前記（２．３．２）乃至〈当審判断〉に記載したとおり、刊行物１に記載された発明、刊行物２、３に記載された発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、刊行物１に記載された発明、刊行物２、３に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものである。
　
　そして、本願発明により奏する効果も、刊行物１に記載された発明、刊行物２、３に記載された発明及び周知技術から当業者が予測できる範囲内のものにすぎない。
（４）むすび
　以上のとおり、本願発明は、刊行物１に記載された発明、刊行物２、３に記載された発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。