【事件の表示】
　特願２００８−５４８５８６「有限トランザクションメモリシステム」拒絶査定不服審判事件〔平成１９年　７月１２日国際公開、ＷＯ２００７／０７８８８３、平成２１年　６月　４日国内公表、特表２００９−５２１７６７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成１８年１２月１４日（パリ条約による優先権主張外国庁受理平成１７年１２月３０日、アメリカ合衆国）の出願であって、その特許請求の範囲の請求項１２に記載された発明（以下、「本願発明」と呼ぶ。）は、平成２５年７月３０日付けの手続補正により補正された特許請求の範囲の請求項１２に記載されたとおりのものであり、次のとおりのものと認める。
「　　【請求項１２】
　ハードウェアトランザクションメモリアクセスに対応するスレッドの第１命令を実行するステップと、
　前記第１命令のコミットが失敗すると、ソフトウェアトランザクションメモリアクセスに対応する前記スレッドの第２命令を実行するステップと、
　対応するメモリエントリのオーナーシップ状態を特定する１以上のオーナーシップフラグビットを格納するステップと、
を有する方法であって、
　前記ハードウェアトランザクションメモリアクセスは、オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される方法。」
　
２．引用例記載の発明
　当審による平成２５年５月１５日付けの拒絶理由通知書で引用した「MOIR M，HYBRID TRANSACTIONAL MEMORY，ANNOUNCEMENT SUN MICROSYSTEMS，SUN MICROSYSTEMS，２００５年　７月，P1-15」（以下、「引用例」と呼ぶ。）には、次の記載がある。
　
（１）
「3.1 Integrating hardware and software transactions 
As discussed earlier, we expect that almost all transactions will be able to complete in hardware, and of course we expect that small transactions committed in hardware will be considerably faster than software transactions. Therefore, it generally makes sense to try a transaction first in hardware. Transactions attempted in hardware may fail to commit for a variety of reasons, including exceeding limitations on hardware resources or functionality, contention with other transactions, and the occurrence of events across which the particular best-effort HTM cannot sustain taransactions(e.g. preemption, page faults, interrupts, etc.). 
 In some cases, it will make sense to retry the transaction in hardware, perhaps after a short delay to reduce contention and improve the chance of committing in hardware; such delay may be effected by simple backoff techniques[1], or by more sophisticated contention control techniques[7,18]. Some transactions are doomed to never succeed in hardware, so eventually a transaction that fails repeatedly should be attempted in software, where hardware limitations become irrelevant, and more flexibility for contention control is available.」（第４ページ下から８行目〜第５ページ第６行） 
（当審による訳） 
 3.1 ハードウェア及びソフトウェアトランザクションの統合 
　前に議論したように、ほとんどすべてのトランザクションがハードウェアで完了することができると、我々は予想する。そして、当然に、ハードウェアで行われる小規模のトランザクションは、ソフトウェアトランザクションよりかなり速いと、我々は予想する。したがって、ハードウェアで最初にトランザクションを試みることは、通常、意味をなす。ハードウェアで試みられるトランザクションは、ハードウェア資源や機能性の制限の超過、他のトランザクションとの競合、特定のベストエフォートＨＴＭがそれをまたいでトランザクションを継続できないイベントの発生（例えば、プリエンプション、ページ・フォールト、割り込みなど）、を含む様々な理由のために、完了に失敗することがある。 
　いくつかのケースでは、競合を減らしハードウェアで完了するチャンスを改善するための、おそらくは短い遅れの後に、ハードウェアでのトランザクションを再度試みることは、意味をなす;　そのような遅れは、単純なバックオフ技術[1]によって、または、より高度な競合制御技術［7、18］によって実現され得る。いくつかのトランザクションは、ハードウェアでは決して成功しない定めをもっている。そこで、繰り返し失敗するトランザクションは、結局、ソフトウェアで試みられる必要がある。そして、そこでは、ハードウェアの制限は無関係になり、競合制御のためのより高度な柔軟性が利用可能となる。 
　
（２）
「3.3 A simple HyTM-compatible STM
 Almost all STM designs can be described at a high level as follows. In order to effect changes to multiple memory locations atomically, a transaction acquires exclusive ownership of each location it intends to modify, and maintains a writeset, which records the new values that will be written to these locations when and if the transaction successfully commits. Each transaction's status is usually recorded in a single word that can be atomically changed, for example from ACTIVE to COMMITED or ABORTED.
 When the transaction changes its status from ACTIVE to COMMITTED, the new values in its writeset are deemed to be logically stored to their respective locations, even though they may not be physically stored in those locations at that time. Typically, the new values are subsequently transferred to the physical locations and then the transaction releases ownership of those locations, thereby allowing other transactions to acquire ownership of them.」（第６ページ第９〜２０行）
