• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1220250
審判番号 不服2007-27318  
総通号数 129 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-09-24 
種別 拒絶査定不服の審決 
審判請求日 2007-10-04 
確定日 2010-07-15 
事件の表示 平成11年特許願第 43713号「分散処理システムおよびその方法、分散処理を行うための端末装置および記録媒体」拒絶査定不服審判事件〔平成12年 9月 8日出願公開、特開2000-242614〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、平成11年2月22日の出願であって、平成18年7月7日付けで拒絶理由通知がなされ、同年9月11日付けで手続補正がなされ、平成19年1月18日付けで最後の拒絶理由通知がなされ、同年3月26日付けで手続補正がなされたが、同年8月31日付けで前記平成19年3月26日付けの手続補正を却下するとともに、拒絶査定がなされ、これに対し、同年10月4日に審判請求がなされるとともに同年10月29日付けで手続補正がなされたものである。そして、平成20年1月11日付けで審査官から前置報告がなされ、平成21年8月31日付けで当審より審尋がなされたものである。

第2.平成19年10月29日付けの手続補正についての補正却下の決定
[補正却下の決定の結論]
平成19年10月29日付けの手続補正を却下する。

[理由]
1.補正の内容
平成19年10月29日付けの手続補正(以下「本件補正」という。)の内容は、
平成18年9月11日付けの手続補正により補正された特許請求の範囲の請求項1の記載
「【請求項1】 ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうちジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」(以下、この特許請求の範囲の請求項1を「補正前の請求項1」という。)を、

「【請求項1】 ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」(以下、この特許請求の範囲の請求項1を「補正後の請求項1」という。)

に補正することを含むものである。

2.補正の適否
2-1.新規事項の有無、補正の目的要件
本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第17条の2第3項の規定に適合する。
そして、平成19年10月29日付けの手続補正により補正された特許請求の範囲の請求項1?22は、それぞれ、平成18年9月11日付けの手続補正により補正された特許請求の範囲の請求項1?22に対応するものである。
そして、本件補正の補正前の請求項1についてなされた補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例とされる同法による改正前の特許法第17条の2第4項第2号の特許請求の範囲の減縮(請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの)を目的とするものであるから、本件補正は、特許法第17条の2第4項の規定に適合する。

2-2.独立特許要件
補正前の請求項1についてなされた補正は、特許法17条の2第4項第2号の特許請求の範囲の減縮を目的とすることから、補正後の請求項1に記載されている事項により特定される発明(以下「補正後の発明」という。)が、特許出願の際独立して特許を受けることができるものであるか、(平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)以下に検討する。

(1)補正後の発明
前記補正前の請求項1についてなされた補正により、補正後の発明は、前記「1.補正の内容」の「補正後の請求項1」に記載された以下のものと認められる。

「ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」

(2)引用文献
原査定と同時になされた補正の却下の決定の理由に引用された刊行物である「高木浩光,Java言語:いま何が課題なのか 4.応用の新展開-メタコンピューティングへの応用-,情報処理,日本,社団法人情報処理学会,1998年4月15日,第39巻,第4号,第302頁?第305頁」(以下、「引用文献1」という。)には、以下の事項が記載されている。(注:下線部は当審で便宜上付与したもの。)

(ア)「1997年10月,RSA Data SecurityのThe RSA Data Security Secret-Key Challengeにおいて,distributed.netのチームが広域分散処埋によって56bit RC5を破ったことが話題となった.このプロジェクトでは,問題を分割しクライアントに配布するサーバを中心に据え,部分問題を解くクライアントプログラムをWindowsやMacOSをも含む各種OS用のバイナリ形式で用意し,ボランティアを募って彼らにこれをダウンロードして実行してもらうことで,多数のクライアントに結果を報告させるという方法をとった.56bit RC5は250日ほどで破られ,この間50万もの異なるIPアドレスの計算機が参加したという.
このような,ネットワーク上の多数の計算機を包括的に1つの仕事のために使用するというアイデアは,「メタコンピューテイング」として知られ,近年,ネットワーキング技術の進歩とインターネットの爆発的な拡大により,現実のものとして再び注目されてきている.」(302頁左欄2行目?24行目。)

