• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04W
管理番号 1374798
審判番号 不服2020-14307  
総通号数 259 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-07-30 
種別 拒絶査定不服の審決 
審判請求日 2020-10-12 
確定日 2021-06-29 
事件の表示 特願2018-564379「NB-IOTのための無競合ランダムアクセスリソースを提供するための方法」拒絶査定不服審判事件〔平成29年12月14日国際公開,WO2017/212443,令和元年9月5日国内公表,特表2019-525521,請求項の数(26)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1 手続の経緯
本願は,2017年(平成29年)6月8日(パリ条約による優先権主張 外国庁受理 2016年6月8日 アメリカ合衆国(US))を国際出願日とする出願であって,その手続の経緯は以下のとおりである。

令和元年12月 9日付け 拒絶理由通知書
令和2年 3月17日 意見書及び手続補正書の提出
令和2年 6月12日付け 拒絶査定
令和2年10月12日 審判請求書の提出

第2 原査定の概要
原査定(令和2年6月12日付け拒絶査定)の概要は次のとおりである。

(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。


・請求項1,2,5,6,7ないし11,14,15,18,19,20ないし24に対して,引用文献等1及び2
・請求項3,4,12,13,16,17,25,26に対して,引用文献1ないし3

引用文献1.Ericsson,Narrowband IoT - Random Access Design [online],3GPP TSG-RAN WG1#83 R1-157424,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_83/Docs/R1-157424.zip>,2015年11月22日,Section 2, Section 3
引用文献2.Samsung Electronics, Co. Ltd.,Discussion on Random Access Procedure [online],3GPP TSG-RAN WG2#91bis R2-154531,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_91bis/Docs/R2-154531.zip>,2015年10月 9日,Section 2
引用文献3.Ericsson,NB-IoT - Remaining issues for random access procedure [online],3GPP TSG RAN WG1 adhoc_LTE_NB-IoT_1603 R1-161836,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/LTE_NB-IoT_1603/Docs/R1-161836.zip>,2016年 3月24日,Section 2

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

「 【請求項1】
ネットワークノード(115)における方法(800)であって、
複数の開始サブキャリアを含む狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内で、無競合ランダムアクセス手順を実行するための前記複数の開始サブキャリアのサブセット(310、410、520、530、610、720、730)を予約すること(804)と、
1つまたは複数のユーザ機器(UE)(110)に、前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信すること(804)と
を含み、
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む、方法。
【請求項2】
前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の前記開始サブキャリア(315、415、525、535、615、725、735)が、競合ベースのランダムアクセス手順を実行するために利用可能である、請求項1に記載の方法。
【請求項3】
前記情報が無線リソース制御情報要素の一部としてシグナリングされる、請求項1に記載の方法。
【請求項4】
前記NPRACHリソース内の前記複数の開始サブキャリアの各々が、サブキャリアホッピングシーケンスのための第1のサブキャリアである、請求項1に記載の方法。
【請求項5】
第1のUEに、前記無競合ランダムアクセス手順を実行するための前記予約された開始サブキャリアのうちの特定の1つを使用するための命令を通信することを含む、請求項1に記載の方法。
【請求項6】
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、予約された開始サブキャリアの数を含む、請求項1に記載の方法。
【請求項7】
ユーザ機器(UE)(110)における方法(900)であって、
狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているか(310、410、520、530、610、720、730)を示す情報をネットワークノード(115)から受信すること(904)と、
前記受信した情報に基づいてランダムアクセス手順を実行すること(908)と
を含み、
前記無競合ランダムアクセス手順を実行するために予約された前記開始サブキャリアが、前記NPRACHリソース内の前記複数の開始サブキャリアのサブセットを含み、
前記予約されたサブセット内にない1つまたは複数の開始サブキャリア(315、415、525、535、615、725、735)が、競合ベースのランダムアクセス手順を実行するために利用可能であり、
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの数を含む、方法。
【請求項8】
前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの前記数に基づいて、前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを決定することを含む、請求項7に記載の方法。
【請求項9】
前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの中から第1の開始サブキャリアを選択することを含み、
前記受信した情報に基づいて前記ランダムアクセス手順を実行することが、前記選択された第1の開始サブキャリアを使用して競合ベースのランダムアクセス手順を実行することを含む、請求項7に記載の方法。
【請求項10】
前記ネットワークノードから、無競合ランダムアクセス手順を実行するための前記予約された開始サブキャリアのうちの特定の1つを使用するための命令を受信することを含み、
前記受信した情報に基づいて前記ランダムアクセス手順を実行することが、前記予約された開始サブキャリアのうちの前記特定の1つを使用して前記無競合ランダムアクセス手順を実行することを含む、請求項7に記載の方法。
【請求項11】
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、予約された開始サブキャリアの数を含む、請求項7に記載の方法。
【請求項12】
前記情報が無線リソース制御情報要素において受信される、請求項7に記載の方法。
【請求項13】
前記NPRACHリソース内の前記複数の開始サブキャリアの各々が、サブキャリアホッピングシーケンスのための第1のサブキャリアである、請求項7に記載の方法。
【請求項14】
処理回路(1120)を備えるネットワークノード(115)であって、前記処理回路が、
複数の開始サブキャリアを含む狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内で、無競合ランダムアクセス手順を実行するための前記複数の開始サブキャリアのサブセット(310、410、520、530、610、720、730)を予約し(804)、
1つまたは複数のユーザ機器(UE)(110)に、前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信する(804)
ように設定され、
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む、ネットワークノード。
【請求項15】
前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の前記開始サブキャリア(315、415、525、535、615、725、735)が、競合ベースのランダムアクセス手順を実行するために利用可能である、請求項14に記載のネットワークノード。
【請求項16】
前記情報が無線リソース制御情報要素の一部としてシグナリングされる、請求項14に記載のネットワークノード。
【請求項17】
前記NPRACHリソース内の前記複数の開始サブキャリアの各々が、サブキャリアホッピングシーケンスのための第1のサブキャリアである、請求項14に記載のネットワークノード。
【請求項18】
前記処理回路が、第1のUEに、前記無競合ランダムアクセス手順を実行するための前記予約された開始サブキャリアのうちの特定の1つを使用するための命令を通信するように設定される、請求項14に記載のネットワークノード。
【請求項19】
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、予約された開始サブキャリアの数を含む、請求項14に記載のネットワークノード。
【請求項20】
処理回路(1020)を備えるユーザ機器(UE)(110)であって、前記処理回路が、
ネットワークノード(115)から、狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているか(310、410、520、530、610、720、730)を示す情報を受信し(904)、
前記受信した情報に基づいてランダムアクセス手順を実行する(908)
ように設定され、
前記無競合ランダムアクセス手順を実行するために予約された前記開始サブキャリアが、前記NPRACHリソース内の前記複数の開始サブキャリアのサブセットを含み、
前記予約されたサブセット内にない1つまたは複数の開始サブキャリア(315、415、525、535、615、725、735)が、競合ベースのランダムアクセス手順を実行するために利用可能であり、
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの数を含む、UE。
【請求項21】
前記処理回路が、
前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの前記数に基づいて、前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを決定するように設定される、請求項20に記載のUE。
【請求項22】
前記処理回路が、前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの中から第1の開始サブキャリアを選択するように設定され、
前記受信した情報に基づいて前記ランダムアクセス手順を実行するように設定される前記処理回路が、前記選択された第1の開始サブキャリアを使用して競合ベースのランダムアクセス手順を実行するように設定される処理回路を含む、請求項20に記載のUE。
【請求項23】
前記処理回路が、前記ネットワークノードから、無競合ランダムアクセス手順を実行するための前記予約された開始サブキャリアのうちの特定の1つを使用するための命令を受信するように設定され、
前記受信した情報に基づいて前記ランダムアクセス手順を実行するように設定される前記処理回路が、前記予約された開始サブキャリアのうちの前記特定の1つを使用して前記無競合ランダムアクセス手順を実行するように設定される処理回路を含む、請求項20に記載のUE。
【請求項24】
前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、予約された開始サブキャリアの数を含む、請求項20に記載のUE。
【請求項25】
前記情報が無線リソース制御情報要素において受信される、請求項20に記載のUE。
【請求項26】
前記NPRACHリソース内の前記複数の開始サブキャリアの各々が、サブキャリアホッピングシーケンスのための第1のサブキャリアである、請求項20に記載のUE。」

第4 引用文献,引用発明及び技術的事項
1 引用文献1について
原査定の拒絶の理由で引用され、本願優先日前に公開された引用文献1(Ericsson,Narrowband IoT - Random Access Design(当審仮訳:狭帯域IoT-ランダムアクセス設定) [online],3GPP TSG-RAN WG1#83 R1-157424,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_83/Docs/R1-157424.zip>,2015年11月22日)には,図面とともに以下の記載がある。(なお,下線は当審で付与した。)

(1)「At RAN#69, a new work item named NarrowBand IOT (NB-IoT) was approved, see [1].」(第1頁第9行)
(当審仮訳:RAN#69において,狭帯域IoT(NB-IoT)と名付けられた新しい作業項目が承認された。[1]を参照されたい。)

(2)「LTE random access can be either contention-based or contention-free. The contention-based random access procedure consists of four steps, as illustrated in Figure 1. Note that only the first step involves physical-layer processing specifically designed for random access, while the remaining three steps follow the same physical-layer processing used in uplink and downlink data transmission. For contention-free random access, the UE uses reserved preambles assigned by the base station. In this case, contention resolution is not needed, and thus only Steps 1 and 2 are required.」(第1頁下から第6行目ないし第1行目)
(当審仮訳:LTEランダムアクセスは,競合ベース又は競合なしのいずれかとすることができる。競合ベースのランダムアクセス手順は、図1に示されるように4つのステップで構成される。最初のステップのみがランダムアクセス用に特別に設計された物理層処理を含み、残りの3つのステップはアップリンク及びダウンリンクのデータ送信で使用されるものと同じ物理層処理に従うことに留意されたい。競合のないランダムアクセスの場合、UEは基地局によって割り当てられた予約済みプリアンブルを使用する。この場合、競合の解決は不要であるため、手順1と2のみが必要となる。)

(3)「In the SC-FDMA based uplink design for NB-IoT, random access procedure follows its counterpart in LTE. Due to the reduced bandwidth in NB-IoT, minor revisions of LTE physical random access channel (PRACH) design are required in the SC-FDMA based uplink design for NB-IoT. The revision, however, only affects Step 1 (Random Access Preamble), since it is the only step that involves random access specific physical-layer processing.」(第2頁第2行ないし第6行目)
(当審仮訳:NB-IoTのためのSC-FDMAベースのアップリンク設計では,ランダムアクセス手順は,LTEの対応する手順に従う。NB-IoTでは帯域幅が減少しているため,NB-IoTのためのSC-FDMAベースのアップリンク設計では,
LTE物理ランダムアクセスチャネル(PRACH)設計の小規模な改訂が必要とされる。但し,この改訂はステップ1(ランダムアクセスプリアンブル)にのみ影響がある。なぜなら,それがランダムアクセス特有の物理層処理を伴う唯一のステップであるからである。)

(4)「■3.1 Uplink Resource Multiplexing
An example of the multiplexing of PRACH with PUSCH for the SC-FDMA based uplink design in NB-IoT is shown in Figure 2. It can be seen that the multiplexing is similar to LTE. PUSCH could be frequency multiplexed with PRACH in PRACH slots. PRACH time-frequency resources can be configured by the base station. The configuration depends on factors such as random access load, cell size, etc.
・・・(中略)・・・

Figure 2: Multiplexing of Uplink Physical Channels」(第2頁第8行目ないし第19行目)
(当審仮訳:■3.1 アップリンクリソースの多重化
NB-IoTにおけるSC-FDMAベースのアップリンク設計のためのPUSCHでのPRACHの多重化の例が図2に示される。その多重化はLTEに似ていることが見て取れる。PUSCHは,PRACHスロット内のPRACHと周波数多重化されることができる。PRACHの時間周波数リソースは,基地局によって構成されることができる。その構成は,ランダムアクセスの負荷,セルサイズなどの要因に依存する。
・・・(中略)・・・
(図の仮訳は省略)
図2:アップリンク物理チャネルの多重化)

(5)「■3.2.1 Preamble Design
For PRACH Formats 0 and 1, we propose that PRACH uses 80 kHz bandwidth. On the one hand, large subcarrier spacing is desirable to make the preamble transmission robust to carrier frequency offset (CFO) and Doppler shift. On the other hand, longer Zadoff-Chu sequences based preambles are preferred. This is because orthogonal preambles are derived by applying cyclic shifts to a base Zadoff-Chu sequence. In LTE, different cyclic shifts are applied to cells to in different size ranges [5]. For a given cell size (i.e., a given cyclic shift), the longer the preambles, the more the orthogonal preambles. With an 80 kHz bandwidth for PRACH, a tradeoff exists between PRACH subcarrier spacing and preamble length. Further, the choice should enable PRACH to well fit within the overall frame structure in the SC-FDMA based uplink design for NB-IoT.
Taking into account all the constraints, it is proposed to use 312.5 Hz subcarrier spacing. The maximum preamble length is thus 80/0.3125=256. To facilitate preamble sequence selection, prime-length Zadoff-Chu sequences are preferred. Since the largest prime number less than 256 is 251, it is proposed to use length-251 Zadoff-Chu sequences as preambles. The proposed design is shown in Figure 3.



Figure 3: Preamble length and subcarrier spacing for PRACH Formats 0 and 1」(第3頁第4行目ないし第18行目)
(当審仮訳:■3.2.1 プリアンブルデザイン
PRACHフォーマット0及び1の場合、PRACHは80kHzの帯域幅を使用することを提案する。一方では,プリアンブル送信をキャリア周波数オフセット(CFO)及びドップラーシフトに対してロバストにするために,大きなサブキャリア間隔が望ましい。他方では,より長いZadoff-chuシーケンスベースのプリアンブルが好まれる。これは,直交プリアンブルが,ベースのZadoff-chuシーケンスにサイクリックシフトを適用することによって導出されるためである。LTEでは,異なるサイズ範囲内のセルに異なるサイクリックシフトが適用される。[5] 所与のセルサイズ(つまり,所与のサイクリックシフト)では,プリアンブルが長いほど,直交プリアンブルが多くなる。PRACHの帯域幅が80kHzの場合,PRACHのサブキャリ間隔とプリアンブル長の間にはトレードオフが存在する。さらに,この選択により,PRACHがNB-IoTのためのSC-FDMAベースのアップリンク設計のフレーム構造全体にうまく適合させるようになる。
すべての制約を考慮して,312.5kHzのサブキャリア間隔を使用することが提案されている。したがって,最大のプリアンブル長は80/0.3125=256である。プリアンブルシーケンスの選択を容易にするために,素数長のZadoff-Chuシーケンスが好まれる。256未満の最大素数は251であるため,プリアンブルとして,長さ251のZadoff-Chuシーケンスを使用することが提案されている。提案された設計が図3に示される。
(図の仮訳は省略)
図3:PRACHフォーマット0及び1のプリアンブル長とサブキャリア間隔)

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

ア 上記「(2)」の「LTEランダムアクセスは,競合ベース又は競合なしのいずれかとすることができる。・・・(中略)・・・競合のないランダムアクセスの場合、UEは基地局によって割り当てられた予約済みプリアンブルを使用する。」との記載,上記「(3)」の「NB-IoTのためのSC-FDMAベースのアップリンク設計では,ランダムアクセス手順は,LTEの対応する手順に従う。」との記載,及び上記「(1)」の「狭帯域IoT(NB-IoT)」との記載によれば,狭帯域IoT(NB-IoT)のためのランダムアクセス手順は,LTEの対応する手順に従うものであるから,競合ベース又は競合なしのいずれかとすることができ,競合のないランダムアクセスの場合,基地局が割り当てた予約済みプリアンブルをUEに使用させるものといえる。

イ 上記「(4)」の「NB-IoTにおけるSC-FDMAベースのアップリンク設計のためのPUSCHでのPRACHの多重化の例が図2に示される。・・・(中略)・・・PRACHの時間周波数リソースは,基地局によって構成されることができる。」との記載によれば,基地局が,NB-IoTにおけるPRACHの時間周波数リソースを構成するものといえる。

ウ 上記「(4)」の図2から,PRACHの時間周波数リソースは,時間周波数リソース内に存在することを読み取ることができる。そして,当該PRACHのリソースの詳細について,上記「(5)」の図3に示されている。

上記「(5)」の図3からは,PRACHのリソースが180kHzの帯域幅のうち,80kHzの帯域幅を使用し,当該80kHzの帯域幅の中で周波数方向に複数の領域に分かれていること,当該領域はそれぞれ312.5kHzの間隔で並び,80kHzの帯域幅の中には251個存在することを読み取ることができる。ここで,上記「(5)」の「PRACHは80kHzの帯域幅を使用する」との記載,「312.5kHzのサブキャリア間隔を使用する」との記載を考慮すれば,上記図3における312.5kHzの間隔で並ぶ上記領域は,サブキャリアを表しており,また80kHzの帯域幅の中に当該サブキャリアが251個含まれていることは明らかである。してみれば,上記80kHzの帯域幅の中に251個のキャブキャリアが312.5kHzのサブキャリア間隔で含まれるといえる。
そして,上記「(4)」の「PRACHの時間周波数リソース」との記載によれば,上記PRACHのリソースは「時間周波数リソース」である。
以上のことから,PRACHの時間周波数リソースは,180kHzの帯域幅のうち,80kHzの帯域幅を使用し,当該80kHzの帯域幅の中に251個のキャブキャリアが312.5kHzのサブキャリア間隔で含まれるといえる。

エ 上記「ア」で述べたとおり,「基地局が割り当てた予約済みプリアンブルをUEに使用させる」ものであり,「イ」で述べたとおり「基地局がPRACHの時間周波数リソースを構成する」ものであるから,これらの動作は基地局において実施される方法といえる。

したがって,上記「ア」ないし「エ」を総合すると,引用文献1には,次の発明(以下,「引用発明」という。)が記載されていると認められる。

「基地局において実施される方法であって,
狭帯域IoT(NB-IoT)のためのランダムアクセス手順は,競合ベース又は競合なしのいずれかとすることができ,競合のないランダムアクセスの場合,割り当てた予約済みプリアンブルをUEに使用させるものであり,
前記NB-IoTにおけるPRACHの時間周波数リソースを構成し,
前記PRACHの時間周波数リソースは,180kHzの帯域幅のうち,80kHzの帯域幅を使用し,当該80kHzの帯域幅の中に251個のサブキャリアが312.5kHzのサブキャリア間隔で含まれる,方法。」

2 引用文献2について
原査定の拒絶の理由で引用され,本願優先日前に公開された引用文献2(Samsung Electronics, Co. Ltd.,Discussion on Random Access Procedure(当審仮訳:ランダムアクセス手順に関する議論) [online],3GPP TSG-RAN WG2#91bis R2-154531,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_91bis/Docs/R2-154531.zip>,2015年10月 9日)には,図面とともに以下の事項が記載されている。(なお,下線は当審で付与した。)

「2 Random access for NB-IOT
・・・(中略)・・・
The actual value of repetition level would need to be determined based on the worst-case coverage loss in each class (i.e. at the edge of each coverage class range), to ensure that all UEs in one class can make reliable transmission of a particular signal. One implication of this arrangement, though, is that the number of necessary repetitions needed for weak coverage condition is significantly larger than that of better coverage condition. This is illustrated in Table 1 below.


Table 1. PRACH formats and required number of repetitions [3].」(第1頁第17行目ないし第2頁第1行目)
(当審仮訳:2 NB-IoTのためのランダムアクセス
・・・(中略)・・・
繰り返しレベルの実際の値は,1つのクラスのすべてのUEが特定の信号の送信を確実に行えるように、クラスごとで最悪のケース(つまり、カバレッジクラスの範囲ごとエッジ)のカバレッジ損失に基づいて決定される必要がある。但し,この取り決めの1つの意味は,弱いカバレッジ条件に必要な繰り返しの数が、より良いカバレッジ条件のそれよりもかなり多いことである。これを以下の表1に示す。


表1 PRACHフォーマットと要求される繰り返し数)

上記記載によれば,引用文献2には,次の技術的事項が記載されていると認められる。

「NB-IoTのためのランダムアクセスにおいて,64-(N0+N1+N2)個のプリアンブルは競合なしのランダムアクセスのために予約される。」

3 引用文献3について
原査定の拒絶の理由で引用され,本願優先日前に公開された引用文献3(Ericsson,NB-IoT - Remaining issues for random access procedure(当審仮訳:NB-IoT-ランダムアクセス手順の残された問題) [online],3GPP TSG RAN WG1 adhoc_LTE_NB-IoT_1603 R1-161836,インターネット<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/LTE_NB-IoT_1603/Docs/R1-161836.zip>,2016年 3月24日)には,図面とともに以下の事項が記載されている。(なお,下線は当審で付与した。)

「Finally, in LTE and eMTC, if the UE has been requested to perform a contention-free random access, for example if downlink data arrives when the terminal is in RRC_CONNECTED and the uplink is not synchronized, the preamble is explicitly indicated from the eNB. In this case Msg4 is omitted as there is no need for contention resolution.」(第4頁第5行目ないし第8行目)
(当審仮訳:最後に,LTE及びeMTCでは,UEが競合のないランダムアクセスを実行するように要求された場合,例えば,端末がRRC_CONNECTEDにあり,アップリンクが同期されていない時にダウンリンクデータが到着した場合,プリアンブルはeNBから明示的に示される。この場合,競合を解決する必要がないため,Msg4は省略される。)

上記記載に加え,引用文献3が,タイトルに記載されているように「NB-IoT-ランダムアクセス手順の残された問題」について記載したものであることを考慮すれば,引用文献3には,次の技術的事項が記載されていると認められる。

「NB-IoTのランダムアクセスにおいて,UEが競合のないランダムアクセスを実行するように要求された場合,プリアンブルはeNBから明示的に示される。」

第5 対比及び判断
1 対比
本願発明1と引用発明とを対比する。

(1)引用発明における「基地局」は,ネットワークを構成するノードの一種であることが無線通信システムの分野における技術常識であるから,本願発明1の「ネットワークノード」に含まれる。

(2)引用発明の「NB-IoTにおけるPRACHの時間周波数リソース」は,「NB」,すなわち「狭帯域」のものであり,「PRACH」が「Physical Random Access CHannel」の略語であることが技術常識であることを考慮すれば,本願発明1の「狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)」に含まれる。

そして,引用発明は「前記NB-IoTにおけるPRACHの時間周波数リソースを構成」するものであるから,PRACHの時間周波数リソースを有していることは明らかである。これに対して,本願発明1は「複数の開始サブキャリアを含む狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内で、無競合ランダムアクセス手順を実行するための前記複数の開始サブキャリアのサブセット(310、410、520、530、610、720、730)を予約する」ものであるから,予約の前提として「狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)」を有していることは明らかである。
してみれば,本願発明1と引用発明は「狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)」を有する点で共通する。

したがって,上記「(1)」ないし「(2)」を総合すれば,本願発明1と引用発明は,以下の点で一致し,また相違する。

<一致点>
「 ネットワークノード(115)における方法(800)であって、
狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)を有する、方法。」

