【事件の表示】
　特願２００６−２１４５２６「画像形成装置、制御方法、制御プログラム」拒絶査定不服審判事件〔平成１９年　２月　８日出願公開、特開２００７−　３５０４９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１４年５月１７日に出願した特願２００２−１４３０８０号の一部を平成１８年８月７日に新たな特許出願としたものであって、平成１８年９月４日に手続補正がなされ、平成１９年２月９日付けで拒絶理由通知がなされ、同年４月２０日付けで手続補正がなされたが、同年５月１１日付けで拒絶査定がなされ、これに対し、同年６月２１日に審判請求がなされるとともに同年７月２０日付けで手続補正がなされたものである。そして、平成２０年３月２７日付けで審査官から前置報告がなされ、平成２１年５月１２日付けで当審より審尋がなされ、同年７月１６日付けで回答書が提出されたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　平成１９年７月２０日付けの手続補正を却下する。
　
［理由］
１．補正後の本願発明
　上記手続補正において、請求項４についてする補正（以下、「本件補正」という。）は、平成１９年４月２０日付けの手続補正により補正された特許請求の範囲の請求項４に記載された
「ネイティブモードで制御プログラムを実行する第１の実行環境と、画像形成装置の機種に非依存である制御プログラムを実行する第２の実行環境とが共存する画像形成装置を制御する制御プログラムにおいて、
　前記制御プログラムは、第１の実行環境上でネイティブモードで実行される、特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリと、機種非依存の第２の実行環境から呼び出すことが出来る前記ソフトウェアライブラリに対してアクセスするためのインターフェースプログラムを含み、
　前記インタフェースプログラムに含まれる少なくともひとつの命令には、前記ソフトウェアライブラリの一部である、画像処理エンジンを制御するための複数のコマンドが対応付けられており、その複数のコマンドの組合せをひとつのコマンドとみなし、前記一つの命令を用いて当該複数のコマンドを呼び出し可能であることを特徴とする制御プログラム。」
という発明（以下、「補正前の発明」という。）を、
「ネイティブモードで制御プログラムを実行する第１の実行環境と、画像形成装置の機種に非依存である制御プログラムである複数のアプリケーションを実行する第２の実行環境とが共存する画像形成装置を制御する制御プログラムにおいて、
　前記制御プログラムは、第１の実行環境上でネイティブモードで実行される、特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリと、機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリであって、複数のアプリケーションにより共用されるソフトウェアライブラリに対してアクセスするためのインターフェースプログラムを含み、
　前記インタフェースプログラムに含まれる少なくともひとつの命令には、前記ソフトウェアライブラリの一部である、画像処理エンジンを制御するための複数のコマンドが対応付けられており、その複数のコマンドの組合せをひとつのコマンドとみなし、前記一つの命令を用いて当該複数のコマンドを呼び出し可能であることを特徴とする制御プログラム。」
という発明（以下、「補正後の発明」という。）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであって、補正前の特許請求の範囲の請求項４に記載された「画像形成装置の機種に非依存である制御プログラム」を、「複数のアプリケーション」に限定するとともに、「機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリ」を、「機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリであって、複数のアプリケーションにより共用されるソフトウェアライブラリ」と限定して特許請求の範囲を減縮するものであるから、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）の規定、及び、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号（補正の目的）の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．補正後の本願発明」の項で認定したとおりである。
　
（２）引用発明及び周知技術
Ａ．引用発明
　原審の拒絶理由に引用された刊行物である、根本忍，「ＪＴＲＯＮ仕様準拠ＲＴＯＳ「ＪＢｌｅｎｄ」を使った組み込み機器へのＪａｖａの導入とその実現手法」，Ｉｎｔｅｒｆａｃｅ，第２５巻，第９号，第８３−９６頁，ＣＱ出版株式会社，１９９９年９月１日（以下、「引用文献１」という。なお、原審の拒絶理由通知には、文献名が「ＪＴＲＯＮ仕様準拠ＲＴＯＳ「ＪＢｌｅｎｄ」を使った組み込み機器へのＪａｖａの導入とその実現方法」と記載されているが、当該記載における「実現方法」は、「実現手法」の誤記と認められるので訂正した。）には、以下の事項が記載されている。
　
（ア）「１．組み込みとＪａｖａ
１．１　組み込み分野におけるＪａｖａの課題
　組み込み分野にＪａｖａを導入する際の最大の障壁は，そのサイズとスピードです．たとえば筆者らが家電機器メーカーにＪａｖａの利用を提案すると，数百Ｋバイト／数ＭＩＰＳのプラットホームで数Ｍバイトのメモリと数十ＭＩＰＳもの環境が必要といわれているＪａｖａが使えるのかと一笑に付されることがあります．しかし，これはパソコンやワークステーションで使われているＪａｖａをそのまま持ち込んだ場合の話です．
　Ｊａｖａにかぎらず，汎用性をめざして多機能化されてきたＰＣやワークステーションの環境をそのまま組み込みの世界に持ち込もうとすると，多くの障壁に直面します．用途や機器構成が多岐にわたるパソコンと違い，家電機器なでの組み込み製品は，特定用途を満たすという目的にしぼり，簡単に使えること／安く製品が提供できることを目標にして，熟慮を重ねて作られています．
　筆者らの会社（アプリックス）が開発／提供しているＪＴＲＯＮ（Ｊａｖａ　Ｔｅｃｈｎｏｌｏｇｙ　ｏｎ　ＩＴＲＯＮ）仕様リアルタイムＯＳ「ＪＢｌｅｎｄ」は，組み込み制御分野で使われているＩＴＲＯＮ仕様を出発点とし，機器制御における課題を克服するための要素技術という観点からＪａｖａを利用しています．」（第８３頁左欄下から１２行−同頁右欄９行）
　
（イ）「こと組み込みについて考えると，Ｊａｖａの最大の魅力の一つは，安くて豊富にあるパソコン上の開発ツールと，ＣＰＵやＯＳに依存しない高い互換性にあります．これについては，後でもう少し詳しく述べます．
１．３　エミュレーション＋クロスコンパイル　ｖｓ　Ｊａｖａ
　安価で手軽な開発環境を使ったプロトタイピングより一歩進んだ開発を可能とする方法としては，エミュレーション環境で検証してクロスコンパイルする方法があります．この場合，ユーザーインターフェースのライブラリを使うか，ＷｉｎｄｏｗｓのようなスケーラブルなＯＳを使うことが考えられますが，どちらもクロスコンパイルしないと実機上では動作しません．クロスコンパイルの最大の欠点は，ＣＰＵやＯＳの微妙な違いによる「似て非なる動作」が発見しにくいことです．
（中略）
　この特性のおかげで，ＰＣ上で正しく動作しているものを実機にもっていったときに誤動作するようなら，Ｊａｖａではないといえることになります．
１．４　組み込みの世界でＪａｖａを使うには
　このような特性をもつＪａｖａにも欠点があります．いちばん大きな問題はハードウェア制御とリアルタイム性の欠如ですが，その他には必要メモリ容量が大きいことと動作速度が遅いこともあげられます．
　まず，必要メモリ容量に関しては，Ｅｍｂｅｄｄｅｄ　Ｊａｖａにより，必要なクラスライブラリを自由に組み合わせられるようになり，用途やプラットホームに合わせて必要なメモリサイズを調整することが可能になりました．また，動作速度についても，たとえばＪＴＲＯＮ仕様ＯＳ「ＪＢｌｅｎｄ」を使うと，画像処理のように高速処理が必要な部分はもっとも速いネイティブコードで書くことができます．」（第８４頁左欄１行−同頁右欄１２行）
　
（ウ）「問題その２：ハードウェアの制御
　リアルタイムシステムの場合，割り込み応答性が要求されるのはハードウェアイベントです．上記のＧＣの問題を解決しても，ハードウェアイベントを受け付けられないと，実際には意味がありません．この問題についての対処方法は，２通り考えられます．一つはＪａｖａの仕様を拡張してハードウェアを直接制御できる方法を提供するもの，もう一つはネイティブコードでハードウェア割り込みを処理し，その情報をＪａｖａのメソッドに通知するものです．
　前者の方法は（中略）
　これに対して後者，つまりＪＴＲＯＮの場合，ネイティブコードで書かれているため高速処理が可能なだけでなく，ＣＰＵ依存の処理も行えます．また，その結果だけをイベントやデータとしてＪａｖａのメソッドに渡すことも可能なので，ＣＰＵに依存するようなＪａｖａの仕様拡張をする必要がありません．これが，ＪＴＲＯＮにおいてＪａｖａのプラットホーム独立というメリットが守られている理由です．リアルタイムＪａｖａとＪＴＲＯＮとの違いを，表１にまとめます（図２も参照のこと）．
１．６　ＪＴＲＯＮ仕様リアルタイムＯＳ
　　　　−ＪＢｌｅｎｄについて
　それでは，ＪＴＲＯＮ仕様に準拠した組み込み用ＲＴＯＳ「ＪＢｌｅｎｄ」について解説していきます．このＪＢｌｅｎｄを搭載した機器では，ＩＴＲＯＮアプリケーションおよび１００％　Ｐｕｒｅ　Ｊａｖａで書かれたＪａｖａアプリケーション／アプレットが．そのまま動作します．
　ＪＴＲＯＮは，高性能ＲＴＯＳの仕様であるＩＴＲＯＮと，プロセッサ独立で高度なＧＵＩやネットワーク機能を実現するＪａｖａの実行環境とを融合したＲＴＯＳの仕様です．ＪＴＲＯＮ環境では，Ｊａｖａのネットワーク機能を利用したＩＴＲＯＮアプリケーションやＩＴＲＯＮのリアルタイム制御機能を利用したＪａｖａアプリケーションを作成して動作させることができます．
（中略）
　ＪＴＲＯＮ仕様の実装にはいくつかの方法がありますが，ＪＢｌｅｎｄでは，ＩＴＲＯＮ上にＪＶＭを実装するのではなく，ＩＴＲＯＮとＪａｖａ実行環境とが相補的に併存する構成をとっています．アプリックスでは「Ｐｅｒｓｏｎａｌ　ＪＢｌｅｎｄ」という製品も提供していますが，こちらはＩＴＲＯＮとＰｅｒｓｏｎａｌ　Ｊａｖａとを融合させたものです．」（第８６頁左欄１０行−同頁右欄下から７行）
　
（エ）「［表１］　リアルタイムＪａｖａとＪＴＲＯＮの違い　
　リアルタイムＪａｖａの場合
　（中略）
　ＪＴＲＯＮの場合　
・ハードウェアの逝去（当審注：原文ママ、「逝去」は「制御」を誤記したものと思われる。）部分は，従来の方法で開発できる．開発環境も従来のもの（ミドルウェア，ＩＣＥ，Ｃコンパイラ，アセンブラ・・・）がそのまま使える
・パソコン上で，Ｊａｖａにより開発できる．
・ハードウェアとのインターフェース部分については，ドライバとのインターフェースを決めて，ドライバのダミーモジュールを作ればよい
例）プリンタのエミュレーションは，データをダミーモジュールに渡すだけになる．ダミーモジュールはプリントしたふりをすればよい．スキャナのエミュレーションの場合なら，ダミーの画像データを返すだけでよい」（第８６頁左欄［表１］）
　
（オ）「・システム構造
　ＪＢｌｅｎｄを大きく分けると，Ｊａｖａの実行環境部分とＩＴＲＯＮ部分（ＩＴＲＯＮ仕様準拠カーネル）の二つで構成されています．この二つのつなぎ目の部分が，「ＰＡＬ（Ｐｒｏｃｅｓｓｏｒ　Ａｂｓｔｒａｃｔｉｏｎ　Ｌａｙｅｒ）」と呼ばれるものです（開発：アプリックス）．ＰＡＬとは，Ｊａｖａ実行環境のＣＰＵ依存部分に設けた独自の抽象化層で，これによりＩＴＲＯＮ仕様準拠のカーネルがＣＰＵのデバイスドライバとして動作します（図６）．
　ＰＡＬとＪａｖａ実行環境との間のインターフェースには，Ｊａｖａ実行環境で使われている関数名や引き数の型をそのまま使用しています．また，ＰＡＬとＩＴＲＯＮとの間のインターフェースは，ＩＴＲＯＮ仕様のＲＴＯＳが提供するインターフェースを使用しています．ここでは，ＰＡＬは一種の通訳のような仕事をしています．
　ＰＡＬがＪａｖａＯＳとＩＴＲＯＮの緩衝層となることで，互換性を維持したまま，ＩＴＲＯＮからＪａｖａの機能が，そしてＪａｖａからＩＴＲＯＮの機能が利用できます．」
（第８８頁左欄１７行−同欄下から６行）
　
（カ）「３．２　Ｒｅｍｏｔｅ　Ｄｅｂｕｇｇｅｒ　ｆｏｒ　ＪＴＲＯＮ
　従来のＪＴＲＯＮ仕様ＯＳ用のソフトウェア開発は，ＩＴＲＯＮ上で動作するドライバなどとユーザーインターフェースなどのＪａｖａアプリケーションを別々に開発し，実機上で最終的な動作確認を行っていました．ＩＴＲＯＮ上で動作するドライバはＣやアセンブラで記述し，従来の開発環境を使って単独でデバッグ，ＪａｖａアプリケーションはＶｉｓｕａｌＣａｆｅやＶｉｓｕａｌＪ＋＋，ＪＢｕｉｌｄｅｒ３などのＰＣ上のＪａｖａアプリケーション開発環境を使って動作確認／デバッグを行っていますが，実機上で両方のプログラムを合わせてテストするとき，Ｊａｖａアプリケーションを実機側でデバッグする環境がありませんでした．」（第９５頁左欄下から２行−同頁右欄９行）
　
（キ）図２（第８７頁）
「［図２］ＪＴＲＯＮとリアルタイムＪａｖａとの違い−リアルタイム処理」との表題の下に、「（ａ）ＪＴＲＯＮアーキテクチャの場合」として，「ＣＰＵ依存処理と，ＣＰＵ非依存処理と，用途に応じて利用する言語を分けることができる．そのため，それぞれの処理を単純化することができる」との説明が付され，ＣＰＵ依存処理がＲＴＯＳ並びにＲＴＯＳの同期通信機能を用いて当該ＲＴＯＳと通信するデバイスドライバ及び割り込み処理が図示され、さらにＲＴＯＳ、デバイスドライバ及び割り込み処理というＣＰＵ依存処理がネイティブコードで書かれることが図示されている．
　
（ク）図３（第８７頁）
「［図３］ＩＴＲＯＮタスクとＪａｖａスレッド」との表題の下に，２つのＪａｖａアプリケーションが２つのＪａｖａのスレッドとして，２つのＩＴＲＯＮタスクと共にＩＴＲＯＮカーネル上にあり、これらがＣＰＵにより実行されることが図示されている。
　
（ケ）図６（第８８頁）
「［図６］ＰＡＬ（Ｐｒｏｃｅｓｓｏｒ　Ａｂｓｔｒａｃｔｉｏｎ　Ｌａｙｅｒ）」との表題の下に、Ｊａｖａ実行環境内のプロセッサ依存部（スレッド，モニタ，割り込み）が，ＰＡＬを介してＩＴＲＯＮカーネル内のタスク操作システムコール及びセマフォ操作システムコールに通信し、そして当該タスク操作システムコール及びセマフォ操作システムコールからＣＰＵに通信することが図示されている。
　
（ａ）上記（ウ）の「ＪＴＲＯＮ仕様に準拠した組み込み用ＲＴＯＳ「ＪＢｌｅｎｄ」について解説していきます．このＪＢｌｅｎｄを搭載した機器では，ＩＴＲＯＮアプリケーションおよび１００％　Ｐｕｒｅ　Ｊａｖａで書かれたＪａｖａアプリケーション／アプレットが．そのまま動作します．
　ＪＴＲＯＮは，高性能ＲＴＯＳの仕様であるＩＴＲＯＮと，プロセッサ独立で高度なＧＵＩやネットワーク機能を実現するＪａｖａの実行環境とを融合したＲＴＯＳの仕様です．」との記載、及び、同（ウ）の「ＪＴＲＯＮ仕様の実装にはいくつかの方法がありますが，ＪＢｌｅｎｄでは，ＩＴＲＯＮ上にＪＶＭを実装するのではなく，ＩＴＲＯＮとＪａｖａ実行環境とが相補的に併存する構成をとっています．」との記載からみて、引用文献１には、
　ＩＴＲＯＮとＪａｖａ実行環境とが併存する組み込み用ＲＴＯＳであるＪＢｌｅｎｄ
について記載されたものと認められる。
　そして、上記（キ）のＲＴＯＳと、デバイスドライバや割り込み処理がネイティブコードで書かれることの図示に関し、当該（カ）の「ＩＴＲＯＮ上で動作するドライバ」との記載を併せると、当該（キ）におけるＲＴＯＳとはＩＴＲＯＮであって、デバイスドライバや割り込み処理は、ＩＴＲＯＮ上で動作するネイティブコードで書かれたプログラムであると解されるから、
　引用文献１に記載のＲＴＯＳであるＩＴＲＯＮとは、ネイティブコードで書かれたプログラムであるデバイスドライバや割り込み処理を実行する環境であること
が解される。
　また、上記（イ）の「Ｊａｖａの最大の魅力の一つは，安くて豊富にあるパソコン上の開発ツールと，ＣＰＵやＯＳに依存しない高い互換性にあります．」との記載、及び、上記（ウ）の「これが，ＪＴＲＯＮにおいてＪａｖａのプラットホーム独立というメリットが守られている理由です．」との記載から、
　引用文献１に記載のＪａｖａ実行環境は、ＣＰＵやＯＳといったプラットフォームに依存しない実行環境
であることが読み取れ、また、図３の図示から、
　引用文献１に記載のＪａｖａ実行環境は、２つのＪａｖａアプリケーションを実行する実行環境でもある
と解される。
　さらに、上記（ア）の「ＪＴＲＯＮ（Ｊａｖａ　Ｔｅｃｈｎｏｌｏｇｙ　ｏｎ　ＩＴＲＯＮ）仕様リアルタイムＯＳ「ＪＢｌｅｎｄ」は，組み込み制御分野で使われているＩＴＲＯＮ仕様を出発点とし，機器制御における課題を克服するための要素技術という観点からＪａｖａを利用しています．」との記載、上記（ウ）の「ＩＴＲＯＮのリアルタイム制御機能を利用したＪａｖａアプリケーションを作成して動作させることができます．」との記載から、
　引用文献１に記載のＪＢｌｅｎｄ、及びＪａｖａアプリケーションは、どちらも組み込み機器の制御を行うためのプログラムであること
が読み取れ、上記（イ）の「安価で手軽な開発環境を使ったプロトタイピングより一歩進んだ開発を可能とする方法としては，エミュレーション環境で検証してクロスコンパイルする方法があります．この場合，ユーザーインターフェースのライブラリを使うか，ＷｉｎｄｏｗｓのようなスケーラブルなＯＳを使うことが考えられますが，どちらもクロスコンパイルしないと実機上では動作しません．クロスコンパイルの最大の欠点は，ＣＰＵやＯＳの微妙な違いによる「似て非なる動作」が発見しにくいことです．
（中略）
　この特性のおかげで，ＰＣ上で正しく動作しているものを実機にもっていったときに誤動作するようなら，Ｊａｖａではないといえることになります．」という、ＰＣ上で実機をエミュレーション環境で開発することの記載、及び、上記（エ）の「・ハードウェアの逝去部分は，従来の方法で開発できる．開発環境も従来のもの（ミドルウェア，ＩＣＥ，Ｃコンパイラ，アセンブラ・・・）がそのまま使える
・パソコン上で，Ｊａｖａにより開発できる．
・ハードウェアとのインターフェース部分については，ドライバとのインターフェースを決めて，ドライバのダミーモジュールを作ればよい
例）プリンタのエミュレーションは，データをダミーモジュールに渡すだけになる．ダミーモジュールはプリントしたふりをすればよい．スキャナのエミュレーションの場合なら，ダミーの画像データを返すだけでよい」という、開発においてエミュレーションされるものはプリンタやスキャナであることを示す記載、並びに、上記（イ）の「たとえばＪＴＲＯＮ仕様ＯＳ「ＪＢｌｅｎｄ」を使うと，画像処理のように高速処理が必要な部分はもっとも速いネイティブコードで書くことができます．」との記載を併せれば、引用文献１に記載されたＪＢｌｅｎｄが用いられる対象の組み込み機器は、少なくともプリンタあるいはスキャナを含むものと解される。
　以上をまとめると、引用文献１には、
　ネイティブコードで書かれたプログラムであるデバイスドライバや割り込み処理を実行する環境であるＩＴＲＯＮと、ＣＰＵやＯＳといったプラットフォームには依存しない実行環境であって、組み込み機器の制御を行うための２つのＪａｖａアプリケーションを実行するＪａｖａ実行環境とが併存し、プリンタあるいはスキャナを少なくとも含む組み込み機器の制御を行うためのプログラムであるＪＢｌｅｎｄ
について記載されたものと認められる。
　
（ｂ）上記（オ）の「ＪＢｌｅｎｄを大きく分けると，Ｊａｖａの実行環境部分とＩＴＲＯＮ部分（ＩＴＲＯＮ仕様準拠カーネル）の二つで構成されています．この二つのつなぎ目の部分が，「ＰＡＬ（Ｐｒｏｃｅｓｓｏｒ　Ａｂｓｔｒａｃｔｉｏｎ　Ｌａｙｅｒ）」と呼ばれるものです（開発：アプリックス）．ＰＡＬとは，Ｊａｖａ実行環境のＣＰＵ依存部分に設けた独自の抽象化層で，これによりＩＴＲＯＮ仕様準拠のカーネルがＣＰＵのデバイスドライバとして動作します（図６）．」との記載、及び、上記（ケ）の図６の図示とを併せると、引用文献１に記載のＪＢｌｅｎｄは、ＩＴＲＯＮカーネルにタスク操作システムコール及びセマフォ操作システムコールを含むこと、及び、Ｊａｖａ実行環境からＣＰＵ依存部分に設けられるＰＡＬを介して当該システムコールを呼び出すことにより、ＣＰＵの制御を行うことが読み取れ、上記（キ）のＲＴＯＳ、デバイスドライバ、割り込み処理がネイティブコードで書かれることの図示、及び、上記（ク）のＩＴＲＯＮカーネル等がＣＰＵにより実行されることの図示からみて、ＩＴＲＯＮカーネルのこれらシステムコールも、ＩＴＲＯＮ上でネイティブコードの状態で実行されるものであることも読み取れるから、引用文献１には
　ＪＢｌｅｎｄが、ＩＴＲＯＮ上でネイティブコードの状態で実行され、ＣＰＵを制御するために、Ｊａｖａ実行環境からＣＰＵ依存部分に設けられるＰＡＬを介して呼び出される、ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコールを含む
ことが記載されたものと認められる。
　
（ｃ）上記（オ）の記載、及び上記（ケ）の図６の図示とを併せると、引用文献１に記載のＪＢｌｅｎｄは、Ｊａｖａ実行環境から、ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォ操作システムコールと通信するためのインターフェースを提供するためのＰＡＬを含むものと解され、当該ＰＡＬは、Ｊａｖａ実行環境で使われている関数名をそのままインターフェースとして使用するものであると解される。
　以上で検討したことから、引用文献１には、以下の発明（以下、「引用発明」という。）が記載されている。
　
　ネイティブコードで書かれたプログラムであるデバイスドライバや割り込み処理を実行する環境であるＩＴＲＯＮと、ＣＰＵやＯＳといったプラットフォームには依存しない実行環境であって、組み込み機器の制御を行うための２つのＪａｖａアプリケーションを実行するＪａｖａ実行環境とが併存し、プリンタあるいはスキャナを少なくとも含む組み込み機器の制御を行うためのプログラムであるＪＢｌｅｎｄであって、
　前記ＪＢｌｅｎｄは、ＩＴＲＯＮ上でネイティブコードの状態で実行される、ＣＰＵを制御するために、Ｊａｖａ実行環境からＣＰＵ依存部分に設けられるＰＡＬを介して呼び出される、ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコールと、
　Ｊａｖａ実行環境から、ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォ操作システムコールと通信するためのインターフェースを提供するためのＰＡＬを含み、
　前記ＰＡＬは、Ｊａｖａ実行環境で使われている関数名をそのままインターフェースとして使用するものである
プログラムであるＪＢｌｅｎｄ。
　
Ｂ．本願出願前に周知の技術
（ａ）特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリについて
　本願の出願日前に頒布された刊行物である特開２０００−１６５６１２号公報の【００３７】段落−【００３９】段落に記載の、ＩＴＲＯＮ準拠のＯＳから構築されるファクシミリ装置において、スキャナ制御部４５、プリンタ制御部４６等の制御タスクがＯＳ上で管理されて実行される例、あるいは、同じく本願の出願日前に頒布された刊行物である特開平８−２５１３２４号公報の【００３０】段落−【００３５】段落に記載の、デジタル複写機において、原稿から画像形成を行い複写を行うという動作を、読み込み要求に対してスキャナ部からメモリへの書込タイミングを制御する書込制御機能、給紙要求に対して転送紙搬送及び現像タイミングを制御する搬送制御機能、及び、画像読出要求に対してメモリ装置から画像を読み出すタイミングを制御する読出制御機能というＩＴＲＯＮを用いた各タスクにより実行する例のように、特定の印刷プロトコルに従い画像形成装置のＣＰＵ（画像処理エンジン）を制御するためのタスクをＩＴＲＯＮ上で管理して実行することは、画像形成装置の技術分野において周知の技術事項であり、ソフトウェアライブラリの実行形態を指す用語である「タスク」を管理して実行するということは、タスクに対応するソフトウェアライブラリを呼び出してＯＳ上で実行することに他ならないから、特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するためのソフトウェアライブラリを呼び出してＯＳ上で実行することは、ＩＴＲＯＮを用いた画像形成装置の技術分野において周知の技術事項（以下、「周知技術事項１」という。）といえる。
　
（ｂ）複数のコマンドの組み合わせをひとつのコマンドにみなすことに関して
　本願の出願日前に頒布された刊行物である特開平１１−１７５３９０号公報の【００４５】段落に「使用されるメディア・デバイスのタイプに従って、前記の個別ＡＰＩの或るものは、多数のアクションへ変換される必要があり、それらのアクションは前記の個別ＡＰＩの他の或るものを使用する。たとえば、ＬＯＡＤ ＡＰＩは、ＯＰＥＮ ＡＰＩ、ＣＯＰＹ＿ＭＥＤＩＡ ＡＰＩ、ＳＥＴ＿ＭＥＤＩＡ＿ＡＴＴＲＩＢＵＴＥ ＡＰＩ、およびＣＬＯＳＥ ＡＰＩを使用しなければならない一群のアクションへ変換される。次に、その一群のアクションは、特定のメディア・デバイス２５に対応するデバイス・レベル・コマンドへ変換される。メディア・デバイス２５の特定のハードウェア実施に従って、これらのデバイス・レベル・コマンドは、一群のアクションと関連して言及した個別ＡＰＩに一対一で対応する。したがって、ＬＯＡＤ ＡＰＩに関連したデバイス・レベル・コマンドは、前記の個別ＡＰＩに対応したＯＰＥＮコマンド、ＣＯＰＹコマンド、少なくとも１つのＳＥＴ＿ＡＴＴＲＩＢＵＴＥコマンド、およびＣＬＯＳＥコマンドを含む。」と記載（以下、「引用記載」という。）されているように、
　アプリケーションから呼び出されるインターフェース（ＡＰＩ）を使用する技術分野において、
　一つの命令（引用記載における「ＬＯＡＤ　ＡＰＩ」）に、ソフトウェアライブラリの一部を構成し、デバイスを制御するためのソフトウェアライブラリの一部にそれぞれ対応する複数のコマンド（引用記載における「ＯＰＥＮコマンド、ＣＯＰＹコマンド、少なくとも１つのＳＥＴ＿ＡＴＴＲＩＢＵＴＥコマンド、およびＣＬＯＳＥコマンド」）を対応付け、その複数のコマンドの組合わせ（引用記載における「一群のアクション」）をひとつのコマンド（引用記載における「ＬＯＡＤ　ＡＰＩに関連したデバイス・レベル・コマンド」）とみなし、上記一つの命令を用いて当該複数のコマンドを呼び出し可能とする
ことは本願出願前に周知の技術事項（以下、「周知技術事項２」という。）である。
　
（３）対比
　引用発明と補正後の発明とを対比する。
　引用発明の「プリンタあるいはスキャナを少なくとも含む組み込み機器」は、補正後の発明の「画像形成装置」に相当し、引用発明の「ＣＰＵ」は、補正後の発明の「画像形成装置の画像処理エンジン」に相当する。
　引用発明の「ネイティブコードで書かれたプログラムであるデバイスドライバや割り込み処理」における「デバイスドライバ」や「割り込み処理」とは、組み込み機器を制御するプログラムであり、また、ネイティブコードで書かれたプログラムを実行することは、ネイティブモードでプログラムを実行することに他ならないから、引用発明の「ネイティブコードで書かれたプログラムであるデバイスドライバや割り込み処理を実行する環境であるＩＴＲＯＮ」は、補正後の発明の「ネイティブモードで制御プログラムを実行する第１の実行環境」に相当する。
　引用発明の「ＣＰＵやＯＳといったプラットフォームには依存しない」は、補正後の発明の「画像形成装置の機種に非依存である」に相当し、引用発明の「組み込み機器の制御を行うための２つのＪａｖａアプリケーション」が、組み込み機器の機種には依存しないプログラムであることは明らかであるから、引用発明の「組み込み機器の制御を行うための２つのＪａｖａアプリケーションを実行するＪａｖａ実行環境」は、補正後の発明の「画像形成装置の機種に非依存である制御プログラムである複数のアプリケーションを実行する第２の実行環境」に相当する。
　そして、引用発明の「・・・ＩＴＲＯＮと、・・・Ｊａｖａ実行環境とが併存」することは、補正後の発明の「・・・第１の実行環境と、・・・第２の実行環境とが共存」することに相当する。
　
　引用発明の「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」に関し、「ＩＴＲＯＮ上でネイティブコードの状態で実行される」ことは、補正後の発明の「第１の実行環境上でネイティブモードで実行される」ことに相当し、引用発明の「ＣＰＵを制御するために、Ｊａｖａ実行環境からＣＰＵ依存部分に設けられるＰＡＬを介して呼び出される」ことは、補正後の発明の「画像形成装置の画像処理エンジンを制御するために呼び出される」ことに相当し、”ＩＴＲＯＮカーネルのシステムコール”という用語は、ＯＳカーネルであるＩＴＲＯＮカーネルを構成するソフトウェアライブラリの一部分により実現されるものを指す用語であることからすれば、引用発明の「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」と、補正後の発明の「第１の実行環境上でネイティブモードで実行される、特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリ」とは、”第１の実行環境上でネイティブモードで実行される、画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリ”である点で一致する。
　引用発明の「Ｊａｖａ実行環境」は、補正後の発明の「機種非依存の第２の実行環境」に相当し、引用発明の「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」は、ＰＡＬを介してＪａｖａ実行環境から呼び出すことができるものであり、また、情報処理技術分野（ＯＳ上で動作するアプリケーションを開発し実行する技術に関する分野）の技術常識からみて、システムコールとは、複数のアプリケーションで共用されることを想定して用意し公開されるものといえるから、引用発明の「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」は、補正後の発明の「機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリであって、複数のアプリケーションにより共用されるソフトウェアライブラリ」に相当し、さらに、引用発明における「Ｊａｖａ実行環境から、ＩＴＲＯＮカーネル内のタスク操作システムコール及びセマフォ操作システムコールと通信するためのインターフェースを提供するためのＰＡＬ」は、補正後の発明の「機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリであって、複数のアプリケーションにより共用されるソフトウェアライブラリに対してアクセスするためのインターフェースプログラム」に相当する。
　
　そして、引用発明の「ＪＢｌｅｎｄ」は、組み込み機器を制御するためのプログラムであって、「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」及び「ＰＡＬ」を含むものであるから、補正後の発明の「制御プログラム」と、”画像形成装置を制御する制御プログラムであって、ソフトウェアライブラリと、インターフェースプログラムを含むプログラム”である点で一致する。
　
　さらに、引用発明の「ＰＡＬは、Ｊａｖａ実行環境で使われている関数名をそのままインターフェースとして使用する」における「Ｊａｖａ実行環境で使われている関数名」は、補正後の発明の「命令」に相当し、引用発明の「ＰＡＬは、Ｊａｖａ実行環境で使われている関数名をそのままインターフェースとして使用する」ことと、補正後の発明の「前記インタフェースプログラムに含まれる少なくともひとつの命令には、前記ソフトウェアライブラリの一部である、画像処理エンジンを制御するための複数のコマンドが対応付けられており、その複数のコマンドの組合せをひとつのコマンドとみなし、前記一つの命令を用いて当該複数のコマンドを呼び出し可能である」こととは、”インタフェースプログラムが命令を含むものである”という点では一致する。
　
　したがって、補正後の発明と引用発明とは、以下の点で一致し、また相違する。
　
（一致点）
　ネイティブモードで制御プログラムを実行する第１の実行環境と、画像形成装置の機種に非依存である制御プログラムである複数のアプリケーションを実行する第２の実行環境とが共存する画像形成装置を制御する制御プログラムにおいて、
　前記制御プログラムは、第１の実行環境上でネイティブモードで実行される、画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリと、機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリであって、複数のアプリケーションにより共用されるソフトウェアライブラリに対してアクセスするためのインターフェースプログラムを含み、
　前記インタフェースプログラムが命令を含むものである
制御プログラム
　
（相違点）
（相違点１）
　補正後の発明の「ソフトウェアライブラリ」は、「特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出される」ものであるのに対して、引用発明の「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」は、特定の印刷プロトコルに従ってＣＰＵを制御するために呼び出されるものとはいえない点。
　
（相違点２）
　補正後の発明の「インタフェースプログラムに含まれる少なくとも一つの命令」には、「ソフトウェアライブラリの一部である、画像処理エンジンを制御するための複数のコマンドが対応付けられており、その複数のコマンドの組合せをひとつのコマンドとみなし、前記一つの命令を用いて当該複数のコマンドを呼び出し可能である」のに対し、引用発明の「ＰＡＬ」が使用する「関数名」ではその点は明らかではない点。
　
（相違点３）
　補正後の発明は、「ソフトウェアライブラリ」及び「インターフェースプログラム」と共に、第２の実行環境で実行される、画像形成装置の機種に非依存である「複数のアプリケーション」を含めて「制御プログラム」としているのに対して、引用発明は、「ＩＴＲＯＮカーネルのタスク操作システムコール及びセマフォシステムコール」及び「ＰＡＬ」を含む「ＪＢｌｅｎｄ」と「組み込み機器の制御を行うための２つのＪａｖａアプリケーション」とを含めて「制御プログラム」とはしていない点。
　
（４）判断
　上記相違点について判断する。
（相違点１）について
　特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するためのソフトウェアライブラリを呼び出してＯＳ上で実行することは、ＩＴＲＯＮを用いた画像形成装置の技術分野において周知の技術事項（周知技術事項１）であり、また、引用発明は、画像処理をネイティブコードの状態で実行されるＣＰＵ依存部分とすることも示唆するものである（例、上記（２）Ａ．（イ）中の、「ＪＴＲＯＮ使用ＯＳ「ＪＢｌｅｎｄ」を使うと、画像処理のように高速処理が必要な部分はもっとも速いネイティブコードで書くことができます。」、上記（２）Ａ．（カ）の、デバイスドライバがＣＰＵ依存部分であってネイティブコードで書かれ、ＲＴＯＳで動作することの図示）ことを考慮すれば、引用発明において、Ｊａｖａ実行環境からＣＰＵ依存部分に設けられるＰＡＬを介して呼び出されてＩＴＲＯＮ上で実行されるソフトウェアライブラリとして、特定の印刷プロトコルに従いプリンタ又はスキャナのＣＰＵを制御するためのソフトウェアライブラリを採用することは当業者が容易に想到し得た事項である。
　したがって、相違点１は格別のものではない。
　
（相違点２）について
　一つの命令に複数のコマンドを対応付けた上、その複数のコマンドの組合せをひとつのコマンドとみなし、当該一つの命令を用いて複数のコマンドを呼び出し可能とすることは、マクロ命令に見られるように情報処理技術分野において広く知られた事項であり、情報処理技術分野のうちアプリケーションから呼び出されるインターフェース（ＡＰＩ）を使用する技術分野においても、一つの命令に、ソフトウェアライブラリの一部を構成し、デバイスを制御するためのソフトウェアライブラリの一部にそれぞれ対応する複数のコマンドを対応付け、その複数のコマンドの組合わせをひとつのコマンドとみなし、上記一つの命令を用いて当該複数のコマンドを呼び出し可能とすることは本願出願前に周知の技術事項（周知技術事項２）である。
　そうすると、引用発明においてＪａｖａ実行環境で使われている関数名をそのままインターフェースとして使用するＰＡＬについても、当該ＰＡＬがインターフェースとして使用する関数名のうち、ある一つの関数名にＣＰＵを制御するためのソフトウェアライブラリの一部を構成する複数のコマンドを対応付けた上、その複数のコマンドを一つのコマンドとみなし、当該一つの関数名を用いて当該複数のコマンドを呼び出し可能であるよう構成することは、上記情報処理技術分野において広く知られた事項を考慮することにより当業者が容易に想到し得た事項といえる。
　したがって、相違点２は格別のものではない。
　
（相違点３）について
　引用発明において、共に組み込み機器の制御を行うためのプログラムである「組み込み機器の制御を行うための２つのＪａｖａアプリケーション」と「ＪＢｌｅｎｄ」とを含めて「制御プログラム」とすることは、当業者にとって容易に行い得る事項である。
　したがって、相違点３は格別のものではない。
　
　上記で検討したごとく、相違点１乃至相違点３は格別のものではなく、そして、補正後の発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
  
