【事件の表示】
　特願２０１１−１１７０２１「無線通信システムにおいてバッファ状態報告を処理する方法および装置」拒絶査定不服審判事件〔平成２３年１２月　８日出願公開、特開２０１１−２５０４０８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成２３年５月２５日（パリ条約に基づく優先権主張　２０１０年５月２６日　米国）の出願であって、平成２５年１月２９日付けで拒絶理由が通知され、これに対して平成２５年５月１０日に手続補正がなされ、平成２５年１０月３０日付けで拒絶査定がなされ、これに対して平成２６年３月５日に拒絶査定不服審判が請求され、同時に手続補正がなされたものである。
　　
　　
第２．平成２６年３月５日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成２６年３月５日付けの手続補正（以下、「本件補正」という。）を却下する。
　　
［理由］
１．補正内容
　本件補正は、補正前の特許請求の範囲（平成２５年５月１０日付けで補正）の請求項１：
「【請求項１】
　無線通信システムにおいてバッファ状態報告を処理する方法であり、
　第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するために、無線リソース制御（RRC）メッセージの指示を使用するステップ；を備え、
　前記第１のバッファサイズのレベル表は、第１のバッファサイズの最大値を有し、前記第２のバッファサイズのレベル表は、前記第１のバッファサイズの最大値より大きい第２のバッファサイズの最大値を有することを特徴とする、方法。」を、
　　　　　　　　
「【請求項１】
　無線通信システムにおいてバッファ状態報告を処理する方法であり、
　第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するために、
eNBから受信したRRC Connection Reconfigurationメッセージ中の指示内容
　前記第１のバッファサイズのレベル表は、第１のバッファサイズの最大値を有し、前記第２のバッファサイズのレベル表は、前記第１のバッファサイズの最大値より大きい第２のバッファサイズの最大値を有
し、前記第２のバッファサイズのレベル表が使用される際には、前記第１のバッファサイズのレベル表は使用されない
　　　
と補正することを含むものである。ただし、下線は当審が付加した。
　　　　　　
　すなわち、本件補正は、請求項１において、
  　　　
ａ．「無線リソース制御（RRC）メッセージの指示」を「
eNBから受信したRRC Connection Reconfigurationメッセージ中の指示内容
　　　　
ｂ．「
前記第２のバッファサイズのレベル表が使用される際には、前記第１のバッファサイズのレベル表は使用されない
　　　　
ことを含むものである。　　　
　　　　　　　
２．補正の目的　　　　
　上記補正事項ａ．は、「無線リソース制御（RRC）メッセージ」を「
RRC Connection Reconfigurationメッセージ
eNBから受信した
　　　　
　補正前の請求項１の最初のステップに「第１のバッファサイズのレベル表を使用する
代わりに
　　　　　　
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法１７条の２第６項において準用する同法１２６条第７項の規定に適合するか）について以下に検討する。
　　　
　　　
３．引用発明
　原査定の拒絶の理由に引用された、後記する「他の出願」の優先権主張の日（２００９年６月１９日）が、本願の優先権主張の日（２０１０年５月２６日）前である他の出願であって、その出願後に国際公開された先願１（特願２０１２−５１２１９２号（特表２０１２−５２８４９５号公報））の国際出願日における国際出願（PCT/CN2010/073573）の明細書（以下、「先願明細書」という。）には、以下の事項が記載されている。ただし、先願１の国際出願が中国語で出願されていることから、以下の事項の記載は、先願１に対応する公表特許公報の記載を用いる。
　　　　　
（ａ）段落番号【0005】
「各ＵＥに合理的に無線リソースを割当てることを保証するために、ＬＴＥシステムは、ＵＥに、自身のバッファ内に記憶されたデータ量の状態を報告することを要求し、当該報告は、バッファ状態報告（Ｂｕｆｆｅｒ　Ｓｔａｔｕｓ　Ｒｅｐｏｒｔ：ＢＳＲと略称する）の形式で、ｅＮＢへ報告される。」
　　　　
（ｂ）段落番号【0026】
「本発明が解決しようとする課題は、キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、端末はコンポーネントキャリアが割り当てられた無線リソースにおいてどのようにバッファ状態報告を報告するかの問題を解決することによって、バッファ状態報告の送信正確率を保証し、アップリンク無線リソースを節約するように、前記バッファ状態報告を報告する方法、端末及びネットワークシステムが提供される。」
　　　　　　　
（ｃ）段落番号【0065】
「実施形態１
　１つのＬＣＧのバッファステータス情報を含むＢＳＲデータユニットの構成方法の特徴は、下記のようなものである。ＬＣＧの番号情報を含み、この情報の長さはｌｏｇ２Ｎビットであり、ＮはＬＣＧの総数である。当該ＢＳＲは前記番号に対応するＬＣＧのバッファ送信待ちデータ量のレベル情報をさらに含む。各ＬＣＧのバッファ送信待ちデータ量のレベル情報の長さは、どのようにＬＣＧのバッファ送信待ちデータ量の範囲を分類するかによって決まる。現在のＬＴＥ　Ｒｅｌｅａｓｅ８スタンダードにおいて、バッファ送信待ちデータ量範囲は６４レベルに分けられ（すなわち、データ量レベル情報の長さは６ビットである）、正確に表示可能な実際のバッファデータ量の最大量は１５００００バイトである。本発明において、サポートしようとする正確な実際のバッファデータ量の最大量がＬＴＥ　Ｒｅｌｅａｓｅ８スタンダードの１０倍、すなわち、１５０００００バイト（背景技術に記載されたＬＴＥ−Ａｄｖａｎｃｅｄシステムに関する説明を参照）とすると、データ量レベル情報の長さは少なくとも６ビット以上である。７ビットを採用する実施形態は、図６に示すように、ＬＣＧ　ＢＳがＬＣＧ番号に対応するＬＣＧのバッファ送信待ちデータ量レベルを表し、８ビットを採用する実施形態は、図７に示すようなものであり、９ビットを採用する実施形態は、図８に示すようなものである。さらに多くのビットを採用する実施形態は、上記した実施形態の方法を参照できるため、ここで、重複して例を挙げない。」
　　　　
（ｄ）段落番号【0105】−【0106】
「【0105】
　上記した３つの例における
ＬＣＧバッファ送信待ちデータ量レベル情報の長さ
当該レベル情報の長さの設定方法は、
ｅＮＢに設定され、かつ、放送チャネルまたは専用に設定されるＲＲＣメッセージを介してＵＥに通知する方法であってもよい
【0106】
　例えば、ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚ未満であると、ＵＥに選択されたＢＳＲデータユニットのＬＣＧバッファ送信待ちデータ量レベル情報の長さは６ビットである。ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚから４０ＭＨｚまでの間であると、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは７ビットである。ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が６０ＭＨｚから８０ＭＨｚまでの間であると、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは８ビットである。」
　　　　　
　したがって、先願明細書には次の発明（以下、「引用発明」という。）が記載されていると認められる。
　　　
「キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、バッファ状態報告の送信正確率を保証し、アップリンク無線リソースを節約するように、バッファ状態報告を報告する方法であって、
　現在のＬＴＥ　Ｒｅｌｅａｓｅ８スタンダードにおいて、バッファ送信待ちデータ量範囲は６４レベルに分けられ（すなわち、データ量レベル情報の長さは６ビットである）、正確に表示可能な実際のバッファデータ量の最大量は１５００００バイトであり、正確な実際のバッファデータ量の最大量がＬＴＥ　Ｒｅｌｅａｓｅ８スタンダードの１０倍、すなわち、１５０００００バイトとすると、データ量レベル情報の長さは少なくとも６ビット以上であり、この「６ビット以上」の具体例は７ビットであり、
　ＬＣＧバッファ送信待ちデータ量レベル情報の長さは、ｅＮＢに設定され、かつ、放送チャネルまたは専用に設定されるＲＲＣメッセージを介してＵＥに通知し、
　ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚ未満であると、ＵＥに選択されたＢＳＲデータユニットのＬＣＧバッファ送信待ちデータ量レベル情報の長さは６ビットであり、ｅＮＢによってＵＥに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が２０ＭＨｚから４０ＭＨｚまでの間であると、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは７ビットである、
　バッファ状態報告を報告する方法。」
　
　　
４．本願補正発明と引用発明の一致点・相違点
　引用発明は、キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、バッファ状態報告を報告する方法であるから、本願補正発明と引用発明とは、「無線通信システムにおいてバッファ状態報告を処理する方法」である点で一致している。　　　
　　　　　　　　　　　　　　　　
　引用発明においては、バッファ送信待ちデータ量範囲が６４レベルに分けられているように、バッファ送信待ちデータ量範囲を複数のレベルに分けた「バッファサイズのレベル表」を備えていることが明らかである。
　引用発明の「実際のバッファデータ量の最大量」が、本願補正発明の「バッファサイズの最大値」に相当する。
　　　　　　　　　　　　　　　　
　引用発明において、バッファ送信待ちデータ量範囲が６４レベルに分けられたバッファサイズのレベル表については、データ量レベル情報の長さが６ビットであり、正確に表示可能な実際のバッファデータ量の最大量は１５００００バイトである。また、引用発明において、データ量レベル情報の長さが７ビットであるバッファサイズのレベル表については、正確な実際のバッファデータ量の最大量が１５０００００バイトである。したがって、引用発明では、データ量レベル情報の長さが７ビットであるバッファサイズのレベル表のバッファサイズの最大値が、データ量レベル情報の長さが６ビットであるバッファサイズのレベル表のバッファサイズの最大値よりも大きい。
　よって、引用発明における、データ量レベル情報の長さが６ビットであるバッファサイズのレベル表が、本願補正発明の「第１のバッファサイズの最大値を有」する「第１のバッファサイズのレベル表」に相当し、引用発明における、データ量レベル情報の長さが７ビットであるバッファサイズのレベル表が、本願補正発明の「第１のバッファサイズの最大値より大きい第２のバッファサイズの最大値を有」する「第２のバッファサイズのレベル表」に相当する。
　　　　　　　　　　　　　　　　　　　
　引用発明では、ＬＣＧバッファ送信待ちデータ量レベル情報の長さは、ｅＮＢに設定され、かつ、放送チャネルまたは専用に設定されるＲＲＣメッセージを介してＵＥに通知している。したがって、引用発明では、ｅＮＢが、ＬＣＧバッファ送信待ちデータ量レベル情報の長さを、ＲＲＣメッセージを介してＵＥに通知している。
　このｅＮＢがＲＲＣメッセージを介してＵＥに通知するＬＣＧバッファ送信待ちデータ量レベル情報の長さは、実際のバッファデータ量の最大量が１５００００バイトのバッファサイズのレベル表を使うか、それとも実際のバッファデータ量の最大量が１５０００００バイトのバッファサイズのレベル表を使うかを表す情報であるから、本願補正発明の「第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するため」の情報に相当する。
　したがって、本願補正発明と引用発明とは、「第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したRRC メッセージ中の指示内容を使用するステップ；を備え」る点で一致している。
　　　　　　　　　　　　　　　　　　
　また、引用発明において、ｅＮＢがＲＲＣメッセージを介してＵＥに通知するＬＣＧバッファ送信待ちデータ量レベル情報の長さが７ビットである時に、データ量レベル情報の長さが６ビットであるバッファサイズのレベル表を使用しないことは明らかである。したがって、本願補正発明と引用発明とは、「前記第２のバッファサイズのレベル表が使用される際には、前記第１のバッファサイズのレベル表は使用されない」点で一致している。
　　　　　　
　したがって、本願補正発明と引用発明の一致点・相違点は、次のとおりである。
　　　
［一致点］
「無線通信システムにおいてバッファ状態報告を処理する方法であり、
　第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したRRC メッセージ中の指示内容を使用するステップ；を備え、
　前記第１のバッファサイズのレベル表は、第１のバッファサイズの最大値を有し、前記第２のバッファサイズのレベル表は、前記第１のバッファサイズの最大値より大きい第２のバッファサイズの最大値を有し、前記第２のバッファサイズのレベル表が使用される際には、前記第１のバッファサイズのレベル表は使用されないことを特徴とする、方法。」である点。
　　　　　　　
［相違点］
　第１のバッファサイズのレベル表を使用する代わりに、第２のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したメッセージが、本願補正発明では、RRC Connection Reconfigurationメッセージであるのに対して、引用発明では、RRC メッセージである点。
　　　　　　　　　　　　　　　　　　　　　
５．相違点についての検討
　国際公開第２００９／０９９３７１号（２００９年８月１３日公開）（特表２０１１−５１１５５２号公報）の従来技術を説明している図１に開示されているように、新しい構成を使用する際に、ｅＮＢがＵＥにＲＲＣ接続再構成メッセージを送信することは、周知である。したがって、引用発明のｅＮＢがＵＥにＬＣＧバッファ送信待ちデータ量レベル情報の長さを通知するＲＲＣメッセージを、ＲＲＣ接続再構成メッセージとすることは、具体化手段における微差に過ぎない。　　
　したがって、本願補正発明は、引用発明と実質同一である。
　　　　　　　　　　　　
　よって、本願補正発明は、先願明細書に記載された発明と同一であり、しかも、本願補正発明の発明者が上記先願明細書に記載された発明の発明者と同一であるとも、また、本願の出願時に、その出願人が上記他の出願の出願人と同一であるとも認められないので、本願補正発明は、特許法２９条の２第１項の規定により特許を受けることができない。
　　　　　
　　　　　
６．むすび
　以上のとおり、本件補正は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　　　
　　　
第３．本願発明について
　平成２６年３月５日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２５年５月１０日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定されるものである。
　　　
１．先願及び引用発明　　　
　原査定の拒絶の理由に引用された先願１、及び引用発明は、前記「第２．３．」に記載したとおりである。　
　　　　　　
２．対比・判断
　本願発明は、前記「第２．」で検討した本願補正発明から補正事項ａ．〜ｂの構成を省いたものである。
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「第２．５．」に記載したとおり、先願明細書に記載された発明と同一であるから、本願発明も同様の理由により、先願明細書に記載された発明と同一である。また、本願発明の発明者が上記先願明細書に記載された発明の発明者と同一であるとも、また、本願の出願時に、その出願人が上記他の出願の出願人と同一であるとも認められないので、本願発明は、特許法２９条の２第１項の規定により特許を受けることができない。
　　　
３．むすび
　以上のとおり、本願の請求項１に係る発明は、特許法２９条の２第１項の規定により特許を受けることができない。
　したがって、本願のその余の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。