【事件の表示】
　特願２００２−　６７３５８「ホストマシンからサービスの健全性を抽出する方法」拒絶査定不服審判事件〔平成１４年１１月２９日出願公開、特開２００２−３４２１２８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１４年３月１２日（パリ条約による優先権主張２００１年５月３日、米国）の出願であって、平成１６年１２月１７日付けで手続補正がなされ、平成１９年１１月６日付けで拒絶理由通知がなされ、平成２０年５月９日付けで意見書が提出されるとともに手続補正がなされたが、同年１１月２０日付けで拒絶査定がなされ、これに対し、平成２１年３月６日付けで拒絶査定に対する審判請求がなされるとともに手続補正がなされ、同年６月２６日付けで特許法第１６４条第３項の規定による報告がなされ、平成２２年１０月２０日付けで当審より審尋がなされ、平成２３年１月１３日付けで前記審尋に対する回答書が提出されたものである。
　
　
第２．平成２１年３月６日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２１年３月６日付けの手続補正を却下する。
　
［理由］
１．本件補正
　平成２１年３月６日付けの手続補正（以下、「本件補正」という）は、平成２０年５月９日付けの手続補正により補正された明細書の特許請求の範囲の記載、
「【請求項１】
　ホストマシンに常駐するサービスの健全性を動的に判断するための方法であって、
　健全性生成器が、サービスからサービス性能情報を収集し、
　前記健全性生成器が、記憶装置に格納された規則のセットに含まれる健全性生成アルゴリズムを使用して、収集されたサービス性能情報を汎用的な出力に変換し、
　該汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納する方法。
　【請求項２】
　ホストマシンが、１または複数のコンポーネントを備え、
　前記健全性生成器が、当該１または複数のコンポーネントの内の１または複数から外部性能情報を収集し、
　前記健全性生成器が、収集された外部性能情報を変換し、
　前記健全性生成器が、汎用的な出力を提供するように、変換された外部性能情報および変換されたサービス性能情報を組み合わせることをさらに含む請求項１に記載の方法。
　【請求項３】
　上記収集することが、サービスによって提供されるサービス性能情報を読み出すことおよびサービスにおいてトランザクションが起こるたびに収集したデータからサービス性能情報を導出することの内の１つを含む請求項１に記載の方法。
　【請求項４】
　上記導出することが、サービス性能情報を読み出すラッパプログラムを使用することおよび性能情報を読み出すプローブプログラムを使用することの内の少なくとも１つを備え、収集されたサービス性能情報が複数の性能計量または性能計量に対する入力を含み、汎用的な出力が複数のサービス健全性計量を含み、変換することが、当該複数のサービス健全性計量の内の１または複数を提供するように、当該複数の性能計量の内の１または複数を組み合わせることを含む請求項３に記載の方法。
　【請求項５】
　複数のサービス健全性計量が、使用可能度、容量、スループット、サービス時間、待ち行列長さ、利用度、サービスレベル違反およびユーザ満足度を含む請求項４に記載の方法。
　【請求項６】
　ホストマシンに常駐するサービスの健全性を判断する装置であって、
　サービス健全性情報を収集するデータ収集エンジンと、
　健全性生成アルゴリズムを含む規則のセットを格納する記憶装置と、
　収集されたサービス健全性情報を、前記健全性生成アルゴリズムを使用して変換し、１または複数の汎用的な健全性計量を提供する変換エンジンと、
　該１または複数の汎用的な健全性計量を格納する共有記憶モジュールと、
　該共有記憶モジュールに接続され、複数の性能監視ツールが、該１または複数の汎用的な健全性計量を読むことができるように、該１または複数の汎用的な健全性計量にインタフェースを提供するインタフェース・ライブラリと、を備える装置。
　【請求項７】
　ホストマシンが１または複数の外部コンポーネントを備え、前記データ収集エンジンは、当該１または複数の外部コンポーネントのうちの１または複数から外部性能情報を収集し、前記変換エンジンは、１または複数の汎用的な健全性計量を提供するように、前記健全性生成アルゴリズムを使用して、収集された外部性能情報を変換する請求項６に記載の装置。
　【請求項８】
　前記データ収集エンジンは、サービスから性能情報を読み出すデータクエリーモジュールと、サービスにおいてトランザクションが起こるたびに収集したデータから性能情報を導出するデータ導出モジュールとを備える請求項６に記載の装置。
　【請求項９】
　前記データ導出モジュールは、ラッパプログラム、ベンチマークプログラムおよびプローブプログラムの内の１または複数から性能情報を導出する請求項８に記載の装置。
　【請求項１０】
　前記健全性生成アルゴリズムは、１または複数の性能情報パラメータを評価する評価方式と、１または複数の性能情報パラメータを組み合わせる要約方式と、サービス健全性計量に対して、収集された健全性情報を平均する平均方式とを含む請求項６に記載の装置。」
を、
　
「【請求項１】
　ホストマシンに常駐するサービスの健全性を動的に判断するための方法であって、
　健全性生成器が、サービスからサービス性能情報を収集し、
　前記健全性生成器が、記憶装置に格納された規則のセットに含まれる健全性生成アルゴリズムを使用して、収集されたサービス性能情報を汎用的な出力に変換し、
　該汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納する方法であって
　該汎用的な出力は、サービスの現在の作業性能に関係し、該汎用的な出力は、該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであり、健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく、該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む、方法。
　【請求項２】
　ホストマシンが、１または複数のコンポーネントを備え、
　前記健全性生成器が、当該１または複数のコンポーネントの内の１または複数から外部性能情報を収集し、
　前記健全性生成器が、収集された外部性能情報を変換し、
　前記健全性生成器が、汎用的な出力を提供するように、変換された外部性能情報および変換されたサービス性能情報を組み合わせることをさらに含む請求項１に記載の方法。
　【請求項３】
　上記収集することが、サービスによって提供されるサービス性能情報を読み出すことおよびサービスにおいてトランザクションが起こるたびに収集したデータからサービス性能情報を導出することの内の１つを含む請求項１に記載の方法。
　【請求項４】
　上記導出することが、サービス性能情報を読み出すラッパプログラムを使用することおよび性能情報を読み出すプローブプログラムを使用することの内の少なくとも１つを備え、収集されたサービス性能情報が複数の性能計量または性能計量に対する入力を含み、汎用的な出力が複数のサービス健全性計量を含み、変換することが、当該複数のサービス健全性計量の内の１または複数を提供するように、当該複数の性能計量の内の１または複数を組み合わせることを含む請求項３に記載の方法。
　【請求項５】
　複数のサービス健全性計量が、使用可能度、容量、スループット、サービス時間、待ち行列長さ、利用度、サービスレベル違反およびユーザ満足度を含む請求項４に記載の方法。
　【請求項６】
　ホストマシンに常駐するサービスの健全性を判断する装置であって、
　サービス健全性情報を収集するデータ収集エンジンと、
　健全性生成アルゴリズムを含む規則のセットを格納する記憶装置と、
　収集されたサービス健全性情報を、前記健全性生成アルゴリズムを使用して変換し、１または複数の汎用的な健全性計量であって、該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであり、健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく、該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む、該１または複数の汎用的な健全性計量を提供する変換エンジンと、
　該１または複数の汎用的な健全性計量を格納する共有記憶モジュールと、
　該共有記憶モジュールに接続され、複数の性能監視ツールが、該１または複数の汎用的な健全性計量を読むことができるように、該１または複数の汎用的な健全性計量にインタフェースを提供するインタフェース・ライブラリと、を備える装置。
　【請求項７】
　ホストマシンが１または複数の外部コンポーネントを備え、前記データ収集エンジンは、当該１または複数の外部コンポーネントのうちの１または複数から外部性能情報を収集し、前記変換エンジンは、１または複数の汎用的な健全性計量を提供するように、前記健全性生成アルゴリズムを使用して、収集された外部性能情報を変換する請求項６に記載の装置。
　【請求項８】
　前記データ収集エンジンは、サービスから性能情報を読み出すデータクエリーモジュールと、サービスにおいてトランザクションが起こるたびに収集したデータから性能情報を導出するデータ導出モジュールとを備える請求項６に記載の装置。
　【請求項９】
　前記データ導出モジュールは、ラッパプログラム、ベンチマークプログラムおよびプローブプログラムの内の１または複数から性能情報を導出する請求項８に記載の装置。
　【請求項１０】
　前記健全性生成アルゴリズムは、１または複数の性能情報パラメータを評価する評価方式と、１または複数の性能情報パラメータを組み合わせる要約方式と、サービス健全性計量に対して、収集された健全性情報を平均する平均方式とを含む請求項６に記載の装置。」に、
補正するものである。
　
　
２．補正の適否
　以下、請求項１についてする本件補正が、特許法第１７条の２の規定を満足しているかについて検討する。
　
（１）新規事項の有無、補正の目的要件
　請求項１についてする本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第１７条の２第３項の規定に適合する。
　
　請求項１についてする本件補正は、本件補正前の請求項１に、
「該汎用的な出力は、サービスの現在の作業性能に関係し、該汎用的な出力は、該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであり、健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく、該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む」
との発明特定事項を追加するものである。
　そして、前記発明特定事項が追加されたことにより、本件補正前の請求項１における「汎用的な出力」は、さらに、
「サービスの現在の作業性能に関係」すること、
「該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであ」ること、そして、
「健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく」、「該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む」こと、
が限定されることとなった。
　
　したがって、請求項１についてする本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮（請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）を目的とするものである。
　
（２）独立特許要件
　以上のとおり、請求項１についてする本件補正は、特許法１７条の２第４項第２号の特許請求の範囲の減縮を目的とすることから、次に、本件補正後の請求項１に係る発明（以下、「補正後の発明」という。）が特許出願の際独立して特許を受けることができるものであるかについて、検討する。
　
（２−１）引用発明
　原査定の拒絶の理由に引用され、本願の優先権主張の日前に頒布された刊行物である、
　堀内浩規、他４名、“ネットワーク管理のための管理情報ベース（ＭＩＢ）に対する柔軟なビュー提供方式”、情報処理学会論文誌、社団法人情報処理学会、１９９８年０２月１５日、第３９巻、第２号、ｐｐ．３６７〜３７８（以下、「引用文献」という。）
には、図面とともに次の事項が記載されている。（下線は、参考のために当審で付したものである。）
　
Ａ．「１．はじめに
　電気通信管理網（ＴＭＮ）１）の標準化が進捗し，これに基づくネットワークの管理が普及しつつある．ＴＭＮでは，ネットワーク管理のための５レイヤ〔上位から順に，ビジネス管理，サービス管理，ネットワーク（ＮＷ）管理，
ネットワーク要素（ＮＥ）
　
ＴＭＮの管理対象であるＮＥ装置は，管理オブジェクト（ＭＯ）の集合である管理情報ベース（ＭＩＢ）として表現される．ＭＩＢの定義は，同種のＮＥ装置でもベンダごとに異なる場合があり，ＮＷ管理レイヤでＮＥ装置にまたがる統合的な管理を行うためには，これらのＭＩＢを均質（ＭＩＢの定義が同一）に見せる必要がある．この場合には，ＮＥ装置のＭＩＢの定義を揃えるため，実際のＭＩＢの定義とは異なった見え方を与えるビューが必要となる．
　
Ｂ．「２．ＭＩＢの概要とＭＩＢにおけるビュー提供の必要性
　２．１　ＭＩＢの概要
　ＴＭＮにおけるＮＥ装置等の管理対象は，管理オブジェクト（ＭＯ）の集合であるＭＩＢとして表現される．同じ性質を持つＭＯの種類のことをＭＯクラスと呼び，ＭＯクラスに属するＭＯの実体のことをＭＯインスタンスと呼ぶ．ＭＩＢに含まれるＭＯクラスは，属性型，許される管理操作，振舞い，ならびに，ＭＯクラス間の包含関係を示す名前結合等がＧＤＭＯ(Guidelines for the Definition of Managed Objects)と呼ばれる記法を用いて定義される（以下，このようなＭＩＢの定義をＭＩＢ定義と呼ぶ）．
　ＭＩＢでは，ＭＯインスタンスの集合を名前木と呼ばれる木構造として保持し，各ＭＯインスタンスは識別名により一意に識別される．また，
ＭＩＢに対する管理操作には，属性値の取得（M-Get）と設定（M-Set），ＭＯインスタンスの生成（M-Create）と削除（M-Delete），動作（M-Action），ならびに，取得操作の取消し（M-CancelGet）とＭＩＢから発行する通知（M-EventReport）がある
　
Ｃ．「２．２　ＭＩＢにおけるビュー提供の必要性
　
図１に，ビューの元となる既存のＭＩＢ（以下，オリジナルのＭＩＢと呼ぶ）に対する異なった見え方，すなわちビューを提供する概念を示す．たとえば，ビューのＭＩＢの“ＭＯ
１
”は，オリジナルのＭＩＢの“ＭＯ
ａ
”と“ＭＯ
ｂ
”を加工したものであることを示す．
ビュー提供の実現形態には，
マネージャとエージェントの間に外付けの装置（プロキシー）として実現する形態
（１）同種ＮＥ装置を均質に見せるビューの提供
管理するネットワークが大きくなるに従い，マルチベンダのＮＥ装置が導入される．この際，同種のＮＥ装置であってもベンダや標準によってＭＩＢ定義が異なる場合がある．たとえば，ＡＴＭ交換機では，ＡＴＭ Forum標準のＭＩＢ定義９）とベンダ独自のＭＩＢ定義１０）とを比較すると，使用ＶＰ（Virtual Path）の総数等のように，標準のＭＩＢ定義における１つの属性型が，ベンダのＭＩＢ定義における複数の属性型で表現されたり，チャネル識別子のように，それぞれのＭＩＢ定義で属性型の名前やシンタックスが同じでも，意味が異なる場合がある．また，ＡＴＭ ForumやＩＴＵ勧告１１）といった標準のＭＩＢ定義間でも，ＭＯクラスや，それに割り当てられるオブジェクト識別子（ＯＩＤ）等が異なる．
このため，ＮＷ管理レイヤでＮＥ装置にまたがる統合的な管理を行うためには，これらのＭＩＢが均質化された，すなわち，各ＮＥ装置のＭＩＢ定義が同一なものとして扱えるビューを提供する必要がある
（２）上位レイヤの管理目的に応じたビューの提供
ＮＷ管理レイヤやサービス管理レイヤ等の上位レイヤにおける性能や障害等の管理で扱うＭＩＢ定義は，一般に，ＮＥ装置のＭＩＢ定義とは異なり，管理目的に応じてＭＩＢの集約や加工を行ったビューを提供する必要がある．
使用パラメータ制御（ＵＰＣ）を違反した廃棄セル等の性能情報が定義されている．
　以上，（１），（２）で示したように，ネットワーク管理システムの構築では，既存のＭＩＢに対して異なる見せ方を与える様々なビューの提供が必要となる．」（第３６８頁右欄第１行〜第３６９頁左欄第１９行）
　
Ｄ．「３．柔軟なビュー提供方式の提案
　２章で述べた様々なビューを提供するために，ビューごとに個別にプログラムを開発するのは効率的でない．そこで，オリジナルのＭＩＢに対し，様々なビューを提供するプログラムを効率的に開発可能とするビュー提供方式を以下に提案する．ここでは，オリジナルのＭＩＢ定義およびビューのＭＩＢ定義は，いずれもＧＤＭＯ１２）で定義されたものとする．
　３．１　基本原理
　ビュー提供方式としては，▲１▼
オリジナルのＭＩＢの情報に対して，あらかじめ集約・加工の処理を行ってビューのＭＩＢの情報として保持し，ビューのＭＩＢに対する管理操作は保持した情報に対して実行する
［(注)上記記載において、「▲１▼」及び「▲２▼」は、原文では丸付き数字として標記されている。］
　
Ｅ．「３．２　ビュー提供方式の概要
　オリジナルのＭＩＢ定義に対し，様々なビューを提供するプログラムを効率的に開発可能とするため，以下を行う．
（１）対応関係記法の導入
　　　
オリジナルのＭＩＢ定義とビューのＭＩＢ定義間の対応関係を記述する方法（以下，対応関係記法と呼ぶ）を新たに規定，導入する（詳細は４章参照）．
（２）対応関係の記述からのプログラム自動生成
　　　
ビューを提供するプログラム（以下，ビュー提供プログラムと呼ぶ）を，上記（１）を用いて記述した対応関係を利用して自動生成させる
　
Ｆ．「３．３　ビュー提供プログラムの機能
　以下では，ビュー提供プログラムを生成するのに必要となる対応関係記法の要求条件を明確にするため，まず，ビュー提供プログラの機能を抽出する．
（１）管理操作受信時に集約・加工を行う機能
（ａ）静的な情報の対応付け機能
　……（中略）……
（ｂ）動的な情報の対応付け機能
　……（中略）……
（２）周期的に集約・加工を行う機能
ビューのＭＩＢに対する管理操作の受信に関係なく，指定した周期でオリジナルのＭＩＢの属性値を取得し，その属性値を集約・加工してビューのＭＩＢの情報として保持する
　
Ｇ．「４．対応関係記法
　４．１　要求条件の明確化
　３．３節のビュー提供プログラムの機能を記述するための対応関係記法の要求条件を以下に示す．
［条件１］
ＭＯクラスと属性型ごとの記述
ＭＯインスタンスとそれに包含される属性値の個数は一般に膨大であり，ＭＯインスタンスごとに対応関係を記述するのは現実的でない．このため，本記法ではＭＯクラスと属性型ごとでビューとオリジナルのＭＩＢの対応を記述する．ビューとオリジナルのＭＩＢのＭＯインスタンスごとの対応は，別の処理により識別名対応情報（５章参照）として求める．
［条件２］
管理操作と通知の種類ごとの記述
ＭＯクラスごとの記述中では，３．３節（１）管理操作受信時に集約・加工を行う機能を記述するため，M-Get操作とM-Set操作はＭＯクラスが包含する属性型ごと，M-Action操作はＭＯクラスに定義される動作の種類ごと，M-Create操作とM-Delete操作はＭＯクラスごと，M-EventReport通知はＭＯクラスに定義される通知の種類ごとに記述する．
［条件３］
静的な情報の対応付けの記述
３．３節（１）（ａ）の機能を記述可能とするため，条件２で示した記述中で，ＭＯクラス名と属性型名を使用し，属性型名を被演算子とする算術演算の記法を導入して対応付ける．
［条件４］
動的な情報の対応付けの記述
３．３節（１）（ｂ）の機能を記述するため，条件３に加え，ビューとオリジナルのＭＩＢに対する管理操作発行やビューのＭＩＢからの通知発行を記述可能とする．この際，ビューのＭＩＢに対する管理操作やオリジナルのＭＩＢからの通知に含まれるパラメータから管理操作の対象となるビューのＭＯインスタンスの識別名や設定する値等を抽出する処理を記述可能とする．
［条件５］
周期的に起動される処理の記述
３．３節（２）の機能を記述するため，周期的にオリジナルのＭＩＢの属性値を取得する処理を記述可能とする．
［条件６］
ＡＳＮ．１データ型の記述
条件３〜５の算術演算において，属性のシンタックスを扱えるようにするため，任意のＡＳＮ．１データ型に対する変数の宣言，値の代入ならびに参照を可能とする．
［条件７］
永続変数の記述
条件４のビューのＭＩＢへのM-Set操作等の処理結果や，
条件５の周期的に取得した属性値をビューのＭＩＢの情報として保持するため，永続的に保存する変数（以下，永続変数と呼ぶ）を宣言可能とする
　
Ｈ．「４．４　対応関係記法を用いた記述例
　
対応関係記法による記述例として，ベンダ独自のＭＩＢ定義（オリジナルのＭＩＢ）を持つFore社製ＡＴＭ交換機に，標準のＭ４インタフェースのＭＩＢ定義に従うビューを提供させるための構成情報，性能情報，通知の対応関係記述を以下に示す
（１）構成情報の対応付け（静的な情報の対応付け例）
　……（中略）……
（２）
性能情報の対応付け（あらかじめ集約・加工を行う例）
図５にビューのＭＩＢのＭＯクラス“cellLevelProtocolCurrentData”の属性型“discardedCellsInvalidHeader”の対応付けの一部を示す．この属性型は，１つのポートにおける不正なヘッダのため廃棄したセル数の１５分ごとの積算値を示す．オリジナルのＭＩＢでは，不正ヘッダによる廃棄セル数は，交換機起動時からの積算値を表し，また，送受別々に積算している．このため，
オリジナルのＭＩＢの６つの属性値から送受の廃棄セルの積算値を取得し（６行目から８行目），前の１５分ごとの性能データからの差分を計算してビューの属性値を得る（９行目）．１５分ごとの性能データは，永続変数として保持し（１３行目），Timer規則により１５分ごと（１１行目）に，１７行目から２１行目の処理により更新する
（３）通知の対応付け（動的な振舞いの例）
図６にビューのＭＩＢのＭＯクラス“tcAdaptorTTPBidirectional”から発行する通知の規則の一部を示す．９行目から１０行目のNotification規則では，オリジナルのＭＩＢからの通知“InternetAlarm”に対して，ビューのＭＩＢの通知“communicationsAlarm”を発行し，その際の手続きは“Internet”であることを示す．通知“InternetAlarm”のパラメータ“probableCause”が条件に合致すれば（１５行目），通知“communicationsAlarm”のパラメータを設定し（１７，１８行目），通知を発行する（１４行目）．この際，ビューのＭＩＢの属性型“m3100alarmStatus”のAttribute規則（３行目から８行目）で定義された永続変数（４行目）に値を設定して（１９行目），障害状態の保持を行う．」（第３７２頁右欄第１２行〜第３７４頁左欄第１６行）
　
J.「５．ビュー提供プログラムの自動生成
ビュー提供プログラム生成コンパイラは，様々なビューを柔軟に提供するため，図７に示すように，▲１▼オリジナルのＭＩＢ定義，▲２▼ビューのＭＩＢ定義および，▲３▼これらの定義間の対応関係を４章の記法に従って記述した対応関係記述を入力とし，Ｃ言語のビュー提供プログラムを生成する．また，識別名対応情報ジェネレータは，上記▲１▼〜▲３▼に加え，▲４▼オリジナルのＭＩＢの名前木と▲５▼ビューのＭＩＢ独自の識別名に用いる属性（以下，名前属性と呼ぶ）の値からビュー提供プログラムが利用する識別名対応情報（５．２節参照）を生成する．
　５．１　コンパイラが生成するビュー提供プログラム
　
ビュー提供プログラムは図８に示すように，（１）制御モジュール，（２）変換処理モジュール，（３）インスタンス管理モジュール，（４）タイマモジュールから構成する
（１）制御モジュール
ビューのＭＩＢに対する管理操作およびオリジナルのＭＩＢからの管理操作応答や通知はすべてこの制御モジュールが受信する．
（２）変換処理モジュール
変換処理モジュールは，対応関係記述に従った管理操作の変換の処理を行う．
（３）インスタンス管理モジュール
　……（中略）……
（４）タイマモジュール
対応関係記述で指定されたタイマのタイムアウトを制御モジュールへ知らせる．タイマは，変換処理モジュールが周期的にオリジナルのＭＩＢの属性値を取得し，ビューのＭＩＢの属性として提供する等のために使用する．」（第３７４頁の左欄第１７行〜第３７５頁右欄第１０行）
［(注)上記記載において、「▲１▼」〜「▲５▼」は、原文では丸付き数字として標記されている。］
　
Ｋ．「６．評価と考察
　提案方式の有効性を実証するため，ビュー提供プログラム生成コンパイラおよび識別名対応情報ジェネレータを実装し，ビュー提供プログラムを生成させた．
生成プログラムは，2.2節で述べた３つの実現形態（マネージャ，プロキシー，エージェント）のうち，今回プロキシーの形態に対応するプログラムとした．
　６．１　ビュー提供プログラムの処理時間
　
ベンダ独自のＭＩＢ
１０）
を持つFore社製ＡＴＭ交換機をオリジナルのＭＩＢとし，標準のＭ４インタフェース
９）
のビューとして提供するビュー提供プログラムを対応関係記述から自動生成した．マネージャから，プロキシーを介してＡＴＭ交換機に管理操作を発行したときの処理時間を計測した．マネージャ，プロキシーならびにエージェントはＬＡＮ（Ethernet）で接続した．
　６．２　ビュー提供プログラムの開発効率
　……（中略）……
　６．３　対応関係記法の記述能力
 
