【事件の表示】
　特願２００９−２３４４６６「制御装置、制御方法及びコンピュータプログラム」拒絶査定不服審判事件〔平成２３年　４月２１日出願公開、特開２０１１−　８１６７１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯 
　本願は平成２１年１０月８日の出願であって，平成２２年１２月２２日付けの拒絶理由の通知に対し，平成２３年２月２４日付けで意見書が提出されるとともに手続補正がなされたが，同年１１月２日付けで拒絶査定がされ，これに対し，平成２４年２月２日付けで拒絶査定不服審判の請求がなされたものである。 
 　 
２．本願発明 
　本願の請求項６に係る発明（以下「本願発明」という。）は，平成２３年２月２４日付けの手続補正書によって補正された明細書，特許請求の範囲及び図面の記載からみて，特許請求の範囲の請求項６に記載された事項により特定される，次のとおりのものである。　　
 「一又は複数のアプリケーションプログラムを実行し，前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行し，更に，前記アプリケーションプログラム及びプラットフォームプログラムの間の入出力データを夫々に適合するように変換して入出力処理を行なう中間処理プログラムを実行し，前記ハードウェア資源の制御を行なう制御方法において，
　外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルを記憶しておき，
　前記中間処理プログラムにより，
　前記テーブルに基づき，前記アプリケーションプログラムに適合するように入出力データを変換し，
　前記テーブルに基づき，前記プラットフォームプログラムに適合するように入出力データを変換する
　ことを特徴とする制御方法。」
 　 
３．引用例について
３．１　引用例１
（１）原査定の拒絶の理由に引用された，本願出願前の平成１６年７月８日に頒布された，特開２００４−１９２５４１号公報（以下，「引用例１」という。）には，図面とともに，次の事項が記載されている。（なお，下線は当審において付与したものである。）
（ア）「【請求項１】
　
プラットフォームプログラムと，アプリケーションプログラムとを備える車両用制御プログラムにおいて，さらに結合処理プログラムを備え
　
前記プラットフォームプログラムは，ハードウェアデバイスからデータを入力し，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って，前記入力したデータに基づくデータを前記結合処理プログラムによる処理に提供する処理をコンピュータに実行させるためのプログラムであり
　
前記結合処理プログラムは，前記ＰＦインターフェースに従って前記プラットフォームプログラムによる処理から提供されたデータを，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに適合するように変換することで前記アプリケーションプログラムによる処理に仲介する処理をコンピュータに実行させるためのプログラムであり
　
前記アプリケーションプログラムは，前記ＡＰインターフェースに従って前記結合処理プログラムによる処理から提供されたデータを用いた処理をコンピュータに実行させるためのプログラムである
　を特徴とする車両用制御プログラム。」
（イ）「【請求項９】
　
プラットフォームプログラムと，アプリケーションプログラムとを備える車両用制御プログラムにおいて，さらに結合処理プログラムを備え
　
前記プラットフォームプログラムは，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って出力のためのデータを前記結合処理プログラムによる処理から取得し，取得したデータに基づくデータを出力する処理をコンピュータに実行させるためのプログラムであり
　
前記結合処理プログラムは，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに従って前記アプリケーションプログラムによる処理から提供されたデータを，前記ＰＦインターフェースに適合するように変換して，前記プラットフォームプログラムによる処理に仲介する処理をコンピュータに実行させるためのプログラムであり，　前記アプリケーションプログラムは，出力対象のデータを生成し，前記ＡＰインターフェースに従って前記出力対象のデータを前記結合処理プログラムによる処理に提供する処理をコンピュータに実行させるためのプログラムである
　を特徴とする車両用制御プログラム。」
（ウ）「【００１４】
【課題を解決するための手段及び発明の効果】
　上述した問題点を解決するためになされた請求項１に記載の車両用制御プログラムは，プラットフォームプログラムと，アプリケーションプログラムと，結合処理プログラムとから構成されている。
【００１５】
　そして，
プラットフォームプログラムは，ハードウェアデバイスからデータを入力し，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って，前記入力したデータに基づくデータを結合処理プログラムによる処理に提供する処理をコンピュータに実行させるためのプログラムである。
【００１６】
　また，
結合処理プログラムは，ＰＦインターフェースに従ってプラットフォームプログラムによる処理から提供されたデータを，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに適合するように変換することでアプリケーションプログラムによる処理に仲介する処理をコンピュータに実行させるためのプログラムである。
【００１７】
　そして，
アプリケーションプログラムは，ＡＰインターフェースに従って結合処理プログラムによる処理から提供されたデータを用いた処理をコンピュータに実行させるためのプログラムである。このように，結合処理プログラムが，ＰＦインターフェースと，ＡＰインターフェースとの橋渡しを行うため，アプリケーションプログラムの開発者は，ＡＰインターフェース仕様，すなわち，開発対象の車両用制御装置の要求仕様を満たすインターフェース仕様に沿ってアプリケーションプログラムを作成することができる。すなわち，アプリケーションプログラムの開発者は，ＰＦインターフェース仕様を念頭において要求仕様を実現する方法を考える必要はなくなるので，アプリケーションプログラムの開発者の負担を軽減することができる。
【００１８】
　このようなＰＦインターフェースとして標準化する対象としては，例えば，請求項２に示すように，ＰＦインターフェースを介して提供するデータの構造及び当該データの更新タイミングなどが挙げられる。異なる要求仕様に従って作成されたアプリケーションプログラムは，異なるデータの構造を持つデータを必要とし，データの必要となるタイミング等も異なる。例えば，データの構造としては，どの入力対象（例えばどのセンサ）からの，どのような精度の，どのようなデータ型式（データ構造）のデータなのかという事項などを標準化して提供する。
　・・・（中略）・・・
【００２４】
　
以上，ハードウェアデバイスからデータの入力処理を行う場合の車両用制御プログラムの構成について説明したが，ハードウェアデバイスへ出力を行う場合にも，同様に構成するとよい。すなわち，入力処理の場合と同様に，車両用制御プログラムをプラットフォームプログラムと，結合処理部と，アプリケーションプログラムとに分けて構成する。例えば，請求項９に示すようにプラットフォームプログラムは，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って出力のためのデータを前記結合処理プログラムによる処理から取得し，取得したデータに基づくデータを出力する処理をコンピュータに実行させるためのプログラムとし，結合処理プログラムは，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに従ってアプリケーションプログラムによる処理から提供されたデータを，ＰＦインターフェースに適合するように変換して，プラットフォームプログラムによる処理に仲介する処理をコンピュータに実行させるためのプログラムとし，アプリケーションプログラムは，出力対象のデータを生成し，ＡＰインターフェースに従って前記出力対象のデータを結合処理プログラムによる処理に提供する処理をコンピュータに実行させるためのプログラムとする。
（エ）「【００３０】
【発明の実施の形態】
　以下，本発明が適用された実施例について図面を用いて説明する。なお，本発明の実施の形態は，下記の実施例に何ら限定されることなく，本発明の技術的範囲に属する限り種々の形態を採りうることは言うまでもない。
【００３１】
　本実施例の車両用制御装置は，エンジンの制御を行うためのエンジンＥＣＵであり，図１に本実施例の説明に必要な部分についての構成を図示している。本実施例のエンジンＥＣＵ１０と従来のエンジンＥＣＵとの差異は，ＲＯＭ１２に記憶されたプログラムの構成にあり，その他の構成は従来のエンジンＥＣＵと同様である。
【００３２】
　エンジンＥＣＵ１０は，図１に示すように，ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，Ｉ／Ｏ１４，Ａ／Ｄ変換器１５，タイマ１６等とこれらを接続するバスライン等から構成されている。そして，Ｉ／Ｏ１４やＡ／Ｄ変換器１５には，エンジン回転センサ２１，Ｏ２センサヒータ２２，水温センサ２３，…，といった各種のエンジン制御用装置２０が駆動回路等を介して接続されている。そして，ＲＯＭ１２に記憶されたプログラムをＣＰＵ１１が実行することによって，こうしたエンジン制御用装置２０からの信号の入力や，エンジン制御用装置２０に対する信号の出力を行う。例えば，ＣＰＵ１１による処理によって，エンジン回転センサ２１からのクランク軸の所定回転角毎（例えば１８０度毎）に発生するパルスをＩ／Ｏ１４から入力したり，Ｉ／Ｏ１４に対してＯ２センサを所定の動作温度まで加熱するためのＯ２センサヒータ２２をＰＷＭ制御するＯ２センサヒータ制御信号を出力したりする。また，Ａ／Ｄ変換器１５を介して，水温センサ２３から水温に対応する電圧値を入力し，入力した電圧値をデジタルデータとしてＲＡＭ１３等へ取り込む。
【００３３】
　こうした制御をＣＰＵ１１に実行させるためにＲＯＭ１２に記憶するプログラム１は，図２（ａ）に示すように，プラットフォームプログラム２（図中ＰＦで表記している）と，特許請求の範囲における結合処理プログラムに相当する結合処理部３と，アプリケーションプログラム４（図中ＡＰで表記している）とをリンクして構成している。
【００３４】
　
プラットフォームプログラム２は，Ｉ／Ｏ１４やＡ／Ｄ変換器１５等のハードウェアデバイスを制御する処理（ハードウェアに依存する処理）をＣＰＵ１１が実行するためのデバイスドライバを含むプログラムであり
【００３５】
　プラットフォームプログラム２と結合処理部３とアプリケーションプログラム４は別々に開発が行われており，プラットフォームプログラム２は，すでに開発済みの従来のエンジンＥＣＵに用いられていたものを利用する。一方，結合処理部３とアプリケーションプログラム４は新規に開発する。
【００３６】
　プラットフォームプログラム２は，図２（ｂ）に示すように，結合処理部３による処理からのＩ／Ｏ１４やＡ／Ｄ変換器１５の駆動要求を受け付けてＩ／Ｏ１４やＡ／Ｄ変換器１５を駆動し，また，Ｉ／Ｏ１４やＡ／Ｄ変換器１５から取得した情報を結合処理部３による処理から参照可能とする処理を行うことによって，結合処理部３の処理に対するインターフェースを提供する（ＰＦインターフェースと称する）。このＰＦインターフェースは，すでに開発済みの従来の車種のエンジンＥＣＵの要求仕様を満足するように標準化して構成されている。
【００３７】
　また，
結合処理部３は，ＰＦインターフェースを介して取得した情報を開発対象のアプリケーションプログラム４の要求仕様を満足する情報に変換してアプリケーションプログラム４の処理から参照可能とする処理と，アプリケーションプログラム４による処理によって生成された要求仕様に従った出力対象の情報を参照してＰＦインターフェースの要求する情報に変換してＰＦインターフェースを介してＩ／Ｏ１４へ出力させる処理をＣＰＵ１１に行わせるプログラムである。
（２）上記記載及び図面から，引用例１には，以下のことが記載されているということができる。 
（ａ）引用例１に記載された技術は，プラットフォームプログラムと，アプリケーションプログラムと，結合処理プログラムを備える車両用制御プログラムに係るものであること。
（ｂ）引用例１のプラットフォームプログラムは，Ｉ／ＯやＡ／Ｄ変換器等のハードウェアデバイスを制御する処理（ハードウェアに依存する処理）を実行するためのデバイスドライバを含むプログラムである。また，当該プラットフォームプログラムは，ハードウェアデバイスからデータを入力し，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って，前記入力したデータに基づくデータを結合処理プログラムによる処理に提供する処理を行い，また，前記ＰＦインターフェースに従って出力のためのデータを結合処理プログラムによる処理から取得し，取得したデータに基づくデータを出力してハードウェアデバイスを制御する処理を行うものである。
（ｃ）引用例１のアプリケーションプログラムは，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに従って結合処理プログラムによる処理から提供されたデータを用いた処理を行い，また，出力対象のデータを生成し，前記ＡＰインターフェースに従って前記出力対象のデータを結合処理プログラムによる処理に提供する処理を行うものである。
（ｄ）引用例１の結合処理プログラムは，前記ＰＦインターフェースに従って前記プラットフォームプログラムによる処理から提供されたデータを，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに適合するように変換することで前記アプリケーションプログラムによる処理に仲介する処理を行い，また，前記ＡＰインターフェースに従って前記アプリケーションプログラムによる処理から提供されたデータを，前記ＰＦインターフェースに適合するように変換して，前記プラットフォームプログラムによる処理に仲介する処理を行うものである。
（ｅ）引用例１の車両用制御プログラムにおける各プログラムによる処理は，実質的に車両を制御するための車両用制御方法ともいえるものである。
（３）以上のことから，引用例１には，次の発明（以下，「引用発明」という。）が記載されていると認められる。 
 「プラットフォームプログラムと，アプリケーションプログラムと，結合処理プログラムによる車両用制御方法において，
