• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1250705
審判番号 不服2009-11712  
総通号数 147 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-03-30 
種別 拒絶査定不服の審決 
審判請求日 2009-06-26 
確定日 2012-01-18 
事件の表示 特願2003-550059「ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト」拒絶査定不服審判事件〔平成15年 6月12日国際公開、WO03/48934、平成17年 4月28日国内公表、特表2005-512190〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 その1.手続の経緯
本願は、2002年12月2日(パリ条約による優先権主張外国庁受理2001年11月30日、アメリカ合衆国)を国際出願日とする出願であって、
平成16年7月16日付けで特許法第184条の4第1項の規定による翻訳文が提出され、平成17年11月30日付けで審査請求がなされるとともに手続補正がなされ、平成20年6月26日付けで審査官により拒絶理由が通知され、これに対して、同年10月1日付けで意見書が提出されるとともに手続補正がなされ、同年10月29日付けで審査官により拒絶理由が通知され、これに対して、平成21年1月29日付けで意見書が提出されるとともに手続補正がなされたが、同年3月26日付けで審査官により拒絶査定がなされ、同年6月26日付けで審判請求がなされるとともに手続補正がなされ、同年8月17日付けで、特許法第164条第3項の規定により審査官による報告がなされ、平成22年11月30日付けで当審により特許法第134条第4項の規定に基づく審尋がなされ、平成23年3月23日付けで回答書の提出があったものである。


その2.補正却下

結論

平成21年 6月26日付け手続補正を却下する。

理由

