【事件の表示】
　特願２０１４−５５３２９３「ネットワークおよびストレージアウェア仮想マシン配置のための方法および装置」拒絶査定不服審判事件〔平成２５年　７月２５日国際公開、ＷＯ２０１３／１０９３４４、平成２７年　２月　５日国内公表、特表２０１５−５０４２２４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は，２０１２年（平成２４年）１１月２８日（パリ条約による優先権主張外国庁受理２０１２年１月１７日（以下，「優先日」という。），米国）を国際出願日とする出願であって，平成２７年１１月１３日付けの拒絶理由通知に対して平成２８年１月２９日付けで意見書が提出されると共に手続補正がなされ，平成２８年６月２９日付けの拒絶理由通知に対して平成２８年１２月１４日付けで意見書が提出されると共に手続補正がなされたが，平成２９年２月２３日付けで拒絶査定がなされ，これに対して平成２９年６月２２日に拒絶査定不服審判の請求がなされたものである。 
  
２．本願発明 
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２８年１２月１４日付けの手続補正により補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。 
 　 
「　【請求項１】
　複数の利用可能なリソースを含むクラウドネットワーク内で仮想マシンの配置を提供するための装置であって，
　データストレージと，
　データストレージに通信可能に結合されたプロセッサとを備え，プロセッサは，
　　クラウドネットワーク内の１つまたは複数のストレージアレイの性能特性を示す第１のセットのストレージ性能データをデータストレージに収集し，
　　複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データをデータストレージに収集し，
　　第１のセットのストレージ性能データおよび第２のセットのネットワーク性能データに基づいてクラウドネットワーク内の仮想マシンの配置場所を決定するように構成され，
　仮想マシンは，１つまたは複数のストレージアレイの少なくとも１つと複数の利用可能なリソースの少なくとも１つを含み，
　複数の通信経路は，第１のストレージアレイと第１の利用可能なリソースの間の第１の経路と，第２のストレージアレイと第２の利用可能なリソースの間の第２の経路を含み，
　第１の利用可能なリソースと第２の利用可能なリソースは異なっており，
　１つまたは複数のストレージアレイは，第１のストレージアレイと第２のストレージアレイを含み，複数の利用可能なリソースは，第１の利用可能なリソースと第２の利用可能なリソースを含む，装置。」
３．引用例 
（１）引用例１ 
　原査定の拒絶理由で引用された，本願の優先日前に頒布された刊行物である，特開２００９−１５１７４５号公報（平成２１年７月９日出願公開。以下，「引用例１」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
  
Ａ　「【００１２】
　本発明は，１つ以上のプロセッサと，１つ以上のメモリと１つ以上のＩ／Ｏデバイスとを内部ネットワークで接続し，
前記プロセッサとメモリ及びＩ／Ｏデバイスを仮想サーバに割り当てる仮想マシンモニタ
前記仮想マシンモニタは，
前記受け付けた生成要求に基づいてＩ／Ｏデバイスを前記仮想サーバに割り当ててから，前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と，を備える
Ｂ　「【００１７】
　図１は第１の実施形態を示し，本発明を適用するマルチプロセッサシステム（計算機），およびその上で動作する仮想マシンモニタとゲストＯＳとの関係を示したブロック図である。
【００１８】
　
マルチプロセッサシステム１００は，１つ以上のＣＰＵソケット（プロセッサパッケージ）１１０，メモリコントローラ１３０，Ｉ／Ｏハブ１６０ａ，１６０ｂをモジュール間接続Ｉ／Ｆ（インターフェース）２００にて接続した構成を採る。
ＣＰＵソケット１１０は１つ以上のＣＰＵコア（プロセッサコア）１２０を含む。メモリコントローラ１３０はメモリＩ／Ｆ１４０を介して１つ以上のＤＩＭＭ（Dual Inline Memory  Module）１５０と接続する。Ｉ／Ｏハブ１６０はＩ／Ｏ接続Ｉ／Ｆ１７０を介して１つ以上のＩ／Ｏアダプタ１８０ａ〜１８０ｆを搭載し，Ｉ／Ｏアダプタ１８０ａ〜１８０ｆの先にはＩ／Ｏデバイス１９０ｄが接続される。
Ｃ　「【００２７】
　
図６４は，図１の構成に対応するマルチプロセッサシステム100上で，仮想マシンモニタ300，ゲストOS1 360a，ゲストOS2 360b，ゲストOS3 360cが実行されている様子を示した構成図である。仮想マシンモニタ300のプログラムは，いずれかのI/Oデバイス190上，あるいはサービスプロセッサ200のROM201上に存在し，マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され，仮想マシンCPUコア120のいずれかの上で実行される。
　ゲストOS 360は，仮想マシンモニタ300によって分割された論理サーバ370に割り当てられたI/Oデバイス190のいずれかの上にプログラムが存在し，論理サーバ370の起動時に370に割り当てられたメモリ150の上に展開され， 370に割り当てられたCPUコア300によって実行される。図６４の例では，ゲストOS1 360aはメモリ150#5上に，ゲストOS2 360bはメモリ150#10上に，ゲストOS3 360cはメモリ150#13へと展開され，実行されている。なお，本例ではわかりやすいように一つのメモリモジュール上にゲストOS 360を配置した例を示したが，ゲストOSのサイズやメモリインタリーブの設定によっては複数のメモリモジュール上に分散配置されることもあり得る。
【００２８】
　
図２〜図６で仮想マシンモニタ３００がサービスプロセッサ２２０経由で得たマルチプロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０について示す。図２は物理ハードウェア構成情報取得Ｉ／Ｆ３２０の内訳を示す。物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，物理コンポーネント構成表４００，Ｉ／Ｏアダプタ構成表４５０，コンポーネント間距離対応表５００，物理ネットワーク構成表５５０の４種類の表（テーブル）で構成される。これらのテーブルは，仮想マシンモニタ３００が所定の周期または所定のタイミングで，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆ２１０を介して収集したハードウェアリソースの情報を問い合わせて生成（または更新）するものである。仮想マシンモニタ３００が設定した物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，図１に示すＩ／Ｏハブ１６０の物理位置情報格納メモリ１６５またはメモリ１５０に格納される。
（途中省略）
【００３０】
　本実施形態の説明においては，コンポーネント＃４２０はＣＰＵソケット１１０やＩ／Ｏハブ１６０のように物理的に挿抜あるいは電源のｏｎ／ｏｆｆの対象となるオブジェクトを指しており，複数のリソースが１つのコンポーネント＃４２０上に接続され得る。本実施形態の例では，
ＣＰＵコア１２０やＤＩＭＭ１５０はＣＰＵソケット１１０というコンポーネントに接続され
（途中省略）
【００３３】
　
図５はコンポーネント間距離対応表５００の構成を示す。コンポーネント間距離対応表５００は，マルチプロセッサシステム１００上の全てのコンポーネントに対応するエントリが存在し，
このコンポーネントと他のコンポーネントの距離を示す対コンポーネント間距離５１０から構成される。対コンポーネント間距離５１０はまた全てのコンポーネント分だけ分けられており，コンポーネント＃４２０のコンポーネントから対コンポーネント間距離５１０のコンポーネントに到達するまでの距離を示している。
本実施形態ではモジュール間接続Ｉ／Ｆ２００の性能は全て等価であると仮定したため，何回モジュール間接続Ｉ／Ｆ２００を渡れば目的のコンポーネントまで辿り着くかという回数を距離としている。この距離を，コンポーネントの物理的な位置情報として扱う。
【００３４】
　
なお，モジュール間接続Ｉ／Ｆが不均一な場合は，後述の物理ネットワーク構成表５５０にあるレイテンシ５７０の合計値を使って距離を示す，といった方法が考えられる。
（途中省略）
【００３７】
　
図６は物理ネットワーク構成表５５０の構成を示している。物理ネットワーク構成表５５０は，マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００に対して，モジュール間接続Ｉ／Ｆ２００の接続の通し番号を示すネットワーク＃５５５と，どのコンポーネント４２０ａからどのコンポーネント４２０ｂをつないでいるのか，そしてコンポーネント４２０ａと４２０ｂ間の帯域５６０とレイテンシ５７０を示す項目からなる。本実施形態では，ＣＰＵソケット１１０間をつなぐネットワークの帯域５６０は６なのに対して，ＣＰＵソケット１１０とＩ／Ｏハブ１６０の間をつなぐネットワーク帯域５６０は半分の３であるとした。なお，帯域５６０の単位は，例えば[Ｇｂｐｓ]であり，レイテンシ５７０の単位は，例えば，[nsec]である。
Ｄ　「【００４６】
　
図９は，上記論理ハードウェア要求Ｉ／Ｆ３５０ａと物理−論理ハードウェア（ＨＷ）割当表３１０に基づいて，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１がマルチプロセッサシステム１００上に割り当てた仮想サーバ１＿３７０ａを示す。図中点線で囲まれた部分は図１のリソースのうち仮想サーバ１＿３７０ａに割り当てられたリソースを示す。
Ｅ　「【００４７】
　＜第１実施形態における動作＞
　以下，図１０〜１７で，本第１実施形態の動作について説明する。
【００４８】
　
図１０と図１１は，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１によって上記図９で示したように仮想サーバ１＿３７０ａが割り当てられた後で，次の仮想サーバ２に対する論理ハードウェア要求Ｉ／Ｆ３５０ｂおよび３５０ｃを示している。論理ハードウェア要求Ｉ／Ｆ３５０ｂと３５０ｃは，どちらも同じＩ／Ｏアダプタ３５３，ＣＰＵコア数３５４，メモリ量３５５を要求している。違いはリソース割当ポリシー３５６のみで，論理ハードウェア要求Ｉ／Ｆ３５０ｂにおいては「ＣＰＵ−メモリ優先」となっているのに対して，論理ハードウェア要求Ｉ／Ｆ３５０ｃにおいては「Ｉ／Ｏ−メモリ優先」となっている。
【００４９】
　
図１２と図１３は，仮想サーバ２に対する上記図１０，図１１の論理ハードウェア要求Ｉ／Ｆ３５０に対して，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１が割り当てを行った結果の２通りの物理−論理ハードウェア割当表３１０を示している。
【００５０】
　
図１０の論理ハードウェア要求Ｉ／Ｆ３５０ｂでは，ＣＰＵ−メモリ優先のポリシーを要求しているため，ＣＰＵソケット１１０ｃのＣＰＵコア＃４，＃５と，ＣＰＵソケット１１０ｃに接続されるメモリ＃８〜１１を仮想サーバ２へ割り当てて，リソースの距離を０とすることでＣＰＵとメモリの距離が短いものを選択している。一方，図１１の論理ハードウェア要求Ｉ／Ｆ３５０ｃでは，Ｉ／Ｏ−メモリ優先のポリシーを要求しているため，Ｉ／Ｏデバイスとメモリの距離が最も短くなるように，Ｉ／Ｏアダプタ＃２に最も近いメモリ＃０〜＃３を選択している。このように，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１は，要求されたポリシーに応じて，仮想サーバに割り当てるハードウェアリソースを最適化することができる。
【００５１】
　
図１４は，図１２に示した割当表３１０ｂに対応して，仮想マシンモニタ３００が各リソース間の距離を計算したリソース間距離計算表６００ｂを示している。リソース間距離計算表６００ｂは，仮想サーバの識別子（または連番）を示す仮想サーバの番号＃３５１と，各仮想サーバ番号＃３５１ごとに，仮想サーバ内のリソース間の距離を計算するための表である。カテゴリ６０１には，リソース割当ポリシーに対応したＣＰＵ−メモリ，Ｉ／Ｏ−メモリ，ＣＰＵ−Ｉ／Ｏの３種類のカテゴリが存在する。それぞれのカテゴリ６０１ごとにリソースｆｒｏｍ６０２からリソースｔｏ６０３までのコンポーネント間距離６０４を，所属するコンポーネント＃と，コンポーネント間距離対応表５００に従って仮想マシンモニタ３００が計算する。
最後にカテゴリ６０１ごとにコンポーネント間距離の総和６０５を計算する。
【００５２】
（途中省略）
【００５３】
　
以上のようにしてリソース間距離計算表６００を計算したリソース割当候補の中から，リソース割当ポリシーを最も満たす候補を選択する。３５０ｂにおける「ＣＰＵ−メモリ優先」の場合は，コンポーネント間距離の総和６０５のＣＰＵ−メモリの値が小さくなるリソース割当を選ぶ。それに対して「Ｉ／Ｏ−メモリ優先」の場合は，コンポーネント間距離の総和６０５のＩ／Ｏ−メモリの値が小さくなるリソース割当を選ぶ。
Ｆ　「【図１】
」
Ｇ　「【図５】
」
Ｈ　「【図８】
」
Ｉ　「【図９】
」
Ｊ　「【図６４】
」
　ここで，上記引用例１に記載されている事項について検討する。 
  
