【事件の表示】
　平成　５年特許願第１１５６０９号「コンパイラ装置」拒絶査定に対する審判事件［平成　６年１１月２５日出願公開、特開平　６−３２４８８１］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯ならびに本件発明の認定　
　
本件審判請求に係る特許出願は、平成５年５月１８日になされたものであって、平成１３年１月２９日付手続補正書により補正された明細書及び図面の記載から見て、その請求項１の発明（以下、本件発明という）は、明細書の特許請求の範囲の請求項１に記載されるとおりの以下のものである。
　
「ソースプログラムに基づき中間テキストを出力するフロントエンド部を有するコンパイラ装置であって，
　ポインタ変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」であるポインタ変数に関する複数のペアについて，各ペア毎の「一致」「不一致」の組合せを生成し，組合せ毎に管理するループ展開リストを作成する静的メモリデータ解析部と、
　前記ループ展開リストに基づいて，ループの中間テキスト列を前記組合せの数複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成する動的メモリアドレス比較命令生成部と、
　前記ループ展開リストに基づいて，前記組合せに応じたパス毎に複写された中間テキスト列を最適化する最適化処理部と
　を有するコンパイラ装置。」　
　
２．本件明細書における開示不十分な点について
　
　当審で合議の結果通知した、平成１４年７月１５日付拒絶理由において、本件明細書には本件発明が実施可能な程度に開示されていない旨を以下の通りに示した。
　
「本件明細書中には、本件明細書中には請求項１の発明に関する抽象的アルゴリズムの記載はあるが、例えば本件図面の図３のプログラムは請求項１の発明の処理を施された後で、どのようなプログラムに変形されるのか記載されておらず、またその他の請求項１の発明の説明は技術的に不十分なものでしかないと思われる。
したがって、本件明細書において、当業者が実施可能な程度に発明を開示しているとは言えない。　
（もし、本件明細書の説明をもって十分な開示がされていると主張するのであれば、本件図３のプログラムを入力として本件明細書中に説明のアルゴリズムにより最終的にどのような中間コードが生成されるのか、適当な中間コードを考えた上で意見書などによる説明が必要である。）」
　
これに対して、審判請求人は、
　
「請求項１に記載の発明を実現するための技術的な裏付けとして，図面の図１にはハード的な構成（各手段の構成）を開示し，図２にソフト（フローチャート）を開示したものであり，図３乃至図８には具体例を用いた技術的な説明を示している。
　したがって，図３に例示したプログラムが請求項１の発明の処理を施された後で，どのようなプログラムに変形されるのか記載されてないからといって，「したがって，本件明細書において，当業者が実施可能な程度に発明を開示しているとは言えない。」という判断は，その不明とする根拠が明確でなく，また例として挙げた図３に関する指摘も上記のように適切とは言えないため，何をもって当業者が実施可能な程度に発明を開示しているとはいえないのか，不可解としかいいようがありません。
　審判官は，括弧書きで「本件明細書の説明をもって十分な開示がされていると主張するのであれば，本件図３のプログラムを入力として本件明細書中に説明のアルゴリズムにより最終的にどのような中間コードが生成されるのか，適当な中間コードを考えた上で意見などによる説明が必要である。」と述べているが，そもそもこのような説明をする必要があるのか疑問があります。」
　
と主張する。
　
　しかしながら、請求項１に記載の発明は先に認定のとおりの「コンパイラ装置」に関するものであって、本件発明については、少なくとも入力されたソースコードから明細書に記載されたアルゴリズムによって最終的にどのようなコードが生成されるのかが明確でなければ、明細書に記載の事項から当業者が実施することができるかどうか甚だ疑問があるとせざるを得ないのであるから、前記の説明が必要ないという具体的な根拠が不明な請求人の主張は到底採用できないものである。
　
　該明細書の記載から、仮に図３の入力から図６のような重なり不明リストが生成されることが理解できたとしても、その後における、ループ展開用リストの各要素について、挿入される各要素の「一致」「不一致」を満たす条件判定中間テキストとはどのようなものか、複写されるループ情報（ループデータ、中間テキスト列）とは具体的にどのようなものになるのか、更には、前記ループ情報の静的メモリ重なり判定リストを変更した結果、どのような状態からどのような状態に変更されるのか、など本件明細書の記載からでは全く不明である。
　
　すなわち、本件明細書には漠然とした概念ないし大雑把なアルゴリズムが提示されているにすぎず、しかもその概念ないしアルゴルズムの提示は図３のような具体的な入力がされた場合の具体的な出力がどのようなものになるのか見当がつかない程度に抽象的なものにすぎず、発明の開示として具体性を欠くものである。
　
　以上のとおりであるから、本件明細書には本件発明が当業者が実施可能な程度に開示されているということはできない。
　
　
３．引用例記載の発明の認定
　
　上記２のとおり、本件発明は当業者に実施可能な程度に本件明細書に記載されているわけではないが、本件発明は本件明細書の特許請求の範囲の請求項１に記載される事項をその構成要件とするものである。
　
　一方、当審で合議の結果通知した、平成１４年７月１５日付拒絶理由通知書において引用した、
Nicolau,A.,Run-Time Disambiguation:Coping with Statically 
Unpredictable Dependencies,
IEEE Transactions on Computers,Vol.38,No.5,1989年5月,P.663-678（以下引用例という）には以下のことが記載されている。
　
（１）「we present a new technique, run-time disambiguation(RTD),for
 anti-aliasing of indirect memory references that cannot be
 disambiguated at compile time」(P.663左段上部のAbstractの
第２パラグラフ１−３行)　
（なお、引用例のP.663右欄７行から９行のAnswering the question of 
whether two references are independent of each other is the problem
 of memory anti-aliasing or disambiguation.という記載からみて、
