• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) A61B
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) A61B
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) A61B
管理番号 1252642
審判番号 不服2011-2843  
総通号数 148 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-04-27 
種別 拒絶査定不服の審決 
審判請求日 2011-02-08 
確定日 2012-02-23 
事件の表示 特願2009-201847「診断ネットワークシステム」拒絶査定不服審判事件〔平成22年 1月28日出願公開、特開2010- 17563〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
第1.手続の経緯

1.手続の経緯の概要

(1)出願までの経緯
1995年6月7日のアメリカ合衆国での2件の出願(出願番号:08/477297、08/484660。以下「第一国出願」と記す。)を基礎とするパリ条約に基づく優先権主張をそれぞれ伴って、
平成8年6月7日(以下「優先日」と記す。)に特願平08-182601号、及び、特願平08-182602号(以下、これらを「国内優先権基礎出願」と記す。)が出願され、
平成9年6月6日に、該国内優先権基礎出願に基づく国内優先権の主張を伴って、特願平09-149496号(以下「祖父出願」と記す。)が出願され、
平成18年7月18日に、該祖父出願を原出願とする特許法第44条第1項の規定による新たな特許出願(以下「分割出願」と記す。)として、特願2006-196211号(以下「親出願」と記す。)が出願された。
そして、本件審判請求に係る出願(以下、「本願」と記す。)は該親出願を原出願とする分割出願として、
平成21年9月1日に出願されたものである。

なお、上記、祖父出願は1995年6月7日のアメリカ合衆国での出願(出願番号:08/477083)を基礎とするパリ条約に基づく優先権主張を伴って平成8年6月7日に出願された特願平08-182603号に基づく国内優先権の主張も伴っていたが、平成9年7月25日付けで、該国内優先権の主張は取り下げられている。

(2)原審の経緯
本願は上記の通り、
平成21年9月1日に出願されたものであって、
該出願と同日付けで審査請求がなされるとともに、上申書が提出され、
平成22年3月8日付けで拒絶理由通知(同年同月16日発送。)がなされ、
同年5月17日付けで意見書が提出されるとともに、同日付けで手続補正書が提出され、
同年10月26日付けで拒絶査定(同年11月9日発送。以下「原審拒絶査定」と記す。)がなされたものである。

(3)当審での経緯
本件審判請求は、
平成23年2月8日付けで上記原審拒絶査定を不服としてなされたもので、これと同時に手続補正書が提出され、
同年3月9日付けで特許法第164条第3項に定める報告(前置報告)がなされ、
同年同月28日付けで当該報告に対する意見を求める旨の審尋(同年同月29日発送)がなされ、これに対して、
同年5月30日付けで回答書が提出され、
同年9月7日付けで上記平成23年2月8日付けの手続補正書による補正の却下の決定(同年同月20日発送)がなされるとともに、
同日付けで拒絶理由通知(同年同月13日発送)(以下、「当審拒絶理由通知」と記す。)がなされ、
同年11月14日付けで意見書(以下、「当審意見書」と記す。)が提出されるとともに、同日付けで手続補正書(以下、「当審補正書」と記す。)が提出されている。


2.拒絶理由・補正の内容・請求人の主張

(1)当審拒絶理由通知
上記当審拒絶理由通知で通知された理由(以下「当審拒絶理由」と記す。)は以下の通りである。
『 理 由

1.本願の発明の詳細な説明及び特許請求の範囲の記載は下記の点で、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていない。

(1)本願請求項1に「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項の記載があるが、発明の詳細な説明においては該発明特定事項を裏付ける(サポートする)記載がない。
(発明の詳細な説明の段落【0015】には請求項1と同一の記載があり、表現上の整合性は足りているものの、この記載をもって実質的な対応関係(請求項に係る発明が、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであるか否か)を認めることは到底できない。
そして、該段落【0015】以外の箇所には該発明特定事項を示唆する記載が見当たらない。特に、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けが不可能である。
なお、この点について、平成21年9月1日付け上申書で「本願の請求項1?5にそれぞれ相当する」旨説明されている特願平9-149496号(以下「祖父出願」と記す。)の審判請求書の説明を参酌するに、該発明特定事項に関連して本願の明細書の段落【0059】?【0060】及び【図15】に対応する記載(該祖父出願の明細書の段落【0062】?【0063】【図15】)に基づく説明がなされているが、そこに記載の何が「ツール」や「示す手段」や「診断ユニット」に対応するのかの説明はなく、該審判請求書の記載を参酌してもこれを推測することすらできない。
また、本願の明細書の段落【0120】及び【図42】にもこれに関連すると思われる記載があるが、やはり該発明特定事項を開示するものではない。)
したがって、本願請求項1?5に係る発明は本願発明の詳細な説明に記載されたものではない。
また、このため、本願請求項1?5に係る発明に属する具体的事物の範囲を明確に把握することは、発明の詳細な説明を参酌しても不可能であり、本願請求項1?5に係る発明は明確でない。
さらに、このため、本願発明の詳細な詳細な説明は、本願請求項1?5に係る発明を説明しているものとは言えず、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項1?5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものでもある。

(2)本願請求項1の「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の関係(前者は後者の一部なのか?全く別の手段なのか?)が明確でない。(両者の間に改行がないが、これはどちらを意味するのか?)
また、発明の詳細な説明には「判定する」ことに対応する記載は認められるものの、上記(1)記載の如く、発明の詳細な説明に記載の何が「示す手段」や「診断ユニット」に対応するのかが不明であるため、該「判定する手段」も発明の詳細な説明に記載のどの事項に対応するのかも不明であり、このため、発明の詳細な説明を参酌しても、上記「判定する手段」と「診断ユニット」との関係は不明である
したがって、本願請求項1?5に係る発明は明確でなく、また、本願発明の詳細な説明に記載されたものではない。
さらに、このため、本願発明の詳細な詳細な説明は、本願請求項1?5に係る発明を説明しているものとは言えず、当業者が本願請求項1?5に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項1?5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものでもある。


2.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
記 (引用文献等については引用文献等一覧参照)
・請 求 項 1?5
・引用文献等 1?20
・備 考
(1)請求項1について
ア.引用文献1には下記の記載がある。
記載1:「【請求項1】 サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備えることを特徴とする医用装置の遠隔診断システム。」
記載2:「【0016】この対応内容の転送を受けたスキャナ10a(?10n)側のコンピュータは、ステップ34で、そのモニタに対応内容(例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」)を表示し、スキャナ10a(?10n)は待機状態に入る。」

イ.引用文献1記載のものと本願請求項1に係る発明とを比較すると、後者は下記相違点を有する点で前者と相違し、その余の点では両者は格別相違しない。

相違点1:診断対象が「複数のデバイス」であり、そのために「複数の分散形試験ユニット」「マスタ分散形試験ユニット」「ネットワーク」等を有する点。(これに対し、引用文献1記載のものにおける各「サイト」の「医用装置」が「複数のデバイス」である旨の明示は無く、そのため「複数の分散形試験ユニット」「マスタ分散形試験ユニット」「ネットワーク」等を有する構成は記載されていない。)

相違点2:「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」を備える点
(これに対し、引用文献1記載のものは、かかるデータベースを有していない。)

相違点3:「トラブルシューティングを行うのに必要なツール」「を示す手段」を有する点(これに対し、引用文献1には、「ツール」「を示す」旨の明示はない。)

ウ.以下、上記相違点について検討する。
(相違点1について)医療装置を複数のデバイスで構成し各デバイスごとに制御監視を行う処理手段を設けてこれらを通信手段で接続することは、例えば引用文献2?4記載の如く、古くから周知慣用の構成であり、係る構成のものを引用文献1記載のものにおける「医用装置」として採用すること、あるいは、引用文献1記載のシステムを引用文献2?4記載の如き医療機器の監視制御に採用することは、当業者であれば当然の如く想到する構成である。そして、複数の処理手段を接続する際に、該処理手段の一つをマスターとして動作させる構成も、当業者にとっては周知の一常套手段に過ぎない構成である(必要があれば引用文献2?4の他にも引用文献5?9等も参照されたし。)。
してみると、引用文献1記載のものを上記相違点1に係る構成を有するものとすることは、当業者が容易に想到し得ることである。

(相違点2について)知識データベースを用いて診断等を行う技術(所謂エキスパートシステム)は、本願出願時には当業者に周知の技術思想に過ぎないものである(必要が有れば引用文献9?12等を参照されたし。)から、引用文献1記載のものに係るシステムの採用を試みること、即ち、上記相違点2にかかる構成を採用することも、当業者が普通に想起し得た構成に過ぎない。

(相違点3について)問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも当然の如く採用される周知慣用の設計事項でありる(必要があれば引用文献13?15等を参照されたし。)。
本願請求項1における「ツール」やこれを「示す」ことの技術的な意味は、上記理由1.(1)で述べたように必ずしも明確なものではないが、該周知慣用の設計事項を採用した構成を包含するものと解釈することもできる。
したがって、引用文献1記載のものに上記相違点3にかかる構成を採用することも、当業者が必要に応じて適宜採用する設計事項にすぎない。

エ.してみると、本願請求項1に係る発明の構成は引用文献1?15に記載された発明に基づいて、当業者が容易に想到し得たものである。
また、本願請求項1に係る発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本願請求項1に係る発明は、引用文献1?15に記載された発明に基づいて、当業者が容易に発明をすることができたものである。

オ.本願請求項1に係る発明と引用文献16?20に記載のものとを比較すると前者においては、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有す診断ユニット」を備える点で後者と相違する。
しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術であるから(必要があれば引用文献9?15等参照)、引用文献16?20に記載のものに該周知慣用技術を付加して本願請求項1に係る発明をなすことも、当業者が容易になし得たことである。
したがって、本願請求項1に係る発明は、引用文献9?20に記載された発明に基づいても、当業者が容易に発明をすることができたものである。

(2)請求項2?5について
請求項2?5において限定される事項も、上記引用文献1等に記載される事項、あるいは、証拠を挙げるまでもない周知慣用技術であり、請求項2?5に係る発明にも進歩性を認めることはできない。


<引用文献等一覧>
引用文献1:特開平06-062130号公報(当審の審尋で引用)

引用文献2:特開平07-303652号公報(原審拒絶理由で引用)
引用文献3:特開平01-238831号公報
引用文献4:特開平02-189134号公報
引用文献5:特開平06-208485号公報(原審拒絶理由で引用)
引用文献6:特開平05-073450号公報
引用文献7:特開平03-072742号公報
引用文献8:特開平05-035329号公報
引用文献9:特開平07-253956号公報(原審拒絶理由で引用)
引用文献10:特開平05-324673号公報(同上)
引用文献11:特開平06-149623号公報(同上)
引用文献12:特開平02-247576号公報
引用文献13:特開平07-030977号公報(原審拒絶査定で引用)
引用文献14:特開平07-036729号公報(同上)
引用文献15:特開平07-305305号公報(同上)

引用文献16:特開平09-168533号公報
引用文献17:特開平09-168532号公報
引用文献18:特開平10-083315号公報
引用文献19:特開2007-026450号公報
引用文献20:米国特許第6487513号明細書


<出願日の遡及、優先権について>
上記理由1.(1)で発明の詳細な説明に記載されていない旨指摘した事項は、本願の原出願である特願2006-196211号の願書に最初に添付した明細書、特許請求の範囲又は図面にも、その原出願である特願平09-149496号の願書に最初に添付した明細書又は図面にも記載されておらず、また、これらの記載からみて自明な事項でもないので、本願は、原出願の一部を一又は二以上の新たな特許出願とするものと認め得るものではなく、出願日の遡及を認めることのできないものである。
したがって、本願の出願日は平成21年9月1日となる。

また、このため、本願請求項1?5に係る発明については、特願平08-182601号、特願平08-182602号(以下「国内優先権基礎出願」と記す。)に基づく国内優先権の主張の効果を認めることはできない。

なお、該国内優先権基礎出願は、アメリカ合衆国への第一国出願を基礎としたパリ条約に基づく優先権の主張を伴ったものであるところ、仮に本願が適法な分割で上記国内優先権基礎出願に基づく国内優先権の主張の効果を認め得るものであると仮定しても、該第一国出願の明細書等に記載されている部分については国内優先権の主張の効果を認めることができない。(審査基準第IV部第2章4.3「優先権主張の基礎とされた出願が優先権主張を伴う場合の取扱い」参照)』

(2)当審補正書
上記当審補正書は特許請求の範囲を以下の通りに補正するとともに、発明の詳細な説明の段落【0015】を該特許請求の範囲の記載に合わせて補正するものである。

