【事件の表示】
　特願２０１２−　２１８９６「コンピュータのメモリを参照する方法およびコンピュータ」拒絶査定不服審判事件〔平成２４年　６月　７日出願公開、特開２０１２−１０８９３８、請求項の数（１１）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続の経緯 
　本願は、平成１２年１月２８日（優先権主張：１９９９年１月２８日、米国他４国）を国際出願日とする特許出願（特願２０００−５９６４４８号）の一部を平成２２年９月２１日に新たな特許出願（２０１０−２１１１０２号）とし、さらに該新たな特許出願の一部を平成２４年２月３日に新たな特許出願（２０１２−２１８９６号）としたものであって、平成２４年５月２８日付けで拒絶理由通知がなされ、同年９月３日付けで意見書の提出とともに手続補正がなされたが、同年１２月５日付けで拒絶査定がなされ、これに対して平成２５年４月９日付けで拒絶査定不服審判請求がなされたものである。
 　 
２．本願発明
　本願の請求項１乃至１１に係る発明は、平成２４年９月３日付けの手続補正で補正された特許請求の範囲に記載された事項により特定される、以下のとおりのものである。
「【請求項１】
　第１のコンピュータ命令ストリームをプロファイルする工程であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録することを含むプロファイル工程と、
　頻繁に実行されるセクションを区別するために、前記第１のコンピュータ命令ストリームのプロファイルを分析する工程と、
　前記第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみを第２のコンピュータ命令ストリームへ変換する工程と、
　前記第１のコンピュータ命令ストリームにおけるそれぞれの命令に対応するビットを含むビットベクトルを保存する工程であって、前記各ビットが、対応する命令のための前記頻繁に実行されるセクションのエントリーポイントがあるかどうかを示すものである工程と、
　前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視する工程と、
　前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動する工程と、
　前記頻繁に実行されるセクションの実行が完了した時に、前記第１のコンピュータ命令ストリームの実行に復帰する工程とを含む、
　第１のコンピュータ命令ストリームから第２のコンピュータ命令ストリームへ実行を移動する方法。
　　【請求項２】
　前記分析する工程は、前記第１のコンピュータ命令ストリームの中の複数の頻繁に実行されるセクションを区別し、
　前記監視する工程は、実行がそれぞれの前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視することを含み、
　前記移動する工程は、前記それぞれの頻繁に実行されるセクションのみを実行するためへ実行を移動させることを含み、
　前記それぞれの頻繁に実行されるセクションの実行が完了した時に、前記第１のコンピュータ命令ストリームの実行に復帰する
請求項１記載の方法。
　　【請求項３】
　テーブルに、前記頻繁に実行されるセクションのエントリーポイントのアドレスを保存する工程をさらに含み、
　前記監視する工程は、前記命令のアドレスが、前記頻繁に実行されるセクションのエントリーポイントのアドレスに一致したかどうかを判断するために、前記第１のコンピュータ命令ストリームのそれぞれの命令において、前記テーブルを照会することを含み、
　前記移動する工程は、前記命令のアドレスが、前記頻繁に実行されるセクションのエントリーポイントのアドレスに一致した場合に実行される工程である
　請求項１記載の方法。
　　【請求項４】
　前記監視する工程は、命令に対応するビットがセットされたかどうかを判断するために、前記第１のコンピュータ命令ストリームの中のそれぞれの命令においてビットベクトルを照会することを含み、
　前記移動する工程は、前記ビットがセットされた場合に実行される
請求項１記載の方法。
　　【請求項５】
　前記監視する工程は、実行が前記頻繁に実行されるセクションに到達した時を判断するために、統計を利用すること含む
請求項１記載の方法。
　　【請求項６】
　前記第１のコンピュータ命令ストリームは、第１の命令セットアーキテクチャにおいて実行されるものであり、
　前記第２のコンピュータ命令ストリームは、第２の命令セットアーキテクチャにおいて実行されるもので、前記第２の命令セットアーキテクチャは、前記第１の命令セットアーキテクチャとは相違する
請求項１記載の方法。
　　【請求項７】
　第１のコンピュータ命令ストリームをプロファイルする工程であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録することを含むプロファイル工程と、
　頻繁に実行されるセクションを区別するために、前記第１のコンピュータ命令ストリームのプロファイルを分析する工程と、
　前記第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみを、第２のコンピュータ命令ストリームへ変換する工程と、
　前記頻繁に実行されるセクションのエントリーポイントのアドレスと前記第１のコンピュータ命令ストリームにおける命令の対応するアドレスとをマッピングしたものを含むマッピングテーブルを保存する工程と、
　前記第１のコンピュータ命令ストリームのそれぞれのページのためのビットであって、それぞれのビットは、前記頻繁に実行されるセクションのマッピングが、対応するページにあるかどうかを示すものであるビットを含むビットベクトルを保存する工程と、
　前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視する工程と、
　前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動する工程と、
　前記頻繁に実行されるセクションの実行が完了した時に、前記第１のコンピュータ命令ストリームの実行に復帰する工程とを含む、
　第１のコンピュータ命令ストリームから第２のコンピュータ命令ストリームへ実行を移動する方法。
　　【請求項８】
　第１のコンピュータ命令ストリームをプロファイルするよう構成されたプロファイル装置であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録するように構成されているプロファイル装置と、
　頻繁に実行されるセクションを区別するために、前記第１のコンピュータ命令ストリームのプロファイルを分析し、
　前記第１のコンピュータ命令ストリームにおけるそれぞれの命令に対応するビットを含むビットベクトルを保存し、
　前記対応する命令のための前記頻繁に実行されるセクションのエントリーポイントがある場合にビットベクトルに対しビットをセットするように構成された分析装置と、
　前記第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみを第２のコンピュータ命令ストリームへ変換するように構成された変換装置と、
　前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視し、
　前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動するように構成された監視装置とを含む、
　第１のコンピュータ命令ストリームから第２のコンピュータ命令ストリームへ実行を移動するように構成されたコンピュータ。
　　【請求項９】
　前記分析装置は、前記第１のコンピュータ命令ストリームの中の複数の頻繁に実行されるセクションを区別するようにさらに構成され、
　前記監視装置は、
　実行がそれぞれの前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視し、かつ
　前記それぞれの頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ実行を移動させるようにさらに構成された
　請求項８記載のコンピュータ。
　　【請求項１０】
　前記第１のコンピュータ命令ストリームは、第１の命令セットアーキテクチャにおいて実行されるものであり、
　前記第２のコンピュータ命令ストリームは、第２の命令セットアーキテクチャにおいて実行されるもので、前記第２の命令セットアーキテクチャは、前記第１の命令セットアーキテクチャとは相違する
　請求項８記載のコンピュータ。
　　【請求項１１】
　第１のコンピュータ命令ストリームをプロファイルするよう構成されたプロファイル装置であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録するように構成されているプロファイル装置と、
　頻繁に実行されるセクションを区別するために、前記第１のコンピュータ命令ストリームのプロファイルを分析し、
　前記頻繁に実行されるセクションのエントリーポイントのアドレスと、前記第１のコンピュータ命令ストリームにおける命令の対応するアドレスとをマッピングしたものを含むマッピングテーブルを保存し、
　前記第１のコンピュータ命令ストリームのそれぞれのページのためのビットであって、それぞれのビットは、前記頻繁に実行されるセクションのマッピングが、対応するページにあるかどうかを示すものであるビットを含むビットベクトルを保存するように構成された分析装置と、
　前記第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみを第２のコンピュータ命令ストリームへ変換するように構成された変換装置と、
　前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視し、
　前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動するように構成された監視装置とを含む、
　第１のコンピュータ命令ストリームから第２のコンピュータ命令ストリームへ実行を移動するように構成されたコンピュータ。」
  　
３．原査定の理由の概要
Ａ．・・・（省略）・・・
Ｂ．・・・（省略）・・・
Ｃ．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
・請求項：１〜１１
・引用文献等：１〜４
・備考：
　・・・（中略）・・・
　　　　　　　　　　　引　用　文　献　等　一　覧
１．瀬古弘和、高速エミュレーション技術−ＦＸ！３２−、情報処理、日本、社団法人情報処理学会、１９９７年１１月１５日、第３８巻、第１１号（通巻３９３号）、ｐｐ．１０２７〜１０２８
２．特開平０７−１６８７１８号公報
３．特開平０９−１６０７７４号公報
４．特開平０９−２３１０９３号公報
   　
４．当審の判断
４−１．請求項１に係る発明について　
（１）引用例
（１−１）原査定の拒絶の理由に引用された「瀬古弘和、高速エミュレーション技術−ＦＸ！３２−、情報処理、日本、社団法人情報処理学会、１９９７年１１月１５日、第３８巻、第１１号（通巻３９３号）、ｐｐ．１０２７〜１０２８」（以下、「引用例１」という。）には、以下の各記載がある。なお、下線は当審で付加したものである。
（ａ）「3.　FX!32の仕組み
　
FX!32は、主要構成要素としてFX!32エージェント、FX!32サーバ、ランタイムエミュレータ、バックグラウンドオプティマイザなどがある。FX!32のアーキテクチャは、ランタイムエミュレータでWin32APIに対応したx86アプリケーションを透過的に実行し、静的に蓄積された変換イメージをバックグラウンドオプティマイザで最適化する
（ｂ）「3.1　
アプリケーションの実行（初回）
　
Win32APIに対応したx86アプリケーション（以下、Win32x86　アプリケーションと略す）が起動されると、FX!32エージェントによってランタイムエミュレータが起動される。ランタイムエミュレータは、Win32x86アプリケーションの実行ファイルと、関連するDLL(Dynamic Link Library)をロードする（これらを「イメージ」と称する。）。同時に最適化コードの有無を検索し、データベースに最適化コードがなければ、エミュレータでWin32x86アプリケーションを実行する。アプリケーションがエミュレータで実行されている間、使用された関数などをアプリケーションのプロファイル情報として収集しデータベースへ保存する。
　3.2　最適化
　アプリケーションを正常終了させると、FX!32サーバがデータベース内の新しいプロファイルをチェックする。プロファイルが新規の場合には、オプティマイザの実行が準備される。
オプティマイザは、置き換えられたバイナリをバックグランドで自動的に最適化するので、ユーザが特別な操作や設定をしなくても最適化されたイメージを手に入れることができる。オプティマイズ（最適化）によって生成されるファイルはバイナリデータで、AlphaネイティブのDLLとしてデータベースに保存されレジストリ（機器設定やソフトウエア設定が格納された一種のデータベース）に記録される。
　FX!32はアプリケーションの実行ファイル自体を書き換えるわけではないので、最適化されたイメージだけでは実行することはできない。なぜなら、FX!32はWin32x86アプリケーションの設定をそのままWindows NT/Alpha上のレジストリに展開し、利用するからである。よって、FX!32を利用するためにはシステム上にWin32x86アプリケーションが常にインストールされている必要がある。このため、FX!32はWin32x86アプリケーションのインストールをx86プラットフォーム同様に行う機能も提供している。
　最適化作業によってバイナリの最適化が進み、実行スピードをあげることができる。最適化によって最もよい性能を発揮するのは、アプリケーションの性質にもよるが、２、３回程度最適化を終えた後である。
これは、エミュレーション時に収集されるプロファイルが、最適化作業の量と範囲を決定するためである。つまり、使われなかったアプリケーション機能のプロファイルは収集さないため最適化も行われないが、頻繁に使われる機能についてはプロファイルがそのつど更新されるので最適化されやすくなる。
　
また、最適化作業自体はイメージ全体をすべて最適化するので、CPUとメモリを大量に消費する。
（ｃ）「3.3　
アプリケーション実行（２回目以降）
　
Win32x86アプリケーションが起動されると、FX!32エージェントによってランタイムエミュレータが起動される。ランタイムエミュレータはWin32x86アプリケーションの実行イメージと関連するDLLをロードする。同時に、最適化コードの有無を検索し、データベースに最適化コードがみつかると、データベースに蓄積されているAlphaネイティブコード（DLL）をロードする。最適化コードがない場合、あるいは利用できない状態のときにはエミュレータが起動される。
　２回目以降の最適化には直前のプロファイルが使用され、最適化を重ねると、アプリケーションの実行性能も向上するが、それにともなってプロファイルやバイナリのサイズも大きくなるため、ディスク容量には注意が必要である（FX!32マネージャの機能でディスク使用量の上限を設定することができる。）。」（第１０２８頁左欄第２４−４２行）
（ｄ）「4.1　主要構成要素
FX!32エージェント
　FX!32エージェントは、WindowsNT/Alpha上のすべてのプロセスに常駐し、Win32の「CreateProcess」コールを検知する。x86コードが検出された場合、ランタイムエミュレータが起動される。
・・・（中略）・・・
ランタイムエミュレータ
　ランタイムエミュレータは、エミュレーションだけでなく変換されたイメージとのインターフェースを受けもつ。x86コードをロードし、
ロードされたx86コードをAlphaネイティブに置き換えるインタプリタエンジン
バックグラウンドオプティマイザ
　FX!32サーバが収集したプロファイルデータをもとに、
x86コードをAlphaネイティブコードに置き換える
    　
　上記（ａ）乃至（ｄ）によると、引用例１には以下の発明（以下、「引用発明」という。）が記載されていると認められる。
「FX!32は、主要構成要素としてFX!32エージェント、FX!32サーバ、ランタイムエミュレータ、バックグラウンドオプティマイザからなり、FX!32のアーキテクチャは、ランタイムエミュレータでWin32APIに対応したx86アプリケーションを透過的に実行し、静的に蓄積された変換イメージをバックグラウンドオプティマイザで最適化するものであり、
　アプリケーションの初回の実行時に、
　Win32APIに対応したx86アプリケーションが起動されると、FX!32エージェントによってランタイムエミュレータが起動され、
　ランタイムエミュレータは、Win32x86アプリケーションの実行ファイルと、関連するDLL(Dynamic Link Library)をロードし、同時に最適化コードの有無を検索し、データベースに最適化コードがなければ、エミュレータでWin32x86アプリケーションを実行するとともに、アプリケーションがエミュレータで実行されている間、使用された関数などをアプリケーションのプロファイル情報として収集しデータベースへ保存するものであり、
　バックグラウンドオプティマイザは、置き換えられたバイナリをバックグランドで自動的に最適化するものであり、オプティマイズ（最適化）によって生成されるファイルはバイナリデータで、AlphaネイティブのDLLとしてデータベースに保存され、
　最適化は、エミュレーション時に収集されるプロファイルにより最適化作業の量と範囲が決定されるものであり、使われなかったアプリケーション機能のプロファイルは収集さないため最適化も行われないが、頻繁に使われる機能についてはプロファイルがそのつど更新されるので最適化されやすくなるものであり、最適化作業自体はイメージ全体をすべて最適化するものであり、
　アプリケーションの２回目以降の実行時に、
　Win32x86アプリケーションが起動されると、FX!32エージェントによってランタイムエミュレータが起動され、ランタイムエミュレータはWin32x86アプリケーションの実行イメージと関連するDLLをロードすると同時に、最適化コードの有無を検索し、データベースに最適化コードがみつかると、データベースに蓄積されているAlphaネイティブコード（DLL）をロードし、最適化コードがない場合、あるいは利用できない状態のときにはエミュレータが起動される、
方法。」
　　
（１−２）原査定の拒絶の理由に引用された特開平０７−１６８７１８号公報「（以下、「引用例２」という。）には、図面とともに以下の記載がある。なお、下線は当審で付加したものである。
（ｅ）「【００１０】
繰り返し処理があるプログラムが実行される場合
【００１１】
オブジェクト生成手段２は、図３に示すように、データ部４に、プログラムの実行時に必要な処理定義だけをオブジェクトコードとして、次のように変換する。
そして、属性により、それぞれ処理パターンにあった処理定義をオブジェクトコードに変換し、データ部４にオブジェクトコードを書き込む（ステップ２２）。必要な処理定義のオブジェクトコードを生成した後、オブジェクトコードに移った制御を元に戻すために、終了処理として、オブジェクトコードに制御を渡した命令の次の命令へ制御を戻すという命令のオブジェクトコードを生成する（ステップ２３）。
【００１２】
オブジェクト実行手段３は、図４に示すように、ステップ３１で前記オブジェクト生成手段２で生成されたオブジェクトコードの先頭へ制御を渡し、オブジェクトコードが実行される（ステップ３２）。最後のオブジェクトコードは、オブジェクトコードの先頭へ制御を渡した命令の次の命令へ制御を戻すという命令であるので、最後にそれが実行されることにより、制御判断手段１のステップ１３の次の命令へと制御が移る
　　
（１−３）原査定の拒絶の理由に引用された特開平０９−１６０７７４号公報「（以下、「引用例３」という。）には、図面とともに以下の記載がある。なお、下線は当審で付加したものである。
（ｆ）「【００１２】
【発明の実施の形態】図１に
命令のアドレスの任意の位置の１または複数ビットを用いて命令体系の種類を選択することで命令拡張を行えるようにした
・・・（中略）・・・
【００１５】図２は
ＴＬＢの各エントリごとに１または複数ビットの命令拡張ビットを有し、命令フェッチの際にその命令拡張ビットを読み出すことにより命令デコード前に命令体系の種類を選択することで命令拡張を行えるようにした
  　
（１−４）原査定の拒絶の理由に引用された特開平０９−２３１０９３号公報「（以下、「引用例４」という。）には、図面とともに以下の記載がある。なお、下線は当審で付加したものである。
（ｇ）「【００２１】上述したように本発明において、
プロセッサ・ハードウェアは、２つのメカニズムのうちのどちらを使用するかを、Ｘ８６プログラムから呼び出しプログラムに戻る際に決めねばならない。実質的には、戻りプログラムがPowerPCかＸ８６かであるかはソフトウェアによって告げられる。これはハードウェアがプログラムの戻りを実行する際に古いＣＳセレクタ及び関連する記述子テーブル・エントリを調べることによって行われる。
記述子テーブル・エントリは、ＣＳセレクタによって参照されたメモリのセグメントについての情報を有する。この記述子エントリの１ビット、特に記述子の上位４バイト（ダブルワード）のビット位置２１は、３２ビットＸ８６アーキテクチャによって指定されないまま残る。本発明では、上位のダブルワードのビット位置２１を、ターゲット戻りセグメントが標準のＸ８６ソフトウェア（この時のビットは０）か、またはPowerPCソフトウェア（この時のビットは１）であるかどうかを示すものと定義する。ビット位置２１は以降、制御転送モード・ビットとして示される。
・・・（中略）・・・
【００２４】従って、本発明の第２の態様は、呼び出しＸ８６プログラムのスタック・ポインタ及び戻りアドレスをメモリではなくレジスタに置くことである。これは呼び出されたプログラムのアーキテクチャ、この場合PowerPCであるが、Ｘ８６アーキテクチャの連係制限に拘束されないからである。
プロセッサはＸ８６とＸ８６間の制御転送と、Ｘ８６とPowerPC間の制御転送とを識別できなければならない。この識別は、転送（Ｘ８６のジャンプまたは呼び出し）を開始するときに使用される命令により参照されるゲート記述子をプロセッサが調べることによって達成される。このようにＸ８６アーキテクチャは、ゲート記述子が、ターゲット・コード・セグメントを指すセレクタを保持することがわかる。命令エミュレーション・ユニットは、ゲート記述子のセレクタによって参照されたコード・セグメント記述子を読取るが、これらの両方はメイン・メモリにある。コード・セグメント記述子は命令エミュレーション・ユニットによって読取られた後、制御転送モード・ビットを参照して次に発生する転送の種類を決める。制御転送モード・ビットが０の場合、通常の制御転送が発生する。制御転送モード・ビットが１の場合、PowerPCコードへの転送が生じ、戻りアドレス及び古いスタック・ポインタはメモリではなくプロセッサ・レジスタに残る。
    　
（２）対比
　そこで、本願の請求項１に係る発明（以下、「本願発明」という）と引用発明とを対比する。
（２−１）引用発明の「ランタイムエミュレータは、Win32x86アプリケーションの実行ファイルと、関連するDLL(Dynamic Link Library)をロードし、同時に最適化コードの有無を検索し、データベースに最適化コードがなければ、エミュレータでWin32x86アプリケーションを実行するとともに、アプリケーションがエミュレータで実行されている間、使用された関数などをアプリケーションのプロファイル情報として収集しデータベースへ保存するものであり」によると、「ランタイムエミュレータ」は「Win32x86アプリケーション」の実行を行うとともに、「使用された関数などをアプリケーションのプロファイル情報として収集しデータベースへ保存する」ものであり、この「使用された関数など」は「Win32x86アプリケーション」の実行フローの詳細を示すものであるから、引用発明の「Win32x86アプリケーション」は本願発明の「第１のコンピュータ命令ストリーム」に相当し、引用発明の「プロファイル情報」は本願発明の「プロファイル」に相当するものである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「第１のコンピュータ命令ストリームをプロファイルする工程であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録することを含むプロファイル工程」
を備える点で共通するものである。
（２−２）引用発明の「バックグラウンドオプティマイザは、置き換えられたバイナリをバックグランドで自動的に最適化するものであり、オプティマイズ（最適化）によって生成されるファイルはバイナリデータで、AlphaネイティブのDLLとしてデータベースに保存され、最適化は、エミュレーション時に収集されるプロファイルにより最適化作業の量と範囲が決定されるものであり、使われなかったアプリケーション機能のプロファイルは収集さないため最適化も行われないが、頻繁に使われる機能についてはプロファイルがそのつど更新されるので最適化されやすくなるものであり、最適化作業自体はイメージ全体をすべて最適化するものであり」との記載によると、「バックグラウンドオプティマイザ」は、「最適化作業の量と範囲」を決定するために収集された「プロファイル」を使用しているものである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「前記第１のコンピュータ命令ストリームのプロファイルを分析する工程」
を備える点で共通するものである。
（２−３）引用発明の「FX!32のアーキテクチャは、ランタイムエミュレータでWin32APIに対応したx86アプリケーションを透過的に実行し、静的に蓄積された変換イメージをバックグラウンドオプティマイザで最適化するものであり」及び「バックグラウンドオプティマイザは、置き換えられたバイナリをバックグランドで自動的に最適化するものであり、オプティマイズ（最適化）によって生成されるファイルはバイナリデータで、AlphaネイティブのDLLとしてデータベースに保存され」において、ここでいう「静的に蓄積された変換イメージ」又は「置き換えられたバイナリ」は、「FX!32」により「x86アプリケーション」のコードから「Alphaネイティブ」のコードへ変換されるものであることは明らかであるから、引用発明におけるこの変換された「Alphaネイティブ」のコードは、本願発明の「第２のコンピュータ命令ストリーム」に相当するものである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「前記第１のコンピュータ命令ストリームを第２のコンピュータ命令ストリームへ変換する工程」
を備える点で共通するものである。
（２−４）引用発明の「アプリケーションの２回目以降の実行時に、Win32x86アプリケーションが起動されると、FX!32エージェントによってランタイムエミュレータが起動され、ランタイムエミュレータはWin32x86アプリケーションの実行イメージと関連するDLLをロードすると同時に、最適化コードの有無を検索し、データベースに最適化コードがみつかると、データベースに蓄積されているAlphaネイティブコード（DLL）をロードし、最適化コードがない場合、あるいは利用できない状態のときにはエミュレータが起動される」によると、引用発明では「ランタイムエミュレータ」により「Win32x86アプリケーション」又は「Alphaネイティブコード（DLL）」を実行するものである。
　そうすると、本願発明と引用発明は、後記する点を除いて、
「前記第１のコンピュータ命令ストリーム又は前記第２のコンピュータ命令ストリームを実行する工程」
を備える点で共通するものである。
（２−５）以上のことから、本願発明と引用発明とは、
「第１のコンピュータ命令ストリームをプロファイルする工程であって、前記第１のコンピュータ命令ストリームのプロファイルを生成するために、前記第１のコンピュータ命令ストリームの実行フローの詳細を記録することを含むプロファイル工程と、
　前記第１のコンピュータ命令ストリームのプロファイルを分析する工程と、
　前記第１のコンピュータ命令ストリームを第２のコンピュータ命令ストリームへ変換する工程と、
　前記第１のコンピュータ命令ストリーム又は前記第２のコンピュータ命令ストリームを実行する工程と、
を備える方法。」
　である点で一致し、以下の点で相違する。  
　　
［相違点１］
　本願発明では、「頻繁に実行されるセクションを区別するために」プロファイルを分析しているが、引用発明では「最適化作業の量と範囲」を決定するためである点。
［相違点２］
　本願発明では、「第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみ」を第２のコンピュータ命令ストリームへ変換するものであるのに対し、引用発明では最適化された「Alphaネイティブコード（DLL）」とする点。
［相違点３］
　本願発明では、「前記第１のコンピュータ命令ストリームにおけるそれぞれの命令に対応するビットを含むビットベクトルを保存する工程であって、前記各ビットが、対応する命令のための前記頻繁に実行されるセクションのエントリーポイントがあるかどうかを示すものである工程」を備えているのに対し、引用発明ではそのようになっていない点。
［相違点４］
　本願発明では、「前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視する工程と、前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動する工程と、前記頻繁に実行されるセクションの実行が完了した時に、前記第１のコンピュータ命令ストリームの実行に復帰する工程」を備えることにより、「第１のコンピュータ命令ストリーム」と「第２のコンピュータ命令ストリーム」間での実行の移動が行われるものであるのに対し、引用発明では「Win32x86アプリケーション」と「Alphaネイティブコード（DLL）」がどのように実行されるものかが不明である点。
　　
（３）当審の判断  
（３−１）［相違点１］及び［相違点２］について
　引用発明の「静的に蓄積された変換イメージ」との記載は、変換元である「Win32x86アプリケーション」全体を「Alphaネイティブ」のコードに変換したものと考えられる（なお、この点について、上記原査定の理由で引用した引用例１の引用箇所ではないが、「一方、バイナリトランスレーションには、実行前に「変換」作業が必要になる。エミュレータのように逐次アプリケーションを実行できる柔軟性はないものの、アプリケーションがバイナリとして静的に蓄積されるため「最適化」を行い、実効性能を向上させる余地がある。」（引用例１の第１０２６頁左欄第１３−１９行）との記載がある。）。
　また、ここで行われる最適化は、プロファイルにより最適化作業の量と範囲を決定するものであり、頻繁に使われる部分については最適化の効果が大きいため、最適化の対象となることは当業者であれば自明であり、このように頻繁に使われる部分についてはネイティブのコードに変換されるものと考えられる。
　そして、最適化により「静的に蓄積された変換イメージ」から生成される「Alphaネイティブコード（DLL）」は、変換元である「Win32x86アプリケーション」を「Alphaネイティブ」のDLL(Dynamic Link Library）すなわち「Alphaネイティブ」の部品とするものであり、また、上記記載（ａ）乃至（ｄ）にはどのような単位（処理ブロックや関数単位など）で部品化されるのかが記載されていないものの、できる限り広い範囲でネイティブのコードとした方が実行速度が速く有利であることは明らかである。
　そうすると、引用発明において、上記頻繁に使われる部分のみに限定してネイティブ化した部品とする格別の理由はなく、また、最適化の対象範囲とネイティブ化する範囲が必ずしも一致する必要もない。
　したがって、上記相違点１及び相違点２に係る構成は当業者が容易に想到しえたものとはいえないものである。
（３−２）［相違点３］について
　引用例３の（ｆ）には、命令のアドレスの任意の位置の１または複数ビットやＴＬＢの各エントリごとに１または複数ビットを用いて命令体系の種類を選択する技術が記載されており、また、引用例４の（ｇ）にも制御転送モード・ビットに基づいてプロセッサ・アーキテクチャを判別する技術が記載されているものの、これらはそもそも「第１のコンピュータ命令ストリームにおけるそれぞれの命令に対応するビットを含むビットベクトル」であって「前記各ビットが、対応する命令のための前記頻繁に実行されるセクションのエントリーポイントがあるかどうかを示すものである」ものではないし、また、これらの技術を引用発明に適用したとしても、上記相違点３に係る構成とすることができたものでもない。
　したがって、上記相違点３に係る構成は当業者が容易に想到しえたものとはいえないものである。
（３−３）［相違点４］について
　引用例１の上記（ｂ）に「FX!32はアプリケーションの実行ファイル自体を書き換えるわけではないので、最適化されたイメージだけでは実行することはできない。なぜなら、FX!32はWin32x86アプリケーションの設定をそのままWindows NT/Alpha上のレジストリに展開し、利用するからである。よって、FX!32を利用するためにはシステム上にWin32x86アプリケーションが常にインストールされている必要がある。」と、また、上記（ｄ）に「ランタイムエミュレータは、エミュレーションだけでなく変換されたイメージとのインターフェースを受けもつ。x86コードをロードし、ロードされたx86コードをAlphaネイティブに置き換えるインタプリタエンジンと、変換イメージがある場合はそれをロードする機能を提供する。Alpha上で利用可能なシステムサービスやライブラリとのインタフェースを受けもつ（これをジャケットと呼ぶ。）。」と記載され、また、上記（３−１）で示したように「Alphaネイティブコード（DLL）」はネイティブコードの部品として使用されるものであることから、引用発明における「ランタイムエミュレータ」は、主として「Win32x86アプリケーション」をインタプリタで実行しており、使用可能な「Alphaネイティブコード（DLL）」があればそれを呼び出してネイティブ環境で実行し、それが終了すれば元の「Win32x86アプリケーション」に戻るような実行制御が行われるものであることは、当業者であれば容易に想到するものであるし、また、引用例２の上記（ｅ）にも、実行時に必要な処理定義だけをオブジェクトコードに変換し、実行時にはインタプリタから生成されたオブジェクトコードの先頭へ制御を渡し、オブジェクトコードが実行され、最後のオブジェクトコードは、オブジェクトコードの先頭へ制御を渡した命令の次の命令へ制御を戻す技術が記載されている。
　したがって、上記相違点４に係る構成は当業者が容易に想到しえたものである。
　　
（４）まとめ
　以上のとおりであるから、本願の請求項１に係る発明は、引用発明及び引用例２乃至４に記載の技術に基づいて当業者が容易に発明をすることができたものとすることができないものである。
　　
４−２．請求項７に係る発明について
（１）引用例
　各引用例の記載事項については、上記「４−１．（１）引用例」で示したとおりのものである。
　　
（２）対比
　そこで、本願の請求項７に係る発明（以下、「本願発明２」という）と引用発明とを対比すると、以下の点で相違する。
    　
［相違点１］
　本願発明２では、「頻繁に実行されるセクションを区別するために」プロファイルを分析しているが、引用発明では「最適化作業の量と範囲」を決定するためである点。
［相違点２］
　本願発明２では、「第１のコンピュータ命令ストリームの頻繁に実行されるセクションのみ」を第２のコンピュータ命令ストリームへ変換するものであるのに対し、引用発明では最適化された「Alphaネイティブコード（DLL）」とする点。
［相違点３］
　本願発明２では、「前記頻繁に実行されるセクションのエントリーポイントのアドレスと前記第１のコンピュータ命令ストリームにおける命令の対応するアドレスとをマッピングしたものを含むマッピングテーブルを保存する工程」と、「前記第１のコンピュータ命令ストリームのそれぞれのページのためのビットであって、それぞれのビットは、前記頻繁に実行されるセクションのマッピングが、対応するページにあるかどうかを示すものであるビットを含むビットベクトルを保存する工程」を備えているのに対し、引用発明ではそのようになっていない点。
［相違点４］
　本願発明２では、「前記第１のコンピュータ命令ストリームの実行が前記頻繁に実行されるセクションに到達した時を判断するために、前記第１のコンピュータ命令ストリームの実行を監視する工程と、前記頻繁に実行されるセクションのみを実行するために、前記第１のコンピュータ命令ストリームから前記第２のコンピュータ命令ストリームへ前記実行を移動する工程と、前記頻繁に実行されるセクションの実行が完了した時に、前記第１のコンピュータ命令ストリームの実行に復帰する工程」を備えることにより、「第１のコンピュータ命令ストリーム」と「第２のコンピュータ命令ストリーム」間での実行の移動が行われるものであるのに対し、引用発明では「Win32x86アプリケーション」と「Alphaネイティブコード（DLL）」がどのように実行されるものかが不明である点。
   　
（３）当審の判断
（３−１）［相違点１］及び［相違点２］について
　上記「４．１（３−１）［相違点１］及び［相違点２］について」で示したとおりである。
　したがって、上記相違点１及び相違点２に係る構成は、当業者が容易に想到しえたものとはいえないものである。
（３−２）［相違点３］について
　引用例３の（ｆ）には、命令のアドレスの任意の位置の１または複数ビットやＴＬＢの各エントリごとに１または複数ビットを用いて命令体系の種類を選択する技術が記載されており、また、引用例４の（ｇ）にも制御転送モード・ビットに基づいてプロセッサ・アーキテクチャを判別する技術が記載されているものの、これらはそもそも「前記頻繁に実行されるセクションのエントリーポイントのアドレスと前記第１のコンピュータ命令ストリームにおける命令の対応するアドレスとをマッピングしたものを含むマッピングテーブル」及び「前記第１のコンピュータ命令ストリームのそれぞれのページのためのビットであって、それぞれのビットは、前記頻繁に実行されるセクションのマッピングが、対応するページにあるかどうかを示すものであるビットを含むビットベクトル」を開示するものではないし、また、これらの技術を引用発明に適用したとしても、上記相違点３に係る構成とすることができたものでもない。
　したがって、上記相違点３に係る構成は、当業者が容易に想到しえたものとはいえないものである。
（３−３）［相違点４］について
　上記「４．１（３−３）［相違点４］について」で示したとおりである。
　したがって、上記相違点４に係る構成は当業者が容易に想到しえたものである。
    　
（４）まとめ
　以上のとおりであるから、本願の請求項７に係る発明は、引用発明及び引用例２乃至４に記載の技術に基づいて当業者が容易に発明をすることができたものとすることができないものである。
　　
４−３．請求項２乃至６及び請求項８乃至１１に係る発明について
　請求項２乃至６及び請求項８乃至１１についても、上記「４−１．請求項１に係る発明について」又は「４−２．請求項７に係る発明について」で示した理由と同様の理由により、引用発明及び引用例２乃至４に記載の技術に基づいて当業者が容易に発明をすることができたものとはいえないものである。
　　
５．むすび
　以上のとおり、本願の請求項１乃至１１に係る発明は、引用発明及び引用例２乃至４に記載の技術に基づいて当業者が容易に発明をすることができたものとすることができないから、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　　
　よって、結論のとおり審決する。