2019-015085

第１　手続の経緯

本願は，２０１５年（平成２７年）１０月３０日（優先権主張　平成２６年１０月３１日）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。

第２　令和元年１１月１１日にされた手続補正についての補正の却下の決定

［補正の却下の決定の結論］

令和元年１１月１１日にされた手続補正（以下，「本件補正」という。）を却下する。

［理由］

１　補正の概要

本件補正は，令和元年７月２５日にされた手続補正により補正された特許請求の範囲の請求項１に記載された

「　パケット送信装置が送信するパケットを，ネットワークを介して受信し，無線端末へ送信する無線基地局であって，

前記パケット送信装置が前記ネットワークにおけるプロトコルに従い前記パケットに設定したパケット種別又はパケット識別子を取得する取得手段と，

前記パケット種別又は前記パケット識別子に基づき，前記無線端末へ送信する前記パケットの送出順序を変更する送信制御を行う制御手段と，を有する，

ことを特徴とする無線基地局。」

との発明（以下，「本願発明」という。）を，

「　パケット送信装置が送信するパケットを，ネットワークを介して受信し，無線端末へ送信する無線基地局であって，

前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定したパケット種別又はパケット識別子を取得する取得手段と，

前記パケット種別又は前記パケット識別子に基づき，前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する送信制御を行う制御手段と，を有する，

ことを特徴とする無線基地局。」（下線は，補正箇所を示す。）

との発明（以下，「本願補正発明」という。）に補正することを含むものである。

２　補正の適否

（１）補正の目的要件

請求項１についての上記補正は，本件補正前の「ネットワークにおけるプロトコルに従い前記パケットに設定したパケット種別又はパケット識別子を」を，「前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定したパケット種別又はパケット識別子」と補正し，本件補正前の「前記無線端末へ送信する前記パケットの送出順序を変更する」を，「前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する」と補正するもので，「パケット種別又はパケット識別子」及び「送出順序を変更する送信制御を行う制御手段」を限定して，特許請求の範囲を減縮するものである。

したがって，上記補正は，特許法第１７条の２第５項第２号に掲げる事項を目的とするものである。

（２）独立特許要件

請求項１についての上記補正は，特許請求の範囲の減宿を目的とするものであるから，本件補正後の請求項１に係る発明が特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下，検討する。

ア　本願補正発明

本願補正発明は，上記「１　補正の概要」の項の「本願補正発明」のとおりのものと認める。

イ　引用発明

原査定の拒絶の理由で引用された原田裕一，ほか，「ＶｏＩＰ品質を保証するための動的ＭＡＣフレーム受信機会制御」，電子情報通信学会技術研究報告情報ネットワーク，日本，社団法人電子情報通信学会，２００９年９月３日，第１０９巻，第１８９号，第１３３－１３８ページ（以下，「引用例１」という。）には，図面とともに以下の事項が記載されている。なお，下線は当審で付与した。

（ア）

「ＭＡＣフレーム受信機会制御の制御パラメタであるフレーム受信拒否確率は，優先／非優先フローのトラフィック量等に応じて適応的に調整する必要がある。本研究では，音声通話のような双方向リアルタイムアプリケーションの品質を保証するためにＭＡＣフレーム受信機会制御を適用する場合において，ＡＰのバッファ占有状況を見ながらフレーム受信拒否確率を動的に制御する仕組みを提案し，その基本性能を評価する。さらに，ＭＡＣ層での制御に加えて，ＡＰバッファを優先／非優先トラフィック用にＩＰ層で分離し，Ｐｒｉｏｒｉｔｙ　Ｑｕｅｕｅを適用することが優先トラフィックの品質保証に極めて効果的であることを示す。」（第１３４ページ左欄第１２行－第２１行）

（イ）

「３．ＭＡＣフレーム受信機会制御