(イ)「…これらに基づくJavaの安全性は,その1つの応用である「Applet」のフレームワークにより実証されている.このような特徴から,不特定多数による不特定多数のためのメタコンピューティングシステムを実現する手段として,Javaが注目されている.
Appletによるメタコンピューティングシステム
このような観点に基づいて提案されたJava Applet によるメタコンピューティングシステムに,…Bayanihan^(19))などがある.」(303頁左欄下から15行目?下から5行目。)

(ウ)「Bayanihanは,ボランティアによる計算を指向しており,できるだけ多くのボランティアを集めるためか,計算の過程を見せることに重点が置かれている.Javelinにおけるブローカに相当する仕組みはなく,問題ごとに個別のサーバが用意され,ボランティア達がこの問題のぺージにアクセスすることで計算が行われる.システムはいわゆるMaster-Workerパターンに基づいており,中央のサーバプログラムがMasterとして,AppletがWorkerとして動作する.Workerには対応するGUIのフレームワークが用意されており,プログラマは,目的のアプリケーションの計算ルーチンと,その結果を表示するメソッドを実装する.」(304頁左欄5行目?16行目。)

(エ)「Bayanihan」の参考文献として、「19)Sarmenta,L.F.G.,Hirano,S,and Ward,S.A.:Web-Based Volunteer Computing Using Java,In Proc. of the 2nd International Conference on Worldwide Computing and its Applications(Mar.1998).http://www.cag.lcs.mit.edu/bayanihan/」(以下、「引用文献1が引用する参考文献1」という)が巻末に挙げられている。(305頁)

そして、前記引用文献1が引用する参考文献1を参照すると、Bayanihanについて以下の事項が記載されている。(注:下線部は当審で便宜上付与したもの。)

(オ)「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. 」(先頭ページの「Abstract」欄)
(和訳:要約:この論文は、ウェブに基づくボランティアによるコンピュータ処理についてのアイデアを提示し、論ずるものであって、このアイデアによって、人々が有する計算機の処理能力を自発的に提供するために標準的なウェブブラウザを利用して、人々が一つの大きな並列問題の解決に協力することが可能となる。)

(カ)「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. 」(先頭ページから4頁目の「2.3 Java-Based Volunteer Computing」欄)
(和訳:Javaに基づくボランティアによるコンピュータ処理
1.使いやすさ. Javaに基づくシステムでは、ボランティアは単に一つのステップ、すなわち、Javaを動作させられるブラウザを用いて、サーバのウェブサイトにアクセスするだけのステップを必要とするだけである。)

(キ)「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. 」(先頭ページから5頁目の「3.1 True (or Altruistic) Volunteer Computing 」欄)
(和訳:distributed.netのようなネットワークは、参加者達が文字どおりボランティアであるという意味で、真のボランティアネットワークと呼ぶことができる。特に、彼らは、
1.自主的 - 彼らは、彼らの意志で参加する(またはやめる)。)

