• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 特174条1項 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない。 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G06F
管理番号 1227058
審判番号 不服2008-7846  
総通号数 133 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2011-01-28 
種別 拒絶査定不服の審決 
審判請求日 2008-04-01 
確定日 2010-11-10 
事件の表示 特願2004-556462「マルチスレッディング・リサイクルおよびディスパッチ機構」拒絶査定不服審判事件〔平成16年 6月17日国際公開、WO2004/051464、平成18年 3月16日国内公表、特表2006-509282〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、
2003年10月22日(パリ条約による優先権主張外国庁受理2002年12月5日、米国)を国際出願日とする出願であって、
平成17年8月2日付けで国際出願翻訳文提出書及び特許協力条約第34条補正の翻訳文提出書が提出され、
平成19年1月10日付けで最初の拒絶理由通知(同年同月16日発送)がなされ、
同年4月11日付けで意見書が提出されるとともに、手続補正がなされ、
平成20年1月9日付けで拒絶査定(同年同月15日発送)がなされ、
同年4月1日付けで審判請求がされるとともに、手続補正がなされたものである。
なお、同年5月27日付けで審査官より前置報告がなされ、平成22年2月24日付けで当審より審尋(同年3月2日発送)がなされ、これに対して、同年4月19日付けで回答書が提出されている。

第2.補正却下の決定
[補正却下の決定の結論]
平成20年4月1日付けの手続補正を却下する。

