• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36 条４項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1076213
審判番号 不服2002-7779  
総通号数 42 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 1995-03-20 
種別 拒絶査定不服の審決 
審判請求日 2002-05-02 
確定日 2003-05-07 
事件の表示 平成 5年特許願第222725号「コンパイラ装置」拒絶査定に対する審判事件[平成 7年 3月20日出願公開、特開平 7- 78087]について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続きの経緯

本件審判請求に係る特許出願は、平成5年9月8日になされたものであって、平成13年11月19日付で拒絶理由の通知がなされ、これに対して平成14年1月24日付で意見書が提出され、平成14年4月2日付で拒絶査定の謄本が送付され、これに対して同年5月2日付で拒絶査定に対する審判請求がなされ、平成14年5月24日付で手続補正がされたものである。
その後、平成14年8月28日付で当審による拒絶理由が通知され、平成14年10月31日付けで意見書の提出及び手続補正がなされ、さらに平成15年2月4日付けで上申書の提出がなされたものである。


2.平成14年8月28日付拒絶理由

当審における合議の結果通知された、平成14年8月28日付拒絶理由は以下の通りである。
「本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第36条第4項並びに第5項及び第6項に規定する要件を満たしていない。

記
平成14年5月24日付手続補正書により補正された本件出願に関する明細書の請求項1には、
「所定のプログラミング言語で記述された原始プログラムを解析して目的プログラムを生成するオブジェクト生成部と、共通シンボル管理部と、複数の目的プログラムを結合編集して実行形式プログラムを生成する実行形式プログラム生成部とを有し、
オブジェクト生成部は、原始プログラム中の共通シンボルに関する所定の宣言を解析して、共通シンボルに関するデータ領域と属性定義情報とを設定した共通シンボルセクションを目的プログラム内に生成し、
共通シンボル管理部は、前記共通シンボルごとに、該共通シンボルを有する複数の前記目的プログラムの共通シンボルセクションに設定された属性定義情報を比較し、該属性定義情報の対応する項目間の定義内容に矛盾がない場合に、すべての属性定義情報をマージした結果を属性定義情報として持つ共通シンボルセクションを選択して実行形式プログラム生成部に通知し、
実行形式プログラム生成部は、共通シンボル管理部から通知された該共通シンボルセクションを使用して、前記共通シンボルに関わる該実行形式プログラムの生成処理をするように構成されていることを特徴とするコンパイラ装置。」と記載されている。

ところで、「属性定義情報の対応する項目間の定義情報に矛盾がない場合」について、ある共通シンボルを共有する複数の目的プログラム中に含まれる属性定義情報を比較して、どのような結果が得られた場合、「属性定義情報の対応する項目間の定義情報に矛盾がない」と判断されるのか、定義情報の矛盾についての定義がない、ないし不明である
(明細書段落0033には「属性定義に矛盾があることを検出し」としか記載されておらず、また、共通シンボル管理部の動作の説明において属性定義の検出に関連すると思われる段落0040-0043の記載は日本語として理解し難く、不明であると言わざるを得ない)。

(中略)

また、本件出願に関する明細書の記載、特に段落0030以降の実施例の根幹に関する記載は、日本語として意味不明な上、技術的にも不可解である。
以下、具体例を列挙した上で、審判請求人が平成14年1月24日付意見書ないし平成14年5月24日付審判請求理由を補充する手続補正書について反論する事項との齟齬ないしは上記意見書、手続補正書における技術的矛盾を示す。

(1)段落0030から0031について

「オフジェクト(オブジェクトの誤記と思われる)生成部1は共通シンボルセクション7に、COMMON文で指定された共通シンボルとローカルなデータ名との対応(図4(a)の例のBLKとA)に従って、ローカルデータ名のデータについて定義されている属性に従うデータの情報を共通シンボルセクションに生成すると共に、前記図2の形式で属性定義情報を設定する。オフジェクト生成部1は属性定義情報を、図2(b)の各項目に、各項目位置によって定まる内容を順次設定していって、有効情報を設定した最後の項目までの長さの情報として生成し、途中に該当する定義の無い項目があれば、それらの項目には例えば所定のnull記号を設定しておく。」とあるが、

