• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04W
管理番号 1323016
審判番号 不服2016-1414  
総通号数 206 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-02-24 
種別 拒絶査定不服の審決 
審判請求日 2016-01-29 
確定日 2017-01-10 
事件の表示 特願2014- 96154「モバイルデバイスのためのフロー制御を提供するシステム及び方法」拒絶査定不服審判事件〔平成26年10月 9日出願公開、特開2014-195272、請求項の数(26)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由
第1 手続の経緯

本願は、2010年6月8日(パリ条約による優先権主張外国庁受理2009年6月8日、米国、2010年6月7日、米国)を国際出願日とする出願であって、平成26年6月6日付けで手続補正がされ、平成26年8月26日付けで手続補正がされ、平成27年3月23日付けで拒絶理由が通知され、平成27年7月31日付けで手続補正がされ、平成27年9月14日付けで拒絶査定がされ、これに対し、平成28年1月29日に拒絶査定不服審判が請求されると同時に手続補正がされ、平成28年3月3日に前置報告がなされたものである。


第2 原査定の理由の概要と前置報告の内容

1.原査定の理由の概要

●理由1(進歩性)について
・請求項1-26
・引用文献等1-4
・備考
引用文献1(特に、2.1 Solution 1 (MAC Flow Control)参照)には、端末でデータの混雑を判断し、MAC CEを通してUEでサポートできるデータレートを基地局に通知することが記載されている。
本願の請求項1,10,19,23に係る発明と引用文献1に記載された発明とを比較すると、MAC CEは、本願発明では、フロー制御タイマ値を示す第1フィールドと前記フロー制御タイマ値のアプリケーションを制御するための第2フィールドを備えるのに対し、引用文献1にはその旨記載されていない点で相違する。
しかりながら、引用文献2(特に、82段落及び図28参照)には、フローコントロールリクエストパケット(本願発明のMAC制御要素に相当)を受信したノードが送信トラヒックを制御すべき時間を示すタイマー(本願発明のフロー制御タイマ値に相当)を含むことが記載されている。
さらに、引用文献3(特に、2.2 Potential Solutions参照)には、"The UE could signal the end of the reduced rate using the MAC flow control mechanism"(本願発明のフロー制御タイマ値のアプリケーションを制御するためものに相当)と記載されている。
引用文献1-3は、データフロー制御に関するものであるから、引用文献1に記載された発明において、引用文献2,3に記載された技術を採用して本願の請求項1,10,19,23に係る発明の構成とすることは当業者が容易に想到し得るものである。

本願の請求項2-9,11-18,20-24,25-26に係る発明の構成は、例えば、引用文献3にみられるように、送信ブロックの最大数を送ることや、引用文献4に例示されるように、MAC CEに電力制御要素を含めること等、いずれも本願出願当時の周知技術であって、それらを限定したものに過ぎない。
したがって、本願の請求項2-9,11-18,20-24,25-26に係る発明の構成は、引用文献1-4に基づいて、当業者が容易に想到し得るものである。

なお、出願人は意見書において、
「引用文献1-4は、本願請求項1に記載の「前記MAC制御要素は、既存のMAC制御要素に対する追加のMAC制御要素であること、そして、該追加のMAC制御要素は、フロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールドを備える(本願明細書の図6、段落0050等を参照)ことについて開示も示唆もしていません。したがって、補正後の特許請求の範囲に係る発明は、当業者といえども引用文献に基づいて容易に発明をすることができないので特許法第29条第2項の規定により拒絶を受けるべきではないと思料します。」
と主張するのでこれを検討する。

