2022-009215

第１ 手続の経緯

本願は、平成３１年３月２９日の出願であって、その手続の経緯は以下のとおりである。

第２ 原査定の概要

原査定（令和４年３月３日付け拒絶査定）の概要は次のとおりである。

本願請求項１－６に係る発明は、以下の引用文献１－５に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

＜引用文献等一覧＞

１．ネットワーク管理 最強の指南書 、日本、日経ＢＰ社、2016年04月29日、p.170

２．特開２００９－２２４９１６号公報 (周知技術を示す文献)

３．特開２０１４－０３３４２４号公報 (周知技術を示す文献)

４．新里 祐教、ＩｏＴ 最強の指南書 、日本、日経ＢＰ社 吉田 琢也、2018年05月21日、p.194-195 (周知技術を示す文献)

５．サンダース クリス Chris Sanders、実践 パケット解析 初版 Practical Packet Analysis、第1版、日本、株式会社オライリー・ジャパン オライリー ティム、2008年01月22日、P.140-142 (周知技術を示す文献)

第３ 当審拒絶理由の概要

当審が令和４年１０月１８日付けで通知した拒絶理由（以下「当審拒絶理由」という。）の概要は次のとおりである。

この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。

特許請求の範囲、明細書及び図面の記載並びに出願時の技術常識に基づいて検討したところ、以下のとおりである。

請求項１、５には「前記通信装置とは別体であるモニタ装置に送信し」及

び「前記モニタ装置から受信する」と記載されているが、この記載では、パソコン等の端末装置において、無線ＬＡＮルータ等の端末装置と別体の通信装置を用いて通信を行うとともに、端末装置から通信装置の動作を設定する、又は端末装置において通信装置の状態をモニタする、といった構成も含んでいるように読み取れ、範囲が不明確である。本願の課題に鑑みると、このような一般的な構成は含まれないといえるから、このような構成が明確に含まれない記載とされたい。

また、請求項１、５には「前記通信装置とは別体であるモニタ装置」と記載されているが、何をモニタするモニタ装置であるのか、また、通信装置との関係について不明確である。

さらに、請求項１、５を引用する請求項２－４、６にも同様の理由が該当する。

第４ 本願発明

本願請求項１－６に係る発明（以下、それぞれ「本願発明１」－「本願発明６」という。）は、令和４年１２月１４日提出の手続補正で補正された特許請求の範囲の請求項１－６に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。

「【請求項１】

通信装置であって、

通信用のインタフェースと、

前記インタフェースに設定可能な１以上の設定情報に１対１に対応する１以上の疑似インタフェース識別子を生成する生成部と、

前記生成部が生成した前記１以上の疑似インタフェース識別子を、前記通信装置とは別体であり、前記通信装置の通信パケットをキャプチャした動作の結果を表示するモニタ装置にネットワークを介して送信し、送信した前記１以上の疑似インタフェース識別子のうちから選択された一の疑似インタフェース識別子を前記モニタ装置から前記ネットワークを介して受信する処理部と、

前記処理部が受信した前記一の疑似インタフェース識別子に対応する前記設定情報に基づく設定を前記インタフェースに適用した後に、当該設定に従った動作を行わせる制御部とを備える

通信装置。」

また、本願発明２－４は、本願発明１を減縮した発明である。

さらに、本願発明５は、本願発明１に対応する「通信方法」の発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。

加えて、本願発明６は、本願発明５を引用する「プログラム」の発明であり、実質的に、本願発明５を減縮した発明である。

第５ 引用文献、引用発明

１ 引用文献１について

原査定の拒絶の理由に引用された引用文献１には、次の事項が記載されている（下線は、当審で付した。以下同じ。）。

ア 「Ａさんは、Ｗｉｒｅｓｈａｒｋのモニターモードのセットアップ済みのＬｉｎｕｘパソコンをカバンから取り出し、先ほど通常モードでキャプチャーを行ったノートパソコンの横にＬｉｎｕｘパソコンを置いた。

まずＬｉｎｕｘパソコンの無線チャネルをアクセスポイントに合わせた。Ｌｉｎｕｘでの無線チャネルの変更は、コマンドで実行する。例えば、Ｕｂｕｎｔｕで「ｗｌａｎ０」と認識された無線ＬＡＮアダプターのチャネルを６ｃｈに変更するときは、コマンドを実行するターミナルを開いて、