　以上のとおり、補正後の発明は、引用発明及び周知の技術事項に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項の規定により準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成１９年７月２０日付けの手続補正は上記のとおり却下されたので、本願の請求項４に係る発明（以下、「本願発明」という。）は、平成１９年４月２０日付けの手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項４に記載された以下のとおりのものと認める。
「ネイティブモードで制御プログラムを実行する第１の実行環境と、画像形成装置の機種に非依存である制御プログラムを実行する第２の実行環境とが共存する画像形成装置を制御する制御プログラムにおいて、
　前記制御プログラムは、第１の実行環境上でネイティブモードで実行される、特定の印刷プロトコルに従い画像形成装置の画像処理エンジンを制御するために呼び出されるソフトウェアライブラリと、機種非依存の第２の実行環境から呼び出すことが出来る前記ソフトウェアライブラリに対してアクセスするためのインターフェースプログラムを含み、
　前記インタフェースプログラムに含まれる少なくともひとつの命令には、前記ソフトウェアライブラリの一部である、画像処理エンジンを制御するための複数のコマンドが対応付けられており、その複数のコマンドの組合せをひとつのコマンドとみなし、前記一つの命令を用いて当該複数のコマンドを呼び出し可能であることを特徴とする制御プログラム。」
　
２．引用発明及び周知技術
　引用発明及び周知の技術事項は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明及び周知技術」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は上記補正後の発明から「画像形成装置の機種に非依存である制御プログラム」が、「複数のアプリケーション」であるとする限定を省き、「機種非依存の第２の実行環境から呼び出すことが出来るソフトウェアライブラリ」が、「複数のアプリケーションにより共用されるソフトウェアライブラリ」であるとする限定を省いたものである。
　そうすると、本願発明の構成に上記限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明及び周知の技術事項に基づいて容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知の技術事項に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。