(ク)「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.」(先頭ページから9頁目の「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. 」(先頭ページから9頁目の「4.2 System Design 」欄)
(和訳:アーキテクチャ 図1は、Bayanihanフレームワークを使ったハイレベルのブロックダイヤグラムを示す。
クライアント側においては、一つのエンジンがそのスレッドで動作し、サーバ上で動作する対応するマネージャとの間で、データオブジェクトを受信し、処理する仕事を引き受ける。例えばワークエンジンは、ワークマネージャからワークデータを取得し、そのワークを処理し、そのワークの処理が終了したら、ワークマネージャに対してさらに別のワークの取得要求を行う仕事を引き受ける。データオブジェクトは、通常ポリモルフィックであって、どのように処理するかを自身で知っている。ワークを処理するために、ワークエンジンは、ワークデータを自身のポインタにパスして、ワークデータのprocess()メソッドを呼び出す。ワークデータは、必要ならば、ワークマネージャと交信するためにワークエンジンを使いながら、自分自身で計算する。エンジンとデータとはともに、ユーザインタフェースのために用いられるGUIオブジェクトに関連付けられている。このエンジンと様々なGUIは全て、アプレットまたはアプリケーションであるシャシーオブジェクトに含まれる。
サーバ側においては、一つの代理オブジェクトがエンジンの代理として動作し、エンジンからのCALLをマネージャに転送する。サーバ上で動作するマネージャは、いくつかのデータプールにアクセスする。これらのデータプールは、いろいろな目的のために別の,マネージャと共有されてもよい。例えば、図1に記載されているように、ワークプールと成果プールとは、ワークマネージャ及び監視マネージャによって共有されており、そうすることで、監視マネージャは、コンピュータ処理の進捗状況を監視して、新しい成果や統計のような事柄を監視エンジンに報告することが可能となる。これらの関連する複数のマネージャ及び複数のデータプールのひとまとまりのセットが問題を形成する。同時に、複数の互いに独立した問題が、ひとつのサーバに存在してもよい。問題テーブルがこれらの問題を絶えず追跡しており、ボランティアが参加したい問題を選択するために、用いることができる。)

(コ)「Fig.1. A Bayanihan system」には、クライアント側において、アプレットまたはアプリケーションであるシャシーオブジェクトの中のワークエンジンがワークマネージャからワークデータプールにプールされたワークデータを取得して処理することと、サーバ側において、ワークマネージャがワークデータプールと結果データプールをハンドリングすることが記載されている。

(ア)における記載「問題を分割しクライアントに配布するサーバを中心に据え,部分問題を解くクライアントプログラムをWindowsやMacOSをも含む各種OS用のバイナリ形式で用意し,ボランティアを募って彼らにこれをダウンロードして実行してもらうことで,多数のクライアントに結果を報告させるという方法をとった. … このような,ネットワーク上の多数の計算機を包括的に1つの仕事のために使用するというアイデアは,「メタコンピューテイング」として知られ,」、(イ)における記載「Java Applet によるメタコンピューティングシステムに,…Bayanihan^(19))などがある.」、(ウ)における記載「Bayanihanは,ボランティアによる計算を指向しており,できるだけ多くのボランティアを集めるためか,計算の過程を見せることに重点が置かれている.…問題ごとに個別のサーバが用意され,ボランティア達がこの問題のぺージにアクセスすることで計算が行われる.システムはいわゆるMaster-Workerパターンに基づいており,中央のサーバプログラムがMasterとして,AppletがWorkerとして動作する.Workerには対応するGUIのフレームワークが用意されており,プログラマは,目的のアプリケーションの計算ルーチンと,その結果を表示するメソッドを実装する.」、(ケ)における記載「クライアント側においては、一つのエンジンがそのスレッドで動作し、サーバ上で動作する対応するマネージャとの間で、データオブジェクトを受信し、処理する仕事を引き受ける。 … ワークを処理するために、ワークエンジンは、ワークデータを自身のポインタにパスして、ワークデータのprocess()メソッドを呼び出す。 … ワークプールと成果プールとは、ワークマネージャ及び監視マネージャによって共有されており、そうすることで、監視マネージャは、コンピュータ処理の進捗状況を監視して、新しい成果や統計のような事柄を監視エンジンに報告することが可能となる。これらの関連する複数のマネージャ及び複数のデータプールのひとまとまりのセットが問題を形成する。」、及び(コ)における記載「クライアント側において、アプレットまたはアプリケーションであるシャシーオブジェクトの中のワークエンジンがワークマネージャからワークデータプールにプールされたワークデータを取得して処理する」からすると、Bayanihanは、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行するメタコンピューティングシステムであると解される。

(ウ)における記載「システムはいわゆるMaster-Workerパターンに基づいており,中央のサーバプログラムがMasterとして,AppletがWorkerとして動作する.Workerには対応するGUIのフレームワークが用意されており,プログラマは,目的のアプリケーションの計算ルーチンと,その結果を表示するメソッドを実装する.」からすると、Bayanihanは、Master-Workerパターンに基づいて分散実行するシステムであって、Masterとしてのサーバ及びWorkerとして動作するアプレットを動作させる複数のボランティアの計算機とから構成されるメタコンピューティングシステムであると解される。

