【事件の表示】
　特願２０１２−５３８７６８「データ提供方法及びその装置、並びにデータ受信方法及びその装置」拒絶査定不服審判事件〔平成２３年　５月１９日国際公開、ＷＯ２０１１／０５９２８６、平成２５年　３月２８日国内公表、特表２０１３−５１１１９８、請求項の数（１５）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　経緯
１　経緯
　本件出願は、２０１０年（平成２２年）１１月１５日（パリ条約による優先権主張外国庁受理２００９年１１月１３日、米国、２０１０年３月５日、米国、２０１０年１０月２２日、韓国）を国際出願日とする出願であって、平成２６年７月２５日付けで拒絶理由の通知がなされ、これに対し、平成２６年１１月５日付けで手続補正がなされたが、平成２７年４月２２日付け（発送日同年４月２７日）で拒絶査定がなされた。
　本件は、上記拒絶査定を不服として平成２７年８月２７日付けで請求された拒絶査定不服審判であり、請求と同時に手続補正がなされた。
　　
２　査定の概要
　原査定の理由は、概略、次のとおりである。
　　
　この出願の請求項１〜１５に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　
　　　　　　　　　　　　　　　　　記
引用文献１：R. Pantos Ed.，HTTP Live Streaming draft-pantos-http-live-streaming-02，Internet-Drafts，IETF，２００９年１０月　５日，［平成26年7月25日検索］，インターネット＜URL: ftp://tsubaki.st.ryukoku.ac.jp/pub/internet/internet-drafts/draft-pantos-http-live-streaming-02.txt＞
引用文献２：国際公開第２００８／０６２９７９号（周知技術を示す文献）
引用文献３：国際公開第２００８／１３０１９１号（周知技術を示す文献）
引用文献４：特開２００９−１３４７００号公報（周知技術を示す文献）
　　
第２　補正却下の決定
　平成２７年８月２７日付けの手続補正について次のとおり決定する。
 　 
［補正却下の決定の結論］
　平成２７年８月２７日付けの手続補正を却下する。
　　
［理由］
１　補正の内容
　平成２７年８月２７日付けの手続補正（以下「本件補正」という。）は、特許請求の範囲についてする補正を含む補正である。そのうち、特許請求の範囲についてする補正の詳細は以下のとおりである。
　　
　特許請求の範囲
「　【請求項１】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階と、
　前記第２付加情報を受信する段階と、を含み、
　前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とするデータ受信方法。
　　【請求項２】
　前記方法は、
　前記第１付加情報に基づいて、前記複数個の第１メディアデータのうち、少なくとも１つの第１メディアデータを、ストリーミング方式で受信する段階と、
　前記第２付加情報に基づいて、前記コンテンツの前記第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータのうち少なくとも一つの第２メディアデータを、ストリーミング方式で受信する段階と、をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項３】
　前記第２付加情報は、
　前記第１付加情報と同じ属性構造を有することを特徴とする請求項１に記載のデータ受信方法。
　　【請求項４】
　前記第１付加情報は、
　前記第２付加情報に係わる位置情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項５】
　前記第２付加情報は、
　前記第１付加情報と異なる属性構造を有することを特徴とする請求項４に記載のデータ受信方法。
　　【請求項６】
　前記第１区間及び前記第２区間は、
　前記第１区間及び前記第２区間で提供されるプログラムによって区分されることを特徴とする請求項１に記載のデータ受信方法。
　　【請求項７】
　前記第１区間及び前記第２区間は、
　前記コンテンツを所定の時間単位に分割して生成されたことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項８】
　前記第１付加情報は、
　前記第１区間が始まる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項９】
　前記第１付加情報は、
　前記第１区間が終わる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項１０】
　前記第１付加情報は、
　前記第１区間で提供されるプログラムの識別情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項１１】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する段階と、
　前記第１付加情報をクライアントに伝送する段階と、
　前記クライアントから、前記第１付加情報に係わる更新要請が受信されれば、前記第２付加情報を前記クライアントに伝送する段階と、を含み、
　前記第１付加情報は、前記第１付加情報が更新可能な時点を示す更新時点情報を含み、
　前記複数個の第１メディアデータ及び前記複数個の第２メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とするデータ提供方法。
　　【請求項１２】
　前記複数個の第１メディアデータのうち、前記クライアントが要請する少なくとも１つの第１メディアデータをストリーミング方式で伝送する段階と、
　前記複数個のメディアデータのうち、前記クライアントが要請する少なくとも１つの第２メディアデータをストリーミング方式で伝送する段階と、をさらに含むことを特徴とする請求項１１に記載のデータ提供方法。
　　【請求項１３】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する受信部と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する獲得部と、を含み、
　前記受信部は、前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報をさらに受信し、
　前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とするデータ受信装置。
　　【請求項１４】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する生成部と、
　前記第１付加情報をクライアントに伝送する伝送部と、
　前記クライアントから、前記第１付加情報に係わる更新要請を受信する要請受信部と、
を含み、
　前記伝送部は、前記更新要請が受信されれば、前記第２付加情報を前記クライアントにさらに伝送し、
　前記第１付加情報は、前記第１付加情報が更新可能な時点を示す更新時点情報を含み、
　前記複数個の第１メディアデータ及び前記複数個の第２メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とするデータ提供装置。
　　【請求項１５】
　データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
　前記方法は、コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新される時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階と、
　前記第２付加情報を受信する段階と、を含み、
　前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とする記録媒体。」
　　
を、特許請求の範囲
　　
「　【請求項１】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、
前記コンテンツの第２区間についての
　
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新される
　　【請求項２】
　前記方法は、
　前記第１付加情報に基づいて、前記複数個の第１メディアデータのうち、
前記
　前記第２付加情報に基づいて、前記コンテンツの前記第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータのうち少なくとも
１
　　【請求項３】
　前記第２付加情報は、
　前記第１付加情報と同じ属性構造を有することを特徴とする請求項１に記載のデータ受信方法。
　　【請求項４】
　前記第１付加情報は、
　前記第２付加情報に係わる位置情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項５】
　前記第２付加情報は、
　前記第１付加情報と異なる属性構造を有することを特徴とする請求項４に記載のデータ受信方法。
　　【請求項６】
　前記第１区間及び前記第２区間は、
　前記第１区間及び前記第２区間で提供されるプログラムによって区分されることを特徴とする請求項１に記載のデータ受信方法。
　　【請求項７】
　前記第１区間及び前記第２区間は、
　前記コンテンツを所定の時間単位に分割して生成されたことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項８】
　前記第１付加情報は、
　前記第１区間が始まる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項９】
　前記第１付加情報は、
　前記第１区間が終わる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項１０】
　前記第１付加情報は、
　前記第１区間で提供されるプログラムの識別情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
　　【請求項１１】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する段階と、
　前記第１付加情報をクライアントに伝送する段階と、
　
前記第１付加情報に含まれた該第１付加情報が更新可能な時点を示す更新時点情報に基づいて、
　前記第１付加情報は、
該第１付加情報に基づいて伝送される少なくとも１つの第１メディアデータが前記クライアントで処理される間に更新される
　　【請求項１２】
　前記複数個の第１メディアデータのうち、
前記
　前記複数個の
第２
　　【請求項１３】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する受信部と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する獲得部と、を含み、
　前記受信部は、前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報をさらに受信し、
　
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新される
　　【請求項１４】
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する生成部と、
　前記第１付加情報をクライアントに伝送する伝送部と、
　前記クライアントから、前記第１付加情報に係わる更新要請を受信する要請受信部と、を含み、
　前記伝送部は、前記更新要請が受信されれば、
前記第１付加情報に含まれた前記第１付加情報が更新可能な時点を示す更新時点情報に基づいて、
　前記第１付加情報は、
該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新される
　　【請求項１５】
　データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
　前記方法は、コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新される時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、
前記コンテンツの第２区間に関する
　
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新される
　　
に補正するものである。
 　 
２　補正の適合性 
　特許法第１７条の２第５項に規定する要件を検討する。　　　
　請求項１に係る補正は、
「コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階と、
　前記第２付加情報を受信する段階と、を含み、
　前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割されることを特徴とするデータ受信方法。」を
「コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
　前記更新時点情報に基づいて、
前記コンテンツの第２区間についての
　
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新される
にする補正である。
　この補正は、補正前の「前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階」、「前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割されること」という事項を削除することを含むから、請求項１に係る補正が特許請求の範囲を減縮することを目的にしたものとは認められない。
　また、請求項１に係る補正は、請求項の削除、誤記の訂正、明りょうでない記載の釈明を目的としたものとも認められない。
　したがって、本件補正における請求項１に係る補正は、特許法第１７条の２第５項に規定する要件を満たしていない。
　よって、本件補正は、請求項１に係る補正を含むから、本件補正は、特許法第１７条の２第５項に規定する要件を満たしていない。
　　
３　まとめ 
　以上のとおり、本件補正は、特許法第１７条の２第５項に規定する要件を満たしていないので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、補正却下の決定の結論のとおり決定する。
 　 
第３　本願発明について
１　本願発明
　平成２７年８月２７日付けの手続補正は、上記のとおり却下されたので、本願の請求項１〜１５に係る発明は、平成２６年１１月５日付け手続補正により補正された明細書、特許請求の範囲及び図面の記載からみて、その特許請求の範囲の請求項１〜１５に記載した事項により特定されるとおりのものであるところ、請求項１に係る発明（以下「本願発明」という。）は次のとおりである。
　　
（本願発明）
（Ａ）コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
（Ｂ）前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
（Ｃ）前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階と、
（Ｄ）前記第２付加情報を受信する段階と、を含み、
（Ｅ）前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割される
（Ｆ）ことを特徴とするデータ受信方法。
　　
（（Ａ）〜（Ｆ）は、当審で付与した。以下各構成要件を「構成要件Ａ」等という。）
　　
２　引用文献１の記載
　原査定の拒絶の理由に引用された
「R. Pantos Ed.，HTTP Live Streaming draft-pantos-http-live-streaming-02，Internet-Drafts，IETF，２００９年１０月　５日，［平成26年7月25日検索］，インターネット＜URL: ftp://tsubaki.st.ryukoku.ac.jp/pub/internet/internet-drafts/draft-pantos-http-live-streaming-02.txt＞」には、次の揚げる事項が記載されている。
　　
（１）「2.  Summary
　　
A multimedia presentation is specified by a URI [RFC3986] to a Playlist file, which is an ordered list of additional URIs.  
Each URI in the Playlist file refers to a media file which is a segment of a single contiguous stream.
　　
To play the stream, the client first obtains the Playlist file and then obtains and plays each media file in the Playlist.
It reloads the Playlist file
to discover additional segments
［訳：マルチメディアプレゼンテーションは、追加のURIの順序付きリストであるプレイリストファイルへのURI[RFC3986]で指定されています。
プレイリストファイル内の各URIは、単一の連続ストリームのセグメントであるメディアファイルを参照します
　　
ストリームを再生するには、クライアントは、最初にプレイリストファイルを取得し、そして、プレイリスト内の各メディアファイルを取得し、再生します
追加のセグメントを発見するために、
プレイリストファイルをリロードします
　　
（２）「4.  Media files
　　
Each media file URI in a Playlist file MUST identify a media file which is a segment of the overall presentation.
  
