【事件の表示】
　特願２００３−５５３８１３「クライアント又はネットワーク環境に基づいて映像ストリームを修正するシステム及び方法」拒絶査定不服審判事件〔平成１５年　６月２６日国際公開、ＷＯ０３／５３０４０、平成１７年　５月１２日国内公表、特表２００５−５１３８７６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
【第１】経緯
　
［１］手続
　本願は、平成１４年１２月１３日（パリ条約による優先権主張平成１３年１２月１５日、米国）を国際出願日とする出願であって、手続の概要は以下のとおりである。
　
　拒絶理由通知　　　　　　　：平成２０年　４月３０日（起案日）
　意見書　　　　　　　　　　：平成２０年１１月１２日
　手続補正（明細書の補正）　：平成２０年１１月１２日
　拒絶査定　　　　　　　　　：平成２１年　９月１８日（起案日）
　拒絶査定不服審判請求　　　：平成２２年　１月２８日
　手続補正（明細書の補正）　：平成２２年　１月２８日
　前置審査報告　　　　　　　：平成２２年　６月２４日
　審尋　　　　　　　　　　　：平成２３年　６月２３日（起案日）
　回答書　　　　　　　　　　：平成２３年１２月２６日
　
［２］査定 
　原査定の理由は、概略、以下のとおりである。 
　
〈査定の理由〉 
　本願の請求項１〜２９に係る各発明は、下記の引用文献１，２，４，５，７に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。 
　
　　　　　　　　　記（引用文献） 
　１．特開２００１−２５０１３号公報
　２．特開平１１−３４１０６３号公報
　３．特開２０００−１０１５３７号公報
　４．特開平１１−２６６２２９号公報
　５．特開２０００−２９５５９７号公報
　６．特開２０００−２２８６７６号公報
　７．特表２０００−５１５６９２号公報
　
【第２】補正の却下の決定　 
　平成２２年１月２８日付けの補正（以下「本件補正」という。）について次のとおり決定する。 
 　 
　《結論》 
 　平成２２年１月２８日付けの補正を却下する。 