(ケ)における記載「サーバ上で動作するマネージャは、いくつかのデータプールにアクセスする。これらのデータプールは、いろいろな目的のために別の,マネージャと共有されてもよい。例えば、図1に記載されているように、ワークプールと成果プールとは、ワークマネージャ及び監視マネージャによって共有されており … 可能となる。これらの関連する複数のマネージャ及び複数のデータプールのひとまとまりのセットが問題を形成する。」及び(コ)における「Fig.1. A Bayanihan system」に関する説明「サーバ側において、ワークマネージャがワークデータプールと結果データプールをハンドリングする」からすると、Bayanihanにおいて、サーバ上で動作するワークマネージャは、問題を形成する複数のワークデータをプールするためのプールであって、前記プールは、ワークデータをプールするワークデータプールと結果データをプールする結果データプールとからなるプールを有していると解される。

そして、(ウ)における記載「システムはいわゆるMaster-Workerパターンに基づいており,中央のサーバプログラムがMasterとして,AppletがWorkerとして動作する.Workerには対応するGUIのフレームワークが用意されており,プログラマは,目的のアプリケーションの計算ルーチンと,その結果を表示するメソッドを実装する.」、(キ)における記載「真のボランティアネットワークと呼ぶことができる。…彼らは、彼らの意志で参加する(またはやめる)。」、及び(ケ)における記載「ワークエンジンは、ワークマネージャからワークデータを取得し、そのワークを処理し、そのワークの処理が終了したら、ワークマネージャに対してさらに別のワークの取得要求を行う仕事を引き受ける。 … サーバ側においては、一つの代理オブジェクトがエンジンの代理として動作し、エンジンからのCALLをマネージャに転送する。 … ボランティアが参加したい問題を選択するために、用いることができる。」からすると、Bayanihanにおいて、ボランティアの意志に基づいて、前記ボランティアの計算機は、Masterとしてのサーバにアクセスして問題に対応するWorkerとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行い、前記サーバ上で動作するワークマネージャは、該取得要求をした前記ボランティアの計算機に対してワークデータプールにプールされたワークデータを与えると解される。

したがって、引用文献1及び引用文献1が引用する参考文献1からすると、少なくとも以下のように構成された「Bayanihan」が、本願の特許出願前に日本国内又は外国において公然知られた発明(以下、「引用発明1」という。)であったものと解される。

Bayanihanは、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行するメタコンピューティングシステムであって、
前記メタコンピューティングシステムは、Master-Workerパターンに基づいて分散実行するシステムであって、Masterとしてのサーバ及びWorkerとして動作するアプレットを動作させる複数のボランティアの計算機とから構成されるシステムであって、
前記サーバ上で動作するワークマネージャは、
前記問題を形成する複数のワークデータをプールするためのプールであって、前記プールは、ワークデータをプールするワークデータプールと結果データをプールする結果データプールとからなるプールを有し、
前記ボランティアの計算機は、ボランティアの意志に基づいて、Masterとしてのサーバにアクセスして問題に対応するWorkerとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行い、
前記サーバ上で動作するワークマネージャは、該取得要求をした前記ボランティアの計算機に対してワークデータプールにプールされたワークデータを与えることを特徴とするメタコンピューティングシステム。

(3)対比
そこで、補正後の発明と引用発明1とを対比する。
引用発明1の「メタコンピューティングシステム」は、補正後の発明の「分散処理システム」に相当する。
引用発明1の「ボランティア」は、補正後の発明の「ユーザ」に相当する。
そして、引用発明1の「メタコンピューティングシステム」は、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して、問題を形成する複数のワークデータの各ワークデータを分散実行することから、引用発明1の「問題」及び「ワークデータ」は、それぞれ、補正後の発明の「ジョブ」及び「分割ジョブ」に相当する。
引用発明1の「ボランティアの意志に基づいて、Masterとしてのサーバにアクセスして問題に対応するWorkerとして動作するアプレットをダウンロードし、サーバ上で動作するワークマネージャにワークデータの取得要求を行う」ボランティアの計算機は、補正後の発明の「計算機のユーザの指示に基づくジョブ取得要求が行われた計算機」に相当する。
引用発明1のサーバ上で動作するワークマネージャは、複数のボランティアの計算機のうち、ボランティアの意志に基づくワークデータ取得要求が行われた計算機に対して、ワークデータプールにプールされたワークデータを与えると解されるから、引用発明1の「ワークマネージャ」は、補正後の発明の「ジョブ配信手段」に相当する。

