• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 H04N
審判 査定不服 1項3号刊行物記載 取り消して特許、登録 H04N
管理番号 1324479
審判番号 不服2015-14810  
総通号数 207 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-03-31 
種別 拒絶査定不服の審決 
審判請求日 2015-08-06 
確定日 2017-02-27 
事件の表示 特願2012-538764「部分化を利用した適応的なストリーミング方法及びその装置」拒絶査定不服審判事件〔平成23年 5月19日国際公開、WO2011/059273、平成25年 3月28日国内公表、特表2013-511196、請求項の数(15)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、2010年11月12日(パリ条約による優先権主張外国庁受理2009年11月13日 米国、2009年11月19日 米国、2009年12月7日 米国、2010年3月16日 米国、2010年3月30日 米国、2010年9月7日 米国、2010年9月7日 米国、2010年10月22日 韓国)を国際出願日とする出願であって、手続の概要は以下のとおりである。

拒絶理由通知 :平成26年 6月25日(起案日)
手続補正 :平成26年10月 1日
拒絶査定 :平成27年 3月30日(起案日)
(以下、「原査定」という。)
拒絶査定不服審判請求 :平成27年 8月 6日
手続補正 :平成27年 8月 6日
拒絶理由通知 :平成28年 9月 8日(起案日)
(以下、「当審拒絶理由通知」という。)
手続補正 :平成28年12月12日

第2 原査定の概要
原査定の概要は次のとおりである。

本願請求項1?15に係る発明は、以下の引用文献A、Bと周知技術(引用文献C)に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
A.特開2004-088766号公報
B.特開2005-303927号公報
C.特開2008-236667号公報(周知技術を示す文献)

第3 当審拒絶理由通知の概要
当審拒絶理由通知の概要は次のとおりである。

理由1
本願請求項1、12?15に係る発明は、以下の引用文献1に記載された発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない。

理由2
本願請求項1?15に係る発明は、以下の引用文献1、2に基いて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特表2004-516717号公報(当審において新たに引用した文献)
2.特開2004-088766号公報(拒絶査定時の引用文献A)

第4 本願発明
本願請求項1?15に係る発明(以下、それぞれ「本願発明1」?「本願発明15」という。)は、平成28年12月12日付けの手続補正で補正された特許請求の範囲の請求項1?15に記載された事項により特定される発明であり、本願発明1?15は以下のとおりの発明である。
なお、本願発明1のA、B・・・については、説明のために当審で付したものであり、以下、「構成A」、「構成B」・・・という。