1.補正の内容
平成21年6月26日付けの手続補正(以下、「本件手続補正」という)により、特許請求の範囲は、
「 【請求項1】
フレームワークから複数のコンポーネントを管理する方法であって、
ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
前記メンバーの少なくとも1つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する、方法。
【請求項2】
前記複数のメンバーは、1組の活性なメンバーおよび1組の非活性なメンバーを含み、前記1組の活性なメンバーのうちのメンバーは、前記1組の非活性なメンバーのうちのメンバーが用いる態様とは異なる態様で前記共通のサービスを提供する、請求項1に記載の方法。
【請求項3】
前記システムのユーザによって特定される構成情報に基づいてフレームワークリソースを介し前記複合リソースを構成するステップをさらに含む、請求項1に記載の方法。
【請求項4】
フレームワークリソースを用いて前記複合リソースを停止するステップをさらに含み、こうして前記複数のメンバーにおける各々のメンバーが停止される、請求項1に記載の方法。
【請求項5】
前記1組の非活性なメンバーのうちのメンバーを有するノードを選択するステップと、
前記複合リソースの前記1組の非活性なメンバーのうちのメンバーを有するノードから当該選択したノードに対して、前記複合リソースの一部としてのサービスを提供する責務を再割当てするステップとをさらに含む、請求項2に記載の方法。
【請求項6】
前記フレームワークリソースから前記複合リソースの性能特性を測定するステップをさらに含む、請求項1に記載の方法。
【請求項7】
管理者が前記フレームワークリソースを介し前記複合リソースにおいて1つ以上の動作を実行することを可能にするためのインターフェイスを設けるステップをさらに含む、請求項1に記載の方法。
【請求項8】
前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするステップをさらに含む、請求項1に記載の方法。
【請求項9】
前記複合リソースを確立するステップは、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある1組のリソースとともに利用されることを可能にするステップを含み、前記メンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項1に記載の方法。
【請求項10】
前記サービスを前記コンポーネントに提供するステップは、
前記サービスが前記複合リソースのうちの第1のメンバーにより前記第1のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
前記第1のメンバーが障害を起こしたときに、前記複数のメンバーのうちの第2のメンバーにより前記サービスが前記第2のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを含み、前記第2のメンバーのノードは前記第1のメンバーのノードとは異なり、
前記第1のメンバーの障害に先立ち、前記方法はさらに、前記第2のメンバーのノードにある1組のリソースを用いて前記第2のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第2のメンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記第2のメンバーにより必要とされる、請求項1に記載の方法。
【請求項11】
前記第1のメンバーが障害を起こしているが前記第1のメンバーのノードはまだ機能していることを検出するステップをさらに含み、前記サービスが第2のメンバーにより前記コンポーネントに提供されることを引起こすステップは、前記第1のメンバーのノードにある1つ以上の他のリソースが機能している間に行なわれる、請求項10に記載の方法。
【請求項12】
前記第1のメンバーが障害を起こしたことを検出した後に前記第1のメンバーを自動的に再始動するステップをさらに含む、請求項11に記載の方法。
【請求項13】
前記サービスが第2のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップは、前記第1のメンバーの回復を試みている間に実行される、請求項11に記載の方法。
【請求項14】
前記複合リソースを確立するステップは、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするステップを含む、請求項1に記載の方法。
【請求項15】
前記複合リソースは、前記フレームワークによって前記複数のノードにある特定のノードに少なくとも部分的に常駐するものとして見なされる、請求項1に記載の方法。
【請求項16】
前記フレームワークは前記複数のノードに対して分配される、請求項1に記載の方法。
【請求項17】
前記複数のノードのうちの第1のノードにおいてアプリケーションを実行するステップをさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項1に記載の方法。
【請求項18】
前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記共通のサービスを提供しなくなることに応答して、前記方法はさらに前記アプリケーションの実行を終了させるステップを含む、請求項17に記載の方法。
【請求項19】
前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記サービスを提供しなくなることに応答して、前記方法はさらに、前記複数のノードのうちの第2のノードに常駐する前記複数のメンバーのうちの第2のメンバーから、前記第1のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するステップを含む、請求項17に記載の方法。
【請求項20】
フレームワークから複数のコンポーネントを管理する方法であって、
第1の複数のメンバーおよび第2の複数のメンバーを含む複合リソースを確立するステップを含み、前記第1および第2の複数のメンバーは、ネットワーク化されたシステムにある複数のノードに常駐し、前記第1の複数のメンバーの各々は共通のサービスを提供するよう活性であり、前記第2の複数のメンバーの各々は、活性化されると前記共通のサービスを提供することができ、前記方法はさらに、
前記第1の複数のメンバーのうちのメンバーが、前記共通のサービスを要求する第1のコンポーネントに前記サービスを提供するよう前記フレームワークにより手配するステップを含み、前記第1の複数のメンバーのうちのいずれかのメンバーは、前記第1のコンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
前記第1の複数のメンバーにおけるメンバーのうちの1つ以上が非活性になることに応答して、
前記第2の複数のメンバーのうちのメンバーを活性化するステップ、
および、前記第1の複数のメンバーまたは前記第2の複数のメンバーのうちの一方にある活性なメンバーを用いて前記共通のサービスを自動的に提供するステップ
を実行するステップとを含む、方法。
【請求項21】
前記複合リソースの状態は、前記複合リソース内の活性な各々のメンバーの状態から独立して維持され、指定された条件が満たされている限り前記複合リソースの状態が活性であり続ける、請求項20に記載の方法。
【請求項22】
前記第1の複数のメンバーまたは前記第2の複数のメンバーのうちの1つにおける活性なメンバーを用いて前記共通のサービスを自動的に提供するステップは、前記複合リソースの共通のサービスを提供するよう活性であるメンバーの数を維持するステップを含む、請求項20に記載の方法。
【請求項23】
前記第2の複数のメンバーのうちの多数のメンバーを活性化して前記共通のサービスを提供させることにより前記メンバーの数を増大させるステップをさらに含む、請求項22に記載の方法。
【請求項24】
前記第1の複数のメンバーのうちのメンバーが前記共通のサービスを提供するよう手配するステップは、前記第1の複数のメンバーおよび前記第2の複数のメンバーにより共有される前記フレームワークのリソースを用いて行なわれる、請求項20に記載の方法。
【請求項25】
前記フレームワークリソースを介し、前記第1の複数のメンバーおよび前記第2の複数のメンバーについての状態情報を維持するステップをさらに含む、請求項24に記載の方法。
【請求項26】
フレームワークから複数のコンポーネントを管理するための1つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、1つ以上のプロセッサによる前記1つ以上の命令シーケンスの実行は、前記1つ以上のプロセッサに、請求項1から19のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。
【請求項27】
前記複数のメンバーは第1のメンバーおよび第2のメンバーを含み、前記第1のメンバーは、前記第2のメンバーが前記共通のサービスを提供するために用いる態様とは異なる態様で前記共通のサービスを提供する、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項28】
前記複数のメンバーにおける各々のメンバーが活性でなくなったときに前記複合リソースの回復を開始させるための命令をさらに含む、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項29】
前記システムのユーザによって特定される構成情報に基づいて前記調整部を介し前記複合リソースを構成するための命令をさらに含む、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項30】
前記調整部を用いて前記複合リソースを停止するための命令をさらに含み、こうして前記複数のメンバーにおける各々のメンバーは実質的に同一のサービスを提供することができなくなる、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項31】
前記1組の非活性なメンバーのうちのメンバーが常駐するノードから、前記1組の活性なメンバーのうちのメンバーが常駐するノードへ、前記複合リソースのソースを再配置するための命令をさらに含み、前記複合リソースのソースを再配置するステップを実行する直前に、前記活性な複数のメンバーのうちの少なくとも1つは、前記複合リソースのソースが再配置された以前に前記1組の非活性なメンバーのうちのメンバーであった、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項32】
前記調整部から前記複合リソースの性能特性を測定するための命令をさらに含む、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項33】
管理者が前記調整部を介し前記複合リソースにおいて1つ以上の動作を実行することを可能にするためのインターフェイスを設けるための命令をさらに含む、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項34】
前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするための命令をさらに含む、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項35】
前記複合リソースを確立するための命令は、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある1組のリソースとともに利用されることを可能にするための命令を含み、前記メンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項36】
前記サービスを前記コンポーネントに提供するための命令は、
前記サービスが前記複合リソース内の第1のメンバーにより前記第1のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
前記第1のメンバーが活性でなくなったときに、前記サービスが前記複数のメンバーにおける第2のメンバーにより前記第2のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを実行するための命令を含み、前記第2のメンバーのノードは前記第1のメンバーのノードとは異なり、
前記第1のメンバーが活性でなくなる前に、前記コンピュータ読取可能な記憶媒体はさらに、前記第2のメンバーのノードにある1組のリソースを用いて前記第2のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第2のメンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記第2のメンバーにより必要とされる、請求項26に記載のコンピュータ読取可能な記憶媒体。
【請求項37】
前記第1のメンバーが障害を起こしたが前記第1のメンバーのノードはまだ機能していることを検出するための命令をさらに含み、前記サービスが第2のメンバーにより前記コンポーネントに提供されることを引起こすための命令は、前記第1のメンバーのノードにある前記1つ以上の他のリソースが機能している間に実行される、請求項35に記載のコンピュータ読取可能な記憶媒体。
【請求項38】
前記サービスが第2のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップを実行するための命令は、前記第1のメンバーの回復を試みる間に前記ステップが実行されるための命令を含む、請求項37に記載のコンピュータ読取可能な記憶媒体。
【請求項39】
前記複合リソースを確立するための命令は、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするための命令を含む、請求項25に記載のコンピュータ読取可能な記憶媒体。
【請求項40】
前記複数のノードのうち1つにおいて前記調整部を実行するための命令をさらに含む、請求項25に記載のコンピュータ読取可能な記憶媒体。
【請求項41】
前記複数のノードの共有するフレームワークにおいて前記調整部を実行するための命令をさらに含む、請求項25に記載のコンピュータ読取可能な記憶媒体。
【請求項42】
前記複数のノードのうちの第1のノードにおいてアプリケーションを実行するステップを行なうための命令をさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項25に記載のコンピュータ読取可能な記憶媒体。
【請求項43】
前記共通のサービスを、前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに提供するための命令をさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記共通のサービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記アプリケーションの実行を終了させるための命令を含む、請求項42に記載のコンピュータ読取可能な記憶媒体。
【請求項44】
前記共通のサービスを、前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに提供するための命令をさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記サービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記複数のメンバーのうちの、前記複数のノードのうちの第2のノードに常駐する第2のメンバーから、前記第1のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するための命令を含む、請求項43に記載のコンピュータ読取可能な記憶媒体。
【請求項45】
フレームワークから複数のコンポーネントを管理するための1つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、1つ以上のプロセッサによる前記1つ以上の命令シーケンスの実行は、前記1つ以上のプロセッサに、請求項23から28のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。
【請求項46】
前記第1の複数のメンバーのうちの前記第1のメンバーが活性でなくなることから独立して前記第2のサービスを提供するための命令は、前記第1のメンバーが活性でなくなった後に連続的に前記第2のサービスを提供するための命令を含む、請求項45に記載のコンピュータ読取可能な記憶媒体。
【請求項47】
さらに、
前記第1のメンバーが第1の組の1つ以上のリソースを用いて前記第1のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第1の組の1つ以上のリソースは、前記第1のサービスを提供するために前記第1のメンバーにより必要とされ、前記第1の組のリソースは前記第1のノードに常駐し、前記コンピュータ読取可能な記憶媒体はさらに、
前記第2のメンバーが第2の組の1つ以上のリソースを用いて前記第2のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第2の組のリソースは、前記第2のサービスを提供するために前記第2のメンバーにより必要とされ、前記第2の組のリソースは前記第1のノードに常駐し、かつ、前記第1の組のリソースと重なる少なくとも1つのリソースを有する、請求項45に記載のコンピュータ読取可能な記憶媒体。
【請求項48】
前記第1のノードから前記第2のサービスを提供するための命令は、前記第1のメンバーが活性でなくなったことを検出した直後に前記第2のサービスを提供することにおいて、前記第2の組のリソースが前記第2のメンバーで利用されるように機能しているよう維持するための命令を含む、請求項47に記載のコンピュータ読取可能な記憶媒体。
【請求項49】
前記第1の複数のメンバーのうちの第1のメンバーが前記第1のサービスを提供するよう手配するための命令は、第1の調整部を用い前記第1のサービスを調整することで前記第1のメンバーを割当てて前記第1のサービスを前記第1のコンポーネントに提供するための命令を含む、請求項45に記載のコンピュータ読取可能な記憶媒体。
【請求項50】
前記第1の複数のメンバーのうちの第2のメンバーが前記第2のサービスを提供するよう手配するための命令は、第2の調整部を用い前記第2のサービスを調整することで前記第2のメンバーを割当てて前記第2のサービスを前記第2のコンポーネントに提供するための命令を含む、請求項49に記載のコンピュータ読取可能な記憶媒体。
【請求項51】
前記第1の調整部および前記第2の調整部を介し、前記第1の複数のメンバーおよび前記第2の複数のメンバーについての状態情報を維持するための命令をさらに含む、請求項50に記載のコンピュータ読取可能な記憶媒体。
【請求項52】
前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項1に記載の方法。
【請求項53】
前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項1に記載の方法。
【請求項54】
前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項24に記載の方法。
【請求項55】
前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項24に記載の方法。」(以下、上記引用の請求項各項を、「補正前の請求項」という)から、

