【事件の表示】
　特願２００７−５４５０４６「ストリーミングデータ配信」拒絶査定不服審判事件〔平成１８年　６月２２日国際公開、ＷＯ２００６／０６４３９６、平成２０年　７月　３日国内公表、特表２００８−５２３６８５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　経緯 
１．手続 
　本件出願は、平成１７年１２月５日（パリ条約による優先権主張２００４年１２月１３日、欧州特許庁）を国際出願日とする出願であって、手続の概要は以下のとおりである。
　
　手続補正書　　　　　　　　：平成２０年　５月　２日
　拒絶理由通知　　　　　　　：平成２３年　６月２０日（起案日）
　手続補正書　　　　　　　　：平成２３年１２月２６日
　拒絶査定　　　　　　　　　：平成２４年　１月３０日（起案日）
　拒絶査定不服審判請求　　　：平成２４年　６月　７日
　手続補正書　　　　　　　　：平成２４年　６月　７日
　前置審査報告　　　　　　　：平成２４年　７月　３日
　審尋　　　　　　　　　　　：平成２４年　８月　８日（起案日）
　回答書　　　　　　　　　　：平成２４年１１月１３日　
 　 
２．査定 
　原査定の理由は、概略、以下のとおりである。 
 　 
　本願の請求項１ないし請求項３８に係る発明は、いずれも、その出願前日本国内又は外国において頒布された下記の各刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　　
　　　　　　　　　　　　記（刊行物）
　刊行物１：特開２００２−１１８５９２号公報
　刊行物２：特開２００４−５６８１９号公報
　刊行物３：特開２００３−１４３５８７号公報
　
第２　補正の却下の決定 
　平成２４年６月７日付の手続補正について次のとおり決定する。 
 　 
《結論》 
　平成２４年６月７日付の手続補正を却下する。 
 　 
《理由》 
１．補正の内容 
　平成２４年６月７日付の手続補正（以下「本件補正」という。）は、補正前の請求項１〜３８(平成２３年１２月２６日付手続補正書で補正されたもの)である、
　
「【請求項１】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを表示装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記表示装置に送信するステップと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記表示装置への送信を継続するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記表示装置に送信するステップと、
を有する方法。
【請求項２】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項１記載の方法。
【請求項３】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項１記載の方法。
【請求項４】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するステップをさらに有する、請求項１記載の方法。
【請求項５】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項４記載の方法。
【請求項６】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項４記載の方法。
【請求項７】
　前記第２チャネルのストリーミングデータの前記表示装置への送信は、前記第２チャネルのストリーミングデータのＩフレームから始まる、請求項４記載の方法。
【請求項８】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを表示装置に配信するよう構成されるユーザ装置であって、
　第１チャネルのストリーミングデータを前記表示装置に送信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記表示装置への送信を継続するよう構成され、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記表示装置に送信するよう構成されるユーザ装置。
【請求項９】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項８記載のユーザ装置。
【請求項１０】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項８記載のユーザ装置。
【請求項１１】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するよう構成される第３インタフェースをさらに有する、請求項８記載のユーザ装置。
【請求項１２】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項１１記載のユーザ装置。
【請求項１３】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項１１記載のユーザ装置。
【請求項１４】
　前記第２チャネルのストリーミングデータの前記表示装置への送信は、前記第２チャネルのストリーミングデータのＩフレームから始まる、請求項１１記載のユーザ装置。
【請求項１５】
　ユーザ装置においてインターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを受信する方法であって、
　第１チャネルのストリーミングデータを受信するステップと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になるまで、前記第１チャネルのストリーミングデータの受信を継続するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になると、前記ユーザ装置において前記第２チャネルのストリーミングデータを受信するステップと、
を有する方法。
【請求項１６】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項１５記載の方法。
【請求項１７】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項１５記載の方法。
【請求項１８】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するステップをさらに有する、請求項１５記載の方法。
【請求項１９】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項１８記載の方法。
【請求項２０】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項１８記載の方法。
【請求項２１】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを受信するよう構成されるユーザ装置であって、
　第１チャネルのストリーミングデータを受信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になるまで、前記第１チャネルのストリーミングデータの受信を継続するよう構成され、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になると、前記ユーザ装置において前記第２チャネルのストリーミングデータを受信するよう構成されるユーザ装置。
【請求項２２】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項２１記載のユーザ装置。
【請求項２３】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項２１記載のユーザ装置。
【請求項２４】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するステップをさらに有する、請求項２１記載のユーザ装置。
【請求項２５】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項２４記載のユーザ装置。
【請求項２６】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項２４記載のユーザ装置。
【請求項２７】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有する方法。
【請求項２８】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項２７記載の方法。
【請求項２９】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項２７記載の方法。
【請求項３０】
　前記第１チャネルから第２チャネルへの変更を示す信号は、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを有する、請求項２７記載の方法。
【請求項３１】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項３０記載の方法。
【請求項３２】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項３０記載の方法。
【請求項３３】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信するよう構成されるルータであって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するよう構成され、
　前記第１インタフェースはさらに、前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するよう構成されるルータ。
【請求項３４】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項３３記載のルータ。
【請求項３５】
　前記第１チャネルのストリーミングデータは、前記ＩＰベースネットワークの第１コンテンツデータストリームサーバからのものであり、前記第２チャネルのストリーミングデータは、前記ＩＰベースネットワークの第２コンテンツデータストリームサーバからのものである、請求項３３記載のルータ。
【請求項３６】
　前記第１チャネルから第２チャネルへの変更を示す信号は、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを有する、請求項３３記載のルータ。
【請求項３７】
　前記第１チャネルから離脱するリクエストは、ＩＧＭＰリーブリクエストである、請求項３６記載のルータ。
【請求項３８】
　前記第２チャネルに参入するリクエストは、ＩＧＭＰジョインリクエストである、請求項３６記載のルータ。」
　
を、
　
「【請求項１】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを表示装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記表示装置に送信するステップと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記表示装置への送信を継続するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記表示装置に送信するステップと、
を有し、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項２】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項１記載の方法。
【請求項３】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するステップをさらに有する、請求項１記載の方法。
【請求項４】
　前記第２チャネルのストリーミングデータの前記表示装置への送信は、前記第２チャネルのストリーミングデータのＩフレームから始まる、請求項
２
【請求項５】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを表示装置に配信するよう構成されるユーザ装置であって、
　第１チャネルのストリーミングデータを前記表示装置に送信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記表示装置への送信を継続するよう構成され、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記表示装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記表示装置に送信するよう構成され
、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項６】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項
５
【請求項７】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するよう構成される第３インタフェースをさらに有する、請求項
５
【請求項８】
　前記第２チャネルのストリーミングデータの前記表示装置への送信は、前記第２チャネルのストリーミングデータのＩフレームから始まる、請求項
７
【請求項９】
　ユーザ装置においてインターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを受信する方法であって、
　第１チャネルのストリーミングデータを受信するステップと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になるまで、前記第１チャネルのストリーミングデータの受信を継続するステップと、
　前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になると、前記ユーザ装置において前記第２チャネルのストリーミングデータを受信するステップと、
を有
し、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項１０】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項
９
【請求項１１】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信するステップをさらに有する、請求項
１０
【請求項１２】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータを受信するよう構成されるユーザ装置であって、
　第１チャネルのストリーミングデータを受信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの所望の変更を示す変更リクエストを受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になるまで、前記第１チャネルのストリーミングデータの受信を継続するよう構成され、
　前記第１インタフェースはさらに、前記変更リクエストの受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置において利用可能になると、前記ユーザ装置において前記第２チャネルのストリーミングデータを受信するよう構成され
、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項１３】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項
１２
【請求項１４】
　前記変更リクエストを受信することに応答して、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを前記ＩＰベースネットワークのルータに送信する
よう構成される第３インタフェース
１２
【請求項１５】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送
信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有
し、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項１６】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項
１５
【請求項１７】
　前記第１チャネルから第２チャネルへの変更を示す信号は、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを有する、請求項
１５
【請求項１８】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信するよう構成されるルータであって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するよう構成される第１インタフェースと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するよう構成される第２インタフェースと、
を有し、
　前記第１インタフェースはさらに、前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するよう構成され、
　前記第１インタフェースはさらに、前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するよう構成され
、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
【請求項１９】
　前記ＩＰベースネットワークは、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ　Ｇｒｏｕｐ　Ｍａｎａｇｅｍｅｎｔ　Ｐｒｏｔｏｃｏｌ）を利用する、請求項
１８
【請求項２０】
　前記第１チャネルから第２チャネルへの変更を示す信号は、前記第１チャネルから離脱するリクエストと、前記第２チャネルに参入するリクエストとを有する、請求項
１８
　
　と補正するものであって、以下の補正事項を含むものである。
　
［補正事項１］
　補正前の請求項３，５，６，１０，１２，１３，１７，１９，２０，２３，２５，２６，２９，３１，３２，３５，３７，３８を削除する。
　
［補正事項２］
　上記［補正事項１］の請求項の削除に伴い、補正前の請求項２７の項番を、請求項１５に繰り上げると共に、補正前の請求項２７(平成２３年１２月２６日付手続補正書で補正されたもの)の
　
「【請求項２７】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有する方法。」
　
　とあるのを、
　
「【請求項１５】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有
し、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
　
　と補正する。
　
２．本件補正の適合性
（１）補正の範囲
　上記［補正事項２］は、願書に最初に添付した明細書の記載（段落【０００１】〜【０００３】【０００５】【００１８】）に基づくものであり、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内においてする補正である。
　
（２）補正の目的
　上記［補正事項１］は、請求項の削除を目的とするものである。
　上記［補正事項２］は、「第２チャネルのストリーミングデータ」の内容を限定するものであり、特許請求の範囲の減縮を目的とするものである。
　
（３）独立特許要件 
　上記［補正事項２］は、特許請求の範囲の減縮を目的とするものであるので、以下、独立特許要件について検討する。 
　
ア．補正後の請求項１５に係る発明 
　本件補正後の請求項１５に係る発明（以下「補正後発明」という。）は、本願明細書又は図面の記載からみて、以下のとおりである。
　
「【請求項１５】
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有
し、
　前記第２チャネルのストリーミングデータは、ビデオデータを含む
　
イ．刊行物の記載
　原査定の拒絶の理由に引用された刊行物１である特開２００２−１１８５９２号公報（以下「引用例１」という。）には、「ビットストリーム切り替え方法、二次配信サーバ、配信サーバ、クライアント、及びそのプログラムを記録した記録媒体」（発明の名称）に関し、図面と共に次に掲げる事項が記載されている。 　 
　
《特許請求の範囲》
「【請求項１】　複数の配信サーバのビットストリームを切り替えてクライアントに配信する際のビットストリーム切り替え方法であって、
切り替え前のビットストリームを、切り替え後のビットストリームが配信されるまで配信し続け、切り替え前のビットストリームと切り替え後のビットストリームを途切れなく繋げてクライアントへ配信することを特徴とするビットストリーム切り替え方法。」
　
《発明の属する技術分野》
「【０００１】
【発明の属する技術分野】本発明は、映像や音声などのビットストリームを配信する技術に関し、特にインターネットなどにおいて、複数のサーバから提供される映像や音声を始めとするビットストリームを切り替えて配信するマルチストリーム切り替え技術に関する。」
　
《従来の技術》
「【０００２】
【従来の技術】従来のインターネットでの一般的な映像中継を図２により説明する。図２において、２０１、２０２、…、２０ｍは配信サーバであり、それぞれ異なる映像を配信する。２１１、２１２、２１３、…、２１ｎはクライアントであり、サーバ２０１、２０２、…、２０ｍから配信された映像を再生する。サーバ２０１、…、２０ｍとクライアント２１１、…、２１ｎはネット手段２２０で結ばれている。ネット手段２２０はインターネットである。」
「【０００３】従来のインターネット中継では、例えばクライアント２１１は映像を配信する配信サーバ２０１へ配信要求を発行し、その配信要求に基づいて配信サーバ２０１がクライアント２１１へユニキャスト若しくはマルチキャストで映像を送り始める。ここで、クライアントから映像の配信要求を出してから映像が配信されるまでの時間が応答遅延時間である。」
「【０００４】一方、映像は細切れのパケットとして配信サーバ２０１からクライアント２１１へ送られる。インターネット経由の映像配信の場合、ネットワークの通信レートが変動するので、一定の速度で配信サーバ２０１からクライアント２１１へパケットが送れない場合がある。例えば、ネットワークで配信遅延が発生した場合、配信サーバ２０１からクライアント２１１へパケットが所定の時間以内に到着しなくなり、最悪の場合、クライアント２１１では映像再生が途切れる。」
「【０００５】図３は、映像再生がクライアントで途切れないようにするための従来方法を説明する図である。図３において、３００はクライアントが具備するメモリバッファであり、３０１、３０２、３０３は配信サーバから細切れに送られてくるパケットの映像である。」
「【０００６】映像再生開始時、クライアントでは、キュー型のメモリバッファ３００に、一旦、パケット化された映像３０１、３０２、３０３、…を溜める。そして、メモリバッファ３００中の映像が一定量溜ったとき、すなわちメモリ蓄積量が再生開始閾値を越えたときから、メモリバッファ３００中の映像を先頭から読み出し、再生し始める。配信サーバから送られてくる映像のパケットは必ずメモリバッファ経由で再生されるので、パケットが到着してメモリバッファが空にならないようにすれば、映像再生が途切れなくなる。」
　
《発明が解決しようとする課題》
「【０００７】
【発明が解決しようとする課題】従来のインターネットでの映像中継では、クライアントはネットワークを通して配信サーバに映像を要求し、配信サーバから映像の配信を受けてからメモリバッファ経由で、再生しているため、応答遅延時間及び、映像がメモリバッファに一定量溜るまでの時間だけ、再生開始を待たざるを得なかった。特に、複数のサーバからの映像を切り替えて再生するようなマルチストリーム型の映像再生では、クライアントは映像切り替えの度に、所望の映像を配信する配信サーバに配信要求をし、配信が開始された後、映像を溜めてから映像再生を開始するので、切り替えた際に一旦画面で再生される映像がなくなりブラックアウトするなど、切り替えを境に映像が途切れ、再生が待たされるという問題があった。」
「【０００８】本発明の目的は、インターネット中継などにおいて、クライアントが複数の配信サーバからの映像等のビットストリームを切り替えて再生する場合、切り替えの際に途切れなく、シームレスに繋がるマルチストリーム再生を可能にすることにある。」
　
《課題を解決するための手段》
「【０００９】
【課題を解決するための手段】本発明における基本的なシステム構成を図１を用いて説明する。図１において、１０１、１０２、…、１０ｍは配信サーバであり、それぞれ異なる映像を配信する。１１１、１１２、１１３、…、１１ｎはクライアントであり、配信サーバ１０１、…、１０ｍから配信された映像を再生する。１２１、１２２、１２３、…、１２ｎは二次配信サーバであり、配信サーバ１０１、…、１０ｍから配信された映像をクライアント１１１、…１１ｎへ中継する。」
「【００１０】配信サーバ１０１、…、１０ｍと二次配信サーバ１２１、…、１２ｎはネット手段１３０で結ばれている。また、二次配信サーバ１２１、…、１２ｎとクライアント１１１、…、１１ｎはネット手段１３１で結ばれている。ネット手段１３０、１３１は例えばインターネットであり、インターネット技術を用いたＩＰネットワークでもよいし、ＩＰ以外のプロトコルで通信するネットワークであっても構わない。さらに、ネット手段１３０は有線、無線の放送、例えばデジタル放送であっても構わない。」
「【００１１】二次配信サーバ１２ｘとクライアント１０ｘ（ｘ＝１、…、ｎ）は１対１に対応している。例えばクライアント１１１が、例えば配信サーバ１０１が配信している映像を要求する場合、まず、二次配信サーバ１２１へ配信要求を発行する。二次配信サーバ１２１は配信サーバ１０１へ映像要求を中継し、結果として配信サーバ１０１から二次配信サーバ１２１へ映像が配信される。二次配信サーバ１２１へ送られてくる映像はクライアント１１１へ中継され、クライアント１１１で映像視聴が始まる。」
「【００１２】ここで、クライアント１１１で再生している映像を、配信サーバ１０１にて配信される映像から、例えば配信サーバ１０２にて配信される映像に切り替える場合について説明する。」
「【００１３】クライアント１１１は二次配信サーバ１２１へ映像の切り替え要求を発行する。映像切り替え要求については、予め映像切り替えがスケジュールされているときは二次配信サーバ１２１でそのスケジュールを管理していてもよい。二次配信サーバ１２１はクライアント１１１からの要求若しくはスケジュールに基づき、配信サーバ１０２へ映像配信要求を発行する。このとき、二次配信サーバ１２１では、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続する。そして、配信サーバ１０２から映像を受け始めたなら、二次配信サーバ１２１は、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替える。」
「【００１４】以上の処理で、映像切り替え時にクライアント１１１では、二次配信サーバ１２１との切断接続はしないので応答遅延はなく、また、メモリバッファをクリアしていないので、結果として映像が途切れることなく、配信映像が切り替えられる。」
　
《発明の実施の形態》
「【００１５】
【発明の実施の形態】以下、本発明の二、三の実施の形態について図４乃至図６により具体的に説明する。
【００１６】図４は本発明の第一の実施形態のシステム構成図である。図４において、４０１、４０２、…、４０ｍは配信サーバであり、それぞれ異なる映像や音声を始めとするビットストリームを配信する。ここでは、映像を配信するとする。４１１はクライアントであり、配信された映像を再生する。４２１は二次配信サーバであり、配信サーバ４０１、４０２、…、４０ｍから配信された映像をクライアント４１１へ中継する。４４１は情報サーバであり、配信サーバ４０１、…、４０ｍで配信される映像に関する情報を二次配信サーバ４２１へ配信する。４３０及び４３１及び４３２はネット手段であり、それぞれ配信サーバ４０１、…、４０ｍと二次配信サーバ４２１、二次配信サーバ４２１とクライアント４１１、情報サーバ４４１と二次配信サーバ４２１とを結ぶ。これらは、例えばインターネットである。なお、ネット手段４３０、４３１、４３２は同じものであっても構わない。」
「【００１７】二次配信サーバ４２１は受信部４２１１、配信部４２１２、制御部４２１３、スケジュールデータベース（スケジュールＤＢ）４２１４を具備する。受信部４２１１は配信サーバ４０１、…、４０ｍからの映像を受信する。配信部４２１２は受信部４２１１で受信した映像をクライアント４１１へ配信する。制御部４２１３は、受信部４２１１を制御し、クライアント４１１へ配信する映像を選択する。スケジュールＤＢ４２１４はクライアント４１１へ配信する映像のスケジュールを管理する。」
「【００１８】二次配信サーバ４２１が、配信サーバ４０１、…、４０ｍから配信される映像を、クライアント４１１からの要求及び情報サーバ４４１からの配信サーバ４０１、…、４０ｍで配信される映像に関する情報に基づき、切り替える動作について説明する。」
「【００１９】配信サーバ４０１、…、４０ｍから配信される映像が、例えばサッカーなどのスポーツ中継のマルチアングル映像であるとし、クライアント４１１は特定の選手Ａを追い掛けて再生するようなカメラ切り替えを要求するとする。また、情報サーバ４４１からは、配信サーバ４０１、…、４０ｍが配信している映像に映っている選手を情報として配信されているとする。」
「【００２０】クライアント４１１は、二次配信サーバ４２１へ、ネット手段４３１を通じて、選手Ａを追い掛けてカメラ切り替えをしたいという要求を発行する。この要求は、二次配信サーバ４２１のスケジュールＤＢ４２１４へ記録される。なお、クライアント４１１が二次配信サーバ４２１へ要求を発行するタイミングは中継が始まる前でも構わない。」
「【００２１】二次配信サーバ４２１では、制御部４２１３がスケジュールＤＢ４２１４中にある要求と情報サーバ４４１から配信される情報に基づき、受信部４２１１で受信する映像を制御し選択する。例えば、情報サーバ４４１から配信される情報として、配信サーバ４０１が配信している映像に選手Ａが映っていると記述されていれば、制御部４２１３は、受信部４２１１に対して、配信サーバ４０１からの映像の配信を受けるように制御する。受信部４２１１は配信サーバ４０１へ映像配信要求を発行し、それによって配信された映像を配信部４２１２へ送り、配信部４２１２はネット手段４３１を経由してクライアント４１１へその映像を配信する。」
「【００２２】次のタイミングで、情報サーバ４４１から配信される情報として、例えば配信サーバ４０２から配信される映像に選手Ａが映っているという記述があれば、制御部４２１３の制御に基づき、受信部４２１１は配信サーバ４０２へ映像を要求する。その間も、受信部４２１１では、配信サーバ４０１からの映像の受信を続行し、配信部４２１２を介してクライアントへ配信し続ける。そして、配信サーバ４０２からの映像が配信し始めると、受信部４２１１は、配信サーバ４０２からの映像を配信部４２１２へ送り始め、同時に配信サーバ４０１へ切断要求を発行する。」
　
《図面》
「【図１】
」
　
ウ．引用発明
（ア）引用例１【請求項１】の「複数の配信サーバのビットストリームを切り替えてクライアントに配信する際のビットストリーム切り替え方法」との記載、段落【００１０】の「ネット手段１３０、１３１は例えばインターネットであり、インターネット技術を用いたＩＰネットワークでもよいし、ＩＰ以外のプロトコルで通信するネットワークであっても構わない」との記載からみて、引用例１記載の発明は「インターネット技術を用いたＩＰネットワークでビットストリームをクライアントに配信する方法」といえる。
　
（イ）引用例１【請求項１】の「複数の配信サーバのビットストリームを切り替えてクライアントに配信する際のビットストリーム切り替え方法」との記載、段落【０００９】の「本発明における基本的なシステム構成を図１を用いて説明する。図１において、１０１、１０２、…、１０ｍは配信サーバであり、それぞれ異なる映像を配信する。１１１、１１２、１１３、…、１１ｎはクライアントであり、配信サーバ１０１、…、１０ｍから配信された映像を再生する。１２１、１２２、１２３、…、１２ｎは二次配信サーバであり、配信サーバ１０１、…、１０ｍから配信された映像をクライアント１１１、…１１ｎへ中継する。」との記載、段落【００１１】の「二次配信サーバ１２ｘとクライアント１０ｘ（ｘ＝１、…、ｎ）は１対１に対応している。例えばクライアント１１１が、例えば配信サーバ１０１が配信している映像を要求する場合、まず、二次配信サーバ１２１へ配信要求を発行する。二次配信サーバ１２１は配信サーバ１０１へ映像要求を中継し、結果として配信サーバ１０１から二次配信サーバ１２１へ映像が配信される。二次配信サーバ１２１へ送られてくる映像はクライアント１１１へ中継され、クライアント１１１で映像視聴が始まる。」との記載からみて、引用例１記載の発明は「配信サーバ１０１からの映像をクライアント１１１に配信するステップ」「配信サーバ１０２からの映像をクライアント１１１に配信するステップ」を有する。
　
（ウ）引用例１段落【００１２】の「ここで、クライアント１１１で再生している映像を、配信サーバ１０１にて配信される映像から、例えば配信サーバ１０２にて配信される映像に切り替える場合について説明する。」との記載、段落【００１３】の「クライアント１１１は二次配信サーバ１２１へ映像の切り替え要求を発行する。映像切り替え要求については、予め映像切り替えがスケジュールされているときは二次配信サーバ１２１でそのスケジュールを管理していてもよい。二次配信サーバ１２１はクライアント１１１からの要求若しくはスケジュールに基づき、配信サーバ１０２へ映像配信要求を発行する。」との記載からみて、引用例１記載の発明は、「クライアント１１１は配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求を発行し、二次配信サーバ１２１が受信するステップ」を有する。
　
（エ）引用例１段落【００１２】の「二次配信サーバ１２１はクライアント１１１からの要求若しくはスケジュールに基づき、配信サーバ１０２へ映像配信要求を発行する。」との記載、段落【００１３】の「このとき、二次配信サーバ１２１では、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続する。」との記載によると、引用例１記載の発明は、「二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続するステップ」を有する。
　
（オ）引用例１段落【００１２】の「二次配信サーバ１２１はクライアント１１１からの要求若しくはスケジュールに基づき、配信サーバ１０２へ映像配信要求を発行する。」との記載、段落【００１３】の「そして、配信サーバ１０２から映像を受け始めたなら、二次配信サーバ１２１は、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替える。」との記載からみて、引用例１記載の発明は、「二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、配信サーバ１０２から映像を受け始めたなら、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替えるステップ」を有する。
　
（カ）引用例１段落【０００１】の「本発明は、映像や音声などのビットストリームを配信する技術に関し、特にインターネットなどにおいて、複数のサーバから提供される映像や音声を始めとするビットストリームを切り替えて配信するマルチストリーム切り替え技術に関する。」、段落【００１２】の「ここで、クライアント１１１で再生している映像を、配信サーバ１０１にて配信される映像から、例えば配信サーバ１０２にて配信される映像に切り替える場合について説明する。」との記載からみて、「配信サーバ１０１，１０２からの映像はビットストリームとして配信される」ものといえる。
　
（キ）まとめ
　上記（ア）〜（カ）によれば、引用例１には、以下の発明（以下「引用発明」という。）が記載されていると認められる。 
 　 
「インターネット技術を用いたＩＰネットワークでビットストリームをクライアントに配信する方法であって、
　配信サーバ１０１からの映像をクライアント１１１に配信するステップと、
　配信サーバ１０２からの映像をクライアント１１１に配信するステップと、
　クライアント１１１は配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求を発行し、二次配信サーバ１２１が受信するステップと、
　二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続するステップと、
　二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、配信サーバ１０２から映像を受け始めたなら、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替えるステップと、
　を有し、
　配信サーバ１０１，１０２からの映像はビットストリームとして配信される、
　方法。」
　
エ．対比 
　補正後発明と引用発明とを対比する。 
　
（ａ）「インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法」
　引用発明は「インターネット技術を用いたＩＰネットワークのビットストリームをクライアントに配信する方法」であり、引用発明の「ビットストリーム」「クライアント」は、補正後発明の「ストリーミングデータ」「ユーザ装置」と一致する。
　すなわち、引用発明と補正後発明は「インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法」である点で一致している。
　
（ｂ）「第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップ」
(1)　補正後発明の「チャネル」という用語の意味について
　ここで、補正後発明の「チャネル」という用語について、本願明細書および図面を参酌してその意味を検討する。本願明細書及び図面には「チャネル」という用語を用いた記載、および、関連する記載として、以下の記載がある。
  
