【事件の表示】
　特願２００４−５５６４６２「マルチスレッディング・リサイクルおよびディスパッチ機構」拒絶査定不服審判事件〔平成１６年　６月１７日国際公開、ＷＯ２００４／０５１４６４、平成１８年　３月１６日国内公表、特表２００６−５０９２８２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　２００３年１０月２２日（パリ条約による優先権主張外国庁受理２００２年１２月５日、米国）を国際出願日とする出願であって、
　平成１７年８月２日付けで国際出願翻訳文提出書及び特許協力条約第３４条補正の翻訳文提出書が提出され、
　平成１９年１月１０日付けで最初の拒絶理由通知（同年同月１６日発送）がなされ、
　同年４月１１日付けで意見書が提出されるとともに、手続補正がなされ、
　平成２０年１月９日付けで拒絶査定（同年同月１５日発送）がなされ、
　同年４月１日付けで審判請求がされるとともに、手続補正がなされたものである。
　なお、同年５月２７日付けで審査官より前置報告がなされ、平成２２年２月２４日付けで当審より審尋（同年３月２日発送）がなされ、これに対して、同年４月１９日付けで回答書が提出されている。
　
第２．補正却下の決定
　[補正却下の決定の結論]
　平成２０年４月１日付けの手続補正を却下する。
　
　[理由]
１．本件補正
　平成２０年４月１日付けの手続補正（以下、「本件補正」という。）の内容は、
　平成１９年４月１１日付けの手続補正により補正された特許請求の範囲の記載
「　【請求項１】
　第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
　前記依存チェック論理が、
　前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップと、
　前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
　前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するステップと、
　前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、
を含む、前記の方法。
　　【請求項２】
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップが、前記依存命令を命令バッファに保持することを有する、請求項１に記載の方法。
　　【請求項３】
　前記命令ディスパッチ・ステージによって、前記依存命令を前記命令バッファに保持することを示す、請求項２に記載の方法。
　　【請求項４】
　前記命令ディスパッチ・ステージをリセットして、前記依存命令を前記命令バッファから解放することを示す、請求項３に記載の方法。
　　【請求項５】
　前記少なくとも１つの長いレイテンシ命令がロード・ミスである、請求項１に記載の方法。
　　【請求項６】
　前記少なくとも１つの長いレイテンシ命令がアドレス変換ミスである、請求項１に記載の方法。
　　【請求項７】
　前記少なくとも１つの長いレイテンシ命令が固定小数点複合命令である、請求項１に記載の方法。
　　【請求項８】
　前記少なくとも１つの長いレイテンシ命令が浮動小数点複合命令である、請求項１に記載の方法。
　　【請求項９】
　前記少なくとも１つの長いレイテンシ命令が浮動小数点非正規化命令である、請求項１に記載の方法。
　　【請求項１０】
　第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理手段とを有するインオーダー・マルチスレッディング・プロセッサであって、
　前記依存チェック論理手段が、
　前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するための手段と、
　前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするための手段と、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段と、
　前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するための手段と、
　前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするための手段と、を含む、インオーダー・マルチスレッディング・プロセッサ。
　　【請求項１１】
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段が、前記依存命令を命令バッファに保持するための手段を有する、請求項１０に記載のインオーダー・マルチスレッディング・プロセッサ。
　　【請求項１２】
　前記命令ディスパッチ・ステージによって、前記依存命令を前記命令バッファに保持することを示す、請求項１１に記載のインオーダー・マルチスレッディング・プロセッサ。
　　【請求項１３】
　前記命令ディスパッチ・ステージをリセットして、前記依存命令を前記命令バッファから解放することを示す、請求項１２に記載のインオーダー・マルチスレッディング・プロセッサ。
　　【請求項１４】
　前記少なくとも１つの長いレイテンシ命令がロード・ミスである、請求項１０に記載のインオーダー・マルチスレッディング・プロセッサ。
　　【請求項１５】
　第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるためのコンピュータ・プログラムであって、媒体において具現化され、前記依存チェック論理により実行される前記コンピュータ・プログラムが、
　前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するためのコンピュータ・プログラム・コードと、
　前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするためのコンピュータ・プログラム・コードと、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるためのコンピュータ・プログラム・コードと、
　前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するためのコンピュータ・プログラム・コードと、
　前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするためのコンピュータ・プログラム・コードと、
を含む、コンピュータ・プログラム。」
（以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。）を、
「　【請求項１】
　第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタと、
　第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタと、
　前記第1および第２の命令フェッチ・アドレス・レジスタに結合された命令キャッシュと、
　前記命令キャッシュに結合され、前記命令キャッシュから第１のスレッドを受信する第1の命令バッファと、
　前記命令キャッシュに結合され、前記命令キャッシュから第２のスレッドを受信する第２の命令バッファと、
　前記命令キャッシュならびに前記第１および第２の命令バッファに結合され、サイクル毎に第１のスレッドと第２のスレッドとを交番して一方を出力する命令ディスパッチ・ステージと、
　前記命令ディスパッチ・ステージに結合された第３のパイプライン・ステージを有する命令発行ステージと、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージに結合された依存チェック論理と、を有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
　前記依存チェック論理の実行が、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップと、
　前記第３のパイプライン・ステージから前記少なくとも１つの長いレイテンシ命令の後の前記依存命令が識別された場合に、前記依存命令をもっと前の前記第１の命令フェッチ・アドレス・レジスタに設けられた前記第１のパイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するステップと、
　前記少なくとも１つの長いレイテンシ命令の前記識別から前記完了までの実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージに設けられた前記第３のパイプライン・ステージにおいて発行することを可能とするステップと、
　を含む、前記の方法。
　　【請求項２】
　第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタと、
　第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタと、
　前記第１および第２の命令フェッチ・アドレス・レジスタに結合された命令キャッシュと、
　前記命令キャッシュに結合され、前記命令キャッシュから第１のスレッドを受信する第１の命令バッファと、
　前記命令キャッシュに結合され、前記命令キャッシュから第２のスレッドを受信する第２の命令バッファと、
　前記命令キャッシュならびに前記第１および第２の命令バッファに結合され、サイクル毎に第１のスレッドと第２のスレッドとを交番して一方を出力する命令ディスパッチ・ステージと、
　前記命令ディスパッチ・ステージに結合された第３のパイプライン・ステージを有する命令発行ステージと、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージに結合された依存チェック論理手段と、を有し、
　前記依存チェック論理手段が、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するための手段と、
　前記第３のパイプライン・ステージから前記少なくとも１つの長いレイテンシ命令の後の前記依存命令が識別された場合に、前記依存命令をもっと前の前記第１の命令フェッチ・アドレス・レジスタに設けられた前記第１のパイプライン・ステージに供給することによって前記依存命令をリサイクルするための手段と、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段と、
　前記命令発行ステージに設けられた前記第３のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するための手段と、
　前記少なくとも１つの長いレイテンシ命令の前記識別から前記完了までの実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージに設けられた前記第３のパイプライン・ステージにおいて発行することを可能とするための手段と、
　を含む、インオーダー・マルチスレッディング・プロセッサ。」
（以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。）
と補正するものである。
　
２．補正の適否
（１）特許法第１７条の２第３項に規定する要件についての検討
　本件補正は、少なくとも、補正前の請求項１にはなかった「第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタ」、「第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタ」という記載を追加し、補正前の請求項１における「前記依存命令をもっと前の前記パイプライン・ステージに供給する」という記載を「前記依存命令をもっと前の前記第１の命令フェッチ・アドレス・レジスタに設けられた前記第１のパイプライン・ステージに供給する」という記載に変更することにより、補正後の請求項１としたものである。
　しかしながら、「命令フェッチ・アドレス・レジスタ」が「パイプライン・ステージ」を有する旨の記載と「依存命令」を「第１の命令フェッチ・アドレス・レジスタに設けられた」「第１のパイプライン・ステージに供給する」旨の記載は、特許法第１８４条の８第４項の規定により誤訳訂正書を提出してされた手続補正とみなされる平成１７年８月２日付けの特許協力条約第３４条補正の翻訳文提出書による手続補正後の明細書又は特許請求の範囲、国際出願日における図面（図面の中の説明を除く。）、及び、平成１７年８月２日付けの国際出願翻訳文提出書における図面の中の説明の翻訳文には存在せず、そのような示唆も存在しない。また、明示の記載がなくとも、当業者において自明な事項であるとも認められない。そのため、本件補正は特許法第１８４条の１２第２項により読み替える、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反するものである。
（２）特許法第１７条の２第４項に規定する要件についての検討
　本件補正は、少なくとも、補正前の請求項１にはなかった「第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタ」、「第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタ」、「前記第1および第２の命令フェッチ・アドレス・レジスタに結合された命令キャッシュ」という記載を追加することにより、補正後の請求項１としたものである。
　しかしながら、上記した３つの追加された記載は、補正前の請求項１に記載された発明を特定するために必要な事項のいずれを限定したものとはいえない。特に、補正前の請求項１には「第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサ」と記載されているが、この記載における「第1の命令バッファ」、「第２の命令バッファ」、「命令ディスパッチ・ステージ」、「命令発行ステージ」及び「依存チェック論理」のいずれかを概念的により下位のものに限定したものであるとはいえず、上記した３つの追加された記載はむしろ、「第１の命令フェッチ・アドレス・レジスタ」、「第２の命令フェッチ・アドレス・レジスタ」及び「命令キャッシュ」を外的に付加するものである。よって、上記した３つの追加された記載について、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号に掲げられる目的を有するとはいえない。また、上記した３つの追加された記載について、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の他のいずれの号（第１号でいう請求項の削除、第３号でいう誤記の訂正、第４号でいう明りょうでない記載の釈明）に掲げられる目的を有するともいえない。そのため、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものである。
（３）特許法第３６条第６項第１号及び第２号に規定する要件についての検討
　上記（２）で示したように、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものであるが、仮に、本件補正が、同法第１７条の２第４項の規定に違反せず、本件補正が同法第１７条の２第４項第２号に掲げられる目的を有するものであるとして、独立特許要件を検討する。
　上記（１）で既に示したように、補正後の請求項１における「第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタ」、「第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタ」、「前記依存命令をもっと前の前記第１の命令フェッチ・アドレス・レジスタに設けられた前記第１のパイプライン・ステージに供給する」という記載は、平成１７年８月２日付けの特許協力条約第３４条補正の翻訳文提出書による手続補正後の明細書には存在せず、そのような示唆も存在しない。同翻訳文提出書による手続補正は明細書の全文を補正するものであり、同翻訳文提出書のあとで行われた手続補正では明細書の補正は行われていないから、補正後の請求項１における上記した３つの記載は、明細書の発明の詳細な説明に記載したものとはいえない。このように、本件補正は、特許法第３６条第６項第１号に違反するから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する。
　また、補正後の請求項１における「第１のスレッドに割り当てられた第１のパイプライン・ステージを有する第１の命令フェッチ・アドレス・レジスタ」、「第２のスレッドに割り当てられた第２のパイプライン・ステージを有する第２の命令フェッチ・アドレス・レジスタ」、「前記依存命令をもっと前の前記第１の命令フェッチ・アドレス・レジスタに設けられた前記第１のパイプライン・ステージに供給する」という記載は、あたかも、「命令フェッチ・アドレス・レジスタ」が「パイプライン・ステージ」を有し、その「命令フェッチ・アドレス・レジスタ」が有する「パイプライン・ステージ」に「依存命令」が供給されるかのように解釈されるものである。しかしながら、明細書等の記載を参酌しても、命令をフェッチするためのアドレス・レジスタがパイプライン・ステージを有するということの技術的な意味が明確でなく、また、アドレス・レジスタが有するパイプライン・ステージに命令が供給されるということの技術的な意味が明確でない。このように、本件補正は、特許法第３６条第６項第２号に違反するから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する。
（４）小括
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定に違反し、また、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　また、仮に本件補正が平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号に掲げられる目的を有するものであるとしても、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正却下の決定の結論のとおり決定する。
　
第３．本願発明の認定
　平成２０年４月１日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１９年４月１１日付けの手続補正により補正された、本願の特許請求の範囲の請求項１に記載されたとおりの次のものと認められる。
「第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
　前記依存チェック論理が、
　前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップと、
　前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
　前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
　前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するステップと、
　前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、
を含む、前記の方法。」
　
第４．引用発明の認定
　原審が拒絶理由通知において引用したBernard Goossens, Duc Thang Vu, Multithreading to Improve Cycle Width and CPI in Superpipelined Superscalar Processors, Proceedings of Second International Symposium on Parallel Architectures, Algorithms, and Networks, IEEE, １９９６年６月１２−１４日, Pages:36-42（以下、「引用例１」という。）には、図面とともに以下の技術事項が記載されている。
　
（１−１）
「This paper presents a multithreaded superpipelined superscalar processor design.」（第３６頁左欄第１行目〜同頁同欄第２行目、仮訳（当審にて訳出したものである。以下、同じ。）：この論文はマルチスレッド化されスーパーパイプライン化されたスーパースケーラプロセッサのデザインを提示するものである。）
　
（１−２）
「Operator sharing is used instead of out of order execution. It requires less hardware -no reservation stations, collision vectors or renamed registers- and should offer a great parallelism potential.」（第３６頁左欄第６行目〜同頁同欄第９行目、仮訳：アウトオブオーダー実行を行う代わりに、演算器の共有手法を用いる。これにより、必要なハードウェアを少なくすることができる。特に、リザベーションステーション、コリジョンベクター、リネームドレジスタは必要なくなる。そして、これにより、潜在的な処理の並列度が大きくなる。）
　
（１−３）
「Our contribution in this paper will be to propose to use multithreading as the  main technique to improve both the processor cycle width and its CPI. Multithreading is perfectly suited to achieve our goal because we will exhibit more parallelism by interleaving threads. The pipeline throughput will no more depend on complex out of order execution of a single thread but on the good sharing of the functional units among the on chips threads. It is of course easier to keep the units busy with multiple threads than with a single one.」（第３６頁右欄下から７行目〜第３７頁左欄第４行目、仮訳：この論文によって我々が果たす貢献は、マルチスレッドの手法を、プロセッササイクル幅とCPI[Cycles Per Instruction：１命令の実行に要するクロック数]の向上のために用いる主たる技術とすることを提案することにある。マルチスレッドの手法は我々の目的に完全に適している。なぜならば、複数のスレッドをインターリーブすることによって、より高い処理の並列度を得るからである。もはや１つのスレッドをアウトオブオーダー実行することに伴う複雑さには基づかずに、オンチップの複数のスレッド間で複数の処理ユニットを適切に共有する手法に基づいて、パイプラインの処理効率を得るようになる。もちろん、１つのスレッドによるよりも、複数のスレッドによるほうが、処理ユニットを稼働状態に保つようにすることが容易である。）
　
（１−４）
「The processor pipeline (see Fig. 2) is separated in three parts: the fetching part reads instruction cache blocks for four threads in parallel and stores all the opcodes to be run in four FIFOs; the issuing part selects FIFO opcodes to enter the operators pipelines; the executing part runs the selected opcodes and writes their results back in the register files.」（第３７頁右欄第６行目〜同頁同欄第１２行目、仮訳：プロセッサのパイプラインは３つのパートに分かれている（図２を参照のこと。）。フェッチパートは、４つのスレッドのために並行して、命令キャッシュからブロックを読み出し、実行されるオペコードの全てを４つのＦＩＦＯに格納する。発行パートは、ＦＩＦＯからオペコードを選択して、演算器のパイプラインに投入する。実行パートは、選択されたオペコードを実行し、実行結果をレジスタファイルに格納する。）
　
（１−５）
「Fetching is handled in four pipeline stages (see Fig.3). Each of them works in parallel on the four threads. The first stage reads the instruction cache block addressed by the current PC.」（第３７頁右欄第２０行目〜同頁同欄第２３行目、仮訳：フェッチは４つのパイプラインステージによって行われる（図３を参照のこと。）。４つのスレッドについて並行して行われる。最初のステージでは、命令キャッシュから、現在のＰＣ[プログラムカウンタ]により指し示されるブロックが読み出される。）
　
（１−６）
「If the current fetch has not been cancelled, the remaining instructions of the fetched block (the ones to be run) are latched in the thread's FIFO during the fourth stage.」（第３８頁左欄第９行目〜同頁同欄第１２行目、仮訳：現在のフェッチがキャンセルされなかったならば、フェッチされたブロック内の（実行される対象となる）残された複数の命令は、対応するスレッドのためのＦＩＦＯに、４番目のステージにおいてラッチされる。）
　
（１−７）
「The four FIFOs keep the ready to be run opcodes. Newly fetched opcodes are entered at the tail, while newly selected ones -see the next section concerning instruction issuing- are taken from the head. A third pointer limits the FIFO cells that may be overlapped. Issued instructions must be kept in the FIFO until they reach the execute stage after which they can no more be restarted (see the data cache miss handling in section 5).」（第３８頁右欄第４行目〜同頁同欄第１２行目、仮訳：４つのＦＩＦＯは、実行されるための準備ができている複数のオペコードを保持する。新たにフェッチされた複数のオペコードは[ＦＩＦＯの]末尾に入れられる。一方、新たに選択された複数のオペコードは[ＦＩＦＯの]先頭から取り出される（命令の発行に関する次のセクションを参照のこと。）。３番目のポインタは、オーバーラップされているＦＩＦＯのセルを限定する。発行された複数の命令が実行ステージに到達し、もはやリスタートされることがなくなるまで、発行された複数の命令はＦＩＦＯに保持される（セクション５のデータキャッシュミスの取り扱いを参照のこと。）。）
　
（１−８）
「Because many conflicts may be detected among the different ready to be run opecodes, instruction issuing is handled in four pipeline stages (see Fig.5). The first one (issue for thread i on Fig.5) selects opcodes from the highest priority thread FIFO. Only the 4 head entries (or all of them if less than 4 are used) are concerned. They are issued in order, which means that if an entry cannot be issued for a conflict reason, the following ones will not be issued either. Nevertheless, this leaves more chance to lower priority threads to issue their own instructions, thanks to multithreading. The three next stage select opcodes from the three other threads, in priority order.
 The four threads compete for operator attribution.」（第３８頁右欄下から１７行目〜同頁同欄下から第４行目、仮訳：実行されるための準備ができている複数の異なるオペコード間に多くの衝突が検出されることがありうるので、命令の発行制御は４つのパイプラインステージにより取り扱われる（図５を参照のこと。）。最初のパイプラインステージ（図５における”スレッドｉのための発行”）は最も高い優先度を有するスレッドのＦＩＦＯから複数のオペコードを選択する。先頭の４つのエントリのみ（もし、４つ未満しか使用されていなければ、その全てのエントリ。）が関係する。それらの複数のエントリはインオーダーに発行される。つまり、もしあるエントリがなんらかの衝突を理由に発行されることができないのであれば、後続する複数のエントリも発行することができない。それにも関わらず、マルチスレッドの手法を用いているおかげで、より低い優先度を有する複数のスレッドが自らの命令を発行する機会を多く得るようになる。３つの次のステージでは、優先度に基づき、３つの他のスレッドからオペコードが選択される。４つのスレッドは演算器の機能を確保することについて競い合う。）
　
