• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04W
審判 査定不服 特29条の2 取り消して特許、登録 H04W
審判 査定不服 1項3号刊行物記載 取り消して特許、登録 H04W
管理番号 1369607
審判番号 不服2020-7493  
総通号数 254 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-02-26 
種別 拒絶査定不服の審決 
審判請求日 2020-06-02 
確定日 2021-01-05 
事件の表示 特願2018-238777「基地局」拒絶査定不服審判事件〔平成31年 4月25日出願公開、特開2019- 68459、請求項の数(3)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成26年12月25日に出願した特願2014-263394号の一部を平成30年12月20日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。

令和1年10月28日付け :拒絶理由通知書
令和1年12月10日 :意見書、手続補正書の提出
令和2年 2月28日付け :拒絶査定
令和2年 6月 2日 :拒絶査定不服審判の請求、手続補正書の提出

第2 原査定の概要
原査定(令和2年2月28日付け拒絶査定)の概要は次のとおりである。
理由1(新規性):請求項1に係る発明は、引用例1に記載された発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。
理由2(進歩性):請求項1ないし3に係る発明は、引用例1に記載された発明に基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
理由3(拡大先願):請求項1ないし3に係る発明は、その出願の日前の日本語特許出願であって、その出願後に国際公開がされた日本語特許出願(先願2)の国際出願日における国際出願の明細書、請求の範囲又は図面に記載された発明と同一であり、しかも、この出願の発明者がその出願前の日本語特許出願に係る上記の発明をした者と同一ではなく、またこの出願の時において、その出願人が上記日本語特許出願の出願人と同一でもないので、特許法第29条の2の規定により、特許を受けることができない(同法第184条の13参照)。

引用文献等一覧
引用例1.NEC Corporation,Services between PDCP and RLC for a split bearer[online],3GPP TSG-RAN WG2♯85bis R2-141282,インターネット＜URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_85bis/Docs/R2-141282.zip＞,2014年 4月 4日
先願2.特願2016-557442号(国際公開第2016/072039号)


第3 本願発明
本願請求項1ないし3に係る発明(以下、それぞれ「本願発明1」ないし「本願発明3」という。)は、令和2年6月2日にされた手続補正により補正された特許請求の範囲の請求項1ないし3に記載された事項により特定される発明であり、以下のとおりの発明である。

「 【請求項1】
デュアルコネクティビティにおけるセカンダリ基地局として動作する基地局であって、
マスタ基地局と連係したユーザ装置とのデュアルコネクティビティ通信を制御する制御部と、
前記マスタ基地局から転送されるデータを受信する管理部と、
を有し、
前記管理部は、破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄し、
前記制御部は、前記ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示すフィードバック情報を前記マスタ基地局に送信する、基地局。
【請求項2】
当該基地局に転送されたデータのうち、当該基地局から破棄されるべきデータの量を前記マスタ基地局から通知されると、前記管理部は、前記通知されたデータの量に基づき前記転送されたデータからデータを破棄する、請求項1記載の基地局。
【請求項3】
当該基地局に転送されたデータのうち、当該基地局から破棄されるべきデータのデータ識別子を前記マスタ基地局から通知されると、前記管理部は、前記通知されたデータ識別子に対応するデータを破棄する、請求項1記載の基地局。」

第4 引用文献、引用発明、先願発明等
1.引用例1について
原査定の拒絶の理由に引用された、NEC Cｏｒｐｏｒaｔiｏn,“Seｒｖiceｓ beｔｗeen PDCP and RLC fｏｒ a ｓｐliｔ beaｒeｒ”([当審仮訳]:スプリットベアラ用のPDCPとRLC間のサービス),3GPP TSG-RAN WG2♯85biｓ R2-141282,2014年3月21日(アップロード),インターネット＜URL:hｔｔｐｓ://ｗｗｗ.3gｐｐ.ｏｒg/fｔｐ/ｔｓg_ｒan/WG2_RL2/TSGR2_85biｓ/Dｏcｓ/R2-141282.ｚiｐ＞(以下、「引用例1」という。)には、以下の事項が記載されている。

「1.Introduction
There are internal services between PDCP and RLC layer, we will discuss these services but in the context of dual connectivity architecture 3C where the PDCP and RLC layer are not collocated anymore for a split bearer. It will be discussed whether and how to realize them over X2. This is also related to flow control and buffer management in PDCP layer of MeNB and RLC layer of SeNB.

