【事件の表示】
　特願２００４−５３３７７１「スタックタイプのスナップショットバッファがネスト化されたインタラプトを処理すること」拒絶査定不服審判事件〔平成１６年　３月１８日国際公開、ＷＯ２００４／０２３３１４、平成１７年１２月　８日国内公表、特表２００５−５３７５８０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　２００３年９月１日（パリ条約による優先権主張外国庁受理２００２年９月３日、欧州特許庁）を国際出願日とする出願であって、
　平成１７年３月３日付けで特許法第１８４条の５第１項に規定される書面が提出されるとともに、国際出願日における明細書、請求の範囲、図面（図面の中の説明に限る。）及び要約の翻訳文が提出され、
　平成２０年１１月２７日付けで最初の拒絶理由通知（同年１２月２日発送）がなされ、
　平成２１年５月２１日付けで意見書が提出されるとともに、手続補正がなされ、
　平成２２年３月３１日付けで拒絶査定（同年４月２日発送）がなされ、
　同年７月２９日付けで審判請求がなされるとともに、手続補正がなされたものである。
　なお、同年１２月２８日付けで審査官より同法第１６４条第３項で規定する報告（前置報告）がなされ、
　平成２３年３月２５日付けで当審より審尋（同年同月２９日発送）がなされ、
　同年７月２５日付けで回答書が提出されている。
　
第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張
１．平成１７年３月３日付け翻訳文における各請求項の記載
　平成１７年３月３日付けで提出された、国際出願日における明細書、請求の範囲、図面（図面の中の説明に限る。）及び要約の翻訳文における（平成２１年５月２１日付け手続補正書による手続補正前の）特許請求の範囲の請求項１、７及び８は、次のとおりであった。
　
「【請求項１】
　１つ以上の機能ユニットと、１つ以上のレジスタファイルと、データメモリと、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファとを具備してなるデータプロセッサであって、
　前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段を備えることを特徴とするデータプロセッサ。」
　
「【請求項７】
　前記データメモリファシリティがスタックとして動作される、請求項１に記載のデータプロセッサ。
【請求項８】
　前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項７に記載のデータプロセッサ。」
　　
２．平成２０年１１月２７日付け拒絶理由通知
　平成２０年１１月２７日付けで原審が通知した拒絶理由は次のとおりである。
　
「１．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
２．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　
…（中略）…
　
　　　　　　　　　　　　　　　　　記
…（中略）…
　
［理由１］
［請 求 項］１−１４
…（中略）…
へ）請求項８に、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」との記載があるが、日本語として意味が不明である。
…（中略）…
　よって、本願の請求項１−１４に係る発明は明確でない。
　
　
［理由２］
［請 求 項］４、８、１４
…（中略）…
ヨ）請求項８に記載の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、明細書のいずれの記載に対応するのか不明である。
…（中略）…
　したがって、本願の請求項４、８、１４に係る発明は、発明の詳細な説明に記載したものでない。
…（後略）…」
　
３．平成２１年５月２１日付け意見書
　平成２１年５月２１日付けで請求人（特許出願人）が提出した意見書は次のとおりである。
　
「…（前略）…
　ヘ）請求項８（補正後の請求項６）の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について
　補正前の請求項８（補正後の請求項６）における「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、図２、図３に示されている。
　図２は、スタックに基づくスナップショットバッファの内部配列を示したものである。明細書の段落［００１４］に記載されたように、このバッファは、複数のシャドウフリップフロップで構成されており、ワード５２が並列に配置された並列ワード群５０として示されている。各シャドウフリップフロップは、図３に示されたように、プロセッサリソース内に配置された対応する状態表示フリップフロップに接続されている。
　これらのワードは、インタラプト処理が実行されている間、ライン６２を介して、ワード５２へ１個ずつ格納される。ワード５２の選択は、マルチプレクサ５８を制御するためのスタックポインタ５８によって制御される。スタックポインタ５８は、ワード５２内に各データを格納するように動作する。
…（中略）…
　ヨ）請求項８の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について
　上記（３−１）ヘ）において、「スタックポインタ」について述べた通りである。
…（中略）…
　（４−１）　請求項４、７、１３を削除し、補正前の請求項１〜３を新たな請求項１〜３、補正前の請求項５〜６を新たな請求項４〜５、補正前の請求項８〜１２を新たな請求項６〜１０、補正前の請求項１４を補正後の請求項１１とする補正を行った。
…（中略）…
　（４−４）　補正前の請求項７の内容を補正前の請求項８、９に合体させて、補正後の請求項６、７とする補正を行った。
…（後略）…」
　
４．平成２１年５月２１日付け手続補正後の各請求項の記載
　平成２１年５月２１日付けで請求人（特許出願人）が提出した手続補正書による手続補正後の（平成２２年７月２９日付け手続補正書による手続補正前の）特許請求の範囲の請求項１及び６の記載は、次のとおりであった。
　
「　【請求項１】
　１つ以上の機能ユニットと、１つ以上のレジスタファイル（２２、２４）と、データメモリ（４０）と、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファ（２０）とを具備してなるデータプロセッサであって、
　前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段（３０）を備え、
　スタックに基づくレジスタファイルとして、スナップショットバッファが動作されるように配列されていることを特徴とするデータプロセッサ。」
　
「　【請求項６】
　前記データメモリファシリティがスタックとして動作され、前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項１に記載のデータプロセッサ。」
　
５．平成２２年３月３１日付け拒絶査定
　原審が平成２２年３月３１日付けで行った拒絶査定は、次のとおりである。
　
「この出願については、平成２０年１１月２７日付け拒絶理由通知書に記載した理由１、２、４によって、拒絶をすべきものです。
　なお、意見書並びに手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。
　
［備考］
（理由１及び２について）
…（中略）…
ヘ）、ヨ）請求項６の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」と、「多数のスタック位置を許容する」との関連・意味が依然として不明であり、明細書のいずれの記載に対応するのかも依然として不明である。
…（中略）…
　なお、上記［備考］で検討したほかに、補正書において補正された請求項には、以下の拒絶理由がある。
…（中略）…
２．補正書において補正された請求項について、下記の点は、特許法第３６条第６項第１号に規定する要件を満たしていない。
Ｄ）請求項６に記載の事項が、具体的な実施の形態として、発明の詳細な説明のいずれの記載に対応するのか不明である。
…（中略）…
　よって、本願の請求項６、７、９に係る発明は、発明の詳細な説明に記載したものでない。」
　
６．平成２２年７月２９日付け審判請求書
　平成２２年７月２９日付けで請求人が提出した審判請求書は、次のとおりである。
　
「…（前略）…  
　（ｂ）記載不備並びに補正の根拠について 
…（中略）…
　ヘ）、ヨ）、Ｄ）請求項６の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について 
　「前記データメモリファシリティがスタックとして動作され」という記載を、「前記スナップショットバッファがスタックとして動作され」とする補正を行った。 
　この補正事項は、出願当初の明細書の段落[００１４]における記載「図２は、スタックに基づくスナップショットバッファの内部構成のブロック図を示している。バッファは、別個に図示されていない複数のシャドウフリップフロップから構成されており、これらはワード５２のみが示されている並列ワード群５０において組織化されている。ワード長さの決定は、ニーズと、データ経路幅などの利用可能なプロセッサファシリティとに応じて行われる。各シャドウフリップフロップは、プロセッサリソース内に位置する対応する状態指示フリップフロップに接続されている。インタラプトの処理中、この状態を保存しなければならないが、以後は図３を参照すること。スナップショットバッファにおいて、様々なシャドウワードに対する入力はデマルチプレクサ５４に接続されており、正確な１ワードをいつでも書き込みすることができる。同様に、スナップショットバッファにおいて、様々なシャドウワードからの出力はマルチプレクサ５６に送られ、正確な１ワードの読み出しを行うことがいつでも可能である。」、並びに段落[００１６]における記載「本実施例において、スナップショットバッファはそれ自身の内部スタックポインタを維持するので、標準ランダムアクセスレジスタファイルで必要であったような、上記読み出し／書き込みコマンドの何れもレジスタアドレスを必要としない。従って、スナップショットバッファにおけるレジスタのアドレッシングを行うために、命令ビットが別途必要となることはない。ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがＤＭ４０にコピーされて、新しいデータのための場所が確保される。」に基づくものである。 
　この補正は、明瞭でない記載の釈明を目的とし、拒絶理由通知に係わる拒絶の理由に示す事項についてするものである。 
　後述する参考図４ａから参考図４ｎに示されたように、スナップショットによりプロセッサ状態が並列ワード群内にコピーされる。この並列ワード群は、スタックとして動作する。 
　明細書の段落[００１６]に記載されたように、スタックポインタレジスタ５８内に保存されたスタックポインタはインタラプトのレベルに関連せず、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連する。
…（中略）… 
　尚、請求項２、１１を削除したことに伴い、補正前の請求項１、３〜１０は、補正後に新たな請求項１、２〜９となった。 
…（中略）…  
　（ｃ）本願発明と引用文献１〜２との対比 
　１）本願発明はデータプロセッサに係わり、プロセッサにより通常のメインスレッドが処理されている最中に、Ｉ／Ｏ等に関するインタラプトが発生することがある。インタラプトされる前の処理を保存するために、プロセッサはシャドウバッファを備えている。各々のプロセッサ状態要素は、シャドウバッファ内に対応するスナップショットバッファ要素を有しており、これにより、インタラプト処理の状態情報を迅速に保存することができ、またプロセッサはインタラプト処理を開始することができる。 
　インタラプトの処理中に、他のより高い優先度を有するインタラプトが発生することがある。このような場合、シャドウバッファが１番目のインタラプト処理の状態情報を格納する前に、シャドウバッファ内のデータを他の保存場所に格納しておく必要がある。 
　状態情報のデータ量は、データパス幅を超える複数ビットから成るデータ量を有する。従って、インタラプトにより状態情報をメモリに保存する場合、異なるレジスタをアドレスする必要がある。 
　本願発明によれば、本願の図２に示されたように、スナップショットバッファがスタックベースレジスタファイルとして動作する。これにより、スナップショットバッファ内のレジスタをアドレスする必要がなくなる。 
　添付された参考図面を用いて、本願発明の動作を説明する。 
　参考図１は、プロセッサのスナップショットバッファ２０とリソースフリップフロップ７０との関係を示す。スナップショットバッファ２０は、シャドウフリップフロップ７２を備え、シャドウフリップフロップ７２は並列ワード５２の群５０内に構成されている。 
　本願明細書の段落[００１４]において、図２を参照してスナップショットバッファについて記載されている。シャドウフリップフロップ７２は、図３に示されたように、リソースフリップフロップ７０に接続されている。 
　参考図１に示されたメインスレッドを処理している最中に、参考図２に示されたようにインタラプトＩＮＴ１が発生したとする。メインスレッドの状態情報がスナップショットバッファ２０内に保存される。 
　参考図３に示されたように、プロセッサはインタラプトＩＮＴ１の処理を実行することが可能となる。 
　インタラプトＩＮＴ１の処理を実行している最中に、引き続いてインタラプトＩＮＴ２が発生した場合には、スナップショットバッファ２０の内容が、参考図４ａ、…、参考図４ｎに示されたようにメモリに保存される。 
　スナップショットバッファ２０は、スタックに基づくレジスタとして動作する。参考図４ａから参考図４ｎに示されたように、メモリ内に格納されるべきスタックポインタレジスタ５８内のスタックポインタによって、スナップショットバッファ５０のパラレルワード５２が一つずつ選択される。 
　このことと関連し、明細書の段落[００１６]において「スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」と記載されている。 
　参考図５に示されたように、１番目のインタラプトの処理の状態情報のスナップショットが撮られた後、参考図６に示されたように２番目のインタラプトの処理が実行される。 
　参考図７に示されたように、２番目のインタラプトＩＮＴ２の処理が完了すると、プロセッサは、スナップショットバッファ２０内に保存された状態情報を用いて、未だ完了していない１番目のインタラプトＩＮＴ１の処理を続けることができる。 
　参考図８ａから参考図８ｎに示されたように、保存されているメインスレッドの状態情報がメモリから取り出されてスナップショットバッファ２０内に１ワード毎に格納される。 
　最終的に、１番目のインタラプトＩＮＴ１の処理が完了すると、スナップショットバッファ２０内の情報を本来のリソースフリップフロップ７０内にコピーした後、プロセッサが１番目のインタラプトが発生する前に処理していたメインスレッドに戻る。 
…（中略）…
　本願発明におけるスタックに基づくレジスタとして動作するスナップショットバッファは、参考図４ａから参考図４ｎを用いて上述したように、スナップショットバッファ２０内の情報が、本願の図２に示されたスタックポインタレジスタ５８内のスタックポインタの制御に基づいて、１ワード毎に保存される。 
　同様に、参考図８ａから参考図８ｎを用いて上述したように、スナップショットバッファ２０内の情報は、スタックポインタの制御に基づいて１ワード毎に再度書き込まれる。 
　このような本願発明におけるスナップショットバッファ自体がスタックに基づくレジスタとして動作する構成を備えたことにより、アドレスする際にレジスタインデックスが要求されず、アドレスビットの格納の際におけるアドレスの書き込みを必要最小限とし、消費電力の増加を防止することができる。 
…（後略）…」
　
７．平成２２年７月２９日付け手続補正後の各請求項の記載
　平成２２年７月２９日付けで請求人が提出した手続補正書による手続補正後の請求項１及び５の記載は、次のとおりである。
　
「　【請求項１】
　１つ以上の機能ユニットと、１つ以上のレジスタファイル（２２、２４）と、データメモリ（４０）と、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファ（２０）とを具備してなるデータプロセッサであって、
　前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段（３０）を備え、
　スタックに基づくレジスタファイルとして、スナップショットバッファが動作されるように配列されていることを特徴とするデータプロセッサ。」
　
「　【請求項５】
　前記スナップショットバッファがスタックとして動作され、前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項１に記載のデータプロセッサ。」
　
８．平成２２年１２月２８日付け前置報告書
　平成２２年１２月２８日付けで審査官が行った特許法第１６４条第３項で規定する報告（前置報告）は、次のとおりである。
　
「請求時の補正は、不明りょうな記載の釈明を目的としたものと認める。
　しかしながら、本願は、以下の理由により特許を受けることができない。
　　
…（中略）…
・理由２
・根拠条文：　特許法第３６条第６項第２号
・請求項：　　１−９
・特許査定できない理由
…（中略）…
（３）請求項５の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」とは、スナップショットバッファの何に対応するのか不明であり、「各スナップショットごと」と「多数のスタック位置を許容する」との関連・意味が依然として不明である。
…（中略）…
　よって、本願の請求項１−９に係る発明は明確でないから、特許法第３６条第６項第２号に規定する要件を満たしておらず、特許を受けることができない。」
　
９．平成２３年７月２５日付け回答書
　平成２３年７月２５日付けで請求人が提出した回答書は、次のとおりである。
　
「…（前略）…
　３）請求項５の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について 
　明細書の段落[０００３]において、「上記のスケジューリングアプローチは、ＮＵＡＬ−ＥＱ意味論（Ｎｏｎ　Ｕｎｉｔ　Ａｓｓｕｍｅｄ　Ｌａｔｅｎｃｙ　ｗｉｔｈ　Ｅｑｕａｌ）と呼ばれている。ＮＵＡＬ−ＥＱに基づいてコンパイル時間スケジューリングをサポートする常に割込可能なプログラム可能プロセッサは、インタラプト処理方式の一部として復元されるべき内部プロセッサパイプラインから正確なスナップショットを撮ることが必要である。」と記載されているように、スナップショットは、インタラプト処理方式の一部として復元されるべき、内部プロセッサパイプラインを表わします。 
　請求項５において記載されているように、多数のスタック位置が、スナップショットを格納するために用いられます。 
　このことは、スナップショットは、多数のスタック位置に格納されることを意味し、図２に示されたようです。 
　スナップショット情報を格納するシャドウフリップフロップが、複数のワード線５２において組織化されています。複数のワード線５２のそれぞれがスタック位置に対応し、スタックポインタレジスタ５８内に格納されたスタックポインタによりその選択が可能です。 
…（中略）…
 （４）　本願発明と引用文献との相違について 