ア　上記Ｂの段落【００１８】の「マルチプロセッサシステム１００は，１つ以上のＣＰＵソケット（プロセッサパッケージ）１１０，メモリコントローラ１３０，Ｉ／Ｏハブ１６０ａ，１６０ｂをモジュール間接続Ｉ／Ｆ（インターフェース）２００にて接続した構成を採る。」との記載，及び「ＣＰＵソケット１１０は１つ以上のＣＰＵコア（プロセッサコア）１２０を含む。メモリコントローラ１３０はメモリＩ／Ｆ１４０を介して１つ以上のＤＩＭＭ（Dual Inline Memory  Module）１５０と接続する。Ｉ／Ｏハブ１６０はＩ／Ｏ接続Ｉ／Ｆ１７０を介して１つ以上のＩ／Ｏアダプタ１８０ａ〜１８０ｆを搭載し，Ｉ／Ｏアダプタ１８０ａ〜１８０ｆの先にはＩ／Ｏデバイス１９０ｄが接続される。」との記載，及び上記Ｆで引用した図１の記載から，
　“マルチプロセッサシステム１００”は，“複数のＣＰＵコア１２０”と“複数のメモリ１５０”と“複数のＩ／Ｏデバイス１９０”を含むことが読み取れるから，
　引用例１には， 
　“複数のＣＰＵコア１２０と複数のメモリ１５０と複数のＩ／Ｏデバイス１９０とを含むマルチプロセッサシステム１００”
が記載されていると認められる。 
イ　上記Ａの段落【００１２】の「前記プロセッサとメモリ及びＩ／Ｏデバイスを仮想サーバに割り当てる仮想マシンモニタ」との記載，及び「前記仮想マシンモニタは，・・・前記受け付けた生成要求に基づいてＩ／Ｏデバイスを前記仮想サーバに割り当ててから，前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と，を備える」との記載から，
　“仮想マシンモニタ”は，“仮想サーバ”に，“Ｉ／Ｏデバイス”，“プロセッサ”，及び“メモリ”を“割り当てる”機能を有するものであることが読み取れ，
　また，上記Ｄの段落【００４６】の「図９は，上記論理ハードウェア要求Ｉ／Ｆ３５０ａと物理−論理ハードウェア（ＨＷ）割当表３１０に基づいて，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１がマルチプロセッサシステム１００上に割り当てた仮想サーバ１＿３７０ａを示す。図中点線で囲まれた部分は図１のリソースのうち仮想サーバ１＿３７０ａに割り当てられたリソースを示す。」との記載から，
　“仮想サーバ”は，“マルチプロセッサシステム１００上のリソースを割り当てられる”ものであることが読み取れるから，
　引用例１には，
　“仮想サーバに，Ｉ／Ｏデバイス，プロセッサ，及びメモリ等のマルチプロセッサシステム１００上のリソースを割り当てる仮想マシンモニタ３００”
が記載されていると認められる。 
ウ　上記Ｃの段落【００２７】の「図６４は，図１の構成に対応するマルチプロセッサシステム100上で，仮想マシンモニタ300，ゲストOS1 360a，ゲストOS2 360b，ゲストOS3 360cが実行されている様子を示した構成図である。仮想マシンモニタ300のプログラムは，いずれかのI/Oデバイス190上，あるいはサービスプロセッサ200のROM201上に存在し，マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され，仮想マシンCPUコア120のいずれかの上で実行される。」との記載，及び上記Ｊで引用した図６４の記載から，
　“仮想マシンモニタ３００のプログラム”は，“メモリ１５０”上へと展開され，“仮想マシンＣＰＵコア１２０”で実行されることが読み取れ，当該“メモリ１５０”と“仮想マシンＣＰＵコア１２０”は，仮想マシンモニタ３００のプログラムを実行するための“装置”であるとみることができるから，
　引用例１には，
　“仮想マシンモニタ３００のプログラムを実行するための装置であって，仮想マシンモニタ３００のプログラムが展開されるメモリ１５０と，仮想マシンモニタ３００のプログラムを実行する仮想マシンＣＰＵコア１２０とを備えた装置”
が記載されていると認められる。 
エ　上記ア〜ウの検討から，引用例１には，
“複数のＣＰＵコア１２０と複数のメモリ１５０と複数のＩ／Ｏデバイス１９０とを含むマルチプロセッサシステム１００内で，仮想サーバに，Ｉ／Ｏデバイス，プロセッサ，及びメモリ等のマルチプロセッサシステム１００上のリソースを割り当てる仮想マシンモニタ３００のプログラムを実行するための装置であって，
　仮想マシンモニタ３００のプログラムが展開されるメモリ１５０と，
　仮想マシンモニタ３００のプログラムを実行する仮想マシンＣＰＵコア１２０とを備えた装置”
が記載されていると認められる。
オ　上記Ｃの段落【００２８】の「図２〜図６で仮想マシンモニタ３００がサービスプロセッサ２２０経由で得たマルチプロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０について示す。図２は物理ハードウェア構成情報取得Ｉ／Ｆ３２０の内訳を示す。物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，物理コンポーネント構成表４００，Ｉ／Ｏアダプタ構成表４５０，コンポーネント間距離対応表５００，物理ネットワーク構成表５５０の４種類の表（テーブル）で構成される。これらのテーブルは，仮想マシンモニタ３００が所定の周期または所定のタイミングで，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆ２１０を介して収集したハードウェアリソースの情報を問い合わせて生成（または更新）するものである。仮想マシンモニタ３００が設定した物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，図１に示すＩ／Ｏハブ１６０の物理位置情報格納メモリ１６５またはメモリ１５０に格納される。」との記載から，
　“仮想マシンモニタ３００”は，マルチプロセッサシステム１００の“物理ハードウェア構成情報取得Ｉ／Ｆ３２０”を取得することが読み取れ，
　当該“物理ハードウェア構成情報取得Ｉ／Ｆ３２０”は，“物理コンポーネント構成表４００，Ｉ／Ｏアダプタ構成表４５０，コンポーネント間距離対応表５００，物理ネットワーク構成表５５０の４種類のテーブルで構成される”ものであり，これらの“テーブル”は，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆ２１０を介して“収集したハードウェアリソースの情報”を問い合わせて生成するものであり，“物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，メモリ１５０に格納される”ことが読み取れるから，
　引用例１には，
　“仮想マシンモニタ３００は，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆを２１０介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０を取得してメモリ１５０に格納し，ここで，物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，物理コンポーネント構成表４００，Ｉ／Ｏアダプタ構成表４５０，コンポーネント間距離対応表５００，物理ネットワーク構成表５５０の４種類のテーブルで構成されるものであ”ること
が記載されていると認められる。 
カ　上記Ｂの段落【００１８】の「Ｉ／Ｏハブ１６０はＩ／Ｏ接続Ｉ／Ｆ１７０を介して１つ以上のＩ／Ｏアダプタ１８０ａ〜１８０ｆを搭載し，Ｉ／Ｏアダプタ１８０ａ〜１８０ｆの先にはＩ／Ｏデバイス１９０ｄが接続される。」との記載，上記Ｃの段落【００３０】の「ＣＰＵコア１２０やＤＩＭＭ１５０はＣＰＵソケット１１０というコンポーネントに接続され」との記載，上記Ｃの段落【００３３】の「図５はコンポーネント間距離対応表５００の構成を示す。コンポーネント間距離対応表５００は，マルチプロセッサシステム１００上の全てのコンポーネントに対応するエントリが存在し，・・・このコンポーネントと他のコンポーネントの距離を示す対コンポーネント間距離５１０から構成される。対コンポーネント間距離５１０はまた全てのコンポーネント分だけ分けられており，コンポーネント＃４２０のコンポーネントから対コンポーネント間距離５１０のコンポーネントに到達するまでの距離を示している。」，「本実施形態ではモジュール間接続Ｉ／Ｆ２００の性能は全て等価であると仮定したため，何回モジュール間接続Ｉ／Ｆ２００を渡れば目的のコンポーネントまで辿り着くかという回数を距離としている。この距離を，コンポーネントの物理的な位置情報として扱う。」との記載，上記Ｃの段落【００３４】の「なお，モジュール間接続Ｉ／Ｆが不均一な場合は，後述の物理ネットワーク構成表５５０にあるレイテンシ５７０の合計値を使って距離を示す，といった方法が考えられる。」との記載，上記Ｆで引用した図１の記載，及び上記Ｇで引用した図５の記載から，
　“コンポーネント間距離対応表５００”は，“ＣＰＵコア１２０が接続されるＣＰＵソケット１１０と，Ｉ／Ｏデバイス１９０が接続されるＩ／Ｏハブ１６０とを含むマルチプロセッサシステム１００上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり，モジュール間接続Ｉ／Ｆ２００が不均一な場合は，物理ネットワーク構成表５５０にあるレイテンシの合計値を使って距離を示すように”することが読み取れる。
キ　上記Ｃの段落【００３７】の「図６は物理ネットワーク構成表５５０の構成を示している。物理ネットワーク構成表５５０は，マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００に対して，モジュール間接続Ｉ／Ｆ２００の接続の通し番号を示すネットワーク＃５５５と，どのコンポーネント４２０ａからどのコンポーネント４２０ｂをつないでいるのか，そしてコンポーネント４２０ａと４２０ｂ間の帯域５６０とレイテンシ５７０を示す項目からなる。本実施形態では，ＣＰＵソケット１１０間をつなぐネットワークの帯域５６０は６なのに対して，ＣＰＵソケット１１０とＩ／Ｏハブ１６０の間をつなぐネットワーク帯域５６０は半分の３であるとした。なお，帯域５６０の単位は，例えば[Ｇｂｐｓ]であり，レイテンシ５７０の単位は，例えば，[nsec]である。」との記載から，
　“物理ネットワーク構成表５５０”は，“マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００の帯域とレイテンシを示す項目からな”ることが読み取れる。
ク　上記カ及びキの検討から，引用例１には，
“コンポーネント間距離対応表５００は，ＣＰＵコア１２０が接続されるＣＰＵソケット１１０と，Ｉ／Ｏデバイス１９０が接続されるＩ／Ｏハブ１６０とを含むマルチプロセッサシステム１００上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり，モジュール間接続Ｉ／Ｆ２００が不均一な場合は，マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００の帯域とレイテンシを示す項目からなる物理ネットワーク構成表５５０にあるレイテンシの合計値を使って距離を示すように”すること
が記載されていると認められる。 
ケ　上記Ｅの段落【００４８】の「図１０と図１１は，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１によって上記図９で示したように仮想サーバ１＿３７０ａが割り当てられた後で，次の仮想サーバ２に対する論理ハードウェア要求Ｉ／Ｆ３５０ｂおよび３５０ｃを示している。論理ハードウェア要求Ｉ／Ｆ３５０ｂと３５０ｃは，どちらも同じＩ／Ｏアダプタ３５３，ＣＰＵコア数３５４，メモリ量３５５を要求している。違いはリソース割当ポリシー３５６のみで，論理ハードウェア要求Ｉ／Ｆ３５０ｂにおいては「ＣＰＵ−メモリ優先」となっているのに対して，論理ハードウェア要求Ｉ／Ｆ３５０ｃにおいては「Ｉ／Ｏ−メモリ優先」となっている。」との記載から，
　“仮想サーバに対する論理ハードウェア要求Ｉ／Ｆ”によって，リソース割当ポリシーを“ＣＰＵ−メモリ優先”又は“Ｉ／Ｏ−メモリ優先”のように指定した要求が行われる”ことが読み取れる。
コ　上記Ｅの段落【００４９】の「図１２と図１３は，仮想サーバ２に対する上記図１０，図１１の論理ハードウェア要求Ｉ／Ｆ３５０に対して，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１が割り当てを行った結果の２通りの物理−論理ハードウェア割当表３１０を示している。」との記載，及び段落【００５１】の「図１４は，図１２に示した割当表３１０ｂに対応して，仮想マシンモニタ３００が各リソース間の距離を計算したリソース間距離計算表６００ｂを示している。リソース間距離計算表６００ｂは，仮想サーバの識別子（または連番）を示す仮想サーバの番号＃３５１と，各仮想サーバ番号＃３５１ごとに，仮想サーバ内のリソース間の距離を計算するための表である。カテゴリ６０１には，リソース割当ポリシーに対応したＣＰＵ−メモリ，Ｉ／Ｏ−メモリ，ＣＰＵ−Ｉ／Ｏの３種類のカテゴリが存在する。それぞれのカテゴリ６０１ごとにリソースｆｒｏｍ６０２からリソースｔｏ６０３までのコンポーネント間距離６０４を，所属するコンポーネント＃と，コンポーネント間距離対応表５００に従って仮想マシンモニタ３００が計算する。・・・最後にカテゴリ６０１ごとにコンポーネント間距離の総和６０５を計算する。」との記載から，
　“仮想マシンモニタ３００”は，“論理ハードウェア要求Ｉ／Ｆに対して要求を行った結果に対応するよう，リソース割当ポリシーに対応したＣＰＵ−メモリ，Ｉ／Ｏ−メモリ，及びＣＰＵ−Ｉ／Ｏの３種類のカテゴリごとにリソースｆｒｏｍからリソースｔｏまでのコンポーネント間距離を，所属するコンポーネントと，コンポーネント間距離対応表５００に従って計算し，さらに，カテゴリごとにコンポーネント間距離の総和を計算して，リソース間距離計算表６００を計算”することが読み取れる。
サ　上記Ｅの段落【００５０】の「図１０の論理ハードウェア要求Ｉ／Ｆ３５０ｂでは，ＣＰＵ−メモリ優先のポリシーを要求しているため，ＣＰＵソケット１１０ｃのＣＰＵコア＃４，＃５と，ＣＰＵソケット１１０ｃに接続されるメモリ＃８〜１１を仮想サーバ２へ割り当てて，リソースの距離を０とすることでＣＰＵとメモリの距離が短いものを選択している。一方，図１１の論理ハードウェア要求Ｉ／Ｆ３５０ｃでは，Ｉ／Ｏ−メモリ優先のポリシーを要求しているため，Ｉ／Ｏデバイスとメモリの距離が最も短くなるように，Ｉ／Ｏアダプタ＃２に最も近いメモリ＃０〜＃３を選択している。このように，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１は，要求されたポリシーに応じて，仮想サーバに割り当てるハードウェアリソースを最適化することができる。」との記載，上記Ｅの段落【００５３】の「以上のようにしてリソース間距離計算表６００を計算したリソース割当候補の中から，リソース割当ポリシーを最も満たす候補を選択する。３５０ｂにおける「ＣＰＵ−メモリ優先」の場合は，コンポーネント間距離の総和６０５のＣＰＵ−メモリの値が小さくなるリソース割当を選ぶ。それに対して「Ｉ／Ｏ−メモリ優先」の場合は，コンポーネント間距離の総和６０５のＩ／Ｏ−メモリの値が小さくなるリソース割当を選ぶ。」との記載から，
　“リソース間距離計算表６００を計算したリソース割当候補の中から，リソース割当ポリシーを最も満たす候補を選択することで，仮想サーバに割り当てるハードウェアリソースを最適化する”ことが読み取れる。
シ　上記Ｄの段落【００４６】の「図９は，上記論理ハードウェア要求Ｉ／Ｆ３５０ａと物理−論理ハードウェア（ＨＷ）割当表３１０に基づいて，仮想マシンモニタ３００の論理ハードウェア割当処理部８０１がマルチプロセッサシステム１００上に割り当てた仮想サーバ１＿３７０ａを示す。図中点線で囲まれた部分は図１のリソースのうち仮想サーバ１＿３７０ａに割り当てられたリソースを示す。」との記載，上記Ｆで引用した図１の記載，上記Ｈで引用した図８の記載，及び上記Ｉで引用した図９の記載から，
　“仮想サーバ１＿３７０ａは，ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃを含み，
　ＣＰＵコア１２０（＃０，＃１）とＩ／Ｏデバイス１９０ａとは，モジュール間接続Ｉ／Ｆ２００の＃５で接続され，また，ＣＰＵコア１２０（＃２，＃３）とＩ／Ｏデバイス１９０ｃとは，モジュール間接続Ｉ／Ｆ２００の＃６で接続され”ていることが読み取れる。
　上記ア〜シの検討から，引用例１には，次のとおりの発明（以下，「引用発明」という。）が記載されていると認められる。 
  
 「複数のＣＰＵコア１２０と複数のメモリ１５０と複数のＩ／Ｏデバイス１９０とを含むマルチプロセッサシステム１００内で，仮想サーバに，Ｉ／Ｏデバイス，プロセッサ，及びメモリ等のマルチプロセッサシステム１００上のリソースを割り当てる仮想マシンモニタ３００のプログラムを実行するための装置であって，
