• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1343789
審判番号 不服2017-9135  
総通号数 226 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2018-10-26 
種別 拒絶査定不服の審決 
審判請求日 2017-06-22 
確定日 2018-09-05 
事件の表示 特願2014-553293「ネットワークおよびストレージアウェア仮想マシン配置のための方法および装置」拒絶査定不服審判事件〔平成25年 7月25日国際公開、WO2013/109344、平成27年 2月 5日国内公表、特表2015-504224〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は,2012年(平成24年)11月28日(パリ条約による優先権主張外国庁受理2012年1月17日(以下,「優先日」という。),米国)を国際出願日とする出願であって,平成27年11月13日付けの拒絶理由通知に対して平成28年1月29日付けで意見書が提出されると共に手続補正がなされ,平成28年6月29日付けの拒絶理由通知に対して平成28年12月14日付けで意見書が提出されると共に手続補正がなされたが,平成29年2月23日付けで拒絶査定がなされ,これに対して平成29年6月22日に拒絶査定不服審判の請求がなされたものである。

2.本願発明
本願の請求項1に係る発明(以下,「本願発明」という。)は,平成28年12月14日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものである。

「 【請求項1】
複数の利用可能なリソースを含むクラウドネットワーク内で仮想マシンの配置を提供するための装置であって,
データストレージと,
データストレージに通信可能に結合されたプロセッサとを備え,プロセッサは,
クラウドネットワーク内の1つまたは複数のストレージアレイの性能特性を示す第1のセットのストレージ性能データをデータストレージに収集し,
複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データをデータストレージに収集し,
第1のセットのストレージ性能データおよび第2のセットのネットワーク性能データに基づいてクラウドネットワーク内の仮想マシンの配置場所を決定するように構成され,
仮想マシンは,1つまたは複数のストレージアレイの少なくとも1つと複数の利用可能なリソースの少なくとも1つを含み,
複数の通信経路は,第1のストレージアレイと第1の利用可能なリソースの間の第1の経路と,第2のストレージアレイと第2の利用可能なリソースの間の第2の経路を含み,
第1の利用可能なリソースと第2の利用可能なリソースは異なっており,
1つまたは複数のストレージアレイは,第1のストレージアレイと第2のストレージアレイを含み,複数の利用可能なリソースは,第1の利用可能なリソースと第2の利用可能なリソースを含む,装置。」

