JP2017510120A - クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ - Google Patents

クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ Download PDF

Info

Publication number
JP2017510120A
JP2017510120A JP2016544798A JP2016544798A JP2017510120A JP 2017510120 A JP2017510120 A JP 2017510120A JP 2016544798 A JP2016544798 A JP 2016544798A JP 2016544798 A JP2016544798 A JP 2016544798A JP 2017510120 A JP2017510120 A JP 2017510120A
Authority
JP
Japan
Prior art keywords
cache
representation
request
representations
client terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2016544798A
Other languages
English (en)
Other versions
JP2017510120A5 (ja
JP6538061B2 (ja
Inventor
ガッシュ，ステファン
ビショー，ギヨーム
ル・ボルゼ，フランソワーズ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of JP2017510120A publication Critical patent/JP2017510120A/ja
Publication of JP2017510120A5 publication Critical patent/JP2017510120A5/ja
Application granted granted Critical
Publication of JP6538061B2 publication Critical patent/JP6538061B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/44—Browsing; Visualisation therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2885—Hierarchically arranged intermediate devices, e.g. for hierarchical caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本開示によるマルチメディアコンテンツのコンテンツ部分をクライアント端末（Ｃ）に提供する方法であって、１つ以上のキャッシュがクライアント端末（Ｃ）とリモートサーバ（Ｓ）との間の伝送経路に配置され、コンテンツ部分の複数のリプレゼンテーションが利用可能であり、この方法が、
第１のキャッシュで、クライアント端末からコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって（Ｓ０）、コンテンツ部分は、利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、リクエストは、さらに、組の他に取り得るリプレゼンテーションのリスト及びクライアント端末とリモートサーバ間のリクエストの範囲を特定する補助情報を含む、受信するステップ（Ｓ０）と、
所定のリプレゼンテーションがキャッシュ（Ｒ）に保存されているかを第１のキャッシュで検査するステップ（Ｓ１）と、
所定のリプレゼンテーションがキャッシュされていない場合に、第１のキャッシュ（Ｒ）でリストに記載された他に取り得るリプレゼンテーションをブラウズするステップ（Ｓ２）と、
を含む、方法。

Description

本発明は一般に、例えばこれに限定されないがＨＴＴＰ（HyperText
Transfer Protocol）を介した適応ストリーミング技術分野に関連し、特にクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、クライアント端末とリモートサーバとの間の伝送経路にキャッシュが配置される、方法に関する。
この項目では、技術の様々な側面を読者に紹介することを意図し、その後説明及び／又は請求される本発明の様々な側面に関連し得る。ここでの検討は、本発明の様々な側面のより良い理解を容易にする背景情報を読者に提供する手助けとなると確信する。その結果、これらの記述はこの観点で読まれるべきであり、先行技術に対する自白と理解すべきではない。
ＨＴＴＰ（マルチビットレートスイッチングとも呼ばれる）を介した適応ストリーミング（adaptive
streaming）は、マルチメディアコンテンツの配布において急速に主要な技術となってきている。既に利用されているＨＴＴＰ適応ストリーミングプロトコルの中で、最も有名なものは、アップルのＨＴＴＰライブストリーミング（ＨＬＳ：HTTP Live Streaming）、マイクロソフトのシルバーライトスムースストリーミング（ＳＳＳ：Silverlight Smooth Streaming）、アドビのアドビダイナミックストリーミング（ＡＤＳ：Adobe Dynamic Streaming）、ＳＡ４グループ内で３ＧＰＰにより開発されたＨＴＴＰを介した動的適応ストリーミング（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）である。
適応ストリーミングにおいてクライアント端末がオーディオビジュアルコンテンツ（すなわち、Ａ／Ｖコンテンツ）の再生を希望するときは、どのようにＡ／Ｖコンテンツを入手可能かということを記述したファイルを最初に入手しなければならない。これは通常、いわゆるマニフェスト（manifest）と呼ばれる説明ファイルをＵＲＬ（Uniform Resource
Locator）から入手することによりＨＴＴＰプロトコル経由で達成されるが、他の手段（例えば、同報通信（broadcast）
、電子メール、ＳＭＳ等）によっても達成できる。マニフェストは、通常、そのようなＡ／Ｖコンテンツ（ビットレート、解像度や他の特性の観点で）の入手可能なリプレゼンテーション（representation）（インスタンスやバージョンとも呼ばれる）のリストを作成し、ここで品質レベル（ビットレート）毎に一つのリプレゼンテーションである。各リプレゼンテーションは、同じ継続時間のチャンク（chunk）の連続でできていて、個別のＵＲＬによりアクセスでき、クライアントの選択に対して添付される説明要素の組を有している。このマニフェストは、事前に生成され、クライアント端末に例えばリモートサーバにより配布される。
実際に、Ａ／Ｖコンテンツに対応するデータのストリームは、異なる品質のＨＴＴＰサーバ上で入手可能である。最高品質は、高いビットレートに関連し、最低品質は、低いビットレートに関連している。このことは、ネットワークの状態が大きく変化を受ける可能性がある多くの異なる端末への配布を可能とする。
各リプレゼンテーションのデータストリーム全体は、同じ継続時間のチャンクに分割されることにより、クライアント端末が２つのチャンク間で一つの品質レベルから他の品質レベルへスムーズに移行することが可能となる。その結果、ビデオ品質は再生中に変化することがあるが、めったに中断（いわゆるフリーズ）に悩まされることが無くなる。
クライアント側において、チャンクは伝送経路の利用可能な帯域幅（bandwidth）の測定に基づいて選択される。特に、クライアント端末は通常、符号化ビットレートに対応するチャンクのリプレゼンテーションをリクエストするので、測定された帯域幅に準拠した品質である。
キャッシュが、良くあるようにクライアント端末とリモートサーバ間の伝送経路にあるとき、所定のチャンクの一つのリプレゼンテーションはこのキャッシュに既に保存されているかも知れず、それは他のクライアントが同じリプレゼンテーションの同じチャンクを以前リクエストしていた場合、又はコンテンツデリバーネットワーク（ＣＤＮ：Content Deliver Network）がキャッシュの中のチャンクを既に供給していた場合である。したがって、所定のチャンクに関するＨＴＴＰリクエストに対する応答は、チャンクがリモートサーバから来る場合よりも早く、重複した伝送を回避することが可能となり、効率的にネットワークリソースをセーブすることが可能となる。
それにもかかわらず、ＨＴＴＰ適応ストリーミングは、キャッシュしにくいように見える（すなわち、少なくとも例えばＨ２６４−ＳＶＣとしてのいわゆる層状化ベースのスイッチングと比較するとキャッシュしづらい）。実際、もし第１のクライアント端末が所定のチャンクのリプレゼンテーションｒをリクエストし、第２のクライアント端末が、第１のクライアント端末及びキャッシュと伝送経路の一部を共用し、所定のチャンク（より高い又はより低い品質で）のリプレゼンテーションｒ’をリクエストしたとすると、キャッシュはヒットせずに、輻輳の発生するリストを伴う、キャッシュとサーバ間のネットワークセグメント上でより高い負荷を発生する。キャッシュすることの利益は、したがって完全に無くなり、キャッシュはこれまでは状況を改善することは出来ない。
本発明は、ネットワークの輻輳（congestion）を防止し、特にクライアント端末と一つ以上のリモートサーバ間の伝送経路に位置するキャッシュをできる限り動作させようとすることに取り組む。
本発明はクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、一つ以上のキャッシュがクライアント端末とリモートサーバとの間の伝送経路に配置され、複数の離プレゼンテーションが利用可能である、方法に関連し、以下を含む点において優れた方法である：
−第１のキャッシュで、クライアント端末からその中から選択可能な利用可能なリプレゼンテーションの組（set）に属するコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、リクエストはさらに組の他に取り得るリプレゼンテーションのリストとリクエストの範囲を特定する補助情報を含む、受信するステップと、
−第１のキャッシュで所定のリプレゼンテーションがキャッシュに保存されているか否かを検査するステップと、
−所定のリプレゼンテーションがキャッシュされていない場合、第１のキャッシュでリスト上の他に取り得るリプレゼンテーションをブラウズするステップ。
これにより、本発明のお陰で、クライアント端末（すなわち、ＨＴＴＰ適応ストリーミングクライアント端末）と対応する元のサーバ間の終端間のトラフィックの削減をキャッシュ手段により行うことが可能となり、キャッシュヒットの数が増加する。この目的を達成するために、キャッシュは、クライアント端末により送信されたリクエストのディレクティブ（directive）をサポートするように構成され、それにより所定のリプレゼンテーションがキャッシュされていないときに、このディレクティブに含まれる他に取り得るリプレゼンテーションがフェッチされる。これによりクライアント端末と元のサーバ間のより少ないトラフィックへと導かれ、結果として、より少ない輻輳になる。このように、本発明は、サーバからのチャンクのダウンロードの必要性を制限することにより、エンドユーザにより良いユーザ体験を提供することができる。
好ましい実施形態の第１の態様において、補助情報（auxiliary
information）がクライアントとサーバの間に配置される残りのキャッシュの数を規定でき、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、補助情報によりリクエストを次のキャッシュへ転送することが可能となる。
特に、残りのキャッシュの最後のキャッシュが、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションを持っていないときに、エラーメッセージがクライアントに送信され得る。
好ましい実施形態の第２の態様において、補助情報は伝送経路に配置される最後のキャッシュを規定でき、それにより、所定のリプレゼンテーションと他に取り得るリプレゼンテーションがこれ以降のキャッシュに保存されていない場合は、リクエストは最後のキャッシュにより転送されない。
有利なことに、最後のキャッシュが所定のリプレゼンテーションと他に取り得るリプレゼンテーションを持たないときは、エラーメッセージは、クライアントに送信されないことができる。
さらに、他に取り得るリプレゼンテーションは望ましい順番で好ましくはブラウズされ、他に取り得るリプレゼンテーションは、例えば、望ましさが減っていく順番でリスト化される。
さらに、それぞれの他に取り得るリプレゼンテーションは、好ましくは所定のリプレゼンテーションの一つより低い対応するビットレートを有する。当然、変形例としては、少なくとも１つの他に取り得るリプレゼンテーションが所定のリプレゼンテーションの一つより高い対応するビットレートを有することもあり得る。
さらに、組の利用可能な各リプレゼンテーションは有利にはクライアント端末とリモートサーバの間の伝送経路の帯域幅と最大でも等しい対応するビットレートを有することができる。
好ましい実施形態の別の態様としては、使用される伝送プロトコルがＨＴＴＰで、リクエストは、ＨＴＴＰリクエストであり、ＨＴＴＰリクエストのキャッシュ制御拡張（Cache Control extension）は他に取り得るリプレゼンテーションのリストを含んでいる。
変形例又は補足として、リクエストは付加情報（additional
information）を含むことにより、もしキャッシュされていれば、リクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、あるいは、所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションがキャッシュされていない場合は、応答メッセージを返す。
具体的には、使用される伝送プロトコルがＨＴＴＰの場合、付加情報は、ＨＴＴＰリクエストのキャッシュ制御拡張内に含まれる。
さらに、本発明は、またクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供するように構成されたキャッシュに関し、キャッシュはクライアント端末とリモートサーバの間の伝送経路上に配置され、コンテンツ部分の複数のリプレゼンテーションが利用可能である。
本発明によるキャッシュは、以下のものを含む。
−クライアント端末からのコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、コンテンツ部分は利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションに属し、リクエストは、さらに、組の他に取り得るリプレゼンテーションのリスト及びリクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
−所定のリプレゼンテーションが保存されているか否かを検査する制御モジュールと、
−所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュール。
好ましくは、他に取り得るリプレゼンテーションは、望ましい順にブラウズされ得る。
好ましい実施形態の第１の態様は、補助情報がクライアントとサーバ間に配置される残りのキャッシュの数を規定し、それにより所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合にリクエストを次のキャッシュに転送し、キャッシュにおいて、残りのキャッシュの数がゼロの場合には、リクエストは好ましくは転送されないことが可能になる。
好ましい実施形態の別の態様では、補助情報は、伝送線路に配置される最後のキャッシュを規定し、リクエストは好ましくは下記の場合に転送され得ない。
−所定のリプレゼンテーション及び他に取り得るリプレゼンテーションがキャッシュに保存されていない場合、且つ
−キャッシュが最後のキャッシュである場合。
開示された実施形態の範囲に対応するいくつかの態様が以下で説明される。これらの態様は単に本発明が取りうるいくつかの形式で概要を読者に提供するためのものであり、これらの態様は、本発明の範囲の制限を意図するものではないことを理解されたい。実際に、本発明は後述されない多くの態様を包含するものである。
本発明は、下記の実施形態や実施例による説明により、制限的な方法ではなく、添付図面を参照してより理解される。
本発明が実装され得るクライアントサーバネットワークアーキテクチャの概略図である。 本発明の好ましい実施形態によるクライアント端末の実施例のブロック図である。 本発明の好ましい実施形態によるキャッシュの実施例のブロック図である。 図３のキャッシュにより実装された所定のチャンクのリプレゼンテーションを検索する方法を説明するフロー図である。
図１から図３において、示されたブロックは、純粋に機能的なエンティティであり、物理的な個別のエンティティに対応する必要はない。すなわち、これらはソフトウェア、ハードウェアの形態で開発され、又は１つ以上のプロセッサを含む１つ以上の集積回路として実装することも可能である。
可能な限り、同じ参照番号は全ての図面において同じ又は類似の要素に使用される。
本発明の図面及び説明は本発明の明確な理解に関連する要素の説明を簡略化したものであり、典型的なデジタルマルチメディアコンテンツ配信方法やシステムにおいて見られる多くの他の要素を明確さのために除外している点を理解されたい。しかしながら、そのような要素は当該技術分野において良く知られるので、そのような要素の詳細な議論はここでは提供しない。ここでの本開示は、当業者に知られているそのような変形や改良を対象にしている。
好ましい実施態様にしたがって、本発明はＨＴＴＰ適応ストリーミングプロトコルに関して説明される。もちろん、本発明は、そのような特定の環境に制限されるものではなく、他の適応ストリーミングプロトコルも考慮され、実装され得る。
図１で説明するように、本発明が実装される得るクライアントサーバネットワークアーキテクチャは、クライアント端末Ｃ、ゲートウェイＧＷ、一つ以上のＨＴＴＰサーバＳ（図１には１つしか示していない）を含む。
クライアント端末Ｃは、第１のネットワークＮ１（例えばホームネットワーク又は企業のネットワーク）を介してゲートウェイＧＷに接続され、第２のネットワークＮ２（例えばインターネットネットワーク）を介してリモートサーバＳに保存されたマルチメディアコンテンツをリクエストし得る。第１のネットワークＮ１は、ゲートウェイＧＷのお陰で第２のネットワークＮ２に接続される。
ＨＴＴＰサーバＳは、クライアントからのリクエストに応じて、１つ以上のＴＣＰ／ＩＰ接続を介してＨＴＴＰ適応ストリーミングプロトコルを使用して、クライアント端末Ｃにチャンクをストリーミングする。
図２に記載された好ましい実施形態にしたがって、クライアント端末Ｃは、少なくとも下記を含む：
−第１のネットワークＮ１への接続インタフェース１（有線及び／又は無線、例えばＷｉ−Ｆｉ、イーサネット（登録商標）等）；
−ＨＴＴＰサーバＳと通信するプロトコルスタックを含む通信モジュール２。具体的には、通信モジュール２は、当該技術分野でよく知られるＴＣＰ／ＩＰスタックを含む。もちろん、クライアント端末ＣのＨＴＴＰサーバＳとの通信を可能にする他のいかなるタイプのネットワーク及び／又は通信手段であっても良い；
−ＨＴＴＰサーバＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する、適応ストリーミングモジュール３。これは対応するビットレートが後述される制約により適合するチャンクのリプレゼンテーションを継続的に選択する；
−マルチメディアコンテンツのデコード及びレンダリングに適合したビデオプレーヤ４；
−クライアント端末Ｃの不揮発性メモリに保存されたアプリケーションとプログラムを実行する１つ以上のプロセッサ５；
−ビデオプレーヤ４に伝送される前にＨＴＴＰサーバＳから受信したチャンクをバッファする、例えば揮発性メモリ等の記憶手段６；
−いくつかのモジュール及び一般的なクライアント端末の機能を実行する技術分野の当業者に周知の全ての手段に接続される内部バスＢ１。
一例として、クライアント端末Ｃは、ポータブルメディアデバイス、携帯電話、タブレット又はラップトップである。当然、クライアント端末Ｃは、完全なビデオプレーヤを含んでいないかも知れないが、メディアコンテンツの逆多重化や復号を行うような部分要素のいくつかのみを含み、エンドユーザに復号済みコンテンツを表示する外部手段に依存しても良い。この場合は、クライアント端末Ｃは、セットトップボックスのようなＨＴＴＰ適応ストリーミング（ＨＡＳ）対応ビデオデコーダである。
図１に記載された好ましい実施形態によると、ゲートウェイＧＷは、キャッシュＲを含み、このキャッシュＲはクライアント端末ＣとサーバＳの間の伝送経路に配置される。変形例としては、キャッシュＲは、第１のネットワークＮ１のプロキシの中又は伝送経路の他の位置に配置され得る。
以下では、クライアント端末ＣがＨＴＴＰ適応ストリーミング（ＨＡＳ）マルチメディアコンテンツをリモートサーバＳに対してリクエストし、ＨＡＳマルチメディアコンテンツは、一連のチャンクから作成されるいくつかのリプレゼンテーションとして利用可能であると仮定する。各リプレゼンテーションの品質は、メディア符号化の品質、メディア符号化のタイプ（例えば２Ｄ対３Ｄ）、メディア符号化カラースキーム等に関連してくることを理解されたい。
この目的を達成するために、図２に示したように、クライアント端末Ｃは、さらに下記を含む。
−伝送経路の帯域幅を推定する、帯域幅推定器７
−クライアント端末Ｃがリクエストし得る利用可能なリプレゼンテーションの組を判定するように構成された、選択モジュール８。利用可能なリプレゼンテーションは、マルチメディアコンテンツの所定のチャンクＩｎの利用可能なリプレゼンテーションの中から選択され、利用可能なリプレゼンテーションは、関連するマニフェストにリスト化される。具体的には、モジュール８による、所定のチャンクＩｎの利用可能なリプレゼンテーションの組の判定は、例えば下記のような一つ以上のパフォーマンス基準に基づく：
・推定器７による帯域幅の推定；
・クライアント端末Ｃの性能；
・以前にリクエストされたチャンクＩｎ−１のリプレゼンテーション；
・クライアント端末Ｃのエンドユーザにより要求される体験品質。
明らかなように、選択モジュール８は、変形例としては、適応ストリーミングモジュール３内に統合され得る。
「利用可能な（allowable）」リプレゼンテーションの意味は、実装に依存することを理解されたい。実際に、以前リクエストされたチャンクＩｎ−１のリプレゼンテーションを比較することにより、所定のチャンクＩｎのリプレゼンテーションの品質は、アップグレード又はダウングレードを意味し得る。
もし所定のチャンクＩｎのリクエストされたリプレゼンテーションが以前にリクエストされたチャンクＩｎ−１のリプレゼンテーションより対応する品質が著しく低い（例えばエンドユーザに可視で）場合は、選択モジュール８は利用可能な帯域幅による制限がある場合を除いて、動作中の潜在的なキャッシュされたチャンクの品質をさらにダウングレードしないように構成され得る。
説明の役に立ち、且つ制限的ではない本発明に準拠している実施例において、所定のチャンクＩｎの利用可能なリプレゼンテーション（マニフェスト中にリスト化された利用可能なリプレゼンテーションから選ばれた）は、推定される帯域幅にほぼ等しい対応するビットレート（所定の品質に関連した）を有する。さらに、組の利用可能なリプレゼンテーションのビットレートは、その品質がクライアント端末Ｃのエンドユーザによって受け入れられない条件下で所定の閾値に少なくとも等しくとも良い。
明らかなように、変形例又は補足として、判定された利用可能なリプレゼンテーションの組は、推定帯域幅より高いビットレートの一つ以上のリプレゼンテーションを含み、それによりキャッシュＲに既に保存されているリプレゼンテーションをフェッチできる。
さらに、適応ストリーミングモジュール３は、利用可能なリプレゼンテーションの組からＨＡＳマルチメディアコンテンツの所定のチャンクＩｎの好ましいリプレゼンテーション（preferred representation）ｒをリクエストするように構成される。例えば、チャンクＩｎの好ましいリプレゼンテーションｒは、推定帯域幅より一寸低い関連するビットレートを有するリプレゼンテーションに対応することができる。
この目的を達成するために、通信モジュール２は、ＨＴＴＰリクエストを送信し、ここで、そのヘッダのキャッシュ制御拡張がディレクティブ「ａｌｔｌｉｓｔ」を含み、クライアント端末Ｃは、好ましいリプレゼンテーションｒがキャッシュされていない場合にキャッシュＲによって返される別のリプレゼンテーションｒ’を望ましい順番又は優先順位にしたがってリスト化する。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’は、判定された組の利用可能なリプレゼンテーションに好ましくは対応する。明らかなように、追加のリプレゼンテーション（例えば、推定される帯域幅より高いビットレートを持つ）が追加される。
以下で、「ａｌｔｌｉｓｔ」ディレクティブを含んでいるＨＴＴＰリクエストの実例を示す：
Figure 2017510120
好ましい実施形態によるキャッシュＲは「ａｌｔｌｉｓｔ」ディレクティブをサポートし、そのコンテンツを解釈するように構成されていると理解されたい。そのようなキャッシュＲは、以下では「スマート（smart）」キャッシュと呼び、他のキャッシュはレガシーキャッシュ（別名非スマートキャッシュ）と呼ばれる。
この目的を達成するために、好ましい実施形態にしたがって、図３に示されるようにスマートキャッシュＲは、以下を含む：
−例えば揮発性メモリ及び／又は永久メモリであり、マルチメディアコンテンツのリクエストをするクライアント端末Ｃへの伝送の前に一つ以上のサーバＳから受信したマルチメディアコンテンツのチャンクを保存する、記憶モジュール９；
−クライアント端末Ｃからコンテンツ部分の好ましいリプレゼンテーションｒに関するＨＴＴＰリクエストを受信するインタフェースモジュール１０であって、好ましいリプレゼンテーションｒは、利用可能なリプレゼンテーションの組に属する、インタフェースモジュール１０。ＨＴＴＰリクエストは「ａｌｔｌｉｓｔ」ディレクティブ内で他に取り得るリプレゼンテーションｒ’を示し、他に取り得るリプレゼンテーションｒ’は、好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより代替品として受け入れられ得る。
−スマートキャッシュＲが既にリクエストされた好ましいリプレゼンテーションｒを持っているか否かを検査するように構成された、制御モジュール１１；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより送信されたＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブ中にリスト化された他に取り得るリプレゼンテーションを望ましい順にブラウズするように適合された、ブラウジングモジュール１２。変形例としては、制御モジュール及びブラウジングモジュールは、ただ一つのモジュールを形成する。
クライアント端末Ｃから所定のチャンクＩｎの好ましいリプレゼンテーションｒに関するそのようなＨＴＴＰリクエストの受信に応じて、スマートキャッシュＲの制御モジュール１１は好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する。
−キャッシュされている場合は、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションｒを返す。
−キャッシュされていない場合は、ブラウジングモジュール１２は、他に取り得るリプレゼンテーションｒ’がキャッシュされているか否か望ましい順番の連続検査に対して、ＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。
「ａｌｔｌｉｓｔ」ディレクティブのそのような他に取り得るリプレゼンテーションｒ’がキャッシュされているとき、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。
「ａｌｔｌｉｓｔ」の他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、スマートキャッシュＲは、クライアント端末ＣによってサーバＳに送信されたＨＴＴＰリクエストをリリース（release）するように構成される。
リリースされたＨＴＴＰリクエストは、その後、スマートキャッシュＲとリモートサーバＳの間の伝送経路にある次のキャッシュによって捉えられ、もし次のキャッシュがスマートキャッシュなら、スマートキャッシュＲとして振る舞う。そうでない場合は（次のキャッシュが「ａｌｔｌｉｓｔ」ディレクティブをサポートしていない場合）、エラーメッセージが返されるか、又はサーバＳに対するＨＴＴＰリクエストがリリースされ得る。
改良版としては、クライアント端末Ｃの通信モジュール２により送信されたＨＴＴＰリクエストが、補助ディレクティブ（補助情報を定義する）「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」（ＴＴＬ）をヘッダのキャッシュ制御拡張に含むことができる。「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」ディレクティブ（トークンとも呼ばれる）は、「ａｌｔｌｉｓｔ」ディレクティブを繰り返し利用することを可能にする。この目的を達成するために、ＴＴＬディレクティブは、クライアント端末ＣとサーバＳの間に配置された残りのキャッシュ（スマートキャッシュ又はレガシーキャッシュ）の数を定義するＴＴＬ値と関連し、それにより、好ましいリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、次のキャッシュにリクエストを転送することが可能となる。実際に、クライアント端末からリクエストを受信する各キャッシュ（スマートキャッシュ又はレガシーキャッシュ）が処理し、リクエストのＴＴＬ値をデクリメントしながら転送する。リクエストのＴＴＬ値がゼロに等しいとき、リクエストは、最早転送されず、エラーコード（例えば４１２）と共に応答がクライアント端末Ｃに送信され得る。失敗の理由が応答に追加されることもできる。
以下で「ａｌｔｌｉｓｔ」及び「ＴＴＬ」ディレクティブを含むＨＴＴＰリクエストの実例を示す：
Figure 2017510120
さらなる改良版又は補足として、クライアント端末Ｃの通信モジュール２によって送信されたＨＴＴＰリクエストは、補助ディレクティブ「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブをヘッダのキャッシュ制御拡張に含むことができる。「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブは、最後のキャッシュを特定する値（例えば、キャッシュのＩＰアドレス、修飾ドメイン名、又は他の種類の識別子）と関連している。
「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブは、それ以降のキャッシュが好ましいリプレゼンテーション又は「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションを含まない場合、所定の最後のキャッシュに到達したときは誰にもＨＴＴＰリクエストを転送しない点を除いて、ＴＴＬディレクティブと同様に動作する。その場合、エラーコード（例えば４１２）を含む応答は、好ましくは生成され、クライアント端末Ｃに送信される。失敗の理由が応答に追加されることもできる。
図４に示したように、好ましい実施形態によるキャッシュＲは、クライアント端末ＣにＨＡＳマルチメディアコンテンツの所定のチャンクＩｎのリクエストされたリプレゼンテーションを提供するための以下のメカニズムＭを実施するように構成される。メカニズムＭは、以下のステップを含む：
−クライアント端末Ｃから以前に定義した利用可能なリプレゼンテーションの組に属する所定のチャンクＩｎ部分の好ましいリプレゼンテーションに対するＨＴＴＰリクエストを受信するステップ（ステップ Ｓ０）。ＨＴＴＰリクエストは、さらに、組の他に取り得るリプレゼンテーションをリスト化する「ａｌｔｌｉｓｔ」ディレクティブを含む。；
−好ましいリプレゼンテーションｒが記憶モジュール９に保存されているか検査するステップ（ステップ Ｓ１）；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、「ａｌｔｌｉｓｔ」ディレクティブにリスト化された他に取り得るリプレゼンテーションｒ’を望ましい順にブラウズするステップ（ステップ Ｓ２）；
−他に取り得るリプレゼンテーションのいずれもがスマートキャッシュＲの記憶モジュール９にキャッシュされていないとき、サーバＳに対するＨＴＴＰリクエストをリリースするステップ（ステップ Ｓ３）。
好ましい実施形態の変形例として、クライアント端末Ｃから送信されたＨＴＴＰリクエストのキャッシュ制御拡張は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」という名前の追加のディレクティブ（追加情報を規定する）をさらに含む。「ａｌｔｌｉｓｔ」ディレクティブは、キャッシュ制御ヘッダの「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ上の優先順位を維持する。以下で上述のディレクティブを含むＨＴＴＰリクエストの例を示す：
Figure 2017510120
変形例として、所定のチャンクＩｎの好ましいリプレゼンテーションｒに関するＨＴＴＰリクエスト（「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」及び「ａｌｔｌｉｓｔ」の両方を含む）の受領に応答して、スマートキャッシュＲは、好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する：
−キャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションＲを返す；
−キャッシュされていない場合、ブラウジングモジュール１２は、一つの別のリプレゼンテーションｒ’がキャッシュされているか否か望ましい順での連続する検査のためＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’がキャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブのお陰で、スマートキャッシュＲが次にエラーメッセージ（例えば「http/1.1 504 altlistがサポートされている」）を返すように構成され、これらは以下のことを示す：
−好ましいリプレゼンテーションｒがキャッシュされていない；
−キャッシュＲが「ａｌｔｌｉｓｔ」ディレクティブをサポートしており、そのようなエラーメッセージの受領から「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションのいずれもがキャッシュされてないことが導き出せる。
さらなるステップで、クライアント端末Ｃは、サーバＳから直接所定のチャンクＩｎの好ましいリプレゼンテーションｒを検索するためにリモートサーバＳに新たなリクエストを送信できる。この目的のために、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ又は「ａｌｔｌｉｓｔ」ディレクティブのいずれもがこの新たなリクエストのヘッダで使用されない。明らかなように、この新たなリクエストは、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブを含まず、「ａｌｔｌｉｓｔ」ディレクティブのみを含むことができる。
本明細書に開示された参照、請求項及び図面は、独立して、又は適切な組合せとして提供され得る。特徴は、適切であれば、ハードウェア、ソフトウェア又はそれらの組合せとして実装することができる。
請求項における参照番号は、説明のためのものであり、請求項の範囲を制限する効果を持つものではない。
好ましい実施形態に記載された本発明は、発明能力を行使することなく、本技術分野の当業者の能力の範囲内で多くの変形例や実施形態を許容できることは明白である。したがって、発明の範囲は、添付の請求項の範囲により規定される。
添付請求項において、特定の機能を実現する手段として表現された構成要素（例えば、適応ストリーミングモジュール３、帯域幅推定器７、選択モジュール８、制御モジュール１１、ブラウジングモジュール１２等）は、これらの機能を実施するためのいかなる方法、例えば、ａ）機能を実行する回路要素の組合せ（例えば一つ以上のプロセッサ）又はｂ）ファームウェア、マイクロコード等、機能を実施するためのソフトウェアを実行するための適切な回路との組合せ等を含むいかなる形式のソフトウェアも包含することを意図する。請求項によって規定される本原理は、様々な引用される手段によって提供される機能性が請求項が請求する態様で結合され、組み合わせられるという事実に存在する。したがって、これらの機能を提供できるいかなる手段も本明細書に示されたものと均等物と見なされる。
本開示は一般に、例えばこれに限定されないがＨＴＴＰ（HyperText Transfer Protocol）を介した適応ストリーミング技術分野に関連し、特にクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、クライアント端末とリモートサーバとの間の伝送経路にキャッシュが配置される、方法に関する。
この項目では、技術の様々な側面を読者に紹介することを意図し、その後説明及び／又は請求される本開示の様々な側面に関連し得る。ここでの検討は、本開示の様々な側面のより良い理解を容易にする背景情報を読者に提供する手助けとなると確信する。その結果、これらの記述はこの観点で読まれるべきであり、先行技術に対する自白と理解すべきではない。
ＨＴＴＰ（マルチビットレートスイッチングとも呼ばれる）を介した適応ストリーミング（adaptive streaming）は、マルチメディアコンテンツの配布において急速に主要な技術となってきている。既に利用されているＨＴＴＰ適応ストリーミングプロトコルの中で、最も有名なものは、アップルのＨＴＴＰライブストリーミング（ＨＬＳ：HTTP Live Streaming）、マイクロソフトのシルバーライトスムースストリーミング（ＳＳＳ：Silverlight Smooth Streaming）、アドビのアドビダイナミックストリーミング（ＡＤＳ：Adobe Dynamic Streaming）、ＳＡ４グループ内で３ＧＰＰにより開発されたＨＴＴＰを介した動的適応ストリーミング（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）である。
適応ストリーミングにおいてクライアント端末がオーディオビジュアルコンテンツ（すなわち、Ａ／Ｖコンテンツ）の再生を希望するときは、どのようにＡ／Ｖコンテンツを入手可能かということを記述したファイルを最初に入手しなければならない。これは通常、いわゆるマニフェスト（manifest）と呼ばれる説明ファイルをＵＲＬ（Uniform Resource Locator）から入手することによりＨＴＴＰプロトコル経由で達成されるが、他の手段（例えば、同報通信（broadcast）
、電子メール、ＳＭＳ等）によっても達成できる。マニフェストは、通常、そのようなＡ／Ｖコンテンツ（ビットレート、解像度や他の特性の観点で）の入手可能なリプレゼンテーション（representation）（インスタンスやバージョンとも呼ばれる）のリストを作成し、ここで品質レベル（ビットレート）毎に一つのリプレゼンテーションである。各リプレゼンテーションは、同じ継続時間のチャンク（chunk）の連続でできていて、個別のＵＲＬによりアクセスでき、クライアントの選択に対して添付される説明要素の組を有している。このマニフェストは、事前に生成され、クライアント端末に例えばリモートサーバにより配布される。
実際に、Ａ／Ｖコンテンツに対応するデータのストリームは、異なる品質のＨＴＴＰサーバ上で入手可能である。最高品質は、高いビットレートに関連し、最低品質は、低いビットレートに関連している。このことは、ネットワークの状態が大きく変化を受ける可能性がある多くの異なる端末への配布を可能とする。
各リプレゼンテーションのデータストリーム全体は、同じ継続時間のチャンクに分割されることにより、クライアント端末が２つのチャンク間で一つの品質レベルから他の品質レベルへスムーズに移行することが可能となる。その結果、ビデオ品質は再生中に変化することがあるが、めったに中断（いわゆるフリーズ）に悩まされることが無くなる。
クライアント側において、チャンクは伝送経路の利用可能な帯域幅（bandwidth）の測定に基づいて選択される。特に、クライアント端末は通常、符号化ビットレートに対応するチャンクのリプレゼンテーションをリクエストするので、測定された帯域幅に準拠した品質である。
キャッシュが、良くあるようにクライアント端末とリモートサーバ間の伝送経路にあるとき、所定のチャンクの一つのリプレゼンテーションはこのキャッシュに既に保存されているかも知れず、それは他のクライアントが同じリプレゼンテーションの同じチャンクを以前リクエストしていた場合、又はコンテンツデリバーネットワーク（ＣＤＮ：Content Deliver Network）がキャッシュの中のチャンクを既に供給していた場合である。したがって、所定のチャンクに関するＨＴＴＰリクエストに対する応答は、チャンクがリモートサーバから来る場合よりも早く、重複した伝送を回避することが可能となり、効率的にネットワークリソースをセーブすることが可能となる。
それにもかかわらず、ＨＴＴＰ適応ストリーミングは、キャッシュしにくいように見える（すなわち、少なくとも例えばＨ２６４−ＳＶＣとしてのいわゆる層状化ベースのスイッチングと比較するとキャッシュしづらい）。実際、もし第１のクライアント端末が所定のチャンクのリプレゼンテーションｒをリクエストし、第２のクライアント端末が、第１のクライアント端末及びキャッシュと伝送経路の一部を共用し、所定のチャンク（より高い又はより低い品質で）のリプレゼンテーションｒ’をリクエストしたとすると、キャッシュはヒットせずに、輻輳の発生するリストを伴う、キャッシュとサーバ間のネットワークセグメント上でより高い負荷を発生する。キャッシュすることの利益は、したがって完全に無くなり、キャッシュはこれまでは状況を改善することは出来ない。
本開示は、ネットワークの輻輳（congestion）を防止し、特にクライアント端末と一つ以上のリモートサーバ間の伝送経路に位置するキャッシュをできる限り動作させようとすることに取り組む。
本開示はクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法であって、一つ以上のキャッシュがクライアント端末とリモートサーバとの間の伝送経路に配置され、複数の離プレゼンテーションが利用可能である、方法に関連し、以下を含む点において優れた方法である：
−第１のキャッシュで、クライアント端末からその中から選択可能な利用可能なリプレゼンテーションの組（set）に属するコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、リクエストはさらに組の他に取り得るリプレゼンテーションのリストとリクエストの範囲を特定する補助情報を含む、受信するステップと、
−第１のキャッシュで所定のリプレゼンテーションがキャッシュに保存されているか否かを検査するステップと、
−所定のリプレゼンテーションがキャッシュされていない場合、第１のキャッシュでリスト上の他に取り得るリプレゼンテーションをブラウズするステップ。
これにより、本開示のお陰で、クライアント端末（すなわち、ＨＴＴＰ適応ストリーミングクライアント端末）と対応する元のサーバ間の終端間のトラフィックの削減をキャッシュ手段により行うことが可能となり、キャッシュヒットの数が増加する。この目的を達成するために、キャッシュは、クライアント端末により送信されたリクエストのディレクティブ（directive）をサポートするように構成され、それにより所定のリプレゼンテーションがキャッシュされていないときに、このディレクティブに含まれる他に取り得るリプレゼンテーションがフェッチされる。これによりクライアント端末と元のサーバ間のより少ないトラフィックへと導かれ、結果として、より少ない輻輳になる。このように、本開示は、サーバからのチャンクのダウンロードの必要性を制限することにより、エンドユーザにより良いユーザ体験を提供することができる。
好ましい実施形態の第１の態様において、補助情報（auxiliary information）がクライアントとサーバの間に配置される残りのキャッシュの数を規定でき、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、補助情報によりリクエストを次のキャッシュへ転送することが可能となる。
特に、残りのキャッシュの最後のキャッシュが、所定のリプレゼンテーション及び他に取り得るリプレゼンテーションを持っていないときに、エラーメッセージがクライアントに送信され得る。
好ましい実施形態の第２の態様において、補助情報は伝送経路に配置される最後のキャッシュを規定でき、それにより、所定のリプレゼンテーションと他に取り得るリプレゼンテーションがこれ以降のキャッシュに保存されていない場合は、リクエストは最後のキャッシュにより転送されない。
有利なことに、最後のキャッシュが所定のリプレゼンテーションと他に取り得るリプレゼンテーションを持たないときは、エラーメッセージは、クライアントに送信されないことができる。
さらに、他に取り得るリプレゼンテーションは望ましい順番で好ましくはブラウズされ、他に取り得るリプレゼンテーションは、例えば、望ましさが減っていく順番でリスト化される。
さらに、それぞれの他に取り得るリプレゼンテーションは、好ましくは所定のリプレゼンテーションの一つより低い対応するビットレートを有する。当然、変形例としては、少なくとも１つの他に取り得るリプレゼンテーションが所定のリプレゼンテーションの一つより高い対応するビットレートを有することもあり得る。
さらに、組の利用可能な各リプレゼンテーションは有利にはクライアント端末とリモートサーバの間の伝送経路の帯域幅と最大でも等しい対応するビットレートを有することができる。
好ましい実施形態の別の態様としては、使用される伝送プロトコルがＨＴＴＰで、リクエストは、ＨＴＴＰリクエストであり、ＨＴＴＰリクエストのキャッシュ制御拡張（Cache Control extension）は他に取り得るリプレゼンテーションのリストを含んでいる。
変形例又は補足として、リクエストは付加情報（additional information）を含むことにより、もしキャッシュされていれば、リクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、あるいは、所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションがキャッシュされていない場合は、応答メッセージを返す。
具体的には、使用される伝送プロトコルがＨＴＴＰの場合、付加情報は、ＨＴＴＰリクエストのキャッシュ制御拡張内に含まれる。
さらに、本開示は、またクライアント端末にマルチメディアコンテンツのコンテンツ部分を提供するように構成されたキャッシュに関し、キャッシュはクライアント端末とリモートサーバの間の伝送経路上に配置され、コンテンツ部分の複数のリプレゼンテーションが利用可能である。
本開示によるキャッシュは、以下のものを含む。
−クライアント端末からのコンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、コンテンツ部分は利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションに属し、リクエストは、さらに、組の他に取り得るリプレゼンテーションのリスト及びリクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
−所定のリプレゼンテーションが保存されているか否かを検査する制御モジュールと、
−所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュール。
好ましくは、他に取り得るリプレゼンテーションは、望ましい順にブラウズされ得る。
好ましい実施形態の第１の態様は、補助情報がクライアントとサーバ間に配置される残りのキャッシュの数を規定し、それにより所定のリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合にリクエストを次のキャッシュに転送し、キャッシュにおいて、残りのキャッシュの数がゼロの場合には、リクエストは好ましくは転送されないことが可能になる。
好ましい実施形態の別の態様では、補助情報は、伝送線路に配置される最後のキャッシュを規定し、リクエストは好ましくは下記の場合に転送され得ない。
−所定のリプレゼンテーション及び他に取り得るリプレゼンテーションがキャッシュに保存されていない場合、且つ
−キャッシュが最後のキャッシュである場合。
開示された実施形態の範囲に対応するいくつかの態様が以下で説明される。これらの態様は単に本開示が取りうるいくつかの形式で概要を読者に提供するためのものであり、これらの態様は、本開示の範囲の制限を意図するものではないことを理解されたい。実際に、本開示は後述されない多くの態様を包含するものである。
本開示は、下記の実施形態や実施例による説明により、制限的な方法ではなく、添付図面を参照してより理解される。
本開示が実装され得るクライアントサーバネットワークアーキテクチャの概略図である。 本開示の好ましい実施形態によるクライアント端末の実施例のブロック図である。 本開示の好ましい実施形態によるキャッシュの実施例のブロック図である。 図３のキャッシュにより実装された所定のチャンクのリプレゼンテーションを検索する方法を説明するフロー図である。
図１から図３において、示されたブロックは、純粋に機能的なエンティティであり、物理的な個別のエンティティに対応する必要はない。すなわち、これらはソフトウェア、ハードウェアの形態で開発され、又は１つ以上のプロセッサを含む１つ以上の集積回路として実装することも可能である。
可能な限り、同じ参照番号は全ての図面において同じ又は類似の要素に使用される。
本開示の図面及び説明は本開示の明確な理解に関連する要素の説明を簡略化したものであり、典型的なデジタルマルチメディアコンテンツ配信方法やシステムにおいて見られる多くの他の要素を明確さのために除外している点を理解されたい。しかしながら、そのような要素は当該技術分野において良く知られるので、そのような要素の詳細な議論はここでは提供しない。ここでの本開示は、当業者に知られているそのような変形や改良を対象にしている。
好ましい実施態様にしたがって、本開示はＨＴＴＰ適応ストリーミングプロトコルに関して説明される。もちろん、本開示は、そのような特定の環境に制限されるものではなく、他の適応ストリーミングプロトコルも考慮され、実装され得る。
図１で説明するように、本開示が実装される得るクライアントサーバネットワークアーキテクチャは、クライアント端末Ｃ、ゲートウェイＧＷ、一つ以上のＨＴＴＰサーバＳ（図１には１つしか示していない）を含む。
クライアント端末Ｃは、第１のネットワークＮ１（例えばホームネットワーク又は企業のネットワーク）を介してゲートウェイＧＷに接続され、第２のネットワークＮ２（例えばインターネットネットワーク）を介してリモートサーバＳに保存されたマルチメディアコンテンツをリクエストし得る。第１のネットワークＮ１は、ゲートウェイＧＷのお陰で第２のネットワークＮ２に接続される。
ＨＴＴＰサーバＳは、クライアントからのリクエストに応じて、１つ以上のＴＣＰ／ＩＰ接続を介してＨＴＴＰ適応ストリーミングプロトコルを使用して、クライアント端末Ｃにチャンクをストリーミングする。
図２に記載された好ましい実施形態にしたがって、クライアント端末Ｃは、少なくとも下記を含む：
−第１のネットワークＮ１への接続インタフェース１（有線及び／又は無線、例えばＷｉ−Ｆｉ、イーサネット（登録商標）等）；
−ＨＴＴＰサーバＳと通信するプロトコルスタックを含む通信モジュール２。具体的には、通信モジュール２は、当該技術分野でよく知られるＴＣＰ／ＩＰスタックを含む。もちろん、クライアント端末ＣのＨＴＴＰサーバＳとの通信を可能にする他のいかなるタイプのネットワーク及び／又は通信手段であっても良い；
−ＨＴＴＰサーバＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する、適応ストリーミングモジュール３。これは対応するビットレートが後述される制約により適合するチャンクのリプレゼンテーションを継続的に選択する；
−マルチメディアコンテンツのデコード及びレンダリングに適合したビデオプレーヤ４；
−クライアント端末Ｃの不揮発性メモリに保存されたアプリケーションとプログラムを実行する１つ以上のプロセッサ５；
−ビデオプレーヤ４に伝送される前にＨＴＴＰサーバＳから受信したチャンクをバッファする、例えば揮発性メモリ等の記憶手段６；
−いくつかのモジュール及び一般的なクライアント端末の機能を実行する技術分野の当業者に周知の全ての手段に接続される内部バスＢ１。
一例として、クライアント端末Ｃは、ポータブルメディアデバイス、携帯電話、タブレット又はラップトップである。当然、クライアント端末Ｃは、完全なビデオプレーヤを含んでいないかも知れないが、メディアコンテンツの逆多重化や復号を行うような部分要素のいくつかのみを含み、エンドユーザに復号済みコンテンツを表示する外部手段に依存しても良い。この場合は、クライアント端末Ｃは、セットトップボックスのようなＨＴＴＰ適応ストリーミング（ＨＡＳ）対応ビデオデコーダである。
図１に記載された好ましい実施形態によると、ゲートウェイＧＷは、キャッシュＲを含み、このキャッシュＲはクライアント端末ＣとサーバＳの間の伝送経路に配置される。変形例としては、キャッシュＲは、第１のネットワークＮ１のプロキシの中又は伝送経路の他の位置に配置され得る。
以下では、クライアント端末ＣがＨＴＴＰ適応ストリーミング（ＨＡＳ）マルチメディアコンテンツをリモートサーバＳに対してリクエストし、ＨＡＳマルチメディアコンテンツは、一連のチャンクから作成されるいくつかのリプレゼンテーションとして利用可能であると仮定する。各リプレゼンテーションの品質は、メディア符号化の品質、メディア符号化のタイプ（例えば２Ｄ対３Ｄ）、メディア符号化カラースキーム等に関連してくることを理解されたい。
この目的を達成するために、図２に示したように、クライアント端末Ｃは、さらに下記を含む。
−伝送経路の帯域幅を推定する、帯域幅推定器７
−クライアント端末Ｃがリクエストし得る利用可能なリプレゼンテーションの組を判定するように構成された、選択モジュール８。利用可能なリプレゼンテーションは、マルチメディアコンテンツの所定のチャンクＩｎの利用可能なリプレゼンテーションの中から選択され、利用可能なリプレゼンテーションは、関連するマニフェストにリスト化される。具体的には、モジュール８による、所定のチャンクＩｎの利用可能なリプレゼンテーションの組の判定は、例えば下記のような一つ以上のパフォーマンス基準に基づく：
・推定器７による帯域幅の推定；
・クライアント端末Ｃの性能；
・以前にリクエストされたチャンクＩｎ−１のリプレゼンテーション；
・クライアント端末Ｃのエンドユーザにより要求される体験品質。
明らかなように、選択モジュール８は、変形例としては、適応ストリーミングモジュール３内に統合され得る。
「利用可能な（allowable）」リプレゼンテーションの意味は、実装に依存することを理解されたい。実際に、以前リクエストされたチャンクＩｎ−１のリプレゼンテーションを比較することにより、所定のチャンクＩｎのリプレゼンテーションの品質は、アップグレード又はダウングレードを意味し得る。
もし所定のチャンクＩｎのリクエストされたリプレゼンテーションが以前にリクエストされたチャンクＩｎ−１のリプレゼンテーションより対応する品質が著しく低い（例えばエンドユーザに可視で）場合は、選択モジュール８は利用可能な帯域幅による制限がある場合を除いて、動作中の潜在的なキャッシュされたチャンクの品質をさらにダウングレードしないように構成され得る。
説明の役に立ち、且つ制限的ではない本開示に準拠している実施例において、所定のチャンクＩｎの利用可能なリプレゼンテーション（マニフェスト中にリスト化された利用可能なリプレゼンテーションから選ばれた）は、推定される帯域幅にほぼ等しい対応するビットレート（所定の品質に関連した）を有する。さらに、組の利用可能なリプレゼンテーションのビットレートは、その品質がクライアント端末Ｃのエンドユーザによって受け入れられない条件下で所定の閾値に少なくとも等しくとも良い。
明らかなように、変形例又は補足として、判定された利用可能なリプレゼンテーションの組は、推定帯域幅より高いビットレートの一つ以上のリプレゼンテーションを含み、それによりキャッシュＲに既に保存されているリプレゼンテーションをフェッチできる。
さらに、適応ストリーミングモジュール３は、利用可能なリプレゼンテーションの組からＨＡＳマルチメディアコンテンツの所定のチャンクＩｎの好ましいリプレゼンテーション（preferred representation）ｒをリクエストするように構成される。例えば、チャンクＩｎの好ましいリプレゼンテーションｒは、推定帯域幅より一寸低い関連するビットレートを有するリプレゼンテーションに対応することができる。
この目的を達成するために、通信モジュール２は、ＨＴＴＰリクエストを送信し、ここで、そのヘッダのキャッシュ制御拡張がディレクティブ「ａｌｔｌｉｓｔ」を含み、クライアント端末Ｃは、好ましいリプレゼンテーションｒがキャッシュされていない場合にキャッシュＲによって返される別のリプレゼンテーションｒ’を望ましい順番又は優先順位にしたがってリスト化する。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’は、判定された組の利用可能なリプレゼンテーションに好ましくは対応する。明らかなように、追加のリプレゼンテーション（例えば、推定される帯域幅より高いビットレートを持つ）が追加される。
以下で、「ａｌｔｌｉｓｔ」ディレクティブを含んでいるＨＴＴＰリクエストの実例を示す：
Figure 2017510120
好ましい実施形態によるキャッシュＲは「ａｌｔｌｉｓｔ」ディレクティブをサポートし、そのコンテンツを解釈するように構成されていると理解されたい。そのようなキャッシュＲは、以下では「スマート（smart）」キャッシュと呼び、他のキャッシュはレガシーキャッシュ（別名非スマートキャッシュ）と呼ばれる。
この目的を達成するために、好ましい実施形態にしたがって、図３に示されるようにスマートキャッシュＲは、以下を含む：
−例えば揮発性メモリ及び／又は永久メモリであり、マルチメディアコンテンツのリクエストをするクライアント端末Ｃへの伝送の前に一つ以上のサーバＳから受信したマルチメディアコンテンツのチャンクを保存する、記憶モジュール９；
−クライアント端末Ｃからコンテンツ部分の好ましいリプレゼンテーションｒに関するＨＴＴＰリクエストを受信するインタフェースモジュール１０であって、好ましいリプレゼンテーションｒは、利用可能なリプレゼンテーションの組に属する、インタフェースモジュール１０。ＨＴＴＰリクエストは「ａｌｔｌｉｓｔ」ディレクティブ内で他に取り得るリプレゼンテーションｒ’を示し、他に取り得るリプレゼンテーションｒ’は、好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより代替品として受け入れられ得る。
−スマートキャッシュＲが既にリクエストされた好ましいリプレゼンテーションｒを持っているか否かを検査するように構成された、制御モジュール１１；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、クライアント端末Ｃにより送信されたＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブ中にリスト化された他に取り得るリプレゼンテーションを望ましい順にブラウズするように適合された、ブラウジングモジュール１２。変形例としては、制御モジュール及びブラウジングモジュールは、ただ一つのモジュールを形成する。
クライアント端末Ｃから所定のチャンクＩｎの好ましいリプレゼンテーションｒに関するそのようなＨＴＴＰリクエストの受信に応じて、スマートキャッシュＲの制御モジュール１１は好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する。
−キャッシュされている場合は、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションｒを返す。
−キャッシュされていない場合は、ブラウジングモジュール１２は、他に取り得るリプレゼンテーションｒ’がキャッシュされているか否か望ましい順番の連続検査に対して、ＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。
「ａｌｔｌｉｓｔ」ディレクティブのそのような他に取り得るリプレゼンテーションｒ’がキャッシュされているとき、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。
「ａｌｔｌｉｓｔ」の他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、スマートキャッシュＲは、クライアント端末ＣによってサーバＳに送信されたＨＴＴＰリクエストをリリース（release）するように構成される。
リリースされたＨＴＴＰリクエストは、その後、スマートキャッシュＲとリモートサーバＳの間の伝送経路にある次のキャッシュによって捉えられ、もし次のキャッシュがスマートキャッシュなら、スマートキャッシュＲとして振る舞う。そうでない場合は（次のキャッシュが「ａｌｔｌｉｓｔ」ディレクティブをサポートしていない場合）、エラーメッセージが返されるか、又はサーバＳに対するＨＴＴＰリクエストがリリースされ得る。
改良版としては、クライアント端末Ｃの通信モジュール２により送信されたＨＴＴＰリクエストが、補助ディレクティブ（補助情報を定義する）「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」（ＴＴＬ）をヘッダのキャッシュ制御拡張に含むことができる。「Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ」ディレクティブ（トークンとも呼ばれる）は、「ａｌｔｌｉｓｔ」ディレクティブを繰り返し利用することを可能にする。この目的を達成するために、ＴＴＬディレクティブ（ＨＴＴＰリクエストの範囲を指定する）は、クライアント端末ＣとサーバＳの間に配置された残りのキャッシュ（スマートキャッシュ又はレガシーキャッシュ）の数を定義するＴＴＬ値と関連し、それにより、好ましいリプレゼンテーション及び他に取り得るリプレゼンテーションが保存されていない場合に、次のキャッシュにリクエストを転送することが可能となる。実際に、クライアント端末からリクエストを受信する各キャッシュ（スマートキャッシュ又はレガシーキャッシュ）が処理し、リクエストのＴＴＬ値をデクリメントしながら転送する。リクエストのＴＴＬ値がゼロに等しいとき、リクエストは、最早転送されず、エラーコード（例えば４１２）と共に応答がクライアント端末Ｃに送信され得る。失敗の理由が応答に追加されることもできる。
以下で「ａｌｔｌｉｓｔ」及び「ＴＴＬ」ディレクティブを含むＨＴＴＰリクエストの実例を示す：
Figure 2017510120
さらなる改良版又は補足として、クライアント端末Ｃの通信モジュール２によって送信されたＨＴＴＰリクエストは、補助ディレクティブ「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブをヘッダのキャッシュ制御拡張に含むことができる。「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブ（ＨＴＴＰリクエストの範囲を指定する）は、最後のキャッシュを特定する値（例えば、キャッシュのＩＰアドレス、修飾ドメイン名、又は他の種類の識別子）と関連している。
「ｕｎｔｉｌ ｅｌｅｍｅｎｔ」ディレクティブは、それ以降のキャッシュが好ましいリプレゼンテーション又は「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションを含まない場合、所定の最後のキャッシュに到達したときは誰にもＨＴＴＰリクエストを転送しない点を除いて、ＴＴＬディレクティブと同様に動作する。その場合、エラーコード（例えば４１２）を含む応答は、好ましくは生成され、クライアント端末Ｃに送信される。失敗の理由が応答に追加されることもできる。
図４に示したように、好ましい実施形態によるキャッシュＲは、クライアント端末ＣにＨＡＳマルチメディアコンテンツの所定のチャンクＩｎのリクエストされたリプレゼンテーションを提供するための以下のメカニズムＭを実施するように構成される。メカニズムＭは、以下のステップを含む：
−クライアント端末Ｃから以前に定義した利用可能なリプレゼンテーションの組に属する所定のチャンクＩｎ部分の好ましいリプレゼンテーションに対するＨＴＴＰリクエストを受信するステップ（ステップ Ｓ０）。ＨＴＴＰリクエストは、さらに、組の他に取り得るリプレゼンテーションをリスト化する「ａｌｔｌｉｓｔ」ディレクティブを含む。；
−好ましいリプレゼンテーションｒが記憶モジュール９に保存されているか検査するステップ（ステップ Ｓ１）；
−好ましいリプレゼンテーションｒがキャッシュされていない場合に、「ａｌｔｌｉｓｔ」ディレクティブにリスト化された他に取り得るリプレゼンテーションｒ’を望ましい順にブラウズするステップ（ステップ Ｓ２）；
−他に取り得るリプレゼンテーションのいずれもがスマートキャッシュＲの記憶モジュール９にキャッシュされていないとき、サーバＳに対するＨＴＴＰリクエストをリリースするステップ（ステップ Ｓ３）。
好ましい実施形態の変形例として、クライアント端末Ｃから送信されたＨＴＴＰリクエストのキャッシュ制御拡張は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」という名前の追加のディレクティブ（追加情報を規定する）をさらに含む。「ａｌｔｌｉｓｔ」ディレクティブは、キャッシュ制御ヘッダの「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ上の優先順位を維持する。以下で上述のディレクティブを含むＨＴＴＰリクエストの例を示す：
Figure 2017510120
変形例として、所定のチャンクＩｎの好ましいリプレゼンテーションｒに関するＨＴＴＰリクエスト（「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」及び「ａｌｔｌｉｓｔ」の両方を含む）の受領に応答して、スマートキャッシュＲは、好ましいリプレゼンテーションｒがキャッシュされているか否かを検査する：
−キャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに好ましいリプレゼンテーションＲを返す；
−キャッシュされていない場合、ブラウジングモジュール１２は、一つの別のリプレゼンテーションｒ’がキャッシュされているか否か望ましい順での連続する検査のためＨＴＴＰリクエストの「ａｌｔｌｉｓｔ」ディレクティブをブラウズする。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’がキャッシュされている場合、スマートキャッシュＲは、クライアント端末Ｃに他に取り得るリプレゼンテーションｒ’を返す。
「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションｒ’が一つもキャッシュされていない場合は、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブのお陰で、スマートキャッシュＲが次にエラーメッセージ（例えば「http/1.1 504 altlistがサポートされている」）を返すように構成され、これらは以下のことを示す：
−好ましいリプレゼンテーションｒがキャッシュされていない；
−キャッシュＲが「ａｌｔｌｉｓｔ」ディレクティブをサポートしており、そのようなエラーメッセージの受領から「ａｌｔｌｉｓｔ」ディレクティブの他に取り得るリプレゼンテーションのいずれもがキャッシュされてないことが導き出せる。
さらなるステップで、クライアント端末Ｃは、サーバＳから直接所定のチャンクＩｎの好ましいリプレゼンテーションｒを検索するためにリモートサーバＳに新たなリクエストを送信できる。この目的のために、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブ又は「ａｌｔｌｉｓｔ」ディレクティブのいずれもがこの新たなリクエストのヘッダで使用されない。明らかなように、この新たなリクエストは、「ｏｎｌｙ＿ｉｆ＿ｃａｃｈｅｄ」ディレクティブを含まず、「ａｌｔｌｉｓｔ」ディレクティブのみを含むことができる。
本明細書に開示された参照、請求項及び図面は、独立して、又は適切な組合せとして提供され得る。特徴は、適切であれば、ハードウェア、ソフトウェア又はそれらの組合せとして実装することができる。
請求項における参照番号は、説明のためのものであり、請求項の範囲を制限する効果を持つものではない。
好ましい実施形態に記載された本開示は、発明能力を行使することなく、本技術分野の当業者の能力の範囲内で多くの変形例や実施形態を許容できることは明白である。したがって、開示の範囲は、添付の請求項の範囲により規定される。
添付請求項において、特定の機能を実現する手段として表現された構成要素（例えば、適応ストリーミングモジュール３、帯域幅推定器７、選択モジュール８、制御モジュール１１、ブラウジングモジュール１２等）は、これらの機能を実施するためのいかなる方法、例えば、ａ）機能を実行する回路要素の組合せ（例えば一つ以上のプロセッサ）又はｂ）ファームウェア、マイクロコード等、機能を実施するためのソフトウェアを実行するための適切な回路との組合せ等を含むいかなる形式のソフトウェアも包含することを意図する。請求項によって規定される本原理は、様々な引用される手段によって提供される機能性が請求項が請求する態様で結合され、組み合わせられるという事実に存在する。したがって、これらの機能を提供できるいかなる手段も本明細書に示されたものと均等物と見なされる。
ここでいくつかの付記を記載する。
（付記１）
マルチメディアコンテンツのコンテンツ部分をクライアント端末に提供する方法であって、一つ以上のキャッシュが前記クライアント端末とリモートサーバとの間の伝送経路に配置され、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記方法が、
第１のキャッシュで、前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、受信するステップと、
前記所定のリプレゼンテーションが前記キャッシュに保存されているかを前記第１のキャッシュで検査するステップと、
前記所定のリプレゼンテーションがキャッシュされていない場合に、前記第１のキャッシュでリストに記載された他に取り得るリプレゼンテーションをブラウズするステップと、
を含む、方法。
（付記２）
前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に、前記リクエストを次のキャッシュに転送することを可能にする、付記１に記載の方法。
（付記３）
前記残りのキャッシュの最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有していないとき、エラーメッセージが前記クライアントへ送信される、付記２に記載の方法。
（付記４）
前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが後ろのキャッシュに保存されていない場合に、前記最後のキャッシュによってリクエストが転送されない、付記１乃至３のいずれか１項に記載の方法。
（付記５）
前記最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有しない場合に、エラーメッセージが前記クライアントに送信される、付記４に記載の方法。
（付記６）
前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、付記１乃至５のいずれか１項に記載の方法。
（付記７）
各他に取り得るリプレゼンテーションが前記所定のリプレゼンテーションのビットレートよりも低い対応するビットレートを有する、付記１乃至６のいずれか１項に記載の方法。
（付記８）
前記組の各利用可能なリプレゼンテーションが、前記クライアント端末と前記リモートサーバの間の前記伝送経路の帯域幅に最大限で等しい対応するビットレートを有する、付記７に記載の方法。
（付記９）
伝送プロトコルとしてＨＴＴＰが使用され、前記リクエストはＨＴＴＰリクエストであり、前記ＨＴＴＰリクエストのキャッシュ制御拡張が他に取り得るリプレゼンテーションの前記リストを含む、付記１乃至８のいずれか１項に記載の方法。
（付記１０）
前記リクエストが、追加情報を含み、キャッシュされている場合は前記第１のキャッシュがリクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、前記所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションのいずれもがキャッシュされていない場合は応答メッセージを返す、付記１乃至９のいずれか１項に記載された方法。
（付記１１）
使用される前記伝送プロトコルがＨＴＴＰであり、前記追加情報が前記ＨＴＴＰリクエストの前記キャッシュ制御拡張内に含まれる、付記１０に記載の方法。
（付記１２）
クライアント端末とリモートサーバとの間の伝送経路に配置され、マルチメディアコンテンツのコンテンツ部分を前記クライアント端末に提供するキャッシュであって、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記キャッシュが、
前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
前記所定のリプレゼンテーションが保存されているかを検査する制御モジュールと、
前記所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュールと、
を含む、キャッシュ。
（付記１３）
前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、付記１２に記載されたキャッシュ。
（付記１４）
前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に前記リクエストを次のキャッシュに転送することを可能にし、前記キャッシュにおいて、残りのキャッシュの数がゼロに等しいときは前記リクエストを転送しない、付記１２又は１３に記載のキャッシュ。
（付記１５）
前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、前記リクエストは、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが前記キャッシュに保存されておらず、且つ、前記キャッシュが前記最後のキャッシュに対応している場合に、転送されない、付記１２乃至１４のいずれか１項に記載のキャッシュ。

Claims (15)

  1. マルチメディアコンテンツのコンテンツ部分をクライアント端末に提供する方法であって、一つ以上のキャッシュが前記クライアント端末とリモートサーバとの間の伝送経路に配置され、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記方法が、
    第１のキャッシュで、前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するステップであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、受信するステップと、
    前記所定のリプレゼンテーションが前記キャッシュに保存されているかを前記第１のキャッシュで検査するステップと、
    前記所定のリプレゼンテーションがキャッシュされていない場合に、前記第１のキャッシュでリストに記載された他に取り得るリプレゼンテーションをブラウズするステップと、
    を含む、方法。
  2. 前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に、前記リクエストを次のキャッシュに転送することを可能にする、請求項１に記載の方法。
  3. 前記残りのキャッシュの最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有していないとき、エラーメッセージが前記クライアントへ送信される、請求項２に記載の方法。
  4. 前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが後ろのキャッシュに保存されていない場合に、前記最後のキャッシュによってリクエストが転送されない、請求項１乃至３のいずれか１項に記載の方法。
  5. 前記最後のキャッシュが前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションを有しない場合に、エラーメッセージが前記クライアントに送信される、請求項４に記載の方法。
  6. 前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、請求項１乃至５のいずれか１項に記載の方法。
  7. 各他に取り得るリプレゼンテーションが前記所定のリプレゼンテーションのビットレートよりも低い対応するビットレートを有する、請求項１乃至６のいずれか１項に記載の方法。
  8. 前記組の各利用可能なリプレゼンテーションが、前記クライアント端末と前記リモートサーバの間の前記伝送経路の帯域幅に最大限で等しい対応するビットレートを有する、請求項７に記載の方法。
  9. 伝送プロトコルとしてＨＴＴＰが使用され、前記リクエストはＨＴＴＰリクエストであり、前記ＨＴＴＰリクエストのキャッシュ制御拡張が他に取り得るリプレゼンテーションの前記リストを含む、請求項１乃至８のいずれか１項に記載の方法。
  10. 前記リクエストが、追加情報を含み、キャッシュされている場合は前記第１のキャッシュがリクエストされたリプレゼンテーション又はリストに記載された他に取り得るリプレゼンテーションを返し、前記所定のリプレゼンテーション及びリストに記載された他に取り得るリプレゼンテーションのいずれもがキャッシュされていない場合は応答メッセージを返す、請求項１乃至９のいずれか１項に記載された方法。
  11. 使用される前記伝送プロトコルがＨＴＴＰであり、前記追加情報が前記ＨＴＴＰリクエストの前記キャッシュ制御拡張内に含まれる、請求項１０に記載の方法。
  12. クライアント端末とリモートサーバとの間の伝送経路に配置され、マルチメディアコンテンツのコンテンツ部分を前記クライアント端末に提供するキャッシュであって、前記コンテンツ部分の複数のリプレゼンテーションが利用可能であり、前記キャッシュが、
    前記クライアント端末から前記コンテンツ部分の所定のリプレゼンテーションに対するリクエストを受信するインタフェースモジュールであって、前記コンテンツ部分は、前記利用可能なリプレゼンテーションの中から選択された利用可能なリプレゼンテーションの組に属し、前記リクエストは、さらに、前記組の他に取り得るリプレゼンテーションのリスト及び前記リクエストの範囲を特定する補助情報を含む、インタフェースモジュールと、
    前記所定のリプレゼンテーションが保存されているかを検査する制御モジュールと、
    前記所定のリプレゼンテーションがキャッシュされていない場合に、リストに記載された他に取り得るリプレゼンテーションをブラウズするブラウジングモジュールと、
    を含む、キャッシュ。
  13. 前記他に取り得るリプレゼンテーションが望ましい順番でブラウズされる、請求項１２に記載されたキャッシュ。
  14. 前記補助情報が、前記クライアントと前記サーバの間に配置された残りのキャッシュの数を規定し、それにより、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが保存されていない場合に前記リクエストを次のキャッシュに転送することを可能にし、前記キャッシュにおいて、残りのキャッシュの数がゼロに等しいときは前記リクエストを転送しない、請求項１２又は１３に記載のキャッシュ。
  15. 前記補助情報が前記伝送経路に配置された最後のキャッシュを規定し、前記リクエストは、前記所定のリプレゼンテーション及び前記他に取り得るリプレゼンテーションが前記キャッシュに保存されておらず、且つ、前記キャッシュが前記最後のキャッシュに対応している場合に、転送されない、請求項１２乃至１４のいずれか１項に記載のキャッシュ。
JP2016544798A 2014-01-07 2014-06-12 クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ Active JP6538061B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP14305015.1 2014-01-07
EP14305015 2014-01-07
PCT/EP2014/062215 WO2015104070A1 (en) 2014-01-07 2014-06-12 Method for providing a content part of a multimedia content to a client terminal, corresponding cache

Publications (3)

Publication Number Publication Date
JP2017510120A true JP2017510120A (ja) 2017-04-06
JP2017510120A5 JP2017510120A5 (ja) 2017-07-20
JP6538061B2 JP6538061B2 (ja) 2019-07-03

Family

ID=49999852

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016544798A Active JP6538061B2 (ja) 2014-01-07 2014-06-12 クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ

Country Status (9)

Country Link
US (1) US10735544B2 (ja)
EP (1) EP3092811B1 (ja)
JP (1) JP6538061B2 (ja)
KR (1) KR102212973B1 (ja)
CN (1) CN105900433B (ja)
AU (1) AU2014377337B2 (ja)
BR (1) BR112016015878B1 (ja)
TW (2) TW201527979A (ja)
WO (1) WO2015104070A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033824B2 (en) * 2014-06-30 2018-07-24 Samsung Electronics Co., Ltd. Cache manifest for efficient peer assisted streaming
US10152080B2 (en) 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
WO2021009597A1 (en) 2019-07-12 2021-01-21 Carrier Corporation A system and a method for streaming videos by creating object urls at client

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006171822A (ja) * 2004-12-13 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信方法
WO2012107341A2 (en) * 2011-02-07 2012-08-16 Alcatel Lucent A cache manager for segmented multimedia and corresponding method for cache management
US20120284371A1 (en) * 2011-05-03 2012-11-08 Cisco Technology, Inc. Reducing Fetching Load on Cache Servers in Adaptive Streaming
JP2013069073A (ja) * 2011-09-21 2013-04-18 Nec Corp 配信ネットワークとサーバ及び配信方法
US20130173737A1 (en) * 2011-12-29 2013-07-04 Nokia Corporation Method and apparatus for flexible caching of delivered media

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8756342B1 (en) * 2000-02-07 2014-06-17 Parallel Networks, Llc Method and apparatus for content synchronization
GB2366965A (en) * 2000-09-01 2002-03-20 Ncr Int Inc Downloading data to a requesting client form the local cache of another client
US6820114B2 (en) * 2001-09-27 2004-11-16 Sap Aktiengesellschaft Identifying object suppliers in a network
US8650266B2 (en) * 2002-03-26 2014-02-11 At&T Intellectual Property Ii, L.P. Cache validation using smart source selection in a data network
US7076544B2 (en) 2002-04-08 2006-07-11 Microsoft Corporation Caching techniques for streaming media
US7085894B2 (en) * 2003-09-11 2006-08-01 International Business Machines Corporation Selectively accepting cache content
WO2008098249A1 (en) 2007-02-09 2008-08-14 Dilithium Networks Pty Ltd. Method and apparatus for the adaptation of multimedia content in telecommunications networks
US20090094224A1 (en) * 2007-10-05 2009-04-09 Google Inc. Collaborative search results
US8799409B2 (en) * 2009-01-15 2014-08-05 Ebay Inc. Server side data cache system
US9310959B2 (en) * 2009-06-01 2016-04-12 Zya, Inc. System and method for enhancing audio
KR101218828B1 (ko) * 2009-07-02 2013-01-04 (주)에임투지 요청배정장치를 이용한 상호협력캐시 방법 및 컨텐츠 제공 방법
US8000259B2 (en) * 2009-09-04 2011-08-16 Viasat, Inc. Distributed cache—adaptive multicast architecture for bandwidth reduction
US8560598B2 (en) * 2009-12-22 2013-10-15 At&T Intellectual Property I, L.P. Integrated adaptive anycast for content distribution
EP2410744A1 (en) * 2010-07-23 2012-01-25 Alcatel Lucent Method for transferring video segments, client entity and proxy entity realizing such a method
US20120194534A1 (en) 2011-02-02 2012-08-02 Alcatel-Lucent Usa Inc. System and Method for Managing Cache Storage in Adaptive Video Streaming System
WO2012125006A2 (ko) * 2011-03-16 2012-09-20 한국전자통신연구원 레프리젠테이션을 사용하는 스트리밍 콘텐츠 제공 장치 및 방법
CN102204218B (zh) * 2011-05-31 2015-01-21 华为技术有限公司 数据处理方法、缓存节点、协作控制器及系统
US9729603B2 (en) * 2012-09-27 2017-08-08 Alcatel Lucent Content stream delivery using variable cache replacement granularity
US9621399B1 (en) * 2012-12-19 2017-04-11 Amazon Technologies, Inc. Distributed caching system
EP2819368A1 (en) * 2013-06-28 2014-12-31 Thomson Licensing Method for providing a content part of a multimedia content to a client terminal, corresponding cache
US9887958B2 (en) * 2013-09-16 2018-02-06 Netflix, Inc. Configuring DNS clients
US8819187B1 (en) * 2013-10-29 2014-08-26 Limelight Networks, Inc. End-to-end acceleration of dynamic content
US9325639B2 (en) * 2013-12-17 2016-04-26 At&T Intellectual Property I, L.P. Hierarchical caching system for lossless network packet capture applications
US9792050B2 (en) * 2014-08-13 2017-10-17 PernixData, Inc. Distributed caching systems and methods

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006171822A (ja) * 2004-12-13 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> コンテンツ配信方法
WO2012107341A2 (en) * 2011-02-07 2012-08-16 Alcatel Lucent A cache manager for segmented multimedia and corresponding method for cache management
JP2014511519A (ja) * 2011-02-07 2014-05-15 アルカテル−ルーセント セグメント化されたマルチメディアのためのキャッシュマネージャおよび対応するキャッシュ管理の方法
US20120284371A1 (en) * 2011-05-03 2012-11-08 Cisco Technology, Inc. Reducing Fetching Load on Cache Servers in Adaptive Streaming
JP2013069073A (ja) * 2011-09-21 2013-04-18 Nec Corp 配信ネットワークとサーバ及び配信方法
US20130173737A1 (en) * 2011-12-29 2013-07-04 Nokia Corporation Method and apparatus for flexible caching of delivered media

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DILIP KUMAR KRISHNAPPA, ET AL.: "DASHing YouTube: An analysis of using DASH in YouTube video service", LOCAL COMPUTER NETWORKS (LCN), 2013 IEEE 38TH CONFERENCE ON, JPN6018014257, 21 October 2013 (2013-10-21), pages 407 - 415, XP032575918, ISSN: 0003781359, DOI: 10.1109/LCN.2013.6761273 *
VIJAY KUMAR ADHIKARI, ET AL.: "Where Do You "Tube"? Uncovering YouTube Server Selection Strategy", COMPUTER COMMUNICATIONS AND NETWORKS (ICCCN), 2011 PROCEEDINGS OF 20TH INTERNATIONAL CONFERENCE ON, JPN6018014260, 31 July 2011 (2011-07-31), pages 1 - 6, XP032049220, ISSN: 0003781360, DOI: 10.1109/ICCCN.2011.6006028 *
藤本章宏, 他: "階層型キャッシュサーバ環境における経路の排反性を利用した高品位ストリーミング手法", 電子情報通信学会技術研究報告, vol. 112, no. 463, JPN6018014262, 28 February 2013 (2013-02-28), pages 237 - 242, ISSN: 0003781361 *

Also Published As

Publication number Publication date
KR102212973B1 (ko) 2021-02-04
EP3092811A1 (en) 2016-11-16
CN105900433B (zh) 2020-02-21
BR112016015878A2 (ja) 2017-08-08
TWI634789B (zh) 2018-09-01
CN105900433A (zh) 2016-08-24
KR20160105803A (ko) 2016-09-07
AU2014377337A1 (en) 2016-08-18
TW201528806A (zh) 2015-07-16
US10735544B2 (en) 2020-08-04
EP3092811B1 (en) 2020-02-12
TW201527979A (zh) 2015-07-16
WO2015104070A1 (en) 2015-07-16
AU2014377337B2 (en) 2019-08-01
JP6538061B2 (ja) 2019-07-03
BR112016015878B1 (pt) 2023-02-23
US20160330289A1 (en) 2016-11-10

Similar Documents

Publication Publication Date Title
CN106105145B (zh) 用于操作沿客户端终端和至少一个服务器之间的传输路径布置的缓存器的方法、及相应的缓存器
KR102335495B1 (ko) 클라이언트 단말기들과 적어도 하나의 서버 사이의 송신 경로를 따라 배열된 캐시를 작동시키기 위한 방법, 및 대응하는 캐시
JP6550405B2 (ja) クライアント端末と少なくとも１つのサーバとの間の伝送経路に沿って配置されたネットワーク装置を動作させる方法およびそれに対応するネットワーク装置
JP6538061B2 (ja) クライアント端末にマルチメディアコンテンツのコンテンツ部分を提供する方法及び対応するキャッシュ
EP2819368A1 (en) Method for providing a content part of a multimedia content to a client terminal, corresponding cache
US10348789B2 (en) Method for retrieving, by a client terminal, a content part of a multimedia content
WO2015104146A1 (en) Method for obtaining network information by a client terminal configured for receiving a multimedia content divided into segments

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170607

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170607

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180313

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180424

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20181220

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20181227

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20190107

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190329

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20190411

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190508

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190605

R150 Certificate of patent or registration of utility model

Ref document number: 6538061

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250