【事件の表示】
　平成　９年特許願第　８１２３９号「負荷分散制御を行うクライアントサーバーシステム」拒絶査定不服審判事件〔平成１０年１０月１３日出願公開、特開平１０−２７５１２６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成９年３月３１日の出願であって、平成１７年４月７日付けで拒絶査定され、これに対し、同年５月１２日に拒絶査定不服審判が請求されるとともに、同年６月１３日付けで手続補正がされたものである。
　
第２．平成１７年６月１３日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１７年６月１３日付けの手続補正（以下、「本件補正」という。）を却下する。
　
［理由］
１．本件補正後の本願発明
　本件補正により、特許請求の範囲の請求項１は次のとおりに補正された。
　
　　【請求項１】
　問合せリクエストを受信して同一の情報処理を行って処理結果を送信する処理の優先順序が定められた複数の問合せ応答型サーバーと、問合せリクエストを送信する複数のクライアントと、全ての前記問合せ応答型サーバーとクライアントと直接接続されたコアーノードと、を有する負荷分散制御を行うクライアントサーバーシステムにおいて、
　前記コアーノードは、
　前記クライアントの問合せリクエストの発生、処理、返信までの処理を管理する問合せリクエスト管理部と、
　問合せリクエスト送信元のクライアントを管理するリクエスト元クライアント管理部と、
　問合せリクエスト送信や処理結果送信のイベントを受信しその処理を前記各管理部に振り分ける主制御部と、を有し、
　前記クライアントからの問合せリクエストは、すべて前記コアーノードに送られ、前記コアーノードの主制御部を介して問合せリクエスト管理部に送信され、前記問合せリクエスト管理部から処理可能な問合せ応答型サーバーのうちで処理の優先順序が最も高い問合せ応答型サーバーに送られ、
　送信元のクライアントは前記コアーノードのリクエスト元クライアント管理部に登録され、
　前記問合せ応答型サーバーからの応答データは、前記コアーノードに送信され、前記コアーノードの問合せリクエスト管理部によって前記リクエスト元クライアント管理部に登録された送信元クライアントに送信される、ことを特徴とする負荷分散制御を行うクライアントサーバーシステム。
　
　前記補正は、請求項１に係る発明を特定するために必要な事項である「問合せ応答型サーバー」について、「処理の優先順序が定められた」との限定を付加するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものである。
　そこで、本件補正後における前記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）について、以下に検討する。
　
２．刊行物記載発明
　原査定の拒絶の理由に引用された、本願出願前に頒布された刊行物である特開平０８−０８７４７３号公報（平成８年４月２日出願公開。以下、「刊行物１」という。）には、図面とともに以下の技術事項が記載されている。
　
【００３４】
【実施例】以下、図面を参照しながら本発明の実施例を説明する。
【００３５】各構成要素（ブロック）に付した参照番号のうち「ｉ−ｊ」「ｉ−ｊ−ｋ」（例えば１０２−１）の形のものは、「ｉ」が同一のものは同様の構成を有するものであることを表す。また、参照番号ｉを付したブロックの個々を区別する必要のない場合など、適宜「−ｊ」「−ｊ−ｋ」を省略して記述する。
【００３６】（第１の実施例）図１に、本発明の第１の実施例の構成を示す。
【００３７】図１のデータ処理装置は、ｍ（ｍは２以上）台の処理要求実行用の計算機（処理要求実行計算機）１１０−１〜１１０−ｍと、フロントエンド処理用の計算機（フロントエンド計算機）１１１と、フロントエンド計算機１１１と各処理要求実行計算機１１０−１〜１１０−ｍとを相互接続する結合路１１４と、各処理要求実行計算機１１０−１〜１１０−ｍに接続されてデータを記憶するデータ記憶装置１１８−１〜１１８−ｍとから構成されている。なお、図１ではフロントエンド計算機は１台であるが並列に複数台設けても良い。また、データ記憶装置はすべての処理要求実行計算機ではなくそのうちの一部にだけローカルに設けても良い（データ記憶装置は１台だけでも良い）。
【００３８】このように複数台の処理要求実行計算機を用いることによって、並列処理による高性能なデータ処理が実現できる。また、処理要求の負荷を複数の処理要求実行計算機に分散して、高負荷のデータ処理に対応できる。
【００３９】フロントエンド計算機１１１は、処理要求を発生するｎ（ｎは１以上）台の各処理要求発生部１０２−１〜１０２−ｎと通信路１１５を介して接続され、処理要求発生部１０２−１〜１０２−ｎから送られてくる処理要求を受信し、それを実行すべきアプリケーションプログラム１１６−１〜１１６−ｍの存在する処理要求実行計算機１１０−１〜１１０−ｍを選択し、該処理要求の実行を指示する処理要求割り付け部１０１を持つ。
【００４０】処理要求発生部１０２としては、端末装置や計算機あるいは自動現金支払機など種々のものが考えられる。
【００４１】各処理要求実行計算機１１０−１〜１１０−ｍは、処理要求を実行するアプリケーションプログラム１１６−１〜１１６−ｍ、アプリケーションプログラム１１６−１〜１１６−ｍの実行に必要なデータ記憶装置１１８−１〜１１８−ｍ上のデータの操作を行うデータ管理部１１７−１〜１１７−ｍを夫々持つ。
【００４２】処理要求実行計算機１１０−１〜１１０−ｍのうちの１つは、データ配置管理部１２０を持つ。このデータ配置管理部１２０は、各処理要求実行計算機１１０−１〜１１０−ｍ内部のデータ管理部１１７−１〜１１７−ｍ夫々と協調して動作するものであり、各データ管理部１１７−１〜１１７−ｍからデータアクセスに関する情報を受け取り、その情報を基に最適なデータ配置を計算し、その結果に従って各処理要求実行計算機１１０−１〜１１０−ｍにデータの配置の変更を指示する。なお、データ配置管理部１２０およびデータ管理部１１７のより具体的な内部構成については後述する。
　
【００４７】次に、図１のデータ処理装置の動作を説明する。
【００４８】処理要求発生部１０２−１〜１０２−ｎのいずれかにより出力された処理要求は、通信路１１５を通してフロントエンド計算機１１１上の処理要求割り付け部１０１に送られる。処理要求割り付け部１０１は、処理要求実行計算機１１０−１〜１１０−ｍのうちから、その処理要求を実行するのに最適なものを選択して処理を割り付ける。
【００４９】処理要求を実行するのに最適な処理要求実行計算機とは、その処理要求を最も小さなコストで実行できる処理要求実行計算機である。コストは、例えばその処理要求を実行するのに必要な時間で表すことができる。あるいは、その処理を実行するのに必要な通信回数などでコストを表すこともできる。
【００５０】処理要求を実行する処理要求実行計算機を選択する方式は、後述するように、「過去に、どの様な処理要求を、どの処理要求実行計算機で実行したら、どれくらいのコストがかかったか」を表す実行履歴を蓄積する手段を設け、新しい処理要求が到着すると、その処理要求を実行履歴と照らし合わせて、どの処理要求実行計算機で実行すると最小のコストで実行できるかを判断する方式を用いることができる。この方式では、過去の実行履歴を基に最適な処理要求実行計算機を選択するため、必ず最適なものが選択される保証はなく、最適なものが選択されるか否かは確率的なものとなる。このような確率的な方式を使用できるのは、後述するように、どの処理要求実行計算機上のアプリケーションプログラムからもすべてのデータに透過にアクセスできるように構成していることによる。
　
【００９３】（第１〜第３の実施例の処理要求割り付け部１０１の具体例）次に、第１〜第３の実施例の処理要求割り付け部１０１の具体例を示す。
【００９４】本実施例の処理要求割り付け部１０１の構成例を図６に示す。また、他の構成例を図７に示す。なお、構成を区別するために、図６の処理要求割り付け部を１で表し、図７の処理要求割り付け部を１１で表すこととする。
【００９５】処理要求割り付け部１，１１は、１つ以上の処理要求発生部２−１〜２−ｎが発生した処理要求を受け取り、その処理要求を実行可能な１つ以上の処理要求実行計算機１０−１〜１０−ｍの中から実行に最適な計算機を選択し、受け取った処理要求を選択した計算機に転送する。
【００９６】まず、処理要求割り付け部の構成例を図６に従って説明する。いずれかの処理要求発生部２から送られて来た処理要求は、処理要求受信部３によって受け取られる。処理要求受信部３は受信した処理要求を処理要求送信部６と特徴パラメタ抽出部４に渡す。特徴パラメタ抽出部４は渡された処理要求から特徴パラメタを抽出し、それを実行計算機選択部５に渡すと共に、そのデータを実行履歴情報記憶部８に渡して該当処理要求の特徴パラメタとして記録しておく。実行計算機選択部５は、特徴パラメタ抽出部４から渡された特徴パラメタの値と、実行履歴情報記憶部８に記録している過去の実行履歴情報を比較することによって、該当処理要求を実行する最適な計算機を選択する。選択した計算機を処理要求送信部６に伝えると共に、実行履歴情報記憶部８に知らせて該当処理要求を実行した計算機として記録しておく。処理要求送信部６は、処理要求受信部３から渡された処理要求を、実行計算機選択部５から知らされた計算機に対して送信することによって、処理要求の割り付け処理を完了する。実行履歴情報管理部７は、実行履歴情報記憶部８に記録している実行履歴情報の管理を行い、定められた時間あるいは処理回数を越える古い実行履歴情報の消去等を行う。処理要求を受け取った処理要求を実行計算機１０は、その処理要求実行すると共に、その実行に要したコストを処理要求割り付け部の実行コスト検出部９に伝える。実行コスト検出部９は、受け取った実行コストを実行履歴情報記憶部８に伝えることによって、該当する処理要求の処理要求実行履歴情報に実行コストを記録する。処理要求実行計算機１０は処理要求の実行結果を処理要求発生部２に伝える必要がある場合は、適当な通信手段を用いて直接処理要求発生部に伝える。
【００９７】処理要求割り付け部の別の構成例を図７に従って説明する。図７の構成例は、処理要求を処理要求実行計算機に伝えるまでは図６の構成例と同じである。処理要求を受け取った処理要求実行計算機１０はその処理を実行するが、図６の構成例とは違って、その実行に要したコストを陽に処理要求割り付け部に知らせることはしない。処理要求実行計算機１０は、処理要求を実行した処理結果を処理要求割り付け部１１に送り返す。この処理結果は処理要求割り付け部の処理結果受信部１２が受信して処理結果送信部１３に伝えると共に、処理結果を受信したことを実行コスト検出部９に伝える。処理結果を受け取った処理結果送信部１３は、該当する処理要求を発生した処理要求発生部２に処理結果を送り返す。処理結果を受信したことを知らされた実行コスト検出部９は、該当する処理要求の実行に要したコストを求め、その実行コストを実行履歴情報記憶部８に伝えることによって、該当する処理要求の処理要求実行履歴情報に実行コストを記憶する。実行コストを求める手段としては、処理要求を受け取った時間とその処理要求に対応する処理結果を受け取った時間の差を実行に必要なコストとする方式や、該当する処理要求の実行を追い抜いて実行を完了した処理要求の数を実行コストとする方式などを用いることが出来る。
　
【０１０９】以下には、本発明をリモート・プロシージャ・コール（ＲＰＣ）による処理要求の割り付け部に適用した場合の一実施例を述べる。
【０１１０】図１１に処理要求割付部の構成を示す。図１１の構成は、図１０の構成に対して処理要求表（記憶部）２６と処理要求表管理部２５がつけ加わったものである。図１０の処理要求割付部は、単一の種類の処理要求の割り付けを行う場合の構成であり、これを複数の種類の処理要求を扱えるようにしたのが図１１の構成である。
【０１１１】処理要求受信部３は、処理要求発生部２から結合路１４を通して伝えられる処理要求パケットを受け取る。例えば結合路としてイーサネットを用いる場合には、ＵＤＰプロトコルの特定ポートに到着するパケットを受信する。パケットは図１２（ａ）に示すようなバイト列の構造を持つデータであるが、ＲＰＣの処理要求パケットはこのバイト列をたとえば図１２（ｂ）に示すような構造を持つデータと解釈する。すなわち、パケットの先頭には処理要求の種別を示すデータが入っている。図１２（ｂ）の例は、ｐｒｏｃ１と呼ぶ処理の種別であることを示している。実際にはｐｒｏｃ１に対応する一意の識別番号が、パケットの先頭の４バイトを占める数値として記録される。その後には、処理要求に付随する引数が必要な個数並ぶ。図１２（ｂ）の例では、ｘ，ｙ，ｚで表している３つの４バイト長のデータが並んでいる。ＲＰＣのパケットの構造は、ここで示したもの以外にも多くの構造があるが、本発明の方式はどのような構造のパケットにも適用可能である。
【０１１２】ＲＰＣのパケットのどの部分に要求の種別が入っているかは固定であるので、パケットを受信した処理要求受信部３はそのパケットから要求の種別を取り出すことができ、それを処理要求表２６に伝える。ここで、処理要求受信部は複数のポートに到着する処理要求パケットを受信するように構成することも可能である。この場合、各ポート毎にそのポートに到着する処理要求に関する情報を記録した処理要求表を作成しておき、処理要求受信部はパケットを受信すると、それを受信したポートに対応する処理要求表に要求の種別を伝えるような構成も可能である。
【０１１３】処理要求表２６は図１３に示すように、要求の種別、引数情報、重み情報、実行計算機情報、実行履歴情報ポインタの５種類の情報の対応関係を記録する表である。
　
【０１２０】図１３の処理要求表２６の実行履歴情報ポインタは、実行履歴情報記憶部８に記憶されている実行履歴情報で各要求の種別に属するもののグループを指し示している。実行履歴情報は図１７に示すように、処理要求の内容、その処理要求を実行した計算機の番号、その実行に要したコスト（例えばここでは実行に要した時間）、処理結果を送り返すのに必要なその処理要求発生部の情報（例えばここではネットワークアドレスとポート番号）からなる。処理要求をそのまま記録するのではなく、その処理要求から取り出した特徴パラメタ、あるいはその特徴パラメタのうち実行計算機の予測に用いる重みの大きなもののみを取り出したものでも構わない。
　
【０１４３】こうして選択された実行計算機番号は処理要求送信部６に送られる。処理要求送信部６はこの実行計算機番号を用いて処理要求表２６から渡された実行計算機情報を引き、該当する計算機に対して、処理要求受信部３から渡された処理要求を転送する。このとき、実行履歴情報記憶部８に記憶した該当する処理要求の実行履歴情報に、処理要求を転送した実行計算機を登録する。
【０１４４】こうして割り付けられて転送された処理要求は、処理要求実行計算機１０によって実行し、その実行結果は処理要求割り付け部１１に送り返される。処理要求割り付け部の処理結果受信部１２は処理結果を受信し、その処理結果を実行コスト検出部９と処理結果送信部１３に送る。実行コスト検出部９はその処理結果に対応する実行履歴情報を実行履歴情報記憶部から取り出し、その実行コストを記録する。ここでは実行に要した時間を実行コストとする方式をとる。そのために、処理要求送信部６は処理要求を転送する際に該当する実行履歴情報の実行コスト欄にその時点の時刻を記録しておく。実行コスト検出部９は実行コスト欄に記録された時刻と現在の時刻の差を実行コストとして実行コスト欄に記録し直す。本実施例では実行時間を実行コストとしたが、処理要求実行計算機１０が実行コストを処理結果に添えて送り返す方式もある。この場合処理要求実行計算機１０で任意のデータを実行コストとして与えることが出来る。実行コストの例としては、実行中に必要となったディスク参照回数、他のノードのデータのアクセス回数、ロックの待ちの回数等を用いることが出来る。
【０１４５】本実施例のように処理結果を処理要求割り付け部が中継して処理要求発生部に送り返す方式以外に、処理要求実行計算機が処理要求発生部に直接処理結果を送り返し、処理要求割り付け部はその間の通信路をモニターし、処理結果のパケットを見つければそれを取り込んで実行コストを検出するような実施方式も可能である。
【０１４６】本実施例では、処理要求実行計算機に送った処理要求とその処理結果の対応は、実行履歴情報を参照することで判断する。しかし、この方式では同時に複数のパケットを同じ処理要求実行計算機に割り付けて多重処理を行なうことが出来ない。これを可能にするためには、図２９（ａ）に示すように処理要求パケットに一意の識別番号を持たせる。処理要求実行計算機は図２９（ｂ）に示すように処理要求に付いて来た識別番号を処理結果に持たせて返す。この一意の識別番号を用いることにより、同時に複数の処理要求を同じ実行計算機に割り付けた場合でも、実行履歴情報に記録された処理要求と処理結果の対応をとることが可能になる。このような識別番号を用いて同じ計算機に対する処理要求を識別する方式以外に、処理要求割り付け部と処理要求実行計算機を結ぶ通信チャネルを論理的に多重化し、同時に同じ計算機に対する処理要求も異なる通信チャネルを用いることで識別することが可能になる。
　
　これらの記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されている。
　
　ｍ（ｍは２以上）台の処理要求実行用の計算機（処理要求実行計算機）と、フロントエンド処理用の計算機（フロントエンド計算機）と、フロントエンド計算機と各処理要求実行計算機とを相互接続する結合路と、各処理要求実行計算機に接続されてデータを記憶するデータ記憶装置とから構成され、複数台の処理要求実行計算機を用いることによって、並列処理による高性能なデータ処理が実現でき、また、処理要求の負荷を複数の処理要求実行計算機に分散して、高負荷のデータ処理に対応できるデータ処理装置であって、
　フロントエンド計算機は、処理要求を発生するｎ（ｎは１以上）台の各処理要求発生部と通信路を介して接続され、処理要求発生部から送られてくる処理要求を受信し、それを実行すべきアプリケーションプログラムの存在する処理要求実行計算機を選択し、該処理要求の実行を指示する処理要求割り付け部を持ち、
　処理要求割り付け部は、１つ以上の処理要求発生部が発生した処理要求を受け取り、その処理要求から特徴パラメタを抽出し、その特徴パラメタの値と過去の実行履歴情報を比較することによって、その処理要求を実行可能な１つ以上の処理要求実行計算機の中から実行に最適な計算機を選択し、受け取った処理要求を選択した計算機に転送するものであり、
　いずれかの処理要求発生部２から送られて来た処理要求は、処理要求受信部３によって受け取られ、処理要求受信部３は受信した処理要求を処理要求送信部６と特徴パラメタ抽出部４に渡し、特徴パラメタ抽出部４は渡された処理要求から特徴パラメタを抽出し、それを実行計算機選択部５に渡すと共に、そのデータを実行履歴情報記憶部８に渡して該当処理要求の特徴パラメタとして記録しておき、実行計算機選択部５は、特徴パラメタ抽出部４から渡された特徴パラメタの値と、実行履歴情報記憶部８に記録している過去の実行履歴情報を比較することによって、該当処理要求を実行する最適な計算機を選択し、選択した計算機を処理要求送信部６に伝えると共に、実行履歴情報記憶部８に知らせて該当処理要求を実行した計算機として記録しておき、処理要求送信部６は、処理要求受信部３から渡された処理要求を、実行計算機選択部５から知らされた計算機に対して送信することによって、処理要求の割り付け処理を完了し、
　処理要求実行計算機は、処理要求を実行した処理結果を処理要求割り付け部に送り返し、この処理結果は処理要求割り付け部の処理結果受信部１２が受信して処理結果送信部１３に伝えると共に、処理結果を受信したことを実行コスト検出部９に伝え、処理結果を受け取った処理結果送信部１３は、該当する処理要求を発生した処理要求発生部２に処理結果を送り返し、処理結果を受信したことを知らされた実行コスト検出部９は、該当する処理要求の実行に要したコストを求め、その実行コストを実行履歴情報記憶部８に伝えることによって、該当する処理要求の処理要求実行履歴情報に実行コストを記憶し、実行コストを求める手段としては、処理要求を受け取った時間とその処理要求に対応する処理結果を受け取った時間の差を実行に必要なコストとする方式や、該当する処理要求の実行を追い抜いて実行を完了した処理要求の数を実行コストとする方式などを用いることが出来、
　さらに、処理要求割り付け部の構成として、処理要求表（記憶部）２６と処理要求表管理部２５がつけ加わったものも可能であり、処理要求表２６は、要求の種別、引数情報、重み情報、実行計算機情報、実行履歴情報ポインタの５種類の情報の対応関係を記録する表であり、処理要求表２６の実行履歴情報ポインタは、実行履歴情報記憶部８に記憶されている実行履歴情報で各要求の種別に属するもののグループを指し示し、実行履歴情報は、処理要求の内容、その処理要求を実行した計算機の番号、その実行に要したコスト（例えばここでは実行に要した時間）、処理結果を送り返すのに必要なその処理要求発生部の情報（例えばここではネットワークアドレスとポート番号）からなり、処理要求実行計算機に送った処理要求とその処理結果の対応は、実行履歴情報を参照することで判断する、
データ処理装置。
　
３．対比
　本願補正発明を、刊行物１記載発明と比較する。
　刊行物１記載発明の「処理要求実行計算機」、「処理要求発生部」、及び「フロントエンド計算機」は、それぞれ、本願補正発明の「問合せ応答型サーバー」、「クライアント」、及び「コアーノード」に相当する。
　
　刊行物１記載発明において、フロントエンド計算機の処理要求割り付け部は、処理要求を実行可能な１つ以上の処理要求実行計算機の中から実行に最適な計算機を選択し、受け取った処理要求を選択した計算機に転送するものであり、かつ、処理要求実行計算機は、処理要求を実行した処理結果を処理要求割り付け部に送り返しているから、処理要求実行計算機が、「問合せリクエストを受信して同一の情報処理を行って処理結果を送信する複数の問合せ応答型サーバー」であることは明らかであり、刊行物１記載発明と、本願補正発明とは、「前記クライアントからの問合せリクエストは、すべて前記コアーノードに送られ、前記コアーノードから処理可能な問合せ応答型サーバーに送られ」る点で一致する。
　
　刊行物１記載発明は、処理要求の負荷を複数の処理要求実行計算機に分散して、高負荷のデータ処理に対応できるデータ処理装置であり、フロントエンド計算機と各処理要求実行計算機とを相互接続する結合路を備え、かつ、フロントエンド計算機は処理要求を発生する各処理要求発生部と通信路を介して接続されるから、刊行物１記載発明と、本願補正発明とは、「問合せリクエストを受信して同一の情報処理を行って処理結果を送信する複数の問合せ応答型サーバーと、問合せリクエストを送信する複数のクライアントと、全ての前記問合せ応答型サーバーとクライアントと直接接続されたコアーノードと、を有する負荷分散制御を行うクライアントサーバーシステム」である点で一致する。
　
　刊行物１記載発明において、実行履歴情報記憶部８に記憶されている実行履歴情報は、処理結果を送り返すのに必要なその処理要求発生部の情報（例えばここではネットワークアドレスとポート番号）を含むから、刊行物１記載発明が、「問合せリクエスト送信元のクライアントを管理するリクエスト元クライアント管理部」に相当する部分を有し、「送信元のクライアントは前記コアーノードのリクエスト元クライアント管理部に登録」することは明らかである。
　
　刊行物１記載発明において、「実行計算機選択部５は、…（中略）…該当処理要求を実行する最適な計算機を選択し、選択した計算機を処理要求送信部６に伝えると共に、実行履歴情報記憶部８に知らせて該当処理要求を実行した計算機として記録しておき、処理要求送信部６は、処理要求受信部３から渡された処理要求を、実行計算機選択部５から知らされた計算機に対して送信」しており、「処理要求実行計算機は、処理要求を実行した処理結果を処理要求割り付け部に送り返し、この処理結果は処理要求割り付け部の処理結果受信部１２が受信して処理結果送信部１３に伝えると共に、…（中略）…処理結果を受け取った処理結果送信部１３は、該当する処理要求を発生した処理要求発生部２に処理結果を送り返」しているから、刊行物１記載発明が、「前記クライアントの問合せリクエストの発生、処理、返信までの処理を管理する問合せリクエスト管理部」を有し、かつ、問合せ応答型サーバーからの応答データを、「問合せリクエスト管理部によって前記リクエスト元クライアント管理部に登録された送信元クライアントに送信」することは明らかである。
　
　すると、本願補正発明と、刊行物１記載発明とは、次の点で一致する。
＜一致点＞
　「問合せリクエストを受信して同一の情報処理を行って処理結果を送信する複数の問合せ応答型サーバーと、問合せリクエストを送信する複数のクライアントと、全ての前記問合せ応答型サーバーとクライアントと直接接続されたコアーノードと、を有する負荷分散制御を行うクライアントサーバーシステムにおいて、
　前記コアーノードは、
　前記クライアントの問合せリクエストの発生、処理、返信までの処理を管理する問合せリクエスト管理部と、
　問合せリクエスト送信元のクライアントを管理するリクエスト元クライアント管理部と、を有し、
　前記クライアントからの問合せリクエストは、すべて前記コアーノードに送られ、前記コアーノードから処理可能な問合せ応答型サーバーに送られ、
　送信元のクライアントは前記コアーノードのリクエスト元クライアント管理部に登録され、
　前記問合せ応答型サーバーからの応答データは、前記コアーノードに送信され、前記コアーノードの問合せリクエスト管理部によって前記リクエスト元クライアント管理部に登録された送信元クライアントに送信される、
負荷分散制御を行うクライアントサーバーシステム。」である点。
　
　一方で、両者は次の点で相違する。
＜相違点１＞
　クライアントからの問合せリクエストは、本願補正発明では、処理の優先順序が定められた問合せ応答型サーバーのうちで処理の優先順序が最も高い問合せ応答型サーバーに送られるのに対して、刊行物１記載発明では、実行に最適な問合せ応答型サーバーに転送する点。
＜相違点２＞
　本願補正発明において、コアーノードは「問合せリクエスト送信や処理結果送信のイベントを受信しその処理を前記各管理部に振り分ける主制御部」を有し、クライアントからの問合せリクエストは、「前記コアーノードの主制御部を介して問合せリクエスト管理部に送信」するのに対して、刊行物１記載発明において、コアーノードが主制御部を有するのか明らかでない点。
　
４．判断
＜相違点１＞について
　例えば、特開平０６−２５９３６２号公報（平成６年９月１６日出願公開。特に段落【００１２】の「この場合、処理の引き渡しのされるサーバの優先順位（順序）を予め定めておくことにより、空いているサーバが見つかるまでこの優先順位に従って処理要求を順に次々のサーバに自動的に引き渡して行くことができる。」、及び段落【００１７】の「優先的に処理要求を受けるように設定された（予め優先順位が１番に設定されている）サーバ１に処理要求が渡され（ステップ７３）、」参照。）、特開平０５−１２８０７７号公報（平成５年５月２５日出願公開。特に段落【０００７】の「このテ−ブル１４０には、複数計算機システム内で処理を実行する計算機の順位と、その計算機の識別情報とを登録したフィ−ルドが設けられている。」、及び段落【０００８】の「処理スケジュ−ラ７０は、…（中略）…該当する最も優先順位の高い計算機が計算機１であることを知る（ステップ１０２）。…（中略）…スケジュ−ラ７０は、処理Ｔを計算機１に割り付けて、実行させる…（後略）…」参照。）、及び、特開平０４−２７１４５４号公報（平成４年９月２８日出願公開。特に段落【００１９】の「このように、資源管理部１１２では、１つの接続要求に対して優先順位付けされた複数のサーバ候補が選定される。」、及び段落【００２７】の「例えば、接続要求がソートジョブを起動要求するものであればメモリ資源がサーバを決める主要素となり、ファイルアクセスを起動要求する接続要求の場合にはＩ／Ｏ待ちの少なさがサーバを決める主要素となる。」参照。）等にあるように、複数の問合せ応答型サーバーに「処理の優先順序」が定められ、処理要求を「処理の優先順序が最も高い」問合せ応答型サーバーに送ることは、当業者にとって周知技術である。
　そうすると、刊行物１記載発明において、最適な計算機を選択する際に、処理の優先順序が定められた問合せ応答型サーバーのうちで処理の優先順序が最も高い問合せ応答型サーバーを選択して、クライアントからの問合せリクエストを送るようにすることは、刊行物１記載発明及び前記周知技術から当業者が適宜実施し得ることである。
　
＜相違点２＞について
　例えば、特開平０８−０１６３１３号公報（平成８年１月１９日出願公開。特に段落【００４１】−【００４８】、図１参照。）、特開平０３−１５６６６１号公報（平成３年７月４日出願公開。特に第２頁左下欄第２行−第３頁右下欄第１５行参照。）等にあるように、受信したデータを主制御部が振り分けるシステムをソフトウェアで実現することは、当業者にとって周知技術である。
　そうすると、刊行物１記載発明のコアーノードをソフトウェアで実現する際に、「問合せリクエスト送信や処理結果送信のイベントを受信しその処理を前記各管理部に振り分ける主制御部」を設けることは、刊行物１記載発明及び前記周知技術から当業者が容易に想到し得ることである。また、その際に、クライアントからの問合せリクエストを、「前記コアーノードの主制御部を介して問合せリクエスト管理部に送信」するようにすることは、当業者が適宜実施し得ることである。
　
　よって、前記＜相違点１＞及び＜相違点２＞は、格別のものとは認められない。また、前記＜相違点１＞及び＜相違点２＞によって生じる効果も、当業者が予測し得るものである。
　
　また、請求人は、平成１７年５月１２日付け審判請求書の同年７月１９日付け手続補正書において、次のとおり主張している。
　
　「ところが、本願発明は処理を「均等に」割り振ることはせずに、優先順序が高いコンピュータがフル稼働になるまではそのコンピュータに処理を集中的に依頼するのである。」
　「以上のように、引用文献１〜４のいずれも、クライアントサーバーシステムにおいて、同一の処理を行う複数のサーバー等を有し、それらのサーバー等に処理の優先順序が定められ、同一の処理に対する要求であれば、処理が可能なサーバー等のうち処理の優先順序が最も高いサーバー等に処理を依頼し、処理の優先順序が低いサーバーの稼働状態を監視することにより、処理要求に対して全体の処理能力がぎりぎりの線で過不足がないサーバーシステムを得るという本願発明の負荷分散制御の技術思想に対する開示も示唆も全くない。」
　
　しかし、本願明細書には、「処理を「均等に」割り振ることはせずに、優先順序が高いコンピュータがフル稼働になるまではそのコンピュータに処理を集中的に依頼する」ことは記載されておらず、しかも、本願明細書の段落【０１１１】には、「【発明の効果】以上の説明から明らかなように、本発明のクライアントサーバーシステムによれば、コアーノードがクライアントとサーバーの交信を仲介し、問合せリクエストに対してそれを処理可能な問合せ応答型サーバーをサーチし、処理可能であって処理の優先順序が最も高い問合せ応答型サーバーに処理を依頼する。これにより、同一処理を行う問合せ応答型サーバーが複数個存在するクライアントサーバーシステムにおいて、問合せ応答型サーバーの負荷が平均的に分散され、特定のサーバーに処理が集中することが防止され、全体として効率のよい処理を行うクライアントサーバーシステムを得ることができる。」と記載されているから、「本願発明は、処理を「均等に」割り振ることはせずに、優先順序が高いコンピュータがフル稼働になるまではそのコンピュータに処理を集中的に依頼する」という請求人の主張は、明細書の記載に基づかないものである。また、本願明細書には、「処理の優先順序が低いサーバーの稼働状態を監視することにより、処理要求に対して全体の処理能力がぎりぎりの線で過不足がないサーバーシステムを得る」という本願発明の負荷分散制御の技術思想は記載されておらず、かつ、このような負荷分散制御の技術思想は、本願明細書に記載されている、処理が集中することを防止する思想と矛盾するものであるから、請求人が主張する本願発明の負荷分散制御の技術思想も、明細書の記載に基づかないものである。
　
　したがって、請求人の主張は採用できない。
　
　以上のとおりであるから、本願補正発明は、刊行物１記載発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
５．本件補正についてのむすび
　以上のとおり、本願補正発明は、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものであるから、本件補正は、特許法第１７条の２第５項において準用する同法第１２６条第５項に規定に適合せず、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１７年６月１３日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１６年４月３０日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、次のとおりのものである。（なお、平成１７年１月１１日付け手続補正書は、平成１７年４月７日付け補正の却下の決定により、却下されている。）
　
　　【請求項１】
　問合せリクエストを受信して同一の情報処理を行って処理結果を送信する複数の問合せ応答型サーバーと、問合せリクエストを送信する複数のクライアントと、全ての前記問合せ応答型サーバーとクライアントと直接接続されたコアーノードと、を有する負荷分散制御を行うクライアントサーバーシステムにおいて、
　前記コアーノードは、
　前記クライアントの問合せリクエストの発生、処理、返信までの処理を管理する問合せリクエスト管理部と、
　問合せリクエスト送信元のクライアントを管理するリクエスト元クライアント管理部と、
　問合せリクエスト送信や処理結果送信のイベントを受信しその処理を前記各管理部に振り分ける主制御部と、を有し、
　前記クライアントからの問合せリクエストは、すべて前記コアーノードに送られ、前記コアーノードの主制御部を介して問合せリクエスト管理部に送信され、前記問合せリクエスト管理部から処理可能な問合せ応答型サーバーのうちで処理の優先順序が最も高い問合せ応答型サーバーに送られ、
　送信元のクライアントは前記コアーノードのリクエスト元クライアント管理部に登録され、
　前記問合せ応答型サーバーからの応答データは、前記コアーノードに送信され、前記コアーノードの問合せリクエスト管理部によって前記リクエスト元クライアント管理部に登録された送信元クライアントに送信される、ことを特徴とする負荷分散制御を行うクライアントサーバーシステム。
　
２．刊行物記載発明
　原査定の拒絶の理由で引用された刊行物及びその記載事項は、前記「第２．［理由］２．刊行物記載発明」に記載したとおりである。
　
３．対比・判断
　本願発明は、前記「第２．［理由］１．本件補正後の本願発明」で検討した本願補正発明から、「問合せ応答型サーバー」について、「処理の優先順序が定められた」との限定を解除するものである。
　そうすると、本願発明の構成要件を全て含み、更に他の構成要件を付加したものに相当する本願補正発明は、前記「第２．［理由］４．判断」に記載したとおり、刊行物１記載発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、刊行物１記載発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものである。
　よって、結論のとおり審決する。