2019-015255

特願２０１５－２３３６７３「無線基地局及び無線通信方法」拒絶査定不服審判事件〔平成２９年　６月　８日出願公開、特開２０１７－１０３５３６〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本願は、平成２７年１１月３０日を出願日とする出願であって、その手続の経緯の概略は以下のとおりである。 平成３１年　４月２４日付け：拒絶理由通知書 令和　元年　７月１６日　　：意見書、手続補正書の提出 令和　元年　８月　５日付け：拒絶査定 令和　元年１１月１３日　　：拒絶査定不服審判の請求 第２　本願発明 令和元年７月１６日にされた手続補正により補正された特許請求の範囲の請求項５に記載された発明（以下、「本願発明」という。）は、以下のとおりのものと認める。 「無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置と無線基地局とのコネクションを確立する無線通信方法であって、 前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を前記無線基地局に送信するステップと、 前記無線基地局が、前記コネクション要求を前記ユーザ装置から受信するステップと、 前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由であっても、前記無線基地局が、前記コネクション要求を拒否せずに正常に処理するステップと を含む無線通信方法。」 第３　原査定の拒絶の理由 原査定の拒絶理由の概要は、「１．（進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」というものであり、請求項５に対し、Vodafone，Handling of Spare Establishment cause values by the Network [online]，3GPP TSG-RAN WG2#73 R2-111697，インターネット、＜URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_73/Docs/R2-111697.zip＞，２０１１年　２月２５日が引用されている。 第４　引用発明 原査定の拒絶の理由に引用されたＶｏｄａｆｏｎｅ，Ｈａｎｄｌｉｎｇ　ｏｆ　Ｓｐａｒｅ　Ｅｓｔａｂｌｉｓｈｍｅｎｔ　ｃａｕｓｅ　ｖａｌｕｅｓ　ｂｙ　ｔｈｅ　Ｎｅｔｗｏｒｋ（[当審仮訳]：ネットワークによる予備の確立理由値の扱い），３ＧＰＰ　ＴＳＧ－ＲＡＮ　ＷＧ２＃７３，Ｒ２－１１１６９７，２０１１年　２月２５日（アップロード），インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ＿ｒａｎ／ＷＧ２＿ＲＬ２／ＴＳＧＲ２＿７３／Ｄｏｃｓ／Ｒ２－１１１６９７．ｚｉｐ＞（以下、「引用例」という。）は、図面とともに以下の事項が記載されている。（下線は、強調のために当審が付与した。） 「Title:　Handling of Spare Establishment cause values by the Network （中略） Reason for change: It is currently not specified how the network should handle the spare establishment cause value and this has been left to implementation. However, based on some precedence of networks not handling spare establishment cause values properly (see GP-021695), there is a risk that a similar situation arises in LTE once we have Release 10 UEs and future release UEs indicating spare values as establishment causes. Hence, this problem should be fixed as soon as possible so that networks do not e.g. reject RRC Connections indicating as spare as establishment cause value. Summary of change: In establishment cause IE field description, indicate that if a ‘spare’ value is received, the network should handle it similarly as if one of the existing establishment cause values was received... （中略） 6.2.1 General message structure --unrelated sections are omitted － RRCConnectionRequest The RRCConnectionRequest message is used to request the establishment of an RRC connection. Signalling radio bearer: SRB0 RLC-SAP: TM Logicalchannel: CCCH Direction: UE to E-UTRAN （中略） establishmentCause Provides the establishment cause for the RRC connection request as provided by the upper layers. W.r.t. the cause value names: highPriorityAccess concerns AC11..AC15, ‘mt’ stands for ‘Mobile Terminating’ and ‘mo’ for ‘Mobile Originating. If a ‘spare’ value is received, the network should handle it similarly as if one of the existing establishment cause values was received.」 （［当審仮訳］： 名称：ネットワークによる予備の確立理由値の扱い （中略） 変更理由： 現在ネットワークがどのように予備の確立理由値を扱うべきかが定められておらず、これは実装に委ねられている。しかし、適切に確立理由値を扱わないいくつかのネットワークの先行を基にすれば（GP-021695参照）、リリース１０のUEや将来のリリースのUEが予備の値を確立理由として示すときはいつでもLTEにおいて同様のシチュエーションが生じる危険性がある。したがって、この問題はネットワークが例えば予備を確立理由値として示すRRC接続を拒絶しないように可及的速やかに解決すべきである。 変更要旨： 確立理由IEフィールド詳細にて、もし‘予備’値が受信されたら、ネットワークは既存の確立理由値の一つを受信したのと同様にそれを扱うべきことを示す。 （中略） ６．２．１　一般メッセージ構造 ――無関係のセクションは省略 ―RRCConnectionRequest RRCConnectionRequestメッセージはRRC接続の確立を要求するために用いる。 シグナリング無線ベアラ：SRB0 RLC-SAP：TM 論理チャネル：CCCH 方向：UEからE-UTRAN （中略） establishmentCause 上位層によって与えられるRRC接続要求のための確立理由を提供する。理由値の名前に関して：高優先アクセスはAC11..AC15に関連し、’mt’は‘モバイル終端’、’mo’は‘モバイル起源’を表す。もし‘予備’値が受信されたら、ネットワークは既存の確立理由値の一つを受信したのと同様にそれを扱うべきである。） 上記の記載、並びに当業者の技術常識を考慮すると、次のことがいえる。 （ア）引用例の「６．２．１　一般メッセージ構造」の「―RRCConnectionRequest」の節に「方向：UEからE-UTRAN」と記載されている。ここで、「方向」とはメッセージが送信される方向のことを示しているのは明らかであるから、当該記載から、UEがRRCConnectionRequestメッセージをE-UTRANに対して送信し、E-UTRANがRRCConnectionRequestメッセージをUEから受信することは明白である。 更に、引用例の「６．２．１　一般メッセージ構造」の「―RRCConnectionRequest」の節の「RRCConnectionRequestフィールド詳細」として、「establishmentCause」と記載されており、「上位層によって与えられるRRC接続要求のための確立理由を提供する。」と記載されている。当該記載から、RRCConnectionRequestメッセージがRRC接続要求のための確立理由を提供するestablishmentCauseを含むことは当業者にとって明らかである。 以上のことから、引用例には「UEがRRC接続要求のための確立理由を提供するestablishmentCauseを含むRRCConnectionRequestメッセージをE-UTRANに対して送信し、E-UTRANがestablishmentCauseを含むRRCConnectionRequestメッセージをUEから受信する」ことが記載されていると認める。 （イ）引用例の「６．２．１　一般メッセージ構造」の「―RRCConnectionRequest」の節の「RRCConnectionRequestフィールド詳細」として、「establishmentCause」について、「もし‘予備’値が受信されたら、ネットワークは既存の確立理由値の一つを受信したのと同様にそれを扱うべきである。」と記載されている。ここで、当該記載中の「‘予備’値」及び「それ」とは、引用例の名称にある「予備の確立理由値」のことであることは明白である。また、引用例の当該記載中の「‘予備’値が受信された」とは、上記（ア）に示した「E-UTRANがestablishmentCauseを含むRRCConnectionRequestメッセージをUEから受信する」ときに、establishmentCauseの値が予備の確立理由値である場合を意味していることは当業者にとって明らかであり、更に当該記載中の「ネットワーク」とは、「E-UTRAN」であることも明らかであるといえる。したがって、引用例の当該記載は、RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が予備の確立理由値である場合、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱うことといえる。 また、引用例の「変更要旨」には、「現在ネットワークがどのように予備の確立理由値を扱うべきかが定められておらず、」及び「この問題はネットワークが例えば予備を確立理由値として示すRRC接続を拒絶しないように可及的速やかに解決すべきである。」と記載されており、当該記載は、現在ネットワークがどのように予備の確立理由値を扱うべきかが定められていないことが問題であり、この問題を解決してネットワークが予備の確立理由値を示すRRC接続を拒絶しないようにすることを意味していることは明らかである。そして前段落にて述べたように「ネットワーク」とは、「E-UTRAN」であることを考慮すれば、引用例の当該記載は、現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値を示すRRC接続を拒絶しないようにすることといえる。 以上のことから、引用例には「RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が予備の確立理由値である場合、現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値を示すRRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う」ことが記載されていると認める。 （ウ）引用例の「６．２．１　一般メッセージ構造」の「―RRCConnectionRequest」の節に「RRCConnectionRequestメッセージはRRC接続の確立を要求するために用いる」と記載されていることから、RRC接続の確立を要求するためのRRCConnectionRequestメッセージに基づきRRC接続を確立することは明らかである。 またRRCとはRadio Resource Control（無線リソース制御）のことであって、無線通信に用いられる通信手順であることは技術常識であり、また上記（ア）に示したRRCConnectionRequestメッセージをUEとE-UTRANとの間で送受信していることを考慮すれば、引用例には「RRC接続の確立を要求するためのRRCConnectionRequestメッセージに基づいて、UEとE-UTRANとのRRC接続を確立する無線通信方法」が記載されていると認める。 以上の上記（ア）ないし（ウ）より、引用例には以下の発明（以下、「引用発明」という。）が記載されていると認める。 「RRC接続の確立を要求するためのRRCConnectionRequestメッセージに基づいて、UEとE-UTRANとのRRC接続を確立する無線通信方法であって、 UEがRRC接続要求のための確立理由を提供するestablishmentCauseを含むRRCConnectionRequestメッセージをE-UTRANに対して送信し、 E-UTRANがestablishmentCauseを含むRRCConnectionRequestメッセージをUEから受信し、 RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が予備の確立理由値である場合、現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値を示すRRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う、 無線通信方法。」 第５　技術常識 本願の最先の優先日以前に利用可能であった規格文書である３ＧＰＰ技術仕様の３ＧＰＰ　ＴＳ　３６．３００　Ｖ１０．１２．０, ２０１５年　１月　５日（アップロード），インターネット＜ＵＲＬ：ｈｔｔｐｓ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／Ｓｐｅｃｓ／ａｒｃｈｉｖｅ／３６＿ｓｅｒｉｅｓ／３６．３００／３６．３００－ａｃ０．ｚｉｐ＞には，以下の事項が記載されている。 「4.3.2 Control plane The figure below shows the protocol stack for the control-plane, where: - PDCP sublayer (terminated in eNB on the network side) performs the functions listed for the control plane in subclause 6, e.g. ciphering and integrity protection; - RLC and MAC sublayers (terminated in eNB on the network side) perform the same functions as for the user plane; - RRC(terminated in eNB on the network side) performs the functions listed insubclause 7, e.g.: - Broadcast; - Paging; - RRC connection management; - RB control; - Mobility functions; - UE measurement reporting and control. - NAS control protocol (terminated in MME on the network side) performs among other things: - EPS bearer management; - Authentication; - ECM-IDLE mobility handling; - Paging origination in ECM-IDLE; - Security control. NOTE:the NAS control protocol is not covered by the scope of this TS and is only mentioned for information. Figure 4.3.2-1: Control-plane protocol stack」（２２ページ） （［当審仮訳］： ４．３．２　制御プレーン 以下の図は制御プレーンのためのプロトコルスタックを示す： －　PDCPサブレイヤー（ネットワーク側ではeNBにて終端される）は第６節の制御プレーンとして列挙されている機能を実行する。例えば暗号化及び完全性保護； －　RLC及びMACサブレイヤー（ネットワーク側ではeNBにて終端される）はユーザプレーンとして同様の機能を実行する； －　RRC（ネットワーク側ではeNBにて終端される）は第７節に列挙されている機能を実行する，例えば： －　ブロードキャスト； －　ページング； －　RRC接続マネージメント； －　RB制御； －　移動性機能； －　UE測定報告及び制御。 －　NAS制御プロトコル（ネットワーク側ではMMEにて終端される）は他のことを実行する： －　EPSベアラ管理； －　認証； －　ECM-IDLE移動性の取り扱い； －　ECM-IDLEのページング方向； －　セキュリティ制御。 注意：NAS制御プロトコルはこのTSの範囲によりカバーされておらず、情報のためとして言及されているだけである。 （図について略） 図４．３．２．１：制御プレーンプロトコルスタック） 規格文書に記載された事項は当業者における技術常識であるから、「RRCはRRC接続マネージメント機能を実行し、ネットワーク側ではeNBにて終端される。」ことは当業者にとって技術常識である。 第６　対比 本願発明と引用発明とを対比すると、 （ア）引用発明の「RRC接続の確立を要求するためのRRCConnectionRequestメッセージ」とは、RRC（無線リソース制御）における接続の要求であることから、本願発明の「無線リソース制御レイヤにおけるコネクション要求」に相当する。また、引用発明の「UE」は、本願発明の「ユーザ装置」に相当する。 そして、本願発明の、無線リソース制御レイヤにおけるコネクション要求に基づいて、ユーザ装置と無線基地局とのコネクションを確立する無線通信方法と、引用発明の、RRC接続の確立を要求するためのRRCConnectionRequestメッセージに基づいて、UEとE-UTRANとのRRC接続を確立する無線通信方法とは、無線リソース制御レイヤにおけるコネクション要求に基づいて、コネクションを確立する無線通信方法との点の限りにおいて一致する。 （イ）引用発明の「establishmentCause」はRRC接続の確立理由を提供するものであることから、本願発明の「コネクションの確立理由」に対応する。 そして、本願発明の「前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を前記無線基地局に送信するステップと、前記無線基地局が、前記コネクション要求を前記ユーザ装置から受信するステップ」との構成と、引用発明の「UEがRRC接続要求のための確立理由を提供するestablishmentCauseを含むRRCConnectionRequestメッセージをE-UTRANに対して送信し、E-UTRANがestablishmentCauseを含むRRCConnectionRequestメッセージをUEから受信し、」との構成とは、ユーザ装置がコネクションの確立要求を含むコネクション要求を送信し、前記コネクション要求をユーザ装置から受信するとの点の限りにおいて一致する。 （ウ）引用発明の「RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が予備の確立理由値である場合、現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値を示すRRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う」ことは、RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が 現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値である場合、RRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱うことといえる。そして、引用発明の「予備の確立理由値」は、現在E-UTRANがどのように扱うべきか定められていないことから、本願発明の「未サポート確立理由」に対応し、引用発明のRRCConnectionRequestメッセージに含まれるestablishmentCauseの値が 現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値である場合は、本願発明の「前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由であっても」に対応する。 また、引用発明の「既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う」との構成は、既存の確立理由値と同様に扱うことから、正常に処理するものといえる。したがって、引用発明の「RRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う」との構成は、RRC接続を拒絶しないように正常に処理することから、本願発明の「コネクション要求を拒否せずに正常に処理する」との構成に対応する。 したがって、本願発明の「前記コネクション要求に含まれる前記確立理由が、前記無線基地局においてサポートしていない未サポート確立理由であっても、前記無線基地局が、前記コネクション要求を拒否せずに正常に処理するステップ」との構成と、引用発明の「RRCConnectionRequestメッセージに含まれるestablishmentCauseの値が予備の確立理由値である場合、現在E-UTRANがどのように扱うべきかが定められていない予備の確立理由値を示すRRC接続を拒絶しないように、E-UTRANは既存の確立理由値の一つを受信したのと同様に予備の確立理由値を扱う」との構成とは、コネクション要求に含まれる確立理由が、未サポート確立理由であっても、コネクション要求を拒否せずに正常に処理するとの点の限りにおいて一致する。 以上を総合すると、本願発明と引用発明とは、以下の点で一致し、また相違する。 （一致点） 「無線リソース制御レイヤにおけるコネクション要求に基づいて、コネクションを確立する無線通信方法であって、 前記ユーザ装置が、前記コネクションの確立理由を含む前記コネクション要求を送信し、 前記コネクション要求を前記ユーザ装置から受信し、 前記コネクション要求に含まれる確立理由が、未サポート確立理由であっても、前記コネクション要求を拒否せずに正常に処理する、 を含む無線通信方法。」 （相違点） 本願発明は、ユーザ装置と無線基地局とのコネクションを確立する無線通信方法であるのに対し、引用発明は、UEとE-UTRANとのRRC接続を確立する無線通信方法であり、E-UTRANが無線基地局であるとは特定されておらず、したがって「前記コネクション要求を前記ユーザ装置から受信し、前記コネクション要求に含まれる確立理由が、未サポート確立理由であっても、前記コネクション要求を拒否せずに正常に処理する」主体が基地局であることが特定されていない点。 第７　判断 以下相違点について検討する。 「第５　技術常識」で示したとおり、「RRCはRRC接続マネージメント機能を実行し、ネットワーク側ではeNBにて終端される。」ことは技術常識である。 したがって引用発明において、RRCがRRC接続マネージメント機能を実行し、eNBにて終端されるとの上記技術常識を考慮すると、E-UTRAN内の無線基地局に相当するeNBがRRCを終端しRRC接続マネージメント機能を実行するために、eNBが現在どのように扱うか定められていない予備の確立理由値を含むRRC接続の確立を要求するためのメッセージを受信してRRC接続の要求を拒絶しないように処理し、UEとeNBとのRRC接続を確立することは当業者にとって自明である。 よって、本願発明は当業者が引用例に記載された発明に基づいて容易に発明をすることができたものである。 第８　むすび 以上のとおり、本願発明は当業者が引用例に記載された発明に基づいて容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。