そして、引用発明1の「ワークデータプールにプールされたワークデータ」と、補正後の発明の「ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブ」とは、ともに、ジョブから分割された複数の分割ジョブのうち所定の分割ジョブである点で一致する。

よって、補正後の発明と引用発明1とは、以下の点で一致し、また、相違している。

(一致点)
ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうち、計算機のユーザの指示に基づくジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち、所定の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。

(相違点)
「所定の分割ジョブ」について、補正後の発明は「未処理の分割ジョブ」であるのに対して、引用発明1は「ワークデータプールにプールされたワークデータ」が未処理であるかどうか明らかでない点。

(4)判断
相違点について検討する。
(ケ)及び(コ)における記載からすると、結果データプールにプールされた結果データは、処理済みデータであると解される。
そして、Bayanihanの目的が、ネットワーク上に分散して存在する多数のボランティアの計算機を利用して問題を形成する複数のワークデータの各ワークデータを処理することであることを勘案すれば、前記ボランティアの取得要求に対して、未処理のワークデータを与えることは、当然に想定し得たことである。
よって、上記相違点は格別のものではない。

そして、補正後の発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

したがって、補正後の発明は上記引用発明1に基づいて容易に発明できたものである。

3.むすび
以上のとおり、補正後の発明は、その出願前日本国内又は外国において公然知られた発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるので、特許法第29条第2項の規定に該当し、特許出願の際独立して特許を受けることができるものでなく、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項の規定により準用する特許法第126条第5項の規定に適合していない。
よって、前記補正前の請求項1についてする補正を含む本件補正は、特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

(備考)
なお、1998年9月3日に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/>)を参照すると、スライド9頁に、Master-Worker Modelによるクラス図が記載され、その中でクライアント側のワークエンジン(WorkEngine)が、サーバ側のワークマネージャ(WorkManager)に対してgetWork()メソッドCallをして、それに対して前記ワークマネージャがワークプール(WorkPool)からgetNextUndoneWork()メソッドを発行する様子が記載され、
スライド16頁に、
「 - uses circular work pool so undone work can be reassigned」
(和訳:- ワークプールをサイクリックに使うことで、未処理のワークを割り当て直す。)と記載されている。
してみると、前記「Bayanihan」が、前記引用発明1の構成に加えて、サーバ上で動作するワークマネージャが、ワークデータの取得要求をしたボランティアの計算機に対してワークデータプールにプールされたワークデータのうち未処理のワークデータを与える構成を有していたこと(当該発明を以下、「引用発明1′」という。)は、本願の特許出願前の1998年9月3日に日本国内又は外国において公然知られていたと推定される。
よって、その場合には、補正後の発明は、本願の特許出願前に日本国内又は外国において公然知られた発明である引用発明1′と実質的に同一の発明であるから、特許法第29条第1項第3号に該当し、補正後の発明は、特許出願の際独立して特許を受けることができるものではなく、記補正前の請求項1についてする補正を含む本件補正は、依然として特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである旨を指摘しておく。

第3.本願発明について
1.本願発明
平成19年10月29日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、同項記載の発明を「本願発明」という。)は、平成18年9月11日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。

「ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうちジョブ取得要求が行われた計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。」

2.引用文献
原査定の拒絶の理由に引用された、特開平11-15799号公報に(以下、「引用文献2」という。)には以下の事項が記載されている。(注意:下線は便宜上、当審にて付与したもの。)

(A)「【0010】
【課題を解決するための手段】本発明は、処理負荷に応じて外部装置の演算部を利用して並列処理を行う並列処理システムであって、複数の外部装置の演算部の余剰処理能力値に応じて処理を分割して複数の外部装置に分配し、並列処理を行うものである。」

(B)「【0016】前記の外部装置の演算部として、例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサを利用することにすれば、余剰処理能力を有する演算部が周囲に数多く存在することとなり、処理能力に応じて柔軟に並列処理システムを構築することが可能である。」

(C)「【0019】図1は、本実施形態の並列処理システムの概略構成を示す図である。図1に示す様に本実施形態の並列処理システムは、処理負荷に応じて外部装置101?103の演算部111?113を利用して並列処理を行うコンピュータ100と、演算部111?113を備える外部装置101?103とを通信ケーブル177を介して接続している。」

