【事件の表示】
　特願２００４−２２２３９９「分岐予測装置およびその制御方法」拒絶査定不服審判事件〔平成１８年　２月　９日出願公開、特開２００６−　４０１７３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　平成１６年７月２９日の出願であって、
　平成２０年５月１６日付けで最初の拒絶理由通知（同年同月２７日発送）がなされ、
　同年７月２８日付けで意見書が提出されるとともに、手続補正がなされ、
　同年１０月２３日付けで拒絶査定（同年同月２８日発送）がなされ、
　同年１１月２７日付けで審判請求がなされ、
　平成２１年１月５日付けで手続補正がなされ、
　同年３月３０日付けで審査官より特許法第１６４条第３項の規定による前置報告がなされ、
　平成２２年８月２３日付けで当審より審尋（同年同月２４日発送）がなされ、
　この審尋に対して、同年１０月２５日付けで回答書が提出され、
　当審より、同年１１月１８日付けで平成２１年１月５日付けの手続補正を却下する旨の補正の却下の決定（平成２２年１１月３０日発送）がなされるとともに、同年同月１８日付けで最初の拒絶理由通知（同年同月２４日発送）がなされ、
　平成２３年１月２４日付けで意見書が提出されるとともに、手続補正がなされたものである。
　
第２．本願発明の認定
　本願の請求項１乃至１０に係る発明は、平成２３年１月２４日付けの手続補正により補正された、本願の特許請求の範囲の請求項１乃至１０に記載された次のものと認められる。
　
「　【請求項１】
　第１のプログラムから第２のプログラムを呼び出すコール命令と前記第２のプログラムから前記第１のプログラムに戻るリターン命令を含む分岐命令の分岐先アドレスを含む分岐履歴情報を保持し、前記分岐履歴情報に基づいて前記分岐命令が実行された場合の分岐先アドレスの予測を行う分岐予測部と、
　前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合に、前記検出されたコール命令のアドレスに所定値を加算して、前記検出されたコール命令に対応するリターン命令の戻り先アドレスである第１の戻り先アドレスを算出する第１のリターンアドレス演算部と、
　前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合に、前記第１の戻り先アドレスが有効であることを表す第１のバリッド情報を生成するとともに、前記分岐予測部が前記分岐履歴情報から検出されたコール命令に対応するリターン命令を検出した場合又は前記分岐予測部が前記分岐履歴情報から検出したコール命令の実行を完了した場合に、前記生成した第１のバリッド情報を無効にする第１のバリッド情報生成部と、
　第１の戻り先アドレスと第１のバリッド情報を保持する単一の第１のエントリを有するとともに、前記第１のリターンアドレス演算部が算出した第１の戻り先アドレスと前記第１のバリッド情報生成部が生成した第１のバリッド情報を、前記第１のエントリに保持する戻り先アドレス記憶部と、
　コール命令が実行された場合に、前記実行されたコール命令のアドレスに所定値を加算して、前記実行されたコール命令に対応するリターン命令の戻り先アドレスである第２の戻り先アドレスを算出する第２のリターンアドレス演算部と、
　第２の戻り先アドレスと、対応する第２の戻り先アドレスが有効であることを表す第２のバリッド情報をそれぞれ保持する複数の第２のエントリを有するとともに、前記第２のリターンアドレス演算部が算出した第２の戻り先アドレスと前記生成された第２の戻り先アドレスに対応する第２のバリッド情報を、前記複数の第２のエントリのうち先頭のエントリに保持する戻り先アドレススタックと、
　値がオール１である場合に前記第１のエントリを指定し、値がオール０である場合に前記複数の第２のエントリの先頭のエントリを指定するとともに、値がオール０から１ずつ増分する場合に前記複数の第２のエントリのうち前記先頭エントリから深さ方向に向かってエントリを１つずつ指定するポインタ情報を保持するとともに、前記分岐予測部が前記分岐履歴情報から検出したコール命令の実行が完了した場合又は前記分岐予測部が前記分岐履歴情報からリターン命令を検出した場合に、前記ポインタ情報に１を加算するとともに、前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合又は前記分岐予測部が前記分岐履歴情報から検出したリターン命令の実行が完了した場合に前記ポインタ情報から１を減算し、値が前記オール１のポインタ情報に１を加算した場合には値が前記オール０のポインタ情報を生成するとともに、値が前記オール０のポインタ情報から１を減算した場合には値が前記オール１のポインタ情報を生成するポインタ部と、
　前記第１のバリッド情報と前記第２のバリッド情報と前記ポインタ情報に基づいて、前記戻り先アドレス記憶部の第１のエントリに保持する第１の戻り先アドレスと、前記戻り先アドレススタックの複数の第２のエントリに保持する第２の戻り先アドレスのうち、前記ポインタ情報が指定したバリッド情報が有効であるエントリに保持された戻り先アドレスを選択するとともに、前記ポインタ情報が指定したエントリのバリッド情報が無効である場合、前記分岐予測部が保持する前記分岐履歴情報から検出したリターン命令に対応する分岐先アドレスを選択する出力選択部と
　を有することを特徴とする分岐予測装置。
　　【請求項２】
　前記出力選択部は、
　前記第１の戻り先アドレスと前記第２の戻り先アドレスがいずれも無効であることを、前記第１のバリッド情報と前記第２のバリッド情報が表す場合には、前記分岐予測部が前記分岐履歴情報に保持するリターン命令に対応する分岐先アドレスを選択することを特徴とする請求項１記載の分岐予測装置。
　　【請求項３】
　前記ポインタ部は、
　分岐命令を実行する分岐命令実行部が出力するコール命令の完了信号を受信した場合に、前記ポインタ情報に１を加算し、前記分岐命令実行部が出力するリターン命令の完了信号を受信した場合に、前記ポインタ情報から１を減算することによりポインタ情報を生成するとともに、前記分岐予測部が前記分岐履歴情報からリターン命令を検出したことを表すリターンヒット信号を受信した場合に、前記ポインタ情報に１を加算し、前記分岐予測部が前記分岐履歴情報からコール命令を検出したことを表すコールヒット信号を受信した場合に、前記ポインタ情報から１を減算することによりポインタ情報を生成して保持することを特徴とする請求項１記載の分岐予測装置。
　　【請求項４】
　前記ポインタ部は、初期値としてオール０を保持することを特徴とする請求項２記載の分岐予測装置。
　　【請求項５】
　前記戻り先アドレス記憶部と前記戻り先アドレススタックは、先入れ後出しにより戻り先アドレスを保持するスタックバッファであることを特徴とする請求項１〜４のいずれか１項に記載の分岐予測装置。
　　【請求項６】
　第１のプログラムから第２のプログラムを呼び出すコール命令と前記第２のプログラムから前記第１のプログラムに戻るリターン命令を含む分岐命令の分岐先アドレスを含む分岐履歴情報を保持し、前記分岐履歴情報に基づいて前記分岐命令が実行された場合の分岐先アドレスの予測を行う分岐予測装置の制御方法において、
　第１のリターンアドレス演算部が、分岐予測部が前記分岐履歴情報からコール命令を検出した場合に、前記検出されたコール命令のアドレスに所定値を加算して、前記検出されたコール命令に対応するリターン命令の戻り先アドレスである第１の戻り先アドレスを算出するステップと、
　第１のバリッド情報生成部が、前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合に、前記第１の戻り先アドレスが有効であることを表す第１のバリッド情報を生成するとともに、前記分岐予測部が前記分岐履歴情報から検出されたコール命令に対応するリターン命令を検出した場合又は前記分岐予測部が前記分岐履歴情報から検出したコール命令の実行を完了した場合に、前記生成した第１のバリッド情報を無効にするステップと、
　第１の戻り先アドレスと第１のバリッド情報を保持する単一の第１のエントリを有する戻り先アドレス記憶部が、前記第１のリターンアドレス演算部が算出した第１の戻り先アドレスと前記第１のバリッド情報生成部が生成した第１のバリッド情報を、前記第１のエントリに保持するステップと、
　第２のリターンアドレス演算部が、コール命令が実行された場合に、前記実行されたコール命令のアドレスに所定値を加算して、前記実行されたコール命令に対応するリターン命令の戻り先アドレスである第２の戻り先アドレスを算出するステップと、
　第２の戻り先アドレスと、対応する第２の戻り先アドレスが有効であることを表す第２のバリッド情報をそれぞれ保持する複数の第２のエントリを有する戻り先アドレススタックが、前記第２のリターンアドレス演算部が算出した第２の戻り先アドレスと前記生成された第２の戻り先アドレスに対応する第２のバリッド情報を、前記複数の第２のエントリのうち先頭のエントリに保持するステップと、
　値がオール１である場合に前記第１のエントリを指定し、値がオール０である場合に前記複数の第２のエントリの先頭のエントリを指定するとともに、値がオール０から１ずつ増分する場合に前記複数の第２のエントリのうち前記先頭エントリから深さ方向に向かってエントリを１つずつ指定するポインタ情報を保持するとともに、前記分岐予測部が前記分岐履歴情報から検出したコール命令の実行が完了した場合又は前記分岐予測部が前記分岐履歴情報からリターン命令を検出した場合に、前記ポインタ情報に１を加算するとともに、前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合又は前記分岐予測部が前記分岐履歴情報から検出したリターン命令の実行が完了した場合に前記ポインタ情報から１を減算し、値が前記オール１のポインタ情報に１を加算した場合には値が前記オール０のポインタ情報を生成するとともに、値が前記オール０のポインタ情報から１を減算した場合には値が前記オール１のポインタ情報を生成するステップと、
　出力選択部が、前記第１のバリッド情報と前記第２のバリッド情報と前記ポインタ情報に基づいて、前記戻り先アドレス記憶部の第１のエントリに保持する第１の戻り先アドレスと、前記戻り先アドレススタックの複数の第２のエントリに保持する第２の戻り先アドレスのうち、前記ポインタ情報が指定したバリッド情報が有効であるエントリに保持された戻り先アドレスを選択するとともに、前記ポインタ情報が指定したエントリのバリッド情報が無効である場合、前記分岐予測部が保持する前記分岐履歴情報から検出したリターン命令に対応する分岐先アドレスを選択するステップと
　を有することを特徴とする分岐予測装置の制御方法。
　　【請求項７】
　前記出力選択部は、
　前記第１の戻り先アドレスと前記第２の戻り先アドレスがいずれも無効であることを、前記第１のバリッド情報と前記第２のバリッド情報が表す場合には、前記分岐予測部が前記分岐履歴情報に保持するリターン命令に対応する分岐先アドレスを選択することを特徴とする請求項６記載の分岐予測装置の制御方法。
　　【請求項８】
　前記ポインタ部は、
　分岐命令を実行する分岐命令実行部が出力するコール命令の完了信号を受信した場合に、前記ポインタ情報に１を加算し、前記分岐命令実行部が出力するリターン命令の完了信号を受信した場合に、前記ポインタ情報から１を減算することによりポインタ情報を生成するとともに、前記分岐予測部が前記分岐履歴情報からリターン命令を検出したことを表すリターンヒット信号を受信した場合に、前記ポインタ情報に１を加算し、前記分岐予測部が前記分岐履歴情報からコール命令を検出したことを表すコールヒット信号を受信した場合に、前記ポインタ情報から１を減算することによりポインタ情報を生成して保持することを特徴とする請求項６記載の分岐予測装置の制御方法。
　　【請求項９】
　前記ポインタ部は、初期値としてオール０を保持することを特徴とする請求項７記載の分岐予測装置の制御方法。
　　【請求項１０】
　前記戻り先アドレス記憶部と前記戻り先アドレススタックは、先入れ後出しにより戻り先アドレスを保持するスタックバッファであることを特徴とする請求項６〜９のいずれか１項に記載の分岐予測装置の制御方法。」
　
第３．当審が通知した拒絶理由
　平成２２年１１月１８日付けで当審が通知した拒絶理由は次のとおりである。
　
「 第１．平成２１年１月５日付けの手続補正について 
 　本拒絶理由通知と同日付けの補正の却下の決定により、平成２１年１月５日付けの手続補正は却下されることとなった。 
 　その補正の却下の決定の内容は以下のとおりのものである。 
　 
 [理由] 
