【事件の表示】
　特願２０００−　７０２７２「半導体設計ライブラリの管理方法及び使用方法」拒絶査定不服審判事件〔平成１３年　９月２１日出願公開、特開２００１−２５６０９３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年３月１４日の出願であって、平成１７年３月２５日付けで拒絶理由通知がなされ、同年５月２７日付けで手続補正がなされたが、同年６月２８日付けで拒絶査定がなされ、これに対し、同年８月３日に拒絶査定不服審判の請求がなされたものである。
　
２．本願発明
　本願の請求項５に係る発明は、平成１７年５月２７日付けの手続補正書により補正された明細書及び図面の記載からみて、次のものと認める。（以下、「本願発明」という。）
「１つ以上のセルファイルから構成された半導体設計ライブラリをライブラリ単位でバージョン管理及びリリースを行い、
　使用する前記半導体設計ライブラリのバージョンを指定したバージョン管理ファイルを作成し、
　該バージョン管理ファイルで指定されたバージョンの半導体設計ライブラリをテンポラリディレクトリに登録し、
　該テンポラリディレクトリに登録された半導体設計ライブラリを用いることを特徴とする半導体設計ライブラリの使用方法。」
　
３．引用例
　原査定の拒絶の理由に引用された特開平８−１３７９２３号公報（以下、「引用例１」という。）、及び特開平１１−２８４０７５号公報（以下、「引用例２」という。）には、それぞれ、図面とともに次の事項が記載されている。
　
（引用例１）
Ａ．「【００１１】図１を参照すると、本実施例はＣＡＤシステムの設計データを一元管理するデータ管理領域６およびＣＡＤシステムを実行するための作業領域７を備える管理データベース５と、入出力装置１からの指示を受けて確保した作業領域を割り当てる作業領域割当手段２と、ＣＡＤシステムの実行に必要なデータをデータ管理領域６から作業領域７にコピーするためのチェックアウト手段３と、ＣＡＤシステムを実行した後に更新されたデータを作業領域７からデータ管理領域６にコピーしたのち使用し終わった作業領域７の内容をクリアするチェックイン手段４とを備えている。」
　
　上記Ａの記載及び図１を参照すると、引用例１には、次の発明が記載されているものと認められる。（以下、「引用例１記載の発明」という。）
「ＣＡＤシステムの設計データを作業領域に登録し、
　該作業領域に登録されたＣＡＤシステムの設計データを用いるＣＡＤシステムの設計データの使用方法。」
　
（引用例２）
Ｂ．「【０００２】
【従来の技術】従来より、半導体マスクレイアウトを設計する場合には、セルを登録したセルライブラリを、コンパクション、マイグレーション、配置配線の手法を用いて設計を行っていた。」
　
Ｃ．「【０００６】図１０は、従来の半導体設計装置のブロック図であり、１は入力部、２は入力部１から入力した情報でデータを処理するＣＰＵ、３はセルを登録したセルライブラリ、４はＣＰＵ２とセルライブラリ３のマスクレイアウトデータを選択的に合成してコンパクションを行うコンパクション部、５はＣＰＵ２とセルライブラリ３のマスクレイアウトデータを選択的に合成してマイグレーションを行うマイグレーション部、６はＣＰＵ２とセルライブラリ３のマスクレイアウトデータを選択的に合成して配置配線を行う配置配線部、７はＣＰＵ２の結果を出力する出力部である。」
　
Ｄ．「【０００９】図３は、セルライブラリ３に登録されたセルＡのセルツリー図であり、セルＡがセルＢとセルＨとセルＥで構成されていて、その下の階層ではセルＢはセルＣとセルＤで、セルＨはセルＤで、セルＥはセルＦで、更にその下の階層ではセルＦはセルＧで構成されている。」
　
　上記Ｃの記載を参照すると、「セルライブラリ３」に登録される「セル」は、ＣＰＵによって処理されるデータであり、「セルファイル」と称することができる。
　よって、上記Ｂ〜Ｄの記載及び関連する図面を参照すると、引用例２には、次の発明が記載されているものと認められる。（以下、「引用例２記載の発明」という。）
「１つ以上のセルファイルから構成された半導体設計ライブラリ。」
　
４．周知例
　本願出願前に頒布された刊行物である「今泉貴史，ＵＮＩＸ流プログラミング　３６，ＵＮＩＸ  ＭＡＧＡＺＩＮＥ，株式会社アスキー，１９９３年１０月１日，第８巻，第１０号，ｐ．１４９−１５４」（以下、「周知例１」という。）、及び「Ｓ．シュトローベル他，ＬＩＮＵＸ　パーソナルユースのＵＮＩＸシステム，シュプリンガー・フェアラーク東京株式会社，１９９５年５月３０日，ｐ．１７６」（以下、「周知例２」という。）には、それぞれ、次の事項が記載されている。
　
（周知例１）
Ｅ．「ＲＣＳ
　プログラムを改良しようとしてソースファイルの編集をすると、誤ってバグを埋め込んでしまったり、ひどいときにはプログラムが動かなくなることもあります。このようなときにも、編集前のプログラムを保存しておけばすぐに以前の状態に戻せます。また、編集後のプログラムを前のものと比較すれば、どんな誤りを犯しているかも調べられるでしょう。つまり、プログラムを編集するときには、以前のバージョンを保存しておくことが重要となるわけです。
　・・・（中略）・・・
　このような問題に対処するためのシステムがバージョン管理システムです。これを用いれば、
●任意のバージョンの取出し
　・・・（中略）・・・
などがおこなえます。
　ＵＮＩＸ上のバージョン管理システムとしてよく利用されるものにＳＣＣＳとＲＣＳがあります。・・・（中略）・・・ＲＣＳは、ソースコードがフリー・ソフトウェア（ＧＮＵのソフトウェア）として配布されており、ほとんどのＵＮＩＸシステムで利用できます。」（第１４９頁左欄下から４行〜右欄第３３行）
　
Ｆ．「バージョンツリー
　実際の使い方の前に、もうすこしＲＣＳについて説明しておきましょう。バージョンは直前のバージョンとの差分として保存されると書きましたが、１つのバージョンから複数の異なるバージョンを作成することも考えられます。たとえば、ある段階でリリースしたバージョンをそのあとも改良のために編集していたところ、リリースしたものにバグが発見されたとしましょう。この場合にはリリースしたバージョンに潜んでいるバグを修正するために、そのバージョンを元に新たなバージョンを作成することになります。すると、リリースしたバージョンからは、開発の流れに沿ってできたバージョンとバグフィックスのためのバージョンという２つが作られます。
　ＲＣＳではこのような状況に対応するために、すべてのバージョンはバージョンツリーと呼ばれる木構造のかたちで保存されています。この本構造の根にあたるのが最初に作成したバージョンです。」（第１５０頁左欄第１８〜３５行）
　
Ｇ．「もっとも簡単な使用例
　ＲＣＳの話をするときに忘れてはならない言葉に、“チェックイン”と“チェックアウト”があります。チェックインは新たにバージョンを作成して登録、チェックアウトは登録してあるバージョンを取り出すことを示します。ＲＣＳは、ファイルをチェックイン、チェックアウトする基本的な機構を提供するもので、それをどう使うかはまったく使う側の自由です。・・・（中略）・・・
　憶えなければならないコマンドは、ｃｉ（チェックイン）コマンドとｃｏ（チェックアウト）コマンドだけです。それも、
％　ｃｉ　−ｌ　ファイル名
％　ｃｏ　−ｌ　ファイル名
という形式しか使いません。さっそく実行してみましょう。
　・・・（中略）・・・
　ａ．ｃというファイルをｃｉコマンドを使ってチェックインしたら、ａ．ｃ，ｖというファイルが作成されました。このファイルはＲＣＳの管理ファイルと呼ばれるもので、すべてのバージョン情報が蓄えられるたいせつなファイルです。」（第１５１頁左欄第１２行〜右欄第２２行）
　
Ｈ．「ＲＣＳの基本的なコマンドであるｃｉやｃｏについて・・・（中略）・・・勉強すれば、直前のバージョンだけでなくそれ以前のバージョンを回復する方法や枝分かれを作成する方法も埋解できるでしょう。」（第１５４頁右欄下から６〜２行）
　
（周知例２）
Ｉ．「ＲＣＳは数多くのコマンドを提供していますが，その中で最も重要なものの概要を，ここで説明します．
●ｃｉ（ｃｈｅｃｋ　ｉｎ）は，指定されたファイルをＲＣＳディレクトリへ移し，現在のバージョンを凍結します．ｃｈｅｃｋ−ｉｎごとにそのバージョン全体を格納するのではなく，ｄｉｆｆコマンドを用いて求めた，前回のバージョンとの差分のみを格納します．モジュールのバージョン番号は，自動的に加算されます．
●ｃｏ（ｃｈｅｃｋ　ｏｕｔ）は，現在のバージョンや，以前のモジュールに関し，修正を認めないコピーを作ります．修正したいモジュールがあれば，−ｌオプションを用いて示さなくてはなりません．このコピーは一度にひとりしか持ち出せないため，他のプログラマが同時にファイルを修正してしまうのを防ぎます．」（第１７６頁第１２〜２１行）
　
　上記周知例１及び周知例２の記載を参照すると、次の事項が周知であるということができる。
（１）編集によってプログラムのソースファイルの複数のバージョンを作成してリリースすること。
（２）作成された複数のバージョンを、バージョン管理システムによって管理すること。
（３）バージョン管理システムにおいて、バージョン情報が蓄えられる管理ファイルを作成すること。
（４）バージョン管理システムにより、作成された複数のバージョンの登録が行われ、登録されたバージョンは、任意のものが取出されて用いられること。
　
５．対比
　本願発明と引用例１記載の発明とを対比すると、まず、引用例１記載の発明における「ＣＡＤシステムの設計データ」も、本願発明における「１つ以上のセルファイルから構成された半導体設計ライブラリ」も、「電子データ」であることには変わりない。
　また、引用例１記載の発明における「作業領域」は、本願発明における「テンポラリディレクトリ」に相当する。
　
　よって、本願発明と引用例１記載の発明とは、ともに、
「設計データをテンポラリディレクトリに登録し、
　該テンポラリディレクトリに登録された設計データを用いる設計データの使用方法。」
である点で一致し、次の点で相違する。
　
　相違点１：「電子データ」が、本願発明においては、「１つ以上のセルファイルから構成された半導体設計ライブラリ」であるのに対し、引用例１記載の発明においては、そのようなものではない点。
　
　相違点２：本願発明においては、「１つ以上のセルファイルから構成された半導体設計ライブラリをライブラリ単位でバージョン管理及びリリースを行い」、「使用する前記半導体設計ライブラリのバージョンを指定したバージョン管理ファイルを作成」しており、テンポラリディレクトリに登録するものが「バージョン管理ファイルで指定されたバージョンの半導体設計ライブラリ」であるのに対し、引用例１記載の発明においては、そのようなものではない点。
　
６．当審の判断
　そこで、上記相違点１，２について検討する。
　
（相違点１について）
　設計の対象となる電子データとして、「１つ以上のセルファイルから構成された半導体設計ライブラリ」は、引用例２記載の発明に見られるような公知のものにすぎない。
　よって、引用例１記載の発明において、設計の対象となる電子データを「１つ以上のセルファイルから構成された半導体設計ライブラリ」とすることは、当業者が容易に想到し得ることである。
　
（相違点２について）
　「１つ以上のセルファイルから構成された半導体設計ライブラリ」も、上記４．の（１）〜（４）の周知事項においてバージョン管理の対象となるプログラムのソースファイルも、電子データであることには変わりないから、上記４．の（１）〜（４）の周知事項に見られる技術は、「１つ以上のセルファイルから構成された半導体設計ライブラリ」に対しても適用できることは、当業者にとって明らかであり、その場合、バージョン管理が行われる電子データの単位は、半導体設計ライブラリの「ライブラリ単位」となることは、当業者にとって明らかである。
　また、上記相違点１についての検討で示したとおり、引用例１記載の発明において、設計の対象となる電子データを「１つ以上のセルファイルから構成された半導体設計ライブラリ」とすることは、当業者が容易に想到し得ることである。
　してみれば、引用例１記載の発明において、上記４．の（１）〜（４）の周知事項を参酌することにより、「１つ以上のセルファイルから構成された半導体設計ライブラリをライブラリ単位でバージョン管理及びリリースを行い」、「使用する前記半導体設計ライブラリのバージョンを指定したバージョン管理ファイルを作成」するものとし、テンポラリディレクトリに登録するものを「バージョン管理ファイルで指定されたバージョンの半導体設計ライブラリ」とすることは、当業者が容易に想到し得ることである。
　
　そして、本願発明の構成によってもたらされる効果も、引用例１，２に記載の発明及び周知技術から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
７．むすび
　以上のとおり、本願発明は、引用例１，２に記載の発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　よって、結論のとおり審決する。