【事件の表示】
　平成１０年特許願第　３８３２９号「オブジェクト指向最適化コード生成装置及び方法」拒絶査定不服審判事件〔平成１１年　８月３１日出願公開、特開平１１−２３７９８０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１０年２月２０日の出願であって、平成１５年９月１９日付けで拒絶査定がなされ、これに対し、同年１０月２４日に拒絶査定に対する審判請求がなされるとともに、同年１１月２５日付けで手続補正がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１５年１１月２５日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
「入力されたオブジェクト指向に基づく仕様書データを、記憶装置から読み出された仕様記述文法に基づいて字句解析，文法解析を行い、前記仕様書データから文字列を抽出する仕様解析手段と、
　前記仕様書データからコードを生成するための条件であって、不要な機能が指定された機能排除規則データを記憶装置に記憶する機能選択項目記述部と、
　前記仕様解析手段により得た前記文字列を前記記憶装置から読み出された前記機能排除規則データに従って、オブジェクト指向の機能のうち不要な機能を排除したプログラム情報を生成する機能排除手段と、
　前記機能排除手段により得た前記プログラム情報に基づいてコードを生成するコード生成手段とを有することを特徴とするソフトウエア生成装置。」
　
３．引用例
　原査定の拒絶の理由に引用された、Naya,H.,et al,Object-Oriented Development Based on Polymorphism Patterns and Optimization to Reduce Executable Code Size,Proceedings of 1997 Technoloty of Object-Oriented Languages and Systems(TOOLS 25),米国,IEEE,1997年11月28日,p.68-78（以下、「引用例１」という。）【審決注：原査定では、文献タイトルのto Reduce Executable Code Sizeの部分が欠落しているが、記載されていた情報から文献の特定は十分可能であり、明確な誤記である】には、図面とともに、以下の事項が記載されている。
　
「3: Optimization method for reducing executable code size
3.1: Causes increasing executable code size
　We examine C++ language as a typical object-oriented language. The reasons of increased code size of an object-oriented program are shown below.
・Instantiation
・Inheritance
・Polymorphism
　In the automotive engine control application, above functions are not always needed. Because of that, elimination of mechanisms which put above functions into practice reduce executable code size.
3.2: Elimination of the mechanism for Instantiation
　Instantiation is a function which provides for making entities from the definition of classes. This function needs the memory management mechanism. Most embedded control systems make no entities dynamically, because these systems run on a fixed ROM address area. In this case, instantiation is a redundant function. So, in the system without dynamic entities, we should translate the definition of a class to a static instance. For example, accessors and mutators can be translated as shown in Figure 7. This simple translation lowers the code increase.
3.3: Elimination of the mechanism for Inheritance
　Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship and it is effective for reusability. Realization of inheritance needs mechanisms that manage relations of classes and relations of methods. Table implementation usually puts these relations into practice, but these implementation take a lot of memory. So we delete redundant members from the inheritance hierarchy, and we restrain code increase when picking required data and methods and translating these data and methods into a structure.
　For example, we translate a class hierarchy as in Figure 8
3.4: Elimination of the mechanism for Polymorphism
　Polymorphism is the function for two or more classes to respond to the same request, each in its way. This function needs management mechanisms of class-to-instance relations and class-to-method relations. Usually, table implementation puts these relation management mechanism into practice, but just for inheritance, the implementation use many memory. So, each polymorphism patterns should be translated to static functions.(p.75-76)
（訳）
「３: 実行コード・サイズを減少させるための最適化方法:
３．１：実行コード・サイズ増加の原因
　典型的なオブジェクト指向言語としてＣ＋＋言語について検討する。オブジェクト指向プログラムのコード・サイズ増加の理由は、以下に示される。
・実体化
・継承
・多態性
　自動車のエンジン・コントロールアプリケーションでは、上記の機能は必ずしも必要とは限らない。そのため、実際に上に挙げた機能のための機構を除去することが実行コード・サイズを減少させる。
３．２：実体化の機構の除去
　実体化とはクラス定義から実体生成を行う機能である。この機能はメモリ管理機構を必要とする。多くの組込型制御システムでは、システムが固定ＲＯＭアドレス空間で実行されるため、動的な実体生成は行われない。この場合、実体化は冗長な機能となる。従って、動的な実体のないシステムにおいては、クラス定義を静的な実体に翻訳すべきである。例えば、アクセッサーやミューテーターは図７に示されるように翻訳可能である。このような単純な翻訳はコードの増加を防ぐ。
３．３：継承機構の除去
　継承とは、クラス間の階層的関係に基づいた属性と操作の共有であり、再利用に有効なものである継承の実現にはクラスの関係とメソッドの関係の管理機構を必要とする。これらの関係に対して、テーブルによる実装が通常行われるが、このような実装は多くのメモリを使用する。そこで、継承の階層から冗長なメンバを削除し、必要なデータとメソッドを選択して、これらを翻訳する際のコード増加を抑制する。例えば、クラス階層は、図８のように翻訳される。
３．４：多態性の機構の除去
　多態性は、２以上のクラスがが共通の要求に対してそれぞれの方法で応答するための機能である。この機能はクラスからインスタンスへの関係と、クラスからメソッドへの関係の管理機構を必要とする。通常テーブルによる実装が通常行われるが、継承のためだけに、実装には多くのメモリを使用する。したがって、個々の多態性パターンは静的な機能に翻訳されるべきである。」
　
　また、Figure 7-9にはＣ＋＋のコードを、実体化、継承、多態性の機構を除去してＣのコードに翻訳した例が示されている。
　
　なお、上記の記載における、翻訳の処理を何が行うかについて、引用例１の記載では明確な記述はないものの、コンピュータのようなハードウェア構成とソフトウェアによって自動的に行わせると行ったことは、プログラム生成における常套手段といえる。
　
　これらのことから、引用例１には実質的に、
「Ｃ＋＋のコードから、実体化、継承、多態性といった冗長な機構を排除したＣのコードを生成する構成」
が開示されているものと認める。（以下、これを「引用例１記載の発明」という。）
　
　また、原査定の拒絶の理由に引用された、田倉著，”ＭＳ−Ｃ　Ver.6.0における最適化”，Ｃ　ＭＡＧＡＺＩＮＥ，日本，ソフトバンク株式会社，１９９０年１２月　１日，第２巻、第１２号，p.46-50（以下、「引用例２」という。）には、図面とともに、以下の事項が記載されている。
　
「最適化オプション
　ＭＳ−Ｃ６には多くの最適化オプションがある。そのうち，/Ot，/Os， /Ocが局所的最適化で，/Og，/Oe，/Olが大域的最適化である。
　以前のバージョンでは，ループ最適化と埋め込み関数しかブラグマが使えなかった。ＭＳ−Ｃ６では各種の最適化オプションにプラグマが使えるので，同一ソースフアイル内にあっても関数ごとに最適化オプションが指定できる。
…（中略）…
/Ocは，基本ブロックレベルでの共通部分式の削除を行う。
…（中略）…
　/Ogオプションのほうは，関数内で共通な部分式を探して削除する。
…（中略）…
/oi
　いくつかの関数を，標準ライブラリにあるルーチンを呼び出すのではなく，その関数と同等のコードを生成する。
…（中略）…
　/Oaオプションを指定すると，プログラム上でエイリアスが使われていないとコンパイラは仮定するので，エイリアスの可能性のある箇所も，できるだけレジスタに値を保持するようなコードを生成する。
…（中略）…
/Ol
　ループを最適化する。」（p.46右欄7行目〜p.49中欄37行目）
　
４．対比
　引用例１記載の発明における「Ｃ＋＋のコード」は、技術常識からしてテキストからなるものであるから、本願発明における「文字列」に相当する。
　また、実体化、継承、多態性はオブジェクト指向の機能の一部といえるから、引用例１記載の発明における「実体化、継承、多態性といった冗長な機構」は、本願発明における「オブジェクト指向の機能のうち不要な機能」に相当するといえる。
　そして、引用例１記載の発明における「Ｃのコード」は、「文字列」から「オブジェクト指向の機能のうち不要な機能」を除去して生成されるものであるから、本願発明でいう「プログラム情報」に相当する。
　してみると、引用例１記載の発明における、Ｃのコードを生成する「構成」は、「プログラム情報」を生成するものであるから、本願発明の「機能排除手段」に相当する。
　また、Ｃのコードはソフトウエアであるといえるから、引用例１記載の発明は、全体として本願発明でいう「ソフトウエア生成装置」を構成するといえる。
　
　してみると、本願発明と引用例１記載の発明は、
 文字列から、オブジェクト指向の機能のうち不要な機能を排除したプログラム情報を生成する機能排除手段を有することを特徴とするソフトウエア生成装置。
