【事件の表示】
　特願２００６−３４９８１０「仮想プロセッサへの直接的なインタラプトの送信」拒絶査定不服審判事件〔平成１９年　７月１９日出願公開、特開２００７−１８３９５１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　平成１８年１２月２６日（パリ条約による優先権主張２００５年１２月３０日、アメリカ合衆国）の出願であって、
　平成２１年７月１３日付けで最初の拒絶理由通知（同年同月２１日発送）がなされ、
　同年１０月２１日付けで意見書が提出されるとともに、手続補正がなされ、
　同年１１月１０日付けで拒絶査定（同年同月１７日発送）がなされ、
　平成２２年３月１７日付けで審判請求がなされたものである。
　
第２．本願発明の認定
　本願の請求項９に係る発明（以下、「本願発明」という。）は、上記平成２１年１０月２１日付けの手続補正により補正された明細書、特許請求の範囲及び図面の記載からみて、本願の特許請求の範囲の請求項９に記載されたとおりの次のものと認められる。
　
「ゲストが仮想プロセッサ上で実行されている間に、インタフェースがインタラプトリクエストを受け付けるステップと、
　前記インタラプトリクエストのモードに基づき、送信ロジックが前記インタラプトリクエストが前記仮想プロセッサに送信されるべきか判断するステップと、
　前記インタラプトリクエストが前記仮想プロセッサに送信されるべきでない場合、イグジットロジックが前記ゲストからホストに制御を移行するステップと、
から構成されることを特徴とする方法。」
　
第３．先行技術文献に記載されている技術的事項と先行技術文献に記載されている発明の認定
　
１．引用例１に記載されている技術的事項
　原審が拒絶理由通知において引用した国際公開第０２／０５２４０４号（２００２年７月４日国際公開。以下、「引用例１」という。）には、図面とともに以下の技術的事項が記載されている。なお、以下の仮訳は当審が訳出したものである。
　　　
（１の１）
「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). 」
（明細書第１頁第１０行目〜同頁第１９行目。
　仮訳：従来の仮想計算機モニタ（ＶＭＭ）は典型的には一つのコンピュータ上で動作し、ＶＭＭは他のソフトウェアに１つまたは複数の仮想計算機のアブストラクションを提供する。それぞれの仮想計算機は、自前のプラットホームであるかのように動作し、それ自身の”ゲストオペレーティングシステム”を動作させる。（つまりは、このゲートオペレーティングシステムは、ＶＭＭにホストされたオペレーティングシステムである。）ゲストオペレーティングシステムは、仮想計算機上というよりも専用に割り当てられた計算機上で動作しているかのように、動作することを期待する。つまり、様々なコンピュータオペレーションを制御し、これらのオペレーションを通じてハードウェア資源へアクセスすることを、ゲストオペレーティングシステムは期待する。ここでのハードウェア資源には、プロセッサに存在する資源（例えば、コントロールレジスタ）やメモリ内に存在する資源（例えば、ディスクリプタテーブル）が含まれうる。）
　　
（１の２）
「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. 」
（明細書第６頁第２０行目〜第７頁第１８行目。
　仮訳：本発明の方法及び装置は、仮想計算機モニタ（ＶＭＭ）のためのプロセッササポートを提供する。図１は、仮想計算機環境１００の一具体例を示したものである。この具体例では、ベアプラットホームハードウェア１１６はコンピューティングプラットホームを含む。このコンピューティングプラットホームは、例えば、標準的なオペレーティングスシステム（ＯＳ）か、ＶＭＭ１１２のような仮想計算機モニタ（ＶＭＭ）を実行しうる。ＶＭＭは典型的にはソフトウェアにより実装されているものの、ＶＭＭはベアマシンインターフェースを、より高レベルのソフトウェアにエミュレーションの如くエクスポートする。ここでの、より高レベルのソフトウェアには、標準ＯＳやリアルタイムＯＳが含まれうるが、本発明はそのようなものに限定されるものではない。加えて、例えば、あるＶＭＭが別のＶＭＭの中または上で動作しうる。ＶＭＭやＶＭＭの典型的な特徴やＶＭＭの機能は当業者にはよく知られており、ソフトウェア、ファームウェアに実装されるか、様々な技術の結合により実装されうる。
　既に述べたように、ＶＭＭは他のソフトウェア（例えば、”ゲスト”ソフトウェア）に１つまたは複数の仮想計算機（ＶＭ）のアブストラクションを提供する。図１は、２つのＶＭ１０２と１１４を示す。それぞれのＶＭのゲストソフトウェアには、ゲストＯＳ１０４または１０６のようなゲストＯＳと、様々なゲストソフトウェアアプリケーション１０８−１１０が含まれる。ゲストＯＳ１０４、１０６が動作しているハードウェアプラットホーム内の物理的資源（例えば、プロセッサレジスタ、メモリ、メモリマップドＩ／Ｏデバイス）へのアクセスを制御することやその他のファンクションを行うことを、それぞれのゲストＯＳ１０４、１０６は期待する。）
　
（１の３）
「Referring to FIG. 3, all guest software runs at a processor mode referred to herein as a virtual 32-bit mode (V32 mode).」
（明細書第１０頁第１７行目〜同頁第１８行目。
　仮訳：図３を参照すると、全てのゲストソフトウェアは、ここではバーチャル３２ビットモード（Ｖ３２モード）と呼ばれるプロセッサモードにおいて動作する。）
　
（１の４）
「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.」
（明細書第１１頁第３行目〜同頁第５行目。
　仮訳：ＶＭＭ３２０はＶ３２モードの外で動作する。Ｖ３２モードの外へ出る遷移が発生する時、ゲストＯＳ３０８かゲストアプリケーション３０６が生じさせたオペレーションに対する制御権を、ＶＭＭ３２０は受け取る。）
　
（１の５）
「In one embodiment, certain exceptions and interrupts cause a transition out of V32 mode. These exceptions and interrupts include virtualization traps.」
（明細書第１１頁第１９行目〜同頁第２０行目。
　仮訳：一具体例では、ある例外やインタラプトは、Ｖ３２モードの外に出る遷移を引き起こす。これらの例外やインタラプトは”バーチャリゼーショントラップ”を含む。） 
　
（１の６）
「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. 」
（明細書第１２頁第９行目〜同頁第１６行目。
　仮訳：一具体例において、ゲストソフトウェアがＶ３２モードにおいて動作している時、ソフトウェアインタラプト（例えば、ＢＯＵＮＤ、ＩＮＴ、ＩＮＴＯ命令の実行により引き起こされたインタラプト）は、ゲストＯＳ３０８により取り扱われる。ゲストＯＳ３０８は、ゲストＩＤＴ（例えば、ゲストアドレス空間３０４に存在するＩＤＴ）を使う。バーチャリゼーショントラップを含む、その他の全てのインタラプトと例外は、Ｖ３２モードの外に出る遷移を引き起こす。Ｖ３２モードの外に出る遷移の結果として、ゲストアドレス空間３０４からＶＭＭアドレス空間３０２への変化が起こる。そして、対応する例外やインタラプトを取り扱うコードを指し示すために、ＩＤＴ３１６は用いられる。）
　
（１の７）
「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. 」
（明細書第１４頁第２０行目〜第１５頁第４行目。
　仮訳：プロセッシングブロック４０６では、ゲストソフトウェアがＶ３２モードにおいて制限されるオペレーションを行おうとする試みが特定される。この試みに応じて、Ｖ３２モードはイグジットされて、ゲストソフトウェアが発したオペレーションに対する制御はＶＭＭに移る（プロセッシングブロック４０８）。このＶＭＭはＶ３２モードの外部にて動作するものである。一具体例では、ＶＭＭはどのオペレーションがＶ３２モードの外に出る遷移を引き起こすべきであるかを設定する。その設定については、後で図７に関連付けてもっと詳細を述べるとおりである。一具体例では、そのようなオペレーションはバーチャリゼーショントラップを生成し、バーチャリゼーショントラップはＶ３２モードの外に出る遷移を引き起こす。）
　
（１の８）
「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,…（以下略）…」
（明細書第１７頁第１２行目〜同頁第１４行目。
　仮訳：加えて、バーチャリゼーショントラップはＣＰＵＩＤ命令の実行を試みることによって引き起こされうる。それにより、ＶＭＭが選んだプロセッサの特性のアブストラクションを、ＶＭＭが提示することを可能にする。）
　
（１の９）
「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). 」
（明細書第１７頁第１８行目〜第１８頁第７行目。
　仮訳：図７は本発明の一具体例に基づくリダイレクションマップを維持するための方法７００の流れ図である。この具体例によれば、ＶＭＭはリダイレクションマップを維持する（プロセッシングブロック７０４）。リダイレクションマップはどのインタラプトや例外がバーチャリゼーショントラップという結果になるべきかを設定するためのものである。プロセッシングブロック７０６において、一つのインタラプトまたは例外が発生したことが特定される。そして、リダイレクションマップが調べられる（プロセッシングブロック７０８）。この調査は、リダイレクションマップのなかの、このインタラプトまたは例外に対応するビットを探すためのものである。
　決定ボックス７１０において、このインタラプトがゲストＯＳによって取り扱われてもよいかについて決定がなされる。その決定が肯定的であるならば、インタラプトまたは例外はＶ３２モードに向けて送信され、インタラプトまたは例外はゲストＯＳにより取り扱われる（プロセッシングボックス７１４）。そうでなければ、バーチャリゼーショントラップが生成され、Ｖ３２モードの外に出る遷移が引き起こされる（プロセッシングブロック７１２）。）
　
２．引用発明の認定
　引用例１の上記（１の１）に「従来の仮想計算機モニタ（ＶＭＭ）は典型的には一つのコンピュータ上で動作し、ＶＭＭは他のソフトウェアに１つまたは複数の仮想計算機のアブストラクションを提供する。」と記載され、上記（１の２）に「ＶＭＭは他のソフトウェア（例えば、”ゲスト”ソフトウェア）に１つまたは複数の仮想計算機（ＶＭ）のアブストラクションを提供する。」と記載されていることから明らかなように、仮想計算機モニタＶＭＭは仮想計算機ＶＭのアブストラクションを提供するものである。
　
　引用例１の上記（１の８）に「バーチャリゼーショントラップはＣＰＵＩＤ命令の実行を試みることによって引き起こされうる。それにより、ＶＭＭが選んだプロセッサの特性のアブストラクションを、ＶＭＭが提示することを可能にする。」と記載され、上記（１の１）に「ゲストオペレーティングシステムは、仮想計算機上というよりも専用に割り当てられた計算機上で動作しているかのように、動作することを期待する。つまり、様々なコンピュータオペレーションを制御し、これらのオペレーションを通じてハードウェア資源へアクセスすることを、ゲストオペレーティングシステムは期待する。ここでのハードウェア資源には、プロセッサに存在する資源（例えば、コントロールレジスタ）やメモリ内に存在する資源（例えば、ディスクリプタテーブル）が含まれうる。」と記載され、上記（１の２）に「ＶＭＭはベアマシンインターフェースを、より高レベルのソフトウェアにエミュレーションの如くエクスポートする。」、「ゲストＯＳ１０４、１０６が動作しているハードウェアプラットホーム内の物理的資源（例えば、プロセッサレジスタ、メモリ、メモリマップドＩ／Ｏデバイス）へのアクセスを制御することやその他のファンクションを行うことを、それぞれのゲストＯＳ１０４、１０６は期待する。」と記載されていることから明らかなように、ＣＰＵＩＤ命令に応じて、仮想計算機モニタＶＭＭがプロセッサの特性のアブストラクションを提示するものであり、また、仮想計算機モニタＶＭＭが仮想計算機ＶＭのアブストラクションを提供することに伴って、仮想計算機ＶＭ上で動作するゲストオペレーティングシステム（ゲストＯＳ）がプロセッサに存在する資源をアクセスできるかのように、仮想計算機モニタＶＭＭは制御するものであるから、結局のところ、仮想計算機モニタＶＭＭはプロセッサのアブストラクションを提供するものである。
　
　引用例１の上記（１の２）に「本発明の方法及び装置は、仮想計算機モニタ（ＶＭＭ）のためのプロセッササポートを提供する。」と記載されていることから明らかなように、引用例１は仮想計算機モニタＶＭＭのためのプロセッササポートを提供する方法に関するものである。
　
　引用例１の上記（１の９）に「プロセッシングブロック７０６において、一つのインタラプトまたは例外が発生したことが特定される。」と記載されていることから明らかなように、インタラプトを受け付けるステップが示されている。
　また、このインタラプトを受け付けるステップの後について、上記（１の９）には「その決定が肯定的であるならば、インタラプトまたは例外はＶ３２モードに向けて送信され、インタラプトまたは例外はゲストＯＳにより取り扱われる（プロセッシングボックス７１４）。そうでなければ、バーチャリゼーショントラップが生成され、Ｖ３２モードの外に出る遷移が引き起こされる（プロセッシングブロック７１２）。」と記載されているころから、インタラプトを受け付けるステップはＶ３２モード下のゲストＯＳが実行されているときに行われるものである。
　そしてＶ３２モードについては、上記（１の３）に「全てのゲストソフトウェアは、ここではバーチャル３２ビットモード（Ｖ３２モード）と呼ばれるプロセッサモードにおいて動作する。」と記載され、上記（１の４）に「ＶＭＭ３２０はＶ３２モードの外で動作する。Ｖ３２モードの外へ出る遷移が発生する時、ゲストＯＳ３０８かゲストアプリケーション３０６が生じさせたオペレーションに対する制御権を、ＶＭＭ３２０は受け取る。」と記載され、上記（１の５）に「ある例外やインタラプトは、Ｖ３２モードの外に出る遷移を引き起こす。これらの例外やインタラプトは”バーチャリゼーショントラップ”を含む。」と記載され、上記（１の６）に「ゲストソフトウェアがＶ３２モードにおいて動作している時、ソフトウェアインタラプト（例えば、ＢＯＵＮＤ、ＩＮＴ、ＩＮＴＯ命令の実行により引き起こされたインタラプト）は、ゲストＯＳ３０８により取り扱われる。ゲストＯＳ３０８は、ゲストＩＤＴ（例えば、ゲストアドレス空間３０４に存在するＩＤＴ）を使う。バーチャリゼーショントラップを含む、その他の全てのインタラプトと例外は、Ｖ３２モードの外に出る遷移を引き起こす。Ｖ３２モードの外に出る遷移の結果として、ゲストアドレス空間３０４からＶＭＭアドレス空間３０２への変化が起こる。」と記載され、上記（１の７）に「プロセッシングブロック４０６では、ゲストソフトウェアがＶ３２モードにおいて制限されるオペレーションを行おうとする試みが特定される。この試みに応じて、Ｖ３２モードはイグジットされて、ゲストソフトウェアが発したオペレーションに対する制御はＶＭＭに移る（プロセッシングブロック４０８）。このＶＭＭはＶ３２モードの外部にて動作するものである。一具体例では、ＶＭＭはどのオペレーションがＶ３２モードの外に出る遷移を引き起こすべきであるかを設定する。その設定については、後で図７に関連付けてもっと詳細を述べるとおりである。一具体例では、そのようなオペレーションはバーチャリゼーショントラップを生成し、バーチャリゼーショントラップはＶ３２モードの外に出る遷移を引き起こす。」と記載されていることから明らかなように、Ｖ３２モードは、仮想計算機モニタＶＭＭではなくて仮想計算機ＶＭが動作していることを示すものである。
　結局のところ、引用例１には、ゲストＯＳが仮想計算機ＶＭ上で実行されている間に、インタラプトを受け付けるステップが生じることが示されている。
　
　引用例１の上記（１の９）に「リダイレクションマップはどのインタラプトや例外がバーチャリゼーショントラップという結果になるべきかを設定するためのものである。プロセッシングブロック７０６において、一つのインタラプトまたは例外が発生したことが特定される。そして、リダイレクションマップが調べられる（プロセッシングブロック７０８）。この調査は、リダイレクションマップのなかの、このインタラプトまたは例外に対応するビットを探すためのものである。…（改行）…決定ボックス７１０において、このインタラプトがゲストＯＳによって取り扱われてもよいかについて決定がなされる。その決定が肯定的であるならば、インタラプトまたは例外はＶ３２モードに向けて送信され、インタラプトまたは例外はゲストＯＳにより取り扱われる（プロセッシングボックス７１４）。そうでなければ、バーチャリゼーショントラップが生成され、Ｖ３２モードの外に出る遷移が引き起こされる（プロセッシングブロック７１２）。」と記載され、既に示したように、Ｖ３２モードは、仮想計算機モニタＶＭＭではなくて仮想計算機ＶＭが動作していることを示すものであるから、引用例１には、リダイレクションマップにおける、受け付けたインタラプトに対応するビットの値に基づき、インタラプトが仮想計算機ＶＭに送信されるべきか判断するステップが示されるとともに、インタラプトが仮想計算機ＶＭに送信されるべきでない場合、ゲストＯＳから仮想計算機モニタＶＭＭに制御を移行するステップが示されているといえる。　
　
　上記引用例１の記載事項及び図面を総合勘案すると、引用例１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。
　
　仮想計算機モニタＶＭＭが仮想計算機ＶＭのアブストラクションとプロセッサのアブスクラクションを提供するシステムにおける方法であり、仮想計算機モニタＶＭＭのためのプロセッササポートを提供する方法であって、
　ゲストＯＳが仮想計算機ＶＭ上で実行されている間に、インタラプトを受け付けるステップと、
　リダイレクションマップにおける、受け付けたインタラプトに対応するビットの値に基づき、インタラプトが仮想計算機ＶＭに送信されるべきか判断するステップと、
　インタラプトが仮想計算機ＶＭに送信されるべきでない場合、ゲストＯＳから仮想計算機モニタＶＭＭに制御を移行するステップと、
から構成されることを特徴とする方法。
　
第４．対比
　本願発明と引用発明を比較する。
　
　引用発明における「ゲストＯＳ」は本願発明における「ゲスト」に相当する。
　引用発明における「インタラプト」は本願発明における「インタラプトリクエスト」に相当する。
　引用発明における「仮想計算機モニタＶＭＭ」は本願発明における「ホスト」に相当する。
　
　すると、本願発明と引用発明とは、少なくとも次の点で一致する。
　
＜一応の一致点＞
　ゲストが実行されている間に、インタラプトリクエストを受け付けるステップと、
　前記インタラプトリクエストに基づき、前記インタラプトリクエストが送信されるべきか判断するステップと、
　前記インタラプトリクエストが送信されるべきでない場合、前記ゲストからホストに制御を移行するステップと、
から構成されることを特徴とする方法。
　
　一方で、両者は、一見して次の点で相違するようにみえる。
　
＜一応の相違点１＞
　ゲストが実行されている間に、インタラプトリクエストを受け付けるステップに関して、本願発明では、ゲストが実行されているのは「仮想プロセッサ上で」あるのに対し、引用発明では、ゲストＯＳが実行されているのは「仮想計算機ＶＭ上で」ある点。
　これに関連して、前記インタラプトリクエストに基づき、前記インタラプトリクエストが送信されるべきか判断するステップに関して、本願発明では、送信されるべき先が「仮想プロセッサ」であるのに対し、引用発明では、送信されるべき先が「仮想計算機ＶＭ」である点。
　これらに更に関連して、前記インタラプトリクエストが送信されるべきでない場合、前記ゲストからホストに制御を移行するステップに関連して、本願発明では、送信されるべきでない先が「仮想プロセッサ」であるのに対し、引用発明では、送信されるべきでない先が「仮想計算機ＶＭ」である点。
　
＜一応の相違点２＞
　前記インタラプトリクエストに基づき、前記インタラプトリクエストが送信されるべきか判断するステップに関して、本願発明では、「前記インタラプトリクエストのモード」に基づくものであるのに対し、引用発明では、「リダイレクションマップにおける、受け付けたインタラプトに対応するビットの値」に基づくものである点。
　
＜一応の相違点３＞
　本願発明では各ステップを行う主体がそれぞれ、「インタフェース」、「送信ロジック」、「イグジットロジック」であるのに対し、引用発明では各ステップを行う主体が特定されていない点。
　
第５．判断
　上記した一応の相違点１乃至３について検討する。
　
１．一応の相違点１について
　引用発明は「仮想計算機モニタＶＭＭが仮想計算機ＶＭのアブストラクションとプロセッサのアブスクラクションを提供する」ものである。このように、引用例１には「仮想プロセッサ」という用語は用いられていないものの、引用発明においては仮想計算機モニタＶＭＭが仮想計算機ＶＭ上で動作するプロセッサを仮想的に提供するものであるから、引用発明においても仮想プロセッサが存在するものであり、ゲストＯＳが仮想プロセッサ上で実行されるものであり、送信されるべき先や送信されるべきでない先が仮想プロセッサである。　
　よって、上記した一応の相違点１は、実質的には本願発明と引用発明の相違点ではない。
　
２．一応の相違点２について
　「インタラプトリクエストのモード」という用語自体は、一般的なインタラプトリクエストの何らかの特定の属性という意味を持つ程度のものである。そして、本願発明に対応する本願の請求項９には「インタラプトリクエストのモード」という用語の意味をそれ以上に特定する記載はない。
　そして、引用発明は、「リダイレクションマップにおける、受け付けたインタラプトに対応するビットの値に基づき、インタラプトが仮想計算機ＶＭに送信されるべきか判断する」ものであり、つまりは、受け付けたインタラプトが対応しうる、リダイレクションマップ内にある複数のビットのうち、いずれの１つのビットに対応しているのかを特定して、その特定されたものに基づいて判断を行うものである。これは、受け付けたインタラプトの何らかの特定の属性に基づいて判断を行うものに他ならない。
　よって、引用発明における「リダイレクションマップにおける、受け付けたインタラプトに対応するビットの値」に基づいて判断することと、本願発明における「前記インタラプトリクエストのモード」に基づいて判断することに、実質的な意味の相違はない。　
　よって、上記した一応の相違点２は、実質的には本願発明と引用発明の相違点ではない。
　
　なお、本願の明細書の【００３９】に「送信モード」及び「トリガーモード」という用語について記載されている。しかしながら、この「送信モード」及び「トリガーモード」という用語は、本願発明に対応する請求項９ではなく、請求項９を引用する請求項１０に記載されている。本願発明に対応する請求項９には、「送信モード」及び「トリガーモード」という用語ではなく、単に「モード」と記載されるのみであるのであるから、本願発明に対応する請求項９における「インタラプトリクエストのモード」という用語の解釈を行う際に、本願の明細書の【００３９】の「送信モード」及び「トリガーモード」という用語に関する記載をそのまま参酌するのは妥当でなく、既に指摘したとおり、「インタラプトリクエストのモード」という用語は、「送信モード」及び「トリガーモード」の有する意味に限定されない、一般的なインタラプトリクエストの何らかの特定の属性という意味を持つ程度のものであると解釈することが妥当である。
　
３．一応の相違点３について
　引用発明は「仮想計算機モニタＶＭＭのためのプロセッササポートを提供する」ものである。また、引用発明の各ステップを行う何らかの主体が存在することは自明である。そのため、引用発明においても、各ステップの主体としてプロセッサ内のハードウェア等の何らかの主体が存在することは自明である。
　よって、上記した一応の相違点３は、実質的には本願発明と引用発明の相違点ではない。
　
４．特許法第２９条第１項第３号の規定についての小括
　上記１．乃至３．にて示したように、上記した一応の相違点１乃至３は、実質的には本願発明と引用発明の相違点ではなく、本願発明は（引用例１に記載された）引用発明である。
　
５．特許法第２９条第２項の規定について
　なお、仮に上記した一応の相違点１乃至３のいずれかが本願発明と引用発明の実質的な相違点であるとしても、上記した一応の相違点１における仮想プロセッサや、上記した一応の相違点２におけるモードや、上記した一応の相違点３における各ステップを行う主体の特定は、当業者にとって通常の創作能力の発揮によりなし得た程度のものであり、これらの相違点は格別のものではない。また、本願発明が有する作用効果は、（引用例１に記載された）引用発明から当業者が予測できた範囲内のものである。よって、仮に上記した一応の相違点１乃至３のいずれかが本願発明と引用発明の実質的な相違点であるとしても、本願発明は、（引用例１に記載された）引用発明に基いて、当業者が容易に発明をすることができたものである。
　
第６．むすび
　したがって、本願の請求項９に係る発明は、その優先日前に日本国内又は外国において頒布された刊行物に記載された発明であるから、他の請求項について検討をするまでもなく、本願は特許法第２９条第１項第３号に該当し特許を受けることができない。
　また、仮に本願の請求項９に係る発明と前記刊行物に記載された発明に実質的な相違点が存在するとしても、本願の請求項９に係る発明は、その優先日前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。