【事件の表示】
　平成　９年特許願第１０５８１１号「Ｃ＋＋プログラムのコンパイル方法及びコンパイラ」拒絶査定不服審判事件〔平成１０年　２月１３日出願公開、特開平１０−　４０１１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成９年４月２３日（パリ条約による優先権主張１９９６年５月１日、加国）の出願であって、平成１４年１月３０日付けで拒絶査定がなされ、これに対し、同年４月２６日に審判請求及び手続補正がなされたものである。
　
２．平成１４年４月２６日付け手続補正書についての補正却下の決定
　
［補正却下の決定の結論］
　平成１４年４月２６日付け手続補正を却下する。
　
［理由］
（１）補正後の請求項４に係る発明
　本件補正により、特許請求の範囲の請求項４は、次のとおりに補正された。
　
「Ｃ＋＋ソース・コード・プログラムを、字句解析を実施して前記ソース・コード・プログラムをトークン化し、構文解析および意味解析を実施して前記ソース・コード・プログラムの中間表現を生成する機能強化されたコンパイラにおいてコンパイルする方法であって、
　すべての識別子が知られていない前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報を、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップであって、前記複数の構文解析パスは、型宣言のみを構文解析する第一のパスと、関数型および変数型を構文解析する第二のパスと、変数イニシャライザおよび関数本体を構文解析する第三パスとを含むステップと、
　各構文解析パスの後に構文解析された宣言のプログラム表現を保存するステップと、
　構文解析パスののち、前記構文解析パス中に得られた宣言に関する新たな情報または変更された情報で前記プログラム表現を更新するステップと
　を含むことを特徴とする方法。」
　
　上記補正後の請求項４は、補正前の請求項８に対応するものであって、補正前の請求項８に記載した発明を特定するために必要な事項である、「それぞれが前記ソース・コード・プログラム中の宣言をプログラム定義から構文解析するための情報を蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップ」を「すべての識別子が知られていない前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報を、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップ」に限定するものであるから、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的としたものに該当する。
　
　そこで、本件補正後の請求項４に記載された発明（以下、「本願補正発明」という。）が特許出願の際に独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第４項）の規定に適合するか）について以下検討する。
　
（２）引用例
Ａ．原査定の拒絶の理由に引用され、本願の優先権主張の日前である昭和５６年に頒布された刊行物である、渡辺、外２名著、”A Three-pass Compiler for ALGOL68、第２２回（昭和５６年前期）情報処理学会全国大会講演論文集、第２７５−２７６頁（以下「引用文献１」という。）には、次の記載がある。
　
（ア）「高級言語では、手続の相互呼出など、宣言の前に名前が使用されることがあり、目的コードを発生するためには多重パスにしなければならないことが多い。」
（第２７５頁第７−８行）
　
（イ）「
２．部分文法を用いた多重パス構文解析
（１）　演算子の優先度宣言　｜　（３）　手続本体内で使用する名前
（２）　型宣言　　　　　　　｜　（４）　ラベル」
（第２７５頁２１−２５行）
　
（ウ）「そこで我々のコンパイラでは、第１パスで演算子宣言、優先度宣言、型宣言の解析を行って太字の名前の定義表を作り、第２パスで変数宣言、同一宣言、ラベル定義を解析して名前の定義表を作る。第３パスでは前の２つのパスで得られた定義表をもとにして残りの部分を解析しながら中間言語プログラムを生成する。
　図１のプログラムに対して、第１パス終了時には図２のテキストと定義表、第２パス終了時には図３のテキストと定義表が得られる。」
（第２７６頁第１−６行）
　
（エ）図１（Ｆｉｇ．１）には、テキスト（プログラム）のみが、図２（Ｆｉｇ．２）には、テキスト、演算子表及び型名表が、並びに、図３（Ｆｉｇ．３）には、テキスト、演算子表、型名表及び名前表が、それぞれ記載されている。
　
（オ）「
４．おわりに
（第２７６頁第２３−２４行）
　
　上記（ウ）において、「残りの部分」が、上記（イ）の「手続本体内で使用する名前」すなわち手続本体を含むことは自明である。
　上記（エ）において、各パスの結果生成されるテキスト（プログラム）が、上記（ウ）における中間言語プログラムの途中の段階であることは自明である。
　上記（ア）乃至（ウ）からすると、各パスで行われる構文解析の結果は、後続の構文解析のパスで使用されていること、及び、第２パスの実行前は、変数宣言に関するすべての名前が知られておらず、第３パスの実行前は、手続本体内で使用する名前のすべてが知られていない状態であり、第２パス及び第３パスでは、当該知られていない名前を解析していることは自明である。また、第１パスの結果である定義表と中間言語プログラムが保存され、これが、第２パスにより新たに生成又は変更された情報により更新され、保存され、これがさらに第３パスにより新たに生成又は変更された情報により更新されていることは、上記（エ）を参酌しても自明である。
　上記（イ）からすると、構文解析の際に、名前の意味づけ、すなわち、意味解析をも同時に実施しているから、構文解析および意味解析を実施することにより目的コードを生成しているといえる。
　また、コンパイラの技術分野における技術常識からして、構文解析が、プログラム言語の文法規則、すなわち、プログラム定義に基づいて行われていることは自明である。
　
　よって、上記（ア）乃至（オ）からして、引用文献１には次の発明（以下「引用発明１」という。）が記載されている。
　
　ＡＬＧＯＬ６８プログラムを、構文解析および意味解析を実施して前記ＡＬＧＯＬ６８プログラムの目的コードを生成する発展されたコンパイラにおいてコンパイルする方法であって、
　宣言に関するすべての名前が知られていない前記ＡＬＧＯＬ６８プログラム中の宣言を、プログラム定義から構文解析するための情報である定義表及び中間言語プログラムを、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記ＡＬＧＯＬ６８プログラムを構文解析するステップであって、前記複数の構文解析パスは、演算子宣言、優先度宣言及び型宣言を構文解析する第１パスと、変数宣言、同一宣言及びラベル定義を構文解析する第２パスと、手続本体を構文解析する第３パスとを含むステップと、
　各構文解析パスの後に構文解析された宣言の定義表及び中間言語プログラムを保存するステップと、
　先行する構文解析パスののち、後続の構文解析パス中に得られた宣言に関する新たな情報または変更された情報で前記定義表及び中間言語プログラムを更新するステップと
　を含むことを特徴とする方法。
　
Ｂ．原査定の拒絶の理由に引用され、本願の優先権主張の日前である平成７年６月２日に頒布された刊行物である特開平７−１４１２０１号公報（以下「引用文献２」という。）には、次の記載がある。
 
