• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 発明同一 取り消して特許、登録 H04L
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
管理番号 1378691
審判番号 不服2020-9636  
総通号数 263 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-11-26 
種別 拒絶査定不服の審決 
審判請求日 2020-07-09 
確定日 2021-10-26 
事件の表示 特願2017- 11621「車載ネットワークシステム」拒絶査定不服審判事件〔平成30年 8月 2日出願公開、特開2018-121220、請求項の数(4)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成29年1月25日の出願であって、その手続の経緯は以下のとおりである。
令和 2年 1月23日付け:拒絶理由通知書
平成 2年 3月10日 :意見書の提出
令和 2年 4月 2日付け:拒絶査定
令和 2年 7月 9日 :拒絶査定不服審判の請求
令和 3年 6月 8日付け:拒絶理由(当審拒絶理由)通知書
令和 3年 8月 2日 :意見書、手続補正書の提出

第2 原査定の概要
原査定(令和2年4月2日付け拒絶査定)の概要は、この出願の請求項1-6に係る発明は、その出願の日前の特許出願であって、その出願後に出願公開がされた特願2015-223105号(特開2017-92807号)の願書に最初に添付された明細書、特許請求の範囲又は図面に記載された発明と同一であり、しかも、この出願の発明者がその出願前の特許出願に係る上記の発明をした者と同一ではなく、またこの出願の時において、その出願人が上記特許出願の出願人と同一でもないので、特許法第29条の2の規定により、特許を受けることができない、というものである。

第3 当審拒絶理由の概要
当審が令和3年6月8日付けで通知した拒絶理由(以下、「当審拒絶理由」という。)の概要は次のとおりである。

1 理由1(サポート要件)
この出願は、特許請求の範囲の記載が、特許法第36条第6項第1号に規定する要件を満たしていない。
請求項1に係る発明の解決しようとする課題は、発明の詳細な説明の段落【0006】に記載されている「あるノードから複数のノードに送信されるデータが複数のノードの各々で正常に受信できたか否かの検証に要する時間をより短縮する」ことを可能とすることであるものと、一応解される。
しかしながら、請求項1に記載されている発明特定事項により、何故、上記課題を解決することができるのか、については、本願明細書の記載からは不明である。
また、請求項1の記載に、上記と異なる他の課題の解決手段が反映されていると認めることもできない。
したがって、請求項1は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲のものとはいえず、発明の詳細な説明に記載した範囲を超えて特許を請求するものである。

2 理由2(拡大先願)
この出願の下記の請求項に係る発明は、その出願の日前の特許出願であって、その出願後に出願公開がされた特願2015-223105号(特開2017-92807号)の願書に最初に添付された明細書又は図面に記載された発明と同一であり、しかも、この出願の発明者がその出願前の特許出願に係る上記の発明をした者と同一ではなく、またこの出願の時において、その出願人が上記特許出願の出願人と同一でもないので、特許法第29条の2の規定により特許を受けることができない。

第4 本願発明
本願請求項1?4に係る発明(以下、それぞれ「本願発明1」?「本願発明4」という。)は、令和3年8月2日に提出された手続補正書により補正された特許請求の範囲の請求項1?4に記載された事項により特定される発明であり、それらのうちの本願発明1は、次のとおりの発明である(下線は補正箇所を示す。)。
「【請求項1】
1つの第1ノードと、複数の第2ノードと、を含む車載ネットワークシステムであって、
前記第1ノードに設けられ、前記複数の第2ノードの各々に所定のデータを一斉送信する第1送信部と、
前記第1ノードに設けられ、前記第1送信部により前記複数の第2ノードの各々に前記所定のデータが一斉送信された場合に、前記複数の第2ノードの各々により前記所定のデータが正常に受信されたか否かを検証するための検証用データを、前記複数の第2ノードの各々に一斉送信する第2送信部と、
前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記所定のデータを受信する第1受信部と、
前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記検証用データを受信する第2受信部と、
前記複数の第2ノードの各々に設けられ、前記第1受信部が受信した前記所定のデータと、前記第2受信部が受信した前記検証用データとに基づき、前記第1受信部が受信した前記所定のデータが正常に受信されたか否かを検証する検証部と、
前記複数の第2ノードの各々に設けられ、前記検証部による検証結果を前記第1ノードに送信する第3送信部と、を備える、
車載ネットワークシステム。」

また、本願発明2?4は、本願発明1を減縮した発明である。