…（中略）…
　しかし本願発明では、スナップショットバッファがスタックに基づいて構成されています。 
　平成２２年７月２９日付けの審判請求書に添付された参考図４ａ〜４ｎに示された状態において、スナップショットバッファの内容がワード毎に、図２に示されたスタックポインタレジスタ５８の制御により格納されます。同審判請求書に添付された参考図８ａ〜８ｎに示された状態において、スナップショットバッファの内容がワード毎に、図２に示されたスタックポインタレジスタ５８の制御により再度書き込まれます。 
　即ち、スナップショットバッファがスタックに基づくレジスタファイルとして構成されたことにより、スナップショットバッファ２０の内容を格納するとき、アドレスされる必要性を回避することができます。 
…（中略）…
　４）本願発明は、以前のインタラプトを処理している間に発生した後続のインタラプトにおいて、メモリへスナップショットバッファのデータを格納することが可能であり、スナップショットバッファ内のプロセッサデータの迅速な格納、インタラプトに対する迅速な応答が実現されます。 
　引用文献３のマイクロコンピュータ装置と異なり、本願発明は、スナップショットが複数のスタック位置に格納される、スタックに基づくスナップショットバッファを備えています。これにより、通常のデータパスを使ってスナップショットバッファとメモリとの間でデータを交換することが可能となります。複数のレジスタをスナップショットバッファとして用いることができるため、スナップショットバッファ内に格納可能なデータ量の増加が可能となります。 
…（後略）… 」
　　
第３．当審の判断
１．はじめに
　上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」から明らかなように、本願の請求項５における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は、平成１７年３月３日付けで提出された、国際出願日における明細書、請求の範囲、図面（図面の中の説明に限る。）及び要約の翻訳文における特許請求の範囲の請求項８にもあった記載であり、平成２１年５月２１日付け手続補正書による手続補正後の特許請求の範囲の請求項６にもあった記載である。
　また、上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」から明らかなように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審は平成２０年１１月２７日付け拒絶理由通知にて「日本語として意味が不明である。」と指摘して特許法第３６条第６項第２号の規定を満たしていないとし、同拒絶理由通知にて「明細書のいずれの記載に対応するのか不明である。」と指摘して同法同条同項第１号の規定を満たしていないとしている。続いて、原審は平成２２年３月３１日付け拒絶査定にて「「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」と、「多数のスタック位置を許容する」との関連・意味が依然として不明」であると指摘して特許法第３６条第６項第２号の規定を満たしていないという拒絶理由が解消していないとし、「「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、…（中略）…明細書のいずれの記載に対応するのかも依然として不明である。」と指摘して同法同条同項第１号の規定を満たしていないという拒絶理由が解消していないとしている。
　そこで、本願の請求項５における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願が特許法第３６条第６項第２号の規定及び同法同条同項第１号の規定を満たしているものであるか否かを検討する。
　
２．特許法第３６条第６項第２号の規定に関する検討
　請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審が平成２０年１１月２７日付け拒絶理由通知にて「日本語として意味が不明である。」と指摘しているので、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が日本語として意味が不明であるか否かを検討する。
　請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を当業者が解釈しようとすると、１つの「スタック」に同時に含まれる「スナップショット」の数が単数と複数のいずれであるか、及び、１つの「スナップショット」に対応する「スタック位置」の数が単数と複数のいずれであるかによって、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す、「スタック」に「スナップショット」が格納される態様が異なるものとなり、「スタックポインタ」の挙動も異なるものとなる。しかしながら、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を解釈するに際しては、１つの「スタック」に同時に含まれる「スナップショット」の数が単数か複数かが不明である。また、同記載を解釈するに際しては、１つの「スナップショット」に対応する「スタック位置」の数が単数か複数かが不明である。さらに、同記載を解釈するに際しては、「各スナップショットごとに多数のスタック位置を許容する」ことと「スタックポインタ」の関係が明確でない。このように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が多義的であって当該記載の意味を特定できず、また、当該記載の意味するところが明確でない点もある。
（なお、後述の「３．特許法第３６条第６項第１号の規定に関する検討」で示すように、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が多義的である点について、明細書等を参酌しても、いくつか想定される解釈のいずれかひとつであると特定することもできない。）
　以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は日本語として意味が不明であり、本願は特許法第３６条第６項第２号の規定を依然として満たしていない。
　
　また、一般に、情報処理の技術分野において、スタックという用語は、互いに時間的な前後関係があるデータを複数個積み上げる態様で管理する記憶手段を意味する。
　そして、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を解釈するに際し、１つの「スタック」に同時に含まれる「スナップショット」の数が１つであると解釈した場合には、１つのスタックのなかに同時には異なるスナップショットが存在しないのであるから、１つのスタックのなかに同時に存在するデータの間にはなんら時間的な前後関係がないことになる。そうすると、当該解釈のもとでは請求項での「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載における「スタック」は、もはや、情報処理の技術分野におけるスタックであるとはいえない。そのため、当該解釈のもとでは、請求項における「スタック」という語が情報処理の技術分野の通常の日本語における「スタック」を意味するとはいえず、請求項での「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載における「スタック」、「スタック位置」及び「スタックポインタ」が意味するところが明確であるとはいえない。
　以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は日本語として意味が不明であり、本願は依然として特許法第３６条第６項第２号の規定を満たしていない。
　
３．特許法第３６条第６項第１号の規定に関する検討
　請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審が平成２０年１１月２７日付け拒絶理由通知にて「明細書のいずれの記載に対応するのか不明である。」と指摘しているので、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が明細書のいずれかに記載されたものといえるかを検討する。
　
３の１．想定される３つの解釈
　上記「２．特許法第３６条第６項第２号の規定に関する検討」で示したように、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載においては、１つの「スタック」に同時に含まれる「スナップショット」の数が単数か複数かが不明であり、また、１つの「スナップショット」に対応する「スタック位置」の数が単数か複数かが不明である。その意味で多義的であることは既に示したところである。
　ここで、１つの「スタック」に同時に含まれる「スナップショット」の数と、１つの「スナップショット」に対応する「スタック位置」の数のそれぞれについて、単数の場合と複数の場合の組み合わせを考慮すると（ただし、請求項における「前記スタックが、…（中略）…多数のスタック位置を許容する」の記載に基づいて、上記した２つの数がいずれも単数の場合については除外する。）、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載の解釈としては、強いて想定すれば、一応以下の３つが考えられる。
　
　解釈１）１つのスタックには同時には１つのスナップショットが存在し得て、１つのスナップショットが複数のスタック位置にわたって格納される。スタックポインタは、１つのスナップショットが格納される複数のスタック位置のうちの１つのスタック位置を指し示すものである。
　解釈２）１つのスタックには同時には複数のスナップショットが存在し得て、１つのスナップショットが複数のスタック位置にわたって格納される。スタックポインタは、複数のスナップショットの内の１つのスナップショットについて、当該１つのスナップショットが格納される複数のスタック位置のうちの１つのスタック位置を指し示すものである。
　解釈３）１つのスタックには同時には複数のスナップショットが存在し得て、１つのスナップショットは１つのスタック位置に格納される。スタックポインタは、複数のスナップショットのうちの１つのスナップショットが格納される１つのスタック位置を指し示すものである。
　　
　そこで、明細書等の記載を参酌して、上記した３つの解釈のいずれのひとつであるかを特定して、その特定した解釈に基づく発明が明細書の発明の詳細な説明に記載したものであるとすることができるか、つまりは、上記した３つの解釈のいずれのひとつが、明細書の発明の詳細な説明に記載され、かつ、矛盾無く記載された技術的事項に対応しているといえるかを検討する。
　
３の２．解釈１の検討
　明細書の【０００８】には次のように記載されている。
　
「…（前略）…スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。…（後略）…」
　
　また、明細書の【００１８】には次のように記載されている。
　
「各インタラプト処理の開始時に、各通常フリップフロップの数値をその対応するシャドウフリップフロップに即座にコピーすることにより、単一のクロック周期内で関連するプロセッサ状態から完全スナップショットを取る。同様に、各インタラプト処理の終了時に、各シャドウフリップフロップをその対応する通常フリップフロップに即座にコピーすることにより、完全スナップショットをスナップショットバッファからプロセッサに適切に復元される。」
　
　仮に上記解釈１を採用すると、１つのスタックに同時に存在するただ１つのスナップショットが格納される複数のスタック位置は、互いに同じスナップショットを構成する各スナップショット要素を格納しているのであって、各スタック位置に格納されるスナップショット要素間には時間的な前後関係はないことになる。上記【００１８】の記載も考慮すれば、１つのスタックに同時に存在するただ１つのスナップショットが格納される複数のスタック位置について、スタック位置相互間では通常フリップフロップからスナップショットを取るタイミングに何ら前後関係がないので、なおさらのこと、上記解釈１を採用すると、１つのスタックに含まれる各スタック位置に格納されるスナップショット要素間には時間的な前後関係はないことになる。
　しかしながら、上記【０００８】には「スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。」と記載されている。つまり、上記【０００８】によれば、１つのスタックの１つのスタック位置から読み出して、スタックポインタの数値が減少したときに、スタックポインタに新たに指し示されるスタック位置は「前回のスタック最上部」であり、１つのスタックの１つのスタック位置に書き込んで、スタックポインタの数値が増加したときに、スタックポインタに新たに指し示されるスタック位置は「次のスタック最上部」である。結局のところ上記【０００８】によれば、１つのスタックに含まれる各スタック位置に格納されるスナップショット要素間に時間的な前後関係があることになる。
　以上のとおり、明細書等には上記解釈１とは矛盾する記載があるので、上記解釈１を採用した場合における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明に記載したものであるとはいえない。
　
３の３．解釈２の検討
３の３の１．スタック位置間の時間的前後関係について
　仮に上記解釈２を採用すると、１つのスナップショットが複数のスタック位置にわたって格納されることになるので、同じスナップショットを構成するスタック位置の間では時間的な前後関係がないことになる。
　これに対し、上記「３の２．解釈１の検討」で既に示したように、上記【０００８】には「スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。」と記載されている。つまり、上記【０００８】によれば、１つのスタックの１つのスタック位置から読み出して、スタックポインタの数値が減少したときに、スタックポインタに新たに指し示されるスタック位置は「前回のスタック最上部」であり、１つのスタックの１つのスタック位置に書き込んで、スタックポインタの数値が増加したときに、スタックポインタに新たに指し示されるスタック位置は「次のスタック最上部」である。結局のところ上記【０００８】によれば、１つのスタックに含まれる各スタック位置に格納されるスナップショット要素間に時間的な前後関係があることになる。
　以上のとおり、明細書等には上記解釈２とは矛盾する記載があるので、上記解釈２を採用した場合における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明に記載したものであるとはいえない。
　
３の３の２．スタックポインタの数について
　上記解釈２を採用すると、１つのスタックに同時に複数のスナップショットが存在し得ることになるが、その一方で明細書の【００１５】には次のとおり記載されている。
　
「デマルチプレクサ５４およびマルチプレクサ５６の両者は、同様にスナップショットバッファに位置するスタックポインタレジスタ５８からのスタックポインタによって制御される。実際、ライン６２上のスナップショットバッファからの読み出しはネスト化されたインタラプトの開始時に必要となるだけであり、またライン６０上のスナップショットバッファへの書込はネスト化されたインタラプトの終了時に必要となるだけである。従って、これらの２つの動作は同時に生じることはなく、スタックバッファにおける異なるワードのインターリーブアドレッシングを制御するのに単一のポインタレジスタ５８で十分である。ポインタ数値は、その後ポインタレジスタ５８の再ロードを行うために、ライン６２（当審注：図面第２図を参酌すればこの「ライン６２」は誤記であり、正しくは「ライン６４」である。）上でポインタアップデート制御部６６に逆結合されている。図に示すように、３動作制御ライン６８により、ポインタ数値に対して読み出しモード、書き込みモード、無動作モードが可能となる。効果的な動作は、（直線逆結合を介して）減少要素（−１）、増加要素（＋１）、無動作要素において実行される。」
　
　そして、この【００１５】の記載に対応して、図面第２図にはスナップショットバッファであるスタックのためにスタックポインタがただ１つ設けられていることが示されている。
　
　しかしながら、上記解釈２を採用し、１つのスタックであるスナップショットバッファに同時に複数のスナップショットが存在し得ることになると、（Ａ）状態指示フリップフロップ（通常フリップフロップ、状態レジスタ）からスナップショットを取ってスナップショットバッファに格納する際のスナップショットと、（Ｂ）スナップショットバッファからバックグラウンドデータメモリにスナップショットを退避させる際のスナップショットとが、１つのスタックであるスナップショットバッファ上で異なるスタック位置（またはスタック位置群）となりうることは自明であり、上記（Ａ）のスナップショットのためのスタック位置（またはスタック位置群）を指し示すポインタと、上記（Ｂ）のスナップショットのためのスタック位置（またはスタック位置群）を指し示すポインタを別々に設けざるを得ないことは当業者にとって技術常識である。
　つまり、当業者の技術常識からは、状態指示フリップフロップ（通常フリップフロップ、状態レジスタ）からスナップショットを取ってスナップショットバッファに格納し、スナップショットバッファからバックグラウンドデータメモリにスナップショットを退避させるという本願で構築しようとするシステムでは、スナップショットバッファであるスタックにおいて、状態指示フリップフロップ（通常フリップフロップ、状態レジスタ）からスナップショットを取ってスナップショットバッファに格納する（一般的にはこの格納のことをプッシュという。）際に格納先となるスタック位置（またはスタック位置群）を指し示すポインタと、スナップショットバッファからバックグラウンドメモリにスナップショットを退避させる際に読み出し元となるスタック位置（またはスタック位置群）を指し示すポインタの２つのポインタを要するといわざるを得ない。
　これに対し、上記【００１５】及び図面第２図には、スナップショットバッファであるスタックのためのポインタがただ１つである旨が示されている。そして、このただ１つのポインタにより、状態指示フリップフロップ（通常フリップフロップ、状態レジスタ）からスナップショットを取ってスナップショットバッファに格納する（一般的にはこの格納のことをプッシュという。）際に格納先となるスタック位置（またはスタック位置群）を指し示すことと、スナップショットバッファからバックグラウンドメモリにスナップショットを退避させる際に読み出し元となるスタック位置（またはスタック位置群）を指し示すことの両方をいかにして行うのかが、明細書の発明の詳細な説明には記載されていない。結局のところ、上記解釈２を採用した場合の本願の請求項５に係る発明に対応する記載は明細書の発明の詳細な説明にはないということになる。
　以上のとおり、仮に上記解釈２を採用すると、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載と明細書等の記載は矛盾するので、上記解釈２に基づく本願の請求項５に係る発明、特に請求項５における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明が記載したものであるとはいえない。
　　
３の４．解釈３の検討
　上記解釈３を採用すると、１つのスタックに同時に複数のスナップショットが存在し得ることになる。そうすると、上記「３の３．解釈２の検討」の「３の３の２．スタックポインタの数について」で既に示した理由と同様の理由で、仮に上記解釈３を採用すると、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載と明細書等の記載は矛盾するので、上記解釈３に基づく本願の請求項５に係る発明、特に請求項５における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明が記載したものであるとはいえない。
　
３の５．特許法第３６条第６項第１号の規定の検討に関する小括
　上記３の２．乃至３の４．で示したように、上記３の１．で仮に想定した３つの解釈のいずれも、明細書の発明の詳細な説明に記載され、かつ、矛盾無く記載された技術的事項に対応しているとはいえない。つまり、明細書等の記載を参酌しても、上記した３つの解釈のいずれのひとつであるかを特定したとしても、特定された解釈に基づく発明が明細書の発明の詳細な説明に記載されているとすることはできない。
　以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は明細書のいずれかに記載されたものとはいえず、本願は特許法第３６条第６項第１号の規定を依然として満たしていない。
　
４．小括
　上記２．で示したように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願は特許法第３６条第６項第２号の規定を満たしていない。
　また、上記３．で示したように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願は特許法第３６条第６項第１号の規定を満たしていない。
　　
５．請求人の主張について
５の１．平成２２年７月２９日付け審判請求書について
　上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「６．平成２２年７月２９日付け審判請求書」に示したように、請求人は「後述する参考図４ａから参考図４ｎに示されたように、スナップショットによりプロセッサ状態が並列ワード群内にコピーされる。この並列ワード群は、スタックとして動作する。」、「状態情報のデータ量は、データパス幅を超える複数ビットから成るデータ量を有する。従って、インタラプトにより状態情報をメモリに保存する場合、異なるレジスタをアドレスする必要がある。」、「参考図１に示されたメインスレッドを処理している最中に、参考図２に示されたようにインタラプトＩＮＴ１が発生したとする。メインスレッドの状態情報がスナップショットバッファ２０内に保存される。」、「インタラプトＩＮＴ１の処理を実行している最中に、引き続いてインタラプトＩＮＴ２が発生した場合には、スナップショットバッファ２０の内容が、参考図４ａ、…、参考図４ｎに示されたようにメモリに保存される。」、「スナップショットバッファ２０は、スタックに基づくレジスタとして動作する。参考図４ａから参考図４ｎに示されたように、メモリ内に格納されるべきスタックポインタレジスタ５８内のスタックポインタによって、スナップショットバッファ５０のパラレルワード５２が一つずつ選択される。」、「参考図５に示されたように、１番目のインタラプトの処理の状態情報のスナップショットが撮られた後、参考図６に示されたように２番目のインタラプトの処理が実行される。」、「参考図７に示されたように、２番目のインタラプトＩＮＴ２の処理が完了すると、プロセッサは、スナップショットバッファ２０内に保存された状態情報を用いて、未だ完了していない１番目のインタラプトＩＮＴ１の処理を続けることができる。」、「参考図８ａから参考図８ｎに示されたように、保存されているメインスレッドの状態情報がメモリから取り出されてスナップショットバッファ２０内に１ワード毎に格納される。」、「本願発明におけるスタックに基づくレジスタとして動作するスナップショットバッファは、参考図４ａから参考図４ｎを用いて上述したように、スナップショットバッファ２０内の情報が、本願の図２に示されたスタックポインタレジスタ５８内のスタックポインタの制御に基づいて、１ワード毎に保存される。」、「同様に、参考図８ａから参考図８ｎを用いて上述したように、スナップショットバッファ２０内の情報は、スタックポインタの制御に基づいて１ワード毎に再度書き込まれる。」と主張している。当該主張は、上記３の１．で示した解釈１に基づくものであると解される。
　しかしながら、既に上記３の２．で示したように、明細書等は上記解釈１を採用できる程度に矛盾無く記載されているとはいえない。つまり、上記解釈１は明細書等の記載から自明に導き出せるものではない。よって、審判請求書における上記された主張は明細書等の記載に適切な根拠がなく、審判請求書における上記された主張を採用することはできない。
　
　また、上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「６．平成２２年７月２９日付け審判請求書」に示したように、請求人は「明細書の段落[００１６]に記載されたように、スタックポインタレジスタ５８内に保存されたスタックポインタはインタラプトのレベルに関連せず、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連する。」、「このことと関連し、明細書の段落[００１６]において「スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」と記載されている。」と主張している。そこで、請求人が主張の根拠としている明細書の【００１６】について検討する。
　当該主張に係る明細書の【００１６】は次のとおりである。
　
「…（前略）…ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがＤＭ４０にコピーされて、新しいデータのための場所が確保される。」
　
　上記【００１６】のうち「インタラプトのレベル」という語については、明細書等における他の箇所を参照しても、これに関する説明が一切無く、その技術的な意味内容が不明である。また「インタラプトのレベル」という語自体が明確にひとつの意味を指し示すともいえない。さらに、これに関連して、「スタックポインタの実際の数値はインタラプトのレベルに関連していない」という文の意味するところも不明である。
　また、上記【００１６】のうち「状態レジスタ」という語についてもどのような動作をするものか理解できず、さらに、明細書等における他の箇所を参照しても「状態レジスタ」に関する説明がなされておらず、如何なる技術的意味を有するものであるのか不明である。仮に「状態レジスタ」が【００１４】の「状態指示フリップフロップ」や【０００７】の「通常のフリップフロップ」や【００１７】の「通常のリソースフリップフロップ」や【００１８】の「通常フリップフロップ」に相当するものであると解釈したとしても、上記【００１６】の「特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンス」という句は、特定のインタラプトに対して、状態情報を保持する通常のレジスタ（フリップフロップ）に、状態情報等のデータが書き込まれる際におけるシーケンス、といった意味になる。一方で、明細書等の記載（特に、明細書の【００１８】の「各インタラプト処理の開始時に、各通常フリップフロップの数値をその対応するシャドウフリップフロップに即座にコピーすることにより、単一のクロック周期内で関連するプロセッサ状態から完全スナップショットを取る。同様に、各インタラプト処理の終了時に、各シャドウフリップフロップをその対応する通常フリップフロップに即座にコピーすることにより、完全スナップショットをスナップショットバッファからプロセッサに適切に復元される。」という記載）を参酌すれば、本願におけるただ一つのスタックポインタは、状態情報を保持する通常のレジスタ（フリップフロップ）への読み書きを直接制御するわけではない。結局のところ、「状態レジスタ」が【００１４】の「状態指示フリップフロップ」や【０００７】の「通常のフリップフロップ」や【００１７】の「通常のリソースフリップフロップ」や【００１８】の「通常フリップフロップ」に相当するものと解釈しても、上記【００１６】の「スタックポインタの実際の数値は…（中略）…特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」という文の文意を理解することができない。
　さらに、上記【００１６】における「次のインタラプトが明白になる」という文と「次のインタラプトが到着する」の文のそれぞれの技術的意味及び両者間の技術的相違点が理解できない。加えて、上記【００１６】における「スタック」が、スナップショットバッファを意味するのか、バックグラウンドデータメモリを意味するのか、または、それ以外の何かを意味するのかが明確でない。これらのことを併せて考慮すれば、上記【００１６】の「次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがＤＭ４０にコピーされて、新しいデータのための場所が確保される。」の意味するところが不明である。
　このように、上記【００１６】の「ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがＤＭ４０にコピーされて、新しいデータのための場所が確保される。」の部分は、意味するところが不明であり、この箇所を根拠とする審判請求書における上記主張は採用することができない。
　
５の２．平成２３年７月２５日付け回答書について
　上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「９．平成２３年７月２５日付け回答書」に示される請求人の主張は、上記「第２．請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「６．平成２２年７月２９日付け審判請求書」に示される請求人の主張と同様のものであり、やはり採用することはできない。
　
第４．むすび
　したがって、本願は特許請求の範囲の記載が特許法第３６条第６項第２号に規定する要件を満たしていない。
　また、本願は特許請求の範囲の記載が特許法第３６条第６項第１号に規定する要件を満たしていない。
　
　よって、結論のとおり審決する。