【事件の表示】
　特願２００５−１９２５６３「印刷システム」拒絶査定不服審判事件〔平成１９年　１月１８日出願公開、特開２００７−　１１７４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　手続の経緯の概要は以下のとおりである。
　　平成１７年　６月３０日　出願
　　平成２２年１２月　９日　拒絶査定
　　平成２３年　３月１０日　審判請求
　　平成２３年　３月１０日　手続補正書
　　平成２４年　２月２２日　拒絶理由
　　平成２４年　４月２３日　手続補正書
　　平成２４年　４月２３日　意見書
　　平成２４年　５月２５日　拒絶理由
　　平成２４年　７月２４日　意見書
　
２．本願発明
　本件発明は、平成２４年４月２３日付けで手続補正された特許請求の範囲の請求項１〜６に記載された事項により特定されるものと認められるところ、その請求項１に記載された発明（以下、「本願発明」という。）は次のとおりのものである。
「【請求項１】
　プリンタから当該プリンタのデバイス情報を取得するプリンタモニタ手段と、ＣＵＰＳ（CommonUnix（登録商標）PrintingSystem）から出力される印字データと前記プリンタモニタ手段が取得したデバイス情報とに基づいて、前記プリンタに固有であって印刷開始時の前記プリンタの状態に適したＰＤＬデータを生成するＰＤＬデータ生成手段と、
　前記ＰＤＬデータ生成手段が生成したＰＤＬデータを、前記プリンタモニタ手段を介して前記プリンタへ転送する転送手段と、
を有することを特徴とする印刷システム。」
　
３．当審による拒絶理由の概要
　平成２４年５月２５日付けで当審が通知した拒絶理由の概要は、以下のとおりである。
　本願発明は、「プリンタの限界性能を引き出す　Ｏｐｅｎ　Ｐｒｉｎｔｉｎｇ　Ｓｙｓｔｅｍ　徹底解剖」、日経Ｌｉｎｕｘ　２００４年９月号、２００４年９月８日、第５４頁〜第６１頁（以下、「引用文献３」という。）に記載された発明において、特開２０００−２４２５９７号公報（以下、「引用文献２」という。）に記載された事項を適用することにより、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
４．引用文献
４−１
　引用文献３には、次の事項が記載されている。なお、下線は当審が付した。
（１）「オープンプリンティングプロジェクトは２００４年６月１７日，ＵＮＩＸ系ＯＳ向けの新しい印刷システム「Ｏｐｅｎ　Ｐｒｉｎｔｉｎｇ　Ｓｙｓｔｅｍ」（以下，ＯＰＳと略記）を開発したと発表した。・・・（中略）・・・
　公開したＯＰＳには，メーカーがプリンタ・ドライバを提供しやすくする仕組みが盛り込まれている。例えば，プリンタ・ドライバのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）を共通化し，同一のドライバを複数の印刷システムで利用できるようにした。また，プリンタ・ドライバをソース・コード非公開でも提供できるライセンス分離機構も用意している。機種によっては従来の１０倍以上という印刷速度向上も実現した。
　また，プリンタの状態情報をアプリケーションが取得するための共通インタフェースも用意した。これにより，印刷アプリケーション側で，インク残量の確認などができるようになった。」（第５４頁左欄第１行〜同頁中央欄第１１行）
　
（２）「ＬｉｎｕｘなどのフリーＵＮＩＸでは一般に，前述のＧｈｏｓｔｓｃｒｉｐｔ（ｇｓ）というフリーのＰｏｓｔｓｃｒｉｐｔインタプリタを図３のような構成で利用する。つまり，
ｇｓがＰｏｓｔＳｃｒｉｐｔデータを解釈し，それを各プリンタ用のプリンタ・ドライバがプリンタ個別のデータ形式に変換して出力する
　
（３）「また最近では，ＣＵＰＳの採用が進んでいる。
ＣＵＰＳは，ｌｐｄに比べて大幅な機能拡張を実現したスプール・システムである。ｌｐｄと互換性を保ちながら，アプリケーションとプリンタとの双方向通信や，柔軟なフィルタ（プリンタ・ドライバ）呼び出しなどを実現している。プリンタ固有の情報をＰＰＤ（ＰｏｓｔＳｃｒｉｐｔ　Ｐｒｉｎｔｅｒ　Ｄｅｆｉｎｉｔｉｏｎ）ファイルに格納し，それを参照して処理をプリンタごとに最適化できるのも特徴である（図６）。
　各種ＬｉｎｕｘディストリビューションでＣＵＰＳが標準採用されるなか，ＣＵＰＳ用フィルタも充実し，「Ｇｉｍｐ−Ｐｒｉｎｔ」（ｈｔｔｐ：／／ｇｉｍｐ−ｐｒｉｎｔ．ｓｏｕｒｃｅｆｏｒｇｅ．ｎｅｔ／）や「Ｆｏｏｍａｔｉｃ」（ｈｔｔｐ：／／ｗｗｗ．１ｉｎｕｘｐｒｉｎｔｉｎｇ．ｏｒｇ／）といったサードパーティ製フィルタも登場している。
　Ｌｉｎｕｘ用のプリンタ・ドライバを提供する場合，これらのどの印刷システム向けのドライバを提供するのかが問題になる。それぞれのシステムには一長一短があり，ディストリビューションによっても標準採用するシステムはまちまちである。全部に対応するのは労力がかかり過ぎる。しかし絞り込むのも難しい。今後，新しいシステムが登場して普及し，せっかく提供したドライバが無駄になる可能性もある。これでは積極的にドライバを提供できない。
　もう一つの理由はライセンスである。例えば，
ＧＮＵ版のＧｈｏｓｔｓｃｒｉｐｔは配布ライセンスにＧＮＵ　ＧＰＬを採用している。ＧＮＵ　ＧＰＬはソフトウエアの配布に当たってソース・コードの公開を義務付けている。そのため，ｇｓの一部と見なされるプリンタ・ドライバもソース・コードを公開しなければならない。
　
しかし，プリンタ・ドライバにはプリンタ・メーカーが開発したさまざまなノウハウが詰まっている。ソース・コードを公開してしまうと，インクの特性・種類に応じて出力を補正する処理など，競争力をつけるために開発した企業秘密が漏えいしてしまう。おいそれとドライバを提供するわけにはいかない。
　
　上記（３）には、（ｉ）ＣＵＰＳは、柔軟なプリンタ・ドライバ呼び出しなどを実現し、プリンタごとに処理を最適化できること、（ｉｉ）ＧＵＮ　ＧＰＬがソース・コードの公開を義務付けているため、プリンタ・メーカーがプリンタ・ドライバを提供することを妨げていること、が記載されている。
　
（４）「メーカー製ドライバの拡充を目指し，ＯＰＳでは，メーカーがベクター・ドライバを提供しやすい環境を整備した。
　まず，
ベクター・ドライバ用の共通ＡＰＩ（標準ベクター・ドライバＡＰＩ）を定義し，これに沿って各プリンタ用のドライバを用意する仕組みにした。
　
（５）「また，ライセンス問題については，
ソース・コードを非公開にしたいドライバ向けに，プロセス間通信を使う図８のような方式を用意した。この方式では，ｇｓとベクター・ドライバが別プロセスとして動作する。
　
　上記（５）には、上記（３）に記載のプリンタ・メーカーがプリンタ・ドライバ（ベクター・ドライバ）を提供することを妨げている問題を解決するために、プロセス間通信を使用して、プリンタ・メーカーによるプリンタ・ドライバをＣＵＰＳとは別プロセスとして動作させる点が記載されている。
　
（６）「
ＯＰＳでは，プリンタの状態情報を取得する仕組みも整備した。Ｂｉ−ｄｉプラグインと呼ばれるプリンタとの双方向通信を実現するソフトウエア・モジュールを用意し，それが利用する共通ＡＰＩ（Ｂｉ−ｄｉプラグインＡＰＩ）を定めた
　
（７）「同プロジェクトでは，ＯＰＳの更なる機能拡張も計画している。例えば，Ｂｉ−ｄｉプラグインは現在，プリンタの状態情報取得にしか利用できないが，「エラー解除機能を皮切りに，プリンタの制御／設定機能も付加したい」（中島氏）という。今後の開発に期待したい。」（第６０頁右欄第１４行〜第２０行）
　
（８）図１１には、「ＣＵＰＳとＯＰＳを組み合わせた場合のシステム構成図」（第６０頁左欄第６〜７行）が記載されている。
　上記（５）に記載の、Ｇｈｏｓｔｓｃｒｉｐｔとベクター・ドライバとが別プロセスとして動作する図８に示されるシステムは、ＧＵＮ　ＧＰＬにしばられることなくプリンタ・ドライバを提供したいというＯＰＳの仕組みの一部であるから、図１１に示されるシステムにおいても当然に適用されるものとみなすことができる。
　それゆえ、
図１１に示されるシステムは、
　
アプリケーションからのＰｏｓｔＳｃｒｉｐｔデータである印刷データがＣＵＰＳに入力され、
　Ｃ
ＵＰＳから出力されたＰｏｓｔＳｃｒｉｐｔデータが、Ｇｈｏｓｔｓｃｒｉｐｔに入力され、ｇｌｕｅコード及び標準ベクター・ドライバＡＰＩを介して、Ｇｈｏｓｔｓｃｒｉｐｔとは別プロセスで動作するプリンタ用のドライバによって、ＰｏｓｔＳｃｒｉｐｔデータからプリンタのページ記述言語に変換され、変換されたデータが再びＣＵＰＳに入力され、
　
ＣＵＰＳから出力された印刷データが、Ｂｉ−ｄｉプラグインを有するプリンタ・サーバーを介して、プリンタに出力されることが記載されており、　プリンタからのプリンタ情報が、プリンタ・サーバーを経由してプリンタ状態監視アプリケーションによって表示されるもの
　
（９）以上を総合すると、引用文献３には、次の発明（以下、「引用発明３」という。）が記載されている。
「各プリンタ用のドライバが用意され、
　アプリケーションからのＰｏｓｔＳｃｒｉｐｔデータである印刷データがＣＵＰＳに入力され、
　ＣＵＰＳから出力されたＰｏｓｔＳｃｒｉｐｔデータが、Ｇｈｏｓｔｓｃｒｉｐｔに入力され、ｇｌｕｅコード及び標準ベクター・ドライバＡＰＩを介して、Ｇｈｏｓｔｓｃｒｉｐｔとは別プロセスで動作するプリンタ用のドライバによって、ＰｏｓｔＳｃｒｉｐｔデータからプリンタのページ記述言語に変換され、変換されたデータが再びＣＵＰＳに入力され、
　ＣＵＰＳから出力された印刷データが、Ｂｉ−ｄｉプラグインを有するプリンタ・サーバーを介して、プリンタに出力されるものであって、
　プリンタからのプリンタ状態情報が、プリンタ・サーバーを経由してプリンタ状態監視アプリケーションによって表示される印刷システム。」
　
４−２
　引用文献２には、次の事項が記載されている。なお、下線は当審が付した。
（１）「【０００６】しかし、「お気に入り」では変更可能な設定項目が多いために、デバイスオプションについてコンフリクト問題が生じる場合がある。例えば、ユーザが両面印刷をする設定をしていても、両面ユニットがプリンタに装着されていなければ両面印刷を行うことはできない。同様にユーザがステイプル等を使用する設定をしていても、専用のフィニッシャがプリンタに装着されていなければステイプル等をすることができない。しかし、「お気に入り」によって多くの設定項目を一括して変更してしまうと、それらのデバイスコンフリクトが生じたまま設定がなされてしまう。
【０００７】また、専用のデバイスオプションが装着されている時に「お気に入り」の作成したが、印刷時にはそのデバイスオプションが外されている場合や、専用のデバイスオプションが装着されていない他のデバイスに対して「お気に入り」をコピーしてしまった場合など、実際には実行できない設定を「お気に入り」で設定してしまうという不具合が生じうる。
【０００８】そこで、
本発明では、「お気に入り」の選択時に、現在のデバイスオプションの装着状況等をチェックし、実行不可能な設定がなされている場合にはその旨のメッセージを表示した上、設定値を丸める。
　
（２）「【００４２】グラフィックエンジン２１０２は、印刷装置ごとに用意されたプリンタドライバ２１０３を同様に外部メモリ１２からＲＡＭ２にロードし、
アプリケーション２１０１の出力をプリンタドライバ２１０３を用いてプリンタの制御コマンドに変換する。このとき、ユーザは、プリンタドライバのユーザインターフェイスを用いて、プリンタに対する印刷設定を行うことができ、その設定にしたがってプリンタドライバ２１０３はプリンタの制御コマンドを生成する。
　
（３）「【００５５】〔コンフリクトチェックの処理〕図４のフローのステップＳ４０３の、コンフリクトチェックの処理について図７のフローチャートを用いて説明する。
【００５６】お気に入り機能はＵＩ上に存在するほぼすべての設定項目を登録対象としている。しかし、
その設定項目の中には、デバイス環境に依存して、特にデバイスに装備されているデバイスオプションに依存して実際に実行できるものと実行できないものとがある。
【００５７】従って、「お気に入り」で、ある設定内容を選んでも、その設定内容が現在のデバイス環境でそのまま実行できるとは限らない。それに対処すべく、ここでは
デバイスに装備されているデバイスオプションに応じたコンフリクトチェックの処理（不整合のチェック＆設定の丸め処理）について説明する。
【００５８】まず、デバイスオプション登録部（レジストリまたは特定のメモリ上）に保持されているデバイスオプション情報を作業領域に読み込む（ステップＳ７０１）。デバイスオプション（例えば、フィニッシャや給紙カセット、メモリ等）の設定については後述する。
【００５９】次に、
装備されているデバイスオプションの影響を受ける設定項目について順次チェックを行い（ステップＳ７０２）、現在の設定内容で実行することが可能であるか否かを確認をする（ステップＳ７０３）。
【００６０】
ステップＳ７０３において、登録されている設定内容では実行できないと判断した場合（ステップＳ７０３−Ｎｏ）、その旨のメッセージを図８のように表示し（ステップＳ７０４）、設定内容を丸める（ステップＳ７０５）。
このステップＳ７０３からステップＳ７０５までの処理を、デバイスオプションの影響を受ける設定項目すべてについて行う。
【００６１】
ここで、デバイスコンフリクトチェックの処理の例をいくつか挙げておく。
・
両面ユニットが装着されていないのに、両面設定が登録されている「お気に入り」を選んだ場合、片面設定に変更する。
・
ステイプル可能なフィニッシャが装着されていないのに、ステイプルが登録されている「お気に入り」を選んだ場合、ステイプル無しに変更する。
・
製本可能なフィニッシャが装着されていないのに、製本印刷が登録されている「お気に入り」を選んだ場合、製本無しの通常印刷に変更する。
・
中綴じ（製本印刷にて折り目にステイプルする機能）可能なフィニッシャが装着されていないのに、中綴じが登録されている「お気に入り」を選んだ場合、中綴じ無しの製本印刷に変更する。
・
装備されていないカセット段が登録されている「お気に入り」を選んだ場合（本体にカセットが２段しか装備されていないのに、カセット６が登録されているような場合）、デフォルトの「自動」に変更する。
・メモリが不十分なのに、メモリを増設しないと印刷できない高精細モードが登録されている「お気に入り」を選んだ場合、デフォルト設定（通常のモード）の印刷に変更する。その他、メモリに依存する処理全般についてもデフォルトに変更する。
【００６２】最後に、丸め処理によってすべてのコンフリクトをなくした状態で設定内容を返す（ステップＳ７０６）。」
　
（４）「【００８０】
ユーザによりデバイス情報取得ボタンＢＴＮ４１が押された場合は（ステップＳ１８０２―Ｙｅｓ）、デバイスとの双方向通信により、実際に装備されているデバイスオプションの情報をデバイス本体から取得し（ステップＳ１８０３）、作業領域にロードされていたデバイスオプション情報を更新しダイアログＤＬＧ４の表示に反映させる（ステップＳ１８０５）。
　
（５）図８には、「ステップ７０３において、
登録されている設定内容では実行できないと判断した場合
自動調整します」とのメッセージ
　
（６）以上を総合すると、引用文献２には、プリンタとの双方向通信によって、該プリンタから取得したデバイス情報に基づいて印刷設定を自動で変更し、当該印刷設定に基づいてプリンタの制御コマンドを生成し、印刷処理を行う技術が記載されている。
　
５．対比・判断
（１）本願発明と引用発明３との対比
　引用発明３の「印刷データ」と本願発明の「印字データ」とは、表現が異なるだけのものであって、共に同じ技術事項を指しているから、以後、本願発明の用語に合わせて「印字データ」という。
　
　引用発明３のプリンタ・サーバーのＢｉ−ｄｉプラグインは、プリンタから当該プリンタのプリンタ情報を取得するプリンタモニタ手段を備えるものであり、本願発明の「プリンタのデバイス情報」と引用発明３の「プリンタ情報」とは同じものではないが、「プリンタに関する情報」である点で共通する。それゆえ、本願発明と引用発明３とは、「プリンタから当該プリンタに関する情報を取得するプリンタモニタ手段」を備える点で共通する。
　
　引用発明３の「ページ記述言語」と本願発明の「ＰＤＬ」とは、単に表現が異なるだけであって、同じものである。
　
　引用発明３は、ＣＵＰＳから出力される印字データが、Ｇｈｏｓｔｓｃｒｉｐｔにおいて、各プリンタ用のドライバによって当該プリンタのページ記述言語に変換されるもの、すなわち、プリンタによってページ記述言語が異なれば、そのプリンタに応じたページ記述言語に変換されるものである。
　ここで、プリンタに応じたページ記述言語に変換するためには、そのプリンタが特定されていなければならないことは自明であるから、明示はされていないものの、引用発明３が“プリンタを特定する情報”を保有していることは明らかである。
　つまり、引用発明３は、プリンタを特定する情報に基づいて、印字データが当該プリンタに用いられる当該プリンタに固有のページ記述言語に変換されるものである。
　そして、上述のように、「ページ記述言語」と「ＰＤＬ」とは表現が異なるだけであるから、結局のところ、本願発明と引用発明３とは、「ＣＵＰＳから出力される印字データとプリンタを特定する情報に基づいて、前記プリンタに固有であって前記プリンタに適したＰＤＬデータを生成するＰＤＬデータ生成手段」を備える点で共通する。
　
　引用発明３は、Ｇｈｏｓｔｓｃｒｉｐｔによって変換（生成）されたページ記述言語をプリンタモニタ手段といえるプリンタ・サーバーのＢｉ−ｄｉプラグインを介してプリンタへ転送するものであるから、本願発明と引用発明３とは、「ＰＤＬデータ生成手段が生成したＰＤＬデータを、前記プリンタモニタ手段を介して前記プリンタへ転送する転送手段」を備える点で共通する。
　
　したがって、本願発明と引用発明３とは、以下の点で一致し、相違する。
［一致点］
「プリンタから当該プリンタに関する情報を取得するプリンタモニタ手段と、ＣＵＰＳから出力される印字データと前記プリンタを特定する情報とに基づいて、前記プリンタに固有であって前記プリンタに適したＰＤＬデータを生成するＰＤＬデータ生成手段と、
　前記ＰＤＬデータ生成手段が生成したＰＤＬデータを、前記プリンタモニタ手段を介して前記プリンタへ転送する転送手段と、
を有することを特徴とする印刷システム。」
　
［相違点］
　本願発明は、プリンタに関する情報として、「プリンタモニタ手段」が「デバイス情報」を取得し、印字データと当該「デバイス情報」とに基づいて、「前記プリンタに固有であって印刷開始時の前記プリンタの状態に適したＰＤＬデータを生成する」のに対して、
　引用発明３は、プリンタに固有であって前記プリンタに適したＰＤＬデータを生成するものであるものの、印字データとプリンタモニタ手段が取得したデバイス情報とに基づいて、印刷開始時の前記プリンタの状態に適したＰＤＬデータを生成するものではない点。
　
（２）相違点に対する判断
　引用発明３のようなＣＵＰＳから出力される印字データを対象とするものではないものの、プリンタに対して印刷処理を行うものにおいて、デバイスとの双方向通信により、実際に装備されているデバイスオプションの情報をデバイス本体から取得して、これに応じた処理、例えば、両面ユニットが装着されていない場合には、設定を片面設定に変更することが、引用文献２に示されているように知られている。
　そして、引用発明３は、プリンタ状態情報を取得して、プリンタ状態をモニターするものであるが、これにとどまらず、「エラー解除機能を皮切りに、プリンタの制御／設定機能も付加したい」という課題、すなわち、プリンタ状態に応じてプリンタに対する制御／設定を行いたいという課題が認識されているものである。
　そのような課題が認識されていて、かつ、引用発明３において、引用文献２に示された事項を適用することを妨げる事情もないから、ＣＵＰＳから出力される印字データを対象とする引用発明３においても、引用文献２に示された事項を適用して、プリンタ状態情報の取得・表示にとどまらず、印字データとプリンタモニタ手段が取得したデバイス情報とに基づいて、プリンタに固有であって印刷開始時の前記プリンタの状態に適したＰＤＬデータを生成するようにすることは、当業者が容易になし得たことである。
　
　なお、本願発明における「ＣＵＰＳ（CommonUnix（登録商標）PrintingSystem）から出力される印字データ」を出力する「ＣＵＰＳ」と、「印刷システム」との関係について、以下に補足する。
　本願の明細書を参酌すれば、段落【００１０】に「本発明の実施形態は、図２で示したＵｎｉｘ系ＯＳの標準的な印刷システムであるＣＵＰＳ２０１におけるフィルタ・レンダラ部２０４の一部の機能であるＰＤＬデータを生成する処理部と、プリンタモニタ部２０６及びステータス表示ＵＩ部２０７に関するものである。」と記載されているように、「ＣＵＰＳ」と「印刷システム」とは別々に存在するものではなく、「ＣＵＰＳ」は「印刷システム」の一部であって、そのような「ＣＵＰＳ」から出力される印字データの処理を「印刷システム」が行うものである。
　「印字データ」が「ＣＵＰＳから出力される」ものであるとする限定は、平成２４年４月２３日付けの手続補正によってなされたものであって、当該補正に関して、同日付けで提出された意見書では、「補正前の請求項１を補正前の請求項７の内容で減縮するものです。」と説明している。
　ところで、補正前の請求項７（平成２３年３月１０日付け手続補正書）は、「前記印刷システムはＵｎｉｘ（登録商標）系ＯＳ（Operating System）に搭載されているＣＵＰＳ（Common Unix Printing System）であることを特徴とする請求項１乃至６のいずれか１項に記載の印刷システム。」であって、要すれば、「印刷システム」と「ＣＵＰＳ」とは一体不可分であって、別々に存在するものではないとの規定である。
　したがって、本願発明における「ＣＵＰＳ」は、「印刷システム」の一部である。
　結局のところ、ＣＵＰＳから出力される印字データからＰＤＬデータを生成しプリンタへ転送する印刷システムである点において、本願発明と引用発明３とは相違しないものであり、上記対比・判断は、このような認定に基づくものである。
　
　したがって、本願発明は、引用発明３及び引用文献２に記載された事項に基づいて当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　
５．むすび
　以上のとおりであるから、本願は、他の請求項に係る発明について検討するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。