【事件の表示】
　特願２００７−３１５６５５「通信中継装置、サーバ、クライアント、ネットワークシステム、及び通信方法」拒絶査定不服審判事件〔平成２１年　６月２５日出願公開、特開２００９−１４０２１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１９年１２月６日の出願であって、平成２２年７月１３日付けで拒絶理由通知がなされ、同年９月１６日付けで手続補正がなされたが、同年１０月１５日付けで拒絶査定がなされ、これに対し、平成２３年１月１３日に拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
２．平成２３年１月１３日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２３年１月１３日付けの手続補正を却下する。
　
［理由］
（１）補正後の請求項１に係る発明
　
　平成２３年１月１３日付けの手続補正（以下、「本件手続補正」という。）は、補正前の請求項１を引用する請求項２に記載された発明を,補正後の請求項１に記載された発明に補正することを含むものである。
　ここで、補正前の請求項１，２の記載と補正後の請求項１の記載は、次のようなものである。
　
（補正前の請求項１，２の記載）
「　【請求項１】　ネットワーク上に接続された複数のサーバから稼働状況に関する情報を取得するサーバ稼働状況監視部と、
　前記稼働状況に関する情報から前記複数のサーバ全体の使用電力量を求め、該使用電力量に基づいて、当該稼働状況において最低限必要なサーバ数を求めるサーバ使用電力量監視部と、
　前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰のコマンドを送信するサーバ遠隔操作部と、
　前記稼働状況に関する情報に基づき、通信リクエストの振り分け先サーバを、前記サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する負荷分散部と、
　前記ネットワーク上に接続されたクライアントからの通信リクエストを受信し、前記振り分け先サーバに送信する通信部と
を備え、
　前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を取得し、
　前記サーバ使用電力量監視部は、前記ＣＰＵ負荷の情報に基づき、前記各サーバの使用電力量を求め、
　前記ＣＰＵ負荷の最大時におけるサーバ１台あたりの使用電力量に対する、前記複数のサーバの使用電力量の合計値の割合に、前記サーバの負荷の余裕を示す係数であって１以上の値である余裕度を乗算した値に基づき、当該稼働状況において最低限必要な前記サーバ数を求めることを特徴とする通信中継装置。
　【請求項２】　前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を取得し、
　前記負荷分散部は、前記複数のサーバのＣＰＵ負荷が均等になるように、前記振り分け先サーバを選択することを特徴とする請求項１記載の通信中継装置。」
　
（補正後の請求項１の記載）
「ネットワーク上に接続された複数のサーバから稼働状況に関する情報を取得するサーバ稼働状況監視部と、
　前記稼働状況に関する情報から前記複数のサーバ全体の使用電力量を求め、該使用電力量に基づいて、当該稼働状況において最低限必要なサーバ数を求めるサーバ使用電力量監視部と、
　前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰のコマンドを送信するサーバ遠隔操作部と、
　前記稼働状況に関する情報に基づき、通信リクエストの振り分け先サーバを、前記サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する負荷分散部と、
　前記ネットワーク上に接続されたクライアントからの通信リクエストを受信し、前記振り分け先サーバに送信する通信部と
を備え、
　前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を
定期的に
　前記サーバ使用電力量監視部は、前記ＣＰＵ負荷の情報に基づき、前記各サーバの使用電力量を求め、
　前記ＣＰＵ負荷の最大時におけるサーバ１台あたりの使用電力量に対する、前記複数のサーバの使用電力量の合計値の割合に、前記サーバの負荷の余裕を示す係数であって１以上の値である余裕度を乗算した値に基づき、当該稼働状況において最低限必要な前記サーバ数を
定期的に
、
前記負荷分散部は、前記複数のサーバのＣＰＵ負荷が均等になるように、前記振り分け先サーバを選択する
　
　上記補正は、補正前の請求項１を引用する請求項２に記載された発明における「前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を取得し」を「前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を定期的に取得し」に、「当該稼働状況において最低限必要な前記サーバ数を求め」を「当該稼働状況において最低限必要な前記サーバ数を定期的に求め」に限定するものであって、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件手続補正後の上記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第５項の規定に適合するか）について、以下に検討する。
　
　
（２）引用例及び周知例
　原査定の拒絶の理由に引用された特表２００６−５０８４４５号公報（以下、「引用例１」という。）、特開２００５−１８２７０２号公報（以下、「引用例２」という。）、及び原査定の備考欄において周知例として引用された特開２００６−１０６８５９号公報（以下、「周知例」という。）には、それぞれ、図面とともに次の事項が記載されている。（下線は当審付与。）
　
（引用例１）
Ａ．「【００３５】
　次に、より詳細に添付図面を参照すると、
図１は、本発明の省電力化概念が使用される例示的なアプリケーション・サービスのトポロジを示している。図１のアプリケーション・サービスは、Ｗｅｂサーバ１００と、ネットワーク・ディスパッチャ１０１および１０２からなる。ネットワーク・ディスパッチャ１０１および１０２は、ＷｅｂサーバにＷｅｂ要求を配布するロード・バランシング・コンポーネントとして機能する
複数のＷｅｂサーバ１００は、Ｗｅｂページを供給する機能を実行するものであり、機能的に同一である。ネットワーク・ディスパッチャ１０１は、インターネットからＷｅｂページに関する要求を受信し、その要求をＷｅｂサーバ１００に転送する。Ｗｅｂサーバ１００は、個々の要求を処理し、インターネット上のクライアントに個々の応答を返送する。
【００３６】
　
負荷（ロード）という用語は、単位時間あたりネットワーク・ディスパッチャ１０１に到着する要求の数として定義することができる。好ましい実施形態によれば、アプリケーション・サービスにかかる負荷が小さい場合、アプリケーション・サービスから特定のサーバを除去することにより、アプリケーション・サービスに使用するサーバの数が削減される。その場合、アプリケーション・サービスから除去されたサーバのサブセットによって消費される電力の量を制御することにより、電力が削減される。さらに、アプリケーション・サービスがワークロードに応じるために十分なオンライン・パワーオン容量に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン容量を有するように、任意の所与の層のサーバに関する冗長管理ポリシーが実現される。図１に示す例の場合、アプリケーション・サービスにかかる負荷が非常に小さい場合、たとえば、複数のＷｅｂサーバのうちの１つをパワーオフすることにより、アプリケーション・サービスに使用するＷｅｂサーバ１００の数を、たとえば、３から２に削減することができる。さらに、複数のＷｅｂサーバを完全にパワーオフするのではなく、スタンバイ、スリープ、ハイバネート、およびその他の省電力化状態およびモードなどの業界標準の半（semi）パワーオン状態または超低電力状態のうちの１つに電力状態を設定することにより、電力を節約することも可能である。
【００３７】
　図２は、アプリケーション・サービスで同一機能を実行する複数冗長サーバの層に含まれるサーバの設備および動作状態を示している。サーバは、そのサーバが経験するワークロードに応じて、アプリケーション・サービスのアクティブ状態２０１と自由プール２０２との間で移動する。アクティブ状態２０１は、サーバがアプリケーション・サービスに従事している完全パワーオン状態である。自由プール２０２内のサーバは、考慮中の特定のアプリケーション・サービスで非アクティブになっている。前述の通り、アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量に加え、１つまたは複数の追加のサーバの形で特定の量のスペア・オンライン・パワーオン容量を保証する冗長管理ポリシーが実現される。このようなスペア・オンライン・パワーオン・サーバは、ホット・スタンバイ・サーバと呼ばれる。この冗長管理ポリシーにより、自由プール２０２の特定の数のサーバがホット・スタンバイ状態２０３に保持される。
このようなホット・スタンバイ・サーバは、アプリケーション・サービスでは非アクティブであるが、アプリケーション・サービスに対するワークロード要求が所定のしきい値を超える場合に素早くアクティブ状態２０１に用意することができる。電力を削減するために、ホット・スタンバイ状態で保持されない自由プール２０２のサーバは、低電力状態２０５に設定することができる。
　好ましい実施形態では、アクティブ状態２０１と自由プール２０２との間ならびに自由プール内のホット・スタンバイ状態２０３と低電力状態２０５との間でサーバを移行するときに、アプリケーション・サービスのトポロジも考慮に入れる。トポロジの決定は多くの形を取ることができ、本明細書では様々な例が示されることになる。しかし、これらの例は、本発明の範囲を制限するものと解釈すべきではない。第１の例としてのトポロジの決定は、アプリケーション・サービスで現在アクティブのサーバの総数を決定するという形を取ることができる。もう１つの例のトポロジの決定は、それぞれのサーバの個々の正常性（health）を決定するという形を取ることができる。正常性を決定する際に、トポロジの決定は、残りのメモリの量あるいはメモリ、ＣＰＵ、入出力（Ｉ／Ｏ）、または任意のその他のシステム・リソースが枯渇している程度に焦点を合わせることができる。正常性を決定する際に、特定のオペレーティング・システムは時々リセット（リブート／再始動）する必要があることは周知のことであり、したがって、トポロジの決定は、任意の所与のサーバがリセットされてから経過した時間の総量に焦点を合わせることができる。また、いかなる種類のシステム・ボトルネックも考慮に入れることができる。
【００３９】
　さらに他の例では、アプリケーション・サービスは仮想サーバ環境で動作する。仮想サーバ環境では、必ずしも仮想サーバと物理サーバとの間に１対１の対応（通信）が存在するわけではない。この環境では、トポロジの決定は、物理サーバが２つ以上の機能を実行しているかどうかまたは物理サーバが２つ以上の層の冗長サーバに関係しているかどうかを考慮することになる。たとえば、１つの物理サーバは、数百もの仮想Ａｐａｃｈｅサーバを実行している可能性がある。この例では、すべてのＡｐａｃｈｅサーバが同じ層内で動作しており、冗長なものである。さらに他の例では、物理サーバは、プロキシ・キャッシュ層またはネットワーク・ディスパッチャ層などの複数の層の仮想アプリケーションを実行することができる。この仮想サーバ環境では、あるサーバを低電力状態２０５に設定する前に、任意の所与の物理サーバ内のすべての仮想サーバのトポロジを考慮に入れ、物理サーバによって実行される仮想関数のすべてが自由プール２０２内にあり、ホット・スタンバイ状態２０３になっていると判定されない限り、物理サーバをパワーダウンしない。適切なワークロードの決定およびトポロジの決定が行われ、アプリケーション・サービスの要求に応じるために十分な数のホット・スタンバイ・サーバが自由プール内に存在すると判定されると、その場合のみ、物理サーバは低電力状態に設定されるかまたは完全にパワーオフされることになる。
【００４０】
　次に、トポロジの決定およびワークロードの決定のより具体的な例を示す。この例では、各関数型あたりホット・スタンバイ状態２０３に保持すべきサーバの数は以下のパラメータによって定義される。この場合、関数型は複数冗長サーバの層によって実行される関数を指す。
　ｍｉｎＨｏｔＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール内のこの関数型の最小数のホット・スタンバイ・サーバを設定するための規定を提供する。
　
ａｄｄＯｎｌｉｎｅＲａｔｉｏ−このパラメータは、アプリケーション・サービスに積極的に関与するこの関数型のサーバの数と、ホット・スタンバイ状態２０３に保持されるであろうこの関数型の追加サーバの数との所望の比率を表す。たとえば、１００個のサーバがアプリケーション・サービスに積極的に関与しており、ａｄｄＯｎｌｉｎｅＲａｔｉｏの値が２０である場合、この特定のアプリケーション・サービスは、自由プール２０２内に１００／２０＝５個のホット・スタンバイ・サーバを必要とすることになるであろう。自由プール２０２内の全サーバが１５であった場合、残りの１５−５＝１０個のサーバはパワーオフするか、あるいは低電力動作モードに設定することができる。
　ｈｏｔＳｅｒｖｅｒｓＩｎＦｒｅｅＰｏｏｌ−このパラメータは、自由プール２０２内にあるべきサーバの数を表す。」
　
Ｂ．「【００４５】
  