2.Discussion
For a split bearer, PDCP will locate in MeNB, one RLC will locate in SeNB. As shown in following figure, the interaction between PDCP in MeNB and RLC in SeNB will go through X2 and suffer the delay on the non-ideal backhaul.


2.1 Successful delivery indication from RLC to PDCP
(中略)
In the context of dual connectivity, the same function shall be kept as the starting point. As shown in following figure [3], only difference is there are two RLC branches, both MeNB RLC and SeNB RLC will send indication of successful delivery to PDCP layer, and PDCP layer shall take into account these two branches together.
(中略)
This successful delivery could be used as flow control. Since all packets, which have been sent to SeNB, but have not been positive acknowledged will be buffered in SeNB either in the transmission or re-transmission buffer, the successful delivery indication implicitly indicates the packets still in the RLC buffer, based on this, MeNB PDCP determines whether and how many more packets could be sent to SeNB, i.e. more packets could be sent to SeNB if more successful delivery acknowledge from SeNB are received. This can be an alternative of the flow control for RAN3 to discuss.
Proposal 1: Introduce a Successful Delivery Indication Control Element over X2 from SeNB RLC to MeNB PDCP.
(中略)
2.2 Timer based Discard
In TS36.322 section 5.3:

5.3 SDU discard procedures
When indicated from upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity shall discard the indicated RLC SDU if no segment of the RLC SDU has been mapped to a RLC data PDU yet.

At reception of a PDCP SDU from upper layers, the discardTimer will start and be associated with the PDCP SDU (if configured), once the discard timer expires, there is no sense to send the packet anymore if it has not been sent yet. Since the PDCP may buffer the packet for an uncertain time e.g. based on flow control, and then route to SeNB RLC, the whole discard time will be consumed partly by MeNB PDCP and partly by SeNB RLC, there are two possible ways to do timer based discard:

・Alt. 1: Timers is only maintained in PDCP, and discard indication will be sent to SeNB when the timer is expired.
・Alt. 2: Timer is started at MeNB PDCP, and will be forwarded together with the packet to SeNB.

With Alt.1, the MeNB shall indicate the discard in advance by taking into account the delay on X2. Ideally, MeNB only indicate the discard if the PDCP PDU packets are still in the transmission buffer, otherwise, in the end, there is useless discard indication.(後略)
」(1葉8行目?17行目、2葉8行目?11行目、2葉15行目?23行目、3葉1行目?17行目)

([当審仮訳]:
1.序章
PDCP層とRLC層の間に内部サービスがある。これらのサービスについて、スプリットベアラのためにPDCP層とRLC層が同じ場所に配置されていないデュアルコネクティビティアーキテクチャ3Cのコンテキストで説明する。X2を介してそれらを実現するかどうか、またどのように実現するかについて説明する。これは、MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理にも関連する。

2.議論
スプリットベアラの場合、PDCPはMeNBに配置され、1つのRLCはSeNBに配置される。次の図に示すように、MeNBのPDCPとSeNBのRLCの間の相互作用はX2を経由し、非理想的なバックホールで遅延が発生する。

(図1略)
2.1 RLCからPDCPへの配信成功表示
(中略)
デュアルコネクティビティのコンテキストでは、同じ機能を開始点として維持する必要がある。 次の図[3]に示すように、2つのRLCブランチがあるという違いのみがあり、MeNB RLCとSeNB RLCの両方がPDCPレイヤーに配信成功の表示を送信し、PDCPレイヤーはこれら2つのブランチを一緒に考慮しなければならない。
(中略)
この配信成功表示は、フロー制御の時に使用することができる。SeNBに送信されたが、肯定的に確認されなかったすべてのパケットは、送信バッファまたは再送信バッファのいずれかでSeNB内にバッファリングされるので、配信成功表示は、RLCバッファ内のパケットがまだあることを暗黙的に示している。これに基づいてMeNB PDCPは、SeNBにさらにパケットを送信することができるかどうか、どのくらいの数のパケットを送信することができるかを決定する。すなわち、SeNBからより多くの成功した配信を受信した場合、より多くのパケットがSeNBに送信される可能性がある。これは、RAN3が議論すべきフロー制御のオプションである。
提案1:SeNB RLCからMeNB PDCPへのX2を介した配信成功表示制御要素の導入。
(中略)
2.2 タイマーベースの廃棄
TS36.322の5.3節中:
5.3 SDU廃棄手続き
上位レイヤ(すなわち PDCP)から特定の RLC SDUを破棄するように指示された場合、AM RLCエンティティの送信側またはUM RLCエンティティの送信側は、RLC SDUのセグメントがまだRLCデータPDUにマッピングされていない場合には、指示されたRLC SDUを破棄しなければならない。

上位層からのPDCP SDUの受信時に、diｓcaｒdTimeｒが起動し、PDCP SDU(構成されている場合)に関連付けら、破棄タイマーが期限切れになると、まだ送信されていないパケットを送信する意味はない。PDCPはパケットをバッファリングする時間が定まっておらず、例えば、フロー制御に基づいて、SeNB RLCにルーティングされるため、破棄時間全体は、一部はMeNB PDCPによって、一部はSeNB RLCによって消費される。タイマーベースの破棄を行う方法は2つある。

Alｔ1:タイマーはPDCPでのみ維持され、タイマーの期限が切れると破棄指示がSeNBに送信される。
Alｔ2:タイマーはMeNB PDCPで開始され、パケットと共にSeNBに転送される。

Alｔ.1では、MeNBはX2の遅延を考慮に入れて、事前に破棄を示すべきである。理想的には、MeNBは、PDCP PDUパケットがまだ送信バッファにある場合にのみ破棄を示し、そうでない場合、最終的には無駄な破棄の表示となる。
(後略))

