【事件の表示】
　特願２０００−２５７８１４「プログラム変換装置」拒絶査定不服審判事件〔平成１３年　６月　８日出願公開、特開２００１−１５４８５５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年８月２８日（優先権主張平成１１年９月１３日）の出願であって、平成１６年１１月１１日付けで拒絶の理由が通知され、平成１７年１月１４日付けで手続補正がなされたたものの、同年２月１４日付けで拒絶査定がなされた。これに対し、同年３月２４日に拒絶査定に対する審判請求がなされるとともに、同年４月２２日付けで手続補正がなされたものである。
　
２．平成１７年４月２２日付け手続補正についての補正の却下の決定
　
［補正の却下の決定の結論］
　平成１７年４月２２日付け手続補正を却下する。
　
［理由］
（１）本件手続補正
　上記平成１７年４月２２日付けの手続補正（以下、「本件手続補正」という。）により補正された特許請求の範囲の請求項６（以下、「補正後の請求項６」という。）は、次のとおりに記載されている。
　
「【請求項６】
　オブジェクト指向言語に基づくソースプログラムから１以上の実行形式命令を生成し、複数のクラス定義と呼出命令とを含むソースプログラムを記憶している記憶手段を備えるプログラム変換装置で用いられるプログラム変換方法であって、
　前記呼出命令は、１個の仮想関数を識別する関数名を含み、
　各クラス定義は、クラスと、前記クラスと他のクラスとの継承関係と、前記関数名で識別され前記クラスに属する仮想関数とを定義し、
　前記呼出命令の実行時に複数のクラスで定義される仮想関数のうち１個の仮想関数のみが実行され、
　前記プログラム変換方法は、
　判断手段により、前記呼出命令に含まれる関数名により識別される仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると確定できるか否かを、前記呼出命令を実行することなく前記ソースプログラムを用いて、判断する判断ステップと、
　生成手段により、前記判断ステップにより確定できると判断される場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令がインライン展開できる場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令を、インライン展開することにより、生成する生成ステップとを含み、
　前記判断ステップは、前記ソースプログラムに含まれる各クラス定義を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断することにより、確定できるか否かを判断し、
　前記生成ステップは、前記判断ステップにより、前記呼出命令に含まれる関数名により識別される仮想関数が他のクラスにより継承されないクラスに属すると判断される場合に、前記実行形式命令を生成し、
　前記記憶手段が記憶しているソースプログラムにおいて、各クラス定義は、各クラスが他のクラスを継承する場合に、前記他のクラスを示す基底クラスを含み、これによりクラスが他のクラスを継承するか否かを示し、
　前記判断ステップは、
　前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義からクラスを抽出し、抽出したクラスを記憶するクラス抽出ステップと、
　前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義から基底クラスを抽出し、抽出した基底クラスを記憶する継承関係抽出ステップと、
　前記クラス抽出ステップに記憶されているクラスから、前記継承関係抽出ステップに記憶されている基底クラスを除いた残りのクラスを抽出し、抽出したクラスを記憶する継承関係解析ステップと、
　前記継承関係解析ステップに記憶されているクラスを含むクラス定義を含む前記ソースプログラムに、最適化情報を書き込む最適化情報付加ステップと、
　前記ソースプログラムに書き込まれた前記最適化情報を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断するクラス判断ステップと
　を含むことを特徴とするプログラム変換方法。」
　
　これに対し、補正後の請求項６に対応する、本件手続補正前の特許請求の範囲の請求項１２（以下、「補正前の請求項１２」という。）は、次のとおりのものである。
　
「【請求項１２】
　オブジェクト指向言語に基づくソースプログラムから１以上の実行形式命令を生成し、複数のクラス定義と呼出命令とを含むソースプログラムを記憶している記憶手段を備えるプログラム変換装置で用いられるプログラム変換方法であって、
　前記呼出命令は、１個の仮想関数を識別する関数名を含み、
　各クラス定義は、クラスと、前記クラスと他のクラスとの継承関係と、前記関数名で識別され前記クラスに属する仮想関数とを定義し、
　前記呼出命令の実行時に複数のクラスで定義される仮想関数のうち１個の仮想関数のみが実行され、
　前記プログラム変換方法は、
　判断手段により、前記呼出命令に含まれる関数名により識別される仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると確定できるか否かを、前記呼出命令を実行することなく前記ソースプログラムを用いて、判断する判断ステップと、
　最適化手段により、前記判断ステップにより確定できると判断される場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令がインライン展開できる場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令をインライン展開する最適化ステップと、
　を含むことを特徴とするプログラム変換方法。」
　
　上記補正前の請求項１２を補正後の請求項６とする補正は、以下の４つの補正事項を含む。
　
（補正事項１）補正前の請求項１２に記載した発明を特定するために必要な事項である「判断ステップ」が、「前記ソースプログラムに含まれる各クラス定義を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断することにより、確定できるか否かを判断」するものであるとの限定を付加する補正。
　
（補正事項２）補正前の請求項１２に記載した発明を特定するために必要な事項である「最適化ステップ」に実質的に対応する補正後の請求項６の「生成ステップ」が、「前記判断ステップにより、前記呼出命令に含まれる関数名により識別される仮想関数が他のクラスにより継承されないクラスに属すると判断される場合に、前記実行形式命令を生成」するものであるとの限定を付加する補正。
　
 なお、補正前の請求項１２における「最適化ステップ」は、出願当初明細書における特許請求の範囲の請求項１２では、「生成ステップ」と称されていたものであって、本件手続補正により再び「生成ステップ」との名称に戻されているが、実質的な変更ではない。
　
