2016-008789

特願２０１４－１４４５２９「バッファ状態報告の報告方法、取得方法、端末、基地局及び通信システム」拒絶査定不服審判事件〔平成２６年１０月１６日出願公開，特開２０１４－１９７９０７〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 第１　手続の経緯 本願は，２０１０年（平成２２年）６月１８日を国際出願日として出願した特願２０１３－５１４５２３号の一部を，平成２６年７月１４日に新たに出願したものであって，平成２７年８月２５日付けで拒絶理由が通知され，同年１０月３０日付けで意見書及び手続補正書が提出され，平成２８年３月８日付けで拒絶査定されたところ，同年６月１４日に拒絶査定不服審判の請求がなされ，同時に手続補正がなされたものである。 第２　平成２８年６月１４日付けの手続補正についての補正の却下の決定 ［補正の却下の決定の結論］ 平成２８年６月１４日付けの手続補正（以下，「本件補正」という。）を却下する。 ［理由］ １　本件補正の概要 本件補正は，平成２７年１０月３０日付け手続補正書の特許請求の範囲の請求項１に記載された 「【請求項１】 端末であって、 前記端末のバッファにおけるデータ量区間を示す第一テーブルと、 前記端末の前記バッファにおけるデータ量区間を示し、前記第一テーブルの最大データ量よりも大きい最大データ量を有する少なくとも一つの第二テーブルと、 前記端末の類型に基づいて、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから一つのテーブルを選択するテーブル選択ユニットと、 前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルからインデックスを確定するインデックス確定ユニットと、 前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニットと、 を含み、 前記テーブル選択ユニットは、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから選択した前記一つのテーブルを、ロジカルチャネル識別子を含むメディアアクセス制御シグナリングにより前記基地局へ通知し、前記インデックスは、前記端末の前記バッファにおけるデータ量を示すバッファサイズであって、前記第一テーブル及び前記少なくとも一つの第二テーブルから選択されたバッファサイズを示す、端末。」 を， 「【請求項１】 端末であって、 前記端末のバッファにおけるデータ量区間を示す第一テーブルと、 前記端末の前記バッファにおけるデータ量区間を示し、前記第一テーブルの最大データ量よりも大きい最大データ量を有する少なくとも一つの第二テーブルと、 前記端末の類型に基づいて、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから一つのテーブルを選択するテーブル選択ユニットと、 前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルからインデックスを確定するインデックス確定ユニットと、 前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニットと、 を含み、 前記テーブル選択ユニットは、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから選択した前記一つのテーブルを、ロジカルチャネル識別子を含むメディアアクセス制御シグナリングにより前記基地局へ通知し、前記インデックスは、前記端末の前記バッファにおけるデータ量を示すバッファサイズであって、前記第一テーブル及び前記少なくとも一つの第二テーブルから選択された前記一つのテーブルにおけるバッファサイズを示す、端末。」 に補正することを含むものである（下線部は，補正箇所を示す。）。 以下，本件補正後の請求項１の記載事項により特定される発明を「本願補正発明」という。 ２　本件補正の適否 本件補正は，上記のとおり請求項１についての補正を含むものであり，審判請求書の「１、補正について」においても記載されているように，特許法第１７条の２第５項第２号に規定する特許請求の範囲の減縮を目的とするものに該当する。 そこで，本願補正発明は，特許出願の際独立して特許を受けることができるものであるのか否か（特許法第１７条の２第６項において準用する同法１２６条７項の規定に適合するか否か）について，以下検討する。 （１）引用発明及び周知技術 ア　引用発明 原査定（平成２８年３月８日付け拒絶査定）の拒絶の理由に引用された，Ｎｏｋｉａ　Ｓｉｅｍｅｎｓ　Ｎｅｔｗｏｒｋｓ，Ｎｏｋｉａ　Ｃｏｒｐｏｒａｔｉｏｎ，ＢＳＲ　ｆｏｒ　Ｃａｒｒｉｅｒ　Ａｇｇｒｅｇａｔｉｏｎ （当審訳：キャリアアグリゲーションのためのＢＳＲ）［ｏｎｌｉｎｅ］，３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　Ｍｅｅｔｉｎｇ　＃７０　Ｒ２－１０２８０５，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｒａｎ／ＷＧ２＿ＲＬ２／ＴＳＧＲ２＿７０／Ｄｏｃｓ／Ｒ２－１０２８０５．ｚｉｐ＞（利用可能日：２０１０年５月１４日。以下，「引用文献」という。）には，次の事項が記載されている（なお，当審訳の下線は，当審にて付したものである。）。 （ア）「 」（第１ページ第７行ないし第２ページ第７行） （当審訳： 「１　導入 ＨＳＵＰＡ［１］［２］と同様に，ＬＴＥ　Ｒｅｌ－８のＢＳＲテーブルについては，指数関数的に分散した粒度と，期待されるレスポンスタイムによって乗算されたアップリンクピークデータレートに基づいて導かれる最大バッファサイズレベルとが，定められた［３］［４］。Ｒｅｌ－１０では，複数のＵＬキャリアが構成されることの，及び，ＵＬ　ＭＩＭＯの可能性にともない，アップリンクピークデータレートは幾倍にも増加し得るものであり，ゆえに，ＢＳＲの拡張が必要かどうかについて議論する必要がある。」 ２　ＣＡのためのＢＳＲフォーマット ｅＮＢは，ＢＳ＞１５０キロバイトに達したとき，設定される／割り当てられる必要がある追加のリソースがどのくらいなのかについての更なる情報を得る方法がないため，スケジューリングの観点からみて，一つのＵＬ　ＣＣを仮定している最大値に基づく現在のＢＳＲテーブルは，ＣＡとＵＬ　ＭＩＭＯにとって十分ではない。 もし最大バッファサイズレベルが，７５３７６ビットの最大トランスポートブロックサイズ［５］，２つのＲＴＴのレスポンスタイム，５つのＵＬ　ＣＣ［６］，ＣＣあたり２つのＴＢで，バッファ状態レポートが送信された後のアップリンクピークデータレートと，期待されるレスポンスタイムとに基づいて導かれるものであるとすれば，Ｅ－ＵＴＲＡアップリンクにおける最大バッファサイズレベルは，Ｂｍａｘ＝（７５３７６×１６×５×２）／８＝１５７５２×１０バイト　＃　１５０×１０キロバイトとなる。 一つの可能性として，ＢＳサイズを７ビットに拡張することがあり得る。不幸なことに，この率直な解決法は，ｓｈｏｒｔ　ＢＳＲ及びｌｏｎｇ　ＢＳＲフォーマットと互換性がなく，ゆえに，もし避けられないのであれば，このことのみが考慮されるべきである。 提案１：ＬＣＧごとのＳｈｏｒｔ／Ｌｏｎｇ　ＢＳＲフォーマット，すなわち，２ビットのＬＣＧ　ＩＤと，６ビットのＢＳサイズ，を再利用する。 ある代替案は，６ビットのＢＳサイズを変更しないで保ちつつ，粒度を下げて最大値を拡大することによって，テーブルを拡張し得る［７］。実際には，ＵＬ　ＭＩＭＯを伴わない１つのＵＬ　ＣＣは，Ｒｅｌ－１０であっても依然として典型的なケースであるため，１つのＵＬ　ＣＣのみがＵＬ　ＭＩＭＯなしで設定されるとき，正確でなくなることのペナルティをともなって，最大値を１０倍に拡張することは，受け入れられないであろう。不正確さがスケジューリング効率に対してどの程度インパクトを与えるかは，ｅＮＢスケジューリングアルゴリズムに強く依存するにもかかわらず，我々は，Ｒｅｌ－１０の仕様が，ＣＡが設定されていないＵＥ，又は，ＣＡが可能でないＵＥにとって，以前のリリースよりも劣らず効率的なスケジューリングを提供することを，期待し得る。更に，Ｒｅｌ－８／９　ＢＳＲテーブルを修正することは，Ｒｅｌ－８／９ネットワークでＲｅｌ－１０のＵＥがスケジュールされたときの，後方互換性の問題があり得る。 他の代替案は，より正確な情報を提供するための，異なる最大値及び粒度を有する複数のテーブル，例えば，少なくとも一つのＲｅｌ－８／９と同じテーブルとＲｅｌ－１０でサポートされるアップリンクピークデータレートをサポートするもう一つの新しいテーブルとを持たせることである。後方互換性の問題を避けるために，新しいテーブルは，Ｒｅｌ－１０の特徴，例えばＣＡ／ＵＬ－ＭＩＭＯ，が設定されたときにのみ用いられる。 提案２：５００Ｍｂｐｓ　ＵＬデータレートをサポートするために新しいＢＳＲテーブルを導入する。 提案３：新しいテーブルは，Ｒｅｌ－１０の特徴，例えばＣＡ／ＵＬ－ＭＩＭＯ，が構成されたときに用いられる。 複数のテーブルが利用できるとき，ＵＥは，現在のバッファ状態に従いテーブルを選択し，また，例えばＭＡＣサブヘッダ中のＲビットを経由して，ｅＮＢに，どれが用いられたかを示すことができる。ＵＥは，ｅＮＢに最も正確な情報を提供することができるように，テーブルを選ぶ。しかしながら，ＭＡＣサブヘッダには２つのＲビットしか存在せず，それは４つのＬＣＧのＬｏｎｇ　ＢＳＲにどのテーブルが用いられているのかを示すには十分ではないから，ゆえに，全てのＬＣＧのｌｏｎｇ　ＢＳＲは，同じＢＳＲテーブルを用いなければならない。単純な基準は，最もデータをバッファしているＬＣＧに対応するテーブルを選択し得る。代替として，ＢＳＲをトリガしたＬＣＧが，ＢＳＲテーブルもセットし得る。 提案４：ＵＥは，現在のバッファ状態に従ってテーブルを選択し，また，どのテーブルが使われたかをｅＮＢに示す。 ３　ＣＡのためのＢＳＲトリガ 閾値ベースのＢＳＲトリガについては，Ｒｅｌ－８で，非常に多くの協力的な会社の間で広く議論された［８］。 ＣＡの文脈においてスケジューラで利用されるより多くの次元のリソースを用いて，例えば，いつバッファステータスが超過し，何が現在の設定／割り当てられたリソースでサポートされ得るのかを遅滞無くｅＮＢに知らせるための，閾値ベースのＢＳＲは，より柔軟／効率的なスケジューリングを実現し得る。我々は，Ｒｅｌ－１０に関し，閾値ベースのトリガを導入することを提案する。 提案５：閾値ベースのＢＳＲトリガがサポートされるべきである。」） よって，引用文献には，「ｅＮＢは，ＢＳ＞１５０キロバイトに達したとき，設定される／割り当てられる必要がある追加のリソースがどのくらいなのかについての更なる情報を得る方法がないため，スケジューリングの観点からみて，一つのＵＬ　ＣＣを仮定している最大値に基づく現在のＢＳＲテーブルは，ＣＡとＵＬ　ＭＩＭＯにとって十分ではない」という課題を解決するための，以下の発明（以下，「引用発明」という。）が記載されている。 「ＵＥであって， ＬＣＧごとのＳｈｏｒｔ／Ｌｏｎｇ　ＢＳＲフォーマット，すなわち，２ビットのＬＣＧ　ＩＤと，６ビットのＢＳサイズ，を再利用し， 異なる最大値及び粒度を有する複数のテーブル，例えば，少なくとも一つのＲｅｌ－８／９と同じテーブル及びＲｅｌ－１０でサポートされるアップリンクピークデータレートをサポートするもう一つの新しいテーブル，を含み， 新しいテーブルは，Ｒｅｌ－１０の特徴，例えばＣＡ／ＵＬ－ＭＩＭＯ，が設定されたときにのみ用いられ， 複数のテーブルが利用できるとき，ＵＥは，現在のバッファ状態に従いテーブルを選択し，また，例えばＭＡＣサブヘッダ中のＲビットを経由して，ｅＮＢに，どれが用いられたかを示すことができ， ＵＥは，ｅＮＢに最も正確な情報を提供することができるように，テーブルを選ぶ ＵＥ。」 イ　周知技術 （ア）周知例１ 原査定の理由に引用された特開２０１０－１１４６８１号公報（平成２２年５月２０日出願公開。以下，「周知例１」という。）には，図面とともに次の事項が記載されている（なお，下線は当審にて付したものである。）。 ａ　「【０００７】 図２４に示すように、例えば、端末には、固定的な所定周期で上り制御チャネル用無線リソースが割り当てられる。ＣＱＩ送信用の無線リソースは、周期毎に割り当てられる。ＣＱＩと異なる制御情報として、ＲＧＢＳ(Radio bearer Group Buffer Status： 送信バッファ滞留量)やＵＰＨ（User equipment Power Headroom）のようなパラメータもＣＱＩと同じ送信周期で送信される。これに対し、ＳＲに関しては、ＣＱＩの送信周期よりも長い送信周期が固定的に規定され、ＳＲは本来ＣＱＩが格納されるべき領域を消費して送信される。」 ｂ　「【００３３】 また、PUCCH1にて端末から基地局へ送信される制御情報には、以下のものがある。 （１）CQI情報 ：ダウンリンク（ DL）の無線品質情報 = DL無線区間における信号対雑音比(SIR) （２）RGBS値：端末が保持する、基地局へ送信するデータの送信バッファに滞留したデータ量のインデックス（index）値。端末と基地局との間には、複数の優先クラス（Priority Class）に対応する複数の論理チャネルが設定される。送信バッファは優先クラス(論理チャネル)毎に用意される。このため、各論理チャネル用の送信バッファの滞留量が個別に報告される。 （３）SR(Scheduling Request)：端末から基地局に対して送信する、PUSCH（データ通信用物理チャネル）の割り当て要求メッセージである。 （４）UPH (UE Power Headroom) ：端末の最大送信電力に対する、現在の送信電力の比。端末の送信電力制御に用いられる。ＵＰＨは、UEの余剰送信電力を示す。具体的には、 (UEの最大送信電力)/(その時点でのUEの送信パワー) で計算される　index値で、値が大きいほど、そのUEはまだ電力を上げる余地がある　ことを示す。」 （イ）周知例２ Ｅｒｉｃｓｓｏｎ，Ｎｏｋｉａ　Ｃｏｒｐｏｒａｔｉｏｎ，Ｎｏｋｉａ　Ｓｉｅｍｅｎｓ　Ｎｅｔｗｏｒｋｓ，Ｓａｍｓｕｎｇ，Ｂｕｆｆｅｒ　Ｓｉｚｅ　Ｌｅｖｅｌｓ　ｆｏｒ　ＢＳＲ　ｉｎ　Ｅ－ＵＴＲＡ　Ｕｐｌｉｎｋ （当審訳：Ｅ－ＵＴＲＡアップリンクにおけるＢＳＲのためのバッファサイズレベル）［ｏｎｌｉｎｅ］，３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　Ｍｅｅｔｉｎｇ　＃６２ｂｉｓ　Ｒ２－０８３１０１，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｒａｎ／ＷＧ２＿ＲＬ２／ＴＳＧＲ２＿６２ｂｉｓ／Ｄｏｃｓ／Ｒ２－０８３１０１．ｚｉｐ＞（利用可能日：２００８年７月４日。以下，「周知例２」という。）には，次の事項が記載されている。 ａ　「 」（第１ページ第１９行ないし第２５行） （当審訳：「しかしながら，表６．１．２．１－１は，まだ３ＧＰＰ仕様書に追加されていない。この寄書において我々は，バッファ状態報告を計算するときにＵＥにおいて用いられるテーブルを提案する。ＨＳＵＰＡにおけるＴｏｔａｌ　Ｅ－ＤＣＨ　Ｂｕｆｆｅｒ　Ｓｔａｔｕｓ（ＴＥＢＳ）のシグナリングのために用いられたのと同様のアプローチが提案される（すなわち，バッファサイズレベルが指数関数的に分散される。）。 ２　バッファサイズレベル 指数関数的に分散したバッファサイズレベルを計算するために，ＨＳＵＰＡで用いられたのと同様のアプローチが提案される。そのようなことを行うために，以下に示すパラメータを決定する必要がある：最小バッファサイズレベル（Ｂｍｉｎ），最大バッファサイズレベル（Ｂｍａｘ），報告されるバッファサイズレベルの数（Ｎ）。」 （当審注：周知例２に記載された「the maximum buffer size level(Bmin)」は，「the maximum buffer size level(Bmax)」の明らかな誤記と認められるから，上記のように訳した。）） ｂ　「 」（第１ページ第２５行ないし第２ページ第３行） （当審訳： 「報告されるバッファサイズレベルの数　－　バッファサイズフィールドのために６ビットが用いられることの合意に基づき，また，インデックス“００００００”は“空バッファ”を報告するために予約されていると仮定すると，２６－１＝６３個の（指数関数的に分散した）バッファサイズレベルが存在する。 Ｎ＝６３ 上述したパラメータに基づき，表１で報告されるバッファサイズレベルは，以下に示す式を用いて導出される［３］： ここでｐ＝（Ｂｍａｘ／Ｂｍｉｎ）１／（Ｎ－１）－１」） ｃ　表１は，以下のとおりである。 「 」（表１のキャプションの当審訳：「表１：Ｅ－ＵＴＲＡアップリンクにおけるＢＳＲのためのバッファサイズレベル」） （ウ）周知例３ Ａｌｃａｔｅｌ－Ｌｕｃｅｎｔ　Ｓｈａｎｇｈａｉ　Ｂｅｌｌ，Ａｌｃａｔｅｌ－Ｌｕｃｅｎｔ，ＢＳＲ　ｒｅｐｏｒｔｉｎｇ　ｉｎ　Ｃａｒｒｉｅｒ　Ａｇｇｒｅｇａｔｉｏｎ （当審訳：キャリアアグリゲーションにおけるＢＳＲ報告）［ｏｎｌｉｎｅ］，３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２　Ｍｅｅｔｉｎｇ　＃７０　Ｒ２－１０３２７７，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｒａｎ／ＷＧ２＿ＲＬ２／ＴＳＧＲ２＿７０／Ｄｏｃｓ／Ｒ２－１０３２７７．ｚｉｐ＞（利用可能日：２０１０年５月１４日。以下，「周知例３」という。）には，図面とともに次の事項が記載されている（なお，下線は，当審において付したものである。）。 ａ　「 」（第１ページ第７行ないし第１１行） （当審訳：「１．導入 バッファ状態報告は，アップリンクシステムにおいて，ｅＮＢでのスケジューリングをアシストするために必要なＵＥ側の情報を提供するために，重要である。Ｒｅｌ－８／９では，一つのＴＴＩ中に一つのＭＡＣ　ＰＤＵしか存在しないので，バッファ状態報告を行うことは，相対的にシンプルであるが，しかし，Ｒｅｌ－１０では，複数のＣＣの導入により，一つのＴＴＩ中に複数のＭＡＣ　ＰＤＵが存在する。このペーパーは，ＣＡのためにバッファ状態報告を行うことを議論する。」） ｂ　「 」（第３ページ第７行ないし第２３行） （当審訳：「２．４　ＢＳＲテーブル バッファサイズテーブルは，期待されるレスポンスタイムが乗算されたアップリンクピークデータレートに基づいて導出された最大バッファサイズレベルを定義する。しかし，ＣＡとＵＬ　ＭＩＭＯの導入に伴うピークデータレートの増大のため，このバッファテーブルは，正確なバッファステータス情報の報告をサポートできないかもしれない。ＢＳサイズを７ビットに拡張するという，これに対する率直な解決方法は，現在のｓｈｏｒｔ　ＢＳＲ及びｌｏｎｇ　ＢＳＲフォーマットと互換性がない。６ビットのＢＳサイズを変更しないよう維持するために，一つの解決方法は，より低い粒度とともに最大値を拡大するか［３］又は異なるテーブルを導入するか［２］である。 例えば，より低い粒度のテーブルを参照しており，付加的な情報（より正確なＢＳＲ情報）を提供するためにパディングＢＳＲが用いられる。オリジナルのＢＳＲ情報と，強化された情報とを区別するために，ＭＡＣサブヘッダのＲビットが用いられる。例えば，一のＴＴＩ中に，送信されるべき２つのＭＡＣ　ＰＤＵがあり，Ｐｅｒｉｏｄｉｃ／Ｒｅｇｕｌａｒ　ＢＳＲがトリガされ，一つのＭＡＣ　ＰＤＵに送信され，そして，パディングＢＳＲは，もう一つのＭＡＣ　ＰＤＵにサポートされる。ＬＣＧが一つだけあり，かつ実際のバッファの総量が１１１１４８バイトと仮定すると，表６．１．３．１－１［１］によれば，Ｐｅｒｉｏｄｉｃ／Ｒｅｇｕｌａｒ　ＢＳＲの報告インデックスは，６１（１０９４３９＜ＢＳ＜＝１２８１２５）となる。パディングＢＳｒは，インデックス３４（インターバル１５５２＜ＢＳ＜＝１８１２）によって示されるインクリメント情報（１１１１４８－１０９４３９＝１７０９）を知らせるために用いられ得る。 提案５：６ビットを有する，より低い粒度のテーブルを参照してＢＳＲの正確性を強化するために，パディングＢＳＲが用いられ得る。」） （エ）周知例４ ３ＧＰＰ　ＴＳ　３６．３２１　Ｖ８．８．０（２００９－１２），３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ；　Ｔｅｃｈｎｉｃａｌ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｇｒｏｕｐ　Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ；　Ｅｖｏｌｖｅｄ　Ｕｎｉｖｅｒｓａｌ　Ｔｅｒｒｅｓｔｒｉａｌ　Ｒａｄｉｏ　Ａｃｃｅｓｓ（Ｅ－ＵＴＲＡ）　Ｍｅｄｉｕｍ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ（ＭＡＣ）　ｐｒｏｔｏｃｏｌ　ｓｐｅｃｉｆｉｃａｔｉｏｎ　（Ｒｅｌｅａｓｅ　８） （当審訳：３ＧＰＰ　ＴＳ　３６．３２１　Ｖ８．８．０（２００９－１２），第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；進化型汎用地上無線アクセス（Ｅ－ＵＴＲＡ）メディアアクセス制御（ＭＡＣ）プロトコル仕様書（リリース８））［ｏｎｌｉｎｅ］，ｐ．２５－３７，インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／ａｒｃｈｉｖｅ／３６＿ｓｅｒｉｅｓ／３６．３２１／３６３２１－８８０．ｚｉｐ＞（利用可能日：２０１０年１月５日。以下，「周知例４」という。）には，図面とともに次の事項が記載されている。 ａ　「 」（第２５ページの下から１４行目ないし１０行目） （当審訳：「５．４．５　バッファ状態報告 バッファ状態報告プロシージャは，ＵＥのＵＬバッファにおける送信のために利用可能なデータの総量についての情報を，サービングｅＮＢに提供するために用いられる。ＲＲＣは２つのタイマーであるｐｅｒｉｏｄｉｃＢＳＲ－ＴｉｍｅｒとｒｅｔｘＢＳＲ－Ｔｉｍｅｒを構成することによって，また，それぞれのロジカルチャネルで，オプションでロジカルチャネルをＬＣＧに割り当てるｌｏｇｉｃａｌＣｈａｎｎｅｌＧｒｏｕｐををシグナリングすることによって，ＢＳＲレポーティングを制御する［８］。」） ｂ　「 」（第３１ページ第２行ないし第１２行） （当審訳：「６．１．２　ＭＡＣ　ＰＤＵ（透過ＭＡＣ及びランダムアクセス応答を除くＤＬ－ＳＣＨ及びＵＬ－ＳＣＨ） 図６．１．２－３に示されているように，ＭＡＣ　ＰＤＵは，ＭＡＣヘッダと，０かそれより多いＭＡＣサービスデータユニット（ＭＡＣ　ＳＤＵ）と，０かそれより多いＭＡＣ制御要素と，オプションとしてパディングとからなる。 ＭＡＣヘッダとＭＡＣ　ＳＤＵは，いずれも可変サイズである。 ＭＡＣ　ＰＤＵヘッダは，１以上のＭＡＣ　ＰＤＵサブヘッダからなり，それぞれのサブヘッダは，ＭＡＣ　ＳＤＵ，ＭＡＣ制御要素，又はパディングのいずれかと対応する。 ＭＡＣ　ＰＤＵサブヘッダは，ＭＡＣ　ＰＤＵ中の最後のサブヘッダのためのものと，固定サイズのＭＡＣ制御要素のためのものとを除き，６つのヘッダフィールドＲ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／Ｌからなる。ＭＡＣ　ＰＤＵ中の最後のサブヘッダと，固定サイズのＭＡＣ制御要素のためのサブヘッダは，単に，４つのヘッダフィールドＲ／Ｒ／Ｅ／ＬＣＩＤからなる。パディングに対応するＭＡＣ　ＰＤＵサブヘッダは，４つのヘッダフィールドＲ／Ｒ／Ｅ／ＬＣＩＤからなる。」） ｃ　ここで，図６．１．２－１，図６．１．２－２，及び図６．１．２－３は，以下のとおりである。 図６．１．２－１ （図６．１．２－１のキャプションの当審訳：「図６．１．２－１：Ｒ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／Ｌ　ＭＡＣサブヘッダ」） 図６．１．２－２ （図６．１．２－２のキャプションの当審訳：「図６．１．２－２：Ｒ／Ｒ／Ｅ／ＬＣＩＤ　ＭＡＣサブヘッダ」） 図６．１．２－３ （図６．１．２－３のキャプションの当審訳：「図６．１．２－３：ＭＡＣヘッダ，ＭＡＣ制御要素，ＭＡＣ　ＳＤＵ及びパディングからなるＭＡＣ　ＰＤＵの例」） ｄ　「 」（第３２ページ第１行ないし第１６行（図面及びそのキャプションは行数に数えない。）） （当審訳：「６．１．３　ＭＡＣ制御要素 ６．１．３．１　バッファ状態報告ＭＡＣ制御要素 バッファ状態報告（ＢＳＲ）ＭＡＣ制御要素は，以下のいずれかを含む： －　Ｓｈｏｒｔ　ＢＳＲ及びＴｒｕｎｃａｔｅｄ　ＢＳＲフォーマット：１つのＬＣＧ　ＩＤフィールドと，１つの対応するＢｕｆｆｅｒ　Ｓｉｚｅフィールド（図６．１．３．１－１）；又は， －　Ｌｏｎｇ　ＢＳＲフォーマット：ＬＣＧ　ＩＤ　＃０から＃３までに対応する，４つのＢｕｆｆｅｒ　Ｓｉｚｅフィールド（図６．１．３．１－２）。 ＢＳＲフォーマットは表６．２．１－２中に示されているように，ＬＣＩＤを有するＭＡＣ　ＰＤＵサブヘッダによって識別される。 ＬＣＧ　ＩＤとＢｕｆｆｅｒ　Ｓｉｚｅフィールドは，以下のように定義される： －　ＬＣＧ　ＩＤ：バッファ状態が報告されるロジカルチャネルのグループを識別するＬｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　Ｇｒｏｕｐ　ＩＤフィールド。フィールドの長さは２ビット： －　Ｂｕｆｆｅｒ　Ｓｉｚｅ：Ｂｕｆｆｅｒ　Ｓｉｚｅフィールドは，ＭＡＣ　ＰＤＵが構築された後の，１つのロジカルチャネルグループの全てのロジカルチャネルに亘って利用可能なデータの総量を識別する。データの総量はバイト数で示される。ＲＬＣレイヤ及びＰＤＣＰレイヤ中の送信可能な全てのデータを含めなければならない；何のデータが送信可能として考慮されるべきかについての定義は，［３］及び［４］にそれぞれ特定されている。ＲＬＣ及びＭＡＣヘッダのサイズは，バッファサイズの計算において考慮されない。このフィールドの長さは６ビットである。Ｂｕｆｆｅｒ　Ｓｉｚｅフィールドで採用される値は，表６．１．３．１－１において示される。」） ｅ　ここで，図６．１．３．１－１，図６．１．３．１－２，及び，表６．１．３．１－１は，以下のとおりである。 図６．１．３．１－１ （図６．１．３．１－１のキャプションの当審訳：「図６．１．３．１－１：Ｓｈｏｒｔ　ＢＳＲ及びＴｒｕｎｃａｔｅｄ　ＢＳＲ　ＭＡＣ制御要素」） 図６．１．３．１－２ （図６．１．３．１－２のキャプションの当審訳：「図６．１．３．１－２：Ｌｏｎｇ　ＢＳＲ　ＭＡＣ制御要素」） 表６．１．３．１－１ （表６．１．３．１－１のキャプションの当審訳：「表６．１．３．１－１：ＢＳＲのためのバッファサイズレベル」） ｆ　「 」（第３６ページの下から９行目ないし第３７ページの上から１２行目） （当審訳：「６．２　フォーマット及びパラメータ ６．２．１　ＤＬ－ＳＣＨ及びＵＬ－ＳＣＨのためのＭＡＣヘッダ ＭＡＣヘッダは可変サイズであり，以下のフィールドからなる： －　ＬＣＩＤ：　Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　ＩＤフィールドは，表６．２．１－１及び６．２．１－２にＤＬ用及びＵＬ－ＳＣＨ用としてそれぞれ示されているように，対応するＭＡＣ　ＳＤＵのロジカルチャネルインスタンスを，又は，対応するＭＡＣ制御要素若しくはパディングのタイプを，識別する。ＭＡＣ　ＰＤＵに含まれるＭＡＣ　ＳＤＵ，ＭＡＣ制御要素，又はパディングのそれぞれに，一つのＬＣＩＤフィールドが存在する。それに加えて，ＭＡＣ　ＰＤＵには，シングル－バイト又は２－バイトパディングが必要であるがＭＡＣ　ＰＤＵの最後にパディングすることによって達成することができないとき，１つ又は２つの追加のＬＣＩＤフィールドが含まれていてもよい。ＬＣＩＤフィールドサイズは５ビットである； －　Ｌ：　Ｌｅｎｇｔｈフィールドは，対応するＭＡＣ　ＳＤＵの長さをバイトで示す。最後のサブヘッダ，又は，固定サイズのＭＡＣ制御要素に対応するサブヘッダを除けば，ＭＡＣ　ＰＤＵごとに一つのＬフィールドがある。Ｌフィールドのサイズは，Ｆフィールドによって示される。 －　Ｆ：　Ｆｏｒｍａｔフィールドは，表６．２．１－３に示されるＬｅｎｇｔｈフィールドのサイズを示す。最後のサブヘッダ，又は，固定サイズのＭＡＣ制御要素に対応するサブヘッダを除けば，ＭＡＣ　ＰＤＵごとに一つのＦフィールドがある。もし，ＭＡＣ　ＳＤＵのサイズが１２８バイトよりも少なければ，ＵＥは，Ｆフィールドの値を０にセットするべきであり，そうでなければ，ＵＥはそれを１にセットするべきである。 －　Ｅ：　Ｅｘｔｅｎｓｉｏｎフィールドは，ＭＡＣヘッダ内に，より多くのフィールドが存在するか否かを示すフラグである。 少なくともＲ／Ｒ／Ｅ／ＬＣＩＤフィールドの，もう一つのセットを示すためには，Ｅフィールドは“１”にセットされる。ＭＡＣ　ＳＤＵ，ＭＡＣ制御要素，及びパディングのいずれかが，次のバイトからスタートすることを示すためには，Ｅフィールドは“０”にセットされる。 －　Ｒ：　Ｒｅｓｅｒｖｅｄビット，“０”にセットされる。 ＭＡＣヘッダとサブヘッダは，オクテットで整列されている。」） ｇ　ここで，表６．２．１－２は，以下のとおりである。 表６．２．１－２ （表６．２．１－２のキャプションの当審訳：「表６．２．１－２　ＵＬ－ＳＣＨのためのＬＣＩＤの値」） ｈ　上記ｄにおける記載，並びに，上記ｅの図６．１．３．１－１，図６．１．３．１－２及び表６．１．３．１－１における記載によれば，バッファ状態報告（ＢＳＲ）ＭＡＣ制御要素に含まれる６ビットのＢｕｆｆｅｒ　Ｓｉｚｅフィールドには，表６．１．３．１－１に示されている，データの総量に対応した０ないし６３の値を取り得るインデックス（Ｉｎｄｅｘ）の値が入ることは自明である。 ｉ　また，上記ｄ及びｆにおける記載，並びに，上記ｇの表６．２．１－２における記載によれば，ＭＡＣ　ＰＤＵサブヘッダに含まれるＬＣＩＤフィールド，すなわち，Ｌｏｇｉｃａｌ　Ｃｈａｎｎｅｌ　ＩＤフィールドは，Ｔｒｕｎｃａｔｅｄ　ＢＳＲ，Ｓｈｏｒｔ　ＢＳＲ，Ｌｏｎｇ　ＢＳＲといった，ＢＳＲのフォーマットを識別するものといえる。 （オ）周知技術１ 上記（ア）ないし（ウ）で示した周知例１ないし３の記載，並びに，上記（エ）で示した周知例４の上記（エ）のａ，ｄ及びｅにおける記載ないしｈにおける検討は，以下に示す技術（以下，「周知技術１」という。）が周知であることを裏付けるものである。 「バッファ状態報告において，端末のバッファにおけるデータ量に対応するインデックスを，端末から基地局に送信する技術」 （カ）周知技術２ また，上記（エ）で示した周知例４は，移動体通信の分野で広く知られたＬＴＥの規格の仕様書であることも考慮すれば，周知例４の上記（エ）のａ，ｂ，ｃ，ｄ，ｆ及びｇにおける記載ないしｉにおける検討は，以下に示す技術（以下，「周知技術２」という。）が周知であることも裏付けるものである。 「ＢＳＲのフォーマットを識別するロジカルチャネル識別子をＭＡＣシグナリングに含める技術」 （２）対比 本願補正発明と引用発明とを対比する。 ア　引用発明の「ＵＥ」，「ｅＮＢ」及び「ＭＡＣ」は，それぞれ，本願補正発明の「端末」，「基地局」及び「メディアアクセス制御」に相当する。 イ　引用文献には，「ＬＴＥ　Ｒｅｌ－８のＢＳＲテーブルについては，指数関数的に分散した粒度と，期待されるレスポンスタイムによって乗算されたアップリンクピークデータレートに基づいて導かれる最大バッファサイズレベルとが，定められた」と記載されている（上記（１）ア（ア）を参照。）ところ，従来のＬＴＥのＢＳＲテーブルについては，本願の明細書の段落【０００９】にも「このようにして、従来のLTE技術中のBSRインデックステーブルは、端末が報告し得る最大バッファデータ量をサポートすることはもうできい。よって、新しい最大バッファデータ量に適応するために、BSRインデックステーブルに対して改良を行う必要がある。」という記載があるように，引用文献に記載された上記「期待されるレスポンスタイムによって乗算されたアップリンクピークデータレートに基づいて導かれる最大バッファサイズレベル」が，「テーブルの最大データ量」を意味することは明らかである。 そうすると，引用発明において，「Ｒｅｌ－８／９と同じテーブル」と，「Ｒｅｌ－１０でサポートされるアップリンクピークデータレートをサポートする別の新しいテーブル」とは，異なる「最大値」及び粒度を有するものであり，これらのテーブルは，いずれも「テーブルの最大データ量」を有するといえる。 ところで，一般に，「最大値」とは，「区間」の上限を示す値である。 また，上記「最大値」が「区間」の上限を示す値であるかどうかは別にしても，引用発明における上述した２種類のテーブルは，異なる「粒度」を有するものでもあるところ，この「粒度」とは，バッファサイズについて，あるかたまり（粒）の大きさの度合いを指しているといえるから，そのような「粒度」を有するテーブルは，バッファサイズのデータ量の情報が，ある大きさを持つかたまりにしたがって区切られている，すなわち，「区間」を有するテーブルであるといえる。 してみれば，引用発明の「Ｒｅｌ－８／９と同じテーブル」及び「Ｒｅｌ－１０でサポートされるアップリンクピークデータレートをサポートする別の新しいテーブル」は，いずれも，端末のバッファにおけるデータ量区間を示すテーブルといえる。 また，データレートが大きいほど，より大きいサイズのバッファが必要であることは当然であるから，引用発明における「Ｒｅｌ－１０でサポートされるアップリンクピークデータレートをサポートする別の新しいテーブル」の最大データ量（最大値）が，「Ｒｅｌ－８／９と同じテーブル」のそれ（最大データ量（最大値））よりも大きいことも当然のことである。 また，引用発明は「異なる最大値及び粒度を有する複数のテーブル，例えば，少なくとも一つのＲｅｌ－８／９と同じテーブル及びＲｅｌ－１０でサポートされるアップリンクピークデータレートをサポートするもう一つの新しいテーブル」を含むから，引用発明は，一つのＲｅｌ－８／９と同じテーブルと，少なくとも一以上の新しいテーブルと，を含むといえる。 そして，引用発明における前記「一つのＲｅｌ－８／９と同じテーブル」及び前記「少なくとも一以上の新しいテーブル」を，それぞれ，旧来の（Ｒｅｌ－８／９と同じ）テーブルか，それとも新しいテーブルか，という観点から分類可能な２種類のテーブルという意味で，「第一」テーブル及び「第二」テーブルとすれば，引用発明は，「前記端末のバッファにおけるデータ量区間を示す第一テーブル」と，「前記端末の前記バッファにおけるデータ量区間を示し、前記第一テーブルの最大データ量よりも大きい最大データ量を有する少なくとも一つの第二テーブル」と，を含むといえる。 ウ　引用発明において，「新しいテーブルは，Ｒｅｌ－１０の特徴，例えばＣＡ／ＵＬ－ＭＩＭＯ，が設定されたときにのみ用いられ」，また，「複数のテーブルが利用できるとき，ＵＥは，現在のバッファ状態に従いテーブルを選択」するものである。 そのため，引用発明は，Ｒｅｌ－１０の特徴が設定されたときにのみ，Ｒｅｌ－８のテーブルに加えて新しいテーブルも用いることができるものであって，それらの複数の利用可能なテーブルの中から適切なテーブルを選択するものであり，またＲｅｌ－１０の特徴が設定されたときでなければ，Ｒｅｌ－８／９と同じテーブルを選択するものと解される。 そして，引用発明の端末（ＵＥ）は，Ｒｅｌ－１０の特徴が設定されたものであるか，そうでないものか，という観点からみて，２つの「類型」に区分することができるから，引用発明は，そのような類型に基づいて，Ｒｅｌ－８／９と同じテーブル及び新しいテーブルのうちから一つのテーブルを選択しているといえる。 ところで，引用発明には，テーブルを選択する処理，及び，選択したテーブルを基地局に通知する処理を実現するための具体的構成として，「テーブル選択ユニット」を含むことは特定されていない。しかし，引用発明においても，テーブルを選択し，その選択したテーブルを基地局に通知することを実現するための何らかの機能ブロック，すなわちユニット，を有することは，特定がなくても当然のことである。 これらのことから，引用発明は，「前記端末の類型に基づいて、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから一つのテーブルを選択するテーブル選択ユニット」を含むといえる。 エ　引用発明は，複数のテーブルが利用できるとき，現在のバッファ状態に従いテーブルを選択し，例えばＭＡＣサブヘッダ中のＲビットを経由して，基地局（ｅＮＢ）に，どれが用いられたかを示すことができるものであるところ，これは，選択したテーブルについての情報をＭＡＣサブヘッダに載せて，信号という形式で，当該情報を基地局に通知するものと解される。 とすれば，上記ウでしたテーブルの選択についての検討も考慮すると，引用発明が「ロジカルチャネル識別子」について特定があるかどうかについてはともかく，本願補正発明と，引用発明は，前記テーブル選択ユニットが，前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから選択した前記一つのテーブルを，前記メディアアクセス制御シグナリングにより前記基地局へ通知するという点で，共通している。 オ　引用発明は，「ｅＮＢは，ＢＳ＞１５０キロバイトに達したとき，設定される／割り当てられる必要がある追加のリソースがどのくらいなのかについての更なる情報を得る方法がない」という課題を解決するためのものであるから，端末のバッファにおけるデータ量に基づく情報が，基地局（ｅＮＢ）に送られることを前提とする発明である。 また，引用発明において「ＵＥは，ｅＮＢに最も正確な情報を提供することができるように，テーブルを選ぶ」ものであるところ，引用文献のタイトルにも「キャリアアグリゲーションのためのＢＳＲ」とあるように，引用発明は，ＢＳＲ，すなわちバッファ状態報告，についての発明であるから，ｅＮＢに提供することができるようにするとされている前記「情報」は，バッファの状態に関する情報であることは明らかである。 そうすると，引用発明は，端末のバッファにおけるデータ量に基づいて，バッファの状態に関する情報を基地局に送信するものといえる。 ところで，引用発明は，端末の類型に基づいて，用いられるテーブルを選択するものであるが，そのテーブルを用いた具体的な処理の内容までは，特定されていない。 しかし，当業者にとって，引用発明における「テーブル」が，「ＢＳＲテーブル」を意味するものであることは引用文献全体の記載から明らかであるから，上記イないしエで検討したような，端末の類型に基づいて選択され，また基地局に通知された「テーブル」は，少なくとも，バッファの状態に関する情報を作成する際に用いられるテーブルであることは，当業者にとって明らかである。 してみれば，引用発明は，端末のバッファにおけるデータ量に基づいて，前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルを用いて，バッファの状態に関する情報を作成し，作成された前記バッファの状態に関する情報を基地局に送信するものといえる。 他方で，本願補正発明は，端末のバッファにおけるデータ量に基づいて，テーブルからインデックスを確定し，前記インデックスを基地局に送信するものであるから，テーブルを用いて確定され，また基地局に送信される「インデックス」は，端末において作成された，バッファの状態に関する情報と解される。 これらのことから，引用発明において，「インデックス」を用いているか否かや，「テーブル」はどのように用いられているのか，といった点はさておき，本願補正発明と，引用発明とは，端末のバッファにおけるデータ量に基づいて，前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルを用いて，バッファの状態に関する情報を作成し，作成された前記バッファの状態に関する情報を基地局に送信する，という点で共通する。 カ　上記アないしオから、本願補正発明と引用発明との一致点及び相違点は，以下のとおりである。 ［一致点］ 「　端末であって、 前記端末のバッファにおけるデータ量区間を示す第一テーブルと、 前記端末の前記バッファにおけるデータ量区間を示し、前記第一テーブルの最大データ量よりも大きい最大データ量を有する少なくとも一つの第二テーブルと、 前記端末の類型に基づいて、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから一つのテーブルを選択するテーブル選択ユニットと、 を含み、 前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルを用いてバッファの状態に関する情報を作成し、作成された前記バッファの状態に関する情報を基地局に送信し、 前記テーブル選択ユニットは、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから選択した前記一つのテーブルを、メディアアクセス制御シグナリングにより前記基地局へ通知する、端末。」 ［相違点］ （相違点１） 上記で一致点とした「前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルを用いてバッファの状態に関する情報を作成し、作成された前記バッファの状態に関する情報を基地局に送信」する点に関し， 本願補正発明は，「前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルからインデックスを確定するインデックス確定ユニット」と，「前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニット」とを含み，また，「前記インデックスは、前記端末の前記バッファにおけるデータ量を示すバッファサイズであって、前記第一テーブル及び前記少なくとも一つの第二テーブルから選択された前記一つのテーブルにおけるバッファサイズを示す」のに対し， 引用発明は，「バッファの状態に関する情報」が「インデックス」であるかについて特定が無く，このため，「前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルからインデックスを確定するインデックス確定ユニット」を含むこと，及び，「前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニット」を含むこと，並びに，「前記インデックスは、前記端末の前記バッファにおけるデータ量を示すバッファサイズであって、前記第一テーブル及び前記少なくとも一つの第二テーブルから選択された前記一つのテーブルにおけるバッファサイズを示す」ことについて，いずれも特定が無い点。 （相違点２） 基地局へ通知する「メディアアクセス制御シグナリング」に関し， 本願補正発明では，「ロジカルチャネル識別子を含むメディアアクセス制御シグナリング」であるのに対し， 引用発明では，メディアアクセス制御シグナリングが「ロジカルチャネル識別子を含む」との特定が無い点。 （３）相違点に対する判断 ア　相違点１について 移動体通信の分野において，情報を相手に伝える際に，できるだけ使用するリソースを少なくなるようにすることは，当業者にとって，常に考慮しなければならない課題である。 他方で，上記（１）イ（オ）で示した周知技術１は，引用発明と同様に，バッファの状態を報告するための技術であり，また，バッファに蓄積されているデータのバイト数をそのまま基地局に送る場合と比べて，使用するビット数を少なくすることができる技術である。 してみれば，引用発明において，テーブルを用いてバッファ状態報告を作成するにあたって，できるだけ少ないリソースで相手に伝えるようにするべく，周知技術１を採用することで，端末のバッファにおけるデータ量に基づいて，選択及び通知された一つのテーブルからインデックスを確定するインデックス確定ユニットと，前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニットと，を備えるよう構成することは，当業者にとって格別のことではない。 そしてそのように構成すれば，当然，「前記インデックスは，前記端末の前記バッファにおけるデータ量を示すバッファサイズであって，前記第一テーブル及び前記少なくとも一つの第二テーブルから選択された前記一つのテーブルにおけるバッファサイズを示す」こととなる。 イ　相違点２について 引用文献は，ＬＣＧごとのＳｈｏｒｔ／Ｌｏｎｇ　ＢＳＲフォーマットを再利用するものであるところ，上記（１）イ（カ）で周知技術２として示したとおり，ＢＳＲのフォーマットを識別するロジカルチャネル識別子をＭＡＣシグナリングに含める技術は周知である。 してみれば，引用発明において，バッファ状態報告のフォーマットがＳｈｏｒｔ　ＢＳＲであるのか，それともＬｏｎｇ　ＢＳＲであるのかを示すために，周知技術２に基づいて，メディアアクセス制御シグナリングに，フォーマットを識別するロジカルチャネル識別子を含ませるよう構成することは，当業者であれば適宜なし得る。 ウ　本願補正発明の作用，効果について また，上記ア及びイで検討した相違点１及び相違点２を総合的に勘案しても，本願補正発明の奏する作用，効果は，引用発明及び周知技術の奏する作用，効果から予測される範囲内のものに過ぎず，格別顕著なものということはできない。 （４）独立特許要件についてのまとめ したがって，本願補正発明は，当業者が引用文献に記載された発明並びに周知技術１及び周知技術２に基づいて容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。 ３　補正の却下の決定についてのまとめ 上記のとおりであるから，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するものであり，同法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 第３　本願発明について １　本願発明 平成２８年６月１４日付けの手続補正は上記のとおり却下されたので，本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２７年１０月３０日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである（上記第２の［理由］１（本件補正の概要）における記載事項を再掲。）。 「【請求項１】 端末であって、 前記端末のバッファにおけるデータ量区間を示す第一テーブルと、 前記端末の前記バッファにおけるデータ量区間を示し、前記第一テーブルの最大データ量よりも大きい最大データ量を有する少なくとも一つの第二テーブルと、 前記端末の類型に基づいて、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから一つのテーブルを選択するテーブル選択ユニットと、 前記端末の前記バッファにおけるデータ量に基づいて、前記テーブル選択ユニットにより選択及び通知された前記一つのテーブルからインデックスを確定するインデックス確定ユニットと、 前記インデックス確定ユニットにより通知された前記インデックスを基地局に送信するインデックス送信ユニットと、 を含み、 前記テーブル選択ユニットは、前記第一テーブル及び前記少なくとも一つの第二テーブルのうちから選択した前記一つのテーブルを、ロジカルチャネル識別子を含むメディアアクセス制御シグナリングにより前記基地局へ通知し、前記インデックスは、前記端末の前記バッファにおけるデータ量を示すバッファサイズであって、前記第一テーブル及び前記少なくとも一つの第二テーブルから選択されたバッファサイズを示す、端末。」 ２　引用発明等 引用発明，並びに，周知技術１及び周知技術２は，上記第２の［理由］２（１）（引用発明及び周知技術）のア，並びに，イ（オ）及び（カ）でそれぞれ示したとおりである。 ３　対比・判断 本願発明は，本願補正発明から，本件補正による限定を省いたものである（上記第２の［理由］１を参照）。 そうすると，本願発明を特定する事項を限定した本願補正発明は，上記第２の［理由］２（２）及び（３）で示したとおり，当業者が引用発明並びに周知技術１及び周知技術２に基づいて容易に発明をすることができたものであるから，本願発明も，同様の理由により，当業者が引用発明並びに周知技術１及び周知技術２に基づいて容易に発明をすることができたものである。 ４　まとめ 以上のとおり，本願の請求項１に係る発明は，当業者が引用文献に記載された発明並びに周知技術１及び周知技術２に基づいて容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 したがって，本願の他の請求項について検討するまでもなく，本願は拒絶されるべきものである。 よって，結論のとおり審決する。