「【請求項1】
複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
マスタ分散形試験ユニットと、
前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニットと、
を備えたことを特徴とする診断ネットワークシステム。
【請求項2】
前記複数の分散形試験ユニット、前記マスタ分散形試験ユニット、前記ネットワーク、および前記システムモニタユニットを備えたシステムが複数の医用モダリティに個別に接続されている請求項1に記載の診断ネットワークシステム。
【請求項3】
前記複数の医用モダリティは、血管X線イメージングシステム、X線CTスキャナ、および磁気共鳴イメージングシステムの内の少なくとも1種類の医用モダリティを含む請求項2に記載の診断ネットワークシステム。
【請求項4】
前記複数の分散形試験ユニットは、前記複数のデバイスそれぞれの所望の試験位置に取り付けられ、且つ、その試験位置における当該デバイスの動作データを前記動作状態に関する情報として連続的に収集する構成を有する請求項1に記載の診断ネットワークシステム。
【請求項5】
前記複数のデバイスは、同一の医用モダリティを構成する複数のデバイスである請求項4に記載の診断ネットワークシステム。」

(3)当審意見書
上記当審意見書の意見の内容は以下の通りである。
『【意見の内容】
(1)拒絶理由通知の内容
本審判事件に関する出願は、(平成23年2月8日付け手続補正は、却下された、したがって、本拒絶理由通知書は平成22年5月17日付けで手続補正された明細書に対するものである、とした上で、)次の2つの理由によって拒絶をすべきものである。
理由1)本願の発明の詳細な説明および特許請求の範囲の記載は、特許法第36条第4項第1号および第6項第1号,第2号に規定する要件を満たしていない。
理由2)本願の請求項1?5に係る発明は、下記の刊行物(引用文献)に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない、というものである。
<引用文献等一覧>
引用文献1:特開平06-062130号公報(当審の審尋で引用)
引用文献2:特開平07-303652号公報(原審拒絶理由で引用)
引用文献3:特開平01-238831号公報
引用文献4:特開平02-189134号公報
引用文献5:特開平06-208485号公報(原審拒絶理由で引用)
引用文献6:特開平05-073450号公報
引用文献7:特開平03-072742号公報
引用文献8:特開平05-035329号公報
引用文献9:特開平07-253956号公報(原審拒絶理由で引用)
引用文献10:特開平05-324673号公報(同上)
引用文献11:特開平06-149623号公報(同上)
引用文献12:特開平02-247576号公報
引用文献13:特開平07-030977号公報(原審拒絶査定で引用)
引用文献14:特開平07-036729号公報(同上)
引用文献15:特開平07-305305号公報(同上)
引用文献16:特開平09-168533号公報
引用文献17:特開平09-168532号公報
引用文献18:特開平10-083315号公報
引用文献19:特開2007-026450号公報
引用文献20:米国特許第6487513号明細書

(2)本願発明の内容
合議体審判官殿の認定に対し、本審判請求人は、明細書および特許請求の範囲の記載を補正しました。
すなわち、本願発明は、補正した特許請求の範囲の請求項1?5に記載したように次の構成にある。
『[請求項1]
複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
マスタ分散形試験ユニットと、
前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニットと、
を備えたことを特徴とする診断ネットワークシステム。
[請求項2]
前記複数の分散形試験ユニット、前記マスタ分散形試験ユニット、前記ネットワーク、および前記システムモニタユニットを備えたシステムが複数の医用モダリティに個別に接続されている請求項1記載の診断ネットワークシステム。
[請求項3]
前記複数の医用モダリティは、血管X線イメージングシステム、X線CTスキャナ、および磁気共鳴イメージングシステムの内の少なくとも1種類の医用モダリティを含む請求項2記載の診断ネットワークシステム。
[請求項4]
前記複数の分散形試験ユニットは、前記複数のデバイスそれぞれの所望の試験位置に取り付けられ、且つ、その試験位置における当該デバイスの動作データを前記動作状態に関する情報として連続的に収集する構成を有する請求項1に記載の診断ネットワークシステム。
[請求項5]
前記複数のデバイスは、同一の医用モダリティを構成する複数のデバイスである請求項4に記載の診断ネットワークシステム。』

(3)補正の内容
(3-1)補正後の請求項と補正前の請求項との関係
補正後の請求項と補正前の請求項との関係は次の通りである。
補正後の請求項 補正前の請求項
1 1+α
2 2
3 3
4 4
5 5

(3-2)補正の根拠の明示
(3-2-1)特許請求の範囲に関して
請求項1のアンダーライン部の記載は、出願時の明細書の段落[0001],[0128],[0130]等の記載に基づくものである。
(3-2-2)明細書に関して
段落[0015]の変更は、請求項1の補正と整合性をとるための補正である。

(4)審判請求人の主張
(4-1)本願発明の説明
本願発明は、特許請求の範囲の請求項1?5に係る診断ネットワークシステムに係り、特に補正した請求項1に記載した診断ネットワークシステムに関するものである。
請求項1に係る発明は、分節して説明すると、
『[A]複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
[B](1)前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
(2)マスタ分散形試験ユニットと、
(3)前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
(4)前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
(5)前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
[C]前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
(1)前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
(2)前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
(3)前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニットと、を備えたことを特徴とする診断ネットワークシステム』である。
請求項1の診断ネットワークシステムによれば、請求項1の[A]医用モダリティの診断ネットワークシステムを対象とするものであり、請求項1の[B](4)および[C]の構成を備え、システムモニタユニットの診断ユニットが、点検修理が必要なデバイス(モジュール)についてトラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段を有するので、複数のデバイスのモニタ、保守および点検コストを低減させ、かつトラブル発生時に、トラブルシューティングを行なうのに必要なツールだけでなく、点検修理の処理手順を示す手段を有して、具体的な問題解決策をユーザやサービスエンジニアリングに提供することができる。また、医用モダリティの診断ネットワークシステムを好適に使用可能な分散形試験ユニットを提供することができる。

(4-2)理由1)の本願の発明の詳細な説明および特許請求の範囲の記載不備について
(4-2-1)
(A)合議体審判官殿は、拒絶理由通知の理由1.の「記」欄(1)において
『(1)本願請求項1に「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項の記載があるが、発明の詳細な説明においては該発明特定事項を裏付ける(サポートする)記載がない。
(発明の詳細な説明の段落[0015]には請求項1と同一の記載があり、表現上の整合性は足りているものの、この記載をもって実質的な対応関係……)を認めることは到底できない。
そして、該段落[0015]以外の箇所には該発明特定事項を示唆する記載が見当たらない。特に、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けが不可能である。』と認定された。

(B)合議体審判官殿が指摘した発明特定事項である「トラベルシューテングを行なうのに必要なツール及び点検修理の処理手順を示す診断ユニット」をサポートする記載は本願明細書の段落[0108]?[0110],[0118]?[0120]および同段落[0056]?[0062]ならびに[図2],[図38]?[図41],[図42]に記載されている。
前記『診断ユニット』に関して、[図2]に示す実施例では、システム・モニタ・ボックス16およびマスタDTU(分散形試験ユニット)16を備える構成であり、システム・モニタ・ボックス16は、段落[0052]では、「システム・モニタ・ボックス16(図1,2および14に示す)は、マスタDTU34を通して他の全てのDTU12を制御するもので、……各DTU12が提供したデータを解析して血管イメージングシステム14に発生した変化を判定することができる。……」旨が記載されている。
また、『トラブルシューテングを行なうのに必要なツール』に関しては、明細書の段落[0109],[0110]および[0111]に記載されている。すなわち、明細書のうち、
『[0109]
フィールド・サービス・エンジニアはフィールド・サービス・ノートブック18をシステムモニタボックス16に直ちに接続することができ、スマートブックのソフトウェアを使い、シリアルポート108を通してデータを収集し、システムモニタボックス16上のエキスパート・システム115を稼働させる。図41にはシーケンス上の記号、およびフィールド・サービス・エンジニアに用意されている以下のオプションを図示してある。最初に、フィールド・サービス・ノートブック18とシステムモニタボックス16との間でイーサネット接続が行われる(ステップ140)。
[0110]
スマートブックのツールを立ち上げるため、フィールド・サービス・エンジニアはカスタマイズされたハードウエア・キー100を自分のノートブックのパラレルポート106に差し込む(ステップ142)。このハードウエア・キー100により診断ネットワークシステム10へのユーザアクセスが許可され、その中に満了時間が組み込まれる。このキーが期限切れになっていない場合、スマートブックは、ユーザ名およびパスワードのプロンプトを表示したログイン画面(図示せず)を立ち上げる。
[0111]
接続され、そして安全なアクセスが確認されると、フィールド・サービス・エンジニアはシステムモニタボックス16に載せている本発明の診断ネットワークシステム10に診断開始を知らせる(ステップ144)。図36は、フィールド・サービス・エンジニアに最初に提供される典型的な画面イメージを図示するもので、グラフィカル・ユーザ・インタフェース・メイン・メニュ22およびステータス・バー134を含んでいる。このメインメニュ22はメニューバー上にいくつかのメニューオプションを提示するもので、このオプションには機器構成(configure)126、システム診断(System Diagnostics)128、ビュー(View)130、およびユーティリティ(Utilities)126が含まれる。』
と記載されている。
そして、さらに、明細書の段落[0118]では、「メインメニュー(図41に示す)上の“Systems Diagnostics”のオプション128を選択することで、ユーザに血管イメージングシステム14に関連する、最も共通するトラブルシューティングのツールが提供される。この“SystemsDiagnostics”のオプション128によって、フィールド・サービス・エンジニアは、キャリブレーションを行い、予防保守を行い、トラブルシュートを実行し、システム固有のコンポーネント・リストを観察し、システム上の部品を交換し、……最適な特性基準を発生させることができる。この“Systems Diagnostics”のオプション128を選択することで、図15および図18?26に示した如くの処理手順を実行できる。「解像度“Resolution”」、「半値階層“Half Value Layer”」といった代表的な処理手順へのアクセスを示す……といった代表的な処理手順へのアクセスを示す……。」と記載されている。また、明細書の段落[0119]では、「ユーザが“Systems Diagnostics”128を選択したときには、血管イメージングシステム14の絵が図38に示すように、フィールド・サービス・ノートブック18の画面上に表示される。かかる血管イメージングシステム14の選択可能なコンポーネントは全てボタンとして確認され、そしてアクション・ボタンはキャリブレート用のステータスバー134、予防保守156、トラブルシューティング158、コンポーネンツ160、スナップショット162、およびリプレイスメント164の下に置かれる。……。」と記載されている。
さらに、『点検修理の処理手順を示す手段』に関しては、明細書の段落[0059]?[0062]に記載されている。
明細書の段落[0059]には、「このシステムモニタボックス16は多数の診断処理手順を実行するので、システムの修理に伴う当て推量を減らすことができる。図15の例によって示す如く、フィールドサービスエンジニアは「解像度処理手順(Resolution Procedure)」により解析処理の中を案内され、画像の解像度が修正される。この結果、X線から細い大動脈の如くのビデオ像が画面上に表示され医師の観察に供せられる。医師にとっては殆ど又は全く価値の無いほど画質が劣化していることがある。そのような場合、画質の劣化はイメージ管(これを取り換えるにはおよそ40,000US$も掛かる)のまずさに因って生じているか、またはX線管(この取り換えはかなり安い)のまずさに因るかであろう。」と記載され、同段落[0062]には、「前記エキスパート・システム(expert system)が実行する他の処理手順としては半値テスト(これは例えばX線ビームのハードネス(hardness)を決める)、クイック・チューブ・キャリブレーション・チェック(Quick Tube Calibration Check)、チェック・マックス・エントランス・エクスポージャ・レート(Check Max Exposure Rate)、およびフルオロ・ドーズ・データ(Flouro DoseData)の手続きなどがあり、それぞれ図20、21、22、23、24、25、および26に示されている。」と記載されている。

(C)「トラブルシューティングを行なうのに必要なツール」および「点検処理の処理手順を示す手段」ならびに「診断ユニット」は、(4-2-1)の(B)項に示したように、本願明細書および図面に記載されている。
したがって、合議体審判官殿が指摘した発明特定事項である「トラブルシューティングを行なうのに必要なツール及び点検処理の処理手順を有する診断ユニット」の記載内容は、本願の出願当初の明細書および図面に記載されたものであると思料する。

(4-2-2)
(A)合議体審判官殿は、拒絶理由通知の理由1.の「記」欄(2)において、『(2)本願請求項1の「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の関係(前者は後者の一部なのか?全く別の手段なのか?)が明確でない。(両者の間に改行がないが、これはどちらを意味するのか?)
また、発明の詳細な説明には「判定する」ことに対応する記載は認められるものの、上記(1)記載の如く、発明の詳細な説明に記載の何が「示す手段」や「診断ユニット」に対応するのかが不明であるため、該「判定する手段」も発明の詳細な説明に記載のどの事項に対応するのかも不明であり、このため、発明の詳細な説明を参酌しても、上記「判定する手段」と「診断ユニット」との関係は不明である
したがって、本願請求項1?5に係る発明は明確でなく、また、本願発明の詳細な説明に記載されたものではない。』と認定された。

(B)本審判請求人は、同日付手続補正書の特許請求の範囲の請求項1に記載したように、合議体審判官殿が指摘した両者の関係を明瞭にしました。
すなわち、補正後の請求項1では、[C](3)の構成で示したように、『前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニットと、を備えたことを特徴とする』と補正しました。
請求項1の[C](3)は、「診断ユニット」が「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」と「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段と」を有する関係に補正し、両者の関係を明瞭にしました。