引用例1の上記記載、図面及びこの分野における技術常識を考慮すると、次のことがいえる。

ア 上記「1.序章」には、「PDCP層とRLC層の間に内部サービスがある。これらのサービスについて、スプリットベアラのためにPDCP層とRLC層が同じ場所に配置されていないデュアルコネクティビティアーキテクチャ3Cのコンテキストで説明する。X2を介してそれらを実現するかどうか、またどのように実現するかについて説明する。これは、MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理にも関連する。」との記載がある。また、上記「2.議論」には、「スプリットベアラの場合、PDCPはMeNBに配置され、1つのRLCはSeNBに配置される。」、「配信成功表示は、フロー制御の時に使用することができる。SeNBに送信されたが、肯定的に確認されなかったすべてのパケットは、送信バッファまたは再送信バッファのいずれかでSeNB内にバッファリングされるので、配信成功表示は、RLCバッファ内のパケットがまだあることを暗黙的に示している。これに基づいてMeNB PDCPは、SeNBにさらにパケットを送信することができるかどうか、どのくらいの数のパケットを送信することができるかを決定する。」、「MeNB RLCとSeNB RLCの両方がPDCPレイヤーに配信成功の表示を送信し」、「SeNB RLCからMeNB PDCPへのX2を介した配信成功表示制御要素の導入。」と記載がある。
そして、上記摘記のとおり、「SeNB」は「デュアルコネクティビティ」の(スプリットベアラの)アーキテクチャで「MeNB」とともに用いられる「SeNB」であって、SeNBが備えるSeNB RLCがMeNB PDCPとX2(Xn)で接続されるものであるから、「SeNB」は「デュアルコネクティビティアーキテクチャにおいて、MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理に関連する」ものである。
そうすると、引用例1には「デュアルコネクティビティアーキテクチャにおいて、MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理に関連する」、「配信成功表示は、フロー制御の時に使用できるものであり、SeNB RLCからMeNB PDCPへのX2を介した配信成功表示を送信する」ものが記載されている。

イ 上記「2.議論」には「MeNB PDCPは、SeNBにさらにパケットを送信する」ことが記載されており、MeNB PDCPが送信したパケットは、SeNBが受信することは明らかであるから、引用例1には、SeNBが「MeNB PDCPからパケットを受信する」ことが記載されているものといえる。

ウ 上記「2.2 タイマーベースの破棄」には、「上位レイヤ(すなわち PDCP)から特定のRLC SDUを破棄するように指示された場合、・・・指示されたRLC SDUを破棄しなければならない。」、「タイマーはPDCPでのみ維持され、タイマーの期限が切れると破棄指示がSeNBに送信される。」との記載がある。また、上記「2.議論」に記載されるように「PDCPはMeNBに配置され」るものである。
そうすると、引用例には「MeNB PDCPから特定のRLC SDUを破棄するように指示された場合、指示されたRLC SDUを破棄するものであり、破棄指示がSeNBに受信される」ものが記載されている。

エ そして、上記「ア」?「ウ」によれば、「SeNB RLCからMeNB PDCPへのX2を介した配信成功表示を送信する」ものであり、「・・・破棄指示がSeNBに受信される」ものであるから、これらの動作は、「SeNB」によるものであるといえる。

以上を総合すると、上記引用例1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。