Transport Stream files MUST contain a single MPEG-2 Program.  There SHOULD be a Program Association Table and a Program Map Table at the start of each file.  A file that contains video SHOULD have at least one key frame and enough information to completely initialize a video  decoder.
　　
Clients SHOULD be prepared to handle multiple tracks of a particular type (e.g. audio or video) by choosing a reasonable subset.  Clients MUST ignore private streams inside Transport Streams that they do not recognize.
　　
The encoding parameters for samples within a stream inside a media file and between corresponding streams across multiple media files SHOULD remain consistent.  However clients SHOULD deal with encoding changes as they are encountered, for example by scaling video content to accomodate 
a resolution change
［訳：4.　メディアファイル
　　
プレイリストファイル内の各メディアファイルURIは、全体的なプレゼンテーションのセグメントであるメディアファイルを特定しなければなりません
　　
トランスポートストリームファイルは、単一のMPEG-2プログラムが含まれていなければなりません。各ファイルの先頭にプログラムアソシエーションテーブルとプログラムマップテーブルがあるべきです。ビデオを含むファイルは、ビデオデコーダを完全に初期化するための少なくとも1つのキーフレームとの十分な情報を持っているべきです。
　　
クライアントは、合理的なサブセットを選択することで、特定のタイプ（例えば、オーディオまたはビデオ）の複数のトラックを扱うように準備されるべきです。クライアントは、認識できないトランスポートストリームの中のプライベートストリームを無視しなければなりません。
　　
メディアファイルの内部と複数のメディアファイル間で対応するストリーム間のストリーム内のサンプルのための符号化パラメータは、一貫性を維持すべきです。しかし、クライアントは、例えば、
解像度変更
　　
（３）「6.1.3.  Providing variant streams
　　
A server MAY offer multiple Playlist files to provide different encodings of the same presentation
If it does so it SHOULD provide a variant Playlist file that lists each variant stream to allow clients to switch between encodings dynamically.
　　
Variant Playlists MUST contain an EXT-X-STREAM-INF tag for each variant stream.  Each EXT-X-STREAM-INF tag for the same presentation MUST have the same PROGRAM-ID attribute value.  The PROGRAM-ID value for each presentation MUST be unique within the variant Playlist.
　　
If an EXT-X-STREAM-INF tag contains the CODECS attribute, the attribute value MUST include every format defined by [RFC4281] that is present in any media file that appears or will appear in the Playlist file.
　　
The server MUST meet the following constraints when producing variant streams:
　　
  
 Each variant stream MUST consist of the same content
　　
   The server MUST make the same period of content available for all variant streams, within an accuracy of the smallest target duration of the streams.
　　
   