(C)請求項1の同日付提出の手続補正書で補正し、請求項1の[C](3)の構成を明瞭にしましたので、合議体審判官殿が指摘した拒絶理由は解消したものと思料する。

(4-3)特許法第29条第2項に関して
合議体審判官殿は、本願の請求項1?5に係る発明は、前述した引用文献1?20に記載した発明から当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない、と認定された。
これに対し、本審判請求人は、本願請求項1?5に係る発明を同日付提出の手続補正書で補正しました。
すなわち、本願発明は、同日付提出の手続補正書で補正した請求項1?5に係る発明、特に請求項1に記載の診断ネットワークシステムである。
請求項1の診断ネットワークシステムは、分節して説明すると、(4)本審判請求人の主張の(4-1)項に示す通りである。

(4-3-1)引用文献記載の発明ならびにこれらの発明と本願発明との比較検討について
合議体審判官殿は、引用文献1?20に記載の発明から本願請求項1?5に係る発明は、容易に発明をすることができたものである、と認定された。
引用文献1には、合議体審判官殿が拒絶理由通知の理由2.の「記」欄(1)、ア(3頁)で指摘するように、「記載1」および「記載2」の内容が記載されている。
しかし、引用文献1に記載された発明は、異常診断手段の診断結果に基づいて異常発生が判断されたとき、自動コール手段で管理装置に自動的に回線を繋ぎ、自己診断手段の診断結果および上記異常診断手段の判断結果の情報をセンタに情報転送手段で伝送し、上記センタに備えられた管理装置で医用装置の異常を修復する指示を修復指令手段で行なう医用装置の遠隔診断システムである。この遠隔診断システムは、前記情報転送手段で送られる異常判断手段の判断結果の情報に基づき、医用装置の異常を修復させる指示を与える指令修復手段を備えるだけである。
すなわち、引用文献1には、図2のステップ21が自己診断手段を形成し、ステップ22が異常判断手段を形成し、さらに、ステップ31,32が修復処理手段を形成し、ステップ32で例えば部品の交換、修復の対抗処理を指示することが開示されているだけである。
しかし、この引用文献1には、本願発明の請求項1の[C](3)の構成が開示されていない。すなわち、引用文献1には、点検修理が必要なデバイスについてトラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段の双方を有する診断ユニットを備えることは示されていない。
また、引用文献2?4には、医療装置を複数のデバイスで構成し、各デバイス毎に制御監視を行なう処理手段を設けてこれらを通信手段で接続することが記載されている。
さらに、引用文献2?9には、複数の処理手段を接続する際に、処理手段の1つをマスタとして動作させる構成が記載されており、引用文献9?12には、知識データベースを用いて診断を行なう技術が記載されている。
しかし、これらの引用文献2?12は本願発明の請求項1の[C](3)の構成を示したり、示唆する記載はない。すなわち、引用文献2?12には、[C](3)の構成の後段部分である「診断ユニットが複数のデバイスの内、点検修理が必要なデバイスについてトラブルシューティング行なうのに必要なツール及び点検修理の処理手順を示す手段の双方を有すること」を示したり、示唆する記載はない。
また、合議体審判官殿は、「知識データベースを用いて診断を行なう技術(いわゆるエキスパートシステム)は、本願出願時には当業者に周知の技術思想に過ぎない(必要があれば引用文献9?12等参照)とし、さらに、問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも当然の如く採用される周知慣用の設計事項であり得る(必要があれば、引用文献13?15等参照)」と判断している。
しかし、これらの引用文献1?15には、「診断ユニットが複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行なうのに必要なツール及び点検修理の処理手順を示す手段を有する」本願請求項1の[C](3)の構成の後段部分を示したり、示唆する記載はない。
これに対し、本願請求項1に係る発明は、請求項1の[C](3)の構成の後段部分に記載したように、「点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段」を有する判断ユニットが、点検修理が必要か否かを常時判定する手段とともに備えたものである。
この判断ユニットが、「トラブルシューティングを行なうのに必要なツールだけでなく、点検修理の処理手順の双方を示す手段」を双方を有することは、本願の出願当時、当業者が容易に発明し得る程度の設計事項であることは到底思わない。
したがって、本願請求項1に係る発明は、引用文献1?15に記載の発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。

(4-3-2)本願発明と引用文献16?20に記載の発明について
合議体審判官殿は、拒絶理由通知の理由2.オの項(5頁)において、『本願請求項1に係る発明と引用文献16?20に記載のものとを比較すると前者においては、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」を備える点で後者と相違する。
しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術であるから(必要があれば引用文献9?15等参照)、引用文献16?20に記載のものに該周知慣用技術を付加して本願請求項1に係る発明をなすことも、当業者が容易になし得たことである。
したがって、本願請求項1に係る発明は、引用文献9?20に記載された発明に基づいても、当業者が容易に発明をすることができたものである。』と認定している。
しかし、本願請求項1に係る発明が「前記ユーザインタフェースの通信に応じて前記複数のデバイスの内の……必要なツール及び点検修理の処理手順を有する診断ユニット」すなわち、[C](3)の構成の後段部分を備えるものであるが、この構成は、引用文献16?20にも記載されており、本願請求項1に係る発明と引用文献16?20に記載された発明との間に技術的な相違点は存在しない。本願の請求項1?5に係る発明は、引用文献16?20に記載されているが、引用文献16?20に記載の発明は、本件出願の遡及する出願日以後に公知になったものである。
しかも、本件出願は、特願2006-196211の分割出願(特願2009-201847、出願日:平成21年9月1日)であり、親出願である特願2006-196211(特開2007-026450号公報(特許文献19)参照)は特願平9-149496号(出願日:平成9年6月6日)の分割出願である。親出願は、特開2007-26450号公報(引用文献19参照)として平成19年2月1日に出願公開され、祖父出願は特開平10-83315号公報(引用文献18参照)として平成10年3月31日に出願公開されたものである。
したがって、本件出願は、特願平9-149496号の孫出願に相当し、出願日は平成9年6月6日まで遡及するものと思料する。
一方、本件出願の祖父出願である特願平9-149496号は、特願平08-182601号(特開平09-16853号公報(特許文献16)参照)、特願平08-182602号(特開平09-168532号公報(引用文献17)参照)の国内優先主張を伴って出願したものである。また、特願平09-182601号および特願平09-182602号は、1995年6月7日にアメリカ合衆国での出願を基礎とするパリ条約に基づく優先権を主張した出願(米国特許出願第08/484,660号)で、米国特許第6487513号明細書(引用文献20参照)として平成14年11月26日に発行されたものである。特願平09-182601号および特願平09-182602号の出願は、引用文献16および17に示すように、平成9年6月30日に出願公開されたものであり、米国特許出願第08/484,660号は、平成14年11月26日に特許明細書が発行されたものである。
したがって、本件出願の出願日は遡及する平成9年6月6日当時、引用文献16?20はいずれも公然と知られておらず、本件出願の拒絶理由の対象ではないと思料する。

(4-3-3)してみると、本願請求項1に係る発明は、引用文献1?20に記載された発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有すると確信する。
なお、引用文献18および19記載の発明は、本件出願の親出願および祖父出願であり、引用文献16および17は、米国出願08/484,660号(USPNo.6,487,513号明細書(引用文献20参照))を基礎とするパリ条約に基づく優先権主張出願の公開公報である。本件出願の出願日は、祖父出願の出願日である平成9年6月6日まで遡及するものである。遡及する出願日である平成9年6月6日当時、引用文献16?20に記載の発明は公知の発明ではない。したがって、引用文献16?20に記載の発明は、今回の拒絶理由の対象となる文献ではないと思料する。

(4-3-4)また、本件の請求項1?5に係る発明(以下、補正後の発明という。)は、同日付提出の手続補正書において、平成22年5月17日付で手続補正された請求項1?5に係る発明(以下、補正前の発明という。)を補正したものである。
しかも、補正前の発明に対し補正後の発明は、平成6年法律第116号で改正された特許法第17条の2第4項の規定(現在の特許法第17条の2第5項の規定に相当する。)が適用されるが、この規定に違反してなされたものではない、と思料する。
その上に、本件の請求項1に係る発明の[C](3)の構成の後段部分に記載の『前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット』である発明特定事項は、本願の明細書の段落[0015]の他、[0059]?[0062],[0108]?[0110],[0118]?[0120]および図面の[図1],[図2],[図15],[図41][図42]に記載されている。
また、本件出願の明細書の段落[0059]?[0062],[0108]?[0110],[0118]?[0120]および図面の[図1],[図2],[図15],[図41],[図42]に相当する技術事項は、次の明細書および図面の対応表で示すように、親出願である特開2007-26450号公報(引用文献19参照)、および祖父出願である特開平10-83315号公報(引用文献18参照)の明細書および図面にもそれぞれ記載されている。
また、本願の明細書の段落および図面の図番と、親出願や祖父出願の明細書の段落および図面の図番の対応関係はそれぞれ次の表に示す通りであり、技術内容は三者間において同一であり、異なるところはない。

したがって、本願の請求項1の[C](3)の構成の後段部分に記載の前記発明特定事項は、親出願および祖父出願の明細書および図面にもそれぞれ記載されている。
また、同日付提出の手続補正書で補正された補正後の発明は、すなわち、補正後の請求項1?5に係る発明は、明細書の段落[0015]に記載された内容と同一であり、さらに、補正後の請求項1の[C](3)の構成のうち、前記発明特定事項は、本願および親出願、祖父出願の各明細書および図面に記載されている。この補正後の請求項1に記載の発明特定事項は、親出願および祖父出願の明細書および図面にも同様に記載され、開示されている。
してみると、本願の請求項1?5に係る発明は、親出願にも祖父出願にも開示されており、本件出願は、平成21年9月1日に分割出願されたものであるが、その出願日は祖父出願の出願日である平成9年6月6日まで遡及するものと思料する。
さらに、同日付提出の手続補正書で補正された補正後の発明は、平成6年法律第116号改正の特許法第17条の2第4項(現在の特許法第17条の2第5項に相当する。)の規定に違反する補正ではないと思料する。また、補正後の請求項1?5に係る発明は、補正前の請求項1?5に係る発明から、請求項1の[A]の構成に「医用モダリティの診断ネットワークシステム」を加え、診断ネットワークシステムの適用対象を医用モダリティに限定したものである。
このため、補正後の請求項1?5に係る発明は、補正前の請求項1?5の発明から特許請求の範囲の記載を減縮したものである。

(4-3-5)独立特許要件について
本件補正後の発明の詳細な説明および特許請求の範囲の記載は明細書および図面に記載されたものである。
中でも、本件補正後の請求項1に記載した[C](3)の構成の後段部分における「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」の発明特定事項は、明細書の段落[0015]に記載の他、前述した、明細書の段落および図面に開示されている。前記発明特定事項は出願当時の明細書および図面に実質的に記載されていると思料する。
また、補正後の請求項1?5に係る発明は、引用文献1?15に記載の発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。
さらに、引用文献16?20は、本件出願の出願日が、前述したように平成9年6月6日まで遡及するものであるから、本件出願の拒絶理由にはなり得ないと思料する。
してみると、本願の請求項1?5に係る発明は、特許出願の際独立して特許を受けることができるものである、と思料する。

(5)むすび
本願の請求項1?5に係る発明は、発明の詳細な説明および特許請求の範囲に記載されたものであり、特許法第36条第4項第1号および第6項第1号,第2号に規定する要件を満たした出願であると思料する。
本願の請求項1?5に係る発明は、引用文献1?20に記載された発明から当業者が容易に発明をすることができたものではなく、充分に進歩性を有する発明であると思料する。
つきましては、審判官殿各位の再度のご審理の上、原査定を取り消す、本願はこれを特許すべきものである、との審決を下さるようお願いする。』


第2.特許法第36条(明細書の記載要件)について

1.拒絶理由、特許請求の範囲及び明細書
特許法第36条についての当審拒絶理由は上記第1.2.(1)の理由1.に記載の通りのものである。
また、本願特許請求の範囲及び明細書の記載は上記当審補正書によって補正された特許請求の範囲及び明細書に記載されるとおりのものである。


2.当審判断
そこで、当該拒絶理由が解消されたものであるか否かについて以下に検討する。

(1)当審拒絶理由1.(1)について
ア.本願特許請求の範囲の請求項1に記載の発明を特定するための事項(以下、「発明特定事項」と記す。)を検討するに、そこには、依然として、当審拒絶理由1.(1)で摘記された「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段を有する診断ユニット」との発明特定事項に対応する「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」を備えるとの発明特定事項(以下、「当審指摘の発明特定事項」と記す。)の記載がある。

イ.なお、ここでの「トラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」との記載は、原審よりの出願人、請求人の主張内容等(特に、平成21年9月1日付け上申書、平成22年5月17日付け意見書、平成23年2月8日付け審判請求書及び平成23年5月30日付け回答書等では、本願発明が「必要なツール」と「点検修理の処理手順」の双方を「示す」ものであると説明している点。)からみて「診断ユニット」が「トラブルシューティングを行うのに必要なツール」と「点検修理の処理手順」の双方を「示す手段」を「有する」と解すべきものである。

