【事件の表示】
　特願２０１１−　６６４２９「マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置」拒絶査定不服審判事件〔平成２３年　８月　４日出願公開、特開２０１１−１５１８４５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，２００６年４月１０日（パリ条約による優先権主張外国庁受理　２００５年４月８日　米国，２００６年４月６日　米国）を国際出願日とする出願である特願２００８−５０５６２１号の一部を，平成２３年３月２４日に新たな特許出願としたものであって，平成２６年３月１８日付けで拒絶査定がなされ，これに対し，同年７月２５日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされ，当審により平成２７年５月８日付けで通知された拒絶理由に対して，同年８月１２日付けで手続補正がなされたものである。
　その請求項５に係る発明は，明細書，特許請求の範囲及び図面の記載からみて，平成２７年８月１２日付け手続補正書により補正された特許請求の範囲の請求項５に記載された次のとおりのものと認める（以下，「本願発明」という。）。 
「【請求項５】
　通信システムにおいてブロードキャストのファイルを送達する方法であって，
　第１通信セッションにおいて，第１通信チャネルにおけるファイル通信チャネルを介して，前記ブロードキャストの少なくとも１つのファイルを処理するためにファイル属性を送信することと，
　第２通信セッションにおいて，第２通信チャネルを介して，前記ファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを送信することと，を備え，
　ここにおいて，前記ファイル属性は永続するファイル属性と短命のファイル属性とを含み，
　前記方法はさらに，
　前記第２通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的および非妨害的に送信することと，ここにおいて，前記複数のファイルは前記少なくとも１つのファイルを含み，
　前記第２通信セッションよりも前の前記第１通信セッションにおいて，前記複数のファイルを処理するための前記ファイル属性を送信することと，ここにおいて，前記複数のファイルは複数のデータパケットを含み，前記ファイル属性は前記複数のデータパケットから前記複数のファイルを再構築するために使用される，を備える，方法。」
２　引用発明及び技術常識
［引用発明］
　当審による拒絶の理由に引用された特開２００３−３０４５１１号公報（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。
（１）「【０００１】
【発明の属する技術分野】本発明は，映像（ビデオ）情報，音声（オーディオ）情報等の放送メディアを放送するための放送通信システム，放送通信方法，及び，これらに用いて好適な通信端末，サーバ装置，中継装置及びプログラムに関する。」（５ページ）
（２）「【００２７】
【課題を解決するための手段】本発明の第１の特徴は，受信した放送メディアを再生する通信端末であって，前記放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合，前記再生情報に基づいて，指定された該放送メディアを再生することを要旨とする。」（７ページ）
（３）「【００８４】（第１の実施形態）本発明の第１の実施形態について図１から図１１を用いて説明する。本実施形態では，インターネットプロトコルである「ＲＴＰ/ＵＤＰ/ＩＰ」パケット（放送メディアパケット）の形式で，音声情報や映像情報等を含む放送メディアを伝送する放送通信システム１について説明する。
【００８５】本実施形態では，受信端末２０は，音声情報や映像情報等の放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，放送通知情報（ＳＡＰメッセージ）を受信した場合に，前記再生情報に基づいて放送メディアを再生する。ここで，放送通知情報（ＳＡＰメッセージ）は，少なくとも一つの放送メディアを指定するものである。
【００８６】コンテンツ送信サーバ１０は，受信端末２０による放送メディアの再生に先立って，放送通知情報（ＳＡＰメッセージ）によって指定されている放送メディアの再生方法を示す再生情報を送信する。
【００８７】コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）によって指定される放送メディア（ＡＭＲを含むＲＴＰパケットやＭＰＥＧ４を含むＲＴＰパケット）を送信する前に，放送メディアの再生方法を示す再生情報を送信する。
【００８８】例えば，コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）を周期的に繰り返し送信して，放送通知情報（ＳＡＰメッセージ）を送信した直後に，カルーセルデータによって再生情報を送信することができる。ここで，カルーセルデータとは，同じデータを繰り返し送信する方式（データカルーセル方式）によって伝送されるデータのことをいう。
【００８９】ここで，再生情報は，ＳＡＰメッセージの「ｐａｙｌｏａｄ（ペイロード）」内に記述されている「ＳＤＰ情報（図４参照）」や，データカルーセル方式によって送信される「ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ  ＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎ  Ｌａｎｇｕａｇｅ）（図８参照）」等に含まれている。
【００９０】また，再生情報は，放送メディアの再生の際に用いられる「レイアウト情報」や，放送メディアの再生の際に用いられる「タイミング情報」を含むことができる。
【００９１】図２は，本実施形態における放送通信システム１におけるコンテンツ送信サーバ１０と受信端末２０との間のシーケンス図である。
【００９２】図２に示すように，ステップ２０１において，コンテンツ送信サーバ１０が，放送通知情報である「ＳＡＰメッセージ」を，受信端末２０に送信する。ＳＡＰメッセージの内容については，後述の図３及び図４において詳細に説明する。ここで，ＳＡＰメッセージが通知される「ＩＰアドレス」及び「ポート番号」は，受信端末２０に既知のものとする。
【００９３】ステップ２０２において，コンテンツ送信サーバ１０が，「ＳＭＩＬ」を含むカルーセルデータを受信端末２０に送信する。また，ステップ２０３において，コンテンツ送信サーバ１０が，ＨＴＭＬ形式のテキスト情報やアンカー情報を含むカルーセルデータを受信端末２０に送信する。
【００９４】例えば，ＪＰＥＧ等の静止画像情報やＸＭＬ形式の構造化データは，ＵＤＰ上でデータを繰り返し送るデータカルーセル方式にて伝送される（図３５参照）。データカルーセル方式については，後述の図５乃至図７の説明において詳細に説明する。
【００９５】ステップ２０４乃至２０７において，コンテンツ送信サーバ１０が，音声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）を含むＲＴＰパケット（放送メディアパケット）を受信端末２０に送信する。
【００９６】ここで，ＳＡＰメッセージ及びカルーセルデータは，ＵＤＰ/ＩＰパケットによって伝送され，音声情報及び映像情報は，ＵＤＰ/ＩＰ上のＲＴＰパケットによって伝送される（図３５参照）。
【００９７】そして，コンテンツ送信サーバ１０は，ＳＡＰメッセージを，所定間隔をもって周期的に繰り返し伝送する。受信端末２０は，ＳＡＰメッセージを受信することにより，放送メディアの再生を開始するので，ＳＡＰメッセージは，できうる限り短い周期にて伝送することが望ましい。
【００９８】次に，図３及び図４を用いて，ＳＡＰメッセージについて説明する。図３は，ＳＡＰメッセージのフォーマットを示すものである。
【００９９】図３において，「Ｖ」は，バージョン情報を示す。「Ａ」は，アドレスタイプを示し，Ａ＝０の時，ＩＰｖ４であり，Ａ＝１の時，ＩＰｖ６である。「Ｒ」は，「Ｒｅｓｅｒｖｅｄ」である。
【０１００】「Ｔ」は，メッセージタイプを示し，Ｔ＝０の時，放送開始を示す放送通知情報であることを意味し，Ｔ＝１の時，放送終了を示す放送通知情報であることを意味する。
【０１０１】「Ｅ」は，「Ｅｎｃｒｙｐｔｉｏｎ  ｂｉｔ」である。「Ｃ」は，「Ｃｏｍｐｒｅｓｓｉｏｎ  ｂｉｔ」である。「ａｕｔｈ  ｌｅｎ」は，「ｏｐｔｉｏｎａｌ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ｄａｔａ」のサイズを示す。
【０１０２】「ｍｓｇ  ｉｄ  ｈａｓｈ」は，「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」に記述されたＩＰアドレスで示される発信元（コンテンツ送信サーバ１０等）によって送信されるＳＡＰメッセージを一意に特定するメッセージＩＤである。
【０１０３】「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」は，ＳＡＰメッセージの発信元のＩＰアドレスである。
【０１０４】ここで，「ｍｓｇ  ｉｄ  ｈａｓｈ」と「ｏｒｉｇｉｎａｔｉｎｇ  ｓｏｕｒｃｅ」との組み合わせによって，ＳＡＰメッセージを一意に特定することができる。
【０１０５】「ｏｐｔｉｏｎａｌ  ｐａｙｌｏａｄ  ｔｙｐｅ」は，「ｐａｙｌｏａｄ」のデータタイプを示す。「ｐａｙｌｏａｄ」については，図４において詳細に説明する。
【０１０６】図４は，本実施形態におけるＳＡＰメッセージ内の「ｐａｙｌｏａｄ」に記述された「ＳＤＰ情報」の例を示す。
【０１０７】「ｖ＝０」は，「ｐａｙｌｏａｄ」のバージョンを示すものであり，「ｐａｙｌｏａｄ」を記述するルールを規定するための情報を示している。
【０１０８】「ｏ＝」は，発信元情報であり，発信元のＩＰアドレス情報（１２６．１６．６４．４）を含む。「ｓ＝」は，放送メディアのセッション名である。「ｃ＝」は，放送メディアを送信しているマルチキャストアドレス（送信先のＩＰアドレス情報）である。「ｔ＝」は，放送メディアの有効期間を示すものである。
【０１０９】「ｍ＝」は，当該ＳＡＰメッセージによって指定されている放送メディアを示す情報であり，図４に示すＳＡＰメッセージは，放送メディアとして，１つの音声情報と１つの映像情報と１つのカルーセルデータを指定している。
【０１１０】すなわち，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ  ３４５６  ＲＴＰ/ＡＶＰ  ０」という記述は，音声情報を「３４５６」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。
【０１１１】また，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ  ２２３２  ＲＴＰ/ＡＶＰ  ９８」という記述は，映像情報を「２２３２」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。
【０１１２】また，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ  ３２４１６  ｕｄｐ  ｄｃ」という記述は，繰り返し送信するカルーセルデータを，ＵＤＰパケットを用いて伝送することを示している。」（１０〜１２ページ）
（４）「【０１４５】第２に，受信端末２０は，ＳＡＰメッセージを参照することにより，音声情報や映像情報やカルーセルデータ等の放送メディアが送信されている「ＩＰアドレス」や，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等の再生情報を取得する。
【０１４６】例えば，図４に示すＳＡＰメッセージを受信した受信端末２０は，「ｃ＝ＩＮＩＰ４  ２２４．２．１７.１２/１２７」という記述により，各放送メディアが送信されている「ＩＰアドレス（マルチキャストアドレス）」を取得する。
【０１４７】また，受信端末２０は，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ  ３４５６  ＲＴＰ/ＡＶＰ  ０」という記述により，音声情報が，ポート番号「３４５６」によってＲＴＰパケットを用いて送信されると解析する。
【０１４８】また，受信端末２０は，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ  ２２３２  ＲＴＰ/ＡＶＰ  ９８」という記述により，映像情報が，ポート番号「２２３２」によってＲＴＰパケットを用いて送信されると解析する。
【０１４９】さらに，受信端末２０は，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ  ３２４１６  ｕｄｐ  ｄｃ」という記述より，ポート番号「３２４１６」によって，ＵＤＰパケット上で，カルーセルデータが送信されると解析する。
【０１５０】第３に，上述の放送メディアについての解析を行った受信端末２０は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つ。」（１３〜１４ページ）
（５）「【０２６６】図２７の例では，コンテンツ送信サーバ１０が，ＳＡＰメッセージ用チャネルを介してＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）を伝送し，番組１用チャネルを介して第１の放送メディア（ＲＴＰ１-ａ，ＲＴＰ１-ｂ）を伝送し，番組２用チャネルを介して第２の放送メディア（ＲＴＰ２-ａ，ＲＴＰ２-ｂ）を伝送している。すなわち，図２７の例では，コンテンツ送信サーバ１０は，番組毎に異なる無線チャネルを使用している。
【０２６７】この場合，コンテンツ送信サーバ１０は，ＳＡＰメッセージにおいて放送メディア（番組）のＩＰアドレス（論理チャネル識別情報）だけ指定したのでは不十分であり，どの無線チャネルにどの放送メディアが流れているかについても特定する必要がある。そこで，コンテンツ送信サーバ１０は，ＳＡＰメッセージ内のＳＤＰ情報の中で，無線チャネルを特定する情報（物理チャネル識別情報）を通知する。
【０２６８】例えば，コンテンツ送信サーバ１０は，図２８に示すように，ＳＤＰの「ｃフィールド」の中で「ｃ＝Ｃｈａｎｎｅｌ  ＡＢＣＤＥ」というように無線チャネルを特定する情報を通知する。無線チャネルを特定する情報としては，ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等が考えられる。
【０２６９】受信端末２０は，この無線チャネルを特定する情報に基づいて，放送メディアの流れている無線チャネルを特定し，当該放送メディアを視聴することが可能となる。
【０２７０】すなわち，本実施形態では，放送通知情報（ＳＡＰメッセージ）内のＳＤＰ情報に，放送メディアが送信される物理チャネル識別情報（ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等の無線チャネルを特定する情報）と論理チャネル識別情報（放送メディアのＩＰアドレス）との対応情報とが含まれている。」（２０ページ）
　上記引用例の記載及び図面（特に図１−４，図２７，図２８，図３５）並びにこの分野における技術常識を考慮すると，
ア　上記（１），（２），（３）の【００８７】及び【００９５】，並びに上記（４）の【０１５０】の記載によれば，引用例には，「放送通信システムにおいて放送メディアを送信する放送通信方法」が記載されていると認められる。
イ　上記（５）の記載及び図２７によれば，ＳＡＰメッセージ用チャネルを介してＳＡＰメッセージが送信され，上記（３）の【００８５】−【００９０】の記載によれば，ＳＡＰメッセージには，放送メディアの再生方法を示す再生情報を含むＳＤＰ情報が含まれている。ここで，ＳＤＰ情報に含まれる再生情報は放送メディアの再生方法を示すものであるから，ＳＤＰ情報は放送メディアを再生するために使用されるといえる。
　したがって，引用例には，「ＳＡＰメッセージ用チャネルを介して，放送メディアを再生するためにＳＤＰ情報を送信する」ことが記載されていると認められる。
ウ　上記（５）の記載及び図２７によれば，放送メディアが，番組１用チャネルを介して，ＳＡＰメッセージとは別に送信されている。そして，上記イのとおり，ＳＡＰメッセージにはＳＤＰ情報が含まれている。
　したがって，引用例には，「番組１用チャネルを介して，ＳＤＰ情報とは別に放送メディアを送信する」ことが記載されていると認められる。
エ　上記（３）の【００８９】，【０１０９】及び図４によれば，ＳＤＰ情報には，「u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps」の情報，音声情報や映像情報などの放送メディアを示す情報，並びに「a=rtpmap:96L8/8000」及び「a=rtpmap:98 MP4V-ES/90000」の情報が含まれている。
　したがって，引用例には，「ここにおいて，前記ＳＤＰ情報は「u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps」の情報，音声情報や映像情報などの放送メディアを示す情報，並びに「a=rtpmap:96L8/8000」及び「a=rtpmap:98 MP4V-ES/90000」の情報を含」むことが記載されていると認められる。
オ　上記（５）の記載及び図２７によれば，番組１用チャネルにおいて放送メディアを送信している。
　したがって，引用例には，「番組１用チャネルにおいて放送メディアを送信すること」が記載されていると認められる。
カ　図２７によれば，ＳＡＰメッセージは放送メディアであるＲＴＰ１−ａ及びＲＴＰ−ｂよりも前に送信されており，上記（３）の【００９６】，【０１０９】−【０１１１】及び図３５によれば，音声情報や映像情報等の放送メディアはＲＴＰパケットによって伝送されている。そして，上記イのとおり，ＳＡＰメッセージにはＳＤＰ情報が含まれており，ＳＤＰ情報は放送メディアを再生するために使用されている。
　したがって，引用例には，「放送メディアの送信よりも前に，放送メディアを再生するためのＳＤＰ情報を送信することと，ここにおいて，前記放送メディアはＲＴＰパケットを含み，前記ＳＤＰ情報は前記ＲＴＰパケットによって伝送される前記放送メディアを再生するために使用される」ことが記載されていると認められる。
　したがって，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。  
「　放送通信システムにおいて放送メディアを送信する放送通信方法であって，
　ＳＡＰメッセージ用チャネルを介して，放送メディアを再生するためにＳＤＰ情報を送信することと，
　番組１用チャネルを介して，ＳＤＰ情報とは別に放送メディアを送信することと，を備え，
　ここにおいて，前記ＳＤＰ情報は「u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps」の情報，音声情報や映像情報などの放送メディアを示す情報，並びに「a=rtpmap:96L8/8000」及び「a=rtpmap:98 MP4V-ES/90000」の情報を含み，
　前記方法はさらに，
　番組１用チャネルにおいて放送メディアを送信することと，
　放送メディアの送信よりも前に，放送メディアを再生するためのＳＤＰ情報を送信することと，ここにおいて，前記放送メディアはＲＴＰパケットを含み，前記ＳＤＰ情報は前記ＲＴＰパケットによって伝送される前記放送メディアを再生するために使用される，を備える，方法。」
［技術常識］
　同じく当審による拒絶の理由に引用された「Y.Kikuchi, et.al., RTP Payload Format for MPEG-4 Audio/Visual Streams（［当審仮訳］：MPEG-4 音声/映像ストリームのためのRTPペイロードフォーマット）, Network Working Group Request for Comments: 3016 (RFC 3016), 2000年11月」には，図面とともに以下の事項が記載されている。
（６）「5.2 SDP usage of MPEG-4 Visual
   The MIME media type video/MP4V-ES string is mapped to fields in the
   Session Description Protocol (SDP), RFC 2327, as follows:
   o  The MIME type (video) goes in SDP m= as the media name.
   o  The MIME subtype (MP4V-ES) goes in SDP a=rtpmap as the encoding
      name.
   o  The optional parameter rate goes in a=rtpmap as the clock
      rate.
   o  The optional parameter profile-level-id and config go in the
      a=fmtp line to indicate the coder capability and configuration,
      respectively.  These parameters are expressed as a MIME media type
      string, in the form of as a semicolon separated list of
      parameter=value pairs.
   The following are some examples of media representation in SDP:
