【事件の表示】
　特願２００５−２０７８７５「可変ビットレートマルチメディアデータの往復遅延時間測定装置及び方法」拒絶査定不服審判事件〔平成１８年　２月　９日出願公開、特開２００６−　４２３３４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は，平成１７年７月１５日（パリ条約による優先権主張２００４年７月２２日，大韓民国）を出願日とする出願であって，平成１９年６月１１日付け拒絶理由通知に対して，同年８月１６日付け手続補正がなされたが，同年９月１４日付けで拒絶査定がなされ，これに対し，同年１２月１７日に拒絶査定に対する審判請求がなされるとともに，同日付で手続補正がなされたものである。
　
第２　補正について
［補正却下の決定の結論］
　平成１９年１２月１７日付けの手続補正（以下，「本件補正」という。）を却下する。
［理由］
　（１）補正後の本願発明
　本件補正により，平成１９年８月１６日付け手続補正書に記された特許請求の範囲の請求項８である
「可変ビットレートマルチメディアデータ伝送システムにおいて，可変ビットレートマルチメディアデータの往復遅延時間を測定する方法であって，
　受信側からリアルタイム転送制御プロトコル（ＲＴＣＰ）のＲＲパケットを受信することと，
　前記ＲＲパケットと，有効伝送率の変動に基づいた適応力とマルチメディア品質の急激な変化との関係を考慮した加重値とを利用して移動平均往復遅延時間を測定することと，
　前記測定された移動平均往復遅延時間を利用した有効伝送率の推定であって，前記マルチメディアデータの伝送中にチャネル環境の全ての劇的な変化が前記推定された有効伝送率により徐々に反映され得るような推定を実行することと
　を含む，方法。」（以下，この請求項８に記載された発明を「本願発明」という。）は，
「可変ビットレートマルチメディアデータ伝送システムにおいて，可変ビットレートマルチメディアデータの往復遅延時間を測定する方法であって，
　受信側からリアルタイム転送制御プロトコル（ＲＴＣＰ）のＲＲパケットを受信することと，
　前記ＲＲパケットと，
（ｉ）
瞬間往復遅延時間の
対する
速度
（ｉｉ）前記
データ
に基づいて決定される
　前記測定された移動平均往復遅延時間を利用した有効伝送率の推定であって，前記マルチメディアデータの伝送
に対する前記瞬間往復遅延時間の変動の効果
を利用して低減される
　を含む，方法。」（以下，この請求項８に記載された発明を「補正発明」という。）と補正された。
　なお，補正発明中の下線部は，補正された箇所である。
　本件補正は，請求人がその審判請求書で主張しているように，「加重値」と「推定」に関して，補正後の請求項８に記載されている，下線部の構成により限定したものであり，新規な事項を追加するものではなから，これらは，誤記の訂正乃至不明りょうな記載の釈明，特許請求の範囲の限定的減縮を目的とする補正である。
　したがって，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項の規定を満足し，しかも，本件補正により，発明がより限定されたということもできるから，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項に規定する特許請求の範囲の減縮を目的とするものでもある。
　そこで，補正発明が，特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について，以下に検討する。
　
　（２）引用発明
　原査定の拒絶の理由に引用された国際公開第０３／０２６２３２号（以下，「引用文献」という。）には，以下の事項が記載されている。
（ア）「Ｆｉｇｕｒｅ　６　ｉｓ　ａ　ｆｌｏｗ　ｄｉａｇｒａｍ　ｏｆ　ｔｈｅ　ｓｔｅｐｓ　ｐｅｒｆｏｒｍｅｄ　ｂｙ　ｔｈｅ　ｓｅｒｖｅｒ　ｃｏｍｐｕｔｅｒ　４０　ｉｎ　ａｃｃｏｒｄａｎｃｅ　ｗｉｔｈ　ｔｈｅ　ｆｉｒｓｔ　ｅｍｂｏｄｉｍｅｎｔ　ｏｆ　ｔｈｅ　ｐｒｅｓｅｎｔ　ｉｎｖｅｎｔｉｏｎ．Ｆｉｒｓｔｌｙ，ａｔ　ｓｔｅｐ　１０２　ｔｈｅ　ｓｅｎｄｉｎｇ　ｒａｔｅ　ｃａｌｃｕｌａｔｏｒ　４６　ｃａｌｃｕｌａｔｅｓ　ｔｈｅ　ｔｏｔａｌ　ｂａｎｄｗｉｄｔｈ　ａｖａｉｌａｂｌｅ　ｆｏｒ　ｔｈｅ　ｉｎｄｉｖｉｄｕａｌ　ｄａｔａ　ｓｔｒｅａｍｓ　ｗｈｉｃｈ　ａｒｅ　ｔｏ　ｂｅ　ｔｒａｎｓｍｉｔｔｅｄ　ｆｒｏｍ　ｔｈｅ　ｓｅｒｖｅｒ　ｃｏｍｐｕｔｅｒ　４０．Ｔｈｉｓ　ｖａｌｕｅ　ｍａｘ＿ｒａｔｅ　ｒｅｐｒｅｓｅｎｔｓ　ｔｈｅ　ｕｐｐｅｒ　ｌｉｍｉｔ　ｏｎ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｗｈｉｃｈ　ｔｈｅ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅｓ　ｏｆ　ｅａｃｈ　ｓｅｐａｒａｔｅ　ｄａｔａ　ｓｔｒｅａｍ　ｓｈｏｕｌｄ　ｎｏｔ　ｂｅ　ｅｘｃｅｅｄ．Ｔｈｅ　ｖａｌｕｅ　ｍａｘ＿ｒａｔｅ　ｉｓ　ｃａｌｃｕｌａｔｅｄ　ｉｎ　ａｃｃｏｒｄａｎｃｅ　ｗｉｔｈ　ｔｈｅ　ｆｏｌｌｏｗｉｎｇ　ｐｒｉｎｃｉｐｌｅｓ．
　Ｔｙｐｉｃａｌｌｙ，ｐｒｅｖｉｏｕｓ　ｍｕｌｔｉｍｅｄｉａ　ｃｏｎｆｅｒｅｎｃｉｎｇ　ａｐｐｌｉｃａｔｉｏｎｓ　ｐｒｅｓｅｎｔｌｙ　ｕｓｅｄ　ｉｎ　ｔｈｅ　Ｉｎｔｅｒｎｅｔ　ａｒｅ　ｂａｓｅｄ　ｏｎ　ｔｈｅ　ＵＤＰ　ｔｒａｎｓｐｏｒｔ　ｐｒｏｔｏｃｏｌ，ｗｈｉｃｈ　ａｓ　ｐｒｅｖｉｏｕｓｌｙ　ｄｉｓｃｕｓｓｅｄ　ｏｆｆｅｒｓ　ｎｏ　ｑｕａｌｉｔｙ　ｏｆ　ｓｅｒｖｉｃｅ　ｃｏｎｔｒｏｌ　ｍｅｃｈａｎｉｓｍｓ　ａｎｄ　ｉｓ　ｔｈｅｒｅｆｏｒｅ　ｉｎｃａｐａｂｌｅ　ｏｆ　ｐｅｒｆｏｒｍｉｎｇ　ｃｏｎｔｒｏｌ　ａｃｔｉｏｎｓ　ｓｕｃｈ　ａｓ　ａｒｅ　ｒｅｑｕｉｒｅｄ　ｔｏ　ｃｏｍｐｅｎｓａｔｅ　ｆｏｒ，ｆｏｒ　ｅｘａｍｐｌｅ，ｎｅｔｗｏｒｋ　ｃｏｎｇｅｓｔｉｏｎ．Ｔｈｕｓ，ｗｈｅｎ　ｎｅｔｗｏｒｋ　ｃｏｎｇｅｓｔｉｏｎ　ｏｃｃｕｒｓ　ｃｏｍｐｅｔｉｎｇ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎｓ　ｒｅｄｕｃｅ　ｔｈｅｉｒ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅｓ　ａｓ　ｄｅｓｃｒｉｂｅｄ　ｐｒｅｖｉｏｕｓｌｙ　ｗｉｔｈｏｕｔ　ａｎｙ　ｒａｔｅ　ｒｅｄｕｃｔｉｏｎ　ｏｎ　ｂｅｈａｌｆ　ｏｆ　ＵＤＰ　ｔｒａｆｆｉｃ．
　Ｉｎ　ｏｒｄｅｒ　ｔｏ　ｇｅｔ　ａｒｏｕｎｄ　ｔｈｉｓ　ｐｒｏｂｌｅｍ，ｉｎ　ｔｈｅ　ｆｉｒｓｔ　ｅｍｂｏｄｉｍｅｎｔ　ｏｆ　ｔｈｅ　ｐｒｅｓｅｎｔ　ｉｎｖｅｎｔｉｏｎ　ｔｈｅ　ＵＤＰ　ａｕｄｉｏ　ａｎｄ　ｖｉｄｅｏ　ｄａｔａ　ｓｔｒｅａｍｓ　ａｒｅ　ｅｎｈａｎｃｅｄ　ｗｉｔｈ　ａ　ｃｏｎｇｅｓｔｉｏｎ　ｃｏｎｔｒｏｌ　ｓｃｈｅｍｅ　ｏｆ　ｗｈｉｃｈ　ｔｈｅ　ｃａｌｃｕｌａｔｉｏｎ　ｏｆ　ａ　ｍａｘ＿ｒａｔｅ　ｐａｒａｍｅｔｅｒ　ｆｏｒｍｓ　ａ　ｐａｒｔ．Ｍｏｒｅ　ｐａｒｔｉｃｕｌａｒｌｙ，ｔｈｅ　ｐａｒａｍｅｔｅｒ　ｍａｘ＿ｒａｔｅ　ｉｓ　ｃａｌｃｕｌａｔｅｄ　ｔｏ　ｐｒｏｖｉｄｅ　ａ　ｍａｘｉｍｕｍ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｆｏｒ　ａ　ｓｔｒｅａｍ　ｗｈｉｃｈ　ｉｓ　“ＴＣＰ−ｆｒｉｅｎｄｌｙ”，ｂｅｉｎｇ　ａ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｗｈｉｃｈ　ｏｖｅｒ　ｔｉｍｅ　ｉｓ　ａｎａｌｏｇｏｕｓ　ｔｏ　ｔｈｅ　ｔｈｒｏｕｇｈｐｕｔ　ａｃｈｉｅｖｅｄ　ｖｉａ　ａ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎ．
　Ｉｎ　ｔｈｅ　ｆｉｒｓｔ　ｅｍｂｏｄｉｍｅｎｔ，ｔｈｅ　ｔｏｔａｌ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｐａｒａｍｅｔｅｒ　ｍａｘ＿ｒａｔｅ　ｉｓ　ｃａｌｃｕｌａｔｅｄ　ｕｓｉｎｇ　ａ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｆｏｒｍｕｌａ　ｗｈｉｃｈ　ｈａｓ　ｂｅｅｎ　ｄｅｒｉｖｅｄ　ｓｏ　ａｓ　ｔｏ　ｍｏｄｅｌ　ｔｈｅ　ａｖｅｒａｇｅ　ｔｈｒｏｕｇｈｐｕｔ　ｏｖｅｒ　ｔｉｍｅ　ｏｆ　ａ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎ，ａｎｄ　ｔｈｅｒｅｆｏｒｅ　ｔｏｔａｌ　ｒａｔｅ　ｉｓ　ｃａｌｃｕｌａｔｅｄ　ｓｏ　ａｓ　ｔｏ　ｐｒｏｖｉｄｅ　ａ　ＴＣＰ−ｆｒｉｅｎｄｌｙ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ．Ｉｎ　ｔｈｅ　ｆｉｒｓｔ　ｅｍｂｏｄｉｍｅｎｔ　ｗｅ　ｕｓｅ　ｔｈｅ　ｔｒａｎｓｍｉｓｓｉｏｎ　ｒａｔｅ　ｆｏｒｍｕｌａ　ｉｌｌｕｓｔｒａｔｅｄ　ｉｎ　ｅｑｕａｔｉｏｎ　１　ｂｅｌｏｗ
　　ｂｉｔ＿ｒａｔｅ＿ｓｔｒｅａｍ＝ｃ（（ｐａｃｋｅｔ＿ｍｅｄｉｕｍ＿ｓｉｚｅ）／（ＲＴＴ）√（ｌｏｓｓ＿ｒａｔｅ））　　　　Ｅｑ．１
　Ｐｌｅａｓｅ　ｎｏｔｅ　ｔｈａｔ　ｔｈｅ　ｄｅｒｉｖａｔｉｏｎ　ｆｏｒ　ｔｈｅ　ａｂｏｖｅ　ｅｑｕａｔｉｏｎ　ａｐｐｌｉｅｄ　ｔｏ　ａｎ　ｕｂｉｑｕｉｔｏｕｓ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎ　ｃａｎ　ｂｅ　ｆｏｕｎｄ　ｉｎ　Ｆｌｏｙｄ　Ｓ．“Ｃｏｎｎｅｃｔｉｏｎｓ　ｗｉｔｈ　Ｍｕｌｔｉｐｌｅ　Ｃｏｎｇｅｓｔｅｄ　Ｇａｔｅｗａｙｓ　ｉｎ　Ｐａｃｋｅｔ　Ｓｗｉｔｃｈｅｄ　Ｎｅｔｗｏｒｋｓ　Ｐａｒｔ　１：Ｏｎｅ　Ｗａｙ　Ｔｒａｆｆｉｃ”，Ｃｏｍｐｕｔｅｒ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｒｅｖｉｅｗ，　ｖｏｌｕｍｅ　２１，ｎｕｍｂｅｒ　５，Ｏｃｔｏｂｅｒ　１９９１，ｐａｇｅ　３０−４７．
　Ｉｎ　ｔｈｅ　ａｂｏｖｅ　ｅｑｕａｔｉｏｎ　Ｃ　ｉｓ　ａ　ｃｏｎｓｔａｎｔ　ｉｎ　ｔｈｅ　ｒａｎｇｅ　ｏｆ　０．８７　ｔｏ　１．３１，ＲＴＴ　ｉｓ　ｔｈｅ　ｒｏｕｎｄ　ｔｒｉｐ　ｔｉｍｅ　ｉｎ　ｓｅｃｏｎｄｓ　ｂｅｉｎｇ　ａ　ｍｅａｓｕｒｅ　ｏｆ　ｔｈｅ　ｔｉｍｅ　ｉｔ　ｔａｋｅｓ　ｆｏｒ　ａ　ｐａｃｋｅｔ　ｔｏ　ｔｒａｎｓｆｅｒ　ｆｒｏｍ　ａ　ｃｏｍｐｕｔｅｒ，ａｃｒｏｓｓ　ａ　ｎｅｔｗｏｒｋ　ｔｏ　ａｎｏｔｈｅｒ　ｃｏｍｐｕｔｅｒ，ａｎｄ　ｂａｃｋ，ｌｏｓｓ
＿
＿
＿
　Ｅｑｕａｔｉｏｎ　１　ｇｉｖｅｓ　ａ　ｖａｌｕｅ　ｂｉｔ＿ｒａｔｅ＿ｓｔｒｅａｍ　ｗｈｉｃｈ　ｉｓ　ａｎ　ｅｓｔｉｍａｔｅ　ｏｆ　ｔｈｅ　ａｖｅｒａｇｅ　ｂａｎｄｗｉｄｔｈ　ｔｈａｔ　ａ　ｓｉｎｇｌｅ　ＴＣＰ　ｃｏｎｎｅｃｔｉｏｎ　ｗｏｕｌｄ　ａｃｈｉｅｖｅ　ｉｎ　ｔｈｅ　ｐｒｅｓｅｎｔ　ｎｅｔｗｏｒｋ　ｃｏｎｄｉｔｉｏｎｓ．」（第１６頁第２４行〜第１８頁第３行）。
　
仮訳）図６はこの発明の第１の実施例によりサーバ計算機４０により実行される段階の流れ図である。第一に，段階１０２では，送り用レート計算器４６はサーバ計算機４０から送られることになる個々のデータストリームの利用可能な全帯域幅を計算する。この値ｍａｘ＿ｒａｔｅは伝送レート上の上限を表していて，この上限を各別個のデータストリームの伝送レートは越えてはならない。この値ｍａｘ＿ｒａｔｅは次の原理により計算される。
　一般に，以前のマルチメディアコンファレンス適用であって，現在インターネットで使用されているものは，ＵＤＰトランスポートプロトコルに基づいていて，このプロトコルは，以前に論じたように，サービスの品質制御機構を何も提供しておらず，それ故に，例えば網輻輳を補償するのに必要であるような制御動作を実行する能力はない。したがって，網輻輳が発生するときに，競合しているＴＣＰ接続は，ＵＤＰトラヒックに代わっていずれかのレート低減なしに前述したように伝送レートを減じる。
　この問題を回復させるために，この発明の第１の実施例では，ＵＤＰオーディオとビデオとのデータストリームは輻輳制御方式で強化され，ｍａｘ＿ｒａｔｅパラメータの計算は該方式の一部を形成している。特に，パラメータｍａｘ＿ｒａｔｅはストリームについて最大の伝送レートを提供するために計算され，このレートは“ＴＣＰフレンドリィ”であって，伝送レートとなっていて，この伝送レートは時間にわたりＴＣＰ接続を介して達成されたスループットと類推できるものとなっている。
　第１の実施例では，全体の（ｔｏｔａｌ）伝送レートパラメータｍａｘ＿ｒａｔｅが伝送レート式を用いて計算され，この式はＴＣＰ接続の時間にわたる平均スループットをモデル化するように求められて，したがって，全体のレートはＴＣＰフレンドリィな伝送レートを与えるように計算される。第１の実施例では下記の式１で示した伝送レート式を使用している。
　　ｂｉｔ＿ｒａｔｅ＿ｓｔｒｅａｍ＝ｃ（（ｐａｃｋｅｔ＿ｍｅｄｉｕｍ＿ｓｉｚｅ）／（ＲＴＴ）√（ｌｏｓｓ＿ｒａｔｅ））　　　　　（式１）
　上記のユビキタス（ｕｂｉｑｕｉｔｏｕｓ）ＴＣＰ接続に適用される式の導入についてはＦｌｏｙｄ，Ｓ．の“Ｃｏｎｎｅｃｔｉｏｎｓ　ｗｉｔｈ　Ｍｕｌｔｉｐｌｅ　Ｃｏｎｇｅｓｔｅｄ　Ｇａｔｅｗａｙ　ｉｎ　Ｐａｃｋｅｔ　Ｓｗｉｔｃｈｅｄ　Ｎｅｔｗｏｒｋｓ　Ｐａｒｔ１：Ｏｎｅ　Ｗａｙ　Ｔｒａｆｆｉｃ”，Ｃｏｍｐｕｔｅｒ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｒｅｖｉｅｗ，ｖｏｌ．２１，ｎｏ．５，１９９１年１０月，ｐａｇｅ３０〜４７に見いだすことができることに留意されたい。
　上式ではｃは定数であってその範囲は０．８７ないし１．３１であり，ＲＴＴはラウンドトリップ時間（単位秒）であって，これはあるパケットがある計算機からある網をまたいで他の計算機に行きまた戻る転送にかかる時間であり，ｌｏｓｓ
＿
＿
＿
式１はｂｉｔ＿ｒａｔｅ＿ｓｔｒｅａｍ値を与え，この値は単一のＴＣＰ接続が現在の網状態で達成できる平均帯域幅の推定値である。
（イ）「Ｗｉｔｈ　ｒｅｓｐｅｃｔ　ｔｏ　ＲＴＴ，ａｓ　ｍｅｎｔｉｏｎｅｄ　ｐｒｅｖｉｏｕｓｌｙ　ＲＴＴ　ｉｓ　ａ　ｍｅａｓｕｒｅ　ｏｆ　ｔｈｅ　ｔｉｍｅ　ｉｔ　ｔａｋｅｓ　ｆｏｒ　ａ　ｐａｃｋｅｔ　ｔｏ　ｔｒａｖｅｌ　ｆｒｏｍ　ａ　ｃｏｍｐｕｔｅｒ，　ａｃｒｏｓｓ　ａ　ｎｅｔｗｏｒｋ　ｔｏ　ａｎｏｔｈｅｒ　ｃｏｍｐｕｔｅｒ，ａｎｄ　ｂａｃｋ．ＲＴＴ　ｉｓ　ｔｈｅｒｅｆｏｒｅ　ｓｏｍｅｔｈｉｎｇ　ｍｅａｓｕｒｅｄ　ｗｉｔｈｉｎ　ｔｈｅ　ｍｅｔｒｉｃｓ　ｃａｌｃｕｌａｔｏｒ　５６　ａｔ　ｔｈｅ　ｃｌｉｅｎｔ　ｃｏｍｐｕｔｅｒ，ｂｕｔ　ｉｎ　ｏｒｄｅｒ　ｔｏ　ｐｒｅｖｅｎｔ　ｏｓｃｉｌｌａｔｉｏｎｓ　ｉｓ　ｐｒｅｆｅｒａｂｌｙ　ｃａｌｃｕｌａｔｅｄ　ａｓ　ｆｏｌｌｏｗｓ：
　ＲＴＴ＝０．２＊ＲＴＴｓａｍｐｌｅ＋０．８＊ＲＴＴｍｅａｎ　　　Ｅｑｕａｔｉｏｎ　４
　Ｔｈｅ　ｖａｌｕｅ　ＲＴＴｓａｍｐｌｅ　ｉｓ　ｔｈｅ　ｍｏｓｔ　ｒｅｃｅｎｔ　ｍｅａｓｕｒｅ　ｏｆ　ＲＴＴ　ｍｅａｓｕｒｅｄ　ｂｙ　ｔｈｅ　ｍｅｔｒｉｃｓ　ｃａｌｃｕｌａｔｏｒ，ｗｈｅｒｅａｓ　ｔｈｅ　ｖａｌｕｅ　ＲＴＴｍｅａｎ　ｉｓ　ｔｈｅ　ｍｅａｎ　ｖａｌｕｅ　ｏｆ　ａｌｌ　ｐｒｅｖｉｏｕｓ　ｍｅａｓｕｒｅｓ　ｏｆ　ＲＴＴ．」（第２２頁第８〜１８行）
　
仮訳）「ＲＴＴに関しては，前述の通り，ＲＴＴがパケットがある計算器から網をまたいで他の計算機に行って戻ってくる移動にかかる時間の測定値である。ＲＴＴはそれ故にクライアント計算機において測度計算器５６内部で測定された何かであるが，発振（ｏｓｃｉｌｌａｔｉｏｎｓ）防止のために次式で計算されるのが好ましい。
ＲＴＴ＝０．２＊ＲＴＴｓａｍｐｌｅ＋０．８＊ＲＴＴｍｅａｎ　　　　　式４
値ＲＴＴｓａｍｐｌｅは測度計算器によって測定されたＲＴＴの最新の測定値であり，また値ＲＴＴｍｅａｎは以前のＲＴＴの全測定値の平均値である。」　
　
　上記摘記事項（イ）中の「ＲＴＴｓａｍｐｌｅ」は瞬間往復遅延時間のことであり，
同じく「ＲＴＴｍｅａｎ」は以前のＲＴＴの全測定値の平均値であるから，「ＲＴＴ」は一種の平均往復遅延時間を表しており，
摘記事項（イ）の「０．２」は加重値であり，「好ましい」と記載されていることからも明らかなように条件によって当然に適応的に定めるものということができる。
　したがって，上記摘記事項における，平均を加味した往復遅延時間ＲＴＴを求める測定方法，及び図１〜５及び関係記載による装置構成を考慮すると，
　引用文献には，
「可変ビットレートマルチメディアデータ伝送システムにおいて，可変ビットレートマルチメディアデータの往復遅延時間を測定する方法であって，
（ｉ）平均帯域幅の瞬間往復遅延時間の変動に対する適応速度に基づいて決定される加重値とを利用して平均往復遅延時間を測定することと，
　前記測定された平均往復遅延時間を利用した平均帯域幅の推定であって，前記マルチメディアデータの伝送に対する前記往復遅延時間の変動の効果が前記推定された平均帯域幅を利用して低減される推定を実行することと
　を含む，方法。」（以下，「引用発明」という。）が開示されている。
　
　（３）対比
　そこで，補正発明と引用発明とを比較する。
　伝送レート式を用いて表される「平均帯域幅」は，上記摘記事項（ア）の式１と有効伝送率に関する本願の請求項７の数１との比較からも明らかなように，技術的に見て，「有効伝送率」と実質的に同意義のものであるから，
　両者は，
「可変ビットレートマルチメディアデータ伝送システムにおいて，可変ビットレートマルチメディアデータの往復遅延時間を測定する方法であって，
　
　（ｉ）有効伝送率の瞬間往復遅延時間の変動に対する適応速度に基づいて決定される加重値とを利用して平均往復遅延時間を測定することと，
　前記測定された平均往復遅延時間を利用した有効伝送率の推定であって，前記マルチメディアデータの伝送に対する前記瞬間往復遅延時間の変動の効果が前記推定された有効伝送率を利用して低減される推定を実行することと
　を含む，方法。」の点で一致し，以下の点で相違する。
　
（相違点１）　
　補正発明では「受信側からリアルタイム転送制御プロトコル（ＲＴＣＰ）のＲＲパケットを受信すること」を構成要素とし，瞬間往復遅延時間の測定に「ＲＲパケット」を利用しているが，引用発明ではリアルタイム転送制御プロトコル（ＲＴＣＰ），ＲＲパケットを利用しているか不明である。
（相違点２）
　平均往復遅延時間に関して，補正発明では「移動平均往復遅延時間」であるのに対して，引用発明では移動平均でない。
（相違点３）
　加重値の決定に際して，補正発明は「（ｉｉ）前記マルチメディアデータの品質の急激な変化との関係」を考慮しているが，引用発明は前記関係を考慮していない。
　
　（４）判断
　そこで，上記相違点について検討する。
（相違点１）について
　可変ビットレートマルチメディアデータ伝送システムにおいて，受信側からリアルタイム転送制御プロトコル（ＲＴＣＰ）のＲＲパケットを受信し，ＲＲパケットを利用して瞬間往復遅延時間の測定することは，一つの標準的な技術であって，引用文献には顕わに記載されてはいないものの，事実上開示されているに等しいといえる程度のものであって，当業者には周知であり，原審の拒絶理由で引用された特開２００２−８４３３８号公報にも開示されているところである。したがって，引用発明の瞬間往復遅延時間の測定に，リアルタイム転送制御プロトコル（ＲＴＣＰ）のＲＲパケットを利用する程度のことに格別な創意工夫を認めることはできない。
（相違点２）について
　通信トラヒックにおいて，遅延時間の評価手法として，実時間性と，平均性を両立させる手法として，移動平均遅延時間を用いることは，例えば，「情報処理学会研究報告，Ｖｏｌ．２００３，Ｎｏ．１２，ｐｐ１９−２４“トラヒックの長期依存性を考慮したＰａｓｓｉｖｅ計測手法の改善とその効果”小松　忠嗣　他２，２００３．２．７，社団法人　情報処理学会発行」に記載されているように，また，原審の拒絶査定で慣用技術として例示された特開２０００−１０６５５７号公報（段落【００６６】，式８）にも記載されているように，よく知らた周知技術であるから，引用発明のに移動平均の手法を適用する程度のことに格別な技術的困難性を見いだすことはできない。
（相違点３）について
　往復遅延時間（ＲＴＴ）の変動幅が大きいと，マルチメディアデータの伝送ような場合には，とりわけその品質（画質，音質）に急激な変化が生じることは，自明の事項である。
　したがって，引用発明においても，加重値の決定に際して，マルチメディアデータの品質の急激な変化との関係を考慮することは，極めて当然の技術的事項にすぎない。
　
　そして，補正発明に関する作用・効果も，引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　してみると，補正発明は，引用発明及び周知技術に基づいて，当業者が容易に発明することができたものであるから，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものである。
　
　（５）むすび
　以上のとおり，本件補正は，平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので，同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
　（１）平成１９年１２月１７日付けの手続補正は上記のとおり却下されたので，本願の請求項８に係る発明は，平成１９年８月１６日付け手続補正書により補正された特許請求の範囲の請求項８に記載された事項により特定される，上記「第２　補正について」の項中の「（１）補正後の本願発明」の冒頭に記載した「本願発明」のとおりである。
　
　（２）引用発明
　原査定の拒絶の理由に引用された引用文献，及び，その記載事項は，上記「第２　補正について」の項中の「（２）引用発明」に記載したとおりである。
　
　（３）対比・判断
　本願発明は，前記「第２　補正について」の項の「（１）補正後の本願発明」で検討したように，上記補正発明から当該補正に係る構成の限定を省いたものであるから，本願発明の構成要件にさらに限定要件である上記構成を付加したものに相当する補正発明が，上記「第２　補正について」の項中の「（４）判断」に記載したとおり，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである以上，本願発明も，同様の理由により，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　そして，本願発明に関する作用・効果も，引用発明及び周知技術から当業者が予測できる範囲のものである。　
　
第４　むすび
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。