ウ.しかしながら、当審指摘の発明特定事項を示す記載は、発明の詳細な説明の段落【0015】にあるのみで、他の箇所には見当たらない。
該段落【0015】は、単に特許請求の範囲の請求項1の記載と同一の文が【課題を解決するための手段】として記載されているのみであり、この記載をもって請求項に係る発明が、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲にあると認めることは到底できず、特許請求の範囲の請求項1の記載と発明の詳細な説明の記載とに実質的な対応関係を認めることはできない。
また、依然として、実施の形態に開示の事項との対応付けを試みても、そこに記載の何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかが皆目不明であり対応付けができない。

エ.なお、請求人はこの点に関し、上記第1.2.(3)に示した当審意見書の(4-2-1)のとおりの釈明をしているが、何が「ツール」に対応し、何がこれを「示す」ことに対応し、何が「示す手段」に対応し、何が「診断ユニット」に対応するのかは明示しておらず、該釈明を参酌しても、これらの対応付けが明確になるものではない。
また、当該当審意見書の「前記『診断ユニット』に関して・・・旨が記載されている。」との釈明からは、「システム・モニタ・ボックス16およびマスタDTU(分散形試験ユニット)16を備える構成」が「診断ユニット」に対応付けられる旨を主張しているとも推測できるが、かかる対応付けは、平成22年5月17日付け意見書(特に(4-3)の「前記システムモニタユニットは、[C](1)のコントロールユニット、(2)のデータベース、(3)の診断ユニットを有し」、「システムモニタユニットが、点検修理に必要なデバイス(モジュール)についてトラブルシューティングを行なうのに必要なツールおよび点検修理の処理手順を示す手段を備えることで」等の記載)、平成23年2月8日付け審判請求書(特に(3-3)の「システムモニタユニットが[C](1)?(4)の構成を備える」、「システムモニタユニットが、[C](4)の構成を備え」等の記載)及び平成23年5月30日付け回答書(特に(2-1)の「システムもニタユニットの診断ユニットが」等の記載)等での「システムモニタユニット」が「診断ユニット」を有する旨の記載と相入れない。
また、当該当審意見書の『そして、さらに、明細書の段落[0118]では・・・・および26に示されている。」と記載されている。』との釈明からは、「スマートブックのソフトウェア」、「システムモニタボックス16上のエキスパート・システム115」及び「メインメニュー(図41に示す)上の“Systems Diagnostics”のオプション128を選択することで」提供される「ユーザに血管イメージングシステム14に関連する、最も共通するトラブルシューティングのツール」が「トラブルシューティングを行うのに必要なツール」に、「「解像度処理手順(Resolution Procedure)」や「半値テスト(これは例えばX線ビームのハードネス(hardness)を決める)、クイック・チューブ・キャリブレーション・チェック(Quick Tube Calibration Check)、チェック・マックス・エントランス・エクスポージャ・レート(Check Max Exposure Rate)、およびフルオロ・ドーズ・データ(Flouro DoseData)の手続きなど」が「点検修理の処理手順」に対応付けられる旨を主張しているとも推測できるが、このような対応付けをしても、これらを「示す」こと及び「示す手段」に齟齬無く対応付けられる記載が発明の詳細な説明には見当たらない。

オ.してみると、当審意見書の釈明を参酌しても、上記当審指摘の発明特定事項は、発明の詳細な説明に記載される事項との対応付けができないものであり、発明の詳細な説明においては該発明特定事項を裏付ける(サポートする)記載がないとした当審拒絶理由1.(1)で指摘した不備は何ら解消されていない。

カ.したがって、本願請求項1?5に係る発明は、依然として、本願の発明の詳細な説明に記載されたものでないので、この出願は特許請求の範囲の記載が特許法第36条第6項第1号に規定する要件を満たしていない。
また、このため、本願請求項1?5に係る発明の範囲も明確なものではないので、依然として、この出願は特許請求の範囲の記載が特許法第36条第6項第2号に規定する要件を満たしていない。
更にこのため、本願発明の詳細な詳細な説明は、依然として、本願請求項1?5に係る発明を説明しているものとは言えず、当業者が請求項に係る発明を実施することができる程度に明確かつ十分に記載されていないものであり、しかも、本願請求項1?5に係る発明の技術上の意義を理解するために必要な事項が十分に記載されておらず、特許法第36条第4項第1号の経済産業省令で定めるところによる記載がされていないものでもあるので、依然として、この出願は発明の詳細な説明の記載が特許法第36条第4項第1号に規定する要件を満たしていない。


3.中結
以上の通り、本願は、明細書及び特許請求の範囲の記載が、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていない。



第3.特許法第29条第2項(進歩性)について-その1

1.本願発明の認定
本願の請求項1に係る発明(以下「本願発明」と言う。)は、上記第1.2.(2)の当審補正書の特許請求の範囲の【請求項1】として記載されたとおりのもの(以下に再掲する。)と認める。

<本願発明>
「複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと、
マスタ分散形試験ユニットと、
前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと、
前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行うシステムモニタユニットと、
前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせるユーザインタフェースと、を備え、
前記システムモニタユニットは、前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもので、
前記複数の分散形試験ユニットから前記動作状態に関する情報を収集するコントロールユニットと、
前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベースと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニットと、
を備えたことを特徴とする診断ネットワークシステム。」


2.引用文献
本願の出願前に頒布され、上記当審拒絶理由通知において引用された、下記引用文献には、それぞれ、下記引用文献記載事項が記載されている。(下線は当審付与。)

<引用文献1>
特開平06-062130号公報(平成6年3月4日出願公開)

<引用文献記載事項1-1>
「【請求項1】 サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備えることを特徴とする医用装置の遠隔診断システム。」

<引用文献記載事項1-2>
「【0011】次いで、上記遠隔診断システムの診断の流れを図2に基づいて説明する。
【0012】図2のステップ20?30は医用装置側、即ちX線CTスキャナ10a?10nの各々において実施される処理である。まず、X線CTスキャナ10a(?10n)のコンピュータは、ステップ20において、通常の撮影処理を実施している。この実施中の適宜なタイミング(例えば、ある患者の撮影が完了して次ぎの患者の撮影に移る前)で、ステップ21の自己診断の処理を実行する。このステップでは、スキャナ10a(?10n)のコンピュータは予め記憶している装置側診断プログラムを自ら走らせて、その診断結果を得る。次いでステップ22に移行し、スキャナ10a(?10n)のコンピュータは診断結果中に、スキャナの機能として異常を示す異常データが有るか否かを判断する。ステップ22において、異常データが無い(NO)の判断のときはステップ20の通常処理に戻るが、異常データが有る(YES)の判断のときはステップ23に移行する。
【0013】ステップ23では、ステップ22で見つかった異常データが回復可能なエラーを示すものか否かを判断し、回復不能なエラーである(NO)と判断されたときは、続いてステップ24?26の処理を行う。ステップ24では、異常データが有り、回復不能である旨の表示、例えば「……というエラーが発生しました。サービスセンタに連絡中です。」がスキャナ10a(?10n)のモニタに表示される。次いでステップ25では、スキャナ10a(?10n)のコンピュータが自動コール処理プログラムを起動することにより、モデム11a(?11n)、電話回線12及びモデム13を介してサービスセンタSのコンピュータ14を自動的に呼び出し、両方のコンピュータ間をつなぐ。次いでステップ26では、スキャナ10a(?10n)でそれまでに収集した異常データ、スキャナ側の履歴情報などのデータが、つながれた電話回線を介してサービスセンタSに転送される。
【0014】一方、上記ステップ23の判断でYES、即ち異常データが検知されたが、回復可能なエラーであると判断されたときは、ステップ27に移行してエラーログに記録した後、ステップ28に移行する。ステップ28で、エラー発生数(頻度)が多いか否かを、予め定めたしきい値と比較するなどの処理によって判断する。この判断の結果、特定のエラー発生数(頻度)が多い(YES)とされたときは、前述したと同様に、ステップ29のサービスセンタSへの自動コール処理、及びステップ30のサービスセンタSへのデータ転送処理に付された後、ステップ20の通常処理に戻り、通常処理を並行して可能にする。ステップ28で、エラー発生数(頻度)が少なく(NO)、未だ異常状態であるとは特定できないとするときは、ステップ20の通常処理に戻る。」

<引用文献記載事項1-3>
「【0016】この対応内容の転送を受けたスキャナ10a(?10n)側のコンピュータは、ステップ34で、そのモニタに対応内容(例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」)を表示し、スキャナ10a(?10n)は待機状態に入る。
【0017】これにより、上記ステップ32で異常状態への対応を依頼された、例えば工場FTは必要な修理部品を病院A(?N)又は担当サービスステーションSTa(?STn)に発送するし、同様に、ステップ32で対応を依頼された担当サービスステーションSTa(?STn)は病院A(?N)にサービスエンジニアを派遣したりすることになる。
【0018】このため、X線CTスキャナ10a(?10n)が故障しても、病院側のオペレータの連絡を待たずに、直ちに異常事態の修復作業に入ることができ、スキャナのダウンタイムを極力短縮させ、医療行為への支障を最小限に食い止めることができる。」

<引用文献記載事項1-4>
「【0021】ここで、上述した図2中のステップ21?23,27,28を中心とする自己診断処理及び異常判断処理の具体例を図3?図7に基づいて説明する。
【0022】画像再構成装置の診断例を図3に示す。X線CTスキャナ10a(…10n)は、まず、図3のステップ40において磁気ディスクからテスト用生データを読出し、ステップ41において再構成演算装置にテスト用生データを用いた画像再構成を命じる。次いでステップ42に移行し、予め記憶しているテスト用画像と再構成した画像とを比較し、ステップ43において両者が一致しているか否か判断する。このステップ43でOK(即ち、両画像が一致)の場合は、ステップ44でテスト継続か否か判断し、継続する場合はステップ40に戻るし、継続しない場合はステップ45の判断に移行する。ステップ45では、それまで規定回数テストした中に異常データが在るか否か判断し、異常データが無い場合は処理を終了し、異常データが在る場合はその旨のモニタ表示、センタ自動コール及びデータ転送(図2のステップ24?26の処理参照)を行う。これに対し、ステップ43でOKでない(即ち、両画像が一致していない)の場合は、ステップ46でテスト継続か否か判断し、YESの場合はステップ47で異常データを記憶した後、上述した処理を繰り返す。しかし、NOの場合は、上述したと同様にモニタ表示、センタ自動コール及びデータ転送を行う。」

<引用文献記載事項1-5>
「【0023】また、X線高電圧装置の通常スキャン時の診断例を図4に示す。なお、この診断に対するハードウエア構成を図5に示す。
【0024】最初に、図5のハードウエア構成から説明する。このX線高電圧装置は、X線制御部50に接続された高圧トランス51を有し、この高圧トランス51の2次側に、整流回路52、52を介してX線管53が負荷として接続されている。整流回路52、52とX線管53の間には、演算増幅器、比較器を各々有する管電流検出回路54及び管電圧検出回路55が接続され、それらの検出信号がCPU56に供給されている。なお、検出回路54、55の各比較器には、管電流、菅電圧の上限値、下限値に相当する基準電圧が各々供給されている。
【0025】上記CPU56は、図4に示すように動作する。つまり、図4のステップ60で通常スキャンを指令している間の適宜なタイミングで、ステップ61のエラー発生か否かの判断を行う。この判断は、上記管電流検出回路54及び管電圧検出回路55から供給される、論理レベルの検出信号を読み込んで、過管電流、過管電圧、主回路の過電流、X線管オーバヒート、熱交換器のフロー異常などの項目をチェックすることで行う。この判断でNO(エラー発生なし)の場合はステップ60に戻るが、YES(エラー発生)の場合はステップ62の致命的なエラーか否かを判断する。この判断でYES(致命的なエラーである)の場合は、図2のステップ24?26の処理と同様に、モニタ表示、センタ自動コール及びデータ転送を行う。しかし、NO(致命的なエラーではない)の場合はステップ63に移行して、異常データを記録し、さらにステップ64に移行して、エラーの発生頻度が基準値よりも大きいか否かを判断する。このステップ64でNOの判断が下されたときはステップ60に戻るが、YES(エラー発生頻度が大きい)の判断が下されたときはモニタ表示、センタ自動コール及びデータ転送を行う。」

