2016-009308

特願２０１４－１５２３８５「マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置」拒絶査定不服審判事件〔平成２６年１１月２０日出願公開，特開２０１４－２２０８４０〕について，次のとおり審決する。

【結　論】 本件審判の請求は，成り立たない。

【理　由】 １　手続の経緯・本願発明 本願は，２００６年４月１０日（パリ条約による優先権主張外国庁受理　２００５年４月８日　米国，２００６年４月６日　米国）を国際出願日とする出願である特願２００８－５０５６２１号の一部を，平成２３年３月２４日に新たな特許出願とした特願２０１１－６６４２９号の一部を，平成２６年７月２５日に更に新たな特許出願としたものであって，平成２８年２月１７日付けで拒絶査定がされ，これに対し，同年６月２２日に拒絶査定不服審判が請求され，同時に手続補正がされ，その後，当審において平成２９年４月２８日付けで拒絶理由（以下，「当審拒絶理由」という。）が通知され，同年８月９日付けで手続補正がされたものである。 その請求項１に係る発明（以下，「本願発明」という。）は，平成２９年８月９日付けで手続補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。 「第１通信セッションと，第２通信セッションとを含むアウトオブバンド通信方式を用いる通信システム内でブロードキャストのファイルをダウンロードする方法であって， 前記第１通信セッションにおいて，少なくとも１つのコンテンツファイルのファイル属性を受信することと， 前記第２通信セッションにおいて，前記ファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのコンテンツファイルを受信することと， を備え，前記ファイル属性は，前記少なくとも１つのコンテンツファイルよりも先に受信され，および前記少なくとも１つのコンテンツファイルを再構築するために使用され，前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに， 前記ファイル属性を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと， 前記少なくとも１つのコンテンツファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと， を備え， 前記第２通信セッション中の前記少なくとも１つのコンテンツファイルの前記受信は，前記第１通信セッション中に前記ファイル属性が正確に受信されたとの確認がされた後にのみ実行される，方法。」 ２　引用発明 当審拒絶理由に引用された特開２００３－３０４５１１号公報（以下，「引用例」という。）には，図面とともに以下の事項が記載されている。 （１）「【０００１】 【発明の属する技術分野】本発明は，映像（ビデオ）情報，音声（オーディオ）情報等の放送メディアを放送するための放送通信システム，放送通信方法，及び，これらに用いて好適な通信端末，サーバ装置，中継装置及びプログラムに関する。」 （２）「【００２７】 【課題を解決するための手段】本発明の第１の特徴は，受信した放送メディアを再生する通信端末であって，前記放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合，前記再生情報に基づいて，指定された該放送メディアを再生することを要旨とする。」 （３）「【００８４】（第１の実施形態）本発明の第１の実施形態について図１から図１１を用いて説明する。本実施形態では，インターネットプロトコルである「ＲＴＰ/ＵＤＰ/ＩＰ」パケット（放送メディアパケット）の形式で，音声情報や映像情報等を含む放送メディアを伝送する放送通信システム１について説明する。 【００８５】本実施形態では，受信端末２０は，音声情報や映像情報等の放送メディアの再生に先立って，該放送メディアの再生方法を示す再生情報を取得し，放送通知情報（ＳＡＰメッセージ）を受信した場合に，前記再生情報に基づいて放送メディアを再生する。ここで，放送通知情報（ＳＡＰメッセージ）は，少なくとも一つの放送メディアを指定するものである。 【００８６】コンテンツ送信サーバ１０は，受信端末２０による放送メディアの再生に先立って，放送通知情報（ＳＡＰメッセージ）によって指定されている放送メディアの再生方法を示す再生情報を送信する。 【００８７】コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）によって指定される放送メディア（ＡＭＲを含むＲＴＰパケットやＭＰＥＧ４を含むＲＴＰパケット）を送信する前に，放送メディアの再生方法を示す再生情報を送信する。 【００８８】例えば，コンテンツ送信サーバ１０は，放送通知情報（ＳＡＰメッセージ）を周期的に繰り返し送信して，放送通知情報（ＳＡＰメッセージ）を送信した直後に，カルーセルデータによって再生情報を送信することができる。ここで，カルーセルデータとは，同じデータを繰り返し送信する方式（データカルーセル方式）によって伝送されるデータのことをいう。 【００８９】ここで，再生情報は，ＳＡＰメッセージの「ｐａｙｌｏａｄ（ペイロード）」内に記述されている「ＳＤＰ情報（図４参照）」や，データカルーセル方式によって送信される「ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ ＭｕｌｔｉｍｅｄｉａＩｎｔｅｇｒａｔｉｏｎ Ｌａｎｇｕａｇｅ）（図８参照）」等に含まれている。 【００９０】また，再生情報は，放送メディアの再生の際に用いられる「レイアウト情報」や，放送メディアの再生の際に用いられる「タイミング情報」を含むことができる。 【００９１】図２は，本実施形態における放送通信システム１におけるコンテンツ送信サーバ１０と受信端末２０との間のシーケンス図である。 【００９２】図２に示すように，ステップ２０１において，コンテンツ送信サーバ１０が，放送通知情報である「ＳＡＰメッセージ」を，受信端末２０に送信する。ＳＡＰメッセージの内容については，後述の図３及び図４において詳細に説明する。ここで，ＳＡＰメッセージが通知される「ＩＰアドレス」及び「ポート番号」は，受信端末２０に既知のものとする。 【００９３】ステップ２０２において，コンテンツ送信サーバ１０が，「ＳＭＩＬ」を含むカルーセルデータを受信端末２０に送信する。また，ステップ２０３において，コンテンツ送信サーバ１０が，ＨＴＭＬ形式のテキスト情報やアンカー情報を含むカルーセルデータを受信端末２０に送信する。 【００９４】例えば，ＪＰＥＧ等の静止画像情報やＸＭＬ形式の構造化データは，ＵＤＰ上でデータを繰り返し送るデータカルーセル方式にて伝送される（図３５参照）。データカルーセル方式については，後述の図５乃至図７の説明において詳細に説明する。 【００９５】ステップ２０４乃至２０７において，コンテンツ送信サーバ１０が，音声情報（ＡＭＲ）や映像情報（ＭＰＥＧ-４）を含むＲＴＰパケット（放送メディアパケット）を受信端末２０に送信する。 【００９６】ここで，ＳＡＰメッセージ及びカルーセルデータは，ＵＤＰ/ＩＰパケットによって伝送され，音声情報及び映像情報は，ＵＤＰ/ＩＰ上のＲＴＰパケットによって伝送される（図３５参照）。 【００９７】そして，コンテンツ送信サーバ１０は，ＳＡＰメッセージを，所定間隔をもって周期的に繰り返し伝送する。受信端末２０は，ＳＡＰメッセージを受信することにより，放送メディアの再生を開始するので，ＳＡＰメッセージは，できうる限り短い周期にて伝送することが望ましい。 【００９８】次に，図３及び図４を用いて，ＳＡＰメッセージについて説明する。図３は，ＳＡＰメッセージのフォーマットを示すものである。 【００９９】図３において，「Ｖ」は，バージョン情報を示す。「Ａ」は，アドレスタイプを示し，Ａ＝０の時，ＩＰｖ４であり，Ａ＝１の時，ＩＰｖ６である。「Ｒ」は，「Ｒｅｓｅｒｖｅｄ」である。 【０１００】「Ｔ」は，メッセージタイプを示し，Ｔ＝０の時，放送開始を示す放送通知情報であることを意味し，Ｔ＝１の時，放送終了を示す放送通知情報であることを意味する。 【０１０１】「Ｅ」は，「Ｅｎｃｒｙｐｔｉｏｎ ｂｉｔ」である。「Ｃ」は，「Ｃｏｍｐｒｅｓｓｉｏｎ ｂｉｔ」である。「ａｕｔｈ ｌｅｎ」は，「ｏｐｔｉｏｎａｌ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ」のサイズを示す。 【０１０２】「ｍｓｇ ｉｄ ｈａｓｈ」は，「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」に記述されたＩＰアドレスで示される発信元（コンテンツ送信サーバ１０等）によって送信されるＳＡＰメッセージを一意に特定するメッセージＩＤである。 【０１０３】「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」は，ＳＡＰメッセージの発信元のＩＰアドレスである。 【０１０４】ここで，「ｍｓｇ ｉｄ ｈａｓｈ」と「ｏｒｉｇｉｎａｔｉｎｇ ｓｏｕｒｃｅ」との組み合わせによって，ＳＡＰメッセージを一意に特定することができる。 【０１０５】「ｏｐｔｉｏｎａｌ ｐａｙｌｏａｄ ｔｙｐｅ」は，「ｐａｙｌｏａｄ」のデータタイプを示す。「ｐａｙｌｏａｄ」については，図４において詳細に説明する。 【０１０６】図４は，本実施形態におけるＳＡＰメッセージ内の「ｐａｙｌｏａｄ」に記述された「ＳＤＰ情報」の例を示す。 【０１０７】「ｖ＝０」は，「ｐａｙｌｏａｄ」のバージョンを示すものであり，「ｐａｙｌｏａｄ」を記述するルールを規定するための情報を示している。 【０１０８】「ｏ＝」は，発信元情報であり，発信元のＩＰアドレス情報（１２６．１６．６４．４）を含む。「ｓ＝」は，放送メディアのセッション名である。「ｃ＝」は，放送メディアを送信しているマルチキャストアドレス（送信先のＩＰアドレス情報）である。「ｔ＝」は，放送メディアの有効期間を示すものである。 【０１０９】「ｍ＝」は，当該ＳＡＰメッセージによって指定されている放送メディアを示す情報であり，図４に示すＳＡＰメッセージは，放送メディアとして，１つの音声情報と１つの映像情報と１つのカルーセルデータを指定している。 【０１１０】すなわち，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/ＡＶＰ ０」という記述は，音声情報を「３４５６」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。 【０１１１】また，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ ２２３２ ＲＴＰ/ＡＶＰ ９８」という記述は，映像情報を「２２３２」で特定されるポート番号にて，ＲＴＰパケットによって伝送することを示している。 【０１１２】また，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｄｃ」という記述は，繰り返し送信するカルーセルデータを，ＵＤＰパケットを用いて伝送することを示している。」 （４）「【０１４５】第２に，受信端末２０は，ＳＡＰメッセージを参照することにより，音声情報や映像情報やカルーセルデータ等の放送メディアが送信されている「ＩＰアドレス」や，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等の再生情報を取得する。 【０１４６】例えば，図４に示すＳＡＰメッセージを受信した受信端末２０は，「ｃ＝ＩＮＩＰ４ ２２４．２．１７.１２/１２７」という記述により，各放送メディアが送信されている「ＩＰアドレス（マルチキャストアドレス）」を取得する。 【０１４７】また，受信端末２０は，第１の放送メディアを指定する「ｍ＝ａｕｄｉｏ ３４５６ ＲＴＰ/ＡＶＰ ０」という記述により，音声情報が，ポート番号「３４５６」によってＲＴＰパケットを用いて送信されると解析する。 【０１４８】また，受信端末２０は，第２の放送メディアを指定する「ｍ＝ｖｉｄｅｏ ２２３２ ＲＴＰ/ＡＶＰ ９８」という記述により，映像情報が，ポート番号「２２３２」によってＲＴＰパケットを用いて送信されると解析する。 【０１４９】さらに，受信端末２０は，「ｍ＝ａｐｐｌｉｃａｔｉｏｎ ３２４１６ ｕｄｐ ｄｃ」という記述より，ポート番号「３２４１６」によって，ＵＤＰパケット上で，カルーセルデータが送信されると解析する。 【０１５０】第３に，上述の放送メディアについての解析を行った受信端末２０は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つ。」 （５）「【０２６６】図２７の例では，コンテンツ送信サーバ１０が，ＳＡＰメッセージ用チャネルを介してＳＡＰメッセージ（ＳＡＰ１，ＳＡＰ２）を伝送し，番組１用チャネルを介して第１の放送メディア（ＲＴＰ１-ａ，ＲＴＰ１-ｂ）を伝送し，番組２用チャネルを介して第２の放送メディア（ＲＴＰ２-ａ，ＲＴＰ２-ｂ）を伝送している。すなわち，図２７の例では，コンテンツ送信サーバ１０は，番組毎に異なる無線チャネルを使用している。 【０２６７】この場合，コンテンツ送信サーバ１０は，ＳＡＰメッセージにおいて放送メディア（番組）のＩＰアドレス（論理チャネル識別情報）だけ指定したのでは不十分であり，どの無線チャネルにどの放送メディアが流れているかについても特定する必要がある。そこで，コンテンツ送信サーバ１０は，ＳＡＰメッセージ内のＳＤＰ情報の中で，無線チャネルを特定する情報（物理チャネル識別情報）を通知する。 【０２６８】例えば，コンテンツ送信サーバ１０は，図２８に示すように，ＳＤＰの「ｃフィールド」の中で「ｃ＝Ｃｈａｎｎｅｌ ＡＢＣＤＥ」というように無線チャネルを特定する情報を通知する。無線チャネルを特定する情報としては，ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等が考えられる。 【０２６９】受信端末２０は，この無線チャネルを特定する情報に基づいて，放送メディアの流れている無線チャネルを特定し，当該放送メディアを視聴することが可能となる。 【０２７０】すなわち，本実施形態では，放送通知情報（ＳＡＰメッセージ）内のＳＤＰ情報に，放送メディアが送信される物理チャネル識別情報（ＣＤＭＡ通信方式のチャネライゼーションコードや周波数値等の無線チャネルを特定する情報）と論理チャネル識別情報（放送メディアのＩＰアドレス）との対応情報とが含まれている。」 引用例の上記記載及び図面並びにこの分野における技術常識を考慮すると， ア　上記（１），（２），（３）の【００８７】及び【００９５】，（４）の【０１５０】，（５）の【０２６６】の記載によれば，引用例には，「ＳＡＰメッセージ用チャネルによる送信と，番組用チャネルによる送信とを含む通信を用いる放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法」が記載されていると認められる。 イ　上記（３）の【００８８】，上記（４）の【０１４５】，及び上記（５）の【０２６６】の記載によれば，受信端末がコンテンツ送信サーバから受信する再生情報には，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等が含まれ，前記再生情報は，ＳＡＰメッセージ用チャネルを介して送信されるＳＡＰメッセージに含まれていると認められる。 したがって，引用例には，「ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信する」ことが記載されていると認められる。 ウ　上記（５）の【０２６６】及び図２７の記載によれば，放送メディアは，番組用チャネルにおいて受信するものと認められる。 したがって，引用例には，「番組用チャネルにおいて，前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報とは別に，前記放送メディアを受信する」ことが記載されていると認められる。 エ　上記（４）の【０１５０】の記載によれば，受信したＳＡＰメッセージを参照することにより再生情報を取得して放送メディアについての解析を行った受信端末は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つのであるから，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，放送メディアよりも先に受信されていることは明らかである。また，当該再生情報は放送メディアの再生のために使用されていることは明らかである。 したがって，引用例には，「前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報は，前記放送メディアよりも先に受信され，前記放送メディアの再生のために使用される」ことが記載されていると認められる。 オ　上記（３）の【００８４】の記載によれば，引用例には，「前記放送通信システムは，インターネットプロトコル（ＩＰ）をサポートする」ことが記載されていると認められる。 カ　上記（３）の【００８４】，【００９２】，【００９６】，【０１０９】－【０１１１】，及び上記（４）の【０１４５】の記載によれば，「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を含むＳＡＰメッセージは，受信端末に既知のポート番号を介してＵＤＰ／ＩＰパケットによって伝送され，音声情報や映像情報等の放送メディアは，「３４５６」及び「２２３２」で特定されるポート番号を介して，ＵＤＰ／ＩＰ上のＲＴＰパケットによって伝送されて，受信端末が受信すると認められる。 したがって，引用例には，「前記「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を，受信端末に既知のポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信する」こと及び「前記放送メディアを，「３４５６」及び「２２３２」で特定されるポート番号を介して前記ＩＰの前記ＵＤＰを介して受信する」ことが記載されていると認められる。 したがって，引用例には以下の発明（以下，「引用発明」という。）が記載されているものと認める。 「ＳＡＰメッセージ用チャネルによる送信と，番組用チャネルによる送信とを含む通信を用いる放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法であって， 前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することと， 前記番組用チャネルにおいて，前記再生情報とは別に，前記放送メディアを受信することと， を備え， 前記再生情報は，前記放送メディアよりも先に受信され，前記放送メディアの再生のために使用され， 前記放送通信システムは，インターネットプロトコル（ＩＰ）をサポートし，前記放送通信方法は更に， 前記再生情報を，受信端末に既知のポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと， 前記放送メディアを，「３４５６」及び「２２３２」で特定されるポート番号を介して前記ＩＰの前記ＵＤＰを介して受信することと， を備える，放送通信方法。」 ３　対比 本願発明と引用発明とを対比すると， （１）ＩＥＥＥから刊行され当業者に周知であるIEEE 100 The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition等を参酌すると，一般に，「アウトオブバンド通信方式」は，制御信号とデータとを異なるチャネルで伝送する方式を意味するものと解され，「インバンド」は，制御信号とデータとが同じチャネルで伝送される方式を意味するものと解されるから，引用発明の「ＳＡＰメッセージ用チャネルによる送信と，番組用チャネルによる送信とを含む通信を用いる放送通信システム」は，明らかに「アウトオブバンド通信方式を用いる通信システム」といえる。 また，引用発明の「放送」が「ブロードキャスト」を意味することは明らかであり，本願発明の「少なくとも１つのコンテンツファイル」と引用発明の「放送メディア」とは，「ファイル」であるか否かは別として，「ブロードキャストのコンテンツ」である点で共通する。 また，本願発明の「ブロードキャストのファイルをダウンロードする」ことは，発明の詳細な説明の【０００９】，【００１０】，【００１４】の記載によれば，ブロードキャストされたコンテンツを受信することを含むと認められる。 したがって，本願発明の「第１通信セッションと，第２通信セッションとを含むアウトオブバンド通信方式を用いる通信システム内でブロードキャストのファイルをダウンロードする方法」と，引用発明の「ＳＡＰメッセージ用チャネルによる送信と，番組用チャネルによる送信とを含む通信を用いる放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法」とは，下記の相違点１，２は別として，「通信システム内でブロードキャストのコンテンツをダウンロードする方法であって」の点で共通している。 （２）本願発明の「少なくとも１つのコンテンツファイルを再構築する」ことと，引用発明の「放送メディアを再生する」こととは，その対象が「ファイル」であるか否かは別として，「ブロードキャストのコンテンツを処理する」ことである点で共通する。そして，本願発明の「少なくとも１つのコンテンツファイルのファイル属性」と，引用発明の「「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報」とは，「コンテンツを処理するために必要な情報」である点で共通している。 （３）上記（１），（２）のとおりであるから，本願発明の「前記第１通信セッションにおいて，少なくとも１つのコンテンツファイルのファイル属性を受信することと，前記第２通信セッションにおいて，前記ファイル属性とは別に，前記ブロードキャストの前記少なくとも１つのコンテンツファイルを受信することと，を備え，前記ファイル属性は，前記少なくとも１つのコンテンツファイルよりも先に受信され，および前記少なくとも１つのコンテンツファイルを再構築するために使用され」と，引用発明の「前記ＳＡＰメッセージ用チャネルにおいて，各放送メディアを再生するために必要な「ポート番号」や「ＲＴＰペイロードタイプ」等を含む再生情報を受信することと，前記番組用チャネルにおいて，前記再生情報とは別に，前記放送メディアを受信することと，を備え，前記再生情報は，前記放送メディアよりも先に受信され，前記放送メディアの再生のために使用され」は，下記の相違点１～３は別して，「前記コンテンツを処理するために必要な情報を受信することと，前記コンテンツを処理するために必要な情報とは別に，前記ブロードキャストのコンテンツを受信することと，を備え，前記コンテンツを処理するために必要な情報は，前記コンテンツよりも先に受信され，および前記コンテンツを処理するために使用され」の点で共通している。 （４）本願発明と引用発明とは，「前記通信システムはインターネットプロトコル（ＩＰ）をサポートし」ている点で差異は無い。 また，引用発明において，「受信端末に既知のポート番号」を「第１ポート番号」と称し，「「３４５６」及び「２２３２」で特定されるポート番号」を「第２ポート番号」と称することは任意である。 したがって，本願発明と引用発明とは，「前記コンテンツを処理するために必要な情報を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと，前記少なくとも１つのコンテンツファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと，を備える」点で差異は無い。 したがって，本願発明と引用発明とは，両者は，以下の点で一致し，また，相違している。 （一致点） 「アウトオブバンド通信方式を用いる通信システム内でブロードキャストのコンテンツをダウンロードする方法であって， 前記コンテンツを処理するために必要な情報を受信することと， 前記コンテンツを処理するために必要な情報とは別に，前記ブロードキャストのコンテンツを受信することと， を備え，前記コンテンツを処理するために必要な情報は，前記コンテンツよりも先に受信され，および前記コンテンツを処理するために使用され，前記通信システムはインターネットプロトコル（ＩＰ）をサポートし，前記方法はさらに， 前記コンテンツを処理するために必要な情報を，第１ポート番号を介して前記ＩＰのユーザデータグラムプロトコル（ＵＤＰ）を通して受信することと， 前記少なくとも１つのコンテンツファイルを，第２ポート番号を介して前記ＩＰの前記ＵＤＰを通して受信することと， を備える，方法。」 （相違点１） 一致点の「ブロードキャストのコンテンツ」の受信及び処理に関し，本願発明は，「ブロードキャストのファイル」，「少なくとも１つのコンテンツファイル」を受信及び処理するのに対し，引用発明はブロードキャストのコンテンツを少なくとも１つのファイルとして受信及び処理することが明らかでなく，これに伴い，一致点の「前記コンテンツを処理するために必要な情報は」「前記コンテンツを処理するために使用され」に関し，本願発明は，「前記ファイル属性は」「前記少なくとも１つのコンテンツファイルを再構築するために使用され」であるのに対し，引用発明はファイルに係る当該事項が明らかでない点。 （相違点２） 一致点の「コンテンツを処理するために必要な情報」及び「コンテンツ」の受信に関し，本願発明は，それぞれ「第１通信セッション」及び「第２通信セッション」において受信するのに対し，引用発明は，それぞれ「ＳＡＰメッセージ用チャネル」及び「番組用チャネル」において受信するものの，「通信セッション」については明らかではない点。 （相違点３） 本願発明は「前記第２通信セッション中の前記少なくとも１つのコンテンツファイルの前記受信は，前記第１通信セッション中に前記ファイル属性が正確に受信されたとの確認がされた後にのみ実行され」なる構成を備えているのに対し，引用発明は当該構成が明らかでない点。 ４　検討 （相違点１について） 端末がサーバからコンテンツをダウンロードして再生する通信システムにおいて，前記端末及び前記サーバが，前記コンテンツを少なくとも１つのファイルとして扱うこと，並びにインターネットプロトコル（ＩＰ）をサポートする通信システムにおいてファイルを伝送する際に，送信側で当該ファイルを複数のパケットに分割して送信し，受信側で前記複数のパケットとして前記ファイルを受信して元のコンテンツを復元するために再構築する処理を行うことは，いずれも当業者により一般的に行われていることにすぎない。　また，その場合，ファイルを「再構築する処理」をするために必要な情報を，「ファイル属性」と称することは任意である。 そうすると，ブロードキャストのコンテンツをブロードキャストの少なくとも１つのファイルとして受信し，当該少なくとも１つのコンテンツファイルを再構築するためにファイル属性を使用すること，すなわち，相違点１は，格別困難なことではなく，当業者が容易になし得ることである。 （相違点２について） インターネットプロトコル（ＩＰ）をサポートする通信システムにおいて，通信セッション単位で通信を行うことは，当業者における技術常識であり，異なるチャネルに異なる通信セッションを対応付けることは格別困難なことではない。 また，引用発明では，ＳＡＰメッセージ用チャネルにおける受信は受信端末に既知のポート番号を介しての受信に対応付けられ，番組用チャネルにおける受信は「３４５６」及び「２２３２」で特定されるポート番号を介しての受信に対応付けられることは明らかであるところ，「多種のアウトオブバンドセッションを，前述した時間分離ではなく異なるポート番号によって識別することもできる。」ことは，本願明細書の【００７８】に記載のとおりである。 してみると，相違点２は格別困難なことではなく，当業者が容易になし得ることにすぎない。 （相違点３について） 上記「２　エ」の項で述べたように，引用発明においては，受信したＳＡＰメッセージを参照することにより再生情報を取得して放送メディアについての解析を行った受信端末は，各放送メディアの受信処理の準備を行い，放送メディアが放送されるのを待つ，換言すれば，受信端末は，再生情報を受信して放送メディアについての解析を行った後に，前記再生情報とは別に，放送メディアを受信するものである。 そして，取得した再生情報に基づいて放送メディアについての解析を行う以上，再生情報を正確に受信した後に解析を始めることは明らかであるから，再生情報を正確に受信した後に，放送メディアを受信しているといえるし，また，そのようにすることは普通に行われ得ることに過ぎない。 したがって，相違点３には実質的な相違は無い，また，相違があるとしても当業者が容易になし得ることである。 そして，本願発明の作用効果も，引用発明に基づいて当業者が予測し得る範囲のものであり，格別なものではない。 ４　むすび 以上のとおり，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。 よって，結論のとおり審決する。