「【０００２】
  ラジオ放送やテレビ放送などのコンテンツのリアルタイムストリーミングの大部分は、現在は各ステーションに用意された
チャネル
チャネル
チャネル
「【０００３】
  インターネットプロトコル（ＩＰ）が情報を配信するため中心的な役割を有しているネットワーク接続環境に現在変化がある。ラジオ及びテレビ放送がＩＰネットワークを利用して自らのコンテンツをユーザに配信することが増大することが予想される。このようなストリーミングデータを配信するための最も一般的なＩＰ技術は、“ＨＴＴＰ−Ｇｅｔ”として知られている。この技術は、ポイント・ツー・ポイント接続に基づくものであり、ユーザ数が少数である事実により現在のニーズに適している。ストリーミングコンテンツにＩＰネットワークを使用するユーザ数が増大するとき（及びステーションからサービスをリクエストするユーザ数が増大するとき）、ＨＴＴＰ−Ｇｅｔ技術は真にスケーリングできるものでない。この理由は、かなりのネットワークロード（帯域幅など）が要求されると同時に、ネットワークサーバが大量のリクエストにサービス提供することを要求するというキャパシティのためである。このロードは、ネットワーク混雑を導く可能性がある。」
「【０００４】
  上記問題点を解決するため、マルチキャストモデルが利用可能である。マルチキャストモデルでは、マルチキャストモデルでは、コンテンツは、当該ルータ／スイッチを介しデータストリームを受信するユーザ数から独立したルータ／スイッチに１回のみ転送される。これは、ネットワークロードを低減する。当該サービスを提供するためインターネットの世界で使用されるマルチキャストプロトコルは、ＩＧＭＰ（ＩＥＴＦ−ＲＦＣ３３７６）である。」