<引用文献記載事項1-6>
「【0029】なお、上述した実施例については、種々の変形例が可能である。
【0030】第1に、回復可能なエラーである(即ち、致命的なエラーではない)か否かの判断に応じて、自動コールの呼び出し先を変えるようにしてもよい。例えば、致命的なエラーの場合には直接、担当のサービスステーションSTa(?STn)に自動コールさせるようにすれば、その緊急性に応じた処置が可能になる。
【0031】第2に、前述した自己診断プログラムは夜間に走らせるようにしてもよく、その自己診断の結果、致命的なエラーではない場合(例えば、何千回かに1回の割合で生じる、画像再構成時のエラー)、スキャナ側の自動コール処理プログラムが起動され、スキャナ側のモデムを通して、サービスセンタSの自動呼び出しを行う。そして、スキャナ側情報、異常発生日時、異常データなどをサービスセンタSに転送しておいて、転送後は、通常のシステムとして使用継続できるようにしてもよい。また、これら一連の処理は、スキャナの通常使用のバックグラウンドでのソフトウエア処理としてもよい。
【0032】第3に、図2のステップ31の処理に係る分析結果、サービスセンタS側でスキャナ10a(?10n)の更に詳細な異常状態を知りたいと判断したとき、センタ側から装置側へ別の診断プログラムを走らせたり、エラーを回避するモードへの自動的な設定変更を装置側に指令することができる(図8のステップ31a参照:同図中で図2と同一符号のステップは同一処理を示す)。なお、センタ側から遠隔診断の処理を指示した後、一旦回線を切り離し、医用装置側の処理が終了した時点で、自動コールし、データ転送するシステムも可能である。このとき、異常時であると判断したときのみ、自動コールするようにしてもよい。」

<引用文献記載事項1-7>
「【0033】第4に、通常使用中にエラーが発生した場合、サービスセンタSへの自動コールの要、不要の判断をオペレータにさせるようにしてもよい。
【0034】第5に、オペレータの判断に応じて自動コールを行う手段を設けてもよい。即ち、オペレータが気付いた異常情報を入力させ、それらの情報をオペレータの操作に基づき自動コールし、転送するようにする。これにより、自動的な自己診断には依存しない各種の不具合を転送可能になる。このとき、オペレータが緊急度を指定できるようにしておけば、ちょっとしたオペレータの要望なども入手できるようになる。即ち、緊急度の低い改善、要望などであって、サービスステーションにわざわざ連絡したり、サービスエンジニアを呼んで要望するほどでもない情報を地道に収集できる。」


<引用文献2>
特開平07-303652号公報(平成7年11月21日出願公開)

<引用文献記載事項2-1>
「【0025】本実施例では、複数の装置を同時に使用する内視鏡システムであるため、手術を行う執刀医、看護婦がそれぞれに適した操作環境が得られるように、図3に示すように構成した複数の装置を集中的に操作及び制御できるようにしている。
【0026】前記内視鏡用カメラ装置1,光源装置8,高周波焼灼装置17,気腹装置18は、各装置に設けられているシリアルインターフェース33a,33b,33c,33d,33e,33f,33gにシリアル通信回線38a,38b,38c,38d,38e,38fを各々1対1に接続して、システム全体の制御を行うシステムコントローラ35によって集中制御されるようになっている。
【0027】内視鏡システムには、各装置の状態の表示を行う表示手段として、集中表示パネル36と集中制御パネル37の複数の表示手段とを設けており、システムコントローラ35に接続されている。集中表示パネル36には液晶ディスプレイなどからなる表示部36aが設けられ各装置の状態が表示されるようになっている。集中制御パネル37には液晶ディスプレイなどからなる表示部37aと、この表示部37aの上に一体的に設けたタッチセンサなどで構成されたタッチパネル37bとが設けられており、各装置の状態が表示されると共に、機能操作スイッチ等が表示部37aに表示され、スイッチ電極が2次元的に配置されたタッチセンサの所定の領域に触れることにより機能操作スイッチが入力されて操作指示が行えるようになっている。
【0028】また、装置毎に設けたCPU1c,8c,17c,18c,35c,36c,37cがシリアルインターフェース33a,33b,33c,33d,33e,33f,33gに1対1で接続されているシリアル通信回線38a,38b,38c,38d,38e,38fによって、CPUの通信内容を互いに確認する通信回線確認手段を構成している。
【0029】さらに、システムコントローラ35には暴走状態を検出する制御機器暴走検出手段としてWDT35bが設けてある。
【0030】なお、集中表示パネル36は、表示部のみを設けて該パネルにおいて表示のみを行うようにしても良い。システムコントローラ35は、集中表示パネル36,集中制御パネル37のそれぞれにおいて目的の機器の状態を表示し、また目的の操作が行えるように、各装置の操作パネル1a,8a,17a,18aの表示画面の制御を行える。
【0031】また、前記集中表示パネル36は、手術を行う執刀医が手術中に必要な情報をひとまとめで見ることができるようにするのが主目的であり、集中制御パネル37は、手術の間、執刀医の指示に従って機器の操作や鉗子類の受け渡しを担当する看護婦などが機器の操作を行なうことが主目的となっている。」


<引用文献3>
特開平01-238831号公報(平成1年9月25日出願公開)

<引用文献記載事項3-1>
「2.特許請求の範囲
(1)X線を被検者に放射しその透過X線像を得る透視台と、この透視台へX線発生用の電力を供給するX線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るX線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、少なくとも透視台及び一つの操作器または透視台及びX線発生装置の個別制御装置内にはマイクロプロセッサを搭載し、このマイクロプロセッサを搭載した各個別制御装置を通信回線で相互に接続したことを特徴とするX線透視撮影装置。
(2)各構成要素ごとに分散して配置された個別制御装置のそれぞれにマイクロプロセッサを搭載すると共に、このマイクロプロセッサを搭載したそれぞれの個別制御装置を通信回線で相互に接続した請求項1記載のX線透視撮影装置。
(3)それぞれの個別制御装置を相互に接続する通信回線の途中に一つまたは複数の分岐手段を設け、この分岐手段により上記通信回線を中継接続した請求項1または2記載のX線透視撮影装置。
(4)各構成要素ごとに分散して配置されたそれぞれの個別制御装置を通信回線でリング状に相互に接続した請求項2記載のX線透視撮影装置。」


<引用文献4>
特開平02-189134号公報(平成2年7月25日出願公開)

<引用文献記載事項4-1>
「2.特許請求の範囲
(1)X線を被検者に放射しその透過X線像を得る透視台と、この透視台へX線発生用の電力を供給するX線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るX線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、これらの個別制御装置を通信回線で相互に接続すると共に、この通信回線には汎用コンピュータを接続したことを特徴とするX線透視撮影装置。
(2)X線を被検者に放射しその透過X線像を得る透視台と、この透視台へX線発生用の電力を供給するX線発生装置と、上記透視台を遠隔操作するための一つまたは複数の操作器と、上記各構成要素の内部構成部品と接続されそれぞれの構成要素を制御する制御装置とを備えて成るX線透視撮影装置において、上記制御装置は、上記各構成要素の動作を制御する個別制御装置ごとに当該構成要素の内部又は付近に分散してそれぞれ配置し、これらの個別制御装置を通信回線で相互に接続すると共に、この通信回線には汎用コンピュータを接続するため相互間で通信仕様を変換する変換器を接続したことを特徴とするX線透視撮影装置。
(3)上記変換器に汎用コンピュータを接続した請求項2記載のX線透視撮影装置。」


<引用文献5>
特開平06-208485号公報(平成6年7月26日出願公開)

<引用文献記載事項5-1>
「【請求項1】複数のデータ処理装置がネットワークを介してそれぞれ接続されているネットワークシステムにおいて、
前記複数のデータ処理装置をグループ化し、各グループ毎に、グループ内で発生した障害情報を蓄積するグループ監視装置を設けると共に、
システム全体に、前記各グループ監視装置からの障害情報を受信して出力するシステム監視装置を設けたことを特徴とする障害監視システム。」


<引用文献6>
特開平05-073450号公報(平成5年3月26日出願公開)

<引用文献記載事項6-1>
「【請求項1】 監視制御装置と複数の機器とが一本のケーブルによってリング状にそれぞれ接続される集中監視制御方式であって、前記複数の機器の動作状態を監視する場合、前記監視制御装置は、前記複数の機器毎の動作情報を挿入するデータ部を有する監視要求パケットを生成して前記ケーブル上に送出し;前記複数の機器は、前記監視要求パケットを受信して該当する前記データ部に動作情報を挿入した後、前記ケーブルを介して前記監視要求パケットを順次送出していくことを特徴とする集中監視制御方式。」


<引用文献7>
特開平03-072742号公報(平成3年3月27日出願公開)

<引用文献記載事項7-1>
「2.特許請求の範囲
1.データをフレーム単位の構成で伝送するリング状ローカルエリアネットワーク伝送路上に配置された複数のデータ伝送装置と、
この各データ伝送装置に接続された複数のプロセッサと、
前記リング状ローカルエリアネットワーク伝送路を監視し保守する保守監視装置と
を備えたデータ伝送システムにおいて、
前記保守監視装置と前記リング状ローカルエリアネットワーク伝送路上に配置された前記データ伝送装置との間に前記保守監視装置を制御するネットワークアダプタを設け、
前記保守監視装置に、
前記ネットワークアダプタで折返され返送されるネットワークアダプタ折返しフレームを送信するネットワークアダプタ折返しフレーム送信手段と、
返送された前記ネットワークアダプタ折返しフレームを受信するネットワークアダプタ折返しフレーム受信手段と
を備えたことを特徴とするデータ伝送システム。」


<引用文献8>
特開平05-035329号公報(平成5年2月12日出願公開)

<引用文献記載事項8-1>
「【請求項1】 配管中を流れる流体の流量や温度等を検出する発信器と2線の制御ループで接続され、配管中の各所に配置された複数の前記発信器の出力に基づいて該発信器及び制御ループの異常を診断する制御ループ系の異常監視システムにおいて、
複数の前記発信器のそれぞれに対応して2線の制御ループで接続される複数のインターフェース装置を各グループに分割し、分割された各インターフェースの中で1つのマスタインターフェース装置を定め、マスタインターフェース装置は自身に接続される発信器の出力データを入力するとともに、自身の配下のインターフェース装置に接続される発信器の出力データを入力し、これら各発信器の出力データの相関関係を演算するとともに、この演算結果と予め設定された当該の各発信器間の相関関係情報とを比較することにより前記発信器を含む制御ループ系の異常を特定するようにしたことを特徴とする制御ループ系の異常診断方法。」


<引用文献9>
特開平07-253956号公報(平成7年10月3日出願公開)

<引用文献記載事項9-1>
「【請求項1】 ネットワークによって互いに接続された多数の被監視計算機を集中監視装置によって監視する計算機監視方式において、
前記障害に対応した対処方法を格納する対処方法格納手段(1a)と、
前記障害に応じたエラーメッセージを、予め前記各被監視計算機(2a,2b・・・)において付加された分類データとともに表示画面(1c)上に表示するメッセージ表示手段(1b)と、
前記エラーメッセージが表示された障害の中から対処したいものをオペレータの操作に従って選択する対処障害選択手段(1d)と、
前記選択された障害の対処方法を前記対処方法格納手段(1a)から読み出して前記表示画面(1c)上に表示する対処方法表示手段(1e)と、
前記表示された対処方法に従ってオペレータの操作により障害対処を実行する障害対処実行手段(1f)と、
前記障害対処実行手段(1f)による対処内容の履歴を格納する対処履歴格納手段(1g)と、
前記格納された対処履歴の中から表示させたいものをオペレータの操作に従って選択する対処履歴選択手段(1h)と、
前記選択された対処履歴を前記表示画面(1c)上に表示する対処履歴表示手段(1i)と、
を有することを特徴とする計算機監視方式。」

<引用文献記載事項9-2>
「【0002】従来、LAN等のネットワークによって互いに接続された多数の被監視計算機を集中監視装置によって監視する計算機監視方式としては、各計算機で生じた障害を上位の計算機が監視し、さらにそれらを最上位の集中監視装置で監視するようにした方式が知られている。」


<引用文献10>
特開平05-324673号公報(平成5年12月7日出願公開)

<引用文献記載事項10-1>
「【請求項1】 故障製品を解析する製品故障解析装置において、
前記故障製品の特徴を入力する入力手段と、
前記入力手段に接続され、一組の過去の故障製品の特徴及び対応する過去の故障メカニズムを格納するデータ・ベース手段と、
前記故障製品の特徴に応答して、前記データ・ベース手段をアクセスし、前記一組の過去の故障メカニズムから少なくとも一つの過去の故障メカニズムを選択する手段と、
前記選択された過去の故障メカニズムを確認するための一組の故障解析手順を決定するエキスパート・システム手段と、
を備えていることを特徴とする製品故障解析装置。
【請求項2】 少なくとも一つの故障部品を解析するための故障解析手順を決定する製品故障解析方法において、
一組の過去の故障部品の特徴及び対応する過去の故障メカニズムをリレーショナル・データ・ベース内に格納するステップと、
前記リレーショナル・データ・ベース手段をアクセスし、前記一組の過去の故障メカニズムから少なくとも一つの過去の故障メカニズムを選択的に供給するステップと、
前記選択した過去の故障メカニズムを確認するための一組の故障解析手順を決定するステップと、
を備えたことを特徴とする製品故障解析方法。」


<引用文献11>
特開平06-149623号公報(平成6年5月31日出願公開)

