ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04N |
---|---|
管理番号 | 1361187 |
審判番号 | 不服2018-7486 |
総通号数 | 245 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2020-05-29 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2018-06-01 |
確定日 | 2020-03-23 |
事件の表示 | 特願2016- 82623「アダプティブ・ストリーミングのマルチパス配信」拒絶査定不服審判事件〔平成28年 9月 8日出願公開、特開2016-165134〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1 手続の経緯及び本願発明 1 手続の経緯 本件出願は、2011年(平成23年)2月16日(パリ条約による優先権主張外国庁受理2010年2月19日、欧州特許庁)を国際出願日とする特願2012-553297号の一部を平成28年4月18日に新たな特許出願としたものであって、その手続の経緯は、以下のとおりである。 平成28年 4月22日:手続補正 平成29年 4月18日:拒絶理由の通知 平成29年 7月21日:手続補正、意見書 平成30年 1月26日:拒絶査定 平成30年 2月 6日:拒絶査定の謄本の送達 平成30年 6月 1日:拒絶査定不服審判の請求 2 本願発明 本願の請求項1?15に係る発明は、平成29年7月21日付け手続補正により補正された特許請求の範囲の記載からみて、その特許請求の範囲の請求項1?15に記載した事項により特定されるとおりのものであるところ、請求項1に係る発明(以下「本願発明」という。)は、次のとおりのものである。 (本願発明) (A)少なくとも第1および第2の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法であり、 (A-1)前記少なくとも第1および第2の通信インタフェースのそれぞれが通信アドレスを有し、 (A-2)前記コンテンツが、それぞれが通信アドレスを有する少なくとも第1および第2のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能であり、 (A-3)第1の経路が、前記第1の通信インタフェースの通信アドレスおよび前記第1のサーバ通信インタフェースのアドレスによって識別され、 (A-4)少なくとも第2の経路が、前記第2の通信インタフェースの通信アドレスおよび前記少なくとも第2のサーバ通信インタフェースのアドレスによって識別され、 (A-5)前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも2つのバージョンで利用可能であり、 (A-6)前記少なくとも2つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、 (A-7)チャンクが、時間指標iおよび前記対応ビット・レートのうちの1つによって識別され、 (A-8)前記コンテンツが、前記第1および前記少なくとも第2の経路を介して前記クライアント装置から同時にアクセス可能である方法であって、 (B)前記クライアント装置において、前記第1の経路上の第1の利用可能なビット・レートおよび前記少なくとも第2の経路上の少なくとも第2の利用可能なビット・レートを決定するステップ(S1)と、 (C)前記決定した第1の利用可能なビット・レートおよび前記決定した少なくとも第2の利用可能なビット・レートから、前記対応ビット・レートの中から要求ビット・レートを決定するステップ(S2)と、 (D)前記時間指標iおよび前記決定した要求ビット・レートによって識別されるチャンクの第1の部分を受信するための第1の要求を前記第1の経路を介して送信し、前記時間指標iによって識別される前記チャンクの少なくとも第2の部分を受信するための少なくとも第2の要求を前記少なくとも第2の経路を介して送信するステップ(S3)であって、 (D-1)前記識別される前記チャンクの前記第1の部分および前記第2の部分が相補的であり、 (D-2)前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれが、前記決定した第1の利用可能なビット・レートおよび前記決定した第2の利用可能なビット・レートから計算されるサイズを有する、 (D)前記ステップ(S3)と、 (E)前記第1の経路を介して前記要求した第1の部分を受信し、前記少なくとも第2の経路を介して前記要求した少なくとも第2の部分を受信するステップ(S4)と、 (A)を含む、前記方法。 ((A)?(E)は、当審で付与した。以下各構成要件を「構成要件A」?「構成要件E」という。) 第2 引用文献の記載事項及び引用文献に記載された発明 1 引用文献1 (1)引用文献1の記載事項 原査定における拒絶の理由に引用された特表2007-535881号公報(以下「引用文献1」という。)には、「ストリーミングコンテントの適応レートシフティング装置、システムおよび方法」(発明の名称)に関し、図面と共に次に掲げる事項が記載されている(下線は当審が付与した。)。 「【0030】 図1は、本発明に係るストリーミングコンテントの動的なレートシフトを行うシステム100の一実施例を示す概略ブロック図である。一の実施例では、システム100は、コンテントサーバ102と、エンドユーザ104を具える。コンテントサーバ102とエンドユーザ局104は、データ通信ネットワークで接続することができる。データ通信ネットワークは、インターネット106と、インターネット106への接続108を具える。代替的に、コンテントサーバ102とエンドユーザ104は、共通のローカルエリアネットワーク、ワイヤレスエリアネットワーク、セルラネットワーク、バーチャルローカルエリアネットワーク、その他の上に配置しても良い。エンドユーザ局104は、パーソナルコンピュータ(PC)、ネットワークを介して通信するように構成された娯楽システム、あるいは、コンテントを提示するように構成された持ち運び可能な電子デバイスを具えていても良い。 【0031】 図に示す実施例では、システム100は又、パブリッシャ110と、ウエブサーバ116を具える。パブリッシャ110は、コンテントの製造者あるいは頒布者であってもよい。例えば、ストリームされるコンテントが、テレビジョンプログラムの放送である場合、パブリッシャ110は、NBC(登録商標)あるいはMTV(登録商標)などのテレビジョンまたはケーブルネットワークチャンネルであってもよい。コンテントは、インターネット106を介してコンテントサーバ102に送信され、ここでこのコンテントがコンテントモジュール112によって受信される。コンテントモジュール112は、コンテントを受信し、処理し、保存するように構成されている。一の実施例では、処理したコンテントは、エンドユーザ局104でそのコンテントを奏するように構成されたクライアントモジュール114によってアクセスされる。更なる実施例では、クライアントモジュール114は、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成されている。例えば、クライアントモジュール114は、複数のウエブサーバ116のいずれかからコンテントを要求して受信することができる。 【0032】 図2aは、コンテントファイル200の一実施例をグラフィカルに示す概略ブロック図である。一の実施例では、コンテントファイル200は、パブリッシャ110によって配信される。コンテントファイル200は、テレビジョン放送、スポーツイベント、映画、音楽、コンサート、その他を具えていてもよい。コンテントファイル200は、ライブまたはアーカイブコンテントであっても良い。コンテントファイル200は、非圧縮ビデオと音響、あるいは、代替的にビデオまたは音響であっても良い。更に、コンテントファイル200は、圧縮されていても良い。圧縮コンテントファイル200の例には、限定するものではないが、DivX(登録商標)、Windows Media Video 9(登録商標)、 Quicktime 6.5 Sorenson 3(登録商標)、またはQuicktime 6.5/MPEG-4(登録商標)で符号化したコンテントがあっても良い。 【0033】 図2bは、品質の度合いと帯域が変化する複数のストリーム202の一実施例を示す概略ブロック図である。一の実施例では、複数のストリーム202は、低品質ストリーム204と、中品質ストリーム206と、高品質ストリーム208を具える。各ストリーム204、206、208は、符号化され、変化するビットレートに圧縮されたコンテントファイル200のコピーである。例えば、低品質ストリーム204は符号化され、秒当たり100キロビット(kbps)のビットレートに圧縮され、中品質ストリーム206は符号化され秒当たり200キロビット(kbps)のビットレートに圧縮され、及び高品質ストリーム208は符号化され秒当たり600キロビット(kbps)のビットレートに圧縮されている。 【0034】 図2cは、複数のストリームレット212に分割されたストリーム210の一実施例を示す概略ブロック図である。ここに用いられているように、ストリームレットとは、コンテントファイル200の何らかのサイズの部分を意味する。各ストリームレット212は、独立したメディア対象物として封入されたストリーム210に含まれるコンテントの部分を具えている。ストリームレット212内のコンテントは、ストリーム210内に含まれているコンテントの開始に関連する独自の時間インデックスを有する。一の実施例では、各ストリームレット212内に含まれるコンテントが2秒の期間を有する。例えば、ストリームレット0は、コンテント再生開始を表す00:00の時間インデックスを有しており、ストリームレット1は、00:02の時間インデックス、などを有していても良い。代替的に、ストリームレット212の期間は、ストリーム210内のコンテントの全再生期間より小さいいずれの期間であっても良い。更なる実施例では、ストリームレット212は、時間インデックスに変えて、ファイルサイズによって分割することもできる。」 「【0038】 ストリームレット212が一旦受信され、処理されると、一の実施例では、各ストリームレット212内に含まれるコンテントが2秒の期間を有する。例えば、ストリームレット0は、コンテント再生開始を表す00:00の時間インデックスを有しており、ストリームレット1は、00:02の時間インデックス、などを有していても良い。クライアント側で開始するこのようなリクエストの使用には、ファイヤーウオールの追加の構成は必要ない。更に、クライアントモジュール114が、このリクエストを開始するので、ウエブサーバ116に必要なのはリクエストのあったストリームレットを取り出して提供することのみである。更なる実施例では、クライアントモジュール114を、複数のウエブサーバ310からストリームレット212を取り出すように構成することができる。各ウエブサーバ116は、インターネット106上の様々な位置に配置することができる。ストリームレット212は本質的には静的ファイルである。このように、クライアントモジュール114は、ストリームレット212を取り出すのに、特化したメディアサーバや、サーバ側のインテリジェンスを必要としていない。ストリームレット212は、ウエブサーバ116によって提供されるか、あるいは、インターネットサービスプロバイダ(ISPs)、あるいはその他のネットワークインフラストラクチュアオペレータのキャッシュサーバに記憶して、キャッシュサーバによって保存することができる。キャッシュサーバの使用は当業者にはよく知られており、ここではこれ以上説明しない。従って、いずれかの特定の場所におけるウェブサーバ116のクライアントモジュール114の大量のリクエストによって妨害されることのない、高度にスケーラブルなソリューションが提供される。」 「【0040】 エージェントコントローラモジュール402は、ビューワ408に送信するストリームレットの品質レベルを選択するように構成されている。エージェントコントローラモジュール402は、各要求されたストリームレットの連続的な受信時間の間の時間インターバルの継続的観察に基づいてより低品質、あるいはより高品質ストリームをリクエストする。より高品質またはより低品質ストリームを要求する方法を、図7を参照して以下により詳しく述べる。 【0041】 エージェントコントローラモジュール402は、ビューワ408からのユーザコマンドを受信するように構成されている。このようなコマンドには、演奏、早送り、巻戻し、ポーズ、停止が含まれている。一の実施例では、エージェントコントローラモジュール402は、ストリームレットキャッシュモジュール404からストリームレット212を要求し、この受信したストリームレット212をステージモジュール409で編集する。ステージモジュール409は、再生時間を上げるためにストリームレット212を編集するように構成することができる。図に示す実施例では、ストリームレット212は、0,1,2,3,4、その他の番号がついている。しかしながら、各ストリームレット212は、独自のファイル名で同定することができる。」 「【0045】 更なる実施例では、ストリームレットリクエストは、いずれかのストリームレットファイルのリクエスト片を具えていても良い。ストリームレット212をより小さな片または部分に分けることで、潜在的に効率が高くなり、所定の瞬間に帯域を共有している複数の全ストリームレットリクエストに関連する問題を解決するものでもあり、有益である。このことは、ストリームレット212片に対する並列TCP/IP接続を使用することによって達成される。この結果、効率とネットワークロスの問題が解決され、ストリームレットはより有用で予測可能なタイミングで到着する。 【0046】 一の実施例では、クライアントモジュール114が、クライアントモジュール114とウエブサーバ116またはウエブキャッシュとの間で多数のTCP接続を使用するように構成されている。キャッシュの介入は、クライアントに分かりやすいか、あるいは、クライアントによってフォワードキャッシュとして構成される。「並列取り出し」と呼ばれるやり方で一以上のストリームレット212を、同時に、あるいはストリームレット212の一以上の部分を同時にリクエストすることによって、効率が大きく上がり、待ち時間が事実上少なくなる。更なる実施例では、クライアントモジュールは、最大3つの現在のストリームレット212リクエストを可能にする。クライアントモジュール114は、追加の開放TCP接続を、別の接続が切れた場合の入手可能なスペアとして維持している。ストリームレット212リクエストは、すべての開接続の間で回転して、特定の接続がすべてスロースタートまたは閉モードに入らないように、TCPフローロジックを維持している。ネットワークコントローラモジュール406が複数部分においてストリームレット212をリクエストした場合、相互に独立したTCP/IP接続のリクエストされた各パートによって、ネットワークコントローラモジュール406は、この部分を組み立てなおして、クライアントモジュール114の他の全ての構成要素による使用のために完全なストリームレット212を提供する。」 「【0050】 単一のストリームレット212リクエストは、全ストリームレット212用に発行されるものであってもよく、あるいは、ストリームレットの各異なる部分について多数リクエストを発行しても良い。幾つかの部分でこのストリームレットがリクエストされると、その部分がクライアントモジュール114ストリームレットによって再結合される。」 「【0057】 図7を参照すると、本発明による適応レートシフティングコンテントストリーミング環境内でストリームレットをリクエストする方法700の一実施例を示す概略フローチャート図が示されている。方法700は、図6の動作611としての一実施例に使用することができる。方法700がスタートし、エージェントコントローラモジュール402が図6を参照して上述したようなストリームレットを受信する(ステップ704)。エージェントコントローラモジュール402は、次いで、リクエストしたストリームレットの受信時間をモニタする(ステップ706)。一の実施例では、エージェントコントローラモジュール402は、各ストリームレット応答についての順次受信した時間の間の時間インターバルΔをモニタする。対応するリクエストの順番に関連するこの応答の順番は、関係しない。 【0058】 ネットワーク行動の特徴は、時に非常に突然に変動するので、所定のΔはどれも別のΔから実質的に変化することがある。この変動を補償するために、エージェントコントローラモジュール402は、再生長さSのストリームレットについてn個のサンプルの窓全域のパフォーマンス率rを計算する(ステップ708)。一の実施例では、パフォーマンス率rは、次の式を用いて計算される。 【0059】 多数の同時ストリームレットを処理するため、およびパフォーマンス率rの代表値をよりよく判定するために、エージェントコントロールモジュール402は、相乗平均を計算するかあるいは代替的に、サイズmの窓全域の等価平均アルゴリズムを計算し、パフォーマンスファクタφを得る: 【0060】 再生品質をアップシフトする(ステップ710)かどうかについての方針決定は、φcurrentをトリガスレッシュホールドΘupと比較することによって開始する。 であれば、次により高品質のストリームへのアップシフトが考えられる(ステップ716)。一の実施例では、トリガスレッシュホールドΘupが、現在の先読みマージン(すなわち、現在の再生時間インデックスで表示するステージングモジュール409によってシーケンシャルに編集された連続的に入手可能なストリームレットの量)に関連するファクタの組み合わせと、最小安全マージンとによって決定される。一の実施例では、最小安全マージンは、24秒である。先読みマージンが小さいほど、Θupが大きく、より大きな先読みマージンが、ネットワークの混乱に耐えるように設定されるまでアップシフティングを止めることになる。エージェントコントローラモジュール402が、品質のアップシフトを保持することができる(ステップ716)のであれば、エージェントコントローラモジュール402は、品質をアップシフトさせて(ステップ717)、順次より高品質のストリームをリクエストする。より高品質ストリームの使用が保持可能かどうかの決定(ステップ716)は、より高品質ストリームの性能ファクタφhigherの見積もりを、Θupと比較することによって行われる。 であれば、より高品質のストリームの使用が保持可能であると考えられる。より高いストリームレートが保持可能であるかどうかの決定(ステップ716)が「no」である場合、エージェントコントロールモジュール402は、ストリーム品質のアップシフト(ステップ717)を試みないであろう。ストリームの終りに達すると(ステップ714)、方法618が終了する(ステップ716)。 【0061】 アップシフト710を試みるべきかどうかの決定が「no」である場合、ダウンシフトを行うべきかどうかの決定(ステップ712)が行われる。一の実施例では、トリガスレッシュホールドΘdownはΘupと同様の方法で決定される。φcurrent>Θdownであれば、ストリーム品質が適当であり、エージェントコントローラモジュール402は、ストリーム品質をダウンシフトしない(ステップ718)。しかしながら、 であれば、エージェントコントロールモジュール402は、ストリーム品質をダウンシフトする(ステップ718)。ストリームの終りに届かない場合(ステップ714)、エージェントコントローラモジュール402は、リクエストを開始して、より低品質のストリームレットを受信して(ステップ704)、方法618を再度開始する。もちろん、上述の式とアルゴリズムは、説明のためだけのものであり、代替のストリームレットモニタリングソリューションによって置き換えることができる。」 「【図1】 」 「【図2a】 」 「【図2b】 」 「【図2c】 」 (2)引用文献1に記載された発明 ア 引用文献1には、「ストリーミングコンテントの適応レートシフティング方法」(名称)が記載されている。 イ 段落【0030】、【0031】によると、複数のウエブサーバとエンドユーザ局は、データ通信ネットワークで接続されている。また、段落【0045】、【0046】によると、接続はTCP/IP接続である。 ウ 段落【0031】によると、エンドユーザ局でそのコンテントを奏するように構成されたクライアントモジュールによって、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成されて、クライアントモジュールは、複数のウエブサーバのいずれかからコンテントを要求して受信する。 段落【0032】によると、コンテントはビデオ等である。 エ 段落【0033】によると、コンテントは、品質の度合いと帯域が変化する複数のストリームを具える。 複数のストリームは、低品質ストリーム(例えば100kbps)、中品質ストリーム(例えば200kbps)、高品質ストリーム(例えば600kbps)である。 オ 段落【0034】によると、ストリームは、同じ再生期間を有する複数のストリームレットに分割され、時間インデックスを有する。 カ 段落【0039】によると、クライアントモジュールはエージェントコントローラモジュールを具え、段落【0057】によると、エージェントコントローラモジュールは、リクエストしたストリームレットの受信時間をモニタする。段落【0058】によると、エージェントコントローラモジュールは、再生長さSのストリームレットについてのn個のサンプル窓全域のパフォーマンス率を計算する。 キ 段落【0059】によると、多数の同時ストリームレットを処理するため、およびパフォーマンス率rの代表値をよりよく判定するために、エージェントコントロールモジュール402は、相乗平均を計算するかあるいは代替的に、サイズmの窓全域の等価平均アルゴリズムを計算し、パフォーマンスファクタφを得る。 ク 段落【0060】?【0061】によると、パフォーマンスファクタφにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断する。 段落【0061】によると、ストリームの終りに届かない場合、エージェントコントロールモジュールは、判断した再生品質のリクエストを開始して、ストリームレットを受信して、ストリームの終わりまで繰り返す。 ケ 段落【0045】によると、ストリームレットリクエストはストリームレットのより小さい部分としてもよく、段落【0046】によると、「並列取り出し」と呼ばれるやり方で、同時にストリームレットあるいはストリームレットの部分をリクエストすることが記載されている。 したがって、上記ア?クにおける「ストリームレット」を「ストリームレットの部分」と置き換えた発明が記載されていると認められる。 コ 以上まとめると、引用文献1には、次の発明(以下「引用発明」という。)が記載されていると認められる。 (引用発明) (a)複数のウエブサーバとエンドユーザ局はデータ通信ネットワークで接続し、エンドユーザ局でコンテントを奏するように構成されたクライアントモジュールによって、複数の位置からのコンテントストリームの異なる部分を同時に受信するように構成され、クライアントモジュールは、TCP/IP接続された複数のウエブサーバにビデオ等のコンテントを要求して受信する方法であり、 (a-1)コンテントが品質の度合いと帯域が変化する複数のストリームを具え、複数のストリームは、低品質ストリーム(例えば100kbps)、中品質ストリーム(例えば200kbps)、高品質ストリーム(例えば600kbps)であり、 (a-2)ストリームは、同じ再生期間を有する複数のストリームレットに分割され、時間インデックスを有し、ストリームレットはさらにより小さい部分に分割され、 (a-3)「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する方法であって、 (b)エンドユーザ局のエージェントコントローラモジュールは、リクエストしたストリームレットの部分の受信時間をモニタし、ストリームレットの部分についてのパフォーマンス率を計算し、 (c)多数の同時ストリームレットの部分を処理するため、およびパフォーマンス率rの代表値をよりよく判定するために、パフォーマンスファクタを得、 パフォーマンスファクタにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断し、 (d)ストリームの終りに届かない場合、エージェントコントロールモジュールは、判断した再生品質のリクエストを開始して、ストリームレットの部分を受信して、ストリームの終わりまで繰り返す (a)方法。 なお、(a)?(d)は、構成を識別するために付与した。以下各構成を「構成a」?「構成d」という。 3 引用文献2 (1)引用文献2の記載事項 原査定における拒絶の理由に引用された特開2006-244054号公報(以下「引用文献2」という。)には、図面と共に次に掲げる事項が記載されている。 「【0215】 例えば、図5に示すコンテンツデータのうち、セグメント71-1のダウンロードが終了しており、セグメント71-2乃至セグメント71-6のダウンロードが終了していない場合、算出部253は、ノード情報および受信履歴を参照して、セグメント71-2乃至セグメント71-6のそれぞれを、ノード情報に含まれている、送信ノードとしてのサーバ52の数によって示される数に分割する。 【0216】 例えば、ノード情報に含まれている、送信ノードとしてのサーバ52の数が“2”である場合、算出部253は、セグメント71-2乃至セグメント71-6を、それぞれ2つのパートに分割する。このとき、パートの大きさは、例えば、受信履歴に含まれている、パートのダウンロード速度を基に、式(4)を計算して定める。 【0217】 Pi=Vi×D/(ΣVi) ・・・(4) 【0218】 ここで、Piは、サーバ52-i(但し、1≦i≦N)に割り当てるパートの大きさを示しており、Viは、前回、サーバ52-iからダウンロードしたパートのダウンロード速度を示している。また、Σは、iを1からNに変えてのViの和(合計)をとることを表し、Dは、セグメントの大きさを示す。 【0219】 したがって、例えば、図5に示すセグメント71の大きさが2300KBであり、パート111-1のサーバ52-1からのダウンロード速度が“3Mbps”であり、パート112-1のサーバ52-2からのダウンロード速度が“2Mbps”であり、さらに、セグメント71-2乃至セグメント71-6を、それぞれ、パート111-2乃至パート111-6、およびパート112-2乃至パート112-6に分割して、パート111-2乃至パート111-6をサーバ52-1からダウンロードし、パート112-2乃至パート112-6をサーバ52-2からダウンロードする場合、パート111-2乃至パート111-6のそれぞれの大きさは、式(4)から、1380KB(3×2300/(2+3))と算出される。 【0220】 そして、算出部253は、セグメント71-2乃至セグメント71-6をそれぞれ分割すると、パート111の送信を、サーバ52-1に割り当て、パート112の送信を、サーバ52-2に割り当てる。そして、算出部253は、パート111-2を特定するための割り当て情報、およびパート112-2を特定するための割り当て情報を、それぞれ生成する。算出部253は、生成したパート111-2を特定するための割り当て情報を、通信制御部183-1に供給し、パート112-2を特定するための割り当て情報を、通信制御部183-2に供給する。」 「【図5】 」 第3 対比 1 対比 本願発明と引用発明とを対比する。 (1)構成要件Aと構成aとを対比する。 構成aの「エンドユーザ局」は構成要件Aの「クライアント装置」に相当する。 構成aの「データ通信ネットワークを介して複数のウエブサーバにTCP/IP接続されたエンドユーザ局」は、「複数のウエブサーバにTCP/IP接続」されているから、「少なくとも第1および第2の通信インタフェースを含む」といえる。 また、構成aの「ビデオ等のコンテント」は、「レンダリングされるコンテンツ」といえる。 さらに、構成aの「エンドユーザ局でコンテントを奏するように構成されたクライアントモジュールによって、・・・TCP/IP接続された複数のウエブサーバにビデオ等のコンテントを要求して受信する方法」は、「クライアント装置においてレンダリングされるコンテンツを提供する方法」といえる。 したがって、構成要件Aと構成aとは、「少なくとも第1および第2の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法」として一致する。 (2)構成要件A-1と構成aとを対比する。 構成aの「エンドユーザ局」は、「TCP/IP接続」されているから、「通信アドレス」を有することは明らかである。 したがって、構成要件A-1と構成aとは、前記少なくとも第1および第2の通信インタフェースのそれぞれが通信アドレスを有する」として一致する。 (3)構成要件A-2と構成a、a-3とを対比する。 「クライアント装置」に相当する「エンドユーザ局」が「それぞれが通信アドレスを有する少なくとも第1および第2のサーバ通信インタフェース」を有することは上記(2)のとおりであり、構成a-3のとおり、エンドユーザ局は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」から、構成a、a-3は、「前記コンテンツがそれぞれが通信アドレスを有する少なくとも第1および第2のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能」であるといえる。 したがって、構成要件A-2と構成a、a-3は、「前記コンテンツが、それぞれが通信アドレスを有する少なくとも第1および第2のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能である」として一致する。 (4)構成要件A-3、A-4と構成aとを対比する。 構成aにおいては、データ通信ネットワークを介して複数のウエブサーバにTCP/IP接続されたエンドユーザ局がコンテントを受信するから、1つのウエブサーバとエンドユーザ局の通信の経路は、第1の経路といえ、TCP/IP接続においては、それぞれのアドレスにより通信が行われるから、「第1の経路が、前記第1の通信インタフェースの通信アドレスおよび前記第1のサーバ通信インタフェースのアドレスによって識別され」といえる。 同様に他のウエブサーバとエンドユーザ局の通信の経路は、第2の経路といえ、「第2の経路が、前記第2の通信インタフェースの通信アドレスおよび前記第2のサーバ通信インタフェースのアドレスによって識別され」といえる。 したがって、構成要件A-3、A-4と構成aとは、「第1の経路が、前記第1の通信インタフェースの通信アドレスおよび前記第1のサーバ通信インタフェースのアドレスによって識別され、少なくとも第2の経路が、前記第2の通信インタフェースの通信アドレスおよび前記少なくとも第2のサーバ通信インタフェースのアドレスによって識別される」として一致する。 (5)構成要件A-5と構成a-1とを対比する。 構成要件a-3によると、コンテントが3つの品質の異なるストリームからなり、異なるビットレートを有するから、構成要件a-3は、「前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも2つのバージョンで利用可能である」として、構成要件A-5と一致する。 (6)構成要件A-6と構成a-2とを対比する。 構成a-2の「ストリームレット」はデータの塊であるから「チャンク」といえる。構成a-1によると、ストリームは複数あるから、構成a-2は、「前記少なくとも2つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割される」として、構成要件A-6と一致する。 (7)構成要件A-7と構成a-2とを対比する。 構成a-2の「時間インデックス」は、構成要件A-7の「時間指標i」に相当する。 したがって、構成要件A-7と構成a-2とは、「チャンクが、時間指標iおよび前記対応ビット・レートのうちの1つによって識別される」として一致する。 (8)構成要件A-8と構成a-3とを対比する。 構成a-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する方法」であり、上記(4)のとおり、引用発明は、「第1の経路」、「第2の経路」を有しているから、「前記コンテンツが、前記第1および前記少なくとも第2の経路を介して前記クライアント装置から同時にアクセス可能である方法」として、構成要件A-8と一致する。 (9)構成要件Bと構成bとを対比する。 構成bの「エンドユーザ局のエージェントコントローラモジュール」は、「エンドユーザ局」に含まれるから、構成要件Bの「クライアント装置」に相当する。 構成bの「リクエストしたストリームレットの部分の受信時間をモニタする」は、構成cにおいて、複数の同時ストリームレットの部分を処理するから、同時に出した複数のストリームリクエストに対してモニタするものと認められ、構成bは、「前記クライアント装置において、前記第1の経路上の第1の指標および前記少なくとも第2の経路上の少なくとも第2の指標を決定するステップ」として、構成要件Bと共通する。 しかしながら、「指標」が、本願発明においては、「利用可能なビット・レート」であるのに対し、引用発明においては、「受信時間」である点で相違する。 (10)構成要件Cと構成cとを対比する。 構成cは、「多数の同時ストリームレットの部分を処理するため、およびパフォーマンス率rの代表値をよりよく判定するために、パフォーマンスファクタを得、パフォーマンスファクタにより、再生品質をアップシフト、そのまま、ダウンシフトするかを判断」するものであり、「再生品質をアップシフト、そのまま、ダウンシフトするかを判断」することは、「前記対応ビット・レートの中から要求ビット・レートを決定する」ことといえる。 上記(9)のとおり、本願発明の「ビット・レート」と引用発明の「受信時間」とは「指標」として一致するものの、相違する。 したがって、構成要件Cと構成cとは、「前記決定した第1の指標および前記決定した少なくとも第2の指標から、前記対応ビット・レートの中から要求ビット・レートを決定するステップ」として共通する。 しかしながら、「指標」が、本願発明においては、「利用可能なビット・レート」であるのに対し、引用発明においては、「受信時間」である点で相違する。 (11)構成要件Dと構成a-3とを対比する。 構成a-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」ものである。 ストリームレットは、上記(7)のとおり、時間指標iで識別され、構成a-1によると、ビットレートで識別され、第1、第2の経路は、上記(4)のとおりである。 したがって、構成要件Dと構成a-3とは、「前記時間指標iおよび前記決定した要求ビット・レートによって識別されるチャンクの第1の部分を受信するための第1の要求を前記第1の経路を介して送信し、前記時間指標iによって識別される前記チャンクの少なくとも第2の部分を受信するための少なくとも第2の要求を前記少なくとも第2の経路を介して送信するステップ」として一致する。 (12)構成要件D-1について 本願発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分が相補的である」のに対し、引用発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分が相補的である」と特定されていない点で相違する。 (13)構成要件D-2について 本願発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれが、前記決定した第1の利用可能なビット・レートおよび前記決定した第2の利用可能なビット・レートから計算されるサイズを有する」のに対し、引用発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれ」が、どのようなサイズにするか特定されていない点で相違する。 (14)構成要件Eと構成a-3とを対比する。 構成a-3は、「「並列取り出し」と呼ばれるやり方で、同時にストリームレットの部分をリクエストし受信する」ものであり、「前記第1の経路を介して前記要求した第1の部分を受信し、前記少なくとも第2の経路を介して前記要求した少なくとも第2の部分を受信するステップ」といえる。 したがって、構成要件Eと構成a-3とは一致する。 2 一致点、相違点 以上より、本願発明と引用発明との一致点、相違点は、次のとおりである。 (一致点) (A)少なくとも第1および第2の通信インタフェースを含むクライアント装置においてレンダリングされるコンテンツを提供する方法であり、 (A-1)前記少なくとも第1および第2の通信インタフェースのそれぞれが通信アドレスを有し、 (A-2)前記コンテンツが、それぞれが通信アドレスを有する少なくとも第1および第2のサーバ通信インタフェースを介して前記クライアント装置からアクセス可能であり、 (A-3)第1の経路が、前記第1の通信インタフェースの通信アドレスおよび前記第1のサーバ通信インタフェースのアドレスによって識別され、 (A-4)少なくとも第2の経路が、前記第2の通信インタフェースの通信アドレスおよび前記少なくとも第2のサーバ通信インタフェースのアドレスによって識別され、 (A-5)前記コンテンツが、対応ビット・レートの制約に対応する符号化品質を有する少なくとも2つのバージョンで利用可能であり、 (A-6)前記少なくとも2つのバージョンのそれぞれが、前記コンテンツの同一のレンダリング持続時間に対応する複数のチャンクに時間的に分割され、 (A-7)チャンクが、時間指標iおよび前記対応ビット・レートのうちの1つによって識別され、 (A-8)前記コンテンツが、前記第1および前記少なくとも第2の経路を介して前記クライアント装置から同時にアクセス可能である方法であって、 (B’)前記クライアント装置において、前記第1の経路上の第1の指標および前記少なくとも第2の経路上の少なくとも第2の指標を決定するステップ(S1)と、 (C’)前記決定した第1の指標および前記決定した少なくとも第2の指標から、前記対応ビット・レートの中から要求ビット・レートを決定するステップ(S2)と、 (D)前記時間指標iおよび前記決定した要求ビット・レートによって識別されるチャンクの第1の部分を受信するための第1の要求を前記第1の経路を介して送信し、前記時間指標iによって識別される前記チャンクの少なくとも第2の部分を受信するための少なくとも第2の要求を前記少なくとも第2の経路を介して送信するステップ(S3)と、 (E)前記第1の経路を介して前記要求した第1の部分を受信し、前記少なくとも第2の経路を介して前記要求した少なくとも第2の部分を受信するステップ(S4)と、 (A)を含む、前記方法。 (相違点1) 「指標」が、本願発明においては「利用可能なビット・レート」であるのに対し、引用発明においては「受信時間」である点 (相違点2) 本願発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分が相補的である」のに対し、引用発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分が相補的である」と特定されていない点 (相違点3) 本願発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれが、前記決定した第1の利用可能なビット・レートおよび前記決定した第2の利用可能なビット・レートから計算されるサイズを有する」のに対し、引用発明においては、「前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれ」がどのようなサイズにするか特定されていない点 第4 判断 1 相違点1について 引用発明における「受信時間」は、ストリームレットの部分の受信時間であり、経路の速度に関係していることは明らかであるから、「受信時間」を「ビット・レート」をすることは当業者が容易に想到し得ることである。 そして、経路の速度である「ビット・レート」は、経路の利用できる速度であるから、「利用可能なビット・レート」といえる。 2 相違点2について 引用発明は、エンドユーザ局においてコンテントを奏する、すなわちコンテントを再生するものであるから、第1の部分と第2の部分との間に不足する部分があることはなく、また効率を高くするため、重複をしないようにすることも普通のことである。 したがって、引用発明において、第1部分と第2の部分とを相補的とすることは、当業者が容易に想到し得ることである。 3 相違点3について 利用可能なビットレートから第1の部分と第2の部分のサイズを決定することは、例えば、拒絶査定で引用された特開2006-244054号公報の段落0215?0220(上記第2の3参照)に記載されているように、周知の技術である。 引用発明と周知技術とは、コンテンツを複数の箇所から受信する技術という技術分野のものであるから、引用発明に周知技術を適用する動機付けはある。 したがって、引用発明に周知技術を適用して、「前記識別される前記チャンクの前記第1の部分および前記第2の部分のそれぞれが、前記決定した第1の利用可能なビット・レートおよび前記決定した第2の利用可能なビット・レートから計算されるサイズを有する」ようにすることは、当業者が容易に想到し得ることである。 4 効果等 本願発明が奏する効果は、その容易想到である構成から当業者が容易に予測し得る範囲内のものであり、同範囲を超える顕著なものでもない。 5 まとめ 以上のとおりであるから、本願発明は、引用発明、周知技術に基づいて、当業者が容易になし得たものである。 第5 むすび 以上のとおり、本願の請求項1に係る発明は、引用文献1に記載された発明、周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。 したがって、本願は、他の請求項について検討するまでもなく、拒絶すべきものである。 よって、結論のとおり審決する。 |
別掲 |
|
審理終結日 | 2019-10-31 |
結審通知日 | 2019-11-01 |
審決日 | 2019-11-12 |
出願番号 | 特願2016-82623(P2016-82623) |
審決分類 |
P
1
8・
121-
Z
(H04N)
|
最終処分 | 不成立 |
前審関与審査官 | 後藤 嘉宏 |
特許庁審判長 |
鳥居 稔 |
特許庁審判官 |
小池 正彦 樫本 剛 |
発明の名称 | アダプティブ・ストリーミングのマルチパス配信 |
代理人 | 内藤 和彦 |
代理人 | 江口 昭彦 |
代理人 | 阿部 豊隆 |
代理人 | 大貫 敏史 |
代理人 | 稲葉 良幸 |