[理由]
1.本件補正
平成20年4月1日付けの手続補正(以下、「本件補正」という。)の内容は、
平成19年4月11日付けの手続補正により補正された特許請求の範囲の記載
「 【請求項1】
第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
前記依存チェック論理が、
前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップと、
前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するステップと、
前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、
を含む、前記の方法。
【請求項2】
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップが、前記依存命令を命令バッファに保持することを有する、請求項1に記載の方法。
【請求項3】
前記命令ディスパッチ・ステージによって、前記依存命令を前記命令バッファに保持することを示す、請求項2に記載の方法。
【請求項4】
前記命令ディスパッチ・ステージをリセットして、前記依存命令を前記命令バッファから解放することを示す、請求項3に記載の方法。
【請求項5】
前記少なくとも1つの長いレイテンシ命令がロード・ミスである、請求項1に記載の方法。
【請求項6】
前記少なくとも1つの長いレイテンシ命令がアドレス変換ミスである、請求項1に記載の方法。
【請求項7】
前記少なくとも1つの長いレイテンシ命令が固定小数点複合命令である、請求項1に記載の方法。
【請求項8】
前記少なくとも1つの長いレイテンシ命令が浮動小数点複合命令である、請求項1に記載の方法。
【請求項9】
前記少なくとも1つの長いレイテンシ命令が浮動小数点非正規化命令である、請求項1に記載の方法。
【請求項10】
第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理手段とを有するインオーダー・マルチスレッディング・プロセッサであって、
前記依存チェック論理手段が、
前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するための手段と、
前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするための手段と、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段と、
前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するための手段と、
前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするための手段と、を含む、インオーダー・マルチスレッディング・プロセッサ。
【請求項11】
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段が、前記依存命令を命令バッファに保持するための手段を有する、請求項10に記載のインオーダー・マルチスレッディング・プロセッサ。
【請求項12】
前記命令ディスパッチ・ステージによって、前記依存命令を前記命令バッファに保持することを示す、請求項11に記載のインオーダー・マルチスレッディング・プロセッサ。
【請求項13】
前記命令ディスパッチ・ステージをリセットして、前記依存命令を前記命令バッファから解放することを示す、請求項12に記載のインオーダー・マルチスレッディング・プロセッサ。
【請求項14】
前記少なくとも1つの長いレイテンシ命令がロード・ミスである、請求項10に記載のインオーダー・マルチスレッディング・プロセッサ。
【請求項15】
第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるためのコンピュータ・プログラムであって、媒体において具現化され、前記依存チェック論理により実行される前記コンピュータ・プログラムが、
前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するためのコンピュータ・プログラム・コードと、
前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするためのコンピュータ・プログラム・コードと、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるためのコンピュータ・プログラム・コードと、
前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するためのコンピュータ・プログラム・コードと、
前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするためのコンピュータ・プログラム・コードと、
を含む、コンピュータ・プログラム。」
(以下、この特許請求の範囲に記載された請求項を「補正前の請求項」という。)を、
「 【請求項1】
第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタと、
第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタと、
前記第1および第2の命令フェッチ・アドレス・レジスタに結合された命令キャッシュと、
前記命令キャッシュに結合され、前記命令キャッシュから第1のスレッドを受信する第1の命令バッファと、
前記命令キャッシュに結合され、前記命令キャッシュから第2のスレッドを受信する第2の命令バッファと、
前記命令キャッシュならびに前記第1および第2の命令バッファに結合され、サイクル毎に第1のスレッドと第2のスレッドとを交番して一方を出力する命令ディスパッチ・ステージと、
前記命令ディスパッチ・ステージに結合された第3のパイプライン・ステージを有する命令発行ステージと、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージに結合された依存チェック論理と、を有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
前記依存チェック論理の実行が、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップと、
前記第3のパイプライン・ステージから前記少なくとも1つの長いレイテンシ命令の後の前記依存命令が識別された場合に、前記依存命令をもっと前の前記第1の命令フェッチ・アドレス・レジスタに設けられた前記第1のパイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するステップと、
前記少なくとも1つの長いレイテンシ命令の前記識別から前記完了までの実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージに設けられた前記第3のパイプライン・ステージにおいて発行することを可能とするステップと、
を含む、前記の方法。
【請求項2】
第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタと、
第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタと、
前記第1および第2の命令フェッチ・アドレス・レジスタに結合された命令キャッシュと、
前記命令キャッシュに結合され、前記命令キャッシュから第1のスレッドを受信する第1の命令バッファと、
前記命令キャッシュに結合され、前記命令キャッシュから第2のスレッドを受信する第2の命令バッファと、
前記命令キャッシュならびに前記第1および第2の命令バッファに結合され、サイクル毎に第1のスレッドと第2のスレッドとを交番して一方を出力する命令ディスパッチ・ステージと、
前記命令ディスパッチ・ステージに結合された第3のパイプライン・ステージを有する命令発行ステージと、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージに結合された依存チェック論理手段と、を有し、
前記依存チェック論理手段が、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するための手段と、
前記第3のパイプライン・ステージから前記少なくとも1つの長いレイテンシ命令の後の前記依存命令が識別された場合に、前記依存命令をもっと前の前記第1の命令フェッチ・アドレス・レジスタに設けられた前記第1のパイプライン・ステージに供給することによって前記依存命令をリサイクルするための手段と、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるための手段と、
前記命令発行ステージに設けられた前記第3のパイプライン・ステージから、前記サイクル毎に交番して出力される一方の前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するための手段と、
前記少なくとも1つの長いレイテンシ命令の前記識別から前記完了までの実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージに設けられた前記第3のパイプライン・ステージにおいて発行することを可能とするための手段と、
を含む、インオーダー・マルチスレッディング・プロセッサ。」
(以下、この特許請求の範囲に記載された請求項を「補正後の請求項」という。)
と補正するものである。

