• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04W
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
管理番号 1352138
審判番号 不服2017-12180  
総通号数 235 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-07-26 
種別 拒絶査定不服の審決 
審判請求日 2017-08-16 
確定日 2019-06-04 
事件の表示 特願2014-546095「異なる無線アクセスネットワーク間でユーザ機器のハンドオーバを実行するための装置および方法」拒絶査定不服審判事件〔平成25年 6月13日国際公開、WO2013/086234、平成27年 1月 8日国内公表、特表2015-501108〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本願は,2012年(平成24年)12月6日(パリ条約による優先権主張外国庁受理 2011年12月6日 アメリカ合衆国,2012年12月5日 アメリカ合衆国)を国際出願日とする出願であって,原審において平成29年4月6日付けで拒絶査定がされ,これに対し,同年8月16日に拒絶査定不服審判が請求され,同時に手続補正がされ,その後,平成30年8月15日付けで当審より拒絶理由(以下,「当審拒絶理由」という。)が通知され,同年11月20日に意見書及び手続補正書が提出されたものである。

第2 本願発明
平成30年11月20日に提出された手続補正書により補正された特許請求の範囲の請求項1及び請求項11には,以下の事項が記載されている。

「【請求項1】
ワイヤレス通信の方法であって,
第1無線アクセスネットワークの第1ユーザプレーン接続を介して,ユーザ機器のためにネットワークコントローラでデータを転送するステップ(102)と,
前記第1ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に,前記ユーザ機器を第2無線アクセスネットワークの第2ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ(110)と
を有し,
前記第1ユーザプレーン接続を介して転送されるデータの量が所定期間中に第1閾値を超える場合に,前記トリガ条件が満たされ,
前記ハンドオーバ手続を開始した後,戻る条件が満たされる場合に,前記第1無線アクセスネットワークに戻るステップをさらに有し,前記戻る条件は,前記第2無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む,方法。

【請求項11】
前記ハンドオーバ手続が,前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み,前記要求が,受信ウィンドウサイズに対応するメッセージを含む請求項1に記載の方法。
」
([当審注]:下線部は補正箇所を示す。なお,半角は全角表示とした。)

平成30年11月20日付けの手続補正により,補正前の請求項1の
「前記ハンドオーバ手続が,前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み,前記要求が,受信ウィンドウサイズに対応するメッセージを含む,」との発明特定事項が,請求項1から削除され,新規の従属項として請求項11とされた。

第3 当審の拒絶理由通知の概要

補正前の請求項1に係る発明に対する当審拒絶理由の概要は,以下のとおりである。

