【事件の表示】
　平成　５年特許願第　５１７５３号「ワンチップマイクロコンピュータを有するシステム」において、平成１２年１０月１２日付けでした手続補正に対してされた補正の却下の決定に対する審判事件について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は平成５年３月１２日の出願であって、その後、平成１２年１０月１２日付けで明細書を補正する手続補正がなされたが、この補正は、平成１３年３月２１日付けで決定をもって却下されたものである。
２．原決定の理由
　原決定における却下の理由は次のとおりである。
『出願人は、平成１２年１０月１２日付け手続補正書による補正において、請求項１に対し「上記データ変更手段から送られてくるデータがデリバティブモードデータか否かを判断する判断手段」（以下「争点一」という。）および、「上記判断手段によりデリバティブモードデータと判断された場合は上記第１のエリアのデータ変更を禁止すると共に、上記第２のエリアのデータ変更を許可する制御手段」（以下「争点二」という。）の両手段を追加する補正をしようとしているが、
出願当初の明細書には、段落【００６９】に「デリバティブモードのクリア、或いは追加する場合にも、バグ修正用のエリアには、何ら手を加えることはない」と効果は記載されているもの、
「デリバティブモードデータか否かを判断する」ことおよびその手段については記載されておらず、
また、「デリバティブモードデータと判断された場合は上記第１のエリアのデータ変更を禁止すると共に、上記第２のエリアのデータ変更を許可する」ことおよびその手段についても記載されておらず、
また、両手段等が当初明細書から自明であるとも認められない。
　よって、上記補正は願書に最初に添付した明細書又は図面に記載した事項の範囲内における補正であるとは認められないので、特許法５３条第１項の規定により却下すべきものである。』
３．請求人の主張の要点
　請求人の主張の要点は次のとおりである。
『（争点一について）
　出願当初明細書の段落【００６１】には「図１８は、バグ修正とデリバティブ用のＲＯＭ修正データをマイコン内にセットするサブルーチンの例である。」と記載されているように、デリバティブデータを含むＲＯＭ修正データをマイコン内にセットすることが示されている。
　そして、段落【００６３】には「そして、ＫにＡR ＋Ｎ（５９H ＋２２H ＝７ＢH ）を代入する（ステップＣ３３）。ここで、ＫはＲＯＭ修正用データの最終アドレスを表す。この後、ＲＯＭ修正用データの有無を判定する（ステップＣ３４）。ＲＯＭ修正用データが無い場合はそのまま本ルーチンを抜け、上記ＲＯＭ修正用データが有る場合（Ｎ≠０）は、データをマイコン１１内のＲＯＭ修正メモリにセットする（ステップＣ３５）。」と記載されているように、ＲＯＭ修正データの有無を判定することが示されている。
　そして、段落【００６４】には「この場合、チェッカ通信で、このサブルーチンをコールする。ＥＥＰＲＯＭ１４のデリバティブ用バイト数（アドレス５８）を“０”にセットすれば（ステップＣ４１）、デリバティブ用データは無いものと判断される。」と記載されているように、デリバティブ用バイト数が“０”にセットされているか否かでデリバティブ用データが無いかどうかを判断することが記載され、若しくは記載内容から自明である。
（争点二について）
出願当初明細書の段落【００６６】には「すなわち、先ず、外部装置よりデリバティブデータの総バイト数（D）とD個のデリバティブ用データを受取る（ステップC51）。」と記載されている。つまり、デリバテイブデータの総バイト数（D）が”0”でなく所定のバイト数であればデリバティブデータであると判断することが記載され、若しくは記載内容から自明である。
　そして、同【００６６】「すでに書込まれているデリバティブデータの数にDを加算し、Kに代入する（ステップC52）。これにより、Kは新しいデリバティブデータ数になる。」と記載され、段落【００６７】には「次いで、Kにバグ修正バイト数を加えてNに代入する（ステップC53）。Nは、総ROM修正エリアのバイト数となる。そして、Nと所定値とを比較し（ステップC54）、Nが所定値以上の場合はEEPROM14の容量がオーバしてしまうので警告を出す（ステップC55）。」と記載され、段落【００６８】には「一方、上記ステップC54にて、容量がオーバしない場合は、新しいデリバティブ用バイト数をアドレス58にセットし（ステップC56）、新しいデリバティブデータをEEPROM14に追加する（ステップC57）。」と記載されている。
　つまり、デリバティブ用バイト数をアドレス58にセットし、それに対応したアドレスにデリバティブデータを書き込むことが示されている。
　従って、バグ修正エリアにはデータが書き込めない（第1のエリアデータ変更の禁止する）ようになっており、デリバティブエリアにはデリバティブデータを書き込む（第2のエリアのデータ変更を許可する）ことが記載され、若しくは記載内容から自明である。
　以上のことから「上記データ変更手段から送られてくるデータがデリバティブモードデータか否かを判断する判断手段」および、「上記判断手段によりデリバティブモードデータと判断された場合は上記第1のエリアのデータ変更を禁止すると共に、上記第2のエリアのデータ変更を許可する制御手段」の両手段を追加する補正は、当初明細書等に記載された事項の範囲内であるか、当初明細書等の記載からみて自明な事項である。
（６）むすび
　よって、本出願人は、本件出願の補正は明細書の要旨を変更するものではないと考え、補正の却下の決定に対する審判を請求する次第である。』
４．補正却下の当否に対する判断
　上記手続補正により補正された特許請求の範囲の請求項１に記載された発明は次のとおりである。
『【請求項１】　プログラムのバグを修正するためのバグ修正データを記憶する第１のエリアと、制御対象の動作仕様を変更するためのデリバティブモードデータを記憶する第２のエリアを有する、外部より電気的に書換可能な不揮発性メモリと、
　上記第１及び第２のエリアに記憶されたデータに従ってマスクＲＯＭに記憶されたプログラム内容を擬似的に変更し制御対象を制御するワンチップマイクロコンピュータと、
　外部から上記不揮発性メモリ内の第１のエリアと第２のエリアのデータを消去及び変更可能なデータ変更手段と、
　上記データ変更手段から送られてくるデータがデリバティブモードデータか否かを判断する判断手段と、
　上記判断手段によりデリバティブモードデータと判断された場合は上記第１のエリアのデータ変更を禁止すると共に、上記第２のエリアのデータ変更を許可する制御手段と、
　を具備することを特徴とするワンチップマイクロコンピュータを有するシステム。』
　この出願の願書に最初に添付された明細書には以下の事項が記載されている。
『【００６１】
・・・図１８は、バグ修正とデリバティブ用のＲＯＭ修正データをマイコン内にセットするサブルーチンの例である。
【００６２】
　先ず、ＡR にＥＥＰＲＯＭ１４のＲＯＭ修正エリアの先頭番地（５７H ）を代入する（ステップＣ３１）。次に、Ｎにバグ修正バイト数とデリバティブ用バイト数を加えたものを代入する（ステップＣ３２）。図１７（ａ）の場合では、１０H ＋１２H ＝２２H をＮに代入する。
【００６３】
　そして、ＫにＡR ＋Ｎ（５９H ＋２２H ＝７ＢH ）を代入する（ステップＣ３３）。ここで、ＫはＲＯＭ修正用データの最終アドレスを表す。この後、ＲＯＭ修正用データの有無を判定する（ステップＣ３４）。ＲＯＭ修正用データが無い場合はそのまま本ルーチンを抜け、上記ＲＯＭ修正用データが有る場合（Ｎ≠０）は、データをマイコン１１内のＲＯＭ修正メモリにセットする（ステップＣ３５）。
【００６４】
　この場合、チェッカ通信で、このサブルーチンをコールする。ＥＥＰＲＯＭ１４のデリバティブ用バイト数（アドレス５８）を“０”にセットすれば（ステップＣ４１）、デリバティブ用データは無いものと判断される。図２１（ａ）は、デリバティブモードがクリアされた状態のメモリマップを示している。
【００６５】
　図２０は、リペア店等に於いて、デリバティブモードのデータを追加するときのサブルーチンである。ここでも、図１９と同様に、チェッカ通信を利用してＥＥＰＲＯＭ１４にデータを書込む。
【００６６】
　すなわち、先ず、外部装置よりデリバティブデータの総バイト数（Ｄ）とＤ個のデリバティブ用データを受取る（ステップＣ５１）。次に、すでに書込まれているデリバティブデータの数にＤを加算し、Ｋに代入する（ステップＣ５２）。これにより、Ｋは新しいデリバティブデータ数になる。
【００６７】
　次いで、Ｋにバグ修正バイト数を加えてＮに代入する（ステップＣ５３）。Ｎは、総ＲＯＭ修正エリアのバイト数となる。そして、Ｎと所定値とを比較し（ステップＣ５４）、Ｎが所定値以上の場合はＥＥＰＲＯＭ１４の容量がオーバしてしまうので警告を出す（ステップＣ５５）。
【００６８】
　一方、上記ステップＣ５４にて、容量がオーバしない場合は、新しいデリバティブ用バイト数をアドレス５８にセットし（ステップＣ５６）、新しいデリバティブデータをＥＥＰＲＯＭ１４に追加する（ステップＣ５７）。図２１（ｂ）は、追加された状態のメモリマップを示している。
【００６９】
　これらからもわかるように、デリバティブモードのクリア、或いは追加する場合にも、バグ修正用のエリアには、何ら手を加えることはないので、誤ってバグ修正用データが変更されて装置として誤動作をすることがない。』
　次に、上記争点について検討する。
（争点一について）
　段落【００６１】ないし【００６３】には、デリバティブ用データをＲＯＭ修正用エリアのデリバティブエリアにセットする（書き込む）ことが記載され、段落【００６４】には、デリバティブ用データをクリアすることが記載され、段落【００６６】ないし【００６８】には、デリバティブデータを追加することが記載されている。その際、段落【００６３】【００６４】【００６８】に記載されるように、デリバティブ用バイト数の値に応じてデリバティブモードデータの量が判断され、デリバティブ用バイト数が“０”の場合、デリバティブモードデータは無いものと判断されるものである。したがって、デリバティブ用バイト数の値によって、デリバティブモードデータか否かが判断されるものである。
　以上のとおりであるから、請求項１の「上記データ変更手段から送られてくるデータがデリバティブモードデータか否かを判断する判断手段」はこの出願の願書に最初に添付された明細書又は図面に記載された事項である。
（争点二について）
　争点一で検討したように、デリバティブ用データをデリバティブエリアに書き込むこと、クリアすること、追加すること（請求項１のデータ変更に相当する。）は行われているが、これは、デリバティブ用データの受け取りによって行われるものである。しかしながら、請求項１の「第２のエリア（デリバティブエリアに相当する。）のデータ変更を許可する」ということは、デリバティブ用データの受け取りの外にデータの書き込みを許可することが必要であって、その許可をすることについてはこの出願の願書に最初に添付された明細書又は図面には記載も示唆もなく、また自明な事項でもない。
　争点一で検討したように、デリバティブ用データをデリバティブエリアに書き込むこと、クリアすること、追加すること（請求項１のデータ変更に相当する。）は行われているが、その際、請求項１の「第１のエリア（バグ修正エリアに相当する。）のデータ変更を禁止する」ことは行われていない。なお、段落【００６９】には、「これらからもわかるように、デリバティブモードのクリア、或いは追加する場合にも、バグ修正用のエリアには、何ら手を加えることはないので、誤ってバグ修正用データが変更されて装置として誤動作をすることがない。」と記載されているが、データ変更を禁止する手段を備えていることではない。すなわち、データ変更を禁止するということは、データ変更をさせないようにガードしておくことが必要であるがそのようなことはこの出願の願書に最初に添付された明細書又は図面には記載も示唆もなく、また自明な事項でもない。
　以上のとおり、請求項１の「上記判断手段によりデリバティブモードデータと判断された場合は上記第１のエリアのデータ変更を禁止すると共に、上記第２のエリアのデータ変更を許可する制御手段」は、この出願の願書に最初に添付された明細書又は図面には記載も示唆もなく、また自明な事項でもない。
５．むすび
　したがって、本件補正について、特許法第５３条第１項の規定により却下をすべきものとした原審の決定は妥当である。
　よって、結論のとおり審決する。