拒絶査定不服の審決｜不服2009-17090 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 5項独立特許用件特許、登録しない。 G06F 審判査定不服 2項進歩性特許、登録しない。 G06F
管理番号	1250706
審判番号	不服2009-17090
総通号数	147
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2012-03-30
種別	拒絶査定不服の審決
審判請求日	2009-09-14
確定日	2012-01-18
事件の表示	特願2006-515366「モニタメモリ待機を用いたキューされたロック」拒絶査定不服審判事件〔平成17年 1月13日国際公開、WO2005/003971、平成19年 7月26日国内公表、特表2007-520769〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1.手続の経緯本願は、2004年6月16日(パリ条約による優先権主張外国庁受理2003年6月27日、米国)を国際出願日とする出願であって、平成20年7月28日付けで拒絶理由が通知され、平成20年11月5日付けで手続補正がなされたものの、平成21年5月1日付けで拒絶査定がなされた。これに対し、同年9月14日に拒絶査定に対する審判請求がなされると共に手続補正がなされ、同年10月9日付けで前置報告がなされ、平成22年12月22日付けで前置報告に基づく審尋がなされ、平成23年5月11日に回答書が提出されたものである。第2.平成21年9月14日付けの手続補正について却下の決定 [補正却下の決定の結論] 平成21年9月14日付けの手続補正を却下する。 [理由] 1.補正の内容平成21年9月14日付けの手続補正(以下、「本件補正」という。)は、平成20年11月5日付けの手続補正により補正された特許請求の範囲の請求項1の記載「【請求項1】イベントに応答して、プロセッサをスリープ状態から退出させるステップと、前記プロセッサがスリープ状態から退出した後、競合するロックに係るノードのモニタリングを停止するステップと、を有する方法であって、前記スリープ状態から退出させるステップは、前記スリープ状態中に前記プロセッサにより解放されたリソースの処理制御を再開させることからなる方法。」(以下、「補正前の請求項1」という。)を「【請求項1】イベントに応答して、プロセッサをスリープ状態から退出させるステップと、前記プロセッサがスリープ状態から退出した後、競合するロックに係るノードのモニタリングを停止するステップと、を有する方法であって、前記スリープ状態から退出させるステップは、前記スリープ状態中に前記プロセッサにより解放されたリソースの処理制御を再開させることからなり、前記プロセッサがスリープ状態にある間に使用するため、前記解放されたリソースは非スリープ状態のプロセッサに再割当される方法。」(以下、「補正後の請求項1」という。) に補正することを含むものである。 2.補正の適否 2-1.新規事項の有無、補正の目的要件本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてなされており、特許法第17条の2第3項の規定に適合する。そして、補正後の請求項1に記載された「前記プロセッサがスリープ状態にある間に使用するため、前記解放されたリソースは非スリープ状態のプロセッサに再割当される」という発明特定事項は、請求前の請求項1の「スリープ状態中に前記プロセッサにより解放されたリソース」における解放されたリソースの状態を限定するものであるから、平成18年法律第55号改正附則第3条第1項によりなお従前の例とされる同法による改正前の特許法第17条の2第4項第2号の特許請求の範囲の減縮(請求項に記載した発明を特定するために必要な事項を限定するものであって、その補正前の当該請求項に記載された発明とその補正後の請求項に記載された発明の産業上の利用分野及び解決しようとする課題が同一であるもの)を目的とするものであり、本件補正は、特許法第17条の2第4項の規定に適合する。 2-2.独立特許要件補正前の請求項1についてなされた補正は、特許法17条の2第4項第2号の特許請求の範囲の減縮を目的とすることから、補正後の請求項1に記載された発明(以下「本件補正発明」という。)が、特許出願の際独立して特許を受けることができるものであるか、(平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)以下に検討する。 (1)本件補正発明前記補正前の請求項1についてなされた補正により、本件補正発明は、前記「1.補正の内容」の「補正後の請求項1」に記載された以下のものと認められる。「イベントに応答して、プロセッサをスリープ状態から退出させるステップと、前記プロセッサがスリープ状態から退出した後、競合するロックに係るノードのモニタリングを停止するステップと、を有する方法であって、前記スリープ状態から退出させるステップは、前記スリープ状態中に前記プロセッサにより解放されたリソースの処理制御を再開させることからなり、前記プロセッサがスリープ状態にある間に使用するため、前記解放されたリソースは非スリープ状態のプロセッサに再割当される方法。」 (2)引用例原査定の拒絶の理由に引用された国際公開03/040948号(以下、「引用文献1」という。)には、以下の事項が図面と共に記載されている。 A.「従来、キャッシュメモリを備えた複数のプロセッサでメインメモリを共有する共有メモリ型マルチプロセッサシステムにおいては、プロセッサ間の同期処理にスピンウェイトが用いられることが多い。このプロセッサ間の同期処理にスピンウェイトを使用する代表的な例がスピンロックである。スピンロックの命令処理は図1のように、検証部100と設定部102の手順で実現されることが多い。検証部100は、ロック獲得ポイントに達したプロセス又はスレッドがステップS1で変数Xをロードし、ステップS2で変数Xが例えばX=0といったロック獲得が可能であることを示す値か否か判定し、X=0になるまでステップS1,S2の処理を繰り返すスピンを行って待つスピンウェイトを行う。設定部102は、「test_and_set」や「compare_and_jump」などのインターロック命令を用いて、ステップS3でロック変数値XをX=1に設定してスピンロック処理を抜ける。もしロック変数値X=1の設定に失敗したら検証部100に戻りスピンウェイトを継続する。このように、ロック獲得が可能であるかどうかをチェックするスピンロックの検証部100でスピンウェイトが用いられることが多い。・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・しかしながら、スピンウェイトの実行には無駄が多い。スピンウェイトは、ウェイト終了条件となっている変数値が他のプロセッサやI/Oデバイスなどの他のエージェントにより所望の値に変更されるまで延々と同じ命令列の実行を繰り返す。繰り返しの回数となるスピン回数は、場合によっては数百回、数千回に及ぶこともめずらしくなく、ある意味でプロセッサを無駄に使用しているといえる。電力消費の観点から考えると、スピンウェイトのあいだは無駄に電力を消費していることになる。また、複数スレッドの同時実行が可能なSMT(Simultaneous Multi-Threading archtecture)プロセッサにおいては、スピンウェイトを実行中のスレッドが他の実行スレッドの妨げとなる可能性がある。一般的にSMTプロセッサでは、プロセッサリソースはスレッド間で共有されている。このプロセッサリソースは、実行スレッド毎に均等に割り当てられるのではなく、各スレッドの状態に応じて割り当てられるプロセッサリソースの数や量が変わるというのが一般的である。プロセッサリソース割り当てを決定する基準にはいろいろな方法が提案されているが、例えば次のようなアプローチがある。 (1)キャッシュミスを起こしたスレッドヘのリソース割り当てを減らす; (2)投機的に実行している命令数が多いスレッドヘのリソース割り当てを減らする; (3)リザベーションステーションに登録されている命令数の多いスレッドヘのリソース割り当てを減らす; これらのアプローチは、よりスムーズに命令を実行できる可能性の高いスレッドに優先的にプロセッサリソースを割り当てようという考えに基づいている。ここスピンウェイトは命令を非常にスムーズに実行することができる。なぜなら、同じ命令列の実行を繰り返しているだけなので、キャッシュミスも起らないし、分岐予測も外れることがないからである。したがって、SMTプロセッサにおいては、スピンウェイトを実行中のスレッドに期せずして優先的にプロセッサリソースを割り当てることになる。すると、スピンウェイト実行中スレッドに比べ、生産性の高い命令列を実行していると思われる他のスレッドへのプロセッサリソースの割り当てが減ってしまい、結果としてプロセッサの性能が下がる可能性がある。この様に、スピンウェイトには (1) 電力を無駄に消費する; (2)SMTプロセッサの性能が下げる可能性が高い; といった問題がある。」(明細書1頁12行?3頁26行) B.「図4は、図3のプロセッサ10-1の実施形態である。なお、他のプロセッサ10-2?10-4も同じ実施形態となる。図4において、プロセッサ10-1は、プロセッサコア11,キャッシュメモリインターフェース20を備える。また、キャッシュメモリ12-1は、プロセッサインターフェース24、キャッシュメモリ制御部26,バスインターフェース28及びキャッシュメモリアレイ30を備えている。このようなプロセッサ10-1及びキャッシュメモリ12-1の構成は従来のプロセッサと同じであるが、本発明にあっては、プロセッサ10-1側に新たにスピンウェイト検出部22を設け、同時にキャッシュメモリ12-1側に値変更検出部32を設けている。プロセッサ10-1に設けられたスピンウェイト検出部22は、プロセッサコア11によるスピンウェイト命令の実行中を検出した際に、スピンウェイトの終了条件となっている変数値の監視をキャッシュメモリ12-1側に設けた値変更検出部32に指示した後に、プロセッサ10-1の動作状態を変更させる。スピンウェイト検出部22によるプロセッサ10-1の動作状態の変更としては、スピンウェイト命令の実行中に生じる無駄を削減する動作状態に変更するものであり、具体的には次のようになる。例えばプロセッサ10-1が通常モードと低消費電力モードの少なくとも2つの動作モードを持っている場合には、スピンウェイト検出部22でスピンウェイト命令の実行中を検出した際にはプロセッサの動作モードを低消費電力モードに変更する。またプロセッサがプログラム実行を停止する機能を持っている場合には、スピンウェイト検出部22でスピンウェイト命令の実行中を検出した際にプロセッサにプログラムの実行を停止させる。このスピンウェイト命令の実行を検出した際の低消費電力モードへの変更あるいはプログラムの実行停止のいずれも、スピンウェイトの終了条件が所定の値に変更されるまで延々とスピンウェイトの命令列の実行を繰り返すスピンにより、プロセッサの無駄な動作や無駄に使用している消費電力を防ぐようにする。もちろん、スピンウェイト命令検出時のプロセッサによるプログラムの実行停止は低消費電力モードの1つの形態に含まれると言うこともできる。キャッシュメモリ12-1側に設けた値変更検出部32は、スピンウェイト検出部22から指示されたスピンウェイトの終了条件となっている変数値を監視し、この変数値が他のプロセッサ10-2?10-4や入出力ユニット18により変更されたことを検出した場合に、プロセッサ10-1側に値変更を通知してプロセッサの動作状態を元に戻す。例えば、スピンウェイト命令実行中の検出でプロセッサか低消費電力モードに変更されていた場合には通常モードに戻す。またスピンウェイト命令の実行中の検出でプロセッサのプログラムの実行停止となっていた場合にはプログラムの実行を再開させる。」(明細書7頁18行?8頁23行) C.「図5は、図4のプロセッサ10-1に設けているスピンウェイト検出部22の実施形態である。スピンウェイト検出部22は、実行済命令列バッファ34、スピンウェイト命令列記録部36及び比較部38を備える。この実施形態にあっては、既存の命令セットISA(Inｓｔｒｕcｔiｏn Seｔ Aｒchiｔecｔｕｒe)をそのまま使用した場合を例に取っている。スピンウェイト検出部22は、まずスピンウェイト命令列記録部36にスピンウェイトであることを示す命令列を予め記録する。この命令列の記録は複数個でもよく、また記録内容は予め定められたものであっても良い。実行済命令列バッファ34には、プロセッサコアで実行が完了した命令列が記録される。比較部38は、スピンウェイト命令列記録部36に記録している基準となる命令列と実行済命令列バッファ34に記録された命令列を比較し、両者が一致したら即ちスピンウェイト命令列が実行されていることを検出したら、キャッシュメモリインタフェース20に対しスピンウェイト命令列検出信号E1を出力する。図6は、図4のキャッシュメモリ12-1側に設けている値変更検出部32の実施形態である。この実施形態において値変更検出部32には、監視対象先記録部40とキャッシュステート監視部42を設けている。プロセッサにおいてスピンウェイト命令の実行によりスピンウェイトが始まると、図5に示したスピンウェイト検出部22よりスピンウェイト命令列検出信号E1が出力され、図6の値変更検出部32に設けている監視対象アドレス記録部40にスピンウェイトの終了条件として参照している変数値を格納しているキャッシュブロック、具体的にはキャッシュメモリエントリを、キャッシュメモリ制御部26を経由して受けて記録する。キャッシュステート監視部42は監視対象アドレス記録部40に記録されたキャッシュメモリエントリを監視しており、このエントリのキャッシュステート(キャッシュ状態)が更新されたら、キャッシュメモリ制御部26を介してプロセッサ側に値変更検出信号E2を出力する。」(明細書8頁24行?9頁19行) D.「図7は、スピンウェイト検出時にスピンウェイト終了条件となっている変数値が格納されているキャッシュメモリエントリ(キャッシュブロック)を監視して値変更を検出する本発明の処理手順のタイムチャートである。まずスピンウェイト検出部22がステップS1でプロセッサ10-1でスピンウェイト命令を実行中か否かチェックしている。プロセッサ10-1でスピンウェイト命令が実行されると、図5の実施形態に示したようなスピンウェイト検出部22でスピンウェイト命令の実行が検出され、スピンウェイト命令検出信号E1が出力される。これによって、ステップS2でスピンウェイト検出部22は、スピンウェイトで参照している変数値が格納されたキャッシュブロックの監視をキャッシュメモリ12-1側の値変更検出部32に指示する。これと同時にスピンウェイト検出部22は、ステップS3でプロセッサ10-1によるスピンウェイト命令の実行を停止し、低消費電力の動作状態に入る。スピンウェイト検出部22からキャッシュブロックの監視を指示された値変更検出部32は、ステップS101でプロセッサから指示されたキャッシュブロックの監視を開始する。即ち、ステップS102で監視対象となるキャッシュブロックにおけるキャッシュステート即ちキャッシュ状態の状態変化、具体的には無効化が行われたか否かを検出している。この状態で他のプロセッサ10-1?10-4のいずれか、あるいは入出力ユニット18によるキャッシュブロックの更新があると、監視しているキャッシュブロックのキャッシュステートが無効状態に更新される。これをステップS102で検出すると、ステップS103に進み、キャッシュブロックの状態変化を図6の値変更検出部30より値変更検出信号E2として出力し、キャッシュブロックの状態変化即ち無効化をプロセッサ側に通知する。」(明細書9頁28行?10頁21行) E.「次に図3のプロセッサ10-1?10-4としてSMTプロセッサを使用した場合について、スピンウェイト命令実行中のプロセッサに対するプロセッサリソースの割り当てを削減する本発明の他の実施形態を説明する。図11は、本発明が適用されるSMTプロセッサの概略構成である。SMTプロセッサは、命令ポインタ46-1,46-2、フェッチ/デコード48-1,48-2、実行ユニット50、リタイヤメントユニット52、1次命令キャッシュユニット54、1次データキャッシュユニット56及び2次キャッシュユニット58を備えている。このような概略構成を持つSMTプロセッサは、同時に複数スレッドを実行するため通常は命令ポインタを複数持っており、この例では2つの命令ポインタ46-1,46-2を持った場合を示している。この命令ポインタ46-1,46-2及びフェッチ/デコード48-1,48-2で実現される2つのスレッドの実行にあっては、実行ユニット50などのリソースをスレッド間で共有することにより、リソースの有効利用率を高めており、これがSMTプロセッサの狙いである。このように複数のスレッドでプロセッサリソースを共有するSMTプロセッサにあっては、次にどのスレッドの命令を実行ユニット50に割り当てるかを極める方針がいろいろ提案されている。そこで本発明は、この実行ユニットなどのプロセッサリソースをどのスレッドの命令に割り当てるかを決める方針の決定に利用することができる。具体的には、スピンウェイト実行中のスレッドを検出したら、スピンウェイト命令を実行中のスレッドに対する実行ユニットなどのプロセッサリソースの割り当てを削減もしくは停止する。これによってスピンウェイトではない、より意味のある命令を実行している他のスレッドの命令を実行ユニットに割り当てる機会が増え、その結果、SMTプロセッサの処理性能の向上が期待できる。図12は、SMTプロセッサについてスピンウェイトを検出してプロセッサリソースを削減する本発明の処理手順のタイムチャートである。SMTプロセッサ側のスピンウェイト検出部22は、ステップS1で複数のスレッド内のあるスレッドでスピンウェイト実行中か否かをチェックしており、実行中を検出すると、ステップS2に進み、スピンウェイトで参照している変数値が格納されたキャッシュブロックの監視をキャッシュメモリ側の値変更検出部32に指示する。またステップS3で、スピンウェイト命令を実行中のスレッドの命令を割り当てるプロセッサリソースの削減または停止を行う。具体的には、例えば命令ポインタ46-1及びフェッチ/デコード48-1側で実行されるスレッドの命令でスピンウェイト実行中が検出された場合には、このスレッドによる命令の実行ユニット50に対する割り当てを削減または停止し、スピンウェイト命令以外の命令を実行している命令ポインタ46-2,フェッチ/デコード48-2側となる他のスレッドの命令に実行ユニット50を割り当てる。キャッシュメモリ側の値変更検出部32にあっては、ステップS101でプロセッサ側から指示されたキャッシュブロックのキャッシュステートを監視し、ステップS102でキャッシュステート即ち状態が無効Iに更新されたことを検出すると、ステップS103でキャッシュブロックの状態変化をプロセッサ側に通知する。これを受けてスピンウェイト検出部22側にあっては、ステップS4でスピンウェイト命令を実行中のスレッドに対するそれまでのプロセッサリソースの割り当ての削減または停止を解除する。」(明細書13頁19行?15頁3行) (ア)上記Aによれば、スピンウェイトの実行には、(1)電力を無駄に消費する;(2)SMTプロセッサの性能を下げる可能性が高い;といった問題があり、それを解決するために、上記B,Cによれば、プロセッサにスピンウェイト命令の実行を検出するスピンウェイト検出部を設け、キャッシュメモリに値変更検出部を設け、スピンウェイト検出部がスピンウェイト命令の実行中を検出すると、スピンウェイトの終了条件として参照している変数値をキャッシュメモリの値変更検出部に通知し、キャッシュメモリの値変更検出部は通知された変数値に基づいてキャッシュの状態の更新を検出したら前記プロセッサに通知するものが記載されている。 (イ)上記Eによれば、プロセッサとして、複数のスレッドでプロセッサリソースを共有するSMTプロセッサを使用した際に、スピンウェイト実行中のスレッドを検出すると、スピンウェイト命令を実行中のスレッドに対する実行ユニットなどのプロセッサリソースの割り当てを削減し、スピンウェイトではない、より意味のある命令を実行している他のスレッドにプロセッサリソースを割り当て、キャッシュメモリの値変更検出部がキャッシュブロックの状態変化をプロセッサ側に通知すると、スピンウェイト命令を実行中のスレッドに対するそれまでのプロセッサリソースの割り当ての削減を解除している。以上より、引用文献1には、次の発明(以下、「引用発明」という。)が記載されている。複数のスレッドでプロセッサリソースを共有するSMTプロセッサにおいて、スピンウェイト命令実行中のスレッドに対してプロセッサリソースの割り当てを削減する方法であって、プロセッサに設けられたスピンウェイト検出部が、あるスレッドでスピンウェイト命令実行中であることを検出すると、スピンウェイトの終了条件として参照している変数値をキャッシュメモリの値変更件検出部に通知し、当該スレッドに割り当てられているプロセッサリソースを削減し、他のスレッドに当該プロセッサリソースを割り当て、キャッシュメモリの値変更検出部は、前記変数値に基づき検出したキャッシュブロックの状態変化をプロセッサに通知し、当該通知を受けたプロセッサは、前記あるスレッドに対するプロセッサリソースの割り当て削減を解除する、プロセッサリソースの割り当て削減方法 (3)対比 (ア)本件補正発明と引用発明とを対比すると、引用発明の「プロセッサリソース」「キャッシュブロックの状態変化」は、それぞれ、本件補正発明の「リソース」「イベント」に相当する。 (イ)本件補正発明の「プロセッサ」について考察する。本願明細書には、本件補正発明がハイパースレッドまたはマルチスレッドプロセッサを対象とするものであること、【0002】段落に、「ハイパースレッドプロセッサは、すべてのスレッドまたは論理プロセッサ(プロセッサ)により共有される1つのリソース設定を有する」こと、また、【0032】?【0036】段落に、リソースの解放や再構成のためのアニール処理は、スレッドに対して行われていること、が記載されている。ハイパースレッドプロセッサにおける各スレッドがOSからみると別個のプロセッサにみえることは技術常識であり、また、【0002】段落に、スレッド又は論理プロセッサに対して括弧書きでプロセッサと標記している点からみても、ハイパースレッドプロセッサにおける「スレッド」のことを本願明細書では「プロセッサ」と称している考えるのが至当である。従って、ハイパースレッドプロセッサの技術常識及び上述の明細書の記載からみて、本件補正発明における「プロセッサ」は、引用発明の「スレッド」に相当するものということができる。 (ウ)引用発明において、スピンウェイト検出部によってスピンウェイト命令実行中であることを検知されたあるスレッドでは、プロセッサリソースを削減された状態になる。このようなあるスレッドの状態を状態1と呼ぶことにする。また、他のスレッドではあるスレッドで削減されたプロセッサリソースを割り当てられる状態になる。このような他のスレッドの状態を状態2と呼ぶことにする。そうすると、引用発明の「状態1」「状態2」は、本件補正発明の「スリープ状態」「非スリープ状態」と対応するものとなる。そして、引用発明の「キャッシュブロックの状態変化」「スレッド」が本件補正発明の「イベント」「プロセッサ」に相当するものであり、引用発明において「あるスレッドに対するプロセッサリソースの割り当て削減を解除する」ことは、あるスレッドにおいては、削減されたプロセッサリソースが再度利用可能となることであるから、引用発明の「キャッシュブロックの状態変化をプロセッサに通知し、当該通知を受けたプロセッサは、前記あるスレッドに対するプロセッサリソースの割り当て削減を解除する」ことは、本件補正発明の「解放されたリソースの処理制御を再開させる」ことと同等のものである。従って、引用発明の「キャッシュブロックの状態変化をプロセッサに通知し、当該通知を受けたプロセッサは、前記あるスレッドに対するプロセッサリソースの割り当て削減を解除する」ことと、本件補正発明の「イベントに応答して、スリープ状態から退出させるステップ」とは、イベントに応答してプロセッサを一の状態から他の状態に変化させるステップである点で共通している。よって、本件補正発明と引用発明とは、次の一致点で一致し、相違点で相違している。 (一致点) イベントに応答してプロセッサを一の状態から他の状態に変化させるステップを有する方法であって、一の状態から他の状態に変化させるステップは、前記一の状態中に前記プロセッサにより解放されたリソースの処理制御を再開させることからなり、前記プロセッサが一の状態にある間に使用するため、前記解放されたリソースは他の状態のプロセッサに再割り当てさせる方法 (相違点1) 一の状態が、本件補正発明ではスリープ状態であるのに対し、引用発明ではプロセッサリソースが削減された状態、すなわち、状態1である点、また、他の状態が、本件補正発明では非スリープ状態であるのに対し、引用発明では、削減されたプロセッサリソースを割り当てられた状態、すなわち、状態2である点 (相違点2) 本件補正発明が「前記プロセッサがスリープ状態から退出した後、競合するロックに係るノードのモニタリングを停止するステップ」を有するものであるのに対し、引用発明がそのようなステップを有するかどうか不明である点 (4)相違点についての判断相違点1について引用発明において、状態1とはスレッドがプロセッサリソースの割り当てを削減されている状態である。一方、本件補正発明においてスリープ状態が如何なる状態であるかについて、請求項の記載からは明確に把握することはできない。一般に、スリープ状態とは、「動作を一時的に停止させ、節電状態で待機させること。電源をオフにするのとは異なり、停止前の状態から速やかに再開することができる。」とされている。しかしながら、本件補正発明のプロセッサとはスレッドのことであるから、スレッドに対して節電状態の待機がどのようなものであるかスリープ状態の一般的定義からみると判然としない。ところで、本願の明細書【0003】段落には、「一実施例によると、プロセッサをスリープ状態にする選択肢は、プロセッサがそれぞれのリソースを解放し、他のプロセッサによる使用のために解放されたリソースを提供することを含む。」と記載されている。従って、本件補正発明におけるプロセッサのスリープ状態とは、リソースを解放して他のプロセッサに解放したリソースを提供する状態と捉えるのが至当である。してみると、一の状態としての、本件補正発明のスリープ状態と、引用発明のプロセッサリソースが削減された状態、すなわち、状態1とは、実質的に相違がないものということができる。同様に、他の状態としての、本件補正発明の非スリープ状態と、引用発明の削減されたプロセッサリソースを割り当てられた状態、すなわち、状態2とは、実質的に相違がないものということができる。よって、相違点1を格別のものということはできない。相違点2について引用発明では、キャッシュの値変更検出部は、スピンウェイト検出部からスピンウェイトの終了条件として参照している変数値を通知されると、その変数値に基づいてキャッシュブロックの状態変化を監視している。キャッシュブロックの状態変化とは、具体的には無効化が行われたか否かを検出していること(前記(2)引用例D及び図7)であり、これはキャッシュのデータに対する他のプロセッサとの競合対策とみることができるから、引用発明におけるスピンウェイト時のキャッシュブロックの状態変化の監視はキャッシュの競合をモニタリングしていると行って良いものである。そして、キャッシュブロックの状態変化の監視は、キャッシュブロックの状態変化を検出した後は、役割が終了したことになるから、役割が終了した後において値変更検出部の監視を停止するようにことは必要に応じてなし得ることである。従って、相違点2を格別のものということはできない。そして、本件補正発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。したがって、本件補正発明は引用発明に基づいて容易に発明できたものであるから、特許法第29条第2項の規定により、特許出願の際独立して特許を受けることができないものである。 (5)回答書について請求人は、平成23年5月11日付け回答書において、「引用文献1の図11及び関連する明細書の段落には、execution unit 50とretirement unit 52というスレッド間で共有される2つのアイテムがあることが記載されています。また、スピンウェイトを実行しているスレッドが検出されると、スピンウェイトコマンドを実行しているスレッドへのexecution unitなどのプロセッサリソースの割当てが減少又は中止され、これにより、スピンウェイトでなく、より重要なコマンドを実行している他のスレッドのコマンドをexecution unitに割り当てる可能性が増大することが記載されています。しかしながら、この場合のプロセッサ(図11のSMT processor)は“スリープ状態”には入りません。引用文献1のスピンウェイトは、図12に関して記載されるようにプロセッサリソースを減少させるのに用いられ、スレッドにおけるスピンウェイトの実行中、value change detecting unitが、スピンウェイトに関するキャッシュブロックをモニタします。spinwait detecting unit 22は、スピンウェイトコマンドを実行するスレッドのコマンドが指示するプロセッサリソースを減少又は中止します。execution unit 50は、第2のスレッドからのコマンドを処理するため、スリープ状態にはならないと考えます。すなわち、引用文献1は、command pointer 46及びfetch/decode 48に対して行われることについては記載しておらず、請求項1の「前記解放されたリソースは非スリープ状態のプロセッサに再割当される」特徴は記載してないと考えます。」と主張している。上述の請求人の主張は、「プロセッサ」をスレッドではなく、物理プロセッサと捉えていること及びリソースをexecution unit と捉えていることに起因するものと思われる。前記(3)対比で検討したように本件補正発明の「プロセッサ」はハイパースレッドプロセッサを前提とするものであるから、「スレッド」と捉えるのが至当である。また、引用文献1には、前記(2)引用例 D項に引用したように「実行ユニット50などのリソースをスレッド間で共有する」「実行ユニットなどのプロセッサリソースをどのスレッドの命令に割り当てるか」「実行中のスレッドに対する実行ユニットなどのプロセッサリソースの割り当てを削減若しくは停止」と記載されている。引用文献1の記載によれば、プロセッサリソースとは、実行ユニットだけでないことは明らかであり、また、プロセッサリソースといえば、プロセッサが有しているレジスタやキャッシュなどが含まれるものであるから、「execution unit 50は、第2のスレッドからのコマンドを処理するため、スリープ状態にはならない」という主張は当を得たものではない。 (6)むすび以上のとおり、本件補正発明は、特許出願の際独立して特許を受けることができるものではないから、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項の規定により準用する特許法第126条第5項の規定に適合していないから、本件補正は、特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。第3.本願発明平成21年9月14日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成20年11月5日付けの手続補正により補正された特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。「イベントに応答して、プロセッサをスリープ状態から退出させるステップと、前記プロセッサがスリープ状態から退出した後、競合するロックに係るノードのモニタリングを停止するステップと、を有する方法であって、前記スリープ状態から退出させるステップは、前記スリープ状態中に前記プロセッサにより解放されたリソースの処理制御を再開させることからなる方法。」 (1)引用例原査定の拒絶の理由に引用された、引用文献およびその記載事項は、前記「第2.平成21年9月14日付けの手続補正についての補正却下の決定」の「2.補正の適否」の「2-2.独立特許要件」の「(2)引用例」に記載したとおりである。 (2)対比・判断本願発明は、前記「第2.平成21年9月14日付けの手続補正についての補正却下の決定」の「2.補正の適否」の「2-2.独立特許要件」の「(1)本件補正発明」に記載された本件補正発明の発明特定事項「(前記スリープ状態から退出させるステップは)前記プロセッサがスリープ状態にある間に使用するため、前記解放されたリソースは非スリープ状態のプロセッサに再割当される」を省いたものである。そうすると、本願発明の構成要件を全て含み、さらに特定の構成要件に限定要件を付加したものに相当する本件補正発明が、前記「第2.平成21年9月14日付けの手続補正についての補正却下の決定」の「2.補正の適否」の「2-2.独立特許要件」の「(4)相違点についての判断」に記載したとおり、引用発明に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用発明に基づいて、当業者が容易に発明をすることができたものである。 (3)むすび以上のとおり、本願発明は、本願の特許出願前に日本国内又は外国において頒布された引用文献1に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。よって、結論のとおり審決する。
審理終結日	2011-08-10
結審通知日	2011-08-16
審決日	2011-09-05
出願番号	特願2006-515366(P2006-515366)
審決分類	P 1 8・ 121- Z (G06F) P 1 8・ 575- Z (G06F)
最終処分	不成立
前審関与審査官	北元健太、大塚良平
特許庁審判長	吉岡浩
特許庁審判官	石井茂和清木泰
発明の名称	モニタメモリ待機を用いたキューされたロック
代理人	伊東忠彦
代理人	伊東忠重
代理人	大貫進介

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