拒絶査定不服の審決｜不服2015-16752 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 1項3号刊行物記載取り消して特許、登録 H04L 審判査定不服 2項進歩性取り消して特許、登録 H04L
管理番号	1321703
審判番号	不服2015-16752
総通号数	205
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2017-01-27
種別	拒絶査定不服の審決
審判請求日	2015-09-11
確定日	2016-11-29
事件の表示	特願2012-551135「再送決定する方法及び装置」拒絶査定不服審判事件〔平成23年 8月 4日国際公開、WO2011/093836、平成25年 5月20日国内公表、特表2013-518511、請求項の数(2)〕について、次のとおり審決する。
結論	原査定を取り消す。本願の発明は、特許すべきものとする。
理由	第1 手続の経緯本願は、2010年1月28日(外国庁受理)を国際出願日とする出願であって、平成26年7月18日付けで最後の拒絶理由が通知され、平成27年1月27日付けで手続補正がされたが、同年4月30日付けで補正の却下の決定がなされるとともに、同日付けで拒絶査定(以下、「原査定」という。)がされ、これに対し、同年9月11日に拒絶査定不服審判が請求されるとともに、同日付けで手続補正がされ、その後、当審において平成28年5月30日付けで拒絶理由(以下、「当審拒絶理由」という。)が通知され、同年8月30日付けで手続補正がされたものである。第2 本願発明本願の請求項1、2に係る発明は、平成28年8月30日付けの手続補正で補正された特許請求の範囲の請求項1、2に記載された事項により特定されるものと認められる。本願の請求項1に係る発明(以下、「本願発明」という。)は以下のとおりである。「【請求項1】送信装置が、デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ(NAL)拡張ヘッダと、前記ビデオコンテンツの第1のレイヤと、前記ビデオコンテンツの第2のレイヤとを含み、前記第1のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第1のビデオデータを含み、前記第2のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第1のビデオデータと共に利用される第2のビデオデータを含む、ステップと、前記送信装置が、前記NAL拡張ヘッダを解析して、前記第1及び第2のビデオデータを特定するステップと、前記送信装置が、前記第2のビデオデータに対して、前記第1のビデオデータに、再送信についてより高い優先度を割り当てるステップと、前記送信装置が、前記第1及び第2のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップと、前記送信装置が、デジタルデータネットワークの第1のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第2のデータチャネルを含み、前記第1のデータチャネルは第1のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第2のデータチャネルは第2のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第1のトランスポートプロトコルは前記第2のトランスポートプロトコルより信頼性が高くない、ステップと、前記送信装置が、デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第1のネットワークデータを収集するステップであって、前記第1のネットワークデータは第1のネットワーク伝送状態を示し、前記第1のネットワーク伝送状態は第1のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第1の利用可能帯域幅と、第1のラウンドトリップ遅延とのうち少なくとも1つを含む、ステップと、前記送信装置が、前記受信装置から前記第2のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第2のネットワークデータを含み、前記第2のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第2のネットワーク伝送状態を示し、前記第2のネットワーク伝送状態は第2のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第2の利用可能帯域幅と、第2のラウンドトリップ遅延とのうち少なくとも1つを含む、ステップと、前記送信装置が、前記第1のネットワークデータを前記第2のネットワークデータで補足するステップと、前記送信装置が、前記再送信要求に応じて、補足された前記第1のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第1及び第2のビデオデータのうち少なくとも1つを回復し、前記第2のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定するステップとを含む、方法。」第3 原査定の理由について 1.原審の拒絶理由の概要「1.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。 2.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。刊行物1:特開平9-191314号公報理由1について請求項:1,2 刊行物:1 刊行物1には、トランスミッタがレシーバから再送要求を受信し、ネットワークトランスポート統計(Tｒ2)と優先度情報に基づき、再送信するか否かを決定することが記載されており(特に、段落36-42)、刊行物1に係る発明と当該請求項に係る発明とは、構成上の差異がない。理由2について請求項:1,2 刊行物:1 上記に加え、当該請求項に係る発明は、上記理由1で述べた理由と同様の理由により、当業者であれば、刊行物1に記載された発明に基づいて、容易に発明することができたものであるから、特許法第29条第2項の規定により特許を受けることができない。」 2.原査定の理由の判断 (1)刊行物の記載事項原査定の拒絶の理由に引用された特開平9-191314号公報(刊行物1)には、図面とともに以下の事項が記載されている。イ.「【0001】【発明の属する技術分野】この発明は動画や音声等の連続データを伝送し、受信側でデータ生成時間と同じ時間で再生する連続データ伝送方法および連続データ伝送装置に関するものである。データを伝送し、データ生成時間と同じ時間で再生することは、例えば10分の映像を10分で表示することです。伝送にかかる遅延時間の問題ではありません。」(3頁左欄) ロ.「【0036】実施の形態5.この実施の形態は、実施の形態1?4においてパケット再送判定機能を受信機側でなく送信機側に持たせた場合の例である。本実施の形態の構成図を図10に示す。図11は受信機40の動作フロー、図12は送信機39のパケット再送動作フロー図である。送信機39の再送以外の動作フローは図2と同一なので省略する。図1で示される実施の形態1との違いは、まず受信機40側において受信パケットのシステムクロックを用いたタイムスタンプ比較とそれに基づく再送判定を行う機能を削除している。従って受信側で誤りを検出したパケットは即座に再送要求メッセージを作成し送信機39に対して返送するものとする(図11のステップ63、77、67)。【0037】一方送信側は再送要求メッセージパケットを受信すると、まずパケット解析部32においてどのパケットの再送が要求されているかの解析を行う(図12のステップ79)。次に再送要求されたパケット内の受信制限時刻に関するタイムスタンプ情報TSと送信機内のシステムクロックSCとを比較し、その差分結果TS-SCをやはり送信機内にある再送判定部37に通知する。再送判定部37ではこの差分時間情報TS-SCと、ここから再送を行って受信側に届くまでの片道の推定時間Tｒ2とを比較し、再送を行うか否かの判定を行う。TS-SC＞Tｒ2なら再送しても受信制限時刻に間に合うので再送を行う(図12のステップ81、82)。そうでない場合は、そのパケットは廃棄する(ステップ83)。【0038】このとき、再送にかかると推定される時間Tｒ2は実施の形態3と同様、再送要求が返ってきた場合のタイムスタンプ情報から動的に変化させてももちろんよい。また再送判定基準としては、再送を行う時の現在時刻にTｒ2を加えた値が、はじめのパケットが作成された時の時刻に伝送遅延許容時間を加えた時刻に対して1/30秒以上の遅れとなるかどうかで判定を下せばよい。【0039】このように再送判定部を送信側に持たせることによって、受信機側に送信機側に何らかの形で同期させたシステムクロックと再送判定プロセスの実行を省くことができるので、複数の送信元からの送信を同時に処理しなければならないようなシステムにおいては特に、受信機側の負荷を軽くすることができる利点がある。」(7頁右欄?8頁左欄) 上記刊行物1の記載及び図面並びにこの分野における技術常識を考慮すると、上記イ.の【0001】における「この発明は動画や音声等の連続データを伝送し、受信側でデータ生成時間と同じ時間で再生する連続データ伝送方法・・・に関するものである。」との記載によれば、刊行物1の連続データ伝送方法は、動画を伝送するものである。また、上記ロ.の【0037】のおける「一方送信側は再送要求メッセージパケットを受信すると、まずパケット解析部32においてどのパケットの再送が要求されているかの解析を行う(図12のステップ79)。次に再送要求されたパケット内の受信制限時刻に関するタイムスタンプ情報TSと送信機内のシステムクロックSCとを比較し、その差分結果TS-SCをやはり送信機内にある再送判定部37に通知する。再送判定部37ではこの差分時間情報TS-SCと、ここから再送を行って受信側に届くまでの片道の推定時間Tｒ2とを比較し、再送を行うか否かの判定を行う。TS-SC＞Tｒ2なら再送しても受信制限時刻に間に合うので再送を行う(図12のステップ81、82)。」との記載、及び図12によれば、刊行物1の連続データ伝送方法は、送信側が、受信側から再送要求メッセージパケットを受信し、差分時間情報TS-SCと片道の推定時間Tｒ2を比較し、再送を行うか否かの判定を行っている。したがって、上記刊行物1には、以下の発明(以下、「引用発明1」という。)が記載されているものと認められる。「送信側が、受信側から再送要求メッセージパケットを受信し、差分時間情報TS-SCと片道の推定時間Tｒ2を比較し、動画の再送を行うか否かの判定を行う連続データ伝送方法。」 (2)対比本願発明と引用発明1とを対比する。 a.引用発明1の「送信側」は、送信側の装置であるから、「送信装置」ということができる。 b.引用発明1の「受信側から再送要求メッセージパケットを受信し、差分時間情報TS-SCと片道の推定時間Tｒ2を比較し、動画の再送を行うか否かの判定を行う」と、本願発明の「前記再送信要求に応じて、補足された前記第1のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第1及び第2のビデオデータのうち少なくとも1つを回復し、前記第2のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」とは、後述する相違点を除いて、「ネットワーク状況を考慮して、再送を行うか否か決定する」という点で一致する。したがって、本願発明と引用発明1は、以下の点で一致ないし相違している。＜一致点＞「送信装置が、ネットワーク状況を考慮して、再送を行うか否か決定するステップを、含む方法。」＜相違点1＞本願発明の「送信装置」は、「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ(NAL)拡張ヘッダと、前記ビデオコンテンツの第1のレイヤと、前記ビデオコンテンツの第2のレイヤとを含み、前記第1のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第1のビデオデータを含み、前記第2のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第1のビデオデータと共に利用される第2のビデオデータを含む、ステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点2＞本願発明の「送信装置」は、「前記NAL拡張ヘッダを解析して、前記第1及び第2のビデオデータを特定するステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点3＞本願発明の「送信装置」は、「前記第2のビデオデータに対して、前記第1のビデオデータに、再送信についてより高い優先度を割り当てる」のに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点4＞本願発明の「送信装置」は、「前記第1及び第2のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点5＞本願発明の「送信装置」は、「デジタルデータネットワークの第1のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第2のデータチャネルを含み、前記第1のデータチャネルは第1のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第2のデータチャネルは第2のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第1のトランスポートプロトコルは前記第2のトランスポートプロトコルより信頼性が高くない、ステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点6＞本願発明の「送信装置」は、「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第1のネットワークデータを収集するステップであって、前記第1のネットワークデータは第1のネットワーク伝送状態を示し、前記第1のネットワーク伝送状態は第1のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第1の利用可能帯域幅と、第1のラウンドトリップ遅延とのうち少なくとも1つを含む、ステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点7＞本願発明の「送信装置」は、「前記受信装置から前記第2のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第2のネットワークデータを含み、前記第2のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第2のネットワーク伝送状態を示し、前記第2のネットワーク伝送状態は第2のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第2の利用可能帯域幅と、第2のラウンドトリップ遅延とのうち少なくとも1つを含む、ステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点。＜相違点8＞本願発明の「送信装置」は、「前記第1のネットワークデータを前記第2のネットワークデータで補足するステップ」を含むのに対し、引用発明1の「送信側」は、当該ステップを含まない点＜相違点9＞一致点の「ネットワーク状況を考慮して、再送を行うか否か決定する」に関し、本願発明の「送信装置」は、「前記再送信要求に応じて、補足された前記第1のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第1及び第2のビデオデータのうち少なくとも1つを回復し、前記第2のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」のに対し、引用発明1の「送信側」は、「受信側から再送要求メッセージパケットを受信し、差分時間情報TS-SCと片道の推定時間Tｒ2を比較し、動画の再送を行うか否かの判定を行う」点。 (3)判断そこで、まず、上記相違点5について検討する。引用発明1の「送信側」は、「受信側から再送要求メッセージパケットを受信し、差分時間情報TS-SCと片道の推定時間Tｒ2を比較し、動画の再送を行うか否かの判定を行う」にすぎず、そもそも、本願発明の前提である相違点5に係る「デジタルデータネットワークの第1のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第2のデータチャネルを含み、前記第1のデータチャネルは第1のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第2のデータチャネルは第2のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第1のトランスポートプロトコルは前記第2のトランスポートプロトコルより信頼性が高くない、ステップ」を備えていない。したがって、引用発明1から本願発明を導き出すことはできない。よって、本願発明は、上記相違点1?4、6?9について検討するまでもなく、本願発明は、刊行物1に記載された発明とはいえない。また、引用発明1に基づいて、当業者が容易に発明をすることができたとはいえない。 (4)小括したがって、本願発明は、本願発明は、刊行物1に記載された発明とはいえない。また、刊行物1に基いて、当業者が容易に発明をすることができたとはいえない。請求項2は、請求項1に係る発明のカテゴリーを「装置」とした発明であるから、上記(3)と同じ理由により、刊行物1に記載された発明とはいえない。また、引用発明1に基づいて当業者が容易に発明をすることができたとはいえない。よって、原査定の理由によっては、本願を拒絶することはできない。第4 当審拒絶理由について 1.当審拒絶理由の概要「A.この出願の請求項1,2に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから,特許法第29条第1項第3号に該当し,特許を受けることができない。 B.この出願の請求項1,2に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。刊行物A:特開2008-312126号公報請求項1,2に係る発明に対して: 上記刊行物A 上記刊行物Aには,受信装置から受信した再送要求の情報に基づいて送信装置が算出したパケットロス率と,パケット毎の重要度とから,再送要求されたパケットの再送の可否を決定するようにした送信装置及び送信方法が記載されている(特に図7のパケット再送制御に関する処理の流れ及び関連する記載参照)。そして,上記「パケットロス率」の具体的な生成方法について,段落【0050】に「パケット再送制御部107はパケットロス率算出手段として機能し,通知されたシーケンスナンバー301と,ロストしたパケットの個数とから,ある単位時間当たりのパケットロス率を計算する。パケットロス率は,再送要求パケットを受信した時刻からある一定時間前までの間(所定時間)に送信した総パケット数と,それに対するロストしたパケット数との割合から計算する。」と記載されているように,「受信装置から受信した複数の再送要求パケットでそれぞれ通知されるシーケンスナンバーに基づき,送信装置でパケットロス率を計算・生成」しているものと認められる。このとき,「受信装置から受信した複数の再送要求パケットでそれぞれ通知されるシーケンスナンバー」は,「受信装置から収集した統計」といい得るものであり,また,この「受信装置から収集した統計」に基づき「送信装置でパケットロス率を計算・生成」することは,「送信装置がデジタルデータネットワークをモニタしてネットワークトランスポート統計を収集」することといい得るものである。そうすると,本願請求項1,2に係る発明と上記刊行物Aに記載された発明との間に格別の差異は見当たらない。」 2.当審拒絶理由の判断 (1)刊行物の記載事項当審の拒絶の理由に引用された特開2008-312126号公報(刊行物A)には、図面とともに以下の事項が記載されている。イ.「【技術分野】【0001】発明はデータ送信装置、データ受信装置、データ送受信システム、データ送信装置の制御方法、データ受信装置の制御方法、プログラム及び記録媒体に関し、特に、回線状況やパケットの重要度に応じて再送の動作を制御するために用いて好適な技術に関する。」(4頁) ロ.「【発明が解決しようとする課題】【0007】しかしながら、前記特許文献1に記載の技術では、受信側は、パケットロスの検知だけではなく、パケットロスが発生した場合にロストしたパケットの重要度を判別して再送要求を行なうか否かの判断を行なう必要があった。このため、受信側の処理負荷が大きくなってしまうという問題点があった。【0008】さらに、ロストしたパケットの重要度を受信側で判別するための仕組みを各パケットに送信側で組み入れる必要があり、その分だけトラフィックが増大してしまう。このため、効率の良い通信を行なう点においては不十分であった。【0009】また、前記特許文献1に記載の技術では、重要度のレベルが高・低の2段階であり、処理の細かい再送制御を行なうことができなかった。このため、再送制御という点に着目した場合においても、効率の良い通信を行なう点においては不十分であった。【0010】本発明は前述の問題点に鑑み、パケットロスが発生した場合に、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうことができるようにすることを目的としている。」(5頁) ハ.「【0020】 (第1の実施形態) 本発明の実施形態として、動画像データから通信用のパケットを生成し、受信装置に送信するシステムについて図面を参照しながら説明する。図1は、本実施形態におけるデータ送受信システムの構成例を示すブロック図である。このシステムは、動画像データを送信する送信装置100と動画像データを受信する受信装置101とで構成され、動画像データは通信に適したサイズに分割され、通信パケットとして送受信が行なわれる。【0021】図1に示す送信装置100においては、動画像データ生成部102は、概念的な機能面からは、動画像データを生成し、パケット生成部103は、生成した動画像データを通信に適したサイズに分割し、通信用のプロトコルに準じたパケットを生成する。また、パケット生成部103はパケット保管手段として機能し、第2の記憶部である送信バッファ112に生成したパケットを一時保管する。【0022】パケット重要度設定部104は、生成したパケット毎に重要度のレベル分けを行なう。また、パケット重要度設定部104はパケット重要度記憶手段として機能し、パケット毎の重要度情報を第1の記憶部である重要度情報バッファ113に一時保管する。接続制御部105は、受信装置101との接続状態を制御し、パケット通信部106は、生成したパケットを受信装置101に送信する。また、パケット再送制御部107は、パケット通信部106を介して受信装置101から送られるパケットの再送要求情報からパケットのロス率を計算する。そして、パケットの再送を行なうか否かを判断し、計算したパケットロス率のデータをロス率バッファ114に一時保管する。【0023】一方、受信装置101においては、接続制御部108は、送信装置100との接続状態を制御し、パケット通信部109は、送信装置100から送信されるパケットを受信する。そして、パケットロス検知部111は、受信したパケットから通信経路途中で損失したパケットを検出し、パケット再送要求部110は、損失したパケットの再送をパケット通信部109を介して送信装置100に要求する。なお、受信装置101は1つの送信装置100に対して、複数接続していてもよい。【0024】次に、図1を参照しながら、本実施形態のシステムの一般的な処理の流れについて説明する。まず、受信装置101を操作する利用者の操作により、送信装置100から動画像データを取得するように要求する。この操作は、例えばGUI(グラフィカル・ユーザ・インターフェース)を用いて送信装置100のURL(Uniform Resource Locator)を入力する操作であってもよい。また、受信装置101に予め通信接続の定義しておいた情報を用いて、スイッチを押下するような操作であってもよい。【0025】動画像データ取得の指示においては、送信装置100に接続するためのメッセージをパケット通信部109から送信するように接続制御部108が制御する。そして、パケット通信部109は、送信装置100のパケット通信部106に対して、接続を要求するメッセージを通知する。【0026】送信装置100では、受信装置101から送信された接続を要求するメッセージをパケット通信部106にて受信し、接続制御部105は、接続の可否を判断する。そして、その判断の結果を示すメッセージを受信装置101に返す。この接続制御のための通信において最も一般的な方法のひとつは、RTSP(Real Time Streaming Protocol、RFC 2326、The Internet Society)によるものである。図1では簡略化のため、接続制御のメッセージを単純化した矢印にて記載しているが、例えばRTSPにおいては、複数回のメッセージ交換により行われる。【0027】送信装置100においては、次に、動画像データ生成部102において動画像データの生成を行ない、生成された動画像データを、所定のバッファに一時的に保管する。そして、所定のバッファに保管された動画像データは、パケット生成部103にて通信に適したサイズに分割され、動画像データを含んだ送信用パケットが生成される。この生成された送信用パケットは、受信装置101から再送要求があった時に備え、送信バッファ112において、一定時間分保管される。【0028】一方、パケット重要度設定部104では、送信用パケットを生成する際に、動画像データ生成部102から動画像のフレーム毎にフレームの種類を取得し、取得したフレームの種類、及びそのフレームの並び順からフレーム毎に重要度を設定する。この重要度設定の方法および処理内容については、後で詳細に説明する。【0029】そして、生成された送信用パケットは、パケット通信部106から受信装置101のパケット通信部109へ順次送信される。【0030】次に、受信装置101では、パケット通信部109で受信したパケットから、通信系路上で失われたパケットの検出を行なう。この検出処理は、パケットロス検出手段として機能するパケットロス検知部111において行なわれる。そして、パケットの損失(ロス)があった場合には、パケット再送要求部110において、パケットロスが検出されたパケットの再送を要求するメッセージ(以下、再送要求メッセージと称す)を生成する。そして、送信装置100の再送要求受信手段として機能するパケット通信部106に対して、パケット通信部109から再送要求メッセージを通知する。【0031】通信経路上で損失したパケットの再送要求メッセージが受信装置101から送信装置100に通知された場合、送信装置100では、パケット通信部106からパケット再送制御部107へ再送要求メッセージが渡される。そして、再送要求メッセージに対して、再送するパケットの選別及び再送の可否が判定される。【0032】この時、パケット再送制御部107では、パケットの再送要求メッセージから算出するパケット損失の割合、パケット重要度設定部104で設定したパケット毎の重要度情報などから、実際に受信装置101へ再送するパケットを決定する。この決定に応じて、パケット通信部106はパケット再送手段として機能し、パケットの再送に備えて送信バッファ112にて保管していたパケットを読み出して受信装置101へ送信する。受信装置101のパケット通信部109はパケット通信手段として機能し、送信装置100から送信された再送パケットを受信する。なお、送信バッファ112、重要度情報バッファ113、及びロス率バッファ114は、同一の記憶装置であってもよい。【0033】次に、図2を参照しながら前述したパケット重要度設定部104で行なわれるフレーム毎の重要度設定の方法及び処理内容について説明する。動画像データを分割してパケット化して送受信を行なう場合、動画像データは一般に圧縮符号化処理が行なわれる。その代表的な方式として、MPEG-2(ISO/IEC 13818)やMPEG-4(ISO/IEC 14496)などのMPEG方式があげられる。本実施形態では、動画像データ生成部102において、これらの圧縮符号化方式を用いて動画像データを符号化するものとする。そこで、まず動画像データを構成する各画像(フレーム)を圧縮する方式として存在する主な3種類の圧縮方式について説明する。【0034】 1つ目は、1つのフレーム内の情報のみでマクロブロック処理などを行ない圧縮符号化処理する方式であり、この方式で圧縮されたフレームはI-Frame (Intra-coded Frame)と呼ばれる。【0035】 2つ目は、時間軸上前方のフレームを参照しながら、動き補償予測、マクロブロック処理など差分情報を抽出して行なう方式であり、前方のフレームに依存した圧縮方式である。この方式で圧縮されたフレームをP-Frame (Predicted Frame)と呼ぶ。【0036】 3つ目は、P-Frameと同様に時間軸上隣り合ったフレームを参照しながら圧縮符号化を行なう方式である。ところが、P-Frameが前方のフレームのみを参照していたのに対し、時間軸上、当該フレームの前後のフレームを参照しながら動き補償予測、マクロブロック処理などを行なう。この方式で圧縮されたフレームをB-Frame (Bi-directional Predicted Frame)と呼ぶ。なお、前述した画像のフレーム(Frame)はピクチャ(Picture)とも呼ばれるが、本実施形態ではフレーム(Frame)と呼ぶこととする。【0037】図2に示す「I」、「P」、「B」は、各々I-Frame、P-Frame、B-Frameを表しており、「P」、及び「B」の添え字の数字は、同じ符号化形式のフレームを識別するために付されている。また、いくつかの符号化済みのフレームの集合はGOP(Group of Pictures)、或いはGOV(Group of Video Object Plane)と呼ばれている。通常、符号化済みの動画像データはGOP或いはGOVの組み合わせのフレームが連続している。以下、符号化済みのフレームの集合をGOPと呼称する。【0038】図2は、代表的な2つのタイプのGOPにおける重要度の設定方法を示す図である。図2(a)に示すタイプのGOPでは、先頭のI-Frameから始まって、以降のP-Frameは常に前方フレームのみを参照している。このため、パケットロスなどで情報の欠落があった場合、情報の欠落があるフレームが前方のフレームであるほど画像への影響が大きい。そこで本実施形態では、パケットの損失などによるエラーの伝播の影響度の高いものほど重要度が高いものとして設定する。したがって、図2(a)に示すタイプのGOPでは、先頭のI-Frameが最も重要度が高く、以降のP-Frameでは送信順に重要度が低下する。また、図2に示す重要度は、数値が小さいほど重要度が高いことを示しており、「1」が最も重要度が高い数値である。【0039】一方、図2(b)に示すタイプのGOPでは、B-Frameが含まれているため、図2(b)に示すように送信順(=デコード順)とディスプレイ装置で表示される表示順とが異なる。この場合、デコード時のフレーム間の参照関係に着目すると、I-Frameはそのフレーム以降の最初の参照元フレームを生成するデータとなるので図2(a)に示すタイプと同様に最も重要度が高い。【0040】ところがB-Frameは、前後のフレームを参照してデコードするが、そのように生成したフレームは、さらにそのフレームを参照してデコードに利用されることはない。つまり、パケットの損失などによるエラーの伝播の影響はそのフレームに限定されるため、B-Frameの重要度は最も低い。また、エラーの伝播の影響のみを考慮した場合も、B-Frame同士では、全て同じレベルの重要度となる。【0041】また、P-FrameはI-FrameとB-Frameの中間の重要度となり、P-Frame間の重要度に関しては、図2(a)に示すタイプと同様に時間軸上前方に位置するフレームの方が重要度が高い。よって、図2(b)に示すようにデコード順が「I・P・B・B・P・B・B」という並びのGOPのフレーム毎の重要度は、「1・2・4・4・3・4・4(数字が小さいほど重要度が高い)」という順番になる。【0042】パケット重要度設定部104では、前述したようにフレーム単位で重要度を決定し、そのフレームのデータを格納したパケットを生成する毎に当該パケットの重要度を設定する。このパケット毎の重要度情報は、少なくとも送信バッファ112で再送用に一時保管されているパケットが廃棄されるまでは、重要度情報バッファ113に保持される。なお、図2においては、I,P,B各フレームを含むGOPの典型的なフレーム構成を示したものであるため、その他の構成のGOPも勿論存在する。【0043】以上のように、本実施形態における各フレームの重要度の設定方法においては、いかなる構成のGOPであっても、パケットロスなどによって各フレームのデータが欠落した場合に、エラーの伝播の影響が及ぶフレームの数が多いほど、重要度を高く設定する。【0044】次に、各フレームから構成された動画像データを通信に適したサイズに分割してパケット化する方法について説明する。本実施形態では、データ通信の手段として、RTPを用いる場合のパケット生成について説明する。【0045】図3は、RTPパケットの構成を模式化した簡略図である。RTPパケットは、RTPヘッダ300とペイロードデータ部303とで構成されている。動画像データ生成部102で生成された動画像データは、パケット生成部103にて通信に適したサイズに分割されるが、この時、分割された動画像データはペイロードデータとして、ペイロードデータ部303に格納される。【0046】動画像データを構成する各フレームのデータは、通信に適した任意のサイズで分割してパケット化することが可能であるため、受信側で復号化する際に、元のフレームのデータを再現する必要がある。その情報を与えるものとして、RTPヘッダ300には、データの順序を表す付加情報として、シーケンスナンバー301が付与されている。また、RTPヘッダ300には、各フレームのデータを復号したものを表示する時間を示す、タイムスタンプ302なども付与されている。これら情報以外にも、各フレームを構成するRTPパケットの終わりを示す情報やRTPパケット仕様のバージョン情報など様々な情報が含まれているが、図3では、簡略化のために記載していない。【0047】次に、受信装置101のパケットロス検知部111によるパケットロス検出の方法について説明する。前述したように、送信装置100から送信されるパケットは、図3に示すような構成を持つRTPパケットであり、RTPヘッダ300にあるシーケンスナンバー301は、パケットを生成する毎に1ずつ増加する自然数で表される。したがって、受信したRTPパケットのシーケンスナンバー301に番号の抜けがあった場合は、送信側から受信側へ到達しなかったパケット、即ちパケットの損失(パケットロス)があったことが分かる。【0048】パケットロス検知部111では、このようにRTPパケットのシーケンスナンバー301を監視することによってパケットロスの発生を検知する。なお、通信経路上において、パケットの送信順番が入れ替わることがある。そこで、パケットロス検知部111では、フレームのデータの復号化などの処理や、後述するパケットの再送処理に支障を来たさない範囲で、ある閾値でパケットの順番の入れ替わりを容認して、損失したパケットの検出を行なう。なお、このパケットの到達する順番の入れ替わりを容認してパケットロスを検出する方法については、本実施形態に関する技術においては重要ではないので、説明を割愛する。【0049】次に、パケットロスがあった場合の再送要求の方法について説明する。パケット再送要求部110ではパケットロス検知部111において検知された損失したパケットのシーケンスナンバー301を送信装置100に通知するための再送要求パケットを生成する。生成された再送要求パケットは、パケット通信部109から送信装置100へ送信される。そして、パケット通信部106で受信された再送要求パケットの情報は、パケット再送制御部107に渡され、再送可否の判定が行なわれる。本実施形態では、受信装置101がパケットロスを検知する毎に再送要求パケットが生成され、随時、送信装置100へ再送要求が行なわれる。【0050】次に、パケット再送制御部107によるパケット再送可否の判定の方法について説明する。前述したように再送要求パケットが受信されると、通信経路上で損失したパケットのシーケンスナンバー301が、再送要求の情報としてパケット再送制御部107へ通知される。パケット再送制御部107はパケットロス率算出手段として機能し、通知されたシーケンスナンバー301と、ロストしたパケットの個数とから、ある単位時間当たりのパケットロス率を計算する。パケットロス率は、再送要求パケットを受信した時刻からある一定時間前までの間(所定時間)に送信した総パケット数と、それに対するロストしたパケット数との割合から計算する。【0051】図4は、計算により求めたパケットロス率に対する、パケットを再送する割合を示したものである。ここで、パケットロス率を計算する際には、図5に示すように、時間的に比較的短い時間レンジでのパケットロス率501と長い時間レンジでのパケットロス率502との2種類の数値を計算する。【0052】図4に示すように、短い時間レンジでのパケットロス率501が図4に示す閾値ThLｏ401以下であった場合は、送信装置100は、再送要求された全てのパケットの再送に応じる。また、逆に閾値ThHi402以上であった場合は、再送要求には応じない。さらに、閾値ThLｏ401と閾値ThHi402との間であった場合は、パケット再送率とパケット毎の重要度とに応じて再送要求するパケットを選別する。【0053】図6は、短い時間レンジでのパケットロス率501が閾値ThLｏ401から閾値ThHi402までの間にある場合において、再送するパケットの重要度レベルを示す図である。図6に示す重要度(再送重要度レベル)は、数値が小さいほど重要度が高いことを意味している。例えば、パケットロス率が10?15%のレンジに含まれている場合は、重要度が「1」から「2」までのパケットを再送し、「3」以上の数値の重要度が設定されているパケットに関しては、再送要求を受けても再送には応じないようにしている。【0054】なお、図6に示すパケットロス率のレンジや再送重要度レベルの設定値は1つの例であり、本実施形態におけるパケット再送制御の絶対的な値を意味するものではない。さらに、閾値ThLｏ401及び閾値ThHi402は、時間的に長い時間レンジでのパケットロス率502の値によって、その値を動的に変更するようにしてもよい。例えば、長い時間レンジでのパケットロス率502が比較的低い場合は、閾値を右側にシフトし、逆に長い時間レンジでのパケットロス率502が比較的高い場合は、閾値を左側にシフトするようにしてもよい。【0055】これによって、短い時間レンジでのパケットロス率501が同じでも、長い時間レンジでのパケットロス率502が低い場合は、再送に応じるパケットの数が増える。また、逆に短い時間レンジでのパケットロス率501が同じで長い時間レンジでのパケットロス率502が高いと、再送に応じるパケットの数が減る。このような方法によって、通信経路の輻輳状態をも考慮したパケットの再送制御が可能となる。【0056】以上、本実施形態について図1に示すシステム構成図を中心に詳細に説明してきたが、より明確に説明するために、パケットの再送制御に関する処理の流れを図7に示すフローチャートを参照しながら再度説明する。図7は、本実施形態におけるパケットの再送制御に関する部分の処理手順の一例を示すフローチャートである。【0057】動画像データの送受信処理が開始されると、送信装置100において動画像データ生成部102により動画像データを生成する(ステップS701)。次に、パケット重要度設定部104は、生成したフレームの種別やGOP構成から推測される、参照フレーム階層に起因するエラー伝播の影響度などからフレーム単位に重要度を決定し、フレームに分割したパケット毎に重要度設定を行なう。そして、このパケット毎に設定した重要度情報を重要度情報バッファ113に一時保管する(ステップS702)。次に、パケット生成部103によりパケットを生成し、パケット通信部106により受信装置101に送信する(ステップS703)。【0058】次に、受信装置101においてパケット通信部109によりパケットを受信する(ステップS704)。そして、パケットロス検知部111によりパケットロスの検出を行なう(ステップS705)。次に、ステップS705の検出処理によりロストしたパケットが有るか否かを判定する(ステップS706)。【0059】この判定の結果、ロストしたパケットが有る場合は、パケット再送要求部110によりロストしたパケットの再送を要求するパケットを生成する(ステップS707)。そして、パケット通信部109により送信装置100に再送を要求するパケットを送信する(ステップS708)。一方、ステップS706の判定の結果、ロストしたパケットがない場合は、再送要求を行なう必要がないため、そのまま処理を終了する。【0060】次に、送信装置100においてパケット通信部106は、再送を要求するパケットを受信する(ステップS709)。そして、パケット再送制御部107によりパケットロス率を算出し、算出したパケットロス率のデータをロス率バッファ114に一時保管する(ステップS710)。ここで算出されるパケットロス率は、例えば、数秒から数十秒単位の短い時間レンジでのパケットロス率501と、例えば、1分から数分単位の長い時間レンジでのパケットロス率502との2種類のパケットロス率である。【0061】次に、再送要求されたパケットのシーケンスナンバー301に対応する重要度情報を重要度情報バッファ113から取得し、前述の2種類のパケットロス率の情報をロス率バッファ114から取得する。そして、パケット再送制御部107は再送パケット決定手段として機能し、これらの取得した情報から再送するパケットを決定する(ステップS711)。そして、パケット再送制御部107により決定した再送するパケットをパケット通信部106が送信バッファ112から取得して、受信装置101に送信する(ステップS712)。そして、処理を終了する。【0062】以上のような処理の流れにより、受信装置101側では、送信装置100から送信されてくるパケットの損失を検出し、再送要求を送信装置側に随時送るだけでよい。一方、送信装置100側においては、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置101側に再送処理を行なう。【0063】以上のように本実施形態によれば、受信装置101から送られた再送要求から、パケット再送制御部107がパケットロス率を算出する。そして、前記算出したパケットロス率とパケット重要度設定部104が設定したパケット毎の重要度とから受信装置101に再送する再送パケットを決定するようにした。これにより、受信装置101は、パケットロスが発生した場合に、損失したパケットの重要度を判別して再送要求を行なうか否かを判断することを不要にすることができる。さらに、ロストしたパケットの重要度を受信装置101で判別するための仕組みを各パケットに組み入れることによるトラフィックの増大を防止することができる。したがって、受信側の処理負荷が大きくならないようにするとともに、効率の良い通信を行なうことができる。」(7?13頁) 上記刊行物Aの記載及び図面並びにこの分野における技術常識を考慮すると、上記イ.の【0001】における「発明はデータ送信装置、データ受信装置、データ送受信システム、データ送信装置の制御方法・・・に関し」との記載、上記ハ.の【0057】における「送信装置100において動画像データ生成部102により動画像データを生成する(ステップS701)。」との記載、及び図7によれば、刊行物Aのデータ送信装置の制御方法は、送信装置(100)が、動画像データを生成している。ここで、同ハ.の【0033】における「動画像データ生成部102において、これらの圧縮符号化方式を用いて動画像データを符号化するものとする。そこで、まず動画像データを構成する各画像(フレーム)を圧縮する方式として存在する」との記載によれば、前述の動画像データは、圧縮符号化されたフレームを含んでいる。また、上記ハ.の【0057】における「パケット重要度設定部104は、生成したフレームの種別やGOP構成から推測される、参照フレーム階層に起因するエラー伝播の影響度などからフレーム単位に重要度を決定し」との記載、及び図7によれば、データ送信装置の制御方法は、送信装置(100)が、フレーム単位に重要度を決定している。また、上記ハ.の【0050】における「パケット再送制御部107はパケットロス率算出手段として機能し、通知されたシーケンスナンバー301と、ロストしたパケットの個数とから、ある単位時間当たりのパケットロス率を計算する。」との記載、及び図3によれば、データ送信装置の制御方法は、送信装置(100)が、通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算している。また、上記ハ.の【0061】における「再送要求されたパケットのシーケンスナンバー301に対応する重要度情報を重要度情報バッファ113から取得し、前述の2種類のパケットロス率の情報をロス率バッファ114から取得する。そして、パケット再送制御部107は再送パケット決定手段として機能し、これらの取得した情報から再送するパケットを決定する(ステップS711)。」との記載、及び図7によれば、データ送信装置の制御方法は、送信装置(100)が、再送要求されたパケットのシーケンスナンバーに対応する重要度情報、パケットロス率の情報から再送するパケットを決定している。また、上記ハ.の【0062】における「送信装置100側においては、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置101側に再送処理を行なう。」との記載、及び図7によれば、データ送信装置の制御方法は、送信装置(100)が、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送している。したがって、上記刊行物Aには、以下の発明(以下、「引用発明A」という。)が記載されているものと認められる。「送信装置が、動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む、ステップと、前記送信装置が、圧縮符号化されたフレーム単位に重要度を決定するステップと、前記送信装置が、通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算するステップと、前記送信装置が、再送要求されたパケットのシーケンスナンバーに対応する重要度情報、パケットロス率の情報から再送するパケットを決定するステップと、前記送信装置が、ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送するステップとを含む、データ送信装置の制御方法。」 (2)対比本願発明と引用発明Aとを対比する。 a.引用発明Aの「動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む」と、本願発明の「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ(NAL)拡張ヘッダと、前記ビデオコンテンツの第1のレイヤと、前記ビデオコンテンツの第2のレイヤとを含み、前記第1のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第1のビデオデータを含み、前記第2のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第1のビデオデータと共に利用される第2のビデオデータを含む」とは、後述する相違点を除いて、「ビデオデータを含む」という点で一致する。 b.引用発明Aの「圧縮符号化されたフレーム単位に重要度を決定する」と、本願発明の「前記第2のビデオデータに対して、前記第1のビデオデータに、再送信についてより高い優先度を割り当てる」とは、後述する相違点を除いて、「ビデオデータに優先度を割り当てる」という点で一致する。 c.引用発明Aの「通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算する」と、本願発明の「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第1のネットワークデータを収集するステップであって、前記第1のネットワークデータは第1のネットワーク伝送状態を示し、前記第1のネットワーク伝送状態は第1のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第1の利用可能帯域幅と、第1のラウンドトリップ遅延とのうち少なくとも1つを含む」とは、後述する相違点を除いて、「ネットワークの状況を監視する」という点で一致する。 d.引用発明Aの「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」と、本願発明の「前記再送信要求に応じて、補足された前記第1のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第1及び第2のビデオデータのうち少なくとも1つを回復し、前記第2のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」とは、後述する相違点を除いて、「ネットワークの状況を考慮して優先度に従って、受信装置に再送する」という点で一致する。したがって、本願発明と引用発明Aは、以下の点で一致ないし相違している。＜一致点＞「送信装置が、ビデオデータを含む、ステップと、ビデオデータに優先度を割り当てるステップと、ネットワークの状況を監視するステップと、ネットワークの状況を考慮して優先度に従って、受信装置に再送するステップとを、含む方法。」＜相違点1＞一致点の「ビデオデータを含む」に関し、本願発明の「送信装置」は、「デジタルビデオデータのソースから符号化ビデオデータを受信するステップであって、前記符号化ビデオデータはスケーラブルに符号化されビデオコンテンツを担い、前記符号化ビデオデータはネットワーク抽象化レイヤ(NAL)拡張ヘッダと、前記ビデオコンテンツの第1のレイヤと、前記ビデオコンテンツの第2のレイヤとを含み、前記第1のレイヤは前記符号化ビデオデータから基本画質で前記ビデオコンテンツを読み出すために利用される第1のビデオデータを含み、前記第2のレイヤは前記符号化ビデオデータから高画質で前記ビデオコンテンツを読み出すために、前記第1のビデオデータと共に利用される第2のビデオデータを含む」のに対し、引用発明Aの「送信装置」は、「動画像データを生成するステップであって、前記動画像データは圧縮符号化されたフレームを含む」点。＜相違点2＞本願発明の「送信装置」は、「前記NAL拡張ヘッダを解析して、前記第1及び第2のビデオデータを特定するステップ」を含むのに対し、引用発明Aの「送信装置」は、当該ステップを含まない点。＜相違点3＞一致点の「ビデオデータに優先度を割り当てる」に関し、本願発明の「送信装置」は、「前記第2のビデオデータに対して、前記第1のビデオデータに、再送信についてより高い優先度を割り当てる」のに対し、引用発明Aの「送信装置」は、「圧縮符号化されたフレーム単位に重要度を決定する」点。＜相違点4＞本願発明の「送信装置」は、「前記第1及び第2のビデオデータを、割り当てられた前記優先度でバッファメモリにキャッシングするステップ」を含むのに対し、引用発明Aの「送信装置」は、当該ステップを含まない点。＜相違点5＞本願発明の「送信装置」は、「デジタルデータネットワークの第1のデータチャネルを介して、受信装置に、前記符号化ビデオデータを最初に送信するステップであって、前記デジタルデータネットワークはさらに第2のデータチャネルを含み、前記第1のデータチャネルは第1のトランスポートプロトコルを利用し、送信装置から前記受信装置に一方向データ通信を提供し、前記第2のデータチャネルは第2のトランスポートプロトコルを利用し、前記送信装置と前記受信装置との間に双方向データ通信を提供し、前記第1のトランスポートプロトコルは前記第2のトランスポートプロトコルより信頼性が高くない、ステップ」を含むのに対し、引用発明Aの「送信装置」は、当該ステップを含まない点。＜相違点6＞一致点の「ネットワークの状況を監視する」に関し、本願発明の「送信装置」は、「デジタルデータネットワークを監視して、前記送信装置の観点から、前記デジタルデータネットワークの統計に関する第1のネットワークデータを収集するステップであって、前記第1のネットワークデータは第1のネットワーク伝送状態を示し、前記第1のネットワーク伝送状態は第1のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第1の利用可能帯域幅と、第1のラウンドトリップ遅延とのうち少なくとも1つを含む」のに対し、引用発明Aの「送信装置」は、「通知されたパケットのシーケンスナンバーと、ロストしたパケットの個数とから、単位時間あたりのパケットロス率を計算する」点。＜相違点7＞本願発明の「送信装置」は、「前記受信装置から前記第2のデータチャネルを介して送信された再送信要求を受信するステップであって、前記再送信要求は前記受信装置の観点からの前記デジタルデータネットワークの統計に関する第2のネットワークデータを含み、前記第2のネットワークデータは前記受信装置において決定された前記デジタルデータネットワークの第2のネットワーク伝送状態を示し、前記第2のネットワーク伝送状態は第2のエンド・ツー・エンドパケット損失率と、前記デジタルデータネットワークの第2の利用可能帯域幅と、第2のラウンドトリップ遅延とのうち少なくとも1つを含む、ステップ」を含むのに対し、引用発明Aの「送信装置」は、当該ステップを含まない点。＜相違点8＞本願発明の「送信装置」は、「前記第1のネットワークデータを前記第2のネットワークデータで補足するステップ」を含むのに対し、引用発明Aの「送信装置」は、当該ステップを含まない点。＜相違点9＞一致点の「ネットワークの状況を考慮して優先度に従って、受信装置に再送する」に関し、本願発明の「送信装置」は、「前記再送信要求に応じて、補足された前記第1のネットワークデータを考慮して、割り当てられた前記優先度に従って、前記バッファメモリから前記第1及び第2のビデオデータのうち少なくとも1つを回復し、前記第2のデータチャネルを介して前記受信装置に回復したビデオデータを送信するか決定する」のに対し、引用発明Aの「送信装置」は、「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」点。 (3)判断そこで、上記相違点5、7及び8について検討する。本願明細書における「特許文献1は、効率的なアプリケーションレイヤの自動再送要求再送信方法を開示している。・・・サーバ100は、UDP/IPトランスミッタインタフェース140又はTCP/IPトランスミッタ/レシーバインタフェース145の一方と、イーサネット(登録商標)/802.11インタフェース150などのデジタルデータネットワークインタフェースにより、デジタルデータを送信する。最初のリアルタイム送信は、最初の送信160を介してネットワーク110に対して行われ、リアルタイムパケットはキャッシュ/バッファ135に一時的に記憶され、例えば、再送ACK/NACK制御155の受信又は所定のタイムアウトを待つ。」(段落【0006】)、「前掲の特許文献1に開示されたような信頼性の高いメディアプロトコルをベースにしたリアルタイムデータ送信システムをさらに信頼性が高いものにする効率的な方法と装置があれば、有利である。本発明は上記その他の問題を解決するものである。」(段落【0007】)との記載によれば、本願発明は、最初にUDPプロトコルでリアルタイムデータ送信を行い、その後、信頼性の高いTCPプロトコルで再送制御を行うシステムを前提とし、リアルタイムデータ送信システムをさらに信頼性が高く効率的なものにするという課題を解決するために、相違点5、7及び8に係る構成としているものである。一方、刊行物Aの上記ロ.における「前記特許文献1に記載の技術では、受信側は、パケットロスの検知だけではなく、パケットロスが発生した場合にロストしたパケットの重要度を判別して再送要求を行なうか否かの判断を行なう必要があった。このため、受信側の処理負荷が大きくなってしまうという問題点があった。」(段落【0007】)、「本発明は前述の問題点に鑑み、パケットロスが発生した場合に、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうことができるようにすることを目的としている。」(段落【0010】)との記載によれば、引用発明Aは、受信側の処理負荷が大きくならないようにするとともに、トラフィックが増大するのをできるだけ抑制して効率の良い通信を行なうという課題を解決するために、「送信装置(100)」が、「ネットワークの状況に応じて重要度が高いパケットから優先して受信装置に再送する」ものにすぎない。よって、そもそも「送信装置」が「受信装置」にビデオデータを送信するための前提となるシステム構成が相違しており、そのため発明の課題も異なっているから、引用発明Aを相違点5、7及び8のように構成する動機付けが存在しない。したがって、引用発明Aから、本願発明の相違点5、7及び8に係る発明特定事項を導き出すことはできない。よって、本願発明は、上記相違点1?4、6、9について検討するまでもなく、本願発明は、刊行物Aに記載された発明とはいえない。また、引用発明1に基づいて、当業者が容易に発明をすることができたとはいえない。 (4)小括よって、本願発明は、刊行物Aに記載された発明とはいえなくなり、また、引用発明Aに基づいて、当業者が容易に発明をすることができたとはいえなくなった。請求項2は、請求項1に係る発明のカテゴリーを「装置」とした発明であるから、上記(3)と同じ理由により、刊行物Aに記載された発明とはいえなくなり、また、引用発明Aに基づいて当業者が容易に発明をすることができたとはいえなくなった。第5 むすび以上のとおり、原査定の理由によっては、本願を拒絶することはできない。また、他に本願を拒絶すべき理由を発見しない。よって、結論のとおり審決する。
審決日	2016-11-15
出願番号	特願2012-551135(P2012-551135)
審決分類	P 1 8・ 113- WY (H04L) P 1 8・ 121- WY (H04L)
最終処分	成立
前審関与審査官	玉木宏治、森谷哲朗
特許庁審判長	大塚良平
特許庁審判官	萩原義則中野浩昌
発明の名称	再送決定する方法及び装置
代理人	伊東忠重
代理人	伊東忠彦
代理人	大貫進介

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