【事件の表示】
　平成　６年特許願第１４９９４９号「ソースコード生成方式」拒絶査定に対する審判事件［平成　８年　１月１９日出願公開、特開平　８−　１６４０２］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯および特許請求の範囲
　
　本件審判請求に係る特許出願は、平成６年６月３０日になされたものであって、平成１４年３月５日付で拒絶査定の謄本が送付され、これに対して同年４月４日に拒絶査定に対する審判請求がなされ、その後、平成１４年１１月５日付で当審による拒絶理由が通知され、平成１４年１２月２７日付で手続補正がなされるとともに、平成１５年１月２０日付で意見書が提出されたものである。
　
　そして、本件出願の請求項１の発明は、明細書の特許請求の範囲に記載されたとおりの次のものである。
　
「データをメモリ上に実行可能形式に展開するメモリ展開手段と、
　このメモリ上に実行可能形式に展開したデータについて、当該データに付与された絶対アドレスをラベル、および当該データのポインタの内容である絶対アドレスを当該ラベルのポインタとして、等価のアセンブラソースを自動生成するアセンブラ生成手段と
を備えたことを特徴とするソースコード生成方式。」
　
２．平成１４年１１月５日付拒絶理由通知書に記載された理由
　
　当審で平成１４年１１月５日付けで発送された拒絶理由通知の概要は以下の通りである。
「本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項並びに第５項及び第６項に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　記
（中略）
　
さて、本件明細書の記載は技術的に不可解な点が多く、本件出願に関する発明の目的・構成・効果を理解することが困難である。以下、詳述する。
　
（１）まず、【発明が解決しようとする課題】として、本件明細書の段落００３５には「データ構造はファイルから読み出してメモリ上に展開するときに展開プログラムが作り出す必要があるという問題がある。また、１つの処理単位（領域を用意→ファイルから読み込み→ポインタの設定）で処理できるのは、連続した一様な構造を持つ領域だけであり、複雑な構造を持つ場合には、逆に時間が多く必要となる場合がある。更に、ポインタ情報が動的に変化する（初期化するときに初めて決まる）ので、ファイル中の静的に記述することが不可能であり（高級言語の静的データの言語的限界に起因）、初期化時に動的に再設定する必要があり」と記載されている。
　
　また、段落００３６には、「また、アセンブラでルールを記述して、（２）の言語的限界や、（１）の問題を解消することも考えられるが、ルールを用いる言語翻訳システムのように、しばしばルールを修正したり、新規に追加したりすることが発生するシステムでは、ルールの修正に応じて初期化時のメモリ状態や構造が変化してしまう」と記載されている。
　
　ところが、段落００４８以降の【実施例】に記載されているのは、連続した一様な構造を持つ場合にすぎず、（段落００７９及び図４の型（１）の場合、すなわちルールのＩＦ部に３個の整数配列、ＴＨＥＮ部に２個の整数配列を持つという場合、の説明しかない）、複雑な構造（例えば平成１４年５月７日付審判請求書手続補正書の図２、図３にあるような型１と型IIが混在するような場合など）を持つ場合については説明されていない。
　
　すなわち、本件明細書は、上記審判請求書手続補正書の「明細書の図３のＳ３３で示す「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」旨を説明していない。
　
（段落００６６には「Ｓ２６は、構造を確認する。これは、例えば後述する図４の（ｂ）に示すデータ構造（型１）に対応する構造を持つか、あるいは他の型２・・・のいずれを持つか確認する。」、段落００７０には「Ｓ３３は、構造を確認する。これは、例えば後述する図４の（ｄ）に示す、メモリ上に展開済ルール（展開済データ３に対応する）の型がいずれの構造（例えば型１）に対応するか確認する（Ｓ２６で既に確認済で記憶しているので、これを取り出して構造を確認する）。」とあるものの、型１に対応する構造を持たなかった場合の説明は出願当初の明細書に存在しない。
　
　なお、そもそも上記審判請求書手続補正書の「明細書の図３のＳ３３で示す「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」という説明は、「適切にプログラミングすれば本件発明が実施可能となる」と説明しているようなものであって、およそ「当業者が実施可能な程度に発明を開示した」ことにならない。
　
上記審判請求書手続補正書の図３では、ルールの構造が型IIである場合についての説明を試みているが、（メモリに展開済ルールの例）という部分のメモリＭＡＰの図は本件出願の出願当初の明細書の内容からどのように導くことができるのか、理解不能である。
　
　例えば、ＩＦ部に１２バイトを使用し、うち最後の４バイトについては”０”（スペース）で埋めることや、データ型は（型II)としながら、int aaa[3]やint bbb[2]という説明が一部に残っている点について、出願当初の明細書の記載からどのように導くのか理解不能である。）
　
　また、本件明細書には、ポインタ情報が動的に変化する場合とはどのような場合であるのか、その場合にどのように処理するのかについても説明されていない（仮に審判請求人は説明されていると考えているとしても、それがどの部分なのか、明細書の記載からでは全く理解不能である）。
　
　加えて、ルールを修正したり、新規に追加している場合については実施例中には全く説明されていない。
　
（２）段落００６２以降に記載される「本発明の構成の動作」の具体的な説明について、技術的に不可解な点があり、本発明の構成の動作を把握できない。
　
（２−１）まず、段落００６５には「Ｓ２５はルールのチェックを行う。これは、Ｓ２４で構文解析を行った後、ルールのデータ構造（型）などの公知のチェックを行う。」と記載されているが、仮にルールのチェック自体が公知のチェックであったとしても、そもそも出願人が説明しようと試みているルールのデータ構造（型）のチェックとは何か不明である。
　
（２−２）続いて、段落００６８には「Ｓ３０はポインタの接続を行う。これは、Ｓ２９で領域に情報を格納してその絶対アドレスが決まったので、ポインタの接続を行い、実行可能形式にする」と記載されているが、一体どのような事項を説明したいのか不明である。
　
　仮に、データ構造の例として図４の（ｂ）に説明されている型１についての説明であって、このルールへのポインタint *ruleにルールint aaaへのポインタを入れるということを説明したいのであれば、これは実行可能形式にすることとは関連性がない。
　
　また、その他の事項について説明したいのであるとしても、それは明細書の記載からでは理解できない。
　
（２−３）さて、（１）においても説明したが、段落００６６には「Ｓ２６は、構造を確認する。これは、例えば後述する図４の（ｂ）に示すデータ構造（型１）に対応する構造を持つか、あるいは他の型２・・・のいずれを持つか確認する。」、段落００７０には「Ｓ３３は、構造を確認する。これは、例えば後述する図４の（ｄ）に示す、メモリ上に展開済ルール（展開済データ３に対応する）の型がいずれの構造（例えば型１）に対応するか確認する（Ｓ２６で既に確認済で記憶しているので、これを取り出して構造を確認する）。」とあるものの、型１に対応する構造を持たなかった場合にどのような処理を行うかについての説明は出願当初の明細書に存在しない。
　
（２−４）段落００７１に「Ｓ３４は、領域を確認する」という説明があるが、領域を確認するとはどのようなことか、領域を確認してその結果を元にどのような処理をするのか不明である（Ｓ３５はＳ３４の結果を元にした処理ではない）。
　
（２−５）段落００７２に「Ｓ３６は、領域先頭のアドレスからラベルを生成する。これは、例えば後述する図５の（ｅ）に示すように、領域の先頭アドレスを生成する。即ち、（ｃ）の先頭アドレスｐからラベルを作る（ここでは、ラベル：Ｌ１２３４５６７２を作る）」と記載されているが、領域の先頭アドレス（すなわち、ルールへのポインタが保持される絶対アドレス）ｐはどのようにして得られるのか、（明細書にはルールへのポインタがどのようにして得られるかが説明されているにすぎず、）明細書には何の説明もない。
　
（２−６）段落００８６「２回目のループ処理：・（ｅ）、（ｆ）は第１回目と同様の処理になる」とあるが、Ｓ３３の「構造を確認」、Ｓ３４の「領域を確認」、Ｓ３６の「領域先頭のアドレスからラベルを生成」、Ｓ３７の「ラベルを出力する」という記載について、（２−３），（２−４）とも関連するが、そもそも「構造を確認」するとか「領域を確認」するという処理は一体何をしているのか不明である。この説明が正しくなされていない以上、Ｓ３６における「領域先頭」とはルールのＩＦ文ないしＴＨＥＮ文に記憶されるべき何らかの情報の先頭なのか、ルールのポインタの先頭アドレスなのか、本来混在すべき説明ではないにも関わらず、混在して説明されているため、日本語として不明である。
　
（３）段落００４８以降の実施例を見ても、本件明細書にはＩＦ文およびＴＨＥＮ文からなるルールをたがたが１つ読み込んでそれを展開したにすぎない実施例しか存在せず、審判請求人は本件明細書において複数個ないし複数の型のルールを読み込んで展開することが当業者が実施可能な程度に説明されていることを示すことに成功していない。
　
　そして、たかたがルール１つを読み込んで展開する処理を、ルールと等価なアセンブラソースに変換してアセンブル・リンクしてロードモジュールを構成するぐらいで一体どのような効果があるのか、少なくとも段落００９１にいう「初期化時にローディングによって迅速に利用可能にする、処理速度を向上させる」などという効果はほとんどないし、「従来の高級言語ベースのときに生じたメモリ冗長域を無くしてメモリ資源の有効利用を図る」「保存するディスク装置の容量を削減する」という効果は全くない。
」
　
３．審判請求人の主張
　
　上記拒絶理由通知に対して、審判請求人は平成１５年１月２０日付け意見書において以下のように主張している。
　
　〔４〕理由（１）について：『「構造の確認を適切に行うようにプログラミングすることで、いかなる構造を持つ情報にも適用することができる」旨を説明していない』というご指摘に関しては次の通り考えます。
　明細書（図面）の図７は、【０００５】−【００１５】で【従来の技術（１）】として解説している通り、ルールを初期化時に動的にメモリ上に展開し、処理を実行し、終了時にメモリから動的に開放する従来の技術を示しています。ここで、図７のＳ１６では、【０００９】で『Ｓ１６は、ルールの構造を確認する』と解説している通り、読み込んだルールについて、Ｓ１７以降でメモリ上に領域を獲得してルールをメモリ上に展開するために必要となるルールのデータ構造を確認する処理を示しています。この「ルールの構造を確認する」処理は、動的に領域を獲得して初期化を行うソフトウェアシステムにおいて、必須の処理であり、ルールの構造やメモリ上における情報の構造に合わせる形で、ルールの構造確認の具体的な方式及び手順は一般的にそれぞれのソフトウェアシステム毎に固有になりますが、対象ソフトウェアシステムの開発者が明確かつ詳細に認識してプログラミンングを行う性質のものですから、各ソフトウェアシステムの開発者においては『ルールの構造を確認する』という説明で十分に理解できます。
　また、図７のＳ２４は、【００１３】で『Ｓ２４は領域を確認する』と解説している通り、Ｓ２６以降で開放する領域をメモリ上で確認する処理であり、Ｓ１６のメモリ展開時のルール構造確認に対応しており、その方式及び手順はＳ１６を実現したソフトウェアシステムの開発者にとって自明のものです。
　更に、図８及び図９は【００１５】−【００３３】で説明しているように、従来技術の他の手法として、ルール等を予めバイナリファイルとして作成しておき、運用時の初期化時間を削減する手法を示していますが、ここで図８のＳ４６はＳ１６と全く同じ処理として『ルールの構造を確認する』を実施しています。また、図９のＳ５４は対象ルールがバイナリ形式であり、バイナリ形式のルールに構造情報が明確に指定されている点を除いてＳ４６と同じ処理として『構造情報を確認』しています。これらの処理も従来から実施されているものですから、当該ソフトウェアシステムの開発者にとって自明のものです。
　一方、明細書の図３は本発明の製品化時の処理フローチャートを示しますが、Ｓ２１−Ｓ３１までの初期化処理は、図７のＳ１１−Ｓ２１と全く同じ処理ですから、図７で示す従来の初期化処理を実現できるソフトウェアシステムの開発者にとって、Ｓ２１−Ｓ３１の具体的方法は自明のものです。従って、初期化処理に含まれるＳ２６も自明であるといえます。
　Ｓ２６に関しては、明細書の【００６６】において「これは、例えば後述する図４の（ｂ）に示すデータ構造（型１）に対応する構造を持つか、あるいは他の型２・・・のいずれを持つか確認する。」と明記されています。即ち、Ｓ２５でルールのチェックをした結果として、該ルールをメモリに展開する場合に、どのようなデータ構造として格納するか（高級言語で言うどの構造体を使用するか）を確認して決定するプロセスです。この判断を誤ると、プログラム（手続き）から情報が正しく参照できなくなるため、重要な判断であり、判断ロジック及び、選択肢としてのデータ構造（構造体やデータ型）はアプリケーションプログラマが慎重かつ明確に認識してプログラミングを行なうものであり、対象プログラムによって個々に定義されるべきものです。
　同様に、Ｓ３３については、【００７０】で『これは、例えば後述する図４の（ｄ）に示す、メモリ上に展開済ルールの型がいずれの構造に対応しているか確認する（Ｓ２６で既に確認済で記憶しているので、これを取り出して構造を確認する）』と明確に説明されています。即ち、Ｓ２６でデータの展開時に展開した情報構造を記憶しておき、その情報から、メモリ上のデータの情報構造は可逆的に明解に判別できるという事です。また、仮にＳ２６でメモリ展開時にその情報構造を記憶しておかなかったとしても、判断ロジック及び構造の選択肢は、Ｓ２６と同様に当該プログラム固有のものであり、アプリケーションプログラマが明確に意識するものですから、アプリケーションプログラマが判断ロジックを適切にプログラミングする事によって、当該アプリケーションが想定する如何なる構造を持つデータであっても、正しい判断が行なわれる事は明白です。Ｓ３３で本発明に必要なものは、データの型及び構造を明確に確認するという結果であって、判断ロジックや判断の候補はアプリケーション固有のもので、当該アプリケーションのプログラマにとっては既知であるので、【００７０】の記述で十分であると考えます。また、先に述べたように、同様の記述は【００１０】でもＳ１６として説明しており、従来の技術として自明な手法を【課題を解決するための手段】で開示する必要はないと考えます。
　更に、この事（判断ロジックや判断の候補はアプリケーション固有のもので、プログラマは既知である）は審判官殿が指摘されている「（未知の部分も有るが）適切にプログラミンングすれば本発明が実施可能になる」という事とは明らかに異なり「自明である既知の判断手法を用いて適切にデータ型及び構造を判断すれば本発明が実施できる」という事です。
　【００６２】で説明しているように、明細書の図４から図６は、図３で示す本特許の製品化時の処理フローを具体的に説明するための実施例です。その中でも、図４は、図３のＳ２１−Ｓ３１で示す初期化処理を実行した例を示しており、図４の（ａ）はＳ２１に対応して記述されたルールの１例を示し、図４の（ｂ）は、Ｓ２６に対応してメモリに展開されるルールデータ構造の１例として（型１）を示し、図４の（ｃ）は、Ｓ３１に対応して初期化完了時のメモリに展開された（型１）の構造を持つルールの１例を示しています。これらの図４の記述は、図５及び図６で示す本特許のソースコード生成方式の本質的な処理（【０００３】に示す動的にメモリ上に展開されたデータ及びデータ構造を、全く等価な静的データ及びデータ構造として実現するプログラムが必須である。この際、動的なメモリ状態から自動生成することが望まれている。」）の実現方法を具体的に説明する為に最小限必要な前提（少なくてもポインタとルールの実体情報を持つ）として、Ｓ３１終了時の１ルールにおけるメモリ展開例、展開されたルール及びルールの構造例を示しているにすぎません。
　
〔５〕理由（２）について：『「本発明の構成の動作」の具体的な説明について、技術的に不可解な点があり、本発明の構成の動作を把握できない』という６件のご指摘に関しては次の通り考えます。
　
〔５−１〕理由（２−１）『ルールのデータ構造（型）のチェックとは何か不明である』というご指摘に関して。
　理由（１）で述べたように、図７のＳ１６、図８のＳ４６及び、図３のＳ２６でルールのメモリ上における構造を確認していますが、【００６５】で説明している「データ構造（型）などの公知のチェックを行う」とは、メモリ上の構造を特定する処理の前段階として、入力されたルールがどのデータ型のものであるかを図７のＳ１５、図８のＳ４５、及び図３のＳ２５で確認するものです。即ち、【００６５】で示すようにＳ２４で構文解析したルールに対して、Ｓ２５ではルールのデータ構造（型）のチェックを行う事によって、ルールがどのデータ型であるかを確認し、その結果としてＳ２６でメモリに展開する場合のデータ構造を確認して決定しており、具体的には図４（ｂ）で示すデータ構造である事を決定しています。その具体的な手段もＳ１６，Ｓ４６，Ｓ２６の「構造の確認」と同様に、Ｓ１５及びＳ４５で従来技術として実施されている自明のものです。
　
〔５-２〕理由（２−２）『段落００６８には、（途中省略）一体どのような事項を説明したいのか不明である。』という「ポインタの接続」に関するご指摘に関して。
　図７のＳ２０及び、図３のＳ３０で「ポインタの接続」を行っていますが、【００１１】で説明しているように「参照関係を付与する」ための処理が「ポインタの接続」です。即ち、図７の従来の技術においては、【００１０】で説明しているように、Ｓ１７で獲得したメモリ上の領域について、Ｓ１８で初期化（メモリの内容を０で埋める）を行い、Ｓ１９でルールの実体情報をメモリに格納しますがこの時点では獲得して実体情報が格納されたメモリ領域が、他から参照されていないため、アプリケーションからも参照する事ができず、利用できません。ここで、アプリケーション（厳密にはアプリケーションから参照可能なメモリ領域）から参照可能なように参照関係を作る処理（アプリケーションから参照可能な領域に、新しく獲得した領域のポインタを格納する処理）が「ポインタの接続」です。
　同様に、図３の本発明においても初期化の最終ステップとしてＳ３０で「ポインタの接続」を行っており、【００６７】で説明しているように、Ｓ２７でメモリ領域を獲得し、Ｓ２８でメモリ領域の初期化（０で埋める）を行い、Ｓ２９でメモリ領域にルール情報を格納しています。この領域に対してＳ３０で「ポインタの接続」を行い、獲得した領域をアプリケーションから参照可能な領域に設定する（参照関係を作る）ことによって、実行可能な状態（アプリケーションから参照可能な状態）にしています。
　具体的には、図４（ｃ）において、ルールへのポインタ（*rule）に対応する領域として0x1234:5672から始まる４バイトを獲得し、ルールの実体に対応する領域として0x1234:5678から始まる１０バイトの領域を獲得したとき、ルールの実体は0x1234:5678から始まる１０バイトの領域に格納されますが、このままではルールへのポインタ（＊rule）はメモリの初期化状態のままで、０が入っているので、ポインタの接続が必要になります。ここでのポインタの接続は、ルールへのポインタ（＊rule）に対応する0x1234:5672から始まる４バイトのメモリ領域に、ルールの先頭アドレスである0x1234:0x5678を代入する処理になります。当然のことながら、0x1234:5672から始まるルールへのポインタ領域もアプリケーションから参照可能な領域から参照できるように、「ポインタの接続」を行う必要がありますが、図４の例ではその後の説明に必要最小限の部分のみを示していますから図４には入っていません。
　一般的には、「ポインタの接続」は、静的な領域としてアプリケーションから参照可能なポインタ型のメモリ領域（仮にｍ０とする）を準備しておき、最初に動的に獲得した領域（仮にｍ１とする）のアドレスをポインタの値としてｍ０に格納し、次に動的に獲得した領域（仮にｍ２とする）のアドレスをポインタの値としてｍ１に格納するという処理を繰り返す事によって、全ての動的に獲得した領域がアプリケーションから参照可能な状態になるようにする処理となります。
　但し、これらの処理も理由（１）で説明した「構造の確認」や理由（２−１）で説明した「ルールのチェック」と同様に、「ポインタの接続」の具体的な方法や対象領域及び処理の結果はアプリケーションプログラム固有の処理として従来から実現されているものであり、当該アプリケーション開発者にとって自明のものです。従って、明細書には【００６８】「実行可能形式にする」【００１１】「参照関係が付与されたこととなる」という処理の効果と、以降の説明に必要最小限の実施例として図４（ｃ）を示しており、アプリケーション開発者は明細書で示している情報から容易に実現可能なものです。
　
〔５−３〕理由（２−３）『型１に対応する構造を持たなかった場合にどのような処理を行うかについての説明は出願当初の明細書に存在しない。』というご指摘に関して。
　理由（１）で詳細に説明したように、本発明における製品化時の処理のなかで、初期化完了までの処理（図３では、Ｓ２１−Ｓ３１）は従来の技術の初期化処理（図７では、Ｓ１１−Ｓ２１）と全く同じ処理であり、アプリケーション開発者にとって自明のものです。
　明細書の具体例としては、（型１）として格納されるルールの場合だけを記述しておりますが、本発明の実施例を具体的に開示するために必要最小限のものとするため、全てのルール型を（型１）で代表して説明しているにすぎません。即ち、いかなる型を持つ情報（ルール）であっても、動的にメモリを獲得して初期化したものは、次のような性質を持つので（型１）で代表することが可能です。
　（１）領域は情報の実体（ルールの実体）を格納する領域と、ポインタを格納する領域に帰着する。
　（２）全ての領域はアプリケーションから参照可能な状態（実行可能な状態）になる。
　（３）全ての領域について、型や内容の解釈は、アプリケーション及びアプリケーション開発者にとって自明である。
言い換えると、（型１）として動的にメモリ領域に展開されたルールを基にして、それと等価の静的なルールを表現するアセンブラソースを自動生成することが出来れば、同様にして他の形式（型）を持つ場合も実現可能です。
　また、前回の意見書では（型２）について具体的に説明していますが、審査官殿からご指摘いただいた疑問点に対して明細書の内容で十分である事を示す回答として明細書に従って説明しているにすぎず、明細書を補完する意図ではありません。
　
〔５−４〕理由（２−４）『段落００７１に「Ｓ３４は、領域を確認する」という説明があるが、領域を確認するとはどういうことなのか、領域を確認してその結果を元にどのような処理をするのか不明である（Ｓ３５はＳ３４の結果を元にした処理ではない）。』というご指摘に関して。
　理由（１）で詳細に説明したように、Ｓ３３の「構造を確認」は、Ｓ２６の「構造を確認」に対応する処理として、次にアセンブラ生成の対象とするメモリ領域の構造を確認して情報が持つ構造（型）を特定する処理です。Ｓ３４ではＳ３３で特定された型に含まれる情報が実際にメモリ領域の何処に存在するかを確認する処理として「領域を確認」処理を行い、次に処理すべきメモリ領域を確定するものです。Ｓ３５はＳ３４で確認した領域としてアセンブラ生成対象とすべき領域が残っていないかを判断してアセンブラ生成の完了の判断をするものですから、Ｓ３５はＳ３４の結果を基にして判断する処理といえます。
　図３のＳ４４で、次の領域にポイントした時、データ構造上、次の領域はどういう構造のどの部分であるべきかを特定するのがＳ３３の「構造を確認」処理であり、Ｓ３４では、Ｓ３３の結果に基づいて、実際にメモリの領域を確認して、特定した有効な領域が存在する事を確認し、アセンブラ生成対象領域として確定します。
　例として、型１を示すべきポインタの値が０ｘ００００：００００であった場合、構造をＳ３３で確認した上で、ポインタの値（０ｘ００００：００００）の意味をＳ３４で解釈し、最終ルールである事をＳ３５で判断する必要があります。
　
〔５−５〕理由（２−５）『段落００７２に（途中省略）、領域の先頭アドレス（すなわち、ルールへのポインタが保持される絶対アドレス）ｐはどのようにして得られるのか、（明細書にはルールのポインタがどのようにして得られるのかが説明されているにすぎず、）明細書には何の説明もない。』というご指摘に関して。
　理由（２-２）の「ポインタの接続」で詳細に説明したように、初期化が完了した状態では全ての領域がアプリケーションから参照可能な状態（実行可能な状態）になっているので、図５における先頭ポインタｐは、静的に確保されているポインタ領域から再帰的にポインタとして参照されるものであり、図３のＳ４２または、Ｓ４４で次のポインタとして渡されるものです。
　
〔５−６〕理由（２−６）『そもそも「構造を確認」するとか「領域を確認」するという処理は何をしているのか不明である。この説明が正しく行われない以上、Ｓ３６における「領域先頭」とはルールのＩＦ文ないしＴＨＥＮ文に記憶されるべき何らかの情報の先頭なのか、ルールのポインタの先頭アドレスなのか、本来混在すべき説明ではないにも関わらず、混在して説明されているため、日本語として不明である。』というご指摘に関して。
　理由（１）及び理由（２−４）で詳細に説明したように、データ構造上、次の対象領域はどういう構造をしているべきかを特定するのがＳ３３の「構造を確認」処理であり、Ｓ３４の「領域を確認」処理では、Ｓ３３の構造確認の結果に基づいて、実際にメモリの領域を確認して、特定した有効な領域が存在するかを確認して次に生成すべき対象領域を確定します。
　図３においては、Ｓ３６−Ｓ４４で処理される情報を最小単位としてＳ３３から始まるループを全ての情報について繰り返しています。
　理由（２-３）の（１）で説明したように動的に獲得して初期化された全ての領域は内容としてポインタを格納するポインタ型の領域と、情報の実体を格納する領域の２種類に帰着しますが、両者の処理で異なるのはＳ４０−Ｓ４３であり、Ｓ３６−Ｓ３８は共通の処理になります。即ちポインタはＳ３６→Ｓ３７→Ｓ３８→Ｓ３９→Ｓ４０→Ｓ４１→Ｓ４２となり、情報の実体領域はＳ３６→Ｓ３７→Ｓ３８→Ｓ３９→Ｓ４３→Ｓ４４となります。
　Ｓ３２から開始される処理は上記の１ループを最小単位として全ての情報について繰り返す事になり、処理すべき有効なメモリ領域の全てが最小単位としてはポインタ型の領域と、情報の実体領域とに帰着するので、両者を同じループ処理で扱う事に矛盾はありません。
　当然の事ながら次に来る領域がポインタ型の領域なのか、情報の実体を格納する領域なのか、情報の実体を格納する領域であった場合のデータ型やデータ長などは全てＳ３３で確認した構造から決定されるものです。
　具体的なデータ構造及び構造確認の手段は理由（１）で説明しているようにアプリケーション固有のもので、当該アプリケーション開発者にとって自明のものです。
　
〔６〕理由（３）について：『審判請求人は本件明細書において複数個ないし複数の型のルールを読み込んで展開することが当業者が実施可能な程度に説明されていることを示すことに成功していない』
　『たかだかルール１つを読み込んで展開する処理を、ルールと等価なアセンブラソースに変換してアセンブル・リンクしてロードモジュールを構成するぐらいで一体どのような効果があるのか、少なくとも段落００９１にいう「初期化時にローディングによって迅速に利用可能にする、処理速度を向上させる」などという効果はほとんどないし、「従来の高級言語ベースの時に生じたメモリ冗長性を無くしてメモリ資源の有効利用を図る」「保存するディスク装置の容量を削減する」という効果は全くない。』
という２件のご指摘に関しては次の通り考えます。
　平成１４年５月７日付審判請求書手続き補正書の図２は明細書（図面）の図４を広範囲に説明するものであり、同手続き補正書の図３は、審査官からのご質問に対して、図２と同じく明細書（図面）の図３のロジックを適用して別の構造体を持つルールについて説明しているものであり、当初明細書（図面）の図４と同じ説明を繰り返しているにすぎないので、明細書を補完するものではありません。
　一般に、アプリケーションプログラムによってメモリ領域を動的に獲得してデータをメモリに展開する初期化処理においては、一度に獲得するメモリ領域内の連続性は保証されていますが、手順は連続でも別々に獲得したメモリ領域は連続しない領域が獲得されます。また、獲得されるメモリ領域のアドレスはシステムによって獲得時に動的に決められるものであって、プログラマが制御することは不可能です。これらは、システム（正確にはアプリケーションプログラムから呼び出されるメモリ管理プログラムで、高級言語ではメモリ管理関数として静的にリンクされる場合が多い）のメモリ管理により決定されるものです。
　実際にＣ言語で記述したサンプルアプリケーションにおけるメモリ獲得の結果を末尾の参考図１に示します。ここで、参考図１（ａ）はＣ言語によるサンプルアプリケーションのソースコードを示し、参考図１（ｂ）は（ａ）のアプリケーションを実行した結果を示し、参考図１（ｃ）は（ａ）のアプリケーションの実行完了直前のメモリ内容を示します。
（中略）
　明細書（図面）の図４では、（ｃ）に展開後のルールを明示していますが、先頭アドレス0x1234:5672はrule領域を獲得するときに決定されます。またruleはポインタ型であり、本例では４バイトの領域を必要としますが、その後ろに冗長領域（例では００００が入っている２バイトの領域）が発生するのは実行システムのメモリ管理の機能によって決められたもので、アプリケーションから制御できるものではありません。
　この事からも、明細書の【００３４】で述べている「メモリを多く消費し」という従来の課題がある事は明白です。
　明細書（図面）の図４ではルールの１つについて記述していますが、機械翻訳システムの様にルール数が数十万にも及ぶ大規模なルールベースのシステムでは、冗長領域の発生による影響も大きなものとなる事は容易に理解できます。
（中略）
　【産業上の利用分野】として【０００３】に『動的にメモリ上に展開されたデータおよびデータ構造を、全く等価な静的データおよびデータ構造として実現するプログラムが必須である。この際、動的なメモリ状態から自動生成することが望まれている。』と明確に述べている通り、本特許は、従来、ルールを読み込んで動的にメモリ上に展開していたデータおよびデータ構造から、それと全く等価な静的データおよびデータ構造として実現するアセンブラプログラムのソースコードを自動生成するために利用され、効果として【発明が解決しようとする課題】として【００３４】で述べている従来方式の課題を解決し、初期化を高速化する、処理を高速化する、メモリ資源を有効利用する、ディスク容量を削減するなどの効果を実現するものです。即ち、本特許を利用した製品は、従来の動的なメモリ初期化による初期化を無くす事で初期化を大幅に高速化し、動的なメモリ獲得による冗長性を無くす事で必要なメモリ領域を大幅に削減し、メモリ領域の削減による処理効率向上によって若干の処理の高速化を実現し、ルールファイルのロードモジュール化によって格納に必要なディスク容量を削減する効果を実現します。
（中略）
　以上で明らかなように、従来の動的なメモリ獲得では獲得したメモリが離散になるため無駄が生じるが、本発明の方式では動的なメモリ獲得と等価なアセンブラの静的情報としてソースコードを自動生成するので、このソースコードをアセンブルしてリンクしたロードモジュールでは、自動的に連続領域が保証されるのは必然的な結果であって、明細書の記述に不足、矛盾や技術的飛躍があるものではないと考えます。
　また、ルールの増減は、単に処理対象となるルールの種類および数が増減するだけであって、理由（１）で明らかにしたように、具体的なルールの形式やメモリ上における構造などは、アプリケーション固有のものであり、本発明の方式に何ら影響を与えるものではないので、ルールを読み込んで動的にメモリを獲得している従来の方式でアプリケーションを開発できるアプリケーション開発者であれば、明細書による開示内容だけで本特許を利用したアプリケーションの開発は容易にできます。
（中略）
　
　〔８〕　したがいまして、以上のごとく誤記・誤用を補正して明確にし、上述した理由（１）から理由（４）でご説明したように、補正後の本願発明（請求項１、および請求項１を引用する請求項２，３）は出願当初の明細書および図面に記載されており、特許法第３６条第４項、第５項及び第６項に規定する要件を満たしますので、原査定を取消して特許査定の決定をお願いします。
　
　〔９〕　以下は、上記説明の参考図１です。
（参考図１）
（略）」
　
４．当審の判断
　
　そこで、上記「２．平成１４年１１月５日付拒絶理由通知書に記載された理由」に関して、
　
・明細書の図３のＳ３３で示す「「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」の技術的な裏付けが不明な点、および「ルールのデータ構造（型）のチェック」とは何か、「構造を確認する処理」や「領域を確認するという処理」の内容およびその実現手段が技術的に不明である点、
　
・「従来の高級言語ベースの時に生じたメモリ冗長性を無くしてメモリ資源の有効利用を図る」、「保存するディスク装置の容量を削減する」という効果を裏付けるための実現手段が技術的に不明である点、
　
について検討する。
　
（４−１）「「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」の技術的な裏付けが不明な点、および「ルールのデータ構造（型）のチェック」とは何か、「構造を確認する処理」や「領域を確認するという処理」の内容およびその実現手段が技術的に不明である点
　
審判請求人の主張の骨子は、「３．審判請求人の主張」の記載から見て、
　
「ソフトウェアシステムの開発者が十分に理解できるものである」
「ソフトウェアシステムの開発者にとって自明なものである」
「アプリケーションプログラマが判断ロジックを適切にプログラミングする事によって、当該アプリケーションが想定する如何なる構造を持つデータであっても、正しい判断が行なわれる事は明白である」。
「本発明に必要なものは、データの型及び構造を明確に確認するという結果であって、判断ロジックや判断の候補はアプリケーション固有のもので、当該アプリケーションのプログラマにとっては既知であるので十分に開示されている」
　
というものである。
　
　ところで、特許法第３６条第４項の規定は、当業者が容易に発明を実施できる程度に発明の構成等を記載することを求めるものである。そして、明細書又は図面に具体的構成が記載されていない場合にその発明を容易に実施できるというためには、本願明細書の目的、構成、効果を含めた全体的記載との関連において、具体的構成が記載されているが如く容易に導き出せるものでなければならない。
　
　そこで、本件明細書の内容を精査しても、「「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」かを具体的に裏付けるような実施例が記載されているということはできない。
　
　また、「アプリケーション固有のものである」ことは具体的実施例を一切開示しなくても自明であることを立証するものではなく、本願明細書の全体的記載との関連において、具体的構成が記載されているが如く容易に導き出せて初めて「アプリケーション固有のものであって自明である」ということがいえるのである。
　
　しかしながら、本件明細書においては、実施例が存在しないにもかかわらず、どのような記載から「ソフトウェア開発者やアプリケーションプログラマにとって自明ないし十分に開示されている」ことが裏付けられるのか、全く不明である。
　
（４−２）「従来の高級言語ベースの時に生じたメモリ冗長性を無くしてメモリ資源の有効利用を図る」、「保存するディスク装置の容量を削減する」という効果を裏付けるための実現手段が技術的に不明である点
　
　審判請求人は、
「一般に、アプリケーションプログラムによってメモリ領域を動的に獲得してデータをメモリに展開する初期化処理においては、一度に獲得するメモリ領域内の連続性は保証されていますが、手順は連続でも別々に獲得したメモリ領域は連続しない領域が獲得される」こと、
「明細書（図面）の図４では、（ｃ）に展開後のルールを明示していますが、先頭アドレス0x1234:5672はrule領域を獲得するときに決定されます。またruleはポインタ型であり、本例では４バイトの領域を必要としますが、その後ろに冗長領域（例では００００が入っている２バイトの領域）が発生するのは実行システムのメモリ管理の機能によって決められ」ることを主張しているが、そもそも上記のような問題の認識も、冗長領域が発生するようなことも、出願当初の明細書に記載されておらず、また出願当初の明細書の記載から導きだせるものではない。
　
　また、審判請求人が「［６］理由（３）について（中略）という２件のご指摘に関しては次の通り考えます。」において述べている事項について、参考図１やその説明は本件特許出願に関する出願当初の明細書及び図面に記載されているものでも、出願当初の明細書及び図面から導き出せるものでもない。
　
　そして、審判請求人が主張する、「明細書の【００３４】で述べている「メモリを多く消費し」という従来の課題」という一般的かつ具体性に欠ける課題が、上記のような「連続したメモリ領域を獲得できないために生じる、いわゆる断片化」のことを指すかどうかは、出願当初の明細書からは全く不明である。
　
　また、「【産業上の利用分野】として【０００３】に『動的にメモリ上に展開されたデータおよびデータ構造を、全く等価な静的データおよびデータ構造として実現するプログラムが必須である。この際、動的なメモリ状態から自動生成することが望まれている。』と明確に述べている通り、」と主張している点も、「本特許は、従来、ルールを読み込んで動的にメモリ上に展開していたデータおよびデータ構造から、それと全く等価な静的データおよびデータ構造として実現するアセンブラプログラムのソースコードを自動生成するために利用され」ると主張している点も、
本件発明の「動的にメモリ上にデータを取得する場合に生じるメモリ断片化を防ぐために静的データとして取得するようなプログラムを生成する」という課題の認識が明細書に記載されているわけでも、明細書に記載されているかの如く当然に導き出せるわけでもない。
　
　そして、本件発明がどのようにして上記の課題を解決したのかについても不明であるといわざるを得ない。
　
５．結び　
　
　以上のとおり、本件明細書又は図面の説明は、
　
　明細書の図３のＳ３３で示す「「構造の確認」を適切に行うようにプログラミングすることで、いかなる構成を持つ情報にも適用することができる」の技術的な裏付けが不明な点、および「ルールのデータ構造（型）のチェック」とは何か、「構造を確認するとか領域を確認するという処理」とはどのような処理であるかを、当業者が本件明細書の全体的記載から実施可能な程度に発明の構成を開示したものということはできない。
　
　また「従来の高級言語ベースの時に生じたメモリ冗長性を無くしてメモリ資源の有効利用を図る」、「保存するディスク装置の容量を削減する」という効果を技術的に裏付ける点について、当業者が出願当初の明細書の全体的記載からその効果を技術的に裏付けるための事項が記載されているかの如く当然に導き出せるものではない。
　
　そして、上記の点が不明であるので、結果として請求項における「データをメモリ上に実行可能形式に展開するメモリ展開手段」の技術的な裏付けが成されていないと言わざるを得ない。
　
　したがって、本件出願は特許法第３６条第４項に規定する要件を満たしていない。　
　
　よって、結論のとおり審決する。