「 【請求項1】
フレームワークから複数のコンポーネントを管理する方法であって、
ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記指定された条件は、前記複合リソースにおける活性なメンバーのユーザ指定の最小の数、または、前記複合リソースについてのユーザ指定の最小のサービスレベル、に対応し、前記方法はさらに、
フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
前記メンバーの少なくとも1つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新し、
前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない、方法。
【請求項2】
前記複数のメンバーは、1組の活性なメンバーおよび1組の非活性なメンバーを含み、前記1組の活性なメンバーのうちのメンバーは、前記1組の非活性なメンバーのうちのメンバーが用いる態様とは異なる態様で前記共通のサービスを提供する、請求項1に記載の方法。
【請求項3】
前記システムのユーザによって特定される構成情報に基づいてフレームワークリソースを介し前記複合リソースを構成するステップをさらに含む、請求項1に記載の方法。
【請求項4】
フレームワークリソースを用いて前記複合リソースを停止するステップをさらに含み、こうして前記複数のメンバーにおける各々のメンバーが停止される、請求項1に記載の方法。
【請求項5】
前記1組の非活性なメンバーのうちのメンバーを有するノードを選択するステップと、
前記複合リソースの前記1組の非活性なメンバーのうちのメンバーを有するノードから当該選択したノードに対して、前記複合リソースの一部としてのサービスを提供する責務を再割当てするステップとをさらに含む、請求項2に記載の方法。
【請求項6】
前記フレームワークリソースから前記複合リソースの性能特性を測定するステップをさらに含む、請求項1に記載の方法。
【請求項7】
管理者が前記フレームワークリソースを介し前記複合リソースにおいて1つ以上の動作を実行することを可能にするためのインターフェイスを設けるステップをさらに含む、請求項1に記載の方法。
【請求項8】
前記複数のメンバーのうちのどれが前記共通のサービスを提供しているかにかかわらず、前記コンポーネントが前記共通のサービスに依存することを可能にするステップをさらに含む、請求項1に記載の方法。
【請求項9】
前記複合リソースを確立するステップは、前記複合リソースの前記複数のメンバーの各々が前記メンバーのノードにある1組のリソースとともに利用されることを可能にするステップを含み、前記メンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記メンバーにより必要とされる、請求項1に記載の方法。
【請求項10】
前記サービスを前記コンポーネントに提供するステップは、
前記サービスが前記複合リソースのうちの第1のメンバーにより前記第1のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
前記第1のメンバーが障害を起こしたときに、前記複数のメンバーのうちの第2のメンバーにより前記サービスが前記第2のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを含み、前記第2のメンバーのノードは前記第1のメンバーのノードとは異なり、
前記第1のメンバーの障害に先立ち、前記方法はさらに、前記第2のメンバーのノードにある1組のリソースを用いて前記第2のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第2のメンバーのノードにある前記1組のリソースは、前記サービスを提供するために前記第2のメンバーにより必要とされる、請求項1に記載の方法。
【請求項11】
前記第1のメンバーが障害を起こしているが前記第1のメンバーのノードはまだ機能していることを検出するステップをさらに含み、前記サービスが第2のメンバーにより前記コンポーネントに提供されることを引起こすステップは、前記第1のメンバーのノードにある1つ以上の他のリソースが機能している間に行なわれる、請求項10に記載の方法。
【請求項12】
前記第1のメンバーが障害を起こしたことを検出した後に前記第1のメンバーを自動的に再始動するステップをさらに含む、請求項11に記載の方法。
【請求項13】
前記サービスが第2のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップは、前記第1のメンバーの回復を試みている間に実行される、請求項11に記載の方法。
【請求項14】
前記複合リソースを確立するステップは、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするステップを含む、請求項1に記載の方法。
【請求項15】
前記複合リソースは、前記フレームワークによって前記複数のノードにある特定のノードに少なくとも部分的に常駐するものとして見なされる、請求項1に記載の方法。
【請求項16】
前記フレームワークは前記複数のノードに対して分配される、請求項1に記載の方法。
【請求項17】
前記複数のノードのうちの第1のノードにおいてアプリケーションを実行するステップをさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項1に記載の方法。
【請求項18】
前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記共通のサービスを提供しなくなることに応答して、前記方法はさらに前記アプリケーションの実行を終了させるステップを含む、請求項17に記載の方法。
【請求項19】
前記複数のメンバーのうちの第1のメンバーから前記第1のノードで実行される前記アプリケーションに前記共通のサービスを提供するステップをさらに含み、前記第1のメンバーは前記第1のノードに常駐し、前記第1のメンバーが前記サービスを提供しなくなることに応答して、前記方法はさらに、前記複数のノードのうちの第2のノードに常駐する前記複数のメンバーのうちの第2のメンバーから、前記第1のノードにおいて実行される前記アプリケーションに前記共通のサービスを提供するステップを含む、請求項17に記載の方法。
【請求項20】
フレームワークから複数のコンポーネントを管理する方法であって、
第1の複数のメンバーおよび第2の複数のメンバーを含む複合リソースを確立するステップを含み、前記第1および第2の複数のメンバーは、ネットワーク化されたシステムにある複数のノードに常駐し、前記第1の複数のメンバーの各々は共通のサービスを提供するよう活性であり、前記第2の複数のメンバーの各々は、活性化されると前記共通のサービスを提供することができ、前記方法はさらに、
前記第1の複数のメンバーのうちのメンバーが、前記共通のサービスを要求する第1のコンポーネントに前記サービスを提供するよう前記フレームワークにより手配するステップを含み、前記第1の複数のメンバーのうちのいずれかのメンバーは、前記第1のコンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
前記第1の複数のメンバーにおけるメンバーのうちの1つ以上が非活性になることに応
答して、
前記第2の複数のメンバーのうちの第1のメンバーを活性化するステップ、
および、前記第1の複数のメンバーまたは前記第2の複数のメンバーのうちの一方にある活性な、前記第1のメンバーとは別の第2のメンバーを用いて前記共通のサービスを自動的に提供するステップ
を実行するステップとを含む、方法。
【請求項21】
前記複合リソースの状態は、前記複合リソース内の活性な各々のメンバーの状態から独立して維持され、指定された条件が満たされている限り前記複合リソースの状態が活性であり続ける、請求項20に記載の方法。
【請求項22】
前記第1の複数のメンバーまたは前記第2の複数のメンバーのうちの1つにおける活性なメンバーを用いて前記共通のサービスを自動的に提供するステップは、前記複合リソースの共通のサービスを提供するよう活性であるメンバーの数を維持するステップを含む、請求項20に記載の方法。
【請求項23】
前記第2の複数のメンバーのうちの多数のメンバーを活性化して前記共通のサービスを提供させることにより前記メンバーの数を増大させるステップをさらに含む、請求項22に記載の方法。
【請求項24】
前記第1の複数のメンバーのうちのメンバーが前記共通のサービスを提供するよう手配するステップは、前記第1の複数のメンバーおよび前記第2の複数のメンバーにより共有される前記フレームワークのリソースを用いて行なわれる、請求項20に記載の方法。
【請求項25】
前記フレームワークリソースを介し、前記第1の複数のメンバーおよび前記第2の複数のメンバーについての状態情報を維持するステップをさらに含む、請求項24に記載の方法。
【請求項26】
前記指定された条件は、前記複合リソースにおける活性なメンバーの、ユーザ指定の最小の数に対応する、請求項24に記載の方法。
【請求項27】
前記指定された条件は、前記複合リソースについてのユーザ指定の最小のサービスレベルに対応する、請求項24に記載の方法。
【請求項28】
フレームワークから複数のコンポーネントを管理するための1つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、1つ以上のプロセッサによる前記1つ以上の命令シーケンスの実行は、前記1つ以上のプロセッサに、請求項1?27のいずれかに記載のステップを実行させる、コンピュータ読取可能な記憶媒体。」(以下、上記引用の請求項各項を、「補正後の請求項」という)に補正された。

