【事件の表示】
　平成　７年特許願第　９４９２０号「リポジトリ装置」拒絶査定に対する審判事件［平成　８年１１月　５日出願公開、特開平　８−２９２８８２］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯　
　本願は、平成７年４月２０日の出願であって、平成１３年６月１１日付で拒絶の理由が通知され、平成１３年８月２０日付で手続補正（以下、手続補正１という。）がなされたものの、平成１３年９月１１日付けで拒絶の査定がなされた。　
　その後、平成１３年１０月２４日に拒絶査定不服審判請求がなされ、同年１１月２６日付で手続補正（以下、手続補正２という。）がなされたものである。　
　
２．手続補正２についての補正却下の決定　
［補正却下の決定の結論］　
　平成１３年１１月２６日付の手続補正を却下する。　
　
［理由１］　
（１）補正後の本願発明　
　上記手続補正２により、特許請求の範囲の請求項１は、
「【請求項１】一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段と、当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、を有するサブモデル管理部と、　
　複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部と、　
　を有する管理部を設けることを特徴とするリポジトリ装置。」と補正された。　
　上記補正は、請求項１に記載した発明を特定するために必要な事項である「一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段」について「一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段」とし、同「前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」について「前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」とし、同「ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置」について、さらに「複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部」を設けたものであるとの限定を付加するものであって、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。　
　そこで、上記手続補正２による補正後の上記請求項１に記載された発明（以下、本願補正発明という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第４項において準用する同法第１２６条第３項の規定に適合するか）について以下に検討する。　
　
（２）引用例　
［引用例］　
　原査定の拒絶の理由に引用された特開平５−３２４２９５号公報（平成５年１２月７日出願公開、以下、引用例という。）には、図面とともに、以下のことが記載されている。　
　
（Ａ）「【０００１】　
【産業上の利用分野】本発明はソフトウエアの開発支援装置に係り、さらに詳しくは、ソフトウエアの設計作業におけるガイダンス、設計ドキュメントや設計部品等の情報管理、チェックを行ない、設計工程を中心とする開発支援および設計作業を自然な流れで進めることを可能とするソフトウエアの開発支援装置に関する。」　
　
（Ｂ）「【００２１】第４に設計ドキュメント管理手段７を有する。設計ドキュメント管理手段７は、前記設計エディタ手段５によって設計した結果として得られる設計ドキュメントやプログラム部品を、前記抽象化レベル規定手段４で規定した抽象化レベルに従った階層ディレクトリをＤＡＳＤ上の設計ドキュメント・ファイル３に自動生成し管理したうえ格納する。・・・　
【００２２】第５に、設計データベース格納手段８を有する。設計データベース格納手段８は、設計ドキュメント・ファイル３に格納する設計部品やプログラム部品のなかで、例えば、レビュー状況が編集完了済みのもののみというように、特定の条件を満たす部品をデータとして登録し、必要に応じて更新する。」（・・・は引用箇所の省略を意味し、以下、同様とする。）　
　
（Ｃ）「【００４０】・・・また、修正が必要な設計ドキュメントについての設計エディタを直接起動し、修正が必要な設計部品やプログラム部品についての図形シンボルを高輝度表示や表示色判定等の方法で判別しやすくする処理を行なう。・・・」　
　
（Ｄ）「【００４４】対話管理制御部１０は、設計者１８とシステムの対話、すなわち、入出力を管理し、制御する部分である。例えば、設計者１８は、対話管理制御部１０を通して設計を開始したい抽象化レベルを指定したり、設計情報の入力を行なったり、設計作業に関する支援の要求を指定する。
【００４５】・・・一方、設計エディタ群１２は、各抽象化レベルの仕様情報ごとに割り付けられた複数の設計エディタからなる。設計者１８は、抽象化レベル規定テーブル群１１によって定義された抽象化レベルを選択し、何をどのように設計したらよいかのガイダンスの提示を受けたうえで、対応する設計エディタを起動することができる。」　
　
（Ｅ）「【００４７】設計ドキュメント管理部１４は、設計エディタ群１２中のいずれかの設計エディタで作成された結果としての設計ドキュメントを設計ドキュメント・ファイル１５に格納し、管理する。・・・　
【００４８】一方、設計データベース１６には、設計エディタ上で定義された設計部品や設計部品間の関連の実体に関するデータを保持する。そして、設計情報矛盾修正支援部１７は、設計データベース上に登録されている設計部品や関連のなかで、抽象化レベル内の複数の設計ドキュメントにまたがって記述されているものに矛盾がないか否かをチェックし、矛盾がある場合には該矛盾に修正を施す支援を行なう。」　
　
（Ｆ）「【０１２０】図２４は、設計ドキュメント管理部（図２の１４）が行なう抽象化レベル毎の設計ドキュメントの管理と、設計ドキュメントの格納の説明図である。設計ドキュメント管理部１４は、設計ドキュメントのディレクトリ階層を作成するディレクトリ階層作成部２５５と、実際に設計ドキュメントをＤＡＳＤ上の設計ドキュメント・ファイル１６に格納する設計ドキュメント格納部２５６からなる。図中の太い矢印は段階的詳細化の流れを示し、破線矢印は制御の流れを示す。　
【０１２１】すなわち、設計者は、抽象化レベル１で設計ドキュメント１を作成し、そのなかの一つの部品を同じ抽象化レベル１の設計ドキュメント２で詳細化している。さらに、設計ドキュメント２で詳細化した部品を下位レベルである抽象化レベル２の設計ドキュメント３でさらに詳細化し、そのなかの一つの部品を更に同じ抽象化レベル２の設計ドキュメント４で詳細化している。　
【０１２２】今、設計者が抽象化レベルに従ってソフトウエアの設計作業を行なう際に、二つの抽象化レベル間にまたがる詳細化を行なう場合（例えば、抽象化レベル１の設計ドキュメント２を抽象化レベル２で詳細化し設計ドキュメント３を作成するような場合）には、設計ドキュメント２の詳細化を実行するときにディレクトリ階層作成部２５５を起動する（Ｓ２５６）。ディレクトリ階層作成部２５５はＤＡＳＤ上に該当する抽象化レベル（抽象化レベル２）に対応したディレクトリがあるか否か確認し、ない場合には抽象化レベルに対応したディレクトリを作成する。すなわち、抽象化レベル２のディレクトリがあるか否かを確認し、ない場合には抽象化レベル２のディレクトリとして設計ドキュメント３を作成する（Ｓ２５７）。」　
　
（Ｇ）「【０１３４】設計データベースの論理構成は階層構造になっていて、その一番上位には抽象化レベル名３１０がある。これには、図４の一実施例の抽象化レベル規定テーブル群の説明図で説明した抽象化レベル・テーブル１１１で規定されている抽象化レベル名が入る。抽象化レベル名３１０の下位には設計部品の種類３１１および関連の種類３１２がある。設計部品の種類３１１には、図４で説明した抽象化レベル設計部品テーブル１１３で規定している設計部品の種類名が、また、関連の種類３１２には、図４で説明した抽象化レベル関連テーブル１１４で規定している関連の種類名が入る。さらに、設計部品の種類３１１の下位に設計部品実体３１３があり、個々の設計部品がもつ種別が入る。さらに、その下位に図４の設計部品属性テーブル１１６で規定されている設計部品のキー属性値３１４と、その他の属性値３１５が入る。さらに、これらと並んで、設計部品が定義されている設計ドキュメント・リスト３１６が入る。一方、関連の種類３１２の下位には関連実体の種別３１７が、さらにその下位には関連の属性値３１８と、その関連が定義されている設計ドキュメント・レベル３１９が入る。　
【０１３５】構成図内の階層を位置づける線分のうち、矢印のない線分は上位に対して下位が複数存在することを意味する。例えば、一つの抽象化レベル内には複数の設計部品と関連が存在し、それぞれが複数の設計部品実体と関連実体をもち、さらに各設計部品や関連の実体は複数の属性値を持つことを意味する。一方、矢印のある線分は上位に対して１個だけ下位が存在することを意味する。例えば、設計部品は設計部品キー属性と設計ドキュメント・リストを１個だけ持つ。設計ドキュメント・リスト３１６および３１９は、各設計部品実体や関連実体が複数の設計ドキュメントに出現する場合に、それらの間の一貫性を保証するための処理に利用される。　
【０１３６】また、設計データベースへの設計部品や関連実体の登録・更新は、図２３の設計ドキュメント格納要求時の動作フローチャートに示したように設計ドキュメントの格納要求に伴って実現される。このとき、設計ドキュメントとして格納される各設計部品や関連実体毎に設計データベース格納フラグによって登録済みか否かが識別できるので、既に設計データベースに登録済みの設計ドキュメント内の設計部品や関連実体に対しては、新規に設計データベースに登録する設計部品や関連実体とは区別した修正処理が施せる。」　
　
（Ｈ）又、上記（Ｃ）及び図１９を勘案すると、設計ドキュメントが個々の設計ドキュメントを図形シンボルで表示するための情報を有していることは明らかである。　
　
（Ｉ）上記（Ｅ）、（Ｇ）及び図３０を勘案すると、設計データベースのデータが個々の設計ドキュメントの設計部品の実体に関するデータと共に、当該設計部品間の関連の実体に関するデータ、当該設計部品が定義されている設計ドキュメント・リストや、階層構造で示された論理的な構造に関する情報を有していることは明らかである。　
　
　上記（Ａ）〜（Ｉ）及び図面を勘案すると、引用例１には、　
　
　個々の設計ドキュメントの論理的な構造に関する情報及び個々の設計ドキュメントを図形シンボルで表示するための情報を入力する対話管理部及びエディタ群と、　
　上記個々の設計ドキュメントの論理的な構造に関する情報を管理する設計データベース格納手段と、　
　上記設計ドキュメントを図形シンボルで表示するための情報を管理する設計ドキュメント管理手段と、　
　上記設計ドキュメント管理手段がさらに複数の設計ドキュメントのディレクトリ階層を格納し管理するものである開発支援装置（以下、引用発明という。）　
　
が開示されていると認められる。　
　
（３）対比　
　そこで、本願補正発明と引用発明を対比すると、引用発明の「設計ドキュメント」、「個々の設計ドキュメントの論理的な構造に関する情報」、「個々の設計ドキュメントを図形シンボルで表示するための情報」、「対話管理部及びエディタ群」、「上記個々の設計ドキュメントの論理的な構造に関する情報を管理する設計データベース格納手段」、「上記設計ドキュメントを図形シンボルで表示するための情報を管理する設計ドキュメント管理手段」は、それぞれ本願補正発明の「ドキュメント」、「論理サブモデル」、「ビュー」、「論理サブモデル取込手段」及び「ビュー取込手段」、「論理サブモデル管理手段」、「ビュー管理手段」に対応する。　
　
　したがって、本願補正発明と引用発明は、　
　
　一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段と、当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、を有するサブモデル管理部と、を有するリポジトリ装置　
　
である点で一致し、以下の点で相違している。　
　
［相違点１］　
　本願補正発明では、複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有しているのに対して、　
　引用発明では、上記設計ドキュメント管理手段がさらに複数の設計ドキュメントのディレクトリ階層を格納し管理するものである点。　
　
［相違点２］　
　本願補正発明では、論理サブモデル取込手段、論理サブモデル管理手段、ビュー取込手段と、ビュー管理手段、をまとめてサブモデル管理部とし、上記サブモデル管理部と論理モデル管理部をまとめて管理部としているのに対して、引用発明がそのようなものでない点。　
　
（４）相違点についての判断　
［相違点１について］　
　例えば、本願出願前に頒布された刊行物である特開昭６２−２１４４３８号公報（昭和６２年９月１２日出願公開、以下、周知例という。）には、　
「２．特許請求の範囲　
１．ソフトウェア仕様書を構成する種々の仕様ドキュメントと、・・・その関連情報とを計算機に蓄積し、蓄積された仕様ドキュメントの変更手段と他の仕様ドキュメント内の関連して変更すべき個所を検出する手段・・・、新しいソフトウェア仕様書に含むべき仕様ドキュメントと、その構成を示す仕様書構成情報を利用する手段を設けることにより、個々の仕様ドキュメントの変更に伴い、追加、削除すべき仕様ドキュメントの検出をも可能としたことを特徴とするソフトウェア仕様書再利用方式。」（公報１頁左下欄４行〜１９行）、　
「前記ファイルメモリ５に蓄積されている仕様関連情報は、対象ソフトウェアシステム全体に含まれる仕様情報とその関連、およびそれらを含む仕様ドキュメントとの関連の情報を保持するものであり、個々のドキュメント修正により、変形が影響する他のドキュメントの検出に使用する。　
　ファイルメモリ７に蓄積されている仕様書構成情報が本発明の特徴とするところであり、その内容は、例えば、システムフロー図にファイル名称が記載されている場合には対応するファイル仕様がなければならないことを示す情報等の、仕様書を構成する仕様ドキュメント間の存在依存関係を示す情報である。」（公報３頁右下欄９行〜４頁左上欄１行）と記載されており、これらの記載を勘案すると、周知例には、複数の仕様ドキュメントの間の存在依存関係を示す情報を蓄積して管理すること、すなわち、複数のドキュメントの間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報を蓄積し管理することが開示されており、上記の構成は本願出願前周知の技術であると認められる。　
　してみれば、引用発明において、周知例に記載されているような上記の周知の技術を参酌して、複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有するようにすることは、当業者が容易になし得るものである。　
　
［相違点２について］　
　本願補正発明では、論理サブモデル取込手段、論理サブモデル管理手段、ビュー取込手段と、ビュー管理手段、をまとめてサブモデル管理部とし、上記サブモデル管理部と論理モデル管理部をまとめて管理部としているのに対して、引用発明がそのようなものでないが、管理のための複数の手段をまとめて１つの管理部として構成することは本願出願前周知の技術であって、当業者が設計時に適宜選択し得る設計的事項であるから、この点については格別の差異ではない。　
　
　したがって、本願補正発明は、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。　
　
（５）むすび　
　以上のとおり、上記手続補正２による上記の補正は、特許法第１７条の２第４項で準用する同第１２６条第３項の規定に違反するものであり、同第１５９条第１項で準用する同第５３条第１項の規定により却下されるべきものである。　
　
［理由２］　
（６）請求項５に係る補正　
　上記手続補正２は、特許請求の範囲の請求項５について　
「【請求項５】前記管理部は、ドキュメントが保存される際に、論理モデルへ保存することなく、論理サブモデルへ保存及びビューへ保存する手段を有する請求項１〜３いずれか１項に記載のリポジトリ装置。」を、　
「【請求項５】前記論理モデル管理部は、前記検出手段により、前記影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する中止手段を有し、　
　前記サブモデル管理部は、前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する手段を有する請求項４記載のリポジトリ装置。」と補正し、それと共に、第００１５段落について、　
「【００１５】　
　請求項５に記載の発明は、前記管理部は、ドキュメントが保存される際に、論理モデルへ保存することなく、論理サブモデルへ保存及びビューへ保存する手段を有する請求項１〜３いずれか１項に記載のリポジトリ装置である。」を　
「【００１５】　
　請求項５に記載の発明は、前記論理モデル管理部は、前記検出手段により、前記影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する中止手段を有し、前記サブモデル管理部は、前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する手段を有する請求項４記載のリポジトリ装置である。」と補正している。　　
　
（７）補正についての判断　
　本願の願書に最初に添付した明細書又は図面には、論理モデルの保存に関して、　
「【請求項５】前記管理部は、ドキュメントが保存される際に、論理モデルへの保存をすることなく、論理サブモデルへの保存及びビューへの保存を行う手段を有する請求項１〜３いずれか１項に記載のリポジトリ装置。」、　
「【請求項６】前記管理部は、ドキュメントが保存される際に、論理モデルへの保存及び論理サブモデルへの保存をすることなく、ビューへの保存を行う手段を有する請求項１〜３いずれか１項に記載のリポジトリ装置。」、　
「【００１０】　
　ところで、ドキュメント自体に誤りがあるのに保存が行なわれると、その誤りによってリポジトリ装置の内部に保存される論理モデルが壊れてしまう。・・・」、　
「【００１５】　
　また、請求項５の発明は、ドキュメントが保存される際に、論理モデルへの保存をすることなく、論理サブモデルへの保存及びビューへの保存を行う手段を有する管理部を設けたリポジトリ装置であり、請求項６の発明は、ドキュメントが保存される際に、論理モデルへの保存及び論理サブモデルへの保存をすることなく、ビューへの保存を行う手段を有する管理部を設けたリポジトリ装置である。」、　
「【００１９】　
　請求項５及び６の発明によるリポジトリ装置では、論理モデルを変更せずに、ドキュメントの保存が可能となる。ドキュメント作業を中断する時、そのドキュメントによって論理モデルが更新されないことを希望する場合などに有用である。特に請求項６の発明によるリポジトリ装置では、誤りの存在によってドキュメント・チェックにパスしないようなドキュメントをリポジトリ装置へ保存することが許容される。エディタを再起動すると、作業中断で保存されたドキュメントが、前回の状態のまま画面に再現される。」　
と記載されているだけであって、「中止手段」という構成、「前記検出手段により、影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する」という構成、及び「前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する」という構成は、本願の願書に最初に添付した明細書又は図面には記載されていない。　
　したがって、上記手続補正２の請求項５及び第００１５段落に係る補正は、本願の願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものとは認められない。　
　
（８）むすび　
　以上のとおり、上記手続補正２による上記の補正は、特許法第１７条の２第２項で準用する同第１７条第２項の規定に違反するものであり、同第１５９条第１項で準用する同第５３条第１項の規定により却下されるべきものである。　
　
３．本願発明について　
　上記手続補正２は、上記のとおり却下されたので、本願の請求項１に係る発明（以下、本願発明という。）は、上記手続補正１により補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。　
「【請求項１】ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置であって、　
　一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段と、　
　当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、　
　前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、　
　当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、　
　を有する管理部を設けることを特徴とするリポジトリ装置。」　
　
（１）引用例　
　原査定の拒絶の理由に引用された引用例、及び、その記載事項は、上記「２．（２）」に記載したとおりである。　
　
（２）対比・判断　
　本願発明は、上記「２．」で検討した本願補正発明から「一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段」を「一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段」とし、同「前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」を「前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」とし、同「ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置」について、さらに「複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部」を設けたとの限定事項である「論理モデル管理部」との構成を省いたものである。　
　そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、上記「２．［理由］（４）」に記載したとおり、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものである。　
　
（３）むすび　
　以上のとおり、本願発明は、引用例に記載された発明及び周知の技術に基き、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。　
　
　よって、結論のとおり審決する。