【事件の表示】
　特願２０１０−　１７０２０「パケット送信装置、通信システム及びプログラム」拒絶査定不服審判事件〔平成２２年　５月２７日出願公開、特開２０１０−１１９１３３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は、平成１７年１１月９日に出願した特願２００５−３２４２２４号の一部を平成２２年１月２８日に新たな特許出願としたものであって、平成２４年３月２３日付けで拒絶理由が通知され、同年６月４日付けで手続補正がされたが、同年９月２５日付けで拒絶査定がなされ、これに対し、同年１２月２８日に拒絶査定不服の審判が請求されるとともに、同日付けで手続補正がされ、平成２５年３月２１日付けで審尋がなされ、同年５月２７日に回答書が提出されたものである。
　
第２　補正却下の決定 
［補正却下の決定の結論］ 
　平成２４年１２月２８日付けの手続補正を却下する。 
 　 
［理由］ 
１．本願発明と補正後の発明 
　上記手続補正（以下、「本件補正」という。）は補正前の平成２４年６月４日付け手続補正書の特許請求の範囲の請求項１に記載された 
　 
　「ネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
　前記到着期限までに到着可能とされた不達パケットの再送を制御するパケット自動再送部と、
　データパケットに冗長パケットを付加する前方誤り訂正符号化部と、
　往復伝搬遅延値が第１の遅延値の場合、前記不達パケットの再送により誤り訂正を行い、往復伝搬遅延値が前記第１の遅延値より大きい第２の遅延値の場合、前記不達パケットの再送及び第１の冗長度の冗長パケットの付加により誤り訂正を行い、往復伝搬遅延値が前記第２の遅延値より大きい第３の遅延値の場合、前記第１の冗長度より大きい第２の冗長度の付加により誤り訂正を行うよう前記パケット自動再送部及び前記誤り訂正符号化部を制御する制御部と
を有するパケット送信装置。」 
 　
という発明（以下、「本願発明」という。）を、 
　 
　「ネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
　前記到着期限までに到着可能とされた不達パケットの再送を制御するパケット自動再送部と、
　データパケットに冗長パケットを付加する前方誤り訂正符号化部と、
　往復伝搬遅延値が第１の遅延値の場合、前記不達パケットの再送により誤り訂正を行い、往復伝搬遅延値が前記第１の遅延値より大きい第２の遅延値の場合、前記不達パケットの再送及び第１の冗長度の冗長パケットの付加により誤り訂正を行い、往復伝搬遅延値が前記第２の遅延値より大きい第３の遅延値の場合、前記第１の冗長度より大きい第２の冗長度の冗長パケットの付加により誤り訂正を行うよう前記パケット自動再送部及び前記誤り訂正符号化部を制御する制御部とを有し、
　前記パケット自動再送部は、前記到着期限と前記往復伝搬遅延値に基づいてパケット受信装置が送信する再送要求パケットを受信することで、前記不達パケットの再送を制御する、
　パケット送信装置。」
　
という発明（以下、「補正後の発明」という。）に変更することを含むものである。 
　
２．新規事項の有無、補正の目的要件について 
　本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１に記載された、「第２の冗長度の付加」に関し、「第２の冗長度の冗長パケットの付加」と限定し、「パケット自動再送部」に関し、「前記パケット自動再送部は、前記到着期限と前記往復伝搬遅延値に基づいてパケット受信装置が送信する再送要求パケットを受信することで、前記不達パケットの再送を制御する」と限定して、特許請求の範囲を減縮するものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び同改正前の特許法第１７条の２第４項第２号（補正の目的）の規定に適合している。 
　
３．独立特許要件について 
　本件補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 
　
（１）補正後の発明 
　上記「１．本願発明と補正後の発明」の項で補正後の発明として認定したとおりである。 
　
（２）引用発明 
Ａ　原審の拒絶理由に引用された特開２００３−１７９５８０号公報（以下、「引用例１」という。）には、図面とともに以下の事項が記載されている。 
　
イ．「【０００１】
【発明の属する技術分野】本発明は、データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。さらに詳細には、ストリーミングデータ転送におけるエラー耐性を高めたパケット送信構成を持つデータ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラムに関する。」（５頁７〜８欄） 
　
ロ．「【００５６】図２のデータ通信システムにおいて、送信側端末２０１は受信側端末２０２に対して画像、音声等のデータをパケット化して送信する。転送データは、例えばビデオカメラ２０３によって取得された画像、音声データである。なお、転送データは、ＣＤ，ＤＶＤ等の記憶媒体から入力されるデータ、あるいは外部ネットワーク、衛星等から受信するデータ等であってもよい。なお、以下の説明では、１つの例として送信側端末２０１から受信側端末２０２へビデオカメラ２０３によって取得された動画像データを転送する構成を中心として説明する。
【００５７】ビデオカメラ２０３によって取得された動画像データは、送信側端末２０１の符号化装置（エンコーダ）２０４により符号化、例えばＭＰＥＧ圧縮処理等による符号化がなされ、階層化部２０５、優先度付け処理部２０６において、送信するデータ、および端末側の再生能力などに応じてデータを階層化し、優先度付け処理を実行する。」（１０頁１７〜１８欄）
　
ハ．「【００８２】このように、優先度付け処理部２０８において、優先度付け処理が行なわれるたデータはバッファ２０７ヘ出力され保存される。バッファ２０７に保存された符号化データは、ＦＥＣ(Forward Error Correction)処理部２０８において、エラー訂正のための冗長コードが必要に応じて付与される。ＦＥＣの手法としては、ＡＴＭのＡＡＬ１におけるパケットロスに対してＦＥＣを行う手法、ITU-T  Recommendation  I.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2specificationに記載のマトリックスを作って損失パケットのリードソロモン復号する手法に準じた方法等が適用可能である。なお、ＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理は、個々のデータに基づく冗長コード付与ではなく、エラー耐性を高めるために複数のデータに渡るテータに基づいて冗長コードを付与する処理、すなわちインターリーブ処理を併せて実行する構成としてもよい。
【００８３】このＦＥＣ(Forward Error Correction)処理部２０８における、エラー訂正のための冗長コード付与処理はすべての階層レベルのパケットに対して同等に処理する必要はなく、ＦＥＣ(Forward Error Correction)処理部２０８は、例えばネットワークの混雑等によるパケットの遅延状況、ネットワークの帯域等をネットワーク監視部２１５が検出し、この検出情報に基づいてＦＥＣ（フォワード・エラー・コレクション）の冗長度を変化させる等、処理を動的に変更する。
【００８４】上述のように、送信側端末２０１は、ネットワーク監視部２１５の情報、すなわち、受信側端末２０２からの受信側端末のデータ受信状況に関する情報、ネットワーク状況に関する情報に基づいて、エンコーダ２０４における符号化態様、階層化部２０５における階層設定処理態様、優先度付け処理部２０６における優先度設定処理態様、ＦＥＣ(Forward Error Correction)処理部２０８における処理を動的に変更可能である。
【００８５】上述した送信側端末の処理構成に基づいて、例えば符号化階層（レイヤー）毎に実行すべきエラー処理態様として、ＦＥＣ処理対象階層データとしたり、あるいは再生要求処理（ＡＲＱ：Auto Repeat reQuest）対象階層データとしての割り当てが可能となり、各階層において最適なエラー訂正とスループットを得ることが可能となる。つまり、伝送路状況がエラー率が高かったり遅延が大きいなどパケット再生処理（ＡＲＱ：Auto Repeat reQuest）に不利な状況ではＦＥＣでエラー訂正を実行する設定としたり、あるいは伝送遅延が小さいが冗長データを送りたくない場合には、ＦＥＣではなくＡＲＱを利用したエラー対応とするなど、送信側で任意のエラー対応設定としたデータパケットの送信が可能となる。」（１３頁２３〜２４欄）
　
ニ．「【００９３】本発明のデータ通信システムでは、エラー監視部２２２にてパケット損失が発見された場合、エラー訂正制御部２３０は、ＦＥＣにより復元可能かを判断する。ＦＥＣにより訂正可能ならば、エラー訂正制御部２３０は、ＦＥＣに基づくエラー訂正を実行する。ＦＥＣエラー訂正によるデータ復元が実行された場合は、送信側端末２０１に対するデータ再送要求としてのＡＲＱ（Auto Repeat reQuest）処理は実行しない。訂正不可能であると判定した場合には、エラー訂正制御部２３０は、再送要求としてＡＲＱ（Auto Repeat reQuest）処理を実行する。図２においては、再送要求としてＲＴＣＰパケット生成部２２７において、ＲＴＣＰパケットを作成し、ＲＴＣＰポート２２５より再送要求を送信側端末に送信する構成を持つ。なお、再送要求伝送処理のプロトコルはＲＴＣＰに限らず、ＴＣＰに従った再送要求をＴＣＰポート２２８を介して出力してもよい。
【００９４】エラー訂正制御部２３０において、再送要求を実行するとの判定がなされた場合、受信側端末２０２は、再送要求パケットを識別するデータを格納した再送要求ＮＡＣＫ（Negative ACKnowledge)−ＲＴＣＰ（Real-time Transport ControlProtocol）パケットをＲＴＣＰパケット生成部２２７にて作成し、ＲＴＣＰパケットポート２２５を介して、送信側端末２０１に対して出力する。
【００９５】送信側端末２０１のＲＴＣＰパケットポート２１７が、受信側端末２０２からの再送要求を示すＮＡＣＫ−ＲＴＣＰパケットを受信すると、受信したＮＡＣＫ−ＲＴＣＰパケットをＲＴＣＰパケット解析部２１６に渡す、ＲＴＣＰパケット解析部２１６はパケットの解析を実行し、解析結果をＡＲＱ制御部２１３、およびネットワーク監視部２１５へ渡す。ネットワーク監視部２１５は、入力情報に基づいて、ＡＲＱの頻度の検出が可能となり、伝送状態を判定することが可能であり、これらの情報を階層エラー訂正優先度制御部２１２に出力し、階層エラー訂正優先度制御部２１２は入力情報に基づいて、符号化、階層化、優先度付け、ＦＥＣ処理の各処理態様の動的変更制御を行なうことが可能となる。
【００９６】また、ＲＴＣＰパケット解析部２１６において解析した解析結果を受信したＡＲＱ制御部２１３では、再送要求に応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴＣＰパケットにおいて指定されたパケットをバッファ２０７から抽出し、抽出したパケットを、ＲＴＰポート２１０を介して再送する制御処理を実行する。ＡＲＱ制御部２１３は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。
【００９７】送信側端末２０１において送信すべきストリームデータの終了を検知した場合には、送信側端末２０１のＲＴＣＰパケット生成部２１４の生成したストリームの終了を示すＥＯＳ（End Of Stream）メッセージを持つＲＴＣＰパケットを受信側端末２０２へ送り、データストリームの終了を明示する。
【００９８】本発明のデータ通信システムにおいては、リアルタイム再生を考慮して、ロストパケットに関する再送要求の実行／非実行の処理を決定する。データ転送における自動再送要求方式であるＡＲＱ（Automatic Repeat reQuest）は非常に有効な誤り訂正機能として知られている。ＡＲＱの具体的方式としては、例えばＳＡＷ（Stop And Wait）方式、ＧＢＮ（Go Back N）方式、ＳＲ（Selective Repeat）方式など種々の方法が提案され実現されている。」（１４頁２６欄〜１５頁２７欄）
　
ホ．「【０１０１】図２のデータ通信システムにおける受信側端末２０２のエラー訂正制御部２２３の処理について、さらに説明する。エラー訂正制御部２２３は、ネットワーク監視部２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、往復伝播遅延（ＲＴＴ）やパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。ＡＲＱにおいてデータ再生におけるリアルタイム性を保持するためには、常に送信と受信における往復伝播遅延（ＲＴＴ）を計測しておく必要がある。本発明のシステムでは、データ受信側端末は、能動的にＲＴＴを計測し、ネットワーク状況等において変化する送信と受信における往復伝播遅延（ＲＴＴ）の更新を実行し、最新のＲＴＴに基づいて再送要求としてのＮＡＣＫ−ＲＴＣＰの送信の実行可否を判定する。
【０１０２】送信と受信における往復伝播遅延（ＲＴＴ）をデータ受信端末において、あらかじめ把握することにより、データ受信端末において、再送要求を行なってから再送パケットを受信するまでの時間の把握が可能となり、データ受信端末においてリアルタイム再生を行なうために必要な最終再送要求時間を割り出すことが可能なる。本発明のシステムでは、受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。これらの処理については、次の各端末の処理フローの説明において詳細に説明する。」（１５頁２８欄）
　
ヘ．「【０１３８】［データ受信端末における処理］次に、データ受信端末の処理手順を図１４に示すフローチャートを参照して説明する。図１４に示す処理は、図２の受信側端末２０２において実行される処理を説明したフローである。
【０１３９】データ受信端末は、ステップＳ４００において、データ送信端末からの送信開始通知を受信後、ステップＳ４０１において、データ送信端末からの送信パケット、すなわち符号化データをペイロードとして格納したＲＴＰパケットを順次、受信する。ＲＴＰパケットは、先に、図６を参照して説明したように、タイムスタンプがヘッダ情報中に格納されている。データ受信端末は、タイムスタンプに基づいて受信するパケットに含まれるフレームを判別することができる。先に説明したように、動画像データをＲＴＰパケットに符号化データとして格納して送信する場合、同一の画像フレームに属する複数のＲＴＰパケットには同一のタイムスタンプが設定され、データ受信側端末は、タイムスタンプを参照して、フレームの判別が可能となる。
【０１４０】データ受信端末は、ステップＳ４０２において、受信パケットがエラー訂正のための冗長コードが付与されているか否かを判定する。冗長コードが付与されている場合は、ステップＳ４１１に進み、エラー訂正制御部２３０において、データ送信側で実行したインターリーブ対応するインターリーブ処理を実行して、ステップＳ４１２において、損失パケットの有無を判定する。損失パケットが無い場合は、ステップＳ４１６のデコード処理に進む。損失パケットがある場合は、ステップＳ４１３で、ＦＥＣによるエラー訂正、すなわち冗長コードに基づくエラー訂正処理を実行し、エラー訂正により再生可能か否かを判定する。再生可能であると判定した場合は、ステップＳ４１６のデコード処理に進む。
【０１４１】ステップＳ４１３においてＦＥＣによる処理のみでは、再生可能でないと判定した場合は、ステップＳ４１５に進む。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理について説明する。リアルタイム再生処理を実現するためには、再生タイミングに間に合うように、再送要求パケットが受信端末に届くことが必要となる。ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。
【０１４２】この判定のためには、前述したように、送信端末と受信端末間における往復伝播遅延（ＲＴＴ）が重要なパラメータとなる。往復伝播遅延（ＲＴＴ）が大きい場合、データ受信端末からデータ送信端末に対して再送要求を出しても、再送要求を発信して、再送パケットがデータ送信端末から再送され、データ受信端末において受信するまでに時間を要すると、その後デコーダに渡して復号を行なってリアルタイム再生に間に合わない場合が発生する。本発明のシステムでは、データ受信端末において、往復伝播遅延（ＲＴＴ）をあらかじめ把握し、往復伝播遅延（ＲＴＴ）に基づいて、ＮＡＣＫ−ＲＴＣＰパケットの送信判定処理を行なう。」（１９頁３５〜３６欄）
　
ト．「【０１７１】また、本発明のデータ通信システムにおける送信側端末の階層エラー訂正優先度制御部２１２は、および受信側端末２０２のエラー訂正制御部２３０は、それぞれのネットワーク監視部２１５、２２９によって監視されている現在のネットワーク状況を踏まえてエラー訂正を制御する。ネットワークの監視は、ＲＴＴやパケットロス率などＲＴＣＰやＩＣＭＰなどの汎用のプロトコルを利用して取得する。受信側がＲＴＴを検知するために、受信側は、前述したＥＣＨＯパケットを送信側に送り、その返事であるＥＣＨＯ−ＲＥＰＬＹパケットを受け取ることにとって、ＲＴＴを計測し、確実なパケット再送処理が実現される。
【０１７２】先に説明したように、ＲＴＰではパケット毎にシーケンス番号をつけており、番号とフレームの先頭と終端を示すフラグをペイロードにいれておくことにより、あるフレームを構成するパケット数を簡単に受信側は計算することができ、必要なパケット数に対してある時間内にどれだけ正当なパケットが届いたかを監視していれば、ある程度のエラー率を求めることができる。ここで得られたエラー率またはＲＦＣ１８８９で規定されているＲＴＣＰのＲＲ（ＲｅｃｉｅｖｅｒＲｅｐｏｒｔ）でのパケットロス率により、送信側はエラー率を知りＦＥＣのエラー訂正強度をあげたり、またはＦＥＣを施さないなどの処理態様の制御を実行する。
【０１７３】エラー訂正処理として実行されるパケット再送要求（ＡＲＱ）は、再送要求ＮＡＣＫを送信し再送パケットが届くまでにＲＴＴ時間を要することになり、また、ＦＥＣ訂正においても送受信端末でインターリーブする処理のために一定時間が必要となる。それぞれの端末におけるネットワーク監視部の監視により得られるネットワーク状況に基づいて、例えば、ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。」（２２頁４１〜４２欄）
　
　上記引用例１の記載及び図面並びにこの分野における技術常識を考慮すると、上記ロ．の【００５６】における「送信側端末２０１は受信側端末２０２に対して画像、音声等のデータをパケット化して送信する。」との記載、及び図２によれば、送信側端末（２０１）は、ＩＰネットワーク（２１９）経由で受信側端末（２０２）にパケットを送信するものである。
　また、上記ニ．の【００９６】における「ＡＲＱ制御部２１３は、データ受信端末装置から受信する再送要求メッセージパケットに従って再送すべきデータパケットの抽出処理を実行する再送制御部として機能する。」との記載、及び図２によれば、送信側端末（２０１）は、再送を制御するＡＲＱ制御部（２１３）を備えている。ここで、上記ヘ．の【０１４１】における「・・・ステップＳ４１５の再送要求処理としてのＮＡＣＫ−ＲＴＣＰパケットの送信判定処理は、ＮＡＣＫ−ＲＴＣＰパケットを送信した場合、リアルタイム再生処理に間に合うタイミングで、再送パケットが受信可能か否かを判定するものである。」との記載によれば、受信側端末（２０２）は、再送要求パケット（ＮＡＣＫ−ＲＴＣＰ）を送信するか否かの判定処理において、リアルタイム再生処理に間に合うタイミング、すなわち、到着期限に基づいて再送要求パケット（ＮＡＣＫ−ＲＴＣＰ）を送信している。
　また、上記ニ．の【００９６】における「ＡＲＱ制御部２１３では、再送要求に応じたパケットの再送を実行するため、ＮＡＣＫ−ＲＴＣＰパケットにおいて指定されたパケットをバッファ２０７から抽出し、抽出したパケットを、ＲＴＰポート２１０を介して再送する制御処理を実行する。」との記載によれば、送信側端末（２０１）のＡＲＱ制御部（２１３）は、再送要求パケット（ＮＡＣＫ−ＲＴＣＰ）を受信することで、再送パケットの再送を制御している。そして、前述の再送パケットは、前述の到着期限までに到着可能とされたものであることは明らかである。
　また、上記ホ．の【０１０２】における「受信端末のＡＲＱ判定部において、往復伝播遅延（ＲＴＴ）に基づく最終再送要求時間を判定し、判定に基づいて、再送要求としてのＮＡＣＫ−ＲＴＣＰの送信を実行する。」との記載によれば、受信側端末（２０２）は、往復伝播遅延（ＲＴＴ）に基づいて再送要求パケット（ＮＡＣＫ−ＲＴＣＰ）を送信している。
　また、上記ハ．の【００８２】における「ＦＥＣ(Forward Error Correction)処理部２０８において、エラー訂正のための冗長コードが必要に応じて付与される。」との記載、及び図２によれば、送信側端末（２０１）は、データパケットに冗長コードを付与するＦＥＣ(Forward Error Correction)処理部（２０８）を備えている。
　また、上記ト．の【０１７１】における「送信側端末の階層エラー訂正優先度制御部２１２は、・・・」との記載、同ト．の【０１７３】における「ＲＴＴが短いならば、ＡＲＱによる再送が可能となるためＡＲＱによるエラー訂正を選択して実行し、ＲＴＴが長く、再送する時間がないほど送信側から受信側に転送時間がかかるというネットワーク状況である場合には、ＡＲＱではなくＦＥＣによるエラー訂正を選択する、といった動的なエラー訂正制御が可能となる。」との記載によれば、送信側端末（２０１）の階層エラー訂正優先度制御部（２１２）は、往復伝播遅延（ＲＴＴ）が短い場合、再送パケットの再送によりエラー訂正を行い、往復伝播遅延（ＲＴＴ）が長い場合、冗長コードの付与によりエラー訂正を行うよう前述のＡＲＱ制御部（２１３）及び前述のＦＥＣ(Forward Error Correction)処理部（２０８）を制御していることが読み取れる。
　
　したがって、上記引用例１には、以下の発明（以下、「引用発明１」という。）が記載されているものと認められる。
　
　「ＩＰネットワーク（２１９）経由で、到着期限に制限のあるパケットを送信する送信側端末（２０１）であって、
　前記到着期限までに到着可能とされた再送パケットの再送を制御するＡＲＱ制御部（２１３）と、
　データパケットに冗長コードを付与するＦＥＣ(Forward Error Correction)処理部（２０８）と、
　往復伝播遅延（ＲＴＴ）が短い場合、前記再送パケットの再送によりエラー訂正を行い、往復伝播遅延（ＲＴＴ）が長い場合、冗長コードの付与によりエラー訂正を行うよう前記ＡＲＱ制御部（２１３）及び前記ＦＥＣ(Forward Error Correction)処理部（２０８）を制御する階層エラー訂正優先度制御部（２１２）とを有し、
　前記ＡＲＱ制御部（２１３）は、前記到着期限と前記往復伝播遅延（ＲＴＴ）に基づいて受信側端末（２０２）が送信する再送要求パケット（ＮＡＣＫ−ＲＴＣＰ）を受信することで、前記再送パケットの再送を制御する、
　送信側端末（２０１）。」
　
Ｂ　原審の拒絶理由に引用されたDan Rubenstein,et al.，A Study of Proactive Hybrid FEC/ARQ and Scalable Feedback Techniques for Reliable,Real-Time Multicast，Computer Communications, ２００１年　３月，ＵＲＬ，http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.3538（以下、「引用例２」という。）には、図面とともに以下の事項が記載されている。 
　
チ．「Abstract
　In this paper, we examine the performance benefits of using parity encoding for reliable delivery of data to multiple receivers, where the receivers have heterogeneous loss and delay characteristics. First, we examine the effect of sending parity loss repairs proactively to receivers before it is known whether or not the repairs are needed to repair losses. We show that in many cases, proactive repair can reduce feedback implosion and the expected delay of reliable delivery without increasing bandwidth usage. Next, we examine how proactive repairs can be used to meet end-to-end deadlines to within a tunable probability. Last, we examine several receiver feedback mechanisms for parity repairs in a heterogeneous networking environment, and find that the various mechanisms offer different levels of robustness. Our examinations take into account temporally correlated (bursty) loss, as well as loss of feedback messages from receivers.」（１頁８〜２０行）
　
訳文（チ．）「抄録
　本論文で我々は、複数の受信者に対する信頼性のあるデータ配信のためのパリティエンコーディング使用のパフォーマンス利益を検証する。ここで受信者は、異機種環境損失と遅延特性を持っている。第一に我々は、リペアが損失を修復するのに必要とされるかどうかが分かる前に、パリティ損失リペアを受信者に送ることの効果を検証する。また多くの事例で、プロアクティブリペアがフィードバックインプロージョンを減らすことができ、バンド幅使用を増すことなく、信頼性のある配信の予測された遅延を減らすことを示す。次に、同調可能性の中でエンドツーエンドデッドラインを満たすために、どのようにプロアクティブリペアが使えるか検討する。最後に、異種ネットワーキング環境におけるパリティリペアのための複数の受信者フィードバックメカニズムを検証し、様々なメカニズムが、異なるレベルのロバスト性を提供することを発見する。我々の検証では、受信者からのフィードバックメッセージ損失だけでなく、一時的相関（バースト性）損失を考慮する。」
　
リ．「1　Introduction
The Internet enables the transmission of a variety of types of data. In partic-ular, there is a growing need to reliably transmit real-time data to numerous receivers where data must be received within a bounded amount of time. Ex-amples range from video and audio communication to reliable delivery of stock data. Using multicast instead of multiple point-to-point unicast connections to distribute this information reduces network bandwidth required to sup-port such applications. However, dealing with packet loss for time-constrained multicast applications remains an open and challenging research problem.
　
There are several issues that reliable multicast protocols must address. First, protocols must avoid feedback implosion: an aggregation of feedback from nu-merous receivers to the sender. For instance, it is well understood that pro-tocols that require each of a large number of receivers to notify the sender of a packet loss (NAK)will  overwhelm the networking resources close to or at the sender [TKP97]. It is also  important to reduce the bandwidth used for retransmissions. Previously proposed solutions solve this problem by in-troducing delay [TKP97], or by distributing the repair process among the ses-sion participants in order to reduce the number of requests that must be sent to the sender [FJL+97,PSLS97,KKT98,PPV98,SBE+98,LDW97]. These works are targeted toward  applications that do not have tight time constraints. The unpredictability of the location of the repairing participant complicates the timing and coordination of  retransmissions that is required for real-time de-livery where the deadline is fixed. The STORM protocol [XM97] is designed for real-time delivery, in that it ceases requesting repairs after a deadline has passed. However, again due to the unpredictability of the location of the re-pairing participant, a receiver cannot adjust the level of reliability with which it receives packets, except by modifying the deadline itself.」（１頁２３行〜２頁２１行）
　
訳文（リ．）「1　序論
インターネットにより様々なタイプのデータの転送が可能になった。特に、リアルタイムデータを信頼性高く受信者に送信するニーズは増している。ここでデータは限られた時間内に受信されねばならない。例は、画像や音声通信からストックデータの信頼性のある配信まで、広範囲に及ぶ。ポイントツーポイントユニキャストコネクションの代わりにマルチキャストを使ってこの情報を配信すれば、そうした用途を支援するのに必要なネットワーク帯域幅を減らすことができる。しかし、時間制限マルチキャストアプリケーションのためにパケット損失に対処することは、オープンかつ困難な研究課題である。
　
信頼できるマルチキャストプロトコルが対処しなければならない複数の問題点がある。第一に、プロトコルはフィードバックインプロージョン（多数の受信者から送信者へのフィードバックの集積）を回避しなければならない。例えば多数の受信者が送信者にパケット損失（NAK）を通知することを必要とするプロトコルが、送信者[TKP97]に近いまたは送信者のところにあるネットワーキングリソースを圧迫するということは、良く理解されている。再送信に使われている帯域幅をへらすことも重要である。かつて提案された解決策は、遅延[TKP97]を導入したり、送信者に送られるリクエスト数を減らすためにセッション参加者にリペアプロセスを配信したりすることによって、この問題を解決する[FJL+97, PSL97, KKT98, PPV98,SBE+98,LDW97]ものであった。これらの作業は厳しい時間制限のないアプリケーションを目標とする。修復中の参加者の位置予測不可能性は、デッドラインが固定されている場合、リアルタイム配信のために必要な再送信のタイミングと調整を複雑にする。STORMプロトコル[XMZ97]は、リアルタイム配信のために設計されており、その中ではデッドラインが経過するとリペアを要求することをやめる。しかし、再び修復中の参加者の位置不可知性によって受信者は、デッドライン自体を変更する以外にパケットを受信する際の信頼性のレベルを調整することができない。」
　
ヌ．「３　Ａ Proactive FEC+ARQ Technique
In this section, we look at protocols that use a combination of ARQ and FEC to reliably deliver data to a set of receivers, R[DL95,NBT98]. The novel aspect of these protocols is the use of techniques that proactively transmit FEC repair packets. To simplify our discussion, we restrict our consideration to protocols in which only the sender transmits repairs, and these repairs are always multicast. Furthermore, in this section, we assume that the receivers are homogeneous, i.e., the round-trip time from the sender to each receiver is fixed and identical across receivers. Hence, feedback from receivers in response to a given transmission from the sender reaches the sender at the same time, and repairs and data packets that are multicast by the sender reach receivers at the same time. We can therefore envision the communication between the senders and the set of receivers taking place over a series rounds. In Section 4, we will resolve issues that arise when the assumption that round-trip times to the sender vary across the set of receivers.」（５頁２〜１６行）
　
訳文（ヌ．）「3　プロアクティブFEC+ARQテクニック
本セクションでは、受信者セットにデータを配信するのにARQおよびFECの組み合わせを使うプロトコルに注目するR[DL95,NBT98]。これらのプロトコルの新しい側面は、FECリペアパケットをプロアクティブに送信するテクニックの使用である。議論を簡単にするために、送信者のみがリペアを送信し、これらのリペアは常にマルチキャストであるようなプロトコルに考察を制限する。さらに本セクションでは、受信者はそれぞれ同種のものとする。つまり送信者から各受信者までの往復時間は固定され、受信者間ですべて同じとする。従って、任意の送信に対する受信者からのフィードバックは送信者に同時刻に到達し、送信者がマルチキャストするリペアおよびデータパケットは、受信者に同時に到達する。そこで我々は、一連のラウンドで生じる送信者と一連の受信者との間の通信を思い描くことができる。セクション4では、一連の受信者の間で送信者への往復時間が変わるという仮定で生じる問題を解決する。」
　
ル．「We associate a proactivity factor ρ with a sender-oriented proactive protocol. Here, ρ is a real number larger than or equal to one. For each block of size k, the sender initially transmits [ρk] packets, 1 consisting of the k data packets plus an additional [(ρ−1)k] repair packets. At the end of each round, each receiver requiring additional packets for the block transmits a request for the number of additional repairs it needs in order to receive k packets.」（６頁３７行〜７頁４行）
　
訳文（ル．）「我々はプロアクティビティファクターρを送信者指向プロアクティブプロトコルと関連付ける。ここで、ρは1以上の実数である。各ブロックサイズkのために、送信者は最初に[ρk]パケットを送信する。これはkデータパケットと追加[(ρ−1)k]リペアパケットからなる。各ラウンドの終わりに、ブロックに追加的パケットを必要とする各受信者はkパケットを受信するために必要な追加的リペア数のリクエストを送信する。」
　
ヲ．「Figures 3(a), 3(b), and 3(c) plot simulation results from 10,000 experiments. These figures respectively plot the expected number of rounds (our measure of expected delay for round-based protocols), implosion factor, and forward bandwidth per block for various multicast group-sizes as a function of the sender's proactivity factor. The block size is 10, and the loss probability on each link is .02532 (roughly an end-to-end loss probability of .05). From Figure 3(a), we see that a protocol using a proactivity factor slightly larger than one requires a significantly smaller number of rounds than one that uses a proactivity factor of one. The expected number of rounds quickly converges to one as the proactivity factor is increased. In Figure 3(b), we see that the implosion factor decreases exponentially as a function of the proactivity factor, so that it can be significantly reduced by a small increase in the proactivity factor. The most interesting result is the effect that the proactivity factor has on forward bandwidth as shown in Figure 3(c). For large multicast groups, initially increasing the proactivity factor has an insignificant effect on the expected number of packets transmitted to reliably deliver data to all receivers. This is because, with a large group, a certain number of repairs must be expected. With proactive FEC, these repairs are simply sent before it is known for certain that they are needed. Note that, after some point, an increase in the proactivity causes the sender to transmit more packets than are required by any of the receivers, and the bandwidth begins to increase along the asymptote y=kx, where k is the block size.」（９頁５〜２６行）
　
訳文（ヲ．）「図3（a）、3（b）、3（c）は一万回の実験によるシミュレーション結果をグラフ化したものである。これらの数値はそれぞれ送信者のプロアクティビティファクターの関数としての様々なマルチキャストグループサイズのためのブロックごとの予測ラウンド数（丸めベースのプロトコルのための予測遅延の我々の測定）、インプロージョンファクター、転送帯域幅をグラフ化している。ブロックサイズは10で各リンクの損失確率は0.02532である（ほぼエンドツーエンド損失確率0.05）。図3（a）から、1よりやや大きいプロアクティビティファクターを使ったプロトコルがプロアクティビティファクター1を使用するものよりも有意に小さいラウンド数を必要としているのが分かる。ラウンド予測数は速やかに1に収束する。同時にプロアクティビティファクターは増加する。図3（b）では、インプロージョンファクターが指数関数的にプロアクティビティファクターの関数として減少するのが示される。そのためプロアクティビティファクターが少し上昇しただけでも大幅に減少しうる。最も興味深い結果はプロアクティビティファクターが転送帯域幅に対して持つ効果である。これは図3（c）に示されている。大型マルチキャストグループでは、最初に増加するプロアクティビティファクターが信頼できるデータをすべての受信者に送信する予測パケット数に有意でない効果を持つ。なぜならば、大型グループでは、リペアの一定の数を予測しなければならないからである。プロアクティブFECでは、これらのリペアは必要数を確認する前に単純に送られる。あるポイントの後では、プロアクティビティの増加は送信者に受信者が必用とする以上のパケットを送信させる。帯域幅は漸近線y＝kxに沿って増加し始める。ここでkはブロックサイズである。」
　
ワ．「We observe that when receivers attempt to meet hard deadlines, the sender can reduce the expected number of transmissions of data and repairs per block by increasing the proactivity factor. This is because, in the absence of proactivity, the number of packets requested by a receiver to meet its deadline is significant whenever a second round is required. By sending a few extra packets in the first round, the sender often obviates the need for the second round altogether. This reduction of forward bandwidth due to sender proactivity is less pronounced as the end-to-end loss rate is decreased, as is shown by contrasting the slopes of the curves in Figure 5(b) with those in Figure 5(a). The reduction in forward bandwidth due to the use of receiver-oriented proactivity also becomes less significant as the receiver's deadline increases (i.e., as more rounds of packet transmissions are permitted). As the deadline increases. the expected number of transmissions decreases, converging to the expected number of transmissions when there is no deadline.」（１３頁２８行〜１４頁３行）
　
訳文（ワ．）「受信者が厳しいデッドラインを満たそうとするとき、送信者はプロアクティビティファクターを増すことでブロックあたりのデータおよびリペア送信予測数を減らすことができることが分かる。これはプロアクティビティの不存在下で、パケット数がデッドラインを満たすことを受信者が要求することが、第二ラウンドを必要とする時には意味をなすためである。いくつかの余剰パケットを第一ラウンドで送信することによって、送信者は第二ラウンドの必要性を軽減できることが多い。送信者プロアクティビティによるこの転送帯域幅の削減は、エンドツーエンド損失率が減少すると目立たなくなる。これは図5（b）の曲線を図5（a）と比較することによって判明する。受信者指向プロアクティビティの使用による転送帯域幅の削減は、受信者のデッドラインが増加すると目立たなくなる（パケットのより多くのラウンド送信が許容されることに従う）。デッドラインが増加するに従って送信予測数は減少する。デッドラインがなければ送信予測数に収束する。」
　
カ．「Our protocol operates on a block-by-block basis. Each block is handled sepa-rately by the protocol. The sender chooses a proactivity factor and transmits a proactive set of repairs along with the block of data. Doing so reduces the expected delay of receipt by receivers and also reduces the expected amount of implosion. The proactivity factor can be chosen such that the forward band-width from the sender (including subsequent retransmissions for the block) does not increase. The sender can adapt the proactivity factor to account for network conditions. If the sender is being heavily inundated with feedback, then it should increase the proactivity factor. If the sender is receiving little feedback, then it should reduce the proactivity factor.
　
Receivers solicit repairs from the sender using one of the heterogeneous feed-back mechanisms discussed in Section 4. If receivers require the data before a given deadline, d, then they should develop conservative estimates of the loss rate and their round trip time, and use the techniques presented in Section 3 to meet these deadlines.」（２０頁２０〜３４行）
　
訳文（カ．）「我々のプロトコルはブロック単位を基本に機能する。各ブロックはプロトコルによって別々に扱われる。送信者は、プロアクティビティファクターを選択し、データのブロックと共に一組のプロアクティブなリペアを送信する。そうすることで、受信者側の予想される受信遅延を低減させ、予想されるインプロ―ジョン量も減らすことができる。プロアクティビティファクターは、送信者からの転送帯域幅が増加しないように、選択することができる（ブロックへの後続の再送信を含む）。送信者は、ネットワークの状態を勘定に入れるためにプロアクティビティファクターを適応させることができる。送信者にフィードバックが極めて大量に送られようとしている場合は、プロアクティビティファクターを増やす必要がある。送信者がフィードバックをほとんど受信していない場合は、プロアクティビティファクターを減らすべきである。
　
受信者は、セクション4で議論した異種のフィードバックメカニズムの一つを用いて、送信者からのリペアを要請する。受信者が、定められたデッドライン、d 以前にデータを要する場合、損失率とその往復時間を低目に見積もり、これらのデッドラインに合致するように、セクション3で提示した技法を用いる必要がある。」
　
　上記引用例２の記載及び図面並びにこの分野における技術常識を考慮すると、上記チ．における「リペアが損失を修復するのに必要とされるかどうかが分かる前に、パリティ損失リペアを受信者に送ることの効果を検証する。また多くの事例で、プロアクティブリペアがフィードバックインプロージョンを減らすことができ、バンド幅使用を増すことなく、信頼性のある配信の予測された遅延を減らすことを示す。次に、同調可能性の中でエンドツーエンドデッドラインを満たすために、どのようにプロアクティブリペアが使えるか検討する。」との記載、上記リ．における「インターネットにより様々なタイプのデータの転送が可能になった。特に、リアルタイムデータを信頼性高く受信者に送信するニーズは増している。ここでデータは限られた時間内に受信されねばならない。」との記載によれば、パケットを送信する装置は、インターネットを経由してデッドラインのあるパケットを送信するものである。
　また、上記ヌ．における「受信者セットにデータを配信するのにARQおよびFECの組み合わせを使うプロトコルに注目する。」との記載によれば、パケットの送信の制御は、ＡＲＱ及びＦＥＣを用いるものである。
　また、上記ル．における「我々はプロアクティビティファクターρを送信者指向プロアクティブプロトコルと関連付ける。ここで、ρは1以上の実数である。各ブロックサイズkのために、送信者は最初に[ρk]パケットを送信する。これはkデータパケットと追加[(ρ−1)k]リペアパケットからなる。」との記載、上記ヲ．における「図3（b）では、インプロージョンファクターが指数関数的にプロアクティビティファクターの関数として減少するのが示される。そのためプロアクティビティファクターが少し上昇しただけでも大幅に減少しうる。」との記載、上記ワ．における「受信者が厳しいデッドラインを満たそうとするとき、送信者はプロアクティビティファクターを増すことでブロックあたりのデータおよびリペア送信予測数を減らすことができることが分かる。」との記載によれば、ＡＲＱ及びＦＥＣの制御は、デッドラインを満たすためにインプロージョンファクターを減少させるとともにプロアクティビティファクター（ρ）を増加させることである。ここで、インプロージョンファクターは、NAK回数のことであり、再送回数に比例するものであることは明らかである。
　
　したがって、上記引用例２には、以下の発明（以下、「引用発明２」という。）が記載されているものと認められる。
　
　「インターネットを経由してデッドラインのあるパケットを送信する装置において、再送回数を減少させるとともにプロアクティビティファクターを増加させるようにＡＲＱ及びＦＥＣを制御する技術。」
　
（３）対比・判断 
　補正後の発明と引用発明１とを対比する。 
ａ．引用発明１の「ＩＰネットワーク（２１９）」、「再送パケット」、「ＡＲＱ制御部（２１３）」、「ＦＥＣ(Forward Error Correction)処理部（２０８）」及び「受信側端末（２０２）」は、補正後の発明の「ネットワーク」、「不達パケット」、「パケット自動再送部」、「前方誤り訂正符号化部」及び「パケット受信装置」にそれぞれ相当する。
ｂ．引用発明１の「冗長コード」と、補正後の発明の「冗長パケット」とは、いずれも、「冗長データ」という点で一致する。
ｃ．引用発明１の「往復伝播遅延（ＲＴＴ）が短い場合、前記再送パケットの再送によりエラー訂正を行い、往復伝播遅延（ＲＴＴ）が長い場合、冗長コードの付与によりエラー訂正を行う」と、補正後の発明の「往復伝搬遅延値が第１の遅延値の場合、前記不達パケットの再送により誤り訂正を行い、往復伝搬遅延値が前記第１の遅延値より大きい第２の遅延値の場合、前記不達パケットの再送及び第１の冗長度の冗長パケットの付加により誤り訂正を行い、往復伝搬遅延値が前記第２の遅延値より大きい第３の遅延値の場合、前記第１の冗長度より大きい第２の冗長度の冗長パケットの付加により誤り訂正を行う」とは、いずれも、「往復伝搬遅延値が第１の遅延値の場合、前記不達パケットの再送により誤り訂正を行い、往復伝搬遅延値が特定の遅延値の場合、特定の処理により誤り訂正を行う」という点で一致する。
ｄ．引用発明１の「送信側端末（２０１）」は、パケットを送信するから、「パケット送信装置」である。
　
 　したがって、補正後の発明と引用発明１は、以下の点で一致ないし相違している。 
 　 
