【事件の表示】
　特願２０１０−　４８２２７「負荷分散システム」拒絶査定不服審判事件〔平成２３年　９月２２日出願公開、特開２０１１−１８６５４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，平成２２年３月４日を出願日とする出願であって，その後の手続の経緯の概要は次のとおりである。
　出願審査請求　　　　　　　　　　　平成２３年４月８日
　拒絶理由（起案日）　　　　　　　　平成２４年８月２８日
　意見書及び手続補正書（提出日）　　平成２４年１０月１９日
　拒絶査定（起案日）　　　　　　　　平成２５年３月１４日
　同謄本送達（送達日）　　　　　　　平成２５年３月１８日
　審判請求（提出日）　　　　　　　　平成２５年６月１７日
　手続補正書（提出日）　　　　　　　平成２５年６月１７日
　前置報告書（作成日）　　　　　　　平成２５年９月２日
　審尋（起案日）　　　　　　　　　　平成２５年１１月２８日
　回答書（提出日）　　　　　　　　　平成２６年１月２８日
　
　
第２．平成２５年６月１７日付の手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成２５年６月１７日付の手続補正を却下する。
　
［理由］
１．本件補正
　平成２５年６月１７日付の手続補正（以下，「本件補正」という。）により，特許請求の範囲は次のように補正された。
　
（本件補正後の特許請求の範囲）
（以下，本件補正により補正された特許請求の範囲に記載された各請求項を「補正後請求項」という。）
「　【請求項１】
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更することを特徴とする負荷分散システム。
　　【請求項２】
　前記生成手段は，前記複数のリソースの各々について，過去に求めた複数の正規化リース値を利用して正規化リソース値の加重平均を求め，加重正規化リソース値を生成し，
　前記導出手段は，生成した複数種類の加重正規化リソース値の加重平均を導出することを特徴とする請求項１に記載の負荷分散システム。
　　【請求項３】
　前記生成手段は，前記正規化リソース値の加重平均を求める際，最新の正規化リソース値に対する重みが最大となり，過去の正規化リソース値に対する重みほど小さくなるように，各重みの値が設定されていることを特徴とする請求項２に記載の負荷分散システム。
　　【請求項４】
　前記複数のリソースには，ハードウエア・リソースが２つ以上含まれていることを特徴とする請求項１〜３のいずれか１の請求項に記載の負荷分散システム。
　　【請求項５】
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置を制御するプログラムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　
前記生成手段，前記導出手段，及び前記通知手段を，異常が検出されない場合に定期的に実行
　前記プログラムは，
　前記負荷分散装置を，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更する手段として機能させることを特徴とするプログラム。」
　
（本件補正前の特許請求の範囲）
（以下，平成２４年１０月１９日付の手続補正により補正された特許請求の範囲に記載された各請求項を「補正前請求項」という。）
「【請求項１】
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更することを特徴とする負荷分散システム。
　　【請求項２】
　前記生成手段は，前記複数のリソースの各々について，過去に求めた複数の正規化リソース値を利用して正規化リソース値の加重平均を求め，加重正規化リソース値を生成し，
　前記導出手段は，生成した複数種類の加重正規化リソース値の加重平均を導出することを特徴とする請求項１に記載の負荷分散システム。
　　【請求項３】
　前記生成手段は，前記正規化リソース値の加重平均を求める際，最新の正規化リソース値に対する重みが最大となり，過去の正規化リソース値に対する重みほど小さくなるように，各重みの値が設定されていることを特徴とする請求項２に記載の負荷分散システム。
　　【請求項４】
　前記複数のリソースには，ハードウエア・リソースが２つ以上含まれていることを特徴とする請求項１〜３のいずれか１の請求項に記載の負荷分散システム。
　　【請求項５】
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置を制御するプログラムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備するものであり，
　前記プログラムは，
　前記負荷分散装置を，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更する手段として機能させることを特徴とするプログラム。」
 
