【事件の表示】
　特願２００４−５１２０４０「トラブル対処支援システムおよびこれに接続される端末装置」拒絶査定不服審判事件〔平成１５年１２月１８日国際公開、ＷＯ０３／１０５０３９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１．手続の経緯
　この出願は、平成１５年６月６日（優先権主張平成１４年６月７日、日本）を国際出願日とする出願であって、平成１７年５月１２日付けで拒絶理由が通知され、これに対して同年７月１３日付けで手続補正がなされたが、同年９月９日付けで拒絶査定がなされ、これに対して同年１０月１７日に拒絶査定不服審判が請求され、同年１１月１６日に手続補正がなされたものである。
　
　
第２．平成１７年１１月１６日付け手続補正についての補正の却下の決定
[補正却下の決定の結論]
　平成１７年１１月１６日付けの手続補正（以下、「本件補正」という。）を却下する。
　
[理由]
１．補正の概要
　本件補正は、原査定時の特許請求の範囲の請求項１が、
「【請求項１】
　装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、これらのデータ相互の関連付けと共に記憶する判断経路記憶手段と、
　事象データが入力されると、当該事象に関連する判断材料データを前記判断経路記憶手段から抽出して出力する判断材料提示手段と、
　前記判断材料提示手段が出力した判断材料データのいずれかが選択入力されると、選択入力された判断材料データから特定される原因に関連する対処手順データを、前記判断経路記憶手段から抽出して出力する対処手順提示手段とを備え、
　前記判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されており、
　前記判断材料提示手段が、抽出した判断材料データを前記適合度に従った順に出力することを特徴とするトラブル対処支援システム。」
であったものを、
「【請求項１】
　装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付けと共に記憶する判断経路記憶手段と、
　事象データが入力されると、当該事象に関連する判断材料データを前記判断経路記憶手段から抽出して出力する判断材料提示手段と、
　前記判断材料提示手段が出力した判断材料データのいずれかが選択入力されると、選択入力された判断材料データから特定される原因に関連する対処手順データを、前記判断経路記憶手段から抽出して出力する対処手順提示手段とを備え、
　前記判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されており、
　前記判断材料提示手段が、抽出した判断材料データを前記適合度に従った順に出力することを特徴とするトラブル対処支援システム。」
とするものである。
　
　本件補正によって、「判断経路記憶手段」について、原査定時の（以下、「補正前の」という。）請求項１では、「装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、これらのデータ相互の関連付けと共に記憶する判断経路記憶手段」であったものが、本件補正によって補正された（以下、「補正後の」という。）請求項１では「装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付けと共に記憶する判断経路記憶手段」と変更された。この補正は、「装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧」と共に記憶するものを、「これらのデータ相互の関連付け」から、「前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付け」に変更しているといえる。
　
　
２．補正の適否
　本件補正は、以下の（１）で述べるように特許法第１７条の２第４項の要件を満たしておらず、また、仮に１７条の２第４項の要件を満たしたものであるとしても、（２）及び（３）で述べるように、同条第５項で準用する同法第１２６条第５項の規定に違反している。
　
（１）１７条の２第４項について
　本件補正によって、「前記事象データと判断材料データと原因との関連付け」と、「前記原因と対処手順データとの関連付け」という、２つの「関連付け」の記載が追加された。
　審判請求人は、平成１７年１２月１４日付け手続補正書で補正された審判請求の理由（以下、「審判請求の理由」という。）において、
『また、今般の補正は、上述のとおり、「これらのデータ相互の関連付け」という文言を、データ相互の関連付けの態様をより限定的に記載した「前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付け」という文言に補正したものであり、特許法第１７条の２第４項第２号に掲げる「特許請求の範囲の減縮」を目的としたものです。』
と述べ、この補正が、特許法第１７条の２第４項第２号の「特許請求の範囲の減縮」を目的としたものである旨主張している。
　そこで、追加された２つの「関連付け」が、補正前の請求項１における「これらのデータ相互の関連付け」をより限定的に記載したもの（下位概念）に該当するか判断する。
　
　まず、補正前の「これらのデータ相互の関連付け」という記載に関し、「これらのデータ」が指すものは、先行する記載で列挙されている「装置に生じ得るトラブルの事象データ」、「前記事象の原因を特定するための判断材料となる現象を表す判断材料データ」、及び、「原因に応じた対処手順データ」であると解される。そして、「これらのデータ相互の関連付け」とは、上記３つのデータの相互の関連付けを上記３つのデータと共に記憶することと解される。
　してみると、「これらのデータ相互の関連付け」の関連付けの組合せは、３つのうちの２つの組である、「装置に生じ得るトラブルの事象データ」と「前記事象の原因を特定するための判断材料となる現象を表す判断材料データ」、「装置に生じ得るトラブルの事象データ」と「原因に応じた対処手順データ」、「前記事象の原因を特定するための判断材料となる現象を表す判断材料データ」と「原因に応じた対処手順データ」、及び、３つのデータすべての組である「装置に生じ得るトラブルの事象データ」と「前記事象の原因を特定するための判断材料となる現象を表す判断材料データ」と「原因に応じた対処手順データ」の４通りがある。そこで、本件補正によって追加された、「前記事象データと判断材料データと原因との関連付け」と、「前記原因と対処手順データとの関連付け」という、２つの「関連付け」が、上記４通りのいずれかに該当すれば、補正前の請求項１における「これらのデータ相互の関連付け」をより限定したものといえ、下位概念に含まれるものであるといえる。
　
　つぎに、補正後の「前記事象データと判断材料データと原因との関連付け」、及び、「前記原因と対処手順データとの関連付け」について検討するに、該記載における「前記」が、それぞれどこまで係るのか明確ではない。
　仮に、「前記」が、それぞれその直後の記載である「事象データ」及び「原因」に係るとすると、「原因」についての先行する記載は「前記事象の原因を特定するための」、「原因に応じた」という２カ所の記載があるものの、いずれも「データ」としての記載ではないから、先行する「データ」以外の、「原因」を含む「関連づけ」は、補正前の「これらのデータ相互の関連付け」の範囲には含まれない。
　また、「前記」が、それぞれ「〜関連付け」まで係るとすると、先行するデータあるいはデータの一覧が「原因」とその他の「データ」との「関連付け」であることとなる。その結果、「これらデータ相互の関連付け」という発明を特定する事項が削除されることになる。（また、同じものを２度繰り返して記載することになるので「〜と共に記憶する」という記載と矛盾する。）
　
　してみると、この補正は、「これらデータ相互の関連付け」（前述の４通りの組合せ）に含まれない「関連付け」を新たな発明を特定する事項として追加し、「これらのデータ相互の関連付け」という、発明を特定する事項を削除するものといえる。
　以上のとおりであるから、この補正は、補正前の特許請求の範囲に記載された発明を特定する事項を限定するものとはいえない。
　
　また、請求項１に対しては明りょうでない旨の拒絶理由は通知されていないから、拒絶理由通知に係る拒絶の理由に示す事項についての明りょうでない記載の釈明にも該当しない。
　また、請求項の削除、あるいは、誤記の訂正にも該当しない。
　
　以上のとおり、この補正は、特許法第１７条の２第４項が規定する要件を満たしていない。
　
（２）第１７条の２第５項において準用する第１２６条第５項（３６条６項２号）について
　本件補正が補正前の請求項１における「これらのデータ相互の関連付け」を限定したものという「特許請求の範囲の減縮」に該当するとしても、（１）で述べたとおり、補正によって追加された「前記事象データと判断材料データと原因との関連付け」、及び、「前記原因と対処手順データとの関連付け」という記載における「前記」がそれぞれ何を指すのか明確でなく、また、解釈によっては「と共に」との記載と矛盾することから、「判断経路記憶手段」がどのようなデータをどのように記憶するのか明確に特定することができず、特許を受けようとする発明の範囲が明確でない。
　したがって、補正後の請求項１に記載された発明は、特許法第３６条第６項第２号の要件を満たさないため、特許出願の際独立して特許を受けることができない。
　
（３）第１７条の２第５項において準用する第１２６条第５項（２９条２項）について
　上記（１）、（２）で述べたとおり、補正後の請求項１は、「判断経路記憶手段」についての記載が明確ではない。
　一方、審判請求人は、審判請求の理由、及び、平成２０年１月２１日付けの回答書において、「事象データと判断材料データと原因との関連付け」、及び、「原因と対処手順データとの関連付け」を用いる点を相違点として本願発明の進歩性を主張している。
　そして、発明の詳細な説明の記載、及び、審判請求の理由における主張等を参酌すると、補正後の請求項１に係る発明の「判断経路記憶手段が、発明の詳細な説明における「判断経路データ記憶部１６」、及び、「原因−対処手順対応データ記憶部１７」に対応し、図３Ａ、及び、図３Ｂで示されるような「事象データ」（図中の「症状」）と「判断材料データ」（図中の「判断材料」）と「原因」、「原因」と「対処手順データ」（図中の「対処手順」）のそれぞれの関連付けを記憶していると解釈可能である。
　そこで、念のため、本件補正後の特許請求の範囲に記載されている事項により特定される発明が、特許法第２９条第２項の要件を満たし、特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）否かを、補正後の請求項１に係る発明（以下、「本願補正発明」という。）について判断する。　
                         　
（ａ）本願補正発明
　本願補正発明は、平成１７年１１月１６日付けの手続補正で補正された特許請求の範囲の請求項１に記載された以下のとおりのものである。
「【請求項１】
　装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付けと共に記憶する判断経路記憶手段と、
　事象データが入力されると、当該事象に関連する判断材料データを前記判断経路記憶手段から抽出して出力する判断材料提示手段と、
　前記判断材料提示手段が出力した判断材料データのいずれかが選択入力されると、選択入力された判断材料データから特定される原因に関連する対処手順データを、前記判断経路記憶手段から抽出して出力する対処手順提示手段とを備え、
　前記判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されており、
　前記判断材料提示手段が、抽出した判断材料データを前記適合度に従った順に出力することを特徴とするトラブル対処支援システム。」
            　
　なお、上記のとおり、本願補正発明の　「判断経路記憶手段」についての記載は明確ではないため、発明の詳細な説明の記載等から、「事象データ」、「判断材料データ」、「対処手順データ」、「原因」を「事象データと判断材料データと原因との関連付け」、「原因と対処手順データとの関連付け」と共に記憶するものであると認定する。
  　
（ｂ）引用例・周知例
（ｂ−１）引用例
　原査定の理由で引用文献１として引用した、特開２００１−２８２９４４号公報（以下、「引用例」という。）には、以下の記載がある。
　
（あ）「(57)【要約】
【課題】  精度が高く検索しやすいサービス情報の提供とともに、修理用の部品の迅速な提供を可能とする。
【解決手段】  サービス情報管理サーバ１に、不具合の発生した機器の症状やチェック項目の一覧表から故障原因を検索する症状検索処理部４と、特定された事例から故障原因や対応の回答を行う回答処理部５と、過去の事例や同事例に対応する回答文や、修理に要する部品情報などを記憶するデータベースとを備え、使用者から問い合わせられる不具合に対する症状を検索し、過去の事例から推定される故障原因や対応の回答を行うとともに、故障の修理やチェックなどに必要と推定される部品の注文を受けて処理するための部品受注処理部８と、修理依頼の受付処理を行う修理受付処理部７とを設けた。」
　
（い）「【請求項１】  インターネットを通じて情報を送受信するｗｅｂサーバ上のホームページを介し、不具合の発生した機器のサービス情報の提供や顧客管理などの管理を行なうための、サービスセンターなどに設置されるサービス情報管理サーバと、通信制御部を有し、前記インターネットに接続され前記サービス情報の受発信を行うユーザーやサービスマンなどの使用者が扱う使用者端末とからなるインターネット利用のサービス支援システムにおいて、
前記サービス情報管理サーバは、前記ホームページ上に各種のメニュー画面を生成するための画面生成処理部と、アクセスする使用者を特定するためのＩＤコードやパスワードを認証する認証処理部と、不具合の発生した機器の症状やキーワードなどから故障原因を特定するための事例を検索する症状検索処理部と、特定された事例から回答を行う回答処理部と、検索のためにアクセスされた回数の計数や記憶管理などを行うアクセス管理処理部と、過去の事例や同事例に対応する回答文などを記憶するデータベースと、データや情報の入力を行う操作入力表示部と、機器の制御を行う制御部とを備え、
前記使用者から問い合わせられる不具合に対する症状などを検索し、過去の事例から推定される故障原因などの回答を行い、
前記推定される故障原因に対応して、前記使用者からの、故障の修理やチェックなどに必要とされる部品の注文を受けて処理するための部品受注処理部と、前記使用者からの修理依頼の受付処理を行う修理受付処理部とを設けたことを特徴とするインターネット利用のサービス支援システム。」
　
（う）「【請求項１７】  前記サービス単位と、同サービス単位毎に発生する症状やチェックすべき項目とは、不具合の発生する頻度順に優先度が判定され、同優先度に従って前記症状検索画面での表示順序の並び替えが行われることを特徴とする請求項１記載のインターネット利用のサービス支援システム。」
　
（え）「【請求項１９】  前記回答処理部に、故障原因や対応方法などの回答とともに、修理に要する部品リストを出力する部品リスト作成部を追加設置することを特徴とする請求項１記載のインターネット利用のサービス支援システム。」
　
（お）「【０００１】
【発明の属する技術分野】本発明は、インターネット利用のサービス支援システムに係わり、より詳細には、インターネットを利用して不具合の発生した機器の修理に対し、的確なサービス情報を提供し、併せて迅速な部品の供給を行うことを可能とするインターネット利用のサービス支援システムに関する。」
　
（か）「【００２８】サービス情報管理サーバ１は、使用者からの症状の質問に対し、症状検索処理部４で該当する症状をデータベースから検索し、その症状に対応する回答を回答処理部５でデータベースから検索して回答を行う。症状検索処理部４では使用者がインプットする症状に対するキーワードから検索するキーワード検索と、予めサービス単位毎に症状を一覧表形式で表示させた中から該当する症状を検索するメニュー検索の２種類を用意している。検索画面設定部４ａでは、メニュー検索を迅速に行えるように、症状検索画面の中の症状やチェック項目の並び替えを行う。最も不具合の発生頻度の高い、あるいは最も症状を特定しやすいサービス単位や部品を画面の上部左から配置し、それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い一覧表に配置する。それぞれの項目毎にチェックボックスを設けており、使用者は該当する項目をマウスなどでチェックすればよい。事例分類管理部４ｂでは、質問されたキーワードやチェックされた項目毎に該当する症状に分類し、それぞれのアクセスの計数とともに、事例ベース４ｃに記憶蓄積するように管理を行う。事例ベース４ｃにない検索不能なキーワードについても記憶蓄積管理される。使用頻度の高いキーワードについては、それに対する対応方法を追加するようにしている。部品検索部４ｄは、症状の検索時に、その修理やチェックに必要な部品も併せて検索する。このため、事例ベース４ｃには、事例に応じて修理などに必要な部品情報も併せて記憶している。」
　
（き）「【００２９】回答処理部５では、症状に対応する回答および症状の組合せに対する基本回答事例を蓄積記憶している回答ベース５ｃと、回答ベース５ｃから該当する回答を検索するための回答検索部５ａと、基本回答から回答文を作成するための回答作成部５ｂと、原因や対応の回答と同時に、修理等に必要な部品リストを作成する部品リスト作成部５ｄとからなる。症状に該当する回答事例がある場合はそのままの出力が可能であるが、症状によって複数の基本回答を得る場合は、回答文は合成して出力される。これらの回答文とともに、修理に必要な部品リストも出力される。なお、ここで出力される部品リストは、使用者がそのまま注文できるフォーマットで表示される。これにより迅速な対応とともに、修理の見積もりが即座に推定できるという特徴をもつ。」
　
（く）「【００３０】アクセス管理処理部６では、使用者の分類毎にアクセス数を計数するアクセス計数部６ａ、アクセスされた質問を追跡するために使用者の分類毎に整理番号を付与して管理する整理番号管理部６ｂ、質問に対する回答が的中したかどうかを判定する的中判定部６ｃ、質問に対する回答が的中した事例および的中しなかった事例をそれぞれ計数する的中計数部６ｄ、的中した的中確率を算出するための的中確率算出部６ｅ、不具合の発生頻度から検索用項目の優先度を判定する優先度判定処理部６ｆ、アクセスされた質問に対する的中、不的中を使用者に問い合わせるための電子メールを作成、送出する電子メール送出処理部６ｇ、使用者から返信される電子メールを解読し、的中、不的中を抽出する電子メール受信処理部６ｈとからなる。アクセス計数部６ａでは症状やチェック項目ごとにアクセス数を計数しているが、アクセス数の多寡により、不具合部品や症状毎の発生頻度の傾向の把握が可能となる。新たな不具合の発見や検索精度の向上、さらには製品の品質向上に反映させることができる。
【００３１】的中確率算出部６ｅでは、的中計数部６ｄの結果より、症状毎に回答の的中率を算出する。的中確率は回答画面中に提示してもよい。また、的中率の少ない回答については装置からアラームを上げ、該アラームを受けてサービスの熟練者が得られた各種データを参考にして回答内容を見直すようにしている。これらの運用と更新とを繰り返すことで、回答の的中確率を上げ、検索精度を向上させることができる。優先度判定処理部６ｆでは不具合の発生頻度の最も多い項目を判定し、該当する項目を優先度を高いものとしている。この優先度判定処理部６ｆの判定結果により症状検索画面での症状やチェック項目などの表示位置を優先度順に並び替え再設定する。不具合の発生の多い順に配列されるので、発生状況を確認しやすくしている。」
　
（け）「【００３７】図２は本実施例における不具合の検索から部品の受注に至るまでの、業務フローの概要を説明するためのフローチャート図である。図３以降の図は、エアコンを選択した場合のホームページから参照される、図３は症状検索画面、図４は回答画面、図５は修理受付画面、図６は部品注文画面、図７は注文確認画面のそれぞれの例を示すものである。図３ないし図７の画面例を参照して図２に基づいて説明する。ホームページで技術相談のボタンをヒットすると、図３に示すような症状検索画面が使用者端末Ｄに表示される。不具合の症状についての原因および対応方法についての回答の検索は、機種名とキーワードを入力して検索開始ボタンをヒットするか、画面の一覧に示される該当する症状の左側のチェックボックスをチェックし、検索開始ボタンをヒットすることで検索がスタートする（ＳＴ１）。」
　
（こ）「【００３８】キーワード検索の場合（ＳＴ２）、ステップ１５へジャンプする。チェックボックスに一項目でもチェックがあれば、その該当する症状やチェック項目について検索を行う（ＳＴ３）。検索は、事例ベース４ｃに記憶された過去の症状事例を検索し（ＳＴ４）、一致すればその症状が特定されるので、ステップ６（ＳＴ６）へジャンプし、一致しなければ、一致度の高いものを抽出する。特に、チェック項目が複数にわたると事例にない場合が生じやすい。この場合、一致する数の多いものを一致度が高いと判定するようにし、上位から数例を抽出する（ＳＴ５）。症状が一致する場合、該当する回答を回答ベース５ｃから検索し、回答文を表示させる。回答文は基本回答を合成するが、回答が複数例ある場合は、例えば上位から３例まで表示させる（ＳＴ６）。これらの症状の検索と連動して修理に必要な部品リストも出力される。推定故障原因や対応についての回答例は図４に示すように、症状、推定故障、および推定故障箇所・対応などが表示される。使用者がサービスマンの場合、提示された内容に従って、修理対応を行えばよい。なお、使用者が一般ユーザーの場合、推定故障のみが表示されるようにしている。質問の症状が過去の事例になく、新規の事例である場合には、症状と回答とをそれぞれ事例ベース４ｃ、回答ベース５ｃに記憶させる（ＳＴ７）。なお、部品リストは、図６に示す部品注文画面であるが、説明は後述する。」
　
（さ）「【００４２】以上、エアコンの実施例について説明した。エアコンの場合、図３の症状検索画面に示されるように、横軸の症状やチェック項目および縦軸のサービス単位が少なく、一覧表に収まる程度であるが、優先度判定処理による不具合の発生頻度順に並び替えを行うと、それらの状況を一目で確認することができる。症状やチェック項目およびサービス単位が多い機器では、さらに効果を上げることができる。これらの並び替えの機能は選択可能としてもよい。」
　　
　引用例の記載（あ）によれば、引用例には、「不具合の発生した機器の症状やチェック項目の一覧表から故障原因を検索する症状検索処理部４」と「特定された事例から故障原因や対応の回答を行う回答処理部５」と、「過去の事例や同事例に対応する回答文や、修理に要する部品情報などを記憶するデータベース」とを備え、「使用者から問い合わせられる不具合に対する症状を検索し、過去の事例から推定される故障原因や対応の回答を行う」サービス支援システムが記載されているといえる。
　
　引用例の記載（か）によれば、「症状検索処理部４」で、使用者からの症状の質問に対し、該当する症状をデータベースから検索すること、「回答処理部５」で、その症状に対応する回答を回答処理部５でデータベースから検索して回答を行うことが記載されているといえる。
　また、「症状検索処理部４」は、「キーワード検索」と「予めサービス単位毎に症状を一覧表形式で表示させた中から該当する症状を検索するメニュー検索」を用意しており、メニュー検索を迅速に行えるように、最も不具合の発生頻度の高い、あるいは最も症状を特定しやすいサービス単位や部品を画面の上部左から配置し、それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い一覧表に配置する、「症状検索画面の中の症状やチェック項目の並び替え」を行うことが記載されているといえる。
　ここで、記載（か）が参照する「症状検索画面」の例である図３をみると、「室内機表示ランプ」、「室内機」、「室外機」が「サービス単位や部品」に該当すると解される。
　また、「それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い一覧表に配置する」とあるから、図３における「室内機表示ランプ」、「室内機」、「室外機」の項目のそれぞれの下部に記載されている「□タイマーランプ点滅」、「□冷える／暖まる」、「□動作する」、等の記載は、「症状や必要なチェック項目」であると解される。
　
　引用例の記載（き）によれば、「回答処理部５」は、「症状に対応する回答および症状の組合せに対する基本回答事例を蓄積記憶している回答ベース５ｃ」と、「回答ベース５ｃから該当する回答を検索するための回答検索部５ａ」と、「基本回答から回答文を作成するための回答作成部５ｂ」とを備えているといえる。
　
　引用例の記載（く）によれば、「アクセス管理処理部６」では、「不具合の発生頻度から検索用項目の優先度を判定する優先度判定処理部６ｆ」を備え、該「優先度判定処理部６ｆ」は、「不具合の発生頻度の最も多い項目を判定し、該当する項目を優先度を高いもの」とすること、この優先度判定処理部６ｆの判定結果により「症状検索画面での症状やチェック項目などの表示位置を優先度順に並び替え再設定」することが記載されているといえる。
　
　引用例の記載（け）によれば、ホームページで技術相談のボタンをヒットすると、図３のような症状検索画面が使用者端末に表示され、画面の一覧に示される該当する症状の左側のチェックボックスをチェックし、検索開始ボタンをヒットすることで検索がスタートすることが記載されているといえる。
　
　引用例の記載（こ）によれば、事例ベース４ｃに記憶された過去の症状事例を検索し、一致するもの、若しくは、一致度の高いものが、過去の症状事例から抽出され、症状が一致する場合、該当する回答を回答ベース５ｃから検索し、図４のような回答画面が表示され、症状、推定故障、および推定故障箇所・対応などが表示されることが記載されているといえる。
　また、「使用者がサービスマンの場合、提示された内容に従って、修理対応を行えばよい」と記載されているから、提示される内容は、サービスマンが修理対応を行うための情報であるといえる。
　そして、記載（こ）が参照する図４によれば、「症状」の欄の「ランプ」の項に「タイマーランプ点灯」と記載され、「推定故障」の欄に、「室外機と室内機の間でシリアル信号の送受信エラーが発生しているものと思われます。修理をご依頼ください。」と記載され、「推定故障箇所・対応」の欄に、「１　コンプレッサのＵＶＷ端子を外した状態で電源を入れ、室外機のファンが回ればコンプレッサの故障。回らなければインバータ基板かトランジスタモジュールの故障が考えられる。」、「２　トランジスタモジュールのプラス端子（黄色）を外した状態で電源を入れ、室外機のファンが回ればトランジスタモジュールの故障なので部品交換。」、「３　上記の確認で室外機のファンが回らない場合はトランジスタモジュールとインバータ基板を同時に交換する。」と記載されている。
　
　引用例の記載（さ）によれば、症状検索画面の、「横軸の症状やチェック項目」および「縦軸のサービス単位」について、不具合の発生頻度順に並べ替えを行うこと、並べ替えの機能を選択可能としてもよいことが記載されている。
　
　引用例の記載（あ）〜（さ）及び図面の記載から、引用例には、以下の発明（以下、「引用発明」という。）が記載されているといえる。
「不具合の発生した機器の症状やチェック項目の一覧表から故障原因を検索する症状検索処理部４と、
　特定された事例から故障原因や対応の回答を行う回答処理部５と、
　過去の事例や同事例に対応する回答文や、修理に要する部品情報などを記憶するデータベースとを備え、
　使用者から問い合わせられる不具合に対する症状を検索し、過去の事例から推定される故障原因や対応の回答を行う、
　サービス支援システムにおいて、
　ホームページで技術相談のボタンをヒットすると、
　症状検索処理部４は、最も不具合の発生頻度の高い、あるいは最も症状を特定しやすいサービス単位や部品を画面の上部左から配置し、それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い一覧表に配置した症状検索画面を端末に表示し、
　画面の一覧に示される該当する症状の左側のチェックボックスをチェックし、検索開始ボタンをヒットすることで検索がスタートし、
　症状検索処理部４で、事例ベース４ｃに記憶された過去の症状事例を検索し、一致するもの、若しくは、一致度の高いものが、過去の症状事例から抽出され、
　回答処理部５で、抽出された症状に該当する回答を回答ベース５ｃから検索し、
　回答処理部５で、症状、推定故障、および推定故障箇所・対応などを含む回答画面を端末に表示する、
サービス支援システム。」
　
　
（ｂ−２）周知例１
　原査定の理由で請求項５乃至９に対する引用文献２として引用した、特開平１０−１２４４７７号公報（以下、「周知例１」という。）には、以下の記載がある。
　
（し）「【０００１】
【発明の属する技術分野】本発明は、故障診断方法に係り、製品が故障や異常を起こした場合に、故障または異常からの復旧を支援するシステム上で用いられる方法であって、特に、故障のための調査の条件が細かく分析できる対象に用いて好適であって、故障の調査に関する条件に関して、何を優先して調査するかを細かく指定できる故障診断方法に関する。」
　
（す）「【０００７】
【課題を解決するための手段】上記目的を達成するために本発明に係る故障診断方法の構成は、故障診断システムを用いて、故障した製品対象と故障現象を入力して、対策のための調査項目を提示する故障診断方法において、この故障診断システムは、故障した製品対象と故障現象を入力する手段と、調査項目レコードのデータベースと、前記調査項目レコードを並び替える手段と、前記調査項目レコードを検索する手段と、前記調査項目レコードを調査項目リストとして表示する表示手段とを備え、前記調査項目レコードは、一つ以上の調査条件を有し、入力された前記故障した製品対象と前記故障現象から、前記調査項目レコードを検索する手段によって、前記調査項目レコードのデータベースから、該当する調査項目レコードを検索し、前記調査項目の有する調査条件に対して、優先する順位を入力して、その順位によって、前記検索された調査項目レコードを順位づけて、調査項目リストとして前記表示手段に提示するようにしたものである。」
　
（せ）「【００１５】ルール管理部１０２は、図２に示すように（ａ）故障現象−故障部位関連テーブル２０１、（ｂ）故障部位−対策方法関連テーブル２０２を具備している。また、調査情報管理部は、（ｃ）故障条件管理テーブル２０３を具備している。故障現象−故障部位関連テーブル２０１は、故障現象と構成部位の因果関係を対として保持し、管理するテーブルである。
【００１６】故障部位−対策方法関連テーブル２０２は、故障している構成部位とそれに対応する対策方法を対として保持し、管理するテーブルである。
【００１７】故障成立条件管理テーブル２０３は、故障成立条件を、それぞれの故障現象と故障部位に対応して保持し、管理するテーブルである。ここで、故障成立条件とは、故障現象に対して構成部位が故障であるとされるための条件あり、構成部位が故障であることを特定するために必要な調査項目とその調査結果からなっている。
【００１８】この図２（ｃ）の例で説明すると、故障現象「ドア閉まらず」が発生した場合に故障を起こしている構成部位が「リレー」であることの故障成立条件は、調査項目「抵抗値確認」において、調査結果が「ＯＫ」となり、かつ調査項目「入力電圧確認」において、調査結果が「ＮＧ」となることである。すなわち、故障現象「ドア閉まらず」が発生した場合に調査員が、この二つの項目を調査して、上記のような結果が得られたときに、故障部位が「リレー」であると特定できることになる。」
     　
（そ）「【００４０】〔故障診断システムの動作〕次に、図７および図８を用いて本発明に係る故障診断システムの動作について説明する。図７は、本発明に係る故障診断システムの表示画面を示す図である。図８は、本発明に係る故障診断システムによる診断手順を示すフローチャートである。
【００４１】先ず、故障が発生すると、Ｓ１においてユーザは入力装置１１１を用いて、故障した製品の固有情報（製品名７０２、型式７０３、製造番号７０４等）と故障現象７０９を入力する（Ｓ１）。また、ユーザが故障成立条件をチェックする際に優先する項目７０５と制約条件７０６を入力する。優先項目７０５とは、調査にあたって優先すべき項目であり、図７の例では、「時間」、「コスト」、「絞り込み能力」、「難易度」がある。これらの優先項目は、「時間」は、時間のかからないものから調査し、「コスト」は、コストのかからないものから調査することを示している。また、「絞り込み能力」は、絞り込み能力の高いものから調査をすることを意味している。このようにすれば、一つの調査項目で、確認できる事項が多くなるので、故障の原因が迅速に判明できることが期待できる。「難易度」は、調査の容易な項目から調査せよということである。これは、調査員が熟練者でないいときに有効な調査項目であろう。
【００４２】この例では、難易度が高く、かつ、コストがある程度かかっても、時間を優先し、早急に調査すべきであることを示している。また、この例では、優先項目として選択できるものは、一つだけになっているが、優先項目を番号付けできるようにして、優先項目の間にもプライオリティを設けることも考えられる。
【００４３】制約条件７０６は、調査にあたっての制約となる条件を具体的にあげたものである。図７に示す例では、制約条件として、調査のための人員が一人であり、調査のために使える装置がテスタであることを示している。システムは、制約条件７０６に反する調査項目があるときには、警告を発するようにしても良いし、以下に述べる調査項目リスト７０８に表示しないようにしても良い。
【００４４】次に、故障現象から故障と考えられる構成部位、故障現象と構成部位の因果関係の強さ（故障率または構成部位が過去に故障であると特定された故障回数で、図７の例では両方表示している。）、構成部位に対して故障と特定するに必要な調査項目、構成部位が故障であると特定するまでに必要な調査回数が、故障部位候補リスト７０７に表示される（Ｓ２）。
【００４５】そして、故障部位候補リスト７０７には、原則として、故障現象に対して故障部位候補が因果関係の強い順に表示される。故障率と故障回数のどちらを重視するかは、ユーザがコマンド等により切り換えれるようにすることができる。また、常に、故障率を優先して、故障部位候補リスト７０７に順位付けることにし、故障率を持たない、あるいは、判明していない場合には、故障回数から、一定の基準で求めることにしても良い。
【００４６】また、因果関係の強さで順序を付ける際に、例えば、故障率で因果関係の強さを決定していれば、１番目と２番目以降の故障率の差が判別式β未満であれば、必要調査回数の小さい故障部位候補について成立条件のチェックをおこなうようにしてもよい。これは、故障率の差よりも調査回数が少なくて済むかも知れないという調査の能率を重視するときである。因果関係の強さを回数で決める場合も同様にしてもよい。
【００４７】故障部位候補のリレーに関する調査項目を選択するときには、故障部位候補リスト７０７のその表示部分を、マウスでクリックすれば良い。
【００４８】そうすると、調査項目一覧に故障である構成部位を特定するために必要な調査項目リスト７０８が一覧表示される（Ｓ３）。図７に示す例では、表示画面７０１には調査項目に必要な時間、コスト、難易度、人員、絞り込み能力、使用装置が、調査項目リスト７０８に表示されている。
【００４９】調査項目は、ユーザがあらかじめ設定した優先項目、制約条件において順序つけされており、その順に調査項目リスト７０８に表示される。調査順序を決定する際、例えば、故障復旧時間を短縮することをユーザが目指していれば、優先項目として、時間と絞り込み能力を併用して、１番目に調査時間の短い調査項目と２番目以降に調査時間の短い調査項目を比較して、その差が判定値α以下であれば、絞り込み能力の高い調査から実行するようにすれば合理的である。このように、調査項目のプライオリティとその組合せを、ユーザが任意に変更できるようにすれば、調査の柔軟性を増すことができる。
【００５０】次に、ユーザは、順位の高い調査項目に関する調査を実施する（Ｓ４）。このときに、コスト優先の場合は、コストのかからない調査項目からおこなうようにし、時間優先の場合は、時間のかからない調査からおこなうようにする。
【００５１】故障部位「リレー」に関していうと、もし本当に「リレー」が故障しているのであれば、コストを優先しても時間を優先している場合であっても、故障成立条件となっている全ての調査項目についてチェックをおこなうことになるが、故障成立条件をチェックする過程で故障成立条件を満たしていない（つまりは「リレー」は故障していない）となれば、結果として、コスト優先の場合は、コストのかからない調査項目からおこなうようにしているので、コストを押さえられるし、時間優先の場合は、時間のかからない調査からおこなうので、調査に要する時間を押さえることができる。
【００５２】ユーザは、調査項目に関する調査を実行後に、図７の調査結果欄７１０に結果を入力する。
【００５３】そして、システムは、入力された調査結果に基づいて、図２に示されるテーブル２０３に記された全ての故障成立条件（「リレー」だけでなく「トランス」「ドアモータ」他の故障成立条件を含む）をチェックする。
【００５４】調査結果が故障成立条件を満たしていなければ（Ｓ５）、その構成部位は故障でないとして、次に、因果関係の強い故障部位候補について必要な調査項目を調査項目リスト７０８に表示する。故障成立条件を満たしていれば、Ｓ６に進む。故障成立条件を満たさないものは、故障部位候補リスト７０７の故障成立条件に「不成立」と記入される。すなわち、「不成立」と記入された故障部位は、故障とは関連しないことが確かめられているわけである。
【００５５】故障成立条件に含まれる調査項目全て（「リレー」であれば「抵抗値確認」「入力電圧確認」）を実行して故障が成立すれば（Ｓ６）、故障部位候補リスト７０７の成立条件が「成立」と表示され、Ｓ７に進む、全てを実行していなければＳ４に進み、ループする。
【００５６】故障成立条件をチェックして故障している構成部位が特定でき（Ｓ６）、で実際に対策を行い復旧すれば（Ｓ７）、稼動時間における故障回数を更新する。対策を行った結果復旧しなければ、Ｓ３に進み、故障部位候補の選択からやりなおす。このようにして、故障が復旧すれば故障診断を終了することになる。」
　
　周知例１の記載（し）〜（そ）によれば、製品が故障や異常を起こした場合に、故障または異常からの復旧を支援するシステムにおいて、故障現象と構成部位の因果関係を対として保持し、管理するテーブルである、「故障現象−故障部位関連テーブル２０１」と、故障している構成部位とそれに対応する対策方法を対として保持し、管理するテーブルである「故障部位−対策方法関連テーブル２０２」と、故障現象に対して構成部位が故障であるとされるための条件であり、構成部位が故障であることを特定するために必要な調査項目とその調査結果からなる故障成立条件を、それぞれの故障現象と故障部位に対応して保持する、「故障成立条件管理テーブル２０３」を備え、故障現象が発生した際に故障現象と調査項目の結果から故障部位を特定するシステムが記載されているといえる。
　また、周知例１において、故障部位が特定された後に、「故障部位−対策方法関連テーブル２０２」を参照することで、故障部位に対する対策方法を提示できることは明らかである。
　
　
（ｂ−３）周知例２
　また、この出願の出願前に頒布された刊行物である、特開平９−２６８０５号公報（以下、「周知例２」という。）には、以下の記載がある。
　
（た）「(57)【要約】
【課題】  設備異常の的確且つ迅速な把握が可能であるとともに、適切な復旧対策をとることができる。
【解決手段】  設備１制御用のプログラマブル・コントローラＰＣの入出力信号及びプログラマブル・コントローラの内部フラッグの状態やその変化の情報を時間情報と共に連続記録する記録手段２と、記録された情報をタイムチャートとして表示する表示手段３と、記録された上記情報と予め記録された正常動作中の情報とを比較して記録された情報についての評価を行う評価手段４と、評価手段による評価結果と故障判定知識ベースとを用いて設備の動作状態や故障発生時の原因の推定と対応する復旧方法の指示とを行う原因追及・復旧指示手段５とを備える。その設備について精通していなくとも、異常の症状の正確な把握及び原因の正確な特定並びに適切な復旧処理を行うことができる。」
　
（ち）「【００１４】原因追及・復旧指示手段５はこのような点に対処すべく設けたものであって、この原因追及・復旧指示手段５は、上記設備１に関して考えられる異常や以前に生じた異常についての原因をまとめた原因追及知識ベースと、各原因についての復旧対策をまとめた復旧方法知識ベースとからなる故障判定知識ベースを元にしたエキスパートシステムとして構築してある。そして、原因追及・復旧指示手段５は、オペレータとの対話入力と、上記評価手段４による評価結果とから、設備１に生じた異常の原因の追及と、その原因に対する復旧対策とを故障判定知識ベースから求めて、原因及び復旧対策をオペレータに指示する。
【００１５】ここで、ある異常を招く原因の候補が複数ある場合には、全原因候補を表示するとともに、各原因候補についての確度をたとえば％表示で付記するようにしておくと、原因の確定作業についての優先度が明らかとなるために、確定が容易となる。また、復旧対策の指示にあたっては、単に文章で指示するのではなく、復旧対策を施すべき部材の位置や箇所を図示するものとしておくことが好ましい。たとえば評価手段４における評価によって異常が設備１における特定のシリンダーの動作にあることが判明し、さらに原因追及・復旧指示手段５による原因追及によって上記シリンダーの前進限検知センサーに異常があると判定するとともに、原因候補として上記センサーの位置ずれ、センサー自体の故障、センサーの断線がある時、これら原因候補について、センサーの位置ずれである可能性が９０％、センサー自体の故障である可能性が９％、センサーの断線である可能性が１％であるというように表示するわけであり、復旧対策については、各原因について、上記センサーの本来あるべき位置やその動作確認の方法等を図面を利用して表示するのである。このように原因の追及と復旧指示とがなされた場合、オペレータがその設備１について精通しなくても、異常原因を迅速に特定することができる上に、異常原因の除去による復旧も迅速に且つ的確に行うことができる。この原因追求結果や復旧対策指示についても、単に画面に表示するだけでなく、報知手段６により、音声出力やプリントアウト出力を行うようにしておくと、オペレータに対して強い訴求力をもった指示を行うことができる。この時、設備の動作状態や異常発生時の発生状況などと合わせて、レポートを自動作成するようにしておくとよい。」
    　
　周知例の記載（た）及び（ち）によれば、設備の動作状態や故障発生時の原因の推定と対応する復旧方法の指示とを行う原因追及・復旧指示手段５が、設備１に関して考えられる異常や以前に生じた異常についての原因をまとめた原因追及知識ベースと、各原因についての復旧対策をまとめた復旧方法知識ベースを備え、オペレータとの対話入力と、上記評価手段４による評価結果とから、設備１に生じた異常の原因の追及と、その原因に対する復旧対策とを故障判定知識ベースから求めて、原因及び復旧対策をオペレータに指示することが記載されているといえる。
      　
        　
（ｂ−４）周知例３
　また、この出願の出願前に頒布された刊行物である、特開昭５９−５３０３号公報（以下、「周知例３」という。）には、以下の記載がある。
　
（つ）「つぎに異常や事故の診断装置２１では、異常や事故の原因を診断する。診断法は多く考えられるがここでは先に述べたイノベイション系列｛ｅ（ｔ）｝の共分散行列Ｖ（ｔ）の値をもとにした診断法を１例として取り上げる。データベース２２には、あらかじめシミュレーションによって種々の事故や異常についてイノベイション解析を行ない、事故や異常が発生してからのある有限時間の共分散行列のトレンドＳ（ｔ）がファイルされている。（中略）以上のようにして、異常や事故の発生が検定された場合に、その原因を診断することができた」（３頁右下欄５行目〜４頁左上欄７行目）
　
（て）「つぎに、この診断結果にもとずいて、安全系統操作のための運転ガイダンスを行うために、ガイダンス装置２３を用意する。ガイダンス装置２２では原因の異なる異常や事故毎に、安全系統を動作させるための操作シーケンスがファイルされているデータベース２４を有していて、診断装置で判定された原因に応じて操作シーケンスを取り出す。表示装置２４によって、運転員が操作すべき操作を時間チャートとして図示する」（４頁左上欄８〜１６行目）
　
　周知例３の記載（つ）及び（て）によれば、異常や事故の診断装置２１では、データベース２２に事故や異常についての診断に用いるデータがファイルされており、該データベースを用いて事故の原因を診断し、ガイダンス装置２３（２２とあるのは、２３の誤記と解される）を用意し、ガイダンス装置２３に原因の異なる異常や事故毎に、安全系統を動作させるための操作シーケンスがファイルされているデータベース２４を用意し、診断装置で判定された原因に応じて操作シーケンスを取り出し、表示装置２４によって運転員が操作すべき操作を時間チャートとして図示することが記載されているといえる。
　
　
（ｃ）対比
　本願補正発明と引用発明とを対比する。
　引用発明における「機器」は、本願補正発明における「装置」に相当する。
　引用発明における「不具合」は、本願補正発明における「トラブル」に相当する。
　本願補正発明における「事象データ」がどのようなものであるのか、請求項１には具体的な記載がないため、その内容が明確ではない。そこで、発明の詳細な説明の記載を参照すると、特許法第１８４条の６第２項の規定により出願当初の明細書とみなされる国際特許出願の明細書（以下、単に「明細書」という。）の７頁２〜１２行には、「修理作業の際、サービスエンジニアは、まず、ユーザ機器の故障の症状をＳＥ端末機Ｐへ入力する。故障の症状が同じであってもその原因は様々であることが多いので、故障を適切にかつ効率的に直すためには、故障の原因を正しくすみやかに見極めることが重要である。サービス支援システム１は、ユーザ機器の種類毎に、想定し得る故障の各々について、症状およびその原因、並びに、その症状から原因を特定するための判断材料を、互いに関連付けてデータベースに記憶している。そして、サービスエンジニアがＳＥ端末機Ｐから症状を入力すると、サービス支援システム１は、入力された症状に応じて、原因を特定するために有効であると考えられる判断材料の候補を前記データベースから選択し、適切な優先順位で、ＳＥ端末機Ｐのディスプレイに表示させる。」との記載があり、「（故障の）症状」を入力すると入力された症状に応じて判断材料の候補を表示するように記載されており、当該記載は、本願補正発明における、「判断材料提示手段」についての記載と対応すると解される。してみると、本願補正発明における「事象」とは、「故障の症状」であるといえる。
　また、本願補正発明における「判断材料」について、請求項１の記載は、「事象の原因を特定するための判断材料となる現象を表す」という記載があるものの、抽象的な用途が述べられているという程度の記載であり、（前記「事象」との違いも含めて）その具体的内容が明確でない。そこで、発明の詳細な説明の記載を参照すると、明細書７頁１６〜１７行には、「サービスエンジニアは、ＳＥ端末機Ｐに表示される判断材料について優先順位の高い順に確認作業を行うことにより、故障原因を特定する。」との記載があるから、要するに、サービスエンジニアが確認作業をする項目であるといえる。
　一方、引用発明の「症状検索画面」で入力する「症状やチェック項目」には、故障の症状や、サービスマンが確認（チェック）する項目が含まれているといえるから、引用発明における「症状やチェック項目」は、本願補正発明における「事象」及び「判断材料」の両方に相当する。
　
　引用発明において、「症状検索画面」に表示される「症状やチェック項目」は、「最も不具合の発生頻度の高い、あるいは最も症状を特定しやすいサービス単位や部品を画面の上部左から配置し、それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い」表示されるものである。この「発生頻度」や「症状の特定しやすさ」、「優先度」といった並べ替えの基準は、表示順序を決めるための指標である点で、本願補正発明における「適合度」と共通する。
　また、「発生頻度」や「症状の特定しやすさ」、「優先度」といった並べ替えの基準は、並べ替える対象である「サービス単位や部品」、「症状やチェック項目」と関連付けられて記憶されていることは明らかである。
　
　また、「症状検索画面」に表示される「該当する症状の左側のチェックボックスをチェックし、検索開始ボタンをヒットすること」は、本願補正発明における「判断材料データ」を「選択入力すること」に相当する。
　
　引用発明における「推定故障箇所・対応」は、「症状検索画面」で入力された「症状やチェック項目」を用いて検索・抽出される情報であり、推定される故障箇所の情報、及び、サービスマンが修理対応をする際に参照する情報を含むから、本願補正発明における、「対処手順データ」に相当する。
　
　引用発明における「症状検索画面」で入力されたデータで「事例ベース４ｃ」を検索することで特定される「事例」は、該「事例」に対する「故障原因や対応の回答」を「回答ベース５ｃ」から検索（抽出）する際に用いられるデータである。
　一方、本願補正発明における「原因」は、「判断材料データ」から特定される「原因」に関連する「対処手順データ」を抽出する際に用いられると解されるから、（事象及び）「判断材料データ」から「対処手順データ」を抽出する際に特定されるデータである。
　してみると、「判断材料データ」から「対処手順データ」を抽出する際に特定されるデータである点で、引用発明における「事例」と、本願補正発明における「原因」とは共通する。
　
　引用発明における、「過去の事例や同事例に対応する回答文や、修理に要する部品情報などを記憶するデータベース」である、「事例ベース４ｃ」及び「回答ベース５ｃ」は、システムで用いられるデータを記憶する記憶手段である点で、本願補正発明における「判断経路記憶手段」と共通する。
　
　また、引用発明における「症状検索画面」、及び、「回答画面」を端末に表示することは、本願補正発明における「出力」に相当する。
　
　してみると、本願補正発明と引用発明とは、以下の点で一致し、また、以下の点でそれぞれ相違する。
　
（一致点）「システムで用いられるデータを記憶する記憶手段を備え、
　装置に生じるトラブルの判断材料データを、表示順序を決めるための指標に基づく順に出力し、
　判断材料データが選択入力されると、入力された判断材料データから特定されるデータに関連する対処手順データを、記憶手段から抽出して出力する
　システム」である点。
　
（相違点１）本願補正発明は、「事象データが入力される」と「判断材料データ」を出力するのに対して、引用発明ではそのようになっていない点。
　
（相違点２）対処手順を抽出するために、入力された判断材料から特定されるデータが、本願補正発明では、「原因」となっているのに対して、引用発明では、そのようになっていない点。
　
（相違点３）システムで用いられるデータを記憶する記憶手段について、本願補正発明は、「事象データ」、「判断材料データ」、「対処手順データ」、「原因」を「事象データと判断材料データと原因との関連付け」、「原因と対処手順データとの関連付け」と共に記憶するものであるのに対して、引用発明ではそのようになっていない点。
　
（相違点４）本願補正発明では、「判断材料提示手段」が判断材料データの抽出及び出力までを行い、「対処手順提示手段」が、「判断材料データ」が「選択入力」された以降の処理を行うようになっているのに対して、引用発明ではそのようになっていない点。
　
（相違点５）判断材料データの表示順序を決めるための指標について、本願補正発明では、「適合度順」であるのに対して、引用発明では、そのようになっていない点。
　また、本願補正発明では、「判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されて」いるようになっているのに対して、引用発明では、そのようになっていない点。
　
　
（ｄ）判断
上記相違点１乃至５について、それぞれ、判断する。
　
（相違点１について）
　本願補正発明は、「事象データ」が入力されると、当該「事象」に関連する「判断材料データ」を抽出して出力するように構成されているのに対して、引用発明は、「ホームページで技術相談のボタンをヒット」すると、症状検索処理部４は、最も不具合の発生頻度の高い、あるいは最も症状を特定しやすいサービス単位や部品を画面の上部左から配置し、それらの下部に症状や必要なチェック項目を発生頻度や優先度に従い一覧表に配置した症状検索画面を端末に表示するようになっており、「症状や必要なチェック項目」を一覧表示する構成になっている。
　上記「（ｃ）対比」で検討したとおり、本願補正発明における「事象」とは、故障の症状であり、「判断材料」とは、サービスエンジニアが確認作業をする項目であると解される。
　してみると、引用発明は、「症状や必要なチェック項目」という形で、本願補正発明でいう「事象」と「判断材料」を分けずに一度に表示・入力するように構成されているといえ、この点で「事象データ」が入力されると、当該「事象」に関連する「判断材料データ」を抽出して出力するように構成されている本願補正発明と相違する。
　しかし、「故障の症状」をサービスエンジニアが確認することは通常行われることであるし、サービスエンジニアが確認する対象は、故障の症状であるといえる。また、本願補正発明において、「事象」及び「判断材料」はともに「原因」と関連付けられているように記載され、どちらも「原因」を特定するための情報として扱われるものといえるから、本願補正発明における「事象」と「判断材料」の内容に実質的違いはないといえる。
　してみると、本願補正発明における、「事象データ」が入力されると、当該「事象」に関連する「判断材料データ」を抽出して出力する構成は、要するに、「原因」を特定するために、故障の症状や確認作業をする項目を段階的に絞り込むものといえる。
　一方、段階的に症状を絞り込むことは、故障の診断・修理において通常行われることである。引用例においても、検索の結果表示される回答画面の中に更なる確認作業が示されている（図４の「推定故障箇所・対応」の記載を参照。）ように、記載ないし示唆されているといえる。
　してみれば、引用発明において、一覧表示される「症状及び必要なチェック項目」について、段階的に絞り込む構成を採用し、「事象（症状）」を選択した後に「判断材料（必要なチェック項目）」を出力するように構成することは、当業者が必要に応じて容易になし得たことである。
　
（相違点２について）
　故障や不具合に対する対処を支援するシステムにおいて、症状等から原因を特定し、特定された原因に対する対処を提示するシステムは、例えば、周知例１〜３に記載されているように、この出願の出願前において周知のことである。
　してみれば、引用発明において、「症状やチェック項目」から「原因」を特定し、該原因に対する「対応」を出力するように構成することは、当業者が容易になし得たことである。
　そして、その際に、原因を特定するための症状と原因を関連付けたデータと、原因に対する対処を提示するための原因と対処を関連付けたデータを別にもつことは、同じく、周知例１〜３に記載されているように一般的に行われていることであり、引用発明においても、「事例ベース４ｃ」と「回答ベース５ｃ」というようにデータベースを分けていることから、上記のような周知のデータ構成をとることは当業者が容易になし得たことである。
　
（相違点３について）
　引用発明における「事例ベース４ｃ」は、「症状やチェック項目」から「事例」を抽出するために用いられることから、「症状やチェック項目」、「事例」、及び、両者の関連付けを記憶していることは明らかである。
　そして、上記の相違点１及び２についてで述べたように、「症状やチェック項目」を「事象」と「判断材料データ」のように段階的に絞り込むように分割し、また、「原因」を特定するようにした際に、それぞれのデータと、それらデータの関連づけを記憶するように構成することは、当業者が容易になし得たことである。
　また、引用発明における「回答ベース５ｃ」は、「事例」から「推定故障箇所・対応」を抽出するために用いられることから、「事例」、「推定故障箇所・対応」、及び、両者の関連付けを記憶していることは明らかであり、上記の相違点２についてで検討したように、「原因」から「対応」を検索するように構成した際に、「原因」と、「推定故障箇所・対応」、及び、両者の関連づけを記憶するように構成することは当業者が容易になし得たことである。
　
（相違点４について）
　引用発明では、症状検索処理部が「事例」の特定までを行い、回答の検索を「回答処理部」が行っている点で、「判断材料提示手段」が判断材料データの抽出及び出力までを行い、「対処手順提示手段」が、「判断材料データ」が「選択入力」された以降の処理を行うようになっている本願補正発明とその構成が異なる。
　しかし、機能的記載によって特定される複数の「処理部」に関し、どのように機能を切り分けて割り当てるかは、当業者が必要に応じて適宜決定すべきことであり、引用発明において、入力された判断材料に対する検索を一括して「回答処理部」で行うように構成することに格別の技術的困難性はなく、容易になし得たことである。
　
（相違点５について）
　本願補正発明は、「判断材料」を「適合度に従った順」で出力するのに対して、本願補正発明は、「サービス単位や部品」及び「症状やチェック項目」を「発生頻度」や「症状の特定しやすさ」、「優先度」といった順で出力する点で相違する。
　一方、補正後の請求項１における「適合度」についての記載は、「前記判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されており」、「前記判断材料提示手段が、抽出した判断材料データを前記適合度に従った順に出力する」というものであり、「適合度」という語の記載から、なんらかの適合の度合いに関係するデータと解されるものの、何にどのように適合するのか特段記載されておらず、「順に出力」するためのデータであることが特定されるのみである。
　そこで、発明の詳細な説明の記載を参照すると、関連する記載として、以下のものがある。
「なお、判断経路データ記憶部１６のレコードは、機種名の順にソートされており、同一機種名のレコードは、さらに症状コードの順にソートされている。さらに、同一症状コードのレコードは、判断材料コードについて、当該症状の原因を特定するために用いられた実績の多い順にソートされている。すなわち、図３（ａ）に示した例では、機種名が“ＨＡ−８１６０”であって症状コードが“Ｔ１１”であるレコードのうち、過去の修理事例において原因を特定する決め手として最も多く用いられた判断材料が“Ｊ２３”であり、その次に多いのが“Ｊ０２”である。なお、判断経路データ記憶部１６における判断材料コードの順位は、後に説明するように、修理報告書データ記憶部１４に蓄積されたデータに基づいて、更新処理部２１により、所定のタイミングで更新される。」（明細書１０頁７〜１８行）
「更新処理部２１は、判断経路データ記憶部１６の判断材料の優先順位については、修理報告書データ記憶部１４に記憶されている全ての修理実績から、同一機種における同一の症状に対して、各判断材料コードが用いられた回数をそれぞれ算出する。そして、更新処理部２１は、算出結果に基づき、過去の修理実績において各機種の各症状の判断材料が、原因を特定する決め手となった回数が多い順になるように、判断経路データ記憶部１６においてレコードを並べ替える。」（明細書１６頁４〜１０行）
　これらの記載から、判断材料のコードは、「用いられた実績の多い順」、「．．．判断材料コードが用いられた回数」の多い順に並べ替えられていると解されるから、要するに判断材料としての使用回数が「適合度」として発明の詳細な説明には記載されているといえる。
　一方、引用発明には、「発生頻度」を並べ替えの基準とすることが記載されており、また、記載箇所（く）には、アクセス回数、質問に対する回答の的中率等を算出し、検索精度を向上させることが記載されている。
　してみれば、引用発明において、「用いられた実績の多い順」、「判断材料コードが用いられた回数」順、原因を特定する決め手となった回数が多い順のような、使用回数に基づく、「適合度」の順に並べ替えることは、当業者が容易になし得たことである。
　また、引用発明においても、優先度を計算し、該優先度に応じて表示していることから、なんらかの形で関連付けて記憶していることは明らかであり、各事象データに対する判断材料データが適合度に応じて記憶されるように構成することは、当業者が必要に応じて適宜なし得たことである。
　
　また、本願補正発明の効果は引用例及び周知の事項から当業者が予想可能な範囲内のものであり、格別のものではない。
　
　してみれば、本願補正発明は、引用例及び周知の事項に基づいてこの出願の出願前において当業者が容易に発明できたものであるので特許法第２９条第２項の規定により特許を受けることができない。
　
　        　
３．むすび
　上記２．（１）のとおり、本件補正は、特許法第１７条の２第４項の規定に違反するのものであり、仮にそうでないとしても、２．（２）及び２．（３）のとおり、本願補正発明は特許出願の際独立して特許を受けることができないから、本件補正は、特許法第１７条の２第５項で準用する同法第１２６条第５項に規定する要件を満たさないものである。
　したがって、いずれにしても、本件補正は、特許法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　
第３．本願発明について
１．本願発明
　平成１７年１１月１６日付けの手続補正は上記のとおり却下されたので、本願の請求項に係る発明は、平成１７年７月１３日付け手続補正書により補正された明細書の特許請求の範囲の請求項１乃至１１に記載されたとおりのものであるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
「【請求項１】
　装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、これらのデータ相互の関連付けと共に記憶する判断経路記憶手段と、
　事象データが入力されると、当該事象に関連する判断材料データを前記判断経路記憶手段から抽出して出力する判断材料提示手段と、
　前記判断材料提示手段が出力した判断材料データのいずれかが選択入力されると、選択入力された判断材料データから特定される原因に関連する対処手順データを、前記判断経路記憶手段から抽出して出力する対処手順提示手段とを備え、
　前記判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されており、
　前記判断材料提示手段が、抽出した判断材料データを前記適合度に従った順に出力することを特徴とするトラブル対処支援システム。」
　
　
２．引用例及び周知例
　これに対し、原査定の理由で引用した引用例（特開２００１−２８２９４４号公報）、及び、この出願の出願前に頒布された刊行物である周知例１〜３（特開平１０−１２４４７７号公報、特開平９−２６８０５号公報、特開昭５９−５３０３号公報）に記載された事項は、「第２［理由］２．（３）（ｂ）引用例・周知例」に記載したとおりである。
　
　
３．対比・判断
　本願発明は、上記「第２［理由］で検討した本願補正発明において、「前記事象データと判断材料データと原因との関連付けと、前記原因と対処手順データとの関連付け」とあったところを、「これらのデータ相互の関連付け」に変更したものに相当する。
　
　そこで、本願発明と引用発明とを対比すると、本願発明と引用発明とは、以下の点で一致し、また、以下の点でそれぞれ相違する。
　
（一致点）「システムで用いられるデータを記憶する記憶手段を備え、
　装置に生じるトラブルの判断材料データを、表示順序を決めるための指標に基づく順に出力し、
　判断材料データが選択入力されると、入力された判断材料データから特定されるデータに関連する対処手順データを、記憶手段から抽出して出力する
　システム」である点。
　
（相違点１）本願発明は、「事象データが入力される」と「判断材料データ」を出力するのに対して、引用発明ではそのようになっていない点。
　
（相違点２）対処手順を抽出するために、入力された判断材料から特定されるデータが、本願発明では、「原因」となっているのに対して、引用発明では、そのようになっていない点。
　
（相違点３’）システムで用いられるデータを記憶する記憶手段について、本願発明は、「装置に生じ得るトラブルの事象データの一覧と、前記事象の原因を特定するための判断材料となる現象を表す判断材料データの一覧と、原因に応じた対処手順データの一覧とを、これらのデータ相互の関連付けと共に記憶する」ものであるのに対して、引用発明ではそのようになっていない点。
　
（相違点４）本願発明では、「判断材料提示手段」が判断材料データの抽出及び出力までを行い、「対処手順提示手段」が、「判断材料データ」が「選択入力」された以降の処理を行うようになっているのに対して、引用発明ではそのようになっていない点。
　
（相違点５）判断材料データの表示順序を決めるための指標について、本願発明では、「適合度順」であるのに対して、引用発明では、そのようになっていない点。
　また、本願発明では、「判断経路記憶手段において、各事象データに対する判断材料データが適合度に応じて記憶されて」いるようになっているのに対して、引用発明では、そのようになっていない点。
　
　上記相違点について判断するに、上記相違点１，２，４，５に係る構成は、上記「第２［理由］２．（３）（ｃ）（相違点１）（相違点２）（相違点４）（相違点５）」と同様であって、その判断は、「第２［理由］２．（３）（ｄ）（相違点１について）（相違点２について）（相違点４について）（相違点５について）」で述べたとおり当業者が容易になし得たことである。そこで、相違点３’について判断する。
　
（相違点３’について）
　引用発明は、「症状とチェック項目」から「事例」を特定し、該「事例」から「推定故障箇所・対応」を検索するものであるから、「事例ベース４ｃ」及び「回答ベース５ｃ」とは、「事例」によって関連付けられているといえる。したがって、「事例ベース４ｃ」及び「回答ベース５ｃ」を含む、「過去の事例や同事例に対応する回答文や、修理に要する部品情報などを記憶するデータベース」において、「症状とチェック項目」と「推定故障箇所・対応」とが、それらのデータの関連づけと共に記憶されていることは明らかである。
　そして、上記（第２［理由］２．（３）（ｄ））の（相違点３について）で検討したことと同様に、「症状やチェック項目」を「事象」と「判断材料データ」のように段階的に絞り込むように分割した際に、それぞれのデータと、データ相互の関連づけを記憶するように構成することは、当業者が容易になし得たことである。
　
　また、本願発明の効果は引用例及び周知の事項から当業者が予想可能な範囲内のものであり、格別のものではない。
　
　以上のとおり、本願発明は、引用例に記載された発明及び周知の事項に基づいて当業者が容易に発明をすることができたものである。
　
　
４．むすび
　以上のとおり、本願の請求項１に係る発明は特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。