ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 5項独立特許用件 特許、登録しない。 H04Q 審判 査定不服 2項進歩性 特許、登録しない。 H04Q |
|---|---|
| 管理番号 | 1337565 |
| 審判番号 | 不服2016-16326 |
| 総通号数 | 220 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2018-04-27 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2016-11-01 |
| 確定日 | 2018-02-15 |
| 事件の表示 | 特願2012- 95980「移動端末及び通信方法」拒絶査定不服審判事件〔平成25年10月31日出願公開、特開2013-225721〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、平成24年4月19日の出願であって、平成27年12月9日付けで拒絶理由が通知され、平成28年2月12日に意見書及び手続補正書が提出され、同年7月28日付けで拒絶査定されたところ、同年11月1日に拒絶査定不服審判が請求され、同時に手続補正されたものである。 第2 補正の却下の決定 [補正の却下の決定の結論] 平成28年11月1日付けの手続補正を却下する。 [理由] 1.本願発明と補正後の発明 平成28年11月1日付けの手続補正(以下、「本件補正」という。)は、平成28年2月12日に提出された手続補正書の特許請求の範囲の請求項8に記載された、 「 【請求項8】 外部との無線通信が可能な移動端末が行う通信方法であって、 前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号を前記移動端末が受信する通信ステップと、 前記通信ステップにより前記通知信号が受信された場合に、且つ、所定条件が満たされた場合に、前記セッションを開放せず維持するための維持処理を前記移動端末が実行する管理ステップと、を有することを特徴とする通信方法。」 という発明(以下、「本願発明」という。)を、本件補正に係る手続補正書の特許請求の範囲の請求項7に記載された、 「 【請求項7】 外部との無線通信が可能な移動端末が行う通信方法であって、 前記無線通信が不可能な圏外状態であるか否かを前記移動端末が判定する判定ステップと、 前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号を前記移動端末内部のソフトウェアプログラムから受信する通信ステップと、 前記通信ステップにて前記通知信号が受信された場合において、前記判定ステップにて前記圏外状態であると判定されたことを通知する前記通知信号が前記通信ステップにて受信された後、所定時間経過後に、前記圏外状態以外の通信状態の変更を通知する前記通知信号が前記通信ステップにて受信された、との所定条件が満たされた場合に、前記セッションを開放せず維持するための維持処理を前記移動端末が実行する管理ステップと、を有することを特徴とする通信方法。」(下線は、補正箇所を示す。) という発明(以下、「補正後の発明」という。)に補正することを含むものである。 2.補正の適否 (1)新規事項の有無、補正の目的要件、シフト補正の有無 上記補正の内容は、以下のとおりである。 (補正事項1)「前記無線通信が不可能な圏外状態であるか否かを前記移動端末が判定する判定ステップ」を新たに追加する補正。 (補正事項2)「通信状態の変更を通知する通知信号」が「前記移動端末内部のソフトウェアプログラムから」受信されることを特定する補正。 (補正事項3)「所定条件」が「前記判定ステップにて前記圏外状態であると判定されたことを通知する前記通知信号が前記通信ステップにて受信された後、所定時間経過後に、前記圏外状態以外の通信状態の変更を通知する前記通知信号が前記通信ステップにて受信された」という条件であることを限定する補正。 そこで、各補正事項について検討すると、 (補正事項1)?(補正事項3)の内容は、願書に最初に添付した明細書(以下「当初明細書等」という。)に記載された事項であり、(補正事項2)及び(補正事項3)の目的は、特許請求の範囲の減縮に該当する。 しかしながら、(補正事項1)の目的は、本件補正前の請求項8の発明特定事項を更に限定していないから、特許請求の範囲の減縮に該当せず、また、請求項の削除、誤記の訂正、及び明りょうでない記載の釈明の何れにも該当しないことは明らかである。 したがって、上記補正は、特許法第17条の2第3項(新規事項)、同条第4項(シフト補正)の規定には違反しないが、同条第5項(目的要件)の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 (2)独立特許要件 上記(1)において判断したように、本件補正は却下すべきものであるが、更に進んで、仮に上記補正が、特許請求の範囲の減縮を目的とするものであるとして、補正後の発明が特許出願の際に独立して特許を受けることができるものであるのかどうかについて、以下に検討する。 [補正後の発明] 上記「1.本願発明と補正後の発明」の項において、「補正後の発明」として認定したとおりである。 [引用発明] 原査定の拒絶の理由に引用された、特表2006-527527号公報(以下、「引用例」という。)には、次の事項が記載されている。 あ.「【技術分野】 【0001】 本出願は、複数のシステムにおける無線通信のためのコンポーネントおよび方法に関し、より詳細には、ユニバーサル移動体通信システム(ユニバーサル・モバイル・テレコミュニュケーション・システム)(UMTS)から無線ローカルエリアネットワーク(無線LAN)(WLAN)へ、またはその逆へのように、第1の種類の無線システムを用いた無線接続から第2の種類の無線システムを用いた無線接続への切替をしながらの連続通信が可能な移動体無線送受信装置(WTRU)に関する。」 い.「【0016】 1つまたは複数のWLANアクセスポイント(AP)、すなわち基地局を伴った、普及している無線ローカルエリアネットワーク環境は、IEEE802.11b標準に従って構築される。このようなWLANの無線サービスエリアは、「ホットスポット」と呼ばれる指定された明確な地理的エリアに限定されることがある。このような無線通信システムは、空港、喫茶店、およびホテルのようなエリアに配備するのに有利である。これらのネットワークへのアクセスは通常、ユーザ認証手続きを要求する。IEEE802ファミリの標準は発展途中なので、このようなシステムのプロトコルは、WLAN技術分野ではまだ完全には標準化されていない。しかし、上記のように、UMTSネットワークのCNは、WLANのような他のネットワークとの通信を容易にするために設計されている。 【発明の開示】 【発明が解決しようとする課題】 【0017】 それぞれ異なる環境で異なるWTRUを使用する代わりに、WTRUは、UMTSおよびWLAN PCMCIAのカードアダプタを個々に備えたポケットPCのように、UMTSおよびWLANの両方の機能を備えることができる。個々のカードコンポーネントにより、ユーザは単一の装置で複数種類のネットワークを使用できるが、これは、接続を切らずに一方の種類のネットワークから他方へ切替可能なWTRUを提供するものではない。例えば、ターゲットWTRUと通信中または通信しようとしているモバイルWTRUが信号品質の低いエリア内に移動し、そこでは当該ターゲットWTRUにサービスを提供する特定種類のネットワークとの通信が散発的であるかまたは存在しない場合がある。このような場合、WTRUが、同じ種類のネットワーク内でローミングできるだけでなく、継続して通信セッションを維持する別の種類のネットワークに切り替えることができれば望ましい。」 う.「【0037】 例えば、WTRU10がインタフェース22経由でUMTS無線通信を実行しており、WLANサービスエリア内に移動する場合、通信セッションは、好ましくは、以下のようにWTRUスタンドアロンモードで、インタフェース24経由で、WLAN無線通信に切り替えられる。プロトコルエンジン20が、APP30によって受信されて評価されたリンクステータス情報を提供し、WLAN無線通信に切り替えるかどうかが判断される。この判断は、既存のUMTSのサービス品質(QｏS)や、本発明の譲受人を権利者とする米国特許出願第10/667、633号に開示されているような他の要因に基づくことができる。APP30が、進行中のUMTS通信セッションをWLANにハンドオーバすべきと判断した後、APP30は、ハンドオフの準備をするようCOM32に通知し、COM32は、無線伝送のために上位層アプリケーション処理コンポーネント26によって生成されているすべての通信データのバッファリングを開始する。したがって、処理コンポーネント26は、中断なしで通信セッションのためのユーザデータの生成を継続する。APP30は、ハンドオフが進行中であることを上位層アプリケーション処理コンポーネント26に通知することにより、ハンドオフが完了するまで無線データを受信する際の遅延を予想することができるようにする。そして、APP30は、プロトコルエンジン20に対して、UMTS通信セッションの引き継ぎ先となるインタフェース24経由で無線WLANコネクションを確立するよう指示する。 【0038】 WLANコネクションが確立されると、プロトコルエンジン20はAPP30に通知する。すると、APP30がCOM32にハンドオフ完了を通知する。そして、COM32は、UMTSインタフェース22からWLANインタフェース24にユーザ通信データの方向を切り替え、バッファリングされたデータをWLANインタフェースに解放することにより、通信セッションを更新し継続する。また、APPは上位層アプリケーション処理コンポーネント26にもハンドオフ完了を通知することにより、通信セッションのための双方向ユーザデータがCOM32およびWLANインタフェース24経由で移動し続ける。最後に、APP30は、UMTSインタフェースにUMTSコネクションを解放させるよう、プロトコルエンジンに通知する。 【0039】 動作を向上させるため、対応するAPPおよびCOMのコンポーネントを、WTRU10が通信しているネットワークに設けることができる。図2bは、種々のコンポーネントの配置の概略図である。UMTSシステムとWLANシステムの間のインタフェースをとるネットワークシステムは、通常、インターネットプロトコル(IP)を用いるもののようなパケット交換(PS)データフローに基づく。図2bは、パケット交換IPセッションのネットワークハンドオフを可能にするように構成されたWTRUを示している。CS音声信号データは、UMTSインタフェースからAPPを通ることができるが、音声通信は、音声データがパケットとして処理されるボイスオーバーIPプロトコルを用いて、WLANおよびUMTSの両方で実施可能である。 【0040】 図2bに表されているように、WTRU10のAPP30は、上位層とCOM32の間で無線インタフェース22、24を用いたシグナリングを仲介する。WTRU10は、COM32を通じて無線インタフェース22、24との間でPSデータを受け渡しするように構成される。好ましくは、図2bに示されているように、WTRUの通信相手であるUMTSシステムおよびWLANシステムは、それぞれUTRANおよびAPを有し、これらはそれぞれの物理層エアインタフェースの上に実現された対応する通信ブローカーを用いて構成される。好ましくは、対応するアプリケーションブローカーが、ネットワークシステムのIPノードに設けられる。ネットワーク側のAPPおよびCOMは、ネットワーク間ハンドオーバに対するネットワークサポートを提供する。」 上記摘記事項並びにこの分野における技術常識を考慮すると、 a.上記あ.及びう.によれば、WTRU10はUMTS無線通信やWLANによって外部との通信を行っていることは明らかであるから、引用例は外部との通信を行うWTRUが行う通信方法であるということができる。 b.上記う.の【0037】によれば、リンクステータス情報をプロトコルエンジン20が提供し、APP30がWLAN無線通信に切り替えるかどうかを判断している。そうしてみると、リンクステータス情報をプロトコルエンジン20から受信するステップを、WTRUが有しているということができる。 c.上記う.の【0037】及び【0038】によれば、APP30がリンクステータス情報を受信してUMTSからWLANにハンドオーバすべきと判断し、その後APP30からの通知により、通信セッションをUMTS無線通信からWLANへ更新し継続することが記載されている。 したがって、引用例には次のような発明(以下、「引用発明」という。)が記載されているものと認められる。 (引用発明) 「 外部との通信を行うWTRUが行う通信方法であって、 リンクステータス情報をプロトコルエンジン20から受信するステップと、 APP30がリンクステータス情報を受信してUMTSからWLANにハンドオーバすべきと判断し、通信セッションをUMTS無線通信からWLANへ更新し継続するステップ、を有する通信方法。」 [公知技術] 原査定の拒絶の理由に引用された、特開2011-211591号公報(以下、「公知例」という。)には、次の事項が記載されている。 「【0027】 図3に戻り、動作管理部106は、動作管理情報を保持する。動作管理情報には、端末1が無線基地局5からの電波を捕捉できない状態、例えば圏外状態になったとき、論理的な接続を維持するか否かの情報及び接続を維持する時間がアプリケーション毎に保持される。論理的な接続は、例えばアプリケーションのセッション接続がある。 【0028】 図5は、動作管理情報の一例を示す図である。図5に示す動作管理情報は、アプリケーション名に対して、圏外時に行う動作を示す圏外動作、ドーマント制御を行う時間を示す接続維持時間が対応付けられる。図5に示す例では、「Webブラウザ」に「接続切断」が対応付けられ、「FTP」に「接続維持」及び「30ｓec」が対応付けられる。アプリケーション「Webブラウザ」は、圏外時には「接続切断」することを示す。アプリケーション「FTP」は、圏外時には「接続維持」が「30ｓec」時間行われることを示す。」 上記摘記事項によれば、無線基地局と通信する端末が、圏外状態になったとき所定時間、例えばアプリケーションのセッション接続のような論理的な接続を維持し、所定時間内に圏内状態になればそのまま接続が維持されるから、上記公知例には以下のような技術(以下、「公知技術」という。)が記載されているものと認められる。 (公知技術) 「無線基地局と通信する端末が、圏外状態になったとき所定時間、例えばアプリケーションのセッション接続のような論理的な接続を維持し、圏内状態になればそのまま接続を維持する。」 [対比] 補正後の発明を引用発明と対比すると、 a.引用発明において、外部との通信を行っている「WTRU」は、補正後の発明の「移動端末」に相当する。 b.引用発明における「リンクステータス情報」は、通信状態の変化に起因して通信システムを変更するトリガとして使われる信号であり、通信状態の変化を表しているということができるから、補正後の発明の「前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号」に相当する。 また、引用発明の「プロトコルエンジン20」はWTRU内の構成であるから、引用発明においてはリンクステータス情報をWTRUの内部から受信しているということができる。 したがって両者は「前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号を前記移動端末内部から受信する通信ステップ」を有する点で共通している。 c.引用発明において「APP30がリンクステータス情報を受信」することが、補正後の発明の「前記通知信号が受信された場合」に対応する。また、引用発明の「UMTSからWLANにハンドオーバすべきと判断」されることが、補正後の発明の「所定条件が満たされた場合」に対応する。 引用発明では「通信セッションをUMTS無線通信からWLANへ更新し継続」しているが、これは引用例の上記摘記事項う.の記載をみれば上位層アプリケーションの動作を中断させることなく行われているから、補正後の発明と同様にセッションを開放せず維持しているということができる。 したがって、補正後の発明と引用発明とは以下の点で一致ないし相違する。 (一致点) 「 外部との無線通信が可能な移動端末が行う通信方法であって、 前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号を前記移動端末内部から受信する通信ステップと、 前記通信ステップにて前記通知信号が受信された場合において、所定条件が満たされた場合に、前記セッションを開放せず維持するための維持処理を前記移動端末が実行する管理ステップと、を有することを特徴とする通信方法。」 (相違点1) 補正後の発明は、「前記無線通信が不可能な圏外状態であるか否かを前記移動端末が判定する判定ステップ」を有しており、「所定条件」が「前記判定ステップにて前記圏外状態であると判定されたことを通知する前記通知信号が前記通信ステップにて受信された後、所定時間経過後に、前記圏外状態以外の通信状態の変更を通知する前記通知信号が前記通信ステップにて受信された、との所定条件」であるのに対して、引用発明では当該発明特定事項を有していない点。 (相違点2) 補正後の発明では「前記無線通信におけるセッションに関する通信状態の変更を通知する通知信号」を「ソフトウェアプログラムから受信」しているのに対して、引用発明は「プロトコルエンジン20から受信」している点。 [判断] 上記相違点1について検討する。 引用発明は、上記摘記事項い.に記載されているように「モバイルWTRUが信号品質の低いエリア内に移動し、そこでは当該ターゲットWTRUにサービスを提供する特定種類のネットワークとの通信が散発的であるかまたは存在しない場合」が想定されており、このように通信が存在しない場合とは、圏外状態を含むと考えるのが自然である。そして、この分野では、動作にばたつきが生じないように時間をおくということが行われているところ、「無線基地局と通信する端末が、圏外状態になったとき所定時間、例えばアプリケーションのセッション接続のような論理的な接続を維持し、圏内状態になればそのまま接続を維持する」ことは公知技術であることに鑑みれば、「前記無線通信が不可能な圏外状態であるか否かを前記移動端末が判定する判定ステップ」を備え、所定条件を「前記判定ステップにて前記圏外状態であると判定されたことを通知する前記通知信号が前記通信ステップにて受信された後、所定時間経過後に、前記圏外状態以外の通信状態の変更を通知する前記通知信号が前記通信ステップにて受信された、との所定条件」とすることは格別困難なことではなく、当業者が適宜成し得ることである。 上記相違点2について検討する。 引用発明における「プロトコルエンジン20」はどのような構成を有するのか引用例に明示されていないが、通信処理を行う各層の処理をソフトウェアで行うことは常套手段にすぎないから、プロトコルエンジン20をソフトウェアプログラムで構成し、相違点2とした補正後の発明の構成とすることは適宜成し得た程度の事項にすぎない。 そして、補正後の発明が奏する効果も、引用発明及び公知技術から、容易に予測できる範囲内のものである。 よって、補正後の発明は、引用発明及び公知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定によって、特許出願の際、独立して特許を受けることができないものである。 3.結語 上記のとおり本件補正は特許法第17条の2第5項各号に規定された目的のいずれも目的としない補正を含むから、特許法第17条の2第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 また、仮に本件補正が目的要件違反ではなかったとしても、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第17条の2第6項において準用する同法第126条第7項の規定に適合していない。 したがって、本件補正は、特許法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3 本願発明について 1.本願発明 平成28年11月1日付けでされた手続補正は上記のとおり却下されたので、本願発明は上記「第2 補正の却下の決定」の項中の「1.本願発明と補正後の発明」の項で「本願発明」として認定したとおりのものである。 2.引用発明 引用発明は、上記「第2 補正の却下の決定」の項中の「(2)独立特許要件」の項で引用発明として認定したとおりである。 3.対比・判断 本願発明は補正後の発明から本件補正に係る限定を省いたものである。 そうしてみると、本願発明を引用発明と比較すると、上記「第2 補正の却下の決定」の項中の「(2)独立特許要件」の項で検討した相違点1?3に係る構成を本願発明は有さず、両者は実質的に同一であるといえる。 4.むすび 以上のとおり、本願発明は、引用発明と実質的に同一の発明であるから、特許法第29条第1項第3号の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2017-12-08 |
| 結審通知日 | 2017-12-12 |
| 審決日 | 2017-12-26 |
| 出願番号 | 特願2012-95980(P2012-95980) |
| 審決分類 |
P
1
8・
575-
Z
(H04Q)
P 1 8・ 121- Z (H04Q) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 東 昌秋 |
| 特許庁審判長 |
菅原 道晴 |
| 特許庁審判官 |
山本 章裕 古市 徹 |
| 発明の名称 | 移動端末及び通信方法 |
| 代理人 | 沖山 隆 |
| 代理人 | 長谷川 芳樹 |
| 代理人 | 深石 賢治 |
| 代理人 | 黒木 義樹 |