Matching content in variant streams MUST have matching timestamps
   This allows clients to synchronize the streams.
　　
   Elementary Audio Stream files MUST signal the timestamp of the first sample in the file by prepending an ID3 PRIV tag [ID3] with an owner identifier of com.apple.streaming.transportStreamTimestamp.  The binary data MUST be a 33-bit MPEG-2 Program Elementary Stream timestamp expressed as a big-endian eight-octet number.
　　
In addition, all variant streams SHOULD contain the same encoded audio bitstream.  This allows clients to switch between streams without audible glitching.」
［訳：6.1.3.　バリアント・ストリームの提供
サーバーは、同じプレゼンテーションの異なるエンコーディングを提供するために、複数のプレイリストファイルを提供することがあります
そうであるなら、クライアントが動的にエンコーディングを切り替えることができるように、各バリアントストリームを示すバリアントプレイリストファイルを提供すべきである
　　
バリアントプレイリストは、各バリアントストリームのためのEXT-X-STREAM-INFタグを含まなければなりません。同じプレゼンテーション用の各EXT-X-STREAM-INFタグは同じPROGRAM-ID属性値にしなければなりません。各プレゼンテーションのためのPROGRAM-ID値は、バリアントプレイリスト内で一意でなければなりません。
　　
EXT-X-STREAM-INFタグはコーデック属性が含まれている場合、属性値は、表示されるか、またはプレイリストファイルに表示される任意のメディアファイルに存在している[RFC4281]によって定義されたすべてのフォーマットを含まなければなりません。
　　
バリアントストリームを作成する場合、サーバーは次の制約を満たす必要があります。
　　
各バリアントストリームは、
同じコンテンツで構成されなければなりません
　　
サーバーは、ストリームの最小のターゲット期間以内の精度で、すべてのバリアントストリームのために、コンテンツの同じ期間を利用できるようにしなければなりません。
　　
バリアント・ストリーム内のコンテンツを照合することは、タイムスタンプを照合することである
これは、クライアントがストリームを同期することができるようにします。
　　
エレメンタリオーディオストリームファイルは、「com.apple.streaming.transportStreamTimestamp」のオーナ識別子とともにID3 PRIVタグ[ID3]を付加することで、ファイルの最初のサンプルのタイムスタンプを通知しなければなりません。バイナリデータは、ビッグエンディアンエイトオクテットナンバとして表される33ビットMPEG-2プログラムエレメンタリ・ストリーム・タイムスタンプでなければなりません。
　　
また、すべてのバリアント・ストリームは、同じ符号化されたオーディオビットストリームを含むべきです。これにより、クライアントは、可聴グリッチなしでストリームを切り替えることができます。］
　　
（４）「6.2.3.  Reloading the Playlist file
　　
The client MUST periodically reload the Playlist file
　　
However the client MUST NOT attempt to reload the Playlist file more frequently than specified by this section.
　　
When a client loads a Playlist file for the first time or reloads a Playlist file and finds that it has changed since the last time it was loaded, the client MUST wait for a period of time before attempting to reload the Playlist file again.  This period is called the initial minimum reload delay.  It is measured from the time that the client began loading the Playlist file.
　　
The initial minimum reload delay is the duration of the last media file in the Playlist or 3 times the target duration, whichever is less.  Media file duration is specified by the EXTINF tag.
　　
If the client reloads a Playlist file and finds that it has not changed then it MUST wait for a period of time before retrying.  The minimum delay is three times the target duration or a multiple of the initial minimum reload delay, whichever is less.  This multiple is 0.5 for the first attempt, 1.5 for the second, and 3.0 thereafter.」
［訳：6.2.3.　プレイリストファイルのリロード
　　
　EXT-X-ENDLISTタグが含まれていない限り、
クライアントは、定期的にプレイリストファイルをリロードする必要があります
　　
しかし、クライアントは、このセクションで指定されたよりも、より頻繁にプレイリストファイルをリロードするのを試みてはいけません。
　　
クライアントが初めてプレイリストファイルをロードするか、プレイリストファイルをリロードし、それがロードされた最後の時間以降に変更されたことを検出すると、クライアントは再びプレイリストファイルをリロードしようとする前に、しばらくの間待たなければなりません。この期間は、最初の最小リロード遅延と呼ばれています。これは、クライアントがプレイリストファイルを読み込む始めた時間から測定されます。
　　
初期最小リロード遅延は、プレイリストの最後のメディアファイルの持続時間またはターゲット持続時間の３倍、のうちのより少ない方です。メディアファイルの持続時間は、EXIFタグで指定されています。
　　
クライアントはプレイリストファイルをリロードし、変更がない場合、それは再試行するまでの時間を待たなければなりません。最小遅延は３倍のターゲット期間または初期最小リロード遅延の倍数のいずれか小さい方です。この倍数は、最初の試みのための0.5、二番目の1.5、およびその後の3.0です。］
　　
３　引用文献１に記載された発明
　上記２（１）によると、引用文献１には、クライアントが、最初にプレイリストファイルを取得し、そして、プレイリスト内の各メディアファイルを取得し、ストリームを再生すること、及び追加のセグメントを発見するために、プレイリストファイルをリロードすることが記載されている。ここで、メディアファイルは、単一の連続ストリームのセグメントである。
　クライアントの動作としてみると、「プレイリストファイルを受信する段階」があるといえる。そして、クライアントは、プレイリスト内の各メディアファイルを取得するから、「プレイリストファイルは、メディアファイルに関連する情報を含む」といえる。
　上記２（３）によると、「同じプレゼンテーションの異なるエンコーディング」を提供でき、各バリアントストリームを示すバリアントプレイリストファイルにより、動的にエンコーディングを切り替えることができる。上記２（２）によると、「解像度変更」についての記載があることから、ストリームには、異なる解像度のエンコーディングされた複数のメディアファイルがあるといえる。
　上記２（３）によると、各バリアントストリームは、同じコンテンツで構成されなければならないから、当該ストリームのセグメント（上記２（１））は、「コンテンツのセグメント」である。
　以上より、引用文献１には、『コンテンツのセグメントを異なる解像度のエンコーディングされた複数のメディアファイルに関連する情報を含むプレイリストファイルを受信する段階』が記載されている。
　上記２（１）によると、追加のセグメントを発見するために、プレイリストファイルをリロードすることが記載され、上記２（４）によると、定期的にプレイリストファイルをリロードすることが記載されているから、引用文献１には、『追加のセグメントを発見するために、プレイリストファイルを定期的にリロードする段階』が記載されている。
　上記２（３）によると、「バリアント・ストリーム内のコンテンツを照合することは、タイムスタンプを照合することである」から、ストリームは時間に関連するものであり、メディアファイルはストリームのセグメントである（上記２（１））から『メディアファイルは、時間に基づいてセグメントに分割されている』といえる。
　　
　以上まとめると、引用文献１には、次の発明（以下「引用発明」という。）が記載されていると認められる。
　　
（引用発明）
（ａ）コンテンツのセグメントを異なる解像度のエンコーディングされた複数のメディアファイルに関連する情報を含むプレイリストファイルを受信する段階と、
（ｂ）追加のセグメントを発見するために、プレイリストファイルを定期的にリロードする段階、
（ｃ）メディアファイルは、時間に基づいてセグメントに分割されている
（ｄ）ことを特徴とする方法。
　　
（（ａ）〜（ｄ）は、構成を識別するために付与した。以下各構成を「構成ａ」等という。）
　　
４　対比
（１）構成要件Ａと構成ａとを対比する。
　構成ａにおける「コンテンツのセグメント」、「異なる解像度」、「メディアファイル」、「プレイリストファイル」は、それぞれ、構成要件Ａにおける「コンテンツの第１区間」、「異なる品質」、「第１メディアデータ」、「第１付加情報」に相当する。
　したがって、本願発明と引用発明とは、「コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階」を含む点で一致する。
　　
（２）構成要件Ｄと構成ｂとを対比する。
　構成ｂにおいて、追加のセグメントがあるプレイリストは、構成ａにおけるプレイリストと異なるものであり、上記（１）のとおり、構成ａにおける「プレイリスト」は、構成要件Ａにおける「第１付加情報」に相当するから、構成ｂにおける「追加のセグメントがあるプレイリスト」は、「第２付加情報」といえる。
　したがって、引用発明は、「第２付加情報」を受信する段階を含む点で、本願発明と共通する。
　しかしながら、本願発明における「第２付加情報を受信する段階」は、構成要件Ｂ、Ｃの段階を経たあとの段階であるのに対し、引用発明における当該段階は、引用発明には構成要件Ｂ、Ｃがないから、構成要件Ｂ、Ｃを経た段階でない点で、本願発明と相違する。
　　
（３）構成要件Ｅと構成ｃとを対比する。
　引用発明における「メディアファイル」は、本願発明における「第１メディアデータ」に相当するから、本願発明と引用発明とは、「前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割される」点で一致する。
　　
（４）構成要件Ｆと構成ｄとを対比する。
　構成ｄの「方法」は、構成ａ、ｂを含むから、「データ受信方法」といえる。
　したがって、本願発明と引用発明とは、「データ受信方法」として一致する。
　　
５　一致点、相違点
　以上より、一致点、相違点は次のとおりである。
　　
（一致点）
　コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
　第２付加情報を受信する段階と、を含み、
　前記複数個の第１メディアデータのそれぞれは時間に基づいてセグメントに分割される
　ことを特徴とするデータ受信方法。　　
　　
（相違点）
　「第２付加情報を受信する段階」が、
　本願発明においては、
「前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階」及び
「前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階」
とを経た後の段階であるのに対し、
　引用発明においては、そのような段階を経た後の段階ではない点
　　
　　
６　判断
（１）周知技術
ア　原査定の拒絶の理由に引用された国際公開第２００８／０６２９７９号（引用文献２）の段落[72]には、次の事項が記載されている。
　　
「The supplementary information service providing system 200 includes a Presentation  Time Stamp (PTS) information creating server 210 for extracting PTS information about the start time of the transmitted broadcast content, and a supplementary information service providing server 220 for storing various pieces of supplementary information corresponding to the broadcast content, extracting corresponding supplementary information, and providing it to the user terminal 10 at the request of the user terminal 10. The user terminal 10 receives broadcast content from the broadcasting system 100, requests supplementary information related to corresponding broadcast content from the supplementary information service providing server 220, and receives the requested supplementary information through a communication infrastructure.」
［訳：付加情報サービス提供システム２００は、前記送出される放送コンテンツの開始時間に対するＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）情報を抽出するＰＴＳ情報生成サーバー２１０；及び前記放送コンテンツに対応する多様な付加情報を保存し、使用者端末機１０に要請に応じて、該当付加情報を抽出して提供する付加情報サービス提供サーバー２２０；を含む。使用者端末機１０は、前記放送システム１００から送出される放送コンテンツを受信し、該当放送コンテンツに関連した付加情報を通信インフラを通じて前記付加情報サービス提供サーバー２２０に要請して受信する。］（特表２０１０−５１０７１０号公報、段落【００５９】）
　　
イ　原査定の拒絶の理由に引用された国際公開第２００８／１３０１９１号（引用文献３）の段落[87]には、次の事項が記載されている。
　　
「Referring to FIGS. 4 through 6, IPTV receiving device 40 requests contents guide information (e.g., EPG, CPG, etc) from a service provider 20, S21. The service provider 20 generates contents guide information in response to the request and transfers the generated information to the IPTV receiving device 40, S22. The IPTV receiving device 40 can then process contents guide information received from the service  provider 20 to agree with a user interface and display the processed information S23.」
［訳：図４乃至図６を参照すると、ＩＰＴＶ受信デバイス４０は、サービスプロバイダ２０にコンテンツ案内情報(例えば、EPG、CPG等)を要請する(ステップＳ２１)。サービスプロバイダ２０は、前記要請に応答してコンテンツ案内情報を生成した後、ＩＰＴＶ受信デバイス４０に送信する(ステップＳ２２)。すると、ＩＰＴＶ受信デバイス４０は、サービスプロバイダ２０から受信したコンテンツ案内情報をユーザインターフェースに合うように加工して表示することができる(ステップＳ２３)。］（特表２０１０−５２５７２０号公報、段落【００６６】）
　　
ウ　原査定の拒絶の理由に引用された特開２００９−１３４７００号公報（引用文献４）の段落【００４４】には、次の事項が記載されている。
　　
「ＩＰＴＶ放送システム１０００は、放送コンテンツを格納するための格納サーバと、リターンチャンネルから入力されるユーザ要請信号（番組推薦要請信号、付加情報要請信号など）を処理するためのリターンパスサーバ、放送コンテンツを分配するための分配サーバなどを含むことができる。」
　　
エ　周知技術
　上記ア〜ウによると、ユーザデバイスから、付加情報を要請することは、周知技術と認められる。
　　
（２）容易想到性
　引用発明に、付加情報を得る技術として引用発明と技術分野が共通する周知技術を適用すると、引用発明において、第２付加情報である「追加のセグメントがあるプレイリスト」を定期的にリロードする代わりに、ユーザデバイスの要請によりリロードするようにすることに至る。
　しかしながら、本願発明は、
「前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階」及び
「前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する段階」
を含むものであって、引用発明に周知技術を適用しても、
「前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得」して、「前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報を要請する」ことには、至らない。
　引用文献２〜４には、相違点に係る構成が開示されているとは、認められない。
　また、引用発明において、相違点の構成を含むようにする理由はない。
　したがって、本願発明は、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　
　請求項２〜１０に係る発明は、請求項１の記載を直接又は間接的に引用しているので、本願発明（請求項１に係る発明）と同じ理由で、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
　請求項１３に係る発明は、「方法」の発明である請求項１に係る発明を「装置」の発明としたものであるから、請求項１に係る発明と同じ理由で、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
　請求項１５に係る発明は、「データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体」の発明であり、請求項１に係る発明と同じ構成を含むから、請求項１に係る発明と同じ理由で、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
　請求項１１に係る発明は、「データ提供方法」であって、「前記第１付加情報は、前記第１付加情報が更新可能な時点を示す更新時点情報を含」むものである。「前記第１付加情報は、前記第１付加情報が更新可能な時点を示す更新時点情報を含」む点は、引用文献１〜４に開示されていないから、請求項１１に係る発明は、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
　請求項１２に係る発明は、請求項１１の記載を引用しているので、請求項１１に係る発明とと同じ理由で、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
　請求項１４に係る発明は、「方法」の発明である請求項１１に係る発明を「装置」の発明としたものであるから、請求項１１に係る発明と同じ理由で、引用文献１〜４に記載された発明に基づいて、当業者が容易に想到し得たものとは、認められない。
　　
７　むすび
　以上のとおり、本願の請求項１〜１５に係る発明は、刊行物１〜４に記載された発明に基づいて当業者が容易に発明をすることができたものではないから、原査定の理由によっては、本願を拒絶することができない。
　また、他に本願を拒絶すべき理由を発見しない。　
　よって、結論のとおり審決する。