ＭＡＣフレーム受信機会制御（Ｒｅｃｅｉｖｅ　Ｏｐｐｏｒｔｕｎｉｔｙ　Ｃｏｎｔｒｏｌ　ｉｎ　ＭＡＣ　Ｆｒａｍｅ：以下　ＲＯＣ）を以下説明する。」（第１３４ページ右欄下第２行～第１３５ページ左欄第１行）

（ウ）

「３．２動作詳細

ＡＰは，接続中のフローを管理する。ＡＰはＭＡＣフレームを受信すると，（ＭＡＣ，ＩＰ，ＴＣＰ（ＵＤＰ））ヘッダ情報から当該フレームのフローを識別し，フローの要求ＱｏＳに従って制御のアクションを決定する。

フレーム受信拒否の最も単純な実現方法は，フロー毎に定められた確率に従ってランダムにフレーム受信拒否を行うものである。例えば，ＶｏＩＰフローのフレームは全て受信し，その他のフローについては一律２０％の確率で受信拒否を行う。このタイプの制御を「ランダム受信拒否型制御」と呼ぶ。」（第１３５ページ左欄第２１行－第３０行）

（エ）

「４．　ＶｏＩＰ品質保証用動的ＲＯＣ

本研究にて提案する音声通話品質を保証するための動的ＭＡＣフレームを受信機会制御について述べる。

４．１　Ｐｒｉｏｒｉｔｙ　Ｑｕｅｕｅ

本研究は，音声通話のようなリアルタイム双方向アプリケーションが優先トラフィックとして扱われるケースを考察する。音声通話は上り下り1本ずつのＶｏｉｃｅ　ｏｖｅｒＩＰ（ＶｏＩＰ）フローから構成されるため，無線ＬＡＮ上で音声通話が行われると，上り方向（端末→ＡＰ）と下り方向（ＡＰ→端末）それぞれに同量のＶｏＩＰトラフィックが加わる。既に述べたように，ＩＥＥＥ８０２．１１ＤＣＦでは端末とＡＰに公平に無線チャネルアクセスの機会が与えられるが，下り方向のトラフィックが集中するＡＰはボトルネックとなりやすい。特に，下り方向のＩＰパケットを一時蓄積するバッファにおいて，バッファ待ち遅延やバッファ溢れが発生しやすい。ボトルネックとなるＡＰにおいてＶｏＩＰトラフィックを他のトラフィックよりも優先的に処理するため，本研究では，ＡＰでＩＰパケットを一時蓄積するバッファを優先トラフィック用と非優先トラフィック用に分け，優先トラフィックに絶対的な処理優先権を与えるＰｒｉｏｒｉｔｙ　Ｑｕｅｕｅを適用することとする。

Ｐｒｉｏｒｉｔｙ Ｑｕｅｕｅでは，優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間は，（ＭＡＣ層が空になるたびに）常に優先トラフィック用バッファの先頭のＩＰパケットが処理され，非優先パケットが処理されるのは優先トラフィック用バッファが空のときのみである（図３）。ＭＡＣ層に渡されたＩＰパケットはそこでフレーム化され，２．２章で説明したＩＥＥＥ８０２．１１ＤＣＦの手順に従って無線端末に送信される。」（第１３５ページ左欄下第３行～右欄第２３行）

（オ）

図３

」

上記（ア）―（エ）の記載，及び（オ）の図面，並びに当業者の技術常識を考慮すると，

ａ　上記（エ）の４．１の「ＭＡＣ層に渡されたＩＰパケットはそこでフレーム化されＩＥＥＥ８０２．１１ＤＣＦの手順に従って無線端末に送信される」との記載から「ＩＰパケットを無線端末へ送信する」ことがいえ，さらに，４．１の「ボトルネックとなるＡＰにおいてＶｏＩＰトラフィックを他のトラフィックよりも優先的に処理するため，本研究では，ＡＰでＩＰパケットを一時蓄積するバッファを優先トラフィック用と非優先トラフィック用に分け，優先トラフィックに絶対的な処理優先権を与えるＰｉｏｒｉｔｙ　Ｑｕｅｕｅを適用することとする。」との記載から，「ＡＰが処理を行う」ことがいえ，ＡＰがＩＰパケットを送信することは明らかであるから，引用例１には「ＩＰパケットを無線端末に送信するＡＰ」が記載されている。

