拒絶査定不服の審決｜不服2007-19430 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服特17条の2、3項新規事項追加の補正特許、登録しない。 G06F
管理番号	1209683
審判番号	不服2007-19430
総通号数	122
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2010-02-26
種別	拒絶査定不服の審決
審判請求日	2007-07-12
確定日	2010-01-07
事件の表示	特願2004- 85961「ストレージベースのジャーナリングを用いてバックアップ及びリカバリを行う方法と装置」拒絶査定不服審判事件〔平成17年 1月20日出願公開、特開2005- 18738〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は、平成16年3月24日(パリ条約による優先権主張2003年6月26日、米国)の出願であって、平成19年6月6日付けで拒絶査定がなされ、これに対し、平成19年7月12日に拒絶査定不服審判の請求がなされるとともに、平成19年8月8日付けで手続補正がなされたものである。第2 平成19年8月8日付けの手続補正についての補正却下の決定〔結論〕平成19年8月8日付けの手続補正を却下する。〔理由〕 1.補正内容平成19年8月8日付けの手続補正(以下、「本件第3補正」という)は、特許請求の範囲の補正を行うものであって、本件補正後の特許請求の範囲は以下のとおりのものである。「【請求項1】ネットワークを介してホストコンピュータに接続されたストレージシステムであって、前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリュームと、前記第1のデータボリュームのスナップショットを格納する第1のスナップショット格納領域と、前記第2のデータボリュームのスナップショットを格納する第2のスナップショット格納領域と、前記第1のデータボリュームヘのライトデータに関するジャーナルエントリを格納する第1のジャーナル格納領域と、前記第2のデータボリュームヘのライトデータに関するジャーナルエントリを格納する第2のジャーナル格納領域と、前記第1のジャーナル格納領域と、前記第1のスナップショット格納領域が所属し、前記第1のデータボリュームへの書込み動作の順序を保証する第1のジャーナルグループと、前記第2のジャーナル格納領域と、前記第2のスナップショット格納領域が所属し、前記第2のデータボリュームへの書込み動作の順序を保証する第2のジャーナルグループとを有し、前記第1のジャーナル格納領域に格納されるデータ量に関する第1の設定は、管埋者からの要求に基づいてなされ、第1のデータボリュームのスナップショットと前記第1のジャーナル格納領域に格納されたジャーナルエントリとを用いて、前記第1の設定に応じた第1の時間範囲内のデータ回復を許容するものであり、前記第2のジャーナル格納領域に格納されるデータ量に関する第2の設定は、管埋者からの要求に基づいてなされ、第2のデータボリュームのスナップショットと前記第2のジャーナル格納領域に格納されたジャーナルエントリとを用いて、前記第2の設定に応じた第2の時間範囲内のデータ回復を許容するものであり、前記第1又は第2の時間範囲内の時刻を指定したデータ回復要求を受けて、前記時刻のデータ回復を実行することを特徴とするストレージシステム。【請求項2】請求項1記載のストレージシステムであって、前記第1のジャーナル格納領域に格納されるデータ量に関する第1の設定と前記第2のジャーナル格納領域に格納されるデータ量に関する第2の設定の値が異なることを特徴とするストレージシステム。【請求項3】請求項1記載のストレージシステムであって、前記ストレージシステムは前記第1及び第2のジャーナル格納領域に格納されたジャーナルエントリを前記第1の設定もしくは前記第2の設定の値に応じて開放することを特徴とするストレージシステム。【請求項4】請求項1記載のストレージシステムであって、前記データ回復要求は前記ホストコンピュータから発行されることを特徴とするストレージシステム。」そこで、ストレージシステム内にデータボリュームを第1と第2の2系統設けるという技術的事項を導入する補正、すなわち、請求項1中の「前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリューム」という技術的事項を導入する補正の適否について検討する。 2.本件第3補正の適否に対する判断 (1) 願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)の、「【0009】図1は本発明に従うバックアップとリカバリシステムの一実施例を説明する上位階層の一般的ブロックダイアグラムである。システムが立ち上がると、スナップショットが生産用データボリューム(DVOL)101に対して取得される。ここで、“スナップショット”とは、本明細書では慣例に従い、ある指定時点に於けるデータボリュームのデータイメージのことを言う。システムに対する要求や実装等に対応して、スナップショットは、データボリュームの全体、又はその或る部分、又は複数の部分に対してなされる。本発明では、システムの正常運用の間にジャーナルエントリがホストから本データボリュームに発せられた全ての書き込み動作に対して作成される。以下に説明するように、所定のスナップショットに対して一連のジャーナルエントリを適用する事により、データは如何なる時点に対しても回復され得る。【0010】図1のバックアップとリカバリシステムには、少なくとも一式のストレージシステム100が存在する。図示されてはいないものの、本ストレージシステムには適切なプロセッサ、メモリ、及びホスト110とそのストレージ媒体(例えばディスク)との間の入出力動作を実行するコントロール回路が存在する事は当業者には明らかである。バックアップとリカバリのシステムには、更に少なくとも一式のホスト110が必要である。適切な通信パス130がホストとストレージシステムの間に存在する。ホスト110には、通常一つ以上のユーザアプリケーション(APP)112が稼動している。これらのアプリケーションは本ストレージシステム100のデータボリューム101に存在するストレージ媒体に対してデータの読み書きを実行する。【0011】かくして、アプリケーション112とデータボリューム101が保護されるべき対象リソースとなる。ユーザのアプリケーションで使用されるデータは、一つあるいはそれ以上のデータボリュームに保存され得るのは明らかである。本発明では、ジャーナルグループ(JNLG)102を定義する。データボリューム101は本ジャーナルグループの中に編成される。本発明では、ジャーナルグループは、ホスト110からデータボリュームへの書き込み動作のジャーナリングが保証されるデータボリュームの最小ユニットである。本関連するジャーナルは、ホストからデータボリュームへの書き込み動作を適切な順序で記録する。ジャーナリング処理によって生成されたジャーナルデータは、一つ以上のジャーナルボリューム(JVOL)106に保存される。ホスト110には更にリカバリマネージャ(RM)111が存在する。本コンポーネントは、バックアップとリカバリ動作の上位階層での協調を可能にする。本リカバリマネージャに関しては更に後に記す。」 (下線は、当審にて付加) という記載等にあるように、「ホスト」上の「アプリケーション」が「ストレージシステム」に対してデータの書き込みを行う最小単位は「データボリューム」ではなく「ジャーナルグループ」であることは明らかである。つまり、「ホスト」側や「ホスト」上の「アプリケーション」側からは、「特定のデータボリュームのみ」に対してデータを書き込むように制御することができない。 (2) 一方、当初明細書等の、「【0028】図4は本発明の実装例に従う、リカバリマネージャ111とストレージシステム100がバックアッププロセスを開始するプロセスを説明するフローチャートである。スナップショットが取得されていても、ジャーナルエントリが記録されていない書き込み動作は、データ回復処理中にデータは損失するか破損する。従って、本発明では最初のスナップショット取得前にジャーナリングプロセスを起動する。これを行うことにより、スナップショット取得後に発生する全ての書き込み動作がジャーナルされることが保障される。スナップショット完成前に記録されたジャーナルエントリは全て無視してもよい事を注記する。更に本発明に従えば、単一系列の順序番号(SEQ)313が各スナップショットとジャーナルエントリに、生成される毎に割り当てられる。各スナップショットとジャーナルエントリに同一系列の順序番号を割り当てる目的は以下に述べる。【0029】図4に戻って、リカバリマネージャ111は、ジャーナルグループ(JNLG)102が定義済でなければ、これをステップ410で定義する。【0030】図1で示した通り、本定義では、ジャーナルの対象となる一台以上のデータボリューム(DVOL)101を指定し、ジャーナル関連情報を保存する一台以上のジャーナルボリューム(JVOL)106を指定する。リカバリマネージャは、目的を達成する為に、ストレージシステム100との間で適切な一連のやり取りを実行する。【0031】ステップ415にて、ストレージシステムは図3のテーブル300の詳細図に示される多様な情報を収容する管理テーブル108(図1)を生成する。とりわけ、本プロセスでは、ジャーナルグループ102を構成するジャーナルボリュームをリストするJVOL_LIST340の初期化を行う。同様に、データボリュームのリストDVOL_LIST320を生成する。次のジャーナルエントリ(又はテーブルが最初に生成される場合には最初のジャーナルエントリ)を指定するフィールドを初期化する。かくして、JI_HEAD_VOL331はジャーナルボリュームリスト内の最初を指定し、JI_HEAD_ADR332は、最初のジャーナルボリュームに存在するジャーナルヘッダ領域210の最初のエントリをポイントする。【0032】同様に、JI_DATA_VOL335は、ジャーナルボリュームリスト内の最初を指定し、JI_DATA_ADR336は、最初のジャーナルボリュームに存在するジャーナルデータ領域220の開始点をポイントする。ヘッダ領域210とデータ領域220は異なるジャーナルボリュームに収容でき、JI_DATA_VOLは最初のジャーナルヘッダボリュームとは異なったジャーナルボリュームを指定することがあり得ることに注意していただきたい。ステップ420にて、リカバリマネージャ111はジャーナリングプロセスを起動する。ジャーナリングを実行する為に、ストレージシステム100に対して適切な交信がなされる。ステップ425にて、ストレージシステムはホスト110からの今後の各書き込み動作に対して、ジャーナルエントリ(これは、“事後ジャーナル”とも呼ばれる)を作成する。【0033】図3を参照するに、ジャーナルエントリを作成するには、とりわけ、次のジャーナルエントリを保存するロケーションを指定することが必要になる。フィールドJI_HEAD_VOL331とJI_HEAD_ADR332は各々、次のジャーナルヘッダ219のジャーナルボリューム106とジャーナルヘッダ領域210内での位置を指定する。管理テーブルからの順序カウンタ(SEQ)313は、次のヘッダのJH_SEQ215フィールドにコピーされ割り当てられる。本順序カウンタは次いで加算され、管理テーブルに戻される。勿論、本順序カウンタは最初に加算し、ついでJH_SEQにコピーし、最後に管理テーブルに戻してもよい。【0034】管理テーブルのJI_DATA_VOL335とJI_DATA_ADR336フィールドは、各々書き込み動作に付随するデータを保存する、ジャーナルボリュームとジャーナルデータ領域220の開始点を指定する。JI_DATA_VOLとJI_DATA_ADRは各々、ジャーナルヘッダのJH_JVOL216とJH_ADR212にコピーされ、この結果ジャーナルヘッダがジャーナルデータに対応するポインタを得る事になる。書き込み動作のデータは保存される。【0035】 JI_HEAD_VOL331とJI_HEAD_ADR332フィールドは、次のジャーナルエントリに対する次のジャーナルヘッダ219をポイントするべく更新される。このことはジャーナルヘッダ領域210内の次に続くジャーナルヘッダエントリを用いる結果となる。同様に、JI_DATA_VOLフィールドとJI_DATA_ADRフィールドは、各々次のジャーナルエントリに対するジャーナルデータボリュームとジャーナルデータ領域での開始点を反映すべく更新される。このことは、ジャーナルデータ領域における次の保存可能位置に進めることを意味する。従ってこれらのフィールドは、ジャーナルエントリのリストをポイントすると見なすことが出来る。リストのジャーナルエントリは、ジャーナルヘッダ領域210内のジャーナルヘッダ219のシーケンシャル構成によって、互いにリンクすることが出来る。【0036】ジャーナルヘッダ領域210の最終点に達したら、次のジャーナルエントリに対するジャーナルヘッダ219は、ジャーナルヘッダ領域の開始点に戻される。ジャーナルデータ225に対しても同様である。以前のジャーナルエントリに上書きする事を防止する為に、本発明はジャーナルボリューム106のエントリを開放する処置を実施する。本件については、以下に述べる。ジャーナル起動後の最初のジャーナルエントリに対しては、JO_HEAD_VOL333、JO_HEAD_ADR334、JO_DATA_VOL337、及びJO_DATA_ADR338の各フィールドは、各対応する“JI_”フィールドの初期値がセットされる。後に説明するように、“JO_”フィールドはその時の最古のジャーナルエントリをポイントする。かくして、新しいジャーナルエントリが作成されると、“JI_”フィールドは前進するが“JO_”フィールドは前進しない。“JO_”フィールドの更新については以下で説明する。【0037】図4のフローチャートに戻って、ジャーナリングプロセスが起動している場合には、ホストからのすべての書き込み動作はジャーナルされる。そこでステップ430に於いて、リカバリマネージャ111はデータボリューム101のスナップショットの取得を起動する。ストレージシステム100は、リカバリマネージャからスナップショットを取得する指示を受け取る。ステップ435にて、ストレージシステムはデータボリュームのスナップショットを取得するプロセスを開始する。この結果特に、管理テーブル(図3)上のSS_LIST350にアクセスすることになる。次のスナップショットを扱う為に必要な量のメモリがフィールド351-354に割り当てられる。順序カウンタ(SEQ)313は、上記のJH_SEQ215で説明したように、SS_SEQ351フィールドにコピーされ、加算される。【0038】かくて、順序番号はSEQ313より生成され、順序カウンタ中の各番号はジャーナルエントリ又はスナップショットエントリのいずれかに処理中を通して割り当てられる。スナップショットは一台(以上)のスナップショットボリューム(SVOL)107に保存される。フィールド355-357に必要な量のメモリが割り当てられる。スナップショットを保存する為のSVOLに関連する情報がフィールド355-357に保存される。スナップショット保存に追加のボリュームが必要なら、フィールド355-357に追加のメモリが割り当てられる。」という記載等にあるように、「ホスト」から送られるデータを受けて「ストレージシステム」は、「ジャーナルグループ」内の「データボリューム」に書き込むことは開示されているとはいえても、「ストレージシステム」は如何なるアプリケーションのデータなのかを判別して、特定の「データボリューム」に書き込むことが開示されているとはいえない。つまり、「ストレージシステム」側からは、「特定のアプリケーション」から送られるデータを「特定のデータボリュームのみ」に対してデータを書き込むように制御することができない。 (3) 上記(1)及び(2)で検討したように、「ホスト」側や「ホスト」上の「アプリケーション」側からは、「特定のデータボリュームのみ」に対してデータを書き込むように制御することができないし、「ストレージシステム」側からは、「特定のアプリケーション」から送られるデータを「特定のデータボリュームのみ」に対してデータを書き込むように制御することができないのであるから、当初明細書等には、ストレージシステム内にデータボリュームを第1と第2の2系統設けることが開示されているとはいえない。つまり、ストレージシステム内にデータボリュームを第1と第2の2系統設けるという技術的事項を導入する補正、すなわち、請求項1中の「前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリューム」という技術的事項を導入する補正は、当初明細書等に記載した事項の範囲内においてしたものでない。しかも、当該補正にあるように、第1と第2の2系統設けることによって、アプリケーションとデータボリュームを対応させる構成を採用すると、 (本願当初明細書段落【0005】に記載された、“誤って昨日10:00AM頃にファイルを消去してしまった。そのファイルを消去直前に回復しなければならない”という要求と類似した)“誤って昨日10:00AM頃に第1のアプリケーションのファイルを消去してしまった。そのファイルを消去直前に回復しなければならない”という要求を処理する場合、「ストレージシステム」内の全ての「データボリューム」を調べるのではなく、「第1のアプリケーション」に対応した特定の「データボリューム」のみを調べれば済み、回復処理時間が大幅に削減されるという効果を新たに奏することになるから、当該補正は、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものである。 3.むすびしたがって、本件第3補正は、特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。第3 本願発明について 1.本願発明本件補正は上記のとおり却下されたので、特許請求の範囲第1乃至4項は、平成19年5月14日付けの手続補正(以下、「本件第2補正」という)によって補正された特許請求の範囲第1乃至4項に記載された以下のとおりのものである。「【請求項1】ネットワークを介してホストコンピュータに接続されたストレージシステムであって、前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリュームと、前記第1のデータボリュームのスナップショットを格納する第1のスナップショット格納領域と、前記第2のデータボリュームのスナップショットを格納する第2のスナップショット格納領域と、前記第1のデータボリュームヘのライトデータに関するジャーナルエントリを格納する第1のジャーナル格納領域と、前記第2のデータボリュームヘのライトデータに関するジャーナルエントリを格納する第2のジャーナル格納領域と、前記第1のジャーナル格納領域と、前記第1のスナップショット格納領域が所属し、前記第1のデータボリュームへの書込み動作の順序を保証する第1のジャーナルグループと、前記第2のジャーナル格納領域と、前記第2のスナップショット格納領域が所属し、前記第2のデータボリュームへの書込み動作の順序を保証する第2のジャーナルグループとを有し、前記第1のジャーナル格納領域は、管埋者からの要求に基づいて容量設定され、第1のデータボリュームのスナップショットと前記第1のジャーナル格納領域に格納されたジャーナルエントリとを用いて、第1の時間範囲内のデータ回復を許容するものであり、前記第2のジャーナル格納領域は、管埋者からの要求に基づいて容量設定され、第2のデータボリュームのスナップショットと前記第2のジャーナル格納領域に格納されたジャーナルエントリとを用いて、第2の時間範囲内のデータ回復を許容するものであり、前記第1又は第2の時間範囲内の時刻を指定したデータ回復要求を受けて、前記時刻のデータ回復を実行することを特徴とするストレージシステム。【請求項2】請求項1記載のストレージシステムであって、第1のジャーナル格納領域と前記第2のジャーナル格納領域に対する容量設定の値が異なることを特徴とするストレージシステム。【請求項3】請求項1記載のストレージシステムであって、前記ストレージシステムは前記第1及び第2のジャーナル格納領域に格納されたジャーナルエントリを各々の容量設定の値に応じて開放することを特徴とするストレージシステム。【請求項4】請求項1記載のストレージシステムであって、前記データ回復要求は前記ホストコンピュータから発行されることを特徴とするストレージシステム。」 2.平成19年3月5日付けの拒絶理由通知書で通知された拒絶理由平成19年3月5日付けの拒絶理由通知書で通知された拒絶理由は、以下のとおりのものである。「平成19年1月10日付けでした手続補正は、下記の点で願書に最初に添付した明細書、特許請求の範囲又は図面(以下、「当初明細書等」という。)に記載した事項の範囲内においてしたものでないから、特許法第17条の2第3項に規定する要件を満たしていない。記請求項1?3についてストレージシステム内に、データボリューム、スナップショット格納領域、ジャーナル格納領域を第1と第2の2系統設けることは当初明細書等には記載されていないし、当初明細書等の記載から自明な事項でもない。第1と第2の系統で、容量の設定を異ならせること、データ回復の時間範囲内を変えることも当初明細書等には記載されていないし、当初明細書等の記載から自明な事項でもない。請求項4について請求項1を引用する請求項4も当初明細書等には記載されていないし、当初明細書等の記載から自明な事項でもない。したがって、当該補正された請求項1?4に記載した事項は、当初明細書等には記載されていないし、当初明細書等の記載から自明な事項でもない。当該補正がなされた特許請求の範囲における請求項1?4に記載した事項は、当初明細書等に記載した事項の範囲内にないことが明らかであるから、請求項1?4に係る発明については特許法第17条の2第3項以外の審査を行っていない。なお、平成19年3月7日付けの説明書において、出願人は明細書第10,11段落の記載を基にして「前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のボリューム」、「前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリューム」と、アプリケーションの種別に応じてライトデータが格納されるデータボリュームを区別する補正を行いたい旨希望しているが、明細書第10,11段落には、アプリケーション毎にデータボリュームを異ならせることは記載されておらず、当初明細書等のその他の箇所にもそのような記載はないし、当初明細書等の記載から自明な事項でもない。」 3.検討そこで、平成19年3月5日付けの拒絶理由通知書で通知された請求項1に対する拒絶理由(以下、単に「拒絶理由」という。)のうち、「ストレージシステム内に、データボリューム、・・・を第1と第2の2系統設けることは当初明細書等には記載されていないし、当初明細書等の記載から自明な事項でもない。」ことについて検討する。当該拒絶理由は、本件第2補正後の請求項1中の「前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリューム」という記載に関するものである。そして、当該記載と同一の記載である、本件第3補正後の請求項1中の「前記ホストコンピュータ上の第1のアプリケーションからのライトデータを格納する第1のデータボリュームと、前記ホストコンピュータ上の第2のアプリケーションからのライトデータを格納する第2のデータボリューム」という記載は、上記「第2 平成19年8月8日付けの手続補正についての補正却下の決定」で検討したように、特許法第17条の2第3項に違反するのであるから、本件第2補正も、同様の理由により、特許法第17条の2第3項に違反する。 4.むすび以上のとおり、本件第2補正は、特許法第17条の2第3項の規定に違反するのであるから、本願は拒絶すべきものである。よって、結論のとおり審決する。
審理終結日	2009-10-28
結審通知日	2009-11-10
審決日	2009-11-24
出願番号	特願2004-85961(P2004-85961)
審決分類	P 1 8・ 561- Z (G06F)
最終処分	不成立
前審関与審査官	高瀬勤
特許庁審判長	田口英雄
特許庁審判官	和田財太小曳満昭
発明の名称	ストレージベースのジャーナリングを用いてバックアップ及びリカバリを行う方法と装置
代理人	特許業務法人第一国際特許事務所

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