「 SeNBであって、
デュアルコネクティビティアーキテクチャにおいて、MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理に関連するものであり、
MeNB PDCPからパケットを受信し、
配信成功表示は、前記フロー制御の時に使用できるものであり、SeNB RLCからMeNB PDCPへのX2を介して配信成功表示を送信するものであって、
前記MeNB PDCPから特定のRLC SDUを破棄するように指示された場合、指示されたRLC SDUを破棄するものであり、破棄指示がSeNBに受信される、
SeNB。」

2.先願2の国際出願日における国際出願の明細書、請求の範囲又は図面について
原査定の拒絶の理由に引用された上記先願2(特願2016-557442号)の国際出願日における国際出願の明細書、請求の範囲又は図面(以下、「先願2の明細書等」という。)には、次の事項が記載されている。

「[0014]以下に、本発明を実施するための形態について図面を参照して説明する。
(1)第1の実施形態
(1-1)第1の実施形態の概要
本実施形態は、無線通信システムの全体構成自体は図1と同様であるが、MeNB20およびSeNB30に新たな機能を追加している。
そこで、以下、MeNB20およびSeNB30の構成について詳細に説明する。
SeNB30は、第1の基地局である。
MeNB20は、第2の基地局であり、Dｕal Cｏnnecｔiｖiｔｙを設定し、CNから受信した下りデータを、MeNB20(MeNB20のセル)とSeNB30とを経由してUE10に送信可能である。
図5に、本実施形態におけるMeNB20の構成の一例を示す。
図5に示すように、本実施形態におけるMeNB20は、通信部21を有している。
通信部21は、SeNB30に対し、SeNB30に送信した下りデータのうち廃棄(diｓcaｒd)する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を送信する。なお、後述するように、下りデータを廃棄する指示として、新たに情報要素(後述の例では、図8に示す情報要素であるDiｓcaｒd)を設けても良い。また、MeNB20からSeMB30に送信する情報自体が、下りデータを廃棄する指示であっても良い。
なお、MeNB20は、通信部21による通信処理以外の処理を行う制御部を有しているが、この制御部は図5からは省略されている。
図6に、本実施形態におけるSeNB30の構成の一例を示す。
図6に示すように、本実施形態におけるSeNB30は、通信部31および制御部32を有している。
通信部31は、MeNB20から、MeNB20がSeNB30に送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信する。
制御部32は、通信部31による通信処理以外の処理を行う部分である。
例えば、制御部32は、MeNB20からの上記情報により特定された下りデータのうち、UE10には未送信で送信バッファ内に残っている下りデータを廃棄する。
また、通信部31は、制御部32が廃棄した下りデータを識別する情報をMeNB20に送信する。なお、通信部31がMeNB20に送信する、制御部32が廃棄した下りデータを識別する情報とは、制御部32が廃棄した下りデータを個々に示す情報であっても良いし、廃棄した下りデータを個々に示さず、通信部31がMeNB20から受信した情報に記載された廃棄すべき下りデータを全て廃棄した旨を示す情報であっても良い。
上述したように本実施形態においては、MeNB20は、SeNB30に対し、SeNB30に送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を送信する。これを受けて、SeNB30は、上記の情報により特定される下りデータのうちUE10に未送信の下りデータを廃棄する。
したがって、SeNB30は、廃棄する下りデータを特定し廃棄することができるため、下りデータの廃棄を実現することができるという効果が得られる。
[0015](1-2)第1の実施形態の詳細
(1-2-1)廃棄指示を送信するケース
MeNB20がSeNB30へ下りデータの廃棄指示を送信するのは、例えば、以下のケースである。
・MeNB20がSeNB30に送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeを一定時間が経過しても受信していない場合
・MeNB20に内部エラーが発生した場合
・MeNB20がSeNB30にPDCP PDUを送信した直後、又は、PDCP PDUを送信してから第一の期間以内に、CNのMME40からE-RAB(EUTRAN-Radiｏ Acceｓｓ Beaｒeｒ)解放指示を受信した場合
・MeNB20がSeNB30にPDCP PDUを送信した直後、又は、PDCP PDUを送信してから第二の期間以内に、MeNB20とCNのMME40やS-GW50との間に何かのエラー(リンクエラー、MeNB20がMME40からReｓeｔを受信するというエラー)が発生した場合
なお、第一の期間及び第二の期間は、タイマーを用いて測定される期間であっても良い。
[0016](1-2-2)廃棄指示の内容
MeNB20がSeNB30へ送信する、下りデータの廃棄指示の内容としては、例えば、以下の(A)?(D)の4通りがある。
(A)すべてのPDCP PDUの廃棄指示
MeNB20は、SeNB30に対し、SeNB30に既に送信したPDCP PDUのすべてを廃棄することを指示することができる。
例えば、MeNB20が、SeNB30に対し、PDCP PDU#3、PDCP PDU#4、PDCP PDU#5を既に送信していたとする。
この状況で、その後にMeNB20は、SeNB30に対し、PDCPPDUをSeｑｕence Nｕmbeｒ(シーケンス番号)等で指定せず、1ビットの廃棄指示だけを送信する。
すると、SeNB30は、PDCP PDU#3、PDCP PDU#4、PDCP PDU#5のうち送信バッファ内に残るPDCP PDUのすべてを廃棄する。
SeNB30は、廃棄したPDCP PDUのSeｑｕence NｕmbeｒをMeNB20に返信する。
これにより、MeNB20は、SeNB30が廃棄したPDCP PDUのSeｑｕence Nｕmbeｒを知ることができる。そのため、MeNB20は、SeNB30が廃棄したPDCP PDUを、若番のPDCP PDUから順番に、自セルからUE10に再送することができる。
上記の例であれば、例えば、SeNB30がMeNB20から廃棄指示を受信した時に既にPDCP PDU#3をUE10に送信し、PDCP PDU#4、PDCP PDU#5がまだ送信バッファ内に残っていたとする。この場合、SeNB30は、PDCP PDU#4とPDCP PDU#5を廃棄し、廃棄したPDCP PDU#4とPDCP PDU#5のSeｑｕence NｕmbeｒをMeNB20に返信する。
なお、MeNB20による上記の廃棄指示は、E-RABを個別指定して、E-RABごとに行う。
[0017](B)Seｑｕence Nｕmbeｒを用いる廃棄指示
MeNB20は、SeNB30に対し、あるSeｑｕence NｕmbeｒのPDCP PDUを廃棄することを指示することができる。
例えば、MeNB20が、SeNB30に対し、既にPDCP PDU#3、PDCP PDU#4、PDCP PDU#5を既に送信していたとする。また、MeNB20が、SeNB30からPDCP PDU#3、PDCP PDU#5のAcknｏｗledgeを受信したが、PDCP PDU#4のAcknｏｗledgeは受信していなかったとする。
この状況で、その後にMeNB20は、SeNB30に対し、PDCP PDU#4のSeｑｕence Nｕmbeｒを指定した上で、廃棄指示を送信する。
すると、SeNB30は、指定されたPDCP PDU#4が送信バッファ内に残っていれば、PDCP PDU#4を廃棄する。
SeNB30は、廃棄したPDCPPDU#4のSeｑｕence NｕmbeｒをMeNB20に返信する。
これにより、MeNB20は、SeNB30がPDCP PDU#4を廃棄したことを知ることができるため、自セルからUE10にPDCP PDU#4を再送することができる。
なお、MeNB20による上記の廃棄指示は、E-RABを個別指定して、E-RABごとに行う。
また、MeNB20による上記の廃棄指示においては、個々のSeｑｕence Nｕmbeｒを指定してもよいし、Seｑｕence Nｕmbeｒの範囲(開始番号と終了番号)を指定してもよいし、あるSeｑｕence Nｕmbeｒ(開始番号)を指定することによりそれ以降のすべてのSeｑｕence Nｕmbeｒを指定してもよい。なお、Seｑｕence Nｕmbeｒの範囲は、上述の通り開始番号と終了番号により特定しても良いし、開始番号と該開始番号から廃棄すべきPDCP PDUの数(Range)により特定しても良い。開始番号と該開始番号から廃棄すべきPDCP PDUの数とは、例えば、開始番号がPDCP PDU#3を示す情報で、該開始番号から廃棄すべきPDCP PDUの数が10を示す情報である。この場合、PDCP PDU#3から数えて10個目のPDCP PDUまでを廃棄する。
また、個別のSeｑｕence Nｕmbeｒを指定する情報と、Seｑｕence Nｕmbeｒの範囲を指定する情報を1つのフォーマットに組み合わせても良い。」