第5 当審拒絶理由の理由1(サポート要件)について
令和3年8月2日に提出された手続補正書により補正された特許請求の範囲の請求項1には、「前記複数の第2ノードの各々に所定のデータを一斉送信する」こと、及び、「検証用データを、前記複数の第2ノードの各々に一斉送信する」ることが記載されている。
この点について、発明の詳細な説明の段落【0064】?【0065】の記載等(「マスタECU11から複数のスレーブECU12の各々に同一のデータを一斉送信する場合に、複数のスレーブECU12の各々により同一のデータが正常に受信されたか否かの検証に要する時間をより短縮することができる。」との記載等)を参酌すると、請求項1に係る発明は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲のものと理解できる。
したがって、当審拒絶理由の理由1(上記第3の1)は解消した。

第6 先願明細書等の記載、先願発明
1 先願明細書等の記載
当審拒絶理由で引用された特願2015-223105号(特開2017-92807号)の願書に最初に添付された明細書、特許請求の範囲又は図面(以下、「先願明細書等」という。)には、以下の事項が記載されている(下線は当審による。)。

「【0010】
<第1実施形態>
図1は、車載ネットワークシステム1の概要を示す模式図である。この車載ネットワークシステム1は、図1に示すように、検査装置として構成されるGW10と、自動車Vに搭載される電子機器である各種のECU20とが、ネットワークを介して接続された構成である。本実施形態のGW10は、車載ネットワークシステム1内のサブネットワーク間の通信を中継したり、車載ネットワークシステム1と車外のネットワークとの間の通信を中継したりといった本来のゲートウェイとしての機能に加えて、通信するECU20同士が共有している事前共有鍵を検査する機能を有する。なお、車載ネットワークシステム1の通信規格としては、例えば、CANやFlexRay(登録商標)など、車載ネットワークの規格として公知のものを利用できる。」

「【0014】
本実施形態の車載ネットワークシステム1では、同じグループに属するECU20同士が同じ事前共有鍵を共有する。事前共有鍵は、例えば、車載ネットワークシステム1を搭載する自動車Vの組み立て時や出荷時などに、作業者によって各ECU20に設定されてもよいし、GW10がネットワークを通じて各ECU20に配布する構成であってもよい。GW10は、これらECU20のグループごとに設定される事前共有鍵を管理している。つまり、GW10は各ECU20と事前共有鍵を共有している。そして、自動車Vが出荷されて実際に運転を開始するタイミング、例えば自動車Vのイグニッションキーがオンされたときなどに、GW10が、グループごとの事前共有鍵から派生するセッション鍵を各ECU20に配布する。この際、GW10は、セッション鍵の配布を通じて各ECU20が記憶する事前共有鍵の検査を行う。そして、事前共有鍵が異常であると判定されたECU20が見つかると、GW10はエラー信号を出力して適切な対応を促すようにしている。」

「【0017】
図3は、本実施形態のGW10の機能的な構成例を示すブロック図である。本実施形態のGW10は、事前共有鍵の検査に関わる機能的な構成要素として、例えば図3に示すように、記憶部110と、送受信部120と、生成部130と、判定部140と、エラー出力部150と、を備える。
【0018】
記憶部110は、グループ管理情報を記憶する。グループ管理情報は、上述したECU20のグループごとに設定される事前共有鍵を管理するための情報である。図4は、記憶部110が記憶するグループ管理情報の一例を示す図である。この図4のグループ管理情報30は、グループに割り当てられたグループIDに対応付けて、そのグループに属するECU20それぞれに割り当てられた機器IDの集合と、そのグループに対して設定された事前共有鍵とを格納している。事前共有鍵を更新する場合は、新たな事前共有鍵がグループに属するECU20に配布されるとともに、グループ管理情報30の事前共有鍵が新たな事前共有鍵に書き換えられる。
【0019】
送受信部120は、GW10がネットワークを介してECU20と通信するモジュールであり、サブモジュールとして、セッション鍵送信部121と、検証結果受信部122と、を含む。
【0020】
セッション鍵送信部121は、後述の生成部130が生成した暗号化データ(セッション鍵を事前共有鍵で暗号化したデータ)と、ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさを検証するための検証用データとを、グループ単位で各ECU20に送信する。例えば、セッション鍵送信部121は、暗号化データおよび検証用データに対してグループIDを付加してネットワーク上にブロードキャストする処理を、グループ数分繰り返す。ネットワークに接続されている各ECU20は、GW10のセッション鍵送信部121により送信される暗号化データおよび検証用データに付加されたグループIDが、自身が属するグループに対応したものである場合に、その暗号化データおよび検証用データを受信する。
【0021】
なお、セッション鍵送信部121が暗号化データおよび検証用データに対して付加するデータは、ECU20がネットワーク上にブロードキャストされた暗号化データおよび検証用データを受信すべきか否かを判断できるデータであればよく、グループIDに限らない。例えば、グループIDの代わりにグループに属するECU20間で送受信される上述の制御信号を付加してもよいし、グループに属するECU20の機器IDの集合を付加してもよい。また、暗号化データと検証用データは必ずしも同時に送信する必要はなく、暗号化データと検証用データとを異なるタイミングで送信してもよい。」

