【事件の表示】
　特願２０１５−　９２５００「通信制御方法、ユーザ端末、プロセッサ、及び基地局」拒絶査定不服審判事件〔平成２７年　８月１３日出願公開、特開２０１５−１４６６４５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯と本願発明
　本件出願は，２０１３年５月９日（パリ条約による優先権主張２０１２年５月１１日，米国）を国際出願日とする特願２０１４−５１４７５０号の一部を平成２７年４月３０日に新たな特許出願としたものであって，平成２７年５月２７日付け拒絶理由通知に対して同年８月３日に意見書及び手続補正書が提出されたが同年８月１７日付けで拒絶査定がなされ，これを不服として同年１１月２４日付けで審判請求がなされるとともに手続補正書が提出されたものであって，その請求項１に係る発明（以下，「本願発明」という。）は，平成２７年１１月２４日に提出された手続補正書の特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「ネットワークとのＲＲＣ接続確立手順の失敗に関する接続確立失敗ログを記憶できるユーザ端末を含む移動通信システムに適用される通信制御方法であって，
　前記ユーザ端末が，該ユーザ端末の移動速度の情報を含む前記接続確立失敗ログを記憶するステップを有することを特徴とする通信制御方法。」
　
２　引用発明
（１）引用発明１
　原査定の拒絶の理由に引用されたEricsson, ST-Ericsson，Accessibility measurements for MDT，3GPP TSG-RAN WG2 #77bis，3GPP，２０１２年３月３０日，Tdoc R2-121605には，「Accessibility measurements for MDT（当審仮訳：ＭＤＴのためのアクセス性測定）」に関し，以下の事項が記載されている。
　
ア　「1 Introduction
　・・・（中略）・・・
One outcome of the e-mail discussion seems to be that accessibility measurements should be included in MDT. This document aims at discussing some of the outstanding issues and applies for both LTE and UMTS, although most of the discussions and details are taken from (based on) LTE. The document assumes that it has been decided to measure accessibility. Both RACH and RRC connection request/setup message measurements will be discussed. 
（当審仮訳：
１　イントロダクション
　・・・（中略）・・・
Ｅメール議論の１つの結果は，アクセス性測定はＭＤＴに含まれるべきだということのようだ。本稿はいくつかの未解決の問題について議論することを目的とし，ＬＴＥとＵＭＴＳの両方に適用できるものであるが，ほとんどの議論と詳細はＬＴＥから（に基づいて）取られている。本稿はアクセス性を測定することが既に決定されたと仮定している。ＲＡＣＨとＲＲＣ接続要求／設定メッセージの両方の測定が議論される。）」（第１節）
　
イ「2 Measurements and reporting
2.1 Discussion
Support of logging unsuccessful Pre-amble transmissions and failures in RRC connection establishment after pre-amble has been a success are both needed in order to determine UL/DL accessibility on random access procedure and CCCH.
・・・（中略）・・・
The RRC connection request will trigger the RACH procedure (pre-amble transmission). If the RACH procedure would not be successful the RRC Connection Request message will not be sent. On the other hand, if the Random access procedure is successful then the RRC connection request message will sent to the NW; and as a response typically RRC connection Setup message is received, and UE enters RRC_CONNECTED. The T300 is started when the transmission of the RRC connection request message is initiated and stopped when RRC connection setup message is successfully received. 
（当審仮訳：
２　測定と報告
２．１　議論
不成功なプリアンブル送信と，プリアンブル送信が成功した後のＲＲＣ接続確立の失敗をロギングすることのサポートは，ランダムアクセス手順とＣＣＣＨ上のＵＬ／ＤＬアクセス性を決定するために両方とも必要とされる。
・・・（中略）・・・
ＲＲＣ接続要求はＲＡＣＨ手順（プリアンブル送信）をトリガする。ＲＡＣＨ手順が成功しなければＲＲＣ接続要求メッセージは送信されない。他方，ランダムアクセス手順が成功すればＲＲＣ接続要求メッセージはＮＷに送信される；そして，応答として典型的にはＲＲＣ接続設定メッセージが受信され，ＵＥはＲＲＣ　ＣＯＮＮＥＣＴＥＤに入る。Ｔ３００が，ＲＲＣ接続要求メッセージの送信が開始された時にスタートし，ＲＲＣ接続設定メッセージが成功裏に受信された時にストップする。）」（第２．１節）
　
ウ「2.2 Pre-amble transmissions (RACH procedure)
When the trigger to stop the transmissions occurs or if aborted before an unsuccessful event has occurred.
The content to be logged is proposed to be: 
- Number of preambles sent (defined also in Rel-9 RACH report)
- Contention detected (defined also in Rel-9 RACH report)
- Max Tx Pwr used (indicates that the UE has hit maximum power level)
- Cause value: T300 timeout or other event (such as higher layer intervention, aborting the establishment)
- Radio environment
- Location
- Cell-id
　
Proposal 1 In case of an unsuccessful Pre-amble transmission (RACH procedure) the UE shall log the parameters (Number of preambles sent, Contention detected, Max Tx Pwr used, Cause value, Radio environment, Location, Cell-id)
（当審仮訳：
２．２　プリアンブル送信（ＲＡＣＨ手順）
送信をストップするトリガが発生したとき，あるいは，不成功なイベントが発生する前に中止された場合。
ログされるべき内容として提案されるのは：
−送信されたプリアンブルの数（Ｒｅｌ−９　ＲＡＣＨレポートでも定義されている）
−検出された競合（Ｒｅｌ−９　ＲＡＣＨレポートでも定義されている）
−使用された最大送信電力（ＵＥが最大電力レベルに達したことを示す）
−要因値：Ｔ３００タイムアウトあるいは他のイベント（上位レイヤの介入，確立の中止など）
−無線環境
−ロケーション
−セルＩＤ
　
提案１：プリアンブル送信（ＲＡＣＨ手順）が不成功の場合，ＵＥはパラメータ（送信されたプリアンブルの数，検出された競合，使用された最大送信電力，要因値，無線環境，ロケーション，セルＩＤ）をログする。）」（第２．２節）
　
エ「2.3 RRC connection request/RRC connection setup messages sent on CCCH
If the RACH procedure is successful and no RRC connection setup message is received in UE before T300 expiry or a higher level intervention has occurred during this time the UE log this event. The network can then be able to correlate this event to other and understand if it was the RRC connection request message or the DL setup message that failed (and hence discover if it was the UL or DL that failed). The content to be logged is proposed to be:
- Cause value: T300 timeout or higher layer intervention (abortion of procedure)
- Radio environment
- Location
- Cell-id
　
Proposal 2 In case of unsuccessful reception of RRC Connection Setup message the UE shall log the parameters (cause value, Radio environment, Location, Cell-id)
（当審仮訳：
２．３　ＣＣＣＨ上で送信されるＲＲＣ接続要求／ＲＲＣ接続設定メッセージ
もしもＲＡＣＨ手順が成功しても，Ｔ３００が満了する前にＲＲＣ接続設定メッセージが受信されないか，あるいは，この間に上位レイヤの介入があれば，ＵＥはこのイベントをログする。そうすれば，ネットワークは，このイベントと他を関連付けることができ，失敗したのがＲＲＣ接続要求メッセージであるのかＤＬの確立メッセージであるのかを知ることができる（そして，それゆえ失敗したのがＵＬなのかＤＬなのかを発見できる）。ログされるべき内容として提案されるのは：
−要因値：Ｔ３００タイムアウトあるいは上位レイヤの介入（手順の中止）
−無線環境
−ロケーション
−セルＩＤ
　
提案２：ＲＲＣ接続確立メッセージの受信が不成功の場合，ＵＥはパラメータ（要因値，無線環境，ロケーション，セルＩＤ）をログする。）」（第２．３節）
　
オ「2.4 Measurement reporting
The logs stored need to be reported at the next connection is established. The logging and reporting the events can be done similar to RLF reporting; alternatively the log is included within the MDT logged reporting procedure. The proposal is to have a simple approach that do not need configuration over the radio interface and let the UE log and indicate to NW it has data available with a new indicator bit and the NW may then request the data if needed (in the same way as RLF reporting and logged measurement reporting etc.)
　
Proposal 3 A UE that supports accessibility measurements always measure accessibility events and indicates logged data available to NW at next connection establishment(s)
（当審仮訳：
２．４　測定報告
記憶されたログは次回の接続が確立されたときに報告される必要がある。イベントのログと報告はＲＬＦと同様に行われる；もしくはそのログは，ログされたＭＤＴの報告手続きに含められる。提案するのは簡単なアプローチであって，無線インターフェース上のコンフィギュレーションを必要とせず，ＵＥにログさせ，新たなインジケータビットでデータを持っていることをＮＷに対して示させ，その後ＮＷはもし必要ならそのデータを要求できるようにする（ＲＬＦ報告とログされた測定報告等と同様に）ものである。
　
提案３：アクセス性測定をサポートするＵＥは，常にアクセス性イベントを測定し，また，次回の接続確立時にログされたデータをＮＷに提供できることをインジケートする。）」（第２．４節）
　
　上記引用例１の記載及びこの分野における技術常識を考慮すると，以下の技術事項が読み取れる。
　
ａ　ＵＥは，ＲＡＣＨ手順やＲＲＣ接続（要求／設定）メッセージ送受信に失敗した場合に，２．２節や２．３節に記載された各種情報をログとして記憶するが，これらは，「ＲＲＣ接続確立手順の失敗に関する接続確立失敗ログ」といい得るものである。
ｂ　上記「ＲＲＣ接続確立手順」がＵＥとＮＷとの間で行われる手順であること，および，ＵＥとＮＷとが「移動通信システム」を構成することは技術常識である。
ｃ　上記「接続確立失敗ログ」の記憶はＲＲＣ接続確立手順時に行われるものであるから，「移動通信システムに適用される通信制御方法」の１ステップであるといえる。
　
　以上を総合すると，上記引用例１には，以下の発明（以下，「引用発明１」という。）が開示されていると認める。
　
「ＮＷとのＲＲＣ接続確立手順の失敗に関する接続確立失敗ログを記憶するＵＥを含む移動通信システムに適用される通信制御方法であって，
　前記ＵＥが，前記接続確立失敗ログを記憶するステップを有する通信制御方法。」
　
（２）引用発明２
　同じく原査定の拒絶の理由に引用された特開２００９−１６４８８２号公報（以下，「引用例２」という。）には「移動端末及び移動体通信管理システム」（発明の名称）に関し，図面とともに以下の事項が記載されている。
　
カ「【００１５】
  （全体構成）