Fore社製ＡＴＭ交換機のＭＩＢに対してＭ４インタフェースのビューを提供する
　……（中略）……
　６．４　ビュー提供方式の複数段適用
　提案方式を複数段繰返し適用することにより，管理目的に合った様々なビューを効率的に提供できる．
　たとえば，サービス管理レイヤのビューを提供する場合には，まず，ＮＥ装置のＭＩＢに対してＮＷ管理レイヤのビューを提供し，そのビューをさらに加工してサービス管理レイヤのビューを提供するといった提案方式の２段の適用で実現できる．
　また，同種のＮＥ装置でもベンダの違いにより互いにＭＩＢ定義が異なるＮＥ装置を統合して，ビューを提供する場合，提案方式の１段の適用でも実現できるが，オリジナルとビューのＭＩＢのＭＯクラスや識別名による選択文等の制御文が多重な入れ子構造になり対応関係記述が複雑化し，可読性や保守性の点から好ましくない．このような場合には，まずＭＩＢ定義が同じＮＥ装置ごと（ベンダごと）に提案方式を適用して均質なビューを提供した後，さらにこれらのビューを加工して統合したビューを提供するという２段の適用により容易に実現できる．」（第３７５頁右欄第２２行〜第３７７頁右欄第７行）
　
Ｌ．「７．おわりに
　本論文では，既存のＭＩＢに対し，様々なビューを提供するプログラムを効率的に開発可能とするビュー提供方式を提案した．提案方式では，既存のＭＩＢと提供するビューとの対応関係を記述する対応関係記法を新たに導入し，それを用いた対応関係記述からビュー提供のプログラムを自動生成させることを特徴とする．対応関係記法は，（１）管理操作受信時に集約・加工を行う静的な情報の対応付け機能，（２）動的な情報の対応付け機能や，（３）周期的に集約・加工を行う機能を記述可能とする．
　
提案方式を実装し，ＡＴＭ交換機のビュー提供に適用し
　今後，ネットワークの高度な運用・管理を可能とするため，ＴＭＮのネットワーク管理レイヤやサービス管理レイヤ，ならびに，顧客網管理（ＣＮＭ）の実装が進むことが予想される．
管理目的に応じて既存のＮＥ装置のＭＩＢを集約・加工した新たなビューを提供可能とする提案方式は，これらの実装に有効な方式である
　
Ｍ．ビュー提供プログラムの構成を図式化した図８から、ビュー提供プログラムは、ビューのＭＩＢ“ＭＯ１”に対する「ビューのＭＩＢへの管理操作」をＡＰＩを介して受け付けること、前記ビュー提供プログラムが、「ビューのＭＩＢからの管理操作応答や通知」を前記ＡＰＩを介して送信すること、が見て取れる。
　また、試験構成と観測点を図示する図９からは、マネージャとビュー提供プログラム、前記ビュー提供プログラムと複数のＴＭＮエージェントが、それぞれ、通信を行うことが見て取れる。そして、前記マネージャと前記ビュー提供プログラムとの間及び前記ビュー提供プログラムと前記複数のＴＭＮエージェントとの間には、それぞれ、ビュー及びオリジナルが介在すること、が見て取れる。そして、前記図９の注には、「（１），（３），（５）および（７）はそれぞれマネージャとビュー提供プログラム間またはビュー変換プログラムとエージェント間の通信時間」であること、「（２）と（６）はともにビュー提供プログラムの処理時間」であることが記載されている。
　
Ｎ．「ビュー提供プログラムの処理時間」をまとめた表５には、測定項目が「（ａ）属性型vpCTPIdの値取得」の処理時間は「１０５．５（２３６．６）」msecであること、測定項目が「（ｂ）属性型maxNumActiveVCCsAllowedの値取得」の処理時間は「８２９．８（１３０８．７）」msecであること、測定項目が「（ｃ）属性型cellScramblingEnabledの値取得」の処理時間は「１５６．３（２９０．２）」msecであること、「測定項目が「（ｄ）属性型m3100alarmStatusの値取得」の処理時間が「８３．４（１２４．４）」msecであることが、それぞれ記載されている。
　そして、同表の「（注１）」には、「数値は図９の（２）と（６）の和．括弧内の数値は（１）から（７）までのすべての和」であることが記載されている。
　
　
ａ．Ａの「電気通信管理網（ＴＭＮ）」では「ネットワーク管理のための５レイヤ〔上位から順に，ビジネス管理，サービス管理，ネットワーク（ＮＷ）管理，ネットワーク要素（ＮＥ）管理，ＮＥ装置と呼ぶ〕からなる機能モデルを定義している．ＴＭＮの実現のための課題は，これまで，ＮＥ装置やＮＥ管理レイヤを中心に論じられてきたが，次第に，上位のＮＷ管理レイヤやサービス管理レイヤの実現へと移りつつある．」及び「ＴＭＮの管理対象であるＮＥ装置は，管理オブジェクト（ＭＯ）の集合である管理情報ベース（ＭＩＢ）として表現される．」から、電気通信管理網（ＴＭＮ）によるネットワーク管理方法の管理対象はＮＥ装置であること、前記ＮＥ装置は管理情報ベース（ＭＩＢ）として表現されること、が記載されている。
　Ｃの「このため，ＮＷ管理レイヤでＮＥ装置にまたがる統合的な管理を行うためには，これらのＭＩＢが均質化された，すなわち，各ＮＥ装置のＭＩＢ定義が同一なものとして扱えるビューを提供する必要がある」における「ＮＥ装置にまたがる統合的な管理」及び「各ＮＥ装置のＭＩＢ定義」の記載から、引用文献におけるネットワークは、複数のＮＥ装置を有するものである。
　
　ところで、ネットワーク技術においては、「ＭＩＢビューはアクセスできるエージェントの管理情報（つまり、ＭＩＢオブジェクト）の部分集合を指定する[村井純監訳、“インターネットシステムハンドブック”、初版、株式会社インプレス発行、１９９６年８月１１日、第５３１頁第２０〜２２行]」ものを云う。一方、Ａには「ＭＩＢの定義は，同種のＮＥ装置でもベンダごとに異なる場合があり，ＮＷ管理レイヤでＮＥ装置にまたがる統合的な管理を行うためには，これらのＭＩＢを均質（ＭＩＢの定義が同一）に見せる必要がある．この場合には，ＮＥ装置のＭＩＢの定義を揃えるため，実際のＭＩＢの定義とは異なった見え方を与えるビューが必要となる．ビューは，ＮＷ管理レイヤ等の上位のレイヤにおける，管理目的に応じた下位のレイヤのＭＩＢを集約・加工する際にも必要となる．」と記載されている。
　さて、Ｃには、「図１に，ビューの元となる既存のＭＩＢ（以下，オリジナルのＭＩＢと呼ぶ）に対する異なった見え方，すなわちビューを提供する概念を示す．たとえば，ビューのＭＩＢの“ＭＯ１”は，オリジナルのＭＩＢの“ＭＯａ”と“ＭＯｂ”を加工したものであることを示す．」と記載されている。
　してみれば、引用文献において、「ビューのＭＩＢ」とは、アクセスできるＭＩＢオブジェクトの部分集合を指定するＭＩＢのそれぞれを云うとともに、ＭＩＢの定義が同一であるかのように見せるためにオリジナルのＭＩＢを加工して「実際のＭＩＢの定義とは異なった見え方を与え」られたＭＩＢでもあると解される。
　ここで、Ｃの「ＮＷ管理レイヤやサービス管理レイヤ等の上位レイヤにおける性能や障害等の管理で扱うＭＩＢ定義は，一般に，ＮＥ装置のＭＩＢ定義とは異なり，管理目的に応じてＭＩＢの集約や加工を行ったビューを提供する必要がある．」、Ｄの「オリジナルのＭＩＢの情報に対して，あらかじめ集約・加工の処理を行ってビューのＭＩＢの情報として保持し，ビューのＭＩＢに対する管理操作は保持した情報に対して実行する」、Ｆの「ビューのＭＩＢに対する管理操作の受信に関係なく，指定した周期でオリジナルのＭＩＢの属性値を取得し，その属性値を集約・加工してビューのＭＩＢの情報として保持する．」から、サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理においては、指定した周期で取得したオリジナルのＭＩＢの属性値を管理目的に応じて集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行する、ことが記載されている。
　ところで、Ｃの「同種のＮＥ装置であってもベンダや標準によってＭＩＢ定義が異なる場合がある．たとえば，ＡＴＭ交換機では，ＡＴＭ Forum標準のＭＩＢ定義９）とベンダ独自のＭＩＢ定義１０）とを比較すると，使用ＶＰ（Virtual Path）の総数等のように，標準のＭＩＢ定義における１つの属性型が，ベンダのＭＩＢ定義における複数の属性型で表現されたり，チャネル識別子のように，それぞれのＭＩＢ定義で属性型の名前やシンタックスが同じでも，意味が異なる場合がある．」、Ｌの「提案方式を実装し，ＡＴＭ交換機のビュー提供に適用して，自動生成したビュー提供プログラムの処理時間やプログラム開発効率等の観点から提案方式の有効性を実証した．」及び「ＴＭＮのネットワーク管理レイヤやサービス管理レイヤ，ならびに，顧客網管理（ＣＮＭ）の実装が進むことが予想される．管理目的に応じて既存のＮＥ装置のＭＩＢを集約・加工した新たなビューを提供可能とする提案方式は，これらの実装に有効な方式である．」から、引用文献に記載されたネットワーク管理方法は、ＡＴＭ交換機として機能させる複数のＮＥ装置を管理対象とすると解される。
　
　以上から、引用文献には、
　ＡＴＭ交換機として機能させる複数のＮＥ装置を管理対象とし、サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理において、指定した周期で取得した各ＮＥ装置を表現するオリジナルのＭＩＢを、その定義が同一であるかのように見せるために、管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行するネットワーク管理方法、
が記載されている。
　
ｂ．Ｅの「オリジナルのＭＩＢ定義とビューのＭＩＢ定義間の対応関係を記述する方法（以下，対応関係記法と呼ぶ）を新たに規定，導入する」及び「ビューを提供するプログラム（以下，ビュー提供プログラムと呼ぶ）を，上記（１）を用いて記述した対応関係を利用して自動生成させる」、Ｈの「対応関係記法による記述例として，ベンダ独自のＭＩＢ定義（オリジナルのＭＩＢ）を持つFore社製ＡＴＭ交換機に，標準のＭ４インタフェースのＭＩＢ定義に従うビューを提供させる」から、ビュー提供プログラムは、ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を記述する対応関係記法を利用して自動生成されることが記載されている。
　また、Ｇには、対応関係記法は、「ＭＯクラスと属性型ごとの記述」、「管理操作と通知の種類ごとの記述」、「静的な情報の対応付けの記述」、「動的な情報の対応付けの記述」、「周期的に起動される処理の記述」、「ＡＳＮ．１データ型の記述」及び「永続変数の記述」という複数の記述で表されることが記載されている。
　
　さらに、Ｂの「ＭＩＢに対する管理操作には，属性値の取得（M-Get）…（中略）…がある．」、Ｆの「ビュー提供プログラムの機能」及び「ビューのＭＩＢに対する管理操作の受信に関係なく，指定した周期でオリジナルのＭＩＢの属性値を取得し，その属性値を集約・加工してビューのＭＩＢの情報として保持する．」、Ｊの「ビュー提供プログラムは図８に示すように，（１）制御モジュール，（２）変換処理モジュール，（３）インスタンス管理モジュール，（４）タイマモジュールから構成する．」及び「ビューのＭＩＢに対する管理操作およびオリジナルのＭＩＢからの管理操作応答や通知はすべてこの制御モジュールが受信する．」から、ビュー提供プログラムが、指定した周期でオリジナルのＭＩＢの属性値を取得する、ことが記載されている。
　
　したがって、引用文献には、
　ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法を利用して自動生成されるビュー提供プログラムが、指定した周期でオリジナルのＭＩＢの属性値を取得する、
ことが記載されている。
　
ｃ．Ｆの「ビュー提供プログラムの機能……（中略）……（２）周期的に集約・加工を行う機能
ビューのＭＩＢに対する管理操作の受信に関係なく，指定した周期でオリジナルのＭＩＢの属性値を取得し，その属性値を集約・加工してビューのＭＩＢの情報として保持する．」、Ｇの「条件５の周期的に取得した属性値をビューのＭＩＢの情報として保持するため，永続的に保存する変数（以下，永続変数と呼ぶ）を宣言可能とする」、Ｈの「オリジナルのＭＩＢの６つの属性値から送受の廃棄セルの積算値を取得し（６行目から８行目），前の１５分ごとの性能データからの差分を計算してビューの属性値を得る（９行目）．１５分ごとの性能データは，永続変数として保持し（１３行目），Timer規則により１５分ごと（１１行目）に，１７行目から２１行目の処理により更新する」、及び、Ｋの「ベンダ独自のＭＩＢ１０）を持つFore社製ＡＴＭ交換機をオリジナルのＭＩＢとし，標準のＭ４インタフェース９）のビューとして提供するビュー提供プログラム」から、ビュー提供プログラムは、ベンダ独自のオリジナルのＭＩＢの属性値を指定した周期で取得し，取得したオリジナルのＭＩＢの属性値を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持する、ことが記載されている。
　そして、Ｃの「ビュー提供の実現形態には…（中略）…マネージャとエージェントの間に外付けの装置（プロキシー）として実現する形態がある．」、Ｋの「生成プログラムは，2.2節で述べた３つの実現形態（マネージャ，プロキシー，エージェント）のうち，今回プロキシーの形態に対応するプログラムとした．」及び「ベンダ独自のＭＩＢ１０）を持つFore社製ＡＴＭ交換機をオリジナルのＭＩＢとし，標準のＭ４インタフェース９）のビューとして提供するビュー提供プログラムを対応関係記述から自動生成した．マネージャから，プロキシーを介してＡＴＭ交換機に管理操作を発行したときの処理時間を計測した．マネージャ，プロキシーならびにエージェントはＬＡＮ（Ethernet）で接続した．」、Ｍの図示態様から、ビュー提供プログラムは、マネージャと各ＮＥ装置を示すエージェントとの間のプロキシーの形態に対応するプログラムであることが記載されている。
　
　さて、Ｈには、「対応関係記法による記述例として，ベンダ独自のＭＩＢ定義（オリジナルのＭＩＢ）を持つFore社製ＡＴＭ交換機に，標準のＭ４インタフェースのＭＩＢ定義に従うビューを提供させるため」の「性能情報」の「対応関係記述を以下に示す．」と記載されるとともに、「（２）性能情報の対応付け（あらかじめ集約・加工を行う例）」の例として「図５にビューのＭＩＢのＭＯクラス“cellLevelProtocolCurrentData”の属性型“discardedCellsInvalidHeader”の対応付けの一部を示す．この属性型は，１つのポートにおける不正なヘッダのため廃棄したセル数の１５分ごとの積算値を示す．オリジナルのＭＩＢでは，不正ヘッダによる廃棄セル数は，交換機起動時からの積算値を表し，また，送受別々に積算している．このため，オリジナルのＭＩＢの６つの属性値から送受の廃棄セルの積算値を取得し（６行目から８行目），前の１５分ごとの性能データからの差分を計算してビューの属性値を得る（９行目）．」と記載されている。
　したがって、引用文献には、「（２）性能情報の対応付け（あらかじめ集約・加工を行う例）」として、オリジナルのＭＩＢから標準のＭ４インタフェースのＭＩＢ定義に従うビューを提供させるための性能情報の対応付けに、「オリジナルのＭＩＢの６つの属性値」から「取得」する「送受の廃棄セルの積算値」を利用することが記載されている。
　ここで、Ｃの「ＮＷ管理レイヤやサービス管理レイヤ等の上位レイヤにおける性能や障害等の管理で扱うＭＩＢ定義は，一般に，ＮＥ装置のＭＩＢ定義とは異なり，管理目的に応じてＭＩＢの集約や加工を行ったビューを提供する必要がある．図２にＮＷ管理レイヤにおけるビュー提供の例を示す．ここでは，ＡＴＭ ForumのＭＩＢ定義９）をオリジナルのＭＩＢ定義としている．…（中略）…その下位のＭＯクラス“upcNpcCurrentData”では，使用パラメータ制御（ＵＰＣ）を違反した廃棄セル等の性能情報が定義されている．」から、「性能情報の対応付け」に利用する「送受の廃棄セルの積算値」を「取得」するために用いる「オリジナルのＭＩＢの６つの属性値」は、オリジナルのＭＩＢの「性能情報」であると認められる。
　
　以上から、引用文献には、
　マネージャと各ＮＥ装置を示すエージェントとの間のプロキシーの形態に対応するビュー提供プログラムが、指定した周期で取得したオリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持する、
ことが記載されている。
　
ｄ．Ｋの「マネージャから，プロキシーを介してＡＴＭ交換機に管理操作を発行した」から、管理操作を発行するのはマネージャである。
　ここで、前記ｃの認定のとおり、ビュー提供プログラムは、マネージャとＮＥ装置を示すエージェントとの間のプロキシーの形態に対応するプログラムである。
　
　ところで、Ｋに「ベンダ独自のＭＩＢ１０）を持つFore社製ＡＴＭ交換機をオリジナルのＭＩＢとし，標準のＭ４インタフェース９）のビューとして提供するビュー提供プログラム」と、Ｈに「ベンダ独自のＭＩＢ定義（オリジナルのＭＩＢ）を持つFore社製ＡＴＭ交換機に，標準のＭ４インタフェースのＭＩＢ定義に従うビューを提供させる」と、それぞれ記載されている。すなわち、引用文献における「ビュー提供プログラム」は、「ＡＴＭ交換機」を表現するベンダ独自の「オリジナルのＭＩＢ」から、「標準のＭ４インタフェース」のビューのＭＩＢに従う「ビュー」を提供するものである。してみれば、管理操作を発行するマネージャから見ると、「ビュー提供プログラム」は、「ＡＴＭ交換機」を表現するベンダ独自の「オリジナルのＭＩＢ」を、「標準のＭ４インタフェース」のビューのＭＩＢであるように見せると認められる。
　
　よって、Ｄの「オリジナルのＭＩＢの情報に対して，あらかじめ集約・加工の処理を行ってビューのＭＩＢの情報として保持し，ビューのＭＩＢに対する管理操作は保持した情報に対して実行する」とは、オリジナルのＭＩＢの情報に対して集約・加工の処理を行って、「標準のＭ４インタフェース」のビューのＭＩＢの情報として保持し，「マネージャ」はビューのＭＩＢに対する管理操作を、前記保持された「標準のＭ４インタフェース」のビューのＭＩＢの情報に対して実行する、という意味であると認められる。
　
　また、Ｂには「ＭＩＢに対する管理操作には，属性値の取得（M-Get）と設定（M-Set），ＭＯインスタンスの生成（M-Create）と削除（M-Delete），動作（M-Action），ならびに，取得操作の取消し（M-CancelGet）とＭＩＢから発行する通知（M-EventReport）がある．」と記載されている。そして、Ｎには、測定項目が「（ａ）属性型vpCTPIdの値取得」の処理時間は「１０５．５（２３６．６）」msecであること、測定項目が「（ｂ）属性型maxNumActiveVCCsAllowedの値取得」の処理時間は「８２９．８（１３０８．７）」msecであること、測定項目が「（ｃ）属性型cellScramblingEnabledの値取得」の処理時間は「１５６．３（２９０．２）」msecであること、「測定項目が「（ｄ）属性型m3100alarmStatusの値取得」の処理時間が「８３．４（１２４．４）」msecであることが、それぞれ記載されている。さらに、同表の「（注１）」には、「数値は図９の（２）と（６）の和．括弧内の数値は（１）から（７）までのすべての和」であることが記載されている。
　以上の記載、前述のとおり、管理操作は保持された「標準のＭ４インタフェース」のビューのＭＩＢの情報に対して実行するものであり、「ビュー提供プログラム」はベンダ独自の「オリジナルのＭＩＢ」を「標準のＭ４インタフェース」のビューのＭＩＢであるように見せるものであることから、「属性値の取得」という管理操作を、保持された標準のＭ４インタフェースのビューのＭＩＢの情報に対して実行すると、前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が、マネージャに出力される、と解される。
　そして、前記ｃの認定から、保持された標準のＭ４インタフェースのビューのＭＩＢの情報は、指定した周期で取得したオリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工したものであるから、マネージャに出力される前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報は、オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である。
　
　したがって、引用文献には、
　マネージャが、保持された標準のＭ４インタフェースのビューのＭＩＢの情報に対して実行する属性値の取得という管理操作を発行すると、オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される、
ことが記載されていると解される。
　
　以上、ａ〜ｄから、引用文献には、次の発明（以下、「引用発明」という）が記載されているものと認められる。
「ＡＴＭ交換機として機能させる複数のＮＥ装置を管理対象とし、サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理において、指定した周期で取得した各ＮＥ装置を表現するオリジナルのＭＩＢを、その定義が同一であるかのように見せるために、管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行するネットワーク管理方法であって、
　ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法を利用して自動生成されるビュー提供プログラムが、指定した周期で前記オリジナルのＭＩＢの属性値を取得し、
　マネージャと各ＮＥ装置を示すエージェントとの間のプロキシーの形態に対応する前記ビュー提供プログラムが、前記指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持し、
　前記マネージャが、前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報に対して実行する属性値の取得という管理操作を発行すると、前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される、
ことを特徴とするネットワーク管理方法。」
　
（２−２）引用発明との対比
　補正後の発明と引用発明とを対比する。
　
ａ．引用発明において、「ＮＥ装置」は「ネットワーク管理方法」の「管理対象」である。
　これに対して、補正後の発明において、「ホストマシン」は、前記「ホストマシン」に「常駐するサービス」から「サービス性能情報を収集」する際の、当該「収集」の対象ホストマシンであるから、補正後の発明における「方法」の対象マシンであると云える。
　したがって、引用発明の「ＮＥ装置」と、補正後の発明の「ホストマシン」とは、対象マシンである点で共通する。
　
ｂ．引用発明において、「オリジナルのＭＩＢの属性値」は「サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理」という「サービス管理」に用いる「性能情報」である。したがって、引用発明の前記「オリジナルのＭＩＢの属性値」は、補正後の発明の「サービス」から「収集」する「サービス性能情報」に相当する。
　一方、引用発明の「標準のＭ４インタフェースのビューのＭＩＢの情報」は、「その定義が同一であるかのように見せるために、管理目的に応じて集約・加工して提供」される「ビューのＭＩＢの情報」であり、具体的には、「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法」の情報を使用して「ビュー提供プログラム」が「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工」することで得られた情報であるから、「ベンダ」に依存しない情報であって、前記「ビュー提供プログラム」の出力であると認められる。
　したがって、引用発明の「標準のＭ４インタフェースのビューのＭＩＢの情報」は、補正後の発明の「汎用的な出力」に相当する。
　ところで、引用発明においては、「指定した周期で前記オリジナルのＭＩＢの属性値を取得」する「ビュー提供プログラム」は、「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法を利用して自動生成される」ものである。そして、前記「自動生成」は、引用文献においてはビュー提供プログラム生成コンパイラが実現することは、前記「（２−１）引用発明」の項の「Ｊ」に記載するとおりである。したがって、前記「ビュー提供プログラム」を「自動生成」するために、該「自動生成」に「利用」する「複数の記述で表した対応関係記法」の情報を、何らかの記憶手段に格納していることは、技術常識を参酌すれば明らかである。そして、「複数の記述で表した対応関係記法」の情報を何らかの記憶手段に格納するのであるから、当該「対応関係記法」を表す「複数の記述」の情報も何らかの記憶手段に格納されることは自明である。
　よって、引用発明における、何らかの記憶手段に格納される「複数の記述」の情報は、補正後の発明の「記憶装置に格納された規則のセット」に相当する。
　
ｃ．さて、上述のとおり、引用発明においては、「ビュー提供プログラム」は「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法を利用して自動生成される」ものである。そして、前記「ビュー提供プログラム」は、「指定した周期で取得した前記オリジナルのＭＩＢの属性値を周期的に集約・加工」して「標準のＭ４インタフェースのビューのＭＩＢの情報」とするものである。すなわち、「指定した周期で取得した前記オリジナルのＭＩＢの属性値」を「周期的に集約・加工」することにより「標準のＭ４インタフェースのビューのＭＩＢの情報」に変換している。
　そして、前記「ビュー提供プログラム」は、「前記オリジナルのＭＩＢの属性値を周期的に集約・加工」するのであるから当然に「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係」を表す「対応関係記法」の情報を有し、「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報と」するに際しては、前記「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係」を表す「対応関係記法」の情報を使用していると認められる。
　よって、引用発明の「指定した周期で取得した前記オリジナルのＭＩＢの属性値を周期的に集約・加工」して「ビューのＭＩＢの情報」とするのに使用する前記「対応関係記法」の情報は、補正後の発明の「収集されたサービス性能情報を汎用的な出力に変換」するのに「使用」する「健全性生成アルゴリズム」に相当する。
　
　引用発明の「ビュー提供プログラム」は、「サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理」という「サービス管理」のために、前述のとおり、前記「対応関係記法」の情報を使用して「指定した周期で取得した前記オリジナルのＭＩＢの属性値」を「周期的に集約・加工」することにより、「標準のＭ４インタフェースのビューのＭＩＢの情報」に変換している。
　ここで、前記「ビュー提供プログラム」は「マネージャと各ＮＥ装置を示すエージェントとの間のプロキシーの形態に対応する」プログラムである。
　してみれば、前記「ビュー提供プログラム」を実行することで実現される、前記「対応関係記法」の情報を使用して「指定した周期で取得した前記オリジナルのＭＩＢの属性値」を「周期的に集約・加工」することにより、「標準のＭ４インタフェースのビューのＭＩＢの情報」に変換するという機能は、「マネージャと各ＮＥ装置を示すエージェントとの間のプロキシー」が果たす機能である。
　したがって、引用発明の前記「プロキシー」は、補正後の発明の「記憶装置に格納された規則のセットに含まれる健全性生成アルゴリズムを使用して、収集されたサービス性能情報を汎用的な出力に変換」する「健全性生成器」に相当する。
　
ｄ．引用発明において、「マネージャ」が「属性値の取得という管理操作を発行する」と、「サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理」という「サービス管理」の対象である「ＮＥ装置」を「表現」する「オリジナルのＭＩＢ」の「属性値である性能情報を周期的に集約・加工」して得られた「前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」が自身に「出力される」のであるから、前記「マネージャ」は前記「ＮＥ装置」の「性能」を監視している手段であると云える。
　してみれば、引用発明の「マネージャ」と補正後の発明の「複数の性能監視ツール」とは、いずれも、性能監視ツールであるという点で共通している。
　
ｅ．引用発明において、「ビュー提供プログラム」は「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持」するものであり、「マネージャ」は「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報に対して実行する属性値の取得という管理操作を発行する」とともに「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」ものである。
　ここで、「ビュー提供プログラム」が「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工し」たものが「標準のＭ４インタフェースのビューのＭＩＢの情報として保持」され、「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」以上、前記「周期的に集約・加工し」て得た「標準のＭ４インタフェースのビューのＭＩＢの情報」を「保持」して「マネージャに出力」するための何らかの記憶モジュールを、引用発明が有することは明らかである。
　また、「（２−１）引用発明」の項のＫに示したように、引用文献には、「提案方式の有効性を実証するため」に「マネージャから，プロキシーを介してＡＴＭ交換機に管理操作を発行したときの処理時間を計測」するための「試験構成」が「マネージャ，プロキシーならびにエージェントはＬＡＮ（Ethernet）で接続した」ものであると記載されている。そして、引用発明は、「マネージャ」が前記何らかの記憶モジュールに「保持」された「標準のＭ４インタフェースのビューのＭＩＢの情報」に対して実行する「属性値の取得という管理操作を発行すると」、「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」という構成を持つ。前記記載及び技術常識を参酌しつつ前記構成を解すれば、引用発明が、前記何らかの記憶モジュールに「保持」された「標準のＭ４インタフェースのビューのＭＩＢの情報」に前記「マネージャ」がアクセスするための、前記「マネージャ」の、前記「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段を有していることは明らかである。
　これに対して、補正後の発明においては、「健全性生成器」の「該汎用的な出力」は、「複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリ」に接続された「共有記憶モジュールに格納」される。
　したがって、引用発明において、「ビュー提供プログラム」は「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持」し、「マネージャ」が「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報に対して実行する属性値の取得という管理操作を発行する」と「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」ことと、補正後の発明において、「健全性生成器」の「該汎用的な出力」は「複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリ」に接続された「共有記憶モジュールに格納」されることとは、健全性生成器の汎用的な出力を記憶モジュールに格納するとともに、性能監視ツールの該汎用的な出力へのインタフェースを提供するインタフェース手段を有する点で、共通する。
　
ｆ．引用発明において、「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は「前記オリジナルのＭＩＢの属性値が周期的に集約・加工」されて「保持」された「性能情報」である。したがって、「前記マネージャに出力」される前記「周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、「指定した周期」で「取得」された「前記オリジナルのＭＩＢの属性値が集約・加工」される時点での「性能情報」である。そして、引用発明の「性能情報」は、「サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理」という「サービス管理」に用いる情報である。
　これに対して、補正後の発明の「サービスの現在の作業性能に関係」する「該汎用的な出力」は、「収集されたサービス性能情報」が「汎用的な出力に変換」される時点を「現在」とする、「サービスの現在の作業性能に関係」する情報であると解される。
　したがって、前記ｂ及びｃの認定を考慮すれば、引用発明において、「指定した周期」で「取得」された「前記オリジナルのＭＩＢの属性値が集約・加工」される時点での前記「性能情報」である「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」を「サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理」という「サービス管理」に用いることは、補正後の発明において「該汎用的な出力は、サービスの現在の作業性能に関係」することに相当する。
　
　そして、引用発明において、前記「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、「マネージャに出力される」ものであるとともに、「その定義が同一であるかのように見せるために、管理目的に応じて集約・加工して提供」される「ビューのＭＩＢの情報」であり、具体的には、「ベンダ独自のオリジナルのＭＩＢ定義と標準のＭ４インタフェースのビューのＭＩＢ定義間の対応関係を複数の記述で表した対応関係記法」の情報を使用して「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して」得られた情報である。
　ここで、引用発明は「マネージャと各ＮＥ装置を示すエージェントとの間のプロキシーの形態に対応する前記ビュー提供プログラムが、指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持し」ているが、前記「（２−１）引用発明」の項の「ｃ」において指摘したとおり、前記「オリジナルのＭＩＢの属性値である性能情報」として、引用文献においては、具体的には、「性能情報の対応付け」に利用する「送受の廃棄セルの積算値」を「取得」するために用いる「オリジナルのＭＩＢの６つの属性値」を用いることが記載されている。そして、「オリジナルのＭＩＢ」はそれぞれの「ＮＥ装置を表現」しているから、前記「オリジナルのＭＩＢの属性値である性能情報」は、「オリジナルのＭＩＢ」で「表現」される「ＮＥ装置」が提供するサービスがどの程度機能しているかを定量的に表す情報であると認められる。
　してみれば、引用発明において、「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を周期的に集約・加工して」得られる「前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、各「ＮＥ装置」が提供するサービスがどの程度機能しているかを「集約・加工」した情報であるとともに、「標準のＭ４インタフェースのビューのＭＩＢの情報」であるから、「ベンダ」に依存しない一貫した情報であると認められる。
　したがって、引用発明において「前記マネージャに出力」される「前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報」が「前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である」ことと、補正後の発明において「該汎用的な出力は、該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであ」ることとは、いずれも、汎用的な出力は性能監視ツールに提供される一貫した健全性計量の要約された情報である点で共通している。
　
ｇ．さて、引用発明は、そもそも、「指定した周期で取得した各ＮＥ装置を表現するオリジナルのＭＩＢを、その定義が同一であるかのように見せるために、管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行」しようとするものであり、具体的には、「前記マネージャ」が「属性値の取得という管理操作を発行する」と「前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」ものである。
　すなわち、「管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行」するために、引用発明においては、「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」が「前記マネージャに出力」されるものであって、前記「標準のＭ４インタフェースのビューのＭＩＢの情報」を生成・導出するために利用した「対応関係記法」の情報や「ビュー提供プログラム」の情報は「前記マネージャに出力」されない。また、「管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行」するために、引用発明の前記「マネージャ」は、前記「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」が必要であって、前記「対応関係記法」の情報や「ビュー提供プログラム」の情報が「出力される」必要がある旨の記載は引用文献には存在しない。
　したがって、引用発明において、「管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行」するために、「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」を「前記マネージャに出力」することと、補正後の発明において「該汎用的な出力」が「健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく、該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む」こととは、いずれも、汎用的な出力が、健全性計量の導出に関する情報を該性能監視ツールに提供することなく、該性能監視ツールに使用され得る該一貫した健全性計量の要約された情報を含む点で共通している。
　
ｈ．引用発明の「ネットワーク管理方法」は、「ＡＴＭ交換機として機能させる複数のＮＥ装置を管理対象とし、サービス管理レイヤ等の上位レイヤにおける性能や障害等の管理において、指定した周期で取得した各ＮＥ装置を表現するオリジナルのＭＩＢを、その定義が同一であるかのように見せるために、管理目的に応じて前記オリジナルのＭＩＢの属性値を集約・加工して提供したビューのＭＩＢの情報に対して管理操作を実行する」ものであり、具体的には、「前記マネージャ」が「属性値の取得という管理操作を発行する」と、「サービス管理」の「管理対象」である「ＮＥ装置」を「表現」している「前記オリジナルのＭＩＢ」の「属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」ものである。
　また、ｆで認定したように、「前記マネージャに出力」される前記「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、「指定した周期」で「取得」された「前記オリジナルのＭＩＢの属性値が集約・加工」される時点での「性能情報」であるとともに、各「ＮＥ装置」が提供するサービスがどの程度機能しているかを「集約・加工」した情報であると認められる。
　そして、前記「マネージャに出力」される前記「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、「前記オリジナルのＭＩＢ」の「属性値が周期的に集約・加工された性能情報」であるから、前記「マネージャ」に「周期的」に継続して「出力」されると認められる。この点は、引用文献の「（２−１）　引用発明」の項における、Ｆの「ビューのＭＩＢに対する管理操作の受信に関係なく，指定した周期でオリジナルのＭＩＢの属性値を取得し，その属性値を集約・加工してビューのＭＩＢの情報として保持する．」との記載、Ｇの「周期的に取得した属性値をビューのＭＩＢの情報として保持するため，永続的に保存する変数（以下，永続変数と呼ぶ）を宣言可能とする」、Ｈに「オリジナルのＭＩＢの６つの属性値から送受の廃棄セルの積算値を取得し（６行目から８行目），前の１５分ごとの性能データからの差分を計算してビューの属性値を得る（９行目）．１５分ごとの性能データは，永続変数として保持し（１３行目），Timer規則により１５分ごと（１１行目）に，１７行目から２１行目の処理により更新する」との記載に示されるように、収集された性能データが周期的に集約・加工された情報が、ビューのＭＩＢの情報として、周期的に継続して保持され出力されることが、引用文献に記載されているとおりである。
　してみれば、引用発明の「ネットワーク管理方法」は、各「ＮＥ装置」が提供するサービスがどの程度機能しているかを「集約・加工」した情報である「前記オリジナルのＭＩＢの属性値が周期的に集約・加工された性能情報である前記保持された標準のＭ４インタフェースのビューのＭＩＢの情報が前記マネージャに出力される」ことにより、管理対象の「ＮＥ装置」が提供するサービスが、「前記オリジナルのＭＩＢの属性値」が「集約・加工され」る時点で、どの程度機能しているかを示す前記「標準のＭ４インタフェースのビューのＭＩＢの情報」を、周期的に継続して前記「マネージャに出力され」る方法であると認められる。
　
　これに対して、補正後の発明は、「ホストマシンに常駐するサービスの健全性を動的に判断するための方法」である。
　ここで、前記「サービスの健全性を動的に判断するするための方法」について、本願明細書の発明の詳細な説明には、以下のように記載されている（下線は、参考のため当審において付したもの。）。
　明細書の段落【００１０】には、「【課題を解決するための手段】」として、「装置は、サービスまたはサービスを構成するアプリケーションまたはプロセスから、
情報を動的に集めおよび／または導出することによって、
サービスの健全性を判断する
広範囲のサービスに対する一貫した健全性計量を動的に導出する
健全性生成器の出力は、プログラムまたはスクリプト可能インタフェースを介して
性能監視ツールセットによって使用され得る
　一方、上記の記載を具体的に説明する、発明の詳細な説明の「【発明の実施の形態】」には、「サービスの健全性を動的に判断する」ことの明示の記載はないものの、以下の記載がある。
　すなわち、
　明細書の段落【００１５】に「
性能監視ソフトウェアは、コンピュータシステムについての即時の性能情報を提供し
性能管理ソフトウェアは、コンピュータシステムについての即時の性能情報を提供し、管理者がコンピュータシステムの活動を検査し、ボトルネックを識別し且つ解決し、動作がより効率的になるようにコンピュータシステムを調整できる
　明細書の段落【００２０】〜【００２６】に「サービスの健全性を完全に、または少なくとも十分に定義するために、たとえば８個の計量が導出される」、「使用可能度は、サービスが
現在動作可能であるかどうかの２値の指示
現時点におけるサービスの最大スループット
スループットは
現時点においてサービスによってどのくらいの仕事が行われているかの指示
利用度は
現在のスループットのパーセント表示
　明細書の段落【００３１】に「共用メモリインプリメンテーション１０７は、健全性データ１４を記憶する。その結果、性能監視ツールセットの中の任意の
性能管理ツールは、健全性データ１４にアクセスし、性能監視ツールセットの設計と一貫した間隔でアクセスし得る
　明細書の段落【００３７】に「データエンジンの各々は、特定のデータソースから情報を取得し、（
間隔管理エンジン１２３を経由して
　明細書の段落【００４１】に「間隔管理エンジン１２３は、
種々の報告時間、間隔および性能監視ツールの種々のデータ読取り要求を伴う計量に対処する
それぞれ記載されている。
　してみれば、補正後の発明の「ホストマシンに常駐するサービスの健全性を動的に判断するための方法」は、本願明細書の発明の詳細な説明の記載を参酌すれば、その段落【００１０】に記載されるように「情報を動的に集めおよび／または導出する」ことによって「サービスの健全性を判断する」ための前記「サービスに対する一貫した健全性計量を動的に導出する」ことで、該「動的」な「健全性計量」を「性能監視ツールセット」が「プログラムまたはスクリプト可能インタフェースを介してアクセス」可能とする方法であると認められ、具体的には、「種々の報告」の「間隔」を管理する「間隔管理エンジン１２３」を「経由」して、「特定のデータソース」から「取得」した「データをデータ解析エンジン１２５」に「提供」して変換した汎用的な出力を、「コンピュータシステムについての即時の性能情報」である「現在」の「健全性データ１４」として「共用メモリインプリメンテーション１０７」に「記憶」し、「任意の性能管理ツール」が所定の「間隔」で前記「健全性データ１４にアクセス」することで、「性能管理ツール」が「コンピュータシステムの活動を検査」し「これらのコンピュータシステムの性能を追跡する」ものである。
　
　よって、引用発明の前記「ネットワーク管理方法」と、補正後の発明の「ホストマシンに常駐するサービスの健全性を動的に判断するための方法」とは、ともに、対象マシンに常駐するサービスの健全性を動的に判断するための方法である点で共通している。
　
　以上ａ〜ｈから、補正後の発明と引用発明とは、以下の点で一致し、また、相違する。
　
（一致点）
　対象マシンに常駐するサービスの健全性を動的に判断するための方法であって、
　健全性生成器が、サービスからサービス性能情報を収集し、
　前記健全性生成器が、記憶装置に格納された規則のセットに含まれる健全性生成アルゴリズムを使用して、収集されたサービス性能情報を汎用的な出力に変換し、
　該汎用的な出力を、記憶モジュールに格納する方法であって、
　性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース手段を有して、該汎用的な出力は、サービスの現在の作業性能に関係し、該汎用的な出力は、該性能監視ツールに提供される一貫した健全性計量の要約された情報であり、健全性計量の導出に関する情報を、該性能監視ツールに提供することなく、該性能監視ツールに使用され得る該一貫した健全性計量の要約された情報を含む、方法。
　
（相違点１）
　補正後の発明は対象マシンが「ホストマシン」であるのに対して、引用発明は対象マシンが「ＮＥ装置」である点。
　
（相違点２）
　補正後の発明は「複数の性能監視ツール」を有するのに対して、引用発明は「マネージャ」を有するものの、該「マネージャ」が複数であるかどうかは不明である点。
　
（相違点３）
　補正後の発明は、「汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納する」のに対して、引用発明は、「マネージャ」の「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段を有するとともに、「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持」する記憶モジュールを有する点。
　
（相違点４）
　補正後の発明の「汎用的な出力」は一貫した健全性計量の要約された「セット」であるのに対して、引用発明の「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、複数種類あり「セット」をなしているのかどうかは不明である点。
　
（２−３）判断
　前記各相違点について検討する。
（２−３−１）相違点１について
　本願の優先権主張の日前に頒布された刊行物である、
(Ａ)萩原崇、“NEWS-OS Release４．０の概要(４)”、ＵＮＩＸ　ＭＡＧＡＺＩＮＥ、株式会社アスキー、１９９１年６月１日、第６巻、第６号、ｐｐ．１６〜２４
には、図面とともに次の事項が記載されている（下線は、参考のために当審で付したものである。以下、他の文献についても同様。）。
ア．「ＳＮＭＰを用いた管理モデル
　
ＳＮＭＰを使ったネットワーク管理では
ネットワーク上の管理の対象
ホスト
からＭＩＢの値を読み出し、ネットワークの状態を把握する
 
