【事件の表示】
　特願２０１５−５０８８５９「通信システムでパケットを送受信するための装置及び方法」拒絶査定不服審判事件〔平成２５年１０月３１日国際公開、ＷＯ２０１３／１６２２５０、平成２７年　６月２５日国内公表、特表２０１５−５１８３４６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成２５年４月２３日（パリ条約に基づく優先権主張外国庁受理 平成２４年４月２３日　韓国、平成２４年４月３０日　韓国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
　平成２６年１０月３０日　　：手続補正書の提出
　平成２９年　３月　３日付け：拒絶理由通知書
　平成２９年　６月２３日　　：意見書、手続補正書の提出
　平成２９年１１月２７日付け：拒絶査定
　平成３０年　４月　４日　　：拒絶査定不服審判の請求、手続補正書の提出
　平成３１年　２月２０日付け：拒絶理由通知書
　令和　元年　５月２７日　　：意見書、手続補正書の提出
　令和　元年　６月１８日付け：最後の拒絶理由通知書
　令和　元年　９月２４日　　：意見書、手続補正書の提出
第２　令和元年９月２４日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　令和元年９月２４日にされた手続補正（以下、「本件補正」という。）を却下する。
［理由］
１　本件補正について
（１）本件補正後の特許請求の範囲
　本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された（下線部は、補正箇所である。）。
「【請求項１】
　メディアデータを送信するための方法において、
　伝送する少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を順方向エラー訂正（ＦＥＣ）符号化し、リペアシンボルを生成する段階と；
　前記少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を利用してＦＥＣパケットを生成する段階と；
　前記リペアシンボルを利用してリペアパケットを生成する段階と；
　前記リペアパケットを含む前記ＦＥＣパケットを送信する段階と；を含み、
　ここで、ＦＥＣパケットヘッダーは、順次に増加するシーケンス番号を含み、
　前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子と前記リペアパケットのための連続的なシーケンス番号を含み、
　対応するＦＥＣブロックの初期シーケンス番号は、ＦＥＣブロック境界情報として各パケットのヘッダーに含まれ、
　前記ＦＥＣパケットは
前記ＦＥＣブロック境界情報
み、前記リペアパケットのヘッダーの分離されたシーケンス番号は、前記ＦＥＣブロックのパケットに順に割り当てられる
　ことを特徴とするパケット伝送方法。」
２　補正の適否
　本件補正により、本願の請求項１に係る発明に「前記リペアパケットのヘッダーの分離されたシーケンス番号は、前記ＦＥＣブロックのパケットに順に割り当てられる」との発明特定事項（以下、「特定事項１」という。）が加えられた。本件補正は、以下に示すように、本願の出願当初の明細書、特許請求の範囲及び図面（以下、「当初明細書等」という。）に記載した事項の範囲内でなされたものではない。
（１） 当初明細書等において、シーケンス番号の割り当てに関する記載は、「シーケンス番号は、ＦＥＣソースパケットに順に割り当てられ、分離されたシーケンス番号は、ＦＥＣ復旧パケットに順に割り当てられる。」（【００５３】）との記載のみである。当該記載に鑑みれば、シーケンス番号には、(a)ＦＥＣソースパケットに順に割り当てられる「シーケンス番号」と、(b)ＦＥＣ復旧パケットに順に割り当てられる「分離されたシーケンス番号」とがある。
　また、当初明細書等の「以下で説明は、本発明の実施例によるＦＥＣパケット生成手続に関する。パケットヘッダーのペイロード形式は、対応するペイロードにマッチングするために構成される。すなわち、ソースペイロードのためのパケットのペイロード形式は、オーディオ、ビデオなどのような、ソースペイロード形式を示す。そして、復旧ペイロードのためのパケットのペイロード形式は、復旧ペイロードを示す。」（【００５３】）との記載及び【００５５】の【表１】によれば、ＦＥＣソースパケット及びＦＥＣ復旧パケットは全体でＦＥＣパケットと総称され、それらのヘッダー構造は共通であり、前記(a)及び(b)は共にヘッダーの「シーケンス番号」のフィールドに格納され、両者はヘッダーの「ペイロード形式」の内容により区別されると認められる。
【表１】
（２） しかしながら、特定事項１の「分離されたシーケンス番号」は、リペアパケットすなわちＦＥＣ復旧パケットのためのものであるにも関わらず「ＦＥＣブロックのパケット」すなわちＦＥＣソースパケット及びＦＥＣ復旧パケットの双方に順に割り当てられたものである点で、前記(a)とも前記(b)とも異なるものである。
３　本件補正についてのむすび
　前記２（２）のとおりであるから、本件補正により特定事項１を加えた本件補正発明は、当初明細書等に記載した事項の範囲内のものとはいえない。したがって、本件補正は、特許法１７条の２第３項の規定に違反するので、同法１５９条１項の規定において読み替えて準用する同法５３条１項の規定により却下すべきものである。
　よって、上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　本件補正は前記第２のとおり却下されたので、本願の請求項１〜１０に係る発明は、本件補正前の令和元年５月２７日にされた手続補正により補正された特許請求の範囲の請求項１〜１０に記載された事項により特定されるものと認められるところ、その請求項１に係る発明（以下「本願発明」という。）は、以下のとおりのものである。
「【請求項１】
　メディアデータを送信するための方法において、
　伝送する少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を順方向エラー訂正（ＦＥＣ）符号化し、リペアシンボルを生成する段階と；
　前記少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を利用してＦＥＣパケットを生成する段階と；
　前記リペアシンボルを利用してリペアパケットを生成する段階と；
　前記リペアパケットを含む前記ＦＥＣパケットを送信する段階と；を含み、
　ここで、ＦＥＣパケットヘッダーは、順次に増加するシーケンス番号を含み、
　前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子と前記リペアパケットのための連続的なシーケンス番号を含み、
　対応するＦＥＣブロックの初期シーケンス番号は、ＦＥＣブロック境界情報として各パケットのヘッダーに含まれ、
　前記ＦＥＣパケットはＦＥＣの境界に関する情報を含む
　ことを特徴とするパケット伝送方法。」
２　当審の拒絶理由通知書の概要
　当審の拒絶の理由である、令和元年６月１８日付け拒絶理由通知の理由は、概略、次のとおりのものである。
理由１．この出願は、明細書、特許請求の範囲及び図面の記載が不備のため、特許法第３６条第６項第１号に規定する要件を満たしていない。
理由２．この出願は、特許請求の範囲の記載が特許法第３６条第６項第２号に規定する要件を満たしていない。 
理由３．この出願の請求項１に係る発明は、以下の引用文献１に記載された発明並びに引用文献２及び３に示される周知技術に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献１．岸田 崇志 他，“ＩＰストリーム伝送のための誤り訂正機能をもつアプリケーションゲートウェイの開発”，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２００４年，Vol.104，No.36，pp.23-28，TM2004-15
引用文献２．特開２００７−２８２４１号公報
引用文献３．米国特許出願公開第２０１２／００７９３３９号明細書
３　引用文献の記載事項
（１） 引用文献１について
ア　引用文献１には、図面とともに、次の記載がある。なお、下線は強調のために当審が付した。
（ア） ２４頁左欄２４行〜右欄３行
「本システムの特徴を以下に挙げる。
（中略）
4) バースト損失に強い
　インターネットで起きるパケット損失はバースト的なものが多いため、パケット損失への対応としてバースト損失に強い
Reed-Solomon符号を用いたFEC(Forward Error Correction)を採用した。
１ブロックはN個のシンボルによって構成され、そのうちK個がデータシンボルであり、N-K個が冗長シンボルである場合、(N,K)の冗長度と呼ぶ。
（イ） ２４頁右欄１９〜２２行
「○２ 
Gateway1はHost Aから受信したメディアパケットにヘッダを付けて拡張パケットを生成する。また、FECエンコードにより、冗長パケットを生成し拡張パケットとともに送信する。
（当審注：前記「○２」は、いわゆる丸付き数字の２、すなわち、数字の「２」が丸で囲まれた記号を表す。）
（ウ） ２４頁右欄３１〜３６行
「現在、本システムはRTP/RTCPを対象に実装を行っている。このとき、
メディアパケット（RTP）
制御用パケット（RTCP）は
冗長パケットを生成しない仕様となっている。
（エ） 図１
（オ） ２５頁左欄１〜９行
「2.3. パケットフォーマット
(a) ヘッダ構成
　ゲートウェイ間での通信に用いられるヘッダの構成を図２に示す。ここでは、ストリームデータの転送プロトコルとしてRTP、ストリームデータの制御プロトコルとしてRTCPを想定している。
ゲートウェイ間を通信するパケットにはゲートウェイヘッダが付けられる。ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成される。
（カ） ２５頁左欄１２〜１４行
「
本研究では、信頼性を高めるためにReed-Solomon FECを付加機能として実装した。そのため、拡張ヘッダとしてFECヘッダを定義した。
（キ） ２５頁左欄１５〜１６行
「また、
ゲートウェイで基本ヘッダが付加されたものを拡張パケットと呼ぶ。
（ク） ２５頁左欄２０〜２５行
「図２の例のように
RTPパケットの場合は、FECにより信頼性を高めるため、基本ヘッダとともに拡張ヘッダのFECヘッダ(12byte)を付けることで拡張パケットとなる。
（ケ） 図２
（コ） 表１
（サ） 表２
（シ） ２６頁右欄１〜２２行
「3.4. システムのオーバーヘッド
　本システムではパケットのゲートウェイ中継時に、拡張ヘッダや冗長パケット分の帯域増加と遅延が生じる。本節では、本システム使用時の帯域増加率とFEC処理による遅延時間を測定した。
3.4.1. 帯域増加率
　ゲートウェイ間の通信は、冗長パケットのサイズ（最大ペイロードサイズ）と拡張パケットのヘッダのサイズ分帯域が増加する。帯域の増加率Bは(1)式により算出した。mpsが最大ペイロードサイズ、extは拡張パケットのサイズ（20byte）、
(n,k)は冗長度でkは1ブロック内のメディアパケット数
最大ペイロードサイズは1ブロック内の最大ペイロードサイズで、このサイズでReed-Solomonエンコードの演算処理を行う。
　今回の測定では、圧縮方式がmjpegを使用し、ペイロードは固定長で1328byteである。これより(1)式のx及びmpsは1328であり、Bと実測値は同じになる。」
（当審注：上記の「extは拡張パケットのサイズ（20byte）」との記載は、「extは拡張パケットのヘッダのサイズ（20byte）」の誤記と認める。）
（ス） ２６頁右欄(1)式
イ（ア）ａ　前記ア（イ）によれば、引用文献１に記載されたGateway1の動作は、メディアパケットにヘッダを付けて拡張パケットを生成する段階と、FECエンコードにより、冗長パケットを生成する段階を含む。
ｂ　前記ア（ウ）によれば、メディアパケットはRTPパケットであり、前記ア（ク）によれば、RTPパケットの場合は、基本ヘッダ(8byte)とともに拡張ヘッダのFECヘッダ(12byte)を付けることで拡張パケット（以下、このパケットを「RTP拡張パケット」という。）となり、そして、前記ア（オ）によれば、ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成されるのだから、前記ａの「メディアパケットにヘッダを付けて拡張パケットを生成する段階」は「メディアパケット（RTP）に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階」だといえる。
ｃ　前記ア（ア）、（シ）及び（ス）によれば、引用文献１に記載されたGateway1は、シンボル長を最大ペイロードサイズとして冗長度を(n,k)としたReed-Solomon符号により、k個のメディアパケットを1ブロックとしてFECエンコードして、n-k個の冗長パケットのペイロードを生成すると認められる。
ｄ　前記ア（オ）によれば、ゲートウェイ間を通信するパケットにはゲートウェイヘッダが付けられ、ゲートウェイヘッダは基本ヘッダと拡張ヘッダにより構成される。そして冗長パケットは、明らかにゲートウェイ間を通信するパケットである。加えて、前記ア（コ）の表１によれば、基本ヘッダにはペイロードタイプを格納するフィールドが存在し、ペイロードタイプの値が44ならば冗長パケットを表すから、冗長パケットのゲートウェイヘッダには基本ヘッダが含まれる。さらに、前記ア（カ）によれば、拡張ヘッダはReed-Solomon FECを付加機能として実装したために定義されたのだから、Reed-Solomon符号を用いたFECエンコードにより得られる冗長パケットのゲートウェイヘッダには拡張ヘッダが含まれる。このことは、RTCPが冗長パケットを生成しないこと（前記ア（ウ））から、冗長パケットがRTPで伝送されると推認されること、及び、図１においてRedundant packet（冗長パケットのことと認める）にData packetと同様のヘッダが付されていることとも整合する。そうすると、前記ｃにおける冗長パケットのペイロードに、基本ヘッダ及び拡張ヘッダが付されることによって、冗長パケットが生成されると認められるから、前記ａの「FECエンコードにより、冗長パケットを生成する段階」は、「k個のメディアパケット（RTP）を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階」と「n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階」との２つの段階を含んでいると認められる。
ｅ　前記ｂ及びｄを総合すると、引用文献１にはGateway1の動作として、「
メディアパケット（RTP）に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階と；k個のメディアパケット（RTP）を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階と；n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階とを含む
（イ） 前記ア（イ）によれば、引用文献１に記載されたGateway1の動作は、冗長パケットを拡張パケットとともに送信する段階を含む。
　前記ア（イ）の拡張パケットは、前記（ア）ｂのとおり、メディアパケットに基本ヘッダ及び拡張ヘッダを付けたRTP拡張パケットである。他方、前記ア（キ）によれば、ゲートウェイで基本ヘッダが付加されたものを「拡張パケット」と称しているが、冗長パケットも基本ヘッダが付与されているので、前記ア（キ）の拡張パケットはRTP拡張パケットとは異なっていることが明らかであり、以下、これを「広義の拡張パケット」という。
　そして、前記（ア）ｅのとおり、RTP拡張パケット及び冗長パケットはいずれも基本ヘッダ（及び拡張ヘッダ）を付加されたものであるから、両者とも広義の拡張パケットに含まれる。このことは、ゲートウェイ間を通信するパケットには基本ヘッダと拡張ヘッダが付されること（前記ア（オ））、基本ヘッダのペイロードタイプのフィールドによりメディアパケットと冗長パケットとが区別されること（前記ア（コ）の表１）とも整合する。
　そうすると、前記「冗長パケットを拡張パケットとともに送信する段階」は、「
冗長パケットを含む広義の拡張パケットを送信する段階
（ウ） 前記（イ）のとおり、基本ヘッダは広義の拡張パケットのヘッダの一部分を成すものである。そして、基本ヘッダには、シーケンス番号のフィールドに、パケットのシーケンス番号が格納される（前記ア（コ）の表１）。
　また、広義の拡張ヘッダの一種である冗長パケットの基本ヘッダには、ペイロードタイプのフィールドに冗長パケットを表す値44が格納され、シーケンス番号のフィールドにパケットのシーケンス番号が格納される（前記ア（コ）の表１）。
　そうすると、引用文献１には、「
広義の拡張パケットの基本ヘッダーはパケットのシーケンス番号を含む」こと、及び、「冗長パケットの基本ヘッダーは、冗長パケットを示す値44とパケットのシーケンス番号とを含むこと
（エ） 前記ア（サ） 表２によれば、広義の拡張パケットの拡張ヘッダには、SNベースのフィールドに、Reed-Solomon符号の1ブロック内の最小シーケンス番号が格納される。
　前記（ア）ｃのとおり、Reed-Solomon符号の1ブロックはk個のメディアパケット（RTP）から成るので、前記最小シーケンス番号は、Reed-Solomon符号を用いたFECエンコードの対象となったk個のメディアパケットの最小シーケンス番号である。
　そうすると、引用文献１には、「
Reed-Solomon符号を用いたFECエンコードの対象となったブロックを構成するk個のメディアパケット（RTP）の最小シーケンス番号が、各々の広義の拡張パケットのヘッダーに含まれる
（オ） 前記（イ）のとおり、引用文献１のGateway1の動作は、冗長パケットをRTP拡張パケットとともに送信する段階を含むのであるから、
引用文献１はパケット伝送方法を開示している
前記パケット伝送方法は、メディアデータを送信するための方法に他ならない。
（カ） 前記（ア）〜（オ）によれば、引用文献１には、以下の発明（以下、「引用発明」という。）が記載されている。
　「メディアデータを送信するための方法であって、
　メディアパケット（RTP）に基本ヘッダ及び拡張ヘッダにより構成されるゲートウェイヘッダを付けてRTP拡張パケットを生成する段階と；
　k個のメディアパケット（RTP）を1ブロックとしてReed-Solomon符号を用いてFECエンコードしてn-k個の冗長パケットのペイロードを生成する段階と；
　n-k個の冗長パケットのペイロードのそれぞれに基本ヘッダ及び拡張ヘッダを付して冗長パケットを生成する段階と；
　冗長パケットを含む広義の拡張パケットを送信する段階と；を含み、
　ここで、広義の拡張パケットの基本ヘッダーはパケットのシーケンス番号を含み、
　冗長パケットの基本ヘッダーは、冗長パケットを示す値44とパケットのシーケンス番号とを含み、
　Reed-Solomon符号を用いたFECエンコードの対象となったブロックを構成するk個のメディアパケット（RTP）の最小シーケンス番号が、各々の広義の拡張パケットのヘッダーに含まれる
　パケット伝送方法。」
（２） 引用文献２について
　引用文献２には、図面とともに、次の記載がある。なお、下線は強調のために当審が付した。
ア　「【００１７】
　図１３は，ＦＥＣによる損失パケット回復の方法を説明する図である。
ここで使用する誤り訂正符号は，ｋ個の値の入力に対して（ｎ−ｋ）個の冗長な値を演算し，合計でｎ個の値を出力する（ｎ，ｋ）誤り訂正符号である。このような符号の例としては，（ｎ，ｋ）リードソロモン符号
が挙げられる。
イ　「【００２１】
　ＦＥＣ符号化演算が終了したら，ＦＥＣ符号化バッファ４０２の各行をペイロードとする通信パケットを構成し，通信ネットワーク３０１へ送出する。図１３においては，符号情報のペイロードを格納した通信パケットをメディアパケット，
ＦＥＣ符号を格納した冗長な通信パケットをＦＥＣパケットと称している。
ウ　「【００２５】
　
図１４は，ＲＦＣ２７３３で規定されるＦＥＣパケットのヘッダフォーマットの一部を模式的に表したものである。メディアパケットおよびＦＥＣパケットは，ＲＦＣ３５５０で規定されるＲＴＰパケットフォーマットに準拠するが，このＲＴＰヘッダに存在するシーケンス番号フィールド（１６ビット）に，それぞれのシーケンス番号を付与する。
エ　図１４
　図１４からは、ｋ個のメディアパケットのヘッダにはMからM+k-1のシーケンス番号が付与され、
n-k個のＦＥＣパケットのヘッダにはFからF+(n-k-1)のシーケンス番号が付与される
４　対比
　本願発明と引用発明とを対比する。
（１） 本願発明と引用発明とは、「
メディアデータを送信するための方法
パケット伝送方法
（２） 引用発明の「メディアパケット（RTP）」は、明らかに本願発明の「伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）」である。
　誤り訂正の技術分野において、Reed-Solomon符号が著名な誤り訂正符号であること及びFEC（Forward Error Correction）が前方エラー訂正を意味することに鑑みると、引用発明における「Reed-Solomon符号を用いてFECエンコード」することは、本願発明における「順方向エラー訂正（ＦＥＣ）符号化」することに相当する。
　引用発明において「k個のメディアパケット（RTP）を1ブロックとしてReed-Solomon符号を用いてFECエンコードして」生成される「冗長パケットのペイロード」は、メディアパケット（RTP）の誤り訂正のためのシンボルであることが明らかであり、本願発明の「リペアシンボル」に相当する。そうすると、本願発明と引用発明とは、「伝送する少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を順方向エラー訂正（ＦＥＣ）符号化し、リペアシンボルを生成する段階」を含む点で一致する。
（３） 引用発明の「冗長パケット」は、「冗長パケットのペイロード」に基本ヘッダ及び拡張ヘッダを付して生成されるものであるから、「冗長パケットのペイロード」を利用して生成されるものである。そうすると、本願発明と引用発明とは「前記リペアシンボルを利用してリペアパケットを生成する段階」を含む点で一致する。
（４） 引用発明の「RTP拡張パケット」は、「メディアパケット（RTP）」にゲートウェイヘッダを付加することにより生成される点で、「メディアパケット（RTP）を利用して生成される」といえる。
　また、引用発明の「冗長パケット」は、前記（２）のとおり、「メディアパケット（RTP）」をReed-Solomon符号を用いてFECエンコードして生成されたペイロードにヘッダを付加して生成される点で、「メディアパケット（RTP）を利用して生成される」といえる。
　そして、「広義の拡張パケット」は、前記３（１）イ（イ）に示したとおり「RTP拡張パケット」及び「冗長パケット」含むものであるから、本願発明の「ＦＥＣパケット」に相当する。
　そうすると、引用発明の「広義の拡張パケット」に含まれる「RTP拡張パケット」及び「冗長パケット」はいずれも「メディアパケット（RTP）を利用して生成される」といえるから、本願発明と引用発明とは、「前記少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を利用してＦＥＣパケットを生成する段階」を含む点で一致する。
（５） 引用発明の「
冗長パケットを含む広義の拡張パケットを送信する段階」は、本願発明の「
」に相当する。
（６） パケット通信の技術常識に鑑みると、パケットに付されるシーケンス番号は、順次に増加する番号である。そうすると、引用発明の「パケットのシーケンス番号」は本願発明の「順次に増加するシーケンス番号」に相当し、本願発明と引用発明とは「ＦＥＣパケットヘッダーは、順次に増加するシーケンス番号を含」む点で一致する。
（７） 引用発明の「冗長パケットを示す値44」は、明らかに本願発明の「リペアパケットを示す識別子」である。
　シーケンス番号は連続的な番号のことであるから、本願発明と引用発明とは、「前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子とパケットのための連続的なシーケンス番号を含」む点で共通する。
（８） 引用発明の「広義の拡張パケット」のヘッダーに含まれる「最小シーケンス番号」は、FECエンコードの対象となったブロックを構成するk個のメディアパケット（RTP）の最小番号である。そうすると、前記「最小シーケンス番号」は、FECエンコードを行う対象となるブロックの最初のメディアパケットのシーケンス番号であるから「初期シーケンス番号」であって、対応するFECブロックの境界を表す情報だといえる。よって、本願発明と引用発明とは、「対応するＦＥＣブロックの初期シーケンス番号は、ＦＥＣブロック境界情報として各パケットのヘッダーに含まれ」る点で一致する。
（９） 請求人が令和元年９月２４日提出の意見書で『「ＦＥＣの境界」と「ＦＥＣブロック境界」とは同一の意味であり、「ＦＥＣの境界に関する情報」と「ＦＥＣブロック境界情報」とは同一の意味であるものと思料致します。』（１頁下から８行目〜下から６行目）と主張する以上、本願発明の「前記ＦＥＣパケットはＦＥＣの境界に関する情報を含む」との発明特定事項は、「前記ＦＥＣパケットはＦＥＣブロック境界情報を含む」の意味であると解すべきである。
　そうすると、本願発明と引用発明とが前記（８）のとおり「対応するＦＥＣブロックの初期シーケンス番号は、ＦＥＣブロック境界情報として各パケットのヘッダーに含まれ」る点で一致する以上、本願発明と引用発明とが「前記ＦＥＣパケットはＦＥＣの境界に関する情報を含む」点で一致することは明らかである。
（１０） 前記（１）〜（９）によれば、本願発明と引用発明との一致点及び相違点は以下のとおりである。
〈一致点〉
「メディアデータを送信するための方法において、
　伝送する少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を順方向エラー訂正（ＦＥＣ）符号化し、リペアシンボルを生成する段階と；
　前記少なくとも１つの伝送パケット（ｔｒａｎｓｐｏｒｔ　ｐａｃｋｅｔ）を利用してＦＥＣパケットを生成する段階と；
　前記リペアシンボルを利用してリペアパケットを生成する段階と；
　前記リペアパケットを含む前記ＦＥＣパケットを送信する段階と；を含み、
　ここで、ＦＥＣパケットヘッダーは、順次に増加するシーケンス番号を含み、
　前記リペアパケットのヘッダーは、前記リペアパケットを示す識別子とパケットのための連続的なシーケンス番号を含み、
　対応するＦＥＣブロックの初期シーケンス番号は、ＦＥＣブロック境界情報として各パケットのヘッダーに含まれ、
　前記ＦＥＣパケットはＦＥＣの境界に関する情報を含む
　ことを特徴とするパケット伝送方法。」である点。
〈相違点〉
　本願発明のリペアパケットのヘッダーに含まれる「連続的なシーケンス番号」は、「リペアパケットのための」ものであるのに対し、引用発明の冗長パケットの基本ヘッダーに含まれる「シーケンス番号」は、冗長パケットのためのものであるのか否かが明らかではない点。
５　判断
　前記相違点について検討する。
　ＦＥＣ符号化において、メディアパケット、冗長パケットにそれぞれシーケンス番号を付与すること、すなわち、冗長パケットに冗長パケット用のシーケンス番号を付与することは周知技術である（前記３（２））。
　前記周知技術は、パケットに対してＦＥＣ符号化を行ってＦＥＣパケットを生成する技術であるから、引用発明における冗長パケットのシーケンス番号として、前記周知技術のように、冗長パケット用のシーケンス番号を用いることは、当業者であれば容易に想到し得ることである。
　そして、本願発明の効果は、引用発明の構成及び前記周知技術から当然に奏されるものであり、格別のものではない。
　以上のとおりであるから、本願発明は、引用発明及び周知技術に基づいて、容易に発明できたものである。
第４　むすび
　以上のとおり、本願発明は、特許法２９条２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。