【事件の表示】
　特願２０１２−５０６６８４「仮想マシン管理装置，開発システム，仮想マシン管理方法，及びプログラム」拒絶査定不服審判事件〔平成２３年　９月２９日国際公開，ＷＯ２０１１／１１７９５６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
　
１．手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２２年３月２０日を国際出願日とする出願であって，平成２４年６月４日付けで特許法第１８４条の５第１項の規定による書面が提出され，同年６月６日付けで審査請求がなされ，平成２５年６月１３日付けで拒絶理由通知（同年６月２１日発送）がなされ，これに対して同年８月１９日付けで意見書が提出されると共に同日付けで手続補正がなされたが，同年９月２５日付けで拒絶査定（同年１０月３日謄本送達）がなされた。　
　これに対して，「原査定を取り消す，本願は特許をすべきものであるとの審決を求める」との請求の趣旨で，平成２５年１２月３日付けで審判請求がなされたものである。　
　
　
２．本願発明
　
　本願の請求項１に記載された発明（以下，「本願発明」という。）は，上記平成２５年８月１９日付け手続補正書により補正された特許請求の範囲及び明細書の記載からみて，その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「開発対象のコンピュータシステムを構成する仮想マシンの各開発段階における構成情報を，設定する構成情報設定部と，
　前記構成情報設定部により設定された各開発段階の構成情報に基づいて，同一のIaaSで提供される仮想化システム内で，互いに異なる開発段階のコンピュータシステムの仮想マシンを稼働させるシステム制御部と
　を有する仮想マシン管理装置。」
　
　
３．引用文献
　
（１）引用文献１に記載されている技術的事項および引用発明
　
　本願出願前に頒布され，原審の拒絶査定の理由である上記平成２５年６月１３日付けの拒絶理由通知において引用された，人見  尊志，「“仮想化時代”に求められる企業システムのライフサイクル管理」，ＩＴアーキテクト，日本，（株）ＩＤＧジャパン，２００８年８月６日，第18巻，ｐ．80−89（以下，「引用文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「サーバ仮想化の意義
　
サーバ仮想化の意義は，ハードウェア層とそれより上位のＯＳを含むミドルウェア層，およびビジネス・アプリケーション層の間の依存関係を弱め（図１），”変化に強い”システム・アーキテクチャを達成することにある。
　
Ｂ　「
テスト環境と仮想化技術
　サーバ仮想化の最大の利点は，しつこいようだがリソースの有効活用にある。
仮想化によって，開発環境や機能テスト環境，インフラ運用テスト環境，受け入れテスト環境といった複数の環境を統合できることに加え，プロジェクトの各局面に応じて仮想サーバに割り振るリソースを調整すれば，大規模なハードウェアが必要なテストの実行も可能になる（次ページの図６）。
　
Ｃ　
図６には，サーバ仮想化によるリソースの有効活用のイメージ例として，開発重視の仮想マシン，検証重視の仮想マシン，リリース直前の検証中の仮想マシンなど複数の仮想マシンが示されている。
　
Ｄ　「
また，仮想化のメリットは複数の開発環境を構築する際にも発揮される。
　
これに対し，仮想環境上では標準の開発環境を１つ作り，それをテンプレート化することで，複数の環境をクローニング（複製）によって作成できるのだ。これにより，環境全体を１つの「バージョン」としてとらえ，開発のある局面での環境，機能テストの環境，本番環境適用前のステージング環境，パッチ適用のための環境といった具合に管理することも可能となる。これは，物理サーバに依存しない仮想化技術の大きなメリットの１つだと言えよう。
　
　ここで，上記引用文献１に記載されている事項を検討する。　
　
（ア）上記Ａの「サーバ仮想化の意義は，ハードウェア層とそれより上位のＯＳを含むミドルウェア層，およびビジネス・アプリケーション層の間の依存関係を弱め（図１），”変化に強い”システム・アーキテクチャを達成することにある。」との記載，上記Ｂの「テスト環境と仮想化技術…（中略）…プロジェクトの各局面に応じて仮想サーバに割り振るリソースを調整すれば，大規模なハードウェアが必要なテストの実行も可能になる（次ページの図６）。」との記載からすると，サーバ仮想化技術を用いてテストを実行する手段が読み取れることから，引用文献１には，
「サーバ仮想化によるテスト実行手段」
が記載されていると解される。
　
（イ）上記Ｂの「仮想化によって，開発環境や機能テスト環境，インフラ運用テスト環境，受け入れテスト環境といった複数の環境を統合できることに加え，プロジェクトの各局面に応じて仮想サーバに割り振るリソースを調整すれば，大規模なハードウェアが必要なテストの実行も可能になる（次ページの図６）。」との記載からすると，開発環境や機能テスト環境，インフラ運用テスト環境，受け入れテスト環境などはプロジェクトの各局面での環境であると解され，サーバ仮想化によって，プロジェクトの各局面に応じて仮想サーバに割り振るリソースを調整することから，プロジェクトの各局面での環境に基づき，プロジェクトの各局面に応じて仮想サーバに割り振るリソースを調整して実行する機能が読み取れる。
　また，上記Ｃの記載からすると，仮想サーバは，プロジェクトの各局面に対応して実行する仮想マシンを意味していると解されるから，引用文献１には，
「プロジェクトの各局面での環境に基づき，前記プロジェクトの各局面に対応した仮想マシンに割り振るリソースを調整して実行する機能」
が記載されていると解される。
　
（ウ）上記Ｄの「また，仮想化のメリットは複数の開発環境を構築する際にも発揮される。…（中略）…これに対し，仮想環境上では標準の開発環境を１つ作り，それをテンプレート化することで，複数の環境をクローニング（複製）によって作成できるのだ。これにより，環境全体を１つの「バージョン」としてとらえ，開発のある局面での環境，機能テストの環境，本番環境適用前のステージング環境，パッチ適用のための環境といった具合に管理することも可能となる。これは，物理サーバに依存しない仮想化技術の大きなメリットの１つだと言えよう。」との記載からすると，開発のある局面での環境，機能テストの環境，本番環境適用前のステージング環境，パッチ適用のための環境はプロジェクトの局面毎の環境であることが読み取れ，また，上記Ｃの記載からすると，各仮想マシンについて環境が管理されると解されるから，引用文献１には，
「各仮想マシンについてプロジェクトの局面毎の環境を管理する機能」
が記載されていると解される。
　
　以上，（ア）乃至（ウ）で指摘した事項から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「各仮想マシンについてプロジェクトの局面毎の環境を管理する機能と，
　前記プロジェクトの各局面での環境に基づき，前記プロジェクトの各局面に対応した前記仮想マシンに割り振るリソースを調整して実行する機能と
を有するサーバ仮想化によるテスト実行手段。」　
　
　
（２）引用文献２に記載されている技術的事項
　
　本願出願前に頒布され，原審の拒絶査定の理由である上記平成２５年６月１３日付けの拒絶理由通知において引用された，　特開２００９−２６５７７８号公報（平成２１年１１月１２日出願公開，以下，「引用文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｅ　「【０００８】
　図１に，本発明を実施した仮想化サーバのシステム構成図を示す。
　
仮想化サーバは，複数のサーバ１をＬＡＮなどのネットワークＮ１に並列に接続して１台の仮想的なサーバに見立てるクラスタを形成し，このネットワークＮ１に負荷分散装置としてのロードバランサ２と各サーバ１のリソースを束ねて管理する管理サーバ３を付加する
　クラスタを形成する目的は構成要素を冗長化して耐障害性を高め，複数のサーバ１で異なるリクエストを同時並行処理してサーバ１の負荷を分散させるためである。」
　
Ｆ　「【００１１】
　
サーバ１には，図２に示すように，公知の仮想マシンモニタ５を搭載して１台に複数の仮想マシン６を構築し，それぞれの仮想マシン６上でゲストＯＳ７を稼動させる。
　仮想マシンモニタ５は，サーバ１が持つＣＰＵ，メモリ，周辺機器（Ｉ／Ｏ）などのハードウエア８を仮想的なリソースに分割して独立にプールし，ゲストＯＳ７に対して必要なリソースを必要なとき必要なだけ動的に割り当てる。
　リソースは，物理的な単位以下に分割が可能なため，リソースサイズの変更が容易で，高い集約効果が得られる。
　ゲストＯＳ７は，１台のサーバ１上で同時並列稼動され，異種ＯＳ，複数バージョンのＯＳが混在可能である。」
　
Ｇ　「【００１３】
　
管理サーバ３は，図３に示すように，ＩＰアドレス管理部３１，負荷計測部３２，資源割り当て部３３，ＶＭテンプレート管理部３４，ＶＭ再配置部３５，ＶＬＡＮ管理部３６，ＶＭグループ管理部３７で構成し，ＩＰアドレス管理部３１，資源割り当て部３３，ＶＭグループ管理部３７にはＩＰアドレス，資源割り当てルール，ＶＭグループＩＤなどの管理情報を格納したデータベースＤ１〜Ｄ３を備える。
【００１４】
　
ＩＰアドレス管理部３１は，どのサーバ１上にどの仮想マシン６が稼働しているか，実サーバと仮想サーバのマッピング状況を把握するために，クラスタを形成する各サーバ１のＩＰアドレスと，各サーバ１に割り当てた仮想マシン６の対応を管理する。
　
　
４．参考文献
　
　本願出願前に頒布された刊行物である，周藤  安造，外４名，「クラウド・コンピューティングによる電子紹介状を中心とする広域連携医療システムの開発構想」，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会，２０１０年１月２１日，第109巻，第407号(MI2009-98)，ｐ．121−126（以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。また，段落３．１において，丸付き数字が使用されているが，「（数字）」に置き換えることとした。）
　
Ｈ　「３．　クラウドモデルの導入
３．１　
クラウドコンピューティングとは
　
クラウドコンピューティングでは，ユーザはインターネットを介し，ハードウェアやソフトウェアの性能やストレージ管理，データベース・ソフト，ユーザインタフェース，セキュリティ管理，バックアップ対策システムなど標準のサービスが利用できる．さらに，独自にカスタマイズや，アプリケーションが開発でき，システムの導入や運用にかかるコストの削減や，開発期間の短縮などが可能とされている．これまでのネットワークシステムとの大きな違いは，ネットワーク上に存在するサーバや他のリソースが提供するサービスを，それらのサーバ群やリソースを意識することなしに利用できる点である．このようなクラウドの主なメリットは以下のようになる［１５］．
　（１）ユーザは自前の設備を持つ必要は無く，データセンターにて提供される各種サービスに対し，従量課金制にて対価を払えばよく，データセンターの設備やサービスを低コストで利用できる．
　（２）ユーザがクラウドにデータを送ると，独自にソフトを開発することなく，クラウド内でデータの加工や分析が一元的に行われる．結果システム稼動までの期間が短縮され，コスト削減も図れる．
　（３）法令対応など急な変更が発生しても契約変更だけで済み，個々にユーザが対応する必要は無い．
　
３．２　クラウドの分類［１６］と提供サービス　
　クラウドにはパブリッククラウド，プライベートクラウドおよびこれらを組み合わせたハイブリッドクラウドがある．まず，
パブリッククラウドはクラウド・プロバイダーが提供する環境を利用することになり，利用に応じた課金となるため，インターネットを介して利用が容易である．
　以上の分類とは別に，問題解決型クラウドとも言うべき区分も有り，たとえば膨大な売り上げデータを分析するための「分析クラウド」や，企業向けとしての「エンタープライズ・クラウド」などが考えられる．
　
一方，クラウドで提供されるサービスには，ソフトウェア（ＳａａＳ），プラットホーム（ＰａａＳ），インフラストラクチャー（ＩａａＳ）がある。これらはクラウド・プロバイダーが提供するサービス群で，組合せ構成はユーザが選択できる［１５］，［１６］．
　
３．３　連携医療形態とクラウド
　これまで我々が考えてきた広域連携医療の構成を，クラウドに移行すると，Ｆｉｇ．４のようになる．すなわち，中核医療機関あるいは大規模総合病院内での院内システム連携があり，それが病診連携へと発展し，さらに在宅医療連携まで展開される．システム全体概念をＦｉｇ．４で示す広域連携医療クラウドとして捉え，連携のハイアラキーを構成する．
各連携システムの構築とネットワークなどはＳａａＳ，ＰａａＳ，ＩａａＳによるＩＴサービスにより実現される
　
４．　クラウドによる連携医療へのシステム展開
４．１　サービス提供の形態
　
Ｆｉｇ．５は情報システムの構築・運用に必要な何らかの資源（ハードウェア，回線，ソフトウェア実行環境，アプリケーションソフト，開発環境など）をインターネットを通じ，サービスとして遠隔から利用できるようにしたクラウドの上位概念としての広域連携医療ＸａａＰＳクラウドである．
　
Ｊ　Ｆｉｇ．５には，Ｉ（Ｈ）ａａＳを含む広域連携医療ＸａａＰＳクラウドの模式図が示されている。　
　
　
５．対比
　
　本願発明と引用発明とを対比する。
　
（１）引用発明の「サーバ仮想化によるテスト実行手段」は各仮想マシンの環境を管理し，割り振るリソースを調整するところ，仮想マシンとは別の装置であるか否か不明であるものの，全体として仮想マシンを管理していると言えることから，引用発明の「サーバ仮想化によるテスト実行手段」と，本願発明の「仮想マシン管理装置」とは，“仮想マシン管理手段”である点で共通していると言える。
　
（２）引用発明の「プロジェクトの局面」は，機能テストやインフラ運用テストなどを含むことから，本願発明の「開発段階」に相当し，引用発明の「プロジェクトの局面毎の環境」は，開発環境や機能テスト環境，インフラ運用テスト環境，受け入れテスト環境など，仮想マシンが対応する局面毎に割り振られるリソースを特定するための情報であると言えることから，引用発明の「プロジェクトの局面毎の環境」は，本願発明の「各開発段階における構成情報」に相当すると言える。
　また，引用発明は「プロジェクトの局面毎の環境を管理する」ところ，「プロジェクトの局面毎の環境」に基づいて「プロジェクトの各局面に対応した前記仮想マシンに割り振るリソースを調整して実行する」ことから，「プロジェクトの局面毎の環境」を設定，保持していることは明らかである。
　そうすると，引用発明の「各仮想マシンについてプロジェクトの局面毎の環境を管理する機能」と，本願発明の「開発対象のコンピュータシステムを構成する仮想マシンの各開発段階における構成情報を，設定する構成情報設定部」とは，後記する点で相違するものの，“仮想マシンの各開発段階における構成情報を設定する構成情報設定部”である点で共通していると言える。　
　
（３）引用発明では，「プロジェクトの各局面に対応した前記仮想マシンに割り振るリソースを調整して実行する」ところ，プロジェクトの互いに異なる局面に対応した仮想マシンを実行しているとみることができ，上記（２）での検討のとおり，引用発明の「プロジェクトの各局面」は本願発明の「各開発段階」に相当することから，引用発明の「前記プロジェクトの各局面に対応した前記仮想マシンに割り振るリソースを調整して実行する機能」と本願発明の「互いに異なる開発段階のコンピュータシステムの仮想マシンを稼働させるシステム制御部」とは，“互いに異なる開発段階の仮想マシンを稼働させる制御部”である点で共通していると言える。
　また，上記（２）での検討のとおり，引用発明の「プロジェクトの各局面での環境」は本願発明の「各開発段階の構成情報」に相当し，引用発明の「仮想マシン」は仮想化システム内のコンピュータシステムの仮想マシンであることは明らかである。
　そうすると，引用発明の「前記プロジェクトの各局面での環境に基づき，前記プロジェクトの各局面に対応した前記仮想マシンに割り振るリソースを調整して実行する機能」と，本願発明の「前記構成情報設定部により設定された各開発段階の構成情報に基づいて，同一のIaaSで提供される仮想化システム内で，互いに異なる開発段階のコンピュータシステムの仮想マシンを稼働させるシステム制御部」とは，後記する点で相違するものの，“前記構成情報設定部により設定された各開発段階の構成情報に基づいて，仮想化システム内で，互いに異なる開発段階のコンピュータシステムの仮想マシンを稼働させる制御部”である点で共通しているといえる。　
　
　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
（一致点） 
　
「仮想マシンの各開発段階における構成情報を設定する構成情報設定部と，
　前記構成情報設定部により設定された各開発段階の構成情報に基づいて，仮想化システム内で，互いに異なる開発段階のコンピュータシステムの仮想マシンを稼働させる制御部と　
　を有する仮想マシン管理手段。」
　
（相違点１）　
　
　仮想マシン管理手段に関し，本願発明は，仮想マシンを管理する手段が「仮想マシン管理装置」であるのに対して，引用発明は，仮想マシンを管理する手段が「サーバ仮想化によるテスト実行手段」であって，装置であるか不明な点。
　
（相違点２）　
　
　仮想マシンに関し，本願発明は，「開発対象のコンピュータシステムを構成する仮想マシン」であるのに対して，引用発明では，「仮想マシン」が開発対象のコンピュータシステムを構成するか言及がない点。
　
（相違点３）　
　
　仮想マシンが稼働する仮想化システムの種別に関し，本願発明は，「同一のIaaSで提供される仮想化システム内で」，仮想マシンを稼働させるのに対して，引用発明では，サーバ仮想化による仮想化システムであって，同一のIaaSで提供される仮想化システム内で仮想マシンを稼働させることについては言及がない点。
　
　
６．当審の判断
　
　上記相違点１乃至３について検討する。
　
（１）相違点１について
　
　引用発明では，「サーバ仮想化によるテスト実行手段」が「仮想マシン」の環境を管理し，割り振るリソースを調整して実行するところ，「テスト実行手段」を「仮想マシン」が稼働する「サーバ」に設置するか，「サーバ」とは異なる装置として構成するかは，本願出願前の技術水準からみて，当業者であれば必要に応じて適宜に選択し得た設計的事項であった。
　例えば，引用文献２（上記Ｅ，Ｇ参照）に記載されるように，管理サーバなどの装置により，異なるサーバ上で稼働する仮想マシンを管理することは，本願出願前には当該技術分野の周知技術であった。
　してみると，引用発明において上記の周知技術を適用し，適宜，テスト実行手段を仮想マシンが稼働するサーバとは異なる装置として構成すること，すなわち，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点１は格別なものではない。　
　
（２）相違点２について
　
　引用発明の「仮想マシン」は，機能テストやインフラ運用テストなどの「プロジェクトの各局面」に対応して実行されるところ，同じ計算機に本番環境空間とテスト環境空間など異なる環境空間を構築し，本番用の業務プログラムの稼働とテストの並行運用を行う旨の技術は，例えば，特開平８−２３５０１１号公報（段落【００１１】〜【００１７】を参照）に記載されるように本願出願前には周知技術であった。すなわち，開発対象の計算機において，本番用の業務プログラムの稼働とテストの並行運用を行うことは，本願出願前には当該技術分野において普通に行われていた技術であった。
　そうすると，引用発明において上記の周知技術を適用し，適宜，プロジェクトの各局面に対応する仮想マシンを開発対象のコンピュータシステムで実行すること，すなわち，相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点２は格別なものではない。　
　
（２）相違点３について
　
　引用発明では，サーバ仮想化による仮想化システム内で「仮想マシン」を稼働するところ，複数のサーバにより構成される同一の仮想化システム内で，複数のサーバ上で複数の仮想マシンを稼働させる旨の技術は，例えば，引用文献２（上記Ｅ，Ｆ，Ｇ参照）に記載されるように本願出願前には周知技術であった。
　また，サーバ群やリソースを意識することなしに利用可能な仮想化システムを提供するサービスとして，クラウドで提供されるインフラストラクチャー（ＩａａＳ）は，例えば，参考文献１（上記Ｈ参照）に記載されるように，本願出願前には当業者に広く知られたサービスであった。すなわち，ＩａａＳは複数のサーバ上で複数の仮想マシンを稼働させることにより仮想化システムを提供するサービスとして本願出願前には周知であった。
　してみると，引用発明において上記周知技術を適用し，適宜，仮想マシンを稼働する仮想化システムを同一のＩａａＳとして，サーバ群やリソースを意識することなしに複数のサーバ上で複数の仮想マシンを稼働させること，すなわち，相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　
　よって，相違点３は格別なものではない。　
　
（４）小括
　
　上記で検討したごとく，相違点１乃至３は格別のものではなく，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，上記引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　
７．むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。