【事件の表示】
　平成　７年特許願第　４２６４２号「資源再利用支援装置」拒絶査定不服審判事件〔平成　８年　９月１７日出願公開、特開平　８−２４１３４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成７年３月２日の出願であって、平成１６年３月８日付で拒絶査定がされ、これに対し、同年４月１５日に拒絶査定不服審判が請求され、その後当審において平成１８年６月３０日付で拒絶の理由が通知され、同年９月１１日付で手続補正書が提出されたものである。
　
２．本願発明
　本願の請求項１に係る発明は、平成１８年９月１１日付の手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下「本願発明」という。）
　
「パッケージを構成する資源の再利用を支援する装置であって、
　前記資料に対して修正内容に基づき修正した場合の変更資源については、パッケージ名情報、資源名情報、資源種別情報、修正内容情報、および工数情報を記憶し、前記資源を該変更資源に修正した場合に修正が必要となる関連資源については、パッケージ名情報、資源名情報、資源種別情報、修正内容情報、および工数情報を記憶した事例データベースと、
　前記変更資源と前記関連資源との関連付け情報を記憶した資源管理テーブルと、
　パッケージ名情報と修正内容情報が入力されると、前記事例データベースで該パッケージ情報と該修正内容情報とが合致する変更資源を前記事例データベースから検索し、変更資源が前記事例データベースにある場合は前記資源管理テーブルに基づき該変更資源に関連する関連資源を検索すると共に、前記事例データベースの工数情報から変更資源と検索された関連資源の全てに対し修正に必要な工数情報と修正内容情報とからなる一覧表と工数の合計工数とを作成する事例検索手段と、
　前記事例検索手段による変更資源と関連資源とからなる検索結果を表示する表示手段とを備えたことを特徴とする資源再利用支援装置。」
　
３．引用例
（３−１）当審の拒絶の理由に引用された、黄錦法ほか、ＨＳＣに基づく通信システム仕様開発環境のＣＢＲツールによる実現、情報処理学会研究報告、社団法人情報処理学会、第９３巻、第５８号（９３−ＯＳ−６０）、１９９３年７月９日、１５５−１６２頁（以下、「引用例１」という。）には、図面と共に次の事項が記載されている。
　
ア「近年，通信技術の進歩に伴って，大規模な情報通信システムの構築が必要になってきている。通信システムの構築には通信ソフトウェアを効率的に開発することが問題となる。通信ソフトウェアの開発は仕様の記述，仕様のインプリメンテション，コンフォーマンステストなどの段階に分けられる。この中で，特に仕様記述段階が重要な役割を占めている。仕様記述段階においては通信システムの仕様をいかに効率的に記述するかが焦点となる。そのため，著者らは通信システムの仕様の初期開発向きの仕様記述法ＨＳＣ（Ｈｉｅｒａｒｃｈｉｃａｌ　Ｓｅｑｕｅｎｃｅ　Ｃｈａｒｔ）を提案している。ＨＳＣの特徴は，仕様をトップダウン的に開発でき，仕様全体の理解性の向上を達成し，さらに仕様の部品の再利用に基づいた仕様の開発が可能となっていることである。
　本稿では，部品の再利用に基づいたＨＳＣ仕様をより効率的に開発するため，事例べース推論を適用したＨＳＣ仕様開発環境をＣＢＲツールＡＲＴ／ＩＭにより実現する。」（１５６頁左欄２行〜２０行）
　
イ「（２）再利用部品の修正支援：過去の仕様の修正事例を修正事例べースに保存する。再利用する仕様を修正する際には，修正事例べースから修正事例を検索し，見付かった場合，修正のアドバイスを提案することができる。」（１５６頁左欄４５行〜右欄２行）
　
ウ「（３）再利用部品の検索および修正機能
　１）再利用部品の検索機能
　仕様要求テンプレートに入力された情報に基づいて，文献［４］で定義された類似度により，類似部品を仕様事例べースから検索し，類似度の高いものを再利用可能な類似部品の候補として挙げる。
　２）再利用部品の修正機能
　１　部品の修正箇所の指摘
　記述する仕様の仕様要求（仕様要求テンプレートに入力された情報）と，類似部品の仕様要求（過去の仕様要求テンプレートに入力された情報）との間のキーワードの比較を行う。前者の仕様要求にはなく，後者のそれにはあるキーワード（削除キーワードと呼ぶ）がある場合，削除キーワードに対応する仕様の部分を削除する。この時，修正事例べースからキーワードの部分が削除キーワードとマッチする修正事例を検索する（複数ある場合はユーザが選択）。部分マッチあるいは全部一致の場合，キーワードに対応する修正事例のＨＳＣ仕様の部分を修正箇所として指摘する。全部一致しない場合，ユーザが再利用部品の中で必要がない部分を削除する。
　２　部品の修正内容の提案
　記述する仕様の仕様要求と類似仕様部品の仕様要求との間のキーワードの比校結果として，前者の仕様要求にあり，後者のそれにはないキーワード（追加キーワードと呼ぶ）がある場合，（１）と同様に追加キーワードとマッチする修正事例を検索する（複数ある場合はユーザが選択）。部分マッチあるいは全部一致の場合，キーワードに対応する修正事例のＨＳＣ仕様の部分を修正内容として提案する。全部一致しない場合，ユーザが追加すべきの仕様を加える。
　３　修正事例（知識）の自動獲得
　修正事例を獲得するため，次の２つの機能を提供する．
　ａ）部品の修正箇所の指摘において，ユーザが再利用部品の中で必要がない部分を削除する際，削除キーワードと，ユーザが削除したＨＳＣ仕様の部分を修正事例として獲得する。
　ｂ）部品の修正内容の提案において，ユーザが追加すべきの仕様を加える際，追加キーワードと，ユーザが加えたＨＳＣ仕様の部分を修正事例として獲得する。」（１５８頁左欄３行〜４５行）
　
エ「（４）修正事例べース
　修正事例べースには仕様枠組修正事例，フェーズ修正事例，ケース修正事例の３種類がある。それぞれの事例は次の２つから構成される。（１）修正事例キーワード：４．２で定義した削除キーワードや追加キーワード，（２）ＨＳＣ仕様：修正事例キーワードに対応する修正されたＨＳＣ仕様の部分。」（１５９頁右欄３行〜９行）
　
オ「Ｓｔｅｐ１．４類似仕様枠組の修正支援
　再利用部品が選択された場合，システムが修正事例に基づいて，図８の右上と右下のウィンドウにそれぞれ再利用部品の修正箇所の指摘と修正内容の提案を行う。例では，修正箇所の指摘として，削除キーワードとそれに対応するＨＳＣ仕様の部分（フェーズ名とそのケース名）が表示されている。また，修正内容の提案として，修正事例が見付からなかったため，修正内容の提案ができないというメッセージが表示されている。」（１６０頁左欄３５行〜４４行）
　
　したがって、アないしオの記載及び図１ないし９から、引用例１には
「通信ソフトウエアを開発する際の、仕様の再利用を支援するＨＳＣ仕様開発環境であって、修正事例キーワードと修正事例キーワードに対応する修正したＨＳＣ仕様の部分が格納された修正事例ベースを有しており、再利用する仕様を修正する際には、修正事例ベースから、修正事例キーワードとマッチする修正事例を検索し、修正事例キーワードに対応する修正事例のＨＳＣ仕様の部分を修正内容としてウィンドウに表示し、提案するもの。」
の発明（以下、「引用発明」という。）が記載されている。
　
（３−２）当審の拒絶の理由に引用された、落水浩一郎、データエンジニアリングの最近の動向　４．ソフトウェア・レポジトリ、情報処理、社団法人情報処理学会、第３５巻、第２号、１９９４年２月１５日、１４０−１４９頁（以下、「引用例２」という。）には、図面と共に次の事項が記載されている。
　
カ「１．はじめに
　本稿では，「支援対象活動」と「ソフトウェア開発の規模」をパラメータとして，８０年代から９０年代にいたるソフトウェア・レポジトリに関する研究成果を解説する。ソフトウェア・レポジトリとは，ソフトウェアに関するさまざまな情報を，目的に適合する記法で表現・格納し，その変更を制御し，利用・維持することを助ける汎用の情報システムである。」（１４０頁左欄１行〜９行）
　
キ「２．３．２　プロジェクト管理
　プロジェクト品質を技術的に評価するためにはプロジェクトを特性づける種々のデータを解析の目的にあわせて収集・管理する必要がある。これにより，プロセスやプロダクトの長所や欠点の理解を助け，欠点を改善するための具体的指針や手掛りを与え，さらにユーザ環境に適する新技術を導入する際の評価手段を与えることができる。たとえば，参考文献２５）によると，データ収集の目的は以下の４点にある。
（１）  モニタリング  現在進行中のソフトウェア開発プロジェクトの追跡をすることにより以下の３点の状況を把握する。（ａ）計算機資源やスタッフ時間などの資源利用率を把握する。（ｂ）進捗状況を，設計済みモジュール数，コード化済みモジュール数，テスト数，モジュール数，作成済みソース行数などにより把握する。（ｃ）複雑性の高すぎるコード，不十分な完成度，テストが容易でないものなどを検出することにより品質を管理する。
（２）　ライフサイクルモデリング　たとえば，汎用コストモデルのモデル定数を履歴データを基にして決めるように，汎用モデルのユーザ環境への特化のためのデータを収集する。
（３）　方法論の評価　環境特性や方法論の評価を実ユーザ環境で実験し，その効果を評価する。
（４）　基礎研究へのフィードバック 　ソフトウェア・メトリックス，信頼性理論，モデリングなどの研究分野へのフィードバックをはかる。
　このとき，プロジェクト進行にともなって発生するデータを図−１（ａ）に示すモデルに従って図−１ （ｂ）に示すような分類で収集する。収集するデータは以下のように目的ごとに異なる。
（１）　方法論の評価
　問題：ソフトウェアの型，要求の数
　資源：要員の型ごとのスタッフ時間
　環境：計算機環境，使用言語，スタッフの経験
　プロセス：採用された方法論と利用の程度
　プロダクト：ソース行数，ドキュメント枚数，実行プログラム行数，決定の回数
　変更／エラー：エラーや変更の数と型，影響度，修正の工数，エラーや変更の発生時期と継続日数
（２）  資源／コストモデリング
　問題：ソフトウェアの型，要求の数
　資源：局面ごとのスタッフ時間，局面ごとの計算機時間と実行回数
　環境：計算機環境，使用言語，スタッフの経験
　プロダクト：データセットとサブシステムの数
（３）　信頼性／エラーモデル
　問題：ソフトウェアの型
　資源：計算機時間と実行回数
　環境：スタッフの経験，オンライン開発
　プロダクト：ソース行数，実行プログラム行数　決定の数，モジュール数
　変更／エラー：エラーや変更の数と型，影響度　修正の工数，エラーや変更の発生時期と継続日数
（４）　ソフトウェア・メトリックス
　問題：ソフトウェア要素の型
　資源：要素ごとのスタッフ時間
　プロダクト：ソース行数，決定の数
　変更／エラー：変更やエラーの数と型
　これらのデータは，解析プログラムの方針にあわせてデータベース化される。データ収集・解析の手順は図−２に示すようになる。」（１４４頁左欄２６行〜１４５頁右欄３行）
　
４．対比
　本願明細書の【０００４】に「ソフトウェア再利用を効率的」に行うこと、【００２８】に関連資源の説明として「資源種別：プログラム」、【００３４】に「１つのパッケージを構成する全ての資源を検索」することが記載されていることから、本願はソフトウエア作成の分野に係るものである。
　
　本願発明の「パッケージ」は「パッケージソフト」の略であり、媒体に格納され、包装された形態（パッケージ）で流通するソフトウエアを意味する語である。また、本願発明の「資源」はソフトウエア作成の分野において、ソフトウエア部品を意味する語である。
　
　引用発明の「通信ソフトウエア」と本願発明の「パッケージ」とは、ソフトウエアである点で共通している。
　
　引用発明の「修正事例キーワード」、「修正事例ベース」は、本願発明の「修正内容情報」、「事例データベース」に相当する。
　
　したがって、本願発明と引用発明とを比較すると、
「ソフトウエアを構成する部品の再利用を支援するものであって、再利用する部品の修正内容情報を含む情報が格納された事例データベースを検索し、検索結果を表示するもの。」
である点で一致し、以下の点で相違する。
　
（相違点１）
　本願発明が「パッケージを構成する資源の再利用を支援する装置」である「資源再利用支援装置」であるのに対し、引用発明は「仕様の再利用を支援するＨＳＣ仕様開発環境」である点。
　
（相違点２）
　本願発明が、資料に対して修正内容に基づき修正した場合の変更資源と、資源を変更資源に修正した場合に修正が必要となる関連資源とを記憶した事例データベースと、変更資源と関連資源との関連付け情報を記憶した資源管理テーブルを有し、検索条件に合致した変更資源が事例データベースにある場合は、資源管理テーブルに基づき変更資源に関連する関連資源を検索する手段と、変更資源と関連資源からなる検索結果を表示する表示手段を有するのに対し、変更資源と関連資源との関連付け情報を記憶した資源管理テーブルとを有するのに対し、引用発明は、修正事例キーワードと修正事例キーワードに対応する修正したＨＳＣ仕様の部分が格納された修正事例ベースを有するものである点。
　
（相違点３）
　本願発明が、事例データベースに格納される情報の項目として、変更資源及び関連資源についてパッケージ名情報、資源名情報、資源種別情報、修正内容情報、および工数情報を記憶し、パッケージ名情報と修正内容情報が入力されると、事例データベースで入力されたパッケージ名情報と修正内容情報とが合致する変更資源を事例データベースから検索し、変更資源が前記事例データベースにある場合は、関連する関連資源を呼び出し、事例データベースの工数情報から変更資源と検索された関連資源の全てに対し修正に必要な工数情報と修正内容情報とからなる一覧表と工数の合計工数とを作成する事例検索手段を有するのに対して、引用発明は、修正事例キーワードによって修正事例キーワードに対応する修正されたＨＳＣ仕様を検索する点。
　
５．判断
　上記相違点について検討する。
（相違点１）について
　パッケージソフトウエア、すなわち「パッケージ」は広く知られてており、また、そのソフトウエア部品、すなわち「資源」を再利用してソフトウエアの作成を支援することはソフトウエア作成の分野において普通に行われることである。
　よって、引用発明において、通信ソフトウエアを作成するための仕様及びＨＳＣ仕様を再利用することを、パッケージソフトウエアを構成する資源の再利用に適用し、資源再利用支援装置とすることは当業者が容易になし得たことである。
　
（相違点２）について
　情報検索の際に、複数の情報の関連付けについての情報を予め用意しておき、検索条件に合致した情報と、当該情報に関連する情報を検索結果とすることは、広く知られている。例えば、菅沼拓夫ほか、事例ベース検索を用いた知的仕様記述エディタと通信ソフトウェア設計への適用、電子情報通信学会技術研究報告、vol.94、no.133（ＡＩ９４−２３〜３２　人工知能と知識処理）、１７−２４頁、平成６年７月８日、には、要求仕様部品とその設計例である設計仕様部品事例が事例ベースに格納されており、要求仕様部品事例と設計仕様部品事例との関係についての情報がデータベースに格納され、要求仕様部品事例の検索指示を受けると検索処理を行い、合致した要求仕様部品と対応する設計仕様部品事例が提示されることが記載されている。
　そして、複数の情報の関連についての情報をテーブルの形で格納することは情報処理の分野において慣用手段である。
　また、検索結果として得られた情報を表示することは情報処理の分野において普通に行われることである。
　よって、引用発明において、事例データベースに格納される修正事例として、資源を変更した事例である変更資源と、変更資源と関連した関連資源を格納し、変更資源と関連資源との対応付け情報を格納したテーブル、すなわち資源管理テーブルを設け、事例データベースに対して検索指示を受けると、変更資源を検索し、得られた変更資源について資源管理テーブルを参照して関連資源を検索し、得られた変更資源と関連資源を検索結果として表示するよう構成することは、当業者が容易になし得たことである。
　
（相違点３）について
　ソフトウエア作成の分野において、資源を特徴付ける項目としてパッケージ名情報、資源名情報、資源種別情報があることは広く知られていることである。
　また、複数の項目を有するレコードが複数格納されたデータベースからレコードを検索する際に、どの項目を検索キーとするかは、項目ごとの識別性や指定の容易性などを考慮して任意に設定することである。さらに、検索結果のレコードを表示する際に、幾つかの項目を一覧表示することは、普通に行われることである。
　さらに、相違点２について述べたように、情報検索の際に、複数の情報の関連付けについての情報を予め用意しておき、検索条件に合致した情報と、当該情報に関連する情報を検索結果とすることは、広く知られている。
　そして、引用例２には、ソフトウエア作成事例に関する情報を収集してデータベースに格納し、ソフトウエア開発に役立てる技術において、ソフトウエア開発事例についてのデータとして工数を格納して評価に用いることが記載されている。また、ソフトウエアを構成する複数のコンポーネントについて工数を求め、これらの工数を合計して全体の工数を見積もることは、システム設計の分野において周知である。例えば、寺本雅則ほか、ソフトウェア開発工数の見積もり手法、日経データプロ・ソフト、日経ＢＰ社、Ｖｏｌ．１、１９９３年１２月３１日、２５１−２６３頁、特に２５９〜２６１頁に記載されている。
　よって、引用発明において、事例データベースに格納する資源の事例として、修正内容情報に加えてパッケージ名情報、資源名情報、資源種別情報及び工数情報を設定し、パッケージ名情報と修正内容情報を検索キーとして一致する変更資源を検索し、検索された変更資源と関連した関連資源を読み出し、得られた変更資源及び関連資源について工数情報と修正内容情報を一覧表示し、工数情報に基づいて合計工数を算出するよう構成することは、当業者が容易になし得たことである。
　
６．むすび
　以上のとおり、本願発明は引用例１，２に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。