ｂ　上記（ア）の音声通話のような双方向リアルタイムアプリケーションの品質を保証するためにＭＡＣフレーム受信機会制御を適用する場合において，ＡＰのバッファ占有状況を見ながらフレーム受信拒否確率を動的に制御する仕組みを提案し，その基本性能を評価する。さらに，ＭＡＣ層での制御に加えて，ＡＰバッファを優先／非優先トラフィック用にＩＰ層で分離し，Ｐｒｉｏｒｉｔｙ　Ｑｕｅｕｅを適用することが優先トラフィックの品質保証に極めて効果的であることを示す。」との記載から，引用例１には，３．のＭＡＣフレーム受信機会制御と４．１のＰｒｉｏｒｉｔｙ　Ｑｕｅｕｅの双方を含むことが記載されている。また，３．２の「ＡＰは，接続中のフローを管理する。ＡＰはＭＡＣフレームを受信すると，（ＭＡＣ，ＩＰ，ＴＣＰ（ＵＤＰ））ヘッダ情報から当該フレームのフローを識別し，フローの要求ＱｏＳに従って制御のアクションを決定する。」と４．１の「ＩＰパケットを一時蓄積するバッファを優先トラフィック用と非優先トラフィック用にわけ」との記載から，引用例１には，ＡＰは「ＭＡＣフレームを受信すると，（ＭＡＣ，ＩＰ，ＴＣＰ（ＵＤＰ））ヘッダ情報から当該フレームのフローを識別すること」が記載されている。

ｃ　上記（エ）の４．１に，「特に，下り方向のＩＰパケットを一時蓄積するバッファにおいて，バッファ待ち遅延やバッファ溢れが発生しやすい。ボトルネックとなるＡＰにおいてＶｏＩＰトラフィックを他のトラフィックよりも優先的に処理するため・・・ＡＰでＩＰパケットを一時蓄積するバッファを優先トラフィック用と非優先トラフィック用に分け，・・・優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間は・・・常に優先トラフィック用バッファの先頭のＩＰパケットが処理され・・・ＭＡＣ層に渡されたＩＰパケットはそこでフレーム化」を行うことが記載されていることから，引用例１には，ＡＰは，「下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け，優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間，常に優先トラフィック用バッファの先頭のＩＰパケットが処理されＭＡＣ層に渡されたＩＰパケットはそこでフレーム化される」ことが記載されている。

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

「　ＩＰパケットを無線端末に送信するＡＰであって，

ＭＡＣフレームを受信すると，（ＭＡＣ，ＩＰ，ＴＣＰ（ＵＤＰ））ヘッダ情報から当該フレームのフローを識別し，

下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け，優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間，常に優先トラフィック用バッファの先頭のＩＰパケットが処理され，ＭＡＣ層に渡されたＩＰパケットがそこでフレーム化されるＡＰ。」が記載されていると認める。

ウ　周知技術

（ア）周知例１

本願の優先日前に公知となった特表２０１０－５３８５１６号公報（以下，「周知例１」という。）には，図面とともに，以下の事項が記載されている。（下線は当審が付与。）

「【００５８】

３ＧＰＰ　ＬＴＥにおいて，音声データ（ＲＴデータ）は，ボイスオーバーインターネットプロトコル（ＶｏＩＰ）を用いて送信される。ＶｏＩＰトラフィックパターンには，独自の特徴がある。これらの特徴には，（２０ｍｓにつき１回の一定間隔において）周期的な小さいＶｏＩＰデータパケットを使用すること，および，適応多重レート（ＡＭＲのような先進の音声符号化／復号（コーデック）方式によって生成された周期的な無音指示（ＳＩＤ）パケットを使用することが含まれる。ＡＭＲは，音声符号化用に最適化された音声データ圧縮方式であり，標準的な音声コーデックとして，３ＧＰＰに採用されている。典型的なＶｏＩＰトラフィックパターンを図５に示す。双方向の音声通信の場合，一方が話しているときには，他方は聞いていることが一般的である。従って，例えば，「有音」と呼ばれることもあるＤＬの音声バーストが，ＵＬ無音期間と同時に生じることになる。このため，２つの異なる周期が存在する。つまり，有音期間と無音期間とである。有音期間中には，２０ｍｓ毎にＶｏＩＰパケットが到着するが，無音期間中には，１６０ｍｓ毎にＳＩＤパケットが到着する。」

