【事件の表示】
　特願２０１１−２４３６７０「ユーザのグループへの効率的なデータ配信のための方法及び装置」拒絶査定不服審判事件〔平成２４年　４月　５日出願公開、特開２０１２−　６９１４４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯  
　本願は、平成１９年（２００７年）６月１８日（パリ条約による優先権主張外国庁受理２００６年６月２３日、アメリカ合衆国）を国際出願日とする特願２００９−５１６６６１号の一部を、平成２３年１１月７日に新たな特許出願としたものであって、平成２５年７月１２日付けで拒絶理由通知がなされ、同年１０月２２日付け手続補正がなされたが、同年１１月２９日付けで拒絶査定がなされ、これに対し、平成２６年４月３日付けで拒絶査定不服審判の請求がなされ、同時に手続補正がなされたものである。 
　
　
第２　平成２６年４月３日付けの手続補正についての補正却下の決定  
〔結論〕  
　平成２６年４月３日付けの手続補正を却下する。  
 　  
〔理由〕  
１．補正内容  
　平成２６年４月３日付けの手続補正（以下、「本件補正」と呼ぶ。）は、補正前の特許請求の範囲の請求項１を、補正後の請求項１に変更する補正事項を含むものである。 
　そして、補正前の請求項１及び補正後の請求項１の各記載は、それぞれ、以下のとおりである。 
　なお、＜補正後の請求項１＞における下線は補正箇所を表している。 
　
＜補正前の請求項１＞ 
　　【請求項１】
　情報を配信する方法であって、
　　　ユニキャストによる前記情報の送信に対する１つ又は複数の要求をサーバにおいて検出することと、
　　　前記サーバにおいて、前記１つ又は複数の要求に基づいて、ユニキャストによる前記情報の送信から、ブロードキャストによる前記情報の送信へと切り替えるか否かを判定することと、
　　　前記情報に、マーカを関連付けることと、
　　　前記情報と、前記関連付けられたマーカとを、ブロードキャストによる送信に適切な通信信号に組み込むことと、
　　　前記判定に基づいて、前記通信信号を前記サーバから送信することと
を備える方法。
 　 
 ＜補正後の請求項１＞ 
