【事件の表示】
　平成１１年特許願第　４３７１３号「分散処理システムおよびその方法、分散処理を行うための端末装置および記録媒体」拒絶査定不服審判事件〔平成１２年　９月　８日出願公開、特開２０００−２４２６１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯 
　本願は、平成１１年２月２２日の出願であって、平成１８年７月７日付けで拒絶理由通知がなされ、同年９月１１日付けで手続補正がなされ、平成１９年１月１８日付けで最後の拒絶理由通知がなされ、同年３月２６日付けで手続補正がなされたが、同年８月３１日付けで前記平成１９年３月２６日付けの手続補正を却下するとともに、拒絶査定がなされ、これに対し、同年１０月４日に審判請求がなされるとともに同年１０月２９日付けで手続補正がなされたものである。そして、平成２０年１月１１日付けで審査官から前置報告がなされ、平成２１年８月３１日付けで当審より審尋がなされたものである。
　 
第２．平成１９年１０月２９日付けの手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
　平成１９年１０月２９日付けの手続補正を却下する。 
　 
［理由］ 
１．補正の内容
　平成１９年１０月２９日付けの手続補正（以下「本件補正」という。）の内容は、
　平成１８年９月１１日付けの手続補正により補正された特許請求の範囲の請求項１の記載
「【請求項１】　ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうちジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」（以下、この特許請求の範囲の請求項１を「補正前の請求項１」という。）を、
　
「【請求項１】　ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」（以下、この特許請求の範囲の請求項１を「補正後の請求項１」という。）
　
　に補正することを含むものである。
　 
２．補正の適否
２−１．新規事項の有無、補正の目的要件 
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第１７条の２第３項の規定に適合する。
　そして、平成１９年１０月２９日付けの手続補正により補正された特許請求の範囲の請求項１〜２２は、それぞれ、平成１８年９月１１日付けの手続補正により補正された特許請求の範囲の請求項１〜２２に対応するものである。
　そして、本件補正の補正前の請求項１についてなされた補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例とされる同法による改正前の特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの）を目的とするものであるから、本件補正は、特許法第１７条の２第４項の規定に適合する。 
　
２−２．独立特許要件  
　補正前の請求項１についてなされた補正は、特許法１７条の２第４項第２号の特許請求の範囲の減縮を目的とすることから、補正後の請求項１に記載されている事項により特定される発明（以下「補正後の発明」という。）が、特許出願の際独立して特許を受けることができるものであるか、（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）以下に検討する。 
　
（１）補正後の発明
　前記補正前の請求項１についてなされた補正により、補正後の発明は、前記「１．補正の内容」の「補正後の請求項１」に記載された以下のものと認められる。
　
　「ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」
　
（２）引用文献 
　原査定と同時になされた補正の却下の決定の理由に引用された刊行物である「高木浩光，Ｊａｖａ言語：いま何が課題なのか　４．応用の新展開−メタコンピューティングへの応用−，情報処理，日本，社団法人情報処理学会，１９９８年４月１５日，第３９巻，第４号，第３０２頁〜第３０５頁」（以下、「引用文献１」という。）には、以下の事項が記載されている。（注：下線部は当審で便宜上付与したもの。）
　 
（ア）「１９９７年１０月，ＲＳＡ　Ｄａｔａ　ＳｅｃｕｒｉｔｙのＴｈｅ　ＲＳＡ　Ｄａｔａ　Ｓｅｃｕｒｉｔｙ　Ｓｅｃｒｅｔ−Ｋｅｙ　Ｃｈａｌｌｅｎｇｅにおいて，ｄｉｓｔｒｉｂｕｔｅｄ．ｎｅｔのチームが広域分散処埋によって５６ｂｉｔ　ＲＣ５を破ったことが話題となった．このプロジェクトでは，
問題を分割しクライアントに配布するサーバを中心に据え，部分問題を解くクライアントプログラム
ボランティアを募って彼らにこれをダウンロードして実行してもらうことで，多数のクライアントに結果を報告させる
　このような，
ネットワーク上の多数の計算機を包括的に１つの仕事のために使用するというアイデア
　
（イ）「…これらに基づくＪａｖａの安全性は，その１つの応用である「Ａｐｐｌｅｔ」のフレームワークにより実証されている．このような特徴から，不特定多数による不特定多数のためのメタコンピューティングシステムを実現する手段として，Ｊａｖａが注目されている．
Ａｐｐｌｅｔによるメタコンピューティングシステム
　このような観点に基づいて提案されたＪａｖａ　
Ａｐｐｌｅｔ によるメタコンピューティングシステム
　
（ウ）「
Ｂａｙａｎｉｈａｎ
問題ごとに個別のサーバが用意
ボランティア達がこの問題のぺージにアクセス
中央のサーバプログラムがＭａｓｔｅｒ
ＡｐｐｌｅｔがＷｏｒｋｅｒ
　
（エ）「Ｂａｙａｎｉｈａｎ」の参考文献として、「１９）Ｓａｒｍｅｎｔａ，Ｌ．Ｆ．Ｇ．，Ｈｉｒａｎｏ，Ｓ，ａｎｄ　Ｗａｒｄ，Ｓ．Ａ．：Ｗｅｂ−Ｂａｓｅｄ　Ｖｏｌｕｎｔｅｅｒ　Ｃｏｍｐｕｔｉｎｇ　Ｕｓｉｎｇ　Ｊａｖａ，Ｉｎ　Ｐｒｏｃ．　ｏｆ　ｔｈｅ　２ｎｄ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｗｏｒｌｄｗｉｄｅ　Ｃｏｍｐｕｔｉｎｇ　ａｎｄ　ｉｔｓ　Ａｐｐｌｉｃａｔｉｏｎｓ（Ｍａｒ．１９９８）．ｈｔｔｐ：／／ｗｗｗ．ｃａｇ．ｌｃｓ．ｍｉｔ．ｅｄｕ／ｂａｙａｎｉｈａｎ／」（以下、「引用文献１が引用する参考文献１」という）が巻末に挙げられている。（３０５頁）
　
　そして、前記引用文献１が引用する参考文献１を参照すると、Ｂａｙａｎｉｈａｎについて以下の事項が記載されている。（注：下線部は当審で便宜上付与したもの。）
　
（オ）「Abstract:This paper presents and discusses the idea of Web-based volunteer computing, which allows people to cooperate in solving a large parallel problem by using standard Web browsers to volunteer their computers' processing power. 」（先頭ページの「Ａｂｓｔｒａｃｔ」欄）
（和訳：要約：この論文は、ウェブに基づくボランティアによるコンピュータ処理についてのアイデアを提示し、論ずるものであって、このアイデアによって、人々が有する計算機の処理能力を自発的に提供するために標準的なウェブブラウザを利用して、人々が一つの大きな並列問題の解決に協力することが可能となる。）
　
（カ）「2.3　Java-Based Volunteer Computing 
　・・・（中略）・・・
1. Ease-of-use. In a Java-based system, volunteering takes only one step: use a Java-capable browser to visit the server web site. 」（先頭ページから４頁目の「2.3　Java-Based Volunteer Computing」欄）
（和訳：Ｊａｖａに基づくボランティアによるコンピュータ処理
１．使いやすさ．　Ｊａｖａに基づくシステムでは、ボランティアは単に一つのステップ、すなわち、Ｊａｖａを動作させられるブラウザを用いて、サーバのウェブサイトにアクセスするだけのステップを必要とするだけである。）
　
（キ）「Networks like distributed.net can be called true volunteer networks - their participants are volunteers in the true sense of the word. Specifically, they are: 
1. autonomous - they join (and leave) of their own free will. 」（先頭ページから５頁目の「3.1　True (or Altruistic) Volunteer Computing 」欄）
（和訳：distributed.netのようなネットワークは、参加者達が文字どおりボランティアであるという意味で、
真のボランティアネットワーク
１．自主的　−　
彼らは、彼らの意志で参加する
　
（ク）「At present, we are developing a flexible software framework that would make it easy to program and set-up forced or true volunteer computing networks for various useful applications.」（先頭ページから９頁目の「4　True (or Altruistic) Volunteer Computing 」欄）
（和訳：現在、我々は柔軟なソフトウェアフレームワークを開発しており、このフレームワークを用いることで、様々な有用なアプリケーションに対して強制的ボランティアネットワークまたは
真のボランティアネットワークを構築してセットアップする
　
（ケ）「Architecture.  Figure 1 shows a high-level block diagram of a system using the Bayanihan framework. 
 On the client side, an engine runs in its own thread, and takes care of receiving and processing data objects from its corresponding manager on the server. A work engine, for example, would take care of getting work data from the work manager, executing the work, and requesting more work when it's done. Data objects are generally polymorphic and know how to process themselves. To execute the work, a work engine passes the work data a pointer to itself, and calls the work data's process() method. The work data will compute itself, using the work engine to communicate with the work manager, if desired. Both the engine and the data have associated GUI objects which can be used for user interface. The engine and the GUIs are all contained in a chassis object, which can be an applet or application. 
 On the server side, an advocate object serves as the engine's representative and forwards the engine's calls to the manager. The manager has access to several data pools. These pools may be shared by other managers serving other purposes. In Fig.1, for example, the work and result pools are shared by the work and watch managers, allowing the watch manager to watch the progress of the computation and inform watch engines of such things as new results and statistics. The whole set of associated managers and data pools compose a problem. There may be many independent problems existing in a server at the same time. A problem table keeps track of these, and can be used by volunteers to choose the problem they want to participate in. 」（先頭ページから９頁目の「4.2　System Design 」欄）