「【0025】
判定部140は、検証結果受信部122がECU20から受信した検証結果データに基づいて、ECU20が記憶している事前共有鍵が正常か否かを判定する。すなわち、判定部140は、検証結果受信部122がECU20から受信した検証結果データが検証成功である場合、このECU20が記憶している事前共有鍵は正常であると判定する。一方、判定部140は、検証結果受信部122がECU20から受信した検証結果データが検証失敗である場合、このECU20が記憶している事前共有鍵は異常であると判定する。」

「【0035】
次に、本実施形態のECU20の概要を説明する。図5は、本実施形態のECU20の機能的な構成例を示すブロック図である。本実施形態のECU20は、事前共有鍵の検査に関わる機能的な構成要素として、例えば図5に示すように、送受信部210と、検証部220と、記憶部230と、を備える。
【0036】
送受信部210は、ECU20がネットワークを介してGW10と通信するモジュールであり、サブモジュールとして、セッション鍵受信部211と、検証結果送信部212と、を含む。
【0037】
セッション鍵受信部211は、GW10のセッション鍵送信部121が送信した暗号化データおよび検証用データに付加されたグループIDが、当該ECU20が属するグループに対応したものである場合に、その暗号化データおよび検証用データを受信する。なお、暗号化データおよび検証用データに制御信号が付加されている場合は、セッション鍵受信部211は、その制御信号が、当該ECU20が他のECU20との間で送受信する制御信号であれば、暗号化データおよび検証用データを受信する。また、暗号化データおよび検証用データに機器IDの集合が付加されている場合は、セッション鍵受信部211は、その機器IDの集合に、当該ECU20に割り当てられた機器IDが含まれていれば、暗号化データおよび検証用データを受信する。
【0038】
検証結果送信部212は、検証部220による検証結果を示す検証結果データ、つまり、復元したセッション鍵が正しかったことを示す検証成功、あるいは、復元したセッション鍵が正しくなかったことを示す検証失敗をGW10に送信する。
【0039】
検証部220は、セッション鍵受信部211が受信した暗号化データを、記憶部230が記憶する事前共有鍵を用いて復号し、GW10が配信するセッション鍵を復元する。そして、検証部220は、セッション鍵受信部211が受信した検証用データを用いて、復元したセッション鍵が正しいかどうかを検証し、復元したセッション鍵が正しい場合、復元したセッション鍵を記憶部230に格納する。また、検証部220は、セッション鍵の正しさを検証した結果を送受信部210に通知する。これにより、検証部220による検証結果を示す検証結果データが、検証結果送信部212からGW10に送信される。」

「【図1】



「【図3】



「【図5】



