【事件の表示】
　特願２０１２−５５１１３５「再送決定する方法及び装置」拒絶査定不服審判事件〔平成２３年　８月　４日国際公開、ＷＯ２０１１／０９３８３６、平成２５年　５月２０日国内公表、特表２０１３−５１８５１１、請求項の数（２）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１０年１月２８日（外国庁受理）を国際出願日とする出願であって、平成２６年７月１８日付けで最後の拒絶理由が通知され、平成２７年１月２７日付けで手続補正がされたが、同年４月３０日付けで補正の却下の決定がなされるとともに、同日付けで拒絶査定（以下、「原査定」という。）がされ、これに対し、同年９月１１日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がされ、その後、当審において平成２８年５月３０日付けで拒絶理由（以下、「当審拒絶理由」という。）が通知され、同年８月３０日付けで手続補正がされたものである。
第２　本願発明
　本願の請求項１、２に係る発明は、平成２８年８月３０日付けの手続補正で補正された特許請求の範囲の請求項１、２に記載された事項により特定されるものと認められる。
　本願の請求項１に係る発明（以下、「本願発明」という。）は以下のとおりである。
「【請求項１】
　送信装置が、デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む、ステップと、
　前記送信装置が、前記ＮＡＬ拡張ヘッダを解析して、前記第１及び第２のビデオデータを特定するステップと、
　前記送信装置が、前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てるステップと、
　前記送信装置が、前記第１及び第２のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップと、
　前記送信装置が、デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、ステップと、
　前記送信装置が、デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集するステップであって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップと、
　前記送信装置が、前記受信装置から前記第２のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第２のネットワークデータを含み、前記第２のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第２のネットワーク伝送状態を示し、前記第２のネットワーク伝送状態は第２のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第２の利用可能帯域幅と、第２のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップと、
　前記送信装置が、前記第１のネットワークデータを前記第２のネットワークデータで補足するステップと、
　前記送信装置が、前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定するステップとを含む、方法。」　
第３　原査定の理由について
１．原審の拒絶理由の概要
「１．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。
２．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
刊行物１：特開平９−１９１３１４号公報
理由１について
請求項：１，２
刊行物：１
　刊行物１には、トランスミッタがレシーバから再送要求を受信し、ネットワークトランスポート統計（Ｔｒ２）と優先度情報に基づき、再送信するか否かを決定することが記載されており（特に、段落３６−４２）、刊行物１に係る発明と当該請求項に係る発明とは、構成上の差異がない。
理由２について
請求項：１，２
刊行物：１
　上記に加え、当該請求項に係る発明は、上記理由１で述べた理由と同様の理由により、当業者であれば、刊行物１に記載された発明に基づいて、容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。」
２．原査定の理由の判断
（１）刊行物の記載事項
　原査定の拒絶の理由に引用された特開平９−１９１３１４号公報（刊行物１）には、図面とともに以下の事項が記載されている。
イ．「【０００１】
【発明の属する技術分野】この発明は動画や音声等の連続データを伝送し、受信側でデータ生成時間と同じ時間で再生する連続データ伝送方法および連続データ伝送装置に関するものである。データを伝送し、データ生成時間と同じ時間で再生することは、例えば１０分の映像を１０分で表示することです。伝送にかかる遅延時間の問題ではありません。」（３頁左欄）
ロ．「【００３６】実施の形態５．この実施の形態は、実施の形態１〜４においてパケット再送判定機能を受信機側でなく送信機側に持たせた場合の例である。本実施の形態の構成図を図１０に示す。図１１は受信機４０の動作フロー、図１２は送信機３９のパケット再送動作フロー図である。送信機３９の再送以外の動作フローは図２と同一なので省略する。図１で示される実施の形態１との違いは、まず受信機４０側において受信パケットのシステムクロックを用いたタイムスタンプ比較とそれに基づく再送判定を行う機能を削除している。従って受信側で誤りを検出したパケットは即座に再送要求メッセージを作成し送信機３９に対して返送するものとする（図１１のステップ６３、７７、６７）。
【００３７】一方送信側は再送要求メッセージパケットを受信すると、まずパケット解析部３２においてどのパケットの再送が要求されているかの解析を行う（図１２のステップ７９）。次に再送要求されたパケット内の受信制限時刻に関するタイムスタンプ情報ＴＳと送信機内のシステムクロックＳＣとを比較し、その差分結果ＴＳ−ＳＣをやはり送信機内にある再送判定部３７に通知する。再送判定部３７ではこの差分時間情報ＴＳ−ＳＣと、ここから再送を行って受信側に届くまでの片道の推定時間Ｔｒ２とを比較し、再送を行うか否かの判定を行う。ＴＳ−ＳＣ＞Ｔｒ２なら再送しても受信制限時刻に間に合うので再送を行う（図１２のステップ８１、８２）。そうでない場合は、そのパケットは廃棄する（ステップ８３）。
【００３８】このとき、再送にかかると推定される時間Ｔｒ２は実施の形態３と同様、再送要求が返ってきた場合のタイムスタンプ情報から動的に変化させてももちろんよい。また再送判定基準としては、再送を行う時の現在時刻にＴｒ２を加えた値が、はじめのパケットが作成された時の時刻に伝送遅延許容時間を加えた時刻に対して１／３０秒以上の遅れとなるかどうかで判定を下せばよい。
【００３９】このように再送判定部を送信側に持たせることによって、受信機側に送信機側に何らかの形で同期させたシステムクロックと再送判定プロセスの実行を省くことができるので、複数の送信元からの送信を同時に処理しなければならないようなシステムにおいては特に、受信機側の負荷を軽くすることができる利点がある。」（７頁右欄〜８頁左欄）
　上記刊行物１の記載及び図面並びにこの分野における技術常識を考慮すると、上記イ．の【０００１】における「この発明は動画や音声等の連続データを伝送し、受信側でデータ生成時間と同じ時間で再生する連続データ伝送方法・・・に関するものである。」との記載によれば、刊行物１の連続データ伝送方法は、動画を伝送するものである。
　また、上記ロ．の【００３７】のおける「一方送信側は再送要求メッセージパケットを受信すると、まずパケット解析部３２においてどのパケットの再送が要求されているかの解析を行う（図１２のステップ７９）。次に再送要求されたパケット内の受信制限時刻に関するタイムスタンプ情報ＴＳと送信機内のシステムクロックＳＣとを比較し、その差分結果ＴＳ−ＳＣをやはり送信機内にある再送判定部３７に通知する。再送判定部３７ではこの差分時間情報ＴＳ−ＳＣと、ここから再送を行って受信側に届くまでの片道の推定時間Ｔｒ２とを比較し、再送を行うか否かの判定を行う。ＴＳ−ＳＣ＞Ｔｒ２なら再送しても受信制限時刻に間に合うので再送を行う（図１２のステップ８１、８２）。」との記載、及び図１２によれば、刊行物１の連続データ伝送方法は、送信側が、受信側から再送要求メッセージパケットを受信し、差分時間情報ＴＳ−ＳＣと片道の推定時間Ｔｒ２を比較し、再送を行うか否かの判定を行っている。
　したがって、上記刊行物１には、以下の発明（以下、「引用発明１」という。）が記載されているものと認められる。
　「送信側が、受信側から再送要求メッセージパケットを受信し、差分時間情報ＴＳ−ＳＣと片道の推定時間Ｔｒ２を比較し、動画の再送を行うか否かの判定を行う連続データ伝送方法。」
（２）対比
　本願発明と引用発明１とを対比する。 
ａ．引用発明１の「送信側」は、送信側の装置であるから、「送信装置」ということができる。
ｂ．引用発明１の「受信側から再送要求メッセージパケットを受信し、差分時間情報ＴＳ−ＳＣと片道の推定時間Ｔｒ２を比較し、動画の再送を行うか否かの判定を行う」と、本願発明の「前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」とは、後述する相違点を除いて、「ネットワーク状況を考慮して、再送を行うか否か決定する」という点で一致する。
　したがって、本願発明と引用発明１は、以下の点で一致ないし相違している。 
＜一致点＞
　「送信装置が、ネットワーク状況を考慮して、再送を行うか否か決定するステップ
を、含む方法。」
＜相違点１＞
　本願発明の「送信装置」は、「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む、ステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点２＞
　本願発明の「送信装置」は、「前記ＮＡＬ拡張ヘッダを解析して、前記第１及び第２のビデオデータを特定するステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点３＞
　本願発明の「送信装置」は、「前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てる」のに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点４＞
　本願発明の「送信装置」は、「前記第１及び第２のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点５＞
　本願発明の「送信装置」は、「デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、ステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点６＞
　本願発明の「送信装置」は、「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集するステップであって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点７＞
　本願発明の「送信装置」は、「前記受信装置から前記第２のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第２のネットワークデータを含み、前記第２のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第２のネットワーク伝送状態を示し、前記第２のネットワーク伝送状態は第２のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第２の利用可能帯域幅と、第２のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点。
＜相違点８＞
　本願発明の「送信装置」は、「前記第１のネットワークデータを前記第２のネットワークデータで補足するステップ」を含むのに対し、引用発明１の「送信側」は、当該ステップを含まない点
＜相違点９＞
　一致点の「ネットワーク状況を考慮して、再送を行うか否か決定する」に関し、
　本願発明の「送信装置」は、「前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」のに対し、引用発明１の「送信側」は、「受信側から再送要求メッセージパケットを受信し、差分時間情報ＴＳ−ＳＣと片道の推定時間Ｔｒ２を比較し、動画の再送を行うか否かの判定を行う」点。
（３）判断
　そこで、まず、上記相違点５について検討する。
　引用発明１の「送信側」は、「受信側から再送要求メッセージパケットを受信し、差分時間情報ＴＳ−ＳＣと片道の推定時間Ｔｒ２を比較し、動画の再送を行うか否かの判定を行う」にすぎず、そもそも、本願発明の前提である相違点５に係る「デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、ステップ」を備えていない。したがって、引用発明１から本願発明を導き出すことはできない。
　よって、本願発明は、上記相違点１〜４、６〜９について検討するまでもなく、本願発明は、刊行物１に記載された発明とはいえない。また、引用発明１に基づいて、当業者が容易に発明をすることができたとはいえない。
（４）小括
　したがって、本願発明は、本願発明は、刊行物１に記載された発明とはいえない。また、刊行物１に基いて、当業者が容易に発明をすることができたとはいえない。
　請求項２は、請求項１に係る発明のカテゴリーを「装置」とした発明であるから、上記（３）と同じ理由により、刊行物１に記載された発明とはいえない。また、引用発明１に基づいて当業者が容易に発明をすることができたとはいえない。
　よって、原査定の理由によっては、本願を拒絶することはできない。
第４　当審拒絶理由について
１．当審拒絶理由の概要
「Ａ．この出願の請求項１，２に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから，特許法第２９条第１項第３号に該当し，特許を受けることができない。 
Ｂ．この出願の請求項１，２に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
刊行物Ａ：特開２００８−３１２１２６号公報 
請求項１，２に係る発明に対して：　上記刊行物Ａ 
　上記刊行物Ａには，受信装置から受信した再送要求の情報に基づいて送信装置が算出したパケットロス率と，パケット毎の重要度とから，再送要求されたパケットの再送の可否を決定するようにした送信装置及び送信方法が記載されている（特に図７のパケット再送制御に関する処理の流れ及び関連する記載参照）。 
　そして，上記「パケットロス率」の具体的な生成方法について，段落【００５０】に「パケット再送制御部１０７はパケットロス率算出手段として機能し，通知されたシーケンスナンバー３０１と，ロストしたパケットの個数とから，ある単位時間当たりのパケットロス率を計算する。パケットロス率は，再送要求パケットを受信した時刻からある一定時間前までの間（所定時間）に送信した総パケット数と，それに対するロストしたパケット数との割合から計算する。」と記載されているように，「受信装置から受信した複数の再送要求パケットでそれぞれ通知されるシーケンスナンバーに基づき，送信装置でパケットロス率を計算・生成」しているものと認められる。 
　このとき，「受信装置から受信した複数の再送要求パケットでそれぞれ通知されるシーケンスナンバー」は，「受信装置から収集した統計」といい得るものであり，また，この「受信装置から収集した統計」に基づき「送信装置でパケットロス率を計算・生成」することは，「送信装置がデジタルデータネットワークをモニタしてネットワークトランスポート統計を収集」することといい得るものである。 
　そうすると，本願請求項１，２に係る発明と上記刊行物Ａに記載された発明との間に格別の差異は見当たらない。」
２．当審拒絶理由の判断
（１）刊行物の記載事項
　当審の拒絶の理由に引用された特開２００８−３１２１２６号公報（刊行物Ａ）には、図面とともに以下の事項が記載されている。
イ．「【技術分野】
【０００１】
　発明はデータ送信装置、データ受信装置、データ送受信システム、データ送信装置の制御方法、データ受信装置の制御方法、プログラム及び記録媒体に関し、特に、回線状況やパケットの重要度に応じて再送の動作を制御するために用いて好適な技術に関する。」（４頁）
ロ．「【発明が解決しようとする課題】
【０００７】
　しかしながら、前記特許文献１に記載の技術では、受信側は、パケットロスの検知だけではなく、パケットロスが発生した場合にロストしたパケットの重要度を判別して再送要求を行なうか否かの判断を行なう必要があった。このため、受信側の処理負荷が大きくなってしまうという問題点があった。
【０００８】
　さらに、ロストしたパケットの重要度を受信側で判別するための仕組みを各パケットに送信側で組み入れる必要があり、その分だけトラフィックが増大してしまう。このため、効率の良い通信を行なう点においては不十分であった。
【０００９】
　また、前記特許文献１に記載の技術では、重要度のレベルが高・低の２段階であり、処理の細かい再送制御を行なうことができなかった。このため、再送制御という点に着目した場合においても、効率の良い通信を行なう点においては不十分であった。
【００１０】
　本発明は前述の問題点に鑑み、パケットロスが発生した場合に、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうことができるようにすることを目的としている。」（５頁）
ハ．「【００２０】
（第１の実施形態）
　本発明の実施形態として、動画像データから通信用のパケットを生成し、受信装置に送信するシステムについて図面を参照しながら説明する。
　図１は、本実施形態におけるデータ送受信システムの構成例を示すブロック図である。このシステムは、動画像データを送信する送信装置１００と動画像データを受信する受信装置１０１とで構成され、動画像データは通信に適したサイズに分割され、通信パケットとして送受信が行なわれる。
【００２１】
　図１に示す送信装置１００においては、動画像データ生成部１０２は、概念的な機能面からは、動画像データを生成し、パケット生成部１０３は、生成した動画像データを通信に適したサイズに分割し、通信用のプロトコルに準じたパケットを生成する。また、パケット生成部１０３はパケット保管手段として機能し、第２の記憶部である送信バッファ１１２に生成したパケットを一時保管する。
【００２２】
　パケット重要度設定部１０４は、生成したパケット毎に重要度のレベル分けを行なう。また、パケット重要度設定部１０４はパケット重要度記憶手段として機能し、パケット毎の重要度情報を第１の記憶部である重要度情報バッファ１１３に一時保管する。接続制御部１０５は、受信装置１０１との接続状態を制御し、パケット通信部１０６は、生成したパケットを受信装置１０１に送信する。また、パケット再送制御部１０７は、パケット通信部１０６を介して受信装置１０１から送られるパケットの再送要求情報からパケットのロス率を計算する。そして、パケットの再送を行なうか否かを判断し、計算したパケットロス率のデータをロス率バッファ１１４に一時保管する。
【００２３】
　一方、受信装置１０１においては、接続制御部１０８は、送信装置１００との接続状態を制御し、パケット通信部１０９は、送信装置１００から送信されるパケットを受信する。そして、パケットロス検知部１１１は、受信したパケットから通信経路途中で損失したパケットを検出し、パケット再送要求部１１０は、損失したパケットの再送をパケット通信部１０９を介して送信装置１００に要求する。なお、受信装置１０１は１つの送信装置１００に対して、複数接続していてもよい。
【００２４】
　次に、図１を参照しながら、本実施形態のシステムの一般的な処理の流れについて説明する。まず、受信装置１０１を操作する利用者の操作により、送信装置１００から動画像データを取得するように要求する。この操作は、例えばＧＵＩ（グラフィカル・ユーザ・インターフェース）を用いて送信装置１００のＵＲＬ（Uniform Resource Locator）を入力する操作であってもよい。また、受信装置１０１に予め通信接続の定義しておいた情報を用いて、スイッチを押下するような操作であってもよい。
【００２５】
　動画像データ取得の指示においては、送信装置１００に接続するためのメッセージをパケット通信部１０９から送信するように接続制御部１０８が制御する。そして、パケット通信部１０９は、送信装置１００のパケット通信部１０６に対して、接続を要求するメッセージを通知する。
【００２６】
　送信装置１００では、受信装置１０１から送信された接続を要求するメッセージをパケット通信部１０６にて受信し、接続制御部１０５は、接続の可否を判断する。そして、その判断の結果を示すメッセージを受信装置１０１に返す。この接続制御のための通信において最も一般的な方法のひとつは、ＲＴＳＰ（Real Time Streaming Protocol、RFC 2326、The Internet Society）によるものである。図１では簡略化のため、接続制御のメッセージを単純化した矢印にて記載しているが、例えばＲＴＳＰにおいては、複数回のメッセージ交換により行われる。
【００２７】
　送信装置１００においては、次に、動画像データ生成部１０２において動画像データの生成を行ない、生成された動画像データを、所定のバッファに一時的に保管する。そして、所定のバッファに保管された動画像データは、パケット生成部１０３にて通信に適したサイズに分割され、動画像データを含んだ送信用パケットが生成される。この生成された送信用パケットは、受信装置１０１から再送要求があった時に備え、送信バッファ１１２において、一定時間分保管される。
【００２８】
　一方、パケット重要度設定部１０４では、送信用パケットを生成する際に、動画像データ生成部１０２から動画像のフレーム毎にフレームの種類を取得し、取得したフレームの種類、及びそのフレームの並び順からフレーム毎に重要度を設定する。この重要度設定の方法および処理内容については、後で詳細に説明する。
【００２９】
　そして、生成された送信用パケットは、パケット通信部１０６から受信装置１０１のパケット通信部１０９へ順次送信される。
【００３０】
　次に、受信装置１０１では、パケット通信部１０９で受信したパケットから、通信系路上で失われたパケットの検出を行なう。この検出処理は、パケットロス検出手段として機能するパケットロス検知部１１１において行なわれる。そして、パケットの損失（ロス）があった場合には、パケット再送要求部１１０において、パケットロスが検出されたパケットの再送を要求するメッセージ（以下、再送要求メッセージと称す）を生成する。そして、送信装置１００の再送要求受信手段として機能するパケット通信部１０６に対して、パケット通信部１０９から再送要求メッセージを通知する。
【００３１】
　通信経路上で損失したパケットの再送要求メッセージが受信装置１０１から送信装置１００に通知された場合、送信装置１００では、パケット通信部１０６からパケット再送制御部１０７へ再送要求メッセージが渡される。そして、再送要求メッセージに対して、再送するパケットの選別及び再送の可否が判定される。
【００３２】
　この時、パケット再送制御部１０７では、パケットの再送要求メッセージから算出するパケット損失の割合、パケット重要度設定部１０４で設定したパケット毎の重要度情報などから、実際に受信装置１０１へ再送するパケットを決定する。この決定に応じて、パケット通信部１０６はパケット再送手段として機能し、パケットの再送に備えて送信バッファ１１２にて保管していたパケットを読み出して受信装置１０１へ送信する。受信装置１０１のパケット通信部１０９はパケット通信手段として機能し、送信装置１００から送信された再送パケットを受信する。なお、送信バッファ１１２、重要度情報バッファ１１３、及びロス率バッファ１１４は、同一の記憶装置であってもよい。
【００３３】
　次に、図２を参照しながら前述したパケット重要度設定部１０４で行なわれるフレーム毎の重要度設定の方法及び処理内容について説明する。動画像データを分割してパケット化して送受信を行なう場合、動画像データは一般に圧縮符号化処理が行なわれる。その代表的な方式として、ＭＰＥＧ−２（ISO/IEC 13818）やＭＰＥＧ−４（ISO/IEC 14496）などのＭＰＥＧ方式があげられる。本実施形態では、動画像データ生成部１０２において、これらの圧縮符号化方式を用いて動画像データを符号化するものとする。そこで、まず動画像データを構成する各画像（フレーム）を圧縮する方式として存在する主な３種類の圧縮方式について説明する。
【００３４】
　１つ目は、１つのフレーム内の情報のみでマクロブロック処理などを行ない圧縮符号化処理する方式であり、この方式で圧縮されたフレームはI-Frame (Intra-coded Frame)と呼ばれる。
【００３５】
　２つ目は、時間軸上前方のフレームを参照しながら、動き補償予測、マクロブロック処理など差分情報を抽出して行なう方式であり、前方のフレームに依存した圧縮方式である。この方式で圧縮されたフレームをP-Frame (Predicted Frame)と呼ぶ。
【００３６】
　３つ目は、P-Frameと同様に時間軸上隣り合ったフレームを参照しながら圧縮符号化を行なう方式である。ところが、P-Frameが前方のフレームのみを参照していたのに対し、時間軸上、当該フレームの前後のフレームを参照しながら動き補償予測、マクロブロック処理などを行なう。この方式で圧縮されたフレームをB-Frame (Bi-directional Predicted Frame)と呼ぶ。なお、前述した画像のフレーム(Frame)はピクチャ(Picture)とも呼ばれるが、本実施形態ではフレーム(Frame)と呼ぶこととする。
【００３７】
　図２に示す「Ｉ」、「Ｐ」、「Ｂ」は、各々I-Frame、P-Frame、B-Frameを表しており、「Ｐ」、及び「Ｂ」の添え字の数字は、同じ符号化形式のフレームを識別するために付されている。また、いくつかの符号化済みのフレームの集合はＧＯＰ(Group of Pictures)、或いはＧＯＶ(Group of Video Object Plane)と呼ばれている。通常、符号化済みの動画像データはＧＯＰ或いはＧＯＶの組み合わせのフレームが連続している。以下、符号化済みのフレームの集合をＧＯＰと呼称する。
【００３８】
　図２は、代表的な２つのタイプのＧＯＰにおける重要度の設定方法を示す図である。図２（ａ）に示すタイプのＧＯＰでは、先頭のI-Frameから始まって、以降のP-Frameは常に前方フレームのみを参照している。このため、パケットロスなどで情報の欠落があった場合、情報の欠落があるフレームが前方のフレームであるほど画像への影響が大きい。そこで本実施形態では、パケットの損失などによるエラーの伝播の影響度の高いものほど重要度が高いものとして設定する。したがって、図２（ａ）に示すタイプのＧＯＰでは、先頭のI-Frameが最も重要度が高く、以降のP-Frameでは送信順に重要度が低下する。また、図２に示す重要度は、数値が小さいほど重要度が高いことを示しており、「１」が最も重要度が高い数値である。
【００３９】
　一方、図２（ｂ）に示すタイプのＧＯＰでは、B-Frameが含まれているため、図２（ｂ）に示すように送信順（＝デコード順）とディスプレイ装置で表示される表示順とが異なる。この場合、デコード時のフレーム間の参照関係に着目すると、I-Frameはそのフレーム以降の最初の参照元フレームを生成するデータとなるので図２（ａ）に示すタイプと同様に最も重要度が高い。
【００４０】
　ところがB-Frameは、前後のフレームを参照してデコードするが、そのように生成したフレームは、さらにそのフレームを参照してデコードに利用されることはない。つまり、パケットの損失などによるエラーの伝播の影響はそのフレームに限定されるため、B-Frameの重要度は最も低い。また、エラーの伝播の影響のみを考慮した場合も、B-Frame同士では、全て同じレベルの重要度となる。
【００４１】
　また、P-FrameはI-FrameとB-Frameの中間の重要度となり、P-Frame間の重要度に関しては、図２（ａ）に示すタイプと同様に時間軸上前方に位置するフレームの方が重要度が高い。よって、図２（ｂ）に示すようにデコード順が「Ｉ・Ｐ・Ｂ・Ｂ・Ｐ・Ｂ・Ｂ」という並びのＧＯＰのフレーム毎の重要度は、「１・２・４・４・３・４・４（数字が小さいほど重要度が高い）」という順番になる。
【００４２】
　パケット重要度設定部１０４では、前述したようにフレーム単位で重要度を決定し、そのフレームのデータを格納したパケットを生成する毎に当該パケットの重要度を設定する。このパケット毎の重要度情報は、少なくとも送信バッファ１１２で再送用に一時保管されているパケットが廃棄されるまでは、重要度情報バッファ１１３に保持される。なお、図２においては、Ｉ，Ｐ，Ｂ各フレームを含むＧＯＰの典型的なフレーム構成を示したものであるため、その他の構成のＧＯＰも勿論存在する。
【００４３】
　以上のように、本実施形態における各フレームの重要度の設定方法においては、いかなる構成のＧＯＰであっても、パケットロスなどによって各フレームのデータが欠落した場合に、エラーの伝播の影響が及ぶフレームの数が多いほど、重要度を高く設定する。
【００４４】
　次に、各フレームから構成された動画像データを通信に適したサイズに分割してパケット化する方法について説明する。本実施形態では、データ通信の手段として、ＲＴＰを用いる場合のパケット生成について説明する。
【００４５】
　図３は、ＲＴＰパケットの構成を模式化した簡略図である。ＲＴＰパケットは、ＲＴＰヘッダ３００とペイロードデータ部３０３とで構成されている。動画像データ生成部１０２で生成された動画像データは、パケット生成部１０３にて通信に適したサイズに分割されるが、この時、分割された動画像データはペイロードデータとして、ペイロードデータ部３０３に格納される。
【００４６】
　動画像データを構成する各フレームのデータは、通信に適した任意のサイズで分割してパケット化することが可能であるため、受信側で復号化する際に、元のフレームのデータを再現する必要がある。その情報を与えるものとして、ＲＴＰヘッダ３００には、データの順序を表す付加情報として、シーケンスナンバー３０１が付与されている。また、ＲＴＰヘッダ３００には、各フレームのデータを復号したものを表示する時間を示す、タイムスタンプ３０２なども付与されている。これら情報以外にも、各フレームを構成するＲＴＰパケットの終わりを示す情報やＲＴＰパケット仕様のバージョン情報など様々な情報が含まれているが、図３では、簡略化のために記載していない。
【００４７】
　次に、受信装置１０１のパケットロス検知部１１１によるパケットロス検出の方法について説明する。前述したように、送信装置１００から送信されるパケットは、図３に示すような構成を持つＲＴＰパケットであり、ＲＴＰヘッダ３００にあるシーケンスナンバー３０１は、パケットを生成する毎に１ずつ増加する自然数で表される。したがって、受信したＲＴＰパケットのシーケンスナンバー３０１に番号の抜けがあった場合は、送信側から受信側へ到達しなかったパケット、即ちパケットの損失（パケットロス）があったことが分かる。
【００４８】
　パケットロス検知部１１１では、このようにＲＴＰパケットのシーケンスナンバー３０１を監視することによってパケットロスの発生を検知する。なお、通信経路上において、パケットの送信順番が入れ替わることがある。そこで、パケットロス検知部１１１では、フレームのデータの復号化などの処理や、後述するパケットの再送処理に支障を来たさない範囲で、ある閾値でパケットの順番の入れ替わりを容認して、損失したパケットの検出を行なう。なお、このパケットの到達する順番の入れ替わりを容認してパケットロスを検出する方法については、本実施形態に関する技術においては重要ではないので、説明を割愛する。
【００４９】
　次に、パケットロスがあった場合の再送要求の方法について説明する。パケット再送要求部１１０ではパケットロス検知部１１１において検知された損失したパケットのシーケンスナンバー３０１を送信装置１００に通知するための再送要求パケットを生成する。生成された再送要求パケットは、パケット通信部１０９から送信装置１００へ送信される。そして、パケット通信部１０６で受信された再送要求パケットの情報は、パケット再送制御部１０７に渡され、再送可否の判定が行なわれる。本実施形態では、受信装置１０１がパケットロスを検知する毎に再送要求パケットが生成され、随時、送信装置１００へ再送要求が行なわれる。
【００５０】
　次に、パケット再送制御部１０７によるパケット再送可否の判定の方法について説明する。前述したように再送要求パケットが受信されると、通信経路上で損失したパケットのシーケンスナンバー３０１が、再送要求の情報としてパケット再送制御部１０７へ通知される。パケット再送制御部１０７はパケットロス率算出手段として機能し、通知されたシーケンスナンバー３０１と、ロストしたパケットの個数とから、ある単位時間当たりのパケットロス率を計算する。パケットロス率は、再送要求パケットを受信した時刻からある一定時間前までの間（所定時間）に送信した総パケット数と、それに対するロストしたパケット数との割合から計算する。
【００５１】
　図４は、計算により求めたパケットロス率に対する、パケットを再送する割合を示したものである。ここで、パケットロス率を計算する際には、図５に示すように、時間的に比較的短い時間レンジでのパケットロス率５０１と長い時間レンジでのパケットロス率５０２との２種類の数値を計算する。
【００５２】
　図４に示すように、短い時間レンジでのパケットロス率５０１が図４に示す閾値ＴｈＬｏ４０１以下であった場合は、送信装置１００は、再送要求された全てのパケットの再送に応じる。また、逆に閾値ＴｈＨｉ４０２以上であった場合は、再送要求には応じない。さらに、閾値ＴｈＬｏ４０１と閾値ＴｈＨｉ４０２との間であった場合は、パケット再送率とパケット毎の重要度とに応じて再送要求するパケットを選別する。
【００５３】
　図６は、短い時間レンジでのパケットロス率５０１が閾値ＴｈＬｏ４０１から閾値ＴｈＨｉ４０２までの間にある場合において、再送するパケットの重要度レベルを示す図である。図６に示す重要度（再送重要度レベル）は、数値が小さいほど重要度が高いことを意味している。例えば、パケットロス率が１０〜１５％のレンジに含まれている場合は、重要度が「１」から「２」までのパケットを再送し、「３」以上の数値の重要度が設定されているパケットに関しては、再送要求を受けても再送には応じないようにしている。
【００５４】
　なお、図６に示すパケットロス率のレンジや再送重要度レベルの設定値は１つの例であり、本実施形態におけるパケット再送制御の絶対的な値を意味するものではない。さらに、閾値ＴｈＬｏ４０１及び閾値ＴｈＨｉ４０２は、時間的に長い時間レンジでのパケットロス率５０２の値によって、その値を動的に変更するようにしてもよい。例えば、長い時間レンジでのパケットロス率５０２が比較的低い場合は、閾値を右側にシフトし、逆に長い時間レンジでのパケットロス率５０２が比較的高い場合は、閾値を左側にシフトするようにしてもよい。
【００５５】
　これによって、短い時間レンジでのパケットロス率５０１が同じでも、長い時間レンジでのパケットロス率５０２が低い場合は、再送に応じるパケットの数が増える。また、逆に短い時間レンジでのパケットロス率５０１が同じで長い時間レンジでのパケットロス率５０２が高いと、再送に応じるパケットの数が減る。このような方法によって、通信経路の輻輳状態をも考慮したパケットの再送制御が可能となる。
【００５６】
　以上、本実施形態について図１に示すシステム構成図を中心に詳細に説明してきたが、より明確に説明するために、パケットの再送制御に関する処理の流れを図７に示すフローチャートを参照しながら再度説明する。図７は、本実施形態におけるパケットの再送制御に関する部分の処理手順の一例を示すフローチャートである。
【００５７】
　動画像データの送受信処理が開始されると、送信装置１００において動画像データ生成部１０２により動画像データを生成する（ステップＳ７０１）。次に、パケット重要度設定部１０４は、生成したフレームの種別やＧＯＰ構成から推測される、参照フレーム階層に起因するエラー伝播の影響度などからフレーム単位に重要度を決定し、フレームに分割したパケット毎に重要度設定を行なう。そして、このパケット毎に設定した重要度情報を重要度情報バッファ１１３に一時保管する（ステップＳ７０２）。次に、パケット生成部１０３によりパケットを生成し、パケット通信部１０６により受信装置１０１に送信する（ステップＳ７０３）。
【００５８】
　次に、受信装置１０１においてパケット通信部１０９によりパケットを受信する（ステップＳ７０４）。そして、パケットロス検知部１１１によりパケットロスの検出を行なう（ステップＳ７０５）。次に、ステップＳ７０５の検出処理によりロストしたパケットが有るか否かを判定する（ステップＳ７０６）。
【００５９】
　この判定の結果、ロストしたパケットが有る場合は、パケット再送要求部１１０によりロストしたパケットの再送を要求するパケットを生成する（ステップＳ７０７）。そして、パケット通信部１０９により送信装置１００に再送を要求するパケットを送信する（ステップＳ７０８）。一方、ステップＳ７０６の判定の結果、ロストしたパケットがない場合は、再送要求を行なう必要がないため、そのまま処理を終了する。
【００６０】
　次に、送信装置１００においてパケット通信部１０６は、再送を要求するパケットを受信する（ステップＳ７０９）。そして、パケット再送制御部１０７によりパケットロス率を算出し、算出したパケットロス率のデータをロス率バッファ１１４に一時保管する（ステップＳ７１０）。ここで算出されるパケットロス率は、例えば、数秒から数十秒単位の短い時間レンジでのパケットロス率５０１と、例えば、１分から数分単位の長い時間レンジでのパケットロス率５０２との２種類のパケットロス率である。
【００６１】
　次に、再送要求されたパケットのシーケンスナンバー３０１に対応する重要度情報を重要度情報バッファ１１３から取得し、前述の２種類のパケットロス率の情報をロス率バッファ１１４から取得する。そして、パケット再送制御部１０７は再送パケット決定手段として機能し、これらの取得した情報から再送するパケットを決定する（ステップＳ７１１）。そして、パケット再送制御部１０７により決定した再送するパケットをパケット通信部１０６が送信バッファ１１２から取得して、受信装置１０１に送信する（ステップＳ７１２）。そして、処理を終了する。
【００６２】
　以上のような処理の流れにより、受信装置１０１側では、送信装置１００から送信されてくるパケットの損失を検出し、再送要求を送信装置側に随時送るだけでよい。一方、送信装置１００側においては、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置１０１側に再送処理を行なう。
【００６３】
　以上のように本実施形態によれば、受信装置１０１から送られた再送要求から、パケット再送制御部１０７がパケットロス率を算出する。そして、前記算出したパケットロス率とパケット重要度設定部１０４が設定したパケット毎の重要度とから受信装置１０１に再送する再送パケットを決定するようにした。これにより、受信装置１０１は、パケットロスが発生した場合に、損失したパケットの重要度を判別して再送要求を行なうか否かを判断することを不要にすることができる。さらに、ロストしたパケットの重要度を受信装置１０１で判別するための仕組みを各パケットに組み入れることによるトラフィックの増大を防止することができる。したがって、受信側の処理負荷が大きくならないようにするとともに、効率の良い通信を行なうことができる。」（７〜１３頁）
　上記刊行物Ａの記載及び図面並びにこの分野における技術常識を考慮すると、上記イ．の【０００１】における「発明はデータ送信装置、データ受信装置、データ送受信システム、データ送信装置の制御方法・・・に関し」との記載、上記ハ．の【００５７】における「送信装置１００において動画像データ生成部１０２により動画像データを生成する（ステップＳ７０１）。」との記載、及び図７によれば、刊行物Ａのデータ送信装置の制御方法は、送信装置（１００）が、動画像データを生成している。ここで、同ハ．の【００３３】における「動画像データ生成部１０２において、これらの圧縮符号化方式を用いて動画像データを符号化するものとする。そこで、まず動画像データを構成する各画像（フレーム）を圧縮する方式として存在する」との記載によれば、前述の動画像データは、圧縮符号化されたフレームを含んでいる。
　また、上記ハ．の【００５７】における「パケット重要度設定部１０４は、生成したフレームの種別やＧＯＰ構成から推測される、参照フレーム階層に起因するエラー伝播の影響度などからフレーム単位に重要度を決定し」との記載、及び図７によれば、データ送信装置の制御方法は、送信装置（１００）が、フレーム単位に重要度を決定している。
　また、上記ハ．の【００５０】における「パケット再送制御部１０７はパケットロス率算出手段として機能し、通知されたシーケンスナンバー３０１と、ロストしたパケットの個数とから、ある単位時間当たりのパケットロス率を計算する。」との記載、及び図３によれば、データ送信装置の制御方法は、送信装置（１００）が、通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算している。
　また、上記ハ．の【００６１】における「再送要求されたパケットのシーケンスナンバー３０１に対応する重要度情報を重要度情報バッファ１１３から取得し、前述の２種類のパケットロス率の情報をロス率バッファ１１４から取得する。そして、パケット再送制御部１０７は再送パケット決定手段として機能し、これらの取得した情報から再送するパケットを決定する（ステップＳ７１１）。」との記載、及び図７によれば、データ送信装置の制御方法は、送信装置（１００）が、再送要求されたパケットのシーケンスナンバーに対応する重要度情報、パケットロス率の情報から再送するパケットを決定している。
　また、上記ハ．の【００６２】における「送信装置１００側においては、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置１０１側に再送処理を行なう。」との記載、及び図７によれば、データ送信装置の制御方法は、送信装置（１００）が、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送している。
　したがって、上記刊行物Ａには、以下の発明（以下、「引用発明Ａ」という。）が記載されているものと認められる。
　「送信装置が、動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む、ステップと、
　前記送信装置が、圧縮符号化されたフレーム単位に重要度を決定するステップと、
　前記送信装置が、通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算するステップと、
　前記送信装置が、再送要求されたパケットのシーケンスナンバーに対応する重要度情報、パケットロス率の情報から再送するパケットを決定するステップと、
　前記送信装置が、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送するステップと
を含む、データ送信装置の制御方法。」
（２）対比
　本願発明と引用発明Ａとを対比する。
ａ．引用発明Ａの「動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む」と、本願発明の「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む」とは、後述する相違点を除いて、「ビデオデータを含む」という点で一致する。
ｂ．引用発明Ａの「圧縮符号化されたフレーム単位に重要度を決定する」と、本願発明の「前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てる」とは、後述する相違点を除いて、「ビデオデータに優先度を割り当てる」という点で一致する。
ｃ．引用発明Ａの「通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算する」と、本願発明の「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集するステップであって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む」とは、後述する相違点を除いて、「ネットワークの状況を監視する」という点で一致する。
ｄ．引用発明Ａの「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」と、本願発明の「前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」とは、後述する相違点を除いて、「ネットワークの状況を考慮して優先度に従って、受信装置に再送する」という点で一致する。
　したがって、本願発明と引用発明Ａは、以下の点で一致ないし相違している。
＜一致点＞
　「送信装置が、ビデオデータを含む、ステップと、
ビデオデータに優先度を割り当てるステップと、
ネットワークの状況を監視するステップと、
ネットワークの状況を考慮して優先度に従って、受信装置に再送するステップと
を、含む方法。」
＜相違点１＞
　一致点の「ビデオデータを含む」に関し、
　本願発明の「送信装置」は、「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ（ＮＡＬ）拡張ヘッダと、前記ビデオコンテンツの第１のレイヤと、前記ビデオコンテンツの第２のレイヤとを含み、前記第１のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第１のビデオデータを含み、前記第２のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第１のビデオデータと共に利用される第２のビデオデータを含む」のに対し、引用発明Ａの「送信装置」は、「動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む」点。
＜相違点２＞
　本願発明の「送信装置」は、「前記ＮＡＬ拡張ヘッダを解析して、前記第１及び第２のビデオデータを特定するステップ」を含むのに対し、引用発明Ａの「送信装置」は、当該ステップを含まない点。
＜相違点３＞
　一致点の「ビデオデータに優先度を割り当てる」に関し、
　本願発明の「送信装置」は、「前記第２のビデオデータに対して、前記第１のビデオデータに、再送信についてより高い優先度を割り当てる」のに対し、引用発明Ａの「送信装置」は、「圧縮符号化されたフレーム単位に重要度を決定する」点。
＜相違点４＞
　本願発明の「送信装置」は、「前記第１及び第２のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップ」を含むのに対し、引用発明Ａの「送信装置」は、当該ステップを含まない点。
＜相違点５＞
　本願発明の「送信装置」は、「デジタルデータネットワークの第１のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第２のデータチャネルを含み、前記第１のデータチャネルは第１のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第２のデータチャネルは第２のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第１のトランスポートプロトコルは前記第２のトランスポートプロトコルより信頼性が高くない、ステップ」を含むのに対し、引用発明Ａの「送信装置」は、当該ステップを含まない点。
＜相違点６＞
　一致点の「ネットワークの状況を監視する」に関し、
　本願発明の「送信装置」は、「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第１のネットワークデータを収集するステップであって、前記第１のネットワークデータは第１のネットワーク伝送状態を示し、前記第１のネットワーク伝送状態は第１のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第１の利用可能帯域幅と、第１のラウンドトリップ遅延とのうち少なくとも１つを含む」のに対し、引用発明Ａの「送信装置」は、「通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算する」点。
＜相違点７＞
　本願発明の「送信装置」は、「前記受信装置から前記第２のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第２のネットワークデータを含み、前記第２のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第２のネットワーク伝送状態を示し、前記第２のネットワーク伝送状態は第２のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第２の利用可能帯域幅と、第２のラウンドトリップ遅延とのうち少なくとも１つを含む、ステップ」を含むのに対し、引用発明Ａの「送信装置」は、当該ステップを含まない点。
＜相違点８＞
　本願発明の「送信装置」は、「前記第１のネットワークデータを前記第２のネットワークデータで補足するステップ」を含むのに対し、引用発明Ａの「送信装置」は、当該ステップを含まない点。
＜相違点９＞
　一致点の「ネットワークの状況を考慮して優先度に従って、受信装置に再送する」に関し、
　本願発明の「送信装置」は、「前記再送信要求に応じて、補足された前記第１のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第１及び第２のビデオデータのうち少なくとも１つを回復し、前記第２のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」のに対し、引用発明Ａの「送信装置」は、「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」点。
（３）判断
　そこで、上記相違点５、７及び８について検討する。
　本願明細書における「特許文献１は、効率的なアプリケーションレイヤの自動再送要求再送信方法を開示している。・・・サーバ１００は、ＵＤＰ／ＩＰトランスミッタインタフェース１４０又はＴＣＰ／ＩＰトランスミッタ／レシーバインタフェース１４５の一方と、イーサネット（登録商標）／８０２．１１インタフェース１５０などのデジタルデータネットワークインタフェースにより、デジタルデータを送信する。最初のリアルタイム送信は、最初の送信１６０を介してネットワーク１１０に対して行われ、リアルタイムパケットはキャッシュ／バッファ１３５に一時的に記憶され、例えば、再送ＡＣＫ／ＮＡＣＫ制御１５５の受信又は所定のタイムアウトを待つ。」（段落【０００６】）、「前掲の特許文献１に開示されたような信頼性の高いメディアプロトコルをベースにしたリアルタイムデータ送信システムをさらに信頼性が高いものにする効率的な方法と装置があれば、有利である。本発明は上記その他の問題を解決するものである。」（段落【０００７】）との記載によれば、本願発明は、最初にＵＤＰプロトコルでリアルタイムデータ送信を行い、その後、信頼性の高いＴＣＰプロトコルで再送制御を行うシステムを前提とし、リアルタイムデータ送信システムをさらに信頼性が高く効率的なものにするという課題を解決するために、相違点５、７及び８に係る構成としているものである。
　一方、刊行物Ａの上記ロ．における「前記特許文献１に記載の技術では、受信側は、パケットロスの検知だけではなく、パケットロスが発生した場合にロストしたパケットの重要度を判別して再送要求を行なうか否かの判断を行なう必要があった。このため、受信側の処理負荷が大きくなってしまうという問題点があった。」（段落【０００７】）、「本発明は前述の問題点に鑑み、パケットロスが発生した場合に、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうことができるようにすることを目的としている。」（段落【００１０】）との記載によれば、引用発明Ａは、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうという課題を解決するために、「送信装置（１００）」が、「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」ものにすぎない。よって、そもそも「送信装置」が「受信装置」にビデオデータを送信するための前提となるシステム構成が相違しており、そのため発明の課題も異なっているから、引用発明Ａを相違点５、７及び８のように構成する動機付けが存在しない。
　したがって、引用発明Ａから、本願発明の相違点５、７及び８に係る発明特定事項を導き出すことはできない。
　よって、本願発明は、上記相違点１〜４、６、９について検討するまでもなく、本願発明は、刊行物Ａに記載された発明とはいえない。また、引用発明１に基づいて、当業者が容易に発明をすることができたとはいえない。
（４）小括
　よって、本願発明は、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて、当業者が容易に発明をすることができたとはいえなくなった。
　請求項２は、請求項１に係る発明のカテゴリーを「装置」とした発明であるから、上記（３）と同じ理由により、刊行物Ａに記載された発明とはいえなくなり、また、引用発明Ａに基づいて当業者が容易に発明をすることができたとはいえなくなった。
第５　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。