Simple Profile/Level 1, rate=90000(90kHz), profile-level-id and
config are present in a=fmtp line:
  m=video 49170/2 RTP/AVP 98
  a=rtpmap:98 MP4V-ES/90000
  a=fmtp:98 profile-level-id=1;config=000001B001000001B5090000010000000120008440FA282C2090A21F」（１５ページ）
（［当審仮訳］：
5.2 MPEG-4 VisualにおけるSDPの取扱い
　MIMEメディアタイプvideo/MP4V-ES文字列は，Session Description Protocol (SDP)，RFC 2327のフィールドに次のようにマッピングされる。
　o MIMEタイプ（video）は，SDPのm=の中にメディア名として入る。
　o MIMEサブタイプ(MP4V-ES)は，SDPのa=rtpmapの中に符号化方式名として入る。
　o オプションのパラメータrateは，a=rtpmapの中にクロックレートとして入る。
　o オプションのパラメータprofile-level-idとconfigは，符号化器の能力と構成をそれぞれ表示するためにa=fmtp行に入る。これらのパラメータは，セミコロンで仕切られたパラメータ＝値のペアのリストの形の中で，MIMEメディアタイプ文字列として表現される。
　以下はSDPにおけるメディア表現のいくつかの例である。
単純なプロファイル／レベル１, レート=90000(90kHz), profile-level-idとconfigはa=fmtp行の中に存在する：
　m=video 49170/2 RTP/AVP 98
　a=rtpmap:98 MP4V-ES/90000
　a=fmtp:98 profile-level-id=1;config=000001B001000001B5090000010000000120008440FA282C2090A21F）
（７）「5.4 SDP usage of MPEG-4 Audio
   The MIME media type audio/MP4A-LATM string is mapped to fields in the
   Session Description Protocol (SDP), RFC 2327, as follows:
   o  The MIME type (audio) goes in SDP m= as the media name.
   o  The MIME subtype (MP4A-LATM) goes in SDP a=rtpmap as the
      encoding name.
   o  The required parameter rate goes in a=rtpmap as the clock
      rate.
   o  The optional parameter ptime goes in SDP a=ptime attribute.
   o  The optional parameter profile-level-id goes in the a=fmtp
      line to indicate the coder capability.  The object parameter
      goes in the a=fmtp attribute.  The payload-format-specific
      parameters
      bitrate, cpresent and config go in the a=fmtp line.  These
      parameters are expressed as a MIME media type string, in the form
      of as a semicolon separated list of parameter=value pairs.
   The following are some examples of the media representation in SDP:
