【事件の表示】
　特願２００９−２１１９０７「モニタメモリ待機を用いたキューされたロック」拒絶査定不服審判事件〔平成２２年　２月２５日出願公開、特開２０１０−　４４７７０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は，２００４年６月１６日（パリ条約による優先権主張外国庁受理２００３年６月２７日　アメリカ合衆国）を国際出願日とする特願２００６−５１５３６６号の一部を平成２１年９月１４日に新たな特許出願としたものであって，
　平成２１年９月１４日付けで審査請求がなされ，平成２２年２月１８日付けで審査官により拒絶理由が通知され，これに対して平成２２年５月２４日付けで意見書が提出されると共に手続補正がなされ，平成２２年６月８日付けで審査官により最後の拒絶理由が通知され，これに対して平成２２年９月１３日付けで意見書が提出されると共に手続補正がなされたが，平成２２年１０月１日付けで審査官により平成２２年９月１３日付けの手続補正が却下されると共に同日付けで拒絶査定がなされ，これに対して平成２３年２月１４日付けで審判請求がなされると共に手続補正がなされ，平成２３年３月１１日付けで審査官により特許法第１６４条第３項の規定に基づく報告がなされ，平成２３年１０月２０日付けで当審により特許法第１３４条第４項の規定に基づく審尋がなされ，平成２４年２月２７日付けで回答書の提出があったものである。
　
第２．平成２３年２月１４日付けの手続補正の却下の決定
　
　［補正却下の決定の結論］
　
　平成２３年　２月１４日付け手続補正を却下する。
　
　理由
　
１．補正の内容
　平成２３年２月１４日付けの手続補正（以下，「本件手続補正」という）により，平成２２年５月２４日付けの手続補正により補正された特許請求の範囲，
「　【請求項１】
　モニタリング機構が，競合するロックに係るノードをモニタするステップと，
　前記モニタリング機構が，前記競合するロックのため待機しているプロセッサを特定するステップと，
　第１ロジックが，イベントが発生するまで，前記プロセッサをスリープ状態に移行させるステップと，
　第２ロジックが，前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させるステップと，
　前記モニタリング機構が，前記プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を有する方法であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサから再開することを含む方法。
　　【請求項２】
　前記モニタリング機構が，前記ノードのモニタリングを開始するための第１命令を実行するステップをさらに有する，請求項１記載の方法。
　　【請求項３】
　前記モニタリング機構が，前記ノードのモニタリングの停止を開始するための第２命令を実行するステップをさらに有する，請求項１記載の方法。
　　【請求項４】
　前記イベントは，前記競合するロックが有効となり，
　前記プロセッサは，有効となったロックを取得する，請求項１記載の方法。
　　【請求項５】
　前記プロセッサは，前記競合するロックを取得するのを待機しているプロセッサのキューにおける次のプロセッサを表す，請求項１記載の方法。
　　【請求項６】
　前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含む，請求項１記載の方法。
　　【請求項７】
　競合するロックに係るノードをモニタし，前記競合するロックを待機しているプロセッサを特定するモニタリング機構と，
　イベントが発生するまで前記プロセッサをスリープ状態に移行させる第１論理と，
　前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させる第２論理と，
を有する装置であって，
　前記スリープ状態への移行は，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含み，
　前記スリープ状態からの退出は，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサからの再開を含み，
　前記プロセッサが前記スリープ状態から退出すると，前記モニタリング機構は前記ノードのモニタリングを停止する装置。
　　【請求項８】
　前記イベントの発生を検出する検出論理をさらに有し，
　前記イベントは，前記競合するロックが有効になることを含む指定されたイベントを含む，請求項７記載の装置。
　　【請求項９】
　前記解放されたリソースは，レジスタプールの複数のレジスタと，命令キューの複数の命令キューエントリと，ストアバッファの複数のストアバッファエントリと，リオーダバッファの複数のリオーダバッファエントリとを含む，請求項７記載の装置。
　　【請求項１０】
　モニタリング機構の各機能を実行するための命令を格納するメモリを有するシステムであって，
前記モニタリング機構は，
　競合するロックに係るノードをモニタし，
　前記競合するロックのため待機しているプロセッサを特定し，
　イベントが発生するまで，前記プロセッサをスリープ状態に移行させ，
　前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させ，
　前記プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止し，
　前記スリープ状態への移行は，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含み，
　前記スリープ状態からの退出は，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサから再開することを含むシステム。
　　【請求項１１】
　前記モニタリング機構はさらに，前記イベントの発生を検出し，
　前記イベントは，前記競合するロックが有効になることを含む指定されたイベントを含む，請求項１０記載のシステム。
　　【請求項１２】
　前記解放されたリソースは，レジスタプールの複数のレジスタと，命令キューの複数の命令キューエントリと，ストアバッファの複数のストアバッファエントリと，リオーダバッファの複数のリオーダバッファエントリとを含む，請求項１０記載のシステム。
　　【請求項１３】
　実行時にマシーンに，
　競合するロックに係るノードをモニタするステップと，
　前記競合するロックのため待機しているプロセッサを特定するステップと，
　イベントが発生するまで，前記プロセッサをスリープ状態に移行させるステップと，
　前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させるステップと，
　前記プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を実行させる命令を有する機械可読な記憶媒体であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサから再開することを含む記憶媒体。
　　【請求項１４】
　前記命令はさらに，実行時に前記マシーンに前記ノードのモニタリングを開始するための第１命令を実行するステップを実行させる，請求項１３記載の記憶媒体。
　　【請求項１５】
　前記命令はさらに，実行時に前記マシーンに前記ノードのモニタリングの停止を開始するための第２命令を実行するステップを実行させる，請求項１３記載の記憶媒体。
　　【請求項１６】
　前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含む，請求項１３記載の記憶媒体。」（以下，上記引用の請求項各項を，「補正前の請求項」という）は，
「　【請求項１】
　モニタリング機構が，競合するロックに係るノードをモニタするステップと，
　前記モニタリング機構が，前記競合するロックのため待機している第１プロセッサを特定するステップと，
　第１ロジックが，イベントが発生するまで，前記第１プロセッサをスリープ状態に移行させるステップと，
　第２ロジックが，前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させるステップと，
　前記モニタリング機構が，前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を有する方法であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態の第１プロセッサに専用の処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含み，
　前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサから再開することを含む方法。
　　【請求項２】
　前記モニタリング機構が，前記ノードのモニタリングを開始するための第１命令を実行するステップをさらに有する，請求項１記載の方法。
　　【請求項３】
　前記モニタリング機構が，前記ノードのモニタリングの停止を開始するための第２命令を実行するステップをさらに有する，請求項１記載の方法。
　　【請求項４】
　前記イベントは，前記競合するロックが有効となり，
　前記第１プロセッサは，有効となったロックを取得する，請求項１記載の方法。
　　【請求項５】
　前記第２プロセッサは，前記競合するロックを取得するのを待機しているプロセッサのキューにおける次のプロセッサを表す，請求項１記載の方法。
　　【請求項６】
　競合するロックに係るノードをモニタし，前記競合するロックを待機している第１プロセッサを特定するモニタリング機構と，
　イベントが発生するまで前記第１プロセッサをスリープ状態に移行させる第１論理と，
　前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させる第２論理と，
を有する装置であって，
　前記スリープ状態への移行は，前記スリープ状態の第１プロセッサに係る処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含み，
　前記解放されたリソースは，レジスタプールの複数のレジスタと，命令キューの複数の命令キューエントリと，ストアバッファの複数のストアバッファエントリと，リオーダバッファの複数のリオーダバッファエントリとを含み，
　前記スリープ状態からの退出は，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサからの再開を含み，
　前記第１プロセッサが前記スリープ状態から退出すると，前記モニタリング機構は前記ノードのモニタリングを停止する装置。
　　【請求項７】
　前記イベントの発生を検出する検出論理をさらに有し，
　前記イベントは，前記競合するロックが有効になることを含む指定されたイベントを含む，請求項６記載の装置。
　　【請求項８】
　モニタリング機構の各機能を実行するための命令を格納するメモリを有するシステムであって，
前記モニタリング機構は，
　競合するロックに係るノードをモニタし，
　前記競合するロックのため待機している第１プロセッサを特定し，
　イベントが発生するまで，前記第１プロセッサをスリープ状態に移行させ，
　前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させ，
　前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止し，
　前記スリープ状態への移行は，前記スリープ状態の第１プロセッサに係る処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含み，
　前記解放されたリソースは，レジスタプールの複数のレジスタと，命令キューの複数の命令キューエントリと，ストアバッファの複数のストアバッファエントリと，リオーダバッファの複数のリオーダバッファエントリとを含み，
　前記スリープ状態からの退出は，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサから再開することを含むシステム。
　　【請求項９】
　前記モニタリング機構はさらに，前記イベントの発生を検出し，
　前記イベントは，前記競合するロックが有効になることを含む指定されたイベントを含む，請求項８記載のシステム。
　　【請求項１０】
　実行時にマシーンに，
　競合するロックに係るノードをモニタするステップと，
　前記競合するロックのため待機している第１プロセッサを特定するステップと，
　イベントが発生するまで，前記第１プロセッサをスリープ状態に移行させるステップと，
　前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させるステップと，
　前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を実行させる命令を有する機械可読な記憶媒体であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態の第１プロセッサに係る処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含み，
　前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサから再開することを含む記憶媒体。
　　【請求項１１】
　前記命令はさらに，実行時に前記マシーンに前記ノードのモニタリングを開始するための第１命令を実行するステップを実行させる，請求項１０記載の記憶媒体。
　　【請求項１２】
　前記命令はさらに，実行時に前記マシーンに前記ノードのモニタリングの停止を開始するための第２命令を実行するステップを実行させる，請求項１０記載の記憶媒体。」（以下，上記引用の請求項各項を，「補正後の請求項」という）に補正された。
　
２．補正の適否
　本件手続補正は，補正前の請求項１，及び，請求項１３に係る発明における発明特定事項である「リソースを解放」することについて，
「前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファエントリの解放を含」むという限定を加えて，補正後の請求項１，及び，請求項１０とし，
　補正前の請求項７，及び，請求項１０に係る発明における発明特定事項である「解放された処理リソース」について，
「レジスタプールの複数のレジスタと，命令キューの複数の命令キューエントリと，ストアバッファの複数のストアバッファエントリと，リオーダバッファの複数のリオーダバッファエントリとを含」むという限定を加え，補正後の請求項６，及び，請求項８としたものであって，当該限定事項は，本願の願書に添付された明細書の記載の範囲内のものであるから，
　本件手続補正は，限定的減縮を目的としたものである。
　そこで，本件手続補正が，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定を満たすものであるか否か，即ち，補正後の請求項に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるか否かについて，以下に検討する。
　
（１）補正後の請求項に係る発明
　補正後の請求項１に係る発明（以下，これを「本件補正発明」という）は，上記「１．補正の内容」において，「補正後の請求項１」として引用した次の記載のとおりのものである。
「　モニタリング機構が，競合するロックに係るノードをモニタするステップと，
　前記モニタリング機構が，前記競合するロックのため待機している第１プロセッサを特定するステップと，
　第１ロジックが，イベントが発生するまで，前記第１プロセッサをスリープ状態に移行させるステップと，
　第２ロジックが，前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させるステップと，
　前記モニタリング機構が，前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を有する方法であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態の第１プロセッサに専用の処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含み，
　前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサから再開することを含む方法。」
（なお，上記引用の記載中，「リオーダバッファの複数のリオーダバッファ」は，他の請求項に記載された事項からみて，「リオーダバッファの複数のリオーダバッファエントリ」の明らかな誤記である。）
　
（２）引用刊行物に記載の発明
　一方，原審が，平成２２年６月８日付けの拒絶理由に引用した，本願の原出願の第１国出願前に既に公知である，国際公開第０３／０４０９４８号（２００３年５月１５日公開，以下，これを「引用刊行物」という）には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「背景技術
　従来，キャッシュメモリを備えた複数のプロセッサでメインメモリを共有する共有メモリ型マルチプロセッサシステムにおいては，プロセッサ間の同期処理にスピンウェイトが用いられることが多い。
　このプロセッサ間の同期処理にスピンウェイトを使用する代表的な例がスピンロックである。スピンウェイトの命令処理は図１のように，検証部１００と設定部１０２の手順で実現されることが多い。検証部１００は，ロック獲得ポイントに達したプロセス又はスレッドがステップＳ１で変数Ｘをロードし，ステップＳ２で変数Ｘが例えばＸ＝０といったロック獲得が可能であることを示す値か否か判定し，Ｘ＝０になるまでステップＳ１，Ｓ２の処理を繰り返すスピンを行って待つスピンウェイトを行う。設定部１０２は，「test_and_set」や「compare_and_jump」などのインターロック命令を用いて，ステップＳ３でロック変数値ＸをＸ＝１に設定してスピンロック処理を抜ける。もしロック変数値Ｘ＝１の設定に失敗したら検証部１００に戻りスピンウェイトを継続する。このように，ロック獲得が可能であるかどうかをチェックするスピンロック検証部１００でスピンウェイトが用いられることが多い。
・・・・(中略）・・・・
　しかしながら，スピンウェイトの実行には無駄が多い。スピンウェイトは，ウェイト終了条件となっている変数値が他のプロセッサやＩ／Ｏデバイスなどの他のエージェントにより所望の値に変更されるまで延々と同じ命令例の実行を繰り返す。繰り返し回数となるスピン回数は，場合によっては数百回，数千回に及ぶこともめずらしくなく，ある意味でプロセッサを無駄に使用しているといえる。電力消費の観点から考えると，スピンウェイトの間は無駄に電力を消費していることになる。
　また，複数スレッドの同時実行が可能なＳＭＴ（Simultaneous Multi-Threading architecture）プロセッサにおいては，スピンウェイトを実行中のスレッドが他の実行スレッドの妨げとなる可能性がある。一般的にＳＭＴプロセッサでは，プロセッサリソースはスレッド間で共有されている。このプロセッサリソースは，実行スレッド毎に均等に割当てられるのではなく，各スレッドの状態に応じて割当てられるプロセッサリソースの数や量が変わるというのが一般的である。
・・・・(中略）・・・・
スピンウェイトは命令を非常にスムーズに実行することができる。なぜなら，同じ命令列の実行を繰り返しているだけなので，キャッシュミスも起こらないし，分岐予測も外れることがないからである。したがって，ＳＭＴプロセッサにおいては，スピンウェイトを実行中のスレッドに期せずして優先的にプロセッサリソースを割当てることになる。すると，スピンウェイト実行中のスレッドに比べ，生産性の高い命令列を実行していると思われる他のスレッドへのプロセッサリソースの割当てが減ってしまい，結果としてプロセッサの性能が下がる可能性がある。
　このように，スピンウェイトには
　（１）電力を無駄に消費する；
　（２）ＳＭＴプロセッサの性能を下げる可能性が高い；
といった問題がある。
・・・・（中略）・・・・
　本発明は，スピンウェイトの実行で生じる電力やプロセッサリソースの無駄省いて命令実行効率を高めるコンピュータ及び制御方法を提供することを目的とする。」（明細書１頁１１行〜４頁１０行）
　
Ｂ．「発明の開示
　本発明は，キャッシュメモリを備えた複数のプロセッサを有するコンピュータにおいて，プロセッサによるスピンウェイト命令の実行中を検出した際に，スピンウェイトの終了条件となっている変数値の監視を指示した後にプロセッサの動作状態を変更させるスピンウェイト検出部と，スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にプロセッサに値変更を通知して動作状態を元に戻す値変更検出部とを設けたことを特徴とする。
・・・・（中略）・・・・
　プロセッサは通常モードと低消費電力モードの少なくとも２つ以上の動作モードを持っている場合，スピンウェイト検出部は，スピンウェイト命令の実行中を検出した際にプロセッサの動作モードを低消費電力モードに変更する。また値変更検出部は，スピンウェイトの終了条件となっている変数値の変更を検出した際に，プロセッサの動作モードを通常モードに変更させる。これによりスピンウェイト実行中にプロセッサの消費電力量を削減できる。
　プロセッサはプログラム実行を停止する機能を持っている場合，スピンウェイト検出部は，スピンウェイト命令の実行中を検出した際にプロセッサにプログラムの実行を停止させる。また値変更検出部は，スピンウェイトの終了条件となっている変数値の変更を検出した際に，プロセッサにプログラムの実行を再開させる。これによりスピンウェイト実行中にプログラムの実行が停止され，これに伴いプロセッサの消費電力量を削減できる。
　プロセッサは，複数スレッドを同時実行できる構造（ＳＭＴプロセッサ）を持っている場合，スピンウェイト検出部は，スピンウェイト命令の実行中のスレッドを検出した際に，このスレッドへのプロセッサリソースの割当てを減少又は停止させる。また値変更検出部は，スピンウェイトの終了条件となっている変数値の変更を検出した際に，スレッドへのプロセッサリソースの割当てを増加又は再開させる。これによりＳＭＰプロセッサにおけるスレッドのスピンウェイト実行中に，他のスレッドプログラムの実行が停止され，スピンウェイト実行スレッドによる他のスレッドへの悪影響を回避し，結果としてプロセッサの性能が上がる。」（明細書４頁１２行〜６頁１行，当審注；上記引用記載中の「ＳＭＰプロセッサ」は，「ＳＭＴプロセッサ」の誤記である。）
　
あ．上記Ａの「複数のプロセッサでメインメモリを共有する共有メモリ型マルチプロセッサシステムにおいては，プロセッサ間の同期処理にスピンウェイトが用いられることが多い」という記載，「このプロセッサ間の同期処理にスピンウェイトを使用する代表的な例がスピンロックである」という記載，「ロック獲得が可能であるかどうかをチェックするスピンロック検証部１００でスピンウェイトが用いられることが多い」，及び，「スピンウェイトには（１）電力を無駄に消費する；（２）ＳＭＴプロセッサの性能を下げる可能性が高い；といった問題がある」という記載から，
“複数のプロセッサでメインメモリを共有する共有メモリ型マルチプロセッサシステムにおいて，プロセッサ間の同期処理に用いられるスピンウェイト，あるいは，スピンロックは，（１）電力を無駄に消費する，更に，ＳＭＴプロセッサにおいては，（２）ＳＭＴプロセッサの性能を下げる可能性が高い；といった問題がある”ことが読み取れる。
　
い．上記あ．で指摘した「スピンウェイト」の問題を解消するために，上記Ｂには「本発明は，キャッシュメモリを備えた複数のプロセッサを有するコンピュータにおいて，プロセッサによるスピンウェイト命令の実行中を検出した際に，スピンウェイトの終了条件となっている変数値の監視を指示した後にプロセッサの動作状態を変更させるスピンウェイト検出部と，スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にプロセッサに値変更を通知して動作状態を元に戻す値変更検出部とを設けたことを特徴とする」と記載され，また，同じく上記Ｂに，「プロセッサは，複数スレッドを同時実行できる構造（ＳＭＴプロセッサ）を持っている場合，スピンウェイト検出部は，スピンウェイト命令の実行中のスレッドを検出した際に，このスレッドへのプロセッサリソースの割当てを減少又は停止させる。また，値変更検出部は，スピンウェイトの終了条件となっている変数値の変更を検出した際に，スレッドへのプロセッサリソースの割当てを増加又は再開させる」と記載されている。
　よって，上記で指摘の点を踏まえると，引用刊行物には，次の発明（以下，これを「引用発明１」という）が記載されているものと認める。
　
　キャッシュメモリを備えた複数のプロセッサを有するコンピュータにおいて，プロセッサ間の同期処理にスピンウェイトを用いるスピンロックを実行する場合に，スピンウェイト検出部が，プロセッサによるスピンウェイト命令の実行中を検出した際に，スピンウェイトの終了条件となっている変数値の監視を指示した後にプロセッサの動作状態を変更させ，値変更検出部が，前記スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にプロセッサに値変更を通知して動作状態を元に戻すようにした，複数のプロセッサを有するコンピュータにおける制御方法。
　
　更に，上記あ．，い．で検討した事項を踏まえると，引用刊行物には，次の発明（以下，これを「引用発明２」という）も記載されているものと認める。
　
　キャッシュメモリを備えた複数のＳＭＴプロセッサを有するコンピュータにおいて，プロセッサ間の同期処理にスピンウェイトを実行する場合に，スピンウェイト検出部が，プスレッドによるスピンウェイト命令の実行中を検出した際に，スピンウェイトの終了条件となっている変数値の監視を指示した後にスレッドへのプロセッサリソースの割当てを減少又は停止させ，前記スピンウェイト検出部からの指示によって値変更検出部は，前記スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にスレッドに値変更を通知してプロセッサリソースの割当てを増加又は再開させるようにした，複数のＳＭＴプロセッサを有するコンピュータにおける制御方法。
　
（３）本件補正発明と引用発明１との対比
あ．引用発明１における「スピンウェイト」は，「スピンロック」におけるものであるから，引用発明１において，「スピンウェイト命令」を実行している「プロセッサ」を検出することは，「スピンロック」に関連している「プロセッサ」を監視することにほかならない。
　よって，引用発明１において，「スピンウェイト検出部が，プロセッサによるスピンウェイト命令の実行中を検出」することと，
　本件補正発明において，「モニタリング機構が，競合するロックに係るノードをモニタするステップと，前記モニタリング機構が，前記競合するロックのために待機している第１のプロセッサ特定するステップ」とは，
“監視部が，競合するロックに係るノードをモニタし，競合するロックのために待機している第１のプロセッサ特定するステップ”である点で共通する。
　
い．引用発明１における「低消費電力モード」，あるいは,「プログラム実行停止モード」が，本件補正発明における「スリープ状態」に相当するので，
　引用発明１において，「スピンウェイト検出部」が，「スピンウェイトの終了条件となっている変数値の監視を指示した後にプロセッサの動作状態を通常モードから，低消費電力モード，或いは，プログラム実行停止モードに変更」するのであるから，
　引用発明１における「スピンウェイト検出部」が，
　本件補正発明における「第１のロジック」に相当し，
　よって，引用発明１における「スピンウェイト検出部」が，「スピンウェイトの終了条件となっている変数値の監視を指示した後にプロセッサの動作状態を通常モードから，低消費電力モード，或いは，プログラム実行停止モードに変更」するが，
　本件補正発明における「第１のロジックが，イベントが発生するまで,前記第１のプロセッサをスリープ状態に移行させるステップ」に相当する。
　
う．引用発明１において，「値変更検出部」は，「スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にプロセッサに値変更を通知して動作状態を通常モードに戻す」ようにしているのであるから，
　引用発明１における「値変更検出部」が，
　本件補正発明における「第２のロジック」に相当し，引用発明において，「通常モード」に戻れば，当然のことながら，「スピンウェイト」の監視は停止するので，
　引用発明１において，「前記スピンウェイト検出部からの指示によって値変更検出部は，前記スピンウェイト検出部から指示された変数値を監視し，この変数値が変更されたことを検出した場合にプロセッサに値変更を通知して動作状態を通常モードに戻す」ことと，
　本件補正発明における「第２ロジックが，前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させるステップと，前記モニタリング機構が，前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップ」とは，
“第２のロジックが，イベントが発生すると，第１プロセッサをスリープ状態から退出させ，監視部が，第１プロセッサがスリープ状態から退出するとき，ノードのモニタリングを停止する”ものである点で共通する。
　よって，上記あ．〜う．で検討した事項から，本件補正発明と，引用発明１との，一致点，及び，相違点は次のとおりである。
　
［一致点］
　監視部が，競合するロックに係るノードをモニタし，
　前記監視部が，前記競合するロックのために待機している第１プロセッサを特定するステップと，
　第１のロジックが，イベントが発生するまで，前記第１プロセッサをスリープ状態に移行させるステップと,
　第２のロジックが，前記イベントが発生すると，前記第１プロセッサを前記スリープ状態から退出させるステップと,
　前記監視部が，前記第１プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップを含む，制御方法。
　
［相違点１］
“監視部”について
　本件補正発明においては，該“監視部”として，「モニタリング機構」が存在するが，
　引用発明においては，「モニタリング機構」についての言及ない点。
　
［相違点２］
　本件補正発明においては，
「前記スリープ状態に移行させるステップは，前記スリープ状態の第１プロセッサに専用の処理リソースを解放し，前記スリープ状態の第１プロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態の第２プロセッサに再割当てすることを含」むのに対して，
　引用発明１には，「リソース」の「再割当て」についての言及がない点。
　
［相違点３］
　本件補正発明においては，
「前記リソースの解放は，レジスタプールの複数のレジスタの解放，命令キューの複数の命令キューエントリの解放，ストアバッファの複数のストアバッファエントリの解放，及びリオーダバッファの複数のリオーダバッファの解放を含むものであるのに対して，
　引用発明１には，「解放するリソース」についての言及がない点。
　
［相違点４］
　本件補正発明においては，
　「前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態の第２プロセッサから再開することを含む」ものであるのに対して，
　引用発明においては，「リソースの制御」を「他のプロセッサ」から行うことについては，特に言及されていない点。
　
（４）相違点についての当審の判断
あ．［相違点１］について
　引用刊行物に，従来手法として，
「同期専用のハードウェアを備える」（明細書４頁４行）と記載されているように，「モニタ」するための単一の機構を設ける手法は，当業者にとっては周知の技術事項である。
　よって，引用発明においても，「プロセッサ」を「モニタ」するための機構を設けるよう構成するとは,当業者が適宜なし得る事項である。
　よって，相違点１は，格別のものではない。
　
い．［相違点２］について
　本件補正発明においては，本願明細書の段落【０００３】に，
「典型的には，ハイパースレッドプロセッサは，すべてのスレッドまたは論理プロセッサ（プロセッサ）により共有される１つのリソース設定を有する。特に１つ以上のプロセッサがロックが利用可能にあるのを待機しているとき，適切なリソースを有しないことは，プロセッサ間の重大なコンテンションを引き起こすかもしれない」，
　と記載されていることから，本件補正発明における「プロセッサ」は，「論理プロセッサ」，及び，「スレッド」を含むものである。
　そして，本願明細書の段落【００３４】に，
「一実施例によると，パーティションされたリソースは，マシーンのアクティブなスレッドをフローに従ってパーティション及びアニール（他のスレッドに拠る再利用のため合成される）されてもよい」，
　と記載されていて，本件補正発明における「処理リソース」の「再割当」は，「スレッド」，或いは，「論理プロセッサ」への「再割当」を含むものである。
　さらに，本願明細書の段落【０００５】に，
「本発明の特徴は・・・前記スリープ状態に移行させるステップは，前記スリープ状態のプロセッサコアに係る処理リソースを解放し，前記スリープ状態のプロセッサコアがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサコアに再割当てすることを含み」，
　と記載されていることから，本件補正発明における「スリープ状態に移行させるステップ」は，「スレッド」に対して，「処理リソースの解放と，再割当て」とを含むものであると解される。
　一方，引用発明２は，「スレッド」が，「スピンウェイト」状態にあるときに，該「スレット」への「資源」の割当ての停止を行うものであり，引用発明２においては，「スピンウェイト」状態に入った「スレッド」が，「スリープ状態」であるかは明確でないが，「スレッド」が，「スピンウェイト」状態に入ったとき，「スリープ状態」に移行し，その際に「資源」を解放し，当該「資源」を「再割当て」するようなことは，例えば，本願の原出願の第１国出願前に既に公知である，特開平０５−２２５１４９号公報（１９９３年９月３日公開，以下，これを「周知文献１」という）に，
「【０００８】このロック方式においては，ロックを獲得できない場合は，そのプロセスはまずスピンロック状態に設定され，そして，所定のスピンロック時間スピンしてもロックを獲得できない場合にスリープ状態に設定される。このため，所定のスピンロック時間を越える長い時間ロックが取れない時にはスリープとなって，プロセッサを他のプロセスに渡すことができ」，
　と記載されているように，当業者にとって周知の技術事項であり，
　引用発明１における「プロセッサ」において，「スリープ状態」に移行する際に「資源」の解放と，該「資源」の，他のプロセッサへの再割当てを行うようにすることは，引用発明２，及び，周知文献１に記載の周知技術から，当業者が適宜なし得る事項である。
　よって，相違点２は，格別のものではない。
　
う．［相違点３］について
　解放する「資源」として，
　「レジスタプールの複数のレジスタ，命令キューの複数の命令キューエントリ，ストアバッファの複数のストアバッファエントリ，及び複数のリオーダバッファ」とすることについても，
　原審が，拒絶査定において，当該技術分野においては，周知であることを示すために引用した，本願の原出願の第１国出願前に既に公知である，「Deborah T. Marr et al., Hyper-Threading Technology Architecture and Microarchitechture, Intel Technology Journal, Intel Corporation, February 14 2002, Vol.6 Issue 1, pp.4−15」（以下，これを「周知文献２」という）に，
　
Ｃ．「Uop Queue
After uops are fetched from the trace cache or the Microcode ROM, or forwarded from the instruction decode logic, they are placed in a “uop queue.” This queue decouples the Front End from the Out-of-order Execution Engine in the pipeline flow. The uop queue is partitioned such that each logical processor has half the entries. This partitioning allows both logical processors to make independent forward progress regardless of front-end stalls (e.g., TC miss) or execution stalls.」（９頁右欄４６行〜１０頁左欄６行）
（Ｕｏｐキュー
　ｕｏｐが，トレース・キャッシュ，あるいは，マイクロコードＲＯＭからフェッチされるか，インストラクション・デコード・ロジックから転送されると，それらは，“ｕｏｐキュー”内に置かれる。このキューは，パイプライン・フローの中で，アウト・オブ・オーダー実行エンジンから，フロント・エンドを切り離す。ｕｏｐキューは，それぞれの論理プロセッサがエントリの半分を有するように，分割される。この分割は，フロント−エンドのストール（例えば，トレース・キャッシュのミス）や，実行ストールに関係なく，独立に前に進む。）
　
Ｄ．「Allocator
The out-of-order execution engine has several buffers to perform its re-ordering, tracing, and sequencing operations. The allocator logic takes uops from the uop queue and allocates many of the key machine buffers needed to execute each uop, including the 126 re-order buffer entries, 128 integer and 128 floating-pointphysical registers, 48 load and 24 store buffer entries. Some of these key buffers are partitioned such that each logical processor can use at most half the entries. 
Specifically, each logical processor can use up to a maximum of 63 re-order buffer entries, 24 load buffers, and 12 store buffer entries.
If there are uops for both logical processors in the uop queue, the allocator will alternate selecting uops from the logical processors every clock cycle to assign resources. If a logical processor has used its limit of a needed resource, such as store buffer entries, the allocator will signal “stall” for that logical processor and continue to assign resources for the other logical processor. In addition, if the uop queue only contains uops for one logical processor, the allocator will try to assign resources for that logical processor every cycle to optimize allocation bandwidth, though the resource limits would still be enforced.
By limiting the maximum resource usage of key buffers, the machine helps enforce fairness and prevents deadlocks.」（１０頁右欄３行〜左欄２９行）
（アロケータ
　アウト・オブ・オーダー実行エンジンは，それのリオーダ，追跡，及び，配列処理を行うために，複数のバッファを有している。アロケータ・ロジックは，ｕｏｐキューから，ｕｏｐを取り出し，それぞれのｕｏｐを実行するために必要な，１２６個のリオーダ・バッファ・エントリ，１２８個の整数，及び，１２８個の浮動小数点物理レジスタ，４８個のロード，及び，２４個のストア・バッファ・エントリを含む，キーとなるマシン・バッファの多くを割り当てる。
　特に，それぞれの論理プロセッサは，最高６３個のリオーダ・バッファエントリ，２４個のロード・バッファ，そして，１２個のストア・バッファ・エントリを使い切ることができる。
　もし，それらが，ｕｏｐキューにおいて，両方の論理プロセッサのｕｏｐであれば，アロケータは，リソースに割り当てるために、クロックサイクル毎に，論理プロセッサから，ｕｏｐを交互に選択する。もし，論理プロセッサが，例えば，ストア・バッファ・エントリなどの，必要とされるリソースの限界で用いていたのであれば，アロケータは，その論理プロセッサのために，“ストール”の信号を送り，他の論理プロセッサのためにリソースの割付を継続する。加えて，ｕｏｐキューが，１つの論理プロセッサのためにのみ，ｕｏｐを含むのであれば，たとえ，リソースの限界が強化されたとしても，アロケータは，その論理プロセッサに，サイクル毎に，割当ての帯域幅が最適になるように，リソースを割り付けることを試みるであろう。
　キー・バッファの最大リソース使用量の制限によって，そのマシンが，公平性の実行を助け，デットロックを防ぐ。）
　
Ｅ．「Register Rename
The register rename logic renames the architectural IA-32 registers onto the machine’s physical registers. This allows the 8 general-use IA-32 integer registers to be dynamically expanded to use the available 128 physical registers. The renaming logic uses a Register Alias Table (RAT) to track the latest version of each architectural register to tell the next instruction(s) where to get its input operands.
Since each logical processor must maintain and track its own complete architecture state, there are two RATs, one for each logical processor. The register renaming process is done in parallel to the allocator logic described above, so the register rename logic works on the same uops to which the allocator is assigning resources.
Once uops have completed the allocation and register rename processes, they are placed into two sets of queues, one for memory operations (loads and stores) and another for all other operations. The two sets of queues are called the memory instruction queue and the general instruction queue, respectively. The two sets of queues are also partitioned such that uops from each logical processor can use at most half the entries.」（１０頁右欄１３行〜１１頁左欄６行）
（レジスタ・リネーム
　レジスタ・リネーム・ロジックは，マシンの物理レジスタ上のアーキテクチャIA-32レジスタのリネームを行う。これは，利用可能な１２８個の物理レジスタを使用するために，動的に拡張される，８個の汎用IA-32整数レジスタを許す。リネーミング・ロジックは,何処から，入力オペランドを取得するかを,次の命令と対話するために，それぞれのアーキテクチャ・レジスタの最新のバーションを追跡するための，レジスタ別名テーブル（RAT）を用いる。
　それぞれの論理プロセッサは,自身の完全なアーキテクチャ状態を，維持し，追跡しなければならないので，それぞれの論理プロセッサに１つずつ，２つのレジスタ別名テーブルが存在する。レジスタ・リネーミング・プロセスは，上述したアロケータ・ロジックと並列に行われる。そのため，レジスタ・リネーム・ロジックは，アロケータがリソースを割り付けた，同じｕｏｐに働く。
　ひとたび，ｕｏｐが，アロケーションと，レジスタ・リネーム・プロセスを完了すると,それらは，１つは，メモリ処理（ロードとストア）の，もう１つは,他のすべての処理ための,２組のキューに配置される。２組のキューは，それぞれ，メモリ命令キューと，汎用命令キューと呼ばれる。２組のキューは，また，それぞれの論理プロセッサからのｕｏｐが，最大で，エントリにの半分を使用することができるように，分割される。）
　
Ｆ．「Execution Units
The execution core and memory hierarchy are also largely oblivious to logical processors. Since the source and destination registers were renamed earlier to physical registers in a shared physical register pool, uops merely access the physical register file to get their destinations, and they write results back to the physical register file. Comparing physical register numbers enables the forwarding logic to forward results to other executing uops without having to understand logical processors.
After execution, the uops are placed in the re-order buffer. The re-order buffer decouples the execution stage from the retirement stage. The re-order buffer is partitioned such that each logical processor can use half the entries.」（１１頁左欄３４行〜４９行）
（実行ユニット
　実行コアとメモリ階層は，また，論理プロセッサには，全く気付かない。送り元と，宛先レジスタは，共有された物理レジスタ・プール内の物理レジスタより早くリネームされるので，ｕｏｐは，それらの宛先を得るために，単に，物理レジスタ・ファイルにアクセスし，結果を物理レジスタ・ファイルに書き戻す。物理レジスタ番号を比較することは，論理プロセッサを理解することを必要としないで，他の実行するｕｏｐの結果を転送するために転送ロジックを有効にする。
　実行すると，ｕｏｐは，リオーダ・バッファ内に配置される。リオーダ・バッファは，実行ステージを，リタイヤメント・ステージから切り離す。リオーダ・バッファは，それぞれの論理プロセッサが，エントリに半分を使用可能なように分割される。）
　
　と記載されているように，割当てられる資源として，「レジスタ」，「ｕｏｐキュー」，及び，「リオーダ・バッファ」は周知であるから，資源を解放する際に，これら割当てられている資源が，解放の対象となることは明らかである。
　よって，引用発明１においても，解放する資源として，「レジスタ」，「ｕｏｐキュー」，及び，「リオーダ・バッファ」とすることは，当業者が適宜なし得る事項である。
　よって，相違点３は，格別のものではない。
　
え．［相違点４］について
　スリープ状態に入っているプロセッサを，スリープ状態から退出させる場合には，新たなリソースを割り当てるのでなく，スリーブに入る時点で割り当てられていたリソースを再割当てするのであれば，先ず，現在該リソースを割り当てられている，非スリープ状態のプロセッサが，該リソースの制御を行って，該リソースの解放を行わなければならないことは自明の事項であるから，
　引用発明１においても，プロセッサの動作状態を元に戻す場合に，該プロセッサに割り当てるべきリソースを再割当てする場合に，現在割り当てられているプロセッサが，該リソースを解放する処理を行った後に，動作状態を変更して，動作状態を元に戻すプロセッサに，該リソースを割り当てるよう構成することは，当業者が，適宜なし得る事項である。
　よって，相違点４は，格別のものではない。
　
　上記で検討したごとく，相違点１〜４はいずれも格別のものではなく，そして，本願発明の構成によってもたらされる効果も，当業者であれば容易に予測できる程度のものであって，格別なものとは認められない。
　よって，本件補正発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。
　
３．補正却下むすび
　したがって，本件手続補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって，補正却下の決定の結論のとおり決定する。
　
第３．本願発明について
　平成２３年２月１４日付けの手続補正は，上記のとおり却下されたので，本願の請求項１に係る発明（以下，これを「本願発明」という）は，平成２２年５月２４日付けの手続補正により補正された，上記「第２．平成２３年２月１４日付けの手続補正の却下の決定」の「１．補正の内容」において，「補正前の請求項１」として引用した，次の記載のとおりのものであると認める。
　
「モニタリング機構が，競合するロックに係るノードをモニタするステップと，
　前記モニタリング機構が，前記競合するロックのため待機しているプロセッサを特定するステップと，
　第１ロジックが，イベントが発生するまで，前記プロセッサをスリープ状態に移行させるステップと，
　第２ロジックが，前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させるステップと，
　前記モニタリング機構が，前記プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップと，
を有する方法であって，
　前記スリープ状態に移行させるステップは，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含み，
　前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサから再開することを含む方法。」
　
第４．引用刊行物に記載の発明
　一方，原審が拒絶理由で引用した引用刊行物には，上記「第２．平成２３年２月１４日付けの手続補正の却下の決定」の「２．補正の適否」における「（２）引用刊行物に記載の発明」において指摘したとおりの，引用発明１，及び，引用発明２が記載されている。
　
第５．本願発明と引用発明との対比
　本願発明は，上記で検討の本件補正発明から，
　「プロセッサ」に対する限定と，「リソースの解放」において，解放する「リソース」についての限定を取り除いたものであるから，
　本願発明と，引用発明１との一致点，及び，相違点は，次のとおりである。
　
［一致点］
　監視部が，競合するロックに係るノードをモニタし，
　前記監視部が，前記競合するロックのために待機しているプロセッサを特定するステップと，
　第１のロジックが，イベントが発生するまで，前記プロセッサをスリープ状態に移行させるステップと,
　第２のロジックが，前記イベントが発生すると，前記プロセッサを前記スリープ状態から退出させるステップと,
　前記監視部が，前記プロセッサが前記スリープ状態から退出するとき，前記ノードのモニタリングを停止するステップを含む，制御方法。
　
［相違点Ａ］
“監視部”について
　本願発明においては，該“監視部”として，「モニタリング機構」が存在するが，
　引用発明においては，「モニタリング機構」についての言及ない点。
　
［相違点Ｂ］
　本願発明においては，
「前記スリープ状態に移行させるステップは，前記スリープ状態のプロセッサに係る処理リソースを解放し，前記スリープ状態のプロセッサがスリープ状態にある間に使用するため，前記解放された処理リソースを非スリープ状態のプロセッサに再割当てすることを含」むのに対して，
　引用発明１には，「リソース」の「再割当て」についての言及がない点。
　
［相違点Ｃ］
　本願発明においては，
「前記スリープ状態から退出させるステップは，前記解放された処理リソースの制御を前記非スリープ状態のプロセッサから再開することを含む」ものであるのに対して，
　引用発明においては，「リソースの制御」を「他のプロセッサ」から行うことについては，特に言及されていない点。
　
第６．当審の判断
　相違点Ａ〜相違点Ｃは，若干の相違はあるものの，実質的には，本件補正発明と引用発明１との，相違点１，相違点２，及び，相違点４と同一のものであるから，上記第２．平成２３年２月１４日付けの手続補正の却下の決定」の「２．補正の適否」における「（４）相違点についての当審の判断」において検討したとおりであるから，
　相違点Ａ〜相違点Ｃは，格別のものではない。
　そして，本願発明の構成によってもたらされる効果も，引用例記載の発明から当業者ならば容易に予測することができる程度のものであって，格別のものとはいえない。
　
第７．むすび
　したがって，本願発明は，本願の特許出願前に日本国内又は外国において頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。