ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1086187 |
| 審判番号 | 不服2001-19006 |
| 総通号数 | 48 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 1996-11-05 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2001-10-24 |
| 確定日 | 2003-10-31 |
| 事件の表示 | 平成 7年特許願第 94920号「リポジトリ装置」拒絶査定に対する審判事件[平成 8年11月 5日出願公開、特開平 8-292882]について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、平成7年4月20日の出願であって、平成13年6月11日付で拒絶の理由が通知され、平成13年8月20日付で手続補正(以下、手続補正1という。)がなされたものの、平成13年9月11日付けで拒絶の査定がなされた。 その後、平成13年10月24日に拒絶査定不服審判請求がなされ、同年11月26日付で手続補正(以下、手続補正2という。)がなされたものである。 2.手続補正2についての補正却下の決定 [補正却下の決定の結論] 平成13年11月26日付の手続補正を却下する。 [理由1] (1)補正後の本願発明 上記手続補正2により、特許請求の範囲の請求項1は、 「【請求項1】一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段と、当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、を有するサブモデル管理部と、 複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部と、 を有する管理部を設けることを特徴とするリポジトリ装置。」と補正された。 上記補正は、請求項1に記載した発明を特定するために必要な事項である「一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段」について「一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段」とし、同「前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」について「前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」とし、同「ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置」について、さらに「複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部」を設けたものであるとの限定を付加するものであって、特許法第17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、上記手続補正2による補正後の上記請求項1に記載された発明(以下、本願補正発明という。)が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第4項において準用する同法第126条第3項の規定に適合するか)について以下に検討する。 (2)引用例 [引用例] 原査定の拒絶の理由に引用された特開平5-324295号公報(平成5年12月7日出願公開、以下、引用例という。)には、図面とともに、以下のことが記載されている。 (A)「【0001】 【産業上の利用分野】本発明はソフトウエアの開発支援装置に係り、さらに詳しくは、ソフトウエアの設計作業におけるガイダンス、設計ドキュメントや設計部品等の情報管理、チェックを行ない、設計工程を中心とする開発支援および設計作業を自然な流れで進めることを可能とするソフトウエアの開発支援装置に関する。」 (B)「【0021】第4に設計ドキュメント管理手段7を有する。設計ドキュメント管理手段7は、前記設計エディタ手段5によって設計した結果として得られる設計ドキュメントやプログラム部品を、前記抽象化レベル規定手段4で規定した抽象化レベルに従った階層ディレクトリをDASD上の設計ドキュメント・ファイル3に自動生成し管理したうえ格納する。・・・ 【0022】第5に、設計データベース格納手段8を有する。設計データベース格納手段8は、設計ドキュメント・ファイル3に格納する設計部品やプログラム部品のなかで、例えば、レビュー状況が編集完了済みのもののみというように、特定の条件を満たす部品をデータとして登録し、必要に応じて更新する。」(・・・は引用箇所の省略を意味し、以下、同様とする。) (C)「【0040】・・・また、修正が必要な設計ドキュメントについての設計エディタを直接起動し、修正が必要な設計部品やプログラム部品についての図形シンボルを高輝度表示や表示色判定等の方法で判別しやすくする処理を行なう。・・・」 (D)「【0044】対話管理制御部10は、設計者18とシステムの対話、すなわち、入出力を管理し、制御する部分である。例えば、設計者18は、対話管理制御部10を通して設計を開始したい抽象化レベルを指定したり、設計情報の入力を行なったり、設計作業に関する支援の要求を指定する。 【0045】・・・一方、設計エディタ群12は、各抽象化レベルの仕様情報ごとに割り付けられた複数の設計エディタからなる。設計者18は、抽象化レベル規定テーブル群11によって定義された抽象化レベルを選択し、何をどのように設計したらよいかのガイダンスの提示を受けたうえで、対応する設計エディタを起動することができる。」 (E)「【0047】設計ドキュメント管理部14は、設計エディタ群12中のいずれかの設計エディタで作成された結果としての設計ドキュメントを設計ドキュメント・ファイル15に格納し、管理する。・・・ 【0048】一方、設計データベース16には、設計エディタ上で定義された設計部品や設計部品間の関連の実体に関するデータを保持する。そして、設計情報矛盾修正支援部17は、設計データベース上に登録されている設計部品や関連のなかで、抽象化レベル内の複数の設計ドキュメントにまたがって記述されているものに矛盾がないか否かをチェックし、矛盾がある場合には該矛盾に修正を施す支援を行なう。」 (F)「【0120】図24は、設計ドキュメント管理部(図2の14)が行なう抽象化レベル毎の設計ドキュメントの管理と、設計ドキュメントの格納の説明図である。設計ドキュメント管理部14は、設計ドキュメントのディレクトリ階層を作成するディレクトリ階層作成部255と、実際に設計ドキュメントをDASD上の設計ドキュメント・ファイル16に格納する設計ドキュメント格納部256からなる。図中の太い矢印は段階的詳細化の流れを示し、破線矢印は制御の流れを示す。 【0121】すなわち、設計者は、抽象化レベル1で設計ドキュメント1を作成し、そのなかの一つの部品を同じ抽象化レベル1の設計ドキュメント2で詳細化している。さらに、設計ドキュメント2で詳細化した部品を下位レベルである抽象化レベル2の設計ドキュメント3でさらに詳細化し、そのなかの一つの部品を更に同じ抽象化レベル2の設計ドキュメント4で詳細化している。 【0122】今、設計者が抽象化レベルに従ってソフトウエアの設計作業を行なう際に、二つの抽象化レベル間にまたがる詳細化を行なう場合(例えば、抽象化レベル1の設計ドキュメント2を抽象化レベル2で詳細化し設計ドキュメント3を作成するような場合)には、設計ドキュメント2の詳細化を実行するときにディレクトリ階層作成部255を起動する(S256)。ディレクトリ階層作成部255はDASD上に該当する抽象化レベル(抽象化レベル2)に対応したディレクトリがあるか否か確認し、ない場合には抽象化レベルに対応したディレクトリを作成する。すなわち、抽象化レベル2のディレクトリがあるか否かを確認し、ない場合には抽象化レベル2のディレクトリとして設計ドキュメント3を作成する(S257)。」 (G)「【0134】設計データベースの論理構成は階層構造になっていて、その一番上位には抽象化レベル名310がある。これには、図4の一実施例の抽象化レベル規定テーブル群の説明図で説明した抽象化レベル・テーブル111で規定されている抽象化レベル名が入る。抽象化レベル名310の下位には設計部品の種類311および関連の種類312がある。設計部品の種類311には、図4で説明した抽象化レベル設計部品テーブル113で規定している設計部品の種類名が、また、関連の種類312には、図4で説明した抽象化レベル関連テーブル114で規定している関連の種類名が入る。さらに、設計部品の種類311の下位に設計部品実体313があり、個々の設計部品がもつ種別が入る。さらに、その下位に図4の設計部品属性テーブル116で規定されている設計部品のキー属性値314と、その他の属性値315が入る。さらに、これらと並んで、設計部品が定義されている設計ドキュメント・リスト316が入る。一方、関連の種類312の下位には関連実体の種別317が、さらにその下位には関連の属性値318と、その関連が定義されている設計ドキュメント・レベル319が入る。 【0135】構成図内の階層を位置づける線分のうち、矢印のない線分は上位に対して下位が複数存在することを意味する。例えば、一つの抽象化レベル内には複数の設計部品と関連が存在し、それぞれが複数の設計部品実体と関連実体をもち、さらに各設計部品や関連の実体は複数の属性値を持つことを意味する。一方、矢印のある線分は上位に対して1個だけ下位が存在することを意味する。例えば、設計部品は設計部品キー属性と設計ドキュメント・リストを1個だけ持つ。設計ドキュメント・リスト316および319は、各設計部品実体や関連実体が複数の設計ドキュメントに出現する場合に、それらの間の一貫性を保証するための処理に利用される。 【0136】また、設計データベースへの設計部品や関連実体の登録・更新は、図23の設計ドキュメント格納要求時の動作フローチャートに示したように設計ドキュメントの格納要求に伴って実現される。このとき、設計ドキュメントとして格納される各設計部品や関連実体毎に設計データベース格納フラグによって登録済みか否かが識別できるので、既に設計データベースに登録済みの設計ドキュメント内の設計部品や関連実体に対しては、新規に設計データベースに登録する設計部品や関連実体とは区別した修正処理が施せる。」 (H)又、上記(C)及び図19を勘案すると、設計ドキュメントが個々の設計ドキュメントを図形シンボルで表示するための情報を有していることは明らかである。 (I)上記(E)、(G)及び図30を勘案すると、設計データベースのデータが個々の設計ドキュメントの設計部品の実体に関するデータと共に、当該設計部品間の関連の実体に関するデータ、当該設計部品が定義されている設計ドキュメント・リストや、階層構造で示された論理的な構造に関する情報を有していることは明らかである。 上記(A)〜(I)及び図面を勘案すると、引用例1には、 個々の設計ドキュメントの論理的な構造に関する情報及び個々の設計ドキュメントを図形シンボルで表示するための情報を入力する対話管理部及びエディタ群と、 上記個々の設計ドキュメントの論理的な構造に関する情報を管理する設計データベース格納手段と、 上記設計ドキュメントを図形シンボルで表示するための情報を管理する設計ドキュメント管理手段と、 上記設計ドキュメント管理手段がさらに複数の設計ドキュメントのディレクトリ階層を格納し管理するものである開発支援装置(以下、引用発明という。) が開示されていると認められる。 (3)対比 そこで、本願補正発明と引用発明を対比すると、引用発明の「設計ドキュメント」、「個々の設計ドキュメントの論理的な構造に関する情報」、「個々の設計ドキュメントを図形シンボルで表示するための情報」、「対話管理部及びエディタ群」、「上記個々の設計ドキュメントの論理的な構造に関する情報を管理する設計データベース格納手段」、「上記設計ドキュメントを図形シンボルで表示するための情報を管理する設計ドキュメント管理手段」は、それぞれ本願補正発明の「ドキュメント」、「論理サブモデル」、「ビュー」、「論理サブモデル取込手段」及び「ビュー取込手段」、「論理サブモデル管理手段」、「ビュー管理手段」に対応する。 したがって、本願補正発明と引用発明は、 一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段と、当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、を有するサブモデル管理部と、を有するリポジトリ装置 である点で一致し、以下の点で相違している。 [相違点1] 本願補正発明では、複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有しているのに対して、 引用発明では、上記設計ドキュメント管理手段がさらに複数の設計ドキュメントのディレクトリ階層を格納し管理するものである点。 [相違点2] 本願補正発明では、論理サブモデル取込手段、論理サブモデル管理手段、ビュー取込手段と、ビュー管理手段、をまとめてサブモデル管理部とし、上記サブモデル管理部と論理モデル管理部をまとめて管理部としているのに対して、引用発明がそのようなものでない点。 (4)相違点についての判断 [相違点1について] 例えば、本願出願前に頒布された刊行物である特開昭62-214438号公報(昭和62年9月12日出願公開、以下、周知例という。)には、 「2.特許請求の範囲 1.ソフトウェア仕様書を構成する種々の仕様ドキュメントと、・・・その関連情報とを計算機に蓄積し、蓄積された仕様ドキュメントの変更手段と他の仕様ドキュメント内の関連して変更すべき個所を検出する手段・・・、新しいソフトウェア仕様書に含むべき仕様ドキュメントと、その構成を示す仕様書構成情報を利用する手段を設けることにより、個々の仕様ドキュメントの変更に伴い、追加、削除すべき仕様ドキュメントの検出をも可能としたことを特徴とするソフトウェア仕様書再利用方式。」(公報1頁左下欄4行〜19行)、 「前記ファイルメモリ5に蓄積されている仕様関連情報は、対象ソフトウェアシステム全体に含まれる仕様情報とその関連、およびそれらを含む仕様ドキュメントとの関連の情報を保持するものであり、個々のドキュメント修正により、変形が影響する他のドキュメントの検出に使用する。 ファイルメモリ7に蓄積されている仕様書構成情報が本発明の特徴とするところであり、その内容は、例えば、システムフロー図にファイル名称が記載されている場合には対応するファイル仕様がなければならないことを示す情報等の、仕様書を構成する仕様ドキュメント間の存在依存関係を示す情報である。」(公報3頁右下欄9行〜4頁左上欄1行)と記載されており、これらの記載を勘案すると、周知例には、複数の仕様ドキュメントの間の存在依存関係を示す情報を蓄積して管理すること、すなわち、複数のドキュメントの間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報を蓄積し管理することが開示されており、上記の構成は本願出願前周知の技術であると認められる。 してみれば、引用発明において、周知例に記載されているような上記の周知の技術を参酌して、複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有するようにすることは、当業者が容易になし得るものである。 [相違点2について] 本願補正発明では、論理サブモデル取込手段、論理サブモデル管理手段、ビュー取込手段と、ビュー管理手段、をまとめてサブモデル管理部とし、上記サブモデル管理部と論理モデル管理部をまとめて管理部としているのに対して、引用発明がそのようなものでないが、管理のための複数の手段をまとめて1つの管理部として構成することは本願出願前周知の技術であって、当業者が設計時に適宜選択し得る設計的事項であるから、この点については格別の差異ではない。 したがって、本願補正発明は、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができないものである。 (5)むすび 以上のとおり、上記手続補正2による上記の補正は、特許法第17条の2第4項で準用する同第126条第3項の規定に違反するものであり、同第159条第1項で準用する同第53条第1項の規定により却下されるべきものである。 [理由2] (6)請求項5に係る補正 上記手続補正2は、特許請求の範囲の請求項5について 「【請求項5】前記管理部は、ドキュメントが保存される際に、論理モデルへ保存することなく、論理サブモデルへ保存及びビューへ保存する手段を有する請求項1〜3いずれか1項に記載のリポジトリ装置。」を、 「【請求項5】前記論理モデル管理部は、前記検出手段により、前記影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する中止手段を有し、 前記サブモデル管理部は、前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する手段を有する請求項4記載のリポジトリ装置。」と補正し、それと共に、第0015段落について、 「【0015】 請求項5に記載の発明は、前記管理部は、ドキュメントが保存される際に、論理モデルへ保存することなく、論理サブモデルへ保存及びビューへ保存する手段を有する請求項1〜3いずれか1項に記載のリポジトリ装置である。」を 「【0015】 請求項5に記載の発明は、前記論理モデル管理部は、前記検出手段により、前記影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する中止手段を有し、前記サブモデル管理部は、前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する手段を有する請求項4記載のリポジトリ装置である。」と補正している。 (7)補正についての判断 本願の願書に最初に添付した明細書又は図面には、論理モデルの保存に関して、 「【請求項5】前記管理部は、ドキュメントが保存される際に、論理モデルへの保存をすることなく、論理サブモデルへの保存及びビューへの保存を行う手段を有する請求項1〜3いずれか1項に記載のリポジトリ装置。」、 「【請求項6】前記管理部は、ドキュメントが保存される際に、論理モデルへの保存及び論理サブモデルへの保存をすることなく、ビューへの保存を行う手段を有する請求項1〜3いずれか1項に記載のリポジトリ装置。」、 「【0010】 ところで、ドキュメント自体に誤りがあるのに保存が行なわれると、その誤りによってリポジトリ装置の内部に保存される論理モデルが壊れてしまう。・・・」、 「【0015】 また、請求項5の発明は、ドキュメントが保存される際に、論理モデルへの保存をすることなく、論理サブモデルへの保存及びビューへの保存を行う手段を有する管理部を設けたリポジトリ装置であり、請求項6の発明は、ドキュメントが保存される際に、論理モデルへの保存及び論理サブモデルへの保存をすることなく、ビューへの保存を行う手段を有する管理部を設けたリポジトリ装置である。」、 「【0019】 請求項5及び6の発明によるリポジトリ装置では、論理モデルを変更せずに、ドキュメントの保存が可能となる。ドキュメント作業を中断する時、そのドキュメントによって論理モデルが更新されないことを希望する場合などに有用である。特に請求項6の発明によるリポジトリ装置では、誤りの存在によってドキュメント・チェックにパスしないようなドキュメントをリポジトリ装置へ保存することが許容される。エディタを再起動すると、作業中断で保存されたドキュメントが、前回の状態のまま画面に再現される。」 と記載されているだけであって、「中止手段」という構成、「前記検出手段により、影響を受ける論理コンポネントを検出した場合には、論理モデルの保存を中止する」という構成、及び「前記中止手段により論理モデルの保存が中止された場合には、論理サブモデル及びビューを保存する」という構成は、本願の願書に最初に添付した明細書又は図面には記載されていない。 したがって、上記手続補正2の請求項5及び第0015段落に係る補正は、本願の願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものとは認められない。 (8)むすび 以上のとおり、上記手続補正2による上記の補正は、特許法第17条の2第2項で準用する同第17条第2項の規定に違反するものであり、同第159条第1項で準用する同第53条第1項の規定により却下されるべきものである。 3.本願発明について 上記手続補正2は、上記のとおり却下されたので、本願の請求項1に係る発明(以下、本願発明という。)は、上記手続補正1により補正された特許請求の範囲の請求項1に記載された次のとおりのものと認める。 「【請求項1】ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置であって、 一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段と、 当該論理サブモデル取込手段により取り込まれた論理サブモデルを管理する論理サブモデル管理手段と、 前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段と、 当該ビュー取込手段により取り込まれたビューを管理するビュー管理手段と、 を有する管理部を設けることを特徴とするリポジトリ装置。」 (1)引用例 原査定の拒絶の理由に引用された引用例、及び、その記載事項は、上記「2.(2)」に記載したとおりである。 (2)対比・判断 本願発明は、上記「2.」で検討した本願補正発明から「一つのドキュメントが持つ意味的な情報を構成する意味的構成要素の当該一つのドキュメントにおける論理的な構造、に関する情報である論理サブモデルを取り込む論理サブモデル取込手段」を「一つのドキュメントに対応する論理モデルである論理サブモデルを取り込む論理サブモデル取込手段」とし、同「前記一つのドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」を「前記ドキュメントが持つ意味的な情報を画面に図形的に表示するために用いられる情報であるビューを取り込むビュー取込手段」とし、同「ドキュメントが持つ意味的な情報を構成する意味的構成要素の、論理的な構造に関する情報である論理モデルを蓄積し管理するリポジトリ装置」について、さらに「複数の論理サブモデル間の論理的な構造に関する情報であって、複数のドキュメントに亘る情報である論理モデルを蓄積し管理する論理モデル管理手段を有する論理モデル管理部」を設けたとの限定事項である「論理モデル管理部」との構成を省いたものである。 そうすると、本願発明の構成要件を全て含み、さらに他の構成要件を付加したものに相当する本願補正発明が、上記「2.[理由](4)」に記載したとおり、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものである。 (3)むすび 以上のとおり、本願発明は、引用例に記載された発明及び周知の技術に基き、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2003-08-19 |
| 結審通知日 | 2003-08-26 |
| 審決日 | 2003-09-08 |
| 出願番号 | 特願平7-94920 |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 林 毅 |
| 特許庁審判長 |
吉岡 浩 |
| 特許庁審判官 |
吉見 信明 新井 則和 |
| 発明の名称 | リポジトリ装置 |
| 代理人 | 本間 崇 |