「【請求項1】
A メディアデータを受信する方法において、
B コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルをサーバから受信する段階と、
C 前記受信されたファイルに基づいて前記複数のメディアデータのうち第1メディアデータに含まれた第1部分を受信する段階と、
D 前記受信されたファイルに基づいて前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分を受信する段階と、を含み、
E 前記複数のメディアデータは、時間に基づいて複数の部分に分割され、
F 前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ、
G 前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報を含む
H ことを特徴とするメディアデータ受信方法。
【請求項2】
前記複数のメディアデータは、
MPEG-2 TS(MPEG-2 transport stream)フォーマットによるメディアデータであり、
前記複数のメディアデータは、前記MPEG-2TSのエレメンタリー・ストリームに対応することを特徴とする請求項1に記載のメディアデータ受信方法。
【請求項3】
前記複数の部分のそれぞれは、少なくとも1つのPES(packetized elementary stream )を含み、1つのPESは、1つの部分にいずれも含まれることを特徴とする請求項2に記載のメディアデータ受信方法。
【請求項4】
前記PESは、少なくとも1つの映像フレームまたは音声フレームに係わるデータを含むことを特徴とする請求項3に記載のメディアデータ受信方法。
【請求項5】
ランダム・アクセスポイントに係わる伝送ストリームは、ランダム・アクセスポイントに係わる伝送ストリームであることを示す情報を含むことを特徴とする請求項3に記載のメディアデータ受信方法。
【請求項6】
前記受信されたファイルは、
前記複数のメディアデータと関連したPAT(program association table)及びPMT(program map table)のうち、少なくとも一つを参考にする情報をさらに含むことを特徴とする請求項2に記載のメディアデータ受信方法。
【請求項7】
前記PAT及びPMTは、
初期化部分であり、前記複数のメディアデータと分離されていることを特徴とする請求項6に記載のメディアデータ受信方法。
【請求項8】
前記PAT及びPMTのうち、少なくとも一つは、
前記複数のメディアデータ全体のリストを含むことを特徴とする請求項6に記載のメディアデータ受信方法。
【請求項9】
前記複数のメディアデータは、複数のPID(packet ID)のそれぞれ異なる一つに割り当てられることを特徴とする請求項6に記載のメディアデータ受信方法。
【請求項10】
前記複数のメディアデータは、それぞれのPTS(presentation time stamp)及びそれぞれのDTS(decoding time stamp)を含むPESから構成され、
前記それぞれのPTSと前記それぞれのDTSは、メディアデータの再生時間によって整列されることをさらに含むことを特徴とする請求項6に記載のメディアデータ受信方法。
【請求項11】
前記複数の部分のそれぞれは、
少なくとも1つのGOP(group of pictures)に係わる少なくとも1つの伝送ストリームを含むことを特徴とする請求項2に記載のメディアデータ受信方法。
【請求項12】
メディアデータを伝送する方法において、
コンテンツをそれぞれ異なる品質にエンコーディングして生成される複数のメディアデータについての情報を含むファイルをクライアントに伝送する段階と、
前記伝送されたファイルを利用した前記クライアントの要請によって、前記複数の第1メディアデータのうち、第1メディアデータに含まれた第1部分を前記クライアントに伝送する段階と、
前記伝送されたファイルに基づいた前記クライアントの要請によって、前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分を前記クライアントに伝送する段階と、を含み、
前記複数のメディアデータは、時間に基づいて複数の部分に分割され、
前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ、
前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報を含むことを特徴とするメディアデータ伝送方法。
【請求項13】
メディアデータを受信する装置において、
コンテンツをそれぞれ異なる品質にエンコーディングして生成される複数のメディアデータについての情報を含むファイルをサーバから受信する情報受信部と、
前記受信されたファイルを利用し、前記複数のメディアデータのうち、第1メディアデータに含まれた第1部分を受信するメディアデータ受信部と、を含み、
前記メディアデータ受信部は、前記受信されたファイルに基づいて前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分を受信し、
前記複数のメディアデータは、時間に基づいて複数の部分に分割され、
前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ、
前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報を含むことを特徴とするメディアデータ受信装置。
【請求項14】
メディアデータを伝送する装置において、
コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルをクライアントに伝送する情報伝送部と、
前記伝送されたファイルに基づいた前記クライアントの要請によって、前記複数のメディアデータのうち、第1メディアデータに含まれた第1部分を伝送するメディアデータ伝送部と、を含み、
前記メディアデータ伝送部は、前記伝送されたファイルに基づいた前記クライアントの要請によって、前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分を伝送し、
前記複数のメディアデータは、時間に基づいて複数の部分に分割され、
前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ、
前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報を含むことを特徴とするメディアデータ伝送装置。
【請求項15】
請求項1ないし請求項11のうち、いずれか1項に記載の方法を実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体。」

第5 引用文献、引用発明等
1.引用文献1について
当審拒絶理由通知に引用された引用文献1には、図面とともに次の事項が記載されている。
なお、下線は、説明のために当審にて付したものである。

【0004】
【課題を解決するための手段】
本発明の1特徴によれば、オーディオまたはビデオマテリアルの連続する時間的部分を表している1組のファイルとして遠隔サーバに記憶されているオーディオまたはビデオマテリアルを再生する端末は、サーバと通信する通信インターフェースと、通信インターフェースからファイルを受取るバッファと、バッファの内容を再生する手段と、バッファの状態に応答してバッファの補充のためにさらに別のファイルに対してリクエストメッセージを生成するように動作する制御手段とを具備していることを特徴とする。
【0005】
本発明の別の特徴によれば、本発明は、デジタル符号化されたオーディオまたはビデオマテリアルを送信する方法が提供され、その方法においては、前記マテリアルの連続する時間的部分をそれぞれ表している複数のディスクリートなファイルにマテリアルを分割し、それらのファイルを第1の局において記憶し、第2の局においては、
a)ファイルの連続するそれぞれに対するリクエストを第1の局に送信し、
b)ファイルを受信し、
c)マテリアルの再生のためにファイルをデコードすることを特徴とする。