（補正事項３）補正前の請求項１２に記載した発明を特定するために必要な事項である「ソースプログラム」について、ソースプログラムに含まれる各クラス定義が、「各クラスが他のクラスを継承する場合に、前記他のクラスを示す基底クラスを含み、これによりクラスが他のクラスを継承するか否かを示」すものであるとの限定を付加する補正。
　
（補正事項４）補正前の請求項１２に記載した発明を特定するために必要な事項である「判断ステップ」が、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義からクラスを抽出し、抽出したクラスを記憶するクラス抽出ステップ」と、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義から基底クラスを抽出し、抽出した基底クラスを記憶する継承関係抽出ステップ」と、「前記クラス抽出ステップに記憶されているクラスから、前記継承関係抽出ステップに記憶されている基底クラスを除いた残りのクラスを抽出し、抽出したクラスを記憶する継承関係解析ステップ」と、「前記継承関係解析ステップに記憶されているクラスを含むクラス定義を含む前記ソースプログラムに、最適化情報を書き込む最適化情報付加ステップ」と、「前記ソースプログラムに書き込まれた前記最適化情報を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断するクラス判断ステップ」とを含むものであるとの限定を付加する補正。
　
　これらの補正事項は、いずれも、補正前の請求項１２に記載した発明を特定するために必要な事項に更に限定を加えるものであって、特許法第１７条の２第４項第２号に規定する特許請求の範囲の減縮を目的とするものに該当する。また、上記補正事項１−４は、いずれも、願書に最初に添付した明細書又は図面に記載した事項の範囲内でなされており、特許法第１７条の２第３項の規定に適合するものである。
　
　そこで、上記補正後の請求項６に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下に検討する。
　
（２）引用発明
［引用文献１］
　原査定の拒絶の理由に引用された刊行物である、春名修介、外５名「Ｃ＋＋言語における機器組み込み向け最適化手法」、情報処理学会論文誌、社団法人情報処理学会、１９９９年５月１５日，第４０巻、Ｎｏ．ＳＩＧ４（ＰＲＯ３），ｐ．３３−４３（以下、「引用文献１」という。）には、以下の事項が記載されている。
　
Ａ．「本稿では，組み込みソフトウェア開発に適した，Ｃ＋＋言語における最適化手法を提案する．また，それらを当社の３２ビット機器組み込みマイコン２）用Ｃ＋＋言語コンパイラに適用した結果について報告する．」（３４頁左欄１８行〜２１行）
　
Ｂ．「３．仮想関数の直接呼び出し手法
　仮想関数は，呼び出される関数が参照しているオブジェクトにしたがって動的に決定される機能である．この機能により，呼び出し元では実際のオブジェクトが何であるかを考慮しない記述が可能になり，プログラム間の独立性が高くなる．例えば，オブジェクトの種類を増やしても，呼び出し元プログラムを変更する必要がなくなる．
　しかし，仮想関数呼び出しは呼び出す関数を実行時に動的に決定するため，関数の検索処理が必要となる．このため，Ｃ言語の関数呼び出しと比べて，コードサイズが大きく，実行性能が低下する．
　よって，仮想関数を必要としない場合は，仮想関数を使用しないことが望ましい．しかし，Ｃ＋＋言語では，基底クラスの関数が仮想関数である場合は，その派生クラスの関数は仮想関数の指定をしなくても仮想関数として扱われるという問題がある．
・・・（中略）・・・
　図２に例を示す．クラスＢで関数ｖｆｕｎｃが仮想関数であるため，クラスＤでも仮想関数となり，クラスＤのオブジェクトを介した関数呼び出しｏｂｊ．ｖｆｕｎｃ（）は，従来の実装では関数検索処理を含む間接呼び出しとなっていた．
　従来手法で図２をコンパイルした結果の機械語命令列を図３に示す．“ｍｏｖ（０，Ａ０），Ａ１”，“ｍｏｖ（０，Ａ１），Ａ１”はオブジェクトｏｂｊ内に保持している呼び出される関数のアドレスを検索する処理であり，“ｃａｌｌ（Ａ１）”は検索した関数のアドレスに分岐する間接呼び出し命令である．
　そこで，派生クラスを持たないリーフのクラスの仮想関数は，再定義されないため，呼び出す関数がコンパイル時に静的に決定できることに着目し，そのような仮想関数を関数検索処理を含まない直接呼び出しに変換する方法を検討した．」（３５頁左欄１９行〜３６頁左欄４行）
　
Ｃ．「／／クラスＢの定義
ｃｌａｓｓ　Ｂ　｛
　　　　ｉｎｔ　ｂ；
　　ｐｕｂｌｉｃ：
　　　　ｖｉｒｔｕａｌ　ｉｎｔ　ｖｆｕｎｃ（ｖｏｉｄ）；／／仮想関数
｝；
／／クラスＢを継承したクラスＤの定義
ｃｌａｓｓ　Ｄ：ｐｕｂｌｉｃ　Ｂ　｛
　　　　ｉｎｔ　ｄ；
　　ｐｕｂｌｉｃ：
　　　　ｉｎｔ　ｖｆｕｎｃ（ｖｏｉｄ）；／／仮想関数
｝；
／／仮想関数呼び出しを含むプログラム
ｖｏｉｄ　ｆｕｎｃ（Ｄ＆　ｏｂｊ）
｛
　　　　ｏｂｊ．ｖｆｕｎｃ（）；／／仮想関数呼び出し
｝
　　図２　仮想関数呼び出しを含むソースプログラム」（３５頁図２）
　
Ｄ．「ここで問題となるのは，ソフトウェア開発で一般に用いられている分割コンパイルでは，プログラム全体を参照することができないため，クラスがリーフのクラスであるか否かの判定がコンパイル時にできないことである．
　この問題を解決するための方法としては，分割コンパイルをせずに，すべてのファイルを１つにまとめてコンパイルする方法１０）が提案されているが，１つのファイルを修正した場合でも，すべのファイルを１つにまとめて再度コンパイルするので，再コンパイルに時間がかかる．・・・（中略）・・・
　分割コンパイルの利点を活かしながら，プログラム全体を参照するためには，コンパイルされたすべての機械語命令列をリンクする機能を果たすリンカで処理を行なうのが適切である．
　そこで，コンパイル時に仮想関数呼び出しを直接呼び出しと関数検索処理を含む間接呼び出しの両方の情報を持つ疑似命令に翻訳し，リンカでどちらかの呼び出しを選択する最適化手法を考案した．」（３６頁左欄５行〜３２行）
　
Ｅ．「コンパイラの処理は以下のようになる．
（１）リンク時にクラスがリーフのクラスであるか否かを判定するために，基底クラスとして使用されているすべてのクラスに対して，そのクラス名の疑似命令を出力する．
（２）仮想関数呼び出しを起動するオブジェクトのクラスがファイル内で基底クラスとして使用されているか否か判定する．
（３）基底クラスとして使用されていれば，従来と同様に関数検索処理を含む間接呼び出しの機械語命令列に翻訳する．
（４）基底クラスとして使用されていなければ，そのクラスのクラス名，直接呼び出しの関数のラベル名，及び関数検索処理を含む間接呼び出しの機械語命令列の情報をオペランドとする仮想関数呼び出し疑似命令に翻訳する．」（３６頁左欄３６行〜同頁右欄５行）
　
Ｆ．「また，リンカでの処理は以下のようになる．
（１）すべてのファイルの基底クラスの情報の和集合をとる．
（２）仮想関数呼び出し疑似命令のオペランドのクラス名が基底クラス情報の和集合に含まれているか否か判定する．
（３）含まれていない場合は，リーフのクラスであるので，仮想関数呼び出し疑似命令のオペランドの直接呼び出しのラベル名を用いて，仮想関数呼び出し疑似命令を直接呼び出しの機械語命令に変換する．
（４）含まれている場合は，仮想関数呼び出し疑似命令のオペランドにある関数検索処理を含む間接呼び出しのための情報を用いて，関数検索処理を含む間接呼び出しの機械語命令列に変換する．
（５）変換された機械語命令列に対してサイズの再計算を行なう．」（３６頁右欄１６行〜３２行）
　
（あ）上記Ａに記載されているように、引用文献１には、Ｃ＋＋言語における最適化手法を、Ｃ＋＋言語コンパイラに適用した結果、すなわち、Ｃ＋＋言語コンパイラで用いられる最適化手法について記載されている。
　ここで、Ｃ＋＋言語は、オブジェクト指向言語である。また、上記Ｂにおいて「従来手法で図２をコンパイルした結果の機械語命令列を図３に示す．」と記載され、図２（上記Ｃ）には「仮想関数呼び出しを含むソースプログラム」が記載されていることから明らかなように、コンパイラは、ソースプログラムから、機械語命令列を生成するものである。
　そして、コンパイラが、その入力であるソースプログラムを記憶するための記憶手段を備えることは当然であるし、上記Ｃに記載されたソースプログラムにも、複数のクラス定義（ｃｌａｓｓ　Ｂ｛・・・｝等）と呼び出し命令（ｏｂｊ．ｖｆｕｎｃ（））が含まれているように、Ｃ＋＋言語のソースプログラムは、一般に複数のクラス定義と呼び出し命令を含むものである。
　以上のことから、引用文献１には、オブジェクト指向言語に基づくソースプログラムから機械語命令列を生成し、複数のクラス定義と呼び出し命令とを含むソースプログラムを記憶している記憶手段を備えるコンパイラで用いられる最適化手法が記載されているといえる。
　
（い）上記Ｃに記載されたソースプログラムの内容及び上記Ｂに記載された関連する説明から明らかなように、前記呼び出し命令には、１個の仮想関数を識別する関数名（ｖｆｕｎｃ）が含まれており、前記クラス定義は、クラスと、前記クラスと他のクラスとの継承関係（ｃｌａｓｓ　Ｄ：　ｐｕｂｌｉｃ　Ｂ｛・・・｝は、クラスＤが基底クラスＢの派生クラスであることを表す。）と、前記関数名で識別され当該クラスに属する仮想関数（クラスＢの定義内のｖｉｒｔｕａｌ　ｉｎｔ　ｖｆｕｎｃ（ｖｏｉｄ）は、ｖｆｕｎｃが仮想関数であることを表す。）とを定義するものである。
　そして、上記Ｃ（図２）のソースプログラムでは、仮想関数ｖｆｕｎｃがクラスＢ及びクラスＤの複数のクラスで定義されていること、また、上記Ｂにおいて「仮想関数呼び出しは呼び出す関数を実行時に動的に決定するため，関数の検索処理が必要となる。」と記載されていることから、前記呼び出し命令の実行時には、複数のクラスで定義される仮想関数のうち１個の仮想関数のみが実行されることが分かる。
　
（う）上記Ｂには、「派生クラスを持たないリーフのクラスの仮想関数は，再定義されないため，呼び出す関数がコンパイル時に静的に決定できることに着目し，そのような仮想関数を関数検索処理を含まない直接呼び出しに変換する」と記載されている。
　ここで、上記（い）で検討したように、仮想関数の呼び出し命令が「呼び出す関数」は、複数のクラスで定義されている複数の仮想関数のうちの１個の仮想関数であり、「コンパイル時に静的に決定できる」とは、実際に命令を実行することなく、ソースプログラムを用いて判断できるということである。また、上記（あ）で述べたように、コンパイラは、ソースプログラムから、機械語命令列を生成するものであって、コンパイラによる変換とは、機械語命令列への変換であるから、「仮想関数を関数検索処理を含まない直接呼び出しに変換する」とは、呼び出す仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換することである。
　したがって、引用文献１に記載の最適化手法では、前記呼び出し命令に含まれる仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると決定できるか否かを、前記呼び出し命令を実行することなく前記ソースプログラムを用いて判断し、その判断の結果、決定できると判断される場合に、前記仮想関数の呼び出しを、前記１個の仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換するものである。
　
（え）さらに、上記（う）で引用した上記Ｂの記載に「派生クラスを持たないリーフのクラスの仮想関数は，再定義されないため，呼び出す関数がコンパイル時に静的に決定できる」と記載されているように、上記決定できるか否かの判断は、前記呼び出し命令に含まれる仮想関数が、派生クラスを持たないリーフのクラスに属するか否かにより判断されるものであり、この判断の結果、前記呼び出し命令に含まれる仮想関数が派生クラスを持たないリーフのクラスに属すると判断される場合に、上記機械語命令への変換が行われることになる。
　そして、上記Ｅの（２）において、「仮想関数呼び出しを起動するオブジェクトのクラスがファイル内で基底クラスとして使用されているか否か判定する」と記載されていることからも明らかなように、上述したリーフのクラスに属するか否かの判断は、ソースプログラムに含まれる各クラス定義を用いて行われるものである。
　
（お）上記（い）で既に述べたように、クラス定義には、そのクラスと他のクラスとの継承関係が含まれており、より具体的には、上記Ｃに「クラスＢを継承したクラスＤの定義」として、「ｃｌａｓｓ　Ｄ：　ｐｕｂｌｉｃ　Ｂ｛・・・｝」と記載されているように、各クラス定義は、各クラスが他のクラスを継承する場合に、前記他のクラスを示す基底クラスを含み、これによりクラスが他のクラスを継承するか否かが示されている。これらのクラス定義は、ソースプログラムに含まれるものであり、また、このソースプログラムがコンパイラの備える記憶手段に記憶されるものであることは、上記（あ）で述べたとおりである。
　
（か）上記Ｄ−Ｆには、上記（う）（え）で述べた引用文献１に記載の最適化手法の実装の詳細が記載されており、仮想関数が派生クラスを持たないリーフのクラスに属するか否かの判断は、各ファイルのコンパイル時に、各ファイルで基底クラスとして使用されているすべてのクラスについて、そのクラス名の疑似命令を出力し（上記Ｅの（１））、リンク時に、この疑似命令の情報を用いて、すべてのファイルの基底クラスの情報の和集合をとることで、すべての基底クラスを抽出し（上記Ｆの（１））、前記仮想関数の属するクラスが、この基底クラス情報の和集合に含まれているか否かを判断する（上記Ｆの（２））ことにより、行われている。
　
　よって、上記Ａ〜Ｆの記載事項を参照すると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
「オブジェクト指向言語に基づくソースプログラムから機械語命令列を生成し、複数のクラス定義と呼び出し命令とを含むソースプログラムを記憶している記憶手段を備えるコンパイラで用いられる最適化手法であって、
　前記呼び出し命令は、１個の仮想関数を識別する関数名を含み、
　各クラス定義は、クラスと、前記クラスと他のクラスとの継承関係と、前記関数名で識別され当該クラスに属する仮想関数とを定義し、
　前記呼び出し命令の実行時に複数のクラスで定義される仮想関数のうち１個の仮想関数のみが実行され、
　前記最適化手法は、
　前記呼び出し命令に含まれる仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると決定できるか否かを、前記呼び出し命令を実行することなく前記ソースプログラムを用いて判断し、
　その判断の結果、決定できると判断される場合に、前記仮想関数の呼び出しを、前記１個の仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換するものであり、
　前記判断は、前記ソースプログラムに含まれる各クラス定義を用いて、前記呼び出し命令に含まれる仮想関数が、派生クラスを持たないリーフのクラスに属するか否かを判断することにより、決定できるか否かを判断するものであり、
　前記変換は、その判断の結果、前記呼び出し命令に含まれる仮想関数が派生クラスを持たないリーフのクラスに属すると判断される場合に、上記機械語命令への変換を行うものであり、
　前記記憶手段が記憶しているソースプログラムにおいて、各クラス定義は、各クラスが他のクラスを継承する場合に、前記他のクラスを示す基底クラスを含み、これによりクラスが他のクラスを継承するか否かを示し、
　前記仮想関数が派生クラスを持たないリーフのクラスに属するか否かの判断は、各ファイルのコンパイル時に、各ファイルで基底クラスとして使用されているすべてのクラスについて、そのクラス名の疑似命令を出力し、リンク時に、この疑似命令の情報を用いて、すべてのファイルの基底クラスの情報の和集合をとることで、すべての基底クラスを抽出し、前記仮想関数の属するクラスが、この基底クラス情報の和集合に含まれているか否かを判断することで行われる
　ことを特徴とする最適化手法」
　
［引用文献２］
　本願の優先権主張の日前に頒布された刊行物である、Aigner, et al.,”Eliminating Virtual Function Calls in C++ Programs, ECOOP '96 Conference Proceedings，（独），Springer Verlag，１９９６年，p.142-166（以下、「引用文献２」という。）には、以下の事項が記載されている。
　
Ｇ．「Abstract. We have designed and implemented an optimizing source-to-source C++ compiler that reduces the frequency of virtual function calls.」（１４２頁４行〜５行）
　
（仮訳）
要約　我々は、仮想関数（virtual function）呼び出しの頻度を減少させるソース変換型（source-to-source）Ｃ＋＋最適化コンパイラを設計し実装した。
　
Ｈ．「Second, it is hard to optimize calls in object-oriented programs because they use dynamic dispatch: the procedure invoked by the call is not known until run-time since it depends on the dynamic type of the receiver. Therefore, a compiler usually cannot apply standard optimizations such as inline substitution or interprocedural analysis to these calls.」（１４２頁２４行〜２８行）
　
（仮訳）
第２に、オブジェクト指向プログラム内の呼び出しは最適化が難しい。それは動的ディスパッチ（dynamic dispatch）−その呼び出しによって呼び出されるプロシージャが、レシーバの動的タイプに依存するため、実行時まで分からない−を使用しているためである。したがって、コンパイラは、通常、インライン置換（inline substitution）やプロシージャ間解析といった標準的な最適化をこれらの呼び出しに適用することができない。
　
Ｉ．「We have developed a proof-of-concept optimizing compiler for C++ that demonstrates that optimization can reduce the frequency of virtual function calls in C++, and that programs execute significantly faster as a result.」（１４３頁２６行〜２８行）
　
（仮訳）
我々は、最適化によりＣ＋＋内の仮想関数呼び出しの頻度を減少可能であり、結果としてプログラムが著しく高速に実行されることを示すための概念実証用（proof-of-concept）Ｃ＋＋向け最適化コンパイラを開発した。
　
Ｊ．「2.2 Static Optimization: Class Hierarchy Analysis
We also implemented a static optimization technique, class hierarchy analysis (CHA) [App88, DGC95, Fer95], which can statically bind some virtual function calls given the application's complete class hierarchy. The optimization is based on a simple observation: if a is an instance of class A (or any subclass), the call a-f() can be statically bound if none of A's subclasses overrides f.」（１４４頁２３行〜２８行）
　
２．２　静的最適化：クラス階層分析
我々は、アプリケーションの完全なクラス階層が与えられれば、仮想関数呼び出しのいくつかを静的に束縛する（bind）ことが可能な静的最適化手法である、クラス階層分析（class hierarchy analysis）（ＣＨＡ）［Ａｐｐ８８，ＤＧＣ９５，Ｆｅｒ９５］も実装した。この最適化は、ａがクラスＡ（又はその任意のサブクラス）のインスタンスであるとき、Ａのサブクラスのいずれもｆをオーバーライドしない場合には、呼び出しａ−＞ｆ（）は、静的に束縛可能という単純な所見に基づいている。
　
Ｋ．「4.1 Overview
The implementation consists of several parts (Figure 1). First, a pre-pass combines the original sources into a single baseline program to simplify the work of later phases (section 4.2). Then, the program is compiled with a modified version of GNU C++ to produce an instrumented executable which serves to collect receiver class profile information (section 4.4). The centerpiece of the system, the optimizing compiler, then uses this profile to transform the baseline source program into an optimized source program (section 4.5) which is subsequently compiled and optimized by the native host C++ compiler.」（１４６頁下７行〜１４７頁２行）
　
（仮訳）
４．１　概要
実装はいくつかの部分から成り立っている（図１）。第１に、事前パス（pre-pass）は、後のフェーズの作業を単純化するために、オリジナルのソースを単一のベースライン・プログラムに一体化する（セクション４．２）。それから、プログラムはＧＮＵ　Ｃ＋＋の修正版を使って、レシーバクラスのプロファイル情報の収集に役立つ機能のついた実行可能形式を生成するためにコンパイルされる（セクション４．４）。このシステムの最重要部分、最適化コンパイラは、それから、ベースライン・ソースプログラムを最適化ソースプログラムへと変換するために、このプロファイルを使用する（セクション４．５）。最適化ソースプログラムは、その後、ネイティブのＣ＋＋ホストコンパイラによってコンパイルされ最適化される。
　
Ｌ．「4.3 Source-To-Source Transformation
We chose to implement our compiler using source-to-source transformation for several reasons:
・・・（中略）・・・
On the other hand, source-to-source transformation is not without problems. In particular, it restricts the extent to which high-level information can be transmitted to the back end. ・・・（中略）・・・ In general, the source-to-source compiler has less control over the final generated code; for example, it cannot force the back end compiler to inline a function since the inline modifier is only a hint, not an order (although gcc appears to always follow such hints).」（１４８頁１７行〜１４９頁５行）
　
（仮訳）
４．３　ソース変換型の変換
我々は、いくつかの理由から、我々のコンパイラをソース変換型の変換を用いて実装することを選択した。
・・・（中略）・・・
一方、ソース変換型の変換にも問題がない訳ではない。特に、バックエンドに伝えることのできるハイレベルの情報の程度が制限される。・・・（中略）・・・一般に、ソース変換型コンパイラは、最終生成コードに関する制御性が低い。例えば、ｉｎｌｉｎｅ修飾子（inline modifier）は、ヒント（hint）であって命令（order）ではないから、ソース変換型コンパイラは、バックエンドコンパイラに関数をインラインすることを強制することができない（ｇｃｃは、常にそのようなヒントに従うようであるが）。
　
Ｍ．「Finally, our optimizer relies on the inlining strategies of the back-end compiler to some extent since the inline keyword is only a suggestion to that compiler; if the function is too large, the back end may decide not to inline it. Consequently, our compiler currently does not take function size into account when deciding whether to optimize a call or not. If the back end does not actually inline a call, the only benefit of optimization is the elimination of the dispatch (in the case of class hierarchy analysis) or the replacement of a virtual function call with a somewhat faster comparison-and-direct-call sequence (for type feedback). However, our current back-end compiler (gcc) always inlines inline functions.」（１５３頁３行〜１１行）
　
（仮訳）
最後に、我々の最適化ツールは、バックエンドコンパイラのインライン化の戦略にある程度依存する。これは、ｉｎｌｉｎｅキーワードが、コンパイラに対する示唆でしかないためである。もし関数が大きすぎればバックエンドはインライン化しないことを決定するかも知れない。したがって、我々のコンパイラは、現在のところ、呼び出しを最低かするか否か決定する際に関数のサイズを考慮していない。もし、バックエンドが、ある呼び出しを実際にインライン化しないとすれば、最適化による唯一の利点は、ディスパッチの除去（クラス階層分析の場合）又は仮想関数呼び出しの、それよりいくらか早い比較及び直接呼び出しシーケンス（comparison-and-direct-call sequence）による置き換え（タイプフィードバックの場合）である。しかし、我々の現在のバックエンドコンパイラ（ｇｃｃ）は、ｉｎｌｉｎｅ関数を常にインライン化する。
　
　上記Ｇ〜Ｍの記載事項を参照すると、引用文献２には、「クラス階層分析による静的最適化等を利用して、仮想関数呼び出しの頻度を減少させるソース変換型のコンパイラにおいて、ソースプログラムに、ｉｎｌｉｎｅ修飾子等の最適化に関する情報を付加することにより、その情報を元に、バックエンドコンパイラに最適化の可否を判断させる」ことが記載されている。
　
［引用文献３］
　本願の優先権主張の日前に頒布された特開平１０−４０１１２号公報（以下、「引用文献３」という。）には、図面とともに以下の事項が記載されている。
　
Ｎ．「【０００１】
【発明の属する技術分野】本発明は、コンピュータプログラムの最適化装置に関し、特に原始プログラムの最適化に関する。」
　
Ｍ．「【００１２】
【課題を解決するための手段】本発明の動的情報利用型プログラム最適化装置は、対象プログラムを実行して動的情報を収集し、その情報に基づき原始プログラムを変更して最適化を行う。より具体的には、プログラムを実行して動的情報を収集する動的情報収集手段と、収集された動的情報に基づき原始プログラムを変更する原始プログラム変更手段とを備える。」
　
Ｏ．「【００２２】
【実施例】
（１）第１実施例
この実施例は、本発明をＣ＋＋の関数呼び出しのインライン展開の最適化に適用したものである。本実施例においては、動的情報収集手段２はプログラムを実行してＣ＋＋の関数の実際の呼び出し状況を動的情報３として収集し、原始プログラム変更手段４は収集された動的情報３を考慮して、Ｃ＋＋の関数のインライン展開の可否を制御すべく原始プログラム１を変更して最適化原始プログラム５を生成する。
・・・（中略）・・・
【００２４】・・・（中略）・・・具体的には、例えば図４の原始プログラム１に示すように、インライン展開を行うべき関数ｉｎ１の宣言に、インライン展開する指示ｉｎｌｉｎｅが含まれていなければ、最適化原始プログラム５中ではｉｎｌｉｎｅを付け加え、逆に、インライン展開を行うべきでない関数ｉｎ２の宣言にｉｎｌｉｎｅが含まれていれば、最適化原始プログラム５中ではそのｉｎｌｉｎｅを取り除く。
・・（中略）・・・
【００２６】また、関数の呼び出しごとにインライン展開するか否かを指定することができるコンパイラを用いる場合には、動的情報収集手段２は例えば図５に示すように、各関数の呼び出し回数を呼び出し場所ごとに記録した動的情報３を収集し、原始プログラム変更手段４は、実行される回数が多い場所における呼び出しをインライン展開し、そうでない場所ではインライン展開しないように原始プログラム１を変更することによって、さらに最適化を行うことができる。原始プログラム１の変更は、各関数の宣言にｉｎｌｉｎｅが含まれていればそれらを全て取り除いた後、例えば図６に示すように、インライン展開すべき箇所ごとにインライン展開を指示する予め定められた記号（図では便宜上＊で示す）を付加することで行う。コンパイラ６では、内部のインライン展開制御部６１が、各関数の呼び出し箇所毎に前記所定の記号の有無を判別し、記号が設定されている箇所はインライン展開し、それ以外はインライン展開しない目的プログラム７を生成する。」
　
　上記Ｎ〜Ｏの記載事項を参照すると、引用文献３には、「コンピュータプログラムの最適化装置において、原始プログラムに、インライン展開する指示ｉｎｌｉｎｅ等の最適化に関する情報を付加することにより、その情報を元に、コンパイラに最適化の可否を判断させる」ことが記載されている。
　
（３）対比
　以下、本願補正発明と引用発明とを対比する。
　
あ）引用発明の「機械語命令」、「機械語命令列」、「呼び出し命令」、「コンパイラ」、「呼び出し命令に含まれる仮想関数」、「派生クラスを持たないリーフのクラス」は、それぞれ、本願補正発明の「実行形式命令」、「１以上の実行形式命令」、「呼出命令」、「プログラム変換装置」、「呼出命令に含まれる関数名により識別される仮想関数」、「他のクラスにより継承されないクラス」に相当する。
　
い）引用発明の「最適化手法」は、コンパイラ（本願補正発明の「プログラム変換装置」に相当。）で用いられる、ソースプログラムを実行形式命令に変換するための手法であるから、本願補正発明の「プログラム変換方法」に相当する。
　
う）引用発明の「前記呼び出し命令に含まれる仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると決定できるか否かを、前記呼び出し命令を実行することなく前記ソースプログラムを用いて判断」することは、本願補正発明の「前記呼出命令に含まれる関数名により識別される仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると確定できるか否かを、前記呼出命令を実行することなく前記ソースプログラムを用いて、判断する判断ステップ」に相当する。
　
え）引用発明の「その判断の結果、決定できると判断される場合に、前記仮想関数の呼び出しを、前記１個の仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換する」における「その判断の結果」とは、上記う）で検討した本願補正発明の「判断ステップ」に相当する判断の結果であり、機械語命令への変換は、すなわち、機械語命令の生成であるから、引用発明の「その判断の結果、決定できると判断される場合に、前記仮想関数の呼び出しを、前記１個の仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換する」ことは、前記判断ステップにより確定できると判断される場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令を生成する生成ステップである点で、本願補正発明の「生成ステップ」と一致する。
　
　したがって、本願補正発明と引用発明とは、
　
「オブジェクト指向言語に基づくソースプログラムから１以上の実行形式命令を生成し、複数のクラス定義と呼出命令とを含むソースプログラムを記憶している記憶手段を備えるプログラム変換装置で用いられるプログラム変換方法であって、
　前記呼出命令は、１個の仮想関数を識別する関数名を含み、
　各クラス定義は、クラスと、前記クラスと他のクラスとの継承関係と、前記関数名で識別され当該クラスに属する仮想関数とを定義し、
　前記呼出命令の実行時に複数のクラスで定義される仮想関数のうち１個の仮想関数のみが実行され、
　前記プログラム変換方法は、
　前記呼出命令に含まれる関数名により識別される仮想関数について、前記複数のクラス定義で定義されている前記複数の仮想関数のうちの１個の仮想関数のみが呼び出されると確定できるか否かを、前記呼出命令を実行することなく前記ソースプログラムを用いて、判断する判断ステップと、
　前記判断ステップにより確定できると判断される場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令を、生成する生成ステップとを含み、
　前記判断ステップは、前記ソースプログラムに含まれる各クラス定義を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断することにより、確定できるか否かを判断し、
　前記生成ステップは、前記判断ステップにより、前記呼出命令に含まれるる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属すると判断される場合に、前記実行形式命令を生成し、
　前記記憶手段が記憶しているソースプログラムにおいて、各クラス定義は、各クラスが他のクラスを継承する場合に、前記他のクラスを示す基底クラスを含み、これによりクラスが他のクラスを継承するか否かを示す、
　ことを特徴とするプログラム変換方法」
　
である点で一致し、以下の３点で相違している。
　
［相違点１］
　本願補正発明では、判断ステップが、「判断手段により」行われ、生成ステップが、「生成手段により」行われるのに対し、引用発明においては、本願補正発明の判断ステップに対応する判断処理、及び、本願補正発明の生成ステップに対応する変換処理を行う主体が、それぞれ独立した主体として明示されていない点。
　
［相違点２］
　本願補正発明の生成ステップが、「前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令がインライン展開できる場合」に、「インライン展開することにより」、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令を生成するのに対し、引用発明では、インライン展開は行われていない点。
　
［相違点３]
　本願補正発明では、判断ステップが、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義からクラスを抽出し、抽出したクラスを記憶するクラス抽出ステップ」と、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義から基底クラスを抽出し、抽出した基底クラスを記憶する継承関係抽出ステップ」と、「前記クラス抽出ステップに記憶されているクラスから、前記継承関係抽出ステップに記憶されている基底クラスを除いた残りのクラスを抽出し、抽出したクラスを記憶する継承関係解析ステップ」と、「前記継承関係解析ステップに記憶されているクラスを含むクラス定義を含む前記ソースプログラムに、最適化情報を書き込む最適化情報付加ステップ」と、「前記ソースプログラムに書き込まれた前記最適化情報を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断するクラス判断ステップ」とを含むものであるのに対し、引用発明では、本願補正発明の判断ステップに対応する判断処理が、「各ファイルのコンパイル時に、各ファイルで基底クラスとして使用されているすべてのクラスについて、そのクラス名の疑似命令を出力し、リンク時に、この疑似命令の情報を用いて、すべてのファイルの基底クラスの情報の和集合をとることで、すべての基底クラスを抽出し、前記仮想関数の属するクラスが、この基底クラス情報の和集合に含まれているか否かを判断することで行われる」ものである点。
　
（４）当審の判断
　以下、上記各相違点について検討する。
　
［相違点１について]
　判断ステップ及び生成ステップを行う主体を、それぞれ、判断手段及び生成手段と称し、判断手段により判断ステップが行われ、生成手段により生成ステップが行われると明示することに、格別の技術的意義はないから、引用発明において、本願補正発明の判断ステップに対応する判断処理、及び、本願補正発明の生成ステップに対応する変換処理を行う主体を、それぞれ、判断手段及び生成手段と称し、判断手段により判断処理が行われ、生成手段により変換処理が行われる旨明示することは、当業者が容易に想到し得ることである。
　
［相違点２について］
　インライン展開による最適化は、上記引用文献２及び３のいずれにおいても、インライン展開による最適化について触れられているように周知であるから、引用発明において、仮想関数の呼び出しを、前記１個の仮想関数に対応する機械語命令列を直接呼び出す機械語命令に変換する際に、さらに、インライン展開が可能な場合には、インライン展開も行うようにすること、すなわち、本願補正発明における「前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令がインライン展開できる場合に、前記１個の仮想関数に対応する実行形式命令群を直接呼び出す実行形式命令を、インライン展開することにより、生成する」構成と、同様の構成とすることは、当業者が容易になし得ることである。
　
［相違点３について］
　引用発明においては、「分割コンパイルの利点を活かしながら，プログラム全体を参照するため」（上記（２）Ｄ参照。）、各ファイルのコンパイル時に、各ファイルで基底クラスとして使用されているクラスの情報を収集し、リンク時に、すべてのファイルの基底クラスの情報の和集合をとるという２段階の作業により、プログラム全体に関する基底クラスの情報を得た上で、仮想関数の属するクラスが派生クラスを持たないリーフのクラスに含まれるか（基底クラスに含まれないか）を判断している。
　しかし、分割コンパイルを考慮しなければ、コンパイル段階で基底クラスか否かの完全な情報を得ることができ、基底クラスの情報を得るための処理を、コンパイル時と、リンク時の二段階に分ける必要のないことは、当業者には明らかであり、事実、上記（２）Ｄにも、「分割コンパイルをせずに，すべてのファイルを１つにまとめてコンパイルする方法１０）が提案されている」として、そのような実装が既になされていることが記載されている。
　そして、ソースプログラム（又は、原始プログラム）に、ｉｎｌｉｎｅ修飾子等の最適化情報を付加し、その最適化情報を元に、最適化の可否を判断することは、引用文献２及び３に記載されているように、周知である。
　また、派生クラスを持たないリーフのクラスの集合が、全クラスの集合から、基底クラスの集合を除いた集合であることは、当業者には明らかであるから、基底クラスの集合に含まれないことを個別に確認することにより、派生クラスを持たないリーフのクラスであることを判断するか、予め全クラスの集合から、基底クラスの集合を除いた集合として、派生クラスを持たないリーフのクラスの集合を求めておいて、このリーフのクラスの集合を用いて判断するようにするかは、当業者が適宜選択し得る設計的事項である。
　以上のことから、引用発明の判断処理において、コンパイル時とリンク時の２段階に分けていた派生クラスを持たないリーフのクラスに含まれるかの判断を、一括して行い、ソースプログラムに含まれるクラス定義から、予め全クラスの集合と、基底クラスの集合を求め、全クラスの集合から基底クラスの集合を除いた集合として、派生クラスを持たないリーフのクラスの集合を求めるようにするとともに、得られた情報を最適化情報としてソースプログラムに付加し、その最適化情報を元に、仮想関数が派生クラスを持たないリーフのクラスに属するか否か判断するようにし、本願補正発明のような、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義からクラスを抽出し、抽出したクラスを記憶するクラス抽出ステップ」と、「前記ソースプログラムに含まれる全てのクラス定義を読み出し、読み出したクラス定義から基底クラスを抽出し、抽出した基底クラスを記憶する継承関係抽出ステップ」と、「前記クラス抽出ステップに記憶されているクラスから、前記継承関係抽出ステップに記憶されている基底クラスを除いた残りのクラスを抽出し、抽出したクラスを記憶する継承関係解析ステップ」と、「前記継承関係解析ステップに記憶されているクラスを含むクラス定義を含む前記ソースプログラムに、最適化情報を書き込む最適化情報付加ステップ」と、「前記ソースプログラムに書き込まれた前記最適化情報を用いて、前記呼出命令に含まれる関数名により識別される仮想関数が、他のクラスにより継承されないクラスに属するか否かを判断するクラス判断ステップ」を備えるようにすることは、当業者が容易になし得ることである。
　
　そして、本願補正発明の作用効果も、引用発明及び周知技術に基づいて当業者が容易に予測できる範囲のものである。
　
　なお、審判請求人は、請求の理由において、「上述したように、ファイルＡ、Ｂ及びＣから構成されるプログラムがあり、ファイルＢに記述されているクラスの継承関係が変化した場合において、引用文献１に記載された技術を適用すると、ファイルＢに記述されているクラスの継承関係が変化したことが、ファイルＡ及びＣに影響するか否かが分からないため、全てのファイルＡ、Ｂ及びＣを再コンパイルする必要があり、これらの全てのファイルを再コンパイルする時間が必要となる。
　一方、本願発明は、上述したように、最適化情報付加手段により最適化情報が書き込まれたプログラムのみをコンパイルすればよく、引用文献１に記載された技術を適用する場合と比較すると、コンパイル時間を短くすることができるという優れた効果を奏する。」旨の主張をしている。
　しかし、本願補正発明においては、ソースプログラムが複数のファイルに分かれている旨の限定はないから、上記主張は、特許請求の範囲の記載に基づく主張ではない。また、そもそも、仮想関数の呼び出しを、直接呼び出しに変換できるか否かは、「呼出命令に含まれる仮想関数」の属するクラスが、他のクラスにより継承されないクラスに属するか否かによるのであって、あるクラスに属する仮想関数の呼出命令は、そのクラスのクラス定義が存在するファイル以外にも存在し得るから、クラスの継承関係の変化の影響は、他のクラスにより継承されないクラスのクラス定義を含むファイルにとどまらないから、上記審判請求人の主張は失当である。
　このことは、本願明細書に記載された実施例のコンパイラが、入力された全てのファイルから、終端クラスの情報を収集して終端クラステーブルを構成してから、その後のコンパイル作業に利用している、すなわち、終端クラスのクラス定義を含むファイル以外のファイルのコンパイルにも、そのクラスが終端クラスであることの情報を必要としていることからも明らかである（特に、本願明細書の段落【００６１】〜【００６２】の構文解析部３３の説明を参照。）。
　
　したがって、本願補正発明は、引用文献１に記載の発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際に独立して特許を受けることができないものである。
　
（５）むすび
　以上のとおり、本件手続補正は、特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、特許法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　
（１）本願発明
　平成１７年４月２２日付けの手続補正は上記のとおり却下されたので、本願の請求項１２に係る発明（以下、「本願発明」という。）は、平成１７年１月１４日付け手続補正により補正された特許請求の範囲の請求項１２（上記補正前の請求項１２）に記載されたとおりのものである。
　
（２）引用発明
　上記引用文献１乃至３、及びその記載事項は、前記２．（２）に記載したとおりである。
　
（３）対比・判断
　本願発明は、前記２．（１）で検討した本願補正発明から、上記２．（１）で検討した補正事項１〜４に係る、本願発明を特定するために必要な事項の限定を省いたものである。
　そうすると、本願発明の発明特定事項を全て含み、更に特定の発明特定事項に限定を付加したものに相当する本願補正発明が、前記２．（４）に記載したとおり、引用文献１に記載の発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであることから、本願補正発明も、同様の理由により、引用文献１に記載の発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用文献１−３に記載の発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。