JP2004312412A - コンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラム - Google Patents

Abstract

【課題】チューナ受信コンテンツのサーバからクライアントに対するライブストリーム配信の改善された制御処理を可能とする装置および方法を提供する。
【解決手段】チャンネルの集合体としてのチャンネルリストにＵＲＬを設定し、クライアントが、チャンネルリストＵＲＬを指定したコンテンツ要求をサーバに送信することで、クライアントは、チャンネルリストにリストアップされたチャンネルコンテンツの取得、すなわちチャンネルリストにリストアップされたチャンネル対応のコンテンツの制御権をまとめて得ることができ、チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したチャンネル切り替えが可能となる。
【選択図】 図６

Description

【０００１】
【発明の属する技術分野】
本発明は、コンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラムに関する。特に、サーバ／クライアントシステムで実行するストリーミングデータの配信および再生処理に適用するコンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラムに関する。
【０００２】
【従来の技術】
昨今のデータ通信ネットワークの普及に伴い、家庭内においても家電機器やコンピュータ、その他の周辺機器をネットワーク接続し、各機器間での通信を可能とした、いわゆるホームネットワークが浸透しつつある。ホームネットワークは、ネットワーク接続機器間で通信を行なうことにより各機器のデータ処理機能を共有することを可能とするものである。ネットワーク接続機器間のコンテンツ送受信等、ユーザに利便性・快適性を提供するものであり、今後、ますます普及することが予測される。
【０００３】
このようなホームネットワークの構成に適するプロトコルとしてユニバーサルプラグアンドプレイ（ＵＰｎＰ：Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）が知られている。ユニバーサルプラグアンドプレイ（ＵＰｎＰ）は、複雑な操作を伴うことなく容易にネットワークを構築することが可能であり、困難な操作や設定を伴うことなくネットワーク接続された機器において各接続機器の提供サービスを受領可能とするものである。また、ＵＰｎＰはデバイス上のＯＳ（オペレーティングシステム）にも依存せず、容易に機器の追加ができるという利点を持つ。
【０００４】
ＵＰｎＰは、接続機器間で、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）に準拠した定義ファイルを交換し、機器間において相互認識を行なう。ＵＰｎＰの処理の概要は、以下の通りである。
（１）ＩＰアドレス等の自己のデバイスＩＤを取得するアドレッシング処理。
（２）ネットワーク上の各デバイスの検索を行ない、各デバイスから応答を受信し、応答に含まれるデバイス種別、機能等の情報を取得するディスカバリ処理。
（３）ディスカバリ処理で取得した情報に基づいて、各デバイスにサービスを要求するサービス要求処理。
【０００５】
上記処理手順を行なうことで、ネットワーク接続された機器を適用したサービスの提供および受領が可能となる。ネットワークに新たに接続される機器は、上記のアドレッシング処理によりデバイスＩＤを取得し、ディスカバリ処理によりネットワーク接続された他のデバイスの情報を取得して、取得情報に基づいて他の機器にサービスの要求が可能となる。
【０００６】
例えばサーバに格納された音楽データ、画像データ等のコンテンツをクライアント側デバイスにおいて再生しようとする場合には、クライアントは、サーバの保有するコンテンツについての情報を取得する。サーバは、記憶部に格納したコンテンツや、チューナを介して外部から受信する様々なコンテンツに関するインフォメーションを含む属性情報を記憶部に格納しており、この情報をクライアントに提供する。属性情報には、例えばコンテンツとしての例えば曲や映画のタイトル、アーティスト名、記録日時、さらにデータの圧縮態様等に関する情報など様々である。これらの属性情報はメタデータあるいはメタ情報と呼ばれる。
【０００７】
クライアントは、サーバに対してサーバに格納されたコンテンツ情報、例えば曲や映画のタイトルやアーティスト名、さらにデータの圧縮態様情報（ＡＴＲＡＣ：ａｄａｐｔｉｖｅ ｔｒａｎｓｆｏｒｍ ａｃｏｕｓｔｉｃ ｃｏｄｉｎｇ， ＭＰＥＧ：ｍｏｖｉｎｇ ｐｉｃｔｕｒｅ ｅｘｐｅｒｔｓ ｇｒｏｕｐ等）、さらに必要に応じて著作権情報などの様々なコンテンツの属性情報の取得要求を行うことができる。
【０００８】
サーバは、クライアントからの要求に応じてサーバの保有するコンテンツに関するメタデータ（属性情報）をクライアントに送信する。クライアントは、サーバから取得したメタデータに基づいて所定の表示プログラムに従ってクライアントデバイスのディスプレイにコンテンツ情報を表示する。例えばアーティスト名、タイトル等からなる曲目リストなどがディスプレイに表示される。ユーザは、表示情報に基づいて、再生対象コンテンツを確認あるいは選択して、コンテンツの送信要求をサーバに送信する。サーバはクライアントからのコンテンツリクエストを受信し、受信リクエストに応じてサーバからクライアントに対するコンテンツの送信が行われ、クライアント側において受信コンテンツの再生が行われる。
【０００９】
このようにサーバに格納されたコンテンツは、ネットワーク接続された他の機器（クライアント）から検索を行い、特定のコンテンツを指定して再生することが可能となる。
【００１０】
また、コンテンツを提供するサーバにチューナ機能を併設し、チューナを介して受信したビデオまたはオーディオデータをクライアントに送信するいわゆるライブストリーミングデータの配信構成を持つサーバ構成が提案されている。例えば、地上波、衛星放送等、の各種のブロードキャストデータをホームサーバ内のチューナにおいて受信し、受信データをサーバからクライアント、例えばチューナを持たないＰＣ等に送信し、ユーザがＰＣに備えられたディスプレイ、スピーカを介して様々なＴＶ、ラジオ等の番組を視聴する構成である。
【００１１】
クライアントからサーバを遠隔操作し、サーバ内のチューナで受信したテレビジョンデータをローカルエリアネットワークを介してクライアント側で受信、再生するシステムについては、例えば特許文献１に記載されている。
【００１２】
ただし、特許文献１に記載の構成は、サーバ内のチューナで受信したデータをサーバ内の記憶手段、例えばＨＤＤに格納し、この格納データをクライアントに提供するものであり、いわゆるサーバ内の格納コンテンツのクライアントに対する提供と同様の処理をチューナ受信データに対して実行する仮想的なライブストリーミングを実現しているものである。
【００１３】
クライアントがサーバから特定のコンテンツを取得する場合の処理は、クライアントからサーバに対してコンテンツ識別子を送信し、サーバがクライアントからの受信識別子に基づいて指定コンテンツを取得して送信するという処理になる。
【００１４】
例えば、サーバがコンテンツに対応付けたコンテンツＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）をコンテンツ対応のメタデータとして保持し、クライアントがコンテンツＵＲＬを指定したＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）のＧＥＴメソッドを生成してサーバに送信することで、サーバが受信ＵＲＬに基づいて特定されるコンテンツをクライアントに送信することができる。
【００１５】
チューナを介して受信するデータを、上述したと同様のＵＲＬ指定に基づいてサーバからクライアントに送信する構成を想定すると、サーバは、チューナを介して受信する多数のチャンネル毎のデータに対応する多数のＵＲＬを設定し、クライアントが各チャンネルに対応するＵＲＬを指定したコンテンツ要求をサーバに送信することが必要となる。
【００１６】
しかし、このようなチャンネル毎のＵＲＬ設定構成では、クライアントがチャンネル切り替えを行おうとすると、切り替え後のチャンネルに対応したＵＲＬを設定したＨＴＴＰ−ＧＥＴメソッドをサーバに新たに送信することが必要となる。従って、サーバクライアント間では、切り替え前のＵＲＬに基づくコネクションを無効とし、新たなＵＲＬに基づくコネクションを新たに設定して、新規設定したコネクションに基づいて切り替え後のチャンネルのストリーミングデータの配信が行われることになる。
【００１７】
このように、チャンネル毎のＵＲＬ設定構成とした場合は、クライアントにおいてチャンネルを切り替える毎にサーバクライアント間において、コネクション設定を行うことが必要となり、双方の負荷が過大になる。さらに、チャンネル切り替え毎に通信の中断が発生することになり、通常のテレビリモコンを使用したチャンネル切り替えのようなスムーズな処理環境が得られないという問題がある。
【００１８】
また、複数のクライアントが１つのサーバから同一番組を受信して複数ユーザが視聴している環境においては、個々のユーザによるチャンネル切り替え毎に番組が中断してしまうといった問題が発生する。
【００１９】
【特許文献１】
特許公開２００２−８４４８４号公報
【００２０】
【発明が解決しようとする課題】
本発明は、上述の問題点に鑑みてなされたものであり、サーバとクライアント間において、クライアントからサーバに対する制御をスムーズにかつ効率的に実行することを可能とし、例えばサーバのチューナを介して受信したストリーミングデータをクライアントに提供し、クライアントがチャンネル切り替え等の制御を実行する場合においても、通信を中断することなくストリーミングデータの配信を継続して実行することを可能としたコンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラムを提供することを目的とする。
【００２１】
【課題を解決するための手段】
本発明の第１の側面は、
クライアントに対するコンテンツ送信処理を実行するコンテンツ提供サーバであり、
データ受信処理を実行するチューナと、
前記チューナによる受信コンテンツおよび制御情報のサーバクライアント間の通信処理を実行するデータ送受信部と、
コンテンツに対応する属性情報をコンテンツ情報として格納した記憶部と、
前記コンテンツ情報のクライアントに対する提供処理を実行するコンテンツ管理部と、
前記チューナを介した受信コンテンツのクライアントに対するライブストリーミング配信制御を実行するコンテンツ配信制御部とを有し、
前記記憶部は、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストの識別情報としてのチャンネルリスト識別子を、チューナ受信コンテンツに対応するコンテンツ情報として格納し、
前記コンテンツ配信制御部は、
前記チャンネルリストに記述された複数チャンネルに対応するチューナの受信する複数コンテンツを制御コンテンツの一単位として設定し、クライアントから受信するチャンネルリスト識別子に対応する制御要求に基づいて、前記チャンネルリストに記述された複数チャンネルに対応する配信コンテンツの制御を実行する構成であることを特徴とするコンテンツ提供サーバにある。
【００２２】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、前記記憶部は、前記チューナ受信コンテンツに対応する属性情報として前記チャンネルリストＵＲＬを格納し、前記コンテンツ配信制御部は、クライアントからの制御要求に従って前記チャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行する構成であることを特徴とする。
【００２３】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記コンテンツ配信制御部は、前記チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行する構成であることを特徴とする。
【００２４】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ情報には、コンテンツ対応のプロトコル情報が含まれ、前記チューナを介した受信コンテンツに対応して設定されるプロトコル情報には、チューナ識別情報としてのファンクションＩＤを含み、前記コンテンツ配信制御部は、チューナ受信コンテンツの制御を実行する制御インスタンスを、前記ファンクションＩＤに基づいて決定される制御対象チューナの制御を実行する制御インスタンスとして設定する処理を実行する構成であることを特徴とする。
【００２５】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ配信制御部は、配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記チューナ受信コンテンツの制御を実行するチューナ制御インスタンスは、クライアントからの制御要求に基づいて、前記チューナの制御を実行する構成であることを特徴とする。
【００２６】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ配信制御部は、配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記制御インスタンスの識別子としてのインスタンスＩＤと、サーバクライアント間のコネクション識別子であるコネクションＩＤと、配信コンテンツに対応するプロトコル情報とを対応付けたコネクション管理テーブルに基づくコネクション管理を実行する構成であることを特徴とする。
【００２７】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ配信制御部は、配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記制御インスタンスは、識別子としてのインスタンスＩＤを設定され、クライアントからの制御インスタンスＩＤを指定した制御要求に応じて、コンテンツ配信制御を実行する構成であることを特徴とする。
【００２８】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ配信制御部は、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルに従った配信コンテンツの制御要求をクライアントから受信し、該制御要求に基づいて、チューナ受信コンテンツの配信制御を実行する構成であることを特徴とする。
【００２９】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記チャンネルリストは、カテゴリ毎に区分された複数チャンネルからなるリストとして設定された構成であることを特徴とする。
【００３０】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記コンテンツ配信制御部は、前記チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行中に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドの受信に応じて、該チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行する構成であることを特徴とする。
【００３１】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記コンテンツ配信制御部は、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えにより、クライアントに対する送信符号化データの整合性の保持可能性を判定し、整合性が保持されないと判定した場合には、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションの切断を実行する構成であり、前記コンテンツ提供サーバは、さらに、サーバクライアント間のイベント通知コネクションを介してチャンネルリストＵＲＬに基づいて設定されたＨＴＴＰコネクションの切断情報を通知する処理を実行する構成を有することを特徴とする。
【００３２】
さらに、本発明のコンテンツ提供サーバの一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記コンテンツ配信制御部は、クライアントに対する送信符号化データの整合性の保持可能なタイミングにおいて、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えをチューナ制御により実行する構成であることを特徴とする。
【００３３】
さらに、本発明の第２の側面は、
サーバに設定されたチューナの受信コンテンツをサーバから受信する情報処理装置であり、
チューナ受信コンテンツを提供するサーバとのデータ送受信処理を実行するデータ送受信部と、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するとともに、前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御部と、
を有することを特徴とする情報処理装置にある。
【００３４】
さらに、本発明の情報処理装置の一実施態様において、前記制御部は、前記サーバから受信するコンテンツ情報に含まれるプロトコル情報中の、チューナ識別情報としてのファンクションＩＤを格納した接続準備要求を前記サーバに対して送信し、該接続準備要求の応答として、前記サーバから受信するチューナ受信コンテンツの制御を実行する制御インスタンスのＩＤを取得し、該制御インスタンスＩＤを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する構成を有することを特徴とする。
【００３５】
さらに、本発明の情報処理装置の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記制御部は、前記チャンネルリストに記述された複数チャンネル間の切り替え前後におけるコンテンツ受信を、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用して実行する構成であることを特徴とする。
【００３６】
さらに、本発明の第３の側面は、
コンテンツ提供サーバに設定されたチューナによる受信コンテンツをクライアントに送信するコンテンツ送信制御方法であり、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストに記述された複数のチャンネルに対応するチューナ受信コンテンツを制御対象のコンテンツ単位として設定した制御インスタンスを設定する制御インスタンス設定ステップと、
前記制御インスタンスに対するクライアントからの制御要求を受信する制御要求受信ステップと、
前記制御要求に基づいて、前記制御インスタンスによるチューナ制御を実行する制御ステップと、
を有することを特徴とするコンテンツ送信制御方法にある。
【００３７】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、前記制御インスタンス設定ステップは、前記チャンネルリストＵＲＬを制御インスタンスに対応付けるステップを含むことを特徴とする。
【００３８】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記制御ステップは、前記チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行することを特徴とする。
【００３９】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記コンテンツ情報には、コンテンツ対応のプロトコル情報が含まれ、前記チューナを介した受信コンテンツに対応して設定されるプロトコル情報には、チューナ識別情報としてのファンクションＩＤを含み、前記制御インスタンス設定ステップは、チューナ受信コンテンツの制御を実行する制御インスタンスを、前記ファンクションＩＤに基づいて決定される制御対象チューナの制御を実行する制御インスタンスとして設定する処理を実行することを特徴とする。
【００４０】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記コンテンツ送信制御方法は、さらに、前記制御インスタンスの識別子としてのインスタンスＩＤと、サーバクライアント間のコネクション識別子であるコネクションＩＤと、配信コンテンツに対応するプロトコル情報とを対応付けたコネクション管理テーブルに基づくコネクション管理を実行するステップを含むことを特徴とする。
【００４１】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記制御要求受信ステップは、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルに従った配信コンテンツの制御要求をクライアントから受信するステップであることを特徴とする。
【００４２】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記コンテンツ送信制御方法において、さらに、前記チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行中に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドの受信に応じて、該チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行するステップを含むことを特徴とする。
【００４３】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記コンテンツ送信制御方法は、さらに、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えにより、クライアントに対する送信符号化データの整合性の保持可能性を判定し、整合性が保持されないと判定した場合には、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションの切断を実行するステップと、
サーバクライアント間のイベント通知コネクションを介してチャンネルリストＵＲＬに基づいて設定されたＨＴＴＰコネクションの切断情報を通知するステップと、
を含むことを特徴とする。
【００４４】
さらに、本発明のコンテンツ送信制御方法の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記制御ステップは、クライアントに対する送信符号化データの整合性の保持可能なタイミングにおいて、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えをチューナ制御により実行するステップを含むことを特徴とする。
【００４５】
さらに、本発明の第４の側面は、
サーバに設定されたチューナの受信コンテンツをサーバから受信する情報処理方法であり、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するコンテンツ送信要求ステップと、
前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御要求ステップと、
を有することを特徴とする情報処理方法にある。
【００４６】
さらに、本発明の情報処理方法の一実施態様において、前記コンテンツ送信要求ステップは、前記サーバから受信するコンテンツ情報に含まれるプロトコル情報中の、チューナ識別情報としてのファンクションＩＤを格納した接続準備要求を前記サーバに対して送信するステップを含み、前記制御要求ステップは、前記接続準備要求の応答として、前記サーバから受信するチューナ受信コンテンツの制御を実行する制御インスタンスのＩＤを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行するステップを含むことを特徴とする。
【００４７】
さらに、本発明の情報処理方法の一実施態様において、前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、前記情報処理方法は、前記チャンネルリストに記述された複数チャンネル間の切り替え前後におけるコンテンツ受信を、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用して実行することを特徴とする。
【００４８】
さらに、本発明の第５の側面は、
コンテンツ提供サーバに設定されたチューナによる受信コンテンツをクライアントに送信するコンテンツ送信制御処理を実行するコンピュータ・プログラムであり、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストに記述された複数のチャンネルに対応するチューナ受信コンテンツを制御対象のコンテンツ単位として設定した制御インスタンスを設定する制御インスタンス設定ステップと、
前記制御インスタンスに対するクライアントからの制御要求を受信する制御要求受信ステップと、
前記制御要求に基づいて、前記制御インスタンスによるチューナ制御を実行する制御ステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００４９】
さらに、本発明の第６の側面は、
サーバに設定されたチューナの受信コンテンツをサーバから受信するための情報処理を実行するコンピュータ・プログラムであり、
前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するコンテンツ送信要求ステップと、
前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御要求ステップと、
を有することを特徴とするコンピュータ・プログラムにある。
【００５０】
【作用】
本発明の構成によれば、チャンネルの集合体としてのチャンネルリストにＵＲＬを設定した構成としたので、クライアントが、チャンネルリストＵＲＬを指定したコンテンツ取得要求をサーバに送信することで、クライアントは、チャンネルリストにリストアップされたチャンネル、すなわちコンテンツ管理ディレクトリにおいて、チューナコンテナの下位に設定されたチャンネルアイテムの全てのコンテンツの制御権をまとめて得ることができる。結果として、チャンネルリストにリストされたチャンネル間の切り替えにおいては、新たなＵＲＬに基づくコンテンツ要求を行う必要がない。
【００５１】
また、本発明の構成においては、チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行することができるので、クライアントは、チャンネル切り替え等の制御命令をコンテンツ配信制御部に送信するのみで、チャンネル切り替えが可能となり、従って、新旧ＵＲＬの切り替えに基づくサーバクライアント間のコネクションの再設定等の処理が不要となる。すなわち、チャンネルリスト中のチャンネルを切り替えるときは、ＡＶＴインスタンスに対してチャンネル切り替え要求（ＡＶＴ Ｓｅｅｋ ａｃｔｉｏｎ）を行うのみで、コンテンツ配信コネクションとしてのＨＴＴＰコネクションを継続的に使用して、チャンネル切り替え前後のコンテンツを受信することができる。
【００５２】
また、本発明の構成においては、チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定されるチューナの受信する複数チャンネルのコンテンツの配信制御をＡＶＴインスタンスの制御の下に実行している間に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドを受信した場合、その要求クライアントは、ＡＶＴインスタンスの設定を行うことなく、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行することができる。
【００５３】
なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体、例えば、ＣＤやＦＤ、ＭＯなどの記憶媒体、あるいは、ネットワークなどの通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。
【００５４】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づく、より詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【００５５】
【発明の実施の形態】
以下、図面を参照しながら、本発明のコンテンツ提供サーバ、情報処理装置、および方法、並びにコンピュータ・プログラムの詳細について説明する。
【００５６】
［システム概要］
まず、図１を参照して、本発明の適用可能なネットワーク構成例について説明する。図１は、様々なクライアント装置からの処理要求に応じて処理を実行するコンテンツ配信装置としてのサーバ１０１と、サーバ１０１に対して処理要求を行なうコンテンツ受信装置としてのクライアントがネットワーク１００を介して接続された構成、例えばホームネットワーク構成を示している。クライアント装置としては、パーソナルコンピュータ（ＰＣ）１２１、モニタ１２２、携帯電話１２３、再生機１２４、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）１２５を例示している。ただし、クライアント装置としては、この他にも様々な電子機器、家電機器が接続可能である。
【００５７】
サーバ１０１がクライアントからの要求に応じて実行する処理は、例えばサーバ１０１の保有するハードディスク等の記憶手段に格納されたコンテンツの提供、あるいはサーバ１０１の有するチューナを介して受信するライブコンテンツをクライアントに対して転送するコンテンツ配信サービス等である。なお、図１においては、サーバ１０１と、クライアント装置とを区別して示しているが、クライアントからの要求に対するサービスを提供する機器をサーバとして示しているものであり、いずれのクライアント装置も、自己のデータ処理サービスを他のクライアントに提供する場合には、サーバとしての機能を提供可能となる。従って、図１に示すネットワーク接続されたクライアント装置もサーバとなり得る。
【００５８】
ネットワーク１００は、有線、無線等いずれかのネットワークであり、各接続機器は、例えばイーサネット（登録商標）フレーム等の通信パケットをネットワーク１００を介して送受信する。すなわち、クライアントは、イーサネットフレームのデータ部に処理要求情報を格納したフレームをサーバ１０１に送信することにより、サーバ１０１に対するデータ処理要求を実行する。サーバ１０１は、処理要求フレームの受信に応じて、データ処理を実行し、必要に応じてデータ処理結果としての結果データを通信パケットのデータ部に格納し、各クライアントに送信する。
【００５９】
ネットワーク接続機器は、例えばユニバーサルプラグアンドプレイ（ＵＰｎＰ：Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）対応機器によって構成される。従って、ネットワークに対する接続機器の追加、削除が容易な構成である。ネットワークに新たに接続する機器は、
（１）ＩＰアドレス等の自己のデバイスＩＤを取得するアドレッシング処理。
（２）ネットワーク上の各デバイスの検索を行ない、各デバイスから応答を受信し、応答に含まれるデバイス種別、機能等の情報を取得するディスカバリ処理。
（３）ディスカバリ処理で取得した情報に基づいて、各デバイスにサービスを要求するサービス要求処理。
上記処理手順を行なうことで、ネットワーク接続された機器を適用したサービスを受領することが可能となる。
【００６０】
図１に示すサーバおよびクライアント装置を構成する情報処理装置の一例としてＰＣのハードウェア構成例について図２を参照して説明する。
【００６１】
ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、またはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４等に記憶されているプログラムに従って、各種の処理を実行し、データ処理手段、あるいは通信制御処理手段として機能する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３には、ＣＰＵ２０１が実行するプログラムやデータが適宜記憶される。ＣＰＵ２０１、ＲＯＭ２０２、およびＲＡＭ２０３、ＨＤＤ２０４は、バス２０５を介して相互に接続されている。
【００６２】
バス２０５には、入出力インタフェース２０６が接続されており、この入出力インタフェース２０６には、例えば、ユーザにより操作されるキーボード、スイッチ、ボタン、ポインティングデバイス、あるいはマウス等により構成される入力部２０７、ユーザに各種の情報を提示するＬＣＤ、ＣＲＴ、スピーカ等により構成される出力部２０８が接続される。さらに、データ送受信手段として機能する通信部２０９、さらに、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブル記録媒体２１１を装着可能で、これらのリムーバブル記録媒体２１１からのデータ読み出しあるいは書き込み処理を実行するドライブ２１０が接続される。
【００６３】
さらに、地上波放送データ、衛星放送データ、ケーブルＴＶデータ、インターネット配信データ等、様々な外部からの配信データの受信を行うチューナ２２０を備えている。
【００６４】
図２に示す構成は、図１に示すネットワーク接続機器の一例としてのサーバ、パーソナルコンピュータ（ＰＣ）の例であるが、ネットワーク接続機器はＰＣに限らず、図１に示すように携帯電話、ＰＤＡ等の携帯通信端末、その他、再生装置、ディスプレイ等の様々な電子機器、情報処理装置によって構成することが可能である。従って、それぞれの機器固有のハードウェア構成を持つことが可能であり、そのハードウェアに従った処理を実行する。
【００６５】
［オブジェクト管理およびメタデータ］
次にクライアントに提供するコンテンツを管理するサーバのコンテンツを含むオブジェクト管理構成、およびメタデータについて説明する。サーバは、自己の記憶部に格納した静止画、動画等の画像データ、音楽等の音声データ等のコンテンツ、さらには、ライブストリーミングデータを実行するためのチューナに関する情報、例えばチャンネル情報を各コンテンツに対応する属性情報（メタデータ）として保有している。
【００６６】
なお、サーバの保有する静止画、動画等の画像データ、音楽等の音声データ、チューナを介して受信するライブストリーミングデータ等のコンテンツを総称してＡＶコンテンツと呼ぶ。サーバにおいて、ＡＶコンテンツは、階層構成を有するコンテンツ管理ディレクトリによってサーバ内のＣＤＳ（コンテンツディレクトリサービス）において管理される。
【００６７】
サーバのＣＤＳ（コンテンツディレクトリサービス）において管理されるコンテンツ管理ディレクトリの構成例を図３に示す。階層構成は図３に示すように分岐ツリー状の図として示すことができる。図３に示す各円の各々が個々のオブジェクトである。この階層構成は、サーバが記憶部に格納し管理するコンテンツ、およびライブストリーミングコンテンツに対応する論理的な管理構成を示すものである。
【００６８】
コンテンツ管理ディレクトリの個々の要素、すなわち、個々のＡＶコンテンツあるいは複数のＡＶコンテンツを格納したフォルダ、メタデータ格納フォルダの各々はオブジェクト（Ｏｂｊｅｃｔ）と呼ばれる。なお、オブジェクトとは、サーバによって処理されるデータ単位の総称であり、個々のＡＶコンテンツあるいは複数のＡＶコンテンツを格納したフォルダ、メタデータ格納フォルダ以外にも様々なオブジェクトが存在する。
【００６９】
ＡＶコンテンツの最小単位、すなわち１つの楽曲データ、１つの動画データ、１つの静止画データ等をアイテム（ｉｔｅｍ）とよぶ。ライブストリーミングデータの場合は、１つのチャンネルが１アイテムとして定義される。
【００７０】
また、アイテムの集合として規定されるアイテムの上位オブジェクトをコンテナ（Ｃｏｎｔａｉｎｅｒ）と呼ぶ、集合の単位は、例えば各オブジェクトの物理的な記憶位置に基づく集合、各オブジェクトの論理的関係に基づく集合、カテゴリに基づく集合等、様々に設定され得る。
【００７１】
例えば、チャンネルをアイテムとしたコンテナの一例としては地上波のみのチャンネルのアイテムを集合としたコンテナや、衛星放送のチャンネルを集合としたコンテナが設定される。これらの例については後段でさらに説明する。
【００７２】
オブジェクトは、その種類、例えば音楽（Ａｕｄｉｏ）、ビデオ（Ｖｉｄｅｏ）、写真（Ｐｈｏｔｏ）等、その種類によりクラスに分類されクラスラベリングがなされる。クライアントは、例えば特定のクラスを指定して、特定の分類に属するオブジェクトのみを対象とした「サーチ」を要求し実行することができる。また特定のフォルダ等のオブジェクトを指定して、そのフォルダに関する情報のみを要求する「ブラウズ」を要求し特定フォルダに関する情報の取得処理をすることが可能である。なお、サーバにおいては、クラスも階層構成で管理されており、１つのクラスの下にサブクラスの設定が可能である。
【００７３】
メタデータは、サーバの持つコンテンツに対応した属性情報、クラスの定義情報、コンテンツ管理ディレクトリを構成する階層構成に関する情報等を含むさまざまな管理情報である。個々のオブジェクトに対応付けて定義されたコンテンツの属性情報としてのメタデータには、例えばコンテンツＵＲＬ等のコンテンツ識別子（ＩＤ）、データサイズ、リソース情報、タイトル、アーティスト名、著作権情報、チャンネル情報等、様々な情報が含まれる。メタデータに含まれる個々の情報をプロパティまたはプロパティ情報と呼ぶ。なお、音楽（Ａｕｄｉｏ）、ビデオ（Ｖｉｄｅｏ）、写真（Ｐｈｏｔｏ）、ライブストリーミングデータ等、前述したクラス毎にどのようなプロパティからなるメタデータを持つかが予め規定されている。
【００７４】
図３において、最上位はルートコンテナ３０１と呼ばれる。ルートコンテナの下位に例えば音楽（ミュージック）コンテナ３０２、動画コンテナ３０３、静止画コンテナ３０４、さらにチューナコンテナ３０５等が設定される。音楽（ミュージック）コンテナ３０２の下位には、ジャンル３０５、ジャンルの下位には、アーティスト３０６などのオブジェクトの設定がなされる。
【００７５】
動画コンテナ３０３の下位には、ジャンル３０８、さらにその下位にコンテンツに対応するアイテムとしてのビデオカプセル３０９が設定される。例えばビデオカプセル３０９は、サーバ内のハードディスク等の記憶部に格納されたビデオコンテンツに対応し、そのビデオコンテンツに対応した属性情報（メタデータ）を持つ。メタデータには、クライアントがコンテンツを取得するためのコンテンツ識別子、すなわちコンテンツの所在を示すアドレス情報としてのコンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）が含まれる。クライアントは、コンテンツ情報取得手続きによりビデオカプセル３０９のＵＲＬすなわち、ビデオカプセルＵＲＬを取得し、ビデオカプセルＵＲＬを指定したコンテンツ要求をサーバに送信することでビデオカプセルに対応するビデオコンテンツをサーバから受信して再生することができる。
【００７６】
一方、チューナコンテナ３０５にもコンテナに対応するＵＲＬとしてチャンネルリストＵＲＬが設定される。すなわち、チューナ受信コンテンツに対応する属性情報としてチャンネルリストＵＲＬが設定される。チャンネルリストＵＲＬは、チューナコンテナ３０６の子として存在するチャンネルアイテムに対応する全てのコンテンツの取得、制御権をクライアントに提供するために設定されたＵＲＬである。
【００７７】
従来のシステムであれば、アイテムであるチャンネル毎にＵＲＬが設定され、クライアントは、チャンネル切り替えに応じてＵＲＬの切替えを行うことが必要となっていたが、本発明においては、チャンネルの集合体としてのチャンネルリストにＵＲＬを設定し、クライアントが、チャンネルリストＵＲＬを指定したコンテンツ取得要求をサーバに送信することで、クライアントは、チャンネルリストにリストアップされたチャンネル、すなわちコンテンツ管理ディレクトリにおいて、チューナコンテナの下位に設定されたチャンネルアイテムの全てのコンテンツの取得、すなわち制御権をまとめて得ることができる。結果として、チャンネルリストにリストされたチャンネル間の切り替えにおいては、新たなＵＲＬに基づくコンテンツ要求を行う必要がない。これらの処理の詳細については後述する。
【００７８】
コンテンツ検索を実行しようとするクライアントは、コンテンツ管理ディレクトリの階層やオブジェクト集合に対応するクラスを指定した「サーチ」、あるいは、特定のオブジェクトの指定としての「ブラウズ」をサーバに要求することで、コンテンツの情報を取得することが可能である。クライアントは、サーバから受信するコンテンツ情報を記述したＸＭＬデータに基づいてコンテンツ情報をディスプレイに表示する。
【００７９】
コンテンツ情報リストの表示処理例を図４に示す。図４に示す例では、コンテンツＮｏ、タイトル、アーティスト名、チャンネル、コンテンツＵＲＬをリスト化したデータ構成を持つコンテンツ情報リスト３５７をディスプレイ３５０に表示した例を示している。
【００８０】
例えばビデオカプセルに対応するメタデータに基づいて表示されるコンテンツ情報は、図４中のコンテンツＮｏ．［０００１］、［０００２］のコンテンツであり、チューナコンテナに対応するメタデータに基づいて表示されるコンテンツ情報は、［０００３］、［０００４］のようにチャンネルリストであることと、チャンネルリストに含まれるチャンネル情報、およびチャンネルリストＵＲＬ等となる。
【００８１】
これらのコンテンツ情報は、サーバの管理するコンテンツ対応のメタデータの構成要素としてのプロパティ情報に基づいて生成される。サーバはクライアントから受信した「サーチ」または「ブラウズ」要求に基づいて条件に一致するコンテンツのメタデータ中のプロパティ情報を取得し、取得したプロパティ情報に基づいてＸＭＬデータを生成し、クライアントに送信する。
【００８２】
クライアントは、サーバによって抽出されたコンテンツに対応するプロパティ情報に基づくＸＭＬデータを受信し、受信ＸＭＬデータに基づいて図４に示すような表示データを生成し、クライアントのディスプレイに表示する。
【００８３】
クライアント側のユーザはこれらのリストから再生対象コンテンツを選択し、選択コンテンツ指定情報、例えばコンテンツＵＲＬをサーバに送信することで、サーバからコンテンツ、すなわち音楽や映画、あるいは写真等、様々なコンテンツが送信されクライアント側で再生、出力が実行される。チューナコンテナに対応するチャンネルリストＵＲＬに基づくコンテンツ要求を行うと、チャンネルリストにリストされたチャンネルに対応するコンテンツをまとめて取得、すなわちＵＲＬ切り替えを行うことなく、チャンネル切り替えを自在に実行することができる。
【００８４】
前述したように、クライアントに送信されるコンテンツ情報には、コンテンツの所在を示すアドレス情報としてのコンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）が含まれる。クライアントディスプレイに表示されたコンテンツＵＲＬあるいはリンクデータをユーザが指定（クリック）したことを条件として、クライアントデバイスにおいて、コンテンツ取得要求であるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ＧＥＴメソッドを生成してサーバに送信し、サーバがコンテンツＵＲＬに対応するコンテンツをクライアントに送信する。
【００８５】
［クライアントによるコンテンツ再生処理］
コンテンツを再生しようとするクライアントは、サーバに対してコンテンツ要求を行い、要求コンテンツをサーバから受信してコンテンツの再生を行うことができる。一般的なコンテンツ再生の手順について図５を参照して説明する。まず、ステップＳ１１において、クライアントは、サーバの保有するコンテンツ情報の取得要求を行う。ステップＳ１２で、サーバは、クライアントの要求に従ってコンテンツ対応のメタデータに基づいて、コンテンツの所在を示すアドレス情報としてのコンテンツのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）一覧、コンテンツのタイトル、アーティスト名などのコンテンツ情報をＸＭＬ（ｅＸｔｅｎｄｅｄ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）データにより生成してクライアントに送信する。
【００８６】
クライアントは、ステップＳ１３において、受信ＸＭＬ情報に従って、コンテンツ情報をディスプレイに表示する。例えば音楽コンテンツであれば、サーバの保有する複数の音楽に対応する曲名、アーティスト名、再生時間等からなるリストとして表示される。
【００８７】
次に、クライアントはステップＳ１４において、クライアント装置において、サーバから受信し再生する曲を選択し、コンテンツ指定情報としてのコンテンツＵＲＬを指定してサーバに送信する。サーバはステップＳ１５において、受信したコンテンツ指定情報に基づいてコンテンツを記憶手段から取得して送信する。ステップＳ１６において、クライアントはサーバから受信したコンテンツを再生する。なお、コンテンツがＡＴＲＡＣ、ＭＰＥＧ等の圧縮処理がなされている場合は、サーバあるいはクライアント側で復号処理を行った後に送信あるいは再生処理を行う。
【００８８】
通常のコンテンツ再生手順は、上述したとおりである。クライアントは、様々なコンテンツ属性情報、すなわち、サーバの保有するコンテンツ対応のメタデータに含まれるプロパティ情報を取得し、プロパティ情報に基づいてクライアントにコンテンツリスト等のＵＩを表示し、コンテンツを選択しサーバに要求することができる。
【００８９】
［ライブストリーミングデータ配信処理］
サーバのハードディスク等に予め格納したコンテンツは、上述したように、クライアントがコンテンツ対応のＵＲＬを指定したコンテンツ要求をサーバに送信することで、コンテンツの取得再生を行うことができる。
【００９０】
しかし、従来技術の欄で説明したように、サーバ内のチューナを介して受信するライブストリーミングデータの各チャンネルのデータに各々ＵＲＬを設定し、ＵＲＬ指定に基づくコンテンツ提供を行う構成とすると、クライアントによるチャンネル切り替えの際に、切り替え後のチャンネルに対応したＵＲＬを設定したＨＴＴＰ−ＧＥＴメソッドをサーバに送信することが必要となる。その結果、サーバクライアント間で、新旧ＵＲＬに基づくコネクションの切断および再接続処理を行うことが必要となり、双方の負荷が過大になり、チャンネル切り替え毎に通信の中断が発生するという問題か発生する。
【００９１】
そこで、本発明においては、複数のチャンネルの集合体であるチャンネルリストを設定し、チャンネルリストを１つのコンテンツと仮定して１つのコンテンツＵＲＬをチャンネルリストに対して設定し管理する構成とした。以下、本構成に基づくライブストリーミングデータ配信処理構成について説明する。
【００９２】
チューナ機能を持ち、チューナにより受信したデータをクライアントに配信する構成を持つサーバの構成例を図６に示す。
【００９３】
図６に示す構成について説明する。サーバ４００は、クライアント４６０に対してクライアント４６０からの要求コンテンツを送信し、ユーザ４７０は、クライアント４６０デバイスに備えたディスプレイ、スピーカ等を介してコンテンツを視聴する。なお、図６においては、クライアント４６０を１つのみ示してあるが、サーバ４００に対して接続するクライアントは複数あり、複数のクライアントがサーバ４００から様々なコンテンツの提供を受けることが可能である。
【００９４】
サーバは、データベース４４３に格納したコンテンツの提供、さらにチューナ４１０を介して外部から受信するデータ、例えば地上波放送データ、衛星放送データ、ケーブルＴＶデータ、インターネット配信データ等、様々な外部からの受信データをクライアント４６０に対して送信する。サーバ４００とクライアント４６０間の通信ネットワークは、先に、図１を参照して説明したように、有線、無線等いずれかのネットワークであり、例えばイーサネット（登録商標）フレーム等の通信パケットをネットワークを介して送受信する。すなわち、クライアント４６０は、イーサネットフレームのデータ部に処理要求情報を格納したフレームをサーバ４００に送信することにより、サーバ４００に対するデータ処理要求を実行する。サーバ４００は、処理要求フレームの受信に応じて、データ処理を実行し、必要に応じてデータ処理結果としての結果データを通信パケットのデータ部に格納し、各クライアント４６０に送信する。
【００９５】
サーバ４００の構成について、以下、説明する。チューナ４１０は、地上波放送データ、衛星放送データ、ケーブルＴＶデータ、インターネット配信データ等、様々な外部からの受信データを受信するライブストリーミングデータの受信部である。チューナ４１０は、コンテンツ配信制御部４３０内のコンテンツ対応制御部４３２に設定される配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスとしてのＡＶＴインスタンス（ＡＶ−Ｔｒａｎｓｐｏｒｔ Ｉｎｓｔａｎｃｅ）４３３によって制御される。なお、本明細書において、制御インスタンスとは、制御対象ハードウェア等の制御オブジェクトの設定が可能で、かつ設定オブジェクトに応じた制御パラメータの設定が可能な制御プログラムであり、該制御プログラムに従って制御対象ハードウェアを含む制御オブジェクトの制御が実行される。
【００９６】
コンテンツ対応制御部４３２は、配信コンテンツ毎に、コンテンツ配信制御実行部としてのＡＶＴインスタンス（ＡＶ−Ｔｒａｎｓｐｏｒｔ Ｉｎｓｔａｎｃｅ）＃１〜＃ｎ４３３を設定する。各ＡＶＴインスタンス４３３は、それぞれ特定のコンテンツの配信制御を実行する。例えばチューナを介して受信するデータのライブストリーミング用のチューナコントロールインスタンスは、チューナを介して受信するデータのライブストリーミングコンテンツのみの制御を実行する。具体的には、コンテンツ送信開始、終了、あるいはチャンネル切り替え等の指示をクライアント４６０から受け、チャンネル切り替え等の制御をチューナ４１０に対して実行する。
【００９７】
コンテンツ対応制御部４３２に設定されるＡＶＴインスタンス４３３は、チューナコントロールインスタンスの他に、例えば、サーバ内のハードディスクに格納されたビデオコンテンツであるビデオカプセルの配信制御を実行するビデオカプセルコンロールインスタンスや、サーバに装着されたＤＶＤに格納されたビデオデータ、オーディオデータ等の配信制御を実行するＤＶＤコントロールインスタンスなどがある。これら各ＡＶＴインスタンスが、特定の配信コンテンツの制御を実行する。
【００９８】
各ＡＶＴインスタンスには、制御対象コンテンツに対応するＵＲＬ、すなわちコンテンツ識別子としてのコンテンツＵＲＬが設定される。コンテンツＵＲＬはコンテンツの所在を示すコンテンツ識別子である。ビデオカプセルコントロールインスタンスには、ビデオカプセルに設定されたビデオカプセルＵＲＬが設定される。本発明の構成においては、チューナコントロールインスタンスにはチューナに対応するチャンネルリストＵＲＬが設定される。ＡＶＴインスタンス４３３は、自己に設定されたＵＲＬに基づいて、制御するコンテンツと関係付けられる。また、ＵＲＬを設定されたＡＶＴインスタンスは、自己の識別子としてのＡＶＴインスタンスＩＤを持つことになる。これらの処理の詳細については後述する。
【００９９】
コンテンツ配信制御部４３０は、チャンネルリストに記述された複数チャンネルに対応するチューナの受信する複数コンテンツを制御コンテンツの一単位として設定し、１つのＡＶＴインスタンスをアサインし、スクライアントから受信するチャンネルリスト識別子に対応する制御要求をＡＶＴインスタンスが受信し、ＡＶＴインスタンスがチャンネルリストに記述された複数チャンネルに対応する配信コンテンツの制御を実行する。
【０１００】
コネクションマネージャサービス（ＣＭＳ）４３１は、クライアント４６０にライブストリーミング制御部４３０の入力プロトコル情報を伝える。また、クライアント４６０から提示されたプロトコル情報に基づいて、ＡＶＴインスタンス４３３をアサインしてクライアント４６０に通知する。
【０１０１】
コネクションマネージャサービス４３１は、クライアント４６０からのコンテンツ要求に応じて、ＡＶＴインスタンス４３３のアサイン（割り当て）処理を実行し、アサインしたＡＶＴインスタンスの識別子、すなわちＡＶＴインスタンスＩＤをクライアント４６０に通知する。この際、サーバクライアント間のコネクション識別子としてのコネクションＩＤもクライアント４６０に通知する。コネクションマネージャサービス４３１は、これらのデータをコネクション管理テーブルに登録する。コネクション管理テーブルについては後述する。
【０１０２】
コネクションマネージャサービス４３１による上述の処理の後、クライアント４６０からのＡＶＴインスタンス４３３に対する要求により、上述したコンテンツＵＲＬおよびＡＶＴインスタンスＩＤがＡＶＴインスタンス４３３に設定される。
【０１０３】
コネクションマネージャサービス４３１によるＡＶＴインスタンス４３３のアサイン処理およびクライアント４６０によるＵＲＬセット処理により、コンテンツ対応のＵＲＬが設定され、ＵＲＬによって識別されるコンテンツの配信制御を受け持つことになったＡＶＴインスタンス４３３は、クライアント４６０からの制御コマンドを受信すると、その制御コマンドに従ったコンテンツ制御を実行する。このクライアント４６０サーバ間でのコンテンツ配信制御処理には、例えばＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルが使用される。クライアント４６０は、ＸＭＬデータに従った記述データを生成しＡＶＴインスタンス４３３に送信することで、クライアント４６０からの制御情報が、各ＡＶＴインスタンス４３３に通知され、ＡＶＴインスタンス４３３が受信情報に基づく制御、例えばコンテンツ再生開始、終了、チャンネル切り替えなどの処理を実行する。
【０１０４】
例えばチューナコントロールインスタンス４３３にクライアント４６０からの制御情報として、チャンネル切り替え指示情報が入力されると、チューナコントロールインスタンス４３３から、制御情報がチューナ４１０に入力されてチューナ４１０が特定のチャンネルのデータを受信するように設定される。
【０１０５】
なお、サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションである。本発明の構成においては、チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行する。
【０１０６】
チューナ４１０の受信データは、例えば符号化データ（ＡＴＲＡＣ：ａｄａｐｔｉｖｅ ｔｒａｎｓｆｏｒｍ ａｃｏｕｓｔｉｃ ｃｏｄｉｎｇ， ＭＰＥＧ：ｍｏｖｉｎｇ ｐｉｃｔｕｒｅ ｅｘｐｅｒｔｓ ｇｒｏｕｐ等）である場合もあり生のデータである場合もある。サーバクライアント間では、データ送信効率を高めるために特定の符号化データとして配信するのが好ましい。符号化データは、クライアント４６０において処理可能なデータである必要がある。コーデック４２０は、チューナ４１０の受信データをクライアント４６０で処理可能なデータ態様に変換する。コーデック４２０は、データのエンコードおよびデコード機能を持つ。コーデック４２０において生成された変換データがクライアント４６０に送信され、再生される。
【０１０７】
コーデック４２０においてどのようなデータ変換を行うかは、ＡＶＴインスタンス４３３からの制御情報によって決定する。ＡＶＴインスタンス４３３は、クライアント４６０からの要求情報をＡＶＴインスタンス４３３が受領し、ＡＶＴインスタンス４３３からの制御情報がコーデック４２０に入力されてコーデック４２０が制御情報に基づいてデータ変換を実行する。
【０１０８】
コンテンツ管理部（メディアサーバ）４４０は、コンテンツホルダーとして機能する。コンテンツのメタデータを格納したデータベース４４３、先に図３を参照して説明したコンテンツ管理ディレクトリに基づいてコンテンツ対応のメタデータの管理を行い、クライアント４６０からのコンテンツサーチ、ブラウズなどの処理要求に応答してコンテンツ情報を提供するコンテンツディレクトリサービス４４２を有する。
【０１０９】
データベース４４３には、予めサーバ内のデータベースに格納したコンテンツの情報のみならず、チューナを介して受信するデータに関する情報、例えばチャンネル情報などの管理情報もチューナコンテナに対応するメタデータとして格納しており、クライアント４６０からのチューナに関するコンテンツ情報取得要求をコンテンツディレクトリサービス４４２が受信した場合には、サーバの受信可能なチャンネル情報、複数のチャンネルの集合として設定されるチャンネルリストに対応付けられたチャンネルリストＵＲＬ等の情報をクライアント４６０に提供する処理などを実行する。
【０１１０】
コンテンツディレクトリサービス４４２は、ライブストリーミングで扱うコンテンツ用のメタデータとして、ライブストリーミングコンテンツ用のＵＲＬやコーデック情報、プロトコル情報をデータベース４４３に保持しており、クライアント４６０からの要求に応じてこれらの情報をクライアント４６０に送信する。
【０１１１】
なお、サーバがライブストリーミングコンテンツ配信可能であるか否かについては、クライアント４６０は、コンテンツディレクトリサービス４４２からのプロトコル情報によって知ることができる。プロトコル情報には、チューナの制御によるコンテンツ配信を実行することが可能であることを示す情報（ファンクションＩＤ（ｆｕｎｃＩＤ））が設定され、クライアントでは、ファンクションＩＤに基づいてチューナを介したライブデータのストリーミング配信が可能であることを知ることができる。ファンクションＩＤは、チューナ制御、ＤＶＤ制御、ハードディスク制御等、コンテンツ処理のための制御対象毎に設定されるＩＤであり、チューナが２つあればそれぞれ異なるファンクションＩＤ、例えばｆｕｎｃＩＤ＝ａ、ｆｕｎｃＩＤ＝ｂのように異なるＩＤが設定され、チューナ識別情報としても利用される。
【０１１２】
クライアント４６０は、コンテンツディレクトリサービス４４２からのコンテンツ情報に基づいて、チューナ受信のライブストリーミングデータの配信を希望する場合は、受信したコンテンツ情報から取得した情報をコンテンツ配信制御部４３０のコネクションマネージャ４３１に送信する。これらの処理の詳細については後述する。
【０１１３】
その後コンテンツ配信制御部４３０において、ＡＶＴインスタンス４３３がアサインされ、クライアントは、ＡＶＴインスタンス４３３に対して配信コンテンツに対する制御、例えばコンテンツの一時停止（ＳＴＯＰ）や、チャンネル切り替え（ＳＥＥＫ）等の各種制御を実行することができる。
【０１１４】
コンテンツ管理部４４０内のコネクションマネージャサービス（ＣＭＳ）４４１は、クライアント４６０にコンテンツ管理部４４０の出力プロトコル情報を伝えるなど、クライアント４６０と、コンテンツ管理部４４０間の通信制御サービスを行う。サーバ４００との接続クライアント４６０が複数いる場合には、クライアント４６０毎のコネションＩＤ管理を実行し、各クライアント４６０からの要求を識別して対応する。
【０１１５】
コンテンツディレクトリサービス４４２におけるライブストリーミングデータ関連のメタデータに関するオブジェクト管理構成について、図７を参照して説明する。
【０１１６】
先に図３を参照して説明したように、コンテンツ提供サーバでは様々なコンテンツに対応するメタデータを階層構成のディレクトリにおいて管理している。図７は、コンテンツディレクトリサービス４４２において管理するライブストリーミングデータ関連のメタデータの管理構成を示している。
【０１１７】
ルートコンテナ４８１の下段にチューナコンテナ４８２が設定される。なお、チューナ数や、チャンネルリストＵＲＬの設定態様に応じて、ディレクトリに設定されるチューナコンテナの設定態様は異なってくる。これらの形態については、後段で詳細に説明する。チューナコンテナ４８２の子として設定されるアイテムに、個々のチャンネル４８３，４８４，４８５が設定される。
【０１１８】
コンテンナ、アイテムにはそれぞれコンテンツ属性情報としてのメタデータが対応付けられ、クライアント４６０からのサーチや、ブラウズ等のコンテンツ情報要求に応じてこれらのメタデータに基づくコンテンツ情報がサーバから提供される。
【０１１９】
チューナコンテナ４８２には、チャンネルリストＵＲＬ、プロトコル情報等がメタデータとして格納される。チャンネルアイテム４８３，４８４，４８５には、例えばチャンネルの名前（東京テレビ、ＡＢＣテレビなど）の情報が格納される。
【０１２０】
チューナコンテナ４８２のメタデータとして設定されるチャンネルリストＵＲＬは、例えば地上波１〜１２チャンネルのみを受信可能なチューナの場合は、１〜１２チャンネルの１２個のチャンネルをリスト化した１つのチャンネルリストを取得するためのＵＲＬとして設定される。地上波、ＢＳ、ＣＳ等の衛星放送等のチャンネル（１〜ｎチャンネル）の放送データを受信可能なチューナの場合は、１〜ｎチャンネルのｎチャンネルをリスト化した１つのチャンネルリストを取得するためのＵＲＬとして設定される。
【０１２１】
なお、地上波のチャンネルリスト、ＢＳ用のチャンネルリスト、ＣＳ用のチャンネルリスト等、カテゴリ毎に区分したチャンネルリストを設定し、それぞれに異なるチャンネルリストＵＲＬを設定してもよい、
【０１２２】
これらのチャンネルリストＵＲＬは、クライアント４６０からコンテンツディレクトリサービス（ＣＤＳ）４４２に対するサーチやブラウズを適用したコンテンツ情報取得処理によってクライアント４６０が取得可能である。
【０１２３】
クライアント４６０は取得したチャンネルリストＵＲＬに基づくコンテンツ取得を行うことで、チャンネルリストに設定された、例えば１〜１２チャンネルの間の切り替え制御をその１つのＵＲＬに基づいて実行可能となる。すなわちクライアント４６０はチャンネルリストＵＲＬによるコンテンツ取得により、チャンネルリストにリストアップされたすべてのストリーミングデータの制御権をまとめて得ることができる。具体的な制御については、後述する。
【０１２４】
本発明の構成では、上述したように、個々のチャンネル毎のＵＲＬ設定ではなく、複数のチャンネルをまとめてその制御を可能とするために、チャンネルの集合としたチャンネルリストにコンテンツＵＲＬを設定した。従って、チャンネルリストにリストアップされたチャンネルに対応するストリーミングデータの制御権をまとめてクライアント４６０に提供することが可能となる。
【０１２５】
クライアント４６０は、チャンネルリストに基づく制御権を持つ場合には、リストにあるチャンネル間の切り替え等の処理を行う場合にも、新たなＵＲＬに基づくＨＴＴＰコネクションを設定する必要がない。チャンネル切り替え等の制御命令をコンテンツ配信制御部４３２に送信するのみで、チャンネル切り替えが可能となり、従って、新旧ＵＲＬの切り替えに基づくサーバクライアント間のコネクションの再設定等の処理が不要となる。
【０１２６】
図７に示すように、チューナコンテナ４８２の子としては、チューナコンテナ４８２の持つチャンネルリストＵＲＬに設定された各チャンネル、例えば地上波１〜１２チャンネルの各々が子アイテムとして設定される。それぞれのアイテムには各チャンネルの情報がメタデータとして設定される。
【０１２７】
図８にチューナコンテナおよびチャンネルアイテムに対応するコンテンツ情報（メタデータ）を示す。図８に示すデータは、クライアント４６０からコンテンツディレクトリサービス（ＣＤＳ）４４２に対するコンテンツ情報要求に応じてクライアント４６０に送信されるＸＭＬデータの例である。
【０１２８】
図８（ａ）がチューナコンテナに対応するメタデータに基づく情報であり、下記に示すような情報を持つ。
＜ｃｏｎｔａｉｎｅｒ ｉｄ＝ｃｈ−ｌｉｓｔ ｐａｒｅｎｔＩＤ＝−１ ｒｅｓｔｒｉｃｔｅｄ＝１ …＞
＜ｄｃ：ｔｉｔｌｅ＞ 地上波チャンネル一覧＜／ｄｃ：ｔｉｔｌｅ＞
＜ｕｐｎｐ：ｃｌａｓｓ＞ｏｂｊｅｃｔ．ｃｏｎｔａｉｎｅｒ．ｆｕｎｃｔｉｏｎ．ａｖＶｉｄｅｏＴｕｎｅｒ＜／ｕｐｎｐ：ｃｌａｓｓ＞
…
＜ａｖ：ａｌｌｏｗｅｄＯｐｅｒａｔｉｏｎ＞Ｐｌａｙ＜／ａｖ：ａｌｌｏｗｅｄＯｐｅｒａｔｉｏｎ＞
＜ａｖ：ｅｖｅｎｔｉｎｇＵＲＩ＞ｈｔｔｐ：／／１．２．３．４：５６０００／ＳＥＮＡ？ｉｄ＝ｌｉｖｅ＜／ａｖ：ｅｖｅｎｔｉｎｇＵＲＩ＞
＜ｒｅｓ ｐｒｏｔｏｃｏｌＩｎｆｏ＝ｈｔｔｐ−ｇｅｔ：＊：ｖｉｄｅｏ／ｍｐｅｇ：ｆｕｎｃ−ｉｄ＝ｔ０１ ａｖ：ｃｏｄｅｃ＝ＭＰＥＧ１Ｖ …＞
ｈｔｔｐ：／／１．２．３．４：５６０００／ｌｉｖｅｏｕｔＵｒｌ
＜／ｒｅｓ＞
＜／ｃｏｎｔａｉｎｅｒ＞
【０１２９】
上段から、コンテナＩＤ、タイトル、クラスに関するデータ、さらに、許容処理［ａｌｌｏｗｅｄＯｐｅｒａｔｉｏｎ］、イベント通知用ＵＲＬ［ｅｖｅｎｔｉｎｇＵＲＩ］、プロトコル情報［ｐｒｏｔｏｃｏｌＩｎｆｏ］などがチューナコンテナのコンテンツ情報として格納される。イベント通知とは、例えばステレオ／モノラルの切り替え、２ヶ国語放送の切り替え等、配信コンテンツに対応するイベントが発生した場合にクライアント４６０に通知するための処理を実行するために設定されるＵＲＬであり、クライアント４６０は、イベント通知用ＵＲＬを指定したイベント通知要求をサーバに対して送信することで、コンテンツ配信に並列して様々なイベント通知を受けることが可能となる。
【０１３０】
図８のデータ部４９１に示すプロトコル情報［ｐｒｏｔｏｃｏｌＩｎｆｏ］中のファンクションＩＤ［ｆｕｎｃ−ｉｄ＝ｔ０１］は、このコンテンツがライブストリーミング用のコンテンツであることを示す、すなわちチューナを適用した制御によるコンテンツ配信を実行することを示している。前述したように、ファンクションＩＤは、チューナ制御、ＤＶＤ制御等、コンテンツ配信のための制御対象毎に設定されるＩＤであり、チューナが２つあればそれぞれ異なるファンクションＩＤ、例えばｆｕｎｃＩＤ＝ａ、ｆｕｎｃＩＤ＝ｂのように異なるＩＤが設定される。図８のデータ部４９２に示す［ｈｔｔｐ：／／１．２．３．４：５６０００／ｌｉｖｅｏｕｔＵｒｌ］が、チャンネルリストＵＲＬである。
【０１３１】
図８（ｂ）が、チャンネルアイテムに対応するメタデータに基づく情報であり、下記に示すような情報を持つ。
＜ｄｃ：ｔｉｔｌｅ＞東京テレビ＜／ｄｃ：ｔｉｔｌｅ＞
＜ｕｐｎｐ：ｃｌａｓｓ＞ｏｂｊｅｃｔ．ｉｔｅｍ．ｖｉｄｅｏＩｔｅｍ．ｖｉｄｅｏＢｒｏａｄｃａｓｔ．ａｖＣｈａｎｎｅｌ
＜／ｕｐｎｐ：ｃｌａｓｓ＞
＜ｕｐｎｐ：ｃｈａｎｎｅｌＮａｍｅ＞東京テレビ＜／ｕｐｎｐ：ｃｈａｎｎｅｌＮａｍｅ＞
＜ｕｐｎｐ：ｃｈａｎｎｅｌＮｒ＞８＜／ｕｐｎｐ：ｃｈａｎｎｅｌＮｒ＞
…
＜／ｉｔｅｍ＞
【０１３２】
上段から、タイトル、クラス、チャンネル名、チャンネル番号が記載されている。クライアント４６０は、チューナコンテンナおよびチャンネルアイテムに対応するコンテンツ情報を取得することで、チューナコンテナに設定されたチャンネルリストＵＲＬに基づくコンテンツ要求により、どのような範囲のチャンネル制御権を取得することが可能かを知ることができる。
【０１３３】
クライアント４６０は、図８に示すコンテンツ情報からなるＸＭＬデータに基づいて、チャンネル情報一覧リストをクライアント４６０のディスプレイに表示する。
【０１３４】
次に、図９を参照して、サーバクライアント間で実行されるチャンネルリストＵＲＬに基づくストリーミングデータ配信処理シーケンスの詳細について説明する。
【０１３５】
まず、クライアント４６０は、サーバが保有し、クライアント４６０に提供可能なコンテンツを調べるために、ステップＳ１０１において、ブラウズまたはサーチ処理により、コンテンツ情報を取得する。コンテンツ検索を実行しようとするクライアント４６０は、コンテンツ管理ディレクトリの階層やオブジェクト集合に対応するクラスを指定した「サーチ」、あるいは、特定のオブジェクトの指定としての「ブラウズ」をサーバに要求することで、コンテンツの情報を取得することが可能である。プラウズまたはサーチは、コンテンツ管理部４４０（図６参照）のコンテンツディレクトリサービス４４２に対して実行され、コンテンツディレクトリサービス４４２がメタデータを格納したデータベース４４３から各オブジェクト対応のメタデータに基づくＸＭＬデータを生成してコンテンツ情報としてクライアント４６０に提供する。
【０１３６】
例えば、チューナコンテナに関するコンテンツ情報を取得した場合は、図８（ａ）に示すチューナコンテナ対応のコンテンツ情報および、図８（ｂ）に示すチャンネル毎のコンテンツ情報に基づく情報がクライアント４６０に送信される。なお、図８（ｂ）に示す情報は、１つのチャンネルに対応するコンテンツ情報であり、クライアント４６０が、チューナコンテナおよび子アイテムとしての全チャンネルの情報を要求した場合は、チューナコンテナの子アイテムとして設定されるチャンネル数に対応する数の図８（ｂ）に示す情報がクライアント４６０に送信されることになる。
【０１３７】
クライアント４６０は、サーバから受信するコンテンツ情報を記述したＸＭＬデータに基づいてコンテンツ情報をディスプレイに表示する。これは、先に、図４を参照して説明したような表示情報である。
【０１３８】
クライアント４６０は、図８（ａ）（ｂ）に示すチューナコンテナおよびチャンネルアイテムに対応するコンテンツ情報に基づいて、
チャンネルリストＵＲＬ
ファンクションＩＤ（ｆｕｎｃＩＤ）
チャンネル情報
を取得する。
【０１３９】
クライアント４６０は、次に、ステップＳ１０２において、コンテンツ配信制御部４３０のコネクションマネージャサービス４３１に対して、プロトコル情報取得要求を送信する。これは、コンテンツ配信制御部４３０に入力可能なプロトコル情報、すなわち、コンテンツ配信制御部４３０の処理可能なプロトコル情報の一覧を要求する処理である。
【０１４０】
ステップＳ１０３において、コネクションマネージャサービス４３１は、プロトコル情報一覧をクライアント４６０に送信する。このプロトコル情報一覧には、例えばビデオデータのプロトコルとしてのＭＰＥＧや、オーディオデータのＡＴＲＡＣ等、コンテンツ配信制御部４３０で処理可能な様々なプロトコル情報が含まれる。
【０１４１】
チューナ４１０の受信データを配信可能なサーバのコネクションマネージャサービス４３１がクライアント４６０に送信するプロトコル情報一覧には、ライブストリーミングデータの配信が可能であることを示す情報が含まれる。具体的には、［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］なるプロトコル情報が含まれる。すなわち、ｓｃｈｅｍａ欄（第１カラム）が［ｉｎｔｅｒｎａｌ］であるものが含まれる。このプロトコル情報は、内部のコンテンツ管理部（メディアサーバ）４４０との論理コネクションが、以下に説明する接続準備（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）によって可能であることを示す。
【０１４２】
このプロトコル情報にもファンクションＩＤが含まれる。前述したように、ファンクションＩＤは、チューナ制御、ＤＶＤ制御等、コンテンツ配信のための制御対象毎に設定されるＩＤであり、ステップＳ１０１においてクライアントがブラウズまたはサーチ処理により、コンテンツディレクトリサービス４４２から取得したコンテンツ情報にも含まれる。ここでは、ファンクションＩＤ［ｆｕｎｃ−ｉｄ＝ｔ０１］がチューナ４１０を適用したコンテンツ配信に対応するファンクションＩＤとして設定されている。
【０１４３】
次に、ステップＳ１０４において、クライアント４６０は、コネクションマネージャサービス４３１から、現在、サーバ４００に接続されている他のクライアントに関する情報を取得する。コネクションマネージャサービス４３１は、サーバに接続しているクライアントに対応するコネクションＩＤをクライアント識別子、および各クライアントに配信されるコンテンツに対応するプロトコル情報等を対応付けた図１０に示すようなコネクション管理テーブルを保持してコネクション管理を実行している。クライアント４６０からのコネクション情報の取得要求に応じて、これらの情報をクライアント４６０に提供する。この処理については、後述する。なお、このコネクション情報通知処理は、クライアント４６０が他のクライアント４６０の接続状況を確認するために実行するものであり、省略してもよい。
【０１４４】
ステップＳ１０５において、クライアント４６０は、コネクションマネージャサービス４３１に対して、接続準備要求（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）を送信する。クライアント４６０が、チューナを適用したライブストリーミングデータの配信を希望する場合は、先にコンテンツディレクトリサービス（ＣＤＳ）４４２から受領したコンテンツ情報としてのチューナコンテナに対応するコンテンツ情報に含まれるファンクションＩＤ（ｆｕｎｃＩＤ）と一致するファンクションＩＤを持つプロトコル情報を送信すればよい。
【０１４５】
ステップＳ１０５の接続準備（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）の送信において、クライアント４６０は、前述のプロトコル情報取得（Ｓ１０３）において、コネクションマネージャサービス４３１から受領したライブストリーミングに関するプロトコル情報［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］を送信する。
【０１４６】
クライアント４６０から接続準備要求（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）を受信したコネクションマネージャサービス４３１は、接続準備要求に含まれるプロトコル情報［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］に基づいて、チューナによる受信データのストリーミング配信の要求であると判断し、コンテンツ対応制御部４３２内の１つのＡＶＴインスタンス４３３をチューナコントロールインスタンスとして設定（アサイン）し、接続準備要求（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）のあったクライアント４６０に対するコネクションＩＤと、チューナコントロールインスタンスとして設定（アサイン）したＡＶＴインスタンスの識別子（ＡＶＴインスタンスＩＤ）とのバインド処理、すなわち対応付けを行う。
【０１４７】
なお、前述したように、コネクションマネージャサービス４３１は、図１０に示すコネクション管理テーブル、すなわち、各接続クライアント４６０毎のコネクションＩＤとＡＶＴインスタンスＩＤ、プロトコル情報との対応データを持ち、これをコネクション管理情報として管理している。
【０１４８】
ステップＳ１０６において、コネクションマネージャサービス４３１は、クライアント４６０に対して、アサインしたＡＶＴインスタンスの識別子であるＡＶＴインスタンスＩＤおよび、クライアント４６０サーバ間のコネクションに対して設定したコネクションＩＤ情報を通知する。クライアント４６０はこれらの情報をメモリに格納する。
【０１４９】
ステップＳ１０７において、クライアント４６０は、コネクションマネージャサービス４３１によってアサインされたＡＶＴインスタンスによるコンテンツ配信制御を行わせるための処理として、アサインされたＡＶＴインスタンスに対して、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）セット要求を発行する。ＡＶＴインスタンスに対してセットするＵＲＩには、コネクションマネージャサービス４３１から通知されたＡＶＴインスタンスＩＤと、ステップＳ１０２の処理において取得したチューナコンテナに対応するコンテンツ情報に含まれるチャンネルリストＵＲＬが含まれる。
【０１５０】
ＡＶＴインスタンスは、クライアント４６０から指定されたＡＶＴインスタンスＩＤと、チャンネルリストＵＲＬとに基づいて、自己の制御対象コンテンツおよびクライアントを識別することが可能となる。すなわち、ＡＶＴインスタンスＩＤを指定して各種の制御命令を送信するクライアントをＡＶＴインスタンスに対応するクライアントであり、チャンネルリストＵＲＬが制御対象コンテンツとなる。
【０１５１】
チャンネルリストＵＲＬは、チューナコンテナの対応コンテンツであり、チャンネルリストＵＲＬをセットしたＡＶＴインスタンスは、チューナ４１０の制御を実行するインスタンスとして設定されることになる。
【０１５２】
次にクライアント４６０はステップＳ１０８以降において、ＡＶＴインスタンスに対して、様々なコンテンツの制御要求を実行することができる。ステップＳ１０８では、再生（Ｐｌａｙ）要求をＡＶＴインスタンスに対して発行している。この制御要求は、例えばＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルが利用される。ＳＯＡＰに基づいて、クライアント４６０は、ＸＭＬデータに従った記述データを生成しＡＶＴインスタンス４３３に送信する。
【０１５３】
ＡＶＴインスタンス４３３は、クライアント４６０からの受信情報に基づく制御、例えばコンテンツ再生開始、終了、チャンネル切り替えなどの処理を実行する。ＡＶＴインスタンス４３３は、セットされたコンテンツＵＲＬに基づいて制御対象コンテンツを特定し、その特定された制御対象コンテンツを制御する。この場合は、コンテンツＵＲＬはチャンネルリストＵＲＬであり、チャンネルリストＵＲＬはチューナコンテナに対応するコンテンツ情報であり、ＡＶＴインスタンス４３３はチューナ４１０の制御を実行する。
【０１５４】
ステップＳ１０８の、再生（Ｐｌａｙ）要求をＡＶＴインスタンス４３３が受領すると、ＡＶＴインスタンス４３３はチューナ４１０を制御し、チューナ受信データのクライアント４６０に対する送信を開始する。
【０１５５】
ステップＳ１０９においては、チャンネル設定（Ｓｅｅｋ）要求をＡＶＴインスタンスに対して発行している。この要求には、ＡＶＴインスタンスＩＤとチャンネル番号が含まれる。チャンネル設定（Ｓｅｅｋ）要求をＡＶＴインスタンス４３３が受領すると、ＡＶＴインスタンス４３３はチューナ４１０を制御し、チューナのチャンネルを設定して受信データをクライアント４６０に送信する。
【０１５６】
ステップＳ１１０は、以下継続して実行されるライブストリーミングデータの配信を示している。ステップＳ１１１は、イベント通知処理（ＳＥＮＡ）がコンテンツ配信と並列して実行されることを示している。前述したようにイベントとは、例えばステレオ／モノラルの切り替え等のように配信コンテンツに関する情報であり、クライアント４６０からのイベントＵＲＬに基づくイベント通知要求に基づいてサーバが様々なイベント情報を通知する処理である。
【０１５７】
チャンネル切り替え処理シーケンスについて、図１１を参照して説明する。チャンネル切り替え処理は、チャンネルリストＵＲＬに基づくストリーミングデータの配信中に実行する。ステップＳ２０１において、ストリーミングデータの配信およびイベント通知が実行されているとする。
【０１５８】
ステップＳ２０２において、クライアント４６０はチャンネル切り替え（Ｓｅｅｋ）要求をＡＶＴインスタンスに対して発行する。この制御要求には、上述したように例えばＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルが利用される。クライアント４６０は、ＸＭＬデータに従った記述データを生成しＡＶＴインスタンス４３３に送信する。この要求には、ＡＶＴインスタンスＩＤと切り替えチャンネル番号が含まれる。チャンネル設定（Ｓｅｅｋ）要求をＡＶＴインスタンス４３３が受領すると、ＡＶＴインスタンス４３３はチューナ４１０を制御し、チューナのチャンネルを切り替えて受信データをクライアント４６０に送信する。
【０１５９】
その後、ステップＳ２０３において、切り替え後のチャンネルに対応するストリーミングデータの配信およびイベント通知が実行される。
【０１６０】
このチャンネル切り替えの前後におけるサーバクライアント間のＨＴＴＰコネクションは、同一のＵＲＬ、すなわち同じチャンネルリストＵＲＬに基づくＨＴＴＰコネクションであるため、サーバクライアント間においてはコネクションが維持されたままチャンネル切り替えが実行されることになる。
【０１６１】
このように、チャンネルリスト中のチャンネルを切り替えるときは、ＡＶＴインスタンスに対してチャンネル切り替え要求（ＡＶＴ Ｓｅｅｋ ａｃｔｉｏｎ）を行う。この際、チャンネル切り替え要求（ＡＶＴ Ｓｅｅｋ ａｃｔｉｏｎ）を行なったクライアント４６０のみならず、同じライブストリーミングを利用しているクライアントも、ＨＴＴＰコネクションを切ることなくコンテンツが変更される。
【０１６２】
なお、サーバからクライアントに対して送信される画像または音声データを、例えばＭＰＥＧ等の符号化データとした場合、クライアントから受信するチャンネル切り替えのタイミングに基づいて無条件に送信データの切り替えを実行すると、送信する符号化データパケットの不整合が発生する場合がある。このような不整合な符号化データをクライアント側でデコード（復号）するとデコードエラーによりコンテンツ再生エラーを発生させる。
【０１６３】
例えばＭＰＥＧ−２システムでは、映像や音声などの個別データストリームであるＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）パケットを複数結合し、さらに制御情報をヘッダに格納したパック（Ｐａｃｋ）を１つの処理単位としている。従って、パック（Ｐａｃｋ）を構成するＰＥＳパケットの一部を送信中に、チャンネル切り替えを実行して、送信データを変更すると、クライアントにおいてデコードする際の１つの処理単位であるパック（Ｐａｃｋ）に欠落が発生し、再生エラーを発生させることになる。
【０１６４】
従って、サーバのコンテンツ配信制御部４３０は、クライアントからのチャンネル切り替え要求に基づく送信データの変更により、送信符号化データの整合性の保持が可能か否かを判定し、整合性が保持されないと判断した場合は、サーバクライアント間のデータストリーム配信用の接続コネクション、すなわち、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションを切断する。サーバは、さらに、クライアントに対して、イベント通知用コネクションを介して、データストリーム配信用の接続コネクションが切断されたことを通知する。
【０１６５】
クライアントは、サーバからコネクション切断通知を受信した場合は、再度、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションを設定する処理、すなわち、チャンネルリストＵＲＬに基づくＨＴＴＰ−ＧＥＴメソッドをサーバに対して送信する。なお、ＡＶＴインスタンス（チューナコントロールインスタンス４３３）の設定状態は維持されているので、チューナコントロールインスタンス４３３の新たなアサイン、ＵＲＩセット等の設定処理は省略可能である。
【０１６６】
あるいは、サーバは、クライアントから受信したチャンネル切り替えタイミングに基づいて無条件にチャンネル切り替えを実行するのではなく、クライアントからのチャンネル切り替え要求受信後、クライアントに対して送信する符号化データの整合性を保持可能なタイミングを待機し、整合性を保持可能なタイミングでクライアントに対する送信データの切り替えを実行する構成としてもよい。この切り替えタイミングの制御は、コーデック４２０のデータエンコード状況を検出し、検出情報をチューナコントロールインスタンス４３３に入力し、チューナコントロールインスタンス４３３のタイミング制御の下にチューナ４１０のチャンネル切り替えを実行することで行う。
【０１６７】
サーバ側でこのようなチャンネル切り替えタイミングの制御を実行することで、クライアント側でのデコードエラーの発生が防止され、クライアント側ではチャンネル切り替え前のデータおよびチャンネル切り替え後のデータ再生を正常に実行することが可能となる。
【０１６８】
次に、図１２のシーケンス図を参照してライブストリーミングデータの配信処理を終了する場合の処理について説明する。ステップＳ３０１において、ストリーミングデータの配信およびイベント通知が実行されているとする。
【０１６９】
ライブストリーミングデータの配信処理を終了しようとするクライアント４６０は、ステップＳ３０２において、コネクションＩＤを格納したコネクション終了要求をコネクションマネージャサービス４３１に送信する。コネクションＩＤは、図９のシーケンス図のステップＳ１０６において、コネクションマネージャサービス４３１から受領したものである。コネクションマネージャサービス４３１は、クライアント４６０からの要求に従って、サーバクライアント間のコネクションの切断を行い、さらに、図１０を参照して説明したコネクション管理テーブルから対応エントリを削除する。
【０１７０】
なお、クライアント４６０は同じＡＶＴインスタンスを使用している他のクライアントの存在を知ることが、ステップＳ１０４の問い合わせ処理によって可能である。このチェックを前もって行うことで、どのファンクションＩＤ（ｆｕｎｃ−ｉｄ）を選択すれば空いているＡＶＴインスタンスを使えるかがわかる。このチェックを行い、他のクライアントに配慮した処理が可能となる。
【０１７１】
例えば、全てのＡＶＴインスタンスが使用されている場合などは、チャンネル変更時に「他に人が視聴している可能性があります。本当に良いですか？」等のメッセージをサーバからクライアント４６０に送信し、クライアント４６０においてメッセージ表示ＵＩを生成し、提示することにより、複数のクライアントが接続されたネットワークにおいて、他のクライアントの接続を不用意に制御する、例えばチャンネルを切り替えてしまうといったことが防止される。
【０１７２】
ステップＳ１０４のコネクション情報取得処理の詳細は、以下の通りである。まず、コンテンツ配信制御部４３０のコネクションマネージャサービス４３１に対し現接続コネクションＩＤ要求（ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩＤｓ）を行う。返り値として現在アクティブであるコネクションＩＤ（ＣｏｎｎｅｃｔｉｏｎＩＤ）の一覧が返される。各々のコネクションＩＤを用いてコネクション情報要求（ＧｅｔＣｕｒｒｅｎｔＣｏｎｎｅｃｔｉｏｎＩｎｆｏ）を行うと、そのコネクションＩＤでアサインされているプロトコル情報（ＰｒｏｔｏｃｏｌＩｎｆｏ）がわかる。このプロトコル情報の追加情報（ＡｄｄｉｔｉｏｎａｌＩｎｆｏ）に記載されるファンクションＩＤ（ｆｕｎｃ−ｉｄ）が自分が使用しようとしているファンクションＩＤと同じ場合は、同一の内部リソース（チューナなど）を扱っていることがわかる。
【０１７３】
上述したように、クライアント４６０は、コンテンツ配信制御部４３０のコネクションマネージャサービス（ＣＭＳ）４３１に対してＡＶＴインスタンスをアサインしてもらい、そのＡＶＴインスタンスにチューナコンテナに対応するチャンネルリストＵＲＬをセットすることによって、そのＵＲＬに基づくライブストリーミングが開始できる。
【０１７４】
なお、コンテンツ配信制御部４３０において、設定可能なＡＶＴインスタンスの数に制限がある場合は、コンテンツ配信制御部４３０のコネクションマネージャサービス（ＣＭＳ）４３１は、以下の処理を実行することで、ＡＶＴインスタンスの設定を制御する。
【０１７５】
既に制限数のＡＶＴインスタンスがアサインされている状態で、コネクションマネージャサービス（ＣＭＳ）４３１が、クライアントから新たにＡＶＴインスタンスを要求されたときには、古いコネクションが優先する。すなわち古いコネクションに基づいて設定されたＡＶＴインスタンスを新しい要求に基づいて切り替えることはしない。
【０１７６】
ただし、これはあくまでＡＶＴインスタンスの限度数の話であって、同じＡＶＴインスタンスを扱う要求であった場合には、たとえ既に他のクライアントに提供していても、異なるコネクションＩＤで同じＡＶＴインスタンスＩＤを新たに提供して良い。この場合には、複数のクライアントが１つのＡＶＴインスタンスに基づく制御を実行することが可能となる。
【０１７７】
具体的には１つのチャンネルリストＵＲＬの設定されたＡＶＴインスタンスの制御を２つ以上のクライアントが実行可能であり、いずれのクライアントからの制御命令、例えばチャンネル切り替え処理もその１つのＡＶＴインスタンスの制御の下に有効に実行されることになる。
【０１７８】
なお、コンテンツ配信制御部４３０が、ＡＶＴインスタンス−＃０とＡＶＴインスタンス−＃１の２つを持っているが、同時に１つのＡＶＴしか動作できないサーバの場合の処理は、例えば以下のａ〜ｆのように実行される。
ａ．最初、クライアント１からＡＶＴ−＃０をアサインするように要求
ｂ．コネクションＩＤ−１にＡＶＴインスタンスＩＤ−＃０をアサイン
ｃ．次に、クライアント２からＡＶＴ−＃０をアサインするように要求
ｄ．コネクションＩＤ−２にＡＶＴインスタンスＩＤ−＃０をアサイン
ｅ．次に、クライアント１からＡＶＴ−＃１をアサインするように要求
ｆ．クライアント１にエラーを返す
【０１７９】
このような処理を実行することで、ＡＶＴインスタンスの設定数の制限が可能となる。
【０１８０】
前述したように、チャンネルリストＵＲＬは、コンテンツディレクトリサービス（ＣＤＳ）４４２から得ることが可能である。チューナがプレイ状態、すなわちクライアントに対するコンテンツ配信状態にあるときは、このチャンネルリストＵＲＬに既にＨＴＴＰ−ＧＥＴに基づくコンテンツ要求を行っている全てのクライアント（サーバが複数クライアント対応時に限る）は、チャンネルリストＵＲＬがＡＶＴインスタンスにセットされたと同時にチューナのストリーミングを得ることができる。
【０１８１】
すなわち、他のクライアントによって使われているストリーミングを単にモニタしたい場合には、ＡＶＴインスタンスの設定を実行することなく、ストリーミング用のＵＲＬすなわち、コンテンツディレクトリサービス（ＣＤＳ）４４２から取得したチャンネルリストＵＲＬを設定したＨＴＴＰ−ＧＥＴメソッドを発行するのみで、チューナのストリーミングを得ることができる。
【０１８２】
サーバ４００のコンテンツ配信制御部４３０は、チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定されるチューナ４１０の受信する複数チャンネルのコンテンツの配信制御をＡＶＴインスタンスの制御の下に実行している間に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドを受信した場合、その要求クライアントは、ＡＶＴインスタンスの設定を行うことなく、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行することができる。
【０１８３】
［複数チューナを持つサーバ］
上述した例は、サーバにチューナが１つのみの例であるが、複数のチューナを搭載した構成も可能である。この場合には、各チューナに対応してチャンネルリストＵＲＬが対応付けられ、さらに個々に異なるＡＶＴインスタンスが設定されて制御が実行される。図１３にチューナを２つ持つサーバにおける処理構成例を示す。
【０１８４】
この場合、チューナＡ５１１、コーデックＡ５１２を介して１つのストリーミングコンテンツがクライアントに送信され、さらにチューナＢ５２１、コーデックＢ５２２を介して他の１つのストリーミングコンテンツがクライアントに送信される。
【０１８５】
コンテンツ配信制御部５００のコネクションマネージャサービス５３０は、それぞれのチューナ制御を実行するＡＶＴインスタンスを個別にアサインする。チューナコントロールインスタンス５３１は、チューナＡ５１１の制御を実行し、チューナコントロールインスタンス５３２は、チューナＢ５２１の制御を実行する。
【０１８６】
この場合、チューナコントロールインスタンス５３１にセットされるチャンネルリストＵＲＬは、チューナＡコンテナに対応するチャンネルリストＵＲＬ（Ａ）であり、チューナコントロールインスタンス５３２にセットされるチャンネルリストＵＲＬは、チューナＢコンテナに対応するチャンネルリストＵＲＬ（Ｂ）となる。
【０１８７】
それぞれのチューナを介してコンテンツを受信しているクライアントは、それぞれチューナコントロールインスタンス５３１または、チューナコントロールインスタンス５３２に対応するＡＶＴインスタンスＩＤを有し、それぞれのＡＶＴインスタンスＩＤを指定した制御が可能であり、それぞれ独立した制御が可能となる。
【０１８８】
なお、チューナとチャンネルリストの対応付けは、前述したように、チューナコンテナに対応して設定されるメタデータとして設定されるチャンネルリストＵＲＬによって決定される。上述した例では、チューナ１つに対して１つのチャンネルリストＵＲＬを対応付けた例を説明したが、チューナが複数ある場合には、チューナとチャンネルリストＵＲＬの対応付け態様は様々な設定が可能である。
【０１８９】
２つのチューナがある場合において、それぞれのチューナが地上波、ＢＳ双方とも受信可能な場合は、１つのチューナコンテナを設定し、２つのチャンネルリストＵＲＬをメタデータとして設定可能となる。チューナコンテナ６０１には地上波チャンネルアイテム６０２と、ＢＳチャンネルアイテム６０３が子アイテムとして設定される。
【０１９０】
チューナコンテナ６０１のメタデータとして、チャンネルリストＵＲＬ１（ｆｕｎｃＩＤ＝ａ）と、チャンネルリストＵＲＬ２（ｆｕｎｃＩＤ＝ｂ）との２つのチャンネルリストＵＲＬが設定されている。
【０１９１】
このような構成の場合、クライアントは、チューナコンテナ６０１のコンテンツ情報として２つのチャンネルリストＵＲＬ、およびそのチャンネル情報を知ることが可能となる。クライアントは、地上波を視聴したい場合は、地上波に対応するチャンネルリスト、例えばチャンネルリストＵＲＬ１（ｆｕｎｃＩＤ＝ａ）を選択して、図９に示す処理シーケンスにおけるステップＳ１０７のＡＶＴインスタンスのセット処理を実行すればよい。ＢＳ波を視聴したい場合は、ＢＳ波に対応するチャンネルリスト、例えばチャンネルリストＵＲＬ２（ｆｕｎｃＩＤ＝ｂ）を選択して、図９に示す処理シーケンスにおけるステップＳ１０７のＡＶＴインスタンスのセット処理を実行する。
【０１９２】
なお、このような構成の場合、ステップＳ１０３におけるコンテンツ配信制御部４３０のコネクションマネージャ４３１から送信されるプロトコル情報には、上述の２つのチャンネルリストＵＲＬのファンクションＩＤに対応する、
［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ａ］と、
［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｂ］との、
２つのチューナを介するストリーミングデータコンテンツに関する２つのプロトコル情報がそれぞれクライアントに通知されることになる。
【０１９３】
また、地上波ＢＳ兼用受信チューナが２つある場合において、一方を地上波専用、他方をＢＳ専用として使い分ける場合には、図１５に示すように、各チューナコンテナ６１１，６２１が設定される。地上波チューナコンテナ６１１には複数の地上波チャンネルアイテム６１２が設定される。ＢＳチューナコンテナ６２１には複数のＢＳチャンネルアイテム６２２が設定される。
【０１９４】
それぞれのチューナコンテナに設定するチャンネルリストＵＲＬを１つとすることも可能であるが、図１５に示す例では、２つのチューナコンテナのそれぞれに２つのチャンネルリストＵＲＬを設定している。
【０１９５】
このような構成とすることで、あるクライアントが１つのチューナを適用して地上波のあるチャンネルを視聴している場合、他のクライアントが他のチューナを利用して他の地上波チャンネルを視聴すること、同様に異なる２つのＢＳチャンネル、あるいは１つは地上波、他方はＢＳといった各タイプの組み合わせが可能となる。
【０１９６】
具体的には、２つの地上波を２つのチューナを介して視聴する場合は、地上波コンテナ６１１にあるチャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ１（ｆｕｎｃＩＤ＝ａ）と、チャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ２（ｆｕｎｃＩＤ＝ｂ）とをそれぞれことなるＡＶＴインスタンスにセットして、それぞれが異なるチューナの制御を行うことで２つの地上波がそれぞれのクライアントに送信される。
【０１９７】
２つのＢＳ波を２つのチューナを介して視聴する場合は、ＢＳ波コンテナ６２１にあるチャンネルリストＵＲＬ−ＢＳ１（ｆｕｎｃＩＤ＝ａ）と、チャンネルリストＵＲＬ−ＢＳ２（ｆｕｎｃＩＤ＝ｂ）とをそれぞれことなるＡＶＴインスタンスにセットして、それぞれが異なるチューナの制御を行うことで２つの地上波がそれぞれのクライアントに送信される。
【０１９８】
地上波とＢＳの場合は、地上波コンテナ６１１にあるチャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ１（ｆｕｎｃＩＤ＝ａ）と、ＢＳ波コンテナ６２１にあるチャンネルリストＵＲＬ−ＢＳ２（ｆｕｎｃＩＤ＝ｂ）、あるいは、地上波コンテナ６１１にあるチャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ２（ｆｕｎｃＩＤ＝ｂ）と、ＢＳ波コンテナ６２１にあるチャンネルリストＵＲＬ−ＢＳ１（ｆｕｎｃＩＤ＝ａ）との組み合わせによる制御を行うことで地上波およびＢＳ波のコンテンツがそれぞれ異なるチューナを介してクライアントに提供される。
【０１９９】
また、２つのチューナ中、１つは地上波専用チューナであり、他方は地上波ＢＳ兼用チューナである場合には、図１６に示すようなチャンネルリストＵＲＬの設定が可能である。
【０２００】
図１６に示すように、各チューナコンテナ６３１，６４１が設定される。地上波チューナコンテナ６３１には複数の地上波チャンネルアイテム６３２が設定される。ＢＳチューナコンテナ６４１には複数のＢＳチャンネルアイテム６４２が設定される。
【０２０１】
地上波チューナコンテナ６３１には２つのチャンネルリストＵＲＬが設定され、２つのチャンネルリストＵＲＬを同時に適用することが可能であり、地上波についてのみ、２つのチューナを利用して同時にストリーミング配信が可能となる。
【０２０２】
具体的には、２つの地上波を２つのチューナを介して視聴する場合は、地上波コンテナ６３１にあるチャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ１（ｆｕｎｃＩＤ＝ａ）と、チャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ２（ｆｕｎｃＩＤ＝ｂ）とをそれぞれことなるＡＶＴインスタンスにセットして、それぞれが異なるチューナの制御を行うことで２つの地上波がそれぞれのクライアントに送信される。
【０２０３】
地上波とＢＳの場合は、地上波コンテナ６１１にあるチャンネルリストＵＲＬ−Ｔｅｒｒｅｓｔｒｉａｌ２（ｆｕｎｃＩＤ＝ｂ）と、ＢＳ波コンテナ６２１にあるチャンネルリストＵＲＬ−ＢＳ１（ｆｕｎｃＩＤ＝ａ）との組み合わせによる制御を行うことで地上波およびＢＳ波のコンテンツがそれぞれ異なるチューナを介してクライアントに提供される。
【０２０４】
［サーバおよびクライアントの処理フロー］
チューナ受信データのライブストリーミング処理におけるサーバおよびクライアント各々の処理手順について、図１７および図１８のフローを参照して説明する。まず、クライアントにおける処理を図１７の処理フローを参照して説明する。
【０２０５】
クライアント装置は、ステップＳ５０１において、ブラウズまたはサーチ処理により、コンテンツ情報の取得要求を実行する。これは、コンテンツ管理部４４０（図６参照）のコンテンツディレクトリサービス４４２に対して実行する。
【０２０６】
ステップＳ５０２において、コンテンツ情報を受信する。ここでは、チューナを介したストリーミングデータの配信を実行するためチューナコンテナおよびチャンネルアイテムのコンテンツ情報を取得するものであり、図８（ａ）に示すチューナコンテナ対応のコンテンツ情報および、図８（ｂ）に示すチャンネル毎のコンテンツ情報に基づく情報を取得する。この処理により、チャンネルリストＵＲＬ、ファンクションＩＤ、チャンネル情報が取得される。
【０２０７】
クライアントは、次に、ステップＳ５０３において、コンテンツ配信制御部４３０のコネクションマネージャサービス４３１に対して、プロトコル情報取得要求を送信する。ステップＳ５０４において、コネクションマネージャサービス４３１から、プロトコル情報一覧を受信する。このプロトコル情報一覧に、ライブストリーミングデータの配信が可能であることを示すプロトコル情報［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］が含まれる。
【０２０８】
次に、ステップＳ５０５において、クライアントは、コネクションマネージャサービス４３１から、現在、サーバ４００に接続されている他のクライアントに関する情報を取得する。ステップＳ５０６において、クライアントは、コネクションマネージャサービス４３１に対して、接続準備要求（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）を送信する。クライアントが、チューナを適用したライブストリーミングデータの配信を希望する場合は、ステップＳ５０２において、コンテンツディレクトリサービス（ＣＤＳ）４４２から受領したチューナコンテナに対応するコンテンツ情報中のファンクションＩＤ（ｆｕｎｃＩＤ）と一致するファンクションＩＤを持つプロトコル情報を送信する。
【０２０９】
ステップＳ５０７において、クライアントは、コネクションＩＤと、チューナコントロールインスタンスとして設定（アサイン）したＡＶＴインスタンスの識別子（ＡＶＴインスタンスＩＤ）を受信する。
【０２１０】
ステップＳ５０８において、クライアントは、アサインされたＡＶＴインスタンスに対して、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）セット要求を発行する。ＡＶＴインスタンスに対してセットするＵＲＩには、コネクションマネージャサービス４３１から通知されたＡＶＴインスタンスＩＤと、ステップＳ５０２において取得したチューナコンテナに対応するコンテンツ情報に含まれるチャンネルリストＵＲＬが含まれる。
【０２１１】
ここまでの処理が、ＡＶＴインスタンスによるチューナ制御を可能とするための設定処理である。これ以降は、クライアントは、ＡＶＴインスタンスに対して制御要求を発行することで、コンテンツ送信、停止、チャンネル切り替えなどの様々な制御が可能となる。
【０２１２】
ステップＳ５０９において、クライアントはＡＶＴインスタンスに対してコンテンツの制御要求を実行する。例えば、再生（Ｐｌａｙ）要求、チャンネル切り替え（Ｓｅｅｋ）要求である。クライアントは、ＸＭＬデータに従った記述データを生成し、各種の制御情報をＡＶＴインスタンス４３３に送信する。
【０２１３】
ステップＳ５１０においてクライアント側ユーザがチャンネル切り替えを行いたいと判断した場合は、ステップＳ５１１において、クライアントはチャンネル切り替え（Ｓｅｅｋ）要求をＡＶＴインスタンスに対して発行する。この制御要求には、ＡＶＴインスタンスＩＤと切り替えチャンネル番号を格納する。ステップＳ５１２において、接続終了すると判断した場合は、コネクションＩＤを格納したコネクション終了要求をコネクションマネージャサービス４３１に送信する。コネクションＩＤは、ステップＳ５０７において、コネクションマネージャサービス４３１から受領したものである。
【０２１４】
次に、サーバ側の処理について、図１８の処理フローを参照して説明する。ステップＳ６０１において、コンテンツ管理部４４０（図６参照）のコンテンツディレクトリサービス４４２は、クライアントからのコンテンツ情報取得要求を受信する。ここではチューナコンテナおよびチャンネルアイテムのコンテンツ情報の取得要求があったものとする。
【０２１５】
ステップＳ６０２において、コンテンツディレクトリサービス４４２は、クライアントに対して、チューナコンテナおよびチャンネルアイテムのコンテンツ情報を送信する。図８（ａ）に示すチューナコンテナ対応のコンテンツ情報および、図８（ｂ）に示すチャンネル毎のコンテンツ情報であり、チャンネルリストＵＲＬ、ファンクションＩＤ（ｆｕｎｃＩＤ）、チャンネル情報を含む情報である。
【０２１６】
ステップＳ６０３において、サーバのコンテンツ配信制御部４３０のコネクションマネージャサービス４３１は、クライアントからプロトコル情報取得要求を受信する。ステップＳ６０４において、コネクションマネージャサービス４３１は、プロトコル情報一覧をクライアントに送信する。コネクションマネージャサービス４３１がクライアントに送信するプロトコル情報一覧には、ライブストリーミングデータの配信が可能であることを示す情報［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］なるプロトコル情報が含まれる。
【０２１７】
次に、ステップＳ６０５において、コネクションマネージャサービス４３１は、クライアントに、現在、サーバ４００に接続されている他のクライアントに関する情報を提供する。コネクションマネージャサービス４３１は、図１０に示すコネクション管理テーブルに基づいてコネクション情報を提供する。
【０２１８】
ステップＳ６０６において、コネクションマネージャサービス４３１はクライアントから接続準備要求（ＰｒｅｐａｒｅＦｏｒＣｏｎｎｅｃｔｉｏｎ）を受信する。クライアントが、チューナを適用したライブストリーミングデータの配信を希望している場合は、先にコンテンツディレクトリサービス（ＣＤＳ）４４２が送信したコンテンツ情報としてのチューナコンテナに対応するコンテンツ情報に含まれるファンクションＩＤ（ｆｕｎｃＩＤ）が、接続準備要求に含まれる。
【０２１９】
クライアントから接続準備要求を受信したコネクションマネージャサービス４３１は、接続準備要求に含まれるプロトコル情報［ｉｎｔｅｒｎａｌ：１．２．３．４：ａｐｐｌｉｃａｔｉｏｎ／ｘ−ａｖ−ｔｕｎｅｒ−ｃｏｎｔｅｎｔ：ｆｕｎｃ−ｉｄ＝ｔ０１］に基づいて、チューナによる受信データのストリーミング配信の要求であると判断し、ステップＳ６０７において、コンテンツ対応制御部４３２内の１つのＡＶＴインスタンス４３３をチューナコントロールインスタンスとして設定（アサイン）し、接続準備要求を送信してきたクライアントに対するコネクションＩＤと、チューナコントロールインスタンスとして設定（アサイン）し、ＡＶＴインスタンスの識別子（ＡＶＴインスタンスＩＤ）とのバインド処理、すなわち対応付け、図１０に示すコネクション管理テーブルに対するエントリ設定を行い、ステップＳ６０８において、コネクションＩＤとＡＶＴインスタンスＩＤをクライアントに通知する。
【０２２０】
ステップＳ６０９において、ＡＶＴインスタンスが、クライアントからＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）セット要求を受信すると、ステップＳ６１０において、ＡＶＴインスタンスＩＤとチャンネルリストＵＲＬとを、ＡＶＴインスタンスＵＲＩとしてＡＶＴインスタンスにセットする。
【０２２１】
ＡＶＴインスタンスは、クライアントから指定されたＡＶＴインスタンスＩＤと、チャンネルリストＵＲＬとに基づいて、自己の制御対象コンテンツおよびクライアントを識別することが可能となる。すなわち、ＡＶＴインスタンスＩＤを指定して各種の制御命令を送信するクライアントをＡＶＴインスタンスに対応するクライアントとして認識し、チャンネルリストＵＲＬによって対応付けられるチューナが制御対象となる。チャンネルリストＵＲＬは、チューナコンテナの対応コンテンツであり、チャンネルリストＵＲＬをセットしたＡＶＴインスタンスは、チューナ４１０の制御を実行するインスタンスとして設定されることになる。
【０２２２】
次にステップＳ６１１において、ＡＶＴインスタンスが、コンテンツ制御要求を受信すると、ステップＳ６１２において、ＡＶＴインスタンス４３３は、クライアントからの受信情報に基づくチューナ制御、例えばコンテンツ再生開始、終了、チャンネル切り替えなどの処理を実行する。ＡＶＴインスタンス４３３は、セットされたコンテンツＵＲＬに基づいて制御対象コンテンツを特定し、その特定された制御対象コンテンツを制御する。この場合は、コンテンツＵＲＬはチャンネルリストＵＲＬであり、チャンネルリストＵＲＬはチューナコンテナに対応するコンテンツ情報であり、ＡＶＴインスタンス４３３はチューナ４１０の制御を実行する。
【０２２３】
ステップＳ６１３において、チャンネル切り替え（Ｓｅｅｋ）要求を受信したと判定した場合は、ステップＳ６１４において、ＡＶＴインスタンス４３３はチューナ４１０を制御し、チューナのチャンネルを切り替える。このチャンネル切り替えの前後におけるサーバクライアント間のＨＴＴＰコネクションは、同一のＵＲＬ、すなわち同じチャンネルリストＵＲＬに基づくＨＴＴＰコネクションであるため、サーバクライアント間においてはコネクションが維持されたままチャンネル切り替えが実行される。
【０２２４】
ステップＳ６１５において、コネクションＩＤを格納したコネクション終了要求をコネクションマネージャサービス４３１が受信したと判定した場合は、ステップＳ６１６において、クライアントからの要求に従って、サーバクライアント間のコネクションの切断を行い、さらに、図１０を参照して説明したコネクション管理テーブルから対応エントリを削除する。
【０２２５】
なお、前述したように、サーバからクライアントに対して送信される画像または音声データを、例えばＭＰＥＧ等の符号化データとした場合、クライアントから受信するチャンネル切り替えのタイミングに基づいて無条件に送信データの切り替えを実行すると、送信する符号化データパケットの不整合が発生する場合がある。例えばＭＰＥＧ−２システムに規定されるパック（Ｐａｃｋ）の構成パケットであるＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）パケットの一部を送信中に、チャンネル切り替えを実行して、送信データを変更すると、クライアントにおいてデコードする際の１つの処理単位であるパック（Ｐａｃｋ）に欠落が発生し、再生エラーを発生させることになる。
【０２２６】
従って、サーバは、ステップＳ６１３において、チャンネル切り替え（Ｓｅｅｋ）要求を受信したと判定した場合は、クライアントからのチャンネル切り替え要求に基づく送信データの変更により、送信符号化データの整合性の保持が可能か否かを判定し、整合性が保持されないと判断した場合は、ステップＳ６１４のＡＶＴインスタンス４３３のチューナ４１０の制御によるチャンネル切り替えの実行前にサーバクライアント間のデータストリーム配信用の接続コネクション、すなわち、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションを切断し、クライアントに対して、イベント通知用コネクションを介して、データストリーム配信用の接続コネクションが切断されたことの通知処理を実行し、その後、ステップＳ６１４のＡＶＴインスタンス４３３のチューナ４１０の制御によるチャンネル切り替えを実行する。
【０２２７】
クライアントは、サーバからコネクション切断通知を受信した場合は、再度、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションを設定する処理、すなわち、チャンネルリストＵＲＬに基づくＨＴＴＰ−ＧＥＴメソッドをサーバに対して送信する。なお、ＡＶＴインスタンス（チューナコントロールインスタンス４３３）の設定状態は維持されているので、チューナコントロールインスタンス４３３の新たなアサイン、ＵＲＩセット等の設定処理は省略可能である。
【０２２８】
なお、前述したように、サーバは、コーデック４２０のデータエンコード状況を検出し、検出情報をチューナコントロールインスタンス４３３に入力し、チューナコントロールインスタンス４３３のタイミング制御の下にチューナ４１０のチャンネル切り替えを実行する構成としてもよく、この場合は、ステップＳ６１３における、チャンネル切り替え（Ｓｅｅｋ）要求受信後、コーデック４２０のデータエンコード状況の検出情報に基づいて、チューナコントロールインスタンス４３３が、クライアントに対して送信する符号化データの整合性を保持可能なタイミングにおいて、ステップＳ６１４のＡＶＴインスタンス（チューナコントロールインスタンス４３３）のチューナ４１０の制御によるチャンネル切り替えを実行する。
【０２２９】
サーバ側でこのようなチャンネル切り替えタイミングの制御を実行することで、クライアント側でのデコードエラーの発生が防止され、クライアント側ではチャンネル切り替え前のデータおよびチャンネル切り替え後のデータ再生を正常に実行することが可能となる。
【０２３０】
［サーバおよびクライアントの機能構成］
サーバおよびクライアント装置のハードウェア構成については、先に図２を参照して説明した通りであり、上述した各種の処理、例えば図１７、図１８のフローを参照して説明した処理は、サーバクライアントそれぞれの記憶部に格納されたプログラムに従って主にＣＰＵの制御の下に実行される。上述した処理を実行するために必要となるサーバの機能構成とクライアントの機能構成について図１９および図２０を参照して説明する。
【０２３１】
図１９は、サーバの主要機能構成を示すブロック図である。基本的に図６に示す構成に対応するが、図１９の構成ではチューナを２つ持つ構成例を示してある。パケット送受信部７０１は、クライアントに対するパケット、クライアントからのパケットを受信する。パケット生成、解析部７０２は、送信パケットの生成処理、受信パケットの解析処理を行う。パケットのアドレス設定、アドレス認識、データ部に対するデータ格納、データ部からのデータ取得処理などである。
【０２３２】
チューナＡ７０３は、チューナＢ７０４は、地上波、ＢＳ、ＣＳ等の衛星放送、インターネット、その他の通信網を介するデータを受信するチューナである。
【０２３３】
コンテンツ記憶部７０５は、サーバの保有するコンテンツを格納する。各コンテンツはコンテンツＵＲＬによって特定可能である。イベント情報記憶部７０６は、コンテンツに対応するイベント情報を格納する。各イベント情報はイベントＵＲＬによって特定可能である。
【０２３４】
コーデック７０７は、サーバの保有するコンテンツ、チューナ受信コンテンツをクライアントからの要求に対応したデータ態様に変換する。ファイルフォーマット、コーデック、解像度等の変換を実行する。例えばＡＴＲＡＣ３、ＭＰＥＧ４に基づくデータ変換を実行する。
【０２３５】
コンテンツ管理部は、コンテンツ管理を実行する処理部であり、メタデータ記憶部７１３は、コンテンツに対応する属性情報としてのメタデータを格納した記憶部である。メタデータ記憶部７１３には、前述したように、コンテナ等の描くブジェクト対応のメタデータを構成するプロパティ情報が格納される。例えば、チューナコンテナのプロパティ情報として、チャンネルリストＵＲＬが設定される。コネクションマネージャサービス７１１は、クライアントからのコンテンツ情報要求に応じて、メタデータに基づいてコンテンツ情報を生成する。コネクションマネージャサービス７１１は、コンテンツ管理部におけるクライアントとの接続を管理し、コンテンツ管理部において処理可能なプロトコル情報等をクライアントに提供する。
【０２３６】
コンテンツ配信制御部７２０は、クライアントに対する配信コンテンツの制御を実行し、コネクションマネージャサービス７２１とコンテンツ対応制御部７２２を有する。コンテンツ対応制御部７２２には配信コンテンツに対応してＡＶＴインスタンス７２３が設定され、具体的なコンテンツの配信制御は、各コンテンツに対応するＡＶＴインスタンスが実行する。
【０２３７】
コネクションマネージャサービス７２１は、ＡＶＴインスタンスをアサインし、コネクションＩＤ、ＡＶＴインスタンスＩＤ、プロトコル情報を対応付けて管理するコネクション管理テーブル（図１０参照）を設定してコネクション管理を行う。
【０２３８】
次に、クライアント装置の機能構成について、図２０を参照して説明する。パケット送受信部８０１は、サーバに対するパケット、サーバからのパケットを受信する。パケット生成、解析部８０２は、送信パケットの生成処理、受信パケットの解析処理を行う。パケット内の格納データ解析のみならず、パケットのアドレス設定、アドレス認識、データ部に対するデータ格納、データ部からのデータ取得処理なども含む。
【０２３９】
記憶部８０３は、サーバから受信したパケットに含まれるコンテンツ情報、コンテンツ、チャンネル情報、チャンネルリストＵＲＬ、ファンクションＩＤ、イベント情報、コネクションＩＤ、ＡＶＴインスタンスＩＤ等を格納する。
【０２４０】
出力部８０４は、コンテンツ再生処理に適用するスピーカ、ディスプレイを含む。なお、ディスプレイは、先に図４を参照して説明した表示情報の出力にも利用される。入力部８０５は、例えば、表示情報として表示されたコンテンツ情報としてのチャンネルリストの選択、チャンネル情報に基づくチャンネル選択など、ユーザの入力を実行するためのキーボード、その他のデータ入力手段である。
【０２４１】
コンテンツ情報解析部８０６は、サーバから受信したコンテンツ情報からなるＸＭＬデータを解析し、解析データに基づいて、先に図４を参照して説明したコンテンツＵＲＬ、チャンネルリストＵＲＬまたはこれらのリンクデータを含む表示情報を生成し、出力部としてのディスプレイに出力する処理を実行する。
【０２４２】
コンテンツ再生制御部８０７は、サーバから受信するコンテンツの再生制御を実行する。なお、コンテンツ再生処理おいては、必要に応じてデータ変換部８０８において、サーバからの受信コンテンツの変換処理を実行する。例えばＡＴＲＡＣ３、ＭＰＥＧ４に基づくデータ復号処理等を実行する。
【０２４３】
サーバ、およびクライアントは、機能的には図１９、図２０に示す各機能を有し、上述した各処理を実行する。ただし、図１９、図２０に示すブロック図は、機能を説明するブロック図であり、実際には、図２に示すＰＣ等のハードウェア構成におけるＣＰＵの制御の下に各種の処理プログラムが実行される。
【０２４４】
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０２４５】
なお、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。
【０２４６】
例えば、プログラムは記録媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に予め記録しておくことができる。あるいは、プログラムはフレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することができる。
【０２４７】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送したり、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０２４８】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【０２４９】
【発明の効果】
以上、説明したように、本発明においては、チャンネルの集合体としてのチャンネルリストにＵＲＬを設定し、クライアントが、チャンネルリストＵＲＬを指定したコンテンツ取得要求をサーバに送信することで、クライアントは、チャンネルリストにリストアップされたチャンネル、すなわちコンテンツ管理ディレクトリにおいて、チューナコンテナの下位に設定されたチャンネルアイテムの全てのコンテンツの取得、すなわち制御権をまとめて得ることができる。結果として、チャンネルリストにリストされたチャンネル間の切り替えにおいては、新たなＵＲＬに基づくコンテンツ要求を行う必要がない。
【０２５０】
また、本発明の構成においては、チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行することができるので、クライアントは、チャンネル切り替え等の制御命令をコンテンツ配信制御部に送信するのみで、チャンネル切り替えが可能となり、従って、新旧ＵＲＬの切り替えに基づくサーバクライアント間のコネクションの再設定等の処理が不要となる。すなわち、チャンネルリスト中のチャンネルを切り替えるときは、ＡＶＴインスタンスに対してチャンネル切り替え要求（ＡＶＴ Ｓｅｅｋ ａｃｔｉｏｎ）を行うのみで、コンテンツ配信コネクションとしてのＨＴＴＰコネクションを継続的に使用して、チャンネル切り替え前後のコンテンツを受信することができる。
【０２５１】
また、本発明の構成においては、チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定されるチューナの受信する複数チャンネルのコンテンツの配信制御をＡＶＴインスタンスの制御の下に実行している間に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドを受信した場合、その要求クライアントは、ＡＶＴインスタンスの設定を行うことなく、チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行することができる。
【図面の簡単な説明】
【図１】本発明の適用可能なネットワーク構成例を示す図である。
【図２】ネットワーク接続機器の構成例について説明する図である。
【図３】サーバにおけるコンテンツ管理ディレクトリ構成について説明する図である。
【図４】コンテンツ情報表示例を示す図である。
【図５】コンテンツデータ再生処理におけるサーバクライアント間の処理シーケンスについて説明する図である。
【図６】チューナ受信データのストリーミング配信処理を実行するサーバの構成を示す図である。
【図７】サーバにおけるコンテンツ管理ディレクトリ構成中のチューナコンテナおよびチャンネルアイテムについて説明する図である。
【図８】チューナコンテナおよびチャンネルアイテムに対応するコンテンツ情報について説明する図である。
【図９】チューナ受信データのストリーミング配信処理を実行するサーバクライアント間の処理シーケンスについて説明する図である。
【図１０】チューナ受信データのストリーミング配信処理を実行するサーバの保有するコネクション管理テーブルの構成データについて説明する図である。
【図１１】チューナ受信データのストリーミング配信処理を実行するサーバクライアント間の処理シーケンス中のチャンネル切り替え処理について説明する図である。
【図１２】チューナ受信データのストリーミング配信処理を実行するサーバクライアント間の処理シーケンス中のコネクション終了処理について説明する図である。
【図１３】複数チューナを持つサーバによるチューナ受信データのストリーミング配信処理について説明する図である。
【図１４】チューナコンテナとチャンネルリストＵＲＬとの対応例について説明する図である。
【図１５】チューナコンテナとチャンネルリストＵＲＬとの対応例について説明する図である。
【図１６】チューナコンテナとチャンネルリストＵＲＬとの対応例について説明する図である。
【図１７】チューナ受信データのストリーミング配信処理を実行するサーバの処理を説明するフローチャート図である。
【図１８】チューナ受信データのストリーミング配信処理を実行するクライアントの処理を説明するフローチャート図である。
【図１９】サーバの処理機能を説明するブロック図である。
【図２０】クライアントの処理機能を説明するブロック図である。
【符号の説明】
１００ ネットワーク
１０１ サーバ
１２１ ＰＣ
１２２ モニタ
１２３ 携帯電話
１２４ 再生機
１２５ ＰＤＡ
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ ＨＤＤ
２０５ バス
２０６ 入出力インタフェース
２０７ 入力部
２０８ 出力部
２０９ 通信部
２１０ ドライブ
２１１ リムーバブル記録媒体
２２０ チューナ
３０１ ルートコンテナ
３０２〜３０９ オブジェクト
３５０ ディスプレイ
３５７ コンテンツ情報
４００ サーバ
４１０ チューナ
４２０ コーデック
４３０ コンテンツ配信制御部
４３１ コネクションマネージャサービス
４３２ コンテンツ対応制御部
４３３ ＡＶＴインスタンス
４４０ コンテンツ管理部
４４１ コネクションマネージャサービス
４４２ コンテンツディレクトリサービス
４４３ データベース
４６０ クライアント
４７０ ユーザ
４８１ ルートコンテナ
４８２ チューナコンテナ
４８３〜４８５ チャンネルアイテム
４９１ ファンクションＩＤ
４９２ チャンネルリストＵＲＬ
５００ コンテンツ配信制御部
５１１ チューナＡ
５１２ コーデックＡ
５２１ チューナＢ
５２２ コーデックＢ
５３０ コネクションマネージャサービス
５３１，５３２ チューナコントロールインスタンス
６０１ チューナコンテナ
６０２，６０３ チャンネルアイテム
６１１ チューナコンテナ
６１２ チャンネルアイテム
６２１ チューナコンテナ
６２２ チャンネルアイテム
６３１ チューナコンテナ
６３２ チャンネルアイテム
６４１ チューナコンテナ
６４２ チャンネルアイテム
７０１ パケット送受信部
７０２ パケット生成、解析部
７０３ チューナＡ
７０４ チューナＢ
７０５ コンテンツ記憶部
７０６ イベント情報記憶部
７０７ コーデック
７１０ コンテンツ管理部
７１１ コネクションマネージャサービス
７１２ コンテンツディレクトリサービス
７１３ メタデータ記憶部
７２０ コンテンツ配信制御部
７２１ コネクションマージャサービス
７２２ コンテンツ対応制御部
７２３ ＡＶＴインスタンス
８０１ パケット送受信部
８０２ パケット生成、解析部
８０３ 記憶部
８０４ 出力部
８０５ 入力部
８０６ コンテンツ情報解析部
８０７ コンテンツ再生制御部
８０８ データ変換部

