JP2018045674A - 情報処理装置及びその制御方法、コンピュータプログラム - Google Patents

Abstract

【課題】プッシュ送信に関する予約を少ないトランザクションでキャンセル可能にする技術を提供する。【解決手段】セグメントに分割されたコンテンツデータを受信装置へプッシュ送信する情報処理装置は、少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を受信装置から受信する通信手段と、通信手段によりプッシュ送信指示を受信したことに応じて、少なくとも１つのセグメントを受信装置へプッシュ送信するように通信手段を制御する制御手段とを備え、制御手段は、セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を受信装置から通信手段により受信した場合、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を停止するように通信手段を制御する。【選択図】 図６

Description

本発明は情報処理装置及びその制御方法、コンピュータプログラムに関し、特に、コンテンツのプッシュ技術に関する。

近年、音声データや映像データ等により構成されるストリーミング形式のコンテンツをユーザにリアルタイムに配信する配信システムが提供されている。このような配信システムにより、ユーザは、自身の端末装置を介して、ライブ映像等の所望のコンテンツをリアルタイムで楽しむことができる。

スマートフォンやタブレットのような端末の普及により、様々な端末装置でいつでもどこでもストリーミングコンテンツを楽しみたいという需要が高まって来ている。この要求を実現するために端末装置の能力や端末装置が置かれる通信状況に応じて、動的に取得するストリームを変更する方式（ＭＰＥＧ−ＤＡＳＨ、Ｈｔｔｐ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇなど）が注目されている。ＤＡＳＨはＤｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰの略称である。

これらの方式では映像データを細かい時間単位のセグメントに分割し、セグメントを取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）をプレイリストと呼ばれるファイルに記述する。受信装置は始めにこのプレイリストを取得し、プレイリストに記述されている情報を用いて所望の映像データを取得する。プレイリスト中に複数のバージョンの映像データセグメントに対するＵＲＬを記載することで、受信装置は、自身の処理能力や通信環境に応じて、最適なバージョンの映像データセグメントを取得することができる。

これらストリーミング方式には、送信装置からデータセグメントをＰＵＳＨ（プッシュ）送信する機能がある。ＰＵＳＨ送信は、受信装置からリクエストがなくても、リクエストの受信に先立って対応するレスポンスを送信することができるため、映像の再生遅延を軽減することができる。

特許文献１には、ＭＰＥＧ−ＤＡＳＨを利用したメディア配信において、メディアの切り替えの要求に応じて、ＰＵＳＨ送信によりメディアを配信することにより、メディアの切り替えを高速に行う構成が記載されている。

特開２０１６−１５５３４号公報

しかし、従来の構成においては、セグメントに分割されたコンテンツデータをＰＵＳＨ送信するシステムにおいて、未送信のセグメントのＰＵＳＨ送信を受信側からキャンセルする仕組みが提供されていない。そのため、従来の構成においては、ＰＵＳＨ送信キャンセルのために行う送信装置と受信装置間のトランザクションが増えてしまうという課題があった。例えば、ＰＵＳＨ送信対象のセグメントのうち一部のセグメントのＰＵＳＨ送信をキャンセルしたり、複数のＰＵＳＨ送信指示に基づきＰＵＳＨ送信が予約されている場合に特定のＰＵＳＨ予約をキャンセルしたりする様なときにトランザクションが増大していた。

本発明は上記課題に鑑みなされたものであり、プッシュ送信に関する予約を少ないトランザクションでキャンセル可能にする技術を提供することを目的とする。

上記目的を達成するため、本発明による情報処理装置は以下の構成を備える。即ち、
セグメントに分割されたコンテンツデータを受信装置へプッシュ送信する情報処理装置であって、
少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を前記受信装置から受信する通信手段と、
前記通信手段により前記プッシュ送信指示を受信したことに応じて、前記少なくとも１つのセグメントを前記受信装置へプッシュ送信するように前記通信手段を制御する制御手段と
を備え、
前記制御手段は、セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を前記受信装置から前記通信手段により受信した場合、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を停止するように前記通信手段を制御する。

本発明によれば、プッシュ送信に関する予約を少ないトランザクションでキャンセルすることが可能になる。

通信システムのシステム構成図である。 送信装置の機能構成例を示すブロック図である。 受信装置の機能構成例を示すブロック図である。 送信装置のハードウェア構成例を示すブロック図である。 受信装置のハードウェア構成例を示すブロック図である。 送信装置の動作手順を示すフローチャートである。 受信装置の動作手順を示すフローチャートである。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。 キャンセル方式の一例を表す図である。

以下に、添付の図面を参照して、本発明の実施形態について詳細に説明する。以下の実施形態において示す構成は一例にすぎず、本発明は以下に示す具体的な構成例に限定されるものではない。

（システム全体の構成）
図１は、本発明の一実施形態における通信システムの全体構成を示す図である。本実施形態に係る送信装置１０１は、ネットワーク１０３を介して、受信装置１０２と接続される。なお、送信装置１０１、受信装置１０２はそれぞれ複数存在してもよい。

送信装置１０１は、セグメントに分割されたコンテンツデータを受信装置１０２へプッシュ送信するコンテンツの送信機能を備えている。なお、セグメントには、コンテンツの再生に用いられるパラメータを記述した初期セグメント（イニシャリゼーションセグメント）と、コンテンツデータを記述したメディアセグメントがある。送信装置１０１は、さらに、ユーザからの入力を受け付ける機能を備えてもよい。送信装置１０１の具体的な例としては、カメラ装置、ビデオカメラ装置、スマートフォン装置、ＰＣ（パーソナルコンピュータ）装置、携帯電話などの情報処理装置が挙げられるが、前述の機能を備えるものであればこれに限定されない。

受信装置１０２は、コンテンツの再生・表示機能、通信機能を備え、送信装置１０１からプッシュ送信されたコンテンツデータのセグメントを受信する。受信装置１０２は、さらに、ユーザからの入力を受け付ける機能を備えてもよい。受信装置１０２の具体例は、スマートフォン装置、ＰＣ装置、テレビ、携帯電話、などの情報処理装置が挙げられるが、前述の機能構成を満たすものであればこれに限定されない。

ネットワーク１０３は、本実施形態におけるネットワークとしての有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、または無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ ＬＡＮ）である。なお、本実施形態ではネットワーク１０３として有線ＬＡＮ、または無線ＬＡＮを利用しているが、これに限らず、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などでもよい。また、ネットワーク１０３は、インターネット等の公衆通信網を経由するものでもよい。

（送信装置の機能構成）
図２は、本実施形態における送信装置の機能構成例を示すブロック図である。本実施形態の送信装置１０１は、撮像部２０１、符号化部２０２、セグメント生成部２０３、プレイリスト生成部２０４、セグメント決定部２０５、指示管理部２０６、及び、通信部２０７を有する。

撮像部２０１は、撮影対象を撮影して、映像データを取得する。符号化部２０２は、撮像部２０１により撮影した映像データを符号化する。なお、撮像部２０１及び符号化部２０２は送信装置１０１の外部にあって、符号化された映像データを送信装置１０１に提供する構成にしてもよい。また、本実施形態において、映像データは動画像だけでなく、音声を含むデータである。なお、送受信対象のコンテンツは、このような映像データだけでなく、静止画像や、テキストデータ等を含む画像、あるいは、Ｊａｖａｓｃｒｉｐｔ等の受信装置１０２において実行されるプログラムコードを含む画像でもよい。

セグメント生成部２０３は、符号化部２０２で符号化された映像データから映像データの送信単位であるセグメントを生成する。セグメントとは、映像データを空間的又は時間的に分割した映像データの単位をいう。本実施形態におけるセグメントのファイルフォーマットとしてはＩＳＯＢＭＦＦ（Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）を利用する例を説明するが、これに限らずＭＰＥＧ２ＴＳなどでもよい。プレイリスト生成部２０４は、セグメント生成部２０３が作成したセグメントへのアクセスを可能とするＵＲＬを記載したプレイリストを生成する。プレイリストのフォーマットとしてＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）がある。Ｈｔｔｐ Ｌｉｖｅｓｔｒｅａｍｉｎｇにおけるプレイリストの記述方法など、これと同等の機能を有するものでもよい。

通信部２０７は、受信装置１０２からの要求に応じて、生成されたプレイリスト及びセグメントをネットワーク１０３越しに受信装置１０２へ送信する。指示管理部（ＰＵＳＨ送信指示管理部）２０６は、通信部２０７が受信装置１０２から受信したＰＵＳＨ送信指示を保持し、またＰＵＳＨ（プッシュ）送信指示の内容をセグメント決定部２０５へ伝える。セグメント決定部（送信セグメント決定部）２０５は、通信部２０７がセグメント取得要求を受けた際に送信するセグメントを決定する。また、セグメント決定部２０５は、指示管理部２０６から受けるＰＵＳＨ送信指示の内容を元にＰＵＳＨ送信するセグメントを決定する。

（受信装置の機能構成）
図３は、本実施形態における受信装置の機能構成を示すブロック図である。本実施形態の受信装置１０２は、表示部３０１、復号化部３０２、プレイリスト解析部３０３、バッファ３０４、ユーザインタフェイス部３０５、指示管理部３０６、セグメント決定部３０７、通信部３０８を有する。

通信部３０８は、ネットワーク１０３越しに送信装置１０１からセグメント及びプレイリストを受信し、セグメントはバッファ３０４に渡し、プレイリストはプレイリスト解析部３０３へ渡す。バッファ３０４は、通信部３０８から渡されたセグメントを蓄積して、一時的に保持する。復号化部３０２は、バッファ３０４に蓄積されているセグメントを元に映像データを復号化する。表示部３０１は、ネットワーク１０３越しに送信装置１０１から受信し、復号化部３０２において復号化された映像データの再生画像を表示したり、音声を出力したりする。なお、表示部３０１は、受信装置１０２の外部にあって、受信装置１０２から映像データを受け取って表示してもよい。

プレイリスト解析部３０３は、通信部３０８から渡されたプレイリストを解析する。ユーザインタフェイス部３０５は、ユーザが操作するための画面をディスプレイ５０８に表示するなどして、ユーザからの指示を入力する。例えば、送信装置１０１から受信したプレイリストを基に取得可能な映像の一覧を表示して、ユーザからの選択を受け付けたり、再生の一時停止、キャンセル等の指示を受け付けたりする。

セグメント決定部（取得セグメント決定部）３０７は、ユーザインタフェイス部３０５からの入力に基づき、プレイリスト解析部３０３からの解析結果を元に取得するセグメントを決定する。もっとも、これに限らずネットワーク１０３の状況に応じてセグメント決定するなど、他の手法を利用してもよい。

指示管理部（ＰＵＳＨ送信指示管理部）３０６は、プレイリスト解析部３０３からの解析結果を元にＰＵＳＨ送信指示を通信部３０８を介して送信し、送信したＰＵＳＨ送信指示を管理する。指示管理部３０６はプレイリスト解析部３０３の解析結果を参照せずにＰＵＳＨ送信指示を送信してもよい。またはプレイリストの取得前にＰＵＳＨ送信指示を送信してもよい。指示管理部３０６はユーザインタフェイス部３０５からの入力に基づきＰＵＳＨ送信指示を送信するが、これに限らずネットワーク１０３の状況に応じて行うなど、他の手法を利用してもよい。

（送信装置のハードウェア構成）
図４は、本実施形態における送信装置１０１のハードウェア構成を表すブロック図である。中央処理装置（以下、ＣＰＵと称す）４０１は、装置全体を制御しデータの計算・加工を行う装置である。ＣＰＵ４０１は、後述するＲＯＭ４０２に格納されたコンピュータプログラムを後述するＲＡＭ４０３に展開して実行する。本実施形態では、ＣＰＵ４０１がコンピュータプログラムに基づき装置全体を制御することで、符号化部２０２、セグメント生成部２０３、プレイリスト生成部２０４、セグメント決定部２０５、及び、指示管理部２０６を実現する。

ＲＯＭ４０２は読出し専用メモリであり、一度書き込まれた情報を読み出すための記憶装置である。本実施形態では、ＲＯＭ４０２は、図２で示された各機能部のコンピュータプログラムを格納する。ＲＡＭ４０３は書込み可能メモリであり、一時的にデータの書き込みと読み出しを行うための記憶装置である。ＲＡＭ４０３は、各プログラムの一時的な値の記憶を行う。

内蔵メモリ４０４及び外部メモリ４０５は、アプリケーションのコンテンツを記憶しておく外部記憶装置である。内蔵メモリ４０４は、ＳＳＤ（ソリッド・ステート・ドライブ）やハードディスク等の内蔵されたストレージ装置である。外部メモリ４０５は、ＵＳＢメモリ、ＳＤメモリ等に代表されるフラッシュメモリ等の着脱可能なメモリ装置である。なお、図２の各機能を実現するためのコンピュータプログラムは、ＲＯＭ４０２ではなく、ＲＡＭ４０３、内蔵メモリ４０４、あるいは、外部メモリ４０５に記憶してもよい。