【0007】
【発明の実施の形態】
添付図面を参照にして、本発明の実施形態について説明する。図1に示されたシステムは、デジタル符号化されたオーディオ信号を通信ネットワークを介して対応する音響がユーザに対して再生されるユーザ端末へ配信することを目的としている。しかしながら、以下詳細に説明するように、このシステムはオーディオ信号の代りに、或いはオーディオ信号に付加してビデオ信号を伝送するために使用することもできる。この例では、ネットワークは、原理的には他のデジタルリンクまたはネットワークを使用することが可能であるが、ハイパーテキスト転送プロトコル(詳細はRFC1945/2068 参照)にしたがって動作するインターネットまたは他のパケットネットワークである。オーディオ信号はISO MPEG-1層III 標準方式(MP3標準方式)を使用する圧縮された形態で記録されていると仮定する。しかしながら、この特定のフォーマットの使用は本質的なことではない。事実、特に利用できるビットレートが制限され、或いは記憶スペースが限定されている場合には圧縮の使用は非常に望ましいことであるが、本質的に必要なことではない。図1ではサーバ1 はインターネット2 を介して1つしか示されていないユーザ端末3 に接続されている。サーバ1 の機能はデータファイルを記憶し、所望のデータファイルの配信のためのリクエストをユーザ端末から受信し、リクエストに応答してそのファイルをネットワークを介してユーザ端末に送信することである。通常そのようなリクエストはネットワーク配信機構(例えば、ハイパーテキスト転送プロトコルまたはファイル転送プロトコルに対してはそれぞれhｔｔｐ://またはファイル://)を指示する第1の部分の形態を取り、それに続いてサーバのネットワークアドレス(例えばｗｗｗサーバ1.cｏm)が付加され、さらにそれに続いてリクエストされているファイル名を付けられている。与えられた例ではそのような名称はタイプ上の理由で//で示されている。

【0009】
通常MP3ファイルの受渡し用のサーバはいわゆるストリーマの形態をとり、それはユーザ端末での応答要求に応じてデータが送信される速度をダイナミックに制御し、パケット損失によるエラーをマスクし、ユーザの介入が許容されている場合にはサーバとクライアントとの間のデータ流を制御する処理装置を含んでいる。しかしながら、ここではサーバ1はそのような設備は含んでいない。したがって、それは通常の“ウエブサーバ”である。
【0010】
データファイルがサーバ1に記憶される方法について説明する。MP3フォーマットのファイルが生成されてサーバに記憶されると考える。それはJ.S.バッハのトッカータとフーガD短調(BWV565)の記録であり、典型的に9分の再生時間を有する。元来これは単一のデータファイルとして生成され、通常のストリーマではこれは1つの単一のファイルとして記憶される。しかしながら、ここではファイルはサーバ1に記憶される前に小さいファイルに分割される。これらの各小さいファイルはそれぞれ固定された再生時間、恐らく4秒に対応する大きさである。MP3のような圧縮されたフォーマットにより、これはそれらのファイルが実際に含んでいるビットの数に対して異なった大きさであることを意味している。したがって9分の期間のバッハのファイルはそれぞれ4秒の再生時間の135の小さいファイルに分割される。この例では、これらは所定のファイル名を与えられ、それはもとのファイル中のそれらの順序を示す通し番号を含んでおり、例えば、
000000.ビン
000001.ビン
000002.ビン
000003.ビン
・
・
000134.ビンである。
【0011】
ファイルのこれらの小さいサブファイルへの分割は典型的にウエブサーバ1へロードするためのファイルを処理する人によって行われることができる(ここで使用されるサブファイルという用語は、全体の記録を含んでいるもとのファイルと区別するためにここで使用されているが、しかしながらサーバが関係される限りサブファイルは他のファイルと同様のファイルであることを強調しておく)。それらを生成する正確な方法について以下さらに十分に説明する。これらのサブファイルは、一度生成されると、任意の他のファイルがウエブサーバへロードされるのと同様の通常の方法でサーバにアップロードされる。もちろんファイル名は特定の記録を識別する文字を含むことができる(MP3ファイルを再生するときサブファイルは著者、著作権等の情報を得る付加的な情報のタグを付けられることもできる)が、この例においてはサブファイルはサーバ中で特定の記録、例えばmｐ3 bｗｖ565に特定された名簿またはホルダー中に記憶される。したがってサブファイルは必要なとき次の形態でリクエストされることができる。

【0015】
次に、端末について説明すると、これは典型的に通常のデスクトップコンピュータの形態のものでよいが、前述したオーディオファイルの受信を処理するための付加的なソフトウエアを有している。所望ならば、端末は手持ち形のコンピュータの形態をとることができ、また、移動体電話機中に内蔵されてもよい。したがって、図2はそのような端末を示し、それは中央プロセッサ30、メモリ31、ディスク記憶装置32、キーボード33、ビデオディスプレイ34、通信インターフェース35、オーディオインターフェース(音響カード)36を備えている。ビデオ配信のためには、音響カード36の代りに或いはそれに追加してビデオカードが使用される。ディスク記憶装置32には通常の方法でプロセッサ30により実行されるためにメモリ中で検索されることのできるプログラムが記憶されている。これらのプログラムは呼出しおよびhｔmページの表示のための通信プログラム37、すなわちNeｔｓcaｐe NaｖigaｔｏｒまたはMicｒｏｓｏfｔ Eｘｐlｏｒeｒのような“ウエブブラウザ”プログラムおよび本発明のこの実施形態にしたがってオーディオファイルの再生のために必要な機能性を与えるここで“プレイヤープログラム”と呼ばれているような別のプログラム38を含んでいる。また、メモリ31の39で示される領域はバッファとして割当てられている。これは再生されるために待機しているデータを含む復調されたオーディオバッファである(典型的に、バッファの動作継続時間は10秒である)。オーディオインターフェースまたは音響カード36は通常のカードであり、単にPCMオーディオ信号を受信してそれをアナログオーディオ信号に変換するように、例えばスピーカにより再生するように機能する。最初に、HTTPおよび内蔵またはプラグインされたクライアント装置を使用するとき、所望の記録を検索して再生する端末装置の動作の概要について簡単に説明する。

【0028】
a)サーバは異なった圧縮率で記録された記録の2以上のバージョンを記憶し[例えば、それぞれ、8 ,16, 24, 32 キロビット/秒の(連続的な)データレートに対応する圧縮率で]、プレイヤープログラムは自動的にそれらの間で切換えることができる。
【0029】
b)プレイヤープログラムはユーザに対して制御パネルを表示し、それによりユーザは再生を開始し、それを中断し、それを再開し(最初から、或いは中止した点から)、または記録中の異なる点(後方または前方)にジャンプすることが可能になる。
【0030】
これらの特徴は相互依存性ではなく、ユーザ制御はレートスイッチングなしに或いはその反対に行われることができる。
【0031】
レートスイッチングを行なうために、サーバにロードするためにファイルを処理する人は、異なったレートで複数回同じPCMファイルを符号化することによって幾つかのソースファイルを処理する。彼は各ソースファイルを前述したようにサブファイルに区分する。これらは異なったレートに対応する別々のディレクトリ(登録簿)でサーバにロードされる。例えば、次の例の構成ではディレクトリネーム中の“008k”“024k”は8キロビット/秒または24キロビット/秒等のレートを示している。
【0032】
彼はまたインデックスファイル(例えばindeｘ.hｔm )を生成し、その主目的は利用可能なデータレートのリストを提供することである。
【0033】
【表1】
(表は略)
サブファイルの長さは前に説明したように固定された時間長に対応しているから、サブファイルの数は各ディレクトリに対して同じである。サブディレクトリネームはキロビット/秒のデータレート(3デジット)プラス文字“k”を含んでおり、この例ではオーディオサンプリングレート(11.025kHｚ)の指示であって、モノとステレオのフラグが確認のために付加されている。
【0034】
したがって、インデックスファイルは次の形態のステートメントである。
【0035】
＜!オーディオ信号=“024k 11 ｓ 032k 11 ｓ 018k 11 ｓ 016k 11 m 018k 11 m ”…＞
(＜!…...…＞は単にステートメントがhｔmlファイル中のコメント[または簡単なテキストファイルが使用可能である]として埋設されていることを示している。)典型的なインデックスファイルは図3に示されており、それには他の情報が含まれている。すなわち、LFIは最高のサブファイル数(すなわち45のサブファイル)であり、SLは全体の再生時間である(178秒)。“モード”は“記録された(ここで)”または“ライブ(以下説明する)”を示している。他のエントリは自明であり、或いは標準的なhｔmlコマンドである。
【0036】
最初に、プレイヤープログラムはリンクファイル、インデックスファイルで特定されたディレクトリからのリクエストにより開始し、将来の基準のために利用可能なデータレートのリストを局部的に記憶する。(このファイルまたは丁度特定したディレクトリの明瞭なリクエストであってもよく、大抵のサーバはファイルネームが特定されていなければindeｘ.hｔmにデフォルトである。)。その後、インデックスファイル-ｖiｚ.024k 11 ｓ(または端末はその端末に局部的に設定されたデフォルトレートにこれに修正することによってこれに重ね書きされる)中の最初に挙げた“レート”ディレクトリから前述のようにオーディオサブファイルのリクエストが開始される。それからのプロセスは、プレイヤープログラムがサーバから受信されている実際のデータレートを測定して、ある期間にわたって(例えば30秒)平均する。全てのURLリクエストをタイミング制御することによって、クライアントとサーバとの間で得られる転送レート(毎秒当たりのビット数)が決定される。この図の正確さはリクエスト数が増加するにしたがって改善される。プレイヤーは現在のレートと測定されたレートをそれぞれ示している2つの記憶されたパラメータを維持する。レート変化の開始がトリガーされる。
a)バッファが空であり、かつ、測定されたレートが現在のレートよりも小さく、かつ、測定されたバッファロウ(Lｏｗ)%がステップダウンしきい値(以下説明する)を越える場合には、現在のレートを減少させる(バッファがすでに空であるとき、音響カードは何も再生しないのが有効であるので時間を変化させ、オーディオサンプリングレート、ステレオ-モノ設定、またはビット幅[サンプル当たりのビット数]が変化された場合にはそれは再構成することが必要である可能性がある)。
【0037】
b)測定されたレートが現在のレートを越えているだけではなく、所定の期間(例えば120秒:これは所望ならばユーザにより調整可能にされることができる)に対して次に高いレートを越えるならば、現在のレートを増加させる。
【0038】
バッファロウ%はバッファの内容がプレイアウト時間(すなわち、バッファが空に近い状態)の25%よりも小さい時間の割合である。ステップダウンしきい値が0%に設定され、そのときバッファは空であるならば、システムは他の条件が満足されたときには常にステップダウンする。ステップダウンしきい値を5%に設定する(これは我々の好ましいデフォルト値である)ことは、バッファは空であるが、測定されたバッファロウ%が5%よりも大きければステップダウンは行わないことを意味している。さらに、バッファの空はこの測定されたレートを明らかに増加させ、レートが持続できない場合には、バッファロウ%が5%を越えることにより再びバッファを最終的に空にする。値を100%に設定することは、クライアントが決してステップダウンを行わないことを意味している。
【0039】
実際のレート変化は、データレートを8kビット/秒から24kビット/秒に増加するために“008k”を“024k”に変更するようにサブファイルアドレスの関係する部分を変更し、現在のレートのパラメータを整合するように変更するプレイヤープログラムによって簡単に行うことができる。その結果サーバに対する次のリクエストはより高い(またはより低い)レートに対するリクエストとなり、新しいディレクトリからサブファイルが受信され、デコードされてバッファに入力される。以上説明したプロセスは次のフローチャートに要約されている。