である点で一致し、以下の点で相違している。
（相違点１）
　本願発明では、「入力されたオブジェクト指向に基づく仕様書データを、記憶装置から読み出された仕様記述文法に基づいて字句解析，文法解析を行い、前記仕様書データから文字列を抽出する仕様解析手段」を備えるのに対し、引用例１記載の発明では、「仕様解析手段」に相当する構成がない点。
（相違点２）
　本願発明では、「仕様書データからコードを生成するための条件であって、不要な機能が指定された機能排除規則データを記憶装置に記憶する機能選択項目記述部」を備え、「機能排除手段」が「記憶装置から読み出された前記機能排除規則データに従って、オブジェクト指向の機能のうち不要な機能を排除する」のに対し、引用例１記載の発明では、不要な機能を指定する手段がなく、「機能排除手段」が排除する不要な機能があらかじめ決まっている点。
（相違点３）
　本願発明では、「機能排除手段により得た前記プログラム情報に基づいてコードを生成するコード生成手段」を備えるのに対し、引用例１記載の発明では、「コード生成手段」に相当する構成がない点。
　
５．当審の判断
（相違点１について）
　オブジェクト関連図、イベントトレース図等の、本願発明でいう「仕様書データ」に相当するデータを解析して、Ｃ＋＋のコードのようなオブジェクト指向プログラムを自動生成（本願発明でいうところの「抽出」に相当）することは、本願出願前において周知技術と認められる。（必要であれば、特開平７−１１０７６２号公報、特開平９−８１３７５号公報参照）
　このような周知技術におけるデータの解析では、オブジェクト関連図、イベントトレース図等の記述ルール（本願発明の「仕様記述文法」に相当）に基づいて、図中の文字列を解析して抽出することは、必然的事項であるといえ、本願発明において、字句解析，文法解析を行って仕様書データから文字列を抽出するとした点が格別のものとは認められない。
　また、コンピュータにおける処理において、必要となるデータを記憶装置に記憶することは常套手段であるから、上述の「仕様記述文法」に相当する記述ルールを記憶装置に格納することも格別のものでない。
　してみると、引用例１記載の発明に該周知技術を組み合わせて、仕様書データを記憶装置から読み出された仕様記述文法に基づいて字句解析，文法解析を行い、前記仕様書データから文字列（Ｃ＋＋のコード）を抽出する構成を付加することは当業者が容易に想到し得たものである。
　よって、相違点１は格別のものでない。
（相違点２について）
　引用例２の記載によれば、最適化オプションの指定によって、最適化の内容を選択することが本願出願前において公知技術である。
　引用例１記載の発明もソフトウエアの最適化に関するものであり、さらに引用例１の開示は、実体化、継承、多態性という３つの機能について、それらが冗長な機能となる場合にその機能を排除するというものであり、そして、これらの機能の排除処理はそれぞれ異なるものであるから、引用例１記載の発明において行われている、冗長な機能の排除という最適化に対して、上記の公知技術を適用して、本願発明の「機能排除規則データ」のように、最適化オプションに従って冗長となる機能、すなわち、不要な機能を排除することは当業者が容易に想到し得たものである。
　そして、コンピュータにおける処理において、必要となるデータを記憶装置に記憶することは常套手段であるから、上記「機能排除規則データ」に相当する最適化オプションを記憶手段に格納することも格別のものでない。
　なお、本願発明では、「機能規則排除データ」に、「仕様書データからコードを生成するための条件であって」との文言が付加されているが、本願発明において、「機能規則排除データ」は、「機能排除手段」において「文字列」から「プログラム情報」を生成する際に用いられているだけであるから、上記文言を付加したことによる実質的な相違はない。
　よって、引用例１記載の発明に引用例２記載の公知技術を適用して、「仕様書データからコードを生成するための条件であって、不要な機能が指定された機能排除規則データを記憶装置に記憶する機能選択項目記述部」を備え、「機能排除手段」が「記憶装置から読み出された前記機能排除規則データに従って、オブジェクト指向の機能のうち不要な機能を排除する」よう構成することは、当業者が容易に想到し得たものである。
　よって、相違点２も格別のものでない。
（相違点３について）
　Ｃ等のプログラム情報を実行形式のコードに変換するコンパイラは、例示するまでもなく本願出願前周知である。
　引用例１記載の発明に該周知のコンパイラを組み合わせて、生成される「プログラム情報」を、コンパイラ（本願発明の「コード生成手段」に相当）によって、本願発明の「コード」に相当する実行形式のコードに変換することは、当業者が容易に想到し得たものと認められる。
　よって、相違点３も格別のものでない。
　
　上記で検討したように、相違点１−３はいずれも格別のものではなく、これらの相違点により格別の効果が生じるものとも認められない。よって、本願補正発明は引用例１，２に記載された発明、および、周知技術に基づいて当業者が容易に想到し得たものである。
　
６．特許法第３６条第４項の拒絶理由について
　原査定では拒絶の理由として、特許法第３６条第４項についても挙げており、その備考欄には次のように記載されている。
「出願人が主張するように、オブジェクト指向に基づく仕様書としては周知のものが存在するが、「機能排除規則」が、本願発明に特徴的な構成である以上、「仕様書」から抽出した「文字列」に対し、どのように図５に記載されたような「機能排除規則」を施して処理するのかまでは技術常識を参酌しても自明とはいえない。
　したがって、発明の詳細な説明及び図面には、「仕様書」がどのように記述され、これをどのように処理してコードを生成するのか依然として不明であるから、請求項１−４に係る発明は、特許法第３６条第４項の規定により特許を受けることができない。」
　そこでこれについて検討する。
　上記拒絶査定の指摘に対して、請求人は審判請求の理由において、「この文字列を抽出する仕様解析手段の処理に関しては、図６及び〔００２９〕〜〔００３１〕に記載され、文法解析結果として文字列を出力することが記載されています。さらにこの文字列から機能排除規則データを用いてプログラム情報を生成する機能排除手段の処理に関しては、図７及び〔００３４〕〜〔００３６〕に記載され、文字列である文法解析結果に基づいて不要な機能を排除した生成パターン情報（プログラム情報）を出力することが記載されています。」と説明する。しかしながら、ここで挙げられる【００２９】段落の説明では、「絵情報として入力されたソフトウエア仕様の情報」が、どのような構造で装置内に保持されているのか不明であり、その結果、該「絵情報として入力されたソフトウエア仕様の情報」に対してlexおよびYaccをどのように使用するのか不明である。そして、例えば【図４】のソフトウエア仕様の情報からの文字列の抽出についても、発明の詳細な説明の記載では、【００３１】段落において四角形４０１に対応する出力が示されている程度にとどまり、このような説明からは、四角形４０２についての出力程度は類推できるとしても、四角形４０３、あるいは、四角形４０１と四角形４０２，４０３との間の接続関係、すなわち、【００２１】段落で説明されている「予め定めた条件を満足するかを判定する」といった内容を示す部分について、どのような処理を行い、どのような「文字列」を出力するのか、さらには、そのようにして出力された「文字列」から、どのようにコードを生成するのかが不明である。
　さらに、請求人は原審における平成１５年８月２８日付け意見書において、「ここで『オブジェクト指向に基づく仕様書』とは、本願図面の図３，図４に記載のソフトウエア仕様の情報に対応します。またこの仕様書は一般にＵＭＬ言語で標準化されており周知の内容であるため、本願明細書及び図面内では単一のクラスのみを記述しましたが、継承，集約の関係を記述する際にネットワーク上に記述することは言うまでもありません。」といった主張を行っているが、ここでいう、ネットワーク上に記述される継承，集約の関係についても、どのような処理を行い、どのような「文字列」を出力するのか、本願明細書の発明の詳細な説明における、一部の要素に対応する出力を示した程度の記載から理解することはできない。そして、そのようにして出力された「文字列」から、どのようにコードを生成するのかも不明である。
　以上のとおりであるから、本願明細書の発明の詳細な説明の記載では、「仕様書」をどのように処理してコードを生成するのかが不明である。
　よって、本願明細書の発明の詳細な説明は、その発明の属する技術の分野における通常の知識を有するものが容易にその実施をすることができる程度に、請求項１〜４に係る発明の構成が記載されておらず、特許法第３６条第４項に規定する要件を満たしていない。
　
７．特許法第３６条第６項２号の拒絶理由について
　原査定では拒絶の理由として、第３６条第６項２号についても挙げており、その備考欄には次のように記載されている。
「請求項１の記載において、仕様書からどのような「文字列」を抽出しているのか、該「文字列」には「機能」がどのように反映されているのか、及び、該「文字列」に対し「機能排除規則」をどのように施して「プログラム情報」を生成するのか依然として不明である。
　したがって、請求項１−４に係る発明は、依然として不明確であるから、特許法第３６条第６項第２号の規定により特許を受けることができない。」
　そこでこれについて検討する。
　上記拒絶査定の指摘に対しても、請求人は審判請求の理由において、上記６．において記載したような主張によって反論している。しかしながら、発明の技術的な範囲は、特別な場合を除き請求項の記載のみから把握されるものであるから、発明の詳細な説明又は図面に記載されていることよって請求項の記載が明確であるという請求人の主張は採用できない。
　また、上記６．で指摘したように、発明の詳細な説明および図面を参酌しても、仕様書に記述される関係をどのように文字列として抽出するのかが不明であるから、請求項１の記載では、仕様書からどのような「文字列」を抽出しているのか、該「文字列」には「機能」がどのように反映されているのかが不明であり、そのような「文字列」に対し「機能排除規則」をどのように施して「プログラム情報」を生成するのかも不明であり、その結果、請求項１に記載される「仕様解析手段」、「機能排除手段」の構成が不明確である。
　よって、本願特許請求の範囲の記載は、請求項１〜４に係る発明について特許法第３６条第６項２項に規定する要件を満たしていない。
　
８．結び
　以上のとおりであるから、本願発明は，引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない。また、本特許出願は特許法第３６条第４項、第３６条第６項第２号に規定する要件を満たしていないので、拒絶すべきものである。
　よって、結論のとおり審決する。