• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) H04W
管理番号 1361239
審判番号 不服2019-3903  
総通号数 245 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-05-29 
種別 拒絶査定不服の審決 
審判請求日 2019-03-25 
確定日 2020-04-02 
事件の表示 特願2016-527473「MTCのための装置、システム、及び方法」拒絶査定不服審判事件〔平成27年 5月 7日国際公開、WO2015/064056、平成28年12月28日国内公表、特表2016-541175〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は,2014年(平成26年)10月21日(国内優先権主張 平成25年10月31日)を国際出願日とする出願であって,その手続の経緯は以下のとおりである。

平成29年 9月 1日 手続補正書の提出
平成30年 5月30日付け 拒絶理由通知書
平成30年 8月 7日 意見書,及び手続補正書の提出
平成30年12月18日付け 拒絶査定
平成31年 3月25日 拒絶査定不服審判の請求,
及び手続補正書の提出
令和 元年11月15日付け 拒絶理由通知書(当審)
令和 2年 1月 8日 意見書,及び手続補正書の提出

第2 本願発明
本願の請求項に係る発明は,令和2年1月8日に提出された手続補正書により補正された特許請求の範囲の請求項1ないし8に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「 Small Data Submission Requestメッセージをノードへ送信するSCS(Service Capability Server)と,
前記SCSに直接接続されてコアネットワークのエントリーポイントとして機能し,前記SCSの承認を実行し,MME(Mobility Management Entity)又はSGSN(Serving GPRS Support Node)と,前記ノード間のセキュアな接続を確立することによって,スモールデータを前記MME又は前記SGSNへ送信し,前記セキュアな接続の解放を判定する前記ノードと,
前記MME又は前記SGSNから前記スモールデータを配信されるUE(User Equipment)と,を備え,
前記ノードは,前記セキュアな接続を解放すると判定した場合に,Release Connectionメッセージを前記MME又は前記SGSNへ送信し,前記MME又は前記SGSNに,前記スモールデータ接続のための関連情報を削除させる,
移動通信システム。」


第3 拒絶の理由
令和元年11月15日付けで当審が通知した拒絶理由(以下,「当審拒絶理由」という。)の概要は,次のとおりである。
「1.(実施可能要件)この出願は,発明の詳細な説明の記載が下記の点で,特許法第36条第4項第1号に規定する要件を満たしていない。
2.(サポート要件)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第1号に規定する要件を満たしていない。
3.(明確性)この出願は,特許請求の範囲の記載が下記の点で,特許法第36条第6項第2号に規定する要件を満たしていない。
(中略)

記 (引用文献等については引用文献等一覧参照)

1 理由1,2,3(実施可能要件,サポート要件,明確性)について

(1)(中略)
また,発明の詳細な説明には,UEとMTC-IWF(ノード)との間でセキュアな接続を確立することは記載されているものの,MME又はSGSNと,ノード間のセキュアな接続を確立することは記載されていない。そして,発明の詳細な説明には,MME又はSGSNとノード間のセキュアな接続を確立することについて記載されていないため,MME又はSGSNとノード間の接続がセキュアな接続だとすると,実施可能な程度に記載しているとは認められない。
さらに,請求項2-8に係る発明についても,同様に不明確である。
したがって,請求項1-8に係る発明は,不明確であり,発明の詳細な説明に記載されたものではなく,また,発明の詳細な説明には,実施可能な程度に記載していない。(明確性,サポート要件,実施可能要件)

(2)請求項1では,MME又はSGSNに削除させる「前記スモールデータに関する情報」と記載されているところ,発明の詳細な説明(段落0045など)には,スモールデータ及びデバイストリガを搬送するための,MME又はSGSNを経由する接続(virtual interface T6を用いた接続)は,MME/SGSNに対して透過的であると記載されており,MME又はSGSNに削除すべきどのようなスモールデータに関する情報があるのか不明確である。
また,発明の詳細な説明(段落0088など)には,請求項1のMME又はSGSNに削除させる「前記スモールデータに関する情報」の具体的な技術内容について記載されていないため,実施可能な程度に記載しているとは認められない。
さらに,請求項2-8に係る発明についても,同様に不明確である。
したがって,請求項1-8に係る発明は,不明確であり,また,発明の詳細な説明には,実施可能な程度に記載していない。(明確性,実施可能要件)

