クライアント端末、コンテンツ受信方法、およびセッション管理装置
【課題】メタデータをもとにコンテンツを配信可能なサーバとのセッションの制御を実現する。
【解決手段】このクライアント端末は、コンテンツの場所を示す情報と、コンテンツを配信可能なサーバから当該コンテンツを受信するためのセッションを確立するために必要な情報を含むメタデータを取得するメタデータ取得部と、取得したメタデータをもとに、コンテンツの場所を示す情報を格納する宛先部とセッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、生成されたメッセージを、前記セッションの制御を行うことが可能なサーバに送信するメッセージ送信部とを具備する。
【解決手段】このクライアント端末は、コンテンツの場所を示す情報と、コンテンツを配信可能なサーバから当該コンテンツを受信するためのセッションを確立するために必要な情報を含むメタデータを取得するメタデータ取得部と、取得したメタデータをもとに、コンテンツの場所を示す情報を格納する宛先部とセッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、生成されたメッセージを、前記セッションの制御を行うことが可能なサーバに送信するメッセージ送信部とを具備する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツを配信可能なサーバとの間にセッションを確立してコンテンツを視聴するクライアント端末、コンテンツ受信方法、およびセッション管理装置に関するものである。
【背景技術】
【０００２】
IPTV（Internet Protocol Television）は、IPを利用してデジタルテレビ放送を配信するサービス、またはその放送技術の総称である。IPTVのセッション制御の標準候補はIMS（IP Multimedia Sub-system）である。ETSIやITU-T（International Telecommunication Union Telecommunication Standardization Sector）でのNGN（Next Generation Network）の標準化においては、IMSが前提となっている。NGNはIP技術をベースとした次世代の基幹ネットワークである。
【０００３】
IMSは、パケット通信を利用した携帯電話のマルチメディアサービスのこと、あるいはそのようなサービスを実現するための標準である。IMSでは、SIP（Session Initiation Protocol）と呼ばれるIP電話の方式を利用して、マルチメディアセッションをセキュアにかつQoSを保証して制御することができる。すなわち、IMSでは、IPTVのセッションを確立する際に、SIPを利用して、セキュアでQoSの保証されたエンド・ツゥ・エンドのパスを確保して、IPTVのストリーミング等のセッションを制御することができる。
【０００４】
この場合、セッションを確立するために必要なパラメタ（例えばQoS制御のためのパラメタ）がSDP（Session Description Protocol）に記述される。このSDPをボディ部に格納したSIP-INVITEメッセージを、IMS-SIPサーバとコンテンツの提供者がもつ端末との間、さらにはIMS-SIPサーバとコンテンツを視聴するユーザのもつ端末との間で相互に交換することにより、エンド・ツゥ・エンドでセッションを確立するためのパラメタのネゴシエーションが行われる。また、SIP-INVITEメッセージの宛先を示すSIP-URI（Uniform Resource Identifier）には、相手の人（ユーザ）を指定することにより、しかるべきアドレス解決（名前から端末のアドレスへのマッピング）がなされて相手の持っている端末にメッセージが届きセッションが確立される。
【０００５】
特許文献１においては、IMS-SIPを用いたセッション制御の例が挙げられている。すなわち、画像通信装置間で画像通信を行うためのセッションを確立するために、要求元である画像通信装置からの送信要求パケットを受信したADSLゲートウェイからVoIPサービス業者のSIPプロキシに対して、SIPの仕様に基づくセッション要求メッセージ（INVITEメッセージ）を送信し、SIPプロキシは、セッション要求メッセージのヘッダに記述されている宛先のアドレス解決後に、その宛先のADSLゲートウェイへセッション要求メッセージ（INVITEメッセージ）を送信することとしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１４７１２８号参照（段落００４６等）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、IMS-SIPをIPTVのセッション制御に応用するためには、SIP-INVITEメッセージ等、セッションの確立を促すためのメッセージに、視聴対象のコンテンツならびにコンテンツを提供するサーバへアドレス解決できる情報と、コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタを記述したSDPを格納することが必要になる。
【０００８】
セッションの確立を促すためのメッセージは、IPTVクライアントアプリケーション１３がコンテンツのメタデータをもとに作成しているが、この場合に次のような問題があった。
【０００９】
IPTV（Internet Protocol Television）の標準化における標準メタデータフォーマットの候補がTV-Anytimeメタデータである。TV-Anytimeメタデータは、ETSI（European Telecommunications Standards Institute）で規格化されたメタデータの標準である。例えば、DVB（Digital Video Broadcasting）でのIPTV標準や、ITU-TにおけるIPTV標準のメタデータフォーマットとしてTV-Anytimeメタデータが候補となっている。
【００１０】
しかしながら、TV-Anytimeメタデータの規格においては、IMS上でのIPTVセッションの制御に必要な情報を格納する規定がないため、現状では、TV-AnytimeメタデータをもとにIMS上でのIPTVセッションの制御を実現することができなかった。
【００１１】
また、一般的なIPTVシステムでは、図２０に示すように、IPTVクライアント端末１０とIPTVサーバ２０との間でコンテンツを視聴するためのセッションが確立されるまでに、アクセス制御２１０つまりどのユーザがどのコンテンツにアクセスできるかのアクセス権の制御のためのシグナリング（メッセージ交換）と、セッション制御２２０つまりコンテンツを視聴するためのセッションを確立する制御のためのシグナリングとが分離して行われる。
【００１２】
図２１は、この一般的なIPTVシステムにおいて、IPTVクライアント端末１０とIPTVサーバ２０との間で、コンテンツの視聴のためのIPTVセッションが確立されるまでの手順を示すシーケンス図である。
【００１３】
メタデータサーバ４０は、IPTVクライアント端末１０のEPG（Electronic program Guide）アプリケーション１４からの、コンテンツのメタデータの取得要求を受けて、コンテンツのメタデータを応答する(ステップＳ８０１)。このコンテンツのメタデータには、例えば、コンテンツのタイトル、そのコンテンツを識別するコンテンツID、そのコンテンツを配信するIPTVサーバのURLなどが記述されている。
【００１４】
EPGアプリケーション１４は、メタデータを取得した後（ステップＳ８０２）、このメタデータをもとにコンテンツの検索・選択用のインタフェース画面を作成してユーザに呈示する（ステップＳ８０３）。このインタフェース画面を用いて、ユーザによって、視聴したいコンテンツの検索・選択が行われると、EPGアプリケーション１４は、その選択されたコンテンツを特定し（ステップＳ８０４）、取得したメタデータからそのコンテンツのコンテンツIDを取り出し、このコンテンツIDをIPTVクライアントアプリケーション１３に渡す。
【００１５】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４よりコンテンツIDを受けると、そのコンテンツIDを含む、当該コンテンツに対するアクセス権の確認を要求するメッセージをネットワークを通じてアクセス制御サーバ３１に送信する(ステップＳ８０５)。アクセス制御サーバ３１は、このアクセス権確認要求のメッセージを受信すると、これに含まれるコンテンツIDをもとにアクセス権確認の処理を行う(ステップＳ８０６)。コンテンツのアクセス権を許諾する場合、アクセス制御サーバ３１は、アクセス権許諾の応答メッセージをネットワークを通じてIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に送信するとともに、IPTVサーバ２０に当該コンテンツのアクセス権をIPTVクライアント端末１０に許諾したことを示すメッセージを送信する。
【００１６】
IPTVクライアントアプリケーション１３は、コンテンツのアクセス権許諾の応答を受信した場合には、当該コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタ（例えばQoS制御のためのパラメタ等）の取得を要求するメッセージを、ネットワークを介して、そのコンテンツの配信元であるIPTVサーバ２０に送信する（ステップＳ８０７）。このパラメタ取得要求のメッセージには、視聴対象のコンテンツのコンテンツID等も含まれている。
【００１７】
IPTVサーバ２０は、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３からのパラメタ取得要求のメッセージを受けると、このメッセージに含まれる視聴対象のコンテンツのコンテンツIDと、アクセス制御サーバ３１より事前に受信したアクセス権許諾のメッセージの内容とから、そのパラメタ取得要求が、IPTVクライアント端末１０に対してアクセス権許諾済みのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタの所得要求であるかどうかを判定し、そうであれば、必要なパラメタを検索し、検索したパラメタをネットワークを通じてIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に応答する(ステップＳ８０８)。
【００１８】
この後、IPTVクライアントアプリケーション１３は、取得したパラメタをもとに当該コンテンツを視聴するためのセッションの確立に必要なネットワークリソースの確保を要求するメッセージを生成し、これをネットワークを通じてネットワークリソース管理サーバ３２とIPTVサーバ２０にそれぞれ送信する (ステップＳ８０９)。
【００１９】
ネットワークリソース管理サーバ３２は、このネットワークリソース確保要求のメッセージを受信すると、このメッセージに含まれているパラメタをもとに当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保のための処理を行う(ステップＳ８１０)。一方、IPTVサーバ２０は、ネットワークリソース確保要求のメッセージを受信すると、このメッセージに含まれているパラメタをもとに当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースを確保し（ステップＳ８１１）、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間でIPTVセッションを確立する処理を行う(ステップＳ８１２及びステップＳ８１３)。
【００２０】
このように、一般的なIPTVシステムでは、IPTVクライアント端末１０とIPTVサーバ２０との間でコンテンツを視聴するためのセッションが確立されるまでに、アクセス制御２１０のためのシグナリングと、セッション制御２２０のためのシグナリングとが行われ、プロトコル処理のオーバヘッドが嵩むという問題があった。
【００２１】
本発明は、かかる実情に鑑み、メタデータをもとにコンテンツを配信可能なサーバとのセッションの制御を実現することのできるコンテンツを配信可能なサーバとの間にセッションを確立してコンテンツを視聴するクライアント端末、コンテンツ受信方法、およびセッション管理装置を提供しようとするものである。
【課題を解決するための手段】
【００２２】
上記の課題を解決するために、本発明の第１の側面のクライアント端末は、コンテンツの視聴のために当該コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得するメタデータ取得部と、前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するメッセージ送信部とを具備する。
【００２３】
本発明によれば、メッセージ生成部が、取得したメタデータから、コンテンツを配信可能なサーバからコンテンツを受信するためのセッションの確立を促すためのメッセージを生成し、メッセージ送信部がこのメッセージをセッションを確立する制御を行うサーバに送信することで、クライアント端末とコンテンツを配信可能なサーバとの間でのセッションが確立される。
【００２４】
前記セッションを確立するために必要な情報はQoS（Quality of Service）の制御のための情報を含むものであってよい。
【００２５】
前記クライアント端末は携帯機器であってよい。
【００２６】
本発明の第２の側面であるコンテンツ受信方法は、コンテンツを受信するためのセッションを確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得し、前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するというものである。
【００２７】
本発明の第３の側面であるセッション管理装置は、コンテンツの視聴のために前記コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得することが可能なクライアント端末より、前記コンテンツを識別するためのコンテンツ識別子および前記セッションを確立するために必要な情報を含むセッション確立要求を受信し、前記コンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記セッションの制御を行うことが可能なサーバに送信するセッション処理部を具備するものである。
【発明の効果】
【００２８】
本発明によれば、メタデータをもとにコンテンツを配信可能なサーバとのセッションの制御を実現することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明の第１の実施形態にかかるIPTVシステムでのIMS上のIPTVセッション制御の概要を示す図である。
【図２】図１のIPTVシステムにおいてIMS-SIPによるセッション制御にアクセス制御のシグナリングを組み込んだ状態を示す図である。
【図３】図１のIPTVシステムの全体的な構成を示す図である。
【図４】図１のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図５】SIP-URI及びSDPを格納したTV-Anytimeメタデータの例を示す図である。
【図６】SDP要素の導入のためのXMLスキーマの拡張に必要なXMLスキーマのシンタクスの例を示す図である。
【図７】メタデータサーバでのTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図８】SIP-INVITEメッセージのフォーマットを示す図である。
【図９】TV-AnytimeメタデータにtransportQuality要素を導入する拡張のためのXMLスキーマのシンタクスの例を示す図である。
【図１０】図９のtransportQuality要素導入のXMLスキーマ拡張により、転送品質等のQoSパラメタが格納されたTV-Anytimeメタデータの例を示す図である。
【図１１】transportQualityCS制限用語辞書の定義の例を示す図である。
【図１２】VisualCodingFormatCS制限用語辞書の定義の例を示す図である。
【図１３】本発明の第２の実施形態にかかるSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【図１４】メタデータサーバでの図１３に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図１５】sipURI属性導入の拡張のためのXMLスキーマのシンタクスの例を示す図である。
【図１６】sipURI属性を導入するXMLスキーマ拡張によりSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【図１７】メタデータサーバでの図１６に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図１８】IPTVクライアント端末のハードウェアの構成を示すブロック図である。
【図１９】サーバのハードウェアの構成を示すブロック図である。
【図２０】一般的なIPTVシステムにおける、アクセス制御のためのシグナリングとセッション制御のためのシグナリングとの関係を示す図である。
【図２１】一般的なIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間で、コンテンツの視聴のためのIPTVセッションが確立されるまでの手順を示すシーケンス図である。
【図２２】本発明の第４の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図２３】第４の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図２４】インスタンス選択基準の設定画面の例を示す図である。
【図２５】IPTVクライアント端末からIMSゲートウェイに送信されるセッション確立要求に含まれるリストの例を示す図である。
【図２６】第４の実施形態の変形例１である動作を示すフローチャートである。
【図２７】優先度選択画面とユーザによる各インスタンスの優先度の選択例を示す図である。
【図２８】コンテンツの選択画面の例を示す図である。
【図２９】第４の実施形態の変形例１である動作を示すフローチャートである。
【図３０】本発明の第５の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図３１】本発明の第６の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図３２】第６の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図３３】デバイス／ユーザ優先度を設定するための画面の構成を示す図である。
【図３４】２つのIPTVクライアント端末からIMSゲートウェイに送信された２つのセッション確立要求に含まれるリストの例を示す図である。
【図３５】第７の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図３６】図３５から続くシーケンス図である。
【図３７】第７の実施形態の変形例を示すフローチャートである。
【図３８】第６の実施形態の変形例を示すシーケンス図である。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面を用いて詳細に説明する。
【００３１】
図１は、本発明の第１の実施形態にかかるIPTVシステム１００でのIMS上のIPTVセッション制御の概要を示す図である。
【００３２】
同図に示すように、この実施形態のIPTVシステム１００では、コンテンツを視聴するユーザが持つIPTVクライアント端末１０とコンテンツを配信するIPTVサーバ２０との間で、IMSプラットフォームを提供するサーバ群３０を介して、SIP-INVITEメッセージ、SIP-BYEメッセージ等のSIPメッセージを交換する。これにより、IPTVクライアント端末１０とIPTVサーバ２０との間での、コンテンツを視聴するためのIPTVセッションの確立／解放等の制御が行われる。
【００３３】
図３は、図１のIPTVシステム１００の全体的な構成を示す図である。
【００３４】
同図に示すように、このIPTVシステム１００は、コンテンツを視聴するユーザ１が持つIPTVクライアント端末１０、コンテンツを配信するIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０、及びこれらを接続可能なネットワーク３とで構成される。
【００３５】
IPTVクライアント端末１０は、例えば、PC、セットップボックス、TV等の端末機器である。IPTVクライアント端末１０は、ユーザインタフェース部１１、ネットワークインタフェース部１２、IPTVクライアントアプリケーション１３、EPGアプリケーション１４、メタデータ記憶部１５、コンテンツ記憶部１６、コンテンツ再生部１７等を備える。
【００３６】
ユーザインタフェース部１１は、ユーザ１に対する入出力を処理する。例えば、ユーザインタフェース部１１は、ユーザ１からの各種の指令を入力して、IPTVクライアントアプリケーション１３やEPGアプリケーション１４に出力したり、IPTVクライアントアプリケーション１３やEPGアプリケーション１４からユーザ１への応答やコンテンツの再生情報を出力する処理などを行う。
【００３７】
ネットワークインタフェース部１２は、インターネット等のネットワーク３とのインタフェースを提供する。
【００３８】
IPTVクライアントアプリケーション１３は、IPTVクライアント端末１０をIPTVクライアントとして動作させるための制御を行うソフトウエアである。
【００３９】
EPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０よりコンテンツのメタデータを取得する処理、このメタデータを用いて視聴対象のコンテンツをユーザ１に検索・選択させるためのインタフェース画面を作成する処理、さらには、このインタフェース画面でユーザ１によって選択されたコンテンツを視聴するためのIPTVセッションの確立を促すためのメッセージの作成に必要な情報をメタデータより抽出して、IPTVクライアントアプリケーション１３に渡す処理等を行う。
【００４０】
メタデータ記憶部１５は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置で構成され、メタデータサーバ４０より取得したコンテンツのメタデータを格納する。
【００４１】
コンテンツ記憶部１６は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置で構成され、IPTVセッションが確立されたIPTVサーバ２０よりストリーミングやダウンロード等により受信したコンテンツのデータを格納する。
【００４２】
コンテンツ再生部１７は、コンテンツ記憶部１６に格納されたコンテンツのデータのデコードから再生までの処理を行う。
【００４３】
メタデータサーバ４０は、IPTVクライアント端末１０のEPGアプリケーション１４からの取得要求に応じて、自身に管理されているコンテンツのメタデータを送信する。
【００４４】
IMSプラットフォームを提供するサーバ群３０は、コンテンツに対するアクセス権の確認等の制御を行うアクセス制御サーバ３１、IPTVセッションを確立するために必要なネットワークリソースを管理するネットワークリソース管理サーバ３２、IMS-SIPを用いてIPTVセッションの確立／解放等の制御を行うIMS-SIPサーバ３３等で構成される。
【００４５】
IMS-SIPサーバ３３は、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３よりSIP-INVITEメッセージを受信したとき、このSIP-INVITEメッセージの宛先に格納されたSIP-URIを用いてアクセス制御サーバ３１に対して当該コンテンツのアクセス権の確認を依頼する処理を行う。また、IMS-SIPサーバ３３は、アクセス制御サーバ３１よりそのコンテンツのアクセス権の許諾を受けたとき、SIP-INVITEメッセージのボディ部に格納されたSDPを用いてネットワークリソース管理サーバ３２に対して、当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保を依頼する処理を行う。さらに、IMS-SIPサーバ３３は、ネットワークリソース管理サーバ３２よりネットワークリソースの確保応答を受信したとき、IPTVクライアントアプリケーション１３より受信したSIP-INVITEメッセージを、このSIP-INVITEメッセージの宛先に格納されたSIP-URIをもとに該当するIPTVサーバ２０に送信する処理を行う。
【００４６】
IPTVサーバ２０は、配信可能なコンテンツのデータを管理しており、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間で、コンテンツの視聴のためのIPTVセッションを確立して、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３に対して、コンテンツのストリーミングあるいはダウンロード等による配信を行う。
【００４７】
図１８は、IPTVクライアント端末１０のハードウェアの構成を示すブロック図である。同図に示すように、CPU（Central Processing Unit）５０１には、システムバス５０２を介して、ROM（Read Only Memory）５０３と、RAM（Random Access Memory）５０４と、入力操作部５０５と、表示部５０６と、音声出力部５０７と、ネットワークインタフェース部１２と、光通信部５１１と、記憶部５１２とが接続されている。
【００４８】
入力操作部５０５は、各種のキーなどを備え、ユーザからの各種の命令やデータの入力を処理する。入力操作部５０５によってユーザより入力された命令は、図示しない入力インタフェース部によってシステムバス５０２を通じてCPU５０１に供給される。表示部５０６は、例えば、LCD（Liquid Crystal Display）などの表示器と、表示器を駆動する表示制御回路よりなる。音声出力部５０７は、デジタルの音声信号をアナログの音声信号に変換する回路と、スピーカなどよりなる。入力操作部５０５、表示部５０６、音声出力部５０７は、図３のユーザインタフェース部１１に相当する。ネットワークインタフェース部１２は、ネットワーク３との有線または無線での接続を処理する。
【００４９】
光通信部５１１は、リモートコントローラやその他の外部機器との間での通信を処理するためのインタフェースであり、具体的には、赤外線などの光を無線媒体として外部機器との通信を行うものである。また、光の他に、電波、音波、電磁波などの他の無線媒体を用いてもよい。記憶部５１２は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置である。
【００５０】
ROM５０３は、IPTVクライアント端末１０としての機能をコンピュータに実行させるためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部５１２に格納されていてもよい。RAM５０４は、ROM５０３や記憶部５１２からロードされたプログラムやプログラムの作業データ等を書き込むために使用されるメモリである。CPU５０１は、ROM５０３に格納されたプログラムやRAM５０４にロードされたプログラムを解釈実行するための演算処理を行う。
【００５１】
図１９は、IPTVサーバ２０、アクセス制御サーバ３１、ネットワークリソース管理サーバ３２、IMS-SIPサーバ３３、メタデータサーバ４０のハードウェアの構成を示すブロック図である。
【００５２】
IPTVサーバ２０、アクセス制御サーバ３１、ネットワークリソース管理サーバ３２、IMS-SIPサーバ３３、メタデータサーバ４０はいずれも、図１９に示すように、パーソナルコンピュータなどの典型的なコンピュータシステムからなる構成とされている。
【００５３】
すなわち、CPU６０１には、システムバス６０９を介して、ROM６０２と、RAM６０３と、ネットワークインタフェース部６０４と、キーボード、マウスなどよりなる入力部６０５と、CRT（Cathode Ray Tube）、LCDなどよりなるディスプレイとスピーカなどよりなる出力部６０６と、メディアインタフェース部６０７と、ハードディスクドライブや不揮発性メモリなどよりなる記憶部６０８とが接続されている。
【００５４】
ネットワークインタフェース部６０４は、ネットワーク３との有線または無線での接続を処理する。記憶部６０８には、特定のサーバとしての機能をコンピュータに実行させるためのプログラムと、各種のデータなどが格納されている。CPU６０１は、ROM６０２や記憶部６０８からプログラムをRAM６０２へロードして、解釈実行するための演算処理を行う。メディアインタフェース部６０７には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２が適宜装着され、それらから読み出されたプログラムが、必要に応じて記憶部６０８にインストールされる。
【００５５】
次に、本実施形態のIPTVシステム１００において、IPTVクライアント端末１０とIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を説明する。
【００５６】
図４は、この動作を示すシーケンス図である。IPTVクライアント端末１０においては、IPTVクライアントアプリケーション１３及びEPGアプリケーション１４が既に起動されているものとする。
【００５７】
メタデータサーバ４０は、コンテンツのメタデータを作成して格納しており（ステップＳ１０１）、IPTVクライアント端末１０のEPGアプリケーション１４より、メタデータの取得要求を受けたとき、そのIPTVクライアント端末１０のEPGアプリケーション１４にコンテンツのメタデータを提供する(ステップＳ１０２)。IPTVクライアント端末１０のEPGアプリケーション１４は、メタデータサーバ４０よりコンテンツのメタデータを受信し、メタデータ記憶部１５に格納する（ステップＳ１０３）。
【００５８】
EPGアプリケーション１４は、取得したメタデータをもとに、コンテンツの検索・選択用のインタフェース画面を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ１０４）。このインタフェース画面を用いて、ユーザ１によって、視聴したいコンテンツの検索・選択が行われると（ステップＳ１０５）、EPGアプリケーション１４は、ユーザ１によって視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたメタデータから当該視聴対象コンテンツの場所を指定するSIP-URIと、このコンテンツに対応するSDPを抽出してIPTVクライアントアプリケーション１３に渡す（ステップＳ１０６）。
【００５９】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より取得したSIP-URI及びSDPを用いて、そのコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージを生成し（ステップＳ１０７）、このSIP-INVITEメッセージを、ネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する（ステップＳ１０８）。
【００６０】
IMSプラットフォームを提供するサーバ群３０において、IMS-SIPサーバ３３は、IPTVクライアント端末１０のEPGアプリケーション１４からのSIP-INVITEメッセージを受信すると、このSIP-INVITEメッセージからSIP-URIを抽出し、このSIP-URIを少なくとも含む、コンテンツのアクセス権の確認を依頼するメッセージをアクセス制御サーバ３１に送信する。アクセス制御サーバ３１は、このアクセス権確認依頼のメッセージに含まれるSIP-URIをもとに当該コンテンツのアクセス権の確認を行う（ステップＳ１０９）。アクセス制御サーバ３１は、当該コンテンツのアクセス権を許諾することを判定した場合には、IMS-SIPサーバ３３にアクセス権許諾の応答メッセージを送信し、当該コンテンツのアクセス権を許諾しないことを判定した場合には、IMS-SIPサーバ３３にアクセス権非許諾の応答メッセージを送信する。以後、アクセス権が許諾された場合について説明を続ける。
【００６１】
IMS-SIPサーバ３３は、アクセス権許諾の応答メッセージを受信すると、SIP-INVITEメッセージのボディ部からSDPを抽出し、このSDPを用いて、ネットワークリソースの確保を要求するメッセージを生成してネットワークリソース管理サーバ３２に送信する。ネットワークリソース管理サーバ３２はネットワークリソース確保要求のメッセージを受けると、これに含まれるSDPをもとに、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保のための処理を行った後（ステップＳ１１０）、IMS-SIPサーバ３３にネットワークリソースの確保応答のメッセージを送信する。IMS-SIPサーバ３３は、ネットワークリソースの確保応答のメッセージを受信すると、SIP-INVITEメッセージの宛先をもとに、SIP-INVITEメッセージをIPTVサーバ２０に送信する（ステップＳ１１１）。
【００６２】
IPTVサーバ２０は、IMS-SIPサーバ３３よりIMS-INVITEメッセージを受信すると、コンテンツを視聴するためのIPTVセッションを確立するために必要なネットワークリソースを確保し(ステップＳ１１２)、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間でIPTVセッションを確立する処理を行う(ステップＳ１１３及びステップＳ１１４)。
【００６３】
この後、図示は省略したが、確立されたIPTVセッションを用いて、IPTVサーバ２０からIPTVクライアント端末１０のIPTVクライアントアプリケーション１３への、ストリーミングまたはダウンロードによるコンテンツのデータの配信が行われる。
【００６４】
コンテンツのメタデータのフォーマットにはTV-Anytimeを用いることとする。このTV-Anytimeの規格には、IMS上のIPTVセッション制御に必要な情報を提供する規定が設けられていない。そこで、この実施形態においては、IMS上のIPTVセッション制御に必要な情報である、コンテンツの場所を指定するSIP-URIと、このコンテンツを視聴するためのセッションの確立に必要なパラメタが記述されたSDPを、次のような方法でTV-Anytimeメタデータに格納している。
【００６５】
次に、TV-Anytimeメタデータにコンテンツの場所を指定するSIP-URI及びSDPを格納する方法について説明する。
【００６６】
図５にSIP-URI及びSDPを格納したTV-Anytimeメタデータの例を示す。
【００６７】
TV-AnytimeメタデータはTVAMain要素５０をルート要素に持つXML（Extensible Markup Language）ドキュメントである。ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置される。さらにその下にはProgramInformationTable要素５２、ProgramLocationTable要素５３が配置される。ProgramInformationTable要素５２の下には、１つ以上のProgramInformation要素５４を配置できる。ProgramInformation要素５４の下には、コンテンツのタイトルが格納されるTitle要素５６、その他のコンテンツのメタデータが格納される要素（図示せず）を子要素として有するBasicDescription要素５７が配置されている。また、ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRID（Content Reference Identifier）が格納される。
【００６８】
CRIDのフォーマットは、"crid://<CRID_Authority"のDNS名>/<CRID_Authority内で一意な識別子>"とされ、例えば、"crid://ca.com/123"のように定義される。CRID_Authorityは、CRIDを一意（スコープはCRID_Ahthority）に振り出すエンティティである。
【００６９】
ProgramLocationTable要素５３の下には、ProgramLocation要素の派生であるOnDemandProgram要素５５を１つ以上配置できる。OnDemandProgram要素５５の下には、CRIDをcrid属性の値として格納するProgram要素６１、コンテンツの場所を指定するSIP-URIが格納されるprogramURL要素５９、InstanceDescription要素６０が配置されている。
【００７０】
TV-Anytimeにおいて、ProgramURLは、"An element specifying a programme location."と定義されており、コンテンツの場所は、通常、"http://..."等のURL（Uniform Resource Locator）で指定される。本実施形態では、コンテンツの場所を指定するために、SIPのメッセージの宛先であるSIP-URIが採用されている。SIP-URIは、例えば、"sip:ca.com_123@as.sp.com"のような形式で指定される。ここで、"ca.com_123"は、CRIDである"crid://abc.com/123"において、URLにおけるスキームを示す"crid:"と"//"を削除し、セパレータである"/"を"_"に置換して生成される。"@"以降の"as.sp.com"は、IPTVサーバ２０のDNS（Domain Name System）名である。
【００７１】
InstanceDescription要素６０の下には、コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタである、例えば、セッション名、セッション生成者、セッション有効期間、メディア記述として音声や動画を送受信するために必要なコーデックの情報等を含むSDPを格納するSDP要素６２が配置されている。しかし、TV-Anytimeの規格には、SDPを格納できる要素が定められていないので、この実施形態では、オリジナルのTV-Anytimeメタデータに対するXMLスキーマで定義されるInstanceDescription要素に対応する型であるInstanceDescriptionType要素を拡張して、SDPを格納するためのSDP要素６２を新たに導入している。
【００７２】
図６はこのSDP要素の導入のためのXMLスキーマ拡張に必要なXMLスキーマのシンタクスの例である。このXMLスキーマのシンタクスには、オリジナルのTV-Anytimeメタデータを識別する名前空間６３、XMLスキーマを識別する名前空間６４、新しく定義するスキーマが"urn:IPTV"で識別されることの宣言６５、新しいXMLスキーマにおけるInstanceDescriptionTypeの定義６６、拡張するオリジナルのTV-Anytimeの要素の指定６７、追加する属性であるSDPの定義６８が含まれている。
【００７３】
図５に示したTV-Anytimeメタデータの例では、InstanceDescription要素６０内のxsi:type属性によるオーバーライドによって、上述のXMLスキーマの拡張で導入された名前空間"urn:IPTV"のInstanceDescriptionType型を参照することにより、オリジナルのTV-AnytimeメタデータのInstanceDescription要素が、このXMLスキーマの拡張で定義されたSDP要素６２を持つInstanceDescription要素６０に置換される。
【００７４】
図７は、メタデータサーバ４０での図５に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【００７５】
メタデータサーバ４０で図５に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まず、ProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、OnDemandProgram要素５５におけるProgram要素６１のcrid属性の値として"crid://ca.com/123"を格納する。これにより、ProgramInformation要素５４とOnDemandProgram要素５５とがcrid属性の値によって紐付けられる。次に、メタデータサーバ４０は、OnDemandProgram要素５５におけるprogramURL要素５９に、crid属性の値である"crid://ca.com/123"とコンテンツの配信元であるIPTVサーバ２０のDNS名"as.sp.com"とから生成した"sip:ca.com_123@as.sp.com"をコンテンツの場所を指定するSIP-URIとして格納する。さらに、メタデータサーバ４０は、そのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタを含むSDPを、XMLスキーマの拡張で、InstanceDescription要素６０の下に導入されたSDP要素６２に格納する。ここまでで、１つのコンテンツに関するSIP-URI及びSDPの格納が完了となる。実際には、複数のコンテンツについてSIP-URI及びSDPの格納が繰り返され、その都度、ProgramInformationTable要素５２内のProgramInformation要素５４とProgramLocationTable要素５３内のOnDemandProgram要素５５が追加されて行くこととなる（ステップＳ１０１）。
【００７６】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ１０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ１０４）。この画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ１０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【００７７】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、取得したTV-Anytimeメタデータから、Program要素６１のcrid属性の値が"crid://ca.com/123"であるOnDemandProgram要素５５のProgramURL要素５９に格納されたSIP-URIである"sip:ca.com_123@as.sp.com"と、そのOnDemandProgram要素５５内のInstanceDescription要素６０の下に配置されたSDP要素６２のSDPの内容を取り出してIPTVクライアントアプリケーション１３に渡す（ステップＳ１０６）。
【００７８】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡されたSIP-URIである"sip:ca.com_123@as.sp.com"をSIP-INVITEメッセージの宛先に格納するとともに、EPGアプリケーション１４より渡されたSDPを、SIP-INVITEメッセージのボディ部に格納する。これによってコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージが生成される（ステップＳ１０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ１０８）。以後の動作は、図４を参照して説明したとおりである。
【００７９】
図８は、SIP-INVITEメッセージのフォーマットを示す図である。ここで、SIP-INVITEメッセージの宛先であるSIP-URIの部分７１には、視聴しようとしているコンテンツへアドレス解決できる情報、つまり上記の例においては"sip:ca.com_123@as.sp.com"が格納され、ボディ部７２にはSDPが格納される。IPTVシステム１００では、このSIP-INVITEメッセージを、IMS-SIPサーバ３３を介してIPTVクライアント端末１０とIPTVサーバ２０との間で相互に交換することにより、コンテンツを視聴するためのIPTVセッションを確立するためのパラメタのネゴシエーションが行われる。
【００８０】
次に、図５に示したTV-Anytimeメタデータの変形例を説明する。
【００８１】
図５に示したTV-AnytimeメタデータのSDP要素６２の"SDPの内容"の部分にはSDPの記述そのものが格納されるが、SDP要素６２内に表現される、例えば、コーデックやQoSパラメタ等の情報については、このままではXMLの要素としては抽出することはできない。市場に浸透してきているネイティブXMLデータベースのようなXML要素やその属性をそのまま検索の対象として扱えるようなデータベースに、SDPを含むTV-Anytimeメタデータを格納する場合、SDPの内容をベースに検索することができないこととなる。これらのデータベースにメタデータを格納し、コーデックやQoSパラメタ等の情報をもとに、対象となるメタデータを検索させるためには、以下の変形例のような方法を用いることが必要となる。
【００８２】
SDPの基本的な内容のうち、コーデックについては、オリジナルのTV-AnytimeメタデータのProgramLocation要素内のInstanceDescription要素内のAVAttributes要素内のVideoAttributes要素内のCoding要素に記述できるが、転送品質等のQoSパラメタを記述できる要素／属性は、オリジナルのTV-Anytimeメタデータには規定されていない。
【００８３】
そこで、この変形例では、転送品質等のQoSパラメタをTV-Anytimeメタデータに記述して検索、照会できるように、ProgramLocation要素内のInstanceDescription要素内のAVAttributes要素内に、転送品質等のQoSパラメタを格納するためのtransportQuality要素を新たに導入するように、XMLスキーマの拡張を行うこととする。
【００８４】
次に、このtransportQuality要素の導入のためのXMLスキーマの拡張方法の詳細を説明する。
【００８５】
図９は、このtransportQuality要素導入の拡張のためのXMLスキーマのシンタクスの例である。このXMLスキーマの拡張のためのシンタクスには、新しいXMLスキーマにおけるAVAttributesTypeの定義８１、拡張するオリジナルのTV-Anytimeの要素の指定８２、追加する属性であるtransportQualityの定義８３等が含まれている。
【００８６】
図１０は、このtransportQuality要素導入のXMLスキーマ拡張により、転送品質等のQoSパラメタが格納されたTV-Anytimeメタデータの例である。
【００８７】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置される。さらにその下にはProgramInformationTable要素５２、ProgramLocationTable要素５３が配置される。ProgramInformationTable要素５２の下には、１つ以上のProgramInformation要素５４が配置される。ProgramInformation要素５４には、ストリーミングもしくはダウンロード等により配信されるコンテンツのタイトル等のメタデータが記述される。ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRIDが格納される。
【００８８】
ProgramLocationTable要素５３の中には、ProgramLocation要素の派生であるOnDemandProgram要素５５が１つ以上配置される。OnDemandProgram要素５５の下には、CRIDが格納されたProgram要素６１と、コンテンツの場所を指定するSIP-URIが格納されたProgramURL要素５９と、InstanceDescription要素６０とが配置されている。
【００８９】
InstanceDescription要素６０の下には、SDP要素６２と、AVAttributes要素８４が配置されている。AVAttributes要素８４の下には、コーデックの情報が記述されるCoding要素８６を子要素としてもつVideoAttributes要素８７が配置されている。そして、この例では、AVAttributes要素８４のxsi:type属性によるオーバーライドにより、上述のXMLスキーマ拡張で導入された名前空間"urn:IPTV"のAVAttributes型を参照することにより、オリジナルのTV-AnytimeメタデータのAVAttributes要素を、このXMLスキーマ拡張で定義されたtransportQuality要素８５を持つAVAttributes要素８４に置換している。
【００９０】
transportQuality要素８５はControlledTermTypeであるが、この型は、制限用語辞書を参照する型である。このため、参照する辞書を、例えば以下のように定義する。
【００９１】
図１１に、transportQualityCS制限用語辞書の定義の例を示す。ここで定義されている３つの転送品質クラスを示すAssuredForwarding、ExcellentEffort、BestEffortの制限用語の間の関係は、品質クラスが高い（遅延やジッターが小さい）ものから、AssuredForwarding、ExcellentEffort、BestEffortの順となる。以下の辞書定義においては、それぞれAssuredForwardingが"urn:iptv:transportQualityCS:1"に、ExcellentEffortが"urn:iptv:transportQualityCS:2"に、BestEffortが"urn:iptv:transportQualityCS:3"に割り当てられる。
【００９２】
SDPでは、記述する対象のメディアの属性をｍ行とａ行の組み合わせにより表現するが、上述の転送品質クラスは、対応するSDPの内容のうち、例えば、以下の属性値の組み合わせにより決定されるものとする。
【００９３】
転送品質クラスがAssuredForwardingクラスとなるのは、SDPのｍ行／ａ行、以下の（１）〜（２）のいずれかの場合：
（１）media-type=videoかつa=sendrecv
（２）media-type=audioかつa=sendrecv
転送品質クラスがExcellentEffortとなるのは、SDPのｍ行／ａ行が、以下の（１）〜（４）のいずれかの場合：
（１）media-type=videoかつa=sendonly
（２）media-type=videoかつa=recvonly
（３）media-type=audioかつa=sendonly
（４）media-type=audioかつa=recvonly
転送品質クラスがBestEffortとなるのは、SDPのｍ行／ａ行が、以下の（１）〜（４）のいずれかの場合：
（１）media-type=data
（２）media-type=text
（３）media-type=application
（４）media-type=message
例えば、SDPの内容に、
"m=video … (メディアの種類はビデオであることを示す)"と
"a=sendrecv (送受信モードで処理しなければならないことを示す)"
の各行が含まれる場合には、転送品質クラスは、"AssuredForwarding"となる。これは、上記のtransportQualityCS制限用語辞書定義から、"urn:iptv:transportQualityCS:1"に相当する。
【００９４】
図１０に示したtransportQuality要素８５の導入のための拡張が行われたTV-Anytimeメタデータの例では、Coding要素８６に辞書参照href="urn:iptv:VisualCodingFormatCS:2"と記述されている。これは、例えば、以下のようなコーディングフォーマットを指定する、名前空間"urn:iptv:VisualCodingFormatCS"で識別されるVisualCodingFormatCS制限用語辞書定義があるものとしている。図１２に、このVisualCodingFormatCS制限用語辞書の定義の例を示す。
【００９５】
以上説明したように、この実施形態によれば、コンテンツを視聴するためのIMS上のIPTVセッションの確立を促すSIP-INVITEメッセージの生成に必要な情報を格納したTV-AnytimeメタデータをIPTVクライアント端末１０に提供することによって、IPTVクライアント端末１０は、このTV-Anytimeメタデータをもとに、視聴したいコンテンツの場所を指定するSIP-URIを宛先に格納し、そのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタが記述されたSDPをボディ部に格納したSIP-INVITEメッセージを生成することができる。
【００９６】
また、この実施形態によれば、SIP-INVITEメッセージのSIP-URIにより、コンテンツへのアドレス解決に必要な情報へ誘導できることによって、IMSプラットフォームそのもので提供される、例えばSIPによるセッション確立の際の認証メカニズム等を、そのまま、コンテンツへのアクセス制御等に利用することができる。これにより、そのコンテンツへのアクセス制御をIMS-SIPによるセッション制御のレイヤーで実現でき、図２に示すように、IMS-SIPによるセッション制御２２０にアクセス制御２１０のシグナリングを組み込むことが可能となって、プロトコル処理のオーバヘッドの大幅な低減を図ることが期待できる。
【００９７】
(第２の実施形態)
【００９８】
次に、本発明の第２の実施形態として、SIP-URIをTV-Anytimeメタデータに格納する別の方法とともに、IPTVクライアント端末１０において、そのTV-AnytimeメタデータからSIP-INVITEメッセージを生成する方法について説明する。
【００９９】
図１３は、本発明の第２の実施形態にかかるSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【０１００】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置されている。ProgramDescription要素５１の下には、ProgramInformationTable要素５２、ProgramLocationTable要素５３、及びServiceInformationTable要素９１が配置されている。このServiceInformationTable要素９１の中には、複数のServiceInformation要素９２を配置できる。ProgramInformationTable要素５２の構成は図５及び図１０に示したものと同じである。
【０１０１】
ProgramLocationTable要素５３の中には、ProgramLocation要素の派生であるOnDemandProgram要素５５（図５及び図１０）に代えてOnDemandService要素９３が配置されている。このOnDemandService要素９３には、CRIDをcrid属性の値として格納するProgram要素６１、コンテンツのインスタンスのメタデータ（配信にかかわるメタデータ）が格納されるとともに、serviceIdRef属性の値として、コンテンツを提供するサービスのIDが格納されている。この例では、サービスのIDとして"sid"が格納されている。
【０１０２】
ServiceInformation要素９２には、サービスの名前等のサービスのメタデータが格納されている。また、ServiceInformation要素９２は、サービスのIDをserviceId属性の値として格納し、このserviceId属性の値によって識別される。さらに、ServiceInformation要素９２の下には、サービスの名前を格納するName要素９４と、サービスを提供するIPTVサーバ２０のURLを格納するServiceURL要素９５と、その他、サービスのメタデータを格納する要素（図示せず）が配置されている。
【０１０３】
TV-Anytimeにおいて、ServiceURLは、"An optional URL for the service e.g. a DVB URL. This URL allows the receiver to identify the associated physical service."と定義されているが、ここでは、ServiceURLとして、コンテンツの配信元であるIPTVサーバ２０のURLが指定されることとする。このIPTVサーバ２０のURLのスキームには"http:"が使用され、例えば、図１４に示すように、"http://as.sp.com"のように指定される。
【０１０４】
図１４は、メタデータサーバ４０での図１３に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【０１０５】
メタデータサーバ４０で図１３に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まずProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、OnDemandService要素９３のserviceIdRef属性の値としてサービスのIDである例えば"sid"を格納し、そのOnDemandService要素９３内のProgram要素６１のcrid属性の値として、CRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、ServiceInformation要素９２のserviceId属性の値として、OnDemandService要素９３のserviceIdRef属性の値として格納されているサービスのIDである例えば"sid"を格納し、そのServiceInformation要素９２内のName要素９４にサービスの名前として例えば"contentService"を格納し、そのServiceInformation要素９２内のServiceURL要素９５に、コンテンツの配信元であるIPTVサーバ２０のDNS名である"as.sp.com"に"http://"を付けた"http://as.sp.com"を格納する。なお、実際には、TV-Anytimeメタデータには、そのコンテンツを視聴するためのIPTVセッションの確立に必要なSDPも格納されるが、このSDPをTV-Anytimeメタデータに格納する方法については前述した通りであり、ここでは省略する。
【０１０６】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ２０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ２０４）。このインタフェース画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ２０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【０１０７】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、TV-Anytimeメタデータから、Program要素６１のcrid属性の値が"crid://ca.com/123"であるOnDemandService要素９３のserviceIdRef属性の値である"sid"をserviceId属性の値として持つServiceInformation要素９２内のServiceURL要素９５に格納された"http://as.sp.com"と、OnDemandService要素９３内のProgram要素６１のcrid属性の値"crid://ca.com/123"と、図示しないSDP要素に格納されたSDPの内容をIPTVクライアントアプリケーション１３に渡す（ステップＳ２０６）。
【０１０８】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡された"http://as.sp.com"から"http://"を除いた"as.sp.com"と、OnDemandService要素９３のProgram要素６１のcrid属性の値である"crid://abc.com/123"から"crid://"を除いた"ca.com/123"から生成した"ca.com_123"と、さらには"sip-uri:"と"@"とを用いて"sip-uri:ca.com_123@as.sp.com"を生成し、これをSIP-INVITEメッセージの宛先にSIP-URIとして格納するとともに、SDPをSIP-INVITEメッセージのボディ部に格納する。これによってコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージが生成される（ステップＳ２０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ２０８）。以後の動作は、第１の実施形態で図４を参照して説明したとおりである。
【０１０９】
以上説明したように、この実施形態によっても、IPTVクライアント端末１０にて、TV-Anytimeメタデータをもとに、SIP-INVITEメッセージの宛先に格納するSIP-URIを得ることができる。
【０１１０】
(第３の実施形態)
【０１１１】
次に、本発明の第３の実施形態として、SIP-URIをTV-Anytimeメタデータに格納する別の方法とともに、IPTVクライアント端末１０において、そのTV-AnytimeメタデータからSIP-INVITEメッセージを生成する方法について説明する。
【０１１２】
SIP-URIをそのまま格納できる要素は、オリジナルのTV-AnytimeのXMLスキーマで定義されるProgramInformation要素に対応する型であるProgramInformationType要素にはない。そのため、この例では、ProgramInformationType要素を拡張して、それにsipURI属性を新たに導入することでSIP-URIを格納できるようにする。
【０１１３】
このXMLスキーマの拡張を行うには、新たなXMLスキーマの名前空間、例えば、"urn:IPTV"を導入し、この名前空間のもとで、sipURI属性をTV-AnytimeのオリジナルのProgramInformationType要素の派生に導入する。
【０１１４】
図１５は、このsipURI属性導入の拡張のためのXMLスキーマのシンタクスの例である。このXMLスキーマの拡張のためのシンタクスには、オリジナルのTV-Anytimeメタデータを識別する名前空間２１、XMLスキーマを識別する名前空間２２、新しく定義するスキーマが"urn:IPTV"で識別されることの宣言２３、新しいXMLスキーマにおけるProgramInformationTypeの定義２４、拡張するオリジナルのTV-Anytimeの要素の指定２５、追加する属性であるsipURIの定義２６等が含まれている。
【０１１５】
図１６は、このsipURI属性を導入するXMLスキーマ拡張によりSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【０１１６】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置されている。ProgramDescription要素５１の下には、ProgramInformationTable要素５２が配置されている。このProgramInformationTable要素５２の中には、１つ以上のProgramInformation要素５４を配置できる。ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRIDが格納される。また、ProgramInformationTable要素５２の下には、BasicDescription要素５７が配置され、このBasicDescription要素５７の下には、コンテンツのタイトルを格納するTitle要素５６、その他、コンテンツのメタデータを格納する要素（図示せず）が配置されている。
【０１１７】
そして、このTV-Anytimeメタデータでは、ProgramInformation要素５４のxsi:type属性によるオーバーライドにより、上述のXMLスキーマ拡張で導入された名前空間"urn:IPTV"のProgramInformationType型を参照することにより、オリジナルのTV-AnytimeメタデータのProgramInformation要素が、このXMLスキーマ拡張で新たに導入されたsipURI属性を持つProgramInformation要素５４に置換されている。sipURI属性には、programId属性の値であるCRIDとコンテンツの配信元であるIPTVサーバ２０のDNS名とを用いて作成されたSIP-URIが格納される。
【０１１８】
図１７は、メタデータサーバ４０での図１６に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【０１１９】
メタデータサーバ４０で図１６に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まずProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、上記のXMLスキーマ拡張により新たに導入されたsipURI属性の値として、CRIDである"crid://abc.com/123"から"crid://"を除き、"/"を"_"に置き換えて得た"ca.com_123"と、さらには、コンテンツの配信元であるIPTVサーバ２０のDNS名"as.sp.com"と"sip-uri:"と"@"とを用いて作成された"sip-uri:ca.com_123@as.sp.com"をSIP-URIとして格納する。なお、実際には、TV-Anytimeメタデータには、そのコンテンツを視聴するためのIPTVセッションの確立に必要なSDPも格納されるが、このSDPをTV-Anytimeメタデータに格納する方法については前述した通りであり、ここでは省略する。
【０１２０】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ３０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ３０４）。このインタフェース画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ３０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【０１２１】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、TV-Anytimeメタデータから、programId属性の値が"crid://ca.com/123"であるProgramInformation要素５４のsipURI属性の値である"sip-uri:ca.com_123@as.sp.com"と、図示しないSDP要素に格納されたSDPの内容をIPTVクライアントアプリケーション１３に渡す（ステップＳ３０６）。
【０１２２】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡された"sip-uri:ca.com_123@as.sp.com"を、SIP-INVITEメッセージの宛先にSIP-URIとして格納し、SDPをSIP-INVITEメッセージのボディ部に格納する。これによってSIP-INVITEメッセージが生成される（ステップＳ３０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ３０８）。以後の動作は、第１の実施形態で図４を参照して説明したとおりである。
【０１２３】
以上説明したように、この実施形態によっても、IPTVクライアント端末１０にて、TV-Anytimeメタデータをもとに、SIP-INVITEメッセージの宛先に格納するSIP-URIを得ることができる。
【０１２４】
(第４の実施形態)
【０１２５】
以上の実施形態ではIPTVクライアント端末１０がIMS-SIPサーバ３３に対してセッションを確立するためのSIP-INVITEメッセージを直接送信する構成としたが、IMS-SIPサーバ３３に対してセッションを確立するためのSIP-INVITEメッセージを生成して送信する部分をIPTVクライアント端末１０から独立させて、セッション管理装置であるIMSゲートウェイとして構成してもよい。この場合、家庭内の機器は、１以上のIPTVクライアント端末とIMSゲートウェイとで構成され、これらをIPTVクライアントシステムと呼ぶこととする。
【０１２６】
図２２は、このようなIPTVクライアントシステムを採用したIPTVシステム１００の全体的な構成を示す図である。
【０１２７】
同図に示すように、このIPTVシステム１００は、コンテンツを視聴するユーザ１が持つIPTVクライアント端末１０Ａ、IPTVクライアント端末１０ＡとLAN（Local Area Network）などのホームネットワーク１８を通じて接続されたIMSゲートウェイ１１０、コンテンツを配信するIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０、及びこれらを接続可能なインターネットなどの広域なネットワーク３とで構成される。
【０１２８】
IPTVクライアント端末１０Ａは、第１の実施形態のIPTVクライアント端末１０の構成に、ホームネットワーク１８とのインタフェースをとるネットワークインタフェース１９を加えて構成される。その他の構成は、第１の実施形態のIPTVクライアント端末１０と同じである。
【０１２９】
IMSゲートウェイ１１０は、例えば、PC、セットップボックスなどとして提供される機器である。IMSゲートウェイ１１０は、IPTVクライアント端末１０Ａとホームネットワーク１８を通じて接続可能とされているとともに、広域なネットワーク３を通じてIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０と接続可能とされている。IMSゲートウェイ１１０は、インスタンス選択基準設定部１１１、インスタンス選択基準データベース１１２、ネットワークインタフェース部１１３，１１４、SIMカード読込部１１５、セッション処理部１１６等を備える。
【０１３０】
インスタンス選択基準設定部１１１は、IPTVクライアント端末１０Ａのユーザ１に、コンテンツのインスタンスの選択基準を選択させ、その情報をインスタンス選択基準データベース１１２に登録する処理を行う部分である。ここで、コンテンツのインスタンスとは次のようなものである。IPTVサーバ２０には、同じタイトルのコンテンツであってもビットレートや符号化方式（コーデックの種類）の異なる複数のものが配信可能なコンテンツのデータの実体として用意されている場合がある。コンテンツのインスタンスとは、このようにビットレートや符号化方式などの違いにより実体が異なるコンテンツのデータのことを言う。一般的にビットレートが高いほどコンテンツの画質は高くなるが、それだけ家庭に割り当てられているネットワーク帯域を消費することになる。また、コーデックの種類によっても画質は変わる。たとえば、あるコーデックＡにより10Mbpsのビットレートで符号化されたコンテンツは、別のコーデックＢにより15Mbpsのビットレートで符号化されたコンテンツよりも画質が高いこともある。インスタンスの選択基準とは、このような事情を考慮してユーザの嗜好により選択される。その具体的な方法に関しては後で説明する。
【０１３１】
インスタンス選択基準データベース１１２は、IPTVクライアント端末１０Ａのユーザ１により選択されたインスタンス選択基準が格納されるデータベースである。
【０１３２】
ネットワークインタフェース部１１３は、ホームネットワーク１８とのインタフェースを提供する。ネットワークインタフェース部１１４は、広域なネットワーク３とのインタフェースを提供する。
【０１３３】
SIM（Subscriber Identity Module）読込部１１５は、IMSにおけるセッション確立のために行われるIPTVクライアントの認証に必要な情報（例えばユーザＩＤおよびパスワードなど）が記憶されたSIMカード１１７の着脱が可能とされ、装着されたSIMカード１１７に記憶された認証に必要な情報を読み込むモジュールである。
【０１３４】
セッション処理部１１６は、IPTVクライアント端末１０よりSIP-URIおよびSDPを含むセッション確立要求を受信したとき、このセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準をもとに各インスタンスの優先順位を決定し、この優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０１３５】
また、セッション処理部１１６は、SIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行い、認証に成功した場合にセッション確立のための処理を有効にする。
【０１３６】
IPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０の構成は第１の実施形態と同じである。
【０１３７】
次に、この第４の実施形態のIPTVシステム１００において、IPTVクライアント端末１０とIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を説明する。
【０１３８】
図２３は、この動作を示すシーケンス図である。IPTVクライアント端末１０においては、EPGアプリケーション１４が既に起動されているものとする。IPTVサーバ２０には、同じタイトルのコンテンツであってもビットレートや符号化方式の異なる複数のコンテンツのデータの実体がインスタンスとして用意されていることとする。
【０１３９】
まず、IPTVクライアント端末１０内のEPGアプリケーション１４からIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対して、IPTVクライアント端末１０のユーザ１により設定されたインスタンス選択基準を送信する（ステップＳ４０１）。IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する（ステップＳ４０２）。
【０１４０】
ここまでの動作は、より具体的には次のような手順で行われる。まず、IPTVクライアント端末１０内のEPGアプリケーション１４は、ホームネットワーク１８を通じて接続されているIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の設定要求を送信する。
【０１４１】
IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４からのインスタンス選択基準の設定要求を受信すると、インスタンス選択基準の設定画面情報をホームネットワーク１８を通じてIPTVクライアント端末１０内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０内のEPGアプリケーション１４は、このインスタンス選択基準の設定画面情報を受信すると、ユーザインタフェース部１１に備えられている表示部にインスタンス選択基準の設定画面を表示する。
【０１４２】
図２４は、このインスタンス選択基準の設定画面２０１の例を示す図である。これはコンテンツのインスタンス選択基準をユーザに選択させる場合の画面の例である。このインスタンス選択基準の設定画面２０１には、複数の嗜好設定項目２１０，２２０，２３０が設けられている。それぞれの嗜好設定項目２１０，２２０，２３０には、嗜好の種類を示す領域として「画質を優先しますか？」「価格を優先しますか？」といった質問文が配置された嗜好表示領域２１１，２２１，２３１と、それぞれの嗜好設定項目２１０，２２０，２３０の質問文に対するユーザの回答として「ＹＥＳ」または「ＮＯ」のいずれかを、インスタンス選択基準の設定画面２０１に設けられた例えばトグルスイッチなどのマウスクリック操作などによって択一的にユーザに選択させる嗜好選択領域２１２，２２２，２３２と、「ＹＥＳ」が選択された各嗜好設定項目に対して、インスタンス選択基準の設定画面２０１に設けられたプルダウンメニューのマウスクリック操作などにより優先度をユーザに指定させる優先度設定領域２１３，２２３，２３３とを備えている。たとえば、画質と価格についてユーザの嗜好を設定する場合には、上記の設定画面の「画質を優先しますか？」の嗜好表示領域２１１に対応する嗜好選択領域２１２で「ＹＥＳ」を選択するとともに、「価格を優先しますか？」の嗜好表示領域２２１に対応する嗜好選択領域２２２で「ＹＥＳ」を選択する。このように複数の嗜好設定項目２１０，２２０の嗜好選択領域２１２，２２２に対して「ＹＥＳ」が選択された場合には、これらの嗜好項目間での優先度を優先度設定領域２１３，２２３で指定する。図２４は画質の優先度を"１"、価格の優先度を"２"として、画質を価格よりも優先した場合の設定例を示している。なお、優先度設定領域２１３，２２３，２３３においては、複数の嗜好が選択された場合にこれらの嗜好に対して同じ優先度が指定できないように入力値の排他制御が行われる。
【０１４３】
IPTVクライアント端末１０のユーザによる、インスタンス選択基準の設定画面２０１への入力が完了した後、設定画面２０１に設けられたＯＫボタン２４１のマウスクリック操作が行われると、EPGアプリケーション１４は、その設定画面２０１への入力情報であるインスタンス選択基準を、ホームネットワーク１８を通じてIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に送信する（この動作がステップＳ４０１に相当）。
【０１４４】
IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０のEPGアプリケーション１４からインスタンス選択基準を受信すると、このインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する（この動作がステップＳ４０２に相当）。
【０１４５】
この後、IPTVクライアント端末１０のEPGアプリケーション１４は、コンテンツのメタデータの取得要求を広域なネットワーク３を通じてメタデータサーバ４０に送信し、メタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを応答として受信してメタデータ記憶部１５に格納する（ステップＳ４０３，Ｓ４０４）。
【０１４６】
EPGアプリケーション１４は、取得したTV-Anytimeメタデータをもとに、コンテンツの選択画面を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ４０５）。図２８はコンテンツの選択画面５００の例を示す図である。コンテンツの選択画面５００には、選択可能な各コンテンツのタイトル、概要、視聴価格などの文字情報５０１，５０２，５０３と、コンテンツの縮小画像５０４，５０５，５０６などが表示される。コンテンツの縮小画像５０４，５０５，５０６は、ユーザ１によるマウスクリック操作などによって選択されたとき、自身の縮小画像５０４，５０５，５０６に対応するコンテンツが選択されたというイベントの発生をEPGアプリケーション１４に通知する機能を有する。EPGアプリケーション１４はこの通知を受けてユーザ１により選択されたコンテンツを判別する。
【０１４７】
このコンテンツの選択画面５００でユーザ１によって視聴したいコンテンツが選択されると（ステップＳ４０６）、EPGアプリケーション１４は、その視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたTV-Anytimeメタデータから当該視聴対象のコンテンツの場所を指定するSIP-URIと、このコンテンツのインタンス毎のSDPを抽出する。ここで、インタンス毎のSDPにはビットレート、コーデック情報、価格情報などが含まれている。
【０１４８】
EPGアプリケーション１４は、TV-Anytimeメタデータから抽出した各インスタンスのSDPに含まれるコーデック情報を読み込み、IPTVクライアント端末１０内のコンテンツ再生部１７にて復号が可能なインスタンスのSDPを判定する（ステップＳ４０７）。この判定は、IPTVクライアント端末１０のシステムに実装されている符号化および復号のためのソフトウエアであるコーデックの種類を調べることによって行われる。
【０１４９】
続いて、EPGアプリケーション１４は、IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の取得要求を送信し、応答として取得したインスタンス選択基準と、コンテンツの各インスタンスのSDPをもとに、コンテンツのインスタンス間の優先順位を優先度として決定する（ステップＳ４０８）。そして、EPGアプリケーション１４は、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとのリストを含むセッション確立要求をホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信する（ステップＳ４０９）。
【０１５０】
図２５はIPTVクライアント端末１０のユーザ１によって画質を最優先するようにインスタンス選択基準が設定され、IPTVクライアント端末１０にはcodec-Aとcodec-Bの２種類のコーデックが実装されている場合のリスト３０１の例である。このリスト３０１には、コンテンツの場所を指定するSIP-URIと、優先度が付けられた３つのインスタンスａ，ｂ，ｃそれぞれのSDPとが含まれている。ここでは、codec-Aのコーデックはcodec-Bのコーデックよりビットレートが小さいが高画質であることから、コーデック情報が" codec-A "のインスタンスのSDPが、コーデック情報が" codec-Ｂ "のインスタンスのSDPよりも優先度が高く設定されている。
【０１５１】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０のEPGアプリケーション１４からのセッション確立要求を受信すると、このセッション確立要求に含まれる、優先度が付けられた各インスタンスのSDPをもとにセッション確立のためのネゴシエーションを行う（ステップＳ４１０）。このセッション確立のためのネゴシエーションは、たとえば、次のように行われる。
【０１５２】
まず、IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０のEPGアプリケーション１４より取得した各インスタンスのSDPの中で最も優先度が高いインスタンスのSDPを判断し、このSDPをボディ部に格納し、IPTVクライアント端末１０のEPGアプリケーション１４より取得したSIP-URIを宛先に格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを、広域なネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する。IMS-SIPサーバ３３は、IMSゲートウェイ１１０からのSIP-INVITEメッセージを受信すると、このSIP-INVITEメッセージからSIP-URIを抽出し、このSIP-URIを少なくとも含む、コンテンツのアクセス権の確認を依頼するメッセージをアクセス制御サーバ３１に送信する。アクセス制御サーバ３１は、このアクセス権確認依頼のメッセージに含まれるSIP-URIをもとに当該コンテンツのアクセス権の確認を行う。アクセス制御サーバ３１は、当該コンテンツのアクセス権を許諾することを判定した場合には、IMS-SIPサーバ３３にアクセス権許諾の応答メッセージを送信し、当該コンテンツのアクセス権を許諾しないことを判定した場合には、IMS-SIPサーバ３３にアクセス権非許諾の応答メッセージを送信する。以後、アクセス権が許諾された場合について説明を続ける。
【０１５３】
IMS-SIPサーバ３３は、アクセス権許諾の応答メッセージを受信すると、SIP-INVITEメッセージのボディ部からSDPを抽出し、このSDPを用いて、ネットワークリソースの確保を要求するメッセージを生成してネットワークリソース管理サーバ３２に送信する。ネットワークリソース管理サーバ３２はネットワークリソース確保要求のメッセージを受けると、これに含まれるSDPをもとに、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソース（ネットワーク帯域）の確保を試み、ネットワーク帯域の確保に成功したならば、IMS-SIPサーバ３３にネットワーク帯域の確保応答のメッセージを送信する。IMS-SIPサーバ３３は、ネットワーク帯域の確保応答のメッセージを受信すると、SIP-INVITEメッセージの宛先をもとに、SIP-INVITEメッセージをIPTVサーバ２０に送信するとともに、IMSゲートウェイ１１０にセッションの確立が成功したことを通知する。IMSゲートウェイ１１０は、セッションの確立が成功したことを知ると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に通知する（ステップＳ４１１）。
【０１５４】
また、ネットワークリソース管理サーバ３２は、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保に失敗した場合には、IMSゲートウェイ１１０にセッションの確立に失敗したことを通知する。IMSゲートウェイ１１０は、このセッションの確立に失敗したことの通知を受信すると、IPTVクライアント端末１０のEPGアプリケーション１４より取得した各インスタンスのSDPのリストの中で次に優先度が高いインスタンスのSDPを判断し、前回と同様に、このSDPをボディ部に格納し、IPTVクライアント端末１０のEPGアプリケーション１４より取得したSIP-URIを宛先に格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを、帯域ネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する。以後の動作は前回の処理と同じである。IMSゲートウェイ１１０は、セッションの確立に成功したことの通知を受信するか、または、SIP-INVITEメッセージのボディ部に格納すべきSDPがなくなるまで、上記の処理を繰り返す。
【０１５５】
セッションの確立に成功した場合の説明に戻る。
IPTVサーバ２０は、IMS-SIPサーバ３３よりIMS-INVITEメッセージを受信すると、コンテンツを視聴するためのIPTVセッションを確立するために必要なネットワーク帯域を確保し、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間で確立されたセッションを用いて、コンテンツのデータを送信する。IPTVクライアント端末１０のIPTVクライアントアプリケーション１３は、IPTVサーバ２０との間に確立されたセッションを通じてコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ４１２）。
【０１５６】
以上説明したように、本実施形態では、IPTVクライアント端末１０のEPGアプリケーション１４からIMSゲートウェイ１１０に対してセッション確立要求を行うとき、視聴対象として選択されたコンテンツの場所を指定するSIP-URIとともに、優先度が付けられた各インスタンスのSDPをIMSゲートウェイ１１０に送信することによって、IMSゲートウェイ１１０は各インスタンスの優先度を考慮しつつセッション確立のためのネゴシエーションを行うことができる。
【０１５７】
(第４の実施形態の変形例１)
図２６は、第４の実施形態の変形例１である動作を示すフローチャートである。
【０１５８】
第４の実施形態では、予めIMSゲートウェイ１１０のインスタンス選択基準データベース１１２に登録されたインスタンス選択基準と、ユーザ１により視聴対象として選択されたコンテンツの各インスタンスのSDPとをもとにIPTVクライアント端末１０が各インスタンスに優先度を自動的に付けることとした。変形例では、ステップＳ４０８ａで、IPTVクライアント端末１０がユーザインタフェース部１１に備えられている表示部を通じて優先度選択画面をユーザ１に呈示し、クライアント端末１０のユーザ１０に各インスタンスの優先度をマニュアルで付けさせることとしている。
【０１５９】
図２７は、この優先度選択画面４００とユーザ１による各インスタンスの優先度の選択例を示す図である。この優先度選択画面４００には、ユーザ１により視聴対象として選択されたコンテンツの識別番号、タイトル、概要など、コンテンツに関する情報４０１と、当該コンテンツのインスタンス毎の画質、ビットレートなどが表示された画質情報表示領域４０２，４０３，４０４と、当該コンテンツのインスタンス毎の優先度をユーザ１に選択させるための優先度選択領域４０５，４０６，４０７などが設けられている。ユーザ１は、各インスタンスの画質情報表示領域４０２，４０３，４０４を参照しつつ各インスタンスの優先度を優先度選択領域４０５，４０６，４０７に入力する。これにより、IPTVクライアント端末１０はIMSゲートウェイ１１０のインスタンス選択基準データベース１１２に登録されたインスタンス選択基準に拠らず、各インスタンスの優先度の情報を取得して、各インスタンスに優先度を自動的に付けることができる。その他の動作は第４の実施形態と同じである。
【０１６０】
(第４の実施形態の変形例２)
図２９は、第４の実施形態の変形例２である動作を示すフローチャートである。
【０１６１】
第４の実施形態では、インスタンス選択基準をIMSゲートウェイ１１０内のインスタンス選択基準データベース１１２で管理することとしたが、IPTVサーバ２０で管理するようにしてもよい。この場合、IPTVクライアント端末１０は、広域なネットワーク３を通じてIPTVサーバ２０に対してインスタンス選択基準の設定要求を送信する。IPTVサーバ２０は、IPTVクライアント端末１０内のEPGアプリケーション１４からのインスタンス選択基準の設定要求を受信すると、その設定画面の情報を広域なネットワーク３を通じてIPTVクライアント端末１０内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示し、ユーザにインスタンス選択基準を入力させた後、広域なネットワーク３を通じてIPTVサーバ２０に送信する（この動作がステップＳ４０１ｂに相当）。
【０１６２】
IPTVサーバ２０は、IPTVクライアント端末１０のEPGアプリケーション１４からのインスタンス選択基準を受信すると、この情報を図示しないインスタンス選択基準データベースへ登録する（この動作がステップＳ４０２ｂに相当）。
【０１６３】
IPTVクライアント端末１０のEPGアプリケーション１４は、ステップＳ４０８ｂでコンテンツのSDPとインスタンス選択基準をもとに各コンテンツのインスタンスに優先度を付けるために、広域なネットワーク３を通じてIPTVサーバ２０にインスタンス選択基準の取得要求を送信してインスタンス選択基準を応答として取得する。その他の動作は第４の実施形態と同じである。
【０１６４】
(第５の実施形態)
【０１６５】
上記の第４の実施形態では、IMSゲートウェイ１１０とIPTVクライアント端末１０Ａとがホームネットワーク１８を介して１対１で接続されているものとしたが、IMSゲートウェイ１１０に対して、１つの家庭内の複数のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を介して接続されていてもよい。
【０１６６】
図３０は、このような構成を採用したIPTVシステム１００の全体的な構成を示す図である。IPTVクライアント端末１０Ａ，１０Ｂの構成、IMSゲートウェイ１１０の構成は、第４の実施形態と同じである。
【０１６７】
このIPTVシステム１００では、いずれかのIPTVクライアント端末（１０Ａまたは１０Ｂ）がインスタンス選択基準を設定し、IMSゲートウェイ１１０に送信してインスタンス選択基準データベース１１２に登録する。このインスタンス選択基準データベース１１２に登録されたインスタンス選択基準は、各IPTVクライアント端末１０Ａ，１０Ｂが視聴対象のコンテンツの各インタンスのSDPに対して優先度を付ける際にアクセスされる。これにより、家庭内に複数のIPTVクライアント端末１０Ａ，１０Ｂが設置された環境においても、インスタンス選択基準を選択する操作は一回で済むことになる。
【０１６８】
また、IMSゲートウェイ１１０に、IPTVクライアントの認証に必要な情報が記録されたSIMカード１１７を読み込むSIM読込部１１５を設け、このSIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行うことによって、複数のIPTVクライアント端末１０Ａ，１０ＢそれぞれにSIM読込部を設ける必要がなくなる。
【０１６９】
なお、図２８では、２機のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を通じてIMSゲートウェイ１１０と接続されている場合を示したが、３機以上のIPTVクライアント端末が接続されている場合も動作は同様である。
【０１７０】
(第６の実施形態)
【０１７１】
IMSゲートウェイ１１０に対して複数のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を介して接続されている場合、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求がIMSゲートウェイ１１０に送信されたときには、どのIPTVクライアント端末からのセッション確立要求に対して優先してセッションの確立のためのネゴシエーションを行うかという競合解決処理をIMSゲートウェイ１１０にて行う。
【０１７２】
図３１は、このような競合解決処理を採用したIPTVシステム１００の全体的な構成を示す図である。IPTVクライアント端末１０Ａ，１０Ｂの構成はEPGアプリケーション１４の一部の処理内容が異なるだけで、その他の部分は第１の実施形態と同様である。IMSゲートウェイ１１０は、第１の実施形態に示した構成に、デバイス／ユーザ優先度データベース１１９とデバイス／ユーザ優先度設定部１２０とが付加されたものである。
【０１７３】
デバイス／ユーザ優先度データベース１１９は、セッション確立のためのネゴシエーションを行う際のデバイス間の優先順位を示す優先度と、IPTVクライアント端末のユーザ間の優先順位を示す優先度が格納されるデータベースである。
【０１７４】
デバイス／ユーザ優先度設定部１２０は、特定のIPTVクライアント端末（この例ではIPTVクライアント端末１０Ａ）のユーザ１に、デバイス間の優先度またはユーザ間の優先度を選択させ、その情報をデバイス／ユーザ優先度データベース１１９に登録する処理を行う部分である。デバイス間の優先度またはユーザ間の優先度をまとめて「デバイス／ユーザ優先度」と表記する。
【０１７５】
セッション処理部１１６は、複数のIPTVクライアント端末１０Ａ，１０ＢよりデバイスＩＤ、ユーザＩＤ、SIP-URIおよびSDPを含むセッション確立要求を受信したとき、これらのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとに、各IPTVクライアント端末１０Ａ，１０Ｂからのセッション確立要求間の競合解決を行う。また、セッション処理部１１６は、競合解決によって優先度が高いと判定されたセッション確立要求から順に、第４の実施形態と同様に、そのセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準とをもとにインスタンス間の優先順位を決定し、優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０１７６】
また、セッション処理部１１６は、SIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行い、認証に成功した場合にセッション確立のための処理を有効にする。
【０１７７】
図３２は、この第６の実施形態のIPTVシステム１００において、IPTVクライアント端末１０Ａ，１０ＢとIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【０１７８】
まず、IPTVクライアント端末１０ＡのEPGアプリケーション１４からIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に対して、IPTVクライアント端末１０Ａのユーザ１により設定されたユーザ／デバイス優先度を送信する（ステップＳ５０１Ａ）。IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたユーザ／デバイス優先度をデバイス／ユーザ優先度データベース１１９へ登録する（ステップＳ５０２）。
【０１７９】
ここまでの動作は、より具体的には次のような手順で行われる。まず、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、ホームネットワーク１８を通じて接続されているIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に対してデバイス／ユーザ優先度の設定要求を送信する。
【０１８０】
IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４からのデバイス／ユーザ優先度の設定要求を受信すると、その設定画面の情報をホームネットワーク１８を通じてIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示する。
【０１８１】
図３３は、このデバイス／ユーザ優先度を設定するための画面の構成を示す図である。まず、IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、初期画面としてデバイス／ユーザ優先度設定画面６００を作成し、これをIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に送信して表示部に表示させる。このデバイス／ユーザ優先度設定画面６００には、競合解決をデバイス間の優先度をもとに行うか、ユーザ間の優先度をもとに行うかを択一的に指定するための２つのボタン６１１，６１２が設けられている。
【０１８２】
２つのボタン６１１，６１２のうち、競合解決をデバイス間の優先度をもとに行うボタン６１１が例えばマウスクリック操作などによって選択されると、デバイス間の優先度を設定するためのデバイス優先度設定画面６０２が現れる。このデバイス優先度設定画面６０２には、各デバイスの優先度を例えばプルダウンメニューに対するマウスクリック操作などにより選択するためのデバイス優先度設定領域６２１，６２２が設けられている。ここで、デバイスとはIPTVのクライアントとしてサービスを利用できるように予め登録されたIPTVクライアント端末である。それぞれのデバイスはデバイス固有のデバイスＩＤによって識別される。IPTVのクライアントとしてサービスを利用する際に、EPGアプリケーション１４はそのデバイスＩＤを使ってサービスを利用する。デバイス優先度設定領域６２１，６２２への各デバイスの優先度の選択後、デバイス優先度設定画面６０２に設けられたＯＫボタン６２３のマウスクリック操作が行われると、EPGアプリケーション１４は、そのデバイス優先度設定画面６０２への入力情報であるデバイス間の優先度をホームネットワーク１８を通じてIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に送信する（この動作がステップＳ５０１Ａに相当）。
【０１８３】
また、２つのボタン６１１，６１２のうち、競合解決をユーザ間の優先度をもとに行うボタン６１２が例えばマウスクリック操作などによって選択されると、ユーザ間の優先度を設定するためのユーザ優先度設定画面６０３が現れる。このユーザ優先度設定画面６０３には、各ユーザの優先度を例えばプルダウンメニューに対するマウスクリック操作などにより選択するためのユーザ優先度設定領域６３１，６３２が設けられている。ここで、ユーザとはIPTVのクライアントとしてサービスを利用できるように予め登録されたユーザであり、それぞれのユーザはユーザ固有のユーザＩＤによって識別される。IPTVのクライアントとしてサービスを利用する際にユーザは自分のユーザＩＤを入力することで、EPGアプリケーション１４はそのユーザＩＤを使ってサービスを利用する。ユーザ優先度設定領域６３１，６３２への各ユーザの優先度の選択後、ユーザ優先度設定画面６０３に設けられたＯＫボタン６３３のマウスクリック操作が行われると、EPGアプリケーション１４は、そのユーザ優先度設定画面６０３への入力情報である各ユーザの優先度をホームネットワーク１８を通じてIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に送信する（この動作がステップＳ５０１Ａに相当）。
【０１８４】
IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０内のEPGアプリケーション１４からデバイス／ユーザ優先度を受信すると、これをデバイス／ユーザ優先度データベース１１９へ登録する（この動作がステップＳ５０２に相当）。
【０１８５】
次に、各IPTVクライアント端末１０Ａ，１０Ｂ内のEPGアプリケーション１４はIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対して、IPTVクライアント端末１０のユーザ１により設定されたインスタンス選択基準を送信する（ステップＳ５０３Ａ，５０３Ｂ）。IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する。このときの処理の詳細は第４の実施形態で説明した通りである。
【０１８６】
この後、各IPTVクライアント端末１０Ａ，１０ＢのEPGアプリケーション１４はそれぞれ、コンテンツのメタデータの取得要求を広域なネットワーク３を通じてメタデータサーバ４０に送信し、メタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを応答として受信してメタデータ記憶部１５に格納する（ステップＳ５０４Ａ，Ｓ５０４Ｂ）。
【０１８７】
この後、各IPTVクライアント端末１０Ａ，１０Ｂにおいて、EPGアプリケーション１４は、TV-Anytimeメタデータをもとに、コンテンツの選択画面５００（図２８）を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ５０５Ａ，Ｓ５０５Ｂ）。
【０１８８】
このコンテンツの選択画面５００でユーザ１によって視聴したいコンテンツが選択されると（ステップＳ５０６Ａ，Ｓ５０６Ｂ）、EPGアプリケーション１４は、その視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたTV-Anytimeメタデータから当該視聴対象コンテンツの場所を指定するSIP-URIと、このコンテンツのインタンス毎のSDPを抽出する。
【０１８９】
EPGアプリケーション１４は、TV-Anytimeメタデータから抽出した各インスタンスのSDPに含まれるコーデック情報を読み込み、IPTVクライアント端末１０Ａ，１０Ｂ内のコンテンツ再生部１７にて復号が可能なインスタンスのSDPを判定する（ステップＳ５０７Ａ，Ｓ５０７Ｂ）。
【０１９０】
続いて、EPGアプリケーション１４は、IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の取得要求を送信し、応答として取得したインスタンス選択基準と、コンテンツの各インスタンスのSDPをもとに、コンテンツのインスタンス間の優先順位を優先度として決定する（ステップＳ５０８Ａ，Ｓ５０８Ｂ）。そして、EPGアプリケーション１４は、デバイスＩＤまたはユーザＩＤと、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとを含むセッション確立要求をホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信する（ステップＳ５０９Ａ，Ｓ５０９Ｂ）。
【０１９１】
ここで、IMSゲートウェイ１１０内のセッション処理部１１６は、２つのIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求が受信したことによって競合の発生を検知し、それぞれのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとに、各IPTVクライアント端末１０Ａ，１０Ｂからのセッション確立要求間の競合解決を行う（ステップＳ５１０）。次に、この競合解決の具体例を説明する。
【０１９２】
図３４は、２つのIPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のセッション処理部１１６にそれぞれ送信された２つのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPの例を示す図である。７００ＡはIPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）から送信されたセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDP、７００ＡはIPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）から送信されたセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPである。
【０１９３】
ここで、２つのIPTVクライアント端末１０Ａ，１０ＢとIMSゲートウェイ１１０が設置されている家庭に割り当てられているネットワーク帯域が15Mbpsとする。また、ここではユーザの優先度に基づいて競合解決が行われることとし、優先度はd2がd1より高いものとする。この場合、セッション処理部１１６は最初に、ユーザ優先度が高いIPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）が依頼する優先度1のインスタンスに対するセッションを確立するためのネゴシエーションを行う（ステップＳ５１１）。このセッションの確立によりネットワーク帯域は8 Mbps消費されるので残りは7Mbpsである。そこで次に、セッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）が依頼するセッションを確立するために、IPTVクライアント端末１０Ａから受信したセッション確立要求に含まれる各インスタンスのSDPを優先度の高いインスタンスから順に参照し、ビットレートが7Mbps以下のインスタンスを検出する。この結果、IPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）が依頼する優先度１のインスタンスのビットレートは10Mbpsであることからこれを無効とし、ビットレートが5Mbpsである優先度２のインスタンスに対するセッションを確立するためのネゴシエーションを行う（ステップＳ５１１）。
【０１９４】
ここでは、ユーザの優先度に従って競合解決が行われる場合を例示したが、デバイスの優先度に従って競合解決が行われる場合も同様である。
【０１９５】
セッションを確立するためのネゴシエーションを含む以後の動作は第４の実施形態と同様である。IMSゲートウェイ１１０内のセッション処理部１１６は、IMS-SIPサーバ３３よりセッションの確立が成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をそれぞれのIPTVクライアント端末１０Ａ，１０ＢのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１２）。各IPTVクライアント端末１０Ａ，１０Ｂ内のIPTVクライアントアプリケーション１３はそれぞれ、IMSゲートウェイ１１０内のセッション処理部１１６からセッション確立が成功したことの通知を受信すると、このセッションを通じてIPTVサーバ２０からコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ａ，５１３Ｂ）。
【０１９６】
以上説明したように、本実施形態では、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時に発生したセッション確立要求に対して、IMSゲートウェイ１１０がデバイス間の優先度またはユーザ間の優先度に基づいて、順次適切なセッションを確立することができる。
【０１９７】
なお、この実施形態では、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求が発生した場合について説明したが、既に、あるIPTVクライアント端末から依頼されたセッションが確立されているときに、別のIPTVクライアント端末からのセッション確立要求が発生した場合、IMSゲートウェイ１１０内のセッション処理部１１６は、その新たに発生したセッションの確立要求の中で優先度の高いインスタンスから順にそのインスタンスのビットレートが、家庭に割り当てられているネットワーク帯域から既に消費されているネットワーク帯域を差し引いた残りのネットワーク帯域以下のものを検出し、このインスタンスに対するセッションを確立するためのネゴシエーションを行う。
【０１９８】
(第６の実施形態の変形例１)
図３８は、第６の実施形態の変形例１の動作を示すフローチャートである。
【０１９９】
第６の実施形態では、デバイス／ユーザ優先度をIMSゲートウェイ１１０で管理することとしたが、IPTVサーバ２０で管理するようにしてもよい。この場合、IPTVクライアント端末１０Ａは、広域なネットワーク３を通じてIPTVサーバ２０に対してデバイス／ユーザ優先度の設定要求を送信する。
【０２００】
IPTVサーバ２０は、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４からのデバイス／ユーザ優先度の設定要求を受信すると、その設定画面の情報を広域なネットワーク３を通じてIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示し、ユーザ１にデバイス／ユーザ優先度を入力させた後、広域なネットワーク３を通じてを通じてIPTVサーバ２０に送信する（この動作がステップＳ５０１Ａｂに相当）。
【０２０１】
IPTVサーバ２０は、IPTVクライアント端末１０のEPGアプリケーション１４からのデバイス／ユーザ優先度を受信すると、この情報を図示しないインスタンス選択基準データベースへ登録する（この動作がステップＳ５０２ｂに相当）。
【０２０２】
IMSゲートウェイ１１０内のセッション処理部１１６は、競合を解決するために、広域なネットワーク３を通じてIPTVサーバ２０にデバイス／ユーザ優先度の取得要求を送信してデバイス／ユーザ優先度を応答として取得する。
【０２０３】
なお、各IPTVクライアント端末１０Ａ，１０Ｂで作成されたインスタンス選択基準についてもIPTVサーバ２０にて管理するようにしてもよい。
【０２０４】
(第７の実施形態)
【０２０５】
あるIPTVクライアント端末のユーザから依頼されたセッションが確立されているときに、そのIPTVクライアント端末またはそのユーザよりデバイス／ユーザ優先度が高い別のIPTVクライアント端末またはユーザからセッション確立要求が発生した場合には、後から依頼されたセッションを優先するために、既に確立されているセッションをより低画質のセッションに変更するようにしてもよい。この方式を採用した第７の実施形態を説明する。
【０２０６】
図３５および図３６は、この第７の実施形態のIPTVシステム１００において、IPTVクライアント端末１０Ａ，１０ＢとIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。なお、第７の実施形態のIPTVシステム１００の構成は図３１に示した第６の実施形態と同じであるが、IMSゲートウェイ１１０内のセッション処理部１１６の処理が異なる。
【０２０７】
まず、ステップＳ５０１ＡからステップＳ５０３Ａ，Ｓ５０３Ｂで、IPTVクライアント端末１０ＡからIMSゲートウェイ１１０内のデバイス／ユーザ優先度データベース１１９へのデバイス／ユーザ優先度の登録と、各IPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のインスタンス選択基準データベース１１２へのインスタンス選択基準の登録が第６の実施形態と同様に行われる。
【０２０８】
この後、IPTVクライアント端末１０ＡのEPGアプリケーション１４がメタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを取得するステップＳ５０４Ａから、IPTVクライアント端末１０ＡのEPGアプリケーション１４が、デバイスＩＤまたはユーザＩＤと、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとを含むセッション確立要求を、ホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信するステップＳ５０９Ａまでの動作も第６の実施形態と同様である。
【０２０９】
ここではIPTVクライアント端末１０ＡのEPGアプリケーション１４だけからセッション確立要求が送信されたことから、IMSゲートウェイ１１０内のセッション処理部１１６は、第４の実施形態と同様に、そのセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準とをもとに各インスタンスの優先順位を決定し、優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０２１０】
IMSゲートウェイ１１０は、IMS-SIPサーバ３３よりセッションの確立が成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１２）。この後、IPTVクライアント端末１０Ａ内のIPTVクライアントアプリケーション１３は、IPTVサーバ２０との間に確立されたセッションを通じてコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ａ）。
【０２１１】
IPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３とIPTVサーバ２０との間にセッションが確立されているとき、IPTVクライアント端末１０ＢのEPGアプリケーション１４が、同様にステップＳ５０４ＢのTV-Anytimeメタデータの取得から、ステップＳ５０９Ｂのセッション確立要求の送信までを行ったこととする。
【０２１２】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０ＢのEPGアプリケーション１４からのセッション確立要求を受信すると競合の発生を検知し、IPTVクライアント端末１０Ａから既に受信しているセッション確立要求とIPTVクライアント端末１０Ｂから受信したセッション確立要求のそれぞれに含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとにセッション確立要求間の競合解決を行う（ステップＳ５１４）。次に、この競合解決の具体例を説明する。
【０２１３】
この競合解決の具体例を説明するために、再び図３４の２つのIPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のセッション処理部１１６にそれぞれ送信された２つのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPの例を採用する。ここで、２つのIPTVクライアント端末１０Ａ，１０ＢとIMSゲートウェイ１１０が設置されている家庭に割り当てられているネットワーク帯域が15Mbpsとする。また、ここではユーザの優先度に従って競合解決が行われることとし、優先度はd2がd1より高いものとする。さらに、IPTVクライアント端末１０Ｂからのセッション確立要求が発生する以前に、IPTVクライアント端末１０Aからのセッション確立要求に含まれる優先度1のインスタンスに対するセッションが既に確立されているものとする。したがって、ネットワーク帯域は既に10Mbps消費されているので残りは5Mbpsである。
【０２１４】
セッション処理部１１６は、まず、２つのセッション確立要求それぞれに含まれるユーザＩＤをもとに、どちらのIPTVクライアント端末のユーザのユーザ優先度が高いかを判定する。図３４の例では、IPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）のユーザの方がIPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）のユーザよりもユーザ優先度が高いことを判定する。そこでセッション処理部１１６は、IPTVクライアント端末１０Ｂからのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスに対するセッションを確立するようにネゴシエーションを行う（ステップＳ５１５）。
【０２１５】
このネゴシエーションにおいて、IPTVクライアント端末１０Ｂからのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスのビットレートは8Mbpsであるのに対し、家庭に割り当てられているネットワーク帯域の残りは現在5Mbpsであるため、このままでは3Mbps分の不足が生じる。そこでセッション処理部１１６は、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスのSDPを参照して、現在セッションが確立されているインスタンスよりもビットレートの低いインスタンスのビットレートを確認して、このビットレートが7Mbps以下ならば、このインスタンスに対するセッションへの変更を行うようにセッション確立のための処理を行う。図３４の例では、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスの中で優先度が２番目に高いインスタンスのビットレートは5Mbpsであることから、このインスタンスに対するセッションへの変更が行われる。そして、セッション処理部１１６は、このセッションへの変更要求をIPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３に送信する（ステップＳ５１６）。なお、ビットレートが7Mbps以下のインスタンスがIPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスの中に無い場合には、現在確立されているIPTVクライアント端末１０Ａからのセッション確立要求に対するセッションを解放する処理のみが行われる。
【０２１６】
IPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３は、IMSゲートウェイ１１０内のセッション処理部１１６からのセッションの変更要求を受信すると、この変更要求に従って低画質なインスタンスに対するセッションへの変更を行い、IPTVサーバ２０からのコンテンツのデータの受信を続ける（ステップＳ５１７Ｂ）。
【０２１７】
一方、IMSゲートウェイ１１０内のセッション処理部１１６は、IMS-SIPサーバ３３より、IPTVクライアント端末１０Ｂからのセッション確立要求に対してセッションの確立に成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０ＢのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１８）。IPTVクライアント端末内のIPTVクライアントアプリケーション１３は、IMSゲートウェイ１１０内のセッション処理部１１６からセッション確立が成功したことの通知を受信すると、このセッションを通じてIPTVサーバ２０からコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ｂ）。
【０２１８】
ここでは、ユーザの優先度に従って競合解決が行われる場合を例示したが、デバイスの優先度に従って競合解決が行われる場合も同様である。
【０２１９】
以上説明したように、本実施形態では、あるIPTVクライアント端末のユーザから依頼されたセッションが確立されているときに、そのIPTVクライアント端末またはそのユーザよりデバイス／ユーザ優先度が高い別のIPTVクライアント端末のユーザからセッション確立要求が発生した場合には、既に確立されているセッションを低画質のものに変更してでも、後から依頼されたセッションの確立を優先する。これにより、デバイス／ユーザ優先度を重視して適切にセッションを確立することができる。
【０２２０】
（第７の実施形態の変形例１）
【０２２１】
第７の実施形態では、デバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度をもとに、必要ならば既に確立されているセッションに割り当てられたネットワーク帯域を修正することとしたが、デバイス／ユーザ優先度に拠らず、後から別のIPTVクライアント端末からのセッション確立要求が発生しならば、そのセッション確立要求に対するセッションの確立を許可するかどうかを、既にセッションが確立されているIPTVクライアント端末のユーザに呈示してユーザに指定させるようにしてもよい。
【０２２２】
図３７は、この処理のフローチャートである。IPTVクライアント端末１０Ａ（デバイス１）から依頼されたセッションが確立されているときに、IPTVクライアント端末１０Ｂ（デバイス２）よりセッション確立要求が発生した場合に、IPTVクライアント端末１０Ａ（デバイス１）の表示部を通して、そのIPTVクライアント端末１０Ｂ（デバイス２）のセッション確立要求を許可するかどうかをユーザ１に質問する（ステップＳ６０１）。この質問に対してユーザ１から許可する通知が入力されると、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からIMSゲートウェイ１１０内のセッション処理部１１６にセッション確立要求を許可する通知が送信される。
【０２２３】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からセッション確立要求を許可する通知を受信すると、IPTVクライアント端末１０Ｂ（デバイス２）からのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスに対するセッションを確立するようにネゴシエーションを行う。また、セッション処理部１１６は、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスのSDPを参照して、現在セッションが確立されているインスタンスよりもビットレートの低いインスタンスのビットレートを確認し、このビットレートと、IPTVクライアント端末１０Ｂ（デバイス２）からのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスのビットレートとの合計が家庭に割り当てられているネットワーク帯域以下ならば、このインスタンスに対するセッションに変更するように処理を行う（ステップＳ６０２）。
【０２２４】
また、IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からセッション確立要求を許可しない通知を受信した場合には、IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４に対してその旨を通知する。IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４は、この通知を受信すると、表示部を通して、セッション確立許可が下りなかったことをユーザ１に呈示する（ステップＳ６０３）。この後、IMSゲートウェイ１１０内のセッション処理部１１６は、現在確立されているセッションを維持し、IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４からのセッション確立要求を却下する（ステップＳ６０４）。
【０２２５】
本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々更新を加え得ることは勿論である。
【符号の説明】
【０２２６】
３ ネットワーク
１０ IPTVクライアント端末
１３ IPTVクライアントアプリケーション
１４ EPGアプリケーション
１５ メタデータ記憶部
２０ IPTVサーバ
３１ アクセス制御サーバ
３２ ネットワークリソース管理サーバ
３３ IMS-SIPサーバ
４０ メタデータサーバ
５２ ProgramInformationTable要素
５３ ProgramLocationTable要素
５４ ProgramInformation要素
５５ OnDemandProgram要素
５６ Title要素
５７ BasicDescription要素
５９ programURL要素
６０ InstanceDescription要素
６１ Program要素
６２ SDP要素
８４ AVAttributes要素
８５ transportQuality要素
８６ Coding要素
８７ VideoAttributes要素
９１ ServiceInformationTable要素
９２ ServiceInformation要素
９３ OnDemandService要素
９５ ServiceURL要素
１００ IPTVシステム
【技術分野】
【０００１】
本発明は、コンテンツを配信可能なサーバとの間にセッションを確立してコンテンツを視聴するクライアント端末、コンテンツ受信方法、およびセッション管理装置に関するものである。
【背景技術】
【０００２】
IPTV（Internet Protocol Television）は、IPを利用してデジタルテレビ放送を配信するサービス、またはその放送技術の総称である。IPTVのセッション制御の標準候補はIMS（IP Multimedia Sub-system）である。ETSIやITU-T（International Telecommunication Union Telecommunication Standardization Sector）でのNGN（Next Generation Network）の標準化においては、IMSが前提となっている。NGNはIP技術をベースとした次世代の基幹ネットワークである。
【０００３】
IMSは、パケット通信を利用した携帯電話のマルチメディアサービスのこと、あるいはそのようなサービスを実現するための標準である。IMSでは、SIP（Session Initiation Protocol）と呼ばれるIP電話の方式を利用して、マルチメディアセッションをセキュアにかつQoSを保証して制御することができる。すなわち、IMSでは、IPTVのセッションを確立する際に、SIPを利用して、セキュアでQoSの保証されたエンド・ツゥ・エンドのパスを確保して、IPTVのストリーミング等のセッションを制御することができる。
【０００４】
この場合、セッションを確立するために必要なパラメタ（例えばQoS制御のためのパラメタ）がSDP（Session Description Protocol）に記述される。このSDPをボディ部に格納したSIP-INVITEメッセージを、IMS-SIPサーバとコンテンツの提供者がもつ端末との間、さらにはIMS-SIPサーバとコンテンツを視聴するユーザのもつ端末との間で相互に交換することにより、エンド・ツゥ・エンドでセッションを確立するためのパラメタのネゴシエーションが行われる。また、SIP-INVITEメッセージの宛先を示すSIP-URI（Uniform Resource Identifier）には、相手の人（ユーザ）を指定することにより、しかるべきアドレス解決（名前から端末のアドレスへのマッピング）がなされて相手の持っている端末にメッセージが届きセッションが確立される。
【０００５】
特許文献１においては、IMS-SIPを用いたセッション制御の例が挙げられている。すなわち、画像通信装置間で画像通信を行うためのセッションを確立するために、要求元である画像通信装置からの送信要求パケットを受信したADSLゲートウェイからVoIPサービス業者のSIPプロキシに対して、SIPの仕様に基づくセッション要求メッセージ（INVITEメッセージ）を送信し、SIPプロキシは、セッション要求メッセージのヘッダに記述されている宛先のアドレス解決後に、その宛先のADSLゲートウェイへセッション要求メッセージ（INVITEメッセージ）を送信することとしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−１４７１２８号参照（段落００４６等）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、IMS-SIPをIPTVのセッション制御に応用するためには、SIP-INVITEメッセージ等、セッションの確立を促すためのメッセージに、視聴対象のコンテンツならびにコンテンツを提供するサーバへアドレス解決できる情報と、コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタを記述したSDPを格納することが必要になる。
【０００８】
セッションの確立を促すためのメッセージは、IPTVクライアントアプリケーション１３がコンテンツのメタデータをもとに作成しているが、この場合に次のような問題があった。
【０００９】
IPTV（Internet Protocol Television）の標準化における標準メタデータフォーマットの候補がTV-Anytimeメタデータである。TV-Anytimeメタデータは、ETSI（European Telecommunications Standards Institute）で規格化されたメタデータの標準である。例えば、DVB（Digital Video Broadcasting）でのIPTV標準や、ITU-TにおけるIPTV標準のメタデータフォーマットとしてTV-Anytimeメタデータが候補となっている。
【００１０】
しかしながら、TV-Anytimeメタデータの規格においては、IMS上でのIPTVセッションの制御に必要な情報を格納する規定がないため、現状では、TV-AnytimeメタデータをもとにIMS上でのIPTVセッションの制御を実現することができなかった。
【００１１】
また、一般的なIPTVシステムでは、図２０に示すように、IPTVクライアント端末１０とIPTVサーバ２０との間でコンテンツを視聴するためのセッションが確立されるまでに、アクセス制御２１０つまりどのユーザがどのコンテンツにアクセスできるかのアクセス権の制御のためのシグナリング（メッセージ交換）と、セッション制御２２０つまりコンテンツを視聴するためのセッションを確立する制御のためのシグナリングとが分離して行われる。
【００１２】
図２１は、この一般的なIPTVシステムにおいて、IPTVクライアント端末１０とIPTVサーバ２０との間で、コンテンツの視聴のためのIPTVセッションが確立されるまでの手順を示すシーケンス図である。
【００１３】
メタデータサーバ４０は、IPTVクライアント端末１０のEPG（Electronic program Guide）アプリケーション１４からの、コンテンツのメタデータの取得要求を受けて、コンテンツのメタデータを応答する(ステップＳ８０１)。このコンテンツのメタデータには、例えば、コンテンツのタイトル、そのコンテンツを識別するコンテンツID、そのコンテンツを配信するIPTVサーバのURLなどが記述されている。
【００１４】
EPGアプリケーション１４は、メタデータを取得した後（ステップＳ８０２）、このメタデータをもとにコンテンツの検索・選択用のインタフェース画面を作成してユーザに呈示する（ステップＳ８０３）。このインタフェース画面を用いて、ユーザによって、視聴したいコンテンツの検索・選択が行われると、EPGアプリケーション１４は、その選択されたコンテンツを特定し（ステップＳ８０４）、取得したメタデータからそのコンテンツのコンテンツIDを取り出し、このコンテンツIDをIPTVクライアントアプリケーション１３に渡す。
【００１５】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４よりコンテンツIDを受けると、そのコンテンツIDを含む、当該コンテンツに対するアクセス権の確認を要求するメッセージをネットワークを通じてアクセス制御サーバ３１に送信する(ステップＳ８０５)。アクセス制御サーバ３１は、このアクセス権確認要求のメッセージを受信すると、これに含まれるコンテンツIDをもとにアクセス権確認の処理を行う(ステップＳ８０６)。コンテンツのアクセス権を許諾する場合、アクセス制御サーバ３１は、アクセス権許諾の応答メッセージをネットワークを通じてIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に送信するとともに、IPTVサーバ２０に当該コンテンツのアクセス権をIPTVクライアント端末１０に許諾したことを示すメッセージを送信する。
【００１６】
IPTVクライアントアプリケーション１３は、コンテンツのアクセス権許諾の応答を受信した場合には、当該コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタ（例えばQoS制御のためのパラメタ等）の取得を要求するメッセージを、ネットワークを介して、そのコンテンツの配信元であるIPTVサーバ２０に送信する（ステップＳ８０７）。このパラメタ取得要求のメッセージには、視聴対象のコンテンツのコンテンツID等も含まれている。
【００１７】
IPTVサーバ２０は、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３からのパラメタ取得要求のメッセージを受けると、このメッセージに含まれる視聴対象のコンテンツのコンテンツIDと、アクセス制御サーバ３１より事前に受信したアクセス権許諾のメッセージの内容とから、そのパラメタ取得要求が、IPTVクライアント端末１０に対してアクセス権許諾済みのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタの所得要求であるかどうかを判定し、そうであれば、必要なパラメタを検索し、検索したパラメタをネットワークを通じてIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に応答する(ステップＳ８０８)。
【００１８】
この後、IPTVクライアントアプリケーション１３は、取得したパラメタをもとに当該コンテンツを視聴するためのセッションの確立に必要なネットワークリソースの確保を要求するメッセージを生成し、これをネットワークを通じてネットワークリソース管理サーバ３２とIPTVサーバ２０にそれぞれ送信する (ステップＳ８０９)。
【００１９】
ネットワークリソース管理サーバ３２は、このネットワークリソース確保要求のメッセージを受信すると、このメッセージに含まれているパラメタをもとに当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保のための処理を行う(ステップＳ８１０)。一方、IPTVサーバ２０は、ネットワークリソース確保要求のメッセージを受信すると、このメッセージに含まれているパラメタをもとに当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースを確保し（ステップＳ８１１）、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間でIPTVセッションを確立する処理を行う(ステップＳ８１２及びステップＳ８１３)。
【００２０】
このように、一般的なIPTVシステムでは、IPTVクライアント端末１０とIPTVサーバ２０との間でコンテンツを視聴するためのセッションが確立されるまでに、アクセス制御２１０のためのシグナリングと、セッション制御２２０のためのシグナリングとが行われ、プロトコル処理のオーバヘッドが嵩むという問題があった。
【００２１】
本発明は、かかる実情に鑑み、メタデータをもとにコンテンツを配信可能なサーバとのセッションの制御を実現することのできるコンテンツを配信可能なサーバとの間にセッションを確立してコンテンツを視聴するクライアント端末、コンテンツ受信方法、およびセッション管理装置を提供しようとするものである。
【課題を解決するための手段】
【００２２】
上記の課題を解決するために、本発明の第１の側面のクライアント端末は、コンテンツの視聴のために当該コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得するメタデータ取得部と、前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するメッセージ送信部とを具備する。
【００２３】
本発明によれば、メッセージ生成部が、取得したメタデータから、コンテンツを配信可能なサーバからコンテンツを受信するためのセッションの確立を促すためのメッセージを生成し、メッセージ送信部がこのメッセージをセッションを確立する制御を行うサーバに送信することで、クライアント端末とコンテンツを配信可能なサーバとの間でのセッションが確立される。
【００２４】
前記セッションを確立するために必要な情報はQoS（Quality of Service）の制御のための情報を含むものであってよい。
【００２５】
前記クライアント端末は携帯機器であってよい。
【００２６】
本発明の第２の側面であるコンテンツ受信方法は、コンテンツを受信するためのセッションを確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得し、前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するというものである。
【００２７】
本発明の第３の側面であるセッション管理装置は、コンテンツの視聴のために前記コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得することが可能なクライアント端末より、前記コンテンツを識別するためのコンテンツ識別子および前記セッションを確立するために必要な情報を含むセッション確立要求を受信し、前記コンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記セッションの制御を行うことが可能なサーバに送信するセッション処理部を具備するものである。
【発明の効果】
【００２８】
本発明によれば、メタデータをもとにコンテンツを配信可能なサーバとのセッションの制御を実現することができる。
【図面の簡単な説明】
【００２９】
【図１】本発明の第１の実施形態にかかるIPTVシステムでのIMS上のIPTVセッション制御の概要を示す図である。
【図２】図１のIPTVシステムにおいてIMS-SIPによるセッション制御にアクセス制御のシグナリングを組み込んだ状態を示す図である。
【図３】図１のIPTVシステムの全体的な構成を示す図である。
【図４】図１のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図５】SIP-URI及びSDPを格納したTV-Anytimeメタデータの例を示す図である。
【図６】SDP要素の導入のためのXMLスキーマの拡張に必要なXMLスキーマのシンタクスの例を示す図である。
【図７】メタデータサーバでのTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図８】SIP-INVITEメッセージのフォーマットを示す図である。
【図９】TV-AnytimeメタデータにtransportQuality要素を導入する拡張のためのXMLスキーマのシンタクスの例を示す図である。
【図１０】図９のtransportQuality要素導入のXMLスキーマ拡張により、転送品質等のQoSパラメタが格納されたTV-Anytimeメタデータの例を示す図である。
【図１１】transportQualityCS制限用語辞書の定義の例を示す図である。
【図１２】VisualCodingFormatCS制限用語辞書の定義の例を示す図である。
【図１３】本発明の第２の実施形態にかかるSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【図１４】メタデータサーバでの図１３に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図１５】sipURI属性導入の拡張のためのXMLスキーマのシンタクスの例を示す図である。
【図１６】sipURI属性を導入するXMLスキーマ拡張によりSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【図１７】メタデータサーバでの図１６に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【図１８】IPTVクライアント端末のハードウェアの構成を示すブロック図である。
【図１９】サーバのハードウェアの構成を示すブロック図である。
【図２０】一般的なIPTVシステムにおける、アクセス制御のためのシグナリングとセッション制御のためのシグナリングとの関係を示す図である。
【図２１】一般的なIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間で、コンテンツの視聴のためのIPTVセッションが確立されるまでの手順を示すシーケンス図である。
【図２２】本発明の第４の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図２３】第４の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図２４】インスタンス選択基準の設定画面の例を示す図である。
【図２５】IPTVクライアント端末からIMSゲートウェイに送信されるセッション確立要求に含まれるリストの例を示す図である。
【図２６】第４の実施形態の変形例１である動作を示すフローチャートである。
【図２７】優先度選択画面とユーザによる各インスタンスの優先度の選択例を示す図である。
【図２８】コンテンツの選択画面の例を示す図である。
【図２９】第４の実施形態の変形例１である動作を示すフローチャートである。
【図３０】本発明の第５の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図３１】本発明の第６の実施形態にかかるIPTVシステムの全体的な構成を示す図である。
【図３２】第６の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図３３】デバイス／ユーザ優先度を設定するための画面の構成を示す図である。
【図３４】２つのIPTVクライアント端末からIMSゲートウェイに送信された２つのセッション確立要求に含まれるリストの例を示す図である。
【図３５】第７の実施形態のIPTVシステムにおいて、IPTVクライアント端末とIPTVサーバとの間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【図３６】図３５から続くシーケンス図である。
【図３７】第７の実施形態の変形例を示すフローチャートである。
【図３８】第６の実施形態の変形例を示すシーケンス図である。
【発明を実施するための最良の形態】
【００３０】
以下、本発明の実施の形態を図面を用いて詳細に説明する。
【００３１】
図１は、本発明の第１の実施形態にかかるIPTVシステム１００でのIMS上のIPTVセッション制御の概要を示す図である。
【００３２】
同図に示すように、この実施形態のIPTVシステム１００では、コンテンツを視聴するユーザが持つIPTVクライアント端末１０とコンテンツを配信するIPTVサーバ２０との間で、IMSプラットフォームを提供するサーバ群３０を介して、SIP-INVITEメッセージ、SIP-BYEメッセージ等のSIPメッセージを交換する。これにより、IPTVクライアント端末１０とIPTVサーバ２０との間での、コンテンツを視聴するためのIPTVセッションの確立／解放等の制御が行われる。
【００３３】
図３は、図１のIPTVシステム１００の全体的な構成を示す図である。
【００３４】
同図に示すように、このIPTVシステム１００は、コンテンツを視聴するユーザ１が持つIPTVクライアント端末１０、コンテンツを配信するIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０、及びこれらを接続可能なネットワーク３とで構成される。
【００３５】
IPTVクライアント端末１０は、例えば、PC、セットップボックス、TV等の端末機器である。IPTVクライアント端末１０は、ユーザインタフェース部１１、ネットワークインタフェース部１２、IPTVクライアントアプリケーション１３、EPGアプリケーション１４、メタデータ記憶部１５、コンテンツ記憶部１６、コンテンツ再生部１７等を備える。
【００３６】
ユーザインタフェース部１１は、ユーザ１に対する入出力を処理する。例えば、ユーザインタフェース部１１は、ユーザ１からの各種の指令を入力して、IPTVクライアントアプリケーション１３やEPGアプリケーション１４に出力したり、IPTVクライアントアプリケーション１３やEPGアプリケーション１４からユーザ１への応答やコンテンツの再生情報を出力する処理などを行う。
【００３７】
ネットワークインタフェース部１２は、インターネット等のネットワーク３とのインタフェースを提供する。
【００３８】
IPTVクライアントアプリケーション１３は、IPTVクライアント端末１０をIPTVクライアントとして動作させるための制御を行うソフトウエアである。
【００３９】
EPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０よりコンテンツのメタデータを取得する処理、このメタデータを用いて視聴対象のコンテンツをユーザ１に検索・選択させるためのインタフェース画面を作成する処理、さらには、このインタフェース画面でユーザ１によって選択されたコンテンツを視聴するためのIPTVセッションの確立を促すためのメッセージの作成に必要な情報をメタデータより抽出して、IPTVクライアントアプリケーション１３に渡す処理等を行う。
【００４０】
メタデータ記憶部１５は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置で構成され、メタデータサーバ４０より取得したコンテンツのメタデータを格納する。
【００４１】
コンテンツ記憶部１６は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置で構成され、IPTVセッションが確立されたIPTVサーバ２０よりストリーミングやダウンロード等により受信したコンテンツのデータを格納する。
【００４２】
コンテンツ再生部１７は、コンテンツ記憶部１６に格納されたコンテンツのデータのデコードから再生までの処理を行う。
【００４３】
メタデータサーバ４０は、IPTVクライアント端末１０のEPGアプリケーション１４からの取得要求に応じて、自身に管理されているコンテンツのメタデータを送信する。
【００４４】
IMSプラットフォームを提供するサーバ群３０は、コンテンツに対するアクセス権の確認等の制御を行うアクセス制御サーバ３１、IPTVセッションを確立するために必要なネットワークリソースを管理するネットワークリソース管理サーバ３２、IMS-SIPを用いてIPTVセッションの確立／解放等の制御を行うIMS-SIPサーバ３３等で構成される。
【００４５】
IMS-SIPサーバ３３は、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３よりSIP-INVITEメッセージを受信したとき、このSIP-INVITEメッセージの宛先に格納されたSIP-URIを用いてアクセス制御サーバ３１に対して当該コンテンツのアクセス権の確認を依頼する処理を行う。また、IMS-SIPサーバ３３は、アクセス制御サーバ３１よりそのコンテンツのアクセス権の許諾を受けたとき、SIP-INVITEメッセージのボディ部に格納されたSDPを用いてネットワークリソース管理サーバ３２に対して、当該コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保を依頼する処理を行う。さらに、IMS-SIPサーバ３３は、ネットワークリソース管理サーバ３２よりネットワークリソースの確保応答を受信したとき、IPTVクライアントアプリケーション１３より受信したSIP-INVITEメッセージを、このSIP-INVITEメッセージの宛先に格納されたSIP-URIをもとに該当するIPTVサーバ２０に送信する処理を行う。
【００４６】
IPTVサーバ２０は、配信可能なコンテンツのデータを管理しており、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間で、コンテンツの視聴のためのIPTVセッションを確立して、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３に対して、コンテンツのストリーミングあるいはダウンロード等による配信を行う。
【００４７】
図１８は、IPTVクライアント端末１０のハードウェアの構成を示すブロック図である。同図に示すように、CPU（Central Processing Unit）５０１には、システムバス５０２を介して、ROM（Read Only Memory）５０３と、RAM（Random Access Memory）５０４と、入力操作部５０５と、表示部５０６と、音声出力部５０７と、ネットワークインタフェース部１２と、光通信部５１１と、記憶部５１２とが接続されている。
【００４８】
入力操作部５０５は、各種のキーなどを備え、ユーザからの各種の命令やデータの入力を処理する。入力操作部５０５によってユーザより入力された命令は、図示しない入力インタフェース部によってシステムバス５０２を通じてCPU５０１に供給される。表示部５０６は、例えば、LCD（Liquid Crystal Display）などの表示器と、表示器を駆動する表示制御回路よりなる。音声出力部５０７は、デジタルの音声信号をアナログの音声信号に変換する回路と、スピーカなどよりなる。入力操作部５０５、表示部５０６、音声出力部５０７は、図３のユーザインタフェース部１１に相当する。ネットワークインタフェース部１２は、ネットワーク３との有線または無線での接続を処理する。
【００４９】
光通信部５１１は、リモートコントローラやその他の外部機器との間での通信を処理するためのインタフェースであり、具体的には、赤外線などの光を無線媒体として外部機器との通信を行うものである。また、光の他に、電波、音波、電磁波などの他の無線媒体を用いてもよい。記憶部５１２は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置である。
【００５０】
ROM５０３は、IPTVクライアント端末１０としての機能をコンピュータに実行させるためのプログラムやデータなどが恒久的に格納された読み出し専用メモリである。なお、プログラムは記憶部５１２に格納されていてもよい。RAM５０４は、ROM５０３や記憶部５１２からロードされたプログラムやプログラムの作業データ等を書き込むために使用されるメモリである。CPU５０１は、ROM５０３に格納されたプログラムやRAM５０４にロードされたプログラムを解釈実行するための演算処理を行う。
【００５１】
図１９は、IPTVサーバ２０、アクセス制御サーバ３１、ネットワークリソース管理サーバ３２、IMS-SIPサーバ３３、メタデータサーバ４０のハードウェアの構成を示すブロック図である。
【００５２】
IPTVサーバ２０、アクセス制御サーバ３１、ネットワークリソース管理サーバ３２、IMS-SIPサーバ３３、メタデータサーバ４０はいずれも、図１９に示すように、パーソナルコンピュータなどの典型的なコンピュータシステムからなる構成とされている。
【００５３】
すなわち、CPU６０１には、システムバス６０９を介して、ROM６０２と、RAM６０３と、ネットワークインタフェース部６０４と、キーボード、マウスなどよりなる入力部６０５と、CRT（Cathode Ray Tube）、LCDなどよりなるディスプレイとスピーカなどよりなる出力部６０６と、メディアインタフェース部６０７と、ハードディスクドライブや不揮発性メモリなどよりなる記憶部６０８とが接続されている。
【００５４】
ネットワークインタフェース部６０４は、ネットワーク３との有線または無線での接続を処理する。記憶部６０８には、特定のサーバとしての機能をコンピュータに実行させるためのプログラムと、各種のデータなどが格納されている。CPU６０１は、ROM６０２や記憶部６０８からプログラムをRAM６０２へロードして、解釈実行するための演算処理を行う。メディアインタフェース部６０７には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２が適宜装着され、それらから読み出されたプログラムが、必要に応じて記憶部６０８にインストールされる。
【００５５】
次に、本実施形態のIPTVシステム１００において、IPTVクライアント端末１０とIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を説明する。
【００５６】
図４は、この動作を示すシーケンス図である。IPTVクライアント端末１０においては、IPTVクライアントアプリケーション１３及びEPGアプリケーション１４が既に起動されているものとする。
【００５７】
メタデータサーバ４０は、コンテンツのメタデータを作成して格納しており（ステップＳ１０１）、IPTVクライアント端末１０のEPGアプリケーション１４より、メタデータの取得要求を受けたとき、そのIPTVクライアント端末１０のEPGアプリケーション１４にコンテンツのメタデータを提供する(ステップＳ１０２)。IPTVクライアント端末１０のEPGアプリケーション１４は、メタデータサーバ４０よりコンテンツのメタデータを受信し、メタデータ記憶部１５に格納する（ステップＳ１０３）。
【００５８】
EPGアプリケーション１４は、取得したメタデータをもとに、コンテンツの検索・選択用のインタフェース画面を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ１０４）。このインタフェース画面を用いて、ユーザ１によって、視聴したいコンテンツの検索・選択が行われると（ステップＳ１０５）、EPGアプリケーション１４は、ユーザ１によって視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたメタデータから当該視聴対象コンテンツの場所を指定するSIP-URIと、このコンテンツに対応するSDPを抽出してIPTVクライアントアプリケーション１３に渡す（ステップＳ１０６）。
【００５９】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より取得したSIP-URI及びSDPを用いて、そのコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージを生成し（ステップＳ１０７）、このSIP-INVITEメッセージを、ネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する（ステップＳ１０８）。
【００６０】
IMSプラットフォームを提供するサーバ群３０において、IMS-SIPサーバ３３は、IPTVクライアント端末１０のEPGアプリケーション１４からのSIP-INVITEメッセージを受信すると、このSIP-INVITEメッセージからSIP-URIを抽出し、このSIP-URIを少なくとも含む、コンテンツのアクセス権の確認を依頼するメッセージをアクセス制御サーバ３１に送信する。アクセス制御サーバ３１は、このアクセス権確認依頼のメッセージに含まれるSIP-URIをもとに当該コンテンツのアクセス権の確認を行う（ステップＳ１０９）。アクセス制御サーバ３１は、当該コンテンツのアクセス権を許諾することを判定した場合には、IMS-SIPサーバ３３にアクセス権許諾の応答メッセージを送信し、当該コンテンツのアクセス権を許諾しないことを判定した場合には、IMS-SIPサーバ３３にアクセス権非許諾の応答メッセージを送信する。以後、アクセス権が許諾された場合について説明を続ける。
【００６１】
IMS-SIPサーバ３３は、アクセス権許諾の応答メッセージを受信すると、SIP-INVITEメッセージのボディ部からSDPを抽出し、このSDPを用いて、ネットワークリソースの確保を要求するメッセージを生成してネットワークリソース管理サーバ３２に送信する。ネットワークリソース管理サーバ３２はネットワークリソース確保要求のメッセージを受けると、これに含まれるSDPをもとに、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保のための処理を行った後（ステップＳ１１０）、IMS-SIPサーバ３３にネットワークリソースの確保応答のメッセージを送信する。IMS-SIPサーバ３３は、ネットワークリソースの確保応答のメッセージを受信すると、SIP-INVITEメッセージの宛先をもとに、SIP-INVITEメッセージをIPTVサーバ２０に送信する（ステップＳ１１１）。
【００６２】
IPTVサーバ２０は、IMS-SIPサーバ３３よりIMS-INVITEメッセージを受信すると、コンテンツを視聴するためのIPTVセッションを確立するために必要なネットワークリソースを確保し(ステップＳ１１２)、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間でIPTVセッションを確立する処理を行う(ステップＳ１１３及びステップＳ１１４)。
【００６３】
この後、図示は省略したが、確立されたIPTVセッションを用いて、IPTVサーバ２０からIPTVクライアント端末１０のIPTVクライアントアプリケーション１３への、ストリーミングまたはダウンロードによるコンテンツのデータの配信が行われる。
【００６４】
コンテンツのメタデータのフォーマットにはTV-Anytimeを用いることとする。このTV-Anytimeの規格には、IMS上のIPTVセッション制御に必要な情報を提供する規定が設けられていない。そこで、この実施形態においては、IMS上のIPTVセッション制御に必要な情報である、コンテンツの場所を指定するSIP-URIと、このコンテンツを視聴するためのセッションの確立に必要なパラメタが記述されたSDPを、次のような方法でTV-Anytimeメタデータに格納している。
【００６５】
次に、TV-Anytimeメタデータにコンテンツの場所を指定するSIP-URI及びSDPを格納する方法について説明する。
【００６６】
図５にSIP-URI及びSDPを格納したTV-Anytimeメタデータの例を示す。
【００６７】
TV-AnytimeメタデータはTVAMain要素５０をルート要素に持つXML（Extensible Markup Language）ドキュメントである。ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置される。さらにその下にはProgramInformationTable要素５２、ProgramLocationTable要素５３が配置される。ProgramInformationTable要素５２の下には、１つ以上のProgramInformation要素５４を配置できる。ProgramInformation要素５４の下には、コンテンツのタイトルが格納されるTitle要素５６、その他のコンテンツのメタデータが格納される要素（図示せず）を子要素として有するBasicDescription要素５７が配置されている。また、ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRID（Content Reference Identifier）が格納される。
【００６８】
CRIDのフォーマットは、"crid://<CRID_Authority"のDNS名>/<CRID_Authority内で一意な識別子>"とされ、例えば、"crid://ca.com/123"のように定義される。CRID_Authorityは、CRIDを一意（スコープはCRID_Ahthority）に振り出すエンティティである。
【００６９】
ProgramLocationTable要素５３の下には、ProgramLocation要素の派生であるOnDemandProgram要素５５を１つ以上配置できる。OnDemandProgram要素５５の下には、CRIDをcrid属性の値として格納するProgram要素６１、コンテンツの場所を指定するSIP-URIが格納されるprogramURL要素５９、InstanceDescription要素６０が配置されている。
【００７０】
TV-Anytimeにおいて、ProgramURLは、"An element specifying a programme location."と定義されており、コンテンツの場所は、通常、"http://..."等のURL（Uniform Resource Locator）で指定される。本実施形態では、コンテンツの場所を指定するために、SIPのメッセージの宛先であるSIP-URIが採用されている。SIP-URIは、例えば、"sip:ca.com_123@as.sp.com"のような形式で指定される。ここで、"ca.com_123"は、CRIDである"crid://abc.com/123"において、URLにおけるスキームを示す"crid:"と"//"を削除し、セパレータである"/"を"_"に置換して生成される。"@"以降の"as.sp.com"は、IPTVサーバ２０のDNS（Domain Name System）名である。
【００７１】
InstanceDescription要素６０の下には、コンテンツを視聴するためのIPTVセッションの確立に必要なパラメタである、例えば、セッション名、セッション生成者、セッション有効期間、メディア記述として音声や動画を送受信するために必要なコーデックの情報等を含むSDPを格納するSDP要素６２が配置されている。しかし、TV-Anytimeの規格には、SDPを格納できる要素が定められていないので、この実施形態では、オリジナルのTV-Anytimeメタデータに対するXMLスキーマで定義されるInstanceDescription要素に対応する型であるInstanceDescriptionType要素を拡張して、SDPを格納するためのSDP要素６２を新たに導入している。
【００７２】
図６はこのSDP要素の導入のためのXMLスキーマ拡張に必要なXMLスキーマのシンタクスの例である。このXMLスキーマのシンタクスには、オリジナルのTV-Anytimeメタデータを識別する名前空間６３、XMLスキーマを識別する名前空間６４、新しく定義するスキーマが"urn:IPTV"で識別されることの宣言６５、新しいXMLスキーマにおけるInstanceDescriptionTypeの定義６６、拡張するオリジナルのTV-Anytimeの要素の指定６７、追加する属性であるSDPの定義６８が含まれている。
【００７３】
図５に示したTV-Anytimeメタデータの例では、InstanceDescription要素６０内のxsi:type属性によるオーバーライドによって、上述のXMLスキーマの拡張で導入された名前空間"urn:IPTV"のInstanceDescriptionType型を参照することにより、オリジナルのTV-AnytimeメタデータのInstanceDescription要素が、このXMLスキーマの拡張で定義されたSDP要素６２を持つInstanceDescription要素６０に置換される。
【００７４】
図７は、メタデータサーバ４０での図５に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【００７５】
メタデータサーバ４０で図５に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まず、ProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、OnDemandProgram要素５５におけるProgram要素６１のcrid属性の値として"crid://ca.com/123"を格納する。これにより、ProgramInformation要素５４とOnDemandProgram要素５５とがcrid属性の値によって紐付けられる。次に、メタデータサーバ４０は、OnDemandProgram要素５５におけるprogramURL要素５９に、crid属性の値である"crid://ca.com/123"とコンテンツの配信元であるIPTVサーバ２０のDNS名"as.sp.com"とから生成した"sip:ca.com_123@as.sp.com"をコンテンツの場所を指定するSIP-URIとして格納する。さらに、メタデータサーバ４０は、そのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタを含むSDPを、XMLスキーマの拡張で、InstanceDescription要素６０の下に導入されたSDP要素６２に格納する。ここまでで、１つのコンテンツに関するSIP-URI及びSDPの格納が完了となる。実際には、複数のコンテンツについてSIP-URI及びSDPの格納が繰り返され、その都度、ProgramInformationTable要素５２内のProgramInformation要素５４とProgramLocationTable要素５３内のOnDemandProgram要素５５が追加されて行くこととなる（ステップＳ１０１）。
【００７６】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ１０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ１０４）。この画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ１０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【００７７】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、取得したTV-Anytimeメタデータから、Program要素６１のcrid属性の値が"crid://ca.com/123"であるOnDemandProgram要素５５のProgramURL要素５９に格納されたSIP-URIである"sip:ca.com_123@as.sp.com"と、そのOnDemandProgram要素５５内のInstanceDescription要素６０の下に配置されたSDP要素６２のSDPの内容を取り出してIPTVクライアントアプリケーション１３に渡す（ステップＳ１０６）。
【００７８】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡されたSIP-URIである"sip:ca.com_123@as.sp.com"をSIP-INVITEメッセージの宛先に格納するとともに、EPGアプリケーション１４より渡されたSDPを、SIP-INVITEメッセージのボディ部に格納する。これによってコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージが生成される（ステップＳ１０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ１０８）。以後の動作は、図４を参照して説明したとおりである。
【００７９】
図８は、SIP-INVITEメッセージのフォーマットを示す図である。ここで、SIP-INVITEメッセージの宛先であるSIP-URIの部分７１には、視聴しようとしているコンテンツへアドレス解決できる情報、つまり上記の例においては"sip:ca.com_123@as.sp.com"が格納され、ボディ部７２にはSDPが格納される。IPTVシステム１００では、このSIP-INVITEメッセージを、IMS-SIPサーバ３３を介してIPTVクライアント端末１０とIPTVサーバ２０との間で相互に交換することにより、コンテンツを視聴するためのIPTVセッションを確立するためのパラメタのネゴシエーションが行われる。
【００８０】
次に、図５に示したTV-Anytimeメタデータの変形例を説明する。
【００８１】
図５に示したTV-AnytimeメタデータのSDP要素６２の"SDPの内容"の部分にはSDPの記述そのものが格納されるが、SDP要素６２内に表現される、例えば、コーデックやQoSパラメタ等の情報については、このままではXMLの要素としては抽出することはできない。市場に浸透してきているネイティブXMLデータベースのようなXML要素やその属性をそのまま検索の対象として扱えるようなデータベースに、SDPを含むTV-Anytimeメタデータを格納する場合、SDPの内容をベースに検索することができないこととなる。これらのデータベースにメタデータを格納し、コーデックやQoSパラメタ等の情報をもとに、対象となるメタデータを検索させるためには、以下の変形例のような方法を用いることが必要となる。
【００８２】
SDPの基本的な内容のうち、コーデックについては、オリジナルのTV-AnytimeメタデータのProgramLocation要素内のInstanceDescription要素内のAVAttributes要素内のVideoAttributes要素内のCoding要素に記述できるが、転送品質等のQoSパラメタを記述できる要素／属性は、オリジナルのTV-Anytimeメタデータには規定されていない。
【００８３】
そこで、この変形例では、転送品質等のQoSパラメタをTV-Anytimeメタデータに記述して検索、照会できるように、ProgramLocation要素内のInstanceDescription要素内のAVAttributes要素内に、転送品質等のQoSパラメタを格納するためのtransportQuality要素を新たに導入するように、XMLスキーマの拡張を行うこととする。
【００８４】
次に、このtransportQuality要素の導入のためのXMLスキーマの拡張方法の詳細を説明する。
【００８５】
図９は、このtransportQuality要素導入の拡張のためのXMLスキーマのシンタクスの例である。このXMLスキーマの拡張のためのシンタクスには、新しいXMLスキーマにおけるAVAttributesTypeの定義８１、拡張するオリジナルのTV-Anytimeの要素の指定８２、追加する属性であるtransportQualityの定義８３等が含まれている。
【００８６】
図１０は、このtransportQuality要素導入のXMLスキーマ拡張により、転送品質等のQoSパラメタが格納されたTV-Anytimeメタデータの例である。
【００８７】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置される。さらにその下にはProgramInformationTable要素５２、ProgramLocationTable要素５３が配置される。ProgramInformationTable要素５２の下には、１つ以上のProgramInformation要素５４が配置される。ProgramInformation要素５４には、ストリーミングもしくはダウンロード等により配信されるコンテンツのタイトル等のメタデータが記述される。ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRIDが格納される。
【００８８】
ProgramLocationTable要素５３の中には、ProgramLocation要素の派生であるOnDemandProgram要素５５が１つ以上配置される。OnDemandProgram要素５５の下には、CRIDが格納されたProgram要素６１と、コンテンツの場所を指定するSIP-URIが格納されたProgramURL要素５９と、InstanceDescription要素６０とが配置されている。
【００８９】
InstanceDescription要素６０の下には、SDP要素６２と、AVAttributes要素８４が配置されている。AVAttributes要素８４の下には、コーデックの情報が記述されるCoding要素８６を子要素としてもつVideoAttributes要素８７が配置されている。そして、この例では、AVAttributes要素８４のxsi:type属性によるオーバーライドにより、上述のXMLスキーマ拡張で導入された名前空間"urn:IPTV"のAVAttributes型を参照することにより、オリジナルのTV-AnytimeメタデータのAVAttributes要素を、このXMLスキーマ拡張で定義されたtransportQuality要素８５を持つAVAttributes要素８４に置換している。
【００９０】
transportQuality要素８５はControlledTermTypeであるが、この型は、制限用語辞書を参照する型である。このため、参照する辞書を、例えば以下のように定義する。
【００９１】
図１１に、transportQualityCS制限用語辞書の定義の例を示す。ここで定義されている３つの転送品質クラスを示すAssuredForwarding、ExcellentEffort、BestEffortの制限用語の間の関係は、品質クラスが高い（遅延やジッターが小さい）ものから、AssuredForwarding、ExcellentEffort、BestEffortの順となる。以下の辞書定義においては、それぞれAssuredForwardingが"urn:iptv:transportQualityCS:1"に、ExcellentEffortが"urn:iptv:transportQualityCS:2"に、BestEffortが"urn:iptv:transportQualityCS:3"に割り当てられる。
【００９２】
SDPでは、記述する対象のメディアの属性をｍ行とａ行の組み合わせにより表現するが、上述の転送品質クラスは、対応するSDPの内容のうち、例えば、以下の属性値の組み合わせにより決定されるものとする。
【００９３】
転送品質クラスがAssuredForwardingクラスとなるのは、SDPのｍ行／ａ行、以下の（１）〜（２）のいずれかの場合：
（１）media-type=videoかつa=sendrecv
（２）media-type=audioかつa=sendrecv
転送品質クラスがExcellentEffortとなるのは、SDPのｍ行／ａ行が、以下の（１）〜（４）のいずれかの場合：
（１）media-type=videoかつa=sendonly
（２）media-type=videoかつa=recvonly
（３）media-type=audioかつa=sendonly
（４）media-type=audioかつa=recvonly
転送品質クラスがBestEffortとなるのは、SDPのｍ行／ａ行が、以下の（１）〜（４）のいずれかの場合：
（１）media-type=data
（２）media-type=text
（３）media-type=application
（４）media-type=message
例えば、SDPの内容に、
"m=video … (メディアの種類はビデオであることを示す)"と
"a=sendrecv (送受信モードで処理しなければならないことを示す)"
の各行が含まれる場合には、転送品質クラスは、"AssuredForwarding"となる。これは、上記のtransportQualityCS制限用語辞書定義から、"urn:iptv:transportQualityCS:1"に相当する。
【００９４】
図１０に示したtransportQuality要素８５の導入のための拡張が行われたTV-Anytimeメタデータの例では、Coding要素８６に辞書参照href="urn:iptv:VisualCodingFormatCS:2"と記述されている。これは、例えば、以下のようなコーディングフォーマットを指定する、名前空間"urn:iptv:VisualCodingFormatCS"で識別されるVisualCodingFormatCS制限用語辞書定義があるものとしている。図１２に、このVisualCodingFormatCS制限用語辞書の定義の例を示す。
【００９５】
以上説明したように、この実施形態によれば、コンテンツを視聴するためのIMS上のIPTVセッションの確立を促すSIP-INVITEメッセージの生成に必要な情報を格納したTV-AnytimeメタデータをIPTVクライアント端末１０に提供することによって、IPTVクライアント端末１０は、このTV-Anytimeメタデータをもとに、視聴したいコンテンツの場所を指定するSIP-URIを宛先に格納し、そのコンテンツを視聴するためのIPTVセッションの確立に必要なパラメタが記述されたSDPをボディ部に格納したSIP-INVITEメッセージを生成することができる。
【００９６】
また、この実施形態によれば、SIP-INVITEメッセージのSIP-URIにより、コンテンツへのアドレス解決に必要な情報へ誘導できることによって、IMSプラットフォームそのもので提供される、例えばSIPによるセッション確立の際の認証メカニズム等を、そのまま、コンテンツへのアクセス制御等に利用することができる。これにより、そのコンテンツへのアクセス制御をIMS-SIPによるセッション制御のレイヤーで実現でき、図２に示すように、IMS-SIPによるセッション制御２２０にアクセス制御２１０のシグナリングを組み込むことが可能となって、プロトコル処理のオーバヘッドの大幅な低減を図ることが期待できる。
【００９７】
(第２の実施形態)
【００９８】
次に、本発明の第２の実施形態として、SIP-URIをTV-Anytimeメタデータに格納する別の方法とともに、IPTVクライアント端末１０において、そのTV-AnytimeメタデータからSIP-INVITEメッセージを生成する方法について説明する。
【００９９】
図１３は、本発明の第２の実施形態にかかるSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【０１００】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置されている。ProgramDescription要素５１の下には、ProgramInformationTable要素５２、ProgramLocationTable要素５３、及びServiceInformationTable要素９１が配置されている。このServiceInformationTable要素９１の中には、複数のServiceInformation要素９２を配置できる。ProgramInformationTable要素５２の構成は図５及び図１０に示したものと同じである。
【０１０１】
ProgramLocationTable要素５３の中には、ProgramLocation要素の派生であるOnDemandProgram要素５５（図５及び図１０）に代えてOnDemandService要素９３が配置されている。このOnDemandService要素９３には、CRIDをcrid属性の値として格納するProgram要素６１、コンテンツのインスタンスのメタデータ（配信にかかわるメタデータ）が格納されるとともに、serviceIdRef属性の値として、コンテンツを提供するサービスのIDが格納されている。この例では、サービスのIDとして"sid"が格納されている。
【０１０２】
ServiceInformation要素９２には、サービスの名前等のサービスのメタデータが格納されている。また、ServiceInformation要素９２は、サービスのIDをserviceId属性の値として格納し、このserviceId属性の値によって識別される。さらに、ServiceInformation要素９２の下には、サービスの名前を格納するName要素９４と、サービスを提供するIPTVサーバ２０のURLを格納するServiceURL要素９５と、その他、サービスのメタデータを格納する要素（図示せず）が配置されている。
【０１０３】
TV-Anytimeにおいて、ServiceURLは、"An optional URL for the service e.g. a DVB URL. This URL allows the receiver to identify the associated physical service."と定義されているが、ここでは、ServiceURLとして、コンテンツの配信元であるIPTVサーバ２０のURLが指定されることとする。このIPTVサーバ２０のURLのスキームには"http:"が使用され、例えば、図１４に示すように、"http://as.sp.com"のように指定される。
【０１０４】
図１４は、メタデータサーバ４０での図１３に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【０１０５】
メタデータサーバ４０で図１３に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まずProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、OnDemandService要素９３のserviceIdRef属性の値としてサービスのIDである例えば"sid"を格納し、そのOnDemandService要素９３内のProgram要素６１のcrid属性の値として、CRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、ServiceInformation要素９２のserviceId属性の値として、OnDemandService要素９３のserviceIdRef属性の値として格納されているサービスのIDである例えば"sid"を格納し、そのServiceInformation要素９２内のName要素９４にサービスの名前として例えば"contentService"を格納し、そのServiceInformation要素９２内のServiceURL要素９５に、コンテンツの配信元であるIPTVサーバ２０のDNS名である"as.sp.com"に"http://"を付けた"http://as.sp.com"を格納する。なお、実際には、TV-Anytimeメタデータには、そのコンテンツを視聴するためのIPTVセッションの確立に必要なSDPも格納されるが、このSDPをTV-Anytimeメタデータに格納する方法については前述した通りであり、ここでは省略する。
【０１０６】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ２０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ２０４）。このインタフェース画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ２０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【０１０７】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、TV-Anytimeメタデータから、Program要素６１のcrid属性の値が"crid://ca.com/123"であるOnDemandService要素９３のserviceIdRef属性の値である"sid"をserviceId属性の値として持つServiceInformation要素９２内のServiceURL要素９５に格納された"http://as.sp.com"と、OnDemandService要素９３内のProgram要素６１のcrid属性の値"crid://ca.com/123"と、図示しないSDP要素に格納されたSDPの内容をIPTVクライアントアプリケーション１３に渡す（ステップＳ２０６）。
【０１０８】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡された"http://as.sp.com"から"http://"を除いた"as.sp.com"と、OnDemandService要素９３のProgram要素６１のcrid属性の値である"crid://abc.com/123"から"crid://"を除いた"ca.com/123"から生成した"ca.com_123"と、さらには"sip-uri:"と"@"とを用いて"sip-uri:ca.com_123@as.sp.com"を生成し、これをSIP-INVITEメッセージの宛先にSIP-URIとして格納するとともに、SDPをSIP-INVITEメッセージのボディ部に格納する。これによってコンテンツを視聴するためのIPTVセッションの確立を促すためのSIP-INVITEメッセージが生成される（ステップＳ２０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ２０８）。以後の動作は、第１の実施形態で図４を参照して説明したとおりである。
【０１０９】
以上説明したように、この実施形態によっても、IPTVクライアント端末１０にて、TV-Anytimeメタデータをもとに、SIP-INVITEメッセージの宛先に格納するSIP-URIを得ることができる。
【０１１０】
(第３の実施形態)
【０１１１】
次に、本発明の第３の実施形態として、SIP-URIをTV-Anytimeメタデータに格納する別の方法とともに、IPTVクライアント端末１０において、そのTV-AnytimeメタデータからSIP-INVITEメッセージを生成する方法について説明する。
【０１１２】
SIP-URIをそのまま格納できる要素は、オリジナルのTV-AnytimeのXMLスキーマで定義されるProgramInformation要素に対応する型であるProgramInformationType要素にはない。そのため、この例では、ProgramInformationType要素を拡張して、それにsipURI属性を新たに導入することでSIP-URIを格納できるようにする。
【０１１３】
このXMLスキーマの拡張を行うには、新たなXMLスキーマの名前空間、例えば、"urn:IPTV"を導入し、この名前空間のもとで、sipURI属性をTV-AnytimeのオリジナルのProgramInformationType要素の派生に導入する。
【０１１４】
図１５は、このsipURI属性導入の拡張のためのXMLスキーマのシンタクスの例である。このXMLスキーマの拡張のためのシンタクスには、オリジナルのTV-Anytimeメタデータを識別する名前空間２１、XMLスキーマを識別する名前空間２２、新しく定義するスキーマが"urn:IPTV"で識別されることの宣言２３、新しいXMLスキーマにおけるProgramInformationTypeの定義２４、拡張するオリジナルのTV-Anytimeの要素の指定２５、追加する属性であるsipURIの定義２６等が含まれている。
【０１１５】
図１６は、このsipURI属性を導入するXMLスキーマ拡張によりSIP-URIが格納されたTV-Anytimeメタデータの例を示す図である。
【０１１６】
このTV-Anytimeメタデータにおいて、ルート要素であるTVAMain要素５０の下にはProgramDescription要素５１が配置されている。ProgramDescription要素５１の下には、ProgramInformationTable要素５２が配置されている。このProgramInformationTable要素５２の中には、１つ以上のProgramInformation要素５４を配置できる。ProgramInformation要素５４はprogramId属性を持ち、ここにコンテンツを識別するIDであるCRIDが格納される。また、ProgramInformationTable要素５２の下には、BasicDescription要素５７が配置され、このBasicDescription要素５７の下には、コンテンツのタイトルを格納するTitle要素５６、その他、コンテンツのメタデータを格納する要素（図示せず）が配置されている。
【０１１７】
そして、このTV-Anytimeメタデータでは、ProgramInformation要素５４のxsi:type属性によるオーバーライドにより、上述のXMLスキーマ拡張で導入された名前空間"urn:IPTV"のProgramInformationType型を参照することにより、オリジナルのTV-AnytimeメタデータのProgramInformation要素が、このXMLスキーマ拡張で新たに導入されたsipURI属性を持つProgramInformation要素５４に置換されている。sipURI属性には、programId属性の値であるCRIDとコンテンツの配信元であるIPTVサーバ２０のDNS名とを用いて作成されたSIP-URIが格納される。
【０１１８】
図１７は、メタデータサーバ４０での図１６に示したTV-Anytimeメタデータの生成から、IPTVクライアント端末１０でのSIP-INVITEメッセージの生成までのシーケンスを示す図である。
【０１１９】
メタデータサーバ４０で図１６に示したTV-Anytimeメタデータを作成する場合の手順は次の通りである。メタデータサーバ４０は、まずProgramInformation要素５４のprogramId属性の値としてコンテンツを識別するCRIDである"crid://ca.com/123"を格納する。次に、メタデータサーバ４０は、上記のXMLスキーマ拡張により新たに導入されたsipURI属性の値として、CRIDである"crid://abc.com/123"から"crid://"を除き、"/"を"_"に置き換えて得た"ca.com_123"と、さらには、コンテンツの配信元であるIPTVサーバ２０のDNS名"as.sp.com"と"sip-uri:"と"@"とを用いて作成された"sip-uri:ca.com_123@as.sp.com"をSIP-URIとして格納する。なお、実際には、TV-Anytimeメタデータには、そのコンテンツを視聴するためのIPTVセッションの確立に必要なSDPも格納されるが、このSDPをTV-Anytimeメタデータに格納する方法については前述した通りであり、ここでは省略する。
【０１２０】
IPTVクライアント端末１０のEPGアプリケーション１４は、ネットワーク３を通じてメタデータサーバ４０に対してコンテンツのメタデータの取得要求を送信し、メタデータサーバ４０から、そのTV-Anytimeメタデータを取得する(ステップＳ３０３)。EPGアプリケーション１４は、取得したTV-AnytimeメタデータにおけるProgramInformationTable要素５２内の１以上のProgramInformation要素５４の内容をもとにコンテンツのタイトル等を含む、コンテンツの検索・選択用のインタフェース画面を作成して、ユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ３０４）。このインタフェース画面を用いてユーザ１によって所望のコンテンツのタイトルが選択されると、EPGアプリケーション１４は、そのタイトルをTitle要素５６の内容とするProgramInformation要素５４のprogramId属性の値を取り出す（ステップＳ３０５）。ここで、CRIDが"crid://ca.com/123"であるコンテンツが視聴対象として選択されたこととする。
【０１２１】
EPGアプリケーション１４は、このコンテンツの選択情報を受けて、TV-Anytimeメタデータから、programId属性の値が"crid://ca.com/123"であるProgramInformation要素５４のsipURI属性の値である"sip-uri:ca.com_123@as.sp.com"と、図示しないSDP要素に格納されたSDPの内容をIPTVクライアントアプリケーション１３に渡す（ステップＳ３０６）。
【０１２２】
IPTVクライアントアプリケーション１３は、EPGアプリケーション１４より渡された"sip-uri:ca.com_123@as.sp.com"を、SIP-INVITEメッセージの宛先にSIP-URIとして格納し、SDPをSIP-INVITEメッセージのボディ部に格納する。これによってSIP-INVITEメッセージが生成される（ステップＳ３０７）。IPTVクライアントアプリケーション１３は、この生成したSIP-INVITEメッセージをネットワーク３を通じてIMS-SIPサーバ３３へ送信する（ステップＳ３０８）。以後の動作は、第１の実施形態で図４を参照して説明したとおりである。
【０１２３】
以上説明したように、この実施形態によっても、IPTVクライアント端末１０にて、TV-Anytimeメタデータをもとに、SIP-INVITEメッセージの宛先に格納するSIP-URIを得ることができる。
【０１２４】
(第４の実施形態)
【０１２５】
以上の実施形態ではIPTVクライアント端末１０がIMS-SIPサーバ３３に対してセッションを確立するためのSIP-INVITEメッセージを直接送信する構成としたが、IMS-SIPサーバ３３に対してセッションを確立するためのSIP-INVITEメッセージを生成して送信する部分をIPTVクライアント端末１０から独立させて、セッション管理装置であるIMSゲートウェイとして構成してもよい。この場合、家庭内の機器は、１以上のIPTVクライアント端末とIMSゲートウェイとで構成され、これらをIPTVクライアントシステムと呼ぶこととする。
【０１２６】
図２２は、このようなIPTVクライアントシステムを採用したIPTVシステム１００の全体的な構成を示す図である。
【０１２７】
同図に示すように、このIPTVシステム１００は、コンテンツを視聴するユーザ１が持つIPTVクライアント端末１０Ａ、IPTVクライアント端末１０ＡとLAN（Local Area Network）などのホームネットワーク１８を通じて接続されたIMSゲートウェイ１１０、コンテンツを配信するIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０、及びこれらを接続可能なインターネットなどの広域なネットワーク３とで構成される。
【０１２８】
IPTVクライアント端末１０Ａは、第１の実施形態のIPTVクライアント端末１０の構成に、ホームネットワーク１８とのインタフェースをとるネットワークインタフェース１９を加えて構成される。その他の構成は、第１の実施形態のIPTVクライアント端末１０と同じである。
【０１２９】
IMSゲートウェイ１１０は、例えば、PC、セットップボックスなどとして提供される機器である。IMSゲートウェイ１１０は、IPTVクライアント端末１０Ａとホームネットワーク１８を通じて接続可能とされているとともに、広域なネットワーク３を通じてIPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０と接続可能とされている。IMSゲートウェイ１１０は、インスタンス選択基準設定部１１１、インスタンス選択基準データベース１１２、ネットワークインタフェース部１１３，１１４、SIMカード読込部１１５、セッション処理部１１６等を備える。
【０１３０】
インスタンス選択基準設定部１１１は、IPTVクライアント端末１０Ａのユーザ１に、コンテンツのインスタンスの選択基準を選択させ、その情報をインスタンス選択基準データベース１１２に登録する処理を行う部分である。ここで、コンテンツのインスタンスとは次のようなものである。IPTVサーバ２０には、同じタイトルのコンテンツであってもビットレートや符号化方式（コーデックの種類）の異なる複数のものが配信可能なコンテンツのデータの実体として用意されている場合がある。コンテンツのインスタンスとは、このようにビットレートや符号化方式などの違いにより実体が異なるコンテンツのデータのことを言う。一般的にビットレートが高いほどコンテンツの画質は高くなるが、それだけ家庭に割り当てられているネットワーク帯域を消費することになる。また、コーデックの種類によっても画質は変わる。たとえば、あるコーデックＡにより10Mbpsのビットレートで符号化されたコンテンツは、別のコーデックＢにより15Mbpsのビットレートで符号化されたコンテンツよりも画質が高いこともある。インスタンスの選択基準とは、このような事情を考慮してユーザの嗜好により選択される。その具体的な方法に関しては後で説明する。
【０１３１】
インスタンス選択基準データベース１１２は、IPTVクライアント端末１０Ａのユーザ１により選択されたインスタンス選択基準が格納されるデータベースである。
【０１３２】
ネットワークインタフェース部１１３は、ホームネットワーク１８とのインタフェースを提供する。ネットワークインタフェース部１１４は、広域なネットワーク３とのインタフェースを提供する。
【０１３３】
SIM（Subscriber Identity Module）読込部１１５は、IMSにおけるセッション確立のために行われるIPTVクライアントの認証に必要な情報（例えばユーザＩＤおよびパスワードなど）が記憶されたSIMカード１１７の着脱が可能とされ、装着されたSIMカード１１７に記憶された認証に必要な情報を読み込むモジュールである。
【０１３４】
セッション処理部１１６は、IPTVクライアント端末１０よりSIP-URIおよびSDPを含むセッション確立要求を受信したとき、このセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準をもとに各インスタンスの優先順位を決定し、この優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０１３５】
また、セッション処理部１１６は、SIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行い、認証に成功した場合にセッション確立のための処理を有効にする。
【０１３６】
IPTVサーバ２０、IMSプラットフォームを提供するサーバ群３０、メタデータサーバ４０の構成は第１の実施形態と同じである。
【０１３７】
次に、この第４の実施形態のIPTVシステム１００において、IPTVクライアント端末１０とIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を説明する。
【０１３８】
図２３は、この動作を示すシーケンス図である。IPTVクライアント端末１０においては、EPGアプリケーション１４が既に起動されているものとする。IPTVサーバ２０には、同じタイトルのコンテンツであってもビットレートや符号化方式の異なる複数のコンテンツのデータの実体がインスタンスとして用意されていることとする。
【０１３９】
まず、IPTVクライアント端末１０内のEPGアプリケーション１４からIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対して、IPTVクライアント端末１０のユーザ１により設定されたインスタンス選択基準を送信する（ステップＳ４０１）。IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する（ステップＳ４０２）。
【０１４０】
ここまでの動作は、より具体的には次のような手順で行われる。まず、IPTVクライアント端末１０内のEPGアプリケーション１４は、ホームネットワーク１８を通じて接続されているIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の設定要求を送信する。
【０１４１】
IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４からのインスタンス選択基準の設定要求を受信すると、インスタンス選択基準の設定画面情報をホームネットワーク１８を通じてIPTVクライアント端末１０内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０内のEPGアプリケーション１４は、このインスタンス選択基準の設定画面情報を受信すると、ユーザインタフェース部１１に備えられている表示部にインスタンス選択基準の設定画面を表示する。
【０１４２】
図２４は、このインスタンス選択基準の設定画面２０１の例を示す図である。これはコンテンツのインスタンス選択基準をユーザに選択させる場合の画面の例である。このインスタンス選択基準の設定画面２０１には、複数の嗜好設定項目２１０，２２０，２３０が設けられている。それぞれの嗜好設定項目２１０，２２０，２３０には、嗜好の種類を示す領域として「画質を優先しますか？」「価格を優先しますか？」といった質問文が配置された嗜好表示領域２１１，２２１，２３１と、それぞれの嗜好設定項目２１０，２２０，２３０の質問文に対するユーザの回答として「ＹＥＳ」または「ＮＯ」のいずれかを、インスタンス選択基準の設定画面２０１に設けられた例えばトグルスイッチなどのマウスクリック操作などによって択一的にユーザに選択させる嗜好選択領域２１２，２２２，２３２と、「ＹＥＳ」が選択された各嗜好設定項目に対して、インスタンス選択基準の設定画面２０１に設けられたプルダウンメニューのマウスクリック操作などにより優先度をユーザに指定させる優先度設定領域２１３，２２３，２３３とを備えている。たとえば、画質と価格についてユーザの嗜好を設定する場合には、上記の設定画面の「画質を優先しますか？」の嗜好表示領域２１１に対応する嗜好選択領域２１２で「ＹＥＳ」を選択するとともに、「価格を優先しますか？」の嗜好表示領域２２１に対応する嗜好選択領域２２２で「ＹＥＳ」を選択する。このように複数の嗜好設定項目２１０，２２０の嗜好選択領域２１２，２２２に対して「ＹＥＳ」が選択された場合には、これらの嗜好項目間での優先度を優先度設定領域２１３，２２３で指定する。図２４は画質の優先度を"１"、価格の優先度を"２"として、画質を価格よりも優先した場合の設定例を示している。なお、優先度設定領域２１３，２２３，２３３においては、複数の嗜好が選択された場合にこれらの嗜好に対して同じ優先度が指定できないように入力値の排他制御が行われる。
【０１４３】
IPTVクライアント端末１０のユーザによる、インスタンス選択基準の設定画面２０１への入力が完了した後、設定画面２０１に設けられたＯＫボタン２４１のマウスクリック操作が行われると、EPGアプリケーション１４は、その設定画面２０１への入力情報であるインスタンス選択基準を、ホームネットワーク１８を通じてIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に送信する（この動作がステップＳ４０１に相当）。
【０１４４】
IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０のEPGアプリケーション１４からインスタンス選択基準を受信すると、このインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する（この動作がステップＳ４０２に相当）。
【０１４５】
この後、IPTVクライアント端末１０のEPGアプリケーション１４は、コンテンツのメタデータの取得要求を広域なネットワーク３を通じてメタデータサーバ４０に送信し、メタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを応答として受信してメタデータ記憶部１５に格納する（ステップＳ４０３，Ｓ４０４）。
【０１４６】
EPGアプリケーション１４は、取得したTV-Anytimeメタデータをもとに、コンテンツの選択画面を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ４０５）。図２８はコンテンツの選択画面５００の例を示す図である。コンテンツの選択画面５００には、選択可能な各コンテンツのタイトル、概要、視聴価格などの文字情報５０１，５０２，５０３と、コンテンツの縮小画像５０４，５０５，５０６などが表示される。コンテンツの縮小画像５０４，５０５，５０６は、ユーザ１によるマウスクリック操作などによって選択されたとき、自身の縮小画像５０４，５０５，５０６に対応するコンテンツが選択されたというイベントの発生をEPGアプリケーション１４に通知する機能を有する。EPGアプリケーション１４はこの通知を受けてユーザ１により選択されたコンテンツを判別する。
【０１４７】
このコンテンツの選択画面５００でユーザ１によって視聴したいコンテンツが選択されると（ステップＳ４０６）、EPGアプリケーション１４は、その視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたTV-Anytimeメタデータから当該視聴対象のコンテンツの場所を指定するSIP-URIと、このコンテンツのインタンス毎のSDPを抽出する。ここで、インタンス毎のSDPにはビットレート、コーデック情報、価格情報などが含まれている。
【０１４８】
EPGアプリケーション１４は、TV-Anytimeメタデータから抽出した各インスタンスのSDPに含まれるコーデック情報を読み込み、IPTVクライアント端末１０内のコンテンツ再生部１７にて復号が可能なインスタンスのSDPを判定する（ステップＳ４０７）。この判定は、IPTVクライアント端末１０のシステムに実装されている符号化および復号のためのソフトウエアであるコーデックの種類を調べることによって行われる。
【０１４９】
続いて、EPGアプリケーション１４は、IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の取得要求を送信し、応答として取得したインスタンス選択基準と、コンテンツの各インスタンスのSDPをもとに、コンテンツのインスタンス間の優先順位を優先度として決定する（ステップＳ４０８）。そして、EPGアプリケーション１４は、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとのリストを含むセッション確立要求をホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信する（ステップＳ４０９）。
【０１５０】
図２５はIPTVクライアント端末１０のユーザ１によって画質を最優先するようにインスタンス選択基準が設定され、IPTVクライアント端末１０にはcodec-Aとcodec-Bの２種類のコーデックが実装されている場合のリスト３０１の例である。このリスト３０１には、コンテンツの場所を指定するSIP-URIと、優先度が付けられた３つのインスタンスａ，ｂ，ｃそれぞれのSDPとが含まれている。ここでは、codec-Aのコーデックはcodec-Bのコーデックよりビットレートが小さいが高画質であることから、コーデック情報が" codec-A "のインスタンスのSDPが、コーデック情報が" codec-Ｂ "のインスタンスのSDPよりも優先度が高く設定されている。
【０１５１】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０のEPGアプリケーション１４からのセッション確立要求を受信すると、このセッション確立要求に含まれる、優先度が付けられた各インスタンスのSDPをもとにセッション確立のためのネゴシエーションを行う（ステップＳ４１０）。このセッション確立のためのネゴシエーションは、たとえば、次のように行われる。
【０１５２】
まず、IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０のEPGアプリケーション１４より取得した各インスタンスのSDPの中で最も優先度が高いインスタンスのSDPを判断し、このSDPをボディ部に格納し、IPTVクライアント端末１０のEPGアプリケーション１４より取得したSIP-URIを宛先に格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを、広域なネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する。IMS-SIPサーバ３３は、IMSゲートウェイ１１０からのSIP-INVITEメッセージを受信すると、このSIP-INVITEメッセージからSIP-URIを抽出し、このSIP-URIを少なくとも含む、コンテンツのアクセス権の確認を依頼するメッセージをアクセス制御サーバ３１に送信する。アクセス制御サーバ３１は、このアクセス権確認依頼のメッセージに含まれるSIP-URIをもとに当該コンテンツのアクセス権の確認を行う。アクセス制御サーバ３１は、当該コンテンツのアクセス権を許諾することを判定した場合には、IMS-SIPサーバ３３にアクセス権許諾の応答メッセージを送信し、当該コンテンツのアクセス権を許諾しないことを判定した場合には、IMS-SIPサーバ３３にアクセス権非許諾の応答メッセージを送信する。以後、アクセス権が許諾された場合について説明を続ける。
【０１５３】
IMS-SIPサーバ３３は、アクセス権許諾の応答メッセージを受信すると、SIP-INVITEメッセージのボディ部からSDPを抽出し、このSDPを用いて、ネットワークリソースの確保を要求するメッセージを生成してネットワークリソース管理サーバ３２に送信する。ネットワークリソース管理サーバ３２はネットワークリソース確保要求のメッセージを受けると、これに含まれるSDPをもとに、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソース（ネットワーク帯域）の確保を試み、ネットワーク帯域の確保に成功したならば、IMS-SIPサーバ３３にネットワーク帯域の確保応答のメッセージを送信する。IMS-SIPサーバ３３は、ネットワーク帯域の確保応答のメッセージを受信すると、SIP-INVITEメッセージの宛先をもとに、SIP-INVITEメッセージをIPTVサーバ２０に送信するとともに、IMSゲートウェイ１１０にセッションの確立が成功したことを通知する。IMSゲートウェイ１１０は、セッションの確立が成功したことを知ると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０のIPTVクライアントアプリケーション１３に通知する（ステップＳ４１１）。
【０１５４】
また、ネットワークリソース管理サーバ３２は、コンテンツを視聴するためのIPTVセッションの確立に必要なネットワークリソースの確保に失敗した場合には、IMSゲートウェイ１１０にセッションの確立に失敗したことを通知する。IMSゲートウェイ１１０は、このセッションの確立に失敗したことの通知を受信すると、IPTVクライアント端末１０のEPGアプリケーション１４より取得した各インスタンスのSDPのリストの中で次に優先度が高いインスタンスのSDPを判断し、前回と同様に、このSDPをボディ部に格納し、IPTVクライアント端末１０のEPGアプリケーション１４より取得したSIP-URIを宛先に格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを、帯域ネットワーク３を通じて、IMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信する。以後の動作は前回の処理と同じである。IMSゲートウェイ１１０は、セッションの確立に成功したことの通知を受信するか、または、SIP-INVITEメッセージのボディ部に格納すべきSDPがなくなるまで、上記の処理を繰り返す。
【０１５５】
セッションの確立に成功した場合の説明に戻る。
IPTVサーバ２０は、IMS-SIPサーバ３３よりIMS-INVITEメッセージを受信すると、コンテンツを視聴するためのIPTVセッションを確立するために必要なネットワーク帯域を確保し、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間で確立されたセッションを用いて、コンテンツのデータを送信する。IPTVクライアント端末１０のIPTVクライアントアプリケーション１３は、IPTVサーバ２０との間に確立されたセッションを通じてコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ４１２）。
【０１５６】
以上説明したように、本実施形態では、IPTVクライアント端末１０のEPGアプリケーション１４からIMSゲートウェイ１１０に対してセッション確立要求を行うとき、視聴対象として選択されたコンテンツの場所を指定するSIP-URIとともに、優先度が付けられた各インスタンスのSDPをIMSゲートウェイ１１０に送信することによって、IMSゲートウェイ１１０は各インスタンスの優先度を考慮しつつセッション確立のためのネゴシエーションを行うことができる。
【０１５７】
(第４の実施形態の変形例１)
図２６は、第４の実施形態の変形例１である動作を示すフローチャートである。
【０１５８】
第４の実施形態では、予めIMSゲートウェイ１１０のインスタンス選択基準データベース１１２に登録されたインスタンス選択基準と、ユーザ１により視聴対象として選択されたコンテンツの各インスタンスのSDPとをもとにIPTVクライアント端末１０が各インスタンスに優先度を自動的に付けることとした。変形例では、ステップＳ４０８ａで、IPTVクライアント端末１０がユーザインタフェース部１１に備えられている表示部を通じて優先度選択画面をユーザ１に呈示し、クライアント端末１０のユーザ１０に各インスタンスの優先度をマニュアルで付けさせることとしている。
【０１５９】
図２７は、この優先度選択画面４００とユーザ１による各インスタンスの優先度の選択例を示す図である。この優先度選択画面４００には、ユーザ１により視聴対象として選択されたコンテンツの識別番号、タイトル、概要など、コンテンツに関する情報４０１と、当該コンテンツのインスタンス毎の画質、ビットレートなどが表示された画質情報表示領域４０２，４０３，４０４と、当該コンテンツのインスタンス毎の優先度をユーザ１に選択させるための優先度選択領域４０５，４０６，４０７などが設けられている。ユーザ１は、各インスタンスの画質情報表示領域４０２，４０３，４０４を参照しつつ各インスタンスの優先度を優先度選択領域４０５，４０６，４０７に入力する。これにより、IPTVクライアント端末１０はIMSゲートウェイ１１０のインスタンス選択基準データベース１１２に登録されたインスタンス選択基準に拠らず、各インスタンスの優先度の情報を取得して、各インスタンスに優先度を自動的に付けることができる。その他の動作は第４の実施形態と同じである。
【０１６０】
(第４の実施形態の変形例２)
図２９は、第４の実施形態の変形例２である動作を示すフローチャートである。
【０１６１】
第４の実施形態では、インスタンス選択基準をIMSゲートウェイ１１０内のインスタンス選択基準データベース１１２で管理することとしたが、IPTVサーバ２０で管理するようにしてもよい。この場合、IPTVクライアント端末１０は、広域なネットワーク３を通じてIPTVサーバ２０に対してインスタンス選択基準の設定要求を送信する。IPTVサーバ２０は、IPTVクライアント端末１０内のEPGアプリケーション１４からのインスタンス選択基準の設定要求を受信すると、その設定画面の情報を広域なネットワーク３を通じてIPTVクライアント端末１０内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示し、ユーザにインスタンス選択基準を入力させた後、広域なネットワーク３を通じてIPTVサーバ２０に送信する（この動作がステップＳ４０１ｂに相当）。
【０１６２】
IPTVサーバ２０は、IPTVクライアント端末１０のEPGアプリケーション１４からのインスタンス選択基準を受信すると、この情報を図示しないインスタンス選択基準データベースへ登録する（この動作がステップＳ４０２ｂに相当）。
【０１６３】
IPTVクライアント端末１０のEPGアプリケーション１４は、ステップＳ４０８ｂでコンテンツのSDPとインスタンス選択基準をもとに各コンテンツのインスタンスに優先度を付けるために、広域なネットワーク３を通じてIPTVサーバ２０にインスタンス選択基準の取得要求を送信してインスタンス選択基準を応答として取得する。その他の動作は第４の実施形態と同じである。
【０１６４】
(第５の実施形態)
【０１６５】
上記の第４の実施形態では、IMSゲートウェイ１１０とIPTVクライアント端末１０Ａとがホームネットワーク１８を介して１対１で接続されているものとしたが、IMSゲートウェイ１１０に対して、１つの家庭内の複数のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を介して接続されていてもよい。
【０１６６】
図３０は、このような構成を採用したIPTVシステム１００の全体的な構成を示す図である。IPTVクライアント端末１０Ａ，１０Ｂの構成、IMSゲートウェイ１１０の構成は、第４の実施形態と同じである。
【０１６７】
このIPTVシステム１００では、いずれかのIPTVクライアント端末（１０Ａまたは１０Ｂ）がインスタンス選択基準を設定し、IMSゲートウェイ１１０に送信してインスタンス選択基準データベース１１２に登録する。このインスタンス選択基準データベース１１２に登録されたインスタンス選択基準は、各IPTVクライアント端末１０Ａ，１０Ｂが視聴対象のコンテンツの各インタンスのSDPに対して優先度を付ける際にアクセスされる。これにより、家庭内に複数のIPTVクライアント端末１０Ａ，１０Ｂが設置された環境においても、インスタンス選択基準を選択する操作は一回で済むことになる。
【０１６８】
また、IMSゲートウェイ１１０に、IPTVクライアントの認証に必要な情報が記録されたSIMカード１１７を読み込むSIM読込部１１５を設け、このSIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行うことによって、複数のIPTVクライアント端末１０Ａ，１０ＢそれぞれにSIM読込部を設ける必要がなくなる。
【０１６９】
なお、図２８では、２機のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を通じてIMSゲートウェイ１１０と接続されている場合を示したが、３機以上のIPTVクライアント端末が接続されている場合も動作は同様である。
【０１７０】
(第６の実施形態)
【０１７１】
IMSゲートウェイ１１０に対して複数のIPTVクライアント端末１０Ａ，１０Ｂがホームネットワーク１８を介して接続されている場合、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求がIMSゲートウェイ１１０に送信されたときには、どのIPTVクライアント端末からのセッション確立要求に対して優先してセッションの確立のためのネゴシエーションを行うかという競合解決処理をIMSゲートウェイ１１０にて行う。
【０１７２】
図３１は、このような競合解決処理を採用したIPTVシステム１００の全体的な構成を示す図である。IPTVクライアント端末１０Ａ，１０Ｂの構成はEPGアプリケーション１４の一部の処理内容が異なるだけで、その他の部分は第１の実施形態と同様である。IMSゲートウェイ１１０は、第１の実施形態に示した構成に、デバイス／ユーザ優先度データベース１１９とデバイス／ユーザ優先度設定部１２０とが付加されたものである。
【０１７３】
デバイス／ユーザ優先度データベース１１９は、セッション確立のためのネゴシエーションを行う際のデバイス間の優先順位を示す優先度と、IPTVクライアント端末のユーザ間の優先順位を示す優先度が格納されるデータベースである。
【０１７４】
デバイス／ユーザ優先度設定部１２０は、特定のIPTVクライアント端末（この例ではIPTVクライアント端末１０Ａ）のユーザ１に、デバイス間の優先度またはユーザ間の優先度を選択させ、その情報をデバイス／ユーザ優先度データベース１１９に登録する処理を行う部分である。デバイス間の優先度またはユーザ間の優先度をまとめて「デバイス／ユーザ優先度」と表記する。
【０１７５】
セッション処理部１１６は、複数のIPTVクライアント端末１０Ａ，１０ＢよりデバイスＩＤ、ユーザＩＤ、SIP-URIおよびSDPを含むセッション確立要求を受信したとき、これらのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとに、各IPTVクライアント端末１０Ａ，１０Ｂからのセッション確立要求間の競合解決を行う。また、セッション処理部１１６は、競合解決によって優先度が高いと判定されたセッション確立要求から順に、第４の実施形態と同様に、そのセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準とをもとにインスタンス間の優先順位を決定し、優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０１７６】
また、セッション処理部１１６は、SIM読込部１１５によってSIMカード１１７から読み込まれた認証に必要な情報をもとにIPTVクライアントの認証処理を行い、認証に成功した場合にセッション確立のための処理を有効にする。
【０１７７】
図３２は、この第６の実施形態のIPTVシステム１００において、IPTVクライアント端末１０Ａ，１０ＢとIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。
【０１７８】
まず、IPTVクライアント端末１０ＡのEPGアプリケーション１４からIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に対して、IPTVクライアント端末１０Ａのユーザ１により設定されたユーザ／デバイス優先度を送信する（ステップＳ５０１Ａ）。IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたユーザ／デバイス優先度をデバイス／ユーザ優先度データベース１１９へ登録する（ステップＳ５０２）。
【０１７９】
ここまでの動作は、より具体的には次のような手順で行われる。まず、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、ホームネットワーク１８を通じて接続されているIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に対してデバイス／ユーザ優先度の設定要求を送信する。
【０１８０】
IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４からのデバイス／ユーザ優先度の設定要求を受信すると、その設定画面の情報をホームネットワーク１８を通じてIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示する。
【０１８１】
図３３は、このデバイス／ユーザ優先度を設定するための画面の構成を示す図である。まず、IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、初期画面としてデバイス／ユーザ優先度設定画面６００を作成し、これをIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に送信して表示部に表示させる。このデバイス／ユーザ優先度設定画面６００には、競合解決をデバイス間の優先度をもとに行うか、ユーザ間の優先度をもとに行うかを択一的に指定するための２つのボタン６１１，６１２が設けられている。
【０１８２】
２つのボタン６１１，６１２のうち、競合解決をデバイス間の優先度をもとに行うボタン６１１が例えばマウスクリック操作などによって選択されると、デバイス間の優先度を設定するためのデバイス優先度設定画面６０２が現れる。このデバイス優先度設定画面６０２には、各デバイスの優先度を例えばプルダウンメニューに対するマウスクリック操作などにより選択するためのデバイス優先度設定領域６２１，６２２が設けられている。ここで、デバイスとはIPTVのクライアントとしてサービスを利用できるように予め登録されたIPTVクライアント端末である。それぞれのデバイスはデバイス固有のデバイスＩＤによって識別される。IPTVのクライアントとしてサービスを利用する際に、EPGアプリケーション１４はそのデバイスＩＤを使ってサービスを利用する。デバイス優先度設定領域６２１，６２２への各デバイスの優先度の選択後、デバイス優先度設定画面６０２に設けられたＯＫボタン６２３のマウスクリック操作が行われると、EPGアプリケーション１４は、そのデバイス優先度設定画面６０２への入力情報であるデバイス間の優先度をホームネットワーク１８を通じてIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に送信する（この動作がステップＳ５０１Ａに相当）。
【０１８３】
また、２つのボタン６１１，６１２のうち、競合解決をユーザ間の優先度をもとに行うボタン６１２が例えばマウスクリック操作などによって選択されると、ユーザ間の優先度を設定するためのユーザ優先度設定画面６０３が現れる。このユーザ優先度設定画面６０３には、各ユーザの優先度を例えばプルダウンメニューに対するマウスクリック操作などにより選択するためのユーザ優先度設定領域６３１，６３２が設けられている。ここで、ユーザとはIPTVのクライアントとしてサービスを利用できるように予め登録されたユーザであり、それぞれのユーザはユーザ固有のユーザＩＤによって識別される。IPTVのクライアントとしてサービスを利用する際にユーザは自分のユーザＩＤを入力することで、EPGアプリケーション１４はそのユーザＩＤを使ってサービスを利用する。ユーザ優先度設定領域６３１，６３２への各ユーザの優先度の選択後、ユーザ優先度設定画面６０３に設けられたＯＫボタン６３３のマウスクリック操作が行われると、EPGアプリケーション１４は、そのユーザ優先度設定画面６０３への入力情報である各ユーザの優先度をホームネットワーク１８を通じてIMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０に送信する（この動作がステップＳ５０１Ａに相当）。
【０１８４】
IMSゲートウェイ１１０内のデバイス／ユーザ優先度設定部１２０は、IPTVクライアント端末１０内のEPGアプリケーション１４からデバイス／ユーザ優先度を受信すると、これをデバイス／ユーザ優先度データベース１１９へ登録する（この動作がステップＳ５０２に相当）。
【０１８５】
次に、各IPTVクライアント端末１０Ａ，１０Ｂ内のEPGアプリケーション１４はIMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対して、IPTVクライアント端末１０のユーザ１により設定されたインスタンス選択基準を送信する（ステップＳ５０３Ａ，５０３Ｂ）。IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１は、IPTVクライアント端末１０内のEPGアプリケーション１４から送信されたインスタンス選択基準をインスタンス選択基準データベース１１２へ登録する。このときの処理の詳細は第４の実施形態で説明した通りである。
【０１８６】
この後、各IPTVクライアント端末１０Ａ，１０ＢのEPGアプリケーション１４はそれぞれ、コンテンツのメタデータの取得要求を広域なネットワーク３を通じてメタデータサーバ４０に送信し、メタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを応答として受信してメタデータ記憶部１５に格納する（ステップＳ５０４Ａ，Ｓ５０４Ｂ）。
【０１８７】
この後、各IPTVクライアント端末１０Ａ，１０Ｂにおいて、EPGアプリケーション１４は、TV-Anytimeメタデータをもとに、コンテンツの選択画面５００（図２８）を作成してユーザインタフェース部１１を通じてユーザ１に呈示する（ステップＳ５０５Ａ，Ｓ５０５Ｂ）。
【０１８８】
このコンテンツの選択画面５００でユーザ１によって視聴したいコンテンツが選択されると（ステップＳ５０６Ａ，Ｓ５０６Ｂ）、EPGアプリケーション１４は、その視聴対象として選択されたコンテンツを判断し、メタデータ記憶部１５に記憶されたTV-Anytimeメタデータから当該視聴対象コンテンツの場所を指定するSIP-URIと、このコンテンツのインタンス毎のSDPを抽出する。
【０１８９】
EPGアプリケーション１４は、TV-Anytimeメタデータから抽出した各インスタンスのSDPに含まれるコーデック情報を読み込み、IPTVクライアント端末１０Ａ，１０Ｂ内のコンテンツ再生部１７にて復号が可能なインスタンスのSDPを判定する（ステップＳ５０７Ａ，Ｓ５０７Ｂ）。
【０１９０】
続いて、EPGアプリケーション１４は、IMSゲートウェイ１１０内のインスタンス選択基準設定部１１１に対してインスタンス選択基準の取得要求を送信し、応答として取得したインスタンス選択基準と、コンテンツの各インスタンスのSDPをもとに、コンテンツのインスタンス間の優先順位を優先度として決定する（ステップＳ５０８Ａ，Ｓ５０８Ｂ）。そして、EPGアプリケーション１４は、デバイスＩＤまたはユーザＩＤと、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとを含むセッション確立要求をホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信する（ステップＳ５０９Ａ，Ｓ５０９Ｂ）。
【０１９１】
ここで、IMSゲートウェイ１１０内のセッション処理部１１６は、２つのIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求が受信したことによって競合の発生を検知し、それぞれのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとに、各IPTVクライアント端末１０Ａ，１０Ｂからのセッション確立要求間の競合解決を行う（ステップＳ５１０）。次に、この競合解決の具体例を説明する。
【０１９２】
図３４は、２つのIPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のセッション処理部１１６にそれぞれ送信された２つのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPの例を示す図である。７００ＡはIPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）から送信されたセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDP、７００ＡはIPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）から送信されたセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPである。
【０１９３】
ここで、２つのIPTVクライアント端末１０Ａ，１０ＢとIMSゲートウェイ１１０が設置されている家庭に割り当てられているネットワーク帯域が15Mbpsとする。また、ここではユーザの優先度に基づいて競合解決が行われることとし、優先度はd2がd1より高いものとする。この場合、セッション処理部１１６は最初に、ユーザ優先度が高いIPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）が依頼する優先度1のインスタンスに対するセッションを確立するためのネゴシエーションを行う（ステップＳ５１１）。このセッションの確立によりネットワーク帯域は8 Mbps消費されるので残りは7Mbpsである。そこで次に、セッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）が依頼するセッションを確立するために、IPTVクライアント端末１０Ａから受信したセッション確立要求に含まれる各インスタンスのSDPを優先度の高いインスタンスから順に参照し、ビットレートが7Mbps以下のインスタンスを検出する。この結果、IPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）が依頼する優先度１のインスタンスのビットレートは10Mbpsであることからこれを無効とし、ビットレートが5Mbpsである優先度２のインスタンスに対するセッションを確立するためのネゴシエーションを行う（ステップＳ５１１）。
【０１９４】
ここでは、ユーザの優先度に従って競合解決が行われる場合を例示したが、デバイスの優先度に従って競合解決が行われる場合も同様である。
【０１９５】
セッションを確立するためのネゴシエーションを含む以後の動作は第４の実施形態と同様である。IMSゲートウェイ１１０内のセッション処理部１１６は、IMS-SIPサーバ３３よりセッションの確立が成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をそれぞれのIPTVクライアント端末１０Ａ，１０ＢのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１２）。各IPTVクライアント端末１０Ａ，１０Ｂ内のIPTVクライアントアプリケーション１３はそれぞれ、IMSゲートウェイ１１０内のセッション処理部１１６からセッション確立が成功したことの通知を受信すると、このセッションを通じてIPTVサーバ２０からコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ａ，５１３Ｂ）。
【０１９６】
以上説明したように、本実施形態では、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時に発生したセッション確立要求に対して、IMSゲートウェイ１１０がデバイス間の優先度またはユーザ間の優先度に基づいて、順次適切なセッションを確立することができる。
【０１９７】
なお、この実施形態では、複数のIPTVクライアント端末１０Ａ，１０Ｂから同時にセッション確立要求が発生した場合について説明したが、既に、あるIPTVクライアント端末から依頼されたセッションが確立されているときに、別のIPTVクライアント端末からのセッション確立要求が発生した場合、IMSゲートウェイ１１０内のセッション処理部１１６は、その新たに発生したセッションの確立要求の中で優先度の高いインスタンスから順にそのインスタンスのビットレートが、家庭に割り当てられているネットワーク帯域から既に消費されているネットワーク帯域を差し引いた残りのネットワーク帯域以下のものを検出し、このインスタンスに対するセッションを確立するためのネゴシエーションを行う。
【０１９８】
(第６の実施形態の変形例１)
図３８は、第６の実施形態の変形例１の動作を示すフローチャートである。
【０１９９】
第６の実施形態では、デバイス／ユーザ優先度をIMSゲートウェイ１１０で管理することとしたが、IPTVサーバ２０で管理するようにしてもよい。この場合、IPTVクライアント端末１０Ａは、広域なネットワーク３を通じてIPTVサーバ２０に対してデバイス／ユーザ優先度の設定要求を送信する。
【０２００】
IPTVサーバ２０は、IPTVクライアント端末１０Ａ内のEPGアプリケーション１４からのデバイス／ユーザ優先度の設定要求を受信すると、その設定画面の情報を広域なネットワーク３を通じてIPTVクライアント端末１０Ａ内のEPGアプリケーション１４に応答する。IPTVクライアント端末１０Ａ内のEPGアプリケーション１４は、この設定画面の情報を受信すると、ユーザインタフェース部１１に備えられている表示部に設定画面を表示し、ユーザ１にデバイス／ユーザ優先度を入力させた後、広域なネットワーク３を通じてを通じてIPTVサーバ２０に送信する（この動作がステップＳ５０１Ａｂに相当）。
【０２０１】
IPTVサーバ２０は、IPTVクライアント端末１０のEPGアプリケーション１４からのデバイス／ユーザ優先度を受信すると、この情報を図示しないインスタンス選択基準データベースへ登録する（この動作がステップＳ５０２ｂに相当）。
【０２０２】
IMSゲートウェイ１１０内のセッション処理部１１６は、競合を解決するために、広域なネットワーク３を通じてIPTVサーバ２０にデバイス／ユーザ優先度の取得要求を送信してデバイス／ユーザ優先度を応答として取得する。
【０２０３】
なお、各IPTVクライアント端末１０Ａ，１０Ｂで作成されたインスタンス選択基準についてもIPTVサーバ２０にて管理するようにしてもよい。
【０２０４】
(第７の実施形態)
【０２０５】
あるIPTVクライアント端末のユーザから依頼されたセッションが確立されているときに、そのIPTVクライアント端末またはそのユーザよりデバイス／ユーザ優先度が高い別のIPTVクライアント端末またはユーザからセッション確立要求が発生した場合には、後から依頼されたセッションを優先するために、既に確立されているセッションをより低画質のセッションに変更するようにしてもよい。この方式を採用した第７の実施形態を説明する。
【０２０６】
図３５および図３６は、この第７の実施形態のIPTVシステム１００において、IPTVクライアント端末１０Ａ，１０ＢとIPTVサーバ２０との間でIPTVセッションが確立されるまでの動作を示すシーケンス図である。なお、第７の実施形態のIPTVシステム１００の構成は図３１に示した第６の実施形態と同じであるが、IMSゲートウェイ１１０内のセッション処理部１１６の処理が異なる。
【０２０７】
まず、ステップＳ５０１ＡからステップＳ５０３Ａ，Ｓ５０３Ｂで、IPTVクライアント端末１０ＡからIMSゲートウェイ１１０内のデバイス／ユーザ優先度データベース１１９へのデバイス／ユーザ優先度の登録と、各IPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のインスタンス選択基準データベース１１２へのインスタンス選択基準の登録が第６の実施形態と同様に行われる。
【０２０８】
この後、IPTVクライアント端末１０ＡのEPGアプリケーション１４がメタデータサーバ４０よりコンテンツのTV-Anytimeメタデータを取得するステップＳ５０４Ａから、IPTVクライアント端末１０ＡのEPGアプリケーション１４が、デバイスＩＤまたはユーザＩＤと、視聴対象として選択されたコンテンツの場所を指定するSIP-URIと、優先度が付けられた各インスタンスのSDPとを含むセッション確立要求を、ホームネットワーク１８を通じてIMSゲートウェイ１１０内のセッション処理部１１６に送信するステップＳ５０９Ａまでの動作も第６の実施形態と同様である。
【０２０９】
ここではIPTVクライアント端末１０ＡのEPGアプリケーション１４だけからセッション確立要求が送信されたことから、IMSゲートウェイ１１０内のセッション処理部１１６は、第４の実施形態と同様に、そのセッション確立要求に含まれる各インスタンスのSDPとインスタンス選択基準データベース１１２に格納されたインスタンス選択基準とをもとに各インスタンスの優先順位を決定し、優先順位の高いインスタンスから順に、SIP-URIとそのインスタンスのSDPを格納したSIP-INVITEメッセージを生成し、このSIP-INVITEメッセージを広域なネットワーク３を通じてIMSプラットフォームを提供するサーバ群３０におけるIMS-SIPサーバ３３に送信してセッション確立のためネゴシエーションを行う。
【０２１０】
IMSゲートウェイ１１０は、IMS-SIPサーバ３３よりセッションの確立が成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１２）。この後、IPTVクライアント端末１０Ａ内のIPTVクライアントアプリケーション１３は、IPTVサーバ２０との間に確立されたセッションを通じてコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ａ）。
【０２１１】
IPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３とIPTVサーバ２０との間にセッションが確立されているとき、IPTVクライアント端末１０ＢのEPGアプリケーション１４が、同様にステップＳ５０４ＢのTV-Anytimeメタデータの取得から、ステップＳ５０９Ｂのセッション確立要求の送信までを行ったこととする。
【０２１２】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０ＢのEPGアプリケーション１４からのセッション確立要求を受信すると競合の発生を検知し、IPTVクライアント端末１０Ａから既に受信しているセッション確立要求とIPTVクライアント端末１０Ｂから受信したセッション確立要求のそれぞれに含まれるデバイスＩＤまたはユーザＩＤとデバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度とをもとにセッション確立要求間の競合解決を行う（ステップＳ５１４）。次に、この競合解決の具体例を説明する。
【０２１３】
この競合解決の具体例を説明するために、再び図３４の２つのIPTVクライアント端末１０Ａ，１０ＢからIMSゲートウェイ１１０内のセッション処理部１１６にそれぞれ送信された２つのセッション確立要求に含まれるデバイスＩＤまたはユーザＩＤ、SIP-URI、優先度が付けられた各インスタンスのSDPの例を採用する。ここで、２つのIPTVクライアント端末１０Ａ，１０ＢとIMSゲートウェイ１１０が設置されている家庭に割り当てられているネットワーク帯域が15Mbpsとする。また、ここではユーザの優先度に従って競合解決が行われることとし、優先度はd2がd1より高いものとする。さらに、IPTVクライアント端末１０Ｂからのセッション確立要求が発生する以前に、IPTVクライアント端末１０Aからのセッション確立要求に含まれる優先度1のインスタンスに対するセッションが既に確立されているものとする。したがって、ネットワーク帯域は既に10Mbps消費されているので残りは5Mbpsである。
【０２１４】
セッション処理部１１６は、まず、２つのセッション確立要求それぞれに含まれるユーザＩＤをもとに、どちらのIPTVクライアント端末のユーザのユーザ優先度が高いかを判定する。図３４の例では、IPTVクライアント端末１０Ｂ（デバイスＩＤ＝d2）のユーザ（ユーザＩＤ＝u2）のユーザの方がIPTVクライアント端末１０Ａ（デバイスＩＤ＝d1）のユーザ（ユーザＩＤ＝u1）のユーザよりもユーザ優先度が高いことを判定する。そこでセッション処理部１１６は、IPTVクライアント端末１０Ｂからのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスに対するセッションを確立するようにネゴシエーションを行う（ステップＳ５１５）。
【０２１５】
このネゴシエーションにおいて、IPTVクライアント端末１０Ｂからのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスのビットレートは8Mbpsであるのに対し、家庭に割り当てられているネットワーク帯域の残りは現在5Mbpsであるため、このままでは3Mbps分の不足が生じる。そこでセッション処理部１１６は、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスのSDPを参照して、現在セッションが確立されているインスタンスよりもビットレートの低いインスタンスのビットレートを確認して、このビットレートが7Mbps以下ならば、このインスタンスに対するセッションへの変更を行うようにセッション確立のための処理を行う。図３４の例では、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスの中で優先度が２番目に高いインスタンスのビットレートは5Mbpsであることから、このインスタンスに対するセッションへの変更が行われる。そして、セッション処理部１１６は、このセッションへの変更要求をIPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３に送信する（ステップＳ５１６）。なお、ビットレートが7Mbps以下のインスタンスがIPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスの中に無い場合には、現在確立されているIPTVクライアント端末１０Ａからのセッション確立要求に対するセッションを解放する処理のみが行われる。
【０２１６】
IPTVクライアント端末１０ＡのIPTVクライアントアプリケーション１３は、IMSゲートウェイ１１０内のセッション処理部１１６からのセッションの変更要求を受信すると、この変更要求に従って低画質なインスタンスに対するセッションへの変更を行い、IPTVサーバ２０からのコンテンツのデータの受信を続ける（ステップＳ５１７Ｂ）。
【０２１７】
一方、IMSゲートウェイ１１０内のセッション処理部１１６は、IMS-SIPサーバ３３より、IPTVクライアント端末１０Ｂからのセッション確立要求に対してセッションの確立に成功したことの通知を受けると、ホームネットワーク１８を通じてその旨をIPTVクライアント端末１０ＢのIPTVクライアントアプリケーション１３に通知する（ステップＳ５１８）。IPTVクライアント端末内のIPTVクライアントアプリケーション１３は、IMSゲートウェイ１１０内のセッション処理部１１６からセッション確立が成功したことの通知を受信すると、このセッションを通じてIPTVサーバ２０からコンテンツのデータを受信し、コンテンツ再生部１７への供給、あるいはコンテンツ記憶部１６への蓄積を行う（ステップＳ５１３Ｂ）。
【０２１８】
ここでは、ユーザの優先度に従って競合解決が行われる場合を例示したが、デバイスの優先度に従って競合解決が行われる場合も同様である。
【０２１９】
以上説明したように、本実施形態では、あるIPTVクライアント端末のユーザから依頼されたセッションが確立されているときに、そのIPTVクライアント端末またはそのユーザよりデバイス／ユーザ優先度が高い別のIPTVクライアント端末のユーザからセッション確立要求が発生した場合には、既に確立されているセッションを低画質のものに変更してでも、後から依頼されたセッションの確立を優先する。これにより、デバイス／ユーザ優先度を重視して適切にセッションを確立することができる。
【０２２０】
（第７の実施形態の変形例１）
【０２２１】
第７の実施形態では、デバイス／ユーザ優先度データベース１１９に登録されたデバイス／ユーザ優先度をもとに、必要ならば既に確立されているセッションに割り当てられたネットワーク帯域を修正することとしたが、デバイス／ユーザ優先度に拠らず、後から別のIPTVクライアント端末からのセッション確立要求が発生しならば、そのセッション確立要求に対するセッションの確立を許可するかどうかを、既にセッションが確立されているIPTVクライアント端末のユーザに呈示してユーザに指定させるようにしてもよい。
【０２２２】
図３７は、この処理のフローチャートである。IPTVクライアント端末１０Ａ（デバイス１）から依頼されたセッションが確立されているときに、IPTVクライアント端末１０Ｂ（デバイス２）よりセッション確立要求が発生した場合に、IPTVクライアント端末１０Ａ（デバイス１）の表示部を通して、そのIPTVクライアント端末１０Ｂ（デバイス２）のセッション確立要求を許可するかどうかをユーザ１に質問する（ステップＳ６０１）。この質問に対してユーザ１から許可する通知が入力されると、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からIMSゲートウェイ１１０内のセッション処理部１１６にセッション確立要求を許可する通知が送信される。
【０２２３】
IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からセッション確立要求を許可する通知を受信すると、IPTVクライアント端末１０Ｂ（デバイス２）からのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスに対するセッションを確立するようにネゴシエーションを行う。また、セッション処理部１１６は、IPTVクライアント端末１０Ａからのセッション確立要求に含まれる各インスタンスのSDPを参照して、現在セッションが確立されているインスタンスよりもビットレートの低いインスタンスのビットレートを確認し、このビットレートと、IPTVクライアント端末１０Ｂ（デバイス２）からのセッション確立要求に含まれる各インスタンスの中で優先度が最も高いインスタンスのビットレートとの合計が家庭に割り当てられているネットワーク帯域以下ならば、このインスタンスに対するセッションに変更するように処理を行う（ステップＳ６０２）。
【０２２４】
また、IMSゲートウェイ１１０内のセッション処理部１１６は、IPTVクライアント端末１０Ａ（デバイス１）内のEPGアプリケーション１４からセッション確立要求を許可しない通知を受信した場合には、IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４に対してその旨を通知する。IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４は、この通知を受信すると、表示部を通して、セッション確立許可が下りなかったことをユーザ１に呈示する（ステップＳ６０３）。この後、IMSゲートウェイ１１０内のセッション処理部１１６は、現在確立されているセッションを維持し、IPTVクライアント端末１０Ｂ（デバイス２）のEPGアプリケーション１４からのセッション確立要求を却下する（ステップＳ６０４）。
【０２２５】
本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々更新を加え得ることは勿論である。
【符号の説明】
【０２２６】
３ ネットワーク
１０ IPTVクライアント端末
１３ IPTVクライアントアプリケーション
１４ EPGアプリケーション
１５ メタデータ記憶部
２０ IPTVサーバ
３１ アクセス制御サーバ
３２ ネットワークリソース管理サーバ
３３ IMS-SIPサーバ
４０ メタデータサーバ
５２ ProgramInformationTable要素
５３ ProgramLocationTable要素
５４ ProgramInformation要素
５５ OnDemandProgram要素
５６ Title要素
５７ BasicDescription要素
５９ programURL要素
６０ InstanceDescription要素
６１ Program要素
６２ SDP要素
８４ AVAttributes要素
８５ transportQuality要素
８６ Coding要素
８７ VideoAttributes要素
９１ ServiceInformationTable要素
９２ ServiceInformation要素
９３ OnDemandService要素
９５ ServiceURL要素
１００ IPTVシステム
【特許請求の範囲】
【請求項１】
コンテンツの視聴のために当該コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得するメタデータ取得部と、
前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、
前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するメッセージ送信部と
を具備するクライアント端末。
【請求項２】
請求項１に記載のクライアント端末であって、
前記セッションを確立するために必要な情報がQoS（Quality of Service）の制御のための情報を含む
クライアント端末。
【請求項３】
請求項１に記載のクライアント端末であって、
前記クライアント端末が携帯機器である
クライアント端末。
【請求項４】
コンテンツを受信するためのセッションを確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得し、
前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、
前記生成されたメッセージを、前記セッションの制御を行うサーバに送信する
コンテンツ受信方法。
【請求項５】
コンテンツの視聴のために前記コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得することが可能なクライアント端末より、前記コンテンツを識別するためのコンテンツ識別子および前記セッションを確立するために必要な情報を含むセッション確立要求を受信し、前記コンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記セッションの制御を行うことが可能なサーバに送信するセッション処理部
を具備するセッション管理装置。
【請求項１】
コンテンツの視聴のために当該コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得するメタデータ取得部と、
前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成するメッセージ生成部と、
前記生成されたメッセージを、前記セッションの制御を行うサーバに送信するメッセージ送信部と
を具備するクライアント端末。
【請求項２】
請求項１に記載のクライアント端末であって、
前記セッションを確立するために必要な情報がQoS（Quality of Service）の制御のための情報を含む
クライアント端末。
【請求項３】
請求項１に記載のクライアント端末であって、
前記クライアント端末が携帯機器である
クライアント端末。
【請求項４】
コンテンツを受信するためのセッションを確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得し、
前記取得したメタデータをもとに、ユーザによって視聴対象として選択されたコンテンツについて、前記コンテンツを識別するためのコンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、
前記生成されたメッセージを、前記セッションの制御を行うサーバに送信する
コンテンツ受信方法。
【請求項５】
コンテンツの視聴のために前記コンテンツを受信するためのセッションの確立を行うためのメッセージの生成に必要な情報を含むメタデータを取得することが可能なクライアント端末より、前記コンテンツを識別するためのコンテンツ識別子および前記セッションを確立するために必要な情報を含むセッション確立要求を受信し、前記コンテンツ識別子を格納する宛先部と前記セッションを確立するために必要な情報を格納するボディ部とを有するメッセージを生成し、前記セッションの制御を行うことが可能なサーバに送信するセッション処理部
を具備するセッション管理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【公開番号】特開２０１２−２１７１９０（Ｐ２０１２−２１７１９０Ａ）
【公開日】平成２４年１１月８日（２０１２．１１．８）
【国際特許分類】
【出願番号】特願２０１２−１３５０９０（Ｐ２０１２−１３５０９０）
【出願日】平成２４年６月１４日（２０１２．６．１４）
【分割の表示】特願２００８−５２９２７（Ｐ２００８−５２９２７）の分割
【原出願日】平成２０年３月４日（２００８．３．４）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年１１月８日（２０１２．１１．８）
【国際特許分類】
【出願日】平成２４年６月１４日（２０１２．６．１４）
【分割の表示】特願２００８−５２９２７（Ｐ２００８−５２９２７）の分割
【原出願日】平成２０年３月４日（２００８．３．４）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]