ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 5項独立特許用件 特許、登録しない。 H04W 審判 査定不服 特29条の2 特許、登録しない。 H04W |
---|---|
管理番号 | 1303729 |
審判番号 | 不服2014-4378 |
総通号数 | 189 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2015-09-25 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2014-03-05 |
確定日 | 2015-07-29 |
事件の表示 | 特願2011-117021「無線通信システムにおいてバッファ状態報告を処理する方法および装置」拒絶査定不服審判事件〔平成23年12月 8日出願公開、特開2011-250408〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1.手続の経緯 本願は、平成23年5月25日(パリ条約に基づく優先権主張 2010年5月26日 米国)の出願であって、平成25年1月29日付けで拒絶理由が通知され、これに対して平成25年5月10日に手続補正がなされ、平成25年10月30日付けで拒絶査定がなされ、これに対して平成26年3月5日に拒絶査定不服審判が請求され、同時に手続補正がなされたものである。 第2.平成26年3月5日付けの手続補正についての補正却下の決定 [補正却下の決定の結論] 平成26年3月5日付けの手続補正(以下、「本件補正」という。)を却下する。 [理由] 1.補正内容 本件補正は、補正前の特許請求の範囲(平成25年5月10日付けで補正)の請求項1: 「【請求項1】 無線通信システムにおいてバッファ状態報告を処理する方法であり、 第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するために、無線リソース制御(RRC)メッセージの指示を使用するステップ;を備え、 前記第1のバッファサイズのレベル表は、第1のバッファサイズの最大値を有し、前記第2のバッファサイズのレベル表は、前記第1のバッファサイズの最大値より大きい第2のバッファサイズの最大値を有することを特徴とする、方法。」を、 「【請求項1】 無線通信システムにおいてバッファ状態報告を処理する方法であり、 第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したRRC Connection Reconfigurationメッセージ中の指示内容を使用するステップ;を備え、 前記第1のバッファサイズのレベル表は、第1のバッファサイズの最大値を有し、前記第2のバッファサイズのレベル表は、前記第1のバッファサイズの最大値より大きい第2のバッファサイズの最大値を有し、前記第2のバッファサイズのレベル表が使用される際には、前記第1のバッファサイズのレベル表は使用されないことを特徴とする、方法。」 と補正することを含むものである。ただし、下線は当審が付加した。 すなわち、本件補正は、請求項1において、 a.「無線リソース制御(RRC)メッセージの指示」を「eNBから受信したRRC Connection Reconfigurationメッセージ中の指示内容」と補正し、 b.「前記第2のバッファサイズのレベル表が使用される際には、前記第1のバッファサイズのレベル表は使用されない」を追加する ことを含むものである。 2.補正の目的 上記補正事項a.は、「無線リソース制御(RRC)メッセージ」を「RRC Connection Reconfigurationメッセージ」と限定し、また「eNBから受信した」を付加することにより限定したものである。 補正前の請求項1の最初のステップに「第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否か」と記載されているから、第2のバッファサイズのレベル表を使用する際には、第1のバッファサイズのレベル表が使用されないことは明らかである。したがって、上記補正事項b.は、補正前の請求項1の最初のステップの記載から自明な事項を記載したものに過ぎない。 そこで、本件補正後の前記請求項1に記載された発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法17条の2第6項において準用する同法126条第7項の規定に適合するか)について以下に検討する。 3.引用発明 原査定の拒絶の理由に引用された、後記する「他の出願」の優先権主張の日(2009年6月19日)が、本願の優先権主張の日(2010年5月26日)前である他の出願であって、その出願後に国際公開された先願1(特願2012-512192号(特表2012-528495号公報))の国際出願日における国際出願(PCT/CN2010/073573)の明細書(以下、「先願明細書」という。)には、以下の事項が記載されている。ただし、先願1の国際出願が中国語で出願されていることから、以下の事項の記載は、先願1に対応する公表特許公報の記載を用いる。 (a)段落番号【0005】 「各UEに合理的に無線リソースを割当てることを保証するために、LTEシステムは、UEに、自身のバッファ内に記憶されたデータ量の状態を報告することを要求し、当該報告は、バッファ状態報告(Buffer Status Report:BSRと略称する)の形式で、eNBへ報告される。」 (b)段落番号【0026】 「本発明が解決しようとする課題は、キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、端末はコンポーネントキャリアが割り当てられた無線リソースにおいてどのようにバッファ状態報告を報告するかの問題を解決することによって、バッファ状態報告の送信正確率を保証し、アップリンク無線リソースを節約するように、前記バッファ状態報告を報告する方法、端末及びネットワークシステムが提供される。」 (c)段落番号【0065】 「実施形態1 1つのLCGのバッファステータス情報を含むBSRデータユニットの構成方法の特徴は、下記のようなものである。LCGの番号情報を含み、この情報の長さはlog2Nビットであり、NはLCGの総数である。当該BSRは前記番号に対応するLCGのバッファ送信待ちデータ量のレベル情報をさらに含む。各LCGのバッファ送信待ちデータ量のレベル情報の長さは、どのようにLCGのバッファ送信待ちデータ量の範囲を分類するかによって決まる。現在のLTE Release8スタンダードにおいて、バッファ送信待ちデータ量範囲は64レベルに分けられ(すなわち、データ量レベル情報の長さは6ビットである)、正確に表示可能な実際のバッファデータ量の最大量は150000バイトである。本発明において、サポートしようとする正確な実際のバッファデータ量の最大量がLTE Release8スタンダードの10倍、すなわち、1500000バイト(背景技術に記載されたLTE-Advancedシステムに関する説明を参照)とすると、データ量レベル情報の長さは少なくとも6ビット以上である。7ビットを採用する実施形態は、図6に示すように、LCG BSがLCG番号に対応するLCGのバッファ送信待ちデータ量レベルを表し、8ビットを採用する実施形態は、図7に示すようなものであり、9ビットを採用する実施形態は、図8に示すようなものである。さらに多くのビットを採用する実施形態は、上記した実施形態の方法を参照できるため、ここで、重複して例を挙げない。」 (d)段落番号【0105】-【0106】 「【0105】 上記した3つの例におけるLCGバッファ送信待ちデータ量レベル情報の長さはいずれも9ビットであり、ほかの長さに設定されてもよい。当該レベル情報の長さの設定方法は、eNBとUE側で固定的に設定される方法であってもよいし、または、eNBに設定され、かつ、放送チャネルまたは専用に設定されるRRCメッセージを介してUEに通知する方法であってもよいし、または、UEによりシステムに設定された当該UEの全てのアップリンクコンポーネントキャリアの総帯域幅に応じて選択され、総帯域幅が大きいほど、より長いバッファ送信待ちデータ量の情報長さを選択する方法であってもよい。 【0106】 例えば、eNBによってUEに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が20MHz未満であると、UEに選択されたBSRデータユニットのLCGバッファ送信待ちデータ量レベル情報の長さは6ビットである。eNBによってUEに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が20MHzから40MHzまでの間であると、LCGバッファ送信待ちデータ量レベル情報の長さは7ビットである。eNBによってUEに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が60MHzから80MHzまでの間であると、LCGバッファ送信待ちデータ量レベル情報の長さは8ビットである。」 したがって、先願明細書には次の発明(以下、「引用発明」という。)が記載されていると認められる。 「キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、バッファ状態報告の送信正確率を保証し、アップリンク無線リソースを節約するように、バッファ状態報告を報告する方法であって、 現在のLTE Release8スタンダードにおいて、バッファ送信待ちデータ量範囲は64レベルに分けられ(すなわち、データ量レベル情報の長さは6ビットである)、正確に表示可能な実際のバッファデータ量の最大量は150000バイトであり、正確な実際のバッファデータ量の最大量がLTE Release8スタンダードの10倍、すなわち、1500000バイトとすると、データ量レベル情報の長さは少なくとも6ビット以上であり、この「6ビット以上」の具体例は7ビットであり、 LCGバッファ送信待ちデータ量レベル情報の長さは、eNBに設定され、かつ、放送チャネルまたは専用に設定されるRRCメッセージを介してUEに通知し、 eNBによってUEに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が20MHz未満であると、UEに選択されたBSRデータユニットのLCGバッファ送信待ちデータ量レベル情報の長さは6ビットであり、eNBによってUEに設定された全てのアップリンクコンポーネントキャリアの総帯域幅が20MHzから40MHzまでの間であると、LCGバッファ送信待ちデータ量レベル情報の長さは7ビットである、 バッファ状態報告を報告する方法。」 4.本願補正発明と引用発明の一致点・相違点 引用発明は、キャリアアグリゲーション技術をサポートする無線ネットワークにおいて、バッファ状態報告を報告する方法であるから、本願補正発明と引用発明とは、「無線通信システムにおいてバッファ状態報告を処理する方法」である点で一致している。 引用発明においては、バッファ送信待ちデータ量範囲が64レベルに分けられているように、バッファ送信待ちデータ量範囲を複数のレベルに分けた「バッファサイズのレベル表」を備えていることが明らかである。 引用発明の「実際のバッファデータ量の最大量」が、本願補正発明の「バッファサイズの最大値」に相当する。 引用発明において、バッファ送信待ちデータ量範囲が64レベルに分けられたバッファサイズのレベル表については、データ量レベル情報の長さが6ビットであり、正確に表示可能な実際のバッファデータ量の最大量は150000バイトである。また、引用発明において、データ量レベル情報の長さが7ビットであるバッファサイズのレベル表については、正確な実際のバッファデータ量の最大量が1500000バイトである。したがって、引用発明では、データ量レベル情報の長さが7ビットであるバッファサイズのレベル表のバッファサイズの最大値が、データ量レベル情報の長さが6ビットであるバッファサイズのレベル表のバッファサイズの最大値よりも大きい。 よって、引用発明における、データ量レベル情報の長さが6ビットであるバッファサイズのレベル表が、本願補正発明の「第1のバッファサイズの最大値を有」する「第1のバッファサイズのレベル表」に相当し、引用発明における、データ量レベル情報の長さが7ビットであるバッファサイズのレベル表が、本願補正発明の「第1のバッファサイズの最大値より大きい第2のバッファサイズの最大値を有」する「第2のバッファサイズのレベル表」に相当する。 引用発明では、LCGバッファ送信待ちデータ量レベル情報の長さは、eNBに設定され、かつ、放送チャネルまたは専用に設定されるRRCメッセージを介してUEに通知している。したがって、引用発明では、eNBが、LCGバッファ送信待ちデータ量レベル情報の長さを、RRCメッセージを介してUEに通知している。 このeNBがRRCメッセージを介してUEに通知するLCGバッファ送信待ちデータ量レベル情報の長さは、実際のバッファデータ量の最大量が150000バイトのバッファサイズのレベル表を使うか、それとも実際のバッファデータ量の最大量が1500000バイトのバッファサイズのレベル表を使うかを表す情報であるから、本願補正発明の「第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するため」の情報に相当する。 したがって、本願補正発明と引用発明とは、「第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したRRC メッセージ中の指示内容を使用するステップ;を備え」る点で一致している。 また、引用発明において、eNBがRRCメッセージを介してUEに通知するLCGバッファ送信待ちデータ量レベル情報の長さが7ビットである時に、データ量レベル情報の長さが6ビットであるバッファサイズのレベル表を使用しないことは明らかである。したがって、本願補正発明と引用発明とは、「前記第2のバッファサイズのレベル表が使用される際には、前記第1のバッファサイズのレベル表は使用されない」点で一致している。 したがって、本願補正発明と引用発明の一致点・相違点は、次のとおりである。 [一致点] 「無線通信システムにおいてバッファ状態報告を処理する方法であり、 第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したRRC メッセージ中の指示内容を使用するステップ;を備え、 前記第1のバッファサイズのレベル表は、第1のバッファサイズの最大値を有し、前記第2のバッファサイズのレベル表は、前記第1のバッファサイズの最大値より大きい第2のバッファサイズの最大値を有し、前記第2のバッファサイズのレベル表が使用される際には、前記第1のバッファサイズのレベル表は使用されないことを特徴とする、方法。」である点。 [相違点] 第1のバッファサイズのレベル表を使用する代わりに、第2のバッファサイズのレベル表を使用すべきか否かを指示するために、eNBから受信したメッセージが、本願補正発明では、RRC Connection Reconfigurationメッセージであるのに対して、引用発明では、RRC メッセージである点。 5.相違点についての検討 国際公開第2009/099371号(2009年8月13日公開)(特表2011-511552号公報)の従来技術を説明している図1に開示されているように、新しい構成を使用する際に、eNBがUEにRRC接続再構成メッセージを送信することは、周知である。したがって、引用発明のeNBがUEにLCGバッファ送信待ちデータ量レベル情報の長さを通知するRRCメッセージを、RRC接続再構成メッセージとすることは、具体化手段における微差に過ぎない。 したがって、本願補正発明は、引用発明と実質同一である。 よって、本願補正発明は、先願明細書に記載された発明と同一であり、しかも、本願補正発明の発明者が上記先願明細書に記載された発明の発明者と同一であるとも、また、本願の出願時に、その出願人が上記他の出願の出願人と同一であるとも認められないので、本願補正発明は、特許法29条の2第1項の規定により特許を受けることができない。 6.むすび 以上のとおり、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3.本願発明について 平成26年3月5日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下、「本願発明」という。)は、平成25年5月10日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定されるものである。 1.先願及び引用発明 原査定の拒絶の理由に引用された先願1、及び引用発明は、前記「第2.3.」に記載したとおりである。 2.対比・判断 本願発明は、前記「第2.」で検討した本願補正発明から補正事項a.?bの構成を省いたものである。 そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「第2.5.」に記載したとおり、先願明細書に記載された発明と同一であるから、本願発明も同様の理由により、先願明細書に記載された発明と同一である。また、本願発明の発明者が上記先願明細書に記載された発明の発明者と同一であるとも、また、本願の出願時に、その出願人が上記他の出願の出願人と同一であるとも認められないので、本願発明は、特許法29条の2第1項の規定により特許を受けることができない。 3.むすび 以上のとおり、本願の請求項1に係る発明は、特許法29条の2第1項の規定により特許を受けることができない。 したがって、本願のその余の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。 |
審理終結日 | 2015-02-24 |
結審通知日 | 2015-03-03 |
審決日 | 2015-03-17 |
出願番号 | 特願2011-117021(P2011-117021) |
審決分類 |
P
1
8・
575-
Z
(H04W)
P 1 8・ 16- Z (H04W) |
最終処分 | 不成立 |
前審関与審査官 | 廣川 浩 |
特許庁審判長 |
佐藤 聡史 |
特許庁審判官 |
寺谷 大亮 江口 能弘 |
発明の名称 | 無線通信システムにおいてバッファ状態報告を処理する方法および装置 |
代理人 | 伊東 忠重 |
代理人 | 伊東 忠彦 |
代理人 | 大貫 進介 |