2.補正の適否
そこで、本件手続補正が、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項により読み替える同法第17条の2第3項の規定を満たすものであるか否か、即ち、本件手続補正が、特許法第184条の4第1項の規定による明細書、請求の範囲及び図面(図面の中の説明に限る)の翻訳文の記載の範囲内でなされたものであるか否かについて以下に検討する。

補正後の請求項1に記載の内容は、補正前の請求項1の記載内容に、該補正前の請求項1の記載における「指定された条件」を説明する事項として、
「前記指定された条件は、前記複合リソースにおける活性なメンバーのユーザ指定の最小の数、または、前記複合リソースについてのユーザ指定の最小のサービスレベル、に対応し」、
という記載(以下、これを「追加事項1」という)が附加されると共に、
補正前の請求項1の記載内容の、
「・・・メンバーの少なくとも1つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新」(以下、「前段の記載事項」という)
に引き続いて、
「前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない」
との記載(以下、これを「追加事項2」という)が附加されたものであり、
追加事項2は、前段の記載事項を前提とし、前段の記載事項における「指定された条件」とは、追加事項1を指すものである。

以下、追加事項2が平成16年7月16日付けの明細書、請求の範囲及び図面(図面の中の説明に限る)の翻訳文(以下、「当初明細書等」という)に記載されていたかについて検討する。
まず、追加事項2における、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」(以下、「追加事項2の前段」という)される点について検討する。

当初明細書等には、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」されることは記載されていない。
そこで、当初明細書等に記載の内容から、追加事項2の前段が読み取れるかについて更に検討する。
この点について、当初明細書等には、その段落【0028】に、
「これに代えて、ステップ140にて、サービスを提供していたメンバーが障害を起こした際に複合リソースの特定の濃度(cardinality)が満足されたかどうかについて判断することもある。1つの一般的な事例では、ノードクラスタにある1メンバーの濃度が「1」であると仮定されるが、実施例によってはより高い濃度が指定されることもある。たとえば濃度が「3」である場合があり、この場合、複合リソースが活きている(alive)と考えられるためには、この複合リソースのメンバー3つが活きていなければならない。」
その段落【0031】に、
「ステップ140にて、複合リソースを形成するメンバーでサービスを提供できるものが他にないと判断された場合、ステップ160にて、この複合リソースが提供するサービスは停止される。一実施例では、複合リソースが利用可能とされるのは、或る数の、または指定されたいくつかのメンバーが再始動できる場合のみである。」
その段落【0056】に、
「複合リソース240全体が障害を起こした場合、複合リソース240の回復を開始することができる。一実施例でこれは、サービスを提供するためになお活きているメンバーが他にない場合に対応する。別の実施例では、複合リソースについて最小濃度を指定し、そして活性なメンバーの数がこの濃度を満足させている限り複合リソースは動作していると見なされる。」
その段落【0084】に、
「ステップ440にて、複合リソース340のサービスレベルを、複合リソース340が非活性であることに対応する指定されたレベルと比較するための判断がなされる。一実施例では、この指定のレベルは管理者によって指定される。たとえばサービスレベルは特定ユーザの濃度に対応することがあり、この場合作動しているメンバーの数はこの濃度と等しいまたはこれを上回る必要がある。別の例として、サービスレベルは、複合リソース340により実行され得る最高のサービス品質の割合または比に対応することもある。」
その段落【0086】に、
「ステップ440にて複合リソース340が利用可能でないと判断された場合、複合リソース340はオフラインになる。そして、メンバーを再始動させて複合リソース340の再評価を引起こすことができる。このように複合リソース340は、存在するメンバーの機能として存在することになる。これに代えて、複合リソース340を拡張して、複合リソース340を利用可能にするであろう追加のサービスを提供することもできる。たとえば複合リソースの濃度を拡張させることがあり得る。たとえば複合リソースが1組の非活性なメンバーを確立し、これら非活性なメンバーを複合リソース340における活性なメンバーのための予備ノードとすることがあり得る。複合リソース340のサービスを拡張する場合、VC350のリソースは予備または非活性なメンバーから1つ以上のメンバーを活性化する。」
との記載が存在し、上記引用の段落【0028】、【0056】、及び、【0084】の記載から
“複合リソースが活きている、即ち、活性であるためには、この複合リソースのメンバーが、所定の数、活性でなければならない”
点が読み取れ、加えて、上記引用の段落【0031】、及び、【0086】の記載から、
“そうでなければ、複合リソースは非活性であると見なされ、該複合リソースはオフラインにされ、この複合リソースが提供するサービスが停止される”
点は読み取れる。
しかしながら、上記引用の当初明細書等の記載内容からは、
「複合リソースが活性でなくなった後に、複合リソースのあるメンバーから共通のサービスを継続して提供」する点、即ち、“複合リソースが非活性”になった時点で、「メンバー」が、提供していた「サービス」を継続して提供するか否かについてを読み取ることはできない。
また、当初明細書等の段落【0037】に、
「このように、「実」複合リソース240はノードから独立しており、複合リソースが依存する特定のノードは任意に決定でき、変更可能である。ある特定の時刻にて、複合リソース240が常駐する所であると見なされたノードが障害を起こすと、この複合リソースは別のノードにおいて透明に再始動される。複合リソース240のメンバーはなお複合リソース240の外側で機能するよう動作可能であり、サービスには変更が生じない。複合リソース240は動作中のメンバーに基づいて再始動および再評価される。」
との記載があり、該記載中に、「複合リソース240のメンバーはなお複合リソース240の外側で機能するよう動作可能であり、サービスには変更が生じない」とあるが、
上記引用の段落【0037】に記載されているのは、「複合リソース」を有している「ノード」自体が障害を起こした場合に、「複合リソース」を他の「ノード」上で「再始動」する点であり、この事例の場合、「ノード」の障害発生時点で、「複合リソース」に、追加事項1である「指定された条件」は満たされていると解するのが妥当であるから、補正後の請求項1における「複合リソース」を「非活性」とする事例には対応していない。
そして、当初明細書等には、上記引用の段落【0037】に記載の事項において、「複合リソース」を含む「ノード」が障害を起こした場合に、その時点で提供されている「サービス」をどのように扱うかについては何ら記載されていない。
よって、上記に引用した当初明細書等の記載からは、追加事項2の前段、即ち、
「複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供」することを読み取ることはできない。

