【事件の表示】
　特願２００９−５４２７４１「インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法」拒絶査定不服審判事件〔平成２０年　６月２６日国際公開、ＷＯ２００８／０７６１２５、平成２２年　４月３０日国内公表、特表２０１０−５１４３４８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、２００６年１２月２１日を国際出願日とする出願であって、平成２４年９月６日に拒絶査定がなされ、これに対し、平成２５年１月１１日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成２５年１月１１日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正（以下、「本件補正」という。）は、本件補正前の平成２４年５月２１日付けの手続補正書の特許請求の範囲の請求項１に記載された、
　
　「【請求項１】
　リアルタイムメディアを保護する方法であって、
　メディアパケットを受信し、
　前記メディアパケットからメディアビット列を生成し、
　前記メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成し、
　前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成し、
　前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し、
　前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離された、前記生成された前方誤り訂正パケットを送信することを有する方法。」
　
という発明（以下、「本願発明」という。）を、平成２５年１月１１日付け手続補正書の特許請求の範囲の請求項１に記載された、
　
　「【請求項１】
　リアルタイムメディアを保護する方法であって、
　メディアパケットを受信し、
　前記メディアパケットからメディアビット列を生成し、
　前記メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成し、
　前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成し、
　前記前方誤り訂正ビット列から前方誤り訂正データを生成し、
　前方誤り訂正パケットを送信することを有し、
　前記前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前記生成された前方誤り訂正データとを含み、
　前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され、
　前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、
　前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す方法。」
　
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、本願発明の「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し、」を「前記前方誤り訂正ビット列から前方誤り訂正データを生成し、」とするとともに、「前方誤り訂正パケット」の構成に関して、「前記前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前記生成された前方誤り訂正データとを含み、」とし、さらに、「前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され、前記前方誤り訂正パケットヘッダは、前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含み、前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す」として特許請求の範囲を減縮するものである。
　したがって、本件補正は、特許法第１７条の２第３項（新規事項）及び平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項（補正の目的）の規定に適合している。
　
３．独立特許要件について
　本件補正は特許請求の範囲の減縮を目的とするものであるから、補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
（２）引用発明
　原審の拒絶理由に引用された、相原玲二　他，ＨＤＴＶ　ＭＰＥＧ２　ｏｖｅｒ　ＩＰｖ６システムの開発，情報処理学会研究報告，日本，社団法人情報処理学会，２００２年１０月，Ｖｏｌ．２００２　Ｎｏ．９３，ｐｐ７−１２（以下、「引用例」という。）には、図面とともに以下の事項が記載されている。
　イ．「２　ＳＤＴＶ　ＭＰＥＧ２　ｏｖｅｒ　ＩＰｖ６システム
　我々が構築してきたＳＤＴＶ　ＭＰＥＧ２　ｏｖｅｒ　ＩＰｖ６伝送システムはＭＰＥＧ２トランスポートストリーム（以下ＭＰＥＧ２−ＴＳ）形式の動画像データをＩＰｖ４／ＩＰｖ６ネットワークを通して伝送するシステムであり、ＩＰｓｅｃやＩＰマルチキャストにも対応している。しかし、ＭＰＥＧ２は画像フレーム間圧縮により高圧縮率を実現しているためわずかのパケット損失でも画像の乱れが顕著に現れるため、広域ネットワークでの使用を考えるとパケット損失対策が必須であることが分かっている。そこで、我々はＦＥＣ（Forward Error Correction：前方誤り訂正）を導入することによりこの点の改善を図った。」（８頁左欄２２行〜３４行）
　
　ロ．「２．１　システムの処理概要
　本システムの処理概要を図１に示す。
　（略）
　以下、送信側と受信側の動作を簡単に示す。送信側ではＮＴＳＣ信号をエンコーダによりＭＰＥＧ２−ＴＳへ変換し、ＴＳパケット（ＭＰＥＧ２−ＴＳを伝送する際の固定長最小基本構成単位）偶数個をカプセル化して固定長データを作る。ＦＥＣ部において固定長データから冗長パケットを生成し、順に送信キューに格納する。最後にＦＥＣ，ＲＴＰ，ＵＤＰ，ＩＰの各ヘッダを付加しＩＰパケットを構成した後、ネットワークインターフェイスからＩＰネットワークを介して受信ノードに転送する。
　（略）
　本システムでのパケットフォーマットを図２に示す。ＩＰ version ６、ＩＰマルチキャストにも対応しており、ＵＤＰとＲＴＰを用いる。ＲＴＰ（Real Time Transport Protocol）[11]はリアルタイム性の要求されるマルチメディアデータの伝送に用いられる。システムでは、ＦＥＣヘッダはＲＴＰの拡張ヘッダとして実装している。ＲＴＰ拡張に対応していない受信ノードではこのＦＥＣヘッダは無視され、冗長パケットの付加されてない通常のＭＰＥＧ２−ＴＳとして受信可能である。ペイロードにはＭＰＥＧ２−ＴＳパケットを偶数個カプセル化する。」（８頁左欄３５行〜右欄２５行）
　
　ハ．「３　ＲＦＣ２７３３準拠ヘッダフォーマット
　これまで構築してきたシステムでは、基本伝送における性能評価に重点をおいていたため、２．１に示したような独自フォーマットを採用してきた。そのため、ＦＥＣ処理の対象としては固定長データのみの対応に留まり、さらにＲＴＰヘッダは冗長化の対象外となっていた。
　一方、パリティ符号化を用いるＦＥＣのためのＲＴＰフォーマットがＲＦＣ２７３３[13]として標準化されている。ＲＦＣ２７３３ではＲＴＰヘッダの特定フィールドについても冗長化され、可変長データにも対応している。また、データパケットと冗長パケットは別ストリームとして伝送され、後方互換性を提供する。しかし、パリティ符号化はReed-Solomon符号方式に比べ、冗長度に対する誤り訂正能力は低い[3]。
　そこで、我々はReed-Solomon符号を用いるＦＥＣのためのＲＴＰフォーマットを新たに提案し、動画像伝送システムへの実装を行った。」（９頁左欄２２行〜３８行）
　
　ニ．「３．１　パケットフォーマット
　提案するパケットフォーマットを図５に示す。メディアパケット（media packet）は送信元から伝送されるユーザデータで、冗長パケット（FEC packet）はＦＥＣアルゴリズムによって新しく生成したパケットである。２つのパケットはそれぞれ別ストリームとして伝送し、後方互換性を提供する。
　ＦＥＣヘッダは図６の通りで、冗長パケットのＲＴＰ／ＦＥＣヘッダの一部は、ＲＦＣ２７３３で標準化された、次節で述べるprotection operationにより生成され、length recovery、PT（payload type）recovery、TS（time stamp）recoveryはこれによって冗長化されたデータが付加される。
　SNbaseはＦＥＣ処理によって保護されたメディアパケットの最小シーケンス番号を付加し、block size、data symbolはＲＳ符号によるＦＥＣパッケージの（Ｎ，Ｋ）コード（一般にdata symbol(K)個のデータパケットを冗長化し、block size(N)個のパケットを生成する方法）に対応している。」（９頁左欄３９行〜右欄１２行）
　
　ホ．「３．２　Ｐｒｏｔｅｃｔｉｏｎ　ｏｐｅｒａｔｉｏｎによるＦＥＣ処理
　ＦＥＣのエンコード／デコード処理には、protection operationを用いることでＲＴＰヘッダの特定のフィールドも冗長化を行う。protection operationによる冗長パケットの生成方法を図７に示す。ＦＥＣエンコード処理では、メディアパケットのＲＴＰヘッダから特定のフィールドを連結したビットストリング複数パケット分を１つのユニットとし、それに対し垂直方向にＦＥＣブロックに対しＦＥＣエンコーディングを行う。これによって生成されたビットストリングを冗長パケットのＲＴＰ／ＦＥＣヘッダの特定フィールド、ペイロードに埋めることでヘッダを含むパケットの冗長化が可能となる。
　デコード処理では、エンコード処理の逆の処理を辿る。冗長パケットのSNbaseとblock sizeフィールドから自身のユニット内のメディアパケットを取り出し、ＦＥＣデコード処理が必要ならば各パケットからビットストリングを生成しデコード処理を行って喪失パケットの回復を行う。」（９頁右欄１３行〜１０頁左欄１３行）
　
　上記イ．〜ホ．の記載及び関連する図面並びにこの分野における技術常識を考慮すると、
　上記イ．及び上記ロ．に記載されるように、引用例には、リアルタイム性が要求されるマルチメディアデータに対してＦＥＣ（Forward Error Correction：前方誤り訂正）処理を行い、冗長パケットを生成して送信する方法について記載がある。
　上記ロ．、ハ．及び図１、図２には、ＴＳパケットをカプセル化したＲＴＰ（Real Time Transport Protocol）フォーマットデータ（後述のメディアパケット）をＦＥＣ処理部が受け取り、冗長パケットを生成することが記載されている。そして、上記ハ．には、ＦＥＣとしてReed-Solomon符号を用いることが記載されている。
　上記ニ．には、メディアパケットにReed-Solomon符号による（Ｎ，Ｋ）コードを用いて、冗長パケット（ＦＥＣパケット）を生成することについて記載がある。ここで、Ｎは、冗長パケットを含む全てのパケットのサイズ（block size）である。図５には、メディアパケットがＲＴＰヘッダとペイロードを含むこと、及び、冗長パケット（ＦＥＣパケット）がＲＴＰ（Real Time Transport Protocol）ヘッダとＦＥＣヘッダとペイロードを含むことが記載されている。また、図６には、ＦＥＣヘッダフォーマットについて記載があり、block sizeフィールドやSNbase（ＦＥＣ処理によって保護されたメディアパケットの最小シーケンス番号）フィールドが設けられている。
　上記ホ．及び図７には、ＦＥＣエンコード処理による冗長パケットの生成方法について記載があり、メディアパケットからメディアパケット毎にビットストリングが図７に記載されるように生成されており、生成されたビットストリングを複数パケット分並べてＦＥＣ処理を行い、このＦＥＣ処理によって生成されたビットストリングを複数の冗長化されたデータとして複数の冗長パケット（ＦＥＣパケット）に格納することが記載されている。
　
　したがって、引用例には以下の発明（以下、「引用発明」という。）が記載されている。
　
（引用発明）
　「リアルタイム性の要求されるマルチメディアデータに対して前方誤り訂正処理を行う方法であって、
　メディアパケットから、ビットストリングを生成し、
　複数パケット分のビットストリングに（Ｎ，Ｋ）コードによる前方誤り訂正処理を行い、これによって複数のビットストリングを生成し、
　前記複数のビットストリングによって冗長化されたデータを生成し、
　前記冗長化されたデータを格納した前方誤り訂正パケットを送信するようにし、
　前記前方誤り訂正パケットは、ＲＴＰヘッダと前方誤り訂正ヘッダと、前記生成された冗長化されたデータとを含み、
　前記前方誤り訂正ヘッダは、前方誤り訂正パケット及びメディアパケットの総数を示すＮをｂｌｏｃｋ　ｓｉｚｅフィールドに含む方法。」
　
（３）対比・判断
　引用発明の「リアルタイム性の要求されるマルチメディアデータに対して前方誤り訂正処理を行う」に関しては、「リアルタイム性の要求されるマルチメディアデータ」が明らかに補正後の発明の「リアルタイムメディア」に相当すること、また、前記マルチメディアデータが「前方誤り訂正（ＦＥＣ）処理」により「保護」されることになるのは自明であることから、補正後の発明の「リアルタイムメディアを保護する」に相当する。
　
　引用発明の「メディアパケットから、ビットストリングを生成し、」に関しては、ＴＳパケットをカプセル化したメディアパケットはＦＥＣ処理部で受け取られており、「メディアパケット」を「受信」しているといえ、また、生成される「ビットストリング」はメディアパケットが格納するＴＳパケット、すなわちマルチメディアデータのビット列であるから、補正後の発明の「メディアパケットを受信し、前記メディアパケットからメディアビット列を生成し、」に相当する。
　
　引用発明の「複数パケット分のビットストリングに（Ｎ，Ｋ）コードによるによる前方誤り訂正処理を行い、これによって複数のビットストリングを生成し、」に関しては、「（Ｎ，Ｋ）コードによる前方誤り訂正処理」は明らかに補正後の発明の「前方誤り訂正符号を適用」することに相当し、また、前方誤り訂正処理により生成される「複数のビットストリング」は補正後の発明の「前方誤り訂正ビット列」に相当するから、補正後の発明の「前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成し、」に相当する。
　
　引用発明の「冗長化されたデータ」は、明らかに補正後の発明の「前方誤り訂正データ」に相当する。また、引用発明の「ＲＴＰヘッダ」のＲＴＰはReal Time Transport Protocolの略であるから、明らかに補正後の発明の「リアルタイムトランスポートヘッダ」に相当する。また、引用発明の「前方誤り訂正ヘッダ」も明らかに補正後の発明の「前方誤り訂正パケットヘッダ」に相当する。
　
　引用発明の「前方誤り訂正パケット及びメディアパケットの総数を示すＮ」は、明らかに補正後の発明の「前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数」に相当する。
　
　したがって、補正後の発明と引用発明は、以下の点で一致ないし相違している。
　
（一致点）
　「リアルタイムメディアを保護する方法であって、
　メディアパケットを受信し、
　前記メディアパケットからメディアビット列を生成し、
　前記生成されたメディアビット列を通じて前方誤り訂正符号を適用し、複数の前方誤り訂正ビット列を生成し、
　前記前方誤り訂正ビット列から前方誤り訂正データを生成し、
　前方誤り訂正パケットを送信することを有し、
　前記前方誤り訂正パケットは、リアルタイムトランスポートヘッダと、前方誤り訂正パケットヘッダと、前記生成された前方誤り訂正データとを含み、
　前記前方誤り訂正パケットヘッダは、前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数を含む方法。」
　
（相違点）
（１）補正後の発明は、前方誤り訂正データを生成するにあたり、「前記メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成」しており、「前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され」るものとなっているが、引用発明では、前方誤り訂正データを生成するにあたり、そのような構成をとっていない点。
（２）前方誤り訂正パケットヘッダに関し、補正後の発明では、「前記前方誤り訂正データのインデックスの所定数の下位ビットを前記前方誤り訂正パケットヘッダの第１のインデックスフィールドに含み、前記前方誤り訂正データの前記インデックスの所定数の上位ビットを前記前方誤り訂正パケットヘッダの第２のインデックスフィールドに含み、」そして、「前記インデックスは、前記前方誤り訂正ブロックの前記前方誤り訂正データの位置を示す」ものであるのに対し、引用発明では、そのようなインデックスに関するフィールドを有していない点。
　
　そこで、上記相違点について検討する。
　まず、上記相違点（１）について検討する。
　引用発明では、前方誤り訂正データを生成するにあたり、「メディアパケットからビットストリングを生成し、複数パケット分のビットストリングに（Ｎ，Ｋ）コードによる前方誤り訂正処理を行い、これによって複数のビットストリングを生成し」ており、複数のメディアパケットからのビットストリングを、引用例図７のように一方向、すなわち１次元に並べて前方誤り訂正処理を行っており、補正後の発明のようにメディアパケットを複数の列及び複数の行の２次元に並べて前方誤り訂正処理を行っていない。
　
　しかしながら、引用例１の摘記事項ハ．に記載されるように、リアルタイム性を要求されるマルチメディアデータのパケット伝送に関して、前方誤り訂正（ＦＥＣ）保護によるＲＴＰ（Real Time Transport Protocol）フォーマットがＲＦＣ２７３３として標準化されており、引用発明はこのＲＦＣ２７３３に準拠したものであるが、このようなＲＦＣ２７３３に準拠した前方誤り訂正処理において、メディアパケットを複数の列及び複数の行の２次元行列を形成するように並び替えて、Reed-Solomon符号のような前方誤り訂正符号による前方誤り訂正処理を、列方向、または列方向及び行方向に行い、複数の前方誤り訂正データを格納する前方誤り訂正パケットを生成することは周知の技術にすぎない。（必要があれば、原審の拒絶査定に周知例としてそれぞれ引用された、Ｐｒｏ−ＭＰＥＧ　Ｃｏｄｅ　ｏｆ　Ｐｒａｃｔｉｃｅ　＃３　ｒｅｌｅａｓｅ　２，２００４年７月，ｐｐ．１−１７、ＵＲＬ，http://www.pro-mpeg.org/documents/wancop3.pdf（以下、「周知例１」という。）の「4.5.1 Background」、「4.5.2 FEC packet arrangement」の項の記載（Ｆｉｇ．１には２次元に並べられたメディアパケットの列方向の前方誤り訂正処理が、Ｆｉｇ．２には２次元に並べられたメディアパケットの列方向及び行方向の前方誤り訂正処理が記載されている。）や、国際公開第２００５／０４１４６６号（以下、「周知例２」という。）の６頁１行〜３１行の記載（Ｆｉｇ．１には２次元に並べられたメディアパケットの列方向及び行方向の前方誤り訂正処理が記載されている。）を参照。）
　
　このような周知の技術を引用発明に適用し、メディアパケットから生成されるビットストリングを１次元に並べて前方誤り訂正処理を行うことに替えて、メディアパケットを並び替え、複数の列及び複数の行の２次元行列を形成した後に前方誤り訂正処理を行うようにすることは当業者が適宜為し得ることである。そして、そのように為せば引用発明においても、「前記前方誤り訂正データは、前記前方誤り訂正データの生成の基礎となる前記メディアパケットの前記２次元行列の１つの次元により分離され」ることになる。
　したがって、相違点（１）は格別なものでない。
　
　ついで、上記相違点（２）について検討する。
　引用例の図６には、前方誤り訂正パケットヘッダに関して記載があり、補正後の発明の「前方誤り訂正ブロックの前方誤り訂正パケット及びメディアパケットの総数を示す所定数」に相当するＮを格納する「block size」フィールドや、ＦＥＣ処理によって保護されたメディアパケットの最小シーケンス番号が格納されるSNbaseフィールドが設けられているが、補正後の発明の「インディックス」に相当するフィールドは設けられていない。
　
　しかしながら、引用発明と同様にＲＦＣ２７３３に準拠するリアルタイムトランスポート（ＲＴＰ）フォーマットにおける前方誤り訂正（ＦＥＣ）ヘッダに、受信側での前方誤り訂正デコーディング処理に必要な情報を所定のフィールドを設けて格納することについては種々検討されており、前方誤り訂正ブロックにおける複数の前方誤り訂正パケットの中で自身の前方誤り訂正パケットがどの位置に存在するパケットであるのかを示す情報、すなわち、補正後の発明の「前方誤り訂正ブロックの前記前方誤り訂正データの位置を示」す「インディックス」に相当する情報を前方誤り訂正（ＦＥＣ）ヘッダに所定のフィールドを設けて格納することは周知の構成である。（必要があれば、原審の拒絶査定に周知例として引用された特開２００６−３２５１１３号公報（以下、「周知例３」という。）の図６及び段落【００９３】に記載された「ＦＥＣ　Ｓｅｑｕｅｎｃｅ」フィールドを参照。）
　ここで、一般にヘッダのフィールドに所望のビット列を格納しようとするとき、当該ビット列の桁数とフィールドに格納できるビット数に応じて、複数のフィールドにビット列を分割して格納し、連結させて読み出せるようにすることは常套手段にすぎない。（例えば、上記周知例１の「４．５．５　ＦＥＣ　ｈｅａｄｅｒ　ｆｏｒｍａｔ」の項には、ＳＮＢａｓｅに関して、「ＳＮＢａｓｅ　ｌｏｗ　ｂｉｔｓ」フィールドと１６ｂｉｔよりも長いシーケンス番号が必要とされるプロトコルのための「ＳＮＢａｓｅ　ｅｘｔ　ｂｉｔｓ」フィールドが設けられている。）
　したがって、引用発明の前方誤り訂正パケットヘッダに、補正後の発明の「インディックス」に相当する周知例３の「ＦＥＣ　Ｓｅｑｕｅｎｃｅ」を格納するフィールドを設けることは適宜為し得ることであり、その際、当該「フィールド」を所定数の下位ビットを格納する「第１のフィールド」と所定数の上位ビットを格納する「第２フィールド」から構成することは当業者が必要に応じて適宜行い得る設計的事項にすぎない。
　このように、相違点（２）も格別なものでない。
　
　そして、補正後の発明に関する作用・効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　以上のとおりであるから、補正後の発明は引用発明及び周知技術に基いて容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成１８年法律第５５号附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　本件補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。　
　
２．引用発明及び周知技術
　引用発明及び周知技術は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の「（２）引用発明」及び「（３）対比・判断」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は補正後の発明から、本件補正に係る構成を省いたものである。
　そうすると、本願発明の構成に本件補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明及び周知技術に基いて容易に発明をすることができたものであるから、補正後の発明から本件補正に係る限定を省いた本願発明も、同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。