【事件の表示】
　特願２００４−　　３６０１「無共有型データベース管理システムにおけるシステム構成変更方法」拒絶査定不服審判事件〔平成１７年　７月２１日出願公開，特開２００５−１９６６０２〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成１６年１月９日の出願であって，平成２１年４月２１日付けの拒絶理由の通知に対し，同年６月２６日付けで意見書が提出されるとともに手続補正がなされ，同年９月３日付けの最後の拒絶理由の通知に対し，同年１１月６日付けで意見書が提出されたが，平成２２年１月２９日付けで拒絶査定がなされ，これに対して同年４月２７日に審判請求がなされ，平成２３年１１月８日付けの最後の拒絶理由の通知に対し，平成２４年１月１３日付けで意見書が提出されるとともに手続補正がなされたものである。
　
第２　平成２４年１月１３日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２４年１月１３日付けの手続補正（以下，「本件補正」という。）を却下する。
　
［理由］
１　補正の内容
（１）本件補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。（下線部は，補正箇所。）
　「複数のＣＰＵリソースと，データベースのデータを分散して格納する
予め細分化された
　前記仮想化層により前記複数のデータ領域を前記複数のＣＰＵリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ，前記複数のＣＰＵリソースの各々が，それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップと，
　新たなＣＰＵリソースを前記データベース管理システムに追加するステップと，
　前記複数のデータ領域のうち一部のデータ領域について，当該一部のデータ領域が関連付けられる仮想ボリュームを前記複数のＣＰＵリソースがアクセスする仮想ボリュームから前記新たなＣＰＵリソースがアクセスする仮想ボリュームに変更するステップと，
　を含むことを特徴とするデータベース管理システムのシステム構成変更方法。」
　
（２）上記補正は，補正前の請求項１に記載された発明を特定するために必要な事項である「データベースのデータを分散して格納する複数のデータ領域」を，「データベースのデータを分散して格納する
予め細分化された
　
２　補正の適否
　そこで，補正後の請求項１に記載された発明（以下，「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか否か（平成１８年改正前特許法１７条の２第５項において準用する同法１２６条５項の規定に適合するか否か）について以下に検討する。
（１）本願補正発明
　本願補正発明は，上記１に記載したとおりのものである。
　
（２）引用例
ア（ア）当審の拒絶理由で引用された，本願の出願日前に頒布された刊行物である特開平９−２１８８５８号公報（以下，「引用例」という。）には，図面とともに，次の事項が記載されている。
・発明の属する技術分野
　「【０００１】本発明は複数のプロセッサにデータが分散配置された分散型データベース管理システムに係り，特に，各々のプロセッサにおける処理負荷を容易に均等化する分散型データベース管理システムに関する。」
・発明が解決しようとする課題
　「【０００４】したがって本発明の目的は，上記の問題点を解決して，アクセス頻度の偏りに応じて各種データのプロセッサに対する分散配置を動的に変更し，複数のプロセッサの処理負荷を容易に均等化させることが可能な分散型データベース管理システムを提供することにある。」
・課題を解決するための手段
　「【０００５】上記の目的を達成するため，本発明の分散型データベース管理システムは，複数のプロセッサに分散配置された各種データへのアクセス要求があったとき，前記アクセス要求に応じた処理を所望のデータが配置されている特定のプロセッサで行う分散型データベース管理システムにおいて，個々のシステム資源に関するシステム資源情報，アクセス要求の発生頻度に関するデータアクセス統計情報，システム全体の処理負荷に関するシステム負荷統計情報に基づき，各プロセッサの処理負荷の偏りを検出する処理負荷偏り検出部と，各プロセッサの処理負荷の偏りを均等化させ得るデータの分散配置構成を前記処理負荷偏り検出部が検出した前記処理負荷の偏りから求め，所定のタイミングで前記分散配置構成の変更処理を行うデータ配置変更部と，を設ける構成としたものである。」
・実施形態の構成
　「【０００８】図１は，本発明の分散型データベース管理システムの実施の一形態の構成を示す図であり，図１（ａ）はシステム全体の物理的な構成を，図１（ｂ）は本発明に関わる主要部分の論理的な構成を，それぞれ示す。同図中，１はシステム全体を統括管理するシステム管理プロセッサ，２〜４はあらかじめ分散配置されたデータを個別に管理するデータ管理プロセッサ，５〜７は具体的なデータが格納されているディスク，８はシステム管理プロセッサ１およびすべてのデータ管理プロセッサ２〜４を相互に接続するネットワークである。また，１１はデータベース制御部，２１はシステム資源情報管理部，２２はシステム資源情報，３１はデータアクセス監視部，３２はデータアクセス統計情報，４１はシステム負荷監視部，４２はシステム負荷統計情報，５１は再配置実行制御部，６１は処理負荷偏り検出部，６２は再配置設計情報，７１はデータ配置変更部，７２は再配置データである。
【０００９】図１（ａ）において，システム管理プロセッサ１は，ネットワーク８を介して送信された処理要求を受け取ると，その処理内容を解析して複数のジョブに細分化した後，各々のデータ管理プロセッサ２〜４にこれらのジョブを送信する。ジョブを受信したデータ管理プロセッサ２〜４は，それぞれ管理が割り当てられたディスク５〜７内のデータを対象として上記ジョブによる実際的な処理を行い，求められた処理結果をシステム管理プロセッサ１へ返送する。
【００１０】図１（ｂ）において，データベース制御部１１は，図１（ａ）に示した物理システムとこれから述べる論理システムとのデータのやりとりを仲介する部分である。システム資源情報管理部２１は，データベース制御部１１を介して得られたディスクなどの二次記憶装置や各種プロセッサなどのシステム構成要素に関するシステム資源情報２２の管理を行う。データアクセス監視部３１は，データベース制御部１１を介してデータベース中の個々のデータへのアクセス状況を常時監視し，これに基づいてデータアクセス統計情報３２の記録を行う。システム負荷監視部４１は，データベース制御部１１を介してシステム全体に対する処理負荷の状態を常時監視し，これに基づいてシステム負荷統計情報４２の記録を行う。処理負荷偏り検出部６１は，上述したシステム資源情報２２およびデータアクセス統計情報３２に基づき，データアクセスが特に集中する傾向の強いプロセッサを検出するとともに，データ管理プロセッサ２〜４の各々に対する負荷をほぼ均一化し得るデータの分散配置を設計し，これを再配置設計情報６２として出力する。データ配置変更部７１は，データ管理プロセッサ２〜４の各々に対するデータの再配置に伴う各種の処理を，この再配置設計情報６２に基づいて行う。再配置実行制御部５１は，処理負荷偏り検出部６１およびデータ配置変更部７１の動作を統括制御するとともに，処理負荷偏り検出部６１およびデータ配置変更部７１とデータベース制御部１１との間のコマンドやデータのやりとりを仲介する。再配置データ７２は，データの再配置に伴う各種の処理中に発生する作業データである。」
・データの再配置処理動作の流れ
　「【００１２】図２および図３において，再配置実行制御部５１は，……再配置処理を開始し（ステップ２０１，３０２），最初に処理負荷偏り検出部６１を起動してシステム資源情報２２が具体的に記録されているシステム資源管理テーブル２２ａを読み込む（ステップ２０３）。次に，処理負荷偏り検出部６１は，アクセス履歴テーブル３２ａを読み込んで個々のデータ域に対するデータ負荷を算出し（ステップ２０４），さらに，得られたデータ負荷とシステム資源管理テーブル２２ａの情報から各々のデータ管理プロセッサに対するデータ負荷を算出した後（ステップ２０５），各プロセッサにおける処理負荷の偏りが存在するか否かの判定を行う（ステップ２０６）。……偏りが存在した場合（ステップ２０６＝Ｙｅｓ），処理負荷偏り検出部６１は，データ負荷とシステム資源管理テーブル２２ａの情報に基づいて各プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し，これを再配置設計情報６２として記録してから再配置実行制御部５１に処理を戻す（ステップ２０７）。
【００１３】続いて再配置実行制御部５１は，……再配置設計情報６２にしたがってデータ再配置の実行を開始する（ステップ２１１）。このとき，異なるデータ管理プロセッサ間で移動するデータについては，再配置データ７２として一時ファイルに格納した上で，データベースからは削除する。そして，データ配置変更部７１がデータベース制御部１１に対してデータ配置規則の変更指示を行った後，退避しておいた再配置データ７２を新たな配置規則にしたがって再びデータベースに登録する。」
　「【００２６】このほか，データ管理プロセッサの追加や削除については，処理負荷偏り検出部６１が，システム資源管理テーブル２２ａ中の変更情報２２a4を参照することによって構成変更の有無を確認する（ステップ２０３）。そして，構成変更があったことが確認された場合には無条件に負荷の偏りがあるものとみなし（ステップ２０６＝Ｙｅｓ），ステップ２０７〜２１１のデータ再配置処理を行う。変更がデータ管理プロセッサの追加であれば，処理負荷偏り検出部６１は，上述した（数式３）中のプロセッサ数に新たに追加したプロセッサ数を加えてデータ再配置設計を行い（ステップ２０７），これに基づいてデータ配置変更部７１は，新たなプロセッサにデータを割り当てるためのデータ再配置を実行する（ステップ２１１）。また，変更がデータ管理プロセッサの削除であれば，処理負荷偏り検出部６１は，上述した（数式３）中のプロセッサ数から削除すべきプロセッサ数を減じてデータ再配置設計を行い（ステップ２０７），これに基づいてデータ配置変更部７１は，削除するプロセッサにデータを割り当てないためのデータ再配置を実行する（ステップ２１１）。」
・発明の効果
　「【００２８】……本発明の分散型データベース管理システムによれば，システムの日常的な使用状況に基づくアクセス頻度の偏り，プロセッサの追加あるいは削除を伴うシステム構成の変更などに応じて，各種データのプロセッサに対する分散配置を動的に変更可能となり，運用の停止と煩雑な作業が必要なシステムの再構築を行うことなく，各プロセッサにおける処理負荷を容易に均等化させることができるという効果が得られる。」
　
（イ）上記記載から，引用例には，以下の技術的事項が記載されているということができる。
ａ　引用例に記載された技術は，データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムにおいて，データ管理プロセッサに対するデータの配置をアクセス頻度の偏りに応じて動的に変更し，複数のデータ管理プロセッサの処理負荷を均等化させることを目的とした技術である（【０００１】【０００４】）。
ｂ　分散型データベース管理システムは，システム全体を統括管理するシステム管理プロセッサ１，分散配置されたデータを個別に管理するデータ管理プロセッサ２〜４，及びデータが格納されているディスク５〜７を有し（【０００８】），システム管理プロセッサ１は，処理要求を受け取ると，複数のジョブに細分化した後，これらのジョブを各々のデータ管理プロセッサ２〜４に送信し，ジョブを受信したデータ管理プロセッサ２〜４は，それぞれ管理が割り当てられたディスク５〜７内のデータを対象として上記ジョブによる実際的な処理を行い，処理結果をシステム管理プロセッサ１へ返送する（【０００９】）。
ｃ　データの再配置処理は，各データ管理プロセッサにおける処理負荷に偏りが存在するか否かを判定し，偏りが存在した場合，各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し，データ再配置を実行するものである（【００１２】【００１３】）。
ｄ　ここで，データ管理プロセッサの追加があった場合は，処理負荷の偏りがあるものとみなし，追加したプロセッサ数を加えてデータ再配置設計を行い，これに基づいて，追加したデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行する（【００２６】）。
ｅ　データの再配置は，異なるデータ管理プロセッサ間で移動するデータを，再配置データ７２として一時ファイルに格納した上でデータベースから削除し，退避しておいた再配置データ７２を新たな配置規則に従って再びデータベースに登録することにより行われる（【００１３】）。
　
（ウ）これらのことから，引用例には，以下の発明（以下，「引用発明」という。）が記載されていると認められる。
　「システム全体を統括管理するシステム管理プロセッサ，分散配置されたデータを個別に管理する複数のデータ管理プロセッサ，及びデータが格納されているディスクを有し，データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムにおいて，
　各データ管理プロセッサにおける処理負荷の偏りが存在した場合，各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し，データ再配置を実行し，
　データ管理プロセッサの追加があった場合，処理負荷の偏りがあるものとみなし，新たに追加したプロセッサ数を加えてデータ再配置設計を行い，新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行するものであって，データ再配置は，異なるデータ管理プロセッサ間で移動するデータを，再配置データとして一時ファイルに格納した上でデータベースから削除し，退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われる，
　方法。」
　
イ（ア）当審の拒絶理由で引用された，本願の出願日前に頒布された刊行物である特開２００３−２９６１５３号公報（以下，「周知例１」という。）には，図面とともに，次の事項が記載されている。
　「【０００１】【発明の属する技術分野】本発明はネットワーク上でデータを保存するためのストレージシステムおよびそのためのプログラムに関し，……。」
　「【０００５】【発明が解決しようとする課題】（ｉ）ネットワークファイルサーバを複数設置したものでは，通常，負荷分散が必要となる状況下において，特定のファイルに負荷が集中する場合が考えられ，その対策としてファイルサーバを増設している。しかしながら，高負荷となったファイルサーバは，負荷が集中したファイルを増設したファイルサーバにコピーしなければならず，手間がかかりユーザからのストレージへのアクセスに対するレスポンスがその分遅れるという問題がある。」
　「【００１４】図１は本発明による一実施形態のストレージシステムの概略構成図である。図１全体に示すストレージシステム１００は，データの格納位置を管理するストレージ処理部１とデータをキャッシュメモリ等の小容量だが高速な記憶装置に一時記憶するデータ一時記憶部２とデータをハードディスク等の不揮発性の大容量だが低速の記憶装置に蓄積するデータ蓄積部３とを有する。ストレージ処理部１，データ一時記憶部２およびデータ蓄積部３はそれぞれ複数個……設けられ，インタコネクト（ＩＮＦＩＮＩバンド）やＬＡＮ等の高速なネットワーク４を介して互いに分散配置されている。」
　「【００１６】ストレージ処理部１は，ネットワーク４に接続された複数のクライアント５の何れか１つのクライアントからデータ一時記憶部２またはデータ蓄積部３に記憶されているデータの送信が要求されると当該データを記憶しているデータ一時記憶部２またはデータ蓄積部３のどこに記憶されているかを検索し，検索したデータをクライアント５に送信する制御を行う。」
　「【００１８】ストレージ処理部１は，仮想ストレージ管理部１０，処理負荷計測部１１，処理分割　統合判定部１２，処理ノード選択部１３，処理負荷通知部１４，制御部１５および通信部１６を有し，また仮想ストレージ管理テーブル２０および処理負荷計測テーブル３０を有する。」
　「【００２６】仮想ストレージ管理テーブル２０は，仮想ストレージと実ストレージとの対応関係を記憶するテーブルである（図５，６，８参照）。……」
　「【００３６】図４は図２における仮想ストレージ分割処理のフローチャートであり，図５および図６は仮想ストレージ管理テーブル内のデータが分割処理により変更される第１および第２の具体例を示す図であり，（Ａ）は分割処理前のテーブルを示す図であり，（Ｂ）は分割処理後のテーブルを示す図である。
【００３７】（ｉ）マスタストレージ処理部の負荷が上限閾値を超えた場合
まず，ステップＳ２０でマスタストレージ処理部１（番号０）の処理ノード選択部１３は，スレーブストレージ処理部１（番号１）に対して負荷の問合せする。スレーブストレージ処理部１の処理負荷通知部１４はこの問合せを受けて，処理負荷計測テーブル３０に格納されている処理負荷値を通知する。
【００３８】ストレージ処理部が他にある場合は，それらをスレーブストレージ処理部とみなし，同様の処理を行う。
【００３９】ステップＳ２１でマスタストレージ処理部１（番号０）は，通知された処理負荷値に基づき，処理負荷値が最も低いスレーブストレージ処理部１（番号１）をここでは選択する。
【００４０】ステップＳ２２でマスタストレージ処理部１（番号０）は，選択されたスレーブストレージ処理部１（番号１）に現在担当している仮想ストレージ処理（番号１）を分割するため仮想ストレージ管理テーブル２０の書換えを行う。その様子を図５に示す。図５の（Ａ）に示す分割処理前の仮想ストレージ管理テーブル２０から判るように，仮想ストレージ（番号１）の処理は，現在マスタストレージ処理部１（番号０）で実行されているが，この処理をスレーブストレージ処理部１（番号１）に分割するものとする。この分割処理を行った後の仮想ストレージ管理テーブル２０を図５の（Ｂ）に示す。……
【００４１】ステップＳ２３でマスタストレージ処理部１（番号０）は，分割後の仮想ストレージ管理テーブル２０にしたがいステップＳ２１で選択されたスレーブストレージ処理部１（番号１）に処理を依頼する。スレーブストレージ処理部１（番号１）はこれを受けて依頼された処理を実行する。」
　また，図面の図１には，ネットワーク４に，それぞれ複数のストレージ処理部１，データ一時記憶部２，データ蓄積部３，及びクライアント５が接続された構成が示されている。
　
（イ）上記記載によれば，周知例１には，（ａ）ネットワークに接続された複数のストレージを，複数のクライアントが共有する技術，及び（ｂ）ネットワーク上でデータを保存するためのストレージシステムにおいて，ストレージ処理部の負荷が上限閾値を超えた場合，処理負荷値が最も低いストレージ処理部を選択し，仮想ストレージ管理テーブルの書換えを行うことにより，現在担当している仮想ストレージ処理を分割し，分割後の仮想ストレージ管理テーブルに基づき，選択されたストレージ処理部に処理を依頼する技術が記載されていると認められる。
　
ウ（ア）当審の拒絶理由で引用された，本願の出願日前に頒布された刊行物である特開２００３−２０２９６４号公報（以下，「周知例２」という。）には，図面とともに，次の事項が記載されている。
　「【０００１】【発明の属する技術分野】本発明は，計算機システムの制御方法，計算機システム，記憶装置の制御方法及び記憶装置に係り，特に，バックアップ処理等を伴う仮想化されたボリュームのスナップショットを作成する情報処理システムの制御方法，計算機システム，記憶装置の制御方法及び記憶装置に関する。」
　「【０００６】その１つの例は，ホストコンピュータと記憶装置システムとの間に仮想化を実現するサーバが接続され，前記サーバが，１つまたは複数の物理的ボリュームの領域をホストコンピュータに対しアドレス変換することにより仮想化ボリュームを生成して，物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し，ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換して，ホストコンピュータによるアクセス要求を処理するというものである。……
【０００７】前述した２つの例は，いずれも，物理的ボリュームの領域と仮想化ボリュームの領域との対応情報を保持して，物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理する手段を備えるものである。
【０００８】……また、複数の物理的ボリュームは、それぞれ異なる複数の記憶装置システムに属していてもよい。」
　「【００１３】【課題を解決するための手段】本発明によれば前記目的は、１つまたは複数の記憶装置と、前記記憶装置の１つまたは複数の記憶領域を提供する１つまたは複数の制御装置と、前記記憶領域を仮想化した記憶領域を提供するための情報を管理する計算機とを備える計算機システムの制御方法において、前記計算機が有する前記記憶領域を提供するための情報が、前記記憶装置が提供する記憶領域と前記仮想化した記憶領域との対応情報を含み、前記制御装置が、前記計算機が有する前記対応情報の全体または一部を保持して前記１つまたは複数の記憶装置の制御を行うことにより達成される。」
　また，図面の図１には，ネットワーク６００に，複数のホスト２００及び記憶装置３００が接続された構成が示されている。
　
（イ）上記記載によれば，周知例２には，（ａ）ネットワークに接続された複数の記憶装置を，複数のホストが共有する技術，及び（ｂ）ホストコンピュータと記憶装置システムとの間に接続されたサーバが，１又は複数の物理的ボリュームの領域をアドレス変換することにより仮想化ボリュームを生成し，物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し，ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換する技術が記載されていると認められる。
　
（３）引用発明との対比
ア　本願補正発明と引用発明とを対比する。
（ア）引用発明は，データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムであって，データ管理プロセッサによって，分散配置されたデータを個別に管理し，管理が割り当てられたディスク５〜７内のデータを対象として実際的な処理を行うものであるから，引用発明の「データ管理プロセッサ」は，本願補正発明の「ＣＰＵリソース」に相当する。また，「ディスク５〜７」は，本願補正発明と対応させれば，「データベースのデータを分散して格納する複数のデータ領域」としての機能を備えた「ストレージ」ということができる。
　したがって，本願補正発明と引用発明とは，「複数のＣＰＵリソースと，データベースのデータを分散して格納する複数のデータ領域を有するストレージと，を有するデータベース管理システム」である点で一致する。
　
（イ）引用発明は，前記のとおり，データ管理プロセッサが，分散配置されたデータを個別に管理するものであって，各データ管理プロセッサにおける処理負荷の偏りが存在した場合，各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し，データ再配置を実行するものであり，データベースのデータを分散して格納する複数のデータ領域は，各データ管理プロセッサに重複しないように関連づけれられているということができるから，本願補正発明と同様に，「データベース管理システムにおけるシステム構成変更方法」ということができ，本願補正発明の，「仮想化層により複数のデータ領域を複数のＣＰＵリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ，複数のＣＰＵリソースの各々が，それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップ」と対比すれば，両者は，「複数のデータ領域を複数のＣＰＵリソースに重複しないように関連づけ，前記複数のＣＰＵリソースの各々が，関連付けられたデータ領域のデータを処理するステップ」を有する点で共通する。
　
（ウ）引用発明は，データ管理プロセッサの追加があった場合，処理負荷の偏りがあるものとみなし，新たに追加したプロセッサ数を加えてデータ再配置設計を行い，新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行するものであり，本願補正発明の，「新たなＣＰＵリソースをデータベース管理システムに追加するステップ」及び「複数のデータ領域のうち一部のデータ領域について，当該一部のデータ領域が関連付けられる仮想ボリュームを複数のＣＰＵリソースがアクセスする仮想ボリュームから新たなＣＰＵリソースがアクセスする仮想ボリュームに変更するステップ」と対比すれば，本願補正発明における，データ領域が関連付けられる仮想ボリュームの変更は，ＣＰＵリソースに関連づけられたデータ領域を変更することにほかならないから，両者は，「新たなＣＰＵリソースをデータベース管理システムに追加するステップ」及び「複数のデータ領域のうち一部のデータ領域について，当該一部のデータ領域が関連付けられるデータ領域を複数のＣＰＵリソースがアクセスするデータ領域から新たなＣＰＵリソースがアクセスするデータ領域に変更するステップ」を有する点で共通する。
　
イ　以上のことから，本願補正発明と引用発明との一致点及び相違点は，次のとおりである。
　【一致点】
　複数のＣＰＵリソースと，データベースのデータを分散して格納する複数のデータ領域を有するストレージと，を有するデータベース管理システムであって，
　データベース管理システムにおけるシステム構成変更方法であって，
　前記複数のデータ領域を前記複数のＣＰＵリソースに重複しないように関連づけ，前記複数のＣＰＵリソースの各々が，関連付けられたデータ領域のデータを処理するステップと，
　新たなＣＰＵリソースを前記データベース管理システムに追加するステップと，
　前記複数のデータ領域のうち一部のデータ領域について，当該一部のデータ領域が関連付けられるデータ領域を前記複数のＣＰＵリソースがアクセスするデータ領域から前記新たなＣＰＵリソースがアクセスするデータ領域に変更するステップと，
　を含むデータベース管理システムのシステム構成変更方法。
　【相違点１】
　本願補正発明のデータベース管理システムは，「ＣＰＵリソースとストレージとを接続するネットワーク」を有するのに対し，引用発明は，当該構成が特定されていない点。
　【相違点２】
　本願補正発明のストレージは，「予め細分化された複数のデータ領域を有し，複数のＣＰＵリソースから共有される」ものであるのに対し，引用発明のストレージは，ＣＰＵリソース（データ管理プロセッサ）に管理が割り当てられたディスクであり，複数のデータ領域を有するものの，「予め細分化」されていること，及び「複数のＣＰＵリソースから共有される」ことは，明示されていない点。
　【相違点３】
　本願補正発明は，データベース管理システムが，データベース管理システム内に，複数のＣＰＵリソースがアクセスする仮想的な記憶装置である仮想ボリュームに複数のデータ領域のいずれかを関連付けることにより複数のＣＰＵリソースからデータ領域へのアクセスを可能とする仮想化層を有し，仮想化層により複数のデータ領域を複数のＣＰＵリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ，複数のＣＰＵリソースの各々が，それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するものであって，新たなＣＰＵリソースをデータベース管理システムに追加する場合，一部のデータ領域が関連付けられる仮想ボリュームを複数のＣＰＵリソースがアクセスする仮想ボリュームから新たなＣＰＵリソースがアクセスする仮想ボリュームに変更することによりデータ再配置を行うのに対し，引用発明は，上記「仮想化層」に相当する構成を有しておらず，データ再配置は，異なるデータ管理プロセッサ間で移動するデータを，再配置データとして一時ファイルに格納した上でデータベースから削除し，退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われる点。
　
（４）判断
　以下，相違点について検討する。
ア　相違点１について
　データベースシステム等のコンピュータシステムにおいて，ＣＰＵリソースとストレージとをネットワークで接続することは，例えば，周知例１，２に記載されているように，周知の技術手段であり，引用発明において，当該構成を採用することは，当業者が適宜なし得ることである。
　
イ　相違点２について
　データベースシステム等のコンピュータシステムにおいて，ストレージを複数のＣＰＵリソースにより共有することは，例えば，周知例１，周知例２及び本願の出願日前に頒布された刊行物である特開２００３−８５０１４号公報（以下，「周知例３」という。）に記載されており，また，ストレージを予め複数のデータ領域に細分化しておくことも，例えば，周知例３に記載されており，いずれも周知の技術手段である。
　引用発明において，上記周知の技術手段に係る構成を採用することは，当業者が容易に想到し得たものである。
　
・周知例３（特開２００３−８５０１４号公報）
　周知例３には，次の記載があり，複数の計算機がネットワークを介して複数の記憶装置をアクセスするネットワークシステムにおいて，ボリューム管理テーブルに，各計算機における論理アドレス領域と各記憶装置の物理領域との関係，及び各入出力計算機のネットワーク上の位置と，各計算機のネットワーク上の位置とを登録し，管理すること（下記記載事項ａ），及び記憶装置の物理ボリュームを，物理エクステントに分割し，ボリューム管理テーブルに，論理ボリュームと，物理ボリュームと，物理エクステントとの関係を記憶すること（下記記載事項ｂ）が記載されている。
ａ　「【０００１】【発明の属する技術分野】本発明は，計算機がネットワークを介して記憶装置をアクセスするネットワークシステムにおける記憶装置のボリューム管理を行うネットワークシステムのボリューム管理方法及び計算機に関する。」
　「【００１３】また，別の発明は，複数の計算機がネットワークを介して複数の記憶装置をアクセスするネットワークシステムにおける各記憶装置のボリューム管理を行うネットワークシステムのボリューム管理方法において，各記憶装置とネットワークとの間に記憶装置に対するデータの入出力を行う入出力計算機を設け，各計算機のネットワーク上の位置と，各入出力計算機のネットワーク上の位置と，各計算機における論理アドレス領域と各記憶装置の物理領域との関係とを記憶するボリューム管理テーブルを設け，各計算機において論理アドレスを指定したアクセス要求に応じて，ボリューム管理テーブルの指定する入出力計算機に接続された記憶装置における論理アドレスが指定する物理領域をアクセスする。
【００１４】このように構成されたネットワークシステムのボリューム管理方法においては，ボリューム管理テーブルに，各計算機における論理アドレス領域と各記憶装置の物理領域との関係の他に，各入出力計算機のネットワーク上の位置と，各計算機のネットワーク上の位置とを登録している。
【００１５】したがって，このボリューム管理テーブルを参照することによって，各計算機は自己の論理アドレスに割当てられた記憶装置の物理領域をアクセスすることが可能となり，結果として，複数の計算機と複数の記憶装置が接続されたネットワークシステムにおけるボリューム管理を実現できる。」
ｂ　「【００３０】物理ボリュームと物理エクステントとの関係を図１を用いて説明する。物理ボリューム（ＰＶ）とは，現実の記憶媒体を示し，この実施形態ではＨＤＤ等の物理ディスクである。また，物理エクステント（ＰＥ）とは物理ボリューム（ＰＶ）を数ＭＢ（メガ　バイト）の大きさに分割した物理領域であり，この実施形態のボリューム管理方式における最小の単位である。また，物理ボリューム（ＰＶ）と物理エクステント（ＰＥ）はラベル付けされている。
【００３１】図１においては，それぞれラベルがＰＶ０，ＰＶ１である２台の物理ボリューム（物理ディスク）１ａ，１ｂが設けられ，各物理ボリューム１ａ，１ｂは，それぞれラベルがＰＥ１，ＰＥ２，ＰＥ３，…，ＰＥｎであるｎ個の物理エクステント（ＰＥ）２ａ，２ｂで構成されている。
【００３２】図２にボリューム管理テーブル３を示す。このボリューム管理テーブル３内には，論理ボリューム（ＬＶ）４と，物理ボリューム（ＰＶ）１ａ，１ｂと，物理エクステント（ＰＥ）２ａ，２ｂとの関係が記憶されている。
【００３３】論理ボリューム（ＬＶ）４とは，計算機が指定する論理アドレス領域を示す。この実施形態のボリューム管理テーブル３には，それぞれラベルＶｏl１，Ｖｏl２，Ｖｏl３の３個の論理ボリューム（ＬＶ）４が登録され，各論理ボリューム（ＬＶ）４に対して，実際の物理ボリューム（ＰＶ）１ａ，１ｂと，物理エクステント（ＰＥ）２ａ，２ｂとが割り付けられている。」
　
ウ　相違点３について
（ア）周知例１には，前記（２）イ（イ）のとおり，ネットワーク上でデータを保存するためのストレージシステムにおいて，ストレージ処理部の負荷が上限閾値を超えた場合，処理負荷値が最も低いストレージ処理部を選択し，仮想ストレージ管理テーブルの書換えを行うことにより，現在担当している仮想ストレージ処理を分割し，分割後の仮想ストレージ管理テーブルに基づき，選択されたストレージ処理部に処理を依頼する技術が記載されている。
　また，周知例２には，前記（２）ウ（イ）のとおり，ホストコンピュータと記憶装置システムとの間に接続されたサーバが，１又は複数の物理的ボリュームの領域をアドレス変換することにより仮想化ボリュームを生成し，物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し，ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換する技術が記載されている。
　周知例１，２に記載された事項から，本願出願前において，ストレージを仮想化して管理することは，周知の技術手段であったということができ，また，当該技術手段によれば，データの移動を行うことなくデータの再配置を行うことができるという作用効果を奏することは，周知例１の段落【０００５】に示唆されているように，当業者にとって自明である。
（イ）引用発明には，データ管理プロセッサの追加があった場合に，新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置は，異なるデータ管理プロセッサ間で移動するデータを，再配置データとして一時ファイルに格納した上でデータベースから削除し，退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われるものであるが，上記のとおり，ストレージを仮想化して管理し，データの移動を行うことなくデータの再配置を行う技術が周知であったことに鑑みれば，引用発明において，データ再配置のための手段として，上記周知の技術手段を採用し，相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
エ　そして，これらの相違点を総合的に勘案しても，本願補正発明の奏する作用効果は，引用例に記載された発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願補正発明は，引用例に記載された発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により，特許出願の際独立して特許を受けることができないものである。
　
（５）本件補正についてのむすび
　よって，本件補正は，平成１８年改正前特許法１７条の２第５項において準用する同法１２６条５項の規定に違反してなされたものであるから，同法１５９条１項において読み替えて準用する同法５３条１項の規定により却下すべきものである。
　
第３　本願発明について
１　本願発明
　平成２４年１月１３日付けの手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成２１年６月２６日付け手続補正書の特許請求の範囲の請求項１ないし３に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，平成２１年６月２６日付けの手続補正書によって補正された明細書及び図面の記載からみて，その請求項１に記載された事項により特定される，次のとおりのものである。
　「複数のＣＰＵリソースと，データベースのデータを分散して格納する複数のデータ領域を有し，前記複数のＣＰＵリソースから共有されるストレージと，前記複数のＣＰＵリソースと前記ストレージとを接続するネットワークと，を有するデータベース管理システムであって，前記データベース管理システム内に，前記複数のＣＰＵリソースがアクセスする仮想的な記憶装置である仮想ボリュームに前記複数のデータ領域のいずれかを関連付けることにより前記複数のＣＰＵリソースから前記データ領域へのアクセスを可能とする仮想化層を有するデータベース管理システムにおけるシステム構成変更方法であって，
　前記仮想化層により前記複数のデータ領域を前記複数のＣＰＵリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ，前記複数のＣＰＵリソースの各々が，それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップと，
　新たなＣＰＵリソースを前記データベース管理システムに追加するステップと，
　前記複数のデータ領域のうち一部のデータ領域について，当該一部のデータ領域が関連付けられる仮想ボリュームを前記複数のＣＰＵリソースがアクセスする仮想ボリュームから前記新たなＣＰＵリソースがアクセスする仮想ボリュームに変更するステップと，
　を含むことを特徴とするデータベース管理システムのシステム構成変更方法。」
　
２　当審の拒絶理由の概要
　当審において平成２３年１１月８日付けで通知した最後の拒絶理由の概要は，本願発明は，特開平９−２１８８５８号公報（引用例）に記載された発明，及び特開２００３−２９６１５３号公報（周知例１）並びに特開２００３−２０２９６４号公報（周知例２）に記載された周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。
　
３　引用例
　引用例及び周知例１，２の記載事項は，前記第２の［理由］２（２）に記載したとおりである。
　
４　対比　判断
　本願発明は，前記第２の［理由］２で検討した本願補正発明から，「予め細分化された」との限定事項を削除したものである。
　そうすると，本願発明の発明特定事項を全て含み，さらに他の事項を付加したものに相当する本願補正発明が，前記第２の［理由］２（３），（４）に記載したとおり，引用例に記載された発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，同様の理由により，引用例に記載された発明及び周知技術に基づいて，当業者が容易に発明することができたものである。
　
５　むすび
　以上のとおり，本願発明は，引用例に記載された発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により特許を受けることができないから，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　よって，結論のとおり審決する。