引用文献1には、「2.1.1. Solution 1 (MAC Flow Control)
In this solution, the UE sends a MAC Flow Control PDU to indicate the DL data rate the UE can support (as a fraction of the maximum DL rate indicated in the UE capability).
The triggers for this MAC Control PDU are implementation dependent and not specified in the standard. When the eNB receives this PDU, its' up to the eNB to reduce the DL traffic.
The advantages of this solution are:
・ We just need to reserve an LCID value, define a new MAC Control Element in the standard (as shown below), and define the SR trigger for such Control Element」
と記載されており、下線部には「規格で新たなMAC制御要素を定義し(下図参照)、このような制御要素のためのSRトリガを定義するLCID値を確保することが必要なだけである。」ことが記載されている。
また、引用文献1には、表6.2.1-2として、UL-SCHのためのLCIDの値を示す表が記載されており、それぞれ、Indexの00000に対応するLCID値がCCCH、Indexの00001-yyyyyに対応するLCID値が論理チャネルの識別、Indexのyyyyy-11001に対応するLCID値が予約、Indexの11010に対応するLCID値がフロー制御レポート、などであることが記載されており、このことからMAC制御要素は複数の異なるフィールドを有しているといえる。
したがって、新たなMAC制御要素(本願の追加のMAC制御要素に相当)を定義すること、そして、それに対応してフロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールドを備えることは引用文献1に記載された発明に基づいて当業者が容易に想到し得る程度のものである。
したがって、上記意見書の主張は採用できない。

<引用文献等一覧>
1.DL Flow Control in LTE (R2-082487),3GPP TSG-RAN WG2 #61bisR2-082487,2008年 5月
2.特開2006-101477号公報
3.DL Flow Control - initial conditions (R2-082450),3GPP TSG-RAN WG2 #62 R2-082450,2008年 4月28日(周知技術を示す文献)
4.3rd Generation Partnership Project;Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA)Medium Access Control (MAC) protocol specification(Release 8),3GPP TS 36.321 V8.2.0 (2008-05),2008年 5月,p.22 5.4.6 Power Headroom Reporting(周知技術を示す文献)


2.前置報告の内容

請求項1,10,19,23についての補正は限定的減縮を目的としている。この場合、補正後の請求項1,10,19,23に係る発明は特許出願の際独立して特許を受けることができるものでなければならない。
そこで、請求項1,10,19,23が独立して特許を受けることができるかについて検討する。
補正後の請求項1,10,19,23に係る発明と引用文献1に記載された発明とを、これまで検討した事項を略して比較すると、前記ダウンリンクのための低減されたデータレートを前記ユーザ通信装置が決定する際に、本願発明では特定された混雑に少なくとも部分的に基づいているのに対し、引用文献1に記載された発明では、その旨明記されていない点で相違する。
しかしながら、引用文献1で引用されている文献(下記引用文献5:前置報告書で新たに引用した文献)には、
「2.1.Background
Today's UEs support multimedia and many different applications running concurrently (e.g., email, video, voice, etc.), even more so in LTE due to the very high data rate supported. Each application demands certain amount of resources from the UE (e.g., processing power, buffers, battery power, etc.). The amount of resources needed is dynamic.
・・・
In extreme cases, a UE may even attempt to reduce the DL data rate by sending back HARQ NAKs, which is an extremely bad idea since it will be throttling the traffic from all the radio bearers equally (i.e., including VoIP, L3 signalling, etc.) and it's wasting the over-the-air capacity and network resources. We believe it is beneficial to have a standardised flow control procedure as opposed to different implementations by different UE vendors.」及び、「2.2. Potential Solutions
We identified the following alternatives to achieve flow control with pros and cons:
・MAC Flow Control- when the UE resource runs low, the UE sends a feedback to the eNB using a MAC Control PDU indicating the level of data rate reduction needed (e.g., reduce DL traffic by 10%, 50%, etc.). eNB reacts by reducing the DL data rate based on the QoS requirements for each radio bearer (e.g., eNB will reduce the DL data rate of the best-effort radio bearers only)」とあり、UEにおける混雑を緩和させるために、低減されたデータレートをUEがeNBに要求する、すなわち、UEが低減されたデータレートを決定する旨が記載されている。
したがって、引用文献1-5に記載された発明に基づいて、本願の請求項1,10,19,23に係る発明の構成とすることは当業者が容易に想到し得るものである。
なお、本願の請求項2-9,11-18,20-22,24-26に係る発明についても、拒絶理由通知、拒絶査定及び上記で検討した通り、引用文献1-5に記載された発明に基づいて当業者が容易に想到し得るものである。