（和訳：アーキテクチャ　図１は、Ｂａｙａｎｉｈａｎフレームワークを使ったハイレベルのブロックダイヤグラムを示す。
　クライアント側においては、一つのエンジンがそのスレッドで動作し、サーバ上で動作する対応するマネージャとの間で、データオブジェクトを受信し、処理する仕事を引き受ける。例えば
ワークエンジンは、ワークマネージャからワークデータを取得し、そのワークを処理し、そのワークの処理が終了したら、ワークマネージャに対してさらに別のワークの取得要求を行う
アプレットまたはアプリケーションであるシャシーオブジェクト
　サーバ側においては、一つの代理オブジェクトがエンジンの代理として動作し、
エンジンからのＣＡＬＬ
ワークプールと成果プール
複数のデータプールのひとまとまりのセットが問題を形成
ボランティアが参加したい問題を選択する
　
（コ）「Fig.1. A Bayanihan system」には、クライアント側において、アプレットまたはアプリケーションであるシャシーオブジェクトの中の
ワークエンジンがワークマネージャからワークデータプールにプールされたワークデータを取得して処理
ワークマネージャがワークデータプールと結果データプールをハンドリング
　
　（ア）における記載「問題を分割しクライアントに配布するサーバを中心に据え，部分問題を解くクライアントプログラムをＷｉｎｄｏｗｓやＭａｃＯＳをも含む各種ＯＳ用のバイナリ形式で用意し，ボランティアを募って彼らにこれをダウンロードして実行してもらうことで，多数のクライアントに結果を報告させるという方法をとった．　…　このような，ネットワーク上の多数の計算機を包括的に１つの仕事のために使用するというアイデアは，「メタコンピューテイング」として知られ，」、（イ）における記載「Ｊａｖａ　Ａｐｐｌｅｔ によるメタコンピューティングシステムに，…Ｂａｙａｎｉｈａｎ１９）などがある．」、（ウ）における記載「Ｂａｙａｎｉｈａｎは，ボランティアによる計算を指向しており，できるだけ多くのボランティアを集めるためか，計算の過程を見せることに重点が置かれている．…問題ごとに個別のサーバが用意され，ボランティア達がこの問題のぺージにアクセスすることで計算が行われる．システムはいわゆるＭａｓｔｅｒ−Ｗｏｒｋｅｒパターンに基づいており，中央のサーバプログラムがＭａｓｔｅｒとして，ＡｐｐｌｅｔがＷｏｒｋｅｒとして動作する．Ｗｏｒｋｅｒには対応するＧＵＩのフレームワークが用意されており，プログラマは，目的のアプリケーションの計算ルーチンと，その結果を表示するメソッドを実装する．」、（ケ）における記載「クライアント側においては、一つのエンジンがそのスレッドで動作し、サーバ上で動作する対応するマネージャとの間で、データオブジェクトを受信し、処理する仕事を引き受ける。　…　ワークを処理するために、ワークエンジンは、ワークデータを自身のポインタにパスして、ワークデータのｐｒｏｃｅｓｓ（）メソッドを呼び出す。　…　ワークプールと成果プールとは、ワークマネージャ及び監視マネージャによって共有されており、そうすることで、監視マネージャは、コンピュータ処理の進捗状況を監視して、新しい成果や統計のような事柄を監視エンジンに報告することが可能となる。これらの関連する複数のマネージャ及び複数のデータプールのひとまとまりのセットが問題を形成する。」、及び（コ）における記載「クライアント側において、アプレットまたはアプリケーションであるシャシーオブジェクトの中のワークエンジンがワークマネージャからワークデータプールにプールされたワークデータを取得して処理する」からすると、Ｂａｙａｎｉｈａｎは、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行するメタコンピューティングシステムであると解される。
　
　（ウ）における記載「システムはいわゆるＭａｓｔｅｒ−Ｗｏｒｋｅｒパターンに基づいており，中央のサーバプログラムがＭａｓｔｅｒとして，ＡｐｐｌｅｔがＷｏｒｋｅｒとして動作する．Ｗｏｒｋｅｒには対応するＧＵＩのフレームワークが用意されており，プログラマは，目的のアプリケーションの計算ルーチンと，その結果を表示するメソッドを実装する．」からすると、Ｂａｙａｎｉｈａｎは、Ｍａｓｔｅｒ−Ｗｏｒｋｅｒパターンに基づいて分散実行するシステムであって、Ｍａｓｔｅｒとしてのサーバ及びＷｏｒｋｅｒとして動作するアプレットを動作させる複数のボランティアの計算機とから構成されるメタコンピューティングシステムであると解される。
　
　（ケ）における記載「サーバ上で動作するマネージャは、いくつかのデータプールにアクセスする。これらのデータプールは、いろいろな目的のために別の，マネージャと共有されてもよい。例えば、図１に記載されているように、ワークプールと成果プールとは、ワークマネージャ及び監視マネージャによって共有されており　…　可能となる。これらの関連する複数のマネージャ及び複数のデータプールのひとまとまりのセットが問題を形成する。」及び（コ）における「Fig.1. A Bayanihan system」に関する説明「サーバ側において、ワークマネージャがワークデータプールと結果データプールをハンドリングする」からすると、Ｂａｙａｎｉｈａｎにおいて、サーバ上で動作するワークマネージャは、問題を形成する複数のワークデータをプールするためのプールであって、前記プールは、ワークデータをプールするワークデータプールと結果データをプールする結果データプールとからなるプールを有していると解される。
　
　そして、（ウ）における記載「システムはいわゆるＭａｓｔｅｒ−Ｗｏｒｋｅｒパターンに基づいており，中央のサーバプログラムがＭａｓｔｅｒとして，ＡｐｐｌｅｔがＷｏｒｋｅｒとして動作する．Ｗｏｒｋｅｒには対応するＧＵＩのフレームワークが用意されており，プログラマは，目的のアプリケーションの計算ルーチンと，その結果を表示するメソッドを実装する．」、（キ）における記載「真のボランティアネットワークと呼ぶことができる。…彼らは、彼らの意志で参加する（またはやめる）。」、及び（ケ）における記載「ワークエンジンは、ワークマネージャからワークデータを取得し、そのワークを処理し、そのワークの処理が終了したら、ワークマネージャに対してさらに別のワークの取得要求を行う仕事を引き受ける。　…　サーバ側においては、一つの代理オブジェクトがエンジンの代理として動作し、エンジンからのＣＡＬＬをマネージャに転送する。　…　ボランティアが参加したい問題を選択するために、用いることができる。」からすると、Ｂａｙａｎｉｈａｎにおいて、ボランティアの意志に基づいて、前記ボランティアの計算機は、Ｍａｓｔｅｒとしてのサーバにアクセスして問題に対応するＷｏｒｋｅｒとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行い、前記サーバ上で動作するワークマネージャは、該取得要求をした前記ボランティアの計算機に対してワークデータプールにプールされたワークデータを与えると解される。
　
　したがって、引用文献１及び引用文献１が引用する参考文献１からすると、少なくとも以下のように構成された「Ｂａｙａｎｉｈａｎ」が、本願の特許出願前に日本国内又は外国において公然知られた発明（以下、「引用発明１」という。）であったものと解される。
　
　Ｂａｙａｎｉｈａｎは、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行するメタコンピューティングシステムであって、
　前記メタコンピューティングシステムは、Ｍａｓｔｅｒ−Ｗｏｒｋｅｒパターンに基づいて分散実行するシステムであって、Ｍａｓｔｅｒとしてのサーバ及びＷｏｒｋｅｒとして動作するアプレットを動作させる複数のボランティアの計算機とから構成されるシステムであって、
　前記サーバ上で動作するワークマネージャは、
　前記問題を形成する複数のワークデータをプールするためのプールであって、前記プールは、ワークデータをプールするワークデータプールと結果データをプールする結果データプールとからなるプールを有し、
　前記ボランティアの計算機は、ボランティアの意志に基づいて、Ｍａｓｔｅｒとしてのサーバにアクセスして問題に対応するＷｏｒｋｅｒとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行い、
　前記サーバ上で動作するワークマネージャは、該取得要求をした前記ボランティアの計算機に対してワークデータプールにプールされたワークデータを与えることを特徴とするメタコンピューティングシステム。
　
（３）対比 
　そこで、補正後の発明と引用発明１とを対比する。
　引用発明１の「メタコンピューティングシステム」は、補正後の発明の「分散処理システム」に相当する。
　引用発明１の「ボランティア」は、補正後の発明の「ユーザ」に相当する。
　そして、引用発明１の「メタコンピューティングシステム」は、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行することから、引用発明１の「問題」及び「ワークデータ」は、それぞれ、補正後の発明の「ジョブ」及び「分割ジョブ」に相当する。
　引用発明１の「ボランティアの意志に基づいて、Ｍａｓｔｅｒとしてのサーバにアクセスして問題に対応するＷｏｒｋｅｒとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行う」ボランティアの計算機は、補正後の発明の「計算機のユーザの指示に基づくジョブ取得要求が行われた計算機」に相当する。
　引用発明１のサーバ上で動作するワークマネージャは、複数のボランティアの計算機のうち、ボランティアの意志に基づくワークデータ取得要求が行われた計算機に対して、ワークデータプールにプールされたワークデータを与えると解されるから、引用発明１の「ワークマネージャ」は、補正後の発明の「ジョブ配信手段」に相当する。
　
　そして、引用発明１の「ワークデータプールにプールされたワークデータ」と、補正後の発明の「ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブ」とは、ともに、ジョブから分割された複数の分割ジョブのうち所定の分割ジョブである点で一致する。
　
　よって、補正後の発明と引用発明１とは、以下の点で一致し、また、相違している。 
　 
（一致点） 
　ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち、所定の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。
　
（相違点）
　「所定の分割ジョブ」について、補正後の発明は「未処理の分割ジョブ」であるのに対して、引用発明１は「ワークデータプールにプールされたワークデータ」が未処理であるかどうか明らかでない点。
　
（４）判断
　相違点について検討する。
　（ケ）及び（コ）における記載からすると、結果データプールにプールされた結果データは、処理済みデータであると解される。
　そして、Ｂａｙａｎｉｈａｎの目的が、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して問題を形成する複数のワークデータの各ワークデータを処理することであることを勘案すれば、前記ボランティアの取得要求に対して、未処理のワークデータを与えることは、当然に想定し得たことである。
　よって、上記相違点は格別のものではない。
　
　そして、補正後の発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、補正後の発明は上記引用発明１に基づいて容易に発明できたものである。
　
３．むすび
　以上のとおり、補正後の発明は、その出願前日本国内又は外国において公然知られた発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定に該当し、特許出願の際独立して特許を受けることができるものでなく、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　よって、前記補正前の請求項１についてする補正を含む本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
（備考）
　なお、１９９８年９月３日にSouthampton, UKで開催されたEuroPar'98のEuroTools Workshop on Tools for High Performance Metacomputingで発表されたスライド“Bayanihan  Web-Based Volunteer Computing Using Java”
（インターネット＜http://groups.csail.mit.edu/cag/bayanihan/papers/eurotools98/slides/＞）を参照すると、スライド９頁に、Ｍａｓｔｅｒ−Ｗｏｒｋｅｒ　Ｍｏｄｅｌによるクラス図が記載され、その中でクライアント側のワークエンジン（ＷｏｒｋＥｎｇｉｎｅ）が、サーバ側のワークマネージャ（ＷｏｒｋＭａｎａｇｅｒ）に対してｇｅｔＷｏｒｋ（）メソッドＣａｌｌをして、それに対して前記ワークマネージャがワークプール（ＷｏｒｋＰｏｏｌ）からｇｅｔＮｅｘｔＵｎｄｏｎｅＷｏｒｋ（）メソッドを発行する様子が記載され、
スライド１６頁に、
「 - uses circular work pool so undone work can be reassigned」
（和訳：−　ワークプールをサイクリックに使うことで、未処理のワークを割り当て直す。）と記載されている。
　してみると、前記「Ｂａｙａｎｉｈａｎ」が、前記引用発明１の構成に加えて、サーバ上で動作するワークマネージャが、ワークデータの取得要求をしたボランティアの計算機に対してワークデータプールにプールされたワークデータのうち未処理のワークデータを与える構成を有していたこと（当該発明を以下、「引用発明１′」という。）は、本願の特許出願前の１９９８年９月３日に日本国内又は外国において公然知られていたと推定される。
　よって、その場合には、補正後の発明は、本願の特許出願前に日本国内又は外国において公然知られた発明である引用発明１′と実質的に同一の発明であるから、特許法第２９条第１項第３号に該当し、補正後の発明は、特許出願の際独立して特許を受けることができるものではなく、記補正前の請求項１についてする補正を含む本件補正は、依然として特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである旨を指摘しておく。
　
第３．本願発明について 
１．本願発明
　平成１９年１０月２９日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成１８年９月１１日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。 
　 
　「ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうちジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」 
　 
２．引用文献 
　原査定の拒絶の理由に引用された、特開平１１−１５７９９号公報に（以下、「引用文献２」という。）には以下の事項が記載されている。（注意：下線は便宜上、当審にて付与したもの。）
　
（Ａ）「【００１０】
【課題を解決するための手段】本発明は、処理負荷に応じて
外部装置の演算部を利用して並列処理を行う並列処理システム
　
（Ｂ）「【００１６】前記の外部装置の演算部として、例えば
家庭用電化製品や事務機器に用いられているマイクロプロセッサ
　
（Ｃ）「【００１９】図１は、本実施形態の並列処理システムの概略構成を示す図である。図１に示す様に本実施形態の並列処理システムは、処理負荷に応じて外部装置１０１〜１０３の演算部１１１〜１１３を利用して
並列処理を行うコンピュータ１００
外部装置１０１〜１０３
通信ケーブル１７７を介して接続
　
（Ｄ）「【００２８】本実施形態の並列処理システムでは、演算部１１０〜１１３を並列処理制御部１４０、
処理能力通知部
稼働状況通知部
として機能させる為のプログラム
　
（Ｅ）「【００３７】次に、図１を用いて本実施形態の並列処理システムの動作を説明する。まず、演算部１１０〜１１３は、電源が投入されると初期化処理を行う。
【００３８】次に、コンピュータ１００は、パラレル・インタフェース１７４を介して補助記憶装置１７５から基本プログラム、並列処理制御部１４０、処理能力通知部１５０、稼働状況通知部１６０及び必要に応じアプリケーション・プログラムをロードし、メモリ１２０に常駐させる。
【００３９】次に、コンピュータ１００は、ユーザの要求をシリアル・インタフェース１７２を介して入力装置１７３から読込み、必要な処理を順次実行する。
【００４０】また、外部装置１０１〜１０３は、メモリ１２１〜１２３に格納されている処理能力通知部１５１〜１５３及び稼働状況通知部１６１〜１６３を起動すると共に、必要に応じて特定の処理プログラムを起動して当該装置独自の機能を実行する。
【００４１】次に、処理能力通知部１５１〜１５３は、演算部１１０〜１１３の夫々で実行可能な単位時間当たりの命令数であるＭＩＰＳ値等の処理能力値を、予め格納された特定のレジスタ等の記憶領域から読み出し、読み出した処理能力値を必要に応じてデータとして出力可能な状態を保持する。
【００４２】また、稼働状況通知部１６０〜１６３は、演算部１１０〜１１３の夫々で実行中の単位時間当たりの命令数である処理負荷値を、特定時間中に実行した命令数を計測して算出し、算出した処理負荷値を必要に応じてデータとして出力可能な状態を保持する。
【００４３】コンピュータ１００の並列処理制御部１４０は、特定の処理を実行するタスクが発生すると、処理能力通知部１５０が読み出した処理能力値と稼働状況通知部１６０が算出した処理負荷値とから演算部１１０の余剰処理能力値を求め、前記特定の処理の実行に必要な必要処理能力値と比較する。
【００４４】並列処理制御部１４０は、前記比較の結果、前記特定の処理の実行に必要な必要処理能力値が演算部１１０の余剰処理能力値を上回る場合や、前記特定の処理を演算部１１０で実行すると演算部１１０の処理負荷値が所定閾値を上回る場合に、
前記特定の処理を分割し外部装置１０１〜１０３に分配して実行させる
【００４５】すなわち、並列処理制御部１４０は、通信アダプタ１３０〜１３３及び通信ケーブル１７７を介し、外部装置１０１〜１０３の演算部１１１〜１１３の処理能力値及び処理負荷値を処理能力通知部１５１〜１５３及び稼働状況通知部１６１〜１６３から順次読み込んで、演算部１１０で不足している処理能力値を充足するまで、演算部１１１〜１１３の余剰処理能力値を求める処理を行う。
【００４６】並列処理制御部１４０は、演算部１１０の不足処理能力値が演算部１１１〜１１３の余剰処理能力値の和で充足されたなら、演算部１１０に割り当てられていた前記特定の処理を、演算部１１１〜１１３の個々の余剰処理能力値の割合に合わせて分割し、
分割した処理を
分配
　
　上記（Ａ）の段落【００１０】における記載「本発明は、処理負荷に応じて外部装置の演算部を利用して並列処理を行う並列処理システムであって、…」、（Ｂ）の段落【００１６】における記載「前記の外部装置の演算部として、例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサを利用する…」、及び（Ｃ）の段落【００１９】における記載「本実施形態の並列処理システムは、処理負荷に応じて外部装置１０１〜１０３の演算部１１１〜１１３を利用して並列処理を行うコンピュータ１００と、演算部１１１〜１１３を備える外部装置１０１〜１０３とを通信ケーブル１７７を介して接続している。」からすると、引用文献２には、ネットワークに接続されたコンピュータと外部装置（例えば家庭用電化製品や事務機器）とからなる分散並列システムであって、前記コンピュータは、前記ネットワーク上に分散して存在する複数の外部装置の演算部（例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ）を利用して並列処理を行う並列処理システムに関する発明が記載されていると解される。
　
　（Ｅ）の段落【００４３】における記載「コンピュータ１００の並列処理制御部１４０は、特定の処理を実行するタスクが発生すると、…演算部１１０の余剰処理能力値を求め、…」、（Ｅ）の段落【００４４】における記載「並列処理制御部１４０は、…前記特定の処理の実行に必要な必要処理能力値が演算部１１０の余剰処理能力値…や、前記特定の処理を演算部１１０で実行すると演算部１１０の処理負荷値が所定閾値を上回る場合に、前記特定の処理を分割し外部装置１０１〜１０３に分配して実行させる処理を行う。」、（Ｅ）の段落【００４５】における記載「並列処理制御部１４０は、…外部装置１０１〜１０３の演算部１１１〜１１３の処理能力値及び処理負荷値を…順次読み込んで、演算部１１０で不足している処理能力値を充足するまで、演算部１１１〜１１３の余剰処理能力値を求める処理を行う。」、及び（Ｅ）の段落【００４６】における記載「並列処理制御部１４０は、演算部１１０の不足処理能力値が演算部１１１〜１１３の余剰処理能力値の和で充足されたなら、演算部１１０に割り当てられていた前記特定の処理を、演算部１１１〜１１３の個々の余剰処理能力値の割合に合わせて分割し、分割した処理を通信アダプタ１３０〜１３３及び通信ケーブル１７７を介して、外部装置１０１〜１０３の演算部１１１〜１１３に分配する。」からすると、前記並列処理システムにおけるコンピュータの並列処理制御部は、上記複数の外部装置の演算部に対して、前記処理から分割された複数の分割した処理のうち、前記コンピュータの演算部で処理できない、すなわち未処理の分割した処理を分配すると解される。
　
　（Ｄ）の段落【００２８】における記載「本実施形態の並列処理システムでは、演算部１１０〜１１３を並列処理制御部１４０、処理能力通知部１５０〜１５３または稼働状況通知部１６０〜１６３として機能させる為のプログラムがメモリ１２０〜１２３に記録されているものとする。」、（Ｅ）の段落【００４０】における記載「外部装置１０１〜１０３は、メモリ１２１〜１２３に格納されている処理能力通知部１５１〜１５３及び稼働状況通知部１６１〜１６３を起動すると共に、必要に応じて特定の処理プログラムを起動して当該装置独自の機能を実行する。」、（Ｅ）の段落【００４１】における記載「処理能力通知部１５１〜１５３は、演算部１１０〜１１３の夫々で実行可能な単位時間当たりの命令数であるＭＩＰＳ値等の処理能力値を、…必要に応じてデータとして出力可能な状態を保持する。」、及び（Ｅ）の段落【００４２】における記載「稼働状況通知部１６０〜１６３は、演算部１１０〜１１３の夫々で実行中の単位時間当たりの命令数である処理負荷値を、…必要に応じてデータとして出力可能な状態を保持する。」からすると、複数の外部装置（例えば家庭用電化製品や事務機器）のうち、前記コンピュータの並列処理制御部から分配される外部装置は、当該装置独自の機能を実行する特定の処理プログラムの外に、処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムを起動しておくことが必要であると解される。
　すなわち、前記コンピュータの並列処理制御部は、複数の外部装置のうち、前記処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している外部装置に対して、未処理の分割した処理を分配すると解される。
　
　よって、（Ａ）〜（Ｅ）における記載及び関連する図面からすると、引用文献２には、次の発明（以下、「引用発明２」という。）が記載されているものと認められる。 
　
　ネットワーク上に分散して存在する複数の外部装置の演算部（例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ）を利用して並列処理を行う並列処理システムであって、
　上記複数の外部装置の演算部のうち、処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部に対して、上記処理から分割された複数の分割した処理のうち未処理の分割した処理を分配する並列処理制御部を備えることを特徴とする並列処理システム。
　
３．対比
　そこで、本願発明と引用発明２とを対比する。
　引用発明２の「外部装置の演算部（例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ）」は、本願発明の「計算機」に相当する。
　引用発明２の「処理」は、本願発明の「ジョブ」に相当する。
　引用発明２の「並列処理を行う並列処理システム」は、本願発明の「ジョブを分散実行する分散処理システム」に相当する。
　引用発明２の「分割した処理を分配する」は、本願発明の「分割ジョブを与える」に相当する。
　そして、引用発明２の「並列処理制御部」は、本願発明の「ジョブ配信手段」に相当する。
　引用発明２の「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部」と、本願発明の「ジョブ取得要求が行われた計算機」とは、ともに、分散処理可能に設定された計算機である点で一致する。
　よって、本願発明と引用発明２とは、以下の点で一致し、また、相違している。 
　 
（一致点） 
　ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
　上記複数の計算機のうち分散処理可能に設定された計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。
　
（相違点）
　「分散処理可能に設定された計算機」について、本願発明は「ジョブ取得要求が行われた計算機」であるのに対して、引用発明２は「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部」である点。
　
４．判断 
　相違点について検討する。
　原査定の拒絶の理由に引用された、特開平９−３４７３３号公報（以下、「引用文献３」という。）における記載（注意：下線は便宜上、当審にて付与したもの。）、
「【要約】…
【課題】…
【解決手段】  伝送路上に複数の計算機が接続され、
１つの計算機のプロセス送信部から他の計算機のプロセス受信部にプロセスを移動させる
「【０００５】本発明は、…システムの負荷状況に応じて、再分散のための条件値を変更することにより、
システム全体の負荷の分散
分散スケジューリングシステム
「【００１５】…
ＬＡＮ１上には複数の計算機２〜４が接続
「【００２４】プロセス受信可能放送部３２は、…計算機２の負荷状況がプロセス受信可能条件設定部３１にて設定されたプロセス受信可能条件を満たすか否かを判定し、プロセス受信可能条件を満たすと判定された場合に、他の計算機３，４に
自計算機の負荷情報を含んだ受信可能メッセージを送信
「【００２６】…プロセス受信要求放送部３５は、他の計算機から送信された送信要求メッセージを受信した場合に、…プロセス受信可能条件を満たすと判定された場合に、他の全計算機に自計算機の負荷情報を含んだ受信可能メッセージを送信する。」、
「【００３２】…他の計算機から送信された…
受信可能メッセージが受信されると
移動するプロセスが決定され
移動する先の計算機が決定され
【００３３】…プロセス移動部２６により、移動プロセス決定部２４にて決定された自己の負荷状況を含む
プロセスが
決定された計算機に送信される
　
　ネットワーク上に分散して存在する複数の計算機を利用してプロセスを分散実行する分散スケジューリングシステムであって、
　上記複数の計算機のうち、受信可能メッセージを送信した計算機に対して、処理プロセスのうち他の計算機に移動するプロセスを送信する手段を備えることを特徴とする分散スケジューリングシステム。
　
　そして、引用発明２と引用発明３とは、ともに、ネットワーク上に分散して存在する複数の計算機を利用して処理を分散実行する分散処理システムである点で共通の分野に属するものといえる。
　してみると、分散処理可能に設定された演算部として、引用発明２記載の「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している」演算部に代えて引用発明３記載の「受信可能メッセージを送信した」計算機（「演算部」に相当）を採用することは、当業者であれば、容易に想到し得たことである。
　そして、「受信可能メッセージ」は、プロセスの受信要求を意味することから、「受信可能メッセージを送信した」計算機は、本願発明の「ジョブ取得要求が行われた計算機」に相当する。
　よって、上記相違点は格別のものではない。
　
　そして、本願発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、本願発明は上記引用発明２及び引用発明３に基づいて容易に発明できたものである
　
５．むすび
　以上のとおり、本願の請求項１に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。