拒絶査定不服の審決｜不服2014-1958 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) H04L 審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない(前置又は当審拒絶理由) H04L
管理番号	1307311
審判番号	不服2014-1958
総通号数	192
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2015-12-25
種別	拒絶査定不服の審決
審判請求日	2014-02-03
確定日	2015-11-04
事件の表示	特願2010-235371「マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置」拒絶査定不服審判事件〔平成23年 3月 3日出願公開,特開2011- 45126〕について,次のとおり審決する。
結論	本件審判の請求は,成り立たない。
理由	第1 手続の経緯本願は,2006年4月10日(パリ条約による優先権主張外国庁受理 2005年4月8日米国,2006年4月6日米国)を国際出願日とする出願である特願2008-505621号の一部を,平成22年10月20日に新たな特許出願としたものであって,平成25年9月25日付けで拒絶査定がなされ,これに対し,平成26年2月3日に拒絶査定に対する審判請求がなされるとともに同日付けで手続補正がなされ,当審による同年10月31日付けで通知された拒絶理由に対して,平成27年2月2日付けで手続補正がなされたものである。第2 特許請求の範囲の記載平成27年2月2日付け手続補正書により補正された特許請求の範囲の請求項1ないし20には,次のとおり記載されている。「【請求項1】 (a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって, (a2)アウトオブバンドの通信セッションにおいて,前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を受信することと, (a3)前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に受信した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, (a4)ここにおいて,前記複数のファイル属性は,前記少なくとも1つのファイルよりも先に受信され,また前記処理することは,前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく,前記少なくとも1つのファイルよりも先に受信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築することを含む, (a5)前記通信システムはインターネットプロトコル(IP)をサポートし,前記方法はさらに, (a6)前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, (a7)前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して受信することと,を備える, 方法。【請求項2】第1通信チャネルを通して前記複数のファイル属性を受信することと, 前記少なくとも1つのファイルを第2通信チャネルを通して受信することと,をさらに備える,請求項1に記載の方法。【請求項3】前記インバンドの通信セッション内で,前記ブロードキャストのために複数のファイルを連続的に受信することと,前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッション内で前記複数のファイルを処理するために,前記複数のファイル属性を受信することとをさらに備える,請求項1に記載の方法。【請求項4】インターネットプロトコル(IP)をサポートする通信システム内でブロードキャストを受信するように構成された装置であって,前記装置は, アウトオブバンドの通信セッションにおいて,前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を受信する手段と, 前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に取得した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信する手段と,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記少なくとも1つのファイルよりも先に受信され,また前記処理することは,前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく,前記少なくとも1つのファイルよりも先に受信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築することを含む, 第1通信チャネルを通して前記複数のファイル属性を受信する手段と, 第2通信チャネルを通して前記少なくとも1つのファイルを受信する手段と, を備える装置。【請求項5】前記複数のファイル属性は第1通信チャネルを通して受信され, 前記少なくとも1つのファイルは第2通信チャネルを通して受信される,請求項4に記載の装置。【請求項6】インターネットプロトコル(IP)をサポートする通信システム内のブロードキャストにおいて使用される装置であって,前記装置は, プロセッサと, 前記プロセッサに結合したメモリユニットとを備え,前記メモリユニットは, アウトオブバンドの通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するための複数のファイル属性を受信することと, 前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に取得した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを受信することと, ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記少なくとも1つのファイルよりも先に受信され,また前記処理することは,前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく,前記少なくとも1つのファイルよりも先に受信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築することを含む, 第1ポート番号を介し,前記IPのユーザデータグラムプロトコル(UDP)を通して前記複数のファイル属性を受信することと,第2ポート番号を介して,前記IPの前記UDPを通して前記少なくとも1つのファイルを受信することとのためのコンピュータ読み出し可能な命令を含む, 装置。【請求項7】前記メモリユニットは,第1通信チャネルを通して前記複数のファイル属性を受信するための,及び前記少なくとも1つのファイルを第2通信チャネルを通して受信するためのコンピュータ読み出し可能な命令とをさらに備える,請求項6に記載の装置。【請求項8】前記メモリユニットはさらに,前記インバンドの通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信するための,及び前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッションにおいて,前記複数のファイルを処理するための前記複数のファイル属性を受信するための,コンピュータ読み出し可能な命令とを備える,請求項6に記載の装置。【請求項9】コンピュータ読み出し可能な命令を含むコンピュータ読み出し可能な記録媒体であって, インターネットプロトコル(IP)をサポートする通信システム内のアウトオブバンドの通信セッションにおいてブロードキャストの少なくとも1つのファイルのコンテンツを処理するための複数のファイル属性を受信することと, 前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に受信した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと, ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記少なくとも1つのファイルよりも先に受信され,また前記処理することは,前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく,前記少なくとも1つのファイルよりも先に受信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築することを含む, 前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, 前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して受信することと, のためのコンピュータ読み出し可能な命令を含むコンピュータ読み出し可能な記録媒体。【請求項10】インターネットプロトコル(IP)をサポートする通信システム内でブロードキャストのファイルを送達する装置であって,前記装置は, アウトオブバンドの通信セッションにおいて,加入者ノードへ前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を送信する手段と, インバンドの通信セッションにおいて,前記加入者ノードへ前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを送信する手段と, ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく,前記少なくとも1つのファイルよりも先に送信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも1つのファイルよりも先に送信される, 第1ポート番号を介し,前記IPのユーザデータグラムプロトコル(UDP)を通して前記複数のファイル属性を送信する手段と, 第2ポート番号を介し,前記IPの前記UDPを通して前記少なくとも1つのファイルを送信する手段と,を備える装置。【請求項11】前記複数のファイル属性は,第1通信チャネルを通して送信され, 前記少なくとも1つのファイルは,第2通信チャネルを通して送信される,請求項10に記載の装置。【請求項12】前記複数のファイル属性は第1のアドレスを介して送信され,前記少なくとも1つのファイルは第2のアドレスを介して送信され,前記第2のアドレスは前記第1のアドレスと異なる,請求項10に記載の装置。【請求項13】前記複数のファイル属性は第1のアドレスを介して送信され,前記少なくとも1つのファイルは第2のアドレスを介して送信され,前記第1および第2のアドレスは同じであるが,前記第1および第2のポート番号は異なる, 請求項10に記載の装置。【請求項14】前記インバンドの通信セッション内で,前記ブロードキャストのために複数のファイルを連続的に送信し,前記インバンドの通信セッションよりも前の前記アウトオブバンドの通信セッション内で前記複数のファイルを処理するために,前記複数のファイル属性を送信する手段をさらに備える,請求項10に記載の装置。【請求項15】前記複数のファイル属性は,永続するファイル属性と短命のファイル属性とを備える,請求項10に記載の装置。【請求項16】通信システム内のブロードキャストのファイルを送達する方法であって,前記方法は, アウトオブバンドの通信セッションにおいて,加入者ノードへ前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を送信することと, インバンドの通信セッションにおいて,前記加入者ノードへ前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを送信することと,を備え, ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく,前記少なくとも1つのファイルよりも先に送信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも1つのファイルよりも先に送信される, 前記通信システムはインターネットプロトコル(IP)をサポートし,前記方法はさらに, 前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して送信することと, 前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して送信することと,を備える, 方法。【請求項17】第1通信チャネルを通して前記複数のファイル属性を送信することと, 前記少なくとも1つのファイルを第2通信チャネルを通して送信することと,をさらに備える,請求項16に記載の方法。【請求項18】前記複数のファイル属性は,永続するファイル属性と短命のファイル属性とを備える,請求項16に記載の方法。【請求項19】インターネットプロトコル(IP)をサポートする通信システム内のブロードキャストにおいて使用される装置であって,前記装置は, プロセッサと, 前記プロセッサに結合したメモリユニットとを備え,前記メモリユニットは, アウトオブバンドの通信セッションにおいて加入者ノードへ前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するための複数のファイル属性を送信することと, インバンドの通信セッションにおいて,前記加入者ノードへ前記複数のファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信することと, ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, ここにおいて,前記複数のファイル属性は,前記インバンドの通信セッションにおいて前記加入者ノードへ前記複数のファイル属性を送信することなく,前記少なくとも1つのファイルよりも先に送信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築するために前記加入者ノードをイネーブルにするために前記少なくとも1つのファイルよりも先に送信される, 前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して送信することと, 前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して送信することと, のためのコンピュータ読み出し可能な命令を含む, 装置。【請求項20】前記メモリユニットは,第1通信チャネルを通して前記複数のファイル属性を送信するための,及び前記少なくとも1つのファイルを第2通信チャネルを通して送信するためのコンピュータ読み出し可能な命令とをさらに備える,請求項19に記載の装置。」第3 当審における拒絶の理由当審において,平成26年10月31日付けで通知した拒絶の理由は,以下のとおりである。「1)本件出願の下記の請求項に係る発明は,その出願前に日本国内又は外国において,頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。 2)本件出願は,特許請求の範囲の記載が下記の点で不備のため,特許法第36条第6項第1号,及び第2号に規定する要件を満たしていない。記 (引用文献等については引用文献等一覧参照) 理由1)について請求項 1-20 引用例等 1 備考引用文献1,特に,段落【0001】,【0027】,図1乃至図4の説明である段落【0084】ないし【0112】,【0142】,【0146】ないし【0150】,図35には以下の発明(以下「引用発明」という。)が記載されている。「コンテンツ通信サーバ10は,インターネット2を介して,受信端末20へ,音声情報,映像情報,カルセールデータからなる放送メディアの再生に先だって,放送メディアのレイアウト情報やタイミング情報を含む再生情報を送信し,受信端末20は,放送メディアの再生に先だって,前記再生情報を受信して放送メディアを再生する放送通信システムにおいて, 上記レイアウト情報やタイミング情報を含む再生情報は,放送通知情報(SAPメッセージ)内のSDP情報やカルーセルデータとしてのSMILに含まれ, 上記SAPメッセージ及びカルーセルデータは,UDP/IPパケットによって伝送され,音声情報及び映像情報は,UDP/IP上のRTPパケットによって伝送され, 上記カルーセルデータは,同一のデータを繰り返し伝送するものであり,再生情報,静止画情報,テクスト情報(テロップ,静止文字),動画像情報や音声情報を,ファイル化して伝送するものであり, 上記SAPメッセージ内の上記再生情報をもとに,カルーセルデータのテキスト情報,音声情報,映像情報の再生を行う放送通信システム。」本願発明と引用発明とを対比すると,以下の点で相違し,その余の点において一致する。本願発明においては,アウトオブバンドの通信セッションとインバンドの通信セッションを使用するのに対して,引用発明においては,どのようなバンドを使っているか不明な点。上記相違点を検討する。下記にも記載するように,本案発明の「アウトオブバンド」,及び「インバンド」の定義は必ずしも明確ではないが,引用発明では,再生情報を含むSAPメッセージが先だって送信され,その後,放送メディアがSAPメッセージの送信されるチャネルとは異なるチャネルで送信されており,引用発明のSAPメッセージの送信をアウトオブバンドの通信セッションとし,引用発明の放送メディアの送信をインバンドの通信セッションとすることは,当業者が容易に想到できることである。理由2)について (1)請求項1の記載に「(a2)アウトオブバンドの通信セッションにおいて,前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を受信することと,(a3)インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと」とあり,「アウトオブバンドの通信セッション」と「インバンドの通信セッション」の両方を用いていると認められる。しかしながら,発明の詳細な説明の段落【0050】には「本発明の例証的な実施形態によれば,FDTとコンテンツデータパケットは,従来実施されていたようにインバンド方式で受信されない。代わりに,ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。」,また,段落【0052】には,「次に図5を参照する。この実施形態では,データパケット#1?#5のようなペイロードデータと比較して,先に述べたFDT78に含まれているファイル属性のようなファイル属性82が別々に,即ち,インバンド方式ではなくアウトバンド方式で送信される。」と記載されており,詳細な説明には,ファイル属性とコンテンツデータを異なるセッションで送るアウトバンドのものしか記載されておらず,両セッションを用いるものは記載されていない。したがって,請求項1の記載は,発明の詳細な説明に記載した範囲を超えるものである。(6項1号) また,請求項の記載において「アウトオブバンドの通信セッション」,及び「インバンドの通信セッション」の定義が不明であり,請求項1の記載が不明確となっている。(6項2号) (2)同様に,請求項3,6,8,9,10,14,16,19についても,発明の詳細な説明には両セッションを用いるものは記載されておらず,各請求項の記載は,発明の詳細な説明に記載した範囲を超えるものである。(6項1号) また,各請求項の記載において「アウトオブバンドの通信セッション」l及び「インバンドの通信セッション」の定義が不明であり,各請求項の記載が不明確となっている。(6項2号) (3)請求項5には,ファイル属性を受信する手段と少なくとも1つのファイルを受信する手段とを,さらに備えるとしているが,さらに備えることは,発明の詳細な説明には記載されておらず(6項1号),さらに備える技術的必要性も明確でない。また,請求項5が引用する請求項4には,第1及び第2の通信チャネルを通して受信する手段を備えているにも係わらず,請求項5において,さらに同様の受信する手段を備えるという構成は,発明の構成が不明確である。(6項2号) 請求項11についても同様である。 (3)請求項9の記載には「コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体」とあり,発明の詳細な説明の段落【0077】には「コンピュータ読み出し可能な媒体」としては記録媒体のみならず伝送媒体も含まれる旨の記載をし独自の定義を行っているが,通常,「コンピュータ読み出し可能な媒体」は記録媒体を指すものであり,「コンピュータ読み出し可能な媒体」を通常の意味に解するか独自に定義した意味に解すべきか不明であり,請求項9に係る発明が不明確となっている。(6項2号) (4)請求項10の記載に「第1のアドレス」と「第2のアドレス」にとあるが,「アドレス」に関して,発明の詳細な説明の段落【0031】に,データパケットのソースアドレスと宛先アドレスを追加する旨が記載されているだけで,上記「第1のアドレス」と「第2のアドレス」に対応するものとは認められず,発明の詳細な説明との対応が不明であり(6項1号),又は,どのような技術的意味があるのかも明確でない。(6項2号) (5)請求項10,14には「受信する手段」が記載されているが,これらの請求項に係る各発明は,ファイルを送達する装置に関するものであって,「受信する手段」を備える技術的必要性が不明であり,また,他の構成との関係も不明である。(6項2号) 引用文献等一覧 1.特開2003-304511号公報」第4 特許法第36条第6項第2号について 1 請求人の対応上記拒絶の理由の通知に対して,請求人は,平成27年2月2日付けで意見書と手続補正書を提出した。請求人は,上記意見書において,拒絶の理由2)の(1)及び(2)の指摘に対して, 「3-1.拒絶理由2(1)(特許請求の範囲の記載不備) (i)審査官殿は,本願請求項1の発明は,アウトオブバンドの通信セッションとインバンドの通信セッションの両方を用いているが,本願明細書には,上記両通信セッションを用いることは説明されていないので,本願請求項1の発明は明細書にサポートされていないことを指摘しました。 (ii)さらに,両通信セッションの定義を明確にすることを求めています。請求項1の構成(a3)を下記の通りに補正しました。「(a3)前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に受信した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである」上記補正は,本願の明細書の少なくとも段落[0051]および[0053]に基づくものです。特に,段落[0053]は,アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることをサポートしています。なぜなら,この開示は,ファイル属性は第1通信セッション(アウトオブバンドの通信セッション)中に取得/受信され,ファイル属性が第1通信セッション中に正確に取得/受信された後に,ファイルコンテンツは第2通信セッション(インバンドの通信セッション)中に取得/受信されることを教示しています。段落[0051]は,「インバンド方式」は,同一の伝送セッション内での情報の移送を意味し,「アウトオブバンド方式」は,多様な伝送セッションを介した情報の移送を意味するものと定義しています。理由2(1)は,上記の補正及び意見により,解消するものと思料いたします。なお,審査官殿は,理由2(1)の中で,本願明細書[0050]に言及していますが,[0050]は,請求項1の発明とは異なる観点に基づく説明であることは自明です。 3-2.拒絶理由2(2) 審査官殿は,他の請求項3,6,8,9,10,14,16,19に関しても,請求項1と同じ記載不備を指摘しました。他の独立請求項に関しても,請求項1と同様の補正を行いました。したがって,上記項目3-1.で述べたものと同様の理由から,拒絶理由2(2)は解消されたものと思料いたします。」と主張している。 2 当審の判断 (1)拒絶の理由2)の(1)及び(2)について請求項1,3,6,8,9,10,14,16,19に記載された「アウトオブバンドの通信セッション」なる構成について,アウトオブバンドは,IEEEから刊行され当業者に周知であるIEEE 100 The Authoritative Dictionary of IEEE Standards Terms, Seventh Editionの下記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」のとおり,一般に,制御信号とデータとを異なるチャネルで伝送する方式を意味するものと解され,異なるチャネルでの制御信号の伝送及びデータの伝送はそれぞれ通信セッションが異なると考えられる余地はあるものの,単一の「セッション」と「アウトオブバンド」の概念とは必ずしも結びつかないから,何をもって「アウトオブバンドの通信セッション」と言い得るのか不明確であり,その意味内容を一義的に理解することは困難である。このため,本願明細書の発明の詳細な説明の記載を参酌して,その意味内容を理解すると,上記文言について,本願明細書の発明の詳細な説明には以下の記載がある。「【0051】これ以降では,用語「インバンド方式」は,伝送チャネルを介し,さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は,図4の伝送工程に図示し,説明しているとおりのものである。一方,用語「アウトバンド方式」は,図5に図示し,以降で説明する伝送工程によって例証されるように,こうした移送が同一の伝送チャネルを介して行われるか,あるいは別の伝送チャネルを介して行われるかに関係なく,多様な伝送セッションを介して,情報の移送を意味するものとして解釈される。【0052】次に図5を参照する。この実施形態では,データパケット#1?#5のようなペイロードデータと比較して,先に述べたFDT78に含まれているファイル属性のようなファイル属性82が別々に,即ち,インバンド方式ではなくアウトバンド方式で送信される。【0053】 FAは,ネットワーク44(図2)により,またブロードキャストチャネル内で伝送されることが好ましい。例えば,FAは先に述べたSGの一部であってよい。SGとさらにFAは,ブロードキャストサービスをシークするノード50によって最初に取得される。即ち,FA82は第1通信セッション81中に取得される。FA82を正確に取得した後,ノード50は,ファイル84のようなコンテンツファイルを取得するために,SG内に提供された情報に従ってチャネルに同調する。即ち,コンテンツファイルは第2通信セッション86中に取得される。図5に示すように,コンテンツファイルパケット同士の間にはFDTが割り込んでいない。むしろ,コンテンツファイル(例えばファイル83,84)は,連続的および非妨害的に伝送されるよう設計されている。表現を変えれば,通信セッション81中の早い時期にノード50がFA82を正確に取り出したと確認された後にのみ,コンテンツファイルが通信セッション86中にダウンロードされる。これにより,ファイルとFDTの両方がインバンド方式で,また上述したとおりに受信される場合に,ファイル処理の成功が関連するFDTのダウンロードの成功によって決まってしまう状況を回避できる。」 ([当審注]: 【0051】のインバンド方式に関する「伝送チャネルを介し,」,アウトバンド方式に関する「多様な伝送セッションを介して,」について,本願は特許法第36条の2第1項の規定による特許出願であるところ,外国語書面の明細書の[0063]にはそれぞれ「through the same transmission channel」,「through different transmission sessions」と記載されているから,それぞれ「同一の伝送チャネルを介し,」「別の伝送セッションを介して,」と解すべきである。また,翻訳文における「インバンド方式」,「アウトバンド方式」なる訳語は,外国語書面の明細書にはそれぞれ「in-band」,「out-of-band」と記載されているから,請求項1に記載された「アウトオブバンドの通信セッション」,「インバンドの通信セッション」は,「アウトバンド方式の通信セッション」,「インバンド方式の通信セッション」と解すべきである。) まず,発明の詳細な説明には,請求項1に記載された「アウトオブバンドの通信セッション」,「インバンドの通信セッション」なる記載は存在しない。そして,【0051】の記載によれば,同一の伝送チャネルを介し,さらに実質的に同一の伝送セッション内での情報の移送が為されれば,「インバンド方式」の通信といえ,当該通信に係るセッションは「インバンドの通信セッション」と理解することは一応可能である。そして,【0051】では,図4はインバンド方式の情報移送の例を示すものとされており,図4では,同一のチャネル及び同一の伝送セッション内で制御信号及びデータが伝送されていると認められるから,当該理解は,上記情報が制御信号とデータを含む場合には,下記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」の内容と一致するものである。一方,【0051】の記載によれば,移送が同一の伝送チャネルを介して行われるか,あるいは別の伝送チャネルを介して行われるかに関係なく,別の伝送セッションを介して,情報の移送が為されれば,「アウトバンド方式」の通信といえる。そして,【0051】では,図5はアウトバンド方式の情報移送の例を示すものとされており,図5ではFAが伝送される第1通信セッション81と,コンテンツファイルが伝送される第2通信セッション86とが示されている。ここで,【0051】,【0052】の記載によれば,情報が別々のセッションで移送されるからこそアウトバンド方式での通信といえるから,アウトバンド方式の通信を形成する個々の通信セッションの各々も,「アウトオブバンドの通信セッション」と考えることもできる。そのような理解は,上記情報が制御信号とデータを含む場合には,下記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」の内容とも一致するものである。しかしながら,【0051】の記載は,移送される「情報」について制御信号とデータとの別を明らかにしていないため,第1通信セッション81単体でみた場合,同一チャネルかつ同一セッション(すなわち,第1通信セッション81)で情報(すなわち,FA。)の移送が為されるから,【0051】の記載によれば,第1通信セッション81は「インバンド方式」の通信セッションともいえることになる。同様に,第2通信セッション86単体でみた場合,同一チャネルかつ同一セッション(すなわち,第2通信セッション86)で情報(すなわち,コンテンツ。)の移送が為されるから,【0051】の記載によれば,第2通信セッション86は「インバンド方式」の通信セッションともいえることになる。このため,第1通信セッション81,第2通信セッション86は,「アウトオブバンドの通信セッション」,「インバンドの通信セッション」のいずれに含まれるのかが不明確である。したがって,発明の詳細な説明の記載を勘案しても,「アウトオブバンドの通信セッション」なる構成が不明確である。更に,「インバンド」は,下記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」のとおり,一般に,制御信号とデータとが同じチャネルで伝送される方式を意味するものと解されるから,請求項1の「(a3)・・・インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである,」の「インバンド通信セッション」では,データであるコンテンツのみならず,制御信号であるFAも同時に伝送されるものとも解される。そうすると,請求項1,3,6,8,9,10,14,16,19に係る発明は,「インバンド通信セッション」について,下記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」に示される一般的なインバンド-シグナリングの解釈と,【0051】の記載に基づくアウトバンド方式を構成する個々の通信セッション(図5の第2の通信セッション86)との解釈との異なる定義による2つの解釈が可能であるところ,そのいずれと解すべきか不明であるため,特許を受けようとする発明が不明確である。 ■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義「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年) (当審仮訳: 「インバンド-シグナリング」シグナリング情報がデータと同じ情報フローで送信されるシグナリングアプリケーション「アウトオブバンド-シグナリング」シグナリング情報がユーザ情報チャネルの外であるシグナリングアプリケーション,関連するユーザデータとは異なる物理又は論理チャネル,例えば異なる物理パス,時分割多重(TDM)ストリームの異なるタイムスロットを介して送信されるか否か ) 3 小括したがって,この出願は,特許請求の範囲の記載が,特許法第36条第6項第2号に規定する要件を満たしていない。第5 特許法第36条第6項第1号について 1 請求人の対応上記拒絶の理由の通知に対する請求人の対応は,上記第3の1のとおりである。 2 当審の判断上記「第4 特許法第36条第6項第2号について」の項で述べたように,【0051】によれば,図4はインバンド方式の例を示すものであり,図5はアウトバンド方式の例を示すものである。そして,アウトバンド方式の例を示したものである図5の第2の通信セッション86が「インバンドの通信セッション」であることは,発明の詳細な説明に記載されておらず,そのように一義的に解釈できるものではない。そして,図4の例と図5の例とは独立した例であって,アウトバンド方式とインバンド方式とを併用することは,発明の詳細な説明に記載も示唆もされていない。すなわち,上記「第4 特許法第36条第6項第2号について」の項で述べたように,「インバンド方式」は,上記「■インバンド-シグナリング及びアウトオブバンド-シグナリングの定義」のとおり,一般に,制御信号とデータとが同じチャネルで伝送される方式を意味するものと解されるから,請求項1の「(a3)・・・インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである,」の「インバンド通信セッション」では,データであるコンテンツのみならず,制御信号であるFAも同時に伝送されるものとも解される。しかし,そのようなものは,発明の詳細な説明に記載も示唆もされておらず,自明でもない。なお,請求人は,補正の根拠に関して,「段落[0053]は,アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることをサポートしています。なぜなら,この開示は,ファイル属性は第1通信セッション(アウトオブバンドの通信セッション)中に取得/受信され,ファイル属性が第1通信セッション中に正確に取得/受信された後に,ファイルコンテンツは第2通信セッション(インバンドの通信セッション)中に取得/受信されることを教示しています。段落[0051]は,「インバンド方式」は,同一の伝送セッション内での情報の移送を意味し,「アウトオブバンド方式」は,多様な伝送セッションを介した情報の移送を意味するものと定義しています。」と述べているが,第2の通信セッション86がインバンド方式であることは記載されておらず,【0051】,【0052】の記載も考慮すれば,第1の通信セッション81と第2の通信セッション86とでアウトバンド方式の伝送をなしていることは明らかである。更に,【0053】には,その文末にインバンド方式の問題を回避するとの記載もあることから,インバンド方式に替えてアウトバンド方式を用いることが述べられていると解するのが自然であり,アウトオブバンドの通信セッションおよびインバンドの通信セッションの両方が使用されることが記載されているとはいえない。したがって,請求人の主張は採用できない。よって,請求項1,3,6,8,9,10,14,16,19に記載された発明は,発明の詳細な説明に記載されたものではない。 3 小括したがって,この出願は,特許請求の範囲の記載が,特許法第36条第6項第1号に規定する要件を満たしていない。第6 特許法第29条第2項について 1 本願発明特許請求の範囲の請求項1は次のとおりのものである。「 (a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって, (a2)アウトオブバンドの通信セッションにおいて,前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を受信することと, (a3)前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に受信した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである, (a4)ここにおいて,前記複数のファイル属性は,前記少なくとも1つのファイルよりも先に受信され,また前記処理することは,前記インバンドの通信セッションにおいて前記複数のファイル属性を受信することなく,前記少なくとも1つのファイルよりも先に受信された前記複数のファイル属性に基づいて,前記少なくとも1つのファイルを再構築することを含む, (a5)前記通信システムはインターネットプロトコル(IP)をサポートし,前記方法はさらに, (a6)前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, (a7)前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して受信することと,を備える, 方法。」(上記「第2 特許請求の範囲の記載」の再掲) ここで,「アウトオブバンドの通信セッション」及び「インバンドの通信セッション」なる用語は,上記「第4 特許法第36条第6項第2号について」の項で述べたとおり不明確であるが,請求人は,【0053】の記載に基づき,図5の第1通信セッション81が「アウトオブバンドの通信セッション」であり,第2通信セッション86が「インバンドの通信セッション」であると主張しているから,「アウトオブバンドの通信セッション」は図5の第1通信セッション81を,「インバンドの通信セッション」は図5の第2通信セッション86を,それぞれ意味するものと解釈することとする。したがって,上記請求項1の記載のうち,「アウトオブバンドの通信セッション」,「インバンドの通信セッション」の記載は上記のとおり解釈するものとして,本願発明は,上記請求項1の記載のとおりのものと認める。 2 引用発明 [引用発明] 当審による拒絶の理由に引用された特開2003-304511号公報(以下,「引用例」という。)には,図面とともに以下の事項が記載されている。 (1)「【0001】【発明の属する技術分野】本発明は,映像(ビデオ)情報,音声(オーディオ)情報等の放送メディアを放送するための放送通信システム,放送通信方法,及び,これらに用いて好適な通信端末,サーバ装置,中継装置及びプログラムに関する。」 (2)「【0027】【課題を解決するための手段】本発明の第1の特徴は,受信した放送メディアを再生する通信端末であって,前記放送メディアの再生に先立って,該放送メディアの再生方法を示す再生情報を取得し,少なくとも一つの前記放送メディアを指定する放送通知情報を受信した場合,前記再生情報に基づいて,指定された該放送メディアを再生することを要旨とする。」 (3)「【0084】(第1の実施形態)本発明の第1の実施形態について図1から図11を用いて説明する。本実施形態では,インターネットプロトコルである「RTP/UDP/IP」パケット(放送メディアパケット)の形式で,音声情報や映像情報等を含む放送メディアを伝送する放送通信システム1について説明する。【0085】本実施形態では,受信端末20は,音声情報や映像情報等の放送メディアの再生に先立って,該放送メディアの再生方法を示す再生情報を取得し,放送通知情報(SAPメッセージ)を受信した場合に,前記再生情報に基づいて放送メディアを再生する。ここで,放送通知情報(SAPメッセージ)は,少なくとも一つの放送メディアを指定するものである。【0086】コンテンツ送信サーバ10は,受信端末20による放送メディアの再生に先立って,放送通知情報(SAPメッセージ)によって指定されている放送メディアの再生方法を示す再生情報を送信する。【0087】コンテンツ送信サーバ10は,放送通知情報(SAPメッセージ)によって指定される放送メディア(AMRを含むRTPパケットやMPEG4を含むRTPパケット)を送信する前に,放送メディアの再生方法を示す再生情報を送信する。【0088】例えば,コンテンツ送信サーバ10は,放送通知情報(SAPメッセージ)を周期的に繰り返し送信して,放送通知情報(SAPメッセージ)を送信した直後に,カルーセルデータによって再生情報を送信することができる。ここで,カルーセルデータとは,同じデータを繰り返し送信する方式(データカルーセル方式)によって伝送されるデータのことをいう。【0089】ここで,再生情報は,SAPメッセージの「ｐaｙlｏad(ペイロード)」内に記述されている「SDP情報(図4参照)」や,データカルーセル方式によって送信される「SMIL(Sｙnchｒｏniｚed MｕlｔimediaInｔegｒaｔiｏn Langｕage)(図8参照)」等に含まれている。【0090】また,再生情報は,放送メディアの再生の際に用いられる「レイアウト情報」や,放送メディアの再生の際に用いられる「タイミング情報」を含むことができる。【0091】図2は,本実施形態における放送通信システム1におけるコンテンツ送信サーバ10と受信端末20との間のシーケンス図である。【0092】図2に示すように,ステップ201において,コンテンツ送信サーバ10が,放送通知情報である「SAPメッセージ」を,受信端末20に送信する。SAPメッセージの内容については,後述の図3及び図4において詳細に説明する。ここで,SAPメッセージが通知される「IPアドレス」及び「ポート番号」は,受信端末20に既知のものとする。【0093】ステップ202において,コンテンツ送信サーバ10が,「SMIL」を含むカルーセルデータを受信端末20に送信する。また,ステップ203において,コンテンツ送信サーバ10が,HTML形式のテキスト情報やアンカー情報を含むカルーセルデータを受信端末20に送信する。【0094】例えば,JPEG等の静止画像情報やXML形式の構造化データは,UDP上でデータを繰り返し送るデータカルーセル方式にて伝送される(図35参照)。データカルーセル方式については,後述の図5乃至図7の説明において詳細に説明する。【0095】ステップ204乃至207において,コンテンツ送信サーバ10が,音声情報(AMR)や映像情報(MPEG-4)を含むRTPパケット(放送メディアパケット)を受信端末20に送信する。【0096】ここで,SAPメッセージ及びカルーセルデータは,UDP/IPパケットによって伝送され,音声情報及び映像情報は,UDP/IP上のRTPパケットによって伝送される(図35参照)。【0097】そして,コンテンツ送信サーバ10は,SAPメッセージを,所定間隔をもって周期的に繰り返し伝送する。受信端末20は,SAPメッセージを受信することにより,放送メディアの再生を開始するので,SAPメッセージは,できうる限り短い周期にて伝送することが望ましい。【0098】次に,図3及び図4を用いて,SAPメッセージについて説明する。図3は,SAPメッセージのフォーマットを示すものである。【0099】図3において,「V」は,バージョン情報を示す。「A」は,アドレスタイプを示し,A=0の時,IPｖ4であり,A=1の時,IPｖ6である。「R」は,「Reｓeｒｖed」である。【0100】「T」は,メッセージタイプを示し,T=0の時,放送開始を示す放送通知情報であることを意味し,T=1の時,放送終了を示す放送通知情報であることを意味する。【0101】「E」は,「Encｒｙｐｔiｏn biｔ」である。「C」は,「Cｏmｐｒeｓｓiｏn biｔ」である。「aｕｔh len」は,「ｏｐｔiｏnal aｕｔhenｔicaｔiｏn daｔa」のサイズを示す。【0102】「mｓg id haｓh」は,「ｏｒiginaｔing ｓｏｕｒce」に記述されたIPアドレスで示される発信元(コンテンツ送信サーバ10等)によって送信されるSAPメッセージを一意に特定するメッセージIDである。【0103】「ｏｒiginaｔing ｓｏｕｒce」は,SAPメッセージの発信元のIPアドレスである。【0104】ここで,「mｓg id haｓh」と「ｏｒiginaｔing ｓｏｕｒce」との組み合わせによって,SAPメッセージを一意に特定することができる。【0105】「ｏｐｔiｏnal ｐaｙlｏad ｔｙｐe」は,「ｐaｙlｏad」のデータタイプを示す。「ｐaｙlｏad」については,図4において詳細に説明する。【0106】図4は,本実施形態におけるSAPメッセージ内の「ｐaｙlｏad」に記述された「SDP情報」の例を示す。【0107】「ｖ=0」は,「ｐaｙlｏad」のバージョンを示すものであり,「ｐaｙlｏad」を記述するルールを規定するための情報を示している。【0108】「ｏ=」は,発信元情報であり,発信元のIPアドレス情報(126.16.64.4)を含む。「ｓ=」は,放送メディアのセッション名である。「c=」は,放送メディアを送信しているマルチキャストアドレス(送信先のIPアドレス情報)である。「ｔ=」は,放送メディアの有効期間を示すものである。【0109】「m=」は,当該SAPメッセージによって指定されている放送メディアを示す情報であり,図4に示すSAPメッセージは,放送メディアとして,1つの音声情報と1つの映像情報と1つのカルーセルデータを指定している。【0110】すなわち,第1の放送メディアを指定する「m=aｕdiｏ 3456 RTP/AVP 0」という記述は,音声情報を「3456」で特定されるポート番号にて,RTPパケットによって伝送することを示している。【0111】また,第2の放送メディアを指定する「m=ｖideｏ 2232 RTP/AVP 98」という記述は,映像情報を「2232」で特定されるポート番号にて,RTPパケットによって伝送することを示している。【0112】また,「m=aｐｐlicaｔiｏn 32416 ｕdｐ dc」という記述は,繰り返し送信するカルーセルデータを,UDPパケットを用いて伝送することを示している。」 (4)「【0145】第2に,受信端末20は,SAPメッセージを参照することにより,音声情報や映像情報やカルーセルデータ等の放送メディアが送信されている「IPアドレス」や,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等の再生情報を取得する。【0146】例えば,図4に示すSAPメッセージを受信した受信端末20は,「c=INIP4 224.2.17.12/127」という記述により,各放送メディアが送信されている「IPアドレス(マルチキャストアドレス)」を取得する。【0147】また,受信端末20は,第1の放送メディアを指定する「m=aｕdiｏ 3456 RTP/AVP 0」という記述により,音声情報が,ポート番号「3456」によってRTPパケットを用いて送信されると解析する。【0148】また,受信端末20は,第2の放送メディアを指定する「m=ｖideｏ 2232 RTP/AVP 98」という記述により,映像情報が,ポート番号「2232」によってRTPパケットを用いて送信されると解析する。【0149】さらに,受信端末20は,「m=aｐｐlicaｔiｏn 32416 ｕdｐ dc」という記述より,ポート番号「32416」によって,UDPパケット上で,カルーセルデータが送信されると解析する。【0150】第3に,上述の放送メディアについての解析を行った受信端末20は,各放送メディアの受信処理の準備を行い,放送メディアが放送されるのを待つ。」 (5)「【0266】図27の例では,コンテンツ送信サーバ10が,SAPメッセージ用チャネルを介してSAPメッセージ(SAP1,SAP2)を伝送し,番組1用チャネルを介して第1の放送メディア(RTP1-a,RTP1-b)を伝送し,番組2用チャネルを介して第2の放送メディア(RTP2-a,RTP2-b)を伝送している。すなわち,図27の例では,コンテンツ送信サーバ10は,番組毎に異なる無線チャネルを使用している。【0267】この場合,コンテンツ送信サーバ10は,SAPメッセージにおいて放送メディア(番組)のIPアドレス(論理チャネル識別情報)だけ指定したのでは不十分であり,どの無線チャネルにどの放送メディアが流れているかについても特定する必要がある。そこで,コンテンツ送信サーバ10は,SAPメッセージ内のSDP情報の中で,無線チャネルを特定する情報(物理チャネル識別情報)を通知する。【0268】例えば,コンテンツ送信サーバ10は,図28に示すように,SDPの「cフィールド」の中で「c=Channel ABCDE」というように無線チャネルを特定する情報を通知する。無線チャネルを特定する情報としては,CDMA通信方式のチャネライゼーションコードや周波数値等が考えられる。【0269】受信端末20は,この無線チャネルを特定する情報に基づいて,放送メディアの流れている無線チャネルを特定し,当該放送メディアを視聴することが可能となる。【0270】すなわち,本実施形態では,放送通知情報(SAPメッセージ)内のSDP情報に,放送メディアが送信される物理チャネル識別情報(CDMA通信方式のチャネライゼーションコードや周波数値等の無線チャネルを特定する情報)と論理チャネル識別情報(放送メディアのIPアドレス)との対応情報とが含まれている。」上記引用例の記載及び図面(特に図1-4,図27,図28,図35)並びにこの分野における技術常識を考慮すると, ア上記(1),(2),(3)の【0087】及び【0095】,並びに上記(4)の【0150】の記載によれば,引用例には,「放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法」が記載されていると認められる。イ上記(3)の【0088】,上記(4)の【0145】,及び上記(5)の【0266】の記載によれば,受信端末がコンテンツ送信サーバから受信する再生情報には,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等が含まれ,前記再生情報は,SAPメッセージ用チャネルを介して送信されるSAPメッセージに含まれていると認められる。したがって,引用例には,「SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信すること」が記載されていると認められる。ウ上記(4)の【0150】の記載によれば,受信したSAPメッセージを参照することにより再生情報を取得して放送メディアについての解析を行った受信端末は,各放送メディアの受信処理の準備を行い,放送メディアが放送されるのを待つ,換言すれば,受信端末は,再生情報を受信して放送メディアについての解析を行った後に,前記再生情報とは別に,放送メディアを受信するものと認められる。そして,取得した再生情報に基づいて放送メディアについての解析を行う以上,再生情報を正確に受信した後に解析を始めることは明らかであるから,受信端末は,再生情報を正確に受信した後に,放送メディアについての解析を始め,当該解析を行った後に前記放送メディアを受信する,すなわち再生情報を正確に受信した後に,放送メディアを受信するものと認められる。また,上記(5)の【0266】及び図27の記載によれば,放送メディアは,番組用チャネルにおいて受信するものと認められ,当該番組用チャネルは,SAPメッセージ用チャネルとは異なるチャネルであると認められる。したがって,引用例には,「前記SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を正確に受信した後に,番組用チャネルにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報とは別に,前記放送メディアを受信することとを備え,ここにおいて,前記SAPメッセージ用チャネルと前記番組用チャネルは,異なるチャネルである」ことが記載されていると認められる。エ上記ウのとおり,前記SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信した後に,番組用チャネルにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報とは別に,前記放送メディアを受信するのであるから,「ポート番号」や「RTPペイロードタイプ」等を含む再生情報は,放送メディアよりも先に受信されると認められる。また,上記(5)の【0266】及び図27の記載によれば,SAPメッセージ用チャネルではSAPメッセージのみが伝送され,番組用チャネルには放送メディアのみが伝送されSAPメッセージは伝送されていないから,受信端末における放送メディアの再生が,番組用チャネルにおいて「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信することなく,前記放送メディアよりも先に受信された「ポート番号」や「RTPペイロードタイプ」等を含む再生情報に基づいて行われることは明らかである。したがって,引用例には,「ここにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報は,前記放送メディアよりも先に受信され,また前記再生することは,前記番組用チャネルにおいて「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信することなく,前記放送メディアよりも先に受信された「ポート番号」や「RTPペイロードタイプ」等を含む再生情報に基づいて行われることを含む」ことが記載されていると認められる。オ上記(3)の【0084】の記載によれば,引用例には,「前記放送通信システムは,インターネットプロトコル(IP)をサポート」することが記載されていると認められる。カ上記(3)の【0084】,【0092】,【0096】,【0109】-【0111】,及び上記(4)の【0145】の記載によれば,「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を含むSAPメッセージは,受信端末に既知のポート番号を介してUDP/IPパケットによって伝送され,音声情報や映像情報等の放送メディアは,「3456」及び「2232」で特定されるポート番号を介して,UDP/IP上のRTPパケットによって伝送されて,受信端末が受信すると認められる。したがって,引用例には,「前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を,受信端末に既知のポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, 前記放送メディアを,「3456」及び「2232」で特定されるポート番号を介して前記IPの前記UDPを介して受信すること」が記載されていると認められる。したがって,引用例には以下の発明(以下,「引用発明」という。)が記載されているものと認める。「放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法であって, SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信することと, 前記SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を正確に受信した後に,番組用チャネルにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報とは別に,前記放送メディアを受信することとを備え,ここにおいて,前記SAPメッセージ用チャネルと前記番組用チャネルは,異なるチャネルである, ここにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報は,前記放送メディアよりも先に受信され,また前記再生することは,前記番組用チャネルにおいて「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信することなく,前記放送メディアよりも先に受信された「ポート番号」や「RTPペイロードタイプ」等を含む再生情報に基づいて行われることを含む, 前記放送通信システムは,インターネットプロトコル(IP)をサポートし,前記放送通信方法は, 前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を,受信端末に既知のポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, 前記放送メディアを,「3456」及び「2232」で特定されるポート番号を介して前記IPの前記UDPを介して受信することと,を備える放送通信方法。」 3 対比本願発明と引用発明とを対比すると, (1)引用発明の「放送通信システム」は,明らかに「通信システム」に含まれる。そして,引用発明の「放送」が「ブロードキャスト」を意味することは明らかであるから,本願発明の「ブロードキャストのファイル」,「ブロードキャストのファイルの少なくとも1つのファイル」及び「ブロードキャストのファイルの少なくとも1つのファイルのコンテンツ」と引用発明の「放送メディア」とは,「ファイル」であるか否かは別として,「ブロードキャストのコンテンツ」である点で共通する。また,本願発明の「ブロードキャストのファイルをダウンロードする」ことは,発明の詳細な説明の【0009】,【0010】,【0014】の記載によれば,ブロードキャストされたコンテンツを受信すること含むと認められる。したがって,本願発明の「(a1)通信システム内でブロードキャストのファイルをダウンロードする方法であって」と,引用発明の「放送通信システム内でコンテンツ送信サーバが放送する放送メディアを受信する放送通信方法であって」とは,「ファイル」であるか否かは別として,「通信システム内でブロードキャストのコンテンツをダウンロードする方法であって」の点で共通している。 (2)本願発明の「少なくとも1つのファイルのコンテンツを処理」することと引用発明の「放送メディアを再生する」こととは,その対象が「ファイル」であるか否か,及びその内容に「少なくとも1つのファイルを再構築することを含む」か否かは別として,「ブロードキャストのコンテンツを処理する」ことである点で共通する。そして,本願発明の「複数のファイル属性」と引用発明の「「ポート番号」や「RTPペイロードタイプ」等を含む再生情報」とは,コンテンツの処理に用いるものである点で共通する。また,引用発明において,「ポート番号」や「RTPペイロードタイプ」等を含む再生情報に基づいて放送メディアの再生が行われる以上,「ポート番号」や「RTPペイロードタイプ」等を含む再生情報は,コンテンツを処理するために受信しているといえる。したがって,本願発明の「前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性」と,引用発明の「各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報」とは,「コンテンツを処理するために必要な情報」である点で共通している。以上のことから,本願発明の「(a2)アウトオブバンドの通信セッションにおいて,前記ブロードキャストの少なくとも1つのファイルのコンテンツを処理するために複数のファイル属性を受信することと」と,引用発明の「SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信することと」は,下記の相違点1?3は別して,「前記ブロードキャストのコンテンツを処理するために必要な情報を受信すること」の点で共通している。 (3)上記(2)のとおりであるから,本願発明の「(a3)前記アウトオブバンドの通信セッションにおいて,前記複数のファイル属性を正確に受信した後に,インバンドの通信セッションにおいて,前記複数のファイル属性とは別に,前記ブロードキャストの前記少なくとも1つのファイルを受信することと,を備え,ここにおいて,前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである」と,引用発明の「前記SAPメッセージ用チャネルにおいて,各放送メディアを再生するために必要な「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を正確に受信した後に,番組用チャネルにおいて,前記「ポート番号」や「RTPペイロードタイプ」等を含む再生情報とは別に,前記放送メディアを受信することとを備え,ここにおいて,前記SAPメッセージ用チャネルと前記番組用チャネルは,異なるチャネルである,」とは,下記の相違点1?3は別して,「前記コンテンツを処理するために必要な情報を正確に受信した後に,前記コンテンツを処理するために必要な情報とは別に,前記ブロードキャストのコンテンツを受信すること」の点で共通している。 (4)上記(2),(3)のとおりであるから,本願発明の「(a4)ここにおいて,・・・前記少なくとも1つのファイルを再構築することを含む」と,引用発明の「ここにおいて,・・・前記放送メディアよりも先に受信された「ポート番号」や「RTPペイロードタイプ」等を含む再生情報に基づいて行われることを含む」とは,下記の相違点1?3は別して,「ここにおいて,前記コンテンツを処理するために必要な情報は,前記コンテンツよりも先に受信され,また前記処理することは,前記コンテンツを処理するために必要な情報をコンテンツと同時に受信することなく,前記コンテンツよりも先に受信された前記複数のファイル属性に基づいて行われることを含む」点で共通している。 (5)本願発明と引用発明とは,「前記通信システムはインターネットプロトコル(IP)をサポートし」ている点で差異は無い。また,引用発明において,受信端末に既知のポート番号を「第1ポート番号」と称し,「3456」及び「2232」で特定されるポート番号を「第2ポート番号」と称することは任意である。したがって,本願発明と引用発明とは,「前記複数のファイル属性を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと,前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して受信することと,を備える」点で差異は無い。したがって,本願発明と引用発明とは,両者は,以下の点で一致し,また,相違している。 (一致点) 「通信システム内でブロードキャストのコンテンツをダウンロードする方法であって, 前記ブロードキャストのコンテンツを処理するために必要な情報を受信することと, 前記コンテンツを処理するために必要な情報を正確に受信した後に,前記コンテンツを処理するために必要な情報とは別に,前記ブロードキャストのコンテンツを受信することと,を備え, ここにおいて,前記コンテンツを処理するために必要な情報は,前記コンテンツよりも先に受信され,また前記処理することは,前記コンテンツを処理するために必要な情報をコンテンツと同時に受信することなく,前記コンテンツよりも先に受信された前記コンテンツを処理するために必要な情報に基づいて行われることを含む, 前記通信システムはインターネットプロトコル(IP)をサポートし,前記方法はさらに, 前記コンテンツを処理するために必要な情報を,第1ポート番号を介して前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと, 前記少なくとも1つのファイルを,第2ポート番号を介して前記IPの前記UDPを通して受信することと,を備える, 方法。」 (相違点1) 一致点の「ブロードキャストのコンテンツ」に関し,本願発明は,「ブロードキャストのファイル」,「ブロードキャストの少なくとも1つのファイルのコンテンツ」,及び「ブロードキャストの少なくとも1つのファイル」を受信及び処理するのに対し,引用発明はブロードキャストのコンテンツを少なくとも1つのファイルとして受信及び処理することが明らかでない点。 (相違点2) 一致点の「コンテンツを処理するために必要な情報」及び「コンテンツ」の受信に関し,本願発明は,それぞれ「アウトオブバンドの通信セッション」及び「インバンドの通信セッション」において受信し,かつ「前記インバンドの通信セッションおよび前記アウトオブバンドの通信セッションは,異なる伝送セッションである」のに対し,引用発明は,それぞれ「SAPメッセージ用チャネル」及び「番組用チャネル」において受信し,「前記SAPメッセージ用チャネルと前記番組用チャネルは,異なるチャネルである」ものの,「通信セッション」については明らかではない点。 (相違点3) 一致点の「コンテンツを処理するために必要な情報に基づいてブロードキャストのコンテンツを処理する」ことに関し,本願発明は,処理の内容に「複数のファイル属性に基づいて少なくとも1つのファイルを再構築する」ことを含むのに対し,引用発明は当該構成が明らかでない点。 4 検討上記各相違点について,先に上記相違点1及び3について検討し,その後相違点2について検討する。 (相違点1及び3について) 端末がサーバからコンテンツをダウンロードして再生する通信システムにおいて,前記端末及び前記サーバが,前記コンテンツを少なくとも1つのファイルとして扱うこと,並びにインターネットプロトコル(IP)をサポートする通信システムにおいてファイルを伝送する際に,送信側で当該ファイルを複数のパケットに分割して送信し,受信側で前記複数のパケットとして前記ファイルを受信して元のコンテンツを復元するために再構築する処理を行うことは,いずれも当業者により一般的に行われていることにすぎない。また,その場合,ファイルを「再構築する処理」をするために必要な情報を,「ファイル属性」と称することは任意である。そうすると,ブロードキャストのコンテンツをブロードキャストの少なくとも1つのファイルとして受信して,複数のファイル属性に基づいて前記少なくとも1つのファイルを再構築すること,すなわち,相違点1及び3は,格別困難なことではなく,当業者が容易になし得ることである。 (相違点2について) 上記1で述べたとおり,本願発明に記載された「アウトオブバンドの通信セッション」,「インバンドの通信セッション」は,それぞれ図5の第1通信セッション81,図5の第2通信セッション86を意味し,それぞれ「複数のファイル属性」,「ブロードキャストの少なくとも1つのファイル」のみを伝送するものである。一方,引用発明において,「ポート番号」や「RTPペイロードタイプ」等を含む再生情報を受信する「SAPメッセージ用チャネル」と,放送メディアを受信する「番組用チャネル」は,異なるチャネルであって,上記2のエで述べたとおり,SAPメッセージ用チャネルではSAPメッセージのみが伝送され,番組用チャネルには放送メディアのみが伝送されている。ここで,インターネットプロトコル(IP)をサポートする通信システムにおいて,通信セッション単位で通信を行うことは,当業者における技術常識であり,異なるチャネルに異なる通信セッションを対応付けることは格別困難なことではなく,当業者が容易になし得ることに過ぎない。そして,引用発明において,「SAPメッセージ用チャネル」と「番組用チャネル」とをそれぞれ別の通信セッションとして伝送した場合,「SAPメッセージ用チャネルの通信セッション」ではSAPメッセージのみが伝送され,「番組用チャネルの通信セッション」では放送メディアのみが伝送されることとなるから,それぞれ本願の図5の第1通信セッション81,第2通信セッション86に対応することは明らかである。したがって,相違点2は格別困難なことではなく,当業者が容易になし得ることにすぎない。そして,本願発明の作用効果も,引用発明及び周知事項に基づいて当業者が予測し得る範囲のものであり,格別なものではない。 5 小括以上のとおり,本願発明は,引用発明に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許を受けることができない。第7 むすび以上のとおり,本願は,特許請求の範囲の記載が,特許法第36条第6項第1号及び第2号に規定する要件を満たしていないから,特許を受けることができない。また,本願発明は,特許法第29条第2項の規定により特許を受けることができない。よって,結論のとおり審決する。
審理終結日	2015-06-04
結審通知日	2015-06-09
審決日	2015-06-23
出願番号	特願2010-235371(P2010-235371)
審決分類	P 1 8・ 121- WZ (H04L) P 1 8・ 537- WZ (H04L)
最終処分	不成立
前審関与審査官	永井啓司
特許庁審判長	菅原道晴
特許庁審判官	▲高▼橋真之大塚良平
発明の名称	マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置
代理人	井関守三
代理人	蔵田昌俊
代理人	野河信久
代理人	堀内美保子
代理人	砂川克
代理人	峰隆司
代理人	井上正
代理人	河野直樹
代理人	岡田貴志
代理人	福原淑弘
代理人	佐藤立志

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