２．補正の適否
（１）新規事項追加についての判断
　本件補正が，第１７条の２第３項の規定を満たすものであるか否か，即ち，本件補正が，願書に最初に添付した明細書，特許請求の範囲又は図面（以下，「当初明細書等」という。）に記載した事項の範囲内でなされたものであるかについて，以下に検討する。
（以下，下線部は補正された部分を示す。）
　
　補正後請求項１の「
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　一方，当初明細書等の段落【００１８】〜【００２３】には，図５に関連して，
　
「【００１８】
　
リソース値正規化処理部（生成手段）
・・・（中略）・・・
【００２１】
　
稼動状況処理部（導出手段）
・・・（中略）・・・
【００２２】
　
稼動状況値通知処理部（通知手段）
【００２３】
（２）実施形態の動作
　図５は，各サーバ３００が
定期的
実行する処理フロー
　各サーバ３００は，
リソース値正規化処理
稼動状況値処理
稼動状況値通知処理
一連の処理を実行
異常が生じたか否かを判断
（下線は参考のため，当審にて付与した。）
　
　と記載されており，生成手段，導出手段，通知手段による一連の処理と，その後の異常の検出処理とが，連続した処理として「定期的」に実行されることは読み取れるものの，異常の検出処理によって一旦「異常が検出されない場合」になると，その後は上記異常の検出処理を経ることなく，「前記生成手段，前記導出手段，及び前記通知手段」のみが「定期的に実行される」態様，すなわち，上述の，一旦「異常が検出されない場合」になると，その後は「前記生成手段，前記導出手段，及び前記通知手段」のみが「定期的に実行される」態様までは読み取ることはできない。また，他の段落などにも当該事項を開示する記載はされていない。
　
　したがって，本件補正は，当初明細書等に記載した事項の範囲内においてしたものではなく，特許法第１７条の２第３項（新規事項）の規定に適合しないから，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
（２）本件補正における補正の目的についての判断
　本件補正は，上記「（１）」において検討したとおり，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，仮に，本件補正が，当初明細書等の記載の範囲内でなされたものであるとして，本件補正が，特許法第１７条の２第５項の規定を満たすものであるか否か，即ち，本件補正が，特許法第１７条の２第５項に規定する請求項の削除，特許請求の範囲の減縮（特許法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る），誤記の訂正，或いは，明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る）の何れかを目的としたものであるかについて，以下に検討する。
　
　補正後請求項１に「
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　また，前記補正は，明りょうでない記載の釈明，誤記の訂正又は請求項の削除を目的としたものでもない。
　
　したがって，本件補正は，特許法第１７条の２第５項の各号に掲げるいずれの事項を目的とするものにも該当せず，同法第１７条の２第５項の規定に適合しないから，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
（３）独立特許要件についての判断
　本件補正は，上記「（１）」において検討したとおり，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであり，
　仮に，本件補正が，当初明細書等の記載の範囲内でなされたものであるとしても，上記「（２）」において検討したとおり，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものであるが，
　仮に，本件補正が，当初明細書等の記載の範囲内でなされ，特許請求の範囲の限定的減縮を目的とし，補正の目的要件を満たすものであるとして，
　本件補正が，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定を満たすものであるか否か，即ち，補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否か，以下に検討する。
  