2.補正の適否
(1)特許法第17条の2第3項に規定する要件についての検討
本件補正は、少なくとも、補正前の請求項1にはなかった「第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタ」、「第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタ」という記載を追加し、補正前の請求項1における「前記依存命令をもっと前の前記パイプライン・ステージに供給する」という記載を「前記依存命令をもっと前の前記第1の命令フェッチ・アドレス・レジスタに設けられた前記第1のパイプライン・ステージに供給する」という記載に変更することにより、補正後の請求項1としたものである。
しかしながら、「命令フェッチ・アドレス・レジスタ」が「パイプライン・ステージ」を有する旨の記載と「依存命令」を「第1の命令フェッチ・アドレス・レジスタに設けられた」「第1のパイプライン・ステージに供給する」旨の記載は、特許法第184条の8第4項の規定により誤訳訂正書を提出してされた手続補正とみなされる平成17年8月2日付けの特許協力条約第34条補正の翻訳文提出書による手続補正後の明細書又は特許請求の範囲、国際出願日における図面(図面の中の説明を除く。)、及び、平成17年8月2日付けの国際出願翻訳文提出書における図面の中の説明の翻訳文には存在せず、そのような示唆も存在しない。また、明示の記載がなくとも、当業者において自明な事項であるとも認められない。そのため、本件補正は特許法第184条の12第2項により読み替える、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項の規定に違反するものである。
(2)特許法第17条の2第4項に規定する要件についての検討
本件補正は、少なくとも、補正前の請求項1にはなかった「第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタ」、「第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタ」、「前記第1および第2の命令フェッチ・アドレス・レジスタに結合された命令キャッシュ」という記載を追加することにより、補正後の請求項1としたものである。
しかしながら、上記した3つの追加された記載は、補正前の請求項1に記載された発明を特定するために必要な事項のいずれを限定したものとはいえない。特に、補正前の請求項1には「第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサ」と記載されているが、この記載における「第1の命令バッファ」、「第2の命令バッファ」、「命令ディスパッチ・ステージ」、「命令発行ステージ」及び「依存チェック論理」のいずれかを概念的により下位のものに限定したものであるとはいえず、上記した3つの追加された記載はむしろ、「第1の命令フェッチ・アドレス・レジスタ」、「第2の命令フェッチ・アドレス・レジスタ」及び「命令キャッシュ」を外的に付加するものである。よって、上記した3つの追加された記載について、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号に掲げられる目的を有するとはいえない。また、上記した3つの追加された記載について、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の他のいずれの号(第1号でいう請求項の削除、第3号でいう誤記の訂正、第4号でいう明りょうでない記載の釈明)に掲げられる目的を有するともいえない。そのため、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するものである。
(3)特許法第36条第6項第1号及び第2号に規定する要件についての検討
上記(2)で示したように、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するものであるが、仮に、本件補正が、同法第17条の2第4項の規定に違反せず、本件補正が同法第17条の2第4項第2号に掲げられる目的を有するものであるとして、独立特許要件を検討する。
上記(1)で既に示したように、補正後の請求項1における「第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタ」、「第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタ」、「前記依存命令をもっと前の前記第1の命令フェッチ・アドレス・レジスタに設けられた前記第1のパイプライン・ステージに供給する」という記載は、平成17年8月2日付けの特許協力条約第34条補正の翻訳文提出書による手続補正後の明細書には存在せず、そのような示唆も存在しない。同翻訳文提出書による手続補正は明細書の全文を補正するものであり、同翻訳文提出書のあとで行われた手続補正では明細書の補正は行われていないから、補正後の請求項1における上記した3つの記載は、明細書の発明の詳細な説明に記載したものとはいえない。このように、本件補正は、特許法第36条第6項第1号に違反するから、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する。
また、補正後の請求項1における「第1のスレッドに割り当てられた第1のパイプライン・ステージを有する第1の命令フェッチ・アドレス・レジスタ」、「第2のスレッドに割り当てられた第2のパイプライン・ステージを有する第2の命令フェッチ・アドレス・レジスタ」、「前記依存命令をもっと前の前記第1の命令フェッチ・アドレス・レジスタに設けられた前記第1のパイプライン・ステージに供給する」という記載は、あたかも、「命令フェッチ・アドレス・レジスタ」が「パイプライン・ステージ」を有し、その「命令フェッチ・アドレス・レジスタ」が有する「パイプライン・ステージ」に「依存命令」が供給されるかのように解釈されるものである。しかしながら、明細書等の記載を参酌しても、命令をフェッチするためのアドレス・レジスタがパイプライン・ステージを有するということの技術的な意味が明確でなく、また、アドレス・レジスタが有するパイプライン・ステージに命令が供給されるということの技術的な意味が明確でない。このように、本件補正は、特許法第36条第6項第2号に違反するから、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する。
(4)小括
したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項の規定に違反し、また、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
また、仮に本件補正が平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号に掲げられる目的を有するものであるとしても、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって、上記補正却下の決定の結論のとおり決定する。

第3.本願発明の認定
平成20年4月1日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成19年4月11日付けの手続補正により補正された、本願の特許請求の範囲の請求項1に記載されたとおりの次のものと認められる。
「第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
前記依存チェック論理が、
前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップと、
前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、
前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するステップと、
前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、
を含む、前記の方法。」