Claims (29)

1. クライアントに対するコンテンツ送信処理を実行するコンテンツ提供サーバであり、
   データ受信処理を実行するチューナと、
   前記チューナによる受信コンテンツおよび制御情報のサーバクライアント間の通信処理を実行するデータ送受信部と、
   コンテンツに対応する属性情報をコンテンツ情報として格納した記憶部と、
   前記コンテンツ情報のクライアントに対する提供処理を実行するコンテンツ管理部と、
   前記チューナを介した受信コンテンツのクライアントに対するライブストリーミング配信制御を実行するコンテンツ配信制御部とを有し、
   前記記憶部は、
   前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストの識別情報としてのチャンネルリスト識別子を、チューナ受信コンテンツに対応するコンテンツ情報として格納し、
   前記コンテンツ配信制御部は、
   前記チャンネルリストに記述された複数チャンネルに対応するチューナの受信する複数コンテンツを制御コンテンツの一単位として設定し、クライアントから受信するチャンネルリスト識別子に対応する制御要求に基づいて、前記チャンネルリストに記述された複数チャンネルに対応する配信コンテンツの制御を実行する構成であることを特徴とするコンテンツ提供サーバ。
2. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
   前記記憶部は、前記チューナ受信コンテンツに対応する属性情報として前記チャンネルリストＵＲＬを格納し、
   前記コンテンツ配信制御部は、
   クライアントからの制御要求に従って前記チャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
3. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
   サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
   前記コンテンツ配信制御部は、
   前記チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
4. 前記コンテンツ情報には、
   コンテンツ対応のプロトコル情報が含まれ、
   前記チューナを介した受信コンテンツに対応して設定されるプロトコル情報には、チューナ識別情報としてのファンクションＩＤを含み、
   前記コンテンツ配信制御部は、
   チューナ受信コンテンツの制御を実行する制御インスタンスを、前記ファンクションＩＤに基づいて決定される制御対象チューナの制御を実行する制御インスタンスとして設定する処理を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
5. 前記コンテンツ配信制御部は、
   配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記チューナ受信コンテンツの制御を実行するチューナ制御インスタンスは、クライアントからの制御要求に基づいて、前記チューナの制御を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
6. 前記コンテンツ配信制御部は、
   配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記制御インスタンスの識別子としてのインスタンスＩＤと、サーバクライアント間のコネクション識別子であるコネクションＩＤと、配信コンテンツに対応するプロトコル情報とを対応付けたコネクション管理テーブルに基づくコネクション管理を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
7. 前記コンテンツ配信制御部は、
   配信コンテンツ毎のコンテンツ配信制御を実行する制御インスタンスを設定して、制御インスタンスに基づくコンテンツ毎の配信制御を実行する構成であり、前記制御インスタンスは、識別子としてのインスタンスＩＤを設定され、クライアントからの制御インスタンスＩＤを指定した制御要求に応じて、コンテンツ配信制御を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