　　【請求項１】
　情報を配信する方法であって、
　　　ユニキャストによる前記情報の送信に対する１つ又は複数の要求をサーバにおいて検出することと、
　　　前記サーバにおいて、前記１つ又は複数の要求に基づいて、ユニキャストによる前記情報の送信から、ブロードキャストによる前記情報の送信へと切り替えるか否かを判定することと、
　　　前記情報に、マーカを関連付けることと、
　　　前記情報と、前記関連付けられたマーカとを、ブロードキャストによる送信
のため
　　　前記判定に基づいて、前記通信信号を前記サーバから
ブロードキャスト
　
２．本件補正に対する判断  
　上記補正事項のうち、「ブロードキャストによる送信に適切な通信信号に組み込む」を「ブロードキャストによる送信
のため
ブロードキャスト
　そこで、本件補正後の上記請求項１に記載された発明（以下、「本願補正発明」と呼ぶ。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に適合するか）について、以下検討する。  
　
２−１．本願補正発明  
　本願補正発明は、上記「１．」の＜補正後の請求項１＞の欄に記載したとおりのものである。
　
２−２．引用例  
（１）原査定の拒絶の理由に引用された、特開２００２−１１８５５３号公報（以下、「引用例１」という。）には、次の記載がある。
　
「【０００１】
【発明の属する技術分野】本発明は放送システム及びその方法に関し、特にサーバと複数のクライアントとが通信媒体を介して接続され、前記クライアントからの要求に応答して前記サーバが番組データを送信するようにした放送方式に関するものである。
【０００２】
【従来の技術】ネットワーク技術の発達に伴い、従来放送用電波を用いて行われていた放送をネットワーク上で流通させることが可能となってきた。例えば、特開平９−１４９３５４号公報には、ビデオサーバと、クライアントとなるセットトップ・ボックスを高速ネットワークバスで接続し、ユーザからの要求に従い、必要なビデオデータをサーバからクライアントに転送して再生を行う技術が開示されている。また、ユーザはビデオデータの再生をいつでも要求することが可能となっている。
【０００３】
【発明が解決しようとする課題】上述した特開平９−１４９３５４号公報のようなビデオ配送システムでは、サーバとクライアントが１対１で通信を行うため、ｎ（ｎは２以上の整数）台のクライアントからビデオデータの要求を受けた場合にはクライアントが１台の場合に比べｎ倍の通信帯域が必要となる。一方、既存のテレビ放送のように１対多でビデオデータの送信を行っている場合には、クライアントの数によらず一定の通信帯域で済むという利点はあるが、送られてくるビデオデータは予め決められたスケジュールに従って送信されており、任意の時刻にビデオデータを先頭から視聴することが出来ないという欠点や、同サイズのデータを送信する場合には１対１通信よりも１対多通信の方がコストがかかるため、受信するクライアント数が少ない場合には非効率的となるという欠点がある。
【０００４】また、ホームサーバのように放送されてくるビデオデータを、クライアント上の補助記憶装置に蓄積しつつデータの再生を行う形態の場合には、一定の通信帯域で複数のクライアントにビデオデータを送信しつつ、クライアント側でビデオデータの視聴開始時刻を自由に選択することが可能となるが、
（ａ）クライアントに大容量の補助記憶装置が必要になる；
（ｂ）クライアントに蓄積されていないビデオデータは視聴することが出来ない；
といった欠点がある。
【０００５】本発明の目的は、クライアントに一切の補助記憶装置を設けることなく、クライアント側でビデオデータの視聴開始時刻を柔軟に指定可能にし、かつ必要な通信帯域と通信コストを要望に応じて低減する放送システム及びその方法を提供することである。
【０００６】
【課題を解決するための手段】
　
・・・（中略）・・・
　
【００１２】本発明によれば、サーバと複数のクライアントとが通信媒体を介して接続され、前記クライアントからの要求に応答して前記サーバが番組データを送信するようにした放送方法であって、前記サーバにおいて、前記クライアントに対して番組データを送信している期間中に、前記番組データを要求するクラインアントの数の増減に応じて、前記通信媒体の通信方式や通信経路を動的に変更制御する通信媒体変更制御ステップを含むことを特徴とする放送方法が得られる。
【００１３】そして、前記通信媒体変更制御ステップは、前記番組データを要求するクラインアントの数が所定数より小の場合には、１対１通信方式での通信を行い、それ以外の場合には、１対多通信方式に切替えるようにしたことを特徴とし、また前記１対多通信方式はブロードキャスト通信であることを特徴とする。前記１対１通信方式は、通信経路として電話回線を用いた通信であることを特徴とする。
　
・・・（中略）・・・
　
【００２８】
【発明の実施の形態】次に、本発明の実施の形態について図面を参照して詳細に説明する。図１は本実施の形態の放送システムの１構成例を示した図である。この放送システムは、Ｎ個（Ｎは１以上の任意の数で、例えばＮ＝３となっている）の通信経路によって結ばれたサーバ１０とクライアント２０から構成されている。図１では便宜上、クライアントの数は１となっているが、実際には２以上のクライアントが接続されているとして説明する。また、以下の説明では本発明の実施に不可欠な要素についてのみ示し、当業者にとって良く知られている従来品と同一の要素についてはその説明を省略する。
【００２９】図１のサーバ１０は、クライアントに送信する番組データを蓄積しておくデータ蓄積部１１と、データ送信部１５の送信状況とクライアント２０からのリクエスト内容に従い、通信手段の決定を行うリクエスト処理部１２と、リクエスト処理部１２からの指示内容に従いデータ蓄積部１１に蓄積されている番組データのダイジェストを生成するダイジェスト生成部１３と、リクエスト処理部１２からの指示内容に従い通信方式や通信経路の選択指示を行う通信手段選択部１４と、通信手段選択部１４からの指示内容に従いデータ蓄積部１１に蓄積されている番組データやダイジェスト生成部１３が生成した番組データのダイジェストをクライアント２０に送信するデータ送信部１５と、データ蓄積部１１に蓄積する番組データを作成するデータ作成部１６とを備えている。
【００３０】ここで通信手段とは、サーバ１０とクライアント２０とをつなぐ通信経路の種類と、サーバ１０からクライアント２０にデータを送信する際に使用する通信方式の種類のことであり、通信経路の種類とは、例えば、イーサネット（登録商標）や電話回線のような有線回線や、放送用電波や無線通信のような無線回線のことであり、通信方式の種類とは、例えば、１対１で通信を行うユニキャストや、１対多で通信を行うマルチキャストやブロードキャストのことである。
【００３１】番組データとは、クライアント２０の利用者が閲覧する動画や音から構成されるマルチメディアデータのことで、例えば、ＭＰＥＧ２形式の映像データのことである。
【００３２】図１のクライアント２０は、サーバに番組データをリクエストするデータリクエスト部２１と、通信経路を通じてサーバから送られてくる番組データを受信するデータ受信部２２と、１種類以上の通信手段によりサーバから送られてくる番組データの中からデータ受信部２２で受信する番組データの選択指示を行うデータ選択部２３と、データ受信部２２で受信した番組データを利用者に提示するデータ出力部２４とを備えている。
【００３３】次に、上述の放送システムにおいて、番組データを受信するクライアント２０の数が増加した場合の動作内容を図を用いて具体的に説明する。サーバ１０は、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図２に示される処理手順に従い、データ蓄積部１１に蓄積されている番組データの送信を行う。リクエスト処理部１２はリクエストを受け付けると（ステップＳ１）、リクエストされた番組データを送信するために必要な通信帯域とリクエストを受け付けた時点で、すでにデータ送信部１５から同リクエスト番組データを送信しているクライアント２０の数とから決定される状態が、図３のどの領域に存在するかを調べる（ステップＳ２）。
【００３４】ここで、図３は、リクエスト処理部１２が持つ通信手段選択のための判断基準の一例を表したもので、例えば、広い通信帯域を必要とする番組データや送信するクライアントの数が多数の場合、すなわち、図３の領域Ｂに位置する場合には、放送用電波を用いたブロードキャストで番組データの送信を行い、逆に狭い通信帯域で十分な番組データや送信するクライアントの数が少ない場合、すなわち、図３の領域Ａに位置する場合には、電話回線を用いたユニキャストで番組データの送信を行う。
【００３５】クライアント２０から番組データのリクエストを受け付けた時点で、すでに図３の領域Ｂに位置する場合には、同番組データはブロードキャストで送信されている状態にあるので、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しブロードキャストで送信されている番組データの受信を指示する（ステップＳ３，Ｓ４）。
【００３６】クライアント２０から番組データのリクエストを受け付けた時点で、図３の領域Ａに位置する場合には、クライアント数が１増えることで領域Ｂに移行するかどうかを調べる（ステップＳ５）。領域Ｂに移行しない場合には、サーバ１０の通信手段選択部１４はリクエストを行ったクライアント２０に対しユニキャストで送信される番組データの受信を指示し（ステップＳ６）、データ送信部１５からクライアント２０に対してユニキャストで同番組データの送信を開始する（ステップＳ７）。
【００３７】一方、クライアント数が１増えたことで、図３の領域Ａから領域Ｂに移行する場合には、サーバ１０の通信手段選択部１４は、同リクエスト番組データを受信している全てのクライアント２０に対し、通信手段をユニキャストからブロードキャストに切り替える指示を出し（ステップＳ８）、さらに、通信手段選択部１４はデータ送信部１５に同番組データの送信をユニキャストからブロードキャストに切り替えるよう指示を出す。また、リクエストを行ったクライアント２０に対してはブロードキャストで送信される番組データの受信を指示する。
【００３８】クライアント２０は利用者から番組データのリクエストを受け付け、図４に示される処理手順に従い番組データの受信を行う。データリクエスト部２１は、利用者からのリクエストに従い、希望する番組データをサーバ１０に対しリクエストする（ステップＳ１１）。リクエストを送信した後、データ選択部２３はサーバ１０から送られてくる番組データを受信するために使用する通信手段の指示を待ちうけ（ステップＳ１２）、送られてきた通信手段に関する指示をデータ受信部２２に受け渡す。
【００３９】データ受信部２２はデータ選択部２３からの指示に従いブロードキャストで送信される番組データ、あるいはユニキャストで送信される番組データの受信を行い、受信した番組データをデータ出力部２４に受け渡す。データ出力部２４はデータ受信部２２から受け渡された番組データを、例えばディスプレイやスピーカのような既存のデータ出力機器を用いて利用者に提示する。」
　
 　ここで、上記記載事項を引用例１の関連図面と技術常識に照らせば、以下のことがいえる。 
　
