(57)【要約】【課題】配信対象を示す情報を効率的に取得および解析可能とする。【解決手段】送信装置は、第１送信部と、第２送信部と、を備える。第１送信部は、１以上の送信データそれぞれを識別するための１以上の識別情報を受信装置に送信する。第２送信部は、識別情報で識別される送信データの送信を要求するか否かを判定するための判定情報を受信装置に送信する。【選択図】図２
2019092133.tif 000002
【特許請求の範囲】
【請求項１】
１以上の送信データそれぞれを識別するための１以上の識別情報を受信装置に送信する第１送信部と、
前記識別情報で識別される前記送信データの送信を要求するか否かを判定するための判定情報を前記受信装置に送信する第２送信部と、
を備える送信装置。
【請求項２】
前記送信データが送信可能である場合に送信可能であることを示す前記判定情報を生成し、前記送信データが送信可能でない場合に送信可能でないことを示す前記判定情報を生成する生成部をさらに備え、
前記第２送信部は、生成された前記判定情報を前記受信装置に送信する、
請求項１に記載の送信装置。
【請求項３】
前記第１送信部は、前記送信データの送信を開始する前に前記識別情報を前記受信装置に送信する、
請求項１に記載の送信装置。
【請求項４】
前記第１送信部は、前記判定情報を対応づけた前記識別情報を前記受信装置に送信する、
請求項１に記載の送信装置。
【請求項５】
前記第１送信部は、送信対象である前記送信データを識別するための前記識別情報を含む配信リストを前記受信装置に送信する、
請求項１に記載の送信装置。
【請求項６】
前記第１送信部は、複数の送信データを識別するための複数の識別情報を送信し、
複数の前記送信データは、時間的な順序が定められた時系列データである、
請求項１に記載の送信装置。
【請求項７】
前記判定情報に基づいて送信を要求すると判定された前記送信データの送信要求を前記受信装置から受信する要求受信部と、
前記送信要求により要求された前記送信データを前記受信装置に送信する第３送信部と、をさらに備える、
請求項１に記載の送信装置。
【請求項８】
１以上の送信データそれぞれを識別するための１以上の識別情報を送信装置から受信する第１受信部と、
前記識別情報で識別される前記送信データの送信を要求するか否かを判定するための判定情報を前記送信装置から受信する第２受信部と、
前記送信データのうち送信を要求する前記送信データを、前記判定情報に基づいて判定する判定部と、
を備える受信装置。
【請求項９】
前記第１受信部は、前記送信装置が前記送信データの送信を開始する前に前記識別情報を前記送信装置から受信する、
請求項８に記載の受信装置。
【請求項１０】
前記第１受信部は、前記判定情報を対応づけた前記識別情報を前記送信装置から受信する、
請求項８に記載の受信装置。
【請求項１１】
前記第１受信部は、送信対象である前記送信データを識別するための前記識別情報を含む配信リストを前記送信装置から受信する、
請求項８に記載の受信装置。
【請求項１２】
前記第１受信部は、複数の送信データを識別するための複数の識別情報を受信し、
複数の前記送信データは、時間的な順序が定められた時系列データである、
請求項８に記載の受信装置。
【請求項１３】
送信を要求すると判定された前記送信データの送信要求を送信する要求送信部と、
前記送信要求に応じて送信された前記送信データを受信する第３受信部と、をさらに備える、
請求項８に記載の受信装置。
【請求項１４】
送信装置と受信装置とを備える通信システムであって、
前記送信装置は、
１以上の送信データそれぞれを識別するための１以上の識別情報を受信装置に送信する第１送信部と、
前記識別情報で識別される前記送信データの送信を要求するか否かを判定するための判定情報を前記受信装置に送信する第２送信部と、を備え、
前記受信装置は、
１以上の送信データそれぞれを識別するための１以上の識別情報を送信装置から受信する第１受信部と、
前記識別情報で識別される前記送信データの送信を要求するか否かを判定するための判定情報を前記送信装置から受信する第２受信部と、
前記送信データのうち送信を要求する前記送信データを、前記判定情報に基づいて判定する判定部と、を備える、
通信システム。
【請求項１５】
コンピュータを、
１以上の送信データそれぞれを識別するための１以上の識別情報を受信装置に送信する第１送信部と、
前記識別情報で識別される前記送信データの送信を要求するか否かを判定するための判定情報を前記受信装置に送信する第２送信部と、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、送信装置、受信装置、通信システムおよびプログラムに関する。
【背景技術】
【０００２】
ＨＬＳ（HTTP  Live  Streaming）およびＭＰＥＧ−ＤＡＳＨ（Moving  Picture  Experts  Group−Dynamic  Adaptive  Streaming  over  HTTP）などのアダプティブストリーミングでは、コンテンツ配信者が、配信するコンテンツ（コンテンツ群）に関する配信リスト（コンテンツ配信リスト）を生成し、コンテンツ取得者に対して配信リストを配信する。通常、コンテンツ配信者は、配信リストにコンテンツの取得先やビットレート等のメタデータを記載する。コンテンツ取得者は、配信リストを取得し、解析することで、取得するコンテンツを特定することができる。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】R.  Pantos  et  al.、"RFC  8216、  HTTP  Live  Streaming"、［online］、August  2017、retrieved  from  the  Internet:  <URL:http://www.ietf.org/rfc/rfc8216.txt>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来技術では、コンテンツ配信者が配信リストのような配信対象を示す情報を更新した場合、コンテンツ取得者は更新された情報を効率的に特定することができない場合があった。
【課題を解決するための手段】
【０００５】
実施形態の送信装置は、第１送信部と、第２送信部と、を備える。第１送信部は、１以上の送信データそれぞれを識別するための１以上の識別情報を受信装置に送信する。第２送信部は、識別情報で識別される送信データの送信を要求するか否かを判定するための判定情報を受信装置に送信する。
【図面の簡単な説明】
【０００６】
【図１】実施形態の通信システムの全体構成図。
【図２】配信サーバおよびクライアントの機能ブロック図。
【図３】配信リストのデータ構造の一例を示す図。
【図４】判定情報のデータ構造の一例を示す図。
【図５】本実施形態におけるリスト生成処理のフローチャート。
【図６】本実施形態における判定情報生成処理のフローチャート。
【図７】本実施形態におけるコンテンツ配信処理のシーケンス図。
【図８】配信リストに対して判定情報を用いて判定する例を説明する図。
【図９】更新した判定情報の一例を示す図。
【図１０】配信リストに対して判定情報を用いて判定する例を説明する図。
【図１１】変形例１の配信リストのデータ構造、および、判定例を説明する図。
【図１２】配信リストに対して判定情報を用いて判定する例を説明する図。
【図１３】一部の判定情報のみを送信して判定する例を説明する図。
【図１４】一部の配信リストのみを送信して判定する例を説明する図。
【図１５】実施形態にかかる装置のハードウェア構成図。
【発明を実施するための形態】
【０００７】
以下に添付図面を参照して、この発明にかかる通信システムの好適な実施形態を詳細に説明する。なお、以下では、動画像データなどのコンテンツ（送信データの一例）を配信する配信サーバ（送信装置の一例）、および、コンテンツを受信するクライアント（受信装置の一例）を含む通信システムを例に説明する。適用可能な通信システムはこれに限られるものではなく、どのような送信データを送信および受信する通信システムであってもよい。
【０００８】
上記のように、コンテンツ配信者が配信リストの情報を更新した場合、コンテンツ取得者は更新箇所を効率的に特定することができない場合がある。例えばコンテンツ取得者が最新の配信リストを得るためには、コンテンツ配信者から配信リストを再度取得し、再解析しなければならず、無駄な処理が生ずる。
【０００９】
配信リストを更新する例として、送信予定の複数のコンテンツのうち一部のコンテンツが、送信できない状態から送信可能な状態に変化した場合が挙げられる。例えば、動画像データ全体のうち、途中の動画像データが何らかの理由により送信できない状態であったが、その後送信できる状態に変化した場合が該当する。
【００１０】
このような場合に配信リストを更新する方法として、コンテンツ配信者が配信リストの途中部分に新たな更新情報を追加して更新する方法が考えられる。コンテンツ取得者は、冒頭から配信リストを部分的に再取得し、再解析し、追加された更新部分が特定できるまで、部分的な再取得と再解析を繰り返す。しかし、例えば既に解析済みの部分が新たに更新された場合、配信リスト上での記載位置が変わるため、コンテンツ取得者は、再度冒頭から部分的に再取得と再解析をやりなおす必要があり、無駄な処理が生ずる。
【００１１】
配信リストを更新する他の方法として、コンテンツ配信者が配信リストの末尾に新たな更新情報を追加する方法が考えられる。コンテンツ取得者は、配信リストの取得済み箇所以降の差分のみを取得すれば、配信リストの更新情報のみを得ることができる。しかし、更新部分の解析結果と既に解析済みの情報との合併処理が生ずるため、非効率的である。
【００１２】
本実施形態にかかる送信装置は、更新される可能性がある情報に関連づけられるコンテンツも含む配信リスト、および、コンテンツが送信可能かを判定するための判定情報を生成し、受信装置に送信する。受信装置は、送信装置から得られる配信リストおよび判定情報を用いて、送信を要求するコンテンツを判定する。情報の更新があった場合、送信装置は、判定情報を再度生成し、受信装置に送信する。
【００１３】
このような構成により、例えば、更新があるごとに配信リストを送信する必要がなくなる。また、判定情報を参照すれば、更新箇所をより容易に解析することができる。すなわち、配信リストを再取得および再解析することなく、最新の配信リストと同等の情報を効率的に取得および解析可能となる。
【００１４】
ここで、本実施形態を適用できる送信データの例について説明する。送信データは、例えば、動画像データおよびセンサデータなどの、時間的な順序が定められた時系列データを含む。
【００１５】
動画像データは、例えばカメラなどの撮像装置により撮像されるデータである。動画像データは、例えば撮像装置からリアルタイムに取得され、配信対象のコンテンツとして使用される。撮像された後、一旦記憶媒体に記憶された動画像データが、配信対象のコンテンツとして使用されてもよい。
【００１６】
センサデータとは、センサ（検知装置）が検知した値を示すデータであり、例えばデータを検知した時刻の情報を含む。センサはどのような装置であってもよい。例えば、検知対象となる電子機器の温度、速度、圧力などを、定期的に、または、不定期に検知してセンサデータとして出力するセンサを使用することができる。
【００１７】
配信リストに記載する送信データ（コンテンツ）の単位は、どのような単位であってもよい。動画像データを配信する場合、任意の期間、または、一定期間で区切られた動画像データを単位としてもよい。１または複数のフレームなどの、予め定められたコンテンツの塊（チャンク）を単位としてコンテンツを配信リストに記載してもよい。センサデータを配信する場合、各時刻のセンサデータを単位としてもよいし、１以上の時刻を含む任意の期間、または、一定期間で区切られたセンサデータを単位としてもよい。
【００１８】
時系列データを配信する構成では、何らかの原因により、途中のデータが配信対象にできなくなる（データの抜けが発生する）場合が生じうる。例えば、撮像装置が撮像する動画像データを取得しつつ配信する構成では、送信装置と撮像装置との間の通信が一時的に途絶えることにより、途中のデータが取得できず、すぐに配信できない状況が生じうる。なお通信接続が回復すれば、取得できなかった途中のデータを取得することが可能である。例えば巻き戻し再生の指示があった場合に、取得した途中のデータを含むすべての動画像データを再生するように構成することができる。
【００１９】
本実施形態では、このような場合にも、途中のデータを含む配信リストを事前に送信し、さらに、送信データが送信可能かを判定するための判定情報を送信する。これにより、例えば途中のデータが取得できたときに配信リストを再送信する必要は生じない。
【００２０】
送信データは、時系列データに限られるものではない。配信対象となる送信データ全体が事前に把握できるが、そのうちの一部が配信対象にできなくなる（データの抜けが発生する）ようなデータに対しても、本実施形態を適用できる。
【００２１】
例えば、送信装置に対して複数の送信データをアップロードし、これらの送信データをさらに別の受信装置に配信する場合にも適用できる。複数の送信データのアップロードを指示した時点で、配信対象となる送信データ全体は把握できる。一方、アップロードのための通信の状況等によって、一部の送信データのアップロードが他の送信データと比較して遅れる場合がある。
【００２２】
本実施形態では、このような場合にも、例えばアップロードが完了したか否かに関わらず、すべての送信データを含む配信リストを送信し、さらに、送信データが送信可能か（アップロードした送信データの配信を受けられるか）を判定するための判定情報を送信することができる。これにより、送信データの配信を受ける受信装置は、いずれの送信データの配信を受けられるかを判定可能となる。また、例えばアップロードが完了したときに配信リストを再送信する必要は生じない。
【００２３】
送信データは、取得済みのデータである必要はなく、例えば今後取得される予定のデータ（未来のデータ）であってもよい。配信リストには、未来の時刻（時刻の範囲）などにより、配信対象となる送信データを指定すればよい。この場合、例えば、指定した時刻となり、送信データが取得されたときに、送信データが送信可能になったことを示す判定情報が生成される。
【００２４】
図１は、本実施形態の通信システムの全体構成の一例を示す図である。図１に示すように、本実施形態の通信システムは、送信装置としての配信サーバ１００と、受信装置としてのクライアント２００と、を備えている。配信サーバ１００とクライアント２００は、インターネット等のネットワーク３００を介して相互に接続されている。
【００２５】
配信サーバ１００は、配信リストおよび判定情報を、ネットワーク３００を介して配信する。配信リストに記載されるコンテンツは、送信可能な状態のコンテンツのみではなく、送信できない状態のコンテンツ、および、送信を許可しないコンテンツなどを含みうる。判定情報は、配信リストに含まれるコンテンツの送信を要求するか否かを受信装置（クライアント２００）が判定するための情報である。
【００２６】
クライアント２００は、配信サーバ１００から配信リストと判定情報を受信し、判定情報を用いて配信リストを解析することにより、コンテンツの配信を受けるために必要な情報を得る。
【００２７】
図１に示す通信システムの構成は一例であり、これに限られるものではない。例えば配信サーバ１００、および、クライアント２００は、それぞれ複数備えられていてもよい。配信サーバ１００により配信するコンテンツを提供する１以上のコンテンツ提供装置（例えば画像データを提供する撮像装置）がさらに備えられてもよい。また、配信サーバ１００およびクライアント２００それぞれは、物理的に１つの装置によって構成されてもよいし、物理的に複数の装置によって構成されてもよい。例えば配信サーバ１００は、クラウド環境上で構築されてもよい。
【００２８】
図２は、配信サーバ１００およびクライアント２００の機能構成の一例を示すブロック図である。図２に示すように、配信サーバ１００は、検出部１０１と、リスト生成部１１１と、判定情報生成部１１２と、リスト送信部１１３（第１送信部）と、判定情報送信部１１４（第２送信部）と、要求受信部１１５と、コンテンツ送信部１１６（第３送信部）と、記憶部１２１と、を備えている。
【００２９】
検出部１０１は、コンテンツが送信可能になったことを検出する。例えば検出部１０１は、コンテンツを提供する提供装置からコンテンツが提供された場合に、コンテンツが送信可能になったと判断する。検出部１０１は、コンテンツが記憶される記憶領域（例えば記憶部１２１）を監視し、コンテンツが記憶された場合に、コンテンツが送信可能になったと判断してもよい。
【００３０】
リスト生成部１１１は、配信リストを生成する。リスト生成部１１１は、例えば、配信リストを生成して送信することをクライアント２００から要求されたときに、配信リストを生成する。配信リストの生成の契機はこれに限られず、どのような契機であってもよい。例えばリスト生成部１１１は、一定時間が経過するごとに、次の期間に送信するコンテンツの配信リストを生成してもよい。リスト生成部１１１は、提供装置からコンテンツが提供されたとき、または、生成を指示されたときなどに配信リストを生成してもよい。
【００３１】
図３は、配信リストのデータ構造の一例を示す図である。図３に示すように、配信リストは、コンテンツを識別する識別情報を含む。図３は、コンテンツのＵＲＬ（Uniform  Resource  Locator）を識別情報として利用する例を示している。識別情報は、コンテンツを識別できればＵＲＬ以外の情報を用いてもよい。配信リストは、識別情報以外の情報を含んでもよい。
【００３２】
図２に戻り、判定情報生成部１１２は、判定情報を生成する。例えば判定情報生成部１１２は、コンテンツが送信可能である場合に送信可能であることを示す判定情報を生成し、コンテンツが送信可能でない場合に送信可能でないことを示す判定情報を生成する。また判定情報生成部１１２は、コンテンツが送信可能であるか否かを示す状況が変化した場合に、変化した後の状況に対応するように更新した判定情報を生成する。
【００３３】
判定情報生成部１１２は、例えば、判定情報を生成して送信することをクライアント２００から要求されたときに、判定情報を生成する。リスト生成部１１１により配信リストが生成されたときに、その時点での判定情報を判定情報生成部１１２が生成してもよい。判定情報の生成の契機はこれに限られず、どのような契機であってもよい。例えば判定情報生成部１１２は、一定時間が経過するごとに、例えば検出部１０１を用いてコンテンツが送信可能になったか否かを検出し、検出結果に応じて更新した判定情報を生成してもよい。
【００３４】
図４は、判定情報のデータ構造の一例を示す図である。図４の判定情報は、図３の配信リストに記載された４つのコンテンツが送信可能かを判定するための判定情報の例である。例えば「○」は、コンテンツが送信可能であることを示し、「×」は、コンテンツが送信可能でないことを示す。図４の例では、図３の４つのＵＲＬに対応する４つのコンテンツ（“ＣｏｎｔｅｎｔＡ＿１”、“ＣｏｎｔｅｎｔＡ＿２”、“ＣｏｎｔｅｎｔＡ＿３”、“ＣｏｎｔｅｎｔＡ＿４”）に対応する４つの判定情報（「○」または「×」）が対応する順序で指定されている。
【００３５】
コンテンツごとに判定情報を指定できる方法であれば、図４以外のデータ構造の判定情報を用いてもよい。例えば、コンテンツの識別情報を判定情報に対応づけてもよい。いずれの配信リストに対応する判定情報であるかを識別可能とするために、配信リストを識別するための情報を判定情報に対応づけてもよい。
【００３６】
コンテンツが送信可能であるとは、例えば、配信対象となるコンテンツが配信サーバ１００に提供されており、クライアント２００に対して送信できる状態である。コンテンツが送信可能でないとは、例えば、配信対象となるコンテンツが配信サーバ１００にまだ提供されておらず、クライアント２００に対して送信できない状態である。なお配信サーバ１００は、クライアント２００からの要求に応じてコンテンツを送信（プル型送信）してもよいし、クライアント２００からの要求なしにコンテンツを送信（プッシュ型送信）してもよい。
【００３７】
コンテンツが提供されているか否かに関わらず、配信サーバ１００が、コンテンツを送信可能であるか否かを指定してもよい。例えば、通信負荷を軽減させるために、提供された複数のコンテンツのうち一部または全部に対して、送信可能でないことを示す判定情報を生成し、これらのコンテンツを送信できないように構成してもよい。このように、送信可能であるコンテンツが、その後、送信可能でなくなる場合がありうる。
【００３８】
判定情報は、コンテンツごとに１つであってもよいし、複数であってもよい。例えば、コンテンツの１以上のメタデータを判定情報として使用してもよい。メタデータは、例えば、コンテンツの範囲を示す範囲情報、コンテンツのデータ長、および、コンテンツの種類などである。範囲情報は、例えば、あるデータのうち、コンテンツとして配信するデータの範囲を指定する情報である。範囲情報が確定している場合には、確定した範囲情報を判定情報として設定し、未確定の場合には、未確定であることを示す予め定められた情報（未確定情報）を判定情報として設定する。クライアント２００は、判定情報としての範囲情報に未確定情報が設定されていた場合に、対応するコンテンツが送信可能でないと判定できる。このように、メタデータを判定情報として使用する場合は、メタデータによりコンテンツが送信可能か否かを判定できるようなデータ形式を定めておけばよい。
【００３９】
図２に戻り、リスト送信部１１３は、リスト生成部１１１により生成された配信リストをクライアント２００に送信する。例えばリスト送信部１１３は、コンテンツの送信を開始する前に、事前に配信リストをクライアント２００に送信する。判定情報送信部１１４は、判定情報生成部１１２により生成された判定情報をクライアント２００に送信する。
【００４０】
要求受信部１１５は、各種要求をクライアント２００から受信する。例えば要求受信部１１５は、配信リストの送信要求、判定情報の送信要求、および、コンテンツの送信要求をクライアント２００から受信する。
【００４１】
コンテンツ送信部１１６は、要求されたコンテンツを、送信要求を送信したクライアント２００に送信する。プッシュ型送信を採用する場合、コンテンツ送信部１１６は、クライアント２００からの要求なしにコンテンツを送信してもよい。
【００４２】
記憶部１２１は、配信サーバ１００が使用する各種データを記憶する。例えば記憶部１２１は、配信対象となるコンテンツ、生成された配信リスト、および、生成された判定情報を記憶する。
【００４３】
上記各部（検出部１０１、リスト生成部１１１、判定情報生成部１１２、リスト送信部１１３、判定情報送信部１１４、要求受信部１１５、および、コンテンツ送信部１１６）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵ（Central  Processing  Unit）などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣ（Integrated  Circuit）などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。
【００４４】
なお配信サーバ１００の各機能は、物理的または論理的に異なる複数の装置に分散されてもよい。例えば、配信リストを送信するサーバ装置と、コンテンツを送信するサーバ装置とに分けられてもよい。
【００４５】
次にクライアント２００の機能について説明する。図２に示すように、クライアント２００は、リスト受信部２１１（第１受信部）と、判定情報受信部２１２（第２受信部）と、判定部２１３と、要求送信部２１４と、コンテンツ受信部２１５（第３受信部）と、再生部２１６と、記憶部２２１と、を備えている。
【００４６】
リスト受信部２１１は、配信リストを配信サーバ１００から受信する。判定情報受信部２１２は、判定情報を配信サーバ１００から受信する。
【００４７】
判定部２１３は、配信リストおよび判定情報に基づいて、送信を要求するコンテンツを判定する。例えば判定部２１３は、図３に示す配信リストにＵＲＬが記載されたコンテンツのうち、図４のように判定情報として「○」が設定されたコンテンツを、送信を要求するコンテンツとして判定する。判定情報として上述の範囲情報を用いる場合、判定部２１３は、例えば、範囲情報に未確定情報が設定されていないコンテンツを、送信を要求するコンテンツと判定する。複数の判定情報を用いる場合、判定部２１３は、複数の判定情報の組み合わせに応じて、送信を要求するコンテンツを判定してもよい。例えば判定部２１３は、すべての判定情報がコンテンツを送信可能であることを示す場合に、対応するコンテンツを、送信を要求するコンテンツと判定する。
【００４８】
要求送信部２１４は、送信を要求すると判定されたコンテンツの送信要求を配信サーバ１００に送信する。コンテンツ受信部２１５は、要求送信部２１４により送信した送信要求に応じて送信されたコンテンツを配信サーバ１００から受信する。再生部２１６は、受信されたコンテンツを再生する。
【００４９】
記憶部２２１は、クライアント２００が使用する各種データを記憶する。例えば記憶部２２１は、送信された配信リスト、送信された判定情報、および、配信されたコンテンツを記憶する。
【００５０】
上記各部（リスト受信部２１１、判定情報受信部２１２、判定部２１３、要求送信部２１４、コンテンツ受信部２１５、および、再生部２１６）は、例えば、１または複数のプロセッサにより実現される。例えば上記各部は、ＣＰＵなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のＩＣなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち１つを実現してもよいし、各部のうち２以上を実現してもよい。
【００５１】
また記憶部（記憶部１２１、２２１）は、ＨＤＤ（Hard  Disk  Drive）、光ディスク、メモリカード、ＲＡＭ（Random  Access  Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。記憶部のそれぞれは、物理的に異なる複数の記憶媒体により実現してもよい。
【００５２】
次に、このように構成された本実施形態にかかる配信サーバ１００によるリスト生成処理について説明する。リスト生成処理は、配信サーバ１００が配信リストを生成する処理である。図５は、本実施形態におけるリスト生成処理の一例を示すフローチャートである。
【００５３】
配信サーバ１００のリスト生成部１１１は、例えばクライアント２００からの要求に応じて、配信リストを生成する（ステップＳ１０１）。リスト生成部１１１は、生成した配信リストを例えば記憶部１２１に記憶する（ステップＳ１０２）。
【００５４】
一例として、時間的に連続したコンテンツであるＣｏｎｔｅｎｔＡ＿１、ＣｏｎｔｅｎｔＡ＿２、ＣｏｎｔｅｎｔＡ＿３、およびＣｏｎｔｅｎｔＡ＿４が配信予定のコンテンツとして存在し、ＣｏｎｔｅｎｔＡ＿１とＣｏｎｔｅｎｔＡ＿３が配信可能であるとする。この場合、リスト生成部１１１は、ＣｏｎｔｅｎｔＡ＿１、ＣｏｎｔｅｎｔＡ＿２、ＣｏｎｔｅｎｔＡ＿３、およびＣｏｎｔｅｎｔＡ＿４を配信するための配信リストを生成する。上述の図３は、このときに生成される配信リストの一例を示す。
【００５５】
次に、本実施形態にかかる配信サーバ１００による判定情報生成処理について説明する。判定情報生成処理は、配信サーバ１００が判定情報を生成する処理である。判定情報生成処理は、例えばクライアント２００から判定情報の送信要求があった場合に実行される。図６は、本実施形態における判定情報生成処理の一例を示すフローチャートである。
【００５６】
配信サーバ１００の判定情報生成部１１２は、配信予定のコンテンツについて、判定情報を生成済みであるか否かを判定する（ステップＳ２０１）。判定情報を生成済みでない場合（ステップＳ２０１：Ｎｏ）、判定情報生成部１１２は、当該コンテンツについての判定情報を生成する（ステップＳ２０２）。上述の図４は、図５で説明した例（ＣｏｎｔｅｎｔＡ＿１とＣｏｎｔｅｎｔＡ＿３が配信可能である例）に対して生成される判定情報の一例を示す。
【００５７】
判定情報を生成した後、および、判定情報を生成済みの場合（ステップＳ２０１：Ｙｅｓ）、判定情報生成部１１２は、生成済みの判定情報を更新するか否かを判定する（ステップＳ２０３）。例えば判定情報生成部１１２は、検出部１０１からコンテンツが送信可能になったことを示す検出結果を受け取った場合に、判定情報を更新すると判定する。
【００５８】
判定情報を更新すると判定した場合（ステップＳ２０３：Ｙｅｓ）、判定情報生成部１１２は、判定情報を更新する（ステップＳ２０４）。判定情報を更新した後、および、判定情報を更新しないと判定した場合（ステップＳ２０３：Ｎｏ）、判定情報生成処理を終了する。
【００５９】
配信サーバ１００は、生成した配信リストおよび判定情報を、ネットワーク３００を介して配信可能な状態にする。クライアント２００は、配信サーバ１００にアクセスして配信リストおよび判定情報を取得することが可能となる。
【００６０】
次に、本実施形態にかかる通信システムによるコンテンツ配信処理について説明する。図７は、本実施形態におけるコンテンツ配信処理の一例を示すシーケンス図である。
【００６１】
配信サーバ１００のリスト生成部１１１は、配信リストを生成する（ステップＳ３０１）。この処理は、例えば上述のリスト生成処理に相当する。配信サーバ１００のリスト送信部１１３は、例えばクライアント２００からの要求に応じて、配信リストをクライアント２００に送信する（ステップＳ３０２）。
【００６２】
配信サーバ１００の判定情報生成部１１２は、判定情報を生成する（ステップＳ３０３）。この処理は、例えば上述の判定情報生成処理に相当する。配信サーバ１００の判定情報送信部１１４は、例えばクライアント２００からの要求に応じて、判定情報をクライアント２００に送信する（ステップＳ３０４）。
【００６３】
クライアント２００のリスト受信部２１１が配信リストを受信し、判定情報受信部２１２が判定情報を受信する。その後、クライアント２００の判定部２１３は、受信した配信リストおよび判定情報を用いて、送信を要求するコンテンツを判定する（ステップＳ３０５）。例えば図３に示す配信リストを受信した場合、判定部２１３は、受信した配信リストを解析することで、ＣｏｎｔｅｎｔＡ＿１〜ＣｏｎｔｅｎｔＡ＿４をそれぞれ取得するためのＵＲＬを得る。また判定部２１３は、受信した判定情報を解析し、配信リストに記載されたコンテンツのうち、送信可能なコンテンツを判定する。
【００６４】
図８は、図３に示す配信リストに対して図４に示す判定情報を用いて判定する例を説明する図である。図８に示すように、配信リストに記載のＣｏｎｔｅｎｔＡ＿１を取得するためのＵＲＬと、ＣｏｎｔｅｎｔＡ＿１に対応する判定情報とを組み合わせることで、判定部２１３は、ＣｏｎｔｅｎｔＡ＿１が送信可能（アクセス可能）であると判定できる。同様に判定部２１３は、ＣｏｎｔｅｎｔＡ＿２が送信不可（アクセス不可）であると判定できる。
【００６５】
図７に戻り、要求送信部２１４は、送信を要求すると判定されたコンテンツの送信要求を、配信サーバ１００に送信する（ステップＳ３０６）。配信サーバ１００のコンテンツ送信部１１６は、要求されたコンテンツをクライアント２００に送信する（ステップＳ３０７）。クライアント２００のコンテンツ受信部２１５がコンテンツを受信し、再生部２１６が、受信したコンテンツを再生する（ステップＳ３０８）。
【００６６】
この後、ＣｏｎｔｅｎｔＡ＿２が配信可能な状態となったとする。このとき、配信サーバ１００の検出部１０１は、ＣｏｎｔｅｎｔＡ＿２が配信可能な状態となったことを検出する。判定情報生成部１１２は、検出結果に応じて更新した判定情報を生成する（ステップＳ３０９）。
【００６７】
図９は、更新した判定情報の一例を示す図である。判定情報生成部１１２は、図９に示すように、ＣｏｎｔｅｎｔＡ＿２に対応する判定情報を「×」から「○」に更新する。更新された判定情報は、ネットワーク３００を介して配信可能な状態にされる。
【００６８】
図７に戻り、配信サーバ１００の判定情報送信部１１４は、例えばクライアント２００からの要求に応じて、更新された判定情報をクライアント２００に送信する（ステップＳ３１０）。この後のステップＳ３１１からステップＳ３１４は、ステップＳ３０５からステップＳ３０８と同様である。
【００６９】
図１０は、図３に示す配信リストに対して図９に示す判定情報を用いて判定する例を説明する図である。図１０に示すように、判定部２１３は、ＣｏｎｔｅｎｔＡ＿２が送信可能（アクセス可能）な状態になったことを判定できる。
【００７０】
このようにクライアント２００は、ＣｏｎｔｅｎｔＡ＿２が配信可能な状態となったときに、配信リストを再取得することなく、既に受信済みの配信リストに対して、更新された判定情報を適用するのみで、各コンテンツの最新の状態を得ることが可能となる。
【００７１】
以上のように、本実施形態にかかる通信システムでは、配信対象を示す情報（配信リスト）を再取得および再解析することなく、最新の配信リストと同等の情報を効率的に取得および解析可能となる。
【００７２】
（変形例１）
配信リストは、配信リストを生成した時点での判定情報を含んでもよい。例えば、リスト生成部１１１は、ＵＲＬなどのコンテンツの識別情報ごとに判定情報を対応づけた配信リストを生成してもよい。
【００７３】
図１１は、変形例１の配信リストのデータ構造、および、この配信リストを用いて判定する例を説明する図である。図１１の例では、各ＵＲＬの右に付与された「＋」および「−」の符号が判定情報を示す。例えば「＋」は、コンテンツが送信可能であることを示し、「−」は、コンテンツが送信可能でないことを示す。このような構成によれば、クライアント２００は、最初に受信した配信リストのみから、その時点で送信可能なコンテンツを判定可能となる。
【００７４】
判定情報が更新された場合は、上記実施形態と同様の手法により、更新された判定情報が生成され、クライアント２００に送信される。
【００７５】
図１２は、図１１に示す配信リストに対して、更新された判定情報を用いて判定する例を説明する図である。図１２は、ＣｏｎｔｅｎｔＡ＿２が配信可能な状態に変化した場合の例を示す。クライアント２００の判定部２１３は、最初に受信した配信リストと、更新された判定情報とから、ＣｏｎｔｅｎｔＡ＿２が送信可能（アクセス可能）な状態になったことを判定できる。
【００７６】
（変形例２）
判定情報は、配信リストに記載されたコンテンツすべてに対して送信する必要はなく、一部のコンテンツに対する判定情報のみを送信してもよい。例えば判定情報生成部１１２が、クライアント２００から要求されたコンテンツに対する判定情報のみを生成し、判定情報送信部１１４が生成された判定情報をクライアント２００に送信してもよい。判定情報送信部１１４が、生成済みの判定情報のうち、クライアント２００から要求された判定情報のみを送信してもよい。
【００７７】
図１３は、一部の判定情報のみを送信して判定する例を説明する図である。図１３は、ＣｏｎｔｅｎｔＡ＿１およびＣｏｎｔｅｎｔＡ＿２の判定情報のみが送信される例を示す。いずれのコンテンツに対応する判定情報を送信するかは、例えばクライアント２００から、送信を要求するコンテンツの識別情報（ＵＲＬなど）を送信することにより決定することができる。
【００７８】
なお、図１３は、変形例１の配信リストを用いた例を示しているが、上記実施形態の配信リスト（図４）に対しても変形例２を適用できる。
【００７９】
（変形例３）
配信リストについても、配信リスト全体を送信せずに、配信リストのうち一部を送信するように構成してもよい。例えば、リスト送信部１１３が、生成済みの配信リストのうち、クライアント２００から要求された部分の配信リストのみを送信してもよい。
【００８０】
図１４は、一部の配信リストのみを送信して判定する例を説明する図である。図１４は、ＣｏｎｔｅｎｔＡ＿１からＣｏｎｔｅｎｔＡ＿４を含む配信リストのうち、ＣｏｎｔｅｎｔＡ＿２およびＣｏｎｔｅｎｔＡ＿３のみを含む配信リストが送信される例を示す。
【００８１】
例えばクライアント２００は、配信リストに記載するコンテンツを特定できる情報を含む要求を、配信サーバ１００に送信する。コンテンツを特定できる情報は、例えば、時系列データであるコンテンツのうち、配信を希望する箇所の開始時間および終了時間を特定する情報である。配信サーバ１００は、このような情報を参照して配信リストに記載するコンテンツの識別情報を決定し、決定した識別情報を含む配信リストを生成する。
【００８２】
なお、図１４は、上記実施形態の配信リスト（図４）を用いた例を示しているが、変形例１の配信リスト（図１１）に対しても変形例３を適用できる。
【００８３】
次に、上記実施形態にかかる各装置（配信サーバ、クライアント）のハードウェア構成について図１５を用いて説明する。図１５は、上記実施形態にかかる装置のハードウェア構成例を示す説明図である。
【００８４】
上記実施形態にかかる装置は、ＣＰＵ５１などの制御装置と、ＲＯＭ（Read  Only  Memory）５２やＲＡＭ（Random  Access  Memory）５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。
【００８５】
上記実施形態にかかる装置で実行されるプログラムは、ＲＯＭ５２等に予め組み込まれて提供される。
【００８６】
上記実施形態にかかる装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact  Disk  Read  Only  Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact  Disk  Recordable）、ＤＶＤ（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
【００８７】
さらに、上記実施形態にかかる装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上記実施形態にかかる装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【００８８】
上記実施形態にかかる装置で実行されるプログラムは、コンピュータを上述した装置の各部として機能させうる。このコンピュータは、ＣＰＵ５１がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
【００８９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９０】
１００  配信サーバ
１０１  検出部
１１１  リスト生成部
１１２  判定情報生成部
１１３  リスト送信部
１１４  判定情報送信部
１１５  要求受信部
１１６  コンテンツ送信部
１２１  記憶部
２００  クライアント
２１１  リスト受信部
２１２  判定情報受信部
２１３  判定部
２１４  要求送信部
２１５  コンテンツ受信部
２１６  再生部
２２１  記憶部
３００  ネットワーク
【図１】
2019092133.tif 000003
【図２】
2019092133.tif 000004
【図３】
2019092133.tif 000005
【図４】
2019092133.tif 000006
【図５】
2019092133.tif 000007
【図６】
2019092133.tif 000008
【図７】
2019092133.tif 000009
【図８】
2019092133.tif 000010
【図９】
2019092133.tif 000011
【図１０】
2019092133.tif 000012
【図１１】
2019092133.tif 000013
【図１２】
2019092133.tif 000014
【図１３】
2019092133.tif 000015
【図１４】
2019092133.tif 000016
【図１５】
2019092133.tif 000017