1.理由1(明確性),理由2(サポート要件),理由3(実施可能要件)について
理由1,2,3は,「(明確性)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。」,「(サポート要件)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号に規定する要件を満たしていない。」,「(実施可能要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。」というものであり,その具体的な理由は次のとおりである。

(1)明確性,サポート要件
請求項1には,「第1無線アクセスネットワークの第1ユーザプレーン接続を介して,ユーザ機器のためにネットワークコントローラでデータを転送するステップと,前記第1ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に,前記ユーザ機器を第2無線アクセスネットワークの第2ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ」を有していることから,発明の詳細な説明に記載されるソースRNCを特定するものであると解される。
しかしながら,ソースRNCは要求を単に中継するだけであって,中継するデータの内容を判別しないから,ソースRNCがどのようにして「第2ユーザプレーン接続を開始する前に・・・中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止」し得るのか不明である。
したがって,「前記ハンドオーバ手続が,前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み,前記要求が,受信ウィンドウサイズに対応するメッセージを含む」なる事項は,ソースRNCに係るワイヤレス通信の方法を特定する事項として不明確である。
また,発明の詳細な説明には,ソースRNCが,第2ユーザプレーン接続を開始する前に,ユーザ機器とのデータ通信でユーザ機器から遠隔サーバに要求を中継することにより,第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止させるものは記載されていない。
したがって,請求項1に係る発明は明確でなく,また,請求項1に係る発明は発明の詳細な説明に記載されたものでない。

(2)実施可能要件
図8,図9,図11及びその説明等の記載によれば,第2ユーザプレーン接続は,ソースRNC104が,あるUEについてある期間内に所定の閾値を超えるデータ量があることをトリガとして,当該UEがUTRANからeUTRANに移動させられるべきと判定し(ステップ902),ソースSGSNにRelｏcaｔiｏn Reｑｕiｒedメッセージを送信し,ソースSGSNからRelｏcaｔiｏn Cｏmmandを受信し,当該UEに対してメッセージHO fｒｏm UTRAN Cｏmmandを送信することにより,開始されると認められる。したがって,「前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」するためには,UEはソースRNCからHO fｒｏm UTRAN Cｏmmandを受信する前に遠隔サーバに要求を送信する必要がある。
一方,段落0074,0075の記載によれば,停止メッセージがUEによって十分に前に送信されるための好適なトリガとして,「HSPAもしくはLTEにおけるモビリティイベント(mｏbiliｔｙ eｖenｔ)」,「モビリティイベントにつながるイベント」が例示されているのみである。
しかしながら,モビリティイベント及びモビリティイベントにつながるイベントが具体的に開示されておらず不明確であり,また,第2ユーザプレーン接続を開始するトリガである「あるUEについてある期間内に所定の閾値を超えるデータ量があること」はモビリティ(移動)とは無関係であるから,例示された上記好適なトリガによりUEが停止メッセージを送信したとしても,当該送信は必ずしも「第2ユーザプレーン接続を開始する前」であるとはいえない。
また,ユーザ機器から遠隔サーバへの要求は,ソースRNCが制御し得るものではなく,ソースRNCはユーザ機器と遠隔サーバとの間のデータ通信を単に中継するだけであって中継するデータ通信の内容を理解するものではないから,必ず「第2ユーザプレーン接続を開始する前に,ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」することはソースRNCにはできないはずである。
してみると,発明の詳細な説明には,「前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止すること」を含むハンドオーバ手続について,当業者が発明を実施できる程度に明確かつ十分に記載されているとはいえない。
よって,請求項1に係る発明は明確でなく,また請求項1に係る発明は発明の詳細な説明に記載したものではない。更に,この出願の発明の詳細な説明は,当業者が請求項1に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。

2.理由5(進歩性)について

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

第4 当審の判断

1 当審拒絶理由通知の概要の1.[理由1(明確性),理由2(サポート要件),理由3(実施可能要件)について]

(1)明確性について

発明の詳細な説明(特に段落[0079]-[0081])を参酌すると,請求項1のステップ(102),ステップ(110)はソースRNCの処理動作であるから,請求項1及び請求項11に係る発明はソースRNCにおけるワイヤレス通信の方法を含むものと認められる。しかしながら,ソースRNCは,UEの要求を遠隔サーバに単に中継するものであって,中継する要求の内容を判別するものではないから,ソースRNCがどの様にして「第2ユーザプレーン接続を開始する前に,ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止」し得るのか不明である。このため請求項11に係る発明は不明確である。
したがって,請求項11の記載は,特許法第36条第6項第2号に規定する要件を満たしていない。

(2)サポート要件,実施可能要件について

本願明細書には,以下の事項が記載されている。(なお,半角は全角表示とした。)

ア「【0068】
プロセス800を参照すると、ステップ802において、UE101が、最初に、UTRAN102にキャンプオンさせられる。ステップ804において、UE101が、HSPAを使用してデータを転送している(たとえば、遠隔サーバまたはアプリケーションサーバからデータをダウンロードしている)。たとえば、UE101は、HSPAによるTCP接続を使用して遠隔サーバまたはアプリケーションサーバからファイルをダウンロードしている可能性がある。ステップ806において、特定のハンドオーバまたはトリガ条件が満たされる場合、UE101が、UTRAN102からeUTRAN110に移動させられる。一態様において、RNC104のインターラットルーチン312は、ハンドオーバ条件を監視するための好適な機能を含み得る。たとえば、UE101がある期間内に閾値(たとえば、所定の閾値)を超える量のデータをダウンロードしており、UTRANにキャンプオンさせられている場合、ステップ808において、UE101をUTRANからeUTRANに移動させるためにインターラットハンドオーバがトリガされる可能性がある。」

イ「【0074】
図9は、パケットの破棄を防止または削減しながらUE101をUTRANからeUTRANに移動させる例示的な手順を示す流れ図900である。例として、図9によって示される手順が、図8のブロック808によって実施される可能性がある。図9を参照すると、ステップ902において、RNC104が、上述のトリガ条件またはその他の好適な条件のうちの1つまたは複数に基づいてUE101がUTRANからeUTRANに移動させられるべきであると判定する。たとえば、UE101が、HSPAによって遠隔サーバ120にデータを転送している。次に、ステップ904において、UE101が、UE101へのデータの送信を停止するように遠隔サーバに要求するために遠隔サーバに停止メッセージを送信する。本開示の一態様においては、UE101のハンドオーバルーチン212が、遠隔サーバ120に停止メッセージを送信するための好適な機能を含む可能性がある。一例において、UE101は、UTRANを通じてTCPサーバとデータ通信をする可能性があり、ハンドオーバを開始する前にTCPサーバに停止メッセージ(たとえば、0個のメッセージに等しい受信ウィンドウサイズ、以降、「ｒeceiｖe ｗindｏｗ = 0」)を送信する可能性がある。ステップ906において、停止メッセージに応じて、遠隔サーバが、UE101にそれ以上のパケットの送信を停止する。ステップ908において、ハンドオーバが、UE101をUTRANからeUTRANに移動させ始める可能性がある。たとえば、UE101のルーチン212が、ハンドオーバ手続を実行するための好適な機能を含む可能性がある。」

ウ「【0075】
しかしながら、遠隔サーバは停止メッセージが受信される前にいくつかのさらなるパケットを送信した可能性があるので、データパスにまだパケットが存在する可能性がある。たとえば、いくつかのパケットが、RNC104、またはUE101と遠隔サーバ120との間のその他のネットワークノードにある可能性がある。したがって、停止メッセージ(たとえば、「ｒeceiｖe ｗindｏｗ = 0」)は、UE101によって十分に前に送信される。一部の例において、適切なトリガが、インターラットハンドオーバの十分に前に遠隔サーバ120に「ｒeceiｖe ｗindｏｗ = 0」メッセージを送信するために使用され得る。本開示の一部の態様によれば、好適なトリガは、HSPAもしくはLTEにおけるモビリティイベント(mｏbiliｔｙ eｖenｔ)、またはモビリティイベントにつながるイベントである可能性がある。」

エ「【0079】
図11を参照すると、ソース(ハンドオーバ元)RNC104が、図8を参照して説明されたトリガ条件のうちの1つまたは複数に基づいてUTRANからeUTRANへのインターラットハンドオーバを開始することを決定する。この時点で、アップリンクのユーザデータおよび/またはダウンリンクのユーザデータの両方は、以下、すなわち、UE101とソースRNC104との間のベアラ1102、ソースRNC104と、ソースSGSN109と、サービングゲートウェイ(S-GW)116と、PDSNゲートウェイ(P-GW)118との間のGPRSトンネリングプロトコル(GTP)トンネル1104を介して送信される可能性がある。」

オ「【0080】
準備フェーズにおいて、ソースRNC104は、ターゲットeNB112、ターゲットMME114、およびS-GW116のリソースを確立するようにコアネットワークに要求するためにソースSGSN109にRelｏcaｔiｏn Reｑｕiｒedメッセージを送信する。準備フェーズ中、ソースRNC104は、ダウンリンクおよび/またはアップリンクのユーザプレーンのPDUを受信し続ける。実行フェーズにおいて、ソースSGSN109は、ソースRNC104にメッセージRelｏcaｔiｏn Cｏmmand1106を送信する。ソースRNC104は、メッセージHO fｒｏm UTRAN Cｏmmand 1108によって、ターゲットeNB112にハンドオーバするようにUE101に命じる。UEへのアクセスネットワークに固有のメッセージは、ターゲットeNB112が準備フェーズで設定した無線アスペクトパラメータ(ｒadiｏ aｓｐecｔ ｐaｒameｔeｒ)を含む透過コンテナを含む。」

発明の詳細な説明には,ソースRNCが,第2ユーザプレーン接続を開始する前に,ユーザ機器とのデータ通信でユーザ機器から遠隔サーバに要求を中継することにより,第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止させるものは記載されていない。
図8,図9,図11及びその説明等の記載によれば,第2ユーザプレーン接続は,ソースRNC104が,あるUEについてある期間内に所定の閾値を超えるデータ量があることをトリガとして(摘記 ア 参照),当該UEがUTRANからeUTRANに移動させられるべきと判定し(摘記 イ及びエ参照),ソースSGSNにRelｏcaｔiｏn Reｑｕiｒedメッセージを送信し,ソースSGSNからRelｏcaｔiｏn Cｏmmandを受信し,当該UEに対してメッセージHO fｒｏm UTRAN Cｏmmandを送信することにより,開始されると認められる(摘記 オ 参照)。
そうすると,「前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」するためには,UEはソースRNCからHO fｒｏm UTRAN Cｏmmandを受信する前に遠隔サーバに要求を送信する必要がある。
一方,摘記 イ及びウの記載によれば,ユーザ機器へのデータの送信を停止するための要求として遠隔サーバに送信される停止メッセージがUEによって十分に前に送信されるための好適なトリガとして,「HSPAもしくはLTEにおけるモビリティイベント(mｏbiliｔｙ eｖenｔ)」,「モビリティイベントにつながるイベント」が例示されているのみであるが,モビリティイベント及びモビリティイベントにつながるイベントが具体的に開示されていない。また,第2ユーザプレーン接続を開始するトリガである「あるUEについてある期間内に所定の閾値を超えるデータ量があること」は,モビリティ(移動)とは無関係であるから,例示された上記好適なトリガであるモビリティイベント又はモビリティイベントにつながるイベントによりUEが停止メッセージを送信したとしても,当該送信は必ずしも「第2ユーザプレーン接続を開始する前」であるとはいえない。
また,ユーザ機器から遠隔サーバへの要求は,ソースRNCが制御し得るものではなく,ソースRNCはユーザ機器と遠隔サーバとの間の間のデータ通信を単に中継するだけであって中継するデータ通信の内容を理解するものではないから,必ず「第2ユーザプレーン接続を開始する前に,ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」することは,ソースRNCにはできないはずである。
してみると,発明の詳細な説明には,「前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止すること」を含むハンドオーバ手続について,当業者が発明を実施できる程度に明確かつ十分に記載されているとはいえない。

請求人は,意見書において「「前記ハンドオーバ手続が,前記第2ユーザプレーン接続を開始する前に,前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して,前記第1ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み,前記要求が,受信ウィンドウサイズに対応するメッセージを含む」との記載は,出願当初の請求項11,12の記載,および,段落[0074]の記載(すなわち,「たとえば,UE101が,HSPAによって遠隔サーバ120にデータを転送している。次に,ステップ904において,UE101が,UE101へのデータの送信を停止するように遠隔サーバに要求するために遠隔サーバに停止メッセージを送信する。」,「ステップ908において,ハンドオーバが,UE101をUTRANからeUTRANに移動させ始める可能性がある。」との記載から,本願の要求中継(ステップ904に対応する)はハンドオーバ交渉を行う(ステップ908に対応する)ことの前に実行されると解釈しています。)に基づいたものです。」と主張する。
しかしながら,発明の詳細な説明の段落[0074]におけるステップ904のUE101による停止メッセージの送信は,UE101が好適なトリガであるモビリティイベント及びモビリティイベントにつながるイベントに基づいて能動的に行われるものであり,ステップ906は,ステップ904において行われた停止メッセージに対して,遠隔サーバがパケットの送信を停止するものである。
一方,ステップ902において行われる「あるUEについてある期間内に所定の閾値を超えるデータ量がある」というトリガ条件に基づいてソースRNCが判定すること,ステップ908において行われるハンドオーバの処理はソースRNCが能動的に実施していることは明らかであるが,当該判定,及びハンドオーバの処理は,上述したように好適なトリガであるモビリティイベント及びモビリティイベントにつながるイベントとは無関係であり,また,UE101で行われるステップ904,ステップ906がソースRNCで行われるステップ902とステップ908の間に必ず実施されることを読み取ることのできる記載は見当たらない。よって,上記主張は採用できない。

したがって,上記補正に係る請求項11の記載は,特許法第36条第4項第1号に規定する要件を満たしていない。

2 当審拒絶理由通知の概要の2.[理由5(進歩性)について]

(1)本願発明

本願の請求項1に係る発明(以下,「本願発明」という。)は,平成30年11月20日に提出された手続補正書により補正された特許請求の範囲の請求項1に記載されたとおりの

「ワイヤレス通信の方法であって,
第1無線アクセスネットワークの第1ユーザプレーン接続を介して,ユーザ機器のためにネットワークコントローラでデータを転送するステップ(102)と,
前記第1ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に,前記ユーザ機器を第2無線アクセスネットワークの第2ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ(110)と
を有し,
前記第1ユーザプレーン接続を介して転送されるデータの量が所定期間中に第1閾値を超える場合に,前記トリガ条件が満たされ,
前記ハンドオーバ手続を開始した後,戻る条件が満たされる場合に,前記第1無線アクセスネットワークに戻るステップをさらに有し,前記戻る条件は,前記第2無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む,方法。」

と認める。

(2)引用発明及び周知技術

[引用発明]
当審拒絶理由に引用された国際公開第2004/023741号(以下,「引用例」という。)には,以下の事項が記載されている。

ア 「ユーザが持つ各移動端末10は,例えば携帯電話機であり,ノードB20のカバーする範囲R1内に存在する場合にノードB20との間が所定の無線通信路によって繋がれ,他方無線LANのエアステーション50のカバーする範囲R2内に存在する場合に当該エアステーション50との間が同様に所定の無線通信路によって繋がれる。ここでノードB20との間の通信では,通常,一般の通話通信,伝送データ量の少ないパケット通信を行い,他方,無線LANのエアステーション50との間の通信では,比較的伝送データ量の大きい高速大容量パケット通信を行なう。」(5ページ9行目?5ページ16行目)

イ 「以下に,本実施例の通信シーケンスについて図2乃至図8と共に説明する。尚,図2のおいて実線は従来のUTRAN経由での信号伝送の流れを示し,破線は無線LAN経由での信号の流れを示す。又,上記3GPPで規定されている装置名称に従い,前述の移動端末10を『MS』,基地局制御装置30を『RNC』,無線基地局20を『ノードB』,基地局制御装置30に接続されるコアネットワーク側装置40の総称を『CN』と称する。
図2において,ステップS1にて,MS10でのデータ受信の際,RNC30とMS10との間で制御信号路確立の為のRRCコネクション設定手順が実行される。尚,これは従来のUMTS,即ち欧州電気通信標準化協会が定める第3世代移動通信システム「IMT2000」の欧州規格で定義されている処理であり,本手順は3GPP仕様書TS25.331で規定されている。
引き続き,ステップS2にて,ユーザデータ伝送路設定の為のPDPコンテキスト処理手順が実行される。本処理手順の詳細は図3に示すとおりであり,これも上記UMTSで定義された処理であり,本手順は3GPP仕様書TS23.060で規定されている。本実施例では,当該手順で規定されているコンテキスト情報として新たに上記『無線LAN希望パラメータ』を付加する(図3のステップS31)。このPDPコンテキスト処理手順が実行されることにより,ユーザデータを運ぶためにRNC30-CN40間にGTPと呼ばれるパイプが確立される。
尚,この処理手順の中でCN40からRNC30に送られるものとして規定されているRABアサイメント・リクエスト(ステップS32)の情報要素の1つとして『無線LAN希望パラメータ』を追加することで,本パラメータ情報がRNC30に届けられ,そこでコンテキスト情報要素の1つとして格納される(ステップS33)と共に,RNC30とMS10との間のユーザデータ伝送路として,割当無線伝送路(Radiｏ Beaｒeｒ)が確立される(ステップS34)。
次にステップS3にて,上記の如く確立されたGTPと割当無線伝送路(Radiｏ Beaｒeｒ)とを使用して従来のUTRAN経路(ノードBG20経由)でのユーザデータ伝送が行なわれる。この際,RNC30の上記ユーザデータ転送部が,CN40から受信したユーザデータを,UTRAN経路へ送出することで,MS10へのユーザデータ伝送が実現される。
(14ページ18行目?15ページ18行目)

ウ ステップS4でRNC30はMS10が受信しているデータの量(トラヒック)の監視を行う。この処理は,従来の3GPP仕様に従った処理としての,データ量に応じて使用される伝送路の割当を共通チャネルと個別チャネルとの間で切り替えるためのRNC30によるトラヒック監視処理の結果を利用する。
次に,ステップS5では,RNC30は上記処理によって得られたデータ量(トラヒック)が,予め定められた所定の閾値を超えたか否かの判断を継続的に行なう。この閾値は,予めRNC30にて固定的に設定されているものとしてもよいし,或いはステップS2にてPDPコンテキスト処理手順の中で,MS10からCN経由でRNC30に通知される情報中に含めて伝送されるものとしてもよい。」(15ページ19行目?15ページ27行目)

エ 「又,RNC30は上記移動端末情報対応表を作成し管理する(ステップS14)。この移動端末情報対応表は,例えば図6Bに示す構成を有し,『移動端末識別子(MSのID)』,『テンポラリIPアドレス』,『割当無線伝送路(Radiｏ Beaｒeｒ)』,『GTP』,『コンテキスト(無線LAN希望)』,及び『閾値』が含まれる。
ステップS15にてRNC30は上記ステップS14で作成された移動端末情報対応表に基づき,データ転送経路を無線LAN経路へ切り替える必要が有るか否かを判断する。具体的には移動端末情報対応表に,『無線LAN希望パラメータ』と『テンポラリIPアドレス』とが含まれている移動端末宛のデータ通信量が上記閾値を超えた場合に,当該移動端末10について上記RNC30の制御部が経路切り替え必要と判断し,RNC30のユーザデータ転送部に対して,無線LAN経路への切替を指示する。
この場合ステップS16にて,RNC30のユーザデータ転送部はユーザデータをテンポラリIPアドレス宛に送信することで,無線LAN経由でのユーザデータ送信が実現される。即ち,図7に示される如く,無線LANのエアステーション50によるデータ伝送路を使用した経路へとユーザデータ転送経路が切り替えられる。以上の手順により,図8に示す如く,ユーザデータは無線LAN経路で当該MS10へと転送される。(17ページ8行目?17ページ25行目)

オ 「ステップS17にて、RNC30はステップS4にて開始したデータ量(トラヒック)の監視を継続しており、データ量(トラヒック)がステップS5に記載の閾値を下回ったか否かを判断する。そして、ステップS18にて、RNC30はでデータ量が閾値を下回ったことを検出した場合、ユーザデータ通信経路を、ステップS16で保持した割当無線伝送路(Radiｏ Beaｒeｒ)経由の経路に切り戻す。」(18ページ7行目?18ページ12行目)

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

(ア)上記イの記載によれば,コアネットワーク装置と基地局制御装置(RNC)(以下,「RNC」と言う。)間にGTPとよばれるパイプが確立され,RNCと移動端末との間のユーザデータ伝送路として,割当無線伝送路(Radiｏ Beaｒeｒ)が確立され,確立されたGTPと割当無線伝送路とを使用して,RNCのユーザデータ転送部が,コアネットワーク装置から受信したデータを移動端末へ送出するものである。
したがって,引用例には,「RNCと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して,RNCがコアネットワーク装置から受信したユーザデータを移動端末へ転送するステップ」が記載されているといえる。

(イ)上記ウ,エの記載によれば,RNCは移動端末が受信しているデータの量(トラヒック)の監視をして予め定められた所定の閾値を超えたか否かの判断を継続的に行い,移動端末宛てのデータ通信量が閾値を超えた場合に,移動端末についてRNCの制御部が経路切り替えが必要と判断し,RNCのユーザデータ転送部に対して,無線LAN経路への切替を指示し,RNCのユーザデータ転送部はユーザデータを無線LAN経由で移動端末に送信するものである。
したがって,引用例には,「転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に,RNCの制御部は移動端末を割当無線伝送路から無線LAN経路へ切り替えるため通信経路の切替をRNCのユーザデータ転送部に指示するステップ」が記載されているといえる。

(ウ)上記オの記載によれば,経路を無線LAN経路とした後,RNCはデータ通信量の監視を継続して行い,データ通信量(トラフィック)が閾値を下回ったか否かを判断し,データ量が閾値を下回った場合,ユーザデータ通信経路を割当無線伝送路経由に切り戻すから,データ通信量は経時的に変化するものであることは明らかである。してみると,当該データ通信量とは,データ通信が行われた総量ではなく,所定の期間中のデータ通信量であるといえる。
したがって,引用例には,「RNCは,所定期間中のデータ通信量が閾値を超える場合に,通信経路を切り替える」ものが記載されているといえる。

(エ)そして,上記(ア)(イ)(ウ)に記載される,割当無線伝送路及び無線LAN経路を用いた移動端末とのそれぞれのデータ通信は,いずれもワイヤレス通信であると言え,RNCがデータ通信量によって,割当無線伝送路と無線LAN経路を切り替える方法が記載されているといえるから,引用例には,「ワイヤレス通信の方法」が記載されているといえる。

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

「ワイヤレス通信の方法であって,
RNCと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して,RNCがコアネットワーク装置から受信したユーザデータを移動端末へ転送するステップと,
転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に,RNCの制御部は移動端末を割当無線伝送路から無線LAN経路へ切り替えるため通信経路の切替をRNCのユーザデータ転送部に指示するステップと
を有し,
RNCは,所定期間中のデータ通信量が閾値を超える場合に,通信経路を切り替える,
方法。」

[周知技術]
本件の優先日前に公開された,NTTドコモ,NTT DｏCｏMｏテクニカルジャーナル VOL.14 NO.3,HSDPA特集 HSDPA移動端末の開発および無線伝送特性,2006年6月掲載,hｔｔｐｓ://ｗｗｗ.nｔｔdｏcｏmｏ.cｏ.jｐ/cｏｒｐｏｒaｔe/ｔechnｏlｏgｙ/ｒd/ｔechnical_jｏｕｒnal/bn/ｖｏl14_3/ｖｏl14_3_014jｐ.ｐdf(以下,「周知例1」という。)には以下の事項が記載されている。

カ 「4.1 HSDPAにおけるハンドオーバ
(略)
以下にHSDPAにおけるハンドオーバ手順を示す。
▲1▼移動端末にて周辺セルから固定電力で送信されている共通パイロットチャネル(CPICH:cｏmmｏn PIlｏｔ CHannel)の品質レベル測定を行う
▲2▼ハンドオーバ元セルのCPICH品質レベルに対し,一定のしきい値(ネットワークより通知されるパラメータ)を超える品質レベルのCPICHが存在した場合,無線ネットワーク制御装置(RNC:Radiｏ Neｔｗｏｒk Cｏnｔｒｏlleｒ)へ当該セルの報告を行う(しきい値を超えるセルが複数存在した場合は,その中で最も品質レベルの高いセルを報告する)
▲3▼RNCは移動端末からの報告を基にハンドオーバ先セルの設定を行い,移動端末へのハンドオーバの通知を行う
▲4▼ハンドオーバの通知を受けた移動端末は,ハンドオーバ元セルとの切断およびハンドオーバ先セルとの接続を行う」

本件の優先日前に公開された,国際公開第2009/066622号(以下,「周知例2」という。)には以下の事項が記載されている。

キ 「【0030】
移動局3において,システムAの周波数RF2での通信品質が低下すると,例えば異周波数RF1の通信品質の測定を開始し,異周波数RF1の通信品質が所定の閾値を超え,もとの周波数RF2の通信品質が所定値以下となるか,あるいは,異周波数RF1の通信品質ともとの周波数RF2の通信品質との差が所定の閾値以上に開くと,異周波数RF1への切替え(異周波数ハンドオーバ)を行う。」

本件の優先日前に公開された,特開2009-49545号(以下,「周知例3」という。)には以下の事項が記載されている。

ク 「【0002】
無線LAN等の移動体通信システムにおいては、無線端末が帰属する無線基地局からの信号強度が、無線端末に予め設定された所定の閾値(以下、「ハンドオーバ閾値」と呼ぶ)より下回った場合に、より電波状態の良い他の無線基地局へ帰属替え(以下、「ハンドオーバ」と呼ぶ)を行うのが一般的である。」

上記カ,キ,クの記載並びに当業者の技術常識を考慮すると,「ハンドオーバ手順(手続)では,帰属する基地局(ハンドオーバ元)の通信品質が所定の値以下になり,ハンドオーバ先セル(ネットワーク)の通信品質がしきい値を超える場合に,ハンドオーバ先のセル(ネットワーク)に接続を行う。」ことは,周知技術であるといえる。

(3)対比・判断

本願発明と引用発明とを対比すると,以下のことがいえる。

ア 引用発明の「移動端末」はユーザが持ち利用する端末であるから「ユーザ端末」と言え,「割当無線伝送路」は「無線アクセスネットワーク」に含まれ,「ユーザデータ」は「データ」に含まれる。また,RNCは当該技術分野においてラジオネットワークコントローラを表すものであるから,「ネットワークコントローラ」に含まれる。そして,「割当無線伝送路」は「RNCと移動端末との間のユーザデータ伝送路」であるから「ユーザプレーン接続」といえ,これを「第1ユーザプレーン接続」と称することは任意である。
したがって,引用発明の「RNCと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して,移動端末のためにRNCでユーザデータを転送するステップ」は,「第1無線アクセスネットワークの第1ユーザプレーン接続を介して,ユーザ機器のためにネットワークコントローラでデータを転送するステップ」といえる点で本願発明と共通している。

イ 引用発明のRNCの制御部が,「割当無線伝送路から無線LAN経路へ切り替えるため通信経路の切替をRNCのユーザデータ転送部に指示」することは,「ハンドオーバ手続を開始する」ことに含まれる。また,「無線LAN経路」は「無線アクセスネットワーク」に含まれ,引用発明の「無線LAN経路」を介してユーザ端末のためにユーザデータを転送するものであるから,引用発明の「無線LAN経路」は「ユーザプレーン接続」といえ,これを「第2ユーザプレーン接続」と称することは任意である。そして,当該「ハンドオーバ手続の開始」は,ユーザデータのデータ通信量が「閾値を超えた」場合であるから,当該「閾値」は「ハンドオーバ手続の開始」の「トリガ条件」であるといえ,「閾値を超える」ことは,「トリガ条件が満たされる」ことに相当する。また,「割当無線伝送路から無線LAN経路への切り替え」は「割当無線伝送路から無線LAN経路への移行」ともいえる。
そうすると,引用発明の「転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に,RNCの制御部は移動端末を割当無線伝送路から無線LAN経路へ切り替えるため通信経路の切替えをRNCのユーザデータ転送部に指示するステップ」は,「第1ユーザプレーン接続を介して転送されるデータの量がトリガ条件を満たされる場合に,ユーザ機器を(第1無線アクセスネットワークの第1ユーザプレーン接続から)第2無線アクセスネットワークの第2ユーザプレーン接続への移行させるハンドオーバ手続を開始するステップ」といえる点で本願発明と共通している。

ウ 引用発明の「通信経路の切り替え(ハンドオーバ手続の開始)」は,上記イで記載したとおり,「トリガ条件が満たされる」ことによって行われるものである。そうすると,引用発明の「RNCは,所定期間中のデータ通信量が閾値を超える場合に,通信経路を切り替える」ことは,本願発明の「(RNCは)第1ユーザプレーン接続を介して転送されるデータの量が所定の期間中に閾値を超える場合に,トリガ条件が満たされたと判断する」ことに相当する。

以上を総合すると,補正後の発明と引用発明とは,以下の点で一致し,また,相違している。

(一致点)
「ワイヤレス通信の方法であって,
第1無線アクセスネットワークの第1ユーザプレーン接続を介して,ユーザ機器のためにネットワークコントローラでデータを転送するステップと,
前記第1ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に,前記ユーザ機器を第2無線アクセスネットワークの第2ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップと
を有し,
前記第1ユーザプレーン接続を介して転送されるデータの量が所定期間中に第1閾値を超える場合に,前記トリガ条件が満たされたと判断する,
方法。」

(相違点)
本願発明は,「前記ハンドオーバ手続を開始した後,戻る条件が満たされる場合に,前記第1無線アクセスネットワークに戻るステップをさらに有し,前記戻る条件は,前記第2無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む,」との発明特定事項を有するのに対し,引用発明は当該発明特定事項を有していない点。

以下,上記相違点について検討する。

本願発明における「ハンドオーバ手続を開始した後」とは,第1ユーザプレーン接続を介して転送されるデータの量が所定期間中に第1閾値を超えた後の期間をすべて含むものである。また,発明の詳細な説明の段落[0071]を参照すると,本願発明における「品質」とは,信号品質(例えば基準信号受信品質),すなわち通信品質を含むものである。

そして,上記「(2)引用発明及び周知技術」の項の「[周知技術]」にて述べたとおり,「ハンドオーバ手順(手続)では,帰属する基地局(ハンドオーバ元)の通信品質が所定の値以下になり,ハンドオーバ先セル(ネットワーク)の通信品質がしきい値を超える場合に,ハンドオーバ先のセル(ネットワーク)に接続を行う。」ことは周知であり,当該周知技術は,言い換えれば「ハンドオーバ手順(手続)では,ハンドオーバ先セル(ネットワーク)の通信品質がしきい値を超えない場合,ハンドオーバ先のセル(ネットワーク)との接続を行わない。」といえる。そうすると,第1ユーザプレーン接続を介して転送されるデータの量が所定期間中に第1閾値を超えた後,ハンドオーバ先セル(ネットワーク)の品質がしきい値を超えない場合,ハンドオーバ先のセルとの接続を行わない,すなわち「ハンドオーバ手続を開始した後,戻る条件が満たされる場合に,前記第1無線アクセスネットワークに戻るステップをさらに有し,前記戻る条件は,前記第2無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む,」とすることは当業者において周知技術から容易に想到し得るものである。

そして,本願発明の作用効果も,引用発明及び周知技術に基づいて当業者が予測できる範囲のものにすぎず,格別顕著なものとはいえない。

したがって,本願発明は,引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許を受けることができない。

第5 むすび

以上のとおり,本願は,発明の詳細な説明の記載が特許法36条4項1号に規定する要件を満たしておらず,特許請求の範囲の記載が同条6項1号,同条6項2号に規定する要件を満たしていないから,拒絶すべきものである。
また,本願発明は,引用発明に及び周知技術に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない。
したがって,他の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2019-01-09 
結審通知日 2019-01-11 
審決日 2019-01-22 
出願番号 特願2014-546095(P2014-546095)
審決分類 P 1 8・ 536- WZ (H04W)
P 1 8・ 121- WZ (H04W)
P 1 8・ 537- WZ (H04W)
最終処分 不成立  
前審関与審査官 久慈 渉、廣川 浩  
特許庁審判長 菅原 道晴
特許庁審判官 本郷 彰
羽岡 さやか
発明の名称 異なる無線アクセスネットワーク間でユーザ機器のハンドオーバを実行するための装置および方法  
代理人 黒田 晋平  
代理人 村山 靖彦  

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