第4.引用発明の認定
原審が拒絶理由通知において引用した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, 1996年6月12-14日, Pages:36-42(以下、「引用例1」という。)には、図面とともに以下の技術事項が記載されている。

(1-1)
「This paper presents a multithreaded superpipelined superscalar processor design.」(第36頁左欄第1行目?同頁同欄第2行目、仮訳(当審にて訳出したものである。以下、同じ。):この論文はマルチスレッド化されスーパーパイプライン化されたスーパースケーラプロセッサのデザインを提示するものである。)

(1-2)
「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.」(第36頁左欄第6行目?同頁同欄第9行目、仮訳:アウトオブオーダー実行を行う代わりに、演算器の共有手法を用いる。これにより、必要なハードウェアを少なくすることができる。特に、リザベーションステーション、コリジョンベクター、リネームドレジスタは必要なくなる。そして、これにより、潜在的な処理の並列度が大きくなる。)

(1-3)
「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.」(第36頁右欄下から7行目?第37頁左欄第4行目、仮訳:この論文によって我々が果たす貢献は、マルチスレッドの手法を、プロセッササイクル幅とCPI[Cycles Per Instruction:1命令の実行に要するクロック数]の向上のために用いる主たる技術とすることを提案することにある。マルチスレッドの手法は我々の目的に完全に適している。なぜならば、複数のスレッドをインターリーブすることによって、より高い処理の並列度を得るからである。もはや1つのスレッドをアウトオブオーダー実行することに伴う複雑さには基づかずに、オンチップの複数のスレッド間で複数の処理ユニットを適切に共有する手法に基づいて、パイプラインの処理効率を得るようになる。もちろん、1つのスレッドによるよりも、複数のスレッドによるほうが、処理ユニットを稼働状態に保つようにすることが容易である。)

(1-4)
「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.」(第37頁右欄第6行目?同頁同欄第12行目、仮訳:プロセッサのパイプラインは3つのパートに分かれている(図2を参照のこと。)。フェッチパートは、4つのスレッドのために並行して、命令キャッシュからブロックを読み出し、実行されるオペコードの全てを4つのFIFOに格納する。発行パートは、FIFOからオペコードを選択して、演算器のパイプラインに投入する。実行パートは、選択されたオペコードを実行し、実行結果をレジスタファイルに格納する。)

(1-5)
「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.」(第37頁右欄第20行目?同頁同欄第23行目、仮訳:フェッチは4つのパイプラインステージによって行われる(図3を参照のこと。)。4つのスレッドについて並行して行われる。最初のステージでは、命令キャッシュから、現在のPC[プログラムカウンタ]により指し示されるブロックが読み出される。)

(1-6)
「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.」(第38頁左欄第9行目?同頁同欄第12行目、仮訳:現在のフェッチがキャンセルされなかったならば、フェッチされたブロック内の(実行される対象となる)残された複数の命令は、対応するスレッドのためのFIFOに、4番目のステージにおいてラッチされる。)

(1-7)
「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).」(第38頁右欄第4行目?同頁同欄第12行目、仮訳:4つのFIFOは、実行されるための準備ができている複数のオペコードを保持する。新たにフェッチされた複数のオペコードは[FIFOの]末尾に入れられる。一方、新たに選択された複数のオペコードは[FIFOの]先頭から取り出される(命令の発行に関する次のセクションを参照のこと。)。3番目のポインタは、オーバーラップされているFIFOのセルを限定する。発行された複数の命令が実行ステージに到達し、もはやリスタートされることがなくなるまで、発行された複数の命令はFIFOに保持される(セクション5のデータキャッシュミスの取り扱いを参照のこと。)。)

(1-8)
「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.」(第38頁右欄下から17行目?同頁同欄下から第4行目、仮訳:実行されるための準備ができている複数の異なるオペコード間に多くの衝突が検出されることがありうるので、命令の発行制御は4つのパイプラインステージにより取り扱われる(図5を参照のこと。)。最初のパイプラインステージ(図5における”スレッドiのための発行”)は最も高い優先度を有するスレッドのFIFOから複数のオペコードを選択する。先頭の4つのエントリのみ(もし、4つ未満しか使用されていなければ、その全てのエントリ。)が関係する。それらの複数のエントリはインオーダーに発行される。つまり、もしあるエントリがなんらかの衝突を理由に発行されることができないのであれば、後続する複数のエントリも発行することができない。それにも関わらず、マルチスレッドの手法を用いているおかげで、より低い優先度を有する複数のスレッドが自らの命令を発行する機会を多く得るようになる。3つの次のステージでは、優先度に基づき、3つの他のスレッドからオペコードが選択される。4つのスレッドは演算器の機能を確保することについて競い合う。)