8. 前記コンテンツ配信制御部は、
   ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルに従った配信コンテンツの制御要求をクライアントから受信し、該制御要求に基づいて、チューナ受信コンテンツの配信制御を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
9. 前記チャンネルリストは、カテゴリ毎に区分された複数チャンネルからなるリストとして設定された構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
10. 前記コンテンツ配信制御部は、
    前記チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行中に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドの受信に応じて、該チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
11. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記コンテンツ配信制御部は、
    前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えにより、クライアントに対する送信符号化データの整合性の保持可能性を判定し、整合性が保持されないと判定した場合には、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションの切断を実行する構成であり、
    前記コンテンツ提供サーバは、さらに、
    サーバクライアント間のイベント通知コネクションを介してチャンネルリストＵＲＬに基づいて設定されたＨＴＴＰコネクションの切断情報を通知する処理を実行する構成を有することを特徴とする請求項１に記載のコンテンツ提供サーバ。
12. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記コンテンツ配信制御部は、
    クライアントに対する送信符号化データの整合性の保持可能なタイミングにおいて、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えをチューナ制御により実行する構成であることを特徴とする請求項１に記載のコンテンツ提供サーバ。
13. サーバに設定されたチューナの受信コンテンツをサーバから受信する情報処理装置であり、
    チューナ受信コンテンツを提供するサーバとのデータ送受信処理を実行するデータ送受信部と、
    前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するとともに、前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御部と、
    を有することを特徴とする情報処理装置。