「【０００５】
  現在、ネットワークの最終部分、すなわち、ユーザのホームネットワークとサービスプロバイダとの間の有線ネットワーク及び／又はホームネットワークである携帯装置とアクセスポイントの間の無線ネットワークの帯域幅は、一般には同時に２つのマルチキャストステーションの受信をサポートするのに十分なものではない。このような場合、第１ステーションの受信を停止し、第２ステーションの受信を要求することによって、第１ステーションから第２ステーションに変更する必要がある。ＩＧＭＰプロトコルの現在のバージョン（バージョン３）は、このオプションをサポートしている。しかしながら、このような技術は、２つのストリームの何れもユーザ装置によって受信されず、フリーズ／ブルー画面（テレビ受信）又はサイレンス（ラジオ受信）をもたらす時間を招くこととなる。これはユーザに望ましいものではない。さらに、一時的に使用されず、要求されない帯域幅（スイッチ期間中）が他のデータストリームに引き継がれる可能性があり、この場合、新たなストリームを受信するための利用可能な帯域幅がなくなってしまう。」
「【０００６】
  他の可能性のある１つの解決方法は、ネットワークの最終部分の帯域幅を増大させることである。しかしながら、すべてのケースで帯域幅を十分に増大させることは困難である。」
「【００１１】
  図１は、ストリーミングされたデータをユーザに提供するシステムを示すブロック図である。第１コンテンツプロバイダ２と第２コンテンツプロバイダ３は、ネットワークにそれぞれ第１コンテンツと第２コンテンツを提供する。ネットワーク４は、何れか適切なネットワークスイッチ、サーバ及びルータにより提供することが可能であり、第１コンテンツプロバイダ２からの第１コンテンツをルータ／スイッチ６を介しユーザネットワーク１０に供給する。第２コンテンツは、第２コンテンツプロバイダ３によってネットワーク４のルータ／スイッチ６を介しユーザネットワーク１０に提供される。」