【0069】
同じ原理は、ビデオ記録または、もちろん添付された音響トラックを有するビデオ記録の受渡しに適用できる。簡単なバージョンでは、ただ1つの記録しかない場合に、システムはオーディオバージョンのみのときとは異なり、ファイルはビデオファイルであり(例えばH.261またはMPEGフォーマット)、プイヤープログラムはビデオデコーダを伴っている。ファイルをサブファイルに区分する方法は変更されない。

ここで、引用文献1の端末は、段落0004、0005等の記載から、遠隔サーバに記憶されているビデオマテリアルを受信し再生するものであるから、引用文献1には、『ビデオマテリアルを受信する方法』についての記載があるといえる。
また、段落0009?0011、0028?0039においては、MP3ファイルすなわちオーディオ信号のファイルを例にしているが、段落0007、0069の記載から、ビデオマテリアルに使用することも可能であるから、ビデオマテリアルのファイルをサブファイルに分割すること、ビデオマテリアルのファイルに関する利用可能なデータレートのリストのインデックスファイルが提供されることが開示されているといえる。

そうすると、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。
なお、引用発明のa、b・・・については、説明のために当審で付したものであり、以下、「構成a」、「構成b」という。

「a ビデオマテリアルを受信する方法において、
b 異なったデータレートに対応する圧縮率で記録された記録の2以上のバージョンがサーバに記憶され、利用可能なデータレートのリストのインデックスファイルが提供され、
c ビデオマテリアルのファイルは複数のサブファイルに分割されており、インデックスファイル中の最初に挙げたレートディレクトリからサブファイルのリクエストが開始され、
d 測定されたレートと現在のレートに応じて、現在のレートを減少もしくは増加させ、新しいディレクトリからサブファイルが受信され、
e サブファイルの長さは、固定された時間長に対応する
f ビデオマテリアルを受信する方法。」