(1-9)
「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.」(第39頁左欄第4行目?同頁同欄第8行目、仮訳:ある命令が稼働中のある演算器を必要とするならば(より優先度の高いスレッドか、または、同じサイクルで発行された同じスレッドの命令のうち先行する命令により、既に確保されているならば)、その命令は現時点の発行では選択されない。)

(1-10)
「Two instructions belonging to the same thread may be conflictual for their source and destination registers (only Read After Write conflicts are concerned).」(第39頁左欄第9行目?同頁同欄第11行目、仮訳:(リード・アフター・ライトの衝突に関する限り、)同じスレッドに属する2つの命令は、そのソースレジスタとデスティネーションレジスタに関して衝突するかもしれない。)

(1-11)
「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.」(第39頁右欄下から9行目?第40頁左欄第3行目、仮訳:命令が発行されるために満たさなければならない6つの条件を挙げる。1.先行する命令が発行されていること。2.ソースレジスタのうちでロックされているものがないこと。3.レジスタファイルのリードライトポートのうちフリーのものが充分にあること。4.演算器のうちフリーのものが充分にあること。5.命令がロードであるならば、同じスレッドに関して他のロードやストアが発行中ではないこと。6.命令がストアであるならば、同じスレッドに関して他のストアが発行中ではなく、かつ、ストアバッファがフリーであること。)

(1-12)
「At the end of each of the four issue stages, the corresponding FIFO head pointer is updated according to the number of issued instructions. 」(第40頁左欄第14行目?同頁同欄第16行目、仮訳:4つの発行ステージのそれぞれの終わりで、発行された命令の数に応じて、対応するFIFOのヘッドポインターを更新する。)

(1-13)
「The executing part is composed of 12 pipelines (one for each operator) each having 7 stages (see Fig.6).」(第40頁左欄第36行目?同頁同欄第37行目、仮訳:実行パートには、(各演算器毎に1つのパイプラインを備えられており、)7つのステージからなるパイプラインが12個ある。)

(1-14)
「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.」(第40頁左欄下から7行目?同頁同欄下から2行目、仮訳:加算器はメモリアクセス命令にて用いられる。アドレスの下位部分が用意できたらすぐに、第2ステージにて、データキャッシュからの読み出しが行われる。実行ステージの第5ステージでタグチェックが行われる。実行ステージの第2ステージの終わりでタグはラッチされる。)

(1-15)
「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.」(第40頁右欄第13行目?第41頁左欄第12行目、仮訳:データキャッシュがミスするケースでは、ロード命令やストア命令はライトバックステージにおいて完了しない。ストアミスの場合、ライトバッファのロック解除が遅れるだけであり、このことは、全てのバッファがビジーであり、かつ、ストア命令が発行を待っている状況において、同じスレッドからの発行を停止させうる。ロードミスの場合、ロードミスした命令の後の命令であり、既に発行されている命令のいくつかについては、誤った情報が渡されているかもしれない。そのようないくつかの命令はキャンセルされリスタートされなければならない。もちろん、[ロードミスした命令に対し]独立した複数の命令は関係しない。違反したロードの1サイクル後に発行された複数の命令がそのケースである。これらの命令は確実に独立である。さもなければ、それらの命令は、デスティネーションレジスタをロックするためのロードディレイフィールドにより、それらの命令は遅らされていたであろう。[ロードミスした]ロード命令自体はリスタートされる必要はない。なぜならば、ミスハンドリングロジックにより[ロードミスした]ロードは為し遂げられるからである。[ロードミスした]ロード命令とともに発行され、かつ、確実に独立な複数の命令も同様にリスタートされる必要はない。命令をリスタートするために、オーバーラップの限界値に合うように、FIFOのヘッドポインターは移動され、再発行すべき複数のオペコードを[FIFOの]未発行パートに再び含むようにする。実行パイプラインのステージx1からx3までにある全ての命令をキャンセルする。さらに、同じスレッドの命令のうち、既に発行され、かつ、まだ実行されていない命令もキャンセルされる。[ロード]ミスに関連するスレッドについて、発行は停止される。)