入力装置４０６はユーザからの指示を入力する装置である。入力装置４０６は、電源ボタンや音量ボタン、ホームボタンなどボタンとして実装したり、タッチパネル、キーボード、ポインティング装置等により実装したりすることができる。入力装置４０６は送信装置１０１に複数実装することができる。

ネットワークＩ／Ｆ４０７は、ネットワーク１０３を介してデータの送受信をするための装置である。ネットワークＩ／Ｆ４０７は、通信部２０７を実現した装置である。電源４０８は送信装置１０１に電源を供給・充電する装置であり、電池と充電装置を含む。なお、電源４０８は、ＡＣアダプタにより実現してもよい。カメラ４０９は送信用コンテンツを撮影する装置であり、撮像部２０１を実現した装置である。

（受信装置のハードウェア構成）
図５は、本実施形態における受信装置１０２のハードウェア構成を表すブロック図である。中央処理装置（以下、ＣＰＵと称す）５０１は、装置全体を制御しデータの計算・加工を行う装置である。後述するＲＯＭ５０２に格納されたコンピュータプログラムを後述するＲＡＭ５０３に展開して実行する。本実施形態では、ＣＰＵ５０１がコンピュータプログラムに基づき装置全体を制御することで、復号化部３０２、プレイリスト解析部３０３、指示管理部３０６、及び、セグメント決定部３０７を実現する。

ＲＯＭ５０２は読出し専用メモリであり、一度書き込まれた情報を読み出すための記憶装置である。本実施形態では、ＲＯＭ５０２は、図３で示された各機能部のコンピュータプログラムを格納する。ＲＡＭ５０３は書込み可能メモリであり、一時的にデータの書き込みと読み出すための記憶装置である。ＲＡＭ５０３は、各プログラムの一時的な値の記憶を行う。

内蔵メモリ５０４及び外部メモリ５０６は、アプリケーションのコンテンツを記憶しておく外部記憶装置である。これらの装置は、バッファ３０４を実現する。なお、バッファ３０４はＲＡＭ５０３で実現してもよい。内蔵メモリ５０４、外部メモリ５０６の具体的な装置の例は、図４を参照して説明した送信装置１０１の内蔵メモリ４０４、外部メモリ４０５と同様である。

入力装置５０５はユーザからの指示を入力する装置である。入力装置５０５は、電源ボタンや音量ボタン、ホームボタンなどボタンとして実装したり、タッチパネル、キーボード、ポインティング装置等により実装したりすることができる。入力装置５０５は受信装置１０２に複数実装することができる。入力装置５０５は、ユーザインタフェイス部３０５を実現した装置である。

スピーカー５０７及びディスプレイ５０８は、送信装置１０１から受信したコンテンツを再生する装置であり、表示部３０１を実現する。すなわち、スピーカー５０７は、受信したコンテンツに含まれる音声データを音声として出力する。ディスプレイ５０８は、受信したコンテンツに含まれる動画像データを画像として表示する。ネットワークＩ／Ｆ５０９は、ネットワークを介してデータの送受信をするための装置である。ネットワークＩ／Ｆ５０９は、通信部３０８を実現した装置である。電源５１０は受信装置１０２に電源を供給・充電する装置であり、電池と充電装置を含む。なお、電源５１０は、ＡＣアダプタにより実現してもよい。

（送信装置の処理）
図６を用いて本実施形態における送信装置１０１の処理について説明する。図６はＰＵＳＨ送信指示を受信してからＰＵＳＨ送信のキャンセルを行う迄における、本実施形態に係る送信装置１０１による処理の手順を示すフローチャートである。図６の各ステップは、ＣＰＵ４０１がコンピュータプログラムに基づき送信装置１０１を制御することにより実行される。

Ｓ６０１において、通信部２０７は、受信装置１０２からＰＵＳＨ送信指示を受信する。ここで、受信するＰＵＳＨ送信指示は一つでもよいし、複数のＰＵＳＨ送信指示を同時に受信してもよい。

Ｓ６０２において、指示管理部２０６は、受信した各ＰＵＳＨ送信指示に対し、それぞれを区別するための識別子を割り振る。この識別子は数字や文字列などでもよいし、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）の様な形でもよい。あるいは、映像や音声といったセグメントのデータの種類を表す値を識別子として用いても良い。この識別子を受信装置１０２側で既に割り振っている場合、Ｓ６０２はスキップして、受信装置１０２が割り振った識別子をそのまま使用してよい。また、セグメントのデータの種類を識別子として使用する場合も新たに識別子を割り振る必要が無いためＳ６０２はスキップしてよい。また、ＰＵＳＨ送信指示を識別子以外で区別する場合もＳ６０２をスキップしてよい。ＰＵＳＨ送信指示は、識別子以外に、ＰＵＳＨ送信指示を受信装置１０２が送信した時刻や、後述するＳ６０３において送信装置１０１がＰＵＳＨ送信指示に対する応答を送信した時刻により区別してもよい。または受信装置１０２がＰＵＳＨ送信指示と合わせて、取得を行ったリソースにより区別してもよい。例えば、ＨＴＴＰ／２において、リソースとはＰＵＳＨ指示を出した際にＧＥＴしたセグメント名などである。また、これら以外にもＰＵＳＨ送信指示を区別して管理できる方法で実施してもよい。

Ｓ６０３において、通信部２０７は、ＰＵＳＨ送信指示に対する応答を送信する。Ｓ６０２を実施している場合や受信装置１０２がＰＵＳＨ送信指示に識別子を割り振っている場合、つまり識別子によりＰＵＳＨ送信指示を区別する場合は応答に識別子を含めて送信する。識別子以外でＰＵＳＨ送信指示を区別する場合は、通信部２０７はＰＵＳＨ送信指示を区別するために必要な値を応答に含めて送信する。各値を応答に含める代わりに、プレイリスト生成部２０４がＭＰＤに各値を記載することにより受信装置１０２へ通知してもよい。

Ｓ６０４において、指示管理部２０６は、受信したＰＵＳＨ送信指示を保持しておく。識別子でＰＵＳＨ送信指示を区別する場合、ＰＵＳＨ送信指示と識別子を紐づけて保持する。セグメントのデータの種類を識別子として使用する際、セグメント名からデータの種類が分かる場合などでは、Ｓ６０４はスキップしても良い。識別子以外でＰＵＳＨ送信指示を区別する場合は、ＰＵＳＨ送信指示を区別するための値と紐づけてＰＵＳＨ送信指示を保持する。

Ｓ６０５において、セグメント決定部２０５は、受信したＰＵＳＨ送信指示の内容を元にＰＵＳＨ送信するセグメントを決定し、決定したセグメントのリストを指示管理部２０６へ通知する。その後、通信部２０７は、対象のセグメントをＰＵＳＨ送信する。ライブ配信時の場合は、ＰＵＳＨ対象のセグメントのうち、生成完了したものからＰＵＳＨ送信していく。なお、Ｓ６０３、Ｓ６０４及びＳ６０５は本フローチャートと異なる順番で実施してもよい。

Ｓ６０６において、通信部２０７は、ＰＵＳＨ送信キャンセル指示を受信装置１０２から受信する。ここで受信するＰＵＳＨ送信キャンセル指示は一つのＰＵＳＨ送信指示を対象にしたものでもよいし、複数のＰＵＳＨ送信指示を対象にしたものでもよい。またＰＵＳＨ送信キャンセル指示は、ＰＵＳＨ送信指示によりＰＵＳＨする予定の全てのセグメントのキャンセルを指示する内容でもよいし、ＰＵＳＨ送信指示によりＰＵＳＨするセグメントのうち一部のセグメントのみのキャンセルを指示する内容でもよい。

次に、ＰＵＳＨキャンセル対象であるＰＵＳＨ送信指示が一つの場合、そのＰＵＳＨ送信指示に基づきＰＵＳＨ送信すべきセグメントのうち、キャンセル候補となるセグメント毎にＳ６０７から６１０処理を順に行う。キャンセル候補についてはＳ６０７の説明にて後述する。またＰＵＳＨキャンセル対象のＰＵＳＨ送信指示が複数の場合、ＰＵＳＨ送信指示毎にＳ６０７から６１１の処理を行う。例えば、ＰＵＳＨ送信キャンセル指示の対象がＰＵＳＨ送信指示Ａ及びＢであり、ＰＵＳＨ送信指示Ａのキャンセル候補セグメントは二つ、Ｂのキャンセル候補セグメントはと三つとする。この場合、まず対象のＰＵＳＨ送信指示の一つであるＡについてＳ６０７から６１１を実行する。その際、キャンセル候補セグメントの数である二回分Ｓ６０７から６１０を順に行う。その後、もう一つのキャンセル対象であるＰＵＳＨ送信指示ＢについてＳ６０７から６１１を実行する。その際キャンセル候補セグメントの数である三回分Ｓ６０７から６１０を順に行う。Ｓ６０７から６１０の処理は、キャンセル対象のＰＵＳＨ送信指示毎に各セグメントに対する処理を並列に行ってもよい。

Ｓ６０７において、指示管理部２０６は、ＰＵＳＨ送信キャンセル指示が対象としているＰＵＳＨ送信指示のうち、一つのＰＵＳＨ送信指示によりＰＵＳＨするセグメントの中からキャンセル候補となるセグメントを一つ特定する。例えば、あるＰＵＳＨ送信指示によりｓｅｇｍｅｎｔ１、ｓｅｇｍｅｎｔ２、ｓｅｇｍｅｎｔ３についてＰＵＳＨ送信することになっているとする。そして、ＰＵＳＨ送信キャンセル指示が全てのセグメントをキャンセルするよう求めてきたとする。この場合、キャンセル候補のセグメントはｓｅｇｍｅｎｔ１、ｓｅｇｍｅｎｔ２、ｓｅｇｍｅｎｔ３の三つ全てであり、Ｓ６０７で指示管理部２０６はその中の一つ（例えば、ｓｅｇｍｅｎｔ１）を選択する。一方でＰＵＳＨ送信キャンセル指示が最後一つのセグメントのみの場合、キャンセル候補のセグメントはｓｅｇｍｅｎｔ３のみであり、必然的にｓｅｇｍｅｎｔ３を選択する。なお、複数のセグメントを対象としてＰＵＳＨ送信キャンセルが指示された場合に、その一部のセグメントが既に送信済みであるか送信キャンセル済みのときは、それらのセグメントを除いたセグメントをキャンセル候補のセグメントとする。例えば、ＰＵＳＨ送信キャンセルの対象がｓｅｇｍｅｎｔ１〜ｓｅｇｍｅｎｔ３の三つの場合で、ｓｅｇｍｅｎｔ１が送信済みで、ｓｅｇｍｅｎｔ２が送信キャンセル済みの場合は、ｓｅｇｍｅｎｔ３のみをＰＵＳＨ送信キャンセルの候補とする。

Ｓ６０８により、Ｓ６０７で特定したキャンセル候補のセグメントが、他のＰＵＳＨ送信指示によるＰＵＳＨ送信対象になっていないことを確認する。例えば、あるＰＵＳＨ送信指示（以下、「指示１」と称する）によりｓｅｇｍｅｎｔ１、ｓｅｇｍｅｎｔ２、ｓｅｇｍｅｎｔ３をＰＵＳＨ送信することになっているとする。また、指示１において、ＰＵＳＨ送信キャンセル指示によるキャンセル候補のセグメントの一つがｓｅｇｍｅｎｔ３であるとする。一方で、別のＰＵＳＨ送信指示（以下、「指示２」と称する）によるＰＵＳＨ送信予定セグメントがｓｅｇｍｅｎｔ３、ｓｅｇｍｅｎｔ４となっているとする。この場合、ｓｅｇｍｅｎｔ３が指示２によりＰＵＳＨ送信予定になっているため、指示１の処理においてｓｅｇｍｅｎｔ３のＰＵＳＨ送信はキャンセルしてはいけないということになる。なお、キャンセル対象のＰＵＳＨ送信指示以外に別のＰＵＳＨ送信指示が受信装置１０２から指示されていない場合、Ｓ６０８はスキップしＳ６０９へ遷移してもよい。

Ｓ６０８にて、Ｓ６０７で特定したキャンセル候補のセグメントが、他のＰＵＳＨ送信指示によるＰＵＳＨ送信対象になっていないと判定した場合（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。Ｓ６０８にて、Ｓ６０７で特定したキャンセル候補のセグメントが、他のＰＵＳＨ送信指示によるＰＵＳＨ送信対象になっていると判定した場合（Ｓ６０８でＹＥＳ）、Ｓ６１０へ遷移する。

Ｓ６０９において、指示管理部２０６は、セグメント決定部２０５へキャンセル候補のセグメントのＰＵＳＨ送信をキャンセルするよう指示を出す。それに応じて、セグメント決定部２０５は、キャンセル候補セグメントのＰＵＳＨ送信をキャンセルする。

