【事件の表示】
　特願２０００−２９０２２１「ストリーミング媒体における制御された追加の選択的オーバーレイの動的配信の方法および装置」拒絶査定不服審判事件〔平成１３年　６月１２日出願公開、特開２００１−１６００７２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯 
　本願は、平成１２年９月２５日（パリ条約による優先権主張１９９９年９月３０日、米国）の出願であって、平成１５年７月７日付で拒絶査定がなされ（発送日同年７月９日）、これに対し、同年１０月１日に拒絶査定不服審判の請求がなされるとともに、同年１０月１日付で手続補正がなされたものである。
　
　
　
第２　平成１５年１０月１日付の手続補正についての補正却下の決定 
［補正却下の決定の結論］ 
 　平成１５年１０月１日付の手続補正を却下する。 
 　
［理由］ 
（１）本件補正後の特許請求の範囲の記載 
 　本件補正により、特許請求の範囲第８項の記載は、 
 「【請求項８】
　サーバからそれぞれのクライアントに調整されたコンテンツ・ストリームを提供する方法であって、
　それぞれのクライアントへのコンテンツの送信中に、それぞれのクライアントのクライアント・プロファイルを生成するコンピュータ実施ステップと、
　複数の関連ストリームから、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信するアドオン・データ・ストリームを選択し、選択された前記アドオン・データ・ストリームをそれぞれのクライアントに送信中の基本データ・ストリームに組み合わせて、コンテンツ・ストリームを形成するコンピュータ実施ステップと、
　それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・ストリームを送信するコンピュータ実施ステップとを含む方法。」 
 　と補正された。 
 　
（２）本件補正前の特許請求の範囲の記載 
 　本件補正後の特許請求の範囲第８項の補正の基礎となっている、本件補正前の、平成１５年６月６日付の手続補正による特許請求の範囲第８乃至１７項の記載は次のとおりである。 
