ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F |
|---|---|
| 管理番号 | 1259025 |
| 審判番号 | 不服2009-23971 |
| 総通号数 | 152 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2012-08-31 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2009-12-04 |
| 確定日 | 2012-06-20 |
| 事件の表示 | 特願2006-526436「バーチャルマシーンの動作の復帰に対する割込又は実行のベクトル処理」拒絶査定不服審判事件〔平成17年 3月31日国際公開、WO2005/029327、平成19年 3月15日国内公表、特表2007-506162〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1.手続の経緯 本願は、 2004年9月15日(パリ条約による優先権主張外国庁受理2003年9月15日、アメリカ合衆国)を国際出願日とする出願であって、 平成18年3月14日付けで特許法第184条の5第1項に規定される書面が提出されるとともに、国際出願日における明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の翻訳文が提出され、 平成21年1月23日付けで最初の拒絶理由通知(同年同月27日発送)がなされ、 同年4月27日付けで意見書が提出されるとともに、手続補正がなされ、 同年7月27日付けで拒絶査定(同年8月4日発送)がなされ、 同年12月4日付けで審判請求がなされるとともに、手続補正がなされ、 平成22年2月23日付けで審査官より同法第164条第3項で規定する報告(前置報告)がなされ、 平成23年1月18日付けで当審より審尋(同年同月25日発送)がなされ、 同年4月22日付けで回答書が提出され、 同年9月14日付けで当審より最初の拒絶理由通知(同年同月20日発送)がなされ、 同年12月20日付けで意見書が提出されるとともに、手続補正がなされたものである。 第2.本願発明の認定 本願の請求項1に係る発明(以下、「本願発明」という。)は、平成23年12月20日付けの手続補正により補正された、本願の特許請求の範囲の請求項1に記載された次のものと認められる。 「バーチャルマシーンモニタ(VMM)からバーチャルマシーン(VM)に制御を移行する要求を受け付けるステップと、 前記VMMが前記VMへの第1フォルトの送信を要求したか判断するステップと、 前記VMMが前記VMへの前記第1フォルトの送信を要求していた場合、前記VMへの制御の移行の際に前記VMに前記第1フォルトを送信するステップと、 前記VMMが前記VMへの前記第1フォルトの送信を要求していなかった場合、前記VMに前記第1フォルトを送信することなく前記VMに制御を移行するステップと、 前記VMへの第1フォルトの送信がさらなるフォルトを生じさせる場合、前記第1フォルトの送信失敗から生じた前記さらなるフォルトが前記VMに送信されるべきか判断するステップと、 から構成されることを特徴とする方法。」 第3.先行技術文献に記載されている技術的事項と先行技術文献に記載されている発明の認定 1.引用例1に記載されている技術的事項 当審が平成23年9月14日付け拒絶理由通知において引用した特開昭61-184643号公報(昭和61年8月18日出願公開。以下、「引用例1」という。)には、図面とともに以下の技術的事項が記載されている。 (1の1) 「本実施例は、ハードウェア上において、VMに起動をかける理由がVMへの割込みであるか否かの情報によりそれぞれに対して適切な処理を実行するというものである。 まず、前述の仮想計算機システムの処理実行の高速化の必要性に答えるためには、(i)VMへ起動をかける理由が割込みであるか否かを識別すること、(ii)割込みであった場合、スタックにVM情報を退避し、対象VMの割込みハンドラーへ制御を移すこと、などをハードウェア上で行う必要がある。 上記(i)を具体化するためにハードレジスタを用意する。このハードレジスタの例を第2図に示す。…(中略)…このハードレジスタ20上に、VMへ起動をかける理由が割込みであるか否かを示すフラグ(割込み識別子)21を設定する(任意の1ビットを使用する)。 このフラグ21の値は、VMを起動する前にVMCP1-1がセットする。…(中略)… 上記(ii)を具体化した場合のVM起動処理(割込み識別フラグ判定、制御移動処理等)についての計算機ハードウェアの動作フローチャートを第3図に示す。 以下、第3図の処理フローチャートを説明する。 VMCP1-1での処理終了後、該当VM起動に当って、まず割込み識別フラグ21に識別子のセットを行う。そして、VM起動をハードウェアに掲示する(VM起動命令を実行する)。 VM起動命令では、まずハードレジスタ20上の割込み識別フラグ21を参照し(ステップ100)、“0”がセットされているならば、VM起動の理由は割込み以外であるから、現在スタックにつまれているPC(プログラムカウンタ)、SR(ステータスレジスタ)を回復する(ステップ101)。これによってVM上の次の命令へ制御が移る。一方、識別フラグ21が“1”である場合は、VM起動の理由は割込みであるから、VM上の割込みハンドラーへ制御が移るように退避してあるスタック内容を回復し(ステップ102)、再度VM上のPC,SRを割込みベクタ番号と共にスタックへ退避する(ステップ103)。このPC,SRは、割込みハンドラー実行後に制御が移るVM上の次の命令アドレス等の情報である。そして、対象VMの割込みハンドラーへ制御を移すためのSRの値を作成し、ロードベクタテーブルよりPCをロードする(ステップ104)。これに従って制御は割込ハンドラーへ移る。」 (第3頁左下欄第13行目?第4頁右上欄第3行目) (1の2) 「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。 第1図において、1-1は仮想計算機制御プログラム(VMCP)、2-1?2-nは仮想計算機(VM)、5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)、6はSRやPCの値を退避するスタックである。VMCP1-1にはシミュレーションプログラム1-1-2,VM起動命令1-1-4が入っている。ここで、斜線をひいた部分(VMの起動制御機能5-1)が上記で述べた(第2図、第3図参照)本発明の部分である。また、ここにはスタックの退避/回復についても記入してある。以下でこれについて簡単に説明する。 VM(2-1?2-n)から何らかの要求が発生したときには、ハードウェア上で実現されているVMサポート機能5を経由してVMCP1-1へ制御が移る。そして、このVMCP1-1での処理が終了した時、又は割込みを受けた時に、VMCP1-1は割込みか否かの識別をハードレジスタ20にセットすると共に、VMサポート機能5内に設けたVMの起動制御機能5-1により起動制御を行い、割込みならば割込みハンドラーへ、それ以外ならばVMの次の命令へと制御を移す。」 (第4頁右上欄第4行目?同頁左下欄第7行目) (1の3) 「また、本実施例では、割込みか否かを識別するフラグをハードレジスタ20を用いて設定しているが、これはソフトウェアで行うこともできる。ソフトウェアで行う例として、例えば各VMCB(Viｒｔｕal Machine Cｏnｔｒｏl Blｏck)の中に設定してもよい。」 (第4頁左下欄第10行目?同頁同欄第15行目) 2.引用発明の認定 上記(1の2)に「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。…(中略)…5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)…(中略)…である。」と記載されていることから明らかなように、引用例1における「VMサポート機能5」及び「VMの起動制御機能5-1」はハードウェアである。 上記(1の1)に「VM起動処理(割込み識別フラグ判定、制御移動処理等)についての計算機ハードウェアの動作フローチャートを第3図に示す。…(中略)…VMCP1-1での処理終了後、該当VM起動に当って…(中略)…VM起動をハードウェアに掲示する(VM起動命令を実行する)。」と記載され、上記(1の2)に「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。…(中略)…1-1は仮想計算機制御プログラム(VMCP)、2-1?2-nは仮想計算機(VM)、5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)…(中略)…である。VMCP1-1には…(中略)…VM起動命令1-1-4が入っている。…(中略)…このVMCP1-1での処理が終了した時、又は割込みを受けた時に、…(中略)…VMCP1-1は…(中略)…VMサポート機能5内に設けたVMの起動制御機能5-1により起動制御を行い、割込みならば割込みハンドラーへ、それ以外ならばVMの次の命令へと制御を移す。」と記載されていることから明らかなように、引用例1においては、仮想計算機制御プログラムVMCPから仮想計算機VMに制御を移行する要求であるVM起動命令を、ハードウェアであるVMの起動制御機能5-1が受け付けるステップがある。 上記(1の1)に「VM起動処理(割込み識別フラグ判定、制御移動処理等)についての計算機ハードウェアの動作フローチャートを第3図に示す。…(中略)…VMCP1-1での処理終了後、該当VM起動に当って、まず割込み識別フラグ21に識別子のセットを行う。そして、VM起動をハードウェアに掲示する(VM起動命令を実行する)。…(改行)…VM起動命令では、まずハードレジスタ20上の割込み識別フラグ21を参照し(ステップ100)、“0”がセットされているならば、VM起動の理由は割込み以外であるから、…(中略)…一方、識別フラグ21が“1”である場合は、VM起動の理由は割込みであるから…(後略)…」と記載され、上記(1の2)に「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。…(中略)…1-1は仮想計算機制御プログラム(VMCP)、2-1?2-nは仮想計算機(VM)、5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)…(中略)…である。VMCP1-1には…(中略)…VM起動命令1-1-4が入っている。ここで、斜線をひいた部分(VMの起動制御機能5-1)が上記で述べた(第2図、第3図参照)本発明の部分である。…(中略)…このVMCP1-1での処理が終了した時、又は割込みを受けた時に、VMCP1-1は割込みか否かの識別をハードレジスタ20にセットすると共に、VMサポート機能5内に設けたVMの起動制御機能5-1により起動制御を行い、割込みならば割込みハンドラーへ、それ以外ならばVMの次の命令へと制御を移す。」と記載されていることから、引用例1においては、仮想計算機制御プログラムVMCPが設定したフラグに基づいて、仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込であるかを、ハードウェアであるVMの起動制御機能5-1が判断するものである。 また、上記(1の3)に「本実施例では、割込みか否かを識別するフラグをハードレジスタ20を用いて設定しているが、これはソフトウェアで行うこともできる。ソフトウェアで行う例として、例えば各VMCB(Viｒｔｕal Machine Cｏnｔｒｏl Blｏck)の中に設定してもよい。」と記載されていることから、引用例1には、仮想計算機制御プログラムVMCPが設定するフラグをViｒｔｕal Machine Cｏnｔｒｏl Blｏck(VMCB)内のものとすることが示されている。 よって、引用例1においては、仮想計算機制御プログラムVMCPがViｒｔｕal Machine Cｏnｔｒｏl Blｏck(VMCB)内に設定したフラグに基づいて、仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込であるかを、ハードウェアであるVMの起動制御機能5-1が判断するステップがある。 上記(1の1)に「VM起動処理(割込み識別フラグ判定、制御移動処理等)についての計算機ハードウェアの動作フローチャートを第3図に示す。…(中略)…VMCP1-1での処理終了後、該当VM起動に当って、まず割込み識別フラグ21に識別子のセットを行う。そして、VM起動をハードウェアに掲示する(VM起動命令を実行する)。…(改行)…VM起動命令では、まずハードレジスタ20上の割込み識別フラグ21を参照し(ステップ100)、…(中略)…識別フラグ21が“1”である場合は、VM起動の理由は割込みであるから、VM上の割込みハンドラーへ制御が移るように…(中略)…これに従って制御は割込ハンドラーへ移る。」と記載され、上記(1の2)に「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。…(中略)…1-1は仮想計算機制御プログラム(VMCP)、2-1?2-nは仮想計算機(VM)、5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)…(中略)…である。VMCP1-1には…(中略)…VM起動命令1-1-4が入っている。ここで、斜線をひいた部分(VMの起動制御機能5-1)が上記で述べた(第2図、第3図参照)本発明の部分である。…(中略)…このVMCP1-1での処理が終了した時、又は割込みを受けた時に、VMCP1-1は割込みか否かの識別をハードレジスタ20にセットすると共に、VMサポート機能5内に設けたVMの起動制御機能5-1により起動制御を行い、割込みならば割込みハンドラーへ…(中略)…と制御を移す。」と記載されていることから明らかなように、引用例1においては、仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込である場合、仮想計算機VMへの制御の移行の際にVMの割込ハンドラーに制御を移すことを、ハードウェアであるVMの起動制御機能5-1が行うステップがある。 上記(1の1)に「VM起動処理(割込み識別フラグ判定、制御移動処理等)についての計算機ハードウェアの動作フローチャートを第3図に示す。…(中略)…VMCP1-1での処理終了後、該当VM起動に当って、まず割込み識別フラグ21に識別子のセットを行う。そして、VM起動をハードウェアに掲示する(VM起動命令を実行する)。…(改行)…VM起動命令では、まずハードレジスタ20上の割込み識別フラグ21を参照し(ステップ100)、“0”がセットされているならば、VM起動の理由は割込み以外であるから、…(中略)…これによってVM上の次の命令へ制御が移る。」と記載され、上記(1の2)に「第1図は、本発明の一実施例を示す仮想計算機システムの処理概要図である。…(中略)…1-1は仮想計算機制御プログラム(VMCP)、2-1?2-nは仮想計算機(VM)、5はVMサポート機能(ハードウェア)、5-1は本発明の主要部をなすVMの起動制御機能(ハードウェア)…(中略)…である。VMCP1-1には…(中略)…VM起動命令1-1-4が入っている。ここで、斜線をひいた部分(VMの起動制御機能5-1)が上記で述べた(第2図、第3図参照)本発明の部分である。…(中略)…このVMCP1-1での処理が終了した時、又は割込みを受けた時に、VMCP1-1は割込みか否かの識別をハードレジスタ20にセットすると共に、VMサポート機能5内に設けたVMの起動制御機能5-1により起動制御を行い、割込みならば…(中略)…それ以外ならばVMの次の命令へと制御を移す。」と記載されていることから明らかなように、引用例1においては、仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込でない場合、仮想計算機VMへの制御の移行の際にVM上の次の命令に制御を移すことを、ハードウェアであるVMの起動制御機能5-1が行うステップがある。 上記引用例1の記載事項及び図面を総合勘案すると、引用例1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。 「ハードウェアであるVMサポート機能及びVMの起動制御機能により実行される方法であって、 仮想計算機制御プログラムVMCPから仮想計算機VMに制御を移行する要求であるVM起動命令を受け付けるステップと、 仮想計算機制御プログラムVMCPがViｒｔｕal Machine Cｏnｔｒｏl Blｏck(VMCB)内に設定したフラグに基づいて、仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込であるか判断するステップと、 仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込である場合、仮想計算機VMへの制御の移行の際にVMの割込ハンドラーに制御を移すステップと、 仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込でない場合、仮想計算機VMへの制御の移行の際にVM上の次の命令に制御を移すステップと から構成されることを特徴とする方法。」 3.引用例2に記載されている技術的事項 当審が平成23年9月14日付け拒絶理由通知において引用した国際公開第02/052404号(2002年7月4日国際公開。以下、「引用例2」という。)には、図面とともに以下の技術的事項が記載されている。仮訳は当審が訳出したものである。 (2の1) 「A conventional virtual-machine monitor (VMM) typically runs on a computer and presents to other software the abstraction of one or more virtual machines. Each virtual machine may function as a self-contained platform, running its own "guest operating system" (i.e., an operating system hosted by the VMM). The guest operating system expects to operate as if it were running on a dedicated computer rather than a virtual machine. That is, the guest operating system expects to control various computer operations and have access to hardware resources during these operations. The hardware resources may include processor-resident resources (e.g., control registers) and resources that reside in memory (e.g., descriptor tables). 」 (明細書第1頁第10行目?同頁第19行目。 仮訳:従来の仮想計算機モニタ(VMM)は典型的には一つのコンピュータ上で動作し、VMMは他のソフトウェアに1つまたは複数の仮想計算機のアブストラクションを提供する。それぞれの仮想計算機は、自前のプラットホームであるかのように動作し、それ自身の”ゲストオペレーティングシステム”を動作させる。(つまりは、このゲートオペレーティングシステムは、VMMにホストされたオペレーティングシステムである。)ゲストオペレーティングシステムは、仮想計算機上というよりも専用に割り当てられた計算機上で動作しているかのように、動作することを期待する。つまり、様々なコンピュータオペレーションを制御し、これらのオペレーションを通じてハードウェア資源へアクセスすることを、ゲストオペレーティングシステムは期待する。ここでのハードウェア資源には、プロセッサに存在する資源(例えば、コントロールレジスタ)やメモリ内に存在する資源(例えば、ディスクリプタテーブル)が含まれうる。) (2の2) 「The method and apparatus of the present invention provide processor support for a virtual-machine monitor (VMM). FIG. 1 illustrates one embodiment of a virtual-machine environment 100, in which the present invention may operate. In this embodiment, bare platform hardware 116 comprises a computing platform, which may be capable, for example, of executing a standard operating system (OS) or a virtual-machine monitor (VMM), such as a VMM 112. A VMM, though typically implemented in software, may export a bare machine interface, such as an emulation, to higher level software. Such higher level software may comprise a standard or real-time OS, although the invention is not limited in scope in this respect and, alternatively, for example, a VMM may be run within, or on top of, another VMM. VMMs and their typical features and functionality are well-known by those skilled in the art and may be implemented, for example, in software, firmware or by a combination of various techniques. As described above, a VMM presents to other software (i.e., "guest" software) the abstraction of one or more virtual machines (VMs). FIG. 1 shows two VMs, 102 and 114. The guest software of each VM includes a guest OS such as a guest OS 104 or 106 and various guest software applications 108-110. Each of the guest OSs 104 and 106 expects to control access to physical resources (e.g., processor registers, memory and memory-mapped I/O devices) within the hardware platform on which the guest OS 104 or 106 is running and to perform other functions. 」 (明細書第6頁第20行目?第7頁第18行目。 仮訳:本発明の方法及び装置は、仮想計算機モニタ(VMM)のためのプロセッササポートを提供する。図1は、仮想計算機環境100の一具体例を示したものである。この具体例では、ベアプラットホームハードウェア116はコンピューティングプラットホームを含む。このコンピューティングプラットホームは、例えば、標準的なオペレーティングスシステム(OS)か、VMM112のような仮想計算機モニタ(VMM)を実行しうる。VMMは典型的にはソフトウェアにより実装されているものの、VMMはベアマシンインターフェースを、より高レベルのソフトウェアにエミュレーションの如くエクスポートする。ここでの、より高レベルのソフトウェアには、標準OSやリアルタイムOSが含まれうるが、本発明はそのようなものに限定されるものではない。加えて、例えば、あるVMMが別のVMMの中または上で動作しうる。VMMやVMMの典型的な特徴やVMMの機能は当業者にはよく知られており、ソフトウェア、ファームウェアに実装されるか、様々な技術の結合により実装されうる。 既に述べたように、VMMは他のソフトウェア(例えば、”ゲスト”ソフトウェア)に1つまたは複数の仮想計算機(VM)のアブストラクションを提供する。図1は、2つのVM102と114を示す。それぞれのVMのゲストソフトウェアには、ゲストOS104または106のようなゲストOSと、様々なゲストソフトウェアアプリケーション108-110が含まれる。ゲストOS104、106が動作しているハードウェアプラットホーム内の物理的資源(例えば、プロセッサレジスタ、メモリ、メモリマップドI/Oデバイス)へのアクセスを制御することやその他のファンクションを行うことを、それぞれのゲストOS104、106は期待する。) (2の3) 「Referring to FIG. 3, all guest software runs at a processor mode referred to herein as a virtual 32-bit mode (V32 mode).」 (明細書第10頁第17行目?同頁第18行目。 仮訳:図3を参照すると、全てのゲストソフトウェアは、ここではバーチャル32ビットモード(V32モード)と呼ばれるプロセッサモードにおいて動作する。) (2の4) 「The VMM 320 runs outside V32 mode. When a transition out of V32 mode occurs, the VMM 320 receives control over the operation initiated by the guest OS 308 or guest application 306.」 (明細書第11頁第3行目?同頁第5行目。 仮訳:VMM320はV32モードの外で動作する。V32モードの外へ出る遷移が発生する時、ゲストOS308かゲストアプリケーション306が生じさせたオペレーションに対する制御権を、VMM320は受け取る。) (2の5) 「In one embodiment, certain exceptions and interrupts cause a transition out of V32 mode. These exceptions and interrupts include "virtualization traps."」 (明細書第11頁第19行目?同頁第20行目。 仮訳:一具体例では、ある例外やインタラプトは、V32モードの外に出る遷移を引き起こす。これらの例外やインタラプトは”バーチャリゼーショントラップ”を含む。) (2の6) 「In one embodiment, when guest software runs in V32 mode, software interrupts (e.g., interrupts caused by execution of BOUND, INT or INTO instructions) are handled by the guest OS 308 using the guest IDT (i.e., the IDT residing in the guest address space 304). All other interrupts and exceptions including virtualization traps cause a transition out of V32 mode which results in a change of the guest address space 304 to the VMM address space 302. The IDT 316 is then used to point to code that handles a corresponding exception or interrupt. 」 (明細書第12頁第9行目?同頁第16行目。 仮訳:一具体例において、ゲストソフトウェアがV32モードにおいて動作している時、ソフトウェアインタラプト(例えば、BOUND、INT、INTO命令の実行により引き起こされたインタラプト)は、ゲストOS308により取り扱われる。ゲストOS308は、ゲストIDT(例えば、ゲストアドレス空間304に存在するIDT)を使う。バーチャリゼーショントラップを含む、その他の全てのインタラプトと例外は、V32モードの外に出る遷移を引き起こす。V32モードの外に出る遷移の結果として、ゲストアドレス空間304からVMMアドレス空間302への変化が起こる。そして、対応する例外やインタラプトを取り扱うコードを指し示すために、IDT316は用いられる。) (2の7) 「At processing block 406, an attempt of the guest software to perform an operation restricted by V32 mode is identified. In response to this attempt, V32 mode is exited to transfer control over the operation initiated by the guest software to the VMM which runs outside V32 mode (processor block 408). In one embodiment, the VMM configures what operations should cause a transition out of V32 mode as will be described in greater detail below in conjunction with FIG. 7. In one embodiment, such operations generate virtualization traps that cause a transition out of V32 mode. 」 (明細書第14頁第20行目?第15頁第4行目。 仮訳:プロセッシングブロック406では、ゲストソフトウェアがV32モードにおいて制限されるオペレーションを行おうとする試みが特定される。この試みに応じて、V32モードはイグジットされて、ゲストソフトウェアが発したオペレーションに対する制御はVMMに移る(プロセッシングブロック408)。このVMMはV32モードの外部にて動作するものである。一具体例では、VMMはどのオペレーションがV32モードの外に出る遷移を引き起こすべきであるかを設定する。その設定については、後で図7に関連付けてもっと詳細を述べるとおりである。一具体例では、そのようなオペレーションはバーチャリゼーショントラップを生成し、バーチャリゼーショントラップはV32モードの外に出る遷移を引き起こす。) (2の8) 「In addition, virtualization traps may be caused by attempts to execute CPUID instructions to allow the VMM to present the abstraction of processor features chosen by the VMM,…(以下略)…」 (明細書第17頁第12行目?同頁第14行目。 仮訳:加えて、バーチャリゼーショントラップはCPUID命令の実行を試みることによって引き起こされうる。それにより、VMMが選んだプロセッサの特性のアブストラクションを、VMMが提示することを可能にする。) (2の9) 「FIG. 7 is a flow diagram of a method 700 for maintaining a redirection map, according to one embodiment of the present invention. According to this embodiment, the VMM maintains a redirection map to configure which interrupts and exceptions should result in a virtualization trap (processing block 704). At processing block 706, an occurrence of an interrupt or exception is identified. The redirection map is then consulted to find a bit associated with this interrupt or exception in the redirection bitmap (processing block 708). At decision box 710, a determination is made as to whether this interrupt is allowed to be handled by the guest OS. If the determination is positive, the interrupt or exception is delivered to V32 mode and is handled by the guest OS (processing block 714). Alternatively, a virtualization trap is generated, causing a transition out of V32 mode (processing block 712). 」 (明細書第17頁第18行目?第18頁第7行目。 仮訳:図7は本発明の一具体例に基づくリダイレクションマップを維持するための方法700の流れ図である。この具体例によれば、VMMはリダイレクションマップを維持する(プロセッシングブロック704)。リダイレクションマップはどのインタラプトや例外がバーチャリゼーショントラップという結果になるべきかを設定するためのものである。プロセッシングブロック706において、一つのインタラプトまたは例外が発生したことが特定される。そして、リダイレクションマップが調べられる(プロセッシングブロック708)。この調査は、リダイレクションマップのなかの、このインタラプトまたは例外に対応するビットを探すためのものである。 決定ボックス710において、このインタラプトがゲストOSによって取り扱われてもよいかについて決定がなされる。その決定が肯定的であるならば、インタラプトまたは例外はV32モードに向けて送信され、インタラプトまたは例外はゲストOSにより取り扱われる(プロセッシングボックス714)。そうでなければ、バーチャリゼーショントラップが生成され、V32モードの外に出る遷移が引き起こされる(プロセッシングブロック712)。) 4.引用例2に記載されている発明の認定 上記(2の2)に「本発明の方法及び装置は、仮想計算機モニタ(VMM)のためのプロセッササポートを提供する。」と記載されていることから明らかなように、引用例2は、仮想計算機モニタVMMのためのプロセッササポートを提供する方法に関するものである。 上記(2の9)に「プロセッシングブロック706において、一つのインタラプトまたは例外が発生したことが特定される。」と記載されていることから、引用例2においては、インタラプトまたは例外を受け付けるステップが存在する。 そして当該記載の後に、上記(2の9)には「そして、リダイレクションマップが調べられる(プロセッシングブロック708)。この調査は、リダイレクションマップのなかの、このインタラプトまたは例外に対応するビットを探すためのものである。…(改行)…決定ボックス710において、このインタラプトがゲストOSによって取り扱われてもよいかについて決定がなされる。その決定が肯定的であるならば、…(中略)…そうでなければ、バーチャリゼーショントラップが生成され、V32モードの外に出る遷移が引き起こされる(プロセッシングブロック712)。」と記載されていることから、上記したインタラプトまたは例外を受け付けるステップは、V32モードにおいて発生するものである。 このV32モードについて、上記(2の3)に「全てのゲストソフトウェアは、ここではバーチャル32ビットモード(V32モード)と呼ばれるプロセッサモードにおいて動作する。」と記載され、上記(2の4)に「VMM320はV32モードの外で動作する。」と記載されている。また、ゲストソフトウェアについて、上記(2の2)に「VMMは他のソフトウェア(例えば、”ゲスト”ソフトウェア)に1つまたは複数の仮想計算機(VM)のアブストラクションを提供する。…(中略)…それぞれのVMのゲストソフトウェアには、ゲストOS104または106のようなゲストOSと、様々なゲストソフトウェアアプリケーション108-110が含まれる。」と記載されている。これらの記載から、V32モードとは、(仮想計算機モニタVMMとは異なる)ゲストOSが仮想計算機VM上で実行されていることを意味するものであることは明らかである。 つまり、引用例2においては、ゲストOSが仮想計算機VM上で実行されている間に、インタラプトまたは例外を受け付けるステップが存在する。 上記(2の9)において「プロセッシングブロック706において、一つのインタラプトまたは例外が発生したことが特定される。」という記載の後に、「そして、リダイレクションマップが調べられる(プロセッシングブロック708)。この調査は、リダイレクションマップのなかの、このインタラプトまたは例外に対応するビットを探すためのものである。…(改行)…決定ボックス710において、このインタラプトがゲストOSによって取り扱われてもよいかについて決定がなされる。その決定が肯定的であるならば、インタラプトまたは例外はV32モードに向けて送信され、インタラプトまたは例外はゲストOSにより取り扱われる(プロセッシングボックス714)。そうでなければ、バーチャリゼーショントラップが生成され、V32モードの外に出る遷移が引き起こされる(プロセッシングブロック712)。」と記載されている。また、リダイレクションマップについて、上記(2の9)に「リダイレクションマップはどのインタラプトや例外がバーチャリゼーショントラップという結果になるべきかを設定するためのものである。」と記載され、上記(2の7)に「VMMはどのオペレーションがV32モードの外に出る遷移を引き起こすべきであるかを設定する。」と記載されている。これらの記載から明らかなように、引用例2には、リダイレクションマップにおける、受け付けたインタラプトまたは例外に対応するビットの値に基づき、インタラプトまたは例外をゲストOSが動作しているV32モードに送信するべきか、それとも、V32モードの外に出る遷移をするべきかを判断するステップが存在する。 そして、既に示したとおり、V32モードとは、(仮想計算機モニタVMMとは異なる)ゲストOSが仮想計算機VM上で実行されていることを意味するものであることは明らかである。 また、上記(2の4)に「VMM320はV32モードの外で動作する。V32モードの外へ出る遷移が発生する時、ゲストOS308…(中略)…が生じさせたオペレーションに対する制御権を、VMM320は受け取る。」と記載されていることから明らかなように、V32モードの外に出る遷移をすることは、ゲストOSから仮想計算機モニタVMMに制御を移行することを意味するものである。 つまり、引用例2においては、リダイレクションマップにおける、受け付けたインタラプトまたは例外に対応するビットの値に基づき、インタラプトまたは例外を仮想計算機VMに送信するべきか、それとも、ゲストOSから仮想計算機モニタVMMに制御を移行すべきかを判断するステップが存在する。 上記引用例2の記載事項及び図面を総合勘案すると、引用例2には、次の発明(以下、「引用例2に記載された発明」という。)が記載されていると認められる。 「仮想計算機モニタVMMのためのプロセッササポートを提供する方法であって、 ゲストOSが仮想計算機VM上で実行されている間に、インタラプトまたは例外を受け付けるステップと、 リダイレクションマップにおける、受け付けたインタラプトまたは例外に対応するビットの値に基づき、インタラプトまたは例外を仮想計算機VMに送信するべきか、それとも、ゲストOSから仮想計算機モニタVMMに制御を移行すべきかを判断するステップと、 から構成されることを特徴とする方法。」 第4.対比 本願発明と引用発明とを比較する。 引用発明における「仮想計算機制御プログラムVMCP」は本願発明における「バーチャルマシーンモニタ(VMM)」に相当する。 引用発明における「仮想計算機VM」は本願発明における「バーチャルマシーン(VM)」に相当する。 引用発明における「割込」は、フォルトの一種であるので、本願発明における「第1フォルト」に相当する。 引用発明における「仮想計算機制御プログラムVMCPから仮想計算機VMに制御を移行する要求であるVM起動命令を受け付けるステップ」は、本願発明における「バーチャルマシーンモニタ(VMM)からバーチャルマシーン(VM)に制御を移行する要求を受け付けるステップ」に相当する。 引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込であるか判断する」ことは、仮想計算機VMが起動するときに割込ハンドラーを実行するか否かを判断することを意味するものであり、結局は仮想計算機VMに対して割込を送信するか否かを判断することであるから、本願発明における「前記VMMが前記VMへの第1フォルトの送信を要求したか判断する」ことに相当する。よって、引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込であるか判断するステップ」は、本願発明における「前記VMMが前記VMへの第1フォルトの送信を要求したか判断するステップ」に相当する。 同様の理由で、引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込である場合」は、本願発明における「前記VMMが前記VMへの第1フォルトの送信を要求していた場合」に相当する。同様の理由で、引用発明における「仮想計算機VMへの制御の移行の際にVMの割込ハンドラーに制御を移す」ことは、本願発明における「前記VMへの制御の移行の際に前記VMに前記第1フォルトを送信する」ことに相当する。よって、引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込である場合、仮想計算機VMへの制御の移行の際にVMの割込ハンドラーに制御を移すステップ」は、本願発明における「前記VMMが前記VMへの前記第1フォルトの送信を要求していた場合、前記VMへの制御の移行の際に前記VMに前記第1フォルトを送信するステップ」に相当する。 同様の理由で、引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込でない場合」は、本願発明における「前記VMMが前記VMへの前記第1フォルトの送信を要求していなかった場合」に相当する。同様の理由で、引用発明における「仮想計算機VMへの制御の移行の際にVM上の次の命令に制御を移す」ことは、本願発明における「前記VMに前記第1フォルトを送信することなく前記VMに制御を移行する」ことに相当する。よって、引用発明における「仮想計算機制御プログラムVMCPが仮想計算機VMを起動する理由が割込でない場合、仮想計算機VMへの制御の移行の際にVM上の次の命令に制御を移すステップ」は、本願発明における「前記VMMが前記VMへの前記第1フォルトの送信を要求していなかった場合、前記VMに前記第1フォルトを送信することなく前記VMに制御を移行するステップ」に相当する。 すると、本願発明と引用発明は、次の点で一致する。 ＜一致点＞ バーチャルマシーンモニタ(VMM)からバーチャルマシーン(VM)に制御を移行する要求を受け付けるステップと、 前記VMMが前記VMへの第1フォルトの送信を要求したか判断するステップと、 前記VMMが前記VMへの前記第1フォルトの送信を要求していた場合、前記VMへの制御の移行の際に前記VMに前記第1フォルトを送信するステップと、 前記VMMが前記VMへの前記第1フォルトの送信を要求していなかった場合、前記VMに前記第1フォルトを送信することなく前記VMに制御を移行するステップと から構成されることを特徴とする方法。 一方で、両者は、次の点で相違する。 ＜相違点＞ 本願発明においては「前記VMへの第1フォルトの送信がさらなるフォルトを生じさせる場合、前記第1フォルトの送信失敗から生じた前記さらなるフォルトが前記VMに送信されるべきか判断するステップ」があるのに対して、引用発明にはそのようなステップはない点。 第5.判断 上記した相違点について検討する。 既に示したように引用例2に記載された発明は以下のとおりのものである。 「仮想計算機モニタVMMのためのプロセッササポートを提供する方法であって、 ゲストOSが仮想計算機VM上で実行されている間に、インタラプトまたは例外を受け付けるステップと、 リダイレクションマップにおける、受け付けたインタラプトまたは例外に対応するビットの値に基づき、インタラプトまたは例外を仮想計算機VMに送信するべきか、それとも、ゲストOSから仮想計算機モニタVMMに制御を移行すべきかを判断するステップと、 から構成されることを特徴とする方法。」 引用発明と引用例2に記載された発明はともに、仮想計算機環境においてフォルト(割込(インタラプト)や例外等)を取り扱うことに関するものである。また、仮想計算機VM上で各種プログラムが実行される際に、各種フォルトが発生する可能性があることは当業者であれば充分認識していることである。 そのため、引用発明における、仮想計算機VM上の割込ハンドラーを実行する際に発生するさらなる各種フォルトの取り扱いについて、引用例2に記載された発明を適用して、引用発明においても、仮想計算機VMへの割込の送信がさらなるフォルトを生じさせる場合、前記割込の送信失敗から生じた前記さらなるフォルトが仮想計算機VMに送信されるべきか判断するステップを備えるようにすることに、特段の困難性はない。 よって、上記相違点は格別のものではない。 また、本願の請求項1に係る発明が有する作用効果は、引用発明及び引用例2に記載されている発明から当業者が予測できた範囲内のものである。 よって、本願の請求項1に係る発明は、引用発明及び引用例2に記載されている発明に基いて、当業者が容易に発明をすることができたものである。 第6.むすび したがって、本願の請求項1に係る発明は、その優先日前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-01-18 |
| 結審通知日 | 2012-01-24 |
| 審決日 | 2012-02-06 |
| 出願番号 | 特願2006-526436(P2006-526436) |
| 審決分類 |
P
1
8・
121-
WZ
(G06F)
P 1 8・ 537- WZ (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 多胡 滋 |
| 特許庁審判長 |
山崎 達也 |
| 特許庁審判官 |
田中 秀人 清木 泰 |
| 発明の名称 | バーチャルマシーンの動作の復帰に対する割込又は実行のベクトル処理 |
| 代理人 | 大貫 進介 |
| 代理人 | 伊東 忠重 |
| 代理人 | 伊東 忠彦 |