Ｓ６０８からＳ６０９のキャンセル可能かのチェック及びキャンセル処理は、一つのＰＵＳＨ送信指示によりＰＵＳＨ送信するセグメントの中で、全てのキャンセル候補セグメントに対し行う。そこで、Ｓ６１０にて、処理対象の一つのＰＵＳＨ送信指示についての全てのキャンセル候補のセグメントについて、Ｓ６０８からＳ６０９の処理によりキャンセル可能かを確認したか否かを判定する。全てのキャンセル候補セグメントに対しＳ６０８からＳ６０９を行ったと判定した場合（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。Ｓ６１０にて、全てのキャンセル候補セグメントに対しＳ６０８からＳ６０９を行っていないと判定した場合（Ｓ６１０でＮＯ）、Ｓ６０７へ遷移して、処理を行っていないキャンセル候補セグメントに対して前述のキャンセル処理を行う。

Ｓ６０７からＳ６１０の処理は、一つのＰＵＳＨ送信指示によりＰＵＳＨ送信するセグメントのうち、一つのキャンセル候補セグメントごとに実施する。なおＳ６０７は最初に全てのキャンセル候補セグメントを特定し、その後特定したキャンセル候補セグメント毎にＳ６０８からＳ６１０を実施してもよい。

Ｓ６１１では、ＰＵＳＨ送信のキャンセルを指示しているすべてのＰＵＳＨ送信指示についてＳ６０７からＳ６１０の処理を行ったか否かを判定する。キャンセル対象になっている全てのＰＵＳＨ送信指示についてＳ６０７からＳ６１０のキャンセル処理を行ったと判定した場合（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。全てのＰＵＳＨ送信指示についてＳ６０７からＳ６１０のキャンセル処理を行っていない判定した場合（Ｓ６１１でＮＯ）、Ｓ６０７へ遷移して、未処理のＰＵＳＨ送信指示について前述のキャンセル処理を行う。

Ｓ６０７からＳ６１１のキャンセル方法は、本説明に記載した方法に限定されない。例えば、セグメントが別のＰＵＳＨ送信指示からのＰＵＳＨ送信対象になっているかに関わらず、あるＰＵＳＨ送信指示のキャンセル候補になった時点で、そのセグメントのＰＵＳＨ送信をキャンセルをするなど、別の方法を用いてもよい。

Ｓ６１２にて、通信部２０７はＰＵＳＨ送信キャンセル指示に対する応答を受信装置１０２へ送信する。

（受信装置の処理）
図７を用いて本実施形態における受信装置１０２の処理について説明する。図７はＰＵＳＨ送信指示の送信を行い、その後ＰＵＳＨ送信のキャンセルを行う迄における、本実施形態に係る受信装置１０２による処理の手順を示すフローチャートである。図７の各ステップは、ＣＰＵ５０１がコンピュータプログラムに基づき受信装置１０２を制御することにより実行される。

Ｓ７０１において、指示管理部３０６は、送信しようとする各ＰＵＳＨ送信指示に対し、それぞれを区別するための識別子を割り振る。この識別子は数字や文字列などでもよいし、ＵＲＬの様な形でもよい。あるいは、映像や音声といったセグメントのデータの種類を表す値を識別子として用いても良い。セグメントのデータの種類を識別子として使用する際、セグメント名からデータの種類が分かる場合などでは、Ｓ７０１はスキップしても良い。この識別子は送信装置１０１が割り振ることもでき、その場合Ｓ７０１はスキップしてよい。またＰＵＳＨ送信指示を識別子以外で区別する場合もＳ７０１をスキップしてよい。

Ｓ７０２において、通信部３０８は、ＰＵＳＨ送信指示を送信装置１０１へ送信する。ここで送信するＰＵＳＨ送信指示は一つでもよいし、複数のＰＵＳＨ送信指示を同時に送信してもよい。Ｓ７０１にて識別子を振っている場合は、各ＰＵＳＨ送信指示に識別子を含めて送信する。

Ｓ７０３において、通信部３０８は、ＰＵＳＨ送信指示に対する送信装置１０１からの応答を受信する。この応答は、図６のＳ６０３のステップにより送信装置１０１から送信される。

Ｓ７０４にて、指示管理部３０６は、送信装置１０１から受信したＰＵＳＨ送信指示の応答を保持しておく。

Ｓ７０５において、通信部３０８は送信装置１０１からＰＵＳＨ送信されるセグメントを受信する。受信したセグメントはバッファ３０４に蓄積され、復号化部３０２において復号されて、表示部３０１により表示・出力される。

Ｓ７０６において、通信部３０８はＰＵＳＨ送信キャンセル指示を送信する。Ｓ７０５にてＰＵＳＨ送信セグメントを受信する前に本ステップを実行してもよい。送信するＰＵＳＨ送信キャンセル指示の対象は、一つのＰＵＳＨ送信指示でもよいし、複数のＰＵＳＨ送信指示を対象にしたものでもよい。また、ＰＵＳＨ送信キャンセル指示は、ＰＵＳＨ送信指示によりＰＵＳＨされる予定の全てのセグメントのキャンセルを指示する内容でもよい。あるいは、ＰＵＳＨ送信指示によりＰＵＳＨされるセグメントのうち一部のセグメントのみのキャンセルを指示する内容でもよい。

Ｓ７０７において、通信部３０８はＰＵＳＨ送信キャンセル指示に対する応答を受信する。この応答は、図６のＳ６１２のステップにより送信装置１０１から送信される。

上記のように、送信装置１０１は、少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を受信装置１０２から受信すると、それに応じて、各セグメントを受信装置１０２へプッシュ送信するように制御する。ここで、送信装置１０１は、セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を受信装置１０２から受信した場合、指定されたプッシュ送信指示に基づく未送信のセグメントのプッシュ送信を停止する。このように本実施形態では、プッシュ送信指示を指定してプッシュ送信をキャンセルすることで、ＨＴＴＰ／２やＷｅｂＳｏｃｋｅｔなどの利用する通信プロトコルにかかわらず、最小限のトランザクション回数でプッシュ送信をキャンセルすることが可能である。

前述のように、プッシュ送信指示の指定は、例えば、プッシュ送信指示の識別子や、あるいは、プッシュ送信指示の内容と、受信装置１０２により要求されたリソース又はプッシュ送信指示の送受信に関する時刻との組み合わせにより行うことができる。また、送信装置１０１が、受信したキャンセル指示の内容に応じて、未送信のセグメントの全て又は一部のプッシュ送信を停止することで、受信装置１０２は、所望のセグメントの送信を事後的にキャンセルすることができる。

また、送信装置１０１は、複数のプッシュ送信指示を受信してセグメントをプッシュ送信している場合に、あるプッシュ送信指示についてキャンセル指示を受信したときは、Ｓ６０８において、他のプッシュ送信指示の送信対象はキャンセル対象から除外する。すなわち、キャンセル指示に指定されたプッシュ送信指示に基づく未送信のセグメントの全ての送信を停止するのではなく、他のプッシュ送信指示に基づく未送信のセグメントに含まれないセグメントについてのみ送信を停止する。したがって、受信装置１０２のユーザが意図しないセグメントのプッシュ配信をキャンセルすることを防ぐことができる。

（動作例１）
ＨＴＴＰ／２上で、ＵＲＬ形式の識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定全てのセグメントをキャンセルする例について、図８を参照して説明する。図８は送信装置１０１−受信装置１０２間でやり取りされるリクエスト、レスポンスメッセージの例を示す概略図である。ここでは、受信装置１０２から送信装置１０１へ送信するデータをリクエスト、送信装置１０１から受信装置１０２へ送信するデータをレスポンスと称する。図の左側上部のメッセージから左側下部のメッセージへ順にやり取りが行われ、次に右上部のメッセージから右下部のメッセージがやり取りされる。つまり、リクエスト８０１から、８０３、８０６、８０７、８０８、８０９、８１１、８１３の順でやり取りされる。以降の図９〜図１７Ｂも同様の構成となる。ここでは、識別子は送信装置１０１が割り振るものとしてＳ７０１はスキップする。

Ｓ７０２により、受信装置１０２の通信部３０８は、送信装置１０１へＰＵＳＨ送信指示８０２をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト８０１を送信する。リクエスト８０１はｓｅｇｍｅｎｔＡ１というセグメントをリクエストする内容を有する。リクエスト８０１はさらに、ｓｅｇｍｅｎｔＡ１から再生時間的に連続する次の五つのセグメントｓｅｇｍｅｎｔＡ２〜ｓｅｇｍｅｎｔＡ６をＰＵＳＨ送信するようＰＵＳＨ送信指示８０２で指示している。８０２において、”ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｎｅｘｔ”に続く数字”５”は、”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”に続いて取得するセグメントの個数を指定したものである。Ｓ６０１により、送信装置１０１の通信部２０７はＰＵＳＨ送信指示８０２を含むリクエスト８０１を受信する。

Ｓ６０２により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示８０２に対し”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ１”という識別子８０５を割り振る。識別子はＵＲＬの形式を採用している。

Ｓ６０３により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示８０２に対する応答として、ＰＵＳＨ送信指示８０２と同内容のＰＵＳＨ送信指示の応答８０４をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス８０３を受信装置１０２へ送信する。レスポンス８０３のｐｕｓｈ−ｐｏｌｉｃｙヘッダーには、ＰＵＳＨ送信指示の応答８０４と対応させて識別子８０５も含める。識別子８０５の前に”ｐｕｓｈ−ＵＲＬ”というプレフィックスを入れることで、ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのどこからが識別子８０５なのかを分かるようにしている。このプレフィックスは”ｐｕｓｈ−ＵＲＬ”に限定しない。識別子８０５をＰＵＳＨ送信指示の応答８０４と共に送信する代わりに、送信装置１０１はＭＰＤに識別子８０５を記載し受信装置１０２へ通知してもよい。

レスポンス８０３送信後、送信装置１０１はＨＴＴＰ／２における、ＰＵＳＨ送信予定のｓｅｇｍｅｎｔＡ２とｓｅｇｍｅｎｔＡ３について、それぞれどのｓｔｒｅａｍで送信するかを予約するためのＰＵＳＨ＿ＰＲＯＭＩＳＥ８０６及び８０７を送信する。これに応じて、受信装置１０２はこれを受信する。図８の例では、ｓｅｇｍｅｎｔＡ２に対してＳｔｒｅａｍ ＩＤ＝２のｓｔｒｅａｍが予約され、ｓｅｇｍｅｎｔＡ３に対してＳｔｒｅａｍ ＩＤ＝４のｓｔｒｅａｍが予約されている。なお、ＰＵＳＨ＿ＰＲＯＭＩＳＥ８０６及び８０７はレスポンス８０３の前にやり取りしてもよい。ｓｅｇｍｅｎｔＡ３以降のセグメント（ｓｅｇｍｅｎｔＡ４、ｓｅｇｍｅｎｔＡ５、ｓｅｇｍｅｎｔＡ６）に対応するＰＵＳＨ＿ＰＲＯＭＩＳＥは送信しないものとする。ＨＴＴＰ／２の場合、例えば該当のセグメントの生成が完了していない場合や、同時に送信予約できる上限数に達している場合にＰＵＳＨ＿ＰＲＯＭＩＳＥを送信しない。このような場合以外にも、ＰＵＳＨ＿ＰＲＯＭＩＳＥを送信しないようにしてもよい。

Ｓ６０４により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示８０２と識別子８０５を紐づけて保持する。

Ｓ７０３により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示８０２の応答８０４とｓｅｇｍｅｎｔＡ１のバイナリデータを含むレスポンス８０３を受信する。さらに、Ｓ７０４により、受信装置１０２の指示管理部３０６は、送信装置１０１により受理されたＰＵＳＨ送信指示８０２を識別子８０５と紐づけて保持する。

Ｓ６０５により、送信装置１０１は、ＰＵＳＨ送信を開始し、ｓｅｇｍｅｎｔＡ２のＰＵＳＨ送信として、送信装置１０１の通信部２０７はレスポンス８０８を受信装置１０２へ送信する。本実施形態では、セグメントの名称末尾の数値が連続している場合、再生時間的に連続しているものとする。例えば、ｓｅｇｍｅｎｔＡ２とｓｅｇｍｅｎｔＡ３とは再生時間が連続しており、ｓｅｇｍｅｎｔＡ２の末尾の映像がｓｅｇｍｅｎｔＡ３の冒頭の映像に連続する関係にある。

Ｓ７０５により、受信装置１０２の通信部３０８は、ｓｅｇｍｅｎｔＡ２のバイナリデータを含むレスポンス８０８を受信する。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示８１０をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト８０９を送信する。ＰＵＳＨ送信キャンセル指示８１０は、ＰＵＳＨ送信指示８０２によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルする内容を有する。リクエスト８０９のｐａｔｈヘッダーに識別子８０５を指定することでキャンセルしたいＰＵＳＨ送信指示８０２を指定する。識別子８０５は、ｐａｔｈヘッダーに含める代わりに、”ｐｕｓｈ−ＵＲＬ”というプレフィックスと共にａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含めてもよい。このプレフィックスは”ｐｕｓｈ−ＵＲＬ”に限定しない。