・「定義されている属性に従うデータの情報」という記載は日本語として不明であるとともに、技術的にどのような事項を指すのか理解不能である。
・どの情報を読みとって「図2の形式で属性定義情報を設定する」のか、日本語として不明である。
・「有効情報を設定した最後の項目までの長さの情報として生成し」とは、どのような情報を長さの情報として生成して、どこに設定するのか不明である。
・「途中に該当する定義のない項目があれば、それらの項目には例えば所定のnull記号を設定しておく」という記載も技術的に意味不明である。

(中略)

PARTITION P1’=(プロセッサ数=4、分割範囲=1:1000)
PARTITION P2’=(プロセッサ数=4、分割方法=均等)
という指示を含む原始プログラム(仮に、Pｒｏ1’,Pｒｏ2’とする)をコンパイルして目的プログラムを生成するとき、上記の審判請求人の主張によれば、この属性定義情報の付加属性は以下のようになるはずである。

Pｒｏ1’では
付加属性1(プロセッサ数)4
付加属性2(分割範囲)1:1000
付加属性3(分割方法)nｕll
Pｒｏ2’では
付加属性1(プロセッサ数)4
付加属性2(分割範囲)nｕll
付加属性3(分割方法)均等

さて、Pｒｏ1’、Pｒｏ2’と関連する原始プログラム(仮にPｒｏ3とする)があって、

PARTITION P3=(プロセッサ数=4、分割幅=300)

という指示を含むとき、Pｒｏ1’またはPｒｏ2’のコンパイルの事前または事後に、この原始プログラムPｒｏ3をコンパイルして目的プログラムを生成する場合、属性定義情報のうち付加属性は、審判請求人の主張を総合的に把握すると、次のいずれかになるはずである。
(略)
付加属性1(プロセッサ数)4
付加属性2(分割範囲)nｕll
付加属性3(分割方法)nｕll
付加属性4(分割幅)300

(中略)
後者のような属性定義情報を生成するのであれば、どのようなアルゴリズムに基づけばPｒｏ1’,Pｒｏ2’の存在を知らなくても付加属性2、3にnｕllを設定できるのか理解不能であるし、この場合、Pｒｏ1’もPｒｏ2’も付加属性4にnｕllが設定されるべきところではあるが、上記意見書の説明からではどのようになるかまったく不明である。

結局のところ、Pｒｏ3をコンパイルする際にはどのような処理が行われてどのような属性定義情報が生成されるのか、その技術的根拠は明細書のどの部分から当然に導き出せるのか、理解不能である。

以上の点からみて、意見書の上記説明は明細書段落0030から0031の記載を実質的に不完全に補完するものであるか、明細書段落0030から0031の記載からでは把握できないことを中途半端に説明するものであり、これをもって明細書の上記記載不備を治癒するものではない。

(中略)

(6)段落0041

「即ち、上記の何れかであるということは、すべての項目について全属性定義情報間で定義内容の一致が有る場合か、又は属性定義情報間で項目数が異なる場合には、項目数の多い属性定義情報間で定義が一致し、項目数の少ない属性定義情報ではその項目について定義をしていない場合である。」

という記載は日本語として整理されておらず理解不能である。

また、上記意見書において、
「ある原始プログラム2において、付加属性の一部分(以下の例では、分割方法)を省略した場合、
PARTITION P1=(プロセッサ数=2、分割範囲=1:1000)
属性定義情報の付加属性3には、第31コラムにあるように(定義がないことを示す)nｕll記号を設定しておく。
更に、別の原始プログラム2においても、上記とは異なる付加属性の一部分(以下の例では、分割範囲)を省略した場合、
PARTITIONP2=(プロセッサ数=2、分割方法=均等)
属性定義情報の付加属性2には、やはりnｕll記号が設定される。」
という主張がなされているが、この両者は属性定義情報の定義内容が一致しているわけでもなく、項目数が異なるわけでもないのに、(意見書の主張の意図からすると)成功裏に終わる例示であるようであり、段落0041の説明と首尾一貫しない。

(中略)

(8)段落0043

「以上のように成功した場合には、処理ステップ15で、繰り返し比較処理の最後回まで項目が終わらなかった属性定義情報の一つを選択する。
即ち最も長い項目数の属性定義情報が選ばれ、その属性定義情報の各項目に対応する項目を持つ他の属性定義情報については、すべて対応する項目の定義内容は一致しているので、選択された属性定義情報は、結局全属性定義情報をマージした結果に等しい。」
という記載もまた日本語として整理されておらず、当該事項の意図する技術内容が不可解である。

