【事件の表示】
　平成　５年特許願第２４３５２２号「プロセッサ制御プログラムの新規ロードないし再ロード方法および装置」拒絶査定に対する審判事件［平成　６年１０月２８日出願公開、特開平　６−３０１５４７］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明の要旨
　本願は、平成５年９月６日（パリ優先権主張１９９３年３月３１日）の出願であって、その請求項１に係る発明（以下、「本願発明」という。）は、平成１３年６月２６日付け及び平成１３年１２月１２日付け手続補正書によって補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載されたとおりの、
　「【請求項１】　交通案内−情報システムのプロセッサ制御される機器（ＰＧ）におけるプロセッサ制御プログラムの新規ロードないし再ロード方法において、
　プロセッサ制御される機器（ＰＧ）は、車両（ＦＺ）内に配置された移動通信機器であり、
　前記プロセッサ制御プログラムは消去防止された固定データメモリ（プログラムメモリ素子ＰＳＢ）にロードされており、
　プロセッサ制御される機器（ＰＧ）の無線データ伝送インタフェース（ＤＵＳＦ）と、ロードのために設けられやはり無線のデータ伝送インタフェース（ＤＵＳＮ）を備えた再ロードステーション（ＮＬＳ）とを介してロードが行われ、
　プロセッサ制御される機器（ＰＧ）に、該機器のために設けられたロードプログラムがインストールされており、該ロードプログラムは前記データ伝送インタフェース（ＤＵＳＦ）ならびに前記固定データメモリ（ＰＳＢ）の消去と新規プログラミングを制御し、
　再ロード制御プログラムの存在は、前記システムの送信ビーコンを介して車両（ＦＺ）へ通報され、
　再ロードすべきプロセッサ制御プログラムないしプログラム部分は、プロセッサ制御される機器（ＰＧ）により再ロードステーション（ＮＬＳ）に対しブロックごとに要求されて記憶され、
　個々のプログラムブロックはブロックごとの伝送にあたりチェックサムにより誤り保護され、
　プログラム入力終了後、再ロードされたプロセッサ制御プログラムは、長さならびにチェックサムの比較によりデータ伝送エラーの有無についてチェックされることを特徴とする、
　プロセッサ制御プログラムの新規ロードないし再ロード方法。」
にあるものと認める。
　
２．引用文献の記載事項
（１）これに対して、原査定の拒絶の理由に引用した特開平５−１２０００号公報（平成５年１月２２日特許庁発行）（以下、「引用文献１」という。）には、
移動局無線機に内装された端末ソフトのバージョン変更方法に関する発明が記載されており、そこには、
　「【０００５】
【課題を解決するための手段】（略）本発明に係る端末ソフトのバージョン変更方法は、移動局無線機に内装された該端末ソフトのバージョン変更方法において、プログラム用ＲＡＭとして電気的消去型のメモリを前記端末に実装する一方、車両電源をオンに維持した状態で、ホストコンピュータを備えた基地局無線機から前記端末にバージョンの変更されたソフトを無線伝送することを特徴としている。」
　「【０００７】
【実施例】以下、本発明に係る車載端末ソフトのバージョン変更方法の実施例を図面に基づいて説明する。図１は移動局無線機１３とホストコンピュータ１１を備えた基地局無線機１２とを示す概略ブロック図であり、基地局無線機１２にはホストコンピュータ１１が接続されている。また、移動局無線機１３には車載端末１９が内装されており、車載端末１９は基地局無線機１２を介してホストコンピュータ１１とアクセスすることができるようになっている。車載端末１９は中央処理演算装置ＣＰＵ１５、Ｉ／Ｏポート１４、プログラム用ＲＡＭ１６とデータ用ＲＡＭ１７等とのメモリ部、及び電源用リレー１８を含んで構成されている。ＣＰＵ１５にはプログラム用ＲＡＭ１６及びデータ用ＲＡＭ１７がそれぞれ接続されており、ＣＰＵ１５はＩ／Ｏポート１４を介して移動局無線機１３の本体側に接続されている。また、Ｉ／Ｏポート１４からは電源用リレー１８には制御信号が送られるようになっており、電源用リレー１８は車載バッテリー（図示せず）及び移動局無線機１３の反対側に接続されている。」
　「【０００９】以下、車載端末ソフトのバージョンを変更する際のホストコンピュータ１１の動作手順を、図２に基づいて説明する。車載端末ソフトのバージョン変更の開始時、ソフトデータの送出回数はｋ＝０から始められ、ホストコンピュータ１１は全車載端末１９に対してソフト送出開始データを送信する（ステップ１）。その後ホストコンピュータ１１から全車載端末１９へソフトデータの送信を行なう（ステップ２）。この際、ソフトデータの送信回数は１加算されてｋ＝ｋ＋１となる。そして、全車載端末１９へのソフトデータの送信が完了すると、ホストコンピュータ１１によって後述する車載端末１９からのソフト受信完了データが全車載端末１９から受信されたかどうかが判断される（ステップ３）。車載端末１９からのソフト受信完了データが全車載端末１９から受信された場合、ホストコンピュータ１１は全車載端末ソフトのバージョン変更が完了したと判断して、ソフトデータの送信を終了する。
【００１０】一方、車載端末１９からのソフト受信完了データが全車載端末１９から受信されない場合、ソフトデータの送出回数がｋ＝３であるかどうかが判断される（ステップ４）。ソフトデータの送出回数がｋ＜３の場合、ステップ１に戻って、ソフトデータの送出回数がｋ＝３になるまで、全車載端末１９へソフトデータ送信のためにステップ１からステップ３まで同様の動作が繰り返される。なお、その間においてもステップ３において、車載端末１９からのソフト受信完了データが全車載端末１９から受信され、全車載端末ソフトのバージョン変更が完了したと判断された場合には、ソフトデータの送信を終了する。そして、ソフトデータの送出回数がｋ＝３となった場合には、全車載端末ソフトのバージョン変更が完了しなかった場合にも、ソフト変更不可の車両番号を表示して（ステップ５）ソフトデータの送信を終了する。なお、ステップ４においてソフトデータ送信回数ｋ＝３としたのは、複数回のソフトデータ送信を行うことにより、１回のソフトデータの送信によってソフトデータを受信しなかった車載端末１９にもソフトデータを受信するチャンスを与えるものであり、ソフトデータの送信回数は３回に限定されるものではない。しかし、複数回のソフトデータ送信に対してソフトデータを受信しなかった車載端末１９については、後述するように、あらかじめ車載端末１９の電源がオン状態となっていなかったり、あるいは故障していることも考えられるので、そのような車載端末１９に対しては車載端末１９の電源がオン状態となっていることを確認した後、改めてソフトデータ送信を行うことが望ましい。
【００１１】次に、車載端末ソフトのバージョンを変更する際の、上記したホストコンピュータ１１の動作手順に対応した各車載端末１９の動作手順を図３に示す。まず、ホストコンピュータ１１から車載端末ソフトのバージョン変更のソフトデータを受けようとする場合には、あらかじめ電源用リレー１８のオンにより、車載端末１９の電源をオン状態にしておく。この状態で、ホストコンピュータ１１から全車載端末１９に対してソフト送出開始データが送信されると、各車載端末１９はソフト送出開始データの受信が可能となり、前記ソフト送出開始データを受信したかどうかが判断される（ステップ６）。ホストコンピュータ１１からソフト送出開始データを受信したと判断されなかった場合は通常のジョグソフトが実行される（ステップ７）。ホストコンピュータ１１からソフト送出開始データを受信したと判断された場合には、次に各車載端末１９はホストコンピュータ１１からのソフトデータを受信する。その後、ソフトデータの受信が完了したかどうかが判断され（ステップ８）、ソフトデータの受信が完了していないと判断された場合には、ソフトデータの受信が完了するまでステップ８の判断が繰り返され、ソフトデータの受信が完了したと判断された場合には、各車載端末１９はそれぞれ自車番秒待機する（ステップ９）。自車番秒待機した後、ソフト受信完了データをホストコンピュータ１１に送信し（ステップ１０）、それぞれ電源用リレー１８をオフにして移動局無線機１３の電源をオフにする（ステップ１１）。
【００１２】以上のごとく本実施例に係る車載端末ソフトのバージョン変更方法によれば、車載端末ソフトは電気的に消去可能なメモリ部に格納されているので、ホストコンピュータ１１が基地局無線機１２を介して移動局無線機１３にソフトデータを送信するだけで、人手を費やすことなく、無線機を通常使用していない夜間等を利用して自動的に短時間で車載端末ソフトのバージョンを変更することができる。」
と、記載されている。
　
（２）又、同じく、原査定の拒絶の理由に引用した特開平４−３５４４４５号公報（平成４年１２月８日特許庁発行）（以下、「引用文献２」という。）には、デジタルコードレス電話装置において、
「【０００１】
【産業上の利用分野】本発明は、デジタル化されたデータの送受信で通話を行うデジタルコードレス電話装置に関する。」
　「【０００３】ここで、このデジタルコードレス電話装置の子機を使用して通話以外の各種サービスを行うことが考えられている。例えば、各種データを受信させて、この受信データを表示させたり、或いはセットされたゲームプログラムにより、ビデオゲームが楽しめるようにすること等が考えられる。」
　「【００１９】そして本例においては、このデジタルコードレス電話装置の子機のアプリケーションプログラム用ＲＡＭ２４に記憶されたプログラムを使用して、ゲームプログラムなどが実行できるようにしてある。まず、このアプリケーションプログラムをＲＡＭ２４に記憶させるダウンローディングを行う場合について説明すると、この場合の全体システムを図５に示す。この図５において、親機ＢＳはテレポイントシステムの基地局を想定し、この基地局から１００ｍ以内程度の屋外で各子機（端末局）ＭＳ１，ＭＳ２‥‥が使用されるとする。この場合、親機ＢＳは有線の電話回線Ｌと接続されていると共に、マスタＲＯＭ装置ＢＳ′が接続してある。このマスタＲＯＭ装置ＢＳ′は、このテレポイントシステムに接続可能なデジタルコードレス電話装置で使用可能な種々のアプリケーションプログラムが格納させてある。
【００２０】そして、この基地局ＢＳの近傍の何れかの子機から、アプリケーションプログラムの送信要求があると、マスタＲＯＭ装置ＢＳ′に格納されたアプリケーションプログラムの中の対応したものを、該当する子機に送信する。このときには、基地局ＢＳからの送信スロットとして、図６Ｂに示すように、音声データの代わりに、ブロック番号とプログラムデータとが割り当てられ、１組のアプリケーションプログラムが１スロット毎に分割されて伝送される。
【００２１】そして、子機側ではこの１スロット毎のアプリケーションプログラム用データを受信する毎に、制御用ＲＯＭ２３に記憶された受信データロード用プログラムに従ってエラー検出及び訂正を行い、訂正処理により正確なデータが得られたか否かの情報を基地局ＢＳ側に返送する。このときの子機からの送信スロットは、図６Ｃに示すように、音声データの代わりに、ブロック番号と肯定応答（ＡＣＫ）情報又は否定応答（ＮＡＫ）情報とが割り当てられる。
【００２２】そして、基地局ＢＳ側では、正確な受信ができたことを示す肯定応答が返送されたとき、順次送信するプログラムのデータを進め、正確な受信ができなかったことを示す否定応答が返送されたとき、肯定応答が返送されるまで同じスロットのデータの送信を繰り返す。」
と、記載されている。
　
３．対比
　本願発明と上記引用文献１に記載の発明とを対比すると、
引用文献１に記載の発明における
「端末ソフト」，「バージョン変更方法」，「車載端末１９」，「プログラム用ＲＡＭとして電気的消去型のメモリ」及び「プログラム用ＲＡＭ１６」，「移動局無線機１３」，「基地局無線機１２」，「ホストコンピュータ１１」は、それぞれ、本願発明の「プロセッサ制御プログラム」，「再ロード方法」，「プロセッサ制御される機器（ＰＧ）」及び「移動通信機器」，「消去防止された固定データメモリ（プログラムメモリ素子ＰＳＢ）」，「無線データ伝送インタフェース（ＤＵＳＦ）」，「無線のデータ伝送インタフェース（ＤＵＳＮ）」，「再ロードステーション（ＮＬＳ）」に相当し、又、引用文献１に記載の発明においても、移動無線機は車両内に設置された車載装置であるので、両者は共に、
プロセッサ制御される機器（ＰＧ）におけるプロセッサ制御プログラムの再ロード方法において、プロセッサ制御される機器（ＰＧ）は、車両（ＦＺ）内に配置された移動通信機器であり、前記プロセッサ制御プログラムは消去防止された固定データメモリ（プログラムメモリ素子ＰＳＢ）にロードされており、プロセッサ制御される機器（ＰＧ）の無線データ伝送インタフェース（ＤＵＳＦ）と、ロードのために設けられやはり無線のデータ伝送インタフェース（ＤＵＳＮ）を備えた再ロードステーション（ＮＬＳ）とを介してロードが行われるものである点では同じである。
　
　ただ、（ａ）本願発明においては、プロセッサ制御される機器（ＰＧ）は交通案内−情報システムにおいて用いられるものであると、具体的に明示されているのに対して、引用文献１に記載の発明においては、車載装置であるとしか述べられておらず、又、（ｂ）本願発明においては、プロセッサ制御される機器（ＰＧ）に、ロードプログラムがインストールされており、該ロードプログラムはデータ伝送インタフェース（ＤＵＳＦ）ならびに固定データメモリ（ＰＳＢ）の消去と新規プログラミングを制御しているとされているのに対して、引用文献１に記載の発明においては、そのようなプログラムがインストールされていることは特に言及されておらず、更に、（ｃ）本願発明においては、再ロードプログラムの存在がシステムの送信ビーコンを介して車両（ＦＺ）へ通報されているのに対して、引用文献１に記載の発明においては、そのような通報をすることは言及されておらず、（ｄ）更に又、本願発明においては、再ロードすべきプロセッサ制御プログラムないしプログラム部分は、プロセッサ制御される機器（ＰＧ）により再ロードステーション（ＮＬＳ）に対しブロックごとに要求されて記憶され、個々のプログラムブロックはブロックごとの伝送にあたりチェックサムにより誤り保護され、プログラム入力終了後、再ロードされたプロセッサ制御プログラムは、長さならびにチェックサムの比較によりデータ伝送エラーの有無についてチェックされるようになされているのに対して、引用文献１に記載の発明には、そのような具体的な方法については明示されていない点で、両者は相違している。
　
４．相違点（ａ）〜（ｄ）についての当審の判断
　よって、上記相違点（ａ）〜（ｄ）について判断すると、
（ａ）については、交通案内−情報システムは、本願明細書に記載されている、ヨーロッパ特許公開第００２１０６０号公報（１９８１年１月７日発行）の記載からも明らかなように周知であり、引用文献１に記載の発明にそのような周知の交通案内−情報システムを適用して本願発明のようにしたところに、何等格別のものは認められない。したがって、刊行物１に記載の発明に該周知の事項を適用して本願発明のようにすることは、当業者が容易に発明をすることができたものと認められる。よって、相違点（ａ）は、格別の相違点であるものとは認められない。
　
　次に（ｂ）については、プログラムをロードする場合に、ロードされる機器内にロードプログラムを予めインストールしておき、該ロードプログラムに基づいて機器が制御され、プログラムのロードが実行されるように構成することは、引用文献２の段落【００２０】〜【００２１】に、基地局ＢＳから子機へアプリケーションプログラムを送信する場合に、子機側では、制御用ＲＯＭ２３に記憶された受信データロード用プログラムに従って受信を行うことが記載されているので、引用文献１に記載の発明に上記引用文献２に記載の発明を適用して本願発明のようにすることは、当業者が容易に発明できたものと認められる。したがって、相違点（ｂ）も、格別の相違点であるものとは認められない。
　
　更に、（ｃ）については、機器へ再ロードすべき再ロード制御プログラムというのは、通常、バージョンアップがあったプログラムであるので、そのようなプログラムが存在する時には、それを機器へロードするように促すための信号を機器へ送信することによって、再ロード制御プログラムの存在を通報することは、プログラムのバージョンアップにおいて一般的に行われていることであるものと認められる。そして、再ロード制御プログラムの存在を車両に通報する手段として、既存のシステムの送信ビーコンを介して行われるようにすればよいことは、当業者であれば容易に想到することができた程度のものと認められる。したがって、本願発明において、既存のビーコンを用いた通報手段を設けることは当業者が通常なしうることであって、何ら格別のもととは認められない。
　
　更に又、（ｄ）については、上記引用文献２の段落【００２０】〜【００２１】には、基地局Ｂから子機へアプリケーションプログラムを送信する場合、基地局ＢＳからの送信は、１組のアプリケーションプログラムが１スロット毎に分割されて伝送され、子機側ではこの１スロット毎のアプリケーションプログラム用データを受信する毎に、エラー検出及び訂正を行いながら受信することが記載されており、引用文献２の１スロットが本願発明の１ブロックに対応しているので、上記引用文献２に記載の発明は、本願発明と同様に、再ロードすべきプログラムは、ブロック毎に分割されて記憶されており、それが１ブロック毎に伝送され、受信された後、データ伝送エラーの有無についてチェックされているものであると認められる。そして、エラーチェックの手法として、長さならびにチェックサムの比較することは、当業者に周知の事項であるので、それを上記引用文献１に記載の発明に適用して、本願発明のようにすることは、当業者が容易に発明できたものと認められる。
　
　以上のとおりであるので、本願発明は、上記引用文献１に記載の発明に、上記引用文献２に記載の発明及び上記周知の発明を適用することによって、当業者が容易に発明をすることができたものと認められる。
　
５．審判請求人の主張について
　審判請求人は、平成１３年１２月１２日付け提出の手続補正書の審判請求の理由中の「【本願発明が特許されるべき理由】」において、
　「本願は、プロセッサ制御される機器におけるプロセッサ制御プログラムの新規ロードないし再ロード方法に関する発明であります。そして本願発明による特徴によれば、プロセッサ制御される機器は車両内に配置された交通案内−情報システムの機器です。さらに本願発明によれば、再ロード制御プログラムの存在は、交通案内−情報システムの送信ビーコンを介して車両へ通報されます。」
　「引用例１はたしかに車両に設置された車載端末に関するものでありますが、交通案内−情報システムに係わるものではありません。さらに引用例１には、本願発明のようにプロセッサ制御される機器にインストールされていてデータインタフェースの通信ならびに固定データメモリの消去と新規プログラミングを制御するロードプログラムについて開示されていません。しかも引用例１には、再ロード制御プログラムの存在が、交通案内ー情報システムの送信ビーコンを介して車両へ通報されることなどまったく示されていません。」
　「引用例２にも、本願発明の上述の特徴のうち殊に、再ロード制御プログラムの存在が、車両のシステムの送信ビーコンを介して車両へ通報されることなどまったく示されていません。この構成を採用したことで、現行のインフラストラクチャで交通案内−情報システムの送信ビーコンを利用できるという利点を得ることができます。」
　「以上のことから明らかなように、いずれの引用例からも、また、それらの組み合わせからも、本願発明へ想到することはできません。」
と主張している。
　
　よって、該主張について判断する。
　本願発明が適用されるような、交通案内−情報システムというのは、上記したように、ヨーロッパ特許公開第００２１０６０号公報（１９８１年１月７日発行）の記載からも明らかなように周知であって、本願明細書の記載を見ても、引用文献１に記載の発明と該周知の発明を結びつけて本願発明のようにしたところに何らかの困難性があるものとは認められないので、引用文献１に記載の発明に上記周知の発明を適用して本願発明のようにすることは、当業者が容易に発明をすることができたものと認められる。又、プログラムをインストールする場合には、インストールされる側は、インストール動作を制御するためのロードプログラムを有しているのが通常であり、又、引用文献２における「受信データロード用プログラム」というのは、本願発明の「ロードプログラム」に相当するものであるものと認められる。更に、本願発明においては、再ロード制御プログラムの存在が、交通案内−情報システムの送信ビーコンを介して車両へ通報されているが、プログラムのバージョンアップがあり、プログラムを再ロードする必要がある場合には、そのことをプログラムのユーザに知らせ、再ロードを促すための信号を発信してユーザに通知することは通常行われていることであり、本願明細書の記載を見ても、そのための送信ビーコンとして、既存のインフラストラクチャである交通案内−情報システムの送信ビーコンを用いたところに、格別の効果があるものとは認められない。
　
　したがって、審判請求人の係る主張には、根拠がなく、採用することはできない。
　
６．むすび
　以上のとおりであるので、本願特許請求の範囲の請求項１に記載された発明は、上記引用文献１，２に記載された発明及び周知の発明に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができないものである。
　
　よって、結論のとおり審決する。