　同様に、本願の優先権主張の日前に頒布された刊行物である、
(Ｂ)藤崎智宏、他、“ホストから情報を収集するエージェントの構成に関する一考察”、第５４回（平成９年前期）全国大会講演論文集（３）、社団法人情報処理学会、１９９７年３月１４日、ｐｐ．３−５７９〜３−５８０
イ．「
ＴＣＰ／ＩＰをべースとしたネットワークでは，ホスト計算機，ルータ，ハブといった管理対象機器上に情報提供／機器制御を行うエージェントが存在し，そのエージェントに対しネットワーク管理ステーションが情報の取得／設定を行う，という管理モデル
　情報の取得にはＳＮＭＰ[RFC1157]が用いられ，管理情報としてはＲＦＣにより，各種のＭＩＢが定義されている．
　……（中略）……
３   ホスト計算機とＭＩＢ
　
管理対象としてホスト計算機
ホストの持つ機能や資源を管理するために，Host Resources ＭｌＢが定義されており，このＭＩＢ情報を扱うエージェントを実装することで，ディスクの使用量，実行中のプロセスなどの情報を取得する
　
　さらに、本願の優先権主張の日前に頒布された刊行物である、
(Ｃ)宇夫陽次朗、“ＲＦＣダイジェスト  ２３”、ＵＮＩＸ　ＭＡＧＡＺＩＮＥ、株式会社アスキー、２０００年６月１日、第１５巻、第６号、ｐｐ．１５４〜１５９
ウ．「
ホストシステムを管理するためのホスト資源ＭＩＢ
　
ホスト資源ＭＩＢは、ホスト内のさまざまな資源を管理するためのＭＩＢである。
　
　ア〜ウから、
「管理対象からＭＩＢの情報を収集して、管理対象の状態を把握することで当該管理対象を管理するネットワーク管理技術において、前記管理対象をホストとする」
ことは、本願の優先権主張の日において、既に、周知技術であった。
　
　してみれば、引用発明において、対象マシンである「ＮＥ装置」をホストとすることは、当業者が必要に応じて適宜なし得た事項であると認められる。
　
　よって、相違点１は格別のものではない。
　
（２−３−２）相違点２及び相違点３について
　原審の拒絶査定は、補正後の発明の「汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納する」という点に関して、
　引用文献に、
「（１）複数の管理対象装置にまたがる統合的な管理を行うために、各装置のＭＩＢ定義を同一のものとして扱えるビューを提供する。
（２）オリジナルのＭＩＢの情報に対して、あらかじめ集約・加工の処理を行って、ビューのＭＩＢの情報として保持する。
（３）オリジナルのＭＩＢの属性値をビューのＭＩＢの属性値に集約・加工するための型変換及び関数を記述した複数の管理操作規則を入力する。
（４）ＡＰＩを介して、ビューのＭＩＢへの管理操作を行う。
（５）標準のビューのＭＩＢを提供する。」
という記載があることから、
「ＭＩＢが、複数の監視ツールに対して、監視情報を入出力するためのインタフェースであることは、本願出願時の技術常識であったことを考慮すれば、ビューのＭＩＢの情報を保持するために、共有された記憶手段を備えていることは、上記引用文献１に記載されているに等しい事項である。」、
としている。
　
　そこで、この点に関し、さらに検討する。
　
　本願の優先権主張の日前に頒布された刊行物である、
(Ｄ)檜垣伸俊、他４名、“オブジェタト指向に基づく
ネットワーク管理システム
には、図面とともに次の事項が記載されている。
エ．「３．２  マネージャエージェントモデル
　ＮＭＳを構成する機器は、マネージャの機能かエージェントの機能のどちらか、または両方の機能を持つ。
　
マネージャでは、複数の管理アプリケーションが、管理操作要求をマネージャＭＩＢ（Ｍ−ＭＩＢ）に送る。Ｍ−ＭＩＢは受け取った要求のうち、必要なものを各エ−ジェントに送り、その結果をアプリケーションに返す。また、エージェントから送られた通知を、必要に応じてアプリケーションに渡す
　エージェントでは、マネージャからの管理操作要求は、Ａ−ＳＭＡＰを経由して、エージェントＭＩＢ（Ａ−ＭＩＢ）に送られる。また、ＬＭはローカルな管理対象からの要求をＡ−ＭＩＢに送る。Ａ−ＭＩＢ は、受け取った要求によって、Ａ−ＭＩＢ内の情報を更新し、必要に応じてマネージャに応答を返したり、自ら判断して通知をマネージャに行う。（図４参照）」（第７３頁右欄第８〜２３行）
　
　同様に、本願の優先権主張の日前に頒布された刊行物である、
(Ｅ)特開平１０−０４０１５２号公報
には、図面とともに次の事項が記載されている。
オ．「【０００１】
【発明の属する技術分野】本発明は、
ネットワーク管理システムにおける障害発生後のリカバリ方式
カ．「【００１９】図１は、本発明の実施の形態の構成を示す図である。図１を参照すると、本発明の実施の形態は、ネットワークアプリケーション１、メモリ管理部２、メモリ更新履歴ファイル３、メモリ部４、メモリ構成定義言語５、オブジェクトファイル生成部６、メモリ構造定義オブジェクトファイル７、情報圧縮機構９、を含んで構成される。また、
トランザクション８はネットワークアプリケーション１とメモリ管理部２が一体となって動作する時の単位を表している。そして、トランザクションが複数になる
キ．「【００２９】本実施例は、ネットワークアプリケーション１、メモリ管理部２、メモリ部４、メモリ更新履歴ファイル３、メモリ構成定義言語５、オブジェクトファイル生成部６、メモリ構成定義オブジェクトファイル７、情報圧縮機構９、メモリ管理部２は、状態管理ＡＰＩ（アプリケーションインタフェース）２−１、メモリアクセスドライバ２−２、バックアップファイルアクセスドライバ２−３、オブジェクトファイルアクセスドライバ２−４を備えて構成される。トランザクション８は、ネットワークアプリケーション１とメモリ管理部２を含んで構成される。」
ク．「【００３２】ネットワークアプリケーションは当システムを初めて、もしくは初期化して利用したい場合に、状態管理ＡＰＩ２−２に対して初期化指示を与える。
【００３３】初期化指示を受けた状態管理ＡＰＩ２−２は、オブジェクトファイルアクセスドライバ２−４に対してメモリ構造定義オブジェクトファイル７の読み込み指示を行う。メモリ構造定義オブジェクトファイル７の定義情報を取得した状態管理ＡＰＩ２−１は、バックアップファイルドライバ２−３に対して、利用者が定義したメモリ定義情報をメモリ更新履歴ファイル３に対して展開するよう指示する。
【００３４】続いて、
状態管理ＡＰＩ２−１は、メモリアクセスドライバ２−２に対して利用者定義のメモリ定義情報を、メモリ部４に展開するよう指示する。また、メモリ更新履歴ファイル３で確保される前の運転情報をメモリ部４に展開し
【００３５】ＷＡＲＭスタート指示を受けた状態管理ＡＰＩ２−１は，バックアップファイルアクセスドライバ２−３に対して、メモリ更新履歴ファイル３の読み込み指示を指示を行う。メモリ更新履歴ファイル３の情報を取得した状態管理ＡＰＩ２−１は、メモリアクセスドライバ２−２に対して取得情報の展開指示を与える。
【００３６】展開指示を受けたメモリアクセスドライバ２−１はメモリ部４にメモリ情報の復旧を行う。
【００３７】上記初期化処理後、
ネットワークアプリケーション１がメモリ部４を参照する場合は、状態管理ＡＰＩ２−１に対して参照要求を発行する。参照要求を受けた状態管理ＡＰＩ２−１は、メモリアクセスドライバ２−２を使用しメモリ部４を検索し、該当情報エリアのポインタ情報を取得
【００３８】そして、そのポインタ情報を状態管理ＡＰＩ２−１が取得しネットワークアプリケーション１に当情報を返却する。
【００３９】
ネットワークアプリケーション１がメモリ部４に情報を書き込む場合は、状態管理ＡＰＩ２−１に対して更新要求を発行
【００４０】更新要求を受けた状態管理ＡＰＩ２−１は、メモリアクセスドライバ２−２を使用しメモリ部４を検索し該当情報エリアに指示された更新情報を書き込む。続いて、状態管理ＡＰＩ２−１は、バックアップファイルアクセスドライバ２−３を使用し、メモリ更新履歴ファイル３を検索し、該当エリアに指示された更新情報を書き込む。状態管理ＡＰＩ２−１とメモリアクセスドライバ２−２、バックアップファイルアクセスドライバ２−３間での情報は、全て情報圧縮機構９によって更新時には圧縮、参照時には伸張を行う。
【００４１】
業務運転中に障害が発生した場合には、ネットワークアプリケーション１よりＷＡＲＭスタート指示を、状態管理ＡＰＩ２−１に発行することにより、自動的にメモリ部４上に障害直前のコミットまでメモリ状態が復旧
　
　さらに、本願の優先権主張の日前に頒布された刊行物である、
(Ｆ)特開２００１−００５７５８号公報
には、図面とともに次の事項が記載されている。
ケ．「【０００４】ＳＮＭＰプロトコルはネットワークマネージャーが問い合わせやコマンドを第バースネットワーク要素に均一な方法で与えることを可能にする。
一般に、ＳＮＭＰプロトコルは、１もしくは複数のネットワークマネージャーおよび管理された各ネットワーク要素に対応する少なくとも１つのエージェントを用いることによってネットワーク管理タスクを実現する。ＳＮＭＰプロトコルに従うと、「エージェント」はサーバ、ホスト、ネットワークゲートウェーのような管理された各ネットワーク要素に対応するコンポーネエントである。各エージェントはマネージトインフォメーションベース（ＭＩＢ:Managed Information Base）に管理データを記憶し、ＳＮＭＰプロトコルに従ってネットワークマネージャーからのそのような管理データに対する問い合わせに応答する
【０００５】ＳＮＭＰプロトコルはネットワークマネージャーとエージェントの間の管理情報を通信するコマンドの数を指定する。例えば、ＳＮＭＰプロトコルは、Getrequest、GetNextRequest、SetRequest、GetResponse、Trapコマンドを指定する。例えば、
ＳＮＭＰプロトコルは、GetRequest、GetNextRequestコマンドに応じて、エージェントはＭＩＢから適切な管理データを評価し取り出す。その後でエージェントはGetResponseコマンドで要求された管理データを返す。
　
　そして、本願の優先権主張の日前に頒布された刊行物である、
(Ｇ)特開平１０−０７８８８２号公報
には、図面とともに次の事項が記載されている。
コ．「【００２５】ハードウェア資源マネージャ10のアーキテクチャおよび機能性は、図２により詳しく示される。図２に示されるように、一般に、ハードウェア資源マネージャ10は、共用メモリ・バッファ36、資源デーモン(resource daemon)38、ソケット接続40を含む。加えて、
各々のアプリケーション・プログラム12は、アプリケーション・プログラム・インタフェース(ＡＰＩ)層42を備え、アプリケーション・プログラムはそれを通して、アプリケーション・プログラム12のプログラミングを単純化するため、また共用メモリ・バッファ36のコマンド形式の変化を可能にするために、ハードウェア資源マネージャ10にインターフェースする
【００２６】
共用メモリ・バッファ36は、それが、１度に１つのアプリケーション・プログラム12のみがハードウェア16を制御するように信号機ロッキング能力を提供するという点で、資源マネージャ10の重要な構成要素である。さらに共用メモリ・バッファ36は、仮想メモリ資源を通して、アプリケーション・プログラム12と資源デーモン38の間の高速リアルタイム通信を提供する。共用メモリ・バッファ36は、それぞれのアプリケーション・プログラム12から通信リンク44を介してデータ情報およびコマンド情報を受け取る
共用メモリ・バッファ36によって受け取られるコマンドは、典型的に、ハードウェア16に特定の働きを実施するために、多様なアプリケーション・プログラム12によって作られるハードウェア16を制御するための要求である。これらのコマンドもまた、それらが資源デーモン38に送られるまで、共用メモリ・バッファ36内の仮想メモリに格納される。
　
　すなわち、上記エ〜コから、
「管理データ・制御データ等の情報を収集してネットワークシステムを管理・制御するに際して、管理・制御対象の管理・制御を行うマネージャあるいは管理ツールを複数設けて、前記複数のマネージャあるいは管理ツールが前記管理・制御対象の前記情報を記録する共通のＭＩＢやメモリにアクセスする」
ことは、本願の優先権主張の日前において、既に、技術常識であった。
　
　さて、
　引用発明は、「マネージャ」の「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段を有するとともに、「指定した周期で取得した前記オリジナルのＭＩＢの属性値である性能情報を集約・加工して、標準のＭ４インタフェースのビューのＭＩＢの情報として保持」する記憶モジュールを有している。
　また、
　前記「（２−１）引用発明」の項の「Ｍ」で指摘したとおり、引用文献には、「ビューのＭＩＢへの管理操作」をビュー提供プログラムはＡＰＩを介して受け付け、前記ビュー提供プログラムが前記ＡＰＩを介して出力した情報を「ビューのＭＩＢからの管理操作応答や通知」として送信することが、その図８に図示されている。
　
　そして、上述のとおりの「管理データ・制御データ等の情報を収集してネットワークシステムを管理・制御するに際して、管理・制御対象の管理・制御を行うマネージャあるいはツールを複数設けて、前記複数のマネージャあるいは管理ツールが前記管理・制御対象の前記情報を記録する共通のＭＩＢやメモリにアクセスする」こと、すなわち、原審の拒絶査定で指摘したとおり、ＭＩＢが複数の監視ツールに対して管理情報を入出力するための共有されるインタフェースであることが、本願の優先権主張の日前において既に技術常識であったことを考慮すれば、
　引用発明において、前記「マネージャ」を複数設け、引用発明が有する「標準のＭ４インタフェースのビューのＭＩＢの情報として保持」する記憶モジュールを当該複数の「マネージャ」に共有させるとともに、引用発明が有する「マネージャ」の「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段をＡＰＩ等のソフトウェアライブラリで実現させて、前記「マネージャ」が前記ＡＰＩ等のソフトウェアライブラリで実現させた「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段を介して、前記共有させた記憶モジュールに「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」に対して実行する「属性値の取得という管理操作を発行」するという動作をできるように、前記ＡＰＩ等のソフトウェアライブラリで実現させたインタフェース手段に前記共有させた記憶モジュールを接続すること、
　すなわち、原審の拒絶査定での指摘のとおり、引用発明において、「標準のＭ４インタフェースのビューのＭＩＢの情報」を、複数の「マネージャ」の、「標準のＭ４インタフェースのビューのＭＩＢの情報」へのインタフェースを提供するインタフェース手段となるＡＰＩ等のソフトウェアライブラリに接続された共有記憶モジュールに「保持」させることは、
引用文献に接した当業者であれば、当然になし得た事項であると認められる。
　
　よって、前記相違点２及び相違点３は格別のものではない。
　
（２−３−３）相違点４について
　引用発明において、「マネージャに出力」される「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」は、「周期的に集約・加工された性能情報」であるとともに、「標準」の、すなわち、一貫した情報である。しかし、前記「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」が、複数種類の情報からなる「セット」をなしているものであるかどうかは不明である。
　
　しかしながら、
　原査定の拒絶の理由に「引用文献２」として引用された、
(Ｈ)山中重幸、“システムリソースやアプリケーションを含む統合管理システムを実現するＴｉｖｏｌｉ”、Ｎｏｔｅｓ／Ｄｏｍｉｎｏ  Ｍａｇａｚｉｎｅ、ソフトバンクパブリッシング株式会社、２０００年０３月０１日、第５巻、第３号、ｐｐ．２４〜２９
には、図面とともに次の事項が記載されている。
サ．「
Tivo1iは、ネットワークからＯＳ、アプリケーションまで、企業システムリソース全体を統合管理する
シ．「
Tivo1i環境にほかの運用管理ツールやアプリケーションを統合するための仕組み
　……（中略）……
（４）ＴＥＣが提供するイベントアダプタのカスタマイズによる統合。ＴＥＣは、ＮＴイベントログ、ＵＮｌＸのsyslog、任意のテキストログファイル、
ＳＮＭＰトラップからイベントを収集してTivoliのイベントに変換するイベントアダプタを持っている。
対象アプリケーションからTivoliのイベント発行コマンドを発行する
ス．「●稼動監視・障害監視
　……（中略）……
　Tivo1i Distributed Monitoringは分散環境で、ノートやアプリケーションの動作状況を集中的に監視する機能を提供する。
ディスクの空き容量やプロセスの動作状況、メモリの使用状況やネットワークの通信状況など２５００種類以上のモニター項目が標準で提供されており、自社開発のアプリケーションなど、標準では対応していない項目をモニタリングする場合には独自のモニター項目も作成てきる
　また、Tivo1i Manager for Dominoは、
メール転送エラーやレプリカ失敗のようなノーツ／ドミノサーバー特有の現象に対するモニター機能も提供
２００種類におよぶモニター項目がR4.5、R4.6、R5.0用として用意
　
それぞれのモニター項目には、複数の閾値を設定して、閾値ごとにアクションを設定
　……（中略）……
●キャパシティ管理
……（中略）……
Tivo1i製品が収集したデータを統合して、分析に適した情報に変換する。さまざまなグラフィカルなフォーマットで表現される情報はインタラクティブに変換（スライス、ダイス、ドリルダウン、ドリルスルー）および参照することができ
　
　本願の優先権主張の日前に頒布された刊行物である、
(Ｉ)“ＨＰ  ＯｐｅｎＶｉｅｗ　評価の高いネットワーク管理ソフトを核に、ＮＴ環境向けに製品ファミリーを拡充中”、アスキーＮＴ、株式会社アスキー、１９９８年７月１日、第３巻、第７号、ｐｐ．１６２
には、図面とともに次の事項が記載されている。
セ．「ただ、ここでも中心となるのはＮＮＭだ。
大きく構成管理、障害管理、性能管理の３つの機能があり
障害管理は、各ノードから発せられるＳＮＭＰ（Simple Network Management Protoco1）のＭＩＢ（Management Information Base）メッセージをＭＩＢブラウザで見てステータスを知ることができるというものだ。性能管理は、やはりＭＩＢメッセージを取得して、被管理マシンのＣＰＵ使用率やディスク容量をグラフ化する
　
　同様に、本願の優先権主張の日前に頒布された刊行物である
(Ｊ)特表平１０−５０２７９４号公報
には、図面とともに次の事項が記載されている。
ソ．「ＯＭＰ２０は、管理情報データベース（ＭＩＢ：management information database）を内蔵するデータベース管理システムを含み、
このＭＩＢ内では、システム・コンフィギュレーション・データならびにセルラ通信システム１０の管理システム要素に関する性能データが管理される。動作中、システム性能データは、ＯＭＰによって受信・処理され、システム性能に関するデータはＭＩＢ内で保持される。ＭＩＢ内で保持されるシステム・データは、本発明に従って、セルラ通信システム１０の性能に関する情報をインタフェース端末２４を介してシステム・オペレータにグラフィカル表示するために、ＭＭＩプロセッサ２２に対してさらに利用可能になる
  第３図には、本発明によるセルラ通信システムの一例としての模式図を示す。複数のＢＴＳは、一般に多角形３０，３２である複数の形状として図示される。各多角形３０，３２は、複数のパラメータによって定義され、これらのパラメータは、例えば多角形の径および高さを設定する。好適な実施例では、各多角形３０，３２はさらに、カラーまたはグレー・シェードを定義するパラメータを含む。第３図において、多角柱３０は全方向性ＢＴＳを表し、六角形として示される。多角柱３２は、セクタ化された通信セルを表し、複数の三角形のセクション３４として画定して示され、各三角形セクションは、セクタ化された通信セルのセクタを表す。多角柱３０，３２の両方の上面から投影されるのは、それぞれインジケータ３６，３８である。インジケータ３６は、多角柱３０と実質的に同じ平面図形を有して示される。同様に、インジケータ３８は、多角柱３２と同じ平面図形、すなわち、複数の三角形セクションを有して示される。
  動作時に、第６図を参照して、
