【事件の表示】
　平成　９年特許願第２０５７１８号「データ処理装置および印刷システムおよび状態監視方法およびコンピュータが読み取り可能な記憶媒体」拒絶査定不服審判事件〔平成１１年　２月２６日出願公開、特開平１１−　５３１３０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は平成９年７月３１日の出願であって、平成１４年８月１２日付で拒絶査定がなされ、これに対して平成１４年９月１９日に拒絶査定に対する審判が請求されるとともに、同年１０月２１日付で手続補正がなされたものである。
　
２．平成１４年１０月２１日付手続補正（以下「本件補正」という。）について
｛補正却下の決定の結論｝平成１４年１０月２１日付の手続補正を却下する。
｛理由｝
　本件補正後の特許請求の範囲の少なくとも請求項１は次のとおり補正された。
「所定の通信媒体を介して印刷装置とパケット通信可能なデータ処理装置であって、
　アプリケーションからのデータを所定のプリント言語に基づく印刷データに変換する変換手段と、
　前記変換手段により変換された印刷データと通知先アドレスとを含む印刷ジョブを通信モジュールを介して前記印刷装置に送信する送信手段と、
　前記印刷装置の状態を要求する印刷状態要求パケットを生成して、前記通信モジュールから取得したアドレスに基づいて前記印刷状態要求パケットを前記印刷装置に送信し、前記印刷装置から受信するパケットを解析して前記印刷装置の状態を監視し、前記印刷装置の状態を表示部に表示する監視手段と、
　ユーザからの印刷要求後、前記印刷装置の状態の監視を前記監視手段に行わせ、印刷終了を示すパケットが受信された後、前記印刷装置の状態の監視を前記監視手段に終了させる制御手段とを有し、
　前記印刷装置は、送信された印刷ジョブに含まれている通知先アドレスに従って前記データ処理装置にパケットを送信することを特徴とするデータ処理装置。」
　
　上記補正は、補正前の請求項１に記載した発明の「印刷ジョブを前記印刷装置に送信する送信手段」を「印刷ジョブを
通信モジュールを介して
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するか）について以下に検討する。
　
（１）引用刊行物
１）原査定の拒絶の理由に引用された、本願の出願日前に頒布された刊行物「特開平６−２４２９０１号公報」（以下「引用刊行物１」という。）には「リモート印刷システム」の発明に関して、図面とともに以下の記載がある。
（ア）「【００３４】本発明の第１の目的は、上記問題を解決するために、プリントサーバが、クライアントに対して、印刷ジョブが印刷待ち状態であるか否か等のキューの状態，プリンタがオンライン状態であるか現在何ページを印刷中であるか等のプリンタの状態を送信できるようにすることにある。
【００３５】本発明の第２の目的は、クライアントが、キューの状態やプリンタの状態を監視できるようにし、離れた場所にあるプリンタでの印刷終了やエラーの発生等を認識することができるようにすることにある。」（第５頁左欄第３４−４３行）
　
（イ）「【００５２】
【実施例】以下、本発明の実施例について図面を参照して説明する。
【００５３】まず、本発明の第１の実施例について、図３〜図８を用いて説明する。
【００５４】図３は本発明の第１の実施例のリモート印刷システムの構成図である。
【００５５】図３の例では、クライアント３２０が、・・・プリントサーバ３１０に接続されたプリンタ３３０を、ＬＡＮ３００に接続された他のクライアントと共有して印刷を行う例を示している。・・・
【００５６】また、図３では、ＬＡＮ３００に接続されたプリントサーバ３１０，クライアント３２０を、それぞれ１台のみ示し、他のクライアントおよびプリントサーバについては省略している。・・・
【００５７】クライアント３２０は、プリントサーバ３１０に印刷を依頼してプリンタ３３０へのリモート印刷を行うホストであり、印刷ジョブを生成する印刷プロセス３２８と、・・・他のホストとの間の通信を制御するネットワーク通信部３２１と、印刷ジョブをプリントサーバ３１０に送信する印刷ジョブ送信部３２２と、さらに、プリントサーバ３１０における印刷ジョブの待ち行列であるキュー３１４の状態およびプリンタ３３０の状態を監視するキュー／プリンタ状態監視部３２５と、予め決められた一定時間ごとに、キュー／プリンタ状態監視部３２５を起動するためのタイマ３２４と、キュー３１４の状態およびプリンタ３３０の状態を解析し、エラー要因を検出するエラー検出部３２６と、検出されたエラー要因に応じた処理を行うエラー処理部３２７とから構成されている。
【００５８】一方、プリントサーバ３１０は、クライアント３２０からの印刷要求を受け付け、プリンタ３３０で印刷を行うホストであり、他のホストとの間の通信を制御するネットワーク通信部３１１と、クライアント３２０から送信された印刷ジョブを受信する印刷ジョブ受信部３１２と、印刷ジョブの待ち行列であるキュー３１４と、キュー３１４への印刷ジョブの格納および削除を行うキュー管理部３１３と、プリンタ３３０への印刷を行う印刷制御部３１８と、さらに、プリンタ３３０の状態を監視するプリンタ監視部３１９と、プリンタ３３０の状態であるプリンタ管理情報３１６を記憶するプリンタ状態管理部３１５と、キュー３１４の状態およびプリンタ管理情報３１６をコード化してクライアント３２０に送信するキュー／プリンタ状態送信部３１７とから構成されている。」（第６頁右欄第３４行−第７頁左欄第４１行）
　
（ウ）「【００６３】送信キュー３６０に印刷ジョブが格納されると、印刷ジョブ送信部３２２が、送信キュー３６０から印刷ジョブを読み出し、指定されたプリンタ３３０にファイル３５１を印刷するためにはどのホストに印刷ジョブを送信すべきかを判定し、ネットワーク通信部３２１を通して、判定したホスト（プリントサーバ３１０）に印刷ジョブのコピーを送信する。なお、印刷ジョブ送信部３２２は、送信キュー３６０に格納されている全ての印刷ジョブをキュー３６０の先頭から順に送信する。また、ネットワーク通信部３２１は、ネットワークに対応したプロトコル処理を行って、ＬＡＮ３００に接続されている他のホストとの間通信を制御するものである。その後、印刷ジョブ送信部３２２は、ネットワーク通信部３２１を通して、プリントサーバ３１０からの受信確認応答を受信すると、受信が確認された印刷ジョブを送信キュー３６０から取り出して、印刷終了キュー３６１に格納し、送信処理を終了する。」（第７頁右欄第１３−２９行）
　
（エ）「【００８３】一方、クライアント３２０においては、タイマ３２４は、印刷ジョブ送信部３２２が印刷ジョブを送信した後、予め決められた一定時間ごとに、キュー／プリンタ状態監視部３２５を起動する。キュー／プリンタ状態監視部３２５は、プリンタ３３０のプリンタ名、および印刷ジョブ格納領域３２３の印刷終了キュー３６１に格納されている印刷ジョブのジョブ名を記述したキュー／プリンタ状態要求コマンド４１０を生成し、プリントサーバ３１０に送信する。
【００８４】プリントサーバ３１０においては、キュー／プリンタ状態送信部３１７は、クライアント３２０からのキュー／プリンタ状態要求コマンド４１０を受信すると、キュー／プリンタ状態要求コマンド４１０に記述されたプリンタ３３０に対応するプリンタ管理情報３１６、および、キュー／プリンタ状態要求コマンド４１０に記述された印刷ジョブに対応するキュー３１４の状態を読み出し、これらの情報をコード化してキュー／プリンタ状態応答４２０を生成し、クライアント３２０に返送する。
【００８５】クライアント３２０においては、プリントサーバ３１０からのキュー／プリンタ状態監視部３２５は、キュー／プリンタ状態応答４２０を受信すると、キュー／プリンタ状態応答４２０に記述されたキュー／プリンタ状態コード４２４を解析し、キュー状態コード５０２が該当ジョブなしを示している場合に、印刷が終了したことを検出する。そして、印刷の終了を検出すると、印刷ジョブ格納領域３２３の印刷終了キュー３６１から印刷ジョブを削除し、ディスプレイに印刷終了を示すメッセージを表示するなどして、ユーザに印刷終了を報告する。
【００８６】また、キュー／プリンタ状態監視部３２５は、プリンタ状態報告内容コード５０５を解析した結果、エラーの発生を検出した場合は、エラー検出部３２６にエラーの発生を通知する。エラー検出部３２６は、エラーコード５１４を解析してエラー要因を検出し、エラー処理部３２７は、検出されたエラー要因に応じた処理を行う。この処理は、例えば、ディスプレイにエラーの発生および要因を示すメッセージを表示したり、印刷ジョブをプリントサーバ３１０に再送信したり、印刷再実行等のエラー回復処理をプリントサーバ３１０に指示するメッセージを送信したりといった処理である。」（第８頁右欄第４２行−第９頁左欄第３２行）
　
（オ）「【００８７】図７に、クライアント３２０およびプリントサーバ３１０の動作、並びに、ＬＡＮ３００上を転送されるメッセージのシーケンスを示す。
・・・
【００８９】一方、クライアント３２０においては、タイマ３２４が、印刷ジョブの送信を終了した後、予め決められた一定時間ごとに、キュー／プリンタ状態監視部３２５を起動し、キュー／プリンタ状態監視部３２５が、プリントサーバ３１０にキュー／プリンタ状態要求コマンド７１２，７１４，７１６を送信して、キュー３１４の状態およびプリンタ３３０の状態を監視する（Ｓ７０２）。
【００９０】プリントサーバ３１０においては、キュー／プリンタ状態送信部３１７が、クライアント３２０からのキュー／プリンタ状態要求コマンド７１２，７１４，７１６を受信すると、クライアント３２０にキュー／プリンタ状態応答７１３，７１５，７１７を返送する（Ｓ７０７，Ｓ７０８，Ｓ７０９）。
【００９１】ここで、正常に印刷が実行された場合、クライアント３２０においては、キュー／プリンタ状態監視部３２５が、印刷の実行が終了した後に最初に返送されたキュー／プリンタ状態応答７１７によって、印刷が終了したことを検出し（Ｓ７０３）、ユーザに印刷の終了を報告して処理を終了する。」（第９頁左欄第３３行−右欄第１７行）
　
２）同じく、原査定の拒絶の理由に引用された、本願の出願日前に頒布された刊行物「特開平６−８３５５１号公報」（以下「引用刊行物２」という。）には「プリントサーバシステムにおける印刷制御方法」の発明に関して、図面とともに以下の記載がある。
（カ）「【０００６】そこで、本発明の目的は、印刷要求元（ユーザ）に、自分の要求した印刷作業が終了したときはその印刷終了を、また印刷作業中にエラーが発生した場合にはそのエラー発生を自動的に通知できるようにすることにある。」（第２頁右欄第１９−２３行）
　
（キ）「【００１１】図２は、ホスト装置１１からプリントサーバシステム１０へ伝送される印刷データの一例を示す。該印刷データは、ユーザが発行する１回の印刷要求に対する全データを単位として扱うもので、プリントサーバアドレス、ホスト装置アドレス、印刷情報ヘッダ及び印刷情報からなる。・・・印刷情報は、文字情報やビットイメージ情報やグラフィック情報などの具体的な印刷画像情報である。印刷情報ヘッダと印刷情報とは対になっており、印刷データは複数の印刷情報ヘッダと印刷情報からなる場合もある。
【００１２】通信制御部１３で受信された印刷データは、主制御部１４の制御に従い磁気ディスク装置１５に一旦格納される。主制御部１４は、複数の印刷データが磁気ディスク装置１５に格納されている場合、格納した順番に読み出しを行えるように、印刷データをテーブルで管理する。図３にその管理テーブルの構成例を示す。この管理テーブルには、印刷データの格納順序を示すポインタと共に、印刷データの印刷要求元であるホスト装置アドレス及びユーザＩＤも格納する。また、印刷データがどの状態（待ち状態や印刷中など）であるかを示すフラグも、この管理テーブルで管理される。」（第３頁左欄第７−３１行）
　
（ク）「【００１５】主制御部１４は、・・・印刷完了の通知をプリンタ制御部１６から受け取ると、その印刷データの印刷要求元に対して印刷完了を知らせるメッセージをネットワーク１２を通じて伝送する。そのメッセージの伝送先、つまり印刷要求元は、上記管理テーブルにある現在印刷作業中の印刷データに該当するホスト装置アドレス及びユーザＩＤより知ることができる。そして、主制御部１４は、通信制御部１３へホスト装置アドレス、ユーザＩＤ及びメッセージデータを渡し、ホスト装置１１へのメッセージデータの実際の転送はこの通信制御部１３で行う。図４に、ホスト装置１１へ送るメッセージデータの構成例を示す。この場合のメッセージ情報ヘッダには、メッセージデータが印刷終了を通知するものであることを示す識別情報が含まれる。
【００１６】また、プリンタ１７へ印刷データの転送を開始するとき、またはプリンタ１７が印刷データを印刷中に、用紙切れや紙づまりなどのユーザにおいて修復可能なエラーが発生した場合には、そのエラー発生がプリンタ制御部１６から主制御部１４へ知らされる。そして、主制御部１４は、そのエラー発生を知らせるメッセージをネットワーク１２を通じて上記と同様に印刷要求元に対して伝送する。この場合のメッセージ情報ヘッダには、メッセージデータが修復可能エラーを通知するものであることを示す識別情報が含まれる。」（第３頁右欄第２−２８行）
　
（２）対比
　本願補正発明と引用刊行物１に記載された発明を対比すると、
　引用刊行物１の「ＬＡＮ」、「プリントサーバ、プリンタ」、「ネットワーク通信部、印刷ジョブ送信部」、「キュー／プリンタ状態要求コマンド」、「キュー／プリンタ状態監視部」及び「ディスプレイ」は、それぞれ、本願補正発明の「通信媒体」、「印刷装置」、「通信モジュール」、「印刷状態要求パケット」「監視手段」及び「表示部」に相当する。
　また、ＬＡＮに接続されたクライアントがパケット通信可能であることは当然であるから、引用刊行物１に記載された「クライアント」は、本願補正発明の「パケット通信可能なデータ処理装置」に相当し、引用刊行物１に記載された「キュー／プリンタ状態応答」は、本願補正発明の、印刷装置からデータ処理装置に送信される「パケット」に相当する。
　また、引用刊行物１では、クライアントが印刷ジョブを送信した後、一定時間毎にキュー／プリンタ状態監視部が起動されている（引用刊行物１の記載事項（エ））から、引用刊行物１のクライアントが、本願補正発明の「ユーザからの印刷要求後、前記印刷装置の状態の監視を前記監視手段に行わせる制御手段」に相当する手段を有していることは明らかである。
　
　したがって、両者は
「所定の通信媒体を介して印刷装置とパケット通信可能なデータ処理装置であって、
　印刷データを含む印刷ジョブを通信モジュールを介して前記印刷装置に送信する送信手段と、
　前記印刷装置の状態を要求する印刷状態要求パケットを生成して、前記印刷状態要求パケットを前記印刷装置に送信し、前記印刷装置から受信するパケットを解析して前記印刷装置の状態を監視し、前記印刷装置の状態を表示部に表示する監視手段と、
　ユーザからの印刷要求後、前記印刷装置の状態の監視を前記監視手段に行わせる制御手段とを有し、
　前記印刷装置は、前記データ処理装置にパケットを送信するデータ処理装置。」
の点で一致し、次の点で相違している。
　
相違点１
　本願補正発明は、データ処理装置が「アプリケーションからのデータを所定のプリント言語に基づく印刷データに変換する変換手段」を有しているのに対して引用刊行物１には変換手段について記載がない点。
　
相違点２
　本願補正発明では、印刷データを含む印刷ジョブが「通知先アドレス」を含んでおり、印刷装置はこの通知先アドレスに従って前記データ処理装置にパケットを送信するのに対して、引用刊行物１には、データ処理装置にパケットを送信（返送）することが記載されているが、送信先であるデータ処理装置のアドレスについては記載がない点。
　
相違点３
　本願補正発明では、「前記通信モジュールから取得したアドレスに基づいて」印刷状態要求パケットを印刷装置に送信しているのに対して、引用刊行物１には、印刷ジョブを送信した印刷装置に印刷状態要求パケットを送信することが記載されているだけである点。
　
相違点４
　本願補正発明では、制御手段は「印刷終了を示すパケットが受信された後、前記印刷装置の状態の監視を前記監視手段に終了させる」が、引用刊行物１ではこの点が必ずしも明確に記載されていない点。
　
（３）当審の判断
　以下、上記相違点について検討する。
　
相違点１について
　印刷装置に印刷ジョブを送信するに際して、データ処理装置においてアプリケーションからのデータを所定のプリント言語に基づく印刷データに変換することは普通に行われており、変換手段を設けることに格別の困難性はない。
　
相違点２について
　引用刊行物２には、ホスト装置（印刷要求元）に印刷終了、エラー発生等を通知するという引用刊行物１と同様の目的で、ホスト装置からプリントサーバシステムに伝送される印刷データにホスト装置アドレス（本願補正発明の通知先アドレスに相当する）を含ませ、当該アドレスに基づいて印刷要求元に印刷作業の終了、あるいはエラー発生等を送信することが記載されており、これを引用刊行物１に記載された印刷システムに適用して、データ処理装置にパケットを送信するために、印刷ジョブに通知先アドレスを含ませることは当業者であれば容易に想到し得ることである。
　
相違点３について
　引用刊行物１では通信モジュールがどの印刷装置に印刷ジョブを送信すべきかを判定し、判定した印刷装置に印刷ジョブを送信している（引用刊行物１の記載事項（ウ）参照）。そして、印刷ジョブの送信が印刷装置のアドレスに基づいて行われることは明らかである。そうすると、印刷状態要求パケットを印刷ジョブを送信した印刷装置に送信する際に、当該印刷装置のアドレスを通信モジュールから取得することに格別の困難性はない。
　
相違点４について
　引用刊行物１の記載事項（オ）には、監視手段が印刷終了を検出すると、ユーザーに印刷終了を報告して処理を終了するとの記載があり、当該記載は、監視手段が印刷終了を検出すれば、監視手段は処理を終了する、あるいは、印刷処理が終了することを意味するものと考えられる。当該記載が、監視手段が印刷終了を検出すると監視手段が処理を終了することを意味するのであれば、引用刊行物１と本願補正発明との間に実質的に相違はないし、また、監視手段が印刷終了を検出すれば印刷処理が終了することを意味するとしても、監視手段は印刷ジョブの送信により開始されるのであるから、印刷処理が終了すれば、監視手段が処理を終了することは当然のことである。したがって、引用刊行物１と本願補正発明との間に実質的に相違はない。
　
　そして、本願補正発明のように構成したことによる効果も引用刊行物１及び引用刊行物２に記載された発明から予測できる程度のものである。
　したがって、本願補正発明（請求項１に係る発明）は、引用刊行物１及び引用刊行物２に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおりであるから、その余の請求項について論及するまでもなく、本件補正は特許法第１７条の２第５項で準用する同法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１４年１０月２１日付手続補正は上記のとおり却下されたので、少なくとも、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１４年６月３日付手続補正書により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「所定の通信媒体を介して印刷装置とパケット通信可能なデータ処理装置であって、
　アプリケーションからのデータを所定のプリント言語に基づく印刷データに変換する変換手段と、
　前記変換手段により変換された印刷データと通知先アドレスとを含む印刷ジョブを前記印刷装置に送信する送信手段と、
　前記印刷装置から受信するパケットを解析して前記印刷装置の状態を監視し、前記印刷装置の状態を表示部に表示する監視手段と、
　ユーザからの印刷要求後、前記印刷装置の状態の監視を前記監視手段に行わせ、印刷終了を示すパケットが受信された後、前記印刷装置の状態の監視を前記監視手段に終了させる制御手段とを有し、
　前記印刷装置は、送信された印刷ジョブに含まれている通知先アドレスに
従って前記データ処理装置にパケットを送信することを特徴とするデータ処理装置。」
　
（１）引用刊行物
　原査定の拒絶の理由に引用された引用刊行物１、引用刊行物２及びその記載事項は、前記「２．（１）」に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記２．で検討した本願補正発明の「印刷ジョブを通信モジュールを介して前記印刷装置に送信する送信手段」の「通信モジュールを介して」との限定を削除し、「監視手段」について、「前記印刷装置の状態を要求する印刷状態要求パケットを生成して、前記通信モジュールから取得したアドレスに基づいて前記印刷状態要求パケットを前記印刷装置に送信し」との限定を削除したものである。
　そうすると、本願発明の構成要件を全て含みさらに限定を付したものに相当する本願補正発明が、前記「２．（３）」に記載したとおり、引用刊行物１及び引用刊行物２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用刊行物１及び引用刊行物２に記載の発明に基づいて、当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明（請求項１に係る発明）は、引用刊行物１、引用刊行物２に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　したがって、本願はその余の請求項について論及するまでもなく、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。