【事件の表示】
　特願２０１０−５１５０２０「無線通信ネットワークにおける常時接続型データ・セッションを維持する方法及び装置」拒絶査定不服審判事件〔平成２１年　１月　８日国際公開、ＷＯ２００９／００６０８０、平成２２年１０月２１日国内公表、特表２０１０−５３３３９５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯及び本願発明
　
１．手続の経緯
　本願は，２００８年(平成２０年)６月２３日(優先権主張　２００７年(平成１９年)６月２８日　米国，２００７年(平成１９年)７月３０日　米国)を国際出願日とする出願であって，平成２４年２月９日付けで拒絶理由が通知され，同年５月１１日付けで意見書とともに手続補正書の提出がなされ，同年６月１３日付けで拒絶査定され，同年１０月１９日に拒絶査定不服審判の請求がなされ，同年１１月２９日付けで手続補正書(審判請求の理由補充)の提出がなされたものである。
　
２．本願発明
　本願の請求項１に係る発明は，平成２４年５月１１日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
　
　　【請求項１】
　無線通信のための装置であって、
　第１のメッセージを第１の非トラヒック・チャネルでアクセス・ネットワークから受信し、第２のメッセージを第２の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成された少なくとも１つのプロセッサと、
　前記少なくとも１つのプロセッサに接続されたメモリとを備え、
　前記第１のメッセージ及び前記第２のメッセージは、データ・セッションをキープアライブするために交換される装置。
　
　
第２　引用発明
　
　原査定の理由に引用された米国特許出願公開第２００６／０００２３５８号明細書(ＵＳ２００６／０００２３５８，２００６年(平成１８年)１月５日米国公開。以下「引用例」という。)には，図面とともに次の事項が記載されている。
　
１．「[ABSTRACT]
The invention relates to a method for maintaining a Point-to-Point Protocol (PPP) connection between a Mobile Terminal (MT) and a Packet Data Serving Node (PDSN). Responsive to a detection at the PDSN that the PPP connection between the PDSN and the MT is inactive, the method sends a first Link Control Protocol (LCP) Echo Request, which including a Short Data Burst (SDB) parameter, wherein the SDB parameter indicates that the message is sent using SDB, from the PDSN to a Base Station Controller/Packet Control Function (BSC/PCF) for locating the MT. The method further determines on the reception of SDB parameter, not to setup a traffic channel (TCH) between the MT and a serving BS. Next, the method sends from the BSC/PCF to the BS a second LCP Echo Request, which includes a NO Traffic Channel (No TCH) parameter instructing not to setup a traffic channel for the MT.」(公報第１ページ右上欄)
(当審訳
[要約]
　本発明は，移動端末(MT)とパケットデータサービングノード(PDSN)間のポイントツーポイントプロトコル(PPP)接続を維持するための方法に関する。PDSNとMTとの間のPPP接続が非アクティブであるPDSNでの検出に応答し,
この方法は，第一のリンク制御プロトコル(LCP)エコー要求を送信する。
このLCPはショートデータバースト(SDB)のパラメータを含んでおり，
ここでこのSDBパラメータは，メッセージが，PDSNからMTの位置を特定するための基地局コントローラ/パケット制御機能(BSC/ PCF)に，SDBを使用して送信していることを示している。この方法はさらに，MTとサービングBSとの間でトラフィックチャネル(TCH)を設定しないSDBパラメータの受信についてを判定する。次に，この方法は，第二LCPエコー要求を，BSC/ PCFから基地局に送信する。この第二LCPエコー要求は，MTのためのトラフィック・チャネルを設定しないことを指示する非トラフィックチャネル(非TCH)のパラメータを含んでいる。)
　
２．「[0034] Consequently, the PDSN 16 maintains the PPP session of the MT 10 until it receives an indication that the PPP connection 116 is inactive or that the Always On feature for the MT 10 has been terminated. PPP resource management in the PDSN 16 could be requested to clear up any unwanted PPP resources due to Always On feature, especially if the PPP inactivity timer is set to a large value. Since Always On is a subscriber service, an indicator should be sent back to home AAA in a Usage Data Record (UDR) for informing the AAA that the PPP timer has lapsed. At step 127, the PDSN 16 detects that the PPP is inactive and starts a PPP connection inactivity timer at step 128. This determination is made when the PDSN stops receiving data from or for the MT 10.
[0035] If the BSC/PCF 14 supports SDB, the BSC/PCF 14 sends a Support message 124 that comprises a parameter (SDB 125) for indicating that the BSC/PCF 14 supports SDB. Following this, the PDSN 16 processes the message 124 and sends to the BSC/PCF 14 a LCP Echo Request 232 for determining whether the MT 10 is located in the network 200. The LCP Echo Request 232 is sent based on threshold value determined at the PPP inactivity timer. The LCP Echo Request 232 includes a SDB parameter 233 included in the GRE header. It can be understood that the SDB indication included in a GRE header of a message for informing a receiving network element that the message is for SDB is not only limited to LCP Requests. But can be included in any PDSN initiated message. The SDB parameter 125 indicates to the BSC/PCF 14 and further to the BS 12 that a TCH does not need to be set up for the Request 232. Not setting up a TCH, avoids unnecessary signaling in the network 200.
[0036] After sending the LCP Echo Request 232, the PDSN 16 starts an Echo Reply timeout timer 138, at step 136. If the PDSN 16 does not receive a LCP Echo Reply from the BSC/PCF 14 after the expiry of a determined threshold in the timeout timer 138, the PDSN 16 sends again the same LCP Echo Request 232 including the SDB parameter 233 until it gets a LCP Echo Reply. The PDSN 16 also initializes an Echo Request-Retries counter 142 (step 140) for counting the number of Echo Requests sent (e.g. Echo Request 232).
[0037] Upon reception of the LCP Echo Request 232 the BSC/PCF 14 determines based on the SDB parameter 233 in the GRE header of the LCP Echo Request 232 that a TCH such as the TCH 108 is not necessary (step 236). Thus the method avoids unnecessary signaling by not setting up a traffic channel. Next the BSC/PCF 14 generates and sends a LCP Echo Request 244 to the BS 12. 
The LCP Echo Request 244 includes an indication (No TCH 246) for informing the BS 12 that assigning a TCH for the MT 10 is not necessary
After receiving and processing the LCP Echo Request 244, the BS 12 does not assign a TCH and directly sends on a common channel signaling (CCHS) 250 between the MT 10 and the BS 12 the LCP Echo request 244 to the MT 10. Next, the MT 10 replies to the LCP Echo Request with a LCP Echo Reply including a MT present parameter (MT present 262) for indicating his presence to the BS 12
(当審注
　引用例[0037](最終文)の「Upon reception of the LCP Echo Reply at the PDSN 16, the PDSN then knows 
hat
　つまり，上記最終文は「Upon reception of the LCP Echo Reply at the PDSN 16, the PDSN then knows 
that
(当審訳
[００３４]
　その結果，PDSN16は，PPP接続116が，非アクティブであること，又はMT10のための常時オン機能が終了したことの指示を受信するまで，MT10のPPPセッションを維持する。PDSN16におけるPPPの資源管理は，「常にオン」機能に起因する不要なPPPのリソースをクリアするために要求される。特に，PPP非アクティビティタイマーは，大きな値に設定されている場合に。ステップ127で，PDSN16は，PPPが非アクティブであること，ステップ128で，PPP接続無活動タイマーを開始することを検知する。PDSNは，MT10から又はMT10へのデータの受信を停止したとき，この決定がなされる。
[００３５]
　BSC/PCF14が，SDBをサポートする場合，BSC/PCF14は，BSC/PCF14がSDBをサポートしていることを示すパラメータ(SDB125)を備えるサポートメッセージ124を送信する。これに続いて，PDSN16は，メッセージ124を処理し，そして，BSC/PCF14に，MT10がネットワーク200に位置しているか否かを判定するためのLCPエコー要求232を送信する。LCPエコー要求232は，PPP非アクティビティタイマーで決定されたしきい値に基づいて送信される。LCPエコー要求232は，GREヘッダに含まれるSDBパラメータ233を含んでいる。メッセージがSDBのためのものである，受信側のネットワーク要素に通知するためのメッセージのGREヘッダーに含まれているSDB表示が，LCPリクエストに制限されているだけではないことを，理解することができる。しかし，PDSN開始メッセージに含めることができる。SDBパラメータ125は，BSC/PCF14に示し，さらに，TCHはリクエスト232のために設定する必要がないBS12へ示す。TCHを設定しないとき，ネットワーク200で不要なシグナリングを避けることができる。
[００３６]
　LCPエコー要求232を送信した後，ステップ136で，PDSN16は，エコー応答タイムアウトタイマー138を開始する。タイムアウトタイマー138での決定されたしきい値が満了した後，PDSN16が，BSC/PCF14からLCPエコー応答を受信しない場合，LCPエコー応答を取得するまで，PDSN16は，SDBパラメータ233を含む同じLCPエコー要求232を，再び送信する。PDSN16はまた，送信されたエコー要求の(例えば，エコー要求232)の数をカウントするため，エコー要求リトライカウンタ142(ステップ140)を初期化する。
[００３７]
　LCPエコー要求232を受信すると，BSC/PCF14は，LCPエコー要求232のGREヘッダー内のSDBパラメータ233に基づいて，TCH108のようなTCHが必要ではないと判定する(ステップ236)。したがって，この方法は，トラフィックチャネルを設定しないことで，不必要なシグナリングを避けることができる。次に，BSC/PCF14は，BS12にLCPエコー要求244を生成し，送信する。
LCPエコー要求244には，MT10のためにTCHを割り当てることは必要ではないBS12に知らせるための表示(TCH246ではない)が含まれる
LCPエコー要求244を受信し，処理した後，BS12は，TCHを割り当てず，そして，MT10とBS12の間の共有チャネルシグナリング(CCHS)250を介して，LCPエコー要求244をMT10へ，直接送信する。続いて，MT10は，BS12へのその存在を示すため，MT存在のパラメータ(MT存在262)を含むLCPエコー応答で，LCPエコー要求に応答する
　
３．「1. A method for maintaining a Point-to-Point Protocol (PPP) connection between a Mobile Terminal (MT) and a Packet Data Serving Node (PDSN), the method comprising the steps of: 
　responsive to a detection at the PDSN that the PPP connection between the PDSN and the MT is inactive, receiving at a Base Station Controller/Packet Control Function (BSC/PCF) a first Link Control Protocol (LCP) Echo Request from the PDSN for locating the MT, the LCP Echo Request including a Short Data Burst (SDB) parameter, wherein the SDB parameter indicates that the message is sent using SDB; 
　determining at the BSC/PCF based on the reception of SDB parameter, not to setup a traffic channel (TCH) between the MT and a serving BS; and 
　sending from the BSC/PCF a second LCP Echo Request to a Base Station (BS), the LCP Request including a NO Traffic Channel (No TCH) parameter instructing not to setup a traffic channel for the MT.」(公報第４ページ右欄)
(当審訳
請求項１．
移動端末(ＭＴ)とパケットデータサービングノード(ＰＤＳＮ)間のポイントツーポイントプロトコル(ＰＰＰ)接続を維持するための方法であって、
以下の工程を含む方法，
　ＰＤＳＮとＭＴとの間のＰＰＰ接続は非アクティブであるＰＤＳＮでの検出に応答し，
ＰＤＳＮからＭＴの位置を特定するため，第１のリンク制御プロトコル(ＬＣＰ)要求を，基地局コントローラ/パケット制御機能(ＢＳＣ/ＰＣＦ)で受信し，
このＬＣＰエコー要求はショートバースト(ＳＤＢ)パラメータを含み，
このＳＤＢパラメータは，メッセージがＳＤＮを使用して送信されることを示し，
　ＭＴとサービングＢＳの間にトラフィックチャネルを設定しないように，ＳＤＢパラメータの受信を基にＢＳＣ/ＰＣＦで決定し，そして，
　基地局(ＢＳ)へ第２のＬＣＰエコー要求をＢＳＣ/ＰＣＦから送信し，
このＬＣＰエコー要求は，ＭＴのためのトラフィックチャネルを設定しないことことを指示する非トラフィックチャネル(非ＴＣＨ)パラメータ含んでいる。)
　
４．「4. The method of claim 1, wherein the step of sending further comprises the steps of: 
　using a common channel signaling between the MT and the BS; and 
　sending in SDB a LCP Echo Reply from the MT to the PDSN, the LCP Echo Reply including a MT present parameter indicating that the MT is present and that the PDSN does not need to send another LCP Echo Request.」(公報第４ページ右欄)
(当審訳
請求項４．
　送信するステップは、更に以下の工程を含む、請求項１に記載の方法であって，
　ＭＴとＢＳ間の共有チャネルシグナリングを使用し，そして，
　ＰＤＳＮへＭＴからＬＣＰエコー応答をＳＤＢで送信し，
　このＬＣＰエコー応答は，ＭＴが存在することと，ＰＤＳＮが別のＬＣＰエコー要求を送信する必要がないことを示すＭＴ存在パラメータを含んでいる。)
　
　上記記載及び図２の記載を技術常識に照らすと，引用例には次の発明(以下「引用発明」という。)が開示されているといえる。
　
　移動端末(以下「ＭＴ」という。)が，パケットデータサービングノード（以下「ＰＤＳＮ」という。）とのポイントツーポイントプロトコル(以下「ＰＰＰ」という。)接続(connection)を維持するため，
　ＬＣＰエコー要求(Link Control Protocol Echo Request)には，ＭＴにＴＣＨ(traffic channel)を割り当てることが必要ないことをＢＳ(Base Station)に知らせるための表示(非ＴＣＨ)が含まれ，
　ＬＣＰエコー要求を受信し，処理した後，ＢＳは，ＴＣＨを割り当てず，そして，ＭＴとＢＳの間の共有チャネルシグナリング(ＣＣＨＳ(common channel signaling))を介して，ＬＣＰエコー要求をＭＴへ，直接送信し，
　ＭＴとＢＳ間の共有チャネルシグナリングを使用し，
　ＰＤＳＮへＬＣＰエコー応答をＳＤＢで送信する
　ＭＴ。
　
　
第３　当審の判断
　
１．対比
　本願発明と引用発明を比較すると次のことがいえる。
　
○　引用発明における「ＭＴ(移動端末)」は，「無線通信のための装置」といえる。
○　引用発明における「ＬＣＰエコー要求」は，「共有チャネルシグナリング」を使用して「ＭＴ」において「ＢＳ」から受信し，また，「ＬＣＰエコー応答」は，ＭＴとＢＳ間の共有チャネルシグナリングを使用して「ＰＤＳＮ」へ送信される。
　ここで，(１)引用発明において，上記「共有チャネルシグナリング」を使用することが，「非ＴＣＨ」つまり「非トラフィックチャネル」を使用することを意味していることは明らかである。
　また，(２)引用発明において，「ＰＤＳＮ」及び「ＢＳ」は，「ＭＴ」によってアクセスされるネットワーク，つまり「アクセスネットワーク」を構成するものである。
　上記(１)，(２)から，上記「ＬＣＰエコー要求」は，「非トラフィックチャネルでアクセスネットワークから受信」される点において，本願発明の「第１のメッセージ」と共通し，このときの「非トラフィックチャネル」は本願発明における「第１のトラフィックチャネル」といえる。
　また，上記「ＬＣＰエコー応答」は，「非トラフィックチャネルでアクセスネットワークへ送信」される点において，本願発明における「第２のメッセージ」と共通し，このときの「非トラフィックチャネル」は本願発明における「第２の非トラフィックチャネル」といえる。
　このように，「ＬＣＰエコー要求」を受信し，それに対し「ＬＣＰエコー応答」を送信することは，「ＬＣＰエコー要求」及び「ＬＣＰエコー応答」が「交換される」といえることを示している。
　
　以上から，本願発明と引用発明は次の点で一致し，相違する。
　
［一致点］
　無線通信のための装置であって、
　第１のメッセージを第１の非トラヒック・チャネルでアクセス・ネットワークから受信し，第２のメッセージを第２の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成され，
　前記第１のメッセージ及び前記第２のメッセージは，交換される
　装置。
　
［相違点１］
　引用発明における「ＭＴ」は，「プロセッサ」を備えることの特定がない点で，本願発明と相違している。
　そして，この相違により，プロセッサに接続された「メモリ」を備えることの特定が，引用発明にはない点で，本願発明と相違する。
　
［相違点２］
　「第１のメッセージ及び第２のメッセージ」の交換が，本願発明は「データ・セッションをキープアライブするため」であるのに対して，引用発明には，そのような特定がない点。
　
２．検討
○　相違点１について　
　移動端末において，送信，受信のようなの通信の制御を行うためにプロセッサを備えることは，引用例を提示するまでもなく周知であって，上記ような制御を行うためのプログラム，データを格納するため，プロセッサにメモリを接続することは当然である。
　このことは，引用発明に周知技術を適用して，「第１のメッセージを第１の非トラヒック・チャネルでアクセス・ネットワークから受信し，第２のメッセージを第２の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成された少なくとも１つのプロセッサと，前記少なくとも１つのプロセッサに接続されたメモリとを備え」るようにすることは，当業者が容易になしえたことを示している。
　
○　相違点２について　
　ＰＰＰ接続を介して，移動端末とＰＤＳＮ間に，ＳＭＳ等のデータサービスを提供するデータ用の接続，つまり「データセッション」がＰＰＰ接続に設定されることは，引用例を提示するまでもなく周知である。
　また，サービスされるデータによっては，そのデータのセッションが，切断されることにより，移動端末等に不具合が生じうることは当然である。
　そして，引用発明は，ＰＰＰ接続を維持すること，つまり，「ＰＰＰ接続をキープアライブ」することを開示していることは明らかである。
　この維持のために，引用発明では，「ＬＣＰエコー要求」，「ＬＣＰエコー応答」の交換を利用している。
　このことは，メッセージの交換により，接続を維持，つまり「キープアライブ」しうることを示しているといえる。
　したがって，引用発明を基に，本願発明のように「前記第１のメッセージ及び前記第２のメッセージ」を交換することにより，「データ・セッションをキープアライブする」ようにすること，すなわち，「前記第１のメッセージ及び前記第２のメッセージは、データ・セッションをキープアライブするために交換される」ように構成することは，当業者が適宜なしえた事項であるといわざるを得ない。
　
　そして，本願発明のように構成したことによる効果も，引用発明及び周知技術から予測できる程度のものである。
　
　したがって，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
　
第４　むすび
　
　以上のとおりであるから，本願発明は，特許法第２９条第２項の規定により，特許を受けることができない。
　したがって，その余の請求項に係る発明について論及するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。