【事件の表示】
　特願２００８−１９６５２１「制御装置」拒絶査定不服審判事件〔平成２２年　２月１２日出願公開，特開２０１０−　３３４３７〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯
　本願は平成２０年７月３０日の出願であって，同年８月１８日付けで手続補正がなされ，平成２１年８月２０日付けの拒絶理由の通知に対し，同年１０月２９日付けで手続補正がなされたが，平成２２年３月４日付けで拒絶査定がされ，これに対し，同年６月１６日付けで審判請求がなされるとともに手続補正がなされ，平成２３年３月２４日付けで審尋がなされ，これに対して同年５月２７日付けで回答書が提出され，同年１０月１９日付けで拒絶理由が通知され，これに対し，同年１２月２３日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２　本願発明について
（１）本願発明
　本願の請求項１，２に係る発明は，平成２３年１２月２３日付け手続補正書の特許請求の範囲の請求項１，２に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，平成２３年１２月２３日付けの手続補正書によって補正された明細書及び図面の記載からみて，その請求項１に記載された事項により特定される，次のとおりのものである。
「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム，及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と，該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置において，
　前記プラットフォームプログラムには，ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと，ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラムとを含み，
　前記アプリケーションプログラム及びプラットフォームプログラムは夫々，機能の属性を示す属性情報が関連付けられた複数のプログラム部品から構成されており，
　前記属性情報には，少なくとも機能の内容を示す情報及び機能の役割を示す情報を含み，
　前記制御部は，
　同一の属性情報が共通して関連付けられたプログラム部品が静的に選択されて構築されたコンピュータプログラムを実行すると共に，
　同一のハードウェア資源に関して，機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ，且つ，機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品が静的に選択されて構築されたリソースマネージャプログラム及びリソースコントローラプログラムを実行すること
　を特徴とする制御装置。」
　
（２）当審の拒絶理由の概要
　当審において平成２３年１０月１９日付けで通知した拒絶理由の概要は，本願の請求項１，２に係る発明は，本願の出願日前に頒布された，特開２００６−１４２９９４号公報（引用例１）に記載された発明，及び特開２００２−２５９６４３号公報（引用例２），特開２００５−７５３１４号公報（引用例３），特開２００５−１８６１０号公報（引用例４）に記載された周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができないというものである。
　
（３）引用例
ア　引用例１には，図面とともに，次の事項が記載されている。
　
［技術分野］
・「本発明は，例えば，演算処理装置が実装された複数の電子制御装置（以下ＥＣＵともいう）を有し，複数の電子制御装置が通信バスを通じて接続されることで，複数の電子制御装置間でデータの送受信を行うように構成された車両用ネットワークおよびそれに用いられる電子制御装置に関するものである。」（段落【０００１】）
［課題］
・「本発明は上記点に鑑みて，複雑な大規模システム開発を行う際にも開発期間の短縮化が図れる車両用ネットワークおよびそれに用いられる電子制御装置を提供することを目的とする。」（段落【００１２】）
・「また，様々な車種に対応できるようなバリエーション対応を行っても，開発期間の短縮が行える車両用ネットワークおよびそれに用いられる電子制御装置を提供することも目的とする。」（段落【００１３】）
［実施形態］
・「図１に示されるように，複数の電子制御装置２，例えばエンジンの制御を行うブレーキＥＣＵ，エンジンＥＣＵ，車体運動制御ＥＣＵ，ステアリングＥＣＵ等が通信バス３を介して接続されることで車両用ネットワーク１が構築されている。そして，各電子制御装置２では，個々の機能を実現するために，各電子制御装置２に記憶された制御プログラムに従って各種演算・制御を実行するようにようになっている。」（段落【００４４】）
・「図２に示されるように，各電子制御装置２は，アプリケーション層４，システムインフラ層５およびハードウェア抽象化層６の３つの階層を基本構造としている。」（段落【００４５】）
・「ここで，アプリケーション層４とは，機能再利用性，拡張性，独立性を有する機能構成と等価な構造フレームワークを提供すると共に，機能的意味を有するＩ／Ｆを提供するものである。システムインフラ層５は，システム開発全体で共有すべきリソースをルールに基づいて一元管理するものである。ハードウェア抽象化層６は，ＥＣＵ，センサ，アクチュエータの電気特性などに加え，ネットワーク１まで含んだハードウェアシステム全体を抽象化するものである。」（段落【００４６】）
・「［（１）アプリケーション層４について］
　アプリケーション層４は，機能構成フレームワーク４ａによって構成されている。この機能構成フレームワーク４ａは，制御内容が組み込まれる部分であり，システム構成で定義された機能・サービス構造，Ｉ／Ｆをフレームワークとして提供する部分である。この機能構成フレームワーク４ａに制御ロジック７を差し込むだけで，システムを実現することが可能となる。」（段落【００４８】）
・「図３に示されるように，車両用ネットワーク１に備えられる機能構成としては，例えば，最上流に車両コーディネータ１１があり，この車両コーディネータ１１によって車両挙動コンポーネント１２やパワートレインコンポーネント１３などが管理される。この車両コーディネータ１１によって管理される階層が車両ドメイン１０である。」（段落【００５１】）
・「また，車両挙動の管理は，車両挙動コーディネータ２１が車輪速やヨーレート，車両縦方向加速度，車両横方向加速度などの挙動参照値２２に基づいて車両安定性を管理することで行われ，パワートレインの管理は，パワートレインコーディネータ３１がトランスミッションの出力軸トルクなどの車両推進力参照値３２に基づいて，スタータ制御コンポーネント３３，クラッチ制御コンポーネント３４，トランスミッション制御コンポーネント３５，エンジン制御コンポーネント３６，ＩＳＧ（アイドルストップ）制御コンポーネント３７を管理することで行われる。・・・」（段落【００５２】）
・「［（２）システムインフラ層５について］
　システムインフラ層５は，システム構造管理部５ａ，仮想センサ５ｂおよびシステムコーディネータ５ｃによって構成されている。」（段落【００５９】）
・「システム構造管理部５ａは，後述するハードウェア抽象化層６から提供される各電子制御装置２や車両用ネットワーク１等の各ハードウェアの状態量から最適な機能構成を決定するものである。このシステム構造管理部５ａは，各電子制御装置２がどの機能を実現するものであるか等のデータを記憶していると共に，各電子制御装置２の動作状態に応じて，処理が可能な状態（実行可能）の機能のみを抽出し，これを機能構成としてシステムコーディネータ５ｃに通知するようになっている。」（段落【００６０】）
・「仮想センサ５ｂは，各電子制御装置２に入力される実在センサ８の検知信号から求められた物理量やその物理量から求められた実在センサ８では求められない物理量を可観測状態量として，あたかも各可観測状態量を求めることができるセンサが実在するかのように，その可観測状態量のデータを管理するものである。」（段落【００６５】）
・「システムコーディネータ５ｃは，システム構造管理部５ａから通知される機能構成に基づいて，機能構成に含まれる各機能（コンポーネント）の能力，状態に応じた制御要求を発行すると共に，機能構成における各機能の実行順序や実行タイミング，つまりスケジューリングを決定するものである（以下，各機能構成の能力，状態に応じた制御要求を機能配分と言い，各機能構成における機能のスケジューリングを実行スケジューリングという）。 」（段落【００７７】）
・「また，システムコーディネータ５ｃでは，機能を単位とした実行スケジューリングを行う。つまり，従来のように，ソフトウェア部品単位だけでなく，機能構成を単位としたスケジューリングを行うことで，システム設計者はシステムの処理フローや応答性を開発の初期段階から把握することが可能となり，大規模システムの設計や検証が容易になる。換言すると，システムコーディネータ５ｃは，従来無かったシステム設計者の視点でのスケジューリングを実現する。」（段落【００７９】）
・「［（３）ハードウェア抽象化層６について］
　ハードウェア抽象化層６は，電子制御装置２や，センサ８，アクチュエータの電気特性などに加え，車両用ネットワーク１まで含んだハードウェアシステム全体を抽象化することで，複雑なハードウェアネットワークシステムを１つの仮想巨大ＥＣＵのように上位層に見せかける仕組みである。そのため，ハードウェア抽象化層６は，上位の階層に対しては，実際の電子制御装置２への配置先に寄らないデータ収受機能といった位置透過な実行環境を実現する機能を提供すると共に，ネットワークシステムのウェイクアップ，スリープ制御などの車両用ネットワーク１の状況管理や各電子制御装置２の動作状態，電源状態管理等の実際のハードウェアの状態管理およびその状態情報の上位階層への通知を行う機能を実現するようになっている。」（段落【０１３１】）
　
イ　上記記載及び図面から，引用例１には，次の技術的事項が記載されているということができる。
（ア）引用例１に記載された技術は，「車両用ネットワークに用いられる電子制御装置」（ＥＣＵ）に関するものであり（【０００１】），複雑な大規模システム開発や，様々な車種に対応できるようなバリエーション対応を行っても，開発期間が短縮できることを目的としている（【００１２】，【００１３】）。
（イ）電子制御装置２は，個々の機能を実現するために，電子制御装置２に記憶された制御プログラムに従って各種演算・制御を実行するものであり（【００４４】），電子制御装置２は，アプリケーション層４，システムインフラ層５及びハードウェア抽象化層６の３つの階層からなる（【００４５】）。
ａ　アプリケーション層４は，制御内容が組み込まれ，システム構成で定義された機能・サービス構造，Ｉ／Ｆをフレームワークとして提供する部分である機能構成フレームワーク４ａによって構成され，機能構成フレームワーク４ａに制御ロジック７を差し込むことによりシステムを実現することが可能となる（【００４６】，【００４８】）。
ｂ　システムインフラ層５は，システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり（【００４６】），システム構造管理部５ａ，仮想センサ５ｂ及びシステムコーディネータ５ｃによって構成される（【００５９】）。
　ここで，システム構造管理部５ａは，ハードウェア抽象化層６から提供される各電子制御装置２や車両用ネットワーク１等の各ハードウェアの状態量から最適な機能構成を決定するものであり（【００６０】），仮想センサ５ｂは，各電子制御装置２に入力される実在センサ８の検知信号から求められた物理量やその物理量から求められた実在センサ８では求められない物理量を可観測状態量として管理するものであり（【００６５】），システムコーディネータ５ｃは，システム構造管理部５ａから通知される機能構成に基づいて，機能構成に含まれる各機能（コンポーネント）の能力，状態に応じた制御要求を発行するとともに，機能構成を単位として，機能構成における機能のスケジューリングを行うものである（【００７７】，【００７９】）。
ｃ　ハードウェア抽象化層６は，電子制御装置２，センサ８，アクチュエータの電気特性，車両用ネットワーク１等のハードウェアシステム全体を抽象化するものであり，上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに，ハードウェアの状態管理及びその状態情報の上位階層への通知を行う機能を行うものである（【００４６】，【０１３１】）。
　
ウ　以上のことから，引用例１には，次の発明（以下，「引用発明」という。）が記載されていると認められる。
「個々の機能を実現するために，電子制御装置に記憶された制御プログラムに従って各種演算・制御を実行する車両用ネットワークに用いられる電子制御装置であって，
　電子制御装置は，アプリケーション層，システムインフラ層及びハードウェア抽象化層からなり，
　アプリケーション層は，制御内容が組み込まれ，システム構成で定義された機能・サービス構造，Ｉ／Ｆをフレームワークとして提供する部分である機能構成フレームワークによって構成され，機能構成フレームワークに制御ロジックを差し込むことによりシステムを実現するものであり，ハードウェア抽象化層は，電子制御装置，センサ，アクチュエータの電気特性，車両用ネットワーク等のハードウェアシステム全体を抽象化するものであり，上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに，ハードウェアの状態管理及びその状態情報の上位階層への通知を行い，システムインフラ層は，システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり，ハードウェア抽象化層から提供される各ハードウェアの状態量から最適な機能構成を決定し，機能構成に含まれる各機能（コンポーネント）の能力，状態に応じた制御要求を発行するとともに，機能構成を単位として，機能のスケジューリングを行う
　車両用ネットワークに用いられる電子制御装置。」
　
（４）対比
ア　本願発明と引用発明とを対比する。
（ア）引用発明は，「電子制御装置」（ＥＣＵ）に係る発明であって，複雑な大規模システム開発や，様々な車種に対応できるようなバリエーション対応を行っても，開発期間が短縮できることを目的としており，他方，本願発明は，コンピュータプログラムに基づき各種制御を行なう制御装置，例えば，車両の電子制御装置に関する発明であって，多様な要求仕様に柔軟に対応した制御を可能とし，かつ各プログラムの再利用性を向上させて開発過程の短縮化，開発負荷の削減を図ることを目的とした発明であるから，両者は，いずれも「制御装置」の技術分野に属する発明であり，その解決課題においても共通する。
（イ）引用発明の「アプリケーション層」は，制御内容が組み込まれ，システム構成で定義された機能・サービス構造，Ｉ／Ｆをフレームワークとして提供する部分である機能構成フレームワークによって構成され，機能構成フレームワークに制御ロジックを差し込むことによりシステムを実現するものであり，当該技術分野における技術常識からみて，本願発明の「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム」に相当する。
　引用発明の「ハードウェア抽象化層」は，電子制御装置，センサ，アクチュエータの電気特性，車両用ネットワーク等のハードウェアシステム全体を抽象化するものであって，上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに，ハードウェアの状態管理及びその状態情報の上位階層への通知を行うものであり，また，「システムインフラ層」は，システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり，ハードウェア抽象化層から提供される各ハードウェアの状態量から最適な機能構成を決定し，機能構成に含まれる各機能（コンポーネント）の能力，状態に応じた制御要求を発行するとともに，機能構成を単位として，機能のスケジューリングを行うことから，技術常識からみて，引用発明の電子制御装置が，本願発明の「一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラム」に相当する構成を備えることは明らかである。
　また，引用発明の電子制御装置は，個々の機能を実現するために，電子制御装置に記憶された制御プログラムに従って各種演算・制御を実行するものであるから，本願発明の，アプリケーションプログラム及びプラットフォームプログラムを含む「コンピュータプログラムを記憶する記憶部と，該記憶部から前記コンピュータプログラムを読み出して実行する制御部」を，当然に備えるものである。
　したがって，本願発明と引用発明とは，「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム，及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と，該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置」である点で共通する。
（イ）引用発明の電子制御装置は，上記のとおり，アプリケーション層，ハードウェア抽象化層，及びシステムインフラ層によって機能構成を決定し，機能構成を単位として機能のスケジューリングを行うものであり，機能構成は，機能が関連付けられた複数のコンポーネント，すなわち「プログラム部品」によって構成されることから，アプリケーションプログラム及びプラットフォームを含むコンピュータプログラムは，「機能が関連付けられた複数のプログラム部品」によって構成されているということができる。
　他方，本願発明は，アプリケーションプログラム及びプラットフォームプログラムが，それぞれ「機能の属性を示す属性情報が関連付けられた複数のプログラム部品から構成」されており，「属性情報」には，「少なくとも機能の内容を示す情報及び機能の役割を示す情報」が含まれ，さらに，プラットフォームプログラムの「リソースマネージャプログラム及びリソースコントローラプログラムは，「同一のハードウェア資源に関して，機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ，かつ，機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されていることが特定されている。これらのことから，「属性情報」は，「機能」に関連する情報であり，本願発明のアプリケーションプログラム，プラットフォームプログラムのリソースマネージャプログラム及びリソースコントローラプログラム，すなわちコンピュータプログラムは，上位概念化すれば，「機能が関連付けられた複数のプログラム部品」によって構成されているということができる。
　そうすると，本願発明と引用発明とは，「アプリケーションプログラム及びプラットフォームプログラムはそれぞれ，機能が関連付けられた複数のプログラム部品から構成されている」点で共通する。
（ウ）上記（ア）のとおり，引用発明は，アプリケーションプログラム及びプラットフォームプログラムを含むコンピュータプログラムを実行する「制御部」を備え，また，上記（イ）のとおり，アプリケーションプログラムは，機能が関連付けられた複数のプログラム部品から構成されているから，「制御部は，機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに，プラットフォームプログラムを実行する」ものである。
　他方，本願発明の「制御部」は，「コンピュータプログラムを実行するとともに，・・・リソースマネージャプログラム及びリソースコントローラプログラムを実行する」ものであり，「コンピュータプログラム」には，「アプリケーションプログラム及びプラットフォームプログラム」が含まれ，さらに，「プラットフォームプログラム」には，「ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと，ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラムと」が含まれることから，本願発明は，「制御部は，属性情報が関連付けられた複数のプログラム部品から構成されアプリケーションプログラム及びプラットフォームプログラムを実行する」ものである。
　そうすると，本願発明と引用発明とは，「制御部は，機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに，プラットフォームプログラムを実行する」点で共通する。
　
イ　以上のことから，本願発明と引用発明との一致点及び相違点は，次のとおりである。
【一致点】
　「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム，及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と，該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置において，
　前記アプリケーションプログラム及びプラットフォームプログラムはそれぞれ，機能が関連付けられた複数のプログラム部品から構成されており，
　前記制御部は，機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに，
　プラットフォームプログラムを実行する
　制御装置。」
【相違点１】
　本願発明は，プラットフォームプログラムが，「ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと，ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラム」を含むのに対し，引用発明は，プラットフォームプログラムが上記構成を含むことは特定されていない点。
【相違点２】
　本願発明は，アプリケーションプログラム及びプラットフォームプログラムが，「少なくとも機能の内容を示す情報及び機能の役割を示す情報」を含む，「機能の属性を示す属性情報」が関連付けられた複数のプログラム部品によって構成されており，プラットフォームプログラムに含まれるコンピュータプログラムが，「同一のハードウェア資源に関して，機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ，かつ，機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されているのに対し，引用発明は，アプリケーションプログラム及びプラットフォームプログラムが，機能が関連付けられた複数のプログラム部品によって構成されているものの，上記機能の属性を示す属性情報によって関連付けられていることは特定されておらず，また，「プラットフォームプログラム」の構成が特定されていない点。
【相違点３】
　本願発明は，コンピュータプログラムが，「同一の属性情報が共通して関連付けられたプログラム部品が静的に選択されて構築」されたものであるのに対し，引用発明は，当該構成について特定されていない点。
　
（５）判断
ア　相違点１について
　制御装置において，プラットフォームプログラムを，ハードウェア資源に対する論理的なアクセスを実行する機能を実現するプログラムと，ハードウェア資源に対する物理的アクセスを実行する機能を実現するプログラムとに分割して構成することは，当該技術分野における周知の技術手段であり，引用発明における，プラットフォームプログラムを含むハードウェア抽象化層において，当該周知の構成を採用し，相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　したがって，相違点１は，格別のものではない。
　
イ　相違点２について
（ア）複数のプログラムによって構成されるコンピュータプログラムにおいて，コンピュータプログラムを構成する個々のプログラム，すなわちプログラム部品を属性情報によって管理することは，当審の拒絶理由で引用した特開２００２−２５９６４３号公報（引用例２），及び特開２００５−７５３１４号公報（引用例３）に以下の記載があるように，周知の技術手段である。
　
ａ　引用例２（特開２００２−２５９６４３号公報）
・「本発明は，ワークフローシステムに接続されたアプリケーションをフローに伴い順次実行する技術，実行する異種アプリケーション間でデータの受け渡しを行う技術，該処理を実行するための定義情報生成を支援する技術に関する。」（段落【０００１】）
・「ビジネス形態の変化が加速する中，企業活動を支えるコンピュータシステムの変化への対応速度が問われている。これまで企業内システムを再構築する場合は，多くの修正と新規アプリケーションの導入に伴う労力が必要であった。・・・」（段落【０００２】）
・「本発明では，データ形式，プログラム属性およびこれらの対応関係・変換ルールを部品化し，部品化されたものとワークフローで実現するビジネスのプロセスの構成要素を関連付けるものである。」（段落【０００６】）
・「より，詳細には，（１）業務プログラム連携情報を業務プログラムの実行方式，受け渡すデータの形式，データ項目の対応関係と変換ルール，の三つに分類し部品として管理する手段と，（２）ビジネスプロセス上の業務ノードと（１）の連携情報部品を関連付ける手段と，（３）ビジネスプロセス定義をビジュアルに行う手段と連動した画面上にてユーザが部品を
選択
・「図６に，連携情報部品が保持する属性を示す。まず，連携情報部品一覧テーブル６００にて定義されている全ての部品の一覧情報を管理する。連携情報部品一覧テーブル６００は，定義した部品の種別６０１と，該部品のＩＤ６０２と，該部品の詳細属性が格納されるテーブル名６０３から構成される。・・・」（段落【００３３】）
・「アダプタ属性部品属性テーブル６１０は，一つのアダプタ属性部品の属性を格納するテーブルであり，部品の名称６１１と，部品のＩＤ６１２と，対応するアダプタプログラムのＩＤ６１３と，対応する業務プログラムへの入力データ形式を示すデータ形式部品のＩＤ６１４と，同じく出力データ形式を示すデータ形式部品のＩＤ６１５から構成される。」（段落【００３４】）
・「データ形式部品属性テーブル６２０は，一つのデータ形式部品の属性を格納するテーブルであり，部品の名称６２１と，部品のＩＤ６２２と，該データ形式部品に定義されたデータ項目の属性から構成される。・・・」（段落【００３５】）
・「マッピング部品属性テーブル６３０は，一つのマッピング部品の属性を格納するテーブルであり，部品の名称６３１と，部品のＩＤ６３２と，変換元データの形式を示すデータ形式部品のＩＤ６３３と，変換先データの形式を示すデータ形式部品のＩＤ６３４と，データ項目の対応関係を示すテーブルの名称６３５から構成される。データ項目マッピングテーブル６３６は，該マッピング部品属性テーブル６３０の項目６３５に対応するテーブルであり，変換元となる項目の名称６３７と，変換先となる項目の名称６３８と，変換ルール６３９から構成される。」（段落【００３６】）
ｂ　引用例３（特開２００５−７５３１４号公報）
・「本発明の車載装置は，インストールしたプログラムに関連付けられている属性情報を管理し，車両の状態とプログラムの属性情報とを比較して，プログラムの動作を制御する。」（段落【０００６】）
・「そして車載装置は，車両状態を取得する車両情報取得部と，追加インストールされたプログラムを，条件と処理内容から構成される属性情報と関連付けて管理するとともに，車両情報取得部より取得した車両状態と前記属性情報の動作条件とを比較し，車両状態が動作条件と適合する場合，プログラムの処理を実施し，適合しない場合は，プログラムの動作を停止しあるいはプログラムの出力を非表示にして，プログラムの動作状態を制御するプログラム管理部とを有する。」（段落【０００７】）
・「プログラムＤＢ１０５には，車載装置２０で使用する為のプログラム７が，サービスセンタシステム１０でそのプログラムに付加されて配信される属性情報８と関連付けられて登録されている。属性情報８は，プログラムの処理条件と車載装置２０の車両状態とこの処理条件が適合した時に実施される処理内容とから構成される動作条件９と，他のプログラムとの間の表示優先度を表す優先度１９０１と，プログラムが動作する車載装置に要求されるメモリ量やＣＰＵ性能や画面サイズなどのハードウェア仕様を記述する動作環境１９０２，から構成される。・・・」（段落【００１５】）
　
　また，上記摘記事項において，引用例２には，アダプタ属性部品が，部品の名称，部品のＩＤ，対応するアダプタプログラムのＩＤ，対応する業務プログラムへの入力データ形式を示すデータ形式部品のＩＤ，及び出力データ形式を示すデータ形式の属性によって構成され，データ形式部品が，部品の名称，部品のＩＤ，該データ形式部品に定義されたデータ項目の属性によって構成され，マッピング部品が，部品の名称，部品のＩＤ，変換元データの形式を示すデータ形式部品のＩＤ，変換先データの形式を示すデータ形式部品のＩＤ，データ項目の対応関係を示すテーブルの名称の属性によって構成されることが，また，引用例３には，属性情報が，プログラムの処理条件と処理内容とから構成される動作条件，他のプログラムとの間の表示優先度，及びハードウェア仕様を記述する動作環境から構成されることが，それぞれ記載されているように，プログラム部品を属性情報を用いて管理するに当たり，属性情報として抽出する情報は，管理の目的に応じて選択できる事項である。
　これらのことから，引用発明において，コンピュータプログラムであるアプリケーションプログラム及びプラットフォームプログラムを，機能が関連付けられた複数のプログラム部品により構成するに当たり，上記周知技術に基づいて，プログラム部品を属性情報によって関連付けること，その際，引用発明が機能構成に基づいてコンピュータプログラムを管理していることからすれば，属性情報として，機能の内容や機能の役割を示す情報を選択することは，当業者であれば容易に想到し得たことである。
　
（イ）そして，アプリケーションプログラム及びプラットフォームプログラムの属性情報として，機能の内容や機能の役割を示す情報を選択すれば，ハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムに含まれるコンピュータプログラムが，「同一のハードウェア資源に関して，機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ，かつ，機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されることとなるのは，自明である。
　
イ　相違点３について
（ア）コンピュータプログラムを構成するに当たり，仕様に応じて，プログラム部品を「静的に」選択して構築することは，周知の技術手段である。
　例えば，上記引用例２（段落【０００７】参照）には，システムの再構築にあたり，ユーザが画面上で部品を選択し関連付けを行うことが記載されており，これは，仕様に応じて，プログラム部品を「静的に」選択することにほかならない。また，例えば，特開平７−１０８８８２号公報には，「本発明は，パワートレイン系を初めとする車両の各種制御を行う車両用電子制御装置であって，特にオプションのセンサやアクチュエータの有無・変更等，仕様変更に伴う設計変更に対応するための車両用電子制御装置に関する。」（段落【０００１】），「この構成において，あらかじめ車種や仕向地別に対応して複数のオプションＩ／Ｏ処理装置２４ｂを設けておくことにより，仕様変更が生じた場合はこれら複数の装置の中から仕様に適するものを選択して使用することで，仕様変更に容易に対処できる。」（段落【００２９】）との記載があり，制御装置において，複数のＩ／Ｏ処理装置を設けておき，仕様変更に応じてＩ／Ｏ処理装置を選択すること，すなわち，プログラム部品を「静的に」選択することが記載されている。
　
（イ）引用発明のコンピュータプログラムは，上記（４）のとおり，「機能が関連付けられた複数のプログラム部品」によって構成されたものであり，上記（ア）及び上記ア（ア）のとおり，コンピュータプログラムにおいて，プログラム部品を静的に選択して構築すること，及びプログラム部品を属性情報によって関連付けて管理することが周知の技術手段であることに鑑みれば，引用発明において，コンピュータプログラムを構築するに当たり，同一の属性情報が共通して関連付けられたプログラム部品を静的に選択することは，当業者であれば容易に想到し得ることである。
　したがって，相違点３は，格別のことではない。
　
（ウ）なお，請求人は，平成２３年１２月２３日付けの意見書において，プログラム部品の選択が静的に行われるか，動的に行われるかでプログラムの構成は全く異なる旨主張するが，本願発明には，静的な選択の内容は特定されておらず，また，明細書の記載及び図面（特に，段落【００５２】及び図７）を参照しても，静的な選択が，請求人が意見書において主張する特定の技術的事項を意味するものと解釈することはできないから，請求人の主張は採用できない。
　
ウ　そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
３　むすび
　以上のとおり，本願の請求項１に係る発明は，引用例１に記載された発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により特許を受けることができないから，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　よって，結論のとおり審決する。