【事件の表示】
　特願２００１−１８８７９８「画像形成装置、画像形成装置の管理システム、プログラム及びコンピュータ読み取り可能な記録媒体」拒絶査定不服審判事件〔平成１５年　１月１０日出願公開、特開２００３−　　８８１０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１３年６月２１日の出願であって、平成１５年１２月８日付け拒絶理由通知に対して平成１６年２月１６日付けで手続補正がなされ、これに対して平成１６年８月１９日に拒絶査定がされ、これに対して平成１６年９月３０日に拒絶査定不服審判が請求されたものである。 
　
２．本願発明の認定
  本願の発明は、平成１６年２月１６日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１から請求項８までに記載した事項により特定されるとおりのものと認められるところ、そのうち、請求項７に係る発明は、下記のとおりである。
　
　【請求項７】　故障管理用ホストコンピュータに、
　画像形成装置から送信された故障検出データを受信すると、その故障検出データを故障管理リストに書き込んで故障管理リストを更新する第１ステップと、
　その更新された故障管理リストを表示手段に表示させるとともに、その故障管理リストのステータスを未処理にする第２ステップと、
　入力手段から故障検出データを受け付けたことを示す受付信号が入力されると、前記ステータスを受付に変更するとともに、その受付信号を前記画像形成装置に送信する第３ステップと、
　前記画像形成装置から送信された故障処理済み信号を受信すると、前記ステータスを処理済みに変更する第４ステップと、
　を実行させるためのプログラム。
　　（以下、これを「本願発明」という。）
　
３．引用刊行物記載の発明 
　
　原査定の拒絶の理由で引用された刊行物１（特開平１１−２３９２３９号公報）には、以下（ア）から（オ）に示す事項が記載されている。
　
『（ア）複数の複写装置等の画像形成装置とセンタシステムとがデータ通信装置及び通信回線を介して接続され、前記各画像形成装置がそれぞれ、通報要因が発生したとき、その旨を示す情報を前記データ通信装置及び前記通信回線を介して前記センタシステムへ自動通報する通報手段を備えた画像形成装置管理システムにおいて、
　前記センタシステムは、複数の端末装置を備え、
　その各端末装置がそれぞれ、前記各画像形成装置から前記データ通信装置及び前記通信回線を介して自動通報される各種情報を共通に一覧表示する一覧表示手段と、該手段によって一覧表示された各種情報のいずれかを処理対象として選択する情報選択手段とを有することを特徴とする画像形成装置管理システム。　　　（請求項１）
　
（イ）請求項１記載の画像形成装置管理システムにおいて、
　前記各端末装置がそれぞれ、前記一覧表示手段によって一覧表示された各種情報のいずれかに対してサービスマン手配済みを入力する手配済み入力手段と、前記一覧表示手段によって一覧表示された各種情報のいずれかに対して他の端末装置でサービスマン手配済みが入力された場合には、該情報に対してサービスマン手配済みである旨を表示する手配済み表示手段とを有することを特徴とする画像形成装置管理システム。　（請求項３）
　
（ウ）図１３は、画像形成装置１〜５における故障時自動通報処理の一例を示すフローチャートである。
　画像形成装置１〜５は、それぞれステップ１で故障（通報要因）の発生を検知したら、ステップ２でその旨を示す情報をデータ通信装置７及び通信回線８を介してセンタシステム６へ通報する通報処理を行なう。
　
　次に、ステップ３で発生した故障（通報要因）をレベル分けし、そのレベルが（略）「ａ−２（自動通報中等の自動通報に関するメッセージを表示させる）」のレベルであるかを判断し、（略）
　一方、「ａ−２」のレベルであれば、ステップ５で当該故障のため自動通報中であることを操作表示部の文字表示器８３に表示させて顧客に知らせ、ステップ６又は７で当該通報の成功／失敗が判明した時点で、ステップ８又は９でその結果を操作表示部の文字表示器８３に表示させて顧客に知らせる。したがって、顧客はその表示内容を見て次の行動に移れることになる。　　　　　（段落００７５〜００７７）
　
（エ）ここで、特定の機能のみが使用できない故障とは、例えば両面トレイ，原稿送り部，転写紙後処理部等の故障に相当する。
　図１５は、画像形成装置１〜５における特定機能故障時自動通報処理の一例を示すフローチャートである。
　
　例えば、両面トレイの故障時には当該トレイを使用する両面モード（特定の機能）は選択できないため、当該故障が発生した時にたまたま両面モードによる画像形成動作を実行していたときは、当該故障の発生を示す情報をセンタシステム６へ自動通報する（ステップ２２）と同時に、画像形成動作を中断（禁止）させて故障のため自動通報中であることを操作表示部の文字表示器８３に表示させ（ステップ２５）、顧客に当該故障の発生を知らせる。　（段落００８４〜００８５）
　
（オ）図１７は、各クライアント１１０の構成例を示すブロック図である。
　各クライアント１１０はそれぞれ、コンピュータ１１１，表示装置１１２，入力装置（キーボード及びマウス）１１３，プリンタ１１４，外部記憶装置１１５，及びＬＡＮ装置１１６等からなる。
　図１８は、サーバ１２０の構成例を示すブロック図である。
　
　サーバ１２０は、コンピュータ１２１，データファイル（大容量記憶装置）１２２，表示装置１２３，入力装置（キーボード及びマウス）１２４，プリンタ１２５，外部記憶装置１２６，及びＬＡＮ装置１２７等からなる。
　データファイル１２２には、例えば図１９に示すようなデータベースが格納されている。
　
　このデータベースに格納されている各情報にはそれぞれ、お客様情報（住所，電話番号，担当者名等），サービス情報（サービス担当会社名，電話番号，住所，担当者名，機械の今までの経歴等），ログ情報（機械の各種内部情報，各種カウンタ情報）等が含まれている。
　
　ここで、各クライアント１１０は、請求項１〜４の一覧表示手段，情報選択手段，処理中表示手段，手配済み入力手段，及び手配済み表示手段としての機能を果たす。　　　　　　　　　　　　　　　　　　　　（段落００９５〜００９８）
　
（カ）センタシステム６の各クライアント１１０はそれぞれ、以下の（１）〜（１１）に示す処理を行なう。
　（１）画像形成装置群１０１からデータ通信装置７，通信回線８，構内交換機１０２，及びモデム１０３を介して自動通報される各種情報を共通に一覧表示する。つまり、画像形成装置群１０１から自動通報される情報は順次データファイル１２２内のデータベース（図１９参照）に書き込む。また、パイプ（ＰＩＰＥ）機能を使用し、クライアント単位に一定時間（例えば１分）毎にデータファイル１２２から各種情報を読み込み、表示装置１１２の画面を表示し直す。
　
　ここで、各クライアント１１０のオペレータは（略）、修理する必要があれば選択した情報に対して入力装置１１３によりサービスマン手配済みを入力すると共に、サービスマンを実際に手配する。
　
　手配されたサービスマンは、ユーザの画像形成装置の修理（作業）を開始する時と完了した時に、その旨を電話等で対応するクライアント１１０のオペレータに連絡する。サービスマンから作業の開始又は完了の連絡を受けたオペレータは、入力装置１１３の操作によって作業開始情報又は作業完了情報を入力する。あるいは、サービスマンは画像形成装置に備えられている作業開始キー又は作業完了キーの押下によって作業開始情報又は作業完了情報を対応するクライアント１１０に自動通報させる。
　
　（２）自機のオペレータによって未処理の情報が選択されると、システム立ち上げ時に登録されたそのオペレータの名前（担当者名）と処理中である旨（ここでは「処理中」の文字列とする）をデータファイル１２２（データベース）内の該当するレコードに書き込んでそのレコードを更新し、処理を行なっているオペレータの名前が判るようにする。
　
　　　（略）
　（５）自機で選択された情報に対してサービスマン手配済みが入力されると、データファイル１２２内の該当するレコードの「処理中」を「手配中（オペレータ手配済みを示す）」に書き換える。このとき、サービスマン手配済みが入力された時刻をサービスマンの手配（依頼）時刻としてデータファイル１２２内の該当するレコードの手配時刻の欄に書き込んでもよい。
　　　（略）
　（８）図２１の「メニュー」が指定されると、例えば図２２の（ａ）に示すように、「未手配情報一覧」「手配済み情報一覧」「受信情報一覧」をサブウィンドウで表示する。そして、「未手配情報一覧」が指定された場合には、表示画面を同図の（ｂ）に示す未手配情報のみの一覧表示に切り替える。「手配済み情報一覧」が指定された場合には、表示画面を同図の（ｃ）に示す手配済み情報のみの一覧表示に切り替える。
　（９）表示画面の「処理中」を含む情報に対して、オペレータによって処理完了情報が入力された時、あるいはユーザの画像形成装置から作業完了情報が通報された時には、その「処理中」を含む情報を消去する。　　　　　　　（段落０１００〜０１１０）　』
　
　また、刊行物１の記載全体から、当該刊行物に記載されている装置はコンピュータで制御されるものであり、プログラム動作することは自明である。
　
　したがって、これらを総合すれば、原査定の拒絶の理由で引用された刊行物１には、次の発明が記載されている。（以下、「引用例発明」という。）
  　
（サ）画像形成装置は特定機能故障時に異常内容をクライアントに自動通報するものであり、クライアント側では画像形成装置から送信された故障検出データを受信すると、その故障検出データを故障管理リストに書き込んで故障管理リストを更新し、レコードを「処理中」として各種情報を一覧リストを表示するとともに、サービスマン手配済みが入力されると、レコードを「手配中」に書き換え、「作業完了情報」が入力あるいは通報されると「処理中」を含む情報が消去されるものであって、
　画像形成装置の画面には故障の自動通報中において「通報の成功／失敗」が識別可能に表示する制御を行うプログラム。
　
４．本願発明と引用例発明との対比
　 
　本願発明における構成要件と引用例発明における構成要件を対比すると、複数の画像形成装置の故障状態を遠隔管理する意味において、引用例発明における「クライアント」は、本願発明における「故障管理用ホストコンピュータ」に相当する。
　また、引用例発明における「レコード」は、例えば、「処理中」であることとともにオペレータの名前をも記憶する（上記３．（カ）参照）領域を意味し、本願発明における「ステータス」とは同義ではないが、「レコード」は、故障した画像形成装置の通報に対する対応状況を示す情報を記憶するという点において、レコードの内容の一部がステータスを意味することになる。
　また、引用例発明における「処理中」「手配中」は、「自機で選択された情報に対してサービスマン手配済みが入力されると、データファイル１２２内の該当するレコードの「処理中」を「手配中（オペレータ手配済みを示す）」に書き換える。（上記３．（カ）参照）」の記載から、本願発明における「未処理」「受付」に相当するものである。
　
　したがって、本願発明と引用例発明とを対比すると、 
　 両者は、
「故障管理用ホストコンピュータに、
　画像形成装置から送信された故障検出データを受信すると、その故障検出データを故障管理リストに書き込んで故障管理リストを更新するステップと、
　その更新された故障管理リストを表示手段に表示させるとともに、その故障管理リストのステータスを未処理にするステップと、
　入力手段から故障検出データを受け付けたことを示す受付信号が入力されると、前記ステータスを受付に変更するとともに、
　前記画像形成装置から送信された故障処理済み信号を受信すると、処理済みの処理を行うステップを実行するプログラム。」 
 である点で一致し、次の（タ）、（チ）の点で一応の相違がある。 
　