　《理由》 
　
【第２-１】本件補正の内容
　本件補正は、特許請求の範囲についてする補正であって、独立請求項である請求項１，１０，１２，１９，２１、２８を補正するものである。
　
　本件補正は、請求項１についてみれば、
　補正前請求項１の「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得する工程」を、
　「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得
し、前記測定値は、利用可能なプロセッサ電力、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、工程
　と補正するものであるところ、
　上記「
プロセッサ電力
　したがって、上記補正は、実質的には、補正前の「コンピュータで利用可能なリソースを表す測定値」について、当該測定値が「
利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む
　
　そして、他の独立請求項である請求項１０，１２，１９，２１、２８についても、実質的に、請求項１についてする上記補正と同様な補正をするものである。
　
　すなわち、本件補正は、補正前請求項１，１０，１２，１９，２１、２８について、実質的に、補正前の「コンピュータで利用可能なリソースを表す測定値」について、当該測定値が「
利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む
　
【第２-２】本件補正の適合性１　補正の範囲（第１７条の２第３項）
　本件補正は、願書に最初に添付した明細書（請求項５，１５，２４，段落0009，0010，0011，0023，0032，0036等）に記載した事項の範囲内においてする補正である。
　
【第２-３】本件補正の適合性２　補正の目的（第１７条の２第４項）
　本件補正は、上記【第２-１】のとおり、請求項１，１０，１２，１９，２１、２８について、実質的に、補正前に記載のあった「コンピュータで利用可能なリソースを表す測定値」を、当該測定値が「
利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む
　また、補正の前後において、産業上の利用分野及び解決しようとする課題は同一である。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項で規定する特許請求の範囲の減縮を目的とする補正に該当する。
　
【第２-４】本件補正の適合性３　独立特許要件（第１７条の２第５項）
　そこで、独立特許要件について検討するに、補正後の請求項１に記載される発明は特許出願の際独立して特許を受けることができない。 
　本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　本件補正後の請求項１に記載される発明が特許出願の際独立して特許を受けることができないとする理由の詳細は、以下のとおりである。 
　
　《理由：独立特許要件に適合しない理由の詳細》
　
［１］補正後発明 
　
　本件補正後の請求項１の記載は、以下のとおりである。
　
　　　　　　　記（請求項１（本件補正後）） 
　「１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：
該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得
し、前記測定値は、利用可能なプロセッサ電力、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、工程
前記１つ以上のパラメータの値を修正する工程であって、該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程を含むことを特徴とする方法。」
　
　上記請求項１の「
利用可能なプロセッサ電力
プロセッサ・パワー
　
　したがって、本件補正後の請求項１に記載された発明（以下「補正後発明」という。）は、
　「１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：
該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得
し、前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、工程
前記１つ以上のパラメータの値を修正する工程であって、該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程を含むことを特徴とする方法。」
　と認められる。
　
［２］引用刊行物の記載の摘示 
　
　特開２０００−２９５５９７号公報（刊行物５）
　
　原査定の拒絶の理由に引用された刊行物である特開２０００−２９５５９７号公報（上記引用文献５に同じ。以下、「刊行物５」という。）には、次に掲げる事項が記載されている。
　注目箇所には、下線を施した。
　
　《特許請求の範囲》
　(K1)「【請求項１】  符号化したメディアデータを受信して復号するメディアデータ受信装置であって、
前記メディアデータ受信装置で受信するメディアデータを送信するメディアデータ送信装置に対して、符号化したメディアデータの復号状況情報を送信することを特徴とするメディアデータ受信装置。
【請求項２】  前記メディアデータ受信装置は、
受信したメディアデータを格納する多バンク構成のバッファを備えることを特徴とする請求項１に記載のメディアデータ受信装置。
【請求項３】略
【請求項４】  符号化したメディアデータを送信する送信装置であって、
前記メディアデータ送信装置から送信するメディアデータを受信して復号するメディアデータ受信装置から送信される復号状況情報に基づき、送信するメディアデータの送信量を変更することを特徴とするメディアデータ送信装置。
【請求項５】  前記メディアデータの復号状況情報は、
復号処理のできなかった受信パケット数情報を含むことを特徴とする請求項１から４に記載のメディアデータ受信またはメディアデータ送信装置。
【請求項６】略
【請求項７】  前記メディアデータの復号状況情報は、
前記受信装置のＣＰＵの負荷状況情報を含む
　
　《技術分野》
　(K2)　「【０００１】
【発明の属する技術分野】この発明は、ＩＰ通信網を介した、マルチメディア符号の実時間伝送系に関する。」
　
　《従来の技術》
　(K3)「【０００２】
【従来の技術】近年、インターネットプロトコル（以下、IPと略す）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行い、遠隔地間でライブ映像を送受信する装置が実用化されている。IPの上位プロトコルとしては、双方向通信に必要な低遅延の伝送を達成するためにしばしばユーザデータグラムプロトコル（以下、UDPと略す）が使用される。この場合は送信データの確実な受信が保証されないが、先進的な送受信装置では、過剰なデータ量や通信帯域の変動に起因する伝送遅延の情報や通信損失の情報などを受信側から送信側へフィードバックすることで、適応的に定常状態を回復する手段がとられる。このようなフィードバック通信のための規格を内包するのが業界の規格の「RTP:A Transport Protocol for Real-Time Application (RFC1889), IETF,1996」である。例えば、文献１では伝送遅延の増減のフィードバック情報を元に、送出データ量を調整している。（文献1：低速回線でのインターネット接続に適したリアルタイムデータの送信レート制御法、信学技報、IN97-101、1997）
文献2は、通信損失を補償するプロトコル上での技術であるが、通信帯域に関する情報のフィードバックだけでなく、
実時間再生に必要な受信装置の資源の変動に関する情報も用いて、送出データを調整する
　
　《解決しようとする課題》
　(K4)「【０００４】
【発明が解決しようとする課題】しかし、以上述べた方法では以下のような問題点があった。
【０００５】受信装置からの周期的なフィードバック情報を元に送信側でマルチメディア符号化の制御を行う既存方式の目的はいずれも通信路の状態の変動を監視するためのものであり、
映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視し、フィードバックする方式は無かった
ソフトウェアによる
復号
資源の変動を逐次に各監視ポイントへ伝える手段が既存の方式では提供されない
【０００６】文献２には、
受信側で再生に使用できる資源の変動
に利用できる資源に応じたデータ
【０００７】また
既存の受信装置は、復号/再生の性能を超えるデータが送信装置から断続的に送られない事を仮定しているが
データ欠落が通信損失によるものかバッファからの溢れによるものかを区別できないという問題がある
　
　〈具体例１、構成〉
　(K5)「【０００９】
【発明の実施の形態】《具体例１》
＜構成＞図１はこの発明の具体例１を示すブロック図を示している。送信装置２０１は、撮影した映像を圧縮符号化してパケット化してＩＰ通信網１０１へ実時間で送信する送信装置全体を示す。
【００１０】ＩＰ通信網１０１は、例えばＬＡＮ回線や高速専用線やISDN回線などで構築され、インターネットプロトコルをサポートする。」
　
　《受信装置３０１》
　(K6)「【００１１】受信装置３０１は送信装置２０１からのパケットをＩＰ通信網１０１を介して受信して符号化方法に対応する復号方法で直ちに復号する受信装置全体を示す。
【００１２】映像取得部２１１は、映像情報量決定部２１５から指示されるスペックで、映像信号をビデオカメラなどから取得し、映像符号化部２１２へ送る。
【００１３】映像符号化部２１２は、映像取得部２１１からの映像信号を予め決められた符号化方式で圧縮符号化して符号データとイントラフラグにし、パケット送信部２１３へ送る。
【００１４】パケット送信部２１３は、映像符号化部２１２からの符号データとイントラフラグをパケット化し、網インターフェイス送信部２１４へ送る。
【００１５】網インターフェイス送信部２１４は、パケット送信部２１３からのパケットをＩＰ通信網１０１を介して、網インターフェイス受信部３１１へ送信し、また、網インターフェイス受信部３１１からの報告パケットを受信して、映像情報量決定部２１５へ送る。
【００１６】
映像情報量決定部２１５は、網インターフェイス送信部２１４からの報告パケットを元に、情報量の変更を映像取得部２１１へ要求する
　
　《送信装置２０１》
　(K7)「【００１７】網インターフェイス受信部３１１は、網インターフェイス送信部２１４からのパケットを受信し、パケット受信部３１２からの要求に答えてパケットをパケット受信部３１２へ送る。また、報告パケット送信部３１６からの報告パケットをＩＰ通信網１０１を介して、網インターフェイス送信部２１４へ送信する。
【００１８】パケット受信部３１２は、網インターフェイス受信部３１１へパケットを要求し、符号バッファ３１３へパケットを送る。符号バッファ３１３は、映像映像復号部３１４へ符号データを送り、逐次取得する受信情報を報告パケット送信部３１６へ知らせる。
【００１９】映像映像復号部３１４は、符号データを復号し、映像信号に変換して映像再生部３１５へ送る。
【００２０】映像再生部３１５は、映像映像復号部３１４からの映像信号を再生する。
【００２１】報告パケット送信部３１６は、パケット受信部３１２からの受信情報をパケット化し、一定の周期で網インターフェイス受信部３１１へ送る。」
　
　〈具体例１，動作〉
　《映像取得部２１１の動作》
　(K8)「【００２２】＜動作＞
映像取得部２１１は、指示通りの映像サイズとフレームレートでデジタル映像を取得する機能を有し、指示に従って動作中途でフレームレートを変更する機能も有する
【００２３】映像取得部２１１は、映像情報量Ｗのデジタル映像信号を映像符号化部２１２へ１フレームずつ映像サイズ情報と共に送る。但し、映像情報量Ｗ＝Ｘ×Ｙ×Ｚで、縦映像サイズＸ画素、横映像サイズＹ画素、Ｚフレーム／秒である。Ｘ，Ｙ，Ｚは映像符号化部２１２が符号化可能な初期値Ｘ０、Ｙ０，Ｚ０を持っており、従って映像情報量Ｗの初期値Ｗ０はＸ０×Ｙ０×Ｚ０で決まる。
【００２４】映像取得部２１１は、映像情報量決定部２１５から別の要求映像情報量Ｖ〓に変更するように指示される毎に映像情報量Ｗを変更し、Ｘ，Ｙ，ＺをＷ＝Ｘ×Ｙ×Ｚを満たしながら更新する。
【００２５】Ｘ，Ｙ，Ｚの更新方法としては、例えば、Ｘ＝Ｘ０，Ｙ＝Ｙ０，Ｚ＝Ｗ／Ｘ／Ｙとする計算式が挙げられ、
この場合は映像サイズは不変で、フレームレートだけが更新される
【００２６】別のＸ，Ｙ，Ｚの更新方法としては、Ｚ＝Ｚ０，Ｘ＾２＝Ｗ×Ｘ０／Ｚ／Ｙ０，Ｙ＾２＝Ｗ×Ｙ０／Ｚ／Ｘ０を満たす計算式が挙げられ、この場合はフレームレートは不変で、映像サイズだけがアスペクト比を保ったまま更新されるが、映像取得部２１１が指示に従って動作中途で映像サイズを変更する機能を有し、映像符号化部２１２が動作中途での映像サイズの変更に対応出来る場合に限った更新方法である。
　《映像符号化部２１２の動作》
　(K9)「【００２７】映像符号化部２１２は映像取得部２１１からの１フレームづつの映像信号を予め決められた符号化方法で符号化し、符号データを作成し、パケット送信部２１３の要求する単位でパケット送信部２１３へ送る。但し、動作中途での映像サイズの変更に対応して、一旦符号化を停止し、新たな映像符号の映像サイズ情報を含む開始コード作成から符号化を再開できる機能を映像符号化部２１２が持つ場合は、映像符号化部２１２は動作途中の映像サイズ変更を監視し、変更に対応する。」
　《パケット送信部２１３の動作》
　(K10)「【００２８】パケット送信部２１３は映像符号化部２１２からの１パケット分の符号データの先頭にパケットヘッダを付加し、パケット化する。パケットヘッダは、例えば、「RFC1889, IETF」にあるRTP基本仕様と「RFC1890, IETF」や「RFC2190, IETF」を一例とする、符号データの符号化方法に応じて決まる関連ペイロード仕様、とに準拠するパケットのヘッダである。１パケット分の符号データは１フレーム相当や数スライス相当や数グループオブブロック相当などであるが、先頭に、復号の同期信号が多重される。同期符号の多重により、パケット損失した際にパケット再送手段が無くても、後続パケットデータの受信及び復号を継続できる。パケットに含まれる符号データが映像データ符号である場合には、パケットヘッダ中には少なくともパケットの通し番号と符号データ長の他に、符号データがフレーム間差分を利用しない符号化方式だけで符号化されたものか否かを示すイントラフラグを記述する。このような符号データの例としては、イントラのフレームを構成する符号やイントラのスライスを構成する符号やイントラのグループオブブロックを構成する符号が挙げられ、例えば、映像符号H.263 (ITU-T) のRTPペイロード規格である「RFC2190, IETF」で規定されるパケットヘッダには、5.1節に 「I Bits」として定義されるフラグがあり、この要件を満たすフラグとして流用できる。イントラフラグは符号データに添付して映像符号化部２１２から送られるイントラフラグ情報から作成する。
【００２９】パケットを作成次第、網インターフェイス送信部２１４へ送信要求を出す。」
　《網インターフェイス送信部２１４の動作》
　(K11)「【００３０】網インターフェイス送信部２１４はパケット送信部２１３から要求されると、網インターフェイス受信部３１１を送信先として、パケット送信部２１３からのパケットをＩＰ通信網１０１へ発信する。
【００３１】網インターフェイス送信部２１４はまた、網インターフェイス受信部３１１からの報告パケットを受信し、映像情報量決定部２１５からの要求に応じて、受信した報告パケットを映像情報量決定部２１５内の指定メモリへコピーする。」
　《映像情報量決定部２１５の動作》
　(K12)「【００３２】映像情報量決定部２１５には網インターフェイス送信部２１４から送られる報告パケットが受信される毎にその内容を映像情報量決定部２１５内のメモリへ取り込まれる。報告パケットには受信装置３０１内における、映像復号部３１４へ送られる送信パケット数Ａとパケット破棄数Ｂと通信損失している損失パケット数Ｃの各々毎秒平均でのデータが含まれる。
【００３３】映像復号部３１４での映像符号の復号に必要な単位時間当たりの演算量は先に定義した映像情報量Ｗに対して単調増加、もしくは、ほぼ比例するという経験則を利用して、送信パケット数Ａと パケット破棄数Ｂと損失パケット数Ｃと現在映像取得部で設定されている 映像情報量Ｗとを元に、 新規の要求映像情報量Ｖを以下の手順で決定する。
【００３４】まず、パケット破棄数Ｂが０であれば、現在は受信装置の復号能力に余裕があるので、Ｖ＝Ｗ＋Ｋとする。Ｋは予め決めた定数でＷ０の数％とする。
【００３５】パケット破棄数Ｂが０でない場合は、現在は受信装置の復号能力に余裕が無いので、映像情報量Ｗを減らす事でこれ以降の映像復号部３１４での映像符号の復号に必要な単位時間当たりの演算量を減らし、復号溢れを低減させる。全ての送信された映像情報量のうち、少なくとも Ｂ/Ａ＋Ｂ＋Ｃで表される割合の情報量が復号できなかったので、Ｖ＝Ｗ−Ｗ ×（Ｂ／（Ａ＋Ｂ＋Ｃ）×Ｄ）とする。ここで、Ｄは急峻な映像情報量の低下を抑えるための定数で、０＜Ｄ＜＝１で、例えば０．５である。
【００３６】いずれの場合も、要求映像情報量Ｖには上限をW0とし、下限はW0の数％である予め決められた定数とするような制限をかる。映像取得部２１１に要求映像情報量Ｖを伝えて映像情報量Ｗを更新させる。
【００３７】起動時に送信装置２０１にとって映像復号部３１４の映像復号能力が未知であっても、何回かの報告パケットの受信により映像情報量Wの設定が最適化されて、
映像復号部３１４の映像復号能力に応じた量の符号データが送信されるようになり、復号溢れが解消される。また、映像復号部３１４の映像復号能力が、中途で変化したときにも、適応的に映像情報量Wの設定が最適化される
　
　《網インターフェイス受信部３１１の動作》
　(K13)「【００３８】網インターフェイス受信部３１１は、通信網１０１からのパケットを待ち受け、内部に存在する図示しないFIFOバッファにパケットを書き込む。また、パケット受信部３１２から受信パケットを要求される度に、FIFOバッファに受信パケットを保持している場合は1パケット分の受信データを符号バッファ３１３の指定メモリへコピーし、保持していない場合は、高々パケット受信部３１２から指定されたタイムアウトの時間まで、次のパケットの受信を待ち受ける。タイムアウト指定が無ければ、次のパケットの受信まで待ち受ける。受信出来たときは1パケット分の受信データを符号バッファ３１３の指定メモリへコピーし、受信出来なかったときは失敗応答をパケット受信部３１２へ返信する。」
　《映像復号部３１４，映像再生部３１５、報告パケット送信部３１６の動作》
　(K14)「【００３９】映像復号部３１４は、符号バッファ３１３からパケットを読み出し、復号する。
【００４０】映像再生部３１５は、映像復号部３１４で復号された１フレーム分の映像信号の再生を繰り返して行う。報告パケット送信部３１６は、報告パケットのデータを作成して、網インターフェイス送信部２１４を送信先として網インターフェイス受信部３１１を通じてＩＰ通信網１０１へ送信する。報告パケットのデータ作成については、具体例３で具体例を示す。」
　《映像取得部２１１の他の構成》
　(K15)「【００４１】本具体例では、映像取得部２１１でフレームレートを変更して映像を取得することとしているが、映像取得部２１１に動的なフレームレート変更の機能が無い場合は、
映像取得部２１１では固定レートとし、映像符号化部２１２において、映像を符号化するフレームレートを変更して符号化を回避するフレームの信号を破棄するという構成にしてもよい
　《効果等》
　(K16)「【００４２】＜効果＞以上のように、具体例１によれば、
復号溢れの程度の情報を映像送信装置へ通知することができる。映像送信装置はこの情報を繰り返し用いることで受信装置での復号が間に合う程度に符号化する映像情報量を調整でき
事前の能力交換不要で、映像再生性能が未知である映像受信装置へ符号の送信を開始できる。また、動作するコンピュータの他のプロセスや他の映像再生装置の状態により、映像受信装置の持つ映像再生性能が接続中途で変わる場合も、同様に映像情報量を調整できる
ソフトウェアによる複数の映像再生装置
刻々と変化しても、動作するコンピュータの性能で再生できる映像情報量の限界での再生が行える効果がある
　
　〈具体例２〉
　(K17)「【００４３】《具体例２》
＜構成＞図２はこの発明の具体例２を示すブロック図を示している。
【００４４】受信装置３０２は１つまたは２つ以上の送信装置からの映像符号パケット及びオーディオ符号パケットを受信して各々の符号化方法に対応する復号方法で直ちに復号する受信装置全体を示す。具体例１と同じ構成には同じ符号を付して説明を省略する。
　・・・（中略）・・・
【００５５】報告パケット送信部３１６は具体例１同様にパケット受信部３２２−ｎおよびパケット受信部３３２−ｎからの受信情報を蓄積する。そして、
予め決められた周期で，単位時間当たりの復号部へ送った送信パケット数Ａと単位時間当たりの復号できなかった破棄パケット数Ｂと単位時間当たりの通信損失された損失パケット数Ｃを記載した報告パケットを映像符号のチャンネルに対してだけ作成し、それぞれに対応する映像送信装置へ送る
【００５６】略
【００５７】＜効果＞以上のように具体例２によれば、ソフトウェアによる複数の映像受信装置やオーディオ受信装置を同時に使用して、復号のための資源を共有しながら多チャネル再生を行う際に、送信装置におけるメディア信号の情報量の変更が困難なオーデイオ符号の再生に必要十分な資源をオーディオ受信装置に優先的に提供し、
残りの資源で再生できる映像情報量の映像符号を映像送信装置へ要求する
　
　〈具体例３〉
　(K18)「【００５８】《具体例３》
＜構成＞図８はこの発明の具体例３を示すブロック図である。マルチタスクOS上で動作し、音声や映像の圧縮符号化され、パケット化された、符号データをＩＰ通信網から受信し、符号化方法に対応する復号方法で直ちに復号する復号装置の一部を示している。具体例１および２と同様の構成には同じ符号を付して説明を省略する。
　・・・（中略）・・・
【００７４】図７は、復号に通常より時間を要するパケットがあったり（復号ジッタ）、想定以上の通信ジッタが発生したために、符号バッファ３１３に未復号のパケットデータが溜まっている非定常な状態の一例を示している。符号バッファ３１３に書き込み可能なバッファが無い場合でも、パケット受信部３１２は網インターフェイス受信部３１１へパケットを要求するため、網インターフェイス受信部３１１内のFIFOバッファが溢れる事はない。受信したが、
復号できずに破棄するパケットの数を正確に把握し、報告する
　・・・（中略）・・・
【００８３】また、
メディア符号の復号が間に合わないときに実行する、受信パケットの破棄
受信パケットの破棄数と通信損失したパケット数を切り分けて検知することが出来る
　
　〈具体例４〉
　(K19)【００８４】《具体例４》
＜構成＞図８はこの発明の具体例４を示すブロック図である。具体例３と同じ構成には同じ符号を付して説明を省略する。具体例３における網インターフェイス受信部３１１とパケット受信部３１２の代わりに、網インターフェイス受信部３４１とパケット受信部３４２を用いる。
　・・・（中略）・・・
【００９２】ステップＳ２０３９では、ローカルメモリに取得したパケットヘッダを読み、この
パケットのパケット通し番号Ｘ
【００９３】まず、現在の i に対して、j= i-1 とし、
前ループで最後に符号バッファ３１３[j-1]へ書き込んだ符号データのパケット通し番号をＬとする。Ｌは前ループでＫとして保存されている。Ｘ＝Ｌ＋１ならば、パケット損失は発生していない
損失した符号データが存在するので、その数を損失パケット数Ｃとして
【００９４】判定が偽と出ればこのパケットの符号データは破棄するものとして、網インターフェイス受信部３４１へこのパケットの符号データをローカルメモリをコピー先に指定して要求し、取得後に破棄し、
復号溢れの回数を破棄パケット数Ｂとして
【００９５】ステップＳ２０４０で、網インターフェイス受信部３４１へこのパケットの符号データを符号バッファ３１３[i-1]をコピー先に指定して要求し、取得する。このとき既に現在のループ中に、ステップＳ２０４０が実行されて符号バッファ３１３[i-1]に符号データが入れられていた場合は、そのデータを上書きしたことになるので、
復号溢れの回数を破棄パケット数Ｂとして
　・・・（中略）・・・
【００９８】ステップＳ２０３５では、網インターフェイス受信部３４１へ受信パケットのコピーを、タイムアウト指定無しで要求する。この際、ローカルメモリをコピー先に指定して、パケットヘッダだけを要求する。ローカルメモリに取得したパケットヘッダを読み、このパケットのパケット通し番号Ｘ及び イントラフラグ Ｚを取り出す。Ｚは符号データの復号にフレーム内符号化方式だけを用いている場合は真、さもなくば偽である。
【００９９】この２つの情報で、このパケットの符号データの復号がメデイア復号部３３４にて正常に行えるかを以下のように判定する。
【０１００】まず、現在の i に対して、j= i-1 とし、前ループで最後に符号バッファ[j-1]へ書き込んだ符号データのパケット通し番号を Ｌ とする。Ｌ は前ループでＫとして保存されている。Ｘ＝Ｌ＋１ならば、パケット損失は発生していないので、正判定を行う。さもなくば、このパケットの符号データと直前にメディア復号部３３４へ渡した符号データの間に欠落した符号データが存在するので、その数を
損失パケット数Ｃとして
【０１０１】判定が偽と出れば
このパケットの符号データは破棄する
復号溢れの回数を破棄パケット数Ｂとして
【０１０２】ステップＳ２０３６で、網インターフェイス受信部３４１へこのパケットの符号データを符号バッファ３１３[i-1]をコピー先に指定して要求し、取得する。
【０１０３】なお、ここで取得したＸをＫとして保存しておく。その後、ステップＳ２０３７へ移る。
【０１０４】ステップＳ２０３７で、 READY信号102-iをメディア復号部３３４へ発信し、
正常な受信回数を送信パケット数Ａとして
　
［３］刊行物に記載された発明（以下、「引用発明」という）
 　 
　（１）刊行物５概要、引用発明認定の対象
　刊行物５には、概要、
　従来の技術−従来の先進的な送受信装置、すなわち、
　近年、実用化されている「インターネットプロトコル（以下、IPと略す）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行い、遠隔地間でライブ映像を送受信する」送受信装置であって、「過剰なデータ量や通信帯域の変動に起因する伝送遅延の情報や通信損失の情報などを受信側から送信側へフィードバックすることで、適応的に定常状態を回復する手段がとられ」ている送受信装置｛前掲(K3)｝
　においても
　・「受信装置からの周期的なフィードバック情報を元に送信側でマルチメディア符号化の制御を行う既存方式の目的はいずれも通信路の状態の変動を監視するためのもの」であって、「映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視し、フィードバックする方式」ではなく｛前掲(K4)｝、
　・「例えば遠隔監視/遠隔支援システムのセンタ装置でソフトウェアによる多チャンネル復号を行う時に、複数の監視ポイント/利用者端末からチャンネルが中途に接続されて同時に復号する映像データのチャネル数が刻々と変動する場合に、資源の変動を逐次に各監視ポイントへ伝える手段が既存の方式では提供されない」｛前掲(K3)｝、
　・「既存の受信装置は、復号/再生の性能を超えるデータが送信装置から断続的に送られない事を仮定しているが、データ欠落が通信損失によるものかバッファからの溢れによるものかを区別できない」｛前掲(K3)｝、
　等の課題があり、
　これらの課題等を解決するものとして、特許請求の範囲（請求項１〜７）記載のもの、及び、実施の形態として具体例１〜４が記載されている。
　
　引用発明認定は、特に、前提となる上記従来技術とその課題、請求項４を引用する請求項５を引用する請求項７、及び具体例１に着目して行う。
　また、補正後発明が「方法」の発明であることから、これと対比する引用発明も「方法」発明として認定することとする。
　
　（２）引用発明の構成
　
　ア　概要構成
　引用発明は、上記従来技術を前提に、その課題を解決しようとするものであることから、
　「インターネットプロトコル（ＩＰ）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行い、遠隔地間で」の「ライブ映像」の送受信に用いられるものであって、
　従来技術の課題−「映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視し」「フィードバック」せず、また、「資源の変動を逐次に各監視ポイントへ伝える手段が提供されず」、「データ欠落が通信損失によるものかバッファからの溢れによるものかを区別できない」等の課題−を解決するために、概要、各請求項記載の構成を採るものといえるところ、
　
　請求項４を引用する請求項５を引用する請求項７は、
　「符号化したメディアデータを送信する送信装置であって、
　前記メディアデータ送信装置から送信するメディアデータを受信して復号するメディアデータ受信装置から送信される復号状況情報に基づき、
　送信するメディアデータの送信量を変更することを特徴とするメディアデータ送信装置。」であって、
　「前記メディアデータの復号状況情報は、復号処理のできなかった受信パケット数情報」及び、「前記受信装置のＣＰＵの負荷状況情報を含む」、
　「メディアデータ送信装置。」
　と記述できるものである。
　
　したがって、引用発明として、概要、　
　ｐ：インターネットプロトコル（ＩＰ）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行い、遠隔地間でのライブ映像の送受信に用いられ、符号化したメディアデータを送信する
方法
　従来技術の課題−映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視しフィードバックせず、また、資源の変動を逐次に各監視ポイントへ伝える手段が提供されず、データ欠落が通信損失によるものかバッファからの溢れによるものかを区別できない等の課題−を解決するためのものであって、
　（→引用発明のＰ）
　ｑ：
符号化したメディアデータ
メディアデータ送信装置
メディアデータ受信装置
復号状況情報
であって
　ｒ：
復号状況情報
復号処理のできなかった受信パケット数情報
受信装置のＣＰＵの負荷状況情報
　ｐ：
方法
　とするものを認めることができ、
　
　この概要構成を基礎として、上記ｑｒの詳細を、以下、発明の詳細な説明記載の具体例（特に具体例１）を参照して引用発明を認定する。
　
　イ　上記ｑの「
符号化したメディアデータ
メディアデータ送信装置
メディアデータ受信装置
　上記概要構成ｑの「
メディアデータ送信装置
　「メディアデータ送信装置」は、「受信装置３０１」に対して「ＩＰ通信網１０１を介して」「映像を圧縮符号化して」「パケット化」した「符号データ」を「実時間で送信する」ものであり、
　上記ｑの「
メディアデータ受信装置
　すなわち、送受信されるｑの「
符号化したメディアデータ
　したがって、
　「ＩＰ通信網を介して映像を圧縮符号化してパケット化した符号データ（メディアデータ）を実時間で送信する
メディアデータ送信装置
メディアデータ受信装置
　を認めることができる。
　
　ウ　上記ｑのメディアデータの送信量の変更、情報量の変更
　
　ウ-１　上記概要構成ｑの「
受信装置
復号状況情報
　送信装置２０１の
映像符号化部２１２において、映像を符号化するフレームレートを
変更
　送信装置２０１（メディアデータ送信装置）として、
　「
受信装置
復号状況情報
映像を符号化するフレームレートを
変更
　を認定することができる。
　
　ウ-２　理由
　そのようなものを認定できるとする理由は、以下の通りである。
　前掲(K6)「【0016】映像情報量決定部２１５は、網インターフェイス送信部２１４からの報告パケットを元に、情報量の変更を映像取得部２１１へ要求する。」，
　前掲(K8)「【0022】＜動作＞映像取得部２１１は、指示通りの映像サイズとフレームレートでデジタル映像を取得する機能を有し、指示に従って動作中途でフレームレートを変更する機能も有する。
【0023】映像取得部２１１は、映像情報量Ｗのデジタル映像信号を映像符号化部２１２へ１フレームずつ映像サイズ情報と共に送る。但し、映像情報量Ｗ＝Ｘ×Ｙ×Ｚで、縦映像サイズＸ画素、横映像サイズＹ画素、Ｚフレーム／秒　である。Ｘ，Ｙ，Ｚは映像符号化部２１２が符号化可能な初期値Ｘ０、Ｙ０，Ｚ０を持っており、従って映像情報量Ｗの初期値Ｗ０はＸ０×Ｙ０×Ｚ０で決まる。
【0024】映像取得部２１１は、映像情報量決定部２１５から別の要求映像情報量Ｖ〓に変更するように指示される毎に映像情報量Ｗを変更し、Ｘ，Ｙ，ＺをＷ＝Ｘ×Ｙ×Ｚを満たしながら更新する。」を踏まえ、
　これを前提に、
　前掲(K15)「【0041】本具体例では、映像取得部２１１でフレームレートを変更して映像を取得することとしているが、映像取得部２１１に動的なフレームレート変更の機能が無い場合は、
映像取得部２１１では固定レートとし、映像符号化部２１２において、映像を符号化するフレームレートを変更して符号化を回避するフレームの信号を破棄するという構成にしてもよい
　送信装置２０１の
映像符号化部２１２において、映像を符号化するフレームレートを
変更
　
　ウ-３　以上イ、ウ-１より、
　「ＩＰ通信網を介して映像を圧縮符号化してパケット化した符号データ（メディアデータ）を実時間で送信する
メディアデータ送信装置
メディアデータ受信装置
　を認めることができる。
　
　エ　上記ｑｒの「メディアデータ受信装置から送信される
復号状況情報
　
　エ-１　
報告パケット
　前掲(K6)(K7)、特に、段落【0015】「網インターフェイス受信部３１１からの報告パケットを受信して、映像情報量決定部２１５へ送る。」、段落【0021】「報告パケット送信部３１６は、パケット受信部３１２からの受信情報をパケット化し、一定の周期で網インターフェイス受信部３１１へ送る。」によれば、
　送信装置２０１は、「一定の周期で」受信装置３０１から「
報告パケット
　当該「
報告パケット
受信装置
復号状況情報
　前掲(K12)段落【0032】の特に「報告パケットには受信装置３０１内における、映像復号部３１４へ送られる送信パケット数Ａとパケット破棄数Ｂと通信損失している損失パケット数Ｃの各々毎秒平均でのデータが含まれる。」によれば、
　「報告パケット」には、
　　(i)送信パケット数Ａ，
　　(ii)パケット破棄数Ｂ，
　　(iii)通信損失している損失パケット数Ｃ
　が含まれるものである。
　そして、これら３つの数に関する、前掲(K17)〜(K19)の記載（特に下線部の記載）、
　前掲(K12)｛特に段落【0033】「映像復号部３１４での映像符号の復号に必要な単位時間当たりの演算量は先に定義した映像情報量Ｗに対して単調増加、もしくは、ほぼ比例するという経験則を利用して、送信パケット数Ａとパケット破棄数Ｂと損失パケット数Ｃと現在映像取得部で設定されている 映像情報量Wとを元に、 新規の要求映像情報量Ｖを以下の手順で決定する。」，【0034】「まず、パケット破棄数Ｂが０であれば、現在は受信装置の復号能力に余裕があるので、Ｖ＝W＋Kとする。Ｋは予め決めた定数でW０の数％とする。」，【0035】「パケット破棄数Ｂが０でない場合は、現在は受信装置の復号能力に余裕が無いので、映像情報量Ｗを減らす事でこれ以降の映像復号部３１４での映像符号の復号に必要な単位時間当たりの演算量を減らし、復号溢れを低減させる。全ての送信された映像情報量のうち、少なくともＢ／Ａ＋Ｂ＋Ｃで表される割合の情報量が復号できなかったので、Ｖ＝Ｗ−Ｗ×（Ｂ／（Ａ＋Ｂ＋Ｃ）×Ｄ）とする。ここで、Ｄは急峻な映像情報量の低下を抑えるための定数で、０＜Ｄ＜＝１で、例えば０．５である。」
　によれば、
　(i)送信パケット数Ａとは、
正常に復号できたパケット数
　(ii)パケット破棄数Ｂとは、復号が間に合わず破棄したパケット数であって、上記概要構成ｒの「
復号処理のできなかった受信パケット数情報
　(iii)通信損失している損失パケット数Ｃとは、
送信装置−受信装置間で失われたパケット数
　
　エ-２　「前記受信装置のＣＰＵの負荷状況情報」
　送信装置２０１は、上記(i)〜(iii)の数Ａ，Ｂ，Ｃの他、復号状況情報として、「
受信装置のＣＰＵの負荷状況情報
　
　エ-３　まとめ
　以上によれば、
メディアデータ送信装置
　「
復号状況情報
受信装置のＣＰＵの負荷状況情報
復号状況情報
　を認定することができる。
　
　オ　上記ｑの「
メディアデータ受信装置
　「
メディアデータ受信装置
　「前記メディアデータの復号状況情報は、前記受信装置のＣＰＵの負荷状況情報を含む」｛(K1)請求項７｝とあり、
　そのような「受信装置」がＣＰＵ（プロセッサ）を備えていることは明らかであり、また、かかるＣＰＵ（プロセッサ）の負荷状況情報が復号状況に影響する情報であることが前提とされていることも明らかであることから、復号がそのＣＰＵ（プロセッサ）を用いてなされるものと、普通に想定されるものである。
　また、受信装置２０１は、「インターネットプロトコル（ＩＰ）通信網に接続されて」いるものであって、上記の数Ａ，Ｂ，Ｃを数値として、また、毎秒の平均値を算出していること｛前掲(K12)｝、
　「
事前の能力交換不要で、映像再生性能が未知である映像受信装置へ符号の送信を開始できる。また、動作するコンピュータの他のプロセスや他の映像再生装置の状態により、映像受信装置の持つ映像再生性能が接続中途で変わる場合も、同様に映像情報量を調整できる
ソフトウェアによる複数の映像再生装置
刻々と変化しても、動作するコンピュータの性能で再生できる映像情報量の限界での再生が行える効果がある
　等も考慮すれば、
　「
メディアデータ受信装置
コンピュータで構成されたもの
　このことは、さらに、「受信装置」に関して、「システムバスの使用率」，「資源の変動」，「残りの資源で再生できる」「ソフトウェアによる・・・復号」等、コンピュータについて使用される特有の用語を用いた記載         −具体的には、
　・前掲(K4)段落【0005】「
映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視し、フィードバックする方式は無かった
ソフトウェアによる
復号
資源の変動を逐次に各監視ポイントへ伝える手段が既存の方式では提供されない
　・「
残りの資源で再生できる映像情報量の映像符号を映像送信装置へ要求する
　がなされていること、からも首肯し得ることである。
　
　以上、「
メディアデータ受信装置
　
　カ　上記ｑのまとめ
　上記エ、オによれば、
　「
メディアデータ受信装置
メディアデータ受信装置
　を認めることができる。
　
　（３）刊行物記載発明（引用発明）
　以上によれば、引用発明として、下記の発明を認定することができる。  
　
　　　　　　　　記（引用発明）
　Ｐ：インターネットプロトコル（ＩＰ）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行い、遠隔地間でのライブ映像の送受信に用いられ、符号化したメディアデータを送信する方法であって、
　従来技術の課題−映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視しフィードバックせず、また、資源の変動を逐次に各監視ポイントへ伝える手段が提供されず、データ欠落が通信損失によるものかバッファからの溢れによるものかを区別できない等の課題−を解決するためのものであって、
　Ｑ：ＩＰ通信網を介して映像を圧縮符号化してパケット化した符号データ（メディアデータ）を実時間で送信するメディアデータ送信装置からの該符号データをＩＰ通信網を介して受信して符号化方法に対応する復号方法で直ちに復号するコンピュータで構成されたメディアデータ受信装置から、送信されるメディアデータの復号状況情報に基づき、映像を符号化するフレームレートを更新変更することで送信するメディアデータの送信量を更新変更するものであって、
　Ｒ：復号状況情報として、正常に復号できたパケット数Ａ，復号が間に合わず破棄したパケット数Ｂ，送信装置−受信装置間で失われたパケット数Ｃ、及び、受信装置のＣＰＵの負荷状況情報を含む復号状況情報を受信する、
　Ｐ：方法
　
［４］補正後発明と引用発明との対比（対応関係）  
　
　（１）補正後発明１（構成要件の分説）
　
　「補正後発明」は、下記のように、大きく３つの要件、
　前提および全体を特定する方法（Ａ）、データを取得する工程（Ｂ）、ラメータの値を修正する工程（Ｃ）、とに分説することができる。
　
　　　　　　記　補正後発明（分説）
　Ａ：１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：
　Ｂ：該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得
し、前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、工程
　Ｃ：前記１つ以上のパラメータの値を修正する工程であって、該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程
　Ａ：を含むことを特徴とする方法。
　
　〈要件Ｂの分説〉
　そして、上記要件Ｂは、さらに、以下の様にB0〜B2に分説することができる。
　B0：該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、
　B1：前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得し、
　B2：前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、
　B0：工程；及び
　
　〈要件Ｃの分説〉
　上記要件Ｃは、さらに、以下の様にC0〜C2に分説することができる。
　C0：前記１つ以上のパラメータの値を修正する工程であって、
　C1：該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、
　C2：前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程
　
　（２）対応関係
　
　ア　要件Ａについて
　Ａ「１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：」
　
　ア-１　配信対象、「ネットワークを通じて配信される映像ストリーム」
　引用発明のＱの「メディアデータ送信装置から」「送信」される「映像を圧縮符号化してパケット化した符号データ（メディアデータ）」は、
　Ｐ「インターネットプロトコル（ＩＰ）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行」う「遠隔地間でのライブ映像 」であって、
　Ｑ「ＩＰ通信網を介して」「実時間で送信」されるものであるところ、
　かかる「送信」は「配信」ともいえ、
　送信されるライブ映像の符号データ｛映像を圧縮符号化してパケット化した符号データ（メディアデータ）｝は「リアルタイム」で「パケット伝送」されるものであるから、「映像ストリーム」ともいい得るものである。
　したがって、引用発明の「メディアデータ送信装置」から送信するライブ映像の符号データ（メディアデータ）も、「ネットワークを通じて配信される映像ストリーム」といい得るものである。
　
　ア-２　「映像ストリームを修正する方法」
　引用発明は、Ｑ「映像を符号化するフレームレートを更新変更することで送信するメディアデータの送信量を更新変更するもの」であるところ、
　「映像ストリーム」と言い得る、「送信するメディアデータ」（「圧縮符号化してパケット化した符号データ」）は、符号化するフレームレートを更新変更すれば、変更前とは異なる「映像ストリーム」、したがって、修正された「映像ストリーム」となるものである。
　したがって、引用発明も「映像ストリームを修正する方法」といい得るものである。
　
　ア-３　（「映像ストリーム」が）「１つ以上のパラメータの値によって符号化され、」
　補正後発明は、C1「該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって
前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む
　「フレーム・レート」を、上記要件Ａの「１つ以上のパラメータ」とするものであるところ、
　上記の通り、引用発明の「映像ストリーム」（メディアデータ）も、Ｑ「符号化するフレームレートを更新変更することで送信するメディアデータの送信量を更新変更するもの」であって、「フレームレート（の値）によって符号化され」ているといい得るものである。
　そして、当該「フレームレート（の値）」は変更することが予定されていて可変できる値であるから、可変できる値によって符号化しているものであり、また、「フレームレート」は、一般に、量子化ステップなどと共に「符号化パラメータ」と扱われるものであることは技術常識である（必要であれば、特開平４−５７４８９号公報（２頁左上欄等）、特開平７−２４０９１５号公報（段落【0015】等）、特開平１１−６９３４９号公報（段落【0021】【0029】等）等参照）ことからすれば、
　引用発明の「映像ストリーム」も、「１つ以上のパラメータの値」といいえる「フレームレート」によって符号化され」ていて、「
映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む
　　
　ア-４　「コンピュータに対してネットワークを通じて配信される」（映像ストリーム）
　引用発明の「映像ストリーム」が配信される「メディアデータ受信装置」は、Ｑ「ＣＰＵ（プロセッサ）を用いて復号等の動作を行うコンピュータで構成されたメディアデータ受信装置」であるから、
　引用発明の映像ストリームも、「コンピュータに対してネットワークを通じて配信される」映像ストリーム、ということができる。
　
　ア-５　まとめ
　以上によれば、引用発明も、Ａ「１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：」といえ、要件Ａにおいて、補正後発明と相違しない。
　
　イ　要件Ｂについて
　B0「該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、」
　B1「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得し、」
　B2「
前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、
　B0「
工程
　
　イ-１　要件Ｂ（B0，B1，B2）の解釈、B2の「測定値」について
　要件B0は、「データを取得する工程」を特定し、その
データ
　(1)該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力に関する
データ
　、及び、
　(2)該映像ストリームを復号化する該コンピュータの処理能力に関する
データ
　の（２種類の）データであることを特定している。
　
　そして、要件B1は、B0の「データを取得する工程」が、
　「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得」することを特定しており、
　要件B2は、さらに、B1で特定した「測定値」が、
　(i)利用可能なプロセッサ・パワー、               
　(ii)関連したパケット喪失、
　(iii)関連した送受信バイト
　のうちの少なくとも何れかを含むことを特定している。
　
　これらの特定事項の解釈について、明細書（発明の詳細な説明）及び図面（下記参照）の記載に照らして検討するに、
　(1)B0で特定する上記(1)の「・・ネットワークの処理能力に関する
データ
　「ネットワークにおける状態に関するＣＲシステム３２０によって収集されるデータの種類は、例えば、ネットワークを通じて現在受信されている映像ストリームに関する、
パケット喪失、送受信バイト、及びビット・エラー・レートを表す測定値
とし、更に詳しくは、「（ａ）ＶＳシステム１００からＶＣシステム３００に対する
ネットワーク２００を通じた映像ストリームの配信に関係したパケット喪失
ネットワーク２００を通じた映像ストリームの配信に関係した
送信されたバイト数
受信されたバイト数
ネットワーク２００を通じた映像ストリームの配信に関係したビット・エラー・レート
　としているのに対して、
　
　(2)B0で特定する上記(2)の「・・コンピュータの処理能力に関する
データ
測定値
　｛後者（ＣＰＵパワーを表す
測定値
総ＣＰＵパワーのパーセンテージとして表された利用可能なＣＰＵパワーを表す測定値
　としていて、
　
　これらのことからすれば、
　・上記(1)該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力に関する
データ
　「
ネットワークを通じた映像ストリームの配信に関係した、パケット喪失、送受信バイト、及びビット・エラー・レート
　と解され、
　・上記(2)該映像ストリームを復号化する該コンピュータの処理能力に関する
データ
　「受信映像ストリームを復号化するのに利用可能なメモリ及びＣＰＵパワーを表す
測定値
　さらに、その後者の「ＣＰＵパワーを表す
測定値
　「
総ＣＰＵパワーのパーセンテージとして表された利用可能なＣＰＵパワーを表す測定値
　と解されるとともに、
　・上記(1)のデータと(2)のデータは、
異なるデータ
ネットワークの処理能力
コンピュータの処理能力
　
　つまり、要件B1で特定される「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値」は、（明細書でいう「
受信映像ストリームを復号化するのに利用可能なメモリ及びＣＰＵパワーを表す測定値
受信されている映像ストリームに関する、パケット喪失、送受信バイト、及びビット・エラー・レートを表す測定値
　
　そうすると、要件B2では、上記のとおり、B1で特定した「測定値」が、
　(i)利用可能なプロセッサ・パワー、               
　(ii)関連したパケット喪失、
　(iii)関連した送受信バイト
　のうちの少なくとも何れかを含む、
　とはしているものの、
　（このように特定すること自体、若干不自然であるものの、少なくとも(i)「利用可能なプロセッサ・パワー」については矛盾なく合理的に理解し得るものであることからすれば、）
　要件B2は、実質的には、（(ii)関連したパケット喪失、と、(iii)関連した送受信バイトは、B1で特定した「・・コンピュータで利用可能なリソースを表す測定値」には含まれ得ないものであるから、）「前記測定値は、利用可能なプロセッサ・パワーを含む」ことを特定するものと解するのが相当というべきであり、
　そして、「利用可能なプロセッサ・パワー」とは、段落【0036】，図２の記載に照らせば、上記のとおり、「
総ＣＰＵパワーのパーセンテージとして表された利用可能なＣＰＵパワー
　要件B2は、実質的には、
　「前記測定値は、利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　
　以上によれば、要件Ｂは、結局、次の事項を特定するもの、と解される。
　
　B0：該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力に関するデータ（
該ネットワークを通じた映像ストリームの配信に関係した、パケット喪失、送受信バイト、及びビット・エラー・レートを含んでいうデータ
　B1’：B0の該コンピュータの処理能力に関するデータは、
　前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値
を含み
　B2：前記測定値は、利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　B0：工程
　
　　　　　　記（要件Ｂに関する、明細書、図面の記載）
【００２１】
　「ＶＣシステム３００は：（ａ）ネットワークを通じて映像ストリームを受信して利用者に対して表示するよう受信映像ストリームを復号化して；（ｂ）（ｉ）
映像ストリームが受信されるネットワークにおける状態
受信される映像ストリームを復号化するのにＶＣシステム３００内部で利用可能なリソースに関するデータを
【００２３】
  「ＣＲシステム３２０は、映像ストリームが受信されて、該映像ストリームを復号化するのにＶＣシステム３００内部で利用可能なリソースが受信される、ネットワークにおける状態に関するデータを収集して、ＶＣシステム３００によって受信される映像ストリームを送信するコンピュータ・システムに対して収集データを送信する、如何なるコンピュータ・システムをも有し得る。ＣＲシステム３２０は、ネットワークにおける条件に関するデータを収集するコンピュータ・コード及び如何なる既知の方法又は手法によってもよいコンピュータ・システム内部で利用可能なリソースに関するデータを有し得る。