上記(1-4)及び(1-6)の記載事項から、引用例1における、4つのFIFOは命令キャッシュから読み出された命令(オペコード)を格納するものであり、個々のFIFOはそれぞれ別々のスレッドに割り当てられているものであると認められる。

上記(1-4)及び(1-8)の記載事項から、引用例1における発行パートは、パイプラインステージを有しており、4つのFIFOに結合され、4つのFIFOから命令(オペコード)を選択して取り出すものであり、選択されて取り出された命令(オペコード)について実行パートの演算器に発行する制御を行うものであると認められる。

上記(1-4)及び(1-8)の記載事項から、上記(1-8)の記載事項に示される命令の発行制御は引用例1における発行パートが行うものであると認められる。特に、上記(1-8)の記載事項から、引用例1における発行パートでは、異なる命令(オペコード)間の衝突が検出されるものであり、何らかの衝突検出論理を有すると認められる。

上記(1-2)、(1-3)、(1-8)及び(1-11)の記載事項から、引用例1におけるプロセッサは、同じスレッドの各命令(オペコード)についてはインオーダー発行を行うものであると認められる。

上記(1-1)、(1-3)及び(1-8)の記載事項から、引用例1におけるプロセッサは、あるスレッドの命令(オペコード)の発行ができなければ、他のスレッドの命令(オペコード)の発行を行うようにする、マルチスレッドの手法を用いるものであると認められる。

上記(1-15)の記載事項から、引用例1においては、データキャッシュからのロードミスが発生した場合に、そのロードミスが発生したスレッドについては命令の発行が停止されるものであると認められる。

、上記(1-15)の記載事項から、引用例1においては、データキャッシュからのロードミスが発生した命令(オペコード)の後の命令であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別し、そのような命令(オペコード)については、FIFOからリスタートされるものであると認められる。

上記引用例1発明の記載事項及び図面を総合勘案すると、引用例1には、次の発明(以下、「引用例1発明」という。)が記載されていると認められる。

「スレッドのための命令を格納するために割り当てられたFIFOをスレッド毎に備え、それぞれのFIFOに結合され、それぞれのFIFOから取り出された命令を実行パートに発行し、衝突検出論理を有し、パイプライン・ステージを有する発行パートを備える、インオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップと、
識別された命令をFIFOからリスタートさせるステップと、
当該あるスレッドの命令の発行を停止するステップと、
当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップと、を含む方法。」

第5.対比
本願発明と引用例1発明とを比較する。

引用例1発明のそれぞれの「FIFO」は、「スレッド毎」に割り当てられたものであり、かつ、対応するスレッドのための「命令」を格納するものであるから、引用例1発明のそれぞれのスレッドに対応する「FIFO」は、本願発明の「第1の命令バッファ」、「第2の命令バッファ」に相当する。

引用例1発明の「発行パート」は、スレッド毎のFIFO(命令バッファ)に結合され、スレッド毎のFIFO(命令バッファ)から命令を取り出すものである点では、本願発明の「命令ディスパッチ・ステージ」に一致するものである。また、引用例1発明の「発行パート」は、パイプライン・ステージを有し、命令の発行の制御を行うものである点では、本願発明の「命令発行ステージ」に一致するものである。

上記(1-8)及び(1-10)の記載事項から、引用例1における「衝突」は複数の命令(オペコード)間で検出されるものであり、その検出の際に考慮する対象として命令のソースレジスタやデスティネーションレジスタが含まれるものであり、しかも、「衝突」が生じたことを理由として命令(オペコード)の発行ができなくなることもあるのであるから、引用例1において「衝突」を「検出」することは、複数の命令(オペコード)間の依存関係をチェックすることである。そのため、引用例1発明の「衝突検出論理」は、複数の命令の間で衝突をチェックするという点で、本願発明における「依存チェック論理」に一致する。