14. 前記制御部は、
    前記サーバから受信するコンテンツ情報に含まれるプロトコル情報中の、チューナ識別情報としてのファンクションＩＤを格納した接続準備要求を前記サーバに対して送信し、該接続準備要求の応答として、前記サーバから受信するチューナ受信コンテンツの制御を実行する制御インスタンスのＩＤを取得し、該制御インスタンスＩＤを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する構成を有することを特徴とする請求項１３に記載の情報処理装置。
15. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記制御部は、
    前記チャンネルリストに記述された複数チャンネル間の切り替え前後におけるコンテンツ受信を、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用して実行する構成であることを特徴とする請求項１３に記載の情報処理装置。
16. コンテンツ提供サーバに設定されたチューナによる受信コンテンツをクライアントに送信するコンテンツ送信制御方法であり、
    前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストに記述された複数のチャンネルに対応するチューナ受信コンテンツを制御対象のコンテンツ単位として設定した制御インスタンスを設定する制御インスタンス設定ステップと、
    前記制御インスタンスに対するクライアントからの制御要求を受信する制御要求受信ステップと、
    前記制御要求に基づいて、前記制御インスタンスによるチューナ制御を実行する制御ステップと、
    を有することを特徴とするコンテンツ送信制御方法。
17. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    前記制御インスタンス設定ステップは、
    前記チャンネルリストＵＲＬを制御インスタンスに対応付けるステップを含むことを特徴とする請求項１６に記載のコンテンツ送信制御方法。
18. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記制御ステップは、
    前記チャンネルリストに記述された複数チャンネルに対応する複数のチューナ受信コンテンツの切り替えとして実行されるチャンネル切り替え前後において、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用したコンテンツ配信を実行することを特徴とする請求項１６に記載のコンテンツ送信制御方法。
19. 前記コンテンツ情報には、
    コンテンツ対応のプロトコル情報が含まれ、
    前記チューナを介した受信コンテンツに対応して設定されるプロトコル情報には、チューナ識別情報としてのファンクションＩＤを含み、
    前記制御インスタンス設定ステップは、
    チューナ受信コンテンツの制御を実行する制御インスタンスを、前記ファンクションＩＤに基づいて決定される制御対象チューナの制御を実行する制御インスタンスとして設定する処理を実行することを特徴とする請求項１６に記載のコンテンツ送信制御方法。
20. 前記コンテンツ送信制御方法は、さらに、
    前記制御インスタンスの識別子としてのインスタンスＩＤと、サーバクライアント間のコネクション識別子であるコネクションＩＤと、配信コンテンツに対応するプロトコル情報とを対応付けたコネクション管理テーブルに基づくコネクション管理を実行するステップを含むことを特徴とする請求項１６に記載のコンテンツ送信制御方法。
21. 前記制御要求受信ステップは、
    ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）プロトコルに従った配信コンテンツの制御要求をクライアントから受信するステップであることを特徴とする請求項１６に記載のコンテンツ送信制御方法。