よって、この補正は同法第17条の2第6項において準用する同法第126条第7項の規定に違反するものであるから、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下されるべきものである。
そして、この出願は原査定の理由に示したとおり拒絶されるべきものである。


<引用文献等一覧>
1.DL Flow Control in LTE (R2-082487),3GPP TSG-RAN WG2 #61bisR2-082487,2008年 5月
2.特開2006-101477号公報
3.DL Flow Control - initial conditions (R2-082450),3GPP TSG-RAN WG2 #62 R2-082450,2008年 4月28日
4.3rd Generation Partnership Project;Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA)Medium Access Control (MAC) protocol specification(Release 8),3GPP TS 36.321 V8.2.0 (2008-05),2008年 5月,p.22 5.4.6 Power Headroom Reporting
5.Fujitsu, Motorola, NEC, Panasonic, and Qualcomm Europe,DL Flow Control in LTE,3GPP TSG-RAN WG2#61 R2-081253,2008年 2月15日,


第3 平成28年1月29日付けの手続補正の適否について

3-1.本件補正の目的

平成28年1月29日付けの手続補正(以下「本件補正」という。)により、特許請求の範囲の請求項1は、

「無線通信システムにおいて動作可能なユーザ通信装置であって、
データレートで基地局からデータを受信し、
前記ユーザ通信装置における混雑を特定し、
推奨されるデータレートを示すために、無線信号としてのMAC制御要素を前記基地局に送信し、ここにおいて、前記MAC制御要素は、フロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールドを備え、及び
前記推奨されるデータレートで前記基地局からデータを受信する、ための命令を保持するメモリと、
前記命令を実行するプロセッサと、を備え、
前記MAC制御要素は、前記基地局に送信中の既存のMAC制御要素のセットに対する追加のMAC制御要素である、ユーザ通信装置。」(以下「補正前発明」という。)

から

「無線通信システムにおいて動作可能なユーザ通信装置であって、
データレートでダウンリンクを介して基地局からデータを受信し、
前記ユーザ通信装置における混雑を特定し、
前記特定された混雑に少なくとも部分的に基づいて前記ダウンリンクのための低減されたデータレートを前記ユーザ通信装置が決定し、
前記低減されたデータレートを示すために、無線信号としてのMAC制御要素を前記基地局に送信し、ここにおいて、前記MAC制御要素は、フロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールドを備え、及び
前記低減されたデータレートで前記基地局からデータを受信する、ための命令を保持するメモリと、
前記命令を実行するプロセッサと、を備え、
前記MAC制御要素は、前記基地局に送信中の既存のMAC制御要素のセットに対する追加のMAC制御要素である、ユーザ通信装置。」(以下「補正後発明」という。)

に変更された。

上記補正は、補正前発明の「推奨されるデータレート」として、「低減されたデータレート」であって、「特定された混雑に少なくとも部分的に基づいて前記ダウンリンクのため」に「ユーザ通信装置」が決定するものであることに限定するものであるから、本件補正は特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。

そこで、補正後発明が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第6項において準用する同法第126条第7項の規定に適合するか)について以下に検討する。

3-2.引用発明

原査定の拒絶の理由に引用された3GPP TSG-RAN WG2 #61bis R2-082487(May 5-9,2008),NEC,Panasonic,Qualcomm Europe,"DL Flow Control in LTE"(以下「引用例1」という。下線は当審が付与。)には、

「2. Discussion
2.1. Solutions
We propose three alternatives here for flow control.
2.1.1. Solution 1 (MAC Flow Control)
In this solution, the UE sends a MAC Flow Control PDU to indicate the DL data rate the UE can support (as a fraction of the maximum DL rate indicated in the UE capability).
The triggers for this MAC Control PDU are implementation dependent and not specified in the standard. When the eNB receives this PDU, its’ up to the eNB to reduce the DL traffic.
The advantages of this solution are:
・ We just need to reserve an LCID value, define a new MAC Control Element in the standard (as shown below), and define the SR trigger for such Control Element
・ Since the eNB scheduler needs to decide on a Transport Block size anyway, it’s just one more step to limit the Transport Block size to whatever the UE reported so we don’t see complexity in the eNB


