【事件の表示】
　特願２００７−　５５９０５「ストレージ装置及びその構成最適化方法」拒絶査定不服審判事件〔平成２０年　９月１８日出願公開、特開２００８−２１７５７５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続きの経緯・本願発明
　本願は、平成１９年３月６日の出願であり、平成２３年２月２８日付けで拒絶査定がなされ、それに対して同年６月８日に拒絶査定不服の審判請求がなされたものであって、その請求項１に係る発明は、特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下、「本願発明」という。）
「キャッシュメモリを論理的に分割してキャッシュセグメントを構成し、分割されたパーティションとともに提供するストレージ装置であって、
　前記各キャッシュセグメントに対するアクセス負荷を監視し、該アクセス負荷に応じて、未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部と、
　キャッシュメモリの増設を検知し、前記キャッシュセグメント割り当て制御部に通知するキャッシュメモリ増設監視部と、を備えたこと、
　を特徴とするストレージ装置。」
　　　
第２　引用文献
（１）原査定の拒絶の理由に引用された特開２００６−２６０２８４号公報（以下、「引用文献１」という。）には、図面とともに次の記載がある。
（ア）「【０００３】
　ストレージコンソリデーションの運用形態として、本発明者は、ストレージサブシステムのリソースを複数のパーティションに論理分割し、各パーティションを独立したストレージサブシステムとしてユーザに提供するＳＬＰＲ（Storage Logical Partition）機能をストレージサブシステムに実装することを検討した。」（段落【０００３】）
　　　
（イ）「【００１８】
　以下、各図を参照して、本発明の実施形態について説明する。
　図１は本実施形態に係るストレージサブシステム６００の全体的なシステム構成を示している。ストレージサブシステム６００は、主に、ディスク制御装置１００と、記憶装置３００とから構成される。ディスク制御装置１００は、例えば、情報処理装置２００から受信したコマンドに従って、記憶装置３００へのデータの入出力制御を行う。また、ディスク制御装置１００は、例えば、管理サーバ７００から受信したコマンドに従って、ストレージサブシステム６００の構成情報の設定又は変更等の各種の処理を行う。
【００１９】
　情報処理装置２００は、例えば、パーソナルコンピュータ、ワークステーション、或いはメインフレームコンピュータ等の上位装置であり、銀行の自動預金預け払いシステムや、航空機の座席予約システム等に利用される。ストレージサブシステム６００は、ＳＬＰＲ（Storage Logical Partition）機能を搭載しており、一台のストレージサブシステム６００を複数のユーザが共用することができる。例えば、ユーザＡが情報処理装置１，２（２００）を所有し、ユーザＢが情報処理装置３，４，５（２００）を所有して、システムを運用することができる。」（段落【００１８】、【００１９】）
　　　　　　　　　　
（ウ）「【００２３】
　記憶装置３００は、複数の物理ディスクドライブ３３０を備えている。物理ディスクドライブ３３０は、例えば、ＡＴＡ（Advanced Technology Attachment）ディスクドライブ、ＳＣＳＩ（Small Computer System Interface）ディスクドライブ、ファイバチャネルディスクドライブ等のハードディスクドライブである。アレイ状に配列された複数のディスクドライブによって、ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）を構成することも可能であり、一つのＲＡＩＤを構成する複数のハードディスクドライブをＥＣＣグループと称する。また、物理ディスクドライブ３３０により提供される物理的な記憶領域である物理ボリュームには、論理的な記憶領域であるＬＤＥＶを設定することができる。
【００２４】
　ディスク制御装置１００と記憶装置３００との間は、ネットワークを介さずに直接に接続してもよく、或いはネットワークを介して接続してもよい。或いは、記憶装置３００とディスク制御装置１００を一体構成としてもよい。
【００２５】
　ディスク制御装置１００は、チャネル制御部１１０、共有メモリ１２０、キャッシュメモリ１３０、ディスク制御部１４０、管理端末１６０、及び接続部１５０を備える。」（段落【００２３】〜【００２５】）
　　　　
（エ）「【００２８】
　共有メモリ１２０とキャッシュメモリ１３０は、それぞれチャネル制御部１１０とディスク制御部１４０とによって共有されるメモリ装置である。共有メモリ１２０は、主として、リソースの構成情報や各種コマンド等を記憶するために利用される。キャッシュメモリ１３０は、主として、物理ディスク３３０に読み書きされるデータを一時的に記憶するために利用される。
【００２９】
　尚、共有メモリ１２０には、ＳＬＰＲのリソース管理を行うためのストレージ管理者テーブル９０１、ＬＤＥＶパーティションテーブル９０２、ポートパーティションテーブル９０３、キャッシュパーティションアドレステーブル９０４、キャッシュパーティションテーブル９０５、ＬＤＥＶ割り当て状態テーブル９０６、ポート割り当て状態テーブル９０７、キャッシュ割り当て状態テーブル９０８、ＳＬＰＲ割り当て状態テーブル９０９が格納されている（図１４〜図２２参照）。これらのテーブル９０１〜９０８の詳細については、後述する。」（段落【００２８】、【００２９】）
　　　
（オ）「【００４０】
　管理端末１６０は、ストレージサブシステム６００を管理するためのコンピュータである。サブシステム管理者又はパーティション管理者は、管理端末１６０を操作することにより、例えば、ＳＬＰＲのリソース管理、物理ディスクドライブ３３０の構成の設定、情報処理装置２００とチャネル制御部１１０との間のパスの設定、チャネル制御部１１０やディスク制御部１４０において実行されるマイクロプログラムのインストール等を行うことができる。ここで、ＳＬＰＲのリソース管理とは、例えば、各ＳＬＰＲへのリソース（ポート、ＬＤＥＶ、キャッシュメモリ等）の割り当て、追加、削除等の設定をいう。物理ディスクドライブ３３０の構成の設定とは、例えば、物理ディスクドライブ３３０の増設或いは減設、ＲＡＩＤ構成の変更（例えば、ＲＡＩＤ１からＲＡＩＤ５への変更）等をいう。更に、管理端末１６０からは、ストレージサブシステム６００の動作状態の確認や故障部位の特定、チャネル制御部１１０で実行されるオペレーティングシステムのインストール等の作業を行うこともできる。これら各種の設定や制御は、管理端末１６０が備えるユーザインターフェースを通じて行うことができる。
【００４１】
　管理端末１６０は、ディスク制御装置１００に内蔵してもよく、或いは外付けの構成としてもよい。また、管理端末１６０は、ディスク制御装置１００及び記憶装置３００の管理専用に用意されたコンピュータでもよく、或いは汎用のコンピュータにストレージシステム６００の管理機能を実装させたものでもよい。」（段落【００４０】、【００４１】）
　　
（カ）「【００４７】
　図６はストレージサブシステム６００とストレージ管理ソフトウェア８００におけるグルーピングの対応関係を示している。ストレージサブシステム６００側のリソース設定では、ＳＬＰＲ１にポート１、キャッシュメモリ１、ＬＤＥＶ１〜４が割り当てられ、ＳＬＰＲ２にポート２、キャッシュメモリ２、ＬＤＥＶ５〜７が割り当てられ、ＳＬＰＲ３にポート３、キャッシュメモリ３、ＬＤＥＶ８〜１０が割り当てられるようにグルーピングされている。ポート１〜３は、チャネル制御部１１０が備える通信ポートが論理的に分割された分割単位である。キャッシュメモリ１〜３は、キャッシュメモリ１３０の記憶領域が論理的に分割された分割単位である。ＬＤＥＶ１〜１０は、複数の物理ディスク３３０が提供するＬＤＥＶである。」（段落【００４７】）　　　　
　　
（キ）「【００６０】
　図１５はＬＤＥＶパーティションテーブル９０２を示している。同テーブル９０２は、各ＬＤＥＶがどのＳＬＰＲに属しているかを示すテーブルであり、「ＳＬＰＲ番号」と「ＬＤＥＶ番号」が対応付けられて登録されている。尚、ＳＬＰＲ番号「０」は、何れのＳＬＰＲにも属しない全てのリソースに付与される。
【００６１】
　図１６はポートパーティションテーブル９０３を示している。同テーブル９０３は、各ポートがどのＳＬＰＲに属しているかを示すテーブルであり、「ＳＬＰＲ番号」と「ポート番号」が対応付けられて登録されている。
【００６２】
　図１７はキャッシュパーティションアドレステーブル９０４を示している。同テーブル９０４は、論理分割された分割単位としての個々のキャッシュメモリのアドレス領域を示すテーブルであり、「キャッシュ番号」と「アドレス領域」が対応付けられて登録されている。
【００６３】
　図１８はキャッシュパーティションテーブル９０５を示している。同テーブル９０５は、論理分割された分割単位としての個々のキャッシュメモリがどのＳＬＰＲに属しているかを示すテーブルであり、「ＳＬＰＲ番号」と「キャッシュ番号」が対応付けられて登録されている。
【００６４】
　図１９はＬＤＥＶ割り当て状態テーブル９０６を示している。同テーブル９０６は、各ＬＤＥＶがＳＬＰＲに割り当てられているか否かを示すテーブルであり、「ＬＤＥＶ番号」と「割り当て状態」が対応付けられて登録されている。具体的には、ＬＤＥＶがどのＳＬＰＲにも割り当てられていない場合には、「割り当て状態」の項目には「０」が登録され、ＬＤＥＶが何れかのＳＬＰＲに割り当てられている場合には、「割り当て状態」の項目には「ＳＬＰＲ番号」が登録される。
【００６５】
　図２０はポート割り当て状態テーブル９０７を示している。同テーブル９０７は、各ポートがＳＬＰＲに割り当てられているか否かを示すテーブルであり、「ポート番号」と「割り当て状態」が対応付けられて登録されている。具体的には、ポートがどのＳＬＰＲにも割り当てられていない場合には、「割り当て状態」の項目には「０」が登録され、ポートが何れかのＳＬＰＲに割り当てられている場合には、「割り当て状態」の項目には「ＳＬＰＲ番号」が登録される。
【００６６】
　図２１はキャッシュ割り当て状態テーブル９０８を示している。同テーブル９０８は、論理分割された分割単位としての個々のキャッシュメモリがＳＬＰＲに割り当てられているか否かを示すテーブルであり、「キャッシュ番号」と「割り当て状態」が対応付けられて登録されている。具体的には、キャッシュメモリがどのＳＬＰＲにも割り当てられていない場合には、「割り当て状態」の項目には「０」が登録され、キャッシュメモリが何れかのＳＬＰＲに割り当てられている場合には、「割り当て状態」の項目には「ＳＬＰＲ番号」が登録される。
【００６７】
　図２２はＳＬＰＲ割り当て状態テーブル９０９を示している。同テーブル９０９は、各ＳＬＰＲにリソース（ポート、ＬＤＥＶ、キャッシュメモリ等）が一つでも割り当てられているか否かを示すテーブルであり、「ＳＬＰＲ番号」と「割り当て状態」が対応付けられて登録されている。具体的には、ＳＬＰＲにポート、ＬＤＥＶ、キャッシュメモリ等の何れのリソースも全く割り当てられていない場合には、「０」が登録され、ＳＬＰＲにポート、ＬＤＥＶ、キャッシュメモリ等の何れかのリソースが割り当てられている場合には、「１」が登録される。
【００６８】
　図２３はストレージサブシステム６００のＳＬＰＲ構成変更を行う各処理手順を概略的に記述したシーケンス図である。ユーザがスーパーユーザに対して、論理グループの構成変更要求を行うと（Ｓ１０１）、これを受けて、スーパーユーザはサブシステム管理者に対して、ＳＬＰＲの構成変更要求を行う（Ｓ１０２）。すると、サブシステム管理者は、管理端末１６０が提供するユーザインターフェースを通じて、管理端末１６０に対して、ＳＬＰＲの構成変更要求を行う（Ｓ１０３）。これを受けて、管理端末は、ＳＬＰＲ構成変更処理を実行する（Ｓ１０４）。ＳＬＰＲ構成変更処理の詳細については後述する。」（段落【００６０】〜【００６８】）
　　　
（ク）「【００７２】
　ログインユーザがサブシステム管理者である場合であって（Ｓ２０３；ＹＥＳ）、ＳＬＰＲの削除が要求されている場合には（Ｓ２０４；ＹＥＳ）、管理端末１６０は、ＳＬＰＲ削除処理を行う（Ｓ２０５）。ＳＬＰＲ削除処理の詳細については、後述する。ＳＬＰＲの削除が要求されていない場合であって（Ｓ２０４；ＮＯ）、ＳＬＰＲ作成処理が要求されている場合には、管理端末１６０は、ＳＬＰＲ作成処理を行う（Ｓ２０６）。ＳＬＰＲ作成処理の詳細については、後述する。尚、ＳＬＰＲにリソースを追加する場合には、一旦、当該ＳＬＰＲを削除してから、新規に作成し直す必要がある。
【００７３】
　図２５は上述したユーザＩＤ及びパスワード認証処理ルーチン（Ｓ２０１）を記述したフローチャートである。この認証処理においては、管理端末１６０は、共有メモリ１２０に格納されているストレージ管理者テーブル９０１を参照することにより、ログインユーザがアクセス権限者であるか否かを判断する。管理端末１６０は、ユーザＩＤが正しく（Ｓ３０１；ＹＥＳ）、しかもパスワードが正しい場合に（Ｓ３０２；ＹＥＳ）、認証が成功したものと判断する。一方、ユーザＩＤが正しくないか（Ｓ３０１；ＮＯ）、或いはパスワードが正しくない場合には（Ｓ３０２；ＮＯ）、管理端末１６０は、認証が失敗したものと判断する（Ｓ３０３）。
【００７４】
　図２６はＳＬＰＲ削除処理ルーチン（Ｓ２０５）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、共有メモリ１２０に格納されているＳＬＰＲ割り当て状態テーブル９０９を参照し、割り当て状態が「１」に設定されているＳＬＰＲを表示する（Ｓ４０１）。次いで、管理端末１６０は、リソース削除処理を行う（Ｓ４０２）。リソース削除処理の詳細については、後述する。そして、更にＳＬＰＲを削除する必要がある場合は（Ｓ４０３；ＹＥＳ）、管理端末１６０は、Ｓ４０１の処理に戻る。ＳＬＰＲを削除する必要がない場合は（Ｓ４０３；ＮＯ）、管理端末１６０は、ＳＬＰＲ削除処理ルーチンを抜ける。
【００７５】
　図２７はリソース削除処理ルーチン（Ｓ４０２）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、ＬＤＥＶパーティションテーブル９０２を参照し、削除対象のＳＬＰＲに属するＬＤＥＶ番号を全て削除するとともに、この削除したＬＤＥＶ番号をＳＬＰＲ番号「０」のＬＤＥＶ番号に追加する（Ｓ５０１）。そして、管理端末１６０は、ＬＤＥＶ割り当て状態テーブル９０６を参照し、削除されたＬＤＥＶ番号の割り当て状態を「０」にする（Ｓ５０２）。
【００７６】
　次いで、管理端末１６０は、ポートパーティションテーブル９０３を参照し、削除対象のＳＬＰＲに属するポート番号を全て削除するとともに、この削除したポート番号をＳＬＰＲ番号「０」のポート番号に追加する（Ｓ５０３）。そして、管理端末１６０は、ポート割り当て状態テーブル９０７を参照し、削除されたポート番号の割り当て状態を「０」にする（Ｓ５０４）。
【００７７】
　次いで、管理端末１６０は、キャッシュパーティションテーブル９０５を参照し、削除対象のＳＬＰＲに属するキャッシュ番号を全て削除するとともに、この削除したキャッシュ番号をＳＬＰＲ番号「０」のキャッシュ番号に追加する（Ｓ５０５）。そして、管理端末１６０は、キャッシュ割り当て状態テーブル９０８を参照し、削除されたキャッシュ番号の割り当て状態を「０」にする（Ｓ５０６）。
【００７８】
　次いで、管理端末１６０は、ＳＬＰＲ割り当て状態テーブル９０９を参照し、削除対象のＳＬＰＲ番号の割り当て状態を「０」にする（Ｓ５０７）。そして、管理端末１６０は、ストレージ管理者テーブル９０１の管理対象から削除対象のＳＬＰＲを削除する（Ｓ５０８）。
【００７９】
　図２８はＳＬＰＲ作成処理ルーチン（Ｓ２０６）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、ＳＬＰＲ割り当て状態テーブル９０９を参照して、ポート、ＬＤＥＶ、キャッシュメモリ等の全てのリソースが未割り当てのＳＬＰＲ番号を表示する（Ｓ６０１）。次いで、管理端末１６０は、ＬＤＥＶ割り当て状態テーブル９０６を参照して、ＳＬＰＲに未割り当てなＬＤＥＶ番号を表示する（Ｓ６０２）。そして、選択されたＬＤＥＶ番号を、選択されたＳＬＰＲに追加する処理を行う（Ｓ６０３）。ＬＤＥＶ番号追加処理の詳細については、後述する。
【００８０】
　次いで、管理端末１６０は、ポート割り当て状態テーブル９０６を参照して、ＳＬＰＲに未割り当てなポート番号を表示する（Ｓ６０４）。そして、選択されたポート番号を、選択されたＳＬＰＲに追加する処理を行う（Ｓ６０５）。ポート番号追加処理の詳細については、後述する。
【００８１】
　次いで、管理端末１６０は、キャッシュ割り当て状態テーブル９０８を参照して、ＳＬＰＲに未割り当てなキャッシュ番号を表示する（Ｓ６０６）。そして、選択されたキャッシュ番号を、選択されたＳＬＰＲに追加する処理を行う（Ｓ６０７）。キャッシュ番号追加処理の詳細については、後述する
【００８２】
　次いで、更にＳＬＰＲ作成を行う場合には（Ｓ６０８；ＹＥＳ）、管理端末１６０は、Ｓ６０１の処理に戻る。ＳＬＰＲ作成を行わない場合には（Ｓ６０８；ＮＯ）、管理端末１６０は、ＳＬＰＲ作成処理ルーチンを抜ける。
【００８３】
　図２９はＬＤＥＶ番号追加処理ルーチン（Ｓ６０３）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、ＬＤＥＶパーティションテーブル９０２を参照して、選択されたＳＬＰＲ番号に、選択された全てのＬＤＥＶ番号を追加するとともに、その追加したＬＤＥＶ番号をＳＬＰＲ番号「０」から削除する（Ｓ７０１）。次いで、管理端末１６０は、ＬＤＥＶ割り当て状態テーブル９０６を参照して、選択された全てのＬＤＥＶ番号の割り当て状態を、選択されたＳＬＰＲ番号に変更する（Ｓ７０２）。
【００８４】
　図３０はポート番号追加処理ルーチン（Ｓ６０５）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、ポートパーティションテーブル９０３を参照して、選択されたＳＬＰＲ番号に、選択された全てのポート番号を追加するとともに、その追加したポート番号をＳＬＰＲ番号「０」から削除する（Ｓ８０１）。次いで、管理端末１６０は、ポート割り当て状態テーブル９０７を参照して、選択された全てのポート番号の割り当て状態を、選択されたＳＬＰＲ番号に変更する（Ｓ８０２）。
【００８５】
　図３１はキャッシュ番号追加処理ルーチン（Ｓ６０７）を記述したフローチャートである。同ルーチンが呼び出されると、管理端末１６０は、キャッシュパーティションテーブル９０５を参照して、選択されたＳＬＰＲ番号に、選択された全てのキャッシュ番号を追加するとともに、その追加したキャッシュ番号をＳＬＰＲ番号「０」から削除する（Ｓ９０１）。次いで、管理端末１６０は、キャッシュ割り当て状態テーブル９０８を参照して、選択された全てのキャッシュ番号の割り当て状態を、選択されたＳＬＰＲ番号に変更する（Ｓ９０２）。」（段落【００７２】〜【００８５】）
　　　
（ケ）「【００９７】
　ここで、上述のＳ１００５の処理において、グルーピングの反映確認を求める理由について説明する。ＳＬＰＲ機能を搭載したストレージサブシステム６００においては、リソースを複数のユーザに提供するために、パーティション分割するだけでなく、ストレージサブシステム６００自体の性能保証の観点から、パーティション分割する場合もある。例えば、ＬＤＥＶには、アクセス頻度が多いＬＤＥＶや、アクセス頻度は少ないが一定の性能を保証したいＬＤＥＶなど、様々なタイプのＬＤＥＶが存在する。このような場合、同じ種類のＬＤＥＶをまとめて、ＳＬＰＲとしてグルーピングすることにより、ストレージサブシステム６００の性能を保証する場合がある。例えば、図３７において、ＬＤＥＶ１，５，８はアクセス頻度が多いＬＤＥＶであり、ＬＤＥＶ４，７，８はアクセス頻度が少ないが一定の性能を保証したいＬＤＥＶであり、ＬＤＥＶ２，３，６，９はその他のＬＤＥＶであるとすると、アクセス頻度が高いＬＤＥＶ１，５，８をまとめて、ＳＬＰＲ１としてグルーピングすることで、ＳＬＰＲ１以外の他のＬＤＥＶのアクセス性能低下を防ぐことができる。また、一定の性能を保証したいＬＤＥＶ４，７，８に入出力されるデータを一時的に記憶するキャッシュメモリ２に多くの記憶領域を割り当てることで、ストレージサブシステム６００の性能を保証することができる。」（段落【００９７】）
　　
　以上の記載によれば、この引用文献１には以下のような発明（以下、「引用発明」という。）が開示されていると認められる。
「ディスク制御装置１００と、複数の物理ディスクドライブ３３０を備える記憶装置３００とから構成され、ストレージサブシステムのリソースを複数のパーティションに論理分割し、各パーティションを独立したストレージサブシステムとしてユーザに提供するＳＬＰＲ（Storage Logical Partition）機能を実装するストレージサブシステム６００であって、
　前記ディスク制御装置１００は、チャネル制御部１１０、共有メモリ１２０、キャッシュメモリ１３０、ディスク制御部１４０、管理端末１６０、及び接続部１５０を備えており、
　管理端末１６０は、ストレージサブシステム６００を管理するためのコンピュータであり、ディスク制御装置１００に内蔵してもよく、
　サブシステム管理者は、管理端末１６０を操作することにより、ＳＬＰＲのリソース管理等を行うことができ、ここで、ＳＬＰＲのリソース管理とは、例えば、各ＳＬＰＲへのリソース（ポート、ＬＤＥＶ、キャッシュメモリ等）の割り当て、追加、削除等の設定をいい、例えば、ＳＬＰＲ１にポート１、キャッシュメモリ１、ＬＤＥＶ１〜４が割り当てられ、ＳＬＰＲ２にポート２、キャッシュメモリ２、ＬＤＥＶ５〜７が割り当てられ、ＳＬＰＲ３にポート３、キャッシュメモリ３、ＬＤＥＶ８〜１０が割り当てられるようにグルーピングされ、ポート１〜３は、チャネル制御部１１０が備える通信ポートが論理的に分割された分割単位であり、キャッシュメモリ１〜３は、キャッシュメモリ１３０の記憶領域が論理的に分割された分割単位であり、ＬＤＥＶ１〜１０は、複数の物理ディスク３３０が提供するＬＤＥＶであり、
　共有メモリ１２０には、ＳＬＰＲのリソース管理を行うためのストレージ管理者テーブル９０１、ＬＤＥＶパーティションテーブル９０２、ポートパーティションテーブル９０３、キャッシュパーティションアドレステーブル９０４、キャッシュパーティションテーブル９０５、ＬＤＥＶ割り当て状態テーブル９０６、ポート割り当て状態テーブル９０７、キャッシュ割り当て状態テーブル９０８、ＳＬＰＲ割り当て状態テーブル９０９が格納されており、
　キャッシュパーティションテーブル９０５は、論理分割された分割単位としての個々のキャッシュメモリがどのＳＬＰＲに属しているかを示すテーブルであり、「ＳＬＰＲ番号」と「キャッシュ番号」が対応付けられて登録され、キャッシュ割り当て状態テーブル９０８は、論理分割された分割単位としての個々のキャッシュメモリがＳＬＰＲに割り当てられているか否かを示すテーブルであり、「キャッシュ番号」と「割り当て状態」が対応付けられて登録、具体的には、キャッシュメモリがどのＳＬＰＲにも割り当てられていない場合には、「割り当て状態」の項目には「０」が登録され、キャッシュメモリが何れかのＳＬＰＲに割り当てられている場合には、「割り当て状態」の項目には「ＳＬＰＲ番号」が登録され、ＳＬＰＲ割り当て状態テーブル９０９は、各ＳＬＰＲにリソース（ポート、ＬＤＥＶ、キャッシュメモリ等）が一つでも割り当てられているか否かを示すテーブルであり、「ＳＬＰＲ番号」と「割り当て状態」が対応付けられて登録、具体的には、ＳＬＰＲにポート、ＬＤＥＶ、キャッシュメモリ等の何れのリソースも全く割り当てられていない場合には、「０」が登録され、ＳＬＰＲにポート、ＬＤＥＶ、キャッシュメモリ等の何れかのリソースが割り当てられている場合には、「１」が登録されており、
　ＳＬＰＲの構成変更要求を行うと、サブシステム管理者は、管理端末１６０が提供するユーザインターフェースを通じて、管理端末１６０に対して、ＳＬＰＲの構成変更要求を行い、管理端末１６０は、ＳＬＰＲ構成変更処理を実行し、
　管理端末１６０は、ＳＬＰＲ構成変更処理において、キャッシュパーティションテーブル９０５を参照し、削除対象のＳＬＰＲに属するキャッシュ番号を全て削除するとともに、この削除したキャッシュ番号をＳＬＰＲ番号「０」のキャッシュ番号に追加し、キャッシュ割り当て状態テーブル９０８を参照し、削除されたキャッシュ番号の割り当て状態を「０」にし、ＳＬＰＲ割り当て状態テーブル９０９を参照し、削除対象のＳＬＰＲ番号の割り当て状態を「０」にし、ストレージ管理者テーブル９０１の管理対象から削除対象のＳＬＰＲを削除し、
　ＳＬＰＲ作成処理ルーチンが呼び出されると、ＳＬＰＲ割り当て状態テーブル９０９を参照して、ポート、ＬＤＥＶ、キャッシュメモリ等の全てのリソースが未割り当てのＳＬＰＲ番号を表示し、ＬＤＥＶ割り当て状態テーブル９０６を参照して、ＳＬＰＲに未割り当てなＬＤＥＶ番号を表示し、選択されたＬＤＥＶ番号を、選択されたＳＬＰＲに追加する処理を行い、
ポート割り当て状態テーブル９０６を参照して、ＳＬＰＲに未割り当てなポート番号を表示し、選択されたポート番号を、選択されたＳＬＰＲに追加する処理を行い、
　キャッシュ割り当て状態テーブル９０８を参照して、ＳＬＰＲに未割り当てなキャッシュ番号を表示し、選択されたキャッシュ番号を、選択されたＳＬＰＲに追加する処理を行うこと、
を特徴とするストレージサブシステム。」
　　
（２）同じく、原査定において引用された特開２００７−２６０６４号公報（以下、「引用文献２」という。）には、図面とともに次の記載がある。
（ア）「【００１５】
　通常、ストレージ装置は、一つのキャッシュメモリを備える。また、ストレージ装置は、複数のサーバに接続されている。この場合、キャッシュメモリは、当該ストレージ装置に接続されている複数のサーバで共用される。そして、それぞれのサーバは、キャッシュメモリの使用量を規制されていない。
【００１６】
　このため、一つのサーバが大量のデータの読み出し要求を行うと、キャッシュメモリが当該サーバによって占有されてしまう。このため、キャッシュメモリを共用する他のサーバのアプリケーションの性能が劣化するという問題があった。
【００１７】
　この問題を解決するために、キャッシュメモリ上の記憶領域をサーバごとに割り当てる技術が知られている（例えば、非特許文献２参照。）。この技術では、それぞれのサーバは、割り当てられた記憶領域を占有する。
【００１８】
　また、キャッシュメモリ上の記憶領域をサーバごとに割り当てた後、割り当てを変更する技術が知られている（例えば、特許文献１参照。）。この技術では、サーバは、アプリケーションの性能要求を満たさなくなると、他のサーバに割り当てられているキャッシュメモリ上の記憶領域を供出してもらう。そして、サーバは、他のサーバから供出してもらった記憶領域を使用することによって、アプリケーションの性能要求を満たす。」（段落【００１５】〜【００１８】）
　　　
（イ）「【０１５９】
　具体的には、制御マネージャ３００１は、アクセスを監視することによって、キャッシュアドレス及びキャッシュヒット回数を収集する。次に、収集したキャッシュアドレスとキャッシュ割当管理テーブル８４００のキャッシュアドレス８４０２とが一致するレコードを、キャッシュ割当管理テーブル８４００から選択する。次に、選択したレコードから、キャッシュ割当ホストＩＤ８４０１を取得する。そして、取得したホストＩＤ８４０１を、キャッシュアクセス状況のホストＩＤとする。
【０１６０】
　次に、収集したキャッシュアドレスとキャッシュデータ管理テーブル８５００のキャッシュアドレス８５０１とが一致するレコードを、キャッシュデータ管理テーブル８５００から選択する。選択したレコードから、論理ユニット番号８５０２及びオフセットアドレス８５０３を取得する。そして、取得した論理ユニット番号８５０２及びオフセットアドレス８５０３を、キャッシュアクセス状況の論理ユニット番号及びオフセットアドレスとする。このようにキャッシュアクセス状況を収集する。
【０１６１】
　次に、制御マネージャ３００１は、収集したキャッシュアクセス状況を、管理サーバ１０３０へ通知する（１３２）。そして、キャッシュアクセス状況通知処理を終了する。
【０１６２】
　図１１は、本発明の実施の形態の管理サーバ１０３０のストレージキャッシュ管理テーブル７３００の更新処理のフローチャートである。
　【０１６３】
　まず、管理マネージャ１０５０は、ストレージ装置３０００からキャッシュアクセス状況の通知を受ける（１３５）。
【０１６４】
　そして、通知を受けたキャッシュアクセス状況に基づいて、ストレージキャッシュ管理テーブル７３００を更新する（１３６）。
　・・・中略・・・
【０１６８】
　　次に、キャッシュアクセス状況に含まれるキャッシュヒット回数を、ストレージキャッシュ管理テーブル７３００のヒット回数７３０５に格納する。次に、キャッシュアクセス状況に含まれる論理ユニット番号を、ストレージキャッシュ管理テーブル７３００の論理ユニット番号７３０６に格納する。次に、キャッシュアクセス状況に含まれるオフセットアドレスを、ストレージキャッシュ管理テーブル７３００のオフセットアドレス７３０７に格納する。
【０１６９】
　以上のように、ストレージキャッシュ管理テーブル７３００を更新する。そして、処理を終了する。」（段落【０１５９】〜【０１６９】）
　　
（ウ）「【０１７１】
　管理サーバ１０３０の管理マネージャ１０５０は、ＤＢＭＳ２００８の性能に関する情報をＤＢＭＳサーバ２０００から定期的に取得する（１４０）。
【０１７２】
　次に、取得したＤＢＭＳ２００８の性能に関する情報に基づいて、ＤＢＭＳ性能情報テーブル７７００を更新する。そして、更新したＤＢＭＳ性能情報テーブル７７００を参照することによって、ＤＢＭＳ２００８に性能問題が発生しているか否かを判断する（１４１）。例えば、管理マネージャ１０５０は、問題の発生回数が閾値を超えると、ＤＢＭＳ２００８に性能問題が発生していると判定する。
【０１７３】
　性能問題は、ＤＢＭＳ２００８に割り当てられているキャッシュメモリ３００３の不足により発生することがある。具体的には、ＤＢＭＳ２００８がアクセスするデータがストレージ装置３０００のキャッシュメモリ３００３に載りきらない場合には、ＬＲＵアルゴリズム等に基づき、キャッシュメモリ３００３上のデータを削除して新たにキャッシュメモリ３００３の空き領域を作成しデータを記憶する。この時、ＤＢＭＳ２００８がアクセスするデータがストレージ装置３０００のキャッシュメモリ３００３に記憶されていないならば、物理ディスク３００６に記憶されているデータへアクセスするためアクセス時間がかかることになり、ＤＢＭＳ２００８が実行する処理が遅延することがある。
【０１７４】
　ＤＢＭＳ２００８に性能問題が発生していないと、キャッシュメモリ３００３の割り当てを変更する必要がないので、ステップ１４０に戻る。
【０１７５】
　一方、ＤＢＭＳ２００８に性能問題が発生していると、キャッシュメモリ３００３の割り当てを変更する必要があると判定する。そこで、ＤＢＭＳ２００８の性能問題を解決するために必要なキャッシュメモリ３００３の容量を算出する（１４２）。
【０１７６】
　例えば、特許文献１に記載された方法で、ＤＢＭＳ２００８の性能問題を解決するために必要なキャッシュメモリ３００３の容量を算出する。具体的には、ＤＢＭＳ２００８の過去の性能情報に基づいて、性能問題を解決するためにＤＢＭＳ２００８がアクセスするデータを判断する。次に、判断したデータへのアクセスに必要なキャッシュメモリ３００３の容量を算出する。そして、算出した容量を、性能問題を解決するために必要なキャッシュメモリ３００３の容量とする。
【０１７７】
　次に、管理マネージャ１０５０は、ストレージキャッシュ管理テーブル７３００を参照して、キャッシュメモリ３００３の割り当てを決定する（１４３）。このとき、算出したキャッシュメモリ３００３の容量を問題が発生したＤＢＭＳ２００８に割り当てるように、キャッシュメモリ３００３の割り当てを決定する。」（段落【０１７１】〜【０１７７】）
　　　
（エ）「【０１８６】
　また、管理マネージャ１０５０は、キャッシュ領域のアクセス回数に基づいて、キャッシュメモリ３００３の割り当てを決定してもよい。
【０１８７】
　具体的には、性能問題を解決するために必要な容量を、ＤＢＭＳ２００８に割り当てるまで以下の処理を繰り返す。
【０１８８】
　まず、ストレージキャッシュ管理テーブル７３００のヒット回数７３０５の小さいレコードをストレージキャッシュ管理テーブル７３００から順に選択する。次に、選択したレコードから、ストレージＩＤ７３０１及びキャッシュアドレス７３０２を抽出する。
【０１８９】
　そして、抽出したストレージＩＤ７３０１及びキャッシュアドレス７３０２に対応するキャッシュ領域を、性能問題が発生したＤＢＭＳ２００８に割り当てる。
【０１９０】
　例えば、性能問題を解決するために必要なキャッシュメモリ３００３の容量が「１００ＭＢ」であるで説明する。この場合、管理マネージャ１０５０は、ストレージキャッシュ管理テーブル７３００のヒット回数７３０５が「１回」のキャッシュ領域を割り当てる。次に、ストレージキャッシュ管理テーブル７３００のヒット回数７３０５が「１回」のキャッシュ領域のすべてを合わせた容量が「１００ＭＢ」以下であるかを判定する。容量が「１００ＭＢ」以下であると、ストレージキャッシュ管理テーブル７３００のヒット回数７３０５が「２回」のキャッシュ領域を割り当てる。このように、割り当てるキャッシュ領域のヒット回数７３０５を徐々に増やす。これによって、管理マネージャ１０５０は、アクセス頻度の低いデータが記憶されているキャッシュ領域を、性能問題が発生したＤＢＭＳ２００８に割り当てることができる。
【０１９１】
　ここでは、アクセス頻度の低いデータが記憶されているキャッシュ領域から順に、ＤＢＭＳ２００８に割り当てている。しかし、アクセス頻度が閾値以上であるデータが記憶されているキャッシュ領域をＤＢＭＳ２００８に割り当てないように、キャッシュメモリ３００３の割り当てを決定してもよい。
【０１９２】
　以上のように、キャッシュメモリ３００３の割り当てを決定すると、決定した割り当てへの変更をストレージ装置３０００へ指示する（１４４）。そして、ステップ１４０へ戻り、本処理を繰り返す。」（段落【０１８６】〜【０１９２】）
　　
第３　対　比
　本願発明と引用発明とを対比する。
（ア）引用発明の「キャッシュメモリ１３０」は、本願発明の「キャッシュメモリ」に相当する。
　　
（イ）引用発明の「キャッシュメモリ１〜３」は、「キャッシュメモリ１３０の記憶領域が論理的に分割された分割単位」であるから、本願発明の「キャッシュセグメント」に相当する。
　　
（ウ）引用発明の「ストレージサブシステム６００」は、「ストレージサブシステムのリソースを複数のパーティションに論理分割し、各パーティションを独立したストレージサブシステムとしてユーザに提供するＳＬＰＲ（Storage Logical Partition）機能を実装」しており、引用発明の「パーティション」及び「ＳＬＰＲ」は、本願発明の「分割されたパーティション」に相当するといえ、ＳＬＰＲのリソース管理は、各ＳＬＰＲへキャッシュメモリ１〜３の割り当てをするから、引用発明の「ストレージサブシステム６００」は、本願発明の「キャッシュメモリを論理的に分割してキャッシュセグメントを構成し、分割されたパーティションとともに提供するストレージ装置」に相当するといえる。
　　
（エ）引用発明の「管理端末１６０」は、「ディスク制御装置１００に内蔵してもよく」、「ＳＬＰＲ構成変更処理を実行し、」「キャッシュ割り当て状態テーブル９０８を参照して、ＳＬＰＲに未割り当てなキャッシュ番号を表示し、選択されたキャッシュ番号を、選択されたＳＬＰＲに追加する処理を行う」から、本願発明の「前記各キャッシュセグメントに対するアクセス負荷を監視し、該アクセス負荷に応じて、未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部」とは、「未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部」である点で共通するといえる。
　
　したがって、本願発明の用語を用いて表現すると両者は、
「キャッシュメモリを論理的に分割してキャッシュセグメントを構成し、分割されたパーティションとともに提供するストレージ装置であって、
　未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部を備えたこと、
　を特徴とするストレージ装置。」
で一致するものであり、次の（１）、（２）の点で相違している。
　　
（１）本願発明は、「前記各キャッシュセグメントに対するアクセス負荷を監視し、該アクセス負荷に応じて、未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部」を備えたのに対して、引用発明は、サブシステム管理者が、管理端末１６０が提供するユーザインターフェースを通じて、管理端末１６０に対して、ＳＬＰＲの構成変更要求を行い、管理端末１６０が、ＳＬＰＲに未割り当てなキャッシュ番号を表示し、選択されたキャッシュ番号を、選択されたＳＬＰＲに追加する処理を実行する点。
　　
（２）本願発明は、「キャッシュメモリの増設を検知し、前記キャッシュセグメント割り当て制御部に通知するキャッシュメモリ増設監視部」を備えたのに対して、引用発明は、そのような構成を備えていない点。
　　
第４　当審の判断
・相違点（１）について
　各キャッシュセグメントに対するアクセス負荷を監視し、該アクセス負荷に応じて、キャッシュセグメントに対する割り当て容量を動的に調整することは、本願出願前に周知の技術（上記引用文献２（特開２００７−２６０６４号公報）段落【０１８６】「管理マネージャ１０５０は、キャッシュ領域のアクセス回数に基づいて、キャッシュメモリ３００３の割り当てを決定してもよい。」の記載、特開２００４−１３９３４９号公報段落【０１００】「本実施の形態においては、キャッシュセグメントの分割割合は、上限値（使用量上限の値）と下限値（使用量下限の値）との間で可変であり、また設定された優先度によって制御される。本実施の形態によれば、キャッシュメモリ５２を単に固定の割合で分割制御するだけでなく、アクセスの状況等に応じてある程度動的に分割割合を変更することで、キャッシュメモリ５２をより有効に使用することが可能となる。」、段落【０１０１】「ここで、「アクセスの状況等に応じてある程度動的に分割割合を変更する」という場合の動的な変更は、自動的に行われ、具体的には、ホストからのアクセスパターンに基づいて制御される。例えば、アクセスが集中しているときには多めに使用され、アクセスが少ないときは少なめに使用される。そして、このような制御を行うために、アクセス頻度を管理するテーブルが必要になる。そのテーブルが、図１１に示すようなセグメント内部管理テーブル６３である。」の記載、特開２００６−２２７６８８号公報段落【００４８】「また、各パーティションのセグメントサイズは、アプリケーションプログラムのＩ／Ｏ特性の変化に応じて、自動的に、或いはオペレータの入力操作によって、電源を落とさずに、動的に設定変更可能である。例えば、パーティションＰ０１♯０のセグメントサイズは、デフォルトの１６ＫＢに設定されているが、Ｉ／Ｏ特性の変化に応じて、これを動的に拡大（例えば、６４ＫＢに設定変更）し、或いは縮小（例えば、４ＫＢに設定変更）することもできる。また、各パーティションのパーティションサイズを自動的に、或いはオペレータの入力操作によって、電源を落とさずに、動的に設定変更することもできる。大量のデータを扱うアプリケーションプログラムが使用するパーティションに対しては、パーティションサイズを大きく設定し、少量のデータを扱うアプリケーションプログラムが使用するパーティションに対しては、パーティションサイズを小さく設定することもできる。」、段落【００４９】「セグメントサイズ、又はパーティションサイズをストレージシステム１０が自動的に設定変更する例として、例えば、キャッシュメモリ２５，３５のリソース競合状態をＣＰＵ２１，３１が監視し、各アプリケーションに最適となるように、セグメントサイズ、又はパーティションサイズを変更するように構成してもよい。」の記載参照。）である。
　そして、引用文献１には、「また、一定の性能を保証したいＬＤＥＶ４，７，８に入出力されるデータを一時的に記憶するキャッシュメモリ２に多くの記憶領域を割り当てることで、ストレージサブシステム６００の性能を保証することができる。」（段落【００９７】）と記載されており、また、各パーティションのセグメントサイズの変更を自動的に行うか、オペレータの入力操作によって行うかは単なる選択的事項（例えば、上記特開２００６−２２７６８８号公報段落【００４８】の記載参照。）にすぎない。
　したがって、引用発明において、上記周知技術を適用し、各キャッシュセグメントに対するアクセス負荷を監視し、該アクセス負荷に応じて、未割り当てのキャッシュメモリ容量と、当該キャッシュセグメントに対する割り当て容量と、を調整するキャッシュセグメント割り当て制御部を備えるようにすることは、当業者が容易になし得ることである。
　　　
・相違点（２）について
　データストレージ装置において、キャッシュメモリを増設し記憶容量を大きくしてデータ処理性能を向上させることは、本願出願前周知の技術（原査定において引用された特開２００１−３４４１５４号公報段落【００１７】「キャッシュメモリ数を増設する場合構成情報管理部１２ｂにはキャッシュ増設前の構成情報に加え、キャッシュ創設後の構成情報が設定され、キャッシュメモリが増設されると、図８に示すように構成情報管理部１２ｂはキャッシュメモリ数の増設を、全インタフェース制御部１２ａとキャッシュ制御部１２ｃ通知する。」の記載、特開２０００−１６３２２１号公報段落【０００２】「ディスクサブシステムにおいて、キャッシュ・ミスによるデータ処理性能はディスクドライブ性能に大きく依存する。データ処理性能向上には、キャッシュ・ヒット率向上のためにキャッシュメモリを増設するか、高速ディスクドライブを用いたサブシステム構成に変更することが有効である。」の記載、特開平４−９７４５８号公報第２頁左上欄「ところで、キャッシュメモリには、半導体記憶素子を使用することが一般的であり、半導体記憶素子を増設することによって記憶容量を大きくすることが可能である。しかし、増設による効果の度合いは、外部記憶装置へのアクセス状況に左右されるために容易には推測できないので、まず、実際に搭載されたキャッシュメモリの現行容量でのヒット率を測定し、次に、実際に試験的に増設工事を行ってヒット率を測定して両者を比較している。」の記載、特開平１−１５４２６３号公報第４頁左上欄「また、コストの関係で当初キャッシュメモリ３−１を１つだけで使用し、次に、高速性を向上させるために更に他のキャッシュメモリ３−２を増設する場合でも、ソフトが単に第１図物理ボリュームＵＣＢ（Ｘ面）５−１あるいは物理ボリュームＵＣＢ（Ｙ面）５−２のいずれかのキャッシュメモリ有情報を格納するのみで極めて容易に増設することが可能となる。」の記載参照。）である。
　キャッシュの記憶容量を大きくしてデータ処理性能を向上させることは、データ処理装置において、一般的な課題であるから、引用発明においても上記周知技術を採用して、キャッシュメモリの増設を可能にすることは当業者が容易に想到し得ることである。
　そして、引用発明の管理端末１６０は、ストレージサブシステム６００を管理するためのコンピュータであり、ＳＬＰＲのリソース管理（各ＳＬＰＲへのリソース（ポート、ＬＤＥＶ、キャッシュメモリ等）の割り当て、追加、削除等の設定）、物理ディスクドライブ３３０の構成の設定（例えば、物理ディスクドライブ３３０の増設或いは減設、ＲＡＩＤ構成の変更（例えば、ＲＡＩＤ１からＲＡＩＤ５への変更））等を行い、更に、ストレージサブシステム６００の動作状態の確認や故障部位の特定を行うこともできる（引用文献１段落【００４０】の記載参照。）ものであるから、キャッシュメモリの増設を可能とする際、キャッシュメモリの増設を検知し、管理端末１６０に通知するキャッシュメモリ増設監視部を備えるようにすることは当業者が適宜なし得る設計事項にすぎない。
　　　　　
　また、本願発明の作用効果も、引用発明及び周知技術から、当業者であれば予想できる範囲内のものである。　　　
　　　
第５　むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。