　仮想マシンモニタ３００のプログラムが展開されるメモリ１５０と，
　仮想マシンモニタ３００のプログラムを実行する仮想マシンＣＰＵコア１２０とを備え，
　仮想マシンモニタ３００は，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆを２１０介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０を取得してメモリ１５０に格納し，
　ここで，物理ハードウェア構成情報取得Ｉ／Ｆ３２０は，物理コンポーネント構成表４００，Ｉ／Ｏアダプタ構成表４５０，コンポーネント間距離対応表５００，物理ネットワーク構成表５５０の４種類のテーブルで構成されるものであり，
　コンポーネント間距離対応表５００は，ＣＰＵコア１２０が接続されるＣＰＵソケット１１０と，Ｉ／Ｏデバイス１９０が接続されるＩ／Ｏハブ１６０とを含むマルチプロセッサシステム１００上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり，モジュール間接続Ｉ／Ｆ２００が不均一な場合は，マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００の帯域とレイテンシを示す項目からなる物理ネットワーク構成表５５０にあるレイテンシの合計値を使って距離を示すようにし，
　仮想サーバに対する論理ハードウェア要求Ｉ／Ｆによって，リソース割当ポリシーをＣＰＵ−メモリ優先又はＩ／Ｏ−メモリ優先のように指定した要求が行われると，
　仮想マシンモニタ３００は，リソース割当ポリシーに対応したＣＰＵ−メモリ，Ｉ／Ｏ−メモリ，及びＣＰＵ−Ｉ／Ｏの３種類のカテゴリごとにリソースｆｒｏｍからリソースｔｏまでのコンポーネント間距離を，所属するコンポーネントと，コンポーネント間距離対応表５００に従って計算し，さらに，カテゴリごとにコンポーネント間距離の総和を計算して，リソース間距離計算表６００を計算し，
　リソース間距離計算表６００を計算したリソース割当候補の中から，リソース割当ポリシーを最も満たす候補を選択することで，仮想サーバに割り当てるハードウェアリソースを最適化するようにし，
　仮想サーバ１＿３７０ａは，ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃを含み，
　ＣＰＵコア１２０（＃０，＃１）とＩ／Ｏデバイス１９０ａとは，モジュール間接続Ｉ／Ｆ２００の＃５で接続され，また，ＣＰＵコア１２０（＃２，＃３）とＩ／Ｏデバイス１９０ｃとは，モジュール間接続Ｉ／Ｆ２００の＃６で接続される
装置。」 
  