(当審訳:
2. 検討
2.1. 解決策
ここでは、フロー制御のための3つの選択を提案する。
2.1.1. 解決策1(MACフロー制御)
この解決策では、UEは、MACフロー制御PDUを送信して、UEがサポートできる(UE能力における最大DLレートの一部として)DLデータレートを示す。
このMAC制御PDUのトリガーは、実装に依存しており、標準では規定されていない。eNBがこのPDUを受信すると、eNBにおいてDLトラフィックを削減する。
この解決策の利点は次のとおり。
・LCID値を予約し、標準で新しいMAC制御要素を定義し(下記参照)、そのような制御要素のSRトリガーを定義するだけで済む。
・eNBスケジューラはトランスポートブロックサイズを決定する必要があるものの、UEが報告したトランスポートブロックサイズに制限する1ステップだけで、eNBに複雑さはない。

)

「2.2. More Discussion
2.2.1. Need of flow control and Performance Gain
In addition to the need discussed in [1], we want to point out most UE vendors would generally advertise performance up to what the UE can pass with GCF (since this is really the only way of enforcement), and not something lower based on some possible concurrencies.
Since all GCF tests are testing the UL and DL individually without any user applications running concurrently, the UE will be able to pass the test. However, for example, when the UE is doing both UL peak rate and DL peak rate and multiple user applications concurrently, it’s possible (and likely) the UE resource will run low. The result is the UE will drop the DL packets and trigger TCP/IP congestion control, which drastically reduces the throughput. The dropped packets were transmitted over the air and hence wasting radio capacity. Worst, it’s likely the UE in question is receiving and/or transmitting high data rate so it takes up a large portion of the total capacity in a cell. So any dropped packets will translate to large capacity loss in terms of percentage of the max possible capacity.
However, if we have flow control, the eNB could reduce the traffic and the UE could process the packets such that the TCP/IP throughput will reduce gracefully (as opposed to abruptly) and maintaining a reasonable throughput.
One argument against flow control was by the time the eNB receives the flow control PDU, the DL packets would have been discarded by the UE already. To avoid this case, the UE can always trigger and send the flow control PDU a bit before the resources are so low that packets need to be discarded.
2.2.2. UE problems pushed to eNB?
If UE does not have flow control, it’s likely the UE would just discard the DL packets, which will trigger TCP congestion control and choking the throughput and the radio capacity will be wasted. With flow control, the throughput could be reduced gradually so the eNB will not have a big backlog accumulation.
When the UE resources run low, the UE cannot process the DL packets in time so the packets will be dropped. The question is whether we want the packets to be transmitted over the air first and then get dropped at the UE (i.e., without flow control) or we want the packets to be dropped at the eNB instead (i.e., with flow control) and not wasting the radio resources.」
(当審訳:
2.2. さらなる検討
2.2.1. フロー制御とパフォーマンスゲインの必要性
[1]で議論された必要性に加えて、いくつかの可能な事情に基づいた低い状況無しに、ほとんどのUEベンダーが、UEがGCF(これは本当に唯一の施行方法)に合格することができるパフォーマンスを広告することを指摘する。
すべてのGCFテストは、同時に実行されているユーザアプリケーション無しにULとDLを独立してテストしているため、UEはテストに合格することができる。しかし、例えば、UEがULピークレートとDLピークレートと複数のユーザアプリケーションとを同時に実行している場合、実行されるUEリソースは低い可能性がある(そしてその可能性が高い)。その結果、UEはDLパケットを廃棄してTCP/IP輻輳制御をトリガし、スループットを大幅に低下させる。無線で送信されていたパケットを破棄したので、無線容量を無駄にした。最悪なことに、問題のあるUEは、高いデータレートを受信および/または送信している可能性が高いため、セル内の総容量の大部分を占めることになる。したがって、破棄されたパケットは、可能な最大容量の割合という観点として考えると、大きな容量の損失である。
しかし、フロー制御があれば、eNBはトラフィックを減らし、TCP/IPスループットが(突然とは対照的に)優雅に減少して、妥当なスループットを維持するようにUEがパケットを扱うことができる。
フロー制御に対する1つの議論は、eNBがフロー制御PDUを受信するまでに、DLパケットが既にUEによって破棄されていることであった。このような場合を回避するため、UEは、パケットを廃棄する必要があるほどリソースが非常に少なくなる前に、常に、フロー制御PDUをトリガして送信する必要がある。

2.2.2. UEの問題をeNBに押しつけ?
UEがフロー制御を持たない場合、UEは単にDLパケットを破棄し、TCP輻輳制御をトリガし、スループットを詰まらせ、無線容量が無駄になる可能性が高い。フロー制御ではスループットを徐々に下げるので、eNBに大きなバックログ蓄積を持つ必要が無い。
UEリソースが低くなると、UEは、DLパケットを時間的に処理できないので、パケットは廃棄される。この問題は、パケットを最初に無線で送信してUEで廃棄する(すなわち、フロー制御なし)か、代わりに(すなわち、フロー制御を用いて)パケットをeNBで廃棄して無線リソースを無駄にしないかである。)