（タ）本願発明が、「入力手段から故障検出データを受け付けたことを示す受付信号が入力されると、その受付信号を前記画像形成装置に送信する」ものであって、画像形成装置が受付られてことを表示するのに対し、引用例発明は、「通報の成功／失敗」が表示されるものである点。
（チ）画像形成装置から送信された故障処理済み信号を受信した際の処理済み処理が、本願発明では「ステータスを処理済みに変更する」ものであるのに対し、引用例発明では「処理中を含む情報が消去される」ものである点。
　
５．相違点の判断 
　
　上記相違点（タ）について検討する。 
　故障検出データが受け付けられたこと、故障の連絡が確実に成功したことの確認という点において、すなわちが画像形成装置で確認できることについて両者は同様の意味をもつ。　すなわち、引用例発明における画像形成装置は、「通報の成功／失敗」が表示されるものであるが、これは受信側で故障情報を受け取り確認したことに対して表示するものであって、故障情報の受取が完了していなければ「通報の成功」にはならないから、クライアント側から「成功」を示す情報を送信していることは自明である。
　したがって、両者の差異は、本願発明が「入力手段から」オペレータによって受付信号が入力されるものであり（段落００３５）、引用例発明は「通報の成功」にオペレータが関与してるか否か不明である点にある。
　しかしながら、通信回線を介して故障対処依頼があった場合に、依頼の受け付けを受付者が確認して、受け付けた旨を依頼者に送信することは、故障に対処する場合に通常行われている周知事項である。
　例えば、ファクシミリで故障依頼があった際に、担当者がサービスマンの手配を確認し、操作（入力と等価である）により、手配確定をファクシミリで自動返送する技術事項が特開２０００−２４４６９３号公報に記載されている。
　すなわち、故障検出データが受け付けられた際に、入力により受付信号を故障データ送出元へ送信すること自体は周知技術であるから、故障検出データが自動的に送信されるものにおいても、故障データ受信側で、入力により受付信号を送信するようにすることは、当業者が容易に想到できることである。
　
　上記相違点（チ）について検討する。 
　本願発明も引用発明も、未処理の情報が修理完了により、そのステータスが変更される点において相違するものではない。
　本願発明における「ステータスを処理済みに変更する」は、ステータスを変更した上で情報がそのまま表示されたままであるとも読み取れ、一方で引用例発明における「処理中を含む情報が消去される」は、故障受付し、その後ステータスが変更された情報を全て消去するとも読み取れ、両者にニュアンスの違いとしての相違はある。
　しかしながら、それは故障修理済みの履歴を残すか否かの違いであり、表示として残したままにするか、表示としては消去し別途処理済みデータをして別途保存するか、完全に消去するかは、そのいずれも周知のデータ管理の選択の問題であって、仮に両者に相違があるとしても、これは当業者における設計的事項の違いでしかない。
　
　そして、これら相違点を総合的に考慮しても当業者が想到し難い格別のものであるとすることはできず、本願発明の効果についてみても、上記構成の採用に伴って当然に予測される程度のものにすぎず、格別顕著なものがあるともいえない。
　
６．むすび
　
　以上のとおり、本願発明は、刊行物１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、残る請求項１から請求項６および請求項８に係る各発明について特に検討するまでもなく、本願は拒絶をすべきものである。 
　よって、結論のとおり審決する。