（１−９）
「When an instruction needs a busy operator (already reserved by a higher priority thread or by a preceding instruction of the same thread issued in the same cycle), it is not selected for current issue.」（第３９頁左欄第４行目〜同頁同欄第８行目、仮訳：ある命令が稼働中のある演算器を必要とするならば（より優先度の高いスレッドか、または、同じサイクルで発行された同じスレッドの命令のうち先行する命令により、既に確保されているならば）、その命令は現時点の発行では選択されない。）
　
（１−１０）
「Two instructions belonging to the same thread may be conflictual for their source and destination registers (only Read After Write conflicts are concerned).」（第３９頁左欄第９行目〜同頁同欄第１１行目、仮訳：（リード・アフター・ライトの衝突に関する限り、）同じスレッドに属する２つの命令は、そのソースレジスタとデスティネーションレジスタに関して衝突するかもしれない。）
　
（１−１１）
「We state the 6 conditions an instruction must meet to be issued:
1.the preceding instruction has been issued;
2.none of the source registers are locked;
3.there are enough register file read and write ports free;
4.there are enough operators free;
5.if the instruction is a load, no other load or store has yet been issued for the same thread;
6.if the instruction is a store, no other store has yet been issued for the same thread and a store buffer is free.」（第３９頁右欄下から９行目〜第４０頁左欄第３行目、仮訳：命令が発行されるために満たさなければならない６つの条件を挙げる。１．先行する命令が発行されていること。２．ソースレジスタのうちでロックされているものがないこと。３．レジスタファイルのリードライトポートのうちフリーのものが充分にあること。４．演算器のうちフリーのものが充分にあること。５．命令がロードであるならば、同じスレッドに関して他のロードやストアが発行中ではないこと。６．命令がストアであるならば、同じスレッドに関して他のストアが発行中ではなく、かつ、ストアバッファがフリーであること。）
　
（１−１２）
「At the end of each of the four issue stages, the corresponding FIFO head pointer is updated according to the number of issued instructions. 」（第４０頁左欄第１４行目〜同頁同欄第１６行目、仮訳：４つの発行ステージのそれぞれの終わりで、発行された命令の数に応じて、対応するＦＩＦＯのヘッドポインターを更新する。）
　
（１−１３）
「The executing part is composed of 12 pipelines (one for each operator) each having 7 stages (see Fig.6).」（第４０頁左欄第３６行目〜同頁同欄第３７行目、仮訳：実行パートには、（各演算器毎に１つのパイプラインを備えられており、）７つのステージからなるパイプラインが１２個ある。）
　
（１−１４）
「The adders are used by memory access instructions. The data cache is read during the second stage, as soon as the address lower slice is ready. Tag check is performed in execute stage 5. The tag is latched at the end of execute stage 2.」（第４０頁左欄下から７行目〜同頁同欄下から２行目、仮訳：加算器はメモリアクセス命令にて用いられる。アドレスの下位部分が用意できたらすぐに、第２ステージにて、データキャッシュからの読み出しが行われる。実行ステージの第５ステージでタグチェックが行われる。実行ステージの第２ステージの終わりでタグはラッチされる。）
　
（１−１５）
「In case of a data cache miss, the load or store instruction will not be terminated with the write back stage. If the miss concerns a store, it only delays the write buffer unlock, which may suspend issuing for the same thread if all the buffers are busy and a store is pending for issue. If the miss is a load one, some instructions that have been issued after it may have been by-passed a wrong datum. They must be cancelled and restarted. Of course, independent instructions are not concerned. This is the case for the ones issued one cycle after the offending load. These are surely independent, otherwise their issue would have been delayed by the load delay field locking their destination register. The load itself need not be restarted because it can be achieved by the miss handling logic. Neither do the instructions issued with it which are also surely independent.
 To restart instructions, the FIFO head pointer is moved to match the overlapping limit, re-including in the non-issued part the opcodes to re-issue. All the instructions in the execute pipeline stages x1 to x3 must be cancelled. Moreover, the instruction already issued for the same thread (but not yet executed) must also be cancelled. Issue is stopped for the thread concerned by the miss.」（第４０頁右欄第１３行目〜第４１頁左欄第１２行目、仮訳：データキャッシュがミスするケースでは、ロード命令やストア命令はライトバックステージにおいて完了しない。ストアミスの場合、ライトバッファのロック解除が遅れるだけであり、このことは、全てのバッファがビジーであり、かつ、ストア命令が発行を待っている状況において、同じスレッドからの発行を停止させうる。ロードミスの場合、ロードミスした命令の後の命令であり、既に発行されている命令のいくつかについては、誤った情報が渡されているかもしれない。そのようないくつかの命令はキャンセルされリスタートされなければならない。もちろん、[ロードミスした命令に対し]独立した複数の命令は関係しない。違反したロードの１サイクル後に発行された複数の命令がそのケースである。これらの命令は確実に独立である。さもなければ、それらの命令は、デスティネーションレジスタをロックするためのロードディレイフィールドにより、それらの命令は遅らされていたであろう。[ロードミスした]ロード命令自体はリスタートされる必要はない。なぜならば、ミスハンドリングロジックにより[ロードミスした]ロードは為し遂げられるからである。[ロードミスした]ロード命令とともに発行され、かつ、確実に独立な複数の命令も同様にリスタートされる必要はない。命令をリスタートするために、オーバーラップの限界値に合うように、ＦＩＦＯのヘッドポインターは移動され、再発行すべき複数のオペコードを[ＦＩＦＯの]未発行パートに再び含むようにする。実行パイプラインのステージx1からx3までにある全ての命令をキャンセルする。さらに、同じスレッドの命令のうち、既に発行され、かつ、まだ実行されていない命令もキャンセルされる。[ロード]ミスに関連するスレッドについて、発行は停止される。）
　
