ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F |
|---|---|
| 管理番号 | 1255412 |
| 審判番号 | 不服2010-13190 |
| 総通号数 | 150 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2012-06-29 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2010-06-16 |
| 確定日 | 2012-04-12 |
| 事件の表示 | 特願2008-196521「制御装置」拒絶査定不服審判事件〔平成22年 2月12日出願公開,特開2010- 33437〕について,次のとおり審決する。 |
| 結論 | 本件審判の請求は,成り立たない。 |
| 理由 |
1 手続の経緯 本願は平成20年7月30日の出願であって,同年8月18日付けで手続補正がなされ,平成21年8月20日付けの拒絶理由の通知に対し,同年10月29日付けで手続補正がなされたが,平成22年3月4日付けで拒絶査定がされ,これに対し,同年6月16日付けで審判請求がなされるとともに手続補正がなされ,平成23年3月24日付けで審尋がなされ,これに対して同年5月27日付けで回答書が提出され,同年10月19日付けで拒絶理由が通知され,これに対し,同年12月23日付けで意見書が提出されるとともに手続補正がなされたものである。 2 本願発明について (1)本願発明 本願の請求項1,2に係る発明は,平成23年12月23日付け手続補正書の特許請求の範囲の請求項1,2に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,平成23年12月23日付けの手続補正書によって補正された明細書及び図面の記載からみて,その請求項1に記載された事項により特定される,次のとおりのものである。 「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム,及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と,該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置において, 前記プラットフォームプログラムには,ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと,ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラムとを含み, 前記アプリケーションプログラム及びプラットフォームプログラムは夫々,機能の属性を示す属性情報が関連付けられた複数のプログラム部品から構成されており, 前記属性情報には,少なくとも機能の内容を示す情報及び機能の役割を示す情報を含み, 前記制御部は, 同一の属性情報が共通して関連付けられたプログラム部品が静的に選択されて構築されたコンピュータプログラムを実行すると共に, 同一のハードウェア資源に関して,機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ,且つ,機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品が静的に選択されて構築されたリソースマネージャプログラム及びリソースコントローラプログラムを実行すること を特徴とする制御装置。」 (2)当審の拒絶理由の概要 当審において平成23年10月19日付けで通知した拒絶理由の概要は,本願の請求項1,2に係る発明は,本願の出願日前に頒布された,特開2006-142994号公報(引用例1)に記載された発明,及び特開2002-259643号公報(引用例2),特開2005-75314号公報(引用例3),特開2005-18610号公報(引用例4)に記載された周知技術に基づいて当業者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができないというものである。 (3)引用例 ア 引用例1には,図面とともに,次の事項が記載されている。 [技術分野] ・「本発明は,例えば,演算処理装置が実装された複数の電子制御装置(以下ECUともいう)を有し,複数の電子制御装置が通信バスを通じて接続されることで,複数の電子制御装置間でデータの送受信を行うように構成された車両用ネットワークおよびそれに用いられる電子制御装置に関するものである。」(段落【0001】) [課題] ・「本発明は上記点に鑑みて,複雑な大規模システム開発を行う際にも開発期間の短縮化が図れる車両用ネットワークおよびそれに用いられる電子制御装置を提供することを目的とする。」(段落【0012】) ・「また,様々な車種に対応できるようなバリエーション対応を行っても,開発期間の短縮が行える車両用ネットワークおよびそれに用いられる電子制御装置を提供することも目的とする。」(段落【0013】) [実施形態] ・「図1に示されるように,複数の電子制御装置2,例えばエンジンの制御を行うブレーキECU,エンジンECU,車体運動制御ECU,ステアリングECU等が通信バス3を介して接続されることで車両用ネットワーク1が構築されている。そして,各電子制御装置2では,個々の機能を実現するために,各電子制御装置2に記憶された制御プログラムに従って各種演算・制御を実行するようにようになっている。」(段落【0044】) ・「図2に示されるように,各電子制御装置2は,アプリケーション層4,システムインフラ層5およびハードウェア抽象化層6の3つの階層を基本構造としている。」(段落【0045】) ・「ここで,アプリケーション層4とは,機能再利用性,拡張性,独立性を有する機能構成と等価な構造フレームワークを提供すると共に,機能的意味を有するI/Fを提供するものである。システムインフラ層5は,システム開発全体で共有すべきリソースをルールに基づいて一元管理するものである。ハードウェア抽象化層6は,ECU,センサ,アクチュエータの電気特性などに加え,ネットワーク1まで含んだハードウェアシステム全体を抽象化するものである。」(段落【0046】) ・「[(1)アプリケーション層4について] アプリケーション層4は,機能構成フレームワーク4aによって構成されている。この機能構成フレームワーク4aは,制御内容が組み込まれる部分であり,システム構成で定義された機能・サービス構造,I/Fをフレームワークとして提供する部分である。この機能構成フレームワーク4aに制御ロジック7を差し込むだけで,システムを実現することが可能となる。」(段落【0048】) ・「図3に示されるように,車両用ネットワーク1に備えられる機能構成としては,例えば,最上流に車両コーディネータ11があり,この車両コーディネータ11によって車両挙動コンポーネント12やパワートレインコンポーネント13などが管理される。この車両コーディネータ11によって管理される階層が車両ドメイン10である。」(段落【0051】) ・「また,車両挙動の管理は,車両挙動コーディネータ21が車輪速やヨーレート,車両縦方向加速度,車両横方向加速度などの挙動参照値22に基づいて車両安定性を管理することで行われ,パワートレインの管理は,パワートレインコーディネータ31がトランスミッションの出力軸トルクなどの車両推進力参照値32に基づいて,スタータ制御コンポーネント33,クラッチ制御コンポーネント34,トランスミッション制御コンポーネント35,エンジン制御コンポーネント36,ISG(アイドルストップ)制御コンポーネント37を管理することで行われる。・・・」(段落【0052】) ・「[(2)システムインフラ層5について] システムインフラ層5は,システム構造管理部5a,仮想センサ5bおよびシステムコーディネータ5cによって構成されている。」(段落【0059】) ・「システム構造管理部5aは,後述するハードウェア抽象化層6から提供される各電子制御装置2や車両用ネットワーク1等の各ハードウェアの状態量から最適な機能構成を決定するものである。このシステム構造管理部5aは,各電子制御装置2がどの機能を実現するものであるか等のデータを記憶していると共に,各電子制御装置2の動作状態に応じて,処理が可能な状態(実行可能)の機能のみを抽出し,これを機能構成としてシステムコーディネータ5cに通知するようになっている。」(段落【0060】) ・「仮想センサ5bは,各電子制御装置2に入力される実在センサ8の検知信号から求められた物理量やその物理量から求められた実在センサ8では求められない物理量を可観測状態量として,あたかも各可観測状態量を求めることができるセンサが実在するかのように,その可観測状態量のデータを管理するものである。」(段落【0065】) ・「システムコーディネータ5cは,システム構造管理部5aから通知される機能構成に基づいて,機能構成に含まれる各機能(コンポーネント)の能力,状態に応じた制御要求を発行すると共に,機能構成における各機能の実行順序や実行タイミング,つまりスケジューリングを決定するものである(以下,各機能構成の能力,状態に応じた制御要求を機能配分と言い,各機能構成における機能のスケジューリングを実行スケジューリングという)。 」(段落【0077】) ・「また,システムコーディネータ5cでは,機能を単位とした実行スケジューリングを行う。つまり,従来のように,ソフトウェア部品単位だけでなく,機能構成を単位としたスケジューリングを行うことで,システム設計者はシステムの処理フローや応答性を開発の初期段階から把握することが可能となり,大規模システムの設計や検証が容易になる。換言すると,システムコーディネータ5cは,従来無かったシステム設計者の視点でのスケジューリングを実現する。」(段落【0079】) ・「[(3)ハードウェア抽象化層6について] ハードウェア抽象化層6は,電子制御装置2や,センサ8,アクチュエータの電気特性などに加え,車両用ネットワーク1まで含んだハードウェアシステム全体を抽象化することで,複雑なハードウェアネットワークシステムを1つの仮想巨大ECUのように上位層に見せかける仕組みである。そのため,ハードウェア抽象化層6は,上位の階層に対しては,実際の電子制御装置2への配置先に寄らないデータ収受機能といった位置透過な実行環境を実現する機能を提供すると共に,ネットワークシステムのウェイクアップ,スリープ制御などの車両用ネットワーク1の状況管理や各電子制御装置2の動作状態,電源状態管理等の実際のハードウェアの状態管理およびその状態情報の上位階層への通知を行う機能を実現するようになっている。」(段落【0131】) イ 上記記載及び図面から,引用例1には,次の技術的事項が記載されているということができる。 (ア)引用例1に記載された技術は,「車両用ネットワークに用いられる電子制御装置」(ECU)に関するものであり(【0001】),複雑な大規模システム開発や,様々な車種に対応できるようなバリエーション対応を行っても,開発期間が短縮できることを目的としている(【0012】,【0013】)。 (イ)電子制御装置2は,個々の機能を実現するために,電子制御装置2に記憶された制御プログラムに従って各種演算・制御を実行するものであり(【0044】),電子制御装置2は,アプリケーション層4,システムインフラ層5及びハードウェア抽象化層6の3つの階層からなる(【0045】)。 a アプリケーション層4は,制御内容が組み込まれ,システム構成で定義された機能・サービス構造,I/Fをフレームワークとして提供する部分である機能構成フレームワーク4aによって構成され,機能構成フレームワーク4aに制御ロジック7を差し込むことによりシステムを実現することが可能となる(【0046】,【0048】)。 b システムインフラ層5は,システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり(【0046】),システム構造管理部5a,仮想センサ5b及びシステムコーディネータ5cによって構成される(【0059】)。 ここで,システム構造管理部5aは,ハードウェア抽象化層6から提供される各電子制御装置2や車両用ネットワーク1等の各ハードウェアの状態量から最適な機能構成を決定するものであり(【0060】),仮想センサ5bは,各電子制御装置2に入力される実在センサ8の検知信号から求められた物理量やその物理量から求められた実在センサ8では求められない物理量を可観測状態量として管理するものであり(【0065】),システムコーディネータ5cは,システム構造管理部5aから通知される機能構成に基づいて,機能構成に含まれる各機能(コンポーネント)の能力,状態に応じた制御要求を発行するとともに,機能構成を単位として,機能構成における機能のスケジューリングを行うものである(【0077】,【0079】)。 c ハードウェア抽象化層6は,電子制御装置2,センサ8,アクチュエータの電気特性,車両用ネットワーク1等のハードウェアシステム全体を抽象化するものであり,上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに,ハードウェアの状態管理及びその状態情報の上位階層への通知を行う機能を行うものである(【0046】,【0131】)。 ウ 以上のことから,引用例1には,次の発明(以下,「引用発明」という。)が記載されていると認められる。 「個々の機能を実現するために,電子制御装置に記憶された制御プログラムに従って各種演算・制御を実行する車両用ネットワークに用いられる電子制御装置であって, 電子制御装置は,アプリケーション層,システムインフラ層及びハードウェア抽象化層からなり, アプリケーション層は,制御内容が組み込まれ,システム構成で定義された機能・サービス構造,I/Fをフレームワークとして提供する部分である機能構成フレームワークによって構成され,機能構成フレームワークに制御ロジックを差し込むことによりシステムを実現するものであり,ハードウェア抽象化層は,電子制御装置,センサ,アクチュエータの電気特性,車両用ネットワーク等のハードウェアシステム全体を抽象化するものであり,上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに,ハードウェアの状態管理及びその状態情報の上位階層への通知を行い,システムインフラ層は,システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり,ハードウェア抽象化層から提供される各ハードウェアの状態量から最適な機能構成を決定し,機能構成に含まれる各機能(コンポーネント)の能力,状態に応じた制御要求を発行するとともに,機能構成を単位として,機能のスケジューリングを行う 車両用ネットワークに用いられる電子制御装置。」 (4)対比 ア 本願発明と引用発明とを対比する。 (ア)引用発明は,「電子制御装置」(ECU)に係る発明であって,複雑な大規模システム開発や,様々な車種に対応できるようなバリエーション対応を行っても,開発期間が短縮できることを目的としており,他方,本願発明は,コンピュータプログラムに基づき各種制御を行なう制御装置,例えば,車両の電子制御装置に関する発明であって,多様な要求仕様に柔軟に対応した制御を可能とし,かつ各プログラムの再利用性を向上させて開発過程の短縮化,開発負荷の削減を図ることを目的とした発明であるから,両者は,いずれも「制御装置」の技術分野に属する発明であり,その解決課題においても共通する。 (イ)引用発明の「アプリケーション層」は,制御内容が組み込まれ,システム構成で定義された機能・サービス構造,I/Fをフレームワークとして提供する部分である機能構成フレームワークによって構成され,機能構成フレームワークに制御ロジックを差し込むことによりシステムを実現するものであり,当該技術分野における技術常識からみて,本願発明の「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム」に相当する。 引用発明の「ハードウェア抽象化層」は,電子制御装置,センサ,アクチュエータの電気特性,車両用ネットワーク等のハードウェアシステム全体を抽象化するものであって,上位の階層に対して位置透過な実行環境を実現する機能を提供するとともに,ハードウェアの状態管理及びその状態情報の上位階層への通知を行うものであり,また,「システムインフラ層」は,システム開発全体で共有すべきリソースをルールに基づいて一元管理するものであり,ハードウェア抽象化層から提供される各ハードウェアの状態量から最適な機能構成を決定し,機能構成に含まれる各機能(コンポーネント)の能力,状態に応じた制御要求を発行するとともに,機能構成を単位として,機能のスケジューリングを行うことから,技術常識からみて,引用発明の電子制御装置が,本願発明の「一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラム」に相当する構成を備えることは明らかである。 また,引用発明の電子制御装置は,個々の機能を実現するために,電子制御装置に記憶された制御プログラムに従って各種演算・制御を実行するものであるから,本願発明の,アプリケーションプログラム及びプラットフォームプログラムを含む「コンピュータプログラムを記憶する記憶部と,該記憶部から前記コンピュータプログラムを読み出して実行する制御部」を,当然に備えるものである。 したがって,本願発明と引用発明とは,「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム,及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と,該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置」である点で共通する。 (イ)引用発明の電子制御装置は,上記のとおり,アプリケーション層,ハードウェア抽象化層,及びシステムインフラ層によって機能構成を決定し,機能構成を単位として機能のスケジューリングを行うものであり,機能構成は,機能が関連付けられた複数のコンポーネント,すなわち「プログラム部品」によって構成されることから,アプリケーションプログラム及びプラットフォームを含むコンピュータプログラムは,「機能が関連付けられた複数のプログラム部品」によって構成されているということができる。 他方,本願発明は,アプリケーションプログラム及びプラットフォームプログラムが,それぞれ「機能の属性を示す属性情報が関連付けられた複数のプログラム部品から構成」されており,「属性情報」には,「少なくとも機能の内容を示す情報及び機能の役割を示す情報」が含まれ,さらに,プラットフォームプログラムの「リソースマネージャプログラム及びリソースコントローラプログラムは,「同一のハードウェア資源に関して,機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ,かつ,機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されていることが特定されている。これらのことから,「属性情報」は,「機能」に関連する情報であり,本願発明のアプリケーションプログラム,プラットフォームプログラムのリソースマネージャプログラム及びリソースコントローラプログラム,すなわちコンピュータプログラムは,上位概念化すれば,「機能が関連付けられた複数のプログラム部品」によって構成されているということができる。 そうすると,本願発明と引用発明とは,「アプリケーションプログラム及びプラットフォームプログラムはそれぞれ,機能が関連付けられた複数のプログラム部品から構成されている」点で共通する。 (ウ)上記(ア)のとおり,引用発明は,アプリケーションプログラム及びプラットフォームプログラムを含むコンピュータプログラムを実行する「制御部」を備え,また,上記(イ)のとおり,アプリケーションプログラムは,機能が関連付けられた複数のプログラム部品から構成されているから,「制御部は,機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに,プラットフォームプログラムを実行する」ものである。 他方,本願発明の「制御部」は,「コンピュータプログラムを実行するとともに,・・・リソースマネージャプログラム及びリソースコントローラプログラムを実行する」ものであり,「コンピュータプログラム」には,「アプリケーションプログラム及びプラットフォームプログラム」が含まれ,さらに,「プラットフォームプログラム」には,「ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと,ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラムと」が含まれることから,本願発明は,「制御部は,属性情報が関連付けられた複数のプログラム部品から構成されアプリケーションプログラム及びプラットフォームプログラムを実行する」ものである。 そうすると,本願発明と引用発明とは,「制御部は,機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに,プラットフォームプログラムを実行する」点で共通する。 イ 以上のことから,本願発明と引用発明との一致点及び相違点は,次のとおりである。 【一致点】 「一又は複数のアプリケーションの機能を各実現する一又は複数のアプリケーションプログラム,及び前記一又は複数のアプリケーションの機能からの処理要求に対応してハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムを含むコンピュータプログラムを記憶する記憶部と,該記憶部から前記コンピュータプログラムを読み出して実行する制御部とを備える制御装置において, 前記アプリケーションプログラム及びプラットフォームプログラムはそれぞれ,機能が関連付けられた複数のプログラム部品から構成されており, 前記制御部は,機能が関連付けられたプログラム部品により構成されたコンピュータプログラムを実行するとともに, プラットフォームプログラムを実行する 制御装置。」 【相違点1】 本願発明は,プラットフォームプログラムが,「ハードウェア資源に対する論理的なアクセスを実行する機能を実現するリソースマネージャプログラムと,ハードウェア資源に対する物理的アクセスを実行する機能を実現するリソースコントローラプログラム」を含むのに対し,引用発明は,プラットフォームプログラムが上記構成を含むことは特定されていない点。 【相違点2】 本願発明は,アプリケーションプログラム及びプラットフォームプログラムが,「少なくとも機能の内容を示す情報及び機能の役割を示す情報」を含む,「機能の属性を示す属性情報」が関連付けられた複数のプログラム部品によって構成されており,プラットフォームプログラムに含まれるコンピュータプログラムが,「同一のハードウェア資源に関して,機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ,かつ,機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されているのに対し,引用発明は,アプリケーションプログラム及びプラットフォームプログラムが,機能が関連付けられた複数のプログラム部品によって構成されているものの,上記機能の属性を示す属性情報によって関連付けられていることは特定されておらず,また,「プラットフォームプログラム」の構成が特定されていない点。 【相違点3】 本願発明は,コンピュータプログラムが,「同一の属性情報が共通して関連付けられたプログラム部品が静的に選択されて構築」されたものであるのに対し,引用発明は,当該構成について特定されていない点。 (5)判断 ア 相違点1について 制御装置において,プラットフォームプログラムを,ハードウェア資源に対する論理的なアクセスを実行する機能を実現するプログラムと,ハードウェア資源に対する物理的アクセスを実行する機能を実現するプログラムとに分割して構成することは,当該技術分野における周知の技術手段であり,引用発明における,プラットフォームプログラムを含むハードウェア抽象化層において,当該周知の構成を採用し,相違点1に係る構成とすることは,当業者が容易に想到し得たことである。 したがって,相違点1は,格別のものではない。 イ 相違点2について (ア)複数のプログラムによって構成されるコンピュータプログラムにおいて,コンピュータプログラムを構成する個々のプログラム,すなわちプログラム部品を属性情報によって管理することは,当審の拒絶理由で引用した特開2002-259643号公報(引用例2),及び特開2005-75314号公報(引用例3)に以下の記載があるように,周知の技術手段である。 a 引用例2(特開2002-259643号公報) ・「本発明は,ワークフローシステムに接続されたアプリケーションをフローに伴い順次実行する技術,実行する異種アプリケーション間でデータの受け渡しを行う技術,該処理を実行するための定義情報生成を支援する技術に関する。」(段落【0001】) ・「ビジネス形態の変化が加速する中,企業活動を支えるコンピュータシステムの変化への対応速度が問われている。これまで企業内システムを再構築する場合は,多くの修正と新規アプリケーションの導入に伴う労力が必要であった。・・・」(段落【0002】) ・「本発明では,データ形式,プログラム属性およびこれらの対応関係・変換ルールを部品化し,部品化されたものとワークフローで実現するビジネスのプロセスの構成要素を関連付けるものである。」(段落【0006】) ・「より,詳細には,(1)業務プログラム連携情報を業務プログラムの実行方式,受け渡すデータの形式,データ項目の対応関係と変換ルール,の三つに分類し部品として管理する手段と,(2)ビジネスプロセス上の業務ノードと(1)の連携情報部品を関連付ける手段と,(3)ビジネスプロセス定義をビジュアルに行う手段と連動した画面上にてユーザが部品を選択することで(2)の関連付けを行うビジュアルな連携情報定義手段と,(4)(1)の連携情報部品をビジネスプロセスとは独立な部品庫に格納・取り出しすることで,同一のビジネスプロセス内,あるいは,異なる複数のビジネスプロセス間において上記部品を流用することが可能な手段を備えることで,上記課題を解決する。」(段落【0007】) ・「図6に,連携情報部品が保持する属性を示す。まず,連携情報部品一覧テーブル600にて定義されている全ての部品の一覧情報を管理する。連携情報部品一覧テーブル600は,定義した部品の種別601と,該部品のID602と,該部品の詳細属性が格納されるテーブル名603から構成される。・・・」(段落【0033】) ・「アダプタ属性部品属性テーブル610は,一つのアダプタ属性部品の属性を格納するテーブルであり,部品の名称611と,部品のID612と,対応するアダプタプログラムのID613と,対応する業務プログラムへの入力データ形式を示すデータ形式部品のID614と,同じく出力データ形式を示すデータ形式部品のID615から構成される。」(段落【0034】) ・「データ形式部品属性テーブル620は,一つのデータ形式部品の属性を格納するテーブルであり,部品の名称621と,部品のID622と,該データ形式部品に定義されたデータ項目の属性から構成される。・・・」(段落【0035】) ・「マッピング部品属性テーブル630は,一つのマッピング部品の属性を格納するテーブルであり,部品の名称631と,部品のID632と,変換元データの形式を示すデータ形式部品のID633と,変換先データの形式を示すデータ形式部品のID634と,データ項目の対応関係を示すテーブルの名称635から構成される。データ項目マッピングテーブル636は,該マッピング部品属性テーブル630の項目635に対応するテーブルであり,変換元となる項目の名称637と,変換先となる項目の名称638と,変換ルール639から構成される。」(段落【0036】) b 引用例3(特開2005-75314号公報) ・「本発明の車載装置は,インストールしたプログラムに関連付けられている属性情報を管理し,車両の状態とプログラムの属性情報とを比較して,プログラムの動作を制御する。」(段落【0006】) ・「そして車載装置は,車両状態を取得する車両情報取得部と,追加インストールされたプログラムを,条件と処理内容から構成される属性情報と関連付けて管理するとともに,車両情報取得部より取得した車両状態と前記属性情報の動作条件とを比較し,車両状態が動作条件と適合する場合,プログラムの処理を実施し,適合しない場合は,プログラムの動作を停止しあるいはプログラムの出力を非表示にして,プログラムの動作状態を制御するプログラム管理部とを有する。」(段落【0007】) ・「プログラムDB105には,車載装置20で使用する為のプログラム7が,サービスセンタシステム10でそのプログラムに付加されて配信される属性情報8と関連付けられて登録されている。属性情報8は,プログラムの処理条件と車載装置20の車両状態とこの処理条件が適合した時に実施される処理内容とから構成される動作条件9と,他のプログラムとの間の表示優先度を表す優先度1901と,プログラムが動作する車載装置に要求されるメモリ量やCPU性能や画面サイズなどのハードウェア仕様を記述する動作環境1902,から構成される。・・・」(段落【0015】) また,上記摘記事項において,引用例2には,アダプタ属性部品が,部品の名称,部品のID,対応するアダプタプログラムのID,対応する業務プログラムへの入力データ形式を示すデータ形式部品のID,及び出力データ形式を示すデータ形式の属性によって構成され,データ形式部品が,部品の名称,部品のID,該データ形式部品に定義されたデータ項目の属性によって構成され,マッピング部品が,部品の名称,部品のID,変換元データの形式を示すデータ形式部品のID,変換先データの形式を示すデータ形式部品のID,データ項目の対応関係を示すテーブルの名称の属性によって構成されることが,また,引用例3には,属性情報が,プログラムの処理条件と処理内容とから構成される動作条件,他のプログラムとの間の表示優先度,及びハードウェア仕様を記述する動作環境から構成されることが,それぞれ記載されているように,プログラム部品を属性情報を用いて管理するに当たり,属性情報として抽出する情報は,管理の目的に応じて選択できる事項である。 これらのことから,引用発明において,コンピュータプログラムであるアプリケーションプログラム及びプラットフォームプログラムを,機能が関連付けられた複数のプログラム部品により構成するに当たり,上記周知技術に基づいて,プログラム部品を属性情報によって関連付けること,その際,引用発明が機能構成に基づいてコンピュータプログラムを管理していることからすれば,属性情報として,機能の内容や機能の役割を示す情報を選択することは,当業者であれば容易に想到し得たことである。 (イ)そして,アプリケーションプログラム及びプラットフォームプログラムの属性情報として,機能の内容や機能の役割を示す情報を選択すれば,ハードウェア資源の動作を夫々制御する機能を実現するプラットフォームプログラムに含まれるコンピュータプログラムが,「同一のハードウェア資源に関して,機能の内容を示す属性情報として同一の情報又は同一のハードウェア資源を示す情報が関連付けられ,かつ,機能の役割を示す属性情報として前記ハードウェア資源の管理及び制御を示す情報がそれぞれ関連付けられたプログラム部品」によって構成されることとなるのは,自明である。 イ 相違点3について (ア)コンピュータプログラムを構成するに当たり,仕様に応じて,プログラム部品を「静的に」選択して構築することは,周知の技術手段である。 例えば,上記引用例2(段落【0007】参照)には,システムの再構築にあたり,ユーザが画面上で部品を選択し関連付けを行うことが記載されており,これは,仕様に応じて,プログラム部品を「静的に」選択することにほかならない。また,例えば,特開平7-108882号公報には,「本発明は,パワートレイン系を初めとする車両の各種制御を行う車両用電子制御装置であって,特にオプションのセンサやアクチュエータの有無・変更等,仕様変更に伴う設計変更に対応するための車両用電子制御装置に関する。」(段落【0001】),「この構成において,あらかじめ車種や仕向地別に対応して複数のオプションI/O処理装置24bを設けておくことにより,仕様変更が生じた場合はこれら複数の装置の中から仕様に適するものを選択して使用することで,仕様変更に容易に対処できる。」(段落【0029】)との記載があり,制御装置において,複数のI/O処理装置を設けておき,仕様変更に応じてI/O処理装置を選択すること,すなわち,プログラム部品を「静的に」選択することが記載されている。 (イ)引用発明のコンピュータプログラムは,上記(4)のとおり,「機能が関連付けられた複数のプログラム部品」によって構成されたものであり,上記(ア)及び上記ア(ア)のとおり,コンピュータプログラムにおいて,プログラム部品を静的に選択して構築すること,及びプログラム部品を属性情報によって関連付けて管理することが周知の技術手段であることに鑑みれば,引用発明において,コンピュータプログラムを構築するに当たり,同一の属性情報が共通して関連付けられたプログラム部品を静的に選択することは,当業者であれば容易に想到し得ることである。 したがって,相違点3は,格別のことではない。 (ウ)なお,請求人は,平成23年12月23日付けの意見書において,プログラム部品の選択が静的に行われるか,動的に行われるかでプログラムの構成は全く異なる旨主張するが,本願発明には,静的な選択の内容は特定されておらず,また,明細書の記載及び図面(特に,段落【0052】及び図7)を参照しても,静的な選択が,請求人が意見書において主張する特定の技術的事項を意味するものと解釈することはできないから,請求人の主張は採用できない。 ウ そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。 したがって,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。 3 むすび 以上のとおり,本願の請求項1に係る発明は,引用例1に記載された発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法29条2項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。 よって,結論のとおり審決する。 |
| 審理終結日 | 2012-02-07 |
| 結審通知日 | 2012-02-14 |
| 審決日 | 2012-02-27 |
| 出願番号 | 特願2008-196521(P2008-196521) |
| 審決分類 |
P
1
8・
121-
WZ
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 林 毅 |
| 特許庁審判長 |
西山 昇 |
| 特許庁審判官 |
赤川 誠一 清木 泰 |
| 発明の名称 | 制御装置 |
| 代理人 | 河野 登夫 |
| 代理人 | 河野 登夫 |
| 代理人 | 河野 登夫 |