【事件の表示】
　特願２００９−２９４７１８「クラスタリングシステム」拒絶査定不服審判事件〔平成２３年　７月　７日出願公開，特開２０１１−１３４２１５〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，
平成２１年１２月２５日を出願日とする出願であって，
平成２４年１１月１日に審査請求がなされ，
平成２５年１０月１８日付けで拒絶理由通知（同年１０月２２日発送）がなされ，
これに対して同年１２月２０日付けで意見書が提出されたが，
平成２６年１月１０日付けで拒絶査定（同年１月２１日謄本送達）がなされたものである。　
　これに対して，「原査定を取り消す，本願は特許をすべきものであるとの審決を求める」との請求の趣旨で，平成２６年４月２１日付けで審判請求がなされた。
　
　
２　本願発明
　
　本願の請求項１に係る発明（以下「本願発明」という。）は，特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
　「クラスタリングによってタスクを処理するクラスタリングシステムであって、
　アミューズメント施設内に複数設置されたゲーム機と、
　前記各ゲーム機にそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、
　前記アミューズメント施設内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバと、
を有し、
　前記管理サーバは、
　前記各演算処理ユニットの可動状態をリアルタイムで示す処理状態テーブルと、
　前記管理サーバに所定のタスクが新たに発生した場合に、前記処理状態テーブルに基づいて前記各演算処理ユニットのうち前記タスクを処理可能な演算処理ユニットを選択し前記タスクを処理するように指示するタスク管理手段と
　を有し、
　前記演算処理ユニットは、
　プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段と、
　前記タスク管理手段によって処理を指示された前記タスクを処理し、前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断するタスク処理手段と、
　前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と
　を有し、
　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する
　ことを特徴とするクラスタリングシステム。」
　
　
３　拒絶理由・請求人の主張等
（１）
原審拒絶理由通知書（平成２５年１０月１８日起案）の内容
　
『この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　　　　　　　　　　　　　記
　
≪引用文献等一覧≫
１．特開平１０−１４３３８１号公報
２．特開２００２−２６９３９４号公報
３．特開２００６−２２３４１９号公報
４．特開２００４−２４０６６９号公報
５．特開２００７−３３４７８２号公報
６．特開２００２−２５９３５３号公報
　
［請 求 項］１
［引用文献］１−３
　引用文献１（【請求項３１】，【請求項３２】，【００１０】−【００１６】，【００２５】−【００５３】，図１等参照）には、
　多数のホストがＬＡＮやＷＡＮで接続されたシステムにおけるジョブ実行の制御方法であって、
　スケジューリングコンピュータ（管理サーバに対応）は、
　収集された各ホストに関する一定の現在情報（ホストの主利用者による最終アクティビティからの経過時間を含む）を状態ファイル（処理状態テーブルに対応）に転記する手段と、
　当該状態ファイルを使用して、利用者によって実行依頼されたジョブを実行するための適切なホストを選択する手段（タスク管理手段に対応）と、
　を有し、
　主利用者によるアクティビティが検出されると、前記ジョブの実行を中断する手段と、
　前記中断されたジョブを再度実行依頼する手段と、
　を備えるジョブ実行の制御方法、の発明が記載されている。
　
　請求項１に係る発明と引用文献１に記載の発明を対比すると、以下の点で相違する。
　
（１）請求項１に係る発明は、アミューズメント施設内のゲーム機によるクラスタリングシステムにおけるタスクの制御方法であるのに対し、引用文献１に記載の発明は、そのようなものではない点。
　
　次に、上記相違点について検討する。
　
（１）アミューズメント施設内のゲーム機によるクラスタリングシステムにおいてジョブ実行を制御することは、例えば、引用文献２（【００２１】−【００２４】，【００２９】−【００３２】，図１−４等参照）や引用文献３（【０００２】−【０００４】，【００１６】−【００３０】，【００８９】，【００９７】，図１−３等参照）に記載されているように周知技術であるから、引用文献１に記載の発明のジョブ実行の制御方法を、引用文献２−３に記載されている周知のアミューズメント施設内のゲーム機によるクラスタリングシステムに適用して、アミューズメント施設内のゲーム機によるクラスタリングシステムにおけるジョブ実行の制御方法を創作することは、当業者が容易になし得たことである。
　
　よって、請求項１に係る発明は、引用文献１に記載の発明および引用文献２−３に記載の周知技術に基づいて、当業者が容易に想到し得たものである。
（以下，省略）』
（２）
意見書（平成２５年１２月２０日提出）の内容
　
『本願発明は、請求項１〜４に記載されたように、
「【請求項１】
Ａ　クラスタリングによってタスクを処理するクラスタリングシステムであって、
Ｂ　アミューズメント施設内に複数設置されたゲーム機と、
Ｃ　前記各ゲーム機にそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、
Ｄ　前記アミューズメント施設内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバと、
を有し、
Ｅ　前記管理サーバは、
　Ｅ−１　前記各演算処理ユニットの可動状態をリアルタイムで示す処理状態テーブルと、
　Ｅ−２　前記管理サーバに所定のタスクが新たに発生した場合に、前記処理状態テーブルに基づいて前記各演算処理ユニットのうち前記タスクを処理可能な演算処理ユニットを選択し前記タスクを処理するように指示するタスク管理手段と
　を有し、
Ｆ　前記演算処理ユニットは、
　Ｆ−１　プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段と、
　Ｆ−２　前記タスク管理手段によって処理を指示された前記タスクを処理し、前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断するタスク処理手段と、
　Ｆ−３　前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と
　を有し、
Ｇ　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する
　ことを特徴とするクラスタリングシステム。
・・・（中略）・・・
　
３．本願発明と引用文献との差異について
（１）請求項１について
　（ア）審査官殿の見解
　審査官殿は、引用文献１の発明と本願の発明とでは計算機資源を共有するためのシステムにおけるジョブ実行の制御方法である点で一致し、引用文献１と本願の相違点は、本願請求項１の発明がアミューズメント施設内のゲーム機によるクラスタリングシステムにおけるタスクの制御方法である点であると認定されています。
　そして、上記の相違点は引用文献２（分散処理仲介システム）および３（ゲームシステム）に記載されているように「周知技術であるから、引用文献１に記載の発明のジョブ実行の制御方法を、引用文献２−３に記載されている周知のアミューズメント施設内のゲーム機によるクラスタリングシステムに適用して、アミューズメント施設内のゲーム機によるクラスタリングシステムにおけるジョブ実行の制御方法を創作することは、当業者が容易になし得たことである。よって、請求項１に係る発明は、引用文献１に記載の発明および引用文献２−３に記載の周知技術に基づいて、当業者が容易に想到し得たものである。」として本願請求項１を拒絶されています。
　
　（イ）引用文献１との比較
　引用文献１には「ネットワークによって互いに接続される複数のコンピュータ間において計算機資源を共有するためのシステム（請求項１前提部引用）」が開示されています。
　しかしながら、審査官殿も拒絶理由通知において示されている通り、引用文献１には、本願請求項１に記載の発明に係るアミューズメント施設内のゲーム機によるクラスタリングシステムにおけるタスクの制御方法に関する記載は全くありません。
　
　（ウ）引用文献２との比較
　引用文献２には、明細書および請求項の全体にわたって「分散処理仲介システム」が開示されています。そして、段落番号００２９には「本発明をゲームセンターに設置されるアミューズメントマシンに応用する例について説明する。」との記載があります。
　しかしながら、段落番号００２９およびその前後を検討しても、その具体的な例は示されていません。
　
　（エ）引用文献３との比較
　上述したように引用文献１及び引用文献２には本願発明の構成要件のすべてが開示されているとは言えないため、審査官殿は、アミューズメントーパーク内での具体的な分散処理のシステム及び方法が示されている先行技術として引用文献３を引用されたものであると思量いたします。
　すなわち、上記引用文献１および２を組み合わせることにより、本願の構成要件Ａ〜Ｇのうち、構成要件Ａ〜Ｅは導きだせる可能性がありますが、本願の要点である以下の構成要件Ｆ、Ｇについては全く開示されていません。
　
「Ｆ　前記演算処理ユニットは、
　Ｆ−１　プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段と、
　Ｆ−２　前記タスク管理手段によって処理を指示された前記タスクを処理し、前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断するタスク処理手段と、
　Ｆ−３　前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と
　を有し、
Ｇ　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する
　ことを特徴とするクラスタリングシステム。」
　
　そこで、引用文献３が上記構成要件Ｆ、Ｇを開示しているかについて検討すると、引用文献３には、上記構成要件Ｆ、Ｇに対応する技術的事項として、サッカーゲーム等の団体対戦ゲーム装置において、対戦に参加していないゲーム機を余剰リソースとして、それらの余剰リソースに上記対戦ゲームの演算処理を分散処理させるシステムが開示されています。
　このシステムにおいては、ネットワークでつながれた複数のゲーム機が設置され、所定の受付時間内に前記複数のゲーム機のいずれから「対戦要求信号」を受け付けると、対戦要求を受け付けたゲーム機同士の対戦を一斉に開始するように構成されたゲームであります。このことは、引用文献３の請求項１中断部の「受付期間を定期的に設定し、前記受付期間内に前記遊戯者が前記入力部を介して入力する対戦要求信号を受け付けるエントリ受付部と、」の記載や段落番号００２３の「このサッカーゲームは、１ つの対戦を含む１ゲームが約８分で運営され、ゲーム装置は、１ゲームが終了すると、次のゲームの参加者を受付期間を区切って募る。受付期間に入出力セットに着いたユーザは、他のユーザとの対戦（２人で遊ぶ）かコンピュータとの対戦（１人で遊ぶ）かを選択し、ゲーム装置はその集計を待って対戦処理を一斉に行う。」の記載から読み取ることができます。
　そして、引用文献３では、ネットワークでつながれた複数のゲーム機のうち、「対戦要求」がされていないゲーム機が１つ以上ある場合には、そのゲーム装置が余剰に処理可能な対戦数（余剰の処理能力）をサーバに通知し、サーバからタスクを受け取るようになっています。このことは、引用文献３の段落番号００２５「本実施形態におけるゲームシステムの特徴は、各ゲーム装置において対戦処理を行うにあたり、その１ゲームで行われる対戦数に基づき、ゲーム装置が更に処理可能な対戦数（余剰の処理能力）をサーバ１に通知し、サーバ１に未処理の対戦に関する情報があれば、サーバ１はそれをゲーム装置に送信し、ゲーム装置が、そのゲーム装置で遊ぶユーザに係る対戦と共にサーバ１から割当てられる対戦を処理することで、ゲーム装置における余剰の処理能力を効率的に活用するものである。本実施形態のサッカーゲームにおける対戦は、少なくとも出場選手を特定するデータを与えれば処理することができるとする。」との記載から読み取れます。
　すなわち、引用文献３の構成であると、ゲームの途中参加が許されないものでありますから、ゲームの途中でそのゲームで対戦要求されていないゲーム機でゲーム処理が始まることがありません。従って、対戦要求されていないゲーム機におけるタスク処理も中断されることはありません。
　本願発明の構成要件Ｆ-２「前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断する」を満たさないものであります。
　また、引用文献３では、タスクが途中で中断しないものでありますから、当然に、他のゲーム機でタスクを引き継ぐ必要がないので、本願発明の構成要件Ｆ-３「前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段」を満たしません。また、これにともない構成要件Ｇ「前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する」ということもあり得ないものであります。
　引用文献３には、上記のように割り当てられたタスクを途中で中断したり他のゲーム機に引き継ぐという技術思想が一切ありませんので、当業者であっても、引用文献３を見て、本願発明の構成要件Ｆ、Ｇに到達することの動機付けを得ることはないものと思料します。
（以下，省略）』
　
（３）
原審拒絶査定（平成２６年１月１０日起案）の内容
　
『この出願については、平成２５年１０月１８日付け拒絶理由通知書に記載した理由によって、拒絶をすべきものです。
　なお、意見書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
備考
Ａ．請求項１について
　出願人は、意見書で、以下のように主張している。
　
（イ）引用文献１との比較
　引用文献１には「ネットワークによって互いに接続される複数のコンピュータ間において計算機資源を共有するためのシステム（請求項１前提部引用）」が開示されています。
　しかしながら、審査官殿も拒絶理由通知において示されている通り、引用文献１には、本願請求項１に記載の発明に係るアミューズメント施設内のゲーム機によるクラスタリングシステムにおけるタスクの制御方法に関する記載は全くありません。
（ウ）引用文献２との比較
　引用文献２には、明細書および請求項の全体にわたって「分散処理仲介システム」が開示されています。そして、段落番号００２９には「本発明をゲームセンターに設置されるアミューズメントマシンに応用する例について説明する。」との記載があります。
　しかしながら、段落番号００２９およびその前後を検討しても、その具体的な例は示されていません。
（エ）引用文献３との比較
　上述したように引用文献１及び引用文献２には本願発明の構成要件のすべてが開示されているとは言えないため、審査官殿は、アミューズメントーパーク内での具体的な分散処理のシステム及び方法が示されている先行技術として引用文献３を引用されたものであると思量いたします。
　すなわち、上記引用文献１および２を組み合わせることにより、本願の構成要件Ａ〜Ｇのうち、構成要件Ａ〜Ｅは導きだせる可能性がありますが、本願の要点である以下の構成要件Ｆ、Ｇについては全く開示されていません。
・・・
　引用文献３には、上記のように割り当てられたタスクを途中で中断したり他のゲーム機に引き継ぐという技術思想が一切ありませんので、当業者であっても、引用文献３を見て、本願発明の構成要件Ｆ、Ｇに到達することの動機付けを得ることはないものと思料します。
　
　上記主張について検討する。
　
　（エ）において「引用文献１及び引用文献２には本願発明の構成要件のすべてが開示されているとは言えないため、審査官殿は、アミューズメントーパーク内での具体的な分散処理のシステム及び方法が示されている先行技術として引用文献３を引用されたものであると思量いたします」との見解を示しているが、そのような意図でではなく、拒絶理由通知書の文言通りの意味、つまり、「アミューズメント施設内のゲーム機によるクラスタリングシステムにおいてジョブ実行を制御すること」が周知であることを示す例として、引用文献２および引用文献３を挙げたものである。拒絶理由通知書に記載したように、本願請求項１に係る発明と引用文献１に記載の発明とを対比すると、ゲーム機によるクラスタリングシステムではない点で相違するのみであって、具体的なジョブ実行の制御方法は差異がないといえる。したがって、引用文献１に記載の発明のジョブ実行の制御方法を、引用文献２−３に記載されている周知のアミューズメント施設内のゲーム機によるクラスタリングシステムに適用して、本願請求項１に係る発明に相当する「アミューズメント施設内のゲーム機によるクラスタリングシステムにおけるジョブ実行の制御方法」を創作することは、当業者が容易になし得たことである。（なお、当該創作された「アミューズメント施設内のゲーム機によるクラスタリングシステムにおけるジョブ実行の制御方法」における「主利用者によるアクティビティ」が、「プレイヤによるゲームプレイ」に対応することを付言しておく。）
　したがって、出願人の主張は拒絶の理由を覆すのに十分であるとはいえない。
　よって、請求項１に係る発明は、引用文献１に記載の発明および引用文献２−３に記載の周知技術に基づいて、依然として当業者が容易に想到し得たものである。
（以下，省略）』
　
（４）
本件審判請求（平成２６年４月２１日提出）の理由に記載された審判請求人の主張
　
『３．　本願に係る発明（本願発明）が特許されるべき理由 
（Ａ）本願発明の説明 
　本願発明は、出願時の請求項１〜４に記載されたように、 
「 
【請求項１】 
Ａ　クラスタリングによってタスクを処理するクラスタリングシステムであって、 
Ｂ　アミューズメント施設内に複数設置されたゲーム機と、 
Ｃ　前記各ゲーム機にそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、 
Ｄ　前記アミューズメント施設内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバと、 
を有し、 
Ｅ　前記管理サーバは、 
　Ｅ−１　前記各演算処理ユニットの可動状態をリアルタイムで示す処理状態テーブルと、 
　Ｅ−２　前記管理サーバに所定のタスクが新たに発生した場合に、前記処理状態テーブルに基づいて前記各演算処理ユニットのうち前記タスクを処理可能な演算処理ユニットを選択し前記タスクを処理するように指示するタスク管理手段と、 
　を有し、 
Ｆ　前記演算処理ユニットは、 
　Ｆ−１　プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段と、 
　Ｆ−２　前記タスク管理手段によって処理を指示された前記タスクを処理し、前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断するタスク処理手段と、 
　Ｆ−３　前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と、 
　を有し、 
Ｇ　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始することを特徴とするクラスタリングシステム。 
・・・（中略）・・・」 
　であります。尚、以下の説明の便宜のため、上記において、請求項１には構成要件毎に符号Ａ〜Ｄを付しました。 
　
（Ｂ）拒絶査定について 
　本願出願人は、平成２５年１０月２２日（発送日）付拒絶理由通知書に対する応答（平成２５年１２月２０日付け意見書）にて、本願発明と引用文献１〜６とを詳細に比較検討し、相違点に基づく本願発明の顕著な効果を詳細に主張して本願の進歩性を主張しました。 
　しかしながら、原査定では、上記出願人の主張を検討した形跡が全くなく、出願人としては、拒絶査定に至った理由が全く理解できなかったため、今回の審判を提起したものであります。 
　以下、再度本願発明と引用文献との差異の説明をすると共に、本願発明が特許されるべき理由を詳細に説明するものであります。 
　
（Ｃ）引用発明の説明
（１）引用文献１について 
　引用文献１には「ネットワークによって互いに接続される複数のコンピュータ間において計算機資源を共有するためのシステム（請求項１前提部引用）」が開示されています。 
　しかしながら、審査官殿も拒絶理由通知において示されている通り、引用文献１には、本願請求項１に記載の発明に係るアミューズメント施設内のゲーム機によるクラスタリングシステムにおけるタスクの制御方法に関する記載は全くありません。 
　
（２）引用文献２について 
　引用文献２には、明細書および請求項の全体にわたって「分散処理仲介システム」が開示されています。そして、段落番号００２９には「本発明をゲームセンターに設置されるアミューズメントマシンに応用する例について説明する。」との記載があります。 
　しかしながら、段落番号００２９およびその前後を検討しても、その具体的な例は示されていません。 
　
（３）引用文献３との比較 
　上述したように引用文献１及び引用文献２には本願発明の構成要件のすべてが開示されているとは言えないため、審査官殿は、アミューズメントーパーク内での具体的な分散処理のシステム及び方法が示されている先行技術として引用文献３を引用されたものであると思量いたします。 
　
（Ｄ）本願発明と引用発明との対比 
　上記引用文献１および２を組み合わせることにより、本願の構成要件Ａ〜Ｇのうち、構成要件Ａ〜Ｅは導きだせる可能性がありますが、本願の要点である以下の構成要件Ｆ、Ｇについては全く開示されていません。 
「Ｆ　前記演算処理ユニットは、 
　Ｆ−１　プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段と、 
　Ｆ−２　前記タスク管理手段によって処理を指示された前記タスクを処理し、前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断するタスク処理手段と、 
　Ｆ−３　前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と、 
　を有し、 
Ｇ　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始することを特徴とするクラスタリングシステム。」 
　そこで、引用文献３が上記構成要件Ｆ、Ｇを開示しているかについて検討すると、引用文献３には、上記構成要件Ｆ、Ｇに対応する技術的事項として、サッカーゲーム等の団体対戦ゲーム装置において、対戦に参加していないゲーム機を余剰リソースとして、それらの余剰リソースに上記対戦ゲームの演算処理を分散処理させるシステムが開示されています。 
　このシステムにおいては、ネットワークでつながれた複数のゲーム機が設置され、所定の受付時間内に前記複数のゲーム機のいずれから「対戦要求信号」を受け付けると、対戦要求を受け付けたゲーム機同士の対戦を一斉に開始するように構成されたゲームであります。このことは、引用文献３の請求項１中断部の「受付期間を定期的に設定し、前記受付期間内に前記遊戯者が前記入力部を介して入力する対戦要求信号を受け付けるエントリ受付部と、」の記載や段落番号００２３の「このサッカーゲームは、１ つの対戦を含む１ゲームが約８分で運営され、ゲーム装置は、１ゲームが終了すると、次のゲームの参加者を受付期間を区切って募る。受付期間に入出力セットに着いたユーザは、他のユーザとの対戦（２人で遊ぶ）かコンピュータとの対戦（１人で遊ぶ）かを選択し、ゲーム装置はその集計を待って対戦処理を一斉に行う。」の記載から読み取ることができます。 
　そして、引用文献３では、ネットワークでつながれた複数のゲーム機のうち、「対戦要求」がされていないゲーム機が１つ以上ある場合には、そのゲーム装置が余剰に処理可能な対戦数（余剰の処理能力）をサーバに通知し、サーバからタスクを受け取るようになっています。このことは、引用文献３の段落番号００２５「本実施形態におけるゲームシステムの特徴は、各ゲーム装置において対戦処理を行うにあたり、その１ゲームで行われる対戦数に基づき、ゲーム装置が更に処理可能な対戦数（余剰の処理能力）をサーバ１に通知し、サーバ１に未処理の対戦に関する情報があれば、サーバ１はそれをゲーム装置に送信し、ゲーム装置が、そのゲーム装置で遊ぶユーザに係る対戦と共にサーバ１から割当てられる対戦を処理することで、ゲーム装置における余剰の処理能力を効率的に活用するものである。本実施形態のサッカーゲームにおける対戦は、少なくとも出場選手を特定するデータを与えれば処理することができるとする。」との記載から読み取れます。 
　すなわち、引用文献３の構成であると、ゲームの途中参加が許されないものでありますから、ゲームの途中でそのゲームで対戦要求されていないゲーム機でゲーム処理が始まることがありません。従って、対戦要求されていないゲーム機におけるタスク処理も中断されることはありません。 
　本願発明の構成要件Ｆ−２「前記ゲーム処理手段が前記ゲーム処理を開始するときには処理中の前記タスクを中断する」を満たさないものであります。 
　また、引用文献３では、タスクが途中で中断しないものでありますから、当然に、他のゲーム機でタスクを引き継ぐ必要がないので、本願発明の構成要件Ｆ−３「前記タスク処理手段によって前記タスクが中断された場合に、前記ローカルネットワークを介して前記処理状態テーブルを参照し、この処理状態テーブルに基づいて前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段」を満たしません。また、これにともない構成要件Ｇ「前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する」ということもあり得ないものであります。 
　引用文献３には、上記のように割り当てられたタスクを途中で中断したり他のゲーム機に引き継ぐという技術思想が一切ありませんので、当業者であっても、引用文献３を見て、本願発明の構成要件Ｆ、Ｇに到達することの動機付けを得ることはないものと思料します。 
　
４．むすび 
　以上のように、上記の引用文献１−３と本願の発明とでは、クラスタリングシステムであるという点は同じであるものの、その構成要件はまったく違うものであり、引用刊行物に記載された発明から当業者が容易に発明をすることができたものではないと確信いたします。従って、原査定を取消し、本願の発明を特許すべき旨の審決を頂きたくお願い申し上げる次第でございます。 』
　
　
４　引用文献
　
（１）　引用文献１
　
　本願の出願前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２５年１０月１８日付けの拒絶理由通知において引用された文献である特開平１０−１４３３８１号公報（平成１０年５月２９日出願公開。以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ．「【要約】
【課題】  遊休ワークステーションを共用するための装置および方法を提供する。
【解決手段】  
ローカルホストワークステーション１００の利用者が、遠隔ワークステーション１０１上において実行するためにジョブを実行依頼することができる。
遊休である遠隔ホストが選択され、次に、ジョブ１０９が実行されている遠隔ホストのアクティビティが連続的にモニタリングされる。システムが遠隔ホスト上に遠隔ホストの主利用者のひとつによる幾らかのアクティビティを検出するときは、ジョブの実行は直ちに中断され主利用者に対する不都合が防止される。
中断されたジョブは、別の遊休ワークステーションを選択して移送され、中断されたジョブの実行が再開される
　
Ｂ．「【請求項１】　
ネットワークによって互いに接続される複数のコンピュータ間において計算機資源を共有するためのシステムであって
前記複数のコンピュータのひとつがホストコンピュータであり、遠隔実行のためのジョブを受け取るローカルコンピュータと、
遠隔実行のためのジョブを受け取る機能を有する遠隔コンピュータ
現在状態プロセスを実行し前記遠隔コンピュータの主利用者に関するアクティビティ情報を含む現在情報を収集し
該システムは、さらに、
少なくとも前記遠隔コンピュータに関する前記主利用者の現在情報に基づいて、受け取ったジョブを遠隔実行するための位置を選択するスケジューリングコンピュータを備え、前記スケジューリングコンピュータは前記複数のコンピュータのひとつである
【請求項２】　請求項１に記載のシステムであって、前記スケジューリングコンピュータと前記ローカルコンピュータとは同一のコンピュータであることを特徴とするシステム。
【請求項３】　請求項１に記載のシステムであって、前記スケジューリングコンピュータと前記遠隔コンピュータとは同一のコンピュータであることを特徴とするシステム。
【請求項４】　請求項１に記載のシステムであって、
前記ローカルコンピュータ、前記遠隔コンピュータおよび前記スケジューリングコンピュータは、前記複数のコンピュータの内の三つの異なるコンピュータである
　
Ｃ．「【００１２】利用者Ｘのような利用者が、遠隔ホスト上において実行するためにジョブを実行依頼するプロセスを、以下に、図１を参照しながら説明する。以下の実施形態においては、図１に示すプロセスがひとつも開始されていない時間上の一点を仮定する。この説明例においては、本発明の原理は前述し本明細書に取り込まれるコシェルシステムに適用される。
【００１３】最初に、利用者は、利用者のローカルホスト上において、デーモンプロセス（ワークステーション上において利用者によって開始されるとその利用者がプロセスを終了しない限り終了しないプロセス）として、コシェルプロセスを開始する（コシェルプロセスは、ローカルネットワークにおいて軽ロード状態のホスト上においてシェル動作を自動的に実行するプロセスである）。したがって、図１において、利用者Ｘは、ローカルホスト１００上において、コシェルプロセス１０４をデーモンプロセスとして開始する。あらゆるコシェルデーモンプロセスは、それを開始した利用者の要求のみを満たす。たとえば、他の利用者Ｙはホスト１００上にログすることはできるが、利用者Ｘだけがコシェルプロセス１０４と通信することができる。
【００１４】起動されると、
コシェルデーモンプロセスは、それ自体のローカルホスト上、およびネットワークによってコシェルがジョブを実行依頼することができるあらゆる他の遠隔ホスト上において、状態デーモンを開始する（状態デーモンが既に実行中である場合以外は）。
【００１５】
各状態デーモンは、それが実行されているホストに関する一定の現在情報を収集し（すなわち、状態デーモン１０５はホスト１００に関する情報を収集し、一方、状態デーモン１１０はホスト１０１に関する情報を収集する）、この情報をすべての他のネットワークホストにとって可視である固有の状態ファイルに転記する。
すべての状態デーモンに関するすべての状態ファイルは、セントラルディレクトリに保持される。
コシェルは、これらの状態ファイルを使用し、コシェルの利用者によって実行依頼されたジョブを実行するための適切な遠隔ホストを選択する。
【００１６】各コシェルは、他のすべてのコシェルとは独立に遠隔ホストを選択し、遠隔ホストは稼働中である場合もあるので、分散化スケジューリングの形式で実行するとこととなる。コシェルは、利用者の遠隔ホスト選択アルゴリズムに無作為平滑化構成要素を有することによって、すべての利用者がそのジョブを同じ遠隔ホストに実行依頼する可能性を回避する。各コシェルは、単独の最良の遠隔ホストよりもむしろ、一組の遠隔ホスト候補を選択し、次にその組の中から個別ホストを無作為に選択する。
【００１７】コシェルは、状態ファイル中の現在情報および属性ファイル中の静的情報に基づいて、一組の遠隔ホスト候補を選択する。属性ファイルは、すべてのコシェルによって共用されるものがただひとつ存在する。本発明によって共用されることができる各ホストの場合は、一般には、属性ファイルは、以下の属性、すなわち、形式、定格、遊休、ｍｅｍ（下記参照）、およびｐｕｓｅｒ（下記参照）を記憶する。属性ファイルの説明用例を、図２の表に示す。図２の各行は左から右に、ホスト名、次いで、そのホストに対する各属性の値の割当を示す。」
　
（２）引用発明の認定
　
　ここで，引用文献１に記載されている事項を検討する。
　
ア　上記Ｂの「ネットワークによって互いに接続される複数のコンピュータ間において計算機資源を共有するためのシステム」及び「遠隔実行のためのジョブを受け取る機能を有する遠隔コンピュータ」との記載並びに上記Ａの「ジョブ１０９が実行されている遠隔ホスト」との記載，遠隔ホストは遠隔コンピュータのことであり，システム内の計算機資源を表すものと認められること等から，引用文献１には，「ジョブを実行する遠隔コンピュータである計算機資源を共有するシステム」であり，「ネットワークによって互いに接続される複数の遠隔コンピュータ」をシステムが備えていることが読み取れる。
　
イ　上記アで確認した記載，上記Ａの「前記ローカルコンピュータ、前記遠隔コンピュータおよび前記スケジューリングコンピュータは、前記複数のコンピュータの内の三つの異なるコンピュータである」との記載及び上記Ｂの「該システムは、さらに、少なくとも前記遠隔コンピュータに関する前記主利用者の現在情報に基づいて、受け取ったジョブを遠隔実行するための位置を選択するスケジューリングコンピュータを備え、前記スケジューリングコンピュータは前記複数のコンピュータのひとつである」との記載等から，「遠隔コンピュータとネットワークによって接続されたスケジューリングコンピュータ」を上記システムが備えていることが読み取れる。
　
ウ　上記イで確認した記載，上記Ｃの「コシェルデーモンプロセスは、それ自体のローカルホスト上、およびネットワークによってコシェルがジョブを実行依頼することができるあらゆる他の遠隔ホスト上において、状態デーモンを開始する。」，「各状態デーモンは、それが実行されているホストに関する一定の現在情報を収集し（すなわち、状態デーモン１０５はホスト１００に関する情報を収集し、一方、状態デーモン１１０はホスト１０１に関する情報を収集する）、この情報をすべての他のネットワークホストにとって可視である固有の状態ファイルに転記する。」及び「すべての状態デーモンに関するすべての状態ファイルは、セントラルディレクトリに保持される。」との記載，上記Ａの「遊休である遠隔ホストが選択され、次に、ジョブ１０９が実行されている遠隔ホストのアクティビティが連続的にモニタリングされる。」との記載並びに上記Ｂの「現在状態プロセスを実行し前記遠隔コンピュータの主利用者に関するアクティビティ情報を含む現在情報を収集し」との記載，「すべての他のネットワークホスト」は「各遠隔コンピュータ」を指すものと認められること等から，引用文献１には，「各遠隔コンピュータに関する現在情報を収集し，この情報を記録する状態ファイルが保持されて」いることが記載されていると解することができる。
　
エ　上記イで確認した記載及び上記Ａの「システムが遠隔ホスト上に遠隔ホストの主利用者のひとつによる幾らかのアクティビティを検出するときは、ジョブの実行は直ちに中断され主利用者に対する不都合が防止される。」及び「中断されたジョブは、別の遊休ワークステーションを選択して移送され、中断されたジョブの実行が再開される」との記載等から，「遠隔コンピュータで何らかのアクティビティが検出されると，遠隔コンピュータ上で実行されていたジョブを中断し，スケジューリングコンピュータによって，状態ファイルに基づいて，別の遊休ワークステーションである遠隔コンピュータの１つを選択して，中断した該ジョブの実行を再開する」ことを特徴とするシステムであることが読み取れる。
　
オ　上記イ及びエで確認した記載等から，「スケジューリングコンピュータによって」，「実行するジョブを受け取った遠隔コンピュータは，当該ジョブを実行し，遠隔コンピュータの主利用者のひとつによるアクティビティを検出するときは，実行中の該ジョブの実行を中断」することを特徴とするシステムであることが読み取れる。
　
カ　上記ウ，エで確認した記載及び上記Ｃの「コシェルは、これらの状態ファイルを使用し、コシェルの利用者によって実行依頼されたジョブを実行するための適切な遠隔ホストを選択する。」との記載，「実行依頼されたジョブ」は「中断した該ジョブ」を指すものと認められること等から，「実行中の該ジョブの実行が中断された場合に，ネットワークを介して可視である状態ファイルを，コシェルが使用し，中断した該ジョブを実行するための適切な別の遠隔コンピュータを選択し，選択された前記遠隔コンピュータは中断した該ジョブの実行を再開する」ことが読み取れる。
　
キ　以上，ア〜カで検討した事項を踏まえると，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　
「ジョブを実行する遠隔コンピュータである計算機資源を共有するシステムであって，
　ネットワークによって互いに接続される複数の遠隔コンピュータと，
　遠隔コンピュータとネットワークによって接続されたスケジューリングコンピュータと，
　を備え，
　各遠隔コンピュータに関する現在情報を収集し，この情報を記録する状態ファイルが保持されており，
　遠隔コンピュータで何らかのアクティビティが検出されると，前記遠隔コンピュータ上で実行されていたジョブを中断し，
　スケジューリングコンピュータによって，状態ファイルに基づいて，別の遊休ワークステーションである遠隔コンピュータの１つを選択して，中断した該ジョブの実行を再開されるものであり，
　前記スケジューリングコンピュータによって，
　実行するジョブを受け取った遠隔コンピュータは，該ジョブを実行し，
　遠隔コンピュータの主利用者のひとつによるアクティビティを検出するときは，実行中の該ジョブの実行を中断し，
　実行中の該ジョブの実行が中断された場合に，ネットワークを介して可視である状態ファイルを，コシェルが使用し，中断した該ジョブを実行するための適切な別の遠隔コンピュータを選択し，
　選択された前記遠隔コンピュータが中断した該ジョブの実行を再開する
　ことを特徴とするシステム。」
　
（３）引用文献２
　
　本願の出願前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２５年１０月１８日付けの拒絶理由通知において引用された文献である特開２００２−２６９３９４号公報（平成１４年９月２０日出願公開。以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
　
Ｄ．「【０００１】
【発明の属する技術分野】本発明は分散処理仲介システムおよび方法に関するものであり、より詳細には広域網に常時接続されたパソコン等の余剰処理能力を利用するための仲介を行う分散処理仲介システムに関するものである。
・・・（中略）・・・
【０００８】
【発明が解決しようとする課題】しかしながら、図８のような分散処理システムにおいては、分散処理委託端末１０、分散処理能力提供端末３０の双方において、以下のよう不な弊害があった。すなわち、分散処理委託端末１０は、ボランティアを募るためにインターネット上にホームページを置いて対外的な啓蒙活動をする必要がある。また分散処理委託端末１０は、ボランティアに悪意がある場合には、処理結果が信用できない危険性、および処理のために提供した情報を悪用される危険性がある。たとえば、委託者が提供するプログラムになりすます偽プログラムをボランティアが使用することも想定される。分散処理委託端末１０は分散処理を依頼する以上、実行するプログラムの処理内容や、プロジェクト委託者の情報を分散処理能力提供端末３０に開示する必要がある。すなわち、プロジェクト委託者のプライバシーはボランティアに漏洩される。
【０００９】一方、ボランティア参加希望者は、まずネットワーク上でどのようなプロジェクトが参加者を募集しているかを検索する必要がある。幸運に１つのプロジェクトを探し当てたとしても、そのプロジェクトの目的や、委託者の信頼性などについてチェックする必要がある。また、ボランティアは、プログラムを実行した結果、所有するコンピュータに不具合が発生するリスクを負うことになる。たとえば、悪意のあるプログラムや、ウィルス、バグを含むプログラムなどによって、通常の使用に支障をきたすような事態を招く危険性がある。また、ボランティアは、プロジェクトに参加すると、自分の存在をプロジェクト委託者に知らせることになる。実行するプログラムによっては、コンピュータ上の個人情報が盗まれてしまう恐れがある。電子商取引が一般的になった状況では、コンピュータ上に秘匿性の高い情報が存在するようになるので、非常に高いリスクとなる。
【００１０】本発明は、上述の課題に鑑みてなされたもので、その目的とするところは、ネットワーク上で分散処理によって大規模な計算を効率よく処理すると共に、従来の分散処理委託端末および分散処理能力提供端末のそれぞれの弊害を解消できる分散処理仲介システムおよび方法を提供することにある。
【００１１】
【課題を解決するための手段】上記の目的を達成するため、本発明は、
分散処理を委託する分散処理委託端末と、情報処理能力が余っている分散処理能力提供端末と、これらの間でネットワークを介して仲介サービスを行う分散処理仲介サーバとを備え、前記分散処理仲介サーバは分散処理能力提供端末の提供する余剰処理能力を分散処理委託端末に仲介することを特徴とする。
・・・（中略）・・・
【００２９】
本発明をゲームセンターに設置されるアミューズメントマシンに応用する例について説明する。ゲームセンタに設置され、ネットワークに常時接続されたアミューズメントマシンは、空きの場合には、処理能力が余っている。このようなアミューズメントマシンを分散処理能力提供端末として導入する。従来、ランニングコストがかかるだけであった空きのアミューズメントマシンを分散処理能力提供端末として導入することによって、自動的に分散処理能力を提供して
　
（４）引用文献３
　
　本願の出願前に頒布または電気通信回線を通じて公衆に利用可能となり，原審の拒絶の査定の理由である上記平成２５年１０月１８日付けの拒絶理由通知において引用された文献である特開２００６−２２３４１９号公報（平成１８年８月３１日出願公開。以下，「引用文献３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
　
Ｅ．「【要約】
【課題】　
ゲーム装置における余剰の計算能力を効率的に活用する方法を簡易に実現することのできるゲームシステムを提供する。
【解決手段】　ゲーム装置１０１は、各フェーズにおけるユーザ同士の対戦状況を集計し、そのフェーズで行われる対戦数を求める。ゲーム装置１０１が一度に処理できる対戦数より、求められた対戦数が少ない場合、そのゲーム装置１０１は余剰の計算能力を持つ。その場合、ゲーム装置１０１は、試合要求信号を、一度に処理できる対戦数と求められた対戦数との差を特定する情報と共にサーバ１に送信する。サーバ１は、試合要求信号を受信し、未処理の対戦に関する情報があれば、それをゲーム装置１０１に処理させるべく、試合要求信号を送信してきたゲーム装置１０１に送信する。」
　
Ｆ．「【００８９】
　
決定された対戦数が処理可能対戦数より少ない場合（Ｓ３Ｎｏ）、そのゲーム装置には余剰の処理能力があるため、ゲーム装置は試合要求を行う。
【００９０】
　制御部１１は、RAM１２を参照し上述したデータが格納されていれば（Ｓ４Ｙｅｓ）、サーバ１に、試合要求信号と、それらの情報を送信する（Ｓ６）。RAM１２に送信すべきデータがなければ（Ｓ４Ｎｏ）、制御部１１は、試合要求信号のみを送信する（Ｓ５）。なお、ステップＳ５又はＳ６で送信される試合要求信号には、
処理可能対戦数からステップＳ２で求まる対戦数を引いた差を特定する情報が、ゲーム装置における余剰の処理能力を示す情報として追加され送信される。
【００９１】
　ステップＳ５又はＳ６の処理が済むと、ゲーム装置は、サーバ１が試合要求信号に対する応答として送信するチームデータを受信し、制御部１１は、受信したチームデータをローカル対戦表（図１２）に格納する（Ｓ７）。続いて、ゲーム装置の制御部１１は、ローカル対戦表（図１２）に格納されたチームデータを基に各対戦試合を処理する（Ｓ８）。
・・・（中略）・・・
【００９７】
　なお、
ステップＳ３において、処理可能対戦数がステップＳ２で決定された対戦数に等しい場合（Ｓ３Ｙｅｓ）、そのゲーム装置には余剰の処理能力はなく試合要求は行わない。
　
　
５　対比
　
　本願発明と引用発明とを対比する。
　
（１）引用発明は，「ジョブを実行する遠隔コンピュータである計算機資源を共有するシステム」であり，このような複数のコンピュータを接続してコンピュータの計算機資源を共有するシステムのことを「クラスター化」あるいは「クラスタリング」と呼ぶことは当該技術分野では周知であることから，本願発明と引用発明とは，「クラスタリングによってタスクを処理するクラスタリングシステム」である点で共通する。
　
（２）引用発明は，「ネットワークによって互いに接続される複数の遠隔コンピュータと，
　遠隔コンピュータとネットワークによって接続されたスケジューリングコンピュータと，
　を備え」ているものであり，本願発明は，「アミューズメント施設内に複数設置されたゲーム機と、前記各ゲーム機にそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、前記アミューズメント施設内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバと，を有し」ているところ，ゲーム機はコンピュータの一態様であり，コンピュータというものは演算処理ユニットを備えるものである。してみると，引用発明には，「アミューズメント施設内に複数設置されたゲーム機」に関する記載がない点で本願発明と相違するものの，本願発明と引用発明とは，「各コンピュータにそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、前記システム内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続されたコンピュータと，を有し」ている点で共通する。
　
（３）引用発明は，「スケジューリングコンピュータ」を備えており，本願発明の「管理サーバ」に相当する。
　
（４）引用発明は，「各遠隔コンピュータに関する現在情報を収集し，この情報を記録する状態ファイル」が保持されており，この「各遠隔コンピュータに関する現在状態」は，本願発明の「各演算処理ユニットの稼働状態をリアルタイムで示す処理状態」に相当する。してみると，引用発明の「状態ファイル」と本願発明の「処理状態テーブル」とは，情報の管理の仕方がファイルなのか，テーブルなのかが異なる点で相違するものの，引用発明と，本願発明とは，「各演算処理ユニットの可動状態をリアルタイムで示す処理状態に関する情報」を保持している点で共通する。
　
（５）引用発明は，「遠隔コンピュータで何らかのアクティビティが検出されると，前記遠隔コンピュータ上で実行されていたジョブを中断し，
スケジューリングコンピュータによって，状態ファイルに基づいて，別の遊休ワークステーションである遠隔コンピュータの１つを選択して，中断した該ジョブの実行を再開されるもの」であり，当該処理は，本願発明の「タスク管理手段」が実行する処理に相当する。
　したがって，引用発明と，本願発明とは，「管理サーバに所定のタスクが新たに発生した場合に、処理状態テーブルに基づいて各演算処理ユニットのうちタスクを処理可能な演算処理ユニットを選択し前記タスクを処理するように指示するタスク管理手段」を有する点で共通する。
　
（６）引用発明では，「前記スケジューリングコンピュータによって，
　実行するジョブを受け取った遠隔コンピュータは，該ジョブを実行し，
　遠隔コンピュータの主利用者のひとつによるアクティビティを検出するときは，実行中の該ジョブの実行を中断し，
　実行中の該ジョブの実行が中断された場合に，ネットワークを介して可視である状態ファイルを，コシェルが使用し，中断した該ジョブを実行するための適切な別の遠隔コンピュータを選択し，選択された前記遠隔コンピュータが中断した該ジョブの実行を再開する」ことから，本願発明の「ゲーム処理」に関する記載はないものの，「タスク処理手段」と，「タスク引継手段」に相当する処理を，引用発明においても有している点が読みとれる。
　したがって，引用発明と，本願発明とは，「前記タスク管理手段によって処理を指示された前記タスクを処理し、遠隔コンピュータの主利用者がアクティビティ処理を開始するときには，処理中の前記タスクを中断するタスク処理手段」と，「前記タスク処理手段によって前記タスクが中断された場合に」、「前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と」を有し，「前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する」点で共通する。
　
（７）以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点）
「クラスタリングによってタスクを処理するクラスタリングシステムであって，
　各コンピュータにそれぞれ搭載されローカルネットワークを介して互いに接続された演算処理ユニットと、前記システム内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバと，
を有し，しかも，
　各演算処理ユニットの可動状態をリアルタイムで示す処理状態に関する情報と，
　管理サーバに所定のタスクが新たに発生した場合に、処理状態テーブルに基づいて各演算処理ユニットのうちタスクを処理可能な演算処理ユニットを選択し前記タスクを処理するように指示するタスク管理手段と，
　前記タスク管理手段によって処理を指示された前記タスクを処理し、遠隔コンピュータの主利用者がアクティビティ処理を開始するときには，処理中の前記タスクを中断するタスク処理手段と，
　前記タスク処理手段によって前記タスクが中断された場合に、前記各演算処理ユニットのうち前記中断されたタスクを処理可能な他の演算処理ユニットを選択し前記中断されたタスクを処理するように指示するタスク引継手段と，
　を有し，
　前記他の演算処理ユニットは、前記処理を指示されたタスクの処理を開始する
　ことを特徴とするクラスタリングシステム。」
　
（相違点１）
　本願発明は，「アミューズメント施設内に複数設置されたゲーム機と」，「前記アミューズメント施設内に設置され前記各演算処理ユニットと前記ローカルネットワークを介して接続された管理サーバ」を備えたクラスタリングシステムであり，「前記演算処理ユニットは、プレイヤにゲームプレイを提供するためのゲーム処理をするゲーム処理手段」を有するのに対して，引用発明では，クラスタリングシステムについて記載はあるものの，クラスタリングシステム内のコンピュータとしてアミューズメント施設内のゲーム機が利用できるかどうかについて言及されていない点。
　
（相違点２）
　本願発明は，「前記各演算処理ユニットの可動状態をリアルタイムで示す処理状態テーブル」を保持しているのに対して，引用発明では，「状態ファイル」が保持されているものであり，処理状態に関する情報の管理の仕方が異なる点。
　
　
６　当審の判断
　
　上記相違点について検討する。
　
（１）　相違点１について
　
　引用文献２（上記Ｄの記載参照。）及び引用文献３（上記Ｅ，Ｆの記載参照）にも記載されているように，ゲームセンターに設置されるアミューズメントマシンやゲーム装置が使用されずに余剰となる計算能力がある場合に，その余剰の計算能力を他の処理に提供して，効率的に活用することは，周知慣用技術であるものと認められる。
　ここで，引用文献１〜３は，複数のコンピュータがネットワークで接続されクラスタリング構成を有するものであることから，引用発明の用途を引用文献２，３に記載されているごときアミューズメント施設として本願発明のように，ゲームセンター等のアミューズメント施設内のアミューズメントマシンによるクラスタリングシステムにおけるジョブ実行の制御方法とすることは，当業者であれば容易に想到しうることである。
　その場合は，引用発明の遠隔コンピュータで検出される「何らかのアクティビティ」が，本願発明の演算処理ユニットがプレイヤーが開始する「ゲーム処理」に対応することは，平成２６年１月２１日付け拒絶査定にも記載した通りである。
　
（２）　相違点２について
　
　管理している情報をテーブルとして保持するようなことは，情報処理の技術分野における常套手段であることから，上記「処理状態に関する情報」に関して，引用発明の「状態ファイル」を，本願発明のようにテーブルとして保持するように変更することは，当業者の通常の創作能力の発揮に過ぎず，当業者であれば容易に想到しうることである。
　
（３）　まとめ
　
　以上のように，相違点１および相違点２に係る構成は，引用発明及び，引用文献２，３に記載の周知慣用技術に基づいて，当業者であれば容易に想到しうる事項である。
　そして，本願発明の奏する作用効果も，引用発明の属する技術分野の周知技術の奏する作用効果から予測される範囲内のものに過ぎず，格別顕著なものでもない。
　したがって，本願発明は，上記引用文献１に記載された発明に基づいて，当業者が容易に発明をすることができたものである。
　
　
７　審判請求書における請求人の主張について
　
（１）請求人は，上記「２　本願発明及び原審拒絶理由通知・請求人の主張等」の「（２）
意見書（平成２５年１２月２０日提出）の内容
本件審判請求（平成２６年４月２１日提出）の理由に記載された審判請求人の主張
　しかしながら，原審拒絶理由通知においては，上記引用文献１を主引例として，本願発明との対比をした上で，その相違点について，引用文献２，３を周知技術であるとして挙げて，当業者が容易に想到したものと判断しているのであり，出願人が主張する上記前提に立った判断はなされていない。
　そして，上記「３　拒絶理由・請求人の主張等」の「（３）
原審拒絶査定（平成２６年１月１０日起案）の内容
　
　なお，出願人は，意見書及び審判請求書において，本願発明の構成要件Ｆ−３と構成要件Ｇが引用文献３に開示されていない旨の主張もしているが，当該構成要件については，上述の「４　引用文献」の「（３）対比」に記載のとおり，構成要件Ｆ−３及び構成要件Ｇに関する事項は，ゲーム処理に関する部分及び各処理状態の情報をテーブルで保持すること以外は，引用文献１に開示されているものであることから，審判請求書における，この主張も認めることができないものである。
　
　８　むすび
　
　以上のとおり，本願発明は，その出願前に日本国内において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて，当業者が容易に発明することができたものであるから，特許法第２９条第２項の規定により特許を受けることができないものであり，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　
　よって，結論のとおり審決する。