「【００１２】
  本発明は、ユーザネットワーク１０における第１コンテンツと第２コンテンツとの間のスイッチに関する。図１及び図２のフローチャートを参照して、本発明を実現する方法が説明される。ステップｉにおいて、第１コンテンツがルータ／スイッチ６から受信される。ステップｉｉにおいて、ユーザコンテンツ変更リクエスト（
チャネル
「【００１４】
  第１及び第２コンテンツデータストリームは同一のコンテンツプロバイダにより提供可能であるということは理解されるであろう。このコンテンツプロバイダは、コンテンツデータサーバ又はそれに等価なものとすることが可能である。」
「【図１】
」
「【図２】
」
　
　ここで、上記段落【００１２】の「ユーザコンテンツ変更リクエスト（
チャネル
　また、上記段落【０００２】の「ラジオ放送やテレビ放送などのコンテンツのリアルタイムストリーミングの大部分は、現在は各ステーションに用意された
チャネル
チャネル
チャネル
チャネル
チャネル
　
　そして、上記段落【０００２】の記載は【背景技術】としての記載であるが、その「このようなシステムは、ユーザが特定のステーションを実際に視聴しているか否かに関係なく、各ユーザについて各ステーションに帯域幅が確保されていることを要求する。」との記載、上記段落【０００３】〜【０００６】【００１１】【００１２】【００１４】の記載、上記【図１】【図２】の記載、更に、それ以外の明細書及び図面の記載をみても、補正後発明の「チャネル」が、上記段落【０００２】に記載される「チャネル」と異なるものであると読み取ることはできない。
　
　すなわち、これら記載からみて、補正後発明における「チャネル」とは、「コンテンツを配信する具体的な構成において、それを介してコンテンツを受信するものであって、それを変更することにより受信するコンテンツを変更するもの」であって、上記段落【０００２】に記載される「ラジオ放送やテレビ放送などのコンテンツのリアルタイムストリーミング」で用いられている「チャネル」と同じ概念のものであると認めることができる。
　
(2)　「第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップ」についての対比
　引用発明は「配信サーバ１０１からの映像をクライアント１１１に配信するステップ」「配信サーバ１０２からの映像をクライアント１１１に配信するステップ」を有し「配信サーバ１０１，１０２からの映像はビットストリームとして配信される」ものであって、この「配信サーバ１０１からの映像」と「配信サーバ１０２からの映像」は異なるものであるといえる。そして、引用発明の「配信サーバ１０１からの映像をクライアント１１１に配信する」ときには、「配信サーバ１０１」から「クライアント１１１」の間の経路を介して配信され、この経路は「配信サーバ１０２」から「クライアント１１１」の間の経路と異なることも明らかである。
　
　ここで、上記（ａ）で述べたように、引用発明の「ビットストリーム」「クライアント」は、補正後発明の「ストリーミングデータ」「ユーザ装置」と一致する。
　
　そして、上記したように、引用発明の「配信サーバ１０１からの映像をクライアント１１１に配信する」ときには、「配信サーバ１０１」から「クライアント１１１」の間の経路を介して配信されるから、この引用発明における『「配信サーバ１０１」から「クライアント１１１」の間の経路』と補正後発明の「第１チャネル」は、いずれも、それを介してコンテンツを受信するものである点で一致している。更に、引用発明はこの『「配信サーバ１０１」から「クライアント１１１」の間の経路』に加え、「配信サーバ１０２からの映像をクライアント１１１に配信する」ときの「配信サーバ１０２」から「クライアント１１１」の間の経路をも有しているから、これら『「配信サーバ１０１」から「クライアント１１１」の間の経路』『配信サーバ１０２」から「クライアント１１１」の間の経路』をそれぞれ「第１の」「第２の」と捉えることができる。加えて、これら『「配信サーバ１０１」から「クライアント１１１」の間の経路』『配信サーバ１０２」から「クライアント１１１」の間の経路』を介して配信されるのは、それぞれ「配信サーバ１０１からの映像」「配信サーバ１０２からの映像」であって、配信される「映像」自体が異なるものであるから、結局、『「配信サーバ１０１」から「クライアント１１１」の間の経路』から『配信サーバ１０２」から「クライアント１１１」の間の経路』に変更すると受信されるコンテンツも「配信サーバ１０１からの映像」「配信サーバ１０２からの映像」と変更されるものである。
　すなわち、引用発明の『「配信サーバ１０１」から「クライアント１１１」の間の経路』は、引用発明において「コンテンツを配信する具体的な構成において、それを介してコンテンツを受信するものであって、それを変更することにより受信するコンテンツを変更するもの」であるとみることができ、引用発明の『「配信サーバ１０１」から「クライアント１１１」の間の経路』と補正後発明の「第１チャネル」が一致する。
　
　次に、引用発明における「配信サーバ１０１からの映像」「クライアント１１１に配信する」と補正後発明の「第１チャネルのストリーミングデータ」「表示装置に送信する」が一致する。
　
　これらをまとめると、引用発明の「配信サーバ１０１からの映像をクライアント１１１に配信するステップ」と補正後発明の「第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップ」が一致する。
　
（ｃ）「前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップ」
　引用発明は「クライアント１１１は配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求を発行し、二次配信サーバ１２１が受信するステップ」を有するものである。これに対し、上記（ｂ）(1)で述べたように、補正後発明における「チャネル」とは、それを介してコンテンツを受信するものであって、それを変更することにより受信するコンテンツを変更できるものであることから、補正後発明において「前記第１チャネルから第２チャネルへの変更」を行うと受信するコンテンツ、すなわち、ストリーミングデータも変更されるものであって、引用発明の「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求を発行するステップ」と補正後発明の「前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップ」は、いずれも、「第１のストリーミングデータから第２のストリーミングデータへの変更を示す信号を受信するステップ」という点で一致する。
　しかしながら、補正後発明は「前記第１チャネルから第２チャネルへの変更を示す信号」を受信し「前記第１チャネルから第２チャネルへの変更」を行うことによりその結果として、受信するコンテンツ、すなわち、ストリーミングデータを変更するものであるのに対し、引用発明は「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求」という直接コンテンツを変更する要求を受信する点で相違している。
　
（ｄ）「前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップ」
　引用発明は「二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続するステップ」を有しており、上記（ｂ）で述べたのと同様に、引用発明における『「配信サーバ１０１」から「クライアント１１１」の間の経路』『「配信サーバ１０２」から「クライアント１１１」の間の経路』が補正後発明の「第１チャネル」「第２チャネル」と一致するから、引用発明の「配信サーバ１０２へ映像配信要求を発行後、クライアント１１１に対する配信サーバ１０１からの映像配信を、少なくとも配信サーバ１０２からの映像配信が始まるまでは継続するステップ」と補正後発明の「前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップ」が一致している。
　
（ｅ）「前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップ」
　引用発明は「二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、配信サーバ１０２から映像を受け始めたなら、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替えるステップ」を有しており、上記（ｄ）で述べたように引用発明における『「配信サーバ１０１」から「クライアント１１１」の間の経路』『「配信サーバ１０２」から「クライアント１１１」の間の経路』が補正後発明の「第１チャネル」「第２チャネル」と一致するから、引用発明の「二次配信サーバ１２１は、配信サーバ１０２へ映像配信要求を発行後、配信サーバ１０２から映像を受け始めたなら、クライアント１１１への配信映像を、配信サーバ１０１からの映像から配信サーバ１０２からの映像に切り替えるステップ」と補正後発明の「前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップ」が一致している。
　
（ｆ）「前記第２チャネルのストリーミングデータは、ビデオデータを含む」
　引用発明の「配信サーバ１０１，１０２からの映像はビットストリームとして配信される」ものであって、上記（ｄ）で述べたように引用発明における『「配信サーバ１０１」から「クライアント１１１」の間の経路』『「配信サーバ１０２」から「クライアント１１１」の間の経路』が補正後発明の「第１チャネル」「第２チャネル」と一致するから、引用発明の「配信サーバ１０１，１０２からの映像はビットストリームとして配信される」と補正後発明の「前記第２チャネルのストリーミングデータは、ビデオデータを含む」が一致している。
　
オ．一致点・相違点 
　以上の対比（ａ）ないし（ｆ）を踏まえると、補正後発明と引用発明との［一致点］［相違点］は以下のとおりである。　　 
　
［一致点］ 
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　第１のストリーミングデータから第２のストリーミングデータへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有し、　
　前記第２チャネルのストリーミングデータは、ビデオデータを含む方法。
 　 
［相違点］　　 
　「第１のストリーミングデータから第２のストリーミングデータへの変更を示す信号を受信するステップ」において、補正後発明は「前記第１チャネルから第２チャネルへの変更を示す信号」を受信し「前記第１チャネルから第２チャネルへの変更」を行うことによりその結果として、受信するコンテンツ、すなわち、ストリーミングデータを変更するものであるのに対し、引用発明は「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求」という直接コンテンツ、すなわち、ストリーミングデータを変更する要求を受信する点。
　
カ．相違点の判断 
［相違点］
　引用発明は「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求」を受信し、それを実行して「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替え」るものであるが、具体的には「配信サーバ１０１にて配信される映像」が『「配信サーバ１０１」から「クライアント１１１」の間の経路』を介して配信されていたのが、「配信サーバ１０２にて配信される映像」が『「配信サーバ１０２」から「クライアント１１１」の間の経路』を介して配信されるように切り替えられるものである。また、上記したように、引用発明における『「配信サーバ１０１」から「クライアント１１１」の間の経路』『「配信サーバ１０２」から「クライアント１１１」の間の経路』が補正後発明の「第１チャネル」「第２チャネル」と一致している。
　ここで、通常のアナログ／ディジタルテレビ放送は、チャネルという概念を有し、受信する番組、すなわち、受信するコンテンツを変更しようとするときには、コンテンツそのものを直接変更するのではなく、受信するチャネルを変更することによって、受信する番組、すなわち、受信するコンテンツを間接的に変更するものであって、このような、受信するチャネルを変更することによって受信するコンテンツを変更するという概念は、極めて良く知られているものと認めることができる。(以下「周知技術」という。)
　そして、(a)引用発明も周知技術も、いずれもコンテンツを切り替えることに関するものである点では同一の技術分野に属すること、(b)引用例１段落【００１０】に「さらに、ネット手段１３０は有線、無線の放送、例えばデジタル放送であっても構わない。」と記載されているように引用発明１でも配信を放送によって行うことが想定されていること、(c)機器の操作を分かりやすいものとすることは例を挙げるまでもなく一般的な課題であるところ、その手法としてできるだけ従来のシステムと同様の操作を維持することよって操作を分かりやすいものとすることは極めて良く行われていることから、引用発明においても、配信される映像を変更するときに、同一の技術分野に属する周知技術である上記「受信するチャネルを変更することによって受信するコンテンツを変更すること」という操作法を採用することは、当業者が容易に想到し得たことにすぎない。
　
　以上のように、補正後発明の相違点にかかる構成は、当業者が容易に想到できることといえ、また、補正後発明の効果は、その構成から当業者が容易に予測し得るものであり、格別顕著なものがあるとは認められない。
　
キ．まとめ（独立特許要件） 
　以上、補正後発明は、引用例１に記載の発明に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。 
　
（４）むすび（補正却下） 
　以上のとおり、補正後発明は特許出願の際独立して特許を受けることができないものであるから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
 
