【事件の表示】
　平成　４年特許願第１７１１６６号「コンピュータシステムの論理ボリューム構成制御方法」拒絶査定に対する審判事件［平成　６年　１月２８日出願公開、特開平　６−　１９６８８］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明　
　本願は、平成４年６月２９日の出願であって、その請求項１に係る発明は、平成１４年７月１５日付で補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載されたとおりの次のもの（以下、「本願発明」という。）である。
　
「【請求項１】電源投入時に、プログラム制御機能をもつ本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルを作成するコンピュータシステムの論理ボリューム構成制御方法において、　
　前記システム構成テーブルは、本体装置に接続されている周辺装置の識別名とそれに格納されている論理ボリュームの識別名とを登録するように構成し、　
　電源投入時に前記システム構成テーブルを作成した後の運用中に、プログラムのローディング処理が行なわれる都度、本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルと照合し、不一致が見出された場合には、システム構成テーブルの内容をそのとき実際に接続されている周辺装置の識別名およびそれに格納されている論理ボリュームの識別名と一致するように自動修正することを特徴とするコンピュータシステムの論理ボリューム構成制御方法。」　
　
２．刊行物　
　これに対して、原査定及び前置審査の拒絶の理由に引用された刊行物である特開昭６０−２５８６４５号公報（昭和６０年１２月２０日出願公開、以下、「刊行物１」という。）、本願出願前に頒布された刊行物である特開昭５４−７０７４０号公報（昭和５４年６月６日出願公開、以下、「刊行物２」という。）、同特開昭６３−１９６９３６号公報（昭和６３年８月１５日出願公開、以下、「刊行物３」という。）には、それぞれ図面とともに以下のことが記載されている。　
　
［刊行物１］　
（Ａ）「２．特許請求の範囲　
１．複数の装置からなるシステムであってシステム資源状態管理情報を保持するシステムにおいて，・・・前記システム資源状態管理情報を修正する手段とを備え，任意の装置を該システムに接続する際に，・・・該装置の機能動作が正常であれば，前記管理情報修正手段によって前記システム資源状態管理情報に登録することにより，該任意装置を該システムに組込むことを特徴とする情報処理システム」（・・・は引用箇所の省略を意味し、以下、同様とする。）（公報１頁左下欄４行〜１６行）　
　
（Ｂ）「［従来技術］　
　システム資源状態管理情報とは，・・・各装置５０〜６２の装置形式，構成等を記述した一種のテーブルである。」（公報１頁右下欄６行〜１１行）
　
（Ｃ）「［実施例］　
　・・・ディスク制御装置７とディスク装置１０を増設する場合を想定する。」（公報２頁右上欄１４行〜１９行）　
　
（Ｄ）「本システムを立上げる時に，システム制御装置１はシステム初期設定プログラムをディスク装置９からメモリ装置４へロードし，本プログラムによってシステム立上げが管理される。　
　初期設定プログラムが正常にロードされると，システム制御装置１は診断パス２０１を使用して実装置構成を調べる。そして，前記システム資源状態管理情報にない装置，パスが存在すると，・・・動作確認プログラムをローカルメモリ５からとりだしてメモリ装置４へロードする。・・・　
　・・・　
　上記のプログラムが正常に終了すると，・・・，システム資源状態管理情報に動作確認エリア内の情報を追加する。　
　・・・　
　すべてのシステム資源状態管理情報にない装置，パスの確認が終了し，修正されたシステム資源状態管理情報を用いてシステム制御装置１はシステム立上げ動作を続行する。」（公報２頁左下欄６行〜３頁左上欄６行）　
　
（Ｅ）「上記のようにしてシステム立上げ時において，本発明のシステムは，システム資源状態管理情報を自動修正して増設装置をくみこむことができる。また，システム運用中においても，初期設定プログラムではなく運用中の増設プログラムによって上記動作を同一に行い，自動的にくみこむことが可能である。」（公報３頁左上欄１３行〜１８行）　
　
（Ｆ）「さらに，本実施例ではシステム制御装置１がローカルエリアメモリ５上でシステム資源状態管理情報を修正しているが，中央処理装置２がメモリ装置４のシステム固有エリアにて修正を行っても同じことであり，・・・」（公報３頁左上欄１９行〜右上欄５行）　
　
（Ｇ）又、第２図には、システム資源状態管理情報に装置のシステム内名称が登録されることが記載されている。　
　
　上記（Ａ）〜（Ｇ）を勘案すると、刊行物１には、　
　
　システム立上げ時に、中央処理装置とディスク装置の実装置構成を調べてシステム資源状態管理情報のテーブルを修正する情報処理システムの任意装置の組込み方法において、　
　前記システム資源状態管理情報のテーブルは、接続されたディスク装置のシステム内名称を登録するように構成され、　
　システム立上げ時に前記システム資源状態管理情報のテーブルを修正した後のシステム運用中に、増設プログラムによって、中央処理装置とディスク装置の実装置構成を調べて、前記システム資源状態管理情報のテーブルにない場合には、前記システム資源状態管理情報のテーブルを自動修正する　
情報処理システムの任意装置の組込み方法（以下、刊行物１発明という。）
　
が記載されているものと認められる。　
　
［刊行物２］　
（Ｈ）「従来から磁気テープ装置，磁気ディスク・パック装置，磁気ドラム装置などの磁気記録装置に対応して機番がもうけられ，該機番にもとずいてシステム構成を管理する方式が採用されていた。しかし，例えばバンキング・システムなどのオンライン・システムにおいては，数百台の磁気記録装置が使用されるようになり，各磁気記録装置に現実に装着された磁気記録媒体自体を例えばボリューム番号やファイル名によって管理されるようになつてきた。即ち，１つの磁気記録装置に或る磁気記録媒体が装着されると，中央処理装置は自動ボリューム番号識別機能（ＡＶＲ機能）によって当該磁気記録媒体上に記録されているボリューム番号を読取って或るボリューム番号をもつ記録媒体がどの磁気記録装置に装着されているかを自動的にチェックしたり，あるいはコンソールにおいてプリント・アウトしたりすることが行われるようになってきた。」（公報２頁左上欄８行〜右上欄４行）　
　
［刊行物３］　
（Ｉ）「電源投入後に実行プログラム３を起動する起動コマンド１が投入されると（ステップ１１）、・・・　
　・・・実行プログラム３が使用するシステムの構成要素が実行プログラム３を動作させるシステムの構成要素にすべて含まれてているか否かを判定する（ステップ１５）。　
　実行プログラム３が使用するシステムの構成要素が実行プログラム３を動作させるシステムの構成要素にすべて含まれていれば、ロード手段７により実行プログラム３のプログラム本体３２をロードし（ステップ１６）、実行プログラム３を起動させる（ステップ１７）。」（公報３頁左下欄４行〜右下欄７行）　
　
３．対比　
　本願発明と刊行物１発明を対比する。　
（１）刊行物１発明の「中央処理装置」、「情報処理システム」は、それぞれ本願発明の「本体装置」、「コンピュータシステム」に対応する。　
　
（２）ディスク装置が論理ボリュームが格納されるものであることは当業者にとって自明の事項であり、してみれば、刊行物１発明の「ディスク装置」は本願発明の「論理ボリュームが格納されている周辺装置」に対応し、さらに、刊行物１発明の「ディスク装置のシステム内名称」は本願発明の「周辺装置の識別名」に対応する。　
　
（３）又、刊行物１発明の「システム資源状態管理情報のテーブル」と本願発明の「システム構成テーブル」は、本体装置に接続されている周辺装置の識別名を登録するように構成されるものである点では対応する。　
　
（４）又、刊行物１発明の「システム立上げ時」と本願発明の「電源投入時」は、いずれもシステム起動時である点では対応する。　
　
（５）刊行物１発明のシステム立上げ時に前記システム資源状態管理情報のテーブルを修正した後のシステム運用中に、増設プログラムによって、中央処理装置とディスク装置の実装置構成を調べて、前記システム資源状態管理情報のテーブルにない場合には、前記システム資源状態管理情報のテーブルを自動修正することは、言い換えれば、システム立上げ時に実装置構成として実際に接続されており、かつシステム資源状態管理情報のテーブルには存在しないディスク装置については、システム内名称を含む当該ディスク装置に関する管理情報が新たに作成され、さらに、その後の運用中においても、実装置構成を調べて、当該実装置構成とシステム資源状態管理情報のテーブルの管理情報が整合しているか否かを判断して、不整合の場合にはシステム資源状態管理情報のテーブルの内容をそのとき実際に接続されているディスク装置のシステム内名称となるように自動修正するということである。　
　
　してみれば、刊行物１発明の「システム立上げ時に前記システム資源状態管理情報のテーブルを修正した後のシステム運用中に、増設プログラムによって、中央処理装置とディスク装置の実装置構成を調べて、前記システム資源状態管理情報のテーブルにない場合には、前記システム資源状態管理情報のテーブルを自動修正する」ことと、本願発明の「電源投入時に前記システム構成テーブルを作成した後の運用中に、プログラムのローディング処理が行なわれる都度、本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルと照合し、不一致が見出された場合には、システム構成テーブルの内容をそのとき実際に接続されている周辺装置の識別名およびそれに格納されている論理ボリュームの識別名と一致するように自動修正する」ことは、システム起動時に前記システム構成テーブルを作成した後の運用中に、本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルと照合し、不一致が見出された場合には、システム構成テーブルの内容をそのとき実際に接続されている周辺装置の識別名と一致するように自動修正することである点では対応する。　
　
　　したがって、本願発明と刊行物１発明は、　
　
　システム起動時に、プログラム制御機能をもつ本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルを作成するコンピュータシステムの構成制御方法において、　
　前記システム構成テーブルは、本体装置に接続されている周辺装置の識別名を登録するように構成し、　
　システム起動時に前記システム構成テーブルを作成した後の運用中に、本体装置と論理ボリュームが格納されている周辺装置との接続状態を調べてシステム構成テーブルと照合し、不一致が見出された場合には、システム構成テーブルの内容をそのとき実際に接続されている周辺装置の識別名と一致するように自動修正する　
　コンピュータシステムの構成制御方法　
　
である点で一致し、次の点で相違する。　
　
［相違点１］　
　システム起動時が、　
　本願発明では電源投入時であるのに対して、　
　刊行物１発明ではシステム立上げ時である点。　
　
［相違点２］　
　システム構成テーブルに登録されるものが、　
　本願発明では、周辺装置の識別名とそれに格納されている論理ボリュームの識別名であるのに対して、　
　刊行物１発明では、周辺装置の識別名である点。　
　
［相違点３］　
　運用中にシステム構成テーブルの自動修正を、　
　本願発明では、プログラムのローディング処理が行われる都度行うのに対して、　
　刊行物１発明では、増設プログラムにより行う点。　
　
４．相違点についての判断　
　上記相違点について検討する。　
　
［相違点１について］　
　システムの起動を電源投入により行うことは本願出願前周知の技術であるから、相違点１は格別の差異ではない。　
　
［相違点２について］　
　例えば刊行物２に記載されているように、周辺装置の識別名に対応する機番とあわせて、ボリュームの識別名に対応するボリューム番号によりシステム構成を管理することは、本願出願前周知の技術であるから、上記周知の技術を参酌して、刊行物１発明において、システム構成テーブルに登録されるものを、周辺装置の識別名とそれに格納されている論理ボリュームの識別名とすることは、当業者が容易になし得るものである。　
　
［相違点３について］　
　刊行物１発明においては、運用中にシステム構成テーブルの自動修正を、増設プログラムにより、すなわち周辺装置の増設時に行っている。　
　
　しかしながら、例えば刊行物３に記載されているように、プログラムのローディング処理が行われる時に、そのとき実際に接続されている最新のシステム構成を認識する必要があること、又、プログラムのローディング処理を契機としてシステム構成の判定を行うことは本願出願前周知の技術であり、してみれば、上記周知の技術を参酌して、刊行物１発明において、運用中にシステム構成テーブルの自動修正を、増設時ではなくて、プログラムのローディング処理が行われる都度行うようにすることは当業者が容易になし得るものである。　
　
５．むすび　
　以上のとおり、本願発明は、刊行物１〜３に記載された発明及び周知の技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。　
　
　よって、結論のとおり審決する。