memory anti-aliasing とdisambiguation は同じ意味を表すものである）
（訳：我々は新しい技術であるランタイムあいまい解消技術を提案する。これはコンパイル時にあいまい解消ができない間接メモリ参照のあいまい解消に対するものである。）
　
（２）「While a large fraction of indirect reference occurring in
ordinary code (particularly scientific code) are array references
that can be disambiguated at compile time, others are too
dependendent on run-time information to yield to any fully static
analysis. 
 For example, the code in Fig.2(unlike that in Fig.1)cannnot be 
disambiguated by any purely static analysis. Also intractable by 
fully static analisys are most pointer references, and multiple 
indirection. 」
（P.665左欄のD. Limitations of Fully Static Disambiguationの第１パラグラフ１行から８行）
（訳：通常のコード（特徴的には科学技術計算コード）に現れる間接参照の大きな塊はコンパイル時にあいまい解消される配列参照であるのに対して、その他、全てを静的解析によるどんな解析でも生成できないほどランタイムの情報に依存するコードもある。例えば、図２のようなコードは図１のそれと違って純粋に静的な解析ではあいまい解消できない。さらに全てを静的解析による場合では処理できないものとして多くのポインタ参照と多段間接参照がある。）
 
（３）「The run-time disambiguation system(RTD) we have
 implemented for Bulldog treats memory anti-aliasing of reference
 which cannot be effectively disambiguated at compile time」
（P.666右段下部のB. Run-Time Disambiguationの第１パラグラフ１−４行)
（訳：我々がBulldogシステムのために実現したランタイムあいまい解消システムは、コンパイル時にはうまくあいまい解消をすることができないメモリ参照のあいまい解消を扱う。）
 
（４）「Given two references that cannot be disambiguated
 at compile time, a potential conflict between them (i.e. i=j )
 (Fig.4) has to  be conservatively resolved to ensure correctness
 using the traditional disambiguation approach.
 RTD, on the other hand, will transform the code segment to that
 in Fig.5. The 0.9 probability estimate gives the trace (a,l1,b)
 priority in the compaction process.」
(P.666右段下部のB. Run-Time Disambiguationの第２パラグラフ１−７行)　
（訳：コンパイル時にあいまい解消できない２つの参照が与えられた場合、これらの、（すなわち図４においてi=jとなるような）、潜在的な衝突は、従来のあいまい解消アプローチを用いて正当性を保証するには、保守的に解決されなければならない。一方、ランタイムあいまい解消システムは図５のようにコードセグメントを変換する。0.9の確からしさという評価がコンパクションプロセスにおける優先度をトレース(ａ，ｌ１，ｂ)に与える。）
　
（５）引用例P.667左欄のFig.4、Fig.5には
(a)A[i]
・・・・
(b)A[j]
Fig.4 ランタイムあいまい解消コードの挿入前のオリジナルコード
　
(a)A[i]
・・・・
if i=|=j  l1 l2 .9　/* i  not equal j */
l1:assert i=|=j
(b)   l2:A[j]     
Fig.5 ランタイムあいまい解消コードを挿入したあとのコード
　
ということが記載されている。
　
（６）「The assertion in statement l1 will be placed in a small
database for the disambiguator and will supercede any information
the disambiguator may have obtained about the references for that
path. 
 The asserted information will be used as a compiler directive,
allowing a,b to be scheduled independently. Of course, the
off-trace branch must take care at run-time of the case in
which i=j. 
 Depending only on the computation of i and j, the if statement