図２に本実施形態の全体構成図を示す。移動端末１は車両などの移動体に搭載あるいは歩行者に携帯される端末である。基地局（アクセスポイント）３５はＩＥＥＥ８０２規格に基づく無線通信の基地局である。移動端末１は基地局（アクセスポイント）３５との無線通信が可能であり，該基地局を介してインターネットなどの通信回線３３を経由して管理端末３との接続が可能である。」
　
キ「【００１９】
  移動端末１は，ログ送信部１１により接続成否ログ１３に記憶したログを管理端末３に対して送信する。ログ送信部１１は接続成否ログ１３にログが蓄積されており，かつ，アクセスポイント３５経由での管理端末３との通信が可能であることを検知した場合に，ログの送信を開始する。」
　
ク「【００２８】
  （接続成否記録部）
接続成否記録部９は，自動接続処理部７のステップ３処理においてアクセスポイント３５との接続処理に失敗した場合には，図４の処理フローの各ステップ（以下，単にＳで示す）にしたがってログの記録を行う。」
　
ケ「【００３２】
  （ログ形式）
図５に接続成否記録部９がＳ６７において記録するログの形式を示す。データラベル欄９１には取得するログの概要，データの内容欄９３には各データラベル９１に対応するデータの具体的な内容を示している。以下，ログの内容を説明する。
【００３３】
  「エラーが発生した接続処理内容」欄には，移動端末１が実行する一連の接続処理のうち，どのフェイズで接続エラーが発生したかを記録する。接続処理の例として（１）アクセスポイントへの接続処理，（２）ＩＰアドレスの取得処理，（３）ＲＡＤＩＵＳサーバ等の認証サーバへの接続・認証処理がある。これらの接続処理のうちどの処理の段階（フェイズ）でエラーが発生したかを記録する（ログをとる）ことで，管理端末３のオペレータは接続処理の不具合発生箇所を特定することが可能となる。例えば，オペレータは，多数の移動端末１からの特定のアクセスポイント３５への接続処理におけるエラーログの集積を把握した場合には，その特定のアクセスポイント３５の設置環境／運用環境又はアクセスポイント３５自体に不具合があることを予測できる。また，オペレータは，多数の移動端末１からの認証サーバでの認証処理エラーログを把握した場合には，認証サーバやセンタ設備の不具合を予測できる。このようにして，不具合箇所の特定を早めることが可能である。