本願発明における「長いレイテンシ命令」とは、その命令を完了するまでにかかる時間が「長いレイテンシ命令」でない命令よりも比較的長い命令である。本願の明細書の【0017】には命令が「長いレイテンシ命令」となるケースのひとつとして、データ・キャッシュDCACHEにおけるロード・ミスが挙げられている。これらのことを考慮すると、引用例1発明における「データキャッシュにおいてロードミスとなった」「命令」は、本願発明における「少なくとも1つの長いレイテンシ命令」に相当する。

引用例1発明における「データキャッシュにおいてロードミスとなった」「命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」は、長いレイテンシ命令である「データキャッシュにおいてロードミスとなった」「命令」と何らかの依存関係があることが原因で、「リスタートされなければ誤った情報が渡されている危険性がある」ことは自明である。そのため、引用例1発明における「データキャッシュにおいてロードミスとなった」「命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」は、長いレイテンシ命令の後であり、かつ、長いレイテンシ命令と依存関係がある点で、本願発明における「依存命令」に一致する。

引用例1発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をFIFOからリスタートさせる」ことは、リスタートすべきであるとされた命令を、FIFOから発行パートのパイプライン・ステージに再び供給することを意味する。ところで、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」における「前記パイプライン・ステージ」は、「命令発行ステージ」が有する「パイプライン・ステージ」を指し示すものであるから、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」とは、依存命令を、命令発行ステージが有する、もっと前のパイプライン・ステージに供給することによって、依存命令をリサイクルすることを意味する。つまり、引用例1発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をFIFOからリスタートさせる」ことは、長いレイテンシ命令に依存する命令を命令発行の制御を行うパイプライン・ステージに供給してリサイクルすることである点で、本願発明における「前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルする」ことに一致する。

引用例1発明における、「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令の発行を停止する」ことと、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をFIFOからリスタートさせる」ことをあわせることにより、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」がFIFOから再び発行されることが遅延されるものであるから、引用例1発明における「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令の発行を停止する」ことと、「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令」であると「識別された命令をFIFOからリスタートさせる」ことをあわせたものは、長いレイテンシ命令に依存する命令のディスパッチを遅延させるものである点で、本願発明における「前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させる」ことに一致する。

引用例1発明における「命令がデータキャッシュにおいてロードミスとなった」「当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行する」ことは、長いレイテンシ命令を実行している間に、代替的なスレッドの命令を発行することである点で、本願発明における「前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とする」ことに一致する。

すると、本願発明と引用例1発明とは、次の点で一致する。

<一致点>
第1のスレッドに割り当てられた第1の命令バッファと、第2のスレッドに割り当てられた第2の命令バッファと、前記第1および第2の命令バッファにそれぞれ結合され、パイプライン・ステージを有し、依存チェック論理を有する、命令ディスバッチと命令発行を行うステージを有するインオーダー・マルチスレッディング・プロセッサのスループットを向上させるための方法であって、
前記第1のスレッドからの少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップと、
前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、
前記依存命令のディスパッチを遅延させるステップと、
前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を発行することを可能とするステップと、
を含む、前記の方法。

一方で、両者は、次の点で相違する。

<相違点1>
本願発明は「前記第1および第2の命令バッファにそれぞれ結合された命令ディスパッチ・ステージと、前記命令ディスパッチ・ステージに結合されパイプライン・ステージを有する命令発行ステージと、前記命令発行ステージに結合された依存チェック論理とを有する」のに対し、引用例1発明は、「それぞれのFIFOに結合され、それぞれのFIFOから取り出された命令を実行パートに発行し、衝突検出論理を有し、パイプライン・ステージを有する発行パートを備える」点。これに関連して、本願発明は「前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップ」を有するのに対し、引用例1発明は「当該あるスレッドの命令の発行を停止するステップ」を有する点。さらに、本願発明は「前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップ」を有するのに対し、引用例1発明は「当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップ」を有する点。
つまり、命令のディスパッチと命令の発行に関連し、本願発明は「命令ディスパッチ・ステージ」と「命令発行ステージ」という2つのステージを有するのに対し、引用例1発明は「発行パート」という1つのステージを有する点。