さらに、審判請求人が上記意見書において主張する、
「(4)・・・他の実施例として「異なる属性定義のマージ」も、以下に示す方法により容易に実現可能です。
ある原始プログラム2において、付加属性の一部分(以下の例では、分割方法)を省略した場合、

PARTITION P1=(プロセッサ数=2、分割範囲=1:1000)

属性定義情報の付加属性3には、第31コラムにあるように(定義がないことを示す)nｕll記号を設定しておく。更に、別の原始プログラム2においても、上記とは異なる付加属性の一部分(以下の例では、分割範囲)を省略した場合、

PARTITION P2=(プロセッサ数=2、分割方法=均等)

属性定義情報の付加属性2には、やはりnｕll記号が設定される。上記二つの属性情報は、共通する付加属性であるプロセッサ数が一致しており、その他の付加属性については属性情報にしか存在しないため、矛盾した定義にならない。」という点について、

P1とP2はどちらも最も長い項目数(2個)の属性定義情報であるが、段落0043の「その属性定義情報の各項目に対応する項目を持つ他の属性定義情報については、すべて対応する項目の定義内容は一致している」という場合に当てはまるわけではないと思われ、段落0043の記載と一貫していない。

また、審判請求人は上記手続補正書において、
「先に説明したように本願請求項1にかかる発明では、属性定義情報に各目的プログム間で矛盾が無いかを判定し、矛盾が無い場合には全ての属性定義情報をマージしたものを有する共通シンボルセクションを、各目的プログラム共通の属性定義情報を有する共通シンボルセクションとして実行形式プログラム生成部に通知しています。したがって、属性定義情報として付加情報がいくつ加えられたとしても、それが各目的プログラムの属性定義情報間で矛盾しない場合(項目の内容の不一致が生じない場合)にはマージすることができ、それをもとに結合処理を行うことができます。」

と主張しているが、そもそも上述の通り、属性定義情報に矛盾が無いという状態がどのような状態か、正しく定義されていない以上、この主張は何ら明細書の記載不備を治癒しない。

さらに、上記手続補正書において、
「実施例においても、図3のフローチャートの処理ステップ12で比較を行って1つの属性定義情報にのみ内容が記載された項目が識別されると、その属性定義情報を全ての目的プログラムの属性定義情報(マージされたもの)とみなして処理を行っています。」
と主張しているが、この主張の根拠もまったく不明である。」


3.審判請求人の主張

上記拒絶理由に対して、審判請求人は平成14年10月31日付けで手続補正をするとともに意見書において以下のように主張している。
「(2)(略)
本件請求項1にかかるコンパイラ装置はこのような構成をとることによって出願明細書の発明の効果の項に記載しているように「本発明によれば、共通シンボルを定義したプログラムを実行形式プログラムにするように結合編集する際において、プログラム間の属性定義の矛盾がチェックされ、矛盾が無い限り、複数の属性定義をマージした結果の、最も定義項目の多い属性定義をしたプログラムのデータが、当該共通シンボルに対応するデータとして選択されるので、共通シンボルに関して、プログラム間の属性定義の矛盾が検出されて適当な処置が可能になると共に、結合編集するプログラムのうちの少なくとも1個のプログラムに完全な属性定義があれば、その属性定義に矛盾した定義にならない範囲で、他のプログラムでは属性定義を省略したり、複数の異なる属性定義とのマージが可能なように定義をすることができる」と言う効果を奏するものである。

(3)本件出願の内容および本意見書の内容の理解を容易にするために、以下に本件出願の請求項1にかかる発明(以下本発明と言う)の趣旨を簡単に説明する。
本発明の目的については段落0015から0016に「従って、結合編集処理に際し共通シンボルを介してデータを同一化する場合に、関連するプログラムのデータ属性定義間について矛盾の無いことをチェックすると共に、各プログラムでデータ属性定義の省略ができることが望まれる。本発明は、共通シンボルについて属性定義の省略を可能にしたコンパイラ装置を目的とする。」と記載している。
この記載から分かるように、本発明は結合する目的プログラムの属性定義に矛盾の無いことをチェックし、また、一部のプログラムの属性定義の省略を行えるようにするというものであり、互いに矛盾した属性定義がなされている目的プログラムを正しく結合することができるようにするというものではない。