の記載があるから、

「フロー制御のための3つの選択のうちの1つはMACフロー制御であり、
新しいMAC制御要素を定義し、
UEは、MACフロー制御PDUを送信して、UEがサポートできるDLデータレートを示し、
MAC制御要素は0から1の間のデータレートファクタ値を示しており、
UEがULピークレートとDLピークレートと複数のユーザアプリケーションとを同時に実行している場合、実行されるUEリソースは低い可能性があり、
UEリソースが低くなると、UEは、DLパケットを時間的に処理できないので、パケットは廃棄される代わりに、フロー制御によりパケットをeNBで廃棄して無線リソースを無駄にしない、
UE。」

の発明が記載されている。(以下「引用発明」という。)

3-3.補正後発明と引用発明の対比

引用発明の「UE」と「eNB」は、それぞれ補正後発明の「ユーザ通信装置」と「基地局」に相当する。
引用発明の「DL」はダウンリンクのことであり、引用発明は「DLデータレート」でeNBからパケットを受信しているから、「データレートでダウンリンクを介して基地局からデータを受信」しているといえる。

引用発明の「データレートファクタ値」は、0から1の間の値であるから、補正後発明の「低減されたデータレート」であり、引用発明は、「DLデータレート」に関する「データレートファクタ値」をUEが送信しているから、「ダウンリンクのための低減されたデータレートを前記ユーザ通信装置が決定」しているといえる。

引用発明のMACフロー制御は、UEが「新しいMAC制御要素」が定義された「MACフロー制御PDUを送信」するから、「低減されたデータレートを示すために、無線信号としてのMAC制御要素を前記基地局に送信」しているといえる。

引用発明は、「eNBがこのPDUを受信すると、eNBにおいてDLトラフィックを削減」するから、UEは「低減されたデータレートで前記基地局からデータを受信」しているといえる。


「無線通信システムにおいて動作可能なユーザ通信装置であって、
データレートでダウンリンクを介して基地局からデータを受信し、
前記ダウンリンクのための低減されたデータレートを前記ユーザ通信装置が決定し、
前記低減されたデータレートを示すために、無線信号としてのMAC制御要素を前記基地局に送信し、及び
前記低減されたデータレートで前記基地局からデータを受信する、ユーザ通信装置。」

で一致し、下記の点で相違する。

相違点1

引用発明は、「ユーザ通信装置における混雑を特定」しているかどうか記載されていない点。

相違点2

引用発明は、「低減されたデータレート」が「混雑に基づいて」いるかどうか記載されていない点。

相違点3

引用発明は、MAC制御要素に「前記基地局に送信中の既存のMAC制御要素のセットに対する追加のMAC制御要素」である「フロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールド」を有さない点。

相違点4

引用発明は、ユーザ通信装置に「命令を保持するメモリ」と「命令を実行するプロセッサ」を備えるかどうか記載されていない点。

3-4.相違点の判断

相違点3について

原査定の理由に用いられた特開2006-101477号公報(以下「引用例2」という。)には、

「【0001】
本発明は、無線アドホックネットワークにおける中継ノードへのデータパケット滞留を抑制し、かつ無線アドホックネットワーク内部のエンドツーエンド(End-to-End)のスループットをリンク毎に均一に設定することのできる無線通信装置、無線通信システムおよび無線通信方法に関する。」