3.引用例
(1)引用例1
原査定の拒絶理由で引用された,本願の優先日前に頒布された刊行物である,特開2009-151745号公報(平成21年7月9日出願公開。以下,「引用例1」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

A 「【0012】
本発明は,1つ以上のプロセッサと,1つ以上のメモリと1つ以上のI/Oデバイスとを内部ネットワークで接続し,前記プロセッサとメモリ及びI/Oデバイスを仮想サーバに割り当てる仮想マシンモニタを備えたマルチプロセッサシステムであって,前記仮想マシンモニタは,前記マルチプロセッサシステムの前記プロセッサとメモリとI/Oデバイス及びネットワークを含むハードウェアの物理的な位置情報を含むハードウェアの構成情報を取得する物理ハードウェア情報取得部と,生成する仮想サーバのプロセッサの数とメモリ量とI/Oデバイス及びリソースの割り当てポリシーとを含む生成要求を受け付ける受付部と,前記受け付けた生成要求に基づいてI/Oデバイスを前記仮想サーバに割り当ててから,前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と,を備える。」

B 「【0017】
図1は第1の実施形態を示し,本発明を適用するマルチプロセッサシステム(計算機),およびその上で動作する仮想マシンモニタとゲストOSとの関係を示したブロック図である。
【0018】
マルチプロセッサシステム100は,1つ以上のCPUソケット(プロセッサパッケージ)110,メモリコントローラ130,I/Oハブ160a,160bをモジュール間接続I/F(インターフェース)200にて接続した構成を採る。なお,モジュール間接続I/F200は,マルチプロセッサシステム100の内部ネットワークを構成する。ここでCPUソケット110とメモリコントローラ130間,CPUソケット110とI/Oハブ160a,160b間,メモリコントローラ130とI/Oハブ160a,160b間のモジュール間接続I/F200が必ずしも同じI/Fである必要はない。それらが異なるI/Fであったとしても以下の説明には差異を生じない。なお,I/Oハブ160a,160bの総称をI/Oハブ160とする。また,メモリコントローラ130やI/Oハブ160の機能を搭載したチップセットが存在していても良い。さらに,図1に示すように,メモリコントローラ130がCPUソケット110上に搭載されたような構成であっても良い。CPUソケット110は1つ以上のCPUコア(プロセッサコア)120を含む。メモリコントローラ130はメモリI/F140を介して1つ以上のDIMM(Dual Inline Memory Module)150と接続する。I/Oハブ160はI/O接続I/F170を介して1つ以上のI/Oアダプタ180a?180fを搭載し,I/Oアダプタ180a?180fの先にはI/Oデバイス190dが接続される。さらにI/O接続I/F170の先にI/OブリッジやI/Oスイッチがあり,多段のI/Oを構成していても良い。なお,I/Oアダプタ180a?180fは,NICやHBA(Host Bus Adapter)などで構成され,これらの総称をI/Oアダプタ180とする。」

C 「【0027】
図64は,図1の構成に対応するマルチプロセッサシステム100上で,仮想マシンモニタ300,ゲストOS1 360a,ゲストOS2 360b,ゲストOS3 360cが実行されている様子を示した構成図である。仮想マシンモニタ300のプログラムは,いずれかのI/Oデバイス190上,あるいはサービスプロセッサ200のROM201上に存在し,マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され,仮想マシンCPUコア120のいずれかの上で実行される。仮想マシンモニタ300を実行するCPUコア120は,固定されていても良いし,例えばその時空いているCPUコアや処理負荷が少ないCPUコアが実行するなどCPUコアの稼動状態に応じて実行するCPUコアが可変でも良い。
ゲストOS 360は,仮想マシンモニタ300によって分割された論理サーバ370に割り当てられたI/Oデバイス190のいずれかの上にプログラムが存在し,論理サーバ370の起動時に370に割り当てられたメモリ150の上に展開され, 370に割り当てられたCPUコア300によって実行される。図64の例では,ゲストOS1 360aはメモリ150#5上に,ゲストOS2 360bはメモリ150#10上に,ゲストOS3 360cはメモリ150#13へと展開され,実行されている。なお,本例ではわかりやすいように一つのメモリモジュール上にゲストOS 360を配置した例を示したが,ゲストOSのサイズやメモリインタリーブの設定によっては複数のメモリモジュール上に分散配置されることもあり得る。
【0028】
図2?図6で仮想マシンモニタ300がサービスプロセッサ220経由で得たマルチプロセッサシステム100の物理ハードウェア構成情報取得I/F320について示す。図2は物理ハードウェア構成情報取得I/F320の内訳を示す。物理ハードウェア構成情報取得I/F320は,物理コンポーネント構成表400,I/Oアダプタ構成表450,コンポーネント間距離対応表500,物理ネットワーク構成表550の4種類の表(テーブル)で構成される。これらのテーブルは,仮想マシンモニタ300が所定の周期または所定のタイミングで,サービスプロセッサ220がモジュール情報取得I/F210を介して収集したハードウェアリソースの情報を問い合わせて生成(または更新)するものである。仮想マシンモニタ300が設定した物理ハードウェア構成情報取得I/F320は,図1に示すI/Oハブ160の物理位置情報格納メモリ165またはメモリ150に格納される。
(途中省略)
【0030】
本実施形態の説明においては,コンポーネント#420はCPUソケット110やI/Oハブ160のように物理的に挿抜あるいは電源のon/offの対象となるオブジェクトを指しており,複数のリソースが1つのコンポーネント#420上に接続され得る。本実施形態の例では,CPUコア120やDIMM150はCPUソケット110というコンポーネントに接続され,I/Oアダプタ180はI/Oハブ160というコンポーネントに接続される。メモリコントローラ130がCPUソケット110とは別の場合や,チップセットが存在する場合などは,それらもまた独立したコンポーネントになり得る。物理コンポーネント構成表400は,このようなリソースとコンポーネントとの包含関係を示す表である。範囲415で示されるリソースがコンポーネント#420に含まれることを示している。リソース種別410がメモリの場合は,対応するDIMM150の番号に加えて,物理アドレスの範囲も示される。この例では1DIMM当たり1GBずつであるため,0x0_0000_0000から0x0_3_FFFF_FFFFまでの16GBが属するCPUソケットに応じて4分割されている。各リソースが稼動状態となった場合の消費電力[W]が430に,リソースの土台となっているコンポーネントが稼動状態となった場合の消費電力が435に示される。例えばコア#0が稼動していてコア#1は稼動していないとする。この場合リソースの消費電力はコア当たり20であるため20だが,土台となるコンポーネントのCPUソケットの消費電力は物理コンポーネント構成表400によると80であるため,合計20+80=100がコア#0のみが稼動している場合の消費電力となる。なお,ここでは物理コンポーネント構成表400のサイズを小さくするために範囲415で同じコンポーネントに属する複数のリソースをまとめて1エントリで示しているが,リソースごとに異なるエントリを使っても構わない。
(途中省略)
【0033】
図5はコンポーネント間距離対応表500の構成を示す。コンポーネント間距離対応表500は,マルチプロセッサシステム100上の全てのコンポーネントに対応するエントリが存在し,コンポーネントの識別子を示すコンポーネント#420と,コンポーネントの種類を示すコンポーネント種別425と,このコンポーネントと他のコンポーネントの距離を示す対コンポーネント間距離510から構成される。対コンポーネント間距離510はまた全てのコンポーネント分だけ分けられており,コンポーネント#420のコンポーネントから対コンポーネント間距離510のコンポーネントに到達するまでの距離を示している。システム全体でN個のコンポーネントがある時,対コンポーネント間距離510はN×Nのマトリックスを構成する。通常,自分自身に到達する距離は0であると考えられるので,このマトリックスの対角線部分には0が並ぶのが普通である。本実施形態ではモジュール間接続I/F200の性能は全て等価であると仮定したため,何回モジュール間接続I/F200を渡れば目的のコンポーネントまで辿り着くかという回数を距離としている。この距離を,コンポーネントの物理的な位置情報として扱う。例えば,CPUソケット110aからI/Oハブ160bまでの距離は,図1において,CPUソケット110aからCPUソケット110dまでの距離がモジュール間接続I/F200を1回経由し,CPUソケット110dからI/Oハブ160bまででモジュール間接続I/F200を1回経由するのでコンポーネント間の距離は合計2となる。
【0034】
なお,モジュール間接続I/Fが不均一な場合は,後述の物理ネットワーク構成表550にあるレイテンシ570の合計値を使って距離を示す,といった方法が考えられる。
(途中省略)
【0037】
図6は物理ネットワーク構成表550の構成を示している。物理ネットワーク構成表550は,マルチプロセッサシステム100上の全てのモジュール間接続I/F200に対して,モジュール間接続I/F200の接続の通し番号を示すネットワーク#555と,どのコンポーネント420aからどのコンポーネント420bをつないでいるのか,そしてコンポーネント420aと420b間の帯域560とレイテンシ570を示す項目からなる。本実施形態では,CPUソケット110間をつなぐネットワークの帯域560は6なのに対して,CPUソケット110とI/Oハブ160の間をつなぐネットワーク帯域560は半分の3であるとした。なお,帯域560の単位は,例えば[Gbps]であり,レイテンシ570の単位は,例えば,[nsec]である。」

D 「【0046】
図9は,上記論理ハードウェア要求I/F350aと物理-論理ハードウェア(HW)割当表310に基づいて,仮想マシンモニタ300の論理ハードウェア割当処理部801がマルチプロセッサシステム100上に割り当てた仮想サーバ1_370aを示す。図中点線で囲まれた部分は図1のリソースのうち仮想サーバ1_370aに割り当てられたリソースを示す。」

E 「【0047】
<第1実施形態における動作>
以下,図10?17で,本第1実施形態の動作について説明する。
【0048】
図10と図11は,仮想マシンモニタ300の論理ハードウェア割当処理部801によって上記図9で示したように仮想サーバ1_370aが割り当てられた後で,次の仮想サーバ2に対する論理ハードウェア要求I/F350bおよび350cを示している。論理ハードウェア要求I/F350bと350cは,どちらも同じI/Oアダプタ353,CPUコア数354,メモリ量355を要求している。違いはリソース割当ポリシー356のみで,論理ハードウェア要求I/F350bにおいては「CPU-メモリ優先」となっているのに対して,論理ハードウェア要求I/F350cにおいては「I/O-メモリ優先」となっている。以下の例では,これらのポリシーの違いにより,異なるリソースが割り当てられる様子を示す。
【0049】
図12と図13は,仮想サーバ2に対する上記図10,図11の論理ハードウェア要求I/F350に対して,仮想マシンモニタ300の論理ハードウェア割当処理部801が割り当てを行った結果の2通りの物理-論理ハードウェア割当表310を示している。どちらもI/Oアダプタ312は#2で同じだが,使用CPUコア313とメモリ314が異なっている。図12の物理-論理ハードウェア割当表310bの方ではCPUコア#4,5とDIMM#8,9,10,11を割り当てているのに対して,図13の物理-論理ハードウェア割当表310cではCPUコア#6,7とDIMM#0,1,2,3を割り当てている。この2通り以外にもリソースの割り当て方は考えられるが,本質的に変わらない割り当て方は排除する等として,いくつか割り当て方の候補を絞り込む。
【0050】
図10の論理ハードウェア要求I/F350bでは,CPU-メモリ優先のポリシーを要求しているため,CPUソケット110cのCPUコア#4,#5と,CPUソケット110cに接続されるメモリ#8?11を仮想サーバ2へ割り当てて,リソースの距離を0とすることでCPUとメモリの距離が短いものを選択している。一方,図11の論理ハードウェア要求I/F350cでは,I/O-メモリ優先のポリシーを要求しているため,I/Oデバイスとメモリの距離が最も短くなるように,I/Oアダプタ#2に最も近いメモリ#0?#3を選択している。このように,仮想マシンモニタ300の論理ハードウェア割当処理部801は,要求されたポリシーに応じて,仮想サーバに割り当てるハードウェアリソースを最適化することができる。
【0051】
図14は,図12に示した割当表310bに対応して,仮想マシンモニタ300が各リソース間の距離を計算したリソース間距離計算表600bを示している。リソース間距離計算表600bは,仮想サーバの識別子(または連番)を示す仮想サーバの番号#351と,各仮想サーバ番号#351ごとに,仮想サーバ内のリソース間の距離を計算するための表である。カテゴリ601には,リソース割当ポリシーに対応したCPU-メモリ,I/O-メモリ,CPU-I/Oの3種類のカテゴリが存在する。それぞれのカテゴリ601ごとにリソースfrom602からリソースto603までのコンポーネント間距離604を,所属するコンポーネント#と,コンポーネント間距離対応表500に従って仮想マシンモニタ300が計算する。この例では,CPUコア#4,#5とDIMM#8,9,10,11はいずれも同一のコンポーネント110c上に搭載されているので,コンポーネント間距離604は0となる。一方,I/Oアダプタ#2が搭載されたコンポーネント160aと,DIMM#8,9,10,11が搭載されたコンポーネント110cとの距離は,コンポーネント間距離対応表500に従うと2であるため,コンポーネント間距離604は2となる。CPUコア#4,5とI/Oアダプタ#2との間の距離も同様に2となる。最後にカテゴリ601ごとにコンポーネント間距離の総和605を計算する。この例では,CPU-メモリは0,I/O-メモリは2,CPU-I/Oは4,となる。
【0052】
(途中省略)
【0053】
以上のようにしてリソース間距離計算表600を計算したリソース割当候補の中から,リソース割当ポリシーを最も満たす候補を選択する。350bにおける「CPU-メモリ優先」の場合は,コンポーネント間距離の総和605のCPU-メモリの値が小さくなるリソース割当を選ぶ。それに対して「I/O-メモリ優先」の場合は,コンポーネント間距離の総和605のI/O-メモリの値が小さくなるリソース割当を選ぶ。物理-論理ハードウェア割当表310bと310cを比べた場合,「CPU-メモリ優先」の場合は310b,「I/O-メモリ優先」の場合は310cのリソース割当がそれぞれ選択される。」

F 「【図1】



G 「【図5】



H 「【図8】



I 「【図9】



J 「【図64】



ここで,上記引用例1に記載されている事項について検討する。

ア 上記Bの段落【0018】の「マルチプロセッサシステム100は,1つ以上のCPUソケット(プロセッサパッケージ)110,メモリコントローラ130,I/Oハブ160a,160bをモジュール間接続I/F(インターフェース)200にて接続した構成を採る。」との記載,及び「CPUソケット110は1つ以上のCPUコア(プロセッサコア)120を含む。メモリコントローラ130はメモリI/F140を介して1つ以上のDIMM(Dual Inline Memory Module)150と接続する。I/Oハブ160はI/O接続I/F170を介して1つ以上のI/Oアダプタ180a?180fを搭載し,I/Oアダプタ180a?180fの先にはI/Oデバイス190dが接続される。」との記載,及び上記Fで引用した図1の記載から,
“マルチプロセッサシステム100”は,“複数のCPUコア120”と“複数のメモリ150”と“複数のI/Oデバイス190”を含むことが読み取れるから,
引用例1には,
“複数のCPUコア120と複数のメモリ150と複数のI/Oデバイス190とを含むマルチプロセッサシステム100”
が記載されていると認められる。

イ 上記Aの段落【0012】の「前記プロセッサとメモリ及びI/Oデバイスを仮想サーバに割り当てる仮想マシンモニタ」との記載,及び「前記仮想マシンモニタは,・・・前記受け付けた生成要求に基づいてI/Oデバイスを前記仮想サーバに割り当ててから,前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と,を備える」との記載から,
“仮想マシンモニタ”は,“仮想サーバ”に,“I/Oデバイス”,“プロセッサ”,及び“メモリ”を“割り当てる”機能を有するものであることが読み取れ,
また,上記Dの段落【0046】の「図9は,上記論理ハードウェア要求I/F350aと物理-論理ハードウェア(HW)割当表310に基づいて,仮想マシンモニタ300の論理ハードウェア割当処理部801がマルチプロセッサシステム100上に割り当てた仮想サーバ1_370aを示す。図中点線で囲まれた部分は図1のリソースのうち仮想サーバ1_370aに割り当てられたリソースを示す。」との記載から,
“仮想サーバ”は,“マルチプロセッサシステム100上のリソースを割り当てられる”ものであることが読み取れるから,
引用例1には,
“仮想サーバに,I/Oデバイス,プロセッサ,及びメモリ等のマルチプロセッサシステム100上のリソースを割り当てる仮想マシンモニタ300”
が記載されていると認められる。

ウ 上記Cの段落【0027】の「図64は,図1の構成に対応するマルチプロセッサシステム100上で,仮想マシンモニタ300,ゲストOS1 360a,ゲストOS2 360b,ゲストOS3 360cが実行されている様子を示した構成図である。仮想マシンモニタ300のプログラムは,いずれかのI/Oデバイス190上,あるいはサービスプロセッサ200のROM201上に存在し,マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され,仮想マシンCPUコア120のいずれかの上で実行される。」との記載,及び上記Jで引用した図64の記載から,
“仮想マシンモニタ300のプログラム”は,“メモリ150”上へと展開され,“仮想マシンCPUコア120”で実行されることが読み取れ,当該“メモリ150”と“仮想マシンCPUコア120”は,仮想マシンモニタ300のプログラムを実行するための“装置”であるとみることができるから,
引用例1には,
“仮想マシンモニタ300のプログラムを実行するための装置であって,仮想マシンモニタ300のプログラムが展開されるメモリ150と,仮想マシンモニタ300のプログラムを実行する仮想マシンCPUコア120とを備えた装置”
が記載されていると認められる。

エ 上記ア?ウの検討から,引用例1には,
“複数のCPUコア120と複数のメモリ150と複数のI/Oデバイス190とを含むマルチプロセッサシステム100内で,仮想サーバに,I/Oデバイス,プロセッサ,及びメモリ等のマルチプロセッサシステム100上のリソースを割り当てる仮想マシンモニタ300のプログラムを実行するための装置であって,
仮想マシンモニタ300のプログラムが展開されるメモリ150と,
仮想マシンモニタ300のプログラムを実行する仮想マシンCPUコア120とを備えた装置”
が記載されていると認められる。

オ 上記Cの段落【0028】の「図2?図6で仮想マシンモニタ300がサービスプロセッサ220経由で得たマルチプロセッサシステム100の物理ハードウェア構成情報取得I/F320について示す。図2は物理ハードウェア構成情報取得I/F320の内訳を示す。物理ハードウェア構成情報取得I/F320は,物理コンポーネント構成表400,I/Oアダプタ構成表450,コンポーネント間距離対応表500,物理ネットワーク構成表550の4種類の表(テーブル)で構成される。これらのテーブルは,仮想マシンモニタ300が所定の周期または所定のタイミングで,サービスプロセッサ220がモジュール情報取得I/F210を介して収集したハードウェアリソースの情報を問い合わせて生成(または更新)するものである。仮想マシンモニタ300が設定した物理ハードウェア構成情報取得I/F320は,図1に示すI/Oハブ160の物理位置情報格納メモリ165またはメモリ150に格納される。」との記載から,
“仮想マシンモニタ300”は,マルチプロセッサシステム100の“物理ハードウェア構成情報取得I/F320”を取得することが読み取れ,
当該“物理ハードウェア構成情報取得I/F320”は,“物理コンポーネント構成表400,I/Oアダプタ構成表450,コンポーネント間距離対応表500,物理ネットワーク構成表550の4種類のテーブルで構成される”ものであり,これらの“テーブル”は,サービスプロセッサ220がモジュール情報取得I/F210を介して“収集したハードウェアリソースの情報”を問い合わせて生成するものであり,“物理ハードウェア構成情報取得I/F320は,メモリ150に格納される”ことが読み取れるから,
引用例1には,
“仮想マシンモニタ300は,サービスプロセッサ220がモジュール情報取得I/Fを210介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム100の物理ハードウェア構成情報取得I/F320を取得してメモリ150に格納し,ここで,物理ハードウェア構成情報取得I/F320は,物理コンポーネント構成表400,I/Oアダプタ構成表450,コンポーネント間距離対応表500,物理ネットワーク構成表550の4種類のテーブルで構成されるものであ”ること
が記載されていると認められる。

カ 上記Bの段落【0018】の「I/Oハブ160はI/O接続I/F170を介して1つ以上のI/Oアダプタ180a?180fを搭載し,I/Oアダプタ180a?180fの先にはI/Oデバイス190dが接続される。」との記載,上記Cの段落【0030】の「CPUコア120やDIMM150はCPUソケット110というコンポーネントに接続され」との記載,上記Cの段落【0033】の「図5はコンポーネント間距離対応表500の構成を示す。コンポーネント間距離対応表500は,マルチプロセッサシステム100上の全てのコンポーネントに対応するエントリが存在し,・・・このコンポーネントと他のコンポーネントの距離を示す対コンポーネント間距離510から構成される。対コンポーネント間距離510はまた全てのコンポーネント分だけ分けられており,コンポーネント#420のコンポーネントから対コンポーネント間距離510のコンポーネントに到達するまでの距離を示している。」,「本実施形態ではモジュール間接続I/F200の性能は全て等価であると仮定したため,何回モジュール間接続I/F200を渡れば目的のコンポーネントまで辿り着くかという回数を距離としている。この距離を,コンポーネントの物理的な位置情報として扱う。」との記載,上記Cの段落【0034】の「なお,モジュール間接続I/Fが不均一な場合は,後述の物理ネットワーク構成表550にあるレイテンシ570の合計値を使って距離を示す,といった方法が考えられる。」との記載,上記Fで引用した図1の記載,及び上記Gで引用した図5の記載から,
“コンポーネント間距離対応表500”は,“CPUコア120が接続されるCPUソケット110と,I/Oデバイス190が接続されるI/Oハブ160とを含むマルチプロセッサシステム100上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり,モジュール間接続I/F200が不均一な場合は,物理ネットワーク構成表550にあるレイテンシの合計値を使って距離を示すように”することが読み取れる。

キ 上記Cの段落【0037】の「図6は物理ネットワーク構成表550の構成を示している。物理ネットワーク構成表550は,マルチプロセッサシステム100上の全てのモジュール間接続I/F200に対して,モジュール間接続I/F200の接続の通し番号を示すネットワーク#555と,どのコンポーネント420aからどのコンポーネント420bをつないでいるのか,そしてコンポーネント420aと420b間の帯域560とレイテンシ570を示す項目からなる。本実施形態では,CPUソケット110間をつなぐネットワークの帯域560は6なのに対して,CPUソケット110とI/Oハブ160の間をつなぐネットワーク帯域560は半分の3であるとした。なお,帯域560の単位は,例えば[Gbps]であり,レイテンシ570の単位は,例えば,[nsec]である。」との記載から,
“物理ネットワーク構成表550”は,“マルチプロセッサシステム100上の全てのモジュール間接続I/F200の帯域とレイテンシを示す項目からな”ることが読み取れる。

ク 上記カ及びキの検討から,引用例1には,
“コンポーネント間距離対応表500は,CPUコア120が接続されるCPUソケット110と,I/Oデバイス190が接続されるI/Oハブ160とを含むマルチプロセッサシステム100上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり,モジュール間接続I/F200が不均一な場合は,マルチプロセッサシステム100上の全てのモジュール間接続I/F200の帯域とレイテンシを示す項目からなる物理ネットワーク構成表550にあるレイテンシの合計値を使って距離を示すように”すること
が記載されていると認められる。

ケ 上記Eの段落【0048】の「図10と図11は,仮想マシンモニタ300の論理ハードウェア割当処理部801によって上記図9で示したように仮想サーバ1_370aが割り当てられた後で,次の仮想サーバ2に対する論理ハードウェア要求I/F350bおよび350cを示している。論理ハードウェア要求I/F350bと350cは,どちらも同じI/Oアダプタ353,CPUコア数354,メモリ量355を要求している。違いはリソース割当ポリシー356のみで,論理ハードウェア要求I/F350bにおいては「CPU-メモリ優先」となっているのに対して,論理ハードウェア要求I/F350cにおいては「I/O-メモリ優先」となっている。」との記載から,
“仮想サーバに対する論理ハードウェア要求I/F”によって,リソース割当ポリシーを“CPU-メモリ優先”又は“I/O-メモリ優先”のように指定した要求が行われる”ことが読み取れる。

コ 上記Eの段落【0049】の「図12と図13は,仮想サーバ2に対する上記図10,図11の論理ハードウェア要求I/F350に対して,仮想マシンモニタ300の論理ハードウェア割当処理部801が割り当てを行った結果の2通りの物理-論理ハードウェア割当表310を示している。」との記載,及び段落【0051】の「図14は,図12に示した割当表310bに対応して,仮想マシンモニタ300が各リソース間の距離を計算したリソース間距離計算表600bを示している。リソース間距離計算表600bは,仮想サーバの識別子(または連番)を示す仮想サーバの番号#351と,各仮想サーバ番号#351ごとに,仮想サーバ内のリソース間の距離を計算するための表である。カテゴリ601には,リソース割当ポリシーに対応したCPU-メモリ,I/O-メモリ,CPU-I/Oの3種類のカテゴリが存在する。それぞれのカテゴリ601ごとにリソースfrom602からリソースto603までのコンポーネント間距離604を,所属するコンポーネント#と,コンポーネント間距離対応表500に従って仮想マシンモニタ300が計算する。・・・最後にカテゴリ601ごとにコンポーネント間距離の総和605を計算する。」との記載から,
“仮想マシンモニタ300”は,“論理ハードウェア要求I/Fに対して要求を行った結果に対応するよう,リソース割当ポリシーに対応したCPU-メモリ,I/O-メモリ,及びCPU-I/Oの3種類のカテゴリごとにリソースfromからリソースtoまでのコンポーネント間距離を,所属するコンポーネントと,コンポーネント間距離対応表500に従って計算し,さらに,カテゴリごとにコンポーネント間距離の総和を計算して,リソース間距離計算表600を計算”することが読み取れる。

サ 上記Eの段落【0050】の「図10の論理ハードウェア要求I/F350bでは,CPU-メモリ優先のポリシーを要求しているため,CPUソケット110cのCPUコア#4,#5と,CPUソケット110cに接続されるメモリ#8?11を仮想サーバ2へ割り当てて,リソースの距離を0とすることでCPUとメモリの距離が短いものを選択している。一方,図11の論理ハードウェア要求I/F350cでは,I/O-メモリ優先のポリシーを要求しているため,I/Oデバイスとメモリの距離が最も短くなるように,I/Oアダプタ#2に最も近いメモリ#0?#3を選択している。このように,仮想マシンモニタ300の論理ハードウェア割当処理部801は,要求されたポリシーに応じて,仮想サーバに割り当てるハードウェアリソースを最適化することができる。」との記載,上記Eの段落【0053】の「以上のようにしてリソース間距離計算表600を計算したリソース割当候補の中から,リソース割当ポリシーを最も満たす候補を選択する。350bにおける「CPU-メモリ優先」の場合は,コンポーネント間距離の総和605のCPU-メモリの値が小さくなるリソース割当を選ぶ。それに対して「I/O-メモリ優先」の場合は,コンポーネント間距離の総和605のI/O-メモリの値が小さくなるリソース割当を選ぶ。」との記載から,
“リソース間距離計算表600を計算したリソース割当候補の中から,リソース割当ポリシーを最も満たす候補を選択することで,仮想サーバに割り当てるハードウェアリソースを最適化する”ことが読み取れる。

シ 上記Dの段落【0046】の「図9は,上記論理ハードウェア要求I/F350aと物理-論理ハードウェア(HW)割当表310に基づいて,仮想マシンモニタ300の論理ハードウェア割当処理部801がマルチプロセッサシステム100上に割り当てた仮想サーバ1_370aを示す。図中点線で囲まれた部分は図1のリソースのうち仮想サーバ1_370aに割り当てられたリソースを示す。」との記載,上記Fで引用した図1の記載,上記Hで引用した図8の記載,及び上記Iで引用した図9の記載から,
“仮想サーバ1_370aは,CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190cを含み,
CPUコア120(#0,#1)とI/Oデバイス190aとは,モジュール間接続I/F200の#5で接続され,また,CPUコア120(#2,#3)とI/Oデバイス190cとは,モジュール間接続I/F200の#6で接続され”ていることが読み取れる。

上記ア?シの検討から,引用例1には,次のとおりの発明(以下,「引用発明」という。)が記載されていると認められる。

「複数のCPUコア120と複数のメモリ150と複数のI/Oデバイス190とを含むマルチプロセッサシステム100内で,仮想サーバに,I/Oデバイス,プロセッサ,及びメモリ等のマルチプロセッサシステム100上のリソースを割り当てる仮想マシンモニタ300のプログラムを実行するための装置であって,
仮想マシンモニタ300のプログラムが展開されるメモリ150と,
仮想マシンモニタ300のプログラムを実行する仮想マシンCPUコア120とを備え,
仮想マシンモニタ300は,サービスプロセッサ220がモジュール情報取得I/Fを210介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム100の物理ハードウェア構成情報取得I/F320を取得してメモリ150に格納し,
ここで,物理ハードウェア構成情報取得I/F320は,物理コンポーネント構成表400,I/Oアダプタ構成表450,コンポーネント間距離対応表500,物理ネットワーク構成表550の4種類のテーブルで構成されるものであり,
コンポーネント間距離対応表500は,CPUコア120が接続されるCPUソケット110と,I/Oデバイス190が接続されるI/Oハブ160とを含むマルチプロセッサシステム100上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離を含むものであり,モジュール間接続I/F200が不均一な場合は,マルチプロセッサシステム100上の全てのモジュール間接続I/F200の帯域とレイテンシを示す項目からなる物理ネットワーク構成表550にあるレイテンシの合計値を使って距離を示すようにし,
仮想サーバに対する論理ハードウェア要求I/Fによって,リソース割当ポリシーをCPU-メモリ優先又はI/O-メモリ優先のように指定した要求が行われると,
仮想マシンモニタ300は,リソース割当ポリシーに対応したCPU-メモリ,I/O-メモリ,及びCPU-I/Oの3種類のカテゴリごとにリソースfromからリソースtoまでのコンポーネント間距離を,所属するコンポーネントと,コンポーネント間距離対応表500に従って計算し,さらに,カテゴリごとにコンポーネント間距離の総和を計算して,リソース間距離計算表600を計算し,
リソース間距離計算表600を計算したリソース割当候補の中から,リソース割当ポリシーを最も満たす候補を選択することで,仮想サーバに割り当てるハードウェアリソースを最適化するようにし,
仮想サーバ1_370aは,CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190cを含み,
CPUコア120(#0,#1)とI/Oデバイス190aとは,モジュール間接続I/F200の#5で接続され,また,CPUコア120(#2,#3)とI/Oデバイス190cとは,モジュール間接続I/F200の#6で接続される
装置。」

(2)引用例2
原査定の拒絶理由で引用された,本願の優先日前に頒布された刊行物である,特開2009-134687号公報(平成21年6月18日出願公開。以下,「引用例2」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

K 「【0013】
[0034] 図2は,各データセンタ10に収容されることが可能なハードウェアアーキテクチャおよびソフトウェアモジュールの詳細を示す。図2に示されるように,管理LAN 202が,統合管理システム111と,ネットワーク管理サーバ131と,サーバ管理サーバ132と,ストレージ管理サーバ133と,VPN(仮想プライベートネットワーク)ルータ/スイッチ141aと,VLAN(仮想ローカルエリアネットワーク)スイッチ141bと,サーバ142と,SANスイッチ143と,ストレージ144とを接続して,それらによる通信を可能にし,さらに,ルータ21経由のネットワーク12との通信を可能にする。統合管理システム111,ネットワーク管理サーバ131,サーバ管理サーバ132,およびストレージ管理サーバ133は,それぞれが,システムバス212を通して内部接続されているCPU 222,メモリ223,NIC(ネットワークインターフェースカード)221,およびディスクドライブ224を含む汎用コンピュータである。統合管理システム111は,マイグレーション受け入れプログラム121,マイグレーション要求プログラム123,およびリソースマネージャプログラム122を含み,これらは,CPU 222aによる実行に備えて,メモリ223aまたは他のコンピュータ可読媒体にロードされる。連合データセンタテーブル213,受信済みマイグレーション要求テーブル214,および送信済みマイグレーション要求テーブル215が,ディスクストレージ224aに格納され,やはりメモリ223aにロードされることが可能である。統合管理システム111は,ユーザインターフェース211を含み,ユーザインターフェース211は,マイグレーション要求を送信したり,データセンタの管理対象データを管理者などに対して表示したりする機能を実施するために使用される。
【0014】
[0035] ネットワークスイッチ141は,仮想プライベートネットワーク(VPN)203の実現を可能にするVPNルータ141aを含むことが可能である。仮想プライベートネットワークサービスは,インターネットのような共用公衆ネットワークを介して,顧客サイト204とサービスプロバイダのデータセンタ10との間にセキュアなネットワークパスを提供する。各VPNサービス顧客は,VPNと接続されるべき1つまたは複数のサイトを有する。VPNパスの一方のエンドポイントは,顧客のサイトのVPNルータ205であり,VPNパスの他方のエンドポイントは,データセンタ10内にあるVPNルータ141aにある。データセンタ10内のVPNルータ141aは,複数のVPNパスを集約し,VPN IDで顧客を識別し,顧客から受け取ったトラフィックを仮想LAN(VLAN)スイッチ141bに送る。
【0015】
[0036] VPNルータ141aでは,それぞれが異なるVPN顧客を担当する,複数の仮想ルータ(VR)プログラム206を実行することが可能である。たとえば,図2では,顧客サイトA 204aからのVPNパスが,VPNルータ141aの仮想ルータA 206aのところでターミネートされている。同様に,顧客サイトB 204bからのVPNパスが,仮想ルータB 206bに接続されている。各仮想ルータ206が,それぞれのルーティングテーブルと,担当する個々の顧客の専用の他のネットワークリソースを有するため,各VPN顧客からのパケットは,ネットワークの観点では,明確に分離されている。これにより,たとえば,2人の異なる顧客が,プライベートアドレス範囲において,同じオーバーラップIPアドレス空間を使用することが可能になる。仮想ルータA 206aは,これらのパケットに顧客A用のVLANタグを追加し,そのパケットをVLANスイッチ141bへ送る。VLANタグは,3つ以上の論理的に独立したネットワークを同じLANセグメントに重ねることが可能なように,LANフレームに追加される情報である。VLANタグのユーザのより詳細な仕様および説明が,参照により本明細書に組み込まれている,IEEE(Institute of Electrical and Electronics Engineers, Inc.)によって公開されたIEEE 803.1Q規格に定義されている。サービス品質を管理する技術は,たとえば,IETF(Internet Engineering Task Force)によって定義されているMPLS(Multi Protocol Label Switching) DiffServ (Differentiated Services)である。
【0016】
[0037] サーバ142は,1つまたは複数の物理サーバ232と,サービスプロセッサ(SVP)231とを含む。図示された実施形態では,PS-001からPS-008までのラベルが付けられた8つの物理サーバ232があるが,物理サーバ232の数は変更可能である。複数の仮想マシンマネージャ(VMM)233が利用可能であり,本発明の実施形態では,顧客は,これらのうちの1つを選択して,そこで自分のアプリケーションを実行することが可能である。図2では,仮想マシンマネージャVMM-001 233a,VMM-002 233b,およびVMM-003 233cが,利用可能であるとして示されている。仮想マシンマネージャ233が担う役割として,複数の物理サーバを組み合わせて1つの仮想サーバにすることと,1つの物理サーバを複数の仮想サーバに分割することとがある。たとえば,図2では,VMM-001は,PS-001からPS-004までの4つの物理サーバを組み合わせ,これら4つの物理サーバのリソースを2つの仮想サーバ(仮想マシン)VM-101 234aおよびVM-102 234bに分割している。さらに,VMM-002 233bは,物理サーバPS-005,PS-006を組み合わせ,それらにおいて1つの仮想サーバVM-201 234cをアクティブにし,VMM-003 233cは,物理サーバPS-007においてアクティブになっているだけである。一方,物理サーバPS-008は,仮想化が適用されない生の物理サーバである。
【0017】
[0038] 仮想マシンマネージャ233は,それらが制御しているサーバのCPU能力およびメモリを,顧客のニーズに応じて割り当てることが可能である。たとえば,各仮想サーバまたは物理サーバは,特定のVLANに属する。しかしながら,VLANセグメント上のVLANスイッチ141bは,VPNルータ141aからの,VLANタグが付けられたパケットを,VLANセグメントに接続された適切なサーバに転送するように構成されるので,各サーバがどのVLANに属しているかを各サーバが知ることは必要ではない。さらに,各仮想サーバまたは物理サーバは,ストレージエリアネットワーク(SAN),すなわち,SANスイッチ143に接続された1つまたは複数のホストバスアダプタ(HBA)(図示せず)を有する。SANの観点では,各仮想サーバまたは物理サーバは,そのHBAアドレスまたはポートで識別される。図2の構成では,各仮想サーバまたは物理サーバは,SANスイッチ143に接続されている。
【0018】
[0039] ストレージ144は,サーバ142によって使用される複数の論理ストレージボリューム243を提供する,1つまたは複数のストレージシステムを含む。各ボリューム243は,RAID(Redundant Array of Independent Disks)として構成されることが可能なアレイグループ242から切り分けられることが可能である。構成によっては,各アレイグループ242が,異なるタイプのディスクおよび/または異なるレベルのRAIDによって構成され,それによって異なるレベルのパフォーマンスを提供することが可能である。図2では,ボリュームVol-101 243aおよびVol-102 243bがアレイグループ242aから切り分けられ,ボリュームVol-201 243cおよびVol-202 243dがアレイグループ242bから切り分けられ,ボリュームVol-301 243eおよびVol-302 243fがアレイグループ242cから切り分けられている。各アレイグループ242は,ストレージコントローラ241によって制御される。仮想サーバ234,物理サーバ232,およびストレージボリューム243は,ストレージエリアネットワーク(SAN)を介して接続されることが可能である。この接続は,ファイバチャネルであっても,他のタイプの接続であってもよい。図2では,SANスイッチ143により,サーバ232,234,およびボリューム243が,SANとして接続されている。異なる顧客向けのサーバおよびボリュームを互いに隔離するために,特定ストレージボリュームへのアクセスが特定の仮想サーバ234または物理サーバ232に限定されるように,SANスイッチ143および/またはストレージボリューム242を構成することが可能である。SANスイッチの場合,このセキュリティ機能は「ポートゾーニング」と呼ばれる。一方,ストレージ装置の場合,このセキュリティ機能は「LUNセキュリティ」と呼ばれることが多い(「LUN」は,論理装置番号を表す)。パフォーマンスの観点では,同様のアクセスパターンを有するボリュームが同じアレイグループにあることが望ましい。ここでの「アクセスパターン」という言葉は,読み出し/書き込みアクセス比およびランダム/シーケンシャルアクセス比を意味する。」

L 「【0033】
[0061] 図12は,マイグレーション要求プログラム123が別のデータセンタへのマイグレーション要求を開始するために作成および送信するマイグレーション要求文書13を示す。マイグレーション要求文書13は,VPN要求部135,サーバ要求部136,およびストレージ要求部137の3つの部分からなる。VPN要求部135は,「帯域幅」1211を含む,要求されるネットワークについての情報を有する。図12では,「帯域幅」エントリ1211は,1.5Mbpsの帯域幅が要求されることを示す。「要求ID」エントリ1212,1231,および1251は,この特定のマイグレーション要求文書の一意識別子である。「要求ID」は,マイグレーション要求文書13内の各要求部135,136,137をつなぐ役割を果たす。サーバ要求部136は,要求される「仮想マシンマネージャタイプ」1232,「CPUタイプ」1233,および「CPU割り当て」1234についての情報を含む。たとえば,図12は,「仮想マシンマネージャタイプ」1232としてVMM-001が要求され,「CPUタイプ」1233としてCPU-002が要求され,「CPU割り当て」1234として200%(すなわち,「CPU」タイプCPU-002の2つのCPUがVMM-001で動作することに相当する処理能力)が要求されることを示している。実施形態によっては,サーバ要求部136によって,最小メモリ要件(図示せず)が指定されることも可能である。ストレージ要求部137は,マイグレーション用として要求される各論理ボリュームの要件の情報を含む。図12では,ストレージ要求部137は,4つの異なるボリューム,すなわち,システムボリューム,インデックスボリューム,データボリューム,およびログボリュームの要件1261?1264を有する。「ボリューム」1252に対する各要求は,要求される「容量」1253,「アクセス時間」1254,「読み出し/書き込み比」1255,および「ランダム/シーケンシャル比」1256の情報を含むことが可能である。しかしながら,他の実施形態では,これらの要件のいくつかが指定されない場合があり,あるいは,他の要件(RAIDタイプ,ディスクタイプ,ビジーレート,その他)が指定される場合もある。」

M 「【0039】
[0068] ステップ1320で,第2のデータセンタのマイグレーション受け入れプログラム121は,ステップ1314で第1のデータセンタのマイグレーション要求プログラム123から送られたマイグレーション要求文書13を受け取り,リソースマネージャプログラム122を起動して,そのマイグレーション要求を受け入れることが可能かどうかを決定する。
【0040】
[0069] ステップ1322で,リソースマネージャプログラム122は,マイグレーション要求文書13のVPN要求部135を処理し,第2のデータセンタにおいて利用可能なVPN帯域幅容量を要求帯域幅と比較するかたちでチェックし,結果をマイグレーション受け入れプログラム121に返す。VPN容量をチェックするプロセスの詳細については,図14を参照して後述する。
【0041】
[0070] ステップ1324で,リソースマネージャプログラム122は,利用可能なサーバ容量およびパフォーマンスを,要求された容量およびパフォーマンスと比較するかたちでチェックすることによって,マイグレーション要求文書13のサーバ要求部136を処理し,結果をマイグレーション受け入れプログラム121に返す。サーバ容量をチェックするプロセスの詳細については,図15を参照して後述する。
【0042】
[0071] ステップ1326で,リソースマネージャプログラム122は,利用可能なストレージ容量およびパフォーマンスを,要求された容量およびパフォーマンスと比較するかたちでチェックすることによって,マイグレーション要求文書13のストレージ要求部137を処理し,結果をマイグレーション受け入れプログラム121に返す。ストレージ容量をチェックするプロセスの詳細については,図16を参照して後述する。」

N 「【0069】
(途中省略)
[00101] 利用可能なストレージ容量/パフォーマンスをチェックするフローチャート
【0070】
[0102] 図16は,マイグレーション要求文書13のストレージ要求部137に関して利用可能なストレージ容量およびパフォーマンスをチェックする,図13のステップ1326の例示的詳細フローチャートである。
【0071】
[0103] ステップ1601で,リソースマネージャプログラム122は,指定された各ボリュームに対する要求を個別に処理するために,ストレージ要求部137からレコード1261?1264のうちの1つを取り出す。
【0072】
[0104] ステップ1602で,リソースマネージャプログラム122は,そのレコードから各値(すなわち,「容量」1253,「アクセス時間」1254,「読み出し/書き込み比」1255,および「ランダム/シーケンシャル比」1256)を読み込む。
【0073】
[0105] ステップ1603で,リソースマネージャプログラム122は,特定のボリュームについてステップ1602で読み込まれた要求値を満たす,データセンタ内のアレイグループを検索する。ボリュームを切り分けるのに適したアレイグループは,以下の式を用いて見つけることが可能である。
(容量>要求された容量)
かつ
(読み出し/書き込み比*0.9)<要求された読み出し/書き込み比<(読み出し/書き込み比*1.1)
かつ
((ランダム/シーケンシャル比*0.9)<要求されたランダム/シーケンシャル比<(ランダム/シーケンシャル比*1.1))
かつ
(アクセス時間<要求されたアクセス時間)
【0074】
[0106] たとえば,図12の例によれば,システムボリュームレコード1261のストレージ要求は,要求された「容量」として「10GB」,要求された「アクセス時間」1254として「24ms」,要求された「読み出し/書き込み比」として「80%」,および要求された「ランダム/シーケンシャル比」として「10%」を指定する。ストレージボリュームリソーステーブル511でレコードを検索すると,レコード924が,システムボリュームについての要求された要件を満たすことがわかる。前述の式は,許容係数「0.9」および「1.1」を含むが,これらは,ボリューム要求に適合するものを見つけることを容易にするために式に含まれている。たとえば,アプリケーションによっては,読み出し/書き込み比およびランダム/シーケンシャル比は,大まかな範囲に入ってさえいれば,特定の数値であることはさほど重要ではない。これらの許容係数を使用することは,このような柔軟性を可能にする。
【0075】
(途中省略)
【0079】
[0111] ステップ1608で,リソースマネージャプログラム122は,結果をマイグレーション受け入れプログラム121に返す。したがって,本発明の一特徴として,アプリケーションをマイグレーションするかどうかを決定する前に,アプリケーションのストレージパフォーマンスを本質的に保証することが可能であり,特定のアプリケーションのタイプおよび要件に応じて,アプリケーションの様々なパフォーマンス指標または値を指定することが可能である。」

O 「【図2】



(3)参考文献1
本願の優先日前に頒布された刊行物である,特開2011-160300号公報(平成23年8月18日出願公開。以下,「参考文献1」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

P 「【0001】
本発明は,ルータ,ルーティング方法,ルーティングプログラム,情報処理装置,仮想マシン構築方法および仮想マシン構築プログラムに関する。
【背景技術】
【0002】
従来より,インターネットサービスプロバイダ(ISP)に接続するルータの設定情報をネットワークから取得することにより,ルータ購入者によるルータ内のインターネット接続の設定を容易にする技術が知られている。この技術では,ルータがモデムに接続されたとき,ルータはブロードバンドアクセスサーバにアクセスし,RADIUSサーバに認証された後,機器認証サーバにおいて,機器認証される。その後,ルータはISPダウンロードサーバより,ISPサーバに接続する際に使用する設定情報を取得する。ルータは,取得した設定情報を自らに設定し,その設定情報を基に,ISPサーバに接続し,ISPサーバ経由で,インターネット上のWEBページのHTMLなどを取得する。
【0003】
また,従来より,クラウドデータセンタ上の仮想マシンを利用したシステムを,顧客のイントラネットから利用する技術が知られている。このシステムでは,クラウドデータセンタ内の物理サーバが,顧客の業務を実行する仮想マシンを起動し,顧客のイントラネットに接続される端末(例えば,コンピュータ)に顧客の業務に利用可能なサービスを提供している。」

(4)参考文献2
本願の優先日前に頒布された刊行物である,特開2011-258098号公報(平成23年12月22日出願公開。以下,「参考文献2」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

Q 「【0002】
経済のグローバル化と競争激化に伴い,企業は絶え間ない変革を求められている。企業活動を支えるITシステムにおいても,1?2ヵ月程度の超短期間でシステム構築とサービスの提供開始が要求されることも珍しくなくなっており,企業がITシステムを自社(インハウス)で構築して所有し続けるコストが重荷となっている。そこで,近年広帯域化が著しいワイドエリアネットワーク(WAN)を活用したサービスとして,ITシステムをデータセンタの事業者にアウトソースして,企業は必要な期間のみ計算機資源を利用可能なクラウドコンピューティングが台頭している。
【0003】
クラウドコンピューティングが提供するサービスの形態は,提供するITリソースの柔軟度に応じて,IaaS(Infrastructure as a Service),PaaS(Platform as a Service),SaaS(Software as a Service)の3種類のクラウドサービスに大別される。IaaSは電力や設置場所,ネットワークバックボーン等のインフラを貸し出すクラウドサービスであり,PaaSはインフラに加えてIT機器のハードウェアと仮想マシンモニタ(Virtual Machine Monitor=VMM),仮想マシン,OSまでをデータセンタ事業者が準備して,企業に仮想マシン(Virtual Machine)を貸し出すクラウドサービスである。SaaSは更に仮想マシンに加えて業務アプリケーションまでもデータセンタ事業者が準備し,企業は時間貸しで業務アプリケーションを利用するサービス形態となる。
【0004】
グローバルで先行するクラウドベンダは,PaaSやSaaS相当のビジネスを行っている。これらのベンダのサービスは俗にパブリッククラウドと呼ばれ,インターネット経由でサービスが提供される。パブリッククラウドは非常に低価格かつ迅速なサービス提供開始が可能である一方,インターネットでの一時的な通信の混雑や切断が生じるため,エンドtoエンド(クライアントの端末から業務アプリケーション)での安定的なサービス提供が難しいという性質を有する。そのため信頼性に対する不安から,企業の中核的なITシステムに対してはパブリッククラウドの適用が進んでいない。
【0005】
一方,インターネットではなく,キャリアが提供する専用線,IP-VPN,広域イーサネット(登録商標)等の回線サービスを利用するWANサービスは,インターネットに比して信頼性及び通信品質が高く,企業の中核的なITシステムに適している。WANを利用したクラウドサービスとしては,PaaSに相当する仮想マシン単位でのサーバリソースの貸出を行うサービスが知られている(例えば,Harmonious Cloud(http://www.hitachi.co.jp/products/it/harmonious/cloud/solution/paas.html)。WANを用いたPaaSは,パブリッククラウドとは異なり高い信頼性を特長としており安定的なクラウドサービスの提供が可能である。」

(5)参考文献3
本願の優先日前に頒布された刊行物である,「渡邉 利和,-クラウドに最適化される仮想化プラットフォーム- 進化するデータセンターの仮想化 -Part1-1 クラウドに向けた仮想化インフラの進化を着実に進めるVMware,データセンター完全ガイド 2012年冬号,株式会社インプレスビジネスメディア,2011年12月31日,第35号.35,p54?57」(以下,「参考文献3」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

R 「●ストレージの仮想化
ストレージの仮想化が大きく進化した点も,vSphere5の重要なポイントだ。従来“ストレージの仮想化”というと,主にストレージハードウェア側での仮想化技術のことを指しており,ハイパーバイザー側からは従来通りに「明示的に割り当てられた領域にアクセスする」というモデルで利用するだけだった。しかし,vSphere5ではVMに対するストレージ領域の割り当ても仮想化され,運用管理者は論理的な結び付きを管理するだけで済む,新しいインターフェイスが提供された。このベースになっているのは以前から実装済みの”Storage vMotion”の機能だ。Storage vMotionによって,必要に応じてストレージ領域のコピーを別の領域に作り,割り当て変更を行うことはできるようになっていた。vSphere5ではこの機能を活用するための上位機能を拡張し,ストレージのアクセス性能などのポリシーに基づいて,適切なストレージを選択する機能が新たに加わった。これをStorage vMotionと組み合わせる形で実現したのが”Storage DRS”である(図4)。コンピューティングリソースに関しては,DRS(Distributed Resource Scheduler)によって自動的なロードバランシング機能としてすでに実装済みだが,これと同様の機能をストレージに関しても実現したのがStorage DRSとなる。いわば,vMotion/Storage vMotionと同様の拡張がDRSに関しても行われたものだといえるだろう。Storage DRSを実現するに当たって,管理者側ではストレージを従来のような「物理デバイス上に作成された特定の領域」という指定ではなく,ポリシーに基づいた指定を行う。具体的には,1/0性能が高いストレージとか,容量単価の安いストレージ,といった属性が考えられるだろう。個々のストレージ上に確保された領域がどのような属性を持つかをvSphere側で管理し,各VMからのストレージ割り当て要求に対して適切な属性を持つストレージ領域を自動的に割り当てていくというのが,Storage DRSの基本的な考え方となる。このため,vSphere5ではストレージ領域を属性に基づく「ストレージプール」として扱うことができるようになった(図5)。また,ストレージ側がどのような機能/属性を持つかをストレージ側からvSphere5に通知できるような新たなインターフェイスも用意されている。ストレージベンダーが提供する属性情報があれば,管理者はストレージの詳細についてまったく気にすることなく,ストレージが接続されれば,あとは自動的に使い始められる環境が実現できるようになるだろう。これも,クラウド環境でのストレージ割り当て作業を省力化し,運用の効率化を推進するために導入された機能である。」(第55頁左欄3行?右欄11行)

(6)参考文献4
本願の優先日前に頒布された刊行物である,「竹内 博史 他1名,Tech×ASCII.jp特別編集 RAIDの基礎から最新の階層化管理まで ゼロからはじめるストレージ入門,株式会社アスキー・メディアワークス,2010年3月24日,p4」(以下,「参考文献4」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

S 「ストレージアレイ
「ストレージアレイ」は,「ディスクアレイ」とも呼ばれている製品で,おもに企業向けのサーバー(たとえばメールサーバーやデータベースサーバーなど)へ接続されることを想定して設計されている(図5)。ストレージアレイは,HDDを収める筐体(ディスクエンクロージャまたはディスクシェルフと呼ばれている)と,HDDの制御装置(コントローラ)およびサーバーと接続する専用のインターフェイスから構成されている。
なお,ストレージアレイはHDDの搭載数やコントローラの性能の違いなどにより,複数の機種が小規模から大規模環境向けとして販売されており,価格も数十万円から数千万円までとさまざまである。
次のPartでは,HDDの仕組みや種類,および利用形態(JBODやRAID)について解説し,それぞれの特徴や耐障害性なども見てみよう。」(第4頁右欄3?18行)

(7)参考文献5
本願の優先日前に頒布された刊行物である,「挾間 崇 他3名,ストレージ仮想化大全 -Part1 ストレージ仮想化を実現する技術-,システム開発ジャーナル,株式会社毎日コミュニケーションズ,2008年3月29日,第3巻,p70?77」(以下,「参考文献5」という。)には,図面とともに,以下の事項が記載されている。(下線は当審において付したものである。)

T 「第1世代のストレージ仮想化技術
第1世代の仮想化はストレージアレイベースのみで,ストレージアレイ配下の複数の物理ディスクを1つのプールとしてとらえ,そのプールから必要な容量のボリュームを切り出して,サーバに提供します(図1)。この方法は,1つの物理ディスクの容量に左右されることなく,少量のボリュームから大容量のボリュームまでを柔軟に扱うことができます。一般的にはRAIDやLU(論理ユニット)と呼ばれる技術になります。」(第72頁左欄4?12行)

4.対比
本願発明と,引用発明とを比較する。

ア 引用発明の「複数のCPUコア120」は,仮想サーバに割り当てるために“利用可能”な,“マルチプロセッサシステム100上のリソース”であるから,本願発明の「複数の利用可能なリソース」に相当する。
引用発明の「仮想マシンモニタ300」は,「仮想サーバに,I/Oデバイス,プロセッサ,及びメモリ等のマルチプロセッサシステム100上のリソースを割り当てる」ものであるから,引用発明の「仮想サーバ」は,「仮想マシンモニタ300」によってリソースを割り当てられるものである点で,本願発明の「仮想マシン」に相当し,引用発明において,「仮想サーバ」に「マルチプロセッサシステム100上のリソースを割り当てる」ことは,「仮想サーバ(仮想マシン)」を,“マルチプロセッサシステム100内で”“配置する”ことに他ならないから,引用発明の「複数のCPUコア120と複数のメモリ150と複数のI/Oデバイス190とを含むマルチプロセッサシステム100内で,仮想サーバに,I/Oデバイス,プロセッサ,及びメモリ等のマルチプロセッサシステム100上のリソースを割り当てる仮想マシンモニタ300のプログラムを実行するための装置」と本願発明の「複数の利用可能なリソースを含むクラウドネットワーク内で仮想マシンの配置を提供するための装置」とは,後記する点で相違するものの,「複数の利用可能なリソースを含むシステム内で仮想マシンの配置を提供するための装置」である点で共通する。

イ 引用発明の「仮想マシンモニタ300のプログラムが展開されるメモリ150」は,「仮想マシンモニタ300のプログラムを実行するための装置」が備える“ストレージ”とみることができるから,本願発明の「データストレージ」に相当する。

ウ 引用発明の「仮想マシンモニタ300のプログラムを実行する仮想マシンCPUコア120」は,「仮想マシンモニタ300のプログラムが展開されるメモリ150」に“通信可能に結合され”ていることは明らかであるから,「仮想マシンモニタ300のプログラムを実行するための装置」が備える“プロセッサ”であるといえ,本願発明の「データストレージに通信可能に結合されたプロセッサ」に相当する。

エ 引用発明の「仮想マシンモニタ300は,サービスプロセッサ220がモジュール情報取得I/Fを210介して収集したハードウェアリソースの情報から生成したマルチプロセッサシステム100の物理ハードウェア構成情報取得I/F320を取得してメモリ150に格納し」(前者)と本願発明の「複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データをデータストレージに収集し」(後者)とを対比すると,
引用発明において収集される“物理ハードウェア構成情報取得I/F320”は,“コンポーネント間距離対応表500”を含んでおり,当該“コンポーネント間距離対応表500”は,“マルチプロセッサシステム100上の全てのコンポーネントの相互間の距離を示す対コンポーネント間距離”を含むものであり,“対コンポーネント間距離”には,“CPUコア120が接続されるCPUソケット110とI/Oデバイス190が接続されるI/Oハブ160のと間の距離”が含まれていて,この2者間の距離は,実質的には,“CPUコア120とI/Oデバイス190の間の距離”とみることができるところ,
引用発明の「CPUコア120」「メモリ150」が,それぞれ,本願発明の「複数の利用可能なリソース」「データストレージ」に相当し,
また,上記Cで引用した引用例1の段落【0027】の「仮想マシンモニタ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によって実行される。」との記載から,引用発明の「I/Oデバイス190」は,「ストレージ」であると認められるから,引用発明の「複数のI/Oデバイス190」は,「複数のストレージ」である点で,本願発明の「複数のストレージアレイ」と共通しており,
さらに,引用発明の「距離」は,「モジュール間接続I/F200が不均一な場合は,マルチプロセッサシステム100上の全てのモジュール間接続I/F200の帯域とレイテンシを示す項目からなる物理ネットワーク構成表550にあるレイテンシの合計値」を使って示されるものであるから,引用発明の「対コンポーネント間距離」は,本願発明の「通信経路の1つまたは複数のネットワーク性能特性」であるといえるので,引用発明の「対コンポーネント間距離」を含む「コンポーネント間距離対応表500」をさらに含む「物理ハードウェア構成情報取得I/F320」は,本願発明の「1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データ」に相当するといえ,
また,引用発明の「CPUコア120が接続されるCPUソケット110と,I/Oデバイス190が接続されるI/Oハブ160」「の相互間の距離を示す対コンポーネント間距離」と本願発明の「複数のストレージアレイと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性」とは,「複数のストレージと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性」である点で共通するといえる。
そうすると,前者と後者とは,後記する点で相違するものの,
「複数のストレージと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データをデータストレージに収集し」ている点で共通する。

オ 引用発明では,「仮想サーバに対する論理ハードウェア要求I/Fによって,リソース割当ポリシーをCPU-メモリ優先又はI/O-メモリ優先のように指定した要求が行われると」,「仮想マシンモニタ300」は,「論理ハードウェア要求I/Fに対して要求を行った結果に対応するよう,リソース割当ポリシーに対応したCPU-メモリ,I/O-メモリ,及びCPU-I/Oの3種類のカテゴリごとにリソースfromからリソースtoまでのコンポーネント間距離を,所属するコンポーネントと,コンポーネント間距離対応表500に従って計算し,さらに,カテゴリごとにコンポーネント間距離の総和を計算して,リソース間距離計算表600を計算し」,「リソース間距離計算表600を計算したリソース割当候補の中から,リソース割当ポリシーを最も満たす候補を選択することで,仮想サーバに割り当てるハードウェアリソースを最適化するようにし」ていることから,「コンポーネント間距離対応表500」を含む「物理ハードウェア構成情報取得I/F320」(本願発明の「第2のセットのネットワーク性能データ」に相当する。)に“基づいて”,仮想サーバに,リソースを割り当てているということができ,
上記アにおける検討も踏まえると,
引用発明と本願発明とは,後記する点で相違するものの,「第2のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定する」点で共通する。

カ 上記ウの検討から,引用発明の仮想マシンモニタが実行する上記エの“収集する”動作,及び上記オの“決定する”動作が,「仮想マシンモニタ300のプログラムを実行するための装置」が備える“プロセッサ”によって実行されていることは明らかであるから,上記ウ?オの検討を総合すると,引用発明と本願発明とは,後記する点で相違するものの,
「プロセッサは,
複数のストレージと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データをデータストレージに収集し,
第2のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定するように構成され」
ている点で共通している。

キ 引用発明の「仮想サーバ1_370a」は,「CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190c」を含んでいるところ,仮想サーバが「CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190c」を含んでいることは,上記アの検討を踏まえれば,仮想マシンが「CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190c」を含んでいることに他ならないから,
引用発明と本願発明とは,後記する点で相違するものの,
「仮想マシンは,1つまたは複数のストレージの少なくとも1つと複数の利用可能なリソースの少なくとも1つを含」む点で一致する。

ク 引用発明の「仮想サーバ1_370a」は,「CPUコア120(#0,#1,#2,#3)と,メモリ150(#4,#5,#6,#7)とI/Oデバイス190a,190c」を含み,「CPUコア120(#0,#1)とI/Oデバイス190aとは,モジュール間接続I/F200の#5で接続され,また,CPUコア120(#2,#3)とI/Oデバイス190cとは,モジュール間接続I/F200の#6で接続される」ものであるところ,
引用発明の「CPUコア120(#0,#1)」が本願発明の「第1の利用可能なリソース」に相当し,以下同様に,引用発明の「モジュール間接続I/F200の#5」が本願発明の「第1の経路」に,引用発明の「CPUコア120(#2,#3)」が本願発明の「第2の利用可能なリソース」に,引用発明の「モジュール間接続I/F200の#6」が本願発明の「第2の経路」にそれぞれ相当し,
また,上記エの検討から,引用発明の「I/Oデバイス190」は,「ストレージ」である点で,本願発明の「ストレージアレイ」と共通していることから,引用発明の「I/Oデバイス190a」,「I/Oデバイス190c」が本願発明の「第1のストレージアレイ」,「第2のストレージアレイ」に対応するので,
引用発明と本願発明とは,後記する点で相違するものの,
「複数の通信経路は,第1のストレージと第1の利用可能なリソースの間の第1の経路と,第2のストレージと第2の利用可能なリソースの間の第2の経路を含」む点で共通している。

ケ 上記クの検討から,引用発明の「CPUコア120(#0,#1)」が本願発明の「第1の利用可能なリソース」に相当し,引用発明の「CPUコア120(#2,#3)」が本願発明の「第2の利用可能なリソース」に相当するから,
引用発明と本願発明とは,
「第1の利用可能なリソースと第2の利用可能なリソースは異なって」いる点で一致する。

コ 上記クの検討を踏まえると,
引用発明と本願発明とは,後記する点で相違するものの,
「1つまたは複数のストレージは,第1のストレージと第2のストレージを含み,複数の利用可能なリソースは,第1の利用可能なリソースと第2の利用可能なリソースを含む」点で共通している。

以上の検討から,本願発明と引用発明とは,

「複数の利用可能なリソースを含むシステム内で仮想マシンの配置を提供するための装置であって,
データストレージと,
データストレージに通信可能に結合されたプロセッサとを備え,プロセッサは,
複数のストレージと複数の利用可能なリソースの間の複数の通信経路の1つまたは複数のネットワーク性能特性を示す第2のセットのネットワーク性能データをデータストレージに収集し,
第2のセットのネットワーク性能データに基づいてシステム内の仮想マシンの配置場所を決定するように構成され,
仮想マシンは,1つまたは複数のストレージの少なくとも1つと複数の利用可能なリソースの少なくとも1つを含み,
複数の通信経路は,第1のストレージと第1の利用可能なリソースの間の第1の経路と,第2のストレージと第2の利用可能なリソースの間の第2の経路を含み,
第1の利用可能なリソースと第2の利用可能なリソースは異なっており,
1つまたは複数のストレージは,第1のストレージと第2のストレージを含み,複数の利用可能なリソースは,第1の利用可能なリソースと第2の利用可能なリソースを含む,装置。」

の点で一致し,以下の点で相違する。

[相違点1]
仮想マシンが配置されるシステムが,
本願発明では,「クラウドネットワーク」であるのに対して,引用発明では,マルチプロセッサシステム100内である点。

[相違点2]
本願発明では,「クラウドネットワーク内の1つまたは複数のストレージの性能特性を示す第1のセットのストレージ性能データをデータストレージに収集し」,「第1のセットのストレージ性能データ」および第2のセットのネットワーク性能データに基づいて仮想マシンの配置場所を決定するように構成されているのに対して,引用発明では,そのような構成になっていない点。

[相違点3]
本願発明のストレージが,「ストレージアレイ」であるのに対して,引用発明のI/Oデバイスは,ストレージアレイではない点。

5.判断
上記各相違点について,検討する。

[相違点1]について
クラウドネットワーク上で,仮想マシンを配置することは,例えば引用例2(上記K及びOの記載を参照。),参考文献1(上記Pの記載を参照。),又は参考文献2(上記Qの記載を参照。)に記載されているように,本願の優先日前に,当該技術分野における周知技術であったと認められるから,引用発明のハードウェアリソースをクラウドネットワークのリソースとすることで,仮想マシンをクラウドネットワーク上で配置するように構成すること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

[相違点2]について
引用例2(上記L,M,及びNの記載を参照。)や参考文献3(上記Rの記載を参照。)には,ストレージの性能を考慮して仮想マシンを割り当てる技術が記載されており,特に引用例2(上記L及びMの記載を参照。)には,ネットワークの性能とストレージの性能の両方を考慮して仮想マシンを割り当てることも記載されていることから,上記[相違点1]の判断も踏まえると,引用発明において,ネットワークの性能に加えて,クラウドネットワーク内のストレージの性能も考慮して仮想マシンを配置するように構成することは,当業者が容易に想到し得たことである。

[相違点3]について
ストレージとして,複数の物理ディスクから構成されたストレージアレイを用いることは,例えば,参考文献4(上記Sの記載を参照),参考文献5(上記Tの記載を参照)等に記載されているように,本願の優先日前に当該技術分野において広く知られた周知技術であるものと認められることから,上記[相違点1]の判断も踏まえると,引用発明のストレージをストレージアレイとすること,すなわち,上記相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

そして,上記各相違点を総合的に勘案しても,本願発明の奏する作用効果は,引用発明,引用例2に記載の技術,参考文献3に記載の技術,及び引用例2,参考文献1,2,4,5に記載の周知技術から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本願発明は,引用発明,引用例2に記載の技術,参考文献3に記載の技術,及び引用例2,参考文献1,2,4,5に記載の周知技術に基づいて,当業者が容易に発明をすることができたものである。

6.むすび
以上のとおり,本願発明は,引用発明,引用例2に記載の技術,参考文献3に記載の技術,及び引用例2,参考文献1,2,4,5に記載の周知技術に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,本願は拒絶されるべきものである。

よって,結論のとおり審決する。
 
審理終結日 2018-03-28 
結審通知日 2018-04-03 
審決日 2018-04-20 
出願番号 特願2014-553293(P2014-553293)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 大桃 由紀雄金沢 史明大塚 俊範  
特許庁審判長 仲間 晃
特許庁審判官 須田 勝巳
辻本 泰隆
発明の名称 ネットワークおよびストレージアウェア仮想マシン配置のための方法および装置  
代理人 特許業務法人川口國際特許事務所  

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