したがって、平成14年8月28日(起案日)付け拒絶理由通知書の第4ページから第6ページに例示されている分割コンパイルの例のように矛盾することが明らかな目的プログラムを結合することはできないし、そのために属性定義情報を生成することもしない。

本発明は、段落0011に「結合対象のすべての目的プログラムで、同一のデータ属性定義がされている場合には問題がないが、誤って互いに矛盾した属性が定義されていた場合に、不都合な処理結果となる恐れがある」とあるように、もともと結合対象となる目的プログラムにおいて誤って互いに矛盾したデータ属性定義がなされた場合に対処するものである。

また、段落0013から0014に「たとえば、メインプログラムでは使用されるがサブプログラムでは使用されないデータ属性については、プログラミングの容易さの観点からサブプログラムでは意識しない(従って定義しない)でよいようにしたい。或いは、サブプログラムでは、サブプログラム単位で目的プログラム生成処理を可能にするために必要な基本的なデータ属性のみを定義し、メインプログラムで、より詳細な属性を定義することができれば、1個のサブプログラムを種々の異なるデータ属性の詳細定義をするプログラムに共通に使用できるので、サブプログラムを汎用的な部品として作成できるようになる。」とあるように、本発明は本来結合するためには同一の属性定義が必要な複数の目的プログラムに関して一部のプログラムの属性定義の省略を行えるようにするものである。

(4)平成14年8月28日(起案日)付け拒絶理由通知書において、明細書中の特定段落の記載やその中の文章を取り上げて記載不明瞭であるとの指摘がなされている。しかし、前述した本発明が解決しようとする課題を考慮に入れ、指摘された段落以外の発明の詳細な説明に記載された内容を勘案すれば、指摘された段落の記載内容の一部に適当とは言い切れない表現があるとしても、平成14年8月28日(起案日)付け拒絶理由通知書に述べられているような、この段落の内容が全て「日本語として理解不能」あるいは「不可解」との指摘はあたらないし、適当でない表現が有ったとしても、その表現によって指摘された段落部分の記載内容が全く理解不能になることはないものと思料する。
以下、指摘されている段落ごとに反論及び説明を行う。

・段落0030、0031
ここでは、個々の文章に対して「意味不明」、「理解不能」等の指摘がなされている。

「定義されている属性に従うデータの情報」について
「ローカルデータ名のデータについて定義されている属性に従うデータの情報を共通シンボルセクションに生成する」という全体の表現からすれば、定義されている属性と同等の属性を持つデータの情報を共通シンボルセクションに生成することが理解可能と思料する。この点につき、段落0025の記載も参照されたい。

「図2の形式で属性定義情報を設定する」について
図2(a)は本発明の共通シンボルセクションを持つ目的プログラムの概念的な構成を示す(段落0023)。共通シンボルセクションに設定される属性定義情報が図2(b)に記載されている(段落0026)。オブジェクト生成部の属性定義情報の設定方法は段落0031に記載されている。属性定義情報の構成については段落0027に記載されている。

「有効情報を設定した最後の項目までの長さの情報として生成し」について 属性情報は複数の項目を持っており(段落0027)、内容が設定された最後の項目までを、その(目的プログラムの)属性情報の長さの情報として生成する(他の目的プログラムの属性情報と項目ごとに比較するときに必要となる。段落0040、0043を参照されたい。)。

「途中に該当する定義のない項目があれば、それらの項目には例えば所定のnull記号を設定しておく」について
属性情報の中に内容が設定されていない項目があったとしても、それが最後で無いなら内容としてnull記号を設定することで項目の順番がずれることを防いでいる。同じ属性定義は同じ順番の項目に設定するためである。なお、属性情報同士を比較するときに先頭の項目から順次処理することは段落0037に記載している。

