【事件の表示】
　平成　４年特許願第１０７１４６号「ループの添字情報収集装置」拒絶査定に対する審判事件［平成　５年１１月１６日出願公開、特開平　５−３０３５０１］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯ならびに本件発明の認定　
　
本件審判請求に係る特許出願は、平成４年４月２７日になされたものであって、その請求項１の発明(以下、本件発明という）は、平成１３年３月２６日、平成１３年１０月２２日付け手続補正書により補正された明細書の特許請求の範囲の請求項１に記載されるとおりの以下のものである。
　
　「ループの添字情報を収集する添字情報収集装置において、
　文法でループ変数を持たないソースプログラムを構文解析して構文木を生成する構文解析手段と、
　上記構文木からループ構造となっている文の第１式、第２式、第３式の構文木を取り出し、各式内で区切り記号毎に部分に分けた内部形式に変換するループ構造変換手段と、
　この内部形式の第１式、第２式、第３式のループ変数のうち、ループ内を検索して定義されているものを除いた後、初期値、終値、増分値をそれぞれ取り出し、ループの添字情報を収集する添字情報収集手段
と備えたことを特徴とするループの添字情報収集装置。」
　
　なお、本件審判請求に係る特許出願の明細書段落００１３には、
「図１において、ソース１は、ソースプログラムであって、文法でループ変数を持たない例えばＣ言語で記述した図５の（ａ）に示すソースプログラムである。
この図５の（ａ）のＣ言語によるｆｏｒ文
　ｆｏｒ（ｊ＝１，ｉ＝０；ｉ＜ｎ；ｉ＋＝２，＋＋ｊ）
　｛・・・・・
　　・・・・・
　｝
は、ループ変数を持っていない。従って、最適化時にループ変数ｉを決定し、このループ変数ｉの初期値、終値、増分値をそれぞれ求め、ループの添字情報として採取するようにしている。」と記載され、
　また、同書の段落００１７には、
「（１）図５の（ａ）のｆｏｒ文の第１式、第２式、第３式から変数ｉ、ｊを取り出す。
（２）（１）で取り出した変数のうち、ループ内で定義（変更）されているものを除き、第１式の初期値、第２式の終値、第３式の増分値がそれそれ確定しているものをループ変数とし、ここではｉをループ変数と決定する。」と記載されていることから、
　本件発明における「文法でループ変数を持たないソースプログラム」は「Ｃ言語で記述したソースプログラム」を含み、「ループ構造となっている文の第１式、第２式、第３式の構文木を取り出」すことは「ｆｏｒ文の第１式、第２式、第３式の構文木を取り出」すことを含み、「ループの添字情報」とは「ループ変数とその初期値、終値、増分」を含むものと解するのが相当である。
　
２．引用例記載の発明の認定　
　
　一方、原査定の拒絶の理由に引用された、R.Allen他、Compiling C for 
Vectorization,Parallelization and Inline Expansion、ACM SIGPLAN Notice, 1988, pp.241-249（以下、引用例という）には以下の事項が記載されている。　
　
（１）引用例記載の発明の前提、および解析の対象とするソースプログラムについて
　
（ア）「This paper discribes the implementation of a C compiler focused on the generation of high-quality code for a multi-processor vector machine.」(p.242左段第２０行から第２２行)
（（訳）本論文はマルチプロセッサベクトルマシン向けに高品質のコード生成することに向けられたＣコンパイラの実現について記述する。）　
　
（イ）「Unfortunately, optimizing C is difficult when vector and 
parallel architechtures are involved.・・・（中略）
３． The for statement in C is considerably less constrained than 
the Fortran DO loop, making vectorization considerably more 
difficult. The loop bounds and increment may change within the 
universally contain operators with side effects to increment the
loop variable (if there even is a loop variable).」
(p.241右段第３行から第２６行より抜粋)
（（訳）残念なことに、ベクトルや並列アーキテクチャを含む場合、C言語のプログラムを最適化することは難しい。（中略）
３．C言語におけるfor文はFortranのDOループよりかなり制約が少ないため、ベクトル化はかなり難しい。ループの境界と増分はループ内で変わりうる；分岐がループ内に入ることが文法的に正しいとされている；forループはほぼ例外なくループ変数を増分する副作用がある演算子を（たとえループ変数があったとしても）含む。）
　
（ウ）「5.Processing C for Vectorization
5.1 Overview 
Effectively vectorizing C requires a number of enhancements not 
normally present in vectorizing Fortran compilers. While there 
are a number of subtle enhancements throughout the compiler, 
there are two majpor changes that are worthy of discussion.
1. Special analysis to convert while loops into Fortran DO loops. 
Since C for loops are converted to while loops by the front end, 
this transformation is essential to success. While the conversion 
of while loops to iterative loops may seem straightforward, there 
 are a surprising number of intricacies involved in the process.」
（p.243右段下から１２行より右段最下行）
(（訳）５．ベクトル化のためのＣプログラムの処理
５．１　概要
Ｃプログラムを効率的にベクトル化するには、ベクトル化Fortranコンパイラでは普通無い機能強化が必要とされる。多くの細かな機能強化がコンパイラ全般において施されている中で、２つの大きな変更が特に議論の価値あるものである。
１．whileループをFortranのDOループに変換するための特別な解析。C言語のforループはフロントエンドによってwhileループに変換できるため、この変換は（ベクトル化の）成功に必須のものである。whileループを繰り返しループに変換することは直接に行えるものであるのに対して、そのプロセスは驚くほど多くの複雑さを含む。) 
　
（エ）「5.2. Conversion of While Loops
The C for loop is one of many C entities which are easily mapped 
into good instruction sequences on serial architectures, but which 
are difficult to treat well on vector and parallel architectures. 
The for loop is relatively unconstrained: the termination and 
increment conditions can have unusual side effects (particularly 
during loop execution (if there even are explicit bounds and 
Given this lack of regularity, we saw little value in having an 
explicit representation of for loops in our intermediate form.
Instead, the C front end represents for loops as while 
loops-something it can do straightforwardly without sophisticated 
analysis.」 （p.244左段第９行から第１６行）
（（訳）５．２　Whileループの変換
Ｃ言語のforループはシリアルアーキテクチャの良い命令列に簡単に変換できるC言語の実体の１つであるが、ベクトルや並列アーキテクチャの上でうまく扱うことは難しい。forループは比較的制限がない：終了条件や増分条件は、（特に揮発性変数が含まれている場合に）独特の副作用を持っている；境界やストライドはループ実行（もし明示的な境界やストライドがあっても）中に変化しうる；分岐は意のままにループに入ったりループから脱出したりする。
規則性の欠如によって、forループの我々の中間形式への明示的な表現を持つことにそれほどの価値を見いだせない。それよりも、C言語のフロントエンドはforループをwhileループに表現するものであり、これは洗練された分析を必要とせずただちに行えることである。）
　
（オ）「Of course, while loops are not generally as well optimized 
as Fortran DO loops are, and since many for loops are DO loops cast 
in a different guise, converting while loops to DO loops is an 
important transformation for the compiler. Given the ways in which 
for loops can differ from DO loops, a significant amount of 
information is necessary to effect the conversion:」
（p.244左段第１７行から第２２行）
（（訳）もちろん、whileループはFortranのDOループほどよく最適化できるわけではない。ただ、多くのforループは異なったやり方でDOループの役割を行うため、whileループをDOループに変換することはコンパイラにとって重要な変換である。
forループがDOループとは異なる方法を仮定すると、かなりの量の情報が効果的な変換には必要となる。）
 
（カ）「２ Variation of bounds and strides within the loop is 
most easily determined by examining the use-def chains built 
during scalar analysis.」（p.244左段第３２行から第３４行）
（（訳）境界とストライドのループ内での変化はスカラー解析によって構築された使用-定義チェインを調べることで簡単に決定できる。）　
　
（キ）「Both of these facts argue that conversion of while loops
 should occur during scalar optimization. Moreover, since the 
primary motivation is to utilize vector hardware for for loops where
possible, the conversion of while loops must come early in the 
scalar optimization process. If for loops are to reap the full 
benefit of the analysis applied to DO loops, then they must be 
converted before all the phases which simplify DO loops-induction 
variable substitution, constant propagation, and dead code 
elimination. Given these restrictions, the proper place to convert 
while loops is immediately after use-def chains have been 
constructed.」
(p.244左段第３５行から第４４行)
（（訳）これらの事実はwhileループの変換はスカラー最適化中に行うべきということを示す。加えて、主たる動機は可能な場合にベクトルハードウェアをforループのために可能な場合利用するというものであるため、whileループの変換はスカラー最適化の初期に行う必要がある。もしforループはDOループに適用される解析方法の利益を受けるならば、それらはDOループを簡単にする−帰納変数の置き換え、定数伝搬、不到達コードの削除−全ての段階の前に変換されなければならない。
これらの制約を考えると、使用−定義チェインが構築された後、whileループを適切に置き換えることがすぐに行われなければならない。）
 
　そして、（ア）から（キ）に記載の事項から見て、
・引用例記載の発明はＣ言語のfor文をベクトル化することを目的としたコンパイラに関するものであること、
・Ｃ言語のfor文においては仮にループ変数が定義されていても、ループの終了条件（境界）や増分条件（ストライド）が副作用のある演算によってループの実行中に変化しうるものであり、これがベクトル化にあたっての困難な点となっていること、
・これら条件の変化は使用−定義チェインを調べて決定すること、
が引用例に記載されている。
　ここで、for文の第１式、第２式、第３式がループの初期値、終了条件、増分値であることはＣ言語の書式における常識であることを鑑みれば、この記載を実現するための何らかの手段、すなわち、Ｃ言語の構文解析を行い構文木を構成する手段、for文の中の第１式、第２式、第３式からループ変数の初期値、終値、増分値をそれぞれ取り出すための手段、ループ変数の変化がループ内で引き起こされることを検出するための手段を当然備えるものと認められる。
　
 してみれば、引用例には以下の発明が記載されているものと認める。
　
　ループの変数に関する情報を収集する情報収集装置において、
　Ｃ言語のソースプログラムを構文解析して構文木を生成する構文解析手段と、
　上記構文木からfor文の第１式、第２式、第３式の構文木を取り出し、第１式、第２式、第３式の変数から、ループ変数と初期値、終値、増分値をそれぞれ取り出す手段と、
　ループ内でのループ変数の変化が引き起こされることを検出するための手段、
と備えたことを特徴とするループの変数に関する情報収集装置。
　
３．本件発明と引用例記載の発明との対比　
　先の認定のとおり、本件発明における「文法でループ変数を持たないソースプログラム」とは「Ｃ言語で記述したソースプログラム」を含むものと認められ、「ループ構造となっている文の第１式、第２式、第３式の構文木を取り出」すこととは「ｆｏｒ文の第１式、第２式、第３式の構文木を取り出」すことを含むものと認められ、また「ループの添字情報」とは「ループ変数とその初期値、終値、増分」を含むものと認められるから、この点に基づき本件発明と引用例記載の発明とを対比すると、両者は、
　
　ループの添字情報を収集する添字情報収集装置において、
　文法でループ変数を持たないソースプログラムを構文解析して構文木を生成する構文解析手段と、
　上記構文木からループ構造となっている文の第１式、第２式、第３式の構文木を取り出し、第１式、第２式、第３式のループ変数のうち、初期値、終値、増分値をそれぞれ取り出し、ループの添字情報を収集する添字情報収集手段と
と備えたことを特徴とするループの添字情報収集装置。
で一致する。
　
一方、両者は以下の点で一応相違する。　
　
（１）本件発明においては、構文木からループ構造となっている文の第１式、第２式、第３式の構文木を取り出し、各式内で区切り記号毎に部分に分けた内部形式に変換するループ構造変換手段を備えるのに対して、引用例記載の発明においては、構文木からループ構造となっている文の第１式、第２式、第３式の構文木を取り出すものの、各式内で区切り記号毎に部分に分けた内部形式に変換することについては不明である点、
　
（２）ループの添字情報に際して、本件発明においては、ループ内を検索して定義されているものを除いた後、初期値、終値、増分値をそれぞれ取り出し、ループの添字情報を収集するのに対して、引用例記載の発明においては、初期値、終値、増分値を取り出し、さらにループ内でのループ変数の変化が引き起こされることを検出するものであって、ループ内を検索して定義されているものを除くわけではない点。
　
４．相違点に対する当審の判断
　
　相違点（１）について、
各式内で区切り記号毎に部分に分けた内部形式の例として、本件出願の明細書および図面においては、図６（ａ）に内部形式が記載されているが、これは図５（ｂ）の構文木と同じだけの情報を保持するものにすぎない。また、本件明細書段落００２９には「図６（ａ）に示す処理のし易い形の内部形式」という記載があるものの、図５（ｂ）の構文木とまったく同じだけの情報を持つ、構文木が簡約化されたわけでもない表現形式にすぎない以上、この変換を行った後で添字情報を取り出すか、構文木から直接に添字情報を取り出すかは当業者が適宜なし得る単なる設計事項にすぎない。
　
　相違点（２）について、
　引用例記載の発明においては、ループ変数がループ内での変化を検出するための手段を備えているが、これはループ変数がループ内において操作されたことを発見した場合にもループ変数の境界、ストライドを追跡し最適化に利用するための工夫である。一方、本件発明においては、ループ変数の境界とストライドがループ内で変化する場合の最適化を行うことなく、これらの値がループ内で変化するときは最適化の対象としない、すなわち、最適化の過程を省略しているにすぎず、このような機能を単に削減する変更を行うことは当業者が必要に応じてなし得る単なる設計変更にすぎない。
　
５．結び　
　以上のとおり、本件発明は、本件出願前に引用例記載の発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定に基づき特許を受けることができない。　
　
　よって、結論のとおり審決する。