2 先願発明
上記1から、先願明細書等には、次の発明(以下、「先願発明」という。)が記載されていると認められる。
「検査装置として構成されるGW10と、自動車Vに搭載される電子機器である各種のECU20とが、ネットワークを介して接続された車載ネットワークシステム1であって(【0010】)、
GW10は、車載ネットワークシステム1と車外のネットワークとの間の通信を中継する機能を有し、
同じグループに属するECU20同士が同じ事前共有鍵を共有し、GW10は、セッション鍵の配布を通じて各ECU20が記憶する事前共有鍵の検査を行い、
GW10は、送受信部120と、判定部140とを備え、
送受信部120は、セッション鍵送信部121と、検証結果受信部122と、を含み、
セッション鍵送信部121は、暗号化データ(セッション鍵を事前共有鍵で暗号化したデータ)と、ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさを検証するための検証用データとを、グループ単位で各ECU20に送信し、例えば、セッション鍵送信部121は、暗号化データおよび検証用データに対してグループIDを付加してネットワーク上にブロードキャストする処理を、グループ数分繰り返し、
暗号化データと検証用データは必ずしも同時に送信する必要はなく、暗号化データと検証用データとを異なるタイミングで送信してもよく、
判定部140は、ECU20から受信した検証結果データが検証成功である場合、このECU20が記憶している事前共有鍵は正常であると判定し、一方、ECU20から受信した検証結果データが検証失敗である場合、このECU20が記憶している事前共有鍵は異常であると判定し、
ECU20は、送受信部210と、検証部220とを備え、
送受信部210は、セッション鍵受信部211と、検証結果送信部212と、を含み、
セッション鍵受信部211は、GW10のセッション鍵送信部121が送信した暗号化データおよび検証用データに付加されたグループIDが、当該ECU20が属するグループに対応したものである場合に、その暗号化データおよび検証用データを受信し、
検証結果送信部212は、検証部220による検証結果を示す検証結果データ、つまり、復元したセッション鍵が正しかったことを示す検証成功、あるいは、復元したセッション鍵が正しくなかったことを示す検証失敗をGW10に送信し、
検証部220は、セッション鍵受信部211が受信した暗号化データを事前共有鍵を用いて復号し、GW10が配信するセッション鍵を復元し、そして、検証部220は、セッション鍵受信部211が受信した検証用データを用いて、復元したセッション鍵が正しいかどうかを検証し、セッション鍵の正しさを検証した結果を送受信部210に通知し、これにより、検証部220による検証結果を示す検証結果データが、検証結果送信部212からGW10に送信される、
車載ネットワークシステム1。」

第7 当審拒絶理由の理由2(拡大先願)について
1 本願発明1について
(1)対比
ア 本願発明1と先願発明とを対比すると、次のことがいえる。

(ア)先願発明の「ECU20」は、「各種」のものであって、「同じグループに属するECU20同士が同じ事前共有鍵を共有」するから、「複数」であり、一方、「GW10」は、「セッション鍵の配布を通じて各ECU20が記憶する事前共有鍵の検査を行」うから、「複数」の「ECU20」に共通の、「1つ」のものである。
また、「車載ネットワークシステム1」は、「GW10」と「各種のECU20」とが、「ネットワークを介して接続された」ものであるから、「GW10」と「ECU20」とを「含む」ものである。
そして、先願発明の「GW10」、「ECU20」は、それぞれ、本願発明1の「第1ノード」、「第2ノード」に相当する。
以上のことから、先願発明は、本願発明1の「1つの第1ノードと、複数の第2ノードと、を含む車載ネットワークシステム」に相当する構成を有している。

(イ)先願発明の「GW10」は、「送受信部120」を備えるものであり、当該「送受信部120」が含む「セッション鍵送信部121」は、「暗号化データ(セッション鍵を事前共有鍵で暗号化したデータ)と、ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさを検証するための検証用データとを、グループ単位で各ECU20に送信し、例えば、セッション鍵送信部121は、暗号化データおよび検証用データに対してグループIDを付加してネットワーク上にブロードキャストする処理を、グループ数分繰り返」すものであって、「暗号化データと検証用データは必ずしも同時に送信する必要はなく、暗号化データと検証用データとを異なるタイミングで送信してもよ」いものである。
ここで、「セッション鍵送信部121」は、機能的には、「GW10」に「設けられ」、「各ECU20」に「セッション鍵を事前共有鍵で暗号化したデータ」である「暗号化データ」を「ブロードキャスト」する手段と、「GW10」に「設けられ」、「暗号化データ」を「ブロードキャスト」する手段により「各ECU20」に「暗号化データ」が「ブロードキャスト」された「場合に」、「検証用データ」を「各ECU20」に「ブロードキャスト」する手段と、からなる、ということができる。そして、それらの手段はそれぞれ、本願発明1の「第1送信部」、「第2送信部」に相当し、「暗号化データ」は、本願発明1の「所定のデータ」に相当し、また、「ブロードキャスト」することは、本願発明1の「一斉送信」に相当する。

