【事件の表示】
　平成　８年特許願第２５１６２３号「産業用機器の遠隔保守システムおよび方法、デバイス生産方法、ならびに監視装置および方法」拒絶査定不服審判事件〔平成１０年　４月１４日出願公開、特開平１０−　９７９６６〕について、次のとおり審決する。
【結論】
　本件審判の請求は、成り立たない。
【理由】
１．手続の経緯
　本願は、平成８年９月２４日（優先権主張平成８年７月３１日）を出願日とする出願であって、平成１５年３月１１日付で拒絶査定がなされ、これに対し平成１５年４月２４日に拒絶査定に対する審判請求がなされるとともに、同年５月２３日付で手続補正がなされた。その後、当審において平成１７年４月１５日付で拒絶理由が通知され、平成１７年６月１７日に意見書が提出されるとともに手続補正がなされたものであり、その請求項に係る発明は、平成１７年６月１７日付の手続補正書で補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１ないし１４に記載された事項により特定されるとおりのものであると認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
「イントラネットを介して構成された、産業用機器の遠隔保守システムであって、
　前記産業用機器を監視する監視装置から、インターネットおよび前記イントラネットを介して、前記産業用機器の異常状態の情報を受信する受信手段と、
　前記受信手段により受信された情報と、前記異常状態への対処方法の情報とを記録するデータベースと、
　前記データベースにアクセスして、前記データベースに記録された情報の参照および前記データベースへの前記対処方法の情報の入力を行うための、前記イントラネットに接続されたアクセス手段と
　を有することを特徴とする産業用機器の遠隔保守システム。」
２．引用例
　これに対して、当審において平成１７年４月１５日付の拒絶理由通知で引用した、本願の優先日前の平成８年２月６日に頒布された刊行物である特開平８−３６４１５号公報（以下、「引用例１」という。）には、図１、図２、図３、及び図９と共に、次のとおり記載されている。
「【請求項１】複数の実働システムがＬＡＮ結合されている分散システムに於いて、分散システムのＬＡＮとは独立した複数の実働システムと実働システム側の保守用端末を接続するＬＡＮと、
保守システムと保守システム側の保守用端末を接続するＬＡＮと、
実働システム側ＬＡＮと保守システム側ＬＡＮとを接続する回線と、
実働システム内にあって、自システムを監視し異常が検出されると、他の実働システム、保守システムおよび保守用端末へ異常発生通知および異常の種別を送信する手段と、
実働システム内にあって、発生した異常の種別ごとに採取するデータ項目を記載した保守テーブルと、
実働システム内にあって、自システムの異常発生時および他の実働システムからの異常発生通知が受信されたときに、保守テーブルを参照して異常種別に該当する項目のデータを自システムより採取して異常時データベースへ格納する手段と、
保守システム内にあって、保守用端末からの入力操作により、実働システムに対して異常時データベースの転送を要求する手段と、
実働システム内にあって、データベース転送要求が受信されると、自システムの異常時データベースから異常時データを読み出して保守システムへ送信する手段と、
保守システム内にあって、実働システムより受信した異常時データを自システムの異常時データベースに格納する手段と、
実働システム内および保守システム内にあって、保守用端末のデータ転送要求に応じて自システムの異常時データベースから異常時データを読み出して保守用端末へ送信する手段と、
を備えたことを特徴とする分散システムのリモートメンテナンス装置。」（特許請求の範囲請求項１）
「【０００１】
　【産業上の利用分野】本発明は、分散・配置されている複数の実働システムを、回線を介して遠隔地よりメンテナンスするリモートメンテナンス装置に関する。
　【０００２】
　【従来の技術】従来、分散されたシステムをリモートメンテナンスする場合は、図９のようにして行われている。これは分散配置されたｎ個の実働システム１１〜１ｎが回線２３１〜２３ｎを介して保守システム７に接続されている。各実働システム１１〜１ｎには異常時データベース２１〜２ｎが備えられ、異常発生時に収集されたデータがいったん異常時データベースに格納されてから保守システム７へ転送されることにより、保守システム７側で実働システム１１〜１ｎをメンテナンスすることができる。実働システム１１〜１ｎの保守者と保守システム７の保守者との間は、電話またはＦＡＸで連絡がとられる。」（第１、２段落）
「【００１８】
　【実施例】以下、図に沿って本発明の実施例を説明する。図１は第１および第２の発明にかかる第１の実施例を示す構成図である。図において、１１〜１ｎは実働システムであり、それぞれ、診断保守プログラム２１〜２ｎ、異常時データベース３１〜３ｎ、保守定数表４１〜４ｎを内蔵している。これら実働システム１１〜１ｎは、実働システム保守用ＬＡＮ５を介して相互に接続されるとともに、保守用端末であるところのマルチメディア端末６に接続されている。
　【００１９】一方、実働システム１１〜１ｎを保守するために設置されている保守システム７には、異常時データ転送プログラム８および異常時データベース写し９１〜９ｎを内蔵している。異常時データベース写し９１〜９ｎには、実働システム１１〜１ｎから転送されてきた異常時データベース３１〜３ｎがそれぞれ格納される。保守システム７は、保守システム用ＬＡＮ１１を介してマルチメディア端末１２に接続されている。ＬＡＮ５，１１は、それぞれ回線アダプタ１３，１４を介して、回線１５に接続されている。
　【００２０】なお、マルチメディア端末６，１２は、図示しないが、電子黒板、動画および音声の入出力機能を備えるとともに、端末相互間での通信機能を備えている。また、保守定数表４１〜４ｎは、表１のように構成されており、実働システムにおいて発生する異常の種類と、その場合に異常時データベースへ格納するデータの項目およびＩＰＬの要否が書き込まれている。」（第１８〜２０段落）
「【００２３】図２は図１の診断保守プログラム２１〜２ｎの動作を示すフローチャートである。以下、このフローチャートに基づき、図１を参照しながら動作を説明する。各実働システムにおいて、診断保守プログラム２が起動されると、自システムの自己診断処理を行い（Ｓ１）、正常であれば（Ｓ２ＹＥＳ）、他システムからＬＡＮ５を介して送られてくる異常通知の有無をチェックする（Ｓ３）。ここで、異常通知があれば（Ｓ４ＹＥＳ）、保守定数表４を参照して送られてきた異常の種別に該当するデータを収集して自システムの異常時データベース３へ格納する（Ｓ５，６）。
　【００２４】ここで、保守システム７の異常時データ転送プログラム８が保守員により端末６，１２を介して起動されると、自システムへＬＡＮ１１、回線１５およびＬＡＮ５を介して異常時データベース転送の要求が送られる。そこで、異常時データベースの転送要求の有無をチェックし（Ｓ７）、転送要求があれば（Ｓ８ＹＥＳ）、自システムの異常時データベース３を保守システム７へ転送する（Ｓ９）。保守システム７では、送られた異常時データが該当する異常時データベース写し９へ格納される。同様に、マルチメディア端末６，１２からも異常時データベースの転送が要求されることがあり、その場合も同じくマルチメディア端末６，１２へ異常時データベースのデータが転送される。転送がすむとＳ１へ戻る。
　【００２５】また、Ｓ２で自システムの自己診断の結果、異常が検出されれば（Ｓ２ＮＯ）、その異常の種別を判定し（Ｓ１０）、保守定数表４を参照して異常の種別に該当するデータを収集して自システムの異常時データベース３へ格納する（Ｓ１１，１２）。さらに、保守定数表４のＩＰＬ要否を参照して、ＩＰＬが必要な場合はＩＰＬ処理を行う（Ｓ１３ＹＥＳ，Ｓ１４）。次に、保守定数表４の異常通知システム一覧に記載されている異常通知システムおよび伝送送信パラメータに基づき、ＬＡＮ５を介して他の実働システムおよび端末６へ、異常の発生および異常の種別を通知する（Ｓ１５）。続いて、ＬＡＮ５、回線１５およびＬＡＮ１１を介し、保守システム７および端末１２へ、同じく、異常の発生および異常の種別を通知し（Ｓ１６）、Ｓ１へ戻る。
　【００２６】これらの処理により、各実働システム１１〜１ｎに異常が発生すると、その異常の種別に応じて異常原因の解析に必要なデータが全ての実働システム１１〜１ｎで採取されてそれぞれの異常時データベース３１〜３ｎに蓄えられる。同時に、異常の発生およびその種別がそれぞれ端末６，１２へ通知される。さらに、保守員が端末６，１２から保守システム７へ要求することにより、各実働システム１１〜１ｎに格納された異常時データが保守システム７へ集められる。
　【００２７】こうして保守システム７の異常時データベース写し９１〜９ｎへいったん異常時データが収集されたことにより、以後、任意のタイミングで端末６，１２から保守システム７の異常時データベース写し９１〜９ｎを呼び出して、発生した異常に関する障害解析を行うことができる。また、保守員はマルチメディア端末６，１２の相互間でも、電子黒板、音声、動画を用いて交信可能であるので、多元的に情報を交換することが可能となり、使い勝手が向上する。
　【００２８】図３は、第１の発明にかかる第２の実施例を示す構成図である。この実施例は図１の第１の実施例と主要部が共通であるので、共通部分には同一符号を付して説明を省略し、異なる部分についてのみ説明する。実働システム保守用ＬＡＮ５には、マルチメディア端末ではない通常の保守端末２１を接続し、保守システム用ＬＡＮ１１にも、同じくマルチメディア端末ではない通常の保守端末２２１〜２２ｍを接続する。この実施例も第１の実施例と同様に作動するが、保守端末が増した分、各ロケーションで複数の保守員により障害解析を行うことができる。
　【００２９】これらのことから第１および第２の実施例では次のような効果が得られる。
　（１）複数の実働システム１１〜１ｎを実働システム保守用ＬＡＮ５に接続し、さらに回線１５を介して保守システム用ＬＡＮ１１に接続することにより、複数の保守者がそれぞれの在席ロケーションで相互に対話し、異常時データベース写し９を参照しながら綿密に障害解析を行うことが可能となり、メンテナンスの作業性が向上する。
　（２）従来技術では複数本必要であった回線が１本ですみ、工事量が少なくなりコストが削減される。
　【００３０】（３）実働システム保守用ＬＡＮ５を導入したことにより、実働システム１１〜１ｎ間のＬＡＮが複数本、複数種類であっても、各実働システムに負担を与えることなく、容易に実働システム１１〜１ｎ、保守システム７、端末６，１２，２１，２２相互間の連携が可能になる。
　（４）複数の実働システムが結合している分散システムのＬＡＮに障害が発生した場合でも、その障害情報を収集することができる。
　（５）診断保守プログラム２１〜２ｎ、異常時データベース３１〜３ｎ、保守定数表４１〜４ｎの導入により、実働システム相互の関係に起因する障害についても調査が容易に行える。
なお、第１および第２の実施例では、実働システム１１〜１ｎおよび保守システム７に機能を追加することで、障害部分のリモート修正を行うこともできる。」（第１８〜３０段落）
これらの記載により、引用例１には、
「分散・配置されている複数の実働システムを、回線１５を介して遠隔地よりメンテナンスするリモートメンテナンス装置であって、
入出力機能とともに、端末相互間での通信機能を備えている保守用端末と、実働システムと実働システム側の保守用端末を接続するＬＡＮ５と
保守システムと保守システム側の保守用端末を接続するＬＡＮ１１と、
実働システム側ＬＡＮ５と保守システム側ＬＡＮ１１とを、それぞれ回線アダプタ１３，１４を介して、接続する回線１５と
実働システム内にあって、自システムを監視し異常が検出されると、他の実働システム、保守システムおよび保守用端末へ異常発生通知および異常の種別を送信する手段と、
実働システム内にあって、発生した異常の種別ごとに採取するデータ項目を記載した保守テーブルと、
実働システム内にあって、自システムの異常発生時および他の実働システムからの異常発生通知が受信されたときに、保守テーブルを参照して異常種別に該当する項目のデータを自システムより採取して異常時データベースへ格納する手段と、
保守システム内にあって、保守用端末からの入力操作により、実働システムに対して異常時データベースの転送を要求する手段と、
実働システム内にあって、データベース転送要求が受信されると、自システムの異常時データベースから異常時データを読み出して保守システムへ送信する手段と、
保守システム内にあって、実働システムより受信した異常時データを自システムの異常時データベースに格納する手段と、
実働システム内および保守システム内にあって、保守用端末のデータ転送要求に応じて自システムの異常時データベースから異常時データを読み出して保守用端末へ送信する手段と、
実働システム及び保守システムに機能として追加された障害部分のリモート修正を行う手段と、
を備えたことを特徴とする分散システムのリモートメンテナンス装置。」
が記載されている。
　また、当審において平成１７年４月１５日付の拒絶理由通知で引用した、本願の優先日前の平成７年１２月に頒布された刊行物である日本ファジィ学会誌、Ｖｏｌ．７，Ｎｏ．６，ｐｐ．１１３４−１１４０「生産工場ネットワークコンサルティングシステム」柴田崇徳、小林利典、　（１９９５）（以下、「引用例２」という。）には、図１と共に次のとおり記載されている。
「一方、ネットワーク接続のインターフェースの進歩により、世界中どことでも、１対１、１対多、多対多でコミュニケーションがとれるインターネットが急速に発達してきた。当初はコンピュータを使う研究者たちだけの世界だったが、電話回線を通して家庭にまで入り込んでおり、世界のどことでも情報交換を瞬時に行うことができるようになった。通信速度や料金などの関係で、情報インフラ整備が待たれる部分もあるが、インターネット上でどのような情報を交換するが今後の大きな課題であるといえる。
　そこで、本稿では日本の産業構造が大きく変わる中、インターネットを利用することによって、これまでに培われてきた「ものづくり」を基本とする日本の財産といえる生産現場のノウハウを保存、拡張し、かつ新たな産業構造を作り出すための生産工場ネットワークのためのコンサルティングシステムについて述べる。」（第１頁（１１３４頁）右欄第１４行〜第２頁（１１３５頁）左欄第１行）
「上述のように、生産工場におけるロボットアームの教示作業の自動化、省力化に役立つ基礎的技術が、独立して研究され、その有効性が示されてきている。それらを統合化する研究開発として、それらの技術を組み合わせて、実用レベルで役立つシステムの研究開発を試みている。
　さらにこれを前提技術として、実際の生産工場での様々な作業で、教示作業のためのスキルを収集し、データベース化をはかる。そして、分散化、遠隔化している生産工場をネットワークで結び、各工場からデータベースにアクセスし、スキルを相互利用したり、新たな作業に関するスキルを登録したりする。このようなスキルのデータベースを利用した作業計画を行うシステムをコンサルティングシステムと呼んでいる（図１）。なお、本稿ではスキルを中心に述べているが、データベースには製造ライン設計のノウハウなども含み得る。これまでに、生産技術のための実際の作業に関する情報をネットワークで利用する研究もこれまでになされていない。」（第４頁（１１３７頁）右欄第１９行〜第５頁（１１３８頁）左欄第１５行）
３．対比
　そこで、本願発明と引用例１に記載された発明（以下「引用例１発明」という。）とを対比すると、
　引用例１発明の「実働システム」には、「保守システム」に「異常時データ」が受信されるようにする手段として、「自システムを監視し異常が検出されると、他の実働システム、保守システムおよび保守用端末へ異常発生通知および異常の種別を送信する手段」、「発生した異常の種別ごとに採取するデータ項目を記載した保守テーブル」、「自システムの異常発生時および他の実働システムからの異常発生通知が受信されたときに、保守テーブルを参照して異常種別に該当する項目のデータを自システムより採取して異常時データベースへ格納する手段」、及び「データベース転送要求が受信されると、自システムの異常時データベースから異常時データを読み出して保守システムへ送信する手段」がそれぞれ備えられており、第２５段落及び第２６段落に記載されているように、「自システムの自己診断の結果、異常が検出されれば（Ｓ２ＮＯ）、その異常の種別を判定し（Ｓ１０）、保守定数表４を参照して異常の種別に該当するデータを収集して自システムの異常時データベース３へ格納」し、「ＬＡＮ５、回線１５およびＬＡＮ１１を介し、保守システム７および端末１２へ、」「異常の発生および異常の種別を通知し」、「保守員が端末６，１２から保守システム７へ要求することにより、各実働システム１１〜１ｎに格納された異常時データが保守システム７へ」転送される。これによると、各「実働システム」は、自システムの異常発生と異常の種別を「保守システム」側に通知するだけでなく、「保守システム」側からの要求に応じて、「自システムの異常発生時」「発生した異常の種別ごとに採取するデータ項目を記載した」「保守テーブルを参照して異常種別に該当する項目のデータ」を自システムの「異常時データベースへ格納」し、「データベース転送要求が受信されると、自システムの異常時データベースから読み出」し、「異常時データ」として「保守システム」側に伝えるものであるから、引用例１発明の「リモートメンテナンス装置」では、「実働システム」をメンテナンス、すなわち、保守する「保守システム」側から見ると、「実働システム」側にある、上述の一連の「保守システム」に「異常時データ」が受信されるようにする手段と「ＬＡＮ５」と「回線アダプタ１３」が、「実働システム」の異常を監視し、異常の発生および異常の種別を通知しつつ、当該異常に関する情報を「異常時データ」として「保守システム」に送信するものである。したがって、引用例１発明の、上述の一連の「保守システム」に「異常時データ」が受信されるようにする手段、「ＬＡＮ５」及び「回線アダプタ１３」は、本願発明の「監視装置」相当し、「異常時データ」は、本願発明の「異常状態の情報」に相当する。
　また、本願発明においては、「アクセス手段」は「イントラネット」に接続されると共に、「データベース」にアクセスし、当該「データベース」は「受信手段により受信された情報」を記録するから、イントラネットの性質上当然「アクセス手段」と「データベース」は「イントラネット」に接続されることによって「インターネット」からの情報を記録し、かつ、「前記データベースに記録された情報の参照」を行うことができる構成である一方、引用例１発明における「保守システム」内には、「実働システムより受信した異常時データを自システムの異常時データベースに格納する手段」及び「保守用端末のデータ転送要求に応じて自システムの異常時データベースから異常時データを読み出して保守用端末へ送信する手段」が備えられ、かつ、引用例１の第１８段落及び第１９段落の記載によれば、「保守システム」は「ＬＡＮ１１」を介して「保守用端末であるところのマルチメディア端末６」に接続されているから、引用例１発明においても、「実働システム」側から送られてくる「異常時データ」を「ＬＡＮ１１」を介して、「異常時データベース」に格納し、「保守用端末」で「保守システム」内の「異常時データベース」から「異常時データ」は読み出される。したがって、引用例１発明の「保守システム」内の「異常時データーベース」は、本願発明の「データベース」に、引用例１発明の「保守用端末」は、本願発明の「アクセス手段」にそれぞれ相当する。
　さらに、本願発明における「受信手段により受信された情報」は、最終的に本願発明の「データベース」に記録されるものであり、「産業用機器を監視する監視装置から、インターネットおよび前記イントラネットを介して、前記産業用機器の異常状態の情報を受信する受信手段」は、「インターネットおよび前記イントラネット」を通して「監視装置」から送られてくる情報を、本願発明の「データベース」に記録するために受信するものである。他方、引用例１発明においては、「保守システムと保守システム側の保守用端末を接続するＬＡＮ１１」を介して、「回線アダプタ１４」、「保守システム」は相互に接続され、「保守システム」内の「異常時データベース」も「ＬＡＮ１１」を介して、「実働システム」側から送られてくる「異常時データ」を格納するので、回線１５と接続される「回線アダプタ１４」、「ＬＡＮ１１」及び「保守システム」は総体として、本願発明の「受信手段」と同じ機能を有するのは明らかである。
　このように見ると、保守システムと保守システム側の保守端末、回線アダプタ１４とを相互に接続する「ＬＡＮ１１」は、本願発明における「データベース」と「アクセス手段」それぞれに相当するものを相互に接続し、かつ、回線１５から送信された「異常時データ」を「異常時データベース」に格納できるようにするので、本願発明の「イントラネット」に相当し、「回線アダプタ１４」、「保守システム」内の「異常時データベース」、及び「保守用端末」全体は、実働システムに対して、回線１５を通してリモートメンテナンス、すなわち、遠隔保守をする構成であるから、引用例１発明の「ＬＡＮ１１」で相互に接続された「回線アダプタ１４」、「保守システム」内の「異常時データベース」、及び「保守用端末」は、本願発明の「遠隔保守システム」に相当する。
　よって、本願発明と引用例１発明とは、
「イントラネットを介して構成された、遠隔保守システムであって、
　監視装置から、前記イントラネットを介して、異常状態の情報を受信する受信手段と、
　前記受信手段により受信された情報を記録するデータベースと、
　前記データベースにアクセスして、前記データベースに記録された情報の参照を行うための、前記イントラネットに接続されたアクセス手段と
　を有することを特徴とする遠隔保守システム。」
で一致し、以下の点で相違する。
［相違点１］
　本願発明は、「産業用機器の遠隔保守システム」であるのに対して、引用例１発明は、分散・配置されている複数の実働システムを、回線を介して遠隔地よりメンテナンスする「回線アダプタ１４」、「保守システム」内の「異常時データベース」、「保守用端末」からなる装置である点
［相違点２］
　本願発明は、「産業用機器を監視する監視装置から、インターネットおよび前記イントラネットを介して、前記産業用機器の異常状態の情報を受信する受信手段」を備えているのに対して、引用例１発明では、「回線１５」及び「ＬＡＮ１１」を介して、「異常時データ」を受信する手段を備えている点
［相違点３］
　本願発明は、「前記受信手段により受信された情報と、前記異常状態への対処方法の情報とを記録するデータベース」及び「前記データベースに記録された情報の参照および前記データベースへの前記対処方法の情報の入力を行うための、前記イントラネットに接続されたアクセス手段」を備えるのに対して、引用例１発明は、「保守システム」内に「異常時データを自システムの異常時データベースに格納する手段」、「保守用端末のデータ転送要求に応じて自システムの異常時データベースから異常時データを読み出して保守用端末へ送信する手段」及び「障害部分のリモート修正を行う手段」を備えている点
４．判断
［相違点１について］
　引用例１発明では、保守されるものは「実働システム」とされており、本願発明における「産業用機器」より、広い概念を含んでいるが、引用例２には、実際の生産工場での様々な作業で、教示作業のためのスキルや製造ライン設計のノウハウなどを収集し、データベース化をはかり、分散化、遠隔化している生産工場をネットワークで結び、各工場からデータベースにアクセスし、スキルを相互利用することが記載されており（第５頁左欄第２〜１２行）、製造ラインなどの産業用機器がネットワーク化されることが公知であり、そのような生産工場の産業用機器が、異常発生時など保守を必要とするものであることも明らかであるから、引用例１発明においてリモートメンテナンスされる「分散・配置されている複数の実働システム」として、引用例２に記載の生産工場のネットワークにおける製造ラインの産業用機器を選ぶこと、また、その場合には産業用機器を「実働システム」のひとつとして保守の対象とすることは、当業者が容易に想到し得た事項である。
［相違点２について］
　引用例１発明には「実働システム」側から「保守システム」側に情報を送るものとしては、回線１５と記載されているだけであり、具体的にいかなる回線が使用可能かについて記載されていないが、引用例２には、インターネットを利用することにより、生産現場のノウハウを保存、拡張し、かつ新たな産業構造を作り出すための生産工場ネットワークのためのコンサルティングシステムについて、実際の生産工場での様々な作業で、教示作業のためのスキルや製造ライン設計のノウハウなどを収集し、データベース化をはかり、分散化、遠隔化している生産工場をネットワークで結び、各工場からデータベースにアクセスし、スキルを相互利用したり、新たな作業に関するスキルを登録するなどして用いることが記載されており（第１頁右欄第２６行〜第２頁左欄第１行及び第５頁左欄第２〜１０行）、遠隔地点をつなぐ通信回線としてインターネットを工場などの生産現場に用いることが本願優先日前に既に公知であるから、遠隔保守のために用いられる、引用例１発明における回線１５として、このように遠隔化している生産工場のネットワークを形成するためには公知の回線である、インターネットを用いることは、当業者が適宜なしえたものであると認められる。
［相違点３について］
　引用例１発明においては、実働システムの障害部分をリモート修正する手段は、機能として実働システムと保守システムに追加されたものであるが、本願発明においては、データベースに異常状態への対処方法を入力し、記録している。しかし、引用例１発明では、異常時データは「保守システム」内の「異常時データベース」に記録されており、これを保守用端末から参照することが可能であるとともに、保守用端末には入出力機能と端末相互間の通信機能が備えられており（第２０、２７段落）、かつ、「保守システム」内の機能として、リモート修正する手段があるから、引用例１発明においても、保守用端末の入出力機能によって保守システム側から実働システム側を修正することは当業者にとって明らかである。そこで、リモート修正は異常状態への対処方法の一種であって、保守用端末の入出力機能によって、リモート修正の情報をデータベースに入力し、記録することは、電子計算機を使ったシステムとしては一般的な構成であるから、引用例１発明において、リモート修正する手段を追加する際に、「保守システム」内の「異常時データベース」に対処方法を入力し、記録することは、当業者が適宜なしえた事項である。
　したがって、本願発明は、当業者が引用例１及び２に記載された発明に基づいて容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
５．むすび
　以上のとおりであるから、請求項２ないし１４に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。