2.引用文献2について
当審拒絶理由通知に引用された引用文献2(原査定に引用された引用文献A)の段落0187、0191、0223?0226、0237の記載からみて、当該引用文献2には、「クライアント端末が、サーバ装置からMPEG2方式で符号化されたビデオデータのストリームを受信する際に、サーバ装置で解像度の異なる同内容のビデオ映像が用意され、サーバ装置は、クライアント端末からのアプリケーション識別情報やデータ識別情報等により、クライアント端末に適するデータを選択して送信し、クライアント端末は該選択されたデータを受信する方法」という技術的事項が記載されていると認められる。

3.引用文献Bについて
原査定に引用された引用文献Bの段落0063の記載からみて、当該引用文献Bには、「MPEG方式でエンコードされている場合、GOPを単位としてエンコードが行われているため、GOPを単位として復号が可能である」という技術的事項が記載されていると認められる。

4.引用文献Cについて
原査定にて周知技術として引用された引用文献Cの段落0045?0059の記載からみて、当該引用文献Cには、「階層伝送された放送波のTSを受信して、パーシャルTSを生成する際に、高階層伝送用のPMTと低階層伝送用のPMTを生成し、各PMTの情報に基づいてPATを生成し、各PMTとPATと映像コンテンツデータ等からパーシャルTSを生成して、高階層のコンテンツデータと低階層のコンテンツデータの両方を包含するパーシャルTSを再構成し、DSMに記録される」という技術的事項が記載されていると認められる。すなわち、高階層、低階層のTSに、様々な情報が付加されている。

