【事件の表示】
　特願２０１６−１３６２３２「車載通信システム」拒絶査定不服審判事件〔平成３０年　１月１１日出願公開、特開２０１８−　　７２１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成２８年７月８日の出願（以下，願書に最初に添付された明細書を「本件明細書」という。）であって，その手続の経緯は以下のとおりである。
　平成２９年１１月２７日付け　　　拒絶理由通知書
　平成３０年　１月１９日　　　　　意見書，手続補正書の提出
　平成３０年　６月　５日付け　　　拒絶査定（以下，「原査定」という。
　　　　　　　　　　　　　　　　　）
　平成３０年　９月１２日　　　　　審判請求書，手続補正書の提出
　平成３０年１２月２７日　　　　　上申書の提出
第２　平成３０年９月１２日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３０年９月１２日にされた手続補正（以下，「本件補正」という。）を却下する。
［理由］
１　本件補正について
（１）補正後の特許請求の範囲の記載
　本件補正により，特許請求の範囲の請求項１の記載は，次のとおり補正された（下線部は，補正箇所である。）
「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システムであって、
　前記識別子として第１識別子が付された第１信号を符号化することなく出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え、
　前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから符号化されることなく出力された第２信号を受信し、
　前記第１ノードは、前記第２信号に
前記第１ノードを表す前記第１識別子と同一の第１識別子
前記第２ノード以外のノードが
認識可能な符号化された異常
　車載通信システム。」
（２）本件補正前の特許請求の範囲
　本件補正前の，平成３０年１月１９日にされた手続補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。
「複数のノード間で互いに異なる識別子が付された複数の信号の通信がなされる車載通信システムであって、
　前記識別子として第１識別子が付された第１信号を符号化することなく出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え、
　前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから符号化されることなく出力された第２信号を受信し、
　前記第１ノードは、前記第２信号に前記第１識別子が付されているならば、前記車載通信システムの異常を通知するために符号化された通知信号を生成する信号生成部を含む
　車載通信システム。」
２　補正の適否
　本件補正は，補正前の請求項１に記載された発明を特定するために必要な事項である「前記第２信号」に付される「前記第１識別子」，及び，「前記車載通信システムの異常を通知するために符号化された通知信号を生成する」ことについて，それぞれ，「
前記第１ノードを表す前記第１識別子と同一の第１識別子
前記第２ノード以外のノードが
認識可能な符号化された異常
　そこで，本件補正後の請求項１に記載される発明（以下，「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。
（１）本件補正発明
　本件補正発明は，上記１（１）に記載したとおりのものである。
（２）引用文献の記載事項
ア　引用文献１
（ア）原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，中野学　他３名，自動車の情報セキュリティ，日経ＢＰ社，２０１３年１２月２７日，初版，pp.156-165（以下，「引用文献１」という。）には，図面とともに，次の記載がある。（下線は，当審で付与した。以下同じ。）
「４．５　
ＣＡＮの不正送信阻止
　ＣＡＮの特徴である一斉送受信機能を利用し，
自らが送信するＩＤのメッセージをほかのＥＣＵが送信した場合，これを不正メッセージとして処理するのが不正送信阻止方式である４−２３〜２５。
不正に送信されるデータフレームの送信自体を阻止する
　なお，不正送信阻止方式はメッセージ送信機能をもつ全てのＥＣＵに適用できるが，特に重要なメッセージ送信を中断させるためには，フレーム単位ではなく，ビット単位での処理が必要になる。さらに一般にはエラーフレームの送信処理はＣＡＮコントローラで実施するため，ＣＡＮコントローラに新しく機能を追加する必要がある。
４．５．１　前提条件
　不正送信阻止方式は，メッセージごとに送信ＥＣＵを一意に識別できることが前提条件になる。最も単純な方法は，メッセージのＩＤをＥＣＵごとに割り当てて，
ＩＤごとに送信ＥＣＵが一意に決まるようにシステムを設計する
　さらに，ＣＡＮプロトコルではＩＤによって通信調停を行っているため，同一ＩＤのメッセージを同じバス上の異なるＥＣＵから同時に送信することを禁止している。従って，
自動車分野ではＥＣＵごとに異なるＩＤを割り振る
【前提条件１】
　
あるＩＤのデータフレームを送信するＥＣＵは，ネットワーク上に一つしか存在しない。
　一方で，ＣＡＮの上位プロトコルの一部では，同一ＩＤを用いてリクエストとレスポンスを行う必要がある。それ以外にも同一ＩＤを複数のＥＣＵが送信する必要がある場合などでは，次の前提条件を設定する。
【前提条件２】
　同一ＩＤとＤＬＣのデータフレームを送信するＥＣＵがネットワーク上に二つ以上存在しない。
　不正送信阻止方式では，正規の送信ＥＣＵがバス上のメッセージを監視し，送信途中のメッセージがなりすましメッセージであると判別できることが肝になる。前提条件を利用してなりすましメッセージを判別するが，以下では前提条件１のＩＤのみを用いてなりすましメッセージを判別する場合を考える（図２４）。
４．５．２　メカニズム
４．５．２．１　エラーフレーム送信のタイミング
　
正規の送信ＥＣＵが不正なメッセージ送信を検知するには，自らが送信していないときに，自らが送信するＩＤのメッセージがバスに流れているかを監視する
　一般にＣＡＮのデータフレームにおけるＩＤフィールド以降ならば，ＩＤチェックやエラーフレームをタイミングを任意に決められる。不正送信阻止方式では，ＩＤチェックするタイミングを変えることで，得られる成果が異なってくる。」
「４．５．２．３　通知機能
　
不正送信阻止方式では，ＣＡＮコントローラ内部で判断して処理する。このため，不正送信が発生した場合には阻止したことをユーザに通知する機能が重要である。
　不正メッセージ自体がなくなるので，攻撃がされてもシステムに誤動作は起きないと考えられるが，安全面を第一に考えると，攻撃された時にシステムを停めるべきである。不正送信を阻止するタイミングによって通知できる情報は異なるが，攻撃されたことや，なりすましの対象になったＩＤフィールドやデータフィールドの値などをマイコンに通知することはできる。」
　上記記載から，引用文献１には以下の発明（以下，「引用発明」という。）が記載されている。
「ＣＡＮの不正送信阻止方式を採用したシステムであって，
　自動車分野で，ＥＣＵごとに異なるＩＤを割り振ることとし，あるＩＤのデータフレームを送信するＥＣＵは，ネットワーク上に一つしか存在しないとし，
　正規の送信ＥＣＵが不正なメッセージ送信を検知するには，自らが送信していないときに，自らが送信するＩＤのメッセージがバスに流れているかを監視し，自らが送信するＩＤのメッセージをほかのＥＣＵが送信した場合，これを不正メッセージとして処理して，不正に送信されるデータフレームの送信自体を阻止し，
　不正送信阻止方式では，ＣＡＮコントローラ内部で判断して処理するため，不正送信が発生した場合には，阻止したことをユーザに通知する機能が重要な，
　システム。」
イ　引用文献２
（ア）原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，国際公開第２０１５／１５１４１８号（以下，「引用文献２」という。）には，図面とともに，次の記載がある。
「技術分野
[0001]　本開示は、電子制御ユニットが通信を行う車載ネットワーク等において送信された不正なフレームを検知して対処する技術に関する。
背景技術
[0002]　近年、
自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。
最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８−１で規定されているＣＡＮ（Controller Area Network）という規格が存在する
[0003]　ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信する送信ノードは、２本のバスに電圧をかけ、バス間で電位差を発生させることによって、レセシブと呼ばれる「１」の値と、ドミナントと呼ばれる「０」の値を送信する。複数の送信ノードが全く同一のタイミングで、レセシブとドミナントを送信した場合は、ドミナントが優先されて送信される。受信ノードは、受け取ったフレームのフォーマットに異常がある場合には、エラーフレームと呼ばれるフレームを送信する。エラーフレームとは、ドミナントを６ｂｉｔ連続して送信することで、送信ノードや他の受信ノードにフレームの異常を通知するものである。
[0004]　またＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier SenseMultiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。」
「[0027]　（実施の形態１）　以下、本開示の実施の形態として、メッセージＩＤを用いて他のノード（ＥＣＵ）において不正なフレームに基づく処理が実行されることを阻止するための不正対処方法を実現する不正検知ＥＣＵを含む車載ネットワークシステム１０について図面を用いて説明する。」
「［0051]　１．４　ヘッドユニット２００の構成］　
ヘッドユニット２００は、例えば、自動車のインパネ等に設けられ、運転者に視認されるための情報を表示する液晶ディスプレイ（ＬＣＤ：liquid　crystal　display）等の表示装置、運転者の操作を受け付ける入力手段等を備える一種のＥＣＵである。
[0052]　図４は、ヘッドユニット２００の構成図である。ヘッドユニット２００は、フレーム送受信部２７０と、フレーム解釈部２６０と、受信ＩＤ判断部２４０と、受信ＩＤリスト保持部２５０と、フレーム処理部２２０と、表示制御部２１０と、フレーム生成部２３０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ヘッドユニット２００における通信回路、ＬＣＤ、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
[0053]　フレーム送受信部２７０は、バス５００ｃに対して、ＣＡＮプロトコルに従ったフレームを送受信する。バス５００ｃからフレームを１ｂｉｔずつ受信し、フレーム解釈部２６０に転送する。また、フレーム生成部２３０より通知を受けたフレームの内容をバス５００ｃに１ｂｉｔずつ送信する。
[0054]　フレーム解釈部２６０は、フレーム送受信部２７０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部２６０は、ＩＤフィールドと判断した値は受信ＩＤ判断部２４０へ転送する。フレーム解釈部２６０は、受信ＩＤ判断部２４０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部２２０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部２６０は、例えば、ＣＲＣの値が合わなかったり、ドミナント固定とされている項目がレセシブだったりする等、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部２３０へ通知する。また、フレーム解釈部２６０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。例えばデータフレームの途中からエラーフレームと解釈された場合においては、そのデータフレームの解釈は中止され、そのデータフレームに応じて特段の処理を行うことがなくなる。
[0054]　受信ＩＤ判断部２４０は、フレーム解釈部２６０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部２５０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部２４０は、フレーム解釈部２６０へ通知する。
[0055]　受信ＩＤリスト保持部２５０は、ヘッドユニット２００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図５は、受信ＩＤリストの一例を示した図である。ヘッドユニット２００は、エンジン４０１に接続されたＥＣＵ４００ａからメッセージＩＤが「１」であるフレーム（メッセージ）を受信し、ブレーキ４０２に接続されたＥＣＵ４００ｂからメッセージＩＤが「２」であるフレームを受信し、ドア開閉センサ４０３に接続されたＥＣＵ４００ｃからメッセージＩＤが「３」であるフレームを受信し、窓開閉センサ４０４に接続されたＥＣＵ４００ｄからメッセージＩＤが「４」であるフレームを受信する。
[0056]　フレーム処理部２２０は、受信したフレームの内容（例えばメッセージＩＤ及びデータフィールドの内容）に基づいて、例えばＬＣＤに表示されるべき画像を形成して、表示制御部２１０に通知する。なお、フレーム処理部２２０は、受信したデータフィールドの内容を保持し、入力手段を通じて受け付けた運転者による操作に応じて、ＬＣＤに表示されるべき画像（例えば車速表示用の画像、窓開閉状態表示用の画像等）を選択して通知しても良い。
[0057]　表示制御部２１０は、フレーム処理部２２０より通知を受けた内容をＬＣＤ等に表示する。
[0058]　フレーム生成部２３０は、フレーム解釈部２６０からのエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部２７０へ通知して送信させる。」
「[0094]　［１．１８　不正フレームの検知に係るシーケンス］　以下、上述の構成を備える車載ネットワークシステム１０のバス５００ａに不正なＥＣＵが接続された場合について、バス５００ａに接続された不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ、ゲートウェイ３００等の動作について説明する。
[0095]　図１８は、不正検知ＥＣＵ１００ａが不正なフレーム（メッセージ）を検知して、他のＥＣＵによりその不正なフレームに対応した処理がなされることを阻止する動作例を示すシーケンス図である。同図では、不正なＥＣＵが、バス５００ａにメッセージＩＤが「４」でデータフィールド（データ）が「２５５（０ｘＦＦ）」となるデータフレームを送信する場合の例を示している。ここでの各シーケンスは、各種装置における各処理手順（ステップ）を意味する。
[0096]　まず、不正なＥＣＵは、メッセージＩＤが「４」、データが「２５５（０ｘＦＦ）」となるデータフレームの送信を開始する（シーケンスＳ１００１）。フレームを構成する各ビットの値は、上述したデータフレームフォーマットに従ってＳＯＦ、ＩＤフィールド（メッセージＩＤ）といった順に逐次バス５００ａ上に送出される。
[0097]　不正なＥＣＵがＩＤフィールド（メッセージＩＤ）までをバス５００ａに送出し終えたときにおいて、不正検知ＥＣＵ１００ａ、ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれメッセージＩＤを受信する（シーケンスＳ１００２）。
[0098]　ＥＣＵ４００ａ、ＥＣＵ４００ｂ及びゲートウェイ３００はそれぞれ、保持している受信ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００３）。このとき、不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストを用いてメッセージＩＤをチェックする（シーケンスＳ１００４）。即ち、不正検知ＥＣＵ１００ａは、送信されたフレームにおけるＩＤフィールドの内容が、不正を示す所定条件（正規ＩＤリストに掲載されていないこと）に該当するか否かを判定する。
[0099]　シーケンスＳ１００３において、ＥＣＵ４００ａ及びＥＣＵ４００ｂは、それぞれが保持している受信ＩＤリストに「４」が含まれていないため（図９参照）、受信を終了する。つまりこれ以上不正なＥＣＵが送信を継続するフレームの解釈をせずフレームに対応した処理を行わない。また、シーケンスＳ１００３においてゲートウェイ３００は、保持している受信ＩＤリストに「４」が含まれているため（図５参照）、受信を継続する。また、シーケンスＳ１００４において不正検知ＥＣＵ１００ａは、保持している正規ＩＤリストに「４」が含まれていないため、不正なメッセージＩＤであると判断して、続いてエラーフレームの発行準備を開始する（シーケンスＳ１００５）。
[0100]　シーケンスＳ１００３に続いて、ゲートウェイ３００はフレームの受信を継続する。例えば、不正検知ＥＣＵ１００ａがエラーフレームの発行準備をしている間に、不正なＥＣＵからはバス５００ａ上にＩＤフィールドより後の部分であるＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）が逐次送出され、続いてデータフィールドが１ビットずつ逐次送出される。ゲートウェイ３００はこのＲＴＲ、コントロールフィールド（ＩＤＥ、ｒ、ＤＬＣ）を受信し、続いてデータフィールドの受信を開始する（シーケンスＳ１００６）。
[0101]　次にエラーフレームの発行準備が終わって、不正検知ＥＣＵ１００ａがエラーフレームを送信する（シーケンスＳ１００７）。このエラーフレームの送信は、不正なフレームの最後尾が送信される前（例えばＣＲＣシーケンスの最後尾が送信される前等）に行われる。この動作例においては、データフィールドの途中で行われる。このエラーフレームの送信が開始されることによりバス５００ａでは、不正なＥＣＵから送信中のフレームのデータフィールドの途中部分がエラーフレーム（優先されるドミナントのビット列）により上書きされることになる。
[0102]　シーケンスＳ１００７において送信されたエラーフレームを受信したゲートウェイ３００は、データフィールドの受信途中で不正なＥＣＵが送信していたフレームの受信を中止する（シーケンスＳ１００８）。つまり、ゲートウェイ３００は、不正なＥＣＵからのデータフィールドがエラーフレームで上書きされており、エラーフレームを検出するので、不正なＥＣＵが送信していたフレームの受信を継続しない。
[0103]　不正検知ＥＣＵ１００ａは、エラーフレームを送信する対象となったデータフレームのメッセージＩＤ「４」に対応する不正検知カウンタをインクリメントする（シーケンスＳ１００９）。
[0104]　インクリメントした結果としてメッセージＩＤ「４」に対応する不正検知カウンタが１７以上となった場合、
不正検知ＥＣＵ１００ａは、ヘッドユニット２００に受信されるようにエラー表示を通知するフレーム（エラー表示メッセージ）を送信する
ヘッドユニット２００のフレーム処理部２２０によってエラー表示のための処理がなされＬＣＤ等を介してエラーが報知される。
　上記記載から，引用文献２には以下の事項（以下，「引用文献２記載事項」という。）が記載されている。
「車載ネットワークのＣＡＮにおいて，不正を検知したＥＣＵが，ＥＣＵの一種であるヘッドユニット２００に受信されるようにエラー表示を通知するフレーム（エラー表示メッセージ）を送信し，ヘッドユニット２００のフレーム処理部２２０によってエラー表示のための処理がなされＬＣＤ等を介してエラーが報知されること。」
ウ　引用文献３
（ア）原査定の拒絶の理由で引用された本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開２０１３−９８７１９号公報（以下，「引用文献３」という。）には，図面とともに，次の記載がある。
「【技術分野】
【０００１】
　本発明は、通信システムにおけるメッセージ認証技術に関する。
【背景技術】
【０００２】
　
車載ネットワークとしてＣＡＮ（Controller Area Network）が採用されている。
ネットワーク上を流れるメッセージを受信したり、ネットワーク上にメッセージを送信したりすることができる。
「【課題を解決するための手段】
【００１０】
　本発明に係る
メッセージ認証方法では、メインメッセージと、メインメッセージのメッセージ認証コード（Message Authentication Code: ＭＡＣ）を含むＭＡＣメッセージを送信する。受信側では、メインメッセージから算出されるＭＡＣとＭＡＣメッセージに含まれるＭＡＣが一致すればメインメッセージが正当なものであり、不一致であれば不正なものであると判断できる。
「【００１４】
　このような本発明によると、ＣＡＮプロトコルに適用可能な方式で、
ＭＡＣによってメインメッセージの正当性を検証することができる。
【００１５】
　また、本発明では、
メインメッセージは平文の状態でネットワーク上を伝送する
「【００３４】
　なお、
本実施形態において、全てのメッセージについてＭＡＣによるメッセージ認証を行う必要はない。すなわち、重要なメッセージについてのみメッセージ認証を行っても良い。
「【００３９】
（メッセージ送信時処理）
　まず、
メインメッセージを送信するＥＣＵが行う処理
【００４０】
　メインメッセージ生成部９は、
ＣＡＮ　ＩＤおよびデータフィールドを含むメインメッセージを生成してＣＡＮに送信する
【００４１】
　また、データフィールド抽出部７は、
メインメッセージ生成部９が送信したメインメッセージのデータフィールドを抽出する
【００４２】
　ＭＡＣ生成部４は、
暗号鍵記憶部５から暗号鍵（共通鍵）を取り出し（Ｓ１０５）、この暗号鍵を用いて、ＣＡＮ　ＩＤ、最新のカウンタ値、送信済みのデータフィールドからＭＡＣを生成する
【００４３】
　ＭＡＣ生成部４が生成したＭＡＣはＭＡＣメッセージ生成部１へ送られ（Ｓ１０７）、
ＭＡＣメッセージ生成部１がＭＡＣをＣＡＮメッセージ（ＭＡＣメッセージ）に加工してＣＡＮに送信する。
　上記記載から，引用文献３には以下の事項（以下，「引用文献３記載事項１」という。）が記載されている。
「車載ネットワークとしてのＣＡＮに流れるメインメッセージをＥＣＵが送信する際，ＭＡＣによってメインメッセージの正当性を検証するために，ＣＡＮ　ＩＤおよびデータフィールドを含むメインメッセージを生成してＣＡＮに送信し，送信したメインメッセージのデータフィールドを抽出し，暗号鍵を用いて，ＣＡＮ　ＩＤ，最新のカウンタ値，送信済みのデータフィールドからＭＡＣを生成し，生成されたＭＡＣをＣＡＮメッセージ（ＭＡＣメッセージ）に加工してＣＡＮに送信すること。」
　また，引用文献３には，以下の事項（以下，「引用文献３記載事項２」という。）も記載されている。
「車載ネットワークとしてのＣＡＮに流れるメッセージについて，全てのメッセージをＭＡＣによるメッセージ認証を行う必要は無く，重要なメッセージのみＭＡＣによるメッセージ認証を行えば良いこと。」
　さらに，引用文献３には，以下の事項（以下，「引用文献３記載事項３」という。）も記載されている。
「車載ネットワークとしてのＣＡＮに流れるメッセージについて，メインメッセージは平文の状態でネットワーク上を伝送すること。」
エ　周知技術
（ア）引用文献４
　本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である，畑正人　他４名，不正送信阻止：ＣＡＮではそれが可能である，情報処理学会，２０１１年１０月１２日，第２０１１巻，第３号，p624-629（以下，「引用文献４」という。なお，引用文献４は，上記引用文献１の「参考文献４−２４」である。）には，図面とともに，次の記載がある。
「１　はじめに
　現代の自動車は，車内の様々な機器の制御を担うＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）を多数搭載し，それらを接続する車載ネットワークとして，ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）を導入していることが多い．ＣＡＮの導入により高度な制御が行うことができ，セーフティの向上やコスト面などで多くの利点がある．しかし，ＣＡＮを導入することによる新たな脅威も知られている．例えば，文献［１］では攻撃者が車載ネットワークに直接アクセスできる環境において，ＥＣＵの書き換え等の攻撃により，運転者が意図しない動作を発生させられることを実際の自動車を用いて実証している．また，文献［２］では攻撃者が車載ネットワークに直接アクセスできない状況でもオーディオシステムやＢｌｕｅｔｏｏｔｈ，携帯電話などを介して侵入することで自動車の制御を乗っ取ることが可能であることが実証されている．文献［３］では，攻撃者がメッセージの挿入を行うことで，パワーウィンドウやエアバッグ制御システムなどの機能が正常に動作しなくなることをシミュレータやデモシステムで示している．これ以外にも多くの文献で車載ネットワークの脆弱性について言及されており，早急な対応が必要といえる．
　自動車は多数の機器からなる複雑なシステムであり，多様なセキュリティ上の課題が考えられるが，最も大きな課題の１つに，ＣＡＮの脆弱性が挙げられる．ＣＡＮは，バスネットワークを想定しており，やりとりされるメッセージ（ＣＡＮではフレームとよぶ）には送信元や宛先情報が含まれず，メッセージは全てバス上にブロードキャストされる．当該バスに接続されたノード（ＥＣＵ）は，任意のメッセージを送信することができるため，バス内のＥＣＵが一度不正侵入されると，このＥＣＵが他の重要な制御を行うＥＣＵになりすまして，様々な不正を行うことができる．そこで本稿では，ＣＡＮの特徴であるブロードキャスト通信を利用し，不正メッセージがバス上に送信されていることを，なりすましの対象となったノード自身が検知し，エラーメッセージを送ることで，偽装メッセージの送信が完了する前にこれを破棄する“不正送信阻上方式”を提案する．
　本稿の構成は以下のとおりである．２章で関連研究を紹介する．３章でＣＡＮについて述べ，４章でＣＡＮにおける問題点と脅威についてまとめる．その後，５章で不正送信阻止方式の提案を行い，６章で考察として評価を行い，そして７節でまとめと今後の課題とする．」（第６２４頁左欄１行ないし第６２５頁左欄２０行）
「４　ＣＡＮにおける問題点と脅威
４．１　ＣＡＮにおけるセキュリティ上の問題
車載ネットワークで用いられているＣＡＮプロトコルには，以下のようなセキュリティ上の問題点が存在する．
●メッセージに送信元情報や認証などのセキュリティ機能が含まれていないため，なりすましが容易に行える．
●バス型であるため，すべてのＥＣＵにメッセージが送信される．従って盗聴や解析などが容易に行える．
既存の研究では，上記に挙げたような車載ネットワークの脆弱性が指摘されており，それらを悪用することにより４．２節で述べる脅威が想定される．
４．２　ＣＡＮにおける脅威
●盗聴
　ＣＡＮプロトコルは守秘性がなく，バス型でメッセージがブロードキャストされるため容易に盗聴が可能である．また，ＯＢＤ−ＩＩポートからある程度のメッセージを受信することが可能である．
●不正メッセージの送信
　ＯＢＤ−ＩＩポートや不正ＥＣＵの接続，正規ＥＣＵの改ざんによりバス上に任意のメッセージを挿入することが可能であるため，他のＥＣＵになりすまして不正メッセージを送信することができる．特に，ＣＡＮでは，全てのメッセージを観測できるため，受信した正規メッセージを再度バス上に送信する再送攻撃が容易に行える．
●ＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅ）攻撃
　不正ＥＣＵによりバスを継続的にドミナント状態にしたり，優先度の高い不正メッセージを連続送信したりすることで，他のメッセージの送信を妨害することが容易に可能である．
　上記の脅威の中で，特に，
不正メッセージの送信はＥＣＵの誤動作を招き，自動車の走行を危険な状態に陥れるため，その対策は非常に重要である．
（イ）引用文献５
　本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である，特開２０１２−１５５６０８号公報（以下，「引用文献５」という。）には，図面とともに，次の記載がある。
「【技術分野】
【０００１】
　本発明は、所定のイベント発生時に、車両を制御する車載制御システムの動作状態などに関連するデータを記録する車両用データ記録装置に関する。」
「【００５７】
　また、
所定の異常イベントが発生したことを車内ＬＡＮを介して他のＥＣＵに通知する場合には、所定の異常イベントの発生を通知するメッセージの優先度を最も高く設定する。
（ウ）引用文献６
　本願の出願前に頒布された又は電気通信回線を通じて公衆に利用可能となった文献である，特開２００５−２７８００７号公報（以下，「引用文献６」という。）には，図面とともに，次の記載がある。
「【技術分野】
【０００１】
　本発明は、通信システム及び通信装置に関し、特に、冗長ビットを含む通信データを送受信する通信システム及び通信装置に関する。
【背景技術】
【０００２】
　近年の情報通信技術の発達により、様々な場所において、通信ネットワークが利用されている。特に、ＬＡＮ等のように通信範囲が限定された、閉じられたネットワークよりも、インターネット等のように通信範囲が限定されない、開かれたネットワークが普及している。これに伴い、ネットワークに接続された情報の盗聴や、改ざん、成りすまし等、ネットワークのセキュリティ性が問題となっている。そこで、ネットワークのセキュリティ性を向上させる技術として暗号技術の研究が盛んに行われている。
【０００３】
　一方、
自動車等の車両ＬＡＮの一つにＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）が知られている。ＣＡＮは、多くの自動車内部の制御用通信方式として利用されており
【０００４】
　ＣＡＮは車両内に限られた、閉じられたネットワークであるため、盗聴等されること少ないが、ユーザが、ＥＣＵ（ElectricControl Unit）のメンテナンス用の端子からＣＡＮに接続し、盗聴等が可能である。また、ＩＴＳ（Ｉｎｔｅｌｌｉｇｅｎｔ　Ｔｒａｎｓｐｏｒｔ　Ｓｙｓｔｅｍｓ）の発達に伴い、ＣＡＮと外部のネットワークを接続し、開かれたネットワークになることもありうる。この場合には、外部から車両内のＣＡＮに接続し、盗聴等が可能となる。」
「【００３２】
　
通信装置１００は、例えば、ＥＣＵであり、エンジンや、トランスミッション、ＡＢＳ、ダッシュボードのメータ類、パワーウィンドウ等の制御装置である。
通信装置１００は、図に示されるように、通信制御部２００とＣＰＵ３００を備えている。
【００３３】
　ＣＰＵ３００は、通信装置１００の各種制御処理を行う処理装置である。通信装置１００には、図示しない各種センサー等の検出に基づいた処理や、他の通信装置１００から受信したデータに基づいた処理を行う。例えば、各種センサーが検出したデータから送信データを生成し、通信制御部２００を介して他の通信装置１００へ通知する。また、通信制御部２００を介して他の通信装置１００のデータを受信し、メータ等に出力する。
【００３４】
　
通信制御部２００は、ＣＡＮコントローラーであり、ＣＡＮバス４００を介した他の通信装置１００との通信の制御を行う制御装置である。
（エ）周知技術
　上記，引用文献４及び５の記載から，以下の事項は周知の事項（以下，「周知事項１」という。」）ということができる。
「制御系の車内ＬＡＮ（ＣＡＮ）において，不正メッセージの送信は，自動車の走行を危険な状態にするために，その対策は重要であること。」
　また，引用文献６の記載から，以下の事項は周知の事項（以下，「周知事項２」という。）ということができる。
「自動車等の車両ＬＡＮの一つであるＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）は，制御装置であるＥＣＵ（通信装置）が接続されており，
　ＥＣＵは，通信制御部とＣＰＵを備え，
　通信制御部は，ＣＡＮコントローラーであり，ＣＡＮバスを介した他のＥＣＵとの通信の制御を行う制御装置であること。」
（３）引用発明との対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明の「自動車分野で，ＥＣＵごとに異なるＩＤを割り振ることとし，あるＩＤのデータフレームを送信するＥＣＵは，ネットワーク上に一つしか存在しない」ことについて，上記記載の「ＥＣＵ」は，本件補正発明の「ノード」に相当し，又，上記記載の「ＥＣＵごとに異なるＩＤを割り振ること」は，本件補正発明の「複数のノード間で互いに異なる識別子が付され」ることに相当する。
　そして，上記記載にあるように引用発明は，「自動車分野」に関する「システム」であるから，引用発明の「システム」は，本件補正発明の「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システム」に相当する。
（イ）引用発明の「あるＩＤのデータフレームを送信する」ことと，本件補正発明の「前記識別子として第１識別子が付された第１信号を符号化することなく出力する」ことは，「前記識別子として第１識別子が付された第１信号を」「出力する」点で共通する。
　そして，引用発明の「正規の送信ＥＣＵ」は，「あるＩＤのデータフレームを送信」しているのであるから，周知事項２（引用文献６参照。）にあるように，送信のための何らかの構成，すなわち「通信制御部（ＣＡＮコントローラ）」を備えていると認められる。そうすると，引用発明の「正規の送信ＥＣＵ」と本件補正発明の「ノード」とは，「前記識別子として第１識別子が付された第１信号を」「出力する通信部を有する」点で共通する。
　してみると，引用発明に備えられた「正規の送信ＥＣＵ」の１つと本件補正発明の「前記識別子として第１識別子が付された第１信号を符号化することなく出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え」ることは，「前記識別子として第１識別子が付された第１信号を」「出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え」る点で共通する。
（ウ）引用発明は，「正規の送信ＥＣＵ」は，「自らが送信していないときに，自らが送信するＩＤのメッセージがバスに流れているかを監視し，自らが送信するＩＤのメッセージをほかのＥＣＵが送信した場合，これを不正メッセージとして処理して，不正に送信されるデータフレームの送信自体を阻止し」ているのであるから，「ほかのＥＣＵ」からのメッセージを受信しているといえ，又，そのために上記（イ）で検討した「通信制御部（ＣＡＮコントローラ）」を用いていると認められる。
　そうすると，引用発明の「通信制御部（ＣＡＮコントローラ）」と，本件補正発明の「前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから符号化されることなく出力された第２信号を受信」することとは，「前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから」「出力された第２信号を受信」している点で共通する。
（エ）引用発明の「正規の送信ＥＣＵ」が「自らが送信していないときに，自らが送信するＩＤのメッセージがバスに流れているかを監視し，自らが送信するＩＤのメッセージをほかのＥＣＵが送信した場合」は，本件補正発明の「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されている」場合に相当する。
　そして，引用発明は，上記の場合「正規の送信ＥＣＵ」の「通信制御部（ＣＡＮコントローラ）」は，「不正送信が発生した場合に，阻止したことをユーザに通知し」ているから，この通知は「異常通知信号」であるといえる。
　そうすると，引用発明の上記「通知」を生成することと，本件補正発明の「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する」こととは，「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、」「異常通知信号を生成する」点で共通する。
　そして，引用発明は上記「通知」を生成するための信号生成手段を当然備えていると認められるから，引用発明の「通知」を生成するための信号生成手段と，本件補正発明の「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」は，「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、」「異常通知信号を生成する信号生成部」である点で共通する。
（オ）してみると，本件補正発明と引用発明は，以下の点で一致し，又相違する。
［一致点］
「複数のノード間で互いに異なる識別子が付された複数の信号の通信が車内においてなされる車載通信システムであって，
　前記識別子として第１識別子が付された第１信号を出力する通信部を有する第１ノードを，前記複数のノードのうち１つとして備え，
　前記通信部は，前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから出力された第２信号を受信し，
　前記第１ノードは，前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば，異常通知信号を生成する信号生成部を含む，
　車載通信システム。」
［相違点１］
　「前記識別子として第１識別子が付された第１信号を出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え」る点について，本件補正発明は「前記識別子として第１識別子が付された第１信号を符号化することなく出力する通信部を有する第１ノードを、前記複数のノードのうち１つとして備え」ているのに対して，引用発明の出力される「データフレーム」は，符号化を行っているのか否か記載されていない点。
［相違点２］
　「前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから出力された第２信号を受信」する点について，本件補正発明は，「前記通信部は、前記複数のノードのうち他のもう１つとして前記車載通信システムに組み込まれた第２ノードから符号化されることなく出力された第２信号を受信」しているのに対して，引用発明の受信する「データフレーム」は，符号化されているのか否か記載されていない点。
［相違点３］
　「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」について，本件補正発明が「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」であるのに対して，引用発明の「通知」を生成するための信号生成手段により生成された「通知」が「前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号」であると特定されていない点。
（４）判断
　以下，各相違点について検討する。
ア　［相違点１］及び［相違点２］について
　引用文献３記載事項３にあるように，車載ネットワークのＣＡＮに流れるメッセージは，平文，即ち，符号化されていない信号である。
　また，引用文献３記載事項１及び２にあるように，引用文献３では，暗号鍵をもちいて符号化された信号（即ち「ＭＡＣ」）も，車載ネットワークのＣＡＮに流れているが，重要であるメッセージについてのみ符号化することが記載されている。
　そして，引用発明では，「正規の送信ＥＣＵ」の「通信制御部（ＣＡＮコントローラ）」は，「不正送信が発生した場合には，阻止したことをユーザに通知する機能が重要」であるとし，又，上記周知事項１（引用文献４及び５参照。）にあるように「車内ＬＡＮ（ＣＡＮ）において，不正メッセージの送信は，自動車の走行を危険な状態にするために，その対策は重要である」ことは周知の事項であるから，「阻止したことをユーザに通知」する信号とそれ以外の信号は重要度が異なることは明らかである。
　してみると，「阻止したことをユーザに通知」する信号以外の信号を，上記引用文献３記載事項３にあるように，平文即ち，符号化されていない信号とすることは，符号化にかかるコストとの関係で当業者が適宜選択する事項である。
　そして，引用発明の「メッセージ」を，上記引用文献３記載事項１ないし３及び上記周知事項１に基づいて，「前記識別子として第１識別子が付された第１信号を符号化することなく出力する」こととし，又，「前記車載通信システムに組み込まれた第２ノードから符号化されることなく出力された第２信号を受信」することとし，引用発明の「通信制御部（ＣＡＮコントローラ）」を［相違点１］及び［相違点２］に係る構成とすることは，当業者が容易に想到することである。
イ　［相違点３］について
　引用発明の「不正送信が発生した場合には，阻止したことをユーザに通知」する際に，引用文献２記載事項にあるようにＥＣＵの一種であるヘッドユニットに受信されるようにエラー表示を通知することは公知の事項であって，引用発明のユーザへの通知において，引用文献２記載の公知技術を採用することに格別の困難性は認められない。
　その際に，ヘッドユニットはＥＣＵの一つとして構成されるのであるから，ＣＡＮ上を流れる「阻止したことをユーザに通知」する信号は，ＣＡＮのプロトコルに従ったメッセージとなることは明らかである。
　そして，上記アで検討したように，「阻止したことをユーザに通知」する信号は重要な信号であり，この重要な信号について，引用文献３記載事項１にあるような信号，即ち暗号化された信号（「ＭＡＣ」）を付加することは当業者が容易に想到することである。加えて，暗号化された信号（「ＭＡＣ」）については，復号のための鍵を有していないＥＣＵ，即ち不正に接続されたＥＣＵは復号できず，一方，復号のための鍵を有しているＥＣＵ，即ち正規のＥＣＵであれば，当然に復号でき，「認識可能」であることは明らかである。
　また，本件明細書には，本件補正発明の「前記第１ノードは、前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する」点について，＜第２実施形態＞（【００７９】ないし【００８３】）において，
「【００７９】
　第１実施形態と同様に、ＥＣＵ２００Ａに割り当てられた識別子が、受信部２１２によって受け取られたパケット信号に付されているならば、判定部２２０Ａは、トリガ信号を生成する。トリガ信号は、判定部２２０Ａから通知信号生成部２４１へ出力される。通知信号生成部２４１は、トリガ信号に応じて、通知信号を生成する。通知信号生成部２４１は、
ＥＣＵ２００Ａに割り当てられた識別子と、ＥＣＵ２００Ａに割り当てられた識別子を表すデータと、を通知信号に組み込む。
【００８０】
　
符号化部２４３は、復号部２３２が復号に利用した鍵と同一の鍵を用いて、通知信号を符号化する。この結果、ＭＡＣが、通知信号に組み込まれる。
【００８１】
　符号化された通知信号は、符号化部２４３から送信部２１１へ伝達される。送信部２１１は、符号化された通知信号をバス１２０へ出力する。
【００８２】
　図２を参照して説明された通信システム１０１に関して、ＥＣＵ１１１が、符号化された通知信号をバス１２０へ出力すると、ＥＣＵ１１２，１１３，１１４それぞれの復号部２３２は、通知信号を復号することができる。この結果、ＥＣＵ１１２，１１３，１１４は、所定の警告動作を実行することができる。一方、不正なＥＣＵ１１５は、復号部２３２を有さない、或いは、復号のための共通鍵を有していない。したがって、ＥＣＵ１１５は、通知信号を復号できず、通知信号の内容を把握することができない。この結果、ＥＣＵ１１５は、通知信号を無効化する不正な動作を実行することはできない。本実施形態において、第３ノードは、ＥＣＵ１１２，１１３，１１４のうち１つによって例示される。
【００８３】
　
通知信号は、ＭＡＣの分だけ、パケット信号生成部２４２によって生成されるパケット信号よりもビット数において大きい。
と記載されているように，本件補正発明の「前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号」は，通知信号に組み込まれた，ＥＣＵ２００Ａに割り当てられた識別子と、ＥＣＵ２００Ａに割り当てられた識別子を表すデータを暗号化したＭＡＣの部分であることを含むと認められる。
　そうすると，引用発明の「阻止したことをユーザに通知」する信号を生成する信号生成手段を，上記引用文献２記載事項及び上記引用文献３記載事項１ないし３及び上記周知事項１に基づいて，「前記第２信号に前記第１ノードを表す前記第１識別子と同一の第１識別子が付されているならば、前記第２ノード以外のノードが前記車載通信システムの異常を認識可能な符号化された異常通知信号を生成する信号生成部」とし，［相違点３］に係る信号生成部とすることは，当業者が容易に想到することである。
　なお，仮に，「符号化された異常通知信号」が「全体が符号化された異常通知信号」を意味するとしても，信号のどの範囲を暗号化（すなわち「符号化」）するかは，セキュリティの程度や処理コスト等に応じて，当業者が適宜選択すべき設計選択事項である。
ウ　そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，引用発明及び引用文献２ないし５に記載された技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
エ　したがって，本件補正発明は，引用発明及び引用文献２及び３に記載された技術並びに周知事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものである。
３　本件補正についてのむすび
　よって，本件補正は，特許法第１７条の２第６項において準用する同法１２６条第７項の規定に違反するので，同法１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
第３　本願発明について
１　本願発明
　平成３０年９月１２日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成３０年１月１９日にされた手続補正により補正された特許請求の範囲の請求項１ないし６に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，その請求項１に記載された事項により特定される，前記第２［理由］１（２）に記載のとおりのものである。
２　原査定の拒絶の理由
　原査定の拒絶の理由は，この出願の請求項１ないし６に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
＜引用文献等一覧＞
１．中野学　他，自動車の情報セキュリティ，日経ＢＰ社，２０１３年１２月２７日，初版，pp.156-165
２．国際公開第２０１５／１５１４１８号
３．特開２０１３−０９８７１９号公報
３　引用文献
　原査定の拒絶の理由で引用された引用文献１ないし３及びその記載事項は，前記第２の［理由］２（２）に記載したとおりである。
４　対比・判断
　本願発明は，前記第２の［理由］２で検討した本件補正発明から，「前記第２信号」に付される「前記第１識別子」，及び，「前記車載通信システムの異常を通知するために符号化された通知信号を生成する」ことに係る限定事項を削除したものである。
　そうすると，本願発明の発明特定事項を全て含み，さらに他の事項を付加したものに相当する本件補正発明が，前記第２の［理由］２（３），（４）に記載したとおり，引用発明及び引用文献２及び３に記載された技術並びに周知事項に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，引用発明及び引用文献２及び３に記載された技術並びに周知事項に基づいて，当業者が容易に発明をすることができたものである。
第４　むすび
　以上のとおり，本願発明は，特許法第２９条第２項の規定により特許を受けることができないから，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　よって，結論のとおり審決する。