「【００７０】

ＵＥがＣＱＩのＵＬ送信を終了させることを可能にするため，および，ｅＮＢがＰＵＣＣＨリソースを複数の他のＵＥに再割り当てすることを可能にするために，ＵＥおよびｅＮＢの両方が，いつＤＬ無音期間が開始するかを知る方法を必要としている。例えば，図６では，ｅＮＢおよびＵＥは，ＤＬ有音３０１の終了時のＤＬ　ＳＩＤ３５０およびＤＬ有音３０５の終了時のＤＬＳＩＤ３５６を識別可能である必要がある。

【００７１】

図７を参照して説明する一技術では，ｅＮＢおよびＵＥの両方が，ＩＰパケットペイロードを検査して，該パケットがＳＩＤまたは音声データであるかを判定することが可能である。図７に示すように，一般的なＡＭＲコーデックフレーム構成６００は，フレームタイプフィールドを備えるヘッダ６０２を含む。このフレームタイプフィールドは，音声データまたはＳＩＤであるフレームを識別する。従って，ＳＩＤであるＡＭＲフレームが，ＡＭＲヘッダの検査から識別され得る。同様に，音声データであるＡＭＲフレームが，ＡＭＲヘッダの検査から識別され得る。３ＧＰＰ　ＬＴＥでは，ｅＮＢは，ＰＤＣＰ層２１５（図２参照）を含む。このＰＤＣＰ層２１５は，ＡＭＲフレームをＩＰパケットのペイロード部分６１２に変換し，ＩＰヘッダ６１４を付加する。ＰＤＣＰ層２１５は，ＩＰヘッダを典型的には４０バイトから２または４バイトに圧縮して，圧縮されたＩＰヘッダ６１６を形成するが，ＩＰペイロード部分６１２は圧縮されない。従って，ＩＰペイロード６１２は，ＰＤＣＰによるヘッダ圧縮の後も，依然としてＳＩＤとして識別されうる。ヘッダ圧縮の後，ＰＤＣＰは，暗号化を行って，暗号化されたＩＰパケット６１８を形成する。暗号化されたＩＰパケット６１８は，暗号化されたペイロード部分を含む。このためＩＰペイロードは，もはやｅＮＢによってＳＩＤとして識別されることができない。従って，本発明では，ｅＮＢは，ＰＤＣＰによる暗号化の前のどこかの時点で各ＩＰパケットペイロードを検査して，ＳＩＤであるこれらのＩＰパケットにフラグ付けする。その後，ＰＤＣＰ層２１５は，暗号化されたＩＰパケット６１８を，ＲＬＣヘッダ６２１を有するプロトコルデータユニット（ＰＤＵ）６１９へとさらに加工するためにＲＬＣ層２１６に渡し，その後，ｅＮＢのＭＡＣ層２１８に渡す。ＭＡＣ層２１８は，暗号化されたＶｏＩＰパケット６１９を，ＭＡＣ　ＰＤＵヘッダ６２２とＰＤＵ６２４とを含むＭＡＣプロトコルデータユニット（ＰＤＵ）に変換する。その後，このＭＡＣ　ＰＤＵは，矢印６２６で示すようにＵＥに送信される。」

「【図２】

【図６】

【図７】