For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz),
  m=audio 49230 RTP/AVP 96
  a=rtpmap:96 MP4A-LATM/8000
  a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
  a=ptime:20」（１７〜１８ページ）
（［当審仮訳］：
5.4 MPEG-4 AudioにおけるSDPの取扱い
　MIMEメディアタイプaudio/MP4A-LATM文字列は，Session Description Protocol (SDP)，RFC 2327のフィールドに次のようにマッピングされる。
　o MIMEタイプ（audio）は，SDPのm=の中にメディア名として入る。
　o MIMEサブタイプ(MP4A-LATM)は，SDPのa=rtpmapの中に符号化方式名として入る。
　o 必須のパラメータrateは，a=rtpmapの中にクロックレートとして入る。
　o オプションのパラメータptimeは，SDPのa=ptime属性の中に入る。
　o オプションのパラメータprofile-level-idは，符号化器の能力を表示するためにa=fmtp行に入る。objectパラメータはa=fmtp属性の中に入る。ペイロードフォーマットに特有のパラメータbitrate，cpresent及びconfigは，a=fmtp行の中に入る。これらのパラメータは，セミコロンで仕切られたパラメータ＝値のペアのリストの形の中で，MIMEメディアタイプ文字列として表現される。
　以下はSDPにおけるメディア表現のいくつかの例である。
6kb/s CELPビットストリーム（8kHzの音声サンプリングレート）
  m=audio 49230 RTP/AVP 96
  a=rtpmap:96 MP4A-LATM/8000
  a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070
  a=ptime:20）