Ｓ６０６により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示８１０を含むリクエスト８０９を受信する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は、識別子８０５から判定したキャンセル対象であるＰＵＳＨ送信指示８０２によるＰＵＳＨ送信予定のセグメントで、ｓｅｇｍｅｎｔＡ３をキャンセル候補セグメントと特定する。図８の例では、ＰＵＳＨ送信指示８０２によりｓｅｇｍｅｎｔＡ２〜ｓｅｇｍｅｎｔＡ６のＰＵＳＨ送信が要求されている。ここでは、ｓｅｇｍｅｎｔＡ２は送信済みのため（８０８）、未送信のセグメントのうち最も通し番号が小さいｓｅｇｍｅｎｔＡ３をキャンセル候補として特定している。

送信装置１０１においてＰＵＳＨ送信指示８０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップし、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ８０７による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ８１３の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示８１０によるＰＵＳＨ送信指示８０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定し（Ｓ６１０でＮＯ）、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は、識別子８０５から判定したキャンセル対象であるＰＵＳＨ送信指示８０２によるＰＵＳＨ送信予定のセグメントで、ｓｅｇｍｅｎｔＡ４をキャンセル候補セグメントと特定する。

送信装置１０１においてＰＵＳＨ送信指示８０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップし、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ４のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ４のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、送信装置１０１内部でＰＵＳＨ送信を停止する処理のみを行う。ｓｅｇｍｅｎｔＡ４の送信予約は行っていないため、送信装置１０１内部の停止処理のみでよい。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示８１０によるＰＵＳＨ送信指示８０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定し（Ｓ６１０でＮＯ）、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は、識別子８０５から判定したキャンセル対象であるＰＵＳＨ送信指示８０２によるＰＵＳＨ送信予定のセグメントで、ｓｅｇｍｅｎｔＡ５をキャンセル候補セグメントと特定する。

送信装置１０１においてＰＵＳＨ送信指示８０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップし、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ５のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ５のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、送信装置１０１内部でＰＵＳＨ送信を停止する処理のみを行う。ｓｅｇｍｅｎｔＡ５の送信予約は行っていないため、送信装置１０１内部の停止処理のみでよい。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示８１０によるＰＵＳＨ送信指示８０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定し（Ｓ６１０でＮＯ）、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は、識別子８０５から判定したキャンセル対象であるＰＵＳＨ送信指示８０２によるＰＵＳＨ送信予定のセグメントで、ｓｅｇｍｅｎｔＡ６をキャンセル候補セグメントと特定する。

送信装置１０１においてＰＵＳＨ送信指示８０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップしＳ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ６のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ６のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、送信装置１０１内部でＰＵＳＨ送信を停止する処理のみを行う。ｓｅｇｍｅｎｔＡ６の送信予約は行っていないため、送信装置１０１内部の停止処理のみでよい。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示８１０によるＰＵＳＨ送信指示８０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は８０２のみであるため（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示８１０に対する応答８１２をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス８１１を受信装置１０２へ送信する。この応答は、ＰＵＳＨ送信キャンセル指示８１０と同じ内容を有する。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示の応答８１２を含むレスポンス８１１を受信する。

キャンセルされたｓｅｇｍｅｎｔＡ３に対して送信装置１０１は受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ８０７を送信しているため、これをキャンセルするためにＲＳＴ＿ＳＴＲＥＡＭ８１３を送信し受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ８１３はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

なお、ＨＴＴＰ２では、複数のｐｕｓｈ−ｐｏｌｉｃｙのうちの一部や、ｐｕｓｈ−ｐｏｌｉｃｙに基づくＰＵＳＨ予定の複数のセグメントの一部をキャンセルするために、全てのＰＵＳＨを一度キャンセルしてから再度必要な設定する必要がある。ＨＴＴＰ２では、ＰＵＳＨ対象のセグメントごとにＰＵＳＨ＿ＰＲＯＭＩＳＥによりストリームのＩＤが通知され、それを指定することで任意のセグメントのＰＵＳＨをキャンセルすることができる。しかし、ＰＵＳＨ＿ＰＲＯＭＩＳＥが遅れて送信される場合や、クライアントがキャンセルすべきセグメント名が分からない場合などに、複数のコマンドをやり取りする必要があるため、トランザクションが増大して遅延が生じる場合があった。

これに対して、動作例１では、送信装置１０１が受信装置１０２に、ＰＵＳＨ送信指示のＵＲＬ形式の識別子８０５を通知することで、受信装置１０２は、識別子８０５によりキャンセル対象を特定してキャンセルを指示することができる。したがって、キャンセル対象を特定するために余分なトランザクションを必要とせずに、ＰＵＳＨ送信のキャンセルを行うことが可能である。

（動作例２）
次に、ＨＴＴＰ／２上で、文字列形式の識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定全てのセグメントをキャンセルする例について、図９を参照して説明する。

９０１から９０２は８０１から８０２と同じである。また、図６のＳ６０１及び図７のＳ７０１からＳ７０２の処理は、図８を参照して説明した内容と同様であるため説明は省略する。

Ｓ６０２により、送信装置１０１の指示管理部２０６は、受信装置１０２から受信したＰＵＳＨ送信指示９０２に対し”ｐｕｓｈ１”という識別子９０５を割り振る。図９では、識別子として文字列の形式を採用している例を示している。

Ｓ６０３により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示９０２に対する応答として、ＰＵＳＨ送信指示９０２と同内容のＰＵＳＨ送信指示の応答９０４をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス９０３を受信装置１０２へ送信する。レスポンス９０３はまたｓｅｇｍｅｎｔＡ１のバイナリデータを含む。レスポンス９０３のｐｕｓｈ−ｐｏｌｉｃｙヘッダーには、ＰＵＳＨ送信指示の応答８０４と対応させて識別子９０５も含める。なお、識別子９０５の前に”ｐｕｓｈ−ＩＤ”というプレフィックスを入れることで、ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのどこからが識別子９０５なのかを区別できるようにしている。このプレフィックスは”ｐｕｓｈ−ＩＤ”に限定しない。識別子９０５をＰＵＳＨ送信指示の応答９０４と共に送信する代わりに、受信装置１０２からＭＰＤの取得要求を受けた際に送信装置１０１はＭＰＤに識別子９０５を記載し受信装置１０２へ通知してもよい。

９０６から９０８は８０６から８０８と同様である。また図６のＳ６０４からＳ６０５及び図７のＳ７０３からＳ７０５における処理は、図８を参照して説明したＰＵＳＨ送信の処理と内容が同様であるため説明は省略する。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示９１１をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト９０９を送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示９１１は、ＰＵＳＨ送信指示９０２によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルする内容である。リクエスト９０９のａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに識別子９０５（”ｐｕｓｈ１”）を合わせて含めることでキャンセルしたいＰＵＳＨ送信指示９０２を指定することができる。リクエスト９０９のｐａｔｈに指定するＵＲＬ９１０は、ＭＰＤに記載するなどして事前に送信装置１０１−受信装置１０２間で共有したものを指定する。９１２から９１４は８１１から８１３と同様である。また、図６のＳ６０６からＳ６１２及び図７のＳ７０７の処理は、図８を参照して説明した内容と同様であるため説明は省略する。

動作例２では、送信装置１０１が受信装置１０２に、ＰＵＳＨ送信指示の文字列形式の識別子９０５を通知することで、受信装置１０２は、識別子９０５によりキャンセル対象を特定してキャンセルを指示することができる。したがって、キャンセル対象を特定するために余分なトランザクションを必要とせずに、ＰＵＳＨ送信のキャンセルを行うことが可能である。

（動作例３）
次に、ＨＴＴＰ／２上で、ＰＵＳＨ送信指示の内容とＰＵＳＨ送信指示を送信した際に合わせて取得したリソースの組み合わせによりキャンセルすべきＰＵＳＨ送信指示を指定する例について、図１０を参照して説明する。図１０は、ＰＵＳＨ送信指示によりＰＵＳＨする予定の全てのセグメントをキャンセルする例を示している。

図１０の１００１及び１００３は、図８の８０１及び８０２と同様である。また、図６のＳ６０１及び図７のＳ７０１からＳ７０２における処理は、図８を参照して説明した処理の内容と同様あるため説明は省略する。

図１０の例では、ＰＵＳＨ送信指示の内容とＰＵＳＨ送信指示を送信した際に取得したリソースの組み合わせによりＰＵＳＨ送信キャンセル指示を行う。このため、送信装置１０１がＰＵＳＨ送信指示に識別子を割り振るＳ６０２はスキップする。図１０の場合、リソースとは、リクエスト１００１でＧＥＴ対象となっている１００２の”ｓｅｇｍｅｎｔＡ１”である。

Ｓ６０３により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示１００３に対する応答を含むレスポンス１００４を受信装置１０２へ返す。図１０の例では、レスポンス１００４は、ＰＵＳＨ送信指示１００３と同じ内容であるＰＵＳＨ送信指示の応答１００５をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含んでいる。また、レスポンス１００４は、ｓｅｇｍｅｎｔＡ１のバイナリデータを含んでいる。レスポンス１００４は、図８、図９を参照して説明した動作例とは異なり、ＰＵＳＨ送信指示の識別子は含まない。

１００６から１００８は、図８の８０６から８０８と同様である。また、図６のＳ６０４からＳ６０５及び図７のＳ７０３からＳ７０５の処理は、図８を参照して説明したＰＵＳＨ送信の処理と内容が同様であるため説明は省略する。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１０１０をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１００９を送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示１０１０の内容は、ＰＵＳＨ送信指示１００３によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルするというものである。リクエスト１００１でＧＥＴ対象となっていた１００２であるｓｅｇｍｅｎｔＡ１をｐａｔｈヘッダーに含み、さらにＰＵＳＨ送信指示１００３の内容をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含める。これによりキャンセルしたいＰＵＳＨ送信指示１００３を指定する。プッシュ送信指示内容とリソースを組み合わせることで、同じＰＵＳＨ送信指示内容が複数のリソースに対して使われていても、キャンセル対象を指定することができる。

１０１１から１０１３は図８の８１１から８１３と同様である。また図６のＳ６０６からＳ６１２及び図７のＳ７０７の処理は、図８を参照して説明した処理の内容と同様であるため説明は省略する。

動作例３では、受信装置１０２は、ＰＵＳＨ送信指示の内容とＰＵＳＨ送信指示を送信した際に合わせて取得したリソースの組み合わせによりキャンセルすべきＰＵＳＨ送信指示を指定する。ＰＵＳＨ送信指示１００３とリソース１００２によりキャンセル対象を特定してキャンセルを指示することができる。したがって、受信装置１０２は、余分なトランザクションを必要とせずに、キャンセル対象を直接特定してＰＵＳＨ送信のキャンセルを行うことが可能である。

（動作例４）
次に、ＨＴＴＰ／２上で、複数のＰＵＳＨ送信指示を要求した後で、ＵＲＬ形式の識別子によりキャンセルするＰＵＳＨ送信指示を一つ指定し、ＰＵＳＨ送信指示によりＰＵＳＨ予定の全てのセグメントをキャンセルする例について、図１１を参照して説明する。この例では、識別子は送信装置１０１が割り振るとして、受信装置１０２がＰＵＳＨ送信指示に識別子を割り振るＳ７０１はスキップする。

Ｓ７０２において、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示１１０２と１１０３をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１１０１を送信装置１０１へ送信する。リクエスト１１０１は二つのａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーを持ち、これら二つのヘッダーによりＰＵＳＨ送信指示１１０２と１１０３を含む。別々のａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーではなく、一つのａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに、ＰＵＳＨ送信指示１１０２と１１０３を含めてもよい。１１０２において、図８の８０２と同様に、”ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｎｅｘｔ”に続く数字”２”は、”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”に続いて取得するセグメントの個数を指定している。したがって、受信装置１０２は、ＰＵＳＨ送信指示１１０２によってｓｅｇｍｅｎｔＡ２及びｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信を要求している。また、１１０３において、”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＢ（％０１ｄ）”に続く括弧内の二つの数字は、”（％０１ｄ）”が採りうる値の範囲により、要求対象のセグメントを特定している。１１０３の例では、”｛２，３｝”が範囲として指定されているから、ＰＵＳＨ送信指示１１０３によって、ｓｅｇｍｅｎｔＢ２及びｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信要求が行われている。

Ｓ６０１により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示１１０２と１１０３を含むリクエスト１１０１を受信する。

Ｓ６０２により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示１１０２に”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ１”という識別子１１０６を割り振る。さらに、ＰＵＳＨ送信指示１１０３に対し、”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ２”という識別子１１０８をそれぞれ割り振る。この例では、識別子はＵＲＬの形式を採用している。