(ウ)先願発明の「GW10」が、上記(イ)の「送受信部120」と共に備える「判定部140」は、「ECU20から受信した検証結果データが検証成功である場合、このECU20が記憶している事前共有鍵は正常であると判定し、一方、ECU20から受信した検証結果データが検証失敗である場合、このECU20が記憶している事前共有鍵は異常であると判定」するものである。
また、先願発明の「ECU20」が備える「検証部220」は、「セッション鍵受信部211が受信した暗号化データを事前共有鍵を用いて復号し、GW10が配信するセッション鍵を復元し、そして、検証部220は、セッション鍵受信部211が受信した検証用データを用いて、復元したセッション鍵が正しいかどうかを検証し、セッション鍵の正しさを検証した結果を送受信部210に通知し、これにより、検証部220による検証結果を示す検証結果データが、検証結果送信部212からGW10に送信される」ものである。
ここで、「セッション鍵受信部211が受信した暗号化データを事前共有鍵を用いて復号し、GW10が配信するセッション鍵を復元し」、「セッション鍵受信部211が受信した検証用データを用いて、復元したセッション鍵が正しいかどうかを検証」するとは、「受信した暗号化データ」そのもの及び「受信した検証用データ」そのものがいずれも正常に受信されたことを前提に、「検証用データを用いて」、「受信した暗号化データ」から「事前共有鍵」により「セッション鍵」が正しく「復元」できるか否かを「検証」する、ということであり、正しく「復元」できる場合には、「GW10」の「判定部140」が、「事前共有鍵」が「正常であると判定」し、正しく「復元」できない場合には、同じく「異常であると判定」するようにしたものである、と理解することができる。
したがって、先願発明の「ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさを検証するための検証用データ」と、本願発明1の「当該第2ノードにより当該所定のデータが正常に受信されたか否かを検証するための検証用データ」とは、「車載ネットワークシステムの正常性を検証するための検証用データ」である点で共通している。

(エ)上記(イ)、(ウ)でそれぞれ検討した点について上記(ア)を踏まえると、先願発明と本願発明1とは、
「車載ネットワークシステム」が、
「前記第1ノードに設けられ、前記複数の第2ノードの各々に所定のデータを一斉送信する第1送信部と、
前記第1ノードに設けられ、前記第1送信部により前記複数の第2ノードの各々に前記所定のデータが一斉送信された場合に、車載ネットワークシステムの正常性を検証するための検証用データを、前記複数の第2ノードの各々に一斉送信する第2送信部と、」
を備える点で共通している。

(オ)先願発明の「ECU20」は、「送受信部210」を備えるものであり、当該「送受信部210」が含む「セッション鍵受信部211」は、「GW10のセッション鍵送信部121が送信した暗号化データおよび検証用データに付加されたグループIDが、当該ECU20が属するグループに対応したものである場合に、その暗号化データおよび検証用データを受信」するものである。
ここで、「セッション鍵受信部211」は、機能的には、上記(イ)で述べた「暗号化データ」を「ブロードキャスト」する手段、「検証用データ」を「ブロードキャスト」する手段にそれぞれ対応する、「GW10」から送信される「暗号化データ」を受信する手段と、「GW10」から送信される「検証用データ」を受信する手段と、からなる、ということができる。そして、それらの手段はそれぞれ、本願発明1の「第1受信部」、「第2受信部」に相当する。

(カ)上記(ウ)のとおり、先願発明の「検証部220」は、「検証用データを用いて」、「受信した暗号化データ」から「事前共有鍵」により「セッション鍵」が正しく「復元」できるか否かを「検証」する、と理解することができるところ、このことは、換言すれば、「暗号化データ」と、「検証用データ」とに基づき、「事前共有鍵」により「セッション鍵」が正しく「復元」できるか否かを「検証」するということである。
この点について上記(オ)も踏まえると、本願発明1の「前記第1受信部が受信した前記所定のデータと、前記第2受信部が受信した前記検証用データとに基づき、前記第1受信部が受信した前記所定のデータが正常に受信されたか否かを検証する検証部」に関して、先願発明と本願発明1とは、「前記第1受信部が受信した前記所定のデータと、前記第2受信部が受信した前記検証用データとに基づき、車載ネットワークシステムの正常性を検証する検証部」である点で共通している。

(キ)先願発明の「ECU20」は、「送受信部210」を備えるものであり、当該「送受信部210」が含む「検証結果送信部212」は、「検証部220による検証結果を示す検証結果データ、つまり、復元したセッション鍵が正しかったことを示す検証成功、あるいは、復元したセッション鍵が正しくなかったことを示す検証失敗をGW10に送信」するものである。
ここで、「検証部220による検証結果を示す検証結果データ」、「検証結果送信部212」は、それぞれ本願発明1の「検証部による検証結果」、「第3送信部」に相当する。