（当審による訳） 
3.3　簡単な、HyTM（ハイブリッドトランザクションメモリー）コンパチブルSTM（ソフトウェアトランザクションメモリ）
　ほとんど全てのＳＴＭデザインは、ハイレベルでは次のように記述される。多数のメモリ位置に同時に変化をもたらすために、トランザクションは、それが修正し、ライトセットを維持しようとするそれぞれの位置の排他的な「オーナーシップ」を獲得する。そして、そのライトセットは、トランザクションが成功裏に終了したとき、これらの位置に書き込まれるであろう新しい値を記録する。各トランザクションのステータスは、通常、例えば、ACTIVEからCOMMITEDあるいはABORTEDへ、のように、同時に変化させられるシングルワードで記録される。
　トランザクションが、そのステータスをACTIVEからCOMMITTEDへ変えるとき、そのライトセットの新しい値は、それらそれぞれの位置に、そのときには物理的には格納されないかも知れないが、「論理的に」格納されるように見える。典型的には、新しい値は、続いて物理的位置へ転送され、その後、トランザクションは、それらの位置のオーナーシップをリリースし、それにより、他のトランザクションがそれらのオーナーシップを獲得できるようにする。
　
（３）
「To keep our presentation simple, the basic HyTM-compatible STM design we describe in this section uses a very simple hashing scheme based on a table of ownership recordes(orecs). The orec used for a given memory location is determined by a hash function on the location's address. By choosing the size of the ownership table to be a power of two, we can implement a simple hash function very efficiently by using selected bits of the address to index the table. Note that multiple locations can map to the same orec. With care, this does not affect correctness. However, it may affect performance if too many false conflicts occur (i.e., two transactions appear to coflict because they access different locations that hash to the same orec). If so, this problem may be addressed by a larger ownership table, or by a more sophisticated hashing mechanism that avoids false conflicts.」（第６ページ下から１１行目〜下から２行目）
（当審による訳） 
　我々の提示を簡単にするために、われわれがこのセクションで述べる基本的なHyTMコンパチブルSTMのデザインは、オーナシップレコーズ(orecs)のテーブルに基づく非常に簡単なハッシュスキームを用いる。与えられたメモリロケーションのために使用されるorecは、ロケーションのアドレスについてのハッシュ関数により決定される。オーナーシップテーブルのサイズを２のべき乗に選択することにより、我々は、テーブルをインデクスするためにアドレスの選択ビットを用いて非常に効率的に単純なハッシュ関数を与えることができる。多数の位置が同じorecにマップされ得ることに留意されたい。注意：これは、正確性には影響しない。しかしながら、もしあまりに多くの”フォールスコンフリクト”が生じる（すなわち、２つのトランザクションが、同じorecにハッシュする異なったロケーションにアクセスするので、コンフリクトしたように見える。）。もしそうなら、この問題は、より大きいオーナーシップテーブルにより、あるいは、フォールスコンフリクトを避けるより洗練されたハッシュメカニズムにより処理されてもよい。
　
（４）
「The key to the simplicity of the HyTM approach is that the HTM ensures that the condition checked by the transformed code remains true throughout a transaction that is successfully comitted. Observe that, even if a software transaction begins after an ongoing hardware transaction checks SW_CNT, this will cause the hardware transaction to abort unless it has already committed. 
 In scenarios in which virtually all transactions succeed in hardware, SW_CNT will usually be zero, and will usually be cached, so the overhead of the additional checking required for compatibility with software transactions will be very low. However, with this simple conflict detection scheme, even the occasional transaction that retries in software for whatever reason will cause all other hardware transactions to abort and retry, and possibly some of them will retry in software, thereby perpetuating the situation. For a HyTM implementation to be effective across a range of workloads, it should avoid this by also providing a more fine-grained approach to conflict detection. 
 One way to support finer-grained conflict detection is to further augment code for hardware transactions to detect conflicts at the granularity of orecs. Specifically, the code for hardware　transactions can lookup the orec associated with each location accessed to detect conflicting software transactions. Because software transactions indicate their mode of ownership(READ or WRITE), a hardware transaction does not have to abort if it reads a location in common with a software transactions that is also reading it.」（第９ページ第１〜１７行） 