Ｓ６０３により、送信装置１０１の通信部２０７はＰＵＳＨ送信指示１１０２と１１０３に対する応答をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１１０４を受信装置１０２へ送信する。レスポンス１１０４はまたｓｅｇｍｅｎｔＡ１のバイナリデータを含んでいる。図１１の例では、ＰＵＳＨ送信指示１１０２と１１０３に対する応答として、ＰＵＳＨ送信指示１１０２及び１１０３と同じ内容であるＰＵＳＨ送信指示の応答１１０５と１１０７を含んでいる。すなわち、レスポンス１１０４は二つのｐｕｓｈ−ｐｏｌｉｃｙヘッダーを持ち、これら二つのヘッダーによりＰＵＳＨ送信指示の応答１１０５と１１０７を含んでいる。なお、別々のｐｕｓｈ−ｐｏｌｉｃｙヘッダーではなく、一つのｐｕｓｈ−ｐｏｌｉｃｙヘッダーにＰＵＳＨ送信指示の応答１１０５と１１０７を含めてもよい。図１１の例では、さらに、応答１１０５に対応させて識別子１１０６（”ｐｕｓｈ１”）を、応答１１０７に対応させて識別子１１０８（”ｐｕｓｈ２”）を含めている。識別子１１０６、１１０８の前に”ｐｕｓｈ−ＵＲＬ”というプレフィックスを入れることで、ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのどこからが識別子１１０６、１１０８なのかを区別できるようにしている。このプレフィックスは”ｐｕｓｈ−ＵＲＬ”に限定しない。

レスポンス１１０４送信後、送信装置１０１は、ＨＴＴＰ／２における、ＰＵＳＨ送信予定のセグメント毎に、そのセグメントを送信するためのｓｔｒｅａｍを予約するＰＵＳＨ＿ＰＲＯＭＩＳＥ１１０９〜１１１２を受信装置１０２へ送信する。受信装置１０２は、ＰＵＳＨ＿ＰＲＯＭＩＳＥ１１０９〜１１１２を送信装置１０１から受信する。ＰＵＳＨ＿ＰＲＯＭＩＳＥ１１０９、１１１０、１１１１及び１１１２は、レスポンス１１０４の前に送受信してもよい。

Ｓ６０４により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示１１０２と識別子１１０６、及び、ＰＵＳＨ送信指示１１０３と識別子１１０８を紐づけて保持する。

Ｓ７０３により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示１１０２に対する応答１１０５、及び、ＰＵＳＨ送信指示１１０３に対する応答１１０７を含むレスポンス１１０４を受信する。

Ｓ７０４により、受信装置１０２の指示管理部３０６は、応答が返ってきて受理されたＰＵＳＨ送信指示１１０２及び１１０３を、識別子１１０６及び１１０８と紐づけて保持する。

Ｓ６０５により、送信装置１０１はＰＵＳＨ送信を開始し、ｓｅｇｍｅｎｔＡ２のＰＵＳＨ送信として、送信装置１０１の通信部２０７は、ｓｅｇｍｅｎｔＡ２のバイナリデータを含むレスポンス１１１３を受信装置１０２へ送信する。

Ｓ７０５により、受信装置１０２の通信部３０８はレスポンス１１１３を受信する。

Ｓ７０６により、受信装置１０２の通信部３０８はＰＵＳＨ送信キャンセル指示１１１５をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１１１４を送信する。ＰＵＳＨ送信キャンセル指示１１１５は、識別子１１０８により識別されるＰＵＳＨ送信指示１１０３によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルするという内容である。リクエスト１１１４のｐａｔｈヘッダーにキャンセルしたいＰＵＳＨ送信指示１１０３に対応する識別子１１０８を指定する。

Ｓ６０６により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１１１５を含むリクエスト１１１４を受信装置１０２から受信する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１１０８から判定したキャンセル対象であるＰＵＳＨ送信指示１１０３によるＰＵＳＨ予定のセグメントで、その中の一つのセグメントをキャンセル候補セグメント特定する。この例では、ＰＵＳＨ送信指示１１０３によるＰＵＳＨ予定のセグメントはｓｅｇｍｅｎｔＢ２、ｓｅｇｍｅｎｔＢ３であるから、その中の一つであるｓｅｇｍｅｎｔＢ２をキャンセル候補セグメントと特定する。

Ｓ６０８により、キャンセル候補セグメントであるｓｅｇｍｅｎｔＢ２は、ＰＵＳＨ送信指示１１０３以外で送信装置１０１が採用しているＰＵＳＨ送信指示１１０２によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＢ２のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＢ２のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１１１１による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１１１８の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１１１５によるＰＵＳＨ送信指示１１０３のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定する（Ｓ６１０でＮＯ）。ＰＵＳＨ予定のセグメントの中で、ｓｅｇｍｅｎｔＢ３について処理を行っていないためである。そこで、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１１０８から判定したキャンセル対象であるＰＵＳＨ送信指示１１０３がＰＵＳＨ予定のセグメントで、その中の一つであるｓｅｇｍｅｎｔＢ３をキャンセル候補セグメントと特定する。

Ｓ６０８により、キャンセル候補セグメントであるｓｅｇｍｅｎｔＢ３が、ＰＵＳＨ送信指示１１０３以外で送信装置１０１が採用しているＰＵＳＨ送信指示１１０２によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６はセグメント決定部２０５へｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１１１２による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１１１９の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１１１５によるＰＵＳＨ送信指示１１０３のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は１１０３のみであるため（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１１１５に対する応答１１１７をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１１１６を受信装置１０２へ送信する。この応答１１１７は、ＰＵＳＨ送信キャンセル指示１１１５と同じ内容を有する。

Ｓ７０７により、受信装置１０２の通信部３０８はＰＵＳＨ送信キャンセル指示の応答１１１７を含むレスポンス１１１６を受信する。

キャンセルされたｓｅｇｍｅｎｔＢ２及びｓｅｇｍｅｎｔＢ３に対して、送信装置１０１は受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ１１１１及び１１１２を送信しているため、これらをキャンセルする必要がある。そこで、送信装置１０１は受信装置１０２へＲＳＴ＿ＳＴＲＥＡＭ１１１８及び１１１９を送信し、受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１１１８及び１１１９はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

動作例４では、２つのＰＵＳＨ送信指示１１０２、１１０３が送信され、一方のＰＵＳＨ送信指示について、全てのセグメントのキャンセルが指示された場合の例を説明した。動作例４では、各ＰＵＳＨ送信指示に識別子１１０６、１１０８を付与して、ＰＵＳＨ送信指示を指定可能としたことで、キャンセル対象を特定するために余分なトランザクションを必要とせずに、ＰＵＳＨ送信のキャンセルを行うことができる。

（動作例５）
次に、ＨＴＴＰ／２上で、ＵＲＬ形式の識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定のセグメントのうち一部のセグメントをキャンセルする例について、図１２を参照して説明する。

１２０１から１２０７及び１２１０は、８０１から８０８と同様である。また図６のＳ６０１からＳ６０５及び図７のＳ７０１からＳ７０５の処理は、図８を参照して説明した処理の内容同様であるため説明は省略する。ただし、図１２の例では、ＰＵＳＨ送信指示１２０２はｓｅｇｍｅｎｔＡ１から再生時間的に連続する次の四つのセグメントのＰＵＳＨ送信要求をするものとなっている。また、ＰＵＳＨ＿ＰＲＯＭＩＳＥ１２０６と１２０７と共に、ｓｅｇｍｅｎｔＡ４及びｓｅｇｍｅｎｔＡ５の送信を予約するＰＵＳＨ＿ＰＲＯＭＩＳＥ１２０８及び１２０９を送信している。

Ｓ７０６により、受信装置１０２は、ＰＵＳＨ送信キャンセル指示１２１２をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１２１１として送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示１２１２は、ｓｅｇｍｅｎｔＡ１から再生時間的に連続する次の四つのセグメントのＰＵＳＨ送信を指示しているＰＵＳＨ送信指示１２０２に対し、送信予定セグメントのうち後ろから二つのセグメントをキャンセルする指示である。ここで、１２１２は、識別子”ｐｕｓｈ１”（１２０５）により識別される、ｓｅｇｍｅｎｔＡ１に後続する連続する二つのセグメントｓｅｇｍｅｎｔＡ２、ｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信を要求するものである。もっとも、リクエスト１２０１では、ｓｅｇｍｅｎｔＡ１に後続する連続する四つのセグメントのＰＵＳＨ送信を要求していたのであるから、１２１２は、ｓｅｇｍｅｎｔＡ４、ｓｅｇｍｅｎｔＡ５の送信要求をキャンセルする要求に相当する。このように、図１２の例では、同一の識別子により識別されるＰＵＳＨ送信要求について、内容の異なるＰＵＳＨ送信要求が送受信されたときは、最後に送受信された要求に従い動作する。リクエスト１２１１のｐａｔｈヘッダーに識別子１２０５を指定することでキャンセルしたいＰＵＳＨ送信指示１２０２を指定する。

Ｓ６０６により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１２１２を含むリクエスト１２１１を受信装置１０２から受信する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１２０５から判定したキャンセル対象であるＰＵＳＨ送信指示１２０２によるＰＵＳＨ予定のセグメントで、その中の一つであるｓｅｇｍｅｎｔＡ４をキャンセル候補セグメントと特定する。送信装置１０１においてＰＵＳＨ送信指示１２０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップしＳ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ４のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５は、ｓｅｇｍｅｎｔＡ４のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１２０８による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１２１５の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１２１２によるＰＵＳＨ送信指示１２０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定する（Ｓ６１０でＮＯ）。ｓｅｇｍｅｎｔＡ５について処理を行っていないためである。そこで、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１２０５から判定したキャンセル対象であるＰＵＳＨ送信指示１２０２がＰＵＳＨ予定のセグメントで、その中の一つであるｓｅｇｍｅｎｔＡ５をキャンセル候補セグメントと特定する。送信装置１０１においてＰＵＳＨ送信指示１２０２以外で指示されているＰＵＳＨ送信指示はないためＳ６０８をスキップしＳ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＡ５のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５は、ｓｅｇｍｅｎｔＡ５のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１２０９による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１２１６の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１２１２によるＰＵＳＨ送信指示１２０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は１２０２のみであるため（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１２１２に対する応答１２１４をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１２１３を受信装置１０２へ送信する。この応答１２１４は、ＰＵＳＨ送信キャンセル指示１２１２と同様の内容を有する。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示の応答１２１４を含むレスポンス１２１３を受信する。

キャンセルされたｓｅｇｍｅｎｔＡ４及びｓｅｇｍｅｎｔＡ５に対して送信装置１０１は受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ１２０８及び１２０９を送信している。そのため、これらをキャンセルするためにＲＳＴ＿ＳＴＲＥＡＭ１２１５及び１２１６を送信し受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１２１５及び１２１６はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

動作例５では、ＰＵＳＨ送信指示に識別子１２０５を付与することで、受信装置１０２は、余分なトランザクションを要さずに、識別子１２０５を指定して送信対象のセグメントの一部の送信をキャンセルすることが可能な例を説明した。

（動作例６）
次に、ＨＴＴＰ／２上で、複数のＰＵＳＨ送信指示を要求し採用された後で、ＵＲＬ形式の識別子によりキャンセル対象として全てのＰＵＳＨ送信指示を指定する場合の例について、図１３を参照して説明する。図１３では、各ＰＵＳＨ送信指示がＰＵＳＨ送信する予定全てのセグメントをキャンセルする例を示している。図１３の１３０１から１３１３は図１１の１１０１から１１１３と同様である。また図６のＳ６０１から６０５及び図７のＳ７０１から７０５の処理は、図１１、図８を参照して説明した処理の内容と同様であるため説明は省略する。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１３１６をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１３１４を送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示１３１６は、ＰＵＳＨ送信指示１３０２及び１３０３の両方によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルする内容のキャンセル指示である。リクエスト１３１４のｐａｔｈヘッダーに、現在送信装置１０１が採用している全てのＰＵＳＨ送信指示を指す識別子１３１５（”ｐｕｓｈ”）を指定する。この識別子１３１５は、事前に送信装置１０１がＭＰＤに記載することなどにより、受信装置１０２へ事前に通知する。この方式以外に、全てのＰＵＳＨ送信指示を指定する識別子を各ＰＵＳＨ送信指示に割り振る識別子の形式から分かるようにしてもよい。例えば、各ＰＵＳＨ送信部に割り振る識別子は”文字列＋数値”の形式を取るものとする。そして、各ＰＵＳＨ送信指示に割り振る識別子の数値部を取り除いた文字列部分のみのものが全てのＰＵＳＨ送信指示を指定するための識別子を表すようにしてもよい。送信装置１０１と受信装置１０２とは、このルールを予め共有しておく。図１３でＰＵＳＨ送信指示１３０２と１３０３に割り振った各識別子１３０６と１３０８はそれぞれ”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ１”と”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ２”である。そこから、受信装置１０２は全てのＰＵＳＨ送信指示を指定するための識別子は数値を除いた”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ”ということが分かる。

