ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04W |
|---|---|
| 管理番号 | 1311138 |
| 審判番号 | 不服2014-22157 |
| 総通号数 | 196 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2016-04-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2014-10-31 |
| 確定日 | 2016-02-10 |
| 事件の表示 | 特願2012-545074「バッファステータス報告を実現する方法及びシステム」拒絶査定不服審判事件〔平成23年12月29日国際公開、WO2011/160480、平成25年 5月 2日国内公表、特表2013-515408〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、平成23年3月30日を国際出願日とする出願(パリ条約による優先権主張平成22年6月21日(中国))であって、平成25年9月4日付けで拒絶の理由が通知され、これに対して同年12月9日に意見書及び手続補正書が提出されたが、平成26年6月27日付けで拒絶査定がなされ、同査定の謄本は同年7月8日に請求人に送達された。これに対して、同年10月31日に拒絶査定不服審判の請求がなされたものである。 第2 本願発明 本願の請求項1に係る発明(以下、「本願発明」という。)は、平成25年12月9日付け手続補正書の特許請求の範囲の請求項1に記載された以下の事項により特定されるとおりのものである。 「【請求項1】 バッファステータス報告を実現する方法であって、前記方法は、 ユーザデバイスが自体のアルゴリズム或いは定義済みの規則に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること、あるいは、 進化型基地局はユーザデバイスが使用すべきであるバッファサイズレベル表を確定し、且つ確定された結果を前記ユーザデバイスに通知し、前記ユーザデバイスが前記確定された結果に基づいて、論理チャネルのバッファステータスを報告するために、第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、バッファステータスレポートを前記進化型基地局に送信することを含み、 ここで、前記第1バッファサイズレベル表がLTE release 8により定義されたものであり、前記第2バッファサイズレベル表がN個のデータ量ランクを含み、ここで、最後のM個のデータ量ランクが対応するデータ量区間は前記第1バッファサイズレベル表のデータ量区間境界の最大値150000より大きく、且つ値が順次に増大するデータ量区間であり、MとNがいずれも整数であり、且つM<=Nであるバッファステータス報告を実現する方法。」 第3 引用例 1 原査定の拒絶の理由で引用された、本願の優先日前に頒布された刊行物であるNokia Siemens Networks, Nokia Corporation、"BSR for Carrier Aggregation"、3GPP TSG-RAN WG2 Meeting #70、 R2-102805(平成22年5月10日発行)(以下、「引用例」という。)には、次の事項が記載されている。(下線は当審が付与。) (1)「1 Introduction Similar to HSUPA [1] [2], BSR table for LTE Rel-8 was settled with exponentially distributed granularity and the Maximum buffer size level derived based on the uplink peak data rate multiplied by the expected response time [3] [4]. With possibility of multiple UL carrier configured and UL MIMO in Rel-10, the uplink peak data rate can be increased by several times, thus it is necessary to discuss whether BSR extension is needed.」 (当審訳:1 イントロダクション HSUPAと同様に[1][2]、LTE Rel-8のBSRテーブルは指数関数的分布を有する粒度及びアップリンクのピークデータレートと予想応答時間との積に基づく最大バッファサイズレベルによって決定されたものである[3][4]。複数のアップリンクキャリアの配置やRel-10のUL MIMOの可能性によって、アップリンクのピークデータレートは数倍に増加する可能性があり、それゆえBSRの拡張が必要かどうかの議論が必要である。) (2)「2 BSR format for CA From scheduling point of view, current BSR table based on a maximum value assuming one UL CC is not enough for CA and UL MIMO as the eNB has no way to get further information of how many extra resources need to be configured/allocated when getting the BS > 150 Kbyte. If the maximum buffer size level is derived based on the uplink peak data rate and the expected response time after a buffer status report is transmitted, with a maximum transport block size of 75376 bits [5], a response time of 2 RTTs, 5 UL CC [6] and 2 TBs per CC, the maximum buffer size level for in E-UTRA uplink becomes Bmax = (75376 x 16 x 5 x 2) / 8 = 15752 x 10 bytes # 150 x 10 Kbyte. One possibility would be to extend BS size to 7 bits. Unfortunately this straightforward solution is not compatible with both the short BSR and long BSR formats and should therefore only be considered if unavoidable. Proposal 1: Reuse per LCG Short/Long BSR format, i.e. 2 bits LCG ID and 6 bits BS size. An alternative would be to extend the table by enlarging the maximum value with lower granularity while keeping the 6bits BS size unchanged [7]. Enlarging the maximum value by 10 times with the penalty of less accuracy when only one UL CC is configured without UL MIMO might not be acceptable because in reality one UL CC without UL MIMO would still be the typical case even for Rel-10. Even though how much the inaccuracy will impact the scheduling efficiency depends very much on eNB scheduling algorithm, we would expect Rel-10 specifications to provide no less scheduling efficiency than earlier Releases for the UEs without CA configured or non-CA capable UEs. Moreover, modifing Rel-8/9 BSR table would have backward compatibility issue when Rel-10 UEs are scheduled in Rel-8/9 network. Another alternative would be to have multiple tables with different maximum value and granularity to provide more accurate information, e.g. at least one table identical to Rel-8/9 and another new table supporting the uplink peak data rate supported in Rel-10. To avoid back compatibility issues, the new table would then only be used when Rel-10 feature, e.g. CA/UL-MIMO, is configured. Proposal 2: Introduce a new BSR table to support 500 Mbps UL data rate. Proposal 3: The new table is used when Rel-10 feature, e.g. CA/UL-MIMO, is configured. When multiple tables are usable, the UE can choose the tables according to current buffer status and indicate to the eNB which one is used via e.g. the R bit(s) in the MAC subheader. UE chooses the table with the finest granularity to provide most accurate information to the eNB. However, as there are only 2 R bits in the MAC subheader, which is not enough to indicate which table has been used for the 4 LCGs of a Long BSR, all LCGs of the long BSRs should therefore use same BSR table. A simple criterion could be to select the table according to the LCG with most data buffered. Alternatively the LCG that has triggered the BSR could also set the BSR table. Proposal 4: UE chooses the tables according to current buffer status and indicates to eNB which table is used.」 (当審訳:2 CAのためのBSRフォーマット スケジューリングの観点からは、単一のUL CCを前提とした最大値に基づく現在のBSRテーブルは、BS > 150キロバイトとなった場合、更にどれほどのリソースを配置・割り当てる必要があるのかに関する更なる情報をeNBが得ることができないために、CAやUL MIMOのためには十分ではない。 もし、最大のバッファサイズレベルが、アップリンクのピークデータレートとバッファステータスレポートが送信された後の予想応答時間から求められるとすると、最大のトランスポートブロックサイズを75376ビット[5]、応答時間を2 RTT、5つのUL CC[6]及びCC当たり2 TBとして、E-UTRAアップリンクのための最大バッファサイズレベルは、Bmax = (75376 x 16 x 5 x 2) / 8 = 15752 x 10 バイト # 150 x 10 キロバイトとなる。 BSのサイズを7ビットに拡張するということが1つ可能性である。このわかりやすい解は、残念ながら短いBSRと長いBSRのフォーマットと互換性がないため、不可避な場合のみ検討されるべきである。 提案1:LCGの短い/長いBSRフォーマット、すなわち、2ビットのLCG IDと6ビットのBSサイズを再利用する。 1つの代替手段は、6ビットのBSサイズを不変としつつ、粒度を下げて最大値を上げることである[7]。UL MIMOなしで1つのUL CCが配置される場合には、精度を犠牲にして最大値を10倍にすることは、UL MIMOなしで1つのUL CCが配置されることが、現実にはRel-10でも依然として典型的であるから、許容できないかもしれない。非正確性がスケジューリング効率にどの程度影響を与えるのかはeNBのスケジューリングアルゴリズムに大きく依存するとはいえ、我々はRel-10の規格が、CAの配置をしないUE、あるいは、CAに対応しないUEのための古いリリースよりも低くないスケジューリング効率を提供することを期待している。さらに、Rel-8/9のBSRテーブルの変更は、Rel-10のUEがRel-8/9のネットワークでスケジューリングを受ける際に後方互換性の問題を生じさせる。 もう1つの代替手段は、より正確な情報を提供するために、異なる最大値と粒度を有する複数のテーブル、すなわち、少なくとも1つのRel-8/9と同じテーブルと、Rel-10でサポートされるアップリンクのピークデータレートをサポートする別の新たなテーブル、を使用することである。後方互換性の問題を避けるため、新たなテーブルはRel-10の仕様、すなわち、CAやUL-MINOが設定されるときにのみ使用される。 提案2:500Mbpsのアップリンクデータレートをサポートする新たなBSRテーブルを導入する。 提案3:新たなテーブルはRel-10の仕様、すなわち、CAやUL-MINOが設定されるときにのみ使用される。 複数のテーブルが使用可能な場合、UEは現在のバッファステータスに基づいてテーブルを選択し、例えばMACサブヘッダのRビットを通じて、eNBにどれが使用されるのかを指示する。UEはeNBに最も精度の高い情報を提供できるよう、最も粒度の高いテーブルを選択する。しかしながら、MACサブヘッダには2Rビットしかなく、これらは長いBSRの4つのLCGについてどのテーブルが使われたのかを指示するには十分でないので、長いBSRの全てのLCGは同じBSRテーブルを使用すべきである。1つの単純な基準は、最も多くのデータがバッファされているLCGに基づいてテーブルを選択することである。代替として、BSRをトリガしたLCGに基づいてテーブルを選択することもできる。 提案4:UEが現在のバッファステータスに基づいてテーブルを選択し、eNBにどのテーブルが使用されるのかを指示する。) 2 これらのことから、引用例には、次の発明(以下、「引用発明」という。)が記載されていると認められる。 HSUPAと同様に、LTE Rel-8のBSRテーブルは指数関数的分布を有する粒度及びアップリンクのピークデータレートと予想応答時間との積に基づく最大バッファサイズレベルによって決定されたものであり、 複数のアップリンクキャリアの配置やRel-10のUL MIMOの可能性によって、アップリンクのピークデータレートは数倍に増加する可能性があり、それゆえBSRの拡張が必要かどうかの議論が必要であり、 スケジューリングの観点からは、単一のUL CCを前提とした最大値に基づく現在のBSRテーブルは、BS > 150キロバイトとなった場合、更にどれほどのリソースを配置・割り当てる必要があるのかに関する更なる情報をeNBが得ることができないために、CAやUL MIMOのためには十分ではなく、 BSのサイズを7ビットに拡張するというわかりやすい解は、残念ながら短いBSRと長いBSRのフォーマットと互換性がないため、不可避な場合のみ検討されるべきであり、 LCGの短い/長いBSRフォーマット、すなわち、2ビットのLCG IDと6ビットのBSサイズを再利用し、 1つの代替手段は、より正確な情報を提供するために、異なる最大値と粒度を有する複数のテーブル、すなわち、少なくとも1つのRel-8/9と同じテーブルと、Rel-10でサポートされるアップリンクのピークデータレートをサポートする別の新たなテーブル、を使用することであり、 500Mbpsのアップリンクデータレートをサポートする新たなBSRテーブルを導入し、 複数のテーブルが使用可能な場合、UEは現在のバッファステータスに基づいてテーブルを選択し、例えばMACサブヘッダのRビットを通じて、eNBにどれが使用されるのかを指示し、 UEはeNBに最も精度の高い情報を提供できるよう、最も粒度の高いテーブルを選択するが、MACサブヘッダには2Rビットしかなく、これらは長いBSRの4つのLCGについてどのテーブルが使われたのかを指示するには十分でないので、長いBSRの全てのLCGは同じBSRテーブルを使用すべきであり、 1つの単純な基準は、最も多くのデータがバッファされているLCGに基づいてテーブルを選択することであり、 代替として、BSRをトリガしたLCGに基づいてテーブルを選択することもでき、 UEが現在のバッファステータスに基づいてテーブルを選択し、eNBにどのテーブルが使用されるのかを指示する方法。 第4 対比 1 本願発明と引用発明とを対比する。 (1)本願発明は「ユーザデバイスが自体のアルゴリズム或いは定義済みの規則に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること」、又は、「進化型基地局はユーザデバイスが使用すべきであるバッファサイズレベル表を確定し、且つ確定された結果を前記ユーザデバイスに通知し、前記ユーザデバイスが前記確定された結果に基づいて、論理チャネルのバッファステータスを報告するために、第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、バッファステータスレポートを前記進化型基地局に送信すること」を択一的に選択することを構成要件の1つとするものであると解される。 (2)また、本願発明は、「ユーザデバイスが」、「第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択」する際に基づくものを「自体のアルゴリズム」又は「定義済みの規則」から択一的に選択することを構成要件の1つとするものであると解される。 (3)そして、一般に、本願発明における択一的に選択する部分についていずれかを選択したものが、引用発明に基づいて当業者が容易に発明をすることができたものであるといえる場合、本願発明全体についても、引用発明に基づいて当業者が容易に発明をすることができたものであるといえるから、本願発明と引用発明との対比を行うに当たっては、本願発明において択一的に選択する部分についていずれかを選択したものをその対象とすれば足りる。 (4)そこで、下記ア?オにおいては、本願発明において「ユーザデバイスが自体のアルゴリズム或いは定義済みの規則に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること」を選択するとともに、「ユーザデバイスが」、「第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択」する際に基づくものとして「自体のアルゴリズム」を選択したものと、引用発明とを対比する。 ア 引用発明における「UE」、「BSR」及び「eNB」は、それぞれ本願発明における「ユーザデバイス」、「バッファステータスレポート」及び「進化型基地局」に相当する。また、引用発明における「BSR」が、バッファステータスを報告するためのものであることは技術常識であるから、引用発明における一連の手順は、本願発明における「バッファステータス報告を実現する方法」といえる。 イ 引用発明における「Rel-8/9と同じテーブル」及び「Rel-10でサポートされるアップリンクのピークデータレートをサポートする別の新たなテーブル」は、それぞれ本願発明における「第1バッファサイズレベル表」及び「第2バッファサイズレベル表」に相当する。 ウ 引用発明における「UEはeNBに最も精度の高い情報を提供できるよう、最も粒度の高いテーブルを選択する」ことは、本願発明における「ユーザデバイスが自体のアルゴリズム」「に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択」することに相当する。 エ 引用発明において「UE」から「eNB」に提供される「正確な情報」や「精度の高い情報」が「BSR」に含まれる情報であることは明らかであるから、引用発明において「UE」が「eNB」に、BSRに含まれる「情報」を提供することは、本願発明において「バッファステータスレポートを進化型基地局に送信すること」に相当する。また、バッファステータスレポートが、論理チャネルのバッファステータスを報告するために、ユーザデバイスから基地局に送信されるものであることは、技術常識であるから、引用発明において、「UE」が「eNB」に、BSRに含まれる「情報」を提供することは、本願発明において「論理チャネルのバッファステータスを報告するために」行うことにも相当する。これらのことから、引用発明において「UE」が「eNB」に、BSRに含まれる「情報」を提供することは、本願発明において「論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信すること」に相当する。 オ 引用発明における「UEは現在のバッファステータスに基づいてテーブルを選択し、例えばMACサブヘッダのRビットを通じて、eNBにどれが使用されるのかを指示」することは、本願発明における「バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること」に相当する。 (5)前記ア?オによれば、引用発明には「バッファステータス報告を実現する方法であって、前記方法は、 ユーザデバイスが自体のアルゴリズムに基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること」を含む方法が記載されているといえる。 (6)さらに、前記(1)?(3)の前提を踏まえれば、引用発明には「バッファステータス報告を実現する方法であって、前記方法は、 ユーザデバイスが自体のアルゴリズム或いは定義済みの規則に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること、あるいは、 進化型基地局はユーザデバイスが使用すべきであるバッファサイズレベル表を確定し、且つ確定された結果を前記ユーザデバイスに通知し、前記ユーザデバイスが前記確定された結果に基づいて、論理チャネルのバッファステータスを報告するために、第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、バッファステータスレポートを前記進化型基地局に送信することを含」む方法が記載されているといえる。 (7)「Rel」がReleaseを意味すること、LTEにRel-8とRel-9が存在すること、及び、Rel-8とRel-9においてバッファステータス報告に同じバッファサイズレベル表が使用されることは、いずれも技術常識である(必要であれば、3GPP TS 36.321 V8.9.0 (2010-06)(平成22年6月18日発行)の第33頁及び3GPP TS 36.321 V9.3.0 (2010-06)(平成22年6月18日発行)の第34頁を参照。)から、引用発明における「Rel-8/9と同じテーブル」は、「LTE release 8により定義されたもの」であるということができる。 (8)引用発明における「バッファサイズレベル」は、本願発明における「データ量ランク」に相当する。 (9)バッファサイズレベル表が整数個のデータ量ランクを含むことは技術常識である(必要であれば、前記(7)で示した文献を参照。)から、引用発明における「Rel-10でサポートされるアップリンクのピークデータレートをサポートする別の新たなテーブル」は、Nを整数として、N個のデータ量ランクを含むものであるということができる。 2 以上から、本願発明と引用発明は、次の点で一致、相違する。 [一致点] バッファステータス報告を実現する方法であって、前記方法は、 ユーザデバイスが自体のアルゴリズム或いは定義済みの規則に基づいて第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、論理チャネルのバッファステータスを報告するために、バッファステータスレポートを進化型基地局に送信し、ここで、前記バッファステータスレポートには該バッファステータスレポートが使用されたバッファサイズレベル表を指示することに用いられる識別子が含まれること、あるいは、 進化型基地局はユーザデバイスが使用すべきであるバッファサイズレベル表を確定し、且つ確定された結果を前記ユーザデバイスに通知し、前記ユーザデバイスが前記確定された結果に基づいて、論理チャネルのバッファステータスを報告するために、第1バッファサイズレベル表及び少なくとも一つの第2バッファサイズレベル表の中の1種のフォーマットを使用することを選択し、バッファステータスレポートを前記進化型基地局に送信することを含み、 ここで、前記第1バッファサイズレベル表がLTE release 8により定義されたものであり、前記第2バッファサイズレベル表がN個のデータ量ランクを含み、Nが整数であるバッファステータス報告を実現する方法。 [相違点] 本願発明においては、「第2バッファサイズレベル表の最後のM個のデータ量ランクが対応するデータ区間は第1バッファサイズレベル表のデータ区間領域の最大値150000より大きく、且つ値が順次に増大するデータ量区間であり、Mが整数であり、且つM<=Nである」のに対し、引用発明においては、第2バッファサイズレベル表の最後のM個のデータ量ランクが対応するデータ区間の具体的内容が明らかでない点。 第5 判断 上記相違点について検討する。 1 引用発明における「Rel-10でサポートされるアップリンクのピークデータレート」がRel-8/9におけるアップリンクのピークデータレートよりも大きいことは技術常識であるから、「Rel-10でサポートされるアップリンクのピークデータレートをサポートする別の新たなテーブル」は、「Rel-8/9と同じテーブル」よりも「最大値を上げ」られたものであることは明らかである。 2 また、LTE Release 8で用いられるバッファサイズレベル表のデータ区間領域の最大値が150000であること、及び、バッファサイズレベル表のデータ量区間の値を順次に増大するよう構成することはいずれも技術常識である。(必要であれば、前記「第4」1(7)で示した文献を参照。) 3 そして、引用発明において、最大値を上げられたテーブルを具体的に構成する際に、前記2で示した技術常識を適用し、データ区間領域の最大値が150000より大きく、かつ、データ量区間の値が順次増大する第2バッファサイズレベル表とすることは、当業者が容易に想到し得たことである。また、こうして構成した第2バッファサイズレベル表の最後のM個のデータ量ランクが対応するデータ区間は、第1バッファサイズレベル表のデータ区間領域の最大値150000より大きくなること、及び、当該Mの値が第2バッファサイズレベル表に含まれるデータ量ランクの数であるNよりも大きな値をとり得ないこと、すなわち、こうして構成した第2バッファサイズレベル表が、本願発明のような構成となることは明らかである。(なお、バッファサイズレベル表を、N個のデータ量ランクを含み、最後のM個のデータ量ランクが対応するデータ量区間が150000より大きく、且つ値が順次に増大するデータ量区間となるよう構成した具体例は、引用例が本文中[7]として引用するSamsung、 "On BSR for REL-10"、3GPP TSG-RAN2#69bis meeting、R2-102459(平成22年4月12日発行)に記載の如く、本願の優先日において公知である。)また、本願発明のように構成したことによる効果も、引用発明及び技術常識から、当業者が予測できる範囲のものである。 4 したがって、本願発明は、引用発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができないものである。 第6 むすび 以上のとおり、本願発明は、本願優先日前に頒布された引用例に記載され た発明に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、その余の請求項に係る発明について言及するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2015-09-01 |
| 結審通知日 | 2015-09-08 |
| 審決日 | 2015-09-28 |
| 出願番号 | 特願2012-545074(P2012-545074) |
| 審決分類 |
P
1
8・
121-
Z
(H04W)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 廣川 浩 |
| 特許庁審判長 |
水野 恵雄 |
| 特許庁審判官 |
清水 祐樹 吉田 隆之 |
| 発明の名称 | バッファステータス報告を実現する方法及びシステム |
| 代理人 | 関谷 三男 |
| 代理人 | 平木 祐輔 |
| 代理人 | 頭師 教文 |
| 代理人 | 松丸 秀和 |