（当審による訳） 
　HyTMアプローチの単純さの鍵は、変換されたコードによってチェックされる条件が成功裏に完了したトランザクションの間を通して真のままであることを、HTMが保証することである。たとえ進行中のハードウェアトランザクションがSW_CNTをチェックした後にソフトウェアトランザクションが開始したとしても、これは、ハードウェアトランザクションをそれがすでに完了している場合を除きアボートさせる、ということに留意されたい。 
　事実上全てのトランザクションがハードウェアで成功しているというシナリオにおいては、SW_CNTは普通ゼロであり、普通キャッシュされている。それゆえ、ソフトウェアトランザクションへの適合性のために必要とされる付加的なチェックのオーバヘッドは非常に小さい。しかしながら、この単純なコンフリクト検出スキームでは、どんな理由による時折のソフトウェアで再試行されるトランザクションであっても、他の全てのハードウェアトランザクションにアボートと再試行をもたらし、おそらく、それらのいくつかはソフトウェアで再試行され、それによって、その状況を永続させる。ワークロードのレンジをまたがる効果的なHyTMの実施のために、コンフリクト検出は、よりきめ細やかなアプローチも提供することで、これを避けるべきである。 
　よりきめ細やかなコンフリクト検出をサポートする一つの方法は、orecs（ownership records）の細かさでコンフリクトを検出するために、ハードウェアトランザクションのためのコードをさらに増大させることである。具体的には、ハードウェアトランザクションのためのコードは、ソフトウェアトランザクションとのコンフリクトを検出するために、アクセスされた各々の位置に関係付けられているorecを調べることができる。ソフトウェアトランザクションはそれらのオーナーシップのモード（リードあるいはライト）を示すので、ハードウェアトランザクションは、それがソフトウェアトランザクションと共通の位置をリードする場合には、アボートする必要はない。 
　
　ここで、引用例の上記記載事項を技術常識に照らせば、以下のことがいえる。
ア．上記（１）に摘記した箇所には、「ハードウェアトランザクションメモリアクセスに対応するスレッドの第１命令を実行するステップと、前記第１命令のコミットが失敗すると、ソフトウェアトランザクションメモリアクセスに対応する前記スレッドの第２命令を実行するステップと、を有する方法」といえる方法（以下、「方法Ａ」と呼ぶ。）が実質的に記載されている。
イ．上記（２）〜（４）に摘記した箇所には、「上記方法Ａにおいて、対応するメモリエントリのオーナシップレコーズ(orecs)を格納する」ことが実質的に記載されている。
　
　したがって、引用例には、
「ハードウェアトランザクションメモリアクセスに対応するスレッドの第１命令を実行するステップと、前記第１命令のコミットが失敗すると、ソフトウェアトランザクションメモリアクセスに対応する前記スレッドの第２命令を実行するステップと、
　対応するメモリエントリのオーナーシップレコーズ(orecs)を格納するステップと、
を有する方法。」の発明（以下、「引用例記載発明」と呼ぶ。）が記載されているといえる。 
　
３．対比
　本願発明と引用例記載発明を対比すると、引用例記載発明の「オーナーシップレコーズ(orecs)」は、オーナーシップ状態を表すフラグとして機能するものであり、また、当然に１以上のビットで構成されるものであるから、本願発明でいう「１以上のオーナーシップフラグビット」の概念に含まれる。
　したがって、本願発明と引用例記載発明の間には、以下の一致点、相違点があるといえる。
　
（一致点）
「　ハードウェアトランザクションメモリアクセスに対応するスレッドの第１命令を実行するステップと、
　前記第１命令のコミットが失敗すると、ソフトウェアトランザクションメモリアクセスに対応する前記スレッドの第２命令を実行するステップと、
　対応するメモリエントリのオーナーシップ状態を特定する１以上のオーナーシップフラグビットを格納するステップと、
を有する方法。」
である点。
　
（相違点）
　本願発明における「ハードウェアトランザクションメモリアクセス」は、「オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される」のに対し、引用例記載発明における「ハードウェアトランザクションメモリアクセス」は、「オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される」とは限らない（引用例には、「ハードウェアトランザクションメモリアクセスは、オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される」旨の明示的記載がない。）点。
　
４．判断
（１）上記（相違点）について
　以下の事情を勘案すると、引用例記載発明における「ハードウェアトランザクションメモリアクセス」を、「オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される」ようにすることは、当業者が容易に推考し得たことというべきである。 
ア．引用例の上記２．（４）に摘記した箇所の記載によれば、引用例記載発明の「ハードウェアトランザクションメモリアクセス」は、コンフリクト検出に応答して中断されるようにされ得るものと認められる。
イ．引用例の上記２．（４）に摘記した箇所の第１段落では、コンフリクト検出は「SW_CNT」の値によるものとされているが、同第３段落には、それに替えて、コンフリクト検出を上記「orecs（ownership records）」を利用して行うようにするのが好ましい旨記載されている。 
ウ．上記イ．に従って、引用例の上記２．（４）に摘記した箇所の第１段落に示される、「SW_CNT」の値によるコンフリクト検出を、同第３段落に示される「orecs（ownership records）」を利用したものに替える場合においても、上記ア．に示した事項を変える必要がないことは当業者に自明のことである。
エ．以上のことは、引用例記載発明における「ハードウェアトランザクションメモリアクセス」を、「オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して中断される」ようにすることが、当業者にとって容易であったことを意味している。 
　
（２）本願発明の効果について
　本願発明の構成によってもたらされる効果は、引用例の記載事項から当業者が予測し得る程度のものであり、本願発明の進歩性を肯定する根拠となり得るものではない。
　
（３）審判請求人の主張について
　審判請求人の、平成２５年７月３０日付けの意見書における主張は、その趣旨が必ずしも明確ではないが、善解すれば、大要以下の趣旨と解される。
ア．引用例のオーナーシップレコーズ(orecs)は、位置アドレスに対するハッシュ関数により決定されるテーブルであり、当該テーブルは別のエンティティであるのに対し、本願発明の「オーナーシップフラグ」は、図２に示されるように、他の要素を含むより大きな構成の一部であり、オーナーシップフラグ２２２は、バーチャルアドレス２１８、物理アドレス２２０及び投機フラグ２２４を含むエンティティの一部となっているから、本願発明の「対応するメモリエントリのオーナーシップ状態を特定する１以上のオーナーシップフラグビット」は、引用例のオーナーシップレコーズ(orecs)のテーブルとは異なる。
イ．引用例には、「ＳＷ＿ＣＮＴが非ゼロである場合、ハードウェアトランザクションメモリアクセスが中断する」旨の記載はあるが、ＳＷ＿ＣＮＴは本願発明の「オーナーシップフラグ」とは異なるから、引用例の当該旨の記載をもって、本願発明の「前記ハードウェアトランザクションメモリアクセスは、オーナーシップフラグが有効なオーナーシップ状態を示しているという決定に応答して、中断される」という特徴（以下、「特徴Ａ」と呼ぶ。）が引用例に記載されているとはいえない。
　
　以上の解釈による審判請求人の主張に対する当審の見解は以下のとおりである。
（ア）上記ア．の趣旨の主張について
　本願の図２に、オーナーシップフラグ２２２が、バーチャルアドレス２１８、物理アドレス２２０及び投機フラグ２２４を含むエンティティの一部とされる例が示されていることは審判請求人が主張するとおりであるが、本願発明を規定する請求項１２には、それに対応する技術的事項を表す記載はないから、上記ア．の趣旨の主張は、特許請求の範囲の記載に基づかない主張である。
　本願発明の「１以上のオーナーシップフラグビット」を、引用例記載発明の「オーナーシップレコーズ(orecs)」を含まないものに限定して解釈すべき理由はない。
（イ）上記イ．の趣旨の主張について
　引用例に上記特徴Ａについての明示的記載がないことについては、上記３．において（相違点）として取り上げているように、当審も異論を唱えるものではない。
　しかしながら、引用例に上記特徴Ａについての明示的記載がないことは、本願発明が進歩性を有することを意味しない。上記（１）、（２）で検討したところから明らかなように、引用例に上記特徴Ａについての明示的記載がなくても、本願発明は、引用例記載発明に基づいて当業者が容易に発明をすることができたものである。
　
５．まとめ
　以上のとおりであるから、本願発明は、引用例記載発明に基づいて当業者が容易に発明をすることができたものである。
　
６．むすび 
　以上のとおり、本願発明は、引用例記載発明に基づいて当業者が容易に発明をすることができた発明であるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。  
　よって、結論のとおり審決する。