ネットワークにおける状態に関するＣＲシステム３２０によって収集されるデータの種類は、例えば、ネットワークを通じて現在受信されている映像ストリームに関する、パケット喪失、送受信バイト、及びビット・エラー・レートを表す測定値、を含む、現在受信されている映像ストリームの、ネットワークを通じた、受信に関する測定値
利用可能なリソースに関するＣＲシステム３２０によって収集されたデータの種類は、例えば、受信映像ストリームを復号化するのに利用可能なメモリ及びＣＰＵパワーを表す測定値
【００３６】
  この判定が肯定の場合、ブロック２１００において表された動作に続き、ここではネットワーク２００における状態及び映像ストリームを復号化するＶＣシステム２００において利用可能なリソースに関するデータが収集される。例えば、ネットワーク２００における状態に関しては、ＣＲシステム３００は、（
ａ）ＶＳシステム１００からＶＣシステム３００に対するネットワーク２００を通じた映像ストリームの配信に関係したパケット喪失
ネットワーク２００を通じた映像ストリームの配信に関係した、ＶＳシステム１００によって送信されたバイト数及びＶＣシステム３００によって受信されたバイト数
ネットワーク２００を通じた映像ストリームの配信に関係したビット・エラー・レート、を表す測定値を含む
利用可能なリソースに関しては
利用可能なＣＰＵパワーを表す測定値を含む
図２の表に表すような、ＣＲシステム３２０及びＶＥＣシステム１２０による総ＣＰＵパワーのパーセンテージとして表された利用可能なＣＰＵパワー
　【図４】２１００で示されるボックスには、「ネットワーク２００における状態及び映像ストリームを復号化するのにＶＣシステム２００において利用可能なリソースに関するデータを収集する」と記載されている。
　【図２】「利用可能なＣＰＵパワー」として、７６％から１００％、５１％から７５％、・・・などと記載されている。
　
　イ-２　B0「該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力に関するデータ（
ネットワークを通じた映像ストリームの配信に関係した、パケット喪失、送受信バイト、及びビット・エラー・レートを
　工程；及び」について
　
　〈(1)ネットワークの処理能力に関する
データ
　引用発明のＱ「メディアデータ送信装置から送信するメディアデータ」が、Ｐ「インターネットプロトコル（ＩＰ）通信網に接続されて、マルチメディアデータ圧縮符号化とパケット伝送をリアルタイムで行」う「遠隔地間でのライブ映像 」であって、かかる「送信」は「配信」といえ、送信されるライブ映像の符号データは「映像ストリーム」といい得るものであること、
　当該映像ストリームが「コンピュータに対してネットワークを通じて配信される」といい得ること、
　は前記のとおりであるところ、
　当該「コンピュータに対して・・・配信」（される）は、「コンピュータに対してトランスポート」（される）ともいい得るものである。
　
　引用発明は、Ｑ「メディアデータ受信装置であって、ＩＰ通信網を介して映像を圧縮符号化して・・・メディアデータ受信装置から、送信されるメディアデータの復号状況情報に基づき、映像を符号化するフレームレートを更新変更することで送信するメディアデータの送信量を変更するもの」であるから、
　引用発明の方法は、「復号状況情報」を取得するものである。
　そして、当該「復号状況情報」は、Ｒ「復号状況情報として、・・・送信装置−受信装置間で失われたパケット数Ｃ」を含むものであるところ、
　当該「送信装置−受信装置間で失われたパケット数Ｃ」は、要件B0の「該映像ストリームを該コンピュータに対してトランスポートする」「
該ネットワークを通じた映像ストリームの配信に関係した、パケット喪失
　引用発明も、「該ネットワークの処理能力に関するデータ（
該ネットワークを通じた映像ストリームの配信に関係した、パケット喪失
　
　〈(2)コンピュータの処理能力に関する
データ
　引用発明は、復号状況情報としての「受信装置のＣＰＵの負荷状況情報」も
取得する
　「ＣＰＵの負荷状況情報」とは、ＣＰＵの総処理能力、すなわち総ＣＰＵパワー、を１００％としたときの負荷によって使用（利用）されている割合で表される情報、が当業者に普通に想定されるものであり、
　その「
ＣＰＵ」は、Ｑ「ＣＰＵ（プロセッサ）を用いて復号等の動作を行うコンピュータで構成されたメディアデータ受信装置」のＣＰＵ
　したがって、引用発明の、復号状況情報としての「受信装置のＣＰＵの負荷状況情報」は、
　補正後発明のB0「該映像ストリームを復号化する該コンピュータの処理能力に関するデータ」ということができるとともに、
　「
該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報
　
　また、引用発明の「受信装置のＣＰＵの負荷状況情報」が１００％、又は１００％に近い状態であれば、復号状況情報として、当該復号するコンピュータ（で構成されたメディアデータ受信装置）に余裕の能力、すなわち余力パワーがないことを示し、逆に、その割合が小さい程、復号状況情報として、当該復号するコンピュータに余力パワー（余裕能力）があることとを示している、つまり、その余力パワー（余裕能力）は、「１００％−負荷状況の割合」で示される、と理解される。
　そして、その余力パワーである「１００％−負荷状況の割合」が、まだ負荷によって
使用（利用）されていない
利用可能なＣＰＵパワー
　したがって、この点からみても、引用発明の「受信装置のＣＰＵの負荷状況情報」は、補正後発明のB0「該映像ストリームを復号化する該コンピュータの処理能力に関するデータ」ということができる。
　
　以上によれば、引用発明も「該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力に関するデータ（
ネットワークを通じた映像ストリームの配信に関係した、パケット喪失
　
　イ-３　上記B0の
データ（該コンピュータの処理能力に関するデータ）を取得する工程
　B1「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得し、」、B2「前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、」について
　
　引用発明の「上記B0の
データ（該コンピュータの処理能力に関するデータ）を取得する工程
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」を取得し、
  とする工程であって、
