【事件の表示】
　特願２００９−２０１８４７「診断ネットワークシステム」拒絶査定不服審判事件〔平成２２年　１月２８日出願公開、特開２０１０−　１７５６３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１．手続の経緯
　
１．手続の経緯の概要
　
（１）出願までの経緯
　１９９５年６月７日のアメリカ合衆国での２件の出願（出願番号：０８／４７７２９７、０８／４８４６６０。以下「第一国出願」と記す。）を基礎とするパリ条約に基づく優先権主張をそれぞれ伴って、
平成８年６月７日（以下「優先日」と記す。）に特願平０８−１８２６０１号、及び、特願平０８−１８２６０２号（以下、これらを「国内優先権基礎出願」と記す。）が出願され、
平成９年６月６日に、該国内優先権基礎出願に基づく国内優先権の主張を伴って、特願平０９−１４９４９６号（以下「祖父出願」と記す。）が出願され、
平成１８年７月１８日に、該祖父出願を原出願とする特許法第４４条第１項の規定による新たな特許出願（以下「分割出願」と記す。）として、特願２００６−１９６２１１号（以下「親出願」と記す。）が出願された。
　そして、本件審判請求に係る出願（以下、「本願」と記す。）は該親出願を原出願とする分割出願として、
平成２１年９月１日に出願されたものである。
　
　なお、上記、祖父出願は１９９５年６月７日のアメリカ合衆国での出願（出願番号：０８／４７７０８３）を基礎とするパリ条約に基づく優先権主張を伴って平成８年６月７日に出願された特願平０８−１８２６０３号に基づく国内優先権の主張も伴っていたが、平成９年７月２５日付けで、該国内優先権の主張は取り下げられている。
　
（２）原審の経緯
　本願は上記の通り、
平成２１年９月１日に出願されたものであって、
該出願と同日付けで審査請求がなされるとともに、上申書が提出され、
平成２２年３月８日付けで拒絶理由通知（同年同月１６日発送。）がなされ、
同年５月１７日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、
同年１０月２６日付けで拒絶査定（同年１１月９日発送。以下「原審拒絶査定」と記す。）がなされたものである。
　
（３）当審での経緯
　本件審判請求は、
　平成２３年２月８日付けで上記原審拒絶査定を不服としてなされたもので、これと同時に手続補正書が提出され、
同年３月９日付けで特許法第１６４条第３項に定める報告（前置報告）がなされ、
同年同月２８日付けで当該報告に対する意見を求める旨の審尋（同年同月２９日発送)がなされ、これに対して、
同年５月３０日付けで回答書が提出され、
同年９月７日付けで上記平成２３年２月８日付けの手続補正書による補正の却下の決定（同年同月２０日発送)がなされるとともに、
同日付けで拒絶理由通知（同年同月１３日発送）（以下、「当審拒絶理由通知」と記す。）がなされ、
同年１１月１４日付けで意見書（以下、「当審意見書」と記す。）が提出されるとともに、同日付けで手続補正書（以下、「当審補正書」と記す。）が提出されている。
　
　
２．拒絶理由・補正の内容・請求人の主張
　
（１）当審拒絶理由通知
　上記当審拒絶理由通知で通知された理由（以下「当審拒絶理由」と記す。）は以下の通りである。
『　　　　　　　　　　　　　　　　理　由 
　
 １．本願の発明の詳細な説明及び特許請求の範囲の記載は下記の点で、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　 記