図３は、好ましい一実施形態の教示による電力および冗長管理ポリシーの流れ図である。ステップ３０１では、複数冗長サーバの層の各サーバのワークロードが決定される。任意の所与のサーバのワークロードは、全体としてアプリケーション・サービスにかかる負荷に直接関連し、さらにサーバ固有の属性（attribute）に依存する。サーバのワークロードの決定は、当技術分野では周知のものであり、したがって、これ以上詳細に説明しない。
【００４６】
  アプリケーション・サービスにかかる負荷が所定の高負荷しきい値および低負荷しきい値を超えるかまたはそれらに適合しない場合、サーバの移行が必要になる。いずれのしきい値にも適合しない場合、処理はステップ３０１に続く。これに対して、一方のしきい値に適合する場合、処理はステップ３０５に続き、そこで以下の基準に従ってサーバが移動する。ステップ３０５では、ステップ３０１で決定された低負荷時に、アプリケーション・サービスのサーバがアプリケーション・サービスから自由プール２０２内に移動する。逆に、ステップ３０１で決定された高負荷時に、サーバが自由プール２０２からアプリケーション・サービス内に移動して戻る。
【００４７】
  
次に、処理はステップ３０７および３０８に続き、そこで上述の電力管理ポリシーが適用される。ステップ３０７では、ステップ３０５でサーバに対して行われる１回または複数回の移行により自由プール２０２のサーバに加えられた電力に関して判断が行われる。自由プール２０２のサーバに加えられた電力の現行レベルが十分なものであり、いかなる変更も不要であると判定された場合、処理はステップ３０１に続く。これに対して、より多くのサーバをホット・スタンバイ・モードにする必要があるかまたはより少ないサーバが必要であると判定された場合、処理はステップ３０８に続き、そこで１つまたは複数のサーバの電力操作レベルが設定される。ステップ３０８では、上記で論じた電力管理ポリシーが適用される。上述の通り、これらのポリシーでは、ステップ３０１および３０２で決定されたワークロードおよびトポロジを考慮に入れる。
【００４８】
  
