【事件の表示】
　平成　７年特許願第１４８４８０号「グラフィックプログラミング用クラスライブラリ」拒絶査定不服審判事件〔平成　８年　７月　２日出願公開、特開平　８−１７１４８４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願の手続の経緯は次のとおりである。
出願　　　　　　　　平成７年６月１５日（パリ条約による優先権主張１９　　　　　　　　　　９４年６月１５日、米国）
拒絶理由の通知　　　平成１３年４月１０日
補正書　　　　　　　平成１３年７月１６日
意見書　　　　　　　平成１３年７月１６日
拒絶査定　　　　　　平成１３年８月８日
同　謄本送達　　　　平成１３年８月１５日
審判請求書　　　　　平成１３年１１月１３日
補正書　　　　　　　平成１３年１２月１３日
前置報告　　　　　　平成１４年２月７日
審尋　　　　　　　　平成１６年７月５日
回答書　　　　　　　平成１７年１月５日
　　　　　　
２．平成１３年１２月１３日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１３年１２月１３日付けの手続補正を却下する。
［理由］
２．１補正後の本願発明
　前記手続補正により、請求項１及び請求項１１は次のように補正され、請求項１２は削除された。
補正前
　「【請求項１】　…（中略）…、
該プログラミングシステムはコンピュータシステム内で実行され、
…（中略）…
　第２の実体クラスは、第１の実体クラスの実体でありかつ追加機能性を有するオブジェクトを指定するためにプログラミングシステム内で使用することができることを特徴とするライブラリ。
　【請求項１１】プログラムのためのコードを生成するためのプログラミングシステムを使用する方法であって、該プログラミングシステムはコンピュータ内にて実行され、そしてそのためのオブジェクト及びクラスを指定しかつ多重継承によるクラス指定を許容タイプであり、…（中略）…
、そして該方法は、
　オブジェクトのクラスの指定を受信するステップと、
　第１のクラス指定と第２のクラス指定とオブジェクトのクラス指定とオブジェクトのための指定とを使用してコードを生成するためにプログラミングシステムのコンパイラ内にてコード生成手段を使用するステップとからなることを特徴とする方法。」
　
補正後
「【請求項１】…（中略）…、
該プログラミングシステムはコンピュータシステム内で実行され、かつグラフィカルユーザインタフェースのためのコードを生成するのに使用されるコンパイラを含み、
…（中略）… 
 第２の実体クラスは、プログラミングシステムにおいて使用されて第１の実体クラスの実体でありかつ追加の機能性を有するオブジェクトを特定しており、