第6 当審の判断
1.本願発明1について
(1)対比
本願発明1と引用発明を対比する。

(1-1)構成Aについて
引用発明の構成aの「ビデオマテリアル」は、本願発明1の構成Aの「メディアデータ」に相当するので、構成aは構成Aに相当する。

(1-2)構成Bについて
引用発明の構成bの「異なったデータレートに対応する圧縮率で記録された記録の2以上のバージョン」は、異なったデータレートに対応する圧縮率で記録されることにより、それぞれのバージョンは、異なる品質に圧縮されたデータになるといえるから、本願発明1の構成Bの「コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータ」に相当する。
そして、構成bの「利用可能なデータレートのリストのインデックスファイル」は、それぞれのバージョンのデータレートのリストをファイルにしたものであり、各バージョンについての情報を含むファイルといえるので、構成Bの「複数のメディアデータについての情報を含むファイル」に相当する。
さらに、構成bの「提供され」ることは、端末側からみると、ファイルをサーバから受信するものであるから、構成Bの「サーバから受信する」ことに相当する。
したがって、構成bは構成Bに相当する。

(1-3)構成Cについて
引用発明の構成cの「サブファイル」は、あるデータレートで圧縮したビデオマテリアルを分割した1つのファイルを指し、本願発明1の構成Cの「第1部分」は、第1メディアデータを分割した部分であることから、構成cの「サブファイル」は、構成Cの「第1部分」に相当する。
構成cの「インデックスファイル中の最初に挙げたレートディレクトリからサブファイルのリクエストが開始され」ることは、インデックスファイルに示された複数のファイルから選択したレートのサブファイルを受信することであるから、本願発明1の構成Cの「前記受信されたファイルに基づいて前記複数のメディアデータのうち第1メディアデータに含まれた第1部分を受信する」ことに相当する。
したがって、構成cは構成Cに相当する。