might be placed early in the schedule.」
(P.666右段下部B. Run-Time Disambiguationの第２パラグラフ７−１３行)
（訳：文l1のアサーションはあいまい解消器のための小さなデータベースにおかれ、あいまい解消器がそのパス（トレース（ａ，l１，ｂ））の参照について取得しえた全ての情報を置き換える。
アサートされた情報は、aとｂが独立にスケジュールされることを許すという、コンパイラに対する指示として用いられる。
もちろん、トレースされない分岐は実行時にi=jとわかる場合に注意をすることが必要である。）
　
（７）「The approach consists of traversing the input code along
each possible path, and identifying operations that involve
indirect memory references which cannot be disambiguated by the
fully static (Bulldog) disambiguator. 」
(P.667左欄第２パラグラフ２−６行)　
（訳：このアプローチは、入力されたコードをそれぞれの実行可能なパスに従ってなぞり、間接的メモリ参照を含む命令を特定するということからなるものであり、この間接メモリ参照は完全に静的なBulldogあいまい解消器によっては解消できないものである。）
　
（８）「Since trace scheduling treats loops individually, RTD has
to also do so, by inserting RTD code for each loop. 
 This is achieved by fresh recursive calls to 
 insert-run-time-disambiguation-code for each loop.」(P.667左欄第２パラグラフ１０行からP.667右欄２行)　
（訳：トレーススケジューリングがループを独立に処理するため、ランタイムあいまい解消システムもまた同様にループを独立に処理する必要があり、これはランタイム誤り解消用のコードを各ループに挿入することにより処理される。これは各ループに、再帰的にinsert-run-time-disambiguation-codeを新たに呼び出すことにより達成される。）
　
（９）「The code for implementating this approarch was shown in
Fig.6. For this appoarch to work well, the compiler was modified to
do two passes.
 During the first pass, the input program is compiled into 