Ｓ６０６により、送信装置１０１の通信部２０７はＰＵＳＨ送信キャンセル指示１３１６を含むリクエスト１３１４を受信する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１３１５から判定したキャンセル対象の一つであるＰＵＳＨ送信指示１３０２によるＰＵＳＨ予定のセグメントのうち、未送信のセグメントをキャンセル候補と特定する。この例では、未送信のセグメントの一つであるｓｅｇｍｅｎｔＡ３をキャンセル候補セグメントと特定している。

Ｓ６０８により、キャンセル候補セグメントであるｓｅｇｍｅｎｔＡ３が、ＰＵＳＨ送信指示１３０２以外で送信装置１０１が採用しているＰＵＳＨ送信指示１３０３によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６はセグメント決定部２０５へｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１３１０による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１３１９の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１３１６によるＰＵＳＨ送信指示１３０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。
Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は１３０２以外に１３０３があるため（Ｓ６１１でＮＯ）、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１３１５から判定したキャンセル対象の一つであるＰＵＳＨ送信指示１３０３がＰＵＳＨ予定のセグメントのうち、その中の一つであるｓｅｇｍｅｎｔＢ２をキャンセル候補セグメントと特定する。

Ｓ６０８により、キャンセル候補セグメントであるｓｅｇｍｅｎｔＢ２が、ＰＵＳＨ送信指示１３０３以外で送信装置１０１が採用しているＰＵＳＨ送信指示１３０２によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｓｅｇｍｅｎｔＢ２のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５は、ｓｅｇｍｅｎｔＢ２のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１３１１による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１３２０の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１３１６によるＰＵＳＨ送信指示１３０３のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定し（Ｓ６１０でＮＯ）、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は識別子１３１５から判定したキャンセル対象の一つであるＰＵＳＨ送信指示１３０３がＰＵＳＨ予定のセグメントのうち、その中の一つであるｓｅｇｍｅｎｔＢ３をキャンセル候補セグメントと特定する。

Ｓ６０８により、キャンセル候補セグメントであるｓｅｇｍｅｎｔＢ３が、ＰＵＳＨ送信指示１３０３以外で送信装置１０１が採用しているＰＵＳＨ送信指示１３０２によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６はセグメント決定部２０５へｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１３１２による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１３２１の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１３１６によるＰＵＳＨ送信指示１３０３のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、ＰＵＳＨ送信キャンセル指示１３１６が対象とする全てのＰＵＳＨ送信指示に対してキャンセルを行ったと判定し（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７はＰＵＳＨ送信キャンセル指示１３１６に対する応答１３１８をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１３１７を受信装置１０２へ送信する。この応答１３１８は、ＰＵＳＨ送信キャンセル指示１３１６と同様の内容を有する。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示の応答１３１８を含むレスポンス１３１７を送信装置１０１から受信する。

キャンセルされたｓｅｇｍｅｎｔＡ３、ｓｅｇｍｅｎｔＢ２及びｓｅｇｍｅｎｔＢ３に対して、送信装置１０１は受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ１３１０から１３１２を送信している。そのため、これらをキャンセルするために、送信装置１０１はＲＳＴ＿ＳＴＲＥＡＭ１３１９から１３２１を送信し、受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１３１９から１３２１はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

動作例６では、複数のＰＵＳＨ送信指示が要求された場合に、各ＰＵＳＨ送信指示のＰＵＳＨ送信をキャンセルするために、ＰＵＳＨ送信指示に共通の識別子を使用することで、余分なトランザクションを不要とする例を説明した。

（動作例７）
次に、ＨＴＴＰ／２上で、ＵＲＬ形式の識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定全てのセグメントをキャンセルしつつ、別のＰＵＳＨ送信指示を行う例について、図１４を参照して説明する。

図１４の１４０１から１４０４は８０１から８０４と同様であり、１４０５から１４０７は８０６から８０８と同様である。また、図６のＳ６０１から６０５及び図７のＳ７０１から７０５は図８と内容が同じであるため説明は省略する。図１４のレスポンス１４０３には図８の８０５に相当する記載がないことからわかるように、図８とは異なり図１４ではＰＵＳＨ送信指示１４０２に対し識別子を割り振っていないが、図８と同様に割り振ってもよい。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１４１０をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１４０８を送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示１４１０は、対象とするＰＵＳＨ送信指示によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルする内容を有する。ＰＵＳＨ送信キャンセル指示１４１０は、キャンセル対象とするＰＵＳＨ送信指示を指定するために、ＰＵＳＨ送信指示１４０２を指示した際に指定したＵＲＬである”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”１４１１を含む。図１４の例では、ＰＵＳＨ送信キャンセル指示１４１０の後ろに”ｐａｔｈ”というプレフィックスと共にＵＲＬ１４１１を含んでいる。このプレフィックスは”ｐａｔｈ”に限定しない。またこのプレフィックスはなくてもよい。ＵＲＬの代わりにＰＵＳＨ送信指示を区別できる他の値を含めてもよい。キャンセル対象のＰＵＳＨ送信指示をＵＲＬ１４１１により指定する代わりに、リスト形式やテンプレート形式により、キャンセルしたいセグメントを直接指定してもよい。キャンセル対象をリスト形式で指定する場合、１４１０に”ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｃａｎｃｅｌ−ｌｉｓｔ”の様なリスト形式を示すキャンセル指示を指定してもよい。そして１４１１の代わりに「”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ３”；”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ４”；”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ５”；”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ６”」の様な形式を指定する。キャンセル対象をテンプレート形式で指定する場合、１４１０に” ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｃａｎｃｅｌ−ｔｅｍｐｌｅｔｅ”の様なテンプレート形式を示すキャンセル指示を指定してもよい。そして１４１１の代わりに「／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ｛％ｄ｝；｛３，４，５，６｝」や「／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ｛％ｄ｝；｛３ー６｝」の様な形式を指定する。受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示とは別に、新しく設定するＰＵＳＨ送信指示１４１２をリクエスト１４０８に含んでいる。ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのＰＵＳＨ送信キャンセル指示１４１０及び１４１１の後ろにＰＵＳＨ送信指示１４１２を含む。１４１０及び１４１１の前にＰＵＳＨ送信指示１４１２を含めてもよい。ｐａｔｈヘッダーに、新しく設定するＰＵＳＨ送信指示１４１２実行時のベースとなるＵＲＬ１４０９を含める。図１４の例では、ｐａｔｈヘッダーに指定しているＵＲＬが”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＢ３”であり、ＰＵＳＨ送信指示１４２３は、連続する四つのセグメントのＰＵＳＨ送信を要求するものである。したがって、ＰＵＳＨ送信指示１４１２は、ｓｅｇｍｅｎｔＢ３から再生時間的に連続する四つのセグメントｓｅｇｍｅｎｔＢ４〜ｓｅｇｍｅｎｔＢ７をＰＵＳＨ送信するよう指示する内容を有する。

図６のＳ６０６からＳ６１１の処理は、図８を参照して説明した処理の内容が同様であるため説明は省略する。

Ｓ６１２により、送信装置１０１の通信部２０７はＰＵＳＨ送信キャンセル指示１４１０及びＰＵＳＨ送信指示１４１２に対する応答１４１４をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１４１５を受信装置１０２へ送信する。この応答１４１４は、１４１０、１４１１及び１４１２と同じ内容を有する。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１４１０とＰＵＳＨ送信指示１４１２の応答１４１４と、ｓｅｇｍｅｎｔＢ３のバイナリデータを含むレスポンス１４１３を受信する。

キャンセルされたｓｅｇｍｅｎｔＡ３に対して、送信装置１０１は、受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ１４０６を送信している。そのため、送信装置１０１は、これをキャンセルするためにＲＳＴ＿ＳＴＲＥＡＭ１４１５を送信し、受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１４１５はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

Ｓ６１２以降、送信装置１０１はＰＵＳＨ送信指示１４１２を元に新たにＰＵＳＨ送信を開始する。すなわち、送信装置１０１は、ｓｅｇｍｅｎｔＢ４〜ｓｅｇｍｅｎｔＢ７のＰＵＳＨ送信を開始する。

動作例７では、識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定全てのセグメントをキャンセルしつつ、別のＰＵＳＨ送信指示を行う例を説明した。動作例７においても、識別子によりＰＵＳＨ送信指示を指定することで、キャンセル対象を特定するために余分なトランザクションを必要とせずに、ＰＵＳＨ送信のキャンセルを行うことが可能である。

（動作例８）
次に、ＨＴＴＰ／２上で、複数のＰＵＳＨ送信指示を要求し採用された後で、ＵＲＬ形式の識別子によりキャンセル対象として全てのＰＵＳＨ送信指示を指定し、各ＰＵＳＨ送信指示がＰＵＳＨ送信する予定の全てのセグメントをキャンセルする例を説明する。このキャンセルと合わせて新しいＰＵＳＨ送信指示を行う例について、図１５を参照して説明する。

図１５において、１５０１から１５１３は図１１の１１０１から１１１３と同様である。また図６のＳ６０１からＳ６０５及び図７のＳ７０１からＳ７０５処理は、図１１、図８を参照して説明した処理の内容と同様であるため説明は省略する。

Ｓ７０６により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１５１６をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１５１４を送信装置１０１へ送信する。ＰＵＳＨ送信キャンセル指示１５１６は、対象とするＰＵＳＨ送信指示によりＰＵＳＨ送信する予定の全てのセグメントをキャンセルする内容を有する。ＰＵＳＨ送信キャンセル指示１５１６は、キャンセル対象とするＰＵＳＨ送信指示を指定するために、ＰＵＳＨ送信指示１５０２、１５０３を指示した際に指定したＵＲＬである”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”１５１７を含む。ＵＲＬ１５１７を指定することにより、”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”を指定して要求を出したＰＵＳＨ送信指示を全てキャンセル対象とする。図１５では、ｓｅｇｍｅｎｔＡ２、ｓｅｇｍｅｎｔＡ３だけでなく、ｓｅｇｍｅｎｔＢ２、ｓｅｇｍｅｎｔＢ３も”：ｐａｔｈ＝／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＡ１”のパス名に基づき要求されている。すなわち、ＰＵＳＨ送信指示１５０２、１５０３は、いずれも同一のリソース”ｓｅｇｍｅｎｔＡ１”を利用している。そのため、ＰＵＳＨ送信キャンセル指示１５１６において、ＰＵＳＨ送信指示１５０２と１５０３の両方がキャンセル対象となる。

ＰＵＳＨ送信キャンセル指示１５１６の後ろに”ｐａｔｈ”というプレフィックスと共にＵＲＬ１５１７を含める。このプレフィックスは”ｐａｔｈ”に限定しない。またこのプレフィックスはなくてもよい。ＵＲＬの代わりにＰＵＳＨ送信指示を区別できる他の値を含めてもよい。キャンセル対象のＰＵＳＨ送信指示をＵＲＬ１５１７により指定する代わりに、リスト形式やテンプレート形式により、キャンセルしたいセグメントを直接指定してもよい。受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示とは別に、新しく設定するＰＵＳＨ送信指示１５１８をリクエスト１５１４に含める。図１５の例では、ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのＰＵＳＨ送信キャンセル指示１５１６及び１５１７の後ろにＰＵＳＨ送信指示１５１８を含んでいる。１５１６及び１５１７の前にＰＵＳＨ送信指示１５１８を含めてもよい。ｐａｔｈヘッダーに、新しく設定するＰＵＳＨ送信指示１５１８実行時のベースとなるＵＲＬ１５１５を含める。ｐａｔｈヘッダーに指定しているＵＲＬが”／ｅｘａｍｐｌｅ／ｔｍｐ／ｓｅｇｍｅｎｔＣ３”なので、ＰＵＳＨ送信指示１５１８はｓｅｇｍｅｎｔＣ３から再生時間的に連続する次の四つのセグメントをＰＵＳＨ送信するよう指示する内容となる。

図６のＳ６０６からＳ６１１の処理は、図８を参照して説明した処理と内容が同様であるため説明は省略する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１５１６及びＰＵＳＨ送信指示１５１８に対する応答１５２０をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１５１９を受信装置１０２へ送信する。応答１５２０は、１５１６、１５１７及び１５１８と同様の内容を有する。レスポンス１５１９はｓｅｇｍｅｎｔＣ３のバイナリデータを含む。また送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示１５１８に対し”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ３”という識別子１５２１を割り振る。そしてレスポンス１５１９のｐｕｓｈ−ｐｏｌｉｃｙヘッダーに、識別子１５２１を含める。識別子１５２１の前に”ｐｕｓｈ−ＵＲＬ”というプレフィックスを入れることで、ｐｕｓｈ−ｐｏｌｉｃｙヘッダーのどこからが識別子１５２１なのかを区別できるようにしている。このプレフィックスは”ｐｕｓｈ−ＵＲＬ”に限定しない。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示１５１６とＰＵＳＨ送信指示１５１８の応答１５２１を含むレスポンス１５１９を送信装置１０１から受信する。キャンセルされたｓｅｇｍｅｎｔＡ３、ｓｅｇｍｅｎｔＢ２及びｓｅｇｍｅｎｔＢ３に対して送信装置１０１は、ＰＵＳＨ＿ＰＲＯＭＩＳＥ１５１０から１５１２を受信装置１０２へ送信している。そのため、これらをキャンセルするために、送信装置１０１はＲＳＴ＿ＳＴＲＥＡＭ１５２２から１５２４を送信し、受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１５２２から１５２４はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