(中略)
・段落0037
複数の目的プログラムのデータ定義情報にはそれぞれ図2(b)に示すような属性情報がある。各項目に対して基本属性1、基本属性2などの属性定義が順次対応する(段落0027参照)。目的プログラムによって有効情報を設定した項目数が異なる(前述したように省略するケースがあるからである)。したがって、同じ項目がある場合と無い場合があり、同じ項目がある場合にその定義内容が同一かを比較することを述べているだけである。
なお、図3の処理ステップ11の「全ての属性定義情報」とは結合しようとする全ての目的プログラムの属性定義情報であり、1項目ずつ比較処理してそれぞれの目的プログラムの属性定義情報間に同じ項目があるかをチェックしており、一貫性は保たれている。

(中略)

・段落0039-0040
前半部では、同じ項目を持つ複数の目的プログラム間で属性定義情報のいずれかの項目に関して内容に一致しないものがあると矛盾が生じることになるが、矛盾が生じない間は順次次の項目に移りながら、項目とその内容を目的プログラム間で繰り返し比較することを述べている。
後半部では、1つの目的プログラムの属性定義情報のみに比較処理対象の項目がある場合、または、全ての属性定義情報の項目の比較が終わった場合には、矛盾なく比較処理が行えたことを述べている。

・段落0041
矛盾なく比較処理が行えたことが、全ての目的プログラムの属性定義情報の項目とその内容の一致を意味することを述べている。または、複数の目的プログラムの属性定義情報の項目数が異なる場合には、矛盾なく比較処理が行えたことが、同じ項目がある場合にはその内容が一致し、項目数の多い属性定義情報に有って項目数の少ない属性義情報に無い項目については、項目数の少ない属性定義情報ではその項目に関して定義がなされていないことを述べている。

・段落0042
「各プログラム毎のデータ属性定義」とは各目的プログラム毎で異なるまたは一致するデータ属性定義のことであり、属性定義情報の各項目に対応させて設定された属性定義のことである(段落0027参照)。なお、オブジェクト生成部がチェックしているのは、原始プログラムから目的プログラムを生成するときにデータの属性定義が正しくなされているかである。

・段落0043
各目的プログラムの属性定義情報を項目ごとに比較して行き、最終的に残ったものが「繰り返し比較処理の最後回まで項目が終わらなかった属性定義情報」となる。したがって、最終的に残ったものは項目数が最も多いものであるとともに、比較された項目の内容は他の目的プログラムの属性定義情報と矛盾が生じていない(生じればステップ13の判断でステップ17にすすんでエラー処理となる)。すなわち、この最終的に残ったものが、他の属性定義情報の内容を全て含んだもの(マージしたもの)となる。

(5)以上の段落0037から0043のフローの説明で分かるように、本実施例には、結合すべき複数の目的プログラム間で属性定義情報を先頭の項目から順番に内容を比較して行き、内容に矛盾がある場合にはエラー処理を行い、矛盾がない場合には最終的に残った(項目数が最も多い)属性定義情報を前記結合すべき複数の目的プログラムの属性定義情報として取り扱うことが記載されている。」

また、審判請求人は平成15年2月4日付け上申書において以下のように主張している。
「(1)平成14年8月28日付け拒絶理由通知について
本拒絶理由通知に関して拒絶の理由(拒絶理由の根拠)であろうと本件審判請求人が判断したのは以下の3点である。
(一)請求項1の「定義情報に矛盾がない」が定義されておらず不明である。
(二)平成14年1月24日付け意見書の具体例には技術的矛盾がある。
(三)段落0030以降の実施例の記載は理解できない。

(2)平成14年10月31日付け意見書(本意見書という)について
平成14年8月28日付け拒絶理由通知は本件請求項1にかかる発明を誤解してなされているように見受けられた。特に上記(二)の拒絶の理由である平成14年1月24日付け意見書の具体例に対する矛盾の指摘は、本件請求項1にかかる発明を理解していればあり得ないものと思われる。したがって、第一にこのような誤解を解消するために、本意見書では発明の目的や趣旨を先に説明した。
なお、上記(二)の拒絶の理由に関連して、前記拒絶理由通知書の第10ページ第31行-第11ページ第2行には、意見書は拒絶理由に承服できない理由を示すものであるが明細書の不備を補うことはできない旨の記載がなされている。したがって、平成14年1月24日付け意見書の具体例に対して拒絶理由通知書の中で指摘された点に反論したとしても、前記意見書の不備に対する反論にはなるかもしれないが、明細書の不備に対する反論にはならないと思われるため、この点については本意見書中では反論を行っていない。