「【請求項８】
　サーバからそれぞれのクライアントに調整されたコンテンツ・ストリームを提供する方法であって、
　それぞれのクライアントのクライアント・プロファイルを生成するコンピュータ実施ステップと、
　複数の関連ストリームから、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信するストリームを選択し、選択された前記ストリームを組み合わせて、コンテンツ・ストリームを形成するコンピュータ実施ステップと、
　それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・ストリームを送信するコンピュータ実施ステップとを含む方法。
【請求項９】
　クライアント・プロファイルを生成するステップが、
　選択されたストリームのセットに関するクライアントにおけるユーザからの入力を収集するステップと、
　その入力をサーバに送信するステップと、
　入力のセットからフィルタを導き出すステップとを含む、請求項８に記載の方法。
【請求項１０】
　クライアント・プロファイルが、少なくとも部分的にクライアント特性に従って導き出される、請求項８に記載の方法。
【請求項１１】
　クライアント特性が場所を含む、請求項１０に記載の方法。
【請求項１２】
　クライアント特性がクライアントの機械の機能を含む、請求項１０に記載の方法。
【請求項１３】
　クライアントからの新規入力によってクライアント・プロファイルの変更を望むことが示されるまで、前のイベントに関して作成された、そのクライアントに関するクライアント・プロファイルを使用して、新規イベントに関してストリームをフィルタリングする、請求項９に記載の方法。
【請求項１４】
　クライアント・プロファイルが特定のタイプのイベントに関して作成される、請求項９に記載の方法。
【請求項１５】
　特定のタイプのイベントがスポーツ・イベントである、請求項１４に記載の方法。
【請求項１６】
　特定のタイプのイベントがコンテンツである、請求項１４に記載の方法。
【請求項１７】
　特定のタイプのイベントが映画である、請求項１４に記載の方法。」 
 　
（３）補正の適否についての判断 
　本件補正が、特許法第１７条の２第４項第２号に掲げる事項である、特許請求の範囲の減縮（同法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）を目的とするものであるか否かについて検討する。 
 　
　補正前の請求項８乃至１７では、「ストリーム」に関して「アドオン・データ・ストリーム」及び「クライアントに送信中の基本データ・ストリーム」という概念は導入されておらず、「コンテンツ・ストリームを形成するコンピュータ実施ステップ」において、「クライアント・プロファイル」に基づいて「複数の関連ストリーム」から選択された「ストリーム」を組み合わせて、「コンテンツ・ストリーム」を形成する技術であったものが、
　補正後の請求項８では、「ストリーム」に関して「アドオン・データ・ストリーム」及び「クライアントに送信中の基本データ・ストリーム」という概念が導入されることにより、「コンテンツ・ストリームを形成するコンピュータ実施ステップ」において、「クライアント・プロファイル」に基づいて「複数の関連ストリーム」から選択された（「コンテンツ・ストリーム」の構成要素であって、「クライアントに送信中の基本データ・ストリーム」に組み合わせるための）「アドオン・データ・ストリーム」と、（「クライアント・プロファイル」に基づいて選択される必要のない）「クライアントに送信中の基本データ・ストリーム」とを組み合わせて「コンテンツ・ストリーム」を形成する技術となった。
　
　つまり、
（Ａ）「ストリーム」に関して「アドオン・データ・ストリーム」及び「クライアントに送信中の基本データ・ストリーム」という概念が導入され、「クライアントに送信中の基本データ・ストリーム」を変更することなく、「アドオン・データ・ストリーム」を変更するものと変更されたことにより、明示はされていないが、発明の課題が、クライアントに送信するためのコンテンツ・ストリームを『新規作成』することから、クライアントに送信しているコンテンツ・ストリーム（即ち、『新規作成』後のコンテンツ・ストリーム）を『動的に修正』することに変更され、補正前と補正後の発明の課題は同一であるとはいえない。
（なお、補正前では、「ストリーム」に関して「アドオン・データ・ストリーム」及び「クライアントに送信中の基本データ・ストリーム」という概念が導入されておらず、「クライアントに送信中の基本データ・ストリーム」を必ずコンテンツ・ストリームに組み合わせるのではないことから、「クライアントに送信中の基本データ・ストリーム」と同じ内容のストリームが「クライアント・プロファイル」に基づいて再度選択されてコンテンツ・ストリームが形成されたとしても、それは結果的にコンテンツ・ストリームを『動的に修正』すると見えるだけで、技術的には、コンテンツ・ストリームを『新規作成』する処理を行っているのに過ぎないといえる。）
　
（Ｂ）補正後の「複数の関連ストリーム」には「クライアントに送信中の基本データ・ストリーム」に相当するストリームは含まれないものとなったことから、補正後の「クライアント・プロファイル」に、「クライアントに送信中の基本データ・ストリーム」と同じ内容のストリームを選択するための情報を含む必要はなくなった。
（つまり、「クライアント・プロファイル」から「クライアントに送信中の基本データ・ストリーム」と同じ内容のストリームを選択するための情報を削除可能になった。）
　
（Ｃ）補正前では、（あるものを組み合わせるためには、２つ以上のものを用意しなくてはならないことは自明であることを鑑みれば）「クライアント・プロファイル」によって選択されるストリームは『２つ以上』である必要があったものが、補正後では、（「クライアントに送信中の基本データ・ストリーム」は必ず組み合わされることを鑑みれば）「クライアント・プロファイル」によって選択されるストリームは『１つ又は２つ以上』で良いものとなった。
　
　よって、上記（Ａ）で指摘した理由により、補正後の請求項８と、補正前の請求項８乃至１７のいずれかに記載した発明とは、発明の解決しようとする課題が同一であるとはいえず、
　また、上記（Ｂ）及び（Ｃ）で指摘した理由により、補正後の請求項８は、補正前の請求項８乃至１７のいずれかに記載した発明を特定するために必要な事項を限定するものであるともいえない。
　
　なお、本件補正後の特許請求の範囲第８項の補正の基礎が、
本件補正前の、平成１５年６月６日付の手続補正による特許請求の範囲第８乃至１７項ではなく、本件補正前の、平成１５年６月６日付の手続補正による特許請求の範囲第１乃至７，３８乃至３９項であるとしても、
　本件補正前の特許請求の範囲第１乃至７，３８乃至３９項においても、「ストリーム」に関して「アドオン・データ・ストリーム」及び「クライアントに送信中の基本データ・ストリーム」という概念は導入されておらず、
　本件補正後の特許請求の範囲第８項と、本件補正前の特許請求の範囲第８乃至１７項について検討した同様の理由により、特許請求の範囲の減縮を目的としたものとはいえない。
　また、本件補正後の特許請求の範囲第８項の補正の基礎が、
　本件補正前の、平成１５年６月６日付の手続補正による特許請求の範囲第８乃至１７項ではなく、本件補正前の、平成１５年６月６日付の手続補正による特許請求の範囲第１８乃至３７、４０乃至４７項であるとしても、
　本件補正後の特許請求の範囲第８項と、本件補正前の特許請求の範囲第１８乃至３７、４０乃至４７項とは、そもそも、発明のカテゴリーが異なるので、特許請求の範囲の減縮を目的としたものとはいえない。
　
　したがって、本件補正は特許請求の範囲の減縮（同法第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）を目的としたものとはいえない。 
　
　また、本件補正が、特許法第１７条の２第４項第１号（請求項の削除）、第３号（誤記の訂正）、第４号（明りょうでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。））に規定される事項を目的とするものでないことは明らかである。 
 　
（４）むすび 
 　以上のとおり、本件補正は、特許法第１７条の２第４項の規定に違反するものであり、特許法第１５９条第１項で準用する特許法第５３条第１項の規定により却下されるべきものである。 
　
　
　