（一致点） 
　「ネットワーク経由で、到着期限に制限のあるパケットを送信するパケット送信装置であって、
　前記到着期限までに到着可能とされた不達パケットの再送を制御するパケット自動再送部と、
　データパケットに冗長データを付加する前方誤り訂正符号化部と、
　往復伝搬遅延値が第１の遅延値の場合、前記不達パケットの再送により誤り訂正を行い、往復伝搬遅延値が特定の遅延値の場合、特定の処理により誤り訂正を行うよう前記パケット自動再送部及び前記誤り訂正符号化部を制御する制御部とを有し、
　前記パケット自動再送部は、前記到着期限と前記往復伝搬遅延値に基づいてパケット受信装置が送信する再送要求パケットを受信することで、前記不達パケットの再送を制御する、
　パケット送信装置。」
　
（相違点１）
　「冗長データ」に関し、
　補正後の発明は、「冗長パケット」であるのに対し、引用発明１は、「冗長コード」である点。
　
（相違点２）
　「制御部」について「往復伝搬遅延値が特定の遅延値の場合、特定の処理により誤り訂正を行う」に関し、
　補正後の発明は、「往復伝搬遅延値が前記第１の遅延値より大きい第２の遅延値の場合、前記不達パケットの再送及び第１の冗長度の冗長パケットの付加により誤り訂正を行い、往復伝搬遅延値が前記第２の遅延値より大きい第３の遅延値の場合、前記第１の冗長度より大きい第２の冗長度の冗長パケットの付加により誤り訂正を行う」のに対し、引用発明１は、「往復伝播遅延（ＲＴＴ）が長い場合、冗長コードの付与によりエラー訂正を行う」点。
　
　そこで、上記相違点１及び２について検討する。 
　引用発明１と引用発明２は、ネットワーク経由で到着期限のあるパケットを送信する送信装置において、ＡＲＱ及びＦＥＣを動的に制御しパケットロスを減少させる技術分野・課題において共通し、引用発明１に引用発明２を採用することに特段の阻害要因は見あたらない。そして、引用発明２の「プロアクティビティファクター」は、「冗長度」といえるものであるから、引用発明２は、再送回数を減少させるとともにプロアクティビティファクター（冗長度）を増加させるものである。
　そうすると、引用発明１は、「往復伝播遅延（ＲＴＴ）が短い場合、前記再送パケットの再送によりエラー訂正を行い、往復伝播遅延（ＲＴＴ）が長い場合、冗長コードの付与によりエラー訂正を行う」ところ、往復伝搬遅延（ＲＴＴ）が長い場合、再送回数を減少させることは技術常識であるから、引用発明２に接した当業者であるならば、往復伝搬遅延（ＲＴＴ）に応じて、再送回数及び冗長度の各割合を段階的に変更して、再送回数を減少させるとともに冗長度を漸次増加させることは自然に導き出せることである。
　したがって、補正後の発明のように「往復伝搬遅延値が前記第１の遅延値より大きい第２の遅延値の場合、前記不達パケットの再送及び第１の冗長度の冗長パケットの付加により誤り訂正を行い、往復伝搬遅延値が前記第２の遅延値より大きい第３の遅延値の場合、前記第１の冗長度より大きい第２の冗長度の冗長パケットの付加により誤り訂正を行う」こと（相違点２）は格別に困難なことではない。
　加えて、上記引用例２の上記ル．における「プロアクティビティファクターρを送信者指向プロアクティブプロトコルと関連付ける。ここで、ρは1以上の実数である。各ブロックサイズkのために、送信者は最初に[ρk]パケットを送信する。これはkデータパケットと追加[(ρ−1)k]リペアパケットからなる。」との記載によれば、リペアパケットは、「冗長パケット」と呼べるものであるから、補正後の発明のように「冗長パケット」と称することができること（相違点１）は当然である。
　
　そして、補正後の発明の作用効果も、引用発明１及び２から当業者が容易に予測できる範囲のものである。 
 　 
　以上のとおり、補正後の発明は引用発明１及び２に基づいて容易に発明できたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。 
 　 
４．結語 
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。  
 　 
第３　本願発明について 
１．本願発明 
　平成２４年１２月２８日付けの手続補正は上記のとおり却下されたので、本願発明は、上記「第２　補正却下の決定　１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。 
　 
２．引用発明 
　引用発明は、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。 
 　 
３．対比・判断 
　本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。 
　そうすると、本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明１及び２に基づいて容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。 
　 
４．むすび 
　以上のとおり、本願発明は、引用発明１及び２に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　 
　よって、結論のとおり審決する。