前記【００７１】の「音声データ」は，前記【００５８】の「音声データ（ＲＴデータ）は，ボイスオーバーインターネットプロトコル（ＶｏＩＰ）を用いて送信される。」との記載を考慮すると「ＶｏＩＰパケット」ということができる。さらに，前記【００７１】の「ＩＰパケットペイロードを検査して，該パケットがＳＩＤまたは音声データであるかを判定することが可能である。図７に示すように，一般的なＡＭＲコーデックフレーム構成６００は，フレームタイプフィールドを備えるヘッダ６０２を含む。このフレームタイプフィールドは，音声データまたはＳＩＤであるフレームを識別する。」との記載を合わせて考慮すると，周知例１には，ＩＰパケットペイロードのＡＭＲコーデックのヘッダの検査からＶｏＩＰパケットを識別することが記載されているといえる。

ここで，ＩＰパケットペイロードを検査していることから，前記「識別」はＩＰレイヤで行われていることは明らかであり，ＡＭＲコーデックのヘッダは，ＩＰレイヤの上位のレイヤで設定したものであることは技術常識である。してみれば，周知例１には，「ＩＰレイヤにおいてＩＰパケットペイロードを検査して，ＩＰレイヤの上位のレイヤで設定したＶｏＩＰパケットを識別する。」ことが記載されていると認める。

（イ）周知例２

本願の優先日前に公知となった特開２００７－１６６２９４号公報（以下，「周知例２」という。）には，図面とともに，以下の事項が記載されている。（下線は当審が付与。）

「【００２５】

（複数回読み込みの構成）　図４は，マルチキャスト宛先テーブルを複数回読み込む本実施の形態におけるルータ１０１の構成例を示す図である。

ルータ１０１は，入力部４１０と，パケット転送／複製部４０３と，宛先検索部４０４と，宛先情報テーブル４０５と，スイッチ４０６と，出力部４２０とを備える。入力部４１０は，例えば，入力ポートに対応した受信キュー４０１とラウンドロビンスケジューラ４０２とを有する。出力部４２０は，例えば，出力ポートに対応した送信キュー４０７及び送信制御部４０８を有する。ルータ１０１は，スケジューリング設定部４０９をさらに備えてもよい。」

「【００３４】

フロー検出／優先度指定部５０１は，パケット転送／複製部４０３からのパケットヘッダ情報の組合せによりフローを検出し，フロー毎に処理の優先度を指定する。例えば，フロー検出／優先度指定部５０１は，パケットヘッダ情報の組合せによりＶｏＩＰのフローを検出し，ＶｏＩＰのフローの優先度を高く指定する。例えば，優先度情報を「高」と設定する。また，フロー検出／優先度指定部５０１は，パケットヘッダ情報の組合せによりマルチキャストのフローを検出し，マルチキャストのフローの優先度を低く指定する。例えば，優先度情報を「低」と設定する。また，フロー検出／優先度指定部５０１は，入力されたヘッダ情報と優先度情報とを宛先情報テーブルポインタ検索部５０２に出力する。なお，フロー検出／優先度指定部５０１は，ＶｏＩＰ以外にも適宜の音声パケットの優先度情報を「高」としてもよい。これら以外にも適宜のパケットの優先度情報を「高」又は「低」と設定してもよい。また，本実施の形態では，「高」と「低」の２段階に設定しているが，複数の優先度を設定し，優先度毎の複数のキューにキューイングするようにしてもよい。」

【図４】

前記【００２５】及び【００３４】の記載から，周知例２において，ルータは，パケットの「パケットヘッダ情報の組み合わせによりフローを検出」するものである。ここで，一般にルータはＩＰパケットを宛先に中継するものであるところ，前記受信したパケットはＩＰパケットである。したがって，周知例２においてＩＰパケットを処理するＩＰレイヤにおいてパケットヘッダ情報の組み合わせにより当該フロー検出を行っていることは明らかである。そして，ＶｏＩＰ等のフローのパケットヘッダ情報は，ＩＰレイヤより上位のレイヤにて設定したものを含むものであることも明らかである。また，ＶｏＩＰのフローはＶｏＩＰのパケットからなることから，ＶｏＩＰのフローを検出することは，ＶｏＩＰのパケットを検出することにほかならない。してみれば，周知例２には，「ＩＰレイヤにおいて，ＩＰレイヤより上位のレイヤにて設定したものを含むパケットヘッダ情報からＶｏＩＰのパケットを検出する。」ことが記載されていると認める。

