【事件の表示】
　特願２００３−２０７００２「負荷制御方法および装置並びにその処理プログラム」拒絶査定不服審判事件〔平成１７年　３月１０日出願公開、特開２００５−　６２９２７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯 
　本願は、平成１５年８月１１日の出願であって、平成１９年６月２２日付けで拒絶理由通知がなされ、同年９月３日付けで手続補正がなされたが、平成２０年２月２５日付けで拒絶査定がなされ、これに対し、同年４月２日に審判請求がなされるとともに同年４月２５日付けで手続補正がなされたものである。そして、同年１０月２日付けで審査官から前置報告がなされ、平成２２年２月２４日付けで当審より審尋がなされ、同年４月２８日付けで回答書が提出されたものである。
　 
第２．平成２０年４月２５日付けの手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
　平成２０年４月２５日付けの手続補正を却下する。 
　 
［理由］ 
１．補正の内容
　平成２０年４月２５日付けの手続補正（以下、「本件補正」という。）の内容は、
　平成１９年９月３日付けの手続補正により補正された特許請求の範囲の請求項１の記載
　
「【請求項１】
　クライアントから送られた業務のリクエストを処理するための複数の業務処理装置と、該リクエストを受信して前記業務処理装置のそれぞれの負荷を分散するように前記業務処理装置に該リクエストを送信する負荷分散装置とを有する計算機システムにおける負荷分散方法において、
　負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，前記業務処理装置にて実行されている階層的な構造を有する複数の業務は、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている業務の構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務のうちの一つである第１の業務に対応しており、当該第１の業務が所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送り、
　前記負荷分散装置は、前記送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務を実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、
　前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務を実行するとともに、該第１の業務の実行に伴い複数の業務処理装置のそれぞれの業務の実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送り、
　前記負荷分散装置は、前記第１のリクエストの処理結果を受信すると、該第１のリクエスの処理結果を前記負荷制御装置に送り、
　前記負荷制御装置は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送るとともに、前記第１のリクエストの処理に費やされた時間を算出し、
さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする負荷分散方法。」（以下、この特許請求の範囲の請求項１を「補正前の請求項１」という。）を、
　
「【請求項１】
　クライアントから送られた業務のリクエストを処理するための複数の業務処理装置と、該リクエストを受信して前記業務処理装置のそれぞれの負荷を分散するように前記業務処理装置に該リクエストを送信する負荷分散装置とを有する計算機システムにおける負荷分散方法において、
　予め、前記業務処理装置は、ＵＲＬと業務プラグラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをしれぞれ格納し、
　負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，前記業務処理装置にて実行されている前記階層的な構造を有する複数の業務プログラムは、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務プログラムのうちの一つである第１の業務プログラムに対応しており、当該第１の業務プログラムが所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送り、
　前記負荷分散装置は、前記送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務プログラムを実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、
　前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い複数の業務処理装置におけるそれぞれの前記業務プログラムの実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送り、
　前記負荷分散装置は、前記第１のリクエストの処理結果を受信すると、該第１のリクエストの処理結果を前記負荷制御装置に送り、
　前記負荷制御装置は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送るとともに、前記第１のリクエストの処理に費やされた時間を算出し、さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする負荷分散方法。」
（以下、この特許請求の範囲の請求項１を「補正後の請求項１」という。）
　
　に補正することを含むものである。
　
　なお、上記補正後の請求項１における記載「予め、前記業務処理装置は、ＵＲＬと業務
プラグラム
しれぞれ
プログラム
それぞれ
　
　「【請求項１】
　クライアントから送られた業務のリクエストを処理するための複数の業務処理装置と、該リクエストを受信して前記業務処理装置のそれぞれの負荷を分散するように前記業務処理装置に該リクエストを送信する負荷分散装置とを有する計算機システムにおける負荷分散方法において、
　予め、前記業務処理装置は、ＵＲＬと業務
プログラム
それぞれ
　負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，前記業務処理装置にて実行されている前記階層的な構造を有する複数の業務プログラムは、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務プログラムのうちの一つである第１の業務プログラムに対応しており、当該第１の業務プログラムが所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送り、
　前記負荷分散装置は、前記送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務プログラムを実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、
　前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い複数の業務処理装置におけるそれぞれの前記業務プログラムの実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送り、
　前記負荷分散装置は、前記第１のリクエストの処理結果を受信すると、該第１のリクエストの処理結果を前記負荷制御装置に送り、
　前記負荷制御装置は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送るとともに、前記第１のリクエストの処理に費やされた時間を算出し、さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする負荷分散方法。」
　 
２．補正の適否
２−１．特許法第１７条の２第３項に規定する要件についての検討
　補正後の請求項１は、その記載からして、次の事項（ａ）を含んでいる。
　 
（ａ）予め、前記業務処理装置は、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納する態様を含むこと。
　
　（ａ）について検討する。
　願書に最初に添付した明細書又は図面には、「予め、前記業務処理装置は、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納する態様」について、記載も示唆もなく、また自明な事項でもない。
　したがって、補正後の請求項１に記載された（ａ）の事項は、出願当初の明細書又は図面に記載されておらず、かつ、その記載から自明なものでもないから、上記事項を追加する本件補正は、出願当初の明細書又は図面に記載した範囲内でしたものではないので、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例とされる同法による改正前の特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
２−２．特許法第１７条の２第４項に規定する要件についての検討 
　仮に、本件補正が、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであると仮定した場合に、本件補正が特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものであるかどうかについて以下に検討する。
　補正後の請求項１は、その記載からして、前記「２−１．特許法第１７条の２第３項に規定する要件についての検討」において指摘した発明特定事項（ａ）を含んでいる。
　  
　そこで、（ａ）について検討する。
　補正前の請求項１には、「…前記業務処理装置にて実行されている階層的な構造を有する複数の業務は、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている業務の構成となっており、…」と記載されている。
　したがって、補正前の請求項１における「業務処理装置」は、階層的な構造を有する複数の業務を有し、その階層構造はＵＲＬで表され、複数の業務は複数のＵＲＬに割り付けられている、階層的な構造を有する複数の業務を有すると認められる。
　しかしながら、前記（ａ）における記載「予め、前記業務処理装置は、ＵＲＬと業務プログラムとの対応付けを複数入力すると、…　ディレクトリ階層に前記プログラムをそれぞれ格納する」については、業務処理装置において、前記階層的な構造を有する複数の業務を有する態様を限定したものでなく、「ＵＲＬと業務プログラムとの対応付けを複数入力する」手段を前記業務処理装置に新たに追加するものであって、そうすることで、前記「階層的な構造を有する複数の業務」を前記記憶手段に予め格納するための入力をどのようにするか、という新たな課題が追加されていると認められる。
　
　したがって、前記補正前の請求項１についてする補正（補正後の請求項１）は、補正前の請求項１に記載した発明を特定するために必要な事項を限定したものではなく、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものとは認められない。
　なお、補正前の請求項１についてする補正が、特許法第１７条の２第４項第１号の請求項の削除、第３号の誤記の訂正、第４号の明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）に該当するものではないことは明らかである。
　以上のとおり、補正前の請求項１についてする補正は、仮に、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであると仮定した場合であっても、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものであり、したがって、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。  
　  
２−３．独立特許要件
　仮に、前記補正前の請求項１についてする補正が、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであると仮定した場合であって、さらに、特許法第１７条の２第４項第２号の特許請求の範囲の限定的減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の利用分野及び解決しようとする課題が同一であるもの）を目的とするものであると仮定した場合に、本件補正後の前記請求項１に記載された発明（以下、「補正後の発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）以下に検討する。
　
（１）補正後の発明
　前記補正前の請求項１についてする補正により、補正後の発明は、前記「１．補正の内容」に記載された、以下のものと認められる。
　
　「クライアントから送られた業務のリクエストを処理するための複数の業務処理装置と、該リクエストを受信して前記業務処理装置のそれぞれの負荷を分散するように前記業務処理装置に該リクエストを送信する負荷分散装置とを有する計算機システムにおける負荷分散方法において、
　予め、前記業務処理装置は、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納し、
　負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，前記業務処理装置にて実行されている前記階層的な構造を有する複数の業務プログラムは、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務プログラムのうちの一つである第１の業務プログラムに対応しており、当該第１の業務プログラムが所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送り、
　前記負荷分散装置は、前記送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務プログラムを実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、
　前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い複数の業務処理装置におけるそれぞれの前記業務プログラムの実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送り、
　前記負荷分散装置は、前記第１のリクエストの処理結果を受信すると、該第１のリクエストの処理結果を前記負荷制御装置に送り、
　前記負荷制御装置は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送るとともに、前記第１のリクエストの処理に費やされた時間を算出し、さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする負荷分散方法。」
　
（２）引用文献 
　原査定の拒絶の理由に引用された特開２００３−１６２４２０号公報（以下、「引用文献１」という。）には、図面とともに次の事項が記載されている。
　 
（ア）「【０００８】なお、ここに言うリソースとは、サーバ装置が格納しているデータ、若しくは、サーバ装置が格納している、当該サーバ装置上で実行されるプログラムあるいはスクリプト等のことである。従って、リクエストとは、所要のデータの送信要求、若しくは、所要のプログラムあるいはスクリプトの実行要求等となるデータのことであり、レスポンスとは、リクエストによって要求された所要のデータ、所要のプログラムあるいはスクリプトの実行結果等のデータのことである。
【０００９】リソース区分とは、サーバ装置が格納しているリソース群を複数のグループに分類したときの個々のグループを表示する論理的概念であって、例えば、ドメインネーム等の識別子によって識別されるウェブサイト、リソースを内包するディレクトリ、木構造をなすデータ構造における子孫を有している節（ノード）、等を挙げることができる。個々のリソースそれ自体が各々のリソース区分と一対一に対応していても構わない。通常、リソース区分を指示するための識別子によって、一の区分と他の区分とを識別することができる。リソース区分を識別する識別子の例としては、ドメインネーム、ＩＰアドレスや、ディレクトリ名、親節を指すポインタ、その他が挙げられる。そして、サーバ装置にもたらされるリクエストには、当該リクエストによって要求されるリソースが属するリソース区分を識別する識別子が含まれていることが普通である。
【００１０】　…（中略）…
【００１１】
【発明の実施の形態】以下、本発明の一実施形態を、図面を参照して説明する。図１に、本実施形態に係るシステムの構成を示す。本システムは、サーバ装置１並びに種々の情報処理装置２がともにインターネット等の情報通信回線網ＮＴに接続されてなるものである。そして、情報処理装置２は、情報通信回線網ＮＴを介してサーバ装置１にリクエストを送信し、当該サーバ装置１に格納されているリソースにアクセスを試みることができる。また、情報処理装置２からのリクエストを受信したサーバ装置１は、当該リクエストを発した情報処理装置２に向けて適宜のレスポンスを送信する機能を有する。
【００１２】本実施形態に係るシステムについて、より具体的に述べる。本システムにおけるサーバ装置１は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆａｒ  Ｐｒｏｔｏｃｏｌ）に則ったリクエストを受け付け、同じくＨＴＴＰに則ってレスポンスを返すウェブサーバとして機能するものである。サーバ装置１には、複数のウェブサイトを構成する種々のデータが格納されている。一例として、図２に示すような４つのウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４を構成するデータがサーバ装置１に格納されているとする。このとき、情報処理装置２からは、４つのウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４を提供する４つのサーバ装置が情報通信回線網ＮＴに接続されているように見える。４つのウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４は、各々異なるドメインネームＤＮによって識別される。通常、情報処理装置２から送信されるＨＴＴＰリクエストには、アクセスの対象となるリソースのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）とともに、当該リソースが属しているウェブサイトのドメインネームＤＮが表示されている（ＨＯＳＴヘッダ）。」
　
（イ）「【００１５】各部の動作について説明する。リソース格納部１１は、種々のリソースを複数のリソース区分に分類して格納する。本実施形態においては、ウェブサイトを構成するための、テキストデータや画像データ等の情報処理装置２に送信されるべきデータや、当該サーバ装置１上で実行されるプログラムやスクリプト等をリソースとして格納している。さらに、これらのリソースを、複数の区分、即ち複数のウェブサイト単位に分類して格納している。各々のリソースとウェブサイトの区分との関連づけの態様については、種々のものが考えられる。例えば、ウェブサイト毎にディレクトリが設けられ、リソースが各ディレクトリ内に格納されることによりウェブサイト単位に分類されるような構成が挙げられる。…（中略）…
【００１６】接続数情報取得部１２は、処理中のリクエストの数に関する情報を含む接続数情報を取得する。本実施形態にあっては、リソースの区分単位、即ちウェブサイト単位で処理中のリクエストの数に関する情報を取得することができるように構成している。詳しくは、当該サーバ装置１が現在処理しているＨＴＴＰリクエストに関する情報が下記処理部１４によって主記憶装置１ｂ若しくは補助記憶装置１ｃ内に適宜に格納されており、これを参照することで個々のリクエストの内容、ウェブサイト単位の処理中のリクエスト数、処理中のリクエストの総数等の情報を取得するようにしている。…（後略）」
　
（ウ）「【００２４】次に、判断部１３が新規リクエストに対応する処理を実行するか否かを判断する際の判断条件の具体例を述べる。図５及び図６に、前記制御接続情報の例を示す。図５に示す例は、各々のリソース区分、即ちウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４に対して、リクエストを受け付けて処理する接続数の上限を設定した例である。この例では、新規のリクエストを受信したとき、これが要求するリソースが属しているウェブサイトについて現在処理中のリクエスト数が上限に達している場合には、当該リクエストに対応した処理を実行しない。…（後略）」
　
（エ）「【００２７】サーバ装置１は、情報処理装置２からのリクエストの送信を待ち受ける（ステップＳ１）。リクエストを受信した（ステップＳ２）とき、当該リクエストによって要求されたリソースが属しているウェブサイトを確認する（ステップＳ３）とともに、当該サーバ装置１が現在処理を行っているリクエストの数に関する情報を含む接続数情報を取得する（ステップＳ４）。この接続数情報取得ステップＳ４で取得される接続数情報の具体的な内容は、上記の接続制限情報の構成にも依存するが、本実施形態では、処理中のリクエストの総数並びに各ウェブサイト単位での処理中のリクエストの数に関する接続数情報を取得する。続いて、接続制限情報を参照して（ステップＳ５）、リクエストに応じた処理を行うか否かを判断する（ステップＳ６）。判断ステップＳ６における判断条件は、例えば上述のような接続制御情報に基づく。リクエストに対応した処理を行う旨の判断がなされた場合には、通常のＨＴＴＰサーバとしての接続処理を実行する（ステップＳ７）。一方で、リクエストに対応した処理を行わない旨の判断がなされた場合には、当該判断がなされた事実に関するエラー情報を生成して前記エラー情報格納部１８に格納する（ステップＳ８）とともに、リクエストを送信してきた情報処理装置２に向けてエラー応答を実施する（ステップＳ９）。」
　
（オ）「【００３１】判断部１３による判断の条件の具体的な設定手段としては、前記新規のリクエストに対応する処理を実行するか否かを判断する条件に関する情報である判断条件情報ＣＩを含む接続制御情報を接続制御情報格納部１５に格納しておくという態様が考えられる。そして、図５に示したように、前記判断条件情報ＣＩが、ウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４の何れか一または何れか二以上に属するリソースに対するリクエストであって処理中のものの数の上限に関するものであるような構成、あるいは、図６に示したように、前記判断条件情報ＣＩが、ウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４の何れか一または何れか二以上に属するリソースに対するリクエストであって処理中のものの数を比較した結果に関するものであるような構成とすることが好適であると言える。」
　
（カ）「【００３９】
【発明の効果】以上に詳述した本発明によれば、複数のリソースに対する複数のリクエストを受け付けて処理するサーバ装置において、リソースの区分単位に、サーバの処理能力を適宜に分配することが可能となる。」
　
　段落【０００９】における記載「リソース区分とは、サーバ装置が格納しているリソース群を複数のグループに分類したときの個々のグループを表示する論理的概念であって、　…　サーバ装置にもたらされるリクエストには、当該リクエストによって要求されるリソースが属するリソース区分を識別する識別子が含まれていることが普通である。」、
段落【００１１】における記載「本システムは、サーバ装置１並びに種々の情報処理装置２がともにインターネット等の情報通信回線網ＮＴに接続されてなるものである。そして、情報処理装置２は、情報通信回線網ＮＴを介してサーバ装置１にリクエストを送信し、当該サーバ装置１に格納されているリソースにアクセスを試みることができる。また、情報処理装置２からのリクエストを受信したサーバ装置１は、当該リクエストを発した情報処理装置２に向けて適宜のレスポンスを送信する機能を有する。」及び段落【００３９】における記載「以上に詳述した本発明によれば、複数のリソースに対する複数のリクエストを受け付けて処理するサーバ装置において、リソースの区分単位に、サーバの処理能力を適宜に分配することが可能となる。」からすると、引用文献１には、情報処理装置から送られたリソースに対するリクエストを処理するためのサーバシステムにおけるリクエスト処理方法であって、前記リソースの属するリソースの区分単位にサーバシステムの処理能力を適宜に分配することを特徴とするリクエスト処理方法に関する発明が記載されていると解される。
　そして、段落【０００８】における記載「ここに言うリソースとは、サーバ装置が格納しているデータ、若しくは、サーバ装置が格納している、当該サーバ装置上で実行されるプログラムあるいはスクリプト等のことである。従って、リクエストとは、所要のデータの送信要求、若しくは、所要のプログラムあるいはスクリプトの実行要求等となるデータのことであり、レスポンスとは、リクエストによって要求された所要のデータ、所要のプログラムあるいはスクリプトの実行結果等のデータのことである。」、段落【０００９】における記載「リソース区分とは、サーバ装置が格納しているリソース群を複数のグループに分類したときの個々のグループを表示する論理的概念であって、例えば、ドメインネーム等の識別子によって識別されるウェブサイト、リソースを内包するディレクトリ、木構造をなすデータ構造における子孫を有している節（ノード）、等を挙げることができる。　…　そして、サーバ装置にもたらされるリクエストには、当該リクエストによって要求されるリソースが属するリソース区分を識別する識別子が含まれていることが普通である。」、段落【００１２】における記載「通常、情報処理装置２から送信されるＨＴＴＰリクエストには、アクセスの対象となるリソースのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）とともに、当該リソースが属しているウェブサイトのドメインネームＤＮが表示されている（ＨＯＳＴヘッダ）。」、及び（イ）の段落【００１５】における記載「例えば、ウェブサイト毎にディレクトリが設けられ、リソースが各ディレクトリ内に格納されることによりウェブサイト単位に分類されるような構成が挙げられる。」を参照すると、前記サーバは、ＵＲＩとリソースとが対応付けられ、前記ＵＲＩに対応するディレクトリ階層に前記リソースがそれぞれ格納された記憶装置を備え、前記サーバにて実行されている階層的な構造を有する複数のリソースは、その階層構造をＵＲＩで表し複数のＵＲＩに割り付けられている構成となっており、リソースに対するリクエストは、前記ＵＲＩを含み、該ＵＲＩに対応する前記階層構造を構成するリソースのうちの一つであるリソースに対応していると解される。
　なお、リソースの区分単位とは、リソース群を複数のグループに分類したときの個々のグループを表示する論理的概念（例えば、ドメインネーム等の識別子によって識別されるウェブサイト、リソースを内包するディレクトリ、木構造をなすデータ構造における子孫を有している節（ノード）、等）を意味する。
　
　段落【００２７】における記載「サーバ装置１は、情報処理装置２からのリクエストの送信を待ち受ける（ステップＳ１）。リクエストを受信した（ステップＳ２）とき、当該リクエストによって要求されたリソースが属しているウェブサイトを確認する（ステップＳ３）とともに、当該サーバ装置１が現在処理を行っているリクエストの数に関する情報を含む接続数情報を取得する（ステップＳ４）。この接続数情報取得ステップＳ４で取得される接続数情報の具体的な内容は、上記の接続制限情報の構成にも依存するが、本実施形態では、処理中のリクエストの総数並びに各ウェブサイト単位での処理中のリクエストの数に関する接続数情報を取得する。続いて、接続制限情報を参照して（ステップＳ５）、リクエストに応じた処理を行うか否かを判断する（ステップＳ６）。判断ステップＳ６における判断条件は、例えば上述のような接続制御情報に基づく。リクエストに対応した処理を行う旨の判断がなされた場合には、通常のＨＴＴＰサーバとしての接続処理を実行する（ステップＳ７）。一方で、リクエストに対応した処理を行わない旨の判断がなされた場合には、当該判断がなされた事実に関するエラー情報を生成して前記エラー情報格納部１８に格納する（ステップＳ８）とともに、リクエストを送信してきた情報処理装置２に向けてエラー応答を実施する（ステップＳ９）。」からすると、前記サーバは、前記情報処理装置から送られた所定のリソースに対するリクエスト（以下、「第１のリソースに対する第１のリクエスト」という）を受信し，当該受信した第１のリクエストに応じた処理を行うか否かを接続制御情報に基づいて判断し、リクエストに対応した処理を行う旨の判断がなされた場合、リクエストに対応した処理を実行させ、リクエストに対応した処理を行わない旨の判断がなされた場合、前記第１のリクエストを送信してきた前記情報処理装置にエラー応答を送信する手段を有していると解される。
　なお、前記サーバは情報処理装置とＴＣＰ／ＩＰを介してデータを送受信していることから、前記サーバはＴＣＰ／ＩＰを介して通信を行う手段（以下、「ＴＣＰ／ＩＰ通信手段」という）を有しており、前記手段と前記ＴＣＰ／ＩＰ通信手段とを合わせて、「リクエスト分配手段」という。
　そして、前記サーバは、リクエストに対応した処理を実行する手段（以下、「処理実行手段」という）を有しており、前記リクエスト分配手段は、前記受信した第１のリクエストに応じた処理を行う旨の判断がなされた場合、前記処理実行手段に前記第１のリクエストを送り、前記処理実行手段から前記第１のリクエストの処理結果を受け取り、情報処理装置に前記処理結果を送信するものと解される。なお、段落【００１５】における記載「リソース格納部１１は、　…　テキストデータや画像データ等の情報処理装置２に送信されるべきデータや、当該サーバ装置１上で実行されるプログラムやスクリプト等をリソースとして格納している。」を参照すると、前記処理実行手段は、前記第１のリソースの実行により、リソース格納部にアクセスすると解される。
　
　そして、段落【００２４】における記載「各々のリソース区分、即ちウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４に対して、リクエストを受け付けて処理する接続数の上限を設定した例である。この例では、新規のリクエストを受信したとき、これが要求するリソースが属しているウェブサイトについて現在処理中のリクエスト数が上限に達している場合には、当該リクエストに対応した処理を実行しない。」、及び段落【００３１】における記載「判断部１３による判断の条件の具体的な設定手段としては、前記新規のリクエストに対応する処理を実行するか否かを判断する条件に関する情報である判断条件情報ＣＩを含む接続制御情報を接続制御情報格納部１５に格納しておくという態様が考えられる。そして、図５に示したように、前記判断条件情報ＣＩが、ウェブサイトＷ１、Ｗ２、Ｗ３、Ｗ４の何れか一または何れか二以上に属するに対するリクエストであって処理中のものの数の上限に関するものであるような構成、…とすることが好適であると言える。」を参照すると、前記受信した第１のリクエストに応じた処理を行うか否かの判断は、前記受信した第１のリクエストに対応する、当該第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数が所定の条件（すなわち、予め設定した、処理中リクエスト数の上限）を満たしているか否かを決定する態様を含むと解される。
　
　以上から、リクエスト分配手段は、情報処理装置から送られた第１のリソースに対する第１のリクエストを受信し、前記受信した第１のリクエストに対応する、当該第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数が、所定の条件を満たしていると判断した場合、処理実行手段へ前記第１のリクエストを送り、前記処理実行手段から前記第１のリクエストの処理結果を受け取ると、情報処理装置に前記第１のリクエストの処理結果を送り、また前記受信した第１のリクエストに対応する、当該第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数が、所定の条件を満たしていないと判断した場合、前記第１のリクエストを送信してきた前記情報処理装置にエラー応答を送信し、
　前記処理実行手段は、前記リクエスト分配手段から送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１のリソースを実行するとともに、該第１のリソースの実行によりアクセスされるリソース格納部にアクセスし、前記第１のリクエストにおける処理が終わると、前記リクエスト分配手段に前記第１のリクエストの処理結果を送ると認められる。
　
　そして、段落【００１６】における記載「接続数情報取得部１２は、処理中のリクエストの数に関する情報を含む接続数情報を取得する。…　詳しくは、当該サーバ装置１が現在処理しているＨＴＴＰリクエストに関する情報が下記処理部１４によって主記憶装置１ｂ若しくは補助記憶装置１ｃ内に適宜に格納されており、これを参照することで個々のリクエストの内容、ウェブサイト単位の処理中のリクエスト数、処理中のリクエストの総数等の情報を取得するようにしている。」を参照すると、前記リクエスト分配手段は、前記情報処理装置から受信した前記第１のリクエストにて要求された前記第１のリソースに関連するＵＲＩで規定されるリソースの区分に属するリソースに対するリクエスト（以下、「第２のリクエスト」という）に対して、前記第２のリクエストにて要求された処理を前記処理実行手段に実行させるか、または実行させずに前記情報処理装置にエラー応答を送信するか、を決定するため、前記リソースの区分に属する個々のリソースに対応する処理中のリクエストの数を利用して前記リソースの区分全てに関連付けられている処理中のリクエストの数を計算すると解される。
　
　したがって、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
　情報処理装置から送られたリソースに対するリクエストを処理するためのサーバシステムにおけるリクエスト処理方法において、
　前記サーバシステムは、ＵＲＩとリソースとが対応付けられ、前記ＵＲＩに対応するディレクトリ階層に前記リソースをそれぞれ格納した記憶装置を備えるとともに、リクエスト分配手段及び処理実行手段を備え、
　前記リクエスト分配手段は、前記情報処理装置から送られた第１のリクエストを受信し，前記処理実行手段にて実行されている階層的な構造を有する複数のリソースは、その階層構造をＵＲＩで表し複数のＵＲＩに割り付けられている構成となっており、当該受信した第１のリクエストは、前記ＵＲＩを含み、該ＵＲＩに対応する前記階層構造を構成するリソースのうちの一つである第１のリソースに対応しており、当該第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数が所定の条件を満たしていると判断した場合、前記処理実行手段へ前記第１のリクエストを送り、所定の条件を満たしていないと判断した場合、前記第１のリクエストを送信してきた前記情報処理装置にエラー応答を送信し、
　前記処理実行手段は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１のリソースを実行するとともに、該第１のリソースの実行によりアクセスされるリソース格納部にアクセスし、前記第１のリクエストにおける処理が終わると前記サーバのリクエスト分配手段に前記第１のリクエストの処理結果を送り、
　前記リクエスト分配手段は、前記送られた第１のリクエストの処理結果を受信すると、前記情報処理装置に処理結果を送り、さらに前記情報処理装置から受信した第１のリクエストにて要求された前記第１のリソースに関連するＵＲＩで規定されるリソースの区分に属するリソースに対する第２のリクエストに対して、前記第２のリクエストにて要求された処理を前記処理実行手段に実行させずに前記情報処理装置にエラー応答を送信するか否かを決定するため、前記リソースの区分全てに関連付けられている処理中のリクエストの数を、前記リソースの区分に属する個々のリソースに対応する処理中のリクエストの数を利用して計算することでリソースの区分単位にサーバシステムの処理能力を適宜に分配することを特徴とするリクエスト処理方法。
　　 
（３）対比 
　ここで、補正後の発明と引用発明とを比較する。 
　引用発明の「情報処理装置」、「ＵＲＩ」、「リソース」、「属する」、及び「リソースの区分」は、それぞれ補正後の発明の「クライアント」、「ＵＲＬ」、「業務プログラム」、「所属する」、及び「業務」に相当する。
　引用発明の「第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数」は、補正後の発明の「第１の業務プログラムが所属する業務全てに関連付けられている第１の情報」に相当する。
　引用発明の「前記リソースの区分に属する個々のリソースに対応する処理中のリクエストの数」は、当該情報を利用して、前記リソースの区分全てに関連付けられている処理中のリクエストの数を計算するものであるから、「前記リソースの区分全てに関連付けられている処理中のリクエストの数」に関連付けられており、補正後の発明の「第１の情報に関連付けられた第２の情報を利用する」における「第２の情報」に相当し、引用発明の「前記リソースの区分全てに関連付けられている処理中のリクエストの数を、前記リソースの区分に属する個々のリソースに対応する処理中のリクエストの数を利用して、計算する」は、補正後の発明の「前記第１の情報に関連付けられた第２の情報を利用する」に相当する。
　
　引用発明の「サーバシステム」と補正後の発明の「計算機システム」とは、ともにコンピュータシステムである点で共通する。
　引用発明の「リクエスト処理方法」と補正後の発明の「負荷分散方法」とは、ともに、処理方法である点で共通する。
　引用発明の「リソース格納部」と補正後の発明の「共通データベース」とはともに、「業務プログラムによりアクセスされるファイル」である点で共通する。
　
　引用発明の「処理実行手段」と補正後の発明の「業務処理装置」とは、ともに、リクエストにおける処理を行う、リクエスト処理手段である点で共通する。
　そして、引用発明の「処理実行手段」の「前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１のリソースを実行するとともに、該第１のリソースの実行によりアクセスされるリソース格納部にアクセスし、前記第１のリクエストにおける処理が終わると前記サーバのリクエスト分配手段に前記第１のリクエストの処理結果を送」る機能と、補正後の発明の「業務処理装置」の「前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い複数の業務処理装置におけるそれぞれの前記業務プログラムの実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送」る機能とは、ともに、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い前記業務プログラムの実行によりアクセスされるファイルにアクセスし、前記第１のリクエストにおける処理が終わると該第１のリクエストの処理結果を転送する点で共通する。
　
　引用発明の「サーバシステム」が、「ＵＲＩとリソースとが対応付けられ、前記ＵＲＩに対応するディレクトリ階層に前記リソースをそれぞれ格納した記憶装置を備える」ことと、補正後の発明の「業務処理装置」が、「予め、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納する」こととは、ともに、コンピュータシステムが、ＵＲＬに対応するディレクトリ階層に前記ＵＲＬに対応する業務プログラムをそれぞれ格納する記憶装置を備える点で共通する。
　
　引用発明の「リクエスト分配手段」と補正後の発明の「負荷制御装置」とは、ともに、クライアントからのリクエストを受信して、該リクエストを実行するか否かを規制するリクエスト中継手段である点で共通する。
　そして、引用発明の「リクエスト分配手段」の「処理実行手段へ前記第１のリクエストを送」る機能と、補正後の発明の「負荷制御装置」の「負荷分散装置へ前記第１のリクエストを送」る機能とはともに、処理するために第１のリクエストを転送する点で共通する。
　さらに、引用発明の「リクエスト分配手段」の「情報処理装置から受信した第１のリクエストにて要求された前記第１のリソースに関連するＵＲＩで規定されるリソースの区分に属するリソースに対する第２のリクエストに対して、前記第２のリクエストにて要求された処理を前記処理実行手段に実行させずに前記情報処理装置にエラー応答を送信するか否かを決定するため、前記リソースの区分全てに関連付けられている処理中のリクエストの数を、前記リソースの区分全てに属する個々のリソースに対応する処理中のリクエストの数を利用して計算することでリソースの区分単位にサーバの処理能力を適宜に分配する」機能と、補正後の発明の「負荷制御装置」が、「クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用する」機能はともに、クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、該リクエストを実行しないか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用する点で共通する。
　
　よって、補正後の発明と引用発明とは、以下の点で一致し、また、相違している。 
　 
（一致点） 
　クライアントから送られた業務のリクエストを処理するためのコンピュータシステムにおける処理方法において、
　コンピュータシステムは、ＵＲＬに対応するディレクトリ階層に前記ＵＲＬに対応する業務プログラムをそれぞれ格納する記憶装置を備え、
　リクエスト中継手段は、前記クライアントから送られた第１のリクエストを受信し、リクエスト処理手段にて実行されている前記階層的な構造を有する複数の業務プログラムは、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務プログラムのうちの一つである第１の業務プログラムに対応しており、当該第１の業務プログラムが所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記第１のリクエストを転送し、
　前記リクエスト処理手段は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い前記業務プログラムの実行によりアクセスされるファイルにアクセスし、前記第１のリクエストにおける処理が終わると該第１のリクエストの処理結果を転送し、
　前記リクエスト中継手段は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送り、さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、該リクエストを実行しないか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする処理方法。
　
（相違点１）
　補正後の発明の「業務処理装置」は、予め、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納するのに対して、引用発明の「サーバシステム」は、ＵＲＩとリソースとが対応付けられ、前記ＵＲＩに対応するディレクトリ階層に前記リソースをそれぞれ格納した記憶装置を備えている点。
　
（相違点２）
　補正後の発明は、複数の業務処理装置と負荷分散装置とを備えた計算機システムにおける分散処理方法であって、前記負荷分散装置は、クライアントから送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務プログラムを実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務プログラムを実行するとともに、該第１の業務プログラムの実行に伴い複数の業務処理装置におけるそれぞれの前記業務プログラムの実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送る、処理方法であるのに対して、引用発明は、情報処理装置から送られたリソースに対するリクエストを処理するためのサーバシステムにおける処理方法である点。
　
（相違点３）
　補正後の発明の「負荷制御装置」は、クライアントから送られた第１のリクエストを受信し、負荷分散装置（すなわち、計算機システム）へ前記第１のリクエストを送り、前記第１のリクエストの処理結果を負荷分散装置（すなわち、計算機システム）から受信すると、前記第１のリクエストの処理に費やされた時間を算出し、さらに前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用するものであるのに対して、引用発明の「リクエスト分配手段」は、情報処理装置から送られた第１のリクエストを受信し、処理実行手段へ前記第１のリクエストを送り、前記第１のリクエストの処理結果を処理実行手段から受信すると、前記第１のリクエストの処理に費やされた時間を算出するものでなく、さらに前記情報処理装置から受信した第１のリクエストにて要求された前記第１のリソースに関連するＵＲＩで規定されるリソースの区分に属するリソースに対する第２のリクエストに対応した処理を、前記処理実行手段に実行させずに前記情報処理装置にエラー応答を送信するか否かを決定するため、前記リソースの区分全てに関連付けられている処理中のリクエストの数を、前記リソースの区分全てに属する個々のリソースに対応する処理中のリクエストの数を利用して計算するものである点。
　
（４）判断 
（相違点１について）
　相違点１について検討する。
　引用発明の「サーバシステム」の備える記憶装置にＵＲＩに対応するディレクトリ階層に前記リソースをそれぞれ格納するために、予め、前記ＵＲＩと業務プログラムとの対応付けを入力することは、当業者であれば、容易に想到し得たことである。
　よって、相違点１は格別のものではない。
　
（相違点２について）
　相違点２について検討する。
　膨大な数のアクセス要求を処理するために、サーバシステムを複数のサーバと負荷分散装置とを備えたクラスタシステム化すること、及び前記クラスタシステムにおける分散処理方法は、負荷分散装置が、クライアントから送られたリクエストを受け付け、前記受け付けたリクエストで要求された処理を実行させるために前記複数のサーバの一つに前記受け付けたリクエストを分散して前記サーバへ送ることによって前記複数のサーバにおける負荷を調整し、前記サーバが、前記送られたリクエストを受信すると前記リクエストにて要求された処理を実行するとともに、該処理の実行に伴い複数のサーバにおけるそれぞれの処理の実行によりアクセスされる共通ファイルサーバにアクセスし、前記リクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送る処理方法であることは、当業者にとって周知の技術（以下、「周知技術１」という）である。（例えば、特開２００２−２５９３５４号公報の段落【０００２】における記載及び段落【０００７】における記載、特開２００２−１４９４６６号公報の段落【０００２】〜【０００７】における記載、特開２００２−１４９６２１号公報の段落【００１０】における記載等参照。）
　してみると、前記周知技術１を適用することで、引用発明の「サーバシステム」に替えて、クラスタシステムとすることは、当業者であれば、容易に想到し得たことである。
　そして、そうすることで、引用発明の「サーバシステムにおけるリクエスト処理方法」が、情報処理装置から送られたリソースに対するリクエストを該リクエストを処理するための複数のサーバと、該リクエストを受信して前記サーバのそれぞれの負荷を分散するように前記サーバに該リクエストを送信する負荷分散装置とを備えたクラスタシステム（「計算機システム」に相当）におけるリクエスト分散処理方法であって、前記負荷分散装置は、クライアントから送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１のリソースを実行させるために前記サーバの一つに前記受け付けた第１のリクエストを分散して前記サーバへ送ることによって前記複数のサーバにおける負荷を調整し、前記サーバは、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１のリソースを実行するとともに、該第１のリソースの実行に伴い複数のサーバにおけるそれぞれの前記リソースの実行によりアクセスされる共通ファイルサーバ（「共通データベース」に相当）にアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送る、クラスタシステムにおける分散処理方法となることは、論理的に明らかである。
　よって、相違点２は格別のものではない。
　
（相違点３について）
　相違点３について検討する。
　所定の機能を実現する手段を装置化することは、当業者にとって周知の常套手段であり、クライアントからサーバへのリクエストを受信して、サーバに転送し、前記サーバの処理結果を前記クライアントへ転送する中継機能を実現する手段を装置として、クライアントとサーバとの間に介在させることは、当業者にとって周知の技術（以下、「周知技術２」という）である。（例えば、特開２００２−２７１４２２号公報の【要約】における記載、特開２０００−１７２６２０号公報の【図４】等参照。）
　そして、リクエスト要求に対応する処理をサーバシステムにおいて制限するか否かを判断するための情報の一つとして、サーバシステムにおけるリクエストの処理に費やされたレスポンスタイムを算出して用いることは、当業者にとって周知の技術（以下、「周知技術３」という）である。（例えば、特開２００３−１５７１７３号公報の段落【００６２】における記載、特開２００３−１８６７７６号公報の段落【００４１】における記載「以上説明したように、リクエスト規制を行う場合に、ステップＳ１２、Ｓ２２、Ｓ２３、Ｓ２４、Ｓ２５などを判定基準とすることができるが、これらの条件単独または任意に複数を組合せてリクエスト規制の判定基準を決めることが可能である。」等参照。）
　また、リクエスト要求に対応する処理を実行させないと判断した場合に、該処理要求を保留して処理待ちキューに格納することは、当業者にとって周知の技術（以下、「周知技術４」という）である。（例えば、特開２００１−１７５４８４号公報の段落【００４５】における記載、特開２０００−４００２０号公報の段落【０００６】における記載、特開平６−７５９１０号公報の段落【０００８】における記載等参照。）
　してみると、引用発明の「リクエスト分配手段」に前記周知技術２を適用することで、リクエスト分配装置（「負荷制御装置」に相当）にするとともに、前記周知技術３を適用することで、第１のリクエストの処理結果を受信すると前記第１のリクエストの処理に費やされた時間を算出するものとし、前記周知技術４を適用することで、「情報処理装置から受信した…第２のリクエストを実行させずに前記情報処理装置にエラー応答を送信する」ことに替えて、情報処理装置から受信した…第２のリクエストを、前記リクエスト分配装置の待ちキューに格納するように構成することは、当業者であれば、容易に想到し得たことである。
　そして、そうすることで、引用発明の「リクエスト分配手段」が、情報処理装置から送られた第１のリクエストを受信し、前記第１のリクエストをクラスタシステムへ送り、前記第１のリクエストの処理結果を受信すると、前記第１のリクエストの処理に費やされた時間を算出し、さらに前記情報処理装置から受信した第１のリクエストにて要求された前記第１のリソースに関連するＵＲＩで規定されるリソースの区分に属するリソースに対する第２のリクエストを、自身の有するキューに格納するか否かを決定するため、前記リソースの区分全てに関連付けられている処理中のリクエストの数を、前記リソースの区分全てに属する個々のリソースに対応する処理中のリクエストの数を利用して計算するリクエスト分配装置となることは、論理的に明らかである。
　よって、相違点３は格別のものではない。
　
　上記で検討したごとく、相違点１〜相違点３は格別のものではなく、そして、補正後の発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、補正後の発明は上記引用発明、及び周知技術１〜４に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
（備考）請求人の主張について
　請求人は、平成２０年６月１９日付けの手続補正（方式）の「請求の理由」において、
「本願発明の主要な構成である「複数のＵＲＬで規定される業務、それに関連するリクエスト、および、そのＵＲＬで規定される業務におけるレスポンスタイムの３つの関係を対応付けて、ＵＲＬ毎に送られるレスポンスにおける実行制御を行う」点については何ら記載されていません。その異なる構成により、本願発明では、業務処理装置や共通DBへ流入するリクエストを、業務毎に一時制限させておくことによって、負荷分散装置単独では実現できなかった、負荷の大きい業務による業務処理装置や共通DBへの負荷を減少させることができ、他の軽敏な業務処理まで負荷を与えないようにすることが可能となるという格別な効果を奏するものです。」（３頁１７行目〜２４行目。）と主張する。
　しかしながら、補正後の発明は、
　「負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，…当該受信した第１のリクエストは、…第１の業務に対応しており、当該第１の業務が所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送」ること、及び
　「負荷制御装置は、…前記第１のリクエストの処理に費やされた時間を算出し、さらに、…前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用する」ことを、発明特定事項として備えることが記載されているに過ぎない。
　そして、前記「第１の情報」として、発明の詳細な説明に記載された「業務の合計リクエスト数」を採用する態様を排除するものでなく、また前記「第２の情報」として、発明の詳細な説明に記載された「リクエストＵＲＬの実行中リクエスト数」を採用する態様を排除するものでない。
　よって、請求人の主張「ＵＲＬで規定される業務におけるレスポンスタイムの３つの関係を対応付けて、ＵＲＬ毎に送られるレスポンスにおける実行制御を行う」点については、特許請求の範囲の請求項の記載に基づかない主張であり、採用することはできない。
　
　なお、仮に、前記「第１の情報」を「業務毎のレスポンスタイムの平均値」であると仮定し、また前記「第２の情報」を「リクエストＵＲＬのレスポンスタイム」であると仮定した場合であっても、上記「（相違点３について）」で指摘したように、リクエスト要求に対応する処理をサーバシステムにおいて制限するか否かを判断するための情報として、リクエストの処理に費やされたレスポンスタイムを算出して用いることは、当業者にとって周知の技術（例えば、特開２００３−１５７１７３号公報の段落【００６２】における記載、特開２００３−１８６７７６号公報の段落【００４１】における記載「以上説明したように、リクエスト規制を行う場合に、ステップＳ１２、Ｓ２２、Ｓ２３、Ｓ２４、Ｓ２５などを判定基準とすることができるが、これらの条件単独または任意に複数を組合せてリクエスト規制の判定基準を決めることが可能である。」等参照）であるから、引用発明における、接続制限を判断するための情報としての「第１のリソースが属するリソースの区分全てに関連付けられている処理中のリクエストの数」に替えて、第１のリソースが属するリソースの区分全てに関連付けられているリクエストの処理に費やされたレスポンスタイムを適用すること、そして、その際、前記「第１のリソースが属するリソースの区分全てに関連付けられているリクエストの処理に費やされたレスポンスタイム」を計算するために、前記第１のリクエストの処理に費やされた時間を算出して利用することは、当業者であれば、容易に想到し得たことである。
　したがって、仮に、補正後の発明における前記「第１の情報」を「業務毎のレスポンスタイムの平均値」であると仮定し、また補正後の発明における前記「第２の情報」を「リクエストＵＲＬのレスポンスタイム」であると仮定した場合であっても、補正後の発明は、依然として、上記引用発明、及び周知技術１〜４に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
　以上のとおり、仮に、本件補正が、願書に最初に添付された明細書、特許請求の範囲又は図面に記載した範囲内にしたものであると仮定した場合であって、さらに、仮に、本件補正が、特許法第１７条の２第４項第２号の特許請求の範囲の限定的減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の利用分野及び解決しようとする課題が同一であるもの）を目的とするものであると仮定した場合であっても、本願補正発明は、特許出願の際独立して特許を受けることができるものではないから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していないから、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．むすび 
　以上のとおり、補正前の請求項１についてする補正は、上記「２−１．特許法第１７条の２第３項に規定する要件についての検討」において指摘したとおり、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するものであるから、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また、仮に本件補正が、特許法第１７条の２第３項の規定に従うものであると仮定した場合においても、補正前の請求項１についてする補正は、上記「２−２．特許法第１７条の２第４項に規定する要件についての検討」において指摘したとおり、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る）とする規定に違反するものであるから、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また、仮に補正前の請求項１についてする補正が、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る）を目的とするものであると仮定した場合においても、上記「２−３．独立特許要件」で指摘したとおり、補正後の発明が特許出願の際独立して特許を受けることができるものではないから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していないから、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　したがって、いずれにしても、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　 
第３．本願発明について 
　平成２０年４月２５日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１９年９月３日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。 
　 
「クライアントから送られた業務のリクエストを処理するための複数の業務処理装置と、該リクエストを受信して前記業務処理装置のそれぞれの負荷を分散するように前記業務処理装置に該リクエストを送信する負荷分散装置とを有する計算機システムにおける負荷分散方法において、
　負荷制御装置は、前記クライアントから送られた第１のリクエストを受信し，前記業務処理装置にて実行されている階層的な構造を有する複数の業務は、その階層構造をＵＲＬで表し複数のＵＲＬに割り付けられている業務の構成となっており、当該受信した第１のリクエストは、前記ＵＲＬを含み、該ＵＲＬに対応する前記階層構造を構成する業務のうちの一つである第１の業務に対応しており、当該第１の業務が所属する業務全てに関連付けられている第１の情報が所定の条件を満たしているならば、前記負荷分散装置へ前記第１のリクエストを送り、
　前記負荷分散装置は、前記送られた第１のリクエストを受け付け、前記受け付けた第１のリクエストで要求された第１の業務を実行させるために前記業務処理装置の一つに前記受け付けた第１のリクエストを分散して前記業務処理装置へ送ることによって前記複数の業務処理装置における負荷を調整し、
　前記業務処理装置は、前記送られた第１のリクエストを受信すると第１のリクエストにて要求された前記第１の業務を実行するとともに、該第１の業務の実行に伴い複数の業務処理装置のそれぞれの業務の実行によりアクセスされる共通データベースにアクセスし、前記第１のリクエストにおける処理が終わると前記負荷分散装置に前記第１のリクエストの処理結果を送り、
　前記負荷分散装置は、前記第１のリクエストの処理結果を受信すると、該第１のリクエスの処理結果を前記負荷制御装置に送り、
　前記負荷制御装置は、前記送られた第１のリクエストの処理結果を受信すると、前記クライアントに処理結果を送るとともに、前記第１のリクエストの処理に費やされた時間を算出し、
さらに、前記クライアントから受信した第１のリクエストにて要求された前記第１の業務に関連するＵＲＬで規定される業務に関連する第２のリクエストを、前記負荷制御装置が有するキューに格納するか否かを決定するため、前記第１の情報に関連付けられた第２の情報を利用することを特徴とする負荷分散方法。」
　　
（１）引用文献 
　原査定の拒絶の理由に引用された、引用文献およびその記載事項は、前記「第２．平成２０年４月２５日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「２−３．独立特許要件」の「（２）引用文献」に記載したとおりである。
　
（２）対比・判断 
　本願発明は、前記「第２．平成２０年４月２５日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「２−３．独立特許要件」の「（１）補正後の発明」に記載された補正後の発明の発明特定事項「予め、前記業務処理装置は、ＵＲＬと業務プログラムとの対応付けを複数入力すると、業務処理装置に備えられた記憶装置の前記ＵＲＬに対応するディレクトリ階層に前記プログラムをそれぞれ格納し、」を削除し、補正後の発明の発明特定事項「業務プログラム」をその上位概念である「業務」としたものである。
　そうすると、本願発明の構成要件を全て含み、さらに特定の構成要件に限定要件を付加したものに相当する補正後の発明が、前記「第２．平成２０年４月２５日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「２−３．独立特許要件」の「（４）判断」に記載したとおり、引用発明、及び周知技術１〜４に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明、及び周知技術１〜４に基づいて、当業者が容易に発明をすることができたものである。 
　 
（３）むすび 
　以上のとおり、本願の請求項１に係る発明は、その出願前日本国内又は外国において頒布された刊行物又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。