【事件の表示】
　特願２００７−３２９７６６「配信システム、配信方法及びプログラム」拒絶査定不服審判事件〔平成２１年　７月　９日出願公開、特開２００９−１５２９５２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯
　本願は、平成１９年１２月２１日の出願であって、平成２３年１０月２４日付け拒絶理由に対して同年１２月２１日付けで手続補正がなされ、平成２４年１月１９日に拒絶査定された。
　本件は、上記拒絶査定を不服とする平成２４年３月２２日の審判請求である。
　　
２　本願発明
　本願の特許請求の範囲の請求項１ないし１４に係る各発明は、平成２３年１２月２１日付けの手続補正によって補正された特許請求の範囲、明細書及び図面の記載からみて、上記各請求項にそれぞれ記載されるとおりのものと認められるところ、請求項１１に係る発明（以下「本願発明」という。）は次のとおりのものである。
　　
「配信サーバが、端末への情報の配信を、ストリーミング方式で開始するステップと、
　映像配信サーバが、端末から送信された、該端末の再生状態を示す再生状態情報を受信するステップと、
　映像配信サーバが、前記受信された再生状態情報に基づいて、映像をストリーミング方式で配信することが可能であるか否かを判定するステップと、
　映像配信サーバが、前記判定の結果、ストリーミング方式で配信することが可能でないと判定した場合に、ストリーミング方式からダウンロード方式に切り替えて配信するステップ
とを備えたことを特徴とする配信方法。」
　　
３　刊行物発明
　これに対して、原査定の拒絶の理由に引用された特表２００５−５１３８７６号公報（以下「刊行物」という。）には、次のとおり記載されている。
　　
〈技術分野〉
「【０００１】
　本発明は、一般に、データ通信ネットワークの境界を越えて映像ストリームを配信するシステム及び方法に関するものである。」
　　
〈課題を解決するための手段〉
「【０００６】
　本発明の実施例によれば、映像ストリームが符号化される基礎となる１つ以上のパラメータは取得データに基づいて修正されるフレーム解像度を含む。
　【０００７】
　本発明の別の実施例においては、映像ストリームが符号化される基礎となる１つ以上のパラメータは取得データに基づいて修正されるフレーム・レートを有する。」
　　
〈実施例〉
「【００１５】
　図１に表すように、映像サーバ（「ＶＳ」）システム１００はネットワーク２００を通じて映像クライアント（「ＶＣ」）システム３００と通信し合う。ＶＳシステム１００は如何なる：（ａ）１つ以上のパラメータによって映像ストリームを符号化して；（ｂ）ネットワークを通じて別のコンピュータに対して符号化ストリームを送信して；（ｃ）ネットワーク及び他方のコンピュータにおける状態に関するデータを受信して；（ｄ）受信データに基づいて１つ以上のパラメータを修正することによって映像ストリームの符号化を修正する；ことができるコンピュータ・システムをも包含する。
　【００１６】
　本発明の実施例においては、ＶＳシステム１００は映像符号化及び送信（「ＶＥＴ」）システム１１０及び映像符号化制御（「ＶＥＣ」）システム１２０を有する。ＶＥＴシステム１００は上記の符号化及び送信機能を実行することができる如何なるコンピュータ・システムをも包含して、これらの機能を実行するコンピュータ・コードを有し得る。例えば、ＶＥＴシステム１００は、例えば、フレーム解像度及びフレーム・レート、を含む、１つ以上のパラメータによる、例えば、ＭＰＥＧ（動画像符号化専門グループ）及びＨ．２６３、の如何なる既知のフォーマットの映像ストリームをも符号化して、既知の手法、例えば、ＩＰ（インターネット・プロトコル）、ＴＣＰ（伝送制御プロトコル）／ＩＰ、及びＵＤＰ（ユーザ・データグラム・プロトコル）、更には、ストリーミング・データのトランスポートに関するプロトコル、例えば、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）、リアル・タイム・トランスポート・プロトコル（ＲＴＰ）、及びリアル・タイム制御プロトコル（ＲＴＣＰ）、によってネットワーク上で映像ストリームを送信することができるコンピュータ・システムを有し得る。上記の１つ以上のパラメータは、他のコンピュータ・システム、例えば、ＶＥＣシステム１２０、によって修正してアクセスすることができるよう、例えば、メモリにおいて、記憶し得る。
　【００１７】
　ＶＥＣシステム１２０は上記の受信及び修正機能を実行する如何なるコンピュータ・システムをも包含して、それらの機能を実行するコンピュータ・コードを有し得る。（後略）」
　　
「【００１８】
　図２は受信データに対する所定範囲及び所定範囲に相当する所定パラメータ値の例示的表を表す。図２の例においては、表の第１列は利用可能なＣＰＵ（中央処理装置）パワーを、下記のように、所定パーセンテージ範囲として表す。表の第２列は利用可能な所定ＣＰＵパワーのパーセンテージ範囲を表す。したがって、更に以下において説明するように、例えば、受信データが６０％の利用可能なＣＰＵパワーを示す場合、ＶＥＣシステム１２０は３５２ｘ２８８のフレーム解像度が受信データを包含する所定の範囲に相当することを判定するよう図２の表を参照し得る。ＶＥＴシステム１１０が映像ストリームを符号化している現行のフレーム解像度が異なる場合、ＶＥＣシステム１２０はフレーム解像度パラメータを３５２ｘ２８８に修正することによってＶＥＴシステム１１０にそのフレーム解像度で映像ストリームを符号化させる。」
　　
「【００２１】
　ＶＣシステム３００は：（ａ）ネットワークを通じて映像ストリームを受信して利用者に対して表示するよう受信映像ストリームを復号化して；（ｂ）（ｉ）映像ストリームが受信されるネットワークにおける状態及び（ｉｉ）受信される映像ストリームを復号化するのにＶＣシステム３００内部で利用可能なリソースに関するデータを収集して；（ｃ）収集データをＶＣシステム３００によって受信される映像ストリームを送信するコンピュータ・システムに対して送信する；ことができる如何なるコンピュータ・システムをも包含する。ＶＣシステム３００は上記の機能を実行するコンピュータ・コードを有し得る。」
　　
「【００２６】
　図３及び４は本発明が動作し得る一方法を表し、図３はＶＳ１００で行われる動作を表して図４はＶＣ３００で行われる動作を表す。図３によれば、まず、ブロック１０００に表すように、通信がＶＣシステム３００と確立される。例えば、ＶＳシステム１００は、符号化映像をＶＣシステム３００に送信し得るＲＴＰ／ＵＤＰ接続及び診断情報をＶＣシステム３００から受信し得るＲＴＣＰ／ＵＤＰ接続を確立するよう、ＶＣシステム３００と通信し得る。
　【００２７】
　次に、ブロック１０５０に表すように、これから、映像ストリームの一部として符号化及び送信されねばならない、ソース・データがあるかについての判定を行い得る。例えば、ソース・データが生映像の場合、ＶＥＴシステム１１０は生映像を符号化する処理が続いているかについての判定を行い得、更に、ソース・データがＶＳシステム１００によってコード変換される記憶ファイルからの映像データの場合、ＶＥＴシステム１１０はこれから記憶映像ファイルにおいてコード変換しなければならないデータがあるかを判定し得る。
　【００２８】
　ブロック１０５０において表される動作から結果として生じる判定が否定の場合、処理はＶＳシステム１００で終了する。一方、ブロック１０５０において表される動作から結果として生じる判定が正の場合、ブロック１１００、１２００、及び１３００において表される動作が行われる。
　【００２９】
　ブロック１１００において表されるように、映像ストリームが符号化される基礎になる１つ以上のパラメータについて記憶された値が取り出される。例えば、ＶＥＴシステム１１０は各パラメータと関係する記憶位置から１つ以上のパラメータの各々についての値を取り出し得る。次に、ソース・データが１つ以上のパラメータについて取り出された値による映像ストリームに、ブロック１２００において表されるように、符号化される。例えば、ＶＥＴシステム１１０は既知の映像圧縮アルゴリズム、例えば、ＭＰＥＧ又はＨ．２６３、によって、上記の１つ以上のパラメータ、例えば、フレーム解像度及びフレーム・レート、について取り出された値によって、ソース・データを符号化し得る。次に、符号化映像ストリームは、ブロック１３００において表されるように、送信される。例えば、ＶＥＴシステム１１０は符号化映像ストリームを、ネットワーク２００を通じて、ＶＣシステム３００に対して送信し得る。処理は次に、ブロック１０５０において表された動作に戻る。
　【００３０】
　図３に表すように、ブロック１０５０において表された動作から結果として生じる判定が肯定の場合、ブロック１１００、１２００、及び１３００において表された動作に加えて、更に、ブロック１４００、１５００及び１６００において表された動作が行われる。ブロック１４００、１５００、及び１６００において表された動作は同時に、かつ、ブロック１１００、１２００、及び１３００において表された動作とは無関係に、実施し得る。
　【００３１】
　ブロック１４００において表されたように、ＶＣシステム３００から受信されたネットワーク２００又はＶＣシステム３００における状態に関するデータがあるかについての判定が行われる。例えば、ＶＳシステム１００のＶＥＣシステム１２０はＶＣシステム３００から確立されたＲＴＣＰ／ＵＤＰ接続上で受信されたＲＴＣＰパケットを、ネットワーク２００における状態、又は、ＶＣシステム３００から受信されたＲＴＣＰパケットのアプリケーション特有部分における映像ストリームの復号化処理能力に関する、ＶＣシステム３００における状態、に関するＶＣシステム３００からのデータが受信されたかを判定するよう、検査し得る。ブロック１４００に表された動作から結果として生じる判定が否定の場合、処理はブロック１０５０に表された動作に戻る。
　【００３２】
　ブロック１４００において表された動作から結果として生じる判定が肯定の場合、処理はブロック１５００において表された動作に続き、受信データに相当する１つ以上のパラメータの各々についての値が判定される。例えば、ＶＥＣシステム１２０はＶＣシステム３００から受信されたデータを、図２とともに上記に説明したように、受信データの種類についての所定範囲及び所定範囲毎の１つ以上のパラメータの各々についての相当する値を規定する表と、比較し得る。例えば、ＶＣシステム３００から受信されたデータがＶＳシステム１００からＶＣシステム３００に対して現在送信されている映像ストリームを復号化するのにＶＣシステム３００で利用可能なＣＰＵパワーの測定値を表す場合、ＶＥＣシステム１２０はＶＣシステム３００から受信されたデータを図２の表と、受信データを包含する所定の範囲とこの範囲に相当するフレーム解像度パラメータについての値とを判定するよう、比較し得る。例えば、ＶＣシステム３００から受信されたデータがＶＳシステム１００によってＶＣシステム３００に対して送信される映像ストリームを復号化するのにＶＣシステム３００で利用可能なＣＰＵ　パワーが６０％の測定値を示す場合、ＶＥＣシステム１２０は３５２ｘ２８８を、この受信データに相当するフレーム解像度パラメータについての適切な値として、判定する。同様に、ＶＥＣシステム１２０はＶＣシステム３００から受信されたデータに相当する１つ以上のパラメータの各々の値を判定し得る。」
　　
「【００３６】
（前略）利用可能なメモリ及びＣＰＵパワーは、それらのリソースがＶＣシステム３００で用いられて他の目的のために開放されるにつれて、すなわち他のアプリケーション・プログラムがＶＣシステム３００でオープン又はクローズされるにつれて、変動し得ることを特筆する。（後略）」
　　
　上記刊行物に記載の「映像サーバシステム（ＶＳシステム）１００」と「映像クライアントシステム（ＶＣシステム）３００」について
　上記段落【０００１】【００１５】の記載によると、「映像サーバシステム１００」は「映像クライアントシステム３００」へ符号化ストリームを送信（配信）することが記載され、また、上記段落【００１６】の記載によると、符号化ストリームは、ストリーミング・データのトランスポートに関するプロトコルにより送信（配信）することが記載され、また、上記段落【００２６】【００２９】の記載によると、「映像サーバシステム１００」は、符号化映像ストリームを、「映像クライアントシステム３００」へ送信（配信）することが記載ている。
　したがって、映像サーバシステムは、符号化映像ストリームをストリーミング・データとして、映像クライアントシステムへ配信することが記載されているといえる。
　　
　上記刊行物に記載の「受信データ」について
　上記段落【００１５】【００１７】【００１８】【００２１】の記載によると、「受信データ」は利用可能なＣＰＵパワーを表すデータであって、映像サーバシステム１００において受信されるもので、映像クライアントシステム３００から送信されるものである。
　また、上記段落【００３６】の記載によると、利用可能なＣＰＵパワーは、映像クライアントシステム３００において変動することが記載されている。
　したがって、映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータが、映像クライアントシステムから送信され、映像サーバシステムにおいて受信されること記載されているといえる。
　　
　上記刊行物に記載の「ＣＰＵパワー」について
　上記段落【００１８】【００３２】の記載によると、映像サーバシステム１００が受信する受信データが６０％の利用可能なＣＰＵパワーを示す場合、映像サーバシステム１００は、フレーム解像度パラメータは３５２ｘ２８８が適切な値と判定し、現行のフレーム解像度が異なる場合、フレーム解像度パラメータを３５２ｘ２８８に修正したフレーム解像度で映像ストリームを符号化させて送信（配信）することが記載されている。
　すなわち、図２に示されるように、映像サーバシステム１００は、利用可能なＣＰＵパワーが７６％から１００％の場合には、フレーム解像度を６４０ｘ４８０とし、５１％から７５％の場合には、３５２ｘ２８８とし、２６％から５０％の場合には、３２０ｘ２４０とし、０％から２５％の場合には、１７６ｘ１４４とすることが記載されている。
　したがって、映像サーバシステムは、受信されたデータに基づいて、現行のフレーム解像度で配信できるか否かを判定し、現行のフレーム解像度で配信できない場合には、現行のフレーム解像度を変更して、映像クライアントシステムに配信していることが記載されているといえる。
　　
　上記刊行物に記載の「フレーム・レート」について
　上記段落【０００６】【０００７】【００１６】【００２９】の記載によると、映像ストリームが符号化される基礎となるパラメータとして、フレーム解像度やフレーム・レートがある。
　そして、フレーム解像度に関して上記の記載があることを勘案すると、フレーム・レートについてもフレーム解像度と同様の動作が記載されていると認められる。
　　
　したがって、刊行物には、次のとおりの発明（以下「刊行物発明」という。）が記載されていると認められる。
「映像サーバシステムは、符号化映像ストリームをストリーミング・データとして、映像クライアントシステムへ配信し、
　映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータが、映像クライアントシステムから送信され、映像サーバシステムにおいて受信され、
　映像サーバシステムは、受信されたデータに基づいて、現行のフレーム解像度又はフレーム・レートで配信できるか否かを判定し、現行のフレーム解像度又はフレーム・レートで配信できない場合には、現行のフレーム解像度又はフレーム・レートを変更して、映像クライアントシステムに配信する方法」
　　
４　対比
　本願発明と刊行物発明とを対比する。
　　
（１）「配信サーバが、端末への情報の配信を、ストリーミング方式で開始するステップ」
　　
(1-1)「配信サーバ」、「映像配信サーバ」について
　本願明細書全体の記載からみて、「配信サーバ」と「映像配信サーバ」とを区別して説明がなされておらず、主に「映像配信サーバ」についての説明がなされているから、本願発明における「配信サーバ」は「映像配信サーバ」と同意義のものと解釈できる。
　刊行物発明における「映像サーバシステム」は、映像を配信するから、「映像配信サーバ」といえる。
　　
(1-2)「端末」について
　刊行物発明における「映像クライアントシステム」は、「映像サーバシステム」から配信された「符号化映像ストリームをストリーミング・データ」を受け取るものであり、「端末」といえる。
　　
(1-3)「ストリーミング方式」について
　刊行物発明は、「符号化映像ストリームをストリーミング・データとして、映像クライアントシステムへ配信」するものであり、「ストリーミング方式」で配信するものといえる。
　　
(1-4)まとめ
　以上より、刊行物発明は、「配信サーバが、端末への情報の配信を、ストリーミング方式で」するものであり、配信をする際に、配信を開始する必要があることは明らかであるから、「配信する方法」である刊行物発明は、「配信サーバが、端末への情報の配信を、ストリーミング方式で開始するステップ」を備えているといえる。
　　
（２）「映像配信サーバが、端末から送信された、該端末の再生状態を示す再生状態情報を受信するステップ」
　　
　刊行物発明は、「映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータが、映像クライアントシステムから送信され、映像サーバシステムにおいて受信され」るものである。上記(1-2)のとおり、「映像クライアントシステム」は「端末」といえ、本願明細書の段落【００２１】には、「この処理が、再生状態情報取得手段の処理に該当する。具体的には、ＣＰＵ１１０は、携帯端末１００の再生状態を監視して、負荷状態を示す負荷情報（例えば、ＣＰＵ使用率）を検出」と記載されていることをから、「映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータ」は、「端末の再生状態を示す再生状態情報」といえる。
　したがって、「配信する方法」である刊行物発明は、「映像配信サーバが、端末から送信された、該端末の再生状態を示す再生状態情報を受信するステップ」を備えているといえる。
　　
（３）「映像配信サーバが、前記受信された再生状態情報に基づいて、映像をストリーミング方式で配信することが可能であるか否かを判定するステップ」
　　
　刊行物発明においては、「映像サーバシステムは、受信されたデータに基づいて、現行のフレーム解像度又はフレーム・レートで配信できるか否かを判定」するものである。
　上記(1-1)のとおり、「映像サーバシステム」は「映像配信サーバ」といえ、刊行物発明の「受信されたデータ」は、「映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータが、・・・映像サーバシステムにおいて受信され」るものであり、上記（２）のとおり、受信された「端末の再生状態を示す再生状態情報」といえる。
　したがって、「配信する方法」である刊行物発明は、「映像配信サーバが、前記受信された再生状態情報に基づいて、映像を所定のやり方で配信することが可能であるか否かを判定するステップ」を備えているといえる。しかしながら、「所定のやり方で」が、本願発明においては「ストリーミング方式で」あるのに対し、刊行物発明においては「現行のフレーム解像度又はフレーム・レートで」ある点で相違する。
　　
（４）「映像配信サーバが、前記判定の結果、ストリーミング方式で配信することが可能でないと判定した場合に、ストリーミング方式からダウンロード方式に切り替えて配信するステップ」
　　
　刊行物発明は、「映像サーバシステムは、受信されたデータに基づいて、現行のフレーム解像度又はフレーム・レートで配信できるか否かを判定し、現行のフレーム解像度又はフレーム・レートで配信できない場合には、現行のフレーム解像度又はフレーム・レートを変更して、映像クライアントシステムに配信する」ものであり、「現行のフレーム解像度又はフレーム・レートを変更して、映像クライアントシステムに配信する」ことは、「現行のフレーム解像度又はフレーム・レート」から「他のフレーム解像度又はフレーム・レート」に切り替えて、「映像クライアントシステムに配信する」ことといえるから、「映像配信サーバが、前記判定の結果、所定のやり方で配信することが可能でないと判定した場合に、所定のやり方から他のやり方に切り替えて配信するステップ」を備えているといえる。しかしながら、「所定のやり方で」が、本願発明においては「ストリーミング方式で」であるのに対し、刊行物発明においては「現行のフレーム解像度又はフレーム・レートで」である点で相違し、「所定のやり方から他のやり方に切り替えて」が、本願発明においては、「ストリーミング方式からダウンロード方式に切り替えて」であるのに対し、刊行物発明においては、「現行のフレーム解像度又はフレーム・レートを変更」する、すなわち、「現行のフレーム解像度又はフレーム・レートから他のフレーム解像度又はフレーム・レートに切り替えて」である点で相違する。
　　
（５）「配信方法」
　刊行物発明は「配信する方法」であるから、「配信方法」といえる。
　　
（６）一致点、相違点
　以上のとおりであるから、本願発明と刊行物発明との一致点、相違点は次のとおりであると認められる。
　　
〈一致点〉
「配信サーバが、端末への情報の配信を、ストリーミング方式で開始するステップと、
　映像配信サーバが、端末から送信された、該端末の再生状態を示す再生状態情報を受信するステップと、
　映像配信サーバが、前記受信された再生状態情報に基づいて、映像を所定のやり方で配信することが可能であるか否かを判定するステップと、
　映像配信サーバが、前記判定の結果、所定のやり方で配信することが可能でないと判定した場合に、所定のやり方から他のやり方に切り替えて配信するステップ
とを備えたことを特徴とする配信方法。」
　　
〈相違点〉
　本願発明においては、「所定のやり方で」が、「ストリーミング方式で」あり、
　「配信するステップ」における「所定のやり方から他のやり方に切り替えて」が、「ストリーミング方式からダウンロード方式に切り替えて」であるのに対して、
　刊行物発明においては、「所定のやり方で」が、「現行のフレーム解像度又はフレーム・レートで」あり、
　「配信するステップ」における「所定のやり方から他のやり方に切り替えて」が、「現行のフレーム解像度又はフレーム・レートを変更」する、すなわち、「現行のフレーム解像度又はフレーム・レートから他のフレーム解像度又はフレーム・レートに切り替えて」である点。
　　
５　判断
　ここで、原査定の拒絶の理由に引用された特開２００４−２２９１０３号公報（以下「刊行物２」という。）には、次のとおり記載されている。
　　
「【０００１】
【発明の属する技術分野】
本発明はデータ通信ネットワークを利用した画像配信システムに関し、特に、カメラで撮影した動画を様々な性能の通信端末に効率よく配信するためのシステムに関する。
【００１６】
本発明による画像配信と従来の動画配信とを比較すると次のようなことが言える。まず、ストリーム配信では、図２（Ａ）に示したように、多数の動画フレームをストリームの形で連続的に端末に送信する。このようにストリームの形で送信されてくる多数の動画フレームを受け取りながら動画を再生する処理は相当に負荷が大きく、ＣＰＵの性能が低い端末では対応できない。これに対し、本発明による画像配信では、アニメーションＧＩＦやモーションＪＰＥＧ等によるコマ送り式動画の再生、あるいは、複数の静止画像の連続表示という比較的負荷の小さい処理だけで擬似的に動画を再生するものであるため、比較的性能の低いＣＰＵでも十分に動画を再生することができる。
【００１７】
　また、ファイルダウンロードでは、図２（Ｂ）に示したように、一般に極めて大きなサイズの動画ファイルを端末に一括ダウンロードするため、メモリ容量の小さい端末では対応できない。これに対し、本発明に係る画像配信では、一連の動画データをサイズの小さい複数のコマ送り式動画ファイル又は静止画像ファイルに分割して端末に順次送信する。このため、メモリ容量が小さい端末でも個々のコマ送り式動画ファイル又は静止画像ファイルを一つずつサーバから受け取って再生することにより、長時間の動画の再生にも対応できる。」
　　
　上記記載によると、端末へ動画をデータ通信ネットワークを利用して配信する画像配信システムにおいては、多数の動画フレームをストリーム配信する。しかしながら、ストリームの形で送信されてくる多数の動画フレームを受け取りながら動画を再生する処理は相当に負荷が大きく、ＣＰＵの性能が低い端末では対応できないから、端末のＣＰＵの性能が低い端末に、その性能に応じて、コマ送り式動画ファイル、あるいは、静止画像ファイルを配信して、再生させることが記載されている。すなわち、刊行物２には、ＣＰＵの性能が低い端末において、その性能に応じて、コマ送り式動画ファイル、あるいは、静止画像ファイルを配信することが記載されている。
　　
　刊行物発明は、「受信されたデータ（映像クライアントシステムにおいて変動する利用可能なＣＰＵパワーを表すデータ）に基づいて、現行のフレーム解像度又はフレーム・レートで配信できるか否かを判定し、現行のフレーム解像度又はフレーム・レートで配信できない場合には、現行のフレーム解像度又はフレーム・レートを変更して、映像クライアントシステムに配信する」ものであり、ＣＰＵパワーが低下した場合には、現行のフレーム解像度又はフレーム・レートを変更して、配信するものである。
　刊行物発明において、ＣＰＵパワーが低下した場合は、ＣＰＵの性能が低い状態であるから、ＣＰＵパワーが低下した場合の配信は、ＣＰＵの性能が低い端末に対応した配信といえる。上記刊行物２に記載された技術は、ＣＰＵの性能が低い端末に対応した配信技術といえるから、刊行物発明におけるＣＰＵの性能が低い端末に対応した配信に上記刊行物２に記載された技術を適用することは、当業者が容易に着想できることと認められる。
　したがって、刊行物発明に刊行物２に記載された技術を適用して、刊行物発明において、ＣＰＵパワーが低下した場合には、映像のフレーム解像度又はフレーム・レートを変更して配信するのに代えて、コマ送り式動画ファイル、あるいは、静止画像ファイルを配信することは、当業者が容易に想到できることである。
　そして、コマ送り式動画ファイル、あるいは、複数の静止画像ファイルを配信することは、「ダウンロード方式で配信」することといえ、刊行物発明は、「符号化映像ストリームをストリーミング・データとして、映像クライアントシステムへ配信」するものであるから、「ストリーミング方式」で配信するものであり、「現行のフレーム解像度又はフレーム・レート」で配信することも、「ストリーミング方式」で配信することである。
　そうすると、刊行物発明に刊行物２に記載された技術を適用して、「映像のフレーム解像度又はフレーム・レートを変更して配信するのに代えて、コマ送り式動画ファイル、あるいは、静止画像ファイルを配信すること」は、「ストリーミング方式からダウンロード方式に切り替えて配信」することとなり、「現行のフレーム解像度又はフレーム・レートで配信できるか否かを判定」することは、「ストリーミング方式で配信することが可能であるか否かを判定する」こととなる。
　　
　以上のおとり、本願発明の刊行物発明に対する相違点は当業者が容易に想到し得たといえるものである。
　また、本願発明の効果についてみても、当業者が当然に予測し得る程度のものにすぎず、格別顕著なものがあるとはいえない。
　　
６　むすび
　以上のとおり、請求項１１に係る本願発明は、刊行物及び刊行物２に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は他の請求項に係る発明について特に検討するまでもなく拒絶されるべきものである。
　よって、結論のとおり審決する。