（ウ）周知技術

周知例１のＶｏＩＰパケット及び，周知例２のＶｏＩＰのパケットは，いずれもパケットの種別ということができるから，周知例１及び２より，「ＩＰレイヤにおいて，ＩＰレイヤより上位のレイヤにて設定したパケットの種別を識別する。」ことは，周知であると認める。

エ　対比・判断

（ア）引用発明の「ＡＰ」は，本願補正発明の「無線基地局」に相当する。引用発明の「ＩＰパケット」は本願補正発明の「パケット」に含まれる。また，引用発明はＶｏＩＰパケットを送受信することは明らかであり，ＶｏＩＰでは，ダウンリンクパケットは，ＶｏＩＰパケットを送信する装置からネットワークを介してＡＰが受信するものであることも明らかである。してみれば，引用発明の「ＩＰパケットを無線端末に送信するＡＰ」は，本願補正発明の「パケット送信装置が送信するパケットを，ネットワークを介して受信し，無線端末へ送信する無線基地局」との点で共通する。

（イ）引用発明の「ＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け」との事項より，引用発明のＡＰはＩＰパケットを取得する手段を有し，当該ＩＰパケットから優先トラフィック（ＶｏＩＰ）と非優先トラフィックという，パケット種別を取得していることは明らかである。してみれば，本願発明の「前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定したパケット種別又はパケット識別子を取得する取得手段」と引用発明の前記事項は，「前記パケットのネットワークにおけるパケット種別を取得する取得手段」との点で共通する。

（ウ）引用発明の「下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け」との事項により，当該分ける処理がＩＰレイヤで行われていることは明らかである。そして，引用発明は，「優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間，常に優先トラフィック用バッファの先頭のＩＰパケットが処理され，ＭＡＣ層に渡されたＩＰパケットがそこでフレーム化される」のであるから，送出順序を変更する送信制御をおこなっているものといえ，当該処理を行う制御手段を備えることは明らかである。

また，引用発明の「下り方向のＩＰパケット」は，無線端末へ送信する際のパケットに含まれることは明らかである。

してみれば，本願補正発明の「前記パケット種別又は前記パケット識別子に基づき，前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する送信制御を行う制御手段」と引用発明の「下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け，優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間，常に優先トラフィック用バッファの先頭のＩＰパケットが処理され，ＭＡＣ層に渡されたＩＰパケットがそこでフレーム化される」とでは，「前記パケット種別に基づき，送出順序を変更する送信制御を行う制御手段」との点で共通する。

以上を総合すると，本願補正発明と引用発明とでは，以下の点で一致，又は，相違する。

（一致点）

「　パケット送信装置が送信するパケットを，ネットワークを介して受信し，無線端末へ送信する無線基地局であって，

前記パケットのネットワークにおけるパケット種別を取得する取得手段と，

前記パケット種別に基づき，送出順序を変更する送信制御を行う制御手段と，を有する

無線基地局。」

（相違点１）

前記一致点の，「前記パケットのネットワークにおけるパケット種別を取得する取得手段」，及び，「前記パケット種別に基づき，送出順序を変更する送信制御を行う制御手段と」に関し，本願補正発明では，「パケット種別又はパケット識別子」を取得し，それらに基づき送出順序を変更するものであるが，引用発明ではパケット種別には基づくが,パケット識別子については特定がない点で相違する。

（相違点２）

前記一致点の「前記パケットのネットワークにおけるパケット種別を取得する取得手段」に関し，本願補正発明は「前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定したパケット種別又はパケット識別子を取得する取得手段」であって，本願補正発明における「パケット種別又はパケット識別子」は，「前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定」するものであるのに対し，引用発明では，当該点について特定がない点で相違する。

