2023-013775

特願２０２１－１７０６５３「高帯域幅ネットワークでのデータのバッファリング」拒絶査定不服審判事件〔令和４年５月１８日出願公開、特開２０２２－７５５４０、請求項の数（２０）〕について、次のとおり審決する。

結 論 原査定を取り消す。 本願の発明は、特許すべきものとする。

理 由 第１ 手続の経緯 本願は、令和３年１０月１９日（パリ条約による優先権主張 ２０２０年１１月４日（以下「優先日」という。）米国）の外国語書面出願であって、その手続の経緯の概略は次のとおりである。 令和３年１０月１９日 翻訳文の提出 令和４年１１月 １日付け 拒絶理由通知書 令和５年 ２月２４日 意見書、手続補正書の提出 令和５年 ４月１９日付け 拒絶査定 令和５年 ８月１６日 審判請求書、手続補正書の提出 令和６年 ５月１０日付け 拒絶理由通知書 令和６年１１月１０日 意見書、手続補正書の提出 第２ 原査定の概要 原査定（令和５年４月１９日付け拒絶査定）の概要は、次のとおりである。 １ 理由１（新規性） 本願の請求項２１に係る発明は、以下の引用文献Ａに記載された発明であるから、特許法第２９条第１項第３号に該当し、特許を受けることができない。 ２ 理由２（進歩性） 本願の請求項２１に係る発明は、以下の引用文献Ａに基づいて、請求項１－４，９－１２，１５－１８，２０に係る発明は、以下の引用文献Ａ－Ｂに基づいて、請求項５，１３，１９に係る発明は、以下の引用文献Ａ－Ｃに基づいて、請求項６－７，１４に係る発明は、以下の引用文献Ａ－Ｂ，Ｄに基づいて、請求項８に係る発明は、以下の引用文献Ａ－Ｂ，Ｅに基づいて、その発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 ３ 引用文献等一覧 Ａ．特表２０１１－５２３２９８号公報 Ｂ．特開２０１２－８０４１７号公報 Ｃ．特表２００６－５０８６２１号公報 Ｄ．特表２０１５－５１５７８８号公報 Ｅ．特表２０２０－５１１８１１号公報 第３ 当審拒絶理由の概要 令和６年５月１０日付けで当審が通知した拒絶理由（以下「当審拒絶理由」という。）の概要は、次のとおりである。 １ 理由１（進歩性） 本願の請求項２１に係る発明は、以下の引用文献１に基づいて、請求項１－４，９－１２，１５－１８，２０に係る発明は、以下の引用文献１－２に基づいて、請求項５，１３，１９に係る発明は、以下の引用文献１－３に基づいて、請求項６－７，１４に係る発明は、以下の引用文献１－２，４に基づいて、請求項８に係る発明は、以下の引用文献１－２，５に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 ２ 引用文献等一覧 １．特表２０１１－５２３２９８号公報（原査定の引用文献Ａ） ２．特開２０１２－８０４１７号公報（原査定の引用文献Ｂ） ３．特表２００６－５０８６２１号公報（原査定の引用文献Ｃ） ４．米国特許出願公開第２０１３／０２６２６９４号明細書 ５．特表２０２０－５１１８１１号公報（原査定の引用文献Ｅ） 第４ 本願発明 本願の請求項１－２０に係る発明（以下、それぞれ「本願発明１」－「本願発明２０」という。）は、令和６年１１月１０日付けの手続補正で補正された特許請求の範囲の請求項１－２０に記載された事項により特定される発明であり、次のとおりの発明である。 「 【請求項１】 デバイスによって、第１のデータストリームに関連するデータの第１部分を第１ダウンロード速度でバッファにダウンロードする工程と、 バッファからデータの第１部分を出力する工程と、 デバイスは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断したことに応答して、 データの１つ以上の後続の部分にキャッシュを使用することを決定し、 同一の第１のデータストリームに関連するデータの第２部分をキャッシュにダウンロードする工程と、 バッファが空であると、判断すると、キャッシュからデータの第２部分を出力する工程とを含み、 データをダウンロードしているときにキャッシュを拡張することができ、データのダウンロードが切断された場合でもキャッシュはダウンロードされたデータを出力可能な方法。 【請求項２】 デバイスは第２ダウンロード速度でデータをダウンロードしていないと、判断すると、データの第３部分をバッファにダウンロードする工程をさらに含む、請求項１に記載の方法。 【請求項３】 データの第１及び第２部分は、第１データストリームに関連付けられたデータの複数の部分であり、 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断すると、データの複数の部分からデータの後続の部分をすべてキャッシュにダウンロードする工程をさらに含む、請求項１に記載の方法。 【請求項４】 データの複数の部分のすべてがキャッシュにダウンロードされたと、判断すると、 第１データストリームに少なくとも部分的に基づいて第２データストリームを識別し、 第２データストリームに関連付けられたデータの少なくとも一部をキャッシュにダウンロードする工程をさらに含む、請求項３に記載の方法。 【請求項５】 デバイスは第１ネットワークを使用してデータの第１部分をダウンロードし、 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断する工程は、デバイスは第２ネットワークを使用してデータのダウンロードを開始したと、判断する工程を含んでいる、請求項１に記載の方法。 【請求項６】 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断する工程は、第１ダウンロード速度と比較して、第２ダウンロード速度は所定の閾値を超えていると、判断する工程を含んでいる、請求項１に記載の方法。 【請求項７】 第２ダウンロード速度は所定の閾値を超えていると、判断する工程は、スライディングウィンドウを使用して第２ダウンロード速度を過去のダウンロード速度と比較する工程を含んでいる、請求項６に記載の方法。 【請求項８】 データの第２部分は第２ダウンロード速度でキャッシュにダウンロードされ、 データの第１部分及びデータの第２部分は両方とも複数のビットレートの第１ビットレートに関連付けられている、請求項１に記載の方法。 【請求項９】 コンピュータプログラムコードを含む非一時的なコンピュータ可読媒体であって、１つ以上のコンピュータプロセッサの動作によってコンピュータプログラムコードが実行された時に実行する動作は、 デバイスによって、第１のデータストリームに関連するデータの第１部分を第１ダウンロード速度でバッファにダウンロードする工程と、 バッファからデータの第１部分を出力する工程と、 デバイスは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断したことに応答して、 データの１つ以上の後続の部分にキャッシュを使用することを決定し、 同一の第１のデータストリームに関連するデータの第２部分をキャッシュにダウンロードする工程と、 バッファが空であると、判断すると、キャッシュからデータの第２部分を出力する工程とを含み、 データをダウンロードしているときにキャッシュを拡張することができ、データのダウンロードが切断された場合でもキャッシュはダウンロードされたデータを出力可能である、非一時的なコンピュータ可読媒体。 【請求項１０】 前記動作は、 デバイスは第２ダウンロード速度でデータをダウンロードしていないと、判断すると、データの第３部分をバッファにダウンロードする工程をさらに含んでいる、請求項９に記載のコンピュータ可読媒体。 【請求項１１】 データの第１及び第２部分は、第１データストリームに関連付けられたデータの複数の部分であり、 前記動作は、 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断すると、データの複数の部分からデータの後続の部分をすべてキャッシュにダウンロードする工程をさらに含んでいる、請求項９に記載のコンピュータ可読媒体。 【請求項１２】 前記動作は、 データの複数の部分のすべてがキャッシュにダウンロードされたと、判断すると、 第１データストリームに少なくとも部分的に基づいて第２データストリームを識別し、 第２データストリームに関連付けられたデータの少なくとも一部をキャッシュにダウンロードする工程をさらに含んでいる、請求項１１に記載のコンピュータ可読媒体。 【請求項１３】 デバイスは第１ネットワークを使用してデータの第１部分をダウンロードし、 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断する工程は、デバイスは第２ネットワークを使用してデータのダウンロードを開始したと、判断する工程を含んでいる、請求項９に記載のコンピュータ可読媒体。 【請求項１４】 デバイスは第２ダウンロード速度でデータをダウンロードしていると、判断する工程は、第１ダウンロード速度と比較して、第２ダウンロード速度は所定の閾値を超えていると、判断する工程を含んでいる、請求項９に記載のコンピュータ可読媒体。 【請求項１５】 １つ以上のコンピュータプロセッサと、 プログラムを含むストレージ媒体であって、１つ以上のコンピュータプロセッサによってプログラムが実行された時に実行する動作は、 システムによって、第１のデータストリームに関連するデータの第１部分を第１ダウンロード速度でバッファにダウンロードする工程と、 バッファからデータの第１部分を出力する工程と、 システムは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断したことに応答して、 データの１つ以上の後続の部分にキャッシュを使用することを決定し、 同一の第１のデータストリームに関連するデータの第２部分をキャッシュにダウンロードする工程と、 バッファが空であると、判断すると、キャッシュからデータの第２部分を出力する工程とを含み、 データをダウンロードしているときにキャッシュを拡張することができ、データのダウンロードが切断された場合でもキャッシュはダウンロードされたデータを出力可能である、ストレージ媒体とを備えるシステム。 【請求項１６】 前記動作は、 システムは第２ダウンロード速度でデータをダウンロードしていないと、判断すると、データの第３部分をバッファにダウンロードする工程をさらに含んでいる、請求項１５に記載のシステム。 【請求項１７】 データの第１及び第２部分は、第１データストリームに関連付けられたデータの複数の部分であり、 前記動作は、 システムは第２ダウンロード速度でデータをダウンロードしていると、判断すると、データの複数の部分からデータの後続の部分をすべてキャッシュにダウンロードする工程をさらに含んでいる、請求項１５に記載のシステム。 【請求項１８】 前記動作は、 データの複数の部分のすべてがキャッシュにダウンロードされたと、判断すると、 第１データストリームに少なくとも部分的に基づいて第２データストリームを識別し、 第２データストリームに関連付けられたデータの少なくとも一部をキャッシュにダウンロードする工程をさらに含んでいる、請求項１７に記載のシステム。 【請求項１９】 システムは第１ネットワークを使用してデータの第１部分をダウンロードし、 システムは第２ダウンロード速度でデータをダウンロードしていると、判断する工程は、システムは第２ネットワークを使用してデータのダウンロードを開始したと、判断する工程を含んでいる、請求項１５に記載のシステム。 【請求項２０】 メモリをさらに備え、 バッファはメモリの割り当てられた部分であり、 キャッシュはストレージ媒体の割り当てられた部分である、請求項１５に記載のシステム。」 なお、請求項１，９，１５には「ダウンロート」との記載があるが、通信の技術分野において「ダウンロート」は一般的な用語でなく、本願の明細書において「ダウンロート」の語は用いられておらず一貫して「ダウンロード」の語が用いられていることから、「ダウンロート」は「ダウンロード」の誤記と認め、本願発明１，９，１５を上記のように認定した。 第５ 引用文献、引用発明等 １ 引用文献１及び引用発明 （１）引用文献１の記載 当審拒絶理由に引用された引用文献１（原査定の引用文献Ａ）には、次の事項が記載されている（下線は当審による。以下同様。）。 ア 「【００１３】 １つまたは複数の実施形態によれば、移行モジュール１１８はストリーミング待ち行列１１６と対話し、第１のビットレートでのメディアのストリームから第２のビットレートでのメディアのストリームに移行できる。たとえば、および制限なく、第１のビットレートでのメディアのストリームが、６００ｋｂｐｓで符号化されたビデオクリップであることがあり、一方、第２のビットレートでのメディアのストリームが、９００ｋｂｐｓで符号化された同じクリップであることがある。したがって、質（ピクセル、解像度、音声圧縮等）は異なる可能性があるが、そのメディアのストリームのコンテンツは同じである可能性がある。移行モジュール１１８によって、ホスト１０２は、ユーザ１０８へのプレイバックのために中断されないまたは実質的に中断されない、クライアント１０４へのメディアのストリームを維持しながら、第１ビットレートでのメディアのストリームから第２のビットレートでのメディアのストリームへの連続ストリーミング移行を容易にさせることができる。」 イ 「【００２８】 図３は、本開示のいくつかの実施形態に従って帯域幅を監視し、ビットレートを選択する実例となるプロセス３００の流れ図である。プロセス３００の動作を説明する順序は、制限として解釈されることを意図されておらず、プロセスを実施するために、任意の数の説明されるブロックが任意の順序で、および／または並列で結合できる。説明のために、プロセス３００は、図１の環境１００を参照して説明する。 【００２９】 ３０２で、ホスト１０２は、ネットワーク１０６を経由してクライアント１０４との接続を開始する。いくつかの実施形態では、ホスト１０２は、以前の帯域幅決定を使用してネットワーク接続を分析することによって、または他の既知の技法によって等、接続の帯域幅を決定できる。３０４で、ホスト１０２は、クライアント１０４に常駐する初期バッファを満たすために第１ビットレートでメディアをストリーミングできる。上記に説明したように、ホスト１０２は単一のコンテンツのために多くの異なるビットレートで符号化されたメディアのストリームを含むことができる。ストリーミングモジュール１１４は、中断されないまたは実質的に中断されないメディアのストリームを維持しつつ、最高品質のメディアを提供するために、クライアント１０４へストリーミングのためのメディアの考えられる最高のビットレートを選択できる。いくつかの実施形態では、第１のメディアのストリームは、メディアの中断されないまたは実質的に中断されないストリーミングを保証するために、相対的に低いビットレート値を含むことがある。たとえば、ホスト１０２がそのメディアのストリームの４つの符号化ビットレートバージョンを有する場合、ホストは、動作３０４の間にクライアント１０４へ最低のまたは２番目に低いメディアのビットレートストリームを送信できる。初期バッファは、メディアの第１のストリームの時間またはデータサイズに基づいた所定の容量を含むことができる。いくつかの実施形態では、初期バッファは第１のメディアのストリームの２秒から５秒を含むことがある。一方、他の量のストリーミングメディアは、メディアのタイプ（たとえば音声および／またはビデオ）およびメディアの解像度（たとえば低解像度、高解像度等）に応じて初期のバッッファに記憶できる。 【００３０】 いくつかの実施形態では、ホスト１０２は３０４で、クライアント１０４とのネットワーク接続の帯域幅を計算できる。たとえば、ホスト１０２は、クライアント１０４が既知のデータサイズをもつ初期バッファを充填するためにどのくらいの時間を要するのかを決定できる。計算された帯域幅は、以下により詳細に説明する、第２のビットレートを選択するために使用できる理想的なビットレートを決定するために使用できる。 【００３１】 １つまたは複数の実施形態によれば、３０６で、第１のメディアのストリームがユーザ１０８に出力される。たとえば、クライアント１０４は、いったん初期バッファが容量まで充填されると、初期バッファ内に記憶されるデータを使用して第１のメディアのストリームを再生できる。いくつかの実施形態では、クライアント１０４は、初期バッファがいっぱいになるまでメディアを再生できず、それによってユーザがプレゼンテーションアプリケーション１２８上での中断されないまたは実質的に中断されないメディアのストリーミングを経験することを保証する。したがって、初期バッファのサイズは、いったんユーザがメディアのストリームの出力の受信を開始すると、ユーザ１０８によってメディアの中断されないまたは実質的に中断されないメディアのストリーミングの受信を保証するために選択される。 【００３２】 ３０８で、ホスト１０２は、クライアント１０４の上に常駐するより大きいバッファを充填するために、第１のビットレートでメディアをストリーミングできる。そのより大きいバッファは、初期バッファとしてデータを記憶するが、より大きい容量をもつ同じバッファであることがある。たとえば、初期バッファは、ストリームが動作３０６でいつ再生できるのかを示すための閾値決定であることがある。代わりに、そのより大きいバッファは、初期バッファとは異なるバッファであることもある。構成に関わらず、初期バッファおよびより大きいバッファは、クライアント１０４がユーザに中断されないまたは実質的に中断されないメディアのストリームを提供できるようにする。動作３０４と同様に、ホスト１０２は、３０８でクライアント１０４とのネットワーク接続の帯域幅を計算できる。プロセス３００のいくつかの実施形態では、帯域幅は、動作３０４、動作３０８または両方で計算できる。 【００３３】 ３１０で、ホスト１０２は、上記に説明したように、バッファ充填速度の測定に加えて、またはバッファ充填速度を測定することなく、システム帯域幅チェックを使用して帯域幅を周期的に計算できる。たとえば、ホスト１０２は、クライアント１０４に既知のデータサイズを有するデータのパケットを送信できる。クライアント１０４は、そのデータのパケットのそれぞれを受信すると、ホスト１０２にメッセージを返し、したがってホストがホストとクライアントの間のネットワーク接続の帯域幅を計算できるようにする。帯域幅を計算する他の既知の技法は、ホスト１０２によって使用され得る。帯域幅の計算は、周期的に、または所定のイベントの後に固定された間隔で発生できる。たとえば、帯域幅の計算は毎秒１回または複数回発生し、ネットワーク帯域幅を連続して監視できる。 【００３４】 １つまたは複数の実施形態によれば、ホスト１０２は、３１２でストリームのビットレートを加速するかどうかを決定する。ビットレートは、測定された帯域幅がメディアの使用可能なより高いビットレートストリームをサポートする場合、加速できる。３１２で決定されるようにより高いビットレートが実現可能である場合、ホスト１０２は、ステップ３１４でバッファ充填レベルのステータスを決定できる。たとえば、クライアント１０４はより大きいバッファのバッファ充填レベルを監視できる。より大きいバッファが低充填レベルまたは削減充填レベルを含む場合は、バッファは最終的に空で実行し、メディアのストリームの望ましくない中断を引き起すことがある。バッファ充填レベルが相対的に低い場合、プロセス３００は、３１６で、ビットレートを減速することを先制して決定できる。 【００３５】 いくつかの実施形態では、バッファ充填レベルは、ウォーターマークと呼ばれる所定の最小閾値を有することがある。ホスト１０２は、クライアント１０４を介してバッファ充填レベルを監視し、いつバッファ充填レベルがウォーターマークを下回るのかを判定する。いくつかの実施形態では、ヒューリスティックモジュール１２０がバッファの活動の統計分析を実施し、バッファの充填レベルがゼロバイトに近づく可能性があるかどうかを判定する。たとえば、クライアントは、バッファ充填レベルがウォーターマークを下回った後に、バッファの充填レベルの連続スナップショットとして周期的なサンプルを採取できる。バッファ充填レベルの減少を示す連続周期サンプルは、クライアント１０４への減速されたビットレートストリームのストリーミングを開始するためにホスト１０２を始動できる。しかし、統計分析が、バッファ充填レベルが空で動作しないと判定した場合、ビットレートは変化しないままとなることがあり、プロセス３００は、動作３０６において等、第１のビットレートでストリーミングを続行できる。 【００３６】 ３１８で、ホスト１０２は、バッファ１２６の内の１つで記憶し、初期バッファを充填するために、クライアント１０４への新しいビットレートを有するメディアをストリーミングできる。新しいビットレートは、他の考えられる要因の中でもホスト１０２とクライアント１０４の間のネットワーク接続の帯域幅に基づいて、図１のヒューリスティックモジュール１２０によって選択され得る。たとえば、ホスト１０２は、帯域幅がより高いビットレートをサポートできる（つまり、動作３１２での決定が「はい」である）のか、または帯域幅が現在のストリームビットレートをサポートできず、ビットレートを引き下げる必要がある（つまり、動作３１６での決定が「はい」である）のかを判定できる。 【００３７】 いくつかの実施形態では、ヒューリスティックモジュール１２０は、メディアの高品質を維持しつつ、ユーザ１０８へのメディアの中断されないまたは実質的に中断されないストリーミングを提供するために、ストリームにとって最も適した使用可能なビットレートを選択できる。たとえば、ホスト１０２は、Ａ、Ｂ、Ｃ、ＤおよびＥとして示される５つの異なるビットレートで符号化される１個のメディアを含むことがあり、その場合「Ａ」が最低のビットレートで、「Ｅ」が最高のビットレートである。クライアント１０４は、最初に３０６でビットレート「Ｃ」でストリームを再生できる。次に、バッファ充填レベルが、ウォーターマークを下回ることがある。ヒューリスティックモジュール１２０は、ビットレートが、動作３０４、３０８、および３１０の内の１つまたは複数で測定された帯域幅に基づいて、ビットレート「Ａ」またはビットレート「Ｂ」のどちらかに調整されるべきであると判定できる。いくつかの実施形態では、ヒューリスティックモジュール１２０は、新しいビットレートを選択するために使用できる理想的なビットレートを選択的に決定できる。その新しいビットレートは、使用できる次の大きさのビットレート（現在のビットレートよりも高いか、または低いかのどちらか）ではないことがあり、したがってホスト１０２は次に高いまたは次に低いビットレートを有さない別のビットレートにジャンプできる。 【００３８】 ３２０で、いったん初期バッファがいっぱいになると、クライアント１０４は新しいビットレートを有するメディアの新しいストリームを再生する。３２２で、３０８での動作と同様に、より大きいバッファがその新しいビットレートを有するストリーミングメディアで充填される。プロセス３００では、無期限に帯域幅の監視および動作３１０～３２２でのビットレートへの調整を続けることができる。」 ウ 「【図３】 ［図：0001418789000001.jpg］ 」 （２）引用発明 上記（１）から、特に下線を付した記載に着目すると、引用文献１には次の発明（以下「引用発明」という。）が記載されていると認められる。 「接続の帯域幅を決定でき、 クライアント１０４に常駐する初期バッファを満たすために第１ビットレートでメディアをストリーミングでき、 初期バッファ内に記憶されるデータを使用して第１のメディアのストリームを再生でき、 ホスト１０２は、クライアント１０４に既知のデータサイズを有するデータのパケットを送信でき、クライアント１０４は、そのデータのパケットのそれぞれを受信すると、ホスト１０２にメッセージを返し、したがってホストがホストとクライアントの間のネットワーク接続の帯域幅を計算でき、 ストリームのビットレートを加速するかどうかを決定し、ビットレートは、測定された帯域幅がメディアの使用可能なより高いビットレートストリームをサポートする場合、加速でき、 初期バッファを充填するために、クライアント１０４への新しいビットレートを有するメディアをストリーミングでき、 初期バッファがいっぱいになると、クライアント１０４は新しいビットレートを有するメディアの新しいストリームを再生する プロセス３００であって、 第１のビットレートでのメディアのストリームが、６００ｋｂｐｓで符号化されたビデオクリップであり、第２のビットレートでのメディアのストリームが、９００ｋｂｐｓで符号化された同じクリップである、 プロセス３００。」 ２ 引用文献２－５，Ｄ （１）引用文献２の記載 当審拒絶理由に引用された引用文献２（原査定の引用文献Ｂ）には、次の事項が記載されている。 ア 「【０１０２】 図２において、コンテンツ再生装置１００は、制御部１１０、プロトコル生成部１２０、送信部１３０、受信部１４０、受信データ処理部１５０、ＨＤＤ１６０、高速メモリ１７０及び再生部１８０を備えた、本発明に係る「ストリーミング再生装置」の一例である。」 イ 「【図２】 ［図：0001418789000002.jpg］ 」 ウ 「【０１１７】 ＜ストリーミング再生制御の詳細＞ 次に、図３を参照し、ストリーミング再生制御の詳細について説明する。ここに、図３は、ストリーミング再生制御のフローチャートである。尚、本実施例では、データ提供ノード３００が再生すべきコンテンツに係るコンテンツデータを全て保持しているものとする。 【０１１８】 図３において、制御部１１０は、準備処理（ステップＳ１００）、初期フラグメント処理（ステップＳ２００）、並列フラグメント処理（ステップＳ３００）及び受信後処理（ステップＳ４００）の順で順次各サブルーチンを実行する。受信後処理が終了すると、ストリーミング再生制御は終了する。 【０１１９】 ＜準備処理の詳細＞ 次に、図４を参照し、準備処理の詳細について説明する。ここに、図４は、準備処理のフローチャートである。 【０１２０】 図４において、制御部１１０は、ノード情報を取得する（ステップＳ１０１）。 【０１２１】 ここで、ノード情報とは、データ提供ノード３００のＩＰアドレス、保持するフラグメントの情報及び各種ハードウェア性能に関する情報（ＣＰＵの処理速度やメモリの情報）等を意味する。ノード情報は、データ提供ノード３００自身が保持しており、制御部１１０は、データ提供ノードに対してこれらの情報の提供を要求することができる。要求に応じてこれらの情報が提供されると、制御部１１０は、これらを順次受信データ解析部１５０を介して解析し、ノード情報としてＲＡＭに格納する。 【０１２２】 次に、制御部１１０は、コンテンツ情報を取得する（ステップＳ１０２）。本実施例において、コンテンツ情報とは、コンテンツの再生速度Ｐ（byte/sec）及びコンテンツサイズＮ（byte）であるとする。ステップＳ１０２は、コンテンツの状態を特定する旨の、本発明に係る「第３特定手段」の動作の一例である。尚、この際、制御部１１０は、送信部１３０を介して、コンテンツ情報の送信を促すリクエストを送信し、受信部１４０を介し、当該リクエストに応じてデータ転送ノード３００から送信されるコンテンツ情報を取得すると共に、その内容を受信データ解析部１５０により解析することによって、コンテンツ情報を取得し、ＲＡＭに格納する。 【０１２３】 次に、制御部１１０は、バッファ状態を取得する（ステップＳ１０３）。本実施例において、バッファ状態とは、ＨＤＤ１６０及び高速メモリ１７０の空き容量及び負荷状態（ビジー状態）であるとする。ステップＳ１０３は、第１及び第２記憶装置の状態を特定する旨の、本発明に係る「第２特定手段」の動作の一例である。尚、ＨＤＤ１６０及び高速メモリ１７０共にコンテンツ再生装置１００の構成要素であるので、制御部１１０は、コンテンツ再生装置１００の動作状態を制御する過程で常にこれらの情報を取得することができる。尚、先に述べた高速メモリ１７０の蓄積容量Ｍ（byte）とは、この段階でコンテンツの再生に供し得ると判断された空き容量であるとする。 【０１２４】 次に、制御部１１０は、ネットワーク状態を取得する（ステップＳ１０４）。本実施例において、ネットワーク状態とは、ネットワーク２００を介したコンテンツ再生装置１００とデータ提供ノード３００との通信状態を意味し、より具体的には、コンテンツ再生装置１００の受信帯域幅Ｂ（byte/sec）、データ提供ノード３００の送信帯域幅Ｃ（byte/sec）、ネットワーク２００の伝送遅延としてのＲＴＴ（Round Trip Time）及びＴＴＬ（Time To Live）であるとする。ステップＳ１０４は、ネットワークを介したデータ提供ノードとの間の通信状態を特定する旨の、本発明に係る「第１特定手段」の動作の一例である。 【０１２５】 尚、受信帯域幅Ｂ及び送信帯域幅Ｃは、コンテンツ再生装置１００及びデータ提供ノード３００における設定値である。また、ＲＴＴは、ＲＴＣＰ（Real-time Transport Control Protocol）のＳＲ（Sender Report）やＲＲ（Receiver Report）を利用する等して測定される。尚、各通信帯域幅については、ネットワーク２００を介してランダムにデータの送受信を行った際のデータの実際の伝送状態に基づいて適宜推定されてもよい。 【０１２６】 ステップＳ１０１乃至Ｓ１０４において必要な情報を取得すると、制御部１１０は、コンテンツデータのフラグメントサイズを決定する（ステップＳ１０５）。ここで、本実施例におけるフラグメントサイズの決定方法について説明する。制御部１１０は先ず、コンテンツデータを、フラグメントＮ０、フラグメントＮ１及びフラグメントＮ２の三種類のフラグメントに分割する。即ち、下記（１）式が成立する。尚、下記（１）式において、Ｎ０、Ｎ１及びＮ２は、各フラグメントのデータ量（bit）を表すものとする。尚、フラグメントＮ０とフラグメントＮ１とにより、本発明に係る「フラグメントＮａ」が、フラグメントＮ２により本発明に係るフラグメントＮｂが、夫々構成される。 【０１２７】 Ｎ＝Ｎ０＋Ｎ１＋Ｎ２・・・（１） 次に、制御部１１０は、フラグメントＮ０を下記（２）式に従って決定する。 【０１２８】 Ｎ０＝ｍｉｎ（Ｍ＋（Ｍ－Ｍ０）／（Ｂ－Ｐ）×Ｐ，Ｎ）・・・（２） ここで、（２）式右辺の左側の比較項のデータ量が、コンテンツサイズＮよりも大きければ、Ｎ０＝Ｎとなり、フラグメントＮ０とは即ちコンテンツデータそのものとなるが、通常、コンテンツサイズＮは、高速メモリ１７０の蓄積容量Ｍよりも十分に大きいため、Ｎ０は、（２）式右辺の左側の比較項となる。 【０１２９】 尚、本実施例では、データ提供ノード３００の送信帯域幅Ｃがコンテンツ再生装置１００の受信帯域幅Ｂよりも十分に大きいものとし、これらの間の最大の転送速度は、受信帯域幅Ｂに等しいものとする。また、フラグメントＮ０の転送速度は、最大転送速度である受信帯域幅Ｂに相当する速度に、フラグメントＮ１の転送速度はコンテンツの再生速度Ｐに、フラグメントＮ２の転送速度は受信帯域幅Ｂから再生速度Ｐに相当する帯域幅を除く残余の帯域幅（即ち、Ｂ－Ｐである）に相当する速度に、夫々予め決定されている。 【０１３０】 尚、データ提供ノード３００が単一のノードである場合、その送信帯域幅Ｃがコンテンツ再生ノード１００の受信帯域幅Ｂ未満であれば、当然ながらこれらの間のデータ伝送速度は、送信帯域幅Ｃに律束される。 【０１３１】 次に、制御部１１０は、フラグメントＮ１及びＮ２を下記（３）及び（４）式に従って決定する。 【０１３２】 Ｎ１＝（Ｎ－Ｎ０）／Ｂ×Ｐ・・・（３） Ｎ２＝（Ｎ－Ｎ０）／Ｂ×（Ｂ－Ｐ）・・・（４） 上記（３）式及び（４）式は、フラグメントＮ０を除いた残余のフラグメントを、フラグメントＮ１及びＮ２に割り当てられる受信帯域幅（即ち、転送速度である）の比率でフラグメントＮ１及びＮ２に割り当てることを意味している。別言すれば、本実施例において、フラグメントＮ１の取得完了タイミングと、フラグメントＮ２の取得完了タイミングとは、理想的には一致する。 【０１３３】 フラグメントサイズが決定されると、制御部１１０は、ＨＤＤ１６０及び高速メモリ１７０に然るべきバッファ領域を確保して（ステップＳ１０６）、準備処理を終了する。 【０１３４】 ＜初期フラグメント処理の詳細＞ 次に、図５を参照し、初期フラグメント処理の詳細について説明する。ここに、図５は、初期フラグメント処理のフローチャートである。 【０１３５】 始めに、制御部１１０は、データ提供ノード３００に対し、フラグメントＮ０を要求する（ステップＳ２０１）。この際、制御部１１０は、プロトコル生成部１２０を介して、先に決定されたフラグメントサイズをデータ提供ノード３００に伝達するプロトコルを生成し、送信部１３０を介してデータ提供ノード３００に送信する。このプロトコルには、フラグメントＮ０のデータサイズＮ０、コンテンツデータにおけるフラグメントＮ０の断片位置及びフラグメントＮ０を構成する各断片データの断片位置が記述されている。 【０１３６】 フラグメントＮ０の転送を要求すると、制御部１１０は、データ提供ノード３００から要求に応じたフラグメントＮ０の転送が開始されるのを待ち、データ転送単位たる一パケットに収まる断片データサイズ毎に受信部１４０に到着するフラグメントＮ０を受信する（ステップＳ２０２）。受信されたフラグメントＮ０は、高速メモリ１７０に順次蓄積される（ステップＳ２０３）。このフラグメントＮ０の受信及び高速メモリ１７０への蓄積に係る処理は、データ提供ノード３００からのフラグメントＮ０の転送が終了するまで継続する。 【０１３７】 尚、この段階でデータ提供ノード３００に要求されるフラグメントはフラグメントＮ０のみであるから、フラグメントＮ０は、最大転送速度、即ち、この場合、コンテンツ再生装置１００の受信帯域幅Ｂ全域を使用して取得される。 【０１３８】 一方、制御部１１０は、高速メモリ１７０へのフラグメントＮ０の蓄積と並行して、高速メモリ１７０に蓄積されたフラグメント量たるメモリキャッシュ量が、再生開始データ量Ｍ０よりも大きいか否かを判別する（ステップＳ２０４）。メモリキャッシュ量がＭ０以下である場合には（ステップＳ２０４：ＮＯ）、処理はステップＳ２０２に戻される。 【０１３９】 メモリキャッシュ量が再生開始データ量Ｍ０より大きい場合（ステップＳ２０４：ＹＥＳ）、制御部１１０は、高速メモリ１７０に蓄積されたフラグメントＮ０たるメモリキャッシュを、先頭データから順次読み出して再生する（ステップＳ２０５）。即ち、この段階で、コンテンツのストリーミング再生が開始される。 【０１４０】 コンテンツのストリーミング再生が開始されると、制御部１１０は、受信データ量がフラグメントＮ０のデータ量Ｎ０以上であるか否かを判別する（ステップＳ２０６）。受信データ量がＮ０未満であれば（ステップＳ２０６：ＮＯ）、処理はステップＳ２０２に戻され、受信データ量がＮ０以上であれば（ステップＳ２０６：ＹＥＳ）、即ち、高速メモリ１７０の蓄積容量Ｍに相当するフラグメントが蓄積されると、初期フラグメント処理は終了する。 【０１４１】 ＜並列フラグメント処理の詳細＞ 次に、図６を参照し、並列フラグメント処理の詳細について説明する。ここに、図６は、並列フラグメント処理のフローチャートである。 【０１４２】 始めに、制御部１１０は、データ提供ノード３００に対し、フラグメントＮ１及びＮ２を要求する（ステップＳ３０１）。この際、制御部１１０は、プロトコル生成部１２０を介して、先に決定されたフラグメントサイズをデータ提供ノード３００に伝達するプロトコルを生成し、送信部１３０を介してデータ提供ノード３００に送信する。このプロトコルには、フラグメントＮ１及びＮ２のデータサイズＮ１及びＮ２、コンテンツデータにおけるフラグメントＮ１及びＮ２の断片位置並びに各フラグメントにおける断片データの断片位置が記述されている。また、制御部１１０は、これと合わせて、フラグメントＮ１の転送速度をコンテンツの再生速度Ｐとし、フラグメントＮ２の転送速度を受信帯域幅Ｂから再生速度Ｐを除外した残余の帯域幅とする旨をデータ提供ノード３００に対し指示する。 【０１４３】 制御部１１０は、フラグメントの受信が開始されると（ステップＳ３０２）、受信データ解析部１５０を介して、受信したフラグメントがフラグメントＮ１であるかフラグメントＮ２であるかを判別する（ステップＳ３０３）。 【０１４４】 受信したフラグメントが、フラグメントＮ１である場合（ステップＳ３０３：ＹＥＳ）、制御部１１０は、フラグメントを高速メモリ１７０に蓄積する（ステップＳ３０４）と共に、高速メモリ１７０からキャッシュを読み出して、メモリキャッシュを再生速度Ｐで再生する（ステップＳ３０６）。即ち、高速メモリ１７０には、再生速度Ｐでフラグメントが読み出される一方で、再生速度Ｐでフラグメントが書き込まれる。従って、高速メモリ１７０に蓄積されているフラグメント量は、基本的に蓄積容量Ｍに維持される。 【０１４５】 一方、受信したフラグメントがフラグメントＮ２である場合（ステップＳ３０３：ＹＥＳ）、制御部１１０は、受信したフラグメントをＨＤＤ１６０に蓄積する（ステップＳ３０５）。 【０１４６】 ステップＳ３０５又はステップＳ３０７が実行されると、制御部１１０は、ストリーミング再生制御の開始時点以降に受信されたデータ量たる受信データ量が、コンテンツサイズＮ以上であるか否かを判別する（ステップＳ３０７）。尚、上記（１）式の関係に鑑みれば、ステップＳ３０７に係る判別処理は、フラグメントＮ１及びＮ２の取得が完了したか否かを意味する。 【０１４７】 受信データ量がＮ未満であれば（ステップＳ３０７：ＮＯ）、制御部１１０は、処理をステップＳ３０２に戻し、一連の処理を繰り返す。一方、受信データ量がＮ以上である場合（ステップＳ３０７：ＹＥＳ）、並列フラグメント処理は終了する。 【０１４８】 ＜受信後処理の詳細＞ 次に、図７を参照し、受信後処理の詳細について説明する。ここに、図７は、受信後処理のフローチャートである。 【０１４９】 図７において、制御部１１０は、ネットワーク２００を介したデータ提供ノード３００との通信回線を切断する（ステップＳ４０１）。続いて、高速メモリ１７０から蓄積されたフラグメントであるメモリキャッシュを読み出して再生する（ステップＳ４０２）。尚、ステップＳ４０２は、ステップＳ３０６から継続される処理である。ここで、ステップＳ４０２における再生処理は、ステップＳ３０６に係る処理と違い、新たなフラグメントの書き込みを伴わない。従って、ステップＳ４０２の実行過程においては、高速メモリ１７０のフラグメント蓄積量は、蓄積容量Ｍから再生速度Ｐで漸減する。 【０１５０】 制御部１１０は、メモリキャッシュが漸減した結果、メモリキャッシュ量がゼロとなったか否かを判別する（ステップＳ４０３）。メモリキャッシュ量がゼロでなければ（ステップＳ４０３：ＮＯ）、即ち、フラグメントＮ２よりも再生順序が早いフラグメントが未だ高速メモリ１７０に残存していれば、制御部１１０は、メモリキャッシュの再生を継続する。 【０１５１】 一方、メモリキャッシュ量がゼロとなった場合（ステップＳ４０３：ＹＥＳ）、制御部１１０は、ＨＤＤ１６０に蓄積されたフラグメントＮ２、即ち、ＨＤＤキャッシュを順次読み出して再生する（ステップＳ４０４）。ＨＤＤキャッシュの再生が開始されると、制御部１１０は、ＨＤＤキャッシュの再生が終了したか否かを判別し（ステップＳ４０５）、再生が終了していなければ（ステップＳ４０５：ＮＯ）、処理をステップＳ４０４に戻してフラグメントＮ２の再生を継続すると共に、再生が終了した場合には（ステップＳ４０５：ＹＥＳ）、受信後処理を終了する。」 エ 「【図３】 ［図：0001418789000003.jpg］ 【図４】 ［図：0001418789000004.jpg］ 【図５】 ［図：0001418789000005.jpg］ 【図６】 ［図：0001418789000006.jpg］ 【図７】 ［図：0001418789000007.jpg］ 」 （２）引用文献３の記載 当審拒絶理由に引用された引用文献３（原査定の引用文献Ｃ）には、次の事項が記載されている。 ア 「【００１７】 図面において、複数の図面を通じて同様の参照数字は類似又は同一の要素を表す。次に特に詳細に図面を参照する。まず図１を参照すると、第３世代セルラ・セル（３Ｇセル）内のシステムアーキテクチャ１０が、無線ネットワークで音声、データ、映像及びその他のサービスを統合するものについて例示的に示されている。システムアーキテクチャ１０は、本発明による方法とシステムを使用する例示的なＷＬＡＮ－ＵＭＴＳ環境として提示されている。当業者に知られているシステムアーキテクチャを構成する個々のブロックの構成要素の詳細は、本発明の理解に十分な程度にのみ詳細に説明される。 【００１８】 本発明は、ＵＭＴＳネットワーク１２とＷＬＡＮ無線ネットワーク１４について例示的に説明される（例えばＩＥＥＥ８０２．１１とＨＩＰＥＲＬＡＮ２規格がこれらのネットワークにより使用されてもよい）。ＵＭＴＳ移動体ネットワーク１２（例えば第３世代（３Ｇ）ネットワーク）は、ノードＢ１１と無線ネットワークコントローラ（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）９とを有する無線アクセスネットワーク（ＲＡＮ：ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）８と通信する。ＷＬＡＮ（１４）は、ＧＧＳＮ（ＧＰＲＳゲートウェイ・サポート・ノード（ＧＰＲＳ Ｇａｔｅｗａｙ Ｓｕｐｐｏｒｔ Ｎｏｄｅ））２４を介してインターネット７を通じてＵＭＴＳネットワーク（１２）に接続されてもよい。当業者にわかる通り、その他の接続も可能である。次にＲＡＮ８は、コアネットワーク（ＣＮ：Ｃｏｒｅ Ｎｅｔｗｏｒｋ）１３に接続される。コアネットワーク（ＣＮ）１３は、ＳＧＳＮ（サービスＧＰＲＳサポート・ノード（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ））２８のようなパケットベースのサービスと、回線ベースのサービスと、ＭＳＣ（移動体交換センタ（Ｍｉｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｅｒ））２１を通じたアクセスと、ＧＧＳＮ（ゲートウェイＧＰＲＳサポート・ノード（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ））２４のような他のＰＬＭＮ（公衆陸上無線ネットワーク（Ｐｕｂｌｉｃ Ｍｏｂｉｌｅ Ｌａｎｄ Ｎｅｔｗｏｒｋ））へのゲートウェイとを有する。コアネットワーク１３はまた、公衆電話交換ネットワーク（ＰＳＴＮ）５及びインターネット７との接続／インタフェースをサポートする。 【００１９】 他の構成要素がＵＭＴＳネットワークに含まれてもよい。例えば、移動局（ＭＳ）４０のホームロケーションを格納するホームロケーションレジスタ（ＨＬＲ：Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）５０が備えられてもよい。本発明により、ネットワーク１２（例えばＰＬＭＮ）が、ネットワークモジュール２５を使用することにより、インターネットを通じて無線ＬＡＮ１４とインタフェース接続される。そのネットワークモジュール２５は、ＷＬＡＮでのダウンロード用に格納される利用可能なコンテンツについてユーザに警告するために使用されてもよい。ＭＳ４０はアクセスポイント３０で接続し、ＭＳ４０は無線アクセスネットワーク間をローミングしてもよい。 【００２０】 ネットワークモジュール２５は、ＷＬＡＮ内にいるユーザにダウンロードされることがあるコンテンツを格納するメモリを有する。ネットワークモジュール２５は、ネットワーク間のインタフェースとしてセルラネットワークのセル内のＷＬＡＮで提供されてもよく、又はネットワーク間に分散されてもよい。モジュール２５は、ＷＬＡＮで利用可能なコンテンツについてユーザに警告し、ユーザがセルラネットワークへのアクセスを有する時にコンテンツに対して行われたユーザ要求を処理するために使用されてもよい。ネットワークモジュール２５は、ユーザがＷＬＡＮの受信可能領域にいる時に、ＷＬＡＮを通じてユーザにコンテンツを配信するために使用されてもよい。ネットワークモジュール２５は、相互接続機能（ＩＷＦ：ｉｎｔｅｒｗｏｒｋｉｎｇ ｆｕｎｃｔｉｏｎ）に実装されてもよく、又は相互接続機能として実装されてもよい。ネットワークモジュール２５は、スタンドアローンユニットとして実装されてもよく、又はサービス提供するネットワーク間に分散されてもよい。 【００２１】 一実施例において、モジュール２５は、ＷＬＡＮ相互接続機能（ＩＷＦ）を有してもよく、そのＷＬＡＮ相互接続機能は、移動体がＷＬＡＮアクセスポイント（ＡＰ）により認証されると移動体の存在を検出し、後述のパラメータに基づいて移動体用に保留しているコンテンツをダウンロードする。ＩＷＦの役割は、ＷＬＡＮとＵＭＴＳネットワークとの間の結合に基づく。ＩＷＦがＵＭＴＳのコアネットワークに接続する密結合では、ＩＷＦはＵＭＴＳセキュリティ機構を再利用するが、ＩＷＦがインターネットに直接接続する疎結合では、インターネットで暗号化パラメータを提供するために、ＩＷＦはＧＧＳＮとのセキュリティ機構を必要とする。ＩＷＦはまた、ＰＬＭＮにより提示されたパラメータと移動体により提供されたパラメータを抽出し、正確な移動体にコンテンツのダウンロードを容易にするために、適応レイヤを必要とする。 【００２２】 ＩＷＦとしてのモジュール２５で本発明を例示的に説明するが、モジュール２５は、ＩＷＦについてここに記載されている全ての機能と別のユニットとして実装されてもよい。 【００２３】 ＷＬＡＮ１４は、無線ユーザ装置（ＵＥ）又は移動局（ＭＳ）４０がＷＬＡＮにアクセス及び使用することを可能にするように提供された複数のアクセスポイント３０を有する。本発明により、モジュール２５はＵＭＴＳネットワーク１２と相互作用し、ＷＬＡＮ環境とインタフェース接続する。モジュール２５は、データパケットプロトコル及びネットワーク（例えばＷＬＡＮやＵＭＴＳ）間の他の通信を解釈するハードウェア及びソフトウェアを有する。 ［ＵＭＴＳ－ＷＬＡＮ相互接続］ 本発明は、ＵＭＴＳ及びＷＬＡＮ（８０２．１１とＨＩＰＥＲＬＡＮ２）無線ネットワーク環境で使用されてもよい。前述の通り、３Ｇ ＵＭＴＳ移動体は、ノードＢ１１と無線アクセスコントローラ（ＲＮＣ）９とを有する無線アクセスネットワーク（ＲＡＮ）８と通信する。次にＲＡＮ８は、ＳＧＳＮ２８（パケットベースのサービス）と、ＭＳＣ（移動体交換センタ）２１（回線ベースのサービス）と、ＧＧＳＮ２４（他のＰＬＭＮへのゲートウェイ）とを有するコアネットワーク（ＣＮ）１３に接続される。ＵＭＴＳネットワークの欠点は、ＷＬＡＮと比較すると、高コストのスペクトルと低データレートである。従って、ＵＭＴＳ無線リソースを節約し、ＵＭＴＳ ＲＡＮの効率を高めるために、ＵＭＴＳを無許可の帯域の高データレートのＷＬＡＮ（ＩＥＥＥ８０２．１１やＥＴＳＩ Ｈｉｐｅｒｌａｎ２等）と交換することが有利である。これを達成するために、移動体端末は、ＵＭＴＳ ＵＥとＷＬＡＮ ＭＳのプロトコルスタックを有する二重スタックを有する必要がある。二重プロトコルスタックにより、ＷＬＡＮプロトコルとＵＭＴＳプロトコルとの間のインタフェースがＷＬＡＮとＵＭＴＳとの間のシームレスな通信を提供することが可能になる。この二重プロトコルスタックは、移動局がＷＬＡＮでＷＬＡＮ ＭＳスタックを使用し、ＵＭＴＳでＵＭＴＳ ＵＥスタックを使用するように実装されてもよい。」 イ 「【図１】 ［図：0001418789000008.jpg］ 」 （３）引用文献４の記載 当審拒絶理由に引用された引用文献４には、次の事項が記載されている。 ア 「[0027] FIG. 2 illustrates an example buffer configuration and data flow among buffers of an application and decoder of a device (e.g., client device). As shown, audio buffer (BA) 202, video buffer (BV) 204, multiplex 206, and multiplexed buffer (BM) 208 may reside in application 200, in some embodiments. Also as shown, decoder buffer (BD) 212 and decode 214 may reside in decoder 210, in some embodiments. Table 1 includes definitions and terms used herein. TABLE 1 Parameters Definition BA The buffer for storing audio fragments BV The buffer for storing video fragments BM The multiplexed buffer used for stored data after multiplexing data from BA and BV BD The decoder buffer BXTh The threshold of BX to request more data from the upstream buffer or the network. FX The size of a fragment in bits r The rate of movement of data from BM to BD in bits/second (bps) fX The rate at which BX is filled up from the network in bps bX The bitrate (Bx)Max The maximum number of bits in buffer Bx during a fragment arrival time J The network jitter handling capacity, where the network jitter is the variation in network bandwidth, which may be the number of seconds during which data does not arrive for an active HTTP request for media. L The live latency, or the difference in time between the event and the playback of the frame that captures that event. S The switching latency, or the difference in time between when the switch was issued and the playback of the first frame of the switched stream.」 （当審仮訳： ［００２７］図２は、アプリケーションのバッファとデバイス（例えば、クライアントデバイス）のデコーダとの間の例示的なバッファ構成及びデータフローを示す。示されるように、オーディオバッファ（ＢＡ）２０２、ビデオバッファ（ＢＶ）２０４、多重化２０６、及び多重化バッファ（ＢＭ）２０８は、いくつかの実施形態では、アプリケーション２００に常駐することができる。また、示されるように、デコーダバッファ（ＢＤ）２１２及びデコード２１４は、いくつかの実施形態において、デコーダ２１０に常駐し得る。表１は、本明細書で使用される定義及び用語を含む。 表１ パラメータ 定義 ＢＡ オーディオフラグメントを格納するバッファ ＢＶ ビデオフラグメント格納用バッファ ＢＭ ＢＡ及びＢＶからのデータを多重化した後、蓄積データに使用される多重化バッファ ＢＤ デコーダバッファ ＢＸＴｈ 上流バッファ又はネットワークにさらなるデータを要求するためのＢＸの閾値。 ＦＸ フラグメントのサイズ（ビット） ｒ ＢＭからＢＤへのデータの移動速度（ビット／秒（ｂｐｓ）） ｆＸ ＢＸがネットワークから充填されるレート（ｂｐｓ） ｂＸ ビットレート (Ｂｘ)Ｍax フラグメント到着時間中のバッファＢｘ内の最大ビット数 Ｊ ネットワークジッター処理能力、ここでネットワークジッターはネットワーク帯域幅の変動であり、メディアに対するアクティブなＨＴＴＰリクエストに対してデータが到着しない秒数であり得る。 Ｌ ライブ・レイテンシー、又はイベントが発生してからそのイベントをキャプチャしたフレームが再生されるまでの時間差。 Ｓ スイッチング・レイテンシー、又はスイッチが発行されてからスイッチングされたストリームの最初のフレームが再生されるまでの時間差。） イ 「 ［図：0001418789000009.jpg］ 」 ウ 「[0052] In multi bitrate streaming, there may be multiple bitrates of the content available. If the fill rate is higher than the bitrate, there may be a residual amount of data in RM and BD after receiving one fragment completely. To analyze how fast the past fragments were downloaded, a sliding window of (BD)Δ can be maintained to make the decision of switching up or down. Each time the fill rate is higher than the corresponding bitrate, BD may go up by (BD)Δ. If it is consistently high for the sliding window, a decision to switch up can be made. Similarly, if (BD)Δ is low for a series of past fragment downloads in the sliding window, a decision to switch down can be made.」 （当審仮訳： ［００５２］マルチビットレートストリーミングでは、コンテンツのビットレートが複数存在する場合がある。充填レートがビットレートより高い場合、１つのフラグメントを完全に受信した後、ＲＭとＢＤにデータ量が残ることがある。過去のフラグメントのダウンロード速度を分析するため、（ＢＤ）Δのスライディング・ウィンドウを維持し、切上げ又は切下げの判断を行うことができる。充填レートが対応するビットレートより高くなるたびに、ＢＤは（ＢＤ）Δだけ上昇する。スライディング・ウィンドウの間、常に高い場合、切上げの決定ができる。同様に、（ＢＤ）Δがスライディング・ウィンドウ内の一連の過去のフラグメントダウンロードにおいて低い場合、切下げの決定ができる。） （４）引用文献５の記載 当審拒絶理由に引用された引用文献５（原査定の引用文献Ｅ）には、次の事項が記載されている。 ア 「【０００６】 コンテンツ配信ネットワーク（ＣＤＮ）は、世界中の種々の地点における異なる物理的データセンタで展開される、プロキシサーバのネットワークを指す。ＣＤＮは、コンテンツ配信のための増加された性能および可用時間を提供するために利用されることができる。本増加された性能は、世界中で同一コンテンツのコピーを伴う複数のサーバを有することによって達成され得る。ユーザが、コンテンツにアクセスすることを試みると、物理的により近いまたは少なくともより短い経由デジタルルーティングを有する、ＣＤＮが、より遠く離れた通常サーバより高速でコンテンツを配信することができる。静的ストリーミング状況では、これは、ストリーミングされるコンテンツが変化しないため、理想的である。しかしながら、ライブストリーミング状況では、理想的には、待ち時間が、コンテンツが最初にエンコードされ、次いで、ＣＤＮネットワークに配布される際に考慮される。加えて、同一コンテンツの複数のコピーを有することは、１つのサーバが、オフラインとなる、またはそうでなければコンテンツを配信する能力を損なわせ得る重いトラフィックを被るとき、コンテンツが利用不可能であろう尤度を減少させる。」 イ 「【００４７】 （適応ＣＤＮ切替システムにおけるコンテンツビットレートレベルの向上） 典型的ストリーミング用途では、単一ＣＤＮのみが、ストリーミングすべきコンテンツのセグメントを決定および選択するときに考慮される。しかしながら、本方法は、他のＣＤＮプロバイダシステム上で利用可能なより高い品質またはより高速でアクセスされるコンテンツの可能性として考えられる可用性を考慮しない。適応ＣＤＮ切替システムは、より高い帯域幅をユーザに提供する代替ＣＤＮシステムにおけるコンテンツのセグメントにアクセスすることによって、ストリーミングされるコンテンツの品質を増加させるために利用されることができる。 【００４８】 本発明のある実施形態による、適応ＣＤＮ切替システムにおいて使用するためのコンテンツビットレートレベルを増加させるためのプロセスが、図６に示される。プロセス６００は、ダウンロードするために利用可能な利用可能なコンテンツの最高ビットレートレベルを決定してもよい（６０２）。代替ＣＤＮ検索が生じるべきであるかどうかを決定するためのある条件の評価（６０４）が、行われてもよい。本発明のある実施形態では、これらの条件は、限定ではないが、最高ビットレートストリーミングが生じてから必要な持続時間および十分なバッファの量を有することを含んでもよい。条件が満たされる場合、代替ＣＤＮプロバイダの検索（６０６）が、生じ得る。コンテンツセグメントが、次いで、代替ＣＤＮプロバイダからダウンロードされてもよい（６０８）。いくつかの実施形態では、ダウンロードされたコンテンツのビットレートレベルは、現在のＣＤＮからダウンロードされたコンテンツの現在のビットレートレベルと同一であって、現在のＣＤＮからダウンロードされたコンテンツと代替ＣＤＮとの間の顕著な切替を回避する。プロセス６００は、次いで、代替ＣＤＮプロバイダからダウンロードされたコンテンツの瞬間帯域幅を現在のＣＤＮプロバイダから提供されている帯域幅に対して評価してもよい（６１０）。必要な場合、代替ＣＤＮプロバイダへの切替（６１２）が、より高いビットレートレベルでエンコードされたコンテンツのダウンロードを可能にするために生じ得、これは、再生デバイスによってダウンロードおよび再生されるとき、より高い知覚品質のコンテンツに変換され得る。」 ウ 「【図６】 ［図：0001418789000010.jpg］ 」 （５）引用文献Ｄの記載 原査定の拒絶の理由に引用された引用文献Ｄには、次の事項が記載されている。 ア 「【００２１】 本発明の方法は、バッファの枯渇のリスクを低減しつつネットワーク帯域幅の使用をより最適なものとするのに役立ちうる先進的なプロセスを提供する。予測アダプティブメディアストリーミングと呼ぶことのできるこの方法には、メディアの近づきつつある一連のセクションのそれぞれ（例えば、時間間隔（「時間限界」）またはデータ量間隔（「データ限界」））について、各ＶＢＲバージョンのどのビットレートがそのセクションにあるかを予測する過程と、およびそれらの予測ビットレートをネットワーク帯域幅との比較ポイントとして使用して、クライアントにストリーム配信されるＶＢＲバージョンが選択されるようにする過程とが関与しうる。このプロセスは、メディア全体にわたり連続的なビットレート予測が提供されるように、また近づきつつあるビットレートの最新の予測をストリーム配信されるＶＢＲバージョンの選択の基準として使用するように、スライディングウィンドウベースで（または代替的には、非重複（すなわち、相互排他的な）ウィンドウで）有利に反復されうる。 【００２２】 図４は、各ＶＢＲバージョンの近づきつつあるビットレートが、３０秒または５メガバイトのスライディングウィンドウ全体について、スライディングウィンドウに基づき近づきつつある平均ビットレートとして毎秒１回予測される、このプロセスの例の説明に役立つ。図４のグラフで、予測ビットレートは、各ＶＢＲバージョンを通して点線でプロットされており、バージョン毎のビットレート曲線を効果的に円滑なものとしている。任意の一時点において、ＶＢＲバージョン毎のこの予測ビットレートは、そのＶＢＲバージョンでのメディアの近づきつつあるウィンドウについての平均ビットレートを表すものであり、よって、メディアコンテンツ全体にわたり近づきつつある平均ビットレートの変化に伴い、予測ビットレートはメディアコンテンツ全体で変化する。」 イ 「【図４】 ［図：0001418789000011.jpg］ 」 第６ 対比及び判断 １ 本願発明１について （１）対比 本願発明１と引用発明を対比すると、次のことがいえる。 ア 引用発明の「クライアント１０４」は、本願発明１の「デバイス」に相当する。 引用発明において「決定」された「接続の帯域幅」は、本願発明１の「第１ダウンロード速度」に相当する。 引用発明の「初期バッファ」は、本願発明１の「バッファ」に相当する。 引用発明における「初期バッファを満たすため」の「ストリーミング」は、ストリーミングしたデータを初期バッファに記憶させるものと認められ、「決定」された「接続の帯域幅」で行われることが明らかであるから、本願発明１における「第１ダウンロード速度でバッファにダウンロードする」ことに相当する。 引用発明の「第１ビットレート」の「メディア」は、本願発明１の「データの第１部分」に相当する。 引用発明の「第１のビットレートでのメディアのストリーム」は、「第１のビットレート」が「第１ビットレート」を指すことは明らかであり、「第１ビットレート」の「メディア」と当然関連するから、本願発明１の「第１のデータストリーム」に相当する。 したがって、引用発明における「クライアント１０４に常駐する初期バッファを満たすために第１ビットレートでメディアをストリーミング」することは、本願発明１における「デバイスによって、第１のデータストリームに関連するデータの第１部分を第１ダウンロード速度でバッファにダウンロードする工程」に相当する。 イ 引用発明の「初期バッファ内に記憶されるデータ」は、上記アを踏まえると、第１ビットレートでメディアをストリーミングして初期バッファを満たすことにより、初期バッファに記憶されるに至ったものと認められるから、「第１ビットレート」の「メディア」と同一のものであり、本願発明１の「データの第１部分」に相当する。 したがって、引用発明における「初期バッファ内に記憶されるデータを使用して第１のメディアのストリームを再生」することは、本願発明１における「バッファからデータの第１部分を出力する工程」に相当する。 ウ 引用発明の「ホストとクライアントの間のネットワーク接続の帯域幅」は、周期的に計算されるものであり、変動があることを前提に当該周期的な計算が行われているものと認められるから、「決定」された「接続の帯域幅」から変動があった場合において、本願発明１の「第２ダウンロード速度」に相当する。 引用発明の「計算」は、「ホスト１０２」が「クライアント１０４に既知のデータサイズを有するデータのパケットを送信」し、「そのデータのパケット」を「受信」した「クライアント１０４」から返ってくる「メッセージ」を受信することによりなされており、クライアント１０４が既知のデータサイズを有するデータを受信するのに要する時間に基づいて「ホストとクライアントの間のネットワーク接続の帯域幅」を求めるものと認められるから、本願発明１における「デバイスは」「第２ダウンロード速度でデータをダウンロードしていると判断」することに相当する。 引用発明における「測定された帯域幅がメディアの使用可能なより高いビットレートストリームをサポートする場合」は、第１のビットレートでのメディアのストリームより高いビットレートストリームを測定された帯域幅がサポートする場合を指すことが明らかであり、上記アを踏まえると、「決定」された「接続の帯域幅」よりも「ホストとクライアントの間のネットワーク接続の帯域幅」が広い場合を指すものと認められるから、本願発明１における「第２ダウンロード速度」が「第１ダウンロード速度よりも速い」場合に相当する。 したがって、引用発明における「ホストとクライアントの間のネットワーク接続の帯域幅を計算」して「測定された帯域幅がメディアの使用可能なより高いビットレートストリームをサポートする場合」に「ストリームのビットレートを加速する」と「決定」することは、本願発明１における「デバイスは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断」することに相当する。 エ 引用発明の「新しいビットレートを有するメディア」は、本願発明１の「データの第２部分」に相当する。 引用発明の「第２のビットレートでのメディアのストリーム」は、「第２のビットレート」が「新しいビットレート」であることが明らかであり、「第１のビットレートでのメディアのストリーム」に係る「ビデオクリップ」と「同じクリップ」に係るものであるから、上記アを踏まえると、本願発明１の「同一の第１のデータストリーム」に相当する。 引用発明の「初期バッファを充填するため」の「ストリーミング」は、ストリーミングしたデータを初期バッファに記憶させるものと認められるから、本願発明１における「キャッシュにダウンロードする」ことと、「ダウンロードする」という限度で一致する。 してみれば、引用発明における「初期バッファを充填するために、クライアント１０４への新しいビットレートを有するメディアをストリーミング」することは、本願発明１における「データの１つ以上の後続の部分にキャッシュを使用することを決定し、同一の第１のデータストリームに関連するデータの第２部分をバッファにダウンロードする工程」と、「同一の第１のデータストリームに関連するデータの第２部分を」「ダウンロードする工程」である点で一致し、後記（２）イの点で相違する。 オ 引用発明における「新しいビットレートを有するメディアの新しいストリームを再生する」ことは、上記エを踏まえると、本願発明１の「バッファが空であると、判断すると、キャッシュからデータの第２部分を出力する工程」と、「データの第２部分を出力する工程」である点で一致し、後記（２）ウの点で相違する。 （２）一致点及び相違点 上記（１）から、本願発明１と引用発明の間には、次のアのとおりの一致点及びイ－エのとおりの相違点があるといえる。 ア 一致点 「デバイスによって、第１のデータストリームに関連するデータの第１部分を第１ダウンロード速度でバッファにダウンロードする工程と、 バッファからデータの第１部分を出力する工程と、 デバイスは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断したことに応答して、 同一の第１のデータストリームに関連するデータの第２部分をダウンロードする工程と、 データの第２部分を出力する工程とを含む、 方法。」 イ 相違点１ 上記「デバイスは第１ダウンロード速度よりも速い第２ダウンロード速度でデータをダウンロードしていると判断したことに応答して」「同一の第１のデータストリームに関連するデータの第２部分をダウンロードする工程」において、本願発明１では、データの１つ以上の後続の部分にキャッシュを使用することを決定し、データの第２部分をキャッシュにダウンロードしているのに対し、引用発明では、キャッシュを使用することを決定しておらず、キャッシュでなく初期バッファを充填している点。 ウ 相違点２ 上記「データの第２部分を出力する工程」において、本願発明１では、バッファが空であると、判断すると、キャッシュから出力をしているのに対し、引用発明では、初期バッファから再生している点。 エ 相違点３ 本願発明１では、データをダウンロードしているときにキャッシュを拡張することができ、データのダウンロードが切断された場合でもキャッシュはダウンロードされたデータを出力可能であるのに対し、引用発明１では、データをダウンロードしているときにキャッシュを拡張することも、データのダウンロードが切断された場合にキャッシュがダウンロードされたデータを出力することも特定されていない点。 （３）相違点についての判断 事案に鑑みて、相違点３について先に検討する。 引用文献２には、上記第５の２（１）に摘記したとおり、準備処理において、コンテンツデータを、フラグメントＮ０、フラグメントＮ１及びフラグメントＮ２の三種類のフラグメントに分割し、初期フラグメント処理において、フラグメントＮ０は、高速メモリ１７０に順次蓄積され、並列フラグメント処理において、受信したフラグメントがフラグメントＮ２である場合、受信したフラグメントをＨＤＤ１６０に蓄積し、受信後処理において、通信回線を切断し、メモリキャッシュ量がゼロとなった場合、ＨＤＤ１６０に蓄積されたフラグメントＮ２を順次読み出して再生するストリーミング再生制御が記載されている。しかしながら、引用文献２には、フラグメントを受信しているときにＨＤＤ１６０を拡張することは記載されておらず、本願発明１における「同一の第１のデータストリームに関連するデータの第２部分をキャッシュにダウンロードする」場合に「データをダウンロードしているときにキャッシュを拡張する」構成（以下「本件構成」という。）は、引用文献２に記載されていない。 また、本件構成は、引用文献３－５，Ｄにも記載されておらず、本願の優先日前における周知技術であったとも認められない。 したがって、相違点１及び２について判断するまでもなく、本願発明１は、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 ２ 本願発明２－８について 本願発明２－８は、本願発明１を減縮したものであり、本願発明１と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 ３ 本願発明９について 本願発明９は、本願発明１に対応する非一時的なコンピュータ可読媒体の発明であり、本件構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 ４ 本願発明１０－１４について 本願発明１０－１４は、本願発明９を減縮したものであり、本願発明９と同一の構成を備えるものであるから、本願発明９と同じ理由により、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 ５ 本願発明１５について 本願発明１５は、本願発明１に対応するシステムの発明であり、本件構成に対応する構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 ６ 本願発明１６－２０について 本願発明１６－２０は、本願発明１５を減縮したものであり、本願発明１５と同一の構成を備えるものであるから、本願発明１５と同じ理由により、当業者であっても、引用発明、引用文献２－５，Ｄに記載の発明に基づいて、容易に発明をすることができたものとはいえない。 第７ 原査定について 上記第６のとおり、本願発明１－２０は、原査定において引用された引用文献Ａに記載された発明でなく、原査定において引用された引用文献Ａ－Ｅに基づいて当業者が容易に発明をすることができたものでもない。 したがって、原査定を維持することはできない。 第８ 当審拒絶理由について 上記第６のとおり、本願発明１－２０は、当業者であっても、当審拒絶理由に引用された引用文献１－５に記載の発明に基づいて、容易に発明をすることができたものではない。 したがって、当審拒絶理由は解消した。 第９ むすび 以上のとおり、原査定の理由及び当審拒絶理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。