先願2の明細書等の上記記載及びこの分野における技術常識を考慮すると、次のことがいえる。

ア 上記段落[0014]には、「MeNB20は、第2の基地局であり、Dｕal Cｏnnecｔiｖiｔｙを設定し、CNから受信した下りデータを、MeNB20(MeNB20のセル)とSeNB30とを経由してUE10に送信可能である。」、「SeNB30は、通信部31および制御部32を有している。通信部31は、MeNB20から、MeNB20がSeNB30に送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信する。」、「制御部32は、MeNB20からの上記情報により特定された下りデータのうち、UE10には未送信で送信バッファ内に残っている下りデータを廃棄する。」との記載がある。
ここで、「SeNB30を経由してUE10に送信」される「下りデータ」は「MeNB20がSeNB30に送信した」ものであるから、先願2の明細書等には、SeNBの動作として「Dｕal Cｏnnecｔiｖiｔｙを設定され、MeNBが送信した下りデータを受信し、UEに送信する」ものが記載されている。また、先願2の明細書等には、「SeNBは、MeNBから、MeNBがSeNBに送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信し、UEには未送信で送信バッファ内に残っている下りデータを廃棄する」ものが記載されている。

イ 上記段落[0015]には、廃棄指示が送信される条件として「MeNB20がSeNB30に送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeを一定時間が経過しても受信していない場合」を含むこと、上記段落[0017]には、「MeNB20が、SeNB30からPDCP PDU#3、PDCP PDU#5のAcknｏｗledgeを受信」すること、が記載されているから、通常の動作では「MeNB20がSeNB30に送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeを一定時間内に受信する」ものといえる。
ここで、「Acknｏｗledge」は「MeNB20がSeNB30に送信したPDCP PDU(下りデータ)に対する」ものであって「MeNB20が・・・受信する」ものであるから、SeNBの動作としては、「MeNBがSeNBに送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeを送信する」ものが記載されているといえる。