ＭＭＩプロセッサ２２は、セルラ通信システム１０に関する情報をＭＩＢから取得し
ＭＩＢは、逆方向ライズ，ピーク・ライズおよび送信機出力パワーなど、各ＢＴＳの性能に関する情報を収容する。これらのパラメータにより、好適な実施例では、多角柱３０，３２は、逆方向ライズに対応する高さと、送信機出力パワーを最大値のパーセントで表すカラーと、ＢＴＳのピーク逆方向ライズに対応する高さで各柱の上に配置されたインジケータ３６，３８とによって定義される。理解されるように、多角柱３０，３２の上記の定義パラメータは、図のＢＴＳの他の性能特性を表してもよい。
　もしくは
インジケータ３６，３８の凸型または凹型などの、更なる定義パラメータを利用して、ＣＤＭＡシステムにおけるソフト・ハンドオーバの高いレベルからソフト・ハンドオーバの低いレベルへの遷移など、更なる性能特性を表す
  システム動作が続くと、送信機出力パワーなどのシステム性能パラメータは変化し、そのため多角柱３０，３２の特性パラメータも変化する。従って、
システムの動作につれて、セルラ通信システム１０の性能特性の変化に応答して、定義パラメータを修正し（ステップ１０６）、それによりディスプレイ装置上で生成される形状として具現される情報の表示を変更する
　
　さらに、本願の優先権主張の日前に頒布された刊行物である
(Ｋ)特開２００１−０４４９９８号公報
には、図面とともに次の事項が記載されている。
タ．「【０００１】
【発明の属する技術分野】本発明は、コンピュータネットワークにおける通信品質を推定して管理する通信品質推定方法および装置に関する。」
チ．「【００２２】また、
上流側ルータ９および加入者宅内ルータ（ｍＲ）１７の各ルータは、管理情報ベース（ＭＩＢ）を備えており、その要素にはそれぞれのインタフェースを経由して送受信したデータのオクテット数が含まれている。また、その値は他の機器からＳＮＭＰを用いて参照する
【００２３】端末１９ａ〜１９ｄおよびＭＩＢ収集用端末５の各端末は、加入者宅内ルータ（ｍＲ）１７ａ〜１７ｄ、上流側ルータ９のそれぞれのＭＩＢオブジェクトをＳＮＭＰを用いて修得することができる。また、収集する際にネットワークや個々の機器のＣＰＵにかかる負荷は他の通信によるものに比べて十分小さく、
ＳＮＭＰを用いてＭＩＢ情報を収集することが他の通信に及ぼす影響は無視する
【００２４】端末１９ａ〜１９ｄ、デスクトップ型サーバ１、ノートブック型サーバ３、ＭＩＢ収集用端末５のそれぞれの時刻は、 Network Time Protocol（ＮＴＰ）を用いて同期が取られている。
【００２５】また、
ルータのそれぞれのインタフェースを通過して送受信されたパケットのデータ量（オクテット数）を１秒毎にＳＮＭＰを用いて収集し、その差分を取れば、任意の１秒間にルータのインタフェースを通過して送受信されたデータ量を求める
【００２６】端末１９ａ〜１９ｄ、デスクトップ型サーバ１、ノートブック型サーバ３には、トラヒックを発生させるためのソフトウェアＤＢＳがインストールされており、各端末間で任意のトラヒックを発生させることができる。また、
発生させたトラヒックに関して、スループットや遅延などの性能情報を受信側端で記録する
【００２７】以上のように構成されるネットワークを用いて、
エンドエンド性能を推定するのに最適な管理データ項目の選択方法とエンドエンド性能の推定方法、および予め与えられたエンドエンド性能の管理目標値から管理閾値を実験を通して求める
【００２８】まず、本実施形態の通信品質推定方法で推定したい性能尺度、すなわち
エンドエンド性能としては
ネットワークＮＷ１，ＮＷ２およびＮＷ３に流したときの受信側でのスループット
【００２９】また、
エンドエンド性能の推定に使用するデータとしては、ＭＩＢ情報から収集できる情報として、上流側ルータ９の送信トラヒック量および加入者宅内ルータ（ｍＲ）１７や高機能加入者宅内ルータ(Cisco) ２１からなる下流側ルータの受信トラヒック量を使用
ツ．「【００６７】
【数４】
      ｙ＝ａ0 ＋ａ11ｘ1 ＋ａ12ｘ12＋ａ13ｘ13
          ＋ａ14ｘ14＋ａ15ｘ15＋ａ41ｘ4                       …（２）