　第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する。
　【請求項１１】　グラフィカルユーザインタフェースのためのコードを生成するためのプログラミングシステムを使用する方法であって、該プログラミングシステムはコンピュータ内にて実行され、そしてコンパイラを含みかつそのためのオブジェクト及びクラスを指定しかつ多重継承によるクラス指定を許容するタイプであり、…（中略）…
そして該方法は、
　コンパイラによって、オブジェクトのクラスの指定を受信するステップと、
　第１のクラス指定と第２のクラス指定とオブジェクトのクラス指定とオブジェクトのための指定とを使用してコードを生成するためにプログラミングシステムのコンパイラ内にてコード生成手段を使用するステップとからなることを特徴とする方法。」
　
　請求項１に係る補正は、明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）を目的としてされたものではなく、誤記の訂正を目的としてなされたものでなく、次に示すように、特許請求の範囲の減縮（補正前発明と解決しようとする課題が同一である発明の構成に欠くことができない事項の範囲内において、その補正前発明の構成に欠くことができない事項の全部又は一部を限定するものに限る。）を目的としてなされたものとも認められない。
　即ち、補正前の発明は、カテゴリがライブラリであり、あくまでライブラリであったものが、補正後は、実質的には、ライブラリとライブラリを入力してコードを生成するコンパイラの発明となっており、具体的には、プログラミングシステムは「グラフィカルユーザインターフェイスのためのコードを生成するのに使用されるコンパイラを含み」、第２の実体クラスは、「プログラミングシステムにおいて使用されて…（中略）…オブジェクトを特定しており」、「第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されて…（中略）…インターフェイスを使用するためのコードを生成する」とされた。この点、請求人が、請求の理由における（３）特許されるべき理由の項において主張するように、ハードウェア資源としてのコンパイラが、ライブラリを処理するために、ソフトウェアと協働するものに補正された旨主張する点と符合する。
　この、実質的には、ライブラリとライブラリを入力してコードを生成するコンパイラの発明は、ライブラリの構成に欠くことができない事項の全部又は一部を限定するものではないから、この補正は、特許請求の範囲の減縮を目的とするものとは認められず、特許法第１７条の２第３項第４号の規定に該当しない。
　　
　更に、仮に、前記補正が、特許請求の範囲の減縮を目的としてなされたとして、本件補正後の前記請求項１に記載された発明が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第４項において準用する同法第１２６条第３項の規定に適合するか）について検討する。
　
　請求人は、請求の理由における（３）特許されるべき理由の項において、補正後の本願発明は、単なる情報の提示ではなく、ハードウェア資源を用いて処理、すなわちコードを生成するものであり、特許法第２９条第１項柱書きに規定する発明に該当する旨主張している。そこで、前記補正が、ライブラリの発明の構成に欠くことができない事項の全部又は一部を限定する補正であるとして、まず、特許法第２９条第１項柱書きに規定する発明に該当するかの点について検討する。
　
２．２特許法第２９条第１項柱書き
２．２．１本願補正発明
　本件補正後の前記請求項１に記載された発明は、補正された明細書及び図面の記載から見て、その特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。（以下、「本願補正発明」という。）
　
「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのプログラミングシステムに使用するクラス指定のライブラリにおいて、該プログラミングシステムはコンピュータシステム内で実行され、かつグラフィカルユーザインタフェースのためのコードを生成するのに使用されるコンパイラを含み、該ライブラリはプログラミングシステムによって読出し可能であり、該ライブラリは、
　オブジェクトによって表される実体を指定する第１の実体クラスを対象にした第１のクラス指定と、
　第１のクラスの実体であるオブジェクトの追加機能性を指定する機能性クラスを対象にした第２のクラス指定とから成り、該機能性クラスは第１の実体クラスも継承する第２の実体クラスによって継承可能であり、
　第２の実体クラスは、プログラミングシステムにおいて使用されて第１の実体クラスの実体でありかつ追加の機能性を有するオブジェクトを特定しており、
　第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する。」
　
２．２．２判断
　本願補正発明は、ライブラリに係る発明であり、本願補正発明のライブラリは、特定のクラス構造を持つことにより機能性を追加できることに向けられ、本願発明のライブラリの構成としてクラス指定（class　specifications，クラス定義、スペック）や構造体が特定されているが、この構成は人為的な取り決め上のものであり、
　ライブラリとプログラミングシステム、コンピュータシステムとの関係についてみると、
　該ライブラリは、プログラミングシステムに使用するライブラリであり、該プログラミングシステムはコンピュータシステム内で実行され、かつグラフィカルユーザインタフェースのためのコードを生成するのに使用されるコンパイラを含み、該ライブラリはプログラミングシステムによって読出し可能であり、さらに、前記ライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する、と記載されているだけで、ライブラリがコンパイラ（又はシステム）をどのように用いているか、ハードウェア資源をどのように用いて具体的に実現されているか記載されておらず、換言すれば、「ライブラリ」がコンパイラ（又はシステム）により処理されることと、「ライブラリ」のクラス構造とは機能的な因果関係が存在しない。よって、本願発明に係る「ライブラリ」は、マウス、コンパイラ等を備えたシステムにより何らかの処理がなされ得ることを言及しているにとどまり、この可能性のみをもって「ライブラリ」が、ハードウェア資源をどのように用いているかを特定しているとはいえず、全体として自然法則を利用した技術的思想の創作であると認めることはできない。
　出願人は、請求の理由において、本願発明に係る「ライブラリ」がコンパイラにより処理されることをもってハードウェア資源を用いている旨主張しているが、ライブラリとコンパイラの処理手段がどのように協働しているのか具体的に記載しているものではないので、この主張は採用できない論理である。
　よって、本願補正発明は、「自然法則を利用した技術的思想の創作」であることを要件とする特許法第２条に規定する「発明」に該当しないから、特許法第２９条第１項柱書に規定する要件を満たしておらず、特許出願の際独立して特許を受けることができないものである。
　
２．３特許法第２９条第２項
２．３．１補正後の請求項１に係る発明
　補正後の請求項１に係る発明は、２．２．１本願補正発明として掲示したとおりのものである。
２．３．２引用例の発明
　原審の拒絶の理由に引用された、本願出願前に頒布された刊行物である、Miller，W.M.著、岩谷訳、”Ｃ＋＋の多重継承”、Ｃ　ＭＡＧＡＺＩＮＥ,Vol.2,No.1(1990年１月)p.18-24
には次の事項が記載されている。
Ａ．「継承は，データ隠蔽や実行時結合（late　binding，仮想関数という機構により，関数コールのアドレスのリゾルブが，従来の言語処理系のようにコンパイル時に行われるのでなく，ランタイムに行われること）と並ぶ，オブジェクト指向プログラミングを形成する基本要素のひとつです。Ｃ＋＋では継承は，クラスを他のクラスから導出することとして表現します：
…（中略）…
継承はクラスとクラスとの間の，次のような少なくとも３種類の関係を表現するのに使います：
■特定−派生クラス…（中略）…
■拡張−派生クラス…（中略）…
■変種−派生クラス…（中略）…
　Ｃ＋＋では，継承によってオブジェクト指向プログラミングの別の重要な側面である実行時結合もサポートされます。」（「継承」の項から抽出）
Ｂ．「多重継承は，ひとつのは派生クラスに複数の基底クラスの属性をもたせたい，というときに便利です。その結果，クラスとクラスの間に「合成」という，第４の種類の関係が多重継承によって導入されます。つまり，ひとつのクラスが既存の複数のクラスの合成（結合）として構築されるのです。
　次のような状況を考えてみましょう。ある種のシミュレーションのプログラムがあって，そこにはシミュレートされるオブジェクトを構成するのに使うsimulated_objectクラスがあるとします。また，画面への描画に使うdisplayable_objectというクラスをもった，グラフィックのシステムもあるとします。そして，シミュレーションをグラフィック的に表示するために，このふたつのシステムを統合したい，としましょう。
　状況に応じて，ときにはsimulated_objectクラスとして，別のときにはdisplayable_objectクラスとして機能するような，単一のクラスを定義できれば理想的です。そういう新たなクラスのオブジェクトは，displayable_objectのオブジェクトのようにdraw（　）やmove（　）のリクエストに応じなければならないし，またsimulated_objectのオブジェクトのようにプロセス制御のリクエストにも応じなければなりません。さらに，この新しいクラスのオブジェクトを，既存の両方のクラスの一員にもできることによって，単一継承で可能だった基底クラスと派生クラスとの可換性を，ここでも保証しなければなりません。…（中略）…
　次に，多重継承における仮想関数の機能は，単一継承の場合とまったく同じです。List３の場合は，…（中略）…displayable_simulated_objectのインプリメンテーション（実現化）によって，それぞれの独自のバージョンが提供されるのです。」（「多重継承」の項から抽出）
Ｃ．「…（中略）…このような曖昧な参照があると，コンパイラはエラーメッセージを出さなければなりません。…（中略）…
　このような曖昧性のために，ひとつの派生クラスに多重継承される複数の基底クラスの書き方に制約が生じます。…（中略）…ひとつの派生クラスは，その直接の基底クラスのメンバを継承するだけでなく，基底クラスの派生元であるクラスのメンバも継承します。派生の全体的な階層構造を考えると，ひとつのクラスが何かのクラスを，中間的なクラスを介して複数回継承することもあり得るのです。」（「曖昧性」の項から抽出）
Ｄ．「多重継承によってＣ＋＋はさらに，ライブラリの開発やコードの再利用がやりやすくなりました。displayable_simulated_objectの例では，シミュレーションとグラフィックのパッケージはたぶん別々に，それも違うメーカーが開発した，という場合もあり得るでしょう。両者を，どちらのライブラリにも合った仕様で，ひとつのオブジェクトに結合できれば，それは，それまでの開発成果をテコとして活かせる強力なテクニックだといえます。」（第２４頁左欄下６行〜右欄３行）
Ｅ．第２１頁のＬｉｓｔ３には、simulated_objectクラスとdisplayable_objectクラスと多重継承によって導入されたdisplayable_simulated_objectのクラス指定の単純な例が示されている。
　
（あ）引用例には、Ｂ．の記載を参照すると、ある種のシミュレーションのプログラムと、シミュレートされるオブジェクトを構成するのに使うsimulated_objectクラスとをもったシステムと、画面への描画に使うクラスをもった、グラフィックのシステムとを備え、シミュレーションをグラフィック的に表示するために、前記２つのシステムを統合する統合システムが記載されている。また、グラフィックのシステムを備え、シミュレーションをグラフィック的に表示することは、入力についての記載はないが、該表示はグラフィカルユーザインターフェイスといえるものである。なお、ボタンなどの入力部を備えたグラフィカルユーザインターフェイスは、通常知られたユーザインターフェイス（例えば特開平５−２５７６６３号公報【００１８】段落の記載を参照）であって適宜採用されているものである。
　Ｂ．Ｄ．の記載を参照すると、前記simulated_objectクラスやdisplayable_objectクラスをライブラリにもつのが読み取れるとともに、多重継承によってライブラリの開発やコードの再利用がされることから、多重継承によって開発されたdisplayable_simulated_objectのクラスは、ライブラリにもつことも自在であることが読み取れる。
　また、Ａ．の記載を参照すると、オブジェクト指向プログラミングにより開発された前記統合システムは、Ｃ＋＋で記述されているので実行される前にはコンパイルされるものであり、前記統合システムはシミュレーションをグラフィック的に表示する（実行する）ことからして、コードを生成するのに用いられることが自明のコンパイラを含むことが読み取れる。
　更に、ライブラリは、通常メモリに記憶でき、前記統合システムによって用いられることから、前記統合システムによって読出し可能であることは自明であるとともに、前記統合システムはシミュレーションを実行するのに、コンピュータシステム内で実行されることも自明である。
（い）Ｂ．の記載とＬｉｓｔ３を参照すると、
　シミュレートされるオブジェクトを構成するのに使うsimulated_objectクラス指定と、
　画面への描画に使うdisplayable_objectクラス指定とから成り、該displayable_objectクラス指定はsimulated_objectクラス指定も継承するdisplayable_simulated_objectのクラスによって継承可能であり、
　displayable_simulated_objectのクラスは、オブジェクト指向プログラミングで開発される統合システムにおいて使用されてsimulated_objectクラスのオブジェクトとシミュレーションをグラフィック的に表示するための画面への描画に使うオブジェクトを特定しており、
　simulated_objectクラス指定及びdisplayable_objectクラス指定からなるライブラリは、コンパイラに入力されてシミュレーションをグラフィック的に表示するために使用されるコードを生成するコンパイラを含む統合システムが示されていると認められる。
　（あ）、（い）及び、クラス指定（class　spesification）はクラス定義（クラスの手続や変数を定義したもの、例としてＬｉｓｔ３参照）に相当すると認められ、かつ、変数の値を決めて用いることは通常の技術である点をふまえると、引用例には、次の統合システムの発明（以下、「引用例の発明」という。）が記載されていると認められる。
　
　オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのオブジェクト指向プログラミングをともなう統合システムに使用するクラス指定のライブラリにおいて、該統合システムはコンピュータシステム内で実行され、グラフィカルユーザインタフェースのためのコードを生成するのに用いられるコンパイラを含み、該ライブラリは前記統合システムによって読出し可能であり、該ライブラリは、
　シミュレートされるオブジェクトを構成するのに使うsimulated_objectクラス指定と、
　画面への描画に使うdisplayable_objectクラス指定とから成り、該displayable_objectクラス指定はsimulated_objectクラス指定も継承するdisplayable_simulated_objectのクラスによって継承可能であり、
　displayable_simulated_objectのクラスは、オブジェクト指向プログラミングで開発される統合システムにおいて使用されてsimulated_objectクラスのオブジェクトとシミュレーションをグラフィック的に表示するための画面への描画に使うオブジェクトを特定しており、
　simulated_objectクラス指定及びdisplayable_objectクラス指定からなるライブラリは、コンパイラに入力されてシミュレーションをグラフィック的に表示するために使用されるコードを生成するコンパイラを含む統合システム。
　
２．３．３対比
　本願補正発明と引用例の発明とを対比すると、
（ａ）引用例の発明の、「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのオブジェクト指向プログラミングをともなう統合システムに使用するクラス指定のライブラリにおいて、該統合システムはコンピュータシステム内で実行され、グラフィカルユーザインタフェースのためのコードを生成するのに用いられるコンパイラを含み、該ライブラリは前記統合システムによって読出し可能であり、」は、
本願補正発明の「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのプログラミングシステムに使用するクラス指定のライブラリにおいて、該プログラミングシステムはコンピュータシステム内で実行され、かつグラフィカルユーザインタフェースのためのコードを生成するのに使用されるコンパイラを含み、該ライブラリはプログラミングシステムによって読出し可能であり、」に相当する。
（ｂ）引用例の発明の、「該ライブラリ」は、本願補正発明の「該ライブラリ」に対応する。
（ｃ）引用例の発明の、「シミュレートされるオブジェクトを構成するのに使うsimulated_objectクラス指定」は、シミュレートされるオブジェクトの実体があり、この実体をsimulated_objectクラス指定により該オブジェクトを構成する実体を指定するものであるから、該「simulated_objectクラス」は本願補正発明の「第１の実体クラス」に相当し、
「simulated_objectクラス指定」はsimulated_objectクラスを対象として指定ないしは定義するものであることは自明であって記載されているに等しい事項であるから、これを加味すると、前記「simulated_objectクラス指定」は、本願補正発明の「オブジェクトによって表される実体を指定する第１の実体クラスを対象にした第１のクラス指定」に相当する。
（ｄ）引用例の発明の、「画面への描画に使うdisplayable_objectクラス指定とから成り、該displayable_objectクラス指定はsimulated_objectクラス指定も継承するdisplayable_simulated_objectのクラスによって継承可能であり、」は、simulated_objectクラス指定を第１のクラス指定とみると、displayable_objectクラス指定は「第２のクラス指定」とみることができるとともに、該displayable_objectクラスは、Ｌｉｓｔ３のclass　displayable_objectのdrawメソッド、moveメソッドの記載からも窺われるように機能性クラスと認められるので、該displayable_objectクラスのクラス指定は機能性クラスを対象としたクラス指定であり、displayable_simulated_objectのクラスは、少なくともクラスである点では本願補正発明の実体クラスと共通し、これらの点をふまえると、引用例の発明の前記事項は、本願補正発明の「機能性クラスを対象にした第２のクラス指定とから成り、該機能性クラスは第１の実体クラスも継承するクラスによって継承可能であり、」に相当する。
（ｅ）引用例の発明の、「displayable_simulated_objectのクラスは、オブジェクト指向プログラミングで開発される統合システムにおいて使用されてsimulated_objectクラスのオブジェクトとシミュレーションをグラフィック的に表示するための画面への描画に使うオブジェクトを特定しており、」は、本願補正発明の「クラスは、プログラミングシステムにおいて使用されて第１の実体クラスの実体と機能性を有するオブジェクトを特定しており、」の点では共通している。
（ｆ）引用例の発明の、「simulated_objectクラス指定及びdisplayable_objectクラス指定からなるライブラリは、コンパイラに入力されてシミュレーションをグラフィック的に表示するために使用されるコードを生成するコンパイラを含む統合システム」は、本願補正発明の
「第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する」の構成を有する点では共通している。
　したがって、引用例の発明と本願補正発明とは、次の構成を有する発明である点では一致し、そして、次の点で相違している。
〈一致点〉　　　　　　　　　　　　　　　
　「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのプログラミングシステムに使用するクラス指定のライブラリにおいて、該プログラミングシステムはコンピュータシステム内で実行され、かつグラフィカルユーザインタフェースのためのコードを生成するのに使用されるコンパイラを含み、該ライブラリはプログラミングシステムによって読出し可能であり、該ライブラリは、
　オブジェクトによって表される実体を指定する第１の実体クラスを対象にした第１のクラス指定と、
　機能性クラスを対象にした第２のクラス指定とから成り、該機能性クラスは第１の実体クラスも継承するクラスによって継承可能であり、
　クラスは、プログラミングシステムにおいて使用されて第１の実体クラスの実体と機能性を有するオブジェクトを特定しており、
　第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する。」
　
〈相違点１〉機能性クラスを対象にした第２のクラス指定が、本願補正発明は、第１のクラスの実体であるオブジェクトの追加機能性を指定するものであるのに対し、引用例の発明は、そのような関係のクラス指定であることは明らかではない点。
〈相違点２〉機能性クラスを継承可能であるクラスが、本願補正発明は、第２の実体クラスであるのに対し、引用例の発明は、クラスではあるが実体クラスであることは明らかではない点。
〈相違点３〉前記クラスがプログラミングシステムにおいて使用されて特定しているオブジェクトは、 本願補正発明は、第１の実体クラスの実体でありかつ追加の機能性を有するオブジェクトであるのに対し、引用例の発明は、第１の実体クラスの実体と機能性を有するオブジェクトである点。 
　
２．３．４当審判断
〈相違点１〉について
　機能性クラスを対象にした第２のクラス指定が、第１のクラスの実体であるオブジェクトの追加機能性を指定する機能性クラスを対象にした第２のクラス指定であるとする技術は、本願の優先権主張日前に周知の技術にすぎない。
　例えば、特開平５−２５７６６３号公報には、部品クラスの機能拡張や新しい機能を持つ部品クラスの作成を容易にすることにより、拡張性の高いユーザーインターフェースを構築することを目的とし（【０００５】段落）、既定義のユーザーインターフェース部品のクラスを多重継承して新しいユーザーインタフェース部品のクラスを定義する部品クラス定義方法が記載され、具体的に、次のような作成例が記載されている。
「【００１８】作成例１　拡張クラスの作成
部品クラスとして四角ボタンクラスが既に定義されており、四角ボタンクラスには、ボタンをクリックしたときに内部の文字を強調表示するメソッドが定義されているとし、これにボタンをクリックしたときに音を出す処理を追加した「確認ボタン」を作成する必要が生じた場合、図８のように四角ボタンのサブクラスとして新たに確認ボタンクラスを定義し(144)、「クリックされた」というイベントに対して音を出す処理メソッドを定義(145)することにより実現できる…（中略）…
第３の作成例　多重継承による機能合成
図１２のように立体ボタンクラス158と確認音クラス159が定義されているとする。立体ボタンクラス158には図１３のようにボタン161をクリックしたときにボタンがへこんで見えるように表示を変える(162)メソッドが定義されているとする。また、確認音クラス159には、ボタンをクリックしたときに音が出るメソッドが定義されているとする。これらから、図１４のように多重継承165により立体確認ボタンクラスを作成することができる。図１３に示すように立体確認ボタンクラスの部品163をクリックすると、へこんだように表示され且つ音が出る(164）。」（【００１８】〜【００１９】段落から抜粋）
　前記第３の作成例における、立体ボタンクラスと確認音クラスとは、別々のクラスであるから、「第１のクラス」「第２のクラス」と呼べるものであり、立体ボタンクラスは表示を変える機能を有していはいるがクラスの実体である立体ボタン（図１３のボタン）のオブジェクトを定義しているから実体クラスであるとみることができる。また、追加の機能性を指定する点に関しては、前記目的の記載を参照すると、前記作成例は、部品クラスの機能拡張や新しい機能を持つ部品クラスの作成を容易にするものであり、作成例１には、多重継承によるものではないが、ボタンクラスにボタンをクリックしたときに音を出す機能を追加すること、つまり、追加の機能性を指定する技術が示されているから、前記確認音クラスは、立体ボタンクラスの追加機能性を指定する機能性クラスとみることができる。
　これらの点をふまえると、前記確認音クラスの定義乃至指定は、立体ボタンクラスの実体である立体ボタンオブジェクトの追加機能性を定義乃至指定する機能性クラス（確認音クラス）を対象にした第２のクラス定義乃至指定であるということができる。即ち、機能性クラスを対象にした第２のクラス指定が、第１のクラスの実体であるオブジェクトの追加機能性を指定する機能性クラスを対象にした第２のクラス指定である技術が示されている。
　また、部品のクラス定義として、部品図形と、部品機能と、を用いることは本願優先権主張日前に周知の事項である。即ち、特開平４−３４８４２８号公報には、部品機能をオブジェクト指向言語のプログラムでクラスとして定義し、一方部品図形についてのクラスを定義しておき、これらを使ってアニメーションで表示する技術が記載されており（【０００５】段落を要約）、部品のクラス定義として、部品図形と部品機能とに分けること示されている。
　引用例の発明においては、ひとつのクラスが既存の複数のクラスの合成（結合）として構築されるものであるが（Ｂ．の記載参照）、この合成されるクラスの間の関係は、シミュレートされるオブジェクトに、表示オブジェクトの表示機能を追加して統合している関係であるとみることもできる。機能性を追加する技術、即ち、機能性クラスを対象にした第２のクラス指定を、第１のクラスの実体であるオブジェクトの追加機能性を指定する機能性クラスを対象にした第２のクラス指定とすることは、前記のように周知技術であるから、引用例の発明においてこれを参酌することは当業者が容易になし得ることである。
〈相違点２〉について 
　例えば、前記特開平５−２５７６６３号公報（【００１９】段落、図１０、図１１参照） 作成例２には、確認音クラスを追加作成し、継承によりボタンクラスのサブクラスである四角ボタンクラスまたは丸ボタンクラスを再定義することが記載され、図１１にはdefclass四角ボタン（ボタン　確認音）〈各種属性の定義〉，defclass丸ボタン（ボタン　確認音）〈各種属性の定義〉が記載されており、これらの記載にみられるように、機能性クラスである確認音クラスを継承可能であるクラスが、ボタンクラスのサブクラスである四角ボタンクラスや丸ボタンクラス、つまり第２の実体クラスであるとする継承の技術は本願優先権主張日前に周知の技術と認められる。
　あるいは、〈相違点１〉で論じた、例えば、立体確認ボタンクラスは、立体ボタンクラスと確認音クラスが合成された新たなクラスではあるが、依然としてボタンクラスであるとみることもできる。
　引用例の発明における前記クラス（displayable_simulated_objectのクラス）は、多重継承しているから、displayable_objectクラスを継承しているクラスともsimulated_objectクラスを継承しているクラスともみれる。機能性クラスを継承可能であるクラスが、第２の実体クラスであるとすることは、前記継承の技術を参酌することにより当業者が適宜決定し得ることであり、技術的に格別なものであるとも認められない。
〈相違点３〉について
　〈相違点２〉で論じた、第２の実体クラスは、ボタンクラスにボタンをクリックしたときに音を出す機能を追加したクラスである。前記クラスが、プログラミングシステムにおいて使用されて特定しているのは、ボタンクラスである第１の実体クラスの実体でありかつ追加の機能性を有するオブジェクトということになる。
　したがって、引用例の発明において、第１の実体クラスの実体と機能性を有するオブジェクトであるところを、第１の実体クラスの実体でありかつ追加の機能性を有するオブジェクトであるとすることは、当業者が容易になし得ることである。
　そして、本願補正発明によって得られる作用効果も、前記引用例の記載及び前記周知事項から当然予想される範囲内のものであり、格別顕著なものとは認められない。
　
　したがって、本願補正発明は、仮に、特許法第２９条第１項柱書にいう「発明」として認められたとしても、引用例に記載された発明及び前記周知事項に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　
２．４むすび
　以上のとおり、本件補正は、特許法第１７条の２第３項、及び、第４項で準用する同法第１２６条第３項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明について
　平成１３年１２月１３日付けの手続補正は前記のとおり却下されたので、本願の請求項１に係る発明（以下、同項記載の発明を「本願発明」という。」は、平成１３年７月１６日付け手続補正書の特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
　
「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのプログラミングシステムに使用するクラス指定のライブラリにおいて、該プログラミングシステムはコンピュータシステム内で実行され、該ライブラリはプログラミングシステムによって読出し可能であり、該ライブラリは、
　オブジェクトによって表される実体を指定する第１の実体クラスを対象にした第１のクラス指定と、
　第１のクラスの実体であるオブジェクトの追加機能性を指定する機能性クラスを対象にした第２のクラス指定とから成り、該機能性クラスは第１の実体クラスも承継する第２の実体クラスによって承継可能であり、
　第２の実体クラスは、第１の実体クラスの実体でありかつ追加機能性を有するオブジェクトを指定するためにプログラミングシステム内で使用することができることを特徴とするライブラリ。」
　
３．１特許法第２９条１項柱書
３．１．１判断
　本願発明は、ライブラリに係る発明であるが、ライブラリ自体はクラスの指定乃至定義、つまりクラス構造及び構造体のみに特徴があるから、単なる情報の提示の域を脱しているものでなく、前記のクラス構造や構造体の構成は人為的な取り決め上のものであり、本願発明のライブラリは、次の構成、つまり「オブジェクトおよびそのクラスを指定しかつ多重継承によってクラス指定を行えるタイプのプログラミングシステムに使用するクラス指定のライブラリにおいて、該プログラミングシステムはコンピュータシステム内で実行され、該ライブラリはプログラミングシステムによって読出し可能であり、」「第２の実体クラスは、第１の実体クラスの実体でありかつ追加機能性を有するオブジェクトを指定するためにプログラミングシステム内で使用することができる」を有するものではあるが、これは、本願発明に係るライブラリがコンピュータに使用されるものであり、システムにより何らかの処理がなされ得ることを言及しているにとどまり、この可能性のみをもって「ライブラリ」が、ハードウェア資源をどのように用いているかを特定しているとはいえず、全体として自然法則を利用した技術的思想の創作であると認めることはできない。
３．１．２むすび
　よって、本願発明は、「自然法則を利用した技術的思想の創作」であることを要件とする特許法第２条に規定する「発明」に該当しないから、特許法第２９条第１項柱書に規定する要件を満たしておらず、特許を受けることができないものである。
３．２特許法第２９条第２項
３．２．１引用例
　引用例とその記載事項、及び周知事項は、前記２．３．２、及び２．３．４に記載したとおりである。
３．２．２対比・判断
　本願発明は、前記２．１乃至２．４で検討した本願補正発明から、
（ａ）プログラミングシステムは「グラフィカルユーザインターフェイスのためのコードを生成するのに使用されるコンパイラを含み、」
（ｂ）第２の実体クラスは、「プログラミングシステムにおいて使用されて…（中略）…の…（中略）…オブジェクトを特定しており」
（ｃ）「第１のクラス指定及び第２のクラス指定からなるライブラリは、コンパイラに入力されてグラフィカルユーザインタフェースを使用するためのコードを生成する」
の限定を省いたものであり、換言すれば、実質的には、ライブラリとライブラリを入力してコードを生成するコンパイラを含む発明からコードを生成するコンパイラを省いたライブラリの発明であり、この点、請求人が、請求の理由における（３）特許されるべき理由の項において主張するような、ハードウェア資源としてのコンパイラが、ライブラリを処理するために、ソフトウェアと協働する部分としている部分を省略したものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．３．３、２．３．４に記載したとおり、引用例の発明及び前記周知技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例及び前記周知技術に基いて当業者が容易に発明をすることができたものである。
　
３．２．３むすび
　以上のとおり、本願発明は、引用例に記載された発明、及び、本願出願前周知の技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。