(3)請求項1の「前記MME又は前記SGSNと,前記ノード間のセキュアな接続を解放する」ことの具体的技術内容が不明確である。つまり,発明の詳細な説明には,MME又は前記SGSNと前記ノード間のセキュアな接続がないのに,「前記MME又は前記SGSNと,前記ノード間のセキュアな接続を解放する」とは,どのような接続を解放しているのか不明確である。
また,発明の詳細な説明(段落0086-0089,図4など)には,eNBとMTC-IWF(ノード)との間の接続(virtual interface T6を用いた接続)を解放することが記載されているものの,MME又はSGSNとノード間のセキュアな接続を解放することは記載されていない。そして,発明の詳細な説明には,MME又はSGSNとノード間のセキュアな接続を解放することについて記載されていないため,実施可能な程度に記載しているとは認められない。
さらに,請求項2-8に係る発明についても,同様に不明確である。
したがって,請求項1-8に係る発明は,不明確であり,発明の詳細な説明に記載されたものではなく,また,発明の詳細な説明には,実施可能な程度に記載していない。(明確性,サポート要件,実施可能要件)
(以下省略)」


第4 本願の発明の詳細な説明の記載
本願の発明の詳細な説明には,以下の記載がある。(下線は当審が付与。)

「【0006】
スモールデータがNAS(Non-Access Stratum)メッセージで搬送され,NASセキュリティに依存している現在のT5ベースのソリューションは,システムへの以下のインパクトを有する。
1)セキュリティ処理のためNASレイヤ及びMMEへの負荷を増大する。
2)新たなNASキーを交渉するためにAKA(Authentication and Key Agreement)手順が実行される場合においてNAS COUNTがwrap aroundする問題を引き起こす。これはHSS(Home Subscriber Server)への負荷につながるかもしれない。
(中略)
【0027】
1.新たなインタフェースT6
本実施の形態では,T6という名称のMTC-IWFとeNB(evolved Node B)との間のダイレクト・インタフェースを提案する。このインタフェースは,セキュア且つ効率的なMTC通信のためのものであり,CP(Control Plane)及びUP(User Plane)の両方をサポートする。アイデアは,サービスプロバイダとの相互接続のためのモバイルネットワークにおけるエンドポイントとしてMTC-IWFを用いることであり,例えば,以下の(A)?(G)の効果を達成することができる。
(A)T5トリガリング及びスモールデータ配信の場合に,多数のデバイスの通信によって引き起こされるMMEの負荷をオフロードする。
(B)T5トリガリング及びスモールデータ配信の場合に,NASセキュリティのための処理によって引き起こされるMMEの負荷をオフロードする。
(C)SCS側からのネットワークエレメント及びUEへのDoS(Denial-of-Service)攻撃を防ぐ。
(D)UE側からのネットワークエレメント及びSCSへのDoS攻撃を防ぐ。
(E)トリガ及びスモールデータ伝送は,NASセキュリティから独立することができる。
(F)UEは,何も変更することなく,WiFi,又はMTC-IWFとのインタフェースを有する他のネットワークエレメントを通じて,MTC通信手段のセンターポイントとしてのMTC-IWFに接続することができる。
(G)MTC-IWFは,3GPPにて議論されているMTCに関するすべての問題に対処することができる。
【0028】
特定のUEのために,MTC-IWFは,直接的にMMEから,又は,HSSを介してMMEからサービング(serving)eNB情報を獲得することにより,サービングeNBを見つけることができる。MTCトリガ及びスモールデータは,T6インタフェース上で配信される。MTC-IWF及びUEは,セキュリティ・アソシエーションを確立し,トリガ及びスモールデータは,MTC-IWFとUEとの間で共有されるキーで保護される。
(中略)
【0042】
2.プロトコルスタック及びメッセージフロー
図4に,ローミングしないケースのメッセージフローを示す。スモールデータ及びデバイストリガのための3GPPネットワークのエンドポイントは,UE及びMTC-IWFである。
【0043】
スモールデータ及びデバイストリガを搬送するメッセージを伝送する方法は,2つある。
1)図4に点線で示す,eNB 20とMTC-IWF 50との間のダイレクト・インタフェースT6を用いる方法。
2)図4に一点鎖線で示す,バーチャル・インタフェースT6を用いる方法。
【0044】
2)の方法では,SDDTE(Small Data and Device Triggering Enhancements)プロトコルがホップ・バイ・ホップ(hop-by-hop)で搬送される。eNB 20及びMME 30は,メッセージがSDを搬送している場合,SDを搬送しているより上位の(higher)レイヤプロトコル(すなわち,SDDTE)があるか否かを検証し,NAS及びASセキュリティのための如何なる処理も実行せずに,前記メッセージを単に転送する。
【0045】
図5に,ダイレクト・インタフェースを用いることについての提案するプロトコルスタックを示す。その一方で,図6に,バーチャル・インタフェースを用いることについての提案するプロトコルスタックを示す。プロトコルSDDTEは,UE 10とMTC-IWF 50との間に広がり,MME/SGSN 30に対して透過的であり得る。
【0046】
図5に示すように,インタフェースT6が,eNB 20とMTC-IWF 50との間のダイレクト・インタフェースであるとき,スモールデータ及びデバイストリガは,インタフェースT6上で直接伝送され,eNB 20とUE 10との間のLTE-Uu上で伝送される。
【0047】
図6に示すように,インタフェースT6が,バーチャル・インタフェースであるとき,スモールデータ及びデバイストリガは,T5,S1-MME,及びLTE-Uu上でホップ・バイ・ホップで伝送される。T5ソリューションと比較すると,本実施の形態では,eNB 20及びMME 30が,SDを搬送している上位のプロトコル(SDDTE)があると検証するとき,MTC-IWF 50とeNB 20との間でメッセージを単に転送する。
(中略)
【0061】
3.2.MTスモールデータ伝送
図8に,MT(Mobile Terminated)スモールデータ伝送フローを示す。MTC-IWF 50は,スモールデータが生じることを知らせるためのスモールデータのインジケーション(indication)を伴う通常のページング手順を使用するために,MME 30をトリガする。MTC-IWF 50がページングの応答を受信するとき,MTC-IWF 50は,インタフェースT6上でスモールデータを送信する。ステップS24,S28,S29,及びS33は,新しいメッセージである。
【0062】
図8に示すように,SCS 60は,Small Data Submission RequestをMTC-IWF 50へ送信する(ステップS21)。
【0063】
MTC-IWF 50は,SCS 60及びUE 10の承認を実行する(ステップS22)。承認が成功した場合,MTC-IWF 50は,サービングノード情報を,HSS 40から又は直接MME 30から検索する。あるいは,MME 30は,サービングeNBが変わるたびに,Serving Node Information UpdateをMTC-IWF50へ送信する(ステップS23)。
(中略)
【0088】
このとき,MTC-IWF 50は,T6接続を解放することをeNB 20に示す(ステップS62)。T6接続が解放されたとき,eNB 20は,スモールデータ及びデバイストリガのための関連情報を削除する。なお,この手順は,バーチャル・インタフェースT6が使用されているときのMME 30にも適用される。
(中略)
【図4】

