【事件の表示】
　特願２０１６−　８２６２３「アダプティブ・ストリーミングのマルチパス配信」拒絶査定不服審判事件〔平成２８年　９月　８日出願公開、特開２０１６−１６５１３４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯及び本願発明
１　手続の経緯
　本件出願は、２０１１年（平成２３年）２月１６日（パリ条約による優先権主張外国庁受理２０１０年２月１９日、欧州特許庁）を国際出願日とする特願２０１２−５５３２９７号の一部を平成２８年４月１８日に新たな特許出願としたものであって、その手続の経緯は、以下のとおりである。
　　
　平成２８年　４月２２日：手続補正
　平成２９年　４月１８日：拒絶理由の通知
　平成２９年　７月２１日：手続補正、意見書
　平成３０年　１月２６日：拒絶査定
　平成３０年　２月　６日：拒絶査定の謄本の送達
　平成３０年　６月　１日：拒絶査定不服審判の請求
 　 
２　本願発明
　本願の請求項１〜１５に係る発明は、平成２９年７月２１日付け手続補正により補正された特許請求の範囲の記載からみて、その特許請求の範囲の請求項１〜１５に記載した事項により特定されるとおりのものであるところ、請求項１に係る発明（以下「本願発明」という。）は、次のとおりのものである。
 　 
（本願発明）
（Ａ）少なくとも第１および第２の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法であり、
（Ａ-1）前記少なくとも第１および第２の通信インタフェースのそれぞれが通信アドレスを有し、
（Ａ-2）前記コンテンツが、それぞれが通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能であり、
（Ａ-3）第１の経路が、前記第１の通信インタフェースの通信アドレスおよび前記第１のサーバ通信インタフェースのアドレスによって識別され、
（Ａ-4）少なくとも第２の経路が、前記第２の通信インタフェースの通信アドレスおよび前記少なくとも第２のサーバ通信インタフェースのアドレスによって識別され、
（Ａ-5）前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、
（Ａ-6）前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、
（Ａ-7）チャンクが、時間指標ｉおよび前記対応ビット・レートのうちの１つによって識別され、
（Ａ-8）前記コンテンツが、前記第１および前記少なくとも第２の経路を介して前記クライアント装置から同時にアクセス可能である方法であって、
（Ｂ）前記クライアント装置において、前記第１の経路上の第１の利用可能なビット・レートおよび前記少なくとも第２の経路上の少なくとも第２の利用可能なビット・レートを決定するステップ（Ｓ１）と、
（Ｃ）前記決定した第１の利用可能なビット・レートおよび前記決定した少なくとも第２の利用可能なビット・レートから、前記対応ビット・レートの中から要求ビット・レートを決定するステップ（Ｓ２）と、
（Ｄ）前記時間指標ｉおよび前記決定した要求ビット・レートによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路を介して送信し、前記時間指標ｉによって識別される前記チャンクの少なくとも第２の部分を受信するための少なくとも第２の要求を前記少なくとも第２の経路を介して送信するステップ（Ｓ３）であって、
（Ｄ-1）前記識別される前記チャンクの前記第１の部分および前記第２の部分が相補的であり、
（Ｄ-2）前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれが、前記決定した第１の利用可能なビット・レートおよび前記決定した第２の利用可能なビット・レートから計算されるサイズを有する、
（Ｄ）前記ステップ（Ｓ３）と、
（Ｅ）前記第１の経路を介して前記要求した第１の部分を受信し、前記少なくとも第２の経路を介して前記要求した少なくとも第２の部分を受信するステップ（Ｓ４）と、
（Ａ）を含む、前記方法。
　　
（（Ａ）〜（Ｅ）は、当審で付与した。以下各構成要件を「構成要件Ａ」〜「構成要件Ｅ」という。）
　　
第２　引用文献の記載事項及び引用文献に記載された発明
１　引用文献１
（１）引用文献１の記載事項
　原査定における拒絶の理由に引用された特表２００７-５３５８８１号公報（以下「引用文献１」という。）には、「ストリーミングコンテントの適応レートシフティング装置、システムおよび方法」（発明の名称）に関し、図面と共に次に掲げる事項が記載されている（下線は当審が付与した。）。
　　
「【００３０】
　図１は、本発明に係るストリーミングコンテントの動的なレートシフトを行うシステム１００の一実施例を示す概略ブロック図である。一の実施例では、
システム１００は、コンテントサーバ１０２と、エンドユーザ１０４を具える
コンテントサーバ１０２とエンドユーザ局１０４は、データ通信ネットワークで接続する
【００３１】
　図に示す実施例では、
システム１００は又
ウエブサーバ１１６を具える
エンドユーザ局１０４でそのコンテントを奏するように構成されたクライアントモジュール１１４によって
複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成されて
クライアントモジュール１１４は、複数のウエブサーバ１１６のいずれかからコンテントを要求して受信する
【００３２】
　
図２ａは、コンテントファイル２００
ビデオ
【００３３】
　
図２ｂは、品質の度合いと帯域が変化する複数のストリーム２０２
複数のストリーム２０２は、低品質ストリーム２０４と、中品質ストリーム２０６と、高品質ストリーム２０８を具える
例えば、低品質ストリーム２０４は符号化され、秒当たり１００キロビット（ｋｂｐｓ）のビットレートに圧縮され、中品質ストリーム２０６は符号化され秒当たり２００キロビット（ｋｂｐｓ）のビットレートに圧縮され、及び高品質ストリーム２０８は符号化され秒当たり６００キロビット（ｋｂｐｓ）のビットレートに圧縮されている
【００３４】
　
図２ｃは、複数のストリームレット２１２に分割されたストリーム２１０
ストリームレットとは、コンテントファイル２００の何らかのサイズの部分を意味する
ストリームレット２１２内のコンテントは、ストリーム２１０内に含まれているコンテントの開始に関連する独自の時間インデックスを有する
一の実施例では、各ストリームレット２１２内に含まれるコンテントが２秒の期間を有する
例えば、ストリームレット０は、コンテント再生開始を表す００：００の時間インデックスを有しており、ストリームレット１は、００：０２の時間インデックス、などを有していても良い
　　
「【００３８】
　ストリームレット２１２が一旦受信され、処理されると、
一の実施例では、各ストリームレット２１２内に含まれるコンテントが２秒の期間を有する
例えば、ストリームレット０は、コンテント再生開始を表す００：００の時間インデックスを有しており、ストリームレット１は、００：０２の時間インデックス、などを有していても良い
クライアントモジュール１１４を、複数のウエブサーバ
からストリームレット２１２を取り出すように構成することができる
各ウエブサーバ１１６は、インターネット１０６上の様々な位置に配置することができる
　　
「【００４０】
　
エージェントコントローラモジュール４０２は、ビューワ４０８に送信するストリームレットの品質レベルを選択するように構成されている
エージェントコントローラモジュール４０２は、各要求されたストリームレットの連続的な受信時間の間の時間インターバルの継続的観察に基づいてより低品質、あるいはより高品質ストリームをリクエストする
【００４１】
　エージェントコントローラモジュール４０２は、ビューワ４０８からのユーザコマンドを受信するように構成されている。このようなコマンドには、演奏、早送り、巻戻し、ポーズ、停止が含まれている。一の実施例では、エージェントコントローラモジュール４０２は、ストリームレットキャッシュモジュール４０４からストリームレット２１２を要求し、この受信したストリームレット２１２をステージモジュール４０９で編集する。ステージモジュール４０９は、再生時間を上げるためにストリームレット２１２を編集するように構成することができる。図に示す実施例では、ストリームレット２１２は、０，１，２，３，４、その他の番号がついている。しかしながら、各ストリームレット２１２は、独自のファイル名で同定することができる。」
　　
「【００４５】
　更なる実施例では、
ストリームレットリクエストは、いずれかのストリームレットファイルのリクエスト片を具えていても良い
ストリームレット２１２をより小さな片または部分に分ける
ＴＣＰ／ＩＰ接続
【００４６】
　一の実施例では、クライアントモジュール１１４が、クライアントモジュール１１４とウエブサーバ１１６またはウエブキャッシュとの間で多数のＴＣＰ接続を使用するように構成されている。キャッシュの介入は、クライアントに分かりやすいか、あるいは、クライアントによってフォワードキャッシュとして構成される。
「並列取り出し」と呼ばれるやり方で
ストリームレット２１２の一以上の部分を同時にリクエストする
ＴＣＰ／ＩＰ接続
　　
「【００５０】
　単一のストリームレット２１２リクエストは、全ストリームレット２１２用に発行されるものであってもよく、あるいは、
ストリームレットの各異なる部分について多数リクエストを発行しても良い
　　
「【００５７】
　図７を参照すると、本発明による
適応レートシフティングコンテントストリーミング環境内でストリームレットをリクエストする方法
エージェントコントローラモジュール４０２が
ストリームレットを受信する
エージェントコントローラモジュール４０２は、
リクエストしたストリームレットの受信時間をモニタする
エージェントコントローラモジュール４０２は、各ストリームレット応答についての順次受信した時間の間の時間インターバルΔをモニタする
【００５８】
　ネットワーク行動の特徴は、時に非常に突然に変動するので、所定のΔはどれも別のΔから実質的に変化することがある。この変動を補償するために、
エージェントコントローラモジュール４０２は、再生長さＳのストリームレットについてｎ個のサンプルの窓全域のパフォーマンス率ｒを計算する
【００５９】
　
多数の同時ストリームレットを処理するため、およびパフォーマンス率ｒの代表値をよりよく判定するために、エージェントコントロールモジュール４０２は、相乗平均を計算するかあるいは代替的に、サイズｍの窓全域の等価平均アルゴリズムを計算し、パフォーマンスファクタφを得る
【００６０】
　
再生品質をアップシフトする
かどうかについての方針決定は、φｃｕｒｒｅｎｔをトリガスレッシュホールドΘｕｐと比較することによって開始する
であれば、次により高品質のストリームへのアップシフトが考えられる
であれば、より高品質のストリームの使用が保持可能であると考えられる。より高いストリームレートが保持可能であるかどうかの決定（ステップ７１６）が「ｎｏ」である場合、エージェントコントロールモジュール４０２は、ストリーム品質のアップシフト（ステップ７１７）を試みないであろう。ストリームの終りに達すると（ステップ７１４）、方法６１８が終了する（ステップ７１６）。
【００６１】
　
アップシフト７１０を試みるべきかどうかの決定が「ｎｏ」である場合、ダウンシフトを行うべきかどうかの決定
が行われる
φｃｕｒｒｅｎｔ＞Θｄｏｗｎであれば、ストリーム品質が適当であり、エージェントコントローラモジュール４０２は、ストリーム品質をダウンシフトしない
であれば、エージェントコントロールモジュール４０２は、ストリーム品質をダウンシフトする
　　
「【図１】
」
「【図２ａ】
」
「【図２ｂ】
」
「【図２ｃ】
」　
　
（２）引用文献１に記載された発明
ア　引用文献１には、「ストリーミングコンテントの適応レートシフティング方法」（名称）が記載されている。
　　
イ　段落【００３０】、【００３１】によると、複数のウエブサーバとエンドユーザ局は、データ通信ネットワークで接続されている。また、段落【００４５】、【００４６】によると、接続はＴＣＰ／ＩＰ接続である。
　　
ウ　段落【００３１】によると、エンドユーザ局でそのコンテントを奏するように構成されたクライアントモジュールによって、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成されて、クライアントモジュールは、複数のウエブサーバのいずれかからコンテントを要求して受信する。
　段落【００３２】によると、コンテントはビデオ等である。
エ　段落【００３３】によると、コンテントは、品質の度合いと帯域が変化する複数のストリームを具える。
　複数のストリームは、低品質ストリーム（例えば１００ｋｂｐｓ）、中品質ストリーム（例えば２００ｋｂｐｓ）、高品質ストリーム（例えば６００ｋｂｐｓ）である。
　　
オ　段落【００３４】によると、ストリームは、同じ再生期間を有する複数のストリームレットに分割され、時間インデックスを有する。
　　
カ　段落【００３９】によると、クライアントモジュールはエージェントコントローラモジュールを具え、段落【００５７】によると、エージェントコントローラモジュールは、リクエストしたストリームレットの受信時間をモニタする。段落【００５８】によると、エージェントコントローラモジュールは、再生長さＳのストリームレットについてのｎ個のサンプル窓全域のパフォーマンス率を計算する。
　　
キ　段落【００５９】によると、多数の同時ストリームレットを処理するため、およびパフォーマンス率ｒの代表値をよりよく判定するために、エージェントコントロールモジュール４０２は、相乗平均を計算するかあるいは代替的に、サイズｍの窓全域の等価平均アルゴリズムを計算し、パフォーマンスファクタφを得る。
　　
ク　段落【００６０】〜【００６１】によると、パフォーマンスファクタφにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断する。
　段落【００６１】によると、ストリームの終りに届かない場合、エージェントコントロールモジュールは、判断した再生品質のリクエストを開始して、ストリームレットを受信して、ストリームの終わりまで繰り返す。
　　
ケ　段落【００４５】によると、ストリームレットリクエストはストリームレットのより小さい部分としてもよく、段落【００４６】によると、「並列取り出し」と呼ばれるやり方で、同時にストリームレットあるいはストリームレットの部分をリクエストすることが記載されている。
　したがって、上記ア〜クにおける「ストリームレット」を「ストリームレットの部分」と置き換えた発明が記載されていると認められる。
　　
コ　以上まとめると、引用文献１には、次の発明（以下「引用発明」という。）が記載されていると認められる。
　　
（引用発明）
（ａ）複数のウエブサーバとエンドユーザ局はデータ通信ネットワークで接続し、エンドユーザ局でコンテントを奏するように構成されたクライアントモジュールによって、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成され、クライアントモジュールは、ＴＣＰ／ＩＰ接続された複数のウエブサーバにビデオ等のコンテントを要求して受信する方法であり、
（ａ-1）コンテントが品質の度合いと帯域が変化する複数のストリームを具え、複数のストリームは、低品質ストリーム（例えば１００ｋｂｐｓ）、中品質ストリーム（例えば２００ｋｂｐｓ）、高品質ストリーム（例えば６００ｋｂｐｓ）であり、
（ａ-2）ストリームは、同じ再生期間を有する複数のストリームレットに分割され、時間インデックスを有し、ストリームレットはさらにより小さい部分に分割され、
（ａ-3）「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する方法であって、
（ｂ）エンドユーザ局のエージェントコントローラモジュールは、リクエストしたストリームレットの部分の受信時間をモニタし、ストリームレットの部分についてのパフォーマンス率を計算し、
（ｃ）多数の同時ストリームレットの部分を処理するため、およびパフォーマンス率ｒの代表値をよりよく判定するために、パフォーマンスファクタを得、
　パフォーマンスファクタにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断し、
（ｄ）ストリームの終りに届かない場合、エージェントコントロールモジュールは、判断した再生品質のリクエストを開始して、ストリームレットの部分を受信して、ストリームの終わりまで繰り返す
（ａ）方法。
　　
　なお、（ａ）〜（ｄ）は、構成を識別するために付与した。以下各構成を「構成ａ」〜「構成ｄ」という。
　　
３　引用文献２
（１）引用文献２の記載事項
　原査定における拒絶の理由に引用された特開２００６−２４４０５４号公報（以下「引用文献２」という。）には、図面と共に次に掲げる事項が記載されている。
　　
「【０２１５】
　例えば、図５に示すコンテンツデータのうち、セグメント７１−１のダウンロードが終了しており、セグメント７１−２乃至セグメント７１−６のダウンロードが終了していない場合、算出部２５３は、ノード情報および受信履歴を参照して、セグメント７１−２乃至セグメント７１−６のそれぞれを、ノード情報に含まれている、送信ノードとしてのサーバ５２の数によって示される数に分割する。
【０２１６】
　例えば、ノード情報に含まれている、送信ノードとしてのサーバ５２の数が“２”である場合、算出部２５３は、セグメント７１−２乃至セグメント７１−６を、それぞれ２つのパートに分割する。このとき、パートの大きさは、例えば、受信履歴に含まれている、パートのダウンロード速度を基に、式（４）を計算して定める。
【０２１７】
　Ｐｉ＝Ｖｉ×Ｄ／（ΣＶｉ）　　　　　　　　　　　　　　・・・（４）
【０２１８】
　ここで、Ｐｉは、サーバ５２−ｉ（但し、１≦ｉ≦Ｎ）に割り当てるパートの大きさを示しており、Ｖｉは、前回、サーバ５２−ｉからダウンロードしたパートのダウンロード速度を示している。また、Σは、ｉを１からＮに変えてのＶｉの和（合計）をとることを表し、Ｄは、セグメントの大きさを示す。
【０２１９】
　したがって、例えば、図５に示すセグメント７１の大きさが2300KBであり、パート１１１−１のサーバ５２−１からのダウンロード速度が“3Mbps”であり、パート１１２−１のサーバ５２−２からのダウンロード速度が“2Mbps”であり、さらに、セグメント７１−２乃至セグメント７１−６を、それぞれ、パート１１１−２乃至パート１１１−６、およびパート１１２−２乃至パート１１２−６に分割して、パート１１１−２乃至パート１１１−６をサーバ５２−１からダウンロードし、パート１１２−２乃至パート１１２−６をサーバ５２−２からダウンロードする場合、パート１１１−２乃至パート１１１−６のそれぞれの大きさは、式（４）から、1380KB（３×２３００／（２＋３））と算出される。
【０２２０】
　そして、算出部２５３は、セグメント７１−２乃至セグメント７１−６をそれぞれ分割すると、パート１１１の送信を、サーバ５２−１に割り当て、パート１１２の送信を、サーバ５２−２に割り当てる。そして、算出部２５３は、パート１１１−２を特定するための割り当て情報、およびパート１１２−２を特定するための割り当て情報を、それぞれ生成する。算出部２５３は、生成したパート１１１−２を特定するための割り当て情報を、通信制御部１８３−１に供給し、パート１１２−２を特定するための割り当て情報を、通信制御部１８３−２に供給する。」
　　
「【図５】
」
　　
第３　対比
１　対比
　本願発明と引用発明とを対比する。
（１）構成要件Ａと構成ａとを対比する。
　構成ａの「エンドユーザ局」は構成要件Ａの「クライアント装置」に相当する。
　構成ａの「データ通信ネットワークを介して複数のウエブサーバにＴＣＰ／ＩＰ接続されたエンドユーザ局」は、「複数のウエブサーバにＴＣＰ／ＩＰ接続」されているから、「少なくとも第１および第２の通信インタフェースを含む」といえる。
　また、構成ａの「ビデオ等のコンテント」は、「レンダリングされるコンテンツ」といえる。
　さらに、構成ａの「エンドユーザ局でコンテントを奏するように構成されたクライアントモジュールによって、・・・ＴＣＰ／ＩＰ接続された複数のウエブサーバにビデオ等のコンテントを要求して受信する方法」は、「クライアント装置においてレンダリングされるコンテンツを提供する方法」といえる。
　したがって、構成要件Ａと構成ａとは、「少なくとも第１および第２の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法」として一致する。
　　
（２）構成要件Ａ-1と構成ａとを対比する。
　構成ａの「エンドユーザ局」は、「ＴＣＰ／ＩＰ接続」されているから、「通信アドレス」を有することは明らかである。
　したがって、構成要件Ａ-1と構成ａとは、前記少なくとも第１および第２の通信インタフェースのそれぞれが通信アドレスを有する」として一致する。
　　
（３）構成要件Ａ-2と構成ａ、ａ-3とを対比する。
　「クライアント装置」に相当する「エンドユーザ局」が「それぞれが通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェース」を有することは上記（２）のとおりであり、構成ａ-3のとおり、エンドユーザ局は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」から、構成ａ、ａ-3は、「前記コンテンツがそれぞれが通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能」であるといえる。
　したがって、構成要件Ａ-2と構成ａ、ａ-3は、「前記コンテンツが、それぞれが通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能である」として一致する。
　　
（４）構成要件Ａ-3、Ａ-4と構成ａとを対比する。
　構成ａにおいては、データ通信ネットワークを介して複数のウエブサーバにＴＣＰ／ＩＰ接続されたエンドユーザ局がコンテントを受信するから、１つのウエブサーバとエンドユーザ局の通信の経路は、第１の経路といえ、ＴＣＰ／ＩＰ接続においては、それぞれのアドレスにより通信が行われるから、「第１の経路が、前記第１の通信インタフェースの通信アドレスおよび前記第１のサーバ通信インタフェースのアドレスによって識別され」といえる。
　同様に他のウエブサーバとエンドユーザ局の通信の経路は、第２の経路といえ、「第２の経路が、前記第２の通信インタフェースの通信アドレスおよび前記第２のサーバ通信インタフェースのアドレスによって識別され」といえる。
　したがって、構成要件Ａ-3、Ａ-4と構成ａとは、「第１の経路が、前記第１の通信インタフェースの通信アドレスおよび前記第１のサーバ通信インタフェースのアドレスによって識別され、少なくとも第２の経路が、前記第２の通信インタフェースの通信アドレスおよび前記少なくとも第２のサーバ通信インタフェースのアドレスによって識別される」として一致する。
　　
（５）構成要件Ａ-5と構成ａ-1とを対比する。
　構成要件a-3によると、コンテントが３つの品質の異なるストリームからなり、異なるビットレートを有するから、構成要件ａ-3は、「前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能である」として、構成要件Ａ-5と一致する。
　　
（６）構成要件Ａ-6と構成ａ-2とを対比する。
　構成ａ-2の「ストリームレット」はデータの塊であるから「チャンク」といえる。構成ａ-1によると、ストリームは複数あるから、構成ａ-2は、「前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割される」として、構成要件Ａ-6と一致する。
　　
（７）構成要件Ａ-7と構成ａ-2とを対比する。
　構成ａ-2の「時間インデックス」は、構成要件Ａ-7の「時間指標ｉ」に相当する。
　したがって、構成要件Ａ-7と構成ａ-2とは、「チャンクが、時間指標ｉおよび前記対応ビット・レートのうちの１つによって識別される」として一致する。
　　
（８）構成要件Ａ-8と構成ａ-3とを対比する。
　構成ａ-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する方法」であり、上記（４）のとおり、引用発明は、「第１の経路」、「第２の経路」を有しているから、「前記コンテンツが、前記第１および前記少なくとも第２の経路を介して前記クライアント装置から同時にアクセス可能である方法」として、構成要件Ａ-8と一致する。
　　
（９）構成要件Ｂと構成ｂとを対比する。
　構成ｂの「エンドユーザ局のエージェントコントローラモジュール」は、「エンドユーザ局」に含まれるから、構成要件Ｂの「クライアント装置」に相当する。
　構成ｂの「リクエストしたストリームレットの部分の受信時間をモニタする」は、構成ｃにおいて、複数の同時ストリームレットの部分を処理するから、同時に出した複数のストリームリクエストに対してモニタするものと認められ、構成ｂは、「前記クライアント装置において、前記第１の経路上の第１の指標および前記少なくとも第２の経路上の少なくとも第２の指標を決定するステップ」として、構成要件Ｂと共通する。
　しかしながら、「指標」が、本願発明においては、「利用可能なビット・レート」であるのに対し、引用発明においては、「受信時間」である点で相違する。
　　
（１０）構成要件Ｃと構成ｃとを対比する。
　構成ｃは、「多数の同時ストリームレットの部分を処理するため、およびパフォーマンス率ｒの代表値をよりよく判定するために、パフォーマンスファクタを得、パフォーマンスファクタにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断」するものであり、「再生品質をアップシフト、そのまま、ダウンシフトするかを判断」することは、「前記対応ビット・レートの中から要求ビット・レートを決定する」ことといえる。
　上記（９）のとおり、本願発明の「ビット・レート」と引用発明の「受信時間」とは「指標」として一致するものの、相違する。
　したがって、構成要件Ｃと構成ｃとは、「前記決定した第１の指標および前記決定した少なくとも第２の指標から、前記対応ビット・レートの中から要求ビット・レートを決定するステップ」として共通する。
　しかしながら、「指標」が、本願発明においては、「利用可能なビット・レート」であるのに対し、引用発明においては、「受信時間」である点で相違する。
　　
（１１）構成要件Ｄと構成ａ-3とを対比する。
　構成ａ-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」ものである。
　ストリームレットは、上記（７）のとおり、時間指標ｉで識別され、構成ａ-1によると、ビットレートで識別され、第１、第２の経路は、上記（４）のとおりである。
　したがって、構成要件Ｄと構成ａ-3とは、「前記時間指標ｉおよび前記決定した要求ビット・レートによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路を介して送信し、前記時間指標ｉによって識別される前記チャンクの少なくとも第２の部分を受信するための少なくとも第２の要求を前記少なくとも第２の経路を介して送信するステップ」として一致する。
　　
（１２）構成要件Ｄ-1について
　本願発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分が相補的である」のに対し、引用発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分が相補的である」と特定されていない点で相違する。
　　
（１３）構成要件Ｄ-2について
　本願発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれが、前記決定した第１の利用可能なビット・レートおよび前記決定した第２の利用可能なビット・レートから計算されるサイズを有する」のに対し、引用発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれ」が、どのようなサイズにするか特定されていない点で相違する。
　　
（１４）構成要件Ｅと構成ａ-3とを対比する。
　構成ａ-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」ものであり、「前記第１の経路を介して前記要求した第１の部分を受信し、前記少なくとも第２の経路を介して前記要求した少なくとも第２の部分を受信するステップ」といえる。
　したがって、構成要件Ｅと構成ａ-3とは一致する。
　　
２　一致点、相違点
　以上より、本願発明と引用発明との一致点、相違点は、次のとおりである。
　　
（一致点）
（Ａ）少なくとも第１および第２の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法であり、
（Ａ-1）前記少なくとも第１および第２の通信インタフェースのそれぞれが通信アドレスを有し、
（Ａ-2）前記コンテンツが、それぞれが通信アドレスを有する少なくとも第１および第２のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能であり、
（Ａ-3）第１の経路が、前記第１の通信インタフェースの通信アドレスおよび前記第１のサーバ通信インタフェースのアドレスによって識別され、
（Ａ-4）少なくとも第２の経路が、前記第２の通信インタフェースの通信アドレスおよび前記少なくとも第２のサーバ通信インタフェースのアドレスによって識別され、
（Ａ-5）前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも２つのバージョンで利用可能であり、
（Ａ-6）前記少なくとも２つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、
（Ａ-7）チャンクが、時間指標ｉおよび前記対応ビット・レートのうちの１つによって識別され、
（Ａ-8）前記コンテンツが、前記第１および前記少なくとも第２の経路を介して前記クライアント装置から同時にアクセス可能である方法であって、
（Ｂ’）前記クライアント装置において、前記第１の経路上の第１の指標および前記少なくとも第２の経路上の少なくとも第２の指標を決定するステップ（Ｓ１）と、
（Ｃ’）前記決定した第１の指標および前記決定した少なくとも第２の指標から、前記対応ビット・レートの中から要求ビット・レートを決定するステップ（Ｓ２）と、
（Ｄ）前記時間指標ｉおよび前記決定した要求ビット・レートによって識別されるチャンクの第１の部分を受信するための第１の要求を前記第１の経路を介して送信し、前記時間指標ｉによって識別される前記チャンクの少なくとも第２の部分を受信するための少なくとも第２の要求を前記少なくとも第２の経路を介して送信するステップ（Ｓ３）と、
（Ｅ）前記第１の経路を介して前記要求した第１の部分を受信し、前記少なくとも第２の経路を介して前記要求した少なくとも第２の部分を受信するステップ（Ｓ４）と、
（Ａ）を含む、前記方法。
　　
（相違点１）
　「指標」が、本願発明においては「利用可能なビット・レート」であるのに対し、引用発明においては「受信時間」である点
　　
（相違点２）
　本願発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分が相補的である」のに対し、引用発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分が相補的である」と特定されていない点
　　
（相違点３）
　本願発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれが、前記決定した第１の利用可能なビット・レートおよび前記決定した第２の利用可能なビット・レートから計算されるサイズを有する」のに対し、引用発明においては、「前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれ」がどのようなサイズにするか特定されていない点
　　
第４　判断
１　相違点１について
　引用発明における「受信時間」は、ストリームレットの部分の受信時間であり、経路の速度に関係していることは明らかであるから、「受信時間」を「ビット・レート」をすることは当業者が容易に想到し得ることである。
　そして、経路の速度である「ビット・レート」は、経路の利用できる速度であるから、「利用可能なビット・レート」といえる。
　　
２　相違点２について
　引用発明は、エンドユーザ局においてコンテントを奏する、すなわちコンテントを再生するものであるから、第１の部分と第２の部分との間に不足する部分があることはなく、また効率を高くするため、重複をしないようにすることも普通のことである。
　したがって、引用発明において、第１部分と第２の部分とを相補的とすることは、当業者が容易に想到し得ることである。
　　
３　相違点３について
　利用可能なビットレートから第１の部分と第２の部分のサイズを決定することは、例えば、拒絶査定で引用された特開２００６−２４４０５４号公報の段落０２１５〜０２２０（上記第２の３参照）に記載されているように、周知の技術である。
　引用発明と周知技術とは、コンテンツを複数の箇所から受信する技術という技術分野のものであるから、引用発明に周知技術を適用する動機付けはある。
　したがって、引用発明に周知技術を適用して、「前記識別される前記チャンクの前記第１の部分および前記第２の部分のそれぞれが、前記決定した第１の利用可能なビット・レートおよび前記決定した第２の利用可能なビット・レートから計算されるサイズを有する」ようにすることは、当業者が容易に想到し得ることである。
　　
４　効果等
　本願発明が奏する効果は、その容易想到である構成から当業者が容易に予測し得る範囲内のものであり、同範囲を超える顕著なものでもない。
　　
５　まとめ
　以上のとおりであるから、本願発明は、引用発明、周知技術に基づいて、当業者が容易になし得たものである。
　　
第５　むすび
　以上のとおり、本願の請求項１に係る発明は、引用文献１に記載された発明、周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。 
　　
　したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。
　　
　よって、結論のとおり審決する。