次に、追加事項2における、
“活性ではない間、前記複合リソースは、継続して実行される”点(以下、「追加事項2の後段」という)について検討する。

当初明細書等には、
「活性ではない間、前記複合リソースは、継続して実行される」との記載は存在しない。
そこで、当初明細書等から、追加事項2の後段が読み取れるかを見ていくと、
当初明細書等には、同段落【0086】に、
「これに代えて、複合リソース340を拡張して・・・メンバーを活性化する」との記載があるが、
当該記載内容は、同段落【0031】の記載と併せると、「複合リソース」を「非活性」にしないために、「複合リソース」の機能を拡張するものと解するのが妥当であから、この記載をもって、“サービスを停止している複合リソースが継続している”ことを示すものとは認められない。
仮に、同段落【0086】の「これに代えて、・・」以降に記載の内容が、「複合リソース」が、「オフライン」にされた以降に関連するものであったとしても、
上記引用の段落【0028】に記載の、
「複合リソースが活きている(alive)と考えられる」から、「複合リソース」が「活性」であるとは、“活きている”状態を表現するものであり、
また、同段落【0027】に記載の、
「この複合リソースを形成する少なくとも1つの他のメンバーが活性または動作している」との記載内容とを勘案すると、当初明細書等に記載の内容においては、「複合リソース」が「非活性」とは、「複合リソース」が“停止”している状態を表現するものと解されるから、同段落【0086】の前段の記載における「複合リソース」が、「オフライン」になったときに「非活性」な状態になっているのであれば、該「複合リソース」は、その時点で一旦、「停止」していることになるから、該「これに代えて・・・」以降の処理において、「非活性」な状態の「複合リソース」を「継続して実行」して行っているものでないことは自明であって、
結果、上記引用の当初明細書等の記載内容からは、追加事項2の後段、即ち、
「活性でない間、複合リソースは、継続して実行される」点を読み取ることはできない。

よって、当初明細書等には、補正後の明細書に記載された追加事項2、即ち、
「前記複合リソースが活性でなくなった後に、前記複合リソースのあるメンバーから前記共通のサービスを継続して提供し、
前記指定された条件が満たされていないことの検出に応答して、前記複合リソースは活性でなくなり、
活性ではない間、前記複合リソースは、継続して実行されるが、もはや前記共通サービスに対する要求にはサービスを提供しない」点は記載されておらず、
また、当初明細書等の記載内容から当業者に自明の事項でもない。
以上のとおりであるから、本件手続補正は、当初明細書等に記載の範囲内でなされたものでない。

3.補正却下むすび
したがって、本件手続補正は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項により読み替える特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、結論のとおり決定する。


その3.本願発明
平成21年6月26日付けの手続補正は、上記のとおり却下されたので、本願の請求項1に係る発明は、平成21年1月29日付けの手続補正により補正された、特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項1に記載された次の事項により特定されるものであると認める。(以下、これを「本願発明」という)

「フレームワークから複数のコンポーネントを管理する方法であって、
ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含み、
前記メンバーの少なくとも1つが活性であっても、前記指定された条件がもはや満たされていないと判断されると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する、方法。」

その4.引用刊行物に記載の発明
一方、原審が、平成20年10月29日付けの拒絶理由に引用した、特開平09-218842号公報(1997年8月19日公開、以下、これを「引用刊行物1」という)には、関連する図面とともに次の事項が記載されている。

A.「【0019】図2は本発明のロードシェアシステムの概略構成を示すブロック図である。これは、通信制御装置が1台の場合の構成である。この図には1つのローカルエリアネットワーク(LAN)41と2つの通信媒体44,45が示されている。LAN41には、複数のサーバ10,20,30と通信制御装置100とが接続されている。サーバ10にはデータベース(DB)42が接続されている。サーバ20,30は、データベース43を共有している。通信媒体44には、通信制御装置100と他の複数のシステム51,52とが接続されている。各システム51,52には、端末61,62が接続されている。通信媒体45には、通信制御装置100と複数の端末63,64とが接続されている。
【0020】サーバ10,20,30のそれぞれには、利用者に各種業務を提供するアプリケーション11,21,31、自己の動作状態を示すデータが格納された状態管理テーブル12,22,32、及び通信制御装置100へ自己の動作状態を報告する状態管理エージェント13,23,33が設けられている。
【0021】通信制御装置100はLAN41と他の通信媒体44,45との情報通信を制御する装置であり、内部にネットワーク連携装置100aを有している。ネットワーク連携装置100aは、振り分けプログラム110と記憶装置120とを有している。振り分けプログラム110は、状態管理エージェントから各サーバ10,20,30の状態を収集し一括管理する状態管理部111、利用者からの要求をいずれかのサーバに振り分ける振り分け処理部112、及び要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部113から構成されている。また、記憶装置120内には各サーバの負荷状態を示す負荷分散情報121、各サーバに振り分けられた要求の情報を示す状態管理テーブル122、及び運用を切り換えるための複数の条件が格納された運用テーブル123が格納されている。」(下線は、説明の都合上当審にて附したものである。以下同じ。)

