【事件の表示】
　特願２００１−３４９１７９「障害自動復旧機能を備えたリモート監視システム」拒絶査定不服審判事件〔平成１５年　５月２３日出願公開、特開２００３−１５０４０７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年１１月１４日の出願であって、平成１７年２月２８日付けで拒絶査定がなされ、これに対し、平成１７年４月７日に拒絶査定に対する審判請求がなされとともに、同年５月６日付けで手続補正がなされたところ、当審において、平成１９年７月１７日付けで最後の拒絶理由通知がなされ、これに対し、同年９月２５日付けで意見書が提出されたものである。
   
２．（１）本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１７年５月６日付け手続補正書により補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載されたとおりの次のものと認める。
「 【請求項１】　監視対象装置において生じた障害を自動的に復旧させる機能を備えたリモート監視システムであって、
　監視対象装置に対してネットワークを介して接続され、監視対象装置が通信可能であるかを調べると共に、前記監視対象装置から障害の発生を知らせる電子情報を受信し、通信可否を含む、監視対象装置の状態を示す情報を生成する個別監視装置と、
　前記個別監視装置において生成された監視対象装置の状態を示す情報に基づいて、当該監視対象装置において発生した障害の原因を解析し、その解析結果に基づいて、前記障害を回復するための電子情報を生成して、前記監視対象装置に送信する復旧指示装置と、
　前記個別監視装置が生成した監視対象装置の状態を示す情報に基づいて、当該監視対象装置をリモート監視する集中監視装置と、
　前記個別監視装置が生成した監視対象の状態を示す情報を送信する監視情報出力装置と、
　前記監視情報出力装置から送信された監視対象の状態を示す情報を受信して、前記集中監視装置に送る監視情報検出装置と、を備え、
　前記復旧指示装置は、障害の原因を解析および復旧処理を行う復旧処理部と、エラーコード、原因候補、および、エラーコードに対して各原因候補がその障害の原因である可能性を定量的に示すポイントを対応づけて記憶する原因テーブルと、原因と対策とを対応づけて記憶している対策テーブルと、を有し、前記復旧処理部は、前記監視対象装置の状態を示す情報として１以上のエラーコードを取得し、これらのエラーコードに基づいて、前記原因候補とそのポイントとを取得し、原因候補別にポイントを集計し、最もポイントが高いものを原因と定め、その原因に基づいて対策テーブルを検索して対策を決定し、その対策を実行するための修正プログラムを前記電子情報として生成し、
　前記監視情報出力装置と前記監視情報検出装置とは、監視情報出力装置から前記監視情報検出装置に一方向にのみ通信可能なプロトコルにより接続されることを特徴とする、障害を自動的に復旧させる機能を備えたリモート監視システム。」
　
（２）当審において平成１９年７月１７日付けで通知した最後の拒絶理由
　これに対して、当審において通知した上記最後の拒絶理由の概要は、次のようなものである。
　
「 １）本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　　　　　　　　　　　　　　　　　　記 
 １．特開平６−１２２８８号公報 
 ２．特開平２−９１７３５号公報 
 ３．特開２０００−１８１７３４号公報 
 ４．特開平４−１３６７９５号公報 
 ５．特開昭６３−５８５５３号公報 
  
 （中略）
 　 」
　