(中略)
【図8】



第5 当審の判断
1 当審拒絶理由「1(1)」について
上記第4の図8のS21によると,MTC-IWF(Machine-Type-Communication Inter-Working Function)はSCSに直接接続されるものであることが見て取れること,及び,上記第4の段落0062,0063によると,SCSからSmall Data Submission RequestメッセージがMTC?IWFへ送信され,前記MTC-IWFがSCSの承認を実行することが記載されているといえるから,請求項1の「ノード」は,発明の詳細な説明のMTC-IWFに対応することは明らかである。
そして,請求項1の「MME(Mobility Management Entity)又はSGSN(Serving GPRS Support Node)と,前記ノード間のセキュアな接続を確立することによって,スモールデータを前記MME又は前記SGSNへ送信」することに関し,上記第4の段落0028,0043,0044,及び図4によると,スモールデータをMTC-IWFとUEとの間で共有されるキーで保護するとともに,MTC-IWFとeNBとを接続するバーチャル・インタフェースT6を用いてスモールデータを搬送し,前記スモールデータを搬送している場合は,MMEは,NAS及びASセキュリティのための如何なる処理も実行せずに,前記スモールデータを搬送しているメッセージを単に転送することが記載されているといえるが,請求項1のMME又はSGSNとMTC-IWF間での「セキュアな接続を確立する」ことについては,発明の詳細な説明には記載されていない。
そして,上記第4の段落0028,0043,0044,及び図4に記載の前記事項は,上記第4の段落0006,0027に記載の「セキュリティ処理のためNASレイヤ及びMMEへの負荷を増大する」との課題を解決するためのものであるといえるところ,仮に,前記バーチャル・インタフェースT6のために,MME又はSGSNとMTC-IWF間で接続を確立するものであるとしても,MTC-IWFとUEとの間で共有されるキーでの保護に更に加えて,MMEとMTC-IWF間の接続を「セキュアな接続」とすることは,セキュリティ処理によってMMEの負荷を増大させることが明らかであるから,前記課題を解決しておらず,当業者にとって自明とはいえない。
また,発明の詳細な説明には,MME又はSGSNとノード間での「セキュアな接続を確立する」ことの具体的な処理内容が記載されておらず,実施可能な程度に記載されているとはいえない。
したがって,本願発明は,発明の詳細な説明に記載したものではなく,また,発明の詳細な説明に実施可能な程度に記載されていない。