(ク)上記(ア)の「複数」の「ECU20」の「各々に」、上記(オ)?(キ)の「暗号化データ」を受信する手段、「検証用データ」を受信する手段、「検証部220」及び「検証結果送信部212」が「設けられ」ていることは自明である。
したがって、上記(オ)?(キ)でそれぞれ検討した点について上記(ア)で更に検討した点も踏まえると、先願発明と本願発明1とは、
「車載ネットワークシステム」が、
「前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記所定のデータを受信する第1受信部と、
前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記検証用データを受信する第2受信部と、
前記複数の第2ノードの各々に設けられ、前記第1受信部が受信した前記所定のデータと、前記第2受信部が受信した前記検証用データとに基づき、車載ネットワークシステムの正常性を検証する検証部と、
前記複数の第2ノードの各々に設けられ、前記検証部による検証結果を前記第1ノードに送信する第3送信部と、」
を備える点で共通している。

イ 上記アから、本願発明1と先願発明とは、次の点で一致する。
「1つの第1ノードと、複数の第2ノードと、を含む車載ネットワークシステムであって、
前記第1ノードに設けられ、前記複数の第2ノードの各々に所定のデータを一斉送信する第1送信部と、
前記第1ノードに設けられ、前記第1送信部により前記複数の第2ノードの各々に前記所定のデータが一斉送信された場合に、車載ネットワークシステムの正常性を検証するための検証用データを、前記複数の第2ノードの各々に一斉送信する第2送信部と、
前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記所定のデータを受信する第1受信部と、
前記複数の第2ノードの各々に設けられ、前記第1ノードから送信される前記検証用データを受信する第2受信部と、
前記複数の第2ノードの各々に設けられ、前記第1受信部が受信した前記所定のデータと、前記第2受信部が受信した前記検証用データとに基づき、車載ネットワークシステムの正常性を検証する検証部と、
前記複数の第2ノードの各々に設けられ、前記検証部による検証結果を前記第1ノードに送信する第3送信部と、を備える、
車載ネットワークシステム。」

ウ また、本願発明1と先願発明とは、次の点で相違する。
(相違点)
本願発明1では、「検証用データ」が、「前記複数の第2ノードの各々により前記所定のデータが正常に受信されたか否かを検証するための」ものであるのに対し、先願発明では、「検証用データ」が、「ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさを検証するための」ものである点。
また、これに伴い、本願発明1の「検証部」は、「前記第1受信部が受信した前記所定のデータが正常に受信されたか否かを検証する」のに対し、先願発明の「検証部220」は、「復元したセッション鍵が正しいかどうかを検証」する点。

(2)判断
そこで、上記相違点について検討する。
本願発明1と先願発明とは、「検証用データ」によって車載ネットワークシステムの正常性を検証するものである点では同一であるが、車載ネットワークシステムにおける検証の対象が異なり、本願発明1は、「複数の第2ノードの各々」により「所定のデータ」が「正常に受信されたか否か」を検証するものである一方、先願発明は、「ECU20が事前共有鍵を用いて暗号化データを復号することによって復元したセッション鍵の正しさ」を検証するものであって、「暗号化データ」が「正常に受信されたか否か」を検証するものではない。
そして、上記の差異は、実質的なものであって、本願発明1は、先願発明に、何らかの周知技術の付加又は周知技術による転換を行ったものであるとはいえず、本願発明1は、先願発明と別異の効果を奏するものである。
よって、本願発明1は、先願発明と実質的に同一であるとはいえない。

2 本願発明2?4について
本願発明2?4は、本願発明1を減縮した発明である。そうすると、本願発明2?4も本願発明1と同様の理由により、先願発明と実質的に同一であるとはいえない。

3 小括
以上のとおりであるから、本願発明1?4は当審拒絶理由の理由2(上記第3の2)は解消した。

第8 原査定について
本願発明1?4が、特願2015-223105号(特開2017-92807号)の願書に最初に添付された明細書又は図面に記載された発明と同一であるとはいないことは、上記第7のとおりであるから、原査定を維持することはできない。

第9 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2021-10-05 
出願番号 特願2017-11621(P2017-11621)
審決分類 P 1 8・ 537- WY (H04L)
P 1 8・ 161- WY (H04L)
最終処分 成立  
前審関与審査官 玉木 宏治  
特許庁審判長 稲葉 和生
特許庁審判官 野崎 大進
富澤 哲生
発明の名称 車載ネットワークシステム  
代理人 伊東 忠彦  
代理人 伊東 忠彦  
代理人 伊東 忠重  
代理人 伊東 忠重  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