また、上記(一)の拒絶の理由に関連して、拒絶理由通知書第2ページ第10行-第11行には「属性定義の検出に関連すると思われる段落0040-0043の記載は日本語として理解し難く、不明であると言わざるを得ない」と記載されている。したがって、日本語として理解し難く不明とされている実施例の部分(上記(三)の拒絶の理由に相当)に関して反論、説明することが、(一)の拒絶の理由対する反論に通じるものと思われる。このため、本意見書中では(三)の拒絶の理由に対する反論を主として行った。

たしかに、明細書の段落0030以降の記載は日本語として理解容易とは言えないかもしれないが、発明の目的や趣旨を考慮して明細書を読めば理解不能とまでは言えないものと理解している。この点につき、本意見書中では発明の目的や趣旨を説明したあと、実施例の各段落ごとに説明を行うことで明確化につとめたつもりである。

なお、前記したように本意見書では主として(三)の拒絶の理由に対する反論を行っており、これが(一)の拒絶の理由に対する反論も含むものと考えているが、本意見書の内容をより明確にするために(一)の拒絶の理由に関連する点につき補足説明をしたほうが良いと思われるので以下に説明する。

「属性定義」の内容については出願明細書の段落0028に記載されている。ここには、基本属性はたとえば実数、整数等のデータ型、配列か単純変数か、配列の構成と大きさなどであり、付加属性は任意に定義する属性であって図4(a)の「PARTITION」が一例であることが明記されている。したがって、この記載とデータ型、配列等の属性定義の内容を説明している段落0007および「PARTITION」の内容を説明している段落0008の記載を合わせて考慮すれば、「データ型(実数)」、「配列か単純変数か(配列)」、「配列の構成(一次元)」、「配列の大きさ(1000)」、「プロセッサ数(2)」、「分割範囲(1:1000)」、「分割方法(均等)」を属性定義情報の各項目(属性定義)と属性定義の定義内容の具体例として理解することは十分可能であるものと思料する。

つぎに「内容の矛盾」についてであるが、この内容の矛盾の判断については段落0037から段落0038にかけて記載がある。すなわち、複数の目的プログラム間でそれぞれの属性定義情報を先頭の項目から順次比較していき(図3のフローのステップ11)、複数の属性定義情報間で同じ項目があるか(たとえばデータ型が定義されているか)を判断し(図3のフローのステップ12)、同じ項目がある場合には同じ項目を持つ全ての属性定義情報間で内容が同一か(たとえば実数型か)を判断する(図3のフローのステップ13)ことが開示されている。
したがって、内容の矛盾とは、属性定義情報の特定の定義項目(たとえばデータ型)の定義内容(たとえば実数)が同一で無いことを意味することが理解できるものと思料する。

なお、段落0027に記載されているように属性定義情報の項目の位置は特定の属性定義に対応させているから、先頭の項目(基本属性1)がデータ型、2番目の項目(基本属性2)が配列か単純変数か、3番目の項目(基本属性3)が配列の構成等のように項目の順番ごとに属性定義があらかじめ決められている。したがって、順番に項目を比較するときに複数の属性定義情報間で異なる属性定義を比較することはあり得ない。

以上説明したように、本件出願明細書には属性定義やその内容、属性定義の矛盾に関する説明がなされ、具体的に開示されているものと思料する。」


4.当審の判断

そこで、上記「2.平成14年8月28日付拒絶理由」に関して、

属性定義情報の一部にnｕllが設定されたり、長さの異なる属性定義情報を持つことを許す目的プログラムを結合する場合に、「属性定義情報の対応する項目間の定義情報に矛盾がないこと」の技術内容が不明な点

について検討する。

すなわち、

「「属性定義情報の対応する項目間の定義情報に矛盾がない場合」について、ある共通シンボルを共有する複数の目的プログラム中に含まれる属性定義情報を比較して、どのような結果が得られた場合、「属性定義情報の対応する項目間の定義情報に矛盾がない」と判断されるのか、定義情報の矛盾についての定義がない、ないし不明である」という点に関連して、上記拒絶理由の(1)(6)(8)において指摘した点、とりわけ、
・3つ以上のオブジェクトを連結する場合など、どのようにして適切にnｕllを設定するのか、
・属性定義情報の一部にnｕllが設定された場合、属性定義情報を比較して、どのような結果が得られた場合に矛盾が生じないと判断するかを説明しているか、
・最も長い項目数を持つ属性定義情報が選択された場合、その属性定義情報の各項目に対応する項目を持つ他の定義属性情報については、すべて対応する項目の定義内容は一致しているといえるのか、

