拒絶査定不服の審決｜不服2018-12269 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 5項独立特許用件特許、登録しない。 H04L 審判査定不服 2項進歩性特許、登録しない。 H04L
管理番号	1360870
審判番号	不服2018-12269
総通号数	245
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2020-05-29
種別	拒絶査定不服の審決
審判請求日	2018-09-12
確定日	2020-03-13
事件の表示	特願2016-136232「車載通信システム」拒絶査定不服審判事件〔平成30年 1月11日出願公開、特開2018- 7211〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	第1 手続の経緯本願は,平成28年7月8日の出願(以下,願書に最初に添付された明細書を「本件明細書」という。)であって,その手続の経緯は以下のとおりである。平成29年11月27日付け拒絶理由通知書平成30年 1月19日意見書,手続補正書の提出平成30年 6月 5日付け拒絶査定(以下,「原査定」という。 ) 平成30年 9月12日審判請求書,手続補正書の提出平成30年12月27日上申書の提出第2 平成30年9月12日にされた手続補正についての補正の却下の決定 [補正の却下の決定の結論] 平成30年9月12日にされた手続補正(以下,「本件補正」という。)を却下する。 [理由] 1 本件補正について (1)補正後の特許請求の範囲の記載本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された(下線部は,補正箇所である。) 「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システムであって、前記識別子として第1識別子が付された第1信号を符号化することなく出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え、前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから符号化されることなく出力された第2信号を受信し、前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部を含む車載通信システム。」 (2)本件補正前の特許請求の範囲本件補正前の,平成30年1月19日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。「複数のノード間で互いに異なる識別子が付された複数の信号の通信がなされる車載通信システムであって、前記識別子として第1識別子が付された第1信号を符号化することなく出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え、前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから符号化されることなく出力された第2信号を受信し、前記第1ノードは、前記第2信号に前記第1識別子が付されているならば、前記車載通信システムの異常を通知するために符号化された通知信号を生成する信号生成部を含む車載通信システム。」 2 補正の適否本件補正は,補正前の請求項1に記載された発明を特定するために必要な事項である「前記第2信号」に付される「前記第1識別子」,及び,「前記車載通信システムの異常を通知するために符号化された通知信号を生成する」ことについて,それぞれ,「前記第1ノードを表す前記第1識別子と同一の第1識別子」であること,及び,「前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する」との限定を付加するものであって,補正前の請求項1に記載された発明と補正後の請求項1に記載される発明との産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。そこで,本件補正後の請求項1に記載される発明(以下,「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。 (1)本件補正発明本件補正発明は,上記1(1)に記載したとおりのものである。 (2)引用文献の記載事項ア引用文献1 (ア)原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,中野学他3名,自動車の情報セキュリティ,日経BP社,2013年12月27日,初版,pp.156-165(以下,「引用文献1」という。)には,図面とともに,次の記載がある。(下線は,当審で付与した。以下同じ。) 「4.5 CANの不正送信阻止 CANの特徴である一斉送受信機能を利用し,自らが送信するIDのメッセージをほかのECUが送信した場合,これを不正メッセージとして処理するのが不正送信阻止方式である^(4-23?25)。不正メッセージの送信を検知したECUは,即座にエラーフレームを送信することで不正メッセージの送信が完了する前にこれを破棄する。特徴は,不正に送信されるデータフレームの送信自体を阻止することができる点にある。なお,不正送信阻止方式はメッセージ送信機能をもつ全てのECUに適用できるが,特に重要なメッセージ送信を中断させるためには,フレーム単位ではなく,ビット単位での処理が必要になる。さらに一般にはエラーフレームの送信処理はCANコントローラで実施するため,CANコントローラに新しく機能を追加する必要がある。 4.5.1 前提条件不正送信阻止方式は,メッセージごとに送信ECUを一意に識別できることが前提条件になる。最も単純な方法は,メッセージのIDをECUごとに割り当てて,IDごとに送信ECUが一意に決まるようにシステムを設計する方法である。この方法以外にも,IDごとにデータ長を示すDLC(Daｔa Lengｔh Cｏde)の値を組み合わせることで識別することもできる。同一IDでもDLCが異なるメッセージを複数のECUに割り当てておけば,IDとDLCの情報を用いて送信ECUを一意に判断できる。当然,CANのデータ本体であるデータフィールドの値まで含めることで同一のIDとDLCのメッセージを送るECUを一意に判断できる可能性はある。ただし,データフィールドの値まで利用すると実装コストや汎用性の点で問題がある。さらに,CANプロトコルではIDによって通信調停を行っているため,同一IDのメッセージを同じバス上の異なるECUから同時に送信することを禁止している。従って,自動車分野ではECUごとに異なるIDを割り振ることが多く,以下の条件を前提に置くことは現実的である(図23)。【前提条件1】あるIDのデータフレームを送信するECUは,ネットワーク上に一つしか存在しない。一方で,CANの上位プロトコルの一部では,同一IDを用いてリクエストとレスポンスを行う必要がある。それ以外にも同一IDを複数のECUが送信する必要がある場合などでは,次の前提条件を設定する。【前提条件2】同一IDとDLCのデータフレームを送信するECUがネットワーク上に二つ以上存在しない。不正送信阻止方式では,正規の送信ECUがバス上のメッセージを監視し,送信途中のメッセージがなりすましメッセージであると判別できることが肝になる。前提条件を利用してなりすましメッセージを判別するが,以下では前提条件1のIDのみを用いてなりすましメッセージを判別する場合を考える(図24)。 4.5.2 メカニズム 4.5.2.1 エラーフレーム送信のタイミング正規の送信ECUが不正なメッセージ送信を検知するには,自らが送信していないときに,自らが送信するIDのメッセージがバスに流れているかを監視する必要がある。自らの送信IDリストとバスに流れるメッセージのIDを照合し,不正送信されていないかを検証することを「IDチェック」と定義する。一般にCANのデータフレームにおけるIDフィールド以降ならば,IDチェックやエラーフレームをタイミングを任意に決められる。不正送信阻止方式では,IDチェックするタイミングを変えることで,得られる成果が異なってくる。」「4.5.2.3 通知機能不正送信阻止方式では,CANコントローラ内部で判断して処理する。このため,不正送信が発生した場合には阻止したことをユーザに通知する機能が重要である。この方式で対処すると不正メッセージ自体が打ち消されるため,ユーザは不正メッセージによって攻撃を受けたことに気づかないおそれがある。不正メッセージ自体がなくなるので,攻撃がされてもシステムに誤動作は起きないと考えられるが,安全面を第一に考えると,攻撃された時にシステムを停めるべきである。不正送信を阻止するタイミングによって通知できる情報は異なるが,攻撃されたことや,なりすましの対象になったIDフィールドやデータフィールドの値などをマイコンに通知することはできる。」上記記載から,引用文献1には以下の発明(以下,「引用発明」という。)が記載されている。「CANの不正送信阻止方式を採用したシステムであって, 自動車分野で,ECUごとに異なるIDを割り振ることとし,あるIDのデータフレームを送信するECUは,ネットワーク上に一つしか存在しないとし, 正規の送信ECUが不正なメッセージ送信を検知するには,自らが送信していないときに,自らが送信するIDのメッセージがバスに流れているかを監視し,自らが送信するIDのメッセージをほかのECUが送信した場合,これを不正メッセージとして処理して,不正に送信されるデータフレームの送信自体を阻止し, 不正送信阻止方式では,CANコントローラ内部で判断して処理するため,不正送信が発生した場合には,阻止したことをユーザに通知する機能が重要な, システム。」イ引用文献2 (ア)原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,国際公開第2015/151418号(以下,「引用文献2」という。)には,図面とともに,次の記載がある。「技術分野 [0001] 本開示は、電子制御ユニットが通信を行う車載ネットワーク等において送信された不正なフレームを検知して対処する技術に関する。背景技術 [0002] 近年、自動車の中のシステムには、電子制御ユニット(ECU:Electronic Control Unit)と呼ばれる装置が多数配置されている。これらのECUをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ISO11898-1で規定されているCAN(Controller Area Network)という規格が存在する(「非特許文献1」参照)。 [0003] CANでは、通信路は2本のバスで構成され、バスに接続されているECUはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、2本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「1」の値と、ドミナントと呼ばれる「0」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを6biｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。 [0004] またCANでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージIDと呼ばれるIDを付けて送信し(つまりバスに信号を送出し)、各受信ノードは予め定められたメッセージIDのみを受信する(つまりバスから信号を読み取る)。また、CSMA/CA(Carrier SenseMultiple Access/Collision Avoidance)方式を採用しており、複数ノードの同時送信時にはメッセージIDによる調停が行われ、メッセージIDの値が小さいフレームが優先的に送信される。」「[0027] (実施の形態1) 以下、本開示の実施の形態として、メッセージIDを用いて他のノード(ECU)において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ECUを含む車載ネットワークシステム10について図面を用いて説明する。」「[0051] 1.4 ヘッドユニット200の構成] ヘッドユニット200は、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ(LCD:liquid crystal display)等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のECUである。 [0052] 図4は、ヘッドユニット200の構成図である。ヘッドユニット200は、フレーム送受信部270と、フレーム解釈部260と、受信ID判断部240と、受信IDリスト保持部250と、フレーム処理部220と、表示制御部210と、フレーム生成部230とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット200における通信回路、LCD、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。 [0053] フレーム送受信部270は、バス500cに対して、CANプロトコルに従ったフレームを送受信する。バス500cからフレームを1biｔずつ受信し、フレーム解釈部260に転送する。また、フレーム生成部230より通知を受けたフレームの内容をバス500cに1biｔずつ送信する。 [0054] フレーム解釈部260は、フレーム送受信部270よりフレームの値を受け取り、CANプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部260は、IDフィールドと判断した値は受信ID判断部240へ転送する。フレーム解釈部260は、受信ID判断部240から通知される判定結果に応じて、IDフィールドの値と、IDフィールド以降に現れるデータフィールドとを、フレーム処理部220へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する(つまりそのフレームとしての解釈を中止する)かを決定する。また、フレーム解釈部260は、例えば、CRCの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、CANプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部230へ通知する。また、フレーム解釈部260は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。 [0054] 受信ID判断部240は、フレーム解釈部260から通知されるIDフィールドの値を受け取り、受信IDリスト保持部250が保持しているメッセージIDのリストに従い、そのIDフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ID判断部240は、フレーム解釈部260へ通知する。 [0055] 受信IDリスト保持部250は、ヘッドユニット200が受信するID(メッセージID)のリストである受信IDリストを保持する。図5は、受信IDリストの一例を示した図である。ヘッドユニット200は、エンジン401に接続されたECU400aからメッセージIDが「1」であるフレーム(メッセージ)を受信し、ブレーキ402に接続されたECU400bからメッセージIDが「2」であるフレームを受信し、ドア開閉センサ403に接続されたECU400cからメッセージIDが「3」であるフレームを受信し、窓開閉センサ404に接続されたECU400dからメッセージIDが「4」であるフレームを受信する。 [0056] フレーム処理部220は、受信したフレームの内容(例えばメッセージID及びデータフィールドの内容)に基づいて、例えばLCDに表示されるべき画像を形成して、表示制御部210に通知する。なお、フレーム処理部220は、受信したデータフィールドの内容を保持し、入力手段を通じて受け付けた運転者による操作に応じて、LCDに表示されるべき画像(例えば車速表示用の画像、窓開閉状態表示用の画像等)を選択して通知しても良い。 [0057] 表示制御部210は、フレーム処理部220より通知を受けた内容をLCD等に表示する。 [0058] フレーム生成部230は、フレーム解釈部260からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部270へ通知して送信させる。」「[0094] [1.18 不正フレームの検知に係るシーケンス] 以下、上述の構成を備える車載ネットワークシステム10のバス500aに不正なECUが接続された場合について、バス500aに接続された不正検知ECU100a、ECU400a、ECU400b、ゲートウェイ300等の動作について説明する。 [0095] 図18は、不正検知ECU100aが不正なフレーム(メッセージ)を検知して、他のECUによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なECUが、バス500aにメッセージIDが「4」でデータフィールド(データ)が「255(0ｘFF)」となるデータフレームを送信する場合の例を示している。ここでの各シーケンスは、各種装置における各処理手順(ステップ)を意味する。 [0096] まず、不正なECUは、メッセージIDが「4」、データが「255(0ｘFF)」となるデータフレームの送信を開始する(シーケンスS1001)。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってSOF、IDフィールド(メッセージID)といった順に逐次バス500a上に送出される。 [0097] 不正なECUがIDフィールド(メッセージID)までをバス500aに送出し終えたときにおいて、不正検知ECU100a、ECU400a、ECU400b及びゲートウェイ300はそれぞれメッセージIDを受信する(シーケンスS1002)。 [0098] ECU400a、ECU400b及びゲートウェイ300はそれぞれ、保持している受信IDリストを用いてメッセージIDをチェックする(シーケンスS1003)。このとき、不正検知ECU100aは、保持している正規IDリストを用いてメッセージIDをチェックする(シーケンスS1004)。即ち、不正検知ECU100aは、送信されたフレームにおけるIDフィールドの内容が、不正を示す所定条件(正規IDリストに掲載されていないこと)に該当するか否かを判定する。 [0099] シーケンスS1003において、ECU400a及びECU400bは、それぞれが保持している受信IDリストに「4」が含まれていないため(図9参照)、受信を終了する。つまりこれ以上不正なECUが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、シーケンスS1003においてゲートウェイ300は、保持している受信IDリストに「4」が含まれているため(図5参照)、受信を継続する。また、シーケンスS1004において不正検知ECU100aは、保持している正規IDリストに「4」が含まれていないため、不正なメッセージIDであると判断して、続いてエラーフレームの発行準備を開始する(シーケンスS1005)。 [0100] シーケンスS1003に続いて、ゲートウェイ300はフレームの受信を継続する。例えば、不正検知ECU100aがエラーフレームの発行準備をしている間に、不正なECUからはバス500a上にIDフィールドより後の部分であるRTR、コントロールフィールド(IDE、ｒ、DLC)が逐次送出され、続いてデータフィールドが1ビットずつ逐次送出される。ゲートウェイ300はこのRTR、コントロールフィールド(IDE、ｒ、DLC)を受信し、続いてデータフィールドの受信を開始する(シーケンスS1006)。 [0101] 次にエラーフレームの発行準備が終わって、不正検知ECU100aがエラーフレームを送信する(シーケンスS1007)。このエラーフレームの送信は、不正なフレームの最後尾が送信される前(例えばCRCシーケンスの最後尾が送信される前等)に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス500aでは、不正なECUから送信中のフレームのデータフィールドの途中部分がエラーフレーム(優先されるドミナントのビット列)により上書きされることになる。 [0102] シーケンスS1007において送信されたエラーフレームを受信したゲートウェイ300は、データフィールドの受信途中で不正なECUが送信していたフレームの受信を中止する(シーケンスS1008)。つまり、ゲートウェイ300は、不正なECUからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なECUが送信していたフレームの受信を継続しない。 [0103] 不正検知ECU100aは、エラーフレームを送信する対象となったデータフレームのメッセージID「4」に対応する不正検知カウンタをインクリメントする(シーケンスS1009)。 [0104] インクリメントした結果としてメッセージID「4」に対応する不正検知カウンタが17以上となった場合、不正検知ECU100aは、ヘッドユニット200に受信されるようにエラー表示を通知するフレーム(エラー表示メッセージ)を送信する(シーケンスS1010)。この結果としてヘッドユニット200のフレーム処理部220によってエラー表示のための処理がなされLCD等を介してエラーが報知される。なお、エラーの報知は、LCD等への表示の他、音声出力、発光等によるものでも良い。」上記記載から,引用文献2には以下の事項(以下,「引用文献2記載事項」という。)が記載されている。「車載ネットワークのCANにおいて,不正を検知したECUが,ECUの一種であるヘッドユニット200に受信されるようにエラー表示を通知するフレーム(エラー表示メッセージ)を送信し,ヘッドユニット200のフレーム処理部220によってエラー表示のための処理がなされLCD等を介してエラーが報知されること。」ウ引用文献3 (ア)原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,特開2013-98719号公報(以下,「引用文献3」という。)には,図面とともに,次の記載がある。「【技術分野】【0001】本発明は、通信システムにおけるメッセージ認証技術に関する。【背景技術】【0002】車載ネットワークとしてCAN(Controller Area Network)が採用されている。このCANにはOBD2ポートと呼ばれる診断用のポートが設けられており、ネットワーク上を流れるメッセージを受信したり、ネットワーク上にメッセージを送信したりすることができる。」「【課題を解決するための手段】【0010】本発明に係るメッセージ認証方法では、メインメッセージと、メインメッセージのメッセージ認証コード(Message Authentication Code: MAC)を含むMACメッセージを送信する。受信側では、メインメッセージから算出されるMACとMACメッセージに含まれるMACが一致すればメインメッセージが正当なものであり、不一致であれば不正なものであると判断できる。本発明においては、以下のようにしてMACを生成する点に特徴がある。」「【0014】このような本発明によると、CANプロトコルに適用可能な方式で、MACによってメインメッセージの正当性を検証することができる。たとえば、不正機器が以前に受信したメインメッセージと対応するMACメッセージを送信した場合であっても、再送時にはカウンタ値が変化しているため正しいMACも変化している。したがって、不正機器がリプレイ攻撃を行っても、受信ノードにおいてメインメッセージが不正であることを検知できる。【0015】また、本発明では、メインメッセージは平文の状態でネットワーク上を伝送するため不正機器がメインメッセージを知ることができるが、カウンタ値はネットワーク上を伝送せず不正機器には未知である。したがって、メインメッセージおよびMACメッセージを盗聴しても、そこからMACを生成するための暗号アルゴリズムや暗号鍵を推測できないという利点もある。」「【0034】なお、本実施形態において、全てのメッセージについてMACによるメッセージ認証を行う必要はない。すなわち、重要なメッセージについてのみメッセージ認証を行っても良い。そして、メッセージ認証が必要ないメッセージのみを送受信するECUについては、図4に示したようなメッセージ認証のための各機能部は不要である。」「【0039】 (メッセージ送信時処理) まず、メインメッセージを送信するECUが行う処理を、図5および図6を参照しつつ説明する。図5は、送信ECUにおける各機能部の連携を示す図である。図6は、メインメッセージ送信時の処理の流れを示すフローチャートである。【0040】メインメッセージ生成部9は、CAN IDおよびデータフィールドを含むメインメッセージを生成してCANに送信する。図6のフローチャートには、メインメッセージを送信した後の処理の流れが示されている。メインメッセージを送信すると、CAN ID抽出部6がメインメッセージ生成部9から送信したメインメッセージのCAN IDを抽出する(S101)。CAN ID抽出部6は、メインメッセージのCAN IDに対応するカウンタ値をカウンタ記憶部3から読み取り(S102)、カウンタを1つ増加させてカウンタ記憶部3を更新する(S103)。抽出されたCAN IDおよび更新後のカウンタ値は、MAC生成部4に送られる。【0041】また、データフィールド抽出部7は、メインメッセージ生成部9が送信したメインメッセージのデータフィールドを抽出する(S104)。抽出されたデータフィールドは、MAC生成部4に送られる。【0042】 MAC生成部4は、暗号鍵記憶部5から暗号鍵(共通鍵)を取り出し(S105)、この暗号鍵を用いて、CAN ID、最新のカウンタ値、送信済みのデータフィールドからMACを生成する(S106)。なお、上述したように本実施形態ではAESを採用しているため暗号アルゴリズムの出力は128ビットであるが、CANのデータフレームが送れるデータフィールドは64ビットである。したがって、システム内で共通するルールに従って出力の128ビットから64ビットを抽出する。例えば、前半64ビットや後半64ビットを採用しても良いし、奇数ビットや偶数ビットを採用しても良い。さらには、CAN IDが奇数か偶数かによって、前半64ビットを採用するか後半64ビットを採用するか、あるいは奇数ビットを採用するか偶数ビットを採用するかなどを決めても構わない。【0043】 MAC生成部4が生成したMACはMACメッセージ生成部1へ送られ(S107)、MACメッセージ生成部1がMACをCANメッセージ(MACメッセージ)に加工してCANに送信する。すなわち、計算された64ビットのMACがMACメッセージのデータフィールドに格納される。また、MACメッセージのCAN IDは、メインメッセージのCAN IDに対応するIDが用いられる。メインメッセージとMACメッセージのCAN IDの対応によって、受信側ECUでは、MACメッセージを受信した場合に対応するCAN IDを有するメインメッセージに対するMACであることが把握できる。」上記記載から,引用文献3には以下の事項(以下,「引用文献3記載事項1」という。)が記載されている。「車載ネットワークとしてのCANに流れるメインメッセージをECUが送信する際,MACによってメインメッセージの正当性を検証するために,CAN IDおよびデータフィールドを含むメインメッセージを生成してCANに送信し,送信したメインメッセージのデータフィールドを抽出し,暗号鍵を用いて,CAN ID,最新のカウンタ値,送信済みのデータフィールドからMACを生成し,生成されたMACをCANメッセージ(MACメッセージ)に加工してCANに送信すること。」また,引用文献3には,以下の事項(以下,「引用文献3記載事項2」という。)も記載されている。「車載ネットワークとしてのCANに流れるメッセージについて,全てのメッセージをMACによるメッセージ認証を行う必要は無く,重要なメッセージのみMACによるメッセージ認証を行えば良いこと。」さらに,引用文献3には,以下の事項(以下,「引用文献3記載事項3」という。)も記載されている。「車載ネットワークとしてのCANに流れるメッセージについて,メインメッセージは平文の状態でネットワーク上を伝送すること。」エ周知技術 (ア)引用文献4 本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である,畑正人他4名,不正送信阻止:CANではそれが可能である,情報処理学会,2011年10月12日,第2011巻,第3号,p624-629(以下,「引用文献4」という。なお,引用文献4は,上記引用文献1の「参考文献4-24」である。)には,図面とともに,次の記載がある。「1 はじめに現代の自動車は,車内の様々な機器の制御を担うECU(Elecｔｒｏnic Cｏnｔｒｏl Uniｔ)を多数搭載し,それらを接続する車載ネットワークとして,CAN(Cｏnｔｒｏlleｒ Aｒea Neｔｗｏｒk)を導入していることが多い.CANの導入により高度な制御が行うことができ,セーフティの向上やコスト面などで多くの利点がある.しかし,CANを導入することによる新たな脅威も知られている.例えば,文献[1]では攻撃者が車載ネットワークに直接アクセスできる環境において,ECUの書き換え等の攻撃により,運転者が意図しない動作を発生させられることを実際の自動車を用いて実証している.また,文献[2]では攻撃者が車載ネットワークに直接アクセスできない状況でもオーディオシステムやBlｕeｔｏｏｔh,携帯電話などを介して侵入することで自動車の制御を乗っ取ることが可能であることが実証されている.文献[3]では,攻撃者がメッセージの挿入を行うことで,パワーウィンドウやエアバッグ制御システムなどの機能が正常に動作しなくなることをシミュレータやデモシステムで示している.これ以外にも多くの文献で車載ネットワークの脆弱性について言及されており,早急な対応が必要といえる. 自動車は多数の機器からなる複雑なシステムであり,多様なセキュリティ上の課題が考えられるが,最も大きな課題の1つに,CANの脆弱性が挙げられる.CANは,バスネットワークを想定しており,やりとりされるメッセージ(CANではフレームとよぶ)には送信元や宛先情報が含まれず,メッセージは全てバス上にブロードキャストされる.当該バスに接続されたノード(ECU)は,任意のメッセージを送信することができるため,バス内のECUが一度不正侵入されると,このECUが他の重要な制御を行うECUになりすまして,様々な不正を行うことができる.そこで本稿では,CANの特徴であるブロードキャスト通信を利用し,不正メッセージがバス上に送信されていることを,なりすましの対象となったノード自身が検知し,エラーメッセージを送ることで,偽装メッセージの送信が完了する前にこれを破棄する“不正送信阻上方式”を提案する. 本稿の構成は以下のとおりである.2章で関連研究を紹介する.3章でCANについて述べ,4章でCANにおける問題点と脅威についてまとめる.その後,5章で不正送信阻止方式の提案を行い,6章で考察として評価を行い,そして7節でまとめと今後の課題とする.」(第624頁左欄1行ないし第625頁左欄20行) 「4 CANにおける問題点と脅威 4.1 CANにおけるセキュリティ上の問題車載ネットワークで用いられているCANプロトコルには,以下のようなセキュリティ上の問題点が存在する. ●メッセージに送信元情報や認証などのセキュリティ機能が含まれていないため,なりすましが容易に行える. ●バス型であるため,すべてのECUにメッセージが送信される.従って盗聴や解析などが容易に行える. 既存の研究では,上記に挙げたような車載ネットワークの脆弱性が指摘されており,それらを悪用することにより4.2節で述べる脅威が想定される. 4.2 CANにおける脅威 ●盗聴 CANプロトコルは守秘性がなく,バス型でメッセージがブロードキャストされるため容易に盗聴が可能である.また,OBD-IIポートからある程度のメッセージを受信することが可能である. ●不正メッセージの送信 OBD-IIポートや不正ECUの接続,正規ECUの改ざんによりバス上に任意のメッセージを挿入することが可能であるため,他のECUになりすまして不正メッセージを送信することができる.特に,CANでは,全てのメッセージを観測できるため,受信した正規メッセージを再度バス上に送信する再送攻撃が容易に行える. ●DｏS(Denial ｏf Seｒｖice)攻撃不正ECUによりバスを継続的にドミナント状態にしたり,優先度の高い不正メッセージを連続送信したりすることで,他のメッセージの送信を妨害することが容易に可能である. 上記の脅威の中で,特に,不正メッセージの送信はECUの誤動作を招き,自動車の走行を危険な状態に陥れるため,その対策は非常に重要である.」(第626頁右欄13行ないし第627頁左欄9行) (イ)引用文献5 本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である,特開2012-155608号公報(以下,「引用文献5」という。)には,図面とともに,次の記載がある。「【技術分野】【0001】本発明は、所定のイベント発生時に、車両を制御する車載制御システムの動作状態などに関連するデータを記録する車両用データ記録装置に関する。」「【0057】また、所定の異常イベントが発生したことを車内LANを介して他のECUに通知する場合には、所定の異常イベントの発生を通知するメッセージの優先度を最も高く設定する。これにより、所定の異常イベントの発生時に、他のデータの通信に優先して、異常イベントの発生を通知するメッセージを即座に送信することができるので、遅滞なく他のECUにおいて必要なデータの記録を実行することが可能となる。ただし、異常イベントの発生を通知する場合、車内LANに加えて、専用の通信線を設け、この専用の通信線を介して通知しても良い。」 (ウ)引用文献6 本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である,特開2005-278007号公報(以下,「引用文献6」という。)には,図面とともに,次の記載がある。「【技術分野】【0001】本発明は、通信システム及び通信装置に関し、特に、冗長ビットを含む通信データを送受信する通信システム及び通信装置に関する。【背景技術】【0002】近年の情報通信技術の発達により、様々な場所において、通信ネットワークが利用されている。特に、LAN等のように通信範囲が限定された、閉じられたネットワークよりも、インターネット等のように通信範囲が限定されない、開かれたネットワークが普及している。これに伴い、ネットワークに接続された情報の盗聴や、改ざん、成りすまし等、ネットワークのセキュリティ性が問題となっている。そこで、ネットワークのセキュリティ性を向上させる技術として暗号技術の研究が盛んに行われている。【0003】一方、自動車等の車両LANの一つにCAN(Cｏnｔｒｏlleｒ Aｒea Neｔｗｏｒk)が知られている。CANは、多くの自動車内部の制御用通信方式として利用されており、車両以外にも、FAや、船舶、医療機器等にも利用されている。例えば、エンジン制御装置や、トランスミッション制御装置、ABS、ダッシュボードのメータ類、ライト、パワーウィンドウ等が、CANにより接続されている。このため、CANには、エンジン等の機器の性能に関する情報等、秘密にしたい情報が流れている。【0004】 CANは車両内に限られた、閉じられたネットワークであるため、盗聴等されること少ないが、ユーザが、ECU(ElectricControl Unit)のメンテナンス用の端子からCANに接続し、盗聴等が可能である。また、ITS(Inｔelligenｔ Tｒanｓｐｏｒｔ Sｙｓｔemｓ)の発達に伴い、CANと外部のネットワークを接続し、開かれたネットワークになることもありうる。この場合には、外部から車両内のCANに接続し、盗聴等が可能となる。」「【0032】通信装置100は、例えば、ECUであり、エンジンや、トランスミッション、ABS、ダッシュボードのメータ類、パワーウィンドウ等の制御装置である。通信装置100は、1つの装置であってもよいし、複数の装置から構成されていてもよい。通信装置100は、図に示されるように、通信制御部200とCPU300を備えている。【0033】 CPU300は、通信装置100の各種制御処理を行う処理装置である。通信装置100には、図示しない各種センサー等の検出に基づいた処理や、他の通信装置100から受信したデータに基づいた処理を行う。例えば、各種センサーが検出したデータから送信データを生成し、通信制御部200を介して他の通信装置100へ通知する。また、通信制御部200を介して他の通信装置100のデータを受信し、メータ等に出力する。【0034】通信制御部200は、CANコントローラーであり、CANバス400を介した他の通信装置100との通信の制御を行う制御装置である。また、通信制御部200は、CANプロトコルに従った通信制御の他に、通信データの暗号化/複合化を行う。例えば、CPU300の送信データを暗号化し、CANプロトコルに従って、暗号化したデータを含むデータフレームをCANバス400へ送信する。また、CANプロトコルに従って、CANバス400から、暗号化されたデータを含むデータフレームを受信し、暗号化されたデータを複合化して、CPU300へ出力する。」 (エ)周知技術上記,引用文献4及び5の記載から,以下の事項は周知の事項(以下,「周知事項1」という。」)ということができる。「制御系の車内LAN(CAN)において,不正メッセージの送信は,自動車の走行を危険な状態にするために,その対策は重要であること。」また,引用文献6の記載から,以下の事項は周知の事項(以下,「周知事項2」という。)ということができる。「自動車等の車両LANの一つであるCAN(Cｏnｔｒｏlleｒ Aｒea Neｔｗｏｒk)は,制御装置であるECU(通信装置)が接続されており, ECUは,通信制御部とCPUを備え, 通信制御部は,CANコントローラーであり,CANバスを介した他のECUとの通信の制御を行う制御装置であること。」 (3)引用発明との対比ア本件補正発明と引用発明とを対比する。 (ア)引用発明の「自動車分野で,ECUごとに異なるIDを割り振ることとし,あるIDのデータフレームを送信するECUは,ネットワーク上に一つしか存在しない」ことについて,上記記載の「ECU」は,本件補正発明の「ノード」に相当し,又,上記記載の「ECUごとに異なるIDを割り振ること」は,本件補正発明の「複数のノード間で互いに異なる識別子が付され」ることに相当する。そして,上記記載にあるように引用発明は,「自動車分野」に関する「システム」であるから,引用発明の「システム」は,本件補正発明の「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システム」に相当する。 (イ)引用発明の「あるIDのデータフレームを送信する」ことと,本件補正発明の「前記識別子として第1識別子が付された第1信号を符号化することなく出力する」ことは,「前記識別子として第1識別子が付された第1信号を」「出力する」点で共通する。そして,引用発明の「正規の送信ECU」は,「あるIDのデータフレームを送信」しているのであるから,周知事項2(引用文献6参照。)にあるように,送信のための何らかの構成,すなわち「通信制御部(CANコントローラ)」を備えていると認められる。そうすると,引用発明の「正規の送信ECU」と本件補正発明の「ノード」とは,「前記識別子として第1識別子が付された第1信号を」「出力する通信部を有する」点で共通する。してみると,引用発明に備えられた「正規の送信ECU」の1つと本件補正発明の「前記識別子として第1識別子が付された第1信号を符号化することなく出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え」ることは,「前記識別子として第1識別子が付された第1信号を」「出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え」る点で共通する。 (ウ)引用発明は,「正規の送信ECU」は,「自らが送信していないときに,自らが送信するIDのメッセージがバスに流れているかを監視し,自らが送信するIDのメッセージをほかのECUが送信した場合,これを不正メッセージとして処理して,不正に送信されるデータフレームの送信自体を阻止し」ているのであるから,「ほかのECU」からのメッセージを受信しているといえ,又,そのために上記(イ)で検討した「通信制御部(CANコントローラ)」を用いていると認められる。そうすると,引用発明の「通信制御部(CANコントローラ)」と,本件補正発明の「前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから符号化されることなく出力された第2信号を受信」することとは,「前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから」「出力された第2信号を受信」している点で共通する。 (エ)引用発明の「正規の送信ECU」が「自らが送信していないときに,自らが送信するIDのメッセージがバスに流れているかを監視し,自らが送信するIDのメッセージをほかのECUが送信した場合」は,本件補正発明の「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されている」場合に相当する。そして,引用発明は,上記の場合「正規の送信ECU」の「通信制御部(CANコントローラ)」は,「不正送信が発生した場合に,阻止したことをユーザに通知し」ているから,この通知は「異常通知信号」であるといえる。そうすると,引用発明の上記「通知」を生成することと,本件補正発明の「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する」こととは,「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、」「異常通知信号を生成する」点で共通する。そして,引用発明は上記「通知」を生成するための信号生成手段を当然備えていると認められるから,引用発明の「通知」を生成するための信号生成手段と,本件補正発明の「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」は,「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、」「異常通知信号を生成する信号生成部」である点で共通する。 (オ)してみると,本件補正発明と引用発明は,以下の点で一致し,又相違する。 [一致点] 「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システムであって, 前記識別子として第1識別子が付された第1信号を出力する通信部を有する第1ノードを,前記複数のノードのうち1つとして備え, 前記通信部は,前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから出力された第2信号を受信し, 前記第1ノードは,前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば,異常通知信号を生成する信号生成部を含む, 車載通信システム。」 [相違点1] 「前記識別子として第1識別子が付された第1信号を出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え」る点について,本件補正発明は「前記識別子として第1識別子が付された第1信号を符号化することなく出力する通信部を有する第1ノードを、前記複数のノードのうち1つとして備え」ているのに対して,引用発明の出力される「データフレーム」は,符号化を行っているのか否か記載されていない点。 [相違点2] 「前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから出力された第2信号を受信」する点について,本件補正発明は,「前記通信部は、前記複数のノードのうち他のもう1つとして前記車載通信システムに組み込まれた第2ノードから符号化されることなく出力された第2信号を受信」しているのに対して,引用発明の受信する「データフレーム」は,符号化されているのか否か記載されていない点。 [相違点3] 「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」について,本件補正発明が「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」であるのに対して,引用発明の「通知」を生成するための信号生成手段により生成された「通知」が「前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号」であると特定されていない点。 (4)判断以下,各相違点について検討する。ア [相違点1]及び[相違点2]について引用文献3記載事項3にあるように,車載ネットワークのCANに流れるメッセージは,平文,即ち,符号化されていない信号である。また,引用文献3記載事項1及び2にあるように,引用文献3では,暗号鍵をもちいて符号化された信号(即ち「MAC」)も,車載ネットワークのCANに流れているが,重要であるメッセージについてのみ符号化することが記載されている。そして,引用発明では,「正規の送信ECU」の「通信制御部(CANコントローラ)」は,「不正送信が発生した場合には,阻止したことをユーザに通知する機能が重要」であるとし,又,上記周知事項1(引用文献4及び5参照。)にあるように「車内LAN(CAN)において,不正メッセージの送信は,自動車の走行を危険な状態にするために,その対策は重要である」ことは周知の事項であるから,「阻止したことをユーザに通知」する信号とそれ以外の信号は重要度が異なることは明らかである。してみると,「阻止したことをユーザに通知」する信号以外の信号を,上記引用文献3記載事項3にあるように,平文即ち,符号化されていない信号とすることは,符号化にかかるコストとの関係で当業者が適宜選択する事項である。そして,引用発明の「メッセージ」を,上記引用文献3記載事項1ないし3及び上記周知事項1に基づいて,「前記識別子として第1識別子が付された第1信号を符号化することなく出力する」こととし,又,「前記車載通信システムに組み込まれた第2ノードから符号化されることなく出力された第2信号を受信」することとし,引用発明の「通信制御部(CANコントローラ)」を[相違点1]及び[相違点2]に係る構成とすることは,当業者が容易に想到することである。イ [相違点3]について引用発明の「不正送信が発生した場合には,阻止したことをユーザに通知」する際に,引用文献2記載事項にあるようにECUの一種であるヘッドユニットに受信されるようにエラー表示を通知することは公知の事項であって,引用発明のユーザへの通知において,引用文献2記載の公知技術を採用することに格別の困難性は認められない。その際に,ヘッドユニットはECUの一つとして構成されるのであるから,CAN上を流れる「阻止したことをユーザに通知」する信号は,CANのプロトコルに従ったメッセージとなることは明らかである。そして,上記アで検討したように,「阻止したことをユーザに通知」する信号は重要な信号であり,この重要な信号について,引用文献3記載事項1にあるような信号,即ち暗号化された信号(「MAC」)を付加することは当業者が容易に想到することである。加えて,暗号化された信号(「MAC」)については,復号のための鍵を有していないECU,即ち不正に接続されたECUは復号できず,一方,復号のための鍵を有しているECU,即ち正規のECUであれば,当然に復号でき,「認識可能」であることは明らかである。また,本件明細書には,本件補正発明の「前記第1ノードは、前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する」点について,＜第2実施形態＞(【0079】ないし【0083】)において, 「【0079】第1実施形態と同様に、ECU200Aに割り当てられた識別子が、受信部212によって受け取られたパケット信号に付されているならば、判定部220Aは、トリガ信号を生成する。トリガ信号は、判定部220Aから通知信号生成部241へ出力される。通知信号生成部241は、トリガ信号に応じて、通知信号を生成する。通知信号生成部241は、ECU200Aに割り当てられた識別子と、ECU200Aに割り当てられた識別子を表すデータと、を通知信号に組み込む。通知信号は、通知信号生成部241から符号化部243へ伝達される。本実施形態において、メッセージは、ECU200Aに割り当てられた識別子を表すデータによって例示される。【0080】符号化部243は、復号部232が復号に利用した鍵と同一の鍵を用いて、通知信号を符号化する。この結果、MACが、通知信号に組み込まれる。既知の様々な符号化技術が、通知信号へのMACの組み込みに利用可能である。本実施形態の原理は、特定の符号化技術に限定されない。【0081】符号化された通知信号は、符号化部243から送信部211へ伝達される。送信部211は、符号化された通知信号をバス120へ出力する。【0082】図2を参照して説明された通信システム101に関して、ECU111が、符号化された通知信号をバス120へ出力すると、ECU112,113,114それぞれの復号部232は、通知信号を復号することができる。この結果、ECU112,113,114は、所定の警告動作を実行することができる。一方、不正なECU115は、復号部232を有さない、或いは、復号のための共通鍵を有していない。したがって、ECU115は、通知信号を復号できず、通知信号の内容を把握することができない。この結果、ECU115は、通知信号を無効化する不正な動作を実行することはできない。本実施形態において、第3ノードは、ECU112,113,114のうち1つによって例示される。【0083】通知信号は、MACの分だけ、パケット信号生成部242によって生成されるパケット信号よりもビット数において大きい。しかしながら、ビット数において大きい信号の通信は、不正アクセスの存在下でのみ生ずるので、通信負荷は、過度に大きくならない。」と記載されているように,本件補正発明の「前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号」は,通知信号に組み込まれた,ECU200Aに割り当てられた識別子と、ECU200Aに割り当てられた識別子を表すデータを暗号化したMACの部分であることを含むと認められる。そうすると,引用発明の「阻止したことをユーザに通知」する信号を生成する信号生成手段を,上記引用文献2記載事項及び上記引用文献3記載事項1ないし3及び上記周知事項1に基づいて,「前記第2信号に前記第1ノードを表す前記第1識別子と同一の第1識別子が付されているならば、前記第2ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」とし,[相違点3]に係る信号生成部とすることは,当業者が容易に想到することである。なお,仮に,「符号化された異常通知信号」が「全体が符号化された異常通知信号」を意味するとしても,信号のどの範囲を暗号化(すなわち「符号化」)するかは,セキュリティの程度や処理コスト等に応じて,当業者が適宜選択すべき設計選択事項である。ウそして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,引用発明及び引用文献2ないし5に記載された技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。エしたがって,本件補正発明は,引用発明及び引用文献2及び3に記載された技術並びに周知事項に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができないものである。 3 本件補正についてのむすびよって,本件補正は,特許法第17条の2第6項において準用する同法126条第7項の規定に違反するので,同法159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。第3 本願発明について 1 本願発明平成30年9月12日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成30年1月19日にされた手続補正により補正された特許請求の範囲の請求項1ないし6に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,その請求項1に記載された事項により特定される,前記第2[理由]1(2)に記載のとおりのものである。 2 原査定の拒絶の理由原査定の拒絶の理由は,この出願の請求項1ないし6に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。＜引用文献等一覧＞ 1.中野学他,自動車の情報セキュリティ,日経BP社,2013年12月27日,初版,pp.156-165 2.国際公開第2015/151418号 3.特開2013-098719号公報 3 引用文献原査定の拒絶の理由で引用された引用文献1ないし3及びその記載事項は,前記第2の[理由]2(2)に記載したとおりである。 4 対比・判断本願発明は,前記第2の[理由]2で検討した本件補正発明から,「前記第2信号」に付される「前記第1識別子」,及び,「前記車載通信システムの異常を通知するために符号化された通知信号を生成する」ことに係る限定事項を削除したものである。そうすると,本願発明の発明特定事項を全て含み,さらに他の事項を付加したものに相当する本件補正発明が,前記第2の[理由]2(3),(4)に記載したとおり,引用発明及び引用文献2及び3に記載された技術並びに周知事項に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,引用発明及び引用文献2及び3に記載された技術並びに周知事項に基づいて,当業者が容易に発明をすることができたものである。第4 むすび以上のとおり,本願発明は,特許法第29条第2項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。よって,結論のとおり審決する。
審理終結日	2020-01-07
結審通知日	2020-01-14
審決日	2020-01-27
出願番号	特願2016-136232(P2016-136232)
審決分類	P 1 8・ 121- Z (H04L) P 1 8・ 575- Z (H04L)
最終処分	不成立
前審関与審査官	速水雄太、中川幸洋、玉木宏治
特許庁審判長	稲葉和生
特許庁審判官	野崎大進小田浩
発明の名称	車載通信システム
代理人	小谷悦司
代理人	小谷昌崇
代理人	渡邉耕平

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