【事件の表示】
　特願２０１４−５４６０９５「異なる無線アクセスネットワーク間でユーザ機器のハンドオーバを実行するための装置および方法」拒絶査定不服審判事件〔平成２５年　６月１３日国際公開、ＷＯ２０１３／０８６２３４、平成２７年　１月　８日国内公表、特表２０１５−５０１１０８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，２０１２年（平成２４年）１２月６日（パリ条約による優先権主張外国庁受理　２０１１年１２月６日　アメリカ合衆国，２０１２年１２月５日　アメリカ合衆国）を国際出願日とする出願であって，原審において平成２９年４月６日付けで拒絶査定がされ，これに対し，同年８月１６日に拒絶査定不服審判が請求され，同時に手続補正がされ，その後，平成３０年８月１５日付けで当審より拒絶理由（以下，「当審拒絶理由」という。）が通知され，同年１１月２０日に意見書及び手続補正書が提出されたものである。
第２　本願発明
　平成３０年１１月２０日に提出された手続補正書により補正された特許請求の範囲の請求項１及び請求項１１には，以下の事項が記載されている。
「【請求項１】
　ワイヤレス通信の方法であって，
　第１無線アクセスネットワークの第１ユーザプレーン接続を介して，ユーザ機器のためにネットワークコントローラでデータを転送するステップ（１０２）と，
　前記第１ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に，前記ユーザ機器を第２無線アクセスネットワークの第２ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ（１１０）と
を有し，
　前記第１ユーザプレーン接続を介して転送されるデータの量が所定期間中に第１閾値を超える場合に，前記トリガ条件が満たされ，
　
前記ハンドオーバ手続を開始した後，戻る条件が満たされる場合に，前記第１無線アクセスネットワークに戻るステップをさらに有し，前記戻る条件は，前記第２無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む，
【請求項１１】
　
前記ハンドオーバ手続が，前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み，前記要求が，受信ウィンドウサイズに対応するメッセージを含む請求項１に記載の方法。
」
（［当審注］：下線部は補正箇所を示す。なお，半角は全角表示とした。）
　平成３０年１１月２０日付けの手続補正により，補正前の請求項１の
「前記ハンドオーバ手続が，前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み，前記要求が，受信ウィンドウサイズに対応するメッセージを含む，」との発明特定事項が，請求項１から削除され，新規の従属項として請求項１１とされた。
第３　当審の拒絶理由通知の概要
　補正前の請求項１に係る発明に対する当審拒絶理由の概要は，以下のとおりである。
１．理由１（明確性），理由２（サポート要件），理由３（実施可能要件）について
　理由１，２，３は，「（明確性）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。」，「（サポート要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていない。」，「（実施可能要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。」というものであり，その具体的な理由は次のとおりである。
（１）明確性，サポート要件
　請求項１には，「第１無線アクセスネットワークの第１ユーザプレーン接続を介して，ユーザ機器のためにネットワークコントローラでデータを転送するステップと，前記第１ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に，前記ユーザ機器を第２無線アクセスネットワークの第２ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ」を有していることから，発明の詳細な説明に記載されるソースＲＮＣを特定するものであると解される。　
　しかしながら，ソースＲＮＣは要求を単に中継するだけであって，中継するデータの内容を判別しないから，ソースＲＮＣがどのようにして「第２ユーザプレーン接続を開始する前に・・・中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止」し得るのか不明である。　
　したがって，「前記ハンドオーバ手続が，前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み，前記要求が，受信ウィンドウサイズに対応するメッセージを含む」なる事項は，ソースＲＮＣに係るワイヤレス通信の方法を特定する事項として不明確である。　
　また，発明の詳細な説明には，ソースＲＮＣが，第２ユーザプレーン接続を開始する前に，ユーザ機器とのデータ通信でユーザ機器から遠隔サーバに要求を中継することにより，第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止させるものは記載されていない。　
　したがって，請求項１に係る発明は明確でなく，また，請求項１に係る発明は発明の詳細な説明に記載されたものでない。　
（２）実施可能要件
　図８，図９，図１１及びその説明等の記載によれば，第２ユーザプレーン接続は，ソースＲＮＣ１０４が，あるＵＥについてある期間内に所定の閾値を超えるデータ量があることをトリガとして，当該ＵＥがＵＴＲＡＮからｅＵＴＲＡＮに移動させられるべきと判定し（ステップ９０２），ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｉｒｅｄメッセージを送信し，ソースＳＧＳＮからＲｅｌｏｃａｔｉｏｎ　Ｃｏｍｍａｎｄを受信し，当該ＵＥに対してメッセージＨＯ　ｆｒｏｍ　ＵＴＲＡＮ　Ｃｏｍｍａｎｄを送信することにより，開始されると認められる。したがって，「前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」するためには，ＵＥはソースＲＮＣからＨＯ　ｆｒｏｍ　ＵＴＲＡＮ　Ｃｏｍｍａｎｄを受信する前に遠隔サーバに要求を送信する必要がある。　
　一方，段落００７４，００７５の記載によれば，停止メッセージがＵＥによって十分に前に送信されるための好適なトリガとして，「ＨＳＰＡもしくはＬＴＥにおけるモビリティイベント（ｍｏｂｉｌｉｔｙ　ｅｖｅｎｔ）」，「モビリティイベントにつながるイベント」が例示されているのみである。　
　しかしながら，モビリティイベント及びモビリティイベントにつながるイベントが具体的に開示されておらず不明確であり，また，第２ユーザプレーン接続を開始するトリガである「あるＵＥについてある期間内に所定の閾値を超えるデータ量があること」はモビリティ（移動）とは無関係であるから，例示された上記好適なトリガによりＵＥが停止メッセージを送信したとしても，当該送信は必ずしも「第２ユーザプレーン接続を開始する前」であるとはいえない。
　また，ユーザ機器から遠隔サーバへの要求は，ソースＲＮＣが制御し得るものではなく，ソースＲＮＣはユーザ機器と遠隔サーバとの間のデータ通信を単に中継するだけであって中継するデータ通信の内容を理解するものではないから，必ず「第２ユーザプレーン接続を開始する前に，ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」することはソースＲＮＣにはできないはずである。　
　してみると，発明の詳細な説明には，「前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止すること」を含むハンドオーバ手続について，当業者が発明を実施できる程度に明確かつ十分に記載されているとはいえない。
　よって，請求項１に係る発明は明確でなく，また請求項１に係る発明は発明の詳細な説明に記載したものではない。更に，この出願の発明の詳細な説明は，当業者が請求項１に係る発明を実施することができる程度に明確かつ十分に記載されたものでない。
２．理由５（進歩性）について
　理由５は，「（進歩性）この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。」というものであり，請求項１に係る発明に対して，国際公開第２００４／０２３７４１号が引用されている。
第４　当審の判断
１　当審拒絶理由通知の概要の１．［理由１（明確性），理由２（サポート要件），理由３（実施可能要件）について］
（１）明確性について
　発明の詳細な説明（特に段落［００７９］−［００８１］）を参酌すると，請求項１のステップ（１０２），ステップ（１１０）はソースＲＮＣの処理動作であるから，請求項１及び請求項１１に係る発明はソースＲＮＣにおけるワイヤレス通信の方法を含むものと認められる。しかしながら，ソースＲＮＣは，ＵＥの要求を遠隔サーバに単に中継するものであって，中継する要求の内容を判別するものではないから，ソースＲＮＣがどの様にして「第２ユーザプレーン接続を開始する前に，ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止」し得るのか不明である。このため請求項１１に係る発明は不明確である。
　したがって，請求項１１の記載は，特許法第３６条第６項第２号に規定する要件を満たしていない。
（２）サポート要件，実施可能要件について
本願明細書には，以下の事項が記載されている。（なお，半角は全角表示とした。）
ア「【００６８】
　プロセス８００を参照すると、ステップ８０２において、ＵＥ１０１が、最初に、ＵＴＲＡＮ１０２にキャンプオンさせられる。ステップ８０４において、ＵＥ１０１が、ＨＳＰＡを使用してデータを転送している（たとえば、遠隔サーバまたはアプリケーションサーバからデータをダウンロードしている）。たとえば、ＵＥ１０１は、ＨＳＰＡによるＴＣＰ接続を使用して遠隔サーバまたはアプリケーションサーバからファイルをダウンロードしている可能性がある。
ステップ８０６において、特定のハンドオーバまたはトリガ条件が満たされる場合、ＵＥ１０１が、ＵＴＲＡＮ１０２からｅＵＴＲＡＮ１１０に移動させられる。一態様において、ＲＮＣ１０４のインターラットルーチン３１２は、ハンドオーバ条件を監視するための好適な機能を含み得る。たとえば、ＵＥ１０１がある期間内に閾値（たとえば、所定の閾値）を超える量のデータをダウンロードしており、ＵＴＲＡＮにキャンプオンさせられている場合、ステップ８０８において、ＵＥ１０１をＵＴＲＡＮからｅＵＴＲＡＮに移動させるためにインターラットハンドオーバがトリガされる
イ「【００７４】
　図９は、パケットの破棄を防止または削減しながらＵＥ１０１をＵＴＲＡＮからｅＵＴＲＡＮに移動させる例示的な手順を示す流れ図９００である。例として、図９によって示される手順が、図８のブロック８０８によって実施される可能性がある。
図９を参照すると、ステップ９０２において、ＲＮＣ１０４が、上述のトリガ条件またはその他の好適な条件のうちの１つまたは複数に基づいてＵＥ１０１がＵＴＲＡＮからｅＵＴＲＡＮに移動させられるべきであると判定する。
ＵＥ１０１が、ＵＥ１０１へのデータの送信を停止するように遠隔サーバに要求するために遠隔サーバに停止メッセージを送信する。本開示の一態様においては、ＵＥ１０１のハンドオーバルーチン２１２が、遠隔サーバ１２０に停止メッセージを送信するための好適な機能を含む可能性がある。一例において、ＵＥ１０１は、ＵＴＲＡＮを通じてＴＣＰサーバとデータ通信をする可能性があり、ハンドオーバを開始する前にＴＣＰサーバに停止メッセージ（たとえば、０個のメッセージに等しい受信ウィンドウサイズ、以降、「ｒｅｃｅｉｖｅ　ｗｉｎｄｏｗ　＝　０」）を送信する可能性がある。
ウ「【００７５】
　しかしながら、遠隔サーバは停止メッセージが受信される前にいくつかのさらなるパケットを送信した可能性があるので、データパスにまだパケットが存在する可能性がある。たとえば、いくつかのパケットが、ＲＮＣ１０４、またはＵＥ１０１と遠隔サーバ１２０との間のその他のネットワークノードにある可能性がある。したがって、
停止メッセージ（たとえば、「ｒｅｃｅｉｖｅ　ｗｉｎｄｏｗ　＝　０」）は、ＵＥ１０１によって十分に前に送信される。一部の例において、適切なトリガが、インターラットハンドオーバの十分に前に遠隔サーバ１２０に「ｒｅｃｅｉｖｅ　ｗｉｎｄｏｗ　＝　０」メッセージを送信するために使用され得る。本開示の一部の態様によれば、好適なトリガは、ＨＳＰＡもしくはＬＴＥにおけるモビリティイベント（ｍｏｂｉｌｉｔｙ　ｅｖｅｎｔ）、またはモビリティイベントにつながるイベントである
エ「【００７９】
　図１１を参照すると、
ソース（ハンドオーバ元）ＲＮＣ１０４が、図８を参照して説明されたトリガ条件のうちの１つまたは複数に基づいてＵＴＲＡＮからｅＵＴＲＡＮへのインターラットハンドオーバを開始することを決定する。
オ「【００８０】
　準備フェーズにおいて、
ソースＲＮＣ１０４は、ターゲットｅＮＢ１１２、ターゲットＭＭＥ１１４、およびＳ−ＧＷ１１６のリソースを確立するようにコアネットワークに要求するためにソースＳＧＳＮ１０９にＲｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｉｒｅｄメッセージを送信する。
ソースＳＧＳＮ１０９は、ソースＲＮＣ１０４にメッセージＲｅｌｏｃａｔｉｏｎ　Ｃｏｍｍａｎｄ１１０６を送信する。ソースＲＮＣ１０４は、メッセージＨＯ　ｆｒｏｍ　ＵＴＲＡＮ　Ｃｏｍｍａｎｄ　１１０８によって、ターゲットｅＮＢ１１２にハンドオーバするようにＵＥ１０１に命じる。
　発明の詳細な説明には，ソースＲＮＣが，第２ユーザプレーン接続を開始する前に，ユーザ機器とのデータ通信でユーザ機器から遠隔サーバに要求を中継することにより，第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止させるものは記載されていない。
　図８，図９，図１１及びその説明等の記載によれば，第２ユーザプレーン接続は，ソースＲＮＣ１０４が，あるＵＥについてある期間内に所定の閾値を超えるデータ量があることをトリガとして（摘記　ア　参照），当該ＵＥがＵＴＲＡＮからｅＵＴＲＡＮに移動させられるべきと判定し（摘記　イ及びエ参照），ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｉｒｅｄメッセージを送信し，ソースＳＧＳＮからＲｅｌｏｃａｔｉｏｎ　Ｃｏｍｍａｎｄを受信し，当該ＵＥに対してメッセージＨＯ　ｆｒｏｍ　ＵＴＲＡＮ　Ｃｏｍｍａｎｄを送信することにより，開始されると認められる（摘記　オ　参照）。
　そうすると，「前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」するためには，ＵＥはソースＲＮＣからＨＯ　ｆｒｏｍ　ＵＴＲＡＮ　Ｃｏｍｍａｎｄを受信する前に遠隔サーバに要求を送信する必要がある。
　一方，摘記　イ及びウの記載によれば，ユーザ機器へのデータの送信を停止するための要求として遠隔サーバに送信される停止メッセージがＵＥによって十分に前に送信されるための好適なトリガとして，「ＨＳＰＡもしくはＬＴＥにおけるモビリティイベント（ｍｏｂｉｌｉｔｙ　ｅｖｅｎｔ）」，「モビリティイベントにつながるイベント」が例示されているのみであるが，モビリティイベント及びモビリティイベントにつながるイベントが具体的に開示されていない。また，第２ユーザプレーン接続を開始するトリガである「あるＵＥについてある期間内に所定の閾値を超えるデータ量があること」は，モビリティ（移動）とは無関係であるから，例示された上記好適なトリガであるモビリティイベント又はモビリティイベントにつながるイベントによりＵＥが停止メッセージを送信したとしても，当該送信は必ずしも「第２ユーザプレーン接続を開始する前」であるとはいえない。
　また，ユーザ機器から遠隔サーバへの要求は，ソースＲＮＣが制御し得るものではなく，ソースＲＮＣはユーザ機器と遠隔サーバとの間の間のデータ通信を単に中継するだけであって中継するデータ通信の内容を理解するものではないから，必ず「第２ユーザプレーン接続を開始する前に，ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継」することは，ソースＲＮＣにはできないはずである。
　してみると，発明の詳細な説明には，「前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止すること」を含むハンドオーバ手続について，当業者が発明を実施できる程度に明確かつ十分に記載されているとはいえない。
　請求人は，意見書において「「前記ハンドオーバ手続が，前記第２ユーザプレーン接続を開始する前に，前記ユーザ機器とのデータ通信で前記ユーザ機器から遠隔サーバに要求を中継して，前記第１ユーザプレーン接続を介した前記ユーザ機器へのデータの送信を停止することを含み，前記要求が，受信ウィンドウサイズに対応するメッセージを含む」との記載は，出願当初の請求項１１，１２の記載，および，段落［００７４］の記載（すなわち，「たとえば，ＵＥ１０１が，ＨＳＰＡによって遠隔サーバ１２０にデータを転送している。次に，ステップ９０４において，ＵＥ１０１が，ＵＥ１０１へのデータの送信を停止するように遠隔サーバに要求するために遠隔サーバに停止メッセージを送信する。」，「ステップ９０８において，ハンドオーバが，ＵＥ１０１をＵＴＲＡＮからｅＵＴＲＡＮに移動させ始める可能性がある。」との記載から，本願の要求中継（ステップ９０４に対応する）はハンドオーバ交渉を行う（ステップ９０８に対応する）ことの前に実行されると解釈しています。）に基づいたものです。」と主張する。
　しかしながら，発明の詳細な説明の段落［００７４］におけるステップ９０４のＵＥ１０１による停止メッセージの送信は，ＵＥ１０１が好適なトリガであるモビリティイベント及びモビリティイベントにつながるイベントに基づいて能動的に行われるものであり，ステップ９０６は，ステップ９０４において行われた停止メッセージに対して，遠隔サーバがパケットの送信を停止するものである。
　一方，ステップ９０２において行われる「あるＵＥについてある期間内に所定の閾値を超えるデータ量がある」というトリガ条件に基づいてソースＲＮＣが判定すること，ステップ９０８において行われるハンドオーバの処理はソースＲＮＣが能動的に実施していることは明らかであるが，当該判定，及びハンドオーバの処理は，上述したように好適なトリガであるモビリティイベント及びモビリティイベントにつながるイベントとは無関係であり，また，ＵＥ１０１で行われるステップ９０４，ステップ９０６がソースＲＮＣで行われるステップ９０２とステップ９０８の間に必ず実施されることを読み取ることのできる記載は見当たらない。よって，上記主張は採用できない。
　したがって，上記補正に係る請求項１１の記載は，特許法第３６条第４項第１号に規定する要件を満たしていない。
２　当審拒絶理由通知の概要の２．［理由５（進歩性）について］
（１）本願発明
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成３０年１１月２０日に提出された手続補正書により補正された特許請求の範囲の請求項１に記載されたとおりの
「ワイヤレス通信の方法であって，
　第１無線アクセスネットワークの第１ユーザプレーン接続を介して，ユーザ機器のためにネットワークコントローラでデータを転送するステップ（１０２）と，
　前記第１ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に，前記ユーザ機器を第２無線アクセスネットワークの第２ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップ（１１０）と
を有し，
　前記第１ユーザプレーン接続を介して転送されるデータの量が所定期間中に第１閾値を超える場合に，前記トリガ条件が満たされ，
　前記ハンドオーバ手続を開始した後，戻る条件が満たされる場合に，前記第１無線アクセスネットワークに戻るステップをさらに有し，前記戻る条件は，前記第２無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む，方法。」
と認める。
（２）引用発明及び周知技術
［引用発明］
　当審拒絶理由に引用された国際公開第２００４／０２３７４１号（以下，「引用例」という。）には，以下の事項が記載されている。
ア　「
ユーザが持つ各移動端末１０は，
イ　「以下に，本実施例の通信シーケンスについて図２乃至図８と共に説明する。尚，
図２のおいて実線は従来のＵＴＲＡＮ経由での信号伝送の流れを示し，破線は無線ＬＡＮ経由での信号の流れを示す。又，上記３ＧＰＰで規定されている装置名称に従い，前述の移動端末１０を『ＭＳ』，基地局制御装置３０を『ＲＮＣ』，無線基地局２０を『ノードＢ』，基地局制御装置３０に接続されるコアネットワーク側装置４０の総称を『ＣＮ』と称する。
　図２において，ステップＳ１にて，ＭＳ１０でのデータ受信の際，ＲＮＣ３０とＭＳ１０との間で制御信号路確立の為のＲＲＣコネクション設定手順が実行される。尚，これは従来のＵＭＴＳ，即ち欧州電気通信標準化協会が定める第３世代移動通信システム「ＩＭＴ２０００」の欧州規格で定義されている処理であり，本手順は３ＧＰＰ仕様書ＴＳ２５．３３１で規定されている。
　引き続き，ステップＳ２にて，ユーザデータ伝送路設定の為のＰＤＰコンテキスト処理手順が実行される。本処理手順の詳細は図３に示すとおりであり，これも上記ＵＭＴＳで定義された処理であり，本手順は３ＧＰＰ仕様書ＴＳ２３．０６０で規定されている。本実施例では，当該手順で規定されているコンテキスト情報として新たに上記『無線ＬＡＮ希望パラメータ』を付加する（図３のステップＳ３１）。
このＰＤＰコンテキスト処理手順が実行されることにより，ユーザデータを運ぶためにＲＮＣ３０−ＣＮ４０間にＧＴＰと呼ばれるパイプが確立される。
　尚，この処理手順の中でＣＮ４０からＲＮＣ３０に送られるものとして規定されているＲＡＢアサイメント・リクエスト（ステップＳ３２）の情報要素の１つとして『無線ＬＡＮ希望パラメータ』を追加することで，本パラメータ情報がＲＮＣ３０に届けられ，そこでコンテキスト情報要素の１つとして格納される（ステップＳ３３）と共に，
ＲＮＣ３０とＭＳ１０との間のユーザデータ伝送路として，割当無線伝送路（Ｒａｄｉｏ　Ｂｅａｒｅｒ）が確立される（ステップＳ３４）。
　次にステップＳ３にて，上記の如く
確立されたＧＴＰと割当無線伝送路（Ｒａｄｉｏ　Ｂｅａｒｅｒ）とを使用して従来のＵＴＲＡＮ経路（ノードＢＧ２０経由）でのユーザデータ伝送が行なわれる。この際，ＲＮＣ３０の上記ユーザデータ転送部が，ＣＮ４０から受信したユーザデータを，ＵＴＲＡＮ経路へ送出することで，ＭＳ１０へのユーザデータ伝送が実現される。
（１４ページ１８行目〜１５ページ１８行目）
ウ　ステップＳ４で
ＲＮＣ３０はＭＳ１０が受信しているデータの量（トラヒック）の監視を行う。
　次に，ステップＳ５では，
ＲＮＣ３０は上記処理によって得られたデータ量（トラヒック）が，予め定められた所定の閾値を超えたか否かの判断を継続的に行なう。
エ　「又，ＲＮＣ３０は上記移動端末情報対応表を作成し管理する（ステップＳ１４）。この移動端末情報対応表は，例えば図６Ｂに示す構成を有し，『移動端末識別子（ＭＳのＩＤ）』，『テンポラリＩＰアドレス』，『割当無線伝送路（Ｒａｄｉｏ　Ｂｅａｒｅｒ）』，『ＧＴＰ』，『コンテキスト（無線ＬＡＮ希望）』，及び『閾値』が含まれる。
　ステップＳ１５にて
ＲＮＣ３０は上記ステップＳ１４で作成された移動端末情報対応表に基づき，データ転送経路を無線ＬＡＮ経路へ切り替える必要が有るか否かを判断する。
移動端末宛のデータ通信量が上記閾値を超えた場合に，当該移動端末１０について上記ＲＮＣ３０の制御部が経路切り替え必要と判断し，ＲＮＣ３０のユーザデータ転送部に対して，無線ＬＡＮ経路への切替を指示する。
　この場合ステップＳ１６にて，
ＲＮＣ３０のユーザデータ転送部は
無線ＬＡＮのエアステーション５０によるデータ伝送路を使用した経路へとユーザデータ転送経路が切り替えられる。以上の手順により，図８に示す如く，ユーザデータは無線ＬＡＮ経路で当該ＭＳ１０へと転送される。
オ　「ステップＳ１７にて、
ＲＮＣ３０はステップＳ４にて開始したデータ量（トラヒック）の監視を継続しており、データ量（トラヒック）がステップＳ５に記載の閾値を下回ったか否かを判断する。そして、ステップＳ１８にて、ＲＮＣ３０はでデータ量が閾値を下回ったことを検出した場合、ユーザデータ通信経路を、ステップＳ１６で保持した割当無線伝送路（Ｒａｄｉｏ　Ｂｅａｒｅｒ）経由の経路に切り戻す。
　引用例の上記記載及びこの分野における技術常識を考慮すると，次のことがいえる。
（ア）上記イの記載によれば，コアネットワーク装置と基地局制御装置（ＲＮＣ）（以下，「ＲＮＣ」と言う。）間にＧＴＰとよばれるパイプが確立され，ＲＮＣと移動端末との間のユーザデータ伝送路として，割当無線伝送路（Ｒａｄｉｏ　Ｂｅａｒｅｒ）が確立され，確立されたＧＴＰと割当無線伝送路とを使用して，ＲＮＣのユーザデータ転送部が，コアネットワーク装置から受信したデータを移動端末へ送出するものである。
　したがって，引用例には，「ＲＮＣと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して，ＲＮＣがコアネットワーク装置から受信したユーザデータを移動端末へ転送するステップ」が記載されているといえる。
（イ）上記ウ，エの記載によれば，ＲＮＣは移動端末が受信しているデータの量（トラヒック）の監視をして予め定められた所定の閾値を超えたか否かの判断を継続的に行い，移動端末宛てのデータ通信量が閾値を超えた場合に，移動端末についてＲＮＣの制御部が経路切り替えが必要と判断し，ＲＮＣのユーザデータ転送部に対して，無線ＬＡＮ経路への切替を指示し，ＲＮＣのユーザデータ転送部はユーザデータを無線ＬＡＮ経由で移動端末に送信するものである。
　したがって，引用例には，「転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に，ＲＮＣの制御部は移動端末を割当無線伝送路から無線ＬＡＮ経路へ切り替えるため通信経路の切替をＲＮＣのユーザデータ転送部に指示するステップ」が記載されているといえる。
（ウ）上記オの記載によれば，経路を無線ＬＡＮ経路とした後，ＲＮＣはデータ通信量の監視を継続して行い，データ通信量（トラフィック）が閾値を下回ったか否かを判断し，データ量が閾値を下回った場合，ユーザデータ通信経路を割当無線伝送路経由に切り戻すから，データ通信量は経時的に変化するものであることは明らかである。してみると，当該データ通信量とは，データ通信が行われた総量ではなく，所定の期間中のデータ通信量であるといえる。
　したがって，引用例には，「ＲＮＣは，所定期間中のデータ通信量が閾値を超える場合に，通信経路を切り替える」ものが記載されているといえる。
（エ）そして，上記（ア）（イ）（ウ）に記載される，割当無線伝送路及び無線ＬＡＮ経路を用いた移動端末とのそれぞれのデータ通信は，いずれもワイヤレス通信であると言え，ＲＮＣがデータ通信量によって，割当無線伝送路と無線ＬＡＮ経路を切り替える方法が記載されているといえるから，引用例には，「ワイヤレス通信の方法」が記載されているといえる。
　以上を総合すると，引用例には，以下の発明（以下，「引用発明」という。）が記載されていると認められる。
「ワイヤレス通信の方法であって，
ＲＮＣと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して，ＲＮＣがコアネットワーク装置から受信したユーザデータを移動端末へ転送するステップと，
転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に，ＲＮＣの制御部は移動端末を割当無線伝送路から無線ＬＡＮ経路へ切り替えるため通信経路の切替をＲＮＣのユーザデータ転送部に指示するステップと
を有し，
ＲＮＣは，所定期間中のデータ通信量が閾値を超える場合に，通信経路を切り替える，
方法。」
［周知技術］
　本件の優先日前に公開された，ＮＴＴドコモ，ＮＴＴ　ＤｏＣｏＭｏテクニカルジャーナル　ＶＯＬ．１４　ＮＯ．３，ＨＳＤＰＡ特集　ＨＳＤＰＡ移動端末の開発および無線伝送特性，２００６年６月掲載，ｈｔｔｐｓ：／／ｗｗｗ．ｎｔｔｄｏｃｏｍｏ．ｃｏ．ｊｐ／ｃｏｒｐｏｒａｔｅ／ｔｅｃｈｎｏｌｏｇｙ／ｒｄ／ｔｅｃｈｎｉｃａｌ＿ｊｏｕｒｎａｌ／ｂｎ／ｖｏｌ１４＿３／ｖｏｌ１４＿３＿０１４ｊｐ．ｐｄｆ（以下，「周知例１」という。）には以下の事項が記載されている。　
カ　「４．１　ＨＳＤＰＡにおけるハンドオーバ
（略）
以下にＨＳＤＰＡにおけるハンドオーバ手順を示す。
▲１▼
移動端末にて周辺セルから固定電力で送信されている共通パイロットチャネル（ＣＰＩＣＨ：ｃｏｍｍｏｎ　ＰＩｌｏｔ　ＣＨａｎｎｅｌ）の品質レベル測定を行う
▲２▼ハンドオーバ元セルのＣＰＩＣＨ品質レベルに対し，
一定のしきい値（ネットワークより通知されるパラメータ）を超える品質レベルのＣＰＩＣＨが存在した場合，無線ネットワーク制御装置（ＲＮＣ：Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌｌｅｒ）へ当該セルの報告を行う（しきい値を超えるセルが複数存在した場合は，その中で最も品質レベルの高いセルを報告する）
▲３▼
ＲＮＣは移動端末からの報告を基にハンドオーバ先セルの設定を行い，移動端末へのハンドオーバの通知を行う
▲４▼
ハンドオーバの通知を受けた移動端末は，
ハンドオーバ先セルとの接続を行う
　本件の優先日前に公開された，国際公開第２００９／０６６６２２号（以下，「周知例２」という。）には以下の事項が記載されている。
キ　「【００３０】
　移動局３において，システムＡの周波数ＲＦ２での通信品質が低下すると，例えば異周波数ＲＦ１の通信品質の測定を開始し，
異周波数ＲＦ１の通信品質が所定の閾値を超え
もとの周波数ＲＦ２の通信品質が所定値以下となるか
異周波数ＲＦ１への切替え（異周波数ハンドオーバ）を行う。
　本件の優先日前に公開された，特開２００９−４９５４５号（以下，「周知例３」という。）には以下の事項が記載されている。
ク　「【０００２】
　無線ＬＡＮ等の移動体通信システムにおいては、
無線端末が帰属する無線基地局からの信号強度が、無線端末に予め設定された所定の閾値（以下、「ハンドオーバ閾値」と呼ぶ）より下回った場合に、より電波状態の良い他の無線基地局へ帰属替え（以下、「ハンドオーバ」と呼ぶ）を行うのが一般的である。
　上記カ，キ，クの記載並びに当業者の技術常識を考慮すると，「ハンドオーバ手順（手続）では，帰属する基地局（ハンドオーバ元）の通信品質が所定の値以下になり，ハンドオーバ先セル（ネットワーク）の通信品質がしきい値を超える場合に，ハンドオーバ先のセル（ネットワーク）に接続を行う。」ことは，周知技術であるといえる。
（３）対比・判断
　本願発明と引用発明とを対比すると，以下のことがいえる。
ア　引用発明の「移動端末」はユーザが持ち利用する端末であるから「ユーザ端末」と言え，「割当無線伝送路」は「無線アクセスネットワーク」に含まれ，「ユーザデータ」は「データ」に含まれる。また，ＲＮＣは当該技術分野においてラジオネットワークコントローラを表すものであるから，「ネットワークコントローラ」に含まれる。そして，「割当無線伝送路」は「ＲＮＣと移動端末との間のユーザデータ伝送路」であるから「ユーザプレーン接続」といえ，これを「第１ユーザプレーン接続」と称することは任意である。
　したがって，引用発明の「ＲＮＣと移動端末との間のユーザデータ伝送路である割当無線伝送路を介して，移動端末のためにＲＮＣでユーザデータを転送するステップ」は，「第１無線アクセスネットワークの第１ユーザプレーン接続を介して，ユーザ機器のためにネットワークコントローラでデータを転送するステップ」といえる点で本願発明と共通している。
イ　引用発明のＲＮＣの制御部が，「割当無線伝送路から無線ＬＡＮ経路へ切り替えるため通信経路の切替をＲＮＣのユーザデータ転送部に指示」することは，「ハンドオーバ手続を開始する」ことに含まれる。また，「無線ＬＡＮ経路」は「無線アクセスネットワーク」に含まれ，引用発明の「無線ＬＡＮ経路」を介してユーザ端末のためにユーザデータを転送するものであるから，引用発明の「無線ＬＡＮ経路」は「ユーザプレーン接続」といえ，これを「第２ユーザプレーン接続」と称することは任意である。そして，当該「ハンドオーバ手続の開始」は，ユーザデータのデータ通信量が「閾値を超えた」場合であるから，当該「閾値」は「ハンドオーバ手続の開始」の「トリガ条件」であるといえ，「閾値を超える」ことは，「トリガ条件が満たされる」ことに相当する。また，「割当無線伝送路から無線ＬＡＮ経路への切り替え」は「割当無線伝送路から無線ＬＡＮ経路への移行」ともいえる。
　そうすると，引用発明の「転送される移動端末宛のユーザデータのデータ通信量が閾値を超えた場合に，ＲＮＣの制御部は移動端末を割当無線伝送路から無線ＬＡＮ経路へ切り替えるため通信経路の切替えをＲＮＣのユーザデータ転送部に指示するステップ」は，「第１ユーザプレーン接続を介して転送されるデータの量がトリガ条件を満たされる場合に，ユーザ機器を（第１無線アクセスネットワークの第１ユーザプレーン接続から）第２無線アクセスネットワークの第２ユーザプレーン接続への移行させるハンドオーバ手続を開始するステップ」といえる点で本願発明と共通している。
ウ　引用発明の「通信経路の切り替え（ハンドオーバ手続の開始）」は，上記イで記載したとおり，「トリガ条件が満たされる」ことによって行われるものである。そうすると，引用発明の「ＲＮＣは，所定期間中のデータ通信量が閾値を超える場合に，通信経路を切り替える」ことは，本願発明の「（ＲＮＣは）第１ユーザプレーン接続を介して転送されるデータの量が所定の期間中に閾値を超える場合に，トリガ条件が満たされたと判断する」ことに相当する。
　
　以上を総合すると，補正後の発明と引用発明とは，以下の点で一致し，また，相違している。
（一致点）
「ワイヤレス通信の方法であって，
　第１無線アクセスネットワークの第１ユーザプレーン接続を介して，ユーザ機器のためにネットワークコントローラでデータを転送するステップと，
　前記第１ユーザプレーン接続を介して転送される前記データがトリガ条件を満たす場合に，前記ユーザ機器を第２無線アクセスネットワークの第２ユーザプレーン接続に移行させるハンドオーバ手続を開始するステップと
を有し，
　前記第１ユーザプレーン接続を介して転送されるデータの量が所定期間中に第１閾値を超える場合に，前記トリガ条件が満たされたと判断する，
方法。」
（相違点）　
　本願発明は，「前記ハンドオーバ手続を開始した後，戻る条件が満たされる場合に，前記第１無線アクセスネットワークに戻るステップをさらに有し，前記戻る条件は，前記第２無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む，」との発明特定事項を有するのに対し，引用発明は当該発明特定事項を有していない点。
　以下，上記相違点について検討する。
　本願発明における「ハンドオーバ手続を開始した後」とは，第１ユーザプレーン接続を介して転送されるデータの量が所定期間中に第１閾値を超えた後の期間をすべて含むものである。また，発明の詳細な説明の段落［００７１］を参照すると，本願発明における「品質」とは，信号品質（例えば基準信号受信品質），すなわち通信品質を含むものである。
　そして，上記「（２）引用発明及び周知技術」の項の「［周知技術］」にて述べたとおり，「ハンドオーバ手順（手続）では，帰属する基地局（ハンドオーバ元）の通信品質が所定の値以下になり，ハンドオーバ先セル（ネットワーク）の通信品質がしきい値を超える場合に，ハンドオーバ先のセル（ネットワーク）に接続を行う。」ことは周知であり，当該周知技術は，言い換えれば「ハンドオーバ手順（手続）では，ハンドオーバ先セル（ネットワーク）の通信品質がしきい値を超えない場合，ハンドオーバ先のセル（ネットワーク）との接続を行わない。」といえる。そうすると，第１ユーザプレーン接続を介して転送されるデータの量が所定期間中に第１閾値を超えた後，ハンドオーバ先セル（ネットワーク）の品質がしきい値を超えない場合，ハンドオーバ先のセルとの接続を行わない，すなわち「ハンドオーバ手続を開始した後，戻る条件が満たされる場合に，前記第１無線アクセスネットワークに戻るステップをさらに有し，前記戻る条件は，前記第２無線アクセスネットワークのカバレッジ又は品質が特定の閾値未満であることを含む，」とすることは当業者において周知技術から容易に想到し得るものである。
　そして，本願発明の作用効果も，引用発明及び周知技術に基づいて当業者が予測できる範囲のものにすぎず，格別顕著なものとはいえない。
　したがって，本願発明は，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
第５　むすび
　以上のとおり，本願は，発明の詳細な説明の記載が特許法３６条４項１号に規定する要件を満たしておらず，特許請求の範囲の記載が同条６項１号，同条６項２号に規定する要件を満たしていないから，拒絶すべきものである。
　また，本願発明は，引用発明に及び周知技術に基づいて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない。
　したがって，他の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。