JP6686029B2 - サーバデバイスによるリソースの改善されたクライアント主導型プッシュ - Google Patents

サーバデバイスによるリソースの改善されたクライアント主導型プッシュ Download PDF

Info

Publication number
JP6686029B2
JP6686029B2 JP2017537233A JP2017537233A JP6686029B2 JP 6686029 B2 JP6686029 B2 JP 6686029B2 JP 2017537233 A JP2017537233 A JP 2017537233A JP 2017537233 A JP2017537233 A JP 2017537233A JP 6686029 B2 JP6686029 B2 JP 6686029B2
Authority
JP
Japan
Prior art keywords
data
push
client
server
request
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.)
Active
Application number
JP2017537233A
Other languages
English (en)
Other versions
JP2018509679A5 (ja
JP2018509679A (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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Publication of JP2018509679A publication Critical patent/JP2018509679A/ja
Publication of JP2018509679A5 publication Critical patent/JP2018509679A5/ja
Application granted granted Critical
Publication of JP6686029B2 publication Critical patent/JP6686029B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/55—Push-based network services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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
    • 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/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/454—Content or additional data filtering, e.g. blocking advertisements
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

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

Description

本発明は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌを表す）通信ネットワークを通してのデータ送信、例えばデータストリーミング、に関し、より正確にはサーバデバイスによるリソースのクライアント主導型プッシュに関する。
ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰの頭字語）メディアコンテンツストリーミングなどの、ＨＴＴＰを通しての通信においては、クライアントデバイスによってサーバデバイスに対して大量のデータが要求されることがある。そうするために、クライアントデバイスは、普通、メソッド（例えば“ＧＥＴ”）と、場合によってはＨＴＴＰリクエスト内の１つまたは複数の追加のヘッダ（例えば、そのユニフォームリソースアイデンティファイア（ＵＲＩ：ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）により特定されるリソースの中のバイトレンジを提供するレンジ（Ｒａｎｇｅ）ヘッダ）と共に、サーバデバイス上の要求されたデータを特定して位置を示すＵＲＩとから成るリクエストラインを各々含むＨＴＴＰリクエストを送る。
クライアントデバイスによってまだ要求されていないデータをサーバデバイスが自発的にプッシュできるようにするためにサーバプッシュフィーチャが開発されている。これは、ウェブリソースのローディング時間を短縮するために有益なフィーチャである。
サーバプッシュフィーチャは、請求されていないウェブリソースリプリゼンテーションをサーバデバイスがクライアントデバイスに送ることを可能にするためにＨＴＴＰ／２（これは単一の現存するコネクションの中で数個のリクエスト／レスポンスを交換すること、すなわち数個のストリームを持つこと、をも可能にする）において導入されている。ウェブページなどのウェブリソースは一般的に他のリソースへのリンクを含んでおり、それら自身が他のリソースへのリンクを含むことがある。ウェブページを完全に表示するためには、一般的に、全てのリンクされているリソースおよびサブリンクされているリソースがクライアントデバイスにより取り出されなければならない。この増加する発見は、特にモバイルネットワークなどの大レイテンシのネットワーク上では、ウェブページの低速の表示につながる可能性がある。
所与のウェブページに対するリクエストを受け取るとき、サーバデバイスは、要求されているリソースの完全な処理のために他のどのリソースが必要かを判定することができる。要求されたリソースと、リンクされているリソースとを同時に送ることにより、サーバデバイスはそのウェブページのローディング時間を短縮することを可能にする。従って、プッシュフィーチャを使って、サーバデバイスは、所与のリソースを要求された時点で追加リソースのリプリゼンテーションを送ることができる。
データのプッシュは、ＤＡＳＨと関連して、例えば本出願人の、特許文献１として公開された出願においても提案されている。
この刊行物は、ユーザの経験を最適化するためにデータストリーミングを、特にＤＡＳＨベースの通信と関連して、改善しようとしている。その理由は、在来のメカニズムにおいては、クライアントおよびサーバデバイスにとっては約束されたデータが所要の時に送られ受け取られるかどうか分からず、クライアントデバイスにとってはビデオセグメントが何時どんな順序で送られるか分からないかもしれないことにある。さらに、サーバデバイスによってプッシュまたはアナウンスされた約束のデータはクライアントデバイスのニーズに合わないかもしれず（これは時間が経つにつれて進化する可能性がある）、従って特にサーバエンドにおいてリソースが浪費される結果につながるかもしれない。従って特許文献１は、サーバデバイスとクライアントデバイスとがプッシュポリシーを共有することを提案している。
この共有は、クライアントデバイスが、どのデータがプッシュされかけているかを前もって知り、その後、ネットワーク帯域幅の浪費を避けるためにそのようなプッシュのキャンセルを準備するために役立つ。
しかし、この刊行物において提案されているメカニズムは、特に、プッシュポリシーに従ってどのデータまたはリソースをプッシュするかを決定するためにＸＭＬベースのＤＡＳＨ“メディアプレゼンテーション記述”ファイル（ＭＰＤ：ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ）に対してプッシュポリシーを適用し得るように、サーバデバイスがＤＡＳＨについての極めて複雑な知識を持つことを要求する。
ＭＰＤファイルはメディアコンテンツの構造をメディアセグメントに記述することに注意されたい。ＭＰＤファイルは、サーバデバイスとクライアントデバイスとの間で交換され、後者に、後者がメディアコンテンツのデリバリを制御することを可能にする、すなわち後者が各メディアセグメントを個別に要求することを可能にする、情報を与える。
国際公開第２０１５／００４２７６号
この文脈において、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法を提供し、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストはサーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに、第２データをプッシュすることに関連する指示を含む１つまたは複数の追加のヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；
第２データをプッシュすることに関連する指示を表す確認応答データをクライアントデバイスに送るステップ；および
１つまたは複数のヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、を用いて、サーバデバイス上の第２データの特定を可能にする第２データ特定情報を決定するステップ；
を含む。
従って、本発明の方法は、クライアントデバイスがサーバデバイスにより適用されるプッシュポリシーを考慮して自分の振る舞いを適合させることを可能にする。
複数の実施形態において、この方法はさらに：
第２データのプッシュをアナウンスするプッシュ約束メッセージをクライアントデバイスに送るステップおよび／または第２データをクライアントデバイスにプッシュするステップを含む。
複数の実施形態において、確認応答データは、第２データをプッシュするための指示を表す。
複数の実施形態において、確認応答データは、ＨＴＴＰリクエストに応じての第２データのプッシュは行われないことを示す。
複数の実施形態において、第２データをプッシュすることに関連する指示は、第２データをプッシュすることに関連する少なくとも２つの異なる指示を含むリストを含む。
複数の実施形態において、確認応答データは第２データをプッシュすることに関連する少なくとも２つの異なる指示のうちの１つを含み、第２データをプッシュすることに関連するその少なくとも２つの異なる指示のうちの前記の１つは、クライアントデバイスにプッシュされるべき第２データを特定するために使用される。
複数の実施形態において、第２データをプッシュすることに関連する指示は第２データのデータのタイプと関連付けられ、そのデータのタイプは記述データタイプまたはコンテンツデータタイプを含み、第２データはコンテンツデータにまたは記述データに属する。
複数の実施形態において、第２データをプッシュすることに関連する指示は、メディアプレゼンテーション記述アップデートをプッシュすることに向けられる。
複数の実施形態において、確認応答データは、第２データをプッシュすることに関連する指示を含み、確認応答データ内の第２データをプッシュすることに関連する指示は、ＨＴＴＰリクエスト内の第２データをプッシュすることに関連する指示とは異なる。
複数の実施形態において、第２データをプッシュすることに関連する指示は、少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュするためのディレクティブとプッシュされるべき第２データのアイデンティフィケーションとを表すかまたは第２データをプッシュしないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は、少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、サーバデバイスとクライアントデバイスとの間でデータを送信する方法が提供され、この方法は、クライアントデバイスにおいて：
サーバデバイスから得られるべきデータを特定するステップ；
特定されたデータから第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともにサーバデバイスが第２データをプッシュするべきか第２データをプッシュするべきでないかに関する指示を含む１つまたは複数の追加のヘッダフィールドを含む、生成するステップ；
第１データを得るとともにサーバデバイスに第２データをプッシュさせまたはプッシュさせないためにＨＴＴＰリクエストをサーバデバイスに送るステップ；および
ＨＴＴＰリクエストを送ることに応答して確認応答データをサーバデバイスから受け取るステップであって、確認応答データは第２データをプッシュすることに関連する指示を表す、受け取るステップ；を含み、
１つまたは複数の追加のヘッダフィールドは、１つまたは複数の追加のヘッダフィールドだけに、および場合によってはさらに第１データ特定情報に、基づいて、サーバデバイス上の特定されたデータから第２データの特定を可能にする第２データ特定情報を定義する。
従って、本発明の方法は、クライアントデバイスがサーバデバイスにより適用されるプッシュポリシーを考慮して自身の振る舞いを適合させることを可能にする
複数の実施形態において、確認応答データは、第２データをプッシュするための指示を表す。
複数の実施形態において、確認応答データは、ＨＴＴＰリクエストに応答しての第２データのプッシュは行われないことを示す。
複数の実施形態において、第２データをプッシュすることに関連する指示は、第２データをプッシュすることに関連する少なくとも２つの異なる指示を含むリストを含む。
複数の実施形態において、確認応答データは第２データをプッシュすることに関連する少なくとも２つの異なる指示のうちの１つを含み、第２データをプッシュすることに関連する少なくとも２つの異なる指示のうちの前記の１つは、クライアントデバイスにプッシュされるべき第２データを特定するためにサーバデバイスにより使用される。
複数の実施形態において、第２データをプッシュすることに関連する指示は第２データのデータのタイプと関連付けられ、そのデータのタイプは記述データタイプまたはコンテンツデータタイプを含み、第２データはコンテンツデータにまたは記述データに属する。
複数の実施形態において、第２データをプッシュすることに関連する指示は、記述データアップデートをプッシュすることに向けられる。
複数の実施形態において、確認応答データは、第２データをプッシュすることに関連する指示を含み、確認応答データ内の第２データをプッシュすることに関連する指示は、ＨＴＴＰリクエスト内の第２データをプッシュすることに関連する指示とは異なる。
複数の実施形態において、第２データをプッシュすることに関連する指示は、少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュするためのディレクティブとプッシュされるべき第２データのアイデンティフィケーションとを表すかまたは第２データをプッシュしないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は、少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、サーバデバイスとクライアントデバイスとの間でデータを送信する方法が提供され、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストはサーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに、１つまたは複数の追加のヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；および
１つまたは複数の追加のフィールドに含まれる第２データをプッシュすることに関連する指示の関数として第２データをクライアントデバイスにプッシュするかまたはプッシュしないステップ；
を含む。
従って、本発明の方法は、有益なデータをクライアントデバイスにプッシュするサーバデバイスの能力を改善する。
複数の実施形態において、第２データをプッシュすることに関連する指示は、第２データをプッシュすることに関連する少なくとも２つの異なる指示を含むリストを含む。
複数の実施形態において、第２データをプッシュすることに関連する指示は第２データのデータのタイプと関連付けられ、そのデータのタイプは記述データタイプまたはコンテンツデータタイプを含み、第２データはコンテンツデータにまたは記述データに属する。
複数の実施形態において、第２データをプッシュすることに関連する指示は、記述データアップデートをプッシュすることに向けられる。
複数の実施形態において、第２データをプッシュすることに関連する指示は、少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュするためのディレクティブとプッシュされるべき第２データのアイデンティフィケーションとを表すかまたは第２データをプッシュしないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は、少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、サーバデバイスとクライアントデバイスとの間でデータを送信する方法が提供され、この方法は、クライアントデバイスにおいて：
サーバデバイスから得られるべきデータを特定するステップ；
特定されたデータから第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともにサーバデバイスが第２データをプッシュするべきか第２データをプッシュするべきでないかに関する指示を含む１つまたは複数の追加のヘッダフィールドを含む、生成するステップ；および
第１データを得るとともにサーバデバイスに第２データをプッシュさせまたはプッシュさせないためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
従って、本発明の方法は、有益なデータをクライアントデバイスにプッシュするサーバデバイスの能力を改善する。
複数の実施形態において、第２データをプッシュすることに関連する指示は、第２データをプッシュすることに関連する少なくとも２つの異なる指示を含むリストを含む。
複数の実施形態において、第２データをプッシュすることに関連する指示は第２データのデータのタイプと関連付けられ、そのデータのタイプは記述データタイプまたはコンテンツデータタイプを含み、第２データはコンテンツデータにまたは記述データに属する。
複数の実施形態において、第２データをプッシュすることに関連する指示は記述データアップデートをプッシュすることに向けられる。
複数の実施形態において、第２データをプッシュすることに関連する指示は、少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュするためのディレクティブとプッシュされるべき第２データのアイデンティフィケーションとを表すかまたは第２データをプッシュしないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は、少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、クライアントデバイスによりサーバデバイスからデータを受け取る方法が提供され、この方法は、クライアントデバイスにおいて：
第１データを得るＨＴＴＰリクエストを送るステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに１つまたは複数の追加のヘッダフィールドを含む、送るステップ；
もしクライアントがサーバデバイスに第１データと異なる第２データをプッシュしてほしくないならば、クライアントはサーバにＨＴＴＰリクエストに応じて第２データをプッシュしてほしくないということを示す情報アイテムを１つまた複数の追加のヘッダフィールドのうちの少なくとも１つに挿入するステップ；および
ＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
従って、本発明の方法は、サーバデバイスからクライアントデバイスにプッシュされる無駄なデータの送信を防止する。
複数の実施形態において、クライアントはサーバに第２データをプッシュしてほしくないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、データをサーバデバイスからクライアントデバイスに送る方法が提供され、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストはサーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに、１つまたは複数の追加のヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；および
サーバはＨＴＴＰリクエストに応じて第１データと異なる第２データをプッシュしないということを示す情報アイテムをクライアントに送るステップ；
を含む。
従って、本発明の方法は、サーバデバイスからクライアントデバイスにプッシュされる無駄なデータの送信を防止する。
複数の実施形態において、サーバは第２データをプッシュしないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、クライアントデバイスによりサーバデバイスからデータを受け取る方法が提供され、この方法は、クライアントデバイスにおいて：
第１データを得るＨＴＴＰリクエストを送るステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに１つまたは複数の追加のヘッダフィールドを含む、送るステップ；
もしクライアントがサーバデバイスに第１データと異なる第２データをプッシュしてほしくないならば、クライアントはサーバにＨＴＴＰリクエストに応じて第２データをプッシュしてほしくないということを示す情報アイテムを１つまた複数の追加のヘッダフィールドのうちの少なくとも１つに挿入するステップ；
ＨＴＴＰリクエストをサーバデバイスに送るステップ；
ＨＴＴＰリクエストを送ることに応答して、サーバデバイスから確認応答データを受け取るステップであって、確認応答データは、サーバは第１データと異なる第２データをプッシュしないということを示す情報アイテムを含む、受け取るステップ；
を含む。
従って、本発明の方法は、サーバデバイスからクライアントデバイスにプッシュされる無駄なデータの送信を防止する。
複数の実施形態において、クライアントはサーバに第２データをプッシュしてほしくないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は、第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、サーバは第２データをプッシュしないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は少なくとも１つのパラメータの関数としてセットされる。
本発明の他の１つの目的に応じて、データをサーバデバイスからクライアントデバイスに送る方法が提供され、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストはサーバデバイス上の第１データの特定を可能にする第１データ特定情報を含むとともに、クライアントはＨＴＴＰリクエストに応じてサーバにより第２データをプッシュしてほしくないということを示す情報アイテムを含む１つまたは複数の追加のヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；および
ＨＴＴＰリクエストに応じて、サーバは第１データと異なる第２データをクライアントにプッシュしないということを示す情報アイテムを送るステップ；
を含む。
従って、本発明の方法は、サーバデバイスからクライアントデバイスにプッシュされる無駄なデータの送信を防止する。
複数の実施形態において、サーバは第２データをプッシュしないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、クライアントはサーバにより第２データをプッシュしてほしくないということを示す情報は少なくとも１つの一意識別子を含み、その少なくとも１つの一意識別子は第２データをプッシュさせないためのディレクティブを表す。
複数の実施形態において、一意識別子は集中リポジトリにおいて定義される。
複数の実施形態において、一意識別子は少なくとも１つのパラメータの関数としてセットされる。
複数の実施形態において、１つまたは複数の追加のヘッダフィールドは１つまたは複数の任意ヘッダフィールドである。
複数の実施形態において、第１および第２のデータ特定情報は、それぞれ、第１および第２のユニフォームリソースアイデンティファイア、ＵＲＩ、を含む。
複数の実施形態において、１つまたは複数の任意ヘッダフィールドは、ＨＴＴＰリクエストの内容から第２ＵＲＩを生成する少なくとも１つの構築ルールを含む。
複数の実施形態において、１つまたは複数の任意ヘッダフィールドは変化部分情報および代入情報を含み、変化部分情報は参照ＵＲＩ内の少なくとも１つの変化サブパーツを特定し、代入情報は１つまたは複数の第２のＵＲＩを定義するために参照ＵＲＩにおいて特定される変化サブパーツに取って代わる少なくとも１つの代入値を含む。
複数の実施形態において、参照ＵＲＩは、受け取られたＨＴＴＰリクエストに含まれる第１ＵＲＩを含む。
複数の実施形態において、変化部分情報は、代入情報に含まれるそれぞれの１つまたは複数の代入値を用いて置換されるべき参照ＵＲＩ内の２つ以上のサブパーツを特定する。
複数の実施形態において、変化部分情報は、２つ以上のサブパーツの代入値をそれらのそれぞれの優先レベルに応じて連続的に考慮するために参照ＵＲＩ内の２つ以上のサブパーツの各々をそれぞれの優先レベルと関連付ける。
複数の実施形態において、追加のヘッダフィールドは第２ＵＲＩを明示的に含む。
複数の実施形態において、第１データ特定情報は、サーバデバイス上のメインリソースを特定する第１ユニフォームリソースアイデンティファイア、ＵＲＩ、を含むとともに、メインリソースのサブパーツを第１データとして定義するサブパーツ情報を含み；および
任意ヘッダフィールドは、第２データ特定情報を定義するために第１データ特定情報内のサブパーツ情報に取って代わる代入サブパーツ情報を含む。
複数の実施形態において、サブパーツ情報は、メインリソースの中のバイトのレンジ値を含む。
複数の実施形態において、第１および第２のデータは、それぞれ、ＤＡＳＨマニフェストプレゼンテーション記述内の第１および第２のデータ特定情報により特定されるメディアセグメントまたはメディアコンテンツサブパーツである。
本発明の他の１つの目的に応じて、サーバデバイスとクライアントデバイスとの間でデータを送信する方法が提供され、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに、第２データを特定することを可能にする１つまたは複数の任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；および
もし任意ヘッダフィールドがＨＴＴＰリクエスト内に存在するならば：
任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、を用いて、サーバデバイス上の第２データを特定することを可能にする第２データ特定情報を決定するステップ、を含む。すなわちＨＴＴＰリクエストの内容だけを使用して；および
第２データのプッシュをアナウンスするプッシュ約束メッセージをクライアントデバイスに送るステップおよび／または第２データをクライアントデバイスにプッシュするステップ；
を含む。
クライアントの視点から、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法を提供し、この方法は、クライアントデバイスにおいて：
サーバデバイスから得られるべきデータを特定するステップ；
その特定されたデータから第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに１つまたは複数の任意ヘッダフィールドを含み、任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報（すなわち、ＨＴＴＰリクエストの内容だけ）、に基づいて、サーバデバイス上の特定されたデータから第２データを特定することを可能にする第２データ特定情報を定義する、生成するステップ；
第１データを得るとともにサーバデバイスに第２データをプッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
相関して、本発明はクライアントデバイスとデータを交換するためのサーバデバイスを提供し、このデバイスは：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに第２データを特定することを可能にする１つまたは複数の任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；ならびに
もしＨＴＴＰリクエスト内に任意ヘッダフィールドが存在するならば：
任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、を用いて、サーバデバイス上の第２データを特定することを可能にする第２データ特定情報を決定するステップ；および
第２データのプッシュをアナウンスするプッシュ約束メッセージをクライアントデバイスに送るステップおよび／または第２データをクライアントデバイスにプッシュするステップ；
を実行するように構成された少なくとも１つのマイクロプロセッサを含む。
さらに、本発明はサーバデバイスとデータを交換するためのクライアントデバイスを提供し、このデバイスは：
サーバデバイスから得られるべきデータを特定するステップ；
その特定されたデータから第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに１つまたは複数の任意ヘッダフィールドを含み、任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、に基づいて、サーバデバイス上の特定されたデータから第２データを特定することを可能にする第２データ特定情報を定義する、生成するステップ；
第１データを得るとともにサーバデバイスに第２データをプッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を実行するように構成された少なくとも１つのマイクロプロセッサを含む。
ＨＴＴＰ／２においては、プッシュ約束メッセージは、対応するデータの実際のプッシュに先行する。他のプロトコル、特にウェブソケット（Ｗｅｂ Ｓｏｃｋｅｔｓ）またはＳＰＤＹ（ＳｐｅｅＤＹを表す）のような双方向プロトコル、は、先行するプッシュアナウンス無しに第２データを直ちにプッシュすることができる。
本発明により、クライアントデバイスは、サーバデバイスによるプッシュメカニズムを効率的に制御し、同時に、下位互換性を可能にする。それは、プッシュされるデータとクライアントのニーズとの不一致を低減する。その理由は、クライアントデバイスがプッシュしてほしい第２データ（リソース、またはリソースの一部）は在来のＨＴＴＰリクエストの任意ヘッダフィールドを用いて定義されることにある。さらに、下位互換性は、もしサーバデバイスが在来のものであるならば、すなわち任意ヘッダフィールドをサポートしなければ、それは依然としてＨＴＴＰリクエストを処理エラー無しに在来の仕方で処理することができるという事実から生じる。
任意ヘッダフィールドを理解するけれどもプッシュフィーチャをサポートしないサーバでは、そのサーバがコンテンツサーバではなくてリレーサーバである場合には、それは任意ヘッダフィールドからの情報を用いてリソースをプリフェッチすることができる。
さらに、この発明は、低スキルのサーバ、例えばＤＡＳＨ知識を持たないサーバ、に依拠することを可能にする。その理由は、プッシュされるべき第２データの特定は、ＭＰＤファイルなどが処理されることを要求しないことにある。本発明によれば、そのような特定を実行するために任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、が使用される。
従って本発明の複数の実施形態は、クライアント主導型サーバプッシュアプローチを含む、サーバ案内型ストリーミングのための軽量なメカニズムを提供する。複数の実施形態はＤＡＳＨネットワークと関連して実装され得る。
本発明の複数の実施形態は、現存するＨＴＴＰ／２フィーチャと両立し得る。これらのフィーチャは、本発明の複数の実施形態を実装するために有利に使用され得る。
ネットワークの性能は一般的に高められる。
方法およびデバイスの任意のフィーチャは、従属請求項において定義される。それらのうちの幾つかは、方法に関連して以下で説明される。しかし、それらは、対応するデバイスにも適用され得る。
一実施形態では、第１および第２のデータ特定情報は、それぞれ、第１および第２のユニフォームリソースアイデンティファイア、ＵＲＩ、を含む。
１つの特定の実施形態では、１つまたは複数の任意ヘッダフィールドは、ＨＴＴＰリクエストの内容から第２ＵＲＩを生成する少なくとも１つの構築ルールを含む。換言すれば、任意ヘッダフィールドは、構築ルールを用いて、１つまたは複数の第２ＵＲＩを暗に定義する。上記から推測されるように、構築ルールは、１つまたは複数の第２ＵＲＩを得るために任意ヘッダフィールド、および場合によってはさらに第１ＵＲＩ、を用いるだけである。
例えば、１つまたは複数の任意ヘッダフィールドは変化部分情報および代入情報を含み、変化部分情報は参照ＵＲＩ内の少なくとも１つの変化サブパーツを特定し、代入情報は１つまたは複数の第２のＵＲＩを定義するために参照ＵＲＩにおいて特定される変化サブパーツに取って代わる少なくとも１つの代入値を含む。従って、この規定は、構築ルールがどのように使用され得るかを定義する。
１つの特定のフィーチャによれば、参照ＵＲＩは、受け取られたＨＴＴＰリクエストに含まれる第１ＵＲＩを含む。換言すれば、構築ルール（代入プロセス）は、第１ＵＲＩに、すなわち要求された第１データのＵＲＩに、適用される。それは、構築ルール（これは一般的なものであり得る）は、ＨＴＴＰリクエストの内容だけを用いて、要求された第１データからプッシュされるべき第２データを推定することを意味する。
他の１つの特定のフィーチャによれば、変化部分情報は、代入情報に含まれるそれぞれの１つまたは複数の代入値を用いて置換されるべき参照ＵＲＩ内の２つ以上のサブパーツを特定する。従って、第１ＵＲＩから複雑な第２ＵＲＩが生成され得る。
さらに別の１つの特定のフィーチャによれば、変化部分情報は、２つ以上のサブパーツの代入値をそれらのそれぞれの優先レベルに応じて連続的に考慮するために参照ＵＲＩ内の２つ以上のサブパーツの各々をそれぞれの優先レベルと関連付ける。この規定により、クライアントデバイスは、複数の第２ＵＲＩを順序付け、このように、第２データがサーバデバイスによりプッシュされる順序を主導する。
幾つかの実施形態では、任意ヘッダフィールドは、第２ＵＲＩを明示的に含む。これは、例えば構築ルールを用いる１つまたは複数の第２ＵＲＩの暗黙の定義とは反対である。
他の複数の実施形態において、第１データ特定情報は、サーバデバイス上のメインリソースを特定する第１ユニフォームリソースアイデンティファイア、ＵＲＩ、を含むとともにメインリソースのサブパーツを第１データとして定義するサブパーツ情報を含み；および
任意ヘッダフィールドは、第２データ特定情報を定義するために第１データ特定情報内のサブパーツ情報に取って代わる代入サブパーツ情報を含む。
サブパーツ情報の一例は、ＤＡＳＨにおいて使用されるレンジパラメータである。この例では、サブパーツ情報はメインリソースの中のバイトのレンジ値を含む。
複数の実施形態では、第１および第２のデータは、それぞれ、ＤＡＳＨマニフェストプレゼンテーション記述内の第１および第２のデータ特定情報により特定されるメディアセグメントまたはメディアコンテンツサブパーツである。ＤＡＳＨレンジパラメータの使用はメディアコンテンツ／セグメントサブパーツを特定することを可能にし、ＤＡＳＨにおけるＵＲＩは、普通、１つのメディアセグメント全体を特定するということに注意されたい。
公知の従来技術と比べると、クライアントデバイスがサーバのプッシュフィーチャを主導または案内するのを助ける必要もある。これと関連して、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法をも提供し、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；ならびに
もしその第１任意ヘッダフィールドがＨＴＴＰリクエスト内に存在するならば：
ＨＴＴＰリクエストから得られるメインリソースを用いてデータのセットを特定するステップ；
第２データのリストを得るために１つまたは複数のフィルタリングパラメータを用いて、特定されたセットの各データをフィルタリングするステップ；および
第２データをクライアントデバイスにプッシュするステップ；
を含む。
プッシュ約束フィーチャを含むプロトコルに関しては、この方法は、第２データをプッシュする前に、第２データのプッシュをアナウンスするプッシュ約束メッセージをクライアントデバイスに送るステップをさらに含む。
クライアントの視点から、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法を提供し、この方法は、クライアントデバイスにおいて：
第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、生成するステップ；
第１データを得るとともにサーバデバイスに、ＨＴＴＰリクエストから推定されるメインリソースにおいて参照される第２データを、フィルタリングパラメータに従って、プッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
１つまたは複数のフィルタリングパラメータは：
− リソースタイプを定義し；その１つまたは複数のリソースタイプは、アプリケーションタイプ、テキストタイプ、イメージタイプ、ビデオタイプ、オーディオタイプからの１つまたは複数のタイプを含み；または
− ＤＡＳＨメディアプレゼンテーション記述内のエレメントの識別子を用いてデータの１つまたは複数のグループを特定し；または
− メインリソースのサブパーツを特定する時間レンジを用いて第１任意ヘッダフィールドにおいて定義される。
さらに、プッシュ約束メッセージも受け取られ得る。
相関して、本発明はクライアントデバイスとデータを交換するためのサーバデバイスを提供し、このデバイスは：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；ならびに
もし第１任意ヘッダフィールドがＨＴＴＰリクエスト内に存在するならば：
ＨＴＴＰリクエストから得られるメインリソースを用いてデータのセットを特定するステップ；
第２データのリストを得るために１つまたは複数のフィルタリングパラメータを用いて、特定されたセットの各データをフィルタリングするステップ；および
第２データをクライアントデバイスにプッシュするステップ；
を実行するように構成された少なくとも１つのマイクロプロセッサを含む。
１つまたは複数のフィルタリングパラメータは：
− リソースタイプを定義し；その１つまたは複数のリソースタイプは、アプリケーションタイプ、テキストタイプ、イメージタイプ、ビデオタイプ、オーディオタイプからの１つまたは複数のタイプを含み；または
− ＤＡＳＨメディアプレゼンテーション記述内のエレメントの識別子を用いてデータの１つまたは複数のグループを特定し；または
− メインリソースのサブパーツを特定する時間レンジを用いて第１任意ヘッダフィールドにおいて定義される。
さらに、本発明はサーバデバイスとデータを交換するためのクライアントデバイスを提供し、このデバイスは：
第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、生成するステップ；
第１データを得るとともにサーバデバイスに、ＨＴＴＰリクエストから推定されるメインリソースにおいて参照される第２データを、フィルタリングパラメータに従って、プッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を実行するように構成された少なくとも１つのマクロプロセッサを含む。
このアプローチの１つの例証は、第１データとしてのメインＨＴＭＬウェブページの要求である。このとき任意ヘッダフィールドは、そのＨＴＭＬページにおいて参照されるどの１つまたは複数のタイプのサブリソースがプッシュされるべきかを定義することができる。従って、任意ヘッダフィールドはフィルタリングパラメータとして振る舞う。例えば、それは、ｊｐｇイメージのサブセットだけをプッシュしてもらうためにサブリソースをフィルタリングするフィルタリングパラメータ“ｉｍａｇｅｓ／＊．ｊｐｇ”を提供することができる。
クライアントデバイスによるサーバプッシュフィーチャの改善された制御は、任意ヘッダフィールドを通して、リクエストにより特定されるデータに対して適用されるフィルタリングパラメータの使用を通して得られる。
重ねて、そのような任意ヘッダフィールドの使用は、サーバのエンドにおける下位互換性を可能にする。
このように本発明の実施形態は、クライアント主導型サーバプッシュアプローチを含む、サーバ案内型ストリーミングのための軽量なメカニズムを提供する。複数の実施形態は、ＤＡＳＨネットワークと関連して実装され得る。
本発明の複数の実施形態は、現存するＨＴＴＰ／２フィーチャと両立し得る。これらのフィーチャは、本発明の実施形態を実装するために有利に使用され得る。
ネットワークの性能は一般的に高められる。
方法およびデバイスの任意のフィーチャは、従属請求項において定義される。それらのうちの幾つかは、方法と関連して以下で説明される。しかし、それらは、対応するデバイスにも適用され得る。
複数の実施形態において、メインリソースは第１データである。それは、単独で利用されるＨＴＴＰリクエストは、サーバデバイスが、プッシュされるべき全ての第２データを効率的に特定することを可能にするということを意味する。サーバデバイスは、上で論じられた従来技術のためのＤＡＳＨ知識などの追加の知識を必要としない。従って低スキルのサーバデバイスが使用され得る。
他の実施形態において、ＨＴＴＰリクエストは、サーバデバイス上のメインリソースを特定するユニフォームリソースアイデンティファイア、ＵＲＩ、を定義する第２任意ヘッダフィールドを含む。そのような実施形態は、クライアントデバイスが初めにメインリソースを得、その後にそれを、メインリソースから適切な第２データを実際に選択するためにフィルタリングパラメータを特定する（および任意ヘッダフィールドを用いて定義する）ために分析する必要があるとき、実装され得る。実際、そのような場合、クライアントデバイスは、メインリソースを要求するとき、メインリソースの内容へのアクセスをまだ持っていないので、フィルタリングパラメータを定義することはできない。
この規定により、クライアントは、リソースタイプごとのリソースのリストを定義し得るサーバに格納されている静的設定ファイルを指定することができる。そのような静的設定ファイルを使用することは、サーバがリソースタイプフィルタリングパラメータに基づいてリソースを特定するために低スキルを必要とする。
さらに別の実施形態では、２つ（またはより多くの）フィルタリングパラメータがデータの２つ（またはより多くの）それぞれのグループおよび２つのそれぞれの優先レベルと関連付けられ；フィルタリングするステップは、第２データの順序リストを得るために、第２データを、それらがそれぞれデータするグループの優先レベルに応じて順序正しく配列し；プッシュするステップは、その順序リストに従って第２データをプッシュする。クライアントエンドにおいて、それは、２つのフィルタリングパラメータがデータの２つのグループおよび２つのそれぞれの優先レベルと関連付けられることを意味し；第２データは、それらがそれぞれ属するグループの優先レベルに応じた順序で受け取られる。このことは、クライアントデバイスが、プッシュされたデータを自身が受け取りたい順序を効率的に主導することを可能にする。
さらに別の実施形態では、各フィルタリングパラメータはリソースタイプを定義し；その１つまたは複数のリソースタイプは、アプリケーションタイプ（例えばｊａｖａｓｃｒｉｐｔ（登録商標））、テキストタイプ（例えばｃｓｓまたはｈｔｍｌ）、イメージタイプ（例えばｐｎｇまたはｊｐｇ）ビデオタイプ（例えばｍｐ４またはｗｅｂｍ）、オーディオタイプ（例えばｍｐ３またはｗａｖ）からの１つまた複数のタイプを含む。
この規定は、特に、ｈｔｍｌ、またはウェブページのロードのためのものなどの類似のエクスチェンジに適用される。もちろん、これらのリソースタイプのいずれの細区分も、特定のコンテンツ（例えば、イメージ、またはＪａｖａｓｃｒｉｐｔファンクションのような組み込み型ファンクション）のロードを効率的に行わせるのに役立つであろう。
さらに別の実施形態では、第１任意ヘッダフィールド内の１つまた複数のフィルタリングパラメータは、ＤＡＳＨメディアプレゼンテーション記述内のエレメントの識別子を用いてデータの１つまたは複数のグループを特定する。そのようなエレメントは、ＤＡＳＨ ＭＰＤのＡｄａｐｔａｔｉｏｎＳｅｔエレメント、ＰｒｅｓｅｎｔａｔｉｏｎエレメントまたはＳｅｇｍｅｎｔエレメントを含み得る。１つの実施形態では、ＨＴＴＰリクエストにより要求される第１データはＤＡＳＨ ＭＰＤである。もちろん、１つの変化形では、ＤＡＳＨ ＭＰＤは上記の第２任意ヘッダフィールドにおいて明示され得る。
この規定は、クライアントデバイスが、ＭＰＤにより定義されるメディアコンテンツの幾つかの部分のプッシュを制御することを可能にする。
さらに別の実施形態では、１つまたは複数のフィルタリングパラメータは、メインリソースのサブパーツを特定する時間レンジ、例えばＤＡＳＨリクエストにおいて使用される時間レンジ、を用いて第１任意ヘッダフィールドにおいて定義される。すぐ前の規定と同様に、この一つも、クライアントデバイスが、ＤＡＳＨを用いてストリーミングされるメディアコンテンツのサブパーツがサーバデバイスによってどのようにプッシュされるかを制御することを可能にする。
本発明の他の１つの面は、デバイス内のマイクロプロセッサまたはコンピュータシステムにより実行されたときそのデバイスに上で定義されたいずれかの方法を実行させるプログラムを格納する非一時的コンピュータ可読媒体に関連する。
非一時的コンピュータ可読媒体は、方法およびデバイスに関連して上および下で記述されるものに類似するフィーチャおよび利点、特に、クライアントによるサーバプッシュフィーチャの制御を改善することおよび低スキルのサーバデバイスに依拠することについてのそれ、を有し得る。
本発明のさらに別の面は、上で定義されたいずれかの方法の各ステップを実行するようにされた手段を含むデバイスに関連する。
本発明のさらに別の面は、実質的に添付図面の図３ａまたは３ｂまたは５ａまたは５ｂまたは６ａまたは７ｂまたは８と関連して上で記載されるとともにこれらに図示されている、サーバデバイスとクライアントデバイスとの間でリソースを送信する方法に関連する。
本発明による方法の少なくとも幾つかの部分はコンピュータで実行され得る。従って、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）またはソフトウェア面と、全て本明細書において“回路”、“モジュール”または“システム”と一般的に称され得るハードウェア面とを組み合わせた実施形態の形をとることができる。さらに、本発明は、コンピュータ可用プログラムコードが媒体内に具体化されている任意の有形表現媒体において具体化されるコンピュータプログラム製品の形をとることができる。
本発明はソフトウェアを用いて実装され得るので、本発明は任意の適切な搬送媒体でプログラマブルな装置に供給されるコンピュータ可読コードとして具体化され得る。有形搬送媒体は、フロッピーディスク、ＣＤ−ＲＯＭ、ハードディスクドライブ、磁気テープデバイスまたはソリッドステートメモリデバイスなどの記憶媒体を含み得る。一時的搬送媒体は電気信号、電子信号、光信号、音響信号、磁気信号または電磁信号、例えばマイクロウェーブもしくはＲＦ信号、などの信号を含み得る。
本発明の他の特徴および利点は、添付図面と関連して、非限定的な例示的実施形態についての以下の記載から明らかになるであろう。
グラフを用いて、ウェブページなどの、メインリソースに連結されたリソースのセットを示す。 プッシュフィーチャを用いない、図１ａのメインリソースのロードを示す。 プッシュフィーチャを用いる、図１ａのメインリソースのロードを示す。 プッシュフィーチャが実装されたときのクライアントデバイスの在来のステップを、フローチャートを用いて、示す。 プッシュフィーチャが実装されたときのサーバデバイスの在来のステップを、フローチャートを用いて、示す。 ウェブページをロードするためのＨＴＴＰエクスチェンジを示す。 従来技術によるＤＡＳＨ指向クライアント−サーバシステムを示す。 本発明の実施形態が実装され得るクライアント−サーバシステムを示す。 本発明の実施形態が実装され得るＤＡＳＨ指向クライアント−サーバシステムを示す。 メディアプレゼンテーションの構築を示す。 ＤＡＳＨメディアプレゼンテーション記述、ＭＰＤファイルの構造を示す。 図３ａのシステムにおけるクライアントの振る舞いを説明する主要ステップを示す。 図３ｂのシステムにおけるストリーミング指向クライアントの振る舞いを説明する主要ステップを示す。 図３ａまたは３ｂのシステムにおけるサーバの振る舞いを説明する主要ステップを示す。 本発明によるプッシュヘッダの例示的構造を説明する。 ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅを有する例示的ＭＰＤファイルを示す。 図７ａのＭＰＤファイルに基づく、本発明を実装するクライアント−サーバエクスチェンジを示す。 ＤＡＳＨストリーミングと関連する、本発明によるプッシュヘッダの例を示す。 実施形態によるデバイスの概略図である。 幾つかのレベルでのテンプレートＵＲＩの宣言を説明するＭＰＤサンプルを示す。 サーバ内でのプッシュポリシー通知の確認応答の例を示す。 サーバ内でのプッシュポリシー通知の確認応答の例を示す。 サーバ内でのプッシュポリシー通知の確認応答の例を示す。 サーバ内でのプッシュポリシー通知の確認応答の例を示す。 サーバ内でのプッシュポリシー通知の確認応答の例を示す。 一意識別子に基づくクライアントとサーバとの間でのプッシュポリシーに関連する情報の交換の例を示す。 一意識別子に基づくクライアントとサーバとの間でのプッシュポリシーに関連する情報の交換の例を示す。
上で簡潔に紹介されたように、本発明はＨＴＴＰ通信ネットワークを通してのデータ送信に関する。１つの用例はＤＡＳＨなどの適応データストリーミングである。
ＨＴＴＰは、ウェブリソース、通例ウェブページ、を送るために用いられるプロトコルである。ＨＴＴＰはクライアントおよびサーバに対して次のことを暗示する：
− クライアントはサーバにリクエストを送り、そのリクエストは様々な種類の“ヘッダ”が任意に後に続く“ｒｅｑｕｅｓｔ＿ｌｉｎｅ”から構成される。“ｒｅｑｕｅｓｔ−ｌｉｎｅ”は、普通、場合によってはレンジヘッダなどを用いてサーバ上の要求されたリソースまたはデータを特定する“Ｒｅｑｕｅｓｔ−ＵＲＩ”パラメータと共にメソッド（例えば“ＧＥＴ”）を含む；
− サーバは、そのウェブリソースのリプリゼンテーションを含むレスポンスを用いてクライアントのリクエストに応える。
リクエストおよびレスポンスは、様々なパーツ、特にＨＴＴＰヘッダ、を含むメッセージである。ＨＴＴＰヘッダは、値とともに名を含む。例えば、“Ｈｏｓｔ： ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ”を考察すると、“Ｈｏｓｔ”はヘッダ名であり、それの値は“ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ”である。それは、クエリされたリソースをホストに示すために使用される（例えば、ＨＴＴＰを説明するＷｉｋｉｐｅｄｉａ（ウィキペディア）ページはＨＴＴＰ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＨＴＴＰから入手できる）。ＨＴＴＰヘッダは、クライアントのリクエストおよびサーバのレスポンスにおいて出現する。
ＨＴＴＰの新しいバージョンであるＨＴＴＰ／２は、ストリームを通してリクエスト／レスポンスを交換することを可能にする。ストリームは、どのＨＴＴＰリクエストおよびレスポンスの交換のためにもＨＴＴＰ／２コネクションの内部で生成される。フレームは、リクエストおよびレスポンスの内容、疑似ヘッダおよびヘッダを伝えるためにストリーム内で交換される。
ＨＴＴＰ／２は：
− ＨＥＡＤＥＲＳ：ＨＴＴＰヘッダの送信のために提供される
○ＨＴＴＰ／２はヘッダ（任意である。すなわち処理側デバイスに理解されなければ無視される）をより厳しいルールに従う疑似ヘッダから区別する。後者は、ＨＴＴＰメソッドおよびｒｅｑｕｅｓｔ−ＵＲＩを示すために以前のＨＴＴＰバージョンで定義されているｒｅｑｕｅｓｔ−ｌｉｎｅのマッピングに対応する。本文書においては、“ＨＴＴＰヘッダ”または“ヘッダ”は、任意のヘッダを指定するべく意図されているのであり、明示的にそのようなものとして指定される疑似ヘッダを指定するべく意図されているのではない。
○さらに、本文書においてもなお、“Ｒｅｑｕｅｓｔ−ＵＲＩ”は、ＲＦＣ２６１６で定義されているＲｅｑｕｅｓｔ−ＵＲＩ（すなわち、“ｒｅｑｕｅｓｔ−ｌｉｎｅ”に用いられているサーバ上の要求されているリソースを特定するパラメータ）またはそれの同等物／ＨＴＴＰ／２疑似ヘッダへの変換を指定するべく意図されている。
− ＤＡＴＡ：これは、ＨＴＴＰメッセージ内容の送信のために提供される
− ＰＵＳＨ＿ＰＲＯＭＩＳＥ：これはプッシュされる内容をアナウンスするために提供される
− ＰＲＩＯＲＩＴＹ：これはストリームの優先順位をセットするために提供される
− ＷＩＮＤＯＷ＿ＵＰＤＡＴＥ：これは制御フローウィンドウの値をアップデートするために提供される
− ＳＥＴＴＩＮＧＳ：これは設定パラメータを伝えるために提供される
− ＣＯＮＴＩＮＵＡＴＩＯＮ：これはヘッダブロックフラグメントのシーケンスを継続させるために提供される
− ＲＳＴ＿ＳＴＲＥＡＭ：これはストリームを終端させまたはキャンセルするために提供される
などの様々な意味を有するフレームの限られたセットを定義する。
ＨＴＴＰ／２では、リクエストはそのとき第１ＨＥＡＤＥＲフレームおよび１つまたは複数のＤＡＴＡフレームに変換され、ＨＴＴＰ／１．ｘからのｒｅｑｕｅｓｔ−ｌｉｎｅは、ＨＴＴＰ／２仕様に記載されているように疑似ヘッダフィールドに変換される。
本明細書は、クライアントからサーバへ送られるメッセージを示すために“リクエスト”または“ＨＴＴＰリクエスト”を使用し、サーバからクライアントへのメッセージを示すために“レスポンス”または“ＨＴＴＰレスポンス”を使用する。リクエストおよびレスポンスの他に、私たちは、サーバによりクライアントに対して開始されるメッセージに対応する通知またはサーバ通知についても語る。この用語は、ＨＴＴＰ／１．ｘおよびＨＴＴＰ／２に準拠している。
サーバによるプッシュは、サーバが請求されていないウェブリソースリプリゼンテーションをクライアントに送ることを可能にするためにＨＴＴＰ／２に導入されている。ウェブページなどのウェブリソースは一般的に他のリソースへのリンクを含み、それら自身は他のリソースへのリンクを含み得る。ウェブページを完全に表示するためには、リンクされまたはサブリンクされているリソースの全てがクライアントにより取り出されなければならないことがある。このますます増加する発見はウェブページの低速な表示を、特にモバイルネットワークなどの大レイテンシのネットワークにおいて、もたらすであろう。
所与のウェブページに対するリクエストを受け取ると、サーバは、要求されたリソースの完全な処理のために他のどのリソースが必要かを知ることができる。要求されたリソースとリンクされているリソースとを同時に送ることにより、サーバは、そのウェブページのローディング時間を短縮することを可能にする。従って、プッシュフィーチャを用いて、サーバは、所与のリソースを要求された時に追加のリソースリプリゼンテーションを送ることができる。
リンクされているリソースの例として、図１ａは、サーバにより所有されているリソースのセットとそれらの関係とのグラフを示す。リソースのセットは絡み合っている：Ｒ１、Ｒ２、Ｒ３、およびＲ４は、クライアントにより適切に処理されるべく一緒にダウンロードされなければならないリソースである。さらに、サブリソースＡからＨが定義される。これらのサブリソースは１つ、２つまたは３つのリソースに関連付けられている。例えば、ＡはＲ１にリンクされ、ＣはＲ１、Ｒ２およびＲ４にリンクされている。
図１ｅのフローチャートを参照して、プッシュフィーチャを実装するサーバの例示的動作モードが記載される。
ステップ１００の間に、サーバは最初のリクエストを受け取る。次に、サーバは、ステップ１０１の間にレスポンスの一部としてプッシュするリソースを特定し、ステップ１０２の間にプッシュ約束メッセージをクライアントに送る。その後、それはステップ１０３の間にコンテンツレスポンスを送り始める。プッシュ約束メッセージは、サーバが、例えば図１ａに示されている依存性に基づいてプッシュしようとしている他のリソースを特定する。これらのメッセージは、どのプッシュされるリソースが送られるかを前もってクライアントに知らせるために送られる。特に、これは、同時にプッシュされつつあるかまたはまさにプッシュされようとしているリソースに対するリクエストをクライアントが送るリスクを減らす。このリスクをさらに減らすために、サーバは、プッシュ約束メッセージを、そのプッシュ約束に記載されているリソースに関連するレスポンスの部分を送る前に、送るべきである。これは、クライアントが、約束されたリソースのプッシュを、もしクライアントがそれらのリソースを欲しくなければ、キャンセルすることも可能にする。次に、ステップ１０４の間にレスポンスと全ての約束されたリソースとを送る。プロセスはステップ１０５の間に終了する。
図１ｂおよび１ｃは、それぞれ、プッシュフィーチャを使用しないウェブページのロードおよびプッシュフィーチャを使用するウェブページのロードを示す。
図１ｂは、サーバのプッシュフィーチャを使用しないＨＴＴＰエクスチェンジを示す：クライアントはＲ１を要求し、次にそれはＲ２、Ａ、Ｂ、ＣおよびＤを発見してそれらを要求する。それらを受信した後、クライアントはＲ３、Ｒ４、ＦおよびＧを要求する。最後にクライアントはＨおよびＩサブリソースを要求する。従って、必要とされるどのリソース：リソースＲ１からＲ４およびサブリソースＡからＩ、に対してもリクエストが送られなければならない。さらに、このプロセスは、リソースのセット全体を取り出すために４つのラウンドトリップを必要とする。
図１ｃは、直接連結されているサブリソースのサーバによるプッシュのフィーチャを使用するＨＴＴＰエクスチェンジを示す。Ｒ１の要求後、サーバはＲ１を送るとともにＡ、Ｂ、ＣおよびＤをプッシュする。クライアントはＲ２を特定し、それを要求する。サーバはＲ２を送り、ＦおよびＧをプッシュする。最後にクライアントはＲ３、Ｒ４を特定し、これらのリソースを要求する。サーバはＲ３、Ｒ４を送り、ＨおよびＩをプッシュする。このように、リクエストの数はエレメントＲ１からＲ４に限定される。エレメントＡからＩは図１ａに示されている依存性に基づいてサーバによりクライアントに“プッシュ”され、これにより、関連するリクエストを不要にする。このプロセスは、リソースのセット全体を取り出すために３つのラウンドトリップを必要とする。
このように、図１ｂおよび１ｃに示されているように、サーバがプッシュフィーチャを使用すると、リソースをそのサブリソースと共にロードするのに必要なＨＴＴＰラウンドトリップ（リクエスト＋レスポンス）の数が減らされる。これは、モバイルネットワークなどの大レイテンシのネットワークのために特に興味あることである。
リソースのセット、典型的にはウェブページとそのサブリソース、のローディング時間を短縮するためにＨＴＴＰ／２は複数のリクエストおよびレスポンス優先順位を並行して交換することを可能にする。図２に示されているように、ウェブページは、ＪａｖａＳｃｒｉｐｔ、イメージなどの数個のリソースのダウンロードを必要とすることがある。最初のＨＴＴＰエクスチェンジ２００の間に、クライアントはＨＴＭＬファイルを取り出す。このＨＴＭＬファイルは、２つのＪａｖａＳｃｒｉｐｔファイル（ＪＳ１、ＪＳ２）、２つのイメージ（ＩＭＧ１、ＩＭＧ２）、１つのＣＳＳファイルおよび１つのＨＴＭＬファイルへのリンクを含む。エクスチェンジ２０１の間に、クライアントは各ファイルに対するリクエストを送る。図２のエクスチェンジ２０１において与えられる順序はウェブページの順序に基づき、クライアントはリンクが発見されると直ちにリクエストを送る。その後サーバは、ＪＳ１、ＣＳＳ、ＩＭＧ１、ＨＴＭＬ、ＩＭＧ２およびＪＳ２に対するリクエストを受信し、これらのリクエストをその順序に従って処理する。その後、クライアントはこれらのリソースをその順序で取り出す。
クライアントは、ウェブページ記述（ＨＴＭＬファイル）において挙げられているサブリソースをダウンロードするために自身の適切な順序を持つことを望むであろう。そのような場合、サーバにとっては、特にその順序を用いてプッシュフィーチャを実行するために、この情報を持つことは貴重なことであろう。
図１ｄのフローチャートは、プッシュフィーチャが実行されるときのクライアント側でのプロセスを示す。
クライアントは、サーバから取り出すリソースを特定すると、初めにステップ１０６の間に、対応するデータが自身のキャッシュメモリ内に既に存在するか否かをチェックする。そのリソースが既にキャッシュメモリ内に存在するならば（Ｙｅｓ）、それはステップ１０７の間にそれから取り出される。キャッシュされているデータは、以前のリクエストから取り出されたデータまたは以前にサーバによりプッシュされたデータであろう。それがキャッシュメモリ内に存在しない場合（Ｎｏ）、クライアントはステップ１０８の間にリクエストを送ってサーバのレスポンスを待つ。
サーバからフレームを受け取ると、クライアントはステップ１０９の間にそのフレームがプッシュ約束に対応するフレームであるか否かをチェックする。もしそのデータフレームがプッシュ約束に対応するならば（Ｙｅｓ）、ステップ１１０の間に、クライアントはそのプッシュ約束を処理する。そうするために、クライアントは、プッシュされるべきリソースを特定する。クライアントがそのリソースを受け取ることを希望しなければ、クライアントはエラーメッセージをサーバに送ることができるのでサーバはそのリソースをプッシュしない。そうでなければ、クライアントは、対応するプッシュされたコンテンツを受け取るまでそのプッシュ約束を保存しておく。そのプッシュ約束は、約束されたリソースをサーバがプッシュしている間にクライアントがその約束されたリソースを要求しないように、使用される。
データフレームがプッシュ約束に対応しない場合（Ｎｏ）、ステップ１１１の間に、そのフレームがプッシュされたデータに関連するデータフレームであるか否かがチェックされる。それがプッシュされたデータに関連する場合（Ｙｅｓ）、クライアントはステップ１１２の間にそのプッシュされたデータを処理する。そのプッシュされたデータはクライアントのキャッシュの中に格納される。
そのフレームがプッシュされたデータに関連するデータフレームでない場合（Ｎｏ）、ステップ１１３の間に、それがサーバから受信されたレスポンスに対応するか否かがチェックされる。そのフレームがサーバからのレスポンスに対応する場合（Ｙｅｓ）、そのレスポンスはステップ１１４の間に処理される（例えば、アプリケーションに送られる）。
そうでない場合（Ｎｏ）、ステップ１１５の間に、そのフレームがレスポンスの終わりを特定するか（Ｙｅｓ）否かがチェックされる。この場合、プロセスはステップ１１６の間に終了される。そうでない場合、プロセスはステップ１０９に戻る。
このように、クライアントはレスポンスおよび約束されたリソースを受け取ると思われる。従って、取り出されたウェブページを表示するブラウザなどのアプリケーションによってレスポンスが使用されている間、約束されたリソースは一般的にクライアントのキャッシュに格納されている。プッシュされたリソースのうちの１つをクライアントアプリケーションが要求すると、そのリソースはネットワーク遅延を招くことなく直ちにクライアントのキャッシュから取り出される。
プッシュされたリソースのキャッシュにおける保存は、キャッシュ制御ディレクティブを使用して制御される。キャッシュ制御ディレクティブは、レスポンスの制御のためにも使用される。これらのディレクティブは特にプロキシに対して適用可能であり、リソースは、プッシュされたリソースであってもプッシュされたリソースでなくても、プロキシによりまたはクライアントのみにより、保存され得る。
上で言及されたように、クライアントは、ウェブページ記述（ＨＴＭＬファイル）において挙げられているサブリソースをダウンロードする自身の適切な順序を持つことを望むであろうから、サーバのエンドにおけるプッシュフィーチャを主導するべきである。本発明は、この点での現下の状況を、例えばクライアントが第１リソースの要求後に希望することのある（サブ）リソースまたは（サブ）リソースの１つもしくは複数の部分の特定のセットをサーバに知らせるために、改善することを意図している。特に、本発明は、僅かのインテリジェンスしか持っていないサーバ、例えば、クライアントがそれらの（サブ）リソースを特定するための根拠としたウェブページ記述などを処理するための知識を持っていないサーバ、に適合しようとしている。
本発明に対するそのようなニーズは、ＨＴＴＰを通してのＨＴＴＰストリーミングに関して、例えば、プッシュフィーチャを使用するとき、ＤＡＳＨなどの適応ＨＴＴＰストリーミングと関連して、大きくなる。
ＨＴＴＰを通してのメディアストリーミングの一般的原理が図３に示されている。ＨＴＴＰを通しての適応メディアストリーミングのための新しいプロトコルおよび標準規格のほとんどは、この原理に基づいている。これはＤＡＳＨの場合であり、以下の説明はこれについて言及する。
メディアサーバ３００はクライアント３１０にデータをストリーミングする。メディアサーバはメディアプレゼンテーションを保存している。例えば、メディアプレゼンテーション３０１はオーディオおよびビデオデータを含む。オーディオおよびビデオは同じファイルにおいてインターリーブされ得る。メディアプレゼンテーションが構築される仕方は、以下で図４ａと関連して記載される。メディアプレゼンテーションは、独立してアドレスされダウンロードされ得る小さな独立の連続的な、ＭＰ４セグメントなどの、一時的セグメント３０２ａ、３０２ｂおよび３０２ｃに時間的に分割される。これらの一時的セグメントの各々のためのメディアコンテンツのダウンロードアドレス（ＨＴＴＰ ＵＲＬ）は、クライアントに対してサーバによりセットされる。オーディオ／ビデオメディアコンテンツの各一時的セグメントは、１つのＨＴＴＰアドレスと関連付けられる。
メディアサーバは、メディアコンテンツ特性（例えばメディアのタイプ：オーディオ、ビデオ、オーディオ−ビデオ、テキストなど）、符号化フォーマット（例えば、ビットレート、タイミング情報など）、一時的メディアセグメントおよび関連ＵＲＬのリストを含むメディアプレゼンテーションの内容を記述するマニフェストファイルドキュメント３０４（その一例が図７ａに示されている）をも保存している。あるいは、このドキュメントは、一時的メディアセグメントおよび関連ＵＲＬの明示的リストを再構築することを可能にするテンプレート情報を含む。このドキュメントは、エクステンシブルマークアップランゲージ（ＸＭＬ：ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を用いて書かれ得る。
マニフェストファイルはクライアントに送られる。ステップ３０５中にマニフェストファイルを受け取ると、クライアントはメディアコンテンツの一時的セグメントとＨＴＴＰアドレスとの関連を知らされる。さらに、マニフェストファイルは、メディアプレゼンテーションの内容（本例ではインターリーブされているオーディオ／ビデオ）に関する情報をクライアントに提供する。この情報は、解像度、ビットレートなどを含み得る。
受信した情報に基づいて、クライアントのＨＴＴＰクライアントモジュール３１１は、マニフェストファイルに記載されているメディアコンテンツの一時的セグメントをダウンロードするためのＨＴＴＰリクエスト３０６を送ることができる。サーバのＨＴＴＰレスポンス３０７は、要求された一時的セグメントを伝える。ＨＴＴＰクライアントモジュール３１１は、レスポンスから一時的メディアセグメントを抽出して、それらをメディアエンジン３１２の入力バッファ３０７に供給する。最後に、メディアセグメントは、それぞれのステップ３０８および３０９の間に復号されて表示され得る。
メディアエンジン３１２は、次の一時的セグメントを適時に出させるためのリクエストを得るためにＤＡＳＨ制御エンジン３１３と相互に作用する。次のセグメントは、マニフェストファイルから特定される。そのリクエストが発せられる時は、受信バッファ３０７が満杯であるか否かに依存する。ＤＡＳＨ制御エンジン３１３は、バッファがオーバーロードされたり完全に空になったりするのを防止するためにバッファを制御する。
メディアプレゼンテーションおよびマニフェストファイルの生成は、図４ａと関連して記載される。ステップ４００および４０１の間に、オーディオおよびビデオデータが取得される。次に、オーディオデータが４０２の間に圧縮される。例えば、ＭＰ３標準規格が使用され得る。さらに、ステップ４０３の間にビデオデータが並行して圧縮される。ＭＰＥＧ４、ＭＰＥＧ／ＡＶＣ、ＳＶＣ、ＨＥＶＣまたはスケーラブルＨＥＶＣなどのビデオ圧縮アルゴリズムが使用され得る。オーディオおよびビデオデータの圧縮が行われたならば、オーディオおよびビデオ基本ストリーム４０４、４０５が利用可能になる。基本ストリームは、ステップ４０６の間にグローバルメディアプレゼンテーションにエンキャプシュレートされる。例えば、符号化されたオーディオおよびビデオ基本ストリームの内容をグローバルメディアプレゼンテーションとして記述するためにＩＳＯ ＢＭＦＦ標準規格（または、ＩＳＯ ＢＭＦＦ標準規格のＡＶＣへのエクステンション、ＳＶＣ、ＨＥＶＣ、ＨＥＶＣのスケーラブルエクステンションなど）が使用され得る。これにより得られたエンキャプシュレートされたメディアプレゼンテーション４０７は、ステップ４０８の間に、ＸＭＬマニフェストファイル４０９を生成するために使用される。ビデオデータ４０１およびオーディオデータ４００の数個のリプリゼンテーションが取得され、圧縮され、エンキャプシュレートされ、メディアプレゼンテーション４０７において記述され得る。
図４ｂに示されているＭＰＥＧ／ＤＡＳＨストリーミングプロトコルの特別の場合については、マニフェストファイルは“メディアプレゼンテーション記述（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）”（あるいは“ＭＰＤ”ファイル）と呼ばれる。このファイルのルートエレメントは、全てのプレゼンテーションとプロファイルまたはスキーマのようなＤＡＳＨ情報とに適用される属性を含むＭＰＤエレメントである。メディアプレゼンテーションは、ピリオドエレメントにより表示される一時的ピリオドに分割される。ＭＰＤファイル４１０は、各一時的ピリオドに関連する全てのデータを含む。この情報を受け取ることにより、クライアントは時間の各ピリオドのためのコンテンツを知る。各ピリオド４１１について、ＡｄａｐｔａｔｉｏｎＳｅｔエレメントが定義される。
１つの可能な構成は、プレゼンテーションに含まれるメディアタイプごとに１つまたは複数のＡｄａｐｔａｔｉｏｎＳｅｔを持つことである。ビデオに関連するＡｄａｐｔａｔｉｏｎＳｅｔ４１２は、サーバから入手し得る符号化されたビデオの様々な可能なリプリゼンテーションに関する情報を含む。各リプリゼンテーションは、リプリゼンテーションエレメントに記述される。例えば、第１リプリゼンテーションは、６４０×４８０の空間解像度で符号化され５００ｋｂｉｔｓ／ｓのビットレートで圧縮されたビデオであり得る。第２リプリゼンテーションは、同じではあるけれども２５０ｋｂｉｔｓ／ｓのビットレートで圧縮されているビデオであり得る。
各ビデオは、その後、クライアントがそのビデオに関連するＨＴＴＰアドレスを知っているならば、ＨＴＴＰリクエストによりダウンロードされ得る。各リプリゼンテーションの内容とＨＴＴＰアドレスとのアソシエーションは、追加のレベルの記述：一時的セグメントを用いて行われる。各ビデオリプリゼンテーションは一時的セグメント４１３（通例、数秒）に分割される。各一時的セグメントは、ＨＴＴＰアドレス（ＵＲＬまたは１バイトのレンジを有するＵＲＬ）を介してアクセスし得るサーバに格納されているコンテンツを含む。ＭＰＤファイルに一時的セグメントを記述するために数個のエレメント：ＳｅｇｍｅｎｔＬｉｓｔ、ＳｅｇｍｅｎｔＢａｓｅまたはＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ、が使用され得る。
さらに、特定のセグメント：初期化セグメント、が利用可能である。初期化セグメントは、（もしビデオがＩＳＯ ＢＭＦＦまたはそのエクステンションを用いてエンキャプシュレートされているならば）そのエンキャプシュレートされているビデオストリームを記述するＭＰ４初期化情報を含む。例えば、それは、クライアントがそのビデオに関連する復号アルゴリズムをインスタンス化するのを助ける。
初期化セグメントおよびメディアセグメントのＨＴＴＰアドレスは、ＭＰＤファイルにおいて明示される。この説明において“セグメント”は一時的フラグメント（例：メディアがＩＳＯ／ＩＥＣ１４４９６パート１２およびパート１５に従ってエンキャプシュレートされるときにはｍｐ４ファイル内の１つまたは複数のｍｏｏｆ＋ｍｄａｔボックス）または一時的セグメント（例えば、“ｓｔｙｐ”指示から始まるｍｐ４セグメント）を示すために使われることに留意しなければならない。
図７ａに、例示的ＭＰＤファイルが示されている。示されているＭＰＤファイルにおいて２つのビデオリプリゼンテーションが記述されている。第１のものは低解像度バージョン（“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｉｄ＝“ｈ２６４ｂｌ＿ｌｏｗ””）であり、第２のものはより大きな解像度のバージョン（“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ ｉｄ＝“ｈ２６４ｂｌ＿ｆｕｌｌ””）である。両方のビデオリプリゼンテーションが同じＡｄａｐｔａｔｉｏｎＳｅｔに含まれ、各リプリゼンテーションの各セグメントがＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ ＵＲＬを通してアドレスされる（“ｍｅｄｉａ＝“ｍｐ４−ｌｉｖｅ−＄ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ＄−＄“Ｎｕｍｂｅｒ＄．ｍ４ｓ””。ここで＄ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ＄は２つの可能なビデオリプリゼンテーションの間で変化し、＄Ｎｕｍｂｅｒ＄はビデオの中での位置に沿って変化する）。
明瞭性を得るために、存在することのある関連付けられているオーディオストリームは表示されておらず、それらは別のＡｄａｐｔａｔｉｏｎＳｅｔにおいて、それぞれ代わりのバージョンと共に、記述され得る。
ストリーミングセッションを開始するとき、ＤＡＳＨクライアントはマニフェストファイルを要求する。受け取ると、クライアントはそのマニフェストファイルを分析し、その環境に適するＡｄａｐｔａｔｉｏｎＳｅｔのセットを選択する。次に、クライアントは、ＭＰＤの中の各ＡｄａｐｔａｔｉｏｎＳｅｔ内の、その帯域幅、復号およびレンダリングの能力に適合するリプリゼンテーションを選択する。次に、それは、要求されるべきセグメントのリストを前もって、まず第１にメディアデコーダのための初期化情報から、構築する（図７ａの例ではＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ＠ｉｎｉｔｉａｌｉｚａｔｉｏｎ ＵＲＬ）。初期化情報がデコーダにより受信されると、それらは初期化され、クライアントは第１メディアデータを要求して、実際に表示を開始する前に最小限の量のデータをバッファリングする。
これらの複数のリクエスト／レスポンスは、ストリーミングセッションのスタートアップ時に遅延をもたらし得る。リスクは、サービスプロバイダが自身のクライアントがそのビデオを見始めることなくサービスから去るという事態に遭遇することである。この、クライアントによって実行される第１メディアデータチャンクに対する最初のＨＴＴＰリクエストと、そのメディアデータチャンクが実際に再生しはじめるときとの間の時間をスタートアップ遅延と呼ぶのは普通のことである。それはネットワークのラウンドトリップ時間だけでなくメディアセグメントのサイズにも依存する：セグメントが長いほど、スタートアップ遅延は長くなる。
さらに、ライブストリーミングでは、クライアントがメディアセグメントを要求した時点で、このセグメントはサーバにおいて準備状態ではないかもしれない。レイテンシを小さくするために、セグメントの長さを小さくすることは有益であるかもしれない。しかし、そのようにセグメントの長さを小さくすると、リクエスト／レスポンスの数が劇的に増加して、かなりのネットワークトラフィックオーバーヘッドがもたらされるかもしれない。
そのようなトラフィックオーバーヘッドの増加を低減するために、提案されるアプローチは、サーバの自発性だけに基づいてデータをクライアントにプッシュできるようにサーバにおいてＨＴＴＰ／２のプッシュフィーチャを使用することである。より一般的にＨＴＴＰに関して、そのようなアプローチ（プッシュフィーチャの使用）は、リソースを多数のサブリソース（例えば、ｃｓｓ、ｊｓｃｒｉｐｔ、イメージを含むウェブページ；またはセグメントのリストを含むＤＡＳＨマニフェスト）に編成し得るようにＨＴＴＰクライアントとＨＴＴＰサーバとの間でのラウンドトリップの数（および、次にレイテンシ）を減らすことを可能にする。
上で言及されたように、ＨＴＴＰを通してのＤＡＳＨストリーミングと関連してプッシュフィーチャをそのように使用することは、特許文献１において既に提案されている。
この刊行物において提案されているメカニズムは、特に、プッシュポリシーに従ってどのデータまたはリソースをプッシュするかを決定するためにＭＰＤファイルにプッシュポリシーを適用できるように、サーバデバイスがＤＡＳＨについての高度に複雑な知識を持つことを要求する。
これらのメカニズムは、ＨＴＴＰを通しての適応ストリーミングの幾つかの有益な面に反する。
より正確には、ＨＴＴＰを通しての適応ストリーミングは、クライアントが一般的に自身の目的のためにマルチメディアコンテンツの最良のバージョンを選択し得るのでクライアントがストリーミングを案内するという仮定に基づいている。例えば、クライアントは、自身のフォームファクタおよびスクリーン解像度に基づいてＨＤビデオを要求するべきかそれともＳＤビデオを要求するべきかを知るであろう。ＨＴＴＰを通しての適応ストリーミングのためのプッシュフィーチャの使用は、そのような振る舞いを維持し、プッシュされるデータに関してクライアントがサーバを完全に主導できるようにするべきである。
さらに、ＭＰＥＧ ＤＡＳＨ標準規格のようなＨＴＴＰを通しての適応ストリーミングはサーバ側においてほとんど全くインテリジェンスを必要としない：クライアントにより送られるＨＴＴＰリクエストは単純なのでマニフェストおよびメディアセグメントにサービスをするために単純なＨＴＴＰサーバで十分である。このようにサーバが単純であるので、ＨＴＴＰの標準的ウェブ使用法以外の追加のコストをサーバリソースに要求することなく多数のストリーミングクライアントを供給することが可能である。特に、多数のストリーミングクライアントは、標準的ＨＴＴＰ最適化技術を用いてコンテンツ配信ネットワークを通して管理され得る。ＨＴＴＰを通しての適応ストリーミングのためのプッシュフィーチャの使用は、このサーバの単純性を維持するべきである。
本発明は、ＨＴＴＰと一般的に関連してプッシュフィーチャの使用を改善することを目指している。それは特に、ＨＴＴＰを通してのストリーミングとＤＡＳＨなどのＨＴＴＰを通しての適応ストリーミングとに適用される。しかし、本発明は、好ましくは、ＨＴＴＰを通しての適応ストリーミングの現存する有益なフィーチャをなるべく維持するべきである。これは、次の要件：
− 潜在的な無用の（クライアントにとって）データがサーバによりプッシュされるのを避けるためにクライアント制御の送信を維持すること；
− 上で言及されたスケーラビリティの利点を維持するためにサーバ側での特定のアプリケーション知識の使用を防止すること；
− レガシークライアントおよび／または本発明を実装しないサーバの間でのインタオペラビリティおよびキャッシュ能力を維持するためにリソースおよびサブリソースを在来の仕方で要求する仕方を維持すること。例えば、ＤＡＳＨセグメントの場合、これは、要求されたセグメントを処理するために特定の動作（例えばリクエスト−ＵＲＩの変換など）を必要とするリクエストフォーマットの導入を避けるべきである；
− サーバ側の処理を少なく保つこと；
のうちのなるべく多くが満たされるべきであることを意味する。
本発明のアイデアは、クライアントが（可能ならばプッシュメカニズムを用いて）受信したい追加のリソース／データまたは複数のリソースをサーバが判定するためのヒントを提供するか、あるいはクライアントが追加のリソースを受け取りたくないということをサーバが判断するためのヒントを提供する任意の情報を、第１データまたはリソースを要求する在来のＨＴＴＰリクエストに含めることである。特に、これらのヒントは、追加のリソース／データまたは複数のリソースの決定が文脈上の情報やリクエストの外側にある情報を使用しない仕方で定義される。ＨＴＴＰリクエストは、追加のリソース／データまたは複数のリソースの定義に関して自動記述的リクエストと見られ得る。
そのようなヒントの例は後述され、明示的なＵＲＩ／ＵＲＬもしくはＵＲＩ／ＵＲＬのリスト、自動記述的ＨＴＴＰリクエストに基づく構築ルールおよびリソース／データのフィルタリングルールの使用を通しての暗黙のＵＲＩ／ＵＲＬを含む。
本発明によるサーバ側方法は、サーバデバイスとクライアントデバイスとの間でデータを送信しようとするものであり、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、このＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに第２データを可能にする１つまたは複数の任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；ならびに
もしその任意ヘッダフィールドがＨＴＴＰリクエスト内に存在するならば：
任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報、を用いて、サーバデバイス上の第２データを特定することを可能にする第２データ特定情報を決定するステップ、を含む。すなわち、ＨＴＴＰリクエストは第２リソースを決定するために自給自足的である、すなわち、自己記述的である；および
第２データをクライアントデバイスにプッシュするとアナウンスするプッシュ約束メッセージを送るおよび／または第２データをクライアントデバイスにプッシュするステップ；
を含む。
特定の実施形態では、クライアントにより要求された第２データまたは追加リソースをサーバがプッシュすることをクライアントに知らせるために、サーバが第２データまたは追加リソースをプッシュしないことを知らせるために、またはサーバが送信し得る第２データまたは追加リソース／データまたは複数のリソースをクライアントが決定するためのヒントを提供するために、確認応答データがクライアントに送られる。
本発明によるクライアント側方法は、サーバデバイスとクライアントデバイスとの間でデータを送信しようとするものであり、クライアントデバイスにおいて：
サーバデバイスから得られるべきデータを特定するステップ；
その特定されたデータから第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは、サーバデバイス上の第１データを特定することを可能にする第１データ特定情報を含むとともに１つまたは複数の任意ヘッダフィールドを含み、その任意ヘッダフィールドだけ、および場合によってはさらに第１データ特定情報（すなわち、ＨＴＴＰリクエストの内容だけ）、に基づいて、サーバデバイス上の特定されたデータから第２データを特定することを可能にする第２データ特定情報を定義する、生成するステップ；
第１データを得るとともにサーバデバイスに第２データをプッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
特定の実施形態では、クライアントは、プッシュリクエストに関する確認応答データを受け取ると、第２データまたは追加リソースを得るために自身のストラテジーを適応させる。
第１データ特定情報は、普通、ＨＴＴＰリクエスト（またはそれの、ＨＴＴＰ／２疑似ヘッダへの変換）の“ｒｅｑｕｅｓｔ−ｌｉｎｅ”の一部を形成するリクエストＵＲＩに対応する。
本発明により提案されるアプローチは、上記要件の全てまたは部分を満たす。
第１に、本発明の方法は、クライアントが、データを要求すると同時に、プッシュするべき１つまたは複数の追加のまたは関連するリソースをサーバに対して明示することを可能にする。クライアントはこれらのリソースを、これらに対する特別のリクエストを送ることなく、受け取るであろうから、ネットワークトラフィックおよびレイテンシが低減される。
さらに、それらは、（本発明による任意ヘッダの、サーバのサポートに依存して）クライアントが追加リソースを受け取るであるか、またはクライアントがそれらを要求しなければならないか、をクライアントが（プッシュ約束フレームを通じて）知らされることをも可能にする。このように現存するストリーミングサーバとの下位互換性は維持され、フィーチャの展開はより容易にされるはずである。
さらに、それらは、サーバがクライアントにプッシュされるべき次の１つまたは複数のリソースを、アプリケーション特有の知識を必要とすることなく、容易に特定することをも可能にする。従って、サーバ側での処理は限定され、多数のクライアントが同じサーバに要求することをオーソライズされ得る。
図３ａは、本発明の実装のためのクライアント／サーバシステムの一般的説明図を示す。以下で、ビデオはメディアまたはコンテンツの特別の場合であることを分かった上で、リソースを示すために“ビデオ”、“メディア”または“コンテンツ”が差別されずに言及される。同様に、サーバからクライアントに送信されるべきメディアリソースの記述ファイルを示すために“ＭＰＤ”または“マニフェスト”または“ストリーミングマニフェスト”または“ＨＴＭＬページ”が差別されずに言及される。
本発明は、図３ａに示されているようにクライアントとサーバとの間でのＨＴＴＰ通信、特にデータストリーミング、を改善することを狙っており、より正確にはリソースのローディング時間およびネットワークトラフィックオーバーヘッドの両方を低減することを狙っている。
サーバ３５０は、クライアント３８０がダウンロードできるリソースを保存している。サーバ上のリソースは、サブリソース（３５２ａ、ｂ、ｃ）を参照または包含するメインリソース３５１に分類される。
例えば、メインリソースはＨＴＭＬページであり得、サブリソースは、ｃｓｓリソース、イメージおよび／またはメディアファイル、ｊａｖａスクリプトコードまたはメインリソースにおいて参照される他のＨＴＭＬページであり得る。これらのリソースのアクセス権および編成は、静的設定ファイル３５５において記述され得る。
クライアント３８０により発せられるＨＴＴＰリクエストはＨＴＴＰプロセッサ３５６により受信されて処理され、このプロセッサ３５６は、そのリクエストをリソース特定およびヘッダ処理に分解するリクエストパーサ３５７を含む。
本発明は、プッシュヘッダプロセッサ３５８により行われる１つの特定のヘッダ処理を考慮する。後者は、以下で記載されるようにＨＴＴＰリクエストにおいて任意的である１つまたは複数の特定のプッシュヘッダの処理を担当する。上で簡潔に紹介されたように、その１つまたは複数の特定のプッシュヘッダに基づき、ＨＴＴＰリクエストだけを用いて、サーバは追加リソースへの１つまたは複数の参照を、それらをプッシュするために、生じさせることができる。
リソースマネージャ３６０は、リソースの存在／不在／鮮度のチェックおよび要求されたリソースのＨＴＴＰプロセッサ３５６への供給を担当する。次に、レスポンスジェネレータ３５９は、これらの供給されたリソースを、クライアントに送られる１つまたは複数のＨＴＴＰレスポンス（ＨＴＴＰ／１．ｘ）またはフレーム（ＨＴＴＰ／２において）にエンキャプシュレートする。
クライアント３８０は、数個のクライアントモジュールにより処理されるコンテンツをユーザが選択し、それと相互作用しおよび見るためのユーザインターフェース３８１を有する。
ユーザインターフェース３８１は、ユーザのクリックを、ＨＴＴＰクライアント３８２内のリクエストスケジューラ３８３により処理される追加コンテンツに対するリクエストに変換する。その追加コンテンツに対するリクエストは、ダウンロードされるべきリソースのリストとして変換され得る。ＨＴＴＰクライアント３８２は、ＨＴＴＰサーバ３５０との通信を処理する。
ＨＴＴＰクライアントは、サーバ３５０に対してリソースを要求するためにＨＴＴＰリクエスト（ＨＴＴＰ１．ｘ）またはフレーム（ＨＴＴＰ／２）を構築するリクエストジェネレータ３８４を含む。
本発明により、ＨＴＴＰクライアント３８２は、リクエストスケジューラ３８３内で待機している次の１つまたは複数のリソースを明示しおよび／またはプッシュポリシー、プッシュストラテジーまたはプッシュディレクティブを明示する上記の特定の（任意の）プッシュヘッダをＨＴＴＰリクエストに挿入することを担当する特定のモジュール、すなわちプッシュヘッダジェネレータ３８５、を含む。特定の実施形態では、プッシュヘッダは、プッシュタイプ、および場合によっては関連するパラメータ、を含み得る。
サーバから受信されたレスポンスまたは通知は、データを抽出してそれらをクライアントキャッシュ／メモリ３８７に格納するレスポンスパーサ３８６により処理される。レスポンスヘッダにより運ばれる情報も、ＨＴＴＰクライアント３１１により受け取られて処理され、ＤＡＳＨ制御エンジン３１３が利用できるようにされ得る（例えば、ＤＡＳＨアプリケーションがＸｍｌＨＴＴＰＲｅｑｕｅｓｔを用いてｊａｖａｓｃｒｉｐｔコードで書かれているとき）。
これらのデータはレンダリングエンジン３８８により使用され、このエンジンはデータをパース（３８９）してそれらを適切な復号モジュール３９０にディスパッチする。それらのデータに基づいて、後者は、復元されたデータを、ユーザインターフェース３８１でのレンダリングのために、ディスプレイ３９１に供給する。
本発明により、パースモジュール３８９は、ユーザにとって潜在的に興味あるものである追加リソースを特定するために、受け取られたデータの内容を分析することができる。そのような場合、パースモジュール３８９は、それらの追加リソースをリクエストスケジューラ３８３において追加する。
クライアントの振る舞いは図５ａに示され、サーバの振る舞いは図６ａに示されている。
図５ａを参照すると、ステップ５５１において、クライアントは、ＨＴＴＰリクエストを用いてメインリソース、例えばＨＴＭＬのウェブページまたはストリーミングマニフェスト、を要求する。そのウェブページのためのＨＴＭＬコードは、そのウェブページを構成するリソースを特定するためにステップ５５２で（モジュール３８９を用いて）パースされる。そのパースの結果を用いて、クライアントは、そのページ全体をレンダリングできるように、自身がダウンロードしなければならないリソースのリストを特定する。これはステップ５５３であり、そのリソースのリストはスケジューラ３８３に格納される。
ステップ５５４において、クライアントは、第１の特定されたリソースをサーバから得るために第１ＨＴＴＰリクエストを生成して送る。本発明により、クライアント（モジュール３８５）は、特定のプッシュヘッダにおいて、自身がサーバにプッシュしてもらいたい追加の／関連するリソースのリストを明示することもできる。これはステップ５５５である。特定のプッシュヘッダのためのシンタックスの例が以下に与えられる。
ステップ５５６においてサーバから１つまたは複数のレスポンスを受け取ると、クライアント（モジュール３８４）は、データのプッシュをアナウンスするサーバ通知（すなわちプッシュ約束）が受け取られたか否かチェックする（ステップ５５７）。このチェックは、第１リソースについてのデータが完全に受け取られたとき、止められ得る。その理由は、要求された第１リソースに対応するストリームの終結後には、特定のプッシュヘッダにより定義された追加の／関連するリソースに関連するプッシュ約束は送られることができないことである。ここで、特定のプッシュヘッダをサポートしないサーバは、このヘッダで定義された追加の／関連するリソースのためのプッシュ約束を送らないで単にこのヘッダを無視するであろうということが想起される。
もしチェックが否定であれば、受け取られるデータは、要求された第１リソースのそれだけである。従って、それらはステップ５６０でモジュール３８４により処理されて、レンダリングエンジン３８８に供給される。プロセスはその後ステップ５５５に戻り、リクエストスケジューラ３８３に保存されているさらなるリソースを要求する（ステップ５６１）。
もしチェックが肯定で、サーバが特定のプッシュヘッダでクライアントにより示唆されたリソースのうちの幾つかをプッシュすることを意味するならば、クライアントはリクエストスケジューラ３８２内のダウンロードするべきリソースのリストをアップデートして、そのプッシュされるリソースをそこから撤回する。これはステップ５５８である。クライアントは、その後、ダウンロードするべきリソースがリクエストスケジューラ３８２に最早残っていなくなるまで反復する（ステップ５６１およびステップ５５５へのループ）前に、第１リソースのためのデータ（ステップ５６０）およびその他の追加の／関連するリソースのためのデータ（ステップ５５９）を処理する。
ここで図６ａに転じて、クライアント３８０によりＨＴＴＰリクエストに設けられる特定のプッシュヘッダを処理するためにサーバ３５０は専用の“プッシュヘッダ”プロセッサ３５８を使用するということが想起される。さらに、ＨＴＴＰプロセッサ３５６は、ＨＴＴＰリクエストをパースすること、および、要求された第１リソースのＵＲＩおよび任意の１つまたは複数のヘッダを含む、リクエストに含まれている種々のパラメータを抽出することを担当する。このように、ＨＴＴＰプロセッサ３５８は、特定の（任意の）プッシュヘッダをその名前によって特定し、それを処理させるべくプッシュヘッダプロセッサ３５８に転送する。
ステップ６０１において、サーバは、クライアント３８０からリクエストを受け取ってそれを、メインリソース、例えばストリーミングの文脈においてはストリーミングマニフェスト、を得るために処理する。それは、ＨＴＴＰプロセッサ３５６により処理される。
次にステップ６０２において、サーバはマニフェストデータを送ることで応答する。ステップ６０３において、サーバは第１リソース、普通はマニフェストデータにおいて参照されている第１リソース、を要求するクライアントからの新しいリクエストを受け取る。これは、メディアストリーミングの文脈においてはメディアセグメントであり得る。
このリクエストにおいて、クライアントは自身が関心を持っている追加のあるいは関連するリソースを、特定のプッシュヘッダを用いて、明示しているかもしれない。従って、ステップ６０４において、サーバは、そのような特定のプッシュヘッダがリクエストに含まれているか否かをチェックする。
もしそれが含まれていて書き込まれているならば、サーバはその特定のプッシュヘッダを特定プッシュヘッダプロセッサ３５８に供給する。後者は、クライアントにより明示された追加のあるいは関連するリソースへの１つまたは複数の参照を生成するために、以下で記載されるようにそのプッシュヘッダの様々な部分をパースする。これはステップ６０５である。
任意に、サーバは、自身が所有しているリソースのリストに属する各リソースについて、それをプッシュできるか否かを宣言する事前設定されたオーソライゼーションファイルを持つことができる。このオーソライゼーションファイルは、ステップ６０５で得られた幾つかの参照を有効にまたは無効にするためにステップ６０６で考察され得る。
サーバは、オーソライゼーションファイルに従ってそのプッシュがオーソライズされているリソースだけのためにプッシュアナウンスメントメッセージ（例えば、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム）でクライアントに通知する。これはステップ６０７である。ＨＴＴＰ／２では、ＰＵＳＨ ＰＲＯＭＩＳＥフレームは、クライアントのリクエストに対応するストリームで、ステップ６０５において特定されたリソースあたりに１つのＰＵＳＨ ＰＲＯＭＩＳＥフレームが、送られる。ステップ６０７にステップ６０８が続き、このステップでサーバは、要求された第１リソース（すなわち、ストリーミングの文脈においては第１メディアセグメント）を、要求しているクライアントに送る。
もし特定プッシュヘッダが存在しないかまたはサポートされなければ（テスト６０４がフォールス）、あるいはもし特定されたリソースについてプッシュが全くオーソライズされなければ（テスト６０６がフォールス）、要求された第１リソースだけがステップ６０８でクライアントに送り返される。
要求された第１リソースを送ると、次にサーバは、対応するストリームを閉じるとともに、プッシュアナウンスメントメッセージ（ＰＵＳＨ ＰＲＯＭＩＳＥフレーム）でアナウンスされたストリームを、もしクライアントによりキャンセルされなければ、用いて、ステップ６０５で特定された追加のまたは関連するリソースのためのデータをプッシュする。これはステップ６０９であり、このステップで送ることは、１つまたは複数のデータフレームを送ることに依拠し得る。
上記のように、特定の実施形態では、クライアントにより要求された第２データまたは追加のリソースをサーバがプッシュするであろうことをクライアントに知らせるか、第２データも追加リソースもサーバはプッシュしないであろうことを知らせるか、あるいはサーバが送信できる第２データまたは追加リソース／データもしくは複数のリソースをクライアントが決定するためのヒントを提供するために確認応答データがクライアントに送られる。
従って、参照記号６１０で示されているように、サーバは、クライアントにより要求された第２データまたは追加のリソースをサーバがプッシュするであろうことをクライアントに知らせるか、第２データも追加リソースもサーバはプッシュしないであろうことを知らせるか、あるいはサーバが送信できる第２データまたは追加リソース／データもしくは複数のリソースをクライアントが決定するためのヒントを提供するために、受信されたリクエストに応答して送られるレスポンスに確認応答データを付け加えることができる。そのような確認応答データの例は、図１１ａから１１ｅを参照することにより与えられる。
図３ｂは、データストリーミング、例えばＤＡＳＨ、と関連するクライアント−サーバシステムを示す。図３のそれと同じコンポーネントは同じ参照数字を有する。
第１に、ダウンロードするべきメディアセグメントの決定を担当するＤＡＳＨ制御エンジン３１３において、ＤＡＳＨ制御エンジン３１３の中のリクエストスケジューリングモジュールにより推測されたダウンロードするべき次のセグメントのリストをＨＴＴＰクライアント３１１と通信するための追加モジュールが付け加えられている。
この情報は、ＨＴＴＰクライアント３１１において特定の“プッシュヘッダ”ジェネレータ３１４により処理される。ダウンロードするべき次のセグメントのリストから、プッシュヘッダジェネレータ３１４は、例えばダウンロードするべき次のセグメントのリストを特定プッシュヘッダの様々な部分にマッピングすることによって、特定プッシュヘッダのための適切なシンタックスを生成することを担当する。
プッシュヘッダジェネレータ３１４により出力された特定プッシュヘッダは、現在のＨＴＴＰリクエストに挿入されるべくＨＴＴＰクライアント３１１に供給される。
サーバ側で、ＨＴＴＰプロセッサ３２０およびプッシュヘッダプロセッサ３２１は、図３ａに関連して上で記載されたＨＴＴＰプロセッサ３５６およびプッシュヘッダプロセッサ３５８に類似してはいるが、ストリーミングおよびＤＡＳＨ指向である。
図５ｂは、図３ｂのシステムにおけるストリーミング指向クライアントの振る舞いを説明する主なステップを示す。
ステップ５０１において、クライアント３１０は、希望するメディアと関連付けられたストリーミングマニフェストをストリーミングサーバ３００に要求する。ストリーミングマニフェストを受け取ると、クライアント３１０はステップ５０２でそれをパースし、次にステップ５０３でビデオリプリゼンテーションを選択する。
反復してメディアのストリーミングの間に、クライアントはサーバに対してダウンロードするように要求する次のセグメントを選択する。これはステップ５０４である。
次に、ステップ５０５はクライアントが必要とするかもしれない将来のセグメントを特定することである。この決定は、ＤＡＳＨ制御エンジン３１３内のリクエストスケジューラにとっては将来のセグメントを予想することであり：例えば、それがすぐに切り替えるかあるいは同じリプリゼンテーションレベルにとどまるかを決定する。
次の１つまたは複数のセグメントのダウンロードを予想するために、クライアントは、後のレンダリングに必要な将来のセグメントの数“Ｋ”（Ｋは、クライアントによりセットされる）を特定することができる。
例えば、これは、現在の１つから次のＫ個のセグメントを取り出すためにＭＰＤ内のＳｅｇｍｅｎｔＬｉｓｔをパースすることにより、またはＭＰＤに設けられているＳｅｇｍｅｎｔＴｅｍｐｌａｔｅを用いて次のＫ個のセグメントのためにセグメント番号を計算することにより、またはセグメントがバイトレンジを通してアドレスされるときにｍｐ４ボックスから次のＫ個のバイトレンジを計算することによって、直接行われ得る。
しかし、ステップ５０５の特定するプロセスに異なる選択基準が使用され得る。
適応ストリーミングと関連して、選択基準は、リプリゼンテーション間で切り替えを行うときクライアントの切り替えストラテジーを含み得る。例えば、クライアントが積極的な切り替えストラテジーを採用するとき、Ｋはより精細な切り替えグラニュラリティを可能にするためにローとして定義される（例えば、５秒未満をカバーするセグメントの数に対応する）。一方、クライアントが保守的なストラテジーを採用していてあまり頻繁には切り替えをしないときには、Ｋはより大きくセットされ得る（例えば、１０秒以上をカバーするセグメントの数に）。
なお適応ストリーミングと関連して、別の選択基準はサーバのＰＵＳＨ ＰＲＯＭＩＳＥ能力を含み得る。例えば、もしサーバがクライアントにより提案されたのと同じ数のセグメントを適時に約束しまたは送ることができなければ、クライアントはこの情報を考慮してＫの値を小さくすることができる。その結果、毎回、より少ないメディアセグメントがプッシュされるべく提案されることとなる。
なお適応ストリーミングと関連して、別の選択基準はクライアントのプリフェッチストラテジーを含み得る。例えば、クライアントは、様々な期間の初めに、高速シークを目的として最初のセグメントを選択することができる。あるいは、もしビデオアプリケーションがビデオ中の非常に人気のある部分に関する情報を提供するならば、その基準は、それらの非常に人気のある部分に対応する最初のセグメントを選択することを含み得る。
別のあり得るストリーミング指向の選択基準は、マニフェスト、ＭＰＤ、の分析からもたらされ得る。例えば、クライアントは、選択されたリプリゼンテーションと関連付けられているセグメントをプッシュすることをサーバに提案することができる。これは、関連付けられているリプリゼンテーション間のａｓｓｏｃｉａｔｉｏｎＩＤを用いて容易に決定され得る。この提案は、ａｓｓｏｃｉａｔｉｏｎＴｙｐｅ情報に依拠することができる。さらに、従属リプリゼンテーションについては、エンハンスメントレイヤのためのセグメントがプッシュされるべく提案され得る。
より一般的にＨＴＴＰを通してのリソースダウンロード、例えばウェブページ（図３ａおよび５ａを参照）、においては、クライアント（ウェブブラウザ、ＨＴＭＬレンダラー）は、メインリソースを分析し、それにおいて参照されている、自身が急いでダウンロードしたい１つまたは複数のサブリソースを特定することができる。ＨＴＭＬメインリソースをパースすることにより、クライアントは例えば：
− “プリフェッチ”または“次”を明示する“ｒｅｌ”値を有する＜ｌｉｎｋ＞エレメント；
− 例えばＣＳＳリソースを選択するスタイルシート関連リソースを明示する＜ｌｉｎｋ＞エレメント；
− 例えばｊａｖａスクリプトコードに対応するサブリソースを選択する＜ｓｃｒｉｐｔ＞エレメント；
− ＜ｉｍｇ＞および／または＜ｖｉｄｅｏ＞のようなメディアエレメント；
に依拠することができる。
ＨＴＭＬページで宣言されていることのあるこれらのエレメントから、クライアントは、それらの“ｈｒｅｆ”属性を通してＵＲＩのリストを選択することができる。ＵＲＩのこのリストは、例えばリソースのタイプに応じて１つまたは複数の特定プッシュヘッダ内に置かれ、またはＵＲＩのリストとして単一のヘッダ内で連結され、または公知のＡｃｃｅｐｔ ＨＴＴＰヘッダ内において“ｑ”値に類似する優先順位付きリストとして編成され得る。
Ｋ個の追加のまたは関連するリソースを選択し特定するステップ５０５の後、クライアントはステップ５０４で特定された次のセグメントを得るＨＴＴＰリクエストを生成する。これはステップ５０６である。
（リクエストラインを形成するＨＴＴＰメソッドの他に）ＨＴＴＰリクエストを形成するために次のセグメントのＵＲＬまたは１つのバイトレンジを有するＳｅｇｍｅｎｔＢａｓｅ ＵＲＬが使用される。
本発明により、追加のステップ５０７は、ＨＴＴＰクライアント３１１のプッシュヘッダプロセッサ３１４に関してステップ５０５でＤＡＳＨ制御エンジン３１３により決定された将来のセグメント（すなわち追加のリソース）のリストを得ること、および、これらの将来のセグメントを定義するために特定プッシュヘッダをセットすることである。
クライアントがサーバにプッシュしてもらいたいこれらの将来セグメントを宣言する幾つかの仕方が、以下で記載されるように実装され得る。
次のセグメントのためのリクエストラインを含むとともに追加セグメントのプッシュを提案するための特定プッシュヘッダを含むＨＴＴＰリクエストが準備状態になると、それはなおステップ５０７においてＨＴＴＰクライアント３１１によりサーバ３００に送られる。
ステップ５０８でサーバからレスポンスを受け取ると、クライアントは、特定プッシュヘッダで定義された追加セグメントをサーバが進んで送ることを示すプッシュアナウンスメント通知をサーバが送っているかどうかチェックする。このチェックはステップ５０９である。
プッシュアナウンスメント通知は、将来のセグメント１つあたりに１つずつ、１つまたは複数のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを用いて例えばＨＴＴＰ／２で行われ得る。
もしステップ５０４で選択されて要求された次のセグメントのためのデータが完全に受け取られ（対応するストリームはサーバにより閉じられる）プッシュアナウンスメント通知が受け取られていなければ（テスト５０９フォールス）、ＨＴＴＰクライアント３１１は、要求する次のセグメントはその直後のセグメントであるということをＤＡＳＨ制御エンジンに知らせる。これはステップ５１０である。
そうでなければ（テスト５０９トゥルー）、新しいＨＴＴＰリクエストを用いて要求する次のセグメントは、プッシュされると約束された最後のセグメントの直後のセグメントである。クライアント側でのアップデートはステップ５１１で行われる。その間に、ステップ５１２で、Ｋ個の将来のセグメントのためのデータがサーバからＨＴＴＰクライアントにより受け取られる。
ステップ５１０および５１２の次に、ストリーミングが終了するまでプロセスを反復するためにプロセスはステップ５０５にループバックする。
代わりに、クライアント３１０は、得るべきＫ個の将来のセグメントの処理をＨＴＴＰクライアント３１１において実装することができる。そのような実装では、ダウンロードするべき次の１つまたは複数のセグメントの決定を担当するのはＨＴＴＰクライアントである。次のセグメントを要求するときに、ＤＡＳＨアプリケーションレベルにおいて知覚されるレイテンシが低減されるように、ＨＴＴＰクライアント３１１により受け取られたプッシュされたデータは、そのとき、ＤＡＳＨ制御エンジン３１３のために予めクライアントキャッシュ（３０７）を満たすであろう。
特定の実施形態では、クライアントは、プッシュリクエストに関する確認応答データを受け取ると、例えば第２データまたは追加のリソースを得る自身のストラテジーを適合させるために、受け取った確認応答データを処理する（ステップ５１３）。そのような確認応答データの処理の例は、図１１ａから１１ｅを参照することにより与えられる。
全てのＨＴＴＰヘッダとして、特定プッシュヘッダのシンタックスを見ると、それは｛名前、値｝ペアによって特定され、その名前と値とはコロン‘：’によって分離される。
ヘッダ名は、例えば“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”であり得、あるいはそれが他の既存のヘッダ名と衝突しなければ他の任意の名前であり得る。もしそれがアプリケーション専用ヘッダであるならば、名前はアプリケーション名から始まることができる：例えば様々なケースに釣り合う“ＤＡＳＨ−Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”または“ＨＴＭＬ−Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”。
以下で、アプリケーション関連のプレフィックス無しで一般的ヘッダが考察される。
特定プッシュヘッダの目標は、１つまたは複数の一意リソース識別子（ＵＲＩ）またはロケータ（ＵＲＬ）などを定義して（サーバに）提供し、第１リソースを要求しているクライアントのために追加のリソースまたは関心の対象であるリソースの部分を特定することである。本発明により規定されるように、ＨＴＴＰリクエストは、これらの追加リソースを決定するために自給自足的でなければならない、すなわち外部からのあるいは前後関係上の情報を用いずに決定しなければならない。
追加リソースまたはリソースの部分を定義する種々の実施形態が考えられる。
複数の実施形態において、特定プッシュヘッダは、これらの追加リソースを特定するためのＵＲＩまたはＵＲＬを明示的に含む。例えば：
＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＨＴＴＰ：／／ｓｅｒｖｅｒ／ｐａｔｈ／ｓｅｇｍｅｎｔ−２．ｍｐ４＞
他の複数の実施形態では、それらは構築ルールを通して示され、そのルールは特定プッシュヘッダに挿入される。換言すれば、関心の対象である追加リソースのリストは構築ルールとして表現される。特定プッシュヘッダのシンタックスは、図６ｂに示されている通りであり得る。
ヘッダ６５０のヘッダ値は予約文字、例えば‘；’、により分離される３つの別々の部分から構成される。
第１部分６５２は、２つの他の部分により定義される構築ルールがＨＴＴＰリクエストのどの部分に適用されなければならないかを定義する“サポート”である。特に、そのようなＵＲＩまたはＵＲＬは、ＨＴＴＰリクエストにおいてセットされたリクエスト−ＵＲＩの全部または一部であり得る。
このように、“サポート”という語は、最初のリクエスト−ＵＲＩ自体を指すことができるし、ＨＴＴＰリクエスト内に存在する別のＨＴＴＰヘッダを指すこともできる。
第２部分６５３は、サポートからの抽出パターン、すなわちサポート部分６５２が指すＵＲＩまたはＵＲＬの変化部分、を定義する。
例えば、リクエスト−ＵＲＩなどの中の変化部分は、予約文字を用いて明示され得る。１つの変化形では、変化部分は、抽出して修正するべきリクエスト−ＵＲＩなどの部分を示す正規表現として表現され得る。
従って第２部分６５３は、変化部分情報を含んでいて、ＵＲＩテンプレートの形をとることができる。
サポートが他の１つのＨＴＴＰヘッダであるときには、示すべき抽出パターンが無いことがあり、或いは、例８８０に関しては（以下を参照）、ヘッダ値全体が置換するべきパターンとして示される。
最後の部分６５４は、第２部分６５３により定義される変化部分の後継者として適用するべき１つまたは複数の代入値を任意に含む。
代入値は、値のコロン分離（または任意の専用セパレータ）リストを用いて、あるいは値のレンジを用いて、あるいはレンジのリストを用いても、定義され得る。そのような場合、プッシュヘッダプロセッサ３２１／３５８は、その値のリストまたは１つもしくは複数のレンジ全体を繰り返して代入値と同数のＵＲＬを推測するべきである。
例えば、第１部分と第２部分とがマージされるとき：
＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＨＴＴＰ：／／ｓｅｒｖｅｒ／ｐａｔｈ／ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４；｛２−５｝＞
ここで｛１｝は変化部分を定義し、｛２−５｝は代入値である。
３つの別々の部分を有する別の例は次の通りである：
＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｒｅｑｕｅｓｔ−ＵＲＩ；ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４；｛２−５｝＞
ここで“ｒｅｑｕｅｓｔ−ＵＲＩ”はサポートであり、“ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４”は変化部分｛１｝を有するサポートにより定義されるＵＲＩの部分であり、｛２−５｝は代入値である。
１つの問題は、構築ルールをなるべく一般的に構築することである。そのような構築のための例示的な重要な面は、適応ストリーミングと関連して提供される。
メディアセグメントまたはメディアコンテンツサブパーツを記述する種々の仕方：ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅ、ＳｅｇｍｅｎｔＢａｓｅまたはＳｅｇｍｅｎｔＬｉｓｔ、がＤＡＳＨで提供され、一度にこれら３つのうちの１つだけがＲｅｐｒｅｓｅｎｔａｔｉｏｎ、ＡｄａｐｔａｔｉｏｎＳｅｔまたはＰｅｒｉｏｄエレメント内に存在する。
ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅは、自身がダウンロードしたい次のセグメントに関してクライアントがサーバにヒントを提供するためのＵＲＩテンプレートを容易に構築する最も便利な方法である。その理由は、ＳｅｇｍｅｎｔＴｅｍｐｌａｔｅはマニフェストで定義されているセグメントＵＲＬのどの部分がまさに変化しようとしているかを、例えばリプリゼンテーションの一意識別子またはリプリゼンテーションの帯域幅などに依存して、明らかに示すことである。この場合、クライアントによるＫ個の将来のセグメントの特定は、ＤＡＳＨ制御エンジン３１３で利用し得る、標準的テンプレート分解プロセス以外の能力を必要としない。
これは図７ａの例の場合である。ＵＲＩテンプレート“ｍｐ４−ｌｉｖｅ−＄ＲｅｐｒｅｓｅｎｔａｔｉｏｎＩＤ＄−＄Ｎｕｍｂｅｒ＄．ｍ４ｓ”から、同じＲｅｐｒｅｓｅｎｔａｔｉｏｎ“ｈ２６４ｂｌ＿ｌｏｗ”の現在のセグメントＮの後のＫ個のセグメントを指定する構築ルールを定義するのは容易である。
＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：“ｍｐ４−ｌｉｖｅ−ｈ２６４ｂｌ＿ｌｏｗ−｛１｝．ｍ４ｓ”；｛（Ｎ＋１）−（Ｎ＋Ｋ）｝＞
ＳｅｇｍｅｎｔＬｉｓｔアプローチに関しては、クライアントは、リストされているセグメントのＵＲＩ間の繰り返すパターンを特定するためにＭＰＤファイルを前処理し、次にセグメントＵＲＬのリストを表す一般的ルールを推測することができる。
代わりに、ＭＰＤアナライザは、この作業をオフラインで行い、使用され得るＵＲＩテンプレートを提供するためにＳｅｇｍｅｎｔＬｉｓｔに新しいエレメント、属性またはディスクリプタを付けることができる。これは、クライアント側での処理を促進するためである。エレメントまたは属性として、ＵＲＩテンプレートはＳｅｇｍｅｎｔＬｉｓｔエレメントの中で定義され得るであろう。ディスクリプタとして、それはＳｅｇｍｅｎｔＬｉｓｔの親エレメントにおいて定義され得るであろう（例えばＲｅｐｒｅｓｅｎｔａｔｉｏｎエレメントのレベルで）。
図１０は、セグメントの記述のためにＳｅｇｍｅｎｔＬｉｓｔエレメントを使用するＭＰＤサンプル１０００を提供する。ＳｅｇｍｅｎｔＬｉｓｔは、ＳｅｇｍｅｎｔＵＲＬエレメントの列挙を含む。このＭＰＤサンプルにおいて、同じビデオコンテンツのための２つの二者択一リプリゼンテーション１００２、１００３が同じＡｄａｐｔａｔｉｏｎＳｅｔ１００１の中に記載されている。
各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ内のＳｅｇｍｅｎｔＵＲＬのリストをパースすることにより、クライアントは、ＵＲＬが、セグメントインデックスを除いて、大部分は一定であることを容易に判定することができる。
次に、１００５および１００６に設けられている例示的ＵＲＩテンプレートのような注釈が親Ｒｅｐｒｅｓｅｎｔａｔｉｏｎエレメントに付け加えられ得る（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎあたりにせいぜい１つのＳｅｇｍｅｎｔＬｉｓｔであるため）。（＠ｔｅｍｐｌａｔｅＵＲＩ属性内の）この注釈のおかげで、リスト内の１つまたは複数のセグメントをプッシュされるべきものとして示したいクライアントは、＠ｔｅｍｐｌａｔｅＵＲＩ値を特定プッシュヘッダ内にコピーアンドペーストするだけで良いであろう。
クライアントのためのＵＲＩテンプレートの使用をさらに簡単化するために、得られた＠ｔｅｍｐｌａｔｅＵＲＩ１００５および１００６のどの部分が一方のＲｅｐｒｅｓｅｎｔａｔｉｏｎと他方のＲｅｐｒｅｓｅｎｔａｔｉｏｎとで異なっているかをチェックすることができる。その理由は、この例１０００では、同じＡｄａｐｔａｔｉｏｎＳｅｔ内に複数のＲｅｐｒｅｓｅｎｔａｔｉｏｎがあることである。これは、今度は複数の変数または変化部分を伴うＡｄａｐｔａｔｉｏｎＳｅｔレベルにおいて、他の１つのテンプレート属性の生成をもたらす（１００７を参照）。
従って、１つのレベルから次のレベルへと、＠ｔｅｍｐｌａｔｅＵＲＩ属性を漸次一般化してゆくことが可能である。従って、その一般化プロセスは、ｓｅｇｍｅｎｔＵＲＬ値が完全に同様のままとなるまで、１つまたは複数の親セグメントにわたって反復され得る。
＠ｔｅｍｐｌａｔｅＵＲＩ注釈１００７に関しては、ＵＲＩテンプレートが偶然に複数の変数または変化部分を含むことがあり得る。そのような場合、それらの変化部分をそれらのそれぞれの代入値との置換のためにどの順序で考察してゆかなければならないかを決定するのはクライアントである。従ってクライアントは、サーバがこれらの変化部分を考察するときにサーバを所定の順序に従わせるために、各変化部分を優先レベルと関連付けることができる。
任意に、＠ｔｅｍｐｌａｔｅＵＲＩ属性の他に、＠ｔｅｍｐｌａｔｅＵＲＩ属性の１つまたは複数の変化部分のために可能な値のレンジを示すために＠ｔｅｍｐｌａｔｅＶａｌｕｅ属性も設けられ得る。可能な値のレンジは、ＭＰＤに基づいて、すなわち図１０の例ではＳｅｇｍｅｎｔＵＲＬのリストに基づいて、決定される。
例えば、注釈１００５および１００６の他に、同じ値のレンジ：＠ｔｅｍｐｌａｔｅＶａｌｕｅ＝“｛１−６｝”を定義するために注釈１００５および１００６の各々と共に＠ｔｅｍｐｌａｔｅＶａｌｕｅ属性が宣言され得るであろう。
ＡｄａｐｔａｔｉｏｎＳｅｔレベルに加えられた＠ｔｅｍｐｌａｔｅＵＲＩに関して、＠ｔｅｍｐｌａｔｅＶａｌｕｅ属性は次の値を取るであろう：＠ｔｅｍｐｌａｔｅＶａｌｕｅ＝“ｌｏｗ：ｈｄ；｛１−６｝”。‘ｌｏｗ’および‘ｈｄ’文字列はリプリゼンテーション識別子に対応する第１変数“ｌｅｖｅｌ”のための可能な値をリストし、レンジ｛１−６｝はセグメントインデックスに対応する第２変数“ｎｂ”のための可能な値をリストする。
図６ｂに示されている特定プッシュヘッダのシンタックスに戻り、一実施形態は、特定プッシュヘッダを記述するとき１つまたは複数の抽出パターン６５３を表現するために次の文法とＵＲＩテンプレートに関するＲＦＣ６５７０とを使用する。
“プッシュヘッダ”は次のように定義され得る：
ｐｕｓｈ＿ｒｅｑｕｅｓｔ＝“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：“ｈｅａｄｅｒ＿ｎａｍｅ”；“ｕｒｉ＿ｔｅｍｐｌａｔｅ＊（“；”ｄｅｆｉｎｉｔｉｏｎ）
ｈｅａｄｅｒ＿ｎａｍｅ＝“ＵＲＩ”｜ＨｅａｄｅｒＮａｍｅ
ＨｅａｄｅｒＮａｍｅは、様々なＨＴＴＰバージョンの仕様の中の所定のヘッダ名に対応する。
ｕｒｉ＿ｔｅｍｐｌａｔｅパラメータは、潜在的にエクステンションを伴ってＲＦＣ６５７０において定義されているＵＲＩテンプレートである。このテンプレートは、中括弧の間に定義される、その名前が数である変数または変化部分を含み得る。例えば：／ｓｅｒｖｅｒ／ｖｉｄｅｏ｛１｝．ｍｐ４は１つの変化するパラメータを有するｕｒｉ＿ｔｅｍｐｌａｔｅであり、／ｓｅｒｖｅｒ／｛１｝／ｉｍａｇｅ｛２｝．ｊｐｇは２つの変化するパラメータを有する別のｕｒｉ＿ｔｅｍｐｌａｔｅである。
最も単純な場合は、サポート全体がが宣言された定義、すなわち代入値、に置き換えられるべきであることを意味する｛１｝に等しいｕｒｉ＿ｔｅｍｐｌａｔｅに対応する。さらに、宣言された変数を持たないｕｒｉ＿ｔｅｍｐｌａｔｅは、サポート６５２全体がｕｒｉ＿ｔｅｍｐｌａｔｅ値に取って代わられるべきであることを意味する。例えば、ｓｕｐｐｏｒｔ＝“ＵＲＩ”でｕｒｉ＿ｔｅｍｐｌａｔｅ＝“／ｓｅｒｖｅｒ／ｒｅｓｏｕｒｃｅ２．ｅｘｔ”であるならば、特定プッシュヘッダは、それ以上の処理無しで、クライアントにより提案されたリソースのためのＵＲＩが／ｓｅｒｖｅｒ／ｒｅｓｏｕｒｃｅ２．ｅｘｔ“であることを示す。
最後の任意定義パラメータは、１つまたは複数の代入値を宣言する。第１定義はｕｒｉ＿ｔｅｍｐｌａｔｅの第１変数のための１つまたは複数の代入値に対応し、第２定義は第２変数に対応する、などである。ｕｒｉ＿ｔｅｍｐｌａｔｅパラメータ（すなわち、抽出パターン）と同数の定義パラメータ（すなわち、代入値のセット）があらねばならない。
従って、このような“定義”は１つまたは複数の値および／または１つまたは複数のリストおよび／または１つまたは複数のレンジを含む：
定義＝値｜リスト｜レンジ
ここで値は、代入値を文字の列として表現する第１の可能性である；
リスト＝値｜レンジ＊（“：”値｜レンジ）は、代入値を値（または値のレンジ）のコロン分離リストとして表現する第２の可能性である。コンマ文字は慣習的に同じヘッダのための数個の値を分離するために使用されるので、コンマ文字よりもコロン文字の方が選択されていることに注意されたい。
レンジ＝“｛“スタート”−“エンド”｝”は、代入値をレンジとして表現する第３の可能性である。これは、‘スタート’と‘エンド’との間の、‘スタート’と‘エンド’との両方を含む、全ての値のリストと解釈されるべきである。これは、整数である値のためにだけ可能である。
定義パラメータの中の可変値のフォーマッティングは、デフォルトのものである。値のレンジに関するフォーマッティング問題を防止するために、レンジ内の値のフォーマッティングは、特に先行するゼロに関して、スタート値およびエンド値のフォーマッティングに従うべきである。例えば、レンジが‘｛８−１０｝’として明示されたならば、生成される値は：‘８、９、１０’である。レンジが‘｛０８−１０｝’として明示されたならば、生成される値は：‘０８、０９、１０’である。
注釈１００７と関連して上で手短に紹介されたように、特定プッシュヘッダは、２つ以上の変化部分（すなわち、変数）を有するＵＲＩテンプレートを含み得る。特定プッシュヘッダにより定義された追加リソースがサーバによりプッシュされる順序は、その２つ以上の変化部分がサーバによりどのように連続して考察されるか（すなわち拡張されるか）に直接依存する。従って、この順序は特定プッシュヘッダから推測されるべきである。
ｕｒｉ＿ｔｅｍｐｌａｔｅルールにおいて変数を拡張するための例示的アルゴリズムは、変数の順序が提供されると仮定して、次の通りである：
１．ｕｒｉ＿ｔｅｍｐｌａｔｅのリストの入手
− 第１変数拡張（提供された順序での第１）のために、特定プッシュヘッダで定義されているｕｒｉ＿ｔｅｍｐｌａｔｅが使用される。
− 次の１つまたは複数の変数拡張（提供された順序での）のために、先行する１つまたは複数の変数の拡張からもたらされるｕｒｉ＿ｔｅｍｐｌａｔｅのリストが使用される。
２．得られたリストの中の各ｕｒｉ＿ｔｅｍｐｌａｔｅは、次のようにして得られたｕｒｉ＿ｔｅｍｐｌａｔｅのリストに置き換えられる：
− 拡張ステップで考察された変数の各値のために、ｕｒｉ＿ｔｅｍｐｌａｔｅが複製され、ＵＲＩテンプレートの中の変数は代入値のうちの１つに置き換えられる。
これは、ＵＲＩの（または、ヘッダ値の）最終リストにおいて、その順序において第１の変数（例えば‘１’により定義される）が最もゆっくり変化し、その順序において最後の（すなわち、最大の数により定義される）変数が最も急速に変化するということを意味する。
例えば、構築ルール＜‘Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；｛１｝−｛２｝；ａ：ｂ；１：２’＞は次の順序リストをもたらす：
− ‘ａ−１’
− ‘ａ−２’
− ‘ｂ−１’
− ‘ｂ−２’
構築ルール＜‘ＰｕｓｈＲｅｑｕｅｓｔ：ＵＲＩ；｛２｝−｛１｝；ａ：ｂ；｛１−３｝’＞は下記の順序リストをもたらす：
− ‘ａ−１’
− ‘ｂ−１’
− ‘ａ−２’
− ‘ｂ−２’
− ‘ａ−３’
− ‘ｂ−３’
代わりに、複数の変数のための処理および置換順序は特定のオペレータとして表現され得る。ＲＦＣ６５７０は、オペレータ拡張のために幾つかの文字を確保している。一実施形態では、‘＠’文字は順序を示すために使用され得る：オペレータの値が大きいほど、処理順序は大きくなる。この代替実施形態において、上の２つの例は次のようになる：
構築ルール＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；｛ｆｏｏ＠１｝−｛ｂａｒ＠２｝；ａ：ｂ；１：２＞、“ｆｏｏ”および“ｂａｒ”は次の順序で値“ａ”および“ｂ”ならびに“１”および“２”にそれぞれ置き換えられる変数名である：
− ‘ａ−１’
− ‘ａ−２’
− ‘ｂ−１’
− ‘ｂ−２’
構築ルール＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；｛ｆｏｏ＠２｝−｛ｂａｒ＠１｝；ａ：ｂ；｛１−３｝＞は次の順序リストをもたらすであろう：
− ‘ａ−１’
− ‘ｂ−１’
− ‘ａ−２’
− ‘ｂ−２’
− ‘ａ−３’
− ‘ｂ−３’
上の例はＨＴＴＰヘッダにおいて単一の特定プッシュヘッダを用いるけれども、他の実施形態は２つ以上のプッシュヘッダを用いることができる。
例えば、クライアントが様々なタイプの数個のリソースに関心を持つときおよび／または構築ルールを設けることがあまりに困難であるとき、それは特定プッシュヘッダの複数のインスタンスを用いると決定することができる。
一例として、もしウェブページのダウンロードを加速することが求められているならば、クライアントはそのウェブページを構成するサブリソースの種類ごとに１つのプッシュヘッダを生成することができる：イメージに１つ、スタイルシートに１つ、スクリプトコードに１つ、など。
そのような状況において、各特定プッシュヘッダの値は、幾つかのタイプのサブリソースをフィルタリングするフィルタリングパラメータのように振る舞う。サブリソースが参照されるメインリソースはＨＴＴＰリクエストによって明示的に要求されたリソース（すなわち、ｒｅｑｕｅｓｔ−ＵＲＩのリソース）であり得るということに留意されたい。
プッシュヘッダの複数のインスタンスを持てばＵＲＩ／ＵＲＬの付加的なリストがもたらされ、各インスタンスが、プッシュするべきリソースの別々のセットを定義するであろう。
特定プッシュヘッダの複数のインスタンスを正当化する他の１つの場合は、クライアントが最初のリクエスト内の様々なサポートからの部分、例えばリクエスト−ＵＲＩの一部分およびレンジヘッダ内のバイトレンジ値、を改変したいとき、あるいは２つの異なるヘッダの改変を示すとき、を含む。そのような状況では、クライアントは２つ（あるいはもっと多く）の特定プッシュヘッダを、一方はＵＲＩ改変のためにおよび他方はレンジ改変のために、置くことができる。処理されたヘッダは、新しいＵＲＩと関連する新しいバイトレンジとを有する１つの複合インスタンスに帰着するであろう。
複数のプッシュヘッダに基づく複数ヘッダ改変については、各プッシュヘッダ処理は、対応する代入値に対応するＵＲＩ／ヘッダのセットを生成し、リソースの最終のリストは生成されたセットの全ての可能な組み合わせを、すなわちヘッダの各ＵＲＩ／セットのための代入値同士の全ての可能な組み合わせを設けることにより得られるということに留意するべきである。
複数の実施形態において、特定プッシュヘッダはｕｒｉ＿ｔｅｍｐｌａｔｅ仕様に代わるもののために使用され得る。
ｕｒｉ＿ｔｅｍｐｌａｔｅパラメータが相対ＵＲＩを示すとき、プッシュヘッダプロセッサは原リクエスト−ＵＲＩからの相対パスを考慮して絶対ＵＲＩを構築しなければならない。
しかし、複数の実施形態において、ベースＵＲＩまたは別のベースＵＲＩは、別の特定ヘッダにおいてまたはＰｕｓｈ−Ｒｅｑｕｅｓｔヘッダの中のパラメータとして明示され得るであろう。これは、例えば、複数のＢａｓｅＵＲＬがマニフェストにおいて宣言されるＤＡＳＨにおいて有益であり得る。それゆえ、もしクライアントが幾つかのリソースをプッシュしてもらいたければ、それは特定プッシュヘッダと共に第１ベースＵＲＬを用いて第１サーバを試験することができ、もしプッシュ約束が受け取られなければ、それは第２サーバがその特定プッシュヘッダをサポートするかどうかを試験するために次のリクエストでベースＵＲＬを変えることができる。
特定プッシュヘッダにおいてベースＵＲＩの変更を示す例示的な仕方はｕｒｉ＿ｔｅｍｐｌａｔｅパラメータの後にセットされる追加のパラメータ、“ｖａｒ＿ｂａｓｅ”、を含む。ｖａｒ＿ｂａｓｅパラメータは、新しいベースＵＲＩ値を宣言する。
例えば、ＨＴＴＰリクエストのリクエストラインが
ＧＥＴ／ｓｅｒｖｅｒ１／ｖｉｄｅｏ／ｓｅｇｍｅｎｔ−１．ｍｐ４
であるならば、特定プッシュヘッダは次のようであり得る
＜Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４；｛２−４｝；ｖａｒ＿ｂａｓｅ＝／ＡｎｏｔｈｅｒＳｅｒｖｅｒ／ｖｉｄｅｏ／＞
この構築ルールは追加リソースの次のリストを生成する：
ｈｔｔｐ：／／ＡｎｏｔｈｅｒＳｅｒｖｅｒ／ｖｉｄｅｏ／ｓｅｇｍｅｎｔ−２．ｍｐ４
ｈｔｔｐ：／／ＡｎｏｔｈｅｒＳｅｒｖｅｒ／ｖｉｄｅｏ／ｓｅｇｍｅｎｔ−３．ｍｐ４
ｈｔｔｐ：／／ＡｎｏｔｈｅｒＳｅｒｖｅｒ／ｖｉｄｅｏ／ｓｅｇｍｅｎｔ−４．ｍｐ４
あるいは、ＵＲＩ−ｔｅｍｐｌａｔｅ ＲＦＣ６５７０を用いてｕｒｉ＿ｔｅｍｐｌａｔｅパラメータを宣言する代わりに、正規表現が代わりに設けられ得る。
インタオペラビリティ目的を処理する複数の実施形態においては、特定プッシュヘッダは２つの別々のヘッダに分割される：
− 第１のものはクライアントの興味の対象であるリソースを示す。これは、上に記載された特定プッシュヘッダである；
− 第２のものは、クライアントがサーバプッシュを受け入れることをサーバに示す。これは接続セットアップ時に取り決められ得るのであるが、クライアントにとっては、プッシュされたデータをそれが何時受け入れ得るかということとプッシュをキャンセルするより大きなリスクが何時存在するか（例えばクライアントが頻繁な切り替えを伴うよく確立されていないビデオモードを経験する時）ということとをサーバに告げることは有益であろう。
この第２ヘッダは、プッシュをサポートしないネットワークインターメディアリのためにも有益であろう（例えばＣＤＮにおいて）：それらは、依然として第１プッシュヘッダをネットワークのエッジに近い何らかのリソースをプリフェッチするためのヒントとして解釈することができるであろう。
本発明の特定プッシュヘッダは、ストリーミングクライアントが様々なＤＡＳＨ状況を改善するのに役立つであろう：
− 例えば、クライアントが次のセグメントを予想したいとき；
− あるいはクライアントがビデオにおける時間オフセットを探したいとき；
− あるいは所与の期間にサーバが次のセグメントを送るとクライアントが信頼しているとき；
− あるいはクライアントが切り替えを予想しているとき；
− あるいはクライアントが関連付けられているリソースに関心を持っているとき；
− あるいはクライアントが多重化されていないオーディオ−ビデオセグメントを要求するとき。そのような場合、ビデオセグメントを要求するとき、それは対応するオーディオセグメントに対する関心を示し得る。
別の実施形態では、代入値は他の専用ヘッダ（下記の“Ｐｕｓｈ−Ｖａｌｕｅｓ”）に置かれることができ、そのときにはヘッダの下記のセット（ここでのヘッダ名は単なる例である）をもたらすであろう：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｈｅａｄｅｒ＿ｎａｍｅ“；”ｕｒｉ＿ｔｅｍｐｌａｔｅ
Ｐｕｓｈ−Ｖａｌｕｅｓ：ｄｅｆｉｎｉｔｉｏｎ［＊（“；”ｄｅｆｉｎｉｔｉｏｎ）］
この別の実施形態に関しては、下記の例８５０は次のように書き換えられるであろう：
ＧＥＴ／ｓｅｒｖｅｒ／ｖｉｄｅｏ／Ｒｅｐ−Ｒ１／ｓｅｇｍｅｎｔ−０１．ｍｐ４
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４；
Ｐｕｓｈ−Ｖａｌｕｅｓ：０２：１０
さらに、下記の例８６５は次のようになるであろう：
ＧＥＴ／ｓｅｒｖｅｒ／ｖｉｄｅｏ／Ｒｅｐ−Ｒ１／ｓｅｇｍｅｎｔ−０１．ｍｐ４
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；Ｒｅｐ−｛１｝／ｓｅｇｍｅｎｔ−｛２｝．ｍｐ４
Ｐｕｓｈ−Ｖａｌｕｅｓ：Ｒ１：Ｒ２；｛０１−０３｝
あるいは、プッシュ特定ヘッダにおいて２つ以上の変数パラメータが宣言されているとき、各変数パラメータのための代入値はそれ自身の“Ｐｕｓｈ−Ｖａｌｕｅｓ”ヘッダにおいて宣言され得る。そのような場合、“Ｐｕｓｈ−Ｖａｌｕｅｓ”ヘッダは、値もしくは値のリストもしくは値のレンジが後に続く変数パラメータ名を含むべきである。例えば：
ＧＥＴ／ｓｅｒｖｅｒ／ｖｉｄｅｏ／Ｒｅｐ−Ｒ１／ｓｅｇｍｅｎｔ−０１．ｍｐ４
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；Ｒｅｐ−｛ｖａｒ１｝／ｓｅｇｍｅｎｔ−｛ｖａｒ２｝．ｍｐ４
Ｐｕｓｈ−Ｖａｌｕｅｓ：ｖａｒ１＝Ｒ１：Ｒ２
Ｐｕｓｈ−Ｖａｌｕｅｓ：ｖａｒ２＝｛０１−０３｝
他の例示的書き換えは、上の書き換え例から容易に推測され得る。
別の代案では、図６ｂに示されているプッシュ特定ヘッダの各部分は対応する別々のヘッダ内に置かれ得る；例えば（ヘッダ名は単なる例である）：
Ｐｕｓｈ−Ｓｕｐｐｏｒｔ：ＵＲＩ
Ｐｕｓｈ−Ｐａｔｔｅｒｎ：ｓｅｇｍｅｎｔ−｛ｖａｒ｝．ｍｐ４
Ｐｕｓｈ−Ｖａｌｕｅｓ：ｖａｒ＝０２：１０
図７ａ、７ｂおよび８と関連して、つぎに、ＵＲＩテンプレートを使用するＤＡＳＨのための特定プッシュヘッダの例が記載される。
図７ａおよび７ｂは、ＤＡＳＨ標準規格を使用するＨＴＴＰを通しての適応ストリーミングの文脈における本発明の使用の例を提供する。図７ａは、各メディアセグメントをどこ（すなわちＵＲＩ）でダウンロードするべきかをストリーミングクライアントに示すＳｅｇｍｅｎｔＴｅｍｐｌａｔｅエレメント７０１を含む例としてのＭＰＤ７００である。クライアントは、希望されたまたは可能な空間解像度および帯域幅に依存して２つの代替ビデオリプリゼンテーション７０２および７０３のいずれかを選択することができる。
図７ｂは、本発明が実装されるときの、クライアントおよびサーバがＨＴＴＰ／２を用いて通信すると仮定する、クライアント−サーバのエクスチェンジを記述する。
クライアント７５０は初めにステップ７５２でＨＴＴＰ ＧＥＴリクエストを介してサーバ７５１にＭＰＤ、ストリーミングマニフェスト、を要求する。サーバはステップ７５３でＭＰＤファイルをクライアントに返すためにＨＴＴＰレスポンスを送る。
ＭＰＤを受け取ると、クライアントは、自身のメディアデコーダをセットアップするための初期化情報を特定するためにステップ７５４でそれをパースする。
次にステップ７５５で、クライアントは、この初期化セグメントを得るために別のＨＴＴＰ ＧＥＴリクエストを送る。サーバは、ＨＴＴＰレスポンスにおいて、要求された初期化セグメントファイルを提供する。これはステップ７５６である。
その間にまたは連続して（ステップ７５７）、クライアントは自身の好み／特性に応じて適切なリプリゼンテーションを特定する。このステップは、クライアントが、ビデオを読み始めるのに必要な第１メディアセグメントだけではなくてビデオを読み続けるためにダウンロードするべき次のセグメント、（もしリプリゼンテーション切り替え決定が行われなければ）普通は同じリプリゼンテーションからの後続のメディアセグメント、をも特定することを可能にする。クライアントは、この／これらの後続の１つまたは複数のセグメントのための１つまたは複数のＵＲＩを、マニフェストを用いて、推測することができる。
次にステップ７５８で、クライアントは、ビデオを表示し始めるために第１メディアセグメントをサーバに要求する。
本発明を用いて、クライアントは、リクエスト７５８に、ダウンロードするべき次のメディアセグメントのための１つまたは複数のＵＲＩを挿入する。この挿入は専用のＨＴＴＰプッシュヘッダ（例えばリクエスト７５８内の“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”ヘッダ）に行われる。この特定のＨＴＴＰヘッダのための値の例は、図８と関連して以下で提供される。
リクエスト７５８に応答して、本発明をサポートし、従って特定プッシュヘッダを理解するサーバは、自身がプッシュヘッダを理解することをクライアントに知らせることができるとともにそれ（サーバ）がクライアントへのデータのプッシュを主導することをアナウンスする。これは、サーバ開始ストリーム識別子をクライアントに提供するサーバにより送られるＰＵＳＨ ＰＲＯＭＩＳＥフレーム７５９の目的である。
サーバは、さらに、ストリーム識別子としてのＧＥＴリクエスト７５８のストリーム識別子と共に、ＧＥＴリクエストの目的である要求された第１セグメントを１つまたは複数のＤＡＴＡフレーム７６０で送る。
最後に、ステップ７５９で交換されるサーバ開始ストリーム識別子と関連して、サーバは、１つまたは複数のＤＡＴＡフレーム７６１を通して、リクエスト７５８の特定ヘッダにおいて示されているメディアセグメントに対応するデータをプッシュする。
特定の実施形態では、サーバは、クライアントからのプッシュリクエスト、すなわち特定された追加リソースをプッシュすることを求める要求、特定されたプッシュポリシー、ストラテジー、もしくはディレクティブを使用することを求めるリクエスト、または追加のリソースをプッシュしないことを求めるリクエスト、の受信を確認する。そのような確認応答はプッシュ約束メッセージのＨＴＴＰヘッダで送信され得る。それは、ＤＡＳＨレスポンスヘッダプロセッサ３８６がサーバにより用いられるプッシュポリシーをＤＡＳＨ制御エンジン３１３に知らせることを可能にする。
図１１ａから１１ｅは、サーバ１１０１がクライアント１１００から受け取られたプッシュポリシーの受信を確認して自身が適用しようとするかまたは適用できるプッシュポリシーを後者に知らせることを可能にする、サーバ１１０１およびクライアント１１００の間のプッシュポリシー管理の幾つかの例を示す。これらの例は、ＭＰＥＧ ＤＡＳＨのような、ＨＴＴＰでの適応ストリーミングに基づく（ストリーミングマニフェストに基づく方法）。
図１１ａは、ストリーミングマニフェスト（ＤＡＳＨの場合にはＭＰＤ）に対する最初のリクエスト１１０２でのプッシュポリシーの指示のクライアント１１００による送信を示す。前述のように、この指示は専用のＨＴＴＰプッシュヘッダを介して伝えられ得る。
受け取ると、サーバ１１０１はそのリクエストをステップ１１０３で処理する、すなわちサーバはクライアント１１００に提供されるべきリソース（ＭＰＤ）を特定する。次に、サーバ１１０１は、参照番号１１０２の最初のリクエストのためのリターンコードを伴う自身のレスポンスをステップ１１０４で準備する。従って、もし要求されたリソースが利用できるならば、リターンコードはＨＴＴＰコード２００である。
並行して、サーバ１１０１は、専用ＨＴＴＰプッシュヘッダに含まれるプッシュポリシー指示を処理する。もしサーバがこのヘッダを理解できて、提案されたプッシュポリシーを処理できるならば、それは、クライアントにより提案されたプッシュポリシーの受信を確認する。これは、参照番号１１０４のレスポンスに確認応答データを加えることにより、例えば参照番号１１０２のリクエストと同じポリシー値を有する同じ専用ＨＴＴＰプッシュヘッダを加えることにより、行われ得る（そのような場合、プッシュ確認応答データはプッシュポリシーデータと同じである）。
これは、クライアントに対して、提案されたプッシュポリシーをサーバが進んで使用することを示す。
従って、そのような場合、参照番号１１０４の応答でのプッシュポリシー確認の後、サーバは自身がクライアントにプッシュしようとしている追加データをアナウンスし始める。これは、例えば、ＨＴＴＰ／２からのＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを用いることにより、行われ得る（ＤＡＳＨの場合、セグメントあたりに１つのＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム）。
標準規格ベースで、サーバは、好ましくは、参照番号１１０２のリクエストでクライアントにより要求されたデータ（すなわち、ＭＰＤファイル）を自身の参照番号１１０４のレスポンスに含めるということに留意するべきである。
そのように生成された参照番号１１０４のＨＴＴＰレスポンスがステップ１１０５でクライアントに送り返されてクライアントにより処理されるのと同時に、サーバは、アナウンスされた追加データをクライアントに送るために使用されるデータストリームを準備し始める（ステップ１１０６）（通例、ＨＴＴＰ／２では、約束されたリソースあたりに１データフレーム、すなわちＤＡＳＨの場合には１セグメント）。
最後に、クライアントはステップ１１０７の間にメディアプレゼンテーションのために第１セグメントを受け取り始め、同時に参照番号１１０２のリクエストに応じて送られたＭＰＤを処理し、このようにしてネットワークトラフィックを節約し送信遅延を小さくする。
代わりに、サーバにより送られる確認応答データは例えば“ＯＫ”のような単純な値を有する別の専用ＨＴＴＰプッシュヘッダを通してシグナリングされ得るということに留意するべきである。
本発明の実施形態を実装するサーバに関しては、クライアントにより提案されたプッシュポリシーの受信を、サーバがそれをサポートしてそれを適用するときに、確認することが推薦され得る。実際、これは、クライアントにとっては、サーバにより送られたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを受け入れるか否かを容易に決定するために適切な情報である。
クライアントとサーバとの間のこの第１ラウンドトリップの後で、クライアントは、例えばステップ１１０６および１１０７の間にプッシュされたセグメントの次のセグメントに対するリクエストを用いて、メディアプレゼンテーションのストリーミングを続けるためにリクエストを提出し続ける（ステップ１１０８）。このリクエストの中で、クライアントは、前のリクエストと同じプッシュポリシー指示を有する専用ＨＴＴＰプッシュヘッダを参照番号１１０８のリクエストに加えることによって自身が同じプッシュポリシーを維持していることを確認することができる。
サーバエンドにおいて、受け取られたリクエストの処理（ステップ１１０９）は、要求されたリソースが利用し得るか否かを確認する（例えばＨＴＴＰステータスコード２００ＯＫ）とともに専用ＨＴＴＰプッシュヘッダを用いて自身が適用しているプッシュポリシーを確認するレスポンスに帰着するとともに、プッシュされるべき追加データのアナウンスおよび要求されたセグメントデータの送信に帰着する（データの実際のプッシュは表されていないがレスポンス１１０９の後に続く）。
図１１ｂはプッシュポリシー通知の確認応答の例を示し、これによりサーバはクライアントにより提案されたプッシュポリシーを自身が実行できないことをクライアントに知らせる。
クライアントにより提案されたプッシュポリシー指示をサーバがサポートしない場合、それは単にそれを無視することができる。
しかし、サーバは、自身がいかなるプッシュポリシーも使用しないとクライアントに警告するのが有益であろう。これはクライアントにとっては自身の将来のリクエストを予定するために有益な情報である。実際、クライアントは全てのセグメントを順々に要求しなければならないであろう。
その目的のために、サーバは、プッシュが行われないということを示す特定のプッシュディレクティブ、例えばタイプ“ｐｕｓｈ−ｎｏｎｅ”の、値を伴わないプッシュポリシー（または、図１２ｂで参照番号１２３１として記載されているもの）、を使用することができる。
図示されているように、第１ステップは、ストリーミングマニフェスト（ＤＡＳＨの場合にはＭＰＤ）に対する最初の要求１１１１におけるプッシュポリシーの指示のクライアント１１００による送信に向けられている。前述されたように、この指示は専用ＨＴＴＰプッシュヘッダを介して伝えられ得る。
受け取ると、サーバ１１０１は、ステップ１１１２でそのリクエストを処理する、すなわちサーバはクライアント１１００に提供されるべきリソース（ＭＰＤ）を特定する。次に、サーバ１１０１は、参照番号１１０２の最初のリクエストに対するリターンコードを伴う自身のレスポンスをステップ１１１３で準備する。従って、もしその要求されたリソースが利用できるならば、リターンコードはＨＴＴＰコード２００である。
この例ではサーバ１１０１はクライアントにより提案されたプッシュポリシーを実行できないと仮定されているので、サーバ１１０１はクライアントに対してその提案されたプッシュポリシーを使用しないことを示す。これは、図１１ｂに示されているように（参照番号１１１３）プッシュが行われないことを示す特定のプッシュディレクティブを使用することによって行われ得る。
そのような情報を受け取ると（ステップ１１１４）、クライアント１１００は全てのセグメントを１つずつステップ１１１５から要求しなければならないことを知る。
任意に、それは、自身のリクエストにおいて同じ“無プッシュ”ポリシー指示を専用ＨＴＴＰプッシュヘッダにセットすることによっても（１１１５で示されているように）、サーバからリソースがプッシュされることを自身が期待していないことを確認することができる。
次に、サーバ１１０１はステップ１１１６で受け取ったリクエストを処理し、ステップ１１１７でそのリクエストに対して、“無プッシュ”ポリシーを確認するとともにリクエストに対応するデータを送信することによって、応答する。これらの２つのステップは、ストリーミングセッションの終了まで反復される。
代わりに、サーバは、確保されている情報コード（例えば１０３、“非サポートプッシュポリシーモード”をクライアントに知らせる）を伴う別の専用ＨＴＴＰプッシュヘッダを使用することができるであろう。
なお、代わりに、クライアントは、ＨＴＴＰ Ｅｘｐｅｃｔヘッダを通して自身のプッシュポリシーを示すことができ、その場合サーバは“期待フェイル”のための４１７コードを示すか、あるいはもっと明瞭に、クライアントが希望しているプッシュモードをサーバがサポートしないことに対して専用される、確保されている４ｘｘコードを示すであろう。
別の実施形態では、本発明の実施形態を実装するクライアントは、サーバが本発明をサポートするか否かを知らない。クライアントが完全なコントロールを維持すると決定して“無プッシュ”プッシュポリシーをサーバに送っても、サーバはそのヘッダを理解しないので確認応答は送り返されない。
サーバは本発明を実装するけれどもクライアントがそれをサポートしない別の実施形態では、クライアントのリクエストで専用ＨＴＴＰプッシュヘッダを受信しないサーバは、何もプッシュされないことをクライアントに警告するために“無プッシュ”ポリシー指示を用いて確認応答をすることができる（サーバは、クライアントが本発明をサポートするか否かを知らないか、あるいは単に自身の好みを示し忘れたので）。そのようにすることにより、サーバは無用なデータを送るリスクを冒さない。
そのような特定の“無プッシュ”ポリシーの目的は、特に、下記を示すために使用され得る：
− クライアントがプッシュに関心を持っていないこと；あるいは
− クライアントが、幾つかのリクエストのためのプッシュを中断させたがっていること。
これは、サーバプッシュの使用が許されるかどうかをサーバに示すためにクライアントによって使用され得る、ＨＴＴＰ／２により定義されている既存のＳＥＴＴＩＮＧＳ＿ＥＮＡＢＬＥ＿ＰＵＳＨセッティングパラメータよりも満足のいくコントロールを提供する。このセッティングパラメータは、サーバプッシュに関してきめ細かなネゴシエーションや制御メカニズムを提供しない。実際、そのようなネゴシエーション手段を持つことはクライアントおよびサーバにとって有益であろう。例えば、ＳＥＴＴＩＮＧＳ＿ＥＮＡＢＬＥ＿ＰＵＳＨセッティングパラメータの値はサーバがサーバプッシュを使用することを可能にするけれども、クライアントはストリーミングセッションの中の幾つかのまたは全てのリクエストのためにサーバプッシュを禁止することを望み得る。例えば、これはクライアントにとっては、ビデオエレメントを埋め込むウェブページをロードするとき、有益であり得る。クライアントは、メディアセグメントではなくて、そのウェブページに関連付けられたリソース（ＣＳＳ、イメージ、ＪａｖａＳｃｒｉｐｔ）をプッシュしてもらうことに興味があるかもしれない。そのような場合、特定のＤＡＳＨコンテンツを除いてコネクション全体にわたってデータのプッシュが可能にされ、クライアントは自身がデータプッシュ無しを選択することをメディアサーバに示すであろう。
図１１ｃはプッシュポリシー通知の受け取りを確認する例を示し、この例ではクライアントはストリーミングマニフェストに対する最初のリクエストにおいて幾つかのプッシュポリシーを提案する。換言すれば、図１１ａおよび１１ｂに関連して記載されたように単一のプッシュポリシーを提案する代わりに、クライアントは自身がサポートするプッシュポリシーのリストを送信する。
図示されているように、第１ステップは、ストリーミングマニフェスト（ＤＡＳＨの場合にはＭＰＤ）に対する最初のリクエスト１１１９におけるクライアント１１００による自身がサポートするプッシュポリシーのリストの送信に向けられている。そのようなリストは好ましくは順序リストである（好みの順序、図１１ｃには表されていない）。
その目的のために、ポリシーのタイプと好みの順序のための任意のパラメータとを伝える専用ＨＴＴＰプッシュヘッダが作成される。例えば、専用ＨＴＴＰプッシュヘッダは既存のＡｃｃｅｐｔ ＨＴＴＰヘッダと同様に“Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ”ＨＴＴＰヘッダとして定義される（ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７２３１＃ｓｅｃｔｉｏｎ−５．３．２を参照）。
Ａｃｃｅｐｔヘッダは、所与のｍｅｄｉａ−ｔｙｐｅが：
０＊（ゼロまたはそれ以上）個の特定ｍｅｄｉａ−ｔｙｐｅパラメータ（例えば：ｃｈａｒｓｅｔ）；これは例えば、リクエスト：＊．ｊｐｇ、＊．ｐｎｇを発行するクライアントによりサポートされるメディアタイプのリストであり得る
０−１個の“ｑ”パラメータ（相対的重さを示すための）
０＊個の拡張パラメータ（拡張パラメータが存在するならばセパレータとして“ｑ”パラメータは必須である）
を持つことを許す。
これは専用ＨＴＴＰプッシュヘッダに関して：
Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ：＜ｕｒｎ＞［‘：’＜ｕｒｎ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍ＞＊］；ｑ＝＜Ｎ＞
に帰着し、この“ｑ”パラメータは、何らかのグローバルパラメータが存在するならば、必須である。
“ｑ”パラメータは、１つまたは複数のポリシーパラメータ、上の式の中の＜ｕｒｎ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍ＞、を、もし存在するならば、ポリシータイプ（上の式の中の＜ｕｒｎ＞により示される）から分離するＱ係数である。
Ｑ係数は、ユーザまたはユーザエージェントが、０から１のｑ値スケールを用いて、ポリシータイプおよび／またはポリシー値についての相対的優先度を示すことを可能にする。デフォルト値はｑ＝１（より大きなＱ係数または好ましいもの）である。
説明のために、クライアントは、プッシュヘッダ内の下記の通知：
Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ：ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｅｘｔ；５
を用いて、１つの要求されたセグメントに続く次の５つのセグメントをプッシュするようにサーバに求めることができ、ここで第１部分、ＵＲＮ、はプッシュディレクティブまたは使用するプッシュポリシーのタイプを一意的に特定する。‘；’セパレータの次の第２パラメータ（任意の）は、このプッシュポリシーにおいて適用するパラメータに対応する。
代わりに、ポリシータイプと値パラメータとの間の他のセパレータがＨＴＴＰヘッダ値におけるセパレータとして使用され得る（ＲＦＣ２６１６を参照）。
クライアントが自身の好みに応じたプッシュポリシーの順序リストを示すことを可能にする代替実施形態は、例えばライブシナリオにおいてサーバに幾つかの次のセグメントを、それらがサーバ上で準備状態になったならば直ちに、好ましくは３セグメント、さもなければ５セグメント、プッシュするように（図１２ｂにおいて参照番号１２３０に従って登録された標準的プッシュポリシー）サーバに示すために“ｑ”パラメータを使用することであり、次のように表現され得る：
Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ：ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｅｘｔ；３、
ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｅｘｔ；５；ｑ＝０．５
好みの順序として品質レベルを用いて、ビデオの急速スタート（すなわちＭＰＤリクエストから、初期化および第１ビデオセグメントをプッシュする）を可能にする（ここでは所有者のプッシュポリシーから。場合によっては図１２ｂの１２３０に従って登録もされる）プッシュポリシーをクライアントが示す別の例として、プッシュポリシーの順序リストが次のように表現され得る：
Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ：ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ｈｉｇｈ、
ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ｍｉｄ；ｑ＝０．７
ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ｌｏｗ；ｑ＝０．３
あるいは解像度の方を選んで：
Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ：ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ＨＤ、
ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ＳＤ；ｑ＝０．７
クライアントがサーバに種々のデータをプッシュするように示すために、それは、ｑのための同じ値を有する２つの異なるプッシュポリシーに対する指示をリクエスト内に置くことができる。これは、サーバにより、そのリクエストに応じて適用されるべき２つのポリシーと解釈されるべきである。
もしサーバが両方を適用できるならば、それは、そのクライアントの受け取りを、自身のレスポンスの中に、専用ＨＴＴＰプッシュヘッダの中に、同じｑ値を有するこれら２つのプッシュポリシーを置くことによって、確認する。
ところが、もしその２つのうちの１つだけが適用され得るならば、それは、専用ＨＴＴＰプッシュヘッダのための値として使用されるプッシュポリシーを用いてクライアントの提案を受け取ったことを確認する。
もしその２つの提案されたプッシュポリシーのいずれもが適用され得なければ、サーバは、無プッシュポリシーの識別子（例えば、登録された値１２３１、またはこの目的のために特に定義されている任意のプッシュポリシータイプ）を専用ＨＴＴＰプッシュヘッダの中に加えることによって、クライアントの提案を受け取ったことを確認する。
図１１ｃに戻って、サーバ１１０１は、ステップ１１２０において、急速スタートに向けられているかもしれない受け取ったリクエスト１１１９を処理する。
そのリクエストに応答して、サーバ１１０１は、最初のリクエストのためのリターンコードを伴う自身のレスポンスをステップ１１２１で準備する。従って、要求されたリソースが利用可能であれば、リターンコードはＨＴＴＰコード２００である。
さらに、サーバ１１０１は、場合によっては自身の好みに合うように順序を再考して同じＡｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙ専用ＨＴＴＰプッシュヘッダを用いることにより（そのような場合には、第１のものは、自身がプッシュしようとしている次のデータをアナウンスするために使用されるものである）、あるいは好ましくはリスト中の自身が使用する実際のプッシュポリシーだけを伝える別の専用ＨＴＴＰプッシュヘッダを使用することにより、クライアント１１００により提案されたプッシュポリシーのうちの１つを承認する。
例えば、そのような専用ＨＴＴＰプッシュヘッダは、“ＤＡＳＨ−ＰＵＳＨ”：ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ；ｌｏｗであり得（ここでヘッダの名前（“ＤＡＳＨ−ＰＵＳＨ”）は例として与えられている）、あるいはパラメータの正確な値を提供せずにポリシーのタイプだけ、例えば“ＤＡＳＨ−ＰＵＳＨ”：ｕｒｎ：ｃａｎｏｎ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｆａｓｔ−ｓｔａｒｔ、（この場合、サーバにプッシュするメディアのバージョンを選択させる）であり得る。
そのような確認応答データはステップ１１２２でクライアント１１００により受け取られる。
並行して、サーバ１１０１は、アナウンスされた追加データをクライアントに送るために使用されるデータストリームの準備を開始して（ステップ１１２３）、対応するデータを送る。
プッシュされたデータの受け取られた（ステップ１１２４）後にクライアント１１００により送られる次のリクエストは、再びプッシュポリシー指示、例えばサーバにより承認された好ましいもの、を含み得る。
サーバ１１０１がＭＰＤリクエストの中で受け取られた提案されているプッシュポリシーのいずれをもサポートしない場合（ステップ１１２０）、それは、専用ＨＴＴＰプッシュヘッダを“無プッシュ”ポリシーにセットすることによってクライアントの提案の受け取りを確認することができる（例えば、図１２ｂの参照番号１２３１の登録されたＵＲＮ、ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｏｎｅ、またはその目的のために特に定義されている任意のプッシュポリシータイプ、を通して）。
図１１ｄはプッシュポリシー通知の受け取りを確認する例を示し、この例ではクライアントはストリーミングマニフェストに対する最初のリクエストで“無プッシュ”ポリシーを提案する。換言すれば、図１１ｄは、クライアントが初めにリプリゼンテーション選択に関するコントロールを維持することを望んでいる場合を示す。
図示されているように、第１ステップは、ストリーミングマニフェスト（ＤＡＳＨの場合にはＭＰＤ）に対する最初のリクエスト１１３１における“無プッシュ”ポリシー指示のクライアント１１００による送信に向けられている。
従って、最初のリクエスト１１３１は、クライアントがサーバに何かをプッシュすることを望んでいないということを明らかに示す。説明のために、そのような“無プッシュ”ポリシーは、図１２ｂにおいて参照番号１２３０に登録されているように、次の通りであり得る：ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｏｎｅ。
このような例は、クライアントがセッションの初めに急速スタートに興味を持っておらず、従ってサーバからのプッシュを阻止する場合に対応する（デフォルトでは、ＨＴＴＰ／２サーバは、適切でない何かをクライアントに送る危険を伴ってプッシュを主導し得る）。
図１１ｄに示されているように、サーバ１１０１は、この無プッシュポリシーを、参照番号１１３３の自身のレスポンスで確認する。
セグメントを要求するために、クライアントは自身が何を頼もうとしているのかをより良く知るためにそのＭＰＤを分析し（ステップ１１３４）、その分析の結果として、１つまたは数個のプッシュポリシーをサーバに提案する（ステップ１１３５）。
応答して、サーバ１１０１は、約束されたデータ（表されていない）をプッシュするために図１１ａまたは図１１ｃと関連して記載されるようにプッシュポリシーを確認する。
当然に、ストリーミングセッションの急速スタートのためのプッシュポリシーは他の目的のためにも使用され得る。例えば、クライアントはＭＰＤリクエスト時にプッシュポリシーを指示し（ステップ１１３１）、次にサーバは（図１１ａまたは図１１ｃと関連して前に記載されたように）肯定的にまたは否定的に確認し、結局、第１セグメントをクライアントにプッシュすると約束する。次に、セグメントに対する連続するリクエストのために、クライアントは、自身の選んだプッシュポリシーを示すことによって自身がサーバを信頼してプッシュを続行させるか、それとも特定の“無プッシュ”ポリシーを用いることにより自身が送信に対する完全なコントロールを維持することを望むのかを決定することができる。
どんなプッシュポリシーがクライアントにより示されても、もしサーバがクライアントにより提案されたプッシュポリシーを処理できないかおよび／または対応する特定ＨＴＴＰヘッダを処理できなければ（例えば図６ａのテスト６０４がフォールスである）、それはどのような種類の確認応答も送ることができず、従ってクライアントからのヒントを単に無視するであろう、ということに留意するべきである。
反対に、クライアントにより提案されたプッシュポリシー（またはディレクティブ）を処理するように構成されてそれを適用すると決定するＤＡＳＨサーバは、自身のレスポンスにおいて容認されるパラメータ値を伴う（もしあれば）プッシュポリシー（またはディレクティブ）のＵＲＮを用いることによってクライアントのリクエストを確認するべきである。クライアントにより複数のプッシュポリシーが示されサーバがクライアントにより提案されたプッシュポリシーのリストのうちのプッシュポリシーの１つをサポートする場合、自身が使用しようとしているプッシュポリシーを、適用されるプッシュポリシーのＵＲＮを専用ＨＴＴＰプッシュヘッダ内に置くことによって、確認するべきである。
任意に、以下で説明されて図１１ｅに示されているようにサーバは自身が実行する代替プッシュポリシーのリストを種々の仕方で宣伝することもできる。
サーバがクライアントにより提案されたプッシュポリシーをサポートしない場合、それは“無プッシュ”ストラテジーのためのＵＲＬ、すなわちｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｏｎｅ、を用いてクライアントに知らせるべきである。“無プッシュ”ポリシーでの確認応答の他に、それは、自身がサポートする１つのプッシュポリシーまたはプッシュポリシーのリストを別の専用ＨＴＴＰプッシュヘッダで公表することができる。確認応答レスポンスからあいまいさを無くすために、サーバは好ましくは別の専用ＨＴＴＰプッシュヘッダを使用する。それは、自身が１つのプッシュポリシーを公表するのかそれともプッシュポリシーのリストを公表するのかにより、Ａｃｃｅｐｔ−Ｐｕｓｈ−Ｐｏｌｉｃｙヘッダにおいて与えられるシンタックスを使用することができる。
無プッシュケイパブルサーバ（すなわち、どのクライアントからのどのプッシュポリシーも理解しないサーバ。例えば図６ａのテスト６０４がフォールスである）に対してプッシュポリシーがアドレスされたときにはどんな種類の確認応答も無く、どんなプッシュポリシーの宣伝もクライアントに対してシグナリングされ得ないであろうということに留意するべきである。
クライアントがプッシュポリシーを提案するのを助けるために、サーバは、自身がサポートするプッシュポリシーのリストをクライアントに送信することができる。これは幾つかの仕方で行われ得る。
例のために、サーバによりサポートされるプッシュポリシーのリストは、ＭＰＤ内のコンテンツを作成するときに決定されることができて後者に１つまたは数個のＤＡＳＨディスクリプタとして加えられることができる。それらは、オリジンサーバによりまたはコンテンツデリバリーネットワーク（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）内のサーバによりサポートされるプッシュポリシーの指示を提供する。
これも、ネットワークインターメディアリによって、もしそれらがＤＡＳＨアウェアであるならば、行われ得る。
そのようなディスクリプタは、特定のｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ属性（例えば“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈＤｉｒｅｃｔｉｖｅ”）により特定され得る。そのようなディスクリプタのための値属性はプッシュポリシーのタイプを含む（例えば：“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｅｘｔ”または“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｏｎｅ”）。
任意に、他の属性（例えばｐａｒａｍ）は、プッシュする次のセグメントの数のようなポリシーパラメータを含み得る。これは次のように書かれるであろう：＜ＳｕｐｐｌｅｍｅｎｔａｌＰｒｏｐｅｒｔｙ ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈＤｉｒｅｃｔｉｖｅ” ｖａｌｕｅ＝“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｎｅｘｔ” ｐａｒａｍ＝“５”／＞。ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉおよび値属性のための値は、ＤＡＳＨ標準規格によりまたは少なくとも１２３０のように登録機関により定義されると想定される。これは、例えば、ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉｓを通してのＤＡＳＨ、ＤＡＳＨ産業フォーラム、あるいは対応するプッシュストラテジーを利用するクライアントおよびサーバの振る舞いに関する関連ガイドラインを有するＩＡＮＡであり得る。
別の例では、特定ＨＴＴＰヘッダフィールド、例えば“Ｓｕｐｐｏｒｔｅｄ−Ｐｕｓｈ−Ｐｏｌｉｃｉｅｓ”、が、サーバによりサポートされるプッシュポリシーを記述するために使用され得る。基本的な実装では、このヘッダフィールドの値は、サポートされるプッシュポリシーの識別子のコンマ分離リストである。
そのような特定ＨＴＴＰヘッダフィールドは、例えば、次の通りであり得る：
Ｓｕｐｐｏｒｔｅｄ−Ｐｕｓｈ−Ｐｏｌｉｃｉｅｓ：ｕｒｎ：ｄａｓｈ：ａｄｏｂｅ：ｋ−ｐｕｓｈ、ｕｒｎ：ｄａｓｈ：ｃａｎｏｎ：ｆａｓｔ−ｓｔａｒｔ
より豊かな実装では、各ポリシーのためにサポートされるパラメータ値は、“，”分離リスト、またはレンジとして記述され得るであろう。
そのような特定ＨＴＴＰヘッダフィールドは、例えば（ポリシータイプとそのパラメータとの間のセパレータとして‘；’を用いて）、次の通りであり得る：
Ｓｕｐｐｏｒｔｅｄ−Ｐｕｓｈ−Ｐｏｌｉｃｉｅｓ： ｕｒｎ：ｄａｓｈ：ａｄｏｂｅ：ｋ−ｐｕｓｈ；０−１００、ｕｒｎ：ｄａｓｈ：ｃａｎｏｎ：ｆａｓｔ−ｓｔａｒｔ；ｌｏｗ：ｍｅｄｉｕｍ
サーバは、各ポリシーのために“ｑ”パラメータを加えることにより各ポリシーに対する自身の好みを示すこともできるであろう。
そのような特定ＨＴＴＰヘッダフィールドは、例えば、次の通りであり得る：
Ｓｕｐｐｏｒｔｅｄ−Ｐｕｓｈ−Ｐｏｌｉｃｉｅｓ： ｕｒｎ：ｄａｓｈ：ａｄｏｂｅ：ｋ−ｐｕｓｈ；０−１００；ｑ＝０．４、ｕｒｎ：ｄａｓｈ：ｃａｎｏｎ：ｆａｓｔ−ｓｔａｒｔ；ｌｏｗ：ｍｅｄｉｕｍ；ｑ＝０．９
アプリケーションコードにおいて、例えばウェブページにおいて、ＨＴＭＬメタタグは、送信を改善するためにクライアントが使用し得る幾つかのポリシーをリストすることができるであろう。
そのようなＨＴＭＬメタタグは、例えば、次の通りであり得る：
＜ｍｅｔａ ｎａｍｅ＝＜＜ｄａｓｈ：ｆｄｈ：ｐｕｓｈＤｉｒｅｃｔｉｖｅ ＞＞ ｃｏｎｔｅｎｔ＝ ＜＜ ｕｒｎ：ｏｎｅ＿ｐｕｓｈ＿ｄｉｒｅｃｔｉｖｅ＿ＩＤ＞＞ ／＞
ここで名前属性に許される新しい“ｄａｓｈ：ｆｄｈ：ｐｕｓｈＤｉｒｅｃｔｉｖｅ”値は既存のエクステンションリスト：ｈｔｔｐｓ：／／ｗｉｋｉ．ｗｈａｔｗｇ．ｏｒｇ／ｗｉｋｉ／ＭｅｔａＥｘｔｅｎｓｉｏｎｓに登録され得るであろう。そのような登録は、メディア配信を最適化するストラテジーをアプリケーションサーバが考慮し、メディアが例えば＜ｖｉｄｅｏ＞エレメントとしてウェブページに埋め込まれるということをウェブクライアントが知らされることを可能にする。コンテンツ属性に置く値は、図１２ｂの参照番号１２３０の登録された値のうちの１つであり得る。
図８は、ＤＡＳＨを伴う適応ストリーミングの場合に関してプッシュヘッダの種々の例を提供する。メディア（ビデオ）は２つの別々のリプリゼンテーションＲ１ ８１０およびＲ２ ８２０として利用可能であり、その両方が時間的に整列しているビデオセグメント８１１および８２１を含む。
第１例８３０は、リプリゼンテーションＲ１の第１セグメントに対するクライアントのリクエストを示す。このリクエストは、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが将来のセグメントとしてセグメントナンバー２に関心を持っているということも示す。そのようにするために、プッシュ特定ヘッダは、サーバがｒｅｑｕｅｓｔ−ＵＲＩの中括弧入りパターン（ヘッダの第１パラメータ：“ＵＲＩ”により示される）、すなわちｒｅｑｕｅｓｔ−ＵＲＩの中の文字列“０１”、を最後のパラメータにおいて提供される値（例８３０においては“０２”）を用いて改変しなければならないことを示す。１つの代案は、Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；−＼（＼ｄ＼＋＼），−＼（％０２ｄ：＼１＋１＼）のような正規表現を介して置換ルールを示すことだったであろう。
第２例８４０は、リプリゼンテーションＲ１の第１セグメントに対するクライアントのリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが将来のセグメントとしてセグメントナンバー０２、０３、０４および０５に関心があることを示す。将来のセグメントのこのリストは、ここではコンパクト性および簡潔さを目的としてレンジとして表現されている。重ねて、中括弧同士の間のパターンは、４つのＵＲＬの対応するリストを構築するために、最初のｒｅｑｕｅｓｔ−ＵＲＩの中で、提供されたレンジでセットされている値によって繰り返し取って代わられなければならない。
第３例８５０は、リプリゼンテーションＲ１の第１セグメントに対するクライアントのリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが将来のセグメントとしてセグメントナンバー０２および１０に関心を持っていることを示す。セグメントナンバーでの関心は、クライアントがビデオを急いでブラウズすることを可能にするであろう。そのとき、代入値は、コロンで分離された値のリストとして与えられる。クライアントがもっと多くのセグメント（ナンバー０２から０４、および１０から１３）に関心を持っていた場合、これらは次のようにレンジのリストを通してシグナリングされ得たであろう：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｓｅｇｍｅｎｔ−｛１｝．ｍｐ４；｛０２−０４｝：｛１０−１３｝
第４例８６０は、リプリゼンテーションＲ１の第１セグメントに対するクライアントのリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが将来のセグメントとして、リプリゼンテーションＲ２内の、セグメントナンバー０１に関心を持っていることを示す。これは、リプリゼンテーションＲ２がベースバージョンＲ１のエンハンストバージョンであるとき、スケーラブルなビデオのために有益であり得る。この例は、ｒｅｑｕｅｓｔ−ＵＲＩに代入する２つのパターン（中括弧の間の）の存在によって示されるｒｅｑｕｅｓｔ−ＵＲＩの中の複数のパターンにおける変化を示す。
第５例８６５は、リプリゼンテーションＲ１の第１セグメントに対するクライアントのリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが、将来のセグメントとして、初めにリプリゼンテーションＲ２のセグメントナンバー０１および両方のリプリゼンテーションＲ１、および次にＲ２、のセグメント０２に、最後に両方のリプリゼンテーション“Ｒ１”および“Ｒ２”のセグメント０３に関心を持っていることを示す。これは、代入の順序を各々示す２つの（中括弧の間の）パターンの存在により示される。この例では、値“Ｒ１”および“Ｒ２”の第１のセットを有するリプリゼンテーション識別子が初めに考慮され、次に、０１から０３を含むレンジ内の値を有するセグメントインデックスが考慮される。
複数のパラメータ（２つのリプリゼンテーションのセグメント０１から０３）にわたって繰り返すという特別の場合に関しては、リプリゼンテーションＲ１の第１セグメントは２回提供される（１回は要求された第１セグメントとして−ｒｅｑｕｅｓｔ−ＵＲＩを見よ；そして１回はプッシュされるデータとして）ことに留意しなければならない。従って、サーバは、最初のｒｅｑｕｅｓｔ−ＵＲＩに対応するＵＲＬを削除するために、得られたＵＲＬのリストをフィルタリングすることができる。
第６例８７０および第７例８８０は、メディアセグメントがバイトレンジを通してアドレスされるときのヘッダの使用を示し、例えばＭＰＤにおいてはメディアセグメントはそれらのセグメントのバイトレンジを提供するＳｅｇｍｅｎｔＵＲＬｓを含むＳｅｇｍｅｎｔＢａｓｅエレメントとして記述される。
例８７０は、リプリゼンテーションＲ１の初めのバイトに対するクライアントのレンジリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが、リソースの将来の部分として、“Ｒｅｐ−Ｒ１．ｍｐ４”ファイル内の２００１バイトオフセットから始まって３０００バイトオフセットで終わるバイトレンジに関心を持っていることを示す。
第７例８８０は、リプリゼンテーションＲ１の初めのバイトに対するクライアントのレンジリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが、リソースの将来の部分として、“Ｒｅｐ−Ｒ１．ｍｐ４”ファイル内の、バイトレンジ、初めは２００１から３０００包含のバイトレンジ、次に３００１から４０００包含のバイトレンジ、のリストに関心があることを示す。
図８の第８且つ最後の例８９０は、初期化セグメントに対するクライアントのリクエストを示す。このリクエストも、プッシュヘッダ“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”を通して、クライアントが、将来のセグメントとして、所与のセグメントに関心を持っていることを示す：ここで、パターンアイデンティフィケーションも代入値も無しに、明示的で絶対的なＵＲＩが提供される。
上の記述は、主に、場合によっては構築ルールを通して、プッシュされるべき特定リソースを定義する特定プッシュヘッダに集中している。
リソースタイプをリソースフォルダにマッピングする静的設定ファイルをサーバが含む幾つかの実施形態では、クライアントは、クライアントが関心を持っているリソースをフィルタリングするために特定プッシュヘッダを使用することができる。そのようなフィルタリングは、例えば上記のステップ６０６の間に行われ得る。
このフィルタリングアプローチは、クライアントが特定プッシュヘッダにおいて特定のリソースではなくてリソースの種類を、あるいは少なくともこれらの特定リソースを特定するルールを、示すときに、有益であり得る。
例えば、図１２ａおよび１２ｂに関連して記載されたように、プッシュポリシーまたはプッシュディレクティブを明確に指定する一意識別子（例えばＵＲＮ）の使用のような、代案が存在する。
図１２ａはストリーミングマニフェスト（ＤＡＳＨの場合にはＭＰＤ）に対する最初のリクエスト１２０１でのプッシュポリシーの指示のクライアント１２００による送信を示し、その指示はそのプッシュポリシーと関連付けられた一意識別子である。前述されたように、この指示は、専用ＨＴＴＰプッシュヘッダを介して伝えられ得る。
受け取ると、サーバ１２１０はステップ１２０３でリクエストを処理する、すなわちサーバはクライアント１２００に提供されるべきリソース（ＭＰＤ）を特定する。次に、サーバ１２１０は、最初のリクエストのためのリターンコードを有する自身のレスポンスを準備する。従って、要求されたリソースが利用可能であるならば、そのリターンコードはＨＴＴＰコード２００である。
並行して、サーバ１２１０は、専用ＨＴＴＰプッシュヘッダに含まれている一意識別子の関数として提案されたプッシュポリシーを特定する。もしサーバがそのヘッダを理解することができて自身が提案されたプッシュポリシーを処理できるならば、それは次に、クライアントにより提案されたプッシュポリシーの受け取りを確認する。これは、その一意識別子をレスポンス１２０４に加えることによって行われ得る。
これは、クライアントに、サーバがその提案されたプッシュポリシーを進んで使用することを示す。
プッシュポリシーと関連付けられる一意識別子は、集中レジストリ、例えば図１２ｂに示されている集中レジストリ１２３０、において定義され得る。ＵＲＮは、プッシュポリシー（またはディレクティブ）の一意特定を可能にする。プッシュポリシー（またはディレクティブ）がパラメータを必要とするとき、これらは、プッシュポリシーが明示されるように、上のレジストリからリンクされた仕様において定義されなければならない。
集中レジストリが定義されていなければ、専用ＨＴＴＰプッシュヘッダはプッシュポリシーのタイプを伝えることができる（例えば、プッシュされるべきセグメントの数、セグメントがプッシュされているべき継続時間、またはＭＰＤアップデートをプッシュするための指示）。
説明のために、専用ＨＴＴＰプッシュヘッダで伝えられ得るプッシュポリシーのタイプは次の通りであり得る（“Ｐｕｓｈ−Ｒｅｑｕｅｓｔ”は、この例では、専用ＨＴＴＰプッシュヘッダの名前である）：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｐｕｓｈ−ｎｅｘｔ
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｐｕｓｈ−ｔｉｍｅ
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｆａｓｔ−ｓｔａｒｔ
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｍｐｄ−ｕｐｄａｔｅ
任意に、専用ＨＴＴＰプッシュヘッダは、プッシュポリシーのタイプと、提案されたプッシュポリシーのためのパラメータとを伝えることができる（例えば、セグメントの数とプッシュする継続時間（秒単位））。従って、専用ＨＴＴＰプッシュヘッダで伝えられる得るプッシュポリシーのタイプと、関連付けられているパラメータとは次の通りであり得る（ここでポリシーのタイプとパラメータとの間のセパレータとして‘；’を使用する）：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｐｕｓｈ−ｎｅｘｔ；５
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｐｕｓｈ−ｔｉｍｅ；２
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｆａｓｔ−ｓｔａｒｔ；２
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｍｐｄ−ｕｐｄａｔｅ；ｐａｔｃｈ
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｐｕｓｈ−ｎｅｘｔ；
より一般的に専用ＨＴＴＰプッシュヘッダは：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＮ＊［‘；’＜ｕｒｎ−ｓｐｅｃｉｆｉｃ−ｐａｒａｍｓ＞］
として表現され得る。
最後の例は、具体的で、所与のセグメントから全ての次のものをプッシュし続けるようにサーバに示すことを狙っている（すなわち、クライアントからサーバ主導モードへの一種の切り替え）。
少数の可能な値と関連付けられた幾つかのポリシータイプに関しては、タイプとパラメータとを１つのＵＲＮ、例えば：
ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１５：ｐｕｓｈ−ｎｅｘｔ−＊
または
ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：２０１５：ｐｕｓｈ−ｔｉｍｅ−２
として登録するのが有利であり得るということに留意するべきである。
特定の実施形態により、プッシュするデータのタイプの関数としてプッシュポリシーを提案するためにクライアントがプッシュするデータに関する自身の希望を明確に表現するオプションがクライアントに与えられる。従って、図１２ｂの集中レジストリ１２３０に示されているように、ユーザはセグメントに関連するプッシュストラテジーのためのセットと、ＭＰＤアップデートに関連するプッシュストラテジーのための別のセットとを定義することができる。
そのような実施形態は、特定ＭＰＤアップデートプッシュポリシーを持つために有益であることが判明し得、これはクライアントがアップデートプロセスを自動化するためである。実際、ＭＰＤアップデートをプッシュすることを提案し承認することは、ＭＰＤ失効日を示すために特別のメタデータボックスをメディアセグメントに加えることを回避することを可能にする（通例、ＭＰＤがアップデートされるときにサーバによって行われる）。
例えば、ストリーミングセッションの間のどこかの時点で承認されたＭＰＤアップデートのためのプッシュポリシーは、サーバがＭＰＤアップデートをプッシュすると約束しているとクライアントに知らせるであろう。
さらにさまざまな種類のＭＰＤアップデートポリシーを持てば、クライアントは、サーバがＭＰＤ全体（例えばＵＲＮ：ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｍｐｄ−ｆｕｌｌと共に）を再送するかそれともパッチだけを再送するか（ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｆｄｈ：ｐｕｓｈ−ｍｐｄ−ｐａｔｃｈ）を知らされ得るであろう。代わりに、ＭＰＤアップデートのために１つのプッシュポリシーだけが定義され得、全体モードまたはパッチモードはパラメータとなる。
図１１ａから１１ｅは、これらの２種類のプッシュポリシーの使用を示す。図１１ａから１１ｅと関連して記載されたように、クライアントは、初めにＭＰＤを要求する。その間に、それは、ＭＰＤアップデートとセグメントとの両方のプッシュに関心があるのか、それともこれらの２種類のデータのうちの一方だけに関心があるのかを示すことができる。同様に、セグメントに対するリクエストを準備するとき、それはＭＰＤアップデートとセグメントとの両方に対する関心またはこれらの２種類のデータのうちの一方だけに対する関心を示すことができる。
実際、任意の時点でＭＰＤアップデートに対する希望を示すためにセグメントに対するリクエストにおいてＭＰＤ特有ポリシーの使用が許されるべきである。同様に、ＭＰＤを要求するときにセグメント関連プッシュポリシーを使用することは、クライアントが高速開始ストリーミングセッションを持つことを可能にする。
ストリーミングアプリケーションに向けられた与えられた例は説明のためにＨＴＴＰ／２プロトコルに基づいているが、ＷｅｂＳｏｃｋｅｔなどの他の双方向プロトコルも使用され得ることに留意するべきである。特に、専用ＨＴＴＰプッシュヘッダはＷｅｂＳｏｃｋｅｔのためのバインディングにおいて次のように取って代わられ得る：
− ＵＲＬ：要求されたリソースのＵＲＬを示す。対応するＪＳＯＮパラメータは“ｕｒｌ”である。
− ＰｕｓｈＤｉｒｅｃｔｉｖｅ：クライアント選択されたＰｕｓｈＤｉｒｅｃｔｉｖｅのＵＲＮを示し、ＪＳＯＮ名“ＰｕｓｈＤｉｒｅｃｔｉｖｅ”を有する。
− ｐｕｓｈＤｉｒｅｃｔｉｖｅに特有であるとともにｐｕｓｈＤｉｒｅｃｔｉｖｅにより定義される値を示す任意のｐｕｓｈＰａｒａｍｓ。
同様に、確認応答メカニズムは、幾つかの専用ＷｅｂＳｏｃｋｅｔフレームにおいてＪＳＯＮパラメータを使用することができる。
例えば、サーバは様々なフォルダにデータをホストすることができる。そのとき、‘ｐａｔｈ’はメインリソースに到達するサーバ上のパスであると仮定して、‘ｐａｔｈ／ｉｍａｇｅ’はイメージリソースを含むであろう、‘ｐａｔｈ／ｃｏｄｅ’はコード、例えばｊａｖａｓｃｒｉｐｔコード、を含むであろう、‘ｐａｔｈ／ｓｔｙｌｅ’はｃｓｓリソースを含むであろう、等々である。このような文脈において、クライアントがウェブページで宣言されている全ての種類のイメージを望むのか（ｉｍａｇｅ／＊）それとも所与のタイプの全てのイメージを望むのか（ｉｍａｇｅ／＊．ｊｐｇ）を特定プッシュヘッダにおいて示すとき、サーバ上の設定ファイルは、どのリソースディレクトリのためにもプッシュされ得るイメージのリストをリストするべきである。
ウェブページは、リクエストのｒｅｑｕｅｓｔ−ＵＲＩにおいて要求されているデータであり得る。１つの変化形では、ウェブページは、リクエスト内の別の任意ヘッダを用いて特定され得る。
フィルタリングアプローチにより、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法を提供し、この方法は、サーバデバイスにおいて：
第１データを得るＨＴＴＰリクエストをクライアントデバイスから受け取るステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、受け取るステップ；
第１データを取り出してクライアントデバイスに送るステップ；ならびに
もし第１任意ヘッダフィールドがＨＴＴＰリクエスト内に存在するならば：
ＨＴＴＰリクエストから得られたメインリソースを用いてデータのセットを特定するステップ；
第２データのリストを得るために１つまたは複数のフィルタリングパラメータを用いて、特定されたセットの各データをフィルタリングするステップ；および
第２データをクライアントデバイスにプッシュするステップ；
を含む。
クライアントの視点からは、本発明はサーバデバイスとクライアントデバイスとの間でデータを送信する方法を提供し、この方法は、クライアントデバイスにおいて：
第１データを得るＨＴＴＰリクエストを生成するステップであって、ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、生成するステップ；
第１データを得るとともにサーバデバイスに、ＨＴＴＰリクエストから推定されるメインリソースにおいて参照される第２データを、フィルタリングパラメータに従って、プッシュさせるためにＨＴＴＰリクエストをサーバデバイスに送るステップ；
を含む。
フィルタリングアプローチとしてのプッシュ特定ヘッダの使用の幾つかの例が次に記載される。
第１の例は、クライアントが、それらのタイプに応じてプッシュされるべきサブリソースの優先順位付きリストをサーバに対して示したいときのウェブページのローディング、例えばｊｓｓおよびｃｓｓならびにその後にｈｔｍｌおよびｉｍｇをロードするためのローディング、に関連する。その、メインリソースと呼ばれるウェブリソースは、リクエストのｒｅｑｕｅｓｔ−ＵＲＩにおいて定義されている要求されたものである。特定プッシュヘッダは、次のように定義され得る：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ： ａｐｐｌｉｃａｔｉｏｎ／ｊａｖａｓｃｒｉｐｔ；ｑ＝１、ｔｅｘｔ／ｃｓｓ；ｑ＝０．８、ｔｅｘｔ／ｈｔｍｌ；ｑ＝０．７、ｉｍａｇｅ／ｐｎｇ；ｑ＝０．６、ｉｍａｇｅ／＊；ｑ＝０．４
これは、クライアントがそれらのタイプ（例えばそれらのＭＩＭＥタイプ、コンテンツタイプ、フォーマットタイプまたはコーデックタイプ）に応じてプッシュされるべきリソース（例えば、メインリソースで宣言されているサブリソース）のセットを望んでいるというサーバに対する指示である。
ここで、クライアントによる好みの相対的程度を示すＡｃｃｅｐｔヘッダの‘ｑ’パラメータと類似する仕方で‘ｑ’パラメータを使用して各リソースタイプに優先レベルが提供される。ｑ＝０は幾つかのリソースタイプをサーバによるプッシュから除外することを可能にするということに留意されたい。
この例では、優先順位‘ｑ’は、サブリソースがサーバによりプッシュされなければならないクライアントの好む順序またはバージョン（例えば、好まれる解像度に応じた）を定義することを可能にする。結果として、サーバは、プッシュされるデータの順序リストを提供するためにサブリソースをフィルタリングしなければならない。
第２の例は、ウェブページのためのイメージのローディングに関し、このときそのウェブページはリクエストのｒｅｑｕｅｓｔ−ＵＲＩにおいて定義されている要求されたデータではない。そのような状況では、特定プッシュヘッダのサポート部分は、ＨＴＴＰ“Ｒｅｆｅｒｅｒ”ヘッダを明示的に示す。これは、クライアントが望んでいる追加リソースがＲｅｆｅｒｅｒヘッダの値で示されるメインリソースのサブリソースであるという、サーバに対する指示である。任意に、下記のヘッダは、．ｐｎｇイメージフォーマットのイメージに対する優先順位を用いて、“Ｒｅｆｅｒｅｒ”ＨＴＴＰヘッダにおいて示されているウェブページの全てのイメージのローディングを行わせる：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：Ｒｅｆｅｒｅｒ；ｉｍａｇｅ／ｐｎｇ；ｑ＝０．６，ｉｍａｇｅ／＊；ｑ＝０．４
Ｒｅｆｅｒｅｒ：ｔｈｅ＿ｕｒｌ＿ｔｏ−ｗｅｂ−ｐａｇｅ
第３の例はＤＡＳＨストリーミング、特にＭＰＤローディングおよび急速スタートに関連する。プッシュヘッダは次の通りであり得、ＭＰＤはリクエストのｒｅｑｕｅｓｔ−ＵＲＩにおいて定義されている要求されたデータである：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ｖｉｄｅｏ／ｍｐ４；ｑ＝１、ｖｉｄｅｏ／ｗｅｂｍ；ｑ＝０．４
これは、“ｖｉｄｅｏ／ｗｅｂｍ”ＭＩＭＥタイプを有するセグメントではなくて“ｖｉｄｅｏ／ｍｐ４”ＭＩＭＥタイプを有するメディアセグメントからスタートするというクライアントからの好みを示す。同等の例は：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：ＵＲＩ；ｖｉｄｅｏ．｛１｝；｛ｖｉｄｅｏ／＊．ｍｐ４；ｑ＝１，ｖｉｄｅｏ／ｗｅｂｍ；ｑ＝０．４｝
を書くことであり得る。
上の例においては、メインリソース、すなわちＭＰＤ、のためのＵＲＩに基づいて、サーバは、クライアントにプッシュするｍｐ４フォーマットの全てのビデオセグメントを推論することができる。このワイルドカード代入値に関しては、例えば所与のマニフェストのための静的設定情報に基づいてあるいはＭＰＤ分析から、プッシュするセグメントのリストを決定することはサーバの義務である。
より一般的に、これは、例えばｊａｖａｓｃｒｉｐｔコードのピースまたはＣＳＳサブリソースをダウンロードするクライアントが、自身が同じリクエストのためにそれぞれそのｊａｖａｓｃｒｉｐｔコードおよびＣＳＳサブリソースにおいて参照されているサブリソースをも入手したいということをウェブページにおいて宣言するとともにサーバに対して示すときに有益であり得る。
第４の例は、ビデオストリーミング、より具体的にはバイトレンジ単位でシークすることに関連する。もしＨＴＴＰリクエストにおいてＳｅｇｍｅｎｔＢａｓｅ ＵＲＬおよびバイトレンジを用いてメディアコンテンツのサブパートが要求されるならば、その同じリクエスト内の次のプッシュヘッダは、バイトレンジ［１４００−４０００］のプッシュ、およびその後により低い優先順位でバイトレンジ［４０００−６０００］のプッシュを行わせることを可能にする：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：Ｒａｎｇｅ；｛１｝；［１４００−４０００］；ｑ＝１：［４０００−６０００］；ｑ＝０．８
第５の例は、ＤＡＳＨアプリケーションに関して、プッシュされるべきリソースのセットをメインリソース、すなわちマニフェスト、に関連するものとして記述する。これは、値“Ｒｅｆｅｒｅｒ”を有する特定プッシュヘッダのサポート部分を通して示される。パターン部分はビデオリソースのセットを示し、ワイルドカード代入値はビデオセグメントのタイプ、ここではｍｐ４、に基づくフィルタリングルールを示す：
Ｐｕｓｈ−Ｒｅｑｕｅｓｔ：Ｒｅｆｅｒｅｒ；ｖｉｄｅｏ．｛１｝；ｖｉｄｅｏ／＊．ｍｐ４
Ｒｅｆｅｒｅｒ：ｔｈｅ＿ｕｒｌ＿ｔｏ−ＭＰＤ
これは、クライアントが特定プッシュヘッダにおいてワイルドカード値を使用することを可能にする。
Ｒｅｆｅｒｅｒヘッダは、任意のものであるけれども、インテリジェントなサーバ（ＭＰＤアウェア）の場合には、それの値は、サーバがクライアントにより示されたセグメント（より一般的には（サブ−）リソース）のセットをフィルタリングするのを助けることができる。
図９は、複数の実施形態によるデバイスの略図である。このデバイスはサーバ、クライアントまたはプロキシであり得る。このデバイスは、複数の実施形態による方法を実行するために構成された制御ユニット９０１のための作業メモリとして使用され得るＲＡＭメモリ９０２を含む。例えば、制御ユニットは、ＲＯＭメモリ９０３からロードされたコンピュータプログラムの命令を実行するように構成され得る。プログラムは、ハードドライブ９０６からもロードされ得る。
デバイスは、単一のネットワークインターフェースであり得るネットワークインターフェース９０４も含み、あるいはネットワークインターフェースのセット（例えば、数個の無線インターフェース、または数タイプの有線もしくは無線インターフェース）を含む。デバイスは、ユーザに対して情報を表示するとともにユーザから入力を受け取るためのユーザインターフェース９０５を含むことができる。
デバイスは、外部デバイスからデータを受け取りおよび／または外部デバイスにデータを送るための入力／出力モジュール９０７をも含むことができる。
本発明は図面に詳しく図示されるとともに叙上において詳しく記載されているが、そのような図示および記載は例示的もしくは代表的なものであって制限的なものではないと見なされるべきであり、本発明は、開示された実施形態に限定されない。開示された実施形態に対する他の改変は、請求項に記載された発明を実施するにあたって図面、明細書および添付されている請求項の検討から、当業者に理解され実施され得る。
そのような改変は、特に、発明の概要および／または添付されている請求項において明らかにされている実施形態を組み合わせることから派生し得る。
請求項において、“含む”という語は他のエレメントやステップを除外せず、不定冠詞“ａ”もしくは“ａｎ”は複数を除外しない。単一のプロセッサまたは他のユニットは、請求項に記載されている数個のアイテムの機能を遂行することができる。互いに異なる従属請求項において様々な特徴が述べられているという単なる事実は、これらの特徴の組み合わせが有利に使用され得ないということを示すものではない。請求項における参照符号は、本発明の範囲を限定するものと見なされるべきではない。

Claims (19)

  1. サーバデバイスとクライアントデバイスとの間でデータを通信する方法であって、この方法は、前記サーバデバイスにおいて：
    第１データを得るＨＴＴＰリクエストを前記クライアントデバイスから受け取るステップであって、前記ＨＴＴＰリクエストは前記サーバデバイス上の前記第１データの特定を可能にする第１データ特定情報を含むとともに、前記ＨＴＴＰリクエストによってリクエストされる前記第１データとは異なる第２データを示す情報を含む１つまたは複数の追加のヘッダフィールドを含む、前記受け取るステップと、
    前記クライアントデバイスから受信した前記ＨＴＴＰリクエストに応答して、前記第１データを前記クライアントデバイスに送るステップと、
    前記１つまたは複数のヘッダフィールドを用いて、前記サーバデバイス上の前記第２データを決定するステップと、
    前記クライアントデバイスから受信した前記ＨＴＴＰリクエストに含まれる前記１つ又は複数の追加のヘッダフィールドを用いて決定された前記第２データを、前記クライアントデバイスにプッシュするステップと、
    を含む、方法。
  2. 前記第２データの前記プッシュをアナウンスするプッシュ約束メッセージを前記クライアントデバイスに送るステップおよび／または前記第２データを前記クライアントデバイスにプッシュするステップ、
    をさらに含む、請求項１に記載の方法。
  3. 前記第２データをプッシュする前に、前記クライアントデバイスへ確認応答データを送信するステップを更に含み、前記確認応答データは、前記クライアントデバイスへプッシュすべき前記第２データの決定に用いられる第２データ特定情報を表す、請求項１に記載の方法。
  4. 前記確認応答データは、前記第２データのプッシュに係るプッシュポリシーを表す、請求項３に記載の方法。
  5. 前記ＨＴＴＰリクエスト内の前記第２データ特定情報は、第２データをプッシュする異なる方法を示す少なくとも２つの異なるプッシュポリシーを含むリストを含む、請求項３に記載の方法。
  6. 前記確認応答データは第２データをプッシュすることに関連する前記少なくとも２つの異なるプッシュポリシーのうちの１つを含み、第２データをプッシュすることに関連する前記少なくとも２つの異なるプッシュポリシーのうちの前記の１つは、前記クライアントデバイスにプッシュされるべき前記第２データを特定するために使用される、請求項４に記載の方法。
  7. 前記第２データ特定情報は前記第２データのタイプと関連付けられ、前記データのタイプは記述データタイプまたはコンテンツデータタイプを含み、前記第２データはコンテンツデータにまたは記述データに属する、請求項３に記載の方法。
  8. 前記確認応答データは、第２データ特定情報含み、当該第２データ特定情報は、前記ＨＴＴＰリクエスト内の第２データ特定情報とは異なる、請求項３に記載の方法。
  9. 前記ＨＴＴＰリクエスト内の前記第２データ特定情報は、少なくとも１つの一意識別子を含み、前記少なくとも１つの一意識別子は、第２データをプッシュするためのディレクティブとプッシュされるべき前記第２データのアイデンティフィケーションとを表すかまたは第２データをプッシュしないためのディレクティブを表す、請求項３に記載の方法。
  10. 前記１つまたは複数の追加ヘッダフィールドは１つまたは複数の任意ヘッダフィールドである、請求項１に記載の方法。
  11. 前記ＨＴＴＰリクエストに含まれる前記第１および第２データ特定情報は、それぞれ、第１および第２のユニフォームリソースアイデンティファイア、ＵＲＩ、を含む、請求項１に記載の方法。
  12. 前記１つまたは複数の任意ヘッダフィールドは、前記ＨＴＴＰリクエストの内容から前記第２ＵＲＩを生成する少なくとも１つの構築ルールを含む、請求項１１に記載の方法。
  13. 前記１つまたは複数の任意ヘッダフィールドは変化部分情報および代入情報を含み、前記変化部分情報は参照ＵＲＩ内の少なくとも１つの変化サブパーツを特定し、前記代入情報は１つまたは複数の前記第２のＵＲＩを定義するために前記参照ＵＲＩにおいて特定される前記変化サブパーツに取って代わる少なくとも１つの代入値を含む、請求項１１に記載の方法。
  14. 前記第２データを特定するための前記第２データ特定情報は、前記クライアントデバイスからの前記ＨＴＴＰリクエストに含まれる前記一つ又は複数の追加のヘッダフィールドを使うことによって前記決定手段において決定される、請求項３に記載の方法。
  15. サーバデバイスとクライアントデバイスとの間でデータを通信する方法であって、前記方法は、クライアントデバイスにおいて：
    前記サーバデバイスへリクエストすべき第１データを特定するステップと、
    前記第１データを得るためのＨＴＴＰリクエストを生成するステップであって、前記ＨＴＴＰリクエストは、前記サーバデバイス上で前記第１データを特定するために前記サーバデバイスによって用いられる第１データ特定情報を含むとともに前記サーバデバイスがデータをプッシュするべきか否かに関する情報要素を含む１つまたは複数の追加のヘッダフィールドを含む、前記生成するステップと、
    前記第１データを得るために前記ＨＴＴＰリクエストを前記サーバデバイスに送るステップと、
    前記ＨＴＴＰリクエストを送ることに応答して、前記サーバデバイスから前記第１データを受け取るステップと、
    を含む、方法。
  16. サーバデバイスとクライアントデバイスとの間でデータを通信する方法であって、前記方法は、前記クライアントデバイスにおいて：
    第１データを得るＨＴＴＰリクエストを生成するステップであって、前記ＨＴＴＰリクエストは１つまたは複数のフィルタリングパラメータを含む第１任意ヘッダフィールドを含む、前記生成するステップと、
    前記第１データを得るとともに前記サーバデバイスに、前記ＨＴＴＰリクエストから推定されるメインリソースにおいて参照される第２データを、前記フィルタリングパラメータに従って、プッシュさせるために前記ＨＴＴＰリクエストを前記サーバデバイスに送るステップと、
    を含む、方法。
  17. 前記１つまたは複数のフィルタリングパラメータは、
    − リソースタイプを定義し；前記１つまたは複数のリソースタイプは、アプリケーションタイプ、テキストタイプ、イメージタイプ、ビデオタイプ、オーディオタイプからの１つまたは複数のタイプを含み、または
    − ＤＡＳＨメディアプレゼンテーション記述内のエレメントの識別子を用いてデータの１つまたは複数のグループを特定し、または
    − 前記第１データのサブパーツを特定する時間レンジを用いて前記第１任意ヘッダフィールドにおいて定義される、
    請求項１６記載の方法。
  18. 請求項１、１５、１６のうちのいずれか１つに記載の方法を実行するためのコンピュータプログラムの命令を記憶しているコンピュータ可読記憶媒体。
  19. 請求項１、１５、１６のうちのいずれか１つに記載の方法の各ステップを実行するようになされている手段を含むデバイス。
JP2017537233A 2015-01-28 2016-01-15 サーバデバイスによるリソースの改善されたクライアント主導型プッシュ Active JP6686029B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB1501437.6 2015-01-28
GB1501437.6A GB2534849A (en) 2015-01-28 2015-01-28 Client-driven push of resources by a server device
GB1509094.7A GB2534617A (en) 2015-01-28 2015-05-27 Improved client-driven push of resources by a server device
GB1509094.7 2015-05-27
PCT/EP2016/050713 WO2016120089A1 (en) 2015-01-28 2016-01-15 Improved client-driven push of resources by a server device

Publications (3)

Publication Number Publication Date
JP2018509679A JP2018509679A (ja) 2018-04-05
JP2018509679A5 JP2018509679A5 (ja) 2019-02-21
JP6686029B2 true JP6686029B2 (ja) 2020-04-22

Family

ID=52674078

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017537233A Active JP6686029B2 (ja) 2015-01-28 2016-01-15 サーバデバイスによるリソースの改善されたクライアント主導型プッシュ

Country Status (7)

Country Link
US (2) US10348846B2 (ja)
EP (1) EP3251322B1 (ja)
JP (1) JP6686029B2 (ja)
KR (1) KR102007105B1 (ja)
CN (1) CN107211022B (ja)
GB (3) GB2534849A (ja)
WO (1) WO2016120089A1 (ja)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2953313A1 (en) * 2014-06-05 2015-12-09 Thomson Licensing Method for operating a cache arranged along a transmission path between client terminals and at least one server, and corresponding cache
US11917002B2 (en) 2014-10-14 2024-02-27 Comcast Cable Communications, Llc Manipulation and recording of content transmissions
US11943289B2 (en) 2014-10-14 2024-03-26 Comcast Cable Communications, Llc Manipulation of content transmissions
US10880357B2 (en) * 2014-12-23 2020-12-29 Adobe Inc. Reducing requests for media segments in streaming of multimedia content
GB2534849A (en) * 2015-01-28 2016-08-10 Canon Kk Client-driven push of resources by a server device
GB2540632B (en) * 2015-07-24 2018-05-16 Canon Kk Methods, devices and computer programs for pushing data in a network environment comprising cache servers
US10158682B2 (en) 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
US10152080B2 (en) * 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
CN106604077B (zh) * 2015-10-14 2020-09-29 中兴通讯股份有限公司 自适应流媒体传输方法及装置
US20180109577A1 (en) * 2016-10-13 2018-04-19 Sharp Laboratories Of America, Inc. Systems and methods for enabling communications associated with digital media distribution
CN107959667B (zh) * 2016-10-18 2020-10-09 华为技术有限公司 一种媒体分片的推送方法、服务器及客户端
US20180176325A1 (en) * 2016-12-15 2018-06-21 Huawei Technologies Co., Ltd. Data pre-fetching in mobile networks
CN108512876B (zh) * 2017-02-27 2020-11-10 腾讯科技（深圳）有限公司 数据的推送方法及装置
US11659057B2 (en) 2017-04-19 2023-05-23 Comcast Cable Communications, Llc Methods and systems for content delivery using server push
KR102307447B1 (ko) * 2017-05-02 2021-09-30 삼성전자주식회사 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말
US11477305B2 (en) * 2017-05-03 2022-10-18 Comcast Cable Communications, Llc Local cache bandwidth matching
CA3011330A1 (en) * 2017-07-14 2019-01-14 Comcast Cable Communications, Llc Reduced content manifest size
US11622020B2 (en) * 2017-08-31 2023-04-04 Micro Focus Llc Push control
JP6950408B2 (ja) * 2017-09-28 2021-10-13 京セラドキュメントソリューションズ株式会社 情報処理システム、画像形成装置、および情報処理方法
US10461884B2 (en) * 2017-10-05 2019-10-29 Comcast Cable Communications, Llc Server selected variable bitrate streaming
GB2567665B (en) * 2017-10-19 2022-06-22 Arm Ip Ltd Asset update service
US20190141075A1 (en) * 2017-11-09 2019-05-09 Monarx, Inc. Method and system for a protection mechanism to improve server security
CN109981695B (zh) * 2017-12-27 2021-03-26 Oppo广东移动通信有限公司 内容推送方法、装置及设备
CN109063142B (zh) * 2018-08-06 2021-03-05 网宿科技股份有限公司 网页资源推送方法、服务器及存储介质
US11716264B2 (en) * 2018-08-13 2023-08-01 Cisco Technology, Inc. In situ triggered function as a service within a service mesh
CA3057118A1 (en) 2018-09-28 2020-03-28 Comcast Cable Communications, Llc Per-segment parameters for content
CN109151492B (zh) * 2018-09-29 2021-02-02 网宿科技股份有限公司 一种直播视频的快速启动方法及装置
CN109359215B (zh) * 2018-12-03 2023-08-22 江苏曲速教育科技有限公司 视频智能推送方法和系统
US11159635B2 (en) 2019-05-07 2021-10-26 Hulu, LLC Soft server push in video streaming
US11212368B2 (en) * 2019-05-17 2021-12-28 Netflix, Inc. Fire-and-forget offload mechanism for network-based services
CN110730206A (zh) * 2019-09-06 2020-01-24 浪潮金融信息技术有限公司 一种应用于新零售平台数据展示的数据服务方案
US11425187B2 (en) * 2019-09-30 2022-08-23 Tencent America Llc. Session-based information for dynamic adaptive streaming over HTTP
CN111427850A (zh) 2019-11-06 2020-07-17 杭州海康威视数字技术股份有限公司 一种显示报警文件的方法、装置及系统
CN111586100B (zh) * 2020-04-01 2022-04-22 富途网络科技(深圳)有限公司 目标对象消息发送装置及方法
CN111988235B (zh) * 2020-08-13 2023-05-09 暨南大学 一种基于多http/3连接的并行传输方法
US20220078261A1 (en) * 2020-09-10 2022-03-10 Microsoft Technology Licensing, Llc Controlling client/server interaction based upon indications of future client requests
CN112600823A (zh) * 2020-12-09 2021-04-02 上海牙木通讯技术有限公司 句柄标识解析缓存方法、查询方法及句柄标识解析系统
US11451602B2 (en) * 2021-01-06 2022-09-20 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
US11816177B2 (en) * 2021-07-21 2023-11-14 Yext, Inc. Streaming static web page generation
CN114553947B (zh) * 2022-01-29 2024-01-19 北京金堤科技有限公司 一种对消息进行处理的方法及装置
US12034789B2 (en) * 2022-04-19 2024-07-09 Tencent America LLC Extensible request signaling for adaptive streaming parameterization
CN115022280B (zh) * 2022-06-16 2023-07-14 杭州楷知科技有限公司 一种nat探测的方法、客户端及系统
CN114827633B (zh) * 2022-06-17 2022-09-13 浙江华创视讯科技有限公司 一种媒体流容灾方法、装置和相关设备
KR102663914B1 (ko) * 2022-07-13 2024-05-13 주식회사 시큐다임 전자 장치 및 이에 의한 http 트래픽의 분석 방법
US11824745B1 (en) * 2022-12-15 2023-11-21 Amazon Technologies, Inc. Reverse engineering computer network system functionality

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1599910A (zh) * 2001-12-06 2005-03-23 株式会社爱可信 用于向移动设备提供订购内容服务的系统和方法
CN1881242A (zh) * 2005-06-14 2006-12-20 张晓东 汽车行业跨企业供应链系统web应用平台
US7873710B2 (en) * 2007-02-06 2011-01-18 5O9, Inc. Contextual data communication platform
CN101350820A (zh) * 2008-08-29 2009-01-21 中兴通讯股份有限公司 一种推送业务代理网关对推送业务发起者的安全认证方法
CN101370033B (zh) * 2008-09-26 2011-09-14 成都市华为赛门铁克科技有限公司 一种推送消息的方法和设备
WO2011100901A2 (zh) * 2011-04-07 2011-08-25 华为技术有限公司 媒体内容的传输处理方法、装置与系统
GB2500229B (en) * 2012-03-14 2014-08-06 Canon Kk Method,system and server device for transmitting a digital resource in a client-server communication system
KR102020363B1 (ko) * 2012-10-31 2019-09-10 삼성전자 주식회사 적응형 스트리밍을 이용한 미디어 세그먼트 송수신 방법 및 장치
CN103036960A (zh) * 2012-12-07 2013-04-10 中国联合网络通信集团有限公司 一种信息推送方法、装置及系统
CN109842613B (zh) * 2013-07-12 2021-11-19 佳能株式会社 用于提供和接收媒体数据的方法和装置以及存储介质
GB2516112B (en) * 2013-07-12 2016-10-26 Canon Kk Methods for providing media data, method for receiving media data and corresponding devices
JP6698553B2 (ja) * 2014-02-13 2020-05-27 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ １つの要求メッセージに基づいたネットワーク・ノードへの多数のチャンクの要求
GB2534849A (en) * 2015-01-28 2016-08-10 Canon Kk Client-driven push of resources by a server device

Also Published As

Publication number Publication date
GB201602333D0 (en) 2016-03-23
WO2016120089A1 (en) 2016-08-04
US20180013845A1 (en) 2018-01-11
GB201509094D0 (en) 2015-07-08
US10348846B2 (en) 2019-07-09
JP2018509679A (ja) 2018-04-05
GB201501437D0 (en) 2015-03-11
GB2534849A (en) 2016-08-10
GB2534617A (en) 2016-08-03
EP3251322B1 (en) 2021-11-24
CN107211022A (zh) 2017-09-26
KR20170106426A (ko) 2017-09-20
EP3251322A1 (en) 2017-12-06
US20170230442A1 (en) 2017-08-10
CN107211022B (zh) 2020-10-27
KR102007105B1 (ko) 2019-08-02
GB2538832A (en) 2016-11-30
GB2538832B (en) 2019-10-09

Similar Documents

Publication Publication Date Title
JP6686029B2 (ja) サーバデバイスによるリソースの改善されたクライアント主導型プッシュ
US11375031B2 (en) Adaptive data streaming method with push messages control
JP5658820B2 (ja) Ｈｔｔｐストリーミングのためのメディアプレゼンテーション記述デルタファイル
JP2016531466A5 (ja)
US20050120091A1 (en) Method, network device and system for providing profile data applicable to hypertext transfer protocol (http)
GB2517060A (en) Adaptive data streaming method with push messages control
GB2534057A (en) Methods for providing media data, method for receiving media data and corresponding devices
GB2575189A (en) Adaptive client-driven push of resources by a server device
GB2543279A (en) Methods, devices and computer programs for optimizing use of bandwidth when pushing data in a network environment comprising cache servers
GB2551674A (en) Adaptive data streaming method with push messages control

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190108

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20191030

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191112

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200110

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: 20200303

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200401

R151 Written notification of patent or utility model registration

Ref document number: 6686029

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151