(1-4)構成Dについて
引用発明の構成dの「測定されたレートと現在のレートに応じて、現在のレートを減少もしくは増加させ」ることは、現在のレートと異なる新しいレートにすることであり、新しいレートにする際には、利用可能なデータレートから選ばれるものであるから、『利用可能なデータレートのリストのインデックスファイルに基づ』くものといえる。
また、構成dの「新しいディレクトリからサブファイルが受信され」ることは、『現在のディレクトリのサブファイルの次のサブファイルと対応する新しいディレクトリのサブファイルを受信』することといえる。
すなわち、構成dは、『利用可能なデータレートのリストのインデックスファイルに基づいて、現在のディレクトリのサブファイルの次のサブファイルと対応する新しいディレクトリのサブファイルを受信する』ものといえる。
そして、構成dの『利用可能なデータレートのリストのインデックスファイル』、『現在のディレクトリのサブファイルの次のサブファイルと対応する新しいディレクトリのサブファイル』は、それぞれ、構成Dの「前記受信されたファイル」、「前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分」に相当する。
したがって、構成dは構成Dに相当する。

(1-5)構成Eについて
引用発明の構成eの「サブファイルの長さは、固定された時間長」は、データが、固定された時間でサブファイルに分割されていることであるから、本願発明1の構成Eの「前記複数のメディアデータは、時間に基づいて複数の部分に分割されること」に相当する。
したがって、構成eは構成Eに相当する。

(1-6)構成Fについて
引用発明の「サブファイル」は、本願発明1の構成Fの「複数の部分」に相当するが、再生時間についての情報が含まれているか否かについて不明である。
したがって、引用発明は、構成Fを有するか否か不明である。

(1-7)構成Gについて
引用発明は、再生時間を対応させるための時間調整情報を含むものではなく、引用発明は、本願発明1の構成Gを有さないものである。

(1-8)構成Hについて
上記(1-1)の検討と同様に、引用発明の構成hは、本願発明1の構成Hに相当する。

(1-9)一致点・相違点
したがって、本願発明1と引用発明は、以下の一致点・相違点がある。

[一致点]
「メディアデータを受信する方法において、
コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルをサーバから受信する段階と、
前記受信されたファイルに基づいて前記複数のメディアデータのうち第1メディアデータに含まれた第1部分を受信する段階と、
前記受信されたファイルに基づいて前記第1メディアデータに含まれた少なくとも一つの部分のうち、前記第1部分の次の部分である第2部分と対応する第2メディアデータの第2部分を受信する段階と、を含み、
前記複数のメディアデータは、時間に基づいて複数の部分に分割される
ことを特徴とするメディアデータ受信方法。」

[相違点]
相違点1
本願発明1は、「前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ」ているのに対し、引用発明は、そのような情報が含まれているか否かについて不明である点。

相違点2
本願発明1は、「前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報を含む」のに対し、引用発明は、そのような時間調整情報が含まれていない点。

(2)相違点についての検討
(2-1)相違点1について
複数の部分に分割されるメディアデータを作成する際に、各部分に再生時間に関する情報を含むようにすることは、周知の技術であり、引用発明にそのような周知の技術を適用して、「前記複数の部分には、それぞれ前記複数の部分の再生時間についての情報が含まれ」ているようにすることは、当業者であれば、容易に想到し得るものである。