<引用文献記載事項11-1>
「【請求項1】 自己の運用管理状態を制御するための情報を採取する情報採取機能と、この情報採取機能の採取した情報を判別しこの判別結果に基づき前記自己の運用管理状態を制御する運用管理制御機能とを情報処理装置内に備えることを特徴とする情報処理装置の運用管理システム。
【請求項2】 情報採取機能が、情報処理装置の運用管理のための情報を既存の情報採取方法では採取できない場合に新規に情報採取方法を作成する情報作成部および前記情報の取得・伝達を行う情報制御部からなる情報採取制御部と、前記情報作成部の作成した情報採取方法を既存の情報採取方法として格納する採取条件ファイルとから構成され、運用管理制御機能が、前記情報処理装置の運用管理についての処理判別条件および処理内容を格納している処理条件ファイルと、前記情報採取制御部から前記情報を受け前記処理条件ファイルを参照して処理を判別する処理判別部およびこの処理判別部の判別結果を受け以後の処理内容を指示する処理部とからなる内部運用制御部と、この内部運用制御部の指示を受け処理を実行する処理実行部とから構成されることを特徴とする請求項1記載の情報処理装置の運用管理システム。
【請求項3】 情報処理装置は、実行処理部の処理の実行結果を情報として採取する情報採取制御部が、前記処理の実行結果から現行の採取条件ファイルおよび処理条件ファイルの格納済の情報からでは適切な情報採取方法を作成できず自己の運用管理を制御できないと判断した場合に最新の情報を出力し運用管理のための処理内容を受領するための端末と接続し、前記端末が、前記情報処理装置の送出する情報を受信する入力制御部と、前記受信した情報を解析し処理の内容を指示する解析部と、前記解析部の指示する処理の内容を前記情報処理装置に出力する出力制御部とからなる外部運用制御部を含み、前記解析部の解析動作を援助する監視方法および人間の経験則を蓄える知識ベースファイルおよび前記出力制御部の出力する前記処理の内容を表示する外部出力装置に接続していることを特徴とする請求項1記載の情報処理装置の運用管理システム。」


<引用文献12>
特開平02-247576号公報(平成2年10月3日出願公開)

<引用文献記載事項12-1>
「5.データを入力する入力装置と、着脱自在の記憶媒体を有する記憶装置と、オペレータに対する指示および処理結果を表示する出力装置とを有し、
かつ、オペレータにたいして点検すべき事項および手法を教示すると共、入力されるデータの異常有無を判定する機能と、入力されたデータに基づいて、余寿命を推定する機能とを有する、診断用端末装置。
6.点検ごとに蓄積される点検情報と、モデル部品について寿命を解析したモデル部品データと、交換部品についての試験データである交換部品データとを有するデータベースと、
前記データベースから、点検対象についての非破壊試験データを検索し、該非破壊試験データに対する残存破壊値の相関関係を示す実験式を求め、かつ、前記データベースから、点検対象についての運転経歴データを検索し、該運転経歴データに対する残存破壊値の相関関係を示す実験式を求める手段と、
点検時に得られたデータを、各々対応する前記実験式に入力して、各々残存破壊値を求める手段と、
予め求められた残存破壊値と径時変化との相関関係により、余寿命を求める手段とを備えたことを特徴とする診断システム。」(特許請求の範囲第5項?第6項)

<引用文献記載事項12-2>
「ホスト装置1は、高速で、大容量のデータ処理が可能なコンピュータであって、内部機能として、推論部5.データベース11、知識ベースエディタ24およびインタフェース28を有する。これらは、コンピュータのハードウェアとソフトウェアによって実現されるものであることはいうまでもない。」(第5頁下右欄第9行?第15行)


<引用文献13>
特開平07-030977号公報(平成7年1月31日出願公開)

<引用文献記載事項13-1>
「【0082】図4は、電気系の故障診断処理を示すフローチャートである。図2のステップ106において「電気系の故障診断プログラム」が起動された場合、あるいは図3のステップ205において電気系の故障診断処理が開始された場合に、図4の処理がスタートされる。
【0083】すなわち、表示器17の画面と対話する形式で処理が進行するものであり、まず、初期画面においてパスワードが入力されると(ステップ301)、基本メニューが表示された基本メニュー画面となる(ステップ302)。図3のフローではステップ203でパスワードを入力するようにしてもよい。
【0084】基本メニューの中から故障診断メニュー、ユーティリティのいずれかが選択される。ユーティリティが選択されるとユーティリティ画面となり(ステップ304)、必要に応じてパスワードを登録、変更するための画面に切り替えられる(ステップ305)。ステップ304では基準値事例集等のデータファイルメンテナンス機能を選択できるようにしてもよい。
【0085】故障診断メニューが選択されると、故障診断メニュー画面となり、通信機能、診断事例集による診断、モニタパネル診断サポートのいずれかを選択することができる(ステップ303)。」


<引用文献14>
特開平07-036729号公報(平成7年2月7日出願公開)

<引用文献記載事項14-1>
「【請求項1】 データ伝送装置に接続される各対象電子装置の不具合に対する復旧支援を行う復旧支援装置において、
前記対象電子装置の不具合発生時、前記データ伝送装置を介して送られてくる前記対象電子装置の不具合データを受信した後、当該不具合対象電子装置に関係する基板の診断情報をデータ送信処理手段を介して要求し、この要求に基づいて送られてくる前記不具合対象電子装置に関係する基板の診断情報を受信するデータ受信処理手段と、
このデータ受信処理手段によって受信された診断情報を採集し、前記不具合対象電子装置を構成する基板の種類ごとに格納する診断情報採集手段と、
この診断情報採集手段によって採集した診断情報を解析して原因を究明し、その故障原因と処置とを前記復旧支援画面表示部に表示する診断情報解析手段と、
を備えたことを特徴とする復旧支援装置。
【請求項2】 請求項1記載の復旧支援装置において、
予め種々の故障原因と処置とに対応する復旧手順が保存されている復旧手順保存手段と、前記不具合対象電子装置から採集されたプログラムを保存するプログラム保存手段と、前記診断情報解析手段で解析された故障原因と処置とから復旧手順を判定し、前記復旧手順保存手段から該当する復旧手順を読み出して復旧支援画面表示部に表示し、また復旧手順からプログラムのローディングが必要な場合には前記プログラム保存手段から該当プログラムを読み出して前記対象電子装置にダウンロードさせる指示を行う復旧手順判定処理手段とを付加したことを特徴とする復旧支援装置。
【請求項3】 請求項1記載の復旧支援装置において、
前記不具合対象電子装置から採集されたプログラムを保存するプログラム保存手段と、常に最新のプログラムを保存するために、定期的に前記各対象電子装置に各種基板の更新用プログラムを要求するプログラム更新要求手段と、このプログラム更新要求手段による更新用プログラムの要求データを送信するデータ送信処理手段と、このデータ送信処理手段の要求データに基づいて前記各対象電子装置側からデータ伝送ラインを介して送られてくる更新プログラムを前記データ受信処理手段で受信した後、前記プログラム保存手段の該当エリアに格納するプログラム更新処理手段とを付加し、
前記復旧手順判定処理手段における復旧処理時、前記プログラム保存手段から最新のプログラムを読み出してダウンロード可能にしたことを特徴とする復旧支援装置。」

<引用文献記載事項14-2>
「【0029】さらに、前記第3の復旧支援制御系では、前記PCメインプロセッサ(MMPU1形)基板にはプログラムのローディングが必要なことを表示するもので、「プログラムローディング」にタッチし、引き続き、「YES」にタッチすると、該当プログラムがローディングされて、ローディング完了時に完了のコメントが表示される。そして、(10)では表示の作業をすることにより、全ての復旧作業を完了させることができる。」


<引用文献15>
特開平07-305305号公報(平成7年11月21日出願公開)

<引用文献記載事項15-1>
「【請求項1】プラント操作盤の記憶部に操作盤における故障発生部位、故障の状況、故障発生要因を大分類、中分類、小分類に分類して故障検索項目とし、これらの故障検索項目をそれぞれ関連づけると共に階層構造として記憶させておき、操作盤に故障が発生した時には先ず操作盤の表示装置に大分類である操作盤の故障発生部位を表示させ、所定の故障発生部位を選択すると次いで中分類である故障の状況のうち関連する項目を表示させ、故障発生要因を特定可能な故障の状況を選択した時点で小分類の故障発生要因を表示装置に表示するようにしたことを特徴とするプラント操作盤の故障診断方法。」


3.引用発明の認定

(1)引用文献1は「医用装置の遠隔診断システム」を説明する文献であり、該「医用装置の遠隔診断システム」は、上記引用文献記載事項1-1のとおりの「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備える」ものである。

(2)上記引用文献記載事項1-2等からみて、「上記自己診断手段、異常判断手段、自動コール手段及び情報転送手段はコンピュータにより実現されて」いると言える。

(3)上記引用文献記載事項1-4、1-5には上記医用装置の「自己診断処理及び異常判断処理の具体例」として「画像再構成装置」と「X線高電圧装置」の診断例が開示されているところ、「画像再構成装置」に関しては、上記引用文献記載事項1-4から明らかなように、「構成演算装置にテスト用生データを用いた画像再構成を命じ」て得られる「画像」に基づいて診断及び判断が行われ、「X線高電圧装置」に対しては、上記引用文献記載事項1-5から明らかなように、その「管電流検出回路」や「管電圧検出回路」から上記「コンピュータ」に「供給」される「検出信号」に基づいて診断及び判断が行われる。
したがって、「上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、X線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われるもの」であると言える。

(4)引用文献記載事項1-7には「通常使用中にエラーが発生した場合、サービスセンタSへの自動コールの要、不要の判断をオペレータにさせるようにしてもよい。」、「オペレータの判断に応じて自動コールを行う手段を設けてもよい。即ち、オペレータが気付いた異常情報を入力させ、それらの情報をオペレータの操作に基づき自動コールし、転送するようにする。」との記載もあり、引用文献1からは、「上記自動コールは上記医療機器のオペレータの判断や該オペレータの操作に基づき行われるもの」である態様も読み取ることができる。

(5)上記引用文献記載事項1-2の『ステップ24では、異常データが有り、回復不能である旨の表示、例えば「……というエラーが発生しました。サービスセンタに連絡中です。」がスキャナ10a(?10n)のモニタに表示される。』との記載、上記引用文献記載事項1-4の「異常データが在る場合はその旨のモニタ表示・・・を行う。」、上記引用文献記載事項1-5の「この判断でYES(致命的なエラーである)の場合は、図2のステップ24?26の処理と同様に、モニタ表示、センタ自動コール及びデータ転送を行う。」「YES(エラー発生頻度が大きい)の判断が下されたときはモニタ表示、センタ自動コール及びデータ転送を行う。」との記載等から、上記「コンピュータ」は「モニタ」に上記「判断結果」の「モニタ表示」をさせていると言える。
また、引用文献記載事項1-3の『この対応内容の転送を受けたスキャナ10a(?10n)側のコンピュータは、ステップ34で、そのモニタに対応内容(例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」)を表示し、』との記載等から明らかなように、上記「コンピュータ」は「モニタ」に上記「修復するための指示」も表示させている。
したがって、「上記コンピュータは、さらに、モニタに上記判断結果のモニタ表示と上記修復するための指示の表示をさせる表示手段」を備えていると言える。

(6)さらに、引用文献記載事項1-3の『この対応内容の転送を受けたスキャナ10a(?10n)側のコンピュータは、ステップ34で、そのモニタに対応内容(例えば、「サービスセンタに連絡致しました。担当のサービスステーションからの連絡をお待ち下さい。」)を表示し、』との記載における「担当のサービスステーションからの連絡をお待ち下さい。」との指示はオペレータへの指示であることから、「上記モニタに表示される修復するための指示には上記オペレータへの指示も含まれて」いると言える。

(7)引用文献記載事項1-2の「まず、X線CTスキャナ10a(?10n)のコンピュータは、ステップ20において、通常の撮影処理を実施している。この実施中の適宜なタイミング(例えば、ある患者の撮影が完了して次ぎの患者の撮影に移る前)で、ステップ21の自己診断の処理を実行する。」との記載や、引用文献記載事項1-6の「また、これら一連の処理は、スキャナの通常使用のバックグラウンドでのソフトウエア処理としてもよい。」との記載等から、「これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである」態様も読みとれる。

(8)以上をまとめると、引用文献1には下記の引用発明1が記載されていると認められる。