B.「【0075】次に第4の機能である業務の運用を切り換えることにより、サーバ間の効率的な負荷の分散を行う機能について説明する。この機能を実行するには、図2に示す振り分け処理部112に対して各種条件の定義を入力する。この定義では、各サーバのアプリケーションへの振り分け条件をグループ化する。このグループ化により、複数の振り分け条件をまとめて管理することができる。
【0076】さらに、振り分け条件グループの定義に「振り分け状態」を持たせる。そして、振り分け処理部112は、振り分け先の決定に使用する振り分け条件グループを「活性状態」に、振り分け先の決定に使用しない振り分け条件グループを「非活性状態」にすることにより業務の振り分けを管理する。このとき、各振り分け条件グループは業務の運用に対応している。
【0077】図20は振り分け処理部112に入力する振り分け定義の例を示す図である。この例では、実資源の定義として、サーバ10,20,30をそれぞれ「サーバX」、「サーバY」、「サーバZ」と名付けており、各サーバ10,20,30内で業務を実行するアプリケーション11,21,31を、それぞれ「業務プログラムA(業務A)」、「業務プログラムB(業務B)」、「業務プログラムB(業務B)」と名付けている。ここで、サーバ20とサーバ30とは同じ業務を提供しており、ロードシェア形態をとっている。
【0078】振り分けの定義において、「業務A」は、「振り分け条件グループA1(振り分け状態=活性)」と「振り分け条件グループA2(振り分け状態=非活性)」とに分かれている・・・・(中略)・・・・
【0080】振り分け処理部112は、振り分け状態が活性である振り分け条件グループの定義を使用して振り分け先のサーバを決定する。運用の切り換えは、活性状態の振り分け条件グループを非活性状態とし、新しい運用に使用すべき振り分け条件グループを活性状態とすることにより行う。」

C.「【0096】図25はアプリケーションの状態の定義を追加した振り分け定義を示す図である。この図では、実資源の定義として、サーバ10,20,30をそれぞれ「サーバX」、「サーバY」、「サーバZ」とし、各サーバ10,20,30内で業務を実行するアプリケーション11,21,31を、それぞれ「業務プログラムA(業務A)」、「業務プログラムB(業務B)」、「業務プログラムB(業務B)」と定義している。さらに、各アプリケーション11,21,31には振り分け状態が設定されており、図中では全て「活性」である。なお、振り分けの定義は、図22に示した例と同じである。
【0097】ロードシェア形態の業務で特定のサーバのアプリケーションにトラブルが発生した場合、トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部111へアプリケーションに障害が発生した旨が通知される。状態管理部111は、障害の発生したアプリケーションの状態を「非活性」とする。」

D.「【0102】図27はホットスタンバイ切り換えを実現するための振り分け定義を示す図である。この例では、1つのデータベースを共有しているサーバ20,30のうち、サーバ20を現用、サーバ30を待機として運用している。実資源の定義として、サーバ20,30をそれぞれ「サーバX」、「サーバY」とし、各サーバ20,30内で業務を実行するアプリケーション21,31をともに「業務A」と定義している。
【0103】振り分けの定義において、「業務A」は、「振り分け条件グループA1(運用名=運用α)」と「振り分け条件グループA2(運用名=運用β)」とに分かれている。「振り分け条件グループA1」の振り分け条件は「振り分け条件A1X(最大100)」と「振り分け条件A1Y(最大100)」とであり、「振り分け条件グループA2」の振り分け条件は「振り分け条件A2X(最大50)」と「振り分け条件A2Y(最大50)」とである。
【0104】現在、「運用α」が活性状態であり、「運用β」が非活性状態である。図28はホットスタンバイ切り換えの状況を示す図である。2つのサーバ20,30が共に正常に動作している状態(図中、上側)では、端末63,64やシステム51からの業務Aの要求142は、現用であるサーバ20への要求143として振り分けられている。この時、双方のサーバ20,30内の状態管理エージェント23,33は、定期的に通信を行う事により、互いに監視し合っている。従って、一方のサーバがダウンすると、他方のサーバ内の状態管理エージェントがそのことを検出する仕組みになっている。
【0105】この状態において、現用のサーバ20にトラブルが発生すると、サーバ20からの通信が滞ったことをサーバ30内の状態管理エージェント33が検出し、サーバ20がダウンしたことを認識する。すると、状態管理エージェント33は通信制御装置100の振り分けプログラム110(その中の状態管理部111)との間の通信パスを利用して、サーバ20がダウンした旨を通信制御装置に通知する。通信制御装置100の状態管理部111がその通知を受け取ると、それに応じて、運用操作部113がサーバ20の振り分け状態を非活性状態に変更する。続いて、サーバ30の振り分け状態を活性状態に変更する。これにより、待機サーバであったサーバ30が新たに現用サーバとなる。従って、振り分け状態変更後(図中、下側)では、利用者の端末63,64等から出力された要求が、全てサーバ30への要求144となる。」

E.「【0107】サーバ間の相対振り分け比率とは、ロードシェア形態の各サーバ上のアプリケーション間の相対的な振り分け比率である。アプリケーションに対する最大振り分け数とは、アプリケーションがそのサーバで同時に処理可能な要求数である。」

(あ)上記Aから、引用刊行物1に記載の「ロードシェアシステム」は、「LAN」で接続された「複数のサーバ10,20,30」、「通信制御装置」、前記「通信制御装置」に接続された「通信媒体」を介した「他の複数のシステム51,52」、前記「他の複数のシステム」に接続された「端末61,62」、「端末63,64」から構成され、前記「サーバ10,20,30」は、それぞれ、「利用者に各種業務を提供するアプリケーション11,21,31」を有しており、前記「通信制御装置」は、「ネットワーク連携装置」を有し、前記「ネットワーク連携装置」は、「振り分けプログラム」を有し、前記「振り分けプログラム」は、「各サーバ10,20,30の状態を収集し一括管理する状態管理部」、「利用者からの要求をいずれかのサーバに振り分ける振り分け処理部」、「要求を振り分けるための条件の活性化・非活性化の切り換えを行う運用操作部」から構成されていることが読み取れ、
上記Dの、
「トラブルが発生したサーバ内に配置された状態管理エージェントから状態管理部111へアプリケーションに障害が発生した旨が通知される」から、
「状態管理部」が、「アプリケーション」の状態の管理も行っていることが読み取れる。

(い)上記Bの「各サーバ10,20,30内で業務を実行するアプリケーション11,21,31を、それぞれ「業務プログラムA(業務A)」、「業務プログラムB(業務B)」、「業務プログラムB(業務B)」と名付けている。ここで、サーバ20とサーバ30とは同じ業務を提供」との記載から、「サーバ10,20,30」内で業務を実行する「アプリケーション11,21,31」を「業務A」、「業務B」、「業務B」とし、同じ名称の「業務」は、「同一の業務を提供する」ものであることが記載され、このことから、同じ「業務」名を与えられた「アプリケーション」は、同一の「業務」を提供するものであり、
各「アプリケーション」は、「業務」名 によって“グループ化”されていることが読み取れる。