（２）引用例２ 
　原査定の拒絶理由で引用された，本願の優先日前に頒布された刊行物である，特開２００９−１３４６８７号公報（平成２１年６月１８日出願公開。以下，「引用例２」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｋ　「【００１３】
[0034]　図２は，各データセンタ１０に収容されることが可能なハードウェアアーキテクチャおよびソフトウェアモジュールの詳細を示す。図２に示されるように，管理ＬＡＮ　２０２が，統合管理システム１１１と，ネットワーク管理サーバ１３１と，サーバ管理サーバ１３２と，ストレージ管理サーバ１３３と，ＶＰＮ（仮想プライベートネットワーク）ルータ／スイッチ１４１ａと，ＶＬＡＮ（仮想ローカルエリアネットワーク）スイッチ１４１ｂと，サーバ１４２と，ＳＡＮスイッチ１４３と，ストレージ１４４とを接続して，それらによる通信を可能にし，さらに，ルータ２１経由のネットワーク１２との通信を可能にする。統合管理システム１１１，ネットワーク管理サーバ１３１，サーバ管理サーバ１３２，およびストレージ管理サーバ１３３は，それぞれが，システムバス２１２を通して内部接続されているＣＰＵ　２２２，メモリ２２３，ＮＩＣ（ネットワークインターフェースカード）２２１，およびディスクドライブ２２４を含む汎用コンピュータである。統合管理システム１１１は，マイグレーション受け入れプログラム１２１，マイグレーション要求プログラム１２３，およびリソースマネージャプログラム１２２を含み，これらは，ＣＰＵ　２２２ａによる実行に備えて，メモリ２２３ａまたは他のコンピュータ可読媒体にロードされる。連合データセンタテーブル２１３，受信済みマイグレーション要求テーブル２１４，および送信済みマイグレーション要求テーブル２１５が，ディスクストレージ２２４ａに格納され，やはりメモリ２２３ａにロードされることが可能である。統合管理システム１１１は，ユーザインターフェース２１１を含み，ユーザインターフェース２１１は，マイグレーション要求を送信したり，データセンタの管理対象データを管理者などに対して表示したりする機能を実施するために使用される。
【００１４】
[0035]　ネットワークスイッチ１４１は，仮想プライベートネットワーク（ＶＰＮ）２０３の実現を可能にするＶＰＮルータ１４１ａを含むことが可能である。
仮想プライベートネットワークサービスは，インターネットのような共用公衆ネットワークを介して，顧客サイト２０４とサービスプロバイダのデータセンタ１０との間にセキュアなネットワークパスを提供する。各ＶＰＮサービス顧客は，ＶＰＮと接続されるべき１つまたは複数のサイトを有する。ＶＰＮパスの一方のエンドポイントは，顧客のサイトのＶＰＮルータ２０５であり，ＶＰＮパスの他方のエンドポイントは，データセンタ１０内にあるＶＰＮルータ１４１ａにある。データセンタ１０内のＶＰＮルータ１４１ａは，複数のＶＰＮパスを集約し，ＶＰＮ　ＩＤで顧客を識別し，顧客から受け取ったトラフィックを仮想ＬＡＮ（ＶＬＡＮ）スイッチ１４１ｂに送る。
【００１５】
[0036]　
ＶＰＮルータ１４１ａでは，それぞれが異なるＶＰＮ顧客を担当する，複数の仮想ルータ（ＶＲ）プログラム２０６を実行することが可能である。たとえば，図２では，顧客サイトＡ　２０４ａからのＶＰＮパスが，ＶＰＮルータ１４１ａの仮想ルータＡ　２０６ａのところでターミネートされている。同様に，顧客サイトＢ　２０４ｂからのＶＰＮパスが，仮想ルータＢ　２０６ｂに接続されている。各仮想ルータ２０６が，それぞれのルーティングテーブルと，担当する個々の顧客の専用の他のネットワークリソースを有するため，各ＶＰＮ顧客からのパケットは，ネットワークの観点では，明確に分離されている。これにより，たとえば，２人の異なる顧客が，プライベートアドレス範囲において，同じオーバーラップＩＰアドレス空間を使用することが可能になる。
【００１６】
[0037]　
サーバ１４２は，１つまたは複数の物理サーバ２３２と，サービスプロセッサ（ＳＶＰ）２３１とを含む。図示された実施形態では，ＰＳ−００１からＰＳ−００８までのラベルが付けられた８つの物理サーバ２３２があるが，物理サーバ２３２の数は変更可能である。複数の仮想マシンマネージャ（ＶＭＭ）２３３が利用可能であり，本発明の実施形態では，顧客は，これらのうちの１つを選択して，そこで自分のアプリケーションを実行することが可能である。図２では，仮想マシンマネージャＶＭＭ−００１　２３３ａ，ＶＭＭ−００２　２３３ｂ，およびＶＭＭ−００３　２３３ｃが，利用可能であるとして示されている。
【００１７】
[0038]　
仮想マシンマネージャ２３３は，それらが制御しているサーバのＣＰＵ能力およびメモリを，顧客のニーズに応じて割り当てることが可能である。
【００１８】
[0039]　ストレージ１４４は，サーバ１４２によって使用される複数の論理ストレージボリューム２４３を提供する，１つまたは複数のストレージシステムを含む。各ボリューム２４３は，ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ　Ｄｉｓｋｓ）として構成されることが可能なアレイグループ２４２から切り分けられることが可能である。構成によっては，各アレイグループ２４２が，異なるタイプのディスクおよび／または異なるレベルのＲＡＩＤによって構成され，それによって異なるレベルのパフォーマンスを提供することが可能である。図２では，ボリュームＶｏｌ−１０１　２４３ａおよびＶｏｌ−１０２　２４３ｂがアレイグループ２４２ａから切り分けられ，ボリュームＶｏｌ−２０１　２４３ｃおよびＶｏｌ−２０２　２４３ｄがアレイグループ２４２ｂから切り分けられ，ボリュームＶｏｌ−３０１　２４３ｅおよびＶｏｌ−３０２　２４３ｆがアレイグループ２４２ｃから切り分けられている。各アレイグループ２４２は，ストレージコントローラ２４１によって制御される。仮想サーバ２３４，物理サーバ２３２，およびストレージボリューム２４３は，ストレージエリアネットワーク（ＳＡＮ）を介して接続されることが可能である。この接続は，ファイバチャネルであっても，他のタイプの接続であってもよい。図２では，ＳＡＮスイッチ１４３により，サーバ２３２，２３４，およびボリューム２４３が，ＳＡＮとして接続されている。
異なる顧客向けのサーバおよびボリュームを互いに隔離するために，特定ストレージボリュームへのアクセスが特定の仮想サーバ２３４または物理サーバ２３２に限定されるように，ＳＡＮスイッチ１４３および／またはストレージボリューム２４２を構成することが可能である。
Ｌ　「【００３３】
[0061]　図１２は，マイグレーション要求プログラム１２３が別のデータセンタへのマイグレーション要求を開始するために作成および送信するマイグレーション要求文書１３を示す。
マイグレーション要求文書１３は，ＶＰＮ要求部１３５，サーバ要求部１３６，およびストレージ要求部１３７の３つの部分からなる。ＶＰＮ要求部１３５は，「帯域幅」１２１１を含む，要求されるネットワークについての情報を有する。図１２では，「帯域幅」エントリ１２１１は，１．５Ｍｂｐｓの帯域幅が要求されることを示す。
ストレージ要求部１３７は，マイグレーション用として要求される各論理ボリュームの要件の情報を含む。図１２では，ストレージ要求部１３７は，４つの異なるボリューム，すなわち，システムボリューム，インデックスボリューム，データボリューム，およびログボリュームの要件１２６１〜１２６４を有する。「ボリューム」１２５２に対する各要求は，要求される「容量」１２５３，「アクセス時間」１２５４，「読み出し／書き込み比」１２５５，および「ランダム／シーケンシャル比」１２５６の情報を含むことが可能である。
Ｍ　「【００３９】
[0068]　ステップ１３２０で，第２のデータセンタのマイグレーション受け入れプログラム１２１は，ステップ１３１４で第１のデータセンタのマイグレーション要求プログラム１２３から送られたマイグレーション要求文書１３を受け取り，リソースマネージャプログラム１２２を起動して，そのマイグレーション要求を受け入れることが可能かどうかを決定する。
【００４０】
[0069]　
ステップ１３２２で，リソースマネージャプログラム１２２は，マイグレーション要求文書１３のＶＰＮ要求部１３５を処理し，第２のデータセンタにおいて利用可能なＶＰＮ帯域幅容量を要求帯域幅と比較するかたちでチェックし，結果をマイグレーション受け入れプログラム１２１に返す。
【００４１】
[0070]　ステップ１３２４で，リソースマネージャプログラム１２２は，利用可能なサーバ容量およびパフォーマンスを，要求された容量およびパフォーマンスと比較するかたちでチェックすることによって，マイグレーション要求文書１３のサーバ要求部１３６を処理し，結果をマイグレーション受け入れプログラム１２１に返す。サーバ容量をチェックするプロセスの詳細については，図１５を参照して後述する。
【００４２】
[0071]　
ステップ１３２６で，リソースマネージャプログラム１２２は，利用可能なストレージ容量およびパフォーマンスを，要求された容量およびパフォーマンスと比較するかたちでチェックすることによって，マイグレーション要求文書１３のストレージ要求部１３７を処理し，結果をマイグレーション受け入れプログラム１２１に返す。
Ｎ　「【００６９】
（途中省略）
[00101]　利用可能なストレージ容量／パフォーマンスをチェックするフローチャート
【００７０】
[0102]　図１６は，マイグレーション要求文書１３のストレージ要求部１３７に関して利用可能なストレージ容量およびパフォーマンスをチェックする，図１３のステップ１３２６の例示的詳細フローチャートである。
【００７１】
[0103]　ステップ１６０１で，リソースマネージャプログラム１２２は，指定された各ボリュームに対する要求を個別に処理するために，ストレージ要求部１３７からレコード１２６１〜１２６４のうちの１つを取り出す。
【００７２】
[0104]　ステップ１６０２で，リソースマネージャプログラム１２２は，そのレコードから各値（すなわち，「容量」１２５３，「アクセス時間」１２５４，「読み出し／書き込み比」１２５５，および「ランダム／シーケンシャル比」１２５６）を読み込む。
【００７３】
[0105]　
ステップ１６０３で，リソースマネージャプログラム１２２は，特定のボリュームについてステップ１６０２で読み込まれた要求値を満たす，データセンタ内のアレイグループを検索する。ボリュームを切り分けるのに適したアレイグループは，以下の式を用いて見つけることが可能である。
（容量＞要求された容量）
かつ
（読み出し／書き込み比＊０．９）＜要求された読み出し／書き込み比＜（読み出し／書き込み比＊１．１）
かつ
（（ランダム／シーケンシャル比＊０．９）＜要求されたランダム／シーケンシャル比＜（ランダム／シーケンシャル比＊１．１））
かつ
（アクセス時間＜要求されたアクセス時間）
【００７４】
[0106]　
たとえば，図１２の例によれば，システムボリュームレコード１２６１のストレージ要求は，要求された「容量」として「１０ＧＢ」，要求された「アクセス時間」１２５４として「２４ｍｓ」，要求された「読み出し／書き込み比」として「８０％」，および要求された「ランダム／シーケンシャル比」として「１０％」を指定する。ストレージボリュームリソーステーブル５１１でレコードを検索すると，レコード９２４が，システムボリュームについての要求された要件を満たすことがわかる。
【００７５】
（途中省略）
【００７９】
[0111]　ステップ１６０８で，リソースマネージャプログラム１２２は，結果をマイグレーション受け入れプログラム１２１に返す。
したがって，本発明の一特徴として，アプリケーションをマイグレーションするかどうかを決定する前に，アプリケーションのストレージパフォーマンスを本質的に保証することが可能であり，特定のアプリケーションのタイプおよび要件に応じて，アプリケーションの様々なパフォーマンス指標または値を指定することが可能である。
Ｏ　「【図２】
」
（３）参考文献１
　本願の優先日前に頒布された刊行物である，特開２０１１−１６０３００号公報（平成２３年８月１８日出願公開。以下，「参考文献１」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｐ　「【０００１】
　本発明は，ルータ，ルーティング方法，ルーティングプログラム，情報処理装置，仮想マシン構築方法および仮想マシン構築プログラムに関する。
【背景技術】
【０００２】
　従来より，インターネットサービスプロバイダ（ISP）に接続するルータの設定情報をネットワークから取得することにより，ルータ購入者によるルータ内のインターネット接続の設定を容易にする技術が知られている。この技術では，ルータがモデムに接続されたとき，ルータはブロードバンドアクセスサーバにアクセスし，RADIUSサーバに認証された後，機器認証サーバにおいて，機器認証される。その後，ルータはISPダウンロードサーバより，ISPサーバに接続する際に使用する設定情報を取得する。ルータは，取得した設定情報を自らに設定し，その設定情報を基に，ISPサーバに接続し，ISPサーバ経由で，インターネット上のWEBページのHTMLなどを取得する。
【０００３】
　また，
従来より，クラウドデータセンタ上の仮想マシンを利用したシステムを，顧客のイントラネットから利用する技術が知られている。このシステムでは，クラウドデータセンタ内の物理サーバが，顧客の業務を実行する仮想マシンを起動し，顧客のイントラネットに接続される端末（例えば，コンピュータ）に顧客の業務に利用可能なサービスを提供している。
（４）参考文献２
　本願の優先日前に頒布された刊行物である，特開２０１１−２５８０９８号公報（平成２３年１２月２２日出願公開。以下，「参考文献２」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｑ　「【０００２】
　経済のグローバル化と競争激化に伴い，企業は絶え間ない変革を求められている。企業活動を支えるＩＴシステムにおいても，１〜２ヵ月程度の超短期間でシステム構築とサービスの提供開始が要求されることも珍しくなくなっており，企業がＩＴシステムを自社（インハウス）で構築して所有し続けるコストが重荷となっている。そこで，
近年広帯域化が著しいワイドエリアネットワーク（ＷＡＮ）を活用したサービスとして，ＩＴシステムをデータセンタの事業者にアウトソースして，企業は必要な期間のみ計算機資源を利用可能なクラウドコンピューティングが台頭している。
【０００３】
　
クラウドコンピューティングが提供するサービスの形態は，提供するＩＴリソースの柔軟度に応じて，ＩａａＳ（Infrastructure as a Service），ＰａａＳ（Platform as a Service），ＳａａＳ（Software as a Service）の３種類のクラウドサービスに大別される。ＩａａＳは電力や設置場所，ネットワークバックボーン等のインフラを貸し出すクラウドサービスであり，ＰａａＳはインフラに加えてＩＴ機器のハードウェアと仮想マシンモニタ（Virtual Machine Monitor＝ＶＭＭ），仮想マシン，ＯＳまでをデータセンタ事業者が準備して，企業に仮想マシン（Virtual Machine）を貸し出すクラウドサービスである。ＳａａＳは更に仮想マシンに加えて業務アプリケーションまでもデータセンタ事業者が準備し，企業は時間貸しで業務アプリケーションを利用するサービス形態となる。
【０００４】
　
グローバルで先行するクラウドベンダは，ＰａａＳやＳａａＳ相当のビジネスを行っている。これらのベンダのサービスは俗にパブリッククラウドと呼ばれ，インターネット経由でサービスが提供される。パブリッククラウドは非常に低価格かつ迅速なサービス提供開始が可能である一方，インターネットでの一時的な通信の混雑や切断が生じるため，エンドｔｏエンド（クライアントの端末から業務アプリケーション）での安定的なサービス提供が難しいという性質を有する。そのため信頼性に対する不安から，企業の中核的なＩＴシステムに対してはパブリッククラウドの適用が進んでいない。
【０００５】
　一方，インターネットではなく，キャリアが提供する専用線，ＩＰ−ＶＰＮ，広域イーサネット（登録商標）等の回線サービスを利用するＷＡＮサービスは，インターネットに比して信頼性及び通信品質が高く，企業の中核的なＩＴシステムに適している。
ＷＡＮを利用したクラウドサービスとしては，ＰａａＳに相当する仮想マシン単位でのサーバリソースの貸出を行うサービスが知られている（例えば，Harmonious Cloud（http://www.hitachi.co.jp/products/it/harmonious/cloud/solution/paas.html）。ＷＡＮを用いたＰａａＳは，パブリッククラウドとは異なり高い信頼性を特長としており安定的なクラウドサービスの提供が可能である。
（５）参考文献３
　本願の優先日前に頒布された刊行物である，「渡邉　利和，−クラウドに最適化される仮想化プラットフォーム−　進化するデータセンターの仮想化　−Ｐａｒｔ１−１　クラウドに向けた仮想化インフラの進化を着実に進めるＶＭｗａｒｅ，データセンター完全ガイド　２０１２年冬号，株式会社インプレスビジネスメディア，２０１１年１２月３１日，第３５号．３５，ｐ５４〜５７」（以下，「参考文献３」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｒ　「●ストレージの仮想化
　ストレージの仮想化が大きく進化した点も，ｖＳｐｈｅｒｅ５の重要なポイントだ。従来“ストレージの仮想化”というと，主にストレージハードウェア側での仮想化技術のことを指しており，ハイパーバイザー側からは従来通りに「明示的に割り当てられた領域にアクセスする」というモデルで利用するだけだった。しかし，ｖＳｐｈｅｒｅ５ではＶＭに対するストレージ領域の割り当ても仮想化され，運用管理者は論理的な結び付きを管理するだけで済む，新しいインターフェイスが提供された。このベースになっているのは以前から実装済みの”Ｓｔｏｒａｇｅ　ｖＭｏｔｉｏｎ”の機能だ。Ｓｔｏｒａｇｅ　ｖＭｏｔｉｏｎによって，必要に応じてストレージ領域のコピーを別の領域に作り，割り当て変更を行うことはできるようになっていた。ｖＳｐｈｅｒｅ５ではこの機能を活用するための上位機能を拡張し，
ストレージのアクセス性能などのポリシーに基づいて，適切なストレージを選択する機能が新たに加わった
Ｓｔｏｒａｇｅ　ＤＲＳを実現するに当たって，管理者側ではストレージを従来のような「物理デバイス上に作成された特定の領域」という指定ではなく，ポリシーに基づいた指定を行う。具体的には，１／０性能が高いストレージとか，容量単価の安いストレージ，といった属性が考えられるだろう。個々のストレージ上に確保された領域がどのような属性を持つかをｖＳｐｈｅｒｅ側で管理し，各ＶＭからのストレージ割り当て要求に対して適切な属性を持つストレージ領域を自動的に割り当てていくというのが，Ｓｔｏｒａｇｅ　ＤＲＳの基本的な考え方となる。
（６）参考文献４
　本願の優先日前に頒布された刊行物である，「竹内　博史　他１名，Ｔｅｃｈ×ＡＳＣＩＩ．ｊｐ特別編集　ＲＡＩＤの基礎から最新の階層化管理まで　ゼロからはじめるストレージ入門，株式会社アスキー・メディアワークス，２０１０年３月２４日，ｐ４」（以下，「参考文献４」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｓ　「
ストレージアレイ
　
「ストレージアレイ」は，「ディスクアレイ」とも呼ばれている製品で，おもに企業向けのサーバー（たとえばメールサーバーやデータベースサーバーなど）へ接続されることを想定して設計されている（図５）。ストレージアレイは，ＨＤＤを収める筐体（ディスクエンクロージャまたはディスクシェルフと呼ばれている）と，ＨＤＤの制御装置（コントローラ）およびサーバーと接続する専用のインターフェイスから構成されている。
　
なお，ストレージアレイはＨＤＤの搭載数やコントローラの性能の違いなどにより，複数の機種が小規模から大規模環境向けとして販売されており，価格も数十万円から数千万円までとさまざまである。
　次のＰａｒｔでは，ＨＤＤの仕組みや種類，および利用形態（ＪＢＯＤやＲＡＩＤ）について解説し，それぞれの特徴や耐障害性なども見てみよう。」（第４頁右欄３〜１８行）
（７）参考文献５
　本願の優先日前に頒布された刊行物である，「挾間　崇　他３名，ストレージ仮想化大全　−Ｐａｒｔ１　ストレージ仮想化を実現する技術−，システム開発ジャーナル，株式会社毎日コミュニケーションズ，２００８年３月２９日，第３巻，ｐ７０〜７７」（以下，「参考文献５」という。）には，図面とともに，以下の事項が記載されている。（下線は当審において付したものである。） 
Ｔ　「
第１世代のストレージ仮想化技術
　
第１世代の仮想化はストレージアレイベースのみで，ストレージアレイ配下の複数の物理ディスクを１つのプールとしてとらえ，そのプールから必要な容量のボリュームを切り出して，サーバに提供します（図１）。この方法は，１つの物理ディスクの容量に左右されることなく，少量のボリュームから大容量のボリュームまでを柔軟に扱うことができます。一般的にはＲＡＩＤやＬＵ（論理ユニット）と呼ばれる技術になります。
４．対比 
　本願発明と，引用発明とを比較する。 
 　 
ア　引用発明の「複数のＣＰＵコア１２０」は，仮想サーバに割り当てるために“利用可能”な，“マルチプロセッサシステム１００上のリソース”であるから，本願発明の「複数の利用可能なリソース」に相当する。
　引用発明の「仮想マシンモニタ３００」は，「仮想サーバに，Ｉ／Ｏデバイス，プロセッサ，及びメモリ等のマルチプロセッサシステム１００上のリソースを割り当てる」ものであるから，引用発明の「仮想サーバ」は，「仮想マシンモニタ３００」によってリソースを割り当てられるものである点で，本願発明の「仮想マシン」に相当し，引用発明において，「仮想サーバ」に「マルチプロセッサシステム１００上のリソースを割り当てる」ことは，「仮想サーバ（仮想マシン）」を，“マルチプロセッサシステム１００内で”“配置する”ことに他ならないから，引用発明の「複数のＣＰＵコア１２０と複数のメモリ１５０と複数のＩ／Ｏデバイス１９０とを含むマルチプロセッサシステム１００内で，仮想サーバに，Ｉ／Ｏデバイス，プロセッサ，及びメモリ等のマルチプロセッサシステム１００上のリソースを割り当てる仮想マシンモニタ３００のプログラムを実行するための装置」と本願発明の「複数の利用可能なリソースを含むクラウドネットワーク内で仮想マシンの配置を提供するための装置」とは，後記する点で相違するものの，「複数の利用可能なリソースを含むシステム内で仮想マシンの配置を提供するための装置」である点で共通する。
イ　引用発明の「仮想マシンモニタ３００のプログラムが展開されるメモリ１５０」は，「仮想マシンモニタ３００のプログラムを実行するための装置」が備える“ストレージ”とみることができるから，本願発明の「データストレージ」に相当する。
ウ　引用発明の「仮想マシンモニタ３００のプログラムを実行する仮想マシンＣＰＵコア１２０」は，「仮想マシンモニタ３００のプログラムが展開されるメモリ１５０」に“通信可能に結合され”ていることは明らかであるから，「仮想マシンモニタ３００のプログラムを実行するための装置」が備える“プロセッサ”であるといえ，本願発明の「データストレージに通信可能に結合されたプロセッサ」に相当する。
エ　引用発明の「仮想マシンモニタ３００は，サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆを２１０介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０を取得してメモリ１５０に格納し」（前者）と本願発明の「複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データをデータストレージに収集し」（後者）とを対比すると，
　引用発明において収集される“物理ハードウェア構成情報取得Ｉ／Ｆ３２０”は，“コンポーネント間距離対応表５００”を含んでおり，当該“コンポーネント間距離対応表５００”は，“マルチプロセッサシステム１００上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離”を含むものであり，“対コンポーネント間距離”には，“ＣＰＵコア１２０が接続されるＣＰＵソケット１１０とＩ／Ｏデバイス１９０が接続されるＩ／Ｏハブ１６０のと間の距離”が含まれていて，この２者間の距離は，実質的には，“ＣＰＵコア１２０とＩ／Ｏデバイス１９０の間の距離”とみることができるところ，
　引用発明の「ＣＰＵコア１２０」「メモリ１５０」が，それぞれ，本願発明の「複数の利用可能なリソース」「データストレージ」に相当し，
　また，上記Ｃで引用した引用例１の段落【００２７】の「仮想マシンモニタ300のプログラムは，いずれかのI/Oデバイス190上，あるいはサービスプロセッサ200のROM201上に存在し，マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され，仮想マシンCPUコア120のいずれかの上で実行される。」との記載や，「ゲストOS 360は，仮想マシンモニタ300によって分割された論理サーバ370に割り当てられたI/Oデバイス190のいずれかの上にプログラムが存在し，論理サーバ370の起動時に370に割り当てられたメモリ150の上に展開され， 370に割り当てられたCPUコア300によって実行される。」との記載から，引用発明の「Ｉ／Ｏデバイス１９０」は，「ストレージ」であると認められるから，引用発明の「複数のＩ／Ｏデバイス１９０」は，「複数のストレージ」である点で，本願発明の「複数のストレージアレイ」と共通しており，
　さらに，引用発明の「距離」は，「モジュール間接続Ｉ／Ｆ２００が不均一な場合は，マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００の帯域とレイテンシを示す項目からなる物理ネットワーク構成表５５０にあるレイテンシの合計値」を使って示されるものであるから，引用発明の「対コンポーネント間距離」は，本願発明の「通信経路の１つまたは複数のネットワーク性能特性」であるといえるので，引用発明の「対コンポーネント間距離」を含む「コンポーネント間距離対応表５００」をさらに含む「物理ハードウェア構成情報取得Ｉ／Ｆ３２０」は，本願発明の「１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データ」に相当するといえ，
　また，引用発明の「ＣＰＵコア１２０が接続されるＣＰＵソケット１１０と，Ｉ／Ｏデバイス１９０が接続されるＩ／Ｏハブ１６０」「の相互間の距離を示す対コンポーネント間距離」と本願発明の「複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性」とは，「複数のストレージと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性」である点で共通するといえる。
　そうすると，前者と後者とは，後記する点で相違するものの，
「複数のストレージと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データをデータストレージに収集し」ている点で共通する。
オ　引用発明では，「仮想サーバに対する論理ハードウェア要求Ｉ／Ｆによって，リソース割当ポリシーをＣＰＵ−メモリ優先又はＩ／Ｏ−メモリ優先のように指定した要求が行われると」，「仮想マシンモニタ３００」は，「論理ハードウェア要求Ｉ／Ｆに対して要求を行った結果に対応するよう,リソース割当ポリシーに対応したＣＰＵ−メモリ，Ｉ／Ｏ−メモリ，及びＣＰＵ−Ｉ／Ｏの３種類のカテゴリごとにリソースｆｒｏｍからリソースｔｏまでのコンポーネント間距離を，所属するコンポーネントと，コンポーネント間距離対応表５００に従って計算し，さらに，カテゴリごとにコンポーネント間距離の総和を計算して，リソース間距離計算表６００を計算し」，「リソース間距離計算表６００を計算したリソース割当候補の中から，リソース割当ポリシーを最も満たす候補を選択することで，仮想サーバに割り当てるハードウェアリソースを最適化するようにし」ていることから，「コンポーネント間距離対応表５００」を含む「物理ハードウェア構成情報取得Ｉ／Ｆ３２０」（本願発明の「第２のセットのネットワーク性能データ」に相当する。）に“基づいて”，仮想サーバに，リソースを割り当てているということができ，
　上記アにおける検討も踏まえると，
　引用発明と本願発明とは，後記する点で相違するものの，「第２のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定する」点で共通する。
カ　上記ウの検討から，引用発明の仮想マシンモニタが実行する上記エの“収集する”動作，及び上記オの“決定する”動作が，「仮想マシンモニタ３００のプログラムを実行するための装置」が備える“プロセッサ”によって実行されていることは明らかであるから，上記ウ〜オの検討を総合すると，引用発明と本願発明とは，後記する点で相違するものの，
「プロセッサは，
　　複数のストレージと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データをデータストレージに収集し，
　　第２のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定するように構成され」
ている点で共通している。
キ　引用発明の「仮想サーバ１＿３７０ａ」は，「ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃ」を含んでいるところ，仮想サーバが「ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃ」を含んでいることは，上記アの検討を踏まえれば，仮想マシンが「ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃ」を含んでいることに他ならないから，
　引用発明と本願発明とは，後記する点で相違するものの，
「仮想マシンは，１つまたは複数のストレージの少なくとも１つと複数の利用可能なリソースの少なくとも１つを含」む点で一致する。
ク　引用発明の「仮想サーバ１＿３７０ａ」は，「ＣＰＵコア１２０（＃０，＃１，＃２，＃３）と，メモリ１５０（＃４，＃５，＃６，＃７）とＩ／Ｏデバイス１９０ａ，１９０ｃ」を含み，「ＣＰＵコア１２０（＃０，＃１）とＩ／Ｏデバイス１９０ａとは，モジュール間接続Ｉ／Ｆ２００の＃５で接続され，また，ＣＰＵコア１２０（＃２，＃３）とＩ／Ｏデバイス１９０ｃとは，モジュール間接続Ｉ／Ｆ２００の＃６で接続される」ものであるところ，
　引用発明の「ＣＰＵコア１２０（＃０，＃１）」が本願発明の「第１の利用可能なリソース」に相当し，以下同様に，引用発明の「モジュール間接続Ｉ／Ｆ２００の＃５」が本願発明の「第１の経路」に，引用発明の「ＣＰＵコア１２０（＃２，＃３）」が本願発明の「第２の利用可能なリソース」に，引用発明の「モジュール間接続Ｉ／Ｆ２００の＃６」が本願発明の「第２の経路」にそれぞれ相当し，
　また，上記エの検討から，引用発明の「Ｉ／Ｏデバイス１９０」は，「ストレージ」である点で，本願発明の「ストレージアレイ」と共通していることから，引用発明の「Ｉ／Ｏデバイス１９０ａ」，「Ｉ／Ｏデバイス１９０ｃ」が本願発明の「第１のストレージアレイ」，「第２のストレージアレイ」に対応するので，
　引用発明と本願発明とは，後記する点で相違するものの，
「複数の通信経路は，第１のストレージと第１の利用可能なリソースの間の第１の経路と，第２のストレージと第２の利用可能なリソースの間の第２の経路を含」む点で共通している。
ケ　上記クの検討から，引用発明の「ＣＰＵコア１２０（＃０，＃１）」が本願発明の「第１の利用可能なリソース」に相当し，引用発明の「ＣＰＵコア１２０（＃２，＃３）」が本願発明の「第２の利用可能なリソース」に相当するから，
　引用発明と本願発明とは，
「第１の利用可能なリソースと第２の利用可能なリソースは異なって」いる点で一致する。
コ　上記クの検討を踏まえると，
　引用発明と本願発明とは，後記する点で相違するものの，
「１つまたは複数のストレージは，第１のストレージと第２のストレージを含み，複数の利用可能なリソースは，第１の利用可能なリソースと第２の利用可能なリソースを含む」点で共通している。
　
 　以上の検討から，本願発明と引用発明とは， 
 　 
 「複数の利用可能なリソースを含むシステム内で仮想マシンの配置を提供するための装置であって，