（相違点３）

前記一致点の「前記パケット種別に基づき，送出順序を変更する送信制御を行う制御手段」に関し，本願補正発明の制御手段は「前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する」のに対し，引用発明では，「下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け，優先トラフィック（ＶｏＩＰ）用バッファにＩＰパケットが存在する間，常に優先トラフィック用バッファの先頭のＩＰパケットが処理され，ＭＡＣ層に渡されたＩＰパケットがそこでフレーム化される」ものである点，すなわち，引用発明ではＩＰ層で送出順序を変更するものであるが，本願補正発明の「前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する」点は特定されていない点で相違する。

上記相違点について，検討する。

（相違点１）

本願補正発明において，「パケット種別又はパケット識別子」との事項に関する記載は，

「前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定したパケット種別又はパケット識別子を取得する取得手段と，

前記パケット種別又は前記パケット識別子に基づき，前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する送信制御を行う制御手段」

というものであり，いずれも択一的な記載であることから，前記（イ）で検討したとおり「パケット種別」について相当する事項が認められる引用発明との間に実質的な相違点はない。さらに進めて，パケット識別子について検討すると，ＶｏＩＰパケットでは，ＩＰレイヤより上位のレイヤにおいてヘッダとともに音声データが作成され，当該ヘッダにはＶｏＩＰ情報であることを示す情報が含まれていることは技術常識である。そして，当該情報を「パケット識別子」と称することは当業者が適宜なし得た事項である。

（相違点２）

一般にＶｏＩＰでは，端末装置間でＶｏＩＰパケットを作成し，ネットワークを介して送受信するものであるところ，パケットの送信を行う装置でＶｏＩＰパケットを作成することは当然である。また，ＶｏＩＰパケットでは，ＩＰレイヤより上位のレイヤにおいてヘッダとともに音声データが作成され，前記ＶｏＩＰパケットのペイロードに格納されることは技術常識であるから，引用発明に特定はないものの，引用発明において，パケット送信装置がプロトコルスタックのＩＰレイヤより上位のレイヤにおいてヘッダとともに音声データを作成することは，引用発明に示唆されているといえる。また，ＩＰレイヤより上位のレイヤを第１のレイヤと称することは適宜なしえることであるから，引用発明において，「前記パケット送信装置が前記パケットの前記ネットワークにおけるプロトコルスタックの第１のレイヤに設定」したパケット種別又はパケット識別子を取得する取得手段とすることは，当業者が容易に想到することができた事項である。

（相違点３）

引用発明には「ＭＡＣフレームを受信すると」すなわちＡＰがアップリンクのフレームを受信すると，（ＭＡＣ，ＩＰ，ＴＣＰ（ＵＤＰ））ヘッダ情報から当該フレームのフローを識別することが特定されている。すなわち，アップリンクの場合ではある（無線端末へ送信する場合ではない）ものの，ＭＡＣレイヤにおいてＭＡＣレイヤより上位のレイヤのヘッダ情報から当該フレームのフローを識別することが特定されている。また，前記ウ（ウ）で検討したように「ＩＰレイヤにおいて，ＩＰレイヤより上位のレイヤにて設定したパケットの種別を識別する。」ことは周知である。このように，アップリンク，ダウンリンクにかかわらず，上位レイヤのヘッダ情報からパケット種別を取得することは，周知であるから，引用発明の「下り方向のＩＰパケットを優先トラフィック（ＶｏＩＰ）用と非優先トラフィック用のバッファに分け」る際に当該技術が用いられることは，当業者が容易に想到することができた事項である。そして，引用発明において，ＩＰパケットの送出順序を変更するのはＩＰレイヤといえ，前記相違点２についての検討で示したとおり，ＩＰレイヤより上位のレイヤを第１のレイヤと称することは適宜なしえることである。

してみれば，引用発明において，「前記パケットの前記無線端末へ送信する際のプロトコルスタックにおける前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する」ものとすることは，当業者が容易に想到することができた事項である。