ｓｕｄｏ ｉｗｃｏｎｆｉｇ ｗｌａｎ０ ｃｈａｎｎｅ１ ６

と入力してＥｎｔｅｒキーを押せば、チャネルが変更される。

モニターモードでのパケットキャプチャーを開始したら、横に置いたＷｉｎｄｏｗｓパソコンでＮＡＳサーバーにアクセスしてファイル転送を行う。モニターモードでのキャプチャー実行中は、キャプチャ一に利用した無線ＬＡＮアダプターでの通常の無線ＬＡＮ通信ができなくなるからだ。」（左欄２行－中欄５行）

イ 「そこでフィルター機能を使った。

フィルター機能は、Ｗｉｒｅｓｈａｒｋの画面上部にあるＦｉｌｔｅｒ欄から使う。パケットに絞り込むため、Ｆ社のアクセスポイントをＭＡＣアドレスで指定した。具体的には、

ｗｌａｎ．ａｄｄｒ ＝＝ ００：３ａ：９ｄ：１ａ：７９：６６

と入力してＥｎｔｅｒキーを押した。「＝＝」は一致を示す記号で、００から始まる数値がアクセスポイントのＭＡＣアドレスを示す。」（中欄下から４行－右欄１０行）

ここで、引用文献１に記載されている事項について検討する。

上記アの「Ａさんは、Ｗｉｒｅｓｈａｒｋのモニターモードのセットアップ済みのＬｉｎｕｘパソコンをカバンから取り出し、先ほど通常モードでキャプチャーを行ったノートパソコンの横にＬｉｎｕｘパソコンを置いた。」及び「モニターモードでのパケットキャプチャーを開始したら、横に置いたＷｉｎｄｏｗｓパソコンでＮＡＳサーバーにアクセスしてファイル転送を行う。」との記載から、引用文献１には、「パケットキャプチャーを行うＷｉｎｄｏｗｓノートパソコンであって、Ｗｉｎｄｏｗｓノートパソコンとは別体であり、Ｗｉｒｅｓｈａｒｋのモニターモードのセットアップ済みのＬｉｎｕｘパソコンによりモニターされる、Ｗｉｎｄｏｗｓノートパソコン」が記載されていると認められる。

したがって、引用文献１には次の発明（以下「引用発明」という。）が記載されていると認められる。

「パケットキャプチャーを行うＷｉｎｄｏｗｓノートパソコンであって、

Ｗｉｎｄｏｗｓノートパソコンとは別体であり、Ｗｉｒｅｓｈａｒｋのモニターモードのセットアップ済みのＬｉｎｕｘパソコンによりモニターされる、

Ｗｉｎｄｏｗｓノートパソコン。」

２ 引用文献２について

原査定の拒絶の理由に引用された引用文献２には、図面とともに次の事項が記載されている。

「【０００５】

図４に示すように、ＷＬＡＮ及びＤＣＬの各通信方式は、いずれも２．４ＧＨｚから２．５ＧＨｚまでの周波数帯域（２．４ＧＨｚ帯）を使用している。そして、各々の通信方式において、周波数帯域内を複数分割したチャンネルが設定されている。なお、各々の通信方式におけるチャンネルを区別するために、以下、ＷＬＡＮで使用されるチャンネルをＷＬＡＮチャンネル、ＤＣＬで使用されるチャンネルをＤＣＬチャンネルと称する。

【０００６】

ＷＬＡＮでは、２．４ＧＨｚから２．５ＧＨｚまでの周波数帯域が１４のＷＬＡＮチャンネル（ｗｃｈ１～ｗｃｈ１４）に分けられている。ＷＬＡＮは、１４のＷＬＡＮチャンネルのうち１つのＷＬＡＮチャンネルを継続して使用しながら、その１つのＷＬＡＮチャンネルに対して送信データを直接スペクトラム拡散する直接拡散方式により、無線通信を行う。

【０００７】

一方、ＤＣＬでは、２．４ＧＨｚから２．５ＧＨｚまでの周波数帯域が８９のＤＣＬチャンネル（ｄｃｈ１～ｄｃｈ８９）に分けられている。そして、ホッピング周期と称される所定の周期（例えば、１／１００秒）毎に、８９あるＤＣＬチャンネルのうち予め選択された例えば４５のＤＣＬチャンネルの間で、使用されるＤＣＬチャンネルが変更（ホッピング）される周波数ホッピング方式により無線通信が行われる。」

３ 引用文献３について