　プラットフォームプログラムは，ハードウェアデバイスからデータを入力し，異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースであるＰＦインターフェースに従って，前記入力したデータに基づくデータを結合処理プログラムによる処理に提供する処理を行い，また，前記ＰＦインターフェースに従って出力のためのデータを結合処理プログラムによる処理から取得し，取得したデータに基づくデータを出力してハードウェアデバイスを制御する処理を行い，
　アプリケーションプログラムは，開発対象の車両用制御装置の要求仕様を満たすインターフェースであるＡＰインターフェースに従って結合処理プログラムによる処理から提供されたデータを用いた処理を行い，また，出力対象のデータを生成し，前記ＡＰインターフェースに従って前記出力対象のデータを結合処理プログラムによる処理に提供する処理を行い，
　結合処理プログラムは，前記ＰＦインターフェースに従って前記プラットフォームプログラムによる処理から提供されたデータを，前記ＡＰインターフェースに適合するように変換することで前記アプリケーションプログラムによる処理に仲介する処理を行い，また，前記ＡＰインターフェースに従って前記アプリケーションプログラムによる処理から提供されたデータを，前記ＰＦインターフェースに適合するように変換して，前記プラットフォームプログラムによる処理に仲介する処理を行う
　車両用制御方法。」
３．２　引用例２
（１）原査定の拒絶の理由に引用された，本願出願前の平成１３年４月２０日に頒布された，特開２００１−１０９６４０号公報（以下，「引用例２」という。）には，図面とともに，次の事項が記載されている。（なお，下線は当審において付与したものである。）
（ア）「【請求項４】
　
プログラムモジュール間におけるデータ通信の際のデータ通信方法であって，第１のプログラムモジュール及び当該第１のプログラムモジュールから出力されるデータを入力対象とする第２のプログラムモジュールとの間の所定の記憶領域に当該第１のプログラムモジュールと第２のプログラムモジュールとの間の入出力に係る関係を記憶させ，前記第１のプログラムモジュールから出力されたデータを，前記記憶させた入出力に係る関係に従って，前記第２のプログラムモジュールへ出力する
（イ）「【００１７】
【発明の実施の形態】
　以下，本発明に係るデータ通信装置及びデータ通信方法の実施の形態を図面を参照して説明する。
【００１８】
　図１は，本発明に係るデータ通信装置及びデータ通信方法の第１の実施の形態の構成図であり，電話の発信及び着信が可能なコンピュータ内部が示されている。電話機ＧＵＩモジュール１は，コンピュータに接続されたディスプレイ装置の画面上で，仮想的に電話機能を実現するための画像処理モジュールであり，この電話機ＧＵＩモジュール１とのデータ通信はイベント（割込み情報）を介して実行される。
【００１９】
　加入者回路モジュール２は，電話回線を制御するモジュールであり，入力されたコマンド（命令）に対する処理結果としてのメッセージを出力するように構成されている。また，コマンドが入力されなくとも，加入者回路モジュール２自体が行う処理結果に基づいて，適宜メッセージを出力できるようにもなっている。
【００２０】
　
インタフェース情報記憶部３には，各モジュールの入力機能毎に，当該モジュールにとって認識可能なデータの入力形式（入力インタフェース仕様という）が記憶され，一方，各モジュールの出力機能毎に，出力されるデータの形式（出力インタフェース仕様という）が記憶される。
【００２５】
　
尚，インタフェース情報記憶部３には，電話機ＧＵＩモジュール１のインタフェース仕様に対応するものと同様のパラメータ保持領域が，加入者回路モジュール２のメッセージＩＤ及びコマンドＩＤ毎に設けられている。
【００２６】
　
さらに，インタフェース情報記憶部３には，電話機ＧＵＩモジュール１と加入者回路モジュール２との間のデータ通信における入出力の対応関係が記憶される。
【００２７】
　
即ち，インタフェース情報記憶部３に記憶された各ＩＤに，通信相手側のモジュールにおける機能のＩＤを対応させて記憶することによって，データ通信における入出力の対応関係が定義される。
（ウ）「【００３０】
　次に，この実施の形態におけるダイヤル発信の際の処理を説明する。
【００３１】
　利用者によって画面上のカーソルが制御され，電話機のテンキー「５」が押下されると，電話機ＧＵＩモジュール１からは，パーツＩＤ「テンキー」と，押下されたことを示すメソッドＩＤ「押下」と，押下されたテンキーに対応するパラメータ「５」とがイベント（割込み情報）として出力される。
【００３２】
　通信制御部４は，このイベントを検出し，その後，インタフェース情報記憶部３に記憶された入出力の対応関係を参照して，イベントに含まれるパーツＩＤ「テンキー」に対応するコマンドＩＤ「ダイヤル受信」を選択し，そのコマンド「ダイヤル受信」及び電話機ＧＵＩモジュール１から出力されたパラメータ「５」とを加入者回路モジュール２に出力する。
【００３３】
　即ち，パーツＩＤ「テンキー」，メソッドＩＤ「押下」及びパラメータ「５」により構成されたイベント（出力データ）が，加入者回路モジュール２の入力インタフェース仕様に従って変換され，その後，加入者回路モジュール２へ出力される。
【００３４】
　加入者回路モジュール２は，通信制御部４から入力されたコマンドとパラメータとを認識し，これらコマンド及びパラメータに従って電話回線を制御し，番号「５」をダイヤル発信する。
【００３５】
　次に，ダイヤル発信された番号「５」を画面上に表示するための処理を説明する。
【００３６】
　入力されたコマンド「ダイヤル受信」及びパラメータ「５」に従ってダイヤル発信を実行した加入者回路モジュール２は，「ダイヤル５を受信しました」というメッセージとメッセージＩＤ「１００１１」とを出力する。
【００３７】
　通信制御部４は，このメッセージ及びメッセージＩＤを検出し，インタフェース情報記憶部３のメッセージＩＤ「１００１１」に対応づけられたフォーマットに基づいてメッセージ「ダイヤル５を受信しました」を解析し，このメッセージに含まれるパラメータ「５」を抽出する。そして，メッセージＩＤ「１００１１」に対応づけられた電話機ＧＵＩモジュール１のパーツＩＤ「ダイヤル表示」を選択し，パーツＩＤ「ダイヤル表示」，メソッドＩＤ「追加表示」及びメッセージの解析により抽出されたパラメータ「５」を電話機ＧＵＩモジュール１へと出力する。
【００３８】
　即ち，メッセージ「ダイヤル５を受信しました」（出力データ）が，電話機ＧＵＩモジュール１の入力インタフェース仕様に従って変換され，その後，電話機ＧＵＩモジュール１へ出力される。
【００３９】
　電話機ＧＵＩモジュール１は，入力されたパーツＩＤ，メソッドＩＤ及びパラメータに従って画像処理を行うことで，加入者回路モジュール２がダイヤル発信した電話番号を画面上に表示する。
【００４０】
　即ち，この実施の形態では，インタフェース情報記憶部３には，モジュール間の通信におけるデータの入出力に係る関係が記憶され，通信制御部４が，この記憶された関係に基づいて，電話機ＧＵＩモジュール１と加入者回路モジュール２との間のデータ通信を制御する。」
（エ）「【００５１】
　
また，インタフェース情報記憶手段を構成するインタフェース情報記憶部３には，電話機ＧＵＩモジュール１，加入者回路モジュール２或は加入者回路モジュール５から出力されるデータに係る出力形式として，パーツＩＤ，メソッドＩＤ，メッセージＩＤ及びフォーマット等が記憶され，一方，通信に際して各プログラムモジュールへと入力されるデータに係る入力形式として，パーツＩＤ，メソッドＩＤ及びコマンドＩＤ等が記憶され，そして，データ形式変換手段としての通信制御部４により，これら出力形式と入力形式とに基づくデータ変換が行われるため，データの形式に依存しないプログラムモジュール間のデータ通信が実行でき，アプリケーションプログラムの開発段階において，これら形式の変更が発生した場合であっても，変更された形式をインタフェース情報記憶部３に記憶させるだけで，変更前と同様のデータ通信を行うことができる。しかも，入出力に係る関係がデータとして記憶されるため，その修正及び管理は極めて容易である。
（オ）図１には，インターフェース情報記憶部３内に，電話機ＧＵＩモジュール１の出力インタフェースと加入者回線モジュール２の入力インタフェースが，また，加入者回線モジュール２の出力インタフェースと電話機ＧＵＩモジュール１の入力インタフェースが，それぞれテーブルとして入出力の対応関係が定義されている。
（２）上記記載及び図面から，引用例２には，以下の事項（以下，「引用例２記載事項」という）ことが記載されているということができる。
「第１のプログラムモジュールと第２のプログラムモジュールとの間の所定の記憶領域に，当該第１のプログラムモジュールと第２のプログラムモジュールとの間の入出力に係る対応関係を定義するテーブルを記憶させ，前記第１のプログラムモジュールから出力されたデータを，前記記憶させた入出力に係るテーブルに基づき変換して前記第２のプログラムモジュールへ入力し，また，前記第２のプログラムモジュールから出力されたデータを，前記記憶させた入出力に係るテーブルに基づき変換して前記第１のプログラムモジュールへ入力すること。また，これにより出力形式と入力形式とに基づくデータ変換が行われるため，データの形式に依存しないプログラムモジュール間のデータ通信が実行でき，アプリケーションプログラムの開発段階において，これら形式の変更が発生した場合であっても，変更された形式を記憶させるだけで，変更前と同様のデータ通信を行うことができ，しかも，入出力に係る関係がデータとして記憶されるため，その修正及び管理は極めて容易である。」
 　 
４．対比 
（１）本願発明と引用発明とを対比する。
（ア）引用発明では，「アプリケーションプログラム」が実行されて「出力対象のデータを生成し，前記ＡＰインターフェースに従って前記出力対象のデータを結合処理プログラムによる処理に提供する処理」を行い，「結合処理プログラム」が実行されて「前記ＡＰインターフェースに従って前記アプリケーションプログラムによる処理から提供されたデータを，前記ＰＦインターフェースに適合するように変換して，前記プラットフォームプログラムによる処理に仲介する処理」が行われ，「プラットフォームプログラム」が実行されて「前記ＰＦインターフェースに従って出力のためのデータを結合処理プログラムによる処理から取得し，取得したデータに基づくデータを出力してハードウェアデバイスを制御する処理」を行うことから，間接的ではあるものの「アプリケーションプログラム」が生成した出力対象のデータに基づいて「プラットフォームプログラム」がハードウェアデバイスを制御するのであるから，引用発明の上記一連の処理は，本願発明の「一のアプリケーションプログラムを実行し，前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行し」に相当するものである。
（イ）引用発明の「結合処理プログラムは，前記ＰＦインターフェースに従って前記プラットフォームプログラムによる処理から提供されたデータを，前記ＡＰインターフェースに適合するように変換することで前記アプリケーションプログラムによる処理に仲介する処理を行い，また，前記ＡＰインターフェースに従って前記アプリケーションプログラムによる処理から提供されたデータを，前記ＰＦインターフェースに適合するように変換して，前記プラットフォームプログラムによる処理に仲介する処理を行う」について，前記「ＰＦインターフェース」が「異なる車両用制御装置の要求仕様に従って作成されたアプリケーションプログラムによる処理によって共通に利用可能なように標準化したインターフェースである」ことや，また，前記「ＡＰインターフェース」が「開発対象の車両用制御装置の要求仕様を満たすインターフェースである」として定義されたものであるとしても，「結合処理プログラム」が「アプリケーションプログラム」からの出力データを「プラットフォームプログラム」への入力データに適合するように変換し，また，「プラットフォームプログラム」からの出力データを「アプリケーションプログラム」への入力データに適合するように変換する点において，引用発明の上記「結合処理プログラム」による処理は，本願発明の「更に，前記アプリケーションプログラム及びプラットフォームプログラムの間の入出力データを夫々に適合するように変換して入出力処理を行なう中間処理プログラムを実行し」に相当するものである。
（ウ）引用発明の「車両用制御方法」もハードウェアデバイスを制御するものであるから，本願発明の「前記ハードウェア資源の制御を行なう制御方法」に相当するものである。
（オ）上記（イ）で述べたように，引用発明の「結合処理プログラム」は，アプリケーションプログラム」からの出力データを「プラットフォームプログラム」への入力データに適合するように変換し，また，「プラットフォームプログラム」からの出力データを「アプリケーションプログラム」への入力データに適合するように変換するものであることから，本願発明とは「前記中間処理プログラムにより」，「前記アプリケーションプログラムに適合するように入出力データを変換し」，「前記プラットフォームプログラムに適合するように入出力データを変換する」点で共通するものである。
（２）以上のことから，本願発明と引用発明との一致点及び相違点は，次のとおりである。
　（一致点） 
　一のアプリケーションプログラムを実行し，前記アプリケーションプログラムからの要求に対応してハードウェア資源の動作を制御するプラットフォームプログラムを実行し，更に，前記アプリケーションプログラム及びプラットフォームプログラムの間の入出力データを夫々に適合するように変換して入出力処理を行なう中間処理プログラムを実行し，前記ハードウェア資源の制御を行なう制御方法において，
　前記中間処理プログラムにより，
　前記アプリケーションプログラムに適合するように入出力データを変換し，
　前記プラットフォームプログラムに適合するように入出力データを変換する
　ことを特徴とする制御方法。
　　
　（相違点）
　本願発明では，「外部から設定することが可能であって各アプリケーションプログラム及びプラットフォームプログラムに夫々対応付けて入出力データを定義するテーブルを記憶しておき」，「前記中間処理プログラムにより，前記テーブルに基づき，前記アプリケーションプログラムに適合するように入出力データを変換し，前記テーブルに基づき，前記プラットフォームプログラムに適合するように入出力データを変換する」ものであるのに対し，引用発明の「結合処理プログラム」では入出力データの変換にそのような“テーブル”を使用することについては記載がない点。
    　
５．判断 
　確かに引用発明の「結合処理プログラム」においては，入出力データの変換にテーブルを使用することについては記載されていないものの，上記引用例２記載事項によれば「第１のプログラムモジュールと第２のプログラムモジュールとの間の所定の記憶領域に，当該第１のプログラムモジュールと第２のプログラムモジュールとの間の入出力に係る対応関係を定義するテーブルを記憶させ，前記第１のプログラムモジュールから出力されたデータを，前記記憶させた入出力に係るテーブルに基づき変換して前記第２のプログラムモジュールへ入力し，また，前記第２のプログラムモジュールから出力されたデータを，前記記憶させた入出力に係るテーブルに基づき変換して前記第１のプログラムモジュールへ入力すること。」は本願出願前に公知であるし，また，プログラムモジュール間に限らず，変換のための対応関係をテーブルで記述することも一般によく行われていることである。
　また，さらに上記引用例２記載事項によれば「また，これにより出力形式と入力形式とに基づくデータ変換が行われるため，データの形式に依存しないプログラムモジュール間のデータ通信が実行でき，アプリケーションプログラムの開発段階において，これら形式の変更が発生した場合であっても，変更された形式を記憶させるだけで，変更前と同様のデータ通信を行うことができ，しかも，入出力に係る関係がデータとして記憶されるため，その修正及び管理は極めて容易である。」ことから，アプリケーションプログラムのデータの形式の変更が発生しても，変更された形式を記憶させるだけで済み，入出力に係る関係がデータとして記憶されるため，その修正及び管理は極めて容易となることは明らかであり，また，この入出力に係る関係は外部から設定可能であることも自明である。
　そうすると，引用発明の「結合処理プログラム」において，「アプリケーションプログラム」と「プラットフォームプログラム」における入出力データの対応関係の定義の修正及び管理を容易とするために，上記引用例２記載事項に係る技術を適用し，上記入出力データの対応関係を定義したテーブルを記憶して変換に用いることにより，上記相違点に係る構成とすることは，当業者であれば容易に想到しえたことである。
　そして，本願発明の奏する作用効果は，引用発明及び引用例２記載事項から予測される範囲内のものにすぎず，格別顕著なものということはできない。 
 　 
６．むすび 
　以上のとおり，本願発明は，引用発明及び引用例２記載事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により特許を受けることができないから，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。 
　よって，結論のとおり審決する。