第３　本願発明について 
（１）本願発明
　平成１５年１０月１日付の手続補正は上記のとおり却下されたので、本願の請求項８に係る発明（以下、「本願発明」という。）は、平成１５年６月６日付手続補正書の特許請求の範囲第８項に記載された事項により特定される、以下のとおりのものである。 
 　 
「サーバからそれぞれのクライアントに調整されたコンテンツ・ストリームを提供する方法であって、
　それぞれのクライアントのクライアント・プロファイルを生成するコンピュータ実施ステップと、
　複数の関連ストリームから、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信するストリームを選択し、選択された前記ストリームを組み合わせて、コンテンツ・ストリームを形成するコンピュータ実施ステップと、
　それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・ストリームを送信するコンピュータ実施ステップとを含む方法。」
　
　
（２）引用例 
 　原査定の拒絶の理由に引用された、特開平１０−２５７０５０号公報（以下、「引用例」という。）には、図面と共に次の事項が記載されている。 　
（ア）「【００１２】
　　【発明が解決しようとする課題】
　リアルタイム通信、不特定多数のユーザとの通信、又は長距離通信を行うと、時間当たりの情報量が多くなり、通信回線が混雑しやすい。通信回線が混雑すると、通信速度の遅れが生じ、リアルタイム演奏に支障が生じる。
【００１３】
　また、ユーザの都合に応じて、各ユーザが必要とするデータが異なるが、サーバコンピュータは、ユーザを区別せずに同じデータを送信するので、ユーザが希望するデータを得ることが困難である。
【００１４】
　本発明の目的は、通信回線の混雑を回避することができるデータの通信技術を提供することである。
【００１５】
　本発明の他の目的は、ユーザに応じて必要なデータを送信することができる通信技術を提供することである。
【００１６】
　　【課題を解決するための手段】
　本発明の一観点によれば、ユーザから送信されたユーザ識別子を受信する受信手段と、前記受信手段が受信するユーザ識別子に応じて異なるデータをユーザに送信する送信手段とを有するサーバコンピュータが提供される。
【００１７】
　ユーザからユーザ識別子を受信すれば、ユーザを特定することができるので、ユーザに応じて異なるデータをユーザに送信することができる。」
　
（イ）「【００２１】
　　【発明の実施の形態】
　図１は、楽音情報及び画像情報の通信ネットワークを示す図である。
【００２２】
　演奏会場１には、ＭＩＤＩ楽器２、カメラ４、エンコーダ３、５、及びルータ６が備えられる。演奏会場１では、演奏者がＭＩＤＩ楽器２を演奏する。ＭＩＤＩ楽器２は、演奏者の演奏操作に応じてＭＩＤＩデータを生成し、エンコーダ３に供給する。エンコーダ３は、ＭＩＤＩデータを所定のデータ形式で、ルータ６を介してインターネット上にパケット送信する。
【００２３】
　カメラ４は、演奏者が演奏している様子を撮影し、その様子を画像データとしてエンコーダ５に供給する。エンコーダ５は、画像データを所定のデータ形式で、ルータ６を介してインターネット上にパケット送信する。
【００２４】
　ルータ６は、以下に示すインターネットを介して、ＭＩＤＩデータ及び画像データを送信する。当該データは、電話回線又は専用回線を通り、ルータ６からメインサーバ７に供給され、さらに複数の中継サーバ１２，１３ａ，１３ｂ，・・・に供給され、さらにＷＷＷ（world wide web）サーバ８に供給される。ＷＷＷサーバ８は、いわゆるプロバイダである。
【００２５】
　以下、中継サーバ１２をメイン中継サーバと呼び、中継サーバ１３ａ，１３ｂ，・・・の個々又は全てを総称してミラーサーバ１３と呼ぶ。メイン中継サーバ１２は中継サーバを代表するサーバであり、ミラーサーバ１３はメイン中継サーバ１２と同様な動作を行うサーバである。」
　
（ウ）「【００２７】
　ユーザは、自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じて、ランクを決めることができる。例えば、あるランクでは画像データとＭＩＤＩデータの受信のサービスを受けることができ、他のランクではＭＩＤＩデータのみの受信のサービスを受けることができる。
【００２８】
　ユーザは、予めメイン中継サーバ１２又は送信者（サービス提供者）にランクを指定してサービスの提供を申請すれば、ユーザＩＤを受け取ることができる。メイン中継サーバ１２は、ユーザＩＤとランクを関連付けて記憶する。
【００２９】
　ユーザＡ〜ユーザＤは、例えば、表１に示すユーザＩＤ、パスワード、ランクが与えられる。
【００３０】
　　【表１】
　┏━━━━━━┳━━━━━━━┯━━━━━━━┯━━━━━━┓
　┃　ユーザ名　┃　ユーザＩＤ　│　パスワード　│　ランク　　┃
　┣━━━━━━╋━━━━━━━┿━━━━━━━┿━━━━━━┫
　┃　ユーザＡ　┃　　１４７　　│　ｍｕｓｉｃ　│　ランクＡ　┃
　┠──────╂───────┼───────┼──────┨
　┃　ユーザＢ　┃　　２５８　　│　　ｄｏｇ　　│　ランクＢ　┃
　┠──────╂───────┼───────┼──────┨
　┃　ユーザＣ　┃　　３６９　　│　　ｘｙｚ　　│　ランクＣ　┃
　┠──────╂───────┼───────┼──────┨
　┃　ユーザＤ　┃　　０００　　│　ｇｕｅｓｔ　│　ランクＺ　┃
　┗━━━━━━┻━━━━━━━┷━━━━━━━┷━━━━━━┛
【００３１】
　ユーザＩＤは、ユーザを特定するための識別子である。パスワードは、そのユーザ以外の者の使用を禁ずるための暗証文字又は暗証番号である。ユーザＩＤ「０００」とパスワード「ｇｕｅｓｔ」は、ゲスト用に一般公開される。」
　
（エ）「【００３２】
　ランクＡは、例えば動画の画像データとＭＩＤＩデータの受信のサービスを受けることができる。ランクＢは、例えば静止画の画像データとＭＩＤＩデータの受信のサービスを受けることができる。ランクＣは、例えばＭＩＤＩデータのみの受信のサービスを受けることができる。ランクＺは、ゲスト用のランク（試聴用のランク）であり、ユーザ登録しているか否かにかかわらず、任意のユーザが受けられるサービスのランクである。ランクＺは、例えば時間制限付きのデータの受信、又は一部の演奏パートのＭＩＤＩデータのみの受信のサービスを受けることできる。
【００３３】
　また、ランクに応じて、音質に差を付けてＭＩＤＩデータを送信したり、画質に差を付けて画像データを送信してもよい。具体的には、ＭＩＤＩデータや画像データの一部を間引いたり、ＭＩＤＩデータを一部の演奏パートに限定したり、単位時間当たりに送信する画像の枚数を減らすことができる。
【００３４】
　さらに、ホールでコンサートを行うことを想定し、ユーザを種々の席に割り当てることができる。ユーザの席の位置に応じて、音のバランスや画像の内容に差を設けて、演奏データ又は画像データを送信することができる。」
 　
（オ）「【００３６】
　ユーザは、ホームコンピュータ９を用いて、ＷＷＷサーバ８を通してメイン中継サーバ１２にアクセスすれば、インターネットで上記のＭＩＤＩデータ又は画像データを受信することができる。」
　
（カ）「【００３７】
　具体的には、ユーザは、まずメイン中継サーバ１２にアクセスし、ユーザＩＤとパスワードを入力する。メイン中継サーバ１２は、入力されたユーザＩＤを識別し、表１を参照してユーザのランクを判断する。」
　
（キ）「【００４３】
　中継サーバ１２，１３ａは、４人のユーザＡ〜ユーザＤからのアクセスを同時に受け付けることができ、各ユーザにランクの異なるデータを供給することができる。すなわち、各中継サーバは、全てのユーザに同じデータを供給するのではなく、ユーザＩＤを識別することにより、ユーザに応じたデータを供給することができる。」
　
（ク）「【００８６】
　本実施例は、インターネットを用いることにより、演奏会場における演奏情報（ＭＩＤＩデータ）及び演奏映像（画像データ）を、不特定多数のユーザに供給することができる。ユーザは、演奏会場に赴かなくても、自宅にいながらリアルタイムでＭＩＤＩデータ及び画像データを得ることができる。」
　
　以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。
　
（ａ）引用例の上記（オ）の「ユーザは、ホームコンピュータ９を用いて、ＷＷＷサーバ８を通してメイン中継サーバ１２にアクセスすれば、インターネットで上記のＭＩＤＩデータ又は画像データを受信することができる。」という記載、
　引用例の上記（キ）の「中継サーバ１２，１３ａは、４人のユーザＡ〜ユーザＤからのアクセスを同時に受け付けることができ、各ユーザにランクの異なるデータを供給することができる。すなわち、各中継サーバは、全てのユーザに同じデータを供給するのではなく、ユーザＩＤを識別することにより、ユーザに応じたデータを供給することができる。」という記載、
　引用例の上記（ク）の「本実施例は、インターネットを用いることにより、演奏会場における演奏情報（ＭＩＤＩデータ）及び演奏映像（画像データ）を、不特定多数のユーザに供給することができる。」という記載から、
　引用例には『中継サーバからそれぞれのホームコンピュータにユーザに応じた演奏に関連するデータを供給する方法』が開示されていると認められる。
　
（ｂ）引用例の上記（ウ）の「ユーザは、自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じて、ランクを決めることができる。・・・。メイン中継サーバ１２は、ユーザＩＤとランクを関連付けて記憶する。・・・ユーザＡ〜ユーザＤは、例えば、表１に示すユーザＩＤ、パスワード、ランクが与えられる。」という記載から、
　引用例には『自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じてそれぞれのユーザが決定したランクとユーザＩＤとを関連付けたユーザ情報を生成する中継サーバ実施ステップ」が開示されていると認められる。
　
（ｃ）上記（ｂ）で指摘したように、引用例には『自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じてそれぞれのユーザが決定したランクとユーザＩＤとを関連付けたユーザ情報」が開示されていると認められること、
　引用例の上記（エ）の「ランクＡは、例えば動画の画像データとＭＩＤＩデータの受信のサービスを受けることができる。・・・。ランクＺは、例えば時間制限付きのデータの受信、又は一部の演奏パートのＭＩＤＩデータのみの受信のサービスを受けることできる。・・・また、ランクに応じて、音質に差を付けてＭＩＤＩデータを送信したり、画質に差を付けて画像データを送信してもよい。具体的には、ＭＩＤＩデータや画像データの一部を間引いたり、ＭＩＤＩデータを一部の演奏パートに限定したり、単位時間当たりに送信する画像の枚数を減らすことができる。・・・さらに、ホールでコンサートを行うことを想定し、ユーザを種々の席に割り当てることができる。ユーザの席の位置に応じて、音のバランスや画像の内容に差を設けて、演奏データ又は画像データを送信することができる。」という記載、
　引用例の上記（キ）の「中継サーバ１２，１３ａは、４人のユーザＡ〜ユーザＤからのアクセスを同時に受け付けることができ、各ユーザにランクの異なるデータを供給することができる。すなわち、各中継サーバは、全てのユーザに同じデータを供給するのではなく、ユーザＩＤを識別することにより、ユーザに応じたデータを供給することができる。」という記載、
　引用例の上記（ク）の「本実施例は、インターネットを用いることにより、演奏会場における演奏情報（ＭＩＤＩデータ）及び演奏映像（画像データ）を、不特定多数のユーザに供給することができる。」という記載から、
　引用例には『演奏に関連する動画の画像データ及びＭＩＤＩデータから、ランクとユーザＩＤとを関連付けたそれぞれのユーザ情報に基づいてそれぞれのホームコンピュータに送信するデータを選択し、選択された前記データを組み合わせてユーザに応じた演奏に関連するデータを形成する中継サーバ実施ステップ』が開示されていると認められる。
　
（ｄ）引用例の上記（オ）の「ユーザは、ホームコンピュータ９を用いて、ＷＷＷサーバ８を通してメイン中継サーバ１２にアクセスすれば、インターネットで上記のＭＩＤＩデータ又は画像データを受信することができる。」という記載、
　引用例の上記（キ）の「中継サーバ１２，１３ａは、４人のユーザＡ〜ユーザＤからのアクセスを同時に受け付けることができ、各ユーザにランクの異なるデータを供給することができる。すなわち、各中継サーバは、全てのユーザに同じデータを供給するのではなく、ユーザＩＤを識別することにより、ユーザに応じたデータを供給することができる。」という記載、
　引用例の上記（ク）の「本実施例は、インターネットを用いることにより、演奏会場における演奏情報（ＭＩＤＩデータ）及び演奏映像（画像データ）を、不特定多数のユーザに供給することができる。」という記載から、
　引用例には『それぞれのホームコンピュータにそのホームコンピュータ向けに形成されたそれぞれの演奏に関連するデータを送信する中継サーバ実施ステップ』が開示されていると認められる。
　
　以上の引用例の記載によれば、引用例には下記の発明（以下、「引用例発明」という。）が開示されていると認められる。
　
「中継サーバからそれぞれのホームコンピュータにユーザに応じた演奏に関連するデータを供給する方法であって、
　自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じてそれぞれのユーザが決定したランクとユーザＩＤとを関連付けたユーザ情報を生成する中継サーバ実施ステップ、
　演奏に関連する動画の画像データ及びＭＩＤＩデータから、ランクとユーザＩＤとを関連付けたそれぞれのユーザ情報に基づいてそれぞれのホームコンピュータに送信するデータを選択し、選択された前記データを組み合わせてユーザに応じた演奏に関連するデータを形成する中継サーバ実施ステップ、
　それぞれのホームコンピュータにそのホームコンピュータ向けに形成されたそれぞれの演奏に関連するデータを送信する中継サーバ実施ステップとを含む方法。」
　
　
（３）対比
　そこで、本願発明と引用例発明とを対比する。
　　
　引用例発明の「中継サーバ」は、本願発明の「サーバ」に相当する。
　
　引用例発明の「ホームコンピュータ」は、本願発明の「クライアント」に相当する。
　
　引用例発明の「演奏に関連するデータ」と、
　本願発明の「コンテンツ・ストリーム」とは、
　『コンテンツ・』データである点で共通し、
　本願発明はデータとして「ストリーム」を取り扱うのに対し、引用例発明ではデータとして「ストリーム」を取り扱うのか否かが不明瞭である点で相違する（以下、「相違点」という）。
　
　引用例発明の「ユーザに応じた演奏に関連するデータ」は、演奏に関連するデータがユーザに応じて調整されていることから、
　引用例発明の「中継サーバからそれぞれのホームコンピュータにユーザに応じた演奏に関連するデータを供給する方法」と、
　本願発明の「サーバからそれぞれのクライアントに調整されたコンテンツ・ストリームを提供する方法」とは、
　サーバからそれぞれのクライアントに調整されたコンテンツ・『データ』（本願の「ストリーム」の上位概念）を提供する方法である点で共通し、
　本願発明はデータとして「ストリーム」を取り扱うのに対し、引用例発明ではデータとして「ストリーム」を取り扱うのか否かが不明瞭である点で相違する（上記「相違点」と同様）。
　
　引用例発明の「中継サーバ実施ステップ」は、中継サーバというコンピュータが実施するステップなのであるから、本願発明の「コンピュータ実施ステップ」に相当する。
　
　引用例発明の「自己が所有するホームコンピュータの性能、自己が受けたいサービスの程度、又はデータ受信に対する対価を支払えるか否か等に応じてそれぞれのユーザが決定したランクとユーザＩＤと関連付けたユーザ情報」は、自己が所有するホームコンピュータの性能に関連する情報を含んでいるのであるから、
　本願発明の「それぞれのクライアントのクライアント・プロファイル」に相当する。
　
　引用例発明の「ユーザ情報を生成する中継サーバ実施ステップ」は、
　本願発明の「クライアント・プロファイルを生成するコンピュータ実施ステップ」に相当する。
　
　引用例発明の「演奏に関連する動画の画像データ及びＭＩＤＩデータから、ランクとユーザＩＤとを関連付けたそれぞれのユーザ情報に基づいてそれぞれのホームコンピュータに送信するデータを選択し、選択された前記データを組み合わせてユーザに応じた演奏に関連するデータを形成する中継サーバ実施ステップ」と、
　本願発明の「複数の関連ストリームから、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信するストリームを選択し、選択された前記ストリームを組み合わせて、コンテンツ・ストリームを形成するコンピュータ実施ステップ」とは、
　複数の関連『データ』（本願発明の「ストリーム」の上位概念）から、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信する『データ』（本願発明の「ストリーム」の上位概念）を選択し、選択された前記データ組み合わせてコンテンツ・『データ』（本願発明の「ストリーム」の上位概念）を形成する中継サーバ実施ステップである点で共通し、
　本願発明はデータとして「ストリーム」を取り扱うのに対し、引用例発明ではデータとして「ストリーム」を取り扱うのか否かが不明瞭である点で相違する（上記「相違点」と同様）。
　
　引用例発明の「それぞれのホームコンピュータにそのホームコンピュータ向けに形成されたそれぞれの演奏に関連するデータを送信する中継サーバ実施ステップ」と、
　本願発明の「それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・ストリームを送信するコンピュータ実施ステップ」とは、
　それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・『データ』（本願発明の「ストリーム」の上位概念）を送信するコンピュータ実施ステップである点で共通し、
　本願発明はデータとして「ストリーム」を取り扱うのに対し、引用例発明ではデータとして「ストリーム」を取り扱うのか否かが不明瞭である点で相違する（上記「相違点」と同様）。
　
　したがって、両者は、
「サーバからそれぞれのクライアントに調整されたコンテンツ・データを提供する方法であって、
　それぞれのクライアントのクライアント・プロファイルを生成するコンピュータ実施ステップ、
　複数の関連データから、それぞれのクライアント・プロファイルに基づいてそれぞれのクライアントに送信するデータを選択し、選択された前記データ組み合わせてコンテンツ・データを形成する中継サーバ実施ステップ、
　それぞれのクライアントにそのクライアント向けに形成されたそれぞれの前記コンテンツ・データを送信するコンピュータ実施ステップとを含む方法」
　の点で一致し、　
　本願発明はデータとして「ストリーム」を取り扱うのに対し、引用例発明ではデータとして「ストリーム」を取り扱うのか否かが不明瞭である点で相違する。
　
　
（４）相違点の判断
　
　引用例発明では、動画の画像データやＭＩＤＩデータが、ストリーミング技術（ファイルをダウンロードするのと同時に、再生をすることにより、待ち時間を大幅に短縮する技術）が採用された「ストリーム」であるか否かは不明瞭ではあるものの、
　引用例の上記（ク）にある「本実施例は、インターネットを用いることにより、演奏会場における演奏情報（ＭＩＤＩデータ）及び演奏映像（画像データ）を、不特定多数のユーザに供給することができる。ユーザは、演奏会場に赴かなくても、自宅にいながらリアルタイムでＭＩＤＩデータ及び画像データを得ることができる。」という記載から、引用例発明では、リアルタイムでＭＩＤＩデータ及び画像データを得る必要があるといえる。
　そして、リアルタイムでデータを得るために、データとして「ストリーム」を用いることは情報処理分野における慣用手段といえる。
　してみると、引用例発明に当該慣用手段を採用して、動画の画像データやＭＩＤＩデータを、ストリーミング技術が採用された「ストリーム」に変更することは、当業者が容易に想到し得ることである。
　
　
（５）むすび
　以上のとおり、本願発明は、引用例発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本願は、他の請求項に係る発明について検討するまでもなく、拒絶されるべきものである。 
　よって、結論のとおり審決する。