　上記B1，B2とはいえず、この点、相違が認められる。
　
　この相違点は、上記B1,B2が前記のとおりB1’B2と解されることから、次のようにいうことができる。
　上記B0の
データ（該コンピュータの処理能力に関するデータ
　補正後発明では、
　B1’「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値
を含み
　B2「前記測定値は、利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　ものであるのに対して、
　引用発明では、
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」
　である点。
　
　ウ　要件Ｃについて
　C0「前記１つ以上のパラメータの値を修正する工程であって、」
　C1「該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、」
　C2「前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程」
　
　既に検討した上記ア、イからすれば、引用発明が上記要件C0，C1，C2の工程を備えている、ということができることは明らかである。
　
［５］一致点、相違点  
　
　以上の対比結果によれば、補正後発明と引用発明とは、
 　 
　［一致点］ 
　Ａ　１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：
　B0　該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する
該コンピュータの処理能力に関するデータ
　工程；及び
　Ｃ　前記１つ以上のパラメータの値を修正する工程であって、該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程
　Ａ　を含むことを特徴とする方法
　
　で一致し、
　
　［相違点］
　上記B0の
データ（該コンピュータの処理能力に関するデータ）を取得する工程
　補正後発明では、
　B1：前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値であって、
　B2：前記測定値は、利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む、
　とするのに対して、
　引用発明では、上記B1B2のようにする、とはしてしない点
　
　で相違が認められる。
　
　この相違点が、次のようにも言えることは、前記のとおりである（上記B1,B2が上記B1’B2と解されるから）。
　
　［相違点］
　上記B0の
データ（該コンピュータの処理能力に関するデータ
　補正後発明では、
　B1’「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値
を含み
　B2「前記測定値は、利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　ものであるのに対して、
　引用発明では、
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」
　である点
　
［６］相違点等の判断（容易想到性の判断）  
 　 
（１）相違点の克服  
　引用発明の、B0の
データ（該コンピュータの処理能力に関するデータ
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの
負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵ（プロセッサ）の利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
測定値
　であれば、
　B1’「前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値
を含み
　B2「前記測定値は、利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　とする要件を満たすことになることは明らかであり、そうであれば、上記B1・B2も満たされて、補正後発明と一致する。
　
　したがって、
　引用発明を起点とし、
　引用発明の、B0の
データ（該コンピュータの処理能力に関するデータ
　−「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」−
　を、
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵ（プロセッサ）の利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
測定値
　とすること（以下、［相違点の克服］という）で、
　上記［相違点］は克服されて補正後発明に至る。
　
（２）［相違点の克服］の容易想到性
　引用発明が、復号状況情報として、「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」を取得するのは、
　かかる「負荷状況情報」「に基づき、映像を符号化するフレームレートを更新変更することで送信するメディアデータの送信量を更新変更する」（引用発明Ｑ）ためであるところ、
　より詳しくは、
　「映像受信装置の復号/表示処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視しフィードバック」（引用発明Ｐ）できるようにするためであり、
　また、刊行物５の下記記載から明らかなように、
　送信量を、現在の（その時々での）復号能力・性能に見合う量となるように更新変更するためであり、そのために、
現在の（その時々での）復号能力・再生性能の状態
　そして、「ＣＰＵ（プロセッサ）を用いて復号等の動作を行うコンピュータで構成されたメディアデータ受信装置」の、
現在の（その時々での）復号能力・再生性能の状態
　なぜなら、［４］（２）対応関係　イ-２でも前記したように、ＣＰＵの利用可能な割合％が、例えば、９０％｛負荷状況が１０％（１００％−９０％）｝であれば、現在十分に余力パワーがあって現在利用できる
復号能力・再生性能
復号能力・再生性能
　
　そうすると、引用発明の、「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」に代えて、
　より直接的に、
現在の（その時々での）復号能力・再生性能
　「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵ（プロセッサ）の利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　そして、
現在の（その時々での）復号能力・再生性能
　
　したがって、上記［相違点の克服］は、当業者が容易に想到し得ることである。
　 
　　　　　記（明細書の記載（復号能力、復号に使用できる資源関連）
　(K16)「
映像送信装置はこの情報を繰り返し用いることで受信装置での復号が間に合う程度に符号化する映像情報量を調整でき
事前の能力交換不要で、映像再生性能が未知である映像受信装置へ符号の送信を開始できる。また、動作するコンピュータの他のプロセスや他の映像再生装置の状態により、映像受信装置の持つ映像再生性能が接続中途で変わる場合も、同様に映像情報量を調整できる
ソフトウェアによる複数の映像再生装置
刻々と変化しても、動作するコンピュータの性能で再生できる映像情報量の限界での再生が行える効果がある
　(K3)「
実時間再生に必要な受信装置の資源の変動
　(K4)「
映像受信装置の復号
処理能力やシステムバスの使用率などの資源で復号/再生に使用できる部分の変動を監視し、
資源の変動を逐次に各監視ポイントへ伝える
　「
受信側で再生に使用できる資源の変動
に利用できる資源に応じたデータ
　(K12)「「パケット破棄数Ｂが０であれば、現在は受信装置の
復号能力に余裕がある
　「パケット破棄数Ｂが０でない場合は、現在は受信装置の
復号能力に余裕が無い
　「起動時に送信装置２０１にとって映像復号部３１４の映像復号能力が未知であっても、何回かの報告パケットの受信により映像情報量Wの設定が最適化されて、
映像復号部３１４の映像復号能力に応じた量の符号データが送信されるようになり、復号溢れが解消される。また、映像復号部３１４の映像復号能力が、中途で変化したときにも、適応的に映像情報量Wの設定が最適化される
　
　〈請求人の主張について〉
　請求人は、刊行物５には、パケット喪失及びパケット連結に関する、ネットワークからの報告に応じて、送信符号化画像の情報量を変更することが開示されているものの、
　受信側のコンピュータの何れのパラメータも送信側に送出されることは開示も示唆もされていない旨、主張している。
　
　しかしながら、
　刊行物５には、復号状況情報として、「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵの、総ＣＰＵパワーを１００％としたときの負荷によって使用（利用）されている割合で表される情報」と想定される、「受信装置のＣＰＵの負荷状況情報」を受信することが示されており、
　この情報に代えて、「該映像ストリームを復号化する該コンピュータの、復号化に用いるＣＰＵ（プロセッサ）の利用可能なプロセッサ・パワー（
総ＣＰＵパワーのうちの利用可能な割合
　したがって、上記請求人の主張は採用できない。
　
　なお、請求人は、回答書においては、新たに補正案を提示し、この補正案に基づく補正案発明の進歩性を主張するのみであって、補正後発明（平成２２年１月２８日補正に基づくもの）に基づく主張をするものではなく、採用できない。
　
　（３）まとめ｛相違点等の判断（容易想到性の判断）｝
　補正後発明は、上記刊行物５に記載された発明及び技術常識・周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。
　
［７］まとめ（理由：独立特許要件不適合）
　以上によれば、補正後の請求項１に係る発明は、上記刊行物５に記載された発明及び技術常識・周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができない。
　
  　
【第３】査定の当否（当審の判断）　 
　
［１］本願発明　 
　平成２２年１月２８日付けの補正は上記のとおり却下する。 
　本願の請求項１〜２９に係る各発明は、本願明細書及び図面（平成２０年１１月１２日付けの手続補正書により補正された明細書及び図面）の記載からみて、それぞれ、その特許請求の範囲の請求項１〜２９に記載した事項により特定されるとおりのものと認められるところ、
　その請求項１に係る発明（以下、「本願発明」という。）は下記の通りである。
 　 
　　　　　　記（本願発明（請求項１））
　「１つ以上のパラメータの値によって符号化され、コンピュータに対してネットワークを通じて配信される映像ストリームを修正する方法であって：
該映像ストリームを該コンピュータに対してトランスポートする、該ネットワークの処理能力、及び、該映像ストリームを復号化する該コンピュータの処理能力に関するデータを取得する工程であって、前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値を取得する工程；及び前記１つ以上のパラメータの値を修正する工程であって、該１つ以上のパラメータによって前記映像ストリームが前記取得されたデータに基づいて符号化され、前記１つ以上のパラメータによって前記映像ストリームが符号化される前記１つ以上のパラメータがフレーム・レートを含む、修正する工程を含み、前記修正する工程は、前記取得されたデータに基づいて前記フレーム・レートの値を修正する工程を含むことを特徴とする方法。」
　
［２］引用刊行物の記載、引用発明、対比 
　原査定の拒絶の理由に引用された刊行物である特開２０００−２９５５９７号公報（上記刊行物５に同じ。）には、前記「【第２-４】［３］」で認定したとおりの引用発明が認められ、
　本願発明と引用発明との対応については、前記「【第２-４】［４］補正後発明と引用発明との対応」を援用する。
　
［３］一致点、相違点
　本願発明は、前記補正後発明における「コンピュータで利用可能なリソースを表す測定値」についての、当該測定値が「
利用可能なプロセッサ・パワー、関連したパケット喪失、及び関連した送受信バイトのうちの少なくとも何れかを含む
　したがって、［本願発明と引用発明との一致点］は、前記「【第２−４】［５］」で示した［補正後発明と引用発明との一致点］と同じであり、
　［本願発明と引用発明との相違点］は、前記「【第２−４】［５］」で示した［補正後発明と引用発明との相違点］から上記B2の相違を除いたものである。
　
　すなわち、
　［本願発明と引用発明との一致点］
　　前記［補正後発明と引用発明との一致点］と同じである。
　［本願発明と引用発明との相違点］
　　上記B0の
データ（該コンピュータの処理能力に関するデータ）を取得する工程
　補正後発明では、
　B1：前記コンピュータに対して配信される前記映像ストリームを復号化するために前記コンピュータで利用可能なリソースを表す測定値であって、
　とするのに対して、
　引用発明では、上記B1のようにする、とはしてしない点
　
［４］相違点等の判断（容易想到性の判断）
　上記［本願発明と引用発明と相違点］は、
　引用発明を起点として、前記「【第２−４】［６］（１）」で示した［補正後発明と引用発明との相違点の克服］をすることで克服されるところ、
　［補正後発明と引用発明との相違点の克服］が当業者が容易に想到し得ることであることは、前記「【第２−４】［６］（２）」で理由を付して示したとおりであるから、
　上記［本願発明と引用発明と相違点］も、同じ理由で当業者の容易想到ということができる。
　
［５］まとめ（本願発明）
　本願発明は、上記刊行物５に記載された発明及び技術常識・周知事項に基づいて、当業者が容易に発明をすることができたものである。
　
【第４】むすび　 
　以上のとおりであるから、本願の請求項１に係る発明は、上記刊行物５に記載された発明及び技術常識・周知事項に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本願の他の請求項について特に検討するまでもなく、本願は拒絶をすべきものである。 
　
　よって、結論のとおり審決する。