（１）本願請求項１に「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項の記載があるが、発明の詳細な説明においては該発明特定事項を裏付ける（サポートする）記載がない。
（発明の詳細な説明の段落【００１５】には請求項１と同一の記載があり、表現上の整合性は足りているものの、この記載をもって実質的な対応関係（請求項に係る発明が、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであるか否か）を認めることは到底できない。
　そして、該段落【００１５】以外の箇所には該発明特定事項を示唆する記載が見当たらない。特に、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けが不可能である。
　なお、この点について、平成２１年９月１日付け上申書で「本願の請求項１〜５にそれぞれ相当する」旨説明されている特願平９−１４９４９６号（以下「祖父出願」と記す。）の審判請求書の説明を参酌するに、該発明特定事項に関連して本願の明細書の段落【００５９】〜【００６０】及び【図１５】に対応する記載（該祖父出願の明細書の段落【００６２】〜【００６３】【図１５】）に基づく説明がなされているが、そこに記載の何が「ツール」や「示す手段」や「診断ユニット」に対応するのかの説明はなく、該審判請求書の記載を参酌してもこれを推測することすらできない。
　また、本願の明細書の段落【０１２０】及び【図４２】にもこれに関連すると思われる記載があるが、やはり該発明特定事項を開示するものではない。）
　したがって、本願請求項１〜５に係る発明は本願発明の詳細な説明に記載されたものではない。
　また、このため、本願請求項１〜５に係る発明に属する具体的事物の範囲を明確に把握することは、発明の詳細な説明を参酌しても不可能であり、本願請求項１〜５に係る発明は明確でない。
　さらに、このため、本願発明の詳細な詳細な説明は、本願請求項１〜５に係る発明を説明しているものとは言えず、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項１〜５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものでもある。
　
（２）本願請求項１の「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の関係（前者は後者の一部なのか？全く別の手段なのか？）が明確でない。（両者の間に改行がないが、これはどちらを意味するのか？）
　また、発明の詳細な説明には「判定する」ことに対応する記載は認められるものの、上記（１）記載の如く、発明の詳細な説明に記載の何が「示す手段」や「診断ユニット」に対応するのかが不明であるため、該「判定する手段」も発明の詳細な説明に記載のどの事項に対応するのかも不明であり、このため、発明の詳細な説明を参酌しても、上記「判定する手段」と「診断ユニット」との関係は不明である
　したがって、本願請求項１〜５に係る発明は明確でなく、また、本願発明の詳細な説明に記載されたものではない。
　さらに、このため、本願発明の詳細な詳細な説明は、本願請求項１〜５に係る発明を説明しているものとは言えず、当業者が本願請求項１〜５に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項１〜５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものでもある。
　
　
２．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　 記　　　（引用文献等については引用文献等一覧参照）
・請　求　項　１〜５
・引用文献等　１〜２０
・備　　　考
（１）請求項１について
ア．引用文献１には下記の記載がある。
記載１：「【請求項１】　サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備えることを特徴とする医用装置の遠隔診断システム。」
記載２：「【００１６】この対応内容の転送を受けたスキャナ１０ａ（〜１０ｎ）側のコンピュータは、ステップ３４で、そのモニタに対応内容（例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」）を表示し、スキャナ１０ａ（〜１０ｎ）は待機状態に入る。」
　
イ．引用文献１記載のものと本願請求項１に係る発明とを比較すると、後者は下記相違点を有する点で前者と相違し、その余の点では両者は格別相違しない。
　
相違点１：診断対象が「複数のデバイス」であり、そのために「複数の分散形試験ユニット」「マスタ分散形試験ユニット」「ネットワーク」等を有する点。（これに対し、引用文献１記載のものにおける各「サイト」の「医用装置」が「複数のデバイス」である旨の明示は無く、そのため「複数の分散形試験ユニット」「マスタ分散形試験ユニット」「ネットワーク」等を有する構成は記載されていない。）
　
相違点２：「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」を備える点
（これに対し、引用文献１記載のものは、かかるデータベースを有していない。）
　
相違点３：「トラブルシューティングを行うのに必要なツール」「を示す手段」を有する点（これに対し、引用文献１には、「ツール」「を示す」旨の明示はない。）
　
ウ．以下、上記相違点について検討する。
（相違点１について）医療装置を複数のデバイスで構成し各デバイスごとに制御監視を行う処理手段を設けてこれらを通信手段で接続することは、例えば引用文献２〜４記載の如く、古くから周知慣用の構成であり、係る構成のものを引用文献１記載のものにおける「医用装置」として採用すること、あるいは、引用文献１記載のシステムを引用文献２〜４記載の如き医療機器の監視制御に採用することは、当業者であれば当然の如く想到する構成である。そして、複数の処理手段を接続する際に、該処理手段の一つをマスターとして動作させる構成も、当業者にとっては周知の一常套手段に過ぎない構成である（必要があれば引用文献２〜４の他にも引用文献５〜９等も参照されたし。）。
　してみると、引用文献１記載のものを上記相違点１に係る構成を有するものとすることは、当業者が容易に想到し得ることである。
　
（相違点２について）知識データベースを用いて診断等を行う技術（所謂エキスパートシステム）は、本願出願時には当業者に周知の技術思想に過ぎないものである（必要が有れば引用文献９〜１２等を参照されたし。）から、引用文献１記載のものに係るシステムの採用を試みること、即ち、上記相違点２にかかる構成を採用することも、当業者が普通に想起し得た構成に過ぎない。
　
（相違点３について）問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも当然の如く採用される周知慣用の設計事項でありる（必要があれば引用文献１３〜１５等を参照されたし。）。
　本願請求項１における「ツール」やこれを「示す」ことの技術的な意味は、上記理由１．（１）で述べたように必ずしも明確なものではないが、該周知慣用の設計事項を採用した構成を包含するものと解釈することもできる。
　したがって、引用文献１記載のものに上記相違点３にかかる構成を採用することも、当業者が必要に応じて適宜採用する設計事項にすぎない。
　
エ．してみると、本願請求項１に係る発明の構成は引用文献１〜１５に記載された発明に基づいて、当業者が容易に想到し得たものである。
　また、本願請求項１に係る発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願請求項１に係る発明は、引用文献１〜１５に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
オ．本願請求項１に係る発明と引用文献１６〜２０に記載のものとを比較すると前者においては、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有す診断ユニット」を備える点で後者と相違する。
　しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術であるから（必要があれば引用文献９〜１５等参照）、引用文献１６〜２０に記載のものに該周知慣用技術を付加して本願請求項１に係る発明をなすことも、当業者が容易になし得たことである。
　したがって、本願請求項１に係る発明は、引用文献９〜２０に記載された発明に基づいても、当業者が容易に発明をすることができたものである。
　
（２）請求項２〜５について
　請求項２〜５において限定される事項も、上記引用文献１等に記載される事項、あるいは、証拠を挙げるまでもない周知慣用技術であり、請求項２〜５に係る発明にも進歩性を認めることはできない。
　
　
＜引用文献等一覧＞
　引用文献１：特開平０６−０６２１３０号公報（当審の審尋で引用）
　
　引用文献２：特開平０７−３０３６５２号公報（原審拒絶理由で引用）
　引用文献３：特開平０１−２３８８３１号公報
　引用文献４：特開平０２−１８９１３４号公報
　引用文献５：特開平０６−２０８４８５号公報（原審拒絶理由で引用）
　引用文献６：特開平０５−０７３４５０号公報
　引用文献７：特開平０３−０７２７４２号公報
　引用文献８：特開平０５−０３５３２９号公報
　引用文献９：特開平０７−２５３９５６号公報（原審拒絶理由で引用）
　引用文献１０：特開平０５−３２４６７３号公報（同上）
　引用文献１１：特開平０６−１４９６２３号公報（同上）
　引用文献１２：特開平０２−２４７５７６号公報
　引用文献１３：特開平０７−０３０９７７号公報（原審拒絶査定で引用）
　引用文献１４：特開平０７−０３６７２９号公報（同上）
　引用文献１５：特開平０７−３０５３０５号公報（同上）
　
　引用文献１６：特開平０９−１６８５３３号公報
　引用文献１７：特開平０９−１６８５３２号公報
　引用文献１８：特開平１０−０８３３１５号公報
　引用文献１９：特開２００７−０２６４５０号公報
　引用文献２０：米国特許第６４８７５１３号明細書
　
　
＜出願日の遡及、優先権について＞
　上記理由１．（１）で発明の詳細な説明に記載されていない旨指摘した事項は、本願の原出願である特願２００６−１９６２１１号の願書に最初に添付した明細書、特許請求の範囲又は図面にも、その原出願である特願平０９−１４９４９６号の願書に最初に添付した明細書又は図面にも記載されておらず、また、これらの記載からみて自明な事項でもないので、本願は、原出願の一部を一又は二以上の新たな特許出願とするものと認め得るものではなく、出願日の遡及を認めることのできないものである。
　したがって、本願の出願日は平成２１年９月１日となる。
　
　また、このため、本願請求項１〜５に係る発明については、特願平０８−１８２６０１号、特願平０８−１８２６０２号（以下「国内優先権基礎出願」と記す。）に基づく国内優先権の主張の効果を認めることはできない。
　
　なお、該国内優先権基礎出願は、アメリカ合衆国への第一国出願を基礎としたパリ条約に基づく優先権の主張を伴ったものであるところ、仮に本願が適法な分割で上記国内優先権基礎出願に基づく国内優先権の主張の効果を認め得るものであると仮定しても、該第一国出願の明細書等に記載されている部分については国内優先権の主張の効果を認めることができない。（審査基準第ＩＶ部第２章４．３「優先権主張の基礎とされた出願が優先権主張を伴う場合の取扱い」参照）』
　
（２）当審補正書
　上記当審補正書は特許請求の範囲を以下の通りに補正するとともに、発明の詳細な説明の段落【００１５】を該特許請求の範囲の記載に合わせて補正するものである。
　
「【請求項１】
複数のデバイスと通信を行う
医用モダリティの
　前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
　マスタ分散形試験ユニットと、
　前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
　前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
　前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
　前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
　前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
　前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
　前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、
判定する手段と、前記
示す手段とを
を
備えた
　　【請求項２】
前記複数の分散形試験ユニット、前記マスタ分散形試験ユニット、前記ネットワーク、および前記システムモニタユニットを備えたシステムが複数の医用モダリティに個別に接続されている請求項１に記載の診断ネットワークシステム。
　　【請求項３】
前記複数の医用モダリティは、血管Ｘ線イメージングシステム、Ｘ線ＣＴスキャナ、および磁気共鳴イメージングシステムの内の少なくとも１種類の医用モダリティを含む請求項２に記載の診断ネットワークシステム。
　　【請求項４】
前記複数の分散形試験ユニットは、前記複数のデバイスそれぞれの所望の試験位置に取り付けられ、且つ、その試験位置における当該デバイスの動作データを前記動作状態に関する情報として連続的に収集する構成を有する請求項１に記載の診断ネットワークシステム。
　　【請求項５】
前記複数のデバイスは、同一の医用モダリティを構成する複数のデバイスである請求項４に記載の診断ネットワークシステム。」
　
（３）当審意見書
　上記当審意見書の意見の内容は以下の通りである。
『【意見の内容】
（１）拒絶理由通知の内容
　本審判事件に関する出願は、（平成２３年２月８日付け手続補正は、却下された、したがって、本拒絶理由通知書は平成２２年５月１７日付けで手続補正された明細書に対するものである、とした上で、）次の２つの理由によって拒絶をすべきものである。
　理由１）本願の発明の詳細な説明および特許請求の範囲の記載は、特許法第３６条第４項第１号および第６項第１号，第２号に規定する要件を満たしていない。
　理由２）本願の請求項１〜５に係る発明は、下記の刊行物（引用文献）に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない、というものである。
　＜引用文献等一覧＞
　引用文献１：特開平０６−０６２１３０号公報（当審の審尋で引用）
　引用文献２：特開平０７−３０３６５２号公報（原審拒絶理由で引用）
　引用文献３：特開平０１−２３８８３１号公報
　引用文献４：特開平０２−１８９１３４号公報
　引用文献５：特開平０６−２０８４８５号公報（原審拒絶理由で引用）
　引用文献６：特開平０５−０７３４５０号公報
　引用文献７：特開平０３−０７２７４２号公報
　引用文献８：特開平０５−０３５３２９号公報
　引用文献９：特開平０７−２５３９５６号公報（原審拒絶理由で引用）
　引用文献１０：特開平０５−３２４６７３号公報（同上）
　引用文献１１：特開平０６−１４９６２３号公報（同上）
　引用文献１２：特開平０２−２４７５７６号公報
　引用文献１３：特開平０７−０３０９７７号公報（原審拒絶査定で引用）
　引用文献１４：特開平０７−０３６７２９号公報（同上）
　引用文献１５：特開平０７−３０５３０５号公報（同上）
　引用文献１６：特開平０９−１６８５３３号公報
　引用文献１７：特開平０９−１６８５３２号公報
　引用文献１８：特開平１０−０８３３１５号公報
　引用文献１９：特開２００７−０２６４５０号公報
　引用文献２０：米国特許第６４８７５１３号明細書
　
（２）本願発明の内容
　合議体審判官殿の認定に対し、本審判請求人は、明細書および特許請求の範囲の記載を補正しました。
　すなわち、本願発明は、補正した特許請求の範囲の請求項１〜５に記載したように次の構成にある。
『［請求項１］
複数のデバイスと通信を行う
医用モダリティの
　前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
　マスタ分散形試験ユニットと、
　前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
　前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
　前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
　前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
　前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
　前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
　前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、
判定する手段と、前記
示す手段とを
を
備えた
［請求項２］
前記複数の分散形試験ユニット、前記マスタ分散形試験ユニット、前記ネットワーク、および前記システムモニタユニットを備えたシステムが複数の医用モダリティに個別に接続されている請求項１記載の診断ネットワークシステム。
［請求項３］
前記複数の医用モダリティは、血管Ｘ線イメージングシステム、Ｘ線ＣＴスキャナ、および磁気共鳴イメージングシステムの内の少なくとも１種類の医用モダリティを含む請求項２記載の診断ネットワークシステム。
［請求項４］
前記複数の分散形試験ユニットは、前記複数のデバイスそれぞれの所望の試験位置に取り付けられ、且つ、その試験位置における当該デバイスの動作データを前記動作状態に関する情報として連続的に収集する構成を有する請求項１に記載の診断ネットワークシステム。
［請求項５］
前記複数のデバイスは、同一の医用モダリティを構成する複数のデバイスである請求項４に記載の診断ネットワークシステム。』
　
（３）補正の内容
（３−１）補正後の請求項と補正前の請求項との関係
　補正後の請求項と補正前の請求項との関係は次の通りである。
　　　
補正後の請求項
補正前の請求項
　　　　　　１　　　　　　　　１＋α
　　　　　　２　　　　　　　　　２
　　　　　　３　　　　　　　　　３
　　　　　　４　　　　　　　　　４
　　　　　　５　　　　　　　　　５
　
（３−２）補正の根拠の明示
　（３−２−１）特許請求の範囲に関して
　請求項１のアンダーライン部の記載は、出願時の明細書の段落［０００１］，［０１２８］，［０１３０］等の記載に基づくものである。
　（３−２−２）明細書に関して
　段落［００１５］の変更は、請求項１の補正と整合性をとるための補正である。
　
（４）審判請求人の主張
（４−１）本願発明の説明
　本願発明は、特許請求の範囲の請求項１〜５に係る診断ネットワークシステムに係り、特に補正した請求項１に記載した診断ネットワークシステムに関するものである。
　請求項１に係る発明は、分節して説明すると、
『［Ａ］複数のデバイスと通信を行う
医用モダリティの
　［Ｂ］（１）前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
　　（２）マスタ分散形試験ユニットと、
　　（３）前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
　　（４）前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
　　（５）前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
　［Ｃ］前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
　（１）前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
　（２）前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
　（３）前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、
判定する手段と前記
示す手段とを
備えた
　請求項１の診断ネットワークシステムによれば、請求項１の［Ａ］医用モダリティの診断ネットワークシステムを対象とするものであり、請求項１の［Ｂ］（４）および［Ｃ］の構成を備え、システムモニタユニットの診断ユニットが、点検修理が必要なデバイス（モジュール）について
トラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段を有する
　
（４−２）理由１）の本願の発明の詳細な説明および特許請求の範囲の記載不備について
　（４−２−１）
　（Ａ）合議体審判官殿は、拒絶理由通知の理由１．の「記」欄（１）において
　『（１）本願請求項１に「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項の記載があるが、発明の詳細な説明においては該発明特定事項を裏付ける（サポートする）記載がない。
（発明の詳細な説明の段落［００１５］には請求項１と同一の記載があり、表現上の整合性は足りているものの、この記載をもって実質的な対応関係……）を認めることは到底できない。
　そして、該段落［００１５］以外の箇所には該発明特定事項を示唆する記載が見当たらない。特に、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けが不可能である。』と認定された。
　
　（Ｂ）合議体審判官殿が指摘した発明特定事項である「トラベルシューテングを行なうのに必要なツール及び点検修理の処理手順を示す診断ユニット」をサポートする記載は本願明細書の段落［０１０８］〜［０１１０］，［０１１８］〜［０１２０］および同段落［００５６］〜［００６２］ならびに［図２］，［図３８］〜［図４１］，［図４２］に記載されている。
　前記『診断ユニット』に関して、［図２］に示す実施例では、システム・モニタ・ボックス１６およびマスタＤＴＵ（分散形試験ユニット）１６を備える構成であり、システム・モニタ・ボックス１６は、段落［００５２］では、「システム・モニタ・ボックス１６（図１，２および１４に示す）は、マスタＤＴＵ３４を通して他の全てのＤＴＵ１２を制御するもので、……各ＤＴＵ１２が提供したデータを解析して血管イメージングシステム１４に発生した変化を判定することができる。……」旨が記載されている。
　また、『トラブルシューテングを行なうのに必要なツール』に関しては、明細書の段落［０１０９］，［０１１０］および［０１１１］に記載されている。すなわち、明細書のうち、
『［０１０９］
　フィールド・サービス・エンジニアはフィールド・サービス・ノートブック１８をシステムモニタボックス１６に直ちに接続することができ、
スマートブックのソフトウェアを使い
システムモニタボックス１６上のエキスパート・システム１１５を稼働させる。
　［０１１０］
　スマートブックのツールを立ち上げるため、フィールド・サービス・エンジニアはカスタマイズされたハードウエア・キー１００を自分のノートブックのパラレルポート１０６に差し込む（ステップ１４２）。このハードウエア・キー１００により診断ネットワークシステム１０へのユーザアクセスが許可され、その中に満了時間が組み込まれる。このキーが期限切れになっていない場合、スマートブックは、ユーザ名およびパスワードのプロンプトを表示したログイン画面（図示せず）を立ち上げる。
　［０１１１］
　接続され、そして安全なアクセスが確認されると、フィールド・サービス・エンジニアはシステムモニタボックス１６に載せている本発明の診断ネットワークシステム１０に診断開始を知らせる（ステップ１４４）。図３６は、フィールド・サービス・エンジニアに最初に提供される典型的な画面イメージを図示するもので、グラフィカル・ユーザ・インタフェース・メイン・メニュ２２およびステータス・バー１３４を含んでいる。このメインメニュ２２はメニューバー上にいくつかのメニューオプションを提示するもので、このオプションには機器構成（configure）１２６、システム診断（System Diagnostics）１２８、ビュー（View）１３０、およびユーティリティ（Utilities）１２６が含まれる。』
と記載されている。
　そして、さらに、明細書の段落［０１１８］では、「
メインメニュー（図４１に示す）上の“Systems Diagnostics”のオプション１２８を選択することで
血管イメージングシステム１４に関連する、最も共通するトラブルシューティングのツールが提供される
　さらに、『点検修理の処理手順を示す手段』に関しては、明細書の段落［００５９］〜［００６２］に記載されている。
　明細書の段落［００５９］には、「このシステムモニタボックス１６は多数の診断処理手順を実行するので、システムの修理に伴う当て推量を減らすことができる。図１５の例によって示す如く、フィールドサービスエンジニアは「解像度処理手順（Resolution Procedure）」により解析処理の中を案内され、画像の解像度が修正される。この結果、Ｘ線から細い大動脈の如くのビデオ像が画面上に表示され医師の観察に供せられる。医師にとっては殆ど又は全く価値の無いほど画質が劣化していることがある。そのような場合、画質の劣化はイメージ管（これを取り換えるにはおよそ４０，０００ＵＳ＄も掛かる）のまずさに因って生じているか、またはＸ線管（この取り換えはかなり安い）のまずさに因るかであろう。」と記載され、同段落［００６２］には、「前記エキスパート・システム（expert system）が実行する他の処理手順としては半値テスト（これは例えばＸ線ビームのハードネス（hardness）を決める）、クイック・チューブ・キャリブレーション・チェック（Quick Tube Calibration Check）、チェック・マックス・エントランス・エクスポージャ・レート（Check Max Exposure Rate）、およびフルオロ・ドーズ・データ（Flouro DoseData）の手続きなどがあり、それぞれ図２０、２１、２２、２３、２４、２５、および２６に示されている。」と記載されている。
　
　（Ｃ）「トラブルシューティングを行なうのに必要なツール」および「点検処理の処理手順を示す手段」ならびに「診断ユニット」は、（４−２−１）の（Ｂ）項に示したように、本願明細書および図面に記載されている。
　したがって、合議体審判官殿が指摘した発明特定事項である「トラブルシューティングを行なうのに必要なツール及び点検処理の処理手順を有する診断ユニット」の記載内容は、本願の出願当初の明細書および図面に記載されたものであると思料する。
　
　（４−２−２）
　（Ａ）合議体審判官殿は、拒絶理由通知の理由１．の「記」欄（２）において、『（２）本願請求項１の「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の関係（前者は後者の一部なのか？全く別の手段なのか？）が明確でない。（両者の間に改行がないが、これはどちらを意味するのか？）
　また、発明の詳細な説明には「判定する」ことに対応する記載は認められるものの、上記（１）記載の如く、発明の詳細な説明に記載の何が「示す手段」や「診断ユニット」に対応するのかが不明であるため、該「判定する手段」も発明の詳細な説明に記載のどの事項に対応するのかも不明であり、このため、発明の詳細な説明を参酌しても、上記「判定する手段」と「診断ユニット」との関係は不明である
　したがって、本願請求項１〜５に係る発明は明確でなく、また、本願発明の詳細な説明に記載されたものではない。』と認定された。
　
　（Ｂ）本審判請求人は、同日付手続補正書の特許請求の範囲の請求項１に記載したように、合議体審判官殿が指摘した両者の関係を明瞭にしました。
　すなわち、補正後の請求項１では、［Ｃ］（３）の構成で示したように、『前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、
判定する手段と、前記
示す手段とを
備えた
　請求項１の［Ｃ］（３）は、「診断ユニット」が「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段と」を有する関係に補正し、両者の関係を明瞭にしました。
　
　（Ｃ）請求項１の同日付提出の手続補正書で補正し、請求項１の［Ｃ］（３）の構成を明瞭にしましたので、合議体審判官殿が指摘した拒絶理由は解消したものと思料する。
　
（４−３）特許法第２９条第２項に関して
　合議体審判官殿は、本願の請求項１〜５に係る発明は、前述した引用文献１〜２０に記載した発明から当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない、と認定された。
　これに対し、本審判請求人は、本願請求項１〜５に係る発明を同日付提出の手続補正書で補正しました。
　すなわち、本願発明は、同日付提出の手続補正書で補正した請求項１〜５に係る発明、特に請求項１に記載の診断ネットワークシステムである。
　請求項１の診断ネットワークシステムは、分節して説明すると、（４）本審判請求人の主張の（４−１）項に示す通りである。
　
　（４−３−１）引用文献記載の発明ならびにこれらの発明と本願発明との比較検討について
　合議体審判官殿は、引用文献１〜２０に記載の発明から本願請求項１〜５に係る発明は、容易に発明をすることができたものである、と認定された。
　引用文献１には、合議体審判官殿が拒絶理由通知の理由２．の「記」欄（１）、ア（３頁）で指摘するように、「記載１」および「記載２」の内容が記載されている。
　しかし、引用文献１に記載された発明は、異常診断手段の診断結果に基づいて異常発生が判断されたとき、自動コール手段で管理装置に自動的に回線を繋ぎ、自己診断手段の診断結果および上記異常診断手段の判断結果の情報をセンタに情報転送手段で伝送し、上記センタに備えられた管理装置で医用装置の異常を修復する指示を修復指令手段で行なう医用装置の遠隔診断システムである。この遠隔診断システムは、前記情報転送手段で送られる異常判断手段の判断結果の情報に基づき、
医用装置の異常を修復させる指示を与える
　すなわち、引用文献１には、図２のステップ２１が自己診断手段を形成し、ステップ２２が異常判断手段を形成し、さらに、ステップ３１，３２が修復処理手段を形成し、
ステップ３２で例えば部品の交換、修復の対抗処理を指示すること
　しかし、この引用文献１には、本願発明の請求項１の［Ｃ］（３）の構成が開示されていない。すなわち、引用文献１には、
点検修理が必要なデバイスについてトラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段の双方を有する診断ユニット
　また、引用文献２〜４には、医療装置を複数のデバイスで構成し、各デバイス毎に制御監視を行なう処理手段を設けてこれらを通信手段で接続することが記載されている。
　さらに、引用文献２〜９には、複数の処理手段を接続する際に、処理手段の１つをマスタとして動作させる構成が記載されており、引用文献９〜１２には、知識データベースを用いて診断を行なう技術が記載されている。
　しかし、これらの引用文献２〜１２は本願発明の請求項１の［Ｃ］（３）の構成を示したり、示唆する記載はない。すなわち、引用文献２〜１２には、［Ｃ］（３）の構成の後段部分である「
診断ユニットが複数のデバイスの内、点検修理が必要なデバイスについてトラブルシューティング行なうのに必要なツール及び点検修理の処理手順を示す手段の双方を有すること
　また、合議体審判官殿は、「知識データベースを用いて診断を行なう技術（いわゆるエキスパートシステム）は、本願出願時には当業者に周知の技術思想に過ぎない（必要があれば引用文献９〜１２等参照）とし、さらに、問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも当然の如く採用される周知慣用の設計事項であり得る（必要があれば、引用文献１３〜１５等参照）」と判断している。
　しかし、これらの引用文献１〜１５には、「
診断ユニットが複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行なうのに必要なツール及び点検修理の処理手順を示す手段を有する
　これに対し、本願請求項１に係る発明は、請求項１の［Ｃ］（３）の構成の後段部分に記載したように、「
点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段
　この判断ユニットが、「
トラブルシューティングを行なうのに必要なツールだけでなく、点検修理の処理手順の双方を示す手段」を双方を有すること
　したがって、本願請求項１に係る発明は、引用文献１〜１５に記載の発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。
　
　（４−３−２）本願発明と引用文献１６〜２０に記載の発明について
　合議体審判官殿は、拒絶理由通知の理由２．オの項（５頁）において、『本願請求項１に係る発明と引用文献１６〜２０に記載のものとを比較すると前者においては、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」を備える点で後者と相違する。
　しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術であるから（必要があれば引用文献９〜１５等参照）、引用文献１６〜２０に記載のものに該周知慣用技術を付加して本願請求項１に係る発明をなすことも、当業者が容易になし得たことである。
　したがって、本願請求項１に係る発明は、引用文献９〜２０に記載された発明に基づいても、当業者が容易に発明をすることができたものである。』と認定している。
　しかし、本願請求項１に係る発明が「前記ユーザインタフェースの通信に応じて前記複数のデバイスの内の……必要なツール及び点検修理の処理手順を有する診断ユニット」すなわち、［Ｃ］（３）の構成の後段部分を備えるものであるが、この構成は、引用文献１６〜２０にも記載されており、本願請求項１に係る発明と引用文献１６〜２０に記載された発明との間に技術的な相違点は存在しない。本願の請求項１〜５に係る発明は、引用文献１６〜２０に記載されているが、引用文献１６〜２０に記載の発明は、本件出願の遡及する出願日以後に公知になったものである。
　しかも、本件出願は、特願２００６−１９６２１１の分割出願（特願２００９−２０１８４７、出願日：平成２１年９月１日）であり、親出願である特願２００６−１９６２１１（特開２００７−０２６４５０号公報（特許文献１９）参照）は特願平９−１４９４９６号（出願日：平成９年６月６日）の分割出願である。親出願は、特開２００７−２６４５０号公報（引用文献１９参照）として平成１９年２月１日に出願公開され、祖父出願は特開平１０−８３３１５号公報（引用文献１８参照）として平成１０年３月３１日に出願公開されたものである。
　したがって、本件出願は、特願平９−１４９４９６号の孫出願に相当し、出願日は平成９年６月６日まで遡及するものと思料する。
　一方、本件出願の祖父出願である特願平９−１４９４９６号は、特願平０８−１８２６０１号（特開平０９−１６８５３号公報（特許文献１６）参照）、特願平０８−１８２６０２号（特開平０９−１６８５３２号公報（引用文献１７）参照）の国内優先主張を伴って出願したものである。また、特願平０９−１８２６０１号および特願平０９−１８２６０２号は、１９９５年６月７日にアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権を主張した出願（米国特許出願第０８／４８４，６６０号）で、米国特許第６４８７５１３号明細書（引用文献２０参照）として平成１４年１１月２６日に発行されたものである。特願平０９−１８２６０１号および特願平０９−１８２６０２号の出願は、引用文献１６および１７に示すように、平成９年６月３０日に出願公開されたものであり、米国特許出願第０８／４８４，６６０号は、平成１４年１１月２６日に特許明細書が発行されたものである。
　したがって、本件出願の出願日は遡及する平成９年６月６日当時、引用文献１６〜２０はいずれも公然と知られておらず、本件出願の拒絶理由の対象ではないと思料する。
　
　（４−３−３）してみると、本願請求項１に係る発明は、引用文献１〜２０に記載された発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有すると確信する。
　なお、引用文献１８および１９記載の発明は、本件出願の親出願および祖父出願であり、引用文献１６および１７は、米国出願０８／４８４，６６０号（ＵＳＰＮｏ．６，４８７，５１３号明細書（引用文献２０参照））を基礎とするパリ条約に基づく優先権主張出願の公開公報である。本件出願の出願日は、祖父出願の出願日である平成９年６月６日まで遡及するものである。遡及する出願日である平成９年６月６日当時、引用文献１６〜２０に記載の発明は公知の発明ではない。したがって、引用文献１６〜２０に記載の発明は、今回の拒絶理由の対象となる文献ではないと思料する。
　
　（４−３−４）また、本件の請求項１〜５に係る発明（以下、補正後の発明という。）は、同日付提出の手続補正書において、平成２２年５月１７日付で手続補正された請求項１〜５に係る発明（以下、補正前の発明という。）を補正したものである。
　しかも、補正前の発明に対し補正後の発明は、平成６年法律第１１６号で改正された特許法第１７条の２第４項の規定（現在の特許法第１７条の２第５項の規定に相当する。）が適用されるが、この規定に違反してなされたものではない、と思料する。
　その上に、本件の請求項１に係る発明の［Ｃ］（３）の構成の後段部分に記載の『前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット』である発明特定事項は、本願の明細書の段落［００１５］の他、［００５９］〜［００６２］，［０１０８］〜［０１１０］，［０１１８］〜［０１２０］および図面の［図１］，［図２］，［図１５］，［図４１］［図４２］に記載されている。
　また、本件出願の明細書の段落［００５９］〜［００６２］，［０１０８］〜［０１１０］，［０１１８］〜［０１２０］および図面の［図１］，［図２］，［図１５］，［図４１］，［図４２］に相当する技術事項は、次の明細書および図面の対応表で示すように、親出願である特開２００７−２６４５０号公報（引用文献１９参照）、および祖父出願である特開平１０−８３３１５号公報（引用文献１８参照）の明細書および図面にもそれぞれ記載されている。
　また、本願の明細書の段落および図面の図番と、親出願や祖父出願の明細書の段落および図面の図番の対応関係はそれぞれ次の表に示す通りであり、技術内容は三者間において同一であり、異なるところはない。
　したがって、本願の請求項１の［Ｃ］（３）の構成の後段部分に記載の前記発明特定事項は、親出願および祖父出願の明細書および図面にもそれぞれ記載されている。
　また、同日付提出の手続補正書で補正された補正後の発明は、すなわち、補正後の請求項１〜５に係る発明は、明細書の段落［００１５］に記載された内容と同一であり、さらに、補正後の請求項１の［Ｃ］（３）の構成のうち、前記発明特定事項は、本願および親出願、祖父出願の各明細書および図面に記載されている。この補正後の請求項１に記載の発明特定事項は、親出願および祖父出願の明細書および図面にも同様に記載され、開示されている。
　してみると、本願の請求項１〜５に係る発明は、親出願にも祖父出願にも開示されており、本件出願は、平成２１年９月１日に分割出願されたものであるが、その出願日は祖父出願の出願日である平成９年６月６日まで遡及するものと思料する。
　さらに、同日付提出の手続補正書で補正された補正後の発明は、平成６年法律第１１６号改正の特許法第１７条の２第４項（現在の特許法第１７条の２第５項に相当する。）の規定に違反する補正ではないと思料する。また、補正後の請求項１〜５に係る発明は、補正前の請求項１〜５に係る発明から、請求項１の［Ａ］の構成に「
医用モダリティの
　このため、補正後の請求項１〜５に係る発明は、補正前の請求項１〜５の発明から特許請求の範囲の記載を減縮したものである。
　
　（４−３−５）独立特許要件について
　本件補正後の発明の詳細な説明および特許請求の範囲の記載は明細書および図面に記載されたものである。
　中でも、本件補正後の請求項１に記載した［Ｃ］（３）の構成の後段部分における「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の発明特定事項は、明細書の段落［００１５］に記載の他、前述した、明細書の段落および図面に開示されている。前記発明特定事項は出願当時の明細書および図面に実質的に記載されていると思料する。
　また、補正後の請求項１〜５に係る発明は、引用文献１〜１５に記載の発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。
　さらに、引用文献１６〜２０は、本件出願の出願日が、前述したように平成９年６月６日まで遡及するものであるから、本件出願の拒絶理由にはなり得ないと思料する。
　してみると、本願の請求項１〜５に係る発明は、特許出願の際独立して特許を受けることができるものである、と思料する。
　
（５）むすび
　本願の請求項１〜５に係る発明は、発明の詳細な説明および特許請求の範囲に記載されたものであり、特許法第３６条第４項第１号および第６項第１号，第２号に規定する要件を満たした出願であると思料する。
　本願の請求項１〜５に係る発明は、引用文献１〜２０に記載された発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。
　つきましては、審判官殿各位の再度のご審理の上、原査定を取り消す、本願はこれを特許すべきものである、との審決を下さるようお願いする。』
　
　
第２．特許法第３６条（明細書の記載要件）について
　
１．拒絶理由、特許請求の範囲及び明細書
　特許法第３６条についての当審拒絶理由は上記第１．２．（１）の理由１．に記載の通りのものである。
　また、本願特許請求の範囲及び明細書の記載は上記当審補正書によって補正された特許請求の範囲及び明細書に記載されるとおりのものである。
　
　
２．当審判断
　そこで、当該拒絶理由が解消されたものであるか否かについて以下に検討する。
　
（１）当審拒絶理由１．（１）について
ア．本願特許請求の範囲の請求項１に記載の発明を特定するための事項（以下、「発明特定事項」と記す。）を検討するに、そこには、依然として、当審拒絶理由１．（１）で摘記された「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項に対応する「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」を備えるとの発明特定事項（以下、「当審指摘の発明特定事項」と記す。）の記載がある。
　
イ．なお、ここでの「トラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」との記載は、原審よりの出願人、請求人の主張内容等（特に、平成２１年９月１日付け上申書、平成２２年５月１７日付け意見書、平成２３年２月８日付け審判請求書及び平成２３年５月３０日付け回答書等では、本願発明が「必要なツール」と「点検修理の処理手順」の双方を「示す」ものであると説明している点。）からみて「診断ユニット」が「トラブルシューティングを行うのに必要なツール」と「点検修理の処理手順」の双方を「示す手段」を「有する」と解すべきものである。
　
ウ．しかしながら、当審指摘の発明特定事項を示す記載は、発明の詳細な説明の段落【００１５】にあるのみで、他の箇所には見当たらない。
　該段落【００１５】は、単に特許請求の範囲の請求項１の記載と同一の文が【課題を解決するための手段】として記載されているのみであり、この記載をもって請求項に係る発明が、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲にあると認めることは到底できず、特許請求の範囲の請求項１の記載と発明の詳細な説明の記載とに実質的な対応関係を認めることはできない。
　また、依然として、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けができない。
　
エ．なお、請求人はこの点に関し、上記第１．２．（３）に示した当審意見書の（４−２−１）のとおりの釈明をしているが、何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかは明示しておらず、該釈明を参酌しても、これらの対応付けが明確になるものではない。
　また、当該当審意見書の「前記『診断ユニット』に関して・・・旨が記載されている。」との釈明からは、「システム・モニタ・ボックス１６およびマスタＤＴＵ（分散形試験ユニット）１６を備える構成」が「診断ユニット」に対応付けられる旨を主張しているとも推測できるが、かかる対応付けは、平成２２年５月１７日付け意見書（特に（４−３）の「前記システムモニタユニットは、［Ｃ］（１）のコントロールユニット、（２）のデータベース、（３）の診断ユニットを有し」、「システムモニタユニットが、点検修理に必要なデバイス（モジュール）についてトラブルシューティングを行なうのに必要なツールおよび点検修理の処理手順を示す手段を備えることで」等の記載）、平成２３年２月８日付け審判請求書（特に（３−３）の「システムモニタユニットが［Ｃ］（１）〜（４）の構成を備える」、「システムモニタユニットが、［Ｃ］（４）の構成を備え」等の記載）及び平成２３年５月３０日付け回答書（特に（２−１）の「システムもニタユニットの診断ユニットが」等の記載）等での「システムモニタユニット」が「診断ユニット」を有する旨の記載と相入れない。
　また、当該当審意見書の『そして、さらに、明細書の段落［０１１８］では・・・・および２６に示されている。」と記載されている。』との釈明からは、「
スマートブックのソフトウェア
システムモニタボックス１６上のエキスパート・システム１１５
メインメニュー（図４１に示す）上の“Systems Diagnostics”のオプション１２８を選択することで
血管イメージングシステム１４に関連する、最も共通するトラブルシューティングのツール
　
オ．してみると、当審意見書の釈明を参酌しても、上記当審指摘の発明特定事項は、発明の詳細な説明に記載される事項との対応付けができないものであり、発明の詳細な説明においては該発明特定事項を裏付ける（サポートする）記載がないとした当審拒絶理由１．（１）で指摘した不備は何ら解消されていない。
　
カ．したがって、本願請求項１〜５に係る発明は、依然として、本願の発明の詳細な説明に記載されたものでないので、この出願は特許請求の範囲の記載が特許法第３６条第６項第１号に規定する要件を満たしていない。
　また、このため、本願請求項１〜５に係る発明の範囲も明確なものではないので、依然として、この出願は特許請求の範囲の記載が特許法第３６条第６項第２号に規定する要件を満たしていない。
　更にこのため、本願発明の詳細な詳細な説明は、依然として、本願請求項１〜５に係る発明を説明しているものとは言えず、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項１〜５に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第３６条第４項第１号の経済産業省令で定めるところによる記載がされていないものでもあるので、依然として、この出願は発明の詳細な説明の記載が特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　
３．中結
　以上の通り、本願は、明細書及び特許請求の範囲の記載が、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていない。
　
　
　
第３．特許法第２９条第２項（進歩性）について−その１
　
１．本願発明の認定
　本願の請求項１に係る発明（以下「本願発明」と言う。）は、上記第１．２．（２）の当審補正書の特許請求の範囲の【請求項１】として記載されたとおりのもの（以下に再掲する。）と認める。
　
＜本願発明＞
「複数のデバイスと通信を行う
医用モダリティの
　前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
　マスタ分散形試験ユニットと、
　前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
　前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
　前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
　前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
　前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
　前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
　前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、
判定する手段と、前記
示す手段とを
を
備えた
　
　
２．引用文献
　本願の出願前に頒布され、上記当審拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。（下線は当審付与。）
　
＜引用文献１＞
特開平０６−０６２１３０号公報（平成６年３月４日出願公開）
　
　＜引用文献記載事項１−１＞
「【請求項１】　サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備えることを特徴とする医用装置の遠隔診断システム。」
　
　＜引用文献記載事項１−２＞
「【００１１】次いで、上記遠隔診断システムの診断の流れを図２に基づいて説明する。
【００１２】図２のステップ２０〜３０は医用装置側、即ちＸ線ＣＴスキャナ１０ａ〜１０ｎの各々において実施される処理である。
まず、Ｘ線ＣＴスキャナ１０ａ（〜１０ｎ）のコンピュータは、ステップ２０において、通常の撮影処理を実施している。この実施中の適宜なタイミング（例えば、ある患者の撮影が完了して次ぎの患者の撮影に移る前）で、ステップ２１の自己診断の処理を実行する
スキャナ１０ａ（〜１０ｎ）のコンピュータは
その診断結果を得る。
スキャナ１０ａ（〜１０ｎ）のコンピュータは
判断する。
【００１３】ステップ２３では、ステップ２２で見つかった異常データが回復可能なエラーを示すものか否かを判断し、回復不能なエラーである（ＮＯ）と判断されたときは、続いてステップ２４〜２６の処理を行う。
ステップ２４では、異常データが有り、回復不能である旨の表示、例えば「……というエラーが発生しました。サービスセンタに連絡中です。」がスキャナ１０ａ（〜１０ｎ）のモニタに表示される。
スキャナ１０ａ（〜１０ｎ）のコンピュータが
自動的に呼び出し、両方のコンピュータ間をつなぐ。次いでステップ２６では、スキャナ１０ａ（〜１０ｎ）でそれまでに収集した異常データ、スキャナ側の履歴情報などのデータが、つながれた電話回線を介してサービスセンタＳに転送される。
【００１４】一方、上記ステップ２３の判断でＹＥＳ、即ち異常データが検知されたが、回復可能なエラーであると判断されたときは、ステップ２７に移行してエラーログに記録した後、ステップ２８に移行する。ステップ２８で、エラー発生数（頻度）が多いか否かを、予め定めたしきい値と比較するなどの処理によって判断する。この判断の結果、特定のエラー発生数（頻度）が多い（ＹＥＳ）とされたときは、前述したと同様に、ステップ２９のサービスセンタＳへの自動コール処理、及びステップ３０のサービスセンタＳへのデータ転送処理に付された後、ステップ２０の通常処理に戻り、通常処理を並行して可能にする。ステップ２８で、エラー発生数（頻度）が少なく（ＮＯ）、未だ異常状態であるとは特定できないとするときは、ステップ２０の通常処理に戻る。」
　
　＜引用文献記載事項１−３＞
「【００１６】
この対応内容の転送を受けたスキャナ１０ａ（〜１０ｎ）側のコンピュータは、ステップ３４で、そのモニタに対応内容（例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」）を表示し
【００１７】これにより、上記ステップ３２で異常状態への対応を依頼された、例えば工場ＦＴは必要な修理部品を病院Ａ（〜Ｎ）又は担当サービスステーションＳＴａ（〜ＳＴｎ）に発送するし、同様に、ステップ３２で対応を依頼された担当サービスステーションＳＴａ（〜ＳＴｎ）は病院Ａ（〜Ｎ）にサービスエンジニアを派遣したりすることになる。
【００１８】このため、Ｘ線ＣＴスキャナ１０ａ（〜１０ｎ）が故障しても、病院側のオペレータの連絡を待たずに、直ちに異常事態の修復作業に入ることができ、スキャナのダウンタイムを極力短縮させ、医療行為への支障を最小限に食い止めることができる。」
　
　＜引用文献記載事項１−４＞
「【００２１】ここで、上述した図２中のステップ２１〜２３，２７，２８を中心とする
自己診断処理及び異常判断処理の具体例
【００２２】画像再構成装置の診断例を図３に示す。Ｘ線ＣＴスキャナ１０ａ（…１０ｎ）は、まず、図３のステップ４０において磁気ディスクからテスト用生データを読出し、
ステップ４１において再構成演算装置にテスト用生データを用いた画像再構成を命じる。次いでステップ４２に移行し、予め記憶しているテスト用画像と再構成した画像とを比較し、ステップ４３において両者が一致しているか否か判断する。
異常データが在る場合はその旨のモニタ表示
を行う。
　
　＜引用文献記載事項１−５＞
「【００２３】また、Ｘ線高電圧装置の通常スキャン時の診断例を図４に示す。なお、この診断に対するハードウエア構成を図５に示す。
【００２４】最初に、図５のハードウエア構成から説明する。このＸ線高電圧装置は、Ｘ線制御部５０に接続された高圧トランス５１を有し、この高圧トランス５１の２次側に、整流回路５２、５２を介してＸ線管５３が負荷として接続されている。
整流回路５２、５２とＸ線管５３の間には、演算増幅器、比較器を各々有する管電流検出回路５４及び管電圧検出回路５５が接続され、それらの検出信号がＣＰＵ５６に供給されている。
【００２５】上記ＣＰＵ５６は、図４に示すように動作する。つまり、図４のステップ６０で通常スキャンを指令している間の適宜なタイミングで、ステップ６１のエラー発生か否かの判断を行う。この判断は、上記管電流検出回路５４及び管電圧検出回路５５から供給される、論理レベルの検出信号を読み込んで、過管電流、過管電圧、主回路の過電流、Ｘ線管オーバヒート、熱交換器のフロー異常などの項目をチェックすることで行う。この判断でＮＯ（エラー発生なし）の場合はステップ６０に戻るが、ＹＥＳ（エラー発生）の場合はステップ６２の致命的なエラーか否かを判断する。この判断でＹＥＳ（致命的なエラーである）の場合は、図２のステップ２４〜２６の処理と同様に、モニタ表示、センタ自動コール及びデータ転送を行う。しかし、ＮＯ（致命的なエラーではない）の場合はステップ６３に移行して、異常データを記録し、さらにステップ６４に移行して、エラーの発生頻度が基準値よりも大きいか否かを判断する。このステップ６４でＮＯの判断が下されたときはステップ６０に戻るが、ＹＥＳ（エラー発生頻度が大きい）の判断が下されたときはモニタ表示、センタ自動コール及びデータ転送を行う。」
　
　＜引用文献記載事項１−６＞
「【００２９】なお、上述した実施例については、種々の変形例が可能である。
【００３０】第１に、回復可能なエラーである（即ち、致命的なエラーではない）か否かの判断に応じて、自動コールの呼び出し先を変えるようにしてもよい。例えば、致命的なエラーの場合には直接、担当のサービスステーションＳＴａ（〜ＳＴｎ）に自動コールさせるようにすれば、その緊急性に応じた処置が可能になる。
【００３１】第２に、前述した自己診断プログラムは夜間に走らせるようにしてもよく、その自己診断の結果、致命的なエラーではない場合（例えば、何千回かに１回の割合で生じる、画像再構成時のエラー）、スキャナ側の自動コール処理プログラムが起動され、スキャナ側のモデムを通して、サービスセンタＳの自動呼び出しを行う。そして、スキャナ側情報、異常発生日時、異常データなどをサービスセンタＳに転送しておいて、転送後は、通常のシステムとして使用継続できるようにしてもよい。
また、これら一連の処理は、スキャナの通常使用のバックグラウンドでのソフトウエア処理としてもよい。
【００３２】第３に、図２のステップ３１の処理に係る分析結果、サービスセンタＳ側でスキャナ１０ａ（〜１０ｎ）の更に詳細な異常状態を知りたいと判断したとき、センタ側から装置側へ別の診断プログラムを走らせたり、エラーを回避するモードへの自動的な設定変更を装置側に指令することができる（図８のステップ３１ａ参照：同図中で図２と同一符号のステップは同一処理を示す）。なお、センタ側から遠隔診断の処理を指示した後、一旦回線を切り離し、医用装置側の処理が終了した時点で、自動コールし、データ転送するシステムも可能である。このとき、異常時であると判断したときのみ、自動コールするようにしてもよい。」
　
　＜引用文献記載事項１−７＞
「【００３３】
第４に、通常使用中にエラーが発生した場合、サービスセンタＳへの自動コールの要、不要の判断をオペレータにさせるようにしてもよい。
【００３４】
第５に、オペレータの判断に応じて自動コールを行う手段を設けてもよい。即ち、オペレータが気付いた異常情報を入力させ、それらの情報をオペレータの操作に基づき自動コールし、転送するようにする
　
　
＜引用文献２＞
特開平０７−３０３６５２号公報（平成７年１１月２１日出願公開）
　
　＜引用文献記載事項２−１＞
「【００２５】本実施例では、複数の装置を同時に使用する内視鏡システムであるため、手術を行う執刀医、看護婦がそれぞれに適した操作環境が得られるように、図３に示すように構成した複数の装置を集中的に操作及び制御できるようにしている。
【００２６】前記内視鏡用カメラ装置１，光源装置８，高周波焼灼装置１７，気腹装置１８は、各装置に設けられているシリアルインターフェース３３ａ，３３ｂ，３３ｃ，３３ｄ，３３ｅ，３３ｆ，３３ｇにシリアル通信回線３８ａ，３８ｂ，３８ｃ，３８ｄ，３８ｅ，３８ｆを各々１対１に接続して、システム全体の制御を行うシステムコントローラ３５によって集中制御されるようになっている。
【００２７】内視鏡システムには、各装置の状態の表示を行う表示手段として、集中表示パネル３６と集中制御パネル３７の複数の表示手段とを設けており、システムコントローラ３５に接続されている。集中表示パネル３６には液晶ディスプレイなどからなる表示部３６ａが設けられ各装置の状態が表示されるようになっている。集中制御パネル３７には液晶ディスプレイなどからなる表示部３７ａと、この表示部３７ａの上に一体的に設けたタッチセンサなどで構成されたタッチパネル３７ｂとが設けられており、各装置の状態が表示されると共に、機能操作スイッチ等が表示部３７ａに表示され、スイッチ電極が２次元的に配置されたタッチセンサの所定の領域に触れることにより機能操作スイッチが入力されて操作指示が行えるようになっている。
【００２８】また、装置毎に設けたＣＰＵ１ｃ，８ｃ，１７ｃ，１８ｃ，３５ｃ，３６ｃ，３７ｃがシリアルインターフェース３３ａ，３３ｂ，３３ｃ，３３ｄ，３３ｅ，３３ｆ，３３ｇに１対１で接続されているシリアル通信回線３８ａ，３８ｂ，３８ｃ，３８ｄ，３８ｅ，３８ｆによって、ＣＰＵの通信内容を互いに確認する通信回線確認手段を構成している。
【００２９】さらに、システムコントローラ３５には暴走状態を検出する制御機器暴走検出手段としてＷＤＴ３５ｂが設けてある。
【００３０】なお、集中表示パネル３６は、表示部のみを設けて該パネルにおいて表示のみを行うようにしても良い。システムコントローラ３５は、集中表示パネル３６，集中制御パネル３７のそれぞれにおいて目的の機器の状態を表示し、また目的の操作が行えるように、各装置の操作パネル１ａ，８ａ，１７ａ，１８ａの表示画面の制御を行える。
【００３１】また、前記集中表示パネル３６は、手術を行う執刀医が手術中に必要な情報をひとまとめで見ることができるようにするのが主目的であり、集中制御パネル３７は、手術の間、執刀医の指示に従って機器の操作や鉗子類の受け渡しを担当する看護婦などが機器の操作を行なうことが主目的となっている。」
　
　
＜引用文献３＞
特開平０１−２３８８３１号公報（平成１年９月２５日出願公開）
　
　＜引用文献記載事項３−１＞
「２．特許請求の範囲
（１）Ｘ線を被検者に放射しその透過Ｘ線像を得る透視台と、この透視台へＸ線発生用の電力を供給するＸ線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るＸ線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、少なくとも透視台及び一つの操作器または透視台及びＸ線発生装置の個別制御装置内にはマイクロプロセッサを搭載し、このマイクロプロセッサを搭載した各個別制御装置を通信回線で相互に接続したことを特徴とするＸ線透視撮影装置。
（２）各構成要素ごとに分散して配置された個別制御装置のそれぞれにマイクロプロセッサを搭載すると共に、このマイクロプロセッサを搭載したそれぞれの個別制御装置を通信回線で相互に接続した請求項１記載のＸ線透視撮影装置。
（３）それぞれの個別制御装置を相互に接続する通信回線の途中に一つまたは複数の分岐手段を設け、この分岐手段により上記通信回線を中継接続した請求項１または２記載のＸ線透視撮影装置。
（４）各構成要素ごとに分散して配置されたそれぞれの個別制御装置を通信回線でリング状に相互に接続した請求項２記載のＸ線透視撮影装置。」
　
　
＜引用文献４＞
特開平０２−１８９１３４号公報（平成２年７月２５日出願公開）
　
　＜引用文献記載事項４−１＞
「２．特許請求の範囲
（１）Ｘ線を被検者に放射しその透過Ｘ線像を得る透視台と、この透視台へＸ線発生用の電力を供給するＸ線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るＸ線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、これらの個別制御装置を通信回線で相互に接続すると共に、この通信回線には汎用コンピュータを接続したことを特徴とするＸ線透視撮影装置。
（２）Ｘ線を被検者に放射しその透過Ｘ線像を得る透視台と、この透視台へＸ線発生用の電力を供給するＸ線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るＸ線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、これらの個別制御装置を通信回線で相互に接続すると共に、この通信回線には汎用コンピュータを接続するため相互間で通信仕様を変換する変換器を接続したことを特徴とするＸ線透視撮影装置。
（３）上記変換器に汎用コンピュータを接続した請求項２記載のＸ線透視撮影装置。」
　
　
　＜引用文献５＞
特開平０６−２０８４８５号公報（平成６年７月２６日出願公開）
　
　＜引用文献記載事項５−１＞
「【請求項１】複数のデータ処理装置がネットワークを介してそれぞれ接続されているネットワークシステムにおいて、
前記複数のデータ処理装置をグループ化し、各グループ毎に、グループ内で発生した障害情報を蓄積するグループ監視装置を設けると共に、
システム全体に、前記各グループ監視装置からの障害情報を受信して出力するシステム監視装置を設けたことを特徴とする障害監視システム。」
　
　
　＜引用文献６＞
特開平０５−０７３４５０号公報（平成５年３月２６日出願公開）
　
　＜引用文献記載事項６−１＞
「【請求項１】　監視制御装置と複数の機器とが一本のケーブルによってリング状にそれぞれ接続される集中監視制御方式であって、前記複数の機器の動作状態を監視する場合、前記監視制御装置は、前記複数の機器毎の動作情報を挿入するデータ部を有する監視要求パケットを生成して前記ケーブル上に送出し；前記複数の機器は、前記監視要求パケットを受信して該当する前記データ部に動作情報を挿入した後、前記ケーブルを介して前記監視要求パケットを順次送出していくことを特徴とする集中監視制御方式。」
　
　
　＜引用文献７＞
特開平０３−０７２７４２号公報（平成３年３月２７日出願公開）
　
　＜引用文献記載事項７−１＞
「２．特許請求の範囲
１．データをフレーム単位の構成で伝送するリング状ローカルエリアネットワーク伝送路上に配置された複数のデータ伝送装置と、
　この各データ伝送装置に接続された複数のプロセッサと、
　前記リング状ローカルエリアネットワーク伝送路を監視し保守する保守監視装置と
　を備えたデータ伝送システムにおいて、
　前記保守監視装置と前記リング状ローカルエリアネットワーク伝送路上に配置された前記データ伝送装置との間に前記保守監視装置を制御するネットワークアダプタを設け、
　前記保守監視装置に、
　前記ネットワークアダプタで折返され返送されるネットワークアダプタ折返しフレームを送信するネットワークアダプタ折返しフレーム送信手段と、
　返送された前記ネットワークアダプタ折返しフレームを受信するネットワークアダプタ折返しフレーム受信手段と
　を備えたことを特徴とするデータ伝送システム。」
　
　
　＜引用文献８＞
特開平０５−０３５３２９号公報（平成５年２月１２日出願公開）
　
　＜引用文献記載事項８−１＞
「【請求項１】　配管中を流れる流体の流量や温度等を検出する発信器と２線の制御ループで接続され、配管中の各所に配置された複数の前記発信器の出力に基づいて該発信器及び制御ループの異常を診断する制御ループ系の異常監視システムにおいて、
複数の前記発信器のそれぞれに対応して２線の制御ループで接続される複数のインターフェース装置を各グループに分割し、分割された各インターフェースの中で１つのマスタインターフェース装置を定め、マスタインターフェース装置は自身に接続される発信器の出力データを入力するとともに、自身の配下のインターフェース装置に接続される発信器の出力データを入力し、これら各発信器の出力データの相関関係を演算するとともに、この演算結果と予め設定された当該の各発信器間の相関関係情報とを比較することにより前記発信器を含む制御ループ系の異常を特定するようにしたことを特徴とする制御ループ系の異常診断方法。」
　
　
　＜引用文献９＞
特開平０７−２５３９５６号公報（平成７年１０月３日出願公開）
　
　＜引用文献記載事項９−１＞
「【請求項１】　ネットワークによって互いに接続された多数の被監視計算機を集中監視装置によって監視する計算機監視方式において、
前記障害に対応した対処方法を格納する対処方法格納手段（１ａ）と、
前記障害に応じたエラーメッセージを、予め前記各被監視計算機（２ａ，２ｂ・・・）において付加された分類データとともに表示画面（１ｃ）上に表示するメッセージ表示手段（１ｂ）と、
前記エラーメッセージが表示された障害の中から対処したいものをオペレータの操作に従って選択する対処障害選択手段（１ｄ）と、
前記選択された障害の対処方法を前記対処方法格納手段（１ａ）から読み出して前記表示画面（１ｃ）上に表示する対処方法表示手段（１ｅ）と、
前記表示された対処方法に従ってオペレータの操作により障害対処を実行する障害対処実行手段（１ｆ）と、
前記障害対処実行手段（１ｆ）による対処内容の履歴を格納する対処履歴格納手段（１ｇ）と、
前記格納された対処履歴の中から表示させたいものをオペレータの操作に従って選択する対処履歴選択手段（１ｈ）と、
前記選択された対処履歴を前記表示画面（１ｃ）上に表示する対処履歴表示手段（１ｉ）と、
を有することを特徴とする計算機監視方式。」
　
　＜引用文献記載事項９−２＞
「【０００２】従来、ＬＡＮ等のネットワークによって互いに接続された多数の被監視計算機を集中監視装置によって監視する計算機監視方式としては、各計算機で生じた障害を上位の計算機が監視し、さらにそれらを最上位の集中監視装置で監視するようにした方式が知られている。」
　
　
＜引用文献１０＞
特開平０５−３２４６７３号公報（平成５年１２月７日出願公開）
　
　＜引用文献記載事項１０−１＞
「【請求項１】　故障製品を解析する製品故障解析装置において、
前記故障製品の特徴を入力する入力手段と、
前記入力手段に接続され、一組の過去の故障製品の特徴及び対応する過去の故障メカニズムを格納するデータ・ベース手段と、
前記故障製品の特徴に応答して、前記データ・ベース手段をアクセスし、前記一組の過去の故障メカニズムから少なくとも一つの過去の故障メカニズムを選択する手段と、
前記選択された過去の故障メカニズムを確認するための一組の故障解析手順を決定するエキスパート・システム手段と、
を備えていることを特徴とする製品故障解析装置。
【請求項２】　少なくとも一つの故障部品を解析するための故障解析手順を決定する製品故障解析方法において、
一組の過去の故障部品の特徴及び対応する過去の故障メカニズムをリレーショナル・データ・ベース内に格納するステップと、
前記リレーショナル・データ・ベース手段をアクセスし、前記一組の過去の故障メカニズムから少なくとも一つの過去の故障メカニズムを選択的に供給するステップと、
前記選択した過去の故障メカニズムを確認するための一組の故障解析手順を決定するステップと、
を備えたことを特徴とする製品故障解析方法。」
　
　
＜引用文献１１＞
特開平０６−１４９６２３号公報（平成６年５月３１日出願公開）
　
　＜引用文献記載事項１１−１＞
「【請求項１】　自己の運用管理状態を制御するための情報を採取する情報採取機能と、この情報採取機能の採取した情報を判別しこの判別結果に基づき前記自己の運用管理状態を制御する運用管理制御機能とを情報処理装置内に備えることを特徴とする情報処理装置の運用管理システム。
【請求項２】　情報採取機能が、情報処理装置の運用管理のための情報を既存の情報採取方法では採取できない場合に新規に情報採取方法を作成する情報作成部および前記情報の取得・伝達を行う情報制御部からなる情報採取制御部と、前記情報作成部の作成した情報採取方法を既存の情報採取方法として格納する採取条件ファイルとから構成され、運用管理制御機能が、前記情報処理装置の運用管理についての処理判別条件および処理内容を格納している処理条件ファイルと、前記情報採取制御部から前記情報を受け前記処理条件ファイルを参照して処理を判別する処理判別部およびこの処理判別部の判別結果を受け以後の処理内容を指示する処理部とからなる内部運用制御部と、この内部運用制御部の指示を受け処理を実行する処理実行部とから構成されることを特徴とする請求項１記載の情報処理装置の運用管理システム。
【請求項３】　情報処理装置は、実行処理部の処理の実行結果を情報として採取する情報採取制御部が、前記処理の実行結果から現行の採取条件ファイルおよび処理条件ファイルの格納済の情報からでは適切な情報採取方法を作成できず自己の運用管理を制御できないと判断した場合に最新の情報を出力し運用管理のための処理内容を受領するための端末と接続し、前記端末が、前記情報処理装置の送出する情報を受信する入力制御部と、前記受信した情報を解析し処理の内容を指示する解析部と、前記解析部の指示する処理の内容を前記情報処理装置に出力する出力制御部とからなる外部運用制御部を含み、前記解析部の解析動作を援助する監視方法および人間の経験則を蓄える知識ベースファイルおよび前記出力制御部の出力する前記処理の内容を表示する外部出力装置に接続していることを特徴とする請求項１記載の情報処理装置の運用管理システム。」
　
　
＜引用文献１２＞
特開平０２−２４７５７６号公報（平成２年１０月３日出願公開）
　
　＜引用文献記載事項１２−１＞
「５．データを入力する入力装置と、着脱自在の記憶媒体を有する記憶装置と、オペレータに対する指示および処理結果を表示する出力装置とを有し、
　かつ、オペレータにたいして点検すべき事項および手法を教示すると共、入力されるデータの異常有無を判定する機能と、入力されたデータに基づいて、余寿命を推定する機能とを有する、診断用端末装置。
６．点検ごとに蓄積される点検情報と、モデル部品について寿命を解析したモデル部品データと、交換部品についての試験データである交換部品データとを有するデータベースと、
　前記データベースから、点検対象についての非破壊試験データを検索し、該非破壊試験データに対する残存破壊値の相関関係を示す実験式を求め、かつ、前記データベースから、点検対象についての運転経歴データを検索し、該運転経歴データに対する残存破壊値の相関関係を示す実験式を求める手段と、
　点検時に得られたデータを、各々対応する前記実験式に入力して、各々残存破壊値を求める手段と、
　予め求められた残存破壊値と径時変化との相関関係により、余寿命を求める手段とを備えたことを特徴とする診断システム。」（特許請求の範囲第５項〜第６項）
　
　＜引用文献記載事項１２−２＞
「ホスト装置１は、高速で、大容量のデータ処理が可能なコンピュータであって、内部機能として、推論部５．データベース１１、知識ベースエディタ２４およびインタフェース２８を有する。これらは、コンピュータのハードウェアとソフトウェアによって実現されるものであることはいうまでもない。」（第５頁下右欄第９行〜第１５行）
　
　
＜引用文献１３＞
特開平０７−０３０９７７号公報（平成７年１月３１日出願公開）
　
　＜引用文献記載事項１３−１＞
「【００８２】図４は、電気系の故障診断処理を示すフローチャートである。図２のステップ１０６において「電気系の故障診断プログラム」が起動された場合、あるいは図３のステップ２０５において電気系の故障診断処理が開始された場合に、図４の処理がスタートされる。
【００８３】すなわち、表示器１７の画面と対話する形式で処理が進行するものであり、まず、初期画面においてパスワードが入力されると（ステップ３０１）、基本メニューが表示された基本メニュー画面となる（ステップ３０２）。図３のフローではステップ２０３でパスワードを入力するようにしてもよい。
【００８４】基本メニューの中から故障診断メニュー、ユーティリティのいずれかが選択される。ユーティリティが選択されるとユーティリティ画面となり（ステップ３０４）、必要に応じてパスワードを登録、変更するための画面に切り替えられる（ステップ３０５）。ステップ３０４では基準値事例集等のデータファイルメンテナンス機能を選択できるようにしてもよい。
【００８５】故障診断メニューが選択されると、故障診断メニュー画面となり、通信機能、診断事例集による診断、モニタパネル診断サポートのいずれかを選択することができる（ステップ３０３）。」
　
　
＜引用文献１４＞
特開平０７−０３６７２９号公報（平成７年２月７日出願公開）
　
　＜引用文献記載事項１４−１＞
「【請求項１】　データ伝送装置に接続される各対象電子装置の不具合に対する復旧支援を行う復旧支援装置において、
前記対象電子装置の不具合発生時、前記データ伝送装置を介して送られてくる前記対象電子装置の不具合データを受信した後、当該不具合対象電子装置に関係する基板の診断情報をデータ送信処理手段を介して要求し、この要求に基づいて送られてくる前記不具合対象電子装置に関係する基板の診断情報を受信するデータ受信処理手段と、
このデータ受信処理手段によって受信された診断情報を採集し、前記不具合対象電子装置を構成する基板の種類ごとに格納する診断情報採集手段と、
この診断情報採集手段によって採集した診断情報を解析して原因を究明し、その故障原因と処置とを前記復旧支援画面表示部に表示する診断情報解析手段と、
を備えたことを特徴とする復旧支援装置。
【請求項２】　請求項１記載の復旧支援装置において、
予め種々の故障原因と処置とに対応する復旧手順が保存されている復旧手順保存手段と、前記不具合対象電子装置から採集されたプログラムを保存するプログラム保存手段と、前記診断情報解析手段で解析された故障原因と処置とから復旧手順を判定し、前記復旧手順保存手段から該当する復旧手順を読み出して復旧支援画面表示部に表示し、また復旧手順からプログラムのローディングが必要な場合には前記プログラム保存手段から該当プログラムを読み出して前記対象電子装置にダウンロードさせる指示を行う復旧手順判定処理手段とを付加したことを特徴とする復旧支援装置。
【請求項３】　請求項１記載の復旧支援装置において、
前記不具合対象電子装置から採集されたプログラムを保存するプログラム保存手段と、常に最新のプログラムを保存するために、定期的に前記各対象電子装置に各種基板の更新用プログラムを要求するプログラム更新要求手段と、このプログラム更新要求手段による更新用プログラムの要求データを送信するデータ送信処理手段と、このデータ送信処理手段の要求データに基づいて前記各対象電子装置側からデータ伝送ラインを介して送られてくる更新プログラムを前記データ受信処理手段で受信した後、前記プログラム保存手段の該当エリアに格納するプログラム更新処理手段とを付加し、
前記復旧手順判定処理手段における復旧処理時、前記プログラム保存手段から最新のプログラムを読み出してダウンロード可能にしたことを特徴とする復旧支援装置。」
　
　＜引用文献記載事項１４−２＞
「【００２９】さらに、前記第３の復旧支援制御系では、前記ＰＣメインプロセッサ（ＭＭＰＵ１形）基板にはプログラムのローディングが必要なことを表示するもので、「プログラムローディング」にタッチし、引き続き、「ＹＥＳ」にタッチすると、該当プログラムがローディングされて、ローディング完了時に完了のコメントが表示される。そして、（１０）では表示の作業をすることにより、全ての復旧作業を完了させることができる。」
　
　
＜引用文献１５＞
特開平０７−３０５３０５号公報（平成７年１１月２１日出願公開）
　
　＜引用文献記載事項１５−１＞
「【請求項１】プラント操作盤の記憶部に操作盤における故障発生部位、故障の状況、故障発生要因を大分類、中分類、小分類に分類して故障検索項目とし、これらの故障検索項目をそれぞれ関連づけると共に階層構造として記憶させておき、操作盤に故障が発生した時には先ず操作盤の表示装置に大分類である操作盤の故障発生部位を表示させ、所定の故障発生部位を選択すると次いで中分類である故障の状況のうち関連する項目を表示させ、故障発生要因を特定可能な故障の状況を選択した時点で小分類の故障発生要因を表示装置に表示するようにしたことを特徴とするプラント操作盤の故障診断方法。」
　
　
３．引用発明の認定
　
（１）引用文献１は「医用装置の遠隔診断システム」を説明する文献であり、該「医用装置の遠隔診断システム」は、上記引用文献記載事項１−１のとおりの「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備える」ものである。
　
（２）上記引用文献記載事項１−２等からみて、「上記自己診断手段、異常判断手段、自動コール手段及び情報転送手段はコンピュータにより実現されて」いると言える。
　
（３）上記引用文献記載事項１−４、１−５には上記医用装置の「自己診断処理及び異常判断処理の具体例」として「画像再構成装置」と「Ｘ線高電圧装置」の診断例が開示されているところ、「画像再構成装置」に関しては、上記引用文献記載事項１−４から明らかなように、「構成演算装置にテスト用生データを用いた画像再構成を命じ」て得られる「画像」に基づいて診断及び判断が行われ、「Ｘ線高電圧装置」に対しては、上記引用文献記載事項１−５から明らかなように、その「管電流検出回路」や「管電圧検出回路」から上記「コンピュータ」に「供給」される「検出信号」に基づいて診断及び判断が行われる。
　したがって、「上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、Ｘ線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われるもの」であると言える。
　
（４）引用文献記載事項１−７には「通常使用中にエラーが発生した場合、サービスセンタＳへの自動コールの要、不要の判断をオペレータにさせるようにしてもよい。」、「オペレータの判断に応じて自動コールを行う手段を設けてもよい。即ち、オペレータが気付いた異常情報を入力させ、それらの情報をオペレータの操作に基づき自動コールし、転送するようにする。」との記載もあり、引用文献１からは、「上記自動コールは上記医療機器のオペレータの判断や該オペレータの操作に基づき行われるもの」である態様も読み取ることができる。
　
（５）上記引用文献記載事項１−２の『ステップ２４では、異常データが有り、回復不能である旨の表示、例えば「……というエラーが発生しました。サービスセンタに連絡中です。」がスキャナ１０ａ（〜１０ｎ）のモニタに表示される。』との記載、上記引用文献記載事項１−４の「異常データが在る場合はその旨のモニタ表示・・・を行う。」、上記引用文献記載事項１−５の「この判断でＹＥＳ（致命的なエラーである）の場合は、図２のステップ２４〜２６の処理と同様に、モニタ表示、センタ自動コール及びデータ転送を行う。」「ＹＥＳ（エラー発生頻度が大きい）の判断が下されたときはモニタ表示、センタ自動コール及びデータ転送を行う。」との記載等から、上記「コンピュータ」は「モニタ」に上記「判断結果」の「モニタ表示」をさせていると言える。
　また、引用文献記載事項１−３の『この対応内容の転送を受けたスキャナ１０ａ（〜１０ｎ）側のコンピュータは、ステップ３４で、そのモニタに対応内容（例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」）を表示し、』との記載等から明らかなように、上記「コンピュータ」は「モニタ」に上記「修復するための指示」も表示させている。
　したがって、「上記コンピュータは、さらに、モニタに上記判断結果のモニタ表示と上記修復するための指示の表示をさせる表示手段」を備えていると言える。
　
（６）さらに、引用文献記載事項１−３の『この対応内容の転送を受けたスキャナ１０ａ（〜１０ｎ）側のコンピュータは、ステップ３４で、そのモニタに対応内容（例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」）を表示し、』との記載における「担当のサービスステーションからの連絡をお待ち下さい。」との指示はオペレータへの指示であることから、「上記モニタに表示される修復するための指示には上記オペレータへの指示も含まれて」いると言える。
　
（７）引用文献記載事項１−２の「まず、Ｘ線ＣＴスキャナ１０ａ（〜１０ｎ）のコンピュータは、ステップ２０において、通常の撮影処理を実施している。この実施中の適宜なタイミング（例えば、ある患者の撮影が完了して次ぎの患者の撮影に移る前）で、ステップ２１の自己診断の処理を実行する。」との記載や、引用文献記載事項１−６の「また、これら一連の処理は、スキャナの通常使用のバックグラウンドでのソフトウエア処理としてもよい。」との記載等から、「これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである」態様も読みとれる。
　
（８）以上をまとめると、引用文献１には下記の引用発明１が記載されていると認められる。
　
＜引用発明１＞
「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備える医用装置の遠隔診断システムであって
　上記自己診断手段、異常判断手段、自動コール手段及び情報転送手段はコンピュータにより実現されており、
　上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、Ｘ線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われるものであり、
　上記自動コールは上記医療機器のオペレータの判断や該オペレータの操作に基づき行われるものであり、
　上記コンピュータは、さらに、モニタに上記判断結果のモニタ表示と上記修復するための指示の表示をさせる表示手段を備えており、
　上記モニタに表示される修復するための指示には上記オペレータへの指示も含まれており、
　これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである
遠隔診断システム。」
　
　
４．対比
　以下に、本願発明と引用発明１とを比較する。
　
（１）引用発明１は「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システム」であるから、本願発明と同様に「医用モダリティの診断ネットワークシステム」と言えるものである。
　また、引用発明１においては「上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、Ｘ線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われる」のであるから、引用発明１も「複数のデバイスと通信を行う」ものであると言える。
　したがって、引用発明１と本願発明とは「複数のデバイスと通信を行う医用モダリティの診断ネットワークシステム」である点で共通する。
　
（２）引用発明１における「コンピュータ」は「上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、Ｘ線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて」「診断及び判断」を行うのであるから、該「再構成演算装置」や「Ｘ線高圧装置」と「通信」を行って言える。そしてその通信相手である「再構成演算装置」や「Ｘ線高圧装置」は「医用装置」即（すなわ）ち「医用モダリティ」の一部に外ならず「医用モダリティ内の通信手段」と言えるものである。また、該「コンピュータ」は「モニタに上記判断結果のモニタ表示」をさせるのであるから「モニタ」に関する処理を行う「ユニット」であるとも言える。
すなわち、引用発明１における「コンピュータ」は「上記医用モダリティ内の通信手段と通信を行うシステムモニタユニット」と言えるものである。
　一方、本願発明における「システムモニタユニット」は、「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行う」ものであるところ、該「分散形試験ユニット」も「医用モダリティ内の通信手段」と言える。
　したがって、引用発明１における「コンピュータ」と、本願発明における「システムモニタユニット」とは、「上記医用モダリティ内の通信手段と通信を行うシステムモニタユニット」と言えるものである点で共通する。
　
（３）引用発明１における「オペレータの操作」のための操作手段や、「修復するための指示」等が表示される「モニタ」は、本願発明における「ユーザインタフェース」に対応付けられるものであるところ、これらが「コンピュータ」と通信を行うことは明らかである。
　また、該「モニタ」は、「判断結果のモニタ表示」も行うのであるから、「オペレータ」即（すなわ）ち「ユーザ」に、「再構成演算装置」や「Ｘ線高圧装置」即（すなわ）ち「上記医用モダリティ内の通信手段」と「通信」を行わせていると言える。
　一方、本願発明における「ユーザインタフェース」は「前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせる」ものであるところ、該「複数の分散形試験ユニット」も「上記医用モダリティ内の通信手段」と言えるものである。
　したがって、引用発明１と本願発明とは、「前記システムモニタユニットと通信を行うとともにユーザに上記医用モダリティ内の通信手段と通信を行わせるユーザインタフェース」を備えている点で共通する。
　
（４）引用発明１における「上記医用装置の再構成演算装置」は「画像再構成を命じ」られるものであるところ、これは上記「コンピュータ」によりなされることは明らかであるから、上記「コンピュータ」は上記「医用装置」すなわち「医用モダリティ」内の「被制御手段」を制御するものであることも明らかである。
　一方、本願発明における「システムモニタユニット」は「前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもの」であるところ、該「分散形試験ユニット」も「上記医用モダリティ内の被制御手段」と言えるものである。
　したがって、引用発明１と本願発明とは、「前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもの」である点でも共通する。
　
（５）
ア．引用発明１における「自己診断手段」は、本願発明における「コントロールユニット」に対応付けられ、引用発明１における「異常判断手段」「自動コール手段」「情報転送手段」「表示手段」は、本願発明における「診断ユニット」に対応付けられ、さらに、引用発明１における「異常判断手段」は、本願発明における「判定する手段」に、引用発明１における「表示手段」は、本願発明における「示す手段」に対応付けられる。
　
イ．引用発明１における「診断及び判断」は「上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、Ｘ線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われる」のであるから、「自己診断手段」がこれらの「画像」に関する情報や「検出信号」の収集とそのための制御をしていることは明らかであり、「前記動作状態に関する情報を収集するコントロールユニット」とも言える。
　
ウ．引用発明１における「異常判断手段」は、「自己診断手段の診断結果に基づいて自己の機能上の異常を判断する」ものであり、ここで「異常」と判断された場合には「異常を修復するための指示」を得るべく「自動コール」がなされるのであるから、「画像」に関する情報や「検出信号」等を「解析」して「点検修理が必要か否か」を判断しているとも言える。
　また、引用発明１においては「これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである」から、「異常判断手段」における「判断」も「常時」なされている処理であると言える。
　したがって、引用発明１における「異常判断手段」と、本願発明における「判定する手段」とは、「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」である点で共通する。
　
エ．引用発明１における「表示手段」が表示させる「修復するための指示」は「オペレータの判断や該オペレータの操作に基づき行われる」「自動コール」に対する応答であるから、「前記ユーザインタフェースとの通信に応じて」表示されるものであると言える。
　また、該「自動コール」は「異常判断手段により異常発生が判断されたときに」なされるのであるから、これに応答する「修復するための指示」は「デバイスの内の点検修理が必要なデバイスについて」のものであることも明らかである。
　さらに、該「修復するための指示」は、「オペレータへの指示も含まれて」いるものであり、このような「オペレータへの指示」も「点検修理の処理手順」と言える。
　したがって、引用発明１における「表示手段」と、本願発明における「示す手段」とは、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段」である点で共通する。
　なお、引用文献１には「担当のサービスステーションからの連絡をお待ち下さい。」との指示しか例示されておらず、点検修理の対象となる機器に対する具体的な操作を指示する例は開示されていないが、オペレータによる操作で修復可能であるならば、その操作を指示することは当然になされることであり、仮に本願発明における「点検修理の処理手順」が該点検修理の対象となる機器に対する具体的な操作を指示することを意味していると仮定しても、これが本審決の結論に影響を与えるものではない。
　
オ．よって、引用発明１と本願発明とは、
「前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもので、
　前記動作状態に関する情報を収集するコントロールユニットと、
　前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段とを有する診断ユニットと、を備えた」ものである点でも共通すると言える。
　
　
５．よって、本願発明は、下記一致点で引用発明１と一致し、下記相違点を有する点で引用発明１と相違する。
　
＜一致点＞
「複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
　　上記医用モダリティ内の通信手段と通信を行うシステムモニタユニットと、
　前記システムモニタユニットと通信を行うとともにユーザに上記医用モダリティ内の通信手段と通信を行わせるユーザインタフェースと、を備え、
　前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもので、
　前記動作状態に関する情報を収集するコントロールユニットと、
　前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段とを有する診断ユニットと、を備えたことを特徴とする診断ネットワークシステム。」
　
＜相違点１＞
　「前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと」、「マスタ分散形試験ユニットと」、「前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと」を備えており、
システムモニタユニットは「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニット」と通信を行い、かつ「前記マスタ分散形試験ユニットを通して前記分散形試験ユニット」を制御するものであり、
ユーザインタフェースはユーザに「前記複数の分散形試験ユニットのそれぞれ」と通信を行わせるものであり、
コントロールユニットは「前記複数の分散形試験ユニットから」前記動作状態に関する情報を収集するものである点。
（要約すれば、複数のデバイスとシステムモニタユニット間の情報の収集及び制御を、複数の分散形試験ユニットとマスタ分散形試験ユニットを接続したネットワークを介して行うものである点。）
（これに対して引用文献１には「分散形試験ユニット」「マスタ分散形試験ユニット」及びこれらを接続する「ネットワーク」に関する記載は無い。）
　
＜相違点２＞
　「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」を備える点
（これに対し、引用発明１はこのようなデータベースを有していない。）
　
＜相違点３＞
　点検修理の処理手順を示す手段が、点検修理が必要なデバイスについて「トラブルシューティングを行うのに必要なツール」も示すものである点。
（これに対して、引用発明１は「表示手段」や「自動コール手段」「情報転送手段」などの「トラブルシューティングを行うのに必要なツール」自体を有することは明らかであるが、これを「示」す旨の記載は、引用文献１には無い。）
　
　
６．判断
　以下に、上記相違点について検討する。
　
（１）相違点１について
　医療装置を構成する複数のデバイスごとに制御監視を行う処理手段を設けてこれらを通信手段で接続することは、例えば引用文献２〜４記載の如く、古くから周知慣用の構成であり、係る構成を引用発明１における「医用装置」に採用することは、当業者であれば当然の如く想到する構成である。そして、複数の処理手段を接続する際に、該処理手段の一つをマスターとして動作させる構成も、当業者にとっては周知の一常套手段に過ぎない構成である（必要があれば引用文献２〜４の他にも引用文献５〜９（引用文献９は特に引用文献記載事項９−２）等も参照。）。
　してみると、引用発明１の「医用装置」の構成として、「前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと」、「マスタ分散形試験ユニットと」、「前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと」を備えた構成を想起することは、当業者であれば当然の如くなし得る常識的な発想に過ぎないものである。
　また、かかる構成すなわち「デバイス」と「コンピュータ」間に「分散形試験ユニット」と「マスタ分散形試験ユニット」を接続した「ネットワーク」が介在する構成を採用した場合には、引用発明１の「コンピュータ」が「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニット」と通信を行い、「前記マスタ分散形試験ユニットを通して前記分散形試験ユニット」を制御するものとなり、引用発明１の「モニタ」等がユーザに「前記複数の分散形試験ユニットのそれぞれ」と通信を行わせるものとなり、引用発明１の「自己診断手段」が「前記複数の分散形試験ユニットから」前記動作状態に関する情報を収集するものとなることは、必然的に採用される事項に外ならない。
　したがって、引用発明１を上記相違点１に係る構成を有するものとすることは、当業者が容易に想到し得ることである。
　
（２）相違点２について
　知識データベースを用いて診断等を行う技術（所謂エキスパートシステム）は、本願出願時においては当業者に周知の技術思想に過ぎないものである（必要があれば引用文献９〜１２等を参照。）から、引用発明１に、係るエキスパートシステムの採用を試みることも、当業者が普通に想起し得た設計事項に過ぎない。そして、その場合には、知識データベースが「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」となることは必定である。
　したがって、引用発明１に上記相違点２にかかる構成を採用することも、当業者が普通に想起し得た事項に過ぎない。
　
（３）相違点３について
　問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも、当然の如く採用される周知慣用の設計事項である（必要があれば引用文献１３〜１５等を参照。）。
　そして、本願発明における「ツール」やこれを「示す」ことの技術的な意味は、上記第２．で述べたように必ずしも明確なものではないものの、該周知慣用の設計事項を採用して「ツール」を「示す」ことを包含するものと解釈することもできる。
　したがって、引用発明１に上記相違点３にかかる構成を採用することも、当業者が必要に応じて適宜採用する設計事項にすぎない。
　
（４）してみると、本願発明の構成は引用文献１〜１５に記載された発明に基づいて、当業者が容易に想到し得たものである。
　また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
　よって、本願発明は、引用文献１〜１５に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
（５）予備的判断
ア．請求人は、この拒絶理由に関連して、当審意見書の（４−３−１）において、「引用文献１には、
点検修理が必要なデバイスについてトラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段の双方を有する診断ユニット
診断ユニットが複数のデバイスの内、点検修理が必要なデバイスについてトラブルシューティング行なうのに必要なツール及び点検修理の処理手順を示す手段の双方を有すること
トラブルシューティングを行なうのに必要なツールだけでなく、点検修理の処理手順の双方を示す手段」を双方を有すること
　当該主張は、本願発明が「必要なツール」と「点検修理の処理手順」の双方を「示す」ものであるとしていた原審よりの請求人の主張内容（上記第２．２．（１）イ．参照）と矛盾する主張ではあるものの、本願の特許請求の範囲の請求項１の記載は、当審意見書の主張の解釈、すなわち、「診断ユニット」は「ツール」を「有する」ユニットであり、かつ該「診断ユニット」は「手順を示す手段」をも「有する」ユニットであると解釈することも可能ではある。
　しかしながら、引用文献１記載の「表示手段」や「自動コール手段」「情報転送手段」等は「トラブルシューティングを行うのに必要なツール」に外ならないものであるから、このような解釈をした場合であっても、上記相違点以外の相違点が生じるものではなく、この場合にも上記（４）と同様の判断結果が得られる。
　
イ．また、当審意見書の主張からは、本願発明の「点検修理の処理手順を示す」との記載は、単に点検修理の処理手順を実行する旨を表現しようと意図した記載とも推測可能である。しかしながら、引用文献１記載の「コンピュータ」が【図２】、【図３】、【図４】、【図６】等記載の処理手順を実行することは「点検修理の処理手順」を実行することに外ならないので、本願の特許請求の範囲の記載が該意図通りの記載に補正されたと仮定しても、上記相違点以外の相違点が生じるものではないので、この場合にも上記（４）と同様の判断結果が得られる。
　
ウ．なお、上記引用文献１〜１５はいずれも、本願の優先日よりも前に頒布された刊行物であるから、本願についての出願日の遡及が認められるか否かに関わらず、上記（４）の判断結果が得られる。
　
　
７．中結
　以上の通り、本願請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
　
第４．特許法第２９条第２項（進歩性）について−その２
　
１．分割・国内優先権の主張の適否について
　本願は、上記親出願の分割出願として出願されたものであるので、該分割が適法であるか否かについて検討する。
　
（１）本願の明細書等の記載内容
　本願の特許請求の範囲及び明細書は、上記当審補正書により補正された特許請求の範囲及び明細書の記載のとおりのものと認められるところ、その特許請求の範囲の請求項１には、上記当審指摘の発明特定事項（すなわち「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」）が記載されており、また、明細書の発明の詳細な説明の段落【００１５】にも該当審指摘の発明特定事項と同様の事項の記載がある。
　
（２）親出願の当初明細書等の記載内容
ア．親出願の願書に最初に添付した特許請求の範囲
　上記親出願の願書に最初に添付した特許請求の範囲の記載は次の通りのものである。
　
「【請求項１】
複数のデバイスと通信を行う診断ネットワークシステムにおいて、
　前記複数のデバイスの内の関連するデバイスと個別に通信を行う複数のプログラム可能な分散形試験ユニットと、
　前記複数の分散形試験ユニットの間で情報を伝達させるネットワークと、
　前記ネットワークを通して前記複数のプログラム可能な分散形試験ユニットと通信を行うシステムモニタユニットとを備え、
　このシステムモニタユニットは前記複数のプログラム可能な分散形試験ユニットのそれぞれを選択した方法で機能させるようにプログラムした手段と、前記複数のプログラム可能な分散形試験ユニットにより得られた情報を予めプログラムしたように前記複数のデバイスから収集する手段と、前記複数のデバイスに対して当該複数のデバイスのユーザに合わせた最適化した性能データを維持する手段とを備えた診断ネットワークシステム。
【請求項２】
前記複数の分散形試験ユニットのそれぞれは、
　前記システムモニタユニットによりプログラムされた標準化されたコントローラユニットと、
　前記プログラムされたコントローラユニットにより制御され且つ前記複数のデバイスの内の該当するデバイスと通信を行うように適合させたサンプルコントロールモジュールと、
　を備える請求項１記載の診断ネットワークシステム。
【請求項３】
前記ネットワークは、前記複数の分散形試験ユニットを互いに接続する光ネットワークを備える請求項２記載の診断ネットワークシステム。
【請求項４】
前記ネットワークは、前記複数のプログラム可能な分散形試験ユニットがループ状に直列に接続された光ネットワークを備える請求項２記載の診断ネットワークシステム。
【請求項５】
前記複数のプログラム可能な分散形試験ユニットの一つはマスタ分散形試験ユニットであり、このマスタ分散形試験ユニットを通して前記システムモニタが残りの前記複数のプログラム可能な分散形試験ユニットと通信を行う構成を有し、さらに、前記ネットワーク上で情報の伝達を行う順序は前記マスタ分散形試験ユニットから始まりかつ終わるようになっている請求項１記載の診断ネットワークシステム。
【請求項６】
前記複数のプログラム可能な分散形試験ユニットのそれぞれは、上流のプログラム可能な分散形試験ユニットから情報を受け、その受けた情報の選択部分を前記一つのプログラム可能な分散形試験ユニットで発生した情報と共に下流のプログラム可能な分散形試験ユニットにリレーする手段を含む請求項４記載の診断ネットワークシステム。
【請求項７】
前記複数のデバイスは当該各デバイスの機能を診断するための試験位置を有し、さらに前記複数のプログラム可能な分散形試験ユニットのそれぞれは前記試験位置で前記各デバイスの機能に関する情報をモニタする手段を含む請求項２記載の診断ネットワークシステム。
【請求項８】
前記複数のデバイスは当該各デバイスの機能を診断するための試験位置を有し、さらに前記複数のプログラム可能な分散形試験ユニットのそれぞれは前記試験位置における前記各デバイスの機能に関する制御量が所定値に維持されるように当該試験位置でその値を制御する手段を含む請求項２記載の診断ネットワークシステム。
【請求項９】
前記システムモニタユニットからプログラム可能な分散形試験ユニットに伝達される前記情報はデバイス制御命令を含み、さらに前記制御手段は前記デバイス制御命令にしたがって前記デバイスを制御することによって前記試験位置における前記制御量を前記デバイス制御命令による指定値に保持する手段である請求項８記載の診断ネットワークシステム。」
　
イ．親出願の当初明細、図面
　親出願の願書に最初に添付した明細書の記載内容は、その段落【００１５】の記載内容が下記の通りのものである点で、本願明細書と相違しているが、他の箇所の記載に関しては、その記載順序や用語等が若干相違するのみで、実質的な相違は認められない。
　また、図面に関しても実質的な相違は認められない。
　
「【００１５】
　本発明に係る診断ネットワークシステムは、複数のデバイスと通信を行うシステムであり、このシステムは、前記複数のデバイスの内の関連する各１つのデバイスと個別に通信を行う複数の分散形試験ユニット（ＤＴＵｓ）、マスタＤＴＵ、マスタＤＴＵおよび複数のＤＴＵの間で情報の伝達をさせるネットワーク、およびマスタＤＴＵを通して複数のＤＴＵと通信を行うシステムモニタユニットを備える。このシステムモニタユニットは、複数のＤＴＵから情報を集めるコントロールユニット、複数のＤＴＵから集められた情報から編集された情報を格納しているデータベース、および、集められた情報を解析し、複数のデバイスの内の点検修理が必要な１つ以上のデバイスの動作状態を識別する診断ユニットを有する。」
　
（３）当審判断
ア．該当審指摘の発明特定事項が上記親出願の特許請求の範囲、明細書及び図面（以下「親出願の当初明細書等」と記す。）に記載した事項の範囲内にあるものであるか否かについて検討するに、当審指摘の発明特定事項は親出願の当初明細書等の何処にも見いだすことはできない。また、親出願の当初明細書等のすべての記載を総合しても当審指摘の発明特定事項を導くことはできない。
　
イ．この点に関し、請求人は、上記当審意見書の【意見の内容】の（４−３−４）において、該発明特定事項が「本願の明細書の段落［００１５］の他、［００５９］〜［００６２］，［０１０８］〜［０１１０］，［０１１８］〜［０１２０］および図面の［図１］，［図２］，［図１５］，［図４１］［図４２］に記載されている」旨を前提とし、「本件出願の明細書の段落［００５９］〜［００６２］，［０１０８］〜［０１１０］，［０１１８］〜［０１２０］および図面の［図１］，［図２］，［図１５］，［図４１］，［図４２］に相当する技術事項」が親出願の明細書の段落［００６３］〜［００６７］，［０１１２］〜［０１１４］，［０１２２］〜［０１２４］および図面の［図１］，［図２］，［図１５］，［図４１］，［図４２］とが「同一であり、異なるところはない」ことを根拠に、当審指摘の発明特定事項が親出願の明細書および図面に記載されている旨主張している。
　しかしながら、当審指摘の発明特定事項が本願の明細書に記載されていないことは、上記第２．で述べた通りであるから、該請求人の主張の前提は妥当でない。
　しかも、親出願の当初明細書等において本願明細書と相違する部分であるところの上記親出願の願書に最初に添付した特許請求の範囲にも、同明細書の段落【００１５】にも、当審指摘の発明特定事項が記載も示唆もされていないことは明らかである。
　してみると、該請求人の主張を考慮しても当審指摘の発明特定事項が親出願の明細書および図面に記載されている旨の主張は到底認め得るものではない。
　
ウ．したがって、本願は、親出願の当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において新たな事項を導入する出願であり、親出願の出願当初の明細書又は図面に記載した事項の範囲内にない事項を含むことは明らかである。
　
（４）小結
　よって、本願は、親出願の一部を一又は二以上の新たな特許出願とするものと認め得るものではなく、出願日の遡及を認めることのできないものである。
　したがって、本願の出願日は現実の平成２１年９月１日となる。
　
　また、このため、上記国内優先権基礎出願に基づく優先権の主張を認めることもできない。
　
　
２．引用文献・引用発明
　
（１）上記１．の通りであるから、下記引用文献もその出願前に日本国内又は外国において頒布された刊行物となる。
　
＜引用文献１６＞特開平０９−１６８５３３号公報（平成９年６月３０日
出願公開。上記第１．１．（１）記載の取り下げられた国内優先権の主張にかかる出願（特願平０８−１８２６０３号）の公開公報。）
　
＜引用文献１７＞特開平０９−１６８５３２号公報（平成９年６月３０日
出願公開。上記国内優先権基礎出願（特願平０８−１８２６０２号）の公開公報。）
　
＜引用文献１８＞
特開平１０−０８３３１５号公報（平成１０年３月３１日出願公開。祖父出願（特願平０９−１４９４９６号）の公開公報。）
　
＜引用文献１９＞
特開２００７−０２６４５０号公報（平成１９年２月１日出願公開。親出願（特願平０９−１４９４９６号）の公開公報。）
　
＜引用文献２０＞
米国特許第６４８７５１３号明細書（２００２年１１月２６日発行。上記第一国出願（出願番号：０８／４８４６６０）の特許明細書。）
　
（２）上記引用文献１６〜２０のいずれの文献にも、本願請求項１記載の発明特定事項のうち、上記第２．及び上記１．で検討した当審指摘の発明特定事項以外の事項を備える診断ネットワークシステム（以下、「引用発明２」と記す）が記載されていると認められる。
　
　
３．本願発明の認定・対比・判断
　本願発明は上記上記第１．２．（２）の【請求項１】として記載及び上記第３．１．に再掲したとおりのものである。
　本願発明と引用発明２とを比較すると、前者においては、上記当審指摘の発明特定事項を備える点で後者と相違し、その余の点では両者は一致する。
　しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術である（必要があれば引用文献９〜１５等参照）から、引用発明２に該周知慣用技術を付加して本願発明をなすことも、当業者が容易になし得たことである。
　したがって、本願発明は、引用文献９〜２０に記載された発明に基づいても、当業者が容易に発明をすることができたものである。
　
　
４．中結
　以上の通り、本願請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。
　
　
　
第５．むすび
　
　上記第２．のとおり、本願は、明細書及び特許請求の範囲の記載が、特許法第３６条第４項第１号及び第６項第１号、第２号に規定する要件を満たしていないものであるから、特許を受けることができない。
　
　上記第３．、及び、第４．のとおり、本願請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、他の請求項についての検討をするまでもなく、本願は、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する