【事件の表示】
　特願２００３−４２３２２０「データレプリケーション方法」拒絶査定不服審判事件〔平成１７年　７月　７日出願公開、特開２００５−１８２５１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１５年１２月１９日の出願であって、平成２１年５月２６日付けで拒絶理由が通知され、同年８月３日に手続補正がなされたが、同年９月１４日付けで拒絶査定がされ、これに対し、同年１２月２８日に拒絶査定不服審判が請求されたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２１年８月３日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
「【請求項１】
　レプリケーション元の記憶装置のデータを通信回線を介してレプリケーション先の記憶装置のデータにコピーするデータレプリケーション方法であって、
　レプリケーション元の記憶装置のデータを物理ブロックアクセスによってレプリケーション元の記憶装置が読み出す読出しステップと、
　レプリケーション元の記憶装置が、読み出したデータをレプリケーション先の記憶装置に通信回線を介して転送する転送ステップと、
　レプリケーション先の記憶装置が、受信したデータをレプリケーション先の記憶装置のオペレーティングシステムがサポートするファイルシステムにおけるファイルとしてレプリケーション先の記憶装置に格納する格納ステップと、
を備えることを特徴とするデータレプリケーション方法。」
　
３．引用例
　原査定の拒絶の理由に引用された特開２００２−３５１７０３号公報（以下、「引用例」という。）には、図面と共に次の事項が記載されている。
　
あ．「【０００８】・・・中略・・・図１は記憶装置１の論理構成を示している。記憶装置１は、４つのファイバチャネルポート５０、４つのイーサネットポート５２、ブロックデータ入出力処理部１０−ａ、ファイルデータ入出力処理部１０−ｂ、論理ボリューム管理部３０、ファイルシステム２０、論理ボリューム３５−ａ、ｂから構成される。論理ボリューム３５−ａ、ｂは、論理ボリューム管理部３０により複数のドライブの物理アドレス上に形成され、論理ボリューム管理部３０はこの複数ドライブ上の記憶領域を管理し、論理ボリューム管理部３０内に論理ボリュームのアドレスとドライブ上の物理アドレスを対応づけるテーブル（以下、アドレス変換テーブルと略す）が保持される（図示していない）。論理ボリュームは、ブロック形式のデータ（以下、ブロックデータと略す）記憶用の論理ボリューム３５−ａと、ファイル形式のデータ（以下、ファイルデータと略す）記憶用の論理ボリューム３５−ｂに分ける。・・・後略・・・」
　
い．「【００１７】ファイルデータを読み出す場合、ファイルシステム２０ではホストコンピュータから指定されたファイルデータから論理ボリューム３５−ｂのアドレスを割り出す。その後、論理ボリューム管理部３０内のアドレス変換テーブルにより指定されるドライブ上の物理アドレスからブロックデータを読み出し、ファイルシステム２０においてファイルデータに変換し、ファイルデータ入出力処理部１０−ｂで、ファイルシステム２０用のデータフォーマットからインターネットプロトコル用のデータフォーマットに変換し、イーサネットポート５２から出力する。」
　
う．「【００３５】記憶装置１−１から１−２へファイルデータをリモートコピーする場合について述べる。ホストサーバ１−１はリモートコピーの対象とするファイルデータのディレクトリを指定してリモートコピー要求を、ファイルデータ用イーサネットポート５４−ｂを介して記憶装置１−１に対して発行する。要求を受けた記憶装置１−１のファイルシステム２０−１は、リモートコピー対象のファイルディレクトリからリモートコピー対象の論理ボリュームを割り出し、イーサネットポート５４−ｂを介したＩＰ（インターネットプロトコル）通信により、ブロックデータ用のイーサネットポート５４−ａからファイルシステムを介さずに対象論理ボリュームをリモートコピーすることを、予め記憶装置１−２のファイルシステム２０−２に通知する（図中矢印１０５）。通知を受けたファイルシステムは２０−２は、ファイルデータがファイルシステムを介さずにブロックデータ用のイーサネットポート５４−ａから入力されることと対象となる論理ボリュームを、論理ボリューム管理部３０−２に通知するとともに、ファイルシステム２０−１からの通知に対する了承をファイルシステム２０−１に返送する。それを受けたファイルシステム２０−１は、論理ボリューム管理部３０−１へリモートコピー対象ボリュームを通知する。
【００３６】以下に、上記リモートコピー要求が、記憶装置１−１から１−２へコピー対象ボリュームの全ファイルデータをコピーする要求と、コピー後に、記憶装置１−１のコピー対象ボリューム内のファイルデータが更新されたとき、記憶装置１−２に更新されたファイルデータの更新をする要求とを含む場合について、説明する。論理ボリューム管理部３０−１は、通知されたリモートコピー対象ボリュームをドライブから読み出し、ブロックデータ及びファイルデータ入出力処理部１１−１で、記憶装置１内部のデータフォーマットからＳＣＳＩプロトコルのデータフォーマットに変換し、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケットに載せ、イーサネットポート５４−ａからイーサネットベースのＳＡＮ９経由で記憶装置１−２へ転送する。リモートコピーのデータを受け取った論理ボリューム管理部３０−２は、データとともに送られる対象論理ボリュームのアドレスからファイルデータのリモートコピーであることを識別し、対象ボリュームのコピーをする。（図中矢印１０６）。また、記憶装置１−１内のコピー対象となったボリューム内のデータが更新された場合には、更新された該当データをドライブから読み出し、ブロックデータ及びファイルデータ入出力処理部１１−１で、記憶装置１内部のデータフォーマットからＳＣＳＩプロトコルのデータフォーマットに変換し、ＳＣＳＩプロトコルのパケットをインターネットプロトコルパケットに載せ、イーサネットポート５４−ａからイーサネットベースのＳＡＮ９経由で記憶装置１−２へ転送する。リモートコピーのデータを受け取った論理ボリューム管理部３０−２は、データとともに送られる対象論理ボリュームのアドレスからファイルデータのリモートコピーであることを識別し、対象ボリューム内の該当データを更新する（図中矢印１０６）。
【００３７】本実施例によれば、記憶装置間でのファイルデータのリモートコピーを、ファイルシステムを介さずに行うことが可能となるため、ファイルシステムにおける処理オーバヘッド分が削減され、ファイルデータのリモートコピーを高速化することが可能となる。実施例１及び実施例３の構成の記憶装置１においても、本実施例を実施する上で問題はなく、本実施例と同様の効果が得られる。」
　
　ここで、上記各記載事項を各種常識に照らせば、以下のことがいえる。
（あ）上記「あ．」及び「い．」によれば、引用例の「記憶装置」は、「ファイルシステム２０」におけるファイル形式のデータ（「ファイルデータ」）として記憶する領域である「論理ボリューム３５−ｂ」を有しており、該領域に記憶格納されたデータは、「ファイルシステム２０」を介して「ファイルデータ」として入出力されるものであるから、該「記憶装置」の「論理ボリューム３５−ｂ」に記憶格納されたデータは、当然に、「記憶装置」を利用するオペレーティングシステムがサポートする「ファイルシステムにおけるファイルとして」扱われるものである。
（い）上記記載事項中の「リモートコピー」は、コピー元の「ファイルデータ」をコピー先の「記憶装置」とも呼び得る手段にコピーする際、コピー元の記憶装置１−１が、ファイルシステムを介さずに記憶装置のデータを読み出し（論理ボリューム管理部３０−１により物理アドレスからブロックデータを読み出し）、通信回線を介して転送すると、コピー先の記憶装置１−２が、該受信したデータをファイルデータのリモートコピーであると識別して、「記憶装置」を利用するオペレーティングシステムがサポートするファイルシステムにおけるファイルとして扱う「論理ボリューム３５−ｂ」に、格納しているから、該「リモートコピー」方法は、当然に、データを物理ブロックアクセスによって読み出すステップと、転送するステップと、受信したデータをファイルシステムにおけるファイルとして格納するステップと、を備えている。
　
　したがって、引用例には
「リモートコピー元の記憶装置のデータを通信回線を介してリモートコピー先の記憶装置のデータにコピーするリモートコピー方法であって、
　リモートコピー元の記憶装置のデータを物理ブロックアクセスによってリモートコピー元の記憶装置が読み出すステップと、
　リモートコピー元の記憶装置が、読み出したデータをリモートコピー先の記憶装置に通信回線を介して転送するステップと、
　リモートコピー先の記憶装置が、受信したデータをリモートコピー先の記憶装置のオペレーティングシステムがサポートするファイルシステムにおけるファイルとしてリモートコピー先の記憶装置に格納するステップと、
を備えるリモートコピー方法。」
　の発明（以下、「引用発明」という。）が記載されている。
　
４．対比
　本願発明と引用発明とを対比すると、以下のことがいえる。
（１）引用発明の「リモートコピー」と本願発明の「レプリケーション」とは、同じデータを複数の記憶装置に格納するための（以下「バックアップ」という。）、コピー方法である点で共通する。
（２）引用発明の「読み出すステップ」、「転送するステップ」、及び「格納するステップ」は、それぞれ、本願発明の「読出しステップ」、「転送ステップ」、及び「格納ステップ」と、上記（１）のようにバックアップの方法が異なる点を除いて、共通する。
　
　したがって、本願発明と引用発明との間には、以下の一致点、相違点があるといえる。
　
（一致点）
「コピー元の記憶装置のデータを通信回線を介してコピー先の記憶装置のデータにコピーするコピー方法であって、
　コピー元の記憶装置のデータを物理ブロックアクセスによってコピー元の記憶装置が読み出す読出しステップと、
　コピー元の記憶装置が、読み出したデータをコピー先の記憶装置に通信回線を介して転送する転送ステップと、
　コピー先の記憶装置が、受信したデータをコピー先の記憶装置のオペレーティングシステムがサポートするファイルシステムにおけるファイルとしてコピー先の記憶装置に格納する格納ステップと、
を備えるコピー方法。」
　
（相違点）
　本願発明の「コピー方法」（データレプリケーション方法）が行うコピーは、「レプリケーション」であるのに対し、引用発明の「コピー方法」（リモートコピー方法）が行うコピーは、「レプリケーション」ではない点。
　
５．判断
　上記相違点について検討する。
　「レプリケーション」がバックアップの一形態であること、「レプリケーション」のように常時（ほぼ）最新のデータが格納されるようにすることがバックアップにおいて有用な場合があることは当業者に自明であるから、引用発明を、「レプリケーション」を行う「データレプリケーション方法」とすることは、当業者が容易に推考し得たことというべきである。
　
（効果について）
　本願発明の奏する効果は、引用発明及び上記周知の事項から予測される範囲内のものにすぎず、格別なものということはできない。
　
（請求人の主張について）
　平成２１年１２月２８日付け審判請求書において、請求人は以下の主張をしている。
「『リモートコピーのデータを受け取った論理ボリューム管理部３０−２は、データと共に送られる対象論理ボリュームのコピーをする』ことが引用例１に記載されていますが、これは、上記の『受信したデータを・・・ファイルとして格納する』とは意味が異なります。本願請求項における上記点は、レプリケーション先が受信したデータ（レプリケーション元が物理ブロックアクセスによって読み出したデータを転送したもの）を１ファイルとして格納するものであり、データのコピーとは異なります。これは、本願明細書の段落００２２及び図３（ａ）に記載があります。また、『図１０の矢印１０６が論理ボリューム３５−ｂへのリモートコピーを示していること、及び段落０００８における『ファイル形式のデータ（以下ファイルデータと略す）記憶用の論理ボリューム３５−ｂ』等の記載から、本願請求項における上記点に相当する構成が開示されているといえる。』と述べられています。確かに、引用例１の図１０の矢印１０６や段落００３６はリモートコピーについて記載されていますが、本願発明の上記点はリモートコピーとは異なるため、上記指摘箇所から本願の上記点に相当する構成が開示されているとはいえません。また、引用例１の段落０００８には、２種類の論理ボリュームを持つとしか記載されていません。
　更に、引用例１の構成は（図１）、入出力処理部としてブロックデータ用（１０−ａ）とファイルデータ用（１０−ｂ）の２つを持ち、ブロック形式のデータ記憶用の論理ボリューム（３５−ａ）とファイル形式のデータ記憶用論理ボリューム（３５−ｂ）という２種類の論理ボリュームを持ちます。論理ボリューム管理部３０は、論理ボリュームの書き込み、読み出しを行い、ファイルシステム２０は、ファイルデータのブロックデータへの変換や論理ボリューム３５−ｂのアドレス割り出しを行ないます。引用例１の審査官殿が指摘された箇所による説明によれば、受信したデータを変換し、論理ボリュームにコピーすることが記載されていますが、論理ボリュームのデータをファイルとして格納する記述は無く、また、本願発明の上記点の機能を想定させる構成も無いことから、本願発明は、引用例１からは容易に想到できないと確信いたします。」
　
　しかしながら、本願発明は請求項１の文言上、「ファイルシステムにおけるファイルとして」格納することは記載されているものの、「受信したデータ（レプリケーション元が物理ブロックアクセスによって読み出したデータを転送したもの）を１ファイルとして格納する」ことまでは読み取れず、上記主張（のうち「データのコピーとは異なります」部分について）は、請求項１の記載に基づく主張であるとはいえない。
　また、上記「３．」の「う．」で摘記したように、引用例におけるリモートコピーは、その最初（初期化時）に、「ファイルシステムを介さずに対象論理ボリュームをリモートコピーすること」が、ファイルシステム２０−２に通知され、該通知を受けたファイルシステム２０−２が、「ファイルデータがファイルシステムを介さずに…入力されることと、対象となる論理ボリューム」を、論理ボリューム管理部３０−２に通知するとともに、ファイルシステム２０−１からの通知に対する了承を返送するのであるから、コピー先のファイルシステム２０−２は、当然に、該通知を受けた時に、ファイル形式のデータ記憶用論理ボリューム（３５−ｂ）内の物理領域を確保するとともに、その領域が、該対象論理ボリュームのリモートコピー専用に確保された一ファイル領域であることを区別可能なように管理するはずである他、データのバックアップにおいては、物理ブロックアクセスによって読み出したデータをそのイメージのまま、バックアップ先において１ファイルとして格納する技術自体、例えば「Ｖ２ｉ　Ｐｒｏｔｅｃｔｏｒ」などでも行われているように周知である（もし必要であれば、例えば「特集　大容量時代のデータバックアップ最新アプローチ」（ソフトウェアデザイン２００３年８月号，ｐ．６２〜６５）、「特集１　ハードディスクの活用でバックアップが変わる」（日経Ｗｉｎｄｏｗｓプロ２００３年３月号，ｐ．７６〜７７）、「Ｗｉｎｄｏｗｓ２０００　Ｓｅｒｖｅｒ／Ａｄｖａｎｃｅｄ　Ｓｅｒｖｅｒ専用のバックアップツール」（Ｗｉｎｄｏｗｓ２０００Ｗｏｒｌｄ２００３年４月号，ｐ．９５）、「先進のＶ２ｉテクノロジーを採用した革新的なバックアップ＆復元ツール」（月刊アスキー２００３年８月号，ｐ．３９）等を参照されたい）から、やはり上記主張を採用することはできない。
　
６．まとめ
　したがって、本願発明は、引用発明及び周知の事項に基いて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願発明は引用発明及び周知の事項に基いて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定によ
り特許を受けることができない。
　したがって、本願は、拒絶されるべきものである。
　よって、結論のとおり審決する。