【事件の表示】
　特願２００３−５５００５９「ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト」拒絶査定不服審判事件〔平成１５年　６月１２日国際公開、ＷＯ０３／４８９３４、平成１７年　４月２８日国内公表、特表２００５−５１２１９０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
その１．手続の経緯
　本願は、２００２年１２月２日（パリ条約による優先権主張外国庁受理２００１年１１月３０日、アメリカ合衆国）を国際出願日とする出願であって、
　平成１６年７月１６日付けで特許法第１８４条の４第１項の規定による翻訳文が提出され、平成１７年１１月３０日付けで審査請求がなされるとともに手続補正がなされ、平成２０年６月２６日付けで審査官により拒絶理由が通知され、これに対して、同年１０月１日付けで意見書が提出されるとともに手続補正がなされ、同年１０月２９日付けで審査官により拒絶理由が通知され、これに対して、平成２１年１月２９日付けで意見書が提出されるとともに手続補正がなされたが、同年３月２６日付けで審査官により拒絶査定がなされ、同年６月２６日付けで審判請求がなされるとともに手続補正がなされ、同年８月１７日付けで、特許法第１６４条第３項の規定により審査官による報告がなされ、平成２２年１１月３０日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ、平成２３年３月２３日付けで回答書の提出があったものである。
　
　
その２．補正却下
　
　結論
　
　平成２１年　６月２６日付け手続補正を却下する。
　
　理由
　
１．補正の内容
　平成２１年６月２６日付けの手続補正（以下、「本件手続補正」という）により、特許請求の範囲は、
「　　【請求項１】
　フレームワークから複数のコンポーネントを管理する方法であって、
　ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
　フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
　前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
　前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
　　前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
　　前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
　前記メンバーの少なくとも１つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する、方法。
　　【請求項２】
　前記複数のメンバーは、１組の活性なメンバーおよび１組の非活性なメンバーを含み、前記１組の活性なメンバーのうちのメンバーは、前記１組の非活性なメンバーのうちのメンバーが用いる態様とは異なる態様で前記共通のサービスを提供する、請求項１に記載の方法。
　　【請求項３】
　前記システムのユーザによって特定される構成情報に基づいてフレームワークリソースを介し前記複合リソースを構成するステップをさらに含む、請求項１に記載の方法。
　　【請求項４】
　フレームワークリソースを用いて前記複合リソースを停止するステップをさらに含み、こうして前記複数のメンバーにおける各々のメンバーが停止される、請求項１に記載の方法。
　　【請求項５】
　前記１組の非活性なメンバーのうちのメンバーを有するノードを選択するステップと、
　前記複合リソースの前記１組の非活性なメンバーのうちのメンバーを有するノードから当該選択したノードに対して、前記複合リソースの一部としてのサービスを提供する責務を再割当てするステップとをさらに含む、請求項２に記載の方法。
　　【請求項６】
　前記フレームワークリソースから前記複合リソースの性能特性を測定するステップをさらに含む、請求項１に記載の方法。
　　【請求項７】
　管理者が前記フレームワークリソースを介し前記複合リソースにおいて１つ以上の動作を実行することを可能にするためのインターフェイスを設けるステップをさらに含む、請求項１に記載の方法。
　　【請求項８】
　前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするステップをさらに含む、請求項１に記載の方法。
　　【請求項９】
　前記複合リソースを確立するステップは、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある１組のリソースとともに利用されることを可能にするステップを含み、前記メンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項１に記載の方法。
　　【請求項１０】
　前記サービスを前記コンポーネントに提供するステップは、
　前記サービスが前記複合リソースのうちの第１のメンバーにより前記第１のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
　前記第１のメンバーが障害を起こしたときに、前記複数のメンバーのうちの第２のメンバーにより前記サービスが前記第２のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを含み、前記第２のメンバーのノードは前記第１のメンバーのノードとは異なり、
　前記第１のメンバーの障害に先立ち、前記方法はさらに、前記第２のメンバーのノードにある１組のリソースを用いて前記第２のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第２のメンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記第２のメンバーにより必要とされる、請求項１に記載の方法。
　　【請求項１１】
　前記第１のメンバーが障害を起こしているが前記第１のメンバーのノードはまだ機能していることを検出するステップをさらに含み、前記サービスが第２のメンバーにより前記コンポーネントに提供されることを引起こすステップは、前記第１のメンバーのノードにある１つ以上の他のリソースが機能している間に行なわれる、請求項１０に記載の方法。
　　【請求項１２】
　前記第１のメンバーが障害を起こしたことを検出した後に前記第１のメンバーを自動的に再始動するステップをさらに含む、請求項１１に記載の方法。
　　【請求項１３】
　前記サービスが第２のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップは、前記第１のメンバーの回復を試みている間に実行される、請求項１１に記載の方法。
　　【請求項１４】
　前記複合リソースを確立するステップは、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするステップを含む、請求項１に記載の方法。
　　【請求項１５】
　前記複合リソースは、前記フレームワークによって前記複数のノードにある特定のノードに少なくとも部分的に常駐するものとして見なされる、請求項１に記載の方法。
　　【請求項１６】
　前記フレームワークは前記複数のノードに対して分配される、請求項１に記載の方法。
　　【請求項１７】
　前記複数のノードのうちの第１のノードにおいてアプリケーションを実行するステップをさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項１に記載の方法。
　　【請求項１８】
　前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記共通のサービスを提供しなくなることに応答して、前記方法はさらに前記アプリケーションの実行を終了させるステップを含む、請求項１７に記載の方法。
　　【請求項１９】
　前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記方法はさらに、前記複数のノードのうちの第２のノードに常駐する前記複数のメンバーのうちの第２のメンバーから、前記第１のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するステップを含む、請求項１７に記載の方法。
　　【請求項２０】
　フレームワークから複数のコンポーネントを管理する方法であって、
　第１の複数のメンバーおよび第２の複数のメンバーを含む複合リソースを確立するステップを含み、前記第１および第２の複数のメンバーは、ネットワーク化されたシステムにある複数のノードに常駐し、前記第１の複数のメンバーの各々は共通のサービスを提供するよう活性であり、前記第２の複数のメンバーの各々は、活性化されると前記共通のサービスを提供することができ、前記方法はさらに、
　前記第１の複数のメンバーのうちのメンバーが、前記共通のサービスを要求する第１のコンポーネントに前記サービスを提供するよう前記フレームワークにより手配するステップを含み、前記第１の複数のメンバーのうちのいずれかのメンバーは、前記第１のコンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　前記第１の複数のメンバーにおけるメンバーのうちの１つ以上が非活性になることに応答して、
　　前記第２の複数のメンバーのうちのメンバーを活性化するステップ、
　　および、前記第１の複数のメンバーまたは前記第２の複数のメンバーのうちの一方にある活性なメンバーを用いて前記共通のサービスを自動的に提供するステップ
を実行するステップとを含む、方法。
　　【請求項２１】
　前記複合リソースの状態は、前記複合リソース内の活性な各々のメンバーの状態から独立して維持され、指定された条件が満たされている限り前記複合リソースの状態が活性であり続ける、請求項２０に記載の方法。
　　【請求項２２】
　前記第１の複数のメンバーまたは前記第２の複数のメンバーのうちの１つにおける活性なメンバーを用いて前記共通のサービスを自動的に提供するステップは、前記複合リソースの共通のサービスを提供するよう活性であるメンバーの数を維持するステップを含む、請求項２０に記載の方法。
　　【請求項２３】
　前記第２の複数のメンバーのうちの多数のメンバーを活性化して前記共通のサービスを提供させることにより前記メンバーの数を増大させるステップをさらに含む、請求項２２に記載の方法。
　　【請求項２４】
　前記第１の複数のメンバーのうちのメンバーが前記共通のサービスを提供するよう手配するステップは、前記第１の複数のメンバーおよび前記第２の複数のメンバーにより共有される前記フレームワークのリソースを用いて行なわれる、請求項２０に記載の方法。
　　【請求項２５】
　前記フレームワークリソースを介し、前記第１の複数のメンバーおよび前記第２の複数のメンバーについての状態情報を維持するステップをさらに含む、請求項２４に記載の方法。
　　【請求項２６】
　フレームワークから複数のコンポーネントを管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、請求項１から１９のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。
　　【請求項２７】
　前記複数のメンバーは第１のメンバーおよび第２のメンバーを含み、前記第１のメンバーは、前記第２のメンバーが前記共通のサービスを提供するために用いる態様とは異なる態様で前記共通のサービスを提供する、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項２８】
　前記複数のメンバーにおける各々のメンバーが活性でなくなったときに前記複合リソースの回復を開始させるための命令をさらに含む、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項２９】
　前記システムのユーザによって特定される構成情報に基づいて前記調整部を介し前記複合リソースを構成するための命令をさらに含む、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３０】
　前記調整部を用いて前記複合リソースを停止するための命令をさらに含み、こうして前記複数のメンバーにおける各々のメンバーは実質的に同一のサービスを提供することができなくなる、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３１】
　前記１組の非活性なメンバーのうちのメンバーが常駐するノードから、前記１組の活性なメンバーのうちのメンバーが常駐するノードへ、前記複合リソースのソースを再配置するための命令をさらに含み、前記複合リソースのソースを再配置するステップを実行する直前に、前記活性な複数のメンバーのうちの少なくとも１つは、前記複合リソースのソースが再配置された以前に前記１組の非活性なメンバーのうちのメンバーであった、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３２】
　前記調整部から前記複合リソースの性能特性を測定するための命令をさらに含む、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３３】
　管理者が前記調整部を介し前記複合リソースにおいて１つ以上の動作を実行することを可能にするためのインターフェイスを設けるための命令をさらに含む、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３４】
　前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするための命令をさらに含む、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３５】
　前記複合リソースを確立するための命令は、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある１組のリソースとともに利用されることを可能にするための命令を含み、前記メンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３６】
　前記サービスを前記コンポーネントに提供するための命令は、
　前記サービスが前記複合リソース内の第１のメンバーにより前記第１のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
　前記第１のメンバーが活性でなくなったときに、前記サービスが前記複数のメンバーにおける第２のメンバーにより前記第２のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを実行するための命令を含み、前記第２のメンバーのノードは前記第１のメンバーのノードとは異なり、
　前記第１のメンバーが活性でなくなる前に、前記コンピュータ読取可能な記憶媒体はさらに、前記第２のメンバーのノードにある１組のリソースを用いて前記第２のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第２のメンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記第２のメンバーにより必要とされる、請求項２６に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３７】
　前記第１のメンバーが障害を起こしたが前記第１のメンバーのノードはまだ機能していることを検出するための命令をさらに含み、前記サービスが第２のメンバーにより前記コンポーネントに提供されることを引起こすための命令は、前記第１のメンバーのノードにある前記１つ以上の他のリソースが機能している間に実行される、請求項３５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３８】
　前記サービスが第２のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップを実行するための命令は、前記第１のメンバーの回復を試みる間に前記ステップが実行されるための命令を含む、請求項３７に記載のコンピュータ読取可能な記憶媒体。
　　【請求項３９】
　前記複合リソースを確立するための命令は、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするための命令を含む、請求項２５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４０】
　前記複数のノードのうち１つにおいて前記調整部を実行するための命令をさらに含む、請求項２５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４１】
　前記複数のノードの共有するフレームワークにおいて前記調整部を実行するための命令をさらに含む、請求項２５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４２】
　前記複数のノードのうちの第１のノードにおいてアプリケーションを実行するステップを行なうための命令をさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項２５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４３】
　前記共通のサービスを、前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに提供するための命令をさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記共通のサービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記アプリケーションの実行を終了させるための命令を含む、請求項４２に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４４】
　前記共通のサービスを、前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに提供するための命令をさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記複数のメンバーのうちの、前記複数のノードのうちの第２のノードに常駐する第２のメンバーから、前記第１のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するための命令を含む、請求項４３に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４５】
　フレームワークから複数のコンポーネントを管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、請求項２３から２８のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。
　　【請求項４６】
　前記第１の複数のメンバーのうちの前記第１のメンバーが活性でなくなることから独立して前記第２のサービスを提供するための命令は、前記第１のメンバーが活性でなくなった後に連続的に前記第２のサービスを提供するための命令を含む、請求項４５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４７】
　さらに、
　前記第１のメンバーが第１の組の１つ以上のリソースを用いて前記第１のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第１の組の１つ以上のリソースは、前記第１のサービスを提供するために前記第１のメンバーにより必要とされ、前記第１の組のリソースは前記第１のノードに常駐し、前記コンピュータ読取可能な記憶媒体はさらに、
　前記第２のメンバーが第２の組の１つ以上のリソースを用いて前記第２のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第２の組のリソースは、前記第２のサービスを提供するために前記第２のメンバーにより必要とされ、前記第２の組のリソースは前記第１のノードに常駐し、かつ、前記第１の組のリソースと重なる少なくとも１つのリソースを有する、請求項４５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４８】
　前記第１のノードから前記第２のサービスを提供するための命令は、前記第１のメンバーが活性でなくなったことを検出した直後に前記第２のサービスを提供することにおいて、前記第２の組のリソースが前記第２のメンバーで利用されるように機能しているよう維持するための命令を含む、請求項４７に記載のコンピュータ読取可能な記憶媒体。
　　【請求項４９】
　前記第１の複数のメンバーのうちの第１のメンバーが前記第１のサービスを提供するよう手配するための命令は、第１の調整部を用い前記第１のサービスを調整することで前記第１のメンバーを割当てて前記第１のサービスを前記第１のコンポーネントに提供するための命令を含む、請求項４５に記載のコンピュータ読取可能な記憶媒体。
　　【請求項５０】
　前記第１の複数のメンバーのうちの第２のメンバーが前記第２のサービスを提供するよう手配するための命令は、第２の調整部を用い前記第２のサービスを調整することで前記第２のメンバーを割当てて前記第２のサービスを前記第２のコンポーネントに提供するための命令を含む、請求項４９に記載のコンピュータ読取可能な記憶媒体。
　　【請求項５１】
　前記第１の調整部および前記第２の調整部を介し、前記第１の複数のメンバーおよび前記第２の複数のメンバーについての状態情報を維持するための命令をさらに含む、請求項５０に記載のコンピュータ読取可能な記憶媒体。
　　【請求項５２】
　前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項１に記載の方法。
　　【請求項５３】
　前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項１に記載の方法。
　　【請求項５４】
　前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項２４に記載の方法。
　　【請求項５５】
　前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項２４に記載の方法。」（以下、上記引用の請求項各項を、「補正前の請求項」という）から、
　
「　　【請求項１】
　フレームワークから複数のコンポーネントを管理する方法であって、
　ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記指定された条件は、前記複合リソースにおける活性なメンバーのユーザ指定の最小の数、または、前記複合リソースについてのユーザ指定の最小のサービスレベル、に対応し、前記方法はさらに、
　フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
　前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
　前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
　　前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
　　前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
　前記メンバーの少なくとも１つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新し、
　前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
　前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
　活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない、方法。
　　【請求項２】
　前記複数のメンバーは、１組の活性なメンバーおよび１組の非活性なメンバーを含み、前記１組の活性なメンバーのうちのメンバーは、前記１組の非活性なメンバーのうちのメンバーが用いる態様とは異なる態様で前記共通のサービスを提供する、請求項１に記載の方法。
　　【請求項３】
　前記システムのユーザによって特定される構成情報に基づいてフレームワークリソースを介し前記複合リソースを構成するステップをさらに含む、請求項１に記載の方法。
　　【請求項４】
　フレームワークリソースを用いて前記複合リソースを停止するステップをさらに含み、こうして前記複数のメンバーにおける各々のメンバーが停止される、請求項１に記載の方法。
　　【請求項５】
　前記１組の非活性なメンバーのうちのメンバーを有するノードを選択するステップと、
　前記複合リソースの前記１組の非活性なメンバーのうちのメンバーを有するノードから当該選択したノードに対して、前記複合リソースの一部としてのサービスを提供する責務を再割当てするステップとをさらに含む、請求項２に記載の方法。
　　【請求項６】
　前記フレームワークリソースから前記複合リソースの性能特性を測定するステップをさらに含む、請求項１に記載の方法。
　　【請求項７】
　管理者が前記フレームワークリソースを介し前記複合リソースにおいて１つ以上の動作を実行することを可能にするためのインターフェイスを設けるステップをさらに含む、請求項１に記載の方法。
　　【請求項８】
　前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするステップをさらに含む、請求項１に記載の方法。
　　【請求項９】
　前記複合リソースを確立するステップは、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある１組のリソースとともに利用されることを可能にするステップを含み、前記メンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項１に記載の方法。
　　【請求項１０】
　前記サービスを前記コンポーネントに提供するステップは、
　前記サービスが前記複合リソースのうちの第１のメンバーにより前記第１のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
　前記第１のメンバーが障害を起こしたときに、前記複数のメンバーのうちの第２のメンバーにより前記サービスが前記第２のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを含み、前記第２のメンバーのノードは前記第１のメンバーのノードとは異なり、
　前記第１のメンバーの障害に先立ち、前記方法はさらに、前記第２のメンバーのノードにある１組のリソースを用いて前記第２のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第２のメンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記第２のメンバーにより必要とされる、請求項１に記載の方法。
　　【請求項１１】
　前記第１のメンバーが障害を起こしているが前記第１のメンバーのノードはまだ機能していることを検出するステップをさらに含み、前記サービスが第２のメンバーにより前記コンポーネントに提供されることを引起こすステップは、前記第１のメンバーのノードにある１つ以上の他のリソースが機能している間に行なわれる、請求項１０に記載の方法。
　　【請求項１２】
　前記第１のメンバーが障害を起こしたことを検出した後に前記第１のメンバーを自動的に再始動するステップをさらに含む、請求項１１に記載の方法。
　　【請求項１３】
　前記サービスが第２のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップは、前記第１のメンバーの回復を試みている間に実行される、請求項１１に記載の方法。
　　【請求項１４】
　前記複合リソースを確立するステップは、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするステップを含む、請求項１に記載の方法。
　　【請求項１５】
　前記複合リソースは、前記フレームワークによって前記複数のノードにある特定のノードに少なくとも部分的に常駐するものとして見なされる、請求項１に記載の方法。
　　【請求項１６】
　前記フレームワークは前記複数のノードに対して分配される、請求項１に記載の方法。
　　【請求項１７】
　前記複数のノードのうちの第１のノードにおいてアプリケーションを実行するステップをさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項１に記載の方法。
　　【請求項１８】
　前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記共通のサービスを提供しなくなることに応答して、前記方法はさらに前記アプリケーションの実行を終了させるステップを含む、請求項１７に記載の方法。
　　【請求項１９】
　前記複数のメンバーのうちの第１のメンバーから前記第１のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記方法はさらに、前記複数のノードのうちの第２のノードに常駐する前記複数のメンバーのうちの第２のメンバーから、前記第１のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するステップを含む、請求項１７に記載の方法。
　　【請求項２０】
　フレームワークから複数のコンポーネントを管理する方法であって、
　第１の複数のメンバーおよび第２の複数のメンバーを含む複合リソースを確立するステップを含み、前記第１および第２の複数のメンバーは、ネットワーク化されたシステムにある複数のノードに常駐し、前記第１の複数のメンバーの各々は共通のサービスを提供するよう活性であり、前記第２の複数のメンバーの各々は、活性化されると前記共通のサービスを提供することができ、前記方法はさらに、
　前記第１の複数のメンバーのうちのメンバーが、前記共通のサービスを要求する第１のコンポーネントに前記サービスを提供するよう前記フレームワークにより手配するステップを含み、前記第１の複数のメンバーのうちのいずれかのメンバーは、前記第１のコンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　前記第１の複数のメンバーにおけるメンバーのうちの１つ以上が非活性になることに応
答して、
　　前記第２の複数のメンバーのうちの第１のメンバーを活性化するステップ、
　　および、前記第１の複数のメンバーまたは前記第２の複数のメンバーのうちの一方にある活性な、前記第１のメンバーとは別の第２のメンバーを用いて前記共通のサービスを自動的に提供するステップ
を実行するステップとを含む、方法。
　　【請求項２１】
　前記複合リソースの状態は、前記複合リソース内の活性な各々のメンバーの状態から独立して維持され、指定された条件が満たされている限り前記複合リソースの状態が活性であり続ける、請求項２０に記載の方法。
　　【請求項２２】
　前記第１の複数のメンバーまたは前記第２の複数のメンバーのうちの１つにおける活性なメンバーを用いて前記共通のサービスを自動的に提供するステップは、前記複合リソースの共通のサービスを提供するよう活性であるメンバーの数を維持するステップを含む、請求項２０に記載の方法。
　　【請求項２３】
　前記第２の複数のメンバーのうちの多数のメンバーを活性化して前記共通のサービスを提供させることにより前記メンバーの数を増大させるステップをさらに含む、請求項２２に記載の方法。
　　【請求項２４】
　前記第１の複数のメンバーのうちのメンバーが前記共通のサービスを提供するよう手配するステップは、前記第１の複数のメンバーおよび前記第２の複数のメンバーにより共有される前記フレームワークのリソースを用いて行なわれる、請求項２０に記載の方法。
　　【請求項２５】
　前記フレームワークリソースを介し、前記第１の複数のメンバーおよび前記第２の複数のメンバーについての状態情報を維持するステップをさらに含む、請求項２４に記載の方法。
　　【請求項２６】
　前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項２４に記載の方法。
　　【請求項２７】
　前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項２４に記載の方法。
　　【請求項２８】
　フレームワークから複数のコンポーネントを管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、請求項１〜２７のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。」（以下、上記引用の請求項各項を、「補正後の請求項」という）に補正された。
　
２．補正の適否
　そこで、本件手続補正が、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える同法第１７条の２第３項の規定を満たすものであるか否か、即ち、本件手続補正が、特許法第１８４条の４第１項の規定による明細書、請求の範囲及び図面（図面の中の説明に限る）の翻訳文の記載の範囲内でなされたものであるか否かについて以下に検討する。
　
　補正後の請求項１に記載の内容は、補正前の請求項１の記載内容に、該補正前の請求項１の記載における「指定された条件」を説明する事項として、
「前記指定された条件は、前記複合リソースにおける活性なメンバーのユーザ指定の最小の数、または、前記複合リソースについてのユーザ指定の最小のサービスレベル、に対応し」、
　という記載（以下、これを「追加事項１」という）が附加されると共に、
　補正前の請求項１の記載内容の、
「・・・メンバーの少なくとも１つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新」（以下、「前段の記載事項」という）
　に引き続いて、
「前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
　前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
　活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない」
　との記載（以下、これを「追加事項２」という）が附加されたものであり、
　追加事項２は、前段の記載事項を前提とし、前段の記載事項における「指定された条件」とは、追加事項１を指すものである。
　
　以下、追加事項２が平成１６年７月１６日付けの明細書、請求の範囲及び図面（図面の中の説明に限る）の翻訳文（以下、「当初明細書等」という）に記載されていたかについて検討する。
　まず、追加事項２における、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」（以下、「追加事項２の前段」という）される点について検討する。
　
　当初明細書等には、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」されることは記載されていない。
　そこで、当初明細書等に記載の内容から、追加事項２の前段が読み取れるかについて更に検討する。
　この点について、当初明細書等には、その段落【００２８】に、
「これに代えて、ステップ１４０にて、サービスを提供していたメンバーが障害を起こした際に複合リソースの特定の濃度（cardinality）が満足されたかどうかについて判断することもある。１つの一般的な事例では、ノードクラスタにある１メンバーの濃度が「１」であると仮定されるが、実施例によってはより高い濃度が指定されることもある。たとえば濃度が「３」である場合があり、この場合、複合リソースが活きている（alive）と考えられるためには、この複合リソースのメンバー３つが活きていなければならない。」
　その段落【００３１】に、
「ステップ１４０にて、複合リソースを形成するメンバーでサービスを提供できるものが他にないと判断された場合、ステップ１６０にて、この複合リソースが提供するサービスは停止される。一実施例では、複合リソースが利用可能とされるのは、或る数の、または指定されたいくつかのメンバーが再始動できる場合のみである。」
　その段落【００５６】に、
「複合リソース２４０全体が障害を起こした場合、複合リソース２４０の回復を開始することができる。一実施例でこれは、サービスを提供するためになお活きているメンバーが他にない場合に対応する。別の実施例では、複合リソースについて最小濃度を指定し、そして活性なメンバーの数がこの濃度を満足させている限り複合リソースは動作していると見なされる。」
　その段落【００８４】に、
「ステップ４４０にて、複合リソース３４０のサービスレベルを、複合リソース３４０が非活性であることに対応する指定されたレベルと比較するための判断がなされる。一実施例では、この指定のレベルは管理者によって指定される。たとえばサービスレベルは特定ユーザの濃度に対応することがあり、この場合作動しているメンバーの数はこの濃度と等しいまたはこれを上回る必要がある。別の例として、サービスレベルは、複合リソース３４０により実行され得る最高のサービス品質の割合または比に対応することもある。」
　その段落【００８６】に、
「ステップ４４０にて複合リソース３４０が利用可能でないと判断された場合、複合リソース３４０はオフラインになる。そして、メンバーを再始動させて複合リソース３４０の再評価を引起こすことができる。このように複合リソース３４０は、存在するメンバーの機能として存在することになる。これに代えて、複合リソース３４０を拡張して、複合リソース３４０を利用可能にするであろう追加のサービスを提供することもできる。たとえば複合リソースの濃度を拡張させることがあり得る。たとえば複合リソースが１組の非活性なメンバーを確立し、これら非活性なメンバーを複合リソース３４０における活性なメンバーのための予備ノードとすることがあり得る。複合リソース３４０のサービスを拡張する場合、ＶＣ３５０のリソースは予備または非活性なメンバーから１つ以上のメンバーを活性化する。」
　との記載が存在し、上記引用の段落【００２８】、【００５６】、及び、【００８４】の記載から
　“複合リソースが活きている、即ち、活性であるためには、この複合リソースのメンバーが、所定の数、活性でなければならない”
　点が読み取れ、加えて、上記引用の段落【００３１】、及び、【００８６】の記載から、
“そうでなければ、複合リソースは非活性であると見なされ、該複合リソースはオフラインにされ、この複合リソースが提供するサービスが停止される”
　点は読み取れる。
　しかしながら、上記引用の当初明細書等の記載内容からは、
「複合リソースが活性でなくなった後に、複合リソースのあるメンバーから共通のサービスを継続して提供」する点、即ち、“複合リソースが非活性”になった時点で、「メンバー」が、提供していた「サービス」を継続して提供するか否かについてを読み取ることはできない。　
　また、当初明細書等の段落【００３７】に、
「このように、「実」複合リソース２４０はノードから独立しており、複合リソースが依存する特定のノードは任意に決定でき、変更可能である。ある特定の時刻にて、複合リソース２４０が常駐する所であると見なされたノードが障害を起こすと、この複合リソースは別のノードにおいて透明に再始動される。複合リソース２４０のメンバーはなお複合リソース２４０の外側で機能するよう動作可能であり、サービスには変更が生じない。複合リソース２４０は動作中のメンバーに基づいて再始動および再評価される。」
　との記載があり、該記載中に、「複合リソース２４０のメンバーはなお複合リソース２４０の外側で機能するよう動作可能であり、サービスには変更が生じない」とあるが、
　上記引用の段落【００３７】に記載されているのは、「複合リソース」を有している「ノード」自体が障害を起こした場合に、「複合リソース」を他の「ノード」上で「再始動」する点であり、この事例の場合、「ノード」の障害発生時点で、「複合リソース」に、追加事項１である「指定された条件」は満たされていると解するのが妥当であるから、補正後の請求項１における「複合リソース」を「非活性」とする事例には対応していない。
　そして、当初明細書等には、上記引用の段落【００３７】に記載の事項において、「複合リソース」を含む「ノード」が障害を起こした場合に、その時点で提供されている「サービス」をどのように扱うかについては何ら記載されていない。
　よって、上記に引用した当初明細書等の記載からは、追加事項２の前段、即ち、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」することを読み取ることはできない。
　
　次に、追加事項２における、
“活性ではない間、前記複合リソースは、継続して実行される”点（以下、「追加事項２の後段」という）について検討する。
　
　当初明細書等には、
「活性ではない間、前記複合リソースは、継続して実行される」との記載は存在しない。
　そこで、当初明細書等から、追加事項２の後段が読み取れるかを見ていくと、
　当初明細書等には、同段落【００８６】に、
「これに代えて、複合リソース３４０を拡張して・・・メンバーを活性化する」との記載があるが、
　当該記載内容は、同段落【００３１】の記載と併せると、「複合リソース」を「非活性」にしないために、「複合リソース」の機能を拡張するものと解するのが妥当であから、この記載をもって、“サービスを停止している複合リソースが継続している”ことを示すものとは認められない。
　仮に、同段落【００８６】の「これに代えて、・・」以降に記載の内容が、「複合リソース」が、「オフライン」にされた以降に関連するものであったとしても、
　上記引用の段落【００２８】に記載の、
「複合リソースが活きている（alive）と考えられる」から、「複合リソース」が「活性」であるとは、“活きている”状態を表現するものであり、
　また、同段落【００２７】に記載の、
「この複合リソースを形成する少なくとも１つの他のメンバーが活性または動作している」との記載内容とを勘案すると、当初明細書等に記載の内容においては、「複合リソース」が「非活性」とは、「複合リソース」が“停止”している状態を表現するものと解されるから、同段落【００８６】の前段の記載における「複合リソース」が、「オフライン」になったときに「非活性」な状態になっているのであれば、該「複合リソース」は、その時点で一旦、「停止」していることになるから、該「これに代えて・・・」以降の処理において、「非活性」な状態の「複合リソース」を「継続して実行」して行っているものでないことは自明であって、
　結果、上記引用の当初明細書等の記載内容からは、追加事項２の後段、即ち、
「活性でない間、複合リソースは、継続して実行される」点を読み取ることはできない。
　
　よって、当初明細書等には、補正後の明細書に記載された追加事項２、即ち、
「前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
　前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
　活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない」点は記載されておらず、
　また、当初明細書等の記載内容から当業者に自明の事項でもない。
　以上のとおりであるから、本件手続補正は、当初明細書等に記載の範囲内でなされたものでない。
　
３．補正却下むすび
　したがって、本件手続補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項により読み替える特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって、結論のとおり決定する。
　
　
その３．本願発明
　平成２１年６月２６日付けの手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明は、平成２１年１月２９日付けの手続補正により補正された、特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次の事項により特定されるものであると認める。（以下、これを「本願発明」という）
　
「フレームワークから複数のコンポーネントを管理する方法であって、
　ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
　フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
　前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
　前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
　　前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
　　前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
　前記メンバーの少なくとも１つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する、方法。」
　
その４．引用刊行物に記載の発明
　一方、原審が、平成２０年１０月２９日付けの拒絶理由に引用した、特開平０９−２１８８４２号公報（１９９７年８月１９日公開、以下、これを「引用刊行物１」という）には、関連する図面とともに次の事項が記載されている。
　
Ａ．「【００１９】図２は本発明のロードシェアシステムの概略構成を示すブロック図である。これは、通信制御装置が１台の場合の構成である。この図には１つのローカルエリアネットワーク（ＬＡＮ）４１と２つの通信媒体４４，４５が示されている。
ＬＡＮ４１には、複数のサーバ１０，２０，３０と通信制御装置１００とが接続されている
【００２０】
サーバ１０，２０，３０のそれぞれには、利用者に各種業務を提供するアプリケーション１１，２１，３１
【００２１】
通信制御装置１００は
内部にネットワーク連携装置１００ａを有している。ネットワーク連携装置１００ａは、振り分けプログラム１１０と記憶装置１２０とを有している。振り分けプログラム１１０は、状態管理エージェントから各サーバ１０，２０，３０の状態を収集し一括管理する状態管理部１１１、利用者からの要求をいずれかのサーバに振り分ける振り分け処理部１１２、及び要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部１１３から構成されている
　
Ｂ．「【００７５】次に第４の機能である業務の運用を切り換えることにより、サーバ間の効率的な負荷の分散を行う機能について説明する。この機能を実行するには、図２に示す振り分け処理部１１２に対して各種条件の定義を入力する。この定義では、各サーバのアプリケーションへの振り分け条件をグループ化する。このグループ化により、複数の振り分け条件をまとめて管理することができる。
【００７６】さらに、振り分け条件グループの定義に「振り分け状態」を持たせる。そして、
振り分け処理部１１２は、振り分け先の決定に使用する振り分け条件グループを「活性状態」に、振り分け先の決定に使用しない振り分け条件グループを「非活性状態」にすることにより業務の振り分けを管理する
【００７７】図２０は振り分け処理部１１２に入力する振り分け定義の例を示す図である。この例では、実資源の定義として、
サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」と名付けており、各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と名付けている
サーバ２０とサーバ３０とは同じ業務を提供
【００７８】振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（振り分け状態＝活性）」と「振り分け条件グループＡ２（振り分け状態＝非活性）」とに分かれている・・・・（中略）・・・・
【００８０】振り分け処理部１１２は、振り分け状態が活性である振り分け条件グループの定義を使用して振り分け先のサーバを決定する。
運用の切り換えは、活性状態の振り分け条件グループを非活性状態とし、新しい運用に使用すべき振り分け条件グループを活性状態とすることにより行う
　
Ｃ．「【００９６】図２５はアプリケーションの状態の定義を追加した振り分け定義を示す図である。この図では、実資源の定義として、サーバ１０，２０，３０をそれぞれ「サーバＸ」、「サーバＹ」、「サーバＺ」とし、
各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と定義している。さらに、各アプリケーション１１，２１，３１には振り分け状態が設定されており、図中では全て「活性」である
【００９７】ロードシェア形態の業務で特定のサーバのアプリケーションにトラブルが発生した場合、トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部１１１へアプリケーションに障害が発生した旨が通知される。
状態管理部１１１は、障害の発生したアプリケーションの状態を「非活性」とする
　
Ｄ．「【０１０２】図２７はホットスタンバイ切り換えを実現するための振り分け定義を示す図である。この例では、１つのデータベースを共有している
サーバ２０，３０のうち、サーバ２０を現用、サーバ３０を待機として運用している。実資源の定義として、サーバ２０，３０をそれぞれ「サーバＸ」、「サーバＹ」とし、各サーバ２０，３０内で業務を実行するアプリケーション２１，３１をともに「業務Ａ」と定義している
【０１０３】
振り分けの定義において、「業務Ａ」は、「振り分け条件グループＡ１（運用名＝運用α）」と「振り分け条件グループＡ２（運用名＝運用β）」とに分かれている
【０１０４】
現在、「運用α」が活性状態であり、「運用β」が非活性状態である
【０１０５】この状態において、
現用のサーバ２０にトラブルが発生すると
通信制御装置１００の状態管理部１１１がその通知を受け取ると、それに応じて、運用操作部１１３がサーバ２０の振り分け状態を非活性状態に変更する。続いて、サーバ３０の振り分け状態を活性状態に変更する。これにより、待機サーバであったサーバ３０が新たに現用サーバとなる
　
Ｅ．「【０１０７】サーバ間の相対振り分け比率とは、ロードシェア形態の各サーバ上のアプリケーション間の相対的な振り分け比率である。
アプリケーションに対する最大振り分け数とは、アプリケーションがそのサーバで同時に処理可能な要求数である
　
（あ）上記Ａから、引用刊行物１に記載の「ロードシェアシステム」は、「ＬＡＮ」で接続された「複数のサーバ１０，２０，３０」、「通信制御装置」、前記「通信制御装置」に接続された「通信媒体」を介した「他の複数のシステム５１，５２」、前記「他の複数のシステム」に接続された「端末６１，６２」、「端末６３，６４」から構成され、前記「サーバ１０，２０，３０」は、それぞれ、「利用者に各種業務を提供するアプリケーション１１，２１，３１」を有しており、前記「通信制御装置」は、「ネットワーク連携装置」を有し、前記「ネットワーク連携装置」は、「振り分けプログラム」を有し、前記「振り分けプログラム」は、「各サーバ１０，２０，３０の状態を収集し一括管理する状態管理部」、「利用者からの要求をいずれかのサーバに振り分ける振り分け処理部」、「要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部」から構成されていることが読み取れ、
　上記Ｄの、
「トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部１１１へアプリケーションに障害が発生した旨が通知される」から、
「状態管理部」が、「アプリケーション」の状態の管理も行っていることが読み取れる。
　
（い）上記Ｂの「各サーバ１０，２０，３０内で業務を実行するアプリケーション１１，２１，３１を、それぞれ「業務プログラムＡ（業務Ａ）」、「業務プログラムＢ（業務Ｂ）」、「業務プログラムＢ（業務Ｂ）」と名付けている。ここで、サーバ２０とサーバ３０とは同じ業務を提供」との記載から、「サーバ１０，２０，３０」内で業務を実行する「アプリケーション１１，２１，３１」を「業務Ａ」、「業務Ｂ」、「業務Ｂ」とし、同じ名称の「業務」は、「同一の業務を提供する」ものであることが記載され、このことから、同じ「業務」名を与えられた「アプリケーション」は、同一の「業務」を提供するものであり、
各「アプリケーション」は、「業務」名  によって“グループ化”されていることが読み取れる。
　
（う）上記Ｄから、「業務Ａ」、「業務Ｂ」である「アプリケーション」自体にも「振り分け状態」が、全て、「活性」として設定されている点が記載され、「活性」である、「アプリケーション」が障害を起こすと該「アプリケーション」の状態を「非活性」とし、「非活性」とされた該「アプリケーション」へは、該「アプリケーション」が提供する「業務」への「利用者からの要求」が、「振り分けられなくなる」ことが記載され、
　上記（い）の項目で指摘したように、上記Ｃから、「業務Ｂ」は、「サーバ２０」、「サーバ３０」上の「アプリケーション２１」、「アプリケーション３１」によって提供されるものであるから、「サーバ２０」、或いは、「アプリケーション２１」がダウンして、「サーバ２０」、或いは、「アプリケーション２１」への「利用者からの要求」の「振り分け状態」が「非活性」になったとしても、「業務Ｂ」自体の提供は可能である、即ち、「業務Ｂ」への「振り分け状態」は、「活性」であり、「業務Ｂ」の「振り分け状態」は、「業務Ｂ」が提供できる「アプリケーション」が存在するかに依存し、個々の「アプリケーション」、或いは、「サーバ」の状態に依存するものでないことは明らかである。
　
（え）上記Ｄ、及び、Ｅから、「サーバ２０」が有する「アプリケーション２１」と、「サーバ３０」が有する「アプリケーション３１」とは、同一の「業務Ａ」を提供し、「サーバ２０」が「現用系」であるとき、「業務Ａ」は、「サーバ２０」の「アプリケーション２１」に割り当てられ、「サーバ２０」がダウンすると、「通信制御装置」が有する「振り分けプログラム」が、「サーバ２０」への「振り分け状態」を「非活性状態」として、「待機系」であった「サーバ３０」への「振り分け状態」を「活性状態」とすることで、「サーバ３０」を「現用系」とし、「サーバ３０」の「業務Ａ」を提供する「アプリケーション３１」に、「業務Ａ」への要求を割り当てるようにしている点が読み取れる。
　
　以上（あ）〜（え）で検討した事項から、引用刊行物１には、次の発明（以下、「引用発明」という）が記載されているものと認める。
　
　振り分けプログラムから、クライアントからの要求を制御する方法であって、
ＬＡＮに接続された複数のサーバが有する複数のアプリケーションにより提供される業務を設定し、
　前記複数のアプリケーションは、同一の業務を提供することができ、前記業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ、前記方法はさらに、
　振り分けプログラムの状態管理部を用いて、各々のアプリケーションの状態を監視し、
　前記同一の業務を要求するクライアントが、通信制御装置が有する振り分けプログラムを介して、前記業務の要求をし、前記業務を、前記クライアントに提供し、
　前記提供は、
　前記同一の業務が、前記複数のアプリケーションにより、前記クライアントへ提供されるよう、前記通信制御装置が有する振り分けプログラムによって振り分けられ、前記アプリケーションのうち活性なものは、前記同一の業務を提供するために使用可能であり、さらに、
　前記同一の業務を提供していた前記アプリケーションが活性でなくなった場合に、前記同一の業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに同一の業務を提供するために使用可能であり、前記方法はさらに、
　業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である、
　方法。
　
その５．本願発明と引用発明との対比
　引用発明における「クライアント」は、「同一の業務」への処理要求を出すものであるから、
　本願発明における「コンポーネント」に相当し、
　引用発明における「振り分けプログラム」は、「クライアント」からの処理要求を、「アプリケーション」に割り当てるものであり、
　本願発明において、「コンポーネント」は、「サービスを提供される」ものであるから、
　引用発明において、「振り分けプログラムから、クライアントからの要求を制御する」ことは、
　本願発明において、「フレームワークから複数のコンポーネントを管理する」ことに相当し、
　引用発明における「業務」は、「同一の業務」を提供する「複数のアプリケーション」を“グループ化”したものと見なさせるから、
　本願発明における「複合リソース」に相当し、
　引用発明における「サーバ」、「アプリケーション」、及び、「同一の業務」は、それぞれ、
　本願発明における「ノード」、「メンバー」、及び、「共通のサービス」に相当し、
　引用発明における「業務」は、「複数のアプリケーション」、或いは、前記「複数のアプリケーション」を有する「サーバ」が「活性」である場合に、「活性状態」であって、これは即ち、“特定の条件が満たされている間は活性状態”であることに他ならないから、
　引用発明において、「業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ」ることは、
　本願発明において、「複合リソースは、指定された条件が満たされている限り活性であり続けるように構成され」ることに相当する。
　引用発明における「ＬＡＮで接続されたサーバ」は、
　本願発明における「ネットワーク化されたシステムおける複数のノード」に相当するので、
　引用発明において、「ＬＡＮに接続されたシステムにおける複数のサーバが有する複数のアプリケーションにより提供される業務を設定」ことは、
　本願発明において、「ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立する」ことに相当する。
　引用発明における「通信制御装置」が有する「振り分けプログラム」は、「複数のアプリケーション」のそれぞれの「状態」を「監視」する「状態管理部」と、「クライアント」から「同一の業務」への要求を受け付ける機能とを有しているので、
　本願発明における「フレームワークリソース」に相当することから、
　引用発明において、「振り分けプログラムの状態管理部を用いて、各々のアプリケーションの状態を監視」することは、
　本願発明において、「フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視」することに相当し、
　引用発明において、「同一の業務を要求するクライアントが、通信制御装置が有する振り分けプログラムを介して、前記業務の要求をし、前記業務を、前記クライアントに提供」することは、
　本願発明において、「共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
　前記サービスを前記コンポーネントに提供するステップ」に相当する。
　そして、上述したように、引用発明においては、「複数のアプリケーション」は、「業務」という“グループ”に含まれるものであるから、
　引用発明において、「同一の業務が、前記複数のアプリケーションにより、前記クライアントへ提供されるよう、前記通信制御装置が有する振り分けプログラムによって振り分けられ、前記アプリケーションのうち活性なものは、前記業務を提供するために使用可能であ」ることは、
　本願発明において、「サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であ」ることに相当する。
　引用発明において、「業務を提供していた前記アプリケーションが活性でなくなった場合に、前記業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに業務を提供するために使用可能であ」ることが、人手を介さずに行われていることは明らかであるから、
　引用発明における「業務を提供していた前記アプリケーションが活性でなくなった場合に、前記業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに業務を提供するために使用可能であ」ることは、
　本願発明における「サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であ」ることに相当する。
　そして、引用発明において、「業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である」であるとは、「業務」の「状態」が、該「業務」を提供する「複数のアプリケーション」、及び、前記「複数のアプリケーション」を有する「サーバ」の個々の状態に依存せずに維持されていることは明らかであるから、
　引用発明において、「業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である」ことは、
　本願発明において、「複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップ」に相当し、
　引用発明における、各処理段階を“ステップ”として表現することは普通のことであるから、
　本願発明と、引用発明との一致点、及び、相違点は次のとおりである。
　
［一致点］
フレームワークから複数のコンポーネントを管理する方法であって、
　ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
　フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
　前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
　前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
　　前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
　　前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
　複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含む、方法。
　
［相違点］
　本願発明においては、
「メンバーの少なくとも１つが活性であっても、指定された条件がもはや満たされていないと判断すると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する」ものであるが、
　引用発明においては、「業務振り分け状態」の状態を更新する条件として、「アプリケーション」、或いは、「サーバ」の「活性」、「不活性」以外の条件が示されおらず、そのような条件が満たされなくなったときに、「業務」を提供し得る「アプリケーション」、或いは、「サーバ」のうち、少なくとも１つが「活性」であっても、「業務振り分け状態」を「活性」でなくするようなことは示されていない点、
　
その６．当審の判断
　そこで、上記［相違点］について検討するに、
　例えば、本願の第１国出願前に既に公知である、特開２０００−２６８０１２号公報（２０００年９月２９日公開）の段落【００１３】に、
Ｆ．「
ＬＡＮトラフィック受付判定機能部213は、サーバ負荷情報重み付け機能部211によって定義された各要素毎の受付限界閾値、受付再開閾値と、サーバ負荷採取機能212により採取された負荷状況を定期的に比較し、ＬＡＮトラフィックの受付／再開、あるいは拒否を判定する
サーバ負荷情報重み付け設定機能部211で定義された受付限界閾値を越えたことが確認された場合、負荷状況通信機能部214は、負荷分散装置１に対してＬＡＮトラフィック受付中断のための負荷制御情報を送信
　また、同じく、本願の第１国出願前に既に公知である、特開平０７−２８８８００号公報（１９９５年１０月３１日公開）の【要約】に、
Ｇ．「【目的】  ネットワークを介して動画や音声などのマルチメディアデータのリアルタイム再生を行うマルチメディアシステムに関し、端末数の多い大規模なシステムを従来より低コストで構築できるようにする。
【構成】  サーバ内には、すべてのマルチメディアデータを格納するマルチメディアデータ記憶装置と、システムのアクセス状況を格納するアクセス状況記憶装置とを設ける。情報サービスを要求されたクライアントは、所望の
マルチメディアデータのリアルタイム再生に必要な転送能力を算出し、アクセス状況記憶装置を参照して得られる現在実行中の転送能力およびサーバの転送能力の上限値に基づいて必要な転送能力が得られないと判定された場合には、当該情報サービスを提供しない
　同じく、本願の第１国出願前にすでに公知である、特開２０００−３２２３６５号公報（２０００年１１月２４日公開）の段落【０００３】に、
Ｈ．「従来技術によれば、クライアントからの処理要求に対して処理プロセス数のみで受付制限するため、
クライアントからの処理要求によってかかる負荷が軽くサーバの処理能力に余裕がある状態でも処理プロセス数の上限に達すると新たなクライアントからの処理要求の受付を拒否する
　あるいは、同じく、本願の第１国出願前に既に公知である、特開平０８−０８７３４１号公報（１９９６年４月２日公開）の【請求項１】に、
Ｉ．「複数のＣＰＵを備え、自動縮退立ち上げ機能を有したコンピュータシステムにおいて、電源投入時に、前記複数のＣＰＵのいずれかに障害が発生していないかどうかを監視し、障害の発生しているＣＰＵを検出した場合に、その障害の発生しているＣＰＵを切り離すＣＰＵ監視制御手段と、
所定の業務を処理するために必要となるＣＰＵの最少数を予め記憶するＣＰＵ数記憶手段と、前記複数のＣＰＵのうちの正常なＣＰＵの数を、前記ＣＰＵ数記憶手段に記憶されたＣＰＵの最少数と比較する比較手段と、前記比較手段による比較の結果、前記正常なＣＰＵの数が前記ＣＰＵの最少数以上であるときに、システムの立ち上げを行わせ、前記正常なＣＰＵの数が前記ＣＰＵの最少数未満であるときに、システムの立ち上げを中止させる
　との記載があるように、“サーバ、或いは、ＣＰＵが動作している、或いは、動作可能であっても、即ち、サービスや業務を提供する主体が動作している、或いは、動作可能であっても、所定のサービスを提供する、或いは、所定の業務を実行するために必要な条件を満たしていない場合に、サービスの提供をしない、或いは、システムを立ち上げない状態にする”といったことは、本願の第１国出願時点で、当業者には周知の技術事項であり、引用発明においても、「業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ」ることから、引用発明において、「業務」を、「同一の業務」が提供する「アプリケーション」、或いは、「サーバ」が「活性」の間、「活性」とするようにすることに替えて、何れかの「サーバ」、或いは、「アプリケーション」が「活性」であっても、“所定の条件を満さない場合”に、該「業務」を、「非活性」とするような条件を設定することは、当業者が適宜なし得る事項である。
　よって、相違点は、格別のものでない。
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
その７．むすび
　以上のとおりであるから、本願発明は、引用発明、及び、周知技術に基づいて当業者が容易に発明することができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。