• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1255408
審判番号 不服2010-8972  
総通号数 150 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-06-29 
種別 拒絶査定不服の審決 
審判請求日 2010-04-27 
確定日 2012-04-12 
事件の表示 特願2004- 3601「無共有型データベース管理システムにおけるシステム構成変更方法」拒絶査定不服審判事件〔平成17年 7月21日出願公開,特開2005-196602〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯
本願は,平成16年1月9日の出願であって,平成21年4月21日付けの拒絶理由の通知に対し,同年6月26日付けで意見書が提出されるとともに手続補正がなされ,同年9月3日付けの最後の拒絶理由の通知に対し,同年11月6日付けで意見書が提出されたが,平成22年1月29日付けで拒絶査定がなされ,これに対して同年4月27日に審判請求がなされ,平成23年11月8日付けの最後の拒絶理由の通知に対し,平成24年1月13日付けで意見書が提出されるとともに手続補正がなされたものである。

第2 平成24年1月13日付けの手続補正についての補正却下の決定
[補正却下の決定の結論]
平成24年1月13日付けの手続補正(以下,「本件補正」という。)を却下する。

[理由]
1 補正の内容
(1)本件補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。(下線部は,補正箇所。)
「複数のCPUリソースと,データベースのデータを分散して格納する予め細分化された複数のデータ領域を有し,前記複数のCPUリソースから共有されるストレージと,前記複数のCPUリソースと前記ストレージとを接続するネットワークと,を有するデータベース管理システムであって,前記データベース管理システム内に,前記複数のCPUリソースがアクセスする仮想的な記憶装置である仮想ボリュームに前記複数のデータ領域のいずれかを関連付けることにより前記複数のCPUリソースから前記データ領域へのアクセスを可能とする仮想化層を有するデータベース管理システムにおけるシステム構成変更方法であって,
前記仮想化層により前記複数のデータ領域を前記複数のCPUリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ,前記複数のCPUリソースの各々が,それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップと,
新たなCPUリソースを前記データベース管理システムに追加するステップと,
前記複数のデータ領域のうち一部のデータ領域について,当該一部のデータ領域が関連付けられる仮想ボリュームを前記複数のCPUリソースがアクセスする仮想ボリュームから前記新たなCPUリソースがアクセスする仮想ボリュームに変更するステップと,
を含むことを特徴とするデータベース管理システムのシステム構成変更方法。」

(2)上記補正は,補正前の請求項1に記載された発明を特定するために必要な事項である「データベースのデータを分散して格納する複数のデータ領域」を,「データベースのデータを分散して格納する予め細分化された複数のデータ領域」と補正するものであり,「複数のデータ領域」について「予め細分化された」との限定を付加するものであって,平成18年法律第55号改正附則3条1項によりなお従前の例によるとされる同法による改正前の特許法(以下,「平成18年改正前特許法」という。)17条の2第4項2号の特許請求の範囲の減縮を目的とするものに該当する。