<相違点1>
本願発明1が「複数の開始サブキャリアを含む狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内で、無競合ランダムアクセス手順を実行するための複数の開始サブキャリアのサブセット(310、410、520、530、610、720、730)を予約すること(804)」を含むものであるのに対して,引用発明は「PRACHの時間周波数リソース」は有するが,当該発明特定事項について特定されていない点。

<相違点2>
本願発明1が「1つまたは複数のユーザ機器(UE)(110)に、NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信すること(804)とを含み」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む」ものであるのに対して,引用発明は,当該発明特定事項について特定されていない点。

2 相違点についての判断
上記相違点について判断するにあたり,事案に鑑みて,上記相違点2について先に検討する。
上記「第4」の「2」で説示したように,引用文献2には「NB-IoTのためのランダムアクセスにおいて,64-(N0+N1+N2)個のプリアンブルは競合なしのランダムアクセスのために予約される。」との技術的事項が記載されている。また,同「3」で説示したように,引用文献3には「NB-IoTのランダムアクセスにおいて,UEが競合のないランダムアクセスを実行するように要求された場合,プリアンブルはeNBから明示的に示される。」との技術的事項が記載されている。
しかしながら,上記相違点2に係る「1つまたは複数のユーザ機器(UE)(110)に、NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信すること(804)とを含み」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む」という発明特定事項は,上記引用文献2及び3のいずれにも記載されておらず,また示唆もされていない。さらに,無線通信システムの分野における周知技術であるともいえない。
よって,引用発明において,上記相違点2に係る「1つまたは複数のユーザ機器(UE)(110)に、NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信すること(804)とを含み」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む」ものとすることは,当業者といえども,容易に想到し得たとはいえない。
したがって,上記相違点1について判断するまでもなく,本願発明1は,当業者であっても,引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。