（３．１）特許法第３６条第４項第１号，第６項第１号，第２号について
　補正後請求項１の「
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　したがって，発明の詳細な説明の記載は，特許法第３６条第４項第１号の規定に違反する。
　
　また，補正後請求項１の「
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　すなわち，前記「異常が検出されない場合」が，いずれの事項に関する「異常」か不明りょうであるとともに，「定期的に実行される」のが何れの処理であるかも不明であり，また，この点について発明の詳細な説明の記載とも整合せず，明確でない。
　また，「異常が検出されない場合」とする契機と，「定期的に実行」との時間的な関連や「異常が検出されない場合」でない場合に如何に制御するのか不明であり，また，この点についても発明の詳細な説明の記載と整合せず，明確でない。
　したがって，特許請求の範囲の記載は，特許を受けようとする発明が明確でないので，特許法第３６条第６項第１号，第２号の規定に違反する。
　
（３．２）特許法第２９条第２項について
（３．２．１）本件補正発明
　上記（３．１）において検討したとおり，補正後請求項１に係る発明（以下，これを「本件補正発明」という）は，特許請求の範囲の記載が明確ではなく，発明の詳細な説明の記載は，当業者がその実施をすることができる程度に明確かつ十分に記載したものではないが，一応，前記「１．本件補正」において，補正後請求項１として引用した以下の記載のとおりのものとして，特許法第２９条第２項についての検討を行う。
　
「負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，　
　前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更することを特徴とする負荷分散システム。」
　
（３．２．２）引用文献１
　原審が，平成２４年８月２８日付の拒絶理由に引用した，本願出願前に頒布された刊行物である特開平６−２６６６４３号公報（以下，「引用文献１」という。）には，図面とともに次の事項が記載されている。
　
Ａ．「【０００４】
【発明が解決しようとする課題】しかしながら，上記の方法ではネットワーク全体の管理ができず，またの方法では異なるホスト上で動く同じ機能のサーバプログラムを効率を含めて管理することができないという問題があった。
【０００５】本発明はこのような点に鑑み，ネットワーク上にリモートプロシージャコールのサーバプログラムグラムが複数個存在する時に，クライアントプログラムがサーバプログラムから効率よくリターンバリューを返してもらうために，一番適切なサーバプログラムを呼び出すことのできる管理方法を提供することを目的とする。」
　
Ｂ．「【０００６】
【課題を解決するための手段】このような目的を達成するために本発明では，複数のホストコンピュータがネットワークを通して接続され，リモートプロシージャコールサーバプログラムが複数のホストコンピュータに存在するシステムにおいて，あるホストコンピュータ上に，ネットワーク全体のリモートプロシージャコールサーバプログラムおよびこのサーバプログラムが動作するホストコンピュータに関する情報を管理テーブルに記憶し，他のホストコンピュータにあるクライアントプログラムからのリクエストを受けるとサーバホストコンピュータの性能や負荷に基づき適切なホストコンピュータを選択し，当該ホストコンピュータのサーバプログラムへメッセージをフォワードするグローバルマネージャを備え，前記サーバプログラムグラムの存在するホストコンピュータ上に，サーバプログラムおよび自身のホストコンピュータの情報を前記グローバルマネージャに送信するローカルマネージャを備え，
【０００７】このローカルマネージャは自身が属するホストコンピュータの性能を前記グローバルマネージャへ送信し，その後は一定周期でロードアベレージをグローバルマネージャへ送信し，前記グローバルマネージャは，前記管理テーブルを初期化した後前記ローカルマネージャまたはクライアントプログラムからの通信を待ち，(a) ローカルマネージャから通信のあったときは，当該ローカルマネージャの存在するホストコンピュータの情報を受け取り，その情報に基づき定められた関係で優先度を求め，(b) クライアントプログラムから通信のあったときは，メッセージを受信し，リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択し前記メッセージをフォワードするようにして，リモートプロシージャコールサーバプログラムを呼び出すことができるようにしたことを特徴とする。」
　
Ｃ．「【０００８】
【作用】サーバプログラムが存在するホストコンピュータ（Ｂ，Ｃ）のローカルマネージャからは，自身のホストコンピュータの性能を，グローバルマネージャの存在するホストコンピュータ（Ａ）へ送信すると共に，ホストコンピュータ（Ｂ，Ｃ）のロードアベレージを一定周期ごとに送信する。ホストコンピュータ（Ａ）では，初期化の後通信待ちに入り，ローカルマネージャからの通信の場合は，当該ホストコンピュータの性能やロードアベレージを受け取って管理テーブルに格納し，管理テーブルを参照してホストコンピュータの優先度を求めておく。クライアントプログラムからの通信の場合は，リモートプロシージャコール対象のサーバプログラムのあるホストコンピュータの内で最も優先度の高いホストコンピュータを選択し，クライアントプログラムからのメッセージを選択されたホストコンピュータのポートへ送る。このような管理により，リモートプロシージャコールにおいて最適なサーバプログラムを選択することができる。」
　
Ｄ．「【００１２】ホスト管理テーブル３は，・・・各ホストの情報［すなわち処理能力（性能とも言う）とロードアベレージ（負荷とも言う）］を保持しておく領域であり，グローバルマネージャ１が管理する。このホスト管理テーブル３には例えば図３のように，ホストエントリ番号，ホストアドレス，性能，ロードアベレージ，優先度に関する情報が登録される。
・・・（中略）・・・
【００１９】ローカルマネージャからの通信に関する処理とは，グローバルマネージャ１のローカルマネージャに関する処理であって，図７に示すように，ホスト情報（性能）を受信した場合にはそのホスト情報をホスト管理テーブル３へ登録する。この登録終了後あるいは初めにホスト情報を受信しなかった場合には，次のロードアベレージ受信に移る。ロードアベレージが受信されるとそれをホスト管理テーブル３へ登録する。登録終了後あるいはロードアベレージを受信しなかった場合には，続いて優先度の再計算を行なう。優先度の計算は次の式に従う。各ホストの性能をＸ（０≦Ｘ≦１０），ロードアベレージをＹ（０≦Ｙ≦１０）とすると，優先度Ｐは，
Ｐ＝ωX Ｘ＋ωY Ｙ
で与えられる。ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示しており，適宜に設定される。また，ローカルマネージャ５（６）は，立ち上げ時に処理能力Ｘの値をグローバルマネージャ１に送信し，また定期的にロードアベレージＹの値をグローバルマネージャ１に送信する。」
　
（Ａ）上記Ｂ．の「複数のホストコンピュータがネットワークを通して接続され，リモートプロシージャコールサーバプログラムが複数のホストコンピュータに存在するシステム」に関し，当該「システム」は，「ローカルマネージャを備え」，「このローカルマネージャは自身が属するホストコンピュータの性能を前記グローバルマネージャへ送信」する「サーバプログラムの存在するホストコンピュータ（当審注：以下，「ローカルマネージャ・ホストコンピュータ」と呼ぶ。）」と，「他のホストコンピュータにあるクライアントプログラムからのリクエストを受けるとサーバホストコンピュータの性能や負荷に基づき適切なホストコンピュータを選択し，当該ホストコンピュータのサーバプログラムへメッセージをフォワードするグローバルマネージャを備え」た「あるホストコンピュータ（当審注：以下，「グローバルマネージャ・ホストコンピュータ」と呼ぶ。）」を備えていることは，上記Ｂ．の記載，及び，図１からも明らかである。
　よって，引用文献１から，
「ローカルマネージャ自身が属するローカルマネージャ・ホストコンピュータの性能をグローバルマネージャ・ホストコンピュータへ送信するサーバプログラムの存在するローカルマネージャ・ホストコンピュータと，ローカルマネージャ・ホストコンピュータの性能や負荷に基づき適切なホストコンピュータを選択し，当該ローカルマネージャ・ホストコンピュータのサーバプログラムへメッセージをフォワードするグローバルマネージャを備えたグローバルマネージャ・ホストコンピュータとを含むシステム」をよみとることができる。
　
（Ｂ）前記（Ａ）の「ローカルマネージャ・ホストコンピュータ」に関し，上記Ｂ．に「サーバプログラムおよび自身のホストコンピュータの情報を前記グローバルマネージャに送信する」，及び，「自身が属するホストコンピュータの性能を前記グローバルマネージャへ送信し，その後は一定周期でロードアベレージをグローバルマネージャへ送信し」との記載があり，また前記「ローカルマネージャ・ホストコンピュータ」が「送信」する「性能」及び「ロードアベレージ」に関し，上記Ｄ．の「各ホストの性能をＸ（０≦Ｘ≦１０），ロードアベレージをＹ（０≦Ｙ≦１０）とする」，及び，「ローカルマネージャ５（６）は，立ち上げ時に処理能力Ｘの値をグローバルマネージャ１に送信し，また定期的にロードアベレージＹの値をグローバルマネージャ１に送信する」との記載から，前記「ローカルマネージャ・ホストコンピュータ」から「送信」される「各ホストの性能」Ｘ及び「ロードアベレージ」Ｙは，それぞれ正規化して生成されてから送信されていることは明らかである。
　よって，引用文献１から，
「前記ローカルマネージャ・ホストコンピュータは，それぞれホストの性能Ｘ（０≦Ｘ≦１０），ロードアベレージＹ（０≦Ｙ≦１０）を正規化して生成し，自身が属するホストコンピュータの性能Ｘを前記グローバルマネージャ・ホストコンピュータへ送信し，その後は一定周期でロードアベレージＹをグローバルマネージャ・ホストコンピュータへ送信」することをよみとることができる。
　
（Ｃ）前記（Ａ）の「グローバルマネージャ・ホストコンピュータ」に関し，上記Ｂ．に「前記グローバルマネージャは，前記管理テーブルを初期化した後前記ローカルマネージャまたはクライアントプログラムからの通信を待ち，(a) ローカルマネージャから通信のあったときは，当該ローカルマネージャの存在するホストコンピュータの情報を受け取り，その情報に基づき定められた関係で優先度を求め」，及び，「(b) クライアントプログラムから通信のあったときは，メッセージを受信し，リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択し前記メッセージをフォワードするようにして，リモートプロシージャコールサーバプログラムを呼び出す」との記載があり，また前記「(a)」の記載事項における「その情報に基づき定められた関係で優先度を求め」るとは，上記Ｄ．の優先度Ｐの計算についての「続いて優先度の再計算を行なう。優先度の計算は次の式に従う。各ホストの性能をＸ（０≦Ｘ≦１０），ロードアベレージをＹ（０≦Ｙ≦１０）とすると，優先度Ｐは，Ｐ＝ωX Ｘ＋ωY Ｙ　で与えられる。ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示しており」との記載によれば，「優先度Ｐ＝ωX Ｘ＋ωY Ｙ（ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示す）に基づいて再計算を行なって優先度を求め」ることと解される。
　よって，引用文献１には，
「グローバルマネージャ・ホストコンピュータは，管理テーブルを初期化した後前記ローカルマネージャ・ホストコンピュータまたはクライアントプログラムからの通信を待ち，(a)ローカルマネージャ・ホストコンピュータから通信のあったときは，当該ローカルマネージャ・ホストコンピュータの存在するホストコンピュータの情報であるロードアベレージを受け取り，優先度Ｐ＝ωX Ｘ＋ωY Ｙ（ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示す）に基づいて再計算を行なって優先度を求め，(b)クライアントプログラムから通信のあったときは，メッセージを受信し，リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択し前記メッセージをフォワードするようにして，リモートプロシージャコールサーバプログラムを呼び出す」ことが示されている。
　
　以上（Ａ）〜（Ｃ）をふまえれば，引用文献１には，異なるホスト上で動く同じ機能のサーバプログラムを効率を含めて管理すること（上記Ａ．の記載参照）を目的とした次の発明（以下，「引用文献１発明」という。）が示されている。　
　
「ローカルマネージャ自身が属するローカルマネージャ・ホストコンピュータの性能をグローバルマネージャ・ホストコンピュータへ送信するサーバプログラムの存在するローカルマネージャ・ホストコンピュータと，ローカルマネージャ・ホストコンピュータの性能や負荷に基づき適切なホストコンピュータを選択し，当該ホストコンピュータのサーバプログラムへメッセージをフォワードするグローバルマネージャを備えたグローバルマネージャ・ホストコンピュータとを含むシステムであって，
　前記ローカルマネージャ・ホストコンピュータは，
　それぞれホストの性能Ｘ（０≦Ｘ≦１０），ロードアベレージＹ（０≦Ｙ≦１０）を正規化して生成し，自身が属するホストコンピュータの性能Ｘを前記グローバルマネージャ・ホストコンピュータへ送信し，その後は一定周期でロードアベレージＹをグローバルマネージャ・ホストコンピュータへ送信し，
　グローバルマネージャ・ホストコンピュータは，
　管理テーブルを初期化した後前記ローカルマネージャ・ホストコンピュータまたはクライアントプログラムからの通信を待ち，(a)ローカルマネージャ・ホストコンピュータから通信のあったときは，当該ローカルマネージャ・ホストコンピュータの存在するホストコンピュータの情報であるロードアベレージを受け取り，優先度Ｐ＝ωX Ｘ＋ωY Ｙ（ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示す）に基づいて再計算を行なって優先度を求め，
　(b)クライアントプログラムから通信のあったときは，メッセージを受信し，リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択し前記メッセージをフォワードするようにして，リモートプロシージャコールサーバプログラムを呼び出すことを特徴とするシステム。」
　　
（３．２．３）引用文献２
　原審が，平成２４年８月２８日付の拒絶理由に引用した，本願出願前に頒布された刊行物である特開２０００−３２２３６５号公報（以下，「引用文献２」という。）には，図１とともに次の事項が記載されている。
　
ａ．「【０００３】
【発明が解決しようとする課題】上記従来技術によれば，クライアントからの処理要求に対して処理プロセス数のみで受付制限するため，クライアントからの処理要求によってかかる負荷が軽くサーバの処理能力に余裕がある状態でも処理プロセス数の上限に達すると新たなクライアントからの処理要求の受付を拒否することになる。逆にサーバにかかる負荷が重くサーバの処理能力に余裕がない状態でも処理プロセス数の上限に達しなければ新たなクライアントからの処理要求を受け付けてしまい，クライアントに対するレスポンス性能を悪化させるという問題がある。
【０００４】本発明の目的は，直接的にサーバの負荷状態に基づいてクライアントからの処理要求を受付制限することによって従来技術の問題を解決することにある。」
　
ｂ．「【００１０】負荷状態値２３は，サーバ２の負荷状態を示す数値であり，サーバ２の平均リソース利用率から計算される。サーバ２の平均リソース利用率は次の式によって計算される。平均リソース利用率＝ウェイト１×ＣＰＵ利用率＋ウェイト２×メモリ使用率＋ウェイト３×ディスク使用率＋ウェイト４×ネットワーク利用率＋ウェイト５×データベースの同時アクセス数＋・・・ここでＣＰＵ，メモリ，ディスク，ネットワークなどはハードウェア・リソースであり，利用率や使用率は０から１００までの範囲の数値とする。またデータベースの同時アクセス数は，ソフトウェア・リソースの使用状況を示す数値であり，その上限を１００とする数値に変換されているものとする。ウェイト１，２，３，・・・は０から１までの範囲の数とし，ウェイト１，ウェイト２，・・・などすべてのウェイトの合計が１になるものとする。負荷状態値２３は平均リソース利用率の実用上の上限を例えば１００に正規化するように変換された数値とする。例えば平均リソース利用率の実用上の上限を８０％とすれば，平均リソース利用率０，４０，８０，１００の１次変換はそれぞれ負荷状態値０，５０，１００，１２５となる。」
　
　上記ａ．及びｂ．の記載によれば，引用文献２には，
　クライアントからの処理要求を受付けるサーバにおいて，生成した複数種類の正規化リソース値（上記ｂ．の「ＣＰＵ，メモリ，ディスク，ネットワークなどはハードウェア・リソースであり，利用率や使用率は０から１００までの範囲の数値」との記載）の加重平均（上記ｂ．の「平均リソース利用率＝ウェイト１×ＣＰＵ利用率＋ウェイト２×メモリ使用率＋ウェイト３×ディスク使用率＋ウェイト４×ネットワーク利用率＋ウェイト５×データベースの同時アクセス数＋・・・ここでＣＰＵ，メモリ，ディスク，ネットワークなどはハードウェア・リソースであり，利用率や使用率は０から１００までの範囲の数値・・・（中略）・・・データベースの同時アクセス数は，ソフトウェア・リソースの使用状況を示す数値であり，その上限を１００とする数値に変換されている」との記載）を自身の稼動状況値（上記ｂ．の「負荷状態値」との記載）とする技術，及び，そのための具体的構成（図１中，負荷検知部２５，負荷状態値算出部２６）が示されている。
　
（３．２．４）対比
　本件補正発明と引用文献１発明とを対比する。
　
ア．引用文献１発明の「グローバルマネージャ・ホストコンピュータ」は，「優先度Ｐ＝ωX Ｘ＋ωY Ｙ・・・に基づいて再計算を行」い，「(b)クライアントプログラムから通信のあったときは，メッセージを受信し，リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択し前記メッセージをフォワードするようにして，リモートプロシージャコールサーバプログラムを呼び出す」ことにより，「ネットワーク上にリモートプロシージャコールのサーバプログラムグラムが複数個存在する時に，クライアントプログラムがサーバプログラムから効率よくリターンバリューを返してもらうために，一番適切なサーバプログラムを呼び出すこと」（上記Ａ．の段落【０００５】）を実現するものであるから，「負荷分散を行うグローバルマネージャ・ホストコンピュータ」，及び，「負荷分散を実現するグローバルマネージャ・ホストコンピュータ」とみることができ，それぞれ，本件補正発明の「負荷分散を行う負荷分散装置」，及び，「負荷分散を実現する負荷分散装置」に相当する。
　また，引用文献１発明の「ローカルマネージャ・ホストコンピュータ」は「ロード（負荷。上記Ｄ．を参照）アベレージＹをグローバルマネージャ・ホストコンピュータへ送信」することから，本件補正発明の「自身の負荷状況を通知する負荷状況通知サーバ」に相当する。
　これらの点を加味すれば，引用文献１発明の「ローカルマネージャ自身が属するローカルマネージャ・ホストコンピュータの性能をグローバルマネージャ・ホストコンピュータへ送信するサーバプログラムの存在するローカルマネージャ・ホストコンピュータと，ローカルマネージャ・ホストコンピュータの性能や負荷に基づき適切なホストコンピュータを選択し，当該ホストコンピュータのサーバプログラムへメッセージをフォワードするグローバルマネージャを備えたグローバルマネージャ・ホストコンピュータとを含むシステム」と，本件補正発明の「負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システム」との間に，実質的な差異はない。
　
イ．引用文献１発明の「ローカルマネージャ・ホストコンピュータの性能や負荷（ロードアベレージ）」に関し，当該性能（「処理能力」）や負荷はＣＰＵやメモリなどに関するものであり，実質的にはリソースについての「リソース値」とみることができ，「ローカルマネージャ・ホストコンピュータ」に存在する「サーバプログラム」も「リソース」であり，少なくとも「ロードアベレージ」Ｙは「稼動状況値」とみることができる。
　してみると，
　引用文献１発明の「前記ローカルマネージャ・ホストコンピュータは，
　それぞれホストの性能Ｘ（０≦Ｘ≦１０），ロードアベレージＹ（０≦Ｙ≦１０）を正規化して生成し，自身が属するホストコンピュータの性能Ｘを前記グローバルマネージャ・ホストコンピュータへ送信し，その後は一定周期でロードアベレージＹをグローバルマネージャ・ホストコンピュータへ送信」することと，
　本件補正発明の「前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備」することとは，
「前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　正規化リソース値を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備」する点で共通するといえる。
　
ウ．引用文献１発明の「グローバルマネージャ・ホストコンピュータ」は，「(a)」において「ローカルマネージャ・ホストコンピュータから通信」があると「当該ローカルマネージャ・ホストコンピュータの存在するホストコンピュータの情報であるロードアベレージを受け取」り「再計算を行なって優先度を求め」，「(b)」において「リモートプロシージャコールサーバプログラムの存在するホストコンピュータを探し，そのうちで最も優先度の高いホストコンピュータを選択」するものであるが，上記「(a)」において「ローカルマネージャ・ホストコンピュータから通信」がなされる際に受け取る「当該ローカルマネージャ・ホストコンピュータの存在するホストコンピュータの情報であるロードアベレージ」に変動があれば，それを用いて計算される「優先度」，及び，上記「(b)」の「最も優先度の高いホストコンピュータ」の「選択」内容が変更されることは自明な事項であり，これは，「ローカルマネージャ・ホストコンピュータから通信」される「ホストコンピュータの情報であるロードアベレージ」に基づいて負荷分散の形態を変更しているものともいえる。
　してみると，引用文献１発明の「グローバルマネージャ・ホストコンピュータ」が，「(a)ローカルマネージャ・ホストコンピュータから通信のあったときは，当該ローカルマネージャ・ホストコンピュータの存在するホストコンピュータの情報であるロードアベレージを受け取り，優先度Ｐ＝ωX Ｘ＋ωY Ｙ（ただし，ωX ＋ωY ＝１であり，ωX ，ωY の値は性能とロードアベレージのどちらに比重を置くかを示す）に基づいて再計算を行なって優先度を求め」ることと，本件補正発明の「前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更すること」とは，
「前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の形態を変更すること」である点で共通するといえる。
　
　上記ア．〜ウ．の対比によれば，本件補正発明と引用文献１発明とは次の事項を有する発明である点で一致し，そして相違する。
　
〈一致点〉　
「負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　正規化リソース値を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の形態を変更することを特徴とする負荷分散システム。」
　
〈相違点１〉
　負荷状況通知サーバにおける，自身の稼動状況値である正規化リソース値の負荷分散装置への通知に関し，
　本件補正発明は，「導出手段」を備え当該「導出手段」により「生成した複数種類の正規化リソース値の加重平均を導出」し，「導出された前記加重平均」を通知するものであるのに対し，引用文献１発明は，そのような構成について特定していない点。
　
〈相違点２〉
　本件補正発明が，「前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御」しているのに対し，引用文献１発明は，そのような構成について特定していない点。
　
〈相違点３〉
　本件補正発明が，各負荷状況通知サーバから通知される前記稼動状況値に基づいて，「前記負荷分散の重み付けを変更する」ものであるのに対し，引用文献１発明は，そのような特定はしていない点。
　
（３．２．５）当審判断
〈相違点１〉について
　引用文献２には，クライアントからの処理要求を受付けるサーバにおいて，生成した複数種類の正規化リソース値の加重平均を自身の稼動状況値とする技術，及び，そのための具体的構成が示されている。
　してみれば，引用文献１発明における自身の稼動状況値の通知として，「導出手段」を備え当該手段により「生成した複数種類の正規化リソース値の加重平均を導出」し，「導出された前記加重平均」を通知するようにすること，すなわち相違点１に係る構成とすることは，前記引用文献２に記載の技術的事項を参酌することにより当業者が容易になし得ることである。
　よって，相違点１は格別なものではない。
　
〈相違点２〉について
　引用文献１には，正規化したリソース値に対する一連の処理の制御に関し，異常検出の有無による処理の進行について具体的記載はない。
　しかしながら，一般に，処理の制御において「異常が検出されない場合」に通常の処理を進行させるようにすることは当業者にとって技術常識であり，そして，前記「〈相違点１〉について」で検討した如く，引用文献１発明に対し引用文献２に記載の技術的事項を参酌して「導出手段」を備えるよう構成する際に，上記技術常識を勘案することで，「前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御」すること，すなわち相違点２に係る構成とすることは，当業者が容易になし得ることである。
　よって，相違点２は格別なものではない。
　
〈相違点３〉について
　本件補正発明の請求項に記載の「前記負荷分散の重み付けを変更する」とは，本願の発明の詳細な説明も参酌すると，負荷の振り分けに用いられる各サーバに対し設定した値の変更であると理解できるところ，引用文献１発明における「優先度」も，各ローカルマネージャ・ホストコンピュータの存在するホストコンピュータに対し計算され負荷の振り分けに用いられるとともに，「ロードアベレージ」の変動によって当然に変更されるものであるから，この点において本件補正発明と引用文献１発明の間に実質的な相違はなく，また，本願の先行文献として提示された特開２００９−１４０２１２号（特に段落【００１９】〜【００２４】）にも記載されているとおり，普通に行われていた技術事項と認められるから，いずれにしても，上記相違点３によって進歩性は見出せない。
　よって，相違点３は格別なものではない。
　
　そして，本件補正発明の構成により奏する効果も，引用文献１発明，及び引用文献２に記載の技術的事項等から当然予測される範囲内のもので，格別顕著なものとは認められない。
　
　したがって，本件補正発明は，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものである。
　
３．補正却下むすび
　以上検討したとおり，本件補正は，特許法第１７条の２第３項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　仮に，本件補正が，当初明細書等の記載の範囲内でなされたものであるとしても，特許法第１７条の２第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　仮に，本件補正が，当初明細書等の記載の範囲内でなされ，補正の目的要件を満たすものであるとしても，本件補正発明は，特許法第１７条の２第６項で準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，上記補正却下の決定の結論のとおり決定する。
　
　
第３．本願発明について
　
１．平成２５年６月１７日付の手続補正は前記のとおり却下されたので，本願の請求項１に係る発明は，平成２４年１０月１９日付の手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。（再掲する。以下「本願発明」という。）
　
「負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって，
　前記負荷状況通知サーバは，
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と，
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，
　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と
　を具備し，
　前記負荷分散装置は，
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更することを特徴とする負荷分散システム。」
　
２．引用刊行物
　原審の拒絶の理由に引用された，本願出願前に頒布された刊行物である，前記引用文献１には，前記（３．２．２）の項で摘記した事項が記載されている。
　また，原審の拒絶の理由に引用された，本願出願前に頒布された刊行物である，前記引用文献２には，前記（３．２．３）の項で摘記した事項が記載されている。
　
３．対比・判断
　本願発明は，前記（３．２．４）（３．２．５）で検討した本件補正発明における発明特定事項である，「
前記生成手段，前記導出手段，及び前記通知手段が，異常が検出されない場合に定期的に実行されるように制御し，
　そうすると，本願発明の構成要件をすべて含み，さらに他の構成要件を付加したものに相当する本件補正発明が，前記（３．２．４）（３．２．５）に記載したとおり，引用文献１に記載された発明，及び，引用文献２に記載された技術事項に基いて，当業者が容易に発明をすることができたものであるから，本願発明も，同様の理由により，引用文献１に記載された発明，及び，引用文献２に示された技術事項に基いて，当業者が容易に発明をすることができたものである。
　
　そして，本願発明の構成により奏する効果も，引用文献１に記載された発明，及び，引用文献２に記載された技術事項から当然予測される範囲内のもので，格別顕著なものとは認められない。
　
　
第４．回答書の補正案について
　
　なお，請求人は，前記平成２６年１月２８日付け回答書において，
　
「［請求項１］ 
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバと，前記各負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置と，備えた負荷分散システムであって， 
　前記負荷状況通知サーバは， 
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と， 
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と 
　を具備し， 
　
前記負荷状況通知サーバは，
　前記生成手段，前記導出手段，及び前記通知手段
を
前記生成手段，前記導出手段，及び前記通知手段のそれぞれにおける処理の実行中に
，
し，
　前記負荷分散装置は， 
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更することを特徴とする負荷分散システム。 
［請求項５］ 
　負荷分散を行う負荷分散装置に対して自身の負荷状況を通知する負荷状況通知サーバからの通知に基づき，負荷分散を実現する負荷分散装置を制御するプログラムであって， 
　前記負荷状況通知サーバは，　
　複数のリソースの各々について，リソース値を正規化し，正規化リソース値を生成する生成手段と， 
　生成した複数種類の正規化リソース値の加重平均を導出する導出手段と，　導出された前記加重平均を自身の稼動状況値として前記負荷分散装置に通知する通知手段と 
　を具備し， 
　
前記負荷状況通知サーバは，
　前記生成手段，前記導出手段，及び前記通知手段
を
前記生成手段，前記導出手段，及び前記通知手段のそれぞれにおける処理の実行中に
に，
するものであり，
　前記プログラムは， 
　前記負荷分散装置を， 
　各負荷状況通知サーバから通知される前記稼動状況値に基づいて，前記負荷分散の重み付けを変更する手段として機能させることを特徴とするプログラム。」
　
　との補正案を提示しているが，上記「第２」「２．」「（３）」「（３．２）」「（３．２．５）」の「〈相違点２〉について」でも検討したとおり，一般に，処理の制御において「異常が検出されない場合」に通常の処理を進行させるようにすることは当業者にとって技術常識であり，そして，引用文献１発明に対し引用文献２に記載の技術的事項を参酌して「ローカルマネージャ・ホストコンピュータ」が「導出手段」を備えるよう構成する際に，上記技術常識を勘案することで，「前記負荷状況通知サーバ」が「前記生成手段，前記導出手段，及び前記通知手段を，前記生成手段，前記導出手段，及び前記通知手段のそれぞれにおける処理の実行中に異常が検出されない場合に，定期的に実行」するようにすることは，当業者が容易になし得ることである。
　したがって，仮に本願特許請求の範囲が，該補正案のとおりのものとなったとしても，本審決の結論に影響するものではない。
　
　
第５．むすび
　以上のとおりであるから，本願発明は，特許法第２９条第２項の規定により特許を受けることができないものであり，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。
　
　よって，結論のとおり審決する。