　よって、補正の却下の決定の結論のとおり、決定する。 
　
第３　本願発明について
　平成２４年６月７日付手続補正は上記のとおり却下されたので、本願の請求項１ないし請求項３８に係る発明は、明細書、特許請求の範囲及び図面（平成２０年５月２日付、平成２３年１２月２６日付の手続補正書により補正された明細書及び図面）の記載からみて、それぞれ、その特許請求の範囲の請求項１ないし請求項３８に記載した事項により特定されるとおりのものであるところ、そのうち、請求項２７に係る発明（以下「本願発明」という。）は、以下のとおりのである。 
　
「インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　前記第１チャネルから第２チャネルへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
を有する方法。」
　
第４　検討 
１．引用例の記載 
　原査定の拒絶の理由に引用された刊行物１である特開２００２−１１８５９２号公報には、上記「第２　補正の却下の決定」「２．本件補正の適合性」「（３）独立特許要件」「イ．引用例の記載」で述べたとおりの記載、及び上記「ウ．引用発明」で述べたとおりの引用発明が記載されている。
 　 
２．対比 
　補正後発明は、本願発明に、上記「第２　補正の却下の決定」「１．補正の内容」で示した補正事項の補正をしたものである。
　したがって、本願発明は、補正後発明から上記［補正事項２］の補正を戻す関係にあり、その内容は、「第２チャネルのストリーミングデータ」に関する限定事項を削除する関係にある。 
　そして、本願発明と引用発明との対比は上記「第２　補正の却下の決定」「２．本件補正の適合性」「（３）独立特許要件」「エ．対比」と、上記削除される構成を除いて同様に対比される。 
　
３．一致点・相違点 
　以上の対比から、本願発明と引用発明との［一致点］・［相違点］は、以下のとおりである。 
 　 
［一致点］ 
　インターネットプロトコル（ＩＰ）ベースネットワークのストリーミングデータをユーザ装置に配信する方法であって、
　第１チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　第１のストリーミングデータから第２のストリーミングデータへの変更を示す信号を受信するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になるまで、前記第１チャネルのストリーミングデータの前記ユーザ装置への送信を継続するステップと、
　前記信号の受信後、前記第２チャネルのストリーミングデータが前記ユーザ装置への送信に利用可能になると、前記第２チャネルのストリーミングデータを前記ユーザ装置に送信するステップと、
　を有する方法。
 　 
［相違点］　　 
　「第１のストリーミングデータから第２のストリーミングデータへの変更を示す信号を受信するステップ」において、補正後発明は「前記第１チャネルから第２チャネルへの変更を示す信号」を受信し「前記第１チャネルから第２チャネルへの変更」を行うことによりその結果として、受信するコンテンツ、すなわち、ストリーミングデータを変更するものであるのに対し、引用発明は「配信サーバ１０１にて配信される映像から配信サーバ１０２にて配信される映像に切り替える切り替え要求」という直接コンテンツ、すなわち、ストリーミングデータを変更する要求を受信する点
　
４．判断 
［相違点］について
　上記［相違点］は「第２　補正の却下の決定」「２．本件補正の適合性」「（３）独立特許要件」「オ．一致点・相違点 」で述べた補正後発明と引用発明１との相違点と同じものであるので、「カ．相違点の判断」での判断と同じ理由によって、本願発明の相違点にかかる構成は、当業者が容易に想到できることといえ、また、本願発明の効果は、その構成から当業者が容易に予測し得るものであり、格別顕著なものがあるとは認められない。
　
第５　むすび 
　以上のように、本願の請求項２７に係る発明は、引用例１に記載された発明に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、残る請求項１ないし請求項２６，請求項２８ないし請求項３８に係る発明について特に検討をするまでもなく、本件出願は拒絶をすべきものである。
　
　よって、結論のとおり審決する。