【事件の表示】
　特願２０００−４０２４２０「通信制御装置」拒絶査定不服審判事件〔平成１４年　７月１９日出願公開、特開２００２−２０４２３８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯と本願発明
　本願は、平成１２年１２月２８日の出願であって、平成２１年７月７日付けで拒絶査定がされ、これに対し、同年１０月１３日に拒絶査定不服の審判が請求されるとともに、同日付けで手続補正がされ、平成２３年６月１０日付けで当審の拒絶理由が通知され、同年８月８日付けで手続補正がされたものである。
　
　特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成２３年８月８日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「複数の演算処理装置のそれぞれに、各種の制御に対応した複数の制御プログラムを備えるとともに、該各制御プログラムのデータの少なくとも送信のコントロールを行う通信プログラムを備え、前記複数の演算処理装置間の通信を行う車両用通信制御装置において、
　前記通信プログラムを、前記複数の制御プログラムで共通して使用し、且つ前記複数の演算処理装置間でデータの送受信を行うものとして共通して使用可能な共通通信プログラムとするとともに、該共通通信プログラムを前記各演算処理装置の各制御プログラムと分離した構成とすることを特徴とする車両用通信制御装置。」
　
第２　引用発明
Ａ　当審の拒絶理由に引用された特開平８−２７５２７５号公報（以下、「引用例１」という。）には図面とともに以下の事項が記載されている。
　
イ．「【０００１】
【産業上の利用分野】この発明は、複数の通信ノードが共通の通信線に接続されて構成される車両用多重伝送装置に関する。」（２頁１欄）
　
ロ．「【００１０】
【実施例】以下、添付図面を参照しながら本発明の好適な実施例を説明する。図１は、本実施例の自動車の多重伝送ネットワークで用いられる通信ノードの回路構成及びネットワークに対する接続形態の一例を示した図である。図１において、本実施例の多重伝送システムにおいては、演算処理機能を有するＣＰＵと多重伝送路とのインタフェース機能を有する通信ＩＣとが一体化されて内蔵された通信ノード１０（以下、ベーシックノード）、ＣＰＵと通信ＩＣとが別々のＩＣとして内蔵された通信ノード２０及び３０（以下、ハイスピードノード）、ＣＰＵを有さず多重伝送路との間でデータの入出力を行うＩ／Ｏ機能のみを有する通信ノード（以下、スタンドアロン型ノード）の３種類の通信ノードが設けられる。但し、本実施例では、上記スタンドアロン型ノードは図示を省略している。
【００１１】上記３種類の通信ノードの内、スタンドアロン型ノードは、例えば、リヤデフスイッチとそのスイッチが投入されたことを示す表示ランプの表示の制御のような高度なデータ処理を不要とする通信制御とデータの簡単な入出力を実行できる。ベーシックノード１０（ＣＰＵ内蔵型通信ノード）とハイスピードノード２０、３０との違いは、ベーシックノードがＣＰＵと通信ＩＣとが一体的に１チップのＩＣで搭載されているのに対して、ハイスピードノードは別々のＩＣとして夫々別体に搭載されている点にある。
【００１２】図２に、上記通信ノードの回路構成を示す。図示のように、例えば、ＡＢＳコントローラ(Anti-lock-brakesystem )を司る通信ノードは、通信用ＩＣ１０１を介して高速伝送路ＭＢ１及び中低速伝送路ＭＢ２に接続されている。１００は制御を行なうＣＰＵであり、ＲＡＭ／ＲＯＭ１０２に格納されたプログラムに従って動作する。CSMA/CD方式の物理層レベルのプロトコル制御は通信ＩＣ１０１により行なわれる。ＣＰＵ１００は、入力インタフェース（Ｉ／Ｆ）部１０３を介して各種センサやスイッチ等の入力補器１０４から信号が入力されると共に、出力インタフェース（Ｉ／Ｆ）部１０５を介して、ソレノイドバルブ駆動モータ等の出力補器１０６に制御信号を出力する。
【００１３】更に、ＣＰＵ１００は、通信用ＩＣ１０１を制御し、入力補器１０４から入力した信号を他の通信ノードが用いる所定の通信フレームに記入して多重伝送路ＭＢ１又はＭＢ２に送出すると共に、通信用ＩＣ１０１が受け取った他のノードからのデータを制御信号に演算処理して出力補器１０６に送出する。即ち、ＣＰＵ１００は、バス上のフレームデータを電装ユニット１０４が使用可能なフォーマットに変換したり、電装ユニット１０４からのデータを所定のフレームフォーマットに変換したりする。
【００１４】入力補器１０４からの入力信号は、入力インタフェース（Ｉ／Ｆ）部１０３を介してＣＰＵ１００に出力される。一方、ＣＰＵ１００から出力される制御信号は、診断機能付き出力ドライバ１０９（IPS : intelligent power switching )を介して出力補器１０６に送出される。ＩＰＳ１０９はＣＰＵ１００から送出される制御信号が正常か否かを診断する。
【００１５】図１，図２において、ハイスピードノード２０、３０は、主にイグニッションスイッチがオンされて通信動作を開始する高速伝送路ＭＢ１に接続され、主に時間的な変化の激しい車輪速等のデータの授受を必要とするＡＢＳや４ＷＳを制御する通信ノードとなる。ハイスピードノード２０には、車輪速等を検出するセンサ２６が入力Ｉ／Ｆ１０３を介してＣＰＵ１００に接続されると共に、ＡＢＳ等を制御するソレノイドバルブ駆動モータ２７が出力Ｉ／Ｆ１０５を介してＣＰＵ１００に接続されている。同様に、ハイスピードノード３０には、ヘッドライト等のスイッチ類３６が入力Ｉ／Ｆ１０３を介してＣＰＵ１００に接続されると共に、4WS等を制御する駆動モータ３７及びブレーキランプ３８が出力Ｉ／Ｆ１０５を介してＣＰＵ１００に接続されている。
【００１６】ベーシックノード１０は、高速伝送路ＭＢ１及び中低速伝送路ＭＢ２に接続され、主に集中ドアロックやパワーウインドウ等を制御する通信ノードとなる。ベーシックノード１０には、集中ドアロックのメインスイッチやパワーウインドウスイッチ等のスイッチ１６が入力Ｉ／Ｆ１５３を介してＣＰＵ１５０接続されている。同様に、ベーシックノード３０には、ウインド開閉モータ等のアクチュエータ１７が出力Ｉ／Ｆ１０５を介して接続されている。周知のように、ドライバ席のスイッチは、集中的に他のドアのウインドの開閉やドアロックも行なうことができるようになっているために、ベーシックノードが用いられている。また、助手席や後部座席においては、それらの個々の座席のウインドを開閉するだけであるので、ウインド開閉モータ等のアクチュエータが接続されたスタンドアロン型ノードが用いられる。」（３頁３〜４欄）
　
ハ．「【００２１】図４は、各ノードのＣＰＵのＲＯＭ１０２ｂにおける記憶領域の構成を示す。同図に示すように、各ノードのＲＯＭ１０２ｂにおいては、主に３つのプログラム／データが記憶されている。それは、当該ノードに接続された補器を制御するためのアプリケーションプログラム３００、このノードの通信制御ＩＣ１０１とデータの交換を実行するためのデータ転送制御マネージャプログラム３０１、そしてこのマネージャプログラム３０２が通信制御を行なう上で必要な各種の固有パラメータを格納する通信制御パラメータ３０２である。アプリケーションプログラムは当該ノードに接続されている特定の補器を制御するためのものであるから、ノード毎に異なるものであり、もし４つのノードＡ，Ｂ，Ｃ，Ｄ，…が接続されているのならば、アプリケーションプログラムＡ，アプリケーションプログラムＢ…は互いに異なることになる。
【００２２】本実施例の最大の特徴は、データ転送制御マネージャプログラム３０１を各ノード間で共通にしたことである。従って、データ転送制御マネージャプログラム３０１は、その内容、そのプログラムが記憶されているＲＯＭ１０２ｂ内のアドレスも、各ノード間で同じである。一方、ＩＣ１０１とＣＰＵ１００との間のデータ転送制御の細部において各ノード間で異なるところは制御パラメータ３０２として記憶されている。
【００２３】この実施例では、制御パラメータの例として、当該ノードに与えられた識別子とする。前述したように、アプリケーションプログラムと制御パラメータはノード間で異なる。本実施例では、メモリ１０２における共通化を促進する目的で、アプリケーションプログラム３００とデータ転送制御マネージャ３０１と制御パラメータ３０２の夫々の記憶アドレスを共通化する。このために、メモリ１０２の先頭に３つのポインタを有する。これらのポインタは、アプリケーションプログラムが記憶されているメモリアドレスを格納するAP-PTR２００、データ転送制御マネージャ３０１が記憶されているアドレスを格納するDTM-PTR２０１、制御パラメータ２０２が記憶されているアドレスを格納するPAR-PTR２０２である。
【００２４】このように、アプリケーションプログラム３００とデータ転送制御マネージャ３０１と制御パラメータ３０２の記憶アドレスを示すポインタを所定位置に記憶させておくことで、アプリケーションプログラム３００とデータ転送制御マネージャ３０１と制御パラメータ３０２のいずれに修正があっても、ポインタ領域に変動は発生することはなく、また、アプリケーションプログラム３００とデータ転送制御マネージャ３０１と制御パラメータ３０２のいずれかが修正された場合、その修正された部分においてのみ変更を行なえばよいことになる。
【００２５】従って、図４に示すように、AP-PTR２００，DTM-PTR２０１，PAR-PTR２０２，データ転送制御マネージャ３０１の夫々はノード間において共通であり、一方、アプリケーションプログラム３００，パラメータ３０２は各ノード間において異なり固有である。図５は、ＲＡＭ１０２ａの格納データを示す。ＲＡＭ１０２ａは主に沸くようのデータを格納するもので、実施例では、通信回線に送信すべき送信用データを一時的に格納するＳバッファ４００と、通信回線から受信したデータを一時的に格納するＲバッファ４０１を有する。
【００２６】図６は各ノード間で同じであるところのデータ転送制御マネージャの制御手順を示す。従って、図６の制御手順は図１のいずれのノードのＣＰＵにおいても共通して行なわれる。一方、図７は各ノードに固有のアプリケーションプログラムの制御手順である。まず図６のステップＳ２において、通信ＩＣ１０１に対して、通信回線からフレームデータを受信したか否かを問い合わせる。受信フレームがないならば、ステップＳ２０に進んで、このノードにおいて他のノードに送るべきフレームデータが発生したかを調べる。そのようなデータが発生していなければ（フラグＦ＝０）、ステップＳ２に戻って通信制御ＩＣ１０１がフレームを受信したかを調べる。
【００２７】ステップＳ２においてＩＣ１０１がフレームを受信したことが確認されたならば、ステップＳ４に進んで、当該フレームデータをＩＣ１０１からＲバッファ４０１に転送する。ステップＳ６では、制御パラメータ領域３０２中の識別子を読み出す。この読出は、PAR-PTR２０２に従って領域３０２を知り、その中から識別子をとりだすものである。ステップＳ８では、この取り出した識別子とフレーム中のIDとを比較して、当該フレームが自ノード宛であるか否かを判断する。自ノード宛でないのであれば、そのフレームデータを無視して、ステップＳ２に戻る。一方、自ノード宛であれば、ステップＳ１０で、Ｒバッファにあるフレームデータをアプリケーションプログラムに渡す。
【００２８】図７は各アプリケーションプログラムのの制御手順を示す。ステップＳ３０では、Ｒバッファ４０１にあるデータがアプリケーションプログラムに渡されたか否かを調べる。この例では、ステップＳ１０（図６）でアプリケーションプログラムに渡されているので、ステップＳ３２に進んで、そのデータに基づいて、このノードに接続されている補器を制御する。この制御が終了するとステップＳ３４ではＲバッファ４０１をクリアする。
【００２９】図７のステップＳ４０は、所定時間毎に補器の状態を調べるためのトリガを検出する。即ち、補器の状態を調べるのは、個々のノードに固有の時間が割り当てられ、その時間がタイムアウトすると（ステップＳ４０でＹＥＳ）、ステップＳ４２で補器に接続されているセンサなどの状態を読み取る。ステップＳ４４では、この状態データに基づいてフレームデータを作成する。ステップＳ４６では、このデータをＳバッファ４００に送り、ステップＳ４８では送信データフラグＦをセットする。
【００３０】このフラグがセットされると、マネージャプログラム３０１は、ステップＳ２０からステップＳ２２に進み、パラメータ領域３０２から自ノードの識別子を読取、ステップＳ２４でこの識別子をＳバッファ４００中のフレームデータにIDとして付加する。ステップＳ２６では、Ｓバッファ４００の内容を通信ＩＣ１０１に送る。ステップＳ２８ではＳバッファの内容をクリアする。
【００３１】以上説明したように、図６に示されたマネージャプログラムは、当該ノードに固有の制御データ（例えば、識別子）をプログラムとは別個のパラメータ領域３０２中に有しているので、たとえ各ノード間で制御データ（例えば、識別子）の値が異なっていても、各ノードにおけるプログラムそのものにおいては制御データをアドレス（ポインタ）の形で有することとなり、従って、プログラムそのものの共通化を図ることができる。    さらに、アプリケーションプログラム領域３００やマネージャプログラム領域３０１は、その格納領域をポインタの形態で表現されているので、プログラム変更が容易である。」（４頁５欄〜５頁８欄）
　
　上記引用例１の記載及び図面ならびにこの分野における技術常識を考慮すると、上記摘記事項イ．の記載、ロ．の【００１０】〜【００１３】、【００１５】の記載、ハ．の【００２１】の記載、図１、２及び４によれば、車両用多重伝送装置は、複数の通信ノードのそれぞれに、各種の制御に対応したアプリケーションプログラムを備えている。
　また、車両用多重伝送装置は、複数の通信ノード間の通信を行うことは自明である。
　また、上記摘記事項ハ．の【００２１】、【００２２】、【００２６】、【００２８】〜【００３０】の記載、図４、６及び７によれば、車両用多重伝送装置は、アプリケーションプログラムのフレームデータを送るデータ転送制御マネージャプログラムを備えている。
　また、上記摘記事項ハ．の【００２１】、【００２２】の記載、及び図４によれば、データ転送制御マネージャプログラムは、アプリケーションプログラムで共通して使用され、且つ複数の通信ノード間で共通して使用可能な共通データ転送制御マネージャプログラムである。
　また、上記摘記事項ハ．の【００２１】、【００２２】の記載、及び図４によれば、共通データ転送制御マネージャプログラムは、各通信ノードのアプリケーションプログラムと分離した構成である。
　
　したがって、上記引用例１には以下の発明（以下、「引用発明１」という。）が記載されている。
　
「複数の通信ノードのそれぞれに、各種の制御に対応したアプリケーションプログラムを備えるとともに、該アプリケーションプログラムのフレームデータを送るデータ転送制御マネージャプログラムを備え、前記複数の通信ノード間の通信を行う車両用多重伝送装置において、
　前記データ転送制御マネージャプログラムを、前記アプリケーションプログラムで共通して使用し、且つ前記複数の通信ノード間で共通して使用可能な共通データ転送制御マネージャプログラムとするとともに、該共通データ転送制御マネージャプログラムを前記各通信ノードのアプリケーションプログラムと分離した構成とする車両用多重伝送装置。」
　
Ｂ　当審の拒絶理由に引用された特開２０００−２５７５０１号公報（以下、「引用例２」という。）には図面とともに以下の事項が記載されている。
　
ニ．「【０００１】
【発明の属する技術分野】本発明は、マイクロコンピュータを備えた自動車用制御装置に関し、特に、そのマイクロコンピュータが、当該装置や他の自動車用制御装置に備えられた他のマイクロコンピュータとデータ通信を行うことにより、その通信対象のマイクロコンピュータと制御用データを共有するようにした自動車用制御装置に関する。」（４頁５欄）
　
ホ．「【００６８】図２に示すように、エンジンＥＣＵ２は、第１マイコン６０と第２マイコン６２との、２つのマイコンを備えている。尚、図示はしていないが、各マイコン６０，６２は、ＣＰＵ，プログラムを記憶する記憶媒体としてのＲＯＭ，データを一時記憶するためのＲＡＭ，及び入出力ポート等を備えた一般的なシングルチップマイクロコンピュータである。また、本実施形態において、各マイコン６０，６２のＲＡＭは、１アドレス当たりに１バイト（８ビット）のデータが格納されるものである。」（１０頁１８欄）
　
ヘ．「【００７３】次に、図３は、第１マイコン６０内の通信モデルを仮想的に示した概念図であり、この通信モデルは、ＩＳＯ／ＯＳＩ（Open System Interconnection ）通信モデルに準拠した階層化構造である。図３に示すように、本実施形態の第１マイコン６０で採用されている通信モデルは、制御対象を制御するための演算処理を行うアプリケーション部１００と、第２マイコン６２及び他のＥＣＵ４，６，８とデータの送受信を行う通信ドライバ部３００と、アプリケーション部１００によって算出される制御用データから、通信ドライバ部３００が送信すべき通信データ列を生成すると共に、通信ドライバ部３００によって受信された通信データ列を、アプリケーション部１００が使用可能な制御用データに変換する通信変換部２００とからなる。そして、通信変換部２００は、更に、共有メモリ部２１０と、物理値変換部２２０と、共通パケットデータ部２３０と、通信データ変換部２４０とに階層化されている。
【００７４】また更に、第１マイコン６０は、通信制御部４００とテーブル格納部５００とを備えている。そして、アプリケーション部１００から第２マイコン６２、或いは、他のＥＣＵ４，６，８に対して、直接データ転送されることはなく、アプリケーション部１００から下位の階層に対して順々にデータを渡し（仮想通信し）、通信ドライバ部３００にて、外部（通信対象）との物理的な通信が実現される。また、この通信モデルでの各階層は、その下の階層に対してサービスを要求し、その上の階層にサービスを提供するというものであり、各階層の目的は、上位階層でのサービスに対して実際の通信仕様等の詳細情報を隠蔽することである。
【００７５】尚、本実施形態において、各マイコン６０，６２により実行されるＲＯＭ内のプログラムは、プログラムの全機能を単位機能毎に細分化して、その単位機能毎にオブジェクトを用意するオブジェクト指向によってプログラミングされており、オブジェクトとは、データとそのデータを処理する手続きである“メソッド”と呼ばれるプログラムとを、一まとめにしたプログラムモジュールである。
【００７６】そして、図３の通信モデルにおいて、ソフトウエアだけに着目すると、テーブル格納部５００以外の各部１００〜４００は、第１マイコン６０のＲＯＭに格納された各オブジェクト（メソッド及びデータ）である。また、テーブル格納部５００は、第１マイコン６０のＲＯＭにて、後述する図４及び図５の各テーブルを記憶した記憶領域である。
【００７７】そして更に、本実施形態の説明において、例えば「共有メモリ部２１０が…する。」や「物理値変換部２２０は…する。」といったオブジェクトを主語とした動作表現は、実際には、第１マイコン６０がそのオブジェクトのメソッドに従って動作する（換言すれば、第１マイコン６０がそのオブジェクトのメソッドを実行する）ことで実現される機能手段が、上記「…」の動作を行うことを示している。同様に、例えば「共有メモリ部２１０によって…される。」や「物理値変換部２２０によって…される。」といったオブジェクトによる受け身の動作表現は、実際には、第１マイコン６０がそのオブジェクトのメソッドに従って動作することで実現される機能手段によって、上記「…」の動作が行われることを示している。
【００７８】ここで、アプリケーション部１００は、エンジンＥＣＵ２の制御対象及び制御内容毎に更に細分化された各オブジェクトからなる。そして、本実施形態において、アプリケーション部１００は、回転数Ｎｅ等の制御用データを算出して、その算出した制御用データに基づきエンジンを制御するための演算処理を行うオブジェクト（以下、エンジンアプリケーションソフトという）１１０と、車速ＳＰＤ等の制御用データを算出して、その算出した制御用データに基づきトランスミッションを制御するための演算処理を行うオブジェクト（以下、ＥＣＴアプリケーションソフトという）１２０と、エンジンのスロットル開度等の制御用データを算出して、その算出した制御用データに基づき車両を定速走行させるためのスロットル開度制御用演算処理を行うオブジェクト（以下、クルーズアプリケーションソフトという）１３０とを有している。そして、これらの各アプリケーションソフト１１０，１２０，１３０は、自分以外のアプリケーションソフトによって算出された制御用データも、自己の演算処理に用いる。つまり、各アプリケーションソフト１１０，１２０，１３０は、制御用データを互いに共有するようにしている。」（１１頁１９〜２０欄）
　
　上記引用例２の記載及び図面ならびにこの分野における技術常識を考慮すると、上記摘記事項ニ．の記載、ホ．の記載、ヘ．の【００７３】、【００７８】の記載、図２及び３によれば、自動車用制御装置は、電子制御装置（ＥＣＵ）に、各種の制御に対応した複数のアプリケーションソフトを備えている。
　
　したがって、上記引用例２には以下の発明（以下、「引用発明２」という。）が記載されている。
　
「電子制御装置（ＥＣＵ）に、各種の制御に対応した複数のアプリケーションソフトを備えた自動車用制御装置。」
　
第３　対比
　本願発明と引用発明１とを対比する。
ａ．引用発明１の「通信ノード」、「アプリケーションプログラム」、及び「フレームデータ」は、本願発明の「演算処理装置」、「制御プログラム」、及び「データ」にそれぞれ相当する。
ｂ．引用発明１の「フレームデータを送る」は、上記ａ．の対比を考慮すれば、「データの送信のコントロールを行う」ということができる。
ｃ．引用発明１の「データ転送制御マネージャプログラム」は、「通信プログラム」に含まれる。
ｄ．引用発明１の「車両用多重伝送装置」は、車両用通信制御装置の一種である。
　
　したがって、本願発明と引用発明１は、以下の点で一致ないし相違する。
　
＜一致点＞
「複数の演算処理装置のそれぞれに、各種の制御に対応した制御プログラムを備えるとともに、該制御プログラムのデータの少なくとも送信のコントロールを行う通信プログラムを備え、前記複数の演算処理装置間の通信を行う車両用通信制御装置において、
　前記通信プログラムを、前記制御プログラムで共通して使用し、且つ前記複数の演算処理装置間で共通して使用可能な共通通信プログラムとするとともに、該共通通信プログラムを前記各演算処理装置の制御プログラムと分離した構成とすることを特徴とする車両用通信制御装置。」
　
＜相違点１＞
　「制御プログラム」に関し、
　本願発明は、「複数の」ものであるのに対し、引用発明１は、単一のものである点。
　
　加えて、
　本願発明は、「各」制御プログラムのように、接頭語「各」が付されているのに対し、引用発明１は、接頭語「各」がない点。
　
＜相違点２＞　
　「共通通信プログラム」に関し、
　本願発明は、複数の演算処理装置間で「データの送受信を行うものとして」共通して使用可能なものであるのに対し、引用発明１は、その様な構成を備えているか不明な点。
　
第４　判断
　そこで、まず、上記相違点１について検討する。
　引用発明２の「電子制御装置（ＥＣＵ）」、及び「アプリケーションソフト」は、本願発明の「演算処理装置」、及び「制御プログラム」に相当し、引用発明１に引用発明２を採用することに特段の阻害要因は見あたらないから、引用発明１の「アプリケーションプログラム」（制御プログラム）に引用発明２を付加して、本願発明のように「複数の」ものとすることは当業者が容易に成し得ることである。また、その際、接頭語「各」を付すことができることは当然である。
　
　次に、上記相違点２について検討する。
　引用例１の上記摘記事項ハ．の【００２６】、【００２７】、【００３０】の記載、図６及び７によれば、複数の通信ノード（演算処理装置）間で「データの送受信を行うものとして」共通して使用可能なものであることは明らかであるから、本願発明のように、複数の演算処理装置間で「データの送受信を行うものとして」共通して使用可能なものということができることは当然である。
　
　さらに、本願発明の作用効果も、引用発明１及び２から当業者が容易に予測できる範囲のものである。
　
第５　むすび
　以上のとおり、本願発明は、引用発明１及び２に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。