「【０００４】コンパイラは、字句スキャナおよびパーサと呼ばれる２つの主要セクションを用いて構成されることが多い。字句スキャナは、単にスキャナと呼ばれることが多く、ソースステートメントを読み出して、そのソースステートメントからの各ワード記号または数を「トークン」へと分割する。その各トークンには参照記号（数である場合が多い）が付与され、この参照記号がコンパイラのパーサセクションに送られる。コンパイラのパーサセクションは、多数のトークンに処理を行って、それらトークンをその言語で有効なステートメントへと分割する。即ち、スキャナがソースコードをトークンのストリームへと分割し、パーサが、その多数のトークンを解析して、そのトークンがその言語内のステートメントと一致するか否かを判定する。パーサが、１つ以上のトークンと言語内における有効なステートメントとの間に一致を見つけると、パーサ動作ルーチンが呼び出されて、その言語のステートメントに対応するオブジェクト言語コードが出力されることになる。」
　
　つまり、引用文献２には、次の発明（以下「引用発明２」という。）が記載されている。
　
　コンパイラは、字句スキャナとパーサと呼ばれるセクションから構成され、字句スキャナは、ソースステートメントを読み出してトークンに分割し、パーサが、トークンを解析して有効なステートメントを生成し、オブジェクト言語コードを出力するコンパイル方法。
　
Ｃ．原査定の拒絶の理由に引用され、本願の優先権主張の日前である１９８０年に頒布された刊行物である、Sassa, M, et al, Design and Implementation of a Multipass-Compiler Generator, Journal of Information Processing, 1980, Vol.3, No.2, p.77-86（以下「引用文献３」という。）には、次の記載がある。
　
「 Supposing again that we are collecting declarations of an Algol 68 program at the first pass, the input
　　　　　…; int i := n+1, j;
causes a problem that it contains an initialization portion :=n+1 which we do not want to parse in this pass. For this purpose, a mechanism is supplied for saving parser state, restoring it and continuing partial grammar parsing thereafter. Schematically, it can work as follows:
 
　　　　　
…; int i 
 , j; 