（３）引用例
　当審より拒絶の理由で通知した特開平６−１２２８８号公報（以下、「引用文献１」という。）には、次の事項が図と共に記載されている。
　
Ａ．「【００３１】図１に示す情報処理システムは、オンライン業務を行う複数の処理装置４−１，４−２と、前記処理装置の監視を行う監視装置２と、前記処理装置と前記監視装置を接続する通信手段３（例えばＦＤＤＩ）と、前記監視装置が収集した監視結果を表示する表示装置１（例えばＣＲＴディスプレイ装置）により構成される。
【００３２】処理装置４−１，４−２内の構成は同一であり、よって説明は処理装置４−１について行う。また、処理装置の重要項目送信手段と、自己監視結果送信手段は図１上ではそれぞれ複数存在するが、これらについては、後述する「６．複数の監視装置による監視方法」の項で説明を行うこととし、本項ではそれぞれ一つずつしかないものとして説明する。説明には重要項目送信手段６−１−１、及び自己監視結果送信手段７−１−１を用いる。
【００３３】処理装置４−１は、通常の処理装置としての構成のほかに、処理装置４−１自身の状態を監視し得られた監視情報を送信手段に渡す自己監視手段５−１と、監視情報のうち見逃してはならない重要なもののみを送信する重要項目送信手段６−１−１と、重要な監視情報も含めた全ての監視情報を送信する自己監視結果送信手段７−１−１の３種の構成要素を持つ。ここでいう監視情報とは、計算機等の処理装置の処理状態，障害メッセージ，ジョブ状態，ネットワーク（回線）状態などのシステム状態を表わす情報をいう。さらに、重要な監視情報とは、ＯＳ障害やハード障害を知らせるメッセージのように、それを見逃すことによりシステム全体、又はシステムの機能の一部が停止する可能性がある情報である。監視情報が重要か否かの判定は自己監視手段５−１が行い、判定の結果重要な監視情報であれば、重要項目送信手段と自己監視結果送信手段の両方に渡し、重要でない監視情報であれば自己監視結果送信手段のみに渡す。各送信手段は自己監視手段より渡された監視情報を監視装置２に対して送信する。送信方法については「４．監視情報の通信方式」の項にて詳細に示す。
【００３４】監視装置２は、処理装置４−１，４−２の重要項目送信手段６−１−１，６−２−１より送信された監視情報を受信する重要項目受信収集手段１３と、前記処理装置の自己監視結果送信手段７−１−１，７−２−１より送信された監視情報を受信する監視対象別監視結果受信手段１４−１，１４−２と、前記重要項目受信収集手段により収集した監視情報を表示装置１へ出力して表示する重要項目表示手段１２と、前記監視対象別監視結果受信手段により受信した監視情報を表示装置１に表示するために出力する監視対象別監視結果表示手段１５−１，１５−２の４種類の構成要素を持つ。この時、処理装置４−１の重要項目送信手段６−１−１から送信された監視情報と、処理装置４−２の重要項目送信手段６−２−１から送信された監視情報は、いずれも監視装置２の重要項目受信収集手段１３により受信され、重要項目表示手段１２により表示装置１上の重要項目表示Window１７に表示されるように出力される。また、処理装置４−１の自己監視結果送信手段７−１−１より送信された監視情報は監視装置２の監視対象別監視結果受信手段１４−１により受信され、監視対象別監視結果表示手段１５−１によって監視結果表示Window（処理装置１）１８−１に表示され、処理装置４−２の自己監視結果送信手段７−２−１より送信された監視情報は監視装置２の監視対象別監視結果受信手段１４−２により受信され、監視対象別監視結果表示手段１５−２によって監視結果表示Window（処理装置２）１８−２に表示される。前記監視対象別監視結果受信手段及び監視対象別監視結果表示手段及び監視結果表示Windowは監視対象となる処理装置の数と同数作成される。このように、監視対象毎に独立して受信手段，表示手段，表示Windowを持つことにより、監視装置がこれらの要素を一つしか持たない場合のように一つの処理装置からの大量な監視情報の受信表示のために前記３手段が占有されて、他の処理装置からの監視情報の受信遅れや受信漏れが発生することを防止できる。」
　
　以上の記載から、引用文献１には次の発明（以下、「引用発明」という。）が記載されている。
　
　処理装置の処理状態、障害メッセージ、ネットワーク状態などの監視情報によってネットワーク上の処理装置を監視するシステムであって、
　処理装置に対して通信手段を介して接続され、前記処理装置からの監視情報を受信し、監視対象別監視結果を生成する監視装置と、
　前記監視装置からの監視対象別監視結果に基づいて、当該処理装置の状態を表示する表示装置と、
　前記監視装置の監視対象別監視結果表示手段が前記監視対象別監視結果を表示装置に対して送信し、前記表示装置は前記監視対象別監視結果を受信して監視結果表示Ｗｉｎｄｏｗに表示することを特徴とするネットワーク上の処理装置を監視するシステム
　
　また、当審より拒絶の理由で通知した特開平２−９１７３５号公報（以下、「引用文献２」という。）には、図面と共に以下の事項が記載されている。
　
Ｂ．「分散ログファイル２５は実行監視部２１の指示に基づく実行状況データおよび復旧処理手続き部２３に基づく復旧手続きデータとを併わせ持つ。
　復旧手続きファイル２６は復旧処理知識ベース１５と同様に分散コンピュータ内に於ける各障害データとそれに対する復旧処理手続きデータとを併わせ持つ。
　第２図は上記リモート障害保守管理システムの動作を示す流れ図である。
　まず、分散コンピュータ２０でプログラムの実行が為されている時に（ステップ３１）、実行監視部２１がこれを監視する。ここで何らかの障害が発生した時、実行監視部は障害発生通知（第３図参照）障害解析処理部２２に送る。障害解析処理部２２では分散ログファイル２５および復旧手続きファイル２６とによりその障害レベルを判断する（ステップ３２，３３．３４）。
　ここで判定された障害レベルの値（０・・・障害レベル小、１・・・障害レベル大）により、その分散コンピュータ内だけでの障害復旧処理で済むか、それともホストコンピュータからの指示を受けるかのどちらかの処理手続きを踏む。すなわち、障害レベルが０の時には、障害解析処理部２２が復旧手続きファイル２６を基に記録しておいた分散ログファイル２５を復旧処理手続き部２３が参照して実行する（ステップ３５）。また、障害レベルが１の時には、障害解析処理部２２はホスト連絡部２４に障害発生通知を行ない、ホスト連絡部２４は回線を径由してホストコンピュータ１０にこれをそのまま伝える（ステップ３６）。」
　
　上記Ｂによれば、検出した障害に応じて、障害の発生したコンピュータ内だけで障害復旧処理を行う技術（以下、「引用文献２の記載事項」という。）が、示されている。
　
　また、当審より拒絶の理由で通知した特開平４−１３６７９５号公報（以下、「引用文献３」という。）には、図面と共に以下の事項が記載されている。
　
Ｃ．「原因推定手段１３は、異常検出装置４で異常が検出された場合、あるいは調査情報入力装置５で原因推定の要求を行なった場合に動作し、前述の検出された異常現象に関する情報および調査情報を入力する。さらに、これらの情報を基に知識ベース１２に蓄積された現象と原因の因果関係を表わす知識ベースを用いて異常原因の推定が行なわれる。このような知識ベースの構築手法（知識表現方法）については、種々の提案がなされているが、代表的なものとして、マトリックス型の知識表現がある。例えば、特開昭６３−１２０９３号公報および特開昭６３−１２０９２号公報では、それぞれ第５図および第６図のような形式のものが使用されている。
　ここで、第５図の場合には、原因「Ｃ1」と現象「Ｐ1」の関係は「１０（％）」と表現し、「Ｃ1」であれば「Ｐ1」が発生する確率は１０％であることを意味している。これより、現象「Ｐ1」が発生すれば原因「Ｃ1」、「Ｃ2」、「Ｃ3」、「Ｃ4」である可能性はそれぞれ１０（％）、９１（％）、２５（％）、０（％）と推定され、複数の現象が発生した場合は、確率の加算が行なわれる。
　また、第６図の場合は、原因「Ｃ1」と現象「Ｐ1」の関係は「△」と表現し、「Ｃ1」であれば現象「Ｐ1」は発生する場合もあり、発生しない場合もある。原因「Ｃ1」と事象「Ｐ2」の関係は「○」であり、「Ｃ1」であれば現象「Ｐ2」は必ず発生する。原因「Ｃ1」と現象「Ｐ３」の関係は「×」であり、「Ｃ1」であれば現象「Ｐ3」は絶対に発生しないことを表わす。これより、現象「Ｐ1」が発生すれば、原因「Ｃ4」である可能性は無くなり原因「Ｃ2」または「Ｃ3」であると推定されることになる。この場合には、第５図のように原因の可能性を数値で求める必要が無いので、原因の候補を素早く絞り込みたい時に適する原因推定手法と言うことができる。第５図あるいは第６図に示すような従来技術に基づく知識ベースの表現方法は因果マトリックスとして良く知られており、ここでは、第５図を数値表現型、第６図を記号表現型と名付けておく。」（公報２頁左上欄１８行〜左下欄１７行）
　
　上記Ｃの記載によれば、異常原因を追及する手法として、現象と原因の関係が確率で示され、複数の現象が発生したときに確率の加算により原因を追及する異常原因追及手法（以下、「引用文献３の記載事項」という。）が示されている。
　
　また、当審より拒絶の理由で通知した特開昭６３−５８５５３号公報（以下、「引用文献４」という。）には、図面と共に以下の事項が記載されている。
　
Ｄ．「第１図は、本発明の一実施例の構成を示す概略図である。図において、・・・・・・・・・・・６はコード組み合わせテーブル、７は原因メッセージテーブル、８は対策メッセージテーブルである。
　第２図は、処理内容を説明するフローチャートである。
・・・・・・・・・・
　即ち、ステップ２２において、コード組合せテーブル６からエラー識別コードに対応する原因コードを先ず取出す。
　次に、ステップ２３において、その原因コードに対応する原因メッセージ文を原因メッセージテーブル７から取出す。この時、エラー復旧の対策を示す対策コードも合わせて取出す。
　最後にステップ２４において、対策コードに対応するため対策メッセージ文を対策メッセージテーブル８から取出す。」（公報２頁右上欄１２行〜左下欄１４行）
　
　上記Ｄの記載によれば、原因メッセージテーブルと対策メッセージを別個に有し、原因メッセージテーブルから取り出された対策コードにより対策メッセージテーブルから対策メッセージを取り出す手法（以下、引用文献４の記載事項」という。）が示されている。
　
　また、当審より拒絶の理由で通知した特開２０００−１８１７３４号公報（以下、「引用文献５」という。）には、図面と共に以下の事項が記載されている。
　
Ｅ．「【００１４】保守センタ−２の障害対処部２１は、上述のように、ユ−ザシステム１から受け取った障害サマリ情報と図７の障害管理デ−タベ−ス２２とを用いて障害ＩＤを特定した上で、この障害ＩＤに対応のプログラム修正情報を図８のプログラム修正デ−タベ−ス２３から求め、これをユ−ザシステム１に送付している。」
　
　上記Ｅの記載によれば、障害ＩＤに対応するプログラム修正情報により障害に対処すること（以下、「引用文献５の記載事項」という。）が示されている。
　
（４）対比
　本願発明と引用発明とを対比すると、
　引用発明の「処理装置」「通信手段」「監視情報」「監視対象別監視結果」は、それぞれ、本願発明の「監視対象装置」「ネットワーク」「障害の発生を知らせる電子情報」「監視対象装置の状態を示す情報」に相当する。
　本願発明の障害を自動的に復旧させる機能を備えたリモート監視システムは、集中監視装置では監視結果を表示するものであるので、引用発明の「ネットワーク上の処理装置を監視するシステム」とは、監視対象装置をリモート監視するシステムである点で一致している。
　引用発明の「監視装置」と本願発明の「個別監視装置」とは、本願発明の監視対象装置が通信可能かどうか調べる点を除いて、引用発明の「監視装置」と対応している。
　引用発明では、監視情報にネットワーク状態が含まれ、このネットワーク状態は処理装置の自己監視手段が取得するものであるから、本願発明における監視対象装置が通信可能であるかを調べる点については、引用発明では処理装置が行っていることになる。
　本願発明の集中監視装置が行うリモート監視というのは、監視対象装置の監視結果を表示するものであるから、本願発明の集中監視装置は引用発明の表示装置と実質的に同等のものである。
　引用発明では、監視装置から表示装置に監視対象別監視結果が送信され、表示装置に表示されるから、監視装置と表示装置に間には監視対象別監視結果を送るための送受信手段が存在しており、本願発明の「監視情報出力装置」および「監視情報検出装置」とは、インターフェース手段を有する点で一致している。
　
  よって、本願発明と引用発明とは、
　