<引用発明1>
「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システムにおいて、前記医用装置側には、自己の機能検査に関する診断プログラムを実行させる自己診断手段と、この自己診断手段の診断結果に基づいて自己の機能上の異常を判断する異常判断手段と、この異常判断手段により異常発生が判断されたときに、前記電話回線を介して前記管理装置に自動的に回線を繋ぐ自動コール手段と、この自動コール手段により回線が繋がると、上記自己診断手段の診断結果及び上記異常判断手段の判断結果を上記電話回線を介して前記センタに転送する情報転送手段とを備えると共に、前記管理装置側には、上記情報転送手段により転送されてくる情報に基づいて上記医用装置の異常を修復するための指示を行う修復指令手段を備える医用装置の遠隔診断システムであって
上記自己診断手段、異常判断手段、自動コール手段及び情報転送手段はコンピュータにより実現されており、
上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、X線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われるものであり、
上記自動コールは上記医療機器のオペレータの判断や該オペレータの操作に基づき行われるものであり、
上記コンピュータは、さらに、モニタに上記判断結果のモニタ表示と上記修復するための指示の表示をさせる表示手段を備えており、
上記モニタに表示される修復するための指示には上記オペレータへの指示も含まれており、
これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである
遠隔診断システム。」


4.対比
以下に、本願発明と引用発明1とを比較する。

(1)引用発明1は「サイトに据え付けられた医用装置と、上記サイトから離れて位置するセンタに据え付けられ且つ上記医用装置の保守点検を管理する管理装置とが電話回線を介して相互に通信可能に結ばれた、医用装置の遠隔診断システム」であるから、本願発明と同様に「医用モダリティの診断ネットワークシステム」と言えるものである。
また、引用発明1においては「上記診断及び判断は、上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、X線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われる」のであるから、引用発明1も「複数のデバイスと通信を行う」ものであると言える。
したがって、引用発明1と本願発明とは「複数のデバイスと通信を行う医用モダリティの診断ネットワークシステム」である点で共通する。

(2)引用発明1における「コンピュータ」は「上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、X線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて」「診断及び判断」を行うのであるから、該「再構成演算装置」や「X線高圧装置」と「通信」を行って言える。そしてその通信相手である「再構成演算装置」や「X線高圧装置」は「医用装置」即(すなわ)ち「医用モダリティ」の一部に外ならず「医用モダリティ内の通信手段」と言えるものである。また、該「コンピュータ」は「モニタに上記判断結果のモニタ表示」をさせるのであるから「モニタ」に関する処理を行う「ユニット」であるとも言える。
すなわち、引用発明1における「コンピュータ」は「上記医用モダリティ内の通信手段と通信を行うシステムモニタユニット」と言えるものである。
一方、本願発明における「システムモニタユニット」は、「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニットと通信を行う」ものであるところ、該「分散形試験ユニット」も「医用モダリティ内の通信手段」と言える。
したがって、引用発明1における「コンピュータ」と、本願発明における「システムモニタユニット」とは、「上記医用モダリティ内の通信手段と通信を行うシステムモニタユニット」と言えるものである点で共通する。

(3)引用発明1における「オペレータの操作」のための操作手段や、「修復するための指示」等が表示される「モニタ」は、本願発明における「ユーザインタフェース」に対応付けられるものであるところ、これらが「コンピュータ」と通信を行うことは明らかである。
また、該「モニタ」は、「判断結果のモニタ表示」も行うのであるから、「オペレータ」即(すなわ)ち「ユーザ」に、「再構成演算装置」や「X線高圧装置」即(すなわ)ち「上記医用モダリティ内の通信手段」と「通信」を行わせていると言える。
一方、本願発明における「ユーザインタフェース」は「前記システムモニタユニットと通信を行うとともにユーザに前記複数の分散形試験ユニットのそれぞれと通信を行わせる」ものであるところ、該「複数の分散形試験ユニット」も「上記医用モダリティ内の通信手段」と言えるものである。
したがって、引用発明1と本願発明とは、「前記システムモニタユニットと通信を行うとともにユーザに上記医用モダリティ内の通信手段と通信を行わせるユーザインタフェース」を備えている点で共通する。

(4)引用発明1における「上記医用装置の再構成演算装置」は「画像再構成を命じ」られるものであるところ、これは上記「コンピュータ」によりなされることは明らかであるから、上記「コンピュータ」は上記「医用装置」すなわち「医用モダリティ」内の「被制御手段」を制御するものであることも明らかである。
一方、本願発明における「システムモニタユニット」は「前記マスタ分散形試験ユニットを通して前記分散形試験ユニットを制御するもの」であるところ、該「分散形試験ユニット」も「上記医用モダリティ内の被制御手段」と言えるものである。
したがって、引用発明1と本願発明とは、「前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもの」である点でも共通する。

(5)
ア.引用発明1における「自己診断手段」は、本願発明における「コントロールユニット」に対応付けられ、引用発明1における「異常判断手段」「自動コール手段」「情報転送手段」「表示手段」は、本願発明における「診断ユニット」に対応付けられ、さらに、引用発明1における「異常判断手段」は、本願発明における「判定する手段」に、引用発明1における「表示手段」は、本願発明における「示す手段」に対応付けられる。

イ.引用発明1における「診断及び判断」は「上記医用装置の再構成演算装置に画像再構成を命じて得られる画像や、X線高圧装置の管電流検出手段や管電圧検出手段から上記コンピュータに供給される検出信号等に基づいて行われる」のであるから、「自己診断手段」がこれらの「画像」に関する情報や「検出信号」の収集とそのための制御をしていることは明らかであり、「前記動作状態に関する情報を収集するコントロールユニット」とも言える。

ウ.引用発明1における「異常判断手段」は、「自己診断手段の診断結果に基づいて自己の機能上の異常を判断する」ものであり、ここで「異常」と判断された場合には「異常を修復するための指示」を得るべく「自動コール」がなされるのであるから、「画像」に関する情報や「検出信号」等を「解析」して「点検修理が必要か否か」を判断しているとも言える。
また、引用発明1においては「これら一連の処理は、上記医用装置の通常使用の適宜なタイミングで通常使用のバックグラウンドでのソフトウエア処理として実行されるものである」から、「異常判断手段」における「判断」も「常時」なされている処理であると言える。
したがって、引用発明1における「異常判断手段」と、本願発明における「判定する手段」とは、「前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段」である点で共通する。

エ.引用発明1における「表示手段」が表示させる「修復するための指示」は「オペレータの判断や該オペレータの操作に基づき行われる」「自動コール」に対する応答であるから、「前記ユーザインタフェースとの通信に応じて」表示されるものであると言える。
また、該「自動コール」は「異常判断手段により異常発生が判断されたときに」なされるのであるから、これに応答する「修復するための指示」は「デバイスの内の点検修理が必要なデバイスについて」のものであることも明らかである。
さらに、該「修復するための指示」は、「オペレータへの指示も含まれて」いるものであり、このような「オペレータへの指示」も「点検修理の処理手順」と言える。
したがって、引用発明1における「表示手段」と、本願発明における「示す手段」とは、「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段」である点で共通する。
なお、引用文献1には「担当のサービスステーションからの連絡をお待ち下さい。」との指示しか例示されておらず、点検修理の対象となる機器に対する具体的な操作を指示する例は開示されていないが、オペレータによる操作で修復可能であるならば、その操作を指示することは当然になされることであり、仮に本願発明における「点検修理の処理手順」が該点検修理の対象となる機器に対する具体的な操作を指示することを意味していると仮定しても、これが本審決の結論に影響を与えるものではない。

オ.よって、引用発明1と本願発明とは、
「前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもので、
前記動作状態に関する情報を収集するコントロールユニットと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段とを有する診断ユニットと、を備えた」ものである点でも共通すると言える。


5.よって、本願発明は、下記一致点で引用発明1と一致し、下記相違点を有する点で引用発明1と相違する。

<一致点>
「複数のデバイスと通信を行う医用モダリティの診断ネットワークシステムにおいて、
上記医用モダリティ内の通信手段と通信を行うシステムモニタユニットと、
前記システムモニタユニットと通信を行うとともにユーザに上記医用モダリティ内の通信手段と通信を行わせるユーザインタフェースと、を備え、
前記システムモニタユニットは、上記医用モダリティ内の被制御手段を制御するもので、
前記動作状態に関する情報を収集するコントロールユニットと、
前記収集された情報を解析して前記複数のデバイスについて点検修理が必要か否かを常時、判定する手段と、前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについて点検修理の処理手順を示す手段とを有する診断ユニットと、を備えたことを特徴とする診断ネットワークシステム。」

<相違点1>
「前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと」、「マスタ分散形試験ユニットと」、「前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと」を備えており、
システムモニタユニットは「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニット」と通信を行い、かつ「前記マスタ分散形試験ユニットを通して前記分散形試験ユニット」を制御するものであり、
ユーザインタフェースはユーザに「前記複数の分散形試験ユニットのそれぞれ」と通信を行わせるものであり、
コントロールユニットは「前記複数の分散形試験ユニットから」前記動作状態に関する情報を収集するものである点。
(要約すれば、複数のデバイスとシステムモニタユニット間の情報の収集及び制御を、複数の分散形試験ユニットとマスタ分散形試験ユニットを接続したネットワークを介して行うものである点。)
(これに対して引用文献1には「分散形試験ユニット」「マスタ分散形試験ユニット」及びこれらを接続する「ネットワーク」に関する記載は無い。)

<相違点2>
「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」を備える点
(これに対し、引用発明1はこのようなデータベースを有していない。)

<相違点3>
点検修理の処理手順を示す手段が、点検修理が必要なデバイスについて「トラブルシューティングを行うのに必要なツール」も示すものである点。
(これに対して、引用発明1は「表示手段」や「自動コール手段」「情報転送手段」などの「トラブルシューティングを行うのに必要なツール」自体を有することは明らかであるが、これを「示」す旨の記載は、引用文献1には無い。)


6.判断
以下に、上記相違点について検討する。

(1)相違点1について
医療装置を構成する複数のデバイスごとに制御監視を行う処理手段を設けてこれらを通信手段で接続することは、例えば引用文献2?4記載の如く、古くから周知慣用の構成であり、係る構成を引用発明1における「医用装置」に採用することは、当業者であれば当然の如く想到する構成である。そして、複数の処理手段を接続する際に、該処理手段の一つをマスターとして動作させる構成も、当業者にとっては周知の一常套手段に過ぎない構成である(必要があれば引用文献2?4の他にも引用文献5?9(引用文献9は特に引用文献記載事項9-2)等も参照。)。
してみると、引用発明1の「医用装置」の構成として、「前記複数のデバイスの内の関連したそれぞれのデバイスと個別に通信を行って当該デバイスの動作状態に関する情報を常時、収集する複数の分散形試験ユニットと」、「マスタ分散形試験ユニットと」、「前記マスタ分散形試験ユニットおよび前記複数の分散形試験ユニットを通信媒体で相互に接続して情報の伝達を可能にしたネットワークと」を備えた構成を想起することは、当業者であれば当然の如くなし得る常識的な発想に過ぎないものである。
また、かかる構成すなわち「デバイス」と「コンピュータ」間に「分散形試験ユニット」と「マスタ分散形試験ユニット」を接続した「ネットワーク」が介在する構成を採用した場合には、引用発明1の「コンピュータ」が「前記マスタ分散形試験ユニットを経由して前記複数の分散形試験ユニット」と通信を行い、「前記マスタ分散形試験ユニットを通して前記分散形試験ユニット」を制御するものとなり、引用発明1の「モニタ」等がユーザに「前記複数の分散形試験ユニットのそれぞれ」と通信を行わせるものとなり、引用発明1の「自己診断手段」が「前記複数の分散形試験ユニットから」前記動作状態に関する情報を収集するものとなることは、必然的に採用される事項に外ならない。
したがって、引用発明1を上記相違点1に係る構成を有するものとすることは、当業者が容易に想到し得ることである。

(2)相違点2について
知識データベースを用いて診断等を行う技術(所謂エキスパートシステム)は、本願出願時においては当業者に周知の技術思想に過ぎないものである(必要があれば引用文献9?12等を参照。)から、引用発明1に、係るエキスパートシステムの採用を試みることも、当業者が普通に想起し得た設計事項に過ぎない。そして、その場合には、知識データベースが「前記複数の分散形試験ユニットから収集された前記動作情報に関する情報を基に編集された編集情報を格納するデータベース」となることは必定である。
したがって、引用発明1に上記相違点2にかかる構成を採用することも、当業者が普通に想起し得た事項に過ぎない。

(3)相違点3について
問題解決に何らかのツールを用いることが必要であれば、そのツールをメニュー等によって示すことも、当然の如く採用される周知慣用の設計事項である(必要があれば引用文献13?15等を参照。)。
そして、本願発明における「ツール」やこれを「示す」ことの技術的な意味は、上記第2.で述べたように必ずしも明確なものではないものの、該周知慣用の設計事項を採用して「ツール」を「示す」ことを包含するものと解釈することもできる。
したがって、引用発明1に上記相違点3にかかる構成を採用することも、当業者が必要に応じて適宜採用する設計事項にすぎない。

(4)してみると、本願発明の構成は引用文献1?15に記載された発明に基づいて、当業者が容易に想到し得たものである。
また、本願発明の効果は、当業者であれば容易に予測し得る程度のものであって、格別顕著なものではない。
よって、本願発明は、引用文献1?15に記載された発明に基づいて、当業者が容易に発明をすることができたものである。