22. 前記コンテンツ送信制御方法において、さらに、
    前記チャンネルリスト識別子としてのチャンネルリストＵＲＬに基づいて特定される前記チューナの受信する複数チャンネルのコンテンツの配信制御を実行中に、他クライアントからの同一のチャンネルリストＵＲＬを指定したコンテンツ要求としてのＨＴＴＰ−ＧＥＴメソッドの受信に応じて、該チャンネルリストＵＲＬに基づくＨＴＴＰコネクションにより、チャンネルリストＵＲＬに基づいて特定されるチューナ受信コンテンツの配信を実行するステップを含むことを特徴とする請求項１６に記載のコンテンツ送信制御方法。
23. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記コンテンツ送信制御方法は、さらに、
    前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えにより、クライアントに対する送信符号化データの整合性の保持可能性を判定し、整合性が保持されないと判定した場合には、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションの切断を実行するステップと、
    サーバクライアント間のイベント通知コネクションを介してチャンネルリストＵＲＬに基づいて設定されたＨＴＴＰコネクションの切断情報を通知するステップと、
    を含むことを特徴とする請求項１６に記載のコンテンツ送信制御方法。
24. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記制御ステップは、
    クライアントに対する送信符号化データの整合性の保持可能なタイミングにおいて、前記チャンネルリストに記述された複数チャンネルのチャンネル間切り替えをチューナ制御により実行するステップを含むことを特徴とする請求項１６に記載のコンテンツ送信制御方法。