(D)「【0028】本実施形態の並列処理システムでは、演算部110?113を並列処理制御部140、処理能力通知部150?153または稼働状況通知部160?163として機能させる為のプログラムがメモリ120?123に記録されているものとする。」

(E)「【0037】次に、図1を用いて本実施形態の並列処理システムの動作を説明する。まず、演算部110?113は、電源が投入されると初期化処理を行う。
【0038】次に、コンピュータ100は、パラレル・インタフェース174を介して補助記憶装置175から基本プログラム、並列処理制御部140、処理能力通知部150、稼働状況通知部160及び必要に応じアプリケーション・プログラムをロードし、メモリ120に常駐させる。
【0039】次に、コンピュータ100は、ユーザの要求をシリアル・インタフェース172を介して入力装置173から読込み、必要な処理を順次実行する。
【0040】また、外部装置101?103は、メモリ121?123に格納されている処理能力通知部151?153及び稼働状況通知部161?163を起動すると共に、必要に応じて特定の処理プログラムを起動して当該装置独自の機能を実行する。
【0041】次に、処理能力通知部151?153は、演算部110?113の夫々で実行可能な単位時間当たりの命令数であるMIPS値等の処理能力値を、予め格納された特定のレジスタ等の記憶領域から読み出し、読み出した処理能力値を必要に応じてデータとして出力可能な状態を保持する。
【0042】また、稼働状況通知部160?163は、演算部110?113の夫々で実行中の単位時間当たりの命令数である処理負荷値を、特定時間中に実行した命令数を計測して算出し、算出した処理負荷値を必要に応じてデータとして出力可能な状態を保持する。
【0043】コンピュータ100の並列処理制御部140は、特定の処理を実行するタスクが発生すると、処理能力通知部150が読み出した処理能力値と稼働状況通知部160が算出した処理負荷値とから演算部110の余剰処理能力値を求め、前記特定の処理の実行に必要な必要処理能力値と比較する。
【0044】並列処理制御部140は、前記比較の結果、前記特定の処理の実行に必要な必要処理能力値が演算部110の余剰処理能力値を上回る場合や、前記特定の処理を演算部110で実行すると演算部110の処理負荷値が所定閾値を上回る場合に、前記特定の処理を分割し外部装置101?103に分配して実行させる処理を行う。
【0045】すなわち、並列処理制御部140は、通信アダプタ130?133及び通信ケーブル177を介し、外部装置101?103の演算部111?113の処理能力値及び処理負荷値を処理能力通知部151?153及び稼働状況通知部161?163から順次読み込んで、演算部110で不足している処理能力値を充足するまで、演算部111?113の余剰処理能力値を求める処理を行う。
【0046】並列処理制御部140は、演算部110の不足処理能力値が演算部111?113の余剰処理能力値の和で充足されたなら、演算部110に割り当てられていた前記特定の処理を、演算部111?113の個々の余剰処理能力値の割合に合わせて分割し、分割した処理を通信アダプタ130?133及び通信ケーブル177を介して、外部装置101?103の演算部111?113に分配する。」

上記(A)の段落【0010】における記載「本発明は、処理負荷に応じて外部装置の演算部を利用して並列処理を行う並列処理システムであって、…」、(B)の段落【0016】における記載「前記の外部装置の演算部として、例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサを利用する…」、及び(C)の段落【0019】における記載「本実施形態の並列処理システムは、処理負荷に応じて外部装置101?103の演算部111?113を利用して並列処理を行うコンピュータ100と、演算部111?113を備える外部装置101?103とを通信ケーブル177を介して接続している。」からすると、引用文献2には、ネットワークに接続されたコンピュータと外部装置(例えば家庭用電化製品や事務機器)とからなる分散並列システムであって、前記コンピュータは、前記ネットワーク上に分散して存在する複数の外部装置の演算部(例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ)を利用して並列処理を行う並列処理システムに関する発明が記載されていると解される。