ア．段落【００１２】でいう「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法」は、段落【００３３】に示されるように、「サーバ１０が、リクエスト処理部１２でクライアント２０からの番組データリクエストを常時待ちうけておき、リクエストがあった場合には、図２に示される処理手順に従い、データ蓄積部１１に蓄積されている番組データの送信を行う」といった動作を想定したものであり、「クライアントからの要求をサーバにおいて検出すること」といい得る工程を当然に有している。　
　
イ．段落【００１２】、【００１３】、【００３７】等の記載によれば、上記「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法」は、「サーバにおいて、クライアントからの要求に基づいて、ユニキャストによる番組データの送信から、ブロードキャストによる番組データの送信へと切り替えるか否かを判定すること」といい得る工程も当然に有している。
　
ウ．一般にブロードキャストは、ブロードキャストすべきデータを「ブロードキャストによる送信のために適切な通信信号」といい得る信号に組み込んで行うのが普通であり、引用例１でいうブロードキャストをそのような普通のブロードキャストとは異なるものと解すべき理由はないから、引用例１でいうブロードキャストも、ブロードキャストすべき番組データを「ブロードキャストによる送信のために適切な通信信号」といい得る信号に組み込んで行うものと理解される。
　したがって、上記「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法」は、「番組データを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」といい得る工程も有しているといえる。
　
エ．段落【００１２】、【００１３】、【００３７】等の記載によれば、上記「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法」は、上記イ．の工程での「判定」に基づいて、上記ウ．でいう「通信信号」を「前記サーバからブロードキャストすること」という工程も当然に有している。
　
　したがって、引用例１には、次の発明（以下、「引用例１発明」という。）が記載されているといえる。
　
「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法であって、
　　　クライアントからの要求をサーバにおいて検出することと、
　　　前記サーバにおいて、前記クライアントからの要求に基づいて、ユニキャストによる前記番組データの送信から、ブロードキャストによる前記番組データの送信へと切り替えるか否かを判定することと、
　　　前記番組データを、ブロードキャストによる送信のために適切な通信信号に組み込むことと、
　　　前記判定に基づいて、前記通信信号を前記サーバからブロードキャストすることとを備える方法。」
　
（２）原査定の拒絶の理由に引用された、特開２００２−２５９４３０号公報（以下、「引用例２」という。原査定においては引用文献４として引用された文献である。）には、次の記載がある。
「【要約】
【課題】  配信されるコンテンツをフィルタリングして選択的にダウンロードすることにより、ユーザが必要とするコンテンツをダウンロードすると共に、不要なコンテンツのダウンロードを抑制することができるコンテンツ選択受信装置、コンテンツ選択受信方法及びコンテンツ選択受信プログラムを提供すること。
【解決手段】  ユーザが受信するコンテンツの属性を設定する第１フィルタと、ユーザのコンテンツ利用状況を記録したログからユーザの好まないコンテンツの属性を推定し、当該属性を有するコンテンツの受信を行わないようにする第２フィルタを設置する。そして、コンテンツの配信を受けるときに、コンテンツの属性を第１フィルタでフィルタリングした後、更に第２フィルタでフィルタリングする。第１フィルタと第２フィルタの双方を通過したコンテンツをキャッシュする。」
　
「【０００１】
【発明の属する技術分野】本発明は、コンテンツ選択受信装置、コンテンツ選択受信方法及びコンテンツ選択受信プログラムに関し、例えば、ネットワークを介して配信されるコンテンツを選択的に受信するものに関する。
【０００２】
【従来の技術】
　
・・・（中略）・・・
　
【０００５】ＳＴＢには、ハードディスクを内蔵したものがあり、ブロードキャスト（配信）されたコンテンツはこのハードディスクに記憶される。ユーザは、メニュー画面（これもコンテンツとして配信される）をデジタルテレビの画面上に表示し、視聴を希望するコンテンツを検索し、選択するようになっている。
【０００６】
【発明が解決しようとする課題】しかし、一斉配信によって送られたコンテンツは大容量となり、また、ＰＣやＳＴＢの記憶容量には限度があるため、配信されるコンテンツを全て記憶することができない場合がある。このため、記憶したデータの容量がある一定量を超えると、先に記憶したコンテンツを消去し、あとから配信されるコンテンツを記憶するようになっているＰＣやＳＴＢがある。
【０００７】そして、ユーザがダウンロードしたコンテンツを利用するときに、目的のコンテンツが消去されている場合は、再度ダウンロードを行わなくてはならない。このように、従来のシステムでは、コンテンツ使用時に、目的のコンテンツが記憶装置に記憶されている確率が低くなり、ユーザの利便性が損なわれるという問題があった。また、ダウンロードするコンテンツを選別するある種のフィルタをＰＣやＳＴＢに設置し、ユーザがこのフィルタを通過できるコンテンツの種類などを設定する場合、ユーザが選択できるコンテンツの範囲を必要以上に狭めてしまい、フィルタによって選択されなかったコンテンツの中にユーザの目的とするものがある場合がある。
【０００８】そこで、本発明の目的は、配信されるコンテンツを適切にフィルタリングして選択的にダウンロードすることにより、ユーザが必要とするコンテンツをダウンロードすると共に、不要なコンテンツのダウンロードを抑制することができるコンテンツ選択受信装置、コンテンツ選択受信方法及びコンテンツ選択受信プログラムを提供することである。
　
・・・（中略）・・・
　
【００２４】図３中破線より左側はＰＣ９内を示しており、右側はコンテンツサーバ側を示している。なお、図３では、簡略化のためインターネット７などを省略してある。コンテンツ選択受信システム２１は、フィルタシステム部３４を有している。フィルタシステム部３４はコンテンツサーバ６から配信されるコンテンツをフィルタリングすることにより選別する機能を提供する部分である。
【００２５】コンテンツサーバ６は、コンテンツ配信業者５が設置したものであり、インターネット７などを介してユーザにコンテンツの配信を行う。このコンテンツサーバ６は、コンテンツデータベース３９、属性データベース４０を備えている。コンテンツデータベース３９、属性データベース４０は、物理的には、例えばハードディスクなどの記憶装置から構成されている。コンテンツデータベース３９には、様々なコンテンツ、コンテンツ１、コンテンツ２、コンテンツ３、・・・が記憶されている。属性データベースには、後に説明するコンテンツの属性を表す属性情報、属性１、属性２、属性３、・・が記憶されている。
【００２６】これらのコンテンツと属性情報はあらかじめ関連付けられており、コンテンツデータベース３９と属性データベース４０は、リレーショナルデータベースを構成している。そして、コンテンツサーバ６は、コンテンツを配信するときに、当該コンテンツに関連付けられた属性情報を属性データベース４０から読出し、これをヘッダ情報に付加して配信するようになっている。
【００２７】属性情報が表す属性としては、例えば、タイトル、カテゴリ、タイプ、性別、年齢層、などがある。タイトルは、コンテンツのタイトルを表す。カテゴリは、音楽、映画、スポーツ、ゲーム、フトウェア、文書ファイルなどのコンテンツの属するカテゴリを表す。タイプは、コンテンツがゲームならロールプレイングゲーム、シューティングなどを、また、コンテンツが音楽ならポップミュージック、クラシック、演歌などを表す。性別は、男性向けのコンテンツ、女性向のコンテンツなど、コンテンツの利用対象となる性別を表す。年齢層は、幼児向けコンテンツ、若年層向けコンテンツ、中高年向けコンテンツなど、コンテンツの利用対象となる年齢層を表す。以上の属性は一例であり、この他にも種々の属性を設定することができる。
　
・・・（中略）・・・
　
【００３０】フィルタ生成部３１は、ユーザ設定情報４１に保持されているデータから第１フィルタ３５を通過できるコンテンツの属性を設定する。第１フィルタは、ユーザが設定した属性情報を用いてコンテンツサーバ６から配信されるコンテンツをフィルタリングする。例えば、ユーザが、カテゴリの属性としてゲーム、音楽、映画を設定したとすると、第１フィルタ３５は、コンテンツサーバ６が配信するコンテンツの内、ゲーム、音楽、映画コンテンツを通過させ、他のカテゴリーの属性を有するコンテンツが受信されないようにする。」
　
２−３．対比 
　本願補正発明と引用例１発明とを対比すると、次のことがいえる。
（１）引用例１発明の「番組データ」は、本願補正発明の「情報」に相当し、引用例１発明の「クライアントからの要求に応答してサーバが番組データを送信するようにした放送方法」は、本願補正発明と同様に「情報を配信する方法」ともいい得る。
　
（２）本願発明の構成と、本願明細書の記載によれば、本願補正発明でいう「ユニキャストによる前記情報の送信に対する１つ又は複数の要求」は、「各デバイスが自己宛に情報を送信することをサーバに対して求める要求であって、サーバがブロードキャストによる情報の送信へと切り替える旨の判定をしない場合には、ユニキャストによる情報の送信という形での応答がなされるが、サーバがブロードキャストによる情報の送信へと切り替える旨の判定をした場合にはブロードキャストによる情報の送信という形での応答がなされるような要求」であると解される。
　一方、引用例１発明の構成と、引用例１の段落【００３８】、【００３９】等の記載からみて、引用例１発明の「クライアントからの要求」も、「各デバイスといえるクライアントが自己宛に情報を送信することをサーバに対して求める要求であって、サーバがブロードキャストによる情報の送信へと切り替える旨の判定をしない場合には、ユニキャストによる情報の送信という形での応答がなされるが、サーバがブロードキャストによる情報の送信へと切り替える旨の判定をした場合にはブロードキャストによる情報の送信という形での応答がなされるような要求」である。
　したがって、引用例１発明でいう「クライアントからの要求」は、本願補正発明でいう「ユニキャストによる前記情報の送信に対する１つ又は複数の要求」に相当し、引用例１発明の「クライアントからの要求をサーバにおいて検出すること」は、本願補正発明の「ユニキャストによる前記情報の送信に対する１つ又は複数の要求をサーバにおいて検出すること」に相当する。
　
（３）上記（１）（２）で言及した事項を踏まえると、引用例１発明の「前記サーバにおいて、前記クライアントからの要求に基づいて、ユニキャストによる前記番組データの送信から、ブロードキャストによる前記番組データの送信へと切り替えるか否かを判定すること」は、本願補正発明の「前記サーバにおいて、前記１つ又は複数の要求に基づいて、ユニキャストによる前記情報の送信から、ブロードキャストによる前記情報の送信へと切り替えるか否かを判定すること」に相当する。
　
（４）引用例１発明の「前記番組データを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」という工程と本願補正発明の「前記情報と、前記関連付けられたマーカとを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」という工程とは、「前記情報を、ブロードキャストによる送信のために適切な通信信号に組み込むこと」といい得る工程である点で共通する。
　
（５）引用例１発明の「前記判定に基づいて、前記通信信号を前記サーバからブロードキャストすること」は、本願補正発明の「前記判定に基づいて、前記通信信号を前記サーバからブロードキャストすること」に相当する。
　
　したがって、本願補正発明と引用例１発明の間には次の一致点、相違点があるといえる。 
 　 
（一致点） 
「情報を配信する方法であって、
　　　ユニキャストによる前記情報の送信に対する１つ又は複数の要求をサーバにおいて検出することと、
　　　前記サーバにおいて、前記１つ又は複数の要求に基づいて、ユニキャストによる前記情報の送信から、ブロードキャストによる前記情報の送信へと切り替えるか否かを判定することと、
　　　前記情報を、ブロードキャストによる送信のために適切な通信信号に組み込むことと、
　　　前記判定に基づいて、前記通信信号を前記サーバからブロードキャストすることとを備える方法。」である点。
　
（相違点１）
　本願補正発明は、「前記情報に、マーカを関連付けること」という工程を有するのに対し、引用例１発明は、それに相当する工程を有していない点。
　
（相違点２）
　本願補正発明の「前記情報を、ブロードキャストによる送信のために適切な通信信号に組み込むこと」といい得る工程（以下、「工程Ａ」という。）は、「前記情報」と「前記関連付けられたマーカ」の両方を「ブロードキャストによる送信のために適切な通信信号」に組み込むものであるのに対し、引用例１発明の工程Ａは、「前記関連付けられたマーカ」までを「ブロードキャストによる送信のために適切な通信信号」に組み込むものではない点。
　
２−４．判断 
　
（１）上記相違点１、２について 
　以下の事情を総合すると、引用例１発明において、上記相違点１、２に係る本願補正発明の構成を採用することは、当業者が容易に推考し得たことというべきである。
　
ア．上記２−２．（２）に摘記した引用例２の記載によれば、「コンテンツのブロードキャストによる配信を受ける装置においてコンテンツに対する適切なフィルタリングができるように、送信側で、ブロードキャストするコンテンツに当該コンテンツのタイトル、カテゴリ、タイプ、性別、年齢層等の属性情報を関連付けておき、コンテンツを配信する際に、コンテンツに対して当該コンテンツに関連する属性情報を付加して配信するようにする」という技術（以下、「引用例２記載の技術」という。）は、本願出願前に公知であったものと認められ、そこでいう「コンテンツ」、「属性情報」は、それぞれ、本願補正発明でいう「情報」、「マーカ」に相当するものといえる。
　
イ．一方、引用例１発明も情報をブロードキャストすることがある方法であり、そのブロードキャストの際に上記引用例２記載の技術が有用であることは、当業者に明らかである。
　また、引用例１発明において、上記引用例２記載の技術を採用できない理由もない。
　
ウ．してみれば、引用例１発明において上記引用例２記載の技術を採用することは、当業者が容易に想到し得たことである。
　そして、引用例１発明において上記引用例２記載の技術を採用するということは、引用例１発明におけるサーバ側で、ブロードキャストする番組データに当該番組データの属性情報を関連付けておき、番組データをブロードキャストにより配信する際に、番組データに対して当該番組データに関連する属性情報を付加して配信するようにすることを意味するが、ブロードキャストする番組データに当該番組データの属性情報を関連付けておくために、引用例１発明に「番組データに、属性情報を関連付けること」といい得る工程を設けるのは当然のことであるし、番組データに対して当該番組データに関連する属性情報を付加して配信するようにする場合に、引用例１発明における「番組データを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」という工程を「番組データと、関連付けられた属性情報とを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」といい得る工程に変更するのはごく自然なことである。
　
エ．以上のことは、引用例１発明を「前記情報に、マーカを関連付けること」という工程を有するものとし、引用例１発明の工程Ａを、「前記情報」と「前記関連付けられたマーカ」の両方を「ブロードキャストによる送信のために適切な通信信号」に組み込むものとすること、換言すれば、引用例１発明において上記相違点１、２に係る本願補正発明の構成を採用することが、当業者にとって容易であったことを意味する。
　
（２）本願補正発明の効果について 
　本願補正発明の構成によってもたらされる効果は、引用例１発明及び引用例２記載の技術から当業者が容易に想到し得た構成のものが奏するであろうと当業者が予測し得る範囲を超えるものではなく、本願補正発明の進歩性を肯定する根拠となり得るものではない。
　
（３）まとめ 
　以上のとおりであるから、本願補正発明は、引用例１発明及び引用例２記載の技術に基づいて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
　なお、仮に、引用例１発明として「前記番組データを、ブロードキャストによる送信のために適切な通信信号に組み込むこと」という工程を有するものまでは認めることができず、本願補正発明が「前記情報を、ブロードキャストによる送信のために適切な通信信号に組み込むこと」といい得る工程を有している点は本願補正発明と引用例１発明の間の相違点であると考えたとしても、番組データをブロードキャストする際に、番組データを「ブロードキャストによる送信のために適切な通信信号」といい得る通信信号に組み込んでブロードキャストするようにすることはごく普通のことであり、引用例１発明をそのような工程を有するものとすることは当業者が容易に推考し得たことと考えられるから、上記（３）の結論は変わらない。
  
３．むすび 
　したがって、本件補正は、特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　
第３　本願発明について 
　
１．本願発明 
　本件補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」と呼ぶ。）は、平成２５年１０月２２日付けの手続補正書の請求項１に記載されたとおりのものであり、上記「第２」の「１．」の＜補正前の請求項１＞の欄に転記したとおりのものである。 
　
２．引用例 
　原査定の拒絶の理由に引用された引用例、およびその記載事項は、上記「第２」の「２．」の「２−２．」の欄に記載したとおりである。 
 　 
３．対比・判断 
　本願発明は、上記「第２」で検討した本願補正発明から、限定事項の一部を省いたものである。 
　そうすると、本願発明の構成要件をすべて含み、さらに特定の限定を施したものに相当する本願補正発明が、上記「第２」の「２．」の欄に記載したとおり、引用例１発明及び引用例２記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用例１発明及び引用例２記載の技術に基づいて、当業者が容易に発明をすることができたものである。 
　
４．むすび 
　以上のとおり、本願発明は、引用例１発明及び引用例２記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。 
　よって、結論のとおり審決する。