【事件の表示】
　特願２００３−１６６２６９「修理審査システム」拒絶査定不服審判事件〔平成１７年　１月　６日出願公開、特開２００５−　　４４２１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　
　本願は、平成１５年６月１１日の出願であって、平成１８年１月３１日付けで拒絶査定がなされ（発送日同年２月６日）、これに対して、同年３月８日に拒絶査定不服審判の請求がなされるとともに、同年４月３日付けで手続補正がなされたものである。
　
　
　
　
第２　平成１８年４月３日付けの手続補正についての補正却下の決定
　
〔補正却下の決定の結論〕
　
　平成１８年４月３日付けの手続補正を却下する。
　
　
〔理由〕
　
１．補正内容
　
　平成１８年４月３日付けの手続補正（以下、「本件補正」という。）は、特許請求の範囲についてするもので、
　
「　【請求項１】　延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、
　サーバと、
　前記サーバにネットワークを介して接続された端末装置と
を備え、
　前記サーバは、
　顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、
　前記受信手段により受信した前記修理請求データを記憶する第１の記憶手段と、
　前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、
　前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、
　予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、
妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段と
を備えた修理審査システム。」
　
　から
　
「　【請求項１】　延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、
　オペレーティング・システムを備えたサーバと、
　前記サーバにネットワークを介して接続された端末装置と
を備え、
　前記サーバは、
　　顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、
　　前記受信手段により受信した前記修理請求データを記憶すると共に、複数のアプリケーション・プログラムを記憶する第１の記憶手段と、
　　前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、
　　前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、
　　予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段とを備え、
　前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現されることを特徴とする修理審査システム。」
　
　へ補正するものである。　
　
　
　つまり、本件補正は、「
オペレーティング・システムを備えた
と共に、複数のアプリケーション・プログラムを記憶する
前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される
　「サーバ」、「第１の記憶手段」、及び「審査手段」を限定するものであるから、特許法第１７条の２第４項第２号に掲げる事項を目的とするものである。
　そこで、本件補正後における特許請求の範囲に記載されている事項により構成される発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項に規定する要件を満たすか）否かを、本件補正後の請求項１に係る発明（以下、「本願補正発明」という。）について検討する。
　
　
　
２．本願補正発明の認定
　
　本願補正発明は、本件補正によって補正された明細書及び図面の記載からみて、特許請求の範囲第１項に記載されたとおりのものと認められるところ、その請求項１に係る発明は、次のとおりのものである。
　
「　【請求項１】　延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、
　オペレーティング・システムを備えたサーバと、
　前記サーバにネットワークを介して接続された端末装置と
を備え、
　前記サーバは、
　　顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、
　　前記受信手段により受信した前記修理請求データを記憶すると共に、複数のアプリケーション・プログラムを記憶する第１の記憶手段と、
　　前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、
　　前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、
　　予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段とを備え、
　前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現されることを特徴とする修理審査システム。」
　
　
　
３．引用例の認定
　
　原査定の拒絶の理由に引用された、特開２００３−１５０７３１号公報（以下、「引用例」という）には、図面とともに以下の技術事項が記載されている。
　
（ア）
「　　【０００１】
　　【発明の属する技術分野】
　本発明は、保証契約に基づいて修理作業を行う修理業者のための保証事務処理システム及び方法に関し、特に保証に伴う事務処理を簡便かつ迅速化することにより、修理業者のみならず保証契約者、保証販売者の負担を軽減するとともに、保証契約者へのサービスの拡充を実現することができる保証事務処理システム及び方法に関する。」
　
（イ）
「　　【０００２】
　　【従来の技術】
　物品を購入した保証契約者が、保証会社に掛け金を支払うことにより、物品を購入した際に付される無料保証期間終了後の一定期間も同様の保証を受けることができる延長保証制度が我が国でも普及しつつある。保証対象となる物品は主に自動車や家電製品であり、特に中古自動車について利用価値が高い。例えば中古自動車を購入、あわせて保証契約も購入した保証契約者は、保証契約で定められた保証期間中に、自動車に故障が生じ、中古自動車を販売した中古自動車販売業者や最寄りの自動車整備店などの修理業者に自動車の修理を依頼した場合、契約で定めた種類の修理及び保証限度額の範囲内ならば、保証契約者が費用負担することなく修理を受けることができる。」
　
（ウ）
「　　【０００３】
　このような保証契約においては、修理費用は保証契約者から仮に修理業者に支払われ、その後保証契約者が保証会社に支払った額の金銭を請求する形が基本ではあるが、保証会社と提携している修理業者が保証契約者に代わって保証会社から直接支払を受けるようにした方が保証契約者にとっては便利である。特に、自動車で遠出している途中で故障した場合など、手元に修理費用がないときに保証契約者に負担を生じない支払形式を選択できるようにすれば、商品的価値も向上する。しかし保証契約があるとしても、全ての種類の修理について限度額なしに無償の修理が保証されているわけではなく、契約により対象となる修理と保証限度額が定められている。このため、修理業者が保証契約者の言うがままに修理すると保証会社からの支払が受けられない可能性もあり、またそれを避けるために保証契約に基づく修理を断られる場合もある。逆に修理業者が保証契約を悪用して通常よりも多額の修理費用を請求し、トラブルに発展する可能性もある。これらの不具合を避けるために、保証契約者及び修理業者は契約内容の説明や確認等についての面倒な事務処理を強いられることになり、延長保証制度による保証の簡便性を充分に生かすことができなかった。
　　【発明が解決しようとする課題】
　よって本発明の目的は、保証事務処理を容易にすることにより修理業者の事務に関する負担を軽減するとともに、保証契約者の契約内容の説明等の手間を省き、保証契約者へのサービスの拡充を実現することができる保証事務処理システム及び方法を提供することにある。」
　
（エ）
「　　【０００４】
　　【課題を解決するための手段】
　上記目的を達成するために本発明は、保証会社と保証契約者との間で、少なくとも保証される修理の内容と保証限度額とを定めた保証契約に基づいて、前記保証会社と提携して、前記保証契約者の要求に応えて修理作業を行い、前記保証契約者に代わって前記保証会社から修理費用の支払いを受ける修理業者のための保証事務処理システムにおいて、前記保証契約者の要求を受けて修理作業を開始する前に送られてきた前記修理業者からの保証契約内容情報の少なくとも一部と修理内容情報とを含む修理着工承認要求に基づいて、前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記修理業者に知らせる修理着工承認手段と、前記修理着工承認要求と同時に、前記修理着工承認を確認後に、またはその間に送られてきた前記修理業者からの見積額を含む見積申請に基づいて、前記見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記修理業者に知らせる見積着工承認手段とを含んで保証事務処理システムを構成した。この保証事務処理システムは、さらに前記修理着工承認及び前記見積着工承認の両方を受けた各修理についての修理作業を完了した後に送られてきた前記修理業者からの修理完了報告に基づいて、前記保証会社が前記修理業者に修理費用を支払うための処理を行う修理費用支払手段とを含むことができる。」
　
（オ）
「　　【０００５】
　このような保証事務処理システムにおいては、まず保証契約者の要求を受けて修理作業を開始する前に、修理業者からの保証契約内容情報の少なくとも一部と修理内容情報とを含む修理着工承認要求が修理着工承認手段に送られてくる。修理着工承認手段はこの修理着工承認要求に基づいて、修理内容情報に一つ以上含まれる各修理が保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断する。なお、保証契約は典型的には自動車保証契約である。」
　
（カ）
「　　【０００６】
　この判断は、例えば修理着工承認手段に含まれている保証修理内容情報データベースを利用して行われる。保証修理内容情報データベースには、各保証契約ごとに、保証契約内容情報の少なくとも一部と、保証されている各修理とを相互に関連付けて登録されている。従って、保証契約内容情報の少なくとも一部により複数の中から特定の保証契約を検索し、検索された保証契約の保証する修理と、修理着工承認要求に含まれる修理とが一致するかどうかにより、上記判断を行うことができる。修理着工承認手段は判断結果に基づいて各修理が保証されているか否かをそれぞれ表す修理着工承認を前記修理業者に知らせる。もしも保証範囲外の種類の修理だった場合には、無償の修理が適用されないので、他の支払手段が用いられたり修理が中止されたりすることになる。」
　
（キ）
「　　【０００７】
　また修理業者は、修理についての見積額を含む見積申請を見積着工承認手段に送る。この見積申請は修理着工承認要求と同時に、修理着工承認を確認後に、またはその間に送られる。すなわち修理業者は、修理着工承認要求と一緒に見積申請を送ってもよく、修理着工承認要求を送った後の任意のタイミングで送ってもよく、また修理着工承認を知らされた後に送ってもよい。修理着工承認を知らされた後であれば、承認された修理についてのみ、見積をすれば足りる。もしも承認されなかった場合には、より低い額に修正した見積額で見積申請を再度送ることになる。」
　
（ク）
「　　【０００８】
　見積着工承認手段は、見積申請に基づいて、見積額が前記保証限度額の範囲内か否かを判断する。この判断は、修理着工承認手段に含まれた保証額情報データベースを利用して行うことができる。保証額情報データベースは、各保証契約ごとに、前記保証契約内容情報の少なくとも一部と保証限度額とを相互に関連付けて登録しており、見積着工承認手段は保証額情報データベースを検索し、保証限度額と見積額とを照合して、見積額が保証限度額を超えていないかどうかを判断する。見積着工承認手段は判断結果に基づいて保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記修理業者に知らせる。もしも保証限度額を超えた場合には、上述のように見積額を訂正したり、超過分を顧客に負担させたりすることになる。」
　
（ケ）
「　　【０００９】
　保証契約において、保証限度額の総額のみならず、各修理の種類ごとに個別の保証限度額が定められている場合、各保証契約ごとに、保証されている各修理と、各修理ごとの個別保証限度額とを相互に関連付けて登録した保証額情報データベースを利用することができる。見積着工承認手段は修理業者からの各修理ごとの個別見積額を含む見積申請に基づいて、保証額情報データベースを検索し、個別見積額がそれぞれ各個別保証限度額の範囲内か否かを判断し、判断結果に基づいて各見積額が各個別保証額の範囲内か否かをそれぞれ表す見積着工承認を修理業者に知らせる。これにより、例えば簡単な修理で多額の修理費用を請求するような不正を防止することができる。」
　
（コ）
「　　【００１０】
　このように各修理の種類ごとに個別の保証限度額が存在する場合、見積着工承認手段は、保証額情報データベースに加えて、各修理と、各修理ごとの標準的な部品代と標準的な工賃とを相互に関連付けて登録した部品代・工賃データベースを利用することができる。部品代・工賃データベースを検索することにより、各個別見積額がそれぞれ標準的な部品代と標準的な工賃とに基づいて定められる各標準額以下であるか否かを判断し、見積着工承認には各見積額がそれぞれ各標準額以下であるか否かを含むようにする。これによって、より適正な保証の実施が可能になる。標準的な部品代と工賃とは、例えば自動車修理の場合、部品交換を伴う場合など自動車の型式ごとに内容が異なる場合には同じような作業でも型式ごとに異なった額が定められ、パンク修理やロック解除などについてはほぼ一律に定められている。」
　
（サ）
「　　【００１１】
　また、修理業者から送られた保証契約内容情報の少なくとも一部に基づいて、少なくとも保証契約者と保証対象とを特定するための他の保証契約内容情報を前記修理業者に知らせる保証対象確認手段をさらに含むようにしてもよく、これにより修理着工承認要求の前に、好ましくは修理箇所や故障している部品を探す作業を開始する前に、保証契約者と保証対象を特定し、修理に保証が効くのかどうかを知ることができる。よって修理業者及び顧客は、修理が保証されているかどうかを予め知ってから修理箇所の点検等を開始することができ、これによって両者間のトラブルを避け、無駄な手間を省くことができる。保証対象確認手段は、各保証契約ごとに、少なくとも保証書番号、保証契約者名、保証対象及び保証期間を含む保証契約内容情報を相互に関連付けて登録した保証契約内容情報データベースを利用することができる。」
　
（シ）
「　　【００１２】
　修理着工承認要求、見積申請及び修理完了報告、さらに修理着工承認及び見積着工承認も、インターネットのようなネットワーク、電話、携帯電話、ＦＡＸ等を通じて送受信されうるが、好適にはインターネットを通じてパソコン、ＰＤＡ、携帯電話等の修理業者クライアントから送信される。保証対象確認における保証契約内容情報も同様である。インターネットを通じて情報を送受信する場合、保証事務処理システムはＷｅｂサーバであり、各データベースはＷｅｂサーバにネットワークを通じて、または通じないで接続されている。保証事務処理システムを構成する各手段は１つのＷｅｂサーバにモジュールとして構築されていても、独立したＷｅｂサーバであってもよい。ネットワークを通じてＷｅｂサーバに接続されたデータベースは、データベースサーバとして構成される。また、各データベースはそれぞれ物理的に独立した機器としても構成でき、物理的に同一の機器としても構成できる。有線の電話、携帯電話及びＦＡＸを通じて情報を送受信する場合、修理業者からの情報はコールセンターやサービスセンター等と呼ばれるサービスを行う機関に送られ、オペレータが上述の検索を行い、結果を修理業者に返信する。」
　
（ス）
「　　【００１９】
　　【発明の実施の形態】
　以下、本発明に係る保証契約事務処理システムの一つの実施の形態について説明する。以下の説明は、本発明をより深く理解させることを目的とするものであり、本発明の技術的範囲を限定的に解釈するためのものではない。
　　　【００２０】
　図１は、本発明に係る保証契約事務処理システムの一つの実施の形態の主要な構成を示すブロック図である。図１に示した保証契約事務処理システムは、メーカーによる無料保証期間経過後の延長保証とも称される自動車保証契約のために利用され、保証会社と保証契約者（通常は自動車の所有者または使用者）との間で、少なくとも保証される修理の内容と保証限度額とを定めた保証契約に基づいて、保証会社と提携して、保証契約者の要求に応えて修理作業を行い、保証契約者に代わって保証会社から修理費用の支払いを受ける修理業者のための保証事務処理システムである。修理業者にはロードアシスタンス会社や修理工場のほか、修理能力を有する中古車販売業者やディーラーなどが含まれる。
　　　【００２１】
　図１において、保証事務処理システム１０は、保証対象確認部１１と、修理着工承認部１２と、保証修理内容データベース１４と、見積着工承認部１６と、保証額データベース１７と、部品代・工賃データベース１８と、支払請求部１９とを含む。保証事務処理システム１０は、インターネット２０を通じて、修理業者の所有するクライアント３０と接続され、クライアント３０から入力されたデータに応じて動作し、生成したデータをクライアント３０に送信する。また保証事務処理システム１０は、インターネット２０を通じて、保証会社サーバ４０との間でデータの授受を行う。」
　
（セ）
「　　【００２２】
　保証対象確認部１１は、保証契約者の要求を受けて修理作業を開始する前にクライアント３０から送信された保証契約内容情報の一部、例えば保証書番号に基づいて、保証契約者と保証対象となる自動車を特定するための他の保証契約内容情報をクライアント３０に対して回答する。保証対象確認部１１は、この実施の形態においては、保証会社サーバ４０にアクセスし、保証書番号などを検索条件として、各保証契約ごとに、少なくとも保証書番号、保証契約者名、保証対象及び保証期間を含む保証契約内容情報を相互に関連付けて登録した保証契約内容データベース４０を検索するが、専用のデータベースを保証事務処理システム１０内に設けておいてもよい。保証対象確認部１１は、保証契約が存在するか、保証期間内か等により保証契約が有効であるかを判断し、クライアント３０にその結果を送信する。修理業者は、保証事務処理システム１０から送信された保証契約内容情報を参照することにより修理を依頼された保証契約者及び自動車が表示されたものと一致するかどうか確認することができる。これにより修理着工承認要求などの作業開始の前に修理に保証が効くのかどうかを知ることができ、これによって修理依頼者と修理業者との間のトラブルを避け、無駄な手間を省くことができる。」
　
（ソ）
「　　【００２３】
　修理着工承認部１２は、保証契約者の要求を受けて修理作業を開始する前にクライアント３０から送信された、例えば保証書番号のような保証契約内容情報の一部と修理内容情報とを含む修理着工承認要求に基づいて、修理内容情報に含まれる修理が保証契約内容情報により特定される保証契約により保証されているか否かを判断し、判断結果に基づいて修理が保証されているか否かをそれぞれ表す修理着工承認をクライアント３０に送信する。ここでの修理内容情報は、例えば故障発生日、不具合の部位・内容、その詳細（発生部位・不具合発生の条件・不具合現象・発生時期）その他である。この判断は保証修理内容データベース１４を利用して行われる。保証修理内容データベース１４には、各保証契約ごとに、保証契約内容情報の一部（保証書番号、車体番号、登録番号等）と、保証されている修理とを相互に関連付けて登録されている。修理着工承認部１２は、保証契約内容情報の少なくとも一部により複数の中から特定の保証契約を検索し、検索された保証契約の保証する修理と、修理着工承認要求に含まれる修理とが一致するかどうかにより、上記判断を行う。修理着工承認部１２は判断結果に基づいて各修理が保証されているか否かをそれぞれ表す修理着工承認をクライアント３０に送信する。もしも保証範囲外の種類の修理だった場合には、無償の修理が適用されないので、この保証事務処理システム１０による処理は中止され、有償の修理としたり修理が中止されたりすることになる。修理が複数必要な場合には、それぞれの修理について承認要求や判断や承認が行われる。保証修理内容データベース１４に蓄積される各データは、例えば保証契約内容データベース４１から定期的に転送されて更新されるが、保証契約内容データベース４１を保証修理内容データベース１４の代わりに利用することも可能である。また、修理が緊急を要する場合にはオペレータにより必要の都度更新することも可能である。」
　
（タ）
「　　【００２４】
　見積着工承認部１６は、クライアント３０から送信された見積額を含む見積が入力され、入力された見積に基づいて、見積額が保証限度額の範囲内か否かを判断し、判断結果に基づいて見積額が保証限度額の範囲内か否かを表す見積着工承認をクライアント３０に送信する。この判断は、修理着工承認手段に含まれた保証額データベース１７を利用して行う。保証額データベース１７は、各保証契約ごとに、保証契約内容情報の一部と保証限度額とを相互に関連付けて登録しており、見積着工承認部１６は保証限度額と見積額とを照合して、見積額が保証限度額を超えていないかどうかを判断する。見積着工承認手段は判断結果に基づいて保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記修理業者に知らせる。もしも保証限度額を超えた場合には、見積額を訂正したり、超過分を顧客に負担させたりすることになる。
　　　【００２５】
　この保証契約においては、保証限度額の総額のみならず、各修理の種類ごとに個別の保証限度額が定められているので、保証額データベース１７には各保証契約ごとに、保証されている各修理と、各修理ごとの個別保証限度額とを相互に関連付けて登録している。見積着工承認部１６はクライアント３０からの各修理ごとの個別見積額を含む見積に基づいて、個別見積額がそれぞれ各個別保証限度額の範囲内か否かを判断し、判断結果に基づいて各見積額が各個別保証額の範囲内か否かをそれぞれ表す見積着工承認をクライアント３０に送信する。これにより、例えば簡単な修理で多額の修理費用を請求するような不正を防止することができる。
　　　【００２６】
　このように各修理の種類ごとに個別の保証限度額が存在する場合、見積着工承認部１６は、保証額データベース１７に加えて、各修理と、各修理ごとの標準的な部品代と標準的な工賃とを相互に関連付けて登録した部品代・工賃データベース１８をさらに含んでいる。見積着工承認部１６は、部品代・工賃データベース１８を利用して、各個別見積額がそれぞれ標準的な部品代と標準的な工賃とに基づいて定められる各標準額以下であるか否かを判断する。見積着工承認には各見積額がそれぞれ各標準額以下であるか否かが含まれる。これによって、より適正な保証の実施が可能になる。標準的な部品代と工賃とは、例えば自動車修理の場合、部品交換を伴う場合など自動車の型式ごとに内容が異なる場合には同じような作業でも型式ごとに異なった額が定められ、パンク修理やロック解除などについてはほぼ一律に定められている。なお、部品代・工賃データベース１８は保証事務処理システム１０の稼働に伴い、クライアント３０から、あるいは保証事務処理システム１０のオペレータにより入力されるデータ内容を随時蓄積し、参照可能とすることで、標準的な部品代と標準的な工賃のデータを拡充することが可能である。これにより、実情に見合った標準額を得ることができる。例えば、ある種の修理についてクライアント３０から送信される見積額の多くが標準額を上回っている場合には、標準額を高い方向に修正し、逆ならば標準額を下げる方向に修正を行う。」
　
（チ）
「　　【００３０】
　ある修理業者が保証契約者から修理を依頼された場合、修理業者はクライアント３０を操作し、ブラウザを起動して、クライアント３０と保証事務処理システム１０とをインターネット２０を介して接続する。するとブラウザには図３の延長保証メニュー画面が表示されるので、「保証契約一覧」の項目をクリックすると、クライアント３０は保証対象確認部１１に接続され、図４のような保証契約検索画面が表示される。図２の手順はここから説明される。なお、図３のメニュー画面にアクセスするには予め設定されたパスワードやユーザＩＤの入力が必要であり、任意のクライアントからアクセスできないようになっているが、その過程の説明は省略する。」
　
（ツ）
「　　【００３１】
　修理業者は図４の画面上でクライアント３０を操作し、契約内容情報のうち保証契約検索情報となる項目（販売店ＩＤ、保証書番号、名前、登録番号等）のいずれか（または複数項目）を入力する（ステップＳ２０１）。ここでは検索条件としてサント自動車の販売店ＩＤを入力したものとする。保証対象確認部１１は保証契約内容データベース４１を検索し（ステップＳ２０２）、検索条件に合致した保証契約を抽出する。もしも検索条件に合致する保証契約が保証契約内容データベース４１に蓄積されていない場合や保証期間を徒過していたような場合、保証対象確認部１１は保証契約が無効であると判断し（ステップＳ２０３）、その旨のメッセージを表示して（ステップＳ２２１）手続を中止する（ステップＳ２２２）。保証契約が有効であると判断された場合（ステップＳ２０３）、保証対象確認部１１は図５のように抽出された保証内容の一部を保証登録一覧として表示する（ステップＳ２０４）。修理業者は図５の画面を参照して、修理依頼者の名前や車種等が保証契約内容と合致するかどうか判断して、手続を継続するかどうか決定する。必要ならば、図５の詳細表示のボタンを押すことにより、さらに詳細な契約内容情報を表示することができる。」
　
（テ）
「　　【００３２】
　保証契約が有効で、かつ修理依頼が適正であれば、修理業者はクライアント３０を修理着工承認部１２に接続して修理着工承認要求の登録を行う（ステップＳ２０５）。すなわち修理業者は、図３のメニュー画面から「修理着工要求」の項目をクリックし、図６のような入力事項フレームを含む修理着工承認要求登録画面をクライアント３０のブラウザに表示させ、連絡日、優先順位、故障発生日、不具合内容（部位・原因）、内容詳細（発生部位・不具合発生の条件・不具合現象・発生時期）等の修理内容情報を各入力欄に入力し、送信ボタン（図示していない）を押して修理着工承認部１２に送信する。もしも故障が複数箇所あれば、故障ごとに再度修理着工承認要求登録の手続を行ってもよいし、複数の項目を入力可能な画面を用意してもよい。
　　　【００３３】
　修理内容情報が入力されると、修理着工承認部１２は保証責任有無検索を行い（ステップＳ２０６）、保証責任が有るか無いかを判断する（ステップＳ２０７）。すなわち修理着工承認部１２は保証修理内容データベース１４から該当する保証契約の内容を読み出し、その保証契約で保証されている修理か否かを判断する。保証責任が無ければメッセージを表示して（ステップＳ２２１）、手続を中止する（ステップＳ２２２）。保証責任が有れば、修理着工承認部１２は修理着工承認をクライアント３０に表示させる（ステップＳ２０８）。すなわち図３のメニュー画面から「修理状況一覧」の項目を選択し、図７のような修理状況一覧を表示させる。修理状況一覧には、各クライアント３０ごとに要求された各修理着工承認要求について、着工承認がされたか否か等がテーブル形式で表示される。より詳細な情報が必要な場合には、詳細表示のボタンを押す。」
　
（ト）
「　　【００３４】
　次に修理業者は、修理着工承認がされた修理についての見積を行い、クライアント３０に入力する（ステップＳ２０９）。すなわち図７の修理着工一覧画面から修理着工承認がされた修理の一つを選択して見積入力ボタンを押すと、クライアント３０は見積着工承認部１６に接続されて、見積登録画面が表示される。見積登録画面には、図８のような見積の入力欄が表示される。これらの入力欄に入力を行い、送信ボタン（図示していない）を押すことにより、見積着工承認部１６への見積送信がなされる。
　　　【００３５】
　見積着工承認部１６は、入力された見積について、見積内容の検索を行う（ステップＳ２１０）。見積内容の検索は、一つは保証額データベース１７を利用した見積に含まれる見積額が保証限度額内か（ステップＳ２１１）、もう一つは部品代・工賃データベース１８を利用した見積に含まれる部品代・工賃が標準額以下かどうか（ステップＳ２１２）の２つである。もしもいずれか一方でも不適であれば、メッセージが送信されて手続が中止される（ステップＳ２２１、２２２）。この場合には、修理業者は図７の画面から見積変更ボタンを押して見積内容を変更してもよい。
　　　【００３６】
　見積が適当であれば、見積着工承認部１６は見積承認されたことをクライアント３０に知らせる（ステップＳ２１３）。例えば図７の修理状況一覧には見積承認がされた旨の表示がなされる。修理業者はこれを見て修理を開始する。修理が完了したら、図７の修理状況一覧から修理が完了したものを選択し、修理完了入力を選択し、図９の修理完了入力を呼び出して、修理完了ボタンを押すことにより、修理完了報告を行う（ステップＳ２１４）。支払請求部１９は、修理完了報告を受領した修理について、保証会社サーバ４０に対して、インターネット２０を通じて請求データ作成・送信を行い（ステップＳ２１５）、修理費用支払の手続を行う。」
　
　
　以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。
　
（ａ）
　引用例の上記（シ）の「インターネットを通じて情報を送受信する場合、保証事務処理システムはＷｅｂサーバであり、各データベースはＷｅｂサーバにネットワークを通じて、または通じないで接続されている。保証事務処理システムを構成する各手段は１つのＷｅｂサーバにモジュールとして構築されていても、独立したＷｅｂサーバであってもよい。ネットワークを通じてＷｅｂサーバに接続されたデータベースは、データベースサーバとして構成される。」という記載、
　
　引用例の上記（ス）の「図１において、保証事務処理システム１０は、保証対象確認部１１と、修理着工承認部１２と、保証修理内容データベース１４と、見積着工承認部１６と、保証額データベース１７と、部品代・工賃データベース１８と、支払請求部１９とを含む。保証事務処理システム１０は、インターネット２０を通じて、修理業者の所有するクライアント３０と接続され、クライアント３０から入力されたデータに応じて動作し、生成したデータをクライアント３０に送信する。また保証事務処理システム１０は、インターネット２０を通じて、保証会社サーバ４０との間でデータの授受を行う。」という記載、
　
　引用例には明記されていないものの、（サーバなどの）情報処理装置が、オペレーティング・システムを備えることによって各種処理を行うことは、情報処理分野における技術常識であることから、
　
　引用例には、「保証事務処理システムであって、オペレーティング・システムを備えたＷｅｂサーバと、前記保証事務処理システムにインターネットを通じて接続されたクライアントとを備える」ことが開示されていると認められる。
　
　
（ｂ）
　引用例の上記（チ）の「ある修理業者が保証契約者から修理を依頼された場合、修理業者はクライアント３０を操作し、ブラウザを起動して、クライアント３０と保証事務処理システム１０とをインターネット２０を介して接続する。」という記載、
　
　引用例の上記（ツ）の「修理業者は図４の画面上でクライアント３０を操作し、契約内容情報のうち保証契約検索情報となる項目（販売店ＩＤ、保証書番号、名前、登録番号等）のいずれか（または複数項目）を入力する（ステップＳ２０１）。ここでは検索条件としてサント自動車の販売店ＩＤを入力したものとする。保証対象確認部１１は保証契約内容データベース４１を検索し（ステップＳ２０２）、検索条件に合致した保証契約を抽出する。」という記載、
（なお、「保証事務処理システム」内の「保証対象確認部」が、「クライアント」からの「保証契約検索情報」を受け取るのであるから、「保証事務処理システム」内に受信手段に相当する構成を備えることは明らかである。）
　
　引用例の上記（テ）の「保証契約が有効で、かつ修理依頼が適正であれば、修理業者はクライアント３０を修理着工承認部１２に接続して修理着工承認要求の登録を行う（ステップＳ２０５）。すなわち修理業者は、図３のメニュー画面から「修理着工要求」の項目をクリックし、図６のような入力事項フレームを含む修理着工承認要求登録画面をクライアント３０のブラウザに表示させ、連絡日、優先順位、故障発生日、不具合内容（部位・原因）、内容詳細（発生部位・不具合発生の条件・不具合現象・発生時期）等の修理内容情報を各入力欄に入力し、送信ボタン（図示していない）を押して修理着工承認部１２に送信する。」という記載、
（なお、「保証事務処理システム」内の「修理着工承認部」が、「クライアント」からの「修理内容情報」を受け取るのであるから、「保証事務処理システム」内に受信手段に相当する構成を備えることは明らかである。）
　
　引用例の上記（ト）の「次に修理業者は、修理着工承認がされた修理についての見積を行い、クライアント３０に入力する（ステップＳ２０９）。すなわち図７の修理着工一覧画面から修理着工承認がされた修理の一つを選択して見積入力ボタンを押すと、クライアント３０は見積着工承認部１６に接続されて、見積登録画面が表示される。見積登録画面には、図８のような見積の入力欄が表示される。これらの入力欄に入力を行い、送信ボタン（図示していない）を押すことにより、見積着工承認部１６への見積送信がなされる。・・・（中略）・・・見積着工承認部１６は、入力された見積について、見積内容の検索を行う（ステップＳ２１０）。」という記載、
（なお、「保証事務処理システム」内の「見積着工承認部」が、「クライアント」からの「見積」を受け取るのであるから、「保証事務処理システム」内に受信手段に相当する構成を備えることは明らかである。）
　
　「保証契約検索情報」、「修理内容情報」、及び「見積」という一連のデータは、修理請求に関するデータであることは明らかであることから、
　
　引用例には、「前記保証事務処理システムは、保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段を備える」ことが開示されていると認められる。
　
　
（ｃ）
　上記（ｂ）の「前記保証事務処理システムは、保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段を備える」という開示、
　
　引用例の上記（ス）の「図１において、保証事務処理システム１０は、保証対象確認部１１と、修理着工承認部１２と、保証修理内容データベース１４と、見積着工承認部１６と、保証額データベース１７と、部品代・工賃データベース１８と、支払請求部１９とを含む。」という記載、
（当該記載から、「保証事務処理システム」が「保証対象確認部」を備えている、ということが明らかである。）、
　
　引用例の上記（ツ）の「修理業者は図４の画面上でクライアント３０を操作し、契約内容情報のうち保証契約検索情報となる項目（販売店ＩＤ、保証書番号、名前、登録番号等）のいずれか（または複数項目）を入力する（ステップＳ２０１）。ここでは検索条件としてサント自動車の販売店ＩＤを入力したものとする。保証対象確認部１１は保証契約内容データベース４１を検索し（ステップＳ２０２）、検索条件に合致した保証契約を抽出する。もしも検索条件に合致する保証契約が保証契約内容データベース４１に蓄積されていない場合や保証期間を徒過していたような場合、保証対象確認部１１は保証契約が無効であると判断し（ステップＳ２０３）、その旨のメッセージを表示して（ステップＳ２２１）手続を中止する（ステップＳ２２２）。保証契約が有効であると判断された場合（ステップＳ２０３）、保証対象確認部１１は図５のように抽出された保証内容の一部を保証登録一覧として表示する（ステップＳ２０４）。修理業者は図５の画面を参照して、修理依頼者の名前や車種等が保証契約内容と合致するかどうか判断して、手続を継続するかどうか決定する。」という記載から、
（なお、「保証契約検索情報」の入力に応答して「保証対象確認部」における処理が実行されるのであるから、当該入力は、「保証対象確認部」に対する実行要求でもあることは明らかである。）
　
　引用例には、「前記保証事務処理システムは、クライアントからの実行要求に応答して、修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する保証対象確認部を備える」ことが開示されていると認められる。
　
　
（ｄ）
　上記（ｂ）の「前記保証事務処理システムは、保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段を備える」という開示、
　
　上記（ｃ）の「前記保証事務処理システムは、クライアントからの実行要求に応答して、修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する保証対象確認部を備える」という開示、
　
　引用例の上記（ス）の「また保証事務処理システム１０は、インターネット２０を通じて、保証会社サーバ４０との間でデータの授受を行う。」という記載、
（なお、「保証事務処理システム」はインターネットを通じて「保証会社サーバ」とデータの授受を行うのであるから、「保証事務処理システム」が当該データを受信するための受信手段に相当する構成を備えることは明らかである。）
　
　引用例の上記（セ）の「保証対象確認部１１は、この実施の形態においては、保証会社サーバ４０にアクセスし、保証書番号などを検索条件として、各保証契約ごとに、少なくとも保証書番号、保証契約者名、保証対象及び保証期間を含む保証契約内容情報を相互に関連付けて登録した保証契約内容データベース４０を検索するが、専用のデータベースを保証事務処理システム１０内に設けておいてもよい。」という記載、
（なお、明記されていないものの、データベースに格納されるデータがテーブルによって管理されることは、情報処理分野における技術常識である。また、当該記載中の「保証契約内容データベース４０」は「保証契約内容データベース４１」の誤記であると認められる。）
　
　引用例には明記されていないものの、（サーバなどの）情報処理装置が、（受信した情報などの）各種情報を実記憶域（メモリ）に格納することによって各種処理を行うことは、情報処理分野における技術常識であることから、
　
　引用例には、「前記保証事務処理システムは、前記保証対象確認部により判断する修理請求データに関連付けられる、保証対象及び保証期間を含む保証契約内容データベース内テーブルの保証契約内容情報を記憶するメモリを備える」ことが開示されていると認められる。
　
　
（ｅ）
　上記（ｂ）の「前記保証事務処理システムは、保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段を備える」という開示、
　
　上記（ｃ）の「前記保証事務処理システムは、クライアントからの実行要求に応答して、修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する保証対象確認部を備える」という開示、
　
　上記（ｄ）の「前記保証事務処理システムは、前記保証対象確認部により判断する修理請求データに関連付けられる、保証対象及び保証期間を含む保証契約内容データベース内テーブルの保証契約内容情報を記憶するメモリを備える」という開示、
　
　引用例の上記（エ）の「・・・、前記保証契約者の要求を受けて修理作業を開始する前に送られてきた前記修理業者からの保証契約内容情報の少なくとも一部と修理内容情報とを含む修理着工承認要求に基づいて、前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記修理業者に知らせる修理着工承認手段と、前記修理着工承認要求と同時に、前記修理着工承認を確認後に、またはその間に送られてきた前記修理業者からの見積額を含む見積申請に基づいて、前記見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記修理業者に知らせる見積着工承認手段とを含んで保証事務処理システムを構成した。」という記載、
　
　引用例の上記（テ）の「保証責任が有れば、修理着工承認部１２は修理着工承認をクライアント３０に表示させる（ステップＳ２０８）。すなわち図３のメニュー画面から「修理状況一覧」の項目を選択し、図７のような修理状況一覧を表示させる。修理状況一覧には、各クライアント３０ごとに要求された各修理着工承認要求について、着工承認がされたか否か等がテーブル形式で表示される。より詳細な情報が必要な場合には、詳細表示のボタンを押す。」という記載、
　
　引用例の上記（ト）の「見積が適当であれば、見積着工承認部１６は見積承認されたことをクライアント３０に知らせる（ステップＳ２１３）。例えば図７の修理状況一覧には見積承認がされた旨の表示がなされる。」という記載から、
　
　引用例には、
「前記保証事務処理システムは、前記保証対象確認部により判断した修理請求データを構成する前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記クライアントに出力する修理着工承認手段、
　及び、前記保証対象確認部により判断した修理請求データを構成する前記見積の見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記クライアントに出力する見積着工承認手段を備える」
　ことが開示されていると認められる。
　
　
（ｆ）
　上記（ｅ）の「前記保証事務処理システムは、前記保証対象確認部により判断した修理請求データを構成する前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記クライアントに出力する修理着工承認手段、及び、前記保証対象確認部により判断した修理請求データを構成する前記見積の見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記クライアントに出力する見積着工承認手段を備える」という開示、
（当該開示によれば、「修理請求データ」の修理請求内容が妥当であるか否かを判断していることは明らかである。）
　
　引用例の上記（イ）の「物品を購入した保証契約者が、保証会社に掛け金を支払うことにより、物品を購入した際に付される無料保証期間終了後の一定期間も同様の保証を受けることができる延長保証制度が我が国でも普及しつつある。保証対象となる物品は主に自動車や家電製品であり、特に中古自動車について利用価値が高い。」という記載、
　
　引用例の上記（ス）の「図１に示した保証契約事務処理システムは、メーカーによる無料保証期間経過後の延長保証とも称される自動車保証契約のために利用され、保証会社と保証契約者（通常は自動車の所有者または使用者）との間で、少なくとも保証される修理の内容と保証限度額とを定めた保証契約に基づいて、保証会社と提携して、保証契約者の要求に応えて修理作業を行い、保証契約者に代わって保証会社から修理費用の支払いを受ける修理業者のための保証事務処理システムである。」という記載から、
　
　引用例には、「メーカーによる無料保証期間経過後の延長保証とも称される保証契約のために利用され、自動車や家電製品に関する修理請求データの修理請求内容が妥当であるか否かを判断するシステム」が開示されていると認められる。
　
　
　以上の引用例の記載によれば、引用例には下記の発明（以下、「引用例発明」という。）が開示されていると認められる。
　
「メーカーによる無料保証期間経過後の延長保証とも称される保証契約のために利用され、自動車や家電製品に関する修理請求データの修理請求内容が妥当であるか否かを判断するシステムであって、
　保証事務処理システムであって、オペレーティング・システムを備えたＷｅｂサーバと、
　前記保証事務処理システムにインターネットを通じて接続されたクライアントと
　を備え、
　前記保証事務処理システムは、
　保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段と、
　クライアントからの実行要求に応答して、修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する保証対象確認部と、
　前記保証対象確認部により判断する修理請求データに関連付けられる、保証対象及び保証期間を含む保証契約内容データベース内テーブルの保証契約内容情報を記憶するメモリと、
　前記保証対象確認部により判断した修理請求データを構成する前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記クライアントに出力する修理着工承認手段、
　及び、前記保証対象確認部により判断した修理請求データを構成する前記見積の見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記クライアントに出力する見積着工承認手段と
　を備えることを特徴とするシステム。」
　
　
　
４．対比
　
　本願補正発明と引用例発明とを対比する。
　
（１）
　引用例発明の
　
「メーカーによる無料保証期間経過後の延長保証とも称される保証契約」、
「保証契約検索情報、修理内容情報、及び見積から構成される修理請求データ」、
「オペレーティング・システムを備えたＷｅｂサーバ」、
「インターネット」、
「クライアント」、
「インターネットを通じて送信」は、
　
　それぞれ、本願補正発明の
　
「延長保証契約」、
「修理請求データ」、
「オペレーティング・システムを備えたサーバ」、
「ネットワーク」、
「端末装置」、
「通信回線を通して転送」、　
　
　に相当する。
　
　
（２）
　引用例発明の「保証対象及び保証期間を含む保証契約内容データベース内テーブルの保証契約内容情報」は、
　
　保証対象（すなわち、保証対象の製品）及び（保証対象の製品に関する）保証期間という、保証製品に関する情報を含んでいるのであるから、
　
　本願補正発明の「保証製品テーブルの製品情報」に相当する。
　
　
（３）
　本願補正発明（すなわち、本件補正後の『特許請求の範囲第１項』の記載）では、「修理請求データ」が、修理『完了後』の「修理請求データ」なのか、修理『開始前』の「修理請求データ」なのか、具体的に特定していないことを鑑みれば、
　
　引用例発明の「メーカーによる無料保証期間経過後の延長保証とも称される保証契約のために利用され、自動車や家電製品に関する修理請求データの修理請求内容が妥当であるか否かを判断するシステム」は、
　
　本願補正発明の「延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システム」に相当する。
　
　
（４）
　引用例発明の「保証事務処理システムであって、オペレーティング・システムを備えたＷｅｂサーバ」は、
　
　本願補正発明の「オペレーティング・システムを備えたサーバ」に相当する。
　
　
（５）
　引用例発明の「前記保証事務処理システムにインターネットを通じて接続されたクライアント」は、
　
　本願補正発明の「前記サーバにネットワークを介して接続された端末装置」に相当する。
　
　
（６）
　引用例発明の「保証契約者から修理を依頼された修理業者から、インターネットを通じて送信された、保証契約検索情報、修理内容情報、及び見積から構成される修理請求データを受信する受信手段」と、
　
　本願補正発明の「顧客企業から通信回線を通して転送された修理請求データを受信する受信手段」とは、
　
　本願補正発明（すなわち、本件補正後の『特許請求の範囲第１項』の記載）では、「修理請求データ」の内容を具体的に特定していないこと、及び、「修理請求データ」を一括して受信するのか、逐次的に受信するのかなど、受信方法について具体的に特定していないことを鑑みれば、
　
　「通信回線を通して転送された修理請求データを受信する受信手段」である点で一致し、
　
　本願補正発明では、「受信手段」が「顧客企業」からデータを受信するのに対し、引用例発明では、「受信手段」が「保証契約者から修理を依頼された修理業者」からデータを受信する点、
　で相違する。
　
　
（７）
　引用例発明の「修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する」ことが、
　本願補正発明の「修理請求データの修理請求内容の形式が妥当であるか否かをチェックする」ことに相当することは、
　
　本出願当初明細書の、
・段落【００３４】中の「後述する請求データ記録（月次）プログラムＰ２による形式チェック」という記載、
・段落【００７５】乃至【００８５】の「請求データ記録（月次）プログラムＰ２」に関する記載、
（特に、段落【００７９】中の「・・・、保証製品テーブルＴ５に当該製品データが存在しないと判断した場合（ステップＳ２０３のＹｅｓ）、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「製品データが未登録」を示す‘３０５２’をセットし（ステップＳ２０４）、ステップＳ２０７へ進む。」という記載、
　及び段落【００８０】中の「・・・、その故障発生日が保証製品データの保証期間内にないとき（ステップＳ２０５のＮｏ）、実記憶域５５上のチェック済み修理請求データにエラー・コードとして「修理受付日が保証期間外」を示す‘３１３２’をセットし（ステップＳ２０６）、ステップＳ２０７へ進む。」という記載）
　によっても支持されることを鑑みれば、
　
　引用例発明の「クライアントからの実行要求に応答して、修理請求データを構成する保証契約検索情報に合致する保証契約が保証契約内容データベースに蓄積されていない場合や保証期間を徒過していたような場合、保証契約が無効であると判断する保証対象確認部」と、
　
　本願補正発明の
「前記受信手段により受信した前記修理請求データを記憶すると共に、複数のアプリケーション・プログラムを記憶する第１の記憶手段と、
　前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段」とは、
　
　「前記端末装置からの実行要求に応答して、前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段」である点で一致し、
　
・本願補正発明では、前記受信手段により受信した前記修理請求データを記憶する「第１の記憶手段」を備え、「チェック手段」が「第１の記憶手段」から「修理請求データ」読み出すのに対し、引用例発明では、「チェック手段」は「修理請求データ」を使用するものの、「チェック手段」が「第１の記憶手段」から「修理請求データ」を読み出すことは記載されていない点、
・本願補正発明では、「複数のアプリケーション・プログラム」を「第１の記憶手段」に記憶するのに対し、引用例発明では、そのような記載はない点、
　で相違する。
　
　
（８）
　引用例発明の「前記保証対象確認部により判断する修理請求データに関連付けられる、保証対象及び保証期間を含む保証契約内容データベース内テーブルの保証契約内容情報を記憶するメモリ」と、
　
　本願補正発明の「前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段」とは、
　
　「前記チェック手段によりチェックした当該チェック済み修理請求データに対応する保証製品テーブルの製品情報を記憶する第２の記憶手段」である点で一致し、
　
　本願補正発明では、「前記チェック手段によりチェックした当該チェック済み修理請求データに対応する保証製品テーブルの製品情報」だけでなく「前記チェック手段によりチェックしたチェック済み修理請求データ」を「第２の記憶手段」に記憶するのに対し、引用例発明では、そのような記載はない点、
　で相違する。
　
　
（９）
　引用例発明の「修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否か」というルール、及び、「修理請求データを構成する前記見積の見積額が前記保証限度額の範囲内か否か」というルールが、
　本願補正発明の「予め定められた・・・修理の妥当性を規定する修理審査ルール」に相当することは、
　
　本出願当初明細書の、
・段落【００３４】中の「修理審査プログラムＰ４による実体審査」という記載、
・段落【０１０７】乃至【０１２４】の「修理審査プログラムＰ４」に関する記載、
（特に、段落【０１１６】中の「・・・、チェック済み修理請求データの故障原因が、修理審査条件テーブルＴ４の登録された故障原因コードに存在するかどうかを判定する（ステップＳ４１３）。チェック済み修理請求データの故障原因が修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４１３のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「故障原因で審査対象から除外」を示す‘３４’をセットし（ステップＳ４１４）、ステップＳ４２４に進む。」という記載、
　段落【０１１７】中の「・・・、チェック済み修理請求データの故障処置が、修理審査条件テーブルＴ４の登録された故障処置コードに存在するかどうかを判定する（ステップＳ４１５）。チェック済み修理請求データの故障処置が修理審査条件テーブルＴ４に存在しない場合には（ステップＳ４１５のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「故障処置で審査対象から除外」を示す‘３５’をセットし（ステップ４１６）、ステップＳ４２４に進む。」という記載、
　及び段落【０１１９】中の「・・・、チェック済み修理請求データの請求金額が、修理審査条件テーブルＴ４の登録された範囲内がどうかを判定する（ステップＳ４１９）。修理請求額が範囲内に入らない場合には（ステップＳ４１９のＮｏ）、オペレーティング・システム５４は、Exitモジュール・コードに「修理請求額で審査対象から除外」を示す‘３７’をセットし（ステップＳ４２０）、ステップＳ４２４に進む。」という記載）
　によっても支持されることを鑑みれば、
　
　引用例発明の
「前記保証対象確認部により判断した修理請求データを構成する前記修理内容情報に一つ以上含まれる各修理が前記保証契約内容情報により特定される前記保証契約によりそれぞれ保証されているか否かを判断し、判断結果に基づいて前記各修理が保証されているか否かをそれぞれ表す修理着工承認を前記クライアントに出力する修理着工承認手段、
　及び、前記保証対象確認部により判断した修理請求データを構成する前記見積の見積額が前記保証限度額の範囲内か否かを判断し、判断結果に基づいて前記見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認を前記クライアントに出力する見積着工承認手段」と、
　
　本願補正発明の
「予め定められた修理の妥当性を規定する修理審査ルールに基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段とを備え、
　前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される」こととは、
　
　「予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、審査結果を出力する審査手段」である点で一致し、
　
・本願補正発明では、「修理審査ルール」が製品種類毎に規定されているのに対し、引用例発明では、「修理審査ルール」が製品種類毎に規定されているのか不明である点、
・本願補正発明では、「審査手段」が「チェック済み修理請求データと前記製品情報」を「第２の記憶手段」から読み出すのに対し、引用例発明では、「審査手段」は「チェック済み修理請求データと前記製品情報」を使用するものの、「審査手段」が「第２の記憶手段」から「チェック済み修理請求データと前記製品情報」を読み出すことは記載されていない点、
・本願補正発明では、「妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データ」を出力するのに対し、引用例発明では、「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」を出力する点、、
・本願補正発明では、「審査手段」がひとつの手段で構成されているのに対し、引用例発明では、「審査手段」が「修理着工承認手段」及び「見積着工承認手段」で構成されている点、
・本願補正発明では、「前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される」のに対し、引用例発明では、そのような記載はない点、
　で相違する。
　
　
（１０）
　したがって、本願補正発明と引用例発明とは、
　
「延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、
　オペレーティング・システムを備えたサーバと、
　前記サーバにネットワークを介して接続された端末装置と
を備え、
　前記サーバは、
　通信回線を通して転送された修理請求データを受信する受信手段と、
　前記端末装置からの実行要求に応答して、前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、
　前記チェック手段によりチェックした当該チェック済み修理請求データに対応する保証製品テーブルの製品情報を記憶する第２の記憶手段と、
　予め定められた修理の妥当性を規定する修理審査ルールに基づいて、前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、審査結果を出力する審査手段とを備えることを特徴とする修理審査システム。」
　
　である点で一致し、以下の点で相違する。
　
（相違点１）
　本願補正発明では、「受信手段」が「顧客企業」からデータを受信するのに対し、引用例発明では、「受信手段」が「保証契約者から修理を依頼された修理業者」からデータを受信する点、
　
　
（相違点２）
　本願補正発明では、前記受信手段により受信した前記修理請求データを記憶する「第１の記憶手段」を備え、「チェック手段」が「第１の記憶手段」から「修理請求データ」読み出すのに対し、引用例発明では、「チェック手段」は「修理請求データ」を使用するものの、「チェック手段」が「第１の記憶手段」から「修理請求データ」を読み出すことは記載されていない点、
　
　
（相違点３）　
　本願補正発明では、「前記チェック手段によりチェックした当該チェック済み修理請求データに対応する保証製品テーブルの製品情報」だけでなく「前記チェック手段によりチェックしたチェック済み修理請求データ」を「第２の記憶手段」に記憶するのに対し、引用例発明では、そのような記載はない点、
　
　そのため、
　
　本願補正発明では、「審査手段」が「チェック済み修理請求データと前記製品情報」を「第２の記憶手段」から読み出すのに対し、引用例発明では、「審査手段」は「チェック済み修理請求データと前記製品情報」を使用するものの、「審査手段」が「第２の記憶手段」から「チェック済み修理請求データと前記製品情報」を読み出すことは記載されていない点、　
　
　
（相違点４）
　本願補正発明では、「複数のアプリケーション・プログラム」を「第１の記憶手段」に記憶するのに対し、引用例発明では、そのような記載はない点、
　
　そのため、
　
　本願補正発明では、「前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される」のに対し、引用例発明では、そのような記載はない点、
　
　
（相違点５）
　本願補正発明では、「修理審査ルール」が製品種類毎に規定されているのに対し、引用例発明では、「修理審査ルール」が製品種類毎に規定されているのか不明である点、
　
　
（相違点６）
　本願補正発明では、「妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データ」を出力するのに対し、引用例発明では、「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」を出力する点、
　
　
（相違点７）
　本願補正発明では、「審査手段」がひとつの手段で構成されているのに対し、引用例発明では、「審査手段」が「修理着工承認手段」及び「見積着工承認手段」で構成されている点、
　
　
　
５．相違点に対する判断
　
（１）相違点１について
　
　保証契約を行う顧客として、個人の他、企業であってもよいことは、一般常識である。
　
　また、本人が各種手続きを直接行う以外に、各種手続きに詳しい者に代理などさせることによって、本人が各種手続きを間接的に行うことも、一般常識である。
　
　したがって、引用例発明に対して、当該一般常識を適用し、
　保証契約者から修理を依頼された修理業者が手続きを行う代わりに、顧客企業が手続きを行う、
　すなわち、「受信手段」が「保証契約者から修理を依頼された修理業者」からデータを受信するかわりに、「受信手段」が「顧客企業」からデータを受信するように構成することは、
　当業者が容易に想到し得ることである。
　
　
（２）相違点２について
　
　（サーバなどの）情報処理装置が、（受信した情報などの）各種情報を、一旦、記憶装置（例：ディスク装置）に記憶しておき、各種処理を行う際に、当該記憶装置に記憶されたデータを読み出すことは、情報処理分野における周知技術である。
　
　したがって、引用例発明に対して、当該周知技術を適用し、
　前記受信手段により受信した前記修理請求データを記憶する「第１の記憶手段」（例：ディスク装置）を備え、「チェック手段」が「第１の記憶手段」から「修理請求データ」読み出すように構成することは、
　当業者が容易に想到し得ることである。
　
　
（３）相違点３について
　
　（サーバなどの）情報処理装置が、（所定の処理後の情報などの）各種情報を、一旦、記憶手段（例：実記憶域（メモリ））に記憶しておき、所定の処理に後続する処理などの各種処理を行う際に、当該記憶手段に記憶されたデータを読み出すことは、情報処理分野における周知技術である。　
　
　したがって、引用例発明に対して、当該周知技術を適用し、
　「前記チェック手段によりチェックした当該チェック済み修理請求データに対応する保証製品テーブルの製品情報」だけでなく「前記チェック手段によりチェックしたチェック済み修理請求データ」を「第２の記憶手段」（例：実記憶域（メモリ））に記憶したり、
　「審査手段」が「チェック済み修理請求データと前記製品情報」を「第２の記憶手段」から読み出したりすることは、
　当業者が容易に想到し得ることである。
　
　
（４）相違点４について
　
　引用例の上記（シ）の「インターネットを通じて情報を送受信する場合、保証事務処理システムはＷｅｂサーバであり、各データベースはＷｅｂサーバにネットワークを通じて、または通じないで接続されている。保証事務処理システムを構成する各手段は１つのＷｅｂサーバにモジュールとして構築されていても、独立したＷｅｂサーバであってもよい。」という記載、
　及び「Ｗｅｂサーバ」が提供する機能は主にソフトウエアによって実現されることから、
　引用例発明の「審査手段」をソフトウエア・モジュールとして構築することが示唆されている。
　また、ソフトウエア・モジュールをアプリケーション・プログラムによって実現することは、情報処理分野における周知技術である。
　
　しかも、複数のアプリケーション・プログラムを予め記憶装置（例：ディスク装置）に記憶しておき、特定のアプリケーション・プログラムによる処理が要求されたとき、オペレーティング・システムの管理下で、当該記憶装置（例：ディスク装置）から当該特定のアプリケーション・プログラムを記憶手段（例：実記憶域（メモリ））にロードして、当該特定のアプリケーション・プログラムを実行させることも、情報処理分野における周知技術である。
　
　したがって、引用例発明に対して、当該周知技術を適用し、
　「複数のアプリケーション・プログラム」を「第１の記憶手段」に記憶しておき、
　「前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される」ように構成することは、
　当業者が容易に想到し得ることである。
　
　
（５）相違点５について
　
　家電製品には、テレビ装置、冷蔵庫、洗濯機、クーラーなど、様々な製品種類があり、当該製品種類に応じて延長保証契約で対応すべき修理請求が異なることは、一般常識である。
　
　したがって、引用例発明に対して、当該一般常識を適用し、
　様々な製品種類の修理請求に対応できるように、「修理審査ルール」を製品種類毎に規定するように構成することは、当業者が容易に想到し得ることである。
　
　
（６）相違点６について
　
　情報処理装置が出力する情報を、（操作者が理解しやすい）自然言語文字列情報としたり、（自然言語文字列に比べて必要とする記憶領域を節約できるものの、操作者が理解しにくい）コード情報としたりすることは、情報処理分野における周知技術である。
　
　一方、引用例発明では、「審査手段」で審査された「修理請求データ」（すなわち、「審査済み修理請求データ」に対して、「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」を付加して出力するのか否かについては不明ではあるものの、
　引用例の【図７】中の「修理状況一覧」には、クライアントに対する出力としての、「連絡日」欄、「お名前」欄、「車名」欄、及び「申込者番号」欄の他に、（「未承認」及び「承認済」という表示例が挙げられている）「着工承認」欄、（「未入力」という表示例が挙げられている）「見積承認」欄が図示されていることから、
　「審査済み修理請求データ」に関連する情報に対して、「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」を関連付けて出力する技術的思想が示唆されているといえる。
　
　したがって、引用例発明に対して、当該示唆に基づき、当該周知技術を適用し、
　「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」をコード情報で表現したり、
　「審査済み修理請求データ」に関連する情報に対して、「各修理が保証されているか否かをそれぞれ表す修理着工承認」及び「見積額が前記保証限度額の範囲内か否かをそれぞれ表す見積着工承認」を関連付けて出力することによって、
　「妥当である場合には妥当であるコードを、妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データ」を出力するように構成することは、当業者が容易に想到し得ることである。
　
　
（７）相違点７について
　
　一連の処理をひとつの手段で行ったり、複数の手段に分担させて処理を行ったりすることは、情報処理分野における周知技術である。 
　また、一連の処理をひとつの手段で行うか、複数の手段に分担させて処理を行うかによって、格別の作用効果はないものと認められる。 
　
　したがって、引用例発明に対して、当該周知技術を適用し、
　「審査手段」を「修理着工承認手段」及び「見積着工承認手段」で構成する代わりに、「審査手段」をひとつの手段で構成することは、当業者が容易に想到し得ることである。
　
　
　
６．付記
　
　上記「第２　〔理由〕４．対比」中の（３）における
「本願補正発明（すなわち、本件補正後の『特許請求の範囲第１項』の記載）では、「修理請求データ」が、修理『完了後』の「修理請求データ」なのか、修理『開始前』の「修理請求データ」なのか、具体的に特定していないことを鑑みれば、・・・」
　という指摘に関して、仮に、本願補正発明が、修理『完了後』の「修理請求データ」の取扱いに関する発明であると、特許請求の範囲に明記されているとしても、以下の理由により、依然として進歩性を有しない。
　
（理由）
　
　修理『完了後』に提出される納品書や請求書の内容の妥当性を自動的に判断する技術は周知技術（例えば、特開２００３−５０８７６号公報（特に、段落【０００４】、【００１４】乃至【００１６】、【００３２】、【００３６】乃至【００６１】の記載）、特開２００３−１１７９６号公報（特に、段落【０００４】乃至【０００６】、【００１８】、【００３３】乃至【００４４】の記載）を参照）である。
　
　したがって、修理『完了後』に提出されるデータの妥当性を自動的に判断するべく、引用例発明に対して、当該周知技術を適用し、
　修理『完了後』に転送される「修理請求データ」に対しても処理を行えるようにすることは、当業者が容易に想到し得ることである。
　
　
　
７．むすび
　
　したがって、本願補正発明は、引用例発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。  
　
　つまり、本件補正は、平成１８年改正前特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　
　
　
第３　本願発明について 
　
１．本願発明  
　
　平成１８年４月３日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明は、平成１７年１２月９日付けの手続補正書の特許請求の範囲第１項に記載されたとおりのものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。  
 　  
「　【請求項１】　延長保証契約における家電製品に関する修理請求データの修理請求内容が妥当であるか否かの修理審査を行う修理審査システムであって、
　サーバと、
　前記サーバにネットワークを介して接続された端末装置と
を備え、
　前記サーバは、
　顧客企業から通信回線を通して転送された修理請求データを受信する受信手段と、
　前記受信手段により受信した前記修理請求データを記憶する第１の記憶手段と、
　前記端末装置からの実行要求に応答して、前記第１の記憶手段から読み出した前記修理請求データの修理請求内容の形式が妥当であるか否かをチェックするチェック手段と、
　前記チェック手段によりチェックしたチェック済み修理請求データと当該チェック済み修理請求データに対応する保証製品テーブルの製品情報とを記憶する第２の記憶手段と、
　予め定められた製品種類毎の修理の妥当性を規定する修理審査ルールに基づいて、前記第２の記憶手段から読み出した前記チェック済み修理請求データと前記製品情報との修理請求内容の実体が妥当であるか否かを審査し、妥当である場合には妥当であるコードを、
妥当でない場合には不適の種類を表すコードを示す審査結果を添付した審査済み修理請求データを出力する審査手段と
を備えた修理審査システム。」  
 　  
　
 　  
２．引用例の認定
　
　原査定の拒絶の理由で引用された引用例、及びその記載事項は、前記「第２　〔理由〕３．引用例の認定」に記載したとおりである。  
 　  
 　  
　
３．対比及び判断  
 　  
　本願発明は、上記「第２　〔理由〕１．補正内容」及び「第２　〔理由〕２．本願補正発明の認定」で検討した本願補正発明から、  
　「
オペレーティング・システムを備えた
と共に、複数のアプリケーション・プログラムを記憶する
前記審査手段は、前記オペレーティング・システムが、前記端末装置からのプログラム実行要求に基づいて、前記第１の記憶手段に記憶されている前記複数のアプリケーション・プログラムから必要なアプリケーション・プログラムを前記第２の記憶手段にロードして当該アプリケーション・プログラムの命令を実行することにより実現される
 　  
 　そうすると、本願発明の構成要件を全て含み、更に他の要件を付加したものに相当する本願補正発明は、
　前記「第２〔理由〕５．相違点に対する判断」に記載したとおり、引用例発明に基づいて、当業者が容易に発明することができたものであるから、
　本願発明も、同様の理由により、引用例発明に基づいて当業者が容易に発明することができたものである。  
 　  
 　  
４．むすび  
 　  
　したがって、本願発明は、引用例発明に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないから、本願は拒絶されるべきものである。  
 　  
 　よって結論の通り審決する。