図４は、ハードウェア装置４００として実現された本発明の代替実施形態を示している。装置４００は、上述した通り、また以下に詳述する通り、サーバ４０９の電力をモニターし、感知し、移動し、制御する。サーバ４０９は、これまでに述べたサーバのいずれかまたは複数サーバの層のいずれかにすることができる。装置４００は、ワークロード・モニター４０１と、トポロジ・センサ４０２と、移動モジュール４０５と、電力コントローラ４０８からなり、本明細書で上述した電力および冗長管理ポリシーを実現する。ワークロード・モニター４０１は、それぞれのサーバ４０９のワークロードを決定し、図３に関してステップ３０１で述べた機能を類似的に実行する。
電力コントローラ４０８は、それぞれのサーバ４０９の電力設定を制御し、図３に関してステップ３０７および３０８で述べた機能を類似的に実行する。さらに、装置４００は、サーバ４０９に結合されたときに本明細書で上述した機能を実行する単一ユニットとして実現することができる。
　
（ｉ）上記Ａ．に記載されているように、ホット・スタンバイ・モードは、アプリケーション・サービスに対するワークロード要求が所定のしきい値を超える場合に素早くアクティブ状態に用意することができるようにするためのものであることから、アクティブ状態の（アプリケーション・サービスに積極的に関与する）サーバ及びホット・スタンバイ状態のサーバ（以下、いずれかの状態のサーバを「パワーオン状態であるサーバ」という。）は、実質的にアプリケーション・サービスのワークロード要求に応じるために最低限必要なサーバであるといえる。
（ｉｉ）上記Ａ．には、アプリケーション・サービスがワークロードに応じるために十分なオンライン・パワーオン容量を有するようにすることが記載されている。さらに、上記Ａ．には、アプリケーション・サービスにかかる負荷が非常に小さい場合、たとえば、複数のＷｅｂサーバのうちの１つをパワーオフすることにより、アプリケーション・サービスに使用するＷｅｂサーバの数を削減することも記載されている。
（ｉｉｉ）上記Ａ．には、アプリケーション・サービスに積極的に関与するこの関数型のサーバの数と、ホット・スタンバイ状態２０３に保持されるであろうこの関数型の追加サーバの数との所望の比率を表すパラメータを用いて、サーバはパワーオフするか、あるいは低電力動作モードに設定することが記載されている。
（ｉｖ）複数のｗｅｂサーバ（サーバ）がネットワークを介してネットワーク・ディスパッチャに接続されていることは上記Ａ．及び図１から明らかである。さらに、上記Ａ．の「ネットワーク・ディスパッチャ１０１および１０２は、ＷｅｂサーバにＷｅｂ要求を配布するロード・バランシング・コンポーネントとして機能する。」及び「ネットワーク・ディスパッチャ１０１は、インターネットからＷｅｂページに関する要求を受信し、その要求をＷｅｂサーバ１００に転送する。」という記載から、ネットワーク・ディスパッチャは実質的に、ロード・バランシング・コンポーネントと、インターネットからＷｅｂページに関する要求を受信し、その要求をＷｅｂサーバに転送する通信手段とを有しているといえる。
（ｖ）上記Ｂ．には、ハードウェア装置として実現する場合には、ワークロード・モニターと電力コントローラとを有すること、ワークロード・モニターは、それぞれのサーバのワークロードを決定すること、及び、任意の所与のサーバのワークロードは、全体としてアプリケーション・サービスにかかる負荷に直接関連することが記載されている。上記Ｂ．にはさらに、電力コントローラは、それぞれのサーバの電力設定を制御することも記載されている。また、上記Ａ．には、アプリケーション・サービスは、Ｗｅｂサーバ（サーバ）と、ネットワーク・ディスパッチャからなることが記載されているが、このような構成の場合、ワークロード・モニター及び電力コントローラの機能は、ネットワーク・ディスパッチャ側に備えられることは明らかである。
　
　よって、上記Ａ．及びＢ．の記載及び関連する図面を参照すると、引用例１には、実質的に、次のような発明が記載されているものと認められる。（以下、「引用例１記載の発明」という。）
　
「ネットワーク上に接続された複数のサーバに対する、アプリケーション・サービスにかかる負荷をモニターするワークロード・モニターと、
　アプリケーション・サービスにかかる負荷から、アプリケーション・サービスがワークロード要求に応じるために十分なオンライン・パワーオン容量を求め、パワーオン状態であるサーバ数、すなわちアプリケーション・サービスのワークロード要求に応じるために最低限必要なサーバ数を決定する手段と、
　前記パワーオン状態であるサーバ数に基づいて、１又は複数の前記サーバを低電力状態とするか否かを設定する電力コントローラと、
　サーバにＷｅｂ要求を配布するロード・バランシング・コンポーネントと、
　インターネット上のクライアントからのＷｅｂ要求を受信し、その要求をＷｅｂサーバに転送する通信手段と
を有し、
　前記ワークロード・モニター、及び、前記アプリケーション・サービスがワークロード要求に応じるために十分なオンライン・パワーオン容量を求め、パワーオン状態であるサーバ数を決定する手段は、前記アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量から、アクティブ状態のサーバの数を決定し、
　前記アクティブ状態のサーバ数と、アクティブ状態のサーバの数に対するホット・スタンバイ状態のサーバの数との所望の比率とから、パワーオン状態であるサーバ数を決定し、
　前記ロード・バランシング・コンポーネントは、サーバに対してＷｅｂ要求を配布する、
　ネットワーク・ディスパッチャ。」
　
　
（引用例２）
Ｃ．「【０００５】
　この方法により，リンク設定時に最も負荷の少ない伝送路を選択してその伝送路にリンクを割り当て，伝送路の負荷に応じてリンクを均等に配分して効率的に複数の伝送路を使用できる。なお，
このように各伝送路（または処理装置）の負荷を計測して，新たな要求に対して負荷の少ない伝送路（処理装置）を選択する機能を備える機構を負荷分散装置（またはロードバランサ）と呼ばれる。
　一方，動的オブジェクトを再利用でき，トラヒックの軽減を図ると共にユーザに与える負担を軽減できて快適にサービスを受けることができるネットワークアクセス制御方法及びそれを用いたネットワークシステム及びそれを構成する装置が提案されている（特許文献２参照）。その提案された方法の中にインターネットサービスプロバイダが受付代行サービスを行う構成が含まれ，その方法の概要を従来例２の構成として図１０に示す。
【０００７】
　図１０の構成では，
ＩＰネットワーク（インターネット）６０にインターネットサービスプロバイダの複数台のサービスサーバ６１ａ〜６１ｃがルータ等のネットワーク装置６１ｅ及び負荷分散装置（ロードバランサと呼ばれる場合もある）６１ｄを介して接続され，サービスサーバ６１へのトラヒックが集中した場合に備えて，アクセス制御サーバ（または受付サーバ）６２を設けたものである。
【０００８】
　(1) 
サービスサーバ６１が快適にユーザ端末６４からの要求を処理できるか否かの情報として，ＣＰＵの使用率が閾値を越えた時に，アクセス制御サーバ６２に高負荷状態であることを通知する
【０００９】
　(2) １台のサービスサーバから高負荷通知を受けたアクセス制御サーバ６２は，その他のサービスサーバが低負荷で処理余力があったとしても，ネットワーク装置６１ｅに対してユーザ端末の要求を待合せサーバ６３に迂回するよう指示する。」
　
Ｄ．「【００１８】
　アクセス制御サーバ１の安定運用管理ＤＢ１７には，予め保守端末１９から負荷分散装置５による負荷分散のための各種の条件（応答時間，優先度，重み，等）や数値を画面を見ながら設定を行うと，安定運用設定変更部１８により安定運用管理ＤＢ１７に格納される。負荷分散装置情報収集部１２はこの安定運用管理ＤＢ１７に設定された項目について，定期的にＩＰネットワーク４を介して負荷分散装置５が管理している情報を要求し，負荷分散装置５から収集した情報を状態管理ＤＢ１６に格納し，安定運用管理部に収集完了の通知を行う。安定運用管理部１３は状態管理ＤＢ１６から収集結果を参照し，参照結果で規定値をオーバーした値や変化が大きい値があると，詳細なデータを収集するため負荷分散装置情報収集部１２に追加のデータ収集の要求を行い，追加して収集したデータは状態管理ＤＢ１６に登録する。また，
収集した情報を元にサービスサーバの負荷（一つのサービスサーバ６内の複数のサーバＡ〜Ｃの負荷）を均一にするため負荷分散装置５の設定を変更する必要があると判断した場合
　
Ｅ．「【００２２】
　本発明により，負荷分散装置を制御する機能を備えることで，負荷分散装置を必要とするサービスサーバを備える施設の資源を有効に利用してユーザサービスを提供することが
できる。また，
サービスサーバの負荷状況やトラヒック状況を定期的に監視する
　
　上記Ｃ．等には、処理装置の負荷を計測して，新たな要求に対して負荷の少ない処理装置を選択する機能を備える機構をロードバランサと呼ぶこと、インターネットに複数台のサービスサーバがロードバランサを介して接続されること、及び、サービスサーバが快適にユーザ端末からの要求を処理できるか否かの情報として，ＣＰＵの使用率が閾値を越えた時に，高負荷状態であることを通知することが記載されている。
　また、上記Ｄ．には、収集した情報を元にサービスサーバの負荷を均一にするため負荷分散装置の設定を変更する必要があると判断することが記載されている。
　さらに、上記Ｅ．には、サービスサーバの負荷状況を定期的に監視することが記載されている。
　よって、上記Ｃ．乃至Ｅ．の記載及び関連する図面を参照すると、引用例２には、実質的に、次のような発明が記載されているものと認められる。（以下、「引用例２記載の発明」という。）
　
「サービスサーバから通知された、前記サービスサーバの負荷状況等を定期的に監視し、収集した情報を元にサービスサーバの負荷を均一にするため、必要に応じて設定を変更する必要があるかを判断する、新たな要求に対して負荷の少ない処理装置を選択する機構を備えるロードバランサ。」
　
　
（周知例）
Ｆ．「【０００２】
　例えば、図５に示すように、
企業のネットワーク（インターネット）１上に公開されたＷｅｂサイトに採用される情報処理システム２においては、多数のクライアント（顧客  消費者）３からの同一ＩＰアドレス（ＵＲＬ）を指定したアクセス要求（処理要求）に短時間で応答するために、１台のサーバ負荷分散装置（ロードバランサー）４と複数台のサーバ５とが組込まれている。
【０００３】
　サーバ負荷分散装置４は、各クライアント３からネットワーク（インターネット）１を介して入力された同一ＩＰアドレス（ＵＲＬ）を指定した複数のアクセス要求（処理要求）を各サーバ５に割り振る。処理要求が割り振られたサーバ５は、自己のＷｅｂ処理部６で処理要求が指定する例えばホームページ閲覧に応じるホームページ送信等の処理を実行する。
【０００４】
　なお、各サーバ５は、同時に複数の処理を実施可能である。同時にＭ個の処理が可能であれば、ｎ個のサーバ５が情報処理システム２に組込まれていた場合は、この情報処理システム２で同時に（Ｍ×ｎ）個のクライアント３からの処理要求に応じることが可能である。
【０００５】
　このような情報処理システム２においては、
サーバ負荷分散装置４へ入力される処理要求数は、一定でなく、時間、曜日に応じて大きく変動する。したがって、常時、全部のサーバ５を動作状態にすることはなく、その時点の処理要求数Ａに応じて運転するサーバ数Ｅを１台分余裕を見越して次のように決めておく。
　
Ｅ＝（Ａ／Ｍ）＋１このサーバ数Ｅ分のサーバ５のみを運転（動作）状態にする。
【０００７】
　なお、特許文献１に、各負荷ユニット（サーバ）の負荷率を算出して、負荷率の小さい負荷ユニット（サーバ）に新規の負荷要求を送信する技術が開示されている。
【特許文献１】特開２００１―７５９３４号公報」
　
　上記Ｆ．には、インターネット上に公開されたＷｅｂサイトに採用される情報処理システムにおいては、多数のクライアントからの同一ＩＰアドレスを指定した処理要求に短時間で応答するために、１台のサーバ負荷分散装置と複数台のサーバとが組込まれていること、及び、入力される処理要求数が、一定でなく、時間、曜日に応じて大きく変動するような場合、その時点の処理要求数に応じて運転するサーバ数を余裕分を見越して決めておくことが記載されている。
　よって、上記Ｆ．の記載及び関連する図面を参照すると、周知例には、実質的に、次の技術が記載されているものと認められる。（以下、「周知例記載の技術」という。）
　
「入力される処理要求数が、一定でなく、時間、曜日に応じて大きく変動するような場合、その時点の処理要求数に応じて運転するサーバ数を余裕分を見越して決めておくサーバ負荷分散装置。」
　
　
（３）対比
　本願補正発明と引用例１記載の発明とを対比すると、次のことがいえる。
　
（あ）本願補正発明における「（ネットワーク上に接続された）複数のサーバ全体の使用電力量」と、引用例１記載の発明における「ワークロード」とは、ネットワーク上に接続された複数のサーバ全体の負荷という点で、共通するものである。
　また、本願補正発明における「当該稼働状況において最低限必要なサーバ数」と、引用例１記載の発明における「パワーオン状態であるサーバ数、すなわちアプリケーション・サービスのワークロード要求に応じるために最低限必要なサーバ数」とは、上記複数のサーバ全体の負荷に対して最低限必要なサーバ数、という点で共通するものである。
　よって、本願補正発明と引用例１記載の発明とは、ともに、「ネットワーク上に接続された複数のサーバ全体の負荷に対して最低限必要なサーバ数を求める手段」を備えるという点において、共通するものである。
　
（い）引用例１記載の発明において、「サーバを低電力状態とするか否かを設定する」ことは、本願補正発明において、「サーバに対し、サスペンド移行又はサスペンド復帰」を設定することに相当する。
　よって、本願補正発明における「前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰のコマンドを送信するサーバ遠隔操作部」と、引用例1記載の発明における「前記パワーオン状態であるサーバ数に基づいて、１又は複数の前記サーバを低電力状態とするか否かを設定する電力コントローラ」とは、「前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰を設定する手段」という点で、共通するものである。
　
（う）引用例１記載の発明における「Ｗｅｂ要求」は、本願補正発明における「通信リクエスト」に相当する。そして、引用例１記載の発明において、「サーバにＷｅｂ要求を配布する」ことは、本願補正発明において、「通信リクエストの振り分け先サーバを選択する」ことに相当する。
　よって、本願補正発明における「前記稼働状況に関する情報に基づき、通信リクエストの振り分け先サーバを、前記サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する負荷分散部」と、引用例１記載の発明における「サーバにＷｅｂ要求を配布するロード・バランシング・コンポーネント」とは、「通信リクエストの振り分け先サーバを選択する負荷分散部」という点で、共通するものである。
　
（え）引用例１記載の発明における「インターネット上のクライアント」、「Ｗｅｂ要求」、「Ｗｅｂサーバに転送する通信手段」は、それぞれ、本願補正発明における「ネットワーク上に接続されたクライアント」、「通信リクエスト」、「振り分け先サーバに送信する通信部」に相当する。
　よって、引用例１記載の発明における「インターネット上のクライアントからのＷｅｂ要求を受信し、その要求をＷｅｂサーバに転送する通信手段」は、本願補正発明における「前記ネットワーク上に接続されたクライアントからの通信リクエストを受信し、前記振り分け先サーバに送信する通信部」に相当する。
　
（お）本願補正発明における「前記ＣＰＵ負荷の情報に基づき、前記各サーバの使用電力量を求め、前記ＣＰＵ負荷の最大時におけるサーバ１台あたりの使用電力量に対する、前記複数のサーバの使用電力量の合計値の割合に、前記サーバの負荷の余裕を示す係数であって１以上の値である余裕度を乗算した値に基づき、当該稼働状況において最低限必要な前記サーバ数を・・・求め」ることと、引用例１記載の発明における「前記アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量から、アクティブ状態のサーバの数を決定し、前記アクティブ状態のサーバ数と、アクティブ状態のサーバの数に対するホット・スタンバイ状態のサーバの数との所望の比率とから、パワーオン状態であるサーバ数を決定」することとは、サーバ全体の負荷に対して、所定の余裕を持たせてサーバ全体の負荷に対して必要なサーバ数を求めること、という点で共通するものである。
　
（か）引用例１記載の発明における「ネットワーク・ディスパッチャ」と、本願補正発明における「通信中継装置」とは、通信中継及びロード・バランシングの機能を有する装置という点で共通するものである。
　
　上記（あ）〜（か）の事項を踏まえると、本願補正発明と引用例１記載の発明とは、
　
「ネットワーク上に接続された複数のサーバ全体の負荷に対して最低限必要なサーバ数を求める手段と、
　前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰を設定する手段と、
　通信リクエストの振り分け先サーバを選択する負荷分散部と、
　前記ネットワーク上に接続されたクライアントからの通信リクエストを受信し、前記振り分け先サーバに送信する通信部と
を備え、
　前記最低限必要なサーバ数を求める手段は、サーバ全体の負荷に対して、所定の余裕を持たせてサーバ全体の負荷に対して必要なサーバ数を求め、
　前記ロード・バランシングを行う手段は、振り分け先サーバを選択する、
通信中継及びロード・バランシングの機能を有する装置。」　
の点で一致し、次の点で相違する。
　
相違点１：「ネットワーク上に接続された複数のサーバ全体の負荷に対して最低限必要なサーバ数を求める手段」が、本願補正発明においては、「ネットワーク上に接続された複数のサーバから稼働状況に関する情報を取得するサーバ稼働状況監視部」及び「前記稼働状況に関する情報から前記複数のサーバ全体の使用電力量を求め、該使用電力量に基づいて、当該稼働状況において最低限必要なサーバ数を求めるサーバ使用電力量監視部」よりなるものであるのに対し、引用例１記載の発明においては、上記のような「サーバ稼働状況監視部」及び「サーバ使用電力量監視部」よりなるものであるとはされていない点。
　
相違点２：「前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰を設定する手段」が、本願補正発明においては、「前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰のコマンドを送信するサーバ遠隔操作部」であるのに対し、引用例１記載の発明においては、「コマンド」を送信する「サーバ遠隔操作部」であるとはされていない点。
　
相違点３：「通信リクエストの振り分け先サーバを選択する負荷分散部」が、本願補正発明においては、「前記稼働状況に関する情報に基づき、通信リクエストの振り分け先サーバを、前記サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する負荷分散部」であるのに対し、引用例１記載の発明においては、単に「サーバにＷｅｂ要求を配布するロード・バランシング・コンポーネント」としかされていない点。
　
相違点４：本願補正発明においては、「最低限必要なサーバ数を求める手段」の「サーバ使用電力量監視部」が「前記ＣＰＵ負荷の情報に基づき、前記各サーバの使用電力量を求め」ているのに対し、引用例１記載の発明においてはそのようなものであるとはされていない点。
　
相違点５：「最低限必要なサーバ数を求める手段」が、本願補正発明においては、「ＣＰＵ負荷の最大時におけるサーバ１台あたりの使用電力量に対する、前記複数のサーバの使用電力量の合計値の割合に、前記サーバの負荷の余裕を示す係数であって１以上の値である余裕度を乗算した値」に基づいて「当該稼働状況において最低限必要なサーバ数」を求めているのに対して、引用例１記載の発明では、アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量から、アクティブ状態のサーバの数を決定し、前記アクティブ状態のサーバ数と、アクティブ状態のサーバの数に対するホット・スタンバイ状態のサーバの数との所望の比率とから、パワーオン状態であるサーバ数を決定している点。
　
　相違点６：本願補正発明においては、「稼働状況に関する情報」を取得すること、及び、「最低限必要なサーバ数」を求めること、を「定期的に」行うのに対して、引用例１記載の発明は、そのようなものであるとはされていない点。
　
（４）判断
（相違点１について）
　上記引用例２記載の発明に見られるように、サーバから通知された負荷状況等を定期的に監視し、サーバの稼働状況に関する情報を取得するようにすることは、公知の技術である。
　そして、サーバの負荷状況を使用電力量により表すようにすることは、適宜になし得ることにすぎないから、サーバの稼働状況として複数のサーバ全体の使用電力量を求め、該使用電力量から最低限必要なサーバ数を求めるようにすることは、当業者が適宜になし得ることにすぎない。
　よって、引用例１記載の発明に対して上記引用例２記載の発明を参酌し、「ネットワーク上に接続された複数のサーバ全体の負荷に対して最低限必要なサーバ数を求める」ことを「ネットワーク上に接続された複数のサーバから稼働状況に関する情報を取得するサーバ稼働状況監視部」及び「前記稼働状況に関する情報から前記複数のサーバ全体の使用電力量を求め、該使用電力量に基づいて、当該稼働状況において最低限必要なサーバ数を求めるサーバ使用電力量監視部」により行うことは、当業者が適宜になし得ることにすぎない。
　
（相違点２について）
　一般に、情報処理分野において、「コマンド」を用いて「遠隔操作」を行うことは、ごく普通に行われていることにすぎない。
　よって、引用例１記載の発明において、「前記パワーオン状態であるサーバ数に基づいて、１又は複数の前記サーバを低電力状態とするか否かを設定する電力コントローラ（前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰を設定する手段）」を「前記サーバ数に基づいて、１又は複数の前記サーバに対し、サスペンド移行又はサスペンド復帰のコマンドを送信するサーバ遠隔操作部」とすることは、当業者が適宜なし得ることにすぎない。
　
（相違点３について）
　引用例１記載の発明における「ロード・バランシング・コンポーネント」は、そもそも、サーバの負荷をサスペンド状態でないサーバにバランスよく分散させるものなのであるから、「通信リクエストの振り分け先サーバ」を、「稼働状況に関する情報」に基づいて「サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する」ようにすることは、当業者がごく自然に考えることにすぎない。また、処理要求数が一定でない場合、その時点の処理要求数に応じて運転するサーバ数を余裕分を見越して決めておくことは、周知例に記載されているように、当業者が適宜なし得ることにすぎない。
　よって、引用例１記載の発明において、「サーバにＷｅｂ要求を配布するロード・バランシング・コンポーネント（通信リクエストの振り分け先サーバを選択するロード・バランシングを行う手段）」を「前記稼働状況に関する情報に基づき、通信リクエストの振り分け先サーバを、前記サスペンド移行コマンドが送信されたサーバ以外の前記サーバから選択する負荷分散部」とすることは、当業者が容易に想到し得ることである。
　
（相違点４について）
　本願補正発明における「使用電力量」とは、明細書を参照すると、ＣＰＵ負荷に定数を乗じたものであるとされている（段落【００３３】〜【００３５】）。してみると、本願補正発明における「使用電力量」は、単位こそ違うものの、実質的には引用例１記載の発明における「オンライン・パワーオン容量」と実質的に差異はない。そして、引用例１の段落【００３６】にも記載されているように、負荷が小さいと必要な電力が削減されることは技術常識であることから、必要なサーバ数を求める中途において、「オンライン・パワーオン容量」を電力量に換算することは当業者が適宜になし得ることである。
　
（相違点５について）
　「アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量」に対して必要なサーバ台数を求める際に、「アプリケーション・サービスのワークロード要求に応じるために十分なオンライン・パワーオン容量」をサーバ１台あたりの最大の処理能力で割ることは、台数を求める際に当然行うことであり、当業者が適宜なし得ることである。
　また、余裕に関する係数を、アクティブ状態のサーバ数とホットスタンバイ状態のサーバ数との所望の比率とするか、アクティブ状態のサーバ数とパワーオン状態とすべきサーバ数との比率とするかは、発明を実施する際に当業者が適宜選択し得る事項にすぎない。
　
（相違点６について）
　引用例２記載の発明のロードバランサは、サービスサーバから通知された、前記サービスサーバの負荷状況等を定期的に監視し、収集した情報を元にサービスサーバの負荷を均一にするにするため、必要に応じて設定を変更する必要があるかを判断している。
　ここで、引用例１記載の発明と引用例２記載の発明とは、ロードバランサという共通の技術分野に属するものであるから、引用例１記載の発明に対して引用例２記載の発明を適用し、ネットワーク上に接続された複数のサーバ全体の負荷に対して最低限必要なサーバ数を求める手段が、サーバの負荷状況を定期的に収集し、前記負荷情報を元にサーバの負荷を均一にするため、負荷分散装置の設定を変更する必要があるかを定期的に判断するよう構成することは、当業者が容易に想到し得ることである。
　
　
（本願補正発明の作用効果について）
　そして、本願補正発明の構成によってもたらされる効果も、引用例１，２記載の発明及び周知例記載の技術から当業者が容易に予測できるものであって、格別のものとはいえない。
　
　したがって、本願補正発明は、引用例１，２記載の発明及び周知例記載の技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
　
（５）むすび
　よって、本件手続補正は、平成２３年法律第６３号改正附則第２条第１８項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第６項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
　
３．補正却下の決定を踏まえた検討
（１）本願発明
　平成２３年１月１３日付けの手続補正は、上記のとおり却下されたので、本願の請求項１を引用する請求項２に記載された発明（以下、「本願発明」という。）は、上記２．（１）において「補正前の請求項１，２の記載」として摘記した、平成２２年９月１６日付け手続補正書の特許請求の範囲の請求項１を引用する請求項２に記載されたとおりものと認める。
　
（２）引用例
　これに対して、原査定の拒絶の理由に引用された引用例とその記載事項は、上記２．（２）に示したとおりである。
　
（３）本願発明は、上記２．で検討した本願補正発明における
「前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を
定期的に
定期的に
「前記サーバ稼働状況監視部は、前記稼働状況に関する情報として前記サーバのＣＰＵ負荷の情報を取得し」、「当該稼働状況において最低限必要な前記サーバ数を求め」とし、
「負荷分散部」に関する「
前記負荷分散部は、前記複数のサーバのＣＰＵ負荷が均等になるように、前記振り分け先サーバを選択する
　そうすると、本願発明の構成要素を全て含み、さらに特定の限定を施したに相当する本願補正発明が、上記２．（４）に記載したとおり、引用例１，２の発明及び周知技術に基いて、当業者が容易に発明することができたものであることから、上記特定の限定を省いた本願発明は、同様に引用例１，２の発明及び周知技術に基いて、当業者が容易に発明することができたものである。
　
　
（４）むすび
　以上のとおり、本願発明は、引用例１，２記載の発明及び周知例記載の発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。