2023-003830

特願２０２１－１１６２１４「更新システム、車両システム、及び更新管理装置」拒絶査定不服審判事件〔令和３年１０月２８日出願公開、特開２０２１－１６９３０８〕について、次のとおり審決する。

結 論 本件審判の請求は、成り立たない。

理 由 第１ 手続の経緯 本願は、平成２９年１１月６日に出願した特願２０１７－２１４２４１号（以下「原出願」という。）の一部を令和３年７月１４日に新たな特許出願としたものであって、同日に上申書が提出され、令和４年６月１７日付け（発送日：同年６月２１日）で拒絶理由が通知され、同年８月５日に意見書が提出されるとともに手続補正がされたが、同年１１月２９日付け（発送日：同年１２月６日）で拒絶査定（以下「原査定」という。）がされ、これに対して、令和５年３月６日に本件拒絶査定不服審判の請求がされると同時に手続補正がされた。 第２ 令和５年３月６日付けの手続補正についての補正の却下の決定 ［補正の却下の決定の結論］ 令和５年３月６日付けの手続補正（以下「本件補正」という。）を却下する。 ［理由］ １ 本件補正について（補正の内容） （１）本件補正後の特許請求の範囲の請求項１の記載 本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された（（２）における下線部分を削除したものである。）。 「【請求項１】 所定の制御を実現するためのプログラムの更新を管理する更新管理装置と、前記プログラムを実行する複数の電子制御装置を含む更新システムであって、 前記複数の電子制御装置のうち、１つ以上の電子制御装置は、 １つ以上の更新前のプログラムと、前記更新管理装置が取得した更新データに基づく１つ以上の更新後のプログラムとを記憶する記憶部と、 自装置が実行する１つ以上の対象プログラムを、前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替える第１の切替処理と、前記更新管理装置から第２の切替処理の実行が要求された場合に、自装置が実行する前記１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理とを実行する切替部と、を備え、 前記更新管理装置は、 前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、前記１つ以上の電子制御装置のうち、前記１つ以上の対象プログラムを前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替えた電子制御装置に、前記第２の切替処理の実行を要求する要求部を備える、 更新システム。」 （２）本件補正前の特許請求の範囲の請求項１の記載 本件補正前の特許請求の範囲の請求項１の記載は次のとおりである。 「【請求項１】 所定の制御を実現するためのプログラムの更新を管理する更新管理装置と、前記プログラムを実行する複数の電子制御装置を含む更新システムであって、 前記複数の電子制御装置のうち、１つ以上の電子制御装置は、 １つ以上の更新前のプログラムと、前記更新管理装置が取得した更新データに基づく１つ以上の更新後のプログラムとを記憶する記憶部と、 自装置が実行する１つ以上の対象プログラムを、前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替える第１の切替処理と、前記更新管理装置から第２の切替処理の実行が要求された場合に、自装置が実行する前記１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理とを実行する切替部と、を備え、 前記更新管理装置は、 前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記記憶部が、１つ以上の更新後のプログラムの少なくとも一部の記憶に失敗した場合、または、前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、前記１つ以上の電子制御装置のうち、前記１つ以上の対象プログラムを前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替えた電子制御装置に、前記第２の切替処理の実行を要求する要求部を備える、 更新システム。」 ２ 補正の適否 本件補正は、本件補正前の請求項１に記載された発明を特定するために必要な事項である「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記記憶部が、１つ以上の更新後のプログラムの少なくとも一部の記憶に失敗した場合、または、前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、」との記載事項を、「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、」との記載事項に限定したものであって、本件補正前の請求項１に記載された発明と本件補正後の請求項１に記載された発明とは、産業上の利用分野及び解決しようとする課題が異なるものではないから、特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件補正後の請求項１に記載された発明（以下「本件補正発明」という。）が、特許出願の際独立して特許を受けることができるものであるか否か（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか否か）について以下に検討する。 （１）本件補正発明 本件補正発明は、上記１（１）に記載したとおりのものである。 （２）引用文献の記載事項、引用発明 ア 引用文献１ 原査定の拒絶の理由で引用された、本願の原出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である特開２０１７－１５７００４号公報（平成２９年９月７日出願公開、以下「引用文献１」という。）には、図面とともに次の記載がある（下線は当審で付した。以下同様。）。 （ア）「【請求項１】 車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続されたゲートウェイと、を含むプログラム更新システムであって、 前記ゲートウェイは、 複数の前記制御装置に対する更新プログラムを記憶する記憶部と、 記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、 同時更新の必要性があるすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備えるプログラム更新システム。 【請求項２】 複数の前記制御装置は、前記制御プログラムの動作領域が複数存在する記憶装置を有する複数領域タイプであり、 前記更新継続処理は、いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理、或いは、すべての前記制御装置を更新前の旧バージョンに戻すロールバック処理である請求項１に記載のプログラム更新システム。」 （イ）「【技術分野】 【０００１】 本発明は、プログラム更新システム、プログラム更新方法及びコンピュータプログラムに関する。具体的には、本発明は、複数の制御装置に対する制御プログラムの同時更新を適切に行うための技術に関する。」 （ウ）「【発明が解決しようとする課題】 【０００６】 管理サーバから受信した更新プログラムを用いて、ＥＣＵが制御プログラムを更新する最中に、電源失陥やファイル欠損などの何らかの障害が発生することがある。この場合、ＥＣＵが旧バーションへの復元が可能ならば、障害がなくなった後に新バーションの制御プログラムの書き込みを最初からやり直すようにすればよい。しかし、車両に搭載された複数のＥＣＵの制御プログラムを同時に更新する場合には、１つＥＣＵの書き込み中に障害が生じた時に、他のＥＣＵが既に新バーションへの更新を完了している場合がある。 【０００７】 この場合、障害が生じたＥＣＵが旧バージョンで動作すると、旧バーションで動作するＥＣＵと新バーションで動作するＥＣＵが混在し、新旧バーションの制御プログラムの相性問題などによりＥＣＵが動作不良に陥る可能性がある。本発明は、かかる従来の問題点に鑑み、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる、プログラム更新システム等を提供することを目的とする。 【課題を解決するための手段】 【０００８】 （１） 本発明の一態様に係るシステムは、車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続されたゲートウェイと、を含むプログラム更新システムであって、前記ゲートウェイは、複数の前記制御装置に対する更新プログラムを記憶する記憶部と、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、同時更新の必要性があるすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備える。」 （エ）「【発明の効果】 【００１１】 本発明によれば、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。」 （オ）「【００１３】 ＜本発明の実施形態の概要＞ 以下、本発明の実施形態の概要を列記して説明する。 （１） 本実施形態のプログラム更新システムは、車両に搭載された複数の制御装置と、複数の前記制御装置と車内通信可能に接続されたゲートウェイと、を含むプログラム更新システムであって、前記ゲートウェイは、複数の前記制御装置に対する更新プログラムを記憶する記憶部と、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、同時更新の必要性があるすべての前記制御装置が前記更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行する処理部と、を備える。 【００１４】 本実施形態のプログラム更新システムによれば、ゲートウェイの処理部が、同時更新の必要性があるすべての制御装置が更新プログラムを用いた制御プログラムの更新を完了するまで、当該制御装置に制御プログラムの更新を継続させる、更新継続処理を実行するので、旧バーションで動作する制御装置と新バーションで動作する制御装置が混在しない。このため、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。 【００１５】 （２） 本実施形態のプログラム更新システムにおいて、複数の前記制御装置が、前記制御プログラムの動作領域が複数存在する記憶装置を有する複数領域タイプである場合には、前記更新継続処理として、いずれかの前記制御装置において途中で更新が中断した場合に、中断した当該制御装置に中断点から更新を再開させる更新復帰処理を採用すればよい。また、旧バージョンを他領域にバックアップとして確保しているため、リプロ対象のＥＣＵを一斉に復帰させる（「ロールバック」という）こともできる。 【００１６】 本実施形態のプログラム更新システムではこの場合、基本的に中断点から再開させるが、場合によっては、すぐに車両を動かす必要がある事態が生じる。ゲートウェイの処理部が上記のロールバック処理を実行すると、短時間で復帰できる。いずれも旧バーションで動作する制御装置と新バーションで動作する制御装置が混在しない。このため、複数の制御装置の制御プログラムを同時に更新する場合に、制御装置に動作不良が生じる事態を未然に防止することができる。」 （カ）「【００２４】 〔システムの全体構成〕 図１は、本発明の実施形態に係るプログラム更新システムの全体構成図である。図１に示すように、本実施形態のプログラム更新システムは、広域通信網２を介して通信可能な車両１、管理サーバ５及びＤＬ（ダウンロード）サーバ６を含む。」 （キ）「【００２５】 車両１には、ゲートウェイ１０及び複数のＥＣＵ３０と、各ＥＣＵ３０によりそれぞれ制御される各種の車載機器（図示せず）が搭載されている。車両１には、共通の車内通信線にバス接続された複数のＥＣＵ３０による通信グループが存在し、ゲートウェイ１０は、通信グループ間の通信を中継している。このため、ゲートウェイ１０には、複数の車内通信線が接続されている。 【００２６】 ゲートウェイ１０は、携帯電話網などの広域通信網２に通信可能に接続されている。ゲートウェイ１０は、広域通信網２を通じて管理サーバ５及びＤＬサーバ６などの車外装置から受信した情報をＥＣＵ３０に送信する。ゲートウェイ１０は、ＥＣＵ３０から取得した情報を、広域通信網２を介して管理サーバ５などの車外装置に送信する。 【００２７】 図１では、ゲートウェイ１０が車外装置と直接通信を行う場合が例示されている。もっとも、ゲートウェイ１０に別の通信装置を接続し、別の通信装置を介して車外装置と通信を行う構成としてもよい。ゲートウェイ１０に接続される別の通信装置としては、例えば、ユーザが所有する携帯電話機、スマートフォン、タブレット型端末、ノートＰＣ（Personal Computer）等の装置が考えられる。 【００２８】 図１のプログラム更新システムでは、管理サーバ５とＤＬサーバ６が別個のサーバで構成されているが、これらのサーバ５，６を１つのサーバ装置で構成してもよい。」 （ク）「【００２９】 〔ゲートウェイの内部構成〕 図２はゲートウェイ１０の内部構成を示すブロック図である。図２に示すように、ゲートウェイ１０は、ＣＰＵ（Central Processing Unit）１１、ＲＡＭ（Random Access Memory）１２、記憶部１３、及び車内通信部１４などを備える。ゲートウェイ１０は、無線通信部１５と車内通信線を介して接続されているが、これらは一つの装置で構成してもよい。 【００３０】 ＣＰＵ１１は、記憶部１３に記憶された一又は複数のプログラムをＲＡＭ１２に読み出して実行することにより、ゲートウェイ１０を各種情報の中継装置として機能させる。ＣＰＵ１１は、例えば時分割で複数のプログラムを切り替えて実行することにより、複数のプログラムを並列的に実行可能である。ＲＡＭ１２は、ＳＲＡＭ（Static ＲＡＭ）又はＤＲＡＭ（Dynamic ＲＡＭ）等のメモリ素子で構成され、ＣＰＵ１１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。 【００３１】 記憶部１３は、フラッシュメモリ若しくはＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性のメモリ素子などにより構成されている。記憶部１３は、ＣＰＵ１１が実行するプログラム及び実行に必要なデータ等を記憶する記憶領域を有する。記憶部１３は、ＤＬサーバ６から受信した各ＥＣＵ３０の更新プログラムなども記憶する。」 （ケ）「【００３５】 〔ＥＣＵの内部構成〕 図３はＥＣＵ３０の内部構成を示すブロック図である。図３に示すように、ＥＣＵ３０は、ＣＰＵ３１、ＲＡＭ３２、記憶部３３、通信部３４などを備える。ＥＣＵ３０は、車両１に搭載された複数の車載機器を個別に制御する制御装置である。ＥＣＵ３０の種類には、例えば、エンジン制御ＥＣＵ、ステアリング制御ＥＣＵ、及びドアロック制御ＥＣＵなどがある。 【００３６】 ＣＰＵ３１は、記憶部３３に予め記憶された一又は複数のプログラムをＲＡＭ３２に読み出して実行することにより、自身が担当する車載機器の動作を制御する。ＲＡＭ３２は、ＳＲＡＭ又はＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ３１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。 【００３７】 記憶部３３は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、或いは、ハードディスクなどの磁気記憶装置等により構成されている。記憶部３３が記憶する情報には、例えば、制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるためのコンピュータプログラム（以下、「制御プログラム」という。）が含まれる。」 （コ）「【００３９】 ＥＣＵ３０のＣＰＵ３１には、当該ＣＰＵ３１による制御モードを、「通常モード」又は「リプログラミングモード」（以下、「リプロモード」ともいう。）のいずれかに切り替える起動部３５が含まれる。通常モードとは、ＥＣＵ３０のＣＰＵ３１が本来の制御内容（例えば、エンジン制御やステアリング制御など）を実行する制御モードのことである。リプログラミングモードとは、ＣＰＵ３１が制御プログラムのＲＯＭ領域に対して消去、書き換えの権限が付与されるモードのことである。本モードのときにのみ、制御プログラムを新バージョンに更新することが可能となる。 【００４０】 起動部３５は、リプログラミングモードにおいて新バーションの制御プログラムを記憶部３３に書き込むと、いったん再起動（リセット）して新バージョンの制御プログラムが書き込まれた記憶領域についてベリファイ処理を実行し、ベリファイ処理の完了後にＣＰＵ３１を更新後の制御プログラムによって動作させる。」 （サ）「【００４１】 〔管理サーバの内部構成〕 図４は、管理サーバ５の内部構成を示すブロック図である。図４に示すように、管理サーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、記憶部５４、及び通信部５５などを備える。」 （シ）「【００４４】 図４に示すように、記憶部５４が記憶する情報には、車両１に搭載されたＥＣＵ３０（ここでは、ＶＩＮ＝１の車両１に搭載されたＥＣＵ３０の識別番号を１～３とする。）の制御プログラムのバーションを記録したリビジョンテーブルＲＴが含まれる。リビジョンテーブルＲＴは、車両１の車両識別番号（ＶＩＮ）と、車両識別番号ごとのリビジョンアップの履歴を表す識別情報であるリビジョン番号と、各リビジョン番号に対応するＥＣＵ１～３のバージョンとを纏めたテーブルよりなる。」 （ス）「【００４９】 〔制御プログラムの同時更新のシーケンス〕 図５は、本実施形態のプログラム更新システムにおいて実行される、複数のＥＣＵ１～３に対する制御プログラムの同時更新の一例を示すシーケンス図である。なお、以下においては、図４のリビジョンテーブルＲＴに従って、各ＥＣＵ１～３の制御プログラムを次のように更新する場合を想定する。リビジョン番号：Ｒ２．０→Ｒ２．４ＥＣＵ１：バーション１．０→バーション１．２ＥＣＵ２：バーション１．３→バーション２．０ＥＣＵ３：バーション２．０→バーション２．２ 【００５０】 更新プログラムは、新バーションのプログラムそのものであってもよいが、本実施形態では、旧バーションからの差分プログラムである場合を想定する。この場合、旧バージョンと新バージョンとのファイルの差分情報を含むΔが同じ記憶領域にあれば、旧バージョンにΔを適応することで、新バージョンに更新することができる。ＥＣＵ１のバーション１．０からバーション１．２への更新プログラムを「Δ１」とし、ＥＣＵ２のバーション１．３からバーション２．０への更新プログラムを「Δ２」とし、ＥＣＵ３のバーション２．０からバーション２．２への更新プログラムを「Δ３」とする。 【００５１】 図５に示すように、本実施形態の制御プログラムの同時更新においては、まず、ゲートウェイ１０が、各ＥＣＵ１～３の制御プログラムの現状のバージョン情報を収集する（ステップＳ１）。図示の例では、ＥＣＵ１の制御プログラムの現バーションは「１．０」であり、ＥＣＵ２の制御プログラムの現バーションは「１．３」であり、ＥＣＵ３の制御プログラムの現バーションは「２．０」である。 【００５２】 次に、ゲートウェイ１０は、収集したＥＣＵ１～３の制御プログラムのバージョン情報と、自車両の車両識別番号（ＶＩＮ）を管理サーバ５に送信する（ステップＳ２）。管理サーバ５は、ゲートウェイ１０から通知されたバージョン情報と車両識別番号に基づいて、前述のリビジョンテーブルＲＴ（図４参照）を探索することにより、各ＥＣＵ１～３について、車両１の各ＥＣＵ１～３の制御プログラムを同時に更新する必要があるか否かを判定する。 【００５３】 ここでは、ＥＣＵ１がバーション１．０であり、ＥＣＵ２がバーション１．３であり、ＥＣＵ３がバーション２．０であるから、管理サーバ５は、車両１がリビジョンＲ２．０で運用中であると判定する。また、管理サーバ５は、最新版のリビジョンＲ２．４が存在することから、ＥＣＵ１のバーション１．２への更新、ＥＣＵ２のバーション２．０への更新、及び、ＥＣＵ３のバーション２．２への更新を、同時に行う必要があると判定する。 【００５４】 そこで、管理サーバ５は、バーション情報を送信してきたゲートウェイ１０宛てに、各ＥＣＵ１～３の更新プログラムΔ１～Δ３の保存先ＵＲＬとダウンロード要求をゲートウェイ１０宛てに送信する（ステップＳ３）。これにより、ゲートウェイ１０は、各ＥＣＵ１～３のための更新プログラムΔ１～Δ３をＤＬサーバ６からダウンロードする（ステップＳ４）。ゲートウェイ１０は、受信した更新プログラムΔ１～Δ３を自装置の記憶部１３に一時的に格納して保存する。 【００５５】 更新プログラムΔ１～Δ３の保存が完了すると、ゲートウェイ１０は、ＤＬが正常に完了したことを管理サーバ５に送信する（ステップＳ５）。引き続き自動で更新を行う場合、ＤＬ完了通知を受信した管理サーバ５は、制御プログラムの更新要求をゲートウェイ１０に送信する。ＤＬ完了後、一時中断し外部から更新要求を受けてから、制御プログラムの更新要求をゲートウェイ１０に送信してもよい（ステップＳ６）。更新要求を受信したゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ１～Δ３を用いて制御プログラムを更新させるべく、各ＥＣＵ１～３にリプロモード移行要求をそれぞれ送信する（ステップＳ７）。 【００５６】 リプロモード移行要求を受信すると、各ＥＣＵ１～３は自身の制御モードを通常モードからリプログラミングモードに切り替える。これにより、各ＥＣＵ１～３は、更新プログラムΔ１～Δ３の展開と、現状の制御プログラムを新バーションの制御プログラムに書き換える処理が可能な状態となる。 【００５７】 ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ１をＥＣＵ１に送信する（ステップＳ８）。ＥＣＵ１は、受信した更新プログラムΔ１を展開して旧バーション１．０に適用することにより、制御プログラムを旧バーション１．０から新バーション１．２に書き換える。書き換えが完了すると、ＥＣＵ１は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ９）。【００５８】 ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ２をＥＣＵ２に送信する（ステップＳ１０）。ＥＣＵ２は、受信した更新プログラムΔ２を展開して旧バーション１．３に適用することにより、制御プログラムを旧バーション１．３から新バーション２．０に書き換える。書き換えが完了すると、ＥＣＵ２は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ１１）。 【００５９】 ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ３をＥＣＵ３に送信する（ステップＳ１２）。ＥＣＵ３は、受信した更新プログラムΔ３を展開して旧バーション２．０に適用することにより、制御プログラムを旧バーション２．０から新バーション２．２に書き換える。書き換えが完了すると、ＥＣＵ３は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ１３）。 【００６０】 なお、図５に例示するシーケンスでは、ステップＳ８～ステップＳ１３までの処理が時系列に表現されているが、これらの処理は同時並行的に行われるので、前後の順番が入れ替わってもよい。 【００６１】 ゲートウェイ１０は、すべてのＥＣＵ１～３から書き換えの完了通知を受信すると、各ＥＣＵ１～３に通常モード移行要求とリセット要求を各ＥＣＵ１～３に送信する（ステップＳ１４）。通常モード移行要求を受信した各ＥＣＵ１～３は、自身の制御モードをリプロモードから通常モードに切り替え、リセット要求に応じてシステムを再起動する。これにより、各ＥＣＵ１～３が、新バーションの制御プログラムによりそれぞれ動作する。 【００６２】 また、ゲートウェイ１０は、書き換えの完了通知をすべてのＥＣＵ１～３から受信すると、更新完了通知を管理サーバ５に送信する（ステップＳ１５）。これにより、管理サーバ５は、車両１の各ＥＣＵ１～３について、制御プログラムの更新がすべて完了したことを察知する。」 （セ）「【００６３】 〔複数領域ＥＣＵによる書き換え処理〕 図６は、制御プログラムの動作領域を複数（図例では２つ）有するＥＣＵ３０（以下、「複数領域ＥＣＵ」という。）が実行する制御プログラムの書き換え処理を示す状態遷移図である。図６では、ＥＣＵ３０の制御プログラムのバーションを「１．０」から「１．２」に更新する場合を例示しているが、その他のバージョン番号の場合も以下と同様の書き換え処理が実行される。 【００６４】 ＥＣＵ３０の記憶部３３は、制御プログラムが動作可能な２つ主領域１，２と、更新プログラムΔ１が格納される１つのワークスペースとに区分されている。ＥＣＵ３０の起動部３５は、起動時において制御プログラムの動作領域を主領域１，２のいずれかに選択可能である。ここでは、プログラム更新前の通常モードにおいて、動作領域として主領域１が選択されているものとする。なお、図６中のハッチング付きの領域は制御プログラムが実行されるアクティブな領域を示す。 【００６５】 起動部３５は、リプログラミングモードにおいてゲートウェイ１０から更新プログラムΔ１を受信すると、更新プログラムΔ１をワークスペースに格納するとともに、主領域２に旧バーション１．０の制御プログラムのバックアップを作成する（図６（ａ））。次に、起動部３５は、更新プログラムΔ１を展開して主領域２のバーション１．０のバックアップに適用し（図６（ｂ））、主領域２の制御プログラムをバーション１．０からバーション１．２に書き換える（図６（ｃ））。 【００６６】 上記の書き換えが完了すると、起動部３５は、動作領域を主領域２に切り替えて主領域２のベリファイ処理を実行したあと（図６（ｄ））、主領域２に格納されたバーション１．２の制御プログラムにてＣＰＵ３１を動作させる（図６（ｅ））。上記のようにして主領域２に対する制御プログラムの書き換えが完了すると、起動部３５は、通常モードにおける起動時の動作領域を主領域２に切り替えるとともに、書き換えの完了通知をゲートウェイ１０に送信する。 （ソ）「【００６７】 〔複数領域ＥＣＵに対するロールバック処理〕 図７は、複数領域ＥＣＵ３０に対してゲートウェイ１０が実行するロールバック処理の説明図である。図７において縦横に配列された各ボックスは、各ＥＣＵ１～３の記憶部３３内の時間経過ごとのメモリ状態Ｒ１～Ｒ５の変遷を示す。各ボックスの上段部分は図６の「主領域１」に対応し、下段部分は図６の「主領域２」に対応している。 【００６８】 図７において、時間ｔは下向きに進行する。時刻ｔ０は、ゲートウェイ１０によるリプロモード移行要求Ｓ７の送信時点である。時刻ｔ９は、ゲートウェイ１０による完了通知Ｓ９の受信時点であり、時刻ｔ１１は、ゲートウェイ１０による完了通知Ｓ１１の受信時点であり、時刻ｔ１３は、ゲートウェイ１０による完了通知Ｓ１３の受信時点である。 【００６９】 メモリ状態Ｒ１は、各ＥＣＵ１～３がリプロモード移行要求Ｓ７を受信したあと、主領域２に旧バーションのバックアップが作成された状態を示している。メモリ状態Ｒ１では、各ＥＣＵ１～３が書き換え処理を未だ実行していないので、主領域１，２の双方ともに旧バーションの制御プログラムが格納されている。メモリ状態Ｒ２は、各ＥＣＵ１～３が主領域２について書き換え処理を実行中である状態を示している。 【００７０】 メモリ状態Ｒ３は、ＥＣＵ１が主領域２の書き換えを完了して完了通知Ｓ９を送信し、ＥＣＵ２，３が未だ書き換え処理を実行中である状態を示している。メモリ状態Ｒ４は、更にＥＣＵ２が主領域２の書き換えを完了して完了通知Ｓ１１を送信し、ＥＣＵ３が未だ書き換え処理を実行中である状態を示している。メモリ状態Ｒ５は、更にＥＣＵ３が主領域２の書き換えを完了して完了通知Ｓ１３を送信し、すべてのＥＣＵ１～３が新バーションに書き換えられた状態を示している。 【００７１】 ここで、例えばｔ９≦ｔ＜ｔ１１の期間中に、車両１の電源失陥などの何らかの障害により、ＥＣＵ３の書き換え処理が中断時点ｔｐにおいて中断したと仮定する。この場合、ゲートウェイ１０は、上記の障害がなくなったあとに、リプロモード移行要求Ｓ７をすべてのＥＣＵ１～３に再送信する。これがロールバック処理である。これにより、書き換え中であったＥＣＵ２，３だけでなく、書き換え済みであったＥＣＵ１についても、当初のメモリ状態Ｒ１から新バーションへの書き換え処理を再度実行する。 【００７２】 なお、ｔ９≦ｔ＜ｔ１１の期間中だけでなく、ｔ０≦ｔ＜ｔ９或いはｔ１１≦ｔ＜ｔ１３の期間中に、電源失陥などの障害に伴う中断時点ｔｐを検出した場合でも、ゲートウェイ１０は同様のロールバック処理を実行する。すなわち、ゲートウェイ１０は、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間は、制御プログラムの書き込みを阻害する障害を検出した場合にロールバック処理を実行する。 【００７３】 このように、本実施形態のプログラム更新システムでは、いずれかのＥＣＵ１～３において途中で更新が中断した場合に、すべてのＥＣＵ１～３に更新をやり直させるロールバック処理を実行する。従って、複数領域ＥＣＵ１～３の同時更新中においていずれかのＥＣＵ１～３における書き換え処理が中断した場合に、すべてのＥＣＵ１～３を動作保障されている現状の旧バージョンに戻すことができる。 【００７４】 このため、旧バーションの制御プログラムで動作するＥＣＵ３０と新バーションの制御プログラムで動作するＥＣＵ３０とが混在することにより、動作保障されていない制御プログラムが同時に動作して動作不良となるのを未然に防止することができる。なお、上記のロールバック処理は、同時更新の必要性があるすべてのＥＣＵ１～３が更新プログラムΔ１～Δ３を用いた制御プログラムの更新を完了するまで、当該ＥＣＵ１～３に制御プログラムの更新を継続させる「更新継続処理」の一種である。」 （タ）図１ 「 ［図：0001413822000001.jpg］ 」 （チ）図２ 「 ［図：0001413822000002.jpg］ 」 （ツ）図３ 「 ［図：0001413822000003.jpg］ 」 （テ）図４ 「 ［図：0001413822000004.jpg］ 」 （ト）図５ 「 ［図：0001413822000005.jpg］ 」 （ナ）図６ 「 ［図：0001413822000006.jpg］ 」 （ニ）図７ 「 ［図：0001413822000007.jpg］ 」 （ヌ）認定事項 ａ 上記（オ）の段落【００１３】の下線部の記載から「ゲートウェイは、複数の制御装置に対する更新プログラムを記憶する記憶部と、記憶された複数の前記更新プログラムを対応する前記制御装置にそれぞれ送信する車内通信部と、更新継続処理を実行する処理部と、を備える」ものであり、図１等から「ゲートウェイ１０」であることが理解でき、上記（ケ）の段落【００３５】、【００３７】の下線部の記載から、制御装置であるＥＣＵ３０の「記憶部３３が記憶する情報には、制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムが含まれ」、そして、図５の制御プログラムの同時更新のシーケンスと上記（ス）の段落【００５１】～【００６２】（特に、段落【００６１】の下線部）の説明により「ゲートウェイ１０は、すべてのＥＣＵ１～３から書き換えの完了通知を受信すると、各ＥＣＵ１～３に通常モード移行要求とリセット要求を各ＥＣＵ１～３に送信」する処理をし、「通常モード移行要求を受信した各ＥＣＵ１～３は、自身の制御モードをリプロモードから通常モードに切り替え、リセット要求に応じてシステムを再起動」して、「各ＥＣＵ１～３が、新バーションの制御プログラムによりそれぞれ動作する」ことからみて、「ゲートウェイ１０は制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムの更新を管理していること」は明らかである。 ｂ 上記（ケ）の段落【００３５】の下線部の「ＥＣＵ３０は、車両１に搭載された複数の車載機器を個別に制御する制御装置である。」という記載、同じく段落【００３７】の下線部の制御装置であるＥＣＵ３０の「記憶部３３が記憶する情報には、制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムが含まれる」という記載及び図３からみて、「ＥＣＵ３０（のＣＰＵ３１）が」「制御対象である車載装置を制御するための処理を実行すること」は明らかであり、上記（カ）の段落【００２４】の下線部の「プログラム更新システムは、広域通信網２を介して通信可能な車両１、管理サーバ５及びＤＬ（ダウンロード）サーバ６を含む。」という記載、同じく段落【００２５】の下線部の「車両１には、ゲートウェイ１０及び複数のＥＣＵ３０と、各ＥＣＵ３０によりそれぞれ制御される各種の車載機器が搭載されている。」という記載と上記ａを踏まえて、「プログラム更新システムは、制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムの更新を管理するゲートウェイ１０と、前記制御対象である車載装置を制御するための処理を実行する複数のＥＣＵ３０を含む」ことは明らかである。 ｃ 上記（セ）の記載事項及び〔複数領域ＥＣＵが実行する制御プログラムの書き換え処理〕を示す図６を参照すると、段落【００６４】の下線部には、「ＥＣＵ３０の記憶部３３は、制御プログラムが動作可能な２つ主領域１，２と、更新プログラムΔ１が格納される１つのワークスペースとに区分されている。」と記載され、図６（ｅ）からみて、ＥＣＵ３０の記憶部３３の主領域１には、更新前の制御プログラムｖ１．０が記憶され、主領域２には、更新後の制御プログラムｖ１．２が記憶されていることは明らかである。 そして、上記（ソ）の段落【００６７】の「図７において縦横に配列された各ボックスは、各ＥＣＵ１～３の記憶部３３内の時間経過ごとのメモリ状態Ｒ１～Ｒ５の変遷を示す。各ボックスの上段部分は図６の「主領域１」に対応し、下段部分は図６の「主領域２」に対応している。」との記載、及び、〔複数領域ＥＣＵに対するロールバック処理〕を示す図７のメモリ状態Ｒ３～Ｒ５を参照すると、ＥＣＵ３０の複数のＥＣＵ１～３について、同様に主領域１に更新前の制御プログラムが、主領域２に更新後の制御プログラムが記憶され得ることが分かる。 また、上記（ス）の段落【００５４】の下線部の「ゲートウェイ１０は、各ＥＣＵ１～３のための更新プログラムΔ１～Δ３をＤＬサーバ６からダウンロードする」（図５のステップＳ４）との記載、及び、同じく段落【００５７】の「ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ１をＥＣＵ１に送信する（ステップＳ８）。ＥＣＵ１は、受信した更新プログラムΔ１を展開して旧バーション１．０に適用することにより、制御プログラムを旧バーション１．０から新バーション１．２に書き換える。」という記載 、段落【００５８】の「ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ２をＥＣＵ２に送信する（ステップＳ１０）。ＥＣＵ２は、受信した更新プログラムΔ２を展開して旧バーション１．３に適用することにより、制御プログラムを旧バーション１．３から新バーション２．０に書き換える。」という記載、及び段落【００５９】の「ゲートウェイ１０は、記憶部１３に保存した更新プログラムΔ３をＥＣＵ３に送信する（ステップＳ１２）。ＥＣＵ３は、受信した更新プログラムΔ３を展開して旧バーション２．０に適用することにより、制御プログラムを旧バーション２．０から新バーション２．２に書き換える。」という記載からみて、「３つの更新後の制御プログラムは、ゲートウェイ１０がＤＬサーバ６から取得した更新プログラムΔ１～Δ３に基づいていること」は明らかである。 そうすると、これらの事項からみて、「複数のＥＣＵ３０のうち、１つ以上のＥＣＵ３０は、１つ以上の更新前の制御プログラムと、ゲートウェイ１０がＤＬサーバ６から取得した更新プログラムΔ１～Δ３に基づく１つ以上の更新後の制御プログラムとを記憶する記憶部３３を備えること」が分かる。 ｄ 上記（セ）の段落【００６４】の下線部の「ここでは、プログラム更新前の通常モードにおいて、動作領域として主領域１が選択されているものとする。」という記載、同じく段落【００６５】の下線部の「起動部３５は、リプログラミングモードにおいてゲートウェイ１０から更新プログラムΔ１を受信すると、更新プログラムΔ１をワークスペースに格納するとともに、主領域２に旧バーション１．０の制御プログラムのバックアップを作成する」、「起動部３５は、更新プログラムΔ１を展開して主領域２のバーション１．０のバックアップに適用し、」「主領域２の制御プログラムをバーション１．０からバーション１．２に書き換える」という記載、同じく段落【００６６】の下線部の「書き換えが完了すると、起動部３５は、動作領域を主領域２に切り替えて主領域２のベリファイ処理を実行したあと、主領域２に格納されたバーション１．２の制御プログラムにてＣＰＵ３１を動作させ、上記のようにして主領域２に対する制御プログラムの書き換えが完了すると、起動部３５は、通常モードにおける起動時の動作領域を主領域２に切り替える」という記載及び図３の図示内容からみて、「ＥＣＵ３０のＣＰＵ３１を動作させる制御プログラムを更新前の制御プログラムから更新後の制御プログラムに切り替える処理を実行する起動部３５を備え」ることは明らかである。 また、図７のメモリ状態Ｒ５のＥＣＵ１～ＥＣＵ３からなる態様を考慮すれば、ＥＣＵ３０のＣＰＵ３１を動作させる制御プログラム、更新前の制御プログラム、及び、更新後の制御プログラムがそれぞれ「１つ以上」となることも明らかである。 ｅ 上記（オ）の段落【００１５】の下線部の記載からみて、「ロールバック」とは「複数の制御装置が、制御プログラムの動作領域が複数存在する記憶装置を有する複数領域タイプである場合には、更新継続処理として、いずれかの前記制御装置において途中で更新が中断した場合に、旧バージョンを他領域にバックアップとして確保しているため、リプロ対象のＥＣＵを一斉に復帰させること」といえる。 そして、上記（ソ）の段落【００６７】の下線部に「図７は、複数領域ＥＣＵ３０に対してゲートウェイ１０が実行するロールバック処理の説明図である。図７において縦横に配列された各ボックスは、各ＥＣＵ１～３の記憶部３３内の時間経過ごとのメモリ状態Ｒ１～Ｒ５の変遷を示す。」と記載されているように、複数領域タイプの複数のＥＣＵ３０（ＥＣＵ１～３）に対してゲートウェイ１０が実行する「ロールバック処理」の説明図が図７であり、上記（ソ）の段落【００７１】の下線部の「車両１の電源失陥などの何らかの障害により、ＥＣＵ３の書き換え処理が中断時点ｔｐにおいて中断したと仮定する。この場合、ゲートウェイ１０は、上記の障害がなくなったあとに、リプロモード移行要求Ｓ７をすべてのＥＣＵ１～３に再送信する。これがロールバック処理である。」という記載及び同じく段落【００７３】の下線部の「プログラム更新システムでは、いずれかのＥＣＵ１～３において途中で更新が中断した場合に、すべてのＥＣＵ１～３に更新をやり直させるロールバック処理を実行する。」という記載からみて、「ロールバック処理」とは「いずれかのＥＣＵ１～３において途中で更新が中断した場合に、リプロモード移行要求Ｓ７をすべてのＥＣＵ１～３に再送信して、更新をやり直させる」ことであり、プログラム更新システムのゲートウエイ１０が実行するものである。 そうすると、「ロールバック処理」は、上記「ロールバック」を含む処理といえる。 そして、「ロールバック」を行うことにより、上記（ソ）の段落【００７３】の下線部に記載されるように「複数領域ＥＣＵ１～３の同時更新中においていずれかのＥＣＵ１～３における書き換え処理が中断した場合に、すべてのＥＣＵ１～３を動作保障されている現状の旧バージョンに戻すことができる」ものである。 また、上記（ソ）の段落【００７１】の下線部の「書き換え済みであったＥＣＵ１についても、当初のメモリ状態Ｒ１から新バーションへの書き換え処理を再度実行する」という記載からみて、「ロールバック処理」における「ロールバック」により、「書き換え済みであったＥＣＵを当初のメモリ状態とする」ことが行われており、「１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理を実行」していることは明らかである（ここで、メモリ状態R４の場合には、「１つ以上」の例として「２つ」になる。）。 さらに、上述したように、「ロールバック処理」とは「いずれかのＥＣＵ１～３において途中で更新が中断した場合に、リプロモード移行要求Ｓ７をすべてのＥＣＵ１～３に再送信して、更新をやり直させる」ことであり、上記（オ）の段落【００１６】の下線部の記載により「ロールバック処理を実行」して、リプロモード移行要求Ｓ７を再送信するのは「ゲートウェイ１０の処理部」であって、リプロモード移行要求Ｓ７を受けて、ＥＣＵ１等を当初のメモリ状態に戻すのは、上記（セ）の段落【００６４】の下線部の記載や図３から「起動部３５」）であることは明らかであるから、「ゲートウェイ１０の処理部からリプロモード移行要求Ｓ７が再送信された場合に、１つ以上の動作させようとする制御プログラムを、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理を実行する起動部３５」といえる。 ｆ 上記ｄ、ｅから、引用文献１には、「ＥＣＵ３０のＣＰＵ３１が実行する１つ以上の制御プログラムを、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理と、ゲートウェイ１０の処理部からリプロモード移行要求Ｓ７が再送信された場合に、１つ以上の動作させようとする制御プログラムを、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理を実行する起動部３５と、を備え」ることが記載されているといえる。 ｇ 上記（ソ）の段落【００７１】の下線部の「車両１の電源失陥などの何らかの障害により、ＥＣＵ３の書き換え処理が中断時点ｔｐにおいて中断した」という記載、同じく段落【００７２】の下線部の「ゲートウェイ１０は、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間は、制御プログラムの書き込みを阻害する障害を検出した場合にロールバック処理を実行する。」という記載や同じく段落【００７３】の下線部の「プログラム更新システムでは、いずれかのＥＣＵ１～３において途中で更新が中断した場合に、すべてのＥＣＵ１～３に更新をやり直させるロールバック処理を実行する。」という記載及び段落【００７２】の「書き込みを阻害する障害」や段落【００７３】の「途中で更新が中断した場合」の例として段落【００７１】に「車両１の電源失陥などの障害」が挙げられていることからみて、上記ｅ、ｆを踏まえると、「ゲートウェイ１０は、いずれかのＥＣＵ１～３において、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間に、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合に、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理をした起動部３５に、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理の実行を含むリプロモード移行要求Ｓ７を再送信するゲートウェイ１０の処理部を備える」ことが分かる。 （ネ）引用発明 これらの記載事項及び認定事項からみて、本件補正発明に倣って整理すると、引用文献１には、以下の発明（以下「引用発明」という。）が記載されていると認められる。 「制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムの更新を管理するゲートウェイ１０と、前記制御対象である車載装置を制御するための処理を実行する複数のＥＣＵ３０を含むプログラム更新システムであって、 複数のＥＣＵ３０のうち、１つ以上のＥＣＵ３０は、 １つ以上の更新前の制御プログラムと、前記ゲートウェイ１０がＤＬサーバ６から取得した更新プログラムΔ１～Δ３に基づく１つ以上の更新後の制御プログラムとを記憶する記憶部３３と、 前記ＥＣＵ３０のＣＰＵ３１を動作させる１つ以上の制御プログラムを、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理と、前記ゲートウェイ１０の処理部からリプロモード移行要求Ｓ７が再送信された場合に、１つ以上の動作させようとする制御プログラムを、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理を実行する起動部３５と、を備え、 前記ゲートウェイ１０は、いずれかの前記ＥＣＵ１～３において、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間に、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合に、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理をした起動部３５に、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理の実行を含むリプロモード移行要求Ｓ７を再送信するゲートウェイ１０の処理部を備える、プログラム更新システム。」 イ 引用文献２ 原査定の拒絶の理由で引用された、本願の原出願前に日本国内において頒布された刊行物である特開２００４－１２６９６０号公報（平成１６年４月２２日出願公開、以下「引用文献２」という。）には、図面とともに次の記載がある。 （ア）「【０００１】 【発明の属する技術分野】 この発明は、広域の複数箇所に分散配置された分散手段におけるソフトウェア（以下、ソフトウェアをソフトと略して示す）のバージョンアップを簡便かつ確実に実施することができるリモートメンテナンスシステムに関するものである。」 （イ）「【０００８】 ・・・また、バージョンアップしたソフトに問題があり、バージョンアップ前の状態に戻したい場合、更新前のソフトをサーバより、クライアントに送付しなければならないという問題点がある。 【０００９】 この発明は上記のような課題を解決するためになされたものであり、簡便にかつ確実にソフトの更新を行うことができるリモートメンテナンスシステムを得ることを目的とする。」 （ウ）「【００１１】 【発明の実施の形態】実施の形態１．・・・。本願リモートメンテナンスシステムは保守センター手段１と、現ソフトにて稼動している複数の分散手段２ａ、２ｂ・・・と、公衆回線またはＬＡＮ３とから成る。」 （エ）「【００１４】 分散手段２ａ、２ｂ・・・にはそれぞれ、分散側通信手段２１と、ソフト更新手段２２と、更新待ソフト待機手段２３と、ソフト稼動手段２４と、稼動ソフト管理手段２５、旧ソフト格納手段２６と、旧ソフト管理手段２７と、更新情報送信手段２８と、更新情報確認手段２９と、時刻決定手段３０とを備えている。」 （オ）「【００２５】 次に、分散手段２ａにおける、予め設定された反映時刻にソフト更新処理を行う、ソフト更新の動作について図４のフローチャートに基づいて説明する。まず、時刻決定手段３０が更新するための反映時刻に成ると、ソフト更新手段２２にソフト更新処理を開始させる（ステップＳ６１）。次に、ソフト更新手段２２は更新待ソフト格納手段２３へソフトの有無をチェックする（ステップＳ６３）。そして新ソフトが無い場合には、反映終了と成る（ステップＳ６８）。 【００２６】 次に、新ソフトがあれば、分散手段２ａにて行っている業務処理を自動で終了させる（ステップＳ６４）。次に、更新対象の現ソフト（現世代）および現ソフトの情報を、ソフト稼動手段２３および稼動ソフト管理手段２５から、それぞれ旧ソフト格納手段２６および旧ソフト管理手段２７にコピーする（ステップＳ６５）。 【００２７】 次に、更新待ソフト格納手段２３の新ソフトをソフト稼動手段２４にコピーし、対応するソフト情報を稼動ソフト管理手段２５に更新する（ステップＳ６５）。次に、ソフト更新手段２２は、更新状態を「更新処理中」として分散手段２ａを自動で再起動する（ステップＳ６６）。次に、更新情報送信手段２８は、分散手段２ａが立ち上がり後、保守センター手段１に反映完了を送信する（ステップＳ６７）。そして、反映を終了する（ステップＳ６８）。」 （カ）「【００３０】 次に、分散手段２ａのソフトのバージョンの戻し処理の動作を図７のフローチャートに基づいて説明する。まず、分散側通信手段２１は、保守センター手段１より「戻し処理」を受信する（ステップＳ９２）。その情報をソフト更新手段２２に渡す。通知されたソフト更新手段２２は、業務処理を自動で終了させる（ステップＳ９３）。そして、旧ソフト格納手段（前世代）２６および旧ソフト管理手段（前世代）２７のソフトおよびソフト情報をそれぞれソフト稼動手段（現世代）２４および稼動ソフト管理手段（前世代）２５にコピーする（ステップＳ９４）。 【００３１】 次に、更新情報手段２８を「戻し処理中」として自動でソフト稼動手段（現世代）２４にて、分散手段２ａを再起動する（ステップＳ９５）。次に、分散手段２ａが立ちあがった後、更新情報送信手段２８は、保守センター手段１に「戻し完了」を送信する（ステップＳ９６）。そして、保守センター手段１は分散手段２ａより「戻し完了」を受信する（図５のフローチャートの、分散手段２ａから反映結果を受信（ステップＳ７３））。次に、保守側通信手段１２は、当該分散手段２ａのソフト更新情報手段１６に戻し日を登録する（ステップＳ７５）。 【００３２】 上記のように構成された実施の形態１のリモートメンテナンスシステムは、分散手段に転送・反映する新ソフトを、保守センター手段に格納するのみで、保守センター手段が自動的にソフト更新情報を作成し、更新対象の分散手段を決定して、当該新ソフトを送信して、分散手段の反映結果を分散手段対応のソフト更新履歴に反映するため、リモート保守作業の軽減と人為的ミスをなくすことができる。」 （キ）図１ 「 ［図：0001413822000008.jpg］ 」 （ク）図４ 「 ［図：0001413822000009.jpg］ 」 （ケ）図７ 「 ［図：0001413822000010.jpg］ 」 （コ）以上の記載事項から引用文献２には、以下の事項が記載されていると認められる。 「分散手段２ａの分散側通信手段２１は、保守センター手段１より「戻し処理」を受信すると、前世代のソフトウェアを現世代にコピーした後、自動でソフト稼動手段（現世代）２４にて、分散手段２ａを再起動すること」 （３）対比 ア 本件補正発明と引用発明とを対比すると、後者の「制御プログラム」は前者の「プログラム」に相当し、以下同様に、「ゲートウェイ１０」は「更新管理装置」に、「ＥＣＵ３０」は「電子制御装置」に、「プログラム更新システム」は「更新システム」に、「更新プログラムΔ１～Δ３」は「更新データ」に、「記憶部３３」は「記憶部」に、「ＥＣＵ３０」は「自装置」に、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理の「処理」は「第１の切替処理」に、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理の「戻す処理」は「第２の切替処理」に、「起動部３５」は「切替部」に、「ゲートウェイ１０の処理部」は「要求部」に、それぞれ相当する。 上記アの相当関係を踏まえると以下のことがいえる。 イ 後者の「制御対象である車載装置を制御するための処理をＣＰＵ３１に実行させるための制御プログラムの更新を管理するゲートウェイ１０と、前記制御対象である車載装置を制御するための処理を実行する複数のＥＣＵ３０を含むプログラム更新システム」は前者の「所定の制御を実現するためのプログラムの更新を管理する更新管理装置と、前記プログラムを実行する複数の電子制御装置を含む更新システム」に相当する。 ウ 後者の「複数のＥＣＵ３０のうち、１つ以上のＥＣＵ３０」は前者の「前記複数の電子制御装置のうち、１つ以上の電子制御装置」に相当し、後者の「１つ以上の更新前の制御プログラムと、前記ゲートウェイ１０がＤＬサーバ６から取得した更新プログラムΔ１～Δ３に基づく１つ以上の更新後の制御プログラムとを記憶する記憶部３３」は、前者の「１つ以上の更新前のプログラムと、前記更新管理装置が取得した更新データに基づく１つ以上の更新後のプログラムとを記憶する記憶部」に相当する。 エ 後者の「１つ以上の動作させようとする制御プログラムを、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理」は前者の「自装置が実行する前記１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理」と「１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える第２の切替処理」という限りにおいて一致する。 後者の「リプロモード移行要求S７を再送信」することは前者の「第２の切替要求の実行が要求された」ことに相当する。 そうすると、後者の「前記ＥＣＵ３０のＣＰＵ３１を動作させる１つ以上の制御プログラムを、１つ以上の更新前の制御プログラムから１つ以上の更新後のプログラムに切り替える処理と、前記ゲートウェイ１０の処理部からリプロモード移行要求Ｓ７が再送信された場合に、１つ以上の動作させようとする制御プログラムを、１つ以上の更新後のプログラムから１つ以上の更新前のプログラムに戻す処理を実行する起動部３５」と、前者の「自装置が実行する１つ以上の対象プログラムを、前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替える第１の切替処理と、前記更新管理装置から第２の切替処理の実行が要求された場合に、自装置が実行する前記１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理とを実行する切替部」とは、「自装置が実行する１つ以上の対象プログラムを、前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替える第１の切替処理と、前記更新管理装置から第２の切替処理の実行が要求された場合に、１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理とを実行する切替部」という限りにおいて一致する。 オ 後者の「いずれかの前記ＥＣＵ１～３において、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間に、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合」は前者の「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合」と「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの更新に失敗した場合」において一致する。 後者の「前記ゲートウェイ１０は、いずれかの前記ＥＣＵ１～３において、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間に、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合に、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理をした起動部３５に、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理の実行を含むリプロモード移行要求Ｓ７を再送信するゲートウェイ１０の処理部を備える」ことは前者の「前記更新管理装置は、前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、前記１つ以上の電子制御装置のうち、前記１つ以上の対象プログラムを前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替えた電子制御装置に、前記第２の切替処理の実行を要求する要求部を備える」ことと、上記エを踏まえると、「前記更新管理装置は、前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの更新に失敗した場合に、前記１つ以上の電子制御装置のうち、前記１つ以上の対象プログラムを前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替えた電子制御装置に、前記第２の切替処理の実行を要求する要求部を備える」ことにおいて一致する。 カ そうすると、両者は、 「所定の制御を実現するためのプログラムの更新を管理する更新管理装置と、前記プログラムを実行する複数の電子制御装置を含む更新システムであって、 前記複数の電子制御装置のうち、１つ以上の電子制御装置は、 １つ以上の更新前のプログラムと、前記更新管理装置が取得した更新データに基づく１つ以上の更新後のプログラムとを記憶する記憶部と、 自装置が実行する１つ以上の対象プログラムを、前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替える第１の切替処理と、前記更新管理装置から第２の切替処理の実行が要求された場合に、１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える第２の切替処理を実行する切替部と、を備え、 前記更新管理装置は、 前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの更新に失敗した場合に、前記１つ以上の電子制御装置のうち、前記１つ以上の対象プログラムを前記１つ以上の更新前のプログラムから前記１つ以上の更新後のプログラムに切り替えた電子制御装置に、前記第２の切替処理の実行を要求する要求部を備える、 更新システム。」 において一致し、以下の各点で相違すると認められる。 ＜相違点１＞ 切替部が、本件補正発明では、前記更新管理装置から第２の切替処理の実行が要求された場合に、「自装置が実行する」前記１つ以上の対象プログラムを、前記１つ以上の更新後のプログラムから前記１つ以上の更新前のプログラムに切り替える前記第２の切替処理を実行するものであって、第２の切替処理の実行により切り替えられた対象プログラムを「自装置が実行する」のに対して、引用発明では、「リプロモード移行要求Ｓ７」の「再送信」により、更新前の制御プログラムに戻した後に、当該更新前の制御プログラムが実行されるか不明である点。 ＜相違点２＞ 切替部が、１つ以上の更新後のプログラムへの更新に失敗した場合における「更新」に失敗が、本件補正発明では、「切り替え」に失敗であるのに対して、引用発明では、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合である点。 （４）相違点の判断 ＜相違点１について＞ ア 引用文献１の段落【００７３】に、ロールバック処理を実行させることにより、「複数領域ＥＣＵ１～３の同時更新中においていずれかのＥＣＵ１～３における書き換え処理が中断した場合に、すべてのＥＣＵ１～３を動作保障されている現状の旧バージョンに戻すことができる。」と記載され、段落【００７４】に「旧バーションの制御プログラムで動作するＥＣＵ３０と新バーションの制御プログラムで動作するＥＣＵ３０とが混在することにより、動作保障されていない制御プログラムが同時に動作して動作不良となるのを未然に防止することができる。」と記載されていることから、すべてのＥＣＵ１～３を動作保障されている現状の旧バージョンに戻して、旧バージョンの制御プログラムでＥＣＵ３０を動作させることが示唆されているといえる。 イ また、引用文献１の段落【００１６】には「本実施形態のプログラム更新システムではこの場合、基本的に中断点から再開させるが、場合によっては、すぐに車両を動かす必要がある事態が生じる。ゲートウェイの処理部が上記のロールバック処理を実行すると、短時間で復帰できる。」と記載されており、すぐに車両を動かす必要がある場合には、ゲートウェイの処理部が上記のロールバック処理を実行することにより、中断点から再開させる場合よりも短時間で復帰できて、すぐに車両を動かすことができる（つまり、旧バージョンの制御プログラムでＥＣＵ３０を動作させること。）と解することが相当であるといえる。 ウ そうすると、引用発明において、上記引用文献１の段落【００７３】、【００７４】及び【００１６】の記載（以下「引用文献１に記載された事項１」という。）に基いて、「リプロモード移行要求Ｓ７」の「再送信」による「ロールバック処理」に含まれる「ロールバック」により、更新前の制御プログラムに戻した後に、当該更新前の制御プログラムが実行されること、つまり、相違点１に係る本件補正発明の発明特定事項とすることは、当業者が容易に想到し得たことである。 エ 仮に相違点１に係る本件補正発明の発明特定事項とすることが引用発明及び引用文献１に記載された事項１に基いて当業者が容易に想到し得たことでなかったとしても、引用文献２には、上記（２）イ（コ）で述べたように「分散手段２ａの分散側通信手段２１は、保守センター手段１より「戻し処理」を受信すると、分散手段２ａは、前世代のソフトウエアを現世代にコピーした後、自動でソフト稼動手段（現世代）２４にて、分散手段２ａを再起動すること」という事項が記載されている。 本件補正発明と引用文献２の上記事項とを対比すると、後者の「分散手段２ａ」は前者の「自装置」及び「電子制御装置」に相当し、以下同様に、「保守センター手段１」は「更新管理装置」に、「戻し処理」は「第２の切替処理」に、「受信」することは「要求された場合」に、「前世代のソフトウエア」は「更新前のプログラム」に、それぞれ相当する。 また、後者の「前世代のソフトウエアを現世代にコピー」することは前者の「更新後のプログラムから更新前のプログラムに切り替える第２の切替処理を実行すること」ことに相当する。 さらに、後者において「現世代にて分散手段２ａを再起動する」ことにより、更新前のプログラムが実行されることを意味していることは明らかである。 そうすると、本件補正発明に倣って整理すると、引用文献２には、以下の事項が記載されているといえる。 「更新管理装置から第２の切替処理の実行が要求された場合に、自装置が実行する対象プログラムを更新後のプログラムから更新前のプログラムに切り替える第２の切替処理を実行し、更新前のプログラムを実行すること」（以下「引用文献２に記載された事項」という。） オ そして、引用発明と引用文献２に記載された事項とは、更新管理装置と電子制御装置とを含む更新システムという点で技術分野が共通し、自装置が実行する対象プログラムの更新という機能についても共通しているから、引用発明及び引用文献２に記載された事項に基いて、更新前のプログラムを実行すること、つまり、相違点１に係る本件補正発明の発明特定事項とすることは、当業者が容易に想到し得たことである。 ＜相違点２について＞ ア 引用発明における「車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合」も、プログラムの「更新」の失敗であり、広義では、プログラムの「切り替え」の失敗ともいえるから、相違点２は、実質的な相違点とはいえない。 イ 仮に、本件補正発明の「切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合」を「切替部が」「実行する対象プログラムを更新前のプログラムから更新後のプログラムに切り替えること（アクティベート）に失敗した場合」と解せるとして、以下に検討する。 ウ 引用発明を開示する引用文献１の図６の〔複数領域ＥＣＵによる書き換え処理〕においては、段落【００６４】に「ＥＣＵ３０の起動部３５は、起動時において制御プログラムの動作領域を主領域１，２のいずれかに選択可能である。ここでは、プログラム更新前の通常モードにおいて、動作領域として主領域１が選択されているものとする。なお、図６中のハッチング付きの領域は制御プログラムが実行されるアクティブな領域を示す。」と記載され、段落【００６６】に「主領域２に対する制御プログラムの書き換えが完了すると、起動部３５は、通常モードにおける起動時の動作領域を主領域２に切り替えるとともに、書き換えの完了通知をゲートウェイ１０に送信する。」と記載されており、主領域２に対する制御プログラムの書き換えが完了すると、起動部３５は、制御プログラムが実行されるアクティブな領域（動作領域）を主領域２に切り替えることが開示されているといえる。 エ 引用文献１には、段落【００７２】に「ｔ９≦ｔ＜ｔ１１の期間中だけでなく、ｔ０≦ｔ＜ｔ９或いはｔ１１≦ｔ＜ｔ１３の期間中に、電源失陥などの障害に伴う中断時点ｔｐを検出した場合でも、ゲートウェイ１０は同様のロールバック処理を実行する。」と記載され、段落【００７３】に「本実施形態のプログラム更新システムでは、いずれかのＥＣＵ１～３において途中で更新が中断した場合に、すべてのＥＣＵ１～３に更新をやり直させるロールバック処理を実行する。」と記載されており、引用文献１には「ｔ０≦ｔ＜ｔ１３の期間中（リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知Ｓ９，Ｓ１１，Ｓ１３の受信を検出するまでの間）に、途中で更新が中断した場合に、ロールバック処理を実行する」こと（以下「引用文献１に記載された事項２」という。）が記載されていると認められる。そして、段落【００６６】に記載されるように、リプロモード移行要求Ｓ７の送信時点ｔ０から、すべての完了通知の受信を検出するまでの間において、起動部３５は、制御プログラムが実行されるアクティブな領域（動作領域）を主領域２に切り替えること（実行する対象プログラムを更新前のプログラムから更新後のプログラムに切り替えること）を含むものであるから、引用発明において上記引用文献１に記載された事項２を考慮して、起動部３５がアクティブな領域（動作領域）の切り替えに失敗した場合を、車両１の電源失陥などの、制御プログラムの書き込みを阻害する障害を検出した場合や途中で更新が中断した場合と同様に、１つ以上の更新前の制御プログラムから１つ以上の更新後の制御プログラムに切り替える処理をした起動部３５に、１つ以上の更新後の制御プログラムから１つ以上の更新前の制御プログラムに戻す処理を実行する条件に含めるようにして、相違点２に係る本件補正発明の発明特定事項とすることは、当業者が容易に想到し得たことである。 そして、本件補正発明の効果について検討しても、引用発明及び引用文献１に記載された事項１、引用発明及び引用文献２に記載された事項、引用発明、引用文献１に記載された事項１及び引用文献１に記載された事項２、又は、引用発明、引用文献２に記載された事項及び引用文献１に記載された事項２に基いて予期される以上の格別のものがあるとはいえない。 （５）請求人の主張の検討 ア 審判請求書において、請求人は、本件補正発明の「更新プログラムの切り替え」は、実行する対象プログラムを更新前のプログラムから更新後のプログラムに切り替えること（アクティベート）を指し、引用文献１、２には、「更新後のプログラムへの切り替え（アクティベート）に失敗した場合」に関して、開示も示唆もない旨主張する。 イ 主張の検討 （ア）本願の明細書には、ＥＣＵ１１１のプログラムの更新の失敗の例として、段落【０１３７】には、「例えば、ＥＣＵ１１１が、図８のステップＳ８０４ａにおいて、第２の記憶領域３３３に更新後のプログラムを記憶しているとき、又は、ステップＳ８０５ａにおいてブート情報を更新する前に、車両１０がＩＧ－ＯＦＦの状態に移行したものとする。」と例示されているが、プログラムの更新の失敗に関して、「アクティベート」の例は、記載されていない。 そうすると、プログラムの更新の失敗として「実行する対象プログラムを更新前のプログラムから更新後のプログラムに切り替えること」は、広義の意味での「プログラムの切り替え」と解するのが相当であり、「アクティベート」と限定して解釈すべき根拠はみあたらない。 （イ）仮に、「アクティベート」と限定して解釈した場合については、上記（４）＜相違点２について＞イに示したとおりである。 （ウ）したがって、請求人の上記主張は採用することができない。 （６）まとめ 以上より、本件補正発明は、引用発明及び引用文献１に記載された事項１、引用発明及び引用文献２に開示記載された事項、引用発明、引用文献１に記載された事項１及び引用文献１に記載された事項２、又は、引用発明、引用文献２に記載された事項及び引用文献１に記載された事項２に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。 そうすると、本件補正発明は、特許出願の際独立して特許を受けることができるものではない。 よって、本件補正は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 第３ 本願発明について １ 本願発明 本件補正は上記のとおり却下されたので、本件補正前の本願の請求項１に係る発明（以下「本願発明」という。）は、「第２ １（２）」に示したとおりのものと認められる。 ２ 原査定の拒絶の理由 原査定の拒絶の理由の概要は、以下のとおりである。 （進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 記 ・請求項 １－７ ・引用文献等 １、２ ＜引用文献等一覧＞ １．特開２０１７－１５７００４号公報（上記第２ ２（２）アの引用文献１と同じ） ２．特開２００４－１２６９６０号公報（上記第２ ２（２）イの引用文献２と同じ） ３ 引用文献とその記載事項等 原査定の拒絶の理由に引用された引用文献、その記載事項及び引用発明は、上記「第２ ２（２）ア、イ」に記載したとおりである。 ４ 対比・判断 「第２ ２」を参照すると、本件補正発明は、本願発明を特定するために必要な事項である「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記記憶部が、１つ以上の更新後のプログラムの少なくとも一部の記憶に失敗した場合、または、前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、」との記載事項から選択的記載事項である下線部分を削除して、「前記１つ以上の電子制御装置のうち少なくとも１つの電子制御装置の前記切替部が、１つ以上の更新後のプログラムへの切り替えに失敗した場合に、」との記載事項に限定したものであるから、本願発明は、本件補正発明に上記選択的記載事項を付加したものである。 そうすると、本願発明の発明特定事項をすべて含み、さらに限定を付した本件補正発明が、引用発明及び引用文献１に記載された事項１、引用発明及び引用文献２に開示記載された事項、引用発明、引用文献１に記載された事項１及び引用文献１に記載された事項２、又は、引用発明、引用文献２に記載された事項及び引用文献１に記載された事項２に基いて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、当業者が容易に発明をすることができたものである。 ５ むすび 以上のとおり、本願発明は、引用発明及び引用文献１に記載された事項１、引用発明及び引用文献２に開示記載された事項、引用発明、引用文献１に記載された事項１及び引用文献１に記載された事項２、又は、引用発明、引用文献２に記載された事項及び引用文献１に記載された事項２に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、本願は、その余の請求項を検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。