【事件の表示】
　特願２０１３−　　３３４７「インターネットプロトコルネットワークでのリアルタイムのオーディオ及びビデオデータの前方誤り訂正をサポートする方法」拒絶査定不服審判事件〔平成２５年　５月　９日出願公開、特開２０１３−　８５２９３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件出願は，２００６年１２月２１日を国際出願日とする特願２００９−５４２７４１号の一部を平成２５年１月１１日に新たな特許出願としたものであって，平成２６年１月８日付け拒絶理由通知に対して同年４月１８日に意見書及び手続補正書が提出されたが同年１０月２３日付けで拒絶査定がなされ，これを不服として平成２７年２月２７日付けで審判請求がなされるとともに手続補正書が提出されたものである。
　
第２　補正却下の決定
［補正却下の決定の結論］
　平成２７年２月２７日に提出された手続補正書による手続補正（以下，「本件補正」という。）を却下する。
　
［理由］
１　本願発明と補正後の発明
　本件補正は，平成２６年４月１８日に提出された手続補正書の特許請求の範囲の請求項１に記載された
　
「リアルタイムメディアパケットを保護する方法であって，
　リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し，
　前記メディアパケットを並び替え，複数の列及び複数の行の２次元行列を形成し，
　前記メディアパケットからメディアビット列を生成し，
　前記生成されたメディアビット列のそれぞれの終端で，前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし，
　それぞれパディングされたビット列が最も長いビット列の長さを有するように，以前にパディングされたビット列の終端で更にパディングし，
　前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し，
複数の前方誤り訂正ビット列を生成し，
　前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し，
　前記生成された前方誤り訂正パケットを送信し，ただし，前記前方誤り訂正パケットは，インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記２次元行列の列のインデックスを表す次元により分離され，
　前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し，
　前記前方誤り訂正パケットは，前記メディアパケットのフォーマットを変更せずに生成され，前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され，非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする方法。」
　
　という発明（以下，「本願発明」という。）を，補正後の特許請求の範囲の請求項１に記載された
　
「リアルタイムメディアパケットを保護する方法であって，
　リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し，
　前記メディアパケットを並び替え，複数の列及び複数の行の２次元行列を形成し，
　前記メディアパケットからメディアビット列を生成し，
　前記生成されたメディアビット列のそれぞれの終端で，前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし，
　それぞれパディングされたビット列が最も長いビット列の長さを有するように，以前にパディングされたビット列の終端で更にパディングし，
　前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し，
複数の前方誤り訂正ビット列を生成し，
　前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し，ただし，前方誤り訂正パリティパケットインデックスの最上位の数ビットが第３のインデックスフィールドに挿入され，
　前記生成された前方誤り訂正パケットを送信し，ただし，前記前方誤り訂正パケットは，インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記２次元行列の列のインデックスを表す次元により分離され，
　前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し，
　前記前方誤り訂正パケットは，前記メディアパケットのフォーマットを変更せずに生成され，前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され，非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする方法。」
　
　という発明（以下，「補正後の発明」という。）に変更することを含むものである。
　
２　新規事項の有無，補正の目的要件について
　本件補正は，願書に最初に添付した明細書，特許請求の範囲若しくは図面に記載した事項の範囲内において，補正前の特許請求の範囲の請求項１に記載された「前方誤り訂正パケット」について「前方誤り訂正パリティパケットインデックスの最上位の数ビットが第３のインデックスフィールドに挿入され」る点を付加して限定することにより特許請求の範囲を限定的に減縮するものであって，特許法第１７条の２第３項（新規事項）及び特許法第１７条の２第４項第２号（補正の目的）の規定に適合している。
　
３　独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものであるから，上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 
　
（１）補正後の発明
　上記「１　本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
（２）引用発明
　原査定の拒絶の理由に引用されたPro-MPEG Code of Practice #3 release 2，２００４年　７月，p.1,5-11,14，ＵＲＬ，http://www.pro-mpeg.org/documents/wancop3.pdf(以下，「引用例」という。)には，以下の事項が記載されている。
　
ア　「4.5 FEC Scheme
　
4.5.1 Background
　
・・・（中略）・・・
The biggest issue with FEC systems on IP networks is that, because of the UDP checksums, channel bit errors get translated into packet losses. In addition to this, buffer and re-route issues cause burst packet losses. The combination of packet losses from the three sources - gross reordering, bit-error induced losses and burst losses needs to be low enough so that the FEC scheme is not broken more than the negotiated error rate. Because any bit errors cause the packet to be discarded there is no requirement for an error correction scheme that can handle errored packets - every packet will either arrive correct or not at all.
　
An RTP payload format for Generic Forward Error Correction Packets has been defined in the RFC 2733 to enable error correction of real time media. This standard allows the use of traditional error correcting codes. A major advantage of this scheme is that it can be used with any video formats standards (MPEG, SDI, SDTI, ...) as long as it is encapsulated in a RTP packet. However, this standard limits the scope of packets used to generate the Forward Error Correction payload, to 24 consecutive packets.
（当審仮訳：
　4.5　ＦＥＣスキーム
　
4.5.1　背景
　
・・・（中略）・・・
ＩＰネットワーク上でのＦＥＣシステムに関する最大の問題は，ＵＤＰチェックサムのため，チャネルビットエラーがパケット損失に変換されることである。これに加え，バッファと経路切替問題によりバースト的なパケット損失を引き起こす。３つの原因−大雑把な再順序付け，ビットエラーに基づく損失，バースト損失，によるパケット損失を組合せたものは，取り決められたエラーレートを超えてＦＥＣスキームが破壊されることがないよう十分に低くなる必要がある。どのようなビットエラーによってもパケットが廃棄されるので，エラーを含むパケットを処理できるような誤り訂正スキームは必要ない−全てのパケットは正しいまま到着するか，全く到着しないかのどちらかである。
　
リアルタイムメディアの誤り訂正を可能にするために，既存の前方誤り訂正パケットのためのＲＴＰペイロードフォーマットがＲＦＣ２７３３で定義されている。この標準は，旧来からの誤り訂正符号の利用を許容する。この標準の主な利点は，それがＲＴＰパケットにカプセリング可能なものである限り，どのようなビデオフォーマット標準（ＭＰＥＧ，ＳＤＩ，ＳＤＴＩ，．．．）に対しても使えることである。しかしながら，この標準は，前方誤り訂正ペイロードを生成するために用いられるパケットの範囲を２４個の連続したパケットに限定する。）」（５頁）
　
イ「4.5.2 FEC packet arrangement
　
To recover burst loss, an extension to the existing RFC is proposed. The same traditional error correcting codes are applied to non-consecutive media packets that can be spaced of more than 24 packets. Each FEC packet is associated to packets periodically selected. Therefore, consecutive RTP packets can be recovered from consecutive FEC packets. The process is detailed in Figure 1.
　
（図１：省略）
Fig.1 Encoding scheme…
　
In Figure 1, the encoding scheme is schematized for L*D media packets. The period chosen is L. Thus the payload of the kth FEC packet is computed based on the D packets numbered nL+k (0≦n≦D - 1).
　
・・・（中略）・・・
　
The main advantage of this scheme is the burst error correction capacity. The error correcting function chosen is XOR which has the ability to recover any one lost packet . If a one dimensional scheme based on XOR is used (i.e. applied to D consecutive packets), a burst error of two or more lost packets is not recoverable. However, if the two dimensional scheme is used, the recoverability is greatly improved, since it can recover up to L consecutive packets.
　
Though this scheme is very robust to bursts of packet losses (it corrects L consecutive packets lost), if only 2 packets are lost and these packets are in the same column, there is no way to correct these losses. It is therefore recommended that two simultaneous FEC streams should be supported, which will allow for a far higher correction capability, at the expense of increased overhead. These FEC streams shall be carried on separate UDP ports, to allow them to have separate sequence number handling, and to maintain backward compatibility with previous implementations that only supported a single (column) FEC stream.
　
The first port shall carry the column FEC stream and the second port shall carry the row FEC stream.
（当審仮訳：
4.5.2　ＦＥＣパケット配列
　
バースト損失を回復するため，既存のＲＦＣに対する拡張を提案する。同じ旧来の誤り訂正符号が２４パケット以上に亘って配置される非連続的なメディアパケットに適用される。各ＦＥＣパケットは周期的に選択されるパケットに関連している。そのため，連続したＦＥＣパケットから連続したＲＴＰパケットが回復できる。この過程は図１に詳説される。
　
　（図１：省略）
　図１．符号化スキーム．．．
　
図１において，符号化スキームがＬ＊Ｄのメディアパケットについて図式化されている。選ばれた周期はＬである。このように，ｋ番目のＦＥＣパケットのペイロードはnL+k (0≦n≦D - 1)と番号付けられたＤ個のパケットに基づいて計算される。
　
・・・（中略）・・・
　
このスキームの主な利点は，バースト的な誤り訂正能力である。選択された誤り訂正機能はＸＯＲでどのような１パケットでも回復できる能力がある。もしも，ＸＯＲに基づく１次元方式が適用された場合（すなわち，Ｄ個の連続したパケットに適用された場合），２個またはそれ以上の損失パケットが生じるバーストエラーは回復できない。しかしながら，２次元方式が使われれば，Ｌ個の連続パケットまで回復可能であるため，回復力は大きく改善する。
　
このスキームはバースト的なパケット損失に対して非常にロバストであるが（Ｌ個の連続したパケット損失を訂正する），もしもたった２個のパケットが損失し，しかもこれらのパケットが同じ列であるならば，これらの損失を回復する術はない。それ故，２つの同時的なＦＥＣストリームがサポートされるべきであり，それにより，増大するオーバーヘッドの代償としてはるかに高い訂正能力を持たせることができる。これらのＦＥＣストリームは別々のＵＤＰポートで運ばれるべきであり，それにより，別々のシーケンス番号処理を可能とし，また，１つの（列の）ＦＥＣストリームのみをサポートする前述の例との後方互換性を維持できる。
　
第１のポートは列ＦＥＣストリームを運び，第２のポートは行ＦＥＣストリームを運ぶ。」（５−７頁）
　
ウ「4.5.5 FEC header format
　
The FEC header described in the RFC 2733 is originally 12 bytes. To allow for the extension to the error correction scheme, the FEC header needs to be modified as detailed in Figure 3.
（図３　省略）
Fig.3 Definition of the FEC header
　
The following fields are as defined in RFC2733:
・SNBase low bits: minimum sequence number of the packets associated to the FEC packet. For MPEG2 transport streams 16 bit sequence numbers are sufficient, so this parameter shall contain the entire sequence number. For protocols with longer sequence numbers this field will contain the least significant 16 bits of the sequence number.
・・・（中略）・・・
The additional fields have been modified from what was in RFC2733, or are new. The definition of these is:
・・・（中略）・・・
Type: This field indicates which error-correcting code is chosen. It can be XOR (type=0), Hamming (type=1), Reed-Solomon (type=2). 
・・・（中略）・・・
SNBase ext bits: This field is reserved for use with protocols which require extended sequence numbers longer than 16 bits. For MPEG2 transport streams 16 bit sequence numbers are sufficient, so this parameter shall be set to zero. For protocols with longer sequence numbers this field will contain the next eight bits of the sequence number, beyond that which is in SNBase low bits.
（当審仮訳：
4.5.5　ＦＥＣヘッダフォーマット
　
ＲＦＣ２７３３に記述されたＦＥＣヘッダはもともと１２バイトである。誤り訂正スキームの拡張を許容するために，ＦＥＣヘッダは図３に詳述されるように変更される必要がある。
　（図３：省略）
　図３．ＦＥＣヘッダの定義
　
以下のフィールドがＲＦＣ２７３３で定義されている：
・SNBase low bits：ＦＥＣパケットに関連するパケットの最小のシーケンス番号。ＭＰＥＧ２トランスポートストリームに対しては１６ビットのシーケンス番号で十分であり，このパラメータは全シーケンス番号を格納できる。より長いシーケンス番号を用いるプロトコルに対しては，このフィールドはシーケンス番号の下位の１６ビットを格納する。
・・・（中略）・・・
付加的なフィールドがＲＦＣ２７３３のものに対して修正され，もしくは，新たに設けられた。それらの定義は：
・・・（中略）・・・
・Type：このフィールドはどの誤り訂正符号が選ばれているかを示す。それは，ＸＯＲ(type=0），ハミング(type=1)，リード−ソロモン(type=2)であり得る。
・・・（中略）・・・
・SNBase ext bits：このフィールドは１６ビットより長い拡張したシーケンス番号を必要とするプロトコルで使用されるために予約されている。ＭＰＥＧ２トランスポートストリームに対しては１６ビットのシーケンス番号で十分であり，そのためこのパラメータは０にセットされる。より長いシーケンス番号のプロトコルに対してはこのフィールドはシーケンス番号のうちSNBase low bitsにあるビットを超える部分の８ビットを格納する。」（９−１１頁）
　
　上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると，
　上記引用例には，リアルタイムメディアの誤り訂正を可能にするためにＲＦＣ２７３３で定義された既存の前方誤り訂正パケット用のＲＴＰペイロードフォーマットを拡張することに関する技術が記載されており，具体的には，
ａ　ＲＴＰパケットを並び替え，Ｌ列Ｄ行の２次元行列を形成し，前記２次元行列の各ＲＴＰパケット列から１つのＦＥＣパケットのペイロードを計算すること（図１および摘記事項イ），
ｂ　ＦＥＣパケットのペイロードに図３に記載された拡張されたＦＥＣヘッダを付加してＦＥＣパケットを生成すること，
ｃ　ＦＥＣパケットは，ＦＥＣパケットに関連するＲＴＰパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別されること（摘記事項ウ）
　が記載されている。
　ここで，上記ＲＴＰパケットは上位レイヤから受信すること，及び，上記ＦＥＣパケットやＲＴＰパケットがＩＰネットワーク上で送信されることは当業者にとり明らかであり，また，ＦＥＣパケットによって関連するＲＴＰパケットの誤り訂正がなされることから，引用例にはＲＴＰパケットを保護する方法が記載されているといえる。
　
　以上を総合すると，上記引用例には，以下の発明（以下，「引用発明」という。）が開示されていると認める。
　
「ＲＴＰパケットを保護する方法であって，
　リアルタイムメディアデータを表すＲＴＰパケットを受信し，
　前記ＲＴＰパケットを並び替え，Ｌ列Ｄ行の２次元行列を形成し，
　前記２次元行列の各ＲＴＰパケット列から１つのＦＥＣパケットのペイロードを計算し，
　前記ＦＥＣパケットのペイロードにＦＥＣヘッダを付加してＦＥＣパケットを生成し，
　前記生成されたＦＥＣパケットをＩＰネットワークで送信し，ただし，前記ＦＥＣパケットは，前記ＦＥＣパケットに関連する前記ＲＴＰパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別され，
　ＩＰネットワークで前記ＲＴＰパケットを送信することを有し，
　前記ＦＥＣパケットは，前記ＲＴＰパケットのフォーマットを変更せずに生成され，ＩＰネットワークで送信される，方法。」
　
（３）対比
　補正後の発明と引用発明とを対比するに，
ａ　引用発明の「ＲＴＰパケット」は補正後の発明の「リアルタイムメディアパケット」及び「メディアパケット」に相当する。
ｂ　引用発明の「ＦＥＣ」はforward error correction（前方誤り訂正）の略であり，補正後の発明の「前方誤り訂正」と同義である。
ｃ　引用発明の「前記２次元行列の各ＲＴＰパケット列から１つのＦＥＣパケットのペイロードを計算し」と，
　補正後の発明の「前記メディアパケットからメディアビット列を生成し，前記生成されたメディアビット列のそれぞれの終端で，前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし，それぞれパディングされたビット列が最も長いビット列の長さを有するように，以前にパディングされたビット列の終端で更にパディングし，前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し，複数の前方誤り訂正ビット列を生成し」とは，
　「前記メディアパケットから前方誤り訂正ビット列を生成し」で共通する。
ｄ　引用発明の「前記ＦＥＣパケットのペイロードにＦＥＣヘッダを付加してＦＥＣパケットを生成し」と，
　補正後の発明の「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し，ただし，前方誤り訂正パリティパケットインデックスの最上位の数ビットが第３のインデックスフィールドに挿入され」とは，
　「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し」で共通する。
ｅ　引用発明の「前記ＦＥＣパケットに関連する前記ＲＴＰパケット列の最小のシーケンス番号」に関し，「前記ＦＥＣパケットに関連する前記ＲＴＰパケット列」は，図１に記載されたＲＴＰパケットの２次元行列の１つの列に含まれるＲＴＰパケット列であるが，引用発明の「前記２次元行列の各ＲＴＰパケット列から１つのＦＥＣパケットのペイロードを計算し」の構成によれば，このＲＴＰパケット列は対応するＦＥＣパケットの生成の基礎となっているといえる。
　さらに，このＲＴＰパケット列の「最小のシーケンス番号」は第１行のＲＴＰパケットのシーケンス番号（０乃至Ｌ−１のいずれか）であって，２次元行列の「列のインデックス」を表し，また，この「列のインデックス」によってＦＥＣパケット間を区別可能となっていることも明らかである。
　以上を踏まえると，
　引用発明の「前記ＦＥＣパケットは，前記ＦＥＣパケットに関連する前記ＲＴＰパケット列の最小のシーケンス番号を表すSNBase low bitsフィールドの値により区別され」は，
　補正後の発明の「前記前方誤り訂正パケットは，インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記２次元行列の列のインデックスを表す次元により分離され」に相当する。
ｆ　引用発明の「前記ＦＥＣパケットは，前記ＲＴＰパケットのフォーマットを変更せずに生成され，ＩＰネットワークで送信される」と，
　補正後の発明の「前記前方誤り訂正パケットは，前記メディアパケットのフォーマットを変更せずに生成され，前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され，非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」とは，
　「前記前方誤り訂正パケットは，前記メディアパケットのフォーマットを変更せずに生成され，送信される」で共通する。
　
　従って，両者は以下の点で一致ないし相違している。
　
（一致点）
「リアルタイムメディアパケットを保護する方法であって，
　リアルタイムのオーディオ及びビデオデータを表すメディアパケットを受信し，
　前記メディアパケットを並び替え，複数の列及び複数の行の２次元行列を形成し，
　前記メディアパケットから前方誤り訂正ビット列を生成し，
　前記前方誤り訂正ビット列から前方誤り訂正パケットを生成し，
　前記生成された前方誤り訂正パケットを送信し，ただし，前記前方誤り訂正パケットは，インターネットプロトコルネットワークで前記前方誤り訂正パケットの生成の基礎となる前記メディアパケットの前記２次元行列の列のインデックスを表す次元により分離され，
　前記インターネットプロトコルネットワークで前記メディアパケットを送信することを有し，
　前記前方誤り訂正パケットは，前記メディアパケットのフォーマットを変更せずに生成され，送信される，方法。」　
　
（相違点１）
　「前記メディアパケットから前方誤り訂正ビット列を生成」する点に関し，
　補正後の発明では，「前記メディアパケットからメディアビット列を生成し，前記生成されたメディアビット列のそれぞれの終端で，前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし，それぞれパディングされたビット列が最も長いビット列の長さを有するように，以前にパディングされたビット列の終端で更にパディングし，前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し，複数の前方誤り訂正ビット列を生成」するのに対し，
　引用発明では，「前記２次元行列の各ＲＴＰパケット列から１つのＦＥＣパケットのペイロードを計算」する点。
　
（相違点２）
　「前記前方誤り訂正ビット列から前方誤り訂正パケットを生成」する点に関し，
　補正後の発明では，「前方誤り訂正パリティパケットインデックスの最上位の数ビットが第３のインデックスフィールドに挿入され」るのに対し，
　引用発明ではそのような構成を有しない点。
　
（相違点３）
　「前方誤り訂正パケット」の「送信」に関し，
　補正後の発明では，「前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され，非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」のに対し，
　引用発明では，単に「ＩＰネットワークで送信される」ものである点。
　
（４）判断
　上記相違点につき検討する。
　
（相違点１）について
　引用例には，前方誤り訂正符号としてリード−ソロモン符号（ＲＳ符号）を用いることが示唆されているが（摘記事項ウ），当該ＲＳ符号化がシンボル単位の符号化であって，「符号化処理のために情報ビットをシンボルの倍数に対応するビット長にパディングにより揃えること」及び，ＲＳ符号を複数の可変長パケットを通じて適用する場合に「各パケットのパケット長をパディングにより揃えること」は，いずれもＲＳ符号化処理における周知技術である（例えば，前置報告で引用された特開２００２−２０４２１９号公報（以下，「周知例１」という。）の段落【００３８】や，原査定の拒絶の理由に引用された特開２００６−３２５１１３号公報（以下，「周知例２」という。）の段落【００４６】−【００４７】を参照。）。
　さらに，一般に，誤り訂正符号としてＲＳ符号を用いる場合，複数の冗長ビット列（冗長パケット）が生成されることは技術常識である。
　そうすると，引用発明において，２次元行列の各ＲＴＰパケット列からそれぞれＦＥＣパケットのペイロードを計算する場合に，ＦＥＣとして引用例に示唆されたＲＳ符号を採用するとともにＲＳ符号化処理に関する上記周知例２，３に例示された周知技術を採用して，補正後の発明のように，「前記メディアパケットからメディアビット列を生成し，前記生成されたメディアビット列のそれぞれの終端で，前記生成されたメディアビット列のそれぞれを最も近い倍数のシンボルにパディングし，それぞれパディングされたビット列が最も長いビット列の長さを有するように，以前にパディングされたビット列の終端で更にパディングし，前記生成及びパディングされたメディアビット列を通じて前方誤り訂正符号を適用し，複数の前方誤り訂正ビット列を生成」することは，当業者であれば容易になし得たものである。
　
（相違点２）について
　引用発明と同様にＲＦＣ２７３３に準拠するリアルタイムトランスポート（ＲＴＰ）フォーマットにおける前方誤り訂正（ＦＥＣ）ヘッダに，受信側での前方誤り訂正デコーディング処理に必要な情報を所定のフィールドを設けて格納することについては種々検討されており，ＦＥＣとして前方誤り訂正ブロックにおける複数の前方誤り訂正パケットの中で自身の前方誤り訂正パケットがどの位置に存在するパケットであるのかを示す情報，すなわち，補正後の発明の「前方誤り訂正パリティパケットインデックス」を前方誤り訂正（ＦＥＣ）ヘッダに所定のフィールドを設けて格納することは，例えば，上記周知例２の図６及び段落【００９３】に記載された「ＦＥＣ　Ｓｅｑｕｅｎｃｅ」フィールドのように周知の構成である。
　ここで，一般にヘッダのフィールドに所望のビット列を格納しようとするとき，当該ビット列の桁数とフィールドに格納できるビット数に応じて，複数のフィールドにビット列を分割して格納し，連結させて読み出せるようにすることは，引用例に，ＲＴＰパケットのシーケンス番号を下位ビットと上位ビットに分割してそれぞれ「SNBase low bits」と「SNBase ext bits」に格納することが記載されているように（摘記事項ウ），常套手段にすぎない。
　そうすると，引用発明のＦＥＣヘッダに，上記周知例２記載の「ＦＥＣ　Ｓｅｑｕｅｎｃｅ」フィールドを設けて「インデックスフィールド」を構成することは当業者が容易に想到し得たものである。その際，当該「インデックスフィールド」を所定数の下位ビットを格納するフィールドと所定数の上位ビットを格納するフィールドとから構成することは当業者が必要に応じて適宜行い得る設計的事項であり，また，このとき，所定数の上位ビットを格納するフィールドを補正後の発明のように「第３のインデックスフィールド」と称することも適宜なし得ることである。
　
（相違点３）について
　後方互換性を目的として，データパケットと冗長パケットを別ストリームとして伝送することは，原査定の拒絶の理由に引用された相原  玲二　他，ＨＤＴＶ  ＭＰＥＧ２  ｏｖｅｒ  ＩＰｖ６システムの開発，情報処理学会研究報告，日本，社団法人情報処理学会，２００２年１０月，Ｖｏｌ．２００２  Ｎｏ．９３，p.7-12（以下，「周知例３」という。）に「提案するパケットフォーマットを図５に示す。メディアパケット(media packet)は送信元から伝送されるユーザデータで，冗長パケット(FEC packet)はＦＥＣアルゴリズムによって新しく生成したパケットである。２つのパケットはそれぞれ別ストリームとして伝送し，後方互換性を提供する。」（９頁左欄）とあるように，ＲＦＣ２７３３でも規定されている周知技術に過ぎず，このとき，各ストリームを異なるポートで伝送することは，例えば，引用例において２つのＦＥＣストリーム（列ＦＥＣストリームと行ＦＥＣストリーム）を別々のＵＤＰポートで運ぶことで１つの（列の）ＦＥＣストリームのみをサポートする場合との後方互換性を持たせているように（摘記事項イ），当業者が当然成すべきことに過ぎない。
　したがって，引用発明において「前方誤り訂正パケット」が「ＩＰネットワークで送信される」際に，補正後の発明のように「前記メディアパケットを送信するために使用されるポートと異なるポートを使用して前記メディアパケットと別々に送信され，非前方誤り訂正システムが前記メディアパケットを受信して回復することを可能にする」構成とすることは，上記周知例３に例示される周知技術に基づいて当業者が容易に想到し得たものである。
　
　そして，補正後の発明が奏する効果も引用発明及び周知技術から容易に予測できる範囲内のものである。
　
（５）まとめ
　以上のとおり，補正後の発明は，引用発明に基づいて周知技術を参酌することにより当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。
　したがって，本件補正は，特許法第１７条の２第５項において準用する特許法第１２６条第５項の規定に違反するので，特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
１　本願発明
　本件補正は上記のとおり却下されたので，本願発明は，上記「第２ 補正却下の決定 １　本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２　引用発明と周知技術
　引用発明及び周知技術は，上記「第２ 補正却下の決定」の項中の「３　独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３　対比・判断
　本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。
　そうすると，本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が，上記「第２　補正却下の決定」の項中の「３　独立特許要件について」の項で検討したとおり，引用発明に基づいて周知技術を参酌することにより容易に発明できたものであるから，本願発明も同様の理由により，容易に発明できたものである。
　
４　むすび
　以上のとおり，本願発明は，引用発明に基づいて周知技術を参酌することにより当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，他の請求項に係る発明について審理するまでもなく，本願は拒絶すべきものである。
　よって，結論のとおり審決する。