各回帰係数とその統計量は図１４に示す表７の通りである。これは、
今回用いたサンプルのうち、ｘ1 ，ｘ4 の２種類の回線使用率を使用し、式（２）に代入すれば、往復遅延を精度良く推定できる
　
　すなわち、上記サ〜ツから、
「ネットワークシステムを管理するネットワーク管理システムにおいて、ＭＩＢの情報を収集する等により、管理対象から取得した性能情報を加工・演算してマネージャ用の性能データを生成するに際して、前記取得した性能情報を加工・演算することで、管理目的にあわせた性能データを複数種類生成する、すなわち、性能データのセットを生成すること」
は、本願の優先権主張の日前において周知・慣用の技術であった。
　
　したがって、引用発明において、「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」を「周期的に集約・加工」して生成するに際して、前記周知・慣用の技術のように、「管理目的」にあわせて複数種類生成することで、「標準」の「保持された標準のＭ４インタフェースのビューのＭＩＢの情報」を、複数種類の情報からなる「セット」をなす「情報」とすることは、当業者が容易に想到したと認められる。
　
　よって、前記相違点４は格別のものではない。
　
（２−４）審判請求人の主張
　審判請求人は、審判請求書において、請求の理由として、
「請求項１に記載された発明と引用文献１の記載内容とは、以下の点で相違する。 
 　（ａ）引用文献１は、一貫した健全性計量の要約されたセットを含む汎用的な出力または一貫した健全性計量の要約されたセットを含む汎用的な健全性計量を開示していない。また、引用文献１の記載内容は、図２に示したような一貫したサービス健全性計量を達成することとは無関係である。 
 　（ｂ）引用文献１は、該汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納することを開示していない。」、
