【事件の表示】
　特願２０１６−５２７４７３「ＭＴＣのための装置、システム、及び方法」拒絶査定不服審判事件〔平成２７年　５月　７日国際公開、ＷＯ２０１５／０６４０５６、平成２８年１２月２８日国内公表、特表２０１６−５４１１７５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は，２０１４年（平成２６年）１０月２１日（国内優先権主張　平成２５年１０月３１日）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。
平成２９年　９月　１日　　　手続補正書の提出 
平成３０年　５月３０日付け　拒絶理由通知書 
平成３０年　８月　７日　　　意見書，及び手続補正書の提出 
平成３０年１２月１８日付け　拒絶査定 
平成３１年　３月２５日　　　拒絶査定不服審判の請求，
　　　　　　　　　　　　　　　及び手続補正書の提出　
令和　元年１１月１５日付け　拒絶理由通知書（当審） 
令和　２年　１月　８日　　　意見書，及び手続補正書の提出 
第２　本願発明
　本願の請求項に係る発明は，令和２年１月８日に提出された手続補正書により補正された特許請求の範囲の請求項１ないし８に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
「　Ｓｍａｌｌ　Ｄａｔａ　Ｓｕｂｍｉｓｓｉｏｎ　Ｒｅｑｕｅｓｔメッセージをノードへ送信するＳＣＳ（Ｓｅｒｖｉｃｅ　Ｃａｐａｂｉｌｉｔｙ　Ｓｅｒｖｅｒ）と，
　前記ＳＣＳに直接接続されてコアネットワークのエントリーポイントとして機能し，前記ＳＣＳの承認を実行し，ＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）と，前記ノード間のセキュアな接続を確立することによって，スモールデータを前記ＭＭＥ又は前記ＳＧＳＮへ送信し，前記セキュアな接続の解放を判定する前記ノードと，
　前記ＭＭＥ又は前記ＳＧＳＮから前記スモールデータを配信されるＵＥ（Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ）と，を備え，
　前記ノードは，前記セキュアな接続を解放すると判定した場合に，Ｒｅｌｅａｓｅ　Ｃｏｎｎｅｃｔｉｏｎメッセージを前記ＭＭＥ又は前記ＳＧＳＮへ送信し，前記ＭＭＥ又は前記ＳＧＳＮに，前記スモールデータ接続のための関連情報を削除させる，
　移動通信システム。」
第３　拒絶の理由
　令和元年１１月１５日付けで当審が通知した拒絶理由（以下，「当審拒絶理由」という。）の概要は，次のとおりである。
「１．（実施可能要件）この出願は，発明の詳細な説明の記載が下記の点で，特許法第３６条第４項第１号に規定する要件を満たしていない。
２．（サポート要件）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第１号に規定する要件を満たしていない。
３．（明確性）この出願は，特許請求の範囲の記載が下記の点で，特許法第３６条第６項第２号に規定する要件を満たしていない。
（中略）
　
　　　　　　　記　　（引用文献等については引用文献等一覧参照）
　
１　理由１，２，３（実施可能要件，サポート要件，明確性）について
　
（１）（中略） 
　また，発明の詳細な説明には，ＵＥとＭＴＣ−ＩＷＦ（ノード）との間でセキュアな接続を確立することは記載されているものの，ＭＭＥ又はＳＧＳＮと，ノード間のセキュアな接続を確立することは記載されていない。そして，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮとノード間のセキュアな接続を確立することについて記載されていないため，ＭＭＥ又はＳＧＳＮとノード間の接続がセキュアな接続だとすると，実施可能な程度に記載しているとは認められない。
　さらに，請求項２−８に係る発明についても，同様に不明確である。 
　したがって，請求項１−８に係る発明は，不明確であり，発明の詳細な説明に記載されたものではなく，また，発明の詳細な説明には，実施可能な程度に記載していない。（明確性，サポート要件，実施可能要件）
　
（２）請求項１では，ＭＭＥ又はＳＧＳＮに削除させる「前記スモールデータに関する情報」と記載されているところ，発明の詳細な説明（段落００４５など）には，スモールデータ及びデバイストリガを搬送するための，ＭＭＥ又はＳＧＳＮを経由する接続（ｖｉｒｔｕａｌ　ｉｎｔｅｒｆａｃｅ　Ｔ６を用いた接続）は，ＭＭＥ／ＳＧＳＮに対して透過的であると記載されており，ＭＭＥ又はＳＧＳＮに削除すべきどのようなスモールデータに関する情報があるのか不明確である。
　また，発明の詳細な説明（段落００８８など）には，請求項１のＭＭＥ又はＳＧＳＮに削除させる「前記スモールデータに関する情報」の具体的な技術内容について記載されていないため，実施可能な程度に記載しているとは認められない。
　さらに，請求項２−８に係る発明についても，同様に不明確である。 
　したがって，請求項１−８に係る発明は，不明確であり，また，発明の詳細な説明には，実施可能な程度に記載していない。（明確性，実施可能要件）
　
（３）請求項１の「前記ＭＭＥ又は前記ＳＧＳＮと，前記ノード間のセキュアな接続を解放する」ことの具体的技術内容が不明確である。つまり，発明の詳細な説明には，ＭＭＥ又は前記ＳＧＳＮと前記ノード間のセキュアな接続がないのに，「前記ＭＭＥ又は前記ＳＧＳＮと，前記ノード間のセキュアな接続を解放する」とは，どのような接続を解放しているのか不明確である。
　また，発明の詳細な説明（段落００８６−００８９，図４など）には，ｅＮＢとＭＴＣ−ＩＷＦ（ノード）との間の接続（ｖｉｒｔｕａｌ　ｉｎｔｅｒｆａｃｅ　Ｔ６を用いた接続）を解放することが記載されているものの，ＭＭＥ又はＳＧＳＮとノード間のセキュアな接続を解放することは記載されていない。そして，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮとノード間のセキュアな接続を解放することについて記載されていないため，実施可能な程度に記載しているとは認められない。
　さらに，請求項２−８に係る発明についても，同様に不明確である。 
　したがって，請求項１−８に係る発明は，不明確であり，発明の詳細な説明に記載されたものではなく，また，発明の詳細な説明には，実施可能な程度に記載していない。（明確性，サポート要件，実施可能要件）
（以下省略）」
第４　本願の発明の詳細な説明の記載
　本願の発明の詳細な説明には，以下の記載がある。（下線は当審が付与。）
「【０００６】
　スモールデータがＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）メッセージで搬送され，ＮＡＳセキュリティに依存している現在のＴ５ベースのソリューションは，システムへの以下のインパクトを有する。
１）セキュリティ処理のためＮＡＳレイヤ及びＭＭＥへの負荷を増大する。
２）新たなＮＡＳキーを交渉するためにＡＫＡ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ａｎｄ　Ｋｅｙ　Ａｇｒｅｅｍｅｎｔ）手順が実行される場合においてＮＡＳ　ＣＯＵＮＴがｗｒａｐ　ａｒｏｕｎｄする問題を引き起こす。これはＨＳＳ（Ｈｏｍｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｓｅｒｖｅｒ）への負荷につながるかもしれない。
（中略）
【００２７】
　１．新たなインタフェースＴ６
　本実施の形態では，Ｔ６という名称のＭＴＣ−ＩＷＦとｅＮＢ（ｅｖｏｌｖｅｄ　Ｎｏｄｅ　Ｂ）との間のダイレクト・インタフェースを提案する。このインタフェースは，セキュア且つ効率的なＭＴＣ通信のためのものであり，ＣＰ（Ｃｏｎｔｒｏｌ　Ｐｌａｎｅ）及びＵＰ（Ｕｓｅｒ　Ｐｌａｎｅ）の両方をサポートする。アイデアは，サービスプロバイダとの相互接続のためのモバイルネットワークにおけるエンドポイントとしてＭＴＣ−ＩＷＦを用いることであり，例えば，以下の（Ａ）〜（Ｇ）の効果を達成することができる。
（Ａ）Ｔ５トリガリング及びスモールデータ配信の場合に，多数のデバイスの通信によって引き起こされるＭＭＥの負荷をオフロードする。
（Ｂ）Ｔ５トリガリング及びスモールデータ配信の場合に，ＮＡＳセキュリティのための処理によって引き起こされるＭＭＥの負荷をオフロードする。
（Ｃ）ＳＣＳ側からのネットワークエレメント及びＵＥへのＤｏＳ（Ｄｅｎｉａｌ−ｏｆ−Ｓｅｒｖｉｃｅ）攻撃を防ぐ。
（Ｄ）ＵＥ側からのネットワークエレメント及びＳＣＳへのＤｏＳ攻撃を防ぐ。
（Ｅ）トリガ及びスモールデータ伝送は，ＮＡＳセキュリティから独立することができる。
（Ｆ）ＵＥは，何も変更することなく，ＷｉＦｉ，又はＭＴＣ−ＩＷＦとのインタフェースを有する他のネットワークエレメントを通じて，ＭＴＣ通信手段のセンターポイントとしてのＭＴＣ−ＩＷＦに接続することができる。
（Ｇ）ＭＴＣ−ＩＷＦは，３ＧＰＰにて議論されているＭＴＣに関するすべての問題に対処することができる。
【００２８】
　特定のＵＥのために，ＭＴＣ−ＩＷＦは，直接的にＭＭＥから，又は，ＨＳＳを介してＭＭＥからサービング（ｓｅｒｖｉｎｇ）ｅＮＢ情報を獲得することにより，サービングｅＮＢを見つけることができる。
ＭＴＣトリガ及びスモールデータは，Ｔ６インタフェース上で配信される。ＭＴＣ−ＩＷＦ及びＵＥは，セキュリティ・アソシエーションを確立し，トリガ及びスモールデータは，ＭＴＣ−ＩＷＦとＵＥとの間で共有されるキーで保護される。
（中略）
【００４２】
　２．プロトコルスタック及びメッセージフロー
　図４に，ローミングしないケースのメッセージフローを示す。スモールデータ及びデバイストリガのための３ＧＰＰネットワークのエンドポイントは，ＵＥ及びＭＴＣ−ＩＷＦである。
【００４３】
　スモールデータ及びデバイストリガを搬送するメッセージを伝送する方法は，２つある。
　１）図４に点線で示す，ｅＮＢ　２０とＭＴＣ−ＩＷＦ　５０との間のダイレクト・インタフェースＴ６を用いる方法。
　２）図４に一点鎖線で示す，バーチャル・インタフェースＴ６を用いる方法。
【００４４】
　
２）の方法では，
ｅＮＢ　２０及びＭＭＥ　３０は，メッセージがＳＤを搬送している場合，ＳＤを搬送しているより上位の（ｈｉｇｈｅｒ）レイヤプロトコル（すなわち，ＳＤＤＴＥ）があるか否かを検証し，ＮＡＳ及びＡＳセキュリティのための如何なる処理も実行せずに，前記メッセージを単に転送する。
【００４５】
　図５に，ダイレクト・インタフェースを用いることについての提案するプロトコルスタックを示す。その一方で，図６に，バーチャル・インタフェースを用いることについての提案するプロトコルスタックを示す。プロトコルＳＤＤＴＥは，ＵＥ　１０とＭＴＣ−ＩＷＦ　５０との間に広がり，ＭＭＥ／ＳＧＳＮ　３０に対して透過的であり得る。
【００４６】
　図５に示すように，インタフェースＴ６が，ｅＮＢ　２０とＭＴＣ−ＩＷＦ　５０との間のダイレクト・インタフェースであるとき，スモールデータ及びデバイストリガは，インタフェースＴ６上で直接伝送され，ｅＮＢ　２０とＵＥ　１０との間のＬＴＥ−Ｕｕ上で伝送される。
【００４７】
　図６に示すように，インタフェースＴ６が，バーチャル・インタフェースであるとき，スモールデータ及びデバイストリガは，Ｔ５，Ｓ１−ＭＭＥ，及びＬＴＥ−Ｕｕ上でホップ・バイ・ホップで伝送される。Ｔ５ソリューションと比較すると，本実施の形態では，ｅＮＢ　２０及びＭＭＥ　３０が，ＳＤを搬送している上位のプロトコル（ＳＤＤＴＥ）があると検証するとき，ＭＴＣ−ＩＷＦ　５０とｅＮＢ　２０との間でメッセージを単に転送する。
（中略）
【００６１】
　３．２．ＭＴスモールデータ伝送
　図８に，ＭＴ（Ｍｏｂｉｌｅ　Ｔｅｒｍｉｎａｔｅｄ）スモールデータ伝送フローを示す。ＭＴＣ−ＩＷＦ　５０は，スモールデータが生じることを知らせるためのスモールデータのインジケーション（ｉｎｄｉｃａｔｉｏｎ）を伴う通常のページング手順を使用するために，ＭＭＥ　３０をトリガする。ＭＴＣ−ＩＷＦ　５０がページングの応答を受信するとき，ＭＴＣ−ＩＷＦ　５０は，インタフェースＴ６上でスモールデータを送信する。ステップＳ２４，Ｓ２８，Ｓ２９，及びＳ３３は，新しいメッセージである。
【００６２】
　図８に示すように，
ＳＣＳ　６０は，Ｓｍａｌｌ　Ｄａｔａ　Ｓｕｂｍｉｓｓｉｏｎ　ＲｅｑｕｅｓｔをＭＴＣ−ＩＷＦ　５０へ送信する（ステップＳ２１）
【００６３】
　
ＭＴＣ−ＩＷＦ　５０は，ＳＣＳ　６０及びＵＥ　１０の承認を実行する（ステップＳ２２）
（中略）
【００８８】
　このとき，
ＭＴＣ−ＩＷＦ　５０は，Ｔ６接続を解放することをｅＮＢ　２０に示す（ステップＳ６２）。Ｔ６接続が解放されたとき，ｅＮＢ　２０は，スモールデータ及びデバイストリガのための関連情報を削除する。なお，この手順は，バーチャル・インタフェースＴ６が使用されているときのＭＭＥ　３０にも適用される。
（中略）
【図４】
（中略）
【図８】
」
第５　当審の判断
１　当審拒絶理由「１（１）」について
　上記第４の図８のＳ２１によると，ＭＴＣ−ＩＷＦ（Ｍａｃｈｉｎｅ−Ｔｙｐｅ−Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｉｎｔｅｒ−Ｗｏｒｋｉｎｇ　Ｆｕｎｃｔｉｏｎ）はＳＣＳに直接接続されるものであることが見て取れること，及び，上記第４の段落００６２，００６３によると，ＳＣＳからＳｍａｌｌ　Ｄａｔａ　Ｓｕｂｍｉｓｓｉｏｎ　ＲｅｑｕｅｓｔメッセージがＭＴＣ―ＩＷＦへ送信され，前記ＭＴＣ−ＩＷＦがＳＣＳの承認を実行することが記載されているといえるから，請求項１の「ノード」は，発明の詳細な説明のＭＴＣ−ＩＷＦに対応することは明らかである。
　そして，請求項１の「ＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）と，前記ノード間のセキュアな接続を確立することによって，スモールデータを前記ＭＭＥ又は前記ＳＧＳＮへ送信」することに関し，上記第４の段落００２８，００４３，００４４，及び図４によると，スモールデータをＭＴＣ−ＩＷＦとＵＥとの間で共有されるキーで保護するとともに，ＭＴＣ−ＩＷＦとｅＮＢとを接続するバーチャル・インタフェースＴ６を用いてスモールデータを搬送し，前記スモールデータを搬送している場合は，ＭＭＥは，ＮＡＳ及びＡＳセキュリティのための如何なる処理も実行せずに，前記スモールデータを搬送しているメッセージを単に転送することが記載されているといえるが，請求項１のＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間での「セキュアな接続を確立する」ことについては，発明の詳細な説明には記載されていない。
　そして，上記第４の段落００２８，００４３，００４４，及び図４に記載の前記事項は，上記第４の段落０００６，００２７に記載の「セキュリティ処理のためＮＡＳレイヤ及びＭＭＥへの負荷を増大する」との課題を解決するためのものであるといえるところ，仮に，前記バーチャル・インタフェースＴ６のために，ＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間で接続を確立するものであるとしても，ＭＴＣ−ＩＷＦとＵＥとの間で共有されるキーでの保護に更に加えて，ＭＭＥとＭＴＣ−ＩＷＦ間の接続を「セキュアな接続」とすることは，セキュリティ処理によってＭＭＥの負荷を増大させることが明らかであるから，前記課題を解決しておらず，当業者にとって自明とはいえない。
　また，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮとノード間での「セキュアな接続を確立する」ことの具体的な処理内容が記載されておらず，実施可能な程度に記載されているとはいえない。
　したがって，本願発明は，発明の詳細な説明に記載したものではなく，また，発明の詳細な説明に実施可能な程度に記載されていない。
２　当審拒絶理由「１（２）」について
　請求項１の「前記ＭＭＥ又は前記ＳＧＳＮに，前記スモールデータ接続のための関連情報を削除させる」ことに関し，上記第４の段落００８８には，ＭＭＥは，バーチャル・インタフェースＴ６が解放されたときに，前記スモールデータ接続のための関連情報を削除することが記載されている。
　しかしながら，発明の詳細な説明には，ＭＭＥが削除する「スモールデータ接続のための関連情報」について，ＭＭＥが記憶しているどのような情報であるのか具体的に記載されておらず不明確であり，発明の技術的範囲も不明確である。
　また，発明の詳細な説明には，どのような「スモールデータ接続のための関連情報」を削除するのかについても記載されておらず，実施可能な程度に記載されているとはいえない。
　したがって，本願発明は，不明確であり，また，発明の詳細な説明に実施可能な程度に記載されていない。
３　当審拒絶理由「１（３）」について
　本願のＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ）と，前記ノード間の「セキュアな接続を解放する」ことに関し，上記第４の段落００８８によると，ＭＴＣ−ＩＷＦとｅＮＢとの間のバーチャル・インタフェースＴ６を解放することが記載されているが，ＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間の接続を解放することは記載されていない。
　さらに，上記１のとおり，バーチャル・インタフェースＴ６でのＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間の接続が「セキュアな接続」であるとは，発明の詳細な説明に記載されておらず，自明であるともいえない。
　そうすると，請求項１のＭＭＥ又はＳＧＳＮと，ノード間の「セキュアな接続を解放する」ことについて，発明の詳細な説明には記載したものとはいえない。
　また，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮと，ノード間の「セキュアな接続を解放する」ことの具体的な処理内容が記載されていないことから，実施可能な程度に記載されているとはいえない。
　したがって，本願発明は，発明の詳細な説明に記載したものではなく，また，発明の詳細な説明に実施可能な程度に記載されていない。
［請求人の主張について］
　請求人は，令和２年１月８日に提出された意見書において，
「（１）「セキュアな接続」について（中略）
　ＵＥとＭＴＣ−ＩＷＦとの間がセキュアな接続であり（００２８段落参照），ｅＮＢ２０とＵＥ１０との間がＡＳによるセキュアな接続である（００３０段落参照）とすると，当然に，ＭＴＣ−ＩＷＦとＭＭＥ／ＳＧＳＮとの間のインタフェースＴ５，及びＭＭＥ／ＳＧＳＮとｅＮＢとの間のインタフェースＳ１もセキュアな接続であるものと思料いたします。すなわち，ＭＴＣ−ＩＷＦとＭＭＥ／ＳＧＳＮとの間の接続は，セキュアな接続であるものと思料いたします。（中略）
（２）「前記スモールデータに関する情報」について（中略）
　該補正により，削除させる情報が，スモールデータ接続のための関連情報であることが明確になり，また，実施可能な程度に記載しているものとなりました。（中略）
（３）「前記ＭＭＥ又は前記ＳＧＳＮと，前記ノード間のセキュアな接続を解放する」に
ついて（中略）
　本願の明細書の００８７段落には，「図１０に示すように，ＭＴＣ−ＩＷＦ　５０にて，Ｔ６接続解放タイマが満了する（ステップＳ６１）。」と記載され，００８８段落には，「このとき，ＭＴＣ−ＩＷＦ　５０は，Ｔ６接続を解放することをｅＮＢ　２０に示す（ステップＳ６２）。Ｔ６接続が解放されたとき，ｅＮＢ　２０は，スモールデータ及びデバイストリガのための関連情報を削除する。なお，この手順は，バーチャル・インタフェースＴ６が使用されているときのＭＭＥ３０にも適用される。」と記載されています。すなわち，本願の明細書の００８８段落には，「ＭＭＥ又はＳＧＳＮとノード間のセキュアな接続を解放すること」が記載されているものと思料いたします。」
と主張している。
（１）「セキュアな接続」について
　上記１のとおり，請求項１のＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間での「セキュアな接続を確立する」ことについて，発明の詳細な説明には記載されておらず，仮に，発明の詳細な説明に記載されたバーチャル・インタフェースＴ６のために，ＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間で接続を確立するものであるとしても，ＭＭＥとＭＴＣ−ＩＷＦ間の接続を「セキュアな接続」とすることは，セキュリティ処理によってＭＭＥの負荷を増大させることが明らかであるから，上記第４の段落０００６，００２７に記載の「セキュリティ処理のためＮＡＳレイヤ及びＭＭＥへの負荷を増大する」との課題を解決しておらず，当業者にとって自明とはいえない。
　また，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮとノード間での「セキュアな接続を確立する」ことの具体的な処理内容が記載されておらず，実施可能な程度に記載されているとはいえない。
（２）「前記スモールデータに関する情報」について
　上記２のとおり，発明の詳細な説明には，ＭＭＥが削除する「スモールデータ接続のための関連情報」について，ＭＭＥが記憶しているどのような情報であるのか記載されておらず不明確であり，また，発明の詳細な説明には，どのような「スモールデータ接続のための関連情報」を削除するのかについても記載されておらず，実施可能な程度に記載されているとはいえない。
（３）「前記ＭＭＥ又は前記ＳＧＳＮと，前記ノード間のセキュアな接続を解放する」について
　上記３のとおり，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮとＭＴＣ−ＩＷＦ間の接続を解放することは記載されておらず，かつ，「セキュアな接続」についても記載されているとはいえないため，ＭＭＥ又はＳＧＳＮと，ノード間の「セキュアな接続を解放する」ことは，発明の詳細な説明には記載されていない。
　また，発明の詳細な説明には，ＭＭＥ又はＳＧＳＮと，ノード間の「セキュアな接続を解放する」ことの具体的な処理内容が記載されていないことから，実施可能な程度に記載されているとはいえない。
　よって，請求人の上記主張は，採用できない。
第６　むすび
　以上のとおり，本件出願は，発明の詳細な説明の記載が，特許法第３６条第４項第１号に規定する要件を満たしておらず，特許請求の範囲の記載が，特許法第３６条第６項第１号又は第２号に規定する要件を満たしていないから，特許を受けることができない。
　したがって，本願は，他の請求項について検討するまでもなく，拒絶すべきものである。
　よって，結論のとおり審決する。