【事件の表示】
　特願２００５−　２３５０５「画像形成装置、情報処理方法、及び制御プログラム」拒絶査定不服審判事件〔平成１７年　８月　４日出願公開、特開２００５−２０９２１３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
平成１７年　１月３１日に、特願２００２−０１１４６６号（平成１４年１月２１日出願。）の一部を新たな特許出願とする分割出願として出願され、
平成１８年１１月１４日付けで手続補正がなされ、
同年１２月　４日付けで最初の拒絶理由通知がなされ、
平成１９年　２月　９日付けで意見書が提出されるとともに、
同日付で手続補正がなされ、
同年２月２８日付けで最後の拒絶理由通知がなされ、
同年５月１日付けで意見書が提出されるとともに、
同日付で手続補正がなされ、
同年５月２１日付けで該５月１日付け手続補正について補正却下の決定がなされるとともに、
同日付けで拒絶査定がなされ、
同年７月５日付けで、上記補正却下の決定に対する不服申立を伴う拒絶査定不服審判が請求されたものである。
　
　
　
第２．補正却下の決定の適否
　請求人は平成１９年５月２１日付けの補正却下の決定に不服を申立ているので、その適否について検討する。
　
　
１．補正却下の決定の対象となった補正の内容
　本件補正却下の決定の対象となった平成１９年５月１日付けの手続補正書による補正（以下「本件補正」と記す。）は、特許請求の範囲について、補正前に
「　【請求項１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置において、
　アプリケーションごとに使用量を管理するカウンタと、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理手段とを有する画像形成装置。
　　【請求項２】
　インストールされるアプリケーションを対応付けることが出来るカウンタを特定する特定手段と、
　前記特定手段が、前記アプリケーションを対応付けることができるカウンタを特定できなかった場合には、前記使用量管理手段は、新しくカウンタを作成して前記入力されたアプリケーションを対応付けることを特徴とする請求項１に記載の画像形成装置。
　　【請求項３】
　前記使用量管理手段は、前記特定手段が特定したカウンタを初期化することを特徴とする請求項２に記載の画像形成装置。
　　【請求項４】
　前記使用量管理手段は、前記アプリケーションを実行した回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至３のいずれか１項に画像形成装
置。
　　【請求項５】
　前記使用量管理手段は、前記アプリケーションを使用した時間により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至４のいずれか１項に画像形成装置。
　　【請求項６】
　前記使用量管理手段は、前記アプリケーションが引き起こした画像形成装置の所定動作の回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至５のいずれか１項に画像形成装置。
　　【請求項７】
　前記使用量管理手段は、前記画像形成装置が提供する機能と、前記画像形成装置が提供する機能を利用する前記アプリケーションとの組合せにより使用量を管理することを特徴とする請求項１乃至６のいずれか１項に画像形成装置。
　　【請求項８】
　前記使用量管理手段は、前記アプリケーションに対応する識別子と前記カウンタに対応する識別子とを対応づけるテーブルを用いて、前記カウンタを管理することを特徴とする請求項１乃至７のいずれか１項に画像形成装置。
　　【請求項９】
　前記画像形成装置は、アプリケーションの属性情報を所定の通信媒体を介して外部から取得する取得手段を有し、
　前記取得手段によって取得されたアプリケーションを使用するためのカウントアップ情報と、前記アプリケーションの属性情報に対応したアプリケーションを前記画像形成装置内に導入するか否かの指示を入力するための入力部を表示する処理を制御する表示制御手段を有することを特徴とする請求項１乃至８のいずれか１項に画像形成装置。
　　【請求項１０】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法において、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理工程とを画像形成装置が実行する情報処理方法。
　　【請求項１１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法を画像処理装置に実行させる制御プログラムであって、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を画像形成装置が管理する使用量管理工程を情報処理方法を、画像処理装置に実行させる制御プログラム。」
とあったものを、
「　【請求項１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置において、
　アプリケーションごとに使用量を管理するカウンタと、
　前記オペレーティングシステム上で動作するインタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理手段とを有する画像形成装置。
　　【請求項２】
　インストールされるアプリケーションを対応付けることが出来るカウンタを特定する特定手段と、
　前記特定手段が、前記アプリケーションを対応付けることができるカウンタを特定できなかった場合には、前記使用量管理手段は、新しくカウンタを作成して前記入力されたアプリケーションを対応付けることを特徴とする請求項１に記載の画像形成装置。
　　【請求項３】
　前記使用量管理手段は、前記特定手段が特定したカウンタを初期化することを特徴とする請求項２に記載の画像形成装置。
　　【請求項４】
　前記使用量管理手段は、前記アプリケーションを実行した回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至３のいずれか１項に画像形成装置。
　　【請求項５】
　前記使用量管理手段は、前記アプリケーションを使用した時間により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至４のいずれか１項に画像形成装置。
　　【請求項６】
　前記使用量管理手段は、前記アプリケーションが引き起こした画像形成装置の所定動作の回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至５のいずれか１項に画像形成装置。
　　【請求項７】
　前記使用量管理手段は、前記画像形成装置が提供する機能と、前記画像形成装置が提供する機能を利用する前記アプリケーションとの組合せにより使用量を管理することを特徴とする請求項１乃至６のいずれか１項に画像形成装置。
　　【請求項８】
　前記使用量管理手段は、前記アプリケーションに対応する識別子と前記カウンタに対応する識別子とを対応づけるテーブルを用いて、前記カウンタを管理することを特徴とする請求項１乃至７のいずれか１項に画像形成装置。
　　【請求項９】
　前記画像形成装置は、アプリケーションの属性情報を所定の通信媒体を介して外部から取得する取得手段を有し、
　前記取得手段によって取得されたアプリケーションを使用するためのカウントアップ情報と、前記アプリケーションの属性情報に対応したアプリケーションを前記画像形成装置内に導入するか否かの指示を入力するための入力部を表示する処理を制御する表示制御手段を有することを特徴とする請求項１乃至８のいずれか１項に画像形成装置。
　　【請求項１０】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法において、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理工程とを画像形成装置が実行する情報処理方法。
　　【請求項１１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法を画像処理装置に実行させる制御プログラムであって、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を画像形成装置が管理する使用量管理工程を情報処理方法を、画像処理装置に実行させる制御プログラム。」
と補正（即ち、独立請求項１、１０、１１における所定のカウンタ制御アプリケーション・プログラム・インタフェースを「インタプリタ上に設けられた」ものであるとする発明を特定するための事項（以下「発明特定事項」と記す。）を「インタプリタと同じ階層に設けられた」ものであるとする発明特定事項に補正）しようとするものである。
　
　
２．補正却下の決定の理由
　これに対して、上記平成１９年５月２１日付け補正却下の決定（以下「本件補正却下の決定」と記す。）の理由は
「本願出願人は、平成１９年５月１日付け手続補正書において、請求項１、１０及び１１における「インタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」を、「インタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」と補正している。
　しかし、当該補正は、請求項の削除及び明りようでない記載の釈明を目的とするものでないことは明らかであり、また、誤記の訂正を目的とするものともいえず、”インタプリタ上に設けられたカウンタ制御アプリケーション・プログラム・インタフェース”を削除する補正でもあるから、特許請求の範囲の減縮を目的とするものともいえない。
　したがって、この補正は、特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第１７条の２第４項の規定に違反するものであるから、同法第５３条第１項の規定により、上記結論の通り決定する。」
と言うものである。
　
　
３．当審判断
　本件補正前の特許請求の範囲の請求項１、１０、１１における「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」なる記載からは、先ず最下層に「オペレーティングシステム」が存在し、該「オペレーティングシステム」の上に「インタプリタ」が、当該「インタプリタ」の上に「カウンタ制御アプリケーション・プログラム・インタフェース」と言う、明確な３層の階層構造を有する画像形成装置・情報処理方法・制御プログラムの発明が明確に特定できる。
　してみると、本件補正前の請求項１、１０、１１の記載自体は明確であり、発明も技術的に明りょうに特定されているのであり、その記載本来の意味内容がこれとは異なるものであると解釈する余地はない。
　その上、本件補正後の特許請求の範囲の請求項１における「前記オペレーティングシステム上で動作するインタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」なる記載からは、先ず最下層に「オペレーティングシステム」が存在し、該「オペレーティングシステム」の上に「インタプリタ」と「カウンタ制御アプリケーション・プログラム・インタフェース」が同じ階層に位置すると言う、上記の補正前の発明とは明らかに異なる階層構造を有する画像形成装置・情報処理方法・制御プログラムの発明が明確に特定でき、本件補正前の審査・審理の対象と本件補正後の審査・審理の対象は明らかに異なるものになっている。
　従って、本件補正を「明りょうでない記載の釈明」であるとも「誤記の訂正」であるとも認めることはできない。
　
　また、本件補正が「請求項の削除」「請求項の限定的減縮」に該当しないことも明らかである。
　
　従って、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の各号に掲げるいずれの事項を目的とするものにも該当せず、同法第１７条の２第４項の規定に違反するものである。
　
　また、他に本件補正却下の決定を不適法とする理由も見あたらない。
　
　
４．請求人の主張
　なお、請求人は、審判請求書において、上記本件補正却下の決定が取り消されるべき理由として、
「今回の「インタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」を、「インタプリタと同じ階層に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」という補正は、明瞭な記載の釈明であり、また、誤記の訂正でもあると存じます。明細書内にそれとわかる記載がありながら、不明瞭な記載または誤記となっていた記載をそれと分かる記載に正したのに過ぎません。よって、かかる補正は１７条の２第５項に合致する適法な補正であります。仮に、誤記若しくは明瞭でない記載の釈明でないとしても、特許審査基準第３部第３節には、「１．基本的考え方　第１７条の２第５項の規定は、発明の保護を十全に図るという特許制度の基本目的を考慮しつつ、迅速・的確な権利付与を確保する審査手続を確立するために、最後の拒絶理由通知に対する補正は、既に行った審査結果を有効に活用できる範囲内で行うこととする趣旨で設けられたものである。そして、この規定に違反する補正は、新規事項を追加するものとは異なり、発明の内容に関して実体的な瑕疵をもたらすものではないことから、それが看過されて拒絶査定又は特許査定がされた後は、遡って補正を却下することはしないこととされており、第１７条の２第５項の規定は第３項の規定とは性格を異にすると解される。したがって、第５項の規定の適用にあたっては、その立法趣旨を十分に考慮し、本来保護されるべきものと認められる発明について、既に行った審査結果を有効に活用して最後の拒絶理由通知後の審査を迅速に行うことができると認められる場合についてまでも、必要以上に厳格に運用することがないようにする。　」と記載されています。
　審査官殿は、審査請求後、一度もサーチを行った形跡がありません。よって、そもそも審査のやり直しになることはありえません。よって、今回の補正後の発明については、審査請求後サーチをすべきであったと考えます。この点で５３条の適用を誤ったといわざるを得ません。しかも、先の拒絶理由で、　審査官殿は、「カウンタ制御アプリケーション・プログラム・インタフェースとインタプリタとが、同一のソフトウェアモジュール階層に置かれていることは明細書第００４６段落の記載及び同図面図９の記載から読み取れる」という補正の示唆と取れるご指摘をされました。出願人はそのように補正したところ、指摘のように補正すると今まで一度もサーチをしていなかったにもかかわらず、補正却下をなされました。出願人としては少々驚いています。
　そもそも、特許制度は発明を奨励し、発明の保護および利用を図り、産業の発達に寄与することを目的とするもの（１条）です。よって、そもそも審査官とは、そもそも、特許要件を満たす特許は特許をし、特許要件を満たさない特許については拒絶をすることで、発明の保護、及び、奨励のために存在するものと考えます。このように考えると、今回の補正却下は、１７条の２第５項の適用を必要以上に厳格に適用し、結果として、法１条の目的にも合致しない審査を行ったものと考えられます。
　すなわち、新規事項の追加となった箇所を、最後の拒絶理由の通知時に、誤記若しくは明瞭でない記載の釈明を目的とするか、しないかに関わらず、補正で取り除くことが許されない、という拒絶査定は、５３条の解釈を誤ったものといわざるを得ません。今回のような補正却下を適法とすれば、今回のような事例では、拒絶理由の後に新規事項となった場合の最後の拒絶理由について、出願人はどのような補正をしても補正却下を受けるという不合理な結果をもたらします。
　よって、審査官殿の補正却下の決定は、迅速的確な権利付与を行う旨の５３条の法の趣旨合致せず、取り消されるべきものであると考えます。」
と主張している。
　
　しかしながら、特許法第１７条の２第４項の規定の趣旨は、請求人も述べるように、最後の拒絶理由の通知に応答する補正を「既に行った審査結果を有効に活用できる範囲内で行うもの」とすることにあるのであるから、当該規定における「明りょうでない記載の釈明」あるいは「誤記の訂正」は、審査・審理の対象を変更するものであってはならないのであって、単に「明細書内にそれとわかる記載」があることをもって、「明りょうでない記載の釈明」や「誤記の訂正」であると認めることは、当該規定の趣旨に反する。
　また、出願内容が著しく不明確な出願や願書に最初に添付した明細書・特許請求の範囲又は図面に記載した事項の範囲内にないことが明らかである発明については、その先行技術文献調査をすることなく拒絶理由を通知することは、迅速・的確な権利付与を確保する審査手続を確立すると言う同規定の目的にも合致する当然に許容されるべき運用であるから、サーチがなされていないからといって審査がなされていないと言う請求人の主張も到底認め得るものではない。
　さらに、最後の拒絶理由における「カウンタ制御アプリケーション・プログラム・インタフェースとインタプリタとが、同一のソフトウェアモジュール階層に置かれていることは明細書第００４６段落の記載及び同図面図９の記載から読み取れる」なる記載は、本願請求項１に係る発明が新規事項追加に該当する旨を説明するためのものにほかならないことは明らかであり、これを補正の示唆と解する請求人の主張も到底認め得るものではない。
　そして、出願人の主張するように本件補正の如き最後の拒絶理由に対して審査・審理の対象を変更する補正を適法とすることは、結果的に１の出願において３つの発明についての審査を行うことになり、当初から完全な内容の明細書等を提出する真当な出願との間に著しい不公平を生じことになるのであるから、到底適切な運用とは言えず、しかも最後の拒絶理由通知に対して出願の分割をすると言う対抗手段もあるのであるから、本件補正却下の決定が「不合理な結果をもたらす」という請求人の主張も到底認め得るものではない。
　
　よって、審判請求書における上記請求人の主張は、いずれも到底認め得るものではなく、これを根拠に本件補正却下を不適法とすることは到底できない。
　
　
５．小結
　以上の通りであるから、本件補正を特許法第法第５３条第１項の規定により却下するとした、本件補正却下の決定は適法なものであり、これを取り消すことはできない。
　
　
　
第３．本願の出願日の遡及について
　本願は、特願２００２−０１１４６６号（以下「原出願」と記す。）の一部を新たな特許出願とする分割出願として出願されたものであるので、以下にその出願日の遡及について検討する。
　
　
１．本願の明細書等の記載内容
　上記第２．記載の通り、平成１９年５月２１日付けでなされた、同年５月１日付け手続補正についての補正却下の決定を取り消すことはできないので、本願請求項１〜１１に係る発明は、平成１９年２月９日付け手続補正書により補正された特許請求の範囲の請求項１〜１１（上記第２．１．において補正前の特許請求の範囲として示したもの）に記載された通りのものであると認められるところ、その請求項１、１０、１１には
「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」
なる発明特定事項が記載されている。
　
　
２．原出願の当初明細書等の記載内容
原出願の願書に最初に添付した明細書及び図面（以下「原出願の当初明細書等」と記す。）には以下の通り記載されている。
　
（１）　「【００３６】図２は、第一の実施形態における画像形成装置のソフトウェアモジュール階層の好適な一例を示した図である。ソフトウェアモジュールはオペレーティングシステム（OS）２０１を有している。ＯＳ２０１の上には、各種機器制御のためのコントローラモジュール２０２を有し、その上にプログラムを逐次実行するためのインタプリタモジュール２０３を有する。インタプリタモジュール２０３の上には、動的に着脱可能な複数のアプリケーション群を管理するためのアプリケーション管理モジュール２０４を有する。各種機能を実現するアプリケーション２０５は、このアプリケーション管理モジュール２０４の管理下で動作する。インタプリタモジュール２０３を介して複写機のサービスを提供するためのアプリケーションモジュールを動作させることができる。例えば、外部サーバ装置から取得したアプリケーションモジュールが画像形成装置内に組み込まれるのに応答して、アプリケーション管理モジュール２０４はアプリケーション２０５を管理対象として追加したり、画像形成装置内からアプリケーションプログラムが削除されるのに応答して、アプリケーション管理モジュール２０４はアプリケーション２０５を管理対象から外すことができる。」
　
（２）「【００６１】図９は、第二の実施形態における複写機１００のソフトウェアモジュール階層の構成を示す図である。ソフトウェアモジュールはオペレーティングシステム（OS）９０１を有している。OS９０１の上には、各種機器制御のためのコントローラモジュール９０２を有し、その上にプログラムを逐次実行するためのインタプリタモジュール９０３と汎用カウンタ（後述）を制御するための汎用カウンタ制御アプリケーション・プログラム・インタフェース（以下、汎用カウンタ制御ＡＰＩ）９０４を有する。インタプリタモジュール９０３と汎用カウンタ制御ＡＰＩ９０４の上には動的に着脱可能なアプリケーション群を管理するためのアプリケーション管理モジュール９０５を有する。各種機能を実現するアプリケーション９０６は、このアプリケーション管理モジュール９０５（使用量管理手段）の管理下で動作する。アプリケーションをインストール・アンインストールするためのアプリケーションであるアプリケーションインストーラ９０７もアプリケーション管理モジュール９０５上で動作する。各アプリケーション９０６はアプリケーション管理モジュール９０５経由で汎用カウンタ制御ＡＰＩ９０４を利用することが可能である。なお、これらのソフトウェアはコア部１０内にあるＣＰＵ（図示省略）上で実行される。」
　
（３）「【００７７】図１６は、第二の実施形態における複写機が有しているカウンタの例を示す図である。この例では、コピーカウンタ(モノクロ)、スキャンカウンタ、プリントカウンタ(モノクロ)、カラーコピーカウンタ、カラープリントカウンタ、汎用カウンタの６種類のカウンタがあり、そのそれぞれについてトータルカウント数を示す総数カウント用カウンタが１つとアプリケーション別カウンタがN個（カウンタ番号１からN）用意されている。モノクロコピージョブが処理される場合、１枚コピーする度にコピーカウンタがカウントアップされる。なおこの時のカウンタの増分はアプリケーション情報の中で定義された分だけ増やされる。同様に、スキャンカウンタ、プリントカウンタ、カラーコピーカウンタ、カラープリントカウンタは、それぞれスキャンジョブ、モノクロプリントジョブ、カラーコピージョブ、カラープリントジョブが実行されたときに所定動作毎にコントローラによって自動的にカウントアップされる。汎用カウンタについては、アプリケーションが汎用カウンタ制御ＡＰＩを通じて指示を出すことにより、アプリケーションの都合の良いタイミングでカウントアップすることができる。
【００７８】例えば、図１４の状況で、アプリケーションＩＤが１１のアプリケーションによりスキャンジョブが実行された場合、１枚スキャンする毎に図１６（い）のカウンタが１０ずつ増加していく。また、アプリケーションＩＤが１１のアプリケーションがジョブを発行するたびに汎用カウンタＡＰＩをコールすれば、アプリケーションＩＤが１１のアプリケーションがジョブを発行するたびに図１６（ろ）のカウンタが１ずつ増加することになる。」
　
（４）「【００９３】インタプリンタによって解釈実行される、移植性・再利用性の高いカウンタ制御ＡＰＩを提供したので、カウンタ制御プログラムの作成が容易になり、また、カウンタ制御プログラムの再利用・他の画像形成装置への移植が容易となる。」
　
　
３．当審判断
　本願請求項１、１０、１１（平成１９年２月９日付け手続補正書により補正された特許請求の範囲の請求項１、１０、１１）に記載した
「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」
が原出願の当初明細書等に記載した事項の範囲内にあるもので有るか否かについて検討するに、「カウンタ制御アプリケーション・プログラム・インタフェース」なるものが「前記オペレーティングシステム上で動作するインタプリタ上に設けられた」ものである旨の記載は原出願の当初明細書等には見あたらない。
　また、上記  ２．（１）（２）（３）（４）等に記載の「アプリケーション管理モジュール」は「インタプリタ上」に設けられたものではあるが、これが「カウンタ制御アプリケーション・プログラム・インタフェース」である旨の説明は何処にも見あたらず、原審における出願人の対応や審判請求書における請求人の主張を参酌すれば、当該「アプリケーション管理モジュール」を特許請求の範囲記載の「カウンタ制御アプリケーション・プログラム・インタフェース」として解釈すべきものではない。
　また、上記 ２．（２）（３）等に記載の「汎用カウンタ制御アプリケーション・プログラム・インタフェース」は「カウンタ制御アプリケーション・プログラム・インタフェース」と言えるものではあるものの、図９の記載からも明らかなように、「インタプリタ上」に設けられるものではなく、インタプリタと同じ階層に設けられていることは明らかであり、これも、「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」と言えるものでは無い。
　さらに、上記２．（４）の記載に関しても、「インタプリンタによって解釈実行される」からといって必ずしも「カウンタ制御ＡＰＩ」が「インタプリタ」の上層に位置するとは限らず同層でも下層でも技術的に矛盾無く理解し得るので、この記載も「カウンタ制御アプリケーション・プログラム・インタフェース」が「インタプリンタ上」に設けられていることを示唆するものではない。
　そして、他に「カウンタ制御アプリケーション・プログラム・インタフェース」が「インタプリタ上」に設けられていることを示唆する記載は見あたらない。
　してみると、原出願の当初明細書等のすべての記載を総合しても「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」なる技術的事項を導くこともできず、「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」なる発明特定事項を含む発明を明示するものである本願は、原出願の当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな事項を導入する出願であり、原出願の出願当初の明細書又は図面に記載した事項の範囲内にない事項を含むことが明らかである。
　
　
４．小結
　よって、本願は、原出願の一部を一又は二以上の新たな特許出願とするものと認め得るものではなく、出願日の遡及を認めることのできないものである。
　従って、本願の出願日は現実の平成１７年１月３１日となる。
　
　
　
第４．原審の拒絶査定の理由について
　
　
１．本願発明
　上記第２．で述べた通り、平成１９年５月２１日付けでなされた、同年５月１日付け手続補正についての補正却下の決定を取り消すことはできないので、本願請求項１〜１１に係る発明は、平成１９年２月９日付け手続補正書により補正された特許請求の範囲の請求項１〜１１に記載された、以下に再掲する通りのものであると認める。
「　【請求項１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置において、
　アプリケーションごとに使用量を管理するカウンタと、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理手段とを有する画像形成装置。
　　【請求項２】
　インストールされるアプリケーションを対応付けることが出来るカウンタを特定する特定手段と、
　前記特定手段が、前記アプリケーションを対応付けることができるカウンタを特定できなかった場合には、前記使用量管理手段は、新しくカウンタを作成して前記入力されたアプリケーションを対応付けることを特徴とする請求項１に記載の画像形成装置。
　　【請求項３】
　前記使用量管理手段は、前記特定手段が特定したカウンタを初期化することを特徴とする請求項２に記載の画像形成装置。
　　【請求項４】
　前記使用量管理手段は、前記アプリケーションを実行した回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至３のいずれか１項に画像形成装
置。
　　【請求項５】
　前記使用量管理手段は、前記アプリケーションを使用した時間により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至４のいずれか１項に画像形成装置。
　　【請求項６】
　前記使用量管理手段は、前記アプリケーションが引き起こした画像形成装置の所定動作の回数により、前記アプリケーションの使用量を管理することを特徴とする請求項１乃至５のいずれか１項に画像形成装置。
　　【請求項７】
　前記使用量管理手段は、前記画像形成装置が提供する機能と、前記画像形成装置が提供する機能を利用する前記アプリケーションとの組合せにより使用量を管理することを特徴とする請求項１乃至６のいずれか１項に画像形成装置。
　　【請求項８】
　前記使用量管理手段は、前記アプリケーションに対応する識別子と前記カウンタに対応する識別子とを対応づけるテーブルを用いて、前記カウンタを管理することを特徴とする請求項１乃至７のいずれか１項に画像形成装置。
　　【請求項９】
　前記画像形成装置は、アプリケーションの属性情報を所定の通信媒体を介して外部から取得する取得手段を有し、
　前記取得手段によって取得されたアプリケーションを使用するためのカウントアップ情報と、前記アプリケーションの属性情報に対応したアプリケーションを前記画像形成装置内に導入するか否かの指示を入力するための入力部を表示する処理を制御する表示制御手段を有することを特徴とする請求項１乃至８のいずれか１項に画像形成装置。
　　【請求項１０】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法において、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する使用量管理工程とを画像形成装置が実行する情報処理方法。
　　【請求項１１】
　オペレーティングシステムにより制御される画像形成装置であって該画像形成装置が提供する機能を制御するアプリケーションを搭載可能な画像形成装置が実行する情報処理方法を画像処理装置に実行させる制御プログラムであって、
　アプリケーションごとにカウンタを用いてアプリケーションの使用量を画像形成装置が管理する工程と、
　前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を画像形成装置が管理する使用量管理工程を情報処理方法を、画像処理装置に実行させる制御プログラム。」
　
　
２．原審の拒絶理由
　原審の拒絶の査定の理由である平成１９年２月２８日付けの最後の拒絶理由通知記載の理由は概略以下の通りのものである。
「＜分割要件について＞
　本出願は、特許法第４４条第１項の規定の適用を受けようとする出願であるが、本出願が同条同項の規定を満たすものであるか否かをまず検討する。
　
　平成１９年２月９日付け手続補正書により、本願の請求項１及び１０には
「オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を管理する」との補正がなされ、また、請求項１１には
「オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェースを用いて前記カウンタを用いたアプリケーションの使用量を画像形成装置が管理する」との補正がなされている。
　そして、「カウンタ制御アプリケーション・プログラム・インタフェース」に関し、本願の原出願（特願２００２−１１４６６号）の出願当初明細書及び図面の記載を検討すると、同原出願明細書第００６１段落に
「ＯＳ９０１の上には、各種機器制御のためのコントローラモジュール９０２を有し、その上にプログラムを逐次実行するためのインタプリタモジュール９０３と汎用カウンタ（後述）を制御するための汎用カウンタ制御アプリケーション・プログラム・インタフェース（以下、汎用カウンタ制御ＡＰＩ）９０４を有する。インタプリタモジュール９０３と汎用カウンタ制御ＡＰＩ９０４の上には動的に着脱可能なアプリケーション群を管理するためのアプリケーション管理モジュール９０５を有する。」との記載があり、該記載と同原出願の図面図９の記載とからみて、
　カウンタ制御アプリケーション・プログラム・インタフェースとインタプリタとが、同一のソフトウェアモジュール階層に置かれていること
は読み取れる。
　しかし、上記補正のごとくインタプリタ上にカウンタ制御アプリケーション・プログラム・インタフェースが設けられていることは記載されておらず、また、このことは原出願の出願当初明細書及び図面の記載から自明な事項であるともいえない。
　したがって、本出願は、原出願の出願当初明細書又は図面に記載した事項の範囲内でない事項である「インタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」を含んでいるから、原出願の明細書又は図面に記載した事項の一部を分割出願に係る発明としたものではなく、特許法第４４条第１項に規定する要件を満たすものではない。
　よって、本出願は、特許法第４４条第２項の適用はなく、現実の出願日である平成１７年１月３１日に新たに出願されたものとして取り扱われる。
（例えば、原出願における特許請求の範囲は明細書の一部として扱われるが、本願においては明細書と特許請求の範囲とは別の書類として扱われる。）
　
＜拒絶の理由＞
Ａ．平成１９年２月９日付けでした手続補正は、下記の点で願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　本願の出願当初明細書、特許請求の範囲又は図面の記載からも、カウンタ制御アプリケーション・プログラム・インタフェースとインタプリタとが、同一のソフトウェアモジュール階層に置かれていることは明細書第００４６段落の記載及び同図面図９の記載から読み取れるが、同手続補正により補正された事項のうち「インタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」は、本願の出願当初明細書、特許請求の範囲又は図面には記載されておらず、また、これらの記載からみて自明な事項ともいえない。
　したがって、当該手続補正は、特許法第１７条の２第３項に規定する要件を満たしていない。」
　
　
３．拒絶の理由の対象となった補正の内容
（１）上記拒絶の理由の対象となった平成１９年２月９日付けでした手続補正（以下においては、これを「本件補正」と記す。）は特許請求の範囲を上記１．記載の通りのものとする補正であり、その請求項１、１０、１１には
「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」
なる発明特定事項が記載されている。
　
　
４．当初明細書等の記載内容
　本願の願書に最初に添付した明細書・特許請求の範囲及び図面（以下「本出願の当初明細書等」と記す。）には以下の通り記載されている。
　
（１）　「【００２１】
　図２は、第一の実施形態における画像形成装置のソフトウェアモジュール階層の好適な一例を示した図である。ソフトウェアモジュールはオペレーティングシステム（ＯＳ）２０１を有している。ＯＳ２０１の上には、各種機器制御のためのコントローラモジュール２０２を有し、その上にプログラムを逐次実行するためのインタプリタモジュール２０３を有する。インタプリタモジュール２０３の上には、動的に着脱可能な複数のアプリケーション群を管理するためのアプリケーション管理モジュール２０４を有する。各種機能を実現するアプリケーション２０５は、このアプリケーション管理モジュール２０４の管理下で動作する。インタプリタモジュール２０３を介して複写機のサービスを提供するためのアプリケーションモジュールを動作させることができる。例えば、外部サーバ装置から取得したアプリケーションモジュールが画像形成装置内に組み込まれるのに応答して、アプリケーション管理モジュール２０４はアプリケーション２０５を管理対象として追加したり、画像形成装置内からアプリケーションプログラムが削除されるのに応答して、アプリケーション管理モジュール２０４はアプリケーション２０５を管理対象から外すことができる。」
　
（２）「【００４６】
　図９は、第二の実施形態における複写機１００のソフトウェアモジュール階層の構成を示す図である。ソフトウェアモジュールはオペレーティングシステム（ＯＳ）９０１を有している。ＯＳ９０１の上には、各種機器制御のためのコントローラモジュール９０２を有し、その上にプログラムを逐次実行するためのインタプリタモジュール９０３と汎用カウンタ（後述）を制御するための汎用カウンタ制御アプリケーション・プログラム・インタフェース（以下、汎用カウンタ制御ＡＰＩ）９０４を有する。インタプリタモジュール９０３と汎用カウンタ制御ＡＰＩ９０４の上には動的に着脱可能なアプリケーション群を管理するためのアプリケーション管理モジュール９０５を有する。各種機能を実現するアプリケーション９０６は、このアプリケーション管理モジュール９０５（使用量管理手段）の管理下で動作する。アプリケーションをインストール・アンインストールするためのアプリケーションであるアプリケーションインストーラ９０７もアプリケーション管理モジュール９０５上で動作する。各アプリケーション９０６はアプリケーション管理モジュール９０５経由で汎用カウンタ制御ＡＰＩ９０４を利用することが可能である。なお、これらのソフトウェアはコア部１０内にあるＣＰＵ（図示省略）上で実行される。」
　
（３）「【００６２】
　図１６は、第二の実施形態における複写機が有しているカウンタの例を示す図である。この例では、コピーカウンタ（モノクロ）、スキャンカウンタ、プリントカウンタ（モノクロ）、カラーコピーカウンタ、カラープリントカウンタ、汎用カウンタの６種類のカウンタがあり、そのそれぞれについてトータルカウント数を示す総数カウント用カウンタが１つとアプリケーション別カウンタがＮ個（カウンタ番号１からＮ）用意されている。モノクロコピージョブが処理される場合、１枚コピーする度にコピーカウンタがカウントアップされる。なおこの時のカウンタの増分はアプリケーション情報の中で定義された分だけ増やされる。同様に、スキャンカウンタ、プリントカウンタ、カラーコピーカウンタ、カラープリントカウンタは、それぞれスキャンジョブ、モノクロプリントジョブ、カラーコピージョブ、カラープリントジョブが実行されたときに所定動作毎にコントローラによって自動的にカウントアップされる。汎用カウンタについては、アプリケーションが汎用カウンタ制御ＡＰＩを通じて指示を出すことにより、アプリケーションの都合の良いタイミングでカウントアップすることができる。
　【００６３】
　例えば、図１４の状況で、アプリケーションＩＤが１１のアプリケーションによりスキャンジョブが実行された場合、１枚スキャンする毎に図１６（い）のカウンタが１０ずつ増加していく。また、アプリケーションＩＤが１１のアプリケーションがジョブを発行するたびに汎用カウンタＡＰＩをコールすれば、アプリケーションＩＤが１１のアプリケーションがジョブを発行するたびに図１６（ろ）のカウンタが１ずつ増加することになる。」
　
（４）「【００７８】
インタプリンタによって解釈実行される、移植性・再利用性の高いカウンタ制御ＡＰＩを提供したので、カウンタ制御プログラムの作成が容易になり、また、カウンタ制御プログラムの再利用・他の画像形成装置への移植が容易となる。」
　
　
５．当審判断
　本願請請求項１、１０、１１に記載した
「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」
が本願の当初明細書等に記載した事項の範囲内にあるもので有るか否かについて検討するに、「カウンタ制御アプリケーション・プログラム・インタフェース」なるものが「前記オペレーティングシステム上で動作するインタプリタ上に設けられた」ものである旨の記載は本願の当初明細書等には見あたらない。
　また、上記  ４．（１）（２）（３）（４）等に記載の「アプリケーション管理モジュール」は「インタプリタ上」に設けられたものではあるが、これが「カウンタ制御アプリケーション・プログラム・インタフェース」である旨の説明は何処にも見あたらず、原審における出願人の対応や審判請求書における請求人の主張を参酌すれば、当該「アプリケーション管理モジュール」を特許請求の範囲記載の「カウンタ制御アプリケーション・プログラム・インタフェース」として解釈すべきものではない。
　また、上記 ４．（２）（３）等に記載の「汎用カウンタ制御アプリケーション・プログラム・インタフェース」は「カウンタ制御アプリケーション・プログラム・インタフェース」と言えるものではあるものの、図９の記載からも明らかなように、「インタプリタ上」に設けられるものではなく、インタプリタと同じ階層に設けられていることは明らかであり、これも、「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」と言えるものでは無い。
　さらに、上記４．（４）の記載に関しても、「インタプリンタによって解釈実行される」からといって必ずしも「カウンタ制御ＡＰＩ」が「インタプリタ」の上層に位置するとは限らず同層でも下層でも技術的に矛盾無く理解し得るので、この記載も「カウンタ制御アプリケーション・プログラム・インタフェース」が「インタプリンタ上」に設けられていることを示唆するものではない。
　そして、他に「カウンタ制御アプリケーション・プログラム・インタフェース」が「インタプリタ上」に設けられていることを示唆する記載は見あたらない。
　してみると、本願の当初明細書等のすべての記載を総合しても「前記オペレーティングシステム上で動作するインタプリタ上に設けられた所定のカウンタ制御アプリケーション・プログラム・インタフェース」なる技術的事項を導くこともできず、本件補正は本願の当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな事項を導入するものである。
　
　
６．小結
　従って、本件補正は願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてしたものでないから、これを特許法第１７条の２第３項に規定する要件を満たしていないとした、原審の拒絶の理由は妥当なものである。
　
　
　
第５．むすび
　以上のとおり、平成１９年５月２１日付けの補正却下の決定は適法なものであり、しかも、平成１９年２月９日付けでした手続補正書による補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項に規定する要件を満たしていない。
　従って、新規性・進歩性等の他の特許要件についての検討をするまでもなく、本願は拒絶すべきものである。
　
　よって、結論のとおり審決する。