(E)の段落【0043】における記載「コンピュータ100の並列処理制御部140は、特定の処理を実行するタスクが発生すると、…演算部110の余剰処理能力値を求め、…」、(E)の段落【0044】における記載「並列処理制御部140は、…前記特定の処理の実行に必要な必要処理能力値が演算部110の余剰処理能力値…や、前記特定の処理を演算部110で実行すると演算部110の処理負荷値が所定閾値を上回る場合に、前記特定の処理を分割し外部装置101?103に分配して実行させる処理を行う。」、(E)の段落【0045】における記載「並列処理制御部140は、…外部装置101?103の演算部111?113の処理能力値及び処理負荷値を…順次読み込んで、演算部110で不足している処理能力値を充足するまで、演算部111?113の余剰処理能力値を求める処理を行う。」、及び(E)の段落【0046】における記載「並列処理制御部140は、演算部110の不足処理能力値が演算部111?113の余剰処理能力値の和で充足されたなら、演算部110に割り当てられていた前記特定の処理を、演算部111?113の個々の余剰処理能力値の割合に合わせて分割し、分割した処理を通信アダプタ130?133及び通信ケーブル177を介して、外部装置101?103の演算部111?113に分配する。」からすると、前記並列処理システムにおけるコンピュータの並列処理制御部は、上記複数の外部装置の演算部に対して、前記処理から分割された複数の分割した処理のうち、前記コンピュータの演算部で処理できない、すなわち未処理の分割した処理を分配すると解される。

(D)の段落【0028】における記載「本実施形態の並列処理システムでは、演算部110?113を並列処理制御部140、処理能力通知部150?153または稼働状況通知部160?163として機能させる為のプログラムがメモリ120?123に記録されているものとする。」、(E)の段落【0040】における記載「外部装置101?103は、メモリ121?123に格納されている処理能力通知部151?153及び稼働状況通知部161?163を起動すると共に、必要に応じて特定の処理プログラムを起動して当該装置独自の機能を実行する。」、(E)の段落【0041】における記載「処理能力通知部151?153は、演算部110?113の夫々で実行可能な単位時間当たりの命令数であるMIPS値等の処理能力値を、…必要に応じてデータとして出力可能な状態を保持する。」、及び(E)の段落【0042】における記載「稼働状況通知部160?163は、演算部110?113の夫々で実行中の単位時間当たりの命令数である処理負荷値を、…必要に応じてデータとして出力可能な状態を保持する。」からすると、複数の外部装置(例えば家庭用電化製品や事務機器)のうち、前記コンピュータの並列処理制御部から分配される外部装置は、当該装置独自の機能を実行する特定の処理プログラムの外に、処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムを起動しておくことが必要であると解される。
すなわち、前記コンピュータの並列処理制御部は、複数の外部装置のうち、前記処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している外部装置に対して、未処理の分割した処理を分配すると解される。

よって、(A)?(E)における記載及び関連する図面からすると、引用文献2には、次の発明(以下、「引用発明2」という。)が記載されているものと認められる。

ネットワーク上に分散して存在する複数の外部装置の演算部(例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ)を利用して並列処理を行う並列処理システムであって、
上記複数の外部装置の演算部のうち、処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部に対して、上記処理から分割された複数の分割した処理のうち未処理の分割した処理を分配する並列処理制御部を備えることを特徴とする並列処理システム。

3.対比
そこで、本願発明と引用発明2とを対比する。
引用発明2の「外部装置の演算部(例えば家庭用電化製品や事務機器に用いられているマイクロプロセッサ)」は、本願発明の「計算機」に相当する。
引用発明2の「処理」は、本願発明の「ジョブ」に相当する。
引用発明2の「並列処理を行う並列処理システム」は、本願発明の「ジョブを分散実行する分散処理システム」に相当する。
引用発明2の「分割した処理を分配する」は、本願発明の「分割ジョブを与える」に相当する。
そして、引用発明2の「並列処理制御部」は、本願発明の「ジョブ配信手段」に相当する。
引用発明2の「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部」と、本願発明の「ジョブ取得要求が行われた計算機」とは、ともに、分散処理可能に設定された計算機である点で一致する。
よって、本願発明と引用発明2とは、以下の点で一致し、また、相違している。

(一致点)
ネットワーク上に分散して存在する複数の計算機を利用してジョブを分散実行する分散処理システムであって、
上記複数の計算機のうち分散処理可能に設定された計算機に対して、上記ジョブから分割された複数の分割ジョブのうち未処理の分割ジョブを与えるジョブ配信手段を備えることを特徴とする分散処理システム。