2 当審拒絶理由「1(2)」について
請求項1の「前記MME又は前記SGSNに,前記スモールデータ接続のための関連情報を削除させる」ことに関し,上記第4の段落0088には,MMEは,バーチャル・インタフェースT6が解放されたときに,前記スモールデータ接続のための関連情報を削除することが記載されている。
しかしながら,発明の詳細な説明には,MMEが削除する「スモールデータ接続のための関連情報」について,MMEが記憶しているどのような情報であるのか具体的に記載されておらず不明確であり,発明の技術的範囲も不明確である。
また,発明の詳細な説明には,どのような「スモールデータ接続のための関連情報」を削除するのかについても記載されておらず,実施可能な程度に記載されているとはいえない。
したがって,本願発明は,不明確であり,また,発明の詳細な説明に実施可能な程度に記載されていない。


3 当審拒絶理由「1(3)」について
本願のMME(Mobility Management Entity)又はSGSN(Serving GPRS Support Node)と,前記ノード間の「セキュアな接続を解放する」ことに関し,上記第4の段落0088によると,MTC-IWFとeNBとの間のバーチャル・インタフェースT6を解放することが記載されているが,MME又はSGSNとMTC-IWF間の接続を解放することは記載されていない。
さらに,上記1のとおり,バーチャル・インタフェースT6でのMME又はSGSNとMTC-IWF間の接続が「セキュアな接続」であるとは,発明の詳細な説明に記載されておらず,自明であるともいえない。
そうすると,請求項1のMME又はSGSNと,ノード間の「セキュアな接続を解放する」ことについて,発明の詳細な説明には記載したものとはいえない。
また,発明の詳細な説明には,MME又はSGSNと,ノード間の「セキュアな接続を解放する」ことの具体的な処理内容が記載されていないことから,実施可能な程度に記載されているとはいえない。
したがって,本願発明は,発明の詳細な説明に記載したものではなく,また,発明の詳細な説明に実施可能な程度に記載されていない。