と主張している。
　
　しかしながら、審判請求書の前記（ａ）の主張については、前記「（２−３）判断」の「（２−３−３）相違点４について」の項で述べたとおりである。
　また、前記（ｂ）の主張については、前記「（２−３）判断」の「（２−３−２）相違点２及び相違点３について」の項で述べたとおりである。
　
　一方、審判請求人は平成２３年１月１３日付けの回答書において、
「請求項１及び６に記載された発明の上記の特徴的な構成により、性能ツールの実現が計量抽出から切り離され、サービス、サービスの実現及び管理ツールセットの間の依存が取り除かれます。したがって、サービスの実現方法が変わっても、システム管理者は必ずしも、性能監視ツールの新しいバージョンをインストールする必要がありません。このように、本発明の装置及び方法は、管理ソフトウェアのより高位のレベルまで、依存を広めることなく拡張可能です（明細書の段落［００１３］）。 
 　このように、本発明の「一貫した健全性計量の要約されたセット」は、本発明の装置及び方法を管理ソフトウェアのより高位のレベルまで、依存を広めることなく拡張可能とするという技術的課題を解決するものです。 
 　これに対して、引用文献１は、上記の技術的課題とは無関係です。また、前置報告書において新たに示された、特開平０２−０６７６４６号公報は、システム性能数を標準的な尺度（メトリック）で表すことを開示していますが、同様に上記の技術的課題を開示も示唆もしていません。」、