2 補正の適否
そこで,補正後の請求項1に記載された発明(以下,「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか否か(平成18年改正前特許法17条の2第5項において準用する同法126条5項の規定に適合するか否か)について以下に検討する。
(1)本願補正発明
本願補正発明は,上記1に記載したとおりのものである。

(2)引用例
ア(ア)当審の拒絶理由で引用された,本願の出願日前に頒布された刊行物である特開平9-218858号公報(以下,「引用例」という。)には,図面とともに,次の事項が記載されている。
・発明の属する技術分野
「【0001】本発明は複数のプロセッサにデータが分散配置された分散型データベース管理システムに係り,特に,各々のプロセッサにおける処理負荷を容易に均等化する分散型データベース管理システムに関する。」
・発明が解決しようとする課題
「【0004】したがって本発明の目的は,上記の問題点を解決して,アクセス頻度の偏りに応じて各種データのプロセッサに対する分散配置を動的に変更し,複数のプロセッサの処理負荷を容易に均等化させることが可能な分散型データベース管理システムを提供することにある。」
・課題を解決するための手段
「【0005】上記の目的を達成するため,本発明の分散型データベース管理システムは,複数のプロセッサに分散配置された各種データへのアクセス要求があったとき,前記アクセス要求に応じた処理を所望のデータが配置されている特定のプロセッサで行う分散型データベース管理システムにおいて,個々のシステム資源に関するシステム資源情報,アクセス要求の発生頻度に関するデータアクセス統計情報,システム全体の処理負荷に関するシステム負荷統計情報に基づき,各プロセッサの処理負荷の偏りを検出する処理負荷偏り検出部と,各プロセッサの処理負荷の偏りを均等化させ得るデータの分散配置構成を前記処理負荷偏り検出部が検出した前記処理負荷の偏りから求め,所定のタイミングで前記分散配置構成の変更処理を行うデータ配置変更部と,を設ける構成としたものである。」
・実施形態の構成
「【0008】図1は,本発明の分散型データベース管理システムの実施の一形態の構成を示す図であり,図1(a)はシステム全体の物理的な構成を,図1(b)は本発明に関わる主要部分の論理的な構成を,それぞれ示す。同図中,1はシステム全体を統括管理するシステム管理プロセッサ,2?4はあらかじめ分散配置されたデータを個別に管理するデータ管理プロセッサ,5?7は具体的なデータが格納されているディスク,8はシステム管理プロセッサ1およびすべてのデータ管理プロセッサ2?4を相互に接続するネットワークである。また,11はデータベース制御部,21はシステム資源情報管理部,22はシステム資源情報,31はデータアクセス監視部,32はデータアクセス統計情報,41はシステム負荷監視部,42はシステム負荷統計情報,51は再配置実行制御部,61は処理負荷偏り検出部,62は再配置設計情報,71はデータ配置変更部,72は再配置データである。
【0009】図1(a)において,システム管理プロセッサ1は,ネットワーク8を介して送信された処理要求を受け取ると,その処理内容を解析して複数のジョブに細分化した後,各々のデータ管理プロセッサ2?4にこれらのジョブを送信する。ジョブを受信したデータ管理プロセッサ2?4は,それぞれ管理が割り当てられたディスク5?7内のデータを対象として上記ジョブによる実際的な処理を行い,求められた処理結果をシステム管理プロセッサ1へ返送する。
【0010】図1(b)において,データベース制御部11は,図1(a)に示した物理システムとこれから述べる論理システムとのデータのやりとりを仲介する部分である。システム資源情報管理部21は,データベース制御部11を介して得られたディスクなどの二次記憶装置や各種プロセッサなどのシステム構成要素に関するシステム資源情報22の管理を行う。データアクセス監視部31は,データベース制御部11を介してデータベース中の個々のデータへのアクセス状況を常時監視し,これに基づいてデータアクセス統計情報32の記録を行う。システム負荷監視部41は,データベース制御部11を介してシステム全体に対する処理負荷の状態を常時監視し,これに基づいてシステム負荷統計情報42の記録を行う。処理負荷偏り検出部61は,上述したシステム資源情報22およびデータアクセス統計情報32に基づき,データアクセスが特に集中する傾向の強いプロセッサを検出するとともに,データ管理プロセッサ2?4の各々に対する負荷をほぼ均一化し得るデータの分散配置を設計し,これを再配置設計情報62として出力する。データ配置変更部71は,データ管理プロセッサ2?4の各々に対するデータの再配置に伴う各種の処理を,この再配置設計情報62に基づいて行う。再配置実行制御部51は,処理負荷偏り検出部61およびデータ配置変更部71の動作を統括制御するとともに,処理負荷偏り検出部61およびデータ配置変更部71とデータベース制御部11との間のコマンドやデータのやりとりを仲介する。再配置データ72は,データの再配置に伴う各種の処理中に発生する作業データである。」
・データの再配置処理動作の流れ
「【0012】図2および図3において,再配置実行制御部51は,……再配置処理を開始し(ステップ201,302),最初に処理負荷偏り検出部61を起動してシステム資源情報22が具体的に記録されているシステム資源管理テーブル22aを読み込む(ステップ203)。次に,処理負荷偏り検出部61は,アクセス履歴テーブル32aを読み込んで個々のデータ域に対するデータ負荷を算出し(ステップ204),さらに,得られたデータ負荷とシステム資源管理テーブル22aの情報から各々のデータ管理プロセッサに対するデータ負荷を算出した後(ステップ205),各プロセッサにおける処理負荷の偏りが存在するか否かの判定を行う(ステップ206)。……偏りが存在した場合(ステップ206=Yes),処理負荷偏り検出部61は,データ負荷とシステム資源管理テーブル22aの情報に基づいて各プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し,これを再配置設計情報62として記録してから再配置実行制御部51に処理を戻す(ステップ207)。
【0013】続いて再配置実行制御部51は,……再配置設計情報62にしたがってデータ再配置の実行を開始する(ステップ211)。このとき,異なるデータ管理プロセッサ間で移動するデータについては,再配置データ72として一時ファイルに格納した上で,データベースからは削除する。そして,データ配置変更部71がデータベース制御部11に対してデータ配置規則の変更指示を行った後,退避しておいた再配置データ72を新たな配置規則にしたがって再びデータベースに登録する。」
「【0026】このほか,データ管理プロセッサの追加や削除については,処理負荷偏り検出部61が,システム資源管理テーブル22a中の変更情報22a4を参照することによって構成変更の有無を確認する(ステップ203)。そして,構成変更があったことが確認された場合には無条件に負荷の偏りがあるものとみなし(ステップ206=Yes),ステップ207?211のデータ再配置処理を行う。変更がデータ管理プロセッサの追加であれば,処理負荷偏り検出部61は,上述した(数式3)中のプロセッサ数に新たに追加したプロセッサ数を加えてデータ再配置設計を行い(ステップ207),これに基づいてデータ配置変更部71は,新たなプロセッサにデータを割り当てるためのデータ再配置を実行する(ステップ211)。また,変更がデータ管理プロセッサの削除であれば,処理負荷偏り検出部61は,上述した(数式3)中のプロセッサ数から削除すべきプロセッサ数を減じてデータ再配置設計を行い(ステップ207),これに基づいてデータ配置変更部71は,削除するプロセッサにデータを割り当てないためのデータ再配置を実行する(ステップ211)。」
・発明の効果
「【0028】……本発明の分散型データベース管理システムによれば,システムの日常的な使用状況に基づくアクセス頻度の偏り,プロセッサの追加あるいは削除を伴うシステム構成の変更などに応じて,各種データのプロセッサに対する分散配置を動的に変更可能となり,運用の停止と煩雑な作業が必要なシステムの再構築を行うことなく,各プロセッサにおける処理負荷を容易に均等化させることができるという効果が得られる。」

(イ)上記記載から,引用例には,以下の技術的事項が記載されているということができる。
a 引用例に記載された技術は,データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムにおいて,データ管理プロセッサに対するデータの配置をアクセス頻度の偏りに応じて動的に変更し,複数のデータ管理プロセッサの処理負荷を均等化させることを目的とした技術である(【0001】【0004】)。
b 分散型データベース管理システムは,システム全体を統括管理するシステム管理プロセッサ1,分散配置されたデータを個別に管理するデータ管理プロセッサ2?4,及びデータが格納されているディスク5?7を有し(【0008】),システム管理プロセッサ1は,処理要求を受け取ると,複数のジョブに細分化した後,これらのジョブを各々のデータ管理プロセッサ2?4に送信し,ジョブを受信したデータ管理プロセッサ2?4は,それぞれ管理が割り当てられたディスク5?7内のデータを対象として上記ジョブによる実際的な処理を行い,処理結果をシステム管理プロセッサ1へ返送する(【0009】)。
c データの再配置処理は,各データ管理プロセッサにおける処理負荷に偏りが存在するか否かを判定し,偏りが存在した場合,各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し,データ再配置を実行するものである(【0012】【0013】)。
d ここで,データ管理プロセッサの追加があった場合は,処理負荷の偏りがあるものとみなし,追加したプロセッサ数を加えてデータ再配置設計を行い,これに基づいて,追加したデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行する(【0026】)。
e データの再配置は,異なるデータ管理プロセッサ間で移動するデータを,再配置データ72として一時ファイルに格納した上でデータベースから削除し,退避しておいた再配置データ72を新たな配置規則に従って再びデータベースに登録することにより行われる(【0013】)。

(ウ)これらのことから,引用例には,以下の発明(以下,「引用発明」という。)が記載されていると認められる。
「システム全体を統括管理するシステム管理プロセッサ,分散配置されたデータを個別に管理する複数のデータ管理プロセッサ,及びデータが格納されているディスクを有し,データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムにおいて,
各データ管理プロセッサにおける処理負荷の偏りが存在した場合,各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し,データ再配置を実行し,
データ管理プロセッサの追加があった場合,処理負荷の偏りがあるものとみなし,新たに追加したプロセッサ数を加えてデータ再配置設計を行い,新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行するものであって,データ再配置は,異なるデータ管理プロセッサ間で移動するデータを,再配置データとして一時ファイルに格納した上でデータベースから削除し,退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われる,
方法。」

イ(ア)当審の拒絶理由で引用された,本願の出願日前に頒布された刊行物である特開2003-296153号公報(以下,「周知例1」という。)には,図面とともに,次の事項が記載されている。
「【0001】【発明の属する技術分野】本発明はネットワーク上でデータを保存するためのストレージシステムおよびそのためのプログラムに関し,……。」
「【0005】【発明が解決しようとする課題】(i)ネットワークファイルサーバを複数設置したものでは,通常,負荷分散が必要となる状況下において,特定のファイルに負荷が集中する場合が考えられ,その対策としてファイルサーバを増設している。しかしながら,高負荷となったファイルサーバは,負荷が集中したファイルを増設したファイルサーバにコピーしなければならず,手間がかかりユーザからのストレージへのアクセスに対するレスポンスがその分遅れるという問題がある。」
「【0014】図1は本発明による一実施形態のストレージシステムの概略構成図である。図1全体に示すストレージシステム100は,データの格納位置を管理するストレージ処理部1とデータをキャッシュメモリ等の小容量だが高速な記憶装置に一時記憶するデータ一時記憶部2とデータをハードディスク等の不揮発性の大容量だが低速の記憶装置に蓄積するデータ蓄積部3とを有する。ストレージ処理部1,データ一時記憶部2およびデータ蓄積部3はそれぞれ複数個……設けられ,インタコネクト(INFINIバンド)やLAN等の高速なネットワーク4を介して互いに分散配置されている。」
「【0016】ストレージ処理部1は,ネットワーク4に接続された複数のクライアント5の何れか1つのクライアントからデータ一時記憶部2またはデータ蓄積部3に記憶されているデータの送信が要求されると当該データを記憶しているデータ一時記憶部2またはデータ蓄積部3のどこに記憶されているかを検索し,検索したデータをクライアント5に送信する制御を行う。」
「【0018】ストレージ処理部1は,仮想ストレージ管理部10,処理負荷計測部11,処理分割 統合判定部12,処理ノード選択部13,処理負荷通知部14,制御部15および通信部16を有し,また仮想ストレージ管理テーブル20および処理負荷計測テーブル30を有する。」
「【0026】仮想ストレージ管理テーブル20は,仮想ストレージと実ストレージとの対応関係を記憶するテーブルである(図5,6,8参照)。……」
「【0036】図4は図2における仮想ストレージ分割処理のフローチャートであり,図5および図6は仮想ストレージ管理テーブル内のデータが分割処理により変更される第1および第2の具体例を示す図であり,(A)は分割処理前のテーブルを示す図であり,(B)は分割処理後のテーブルを示す図である。
【0037】(i)マスタストレージ処理部の負荷が上限閾値を超えた場合
まず,ステップS20でマスタストレージ処理部1(番号0)の処理ノード選択部13は,スレーブストレージ処理部1(番号1)に対して負荷の問合せする。スレーブストレージ処理部1の処理負荷通知部14はこの問合せを受けて,処理負荷計測テーブル30に格納されている処理負荷値を通知する。
【0038】ストレージ処理部が他にある場合は,それらをスレーブストレージ処理部とみなし,同様の処理を行う。
【0039】ステップS21でマスタストレージ処理部1(番号0)は,通知された処理負荷値に基づき,処理負荷値が最も低いスレーブストレージ処理部1(番号1)をここでは選択する。
【0040】ステップS22でマスタストレージ処理部1(番号0)は,選択されたスレーブストレージ処理部1(番号1)に現在担当している仮想ストレージ処理(番号1)を分割するため仮想ストレージ管理テーブル20の書換えを行う。その様子を図5に示す。図5の(A)に示す分割処理前の仮想ストレージ管理テーブル20から判るように,仮想ストレージ(番号1)の処理は,現在マスタストレージ処理部1(番号0)で実行されているが,この処理をスレーブストレージ処理部1(番号1)に分割するものとする。この分割処理を行った後の仮想ストレージ管理テーブル20を図5の(B)に示す。……
【0041】ステップS23でマスタストレージ処理部1(番号0)は,分割後の仮想ストレージ管理テーブル20にしたがいステップS21で選択されたスレーブストレージ処理部1(番号1)に処理を依頼する。スレーブストレージ処理部1(番号1)はこれを受けて依頼された処理を実行する。」
また,図面の図1には,ネットワーク4に,それぞれ複数のストレージ処理部1,データ一時記憶部2,データ蓄積部3,及びクライアント5が接続された構成が示されている。

(イ)上記記載によれば,周知例1には,(a)ネットワークに接続された複数のストレージを,複数のクライアントが共有する技術,及び(b)ネットワーク上でデータを保存するためのストレージシステムにおいて,ストレージ処理部の負荷が上限閾値を超えた場合,処理負荷値が最も低いストレージ処理部を選択し,仮想ストレージ管理テーブルの書換えを行うことにより,現在担当している仮想ストレージ処理を分割し,分割後の仮想ストレージ管理テーブルに基づき,選択されたストレージ処理部に処理を依頼する技術が記載されていると認められる。

ウ(ア)当審の拒絶理由で引用された,本願の出願日前に頒布された刊行物である特開2003-202964号公報(以下,「周知例2」という。)には,図面とともに,次の事項が記載されている。
「【0001】【発明の属する技術分野】本発明は,計算機システムの制御方法,計算機システム,記憶装置の制御方法及び記憶装置に係り,特に,バックアップ処理等を伴う仮想化されたボリュームのスナップショットを作成する情報処理システムの制御方法,計算機システム,記憶装置の制御方法及び記憶装置に関する。」
「【0006】その1つの例は,ホストコンピュータと記憶装置システムとの間に仮想化を実現するサーバが接続され,前記サーバが,1つまたは複数の物理的ボリュームの領域をホストコンピュータに対しアドレス変換することにより仮想化ボリュームを生成して,物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し,ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換して,ホストコンピュータによるアクセス要求を処理するというものである。……
【0007】前述した2つの例は,いずれも,物理的ボリュームの領域と仮想化ボリュームの領域との対応情報を保持して,物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理する手段を備えるものである。
【0008】……また、複数の物理的ボリュームは、それぞれ異なる複数の記憶装置システムに属していてもよい。」
「【0013】【課題を解決するための手段】本発明によれば前記目的は、1つまたは複数の記憶装置と、前記記憶装置の1つまたは複数の記憶領域を提供する1つまたは複数の制御装置と、前記記憶領域を仮想化した記憶領域を提供するための情報を管理する計算機とを備える計算機システムの制御方法において、前記計算機が有する前記記憶領域を提供するための情報が、前記記憶装置が提供する記憶領域と前記仮想化した記憶領域との対応情報を含み、前記制御装置が、前記計算機が有する前記対応情報の全体または一部を保持して前記1つまたは複数の記憶装置の制御を行うことにより達成される。」
また,図面の図1には,ネットワーク600に,複数のホスト200及び記憶装置300が接続された構成が示されている。

(イ)上記記載によれば,周知例2には,(a)ネットワークに接続された複数の記憶装置を,複数のホストが共有する技術,及び(b)ホストコンピュータと記憶装置システムとの間に接続されたサーバが,1又は複数の物理的ボリュームの領域をアドレス変換することにより仮想化ボリュームを生成し,物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し,ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換する技術が記載されていると認められる。

(3)引用発明との対比
ア 本願補正発明と引用発明とを対比する。
(ア)引用発明は,データが複数のデータ管理プロセッサに分散配置された分散型データベース管理システムであって,データ管理プロセッサによって,分散配置されたデータを個別に管理し,管理が割り当てられたディスク5?7内のデータを対象として実際的な処理を行うものであるから,引用発明の「データ管理プロセッサ」は,本願補正発明の「CPUリソース」に相当する。また,「ディスク5?7」は,本願補正発明と対応させれば,「データベースのデータを分散して格納する複数のデータ領域」としての機能を備えた「ストレージ」ということができる。
したがって,本願補正発明と引用発明とは,「複数のCPUリソースと,データベースのデータを分散して格納する複数のデータ領域を有するストレージと,を有するデータベース管理システム」である点で一致する。

(イ)引用発明は,前記のとおり,データ管理プロセッサが,分散配置されたデータを個別に管理するものであって,各データ管理プロセッサにおける処理負荷の偏りが存在した場合,各データ管理プロセッサにおける処理負荷の偏りが均等化されるようにデータの配置を設計し,データ再配置を実行するものであり,データベースのデータを分散して格納する複数のデータ領域は,各データ管理プロセッサに重複しないように関連づけれられているということができるから,本願補正発明と同様に,「データベース管理システムにおけるシステム構成変更方法」ということができ,本願補正発明の,「仮想化層により複数のデータ領域を複数のCPUリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ,複数のCPUリソースの各々が,それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップ」と対比すれば,両者は,「複数のデータ領域を複数のCPUリソースに重複しないように関連づけ,前記複数のCPUリソースの各々が,関連付けられたデータ領域のデータを処理するステップ」を有する点で共通する。

(ウ)引用発明は,データ管理プロセッサの追加があった場合,処理負荷の偏りがあるものとみなし,新たに追加したプロセッサ数を加えてデータ再配置設計を行い,新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置を実行するものであり,本願補正発明の,「新たなCPUリソースをデータベース管理システムに追加するステップ」及び「複数のデータ領域のうち一部のデータ領域について,当該一部のデータ領域が関連付けられる仮想ボリュームを複数のCPUリソースがアクセスする仮想ボリュームから新たなCPUリソースがアクセスする仮想ボリュームに変更するステップ」と対比すれば,本願補正発明における,データ領域が関連付けられる仮想ボリュームの変更は,CPUリソースに関連づけられたデータ領域を変更することにほかならないから,両者は,「新たなCPUリソースをデータベース管理システムに追加するステップ」及び「複数のデータ領域のうち一部のデータ領域について,当該一部のデータ領域が関連付けられるデータ領域を複数のCPUリソースがアクセスするデータ領域から新たなCPUリソースがアクセスするデータ領域に変更するステップ」を有する点で共通する。

イ 以上のことから,本願補正発明と引用発明との一致点及び相違点は,次のとおりである。
【一致点】
複数のCPUリソースと,データベースのデータを分散して格納する複数のデータ領域を有するストレージと,を有するデータベース管理システムであって,
データベース管理システムにおけるシステム構成変更方法であって,
前記複数のデータ領域を前記複数のCPUリソースに重複しないように関連づけ,前記複数のCPUリソースの各々が,関連付けられたデータ領域のデータを処理するステップと,
新たなCPUリソースを前記データベース管理システムに追加するステップと,
前記複数のデータ領域のうち一部のデータ領域について,当該一部のデータ領域が関連付けられるデータ領域を前記複数のCPUリソースがアクセスするデータ領域から前記新たなCPUリソースがアクセスするデータ領域に変更するステップと,
を含むデータベース管理システムのシステム構成変更方法。
【相違点1】
本願補正発明のデータベース管理システムは,「CPUリソースとストレージとを接続するネットワーク」を有するのに対し,引用発明は,当該構成が特定されていない点。
【相違点2】
本願補正発明のストレージは,「予め細分化された複数のデータ領域を有し,複数のCPUリソースから共有される」ものであるのに対し,引用発明のストレージは,CPUリソース(データ管理プロセッサ)に管理が割り当てられたディスクであり,複数のデータ領域を有するものの,「予め細分化」されていること,及び「複数のCPUリソースから共有される」ことは,明示されていない点。
【相違点3】
本願補正発明は,データベース管理システムが,データベース管理システム内に,複数のCPUリソースがアクセスする仮想的な記憶装置である仮想ボリュームに複数のデータ領域のいずれかを関連付けることにより複数のCPUリソースからデータ領域へのアクセスを可能とする仮想化層を有し,仮想化層により複数のデータ領域を複数のCPUリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ,複数のCPUリソースの各々が,それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するものであって,新たなCPUリソースをデータベース管理システムに追加する場合,一部のデータ領域が関連付けられる仮想ボリュームを複数のCPUリソースがアクセスする仮想ボリュームから新たなCPUリソースがアクセスする仮想ボリュームに変更することによりデータ再配置を行うのに対し,引用発明は,上記「仮想化層」に相当する構成を有しておらず,データ再配置は,異なるデータ管理プロセッサ間で移動するデータを,再配置データとして一時ファイルに格納した上でデータベースから削除し,退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われる点。

(4)判断
以下,相違点について検討する。
ア 相違点1について
データベースシステム等のコンピュータシステムにおいて,CPUリソースとストレージとをネットワークで接続することは,例えば,周知例1,2に記載されているように,周知の技術手段であり,引用発明において,当該構成を採用することは,当業者が適宜なし得ることである。

イ 相違点2について
データベースシステム等のコンピュータシステムにおいて,ストレージを複数のCPUリソースにより共有することは,例えば,周知例1,周知例2及び本願の出願日前に頒布された刊行物である特開2003-85014号公報(以下,「周知例3」という。)に記載されており,また,ストレージを予め複数のデータ領域に細分化しておくことも,例えば,周知例3に記載されており,いずれも周知の技術手段である。
引用発明において,上記周知の技術手段に係る構成を採用することは,当業者が容易に想到し得たものである。

・周知例3(特開2003-85014号公報)
周知例3には,次の記載があり,複数の計算機がネットワークを介して複数の記憶装置をアクセスするネットワークシステムにおいて,ボリューム管理テーブルに,各計算機における論理アドレス領域と各記憶装置の物理領域との関係,及び各入出力計算機のネットワーク上の位置と,各計算機のネットワーク上の位置とを登録し,管理すること(下記記載事項a),及び記憶装置の物理ボリュームを,物理エクステントに分割し,ボリューム管理テーブルに,論理ボリュームと,物理ボリュームと,物理エクステントとの関係を記憶すること(下記記載事項b)が記載されている。
a 「【0001】【発明の属する技術分野】本発明は,計算機がネットワークを介して記憶装置をアクセスするネットワークシステムにおける記憶装置のボリューム管理を行うネットワークシステムのボリューム管理方法及び計算機に関する。」
「【0013】また,別の発明は,複数の計算機がネットワークを介して複数の記憶装置をアクセスするネットワークシステムにおける各記憶装置のボリューム管理を行うネットワークシステムのボリューム管理方法において,各記憶装置とネットワークとの間に記憶装置に対するデータの入出力を行う入出力計算機を設け,各計算機のネットワーク上の位置と,各入出力計算機のネットワーク上の位置と,各計算機における論理アドレス領域と各記憶装置の物理領域との関係とを記憶するボリューム管理テーブルを設け,各計算機において論理アドレスを指定したアクセス要求に応じて,ボリューム管理テーブルの指定する入出力計算機に接続された記憶装置における論理アドレスが指定する物理領域をアクセスする。
【0014】このように構成されたネットワークシステムのボリューム管理方法においては,ボリューム管理テーブルに,各計算機における論理アドレス領域と各記憶装置の物理領域との関係の他に,各入出力計算機のネットワーク上の位置と,各計算機のネットワーク上の位置とを登録している。
【0015】したがって,このボリューム管理テーブルを参照することによって,各計算機は自己の論理アドレスに割当てられた記憶装置の物理領域をアクセスすることが可能となり,結果として,複数の計算機と複数の記憶装置が接続されたネットワークシステムにおけるボリューム管理を実現できる。」
b 「【0030】物理ボリュームと物理エクステントとの関係を図1を用いて説明する。物理ボリューム(PV)とは,現実の記憶媒体を示し,この実施形態ではHDD等の物理ディスクである。また,物理エクステント(PE)とは物理ボリューム(PV)を数MB(メガ バイト)の大きさに分割した物理領域であり,この実施形態のボリューム管理方式における最小の単位である。また,物理ボリューム(PV)と物理エクステント(PE)はラベル付けされている。
【0031】図1においては,それぞれラベルがPV0,PV1である2台の物理ボリューム(物理ディスク)1a,1bが設けられ,各物理ボリューム1a,1bは,それぞれラベルがPE1,PE2,PE3,…,PEnであるn個の物理エクステント(PE)2a,2bで構成されている。
【0032】図2にボリューム管理テーブル3を示す。このボリューム管理テーブル3内には,論理ボリューム(LV)4と,物理ボリューム(PV)1a,1bと,物理エクステント(PE)2a,2bとの関係が記憶されている。
【0033】論理ボリューム(LV)4とは,計算機が指定する論理アドレス領域を示す。この実施形態のボリューム管理テーブル3には,それぞれラベルVol1,Vol2,Vol3の3個の論理ボリューム(LV)4が登録され,各論理ボリューム(LV)4に対して,実際の物理ボリューム(PV)1a,1bと,物理エクステント(PE)2a,2bとが割り付けられている。」

ウ 相違点3について
(ア)周知例1には,前記(2)イ(イ)のとおり,ネットワーク上でデータを保存するためのストレージシステムにおいて,ストレージ処理部の負荷が上限閾値を超えた場合,処理負荷値が最も低いストレージ処理部を選択し,仮想ストレージ管理テーブルの書換えを行うことにより,現在担当している仮想ストレージ処理を分割し,分割後の仮想ストレージ管理テーブルに基づき,選択されたストレージ処理部に処理を依頼する技術が記載されている。
また,周知例2には,前記(2)ウ(イ)のとおり,ホストコンピュータと記憶装置システムとの間に接続されたサーバが,1又は複数の物理的ボリュームの領域をアドレス変換することにより仮想化ボリュームを生成し,物理的ボリュームの領域と仮想化ボリュームの領域との対応を管理し,ホストコンピュータによる仮想化ボリュームへのアクセスを物理的ボリュームへのアクセスに変換する技術が記載されている。
周知例1,2に記載された事項から,本願出願前において,ストレージを仮想化して管理することは,周知の技術手段であったということができ,また,当該技術手段によれば,データの移動を行うことなくデータの再配置を行うことができるという作用効果を奏することは,周知例1の段落【0005】に示唆されているように,当業者にとって自明である。
(イ)引用発明には,データ管理プロセッサの追加があった場合に,新たなデータ管理プロセッサにデータを割り当てるためのデータ再配置は,異なるデータ管理プロセッサ間で移動するデータを,再配置データとして一時ファイルに格納した上でデータベースから削除し,退避しておいた再配置データを新たな配置規則に従って再びデータベースに登録することにより行われるものであるが,上記のとおり,ストレージを仮想化して管理し,データの移動を行うことなくデータの再配置を行う技術が周知であったことに鑑みれば,引用発明において,データ再配置のための手段として,上記周知の技術手段を採用し,相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

エ そして,これらの相違点を総合的に勘案しても,本願補正発明の奏する作用効果は,引用例に記載された発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。
したがって,本願補正発明は,引用例に記載された発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法29条2項の規定により,特許出願の際独立して特許を受けることができないものである。

(5)本件補正についてのむすび
よって,本件補正は,平成18年改正前特許法17条の2第5項において準用する同法126条5項の規定に違反してなされたものであるから,同法159条1項において読み替えて準用する同法53条1項の規定により却下すべきものである。

第3 本願発明について
1 本願発明
平成24年1月13日付けの手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成21年6月26日付け手続補正書の特許請求の範囲の請求項1ないし3に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,平成21年6月26日付けの手続補正書によって補正された明細書及び図面の記載からみて,その請求項1に記載された事項により特定される,次のとおりのものである。
「複数のCPUリソースと,データベースのデータを分散して格納する複数のデータ領域を有し,前記複数のCPUリソースから共有されるストレージと,前記複数のCPUリソースと前記ストレージとを接続するネットワークと,を有するデータベース管理システムであって,前記データベース管理システム内に,前記複数のCPUリソースがアクセスする仮想的な記憶装置である仮想ボリュームに前記複数のデータ領域のいずれかを関連付けることにより前記複数のCPUリソースから前記データ領域へのアクセスを可能とする仮想化層を有するデータベース管理システムにおけるシステム構成変更方法であって,
前記仮想化層により前記複数のデータ領域を前記複数のCPUリソースの各々がアクセスする仮想ボリュームに重複しないように関連づけ,前記複数のCPUリソースの各々が,それぞれのアクセスする仮想ボリュームに関連付けられたデータ領域のデータを処理するステップと,
新たなCPUリソースを前記データベース管理システムに追加するステップと,
前記複数のデータ領域のうち一部のデータ領域について,当該一部のデータ領域が関連付けられる仮想ボリュームを前記複数のCPUリソースがアクセスする仮想ボリュームから前記新たなCPUリソースがアクセスする仮想ボリュームに変更するステップと,
を含むことを特徴とするデータベース管理システムのシステム構成変更方法。」

2 当審の拒絶理由の概要
当審において平成23年11月8日付けで通知した最後の拒絶理由の概要は,本願発明は,特開平9-218858号公報(引用例)に記載された発明,及び特開2003-296153号公報(周知例1)並びに特開2003-202964号公報(周知例2)に記載された周知技術に基づいて当業者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない,というものである。

3 引用例
引用例及び周知例1,2の記載事項は,前記第2の[理由]2(2)に記載したとおりである。

4 対比 判断
本願発明は,前記第2の[理由]2で検討した本願補正発明から,「予め細分化された」との限定事項を削除したものである。
そうすると,本願発明の発明特定事項を全て含み,さらに他の事項を付加したものに相当する本願補正発明が,前記第2の[理由]2(3),(4)に記載したとおり,引用例に記載された発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,同様の理由により,引用例に記載された発明及び周知技術に基づいて,当業者が容易に発明することができたものである。

5 むすび
以上のとおり,本願発明は,引用例に記載された発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法29条2項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。
よって,結論のとおり審決する。
 
審理終結日 2012-02-09 
結審通知日 2012-02-14 
審決日 2012-02-27 
出願番号 特願2004-3601(P2004-3601)
審決分類 P 1 8・ 575- WZ (G06F)
P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 井上 宏一  
特許庁審判長 西山 昇
特許庁審判官 清木 泰
田中 秀人
発明の名称 無共有型データベース管理システムにおけるシステム構成変更方法  
代理人 井上 学  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