(う)上記Dから、「業務A」、「業務B」である「アプリケーション」自体にも「振り分け状態」が、全て、「活性」として設定されている点が記載され、「活性」である、「アプリケーション」が障害を起こすと該「アプリケーション」の状態を「非活性」とし、「非活性」とされた該「アプリケーション」へは、該「アプリケーション」が提供する「業務」への「利用者からの要求」が、「振り分けられなくなる」ことが記載され、
上記(い)の項目で指摘したように、上記Cから、「業務B」は、「サーバ20」、「サーバ30」上の「アプリケーション21」、「アプリケーション31」によって提供されるものであるから、「サーバ20」、或いは、「アプリケーション21」がダウンして、「サーバ20」、或いは、「アプリケーション21」への「利用者からの要求」の「振り分け状態」が「非活性」になったとしても、「業務B」自体の提供は可能である、即ち、「業務B」への「振り分け状態」は、「活性」であり、「業務B」の「振り分け状態」は、「業務B」が提供できる「アプリケーション」が存在するかに依存し、個々の「アプリケーション」、或いは、「サーバ」の状態に依存するものでないことは明らかである。

(え)上記D、及び、Eから、「サーバ20」が有する「アプリケーション21」と、「サーバ30」が有する「アプリケーション31」とは、同一の「業務A」を提供し、「サーバ20」が「現用系」であるとき、「業務A」は、「サーバ20」の「アプリケーション21」に割り当てられ、「サーバ20」がダウンすると、「通信制御装置」が有する「振り分けプログラム」が、「サーバ20」への「振り分け状態」を「非活性状態」として、「待機系」であった「サーバ30」への「振り分け状態」を「活性状態」とすることで、「サーバ30」を「現用系」とし、「サーバ30」の「業務A」を提供する「アプリケーション31」に、「業務A」への要求を割り当てるようにしている点が読み取れる。

以上(あ)?(え)で検討した事項から、引用刊行物1には、次の発明(以下、「引用発明」という)が記載されているものと認める。

振り分けプログラムから、クライアントからの要求を制御する方法であって、
LANに接続された複数のサーバが有する複数のアプリケーションにより提供される業務を設定し、
前記複数のアプリケーションは、同一の業務を提供することができ、前記業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ、前記方法はさらに、
振り分けプログラムの状態管理部を用いて、各々のアプリケーションの状態を監視し、
前記同一の業務を要求するクライアントが、通信制御装置が有する振り分けプログラムを介して、前記業務の要求をし、前記業務を、前記クライアントに提供し、
前記提供は、
前記同一の業務が、前記複数のアプリケーションにより、前記クライアントへ提供されるよう、前記通信制御装置が有する振り分けプログラムによって振り分けられ、前記アプリケーションのうち活性なものは、前記同一の業務を提供するために使用可能であり、さらに、
前記同一の業務を提供していた前記アプリケーションが活性でなくなった場合に、前記同一の業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに同一の業務を提供するために使用可能であり、前記方法はさらに、
業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である、
方法。

その5.本願発明と引用発明との対比
引用発明における「クライアント」は、「同一の業務」への処理要求を出すものであるから、
本願発明における「コンポーネント」に相当し、
引用発明における「振り分けプログラム」は、「クライアント」からの処理要求を、「アプリケーション」に割り当てるものであり、
本願発明において、「コンポーネント」は、「サービスを提供される」ものであるから、
引用発明において、「振り分けプログラムから、クライアントからの要求を制御する」ことは、
本願発明において、「フレームワークから複数のコンポーネントを管理する」ことに相当し、
引用発明における「業務」は、「同一の業務」を提供する「複数のアプリケーション」を“グループ化”したものと見なさせるから、
本願発明における「複合リソース」に相当し、
引用発明における「サーバ」、「アプリケーション」、及び、「同一の業務」は、それぞれ、
本願発明における「ノード」、「メンバー」、及び、「共通のサービス」に相当し、
引用発明における「業務」は、「複数のアプリケーション」、或いは、前記「複数のアプリケーション」を有する「サーバ」が「活性」である場合に、「活性状態」であって、これは即ち、“特定の条件が満たされている間は活性状態”であることに他ならないから、
引用発明において、「業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ」ることは、
本願発明において、「複合リソースは、指定された条件が満たされている限り活性であり続けるように構成され」ることに相当する。
引用発明における「LANで接続されたサーバ」は、
本願発明における「ネットワーク化されたシステムおける複数のノード」に相当するので、
引用発明において、「LANに接続されたシステムにおける複数のサーバが有する複数のアプリケーションにより提供される業務を設定」ことは、
本願発明において、「ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立する」ことに相当する。
引用発明における「通信制御装置」が有する「振り分けプログラム」は、「複数のアプリケーション」のそれぞれの「状態」を「監視」する「状態管理部」と、「クライアント」から「同一の業務」への要求を受け付ける機能とを有しているので、
本願発明における「フレームワークリソース」に相当することから、
引用発明において、「振り分けプログラムの状態管理部を用いて、各々のアプリケーションの状態を監視」することは、
本願発明において、「フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視」することに相当し、
引用発明において、「同一の業務を要求するクライアントが、通信制御装置が有する振り分けプログラムを介して、前記業務の要求をし、前記業務を、前記クライアントに提供」することは、
本願発明において、「共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
前記サービスを前記コンポーネントに提供するステップ」に相当する。
そして、上述したように、引用発明においては、「複数のアプリケーション」は、「業務」という“グループ”に含まれるものであるから、
引用発明において、「同一の業務が、前記複数のアプリケーションにより、前記クライアントへ提供されるよう、前記通信制御装置が有する振り分けプログラムによって振り分けられ、前記アプリケーションのうち活性なものは、前記業務を提供するために使用可能であ」ることは、
本願発明において、「サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であ」ることに相当する。
引用発明において、「業務を提供していた前記アプリケーションが活性でなくなった場合に、前記業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに業務を提供するために使用可能であ」ることが、人手を介さずに行われていることは明らかであるから、
引用発明における「業務を提供していた前記アプリケーションが活性でなくなった場合に、前記業務が、前記複数のアプリケーションのうちの別のアプリケーションによって、前記クライアントに提供され、いずれかの活性なアプリケーションは、前記クライアントに業務を提供するために使用可能であ」ることは、
本願発明における「サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であ」ることに相当する。
そして、引用発明において、「業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である」であるとは、「業務」の「状態」が、該「業務」を提供する「複数のアプリケーション」、及び、前記「複数のアプリケーション」を有する「サーバ」の個々の状態に依存せずに維持されていることは明らかであるから、
引用発明において、「業務が、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバの個々の状態に依存せず、前記複数のアプリケーション、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性である」ことは、
本願発明において、「複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップ」に相当し、
引用発明における、各処理段階を“ステップ”として表現することは普通のことであるから、
本願発明と、引用発明との一致点、及び、相違点は次のとおりである。

