【事件の表示】
　特願２００７−　４３９６３「データ復号処理プログラム」拒絶査定不服審判事件〔平成２０年　９月１１日出願公開、特開２００８−２１００１２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　
　本件審判請求に係る出願（以下、「本願」という。）は、平成１９年２月２３日の出願であって、平成２１年１１月１０日付けで審査請求がなされ、平成２３年９月３０日付けで拒絶理由が通知（同年１０月１１日発送）され、同年１２月１２日付けで意見書が提出されるとともに、同日付けで手続補正がなされたが、同年１２月２６日付けで拒絶査定（平成２４年１月１０日謄本送達）がなされた。　
　これに対して、本件審判請求は、「原査定を取り消す、本願は特許をすべきものであるとの審決を求める。」ことを請求の趣旨として、平成２４年４月１０日付けで審判請求がなされるとともに、同日付けで手続補正がなされ、同年６月１２日付けで審査官により特許法第１６４条第３項に定める報告（前置報告）がなされ、平成２５年１月２４日付けで当審により特許法第１３４条第４項の規定に基づく審尋（同年１月２９日発送）がなされ、同年３月２９日付けで回答書の提出があったものである。　
　そして、平成２５年１０月９日付けで当審により拒絶理由が通知（同年１０月１５日発送）され、同年１２月１６日付けで意見書が提出されるとともに、同日付けで手続補正がなされた。　
　
　
第２　本件審判請求の成否について
　
１．本願発明
　
　本願の特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、上記平成２５年１２月１６日付け手続補正書により補正された明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。　
　
「平文データを暗号化した暗号化データと、通信されるデータのデータサイズの情報を備える通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラムにおいて、　
　コンピュータを、　
　予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第１の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第２の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する準備手段、　
　前記第１の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第２の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納するデータ格納手段、　
　前記第１の格納領域に格納された前記暗号化データから前記平文データを復号する復号手段、　
　として機能させることを特徴とするデータ復号処理プログラム。」　
　
　
２．引用文献
　
（２−１）引用文献１に記載されている技術的事項及び引用発明の認定
　
　本願の出願日前に頒布され、当審の平成２５年１０月９日付けの拒絶理由通知において引用された、特開２００４−３６４０２２号公報（平成１６年１２月２４日出願公開、以下、「引用文献１」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ａ　「【０００５】　
本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御方式を提供することを目的とする。
【０００６】　
【課題を解決するための手段】　
本発明の第一の観点によると、
アプリケーション層のデータをブロック暗号化し、それをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットに分割して送信する暗号化送信手段と、トランスミッション・コントロール・プロトコルのパケットを受信して暗号化データを組み立て、アプリケーション層のデータに復号化し、メッセージ認証コードを計算して改竄されていないことを検証する受信復号化手段とを備えた暗号化通信制御方式
　
Ｂ　「【０００９】　
【発明の実施の形態】　
図１は本発明の実施形態を示すブロック構成図である。
本発明は、図１に示すような、インターネット４からサーバ５に向かうＳＳＬトラフィックを復号化し、サーバ５からインターネット４へ出て行くトラフィックを暗号化するＳＳＬ通信装置１で実施される。このＳＳＬ通信装置１は、インターネット４からサーバ５への受信プロセスを担当する復号回路２と、サーバ５からインターネット４への送信プロセスを担当する暗号回路３とからなる。
　
Ｃ　「【００１１】　
図３はＳＳＬフォーマットを示す。ＳＳＬブロックは、ＳＳＬヘッダ、ペイロード、ＭＡＣ（メッセージ認証コード）、パディングおよびパディング長により構成される。データ部分（ペイロード）は最大１８ＫＢまで許容されており、このデータ全体にわたってハッシュ値を計算して、ＳＳＬ内のＭＡＣと比較することで改竄の有無を調べる。
　
Ｄ　「【００１４】　
図７は復号回路２の詳細を示すブロック構成図である。この復号回路２は、識別部２０１、ＳＳＬ受信バッファ２０２、復号化スケジューラ２０３、復号化処理部２０４、平文メモリ２０５、ハッシュスケジューラ２０６、ハッシュ計算処理部２０７、ハッシュメモリ２０８、平文送信処理部２０９およびセッションテーブル２１０を備える。
【００１５】　
識別部２０１は受信したトラフィックがどこからきたものであるかを判別する。この識別されたトラフィックをフローと呼ぶ。
識別部２０１で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはＳＳＬ受信バッファ２０２に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ２０３でスケジュールされ、復号化処理部２０４で復号化処理される。
復号化処理部２０４による復号化処理を終えたデータは平文メモリ２０５に格納される。
　
Ｅ　「【００２０】　
図７に示した復号回路２の動作についてさらに詳しく説明する。　
【００２１】　
図９はＳＳＬ受信バッファ２０２の処理のフローチャートを示し、図１０は復号化スケジューラ２０３の処理のフローチャートを示す。これらの処理は復号化処理部２０４の処理に連動する。　
【００２２】　
ＳＳＬ受信バッファ２０２では、ＴＣＰで運ばれてきた図３に示したようなＳＳＬブロックを格納する。このとき、ＳＳＬヘッダから読み取れられＳＳＬブロックの長さをSSL_Length、
【００２３】　
ＳＳＬ受信バッファ２０２は、受信開始後、ＳＳＬ暗号データをネットワークより受信し（ステップＡ１）、それがＳＳＬブロックの先頭であれば（ステップＡ２）そのブロック用の領域を確保し
　
　ここで、上記引用文献１に記載されている事項を検討する。　
　
（ア）上記Ａの「本発明は、このような課題を解決し、遅延を低減できる暗号化通信制御方式を提供することを目的とする。…（中略）…アプリケーション層のデータをブロック暗号化し、それをトランスポート層であるトランスミッション・コントロール・プロトコルのパケットに分割して送信する暗号化送信手段と、トランスミッション・コントロール・プロトコルのパケットを受信して暗号化データを組み立て、アプリケーション層のデータに復号化し、メッセージ認証コードを計算して改竄されていないことを検証する受信復号化手段とを備えた暗号化通信制御方式」との記載、上記Ｂの「本発明は、図１に示すような、インターネット４からサーバ５に向かうＳＳＬトラフィックを復号化し、サーバ５からインターネット４へ出て行くトラフィックを暗号化するＳＳＬ通信装置１で実施される。このＳＳＬ通信装置１は、インターネット４からサーバ５への受信プロセスを担当する復号回路２と、サーバ５からインターネット４への送信プロセスを担当する暗号回路３とからなる。」との記載からすると、ＳＳＬ通信装置の復号回路によりＳＳＬトラフィックを復号化する暗号化通信制御方式が記載されていると解される。また、上記Ｃの「図３はＳＳＬフォーマットを示す。ＳＳＬブロックは、ＳＳＬヘッダ、ペイロード、ＭＡＣ（メッセージ認証コード）、パディングおよびパディング長により構成される。データ部分（ペイロード）は最大１８ＫＢまで許容されており、このデータ全体にわたってハッシュ値を計算して、ＳＳＬ内のＭＡＣと比較することで改竄の有無を調べる。」との記載からすると、ＳＳＬトラフィックはＳＳＬブロックデータにより送受信され、該ＳＳＬブロックは、平文データを暗号化したデータ部分（ペイロード）と、ＳＳＬヘッダと、ＭＡＣ（メッセージ認証コード）と、パディングなどにより構成されることは明らかであるから、引用文献１には、　
「平文データを暗号化したデータ部分（ペイロード）と、ＳＳＬヘッダと、ＭＡＣ（メッセージ認証コード）と、パディングとを含むＳＳＬブロックを復号回路で受信して復号化する処理を実行する暗号化通信制御方式」　
が記載されていると解される。
　
（イ）上記Ｄの「図７は復号回路２の詳細を示すブロック構成図である。この復号回路２は、識別部２０１、ＳＳＬ受信バッファ２０２、復号化スケジューラ２０３、復号化処理部２０４、平文メモリ２０５、ハッシュスケジューラ２０６、ハッシュ計算処理部２０７、ハッシュメモリ２０８、平文送信処理部２０９およびセッションテーブル２１０を備える。　…（中略）…。識別部２０１で認識するフロー毎にバッファが割り当てられている。識別されたトラフィックはＳＳＬ受信バッファ２０２に入り」との記載、上記Ｅの「ＳＳＬ受信バッファ２０２では、ＴＣＰで運ばれてきた図３に示したようなＳＳＬブロックを格納する。…（中略）…。ＳＳＬ受信バッファ２０２は、受信開始後、ＳＳＬ暗号データをネットワークより受信し（ステップＡ１）、それがＳＳＬブロックの先頭であれば（ステップＡ２）そのブロック用の領域を確保し」との記載からすると、復号回路は受信したＳＳＬトラフィックであるＳＳＬブロックを格納するＳＳＬ受信バッファを備え、ＳＳＬブロックをネットワークより受信し、受信したデータがＳＳＬブロックの先頭であればＳＳＬ受信バッファにそのブロック用の領域を確保すると解されるから、引用文献１には、　
「復号回路を、ネットワークよりＳＳＬブロックを受信し、それがＳＳＬブロックの先頭であれば、ＳＳＬ受信バッファにそのブロック用の領域を確保し、受信したＳＳＬブロックを前記ＳＳＬ受信バッファに格納する手段として機能させること」　
が記載されていると解される。　
　
（ウ）上記Ｄの「識別されたトラフィックはＳＳＬ受信バッファ２０２に入り、フローごとに割り当てられた処理性能で処理が行われるように復号化スケジューラ２０３でスケジュールされ、復号化処理部２０４で復号化処理される。…（中略）…。復号化処理部２０４による復号化処理を終えたデータは平文メモリ２０５に格納される。」の記載からすると、復号回路の復号化処理部は、ＳＳＬ受信バッファに格納されたＳＳＬブロックを平文に復号化すると解されるから、引用文献１には、　
「復号回路を、ＳＳＬ受信バッファに格納されたＳＳＬブロックを復号化処理部で平文に復号化する手段として機能させること」　
が記載されていると解される。　
　
　以上、（ア）乃至（ウ）で指摘した事項から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認める。
　
「平文データを暗号化したデータ部分（ペイロード）と、ＳＳＬヘッダと、ＭＡＣ（メッセージ認証コード）と、パディングとを含むＳＳＬブロックを復号回路で受信する処理を実行する暗号化通信制御方式であって、　
　前記復号回路を、　
　ネットワークよりＳＳＬブロックを受信し、それがＳＳＬブロックの先頭であれば、ＳＳＬ受信バッファにそのブロック用の領域を確保し、受信したＳＳＬブロックを前記ＳＳＬ受信バッファに格納する手段、　
　前記ＳＳＬ受信バッファに格納されたＳＳＬブロックを復号化処理部で平文に復号化する手段、　
として機能させることを特徴とする暗号化通信制御方式。」　
　
（２−２）引用文献２に記載されている技術的事項
　
　本願の出願日前に頒布され、当審の平成２５年１０月９日付けの拒絶理由通知において引用された、特開２００４−１４０５４６号公報（平成１６年５月１３日出願公開、以下、「引用文献２」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）　
　
Ｆ　「【００４０】　
サービス情報管理テーブル６００の更新日時の方が新しければ、サービス情報ファイル３８から該当するサービス情報（コンテンツデータ）を読出し、
コンテンツＩＤ、更新日時、データ長等の情報をヘッダ部に含むデータパケットを生成して、情報チャネルｆ２ｘに送信する（４１２）
　
（２−３）引用文献３に記載されている技術的事項
　
　本願の出願日前に頒布され、当審の平成２５年１０月９日付けの拒絶理由通知において引用された、特開２００６−１８９９３７号公報（平成１８年７月２０日出願公開、以下、「引用文献３」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ｇ　「【００２４】　
　
本実施の形態においては、バッファ制御回路１３は、受信バッファ１２における各データタイプ毎の領域の割り当てを変更することができるようになっている。図１の斜線部は各データタイプに割り当てられた領域の初期値を示している。領域１２ａ内の無地の領域ＰＨは、データタイプＰＨに対して初期状態から増大させた領域を示している。
【００２５】　
　バッファ制御回路１３は、受信したＴＬＰのデータタイプの統計、即ち、トラフィックの統計を求める。
バッファ制御回路１３は、求めたトラフィック統計に基づいて、受信バッファ１２の各領域の容量を増大させるか否かの決定及び増大させる量の決定を行うようになっている。
　
Ｈ　「【００２８】　
　
受信装置１１はフロー制御の初期化時において、送信装置１からのデータ伝送に最低限必要な容量を受信バッファ１２に設定する。この場合には、バッファ制御回路１３は、データタイプ毎の伝送量の予測が可能であれば、その予測に従って特定のデータタイプのクレジット値及び受信バッファの確保領域を他のデータタイプのものよりも大きく設定してもよい。
　
（２−４）引用文献４に記載されている技術的事項
　
　本願の出願日前に頒布され、当審の平成２５年１０月９日付けの拒絶理由通知において引用された、特開２００１−３０６４８２号公報（平成１３年１１月２日出願公開、以下、「引用文献４」という。）には、関連する図面とともに、以下の技術的事項が記載されている。
　（当審注：下線は、参考のために当審で付与したものである。）
　
Ｊ　「【００１８】　
【発明の実施の形態】以下、図を用いて本発明の実施の形態について説明する。なお、これにより本発明が限定されるものではない。図１は、本発明の一実施形態に係る入出力制御装置１００の構成図である。
この入出力制御装置１００は、ファブリックＦａからのフレームを受信しそのフレームをヘッダ部とデータ部とに分けるデータ入力レジスタ１１１と、前記ヘッダ部を格納するヘッダ用受信バッファ１０３と、前記データ部を格納するデータ用受信バッファ１０２と
　
　
３．対比
　
　本願発明と引用発明とを対比する。
　
（３−１）引用発明の「平文データを暗号化したデータ部分（ペイロード）」は本願発明の「平文データを暗号化した暗号化データ」に相当し、引用発明の「平文データを暗号化したデータ部分（ペイロード）」を含む「ＳＳＬブロック」は、本願発明の「平文データを暗号化した暗号化データ」を有する「通信用暗号化データ」に対応する。そして、引用発明の「ＳＳＬヘッダ」は、引用文献１の上記Ｅの「ＳＳＬ受信バッファ２０２では、ＴＣＰで運ばれてきた図３に示したようなＳＳＬブロックを格納する。このとき、ＳＳＬヘッダから読み取れられＳＳＬブロックの長さをSSL_Length」との記載からすると、「ＳＳＬブロック」に関するデータサイズの情報を含んでいることから、本願発明の「通信されるデータのデータサイズの情報を備える通信用データ」に対応し、両者はともに、“データサイズの情報を含む通信用データ”である点で共通するといえる。　
　また、引用文献１の上記Ｂの「このＳＳＬ通信装置１は、インターネット４からサーバ５への受信プロセスを担当する復号回路２」との記載、上記Ｄの「図７は復号回路２の詳細を示すブロック構成図である。この復号回路２は、識別部２０１、ＳＳＬ受信バッファ２０２、復号化スケジューラ２０３、復号化処理部２０４、平文メモリ２０５、ハッシュスケジューラ２０６、ハッシュ計算処理部２０７、ハッシュメモリ２０８、平文送信処理部２０９およびセッションテーブル２１０を備える。」との記載からすると、引用発明の「暗号化通信制御方式」は、コンピュータを含む「復号回路」が、復号処理プログラムである「受信プロセス」を実行しているといえる。　
　してみると、引用発明の「平文データを暗号化したデータ部分（ペイロード）と、ＳＳＬヘッダと、ＭＡＣ（メッセージ認証コード）と、パディングとを含むＳＳＬブロックを復号回路で受信する処理を実行する暗号化通信制御方式」と、本願発明の「平文データを暗号化した暗号化データと、通信されるデータのデータサイズの情報を備える通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラム」は、ともに、“平文データを暗号化した暗号化データと、データサイズの情報を含む通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラム”である点で共通するといえる。　
　
（３−２）引用発明の「復号回路」は復号化の処理を実行することから、本願発明の「コンピュータ」に対応する。また、引用発明の「ＳＳＬ受信バッファ」は、「ＳＳＬブロック」を格納するために「復号回路」が備えていることから、本願発明の「コンピュータが備える一時記憶手段」に相当し、両者はともに、暗号化データを受信すると格納領域を準備する点で共通するといえる。　
　してみると、引用発明の「ネットワークよりＳＳＬブロックを受信し、それがＳＳＬブロックの先頭であれば、ＳＳＬ受信バッファにそのブロック用の領域を確保し」と、本願発明の「予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第１の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第２の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する準備手段」は、ともに、“コンピュータが備える一時記憶手段に格納領域を準備する”点で共通するといえる。　
　
（３−３）引用発明の「復号回路」は受信した「ＳＳＬブロック」を「ＳＳＬ受信バッファ」の確保した領域に格納することから、引用発明の「受信したＳＳＬブロックを前記ＳＳＬ受信バッファに格納する」と、本願発明の「前記第１の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第２の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納するデータ格納手段」は、ともに、“受信した通信用暗号化データを格納領域に格納する”点で共通するといえる。　
　
（３−４）引用発明の「復号回路」は、暗号化データを含む「ＳＳＬブロック」を平文に復号化することから、引用発明の「前記ＳＳＬ受信バッファに格納されたＳＳＬブロックを復号化処理部で平文に復号化する」と、本願発明の「前記第１の格納領域に格納された前記暗号化データから前記平文データを復号する復号手段」は、ともに、“格納領域に格納された暗号化データから平文データを復号する”点で共通するといえる。　
　
　以上から、本願発明と引用発明とは、以下の点で一致し、また、以下の点で相違する。 
　
（一致点） 
　
「平文データを暗号化した暗号化データと、データサイズの情報を含む通信用データとを有する通信用暗号化データを受信する際の処理を行うためのデータ復号処理プログラムにおいて、
　コンピュータを、
　前記コンピュータが備える一時記憶手段に格納領域を準備する手段、　
　受信した前記通信用暗号化データを前記格納領域に格納する手段、　
　前記格納領域に格納された暗号化データから平文データを復号する手段、
として機能させることを特徴とするデータ復号処理プログラム。」　
　
（相違点１）
　
　通信用暗号化データに含まれる通信用データに関して、本願発明の「通信用データ」は通信されるデータのデータサイズの情報を備えているのに対して、引用発明の「ＳＳＬヘッダ」は「ＳＳＬブロック」に関するデータサイズの情報を含んでいるが、通信されるデータのデータサイズかどうかは不明である点。
　
（相違点２）
　
　通信用暗号化データの格納領域の準備に関し、本願発明では、「予め用意された前記平文データのサイズに基づいて前記コンピュータが備える一時記憶手段に準備される第１の格納領域以外の、前記通信用暗号化データに含まれるデータを格納する第２の格納領域を、暗号化方式により規定され、前記予め用意されたサイズに比べて増加し得るサイズに基づいて準備する」のに対して、引用発明では、「ネットワークよりＳＳＬブロックを受信し、それがＳＳＬブロックの先頭であれば、ＳＳＬ受信バッファにそのブロック用の領域を確保」するものの、領域の確保のしかたについて詳細が不明である点。
　
（相違点３）
　
　通信用暗号化データの格納に関し、本願発明では、「前記第１の格納領域に前記通信用暗号化データに含まれる前記暗号化データを格納し、前記第２の格納領域に前記通信用暗号化データに含まれる前記通信用データを格納」し、「前記第１の格納領域に格納された前記暗号化データから前記平文データを復号する」のに対して、引用発明では、「受信したＳＳＬブロックを前記ＳＳＬ受信バッファに格納」し、「前記ＳＳＬ受信バッファに格納されたＳＳＬブロックを復号化処理部で平文に復号化する」ものの、「ＳＳＬ受信バッファ」への格納のしかた、復号化される「ＳＳＬブロック」の「ＳＳＬ受信バッファ」での格納領域についての詳細が不明である点。
　
　
４．当審の判断
　
　上記相違点１乃至相違点３について検討する。
　
（４−１）相違点１について　
　
　データ長をヘッダ部に含むデータパケットを生成して、通信されるデータのデータサイズの情報を含む通信用データを送受信する旨の技術は、例えば、引用文献２（上記Ｆ参照）に記載されているように、本願出願前にはデータ通信の技術分野における周知の技術的事項であった。
　そして、引用発明においても、「ＳＳＬヘッダ」は「ＳＳＬブロック」に関するデータサイズの情報を含んでいることから、復号回路で受信するＳＳＬブロックの中に通信されるデータのデータサイズの情報を含むようにすること、すなわち、上記相違点１に係る構成とすることは、当業者が容易に想到し得たことである。 
　
　よって、相違点１は格別なものではない。　
　
（４−２）相違点２及び相違点３について　
　
　引用発明において、復号回路のＳＳＬ受信バッファに格納するＳＳＬブロックは、平文データを暗号化したデータ部分（ペイロード）以外に、ＳＳＬヘッダ、ＭＡＣ（メッセージ認証コード）、パディングなどの暗号化方式により規定されるデータを含んでおり、復号回路はネットワークよりＳＳＬブロックを受信し、それがＳＳＬブロックの先頭であれば、ＳＳＬ受信バッファにそのブロック用の領域を確保していることから、平文データを暗号化したデータ部分以外の暗号化方式により規定されるデータのサイズも考慮して、格納領域の確保を行っているといえる。　
　また、引用文献３（上記Ｇ，Ｈ参照）に記載されているように、データ伝送の受信装置における受信バッファの制御について、受信したデータタイプ毎に初期状態の領域のほか、増大させた領域を割り当て、必要容量を確保する旨の技術は、本願出願前にはデータ通信技術の分野における周知の技術的事項であった。さらに、引用文献４（上記Ｊ参照）に記載されているように、入出力制御装置における受信バッファを、ヘッダ部を格納するヘッダ用受信バッファと、データ部を格納するデータ用受信バッファに分けて構成する旨の技術も、本願出願前にはデータ通信技術の分野における周知の技術的事項であった。　
　してみると、暗号化方式は一種のデータタイプとみることができるから、引用発明においても、ＳＳＬ受信バッファにそのブロック用の領域を確保するに当たって当該周知技術を適用し、適宜、平文データのサイズに基づいてＳＳＬ受信バッファに予め準備される第１の格納領域以外に、暗号化方式により規定されるデータを格納する増大した第２の格納領域を増加し得るサイズに基づいて準備し、前記第１の格納領域に格納した暗号化したデータ部分（ペイロード）は平文に復号化し、前記第２の格納領域には、データサイズの情報を含むＳＳＬヘッダを格納すること、すなわち、上記相違点２及び相違点３に係る構成とすることは、当業者が容易に想到し得たことである。　
　
　よって、相違点２及び相違点３は格別なものではない。
　
　上記で検討したごとく、相違点１乃至相違点３は格別のものではなく、そして、この相違点を総合的に勘案しても、本願発明の奏する作用効果は、上記引用発明及び引用文献２乃至４に記載の周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　
　
５．むすび 
　
　以上のとおり、本願の請求項１に係る発明は、特許法第２９条第２項の規定により特許を受けることができないものであるから、その余の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。 
　
よって、結論のとおり審決する。