(57)【要約】【課題】SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供して、クライアント端末がメタデータを取得する際のコストを低減できるシステムを提供する。【解決手段】ネットワークを介してコンテンツを受信して再生可能なクライアント端末と、コンテンツのメタデータを管理するメタデータサーバとを具備するネットワークシステムにおいて、クライアント端末は、イベント通知予約のための、メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成してメタデータサーバに宛て送信する。メタデータサーバは、SIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立した後、このSIP SUBSCRIBEリクエストに含まれる検索条件をもとにコンテンツのメタデータデータベースを検索し、検索結果を含むSIP NOTIFYメッセージを生成し、クライアント端末に宛て返信する。【選択図】  図１８
2009059160.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツのメタデータを格納するデータベースと、
クライアント端末からの、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、
前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、
前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段と
を具備することを特徴とするサーバ装置。
【請求項２】
請求項１に記載のサーバ装置であって、
前記メタデータ検索手段は、前記ダイアログの確立以降、定期的に前記データベースの検索を行うことを特徴とするサーバ装置。
【請求項３】
請求項１に記載のサーバ装置であって、
前記SIP SUBSCRIBEリクエストに含まれる検索条件が、前記データベースに対するクエリーであることを特徴とするサーバ装置。
【請求項４】
請求項１に記載のサーバ装置であって、
前記SIP SUBSCRIBEリクエストに含まれる検索条件が、前記データベースに対するクエリーを参照／取得するための情報であることを特徴とするサーバ装置。
【請求項５】
請求項１に記載のサーバ装置であって、
前記メッセージ送信手段は、前記SIP NOTIFYメッセージに、前記データベースの検索結果として、前記検索条件に一致するメタデータを格納して、前記SIP NOTIFYメッセージの送信を行うことを特徴とするサーバ装置。
【請求項６】
請求項１に記載のサーバ装置であって、
前記メッセージ送信手段は、前記SIP NOTIFYメッセージに、前記データベースの検索結果として、前記検索条件に一致するメタデータを参照／取得するための情報を格納して、前記SIP NOTIFYメッセージの送信を行うことを特徴とするサーバ装置。
【請求項７】
請求項１に記載のサーバ装置であって、
前記メタデータのフォーマットがTV-Anytimeであることを特徴とするサーバ装置。
【請求項８】
ネットワークを介してコンテンツを受信して再生可能なクライアント端末と、前記コンテンツのメタデータを管理するサーバ装置とを具備するネットワークシステムであって、
前記クライアント端末は、
イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成して前記サーバ装置に宛て送信するメッセージ送信手段と、
前記SIP SUBSCRIBEリクエストに対する前記サーバ装置からの応答であるSIP NOTIFYメッセージを受信し、このSIP NOTIFYメッセージに含まれる前記メタデータの検索結果を格納するメタデータ格納部とを具備し、
前記サーバ装置は、
前記コンテンツのメタデータを格納するデータベースと、
前記クライアント端末からの前記SIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、
前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、
前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段とを具備することを特徴とするネットワークシステム。
【請求項９】
ネットワークを介してコンテンツを受信して再生可能なクライアント端末と、前記コンテンツのメタデータを管理するサーバ装置とを具備するネットワークシステムのコンテンツ発見通知方法であって、
前記クライアント端末のメッセージ送信手段が、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成して前記サーバ装置に宛て送信するステップと、
前記サーバ装置のメッセージ受信手段が、前記クライアント端末からの前記SIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するステップと、
前記サーバ装置のメタデータ検索手段が、前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記コンテンツのメタデータを格納するデータベースの検索を行うステップと、
前記サーバ装置のメッセージ送信手段が、前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するステップと
を具備することを特徴とするネットワークシステムのコンテンツ発見通知方法。
【請求項１０】
コンテンツのメタデータを管理するサーバ装置のコンピュータ・プログラムであって、
コンテンツのメタデータを格納するデータベースと、
クライアント端末からの、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、
前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、
前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段として
コンピュータを機能させることを特徴とするコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツのメタデータを管理するサーバ装置、ネットワークシステム、コンテンツ発見通知方法、及びコンピュータ・プログラムに関するものである。
【背景技術】
【０００２】
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を保証して制御することができる。例えばプッシュトゥトークやテレビ電話、インターネットTV等がIMSによって実現可能になる。
【０００４】
一般に、IPTV等でコンテンツを視聴するためには、EPG(Electronic Program Guide)等のサービスやアプリケーションにより、視聴対象のコンテンツを特定してから、そのコンテンツを取得するために必要な情報を取得して、コンテンツのストリーミング再生のセッションを開始する。IPTVセットップボックスやTV等に実装されるEPGアプリケーションがコンテンツの情報を視聴者に提示してコンテンツを選択、特定するためには、EPGアプリケーションがコンテンツの詳細情報を提供するメタデータサーバからコンテンツの詳細が記述されたメタデータを取得する。これらメタデータをもとにして、生成されたEPGアプリケーションの画面から視聴者が所望のコンテンツを選択、特定する。メタデータの取得は、例えば、メタデータサーバ側で新たなメタデータが追加されたり、既存のメタデータの内容の更新が行われたりするたび等、定期的に行われる。その後、IPTVクライアントはIPTVサーバとの間にIPTVセッションを確立する。
【０００５】
特許文献１においては、IMS-SIPを用いたセッション制御の例が挙げられている。すなわち、画像通信装置間で画像通信を行うためのセッションを確立するために、要求元である画像通信装置からの送信要求パケットを受信したADSLゲートウェイからVoIPサービス業者のSIPプロキシに対して、SIPの仕様に基づくセッション要求メッセージ（INVITEメッセージ）を送信し、SIPプロキシは、セッション要求メッセージのヘッダに記述されている宛先のアドレス解決後に、その宛先のADSLゲートウェイへセッション要求メッセージ（INVITEメッセージ）を送信することとしている。
【特許文献１】特開２００４−１４７１２８号参照（段落００４６等）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
一般に、IPTV等でコンテンツを視聴するためには、例えば、図２９に示すように、IPTVセットップボックスやTV等のIPTVクライアント端末に実装されるEPG(Electronic Program Guide)アプリケーション１４により、視聴したいコンテンツを特定してから、そのコンテンツを取得するために必要な情報を取得して、コンテンツのストリーミング再生のセッションを開始する。EPGアプリケーション１４がコンテンツの情報を視聴者に提示してコンテンツを選択、特定するためには、EPGアプリケーション１４がコンテンツの詳細情報を提供するメタデータサーバ３０からコンテンツの詳細が記述されたメタデータを取得する。これらメタデータをもとにして、生成されたEPGアプリケーションの画面から視聴者が所望のコンテンツを選択、特定する。メタデータの取得は、例えば、メタデータサーバ３０側で新たなメタデータが追加されたり、既存のメタデータの内容の更新が行われたりする等、定期的に行われる。その後、IPTVクライアント端末はIPTVサーバとの間に、コンテンツを再生するためのIPTVセッションを確立する。
【０００７】
このような一般的なIPTVシステムにおいて、IPTVクライアント端末によるメタデータサーバからのメタデータの定期的な取得には大きなコストがかかる。これは、メタデータサーバで新たなメタデータの追加や、メタデータの更新が起こる事象をIPTVクライアント端末の側で予測することができないため、なるべく最新のメタデータをもとにコンテンツを選択できるようにするには、IPTVクライアント端末は、ポーリングの周期を短くとって、メタデータサーバ側に所望のメタデータの最新版を要求しなければならない。したがって、メタデータサーバが、多数ある場合は、このポーリング処理だけでも非常に多くのコストがかかる。
【０００８】
また、IMSでは、セッション制御にSIPを利用する。(IMS-SIPに限らず本来の)SIPには、SUBSCRIBE/NOTIFYプロトコルがある。このSUBSCRIBE/NOTIFYプロトコルでは、クライアント側が、サーバ側に対して条件を提示して、その条件を満たす事象が起こった場合には、その事象をクライアント側に通知するという機構が定義されている。条件、事象等は自由に定義することができる。
【０００９】
しかし、既存のIPTVプロトコルにおいては、このSIPのSUBSCRIBE/NOTIFY機構を用いて、ユーザのクライアント側で処理できるフォーマットや、嗜好するコンテンツの種類を表現する情報をサーバ側に宣言しておき、該当するコンテンツが見つかった場合に通知を受けるという汎用的な方式が定義されていない。
【００１０】
ところで、IPTV標準化における標準メタデータフォーマットの候補はTV-Anytimeメタデータである。TV-Anytimeメタデータは、ETSI(European Telecommunications Standards Institute)で規格化されたメタデータの標準である。例えば、DVB(Digital Video Broadcasting)でのIPTV標準や、ITU-TにおけるIPTV標準のメタデータフォーマットとしてTV-Anytimeメタデータが候補となっている。
【００１１】
本発明は、かかる実情に鑑み、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供して、メタデータの取得コストを低減することのできるサーバ装置、ネットワークシステム、コンテンツ発見通知方法、及びコンピュータ・プログラムを提供しようとするものである。
【課題を解決するための手段】
【００１２】
上記の課題を解決するために、本発明のサーバ装置は、コンテンツのメタデータを格納するデータベースと、クライアント端末からの、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段とを具備する。
【００１３】
本発明により、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供することができ、クライアント端末によるメタデータサーバからのメタデータの取得にかかるコストを低減することができる。
【００１４】
また、本発明のサーバ装置において、前記メタデータ検索手段は、前記ダイアログの確立以降、定期的に前記データベースの検索を行うこととしてもよい。これにより、サーバ装置で新たなメタデータの追加や、メタデータの更新が発生した場合であっても、イベント通知予約のダイアログが確立されている間は、サーバ装置にて定期的にデータベースの検索が行われ、その結果を格納したSIP NOTIFYメッセージがクライアント端末に送信されるので、クライアント端末においては、常に所望とする最新のコンテンツのメタデータを保持しておくことができる。
【００１５】
また、本発明のサーバ装置において、前記SIP SUBSCRIBEリクエストに含まれる検索条件は、前記データベースに対するクエリー、もしくは、前記データベースに対するクエリーを参照／取得するための情報としてもよい。
【００１６】
さらに、本発明のサーバ装置において、前記メッセージ送信手段は、前記SIP NOTIFYメッセージに、前記データベースの検索結果として、前記検索条件に一致するメタデータを格納して、前記SIP NOTIFYメッセージの送信を行うこととしてもよい。あるいは、前記メッセージ送信手段は、前記SIP NOTIFYメッセージに、前記データベースの検索結果として、前記検索条件に一致するメタデータを参照／取得するための情報を格納して、前記NOTIFYメッセージの送信を行うこととしてもよい。
【００１７】
本発明の別の観点に基づくネットワークシステムは、ネットワークを介してコンテンツを受信して再生可能なクライアント端末と、前記コンテンツのメタデータを管理するサーバ装置とを具備するネットワークシステムであって、前記クライアント端末は、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成して前記サーバ装置に宛て送信するメッセージ送信手段と、前記SIP SUBSCRIBEリクエストに対する前記サーバ装置からの応答であるSIP NOTIFYメッセージを受信し、このSIP NOTIFYメッセージに含まれる前記メタデータの検索結果を格納するメタデータ格納部とを具備し、前記サーバ装置は、前記コンテンツのメタデータを格納するデータベースと、前記クライアント端末からの前記SIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段とを具備する。
【００１８】
本発明により、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供することができ、クライアント端末によるメタデータサーバからのメタデータの取得にかかるコストを低減することができる。
【００１９】
本発明の別の観点に基づくコンテンツ発見通知方法は、ネットワークを介してコンテンツを受信して再生可能なクライアント端末と、前記コンテンツのメタデータを管理するサーバ装置とを具備するネットワークシステムのコンテンツ発見通知方法であって、前記クライアント端末のメッセージ送信手段が、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成して前記サーバ装置に宛て送信するステップと、前記サーバ装置のメッセージ受信手段が、前記クライアント端末からの前記SIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するステップと、前記サーバ装置のメタデータ検索手段が、前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記コンテンツのメタデータを格納するデータベースの検索を行うステップと、前記サーバ装置のメッセージ送信手段が、前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するステップとを具備する。
【００２０】
本発明により、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供することができ、クライアント端末によるメタデータサーバからのメタデータの取得にかかるコストを低減することができる。
【００２１】
本発明の別の観点に基づくサーバ装置のコンピュータ・プログラムは、コンテンツのメタデータを格納するデータベースと、クライアント端末からの、イベント通知予約のための、前記メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段と、前記メッセージ受信手段にて受信された前記SIP SUBSCRIBEリクエストに含まれる前記検索条件をもとに前記データベースの検索を行うメタデータ検索手段と、前記メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、前記クライアント端末に宛て返信するメッセージ送信手段として前記コンピュータを機能させるものである。
【００２２】
本発明のコンピュータ・プログラムを用いたサーバ装置により、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供することができ、クライアント端末によるメタデータサーバからのメタデータの取得にかかるコストを低減することができる。
【発明の効果】
【００２３】
本発明によれば、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供して、メタデータの取得コストを低減することができる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態を図面を用いて詳細に説明する。
【００２５】
図１は、本発明の実施の形態であるIPTVシステムに用いられるSIPイベント通知機構を示す図である。
【００２６】
ここで、Subscriber(A)はイベント通知予約の予約者であり、Notifier(B)はイベント通知予約に従ってイベントの発生を予約者に通知する通知者である。
【００２７】
Subscriber(A)からNotifier(B)へイベント通知予約を行う場合にはSIPのSUBSCRIBEリクエストが用いられる。この際、Subscriber(A)は、Notifier(B)のサーバのURIに対してイニシャルSIP SUBSCRIBEリクエストを送信する（Ｓ１）。このイニシャルSIP SUBSCRIBEリクエストは、イベントの種類を示すためのEventヘッダと予約通知の期限(イベントモニタリングの期間)を示すExpiresヘッダを含む。
【００２８】
イベント通知予約のためのイニシャルSIP SUBSCRIBEリクエストを受信したNotifier(B)は、要求されているイベント通知予約を受け付ける場合には200(OK)レスポンスをSubscriber(A)に返信して（Ｓ２）、イベント通知予約のためのダイアログを確立する。ダイアログとは、Subscriber(A)とNotifier(B)との間でのシグナリング（メッセージのやりとり）である。Notifier(B)からの200(OK)レスポンスを受信したSubscriber(A)でもイベント通知予約のためのダイアログが確立される。
【００２９】
ダイアログの確立後、Notifier(B)は、イニシャルSIP SUBSCRIBEリクエストを受信した時点での初期状態を通知するために、Subscriber(A)に対してSIP NOTIFYメッセージを送信する（Ｓ３）。SIP NOTIFYメッセージには、通知対象となるイベントを示すEventヘッダと、通知予約状態を示すSubscriber-Statusヘッダとが含まれる。通知予約状態には、通知予約が有効であることを示す"active"、通知予約が保留（有効か拒否されるか決定されていない状態）されている事を示す"pending"、通知予約が無効（拒否されたか、何らかの理由で終了された状態）であることを示す"terminated"が定義されている。Subscriber(A)は、Notifier(B)からのSIP NOTIFYメッセージを受信した後、200(OK)レスポンスをSubscriber(A)に返信する（Ｓ４）。
【００３０】
ダイアログの確立以降、通知予約されたイベントにおいて状態通知を行うべき事象が発生した場合、Notifier(B)は、イベント通知のためのSIP NOTIFYメッセージをSubscriber(A)に送信する（Ｓ５）。なお、実際のSIP NOTIFYメッセージの送信契機や、メッセージボディパートのMIMEタイプとフォーマットは、通知するイベントの目的に応じて定義されるイベントパッケージの中で規定される。
【００３１】
Subscriber(A)は、Notifier(B)よりSIP NOTIFYメッセージを受信すると、イベント通知予約のためのダイアログが存在するかどうかを確認し、ダイアログが存在し、かつEventヘッダの内容を含めてメッセージ処理可能である場合に、200(OK)レスポンスをNotifier(B)に返信する（Ｓ６）。
【００３２】
Subscriber(A)から通知予約を終了する場合には、Expireヘッダに0を設定したSIP SUBSCRIBEリクエストをSubscriber(A)からNotifier(B)に送信する（Ｓ７）。このSIP SUBSCRIBEリクエストを受信したNotifier(B)は、200(OK)レスポンスを返信した後（Ｓ８）、イベント通知予約の終了を示すSIP NOTIFYメッセージつまりSubscriber-Statusヘッダの示す状態が"terminated"であるSIP NOTIFYメッセージをSubscriber(A)に送信する（Ｓ９）。Subscriber(A)は、このSIP NOTIFYメッセージを受信すると、200(OK)レスポンスを返信する（Ｓ１０）。これにより、Subscriber(A)とNotifier(B)の双方において、イベント通知予約のためのダイアログが解放される。
【００３３】
このイベント通知予約のSubscriber(A)とNotifier(B)とのやりとりのセキュリティを保護するためには、SIPで利用可能なセキュリティメカニズム、例えば、リクエスト認証に利用するHTTP（HyperText Transfer Protocol）ダイジェスト認証や、SIPS URIを用いたメッセージ転送パスにおけるトランスポートレイヤ上のセキュリティの確保や、S/MIME（Secure Multipurpose Internet Mail Extensions）による状態通知内容を含むメッセージボディパートの暗号化等をそのまま利用することができる。
【００３４】
上記のSIPイベント通知機構のSubscriber(A)はクライアント側のEPGアプリケーションであり、Notifier(B)はメタデータサーバであることとする。メタデータサーバは、IPTVサーバがストリーミングやダウンロード等によって配信可能なコンテンツの詳細情報であるメタデータをTV-Anytimeメタデータのフォーマットで管理している。このTV-Anytimeメタデータは、XML（Extensible Markup Language）ドキュメントであり、XMLデータベース等のデータベースに格納されている。
【００３５】
本実施形態のIPTVシステムでは、クライアント側のEPGアプリケーションが、処理可能なフォーマットや、クライアント側のユーザの嗜好にマッチするメタデータを持つコンテンツを特定（表現）する情報をメタデータサーバに宣言し、その宣言された情報にマッチするコンテンツメタデータが発見されたときに、上記のSIPイベント通知機構によって、そのコンテンツメタデータをクライアント側のEPGアプリケーションに通知してもらうサービスが実行される。このサービスを「コンテンツ発見通知イベントパッケージ」と呼ぶ。
【００３６】
次に、このコンテンツ発見通知イベントパッケージの詳細を説明する。
【００３７】
図２にイベント通知予約のためにSubscriber(A)からNotifier(B)へ送信されるSIP SUBSCRIBEリクエストの形式を示す。ここで、sip-uriにはSIP SUBSCRIBEリクエストの宛先を示すURIが格納され、ボディパートには対象のサービスで提供されるコンテンツに関するメタデータのXMLドキュメント（メタデータデータベース)を検索するXQuery文が格納される。
【００３８】
図３にXQuery文の例を示す。XQuery文はプロローグとクエリー本体を含み、プロローグには、XQueryバージョン宣言である"xquery version "1.0";"や、名前空間宣言である"declare default element namespace "urn:tva:metadata:2005";"等が格納される。クエリー本体には、XMLメタデータドキュメントを検索するXPath形式やFLWOR形式のクエリーが格納される。
【００３９】
図４はXPath形式のクエリーの例である。この例は、対象のTV-Anytimeメタデータの中から、コンテンツ概要に「派遣」を含み、かつ、出演者名に「涼子」を含む、コンテンツのメタデータを返すクエリーである。すなわち、コンテンツのメタデータを記述するProgramInformation要素の配下の（より具体的には、この直下のBasicDescription要素の）Synopsis要素のテキスト部に「派遣」を含み、かつ、ProgramInformation要素の配下の（より具体的には、この直下のBasicDescription要素のCreditsList要素のCreditsItem要素のPersonName要素の）GivenName要素に「涼子」を含むProgramInformation要素全体を返すクエリーである。なお、条件に見合う複数のProgramInformation要素がある場合は、クエリーは複数のProgramInformation要素のシーケンスとなる。例えば、"<ProgramInformation>1つ目のProgramInformationの内容</ProgramInformation><ProgramInformation>2つ目のProgramInformationの内容</ProgramInformation>..."のようなクエリーとなる。
【００４０】
図５はFLWOR形式のクエリーの例である。この例は、対象のTV-Anytimeメタデータの中から、コンテンツタイトルに「ハケンの品格」を含むコンテンツのメタデータを返すクエリーである。すなわち、コンテンツのメタデータを記述するProgramInformation要素のBasicDescription要素のTitle要素のテキスト部に「ハケンの品格」を含むProgramInformation要素全体を返すクエリーである。
【００４１】
SIPメッセージは、IMSにおけるセッションを制御するための重要なシグナリングの役割を担っているため、通常、優先度の高いネットワーク上のパスが割り当てられている。そのため、SIPセッション制御が頻繁にかつ大量に発生する環境においては、このシグナリングパスのネットワークリソース（帯域等）のトラフィックを最小限に抑える必要がある。一方、コンテンツのメタデータのドキュメントはサービスプロバイダによっては、非常に大きなものとなる可能性がある。その場合、SIP SUBSCRIBEリクエストで通知されるメタデータクエリーや、後述するSIP NOTIFYメッセージで通知されるメタデータが非常に大きくなり、SIPシグナリングのリソースを圧迫する可能性が出てくる。したがって、本実施の形態では、この問題を回避するため、SIP SUBSCRIBEリクエスト及びSIP NOTIFYメッセージのボディパートに直接該当するクエリーやメタデータを格納する方式だけではなく、そのクエリーやメタデータを参照／取得するための情報を格納する方式を提供する。
【００４２】
図６は、メタデータクエリーや、結果のメタデータ要素、もしくは、それを取得するための参照を格納するメタデータのXMLドキュメントのXMLスキーマの例である。ここで、"encapsulation"はルート要素、"entity"はメタデータクエリーや、結果のメタデータ要素を直接格納する要素、"reference"はメタデータクエリーや、結果のメタデータ要素を取得するための参照を格納する要素である。
【００４３】
このデータ書式（DIDF:Descovery Information Data Format）を識別するためのMIME （Multipurpose Internet Mail Extensions）タイプを" application/didf+xml"とする。メタデータクエリーを格納する、もしくは、それを参照する場合、encapsulation要素をフィルタドキュメントとよぶ。クエリーの結果のメタデータ要素を格納する、もしくは、それを参照する場合、encapsulation要素をメタデータドキュメントとよぶ。
【００４４】
図７は、図４のXPath形式のクエリーを含むSIP SUBSCRIBEリクエストの例である。ここで開始行の、SIP SUBSCRIBEメソッドのリクエストURIの"sip:IPTVDiscoveryServer@servicePlatform.com"は、コンテンツ発見イベント通知サービスを提供するメタデータサーバ３０のsip-uriである。Fromヘッダの"sip:IPTVClient@servicePlatform.com"は、クライアント端末のsip-uriである。Eventヘッダには、コンテンツ発見通知イベントパッケージを識別する"discoveryService"が格納される。Expiresヘッダは、この予約(イベントサブスクリプション)の有効期限を秒単位で示す。Content-Typeヘッダは、ボディパートのMIMEタイプ(application/didf+xml)を示す。XPath形式のクエリーは、entity要素の内容として格納されている。
【００４５】
上記のSIP SUBSCRIBEリクエストを受信したNotifier(B)は、要求されているイベント通知予約を受け付ける場合にSubscriber(A)に200(OK)レスポンスを返信する。図８に、この200(OK)レスポンスの例を示す。
【００４６】
Notifier(B)は、200(OK)レスポンスの返信後、SIP SUBSCRIBEリクエストを受信した時点や、通知予約されたイベントにおいて状態通知を行うべき事象が発生した場合に、Subscriber(A)に対して初期状態やコンテンツ発見通知イベントを通知するためのSIP NOTIFYメッセージを送信する。図９は、上記のコンテンツ発見通知イベントを通知するためのSIP NOTIFYメッセージの形式である。ここで、sip-uriには接続先の相手を示すURIが格納され、ボディパートには、コンテンツ発見結果のメタデータ要素が格納される。
【００４７】
図１０は、図４のXPath形式のクエリーの例を含むSIP SUBSCRIBEリクエストに対する、コンテンツ発見結果のメタデータ要素２をボディパートに格納したSIP NOTIFYメッセージの例である。ここで、開始行の、SIP NOTIFYメソッドのリクエストURIの"sip:IPTVClient@servicePlatform.com"は、コンテンツ発見イベント通知サービスを受ける（イベント通知予約をしている）EPGアプリケーションが稼動しているIPTVクライアント端末のsip-uriである。Fromヘッダの"sip:IPTVDiscoveryServer@servicePlatform.com"は、コンテンツ発見イベント通知サービスを提供するメタデータサーバのsip-uriである。Subscription-Stateヘッダには、 このサブスクリプションが有効であること示す"active"が指定されており、通知予約の有効期間を示すexpiresパラメタを含む。
【００４８】
図１１は、上記と同じSIP NOTIFYメッセージを、コンテンツ発見結果のメタデータ要素を参照／取得するための情報３を格納する方式で表現した例である。この例では、reference要素のhttp://servicePlatform.com/metadataResponse/1234567890.xmlを参照先として、コンテンツ発見結果のメタデータ要素を取得できるものとしている。
【００４９】
Subscriber(A)は、Notifier(B)からのSIP NOTIFYメッセージを受信した後、200(OK)レスポンスをSubscriber(A)に返信する。図１２は、上記SIP NOTIFYメッセージに対する200(OK)レスポンスの例である。
【００５０】
上記のSIP NOTIFYメッセージは、Notifier(B)において、Subscriber(A)から予約されたイベントに該当する事象が起こるたびに送信される。上述の例で言えば、図７に示したSIP SUBSCRIBEリクエストのボディパートの予約(イベントサブスクリプション)の有効期限が有効な間は、クエリーにヒットするコンテンツのメタデータが、対象のサービスで提供されるコンテンツに関するメタデータのXMLドキュメント(メタデータデータベース３４)に追加された場合に、SIP NOTIFYメッセージが送信される。
【００５１】
図１３は、メタデータのXMLドキュメント(メタデータデータベース３４)への追加により新たにヒットしたメタデータ４を含むSIP NOTIFYメッセージの例である。
【００５２】
このコンテンツ発見通知イベントパッケージをまとめると以下のようになる。
【００５３】
１）イベントパッケージ名
(イベントパッケージの名称)
このパッケージの名称は「discoveryService」である。この値は、SIP SUBSCRIBEリクエストおよびSIP NOTIFYメッセージで指定されるEventヘッダーフィールドで使用される。
【００５４】
２）SIP SUBSCRIBEリクエストのボディパート
SIP SUBSCRIBEリクエストにはボディパートを含めなければならない。このボディパートは、フィルタドキュメントである。フィルタドキュメントは、MIMEタイプ"application/didf+xml"のデータ形式に対応しなければならない。フィルタドキュメントでは、特定のイベントのみの通知を要求し、SIP NOTIFYメッセージで返されるデータセットに関する制限を指定する。たとえば、ユーザの嗜好にマッチしたコンテンツが提供可能となった場合にだけイベントを通知するようなフィルタを設定する。  
【００５５】
３）サブスクリプション期間
(デフォルトのサブスクリプション期間)
サブスクリプションのデフォルトの有効期間は2592000秒(30日)とする。サブスクライバは、自由にExpiresヘッダーフィールドの有効期限を指定してもよい。
【００５６】
４）SIP NOTIFYメッセージのボディパート
SIP NOTIFYメッセージには、ボディパートを含めなければならない。このボディパートは、メタデータドキュメントである。メタデータドキュメントは、MIMEタイプ"application/didf+xml"のデータ形式に対応しなければならない。メタデータドキュメントには、サブスクライブされる際に設定されるフィルタにマッチするメタデータのみが格納される。
【００５７】
５）メッセージ交換のセキュリティ
（認証／認可の方法）
SIP SUBSCRIBEリクエストの受信時には、SIPで利用可能なセキュリティメカニズム、例えば、リクエスト認証に利用するHTTPダイジェスト認証や、SIPS URIを用いたメッセージ転送パスにおけるトランスポートレイヤ上のセキュリティの確保や、S/MIMEによる状態通知内容を含むメッセージボディパートの暗号化等をそのまま利用することができる。
【００５８】
６）SIP NOTIFYメッセージ送出のタイミング
(メッセージ送出頻度)
SIP NOTIFYメッセージの送出は、Notifier(B)が監視対象とするメタデータデータベース３４の内容の変更を表すイベント（データの新規作成、内容の更新)毎に実施することも、一定の周期(デフォルトを3600秒とする)毎に実施することもできる。Notifier(B)の運用方法に依存する。一定の周期毎に実施する場合は、その周期の間に起こったイベントをまとめて送出する。
【００５９】
（1 コンテンツの取得・再生）
コンテンツ発見通知イベントサービスにより、所望のコンテンツを発見したクライアント側のEPGアプリケーションは、同じクライアント端末上で稼動するIPTVクライアントアプリケーション１３に対して、結果として返されるSIP NOTIFYメッセージのボディパートに格納されたメタデータドキュメントを渡し、コンテンツの取得・再生を依頼する。IPTVクライアントアプリケーション１３は、当該メタデータ要素から、コンテンツの取得に必要なアドレス情報等を取り出して、コンテンツをダウンロード、あるいは、ストリーミングサーバ上のコンテンツを再生する。
【００６０】
図１４は、SIP NOTIFYメッセージのボディパートに格納されたメタデータドキュメントの例である。このメタデータドキュメントに格納されているコンテンツメタデータであるProgramInformation要素の記述対象となっているコンテンツを取得するためには、ProgramInformation要素の属性の値である"crid://ca.com/321"をキーにして、コンテンツのアドレスURLが記述されているOnDemandProgram要素を取得する。このOnDemandProgram要素は、直接メタデータデータベース３４に対してクエリーを発行することにより取得することもできれば、コンテンツ発見通知イベントサービスを利用して取得することもできる。なお、上記の例では、コンテンツメタデータのProgramInformation要素のみを結果送信の対象としていたが、この要素とOnDemandProgram要素を取得するようなクエリーを構成して、サブスクライブしておくことにより、ProgramInformation要素とそれと紐づいているOnDemandProgram要素を同時に取得することも可能である。
【００６１】
次に、上記の方式を用いた本実施形態のIPTVシステムについて説明する。
【００６２】
図１５は、本実施形態のIPTVシステム１００の構成を示すブロック図である。
【００６３】
同図に示すように、この実施形態のIPTVシステム１００は、IPTVクライアント端末１０、コンテンツをストリーミングやダウンロード等で配信可能するIPTVサーバ２０、IPTVサーバ２０が配信可能なコンテンツの詳細情報であるメタデータを管理するメタデータサーバ３０、及びこれらを接続可能なネットワーク４０とで構成される。
【００６４】
IPTVクライアント端末１０は、例えば、PC（Personal Computer）、セットップボックス、TV等の端末機器である。IPTVクライアント端末１０は、ユーザインターフェイス１１、ネットワークインターフェイス１２、IPTVクライアントアプリケーション１３、EPGアプリケーション１４、ローカルメタデータデータベース１５等を備える。
【００６５】
ユーザインターフェイス１１は、ユーザ１に対する入出力を処理する。例えば、ユーザインターフェイス１１は、ユーザ１からの各種の指令を入力してEPGアプリケーション１４に出力したり、EPGアプリケーション１４からユーザ１への応答やコンテンツの再生情報を出力する処理等を行う。
【００６６】
ネットワークインターフェイス１２は、インターネット等のネットワーク４０とのインターフェイスを提供する。
【００６７】
IPTVクライアントアプリケーション１３は、IPTVクライアント端末１０をIPTVクライアントとして動作させるための各種制御を行うソフトウエアである。
【００６８】
EPGアプリケーション１４は、ユーザ１に対する入出力等の処理を行うユーザインタラクション処理部１６と、コンテンツ発見通知イベントパッケージの処理を行うイベントパッケージ処理部１７とを有する。イベントパッケージ処理部１７は、イベント通知予約のための、メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを生成してメタデータサーバ３０に宛て送信するメッセージ送信手段である。
【００６９】
ローカルメタデータデータベース１５は、例えば、ハードディスクドライブや半導体メモリ等の記憶装置で構成され、メタデータサーバ３０より取得したコンテンツメタデータを格納する。すなわち、メタデータサーバ３０より受信したNOTIFYメッセージに含まれるメタデータの検索結果を格納するメタデータ格納部である。
【００７０】
その他、図示は省略したが、IPTVクライアント端末１０は、IPTVサーバ２０よりストリーミングやダウンロード等により受信したコンテンツのデータを記憶するコンテンツ記憶部、コンテンツのデコードから再生までの処理を行うコンテンツ再生部等を備える。
【００７１】
IPTVサーバ２０は、ストリーミングやダウンロード等によって配信可能なコンテンツの本体データを管理しており、IPTVクライアント端末１０のIPTVクライアントアプリケーション１３との間でコンテンツの取得・再生のためのセッションを確立して、IPTVクライアント端末１０に対してストリーリングやダウンロード等によってコンテンツを配信する。
【００７２】
メタデータサーバ３０は、ネットワークインターフェイス３１、イベントパッケージ処理部３２、メタデータクエリー処理部３３、及びメタデータデータベース３４を備える。
【００７３】
ネットワークインターフェイス３１は、インターネット等のネットワーク４０とのインターフェイスを提供する。
【００７４】
イベントパッケージ処理部３２は、コンテンツ発見通知イベントパッケージの処理を行う。イベントパッケージ処理部３２は、IPTVクライアント端末１０からの、イベント通知予約のための、メタデータに対する検索条件を含むSIP SUBSCRIBEリクエストを受信して、イベント通知予約のためのダイアログを確立するメッセージ受信手段、及び、メタデータ検索手段により得られた検索結果を含むSIP NOTIFYメッセージを生成し、IPTVクライアント端末１０に宛て返信するメッセージ送信手段である。
【００７５】
メタデータクエリー処理部３３は、メタデータデータベース３４に対してクエリーを発行してメタデータの検索を行う。すなわち、メタデータクエリー処理部３３は、上記のメッセージ受信手段にて受信されたSIP SUBSCRIBEリクエストに含まれる検索条件をもとにメタデータデータベース３４の検索を行うメタデータ検索手段である。
【００７６】
メタデータデータベース３４は、PTVサーバ２０が配信可能なコンテンツの詳細情報であるメタデータをTV-Anytimeメタデータのフォーマットで管理している。このTV-Anytimeメタデータは、XML（Extensible Markup Language）ドキュメントであり、XMLデータベース等のデータベースに格納されている。
【００７７】
図１６は、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サーバ２０及びメタデータサーバ３０のハードウェアの構成を示すブロック図である。
【００８２】
IPTVサーバ２０及びメタデータサーバ３０は、図１７に示すように、パーソナルコンピュータ等の典型的なコンピュータシステムからなる構成とされている。
【００８３】
すなわち、CPU６０１には、システムバス６０９を介して、ROM６０２と、RAM６０３と、ネットワークインターフェイス３１と、キーボード、マウス等よりなる入力部６０５と、CRT（Cathode Ray Tube）、LCD等よりなるディスプレイとスピーカ等よりなる出力部６０６と、メディアインターフェイス６０７と、ハードディスクドライブや不揮発性メモリ等よりなる記憶部６０８とが接続されている。
【００８４】
ネットワークインターフェイス３１は、ネットワーク４０との有線または無線での接続を処理する。記憶部６０８には、特定のサーバとしての機能をコンピュータに実行させるためのプログラムと、各種のデータ等が格納されている。CPU６０１は、ROM６０２や記憶部６０８からプログラムをRAM６０２へロードして、解釈実行するための演算処理を行う。メディアインターフェイス６０７には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等のリムーバブルメディア６０が適宜装着され、それらから読み出されたプログラムが、必要に応じて記憶部６０８にインストールされる。
【００８５】
次に、本実施形態のIPTVシステム１００の動作を説明する。
【００８６】
図１８は、本実施形態のIPTVシステム１００におけるコンテンツ発見通知イベントパッケージのシーケンス図である。
【００８７】
はじめにIPTVクライアント端末１０とメタデータサーバ３０との間で、コンテンツ発見のイベント通知予約のダイアログを確立する処理が次のように行われる。図１９は、このときのIPTVクライアント端末１０での処理の流れを示すシーケンス図である。
【００８８】
まず、IPTVクライアント端末１０のEPGアプリケーション１４内のユーザインタラクション処理部１６が、ユーザインターフェイス１１を介して、ユーザ１からのコンテンツ検索通知の開始要求を受け付ける（図１９：ステップS２０１）。このユーザ１からのコンテンツ検索通知の開始要求は、例えば、コンテンツ概要に「派遣」を含み、かつ、出演者名に「涼子」を含むコンテンツがほしい等の要求である。ユーザインタラクション処理部１６は、このコンテンツ検索通知開始要求を受け付けると、SIP SUBSCRIBEリクエストのボディパートに格納されるXQuery文のクエリーを生成する（図１９：ステップS２０２）。より具体的には、例えば、図７に示したSIP SUBSCRIBEリクエストにおけるentity要素の内容が、ユーザインタラクション処理部１６によって生成される。この後、ユーザインタラクション処理部１６は、イベントパッケージ処理部１７に対して、イベント通知予約を依頼する（図１９：ステップS２０３）。イベントパッケージ処理部１７は、ネットワークインターフェイス１２を介して、イベント通知予約のためのSIP SUBSCRIBEリクエスト（図７参照）をメタデータサーバ３０に送信する（図１９：ステップS２０４）。このとき、SIP SUBSCRIBEリクエストの宛先には、既知のメタデータサーバ３０のsip-uri（例えば、図７の開始行のsip:IPTVDiscoveryServer@servicePlatform.com等）が格納される。その後、イベントパッケージ処理部１７が上記SIP SUBSCRIBEリクエストに対応する200(OK)レスポンス（図８参照）を受け取ることにより、コンテンツ発見のイベント通知予約のためのダイアログが確立する。
【００８９】
次に、メタデータサーバ３０でのイベント通知予約のためのダイアログ確立処理を説明する。このときのメタデータサーバ３０での処理の流れを図２０に示す。
【００９０】
まず、イベントパッケージ処理部３２は、ネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４が発行するイベント通知予約のためのSIP  SUBSCRIBEリクエストを受けると、それに対応する200(OK)レスポンス（図８参照）をネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４に返し（図２０：ステップS３０１）、イベント通知予約のためのダイアログが確立する。次に、イベントパッケージ処理部１７は、受け取ったSIP SUBSCRIBEリクエストのボディパートに格納されたXQuery文のクエリーをメタデータクエリー処理部３３に渡す（図２０：ステップS３０２）。
【００９１】
メタデータクエリー処理部３３がクエリーを受け取った後のメタデータサーバ３０での処理の流れを図２１及び図２２に示す。メタデータクエリー処理部３３ は、イベントパッケージ処理部３２からクエリーを受け取るとクエリー処理プロセスを立ち上げ、コンテンツのメタデータを管理するメタデータデータベース３４に対してそのクエリーを発行する（図２１：ステップS４０１，図２２：ステップS５０１）。対象のメタデータデータベース３４は、単一のIPTVサービスプロバイダで管理されるメタデータデータベースの場合もあれば、複数のIPTVサービスプロバイダをまたがった、複数のメタデータデータベースから構成される場合もある。
【００９２】
このメタデータデータベース３４の検索処理は定期的に行われるが、最初の検索処理では、図２１に示すように、該当するメタデータつまりクエリーにヒットするメタデータが得られたか否かにかかわらず、メタデータクエリー処理部３３はメタデータデータベース３４より検索結果を取得した後（図２１：ステップS４０２）、イベントパッケージ処理部３２に対して、検索結果をイベントパッケージ処理部３２に渡して、初期状態の通知のためのSIP NOTIFYメッセージの発行をイベントパッケージ処理部３２に依頼する（図２１：ステップS４０３）。ここで、メタデータデータベース３４より検索結果とは、クエリーにヒットしたメタデータ要素もしくはそのメタデータを参照／取得するための情報である。イベントパッケージ処理部３２は、この初期状態の通知のためのSIP NOTIFYメッセージの発行依頼を受けると、メタデータデータベース３４の検索結果を初期状態の通知のためのSIP NOTIFYメッセージ（図１０、図１１参照）のボディパートに格納して、ネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４に送信する（図２１：ステップS４０４）。
【００９３】
図２３は、クライアント側のEPGアプリケーション１４がメタデータサーバ３０よりSIP NOTIFYメッセージを受信したときの処理の流れを示す図である。同図に示すように、クライアント側のEPGアプリケーション１４は、メタデータサーバ３０より初期状態の通知のSIP NOTIFYメッセージを受信すると、これに対応する200(OK)レスポンス（図１２参照）をネットワークインターフェイス１２を介して、メタデータサーバ３０に返信する（図２３：ステップS６０１）。ここで、初期状態の通知のSIP NOTIFYメッセージのボディパートにコンテンツのメタデータまたはメタデータを参照／取得するための情報が格納されている場合には、EPGアプリケーション１４は、このSIP NOTIFYメッセージのボディパートに格納されたコンテンツのメタデータまたはメタデータを参照／取得するための情報をローカルメタデータベース１５に格納する（図２３：ステップS６０２）。
【００９４】
メタデータサーバ３０での検索処理は、イベント通知予約のダイアログ期間においては定期的に行われる。すなわち、図２２に示すように、メタデータクエリー処理部３３は一定周期でメタデータデータベース３４に対してクエリーを発行する（図２２：ステップS５０１）。メタデータクエリー処理部３３はメタデータデータベース３４より検索結果を取得した後（図２２：ステップS５０２）、当該検索結果をイベントパッケージ処理部３２に渡して、イベント通知のためのSIP NOTIFYメッセージの発行を依頼する（図２２：ステップS５０３）。イベントパッケージ処理部３２は、SIP NOTIFYメッセージの発行依頼を受けると、検索結果をイベント通知のためのSIP NOTIFYメッセージ（図１４参照）のボディパートに格納し、ネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４に、そのSIP NOTIFYメッセージを送信する（図２２：ステップＳ５０４）。
【００９５】
クライアント側のEPGアプリケーション１４は、図２３に示したように、メタデータサーバ３０よりイベント通知のためのSIP NOTIFYメッセージを受信すると、これに対応する200(OK)レスポンス（図１２参照）をネットワークインターフェイス１２を介して、メタデータサーバ３０に返信する（図２３：ステップS６０１）。そして、EPGアプリケーション１４は、このSIP NOTIFYメッセージのボディパートに格納されたコンテンツのメタデータまたはメタデータを参照／取得するための情報をローカルメタデータベース１５に格納する（図２３：ステップS６０２）。
【００９６】
以後、定期的に、メタデータサーバ３０がメタデータデータベース３４に対してクエリーを発行する処理（ステップＳ５０１）から、クライアント側のEPGアプリケーション１４がイベント通知のSIP NOTIFYメッセージに対して200(OK)レスポンスを返す処理までの「クエリー発行&通知ループ」が繰り返される。
【００９７】
図２４は、「クエリー発行&通知ループ」の繰り返しの中で、クライアント側にて、ユーザ１からのコンテンツ検索要求が発生したとき、もしくはローカルメタデータデータベース１５のメタデータが最新のものに更新された場合の処理の流れを示す図である。この場合、EPGアプリケーション１４のユーザインタラクション処理部１６は、ローカルメタデータデータベース１５よりメタデータを取得し（図２４：ステップS７０１）、このメタデータをもとに、視聴するコンテンツをユーザ１に選択させるためのインターフェイス画面を作成し、ユーザインターフェイス１１を通じてユーザに提示する（図２４：ステップS７０２）。インターフェイス画面でユーザ１によって視聴したいコンテンツが選択されると（図２４：ステップS７０３）、ユーザインタラクション処理部１６は、この選択されたコンテンツのメタデータをローカルメタデータデータベース１５から読み出し、このメタデータを含む、コンテンツ再生のためのセッション確立依頼をIPTVクライアントアプリケーション１３に渡す（図２４：ステップS７０４）。IPTVクライアントアプリケーション１３は、このコンテンツ再生のためのセッション確立依頼を受けると、そのコンテンツの取得・再生のためのシーケンスを実行する（図２４：ステップS７０５）。
【００９８】
図２５は、コンテンツの取得・再生のシーケンスを示す図である。IPTVクライアントアプリケーション１３は、ローカルメタデータデータベース１５に格納された当該コンテンツのメタデータに、当該コンテンツのURL等のアドレス情報が含まれているかどうかを判断する（図２５：ステップS８０１）。すなわち、クエリーの構成によっては、メタデータデータベース３４からの検索結果として、図１３に示したメタデータ要素におけるProgramInformation要素のprogramId属性の値であるアドレス情報を含めるかどうかを選択することができる。
【００９９】
もしローカルメタデータデータベース１５に格納されたコンテンツのメタデータにそのコンテンツのアドレス情報が含まれている場合、IPTVクライアントアプリケーション１３は、そのアドレス情報を含むメタデータを用いて、当該コンテンツを配信可能なIPTVサーバ２０に、当該コンテンツの再生セッションの確立を依頼し（図２５：ステップS８０４）、この再生セッションの確立後、この再生セッションを用いてIPTVサーバ２０からコンテンツのデータを取得して再生を行う（図２５：ステップS８０５）。
【０１００】
また、ローカルメタデータデータベース１５に格納されたコンテンツのメタデータに当該コンテンツのアドレス情報が含まれていなければ、IPTVクライアントアプリケーション１３は、当該コンテンツのアドレス情報を含むメタデータを取得するためのクエリーを生成して、ネットワーク４０を介してメタデータデータベース３４に直接検索を依頼する（図２５：ステップS８０２）。メタデータデータベース３４は、この検索依頼を受けて、該当するコンテンツのメタデータを検索してその中のアドレス情報をネットワーク４０を介してクライアント側のIPTVクライアントアプリケーション１３に返信する（図２５：ステップS８０３）。IPTVクライアントアプリケーション１３は、メタデータデータベース３４より直接取得したアドレス情報を含むメタデータを用いて、前述と同様に、当該コンテンツを配信可能なIPTVサーバ２０に対して、コンテンツの再生セッションの確立を依頼し（図２５：ステップS８０４）、セッション確立後、この再生セッションの確立後、この再生セッションを用いてIPTVサーバ２０からコンテンツのデータを取得して再生を行う（図２５：ステップS８０５）。
【０１０１】
次に、イベント通知予約のダイアログの解放処理について説明する。
【０１０２】
図２６はクライアント側でのイベント通知予約のダイアログの解放処理の手順を示す図、図２７及び図２８はメタデータサーバ３０でのイベント通知予約のダイアログの解放処理の手順を示す図である。
【０１０３】
EPGアプリケーション１４内のユーザインタラクション処理部１６は、ユーザインターフェイス１１を介してユーザ１からのコンテンツ検索通知の終了要求を受け付ける（図２６：ステップS９０１）。ユーザインタラクション処理部１６は、このコンテンツ検索通知の終了要求を受け付けると、イベントパッケージ処理部１７に対して、イベント通知予約の終了を依頼する（図２６：ステップS９０２）。イベントパッケージ処理部１７は、このイベント通知予約終了の依頼を受けると、ネットワークインターフェイス１２を介して、イベント通知予約終了のSIP SUBSCRIBEリクエストをメタデータサーバ３０に送信する（図２６：ステップS９０３）。
【０１０４】
メタデータサーバ３０内のイベントパッケージ処理部３２は、ネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４からのイベント通知予約終了のSIP SUBSCRIBEリクエストを受けると、メタデータクエリー処理部３３に対して、対応するクエリー処理プロセスの終了を依頼する（図２８：ステップS１００１）。メタデータクエリー処理部３３は、このクエリー処理プロセスの終了依頼を受けて、対応するクエリー処理プロセスを終了し、このクエリー処理プロセスの終了通知をイベントパッケージ処理部３２に返す（図２８：ステップS１００２）。イベントパッケージ処理部３２は、メタデータクエリー処理部３３からのクエリー処理プロセスの終了通知を受けて、200(OK)レスポンスをネットワークインターフェイス３１を介してクライアント側のEPGアプリケーション１４に送信する（図２８：ステップS１００３）。この後、イベントパッケージ処理部３２はイベント通知予約のためのダイアログを解放する。
【０１０５】
イベントパッケージ処理部３２は、イベント通知予約のためのダイアログを解放した後、イベント通知予約終了のSIP NOTIFYメッセージを生成し、ネットワークインターフェイス３１を介して、クライアント側のEPGアプリケーション１４に送信する（図２８：ステップS１１０１）。EPGアプリケーション１４のイベントパッケージ処理部１７は、イベント通知予約終了のSIP NOTIFYメッセージを受信すると、イベント通知予約のためのダイアログを解放し、200(OK)レスポンスをネットワークインターフェイス１２を介してサーバ側に送信する。
【０１０６】
この実施形態によれば、SIPのSUBSCRIBE/NOTIFY機構を利用して所望のコンテンツを発見する仕組みを提供することができ、IPTVクライアント端末１０によるメタデータサーバ３０からのメタデータの取得にかかるコストを低減することができる。また、メタデータサーバ３０で新たなメタデータの追加や、メタデータの更新が発生した場合であっても、イベント通知予約のダイアログが確立されている間は、メタデータサーバ３０にて定期的にクエリー発行によるメタデータデータベース３４の検索が行われ、その結果を格納したSIP NOTIFYメッセージがIPTVクライアント端末１０に送信されるので、IPTVクライアント端末１０においては、常に所望とする最新のコンテンツのメタデータを保持しておくことができる。
【０１０７】
本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々更新を加え得ることは勿論である。
【図面の簡単な説明】
【０１０８】
【図１】本発明の実施の形態であるIPTVシステムに用いられるSIPイベント通知機構を示す図である。
【図２】SIP SUBSCRIBEリクエストの形式を示す図である。
【図３】図２のSIP SUBSCRIBEリクエスト内のXQuery文の例を示す図である。
【図４】XPath形式のクエリーの例を示す図である。
【図５】FLWOR形式のクエリーの例を示す図である。
【図６】メタデータのクエリーやメタデータに対するXMLスキーマの例を示す図である。
【図７】図４のXPath形式のクエリーを含むSIP SUBSCRIBEリクエストの例を示す図である。
【図８】図４のSIP SUBSCRIBEリクエストに対するリプライである200(OK)レスポンスの例を示す図である。
【図９】コンテンツ発見通知イベントを通知するためのSIP NOTIFYメッセージの形式を示す図である。
【図１０】図９のSIP NOTIFYメッセージの例を示す図である。
【図１１】図９のSIP NOTIFYメッセージの他の例を示す図である。
【図１２】図１０のSIP NOTIFYメッセージに対する200(OK)レスポンスの例を示す図である。
【図１３】図９のSIP NOTIFYメッセージのさらに他の例を示す図である。
【図１４】SIP NOTIFYメッセージのボディパートに格納されたメタデータドキュメントの例である。
【図１５】本実施形態のIPTVシステムの構成を示すブロック図である。
【図１６】図１５のIPTVシステムのIPTVクライアント端末のハードウェアの構成を示すブロック図である。
【図１７】図１５のIPTVシステムのIPTVサーバ及びメタデータサーバのハードウェアの構成を示すブロック図である。
【図１８】本実施形態のIPTVシステムにおけるコンテンツ発見通知イベントパッケージのシーケンス図である。
【図１９】IPTVクライアント端末でのイベント通知予約のダイアログ確立処理のシーケンス図である。
【図２０】メタデータサーバでのイベント通知予約のダイアログ確立処理のシーケンス図である。
【図２１】メタデータサーバでの最初の検索処理のシーケンス図である。
【図２２】メタデータサーバでの定期的な検索処理のシーケンス図である。
【図２３】EPGアプリケーションでの検索結果取得処理のシーケンス図である。
【図２４】IPTVクライアント端末でのメタデータを用いてコンテンツの選択及びコンテンツの再生セッションの確立依頼を行う処理のシーケンス図である。
【図２５】コンテンツの取得・再生のシーケンスを示す図である。
【図２６】IPTVクライアント端末でのイベント通知予約のダイアログの解放処理のシーケンスを示す図である。
【図２７】メタデータサーバでのイベント通知予約のダイアログの解放処理のシーケンスを示す図である。
【図２８】図２７から続くメタデータサーバでのイベント通知予約のダイアログの解放処理のシーケンスを示す図である。
【図２９】一般的なIPTVシステムでのコンテンツのメタデータの取得からコンテンツ再生のためのセッションの確立までの手順を示すシーケンス図である。
【符号の説明】
【０１０９】
１０    IPTVクライアント端末
１３    IPTVクライアントアプリケーション
１４    EPGアプリケーション
１５    ローカルメタデータデータベース
１６    ユーザインタラクション処理部
１７    イベントパッケージ処理部
２０    IPTVサーバ
３０    メタデータサーバ
３２    イベントパッケージ処理部
３３    メタデータクエリー処理部
３４    メタデータデータベース
４０    ネットワーク
１００  IPTVシステム
【図１】
2009059160.tif 000003
【図２】
2009059160.tif 000004
【図３】
2009059160.tif 000005
【図４】
2009059160.tif 000006
【図５】
2009059160.tif 000007
【図６】
2009059160.tif 000008
【図７】
2009059160.tif 000009
【図８】
2009059160.tif 000010
【図９】
2009059160.tif 000011
【図１０】
2009059160.tif 000012
【図１１】
2009059160.tif 000013
【図１２】
2009059160.tif 000014
【図１３】
2009059160.tif 000015
【図１４】
2009059160.tif 000016
【図１５】
2009059160.tif 000017
【図１６】
2009059160.tif 000018
【図１７】
2009059160.tif 000019
【図１８】
2009059160.tif 000020
【図１９】
2009059160.tif 000021
【図２０】
2009059160.tif 000022
【図２１】
2009059160.tif 000023
【図２２】
2009059160.tif 000024
【図２３】
2009059160.tif 000025
【図２４】
2009059160.tif 000026
【図２５】
2009059160.tif 000027
【図２６】
2009059160.tif 000028
【図２７】
2009059160.tif 000029
【図２８】
2009059160.tif 000030
【図２９】
2009059160.tif 000031