以上を総合すると、上記先願2の明細書等には、次の発明(以下、「先願発明」という。)が記載されていると認められる。

「 SeNBであって、
Dｕal Cｏnnecｔiｖiｔｙを設定され、
MeNBが送信した下りデータを受信し、UEに送信するものであり、
MeNBから、MeNBがSeNBに送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信し、UEには未送信で送信バッファ内に残っている下りデータを廃棄するものであり、
MeNBがSeNBに送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeをMeNBに送信する、
SeNB。」

第5 対比・判断
1.本願発明1について
(1)特許法第29条第1項第3号について
本願発明1と引用発明とを対比すると、以下のことがいえる。

ア 引用発明の「SeNB」は、「デュアルコネクティビティアーキテクチャ」においてSeNBとして動作するものであり、SeNBはセカンダリ基地局であることは当該技術分野において技術常識である。
そうすると、引用発明の「SeNB」は、本願発明1と「デュアルコネクティビティにおけるセカンダリ基地局として動作する基地局」である点で一致する。

イ 引用発明の「SeNB」は「MeNBのPDCPレイヤー及びSeNBのRLCレイヤーでのフロー制御とバッファ管理に関連する」ものであるから、引用発明の「SeNB」は、MeNB、つまりマスタ基地局と連携したユーザ装置とデュアルコネクティビティ通信を行うものであることは自明である。また、引用発明の「SeNB」は「MeNB PDCPからパケットを受信」するものであり、当該受信するパケットは、デュアルコネクティビティ通信においては、ユーザ装置に転送するために転送されるデータであることは自明である。そして、前記通信を行うための制御を行う制御部、前記転送されるデータを受信する管理部に相当する部位をそれぞれ有しているものといえる。
そうすると、本願発明1と引用発明は「マスタ基地局と連係したユーザ装置とのデュアルコネクティビティ通信を制御する制御部と、前記マスタ基地局から転送されるデータを受信する管理部と、」を有する点で一致する。

ウ 引用発明の「SeNB」において、「成功配信表示」は、デュアルコネクティビティ通信を行う場合に「SeNB RLCからMeNB PDCPへのX2を介して送信されるもの」であるから、当該「配信成功表示」は、SeNBが、マスタ基地局であるMeNBの「MeNB PDCPからパケットを受信」し、SeNBからユーザ装置へのデータ転送が成功したことを表す表示であることは自明である。してみれば、当該「配信成功表示」は、ユーザ装置からの肯定的応答を示すフィードバック情報であるといえる。そして、上記「イ」で述べたとおり、通信を行うための制御は制御部で行うものであり、配信成功表示も送信されるものであるから、送信される対象である配信成功表示の送信及びその他のデータ受信は、少なくとも通信行うための制御を行う制御部において行われているといえる。
そうすると、本願発明1と引用発明は「制御部は、前記ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信し、これに関するフィードバック情報を前記マスタ基地局に送信する」点で共通する。