Ｓ６１２以降、送信装置１０１はＰＵＳＨ送信指示１５１８を元に新たにＰＵＳＨ送信を開始する。

動作例８では、複数のＰＵＳＨ送信指示を要求し採用された後で、識別子によりキャンセル対象として全てのＰＵＳＨ送信指示を指定する例を説明した。動作例８においても、キャンセル対象を特定するために余分なトランザクションを必要とせずに、ＰＵＳＨ送信のキャンセルを行うことが可能である。

（動作例９）
次に、ＷｅｂＳｏｃｋｅｔ上で、ＵＲＬ形式の識別子によりキャンセルすべきＰＵＳＨ送信指示を指定し、ＰＵＳＨ送信指示によりＰＵＳＨする予定全てのセグメントをキャンセルする例について、図１６を参照して説明する。

識別子は送信装置１０１が割り振るものとして、受信装置１０２はＳ７０１の処理をスキップする。

Ｓ７０２により、受信装置１０２の通信部３０８は、送信装置１０１へＰＵＳＨ送信指示１６０２を含むリクエスト１６０１を送信する。ＰＵＳＨ送信指示は”ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｎｅｘｔ；２”という文字列を、”ｐｕｓｈ＿ｄｉｒｅｃｔｉｖｅ”というプレフィックスの後ろに含めている。このプレフィックスは”ｐｕｓｈ＿ｄｉｒｅｃｔｉｖｅ”に限定しない。リクエスト１６０１はｓｅｇｍｅｎｔＡ１をリクエストするメッセージであり、ｓｅｇｍｅｎｔＡ１から再生時間的に連続する次の二つのセグメントをＰＵＳＨ送信するようＰＵＳＨ送信指示１６０２で指示している。

Ｓ６０１により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示１６０２を含むリクエスト１６０１を受信装置１０２から受信する。

Ｓ６０２により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示１６０２に対し”／ｅｘａｍｐｌｅ／ｔｍｐ／ｐｕｓｈ１”という識別子１６０５を割り振る。図１６の例では、識別子はＵＲＬの形式を採用している。

Ｓ６０３により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示１６０２に対する応答１６０４と、を含むレスポンスをｓｅｇｍｅｎｔＡ１のバイナリデータを含むレスポンス１６０３を受信装置１０２へ送信する。この応答１６０４は、ＰＵＳＨ送信指示１６０２と同様の内容を有する。ＰＵＳＨ送信指示の応答１６０４は、”ｐｕｓｈ＿ａｃｋ”というプレフィックスの後ろに含めている。このプレフィックスは”ｐｕｓｈ＿ａｃｋ”に限定しない。ＰＵＳＨ送信指示の応答１６０６と対応させて識別子１６０５を含める。識別子１６０５は”ｐｕｓｈ＿ｕｒｌ＝”というプレフィックスの後ろに含めている。このプレフィックスは”ｐｕｓｈ＿ｕｒｌ＝”に限定しない。

Ｓ６０４により、送信装置１０１の指示管理部２０６は、受信したＰＵＳＨ送信指示１６０２と識別子１６０５を紐づけて保持する。

Ｓ７０３により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示１６０２の応答１６０４を含むレスポンス１６０３を受信する。

Ｓ７０４により、受信装置１０２の指示管理部３０６は、応答が返ってきて受理されたＰＵＳＨ送信指示１６０２を識別子１６０５と紐づけて保持する。

Ｓ６０５により、送信装置１０１はＰＵＳＨ送信を開始し、ｓｅｇｍｅｎｔＡ２のＰＵＳＨ送信として、送信装置１０１の通信部２０７は、ｓｅｇｍｅｎｔＡ２のバイナリデータを含むレスポンス１６０６を受信装置１０２へ送信する。

Ｓ７０５により、受信装置１０２の通信部３０８は、レスポンス１６０６を受信する。

Ｓ７０６により、受信装置１０２の通信部３０８はＰＵＳＨ送信指示１６０２によりＰＵＳＨ送信する予定の全てのセグメントに対するＰＵＳＨ送信キャンセル指示１６０８をリクエスト１６０７として送信する。識別子１６０５を指定することでキャンセルしたいＰＵＳＨ送信対象を指定する。識別子１６０５は”ｓｅｇｍｅｎｔ＿ｕｒｉ”というプレフィックスの後ろに含めている。このプレフィックスは”ｓｅｇｍｅｎｔ＿ｕｒｉ”に限定しない。

Ｓ６０６により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１６０８を含むリクエスト１６０７を受信装置１０２から受信する。

Ｓ６０７により、送信装置１０１の指示管理部２０６は、識別子１６０５から判定したキャンセル対象であるＰＵＳＨ送信指示１６０２によるＰＵＳＨ予定のセグメントで、その中の一つであるｓｅｇｍｅｎｔＡ３をキャンセル候補セグメントと特定する。送信装置１０１においてＰＵＳＨ送信指示１６０２以外で指示されているＰＵＳＨ送信指示はないため、Ｓ６０８をスキップしＳ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６はセグメント決定部２０５へｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルする。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１６０８によるＰＵＳＨ送信指示１６０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は１６０２のみであるため（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１６０８に対する応答１６１０を含むレスポンス１６０９を受信装置１０２へ送信する。応答１６１０は、ＰＵＳＨ送信キャンセル指示１６０８と同じ内容を有する。ＰＵＳＨ送信キャンセル指示の応答１６１０は”ｐｕｓｈ＿ａｃｋ”というプレフィックスの後ろに含めている。このプレフィックスは”ｐｕｓｈ＿ａｃｋ”に限定しない。

Ｓ７０７により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信キャンセル指示の応答１６１０を含むレスポンス１６０９を送信装置１０１から受信する。

動作例９ではＨＴＴＰ／２とＷｅｂＳｏｃｋｅｔにおける説明をしたが、ＱＵＩＣやその他ＰＵＳＨ機能を有するプロトコルに対しても本実施形態は適用可能である。

以上のように、本実施形態によれば、送信装置１０１と受信装置１０２の間において、少ないトランザクション回数でＰＵＳＨ送信のキャンセルを行うことができる。また複数のＰＵＳＨ送信指示を行った際に一部のＰＵＳＨ送信指示のみのキャンセルを行う場合や、ＰＵＳＨ送信予定のセグメントの一部のみをキャンセルする場合、受信装置１０２は一つのリクエスト送信でキャンセルを行うことができる。また、ＨＴＴＰ／２上でＭＰＥＧ−ＤＡＳＨの送受信を行い受信装置１０２がＰＵＳＨ送信のキャンセルを指示する際、ＰＵＳＨ＿ＰＲＯＭＩＳＥにより送信予約をしていないセグメントを個別にキャンセルする必要がない。したがって、ネットワーク上の帯域を節約することができる。

（動作例１０）
ＨＴＴＰ／２上で、ＰＵＳＨ送信指示を要求した後で、ＰＵＳＨ送信キャンセルと新たなＰＵＳＨ送信指示を合わせて行う例について、図１７Ａ、図１７Ｂを参照して説明する。この例では、セグメントのデータの種類を識別子として使用するため、受信装置１０２がＰＵＳＨ送信指示に識別子を割り振るＳ７０１はスキップする。また、この例では“／ｅｘａｍｐｌｅ／ｖｉｄｅｏ／”＋セグメント名で映像データセグメントを、“／ｅｘａｍｐｌｅ／ａｕｄｉｏ／”＋セグメント名で音声データのセグメントを表すものとする。

Ｓ７０２において、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示１７０２と１７０３をａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むリクエスト１７０１を送信装置１０１へ送信する。別々のａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーではなく、一つのａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダーに、ＰＵＳＨ送信指示１７０２と１７０３を含めてもよい。１７０２において、“ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｎｅｘｔ”に続く数字“２”は、“／ｅｘａｍｐｌｅ／ｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ１”に続いて取得するセグメントの個数を指定している。したがって、受信装置１０２は、ＰＵＳＨ送信指示１７０２によってｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２及びｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信を要求している。また、１７０３において、“／ｅｘａｍｐｌｅ／ａｕｄｉｏ／ｓｅｇｍｅｎｔＡ（％０１ｄ）”に続く括弧内の二つの数字は、“（％０１ｄ）”が採りうる値の範囲により、要求対象のセグメントを特定している。１７０３の例では、“｛２，３｝”が範囲として指定されているから、ＰＵＳＨ送信指示１７０３によって、ａｕｄｉｏ／ｓｅｇｍｅｎｔＡ２及びａｕｄｉｏ／ｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信要求が行われている。

Ｓ６０１により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信指示１７０２と１７０３を含むリクエスト１７０１を受信する。

動作例１０ではセグメントのデータの種類を識別子として使用するため、送信装置１０１はＳ６０２の処理をスキップする。

Ｓ６０３により、送信装置１０１の通信部２０７はＰＵＳＨ送信指示１７０２と１７０３に対する応答をｐｕｓｈ−ｐｏｌｉｃｙヘッダーに含むレスポンス１７０４を受信装置１０２へ送信する。レスポンス１７０４はまたｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ１のバイナリデータを含んでいる。動作例１０では、レスポンス１７０４は、ＰＵＳＨ送信指示１７０２と１７０３に対する応答として、ＰＵＳＨ送信指示１７０２及び１７０３と同じ内容であるＰＵＳＨ送信指示の応答１７０５と１７０６を含んでいる。すなわち、レスポンス１７０４は二つのｐｕｓｈ−ｐｏｌｉｃｙヘッダーを持ち、これら二つのヘッダーによりＰＵＳＨ送信指示の応答１７０５と１７０６を含んでいる。なお、別々のｐｕｓｈ−ｐｏｌｉｃｙヘッダーではなく、一つのｐｕｓｈ−ｐｏｌｉｃｙヘッダーにＰＵＳＨ送信指示の応答１７０５と１７０６を含めてもよい。

レスポンス１７０４送信後、送信装置１０１は、ＨＴＴＰ／２における、ＰＵＳＨ送信予定のセグメント毎に、そのセグメントを送信するためのｓｔｒｅａｍを予約するＰＵＳＨ＿ＰＲＯＭＩＳＥ１７０７〜１７１１を受信装置１０２へ送信する。受信装置１０２は、ＰＵＳＨ＿ＰＲＯＭＩＳＥ１７０７〜１７１１を送信装置１０１から受信する。ＰＵＳＨ＿ＰＲＯＭＩＳＥ１７０７、１７０８、１７０９、１７１０及び１７１１は、レスポンス１７０４の前に送受信してもよい。

動作例１０ではセグメントのデータの種類を識別子として使用するため、送信装置１０１はＳ６０４の処理をスキップする。

Ｓ７０３により、受信装置１０２の通信部３０８は、ＰＵＳＨ送信指示１７０２に対する応答１７０５、及び、ＰＵＳＨ送信指示１７０３に対する応答１７０６を含むレスポンス１７０４を受信する。

Ｓ７０４により、受信装置１０２の指示管理部３０６は、応答が返ってきて受理されたＰＵＳＨ送信指示１７０２及び１７０３を保持する。なお、動作例１０では一組のリクエストとレスポンスで複数のＰＵＳＨ送信指示のやり取りをしているが、一つのＰＵＳＨ送信指示毎にリクエストとレスポンスを交わす方法でも本実施形態のＰＵＳＨ送信キャンセル処理は実施可能である。

Ｓ６０５により、送信装置１０１はＰＵＳＨ送信を開始し、ａｕｄｉｏ／ｓｅｇｍｅｎｔＡ１のＰＵＳＨ送信として、送信装置１０１の通信部２０７は、ａｕｄｉｏ／ｓｅｇｍｅｎｔＡ１のバイナリデータを含むレスポンス１７１２を受信装置１０２へ送信する。

Ｓ７０５により、受信装置１０２の通信部３０８はレスポンス１７１２を受信する。