　データストレージと，
　データストレージに通信可能に結合されたプロセッサとを備え，プロセッサは，
　複数のストレージと複数の利用可能なリソースの間の複数の通信経路の１つまたは複数のネットワーク性能特性を示す第２のセットのネットワーク性能データをデータストレージに収集し，
　第２のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定するように構成され，
　仮想マシンは，１つまたは複数のストレージの少なくとも１つと複数の利用可能なリソースの少なくとも１つを含み，
　複数の通信経路は，第１のストレージと第１の利用可能なリソースの間の第１の経路と，第２のストレージと第２の利用可能なリソースの間の第２の経路を含み，
　第１の利用可能なリソースと第２の利用可能なリソースは異なっており，
　１つまたは複数のストレージは，第１のストレージと第２のストレージを含み，複数の利用可能なリソースは，第１の利用可能なリソースと第２の利用可能なリソースを含む，装置。」 
 　 
の点で一致し，以下の点で相違する。 
 　 
［相違点１］ 
　仮想マシンが配置されるシステムが，
　本願発明では，「クラウドネットワーク」であるのに対して，引用発明では，マルチプロセッサシステム１００内である点。
  
［相違点２］ 
　本願発明では，「クラウドネットワーク内の１つまたは複数のストレージの性能特性を示す第１のセットのストレージ性能データをデータストレージに収集し」，「第１のセットのストレージ性能データ」および第２のセットのネットワーク性能データに基づいて仮想マシンの配置場所を決定するように構成されているのに対して，引用発明では，そのような構成になっていない点。
［相違点３］
　本願発明のストレージが，「ストレージアレイ」であるのに対して，引用発明のＩ／Ｏデバイスは，ストレージアレイではない点。
５．判断　 
　上記各相違点について，検討する。 
  