　上記（１−４）及び（１−６）の記載事項から、引用例１における、４つのＦＩＦＯは命令キャッシュから読み出された命令（オペコード）を格納するものであり、個々のＦＩＦＯはそれぞれ別々のスレッドに割り当てられているものであると認められる。
　
　上記（１−４）及び（１−８）の記載事項から、引用例１における発行パートは、パイプラインステージを有しており、４つのＦＩＦＯに結合され、４つのＦＩＦＯから命令（オペコード）を選択して取り出すものであり、選択されて取り出された命令（オペコード）について実行パートの演算器に発行する制御を行うものであると認められる。
　
　上記（１−４）及び（１−８）の記載事項から、上記（１−８）の記載事項に示される命令の発行制御は引用例１における発行パートが行うものであると認められる。特に、上記（１−８）の記載事項から、引用例１における発行パートでは、異なる命令（オペコード）間の衝突が検出されるものであり、何らかの衝突検出論理を有すると認められる。
　
　上記（１−２）、（１−３）、（１−８）及び（１−１１）の記載事項から、引用例１におけるプロセッサは、同じスレッドの各命令（オペコード）についてはインオーダー発行を行うものであると認められる。
　
　上記（１−１）、（１−３）及び（１−８）の記載事項から、引用例１におけるプロセッサは、あるスレッドの命令（オペコード）の発行ができなければ、他のスレッドの命令（オペコード）の発行を行うようにする、マルチスレッドの手法を用いるものであると認められる。
　
　上記（１−１５）の記載事項から、引用例１においては、データキャッシュからのロードミスが発生した場合に、そのロードミスが発生したスレッドについては命令の発行が停止されるものであると認められる。
　
、上記（１−１５）の記載事項から、引用例１においては、データキャッシュからのロードミスが発生した命令（オペコード）の後の命令であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別し、そのような命令（オペコード）については、ＦＩＦＯからリスタートされるものであると認められる。
　
　上記引用例１発明の記載事項及び図面を総合勘案すると、引用例１には、次の発明（以下、「引用例１発明」という。）が記載されていると認められる。
　
「スレッドのための命令を格納するために割り当てられたＦＩＦＯをスレッド毎に備え、それぞれのＦＩＦＯに結合され、それぞれのＦＩＦＯから取り出された命令を実行パートに発行し、衝突検出論理を有し、パイプライン・ステージを有する発行パートを備える、インオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
　あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップと、
　識別された命令をＦＩＦＯからリスタートさせるステップと、
　当該あるスレッドの命令の発行を停止するステップと、
　当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップと、を含む方法。」
　
第５．対比
　本願発明と引用例１発明とを比較する。
　
　引用例１発明のそれぞれの「ＦＩＦＯ」は、「スレッド毎」に割り当てられたものであり、かつ、対応するスレッドのための「命令」を格納するものであるから、引用例１発明のそれぞれのスレッドに対応する「ＦＩＦＯ」は、本願発明の「第１の命令バッファ」、「第２の命令バッファ」に相当する。
　
　引用例１発明の「発行パート」は、スレッド毎のＦＩＦＯ（命令バッファ）に結合され、スレッド毎のＦＩＦＯ（命令バッファ）から命令を取り出すものである点では、本願発明の「命令ディスパッチ・ステージ」に一致するものである。また、引用例１発明の「発行パート」は、パイプライン・ステージを有し、命令の発行の制御を行うものである点では、本願発明の「命令発行ステージ」に一致するものである。
　
　上記（１−８）及び（１−１０）の記載事項から、引用例１における「衝突」は複数の命令（オペコード）間で検出されるものであり、その検出の際に考慮する対象として命令のソースレジスタやデスティネーションレジスタが含まれるものであり、しかも、「衝突」が生じたことを理由として命令（オペコード）の発行ができなくなることもあるのであるから、引用例１において「衝突」を「検出」することは、複数の命令（オペコード）間の依存関係をチェックすることである。そのため、引用例１発明の「衝突検出論理」は、複数の命令の間で衝突をチェックするという点で、本願発明における「依存チェック論理」に一致する。
　
　本願発明における「長いレイテンシ命令」とは、その命令を完了するまでにかかる時間が「長いレイテンシ命令」でない命令よりも比較的長い命令である。本願の明細書の【００１７】には命令が「長いレイテンシ命令」となるケースのひとつとして、データ・キャッシュＤＣＡＣＨＥにおけるロード・ミスが挙げられている。これらのことを考慮すると、引用例１発明における「データキャッシュにおいてロードミスとなった」「命令」は、本願発明における「少なくとも１つの長いレイテンシ命令」に相当する。
　
　引用例１発明における「データキャッシュにおいてロードミスとなった」「命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」は、長いレイテンシ命令である「データキャッシュにおいてロードミスとなった」「命令」と何らかの依存関係があることが原因で、「リスタートされなければ誤った情報が渡されている危険性がある」ことは自明である。そのため、引用例１発明における「データキャッシュにおいてロードミスとなった」「命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」は、長いレイテンシ命令の後であり、かつ、長いレイテンシ命令と依存関係がある点で、本願発明における「依存命令」に一致する。
　
　引用例１発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をＦＩＦＯからリスタートさせる」ことは、リスタートすべきであるとされた命令を、ＦＩＦＯから発行パートのパイプライン・ステージに再び供給することを意味する。ところで、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」における「前記パイプライン・ステージ」は、「命令発行ステージ」が有する「パイプライン・ステージ」を指し示すものであるから、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」とは、依存命令を、命令発行ステージが有する、もっと前のパイプライン・ステージに供給することによって、依存命令をリサイクルすることを意味する。つまり、引用例１発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をＦＩＦＯからリスタートさせる」ことは、長いレイテンシ命令に依存する命令を命令発行の制御を行うパイプライン・ステージに供給してリサイクルすることである点で、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」ことに一致する。
　
　引用例１発明における、「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令の発行を停止する」ことと、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をＦＩＦＯからリスタートさせる」ことをあわせることにより、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」がＦＩＦＯから再び発行されることが遅延されるものであるから、引用例１発明における「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令の発行を停止する」ことと、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をＦＩＦＯからリスタートさせる」ことをあわせたものは、長いレイテンシ命令に依存する命令のディスパッチを遅延させるものである点で、本願発明における「前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させる」ことに一致する。
　
　引用例１発明における「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行する」ことは、長いレイテンシ命令を実行している間に、代替的なスレッドの命令を発行することである点で、本願発明における「前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とする」ことに一致する。
　
　すると、本願発明と引用例１発明とは、次の点で一致する。
　
＜一致点＞
　第１のスレッドに割り当てられた第1の命令バッファと、第２のスレッドに割り当てられた第２の命令バッファと、前記第１および第２の命令バッファにそれぞれ結合され、パイプライン・ステージを有し、依存チェック論理を有する、命令ディスバッチと命令発行を行うステージを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
　前記第１のスレッドからの少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップと、
　前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
　前記依存命令のディスパッチを遅延させるステップと、
　前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を発行することを可能とするステップと、
を含む、前記の方法。
　
　一方で、両者は、次の点で相違する。
　
＜相違点１＞
　本願発明は「前記第１および第２の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有する」のに対し、引用例１発明は、「それぞれのＦＩＦＯに結合され、それぞれのＦＩＦＯから取り出された命令を実行パートに発行し、衝突検出論理を有し、パイプライン・ステージを有する発行パートを備える」点。これに関連して、本願発明は「前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップ」を有するのに対し、引用例１発明は「当該あるスレッドの命令の発行を停止するステップ」を有する点。さらに、本願発明は「前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップ」を有するのに対し、引用例１発明は「当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップ」を有する点。
　つまり、命令のディスパッチと命令の発行に関連し、本願発明は「命令ディスパッチ・ステージ」と「命令発行ステージ」という２つのステージを有するのに対し、引用例１発明は「発行パート」という１つのステージを有する点。
　
＜相違点２＞
　本願発明は「前記依存チェック論理」が、「前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップと、前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するステップと、前記少なくとも１つの長いレイテンシ命令を実行している間に、代替的なスレッドが１つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、を含む、」ものであるのに対し、引用例１発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップと、識別された命令をＦＩＦＯからリスタートさせるステップと、当該あるスレッドの命令の発行を停止するステップと、当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップと」を実行する主体が明確でない点。
　
＜相違点３＞
　本願発明は「前記第１のスレッドからのレジスタ依存によって少なくとも１つの長いレイテンシ命令の後の依存命令を識別するステップ」を有するのに対し、引用例１発明は「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップ」を有するものの、引用例１発明における「データキャッシュにおいてロードミスとなった」「命令」と「リスタートされなければ誤った情報が渡されている危険性がある命令」との間の依存関係がレジスタ依存であるのかが明確でない点。
　
＜相違点４＞
　本願発明は「前記第１のスレッドから前記少なくとも１つの長いレイテンシ命令の完了を検出するステップ」を有するのに対し、引用例１発明が「データキャッシュにおいてロードミスとなった」「命令」の完了を検出するものであるのか否かが、引用例１には記載されていない点。
　
第６．判断
　そこで、上記相違点について検討する。
　
・相違点１について
　上記（１−４）及び（１−８）の記載事項から、引用例１発明の「実行パート」は、ＦＩＦＯから命令をディスパッチし、ディスパッチした命令について発行制御を行うものであり、「実行パート」はパイプライン・ステージを有するものである。この「実行パート」における、ＦＩＦＯから命令をディスパッチするまでの処理と、ディスパッチした後の命令の発行制御の処理とを分離して、２つのステージとするように設計変更を行うことは、当業者が容易になし得たことである。
　
・相違点２について
　引用例１発明の「衝突検出論理」は（既に、”第５．対比”にて示したように、）複数の命令の間で衝突（依存）関係をチェックするものであるから、引用例１発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップ」、「識別された命令をＦＩＦＯからリスタートさせるステップ」及び「当該あるスレッドの命令の発行を停止するステップと、当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップ」に示される、命令間の衝突（依存）関係に基づく処理も、引用例１発明における「衝突検出論理」で実行するようにすることは、当業者が容易になし得たことである。
　
・相違点３について
　上記（１−１０）の記載事項からも示されるように、命令間の衝突（依存）関係としてレジスタ依存があることは当業者には周知である。そのため、引用例１発明における依存関係の識別をレジスタ依存に基づいて行うようにすることは、当業者が容易になし得たことである。
　
・相違点４について
　引用例１発明において、ある命令がデータキャッシュにおいてロードミスとなったために命令の発行が停止されたスレッドについて、命令の発行を再開するための最低限の条件が、ロードミスとなったデータのロードが完了した時であることは当業者には自明のことであることを考えれば、そのような最低限の条件が成立したか否かを知るべく、ロードミスとなった命令の完了を検出するようにすることは、当業者が容易になし得たことである。
　
　また、本願発明が有する作用効果は、引用例１発明から当業者が予測できた範囲内のものである。
　
　よって、本願発明は、引用例１発明に基いて、当業者が容易に発明をすることができたものである。
　
第７．むすび
　したがって、本願の請求項１に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。