　　　　　　　　　　save　　restore
 
Only underlined portions are parsed by the partial grammar.
 Another example follows: 
 
　　　　　
proc p = (real a)real 
　　　　　　　　　　　　　　　save　　restore 」
（第８１頁左欄第２１行−行末（行数は、式及び図を除く。））
［審決仮訳］
「　次に、最初のパスで、Ａｌｇｏｌ６８プログラムの宣言を集める場合を想定すると、次の入力
　　　　　…; int i := n+1, j;
には、このパスでは構文解析を行いたくない初期化部分:=n+1を含むという問題がある。そのため、構文解析の状態を保存し、復元し、その後で、部分文法構文解析を続行するというメカニズムが提供されている。図で表すと、次のように行われる：
 
　　　　　
…; int i 
 , j; 
　　　　　　　　　　保存　　復元
 
下線部の部分だけが部分文法により構文解析される。
　他の例を挙げる：
 
　　　　　
proc p = (real a)real 
　　　　　　　　　　　　　　　保存　　復元 」
　
」
　
（審決注：上記式において、「:=n+1」及び「: …」の上線については記載表現できないので省略した。）
　
　当該記載からして、引用文献３には、次の発明（以下「引用発明３」という。）が記載されている。
　
　構文解析において、変数の宣言を構文解析(parsing)した次のパスで変数の初期化部分(initialization portion)を構文解析し、同様に、関数(proc p)の型宣言を構文解析した次のパスで、関数の本体を構文解析する方法。
　
（３）対比
　本願補正発明と引用発明１とを対比する前に、本願補正発明のうち、「すべての識別子が知られていない前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報を、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップ」（以下、単に「構文解析ステップ」という。）は、不明りょうな表現があるので、その意味内容について検討する。
　まず、構文解析ステップにおける文脈からして、それぞれの「構文解析パス」ごとに「蓄積」されるものは、「すべての識別子が知られていない前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報」である。また、本願補正発明の「各構文解析パスの後に構文解析された宣言のプログラム表現を保存するステップ」は、各構文解析パスにより「宣言」が「構文解析」された結果は、「プログラム表現」として、「保存」されるものと理解されるが、ここで、当該「保存」と前記「蓄積」は同義であるから、構文解析ステップにおいても、構文解析の結果として「蓄積」されるものは、「プログラム表現」でなければならない。このことは、本願補正発明の「構文解析パスののち、前記構文解析パス中に得られた宣言に関する新たな情報または変更された情報で前記プログラム表現を更新するステップ」において、「プログラム表現」が「情報」により更新されることからも裏付けることができる。したがって、前記「すべての識別子が知られていない前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報」は、「プログラム表現」に等しいと理解できる。
　また、構文解析ステップにおいて、「識別子」とは、何の識別子であるのか直接的に特定していないが、「構文解析」の対象が「宣言」であることを考慮すれば、当該「識別子」は、「宣言」に関するものであると把握できる。
　これを踏まえて、本願補正発明と引用発明１とを対比すると、引用発明１の「目的コード」、「発展された」、「名前」、「変数宣言」、「手続本体」及び「定義表及び中間言語プログラム」は、それぞれ本願補正発明の「中間表現」、「機能強化された」、「識別子」、「変数型」、「関数本体」及び「プログラム表現」に対応している。また、本願補正発明の「Ｃ＋＋ソース・コード・プログラム」と引用発明１の「ＡＬＧＯＬ６８プログラム」は、高級言語のソース・コード・プログラムである点で一致している。さらに、本願補正発明の「第一のパス」と引用発明１の「第１パス」は、少なくとも「型宣言」を対象としている点で一致し、本願補正発明の「第二のパス」と引用発明１の「第２パス」は、少なくとも「変数型」を対象としている点で一致し、並びに、本願補正発明の「第三パス」と引用発明１の「第３パス」は、少なくとも「関数本体」を対象としている点で一致している。
　よって、両者は、
　
　高級言語ソース・コード・プログラムを、構文解析および意味解析を実施して前記高級言語ソース・コード・プログラムの中間表現を生成する機能強化されたコンパイラにおいてコンパイルする方法であって、
　すべての識別子が知られていない前記高級言語ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報を、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記高級言語ソース・コード・プログラムを構文解析するステップであって、前記複数の構文解析パスは、少なくとも型宣言を構文解析する第一のパスと、少なくとも変数型を構文解析する第二のパスと、少なくとも関数本体を構文解析する第三パスとを含むステップと、
　各構文解析パスの後に構文解析された宣言のプログラム表現を保存するステップと、
　構文解析パスののち、前記構文解析パス中に得られた宣言に関する新たな情報または変更された情報で前記プログラム表現を更新するステップと
　を含むことを特徴とする方法。
　
の点で一致し、以下の点で相違している。
　
［相違点１］
　本願補正発明は、字句解析を実施してソース・コード・プログラムをトークン化し、トークン化したものに対して構文解析および意味解析を実施することにより中間表現を生成するものであるのに対し、引用発明１は、字句解析およびトークン化について特定していない点。
［相違点２］
　本願補正発明は、第二のパスが変数型のみならず関数型をも対象とするのに対し、引用発明１は、当該関数型について記載がなく、更に、本願補正発明は、第三のパスが関数本体の他に変数イニシャライザをも対象としているのに対し、引用発明１は、当該変数イニシャライザについて特定していない点。
［相違点３］
　本願補正発明は、高級言語ソース・コード・プログラムがＣ＋＋言語であると共に、第一のパスが型宣言のみを対象とし、第二のパスが同一宣言及びラベル定義を対象としていないのに対し、引用発明１では、高級言語ソース・コード・プログラムがＡＬＧＯＬ６８言語であると共に、第一のパスが型宣言の他に演算子宣言及び優先度宣言をも対象とし、第二のパスが同一宣言及びラベル定義をも対象としている点。
　
（４）判断
　以下、上記各相違点について検討する。
　
［相違点１について］
　引用発明２のように、ソース・コード・プログラムに字句解析を実施してトークン化し、その結果をパーサ、すなわち構文解析に用いることはコンパイラにおいて周知であるから、引用発明１に、高級言語ソース・コード・プログラムに字句解析を実施してトークン化し、その結果を構文解析に用いることを付加することは単なる設計変更にすぎない。
　
［相違点２について］
　本願補正発明の「変数イニシャライザ」及び「関数型」は、引用発明３の「変数の初期化部分」及び「関数の型宣言」にそれぞれ対応している。そして、引用発明３は、引用発明１と同じ構文解析に関する技術である点で一致し、かつ、引用発明１は、変数型を第二のパスで、関数本体を第三パスで、構文解析するものであるから、引用発明１に引用発明３を適用し、第二のパスの次のパスである第三パスで「変数イニシャライザ」を構文解析するとともに、第三パスの前のパスである第二パスで「関数型」を構文解析するよう構成することは、当業者が容易に想到し得たものである。
　
［相違点３について］
　本願の優先権主張の日前に、Ｃ＋＋が高級言語として存在していたことは周知の事実であり、かつ、例えば、龍崎、他２名著、”実力養成講座　スタートアップＣ＋＋第５回　クラス（１）”、Ｃ　ＭＡＧＡＺＩＮＥ、ソフトバンク株式会社、第３巻、第９号、１９９１年９月１日、第１２３−１３１頁（以下、「周知文献」という。）のＦｉｇ．３に、クラスの宣言並びに変数及び関数の型宣言を行うこと、並びに、当該周知文献の第１２６頁中欄第２−１１行に変数の初期化を関数により行うことが記載されているように、Ｃ＋＋には、型宣言、関数型及び変数型、並びに、変数イニシャライザに相当する文法が用意されていることも周知である。
　さらに、引用発明１に係る同一宣言、ラベル定義、演算子宣言及び優先度宣言が、ＡＬＧＯＬ６８の文法に基いてプログラムに記述すべき事項であるが、Ｃ＋＋のプログラムにおいてはその文法上不要なものであることは技術常識である。
　したがって、引用発明１の適用言語をＣ＋＋に変更することは単なる設計変更にすぎず、かつ、第一のパスの対象から演算子宣言及び優先度宣言を除外して型宣言のみとし、第二のパスの対象から同一宣言及びラベル定義を除外して変数型及び関数型とすることは、Ｃ＋＋の文法上必然的な事項にすぎない。
　
　なお、請求人は、平成１４年４月２６日付けの審判請求書において、本願補正発明の作用効果について以下のように主張している。
　
［主張１］
　「本願は、上記構成を採用することにより明細書第（００１０）段および、明細書第（００３３）段に記載のようにヘッダ・ファイルの作成および作成されたヘッダ・ファイルがもたらす開発環境問題を無くすることができるように、フォワード宣言および順序づけを無くすることができ、不必要なコンパイルを減らすことで、コンパイル時間を大幅に改善することを可能とするという、顕著な効果を奏するものであります。」
［主張２］
　「本願の上記作用効果は、明細書第（００４０）段、第（００４３）段、第（００４４）段に記載のように、多重パス構文解析技術に対して、各パスにおいて構文解析により得られたプログラム表現を、逐次的に蓄積させ、新たに付け加えられた定義または宣言に関連してインクリメンタリ・コンパイルを行うことを可能とする技術思想を採用すること、また明細書第（００５７）段に記載されるように、優先順位を使用する待ち行列の構成を採用することを可能とする技術思想を採用することにより達成されるものであります。」
　
　以下、上記各主張について検討する。
［主張１について］
　引用発明１は、上記２．（２）Ａ．（イ）で指摘した記載事項からして、ヘッダ・ファイルのように宣言をまとめて記述する部分を設けなくてもよいことは明らかである。よって、引用発明１も、ヘッダ・ファイルがもたらす問題をなくし、不必要なコンパイルを減らすことができる点で本願補正発明と一致している。
　したがって、前記主張１は採用しない。
　
［主張２について］
　引用発明１は、上記２．（２）Ａ．でも指摘したように、各構文解析パスで得られた情報により各定義表及び中間言語プログラムを逐次的に蓄積していることは自明である。
　また、上記主張２における「新たに付け加えられた定義または宣言に関連してインクリメンタリ・コンパイルを行うことを可能とする技術思想」は、本願発明の構成に特定されたものではない。つまり、本願明細書の段落【０００９】には、「Ｃ＋＋コンパイラでは、インクリメンタル・コンパイラの形態をインプリメントする技術であって、「メイク」と呼ばれるツールが、タイムスタンプをもつファイルを最後のコンパイルの後に位置づけたのち、コンパイラに対し、必要なファイルをコンパイルするよう指示することにより、どのファイルを再コンパイルする必要があるかを決定する技術が開発された。」と記載されているが、当該記載及びコンパイラに関する技術常識を参酌すると、前記主張２における「インクリメンタリ・コンパイル」とは、一旦コンパイルが終了した後、再度コンパイルを要する時、すなわち再コンパイル時に、ファイルのタイムスタンプに基づいて、変更がなされたファイルのみをコンパイルする技術であると認められる。
　一方、本願補正発明は、「構文解析パスののち」という文言を含むが、「構文解析パス」がコンパイルの一部分の処理にすぎないことは本願補正発明の構成及び技術常識から明らかであるから、前記文言を例えば「コンパイルののち」とまで拡張して解釈することはできず、したがって、本願補正発明の「前記プログラム表現を更新するステップ」が前記主張２の「インクリメンタリ・コンパイル」に相当しているとは言えない。
　よって、前記主張２も採用しない。
　
　したがって、本願補正発明の作用効果は、引用発明１乃至３及び周知技術から当業者が容易に予測できる範囲内のものである。
　
　以上のとおり、本願補正発明は、引用発明１乃至３及び周知技術に基づいて当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により、特許出願の際に独立して特許を受けることができないものである。
　
（５）むすび
　そして、本件補正は、平成１５年改正前特許法第１７条の２第５項で準用する特許法第１２６条第４項の規定に違反するものであり、特許法第１５９条第１項で読み替えて準用する特許法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について、
（１）本願発明
　平成１４年４月２６日付けの手続補正は上記のとおり却下されたので、本願の請求項８に係る発明（以下、「本願発明」という。）は、平成１３年７月２６日付け手続補正書の特許請求の範囲の請求項８の記載、請求項８が引用する請求項６の記載、及び、請求項６が引用する請求項５の記載からして、次のとおりのものである。
　
　Ｃ＋＋ソース・コード・プログラムを、字句解析を実施して前記ソース・コード・プログラムをトークン化し、構文解析および意味解析を実施して前記ソース・コード・プログラムの中間表現を生成する機能強化されたコンパイラにおいてコンパイルする方法において、
　それぞれが前記ソース・コード・プログラム中の宣言をプログラム定義から構文解析するための情報を蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップと、
　各構文解析パスの後に構文解析された宣言のプログラム表現を保存するステップと、
　構文解析パスののち、前記構文解析パス中に得られた宣言に関する新たな情報または変更された情報で前記プログラム表現を更新するステップと
を含むことを特徴とする方法であって、
　前記複数のパスが最初のパスおよび後続のパスを少なくとも含み、前記最初のパスで、前記トークン化したソース・コード・プログラムの型宣言だけを構文解析するものであり、
　前記最初のパスおよび後続のパスが３回のパスを含み、前記ソース・コード・プログラムからの関数および変数の型を第二のパスで構文解析し、前記ソース・コード・プログラムからの変数イニシャライザおよび関数本体を第三のパスで構文解析する方法。
　
（２）引用例
　原査定の拒絶の理由に引用した引用文献１乃至３、及びその記載事項は、前記２．（２）に記載したとおりである。
　
（３）対比・判断
　本願発明は、技術的に見れば、前記２．で検討した本願補正発明から、「前記ソース・コード・プログラム中の宣言を、プログラム定義から構文解析するための情報を、それぞれのパスごとに蓄積する複数の構文解析パスを通して前記トークン化したソース・コード・プログラムを構文解析するステップ」の限定事項である「すべての識別子が知られていない」の構成を省いたものである。
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記２．（４）に記載したとおり、引用発明１乃至３及び周知技術に基づいて当業者が容易に発明することができたものであるから、本願発明も、同様の理由により、引用発明１乃至３及び周知技術に基づいて当業者が容易に発明することができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用発明１乃至３及び周知技術に基づいて当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。