「…（中略）…
３の２．独立特許要件 
　上記３の１で示したように、本件補正は限定的減縮の目的を少なくとも有するものであるので、本件補正が、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定（以下、この規定を「独立特許要件」という。）に違反するものであるかを検討する。 
　 
３の２の１．特許法第３６条第４項第１号の要件の検討 
　独立特許要件のうち、補正後の各請求項について、本願が特許法第３６条第４項第１号の規定を満たすものであるか否かを検討すると、下記の点で特許法第３６条第４項第１号の規定を満たしていない。 
　 
３の２の１の１．実施可能要件を満たすために明細書等に記載されているべき最低限必要な技術的事項の検討 
　明細書等に記載された実施例の動作例においては、リターンスタックポインタ２７０の二進数値が”１１１”か”０００”のいずれかのみであり、かつ、リターンアドレススタックＸ２４０とリターンアドレススタック２２０において実質的に用いられるエントリはそれぞれ１つのみである。また、動作例として示されているものは、図面の【図７】で示されるプログラムを実行する場合に通常あり得るケースのごく一部のみに過ぎない。つまり、本願が特許法第３６条第４項第１号で規定される実施可能要件を満たすか否かを判断するためには、図面の【図７】で示されるプログラムを実行する場合に通常あり得るケースのそれぞれについて、明細書等に記載された実施例が正しく稼働することが、明細書等の記載から明確であるか否かを検証する必要がある。 
　先行する命令が完了するタイミングと後続の命令の属性がブランチヒストリ（分岐予測部）にて検出されるタイミングの前後関係が不定であるパイプライン処理を行うという本願において前提とされている条件下で、本願図面の【図７】で示されるプログラムを実行する際において、明細書等に記載された実施例である、リターンアドレススタック２２０、リターンアドレススタックＸ２４０、リターンスタックポインタ２７０を備えた、分岐予測のためにリターン命令の戻り先アドレスを読み出す装置を、正常に稼働させるために最低限必要な技術的事項を、本願の明細書等に記載された範囲にとらわれず、当審にて推察・検討した。 
　その結果、少なくとも下記のＡ．とＢ．に示す割り当て・定義・動作の全てが必須であると考えられる。 
　 
Ａ．割り当て・定義 
　リターンアドレススタック２２０（以下、単に「スタック」という。）の先頭エントリＳＴＫ０、２番目のエントリＳＴＫ１、３番目のエントリＳＴＫ２…にそれぞれ、リターンスタックポインタ２７０（以下、単に「ポインタ」という。）の二進数値”０００”、”００１”、”０１０”…を割り当てる。 
　リターンアドレススタックＸ２４０（以下、単に、「スタックＸ」という。）の先頭エントリＳＴＫＸ−１、２番目のエントリＳＴＫＸ−２…にそれぞれ、ポインタの二進数値”１１１”、”１１０”…を割り当てる。 
　ポインタの二進数値”０００”から１だけ減算されるときの二進数値を”１１１”と定義する。 
　ポインタの二進数値”１１１”に１だけ加算するときの二進数値を”０００”と定義する。 
　 
Ｂ．動作 
（１）ブランチヒストリ（分岐予測部）にてコール命令を検出した（以下、単に「コール検出」という。）ときに行うべき動作は以下の（１−ａ）と（１−ｂ）である。 
　（１−ａ）ポインタを１だけ減算する。 
　（１−ｂ）スタックＸに戻り先アドレスを格納する。その際の詳細は（１−ｂ−α）と（１−ｂ−β）である。 
　　（１−ｂ−α）格納先は、上記（１−ａ）で更新（減算）された後のポインタが示すエントリである。 
　　（１−ｂ−β）スタックＸに既に格納されている戻り先アドレスについては、エントリ間移動をさせない。 
　 
（２）コール命令が完了した（以下、単に「コール完了」という。）ときに行うべき動作は以下の（２−ａ）、（２−ｂ）及び（２−ｃ）である。 
　（２−ａ）ポインタを１だけ加算する。 
　（２−ｂ）スタックに戻り先アドレスを格納する。その際の詳細は（２−ｂ−α）と（２−ｂ−β）である。 
　　（２−ｂ−α）格納先は常にスタックの先頭エントリＳＴＫ０である。 
　　（２−ｂ−β）スタックに既に格納されている戻り先アドレスについては、ＳＴＫ０→ＳＴＫ１→ＳＴＫ２→…という形態でプッシュのようなエントリ間移動を行う。 
　（２−ｃ）スタックＸに既に格納されている戻り先アドレスについては、…→ＳＴＫＸ−２→ＳＴＫＸ−１→破棄という形態でポップのようなエントリ間移動を行う。 
　 
（３）ブランチヒストリ（分岐予測部）にてリターン命令を検出した（以下、単に「リターン検出」という。）ときに行うべき動作は、以下の（３−ａ）、（３−ｂ）、（３−ｃ）及び（３−ｄ）である。 
　（３−ａ）ポインタを１だけ加算する。 
　（３−ｂ）スタックまたはスタックＸ内の、上記（３−ａ）で更新（加算）される前のポインタが示すエントリから、分岐予測のための戻り先アドレスを読み出す。 
　（３−ｃ）上記（３−ｂ）にてスタック内のエントリから戻り先アドレスを読み出した場合でも、スタックの既に格納されている戻り先アドレスについて、エントリ間移動はさせない。 
　（３−ｄ）上記（３−ｂ）にてスタックＸ内のエントリから戻り先アドレスを読み出した場合でも、スタックＸの既に格納されている戻り先アドレスについて、エントリ間移動はさせない。 
　 
（４）リターン命令が完了した（以下、単に「リターン完了」という。）ときに行うべき動作は以下の（４−ａ）及び（４−ｂ）である。 
　（４−ａ）ポインタを１だけ減算する。 
　（４−ｂ）スタックに既に格納されている戻り先アドレスについて、…→ＳＴＫ２→ＳＴＫ１→ＳＴＫ０→破棄という形態でポップのようなエントリ間移動を行う。 
　 
３の２の１の２．明細書等に最低限必要な技術的事項が記載されているか否かの検討 
　上記の「Ｂ．動作」で示した各動作内容のうち、（１−ｂ−β）、（２−ｂ−α）、（２−ｂ−β）、（２−ｃ）、（３−ｃ）、（３−ｄ）及び（４−ｂ）の部分の動作内容は、明細書等には記載されていない。また、技術常識に基づいて、これらの動作内容が明細書等に記載されているに等しいというわけでもない。なお、平成２２年１０月２５日付け回答書において、審判請求人（出願人）は、明細書等に記載された実施例が上記の（２−ｂ−α）、（２−ｂ−β）の動作を行う旨の主張を行っているが、当該主張は明細書等の記載に基づくものではない。（なお、明細書の【００６８】の記載は、コール完了の際に、スタックに有効な戻り先アドレスが何もないときに、新たな戻り先アドレスをスタックの先頭エントリＳＴＫ０に置くことを示した程度のものであり、上記した（２−ｂ−α）、（２−ｂ−β）の動作を行う旨を示したものとはいえない。また、スタックが先入れ後出しのスタックバッファであるというだけでは、上記した（２−ｂ−α）、（２−ｂ−β）の動作を行うことが自明というわけではない。先入れ後出しのスタックバッファを実現するための手法はひとつとは限られないからである。） 
　つまり、先行する命令が完了するタイミングと後続の命令の属性がブランチヒストリ（分岐予測部）にて検出されるタイミングの前後関係が不定であるパイプライン処理を行うという本願において前提とされる条件下で、本願図面の【図７】で示されるプログラムを実行する際において、明細書等に記載された実施例である、リターンアドレススタック２２０、リターンアドレススタックＸ２４０、リターンスタックポインタ２７０を備えた、分岐予測のためにリターン命令の戻り先アドレスを読み出す装置を、正常に稼働させるために最低限必要な技術的事項が、明細書等には開示されているとはいえない。よって、補正後の請求項１乃至１０に係る発明（及び、補正前の請求項１乃至１０に係る発明）を実施をすることができる程度に明確かつ十分に、明細書等が記載されているとはいえない。 
　 
３の２の１の３．明細書等の記載から類推されるいくつかの想定例の不具合 
　なお、上記の「Ｂ．動作」で示した各動作内容のうち、（１−ｂ−β）、（２−ｂ−α）、（２−ｂ−β）、（２−ｃ）、（３−ｃ）、（３−ｄ）及び（４−ｂ）の部分の動作内容は、明細書等には記載されていない。そのため、これらの部分については他の動作を行うことも考えられるが、その場合には、以下で例示するように、いずれもポインタが適切なエントリを指し示さなくなる。 
　 
（想定例１） 
　（１）コール検出時に、ポインタを１だけ減算するとともに、スタックＸに戻り先アドレスを格納し、（２）コール完了時に、ポインタを１だけ加算するとともに、スタック内でプッシュのようなエントリ間移動を行わずに、スタック内の空いている次のエントリに新たな戻り先アドレスを格納し、（３）リターン検出時に、ポインタが示すエントリから、分岐予測のための戻り先アドレスを読み出す場合（つまり、上記「Ｂ．動作」の（２−ｂ−α）及び（２−ｂ−β）とは異なる動作を行うと想定した場合） 
　図面の【図７】で示されるプログラムを実行して、コール検出、コール完了、コール検出、コール完了、リターン検出の順に発生した場合に、このリターン検出時には、スタックの２番目のエントリであるＳＴＫ１に正しい戻り先アドレスがあるのに、ポインタはスタックの先頭のエントリであるＳＴＫ０を指し示してしまう。 
　 
（想定例２） 
　（１）コール検出時に、ポインタを１だけ減算するとともに、スタックＸに戻り先アドレスを格納し、（２）コール完了時に、ポインタを１だけ加算するとともに、スタック内でプッシュのようなエントリ間移動を行いつつ、スタック内の先頭のエントリＳＴＫ０に新たな戻り先アドレスを格納し、（３）リターン検出時に、ポインタを１だけ加算するとともに、更新（加算）される前のポインタが示すエントリから、分岐予測のための戻り先アドレスを読み出し、スタックから読み出した場合にスタック内でポップのようなエントリ間移動を行う場合（つまり、上記「Ｂ．動作」の（３−ｃ）とは異なる動作を行うと想定した場合） 
　図面の【図７】で示されるプログラムを実行して、コール検出、コール完了、コール検出、コール完了、リターン検出、リターン検出の順に発生した場合に、最後のリターン検出時には、スタックの先頭のエントリであるＳＴＫ０に正しい戻り先アドレスがあるのに、更新（加算）される前のポインタはスタックの２番目のエントリであるＳＴＫ１を指し示してしまう。 
　 
（想定例３） 
　（１）コール検出時に、ポインタを１だけ減算するとともに、スタックＸに戻り先アドレスを格納し、（２）コール完了時に、ポインタを１だけ加算するとともに、スタック内でプッシュのようなエントリ間移動を行いつつ、スタック内の先頭のエントリＳＴＫ０に新たな戻り先アドレスを格納し、（３）リターン検出時に、ポインタを１だけ加算するとともに、更新（加算）される前のポインタが示すエントリから、分岐予測のための戻り先アドレスを読み出し、スタックから読み出した場合にスタック内でエントリ間移動を行わず、（４）リターン完了時に、ポインタを１だけ減算し、スタック内でエントリ間移動を行わない場合（つまり、上記「Ｂ．動作」の（４−ｂ）とは異なる動作を行うと想定した場合） 
　図面の【図７】で示されるプログラムを実行して、コール検出、コール完了、コール検出、コール完了、リターン検出、リターン完了、リターン検出の順に発生した場合に、最後のリターン検出時には、スタックの２番目のエントリであるＳＴＫ１に正しい戻り先アドレスがあるのに、更新（加算）される前のポインタはスタックの先頭エントリであるＳＴＫ０を指し示してしまう。 
　 
　上記の「Ｂ．動作」で示した各動作内容のうち、（１−ｂ−β）、（２−ｂ−α）、（２−ｂ−β）、（２−ｃ）、（３−ｃ）、（３−ｄ）及び（４−ｂ）の部分の動作内容は、明細書等には記載されていない以上、明細書等の記載からは、上記した想定例１、想定例２及び想定例３のようなものも類推されるところである。つまり、明細書等に接した当業者にとって、実施可能な態様（上記した「Ｂ．動作」で示される態様）が明細書等に開示されていると認識できるものではない。このように明細書等の記載は不完全なものと言わざるを得ないから、本願は特許法第３６条第４項第１号で規定される実施可能要件を満たしているとはいえない。 
　 
３の２の１の４．リターンアドレススタックＸに複数のエントリがある場合についての動作を明確にする必要性について 
　なお、上記した「Ｂ．動作」の（１−ｂ−β）、（２−ｃ）及び（３−ｄ）は、スタックＸが複数のエントリからなり、かつ、図面の【図７】で示されるプログラムを実行して、途中でコール完了が発生することなくコール検出が２回連続するケースなどで必要になる動作である。明細書等に記載された実施例においてはスタックＸが１つのみとなっているため、上記した「Ｂ．動作」の（１−ｂ−β）、（２−ｃ）及び（３−ｄ）について明細書等にて言及されていない。しかしながら、本願においてはスタックのみならずスタックＸについても先入れ後出しのスタックバッファであることを想定したものであるのだから、スタックＸについても複数のエントリがある場合にどのように動作させるべきであるのかが、明細書等に開示されていることが、特許法第３６条第４項第１号に規定される実施可能要件を満たすためには必要である。この点でも本願は実施可能要件を満たすものとはなっていない。 
　 
３の２の１の５．実施可能要件についての小括　　 
　したがって、上記で指摘した点で、本願は特許法第３６条第４項第１号の規定に違反するものであるから、補正後の請求項１乃至１０に係る発明は特許出願の際独立して特許を受けることができないものである。つまり、本件補正は、独立特許要件に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
…（中略）…」 
　 
…（中略）…
　
第３．拒絶の理由 
理由１ 
　この出願は、発明の詳細な説明の記載について下記の点で、特許法第３６条第４項第１号に規定する要件を満たしていない。 
　 
　　　　　　　　　　　　　　　　　記 
　「第１．平成２１年１月５日付けの手続補正について」の「３の２の１．特許法第３６条第４項第１号の要件の検討」で示した理由と同じ理由で、本願は、特許法第３６条第４項第１号でいう実施可能要件を満たしていない。 
　　 
…（中略）…　
　
理由３ 
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
　 
　　　　　　　　　　　　　　　　　記 
…（中略）…
２．本願の請求項１乃至１０には「ポインタ情報」に関する記載または「ポインタ情報」を加算または減算する旨の記載はあるものの、「ポインタ情報」により指し示されるべき（明細書等に記載された実施例における「リターンアドレススタックＸ２４０」に対応する）「第１の戻り先アドレス記憶部」の「第１のエントリ」や（明細書等に記載された実施例における「リターンアドレススタック２２０」に対応する）「第２の戻り先アドレス記憶部」の「第２のエントリ」において、戻り先アドレス等をどのように格納・移動・消去していくかが明確には記載されていない。そのため、本願の請求項１乃至１０の記載では、結局のところ、「ポインタ情報」が指し示すものが何であるのかが明確でなく、また、本願の請求項１乃至１０からまとまりのあるひとつの技術思想を捉えることが出来ない。（なお、「第１．平成２１年１月５日付けの手続補正について」の「３の２の１．特許法第３６条第４項第１号の要件の検討」にて既に示したように、リターンアドレススタックＸ２４０とリターンアドレススタック２２０において、戻り先アドレス等をどのように格納・移動・消去していくかについては、本願の請求項１乃至１０に係る発明に関して実施可能要件を満たす程度には、出願当初の明細書等には記載されているとはいえない。そのため、リターンアドレススタックＸ２４０とリターンアドレススタック２２０において、戻り先アドレス等をどのように格納・移動・消去していくかについてを特定するように、各請求項を補正することは、特許法第１７条の２第３項に規定される新規事項の追加となる可能性が極めて高いので注意されたい。） 
…（後略）… 　 」
　
第４．請求人の意見書による主張
　平成２２年１１月１８日付け拒絶理由通知に対して、請求人は平成２３年１月２４日付けで意見書を提出した。同意見書における請求人の主張（特に、上記「第３．当審が通知した拒絶理由」で示した特許法第３６条第４項第１号でいう実施可能要件に関する理由１と、特許法第３６条第６項第２号に関する理由２の２．に対する主張）は次のとおりである。
　
「…（前略）…
（ｂ）理由１（特許法第３６条第４項第１号）について
（ｂ−１）「３の２の１の１．実施可能要件を満たすために明細書等に記載されているべき最低限必要な技術的事項の検討」について
　『明細書等に記載された実施例の動作例においては、リターンスタックポインタ２７０の二進数値が”１１１”か”０００”のいずれかのみであり、かつ、リターンアドレススタックＸ２４０とリターンアドレススタック２２０において実質的に用いられるエントリはそれぞれ１つのみである。』旨の指摘に対しては、請求項１の記載を
　「第１の戻り先アドレスと第１のバリッド情報を保持する単一の第１のエントリを有するとともに、前記第１のリターンアドレス演算部が算出した第１の戻り先アドレスと前記第１のバリッド情報生成部が生成した第１のバリッド情報を、前記第１のエントリに保持する戻り先アドレス記憶部と、」と補正したことにより、リターンアドレススタックＸ２４０が単一の第１のエントリのみを有することを明確にした。
　ここで、リターンアドレススタック２２０の先頭エントリにリターンアドレスをプッシュした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されているリターンアドレスについても深さ方向にそれぞれプッシュされ、リターンアドレススタック２２０の先頭エントリに保持されているリターンアドレスをポップした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されているリターンアドレスについても深さ方向とは反対方向にポップされることは、通常のスタックが行なう動作と同様であり、演算処理装置の分岐予測技術の分野における当業者の有する技術常識に該当する。
　『また、動作例として示されているものは、図面の「図７」で示されるプログラムを実行する場合に通常あり得るケースのごく一部のみに過ぎない。つまり、本願が特許法第３６条第４項第１号で規定される実施可能要件を満たすか否かを判断するためには、図面の「図７」で示されるプログラムを実行する場合に通常あり得るケースのそれぞれについて、明細書等に記載された実施例が正しく稼働することが、明細書等の記載から明確であるか否かを検証する必要がある。』旨の指摘に対しては、本願発明は、出願当初の明細書の発明の詳細な説明の段落「００５９」〜「００６１」及び図７の記載のように、正常に動作する「コール命令の検出→検出されたコール命令の実行→次のコール命令の検出→検出された次のコール命令の実行→リターン命令の検出」のケースが前提である。
　『Ａ．割り当て・定義
　リターンアドレススタック２２０（以下、単に「スタック」という。）の先頭エントリＳＴＫ０、２番目のエントリＳＴＫ１、３番目のエントリＳＴＫ２…にそれぞれ、リターンスタックポインタ２７０（以下、単に「ポインタ」という。）の二進数値”０００”、”００１”、”０１０”…を割り当てる。
　リターンアドレススタックＸ２４０（以下、単に、「スタックＸ」という。）の先頭エントリＳＴＫＸ−１、２番目のエントリＳＴＫＸ−２…にそれぞれ、ポインタの二進数値”１１１”、”１１０”…を割り当てる。
　ポインタの二進数値”０００”から１だけ減算されるときの二進数値を”１１１”と定義する。
　ポインタの二進数値”１１１”に１だけ加算するときの二進数値を”０００”と定義する。』の割り当て及び定義が必要である旨の指摘に対しては、請求項１の記載を
　「値がオール１である場合に前記第１のエントリを指定し、値がオール０である場合に前記複数の第２のエントリの先頭のエントリを指定するとともに、値がオール０から１ずつ増分する場合に前記複数の第２のエントリのうち前記先頭エントリから深さ方向に向かってエントリを１つずつ指定するポインタ情報を保持するとともに、前記分岐予測部が前記分岐履歴情報から検出したコール命令の実行が完了した場合又は前記分岐予測部が前記分岐履歴情報からリターン命令を検出した場合に、前記ポインタ情報に１を加算するとともに、前記分岐予測部が前記分岐履歴情報からコール命令を検出した場合又は前記分岐予測部が前記分岐履歴情報から検出したリターン命令の実行が完了した場合に前記ポインタ情報から１を減算し、値が前記オール１のポインタ情報に１を加算した場合には値が前記オール０のポインタ情報を生成するとともに、値が前記オール０のポインタ情報から１を減算した場合には値が前記オール１のポインタ情報を生成するポインタ部」と補正したことにより、リターンスタックポインタ２７０を指定するポインタ情報の値として”０００”、”００１”、”０１０”…を割り当てるとともに、リターンアドレススタックＸ２４０の先頭エントリＳＴＫＸ−１にポインタ情報の値”１１１”を割り当てるとともに、ポインタ情報の値”０００”から１だけ減算した場合の値が”１１１”であり、ポインタ値”１１１”に１だけ加算した場合の値が”０００”となることを明確にしたため、解消したものと思料する。
（ｂ−２）「３の２の１の２．明細書等に最低限必要な技術的事項が記載されているか否かの検討」について
　『上記の「Ｂ．動作」で示した各動作内容のうち、（１−ｂ−β）、（２−ｂ−α）、（２−ｂ−β）、（２−ｃ）、（３−ｃ）、（３−ｄ）及び（４−ｂ）の部分の動作内容は、明細書等には記載されていない。また、技術常識に基づいて、これらの動作内容が明細書等に記載されているに等しいというわけでもない。なお、平成２２年１０月２５日付け回答書において、審判請求人（出願人）は、明細書等に記載された実施例が上記の（２−ｂ−α）、（２−ｂ−β）の動作を行う旨の主張を行っているが、当該主張は明細書等の記載に基づくものではない。（なお、明細書の「００６８」の記載は、コール完了の際に、スタックに有効な戻り先アドレスが何もないときに、新たな戻り先アドレスをスタックの先頭エントリＳＴＫ０に置くことを示した程度のものであり、上記した（２−ｂ−α）、（２−ｂ−β）の動作を行う旨を示したものとはいえない。また、スタックが先入れ後出しのスタックバッファであるというだけでは、上記した（２−ｂ−α）、（２−ｂ−β）の動作を行うことが自明というわけではない。先入れ後出しのスタックバッファを実現するための手法はひとつとは限られないからである。）
　つまり、先行する命令が完了するタイミングと後続の命令の属性がブランチヒストリ（分岐予測部）にて検出されるタイミングの前後関係が不定であるパイプライン処理を行うという本願において前提とされる条件下で、本願図面の「図７」で示されるプログラムを実行する際において、明細書等に記載された実施例である、リターンアドレススタック２２０、リターンアドレススタックＸ２４０、リターンスタックポインタ２７０を備えた、分岐予測のためにリターン命令の戻り先アドレスを読み出す装置を、正常に稼働させるために最低限必要な技術的事項が、明細書等には開示されているとはいえない。よって、補正後の請求項１乃至１０に係る発明（及び、補正前の請求項１乃至１０に係る発明）を実施をすることができる程度に明確かつ十分に、明細書等が記載されているとはいえない。』旨の指摘については、
　　（２−ｂ−α）『格納先は常にスタックの先頭エントリＳＴＫ０である。』、及び、
　　（２−ｂ−β）『スタックに既に格納されている戻り先アドレスについては、ＳＴＫ０→ＳＴＫ１→ＳＴＫ２→…という形態でプッシュのようなエントリ間移動を行う。』
　のそれぞれについては、リターンアドレススタック２２０の先頭エントリにリターンアドレスをプッシュした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されているリターンアドレスについても深さ方向にそれぞれプッシュされ、リターンアドレススタック２２０の先頭エントリに保持されているリターンアドレスをポップした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されているリターンアドレスについても深さ方向とは反対方向にポップされることは、通常のスタックが行なう動作と同様であり、演算処理装置の分岐予測技術の分野における当業者の有する技術常識に該当する。
（ｂ−３）「３の２の１の３．明細書等の記載から類推されるいくつかの想定例の不具合」について
　『なお、上記した「Ｂ．動作」の（１−ｂ−β）、（２−ｃ）及び（３−ｄ）は、スタックＸが複数のエントリからなり、かつ、図面の「図７」で示されるプログラムを実行して、途中でコール完了が発生することなくコール検出が２回連続するケースなどで必要になる動作である。明細書等に記載された実施例においてはスタックＸが１つのみとなっているため、上記した「Ｂ．動作」の（１−ｂ−β）、（２−ｃ）及び（３−ｄ）について明細書等にて言及されていない。そのため、これらの部分については他の動作を行うことも考えられるが、その場合には、以下で例示するように、いずれもポインタが適切なエントリを指し示さなくなる。』については、
　　（１−ｂ−β）『スタックＸに既に格納されている戻り先アドレスについては、エントリ間移動をさせない。』、
　　（２−ｃ）『スタックＸに既に格納されている戻り先アドレスについては、…→ＳＴＫＸ−２→ＳＴＫＸ−１→破棄という形態でポップのようなエントリ間移動を行う。』、及び、
　　（３−ｄ）『上記（３−ｂ）にてスタックＸ内のエントリから戻り先アドレスを読み出した場合でも、スタックＸの既に格納されている戻り先アドレスについて、エントリ間移動はさせない。』
　のそれぞれについて、上記の（ｂ−１）の通り、請求項１の記載を、リターンアドレススタックＸ２４０が単一の第１のエントリのみを有することを明確にしたため、（２−ｃ）及び（３−ｄ）については考慮する必要が無い。
　そして、リターンアドレススタック２２０（戻り先アドレススタック）とリターンアドレススタックＸ２４０（戻り先アドレス記憶部）とは、同一のポインタ情報により制御されるが、リターンアドレススタック２２０（戻り先アドレススタック）とリターンアドレススタックＸ２４０（戻り先アドレス記憶部）とが全体として一つのスタックとして動作するものではなく、従って、単一の第１のエントリのみを有するリターンアドレススタックＸ２４０については、保持したリターンアドレスについてエントリ移動を行なうという概念が生じ得ないため、（１−ｂ−β）については考慮する必要が無い。
　『しかしながら、本願においてはスタックのみならずスタックＸについても先入れ後出しのスタックバッファであることを想定したものであるのだから、スタックＸについても複数のエントリがある場合にどのように動作させるべきであるのかが、明細書等に開示されていることが、特許法第３６条第４項第１号に規定される実施可能要件を満たすためには必要である。この点でも本願は実施可能要件を満たすものとはなっていない。』旨の指摘に対しては、上記の（ｂ−１）の通り、請求項１の記載を、リターンアドレススタックＸ２４０が単一の第１のエントリのみを有することを明確にしたため、解消したものと思料する。
（ｃ）理由２（特許法第３６条第６項第１号）について
（ｃ−１）『明細書等に記載された実施例においては、リターンアドレススタックＸ２４０のＳＴＫＸにリターンスタックポインタ２７０の二進数値”１１１”を割り当て、リターンアドレススタック２２０のＳＴＫ０、ＳＴＫ１、ＳＴＫ２、ＳＴＫ３にそれぞれリターンスタックポインタ２７０の二進数値”０００”、”００１”、”０１０”、”０１１”を割り当てた上で、リターンスタックポインタ２７０の二進数値”０００”から１だけ減算した値を二進数値”１１１”と定義し、リターンスタックポインタ２７０の二進数値”１１１”に１だけ加算した値を二進数値”０００”と定義している。これに対し、補正後の請求項１乃至１０には「ポインタ情報」に関する記載または「ポインタ情報」を加算または減算する旨の記載はあるものの、明細書等に記載された実施例における上記したような割り当てや定義が記載されていない。このように、補正後の請求項１乃至１０には、明細書の発明の詳細な説明に記載された、発明の課題を解決するための手段が正しく反映されているとはいえない。』旨の指摘に対しては、上記の（ｂ−１）の指摘と同様であり、請求項１の記載を補正したことにより、リターンスタックポインタ２７０を指定するポインタ情報の値として”０００”、”００１”、”０１０”…を割り当てるとともに、リターンアドレススタックＸ２４０の先頭エントリＳＴＫＸ−１にポインタ情報の値”１１１”を割り当てるとともに、ポインタ情報の値”０００”から１だけ減算した場合の値が”１１１”であり、ポインタ値”１１１”に１だけ加算した場合の値が”０００”となることを明確にしたため、解消したものと思料する。
…（中略）…
（ｄ）理由３（特許法第３６条第６項第２号）について
…（中略）…
（ｄ−２）『補正後の請求項１乃至１０には「ポインタ情報」に関する記載または「ポインタ情報」を加算または減算する旨の記載はあるものの、「ポインタ情報」により指し示されるべき（明細書等に記載された実施例における「リターンアドレススタックＸ２４０」に対応する）「第１の戻り先アドレス記憶部」の「第１のエントリ」や（明細書等に記載された実施例における「リターンアドレススタック２２０」に対応する）「第２の戻り先アドレス記憶部」の「第２のエントリ」において、戻り先アドレス等をどのように格納・移動・消去していくかが明確には記載されていない。そのため、補正後の請求項１乃至１０の記載では、結局のところ、「ポインタ情報」が指し示すものが何であるのかが明確でなく、また、補正後の請求項１乃至１０からまとまりのあるひとつの技術思想を捉えることが出来ない。』旨の指摘に対しては、上記の（ｃ−１）の指摘と同様であり、解消したものと思料する。」
　
第５．当審の判断
５の１．意見書における請求人の主張の概要
　上記「第４．請求人の意見書による主張」で示したもののうち、特許法第３６条第４項第１号に係る主張を整理すると次の３つの主張にまとめることができる。
　
・主張Ａ
　各請求項の記載において、「戻り先アドレス記憶部」（明細書等における「リターンアドレススタックＸ２４０」に相当する。）が単一の第１のエントリのみを有することを明確にした。
　そのため、拒絶理由通知書における『明細書等に記載された実施例の動作例においては、リターンスタックポインタ２７０の二進数値が”１１１”か”０００”のいずれかのみであり、かつ、リターンアドレススタックＸ２４０とリターンアドレススタック２２０において実質的に用いられるエントリはそれぞれ１つのみである。』との指摘は妥当でない。
　また、各請求項の記載において、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）が単一の第１のエントリのみを有することを明確にしたから、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）が複数のエントリを有する場合に要すると考えられる動作を本願明細書等において考慮する必要はない。特に、拒絶理由通知書における『（１）ブランチヒストリ（分岐予測部）にてコール命令を検出した（以下、単に「コール検出」という。）ときに行うべき動作は以下の（１−ａ）と（１−ｂ）である。…（中略）…（１−ｂ−β）スタックＸに既に格納されている戻り先アドレスについては、エントリ間移動をさせない。』で示される動作や、『（２）コール命令が完了した（以下、単に「コール完了」という。）ときに行うべき動作は以下の（２−ａ）、（２−ｂ）及び（２−ｃ）である。…（中略）…（２−ｃ）スタックＸに既に格納されている戻り先アドレスについては、…→ＳＴＫＸ−２→ＳＴＫＸ−１→破棄という形態でポップのようなエントリ間移動を行う。』で示される動作や、『（３）ブランチヒストリ（分岐予測部）にてリターン命令を検出した（以下、単に「リターン検出」という。）ときに行うべき動作は、以下の（３−ａ）、（３−ｂ）、（３−ｃ）及び（３−ｄ）である。…（中略）…（３−ｄ）上記（３−ｂ）にてスタックＸ内のエントリから戻り先アドレスを読み出した場合でも、スタックＸの既に格納されている戻り先アドレスについて、エントリ間移動はさせない。』で示される動作を、本願明細書等において考慮する必要はない。
　
・主張Ｂ
　各請求項における「戻り先アドレススタック」（明細書等における「リターンアドレススタック２２０」に相当する。）においては、先頭エントリに「戻り先アドレス」（明細書等における「リターンアドレス」に相当する。）をプッシュした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されている「戻り先アドレス」（リターンアドレス）についても深さ方向にそれぞれプッシュされ、「戻り先アドレススタック」（リターンアドレススタック２２０）の先頭エントリに保持されている「戻り先アドレス」（リターンアドレス）をポップした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されている「戻り先アドレス」（リターンアドレス）についても深さ方向とは反対方向にポップされるものである。このようなプッシュとポップの動作は、通常のスタックが行う動作と同様であり、分岐予測技術の分野における当業者の有する技術常識に該当する。
　そのため、拒絶理由通知書における『（２）コール命令が完了した（以下、単に「コール完了」という。）ときに行うべき動作は以下の（２−ａ）、（２−ｂ）及び（２−ｃ）である。…（中略）…（２−ｂ）スタックに戻り先アドレスを格納する。その際の詳細は（２−ｂ−α）と（２−ｂ−β）である。…（改行）…（２−ｂ−α）格納先は常にスタックの先頭エントリＳＴＫ０である。…（改行）…（２−ｂ−β）スタックに既に格納されている戻り先アドレスについては、ＳＴＫ０→ＳＴＫ１→ＳＴＫ２→…という形態でプッシュのようなエントリ間移動を行う。』で示される動作と同様の動作を、本願明細書等や本願の各請求項に係る発明においても行うことは自明である。
　
・主張Ｃ
　本願では、【図７】に示されるプログラムに適用するものであり、かつ、正常に動作するケース（当審注：意見書では、「コール命令の検出→検出されたコール命令の実行→次のコール命令の検出→検出された次のコール命令の実行→リターン命令の検出」のケースとしているが、明細書等で挙げられているものは、”コール命令の検出→検出されたコール命令の実行→次のコール命令の検出→リターン命令の検出→リターン命令の検出”、のケースである。）を前提としたものである。
　そのため、拒絶理由通知書における『また、動作例として示されているものは、図面の【図７】で示されるプログラムを実行する場合に通常あり得るケースのごく一部のみに過ぎない。つまり、本願が特許法第３６条第４項第１号で規定される実施可能要件を満たすか否かを判断するためには、図面の【図７】で示されるプログラムを実行する場合に通常あり得るケースのそれぞれについて、明細書等に記載された実施例が正しく稼働することが、明細書等の記載から明確であるか否かを検証する必要がある。』との指摘は妥当でない。
　
５の２．本願が特許法第３６条第４項第１号でいう実施可能要件を満たすための必要条件
　本願は、先行する命令が完了するタイミングと後続の命令の属性が「分岐予測部」（明細書等における「ブランチヒストリ」に相当する。）にて検出されるタイミングの前後関係が不定であるパイプライン処理を行うという本願において前提とされている条件下でも、プログラムを構成する各命令を先読みし実行する過程において「分岐予測部」（ブランチヒストリ）により先読み対象の命令がリターン命令であることを検出した際に、当該リターン命令に対応する適切な「戻り先アドレス」（リターンアドレス）を予測して、その予測した「戻り先アドレス」（リターンアドレス）の命令の先読みを行おうとするものである。そのため、本願が特許法第３６条第４項第１号でいう実施可能要件を満たすといえるためには、前述したタイミングの前後関係として通常あり得る各ケースについて、適切な「戻り先アドレス」（リターンアドレス）を予測できることが、明細書等の記載から明確でなければならない。
　なお、プログラム内における、コール命令やリターン命令により互いが関連付けられるメインルーチンとサブルーチンの関係は単純なものから複雑なものまで様々なものが想定できる。その様々な態様のプログラムのうち、少なくとも本願の図面の【図７】で示されるプログラムを実行する場合に通常あり得る各ケースについて、適切な「戻り先アドレス」（リターンアドレス）を予測できることが、明細書等の記載から明確であることが、本願が特許法第３６条第４項第１号でいう実施可能要件を満たすための必要条件（なお、十分条件とは必ずしもいえない。）である。
　ここで、本願の図面の【図７】で示されるプログラムは、メインルーチンからサブルーチンＡを呼出し、サブルーチンＡからサブルーチンＢを呼び出すものである。メインルーチンとサブルーチンＡの呼出し関係のために、メインルーチンにコール命令があり、サブルーチンＡにリターン命令がある。さらに、サブルーチンＡとサブルーチンＢの呼出し関係のために、サブルーチンＡにコール命令があり、サブルーチンＢにリターン命令がある。これらのコール命令とリターン命令について、各命令の「分岐予測部」（ブランチヒストリ）での検出タイミングと各命令の完了タイミングの前後関係は、（明細書等では要因について必ずしも明確に記されているわけではないが、一般的には、命令の先読み処理における実行時遅延、実行パイプラインにおける実行時遅延、各サブルーチンの有する命令数などの要因があるため、）不定である。
　上記したことを踏まえて、請求人の意見書における主張Ａ乃至Ｃについて、以下の５の３乃至５の５で検討する。
　
５の３．主張Ａについて
　本願の図面の【図７】で示されるプログラムを実行した場合において、メインルーチンからサブルーチンＡへのコール命令の検出→サブルーチンＡからサブルーチンＢへのコール命令の検出、というケース（つまり、メインルーチンからサブルーチンＡへのコール命令の完了より先に、サブルーチンＡからサブルーチンＢへのコール命令の検出が起こるケース）は、通常起こりうるものである。このケースでは「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）に本来記憶されるべき「戻り先アドレス」（リターンアドレス）は２つとなる。
　平成２３年１月２４日付け手続補正により、各請求項における「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）が有する「戻り先アドレス」（リターンアドレス）を格納するためのエントリは１つとなった。そのような１つのエントリしか有さない「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）を用いて、上記したような、本来記憶されるべき「戻り先アドレス」（リターンアドレス）が２つ以上となるケースに対して、どのように対処するのかが、明細書等に示されていることが、上記「５の２．本願が特許法第３６条第４項第１号でいう実施可能要件を満たすための必要条件」で示した必要条件を満たすためには必要である。
　しかしながら、そのような対処手法について明細書等には何ら示されていない。このように、上記「５の２．本願が特許法第３６条第４項第１号でいう実施可能要件を満たすための必要条件」で示した必要条件すら満たしていないものであるから、本願は特許法第３６条第４項第１号でいう実施可能要件を満たすものとはいえない。
　なお、請求人は意見書において、平成２３年１月２４日付け手続補正により、各請求項における「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）が有する「戻り先アドレス」（リターンアドレス）を格納するためのエントリは１つとなったのであるから、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）における「戻り先アドレス」（リターンアドレス）のエントリ間移動について考慮する必要がない旨を主張している。しかしながら、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）が有する「戻り先アドレス」（リターンアドレス）を格納するためのエントリは１つとなったとしても、なお、上記したような、本来記憶されるべき「戻り先アドレス」（リターンアドレス）が２つ以上となるケースに対して、どのように対処するのかを考慮しなければならないことには変わりはなく、同手続補正によっても、本願が特許法第３６条第４項第１号でいう実施可能要件を満たさないことにも変わりはない。よって、請求人の意見書による主張Ａは採用できない。
　
５の４．主張Ｂについて
　請求人は意見書において、スタックにおけるプッシュとポップの動作は技術常識であり、本願明細書等や本願の各請求項に係る発明における「戻り先アドレススタック」（リターンアドレススタック２２０）においてもプッシュとポップの動作については技術常識と同様である旨を主張している。
　しかしながら、明細書等において、単に、先入れ後出し（ＦＩＬＯ）のスタックであるとしているのみでは、スタックの外部からみたスタックとのデータ（本願の場合はここでのデータは「戻り先アドレス」（リターンアドレス）である。）の出し入れが先入れ後出し（ＦＩＬＯ）であることを意味するにとどまり、先入れ後出し（ＦＩＬＯ）を実現するためのスタック内部の構成や動作までは特定されるものではない。そして、先入れ後出し（ＦＩＬＯ）を実現するためのスタック内部の構成や動作としては、請求人が意見書で主張するようなもの以外にも様々なものが想定され、様々に想定される構成や動作のうちどのような構成や動作を採用するのかが、本願の明細書等の記載からは明らかでない。
　なお、本願の明細書の【００６８】の記載は、コール命令の完了の際に、「戻り先アドレススタック」（リターンアドレススタック２２０）に有効な「戻り先アドレス」（リターンアドレス）が何もないときに、新たな「戻り先アドレス」（リターンアドレス）を「戻り先アドレススタック」（リターンアドレススタック２２０）の先頭エントリＳＴＫ０に置くことを示した程度のものである。この【００６８】の記載が請求人が意見書で主張するような動作を指し示しているとまではいえない。
　
　さらに、請求人は意見書で「リターンアドレススタック２２０の先頭エントリに保持されているリターンアドレスをポップした場合は、先頭エントリから深さ方向にある２番目以降のエントリにそれぞれ保持されているリターンアドレスについても深さ方向とは反対方向にポップされる」とポップのようなエントリ間移動の動作について主張している。
　まず、前述した通り、この主張は本願の明細書等から導けるものではない。念のため言及すれば、「戻り先アドレススタック」（リターンアドレススタック２２０）においてポップのようなエントリ間移動を行うことは本願の明細書等には記載されていない。また、「戻り先アドレススタック」（リターンアドレススタック２２０）から「戻り先アドレス」（リターンアドレス）を読み出す際に、先頭エントリから必ず読み出すことは、本願の明細書等からは導き出せない。（仮に、先頭エントリから必ず読み出すのであれば、何のために、「ポインタ情報」（明細書等に記載された実施例における、「リターンスタックポインタ２７０」に相当する。）が存在するのかが不明となる。）
　さらに、この主張で示す動作、つまり、「分岐予測部」（ブランチヒストリ）がリターン命令を検出した場合に、「戻り先アドレススタック」（リターンアドレススタック２２０）から「戻り先アドレス」（リターンアドレス）を読み出して命令の先読み処理に用いるとともに、「戻り先アドレススタック」（リターンアドレススタック２２０）内において「戻り先アドレス」（リターンアドレス）のエントリ間移動をする、という動作を、本願明細書等が示していると仮定しても、このような仮定は、まさに、上記「第３．当審が通知した拒絶理由」において指摘した「想定例２」にそのまま該当するものであり、このような仮定のもとでは、本願において発明が解決しようとする課題とする、適切な「戻り先アドレス」（リターンアドレス）を予測することができないのは明らかである。
　
　このように、請求人の意見書における主張Ｂは、本願明細書等に根拠がない。また、請求人の意見書における主張Ｂが意味する構成を仮定しても、そのような構成によっては本願における発明が解決しようとする課題が解決できない。よって、請求人の意見書における主張Ｂを採用することはできない。
　
５の５．主張Ｃについて
　本願の明細書等においては、本願の図面の【図７】で示されるプログラムを実行して、メインルーチンからサブルーチンＡへのコール命令の検出→当該コール命令の完了→サブルーチンＡからサブルーチンＢへのコール命令の検出→サブルーチンＢからサブルーチンＡへのリターン命令の検出→サブルーチンＡからメインルーチンへのリターン命令の検出、となったケースのみが挙げられている。本願の図面の【図７】で示されるプログラムを実行する際には、上記で挙げられているケースには現れていない、サブルーチンＡからサブルーチンＢへのコール命令の完了、サブルーチンＢからサブルーチンＡへのリターン命令の完了の事象と、上記で挙げられている事象との間のタイミングの前後関係について、様々なケースがあり得るものであり、また、上記で挙げられている事象の間においてもタイミングの前後関係について、様々なケースがあり得るものである。本願の明細書等では、上記で挙げられたただ１つのケースのみが示されているのみであり、通常あり得る様々なケースにおいて、適切な「戻り先アドレス」（リターンアドレス）を予測できることを本願の明細書等が示しているとは到底いえない。よって、本願は、上記「５の２．本願が特許法第３６条第４項第１号でいう実施可能要件を満たすための必要条件」で示した必要条件すら満たしていないものであるから、特許法第３６条第４項第１号でいう実施可能要件を満たすものとはいえない。
　なお、請求人は意見書において、上記で挙げられたただ１つのケースを前提としている旨の主張をしていると考えられるが、本願の図面の【図７】で示されるプログラムを実行する際に、コール命令やリターン命令の検出や完了の時間的前後関係が上記で挙げられたただ１つのケースに必ずなるということが保証できるものではないから（仮に保証できるなら、（出願当初の明細書の【０００５】〜【００１０】の「サブルーチンからのリターン命令により分岐する場合、分岐先は、サブルーチンのコール命令の次の命令となる。だが、一般的に、サブルーチンはプログラムの各所から呼び出されるため、リターン命令の戻り先は一定ではない。したがって、過去の履歴にしたがって分岐先を予測しても、予測が正しいとは限らない。…（中略）…そこで、特許文献１では、サブルーチンのコール命令の実行時にリターン命令による戻り先のアドレスをリターンスアドレスタックに格納しておき、リターン命令については、ブランチヒストリよりリターンアドレススタックを優先して分岐予測をおこなうことで予測の精度を高める技術が開示されている。…（中略）…しかしながら、特許文献１に開示された技術は、コール命令の実行が完了した後にリターンスアドレスタックにそのコール命令に対応するリターン命令の戻り先のアドレスを格納するものであるため、命令列の先読み等により、コール命令の実行が完了する前にリターン命令がブランチヒストリによって検出された場合には、リターンスアドレスタックには戻り先のアドレスが格納されていないことになる。…（中略）…このように、特許文献１に開示された技術には、リターン命令の検出タイミングによっては分岐予測の精度が低下するという問題が含まれている。…（中略）…この発明は、上述した従来技術による問題点を解消するためになされたものであり、リターン命令による分岐先を高い精度で予測することができる分岐予測装置および分岐予測方法を提供することを目的とする。」という記載に示されるように、）コール命令やリターン命令の検出や完了の時間的前後関係がただ１つのケースに必ずなることが保証できないことを前提とした課題を本願が掲げている以上、本願の請求項１乃至１０に係る発明自体が前記課題に対応しないものとなる。）、請求人の意見書における主張Ｃは採用できない。
　
５の６．特許法第３６条第６項第２号に関する請求人の意見書における主張について
　上記「第３．当審が通知した拒絶理由」における「理由３」の「２．」に対して、請求人は意見書において、上記「第４．請求人の意見書による主張」の（ｄ−２）の項目にて示すように主張しており、当該主張においては上記「第４．請求人の意見書による主張」の（ｃ−１）の項目の内容を引用して拒絶理由が解消された旨を述べている。
　しかしながら、上記「第４．請求人の意見書による主張」の（ｃ−１）の項目は、「ポインタ情報」（リターンスタックポインタ２７０）の各値と「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）や「戻り先アドレススタック」（リターンアドレススタック２２０）の各エントリとの対応付けや、「ポインタ情報」（リターンスタックポインタ２７０）の値を加減算したときの取り決めに関して、各請求項の記載を明細書等に記載された実施例に即して明確化したことを示すのみである。この（ｃ−１）の項目は、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）や「戻り先アドレススタック」（リターンアドレススタック２２０）に、「戻り先アドレス」（リターンアドレス）等をどのように格納・移動・消去していくかが、各請求項において明確であることを主張するものではない。
　よって、上記「第４．請求人の意見書による主張」の（ｄ−２）の項目で引用される、（ｃ−１）の項目は、上記「第３．当審が通知した拒絶理由」における「理由３」の「２．」の拒絶理由を覆し得るものではない。
　
５の７．小括
　上記した５の２乃至５の５で示したように、請求人の意見書における主張Ａ乃至Ｃはいずれも採用することはできない。
　既に上記「第３．当審が通知した拒絶理由」や上記５の２乃至５の５で示したように、本願の明細書等に接した当業者にとって、実施可能な態様が明細書等に開示されていると認識できるものではない。このように本願の明細書等の記載は不完全なものと言わざるを得ず、本願の明細書等に接した当業者が実施可能な態様を想到するに至るまでに過度の試行錯誤を強いるものであり、上記「第３．当審が通知した拒絶理由」で示した、本願は特許法第３６条第４項第１号でいう実施可能要件を満たさない旨の判断は妥当なものである。
　
　また、上記した５の６で示したように、上記「第３．当審が通知した拒絶理由」における「理由３」の「２．」に対する、請求人の意見書における主張は採用することはできない。
　既に示した、本願が実施可能要件を満たさないことに関連して、各請求項において、「戻り先アドレス記憶部」（リターンアドレススタックＸ２４０）や「戻り先アドレススタック」（リターンアドレススタック２２０）に、「戻り先アドレス」（リターンアドレス）等をどのように格納・移動・消去していくかが明確には記載されていないのであるから、上記「第３．当審が通知した拒絶理由」で示した、本願は特許法第３６条第６項第２号の要件を満たさない旨の判断は、上記「第３．当審が通知した拒絶理由」における「理由３」の「２．」の限りにおいて、妥当なものである。
　
　このように、平成２３年１月２４日付け意見書及び手続補正を考慮したとしても、上記「第３．当審が通知した拒絶理由」で示される拒絶理由は依然として解消していない。
　
第６．むすび
　したがって、本願の請求項１乃至１０に関して、本願は特許法第３６条第４項第１号の要件を満たしておらず、特許を受けることができない。
　また、本願の請求項１乃至１０に関して、本願は特許法第３６条第６項第２号に規定する要件をみてしておらず、特許を受けることができない。
　
　よって、結論のとおり審決する。