【事件の表示】
　特願２００２−２２４７３２「ファイル格納先ボリューム制御方法」拒絶査定不服審判事件〔平成１６年　３月　４日出願公開、特開２００４−　７０４０３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　　　
１．　手続の経緯
　　　
　本願の手続の経緯は次に示すとおりである。
　　　
平成１４年　８月　１日　特許出願。
平成１９年　３月２０日　拒絶理由通知（起案日）。
平成１９年　６月１５日　手続補正。
平成１９年　８月　６日　拒絶査定（起案日）。
平成１９年　９月２７日　拒絶査定不服審判請求。
平成２０年　１月　９日　手続補正（方式）。
　　　
２．　本願発明
　　　
　本願に係る発明は、平成１９年６月１５日付け手続補正書により補正された明細書の特許請求の範囲の請求項１乃至５に記載されたとおりのものと認められるところ、その請求項１に係る発明（以下、「本願発明」という。）は、次のとおりである。
　　　
＜本願発明＞
「　業務アプリケーションからのファイル格納要求に基づいて複数のボリュームにデータを分散して格納するファイルシステムにおけるファイル格納先ボリューム制御方法であって、
　格納要求を行った業務アプリケーションの種別をキーとして、予め定義された業務アプリケーションの種別毎に必要とされる格納要件である信頼性要件および性能要件を検索することにより、格納要件を算出する格納要件算出ステップと、
　予め静的に定義された各ボリュームの信頼性特性および性能特性と、格納要求のあったファイルの格納要件との突合せによって実際のファイルの格納先ボリュームを算出する格納先ボリューム算出ステップと、
　該算出された格納先ボリュームに基づいてファイル毎にボリュームを振り分けてファイルを格納するファイル格納ステップを有することを特徴とするファイル格納先ボリューム制御方法。」
　　　
　　　
３．　引用例
　　　
　原査定の拒絶の理由に引用された、本願出願前である平成１３年５月２５日に頒布された刊行物である、特開２００１−１４２６４８号公報（以下、「引用例」という。）には、図面とともに以下の記載がある。
　　　
（ａ）　「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、計算機システム、及び、計算機システムにおける計算機への記憶デバイスの割り当て方法に係り、特に、複数の計算機により共用される記憶装置サブシステムを備えた計算機システムにおいて、計算機に対する記憶デバイスの割り当てを行うための方法に関する。
【０００２】
【従来の技術】近年、企業などで利用される計算機システムで扱われる情報量は、飛躍的に増大しており、これに伴いデータを記憶するディスク装置などの容量も増加の一途をたどっている。例えば、磁気ディスク装置においては、数ＴＢ（テラバイト）の容量を持つ装置も珍しくなくなってきている。このようなディスク装置に関して、例えば、特開平９−２７４５４４号公報には、１台の記憶装置サブシステムを複数種類の論理的なディスク装置（以下では、デバイスとも呼ぶ）で構成する技術が開示されている。具体的には、ホストコンピュータからアクセスされるデバイス（論理ディスク）として、ＲＡＩＤ（Redundant Arrays of InexpensiveDisks）におけるＲＡＩＤ５とＲＡＩＤ１のように、ＲＡＩＤレベルの異なるものを混在させ、あるいは、論理ディスクを構成するための実際の磁気ディスク装置（物理ディスク装置）として、アクセス速度の異なるものを混在させたディスクサブシステムが開示されている。ユーザは、各デバイスのアクセス頻度に応じて、デバイスを使い分けることができる。
【０００３】一方、ホスト計算機とディスク装置などの周辺装置との間のインタフェースとして、ファイバチャネル技術が現れたことにより、複数のホスト計算機、複数の記憶装置を１つのファイバチャネルケーブルで接続して計算機システムを構成することも行われるようになってきた。このような計算機システムでは、それぞれのホスト計算機は、ファイバチャネル上の任意の記憶装置に直接アクセスできる。このため、従来ように、各ホスト計算機がそれぞれに記憶装置を持つ場合に比べ、ホスト計算機間でのデータの共有やネットワーク負荷の低減が期待できる。
【０００４】
【発明が解決しようとする課題】上述した従来技術によれば、各ホスト計算機がアクセスできるデバイスの数や種類を飛躍的に増加させることができる。しかし、ホスト計算機がアクセスできるデバイスの数や種類が増加するに伴い、各ホスト計算機でのデバイスの管理が難しくなってくる。１つのホスト計算機から多くのデバイスにアクセスできる利点の一方で、ユーザにとっては、ある業務でどのデバイスを使用すれば良いか選択するといったことが困難となる。特に、ファイバチャネルで接続された計算機システムの場合、あるホスト計算機からそのホスト計算機が本来使用していないデバイスにまでアクセスできることとなる。このため、他のホスト計算機が使用しているデバイスに不正アクセスを起こし、データを破壊してしまうといったことが生じ得る。
【０００５】特開平１０―３３３８３９号公報には、このような問題を解決するため、ファイバチャネルで接続された記憶装置が、特定のホスト計算機からのアクセスだけを許可する方法が開示されている。しかし、記憶装置、デバイスが複数になった場合や、異なる種類のデバイスが混在する場合には、処理が複雑であることには変わりはなく、各ホスト計算機で、それぞれデバイスの種類などを常に意識する必要がある。
【０００６】本発明の目的は、各ホスト計算機が用途に合ったデバイスを必要な時に必要な分だけ利用できるように、デバイスの設定、デバイスの各ホスト計算機への割り当てを容易に行えるようにすることにある。
【０００７】
【課題を解決するための手段】本発明における計算機システムは、その好ましい一つの態様において、複数の計算機と、これら複数の計算機に接続する記憶装置サブシステムとを有する。記憶装置サブシステムは、複数の記憶デバイスと複数のインタフェースとを有し、各計算機に接続される。複数の計算機の１つは、記憶装置サブシステム内の記憶デバイスと、各計算機と記憶装置サブシステムの接続関係の情報を保持する管理手段を有する。各計算機は、新たにデバイスが必要なとき、管理手段にその容量や種類を通知する。管理手段は、その通知を受けて、要求に合った記憶デバイスを選択する。そして選択したデバイスが計算機からアクセスできるように、記憶装置サブシステムに対し所定の情報を設定するように指示する。管理手段は、また、デバイス割り当ての要求の有った計算機に所定の情報を返却し、要求の有った計算機では、その情報に基づき計算機の設定を変更し、当該計算機で割り当てられたデバイスが使用できるようにする。
【０００８】本発明の他の態様において、複数の計算機と複数の記憶装置サブシステムがネットワークを介して接続される。任意の計算機上には、各記憶装置サブシステムが有する記憶デバイスと、各計算機と記憶装置サブシステムの接続関係の情報を保持する管理手段が設けられる。各記憶装置サブシステムは、管理手段から指定された計算機に対してアクセスを許可するための制御手段を有する。各計算機は、新たな記憶デバイスを必要とするとき、管理手段にその容量や種類を通知する。管理手段は、通知に応じて要求に合ったデバイスを選択し、選択したデバイスが新たな記憶デバイスを必要とする計算機からアクセスできるように、記憶装置サブシステムに対し当該計算機からのアクセスを許可するよう指示する。管理手段は、また、デバイス割り当てを要求した計算機に所定の情報を返却する。デバイス割り当てを要求した計算機では、管理手段から返却された情報に基づき、計算機の設定を変更し、その計算機から割り当てられたデバイスが使用できるようにする。
【０００９】
【発明の実施の形態】図１は、本発明が適用された計算機システムの一実施形態における構成例を示す簡略なブロック図である。
【００１０】計算機システムは、複数のホスト計算機、ホスト計算機１ａ、ホスト計算機１ｂ、…ホスト計算機１ｎ（総称してホスト１と呼ぶ）、ホスト1に接続される記憶装置サブシステム２、管理用ホスト計算機３、ネットワーク４、及び遠隔地に配置される記憶装置である副記憶装置５を有して構成される。
【００１１】ホスト計算機１a、１ｂ、…は、ＣＰＵ、メモリなどを有する計算機であり、メモリに格納されたオペレーティングシステム、アプリケーションプログラムをＣＰＵが読み出して実行することで、所定の機能を達成する。
【００１２】記憶装置サブシステム２は、複数のディスクユニット２１、ディスクコントローラ２２、ホスト計算機１と接続する複数のポート２３、副記憶装置５と接続するためのインタフェース２４、ネットワーク４と接続するネットワークインタフェース２５を有している。本実施形態における記憶装置サブシステム２は、複数のディスクユニット２１をまとめて１または複数の論理デバイスとしてホスト計算機１に見せかける。もちろん、個々のディスクユニット２１を１つの論理デバイスとしてホスト計算機１に見せるようにしても良い。
【００１３】ポート２３としては、　・・・（中略）・・・　ＳＣＳＩ（Small Computer System Interface）などのインタフェースが用いられる。　・・・（中略）・・・　本実施形態では、全てのポート２３にインタフェースとして、ＳＣＳＩを用いるものとして説明する。
【００１４】　・・・（中略）・・・　ディスクコントローラ２２は、ネットワークインタフェース２５を介して管理用ホスト計算機３との通信を行う。
【００１５】　　（略）
【００１６】　　（略）
【００１７】各ホスト計算機１ａ、１ｂ…には、ボリュームマネージャ１１と呼ばれるソフトウェア（プログラム）が配置される。ボリュームマネージャ１１は、管理用ホスト計算機３に配置される管理マネージャ３１と通信しあって動作する。各ホスト計算機１は、インタフェース（Ｉ／Ｆ）１２を持っており、インタフェース１２により記憶装置サブシステム２のポート２３と接続される。
【００１８】次に、記憶装置サブシステム２内の論理デバイスの管理形態について説明する。
【００１９】前述の通り、記憶装置サブシステム２は、複数のディスクユニット２１を１または複数の論理デバイスとして、あるいは、個々のディスクユニット２１を１つの論理デバイスとしてホスト計算機１に見せかける。　・・・（中略）・・・　記憶装置サブシステム２内のディスクユニット２１の数と論理デバイスの数に相関関係はない。
【００２０】図２は、記憶装置サブシステム２が論理デバイスを管理するために使用する情報を保持する論理デバイス管理テーブルの一例を示すテーブル構成図である。
【００２１】論理デバイス管理テーブルは、論理デバイス番号６１に対し、サイズ６２、構成６３、状態６４、パス６５、ターゲットＩＤ６６，ＬＵＮ６７の項目の組を保持する。サイズ６２には、論理デバイス番号６１により特定される論理デバイスの容量を表す情報が設定される。
【００２２】構成６３には、当該論理デバイスの構成を示す情報、たとえばディスクユニット２１によりＲＡＩＤ（Redundant Arrays of Inexpensive Disks）が構成され、それが論理デバイスに割り当てられている場合、ＲＡＩＤ１、ＲＡＩＤ５など、ＲＡＩＤの種別を示す情報が設定される。　・・・（中略）・・・　
【００２３】状態６４には、当該論理デバイスの状態を示す情報が設定される。状態としては、「オンライン」、「オフライン」、「未実装」、「障害オフライン」が存在する。「オンライン」は、当該論理デバイスが正常に稼動し、ホスト計算機１からのアクセスが可能な状態であることを示す。「オフライン」は、当該論理デバイスは定義され、正常に稼動しているが、ホスト計算機１からのアクセスはできない状態にあることを示す。この状態は、以前ホスト計算機１で使用されていたが、ホスト計算機１でそのデバイスが不要となって使われなくなった場合に相当する。「未実装」は、当該論理デバイスが定義されておらずホストからのアクセスはできない状態にあることを示す。また「障害オフライン」は、当該論理デバイスに障害が発生してホストからのアクセスができないことを示す。
【００２４】パス６５には、当該論理デバイスが複数のポート２３のどのポートに接続されているかを表す情報が設定される。各ポート２３には、記憶装置サブシステム２内で一意な番号が割り振られており、「パス」欄には論理デバイスが接続されているポート２３の番号が記録される。ターゲットＩＤ６６とＬＵＮ６７は、論理デバイスを識別するための識別子である。ここでは、これらの識別子として、ＳＣＳＩ上でホスト計算機１からデバイスをアクセスする場合に用いられるＳＣＳＩ−ＩＤ、ＬＵＮが用いられる。
【００２５】　　（略）
【００２６】論理デバイス管理テーブルに保持された情報は、ネットワークインタフェース２４を通じて、適当なタイミングで、あるいは記憶装置サブシステム２に障害が発生して構成が変化した、などの際に管理用ホスト計算機３に送られる。このため、管理用ホスト計算機３も、図２に示すテーブルと同様の論理デバイス管理テーブルを保持する。
【００２７】図３は、管理用ホスト計算機３の管理マネージャ３１により保持されるホスト管理テーブルの一例を示すテーブル構成図である。
【００２８】ホスト管理テーブルは、管理用ホスト計算機３が各ホスト計算機１に対するデバイスの割り当てを管理するために、ホスト名７１、ポート番号７２、インタフェース番号７３、論理デバイス番号７４の組で構成される管理情報を保持する。
【００２９】ポート番号７２と論理デバイス番号７４は、記憶装置サブシステム２の内部で定義される番号で、記憶装置サブシステム２の各ポート２３及び論理デバイスを識別するための情報である。ポート番号７２と論理デバイス番号７４には、ホスト名７１に設定された識別子で識別されるホスト計算機１が接続されるポートのポート番号と、そのホスト計算機に割り当てられている論理デバイスのデバイス番号が設定される。
【００３０】インタフェース番号７３は、各ホスト計算機１のインタフェース１２を管理するために付けられた番号である。　・・・（中略）・・・　
【００３１】管理用ホスト計算機３は、ホスト管理テーブルと、記憶装置サブシステム２から送られる論理デバイス管理テーブルを参照して、各ホスト計算機１に論理デバイスを割り当てる。以下、デバイスの割り当ての処理について説明する。
【００３２】図４は、各ホスト計算機１のボリュームマネージャ１１により実施される処理の流れを示すフローチャートである。この処理は、ホスト計算機１を使用するユーザ、またはホスト計算機１で稼動するアプリケーションプログラムなどが新規にデバイスを必要とするときに実施される。
【００３３】ステップ１００１で、ボリュームマネージャ１１は、ユーザ、またはアプリケーションプログラムから必要とされるデバイスの数とデバイスの種類の情報を得る。ユーザ、またはアプリケーションプログラムは、デバイスに関する情報として、その容量、性能条件、信頼性レベルなどの情報を指定する。デバイスの容量とは、先に説明したデバイスのサイズのことである。性能条件としては、例えば、低速ディスクドライブ、高速ディスクドライブ、キャッシュ常駐ディスクドライブといった、デバイスのアクセス速度などの性能に関する情報が指定される。信頼性レベルとしては、例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５、二重パス、リモートミラーなど、デバイスの信頼性に関する情報が指定される。　・・・（中略）・・・　
【００３４】次に、ステップ１００２でボリュームマネージャ１１は、当該ホスト計算機１のインタフェース１２上で使用されていないターゲットＩＤ、ＬＵＮの組を検索する。
【００３５】ステップ１００３でボリュームマネージャ１１は、ステップ１００１において指定された容量、性能条件、信頼性レベル、及びステップ１００２で検索された未使用のターゲットＩＤ、ＬＵＮの組を管理用ホスト計算機３の管理マネージャ３１に送信し、新たなデバイスの割付を要求する。管理マネージャ３１は、受け取った情報に基づいて割り当てるべきデバイスを検索し、そのデバイスのアクセスに使用するホストインタフェース番号、ターゲットＩＤ、及びＬＵＮを指定する情報を返却する。ここで行われる管理マネージャ３１の処理については後述する。
【００３６】ステップ１００４でボリュームマネージャ１１は、管理マネージャ１３からの情報を受け取る。ステップ１００５では、管理マネージャ１３から受け取った情報をもとに、新しいデバイスを使用できるようにホスト計算機１の設定変更が行われる。
【００３７】　　（略）
【００３８】最後にステップ１００６でボリュームマネージャ１１は、割り当てられたデバイスファイル名、ターゲットＩＤ、ＬＵＮの情報をユーザまたはアプリケーションプログラムに通知して処理を終了する。
【００３９】図５は、新しいデバイスの割り当て時に管理用ホスト計算機３の管理マネージャ３１による処理の流れを示すフローチャートである。
【００４０】管理マネージャ３１は、ステップ１１０１でホスト計算機１から送られてきたデバイスサイズ、性能条件、信頼度レベルなどの情報を受け取ると、保持している論理デバイス管理テーブル、及びホスト管理テーブルに設定されている情報を参照し、要求に応じたデバイスが存在するか検索する。ここで検索対象となるデバイスは、論理デバイス管理テーブルの状態６４に「オフライン」が設定されているものである（ステップ１１０２）。管理マネージャ３１は、検索の結果、要求に合った「オフライン」状態のデバイスが見つかったかどうか判別する（ステップ１１０３）。
【００４１】要求に合った「オフライン」状態のデバイスが見つかった場合、管理マネージャ３１は、ホスト計算機１から受け取ったターゲットＩＤ、ＬＵＮの情報と、論理デバイス管理テーブル及びホスト管理テーブルに設定されている情報に基づいて、当該デバイスをホスト計算機１に接続するために使用するポート番号、ターゲットＩＤ、ＬＵＮを決定する（ステップ１１０４）。
【００４２】次に、管理マネージャ３１は、ステップ１１０３で見つけた論理デバイス番号のデバイスを、ステップ１１０４で決定したポート番号、ターゲットＩＤ、ＬＵＮでアクセスできるように設定してオンライン状態にするよう記憶装置サブシステム２に指示する。記憶装置サブシステム２は、管理マネージャ３１からの指示に従って設定を行い、その結果を管理マネージャ３１に返却する（ステップ１１０５）。
【００４３】管理マネージャ３１は、記憶装置サブシステム２から結果を受け取ると（ステップ１１０６）、要求のあったホスト計算機１のボリュームマネージャ１１に対して、インタフェース番号、ターゲットＩＤ、ＬＵＮを返却する（ステップ１１０７）。
【００４４】　　（略）
【００４５】　　（略）
【００４６】　　（略）
【００４７】　　（略）
【００４８】　　（略）
【００４９】　　（略）
【００５０】上述した第１の実施形態では、管理用ホスト計算機を設け、そこに管理マネージャを配置しているが、管理マネージャの機能は必ずしも管理用ホスト計算機に存在する必要はない。例えば、ホスト計算機１ａ、１ｂ、…のいずれかに存在するように構成することも可能である。また、管理マネージャの機能を記憶装置サブシステムに設けることもできる。この場合、各ホスト計算機１ａ、１ｂ、…は、インタフェースを介して直接記憶装置サブシステムとの間で、要求の送出、情報受け取りを行えばよい。」
　　　
（ｂ）　「【０１１５】
【発明の効果】本発明によれば、ホスト計算機に対する記憶デバイスの割り当てを必要に応じて動的に行うことができる。」
　　　
　ここで、上記引用例の（ａ），（ｂ）の記載事項及び関連する【図１】、【図２】、【図３】、【図４】、【図５】等の図面からみて、引用例には次の事項が示されているといえる。
　　　
・　引用例の上記段落【００２６】には、
「管理用ホスト計算機３も、図２に示すテーブルと同様の論理デバイス管理テーブルを保持する。」
と記載されているから、引用例の【図１】の管理用ホスト（３）にも、【図２】と同様の論理デバイス管理テーブルが保持されている。
・　引用例の上記段落【００４０】には、
「管理マネージャ３１は、ステップ１１０１でホスト計算機１から送られてきたデバイスサイズ、性能条件、信頼度レベルなどの情報を受け取ると、保持している論理デバイス管理テーブル、及びホスト管理テーブルに設定されている情報を参照し、要求に応じたデバイスが存在するか検索する。」
と記載されているから、引用例の【図２】に示されている論理デバイス管理テーブルには、（ｉ）デバイスサイズ、（ｉｉ）性能条件、及び、（ｉｉｉ）信頼度レベルに対応する同種の情報が、論理デバイス番号（【図２】の６１）毎に、（ｉ）サイズ（６２）、（ｉｉ）性能条件に対応する情報、及び、（ｉｉｉ）構成（６３）（例えば、ＲＡＩＤ１、ＲＡＩＤ５などの別。）としてそれぞれ記録されている。
　　　
　そして、上記引用例の（ａ），（ｂ）の記載事項、関連する【図１】、【図２】、【図３】、【図４】、【図５】等の図面、及び、上記事項から、引用例には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　　　
＜引用発明＞
「　アプリケーションプログラムからのデータを記憶させる要求に基づいて複数の論理デバイスにデータを分散して記憶するデータ記憶システムにおける、データ記憶先の論理デバイスを割り当てる方法であって、
　データを記憶させる要求を行ったアプリケーションプログラムが指定した、デバイスに関する情報であって、予め定義された様々なアプリケーションプログラムのそれぞれが必要とするデバイスに関する情報である、信頼性レベル（例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５、二重パス、リモートミラーなどの別。）および性能条件（例えば、低速ディスクドライブ、高速ディスクドライブ、キャッシュ常駐ディスクドライブといった、デバイスのアクセス速度などの性能に関する情報。）を、記憶すべきデバイスに関する情報とすることにより、記憶すべきデバイスに関する情報を決定する第１のステップと、
　論理デバイス管理テーブル（【図２】）に予め静的に定義された、各論理デバイス番号（６１）毎の構成（６３）（例えば、ＲＡＩＤ１、ＲＡＩＤ５などの別。）および性能条件に対応する情報と、記憶させる要求のあったデータについての記憶すべきデバイスに関する情報である、信頼性レベルおよび性能条件との突合せによって、実際のデータの記憶先論理デバイスを検索する第２のステップと、
　該検索された記憶先論理デバイスに基づいて論理デバイスを振り分けてデータを記憶する第３のステップを有する、データ記憶先の論理デバイスを割り当てる方法。」
　　　
　　　
４．　対比
　　　
　本願発明と引用発明とを比較すると、次のことがいえる。
　　　
（１）　引用発明における「アプリケーションプログラム」は、本願発明における「業務アプリケーション」に相当する。
（２）　引用発明における「データ」は、本願発明における「データ」に相当する。
（３）　引用発明において、データを記憶していることは、本願発明において、データを格納していることに相当する。
（４）　引用発明における「データを記憶させる要求」は、本願発明における「格納要求」に相当する。
（５）　引用発明における「論理デバイス」は、本願発明における「ボリューム」に相当する。
（６）　引用発明における「データ記憶システム」は、本願発明における「システム」に相当する。
（７）　引用発明における「データ記憶先の論理デバイスを割り当てる方法」は、本願発明における「格納先ボリューム制御方法」に相当する。
（８）　引用発明における「デバイスに関する情報」及び「記憶すべきデバイスに関する情報」は、本願発明における「格納要件」に相当する。
（９）　引用発明における「信頼性レベル（例えば、ＲＡＩＤ０、ＲＡＩＤ１、ＲＡＩＤ５、二重パス、リモートミラーなどの別。）」は、本願発明における「信頼性要件」に相当する。
（１０）　引用発明における「性能条件（例えば、低速ディスクドライブ、高速ディスクドライブ、キャッシュ常駐ディスクドライブといった、デバイスのアクセス速度などの性能に関する情報。）」は、本願発明における「性能要件」に相当する。
（１１）　引用発明における「第１のステップ」は、本願発明における「格納要件算出ステップ」に対応している。ただし、引用発明の該第１のステップは、アプリケーションプログラムが指定したデバイスに関する情報をそのまま記憶すべきデバイスに関する情報としているのに対し、本願発明の該格納要件算出ステップは、業務アプリケーションの種別をキーとして、格納要件を検索することによって、格納要件を算出している。
（１２）　引用発明における「論理デバイス管理テーブル（【図２】）に予め静的に定義された、各論理デバイス番号（６１）毎の構成（６３）（例えば、ＲＡＩＤ１、ＲＡＩＤ５などの別。）および性能条件に対応する情報」は、本願発明における「予め静的に定義された各ボリュームの信頼性特性および性能特性」に相当する。
（１３）　引用発明における「記憶先論理デバイス」は、本願発明における「格納先ボリューム」に相当し、引用発明において、実際のデータの記憶先論理デバイスを検索していることは、本願発明において、実際のファイルの格納先ボリュームを算出していることに相当する。
（１４）　引用発明における「第２のステップ」は、本願発明における「格納先ボリューム算出ステップ」に相当する。
（１５）　引用発明における「第３のステップ」は、本願発明における「ファイル格納ステップ」に相当する。
　　　
　してみると、本願発明と引用発明とは次の点で一致する。
　　　
＜一致点＞
「　業務アプリケーションからの格納要求に基づいて複数のボリュームにデータを分散して格納するシステムにおける格納先ボリューム制御方法であって、
　格納要求を行った業務アプリケーションが指定した格納要件であって、予め定義された業務アプリケーションの種別毎に必要とされる格納要件である信頼性要件および性能要件を格納要件とすることにより、格納要件を決定する格納要件決定ステップと、
　予め静的に定義された各ボリュームの信頼性特性および性能特性と、格納要求のあったデータの格納要件との突合せによって実際のデータの格納先ボリュームを算出する格納先ボリューム算出ステップと、
　該算出された格納先ボリュームに基づいてボリュームを振り分けてデータを格納する格納ステップを有する格納先ボリューム制御方法。」
　　　
　一方で、本願発明と引用発明とは次の点で相違する。
　　　
＜相違点１＞
　本願発明は、業務アプリケーションの種別をキーとして、格納要件を検索することによって、格納要件を算出しているものであるのに対し、引用発明は、アプリケーションプログラムが指定したデバイスに関する情報をそのまま記憶すべきデバイスに関する情報としているものである点。
　　　
＜相違点２＞
　本願発明は、ファイル毎にボリュームを振り分けてファイルを格納するものであるのに対し、引用発明は、本願発明に係るボリュームに相当している論理デバイスを振り分けてデータを記憶するものではあるものの、その振り分け及び格納をファイル毎にすることが引用発明には示されていない点。
　　　
　　　
５．　判断
　
　上記相違点について検討する。
　　　
＜相違点１について＞
　引用発明は、アプリケーションプログラムのそれぞれが必要とするデバイスに関する情報を、当該アプリケーションプログラムそれ自体が指定しているものであるから、引用発明におけるアプリケーションプログラムのそれぞれが必要とするデバイスに関する情報は、当該アプリケーションプログラムの種別をキーとして決定されている情報であるといえる。また、必要となる情報を決定するために、当該必要となる情報をテーブルとして持っておくこと、及び、当該テーブルを検索することによって当該必要となる情報を決定することは、本願出願前の慣用の手法であるから、引用発明においてアプリケーションプログラムのそれぞれが必要とするデバイスに関する情報を、当該アプリケーションプログラムの種別毎にテーブルとして持っておき、このテーブルをアプリケーションプログラムの種別をキーとして検索することにより当該アプリケーションプログラムが必要としているデバイスに関する情報を算出するように構成することは、当業者が普通に推考できたことである。してみると、引用発明において、業務アプリケーションの種別をキーとして格納要件を検索することによって格納要件を算出するように構成することは、当業者が容易になし得たことである。
　　　
＜相違点２について＞
　コンピュータを用いてデータを記憶するシステムにおいて、アプリケーションプログラムからのデータをファイル毎に記憶することは、本願出願前から通常行われていたことであるから、引用発明において、論理デバイスを振り分けてデータを記憶する際に、データをファイル単位で扱うことによって、データをファイル毎に振り分けて記憶することは、当業者が普通に推考できたことである。してみると、引用発明において、ファイル毎にボリュームを振り分けてファイルを格納するように構成することは、当業者が容易になし得たことである。
　　　
　また、本願発明の構成によってもたらされる効果も、引用発明及び周知技術から当業者が予測することができた程度のものであって、格別のものとは認められない。
　　　
　　　
６．　むすび
　　　
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　したがって、その余の請求項について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。