【事件の表示】
　平成１１年特許願第２４１９０２号「障害連絡到着通知システム」拒絶査定不服審判事件〔平成１３年　３月１６日出願公開、特開２００１−　６７２８４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１１年８月２７日の特許出願されたものであって、平成１５年４月１１日付で拒絶査定がなされ、これに対して、平成１５年５月１５日に拒絶査定に対する審判請求がなされるとともに、平成１５年６月１３日付で手続補正がなされたものである。
　
２．平成１５年６月１３日付の手続補正について
　平成１５年６月１３日付の手続補正（以下「本件補正」という。）について、以下のとおり決定する。
　
［結論］
　平成１５年６月１３日付の手続補正を却下する。
　
［理由］
(１)補正後の本願発明
　本件補正により、少なくとも特許請求の範囲の請求項１について、以下のとおり補正するものである。
「ネットワークにより接続された複数のサイトと、
　前記複数のサイトの各々に設けられた業務サーバと、
　前記複数のサイトの少なくとも１つに設けられた障害連絡受付サーバと、
　前記障害連絡受付サーバが設けられたサイトの少なくとも１つに設けられた稼働確認サーバと、
　前記障害連絡受付サーバ及び前記稼働確認サーバのそれぞれに接続された複数種類の警報装置とを備え、
　前記複数種類の警報装置の稼働時には前記警報装置の種類はオペレータにより識別可能なものであり、
　前記業務サーバと、前記障害連絡受付サーバと、前記稼働確認サーバとのいずれかに障害が発生すると、電子メール及びファイル転送プロトコルのいずれかにより該障害を障害が発生しているサーバ以外の前記障害連絡受付サーバ及び前記稼働確認サーバの少なくとも１つが検知し、
　前記業務サーバは前記障害連絡受付サーバの少なくとも１つに対して一定時間間隔毎に稼働確認データを電子メール及びファイル転送プロトコルのいずれかにより送信し、
　前記障害連絡受付サーバ及び前記稼働確認サーバは、前記障害の検知時に、障害の種類に応じた種類の警報装置を駆動し、且つ、
　前記障害連絡受付サーバは、前記稼働確認データを前記一定時間間隔毎に受信しなくなると前記稼働確認データに対応した種類の警報装置を駆動するようにし、前記電子メール及びファイル転送プロトコルのいずれかにより受信した該障害連絡の内容が前記警報装置の駆動により障害連絡があったことを認識したオペレータにより受信されることにより警報装置の駆動を終了することを特徴とする障害連絡到着通知システム。」
　
　本件補正についてその内容をみると、この補正は、請求項１に記載した発明を特定するために必要な事項である「障害連絡受付サーバ」による警報装置の駆動において「前記電子メール及びファイル転送プロトコルのいずれかにより受信した該障害連絡の内容が前記警報装置の駆動により障害連絡があったことを認識したオペレータにより受信されることにより警報装置の駆動を終了すること」の限定を付加するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際、独立して特許を受けることができるものであるか否か（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか否か）について、以下に検討する。
　
（２）引用例
　原査定の拒絶の理由に引用された、本願の出願の日前である平成６年３月１１日に頒布された「特開平６−６８００２号公報」（以下、「引用刊行物１」という。）には、その実施例及び図面の記載を参酌すると、以下のとおりの技術的事項が記載されている。
　
（2-1）「【００１６】【実施例】以下、本発明の実施例を図面を用いて詳細に説明する。　図１は本発明のネットワーク管理システムの第１実施例を示すブロック図である。このシステムは、１台の管理システム１０と、複数台の管理対象システム２０のうちの１台を示しており、管理システム１０と管理対象システム２０とはネットワークを介して接続されている。
【００１７】図２に、その接続関係を示す。即ち、管理システム１０と複数台の管理対象システム２０（２０−１、２０−２、…２０−ｎ）は、ＬＡＮ（ローカル・エリア・ネットワーク）あるいはＷＡＮ（ワイド・エリア・ネットワーク）等のネットワーク３０に接続されている。ここで、管理システム１０はパーソナルコンピュータやワークステーション等からなり、管理対象システム２０は、種々の情報処理装置、例えば、通信交換機、伝送路の多重化装置あるいはモデム等から構成されている。
【００１８】図１において、管理システム１０は、管理システム側情報転送手段１１と、管理システム側共通／個別情報管理手段１２と、管理システム側記録情報管理手段１３と、管理システム識別手段１４と、情報格納索出手段１５と、マンマシンインタフェース１６と、共通／個別情報作成手段１７と、記録情報編集出力手段１８とを備えている。また、管理対象システム２０は、情報転送手段２１と、共通／個別情報管理手段２２と、記録情報管理手段２３と、管理対象システム識別手段２４とを備えている。
【００１９】管理システム１０における管理システム側情報転送手段１１は、複数の管理対象システム２０−１、２０−２、…２０−ｎへの通信制御を行うものであり、管理システム側共通／個別情報管理手段１２は、複数の管理対象システム２０−１、２０−２、…２０−ｎの各々に共通のデータと、各々に固有のデータとを管理する機能を有している。管理システム側記録情報管理手段１３は、それぞれの管理対象システム２０−１、２０−２、…２０−ｎが記録した情報を収集管理するものである。また、管理システム識別手段１４は、各々の管理対象システム２０−１、２０−２、…２０−ｎに対して自アドレス（管理システム１０のネットワーク３０におけるアドレス）を同報する機能を有している。
【００２０】情報格納索出手段１５は、管理システム２０に関する種々の管理情報等を格納したデータベースである管理情報ベース４０に対して、そのファイルへの書込み／読出しを管理するためのものである。マンマシンインタフェース１６は、キーボードやディスプレイ等からなり、管理システム１０としての入出力装置である。共通／個別情報作成手段１７は、このマンマシンインタフェース１６により共通／個別情報を作成するためのものである。記録情報編集出力手段１８は、収集した記録情報をマンマシンインタフェース１６を通して表示させるためのものである。」（第４頁左欄第７行〜右欄第８行，図１，２を参照。）
（2-2）「【００２２】記録情報管理手段２３は、自システムで発生する障害情報、収集する性能情報を記録し、かつ情報転送手段２１を介して管理システム１０に送るためのものである。尚、性能情報とは、管理対象システム２０のＣＰＵの稼働率、ファイルの使用頻度、回線の使用率等の情報である。管理対象システム識別手段２４は、各々の管理対象システム２０−１、２０−２、…２０−ｎをネットワーク３０上のアドレスによって識別するものであり、その管理対象システム２０に固有のアドレスを管理している。
【００２３】このように構成されたシステムは、管理システム１０によって複数の管理対象システム２０を管理する。また、共通／個別情報は管理システム１０から管理対象システム２０に転送されるのが普通であるが、管理対象システム２０がローカルに個別情報を変更した場合は、その管理対象システム２０の共通／個別情報管理手段２２が個別情報を管理システム１０に転送する。そして、管理システム１０側では、管理システム側記録情報管理手段１３がこれを収集し、情報格納索出手段１５を介して管理情報ベース４０に格納する。また管理対象システム２０で発生する障害情報や収集される性能情報は、管理対象システム２０が自律的に管理システム１０に転送する方法と、管理システム１０が定期的に収集要求を管理対象システム２０に発行し、情報を収集する方法とがある。」（第４頁右欄第２０〜４４行，図２を参照。）
（2-3）「【００３２】次に第３実施例を説明する。図７は、その構成図である。このシステムは、相互予備方式であり、２つのネットワークを管理する各々の管理システム７０ａ、７０ｂが、お互いに相手を監視し、相手の障害時には代替を行うようにしたものである。即ち、管理システム７０ａ（図中、Ｍ１で示す）は、管理対象システム２０ａ−１〜２０ａ−ｎを管理し、管理システム７０ｂ（図中、Ｍ２で示す）は、管理対象システム２０ｂ−１〜２０ｂ−ｎを管理している。
【００３３】また、管理システム７０ａ、７０ｂの構成においては、図４に示したものと同様であるが、予備管理システム６０と基本管理システム５０の両方の機能を各々の管理システム７０ａ、７０ｂが持っている。また、その動作においても、図５、図６で示した双方の監視手段１９ａ、１９ｂの動作を行えるように構成されている。」（第５頁右欄第３１〜４６行，図７を参照。）
（2-4）「【００３９】次に第６実施例を説明する。図９は、（ｎ＋ｍ）待機予備方式２のネットワーク構成を示すもので、ｎ個の基本管理システム５０（５０−１〜５０−ｎ）に対してｍ個の予備管理システム６０（６０−１〜６０−ｍ）を備えていることは上記第４、５実施例と同様である。また、管理対象システム２０（２０ａ−１〜２０ｎ−ｎ）と基本管理システム５０（５０−１〜５０−ｎ）との関係も上記第４、５実施例と同様である。
【００４０】上記第４、５実施例と異なる点は、待機予備分割管理方式として、基本管理システム５０（５０−１〜５０−ｎ）を、地域的またはネットワーク種別によりグループ化しておき、そのグループに対応して予備管理システム６０（６０−１〜６０−ｍ）を割り当てることである。例えば、図示した例では、基本管理システム５０−１〜５０−１０に予備管理システム６０−１が割り当てられ、基本管理システム５０−１１〜５０−２０に予備管理システム６０−２が割り当てられているといったグループ化が行われている。
【００４１】そして、このような構成において、各予備管理システム６０は、グループ内の基本管理システム５０を監視し、グループ内の基本管理システム５０の障害を検出した場合はその代替を行う。例えば、図示のように、基本管理システム５０−１に障害が発生した場合、予備管理システム６０−１がその代替を行う。また、ここで、障害が発生した基本管理システム５０−１の代替とグループ内の正常な基本管理システム５０−２〜５０−１０の監視を両方行う方式と、正常な基本管理システム５０−２〜５０−１０の監視は他の予備管理システム６０−２〜６０−ｍに依頼する方式があり、図示例では他の予備管理システム６０−２〜６０−ｍに依頼する方式を示している。」（第６頁右欄第１０〜４０行，図９を参照。）
（2-5）「【００４２】次に第７実施例を説明する。この第７実施例は、基本管理システム５０の監視を行い、基本管理システム５０のいずれかが障害となった場合は、その基本管理システム５０の代替を行うと共に、複数の基本管理システム５０の監視も行う統合管理システム８０（図中、ＭＭで示す）を備えた階層化方式の構成としたものである。図１０はその階層化方式のネットワーク構成図、図１１は、統合管理システム８０と基本管理システム５０の内部構成図である。
【００４３】このような階層化方式においては、図１０に示すように、複数の基本管理システム５０（５０−１〜５０−ｎ）を、一つの統合管理システム８０で一括して管理する。即ち、基本管理システム５０を監視するために、上位システムとして統合管理システム８０を備え、統合管理システム８０は監視手段１９ｃによって全基本管理システム５０を常時監視しており、障害を検出したら代替を行う。また、代替中も障害の発生した基本管理システム５０の復旧監視とその他の正常な基本管理システムの監視を続け、複数の管理システム５０の障害検出、代替を可能としたものである。図１０に示した例では基本管理システム５０−１が障害を起こした場合を示している。」（第６頁右欄第４１行〜第７頁左欄第１２行，図１０，１１を参照。）
　
　引用刊行物１には、中核となる構成を持つ第１実施例に種々の構成を付加した複数の実施例が記載されており、この付加した構成についてそれぞれ適宜組み合わせた構成も引用文献１において開示されていることは明かであるから、（2-1）〜（2-5）の記載事項及び図１，２，７，９〜１１によると引用刊行物１には、
「グループ化されたネットワークにより接続された複数の管理対象システム２０（２０ａ−１，２０ａ−２，・・・２０ｎ−ｎ）（種々の情報処理装置）と、管理システム１０若しくは基本管理システム５０（５０−１〜５０−ｎ）と、予備管理システム６０もしくは統合管理システム８０を備え、
　管理対象システム２０が自システムで発生する障害情報や性能情報を記録し、情報転送手段２１を介して管理システム１０に送る手段を持ち、
　管理対象システム２０で発生する障害情報や性能情報は、管理対象システム２０が自律的に管理システム１０に転送する方法と、管理システム１０が定期的に収集要求を管理対象システムに発行し情報を収集する方法があり、
　予備管理システム６０は、グループ内の基本管理システム５０を監視し、グループ内の基本管理システム５０の障害を検出した場合はその代替を行う手段、もしくは、
　管理システム７０ａ，７０ｂがお互いに相手を監視し、相手の障害時には代替を行う手段、もしくは、
　統合管理システム８０は監視手段によって基本管理システム５０を常時監視しており、障害を検出したら代替を行う手段を持ち、
　（基本）管理システム１０，５０は収集した記録情報をマンマシンインターフェース１６を通して表示させる構成の障害システム」の発明（以下、「引用刊行物１記載の発明」という。）が記載されていると認められる。
　
　
　原査定の拒絶の理由に引用された、本願の出願の日前である平成５年６月１８日に頒布された「特開平５−１５１１２５号公報」（以下、「引用刊行物２」という。）には、次の事項が記載されている。
（2-6）「【請求項１】　通信回線を介して、ホスト装置との間でデータの送受信を行う端末装置において、
　前記ホスト装置との間でデータの送受信を行ってからの経過時間をカウントする計時手段と、
　その計時手段のカウント値が所定の値に達したときに、前記ホスト装置に対して信号を発する発信手段と
　を備えたことを特徴とする端末装置。」（第２頁左欄第２〜８行）
（2-7）「【００２１】【発明の効果】 以上説明したことから明かなように、本発明の端末装置によれば、端末装置からホスト装置に対して、端末装置の稼動状況を定期的に送信することが可能となるので、ホスト装置は端末装置の稼働状況を容易に把握することができる。」（第３頁右欄第２９〜３４行）
　
　原査定の拒絶の理由に引用された、本願の出願の日前である平成８年１１月１日に頒布された「特開平８−２８６９９０号公報」（以下、「引用刊行物３」という。）には、次の事項が記載されている。
（2-8）「【００２１】【作用】本発明では、計算機の障害情報を電子メールで中央監視装置に通知する。関した衣装の計算機側において、電子メール作成装置は、障害情報を電子メールで通知する際、当該障害の種類に応じた処理属性情報を通知先情報とともに電子メールの通知先メールボックス名に含めてメールボックスの指定を行うようにしたので、中央監視装置は、自己宛の全ての電子メールの中から、その処理属性に応じた優先度で電子メールを取り出して障害対策支援処理を行うことができる。したがって、より重要度の低い障害情報に比べて、重要度の高い障害情報障害を優先して処理でき、監視システムの効率的な運用が可能となる。
【００２２】また、中央監視装置側の電子メール受付装置では、電子メールを、その通知先メールボックス名の処理属性に応じて別個のメールボックスに格納するので、各電子メールの中身を参照することなく、分類格納処理が行える。
【００２３】メールボックス名に含める通知先として中央監視装置以外の通知先を指定することにより、中央監視装置を介さず直接、担当者あるいは該当部署等に処理を依頼することも可能となる。
【００２４】発生した障害の種類または要因に対応してその障害の通知先および処理属性を予め定めた通知先テーブルを設けることにより、当該障害情報の電子メールの通知先および処理属性を自動的に決定することができる。
【００２５】本発明の電子メールによる障害監視システムは、従来のＳＶＰを用いるシステムと併用することができる。」（第３頁右欄第１８〜４７行）
　
　原査定の拒絶の理由に引用された、本願の出願の日前である平成１０年１２月４日に頒布された「特開平１０−３２２３３３号公報」（以下、「引用刊行物４」という。）には、次の事項が記載されている。
（2-9）「【００３９】図４は、測定値システム７０によってシステム６０の諸モジュールから収集される測定値を示す。図４に示されるように、測定値は、システム６０の１つまたは複数のモジュールに連係して動作する監視機構７４−７９を通して収集される。監視機構の各々は、１つの測定ルートに対応して配置される。異なる監視機構から収集される測定値は、(ＦＴＰ、遠隔プロシージャ呼び出し、単純なネットワーク管理プロトコルなどの)プロトコルの組合せを使用して、測定システム７０へ伝送される。使用されるプロトコルの選択は、その能力、監視機構によって行われる測定のタイプ、機構容量および測定の頻度に応じて、各監視機構に特有のものである。」（第７頁左欄第２４〜３５行，図４参照）
　
（３）対比
　
（対比）
　本願補正発明と引用刊行物１記載の発明を対比すると、引用刊行物１記載の発明の「管理対象システム２０」は本願補正発明の「業務サーバ」に相当する。そして、ネットワークをどのようにグループ化（サイト化）するかは当業者が適宜設計する設計的事項であり、引用刊行物１記載の発明において、管理システムが他の管理システムの監視をし障害時に代替するためには障害情報が転送されることは明かであることから、「統合管理システム」は「基本管理システム」の障害情報を受け付けることも明かである。このことから、引用刊行物１記載の発明の「基本管理システム」，「統合管理システム」はそれぞれ本願補正発明の「障害連絡受付サーバ」，「稼働確認サーバ」に相当する。
　また、引用刊行物１記載の発明は、障害情報をマンマシンインターフェース１６を介して表示する構成であるから、障害発生時にオペレータに“障害情報を提示する装置”である点で本願発明の「警報装置」と同じものであり、引用刊行物１の「統合管理システム」は同じマンマシンインターフェース１６があることから「統合管理システム」にも同様の機能である「警報装置」があるものと認められ、障害発生時にオペレータに情報を提示する点で引用刊行物１記載の発明は本願補正発明の「障害連絡到着通知システム」と同じである。
　したがって、両者は、以下のとおりの一致点及び相違点を有するものと認められる。
　
（一致点）
「ネットワークにより接続された複数のサイトと、
　前記複数のサイトの各々に設けられた業務サーバと、
　前記複数のサイトの少なくとも１つに設けられた障害連絡受付サーバと、
　前記障害連絡受付サーバが設けられたサイトの少なくとも１つに設けられた稼働確認サーバと、
　障害連絡受付サーバ及び稼働確認サーバのそれぞれに接続された障害情報を提示する装置とを備え、
　前記業務サーバと、前記障害連絡受付サーバと、前記稼働確認サーバとのいずれかに障害が発生すると、該障害を障害が発生しているサーバ以外の前記障害連絡受付サーバ及び前記稼働確認サーバの少なくとも１つが検知し、
　前記業務サーバは前記障害連絡受付サーバの少なくとも１つに対して一定時間間隔毎に稼働確認データを送信し、
　障害連絡受付サーバおよび前記稼働確認サーバは障害の検知時に障害情報を提示する
　障害連絡到着通知システム。」
　
（相違点）
(3-1)本願補正発明においては、“障害連絡受付サーバ及び稼働確認サーバのそれぞれに接続された複数種類の警報装置とを備え、前記複数種類の警報装置の稼働時には前記警報装置の種類はオペレータにより識別可能なものであり、前記障害連絡受付サーバ及び前記稼働確認サーバは、前記障害の検知時に、障害の種類に応じた種類の警報装置を駆動し、且つ、前記障害連絡受付サーバは、前記稼働確認データを前記一定時間間隔毎に受信しなくなると前記稼働確認データに対応した種類の警報装置を駆動するようにし、前記電子メール及びファイル転送プロトコルのいずれかにより受信した該障害連絡の内容が前記警報装置の駆動により障害連絡があったことを認識したオペレータにより受信されることにより警報装置の駆動を終了する構成の障害連絡通知システム”であるのに対して、引用刊行物１に記載の発明はマンマシンインターフェースを介して表示するのみであり、そのような構成が付加されていない点。
　
(3-2)本願補正発明は、業務サーバが自ら稼働確認データを一定時間間隔毎に送信するのに対して、引用刊行物１記載の発明は、他の装置より一定時間間隔毎に送信を指示されて稼働確認データを送信する点。
　
(3-3)本願補正発明においては、障害通知や稼働確認データを“電子メール及びファイル転送プロトコルのいずれかにより”送受信しているのに対して、引用刊行物１記載の発明ではどのような手段で障害通知や稼働確認データを送受信するのか特定されていない点。
　
（４）検討
　上記相違点(3-1)〜(3-3)について検討する。
　
相違点(3-1)について
　本願補正発明において、「障害連絡があったことを認識したオペレータにより受信される」とあるが、オペレータが受信する構成は請求項１に記載されておらず、何によって受信するのか不明確ではあるが、発明の詳細な説明の記載を参酌するに、オペレータが障害連絡の内容を（メール等により）認識したことであると認められる。
　一般に、オペレータがどのような種類の警報であるか識別可能とするために複数の種類の警報手段を用いることは、例えば「特開平１０−３２７１５４号公報（拒絶査定時に周知文献として提示。）」，「特開平９−１８５４６号公報（拒絶査定時に周知文献として提示。）」に記載されているように、周知慣用技術である。
　そして、発した警報を終了させる構成が必要なことは明かであり、オペレータが障害を認知し障害の内容（異常の内容）を確認した後に警報の駆動を終了させる構成は、「特開平９−２８２０２７号公報（特に【0033】〜【0039】参照）」，「特開平９−２８８７９１号公報（特に【0067】参照）」に記載されるように周知慣用技術であり、警報を認識したユーザが行う必要のある動作と連動して警報を終了させることも、例えば「特開平７−３２５９７１号公報（特に【0024】参照）」に記載されているように周知慣用技術である。
　また、未読メールがある場合はユーザに警告を発し、メールを開封する動作により警告を解除することは、例えば「特開平１１−１５４９７５号公報」に記載されているように周知慣用技術であり、留守番電話機で留守番電話がある際は警告を表示しユーザが留守番電話（その警告の詳細な情報）を確認するまで表示し続けることも、周知慣用技術である。
　さらに、警告と警告の詳細内容をオペレータに別々に提示することは「特開平５−８７５９９号公報」に記載されているように周知慣用技術である。
　上記の複数の周知慣用技術はすべてオペレータやユーザに警報や警告を示すための技術であり、これらの周知慣用技術をどのように組み合わせるかは当業者が必要に応じて適宜選択する程度の設計的事項である。
　以上のことから、引用刊行物１に記載の発明にこれら周知慣用技術を適宜組み合わせることは当業者が容易になし得るものと認められる。
　また、組み合わせたことによる作用効果も、当業者が予測し得る程度のものであって格別のものとは認められない。
　
相違点(3-2)について
　ホスト装置に対して、端末装置から稼働確認データを一定時間毎に送信することは、例えば引用刊行物２に記載されているように、周知慣用技術であり、引用刊行物１記載の発明において稼働確認データを一定時間間隔毎に発するために送信側でタイミングを計るか、受信側でタイミングを計り指示するかは、実施に当たり適宜選択する程度の設計的事項である。
　
相違点(3-3)について
　ネットワーク上において、データを転送する際に電子メールやファイル転送プロトコルを用いることは、引用刊行物３および４に記載されているように、周知慣用技術である。
　引用刊行物１記載の発明において、情報を転送する際に、電子メールやファイル転送プロトコルを用いることは、当業者が必要に応じて適宜選択する程度の設計的事項である。
　
　
　したがって、本願補正発明は、引用刊行物１〜４に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際、独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件補正は、特許法第１７条の２第５項で準用する同法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
（１）本願発明について
　本願について、平成１５年６月１３日付の手続補正は上記のとおり却下されたので、本願の請求項１〜４に係る発明は、出願当初の特許請求の範囲の請求項１〜４に記載されたとおりのものであって、当該請求項１に係る発明（以下「本願発明」という。）は以下のとおりのものと認める。
「ネットワークにより接続された複数のサイトと、
　前記複数のサイトの各々に設けられた業務サーバと、
　前記複数のサイトの少なくとも１つに設けられた障害連絡受付サーバと、
　前記障害連絡受付サーバが設けられたサイトの少なくとも１つに設けられた稼働確認サーバと、
　前記障害連絡受付サーバ及び前記稼働確認サーバのそれぞれに接続された複数種類の警報装置とを備え、
　前記複数種類の警報装置の稼働時には前記警報装置の種類はオペレータにより識別可能なものであり、
　前記業務サーバと、前記障害連絡受付サーバと、前記稼働確認サーバとのいずれかに障害が発生すると、電子メール及びファイル転送プロトコルのいずれかにより該障害を障害が発生しているサーバ以外の前記障害連絡受付サーバ及び前記稼働確認サーバの少なくとも１つが検知し、
　前記業務サーバは前記障害連絡受付サーバの少なくとも１つに対して一定時間間隔毎に稼働確認データを電子メール及びファイル転送プロトコルのいずれかにより送信し、
　前記障害連絡受付サーバ及び前記稼働確認サーバは、前記障害の検知時に障害の種類に応じた種類の警報装置を駆動し、且つ、
　前記障害連絡受付サーバは、前記稼働確認データを前記一定時間間隔毎に受信しなくなると前記稼働確認データに対応した種類の警報装置を駆動するようにしたことを特徴とする障害連絡到着通知システム。」
　
（２）引用刊行物
　原査定の拒絶の理由に引用された引用刊行物１〜４、および、その記載事項は、前記「２．（２）」に記載したとおりである。
　
（３）対比・判断
　本願発明は、前記「２．（１）」で検討した本願補正発明における、「障害連絡受付サーバ」による警報装置の駆動において「前記電子メール及びファイル転送プロトコルのいずれかにより受信した該障害連絡の内容が前記警報装置の駆動により障害連絡があったことを認識したオペレータにより受信されることにより警報装置の駆動を終了すること」の構成を省くものである。
　してみると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「２．（４）」に記載したとおり、引用刊行物１〜４に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用刊行物１〜４に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用刊行物１〜４に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。