(5)予備的判断
ア.請求人は、この拒絶理由に関連して、当審意見書の(4-3-1)において、「引用文献1には、点検修理が必要なデバイスについてトラブルシューティングを行なうために必要なツール及び点検修理の処理手順を示す手段の双方を有する診断ユニットを備えることは示されていない」との主張や、「引用文献2?12には」『「診断ユニットが複数のデバイスの内、点検修理が必要なデバイスについてトラブルシューティング行なうのに必要なツール及び点検修理の処理手順を示す手段の双方を有すること」を示したり、示唆する記載はない』との主張や、『この判断ユニットが、「トラブルシューティングを行なうのに必要なツールだけでなく、点検修理の処理手順の双方を示す手段」を双方を有することは、本願の出願当時、当業者が容易に発明し得る程度の設計事項であることは到底思わない。』との主張をしている。
当該主張は、本願発明が「必要なツール」と「点検修理の処理手順」の双方を「示す」ものであるとしていた原審よりの請求人の主張内容(上記第2.2.(1)イ.参照)と矛盾する主張ではあるものの、本願の特許請求の範囲の請求項1の記載は、当審意見書の主張の解釈、すなわち、「診断ユニット」は「ツール」を「有する」ユニットであり、かつ該「診断ユニット」は「手順を示す手段」をも「有する」ユニットであると解釈することも可能ではある。
しかしながら、引用文献1記載の「表示手段」や「自動コール手段」「情報転送手段」等は「トラブルシューティングを行うのに必要なツール」に外ならないものであるから、このような解釈をした場合であっても、上記相違点以外の相違点が生じるものではなく、この場合にも上記(4)と同様の判断結果が得られる。

イ.また、当審意見書の主張からは、本願発明の「点検修理の処理手順を示す」との記載は、単に点検修理の処理手順を実行する旨を表現しようと意図した記載とも推測可能である。しかしながら、引用文献1記載の「コンピュータ」が【図2】、【図3】、【図4】、【図6】等記載の処理手順を実行することは「点検修理の処理手順」を実行することに外ならないので、本願の特許請求の範囲の記載が該意図通りの記載に補正されたと仮定しても、上記相違点以外の相違点が生じるものではないので、この場合にも上記(4)と同様の判断結果が得られる。

ウ.なお、上記引用文献1?15はいずれも、本願の優先日よりも前に頒布された刊行物であるから、本願についての出願日の遡及が認められるか否かに関わらず、上記(4)の判断結果が得られる。


7.中結
以上の通り、本願請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。



第4.特許法第29条第2項(進歩性)について-その2

1.分割・国内優先権の主張の適否について
本願は、上記親出願の分割出願として出願されたものであるので、該分割が適法であるか否かについて検討する。

(1)本願の明細書等の記載内容
本願の特許請求の範囲及び明細書は、上記当審補正書により補正された特許請求の範囲及び明細書の記載のとおりのものと認められるところ、その特許請求の範囲の請求項1には、上記当審指摘の発明特定事項(すなわち「前記ユーザインタフェースとの通信に応じて前記複数のデバイスの内の点検修理が必要なデバイスについてトラブルシューティングを行うのに必要なツール及び点検修理の処理手順を示す手段とを有する診断ユニット」)が記載されており、また、明細書の発明の詳細な説明の段落【0015】にも該当審指摘の発明特定事項と同様の事項の記載がある。

(2)親出願の当初明細書等の記載内容
ア.親出願の願書に最初に添付した特許請求の範囲
上記親出願の願書に最初に添付した特許請求の範囲の記載は次の通りのものである。

「【請求項1】
複数のデバイスと通信を行う診断ネットワークシステムにおいて、
前記複数のデバイスの内の関連するデバイスと個別に通信を行う複数のプログラム可能な分散形試験ユニットと、
前記複数の分散形試験ユニットの間で情報を伝達させるネットワークと、
前記ネットワークを通して前記複数のプログラム可能な分散形試験ユニットと通信を行うシステムモニタユニットとを備え、
このシステムモニタユニットは前記複数のプログラム可能な分散形試験ユニットのそれぞれを選択した方法で機能させるようにプログラムした手段と、前記複数のプログラム可能な分散形試験ユニットにより得られた情報を予めプログラムしたように前記複数のデバイスから収集する手段と、前記複数のデバイスに対して当該複数のデバイスのユーザに合わせた最適化した性能データを維持する手段とを備えた診断ネットワークシステム。
【請求項2】
前記複数の分散形試験ユニットのそれぞれは、
前記システムモニタユニットによりプログラムされた標準化されたコントローラユニットと、
前記プログラムされたコントローラユニットにより制御され且つ前記複数のデバイスの内の該当するデバイスと通信を行うように適合させたサンプルコントロールモジュールと、
を備える請求項1記載の診断ネットワークシステム。
【請求項3】
前記ネットワークは、前記複数の分散形試験ユニットを互いに接続する光ネットワークを備える請求項2記載の診断ネットワークシステム。
【請求項4】
前記ネットワークは、前記複数のプログラム可能な分散形試験ユニットがループ状に直列に接続された光ネットワークを備える請求項2記載の診断ネットワークシステム。
【請求項5】
前記複数のプログラム可能な分散形試験ユニットの一つはマスタ分散形試験ユニットであり、このマスタ分散形試験ユニットを通して前記システムモニタが残りの前記複数のプログラム可能な分散形試験ユニットと通信を行う構成を有し、さらに、前記ネットワーク上で情報の伝達を行う順序は前記マスタ分散形試験ユニットから始まりかつ終わるようになっている請求項1記載の診断ネットワークシステム。
【請求項6】
前記複数のプログラム可能な分散形試験ユニットのそれぞれは、上流のプログラム可能な分散形試験ユニットから情報を受け、その受けた情報の選択部分を前記一つのプログラム可能な分散形試験ユニットで発生した情報と共に下流のプログラム可能な分散形試験ユニットにリレーする手段を含む請求項4記載の診断ネットワークシステム。
【請求項7】
前記複数のデバイスは当該各デバイスの機能を診断するための試験位置を有し、さらに前記複数のプログラム可能な分散形試験ユニットのそれぞれは前記試験位置で前記各デバイスの機能に関する情報をモニタする手段を含む請求項2記載の診断ネットワークシステム。
【請求項8】
前記複数のデバイスは当該各デバイスの機能を診断するための試験位置を有し、さらに前記複数のプログラム可能な分散形試験ユニットのそれぞれは前記試験位置における前記各デバイスの機能に関する制御量が所定値に維持されるように当該試験位置でその値を制御する手段を含む請求項2記載の診断ネットワークシステム。
【請求項9】
前記システムモニタユニットからプログラム可能な分散形試験ユニットに伝達される前記情報はデバイス制御命令を含み、さらに前記制御手段は前記デバイス制御命令にしたがって前記デバイスを制御することによって前記試験位置における前記制御量を前記デバイス制御命令による指定値に保持する手段である請求項8記載の診断ネットワークシステム。」

イ.親出願の当初明細、図面
親出願の願書に最初に添付した明細書の記載内容は、その段落【0015】の記載内容が下記の通りのものである点で、本願明細書と相違しているが、他の箇所の記載に関しては、その記載順序や用語等が若干相違するのみで、実質的な相違は認められない。
また、図面に関しても実質的な相違は認められない。

「【0015】
本発明に係る診断ネットワークシステムは、複数のデバイスと通信を行うシステムであり、このシステムは、前記複数のデバイスの内の関連する各1つのデバイスと個別に通信を行う複数の分散形試験ユニット(DTUs)、マスタDTU、マスタDTUおよび複数のDTUの間で情報の伝達をさせるネットワーク、およびマスタDTUを通して複数のDTUと通信を行うシステムモニタユニットを備える。このシステムモニタユニットは、複数のDTUから情報を集めるコントロールユニット、複数のDTUから集められた情報から編集された情報を格納しているデータベース、および、集められた情報を解析し、複数のデバイスの内の点検修理が必要な1つ以上のデバイスの動作状態を識別する診断ユニットを有する。」

(3)当審判断
ア.該当審指摘の発明特定事項が上記親出願の特許請求の範囲、明細書及び図面(以下「親出願の当初明細書等」と記す。)に記載した事項の範囲内にあるものであるか否かについて検討するに、当審指摘の発明特定事項は親出願の当初明細書等の何処にも見いだすことはできない。また、親出願の当初明細書等のすべての記載を総合しても当審指摘の発明特定事項を導くことはできない。

イ.この点に関し、請求人は、上記当審意見書の【意見の内容】の(4-3-4)において、該発明特定事項が「本願の明細書の段落[0015]の他、[0059]?[0062],[0108]?[0110],[0118]?[0120]および図面の[図1],[図2],[図15],[図41][図42]に記載されている」旨を前提とし、「本件出願の明細書の段落[0059]?[0062],[0108]?[0110],[0118]?[0120]および図面の[図1],[図2],[図15],[図41],[図42]に相当する技術事項」が親出願の明細書の段落[0063]?[0067],[0112]?[0114],[0122]?[0124]および図面の[図1],[図2],[図15],[図41],[図42]とが「同一であり、異なるところはない」ことを根拠に、当審指摘の発明特定事項が親出願の明細書および図面に記載されている旨主張している。
しかしながら、当審指摘の発明特定事項が本願の明細書に記載されていないことは、上記第2.で述べた通りであるから、該請求人の主張の前提は妥当でない。
しかも、親出願の当初明細書等において本願明細書と相違する部分であるところの上記親出願の願書に最初に添付した特許請求の範囲にも、同明細書の段落【0015】にも、当審指摘の発明特定事項が記載も示唆もされていないことは明らかである。
してみると、該請求人の主張を考慮しても当審指摘の発明特定事項が親出願の明細書および図面に記載されている旨の主張は到底認め得るものではない。

ウ.したがって、本願は、親出願の当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において新たな事項を導入する出願であり、親出願の出願当初の明細書又は図面に記載した事項の範囲内にない事項を含むことは明らかである。

(4)小結
よって、本願は、親出願の一部を一又は二以上の新たな特許出願とするものと認め得るものではなく、出願日の遡及を認めることのできないものである。
したがって、本願の出願日は現実の平成21年9月1日となる。

また、このため、上記国内優先権基礎出願に基づく優先権の主張を認めることもできない。


2.引用文献・引用発明

(1)上記1.の通りであるから、下記引用文献もその出願前に日本国内又は外国において頒布された刊行物となる。

<引用文献16>特開平09-168533号公報(平成9年6月30日
出願公開。上記第1.1.(1)記載の取り下げられた国内優先権の主張にかかる出願(特願平08-182603号)の公開公報。)

<引用文献17>特開平09-168532号公報(平成9年6月30日
出願公開。上記国内優先権基礎出願(特願平08-182602号)の公開公報。)

<引用文献18>
特開平10-083315号公報(平成10年3月31日出願公開。祖父出願(特願平09-149496号)の公開公報。)

<引用文献19>
特開2007-026450号公報(平成19年2月1日出願公開。親出願(特願平09-149496号)の公開公報。)

<引用文献20>
米国特許第6487513号明細書(2002年11月26日発行。上記第一国出願(出願番号:08/484660)の特許明細書。)

(2)上記引用文献16?20のいずれの文献にも、本願請求項1記載の発明特定事項のうち、上記第2.及び上記1.で検討した当審指摘の発明特定事項以外の事項を備える診断ネットワークシステム(以下、「引用発明2」と記す)が記載されていると認められる。


3.本願発明の認定・対比・判断
本願発明は上記上記第1.2.(2)の【請求項1】として記載及び上記第3.1.に再掲したとおりのものである。
本願発明と引用発明2とを比較すると、前者においては、上記当審指摘の発明特定事項を備える点で後者と相違し、その余の点では両者は一致する。
しかしながら、トラブルシューティングを行うのに必要なツールや点検修理の処理手順を示すことは、従来から適宜に採用されている周知慣用技術である(必要があれば引用文献9?15等参照)から、引用発明2に該周知慣用技術を付加して本願発明をなすことも、当業者が容易になし得たことである。
したがって、本願発明は、引用文献9?20に記載された発明に基づいても、当業者が容易に発明をすることができたものである。


4.中結
以上の通り、本願請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものである。



第5.むすび

上記第2.のとおり、本願は、明細書及び特許請求の範囲の記載が、特許法第36条第4項第1号及び第6項第1号、第2号に規定する要件を満たしていないものであるから、特許を受けることができない。

上記第3.、及び、第4.のとおり、本願請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、当業者が容易に発明をすることができたものであるから、他の請求項についての検討をするまでもなく、本願は、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する
 
審理終結日 2011-12-06 
結審通知日 2011-12-13 
審決日 2012-01-06 
出願番号 特願2009-201847(P2009-201847)
審決分類 P 1 8・ 537- WZ (A61B)
P 1 8・ 536- WZ (A61B)
P 1 8・ 121- WZ (A61B)
最終処分 不成立  
前審関与審査官 多胡 滋  
特許庁審判長 山崎 達也
特許庁審判官 石井 茂和
殿川 雅也
発明の名称 診断ネットワークシステム  
代理人 特許業務法人東京国際特許事務所  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