【００３４】
  「走行環境（速度／進行方向／天気）」欄には，車両速度，車両進行方向，天気などの車両の走行環境を記録する（ここでは移動体として車両を前提として説明する）。オペレータは，「エラーが発生した接続処理内容」と共にこれら情報を参照することで，接続処理時のエラーが特殊な条件下に車両があったために発生したのか，あるいは，アクセスポイント３５の設定／運用状況が不適切であったために発生したのかを判断可能である。
【００３５】
  オペレータは「走行環境」情報により接続処理時のエラーが，移動端末１が特殊な環境にあったために発生したと判断できれば，アクセスポイント３５その他の設備の設定／運用の調整は不要と判断できる。通信性能に影響を与える走行環境として，例えば，車両が高速で走行中，アクセスポイント３５がカバーする通信可能エリアを非常に短い時間内に車両が通過してしまう場合がある。この場合，オペレータは接続処理エラー発生時の車両走行速度をログから参照して車両速度が高速であった場合には，通信処理の完了を待たずに車両が通過したためにエラーとなった可能性があると判断できる。移動端末１は，移動端末１に接続されたＣＡＮ（Controller Area Network）などの車載ネットワークから車速パルス情報を取得，あるいはＧＰＳ装置６０によって車両速度を検知する。」
　
