【事件の表示】
　特願２００５−１４４４８０「管理プログラム、該プログラムを記録した記録媒体、管理方法、ノード群」拒絶査定不服審判事件〔平成１８年１１月３０日出願公開、特開２００６−３２３５２６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　
　本願は、平成１７年５月１７日の出願であって、平成２１年１０月２８日付けで拒絶理由通知（同年１１月１０日発送）がなされ、平成２２年１月１２日付けで意見書が提出されるとともに手続補正がなされ、平成２２年５月１９日付けで最後の拒絶理由通知（同年５月２５日発送）がなされ、平成２２年７月２６日付けで意見書が提出されるとともに手続補正がなされたが、平成２２年８月１２日付けで、前記平成２２年７月２６日付け手続補正を却下（同年８月２４日発送）するとともに、同日付けで拒絶査定（同年８月２４日発送）がなされ、これに対して、同年１１月２４日付けで審判請求がなされるとともに手続補正がなされたものである。そして、平成２２年１２月１７日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、平成２３年６月２日付けで当審より審尋（同年６月７日発送）がなされ、同年８月８日付けで回答書が提出されたものである。
　
第２　平成２２年１１月２４日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　
　平成２２年１１月２４日付けの手続補正を却下する。
　
［理由］
　
１．補正の内容
　
　平成２２年１１月２４日付けの手続補正（以下、「本件補正」という。）の内容は、平成２２年１月１２日付けの手続補正により補正された特許請求の範囲の請求項１乃至請求項１０の記載
　
「　【請求項１】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　サービスの提供に関する処理に対してノードの割り当て処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程において停止を検出した場合に、サービスの提供に関する処理に対してノードの割り当て処理を開始する起動工程と、
　を実行させることを特徴とする管理プログラム。
　　【請求項２】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　前記割り当て処理を行うノードに、自ノードの負荷情報を通知する通知工程と、
　前記割り当て処理を行うノードから、前記割り当て処理を行うノードに通知されたノードの負荷情報を取得する取得工程と、
　前記検出工程において停止した場合に、取得した前記ノードの負荷情報に基づいて、自ノードが前記割り当て処理を開始するかを判断する判断工程と、
　をさらに実行させることを特徴とする請求項１に記載の管理プログラム。
　　【請求項３】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　自ノードが前記割り当て処理を実行していない場合に、自ノードが割り当て処理を実行するノードでない旨の否決情報を他のノードに発信する発信工程をさらに実行させ、
　前記取得工程は、
　さらに、前記他のノードから前記否決情報を取得し、
　前記判断工程は、
　取得された否決情報に基づいて、自ノードが割り当て処理を開始するか否かを判断することを特徴とする請求項２に記載の管理プログラム。
　　【請求項４】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　自ノードにおいて前記割り当て処理が実行された場合に、前記自ノードに割り当てられたサービスの提供に関する処理を他のノードのいずれかに移行する移行工程をさらに実行させることを特徴とする請求項１〜請求項３記載の管理プログラム。
　　【請求項５】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　前記割り当て処理を行うノードの指定を受け付ける受付工程をさらに実行させ、
　前記受付工程において自ノードが指定された場合に、前記割り当て処理を実行させることを特徴とする請求項１〜請求項４記載の管理プログラム。
　　【請求項６】
　サービスの提供に関する処理を実行可能なノードのコンピュータに、
　自ノードが前記割り当て処理を行う場合、他のノードに関するクラスタ情報を生成する生成工程と、
　前記クラスタ情報を自ノードのメモリに格納する格納工程と、
　前記クラスタ情報を、前記他のノードに配信する配信工程と、
　を実行させることを特徴とする請求項１〜請求項５記載の管理プログラム。
　　【請求項７】
　請求項１〜請求項６のいずれか一つに記載の管理プログラムを記録したコンピュータに読み取り可能な記録媒体。
　　【請求項８】
　連携してサービスを提供可能な複数のノードのうち、いずれかのノードにおいて、
　前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程において停止を検出した場合に、前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を開始する起動工程と、
　を含んだことを特徴とする管理方法。
　　【請求項９】
　連携してサービスを提供可能な複数のノードのうち、いずれかであって、
　前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を行うノードが停止したか否かを検出する検出手段と、
　前記検出する手段において停止を検出した場合に、前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を開始する起動手段と、
　を備えることを特徴とするノード。
　　【請求項１０】
　連携してサービスを提供可能な複数のノードからなるクラスタであって、
　前記クラスタを構成する各ノードが、
　前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を行うノードが停止したか否かを検出する検出手段と、
　前記検出手段において停止を検出した場合に、前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を開始する起動手段と、
　を備えることを特徴とするクラスタ。」（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）
　
を、
　
「　【請求項１】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　前記複数のノードに含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程においてノードの停止を検出した場合に、前記あるノードを含む前記複数のノードを対象に、前記サービスの提供に関する処理を割り当てる処理を開始する起動工程と、
　を含むことを特徴とする管理プログラム。
　　【請求項２】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　前記割り当てる処理を行うノードに、自ノードの負荷情報を通知する通知工程と、
　前記割り当てる処理を行うノードから、前記割り当てる処理を行うノードに通知されたノードの負荷情報を取得する取得工程と、
　前記検出工程においてノードが停止した場合に、取得した前記ノードの負荷情報に基づいて、自ノードが前記割り当てる処理を開始するかを判断する判断工程と、
　をさらに実行させることを特徴とする請求項１に記載の管理プログラム。
　　【請求項３】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　自ノードが前記割り当てる処理を実行していない場合に、自ノードが割り当てる処理を実行するノードでない旨の否決情報を他のノードに発信する発信工程をさらに実行させ、
　前記取得工程は、
　さらに、前記他のノードから前記否決情報を取得し、
　前記判断工程は、
　取得された否決情報に基づいて、自ノードが割り当てる処理を開始するか否かを判断することを特徴とする請求項２に記載の管理プログラム。
　　【請求項４】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　自ノードにおいて前記割り当てる処理が実行された場合に、前記自ノードに割り当てられたサービスの提供に関する処理を他のノードのいずれかに移行する移行工程をさらに実行させることを特徴とする請求項１〜請求項３のいずれか一つに記載の管理プログラム。
　　【請求項５】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　前記割り当てる処理を行うノードの指定を受け付ける受付工程をさらに実行させ、
　前記受付工程において自ノードが指定された場合に、前記割り当てる処理を実行させることを特徴とする請求項１〜請求項４のいずれか一つに記載の管理プログラム。
　　【請求項６】
　連携してサービスを提供可能な複数のノードのうちのあるノードによって実行されるプログラムであって、
　自ノードが前記割り当てる処理を行う場合、他のノードに関するクラスタ情報を生成する生成工程と、
　前記クラスタ情報を自ノードのメモリに格納する格納工程と、
　前記クラスタ情報を、前記他のノードに配信する配信工程と、
　を実行させることを特徴とする請求項１〜請求項５のいずれか一つに記載の管理プログラム。
　　【請求項７】
　請求項１〜請求項６のいずれか一つに記載の管理プログラムを記録したコンピュータに読み取り可能な記録媒体。
　　【請求項８】
　連携してサービスを提供可能な複数のノードのうちのあるノードにおいて、
　前記複数のノードに含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程においてノードの停止を検出した場合に、前記あるノードを含む前記複数のノードを対象に、前記サービスの提供に関する処理を割り当てる処理を開始する起動工程と、
　を含むことを特徴とする管理方法。
　　【請求項９】
　連携してサービスを提供可能なノード群であって、
　前記ノード群に含まれる各ノードが、
　前記サービスの提供に関する処理を前記ノード群に含まれるノードに割り当てる処理を制御に応じて実行する割当手段と、
前記割当手段の処理を実行するノードが停止したか否かを検出する検出手段と、
　前記検出手段においてノードの停止を検出した場合に、前記サービスの提供に関する処理に前記ノード群に含まれるノードを割り当てる処理を開始させる制御を行う起動手段と、
　を含むことを特徴とするノード群。」（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
　
に補正することを含むものである。
　
　
２．新規事項の有無、補正の目的要件 
　
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第１７条の２第３項の規定に適合している。
　
　そして本件補正は、特許法第１７条の２第４項第１号の請求項の削除を目的として、補正前の請求項１０を削除し、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的として、補正前の請求項１、８における「ノードの割り当て処理を行うノード」に対して、「複数のノードに含まれるノードであって」というように限定を行い、そして、特許法第１７条の２第４項第４号の明りょうでない記載の釈明を目的として、各請求項間における記載ぶりを統一したものである。
　
３．独立特許要件
　
　そこで、本件補正後の請求項８に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）以下に検討する。
　
（１）補正後の発明
　
　本件補正により、本願補正発明は、前記「１．補正の内容」の補正後の請求項８に記載された以下のとおりのものである。
　
「連携してサービスを提供可能な複数のノードのうちのあるノードにおいて、
　前記複数のノードに含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程においてノードの停止を検出した場合に、前記あるノードを含む前記複数のノードを対象に、前記サービスの提供に関する処理を割り当てる処理を開始する起動工程と、
　を含むことを特徴とする管理方法。」
　
（２）引用文献に記載されている技術的事項及び引用発明の認定
　
　原審が拒絶理由通知において引用した特開２００４−２６４９１１号公報 （平成１６年９月２４日公開、以下、「引用文献１」という。）には、関連する図面とともに以下の技術的事項が記載されている。（当審注：下線は、参考のために当審で付与したものである。）
　
Ａ　「【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上の計算機をノードとし、複数のノードを１つのシステムとして動作させるクラスタシステムにおいて、ノード故障などの構成の変化に柔軟に対応できる
クラスタ管理方法
　
Ｂ　「【００３９】
まず、本実施の形態に係るクラスタシステムの構成について、図１を用いて説明する。図１は、本実施の形態に係るクラスタシステムの構成の一例を示すブロック図である。
図１に示すように、本実施の形態に係るクラスタシステム１は、コーディネータノード２と実ノード３ａ，３ｂ，３ｃから構成される
　
Ｃ　「【００４０】
本実施の形態に係るクラスタシステムでは、ユーザアプリケーションにクラスタ内のノードを直接操作することを禁止する。これは仮想的な計算機ノードである仮想ノードだけをクライアント５に提供し、実際にアプリケーションを実行する物理的な計算機ノードである実ノードを隠蔽することにより実現される。
コーディネータノードとは、クライアントからの要求や実ノードの負荷状態等に応じて、実ノードに対して仮想ノードやアプリケーション実行の割り当てを行う計算機ノード
　
Ｄ　「【００６８】
以上のように、
コーディネータノード２が実ノードの負荷状態や故障等に応じてＶＩＰをＲＩＰへ割り振ることにより、ノードの負荷の変化やノードの故障に柔軟に対応でき、高可用性を実現することができる
　
Ｅ　「【００６９】
実施の形態２．
本実施の形態では、
図１で説明した本発明のクラスタシステムをＨＰＣモードで使う場合について説明する。ＨＰＣモードでは、複数のアプリケーションの実行を複数の実ノードで分担して行う
コーディネータノード２がクライアント５に対して複数の仮想ノードを提供し、実ノード間で通信を行うことにより、ＨＰＣ型のアプリケーションが動作可能となる
　
Ｆ　「【００７８】
ノード割り当て完了通知を受信したオペレータ６は、サーバ起動要求を行う（Ｓ３０５）。サーバ起動要求を受けた
コーディネータノード２は、各実ノード３ａ，３ｂ，３ｃに対してサーバ起動を指示する
。各実ノード３ａ，３ｂ，３ｃは、自ノードを起動させると共に、起動したことを示す情報をコーディネータノード２へ返す
　
Ｇ　「【００８４】
以上、実施の形態１から実施の形態３において本発明のクラスタシステムについて説明したが、図３で説明した本発明のクラスタシステムの構成において、コーディネータノード２が状況に応じたＩＰ管理テーブルを作成することにより、実施の形態１で説明したｒｓｈモード、実施の形態２で説明したＨＰＣモード、実施の形態３で説明したＷＷＷモードからなる３つのモードをいずれかに切り替えて動作させたり、３つのモードを組み合わせて動作させるようにすることも可能である。また、
実ノードのいずれかに仮想ノード提供部２２２とパケット割り振り部２２３とコーディネータ２３の機能を備えることにより、コーディネータノード２として機能することが可能となるため、コーディネータノード２が故障した場合にも対応することができる。これによりさらに高信頼性を実現することができる
　
（ア）上記Ａの「本発明は、ネットワーク上の計算機をノードとし、複数のノードを１つのシステムとして動作させるクラスタシステムにおいて、ノード故障などの構成の変化に柔軟に対応できる…（中略）…クラスタ管理方法」との記載からすると、引用文献１には、複数のノードを１つのシステムとして動作させるクラスタシステムにおけるクラスタ管理方法が記載されているものと認められる。
　
（イ）上記Ｂの「図１に示すように、本実施の形態に係るクラスタシステム１は、コーディネータノード２と実ノード３ａ，３ｂ，３ｃから構成される」との記載、上記Ｅの「図１で説明した本発明のクラスタシステムをＨＰＣモードで使う場合について説明する。ＨＰＣモードでは、複数のアプリケーションの実行を複数の実ノードで分担して行う。…（中略）…コーディネータノード２がクライアント５に対して複数の仮想ノードを提供し、実ノード間で通信を行うことにより、ＨＰＣ型のアプリケーションが動作可能となる」との記載、及び上記Ｃの「コーディネータノードとは、クライアントからの要求や実ノードの負荷状態等に応じて、実ノードに対して仮想ノードやアプリケーション実行の割り当てを行う計算機ノード」との記載からすると、引用文献１には、複数のノードで分担して複数のアプリケーションの実行（以下、「サービス」という。）を提供するクラスタシステムにおけるあるノードにおいて、複数のノード（コーディネータノード２と実ノード３ａ，３ｂ，３ｃ）に含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うコーディネータノードを含む態様が記載されているものと認められる。
　
（ウ）上記Ｄの「コーディネータノード２が実ノードの負荷状態や故障等に応じて…（中略）…割り振ることにより、ノードの負荷の変化やノードの故障に柔軟に対応でき、高可用性を実現することができる」との記載、及び上記Ｆの「コーディネータノード２は、各実ノード３ａ，３ｂ，３ｃに対してサーバ起動を指示する…（中略）…。各実ノード３ａ，３ｂ，３ｃは、自ノードを起動させると共に、起動したことを示す情報をコーディネータノード２へ返す」との記載から、引用文献１には、ノードが故障した場合に、コーディネータノードは、複数のノードを対象に、サービスの提供に関する処理を割り当てる処理を開始する工程（以下、「起動工程」という。）が記載されているものと認められる。そして、上記Ｇに「実ノードのいずれかに仮想ノード提供部２２２とパケット割り振り部２２３とコーディネータ２３の機能を備えることにより、コーディネータノード２として機能することが可能となるため、コーディネータノード２が故障した場合にも対応することができる。これによりさらに高信頼性を実現することができる」と記載されていることから、実ノードにコーディネータの機能を備えさせることにより、コーディネータノードが故障した場合においても、（コーディネータ機能を有するノードが、）複数のノードを対象に、サービスの提供に関する処理を割り当てる処理を開始する起動工程を含む態様が記載されているものと認められる。　
　
　以上、（ア）乃至（ウ）で指摘した事項から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認める。
　
　複数のノードで分担してサービスを提供するクラスタシステムにおけるあるノードにおいて、
　前記複数のノードに含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うコーディネータノードが故障した場合に、前記複数のノードを対象に、前記サービスの提供に関する処理を割り当てる処理を開始する起動工程
　を含むことを特徴とするクラスタ管理方法。
　
（３）本願補正発明と引用発明との対比
　
　引用発明の「複数のノードで分担してサービスを提供する」ことは、複数のノードが連携してサービスを提供することに他ならない。してみれば、引用発明の「複数のノードで分担してサービスを提供するクラスタシステムにおけるあるノード」は、本願補正発明の「連携してサービスを提供可能な複数のノードのうちのあるノード」に相当すると言える。
　
　引用発明の「複数のノードに対して割り当てる処理を行うコーディネータノード」は、本願補正発明の「複数のノードに対して割り当てる処理を行うノード」に相当する。
　
　引用発明の「コーディネータノードが故障した場合」と、本願補正発明の「ノードの停止を検出した場合」とは、ともに、「ノードが使用できなくなった場合」である点で共通する。
　
　引用発明の「複数のノード」が「あるノード」を含むことは明らかであるから、引用発明の「複数のノード」は、本願補正発明の「あるノードを含む複数のノード」に相当すると言える。
　
　引用発明の「クラスタ管理方法」は、本願補正発明の「管理方法」に相当する。
　
　したがって、本願補正発明と引用発明とは、以下の点で一致し、また、相違している。
　
＜一致点＞
　
　連携してサービスを提供可能な複数のノードのうちのあるノードにおいて、
　前記複数のノードに含まれるノードであって、前記サービスの提供に関する処理を前記複数のノードに対して割り当てる処理を行うノードが使用できなくなった場合に、前記あるノードを含む前記複数のノードを対象に、前記サービスの提供に関する処理を割り当てる処理を開始する起動工程
　を含むことを特徴とする管理方法。
　
＜相違点＞
　
　複数のノードのうちのあるノードにおいて、本願補正発明では、「複数のノードに対して割り当てる処理を行うノードが停止したか否かを検出する検出工程」を有しているのに対して、引用発明では、「複数のノードに対して割り当てる処理を行うコーディネータノード」の故障をどのように検出するか明記されていない点。
　
（４）当審の判断
　
　上記相違点について検討する。
　
　処理を引き継ぐ予定の装置が、現在処理を行っている装置の動作状態を監視することは、周知慣用的に行われている技術に過ぎない（必要であれば、特開平９−２５９０９６号公報（特に、段落【００２１】）等参照）ことから、引用発明のあるノードにおいても、複数のノードに対して割り当てる処理を行うコーディネータノードの動作状態（停止したか否か）を検出する検出工程を備える構成とすることは、当業者であれば、容易に想到し得たものである。
　
　よって、相違点は格別のものではない。
　
　上記で検討したごとく、相違点は格別のものではなく、そして、本願補正発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
　したがって、本願補正発明は、上記引用発明及び周知慣用技術に基づいて、当業者が容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　　
（５）むすび
　
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　
　したがって、本件補正は、特許法第１５９条第１項において準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、補正却下の決定の結論のとおり決定する。
　
第３　本願発明について 
　
１．本願発明の認定
　
　平成２２年１１月２４日付けの手続補正は上記のとおり却下されたので、本願の請求項８に係る発明（以下、同項記載の発明を「本願発明」という。）は、平成２２年１月１２日付け手続補正書の特許請求の範囲の請求項８に記載された事項により特定される、以下のとおりのものである。
　
「連携してサービスを提供可能な複数のノードのうち、いずれかのノードにおいて、
　前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を行うノードが停止したか否かを検出する検出工程と、
　前記検出工程において停止を検出した場合に、前記サービスの提供に関する処理に前記複数のノードを割り当てる処理を開始する起動工程と、
　を含んだことを特徴とする管理方法。」
　
２．引用文献に記載されている技術的事項及び引用発明の認定
　
　原査定の拒絶の理由に引用された、引用文献およびその記載事項は、前記「第２　平成２２年１１月２４日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（２）引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。 
　
３．対比・判断 
　
　本願発明は、前記「第２　平成２２年１１月２４日付けの手続補正についての補正却下の決定」の「３．独立特許要件」の「（１）補正後の発明」に記載された本願補正発明の発明特定事項「前記複数のノードに含まれるノードであって、」を省き、明りょうでない記載の釈明を行ったものである。
　してみると、本願発明の構成も、引用発明及び周知慣用技術に基づいて、当業者が容易に想到し得たものである。
　
　そして、当該構成の採用によって奏される作用効果も、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　
　よって、本願発明は、引用発明及び周知慣用技術に基づいて、当業者が容易に発明をすることができたものである。
　
４．むすび
　
　以上のとおり、本願の特許請求の範囲の請求項８に係る発明は、本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。