[一致点]
フレームワークから複数のコンポーネントを管理する方法であって、
ネットワーク化されたシステムにおける複数のノードに常駐する複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーのうちの各々のメンバーは共通のサービスを提供することができ、前記複合リソースは、指定された条件が満たされている限り活性であり続けるように構成されており、前記方法はさらに、
フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
前記共通のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
前記サービスが前記複合リソース内のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、前記複合リソースのいずれかの活性なメンバーは前記コンポーネントに前記サービスを提供するために利用可能であり、さらに、
前記サービスを提供するように手配された前記メンバーが活性でなくなったときに、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを自動的に引起こすことによって行なわれ、いずれかの活性なメンバーは、前記コンポーネントに前記サービスを提供するために利用可能であり、前記方法はさらに、
複合リソースの状態が、前記指定された条件が満たされている限り活性であり続けるように、前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含む、方法。

[相違点]
本願発明においては、
「メンバーの少なくとも1つが活性であっても、指定された条件がもはや満たされていないと判断すると、前記複合リソースがもはや活性でないことを示すように、前記複合リソースの状態を更新する」ものであるが、
引用発明においては、「業務振り分け状態」の状態を更新する条件として、「アプリケーション」、或いは、「サーバ」の「活性」、「不活性」以外の条件が示されおらず、そのような条件が満たされなくなったときに、「業務」を提供し得る「アプリケーション」、或いは、「サーバ」のうち、少なくとも1つが「活性」であっても、「業務振り分け状態」を「活性」でなくするようなことは示されていない点、

その6.当審の判断
そこで、上記[相違点]について検討するに、
例えば、本願の第1国出願前に既に公知である、特開2000-268012号公報(2000年9月29日公開)の段落【0013】に、
F.「LANトラフィック受付判定機能部213は、サーバ負荷情報重み付け機能部211によって定義された各要素毎の受付限界閾値、受付再開閾値と、サーバ負荷採取機能212により採取された負荷状況を定期的に比較し、LANトラフィックの受付/再開、あるいは拒否を判定する(ステップS64)。LANトラフィック受付判定機能部213により、サーバ負荷情報重み付け設定機能部211で定義された受付限界閾値を越えたことが確認された場合、負荷状況通信機能部214は、負荷分散装置1に対してLANトラフィック受付中断のための負荷制御情報を送信し(ステップS65)、また、受付再開閾値に負荷が下がった場合、LANトラフィックの受付再開のための負荷制御情報を送信する(ステップS66)。定義された閾値の範疇にある場合は該当サーバでのLANトラフィックの受け入れを許容する」との記載、
また、同じく、本願の第1国出願前に既に公知である、特開平07-288800号公報(1995年10月31日公開)の【要約】に、
G.「【目的】 ネットワークを介して動画や音声などのマルチメディアデータのリアルタイム再生を行うマルチメディアシステムに関し、端末数の多い大規模なシステムを従来より低コストで構築できるようにする。
【構成】 サーバ内には、すべてのマルチメディアデータを格納するマルチメディアデータ記憶装置と、システムのアクセス状況を格納するアクセス状況記憶装置とを設ける。情報サービスを要求されたクライアントは、所望のマルチメディアデータのリアルタイム再生に必要な転送能力を算出し、アクセス状況記憶装置を参照して得られる現在実行中の転送能力およびサーバの転送能力の上限値に基づいて必要な転送能力が得られないと判定された場合には、当該情報サービスを提供しない。これにより、システムの低コスト化を図るとともに動作の安定性を保証することができる。」との記載、
同じく、本願の第1国出願前にすでに公知である、特開2000-322365号公報(2000年11月24日公開)の段落【0003】に、
H.「従来技術によれば、クライアントからの処理要求に対して処理プロセス数のみで受付制限するため、クライアントからの処理要求によってかかる負荷が軽くサーバの処理能力に余裕がある状態でも処理プロセス数の上限に達すると新たなクライアントからの処理要求の受付を拒否することになる。」との記載、
あるいは、同じく、本願の第1国出願前に既に公知である、特開平08-087341号公報(1996年4月2日公開)の【請求項1】に、
I.「複数のCPUを備え、自動縮退立ち上げ機能を有したコンピュータシステムにおいて、電源投入時に、前記複数のCPUのいずれかに障害が発生していないかどうかを監視し、障害の発生しているCPUを検出した場合に、その障害の発生しているCPUを切り離すCPU監視制御手段と、所定の業務を処理するために必要となるCPUの最少数を予め記憶するCPU数記憶手段と、前記複数のCPUのうちの正常なCPUの数を、前記CPU数記憶手段に記憶されたCPUの最少数と比較する比較手段と、前記比較手段による比較の結果、前記正常なCPUの数が前記CPUの最少数以上であるときに、システムの立ち上げを行わせ、前記正常なCPUの数が前記CPUの最少数未満であるときに、システムの立ち上げを中止させる立ち上げ制御手段と、を有することを特徴とする自動縮退立ち上げ機能を有したコンピュータシステム」
との記載があるように、“サーバ、或いは、CPUが動作している、或いは、動作可能であっても、即ち、サービスや業務を提供する主体が動作している、或いは、動作可能であっても、所定のサービスを提供する、或いは、所定の業務を実行するために必要な条件を満たしていない場合に、サービスの提供をしない、或いは、システムを立ち上げない状態にする”といったことは、本願の第1国出願時点で、当業者には周知の技術事項であり、引用発明においても、「業務は、前記複数のアプリケーションのいずれか、或いは、前記複数のアプリケーションを有する複数のサーバのいずれかが活性である間は活性であるようにすることができ」ることから、引用発明において、「業務」を、「同一の業務」が提供する「アプリケーション」、或いは、「サーバ」が「活性」の間、「活性」とするようにすることに替えて、何れかの「サーバ」、或いは、「アプリケーション」が「活性」であっても、“所定の条件を満さない場合”に、該「業務」を、「非活性」とするような条件を設定することは、当業者が適宜なし得る事項である。
よって、相違点は、格別のものでない。
そして、本願発明の構成によってもたらされる効果も、引用例記載の発明から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。

その7.むすび
以上のとおりであるから、本願発明は、引用発明、及び、周知技術に基づいて当業者が容易に発明することができたものであるので、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2011-08-15 
結審通知日 2011-08-23 
審決日 2011-09-05 
出願番号 特願2003-550059(P2003-550059)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 塚田 肇鳥居 稔鈴木 修治  
特許庁審判長 赤川 誠一
特許庁審判官 清木 泰
石井 茂和
発明の名称 ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト  
代理人 深見 久郎  
代理人 仲村 義平  
代理人 堀井 豊  
代理人 野田 久登  
代理人 酒井 將行  
代理人 森田 俊雄  
  • この表をプリントする

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