「【0014】
すなわち、図1において、各アクセスポイントAP1?AP4はプロトコル上は同一の確率で送信機会を得るものではあるが、途中に配置されるアクセスポイントAP2、AP3は中継ノードとして他のアクセスポイントのデータ中継を行う必要があることから、左右端部のアクセスポイントAP1、AP4と比較して送信すべきデータ量が多くなり、相対的に送信機会が少なくなる。そのため、送信するデータを格納しておく送信バッファ(中継バッファ)が溢れる場合があり、溢れたデータは破棄されるものであることから、その後に再送が必要となり、無線アドホックネットワークシステム全体としてのスループットが低下するという問題があった。」

「【0017】
図6ではアクセスポイントAP1?AP3はアクセスポイントAP4へ、アクセスポイントAP4はアクセスポイントAP5?AP7へデータの送信を行っている場合を示している。アクセスポイントAP4は無線アドホックネットワークにおいて中継ノードとしての役割を有する。前述の非特許文献1にて規定されている無線LAN規格を使用した場合、アクセスポイントAP1?AP4の送信機会は均等となるため、アクセスポイントAP1?AP3からアクセスポイントAP4が受信する合計のデータ量と比べ、アクセスポイントAP4がアクセスポイントAP5?AP7へ送信可能となるデータ量はおよそ3分の1になる。そのため、中継するアクセスポイントAP4の送信バッファへ中継すべきデータパケットが滞留し、バッファ量の限界に達することでバッファ溢れが発生する。
【0018】
図7ではアクセスポイントAP1はアクセスポイントAP2、AP3を介しアクセスポイントAP4にデータパケットの送信を行い、同時にアクセスポイントAP4もアクセスポイントAP3、AP2を介しアクセスポイントAP1にデータ送信を行う場合を示している。このようなネットワーク構成ではデータパケットを送信するアクセスポイント(AP1、AP4)は隣接するアクセスポイント(AP1はAP2へ、AP4はAP3へ)へデータ送信を行うが、中継するアクセスポイント(AP2、AP3)はそれぞれ隣接する2つのアクセスポイント(AP2はAP1、AP3へ、AP3はAP2、AP4へ)へデータを中継送信する必要がある。そのためデータの送信を行うアクセスポイント(AP1、AP4)よりも送信機会を多く取得しないと送信バッファにデータパケットが溜まり、結果としてバッファ溢れが発生する。」

「【0022】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、無線アドホックネットワークシステムにおける中継ノードとなるアクセスポイントのデータパケット滞留によるバッファ溢れを防止し、システム全体のスループットを向上させることのできる無線通信装置、無線通信システムおよび無線通信方法を提供することにある。」

「【0047】
優先制御モジュール2(図8)において送信優先度を考慮したデータ送信を行う際の送信データ量の制御は、IEEE802.11eにて規定されているEDCA(Enhanced Distributed Channel Access)パラメタの変更により実現可能である。EDCAは本来QoSのためのメカニズムであるが、EDCAのメカニズムを使用することで送信トラヒックの制御を行うことができる。
【0048】
図11はEDCAパラメタの説明図であり、EDCAの動作を決定するEDCAパラメタはAIFS(Arbitrary Inter Frame Space)、Backoff、TXOP Limit(Transmission Opportunity Limit)により構成される。AIFSはBackoffまでに待機する一定時間、Backoffはパケット送信までに待機するランダム時間、TXOP Limitは一つのノードが連続してデータパケットの送信を行うことができる一定期間である。」

