2019-004433

特願２０１４－２３７４５１「保守管理システム、保守管理方法および保守管理プログラム」拒絶査定不服審判事件〔平成２８年　５月３０日出願公開、特開２０１６－　９９８５９、請求項の数（１０）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続きの経緯 本願は，平成２６年１１月２５日の出願であって，平成３０年６月２６日付けで拒絶理由通知がされ，同年７月２４日に意見書が提出されるとともに手続補正がされ，同年１１月１６日付けで最後の拒絶理由通知がされ，平成３１年１月１５日に意見書が提出されるとともに手続補正がされたものの，同年１月２９日付けで拒絶査定（以下，「原査定」という。）がされ，これに対し，同年４月４日付けで拒絶査定不服審判の請求がされると同時に手続補正がされ，令和２年４月２２日付けで拒絶理由通知（以下，「当審拒絶理由通知」という。）がされ，同年７月１０日に意見書が提出されるとともに手続補正がされたものである。 第２　原査定の概要 原査定（平成３１年１月２９日付け拒絶査定）の概要は次のとおりである。 １．理由２（特許法第２９条第１項第３号）について 本願請求項１０に係る発明は，以下の引用文献Ａに記載された発明であるから，特許法第２９条第１項第３号に該当し、特許を受けることができない。 ２．理由３（特許法第２９条第２項）について 本願請求項１－１０に係る発明は，以下の引用文献Ａ，Ｂ，Ｃに基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 ［引用文献等一覧］ Ａ．特開２００８－１７１２３１号公報 Ｂ．特開平７－２００３６５号公報 Ｃ．特開２０１２－１０８７８３号公報 第３　当審拒絶理由通知の概要 当審拒絶理由通知の概要は次のとおりである。 本願請求項１－１０に係る発明は，以下の引用文献１－３に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 ［引用文献等一覧］ １．特開２００３－２７１４２２号公報　（当審において新たに引用した文献） ２．特開２００９－１７００３４号公報　（当審において新たに引用した文献） ３．特開２００８－１７１２３１号公報　（拒絶査定時の引用文献Ａ） 第４　本願発明 本願請求項１－１０に係る発明（以下，それぞれ「本願発明１」－「本願発明１０」という。）は，令和２年７月１０日付けの手続補正で補正された特許請求の範囲の請求項１－１０に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。 「【請求項１】 ある保守対象からそのログ情報を受信し、そのログ情報を汎用通信回線を通じて送信する保守手段と、 前記ログ情報を、汎用通信回線を通じて受信し、処置を行うまでに前記保守対象のある個別の構成要素について発生する異常の発生の許容値を、その個別の構成要素についてのある期間内に前記異常が発生した回数及び前記期間内に前記異常が発生する回数の予測値のうちのいずれかである対象発生回数と、予め設定した基準値との比較結果に応じて更新する管理手段と、 前記許容値を出力する出力手段と、 を備え、 前記管理手段は前記保守対象の保守を行う者により管理される保守センタに設置され、 前記保守手段及び前記出力手段は顧客が管理する領域に置かれる、 保守管理システム。」 本願発明２－８は，本願発明１を減縮した発明である。 本願発明９は，本願発明１に対応する方法の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。 本願発明１０は，本願発明１のうち，「保守手段」を省いたものに対応するプログラムの発明である。 第５　引用文献，引用発明等 １　引用文献１について ア　当審による令和２年４月２２日付けの拒絶の理由（以下，「当審拒絶理由」という。）に引用された引用文献１（特開２００３－２７１４２２号公報）には，図面とともに次の事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ａ「【０００１】 【発明の属する技術分野】本発明は、コンピュータ端末の保守の必要性を判定する予防保守判定処理方法に関する。特に、ネットワークを用いて端末のシステムの復旧処理を行なう保守管理システムにおいて、端末のハードウェア保守推奨の有無を判定する予防保守判定処理方法と、その処理方法をコンピュータに実行させるためのプログラムと、予防保守判定処理の結果をもとにシステムの復旧処理を行なう保守管理方法とに関する。」 Ｂ「【００１１】さらに、保守管理システムが複数の顧客端末の保守を管理している場合に、例えばセクタ異常が所定の回数以上となれば直ちにＨＤＤ交換を行なうなど、保守推奨を判定する閾値を一定にしてしまうと、各顧客端末の環境や固有の稼動状態に則した判定を行うことができず、かえって予防保守によってＨＤＤなどの資源が無駄になったり、保守作業が非効率になったりすることになる。」 Ｃ「【００２６】 【発明の実施の形態】図１に、本発明の実施の形態におけるシステム構成例を示す。本発明にかかる予防保守判定処理装置１は、顧客端末２および保守管理者端末３と接続しデータ通信を行なうことができる。予防保守判定処理装置１は、ログ情報入力部１１と、ログ情報解析部１２と、予防保守判定処理部１３と、判定結果表示処理部１４と、閾値変更処理部１５と、データベース群１６からなる。」 Ｄ「【００３０】予防保守判定処理部１３は、数値ログＤＢ１６１の数値ログ情報を、規定閾値ＤＢ１６２で記憶する顧客端末２ごともしくはハードウェアの種別ごとに規定した閾値と比較し、所定の対処方法に該当するか否かを判定する手段である。ここで、対処方法は、例えば「再構築」、「再構築、保守推奨」、「待機、保守派遣」などがある。 【００３１】「再構築」は、顧客端末２の数値ログ情報の解析結果が所定の閾値に達しない状態、すなわち顧客端末２のハードウェアが異常状態ではないため、ソフトウェアの再構築のみを行なうように顧客端末２に指示する対処方法である。 【００３２】「再構築、保守推奨」は、顧客端末２の数値ログ情報の解析結果（値）が所定の閾値を超えてはいないが閾値との差が少ない状態、すなわち、顧客端末２のハードウェアが異常状態ではないが近い将来には交換保守が必要となるような状態であるため、現時点ではソフトウェアの再構築処理と保守推奨とを指示する対処方法である。 【００３３】「待機、派遣」は、顧客端末２の数値ログ情報の解析結果（値）が所定の閾値を超えている状態、すなわち顧客端末２のハードウェアが異常状態にあり、直ちに交換や修理などの保守が必要な状態であるため、顧客端末２へ待機する旨を通知し、保守管理者端末３へ保守派遣依頼を通知する対処方法である。」 Ｅ「【００４３】図２に顧客端末２の構成例を示す。顧客端末２は、ログ情報生成部２１と、ログ情報記憶部２２と、ログ情報送信部２３と、メッセージ表示部２４と、再構築処理部２５とを備える。」 Ｆ「【００５０】顧客端末２に何らかの異常が生じたときに、ユーザがリカバリ起動メディア２０を顧客端末２へセットすることにより、処理プログラムであるこれらの各処理部が直接起動して所定の処理を行なう。 【００５１】すなわち、ユーザがリカバリ起動メディア２０を顧客端末２へセットすると、ログ情報送信部２３は、基本ＯＳを起動し、ログ情報記憶部２２に記憶されているログ情報を収集して、予防保守判定処理装置１にネットワーク９を通じて接続し、対処方法の問い合わせと収集したログ情報を送信する。」 Ｇ「【００５３】図３に、本発明にかかる予防保守判定処理装置１を適用する保守管理センタ１００の構成例を示す。 【００５４】保守管理センタ１００はネットワーク９を通じてアクセスが可能なサーバであり、例えば、予防保守判定処理装置１の他、認証サーバ４と、顧客情報マスタデータベース（ＤＢ）５と、ソフトウェア復旧サーバ６と、固有設定情報マスタデータベース（ＤＢ）７とを備える。」 Ｈ「【００６３】予防保守判定処理装置１のログ情報入力部１１は、送信されたログ情報を入力して（ステップＳ１１）、通常、図５に示すようなテキストデータ形式であるログ情報を数値化し（ステップＳ１２）、数値化したログ情報を数値ログＤＢ１６１へ反映させる（ステップＳ１３）。」 Ｊ「【００６６】例えば、ログ情報解析部１２は、ＰＣ００００１で登録されている顧客端末２のＨＤＤ（型名：ＨＤＤ００１０）についての数値ログ情報を数値ログＤＢ１６１から抽出し、ハードウェア・エラーが発生しているかどうかを調べる。具体的には、ログ情報解析部１２は、数値ログＤＢ１６１から顧客端末と型名／ＯＳをキーに数値ログ情報を抽出し、図７に示すような解析情報を生成する。 【００６７】また、ログ情報解析部１２は、解析情報からエラー番号をキーにしてエラーを抽出し、図８（Ａ）に示すようなエラーカウント情報を生成する。エラーカウント情報は、ハードウェアの型名、エラー番号、発生回数、発生台数、およびこれまでの保守回数からなる。 【００６８】また、ログ情報解析部１２は、解析情報から、エラー番号についてメッセージの種別ごとの発生件数を抽出し、図８（Ａ）に示すようなエラーメッセージ種別カウント情報を生成する。エラーメッセージ種別カウント情報は、エラー種別（エラー番号）ごとに警告的状況メッセージ（Ｗａｒｎｉｎｇ）、破壊的状況メッセージ（Ｆａｔａｌ）などのメッセージ件数を記憶し管理する。エラーメッセージ種別カウント情報はエラーＤＢ１６３に反映させる。 【００６９】ログ情報解析部１２は、さらに、図７の解析情報からＨＤＤの交替セクタ状況に関するデータを抽出し、図９に示すような交替セクタ監視テーブルを生成し、規定閾値ＤＢ１６２から該当するハードウェアの交替セクタについて設定されている規定閾値を抽出し、図１０に示すような交替セクタ規定閾値テーブルを生成する。 【００７０】図９の交替セクタ監視テーブルには、該当するＨＤＤ（型名ＨＤ００１０）について、週、月および年の各単位で集計した交替セクタの使用回数、ＨＤＤの仕様情報をもとに算出した交替可能な残りのセクタ数が格納される。また、図１０の交替セクタ規定閾値テーブルには、該当するＨＤＤの使用可能な交替セクタ数が、週、月、年の各単位および合計について設定され格納される。 【００７１】そして、ログ情報解析部１２は、交替セクタ監視テーブルと交替セクタ規定閾値テーブルとをもとに、ＨＤＤでハードエラーが発生しているか否かを判定する（ステップＳ１５）。すなわち、ログ情報解析部１２は、交替セクタの使用状況を週単位、月単位、年単位にまとめた交替セクタ監視テーブルと交替セクタ規定閾値テーブルとを比較して、交替セクタの枯渇が生じているか否かを確認する。そして、交替セクタが、週、月、年のいずれかの単位で交替セクタが枯渇していれば、ハードエラーに該当すると判定する。ここで、図９に示すように、交替セクタ監視テーブルの交替可能なセクタの残りが「０」である場合には（下線で示す）、既に交替可能なセクタがない枯渇状態であるためハードエラーが発生したと判定する。 【００７２】ＨＤＤにハードエラーが発生したと判定した場合には（ステップＳ１５）、さらに、閾値変更処理部１５は、以降はハードエラーが発生する前に保守推奨（この場合にはＨＤＤ交換）を行なえるように、交替セクタ監視テーブルの各単位の交替セクタの使用数をもとに、所定の規則にしたがって、交替セクタ規定閾値テーブルの閾値を変更する必要があるかどうかを判定する（ステップＳ１６）。規定閾値の変更の有無を判定する所定の規則としては、以下のようなものを用いる。 【００７３】(a)交替セクタ監視テーブルの各単位の値のいずれかが、交替セクタ規定閾値テーブルの値に達した場合もしくは超えた場合、または、(b)交替セクタ監視テーブルおよび交替セクタ規定閾値テーブルの対応する値の差が所定の範囲内の場合。 【００７４】閾値変更処理部１５は、規定閾値の変更が必要と判定した場合に、交替セクタ規定閾値テーブルの閾値を変更する（ステップＳ１７）。 【００７５】例えば、図９の交替セクタ監視テーブルと図１０の交替セクタ規定閾値テーブルとをもとに判定する場合に、交替セクタ監視テーブルの交替セクタの使用数が年１０回であり、交替セクタ規定閾値テーブルの対応する規定閾値に達し、交替セクタが枯渇してハードエラーが発生する可能性があることを意味している。 【００７６】閾値変更処理部１５は、前記の（ａ）の規則に従って閾値変更を決定し、変更処理を行う。閾値変更処理部１５は、交替セクタ規定閾値テーブルの年の設定を１減算して１０から９に変更し、併せて合計を２９から３０に変更する。図１１に、変更後の交替セクタ規定閾値テーブルを示す。 【００７７】なお、閾値変更処理部１５は、規定閾値を年→月→週の順に１項目ずつ変更していくようにして変更を行ってもよい。また、「出荷台数当たりに対する障害取扱い件数×数％」で規定閾値を調整して変更を行ってもよい。また、エラーＤＢ１６３のエラーの発生回数などを統計処理し規定閾値を調整して変更を行ってもよい。 【００７８】このように、本発明では、顧客端末２の実際の稼動状況を反映したログ情報を解析し、その解析結果をもとにハードエラーや保守推奨を判定する規定閾値を設定し自動的に変更することができる。 【００７９】そして、以降の保守推奨判定の処理においては、交替セクタ数がより厳格に設定された規定閾値を用いて保守推奨の必要性を判定することができるため、交替セクタの残りが０になってハードエラーとなる前に、交替セクタの枯渇となりやすい状況を早期に発見して予防保守を行なうことができる。 【００８０】その後、予防保守判定処理部１３は、ログ情報解析部１２の解析結果にもとづいて対処方法を判定する。ここでは、交替セクタの枯渇が生じてハードウェア・エラーとなっていてＨＤＤ交換が必要である。そこで、対処方法として「待機、派遣」指示を選択して判定結果表示処理部１４へ通知する（ステップＳ１８）。」 Ｋ「【００９４】予防保守判定処理装置１の閾値変更処理部１５は、入力装置（図１に図示しない）から入力された任意の値をもとに規定閾値ＤＢ１６２の値を変更する。これにより、権限を有する管理者は、意図的に規定閾値ＤＢ１６２の規定閾値を任意の値に変更して、具体的なエラー発生にかかわらず、顧客端末２に搭載されている特定のハードの確認したり回収場所の特定したりするなど、潜在的な障害を回避するための作業、例えばリコール対象装置回収の作業で用いる情報を自動的に取得することができ、かかる作業負担を軽減することができる。」 Ｌ「【０１１０】 【発明の効果】以上説明したように、本発明によれば、保守管理の対象となる顧客端末のログ情報を取得し解析し、所定の規定閾値を用いてハードウェアが異常ではないが潜在する危機的状況であって保守推奨をするか否かを判定し、顧客端末もしくは保守管理者端末へ「保守推奨」を通知する予防保守判定処理を実現することができる。これにより、ソフトウェア復旧の前提となるハードウェアについて将来のハードウェア・エラーにつながる障害を早期に認識することができる。また、従来では正常に動作可能なハードウェアについても障害の原因を追求することなく交換保守していた経費などが削減でき、効率的な保守管理を実現することができる。 【０１１１】特に、保守対象が複数の顧客端末である場合に、「待機、派遣」、「保守推奨、再構築」、「再構築」などの対処方法を判定する規定閾値を各顧客端末ごとに設定でき、顧客端末２のログ情報の解析結果をもとに変更することができる。これにより、顧客端末ごとに対応した保守管理が可能となり有効的な保守管理を実現することができる。」 イ　上記Ａ，ＣないしＦ，及びＨないしＬの記載内容からすると，引用文献１には，次のとおりの発明（以下，「引用発明」という。）が記載されているものと認められる。 「ネットワークを用いて端末のシステムの復旧処理を行う保守管理システムであって， 顧客端末は，ログ情報記憶部と，ログ情報送信部とを備え， ログ情報送信部は，ログ情報記憶部に記憶されているログ情報を収集して，予防保守判定処理装置にネットワークを通じて接続し，収集したログ情報を送信し， 予防保守判定処理装置は，ログ情報入力部と，ログ情報解析部と，予防保守判定処理部と，判定結果表示処理部と，閾値変更処理部と，データベース群からなるものであり，保守管理センタは，予防保守判定処理装置を備え， ログ情報入力部は，送信されたログ情報を数値化し，数値化したログ情報を数値ログＤＢへ反映させ， ログ情報解析部は，顧客端末のＨＤＤについての数値ログ情報を数値ログＤＢから抽出し，解析情報を生成し，解析情報からＨＤＤの交替セクタ状況に関するデータを抽出し，交替セクタ監視テーブルを生成し，規定閾値ＤＢから該当するハードウェアの交替セクタについて設定されている規定閾値を抽出し，交替セクタ規定閾値テーブルを生成し，交替セクタの使用状況を週単位，月単位，年単位にまとめた交替セクタ監視テーブルと交替セクタ規定閾値テーブルとを比較して，交替セクタの枯渇が生じているか否かを確認し，週，月，年のいずれかの単位で交替セクタが枯渇していれば，ハードエラーに該当すると判定し， ＨＤＤにハードエラーが発生したと判定した場合には，閾値変更処理部は，以降はハードエラーが発生する前に保守推奨を行なえるように，所定の規則にしたがって，交替セクタ規定閾値テーブルの閾値を変更する必要があるかどうかを判定し，規定閾値の変更が必要と判定した場合に，交替セクタ規定閾値テーブルの閾値を変更し， 規定閾値の変更の有無を判定する所定の規則としては，（ａ）交替セクタ監視テーブルの各単位の値のいずれかが，交替セクタ規定閾値テーブルの値に達した場合もしくは超えた場合，のようなものを用い， 閾値変更処理部は，前記の（ａ）の規則に従って閾値変更を決定し，交替セクタ規定閾値テーブルの年の設定を１減算して１０から９に変更し， 予防保守判定処理部は，ログ情報解析部の解析結果にもとづいて対処方法を判定し，対処方法として「待機，派遣」指示を選択し，「待機，派遣」は，顧客端末の数値ログ情報の解析結果が所定の閾値を超えている状態，すなわち顧客端末２のハードウェアが異常状態にあり，直ちに交換や修理などの保守が必要な状態であり， 保守対象が複数の顧客端末である場合に規定閾値を各顧客端末ごとに設定でき，顧客端末のログ情報の解析結果をもとに変更することができ，閾値変更処理部は，入力装置から入力された任意の値をもとに規定閾値ＤＢの値を変更する， ことを特徴とする保守管理システム。」 ２　引用文献２について ア　当審拒絶理由に引用された引用文献２（特開２００９－１７００３４号公報）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｍ「【００３６】 次に、本実施の形態のデータ記録装置１内にコマンドが供給されることで、行われるデータの書き込み及び読み出しの処理構造であるプロセス構造を、図５を参照して説明する。この図５に示したプロセス構造は、図３及び図４に示した内部制御部１１－２の制御で実行される場合のプロセス構造を示したものであり、内部制御部１１－２が制御機能を備える。 【００３７】 デジタルシネマサーバから高速ネットワークのドライバであるＦＣドライバにコマンドが供給されると、コマンド待機処理が行われ、コマンドで指示された処理内容を、コマンド処理に伝える。 コマンド処理は、コマンドの処理内容を実際に処理する部分であり、テーブル検索、リソースの確保などを行い、高速ネットワーク側と通信を行う。 また、再構築設定に合わせて、再構築用のコマンドを発行し、設定と状況に合わせて再構築を実行する。 ＬＢＡマネージャでは、例えば、ＨＤＤにデータが書き込み出来ない状況が発生した場合に、そのことが通知されて、管理を行う。 モードページマネージャでは、ＨＤＤのエラーを集計して、各ＨＤＤの不良判断を行う。後述する不良判断処理は、ここで実行されることになる。ここでは、具体的にはエラー発生の頻度値と積算値とを集計する。頻度値は、各ＨＤＤに対して一定数のコマンドが発行される毎のエラー数であり、積算値は、該当するＨＤＤを使用開始してからの累積のエラー数である。また、不良判断は、現在の頻度値と設定された閾値とを比較して、現在の頻度値が閾値を越えた場合に、不良であると判断する。但し後述するように本例の場合には、この閾値を可変設定するようにしてある。また、不良と判断された場合には、該当する不良ＨＤＤを、管理者に対して伝える処理が実行される。例えば表示などで不良と判断されたＨＤＤを知らせる処理が行われる。 【００３８】 リソースマネージャでは、コマンドテーブルやキャッシュの割当てを行う。 ＨＤＤマネージャでは、コマンドテーブルの監視、空いているＨＤＤコントローラへの指令、ＨＤＤステータスの管理を行う。 ＨＤＤコントローラは、ＨＤＤ実行部へのコマンドの発行を行う。コマンドに基づいた処理が、規定された時間内に行われているかを監視するタイムアウト監視についても行う。正常に終了した場合は、終了を返答して次のコマンド待ちになる。規定された時間内に処理が終了しないタイムアウトした場合には、タイムアウトを返送し、ＨＤＤステータスをＲＡＤＩコントローラに返し、タイムアウトしたドライバの終了を待つ。さらにタイムアウトした場合はリセット処理に入り、終了時点でステータスを返し、次の待ちに入る。さらにだめな場合には、不良としてステータスを返し、次の待ちに入る。 実行部は、ＨＤＤドライバを呼び出す処理を実行する。 ステータスデーモンは、ＨＤＤの状態を監視する。ここでは、主として物理層の状態を監視する。ＨＤＤの着脱、物理層のエラーによる切断も反映させる。 【００３９】 次に、本実施の形態によるＨＤＤの故障診断処理について、図６のフローチャートを参照して説明する。 この故障診断処理は、データ記録装置１が備える複数台のＨＤＤ１台ごとに行われるものである。 まず、ＨＤＤに対するデータの書き込み及び読み出しのコマンドが供給されると、そのコマンドが正常に処理されたか否か判断して、正常に処理されない場合に、エラーとする。正常に処理されない状態としては、データの読み出しや書き込みができない場合だけでなく、規定された時間内に処理されないタイムアウト時も含まれる。 エラー発生があると（ステップＳ１１）、そのエラー発生の頻度値と積算値とをカウントアップさせる（ステップＳ１２）。頻度値は、ここでは１００アクセス当りのエラーの発生数である。そして、そのエラー発生回数の積算値が１００００の倍数に達したか否か判断する（ステップＳ１３）。 【００４０】 エラー発生回数の積算値が、１００００の倍数に達した場合には、頻度値を比較する閾値の設定値を、現在の設定値の約半分の値とする（ステップＳ１４）。但し、閾値の下限値を予め決めておく。ここでは、初期状態での閾値を１０とし、１０→５→２と変化させる。この２を下限値とし、以後は閾値２が設定された状態を継続させる。 そして、ステップＳ１３で積算値が１００００の倍数に達してない場合と、ステップＳ１４で閾値を変更した場合のいずれの場合でも、現在設定されている閾値とエラー発生回数の積算値とを比較して、故障判定を行う（ステップＳ１５）。閾値を越えた場合、該当するＨＤＤが故障と判断する。故障と判断すると、そのＨＤＤの交換を告知する処理が行われる。 【００４１】 このように処理されることで、例えば１台のＨＤＤが使用開始されると、当初はエラー頻度値と比較する閾値が１０であり、１００アクセス当りのエラー数が１０を越える場合に、不良であると判断される。そして、エラーの発生回数の累計値が１００００になったとき、閾値が５に変化し、１００アクセス当りのエラー数が５を越える場合に、不良であると判断される。さらに、エラーの発生回数の累計値が２００００になったとき、閾値が２に変化し、１００アクセス当りのエラー数が２を越える場合に、不良であると判断される。それ以後は、エラーの発生回数の累計値が３００００になっても、閾値は２のままである。」 Ｎ「【００４５】 従って本実施の形態によると、ＨＤＤのエラーの発生頻度についてはそれ程変化がない場合であっても、不良と判断できるようになり、適正にエラー発生回数に基づいた不良管理が可能となる。例えば、比較的エラーの発生状況が多い状況で安定しているようなハードディスクドライブを、比較的短い使用期間で不良品として検出できるようになり、ハードディスクドライブを使用したデータ記録装置の信頼性向上に貢献する。」 ３　引用文献３（原査定における引用文献Ａ）について ア　原査定における拒絶の理由，及び当審拒絶理由に引用された引用文献３（特開２００８－１７１２３１号公報）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｐ「【００２９】 図５は、アレイディスク群の保守管理装置によるリカバリエラーの発生回数の閾値の更新処理の例を説明する図である。この例では、アレイディスク群の保守管理装置１が備える閾値更新部１４が、図４を参照して前述したＡＦＲの算出例に従って故障率算出部１３が算出したアレイディスクの世代毎のＡＦＲと、予め定められた該ＡＦＲの閾値の情報とを比較し、該比較結果に基づいて、各世代のリカバリエラーの発生回数の閾値を更新する。 【００３０】 より具体的には、閾値更新部１４は、ＡＦＲが該ＡＦＲの閾値未満であると判断した場合には、該ＡＦＲに対応する世代のアレイディスク１０１についてのリカバリエラーの発生回数の閾値を更新せず、ＡＦＲが該ＡＦＲの閾値以上であると判断した場合には、該ＡＦＲに対応する世代のアレイディスク１０１についてのリカバリエラーの発生回数の閾値を、該ＡＦＲが該ＡＦＲの閾値を超える程度に応じた値に設定して減らす。閾値更新部１４は、例えば、ＡＦＲが該ＡＦＲの閾値を超える程度が大きいほど、設定するリカバリエラーの発生回数の閾値を小さくする。 【００３１】 図５中に示すグラフの横軸はアレイディスク１０１の世代、縦軸はアレイディスク１０１の各世代に対応するＡＦＲである。ＥｔはＡＦＲの閾値、Ｅａはａ世代のアレイディスク１０１のＡＦＲ、Ｅｂはｂ世代のアレイディスク１０１のＡＦＲ、Ｅｃはｃ世代のアレイディスク１０１のＡＦＲである。 【００３２】 閾値更新部１４は、ＥａとＥｔとを比較し、ＥａがＥｔ未満であると判断する。従って、閾値更新部１４は、ａ世代のアレイディスクについてのリカバリエラーの発生回数の閾値を更新しない。 また、閾値更新部１４は、ＥｂとＥｔとを比較し、ＥｂがＥｔ以上であると判断する。従って、閾値更新部１４は、ｂ世代のアレイディスクについてのリカバリエラーの発生回数の閾値を、例えばＥｂからＥｔを減じた結果得られる値に応じた値に設定して減らす。また、閾値更新部１４は、ＥｃとＥｔとを比較し、ＥｃがＥｔ以上であると判断する。従って、閾値更新部１４は、ｃ世代のアレイディスクについてのリカバリエラーの発生回数の閾値を、ＥｃからＥｔを減じた結果得られる値に応じた値に設定して減らす。 【００３３】 本発明におけるリカバリエラーの発生回数の閾値の更新処理は、上述した処理に限定されない。本発明の一実施例によれば、閾値更新部１４が、例えば、ＡＦＲが該ＡＦＲの閾値未満であると判断した場合には、該ＡＦＲに対応する世代のアレイディスク１０１についてのリカバリエラーの発生回数の閾値を増やし、ＡＦＲが該ＡＦＲの閾値と等しいと判断した場合には、該ＡＦＲに対応する世代のアレイディスク１０１についてのリカバリエラーの発生回数の閾値を更新せず、ＡＦＲが該ＡＦＲの閾値より大きいと判断した場合には、該ＡＦＲに対応する世代のアレイディスク１０１についてのリカバリエラーの発生回数の閾値を減らすようにしてもよい。」 ４　原査定における引用文献Ｂについて ア　原査定の拒絶の理由に引用された引用文献Ｂ（特開平７－２００３６５号公報）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｑ「【００１９】次に図４を用いて、本発明におけるホストコンピュータ１の処理動作について説明する。 【００２０】端末３からログ情報が送信されてくると、ログ情報受信手段１５が起動され、該ログ情報は、ログ情報受信手段１５で受信処理を施された後（ステップ１０４）、発信元ＩＤ付加手段１６が起動される。 【００２１】該ログ情報がどの端末３から送信されたものであるかを識別するための発信元ＩＤが発信元ＩＤ付加手段１６で付加されてログ情報蓄積手段１１が起動される（ステップ１０５）。 【００２２】この発信元ＩＤを付加されたログ情報は、ホストコンピュータ１のログ情報ファイル１０にログ情報蓄積手段１１によって蓄積される（ステップ１０６）　こうして複数の端末３から送信されたログ情報は、ホストコンピュータ１で一元管理され、システム側で設定した条件に従って随時または定期的にログ情報出力手段１７が起動されて、ログ情報出力手段１７がログ情報ファイル１０の内容を編集して出力装置に一覧表を出力する（ステップ１０７）。 【００２３】このホストコンピュータ１に蓄積されたログ情報は、システム側で設定した条件に従って随時または定期的にログ情報送信手段１３で送信処理が施され、通信回線４を介して保守センタ２に送信される（ステップ１０８）。」 ５　原査定における引用文献Ｃについて ア　原査定の拒絶の理由に引用された引用文献Ｃ（特開２０１２－１０８７８３号公報）には，関連する図面とともに，以下の技術的事項が記載されている。 （当審注：下線は，参考のために当審で付与したものである。） Ｒ「【００１７】 ユーザ端末１００は、障害発生通知部１１、ログ情報作成部１６、ログ情報記憶部１２、ログ情報自動収集部１３、ログ情報暗号化部１４、電力供給部１５を含む。ユーザ端末１００は、障害検出時にはネットワークから切り離し、制御部２００、障害記録中継装置３００にのみ接続するものとする。」 Ｓ「【００２５】 ログ情報暗号化部１４は、保守センタ４００で設定されている暗号化方式に合わせて、保守センタ４００で復号化できるように、ログ情報の暗号化を行なう。また、ログ情報暗号化部１４は、暗号化の後、障害記録中継装置３００に暗号化したログ情報（以降、暗号化ログと呼ぶ）を送信する。障害記録中継装置３００のログ情報送受信部３２はこれを受信し、ログ情報退避部３３に格納する。ログ情報暗号化部１４は、ログ情報退避部３３に関する、場所、容量等の情報を格納する、図示しない退避先情報記憶部を有している。ログ情報暗号化部１４は、送信に必要な情報を、この退避先情報記憶部から得る。ログ情報暗号化部１４は、ログ情報送受信部３２から暗号化ログの退避完了の通知を受けると、障害発生通知部１１に退避が完了したことを通知する。」 Ｔ「【００２８】 障害記録中継装置３００は、ログ情報送信指示部３１、ログ情報送受信部３２、ログ情報退避部３３、ログ情報消去部３４、電力供給判断部３５、充電池３６を含む。障害記録中継装置３００は、ネットワークへの接続が可能である。」 Ｕ「【００３２】 ログ情報送受信部３２は、ログ情報暗号化部１４から受信した暗号化ログをログ情報退避部３３に格納し、格納完了後にログ情報暗号化部１４に退避の完了を通知する。また、ログ情報送受信部３２は、ログ情報送信指示部３１からの指示を受けて、ログ情報退避部３３から暗号化ログを取得し、これを保守センタ４００に送信する。また、ログ情報送受信部３２は、保守センタ４００から暗号化ログ受信通知を受けて、ログ情報消去部３４に、ログ情報退避部３３の中の暗号化ログの消去を指示する。」 第６　対比・判断 １　本願発明１について （１）対比 ア　本願発明１と引用発明とを対比する。 （ア）引用発明の「保守管理システム」は，本願発明１の「保守管理システム」に相当する。 （イ）引用発明の「顧客端末」及び「ログ情報」は，それぞれ，本願発明１の「保守対象」及び「ログ情報」に相当する。また，引用発明の「ネットワーク」と本願発明１の「汎用通信回線」とは，「通信回線」である点で共通する。そして，引用発明の「顧客端末は，ログ情報記憶部と，ログ情報送信部とを備え」との記載，及び，「ログ情報送信部は，ログ情報記憶部に記憶されているログ情報を収集して，予防保守判定処理装置にネットワークを通じて接続し，収集したログ情報を送信」との記載から，引用発明の保守管理システムは，顧客端末が備えるログ情報記憶部からログ情報を受信し，そのログ情報をネットワークを通じて送信する，保守手段を備えるものであるといえる。 してみると，引用発明と本願発明１とは，後記する点で相違するものの，“ある保守対象からそのログ情報を受信し，そのログ情報を通信回線を通じて送信する保守手段”を備える点で共通する。 （ウ）引用発明の「交換や修理などの保守」及び「顧客端末のＨＤＤ」は，それぞれ，本願発明１の「処置」及び「保守対象のある個別の構成要素」に相当する。また，引用発明の「顧客端末のＨＤＤについての数値ログ情報数値ログＤＢから抽出し，解析情報を生成し，解析情報からＨＤＤの交替セクタ状況に関するデータを抽出し」との記載，「交替セクタの使用状況を週単位，月単位，年単位にまとめた交替セクタ監視テーブルと交替セクタ規定閾値テーブルとを比較して」との記載，及び「顧客端末の数値ログ情報の解析結果が所定の閾値を超えている状態，すなわち顧客端末のハードウェアが異常状態にあり，直ちに交換や修理などの保守が必要な状態」との記載からすると，引用発明の「該当するハードウェアの交替セクタについて設定されている規定閾値」は，交換や修理などの保守を行うまでにＨＤＤについて発生する交替セクタの使用状況についての閾値といえるものである。そして，引用文献１の上記Ｂの段落【００１１】に，「保守管理システムが複数の顧客端末の保守を管理している場合に、例えばセクタ異常が所定の回数以上となれば直ちにＨＤＤ交換を行なうなど・・・閾値を一定にしてしまうと・・・保守作業が非効率になったりすることになる」と記載されるように，引用発明のＨＤＤにおいても，交替セクタは，セクタ異常の発生に伴い使用されるものであるといえる。さらに，引用発明では，「保守管理センタは，予防保守判定処理装置を備え」ることから，引用発明の「予防保守判定処理装置」は，保守センタに設置される保守管理のための手段であるといえる，加えて，引用発明の「予防保守判定処理装置は，ログ情報入力部と，ログ情報解析部と，予防保守判定処理部と，判定結果表示処理部と，閾値変更処理部と，データベース群からなる」との記載，「閾値変更処理部は」「ハードエラーが発生する前に保守推奨を行なえるように」「交替セクタ規定閾値テーブルの閾値を変更」との記載，及び上記（イ）の検討内容を踏まえると，引用発明の保守管理システムは，ログ情報を通信回線を通じて受信し，交換や修理などの保守を行うまでに顧客端末のＨＤＤについて発生するセクタ異常の発生の許容値を更新する，保守管理手段を備えるものであるといえる。 してみると，引用発明と本願発明１とは，後記する点で相違するものの，“前記ログ情報を，通信回線を通じて受信し，処置を行うまでに前記保守対象のある個別の構成要素について発生する異常の発生の許容値を，更新する管理手段”を備える点，及び“前記管理手段は保守センタに設置される”点で共通する。 イ　以上から，本願発明１と引用発明とは，以下の点で一致し，また，以下の点で相違する。 （一致点） ある保守対象からそのログ情報を受信し，そのログ情報を通信回線を通じて送信する保守手段と， 前記ログ情報を，通信回線を通じて受信し，処置を行うまでに前記保守対象のある個別の構成要素について発生する異常の発生の許容値を，更新する管理手段と， を備え， 前記管理手段は保守センタに設置される， 保守管理システム。 （相違点１） 本願発明１が，「汎用通信回線」を通じて「ログ情報」を「送信」及び「受信」するものであるのに対し，引用発明の「ネットワーク」は，「通信回線」ではあるが，「汎用通信回線」であることについてまでは明記されていない点。 （相違点２） 本願発明１が，「異常の発生の許容値」を，「その個別の構成要素についてのある期間内に前記異常が発生した回数及び前記期間内に前記異常が発生する回数の予測値のうちのいずれかである対象発生回数と，予め設定した基準値との比較結果に応じて」「更新する」のに対し，引用発明は，そのような比較結果に応じて許容値を更新するものではない点。 （相違点３） 本願発明１が，「許容値を出力する出力手段」を備えるのに対し，引用発明は，「入力装置から入力された任意の値をもとに規定閾値ＤＢの値を変更する」手段を備えるものであるが，「許容値を出力する出力手段」を備えることについて明記されていない点。 （相違点４） 本願発明１が，「保守センタ」は「保守対象の保守を行う者により管理される」ものであり，「保守手段」は「顧客が管理する領域に置かれる」ものであるのに対し，引用発明の「保守管理システム」は，そのような特定がなされていない点。 （相違点５） 本願発明１が，「出力手段は顧客が管理する領域に置かれる」ものであるのに対し，引用発明の「保守管理システム」は，そのような特定がなされていない点。 （２）判断 事案に鑑みて，上記相違点５について先に検討する。相違点５に係る本願発明１の「出力手段は顧客が管理する領域に置かれる」という構成は，上記引用文献１－３，Ｂ，Ｃには記載されておらず，本願の出願日前において周知技術であるともいえない。また，引用発明では，「入力装置から入力された任意の値をもとに規定閾値ＤＢの値を変更する」ものであるところ，仮に，データベースの値を入力装置から変更する上で，その時点での値を画面といった出力手段に出力して確認可能とする技術思想が，本願の出願日前における周知技術であったとしても，引用発明の「入力装置」は，上記引用文献１の上記Ｋの段落【００９４】に，「閾値変更処理部は、入力装置・・・から入力された任意の値をもとに規定閾値ＤＢの値を変更する。これにより、権限を有する管理者は、意図的に規定閾値ＤＢの規定閾値を任意の値に変更し」とあるように，保守センタの管理者によって操作されることを前提とするものであって，この「入力装置」を顧客が管理する領域に設置するべきであるとする課題について何ら言及されておらず，この点において引用発明に対して上記相違点５に係る構成を採用する動機付けを認めることはできない。そして，他に引用発明に対し上記相違点５に係る構成を採用する動機づけも見出すことはできない。 したがって，引用発明に基づいて，相違点５に係る本願発明１の構成とすることは，当業者が容易になし得ることであるとはいえない。 （３）小括 したがって，本願発明１は，他の相違点を検討するまでもなく，当業者であっても引用発明，引用文献２－３，Ｂ，Ｃに記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ２　本願発明２－８について 本願発明２－８は，直接・間接に本願発明１を引用するものであり，本願発明１の「出力手段は顧客が管理する領域に置かれる」ことと同一の構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明，引用文献２－３，Ｂ，Ｃに記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ３　本願発明９について 本願発明９は，本願発明１に対応する方法の発明であり，本願発明１の「出力手段は顧客が管理する領域に置かれる」ことに対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても引用発明，引用文献２－３，Ｂ，Ｃに記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ４　本願発明１０について 本願発明１０は，本願発明１のうち，「保守手段」を省いたものに対応するプログラムの発明であり，本願発明１の「出力手段は顧客が管理する領域に置かれる」ことに対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても引用発明，引用文献２－３，Ｂ，Ｃに記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 第７　原査定についての判断 令和２年７月１０日付けの補正により，補正後の請求項１－８は，「出力手段は顧客が管理する領域に置かれる」という技術的事項を有するものとなり，補正後の請求項９－１０は，当該技術的事項に対応する技術的事項を有するものとなった。当該技術的事項は，引用文献A（当審拒絶理由における引用文献３）には記載されていないので，本願発明１－１０は，原査定における引用文献Ａに記載された発明ではない。また，当該技術的事項は，引用文献Ｂ，Ｃにも記載されておらず，本願出願日前における周知技術でもないので，本願発明１－１０は，当業者であっても，原査定における引用文献Ａ，Ｂ，Ｃに基づいて，容易に発明できたものではない。したがって，原査定を維持することはできない。 第８　むすび 以上のとおり，原査定の理由によっては，本願を拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。