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

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

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

PDF	PDFをダウンロード

審決分類	審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない。 G06F 審判査定不服特36条4項詳細な説明の記載不備特許、登録しない。 G06F
管理番号	1254138
審判番号	不服2010-17004
総通号数	149
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2012-05-25
種別	拒絶査定不服の審決
審判請求日	2010-07-29
確定日	2012-03-19
事件の表示	特願2004-533771「スタックタイプのスナップショットバッファがネスト化されたインタラプトを処理すること」拒絶査定不服審判事件〔平成16年 3月18日国際公開、WO2004/023314、平成17年12月 8日国内公表、特表2005-537580〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1.手続の経緯本願は、 2003年9月1日(パリ条約による優先権主張外国庁受理2002年9月3日、欧州特許庁)を国際出願日とする出願であって、平成17年3月3日付けで特許法第184条の5第1項に規定される書面が提出されるとともに、国際出願日における明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の翻訳文が提出され、平成20年11月27日付けで最初の拒絶理由通知(同年12月2日発送)がなされ、平成21年5月21日付けで意見書が提出されるとともに、手続補正がなされ、平成22年3月31日付けで拒絶査定(同年4月2日発送)がなされ、同年7月29日付けで審判請求がなされるとともに、手続補正がなされたものである。なお、同年12月28日付けで審査官より同法第164条第3項で規定する報告(前置報告)がなされ、平成23年3月25日付けで当審より審尋(同年同月29日発送)がなされ、同年7月25日付けで回答書が提出されている。第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張 1.平成17年3月3日付け翻訳文における各請求項の記載平成17年3月3日付けで提出された、国際出願日における明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の翻訳文における(平成21年5月21日付け手続補正書による手続補正前の)特許請求の範囲の請求項1、7及び8は、次のとおりであった。「【請求項1】 1つ以上の機能ユニットと、1つ以上のレジスタファイルと、データメモリと、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファとを具備してなるデータプロセッサであって、前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段を備えることを特徴とするデータプロセッサ。」「【請求項7】前記データメモリファシリティがスタックとして動作される、請求項1に記載のデータプロセッサ。【請求項8】前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項7に記載のデータプロセッサ。」 2.平成20年11月27日付け拒絶理由通知平成20年11月27日付けで原審が通知した拒絶理由は次のとおりである。「1.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。 2.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。 …(中略)… 記 …(中略)… [理由1] [請求項]1-14 …(中略)… へ)請求項8に、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」との記載があるが、日本語として意味が不明である。 …(中略)… よって、本願の請求項1-14に係る発明は明確でない。 [理由2] [請求項]4、8、14 …(中略)… ヨ)請求項8に記載の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、明細書のいずれの記載に対応するのか不明である。 …(中略)… したがって、本願の請求項4、8、14に係る発明は、発明の詳細な説明に記載したものでない。 …(後略)…」 3.平成21年5月21日付け意見書平成21年5月21日付けで請求人(特許出願人)が提出した意見書は次のとおりである。「…(前略)… ヘ)請求項8(補正後の請求項6)の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について補正前の請求項8(補正後の請求項6)における「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、図2、図3に示されている。図2は、スタックに基づくスナップショットバッファの内部配列を示したものである。明細書の段落[0014]に記載されたように、このバッファは、複数のシャドウフリップフロップで構成されており、ワード52が並列に配置された並列ワード群50として示されている。各シャドウフリップフロップは、図3に示されたように、プロセッサリソース内に配置された対応する状態表示フリップフロップに接続されている。これらのワードは、インタラプト処理が実行されている間、ライン62を介して、ワード52へ1個ずつ格納される。ワード52の選択は、マルチプレクサ58を制御するためのスタックポインタ58によって制御される。スタックポインタ58は、ワード52内に各データを格納するように動作する。 …(中略)… ヨ)請求項8の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について上記(3-1)ヘ)において、「スタックポインタ」について述べた通りである。 …(中略)… (4-1) 請求項4、7、13を削除し、補正前の請求項1?3を新たな請求項1?3、補正前の請求項5?6を新たな請求項4?5、補正前の請求項8?12を新たな請求項6?10、補正前の請求項14を補正後の請求項11とする補正を行った。 …(中略)… (4-4) 補正前の請求項7の内容を補正前の請求項8、9に合体させて、補正後の請求項6、7とする補正を行った。 …(後略)…」 4.平成21年5月21日付け手続補正後の各請求項の記載平成21年5月21日付けで請求人(特許出願人)が提出した手続補正書による手続補正後の(平成22年7月29日付け手続補正書による手続補正前の)特許請求の範囲の請求項1及び6の記載は、次のとおりであった。「【請求項1】 1つ以上の機能ユニットと、1つ以上のレジスタファイル(22、24)と、データメモリ(40)と、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファ(20)とを具備してなるデータプロセッサであって、前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段(30)を備え、スタックに基づくレジスタファイルとして、スナップショットバッファが動作されるように配列されていることを特徴とするデータプロセッサ。」「【請求項6】前記データメモリファシリティがスタックとして動作され、前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項1に記載のデータプロセッサ。」 5.平成22年3月31日付け拒絶査定原審が平成22年3月31日付けで行った拒絶査定は、次のとおりである。「この出願については、平成20年11月27日付け拒絶理由通知書に記載した理由1、2、4によって、拒絶をすべきものです。なお、意見書並びに手続補正書の内容を検討しましたが、拒絶理由を覆すに足りる根拠が見いだせません。 [備考] (理由1及び2について) …(中略)… ヘ)、ヨ)請求項6の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」と、「多数のスタック位置を許容する」との関連・意味が依然として不明であり、明細書のいずれの記載に対応するのかも依然として不明である。 …(中略)… なお、上記[備考]で検討したほかに、補正書において補正された請求項には、以下の拒絶理由がある。 …(中略)… 2.補正書において補正された請求項について、下記の点は、特許法第36条第6項第1号に規定する要件を満たしていない。 D)請求項6に記載の事項が、具体的な実施の形態として、発明の詳細な説明のいずれの記載に対応するのか不明である。 …(中略)… よって、本願の請求項6、7、9に係る発明は、発明の詳細な説明に記載したものでない。」 6.平成22年7月29日付け審判請求書平成22年7月29日付けで請求人が提出した審判請求書は、次のとおりである。「…(前略)… (b)記載不備並びに補正の根拠について …(中略)… ヘ)、ヨ)、D)請求項6の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について「前記データメモリファシリティがスタックとして動作され」という記載を、「前記スナップショットバッファがスタックとして動作され」とする補正を行った。この補正事項は、出願当初の明細書の段落[0014]における記載「図2は、スタックに基づくスナップショットバッファの内部構成のブロック図を示している。バッファは、別個に図示されていない複数のシャドウフリップフロップから構成されており、これらはワード52のみが示されている並列ワード群50において組織化されている。ワード長さの決定は、ニーズと、データ経路幅などの利用可能なプロセッサファシリティとに応じて行われる。各シャドウフリップフロップは、プロセッサリソース内に位置する対応する状態指示フリップフロップに接続されている。インタラプトの処理中、この状態を保存しなければならないが、以後は図3を参照すること。スナップショットバッファにおいて、様々なシャドウワードに対する入力はデマルチプレクサ54に接続されており、正確な1ワードをいつでも書き込みすることができる。同様に、スナップショットバッファにおいて、様々なシャドウワードからの出力はマルチプレクサ56に送られ、正確な1ワードの読み出しを行うことがいつでも可能である。」、並びに段落[0016]における記載「本実施例において、スナップショットバッファはそれ自身の内部スタックポインタを維持するので、標準ランダムアクセスレジスタファイルで必要であったような、上記読み出し/書き込みコマンドの何れもレジスタアドレスを必要としない。従って、スナップショットバッファにおけるレジスタのアドレッシングを行うために、命令ビットが別途必要となることはない。ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがDM40にコピーされて、新しいデータのための場所が確保される。」に基づくものである。この補正は、明瞭でない記載の釈明を目的とし、拒絶理由通知に係わる拒絶の理由に示す事項についてするものである。後述する参考図4aから参考図4nに示されたように、スナップショットによりプロセッサ状態が並列ワード群内にコピーされる。この並列ワード群は、スタックとして動作する。明細書の段落[0016]に記載されたように、スタックポインタレジスタ58内に保存されたスタックポインタはインタラプトのレベルに関連せず、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連する。 …(中略)… 尚、請求項2、11を削除したことに伴い、補正前の請求項1、3?10は、補正後に新たな請求項1、2?9となった。 …(中略)… (c)本願発明と引用文献1?2との対比 1)本願発明はデータプロセッサに係わり、プロセッサにより通常のメインスレッドが処理されている最中に、I/O等に関するインタラプトが発生することがある。インタラプトされる前の処理を保存するために、プロセッサはシャドウバッファを備えている。各々のプロセッサ状態要素は、シャドウバッファ内に対応するスナップショットバッファ要素を有しており、これにより、インタラプト処理の状態情報を迅速に保存することができ、またプロセッサはインタラプト処理を開始することができる。インタラプトの処理中に、他のより高い優先度を有するインタラプトが発生することがある。このような場合、シャドウバッファが1番目のインタラプト処理の状態情報を格納する前に、シャドウバッファ内のデータを他の保存場所に格納しておく必要がある。状態情報のデータ量は、データパス幅を超える複数ビットから成るデータ量を有する。従って、インタラプトにより状態情報をメモリに保存する場合、異なるレジスタをアドレスする必要がある。本願発明によれば、本願の図2に示されたように、スナップショットバッファがスタックベースレジスタファイルとして動作する。これにより、スナップショットバッファ内のレジスタをアドレスする必要がなくなる。添付された参考図面を用いて、本願発明の動作を説明する。参考図1は、プロセッサのスナップショットバッファ20とリソースフリップフロップ70との関係を示す。スナップショットバッファ20は、シャドウフリップフロップ72を備え、シャドウフリップフロップ72は並列ワード52の群50内に構成されている。本願明細書の段落[0014]において、図2を参照してスナップショットバッファについて記載されている。シャドウフリップフロップ72は、図3に示されたように、リソースフリップフロップ70に接続されている。参考図1に示されたメインスレッドを処理している最中に、参考図2に示されたようにインタラプトINT1が発生したとする。メインスレッドの状態情報がスナップショットバッファ20内に保存される。参考図3に示されたように、プロセッサはインタラプトINT1の処理を実行することが可能となる。インタラプトINT1の処理を実行している最中に、引き続いてインタラプトINT2が発生した場合には、スナップショットバッファ20の内容が、参考図4a、…、参考図4nに示されたようにメモリに保存される。スナップショットバッファ20は、スタックに基づくレジスタとして動作する。参考図4aから参考図4nに示されたように、メモリ内に格納されるべきスタックポインタレジスタ58内のスタックポインタによって、スナップショットバッファ50のパラレルワード52が一つずつ選択される。このことと関連し、明細書の段落[0016]において「スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」と記載されている。参考図5に示されたように、1番目のインタラプトの処理の状態情報のスナップショットが撮られた後、参考図6に示されたように2番目のインタラプトの処理が実行される。参考図7に示されたように、2番目のインタラプトINT2の処理が完了すると、プロセッサは、スナップショットバッファ20内に保存された状態情報を用いて、未だ完了していない1番目のインタラプトINT1の処理を続けることができる。参考図8aから参考図8nに示されたように、保存されているメインスレッドの状態情報がメモリから取り出されてスナップショットバッファ20内に1ワード毎に格納される。最終的に、1番目のインタラプトINT1の処理が完了すると、スナップショットバッファ20内の情報を本来のリソースフリップフロップ70内にコピーした後、プロセッサが1番目のインタラプトが発生する前に処理していたメインスレッドに戻る。 …(中略)… 本願発明におけるスタックに基づくレジスタとして動作するスナップショットバッファは、参考図4aから参考図4nを用いて上述したように、スナップショットバッファ20内の情報が、本願の図2に示されたスタックポインタレジスタ58内のスタックポインタの制御に基づいて、1ワード毎に保存される。同様に、参考図8aから参考図8nを用いて上述したように、スナップショットバッファ20内の情報は、スタックポインタの制御に基づいて1ワード毎に再度書き込まれる。このような本願発明におけるスナップショットバッファ自体がスタックに基づくレジスタとして動作する構成を備えたことにより、アドレスする際にレジスタインデックスが要求されず、アドレスビットの格納の際におけるアドレスの書き込みを必要最小限とし、消費電力の増加を防止することができる。 …(後略)…」 7.平成22年7月29日付け手続補正後の各請求項の記載平成22年7月29日付けで請求人が提出した手続補正書による手続補正後の請求項1及び5の記載は、次のとおりである。「【請求項1】 1つ以上の機能ユニットと、1つ以上のレジスタファイル(22、24)と、データメモリ(40)と、インタラプト状態の処理中に様々なプロセッサ状態要素の状態情報を各スナップショットバッファ要素に保存するように適応しているスナップショットバッファ(20)とを具備してなるデータプロセッサであって、前記データプロセッサが、実際のインタラプト状態の処理中に生じる次のインタラプト状態のときに、前記スナップショットバッファ要素の内容をマルチビットアクセスポートファシリティを有するデータメモリファシリティに保存するように配列されているコントローラ手段(30)を備え、スタックに基づくレジスタファイルとして、スナップショットバッファが動作されるように配列されていることを特徴とするデータプロセッサ。」「【請求項5】前記スナップショットバッファがスタックとして動作され、前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する、請求項1に記載のデータプロセッサ。」 8.平成22年12月28日付け前置報告書平成22年12月28日付けで審査官が行った特許法第164条第3項で規定する報告(前置報告)は、次のとおりである。「請求時の補正は、不明りょうな記載の釈明を目的としたものと認める。しかしながら、本願は、以下の理由により特許を受けることができない。 …(中略)… ・理由2 ・根拠条文: 特許法第36条第6項第2号・請求項: 1-9 ・特許査定できない理由 …(中略)… (3)請求項5の、「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」とは、スナップショットバッファの何に対応するのか不明であり、「各スナップショットごと」と「多数のスタック位置を許容する」との関連・意味が依然として不明である。 …(中略)… よって、本願の請求項1-9に係る発明は明確でないから、特許法第36条第6項第2号に規定する要件を満たしておらず、特許を受けることができない。」 9.平成23年7月25日付け回答書平成23年7月25日付けで請求人が提出した回答書は、次のとおりである。「…(前略)… 3)請求項5の「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」について明細書の段落[0003]において、「上記のスケジューリングアプローチは、NUAL-EQ意味論(Nｏn Uniｔ Aｓｓｕmed Laｔencｙｗiｔh Eｑｕal)と呼ばれている。NUAL-EQに基づいてコンパイル時間スケジューリングをサポートする常に割込可能なプログラム可能プロセッサは、インタラプト処理方式の一部として復元されるべき内部プロセッサパイプラインから正確なスナップショットを撮ることが必要である。」と記載されているように、スナップショットは、インタラプト処理方式の一部として復元されるべき、内部プロセッサパイプラインを表わします。請求項5において記載されているように、多数のスタック位置が、スナップショットを格納するために用いられます。このことは、スナップショットは、多数のスタック位置に格納されることを意味し、図2に示されたようです。スナップショット情報を格納するシャドウフリップフロップが、複数のワード線52において組織化されています。複数のワード線52のそれぞれがスタック位置に対応し、スタックポインタレジスタ58内に格納されたスタックポインタによりその選択が可能です。 …(中略)… (4) 本願発明と引用文献との相違について …(中略)… しかし本願発明では、スナップショットバッファがスタックに基づいて構成されています。平成22年7月29日付けの審判請求書に添付された参考図4a?4nに示された状態において、スナップショットバッファの内容がワード毎に、図2に示されたスタックポインタレジスタ58の制御により格納されます。同審判請求書に添付された参考図8a?8nに示された状態において、スナップショットバッファの内容がワード毎に、図2に示されたスタックポインタレジスタ58の制御により再度書き込まれます。即ち、スナップショットバッファがスタックに基づくレジスタファイルとして構成されたことにより、スナップショットバッファ20の内容を格納するとき、アドレスされる必要性を回避することができます。 …(中略)… 4)本願発明は、以前のインタラプトを処理している間に発生した後続のインタラプトにおいて、メモリへスナップショットバッファのデータを格納することが可能であり、スナップショットバッファ内のプロセッサデータの迅速な格納、インタラプトに対する迅速な応答が実現されます。引用文献3のマイクロコンピュータ装置と異なり、本願発明は、スナップショットが複数のスタック位置に格納される、スタックに基づくスナップショットバッファを備えています。これにより、通常のデータパスを使ってスナップショットバッファとメモリとの間でデータを交換することが可能となります。複数のレジスタをスナップショットバッファとして用いることができるため、スナップショットバッファ内に格納可能なデータ量の増加が可能となります。 …(後略)… 」第3.当審の判断 1.はじめに上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」から明らかなように、本願の請求項5における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は、平成17年3月3日付けで提出された、国際出願日における明細書、請求の範囲、図面(図面の中の説明に限る。)及び要約の翻訳文における特許請求の範囲の請求項8にもあった記載であり、平成21年5月21日付け手続補正書による手続補正後の特許請求の範囲の請求項6にもあった記載である。また、上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」から明らかなように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審は平成20年11月27日付け拒絶理由通知にて「日本語として意味が不明である。」と指摘して特許法第36条第6項第2号の規定を満たしていないとし、同拒絶理由通知にて「明細書のいずれの記載に対応するのか不明である。」と指摘して同法同条同項第1号の規定を満たしていないとしている。続いて、原審は平成22年3月31日付け拒絶査定にて「「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、「各スナップショットごと」と、「多数のスタック位置を許容する」との関連・意味が依然として不明」であると指摘して特許法第36条第6項第2号の規定を満たしていないという拒絶理由が解消していないとし、「「各スナップショットごとに多数のスタック位置を許容するスタックポインタ」は、…(中略)…明細書のいずれの記載に対応するのかも依然として不明である。」と指摘して同法同条同項第1号の規定を満たしていないという拒絶理由が解消していないとしている。そこで、本願の請求項5における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願が特許法第36条第6項第2号の規定及び同法同条同項第1号の規定を満たしているものであるか否かを検討する。 2.特許法第36条第6項第2号の規定に関する検討請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審が平成20年11月27日付け拒絶理由通知にて「日本語として意味が不明である。」と指摘しているので、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が日本語として意味が不明であるか否かを検討する。請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を当業者が解釈しようとすると、1つの「スタック」に同時に含まれる「スナップショット」の数が単数と複数のいずれであるか、及び、1つの「スナップショット」に対応する「スタック位置」の数が単数と複数のいずれであるかによって、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す、「スタック」に「スナップショット」が格納される態様が異なるものとなり、「スタックポインタ」の挙動も異なるものとなる。しかしながら、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を解釈するに際しては、1つの「スタック」に同時に含まれる「スナップショット」の数が単数か複数かが不明である。また、同記載を解釈するに際しては、1つの「スナップショット」に対応する「スタック位置」の数が単数か複数かが不明である。さらに、同記載を解釈するに際しては、「各スナップショットごとに多数のスタック位置を許容する」ことと「スタックポインタ」の関係が明確でない。このように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が多義的であって当該記載の意味を特定できず、また、当該記載の意味するところが明確でない点もある。 (なお、後述の「3.特許法第36条第6項第1号の規定に関する検討」で示すように、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が多義的である点について、明細書等を参酌しても、いくつか想定される解釈のいずれかひとつであると特定することもできない。) 以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は日本語として意味が不明であり、本願は特許法第36条第6項第2号の規定を依然として満たしていない。また、一般に、情報処理の技術分野において、スタックという用語は、互いに時間的な前後関係があるデータを複数個積み上げる態様で管理する記憶手段を意味する。そして、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載を解釈するに際し、1つの「スタック」に同時に含まれる「スナップショット」の数が1つであると解釈した場合には、1つのスタックのなかに同時には異なるスナップショットが存在しないのであるから、1つのスタックのなかに同時に存在するデータの間にはなんら時間的な前後関係がないことになる。そうすると、当該解釈のもとでは請求項での「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載における「スタック」は、もはや、情報処理の技術分野におけるスタックであるとはいえない。そのため、当該解釈のもとでは、請求項における「スタック」という語が情報処理の技術分野の通常の日本語における「スタック」を意味するとはいえず、請求項での「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載における「スタック」、「スタック位置」及び「スタックポインタ」が意味するところが明確であるとはいえない。以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は日本語として意味が不明であり、本願は依然として特許法第36条第6項第2号の規定を満たしていない。 3.特許法第36条第6項第1号の規定に関する検討請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、原審が平成20年11月27日付け拒絶理由通知にて「明細書のいずれの記載に対応するのか不明である。」と指摘しているので、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が明細書のいずれかに記載されたものといえるかを検討する。 3の1.想定される3つの解釈上記「2.特許法第36条第6項第2号の規定に関する検討」で示したように、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載においては、1つの「スタック」に同時に含まれる「スナップショット」の数が単数か複数かが不明であり、また、1つの「スナップショット」に対応する「スタック位置」の数が単数か複数かが不明である。その意味で多義的であることは既に示したところである。ここで、1つの「スタック」に同時に含まれる「スナップショット」の数と、1つの「スナップショット」に対応する「スタック位置」の数のそれぞれについて、単数の場合と複数の場合の組み合わせを考慮すると(ただし、請求項における「前記スタックが、…(中略)…多数のスタック位置を許容する」の記載に基づいて、上記した2つの数がいずれも単数の場合については除外する。)、「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載の解釈としては、強いて想定すれば、一応以下の3つが考えられる。解釈1)1つのスタックには同時には1つのスナップショットが存在し得て、1つのスナップショットが複数のスタック位置にわたって格納される。スタックポインタは、1つのスナップショットが格納される複数のスタック位置のうちの1つのスタック位置を指し示すものである。解釈2)1つのスタックには同時には複数のスナップショットが存在し得て、1つのスナップショットが複数のスタック位置にわたって格納される。スタックポインタは、複数のスナップショットの内の1つのスナップショットについて、当該1つのスナップショットが格納される複数のスタック位置のうちの1つのスタック位置を指し示すものである。解釈3)1つのスタックには同時には複数のスナップショットが存在し得て、1つのスナップショットは1つのスタック位置に格納される。スタックポインタは、複数のスナップショットのうちの1つのスナップショットが格納される1つのスタック位置を指し示すものである。そこで、明細書等の記載を参酌して、上記した3つの解釈のいずれのひとつであるかを特定して、その特定した解釈に基づく発明が明細書の発明の詳細な説明に記載したものであるとすることができるか、つまりは、上記した3つの解釈のいずれのひとつが、明細書の発明の詳細な説明に記載され、かつ、矛盾無く記載された技術的事項に対応しているといえるかを検討する。 3の2.解釈1の検討明細書の【0008】には次のように記載されている。「…(前略)…スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。…(後略)…」また、明細書の【0018】には次のように記載されている。「各インタラプト処理の開始時に、各通常フリップフロップの数値をその対応するシャドウフリップフロップに即座にコピーすることにより、単一のクロック周期内で関連するプロセッサ状態から完全スナップショットを取る。同様に、各インタラプト処理の終了時に、各シャドウフリップフロップをその対応する通常フリップフロップに即座にコピーすることにより、完全スナップショットをスナップショットバッファからプロセッサに適切に復元される。」仮に上記解釈1を採用すると、1つのスタックに同時に存在するただ1つのスナップショットが格納される複数のスタック位置は、互いに同じスナップショットを構成する各スナップショット要素を格納しているのであって、各スタック位置に格納されるスナップショット要素間には時間的な前後関係はないことになる。上記【0018】の記載も考慮すれば、1つのスタックに同時に存在するただ1つのスナップショットが格納される複数のスタック位置について、スタック位置相互間では通常フリップフロップからスナップショットを取るタイミングに何ら前後関係がないので、なおさらのこと、上記解釈1を採用すると、1つのスタックに含まれる各スタック位置に格納されるスナップショット要素間には時間的な前後関係はないことになる。しかしながら、上記【0008】には「スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。」と記載されている。つまり、上記【0008】によれば、1つのスタックの1つのスタック位置から読み出して、スタックポインタの数値が減少したときに、スタックポインタに新たに指し示されるスタック位置は「前回のスタック最上部」であり、1つのスタックの1つのスタック位置に書き込んで、スタックポインタの数値が増加したときに、スタックポインタに新たに指し示されるスタック位置は「次のスタック最上部」である。結局のところ上記【0008】によれば、1つのスタックに含まれる各スタック位置に格納されるスナップショット要素間に時間的な前後関係があることになる。以上のとおり、明細書等には上記解釈1とは矛盾する記載があるので、上記解釈1を採用した場合における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明に記載したものであるとはいえない。 3の3.解釈2の検討 3の3の1.スタック位置間の時間的前後関係について仮に上記解釈2を採用すると、1つのスナップショットが複数のスタック位置にわたって格納されることになるので、同じスナップショットを構成するスタック位置の間では時間的な前後関係がないことになる。これに対し、上記「3の2.解釈1の検討」で既に示したように、上記【0008】には「スナップショットをバックグラウンドメモリに保存するために、スナップショットバッファから読み出しを行うと、スタック最上部が飛び出し、スタックポインタ数値が減少するので、前回のスタック最上部が指示される。バックグラウンドメモリからスナップショットを再ロードするためにスナップショットバッファに書込を行うと、新しいデータがスタックに押され、スタックポインタの数値が増加するので、次のスタック最上部が指示される。」と記載されている。つまり、上記【0008】によれば、1つのスタックの1つのスタック位置から読み出して、スタックポインタの数値が減少したときに、スタックポインタに新たに指し示されるスタック位置は「前回のスタック最上部」であり、1つのスタックの1つのスタック位置に書き込んで、スタックポインタの数値が増加したときに、スタックポインタに新たに指し示されるスタック位置は「次のスタック最上部」である。結局のところ上記【0008】によれば、1つのスタックに含まれる各スタック位置に格納されるスナップショット要素間に時間的な前後関係があることになる。以上のとおり、明細書等には上記解釈2とは矛盾する記載があるので、上記解釈2を採用した場合における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明に記載したものであるとはいえない。 3の3の2.スタックポインタの数について上記解釈2を採用すると、1つのスタックに同時に複数のスナップショットが存在し得ることになるが、その一方で明細書の【0015】には次のとおり記載されている。「デマルチプレクサ54およびマルチプレクサ56の両者は、同様にスナップショットバッファに位置するスタックポインタレジスタ58からのスタックポインタによって制御される。実際、ライン62上のスナップショットバッファからの読み出しはネスト化されたインタラプトの開始時に必要となるだけであり、またライン60上のスナップショットバッファへの書込はネスト化されたインタラプトの終了時に必要となるだけである。従って、これらの2つの動作は同時に生じることはなく、スタックバッファにおける異なるワードのインターリーブアドレッシングを制御するのに単一のポインタレジスタ58で十分である。ポインタ数値は、その後ポインタレジスタ58の再ロードを行うために、ライン62(当審注:図面第2図を参酌すればこの「ライン62」は誤記であり、正しくは「ライン64」である。)上でポインタアップデート制御部66に逆結合されている。図に示すように、3動作制御ライン68により、ポインタ数値に対して読み出しモード、書き込みモード、無動作モードが可能となる。効果的な動作は、(直線逆結合を介して)減少要素(-1)、増加要素(+1)、無動作要素において実行される。」そして、この【0015】の記載に対応して、図面第2図にはスナップショットバッファであるスタックのためにスタックポインタがただ1つ設けられていることが示されている。しかしながら、上記解釈2を採用し、1つのスタックであるスナップショットバッファに同時に複数のスナップショットが存在し得ることになると、(A)状態指示フリップフロップ(通常フリップフロップ、状態レジスタ)からスナップショットを取ってスナップショットバッファに格納する際のスナップショットと、(B)スナップショットバッファからバックグラウンドデータメモリにスナップショットを退避させる際のスナップショットとが、1つのスタックであるスナップショットバッファ上で異なるスタック位置(またはスタック位置群)となりうることは自明であり、上記(A)のスナップショットのためのスタック位置(またはスタック位置群)を指し示すポインタと、上記(B)のスナップショットのためのスタック位置(またはスタック位置群)を指し示すポインタを別々に設けざるを得ないことは当業者にとって技術常識である。つまり、当業者の技術常識からは、状態指示フリップフロップ(通常フリップフロップ、状態レジスタ)からスナップショットを取ってスナップショットバッファに格納し、スナップショットバッファからバックグラウンドデータメモリにスナップショットを退避させるという本願で構築しようとするシステムでは、スナップショットバッファであるスタックにおいて、状態指示フリップフロップ(通常フリップフロップ、状態レジスタ)からスナップショットを取ってスナップショットバッファに格納する(一般的にはこの格納のことをプッシュという。)際に格納先となるスタック位置(またはスタック位置群)を指し示すポインタと、スナップショットバッファからバックグラウンドメモリにスナップショットを退避させる際に読み出し元となるスタック位置(またはスタック位置群)を指し示すポインタの2つのポインタを要するといわざるを得ない。これに対し、上記【0015】及び図面第2図には、スナップショットバッファであるスタックのためのポインタがただ1つである旨が示されている。そして、このただ1つのポインタにより、状態指示フリップフロップ(通常フリップフロップ、状態レジスタ)からスナップショットを取ってスナップショットバッファに格納する(一般的にはこの格納のことをプッシュという。)際に格納先となるスタック位置(またはスタック位置群)を指し示すことと、スナップショットバッファからバックグラウンドメモリにスナップショットを退避させる際に読み出し元となるスタック位置(またはスタック位置群)を指し示すことの両方をいかにして行うのかが、明細書の発明の詳細な説明には記載されていない。結局のところ、上記解釈2を採用した場合の本願の請求項5に係る発明に対応する記載は明細書の発明の詳細な説明にはないということになる。以上のとおり、仮に上記解釈2を採用すると、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載と明細書等の記載は矛盾するので、上記解釈2に基づく本願の請求項5に係る発明、特に請求項5における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明が記載したものであるとはいえない。 3の4.解釈3の検討上記解釈3を採用すると、1つのスタックに同時に複数のスナップショットが存在し得ることになる。そうすると、上記「3の3.解釈2の検討」の「3の3の2.スタックポインタの数について」で既に示した理由と同様の理由で、仮に上記解釈3を採用すると、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載と明細書等の記載は矛盾するので、上記解釈3に基づく本願の請求項5に係る発明、特に請求項5における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載が示す発明特定事項は、明細書の発明の詳細な説明が記載したものであるとはいえない。 3の5.特許法第36条第6項第1号の規定の検討に関する小括上記3の2.乃至3の4.で示したように、上記3の1.で仮に想定した3つの解釈のいずれも、明細書の発明の詳細な説明に記載され、かつ、矛盾無く記載された技術的事項に対応しているとはいえない。つまり、明細書等の記載を参酌しても、上記した3つの解釈のいずれのひとつであるかを特定したとしても、特定された解釈に基づく発明が明細書の発明の詳細な説明に記載されているとすることはできない。以上より、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載は明細書のいずれかに記載されたものとはいえず、本願は特許法第36条第6項第1号の規定を依然として満たしていない。 4.小括上記2.で示したように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願は特許法第36条第6項第2号の規定を満たしていない。また、上記3.で示したように、請求項における「前記スタックが、各スナップショットごとに多数のスタック位置を許容するスタックポインタを有する」という記載に関して、本願は特許法第36条第6項第1号の規定を満たしていない。 5.請求人の主張について 5の1.平成22年7月29日付け審判請求書について上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「6.平成22年7月29日付け審判請求書」に示したように、請求人は「後述する参考図4aから参考図4nに示されたように、スナップショットによりプロセッサ状態が並列ワード群内にコピーされる。この並列ワード群は、スタックとして動作する。」、「状態情報のデータ量は、データパス幅を超える複数ビットから成るデータ量を有する。従って、インタラプトにより状態情報をメモリに保存する場合、異なるレジスタをアドレスする必要がある。」、「参考図1に示されたメインスレッドを処理している最中に、参考図2に示されたようにインタラプトINT1が発生したとする。メインスレッドの状態情報がスナップショットバッファ20内に保存される。」、「インタラプトINT1の処理を実行している最中に、引き続いてインタラプトINT2が発生した場合には、スナップショットバッファ20の内容が、参考図4a、…、参考図4nに示されたようにメモリに保存される。」、「スナップショットバッファ20は、スタックに基づくレジスタとして動作する。参考図4aから参考図4nに示されたように、メモリ内に格納されるべきスタックポインタレジスタ58内のスタックポインタによって、スナップショットバッファ50のパラレルワード52が一つずつ選択される。」、「参考図5に示されたように、1番目のインタラプトの処理の状態情報のスナップショットが撮られた後、参考図6に示されたように2番目のインタラプトの処理が実行される。」、「参考図7に示されたように、2番目のインタラプトINT2の処理が完了すると、プロセッサは、スナップショットバッファ20内に保存された状態情報を用いて、未だ完了していない1番目のインタラプトINT1の処理を続けることができる。」、「参考図8aから参考図8nに示されたように、保存されているメインスレッドの状態情報がメモリから取り出されてスナップショットバッファ20内に1ワード毎に格納される。」、「本願発明におけるスタックに基づくレジスタとして動作するスナップショットバッファは、参考図4aから参考図4nを用いて上述したように、スナップショットバッファ20内の情報が、本願の図2に示されたスタックポインタレジスタ58内のスタックポインタの制御に基づいて、1ワード毎に保存される。」、「同様に、参考図8aから参考図8nを用いて上述したように、スナップショットバッファ20内の情報は、スタックポインタの制御に基づいて1ワード毎に再度書き込まれる。」と主張している。当該主張は、上記3の1.で示した解釈1に基づくものであると解される。しかしながら、既に上記3の2.で示したように、明細書等は上記解釈1を採用できる程度に矛盾無く記載されているとはいえない。つまり、上記解釈1は明細書等の記載から自明に導き出せるものではない。よって、審判請求書における上記された主張は明細書等の記載に適切な根拠がなく、審判請求書における上記された主張を採用することはできない。また、上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「6.平成22年7月29日付け審判請求書」に示したように、請求人は「明細書の段落[0016]に記載されたように、スタックポインタレジスタ58内に保存されたスタックポインタはインタラプトのレベルに関連せず、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連する。」、「このことと関連し、明細書の段落[0016]において「スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」と記載されている。」と主張している。そこで、請求人が主張の根拠としている明細書の【0016】について検討する。当該主張に係る明細書の【0016】は次のとおりである。「…(前略)…ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがDM40にコピーされて、新しいデータのための場所が確保される。」上記【0016】のうち「インタラプトのレベル」という語については、明細書等における他の箇所を参照しても、これに関する説明が一切無く、その技術的な意味内容が不明である。また「インタラプトのレベル」という語自体が明確にひとつの意味を指し示すともいえない。さらに、これに関連して、「スタックポインタの実際の数値はインタラプトのレベルに関連していない」という文の意味するところも不明である。また、上記【0016】のうち「状態レジスタ」という語についてもどのような動作をするものか理解できず、さらに、明細書等における他の箇所を参照しても「状態レジスタ」に関する説明がなされておらず、如何なる技術的意味を有するものであるのか不明である。仮に「状態レジスタ」が【0014】の「状態指示フリップフロップ」や【0007】の「通常のフリップフロップ」や【0017】の「通常のリソースフリップフロップ」や【0018】の「通常フリップフロップ」に相当するものであると解釈したとしても、上記【0016】の「特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンス」という句は、特定のインタラプトに対して、状態情報を保持する通常のレジスタ(フリップフロップ)に、状態情報等のデータが書き込まれる際におけるシーケンス、といった意味になる。一方で、明細書等の記載(特に、明細書の【0018】の「各インタラプト処理の開始時に、各通常フリップフロップの数値をその対応するシャドウフリップフロップに即座にコピーすることにより、単一のクロック周期内で関連するプロセッサ状態から完全スナップショットを取る。同様に、各インタラプト処理の終了時に、各シャドウフリップフロップをその対応する通常フリップフロップに即座にコピーすることにより、完全スナップショットをスナップショットバッファからプロセッサに適切に復元される。」という記載)を参酌すれば、本願におけるただ一つのスタックポインタは、状態情報を保持する通常のレジスタ(フリップフロップ)への読み書きを直接制御するわけではない。結局のところ、「状態レジスタ」が【0014】の「状態指示フリップフロップ」や【0007】の「通常のフリップフロップ」や【0017】の「通常のリソースフリップフロップ」や【0018】の「通常フリップフロップ」に相当するものと解釈しても、上記【0016】の「スタックポインタの実際の数値は…(中略)…特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。」という文の文意を理解することができない。さらに、上記【0016】における「次のインタラプトが明白になる」という文と「次のインタラプトが到着する」の文のそれぞれの技術的意味及び両者間の技術的相違点が理解できない。加えて、上記【0016】における「スタック」が、スナップショットバッファを意味するのか、バックグラウンドデータメモリを意味するのか、または、それ以外の何かを意味するのかが明確でない。これらのことを併せて考慮すれば、上記【0016】の「次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがDM40にコピーされて、新しいデータのための場所が確保される。」の意味するところが不明である。このように、上記【0016】の「ちなみに、スタックポインタの実際の数値はインタラプトのレベルに関連していないが、特定のインタラプトに対してデータが状態レジスタに書き込まれるシーケンスに関連している。次のインタラプトが明白になると、シャドウレジスタ群の内容がスタックに書き込まれる。次のインタラプトが到着すると、シャドウレジスタがDM40にコピーされて、新しいデータのための場所が確保される。」の部分は、意味するところが不明であり、この箇所を根拠とする審判請求書における上記主張は採用することができない。 5の2.平成23年7月25日付け回答書について上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「9.平成23年7月25日付け回答書」に示される請求人の主張は、上記「第2.請求項の記載の変遷、原審が通知した拒絶理由等、及び、請求人の主張」の「6.平成22年7月29日付け審判請求書」に示される請求人の主張と同様のものであり、やはり採用することはできない。第4.むすびしたがって、本願は特許請求の範囲の記載が特許法第36条第6項第2号に規定する要件を満たしていない。また、本願は特許請求の範囲の記載が特許法第36条第6項第1号に規定する要件を満たしていない。よって、結論のとおり審決する。
審理終結日	2011-10-25
結審通知日	2011-10-28
審決日	2011-11-08
出願番号	特願2004-533771(P2004-533771)
審決分類	P 1 8・ 537- Z (G06F) P 1 8・ 536- Z (G06F)
最終処分	不成立
前審関与審査官	井上宏一
特許庁審判長	酒井伸芳
特許庁審判官	石井茂和清木泰
発明の名称	スタックタイプのスナップショットバッファがネスト化されたインタラプトを処理すること
代理人	川崎康
代理人	勝沼宏仁
代理人	吉元弘
代理人	関根毅
代理人	赤岡明
代理人	佐藤泰和

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