コ「【００４６】
  接続失敗件数は積上棒グラフ１０１で表示し，グラフに積上げたそれぞれの項目について表示枠１０７に説明される。図６の１０３は棒グラフ所在地点で稼動するアクセスポイント３５における接続失敗件数を棒グラフ表示したものである。棒グラフ表示は，各件のエラー内容毎に積上表示を行う。接続成否統計表示部２５はエラー内容によってフィルタすることにより棒グラフの積上表示の形態を変更することが可能である。図６の１０５は接続失敗の総件数より，雨天走行時／高速走行時等の電波環境が悪化する特殊な条件でのエラーを排除して表示した例である。オペレータは図６の１０５を参照することで，特殊な走行条件下では無い場合のエラー件数を把握することが可能であり，これにより当該アクセスポイント３５の設定／運用の要否を判断可能である。」
　
　上記引用例２の記載及びこの分野における技術常識を考慮すると，以下の技術事項が読み取れる。
　
ａ　移動端末がアクセスポイントとの接続処理に失敗した場合にログの記録を行うが，このログは「接続処理失敗ログ」ということができる。
ｂ　ログの情報は「車両速度」を含むが，これは，移動端末のＧＰＳ装置によって検知されたものである。
ｃ　ログの記録は移動端末がネットワーク（アクセスポイント）との接続処理時に行われるものであるから，「通信制御方法」の１手順であるといえる。
　
　以上を総合すると，上記引用例２には，以下の発明（以下，「引用発明２」という。）が開示されていると認める。
　
　「ネットワークとの接続処理失敗ログの一部として移動端末のＧＰＳ装置によって検知した車両速度を記録するようにした通信制御方法。」
　
３　対比
　本願発明と引用発明１とを対比するに，引用発明１の「ＮＷ」，「ＵＥ」はそれぞれ本願発明の「ネットワーク」，「ユーザ端末」に相当し，両者は以下の点で一致ないし相違している。
　
（一致点）
「ネットワークとのＲＲＣ接続確立手順の失敗に関する接続確立失敗ログを記憶できるユーザ端末を含む移動通信システムに適用される通信制御方法であって，
　前記ユーザ端末が，前記接続確立失敗ログを記憶するステップを有する通信制御方法。」
　
（相違点）
　「接続確立失敗ログ」が，本願発明では「該ユーザ端末の移動速度の情報を含む」のに対し，引用発明１ではそのような情報を含まない点。
　
４　検討
　上記相違点につき検討する。
　
　引用例１の文献タイトル「ＭＤＴのためのアクセス性測定」における「ＭＤＴ」が「Minimization of Drive Test（ドライブテストの縮小化）」の略であり，上記「ＭＤＴのためのアクセス性測定」が移動通信システムのネットワーク最適化を目的とするドライブテスト（DT）の代替的手段として行われることは技術常識であるところ，引用発明１の「接続確立失敗ログ」に記憶される情報がネットワーク最適化のために用いられる情報であることは明らかである。
　ここで，引用発明１と同様に「接続処理失敗ログ」を記憶する発明として，引用例２には「２　引用発明」の項中の「（２）引用発明２」に記したとおりの「ネットワークとの接続処理失敗ログの一部として移動端末のＧＰＳ装置によって検知した車両速度を記録するようにした通信制御方法。」が記載されているが，引用例２の「例えば，オペレータは，多数の移動端末１からの特定のアクセスポイント３５への接続処理におけるエラーログの集積を把握した場合には，その特定のアクセスポイント３５の設置環境／運用環境又はアクセスポイント３５自体に不具合があることを予測できる。」（摘記事項ケの【００３２】），「図６の１０５は接続失敗の総件数より，雨天走行時／高速走行時等の電波環境が悪化する特殊な条件でのエラーを排除して表示した例である。オペレータは図６の１０５を参照することで，特殊な走行条件下では無い場合のエラー件数を把握することが可能であり，これにより当該アクセスポイント３５の設定／運用の要否を判断可能である。」（摘記事項コの【００４６】）等の記載を参酌すれば，引用発明２の「接続処理失敗ログの一部として」記録される「移動端末のＧＰＳ装置によって検知した車両速度」は，アクセスポイント３５の設定／運用の要否を判断するために用いられるから，引用発明１の「接続確立失敗ログ」に記憶される情報と同様，ネットワーク最適化に用いられる情報であると認められる。また，この「移動端末のＧＰＳ装置によって検知した車両速度」は，移動端末が備えるＧＰＳ装置によって検知された速度であるから「移動端末の移動速度の情報」であることは明らかである。
　そして，引用発明１の「接続確立失敗ログ」として記憶される具体的な情報は，引用例１に「送信されたプリアンブルの数」，「検出された競合」，「使用された最大送信電力」，「要因値」，「無線環境」，「ロケーション」，「セルＩＤ」などの情報が提案されていることからもわかるように，必要に応じて種々の情報を選択し得るものであることころ，引用発明２の「移動端末のＧＰＳ装置によって検知した車両速度」，すなわち，「ユーザ端末の移動速度の情報」をこれらに付加して記憶するようにすることは，当業者であれば容易になし得たものである。
　
　そして，本願発明が奏する効果も引用発明１，２から容易に予測出来る範囲内のものである。
　
５　むすび
　以上のとおり，本願発明は，上記引用例１，２に記載された発明に基づいて，当業者が容易に発明をすることができたものと認められるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，他の請求項に係る発明について審理するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。