sequential NADDR(our intermediate language)」（P.671左欄下から５行から最終行）（訳：このアプローチにより実現されたコードは図６に示されていた。このアプローチを上手く行うために、コンパイラは２つのパスを行うように改変された。最初のパスで入力されたプログラムは逐次的なNADDRとよばれる我々の中間言語にコンパイルされる）
　
さて、（１）（３）（９）の記載から見て、引用例記載の発明は、間接メモリ参照による別名参照（異なる変数名による同じメモリ領域の参照）があるかどうかについてのあいまい性をコンパイル時ではなく実行時に解消するようなコンパイラであって、ソースコードに基づき中間コードを生成するコンパイラに関するものであると認める。
　
また、（２）の記載から見て、コンパイル時にあいまい性を解決できない間接メモリ参照としてポインタ変数による参照が含まれることは当業者にとってよく知られた技術事項であるものと認める。
　
また、（４）（５）の記載から、引用例記載の発明において、判定結果が不明である複数の間接的メモリ参照を含む変数に関するペアについて、「一致した場合」と「一致しない場合」についての組み合わせを考慮して、実行時にメモリデータの重なりの判定と判定結果に応じた分岐を行うための、分岐命令の生成を行うものと認める。
ところで、「コンパクション」とは、引用例P.665右欄２７行目に
「parallelization(compaction)」という記載があることから見て、命令の並列実行のための最適化処理を指すものと認められる。
そして、この点を考慮して、（４）（５）（６）を総合すると、引用例記載の発明において、この分岐命令が生成されたコードの各pathに対して、その後トレーススケジューリングにより命令の並列実行を目的とするものを含めた最適化を行うものと認める。
　
さらに、（７）、（８）から見て、動的に間接メモリ参照のあいまい性を解消するための命令列を生成するコンパイラにおいて、トレーススケジューリングと同じく、ループを持つ命令列を変形するに当たっては、各path毎にその後の処理を施すものと認める。
このとき、「The split compensation consists of copies of all the 
operations skipped by a conditional jump moving upward in the trace 
body during compaction.（中略）(see the example in Fig.3)」
(P.666右欄５行から１６行より抜粋）（訳：スプリット補償は、コンパクションの際、トレースの本体に移動される条件ジャンプによってスキップされる全ての命令の複写からなる。（中略）図３を参照））とあることから見て、トレーススケジューリングと同じく、ループを持つ命令列を変形する場合、ループの中に含まれる分岐命令によってスキップされる命令列の複写を行うものと認める。
　
以上のことから見て、引用例には以下の発明が記載されているものと認める。
　
　ソースプログラムに基づき中間テキストを出力する部分を有するコンパイラ装置であって，
　間接メモリ参照する変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」である変数に関するペアについて，ペア毎の「一致」「不一致」の組合せを元に、
　中間テキスト列を前記組合せの数複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成する部分と、
　前記組合せに応じたパス毎に複写された中間テキスト列を最適化する最適化処理部と
　を有するコンパイラ装置。
　
４．本件発明と引用例記載の発明との対比　
　
　２．のとおり、本件明細書において本件発明が当業者が実施可能な程度に開示されているかどうか不明ではあるが、本件発明を文言通り認定した場合について、３における引用例記載の発明と対比する。
　
　本件発明における「フロントエンド部」は引用例記載の発明における「中間テキストを出力する部分」に相当する。
　また、本件発明における「静的メモリデータ解析部」が行う処理である、
「ポインタ変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」であるポインタ変数に関するペアについて，ペア毎の「一致」「不一致」の組合せを生成」することは、引用例記載の発明においても行われる処理である。
　さらに、本件発明における「動的メモリアドレス比較命令生成部」が行う処理である「ループの中間テキスト列を前記組合せの数複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成」することも、引用例記載の発明においても行われることである。
　
以上の点を踏まえて、本件発明と引用例記載の発明とを対比すると、両者は、
　
　ソースプログラムに基づき中間テキストを出力するフロントエンド部を有するコンパイラ装置であって，
　変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」である変数に関するペアについて，ペア毎の「一致」「不一致」の組み合わせを元に、
　中間テキスト列を「一致」、「不一致」のパスの数にあわせて複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成する部分と、
　前記パス毎に複写された中間テキスト列を最適化する最適化処理部と
　を有するコンパイラ装置。
　
で一致する。
一方、両者は以下の点で相違する。
　
（１）本件発明においては、判定結果が不明であるポインタ変数に関するペアについて、「一致」「不一致」の組み合わせを生成するの対して、引用例記載の発明では判定結果が不明な間接メモリ参照変数に関するペアについて、「一致」「不一致」に関する情報を生成する点、
　
（２）本件発明においては、判定結果が不明である変数に関する複数のペアについて、各ペア毎の「一致」「不一致」の組み合わせを生成し、ループの中間テキスト列を前記組み合わせの数複写するのに対して、
引用例記載の発明では判定結果が不明である変数に関するペアの数については言及されておらず、中間テキスト列を複数複写するかどうかについては不明な点、
　
（３）本件発明においては、判定結果が不明であるポインタ変数に関するペアについて、「一致」「不一致」の組み合わせを生成し、その組み合わせ毎に管理するため、ループ展開リストを備えるのに対して、引用例記載の発明ではそのような管理機能については格別の言及が無い点、
　
（４）本件発明においては
「静的メモリデータ解析部」において「ポインタ変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」であるポインタ変数に関する複数のペアについて，各ペア毎の「一致」「不一致」の組合せを生成し，組合せ毎に管理するループ展開リストを作成し、
「動的メモリアドレス比較命令生成部」において、前記ループ展開リストに基づいて，ループの中間テキスト列を前記組合せの数複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成する、
のに対して、引用例記載の発明では一連の処理を行うに際して、処理をどのように分割して行うか、分割された個々の処理を行うための構成はどのようなものか、格別の言及が無い点
　
５．相違点に対する当審の判断
　
（１）について、３（２）にもあるように、動的にあいまい解消される間接メモリ参照の１つとしてポインタ参照があることは引用例に記載されていることから、引用例記載のコンパイラにこのような機能を持たせ、ポインタ変数に関するペアについても判定結果が不明であった場合に「一致」「不一致」の組み合わせを生成するようにすることは、当業者が必要に応じてなし得る単なる設計変更にすぎない。
　
（２）について、判定結果が不明である変数のペアが複数ある場合には、それら複数のペアについて中間テキスト列の複写を行うように構成する程度のことは単に引用例記載の発明を判定結果が不明である変数のペアが複数ある場合に対応させたにすぎず、当業者が格別の困難無く想到しえた事項にすぎない。
　
（３）について、引用例記載のものにおいても判定結果が不明である変数に関するペアについて何らかの管理を行って、そのペアに応じて中間テキスト列を複写する処理を行う点では本件発明との違いはなく、これを本件発明のようにループ展開リストとして管理することは当業者が必要に応じてなし得る設計事項にすぎない。
　
（４）について、間接メモリ参照する変数の指し示すメモリデータの重なり判定を行い，判定結果が「不明」である変数に関するペアについて，ペア毎の「一致」「不一致」の組合せを元に、中間テキスト列を前記組合せの数複写するとともに，実行時にメモリデータの重なりの判定と判定結果に応じて分岐を行う分岐命令を生成するという一連の処理をどの点で分割し、分割された個々の処理を行うための構成要件を割り当てるかは当業者が必要に応じてなし得る設計的選択事項にすぎない。
　
６．結び　
　２のとおり、本件明細書には本件発明が実施可能な程度に開示されているということはできず、本件出願は特許法第３６条第４項に規定する要件を満たしていない。　
　３から５のとおり、本件発明は、本件出願前に引用例記載の発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定に基づき特許を受けることができない。　
　
　よって、結論のとおり審決する。