25. サーバに設定されたチューナの受信コンテンツをサーバから受信する情報処理方法であり、
    前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するコンテンツ送信要求ステップと、
    前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御要求ステップと、
    を有することを特徴とする情報処理方法。
26. 前記コンテンツ送信要求ステップは、
    前記サーバから受信するコンテンツ情報に含まれるプロトコル情報中の、チューナ識別情報としてのファンクションＩＤを格納した接続準備要求を前記サーバに対して送信するステップを含み、
    前記制御要求ステップは、
    前記接続準備要求の応答として、前記サーバから受信するチューナ受信コンテンツの制御を実行する制御インスタンスのＩＤを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行するステップを含むことを特徴とする請求項２５に記載の情報処理方法。
27. 前記チャンネルリスト識別子は、チャンネルリストＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）であり、
    サーバクライアント間のチューナ受信コンテンツの配信用コネクションは、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）コネクションであり、
    前記情報処理方法は、
    前記チャンネルリストに記述された複数チャンネル間の切り替え前後におけるコンテンツ受信を、前記チャンネルリストＵＲＬに基づいて設定されるＨＴＴＰコネクションを継続的に使用して実行することを特徴とする請求項２５に記載の情報処理方法。
28. コンテンツ提供サーバに設定されたチューナによる受信コンテンツをクライアントに送信するコンテンツ送信制御処理を実行するコンピュータ・プログラムであり、
    前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むチャンネルリストに記述された複数のチャンネルに対応するチューナ受信コンテンツを制御対象のコンテンツ単位として設定した制御インスタンスを設定する制御インスタンス設定ステップと、
    前記制御インスタンスに対するクライアントからの制御要求を受信する制御要求受信ステップと、
    前記制御要求に基づいて、前記制御インスタンスによるチューナ制御を実行する制御ステップと、
    を有することを特徴とするコンピュータ・プログラム。
29. サーバに設定されたチューナの受信コンテンツをサーバから受信するための情報処理を実行するコンピュータ・プログラムであり、
    前記チューナの受信チャンネル中、少なくとも複数チャンネルを含むリストの識別子であるチャンネルリスト識別子に基づくコンテンツ送信要求を前記サーバに対して送信するコンテンツ送信要求ステップと、
    前記サーバにおいてコンテンツ配信制御を実行する制御インスタンスを指定したチューナ受信コンテンツの配信制御要求の送信処理を実行する制御要求ステップと、
    を有することを特徴とするコンピュータ・プログラム。

Images