ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04W |
---|---|
管理番号 | 1292280 |
審判番号 | 不服2012-20684 |
総通号数 | 179 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2014-11-28 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2012-10-19 |
確定日 | 2014-10-08 |
事件の表示 | 特願2010-515020「無線通信ネットワークにおける常時接続型データ・セッションを維持する方法及び装置」拒絶査定不服審判事件〔平成21年 1月 8日国際公開、WO2009/006080、平成22年10月21日国内公表、特表2010-533395〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1 手続の経緯及び本願発明 1.手続の経緯 本願は,2008年(平成20年)6月23日(優先権主張 2007年(平成19年)6月28日 米国,2007年(平成19年)7月30日 米国)を国際出願日とする出願であって,平成24年2月9日付けで拒絶理由が通知され,同年5月11日付けで意見書とともに手続補正書の提出がなされ,同年6月13日付けで拒絶査定され,同年10月19日に拒絶査定不服審判の請求がなされ,同年11月29日付けで手続補正書(審判請求の理由補充)の提出がなされたものである。 2.本願発明 本願の請求項1に係る発明は,平成24年5月11日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものである。 【請求項1】 無線通信のための装置であって、 第1のメッセージを第1の非トラヒック・チャネルでアクセス・ネットワークから受信し、第2のメッセージを第2の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成された少なくとも1つのプロセッサと、 前記少なくとも1つのプロセッサに接続されたメモリとを備え、 前記第1のメッセージ及び前記第2のメッセージは、データ・セッションをキープアライブするために交換される装置。 第2 引用発明 原査定の理由に引用された米国特許出願公開第2006/0002358号明細書(US2006/0002358,2006年(平成18年)1月5日米国公開。以下「引用例」という。)には,図面とともに次の事項が記載されている。 1.「[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.」(公報第1ページ右上欄) (当審訳 [要約] 本発明は,移動端末(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)のパラメータを含んでいる。) 2.「[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. The BS 12 further forwards the reply 260 to the BSC/PCF 14, which further transmits this to the PDSN 16. Upon reception of the LCP Echo Reply at the PDSN 16, the PDSN then knows hat the MT 10 is located in its serving area.」(公報第4ページ左欄-同ページ右欄) (当審注 引用例[0037](最終文)の「Upon reception of the LCP Echo Reply at the PDSN 16, the PDSN then knows hat the MT 10 is located in its serving area.」における「hat」は,引用例の記載事項全てからみて,正しくは「that」の明らかな誤記であると解される。 つまり,上記最終文は「Upon reception of the LCP Echo Reply at the PDSN 16, the PDSN then knows that the MT 10 is located in its serving area.」である明らかな誤記と解される。) (当審訳 [0034] その結果,PDSN16は,PPP接続116が,非アクティブであること,又はMT10のための常時オン機能が終了したことの指示を受信するまで,MT10のPPPセッションを維持する。PDSN16におけるPPPの資源管理は,「常にオン」機能に起因する不要なPPPのリソースをクリアするために要求される。特に,PPP非アクティビティタイマーは,大きな値に設定されている場合に。ステップ127で,PDSN16は,PPPが非アクティブであること,ステップ128で,PPP接続無活動タイマーを開始することを検知する。PDSNは,MT10から又はMT10へのデータの受信を停止したとき,この決定がなされる。 [0035] 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で不要なシグナリングを避けることができる。 [0036] LCPエコー要求232を送信した後,ステップ136で,PDSN16は,エコー応答タイムアウトタイマー138を開始する。タイムアウトタイマー138での決定されたしきい値が満了した後,PDSN16が,BSC/PCF14からLCPエコー応答を受信しない場合,LCPエコー応答を取得するまで,PDSN16は,SDBパラメータ233を含む同じLCPエコー要求232を,再び送信する。PDSN16はまた,送信されたエコー要求の(例えば,エコー要求232)の数をカウントするため,エコー要求リトライカウンタ142(ステップ140)を初期化する。 [0037] 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エコー要求に応答する。BS12は,更に応答260をBSC/PCF14に転送し,このBSC/PCF14は更にPDSN16に送信する。PDSN16で,LCPエコー応答を受信すると,PDSNは,その時,MT10がそのサービングエリアに位置していることを知る。) 3.「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ページ右欄) (当審訳 請求項1. 移動端末(MT)とパケットデータサービングノード(PDSN)間のポイントツーポイントプロトコル(PPP)接続を維持するための方法であって、 以下の工程を含む方法, PDSNとMTとの間のPPP接続は非アクティブであるPDSNでの検出に応答し, PDSNからMTの位置を特定するため,第1のリンク制御プロトコル(LCP)要求を,基地局コントローラ/パケット制御機能(BSC/PCF)で受信し, このLCPエコー要求はショートバースト(SDB)パラメータを含み, このSDBパラメータは,メッセージがSDNを使用して送信されることを示し, MTとサービングBSの間にトラフィックチャネルを設定しないように,SDBパラメータの受信を基にBSC/PCFで決定し,そして, 基地局(BS)へ第2のLCPエコー要求をBSC/PCFから送信し, このLCPエコー要求は,MTのためのトラフィックチャネルを設定しないことことを指示する非トラフィックチャネル(非TCH)パラメータ含んでいる。) 4.「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.」(公報第4ページ右欄) (当審訳 請求項4. 送信するステップは、更に以下の工程を含む、請求項1に記載の方法であって, MTとBS間の共有チャネルシグナリングを使用し,そして, PDSNへMTからLCPエコー応答をSDBで送信し, このLCPエコー応答は,MTが存在することと,PDSNが別のLCPエコー要求を送信する必要がないことを示すMT存在パラメータを含んでいる。) 上記記載及び図2の記載を技術常識に照らすと,引用例には次の発明(以下「引用発明」という。)が開示されているといえる。 移動端末(以下「MT」という。)が,パケットデータサービングノード(以下「PDSN」という。)とのポイントツーポイントプロトコル(以下「PPP」という。)接続(connection)を維持するため, LCPエコー要求(Link Control Protocol Echo Request)には,MTにTCH(traffic channel)を割り当てることが必要ないことをBS(Base Station)に知らせるための表示(非TCH)が含まれ, LCPエコー要求を受信し,処理した後,BSは,TCHを割り当てず,そして,MTとBSの間の共有チャネルシグナリング(CCHS(common channel signaling))を介して,LCPエコー要求をMTへ,直接送信し, MTとBS間の共有チャネルシグナリングを使用し, PDSNへLCPエコー応答をSDBで送信する MT。 第3 当審の判断 1.対比 本願発明と引用発明を比較すると次のことがいえる。 ○ 引用発明における「MT(移動端末)」は,「無線通信のための装置」といえる。 ○ 引用発明における「LCPエコー要求」は,「共有チャネルシグナリング」を使用して「MT」において「BS」から受信し,また,「LCPエコー応答」は,MTとBS間の共有チャネルシグナリングを使用して「PDSN」へ送信される。 ここで,(1)引用発明において,上記「共有チャネルシグナリング」を使用することが,「非TCH」つまり「非トラフィックチャネル」を使用することを意味していることは明らかである。 また,(2)引用発明において,「PDSN」及び「BS」は,「MT」によってアクセスされるネットワーク,つまり「アクセスネットワーク」を構成するものである。 上記(1),(2)から,上記「LCPエコー要求」は,「非トラフィックチャネルでアクセスネットワークから受信」される点において,本願発明の「第1のメッセージ」と共通し,このときの「非トラフィックチャネル」は本願発明における「第1のトラフィックチャネル」といえる。 また,上記「LCPエコー応答」は,「非トラフィックチャネルでアクセスネットワークへ送信」される点において,本願発明における「第2のメッセージ」と共通し,このときの「非トラフィックチャネル」は本願発明における「第2の非トラフィックチャネル」といえる。 このように,「LCPエコー要求」を受信し,それに対し「LCPエコー応答」を送信することは,「LCPエコー要求」及び「LCPエコー応答」が「交換される」といえることを示している。 以上から,本願発明と引用発明は次の点で一致し,相違する。 [一致点] 無線通信のための装置であって、 第1のメッセージを第1の非トラヒック・チャネルでアクセス・ネットワークから受信し,第2のメッセージを第2の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成され, 前記第1のメッセージ及び前記第2のメッセージは,交換される 装置。 [相違点1] 引用発明における「MT」は,「プロセッサ」を備えることの特定がない点で,本願発明と相違している。 そして,この相違により,プロセッサに接続された「メモリ」を備えることの特定が,引用発明にはない点で,本願発明と相違する。 [相違点2] 「第1のメッセージ及び第2のメッセージ」の交換が,本願発明は「データ・セッションをキープアライブするため」であるのに対して,引用発明には,そのような特定がない点。 2.検討 ○ 相違点1について 移動端末において,送信,受信のようなの通信の制御を行うためにプロセッサを備えることは,引用例を提示するまでもなく周知であって,上記ような制御を行うためのプログラム,データを格納するため,プロセッサにメモリを接続することは当然である。 このことは,引用発明に周知技術を適用して,「第1のメッセージを第1の非トラヒック・チャネルでアクセス・ネットワークから受信し,第2のメッセージを第2の非トラヒック・チャネルで前記アクセス・ネットワークへ送信するように構成された少なくとも1つのプロセッサと,前記少なくとも1つのプロセッサに接続されたメモリとを備え」るようにすることは,当業者が容易になしえたことを示している。 ○ 相違点2について PPP接続を介して,移動端末とPDSN間に,SMS等のデータサービスを提供するデータ用の接続,つまり「データセッション」がPPP接続に設定されることは,引用例を提示するまでもなく周知である。 また,サービスされるデータによっては,そのデータのセッションが,切断されることにより,移動端末等に不具合が生じうることは当然である。 そして,引用発明は,PPP接続を維持すること,つまり,「PPP接続をキープアライブ」することを開示していることは明らかである。 この維持のために,引用発明では,「LCPエコー要求」,「LCPエコー応答」の交換を利用している。 このことは,メッセージの交換により,接続を維持,つまり「キープアライブ」しうることを示しているといえる。 したがって,引用発明を基に,本願発明のように「前記第1のメッセージ及び前記第2のメッセージ」を交換することにより,「データ・セッションをキープアライブする」ようにすること,すなわち,「前記第1のメッセージ及び前記第2のメッセージは、データ・セッションをキープアライブするために交換される」ように構成することは,当業者が適宜なしえた事項であるといわざるを得ない。 そして,本願発明のように構成したことによる効果も,引用発明及び周知技術から予測できる程度のものである。 したがって,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。 第4 むすび 以上のとおりであるから,本願発明は,特許法第29条第2項の規定により,特許を受けることができない。 したがって,その余の請求項に係る発明について論及するまでもなく,本願は拒絶すべきものである。 よって,結論のとおり審決する。 |
審理終結日 | 2014-02-05 |
結審通知日 | 2014-02-12 |
審決日 | 2014-02-26 |
出願番号 | 特願2010-515020(P2010-515020) |
審決分類 |
P
1
8・
121-
Z
(H04W)
|
最終処分 | 不成立 |
前審関与審査官 | 北川 純次 |
特許庁審判長 |
近藤 聡 |
特許庁審判官 |
佐藤 聡史 水野 恵雄 |
発明の名称 | 無線通信ネットワークにおける常時接続型データ・セッションを維持する方法及び装置 |
代理人 | 竹内 将訓 |
代理人 | 幸長 保次郎 |
代理人 | 堀内 美保子 |
代理人 | 佐藤 立志 |
代理人 | 中村 誠 |
代理人 | 蔵田 昌俊 |
代理人 | 岡田 貴志 |
代理人 | 河野 直樹 |
代理人 | 野河 信久 |
代理人 | 井関 守三 |
代理人 | 白根 俊郎 |
代理人 | 峰 隆司 |
代理人 | 福原 淑弘 |
代理人 | 砂川 克 |