さらに，本願補正発明の作用効果も，引用発明に基づいて当業者が予測できる範囲のものである。

したがって，本願補正発明（本件補正の請求項１に係る発明） は，引用発明，及び，周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許を受けることができない 。

［請求人の主張について］

請求人は審判請求書の「（４）本願発明と引用発明との対比」において，

「具体的には，「パケット送信装置が送信するパケットを，ネットワークを介して受信し，無線端末へ送信する」ための従来技術では，無線基地局と無線端末との間の無線区間におけるパケット（ＰＤＣＰパケット）のシーケンス番号と，無線基地局までのネットワーク区間におけるパケット（ＴＣＰパケット）のシーケンス番号とが，異なるものを使用していたので，ユーザーが利用する無線端末には，必ずしも好ましい順序でパケットが到達しないという問題があります（［発明が解決しようとする課題］および［００５６］等参照）。

・・・中略・・・

また，引用文献１および引用文献２は，どちらも単に無線区間における優先順位を制御する技術に関するものであるので，上記したような「無線区間におけるパケット（ＰＤＣＰパケット）のシーケンス番号と，無線基地局までのネットワーク区間におけるパケット（ＴＣＰパケット）のシーケンス番号とが，異なる」という課題が生じることもありません。したがいまして，如何に当業者といえども引用文献１および引用文献２に記載の技術に基づいて，本願発明のような「第１のレイヤに設定したパケット種別又はパケット識別子を取得」し，「前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する送信制御を行う」構成を容易に想到することはできなかったと思料いたします。」

と主張している。

しかしながら，本願補正発明には「無線区間におけるパケット（ＰＤＣＰパケット）のシーケンス番号」及び「ネットワーク区間におけるパケット（ＴＣＰパケット）のシーケンス番号」に関する記載は存在しないから，請求人の上記の主張は本願補正発明に関するものではない。

更に，（相違点１），（相違点２），（相違点３）について検討したとおり，引用発明において「第１のレイヤに設定したパケット種別又はパケット識別子を取得」し,「前記第１のレイヤよりも下位の第２のレイヤで送出順序を変更する送信制御を行う」ことは当業者が容易に想到しうることである。

よって，請求人の主張を採用することはできない。

３　結語

したがって，本件補正は，特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に違反するものであるから，特許法第１５９条第１項において読み替えて準用する特許法第５３条第１項の規定により却下すべきものである。

第３　本願発明について

１　本願発明

令和元年１１月１１にされた手続補正は上記のとおり却下されたので，本願発明は，上記「第２」の項の「１　補正の概要」の項の「本願発明」のとおりのものと認める。

２　原査定の拒絶の理由

原査定の拒絶理由の概要は，

「（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。」

というものであり，請求項１に対して引用例１（原田裕一，ほか，「ＶｏＩＰ品質を保証するための動的ＭＡＣフレーム受信機会制御」，電子情報通信学会技術研究報告情報ネットワーク，日本，社団法人電子情報通信学会，２００９年９月３日，第１０９巻，第１８９号，第１３３－１３８ページ）が引用されている。

３　引用発明及び周知技術

引用発明，周知技術は，上記「第２　令和元年１１月１１日に手続補正についての補正の却下の決定」の項中の「（２）イ　引用発明」，「（２）ウ　周知技術」の項で認定したとおりである。

４　対比・判断

本願発明と引用発明とを対比するに，本願発明は，本願補正発明から当該補正に係る限定を省いたものである。

そうすると，本願発明の構成に当該補正に係る限定を付加した本願補正発明が，「第２　令和元年１１月１１日にされた手続補正についての補正の却下の決定」の項中の「２　補正の適否」の項中の「（２）エ　対比・判断」の項で検討したとおり，当業者が引用発明に基づいて容易に発明できたものであるから，本願発明も同様の理由により，引用発明に基づいて容易に発明できたものである。

５　むすび

以上のとおり,本願発明（本源の請求項１に係る発明）は,特許法２９条２項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。

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