［相違点１］について 
　クラウドネットワーク上で，仮想マシンを配置することは，例えば引用例２（上記Ｋ及びＯの記載を参照。），参考文献１（上記Ｐの記載を参照。），又は参考文献２（上記Ｑの記載を参照。）に記載されているように，本願の優先日前に，当該技術分野における周知技術であったと認められるから，引用発明のハードウェアリソースをクラウドネットワークのリソースとすることで，仮想マシンをクラウドネットワーク上で配置するように構成すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
［相違点２］について 
　引用例２（上記Ｌ，Ｍ，及びＮの記載を参照。）や参考文献３（上記Ｒの記載を参照。）には，ストレージの性能を考慮して仮想マシンを割り当てる技術が記載されており，特に引用例２（上記Ｌ及びＭの記載を参照。）には，ネットワークの性能とストレージの性能の両方を考慮して仮想マシンを割り当てることも記載されていることから，上記［相違点１］の判断も踏まえると，引用発明において，ネットワークの性能に加えて，クラウドネットワーク内のストレージの性能も考慮して仮想マシンを配置するように構成することは，当業者が容易に想到し得たことである。
［相違点３］について
　ストレージとして，複数の物理ディスクから構成されたストレージアレイを用いることは，例えば，参考文献４（上記Ｓの記載を参照），参考文献５（上記Ｔの記載を参照）等に記載されているように，本願の優先日前に当該技術分野において広く知られた周知技術であるものと認められることから，上記［相違点１］の判断も踏まえると，引用発明のストレージをストレージアレイとすること，すなわち，上記相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
  
　そして，上記各相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明，引用例２に記載の技術，参考文献３に記載の技術，及び引用例２，参考文献１，２，４，５に記載の周知技術から予測される範囲内のものにすぎず，格別顕著なものということはできない。
  
　したがって，本願発明は，引用発明，引用例２に記載の技術，参考文献３に記載の技術，及び引用例２，参考文献１，２，４，５に記載の周知技術に基づいて，当業者が容易に発明をすることができたものである。 
  
 ６．むすび　 
　以上のとおり，本願発明は，引用発明，引用例２に記載の技術，参考文献３に記載の技術，及び引用例２，参考文献１，２，４，５に記載の周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
　したがって，本願は拒絶されるべきものである。 
  
　よって，結論のとおり審決する。