(相違点)
「分散処理可能に設定された計算機」について、本願発明は「ジョブ取得要求が行われた計算機」であるのに対して、引用発明2は「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している演算部」である点。

4.判断
相違点について検討する。
原査定の拒絶の理由に引用された、特開平9-34733号公報(以下、「引用文献3」という。)における記載(注意:下線は便宜上、当審にて付与したもの。)、
「【要約】…
【課題】…
【解決手段】 伝送路上に複数の計算機が接続され、1つの計算機のプロセス送信部から他の計算機のプロセス受信部にプロセスを移動させることにより、各計算機の負荷を分散させる分散スケジューリングシステムにおいて…」、
「【0005】本発明は、…システムの負荷状況に応じて、再分散のための条件値を変更することにより、システム全体の負荷の分散を最適に行なうことのできる分散スケジューリングシステムを提供することを目的とする。」、
「【0015】…LAN1上には複数の計算機2?4が接続されている。計算機2は、折衝プロセス11を備えており、この折衝プロセス11はプロセス送信部、プロセス受信部、条件変更部から構成される。また、計算機3,4も計算機2と同様の構成の折衝プロセスを備えている。」、
「【0024】プロセス受信可能放送部32は、…計算機2の負荷状況がプロセス受信可能条件設定部31にて設定されたプロセス受信可能条件を満たすか否かを判定し、プロセス受信可能条件を満たすと判定された場合に、他の計算機3,4に自計算機の負荷情報を含んだ受信可能メッセージを送信する。…」、
「【0026】…プロセス受信要求放送部35は、他の計算機から送信された送信要求メッセージを受信した場合に、…プロセス受信可能条件を満たすと判定された場合に、他の全計算機に自計算機の負荷情報を含んだ受信可能メッセージを送信する。」、
「【0032】…他の計算機から送信された…受信可能メッセージが受信されると、この受信された受信可能メッセージに含まれる他の計算機の負荷状況に基づいて、移動プロセス決定部24により他の計算機に移動するプロセスが決定されるとともに、プロセス移動先決定部25により、移動する先の計算機が決定される。…
【0033】…プロセス移動部26により、移動プロセス決定部24にて決定された自己の負荷状況を含むプロセスが、プロセス移動先決定部25により決定された計算機に送信される…」を参照すると、引用文献3には、次の発明(以下、「引用発明3」という。)が記載されているものと認められる。

ネットワーク上に分散して存在する複数の計算機を利用してプロセスを分散実行する分散スケジューリングシステムであって、
上記複数の計算機のうち、受信可能メッセージを送信した計算機に対して、処理プロセスのうち他の計算機に移動するプロセスを送信する手段を備えることを特徴とする分散スケジューリングシステム。

そして、引用発明2と引用発明3とは、ともに、ネットワーク上に分散して存在する複数の計算機を利用して処理を分散実行する分散処理システムである点で共通の分野に属するものといえる。
してみると、分散処理可能に設定された演算部として、引用発明2記載の「処理能力通知部として機能させる為のプログラム及び稼働状況通知部として機能させる為のプログラムが起動している」演算部に代えて引用発明3記載の「受信可能メッセージを送信した」計算機(「演算部」に相当)を採用することは、当業者であれば、容易に想到し得たことである。
そして、「受信可能メッセージ」は、プロセスの受信要求を意味することから、「受信可能メッセージを送信した」計算機は、本願発明の「ジョブ取得要求が行われた計算機」に相当する。
よって、上記相違点は格別のものではない。

そして、本願発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。

したがって、本願発明は上記引用発明2及び引用発明3に基づいて容易に発明できたものである

5.むすび
以上のとおり、本願の請求項1に係る発明は、その出願前日本国内又は外国において頒布された刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2010-05-12 
結審通知日 2010-05-18 
審決日 2010-06-03 
出願番号 特願平11-43713
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 殿川 雅也  
特許庁審判長 赤川 誠一
特許庁審判官 冨吉 伸弥
鈴木 匡明
発明の名称 分散処理システムおよびその方法、分散処理を行うための端末装置および記録媒体  
代理人 國分 孝悦  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