特許拒絶査定不服審判
2016-010785
長期進化型(LTE)システムにおけるアップリンク欠乏状態回避を支援するための方法および装置
- 審判番号
- 2016-010785
- 法域
- 特許
- 審判種別
- 拒絶査定不服審判(拒絶査定不服の審決)
- 出願番号
- 特願2014-156472外部サイト(J-PlatPat)へ移動します
- 請求日
- 2016年07月15日
- 審決日
- 2017年11月21日
- 公報発行日
- 2018年05月25日
- 結論
- 請求不成立
- 当事者
- 【請求人】インターデイジタル テクノロジー コーポレーション
- 【請求人代理人】特許業務法人 谷・阿部特許事務所
- 分類
- P18 .537-Z (H04W)
- 根拠条文(結論部分から自動抽出・参考)
- 特許法36条6項1号
- 条文(本文から自動抽出・参考)
- 特許法第36条第6項第1号、特許法第17条の2第5項第1号
- データ出所
- 審決公報(SGML)
事件の表示
特願2014-156472「長期進化型(LTE)システムにおけるアップリンク欠乏状態回避を支援するための方法および装置」拒絶査定不服審判事件〔平成26年12月11日出願公開、特開2014-233082〕について、次のとおり審決する。
結論
【結 論】
本件審判の請求は、成り立たない。
理由
【理 由】
第1 手続の経緯
本願は、2008年(平成20年)3月12日(パリ条約による優先権主張外国庁受理2007年3月14日 米国)を国際出願日とした特願2009-553607号の一部を、平成23年8月11日に新たな特許出願とした特願2011-175916号の一部を、平成24年5月21日に新たな特許出願とした特願2012-116008号の一部を、更に平成26年7月31日に新たな特許出願としたものであって、平成27年7月9日付けで拒絶理由が通知され、同年11月20日付けで意見書及び手続補正書が提出され、平成28年3月8日付けで拒絶査定されたところ、同年7月15日に拒絶査定不服審判の請求がなされ、同時に手続補正がなされたものである。
第2 原査定の概要
原査定(平成28年3月8日付け拒絶査定)の概要は、平成27年7月9日付け拒絶理由通知書も参照すれば次のとおりである。
・・・・・・
2.(サポート要件)この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。
・・・・・・
備考
・・・・・・
●理由2.1(特許法第36条第6項第1号)について
・請求項 1-30
・・・・・請求項1記載の
『前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと、およびに前記第2のUL RBに関連付けられた前記ULのデータが前記UL RBsの第1のグループの前記少なくとも1つのUL RBの優先度よりも高い優先度を有していること基づいて、バッファー状態報告(BSR)を提供すること』
は、発明の詳細な説明に記載されていない。
請求項16、及び、これらの請求項を引用する請求項2-15,17-30も、同様である。
●理由2.3(特許法第36条第6項第1号)について
・請求項 2-15,17-30
・・・・・請求項2記載の
『送信のための前記UL RBsの第1のグループのいずれかのULに関連付けられた未処理のULのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったことに基づいて、BSRを提供すること』は、発明の詳細な説明に記載されていない。
請求項17、及び、これらの請求項を引用する請求項3-15,18-30も、同様である。
・・・・・・
第3 請求人の主張
請求人は審判請求書(平成28年8月30日付け手続補正書を参照。)において、審判請求時の補正を前提として、概略以下のように主張している。
「・・・・
(c-3)理由2.1について
拒絶査定において、補正前の請求項1について、“『前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと、およびに前記第2のUL RBに関連付けられた前記ULのデータが前記UL RBsの第1のグループの前記少なくとも1つのUL RBの優先度よりも高い優先度を有していること基づいて、バッファー状態報告(BSR)を提供すること』は、発明の詳細な説明に記載されていない。”
と認定されました。
上記のとおり、補正前の請求項1の「UL無線ベアラ(RB)の第1のグループ」の記載は削除されており、補正後の請求項1には存在しません。また、補正後の請求項1の第3段落において、バッファー状態報告(BSR)は、WTRUの状況(WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となった状況)に応じて生じるイベントに応じて提供されることが明確にされました。
また、拒絶査定において、“出願人が主張するように、明細書の段落[0024]には、高優先度のRBのみ報告することが記載されている。”と認定されました。
しかしながら、この認定は、明細書全体からの把握される事項が考慮されていないと思料いたします。
上記のように、本願の開示において、本質的に、報告をトリガーするためのイベントは
、WTRUに関する情報の値があるレベルまで上昇する(閾値を超過する)場合に発生するイベント、すなわち、このイベントが適用されなければタイムリーな報告を行うことができなくなり、適切に許可(grant)のサイズ調整を行うことができなくなり、結果として、ULの欠乏及び/または許可ロスを生じさせることつながるようなイベントを含みます。そして、本願は、ネットワークが、適切にサイズ調整された許可を発行し、複数のUL無線リソース(BR)のバッファーの報告されたバッファーレベルに対して、各々のQoSレベルに従って対処しており、WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となった状況において、レポートがトリガーされるようにできることを開示します(例えば、本願明細書の第0004、0010、0024段落参照)。
より詳細には、本願により開示されているように、アプリケーションの間で許可された資源を如何に分配するかに関してネットワークは制御しません。許可された資源(WTRUが既に報告しているより低い優先度のRBに基づいて許可された資源)がより高い優先度のRBのデータのために使われる結果として、より低い優先度のフローに欠乏が生じます(例えば、本願の第0004段落参照)。しかしながら、本願は、さらに開示されているように、WTRUが、ネットワークが状況を把握した状態を維持することができれば、このような欠乏を回避できることを開示します(例えば、本願の第0024段落参照)。ネットワークに状況を把握させるため、WTRUは、バッファー状態報告を提供します(例えば、本願の第0024-0025段落参照)。また、本願は、バッファー状態報告が、予め定義されたイベントによりトリガーされることを開示します(例えば、本願の第0025段落参照)。本願は、報告をトリガーするために使用され得るイベントは、予め記述された情報についての値が閾値を超えたかまたは下回るイベントを含むことを開示します(例えば、本願の第0025段落参照)。予め記述された情報は、バッファー占有率情報を含みます(例えば、第0020段落参照)。バッファー状態情報は、複数のRBsのそれぞれについての値を含まなければなりません(例えば、第0020、0025段落参照)。WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータの利用可能となったWTRUの状況に対処ために(例えば、第0004、0010段落参照)、バッファー状態情報は、より高い優先度のRBのバッファー占有についての値を含まなければなりません。WTRUが、ネットワークが状況を把握した状態を維持するために、この値と関連した閾値との組み合わせにより、設定された閾値がどのようなものであっても、より高い優先度RBのバッファー占有についての値はそのような閾値条件を満たす場合は、バッファーバッファー状態報告をトリガーしなければなりません。それ故、より高い優先度のRBについてのバッファー占有の値は、そのより高い優先度のRBについて、データが利用可能になったことを示します。そして、そのような値が、関連する閾値に適用された場合、バッファー状態報告がトリガーさえることになります。
以上のように、本願の発明の詳細な説明は、補正後の請求項1の第3段落(補正前の第4段落に対応)に記載の事項を十分に、開示しているものと思料いたします。補正後の請求項16も同様です。
(c-4)理由2.3について
拒絶査定において、“請求項2記載の『送信のための前記UL RBsの第1のグループのいずれかのULに関連付けられた未処理のULのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったことに基づいて、BSRを提供すること』は、発明の詳細な説明に記載されていない。請求項17、及び、これらの請求項を引用する請求項3-15,18-30も、同様である。”と認定されました。
本願の開示において、本質的に、報告をトリガーするためのイベントは、WTRUに関する情報の値があるレベルまで上昇する(閾値を超過する)場合に発生するイベント、すなわち、このイベントが適用されなければタイムリーな報告を行うことができなくなり、適切に許可(grant)のサイズ調整を行うことができなくなり(または許可を与えなくなり)、結果として、ULの欠乏及び/または許可ロスを生じさせることつながるようなイベントを含みます。そして、本願発明は、周期的な報告が複数のUL無線ベアラ(RBs)のバッファーレベルにおいて、データを欠いていることを示す故、ネットワークが許可を発行していない状況において、WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となったWTRUの状況に対処するために、報告がトリガーされることを開示します。第0025段落に開示されているようなバッファー状況報告(BSR)および第0034段落(当審注:記載内容から見て「第0024段落」の誤記であると認められる。)に開示されているようなBSRは、複数のRBsに関連づけられたデータを欠いているため許可を受け取っていない状況において、WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となったWTRUの状況が意図されています。
したがって、請求項2は、本願の発明の詳細な説明に記載された発明であると思料いたします。請求項17についても同様です。」(当審注:下線は、平成29年2月27日付け上申書によって請求人が訂正した箇所である。)
第4 当審の判断
1 補正の適否について
平成28年7月15日付けでなされた手続補正(以下、「本件補正」という。)は、請求項1、2、4、6-8、11、15-19、21-23,26,30については、明りょうではない記載の釈明を目的とし、請求項31-58については請求項の削除を目的としたものであるから、特許法第17条の2第5項第1号及び第4号(補正の目的)の規定に適合するものであり、また、同法第17条の2第3項(新規事項)、同法第17条の2第4項(シフト補正)の規定に違反しないことも明らかである。
したがって、平成28年7月15日付けでなされた手続補正は適法になされたものである。
2 補正後の請求項
補正後の請求項1、2は以下のとおりのものである。
「 【請求項1】
無線送受信ユニット(WTRU)からのアップリンク(UL)のデータをスケジューリングする方法であって、
複数のUL無線ベアラ(RBs)に関連付けられた、現在のバッファー状態情報を、各々のビットレートに対する前記複数のUL RBsの各々のトークンバケットのサイズに基づいて、判定することであって、前記現在のバッファー状態情報は、(i)前記WTRUにおけるバッファーが送信のための前記複数のUL RBsのうちの少なくとも1つのUL RBに関連付けられた未処理のULのデータを含んでいること、および(ii)前記複数のUL RBsのうちの第2のUL RBに関連付けられたULのデータが送信のために利用可能になったことを示す、ことと、
前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと、および前記第2のUL RBが前記少なくとも1つのUL RBの優先度よりも高い優先度を有していることに基づいてトリガーされるイベントに応答して、バッファー状態報告(BSR)を提供することと、
提供した前記BSRに応答して、前記第2のUL RBに関連付けられた前記ULのデータの送信の許可を受信することと
を具備する方法。
【請求項2】
前記複数のUL無線ベアラ(RBs)に関連付けられた、第2の現在のバッファー状態情報を、各々のビットレートに対する前記複数のRBsの各々のトークンバケットのサイズに基づいて、判定することと、
前記第2の現在のバッファー状態情報が、送信のための前記少なくとも1つのUL RBに関連付けられた未処理のULのデータをバッファーが欠いていることを示すこと、および前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったことに基づいてトリガーされるイベントに応答して、BSRを提供することをさらに備えた、請求項1に記載の方法。」
3 理由2.1について
理由2.1は、本件補正前の請求項1に記載された
「前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと、および前記第2のUL RBが前記UL RBsの第1のグループの前記少なくとも1つのUL RBの優先度よりも高い優先度を有していることに基づいて、バッファー状態報告(BSR)を提供すること」は、発明の詳細な説明に記載されていないというものである。
当該記載は、本件補正により以下のように補正された。
「前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと、および前記第2のUL RBが前記少なくとも1つのUL RBの優先度よりも高い優先度を有していることに基づいてトリガーされるイベントに応答して、バッファー状態報告(BSR)を提供すること」
上記本件補正後の記載によれば、バッファー状態報告(BSR)の提供を行うためのイベントのトリガーが、
(1)第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったこと(以下、「条件1」という。)、および、
(2)前記第2のUL RBが前記少なくとも1つのUL RBの優先度よりも高い優先度を有していること(以下、「条件2」という。)、
という2つの条件に基づいて行われることが特定されている。
これに対して、発明の詳細な説明において、イベントのトリガーに関して記述されているのは【0025】であり、そこには次のように記載されている。
「【0025】
WTRU210は、自身の報告またはトークン・バケット情報を定期的に送信する(ステップ410)ことができ、または予め定義されたイベントによりそれをトリガーすることができる。報告をトリガーするために利用することができるイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントを含む。例えば、あるRBまたはRB群に対するトークンの量が、予め定義された閾値を下回るなら、報告するべくWTRU210をトリガーすることができる。閾値は、RB確立にてRRC信号方式により設定することができ、そしてトークン・バケットの最大のサイズの一部分(fraction)であると定義することができる。」
上記記載によれば、報告をトリガーするイベントは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントであって、例えば、あるRBまたはRB群に対するトークンの量が、予め定義された閾値を下回るというイベントをトリガーの条件とすることが例示されているのみである。そうしてみると、上述した請求項1におけるバッファー状態報告(BSR)の提供を行うためのイベントをトリガーする2つの条件(条件1、条件2)については何ら記載されていない。また、仮にバッファー状態を報告する必要が生じたのであるから、条件1の「第2のUL RBに関連付けられたULのデータが送信のために利用可能になったこと」が報告するためのイベントに当然なり得るといえたとしても、「第2のUL RBに関連付けられたULのデータ」の優先度を、他のUL RBの優先度との関係において規定する条件2については、発明の詳細な説明に記載されているということはできない。
したがって、本願の請求項1に係る発明は、発明の詳細な説明に記載したものではない。
請求項1と同様の記載を有する請求項16、及び請求項1、16を引用する請求項2-15、17-30に係る発明についても発明の詳細な説明に記載したものとはいえない。
なお、請求人は審判請求書において「WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となった状況において、レポートがトリガーされるようにできることを開示します(例えば、本願明細書の第0004、0010、0024段落参照)。」と主張する。
しかしながら、本願明細書の【0004】には高優先度フローが利用可能な帯域幅まで拡大すると低優先度のフローが欠乏状態になると言うことが、また【0010】には許可ロスがどのように発生するかと言うことが、それぞれ本願発明の背景技術として記載されているのみである。【0024】をみてもWTRU210がWTRU210に関連する情報をeNB220に報告することにより許可ロスを回避する支援をすることが可能であると言うことや、WTRU210が「それぞれのRB、RBのグループ、すべてのRB、高優先度のRBのみ、または任意の組合せに対して報告する」ことについて記載されているのみであって、バッファー状態報告を行うためのイベントのトリガーが上述した条件1及び条件2に基づいて行われることについて記載されていない。
したがって、請求人の上記主張を採用することはできない。
4 理由2.3について
理由2.3は、本件補正前の請求項2に記載された
「送信のための前記UL RBsの第1のグループのいずれかのULに関連付けられた未処理のULのデータをバッファーが欠いていることを示す前記現在のバッファー状態情報、および前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったことに基づいて、BSRを提供すること」は、発明の詳細な説明に記載されていないというものである。
当該記載は、本件補正により以下のように補正された。
「 前記複数のUL無線ベアラ(RBs)に関連付けられた、第2の現在のバッファー状態情報を、各々のビットレートに対する前記複数のRBsの各々のトークンバケットのサイズに基づいて、判定することと、
前記第2の現在のバッファー状態情報が、送信のための前記少なくとも1つのUL RBに関連付けられた未処理のULのデータをバッファーが欠いていることを示すこと、および前記第2のUL RBに関連付けられた前記ULのデータが送信のために利用可能になったことに基づいてトリガーされるイベントに応答して、BSRを提供すること」
当該記載によれば、BSRを提供するためのイベントのトリガーが「第2の現在のバッファー状態情報が、送信のための前記少なくとも1つのUL RBに関連付けられた未処理のULのデータをバッファーが欠いていることを示すこと」(以下、「条件A」という。)を条件の一つとすることが特定されている。
しかしながら、上記「3 理由2.1について」で検討したように、発明の詳細な説明には、バッファー状態報告の提供を行うためのイベントのトリガーは、予め記述された情報に対する値が閾値を超過するか、または下回るというイベントであって、例えば、あるRBまたはRB群に対するトークンの量が、予め定義された閾値を下回るということをトリガーの条件とすることが例示されているのみである。そして、上記条件Aに基づいてトリガーされるイベントに応答してBSRを提供することについては、本願の発明の詳細な説明に記載も示唆もなく、また自明のことともいえない。
したがって、本願の請求項2に係る発明は、発明の詳細な説明に記載されたものではない。
請求項2と同様の記載を有する請求項17、及び請求項2、17を引用する請求項3-7、9-15、18-30に係る発明についても発明の詳細な説明に記載したものとはいえない。
なお、請求人は審判請求書において、「第0025段落に開示されているようなバッファー状況報告(BSR)および第0034段落(当審注:記載内容から見て「第0024段落」の誤記であると認められる。)に開示されているようなBSRは、複数のRBsに関連づけられたデータを欠いているため許可を受け取っていない状況において、WTRUが既に報告している他のRBsよりも高い優先度を有しているRBについてのデータが利用可能となったWTRUの状況が意図されています。」と主張しているが、【0024】及び【0025】をみても、「前記第2の現在のバッファー状態情報が、送信のための前記少なくとも1つのUL RBに関連付けられた未処理のULのデータをバッファーが欠いていることを示すこと」をトリガーの条件としていることは記載されていない。
したがって、請求人の主張を採用することはできない。
第5 むすび
以上のとおり、本件出願は、特許請求の範囲の記載に不備があり、特許法第36条第6項第1号に規定する要件を満たしていないから、特許を受けることができない。
よって、結論のとおり審決する
審決本文(J-PlatPat)
J-PlatPatの審決検索トップを開きます。番号入力で「審判番号」を選び、下の番号を貼り付けて検索してください。
J-PlatPat 審決検索を開く
2016-010785