「【0071】
<第4の実施形態>
次に、図18は本発明の第4の実施形態にかかる無線通信装置の構成図であり、隣接AP情報交換モジュール5により隣接するアクセスポイントに対して送信トラヒック量等の情報をシグナリング等により制御パケットとして送信するとともに、隣接するアクセスポイントから制御パケットを受信し、優先度算出モジュール4により優先度関連パラメタの決定を行うようにしたものである。
【0072】
図19は第4の実施形態におけるフロー制御処理を示すフローチャートであり、大別して以下の3つのフェーズにより構成される。
(1)送信トラフィック量およびバッファ量の観測
(2)シグナリング等による周辺ノードへの通知
(3)送信トラフィック調整
図19において、先ず、データパケットを中継するアクセスポイントは常に送信トラヒック量および送信バッファ中のパケット数を観測する(ステップS401)。なお、観測される送信トラヒック量やバッファ中のパケット数は常に変化するため、常時行われる。次に、データパケットを中継するアクセスポイントは接続している隣接するアクセスポイントへ観測した送信トラヒック量および送信バッファ中のパケット数を制御パケットにより通知する(ステップS402)。
【0073】
隣接するアクセスポイントは、制御パケットを受信すると(ステップS403)、制御パケット中に含まれる中継ノードの送信トラヒック量および送信バッファ中のパケット数に応じ前述したEDCAパラメタを制御することにより送信トラヒック制御を行う(ステップS404)。」

「【0081】
フロー制御に使用可能なフレーム構成例を図25?図28に示す。それぞれはパケットに含まれるエレメント例としており、ユニキャストによる方式およびビーコンによる方式の両方の方式に対し適用可能である。
【0082】
図25はアクセスポイントのデータ送信量を周囲のノードに通達するためのエレメントであり、エレメントID(Element ID)と、ペイロードの長さ(Length)と、データ送信量(Packet transmission rate)とを有している。図26は付加情報としてのノード接続数を周囲のノードに通達するためのエレメントであり、エレメントID(Element ID)と、ペイロードの長さ(Length)と、ノード接続数(Number of associated MP(Mesh Point))とを有している。図27はノードが受信するデータ量をリンク毎に示したものであり、エレメントID(Element ID)と、ペイロードの長さ(Length)と、リンク数分のリンク識別(Associated MP’s MAC Address)および受信データ量(Packet receiving rate)とを有している。図28では各QoSの優先度AC(Access Category)毎の最大送信データレート(Peak Data Rate)を有するエレメントの例である。図28ではさらにフローコントロールリクエストパケットを受信したノードが送信トラヒックを制御すべき時間を示すタイマー(Expiration Timer)を含んでいる。」

の記載があるから、引用例2には、

「送信すべきデータ量が多い中継ノードが送信バッファ溢れを起こさないようにするために、隣接APとトラヒック量等の情報を交換して送信優先度関連のEDCAパラメタの決定を行う場合に、フローコントロールリクエストパケットを受信したノードが送信トラヒックを制御すべき時間を示すタイマーを含むフレームを送信すること」

が記載されている。

つまり、引用例2に記載される「送信トラヒックを制御すべき時間を示すタイマー」は、APが送信機会を増やすために、隣接APに対して要請する「送信禁止時間」であって、「混雑」が発生した場合に、「低減された送信レートの期間」を示すタイマーではない。

また、原査定の理由に用いられた3GPP TSG-RAN WG2 #62 R2-082450(5-9 May,2008),Freescale Semiconductor,"DL Flow Control - initial conditions"(以下「引用例3」という。)には、

「1. Introduction
R2-081062 proposes MAC layer flow control for LTE. We agree that there is a need for DL flow control to prevent buffer overflow in the UE without requiring the UE to be over-dimensioned. We support the proposal [1] to implement flow control at the MAC layer.
In further consideration of the scenarios where flow control is required, we identified a scenario where the proposed MAC flow control mechanism does not fully address the problem.
In this contribution, we discuss the flow startup scenario, and propose a solution based on new capability parameters to establish an initial value for the flow.」
(当審訳:
1. 導入
R2-081062はLTEのためのMACレイヤフロー制御を提案している。我々は、UEに対して過大な要素を要求しないUEでのバッファ溢れを防止するためのDLフロー制御が必要であることに同意する。我々は、提案[1]をサポートし、MACレイヤでのフロー制御を実装する。
フロー制御が必要な状況をさらに考慮して、我々は提案されたMACフロー制御メカニズムが問題を完全に対処しない状況を特定した。
この寄稿では、フロー起動の状況について説明し、フローの初期値を確立する新しい能力パラメータに基づいた解決策を提案する。)