(2-2)相違点2について
当該相違点2に関連する記載として、本願明細書には以下の記載がある。

「【0067】
複数のメディアデータのPESのPTS及び/またはDTSが、再生時間に基づいて整列されず、連続的な再生が不可能な場合が発生しもする。例えば、所定コンデンツに係わる第1メディアデータを第1サーバが生成し、所定コンデンツに係わる第2メディアデータを第2サーバが生成する場合、PTS及び/またはDTSが再生時間に基づいて整列されない。
【0068】
例えば、第1メディアデータの連続した3つの部分のPTSが、それぞれ「1000」、「2000」、「3000」と定義されており、同じ再生時間に係わる第2メディアデータの連続した3つの部分のPTSが、それぞれ「11000」、「12000」、「13000」と定義されていることもある。その場合、第1メディアデータの最初の部分のPTSは、「1000」であり、第2メディアデータの2番目の部分のPTSは、「11000」であるから、メディアデータを受信する側では、同じ再生時間に係わる部分であると判断することができない。その場合、PTSの不一致によって、メディアデータの変更再生を介した適応的なストリーミングが不可能である。
【0069】
このような問題を解決するために、次のような構文を介して、タイムスタンプの不一致を校正するための情報を生成し、生成された情報を、前述のメディア表現記述またはメディアデータに挿入することができる。」

すなわち、本願発明1は、第1メディアデータと第2メディアデータが異なるサーバで生成され、PTSやDTSが同じ再生時間に係わる部分と判断できず、整列されなくなるという課題を解決するために、時間調整情報を含むようにしたものである。
しかし、引用発明は、そのような課題を有しているものでなく、また、同じ再生時間のデータであれば、予めPTSやDTSを同じに設定しようと考えることの方が当業者にとって自然であり、引用発明において、「再生時間を対応させるための時間調整情報」を含むようにすることは、容易に思い至るものではない。
また、当審拒絶理由通知に引用された引用文献2をみても、クライアント端末からのアプリケーション識別情報やデータ識別情報等により、クライアント端末に適するデータを選択して送信するという技術的事項が開示されているだけであり、当該相違点2が容易に思い至るものであるとはいえない。

したがって、他の相違点について判断するまでもなく、本願発明1は、当業者であっても引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2?11について
本願発明2?11については、本願発明1を直接若しくは間接的に引用する発明であるから、同様に上記相違点2に係る構成を全て有しているものであるので、本願発明1と同様に、当業者であっても引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.本願発明12?14について
本願発明12?14は、本願発明1の「メディアデータを受信する方法」を、「メディアデータを伝送する方法」、「メディアデータを受信する装置」、「メディアデータを伝送する装置」としたものであり、いずれにおいても、上記相違点2に係る構成を有しているものであるので、本願発明1と同様に、当業者であっても引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

4.本願発明15について
本願発明15は、本願発明1?11の方法を実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体についての発明であり、上記相違点2に係る構成を有しているものであるので、本願発明1と同様に、当業者であっても引用発明、引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第7 原査定についての判断
平成28年12月12日付けの補正により、補正後の請求項1?15は、「前記ファイルは、前記第1メディアデータに含まれた少なくとも一つの部分と前記第2メディアデータに含まれた少なくとも一つの部分の再生時間を対応させるための時間調整情報」という技術的事項を含むものとなり、当該「時間調整情報」は、原査定における引用文献A、B、周知技術(引用文献C)には記載されておらず、本願発明1?15は、当業者であっても、原査定における引用文献A、B、及び周知技術に基づいて容易に発明できたものではない。
したがって、原査定を維持することはできない。

第8 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2017-02-13 
出願番号 特願2012-538764(P2012-538764)
審決分類 P 1 8・ 113- WY (H04N)
P 1 8・ 121- WY (H04N)
最終処分 成立  
前審関与審査官 畑中 高行  
特許庁審判長 清水 正一
特許庁審判官 渡辺 努
渡邊 聡
発明の名称 部分化を利用した適応的なストリーミング方法及びその装置  
代理人 実広 信哉  
代理人 崔 允辰  
代理人 木内 敬二  
代理人 阿部 達彦  

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