　（６）及び（７）の記載を考慮すると，ＳＤＰの「a=rtpmap」の欄が符号化方式の名称を示していることは，この分野における技術常識であると認める。
３　対比
　本願発明と引用発明とを対比すると，
（１）引用発明の「放送通信システム」は，明らかに「通信システム」に含まれる。また，引用発明の「送信」が「送達」と同義であることは明らかである。さらに，引用発明の「放送」が「ブロードキャスト」を意味することは明らかであるから，本願発明の「ブロードキャストのファイル」，「ブロードキャストの少なくとも１つのファイル」と引用発明の「放送メディア」とは，「ファイル」であるか否かは別として，「ブロードキャストのコンテンツ」である点で共通する。
　したがって，本願発明の「通信システムにおいてブロードキャストのファイルを送達する方法であって，」と，引用発明の「放送通信システムにおいて放送メディアを送信する放送通信方法であって，」とは，「ファイル」であるか否かは別として，「通信システムにおいてブロードキャストのコンテンツを送達する方法であって，」の点で共通している。
（２）本願発明の「ブロードキャストの少なくとも１つのファイルを処理する」することと引用発明の「放送メディアを再生する」こととは，その対象が「ファイル」であるか否かは別として，「ブロードキャストのコンテンツを処理する」ことである点で共通し，本願発明の「ファイル属性」と引用発明の「ＳＤＰ情報」とは，処理の対象が「ファイル」であるか否かは別として，「ブロードキャストのコンテンツを処理する」ために送信される「コンテンツの属性」である点で共通する。また，引用発明の「ＳＡＰメッセージ用チャネル」は，ブロードキャストのコンテンツを処理するための「コンテンツの属性」を送信するチャネルであるから，本願発明の「第１通信チャネル」に相当する。
　したがって，本願発明の「第１通信セッションにおいて，第１通信チャネルにおけるファイル通信チャネルを介して，前記ブロードキャストの少なくとも１つのファイルを処理するためにファイル属性を送信することと，」と，引用発明の「ＳＡＰメッセージ用チャネルを介して，放送メディアを再生するためにＳＤＰ情報を送信することと，」とは，「ファイル」であるか否かは別として，「第１通信チャネルを介して，前記ブロードキャストのコンテンツを処理するためにコンテンツの属性を送信することと，」の点で共通している。
（３）引用発明の「番組１用チャネル」は，ブロードキャストのコンテンツを送信するチャネルであるから，本願発明の「第２通信チャネル」に相当する。そして，上記（１）及び（２）のとおりであるから，本願発明の「第２通信セッションにおいて，第２通信チャネルを介して，前記ファイル属性とは別に前記ブロードキャストの前記少なくとも１つのファイルを送信することと，を備え，」と，引用発明の「番組１用チャネルを介して，ＳＤＰ情報とは別に放送メディアを送信することと，を備え，」とは，「第２通信チャネルを介して，前記コンテンツの属性とは別に前記ブロードキャストのコンテンツを送信することと，を備え，」の点で共通している。
（４）本願明細書の【００５６】によれば，本願発明の「永続するファイル属性」はファイル名を含み，「短命のファイル属性」はコンテンツタイプ及び符号化スキームを含んでいる。そして，引用発明の「u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps」の「sdp.03.ps」はファイル名であるから，「永続するコンテンツの属性」といえ，引用発明の「音声情報や映像情報などの放送メディアを示す情報」はコンテンツタイプに相当するから，「短命のコンテンツの属性」といえる。また，上記「２　引用発明及び技術常識」の［技術常識］の項で述べたとおり，ＳＤＰの「a=rtpmap」の欄が符号化方式の名称を示していることは，この分野における技術常識であるから，引用発明の「a=rtpmap:96L8/8000」及び「a=rtpmap:98 MP4V-ES/90000」の情報は符号化スキームに相当するといえ，「短命のコンテンツの属性」といえる。
　そして，上記（２）のとおりであるから，本願発明の「ここにおいて，前記ファイル属性は永続するファイル属性と短命のファイル属性とを含み，」と，引用発明の「ここにおいて，前記ＳＤＰ情報は「u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps」の情報，音声情報や映像情報などの放送メディアを示す情報，並びに「a=rtpmap:96L8/8000」及び「a=rtpmap:98 MP4V-ES/90000」の情報を含み，」とは，「ファイル」であるか否かは別として，「ここにおいて，前記コンテンツの属性は永続するコンテンツの属性と短命のコンテンツの属性とを含み，」の点で共通している。
（５）上記（１）のとおりであるから，本願発明の「前記第２通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的および非妨害的に送信することと，ここにおいて，前記複数のファイルは前記少なくとも１つのファイルを含み，」と，引用発明の「番組１用チャネルにおいて放送メディアを送信することと，」とは，「ファイル」であるか否か，及び「連続的および非妨害的に送信する」か否かは別として，「前記ブロードキャスト用にブロードキャストのコンテンツを送信することと，」の点で共通する。
（６）引用発明の「ＲＴＰパケット」は，放送メディアすなわちデータを格納するものであるから，「データパケット」に含まれる。また，本願発明の「前記複数のデータパケットから前記複数のファイルを再構築する」することと引用発明の「前記ＲＴＰパケットによって伝送される前記放送メディアを再生する」こととは，「データパケットを処理する」ことである点で共通する。
　そして，上記（１）及び（２）のとおりであるから，本願発明の「前記第２通信セッションよりも前の前記第１通信セッションにおいて，前記複数のファイルを処理するための前記ファイル属性を送信することと，ここにおいて，前記複数のファイルは複数のデータパケットを含み，前記ファイル属性は前記複数のデータパケットから前記複数のファイルを再構築するために使用される」と，引用発明の「放送メディアの送信よりも前に，放送メディアを再生するためのＳＤＰ情報を送信することと，ここにおいて，前記放送メディアはＲＴＰパケットを含み，前記ＳＤＰ情報は前記ＲＴＰパケットによって伝送される前記放送メディアを再生するために使用される」とは，「ファイル」であるか否か，及び処理の内容が「複数のファイルの再構築」であるか否かは別として，「前記ブロードキャストのコンテンツを処理するための前記コンテンツの属性を送信することと，ここにおいて，前記ブロードキャストのコンテンツはデータパケットを含み，前記コンテンツの属性は前記データパケットを処理するために使用される」の点で共通する。
　したがって，本願発明と引用発明とは，両者は，以下の点で一致し，また，相違している。
（一致点）
　「　通信システムにおいてブロードキャストのコンテンツを送達する方法であって，
　第１通信チャネルを介して，前記ブロードキャストのコンテンツを処理するためにコンテンツの属性を送信することと，
　第２通信チャネルを介して，前記コンテンツの属性とは別に前記ブロードキャストのコンテンツを送信することと，を備え，
　ここにおいて，前記コンテンツの属性は永続するコンテンツの属性と短命のコンテンツの属性とを含み，
　前記方法はさらに，
　前記ブロードキャスト用にブロードキャストのコンテンツを送信することと，
　前記ブロードキャストのコンテンツを処理するための前記コンテンツの属性を送信することと，ここにおいて，前記ブロードキャストのコンテンツはデータパケットを含み，前記コンテンツの属性は前記データパケットを処理するために使用される，を備える，方法。」
（相違点１）
　一致点の「ブロードキャストのコンテンツ」に関し，本願発明は，「ブロードキャストのファイル」，「ブロードキャストの少なくとも１つのファイル」，及び「複数のファイル，ここにおいて，前記複数のファイルは前記少なくとも１つのファイルを含み」を送達及び処理するのに対し，引用発明はブロードキャストのコンテンツを少なくとも１つのファイルを含む複数のファイルとして送達及び処理することが明らかでなく，このため，一致点の「コンテンツの属性」に関し，本願発明は，「ファイル属性」であるのに対し，引用発明はファイル属性であるか否かが明らかでなく，さらに，一致点の「データパケット」に関し，本願発明は，「複数のデータパケット」であるのに対し，引用発明は，データパケットが複数であることが明らかでなく，それにともない，一致点の「前記コンテンツの属性は前記データパケットを処理するために使用される」に関し，本願発明は，処理の内容に「前記複数のデータパケットから前記複数のファイルを再構築する」ことを含むのに対し，引用発明は「前記放送メディアを再生する」ことを含むものの，「前記複数のデータパケットから前記複数のファイルを再構築する」ことを含むのか否かが明らかでない点。
（相違点２）
　一致点の「コンテンツの属性」及び「コンテンツ」の送信に関し，本願発明は，それぞれ「第１通信セッションにおいて，第１通信チャネルにおけるファイル通信チャネルを介して」及び「第２通信セッションにおいて」送信し，かつ「第１通信セッション」は「前記第２通信セッションよりも前」であり，さらに「コンテンツ」を「連続的および非妨害的」に送信するのに対し，引用発明は，それぞれ「ＳＡＰメッセージ用チャネル」及び「番組１用チャネル」において送信するものの，「通信セッション」及び「第１通信チャネルにおけるファイル通信チャネル」については明らかではなく，コンテンツを「連続的および非妨害的」に送信することも明らかでない点。
４　検討
　上記各相違点について検討する。
（相違点１について）
　端末がサーバからコンテンツをダウンロードして再生する通信システムにおいて，前記端末及び前記サーバが，前記コンテンツを，少なくとも１つのファイルを含む複数のファイルとして扱うこと，並びにＲＴＰパケットによりファイルを伝送する際に，送信側で当該ファイルを複数のパケットに分割して送信し，受信側で前記複数のパケットとして前記ファイルを受信して元のコンテンツを復元するために再構築する処理を行うことは，当業者により一般的に行われていることにすぎず，その際に，複数の「コンテンツの属性」を「再構築する処理」のために使用することは，当業者が適宜なし得ることである。
　そうすると，ブロードキャストのコンテンツをブロードキャストの少なくとも１つのファイルとして受信して，複数のファイル属性に基づいて前記少なくとも１つのファイルを再構築すること，すなわち，相違点１は，格別困難なことではなく，当業者が容易になし得ることである。
（相違点２について）
　引用例の記載（上記「２　引用発明及び技術常識」の（３）の【００８４】）によれば，引用発明は，インターネットプロトコル（ＩＰ）をサポートする通信システムを前提としており，ＩＰをサポートする通信システムにおいて，通信セッション単位で通信を行うことは，当業者における技術常識であるから，異なるチャネルに異なる通信セッションを対応付けることは格別困難なことではない。
　そして，引用発明において，ＳＤＰ情報は放送メディアの送信よりも前に送信されるのであるから，引用発明において放送メディアを再生するための「ＳＡＰメッセージ用チャネル」と「番組用チャネル」とをそれぞれ別の通信セッションとした場合，「ＳＡＰメッセージ用チャネルの通信セッション」が「番組１用チャネルの通信セッション」よりも前となることは明らかであり，その場合に，「ＳＡＰメッセージ用チャネルの通信セッション」及び「番組１用チャネルの通信セッション」を，それぞれ「第１通信セッション」及び「第２通信セッション」と称することは任意である。
　また，本願発明の「第１通信チャネルにおけるファイル通信チャネルを介して，」なる点は，平成２５年１０月２日付け手続補正により限定された事項であるが，本願明細書を見ても「ファイル通信チャネル」なるものは記載されておらず，平成２５年１０月２日付け意見書をみても当該補正の根拠は明らかにされていない。このため，明細書全体の記載を考慮して当該用語の意味を解釈すると，第１の通信セッション（第１の通信チャネル）においてファイル属性が送信されている期間を単に「ファイル通信チャネル」と称する態様を含むと解するのが相当である。そして，引用発明がＳＡＰメッセージ用チャネルにおいてＳＤＰ情報を送信している期間を「ＳＤＰ情報チャネル」と称するのは任意であり，「ＳＡＰメッセージ用チャネルにおけるＳＤＰ情報チャネルを介して，」ＳＤＰ情報を送信するといえるから，「第１通信チャネルにおけるファイル通信チャネルを介して，」の点には実質的な相違は無い。
　さらに，本願明細書の【００５３】の「図５に示すように，コンテンツファイルパケット同士の間にはＦＤＴが割り込んでいない。むしろ，コンテンツファイル（例えばファイル８３，８４）は，連続的および非妨害的に伝送されるよう設計されている。」なる記載によれば，本願発明において，連続的および非妨害的に送信することは，間にコンテンツの属性が割り込むことなく送信する態様を含んでいる。そして，引用例の図２７からは，ブロードキャストのコンテンツすなわちＲＴＰ１−ａ及びＲＴＰ−ｂを，その間にコンテンツの属性すなわちＳＡＰメッセージが割り込むことなく送信することが見て取れるから，ブロードキャストのコンテンツを連続的および非妨害的に送信することは，当業者が容易になし得ることにすぎない。
　したがって，相違点２は格別困難なことではなく，当業者が容易になし得ることにすぎない。
　そして，本願発明の作用効果も，引用発明及び技術常識に基づいて当業者が予測し得る範囲のものであり，格別なものではない。 
５　むすび
　以上のとおり，本願発明は，引用発明及び技術常識に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。 
　よって，結論のとおり審決する。