【事件の表示】
　特願２００２−１５３０５０「顧客システムの保守方式、保守装置、保守方法、及びプログラム」拒絶査定不服審判事件〔平成１５年１２月　５日出願公開、特開２００３−３４５６２２、請求項の数（３）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯・本願発明  
　本願は、平成１４年５月２７日の出願であって、平成１７年１０月７日付けで拒絶の査定がなされ、これに対し、平成１７年１０月２８日に拒絶の査定を不服として審判請求がなされるとともに同日付けで手続補正書が提出されたものである。  
　そして、その請求項１から請求項３に係る発明（以下、それぞれ、「本願発明１」、「本願発明２」、「本願発明３」という。）は、平成１７年１０月２８日付けの手続補正書に記載の、以下のとおりのものと認められる。  
　  
　 
『【請求項１】　複数の保守対象装置を含む顧客システムと顧客システムの保守を実行し管理する保守装置とを互いにネットワークで接続した保守方式であって、  
　前記保守対象装置は、自身が有するネットワーク上のアドレスと診断プログラムを実行した診断結果を保守装置へ送信する診断実行部を有する第１の保守対象装置と、ネットワーク上のアドレスを持たず第１の保守対象装置によって自身の診断プログラムを実行する第２の保守対象装置とを含み、  
　前記保守装置は、  
　前記第２の保守対象装置毎に、当該保守対象装置の製造番号、型名と版数、および当該第２の保守対象装置の診断プログラムを実行する前記第１の保守対象装置のアドレスと顧客名とを含む構成情報を保持する構成ＤＢと、前記顧客システム毎に診断プログラムの実行時刻を含む診断実行条件と顧客名とを含む顧客情報を保持する保守ＤＢと、前記第２の保守対象装置の正常性を確認するための診断プログラムを前記型名及び版数毎に記憶する診断プログラム部とを有し、  
　一定時間間隔で前記保守ＤＢを参照して、前記診断実行条件が成立した前記顧客情報の前記顧客名を取得し、前記構成ＤＢを参照して当該顧客名を有する前記構成情報に含まれる前記型名及び版数を読み出し、読み出した当該型名及び版数に該当する診断プログラムを前記診断プログラム部から読み出し、当該構成情報に含まれる前記アドレスの第１の保守対象装置に送信し、
　当該第１の保守対象装置は、  
　当該診断プログラムを受信すると前記第２の保守対象装置に対して受信した当該診断プログラムを実行し実行結果を返信することを特徴とする保守方式。  
　  
【請求項２】　自身が有するネットワーク上のアドレスと診断プログラムを実行した診断結果を保守装置へ送信する診断実行部を有する第１の保守対象装置と、ネットワーク上のアドレスを持たず第１の保守対象装置によって自身の診断プログラムを実行する第２の保守対象装置とを含み顧客システムに設置された複数の保守対象装置とネットワークを介して接続し、  
　前記第２の保守対象装置毎に保守対象装置の製造番号、型名と版数、および当該第２の保守対象装置の診断プログラムを実行する前記第１の保守対象装置のアドレスと顧客名とを含む構成情報を保持する構成ＤＢと、  
　前記顧客システム毎に診断プログラムの実行時刻を含む診断実行条件と顧客名とを含む顧客情報を保持する保守ＤＢと、  
　前記第２の保守対象装置の正常性を確認するための診断プログラムを前記型名及び版数毎に記憶する診断プログラム部とを有し、  
　一定時間間隔で前記保守ＤＢを参照して前記診断実行条件が成立した前記顧客情報の前記顧客名を取得し、前記構成ＤＢを参照して当該顧客名を有する前記構成情報に含まれる前記型名及び版数を読み出し、読み出した当該型名及び版数に該当する診断プログラムを前記診断プログラム部から読み出し、当該構成情報に含まれる前記アドレスの第１の保守対象装置に送信することを特徴とする保守装置。  
　  
【請求項３】　複数の保守対象装置を含む顧客システムと顧客システムの保守を実行し管理する保守装置とを互いにネットワークで接続した保守方法であって、  
　前記保守対象装置は、自身が有するネットワーク上のアドレスと診断プログラムを実行した診断結果を保守装置へ送信する診断実行部を有する第１の保守対象装置と、ネットワーク上のアドレスを持たず第１の保守対象装置によって自身の診断プログラムを実行する第２の保守対象装置とを含み、  
　前記保守装置は、  
　前記第２の保守対象装置毎に、当該保守対象装置の製造番号、型名と版数、および当該第２の保守対象装置の診断プログラムを実行する前記第１の保守対象装置のアドレスと顧客名とを含む構成情報を保持する構成ＤＢと、前記顧客システム毎に診断プログラムの実行時刻を含む診断実行条件と顧客名とを含む顧客情報を保持する保守ＤＢと、前記第２の保守対象装置の正常性を確認するための診断プログラムを前記型名及び版数毎に記憶する診断プログラム部とを有し、  
　一定時間間隔で前記保守ＤＢを参照して、前記診断実行条件が成立した前記顧客情報の前記顧客名を取得し、前記構成ＤＢを参照して当該顧客名を有する前記構成情報に含まれる前記型名及び版数を読み出し、読み出した当該型名及び版数に該当する診断プログラムを前記診断プログラム部から読み出し、当該構成情報に含まれる前記アドレスの第１の保守対象装置に送信し、
　当該第１の保守対象装置は、  
　当該診断プログラムを受信すると前記第２の保守対象装置に対して受信した当該診断プログラムを実行し実行結果を返信することを特徴とする保守方法。』  
 
　
２．原査定の理由  
　原審における拒絶査定の要旨は、本願発明が明確でないから特許法第３６条第６項第２号に規定する要件を満たしていないので特許を受けることができないとともに、本願発明は自然法則を利用した技術思想の創作であるとは認められないから特許法第２９条第１項柱書に規定する要件を満たしていないので特許を受けることができないというものであり、また、本願発明は拒絶の理由に引用された特開平１１−１４３７３０号公報（以下、「引用文献１」という。）、特開平１０−３０１７９９号公報（以下、「引用文献２」という。）、特開平０６−２４２９９１号公報（以下、「引用文献３」という。）、及び、特開２００２−０４９５０８号公報（以下、「引用文献４」という。）に基づいて、当業者が容易に発明をすることができたものであるから特許法第２９条第２項の規定により特許を受けることができないというものである。  
　 
　 
３．判断  
　前記平成１７年１０月２８日付けの手続補正書でした手続補正により特許請求の範囲の記載は明確となり、したがって、特許法第３６条第６項第２号について拒絶の理由で指摘した点は解消した。また、その結果、本願発明１〜本願発明３において、コンピュータのハードウェア資源を利用して情報処理が具体的に実現されていると認められ、特許法第２９条第１項柱書について指摘した点も解消した。  
　  
　したがって、以下、特許法第２９条第２項について指摘した点について判断する。  
　  
　原査定の拒絶の理由に引用された前記引用文献１には、  
「【０００５】本発明の目的は、被試験装置のバージョンアップや搭載パッケージの変更や追加等で試験内容に変更及や追加が生じた場合に、変更内容に応じた試験プログラムを自動的に選択し、実行するコンピュータシステム装置の試験方法を提供することにある。」とした、  
“複数の試験対象装置の試験プログラムを搭載した管理サーバと、複数の被試験装置であるコンピュータシステム装置とを通信網によって接続したコンピュータシステム装置の保守方式であって、前記被試験装置は搭載パッケージを含み、前記被試験装置は電源投入後に自動的に装置構成の調査を行い、前記被試験装置及び前記含まれる搭載パッケージの装置名称及び装置構成情報を前記管理サーバへ報告し、前記管理サーバは、前記管理サーバに搭載した試験プログラムの中から、前記被試験装置及び前記搭載パッケージにそれぞれ適切な試験プログラム名称を被試験装置側へ報告し、前記被試験装置は、前記管理サーバより試験プログラムを自動的に取り込み実行するコンピュータシステム装置の保守方式”  
の発明が記載されている。  
　  
　本願発明１〜本願発明３と引用文献１に記載された発明とを比較すると、少なくとも以下の点で相違する。  
（相違点）  
　本願発明１〜本願発明３においては、複数の保守対象装置を含む顧客システム毎に診断プログラムの実行時刻を含む診断実行条件を設定し、保守装置が、この診断実行条件が成立したと判断したことを契機として、当該顧客システムに含まれる第１の保守対象装置に診断プログラムを実行させるのに対して、引用文献１に記載された発明においては、被試験装置のバージョンアップや搭載パッケージの変更・追加等の後の当該被試験装置における電源投入を契機として、当該被試験装置は自動的に試験プログラムを実行する点。
　  
　ところで、引用文献２には、  
「【００１４】図１〜３を参照して、本システムは、ユーザサイトＡならびにＢと、ＲＭＣ３０と、通信回線４０とを有している。各ユーザサイトは、複数の構成モジュールにより構成されるホストコンピュータ１０−１〜１０−ｎ（ｎは、自然数）と、複数の構成モジュールのそれぞれについての運用履歴、故障率パラメータ、および修理・交換履歴を含むモジュール状態情報、障害情報、ならびに試験プログラムを更新可能に記録・保管する管理データベース２６を備える管理プロセッサ２０とを有している。」こと、  
「【００２７】…(中略)…ホストコンピュータの構成モジュールの稼動時間や固有の故障率に基づいて試験プログラムの投入スケジュールを計画立案する。また、故障の発生頻度が高い構成モジュールや、最も最近に障害の発生した構成モジュールについては、障害発生頻度の低い構成モジュールよりも定期保守の周期を短くしたスケジュールにする。」こと、  
「【００３０】この後、管理プロセッサ２０は、スケジュールを管理ＤＢ２６に格納する（ステップＳ２６）。管理プロセッサ２０は、一定周期毎に管理ＤＢ２６の内容を参照し、試験プログラムの投入スケジュールを確認する。  
【００３１】試験プログラム実行制御部２３は、各構成モジュール毎に管理ＤＢ２６を参照して、スケジュールが更新されているかどうか確認する。スケジュール確認の結果、該構成モジュールに対して試験プログラム投入契機であるとする。」こと、  
「【００３２】…(中略)…構成モジュールに対応した試験プログラムを管理ＤＢ２６から読み出し、ホストコンピュータへ転送する。その後、試験プログラム実行制御部２３は、ホストコンピュータに対して試験プログラムの実行を指示する。」こと、  
が記載されている。  
　したがって、引用文献２には、ホストコンピュータにおける試験プログラム実行を管理する管理プロセッサ２０において、各構成モジュール毎の投入スケジュールを確認し、特定の構成モジュールの試験プログラム投入の時期であると判断したことを契機として、ホストコンピュータに当該構成モジュールの試験プログラムを実行させることが記載されている。  
　  
　これに対して、引用文献１に記載された発明においては、上記相違点で述べたとおり、試験プログラム実行の契機は、保守対象装置である被試験装置における電源投入である。そして、「被試験装置のバージョンアップや搭載パッケージの変更や追加等で試験内容に変更及や追加が生じた場合に、変更内容に応じた試験プログラムを自動的に選択し、実行する」という、前記した引用文献１に記載された発明の目的を考えれば、前記電源投入は被試験装置のバージョンアップや搭載パッケージの変更・追加等を行ったことに基づくものであることは明らかである。よって、前記電源投入を契機として自動的に試験プログラムを実行する引用文献１に記載された発明においては、そもそも、被試験装置での試験プログラム実行のスケジュール管理を行うことを想定していない。
　したがって、保守対象装置の保守を実行し管理する保守装置である管理プロセッサ２０における各構成モジュール毎の投入スケジュール確認処理を契機として、この投入スケジュールに従ってホストコンピュータに当該構成モジュールの試験プログラムを実行させる技術が引用文献２に記載されているからといって、当該技術を、保守対象装置である被試験装置が試験プログラム実行の契機を与え、かつ、試験プログラム実行のスケジュール管理を行うことを想定していない引用文献１に記載された発明に適用することを、当業者が容易に想到し得るとは認められない。
　  
　一方、引用文献３及び引用文献４には、前記相違点で指摘した本願発明１〜本願発明３の発明特定事項が記載されていないばかりでなく、引用文献１に記載された発明に引用文献２に記載された技術を適用することを肯首させる事項も記載されていない。  
　そして、本願発明１〜本願発明３は、前記相違点で指摘した発明特定事項を備えることにより、明細書に記載された効果を奏するものである。  
　  
　よって、本願発明１〜本願発明３が、引用文献１〜４に記載の発明に基づいて、当業者が容易に発明できたものということはできない。
　
  
４．まとめ  
　以上のとおりであるから、本願発明が、特許法第３６条第６項第２号、同法第２９条第１項柱書及び同法第２９条第２項の規定により特許を受けることができないとした原査定の判断は妥当でない。 
　また、他に本願を拒絶すべき理由を発見しない。 
　よって、結論のとおり審決する。