について検討する。

(ア)平成14年10月31日付け意見書においては、段落0031の記載不備に対して、「「途中に該当する定義のない項目があれば、それらの項目には例えば所定のnull記号を設定しておく」について、属性情報の中に内容が設定されていない項目があったとしても、それが最後で無いなら内容としてnull記号を設定することで項目の順番がずれることを防いでいる。」と釈明するのみであり、例えば(1)のPｒｏ1’,Pｒｏ2’,Pｒｏ3から作られる目的プログラムをリンクしようとする場合、どのようにして属性情報に適切にnｕllを設定するのか、このような事例ではリンクが成功(または失敗)するのかについてすら不明である。
また、段落0030について、「定義されている属性と同等の属性」という、本件明細書にない概念を新たに説明なく持ちだして釈明しようとしているが、そもそも段落0030が日本語として不可解な記載であるのに、さらに明細書中に存在しない概念を新たに説明なく持ち出しても、記載不備であることを解消するものではない。

この点に関して、上記意見書においては
「したがって、平成14年8月28日(起案日)付け拒絶理由通知書の第4ページから第6ページに例示されている分割コンパイルの例のように矛盾することが明らかな目的プログラムを結合することはできないし、そのために属性定義情報を生成することもしない。」とあるものの、上記の事例が矛盾することが明らかな目的プログラムであることを正しく説明するわけでもなく、属性定義情報を生成することもしないとしている。
しかしながら、上記事例は段落0035から0043及び図3の説明からでは矛盾を生じることが明らかな目的プログラムということはできないが、この点についてすら何らの釈明もなされないままである。

(イ)また、上記意見書においては、段落0041の釈明として、「矛盾なく比較処理が行えたことが、全ての目的プログラムの属性定義情報の項目とその内容の一致を意味することを述べている。または、複数の目的プログラムの属性定義情報の項目数が異なる場合には、矛盾なく比較処理が行えたことが、同じ項目がある場合にはその内容が一致し、項目数の多い属性定義情報に有って項目数の少ない属性義情報に無い項目については、項目数の少ない属性定義情報ではその項目に関して定義がなされていないことを述べている。」と説明するものの、やはり上記の点について釈明するものではない。

(ウ)さらに、上記意見書においては、段落0043について、
「各目的プログラムの属性定義情報を項目ごとに比較して行き、最終的に残ったものが「繰り返し比較処理の最後回まで項目が終わらなかった属性定義情報」となる。したがって、最終的に残ったものは項目数が最も多いものであるとともに、比較された項目の内容は他の目的プログラムの属性定義情報と矛盾が生じていない(生じればステップ13の判断でステップ17にすすんでエラー処理となる)。すなわち、この最終的に残ったものが、他の属性定義情報の内容を全て含んだもの(マージしたもの)となる。」と説明しているものの、上記の点について釈明するものではないし、上記拒絶理由の(1)(6)(8)で示した例では、最終的に残ったものが項目数が最も多いものであるわけでもない。

(エ)加えて、上記意見書においては段落0037から0043のフローについて、「本実施例には、結合すべき複数の目的プログラム間で属性定義情報を先頭の項目から順番に内容を比較して行き、内容に矛盾がある場合にはエラー処理を行い、矛盾がない場合には最終的に残った(項目数が最も多い)属性定義情報を前記結合すべき複数の目的プログラムの属性定義情報として取り扱うことが記載されている。」と説明しているものの、上記の点、とりわけ上記拒絶理由の(8)において指摘した点について釈明するものではない。