　監視対象装置をリモート監視するシステムであって、
　監視対象装置に対してネットワークを介して接続され、前記監視対象装置から障害の発生を知らせる電子情報を受信し、監視対象装置の状態を示す情報を生成する個別監視装置と、
　前記個別監視装置が生成した監視対象装置の状態を示す情報に基づいて、当該監視対象装置をリモート監視する集中監視装置と、
　前記個別監視装置が生成した監視対象の状態を示す情報を前記集中監視装置に送るインターフェース手段とを、
　備えたリモート監視システム
　
である点で一致し、次の点で相違する。
　
相違点１
　監視対象装置をリモート監視するシステムが、本願発明では復旧指示装置を有し監視対象装置の障害を自動的の復旧させる機能を有するものであるのに対し、引用発明では監視対象装置の状態を表示するためのものである点
　なお、本願発明の復旧指示装置は、障害の原因を解析および復旧処理を行う復旧処理部と、エラーコード、原因候補、および、エラーコードに対して各原因候補がその障害の原因である可能性を定量的に示すポイントを対応づけて記憶する原因テーブルと、原因と対策とを対応づけて記憶している対策テーブルと、を有し、前記復旧処理部は、前記監視対象装置の状態を示す情報として１以上のエラーコードを取得し、これらのエラーコードに基づいて、前記原因候補とそのポイントとを取得し、原因候補別にポイントを集計し、最もポイントが高いものを原因と定め、その原因に基づいて対策テーブルを検索して対策を決定し、その対策を実行するための修正プログラムを前記電子情報として生成するものである。
　
相違点２
　監視対象装置が通信可能であるか調べるものが、本願発明では、個別監視装置であるのに対し、引用発明では監視対象装置である点
　
相違点３
　監視対象の状態を示す情報を個別監視装置から集中監視装置に送るインターフェース手段が、本願発明では監視情報出力装置と監視情報検出装置からなり、一方向にのみ通信可能なプロトコルであるのに対し、引用発明では監視対象別監視結果表示手段が前記監視対象別監視結果を表示装置に対して送信し、前記表示装置は前記監視対象別監視結果を受信して表示するものである点
　
（５）検討
相違点１について
　社団法人電子情報通信学会編　電子情報通信ハンドブック　昭和６３年３月３０日第１版第１刷発行、オーム社、Ｐ１８１２−Ｐ１８１５には、保守管理として、本体系障害処理、入出力装置系障害処理、構成制御、ソフトウエア障害処理、オンライン保守について記載され、これによれば、本体系障害処理、入出力装置系障害処理、構成制御、ソフトウエア障害処理は個別装置が独自に障害回復を行うものであり、オンライン保守とは、ユーザシステムの障害回復を遠隔から行うものである。このように、障害回復は基本的には個別装置が独自に行うものであり、オンライン保守では更に保守センタから介入して障害回復の精度を高めるものである。上記した引用文献２の記載事項では障害の種類に応じて障害の発生した装置内だけで障害回復を図ったり、遠隔から介入して障害回復を図る技術が示されている。従って、遠隔保守システムにおいて、センタから介入するような高度な障害回復を図らずに障害の発生した装置内だけで障害回復を図るという基本的な障害回復を行うことは必要に応じて為されることである。
　また、障害回復のための装置として、本願発明では復旧指示装置の具体的構成を規定しているが、異常現象からその原因を追及し障害回復のための修正情報を作成するための構成は、上記引用文献３，４，５の記載事項に示されるように、従来より周知のものであるから、この復旧指示装置の具体的構成を格別のものと言うことはできない。
　
相違点２について
　引用発明においては、ネットワークの状態についても処理装置の状態と同様に処理装置側で検出し、その結果を監視情報として監視装置に送信しているから、監視装置側では監視情報を調べることによりネットワークの状態を知ることが出来る。また、ネットワークが通信可能でなければそもそも監視情報では受け取ることが出来ないから、監視装置は通信可能かどうか知ることが出来るものである。従って、この相違点２を格別のものということはできない。
　
相違点３について
　装置間でデータを伝送するためのインターフェース手段には、データを双方向で伝送するもの（特開平９−１６２９９号公報参照）や、データを単方向で伝送するもの（実願昭５８−８１１３４号（実開昭５９−１８７２５４号公報）のマイクロフィルム）がある。そして、引用発明のように監視対象別監視結果を表示装置に表示するためのインターフェース手段としてはデータを単方向で伝送する形態のものを採用することが通常のことである。単方向伝送のインターフェース手段では出力側に出力ドライバをもち、入力側に入力レシーバを有することになるから、この出力ドライバおよび入力レシーバが本願発明の監視情報出力装置および監視情報検出装置に対応することになる。そして、信号は出力ドライバから入力レシーバに一方向に伝送されることになるから、本願発明ように一方向にのみ通信可能なプロトコルを用いる点も格別のことということはできない。
　
　なお、請求人は、平成１９年９月２５日付け意見書において、
「（２）一方向プロトコル
　本発明において他の重要な点は、監視情報出力装置と監視情報検出装置とが、一方向にのみ通信可能なプロトコルにより接続されていること、にあります。すなわち、本発明は、００２０段落において記載されていますように、「監視情報出力装置３３および監視情報検出装置３４は、監視情報出力装置３３から監視情報検出装置３４への一方向にのみ通信可能なプロトコルで接続されている。したがって、監視情報検出装置３４から監視情報出力装置３３へ何らかの情報を転送することはできない。」構成となっています。これにより、「ユーザシステム３１を含むネットワークに対して、外部のネットワーク９からの不正浸入を防止することができる。」という顕著な効果を奏します。」と主張している。
　しかしながら、本願発明において、「監視情報出力装置」から「監視情報検出装置」に送られて、その後における集中監視装置での利用は、明細書の記載によれば監視対象装置の状態を示す情報を表示するだけであるから、引用発明と同様に単方向の伝送インターフェースを用いることはごく自然な形態であり、一方向の伝送であれば逆方向への不正進入を阻止できることは単方向インターフェースが当然有する効果にすぎないものである。
　
３．むすび
　したがって、本願発明は、引用文献１−５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。