「2.2. Potential Solutions
Building on the MAC layer flow control solution proposed in [1], we propose the addition of a UE capability parameter that defines the percentage of the Maximum number of DL-SCH transport block bits received within a TTI at the start of the downlink flow. The UE could signal the end of the reduced rate using the MAC flow control mechanism.
At RAN2 #61 during the discussion of [1], concerns were expressed that flow control would enable a UE to represent itself as a higher category than it can actually support. To address this concern, and further reduce the need for flow control signalling, we propose an additional UE capability parameter that defines the maximum duration of the initial flow control percentage. This value would be provided by the UE to cover the internal connection latency plus some margin. A maximum allowed value such as 750mS would be specified. The UE could choose to signal to end the flow control signalling using the mechanisms defined in [1], or simply wait for the expiration of the timer that is counting down the initial flow control duration parameter.


(当審訳:
2.2. 可能な解決策
[1]で提案されたMACレイヤフロー制御解決策を基にして、我々は、ダウンリンクフローの開始時にTTI内に受信されたDL-SCHトランスポートブロックビットの最大数の割合を定義するUE能力パラメータの追加を提案する。UEはMACフロー制御メカニズムを用いて低減されたレートの終了を通知することができる。
[1]が議論中のRAN2 #61では、フロー制御はUEが実際にサポートできるよりも高いカテゴリーとしてUE自身を表すことができるという懸念が表明された。この問題に対処し、さらにフロー制御シグナリングの必要性を減らすため、我々は、初期フロー割合の最大持続時間を定義する追加のUE能力パラメータを提案する。この値は、マージンを加算した初期コネクション遅延をカバーするために、UEによって提供される。例えば750mSのような最大許容値が規定される。UEは[1]で定義されたメカニズムを使用したフロー制御シグナリングを終了するように通信するか、単に初期フロー制御持続時間パラメータをカウントダウンするタイマが満了するのを待つかを選択できる。

)

の記載があるから、引用例3には、

「初期フロー割合の最大持続時間を定義するパラメータにより、ダウンリンクフローの開始時の低減されたレートの終了を通知することができる」

ことが記載されている。

つまり、引用例3に記載される「最大持続時間」は、「ダウンリンク開始時」の低減されたレートを終了する時間であって、「混雑が発生した場合」の低減されたレートの期間を示すタイマではない。

したがって、引用例2、3のいずれも、「混雑が発生した場合」に、送信側に対して「低減されたレート」を示す場合のタイマでは無いから、引用発明において引用例2、3を適用したとしても、「フロー制御タイマ値を示すための第1フィールドと前記フロー制御タイマ値の適用を制御するための第2フィールド」を有するようにすることは容易とはいえない。

3-5.まとめ

補正後発明は、少なくとも相違点3について、容易に発明をすることができたとはいえないから、引用例1乃至3により容易に発明をすることができたとはいえない。
また、補正後発明について、その他に独立して特許を受けることができない理由も発見しない。
さらに、本件補正の請求項2-26に記載された発明についても、独立して特許を受けることができない理由を発見しない。

したがって、本件補正は特許法第17条の2第5項第2号を目的とするものに該当する。
また、特許法第17条の2第3項、第4項の規定にも適合する。

したがって、本件補正を認める。


第4 本願発明

本件補正は上記のとおり、特許法第17条の2第3項ないし第5項の規定に適合するから、本願の発明は、本件補正により補正された特許請求の範囲の請求項1-26に記載された事項により特定されるとおりのもの(以下「本願発明」という。)である。


第5 むすび

「3-4.相違点の判断」に記載したように、本願発明は、引用例1乃至3により容易に発明をすることができたとはいえないから、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2016-12-12 
出願番号 特願2014-96154(P2014-96154)
審決分類 P 1 8・ 121- WY (H04W)
最終処分 成立  
前審関与審査官 遠山 敬彦  
特許庁審判長 近藤 聡
特許庁審判官 吉田 隆之
佐藤 智康
発明の名称 モバイルデバイスのためのフロー制御を提供するシステム及び方法  
代理人 福原 淑弘  
代理人 井関 守三  
代理人 蔵田 昌俊  
代理人 奥村 元宏  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