(オ)また、平成15年2月4日付け上申書においても
「つぎに「内容の矛盾」についてであるが、この内容の矛盾の判断については段落0037から段落0038にかけて記載がある。すなわち、複数の目的プログラム間でそれぞれの属性定義情報を先頭の項目から順次比較していき(図3のフローのステップ11)、複数の属性定義情報間で同じ項目があるか(たとえばデータ型が定義されているか)を判断し(図3のフローのステップ12)、同じ項目がある場合には同じ項目を持つ全ての属性定義情報間で内容が同一か(たとえば実数型か)を判断する(図3のフローのステップ13)ことが開示されている。したがって、内容の矛盾とは、属性定義情報の特定の定義項目(たとえばデータ型)の定義内容(たとえば実数)が同一でないことが理解できるものと思料する。」
「なお、段落0027に記載されているように属性定義情報の項目の位置は特定の属性定義に対応させているから、先頭の項目(基本属性1)がデータ型、2番目の項目(基本属性2)が配列か単純変数か、3番目の項目(基本属性3)が配列の構成等のように項目の順番ごとに属性定義があらかじめ決められている。したがって、順番に項目を比較するときに複数の属性定義情報間で異なる属性定義を比較することはあり得ない。」という釈明をするのみで、上記の点についての釈明ではない。

結局、「「属性定義情報の対応する項目間の定義情報に矛盾がない場合」について、ある共通シンボルを共有する複数の目的プログラム中に含まれる属性定義情報を比較して、どのような結果が得られた場合、「属性定義情報の対応する項目間の定義情報に矛盾がない」と判断されるのか、定義情報の矛盾についての定義がない、ないし不明である」という点に関連して、上記拒絶理由の(1)(6)(8)において指摘した点について、拒絶理由を覆すに足る釈明はなされておらず、依然として不明である。

(なお、審判請求人が平成14年10月31日付け意見書で、
「(4)平成14年8月28日(起案日)付け拒絶理由通知書において、明細書中の特定段落の記載やその中の文章を取り上げて記載不明瞭であるとの指摘がなされている。しかし、前述した本発明が解決しようとする課題を考慮に入れ、指摘された段落以外の発明の詳細な説明に記載された内容を勘案すれば、指摘された段落の記載内容の一部に適当とは言い切れない表現があるとしても、平成14年8月28日(起案日)付け拒絶理由通知書に述べられているような、この段落の内容が全て「日本語として理解不能」あるいは「不可解」との指摘はあたらないし、適当でない表現が有ったとしても、その表現によって指摘された段落部分の記載内容が全く理解不能になることはないものと思料する」
と主張しているが、発明の解決しようとする課題を考慮に入れ、指摘された段落以外の発明の詳細な説明に記載された内容を勘案すると、なぜ上記意見書のような釈明が成り立つのか、具体的かつ合理的な根拠が示されているということはできない。

また、審判請求人は平成15年2月4日付け上申書で、
「平成14年10月31日付け意見書(本意見書という)について 平成14年8月28日付け拒絶理由通知は本件請求項1にかかる発明を誤解してなされているように見受けられた。特に上記(二)の拒絶の理由である平成14年1月24日付け意見書の具体例に対する矛盾の指摘は、本件請求項1にかかる発明を理解していればあり得ないものと思われる。したがって、第一にこのような誤解を解消するために、本意見書では発明の目的や趣旨を先に説明した。」と主張する。
しかしながら、審判請求人は具体的かつ正しく動作する当業者に実施可能な例を出願当初の明細書の記載の範囲内においては示したということはできず、また、平成14年1月24日付の意見書における例も、本件実施例記載の内容が実施可能な程度に矛盾なく開示されていることを論理的に説明していない。
また、審判請求人は平成14年8月28日付拒絶理由における例が本件明細書記載の技術内容において考慮すべき必要がないことを論理的に説明していないと言わざるを得ない。)

5.結び

以上のとおり、本件明細書又は図面の説明は、「属性定義情報の対応する項目間の定義情報に矛盾がない場合」とはどのような場合であるかを正しく説明しておらず、当業者が実施可能な程度に発明の構成を開示したものということはできない。

したがって、本件出願は特許法第36条第4項に規定する要件を満たしていない。

よって、結論のとおり審決する。
 
審理終結日 2003-02-27 
結審通知日 2003-03-04 
審決日 2003-03-17 
出願番号 特願平5-222725
審決分類 P 1 8・ 531- WZ (G06F)
最終処分 不成立  
前審関与審査官 久保 光宏  
特許庁審判長 吉岡 浩
特許庁審判官 大橋 隆夫
川崎 優
発明の名称 コンパイラ装置  
代理人 横山 淳一  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