3 本願発明2ないし6について
本願発明2ないし6は,本願発明1の発明特定事項を全て備えるものであるから,本願発明1と同じ理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。

4 本願発明7ないし13について
本願発明7は,NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信(送信)するネットワークノードの方法発明である本願発明1に対して,当該情報を受信するユーザ機器(UE)の方法発明である。そして,本願発明7は,上記「1」で説示した相違点2に対応する「狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているか(310、410、520、530、610、720、730)を示す情報をネットワークノード(115)から受信することを含み」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの数を含む」という発明特定事項を少なくとも含むものであるから,本願発明1と同様な理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。
また,本願発明8ないし13は,本願発明7の発明特定事項を全て備えるものであるから,本願発明7と同じ理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。

5 本願発明14ないし19について
本願発明14は,ネットワークノードの方法発明である本願発明1を,ネットワークノードの装置発明としたものである。そして,本願発明14は,上記「1」で説示した相違点2に対応する「1つまたは複数のユーザ機器(UE)(110)に、NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信する(804)ように設定され」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む」という発明特定事項を少なくとも含むものであるから,本願発明1と同様な理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。
また,本願発明15ないし19は,本願発明14の発明特定事項を全て備えるものであるから,本願発明14と同じ理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。

6 本願発明20ないし26について
本願発明20は,ユーザ機器(UE)の方法発明である本願発明7を,ユーザ機器(UE)の装置発明としたものである。そして,本願発明20は,上記「1」で説示した相違点2に対応する「ネットワークノード(115)から、狭帯域物理ランダムアクセスチャネル(NPRACH)リソース(305、405、505、605、705)内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているか(310、410、520、530、610、720、730)を示す情報を受信し(904)」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記予約されたサブセット内にない前記1つまたは複数の開始サブキャリアの数を含む」という発明特定事項を少なくとも含むものであるから,本願発明7と同様な理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。
また,本願発明21ないし26は,本願発明20の発明特定事項を全て備えるものであるから,本願発明20と同じ理由により,当業者であっても引用発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものとはいえない。