と主張している。
　
　しかしながら、引用発明は、「取得した各ＮＥ装置を表現するオリジナルのＭＩＢを、その定義が同一であるかのように見せるため」ためのものである。そして、そのために、引用発明においては、「オリジナルのＭＩＢの属性値である性能データがあらかじめ周期的に集約・加工されて前記ビューのＭＩＢの情報として保持される」ことで、「ビューのＭＩＢの情報」が「標準のＭ４インタフェースのＭＩＢ定義に従う」ようにするものである。
　そして、管理「方法を管理ソフトウェアのより高位のレベルまで、依存を広めることなく拡張」することは、前記「（２−１）引用発明」において、「Ｃ」の「（２）上位レイヤの管理目的に応じたビューの提供」の項、及び、「Ｋ」の「６．４　ビュー提供方式の複数段適用」の項で列記したように、引用文献に記載された事項である。
　してみれば、前記本願明細書の段落【００１３】に記載の作用効果は、当業者であれば引用発明から予期し得たものと認められる。
　
　以上のとおりであるから、前記主張はいずれも当を得ておらず、これらを採用することができない。
　
（２−５）独立特許要件のまとめ
　以上のとおり、相違点は格別のものではない。そして、補正後の発明の効果も、引用発明から当業者が予測し得る範囲のものである。
　したがって、補正後の発明は、引用発明から当業者が容易に発明をすることができたものであるから、特許法第２９条第２項に規定により、特許出願の際独立して特許を受けることができるものではない。
　よって、本件補正は、特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　
　
３．小括
　以上のとおりであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、補正却下の決定の結論のとおり、決定する。
　
　
第３．本願発明について
１．本願発明
　平成２１年３月６日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２０年５月９日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「ホストマシンに常駐するサービスの健全性を動的に判断するための方法であって、
　健全性生成器が、サービスからサービス性能情報を収集し、
　前記健全性生成器が、記憶装置に格納された規則のセットに含まれる健全性生成アルゴリズムを使用して、収集されたサービス性能情報を汎用的な出力に変換し、
　該汎用的な出力を、複数の性能監視ツールの、該汎用的な出力へのインタフェースを提供するインタフェース・ライブラリに接続された共有記憶モジュールに格納する方法。」
　
　
２．引用発明
　引用発明は、前記「第２．平成２１年３月６日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「（２）独立特許要件」の「（２−１）引用発明」の項で認定したとおりである。
　
　
３．対比・判断
　本願発明は、補正後の発明が有する、
「該汎用的な出力は、サービスの現在の作業性能に関係し、該汎用的な出力は、該複数の性能監視ツールに提供される一貫した健全性計量の要約されたセットであり、健全性計量の導出に関する情報を、該複数の性能監視ツールに提供することなく、該複数の性能監視ツールに使用され得る該一貫した健全性計量の要約されたセットを含む」、
という発明特定事項を削除した発明である。
　そして、前記「第２．平成２１年３月６日付けの手続補正についての補正却下の決定」の「２．補正の適否」の「（２）独立特許要件」における「（２−１）引用発明」〜「（２−５）独立特許要件のまとめ」で検討したように、補正後の発明が引用発明に基づいて当業者が容易に発明をすることができたものであるから、補正後の発明から前記の発明特定事項を削除した発明である本願発明も、引用発明に基づいて当業者が容易に発明をすることができたものである。
　
　
４．むすび
　以上のとおり、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。