[請求人の主張について]
請求人は,令和2年1月8日に提出された意見書において,
「(1)「セキュアな接続」について(中略)
UEとMTC-IWFとの間がセキュアな接続であり(0028段落参照),eNB20とUE10との間がASによるセキュアな接続である(0030段落参照)とすると,当然に,MTC-IWFとMME/SGSNとの間のインタフェースT5,及びMME/SGSNとeNBとの間のインタフェースS1もセキュアな接続であるものと思料いたします。すなわち,MTC-IWFとMME/SGSNとの間の接続は,セキュアな接続であるものと思料いたします。(中略)
(2)「前記スモールデータに関する情報」について(中略)
該補正により,削除させる情報が,スモールデータ接続のための関連情報であることが明確になり,また,実施可能な程度に記載しているものとなりました。(中略)
(3)「前記MME又は前記SGSNと,前記ノード間のセキュアな接続を解放する」に
ついて(中略)
本願の明細書の0087段落には,「図10に示すように,MTC-IWF 50にて,T6接続解放タイマが満了する(ステップS61)。」と記載され,0088段落には,「このとき,MTC-IWF 50は,T6接続を解放することをeNB 20に示す(ステップS62)。T6接続が解放されたとき,eNB 20は,スモールデータ及びデバイストリガのための関連情報を削除する。なお,この手順は,バーチャル・インタフェースT6が使用されているときのMME30にも適用される。」と記載されています。すなわち,本願の明細書の0088段落には,「MME又はSGSNとノード間のセキュアな接続を解放すること」が記載されているものと思料いたします。」
と主張している。

(1)「セキュアな接続」について
上記1のとおり,請求項1のMME又はSGSNとMTC-IWF間での「セキュアな接続を確立する」ことについて,発明の詳細な説明には記載されておらず,仮に,発明の詳細な説明に記載されたバーチャル・インタフェースT6のために,MME又はSGSNとMTC-IWF間で接続を確立するものであるとしても,MMEとMTC-IWF間の接続を「セキュアな接続」とすることは,セキュリティ処理によってMMEの負荷を増大させることが明らかであるから,上記第4の段落0006,0027に記載の「セキュリティ処理のためNASレイヤ及びMMEへの負荷を増大する」との課題を解決しておらず,当業者にとって自明とはいえない。
また,発明の詳細な説明には,MME又はSGSNとノード間での「セキュアな接続を確立する」ことの具体的な処理内容が記載されておらず,実施可能な程度に記載されているとはいえない。

(2)「前記スモールデータに関する情報」について
上記2のとおり,発明の詳細な説明には,MMEが削除する「スモールデータ接続のための関連情報」について,MMEが記憶しているどのような情報であるのか記載されておらず不明確であり,また,発明の詳細な説明には,どのような「スモールデータ接続のための関連情報」を削除するのかについても記載されておらず,実施可能な程度に記載されているとはいえない。

(3)「前記MME又は前記SGSNと,前記ノード間のセキュアな接続を解放する」について
上記3のとおり,発明の詳細な説明には,MME又はSGSNとMTC-IWF間の接続を解放することは記載されておらず,かつ,「セキュアな接続」についても記載されているとはいえないため,MME又はSGSNと,ノード間の「セキュアな接続を解放する」ことは,発明の詳細な説明には記載されていない。
また,発明の詳細な説明には,MME又はSGSNと,ノード間の「セキュアな接続を解放する」ことの具体的な処理内容が記載されていないことから,実施可能な程度に記載されているとはいえない。

よって,請求人の上記主張は,採用できない。


第6 むすび
以上のとおり,本件出願は,発明の詳細な説明の記載が,特許法第36条第4項第1号に規定する要件を満たしておらず,特許請求の範囲の記載が,特許法第36条第6項第1号又は第2号に規定する要件を満たしていないから,特許を受けることができない。
したがって,本願は,他の請求項について検討するまでもなく,拒絶すべきものである。

よって,結論のとおり審決する。
 
審理終結日 2020-01-28 
結審通知日 2020-02-04 
審決日 2020-02-18 
出願番号 特願2016-527473(P2016-527473)
審決分類 P 1 8・ 536- WZ (H04W)
P 1 8・ 537- WZ (H04W)
最終処分 不成立  
前審関与審査官 三枝 保裕  
特許庁審判長 中木 努
特許庁審判官 井上 弘亘
脇岡 剛
発明の名称 MTCのための装置、システム、及び方法  
代理人 家入 健  

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