第6 原査定について
本願発明1ないし26は,いずれも「1つまたは複数のユーザ機器(UE)(110)に、NPRACHリソース内の複数の開始サブキャリアのうちのどれが無競合ランダムアクセス手順を実行するために予約されているかを示す情報を通信すること(804)とを含み、」,「前記NPRACHリソース内の前記複数の開始サブキャリアのうちのどれが前記無競合ランダムアクセス手順を実行するために予約されているかを示す前記情報が、前記無競合ランダムアクセス手順を実行するために予約されていない前記NPRACHリソース内の開始サブキャリアの数を含む」という発明特定事項,もしくはこれに対応する発明特定事項を備えるものである。してみれば,上記「第5」の「1」ないし「5」で説示したとおり,請求項1,2,5,6,7ないし11,14,15,18,19,20ないし24に係る発明は,当業者であっても,拒絶査定で引用された引用文献1に記載された発明及び引用文献2に記載された技術的事項に基いて容易に発明をすることができたものであるとはいえず,また請求項3,4,12,13,16,17,25,26に係る発明は,当業者であっても,引用文献1に記載された発明及び引用文献2,3に記載された技術的事項に基いて容易に発明をすることができたものであるとはいえない。
したがって,原査定の理由を維持することはできない。

第7 むすび
以上のとおり,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2021-06-09 
出願番号 特願2018-564379(P2018-564379)
審決分類 P 1 8・ 121- WY (H04W)
最終処分 成立  
前審関与審査官 大濱 宏之  
特許庁審判長 國分 直樹
特許庁審判官 廣川 浩
本郷 彰
発明の名称 NB-IOTのための無競合ランダムアクセスリソースを提供するための方法  
代理人 園田 吉隆  
代理人 藤井 亮  
代理人 石岡 利康  
代理人 冨樫 義孝  

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