<相違点2>
本願発明は「前記依存チェック論理」が、「前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップと、前記依存命令をもっと前の前記パイプライン・ステージに供給することによって前記依存命令をリサイクルするステップと、前記依存命令を前記命令ディスパッチ・ステージにおいて遅延させるステップと、前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するステップと、前記少なくとも1つの長いレイテンシ命令を実行している間に、代替的なスレッドが1つ以上の命令を前記命令発行ステージにおいて発行することを可能とするステップと、を含む、」ものであるのに対し、引用例1発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップと、識別された命令をFIFOからリスタートさせるステップと、当該あるスレッドの命令の発行を停止するステップと、当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップと」を実行する主体が明確でない点。

<相違点3>
本願発明は「前記第1のスレッドからのレジスタ依存によって少なくとも1つの長いレイテンシ命令の後の依存命令を識別するステップ」を有するのに対し、引用例1発明は「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップ」を有するものの、引用例1発明における「データキャッシュにおいてロードミスとなった」「命令」と「リスタートされなければ誤った情報が渡されている危険性がある命令」との間の依存関係がレジスタ依存であるのかが明確でない点。

<相違点4>
本願発明は「前記第1のスレッドから前記少なくとも1つの長いレイテンシ命令の完了を検出するステップ」を有するのに対し、引用例1発明が「データキャッシュにおいてロードミスとなった」「命令」の完了を検出するものであるのか否かが、引用例1には記載されていない点。

第6.判断
そこで、上記相違点について検討する。

・相違点1について
上記(1-4)及び(1-8)の記載事項から、引用例1発明の「実行パート」は、FIFOから命令をディスパッチし、ディスパッチした命令について発行制御を行うものであり、「実行パート」はパイプライン・ステージを有するものである。この「実行パート」における、FIFOから命令をディスパッチするまでの処理と、ディスパッチした後の命令の発行制御の処理とを分離して、2つのステージとするように設計変更を行うことは、当業者が容易になし得たことである。

・相違点2について
引用例1発明の「衝突検出論理」は(既に、”第5.対比”にて示したように、)複数の命令の間で衝突(依存)関係をチェックするものであるから、引用例1発明における「あるスレッドからの命令がデータキャッシュにおいてロードミスとなった際に、当該命令の後であり、かつ、リスタートされなければ誤った情報が渡されている危険性がある命令を識別するステップ」、「識別された命令をFIFOからリスタートさせるステップ」及び「当該あるスレッドの命令の発行を停止するステップと、当該あるスレッドの命令が発行できない間に、他のスレッドの命令を発行するステップ」に示される、命令間の衝突(依存)関係に基づく処理も、引用例1発明における「衝突検出論理」で実行するようにすることは、当業者が容易になし得たことである。

・相違点3について
上記(1-10)の記載事項からも示されるように、命令間の衝突(依存)関係としてレジスタ依存があることは当業者には周知である。そのため、引用例1発明における依存関係の識別をレジスタ依存に基づいて行うようにすることは、当業者が容易になし得たことである。

・相違点4について
引用例1発明において、ある命令がデータキャッシュにおいてロードミスとなったために命令の発行が停止されたスレッドについて、命令の発行を再開するための最低限の条件が、ロードミスとなったデータのロードが完了した時であることは当業者には自明のことであることを考えれば、そのような最低限の条件が成立したか否かを知るべく、ロードミスとなった命令の完了を検出するようにすることは、当業者が容易になし得たことである。

また、本願発明が有する作用効果は、引用例1発明から当業者が予測できた範囲内のものである。

よって、本願発明は、引用例1発明に基いて、当業者が容易に発明をすることができたものである。

第7.むすび
したがって、本願の請求項1に係る発明は、その出願前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2010-06-11 
結審通知日 2010-06-15 
審決日 2010-06-28 
出願番号 特願2004-556462(P2004-556462)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 572- Z (G06F)
P 1 8・ 575- Z (G06F)
P 1 8・ 55- Z (G06F)
P 1 8・ 537- Z (G06F)
最終処分 不成立  
前審関与審査官 塚田 肇鳥居 稔須田 勝巳  
特許庁審判長 鈴木 匡明
特許庁審判官 山崎 達也
清木 泰
発明の名称 マルチスレッディング・リサイクルおよびディスパッチ機構  
復代理人 正林 真之  
代理人 上野 剛史  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