エ 引用発明の「破棄指示」は、PDCPから指示されSeNBに受信されるものであり、PDCPレイヤーはMeNBに存在するものである。そして、特定のRLC SDU、すなわちSeNBにMeNB PDCPから転送されたパケット、すなわちデータは、MeNBからの破棄指示に基づいて破棄されるものといえるから、引用発明の「破棄指示」は、本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報」に相当し、引用発明の「破棄指示」が「SeNBに受信される」ことは、本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報がマスタ基地局から通知される」ことに相当する。また、データの破棄は、上記「破棄指示」以外の条件で行われるものではないから、「破棄指示のみ」に基づいて行われるものといえる。してみれば、引用発明は、受信された破棄指示のみに基づいて、指示されたRLC SDU、すなわちデータを破棄するものといえる。
そうすると、本願発明1と引用発明は、「破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄」する点で共通する。

以上を総合すると、本願発明1と引用発明とは、以下の点で一致し、また、相違している。

(一致点)
「デュアルコネクティビティにおけるセカンダリ基地局として動作する基地局であって、
マスタ基地局と連係したユーザ装置とのデュアルコネクティビティ通信を制御する制御部と、
前記マスタ基地局から転送されるデータを受信する管理部と、
破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄し、
前記制御部は、前記ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信し、これに関するフィードバック情報を前記マスタ基地局に送信する、基地局。」

(相違点1)
本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄」する部位が管理部と特定されているのに対し、引用発明では、「前記MeNB PDCPから特定のRLC SDUを破棄するように指示された場合、指示されたRLC SDUを破棄するものであり、破棄指示がSeNBに受信される、」際に用いられる部位が特定されていない点。

(相違点2)
本願発明1の「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」のに対し、引用発明の「配信成功表示」はそれ自体であって、そのような発明特定事項を有していない点。

そうすると、本願発明1と引用発明は、上記相違点1及び相違点2で相違するから、本願発明1は引用発明であるとはいえない。

(2)特許法第29条第2項について
ア.対比
本願発明1と引用発明との一致点及び相違点は、上記「(1)」で説示したとおりである。

イ.相違点についての判断
事案に鑑み、まず、上記相違点2について検討する。
相違点2に係る本願発明1の「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」という発明特定事項は、引用例1には記載も示唆もされておらず、当該技術分野において周知技術であるともいえない。
よって、当業者といえども、引用発明において、上記相違点2に係る「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」ものとすることは、容易に想到し得たとはいえない。
したがって、上記相違点1について判断するまでもなく、本願発明1は、当業者であっても、引用発明に基いて容易に発明をすることができたものであるとはいえない。

(3)特許法第29条の2について
ア.対比
本願発明1と先願発明とを対比すると、以下のことがいえる。

(ア)先願発明の「SeNB」は、「Dｕal Cｏnnecｔiｖiｔｙ」が設定され、SeNBとして動作するものであり、SeNBがセカンダリ基地局であることは当該技術分野において技術常識である。そして、先願発明の「SeNB」は、Dｕal Cｏnnecｔiｖiｔｙ下において「MeNBが送信した下りデータを受信し、UEに送信するもの」であるから、先願発明の「SeNB」は、MeNB(マスタ基地局)と連携したUEとデュアルコネクティビティ通信を行うものであることは自明であり、当該通信を行うための制御を行う制御部、MeNBが送信した下りデータを受信する管理部に相当する部位をそれぞれ有しているものといえる。
そうすると、先願発明の「SeNB」と本願発明1は「デュアルコネクティビティにおけるセカンダリ基地局として動作する基地局」であって、「マスタ基地局と連係したユーザ装置とのデュアルコネクティビティ通信を制御する制御部と、前記マスタ基地局から転送されるデータを受信する管理部」を有するものである点で一致する。

(イ)先願発明の「MeNBがSeNBに送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示」は、本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報」に相当するから、「MeNBから、MeNBがSeNBに送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信」することは、本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知される」ことに相当する。また、先願発明の上記「指示を受信し、UEには未送信で送信バッファ内に残っている下りデータを廃棄する」ことは、上記指示のみに基づいて行われることは明らかである、本願発明1の「前記通知のみに基づいて、前記データを破棄」することに相当する。
そうすると、本願発明1と先願発明は「破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄」する点で共通する。