Ｓ７０６により、受信装置１０２の通信部３０８はＰＵＳＨ送信キャンセル指示１７１５とＰＵＳＨ送信指示１７１４を含むリクエスト１７１３を送信する。本実施形態ではＰＵＳＨ送信キャンセル指示１７１５としてｐｕｓｈ−ｃａｎｃｅｌヘッダーが用いられるが、ｐｕｓｈ−ｃａｎｃｅｌとは異なる名前のヘッダーをキャンセル指示として用いても良い。動作例１０では、映像データのセグメントをＰＵＳＨ送信キャンセル対象とし、ＰＵＳＨ送信キャンセル対象を指示するためｐｕｓｈ−ｃａｎｃｅｌヘッダー１７１５の値に“ｖｉｄｅｏ”という値を指定するが、“ｖｉｄｅｏ”とは異なる値を用いても良い。また、“ａｕｄｉｏ”や“ｍｅｔａｄａｔａ”という値を指定することで音声データやメタデータのセグメントなど映像データ以外のセグメントをＰＵＳＨ送信キャンセル対象としてもよい。コーデック名や音声の言語などというようにセグメントのデータの種類を詳細に指定しても良い。“ｉｍｍｅｄｉａｔｅ”などを指定することですべてのセグメントをＰＵＳＨ送信キャンセル対象としてもよい。ＰＵＳＨキャンセル対象を指示するための値として“ｖｉｄｅｏ”などデータの種類を表す文字列の代わりに、ＡｄａｐｔａｔｉｏｎＳｅｔやＲｅｐｒｅｓｅｔａｔｉｏｎのＩＤを用いても良い。ＰＵＳＨ送信指示１７１４において、“ｕｒｎ：ｓａｍｐｌｅ：ｐｕｓｈ−ｎｅｘｔ”に続く数字“１”は、“／ｅｘａｍｐｌｅ／ｖｉｄｅｏ／ｓｅｇｍｅｎｔＢ２”に続いて取得するセグメントの個数を指定している。したがって、受信装置１０２は、ＰＵＳＨ送信指示１７１４によってｖｉｄｅｏ／ｓｅｇｍｅｎｔＢ３のＰＵＳＨ送信を要求している。

Ｓ６０６により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１７１５とＰＵＳＨ送信指示１７１４を含むリクエスト１７１３を受信装置１０２から受信する。キャンセル指示１７１５を含むリクエスト１７１３を送信した受信装置と、キャンセル指示１７１５に含まれているデータの種類（本例では、ｖｉｄｅｏ）からキャンセル対象のプッシュ送信指示１７０２が特定される。

Ｓ６０７により、送信装置１０１の指示管理部２０６はＰＵＳＨ送信キャンセル指示１７１５の値から、ＰＵＳＨ送信指示１７０２によるＰＵＳＨ予定のセグメントで、その中の一つのセグメントをキャンセル候補セグメントとして特定する。この例では、ＰＵＳＨ送信指示１１０３によるＰＵＳＨ予定のセグメントはｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２、ｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３であるから、その中の一つであるｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２がキャンセル候補セグメントとして特定される。

Ｓ６０８により、キャンセル候補セグメントであるｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２は、ＰＵＳＨ送信指示１７０２以外で送信装置１０１が採用しているＰＵＳＨ送信指示１７０３によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６は、セグメント決定部２０５へｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１７０８による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１７１９の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１７１５によるＰＵＳＨ送信指示１７０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行っていないと判定する（Ｓ６１０でＮＯ）。ＰＵＳＨ予定のセグメントの中で、ｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３について処理を行っていないためである。そこで、Ｓ６０７へ遷移する。

Ｓ６０７により、送信装置１０１の指示管理部２０６はＰＵＳＨ送信キャンセル指示１７１５の値から、ＰＵＳＨ送信指示１７０２によるＰＵＳＨ予定のセグメントで、その中の一つであるｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３をキャンセル候補セグメントと特定する。

Ｓ６０８により、キャンセル候補セグメントであるｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３が、ＰＵＳＨ送信指示１７０２以外で送信装置１０１が採用しているＰＵＳＨ送信指示１７０３によるＰＵＳＨ送信対象になっていないと判定し（Ｓ６０８でＮＯ）、Ｓ６０９へ遷移する。

Ｓ６０９により、送信装置１０１の指示管理部２０６はセグメント決定部２０５へｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルするよう指示を出し、セグメント決定部２０５はｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３のＰＵＳＨ送信をキャンセルする。具体的なキャンセル処理として、既にＰＵＳＨ＿ＰＲＯＭＩＳＥ１７１０による送信予約済みであるため、送信予約をキャンセルするためのＲＳＴ＿ＳＴＲＥＡＭ１７２１の送信と、送信装置１０１内部でＰＵＳＨ送信を停止する処理を行う。

Ｓ６１０により、ＰＵＳＨ送信キャンセル指示１７１５によるＰＵＳＨ送信指示１７０２のキャンセル候補セグメント全てに対し、キャンセル可能かの確認及びキャンセル処理を行ったと判定し（Ｓ６１０でＹＥＳ）、Ｓ６１１へ遷移する。

Ｓ６１１により、キャンセル対象であるＰＵＳＨ送信指示は１７０２のみであるため（Ｓ６１１でＹＥＳ）、Ｓ６１２へ遷移する。

Ｓ６１２により、送信装置１０１の通信部２０７は、ＰＵＳＨ送信キャンセル指示１７１５に対する応答１７１８とＰＵＳＨ送信指示１７１４に対する応答１７１７を含むレスポンス１７１６を受信装置１０２へ送信する。ＰＵＳＨ送信キャンセル指示１７１５に対する応答１７１８はｐｕｓｈ−ｃａｎｃｅｌヘッダーを用い、ＰＵＳＨ送信キャンセル指示１７１５と同じ内容を有する。なお、別のヘッダーが用いられても良い。レスポンス１７１７はまたｖｉｄｅｏ／ｓｅｇｍｅｎｔＢ２のバイナリデータを含んでいる。

Ｓ７０７により、受信装置１０２の通信部３０８はＰＵＳＨ送信キャンセル指示１７１５に対する応答１７１８とＰＵＳＨ送信指示１７１４に対する応答１７１７を含むレスポンス１７１６を受信する。

レスポンス１７１６の送信後、送信装置１０１は、ＨＴＴＰ／２における、ＰＵＳＨ送信予定のセグメント毎に、そのセグメントを送信するためのｓｔｒｅａｍを予約するＰＵＳＨ＿ＰＲＯＭＩＳＥ１７１９を受信装置１０２へ送信する。受信装置１０２は、ＰＵＳＨ＿ＰＲＯＭＩＳＥ１７１９を送信装置１０１から受信する。

キャンセルされたｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ２及びｖｉｄｅｏ／ｓｅｇｍｅｎｔＡ３に対して、送信装置１０１は受信装置１０２へＰＵＳＨ＿ＰＲＯＭＩＳＥ１７０８及び１７１０を送信しているため、これらをキャンセルする必要がある。そこで、送信装置１０１は受信装置１０２へＲＳＴ＿ＳＴＲＥＡＭ１７２０及び１７２１を送信し、受信装置１０２はこれを受信する。このＲＳＴ＿ＳＴＲＥＡＭ１７２０及び１７２１はＳ７０６の前かＳ７０７の後に受信装置１０２が送信してもよい。

動作例１０では、ＰＵＳＨ送信キャンセル指示１７１５とＰＵＳＨ送信指示１７１４を合わせて行う場合の例を説明した。ＰＵＳＨ送信キャンセル指示１７１５とＰＵＳＨ送信指示１７１４を同じリクエストで送信可能としたことで、ＰＵＳＨ送信指示の再設定を余分なトランザクションを必要とせずに行うことが出来る。またセグメントのデータの種類を指定可能としたことで、特定の種類のセグメントのみのＰＵＳＨ送信キャンセルおよびＰＵＳＨ送信再設定を容易に行うことが出来る。例として、映像セグメントと音声セグメントをＰＵＳＨ対象としている中で、音声セグメントをキャンセルせずに映像セグメントのみをＰＵＳＨ送信キャンセルし、異なる解像度の映像セグメントのＰＵＳＨ送信再設定をすることなどが可能となる。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１：送信装置、１０２：受信装置、１０３：ネットワーク

Claims (15)

1. セグメントに分割されたコンテンツデータを受信装置へプッシュ送信する情報処理装置であって、
   少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を前記受信装置から受信する通信手段と、
   前記通信手段により前記プッシュ送信指示を受信したことに応じて、前記少なくとも１つのセグメントを前記受信装置へプッシュ送信するように前記通信手段を制御する制御手段と
   を備え、
   前記制御手段は、セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を前記受信装置から前記通信手段により受信した場合、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を停止するように前記通信手段を制御する
   ことを特徴とする情報処理装置。
2. 前記通信手段は、識別子によるプッシュ送信指示の指定を含むキャンセル指示を前記受信装置から受信することを特徴とする請求項１に記載の情報処理装置。
3. 前記通信手段は、前記プッシュ送信指示の内容と、前記受信装置により要求されたリソース又はプッシュ送信指示の送受信に関する時刻との組み合わせによるプッシュ送信指示の指定を含むキャンセル指示を前記受信装置から受信することを特徴とする請求項１に記載の情報処理装置。
4. 前記通信手段は、プッシュ送信指示に含まれていたデータの種類を表す値を含むキャンセル指示を前記受信装置から受信し、前記制御手段は、前記データの種類を表す値に基づいてキャンセル対象のプッシュ送信指示を特定することを特徴とする請求項１に記載の情報処理装置。
5. 前記制御手段は、受信した前記キャンセル指示の内容に応じて、前記未送信のセグメントの全て又は一部のプッシュ送信を停止するように前記通信手段を制御することを特徴とする請求項１から４のいずれか１項に記載の情報処理装置。
6. 前記制御手段は、
   前記受信装置から複数のプッシュ送信指示を受信したことに応じてセグメントをプッシュ送信している場合に、当該複数のプッシュ送信指示のうちのいずれかのプッシュ送信指示の指定を含むキャンセル指示を該受信装置から受信したときは、指定された当該プッシュ送信指示に基づく未送信のセグメントのうち、他のプッシュ送信指示に基づく未送信のセグメントに含まれないセグメントのプッシュ送信を停止するように前記通信手段を制御することを特徴とする請求項１から５のいずれか１項に記載の情報処理装置。
7. 送信装置からプッシュ送信された、セグメントに分割されたコンテンツデータを受信する情報処理装置であって、
   少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を前記送信装置へ送信する通信手段と、
   前記プッシュ送信指示に応じて前記送信装置からプッシュ送信された前記少なくとも１つのセグメントを受信するように前記通信手段を制御する制御手段と
   を備え、
   前記制御手段は、セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を前記通信手段により前記送信装置へ送信して、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を該送信装置に停止させる
   ことを特徴とする情報処理装置。
8. 前記制御手段は、前記通信手段により、識別子によるプッシュ送信指示の指定を含むキャンセル指示を前記送信装置へ送信することを特徴とする請求項７に記載の情報処理装置。
9. 前記制御手段は、前記通信手段により、前記プッシュ送信指示の内容と、前記情報処理装置により要求されたリソース又はプッシュ送信指示の送受信に関する時刻との組み合わせによるプッシュ送信指示の指定を含むキャンセル指示を前記送信装置へ送信することを特徴とする請求項７に記載の情報処理装置。
10. 前記通信手段は、プッシュ送信の対象のデータの種類を示す値を含むプッシュ送信指示を送信し、
    前記制御手段は、前記通信手段により、前記データの種類を示す値によるプッシュ送信指示の指定を含むキャンセル指示を前記送信装置へ送信することを特徴とする請求項７に記載の情報処理装置。
11. 前記制御手段は、前記未送信のセグメントの全て又は一部のプッシュ送信を停止させるためのキャンセル指示を前記送信装置へ送信するように前記通信手段を制御することを特徴とする請求項７から１０のいずれか１項に記載の情報処理装置。
12. 前記プッシュ送信指示の指定は、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）により記述されることを特徴とする請求項１から１１のいずれか１項に記載の情報処理装置。
13. セグメントに分割されたコンテンツデータを受信装置へプッシュ送信する、通信手段を備えた情報処理装置の制御方法であって、
    少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を前記受信装置から前記通信手段により受信する受信工程と、
    前記通信手段により前記プッシュ送信指示を受信したことに応じて、前記少なくとも１つのセグメントを前記受信装置へ前記通信手段によりプッシュ送信する送信工程と、
    セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を前記受信装置から前記通信手段により受信した場合、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を停止する停止工程と
    を有することを特徴とする情報処理装置の制御方法。
14. 送信装置からプッシュ送信された、セグメントに分割されたコンテンツデータを受信する、通信手段を備えた情報処理装置の制御方法であって、
    少なくとも１つのセグメントのプッシュ送信を指示するためのプッシュ送信指示を前記送信装置へ前記通信手段により送信する送信工程と、
    前記プッシュ送信指示に応じて前記送信装置からプッシュ送信された前記少なくとも１つのセグメントを前記通信手段により受信する受信工程と、
    セグメントのプッシュ送信をキャンセルするための、プッシュ送信指示の指定を含むキャンセル指示を前記通信手段により前記送信装置へ送信して、指定された当該プッシュ送信指示に基づく未送信のセグメントのプッシュ送信を該送信装置に停止させる停止工程と
    を有することを特徴とする情報処理装置の制御方法。
15. コンピュータを請求項１から１２のいずれか１項に記載の情報処理装置が備える各手段として機能させるためのコンピュータプログラム。

Images