原査定の拒絶の理由に引用された引用文献３には、図面とともに次の事項が記載されている。

「【０２４２】

また、例えば、Ａ１乃至Ａ５において、ＷｉＦｉ干渉しているときは、当該空間と未使用チャンネルＡ６を入れ替えることにより、ＷｉＦｉ干渉を回避することができる。なお、未使用チャンネルとして対でＢ６も設定されているが、Ｂ６を用いても同様に回避することができる。

【０２４３】

ここで、本技術の参考となる各国規格の一部を以下の（ａ）乃至（ｈ）に示す。

続きを表示（全21行）

（ａ）日本（ＴＥＬＥＣ（財団法人テレコムエンジニアリングセンター）、ほか認定機関あり）

２．４１２～２．４７２ＧＨｚ、１３チャネル（ＯＦＤＭ（Orthogonal Frequency Division Multiplexing））

２．４１２～２．４８４ＧＨｚ、１４チャネル（ＣＣＫ（Complementary Code Keying） ただし、ｃｈ１４＝１１ｂのみ利用可能）

（ｂ）米州（ＦＣＣ） ＦＣＣ（米国連邦通信委員会）

２．４１２～２．４６２ＧＨｚ、１１チャネル

（ｃ）北米（ＦＣＣを除く）ＩＣ（カナダ）

２．４１２～２．４６２ ＧＨｚ、１１チャネル

（ｄ）ＥＴＳＩ（欧州通信規格協会）

２．４１２～２．４７２ ＧＨｚ、１３チャネル

（ｅ）中国

２．４１２～２．４７２ＧＨｚ、１３チャネル

（ｆ）韓国

２．４１２～２．４７２ＧＨｚ、１３チャネル

（ｇ）シンガポール

２．４１２～２．４７２ＧＨｚ、１３チャネル（ＥＴＳＩ）

（ｈ）台湾

２．４１２～２．４６２ＧＨｚ、１１チャネル（ＦＣＣ）」

４ 引用文献４について

原査定の拒絶の理由に引用された引用文献４には、次の事項が記載されている。

「▼ヘッドレス運用

モニターやキーボードを直接接続せずに運用すること。操作が必要な場合は、リモートＳＳＨ（Ｓｅｃｕｒｅ ＳＨｅｌｌ）やリモートデスクトップを使ってネットワーク経由で接続する。」（１９５ページ左上欄３－８行）

「吉田：その通り。Ｐ社では、工場内のＩｏＴ端末が出すパケットを、Ｒａｓｐｂｅｒｒｙ ＰｉのＷｉｒｅｓｈａｒｋでキャプチャーしてモニタリングしているの（図１）。Ｒａｓｐｂｅｒｒｙ Ｐｉはヘッドレス運用で本社のパソコンからリモートデスクトップを使って遠隔操作しているわ。」（１９５ページ左下欄６－１３行）

【図１】「

［図：0001393908000001.jpg］

」

５ 引用文献５について

原査定の拒絶の理由に引用された引用文献５には、次の事項が記載されている。

「［Ｉｎｔｅｒｆａｃｅ］

キャプチャに使うデバイスを選択できます。解析するときに、複数のＡｉｒＰｃａｐを使って複数のチャンネルを同時にスニッフィングする場合があります。

［Ｂｌｉｎｋ Ｌｅｄ］

ＡｉｒＰｃａｐのＬＥＤを点滅させます。複数のＡｉｒＰｃａｐを使っているときに、どれを使っているかを示すためのものです。

［Ｃｈａｎｎｅｌ］

ここでは、ＡｉｒＰｃａｐを使ってキャプチャするチャンネルを選択します。」（１４１ページ１－８行）

第６ 対比・判断

１ 本願発明１について

（１）対比

本願発明１と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「Ｗｉｎｄｏｗｓノートパソコン」は、パケットキャプチャーを行うことから、通信に関する装置であることは明らかである。したがって、引用発明の「Ｗｉｎｄｏｗｓノートパソコン」は、本願発明１の「通信装置」に相当する。

イ 引用発明の「Ｗｉｎｄｏｗｓノートパソコン」は、パケットキャプチャーを行うことから、通信用のインタフェースを備えていることは明らかである。