(ウ)先願発明の「SeNB」は「MeNBがSeNBに送信したPDCP PDU(下りデータ)に対するAcknｏｗledgeをMeNBに送信する」ものであり、下りデータに対するAcknｏｗledgeは、UEからの肯定的応答に他ならないから、本願発明1の「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信」し、これに関する「フィードバック情報をマスタ基地局に送信する」点で共通する。
そうすると、本願発明1と先願発明は「前記ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答に関するフィードバック情報を前記マスタ基地局に送信する」点で共通する。

以上を総合すると、本願発明1と先願発明とは、以下の点で一致し、また、相違している。

(一致点)
「デュアルコネクティビティにおけるセカンダリ基地局として動作する基地局であって、
マスタ基地局と連係したユーザ装置とのデュアルコネクティビティ通信を制御する制御部と、
前記マスタ基地局から転送されるデータを受信する管理部と、
破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄し、
前記ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信し、これに関するフィードバック情報を前記マスタ基地局に送信する、基地局。」

(相違点1)
本願発明1の「破棄されるべき当該基地局に転送されたデータを示す情報が前記マスタ基地局から通知されると、前記通知のみに基づいて、前記データを破棄」する処理の部位が「管理部」であるとの特定がされているのに対し、先願発明では、「MeNBから、MeNBがSeNBに送信した下りデータのうち廃棄する下りデータを特定する情報とともに、その情報により特定される下りデータを廃棄する指示を受信し、UEには未送信で送信バッファ内に残っている下りデータを廃棄する」際に用いられる部位が特定されていない点。

(相違点2)
本願発明1の「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」ものであり、該フィードバック情報を送信する部位が「制御部」であるとの特定がされているのに対し、先願発明は「Acknｏｗledge」が「肯定的応答」自体であって、肯定的応答を受信したデータ量を少なくとも示すものではなく、該フィードバック情報を送信する部位が特定されていない点。

イ.相違点についての判断
事案に鑑み、まず、上記相違点2について検討する。
上記相違点2に係る本願発明1の「フィードバック情報」が、「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」という発明特定事項は、先願2の明細書等の記載を参酌しても、その課題解決のための具体化手段における微差(周知技術、慣用技術の付加、削除、転換等であって、新たな効果を奏するものでないもの)であるともいえない。
よって、先願発明において、上記相違点2に係る「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」ものであることは、課題解決のための具体化手段における微差であるとはいえない。そして,そのようなフィードバック情報を送信する「制御部」を引用発明が有するものともいえない。
したがって、上記相違点1について判断するまでもなく、本願発明1は、先願発明と同一であるとはとはいえない。

2.本願発明2及び3について
本願発明2及び3は、本願発明1の発明特定事項を全て含むから、本願発明1と同じ理由により、引用発明であるとはいえず、また当業者であっても、引用発明に基いて容易に発明をすることができたものであるとはいえない。
さらに、本願発明2及び3は、本願発明1の発明特定事項を全て含むから、本願発明1と同じ理由により、先願発明と同一もしくは実質同一であるとはとはいえない。

第6 原査定について
1.理由1(特許法第29条第1項第3号)について
審判請求時補正により、本願発明1ないし3は「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」という発明特定事項を有するものとなっているから、上記第5の1.(1)で説示したとおり、拒絶査定において引用された引用例1に記載された発明であるとはいえない。したがって、原査定の理由1を維持することはできない。

2.理由2(特許法第29条第2項)について
審判請求時補正により、本願発明1ないし3は「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」という発明特定事項を有するものとなっているから、上記第5の1.(2)及び2.で説示したとおり、当業者であっても、拒絶査定において引用された引用例1に基いて、容易に発明をすることができたものとはいえない。したがって、原査定の理由2を維持することはできない。

3.理由3(特許法第29条の2)について
審判請求時補正により、本願発明1ないし3は「フィードバック情報」が「ユーザ装置に送信したデータに対して前記ユーザ装置から肯定的応答を受信したデータ量を少なくとも示す」という発明特定事項を有するものとなっているから、上記第5の1.(3)及び2.で説示したとおり、拒絶査定において引用された先願2の明細書等に記載された発明と同一もしくは実質同一であるとはとはいえない。したがって、原査定の理由3を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2020-12-15 
出願番号 特願2018-238777(P2018-238777)
審決分類 P 1 8・ 113- WY (H04W)
P 1 8・ 121- WY (H04W)
P 1 8・ 16- WY (H04W)
最終処分 成立  
前審関与審査官 三枝 保裕  
特許庁審判長 廣川 浩
特許庁審判官 望月 章俊
本郷 彰
発明の名称 基地局  
代理人 石原 隆治  
代理人 伊東 忠彦  
代理人 伊東 忠重  

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