【事件の表示】
　特願２０１０−２３５３７１「マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置」拒絶査定不服審判事件〔平成２３年　３月　３日出願公開，特開２０１１−　４５１２６〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２００６年４月１０日（パリ条約による優先権主張外国庁受理　２００５年４月８日　米国，２００６年４月６日　米国）を国際出願日とする出願である特願２００８−５０５６２１号の一部を，平成２２年１０月２０日に新たな特許出願としたものであって，平成２５年９月２５日付けで拒絶査定がなされ，これに対し，平成２６年２月３日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされ，当審による同年１０月３１日付けで通知された拒絶理由に対して，平成２７年２月２日付けで手続補正がなされたものである。
第２　特許請求の範囲の記載
　平成２７年２月２日付け手続補正書により補正された特許請求の範囲の請求項１ないし２０には，次のとおり記載されている。
「【請求項１】
　(a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって，
　(a2)アウトオブバンドの通信セッションにおいて，前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を受信することと，
　(a3)前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に受信した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　(a4)ここにおいて，前記複数のファイル属性は，前記少なくとも１つのファイルよりも先に受信され，また前記処理することは，前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく，前記少なくとも１つのファイルよりも先に受信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築することを含む，
　(a5)前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに，
　(a6)前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　(a7)前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，を備える，
　方法。
【請求項２】
　第１通信チャネルを通して前記複数のファイル属性を受信することと，
　前記少なくとも１つのファイルを第２通信チャネルを通して受信することと，をさらに備える，請求項１に記載の方法。
【請求項３】
　前記インバンドの通信セッション内で，前記ブロードキャストのために複数のファイルを連続的に受信することと，前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッション内で前記複数のファイルを処理するために，前記複数のファイル属性を受信することとをさらに備える，請求項１に記載の方法。
【請求項４】
　インターネットプロトコル（ＩＰ）をサポートする通信システム内でブロードキャストを受信するように構成された装置であって，前記装置は，
　アウトオブバンドの通信セッションにおいて，前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を受信する手段と，
　前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に取得した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信する手段と，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記少なくとも１つのファイルよりも先に受信され，また前記処理することは，前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく，前記少なくとも１つのファイルよりも先に受信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築することを含む，
　第１通信チャネルを通して前記複数のファイル属性を受信する手段と，
　第２通信チャネルを通して前記少なくとも１つのファイルを受信する手段と，
　を備える装置。
【請求項５】
　前記複数のファイル属性は第１通信チャネルを通して受信され，
　前記少なくとも１つのファイルは第２通信チャネルを通して受信される，請求項４に記載の装置。
【請求項６】
　インターネットプロトコル（ＩＰ）をサポートする通信システム内のブロードキャストにおいて使用される装置であって，前記装置は，
　プロセッサと，
　前記プロセッサに結合したメモリユニットとを備え，前記メモリユニットは，
　アウトオブバンドの通信セッションにおいて前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するための複数のファイル属性を受信することと，
　前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に取得した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを受信することと，
　ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記少なくとも１つのファイルよりも先に受信され，また前記処理することは，前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく，前記少なくとも１つのファイルよりも先に受信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築することを含む，
　第１ポート番号を介し，前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記複数のファイル属性を受信することと，第２ポート番号を介して，前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを受信することと
　のためのコンピュータ読み出し可能な命令を含む，
装置。
【請求項７】
　前記メモリユニットは，第１通信チャネルを通して前記複数のファイル属性を受信するための，及び前記少なくとも１つのファイルを第２通信チャネルを通して受信するためのコンピュータ読み出し可能な命令とをさらに備える，請求項６に記載の装置。
【請求項８】
　前記メモリユニットはさらに，前記インバンドの通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信するための，及び前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッションにおいて，前記複数のファイルを処理するための前記複数のファイル属性を受信するための，コンピュータ読み出し可能な命令とを備える，請求項６に記載の装置。
【請求項９】
　コンピュータ読み出し可能な命令を含むコンピュータ読み出し可能な記録媒体であって，
　インターネットプロトコル（ＩＰ）をサポートする通信システム内のアウトオブバンドの通信セッションにおいてブロードキャストの少なくとも１つのファイルのコンテンツを処理するための複数のファイル属性を受信することと，
　前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に受信した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，
　ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記少なくとも１つのファイルよりも先に受信され，また前記処理することは，前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく，前記少なくとも１つのファイルよりも先に受信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築することを含む，
　前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，
　のためのコンピュータ読み出し可能な命令を含むコンピュータ読み出し可能な記録媒体。
【請求項１０】
　インターネットプロトコル（ＩＰ）をサポートする通信システム内でブロードキャストのファイルを送達する装置であって，前記装置は，
　アウトオブバンドの通信セッションにおいて，加入者ノードへ前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を送信する手段と，
　インバンドの通信セッションにおいて，前記加入者ノードへ前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを送信する手段と，
　ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく，前記少なくとも１つのファイルよりも先に送信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも１つのファイルよりも先に送信される，
　第１ポート番号を介し，前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して前記複数のファイル属性を送信する手段と，
　第２ポート番号を介し，前記ＩＰの前記ＵＤＰを通して前記少なくとも１つのファイルを送信する手段と，を備える装置。
【請求項１１】
　前記複数のファイル属性は，第１通信チャネルを通して送信され，
　前記少なくとも１つのファイルは，第２通信チャネルを通して送信される，請求項１０に記載の装置。
【請求項１２】
　前記複数のファイル属性は第１のアドレスを介して送信され，前記少なくとも１つのファイルは第２のアドレスを介して送信され，前記第２のアドレスは前記第１のアドレスと異なる，請求項１０に記載の装置。
【請求項１３】
　前記複数のファイル属性は第１のアドレスを介して送信され，前記少なくとも１つのファイルは第２のアドレスを介して送信され，前記第１および第２のアドレスは同じであるが，前記第１および第２のポート番号は異なる，
　請求項１０に記載の装置。
【請求項１４】
　前記インバンドの通信セッション内で，前記ブロードキャストのために複数のファイルを連続的に送信し，前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッション内で前記複数のファイルを処理するために，前記複数のファイル属性を送信する手段をさらに備える，請求項１０に記載の装置。
【請求項１５】
　前記複数のファイル属性は，永続するファイル属性と短命のファイル属性とを備える，請求項１０に記載の装置。
【請求項１６】
　通信システム内のブロードキャストのファイルを送達する方法であって，前記方法は，
　アウトオブバンドの通信セッションにおいて，加入者ノードへ前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を送信することと，
　インバンドの通信セッションにおいて，前記加入者ノードへ前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを送信することと，を備え，
　ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく，前記少なくとも１つのファイルよりも先に送信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも１つのファイルよりも先に送信される，
　前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに，
　前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して送信することと，
　前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して送信することと，を備える，
　方法。
【請求項１７】
　第１通信チャネルを通して前記複数のファイル属性を送信することと，
　前記少なくとも１つのファイルを第２通信チャネルを通して送信することと，をさらに備える，請求項１６に記載の方法。
【請求項１８】
　前記複数のファイル属性は，永続するファイル属性と短命のファイル属性とを備える，請求項１６に記載の方法。
【請求項１９】
　インターネットプロトコル（ＩＰ）をサポートする通信システム内のブロードキャストにおいて使用される装置であって，前記装置は，
　プロセッサと，
　前記プロセッサに結合したメモリユニットとを備え，前記メモリユニットは，
　アウトオブバンドの通信セッションにおいて加入者ノードへ前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するための複数のファイル属性を送信することと，
　インバンドの通信セッションにおいて，前記加入者ノードへ前記複数のファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを送信することと，
　ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　ここにおいて，前記複数のファイル属性は，前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく，前記少なくとも１つのファイルよりも先に送信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも１つのファイルよりも先に送信される，
　前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して送信することと，
　前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して送信することと，
　のためのコンピュータ読み出し可能な命令を含む，
装置。
【請求項２０】
　前記メモリユニットは，第１通信チャネルを通して前記複数のファイル属性を送信するための，及び前記少なくとも１つのファイルを第２通信チャネルを通して送信するためのコンピュータ読み出し可能な命令とをさらに備える，請求項１９に記載の装置。
」
第３　当審における拒絶の理由
　当審において，平成２６年１０月３１日付けで通知した拒絶の理由は，以下のとおりである。
「１）本件出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
２）本件出願は，特許請求の範囲の記載が下記の点で不備のため，特許法第３６条第６項第１号，及び第２号に規定する要件を満たしていない。
　　　　　記　　　（引用文献等については引用文献等一覧参照）
理由１）について
請求項　１−２０
引用例等　１
備考
　引用文献１，特に，段落【０００１】，【００２７】，図１乃至図４の説明である段落【００８４】ないし【０１１２】，【０１４２】，【０１４６】ないし【０１５０】，図３５には以下の発明（以下「引用発明」という。）が記載されている。
「コンテンツ通信サーバ１０は，インターネット２を介して，受信端末２０へ，音声情報，映像情報，カルセールデータからなる放送メディアの再生に先だって，放送メディアのレイアウト情報やタイミング情報を含む再生情報を送信し，受信端末２０は，放送メディアの再生に先だって，前記再生情報を受信して放送メディアを再生する放送通信システムにおいて，
　上記レイアウト情報やタイミング情報を含む再生情報は，放送通知情報（ＳＡＰメッセージ）内のＳＤＰ情報やカルーセルデータとしてのＳＭＩＬに含まれ，
　上記ＳＡＰメッセージ及びカルーセルデータは，ＵＤＰ/ＩＰパケットによって伝送され，音声情報及び映像情報は，ＵＤＰ/ＩＰ上のＲＴＰパケットによって伝送され，
　上記カルーセルデータは，同一のデータを繰り返し伝送するものであり，再生情報，静止画情報，テクスト情報（テロップ，静止文字），動画像情報や音声情報を，ファイル化して伝送するものであり，
　上記ＳＡＰメッセージ内の上記再生情報をもとに，カルーセルデータのテキスト情報，音声情報，映像情報の再生を行う放送通信システム。」
　本願発明と引用発明とを対比すると，以下の点で相違し，その余の点において一致する。
　本願発明においては，アウトオブバンドの通信セッションとインバンドの通信セッションを使用するのに対して，引用発明においては，どのようなバンドを使っているか不明な点。
　上記相違点を検討する。
　下記にも記載するように，本案発明の「アウトオブバンド」，及び「インバンド」の定義は必ずしも明確ではないが，引用発明では，再生情報を含むＳＡＰメッセージが先だって送信され，その後，放送メディアがＳＡＰメッセージの送信されるチャネルとは異なるチャネルで送信されており，引用発明のＳＡＰメッセージの送信をアウトオブバンドの通信セッションとし，引用発明の放送メディアの送信をインバンドの通信セッションとすることは，当業者が容易に想到できることである。
理由２）について
（１）請求項１の記載に「（ａ２）アウトオブバンドの通信セッションにおいて，前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を受信することと，（ａ３）インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと」とあり，「アウトオブバンドの通信セッション」と「インバンドの通信セッション」の両方を用いていると認められる。
　しかしながら，発明の詳細な説明の段落【００５０】には「本発明の例証的な実施形態によれば，ＦＤＴとコンテンツデータパケットは，従来実施されていたようにインバンド方式で受信されない。代わりに，ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。」，また，段落【００５２】には，「次に図５を参照する。この実施形態では，データパケット＃１〜＃５のようなペイロードデータと比較して，先に述べたＦＤＴ７８に含まれているファイル属性のようなファイル属性８２が別々に，即ち，インバンド方式ではなくアウトバンド方式で送信される。」と記載されており，詳細な説明には，ファイル属性とコンテンツデータを異なるセッションで送るアウトバンドのものしか記載されておらず，両セッションを用いるものは記載されていない。
　したがって，請求項１の記載は，発明の詳細な説明に記載した範囲を超えるものである。（６項１号）
　また，請求項の記載において「アウトオブバンドの通信セッション」，及び「インバンドの通信セッション」の定義が不明であり，請求項１の記載が不明確となっている。（６項２号）
　
（２）同様に，請求項３，６，８，９，１０，１４，１６，１９についても，発明の詳細な説明には両セッションを用いるものは記載されておらず，各請求項の記載は，発明の詳細な説明に記載した範囲を超えるものである。（６項１号）
　また，各請求項の記載において「アウトオブバンドの通信セッション」ｌ及び「インバンドの通信セッション」の定義が不明であり，各請求項の記載が不明確となっている。（６項２号）
（３）請求項５には，ファイル属性を受信する手段と少なくとも１つのファイルを受信する手段とを，さらに備えるとしているが，さらに備えることは，発明の詳細な説明には記載されておらず（６項１号），さらに備える技術的必要性も明確でない。
　また，請求項５が引用する請求項４には，第１及び第２の通信チャネルを通して受信する手段を備えているにも係わらず，請求項５において，さらに同様の受信する手段を備えるという構成は，発明の構成が不明確である。（６項２号）
　請求項１１についても同様である。
（３）請求項９の記載には「コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体」とあり，発明の詳細な説明の段落【００７７】には「コンピュータ読み出し可能な媒体」としては記録媒体のみならず伝送媒体も含まれる旨の記載をし独自の定義を行っているが，通常，「コンピュータ読み出し可能な媒体」は記録媒体を指すものであり，「コンピュータ読み出し可能な媒体」を通常の意味に解するか独自に定義した意味に解すべきか不明であり，請求項９に係る発明が不明確となっている。（６項２号）
（４）請求項１０の記載に「第１のアドレス」と「第２のアドレス」にとあるが，「アドレス」に関して，発明の詳細な説明の段落【００３１】に，データパケットのソースアドレスと宛先アドレスを追加する旨が記載されているだけで，上記「第１のアドレス」と「第２のアドレス」に対応するものとは認められず，発明の詳細な説明との対応が不明であり（６項１号），又は，どのような技術的意味があるのかも明確でない。（６項２号）
（５）請求項１０，１４には「受信する手段」が記載されているが，これらの請求項に係る各発明は，ファイルを送達する装置に関するものであって，「受信する手段」を備える技術的必要性が不明であり，また，他の構成との関係も不明である。（６項２号）
　　　　　　　　　　　引　用　文　献　等　一　覧
１．特開２００３−３０４５１１号公報
」
第４　特許法第３６条第６項第２号について
１　請求人の対応
　上記拒絶の理由の通知に対して，請求人は，平成２７年２月２日付けで意見書と手続補正書を提出した。
　請求人は，上記意見書において，拒絶の理由２）の（１）及び（２）の指摘に対して，
「３−１．拒絶理由２（１）（特許請求の範囲の記載不備）
(i)審査官殿は，本願請求項１の発明は，アウトオブバンドの通信セッションとインバンドの通信セッションの両方を用いているが，本願明細書には，上記両通信セッションを用いることは説明されていないので，本願請求項１の発明は明細書にサポートされていないことを指摘しました。
(ii)さらに，両通信セッションの定義を明確にすることを求めています。
　請求項１の構成(a3)を下記の通りに補正しました。
　「(a3)前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に受信した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである」
　上記補正は，本願の明細書の少なくとも段落［００５１］および［００５３］に基づくものです。
　特に，段落［００５３］は，アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることをサポートしています。なぜなら，この開示は，ファイル属性は第１通信セッション（アウトオブバンドの通信セッション）中に取得／受信され，ファイル属性が第１通信セッション中に正確に取得／受信された後に，ファイルコンテンツは第２通信セッション（インバンドの通信セッション）中に取得／受信されることを教示しています。段落［００５１］は，「インバンド方式」は，同一の伝送セッション内での情報の移送を意味し，「アウトオブバンド方式」は，多様な伝送セッションを介した情報の移送を意味するものと定義しています。
　理由２（１）は，上記の補正及び意見により，解消するものと思料いたします。なお，審査官殿は，理由２（１）の中で，本願明細書［００５０］に言及していますが，［００５０］は，請求項１の発明とは異なる観点に基づく説明であることは自明です。
３−２．拒絶理由２（２）
　審査官殿は，他の請求項３，６，８，９，１０，１４，１６，１９に関しても，請求項１と同じ記載不備を指摘しました。
　他の独立請求項に関しても，請求項１と同様の補正を行いました。したがって，上記項目３−１．で述べたものと同様の理由から，拒絶理由２（２）は解消されたものと思料いたします。」
と主張している。
２　当審の判断
（１）拒絶の理由２）の（１）及び（２）について
　請求項１，３，６，８，９，１０，１４，１６，１９に記載された「アウトオブバンドの通信セッション」なる構成について，アウトオブバンドは，ＩＥＥＥから刊行され当業者に周知であるIEEE 100 The Authoritative Dictionary of IEEE Standards Terms, Seventh Editionの下記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」のとおり，一般に，制御信号とデータとを異なるチャネルで伝送する方式を意味するものと解され，異なるチャネルでの制御信号の伝送及びデータの伝送はそれぞれ通信セッションが異なると考えられる余地はあるものの，単一の「セッション」と「アウトオブバンド」の概念とは必ずしも結びつかないから，何をもって「アウトオブバンドの通信セッション」と言い得るのか不明確であり，その意味内容を一義的に理解することは困難である。
　このため，本願明細書の発明の詳細な説明の記載を参酌して，その意味内容を理解すると，上記文言について，本願明細書の発明の詳細な説明には以下の記載がある。
「【００５１】
これ以降では，用語「インバンド方式」は，伝送チャネルを介し，さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は，図４の伝送工程に図示し，説明しているとおりのものである。一方，用語「アウトバンド方式」は，図５に図示し，以降で説明する伝送工程によって例証されるように，こうした移送が同一の伝送チャネルを介して行われるか，あるいは別の伝送チャネルを介して行われるかに関係なく，多様な伝送セッションを介して，情報の移送を意味するものとして解釈される。
【００５２】
次に図５を参照する。この実施形態では，データパケット＃１〜＃５のようなペイロードデータと比較して，先に述べたＦＤＴ７８に含まれているファイル属性のようなファイル属性８２が別々に，即ち，インバンド方式ではなくアウトバンド方式で送信される。
【００５３】
ＦＡは，ネットワーク４４（図２）により，またブロードキャストチャネル内で伝送されることが好ましい。例えば，ＦＡは先に述べたＳＧの一部であってよい。ＳＧとさらにＦＡは，ブロードキャストサービスをシークするノード５０によって最初に取得される。即ち，ＦＡ８２は第１通信セッション８１中に取得される。ＦＡ８２を正確に取得した後，ノード５０は，ファイル８４のようなコンテンツファイルを取得するために，ＳＧ内に提供された情報に従ってチャネルに同調する。即ち，コンテンツファイルは第２通信セッション８６中に取得される。図５に示すように，コンテンツファイルパケット同士の間にはＦＤＴが割り込んでいない。むしろ，コンテンツファイル（例えばファイル８３，８４）は，連続的および非妨害的に伝送されるよう設計されている。表現を変えれば，通信セッション８１中の早い時期にノード５０がＦＡ８２を正確に取り出したと確認された後にのみ，コンテンツファイルが通信セッション８６中にダウンロードされる。これにより，ファイルとＦＤＴの両方がインバンド方式で，また上述したとおりに受信される場合に，ファイル処理の成功が関連するＦＤＴのダウンロードの成功によって決まってしまう状況を回避できる。」
（［当審注］：
【００５１】のインバンド方式に関する「伝送チャネルを介し，」，アウトバンド方式に関する「多様な伝送セッションを介して，」について，本願は特許法第３６条の２第１項の規定による特許出願であるところ，外国語書面の明細書の[0063]にはそれぞれ「through the same transmission channel」，「through different transmission sessions」と記載されているから，それぞれ「同一の伝送チャネルを介し，」「別の伝送セッションを介して，」と解すべきである。
　また，翻訳文における「インバンド方式」，「アウトバンド方式」なる訳語は，外国語書面の明細書にはそれぞれ「in-band」，「out-of-band」と記載されているから，請求項１に記載された「アウトオブバンドの通信セッション」，「インバンドの通信セッション」は，「アウトバンド方式の通信セッション」，「インバンド方式の通信セッション」と解すべきである。）
　まず，発明の詳細な説明には，請求項１に記載された「アウトオブバンドの通信セッション」，「インバンドの通信セッション」なる記載は存在しない。
　そして，【００５１】の記載によれば，同一の伝送チャネルを介し，さらに実質的に同一の伝送セッション内での情報の移送が為されれば，「インバンド方式」の通信といえ，当該通信に係るセッションは「インバンドの通信セッション」と理解することは一応可能である。そして，【００５１】では，図４はインバンド方式の情報移送の例を示すものとされており，図４では，同一のチャネル及び同一の伝送セッション内で制御信号及びデータが伝送されていると認められるから，当該理解は，上記情報が制御信号とデータを含む場合には，下記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」の内容と一致するものである。
　一方，【００５１】の記載によれば，移送が同一の伝送チャネルを介して行われるか，あるいは別の伝送チャネルを介して行われるかに関係なく，別の伝送セッションを介して，情報の移送が為されれば，「アウトバンド方式」の通信といえる。そして，【００５１】では，図５はアウトバンド方式の情報移送の例を示すものとされており，図５ではＦＡが伝送される第１通信セッション８１と，コンテンツファイルが伝送される第２通信セッション８６とが示されている。ここで，【００５１】，【００５２】の記載によれば，情報が別々のセッションで移送されるからこそアウトバンド方式での通信といえるから，アウトバンド方式の通信を形成する個々の通信セッションの各々も，「アウトオブバンドの通信セッション」と考えることもできる。そのような理解は，上記情報が制御信号とデータを含む場合には，下記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」の内容とも一致するものである。
　しかしながら，【００５１】の記載は，移送される「情報」について制御信号とデータとの別を明らかにしていないため，第１通信セッション８１単体でみた場合，同一チャネルかつ同一セッション（すなわち，第１通信セッション８１）で情報（すなわち，ＦＡ。）の移送が為されるから，【００５１】の記載によれば，第１通信セッション８１は「インバンド方式」の通信セッションともいえることになる。同様に，第２通信セッション８６単体でみた場合，同一チャネルかつ同一セッション（すなわち，第２通信セッション８６）で情報（すなわち，コンテンツ。）の移送が為されるから，【００５１】の記載によれば，第２通信セッション８６は「インバンド方式」の通信セッションともいえることになる。
　このため，第１通信セッション８１，第２通信セッション８６は，「アウトオブバンドの通信セッション」，「インバンドの通信セッション」のいずれに含まれるのかが不明確である。
　したがって，発明の詳細な説明の記載を勘案しても，「アウトオブバンドの通信セッション」なる構成が不明確である。
　更に，「インバンド」は，下記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」のとおり，一般に，制御信号とデータとが同じチャネルで伝送される方式を意味するものと解されるから，請求項１の「(a3)・・・インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，」の「インバンド通信セッション」では，データであるコンテンツのみならず，制御信号であるＦＡも同時に伝送されるものとも解される。
　そうすると，請求項１，３，６，８，９，１０，１４，１６，１９に係る発明は，「インバンド通信セッション」について，下記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」に示される一般的なインバンド−シグナリングの解釈と，【００５１】の記載に基づくアウトバンド方式を構成する個々の通信セッション（図５の第２の通信セッション８６）との解釈との異なる定義による２つの解釈が可能であるところ，そのいずれと解すべきか不明であるため，特許を受けようとする発明が不明確である。
■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義
「in-band signaling」
　Signaling applications in which the signaling information is transmitted in the same information flow as the data.
「out-of-band signaling」
　Signaling applications in which the signaling information is outside of the user information channel, whether or not transmitted in a different physical or logical channel from the associated user data, e.g., over different physical paths, in different time-slots in a time division multiplex (TDM) stream.
（出典：IEEE 100 The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition, IEEE Press, 2000年）
（当審仮訳：
「インバンド−シグナリング」
シグナリング情報がデータと同じ情報フローで送信されるシグナリングアプリケーション
「アウトオブバンド−シグナリング」
シグナリング情報がユーザ情報チャネルの外であるシグナリングアプリケーション，関連するユーザデータとは異なる物理又は論理チャネル，例えば異なる物理パス，時分割多重（ＴＤＭ）ストリームの異なるタイムスロットを介して送信されるか否か
）
３　小括
　したがって，この出願は，特許請求の範囲の記載が，特許法第３６条第６項第２号に規定する要件を満たしていない。
第５　特許法第３６条第６項第１号について
１　請求人の対応
　上記拒絶の理由の通知に対する請求人の対応は，上記第３の１のとおりである。
２　当審の判断
　上記「第４　特許法第３６条第６項第２号について」の項で述べたように，【００５１】によれば，図４はインバンド方式の例を示すものであり，図５はアウトバンド方式の例を示すものである。そして，アウトバンド方式の例を示したものである図５の第２の通信セッション８６が「インバンドの通信セッション」であることは，発明の詳細な説明に記載されておらず，そのように一義的に解釈できるものではない。
　そして，図４の例と図５の例とは独立した例であって，アウトバンド方式とインバンド方式とを併用することは，発明の詳細な説明に記載も示唆もされていない。すなわち，上記「第４　特許法第３６条第６項第２号について」の項で述べたように，「インバンド方式」は，上記「■インバンド−シグナリング及びアウトオブバンド−シグナリングの定義」のとおり，一般に，制御信号とデータとが同じチャネルで伝送される方式を意味するものと解されるから，請求項１の「(a3)・・・インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，」の「インバンド通信セッション」では，データであるコンテンツのみならず，制御信号であるＦＡも同時に伝送されるものとも解される。しかし，そのようなものは，発明の詳細な説明に記載も示唆もされておらず，自明でもない。
　なお，請求人は，補正の根拠に関して，「段落［００５３］は，アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることをサポートしています。なぜなら，この開示は，ファイル属性は第１通信セッション（アウトオブバンドの通信セッション）中に取得／受信され，ファイル属性が第１通信セッション中に正確に取得／受信された後に，ファイルコンテンツは第２通信セッション（インバンドの通信セッション）中に取得／受信されることを教示しています。段落［００５１］は，「インバンド方式」は，同一の伝送セッション内での情報の移送を意味し，「アウトオブバンド方式」は，多様な伝送セッションを介した情報の移送を意味するものと定義しています。」と述べているが，第２の通信セッション８６がインバンド方式であることは記載されておらず，【００５１】，【００５２】の記載も考慮すれば，第１の通信セッション８１と第２の通信セッション８６とでアウトバンド方式の伝送をなしていることは明らかである。更に，【００５３】には，その文末にインバンド方式の問題を回避するとの記載もあることから，インバンド方式に替えてアウトバンド方式を用いることが述べられていると解するのが自然であり，アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることが記載されているとはいえない。したがって，請求人の主張は採用できない。
　よって，請求項１，３，６，８，９，１０，１４，１６，１９に記載された発明は，発明の詳細な説明に記載されたものではない。
３　小括
　したがって，この出願は，特許請求の範囲の記載が，特許法第３６条第６項第１号に規定する要件を満たしていない。
第６　特許法第２９条第２項について
１　本願発明
　特許請求の範囲の請求項１は次のとおりのものである。
「　(a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって，
　(a2)アウトオブバンドの通信セッションにおいて，前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を受信することと，
　(a3)前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に受信した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである，
　(a4)ここにおいて，前記複数のファイル属性は，前記少なくとも１つのファイルよりも先に受信され，また前記処理することは，前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく，前記少なくとも１つのファイルよりも先に受信された前記複数のファイル属性に基づいて，前記少なくとも１つのファイルを再構築することを含む，
　(a5)前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに，
　(a6)前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　(a7)前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，を備える，
　方法。」（上記「第２　特許請求の範囲の記載」の再掲）
　ここで，「アウトオブバンドの通信セッション」及び「インバンドの通信セッション」なる用語は，上記「第４　特許法第３６条第６項第２号について」の項で述べたとおり不明確であるが，請求人は，【００５３】の記載に基づき，図５の第１通信セッション８１が「アウトオブバンドの通信セッション」であり，第２通信セッション８６が「インバンドの通信セッション」であると主張しているから，「アウトオブバンドの通信セッション」は図５の第１通信セッション８１を，「インバンドの通信セッション」は図５の第２通信セッション８６を，それぞれ意味するものと解釈することとする。
　したがって，上記請求項１の記載のうち，「アウトオブバンドの通信セッション」，「インバンドの通信セッション」の記載は上記のとおり解釈するものとして，本願発明は，上記請求項１の記載のとおりのものと認める。
２　引用発明
［引用発明］
　当審による拒絶の理由に引用された特開２００３−３０４５１１号公報（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。
（１）「【０００１】
【発明の属する技術分野】本発明は，映像（ビデオ）情報，音声（オーディオ）情報等の放送メディアを放送するための放送通信システム，放送通信方法，及び，これらに用いて好適な通信端末，サーバ装置，中継装置及びプログラムに関する。」
（２）「【００２７】
【課題を解決するための手段】本発明の第１の特徴は，受信した放送メディアを再生する通信端末であって，前記放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合，前記再生情報に基づいて，指定された該放送メディアを再生することを要旨とする。」
（３）「【００８４】（第１の実施形態）本発明の第１の実施形態について図１から図１１を用いて説明する。本実施形態では，インターネットプロトコルである「ＲＴＰ/ＵＤＰ/ＩＰ」パケット（放送メディアパケット）の形式で，音声情報や映像情報等を含む放送メディアを伝送する放送通信システム１について説明する。
【００８５】本実施形態では，受信端末２０は，音声情報や映像情報等の放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，放送通知情報（ＳＡＰメッセージ）を受信した場合に，前記再生情報に基づいて放送メディアを再生する。ここで，放送通知情報（ＳＡＰメッセージ）は，少なくとも一つの放送メディアを指定するものである。
【００８６】コンテンツ送信サーバ１０は，受信端末２０による放送メディアの再生に先立って，放送通知情報（ＳＡＰメッセージ）によって指定されている放送メディアの再生方法を示す再生情報を送信する。
【００８７】コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）によって指定される放送メディア（ＡＭＲを含むＲＴＰパケットやＭＰＥＧ４を含むＲＴＰパケット）を送信する前に，放送メディアの再生方法を示す再生情報を送信する。
【００８８】例えば，コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）を周期的に繰り返し送信して，放送通知情報（ＳＡＰメッセージ）を送信した直後に，カルーセルデータによって再生情報を送信することができる。ここで，カルーセルデータとは，同じデータを繰り返し送信する方式（データカルーセル方式）によって伝送されるデータのことをいう。
【００８９】ここで，再生情報は，ＳＡＰメッセージの「ｐａｙｌｏａｄ（ペイロード）」内に記述されている「ＳＤＰ情報（図４参照）」や，データカルーセル方式によって送信される「ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ  ＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎ  Ｌａｎｇｕａｇｅ）（図８参照）」等に含まれている。
【００９０】また，再生情報は，放送メディアの再生の際に用いられる「レイアウト情報」や，放送メディアの再生の際に用いられる「タイミング情報」を含むことができる。
【００９１】図２は，本実施形態における放送通信システム１におけるコンテンツ送信サーバ１０と受信端末２０との間のシーケンス図である。
【００９２】図２に示すように，ステップ２０１において，コンテンツ送信サーバ１０が，放送通知情報である「ＳＡＰメッセージ」を，受信端末２０に送信する。ＳＡＰメッセージの内容については，後述の図３及び図４において詳細に説明する。ここで，ＳＡＰメッセージが通知される「ＩＰアドレス」及び「ポート番号」は，受信端末２０に既知のものとする。
【００９３】ステップ２０２において，コンテンツ送信サーバ１０が，「ＳＭＩＬ」を含むカルーセルデータを受信端末２０に送信する。また，ステップ２０３において，コンテンツ送信サーバ１０が，ＨＴＭＬ形式のテキスト情報やアンカー情報を含むカルーセルデータを受信端末２０に送信する。
【００９４】例えば，ＪＰＥＧ等の静止画像情報やＸＭＬ形式の構造化データは，ＵＤＰ上でデータを繰り返し送るデータカルーセル方式にて伝送される（図３５参照）。データカルーセル方式については，後述の図５乃至図７の説明において詳細に説明する。
【００９５】ステップ２０４乃至２０７において，コンテンツ送信サーバ１０が，音声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）を含むＲＴＰパケット（放送メディアパケット）を受信端末２０に送信する。
【００９６】ここで，ＳＡＰメッセージ及びカルーセルデータは，ＵＤＰ/ＩＰパケットによって伝送され，音声情報及び映像情報は，ＵＤＰ/ＩＰ上のＲＴＰパケットによって伝送される（図３５参照）。
【００９７】そして，コンテンツ送信サーバ１０は，ＳＡＰメッセージを，所定間隔をもって周期的に繰り返し伝送する。受信端末２０は，ＳＡＰメッセージを受信することにより，放送メディアの再生を開始するので，ＳＡＰメッセージは，できうる限り短い周期にて伝送することが望ましい。
【００９８】次に，図３及び図４を用いて，ＳＡＰメッセージについて説明する。図３は，ＳＡＰメッセージのフォーマットを示すものである。
【００９９】図３において，「Ｖ」は，バージョン情報を示す。「Ａ」は，アドレスタイプを示し，Ａ＝０の時，ＩＰｖ４であり，Ａ＝１の時，ＩＰｖ６である。「Ｒ」は，「Ｒｅｓｅｒｖｅｄ」である。
【０１００】「Ｔ」は，メッセージタイプを示し，Ｔ＝０の時，放送開始を示す放送通知情報であることを意味し，Ｔ＝１の時，放送終了を示す放送通知情報であることを意味する。
【０１０１】「Ｅ」は，「Ｅｎｃｒｙｐｔｉｏｎ  ｂｉｔ」である。「Ｃ」は，「Ｃｏｍｐｒｅｓｓｉｏｎ  ｂｉｔ」である。「ａｕｔｈ  ｌｅｎ」は，「ｏｐｔｉｏｎａｌ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｄａｔａ」のサイズを示す。
【０１０２】「ｍｓｇ  ｉｄ  ｈａｓｈ」は，「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」に記述されたＩＰアドレスで示される発信元（コンテンツ送信サーバ１０等）によって送信されるＳＡＰメッセージを一意に特定するメッセージＩＤである。
【０１０３】「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」は，ＳＡＰメッセージの発信元のＩＰアドレスである。
【０１０４】ここで，「ｍｓｇ  ｉｄ  ｈａｓｈ」と「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」との組み合わせによって，ＳＡＰメッセージを一意に特定することができる。
【０１０５】「ｏｐｔｉｏｎａｌ  ｐａｙｌｏａｄ  ｔｙｐｅ」は，「ｐａｙｌｏａｄ」のデータタイプを示す。「ｐａｙｌｏａｄ」については，図４において詳細に説明する。
【０１０６】図４は，本実施形態におけるＳＡＰメッセージ内の「ｐａｙｌｏａｄ」に記述された「ＳＤＰ情報」の例を示す。
【０１０７】「ｖ＝０」は，「ｐａｙｌｏａｄ」のバージョンを示すものであり，「ｐａｙｌｏａｄ」を記述するルールを規定するための情報を示している。
【０１０８】「ｏ＝」は，発信元情報であり，発信元のＩＰアドレス情報（１２６．１６．６４．４）を含む。「ｓ＝」は，放送メディアのセッション名である。「ｃ＝」は，放送メディアを送信しているマルチキャストアドレス（送信先のＩＰアドレス情報）である。「ｔ＝」は，放送メディアの有効期間を示すものである。
【０１０９】「ｍ＝」は，当該ＳＡＰメッセージによって指定されている放送メディアを示す情報であり，図４に示すＳＡＰメッセージは，放送メディアとして，１つの音声情報と１つの映像情報と１つのカルーセルデータを指定している。
【０１１０】すなわち，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ  ３４５６  ＲＴＰ/ＡＶＰ  ０」という記述は，音声情報を「３４５６」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。
【０１１１】また，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ  ２２３２  ＲＴＰ/ＡＶＰ  ９８」という記述は，映像情報を「２２３２」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。
【０１１２】また，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ  ３２４１６  ｕｄｐ  ｄｃ」という記述は，繰り返し送信するカルーセルデータを，ＵＤＰパケットを用いて伝送することを示している。」
（４）「【０１４５】第２に，受信端末２０は，ＳＡＰメッセージを参照することにより，音声情報や映像情報やカルーセルデータ等の放送メディアが送信されている「ＩＰアドレス」や，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等の再生情報を取得する。
【０１４６】例えば，図４に示すＳＡＰメッセージを受信した受信端末２０は，「ｃ＝ＩＮＩＰ４  ２２４．２．１７.１２/１２７」という記述により，各放送メディアが送信されている「ＩＰアドレス（マルチキャストアドレス）」を取得する。
【０１４７】また，受信端末２０は，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ  ３４５６  ＲＴＰ/ＡＶＰ  ０」という記述により，音声情報が，ポート番号「３４５６」によってＲＴＰパケットを用いて送信されると解析する。
【０１４８】また，受信端末２０は，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ  ２２３２  ＲＴＰ/ＡＶＰ  ９８」という記述により，映像情報が，ポート番号「２２３２」によってＲＴＰパケットを用いて送信されると解析する。
【０１４９】さらに，受信端末２０は，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ  ３２４１６  ｕｄｐ  ｄｃ」という記述より，ポート番号「３２４１６」によって，ＵＤＰパケット上で，カルーセルデータが送信されると解析する。
【０１５０】第３に，上述の放送メディアについての解析を行った受信端末２０は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つ。」
（５）「【０２６６】図２７の例では，コンテンツ送信サーバ１０が，ＳＡＰメッセージ用チャネルを介してＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）を伝送し，番組１用チャネルを介して第１の放送メディア（ＲＴＰ１-ａ，ＲＴＰ１-ｂ）を伝送し，番組２用チャネルを介して第２の放送メディア（ＲＴＰ２-ａ，ＲＴＰ２-ｂ）を伝送している。すなわち，図２７の例では，コンテンツ送信サーバ１０は，番組毎に異なる無線チャネルを使用している。
【０２６７】この場合，コンテンツ送信サーバ１０は，ＳＡＰメッセージにおいて放送メディア（番組）のＩＰアドレス（論理チャネル識別情報）だけ指定したのでは不十分であり，どの無線チャネルにどの放送メディアが流れているかについても特定する必要がある。そこで，コンテンツ送信サーバ１０は，ＳＡＰメッセージ内のＳＤＰ情報の中で，無線チャネルを特定する情報（物理チャネル識別情報）を通知する。
【０２６８】例えば，コンテンツ送信サーバ１０は，図２８に示すように，ＳＤＰの「ｃフィールド」の中で「ｃ＝Ｃｈａｎｎｅｌ  ＡＢＣＤＥ」というように無線チャネルを特定する情報を通知する。無線チャネルを特定する情報としては，ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等が考えられる。
【０２６９】受信端末２０は，この無線チャネルを特定する情報に基づいて，放送メディアの流れている無線チャネルを特定し，当該放送メディアを視聴することが可能となる。
【０２７０】すなわち，本実施形態では，放送通知情報（ＳＡＰメッセージ）内のＳＤＰ情報に，放送メディアが送信される物理チャネル識別情報（ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等の無線チャネルを特定する情報）と論理チャネル識別情報（放送メディアのＩＰアドレス）との対応情報とが含まれている。」
　上記引用例の記載及び図面（特に図１−４，図２７，図２８，図３５）並びにこの分野における技術常識を考慮すると，
ア　上記（１），（２），（３）の【００８７】及び【００９５】，並びに上記（４）の【０１５０】の記載によれば，引用例には，「放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法」が記載されていると認められる。
イ　上記（３）の【００８８】，上記（４）の【０１４５】，及び上記（５）の【０２６６】の記載によれば，受信端末がコンテンツ送信サーバから受信する再生情報には，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等が含まれ，前記再生情報は，ＳＡＰメッセージ用チャネルを介して送信されるＳＡＰメッセージに含まれていると認められる。
　したがって，引用例には，「ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信すること」が記載されていると認められる。
ウ　上記（４）の【０１５０】の記載によれば，受信したＳＡＰメッセージを参照することにより再生情報を取得して放送メディアについての解析を行った受信端末は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つ，換言すれば，受信端末は，再生情報を受信して放送メディアについての解析を行った後に，前記再生情報とは別に，放送メディアを受信するものと認められる。そして，取得した再生情報に基づいて放送メディアについての解析を行う以上，再生情報を正確に受信した後に解析を始めることは明らかであるから，受信端末は，再生情報を正確に受信した後に，放送メディアについての解析を始め，当該解析を行った後に前記放送メディアを受信する，すなわち再生情報を正確に受信した後に，放送メディアを受信するものと認められる。
　また，上記（５）の【０２６６】及び図２７の記載によれば，放送メディアは，番組用チャネルにおいて受信するものと認められ，当該番組用チャネルは，ＳＡＰメッセージ用チャネルとは異なるチャネルであると認められる。
　したがって，引用例には，「前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を正確に受信した後に，番組用チャネルにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報とは別に，前記放送メディアを受信することとを備え，ここにおいて，前記ＳＡＰメッセージ用チャネルと前記番組用チャネルは，異なるチャネルである」ことが記載されていると認められる。
エ　上記ウのとおり，前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信した後に，番組用チャネルにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報とは別に，前記放送メディアを受信するのであるから，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，放送メディアよりも先に受信されると認められる。
　また，上記（５）の【０２６６】及び図２７の記載によれば，ＳＡＰメッセージ用チャネルではＳＡＰメッセージのみが伝送され，番組用チャネルには放送メディアのみが伝送されＳＡＰメッセージは伝送されていないから，受信端末における放送メディアの再生が，番組用チャネルにおいて「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することなく，前記放送メディアよりも先に受信された「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報に基づいて行われることは明らかである。
　したがって，引用例には，「ここにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，前記放送メディアよりも先に受信され，また前記再生することは，前記番組用チャネルにおいて「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することなく，前記放送メディアよりも先に受信された「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報に基づいて行われることを含む」ことが記載されていると認められる。
オ　上記（３）の【００８４】の記載によれば，引用例には，「前記放送通信システムは，インターネットプロトコル（ＩＰ）をサポート」することが記載されていると認められる。
カ　上記（３）の【００８４】，【００９２】，【００９６】，【０１０９】−【０１１１】，及び上記（４）の【０１４５】の記載によれば，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を含むＳＡＰメッセージは，受信端末に既知のポート番号を介してＵＤＰ／ＩＰパケットによって伝送され，音声情報や映像情報等の放送メディアは，「３４５６」及び「２２３２」で特定されるポート番号を介して，ＵＤＰ／ＩＰ上のＲＴＰパケットによって伝送されて，受信端末が受信すると認められる。
　したがって，引用例には，「前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を，受信端末に既知のポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　前記放送メディアを，「３４５６」及び「２２３２」で特定されるポート番号を介して前記ＩＰの前記ＵＤＰを介して受信すること」が記載されていると認められる。
　したがって，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。  
「　放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法であって，
　ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することと，
　前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を正確に受信した後に，番組用チャネルにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報とは別に，前記放送メディアを受信することとを備え，ここにおいて，前記ＳＡＰメッセージ用チャネルと前記番組用チャネルは，異なるチャネルである，
　ここにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，前記放送メディアよりも先に受信され，また前記再生することは，前記番組用チャネルにおいて「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することなく，前記放送メディアよりも先に受信された「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報に基づいて行われることを含む，
　前記放送通信システムは，インターネットプロトコル（ＩＰ）をサポートし，前記放送通信方法は，
　前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を，受信端末に既知のポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　前記放送メディアを，「３４５６」及び「２２３２」で特定されるポート番号を介して前記ＩＰの前記ＵＤＰを介して受信することと，を備える
　放送通信方法。」
３　対比
　本願発明と引用発明とを対比すると，
（１）引用発明の「放送通信システム」は，明らかに「通信システム」に含まれる。そして，引用発明の「放送」が「ブロードキャスト」を意味することは明らかであるから，本願発明の「ブロードキャストのファイル」，「ブロードキャストのファイルの少なくとも１つのファイル」及び「ブロードキャストのファイルの少なくとも１つのファイルのコンテンツ」と引用発明の「放送メディア」とは，「ファイル」であるか否かは別として，「ブロードキャストのコンテンツ」である点で共通する。
　また，本願発明の「ブロードキャストのファイルをダウンロードする」ことは，発明の詳細な説明の【０００９】，【００１０】，【００１４】の記載によれば，ブロードキャストされたコンテンツを受信すること含むと認められる。
　したがって，本願発明の「(a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって」と，引用発明の「放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法であって」とは，「ファイル」であるか否かは別として，「通信システム内でブロードキャストのコンテンツをダウンロードする方法であって」の点で共通している。
（２）本願発明の「少なくとも１つのファイルのコンテンツを処理」することと引用発明の「放送メディアを再生する」こととは，その対象が「ファイル」であるか否か，及びその内容に「少なくとも１つのファイルを再構築することを含む」か否かは別として，「ブロードキャストのコンテンツを処理する」ことである点で共通する。
　そして，本願発明の「複数のファイル属性」と引用発明の「「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報」とは，コンテンツの処理に用いるものである点で共通する。また，引用発明において，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報に基づいて放送メディアの再生が行われる以上，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，コンテンツを処理するために受信しているといえる。したがって，本願発明の「前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性」と，引用発明の「各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報」とは，「コンテンツを処理するために必要な情報」である点で共通している。
　以上のことから，本願発明の「(a2)アウトオブバンドの通信セッションにおいて，前記ブロードキャストの少なくとも１つのファイルのコンテンツを処理するために複数のファイル属性を受信することと」と，引用発明の「ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することと」は，下記の相違点１〜３は別して，「前記ブロードキャストのコンテンツを処理するために必要な情報を受信すること」の点で共通している。
（３）上記（２）のとおりであるから，本願発明の「(a3)前記アウトオブバンドの通信セッションにおいて，前記複数のファイル属性を正確に受信した後に，インバンドの通信セッションにおいて，前記複数のファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのファイルを受信することと，を備え，ここにおいて，前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである」と，引用発明の「前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を正確に受信した後に，番組用チャネルにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報とは別に，前記放送メディアを受信することとを備え，ここにおいて，前記ＳＡＰメッセージ用チャネルと前記番組用チャネルは，異なるチャネルである，」とは，下記の相違点１〜３は別して，「前記コンテンツを処理するために必要な情報を正確に受信した後に，前記コンテンツを処理するために必要な情報とは別に，前記ブロードキャストのコンテンツを受信すること」の点で共通している。
（４）上記（２），（３）のとおりであるから，本願発明の「(a4)ここにおいて，・・・前記少なくとも１つのファイルを再構築することを含む」と，引用発明の「ここにおいて，・・・前記放送メディアよりも先に受信された「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報に基づいて行われることを含む」とは，下記の相違点１〜３は別して，「ここにおいて，前記コンテンツを処理するために必要な情報は，前記コンテンツよりも先に受信され，また前記処理することは，前記コンテンツを処理するために必要な情報をコンテンツと同時に受信することなく，前記コンテンツよりも先に受信された前記複数のファイル属性に基づいて行われることを含む」点で共通している。
（５）本願発明と引用発明とは，「前記通信システムはインターネットプロトコル（ＩＰ）をサポートし」ている点で差異は無い。
　また，引用発明において，受信端末に既知のポート番号を「第１ポート番号」と称し，「３４５６」及び「２２３２」で特定されるポート番号を「第２ポート番号」と称することは任意である。したがって，本願発明と引用発明とは，「前記複数のファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，を備える」点で差異は無い。
　したがって，本願発明と引用発明とは，両者は，以下の点で一致し，また，相違している。
（一致点）
　「　通信システム内でブロードキャストのコンテンツをダウンロードする方法であって，
　前記ブロードキャストのコンテンツを処理するために必要な情報を受信することと，
　前記コンテンツを処理するために必要な情報を正確に受信した後に，前記コンテンツを処理するために必要な情報とは別に，前記ブロードキャストのコンテンツを受信することと，を備え，
　ここにおいて，前記コンテンツを処理するために必要な情報は，前記コンテンツよりも先に受信され，また前記処理することは，前記コンテンツを処理するために必要な情報をコンテンツと同時に受信することなく，前記コンテンツよりも先に受信された前記コンテンツを処理するために必要な情報に基づいて行われることを含む，
　前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに，
　前記コンテンツを処理するために必要な情報を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，
　前記少なくとも１つのファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，を備える，
　方法。」
（相違点１）
　一致点の「ブロードキャストのコンテンツ」に関し，本願発明は，「ブロードキャストのファイル」，「ブロードキャストの少なくとも１つのファイルのコンテンツ」，及び「ブロードキャストの少なくとも１つのファイル」を受信及び処理するのに対し，引用発明はブロードキャストのコンテンツを少なくとも１つのファイルとして受信及び処理することが明らかでない点。
（相違点２）
　一致点の「コンテンツを処理するために必要な情報」及び「コンテンツ」の受信に関し，本願発明は，それぞれ「アウトオブバンドの通信セッション」及び「インバンドの通信セッション」において受信し，かつ「前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは，異なる伝送セッションである」のに対し，引用発明は，それぞれ「ＳＡＰメッセージ用チャネル」及び「番組用チャネル」において受信し，「前記ＳＡＰメッセージ用チャネルと前記番組用チャネルは，異なるチャネルである」ものの，「通信セッション」については明らかではない点。
（相違点３）
　一致点の「コンテンツを処理するために必要な情報に基づいてブロードキャストのコンテンツを処理する」ことに関し，本願発明は，処理の内容に「複数のファイル属性に基づいて少なくとも１つのファイルを再構築する」ことを含むのに対し，引用発明は当該構成が明らかでない点。
４　検討
　上記各相違点について，先に上記相違点１及び３について検討し，その後相違点２について検討する。
（相違点１及び３について）
　端末がサーバからコンテンツをダウンロードして再生する通信システムにおいて，前記端末及び前記サーバが，前記コンテンツを少なくとも１つのファイルとして扱うこと，並びにインターネットプロトコル（ＩＰ）をサポートする通信システムにおいてファイルを伝送する際に，送信側で当該ファイルを複数のパケットに分割して送信し，受信側で前記複数のパケットとして前記ファイルを受信して元のコンテンツを復元するために再構築する処理を行うことは，いずれも当業者により一般的に行われていることにすぎない。
　また，その場合，ファイルを「再構築する処理」をするために必要な情報を，「ファイル属性」と称することは任意である。
　そうすると，ブロードキャストのコンテンツをブロードキャストの少なくとも１つのファイルとして受信して，複数のファイル属性に基づいて前記少なくとも１つのファイルを再構築すること，すなわち，相違点１及び３は，格別困難なことではなく，当業者が容易になし得ることである。
（相違点２について）
　上記１で述べたとおり，本願発明に記載された「アウトオブバンドの通信セッション」，「インバンドの通信セッション」は，それぞれ図５の第１通信セッション８１，図５の第２通信セッション８６を意味し，それぞれ「複数のファイル属性」，「ブロードキャストの少なくとも１つのファイル」のみを伝送するものである。
　一方，引用発明において，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信する「ＳＡＰメッセージ用チャネル」と，放送メディアを受信する「番組用チャネル」は，異なるチャネルであって，上記２のエで述べたとおり，ＳＡＰメッセージ用チャネルではＳＡＰメッセージのみが伝送され，番組用チャネルには放送メディアのみが伝送されている。
　ここで，インターネットプロトコル（ＩＰ）をサポートする通信システムにおいて，通信セッション単位で通信を行うことは，当業者における技術常識であり，異なるチャネルに異なる通信セッションを対応付けることは格別困難なことではなく，当業者が容易になし得ることに過ぎない。
　そして，引用発明において，「ＳＡＰメッセージ用チャネル」と「番組用チャネル」とをそれぞれ別の通信セッションとして伝送した場合，「ＳＡＰメッセージ用チャネルの通信セッション」ではＳＡＰメッセージのみが伝送され，「番組用チャネルの通信セッション」では放送メディアのみが伝送されることとなるから，それぞれ本願の図５の第１通信セッション８１，第２通信セッション８６に対応することは明らかである。
　したがって，相違点２は格別困難なことではなく，当業者が容易になし得ることにすぎない。
　そして，本願発明の作用効果も，引用発明及び周知事項に基づいて当業者が予測し得る範囲のものであり，格別なものではない。
５　小括
　以上のとおり，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。 
第７　むすび
　以上のとおり，本願は，特許請求の範囲の記載が，特許法第３６条第６項第１号及び第２号に規定する要件を満たしていないから，特許を受けることができない。
　また，本願発明は，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。