ウ 引用発明の「パケット」は、通信に関するものであることが明らかであるから、本願発明の「通信パケット」に相当する。また、引用発明において、「パケットキャプチャーを行うＷｉｎｄｏｗｓノートパソコンであ」ることから、Ｗｉｎｄｏｗｓノートパソコンは、当該Ｗｉｎｄｏｗｓノートパソコンのパケットをキャプチャした動作の結果を得る処理部のような構成を備えていることは明らかである。したがって、上記アを踏まえると、引用発明の「Ｗｉｎｄｏｗｓノートパソコン」と、本願発明の「前記生成部が生成した前記１以上の疑似インタフェース識別子を、前記通信装置とは別体であり、前記通信装置の通信パケットをキャプチャした動作の結果を表示するモニタ装置にネットワークを介して送信し、送信した前記１以上の疑似インタフェース識別子のうちから選択された一の疑似インタフェース識別子を前記モニタ装置から前記ネットワークを介して受信する処理部」「を備える」こととは、「前記通信装置の通信パケットをキャプチャした動作の結果を得る処理部」を備える点で共通するといえる。

したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。

（一致点）

「通信装置であって、

通信用のインタフェースと、

前記通信装置の通信パケットをキャプチャした動作の結果を得る処理部とを備える

通信装置。」

（相違点１）

本願発明１では、「前記インタフェースに設定可能な１以上の設定情報に１対１に対応する１以上の疑似インタフェース識別子を生成する生成部」を備えるのに対し、引用発明では、このような構成について特定されていない点。

（相違点２）

本願発明１では、「前記生成部が生成した前記１以上の疑似インタフェース識別子を、前記通信装置とは別体であり、前記通信装置の通信パケットをキャプチャした動作の結果を表示するモニタ装置にネットワークを介して送信し、送信した前記１以上の疑似インタフェース識別子のうちから選択された一の疑似インタフェース識別子を前記モニタ装置から前記ネットワークを介して受信する処理部」を備えるのに対し、引用発明では、「Ｗｉｎｄｏｗｓノートパソコンとは別体であり、Ｗｉｒｅｓｈａｒｋのモニターモードのセットアップ済みのＬｉｎｕｘパソコンによりモニターされ」ているが、疑似インタフェース識別子に関する構成については特定されていない点。

（相違点３）

本願発明１では、「前記処理部が受信した前記一の疑似インタフェース識別子に対応する前記設定情報に基づく設定を前記インタフェースに適用した後に、当該設定に従った動作を行わせる制御部」を備えるのに対し、引用発明では、このような構成について特定されていない点。

（２）相違点についての判断

事案に鑑みて、上記相違点２について先に検討する。

上記第５の４の記載から、「モニタ装置を通信装置と別体とすること」は、本願の出願前において周知技術であったと認められる。

また、上記第５の５の記載から、「監視するインタフェースを複数とすること」は、本願の出願前において周知技術であったと認められる。

さらに、通信分野の技術常識に照らすと、「識別子が長い場合などに、別名を与えること」は、本願の出願前において周知技術であったと認められる。

しかしながら、上記周知技術を考慮しても、引用文献２－５には、上記相違点２に係る本願発明１の構成について記載も示唆もなく、この構成までが本願の出願前において周知技術であったともいえない。

したがって、当業者といえども、引用発明及び引用文献２－５に記載された技術的事項から、上記相違点２に係る本願発明１の構成を容易に想到することはできない。

よって、上記相違点１、３について判断するまでもなく、本願発明１は、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

２ 本願発明２－４について

本願発明２－４は、本願発明１と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

３ 本願発明５について

本願発明５は、上記相違点２に係る本願発明１の構成に対応する構成を実質的に備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

４ 本願発明６について

本願発明６は、実質的に、本願発明５と同一の構成を備えるものであるから、本願発明５と同じ理由により、当業者であっても、引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第７ 当審拒絶理由についての判断

令和４年１２月１４日付けの手続補正において、請求項１、５では、「・・・前記通信装置とは別体であるモニタ装置に送信し、・・・」を、「・・・前記通信装置とは別体であり、前記通信装置の通信パケットをキャプチャした動作の結果を表示するモニタ装置にネットワークを介して送信し、・・・」と補正され、また、「・・・前記モニタ装置から受信する・・・」を、「・・・前記モニタ装置から前記ネットワークを介して受信する・・・」と補正された結果、この拒絶の理由は解消した。

第８ むすび

以上のとおり、本願発明１－６は、当業者が引用発明及び引用文献２－５に記載された技術的事項に基づいて容易に発明をすることができたものではない。

したがって、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。