JPWO2007102549A1

JPWO2007102549A1 - 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム

Info

Publication number: JPWO2007102549A1
Application number: JP2008503893A
Authority: JP
Inventors: 五十嵐　卓也; 卓也五十嵐
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2006-03-07
Filing date: 2007-03-07
Publication date: 2009-07-23
Also published as: EP2000917A1; EP2000919A1; KR20080098650A; CN101438257B; EP2000918A4; CN101438256B; KR101361053B1; RU2008136041A; WO2007102550A1; EP2000918A1; CN101438256A; US20090180484A1; CN101438257A; US20090307307A1; JPWO2007105568A1; BRPI0708573A2; JPWO2007102547A1; WO2007102547A1; JPWO2007102550A1; US8316082B2

Abstract

ホームネットワーク内機器が、ホームネットワーク外のサーバからコンテンツを受領して再生する構成を提供する。ホームＩＭＳゲートウェイが、ホームネットワーク外の外部サーバを仮想的なホームネットワーク機器としてマッピングし、マッピング情報を適用して外部サーバの提供するコンテンツ提供サービスの受領処理を実行する。さらに、外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行する。

Description

本発明は、情報処理装置、および情報処理方法、並びにコンピュータ・プログラムに関する。特に、ホームネットワーク内の機器においてホームネットワーク外からの供給データの利用を実現する情報処理装置、および情報処理方法、並びにコンピュータ・プログラムに関する。

ＰＣ，デジタル家電の普及のともない、ホームＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）ネットワークを介してそれら機器を相互接続し、ビデオ、オーディオ、写真などのデジタルコンテンツを共有して楽しむことが現実のものとなってきている。例えば、ＤＬＮＡ（ＤｉｇｉｔａｌＬｉｖｉｎｇＮｅｔｗｏｒｋＡｌｌｉａｎｃｅ）ではそれらデジタル機器がデジタルコンテンツの共有をおこなううえでの必要な技術仕様、実装ガイドラインを定め、異なるベンダーの機器同士でも相互に接続することができ、ホームＩＰネットワークの業界標準となっている。

図１にＤＬＮＡの提案するホームネットワーク１００の例を示す。デジタルビデオコンテンツの記録装置としてのＤＶＲ（ＤｉｇｉｔａｌＶｉｄｅｏＲｅｃｏｒｄｅｒ）１０１と、ＴＶチューナを内蔵したＰＣ１０２は衛星、地上波のアナログ放送やデジタル放送を受信可能であり、放送番組を内蔵のハードディスクレコーダに記録保存する。ＤＬＮＡではコンテンツを蓄積し、ホームネットワーク内の機器に対してコンテンツの提供を行なう機器をデジタルメディアサーバ（ＤＭＳ：ＤｉｇｉｔａｌＭｅｄｉａＳｅｒｖｅｒ）と呼ぶ。図１では、ＤＶＲ１０１，ＰＣ１０２がＤＭＳである。

ＤＭＳは例えばハードディスクに記録されたＴＶ番組のビデオコンテンツを、ホームＩＰネットワークを介して接続されたデジタルメディアプレーヤ（ＤＭＰ：ＤｉｇｉｔａｌＭｅｄｉａＰｌａｙｅｒ）にストリーミング伝送することができる。デジタルメディアプレーヤ（ＤＭＰ）は、ＤＭＳからコンテンツを受領して再生する機器である。

図１の例ではＴＶ１０３にＤＭＰが実装されており、ユーザは、例えばＴＶ１０３の赤外線リモコンなどを利用して、ＴＶ１０３を操作することにより離れた部屋に置かれたＰＣ１０２や、ＤＶＲ１０１に蓄積されたビデオコンテンツを再生可能となる。なお、レジデンシャルゲートウェイ（ＲＧ：ＲｅｓｉｄｅｎｔｉａｌＧａｔｅｗａｙ）１０４は家庭内の機器がインターネットとしてのＩＰブロードバンドネットワーク１２０に接続する場合のネットワーク接続機器として利用されるが、ＤＬＮＡの利用例では家庭内の機器がＩＰ接続するためのブリッジとして利用されている。

一方、放送システムも変革が見られ、従来、地上波や衛星を使って放送していたビデオコンテンツをＩＰブロードバンドネットワーク経由で伝送するＩＰＴＶサービス、ＶＯＤ（ＶｉｄｅｏＯｎＤｅｍａｎｄ）サービスなどが商用化され始めてきている。図２にＩＰＴＶ，ＶＯＤサービスの概念図を示す。

家庭内にはＳＴＢ（ＳｅｔＴｏｐＢｏｘ）１０５が設置されＲＧ（ＲｅｓｉｄｅｎｔｉａｌＧａｔｅｗａｙ）１０４を介してＩＰブロードバンドネットワーク１２０を介して様々なＩＰＴＶサービス提供サーバ１２１ａ１〜ａｎ、ＶＯＤサービス提供サーバ１２２ｂ１〜ｂｎからのサービスに基づくコンテンツを受信することができる。ＳＴＢ（ＳｅｔＴｏｐＢｏｘ）１０５は、映像情報の受信機能や、コマンド送受信、ＭＰＥＧデコード、その他受信データの再生に必要となるアプリケーション実行機能などを有する。

レジデンシャルゲートウェイ（ＲＧ）１０４は、複数のＩＰＴＶサービス提供サーバ１２１や、ＶＯＤサービス提供サーバ１２２の提供サービス（コンテンツ）を同一の業者、たとえば、電話会社やＣａｂｌｅＴＶの会社などのアクセスライン提供会社を介して受信する場合と、それぞれのサービスをそれぞれ個別に受信する場合がある。ただし、ユーザが利用するＳＴＢ（ＳｅｔＴｏｐＢｏｘ）１０５自体は接続先のＩＰＴＶサービスに対応したシステムとして構成されることが必要である。

このようなＩＰＴＶサービスやＶＯＤサービスが今後普及してくると、従来、一般的なブロードキャスト放送としてのＴＶ放送コンテンツをＤＬＮＡ機器で共有して視聴していたのと同様に、ＩＰＴＶサービスから提供されるビデオコンテンツについてもＤＬＮＡ機器で利用したいというユーザの要求が起きてくる。

このような要請を実現するための解決案として、ホームサーバのような大容量のハードディスクを持った機器が、ＩＰＴＶサービスからのビデオコンテンツをダウンロードしてホームネットワーク内で共有する方法や、ＩＰＴＶサービスのプロトコル、メディアフォーマットなどをレジデンシャルゲートウェイ（ＲＧ）においてＤＬＮＡ機器のプロトコル、メディアフォーマットに変換して、ホームネットワーク接続機器に提供するといった手法が考えられる。なお、フォーマット変換処理を実行するホームネットワーク組み込みモジュールについては特許文献１に記載がある。

しかしながら、前者の場合は、ホームサーバへの一時蓄積のためダウンロードの時間が必要となり、ビデオオンデマンドサービスのように好きなときにビデオを楽しむということが困難となり、ライブ視聴には向かない。後者のレジデンシャルゲートウェイ（ＲＧ）に処理を行なわせる構成では、レジデンシャルゲートウェイ（ＲＧ）がプロトコル変換、メディアフォーマット変換を行うことが必要であり、高性能なハードウェアが必要となるし、ソフトウェアも複雑になるためＲＧが高価ものとなる。

一般的にＲＧはブロードバンドネットワークのアクセスライン提供会社（電話会社など）から供給される場合が多く、ユーザの利用可能なＩＰＴＶサービスはアクセスラインが提供するベンダーに限定されるなど、オープンなインターネット上でＩＰＴＶサービスを行う場合の妨げとなる。新たなゲートウェイ機器をレジデンシャルゲートウェイ（ＲＧ）とは別にホームＩＰネットワークに設けることも可能であるが、この場合はネットワークトポロジーによっては、コンテンツのストリーミングのデータがホームネットワークで重複して伝送されることになり、ホームネットワーク内で帯域を無駄に使ってしまうといったことが発生する。

なお、ホームネットワークのＤＬＮＡ機器とインターネットのコンテンツ配信サービスの接続例として米国Ｉｎｔｅｌ社のＶｉｉｖ（登録商標）テクノロジがある。ＶｉｉｖはＰＣのハードウェア、ソフトウェアのプラットフォームと位置づけられＤｕａｌＣｏｒｅの高性能ＣＰＵによってインターネットからのコンテンツをＰＣでストリーミング視聴することを目的としているが、同時に、ＤＬＮＡ機能も有し、インターネットから一旦、ＰＣにダウンロードしたコンテンツをホームネットワークに接続された他のＤＬＮＡ機器にストリーミングするＤＬＮＡメディアサーバ（ＤＬＮＡＭｅｄｉａＳｅｒｖｅｒ）となる。
特表２００５−５３１２３１号公報

上述したように、一般的なブロードキャスト放送としてのＴＶ放送コンテンツと同様に、ＩＰＴＶサービス、ＶＯＤサービスの提供コンテンツもＤＬＮＡ機器で利用しようとする場合、これまでのホームネットワーク構成では、ホームネットワーク内のＰＣ、ＤＶＲなどのデジタルメディアサーバ（ＤＭＳ）において、予めコンテンツをダウンロードしておくか、あるいは、レジデンシャルゲートウェイ（ＲＧ）にプロトコル、メディアフォーマット変換機能を持たせるといったことが必要となり、前者の場合は、リアルタイム性に欠け、ストリーミング再生処理などに不適であり、後者の場合は、コスト高を招くといった問題があった。

本発明は、このような問題点に鑑みてなされたものであり、例えば、インターネットへのアクセスラインやゲートウェイなどのインフラに依存しない、オープンなインターネット接続環境において、既存のＤＬＮＡ機器を適用してＩＰＴＶサービスなどのホームネットワーク外の外部サーバの提供するコンテンツを視聴可能とする情報処理装置、および情報処理方法、並びにコンピュータ・プログラムを提供することを目的とする。

本発明の第１の側面は、
情報処理装置であり、
ホームネットワークを介した通信処理を実行する通信部と、
ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ提供サービスの受領処理を実行するデータ処理部を有し、
前記データ処理部は、
前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行する構成であることを特徴とする情報処理装置にある。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、管理サーバに予め格納済みのユーザプロファイルを取得し、取得したユーザプロファイルを前記外部サーバに提供する処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、情報処理装置において更新したユーザプロファイルを前記管理サーバに送信して、前記管理サーバに格納されたユーザプロファイルの更新処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたコンテンツリストを受信して表示部に表示する処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定された広告情報を受信して表示部に表示する処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたＶｏＤ（ビデオオンデマンド）対応コンテンツを受信して表示部に表示する処理を実行する構成であることを特徴とする。

さらに、本発明の情報処理装置の一実施態様において、記ユーザプロファイルは、ユーザの使用言語、国籍、年令、アドレス、電話番号、趣味嗜好情報の少なくともいずれかの情報を含む構成であることを特徴とする。

さらに、本発明の第２の側面は、
情報処理装置において実行する情報処理方法であり、
通信部が、ホームネットワークを介した通信処理を実行する通信ステップと、
データ処理部が、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ受信処理を実行するコンテンツ受信ステップと、
前記データ処理部が、前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信するコンテンツ制御処理ステップと、
を実行することを特徴とする情報処理方法にある。

さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法において、さらに、前記データ処理部は、管理サーバに予め格納済みのユーザプロファイルを取得し、取得したユーザプロファイルを前記外部サーバに提供する処理を実行することを特徴とする。

さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法において、さらに、前記データ処理部は、情報処理装置において更新したユーザプロファイルを前記管理サーバに送信して、前記管理サーバに格納されたユーザプロファイルの更新処理を実行することを特徴とする。

さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法において、さらに、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたコンテンツリストを受信して表示部に表示する処理を実行することを特徴とする。

さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法において、さらに、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定された広告情報を受信して表示部に表示する処理を実行することを特徴とする。

さらに、本発明の情報処理方法の一実施態様において、前記情報処理方法において、さらに、前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたＶｏＤ（ビデオオンデマンド）対応コンテンツを受信して表示部に表示する処理を実行することを特徴とする。

さらに、本発明の情報処理方法の一実施態様において、前記ユーザプロファイルは、ユーザの使用言語、国籍、年令、アドレス、電話番号、趣味嗜好情報の少なくともいずれかの情報を含むことを特徴とする。

さらに、本発明の第３の側面は、
情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
通信部に、ホームネットワークを介した通信処理を実行させる通信ステップと、
データ処理部に、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ受信処理を実行させるコンテンツ受信ステップと、
前記データ処理部に、前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信させるコンテンツ制御処理ステップと、
を実行させることを特徴とするコンピュータ・プログラムにある。

なお、本発明のコンピュータ・プログラムは、例えば、様々なプログラム・コードを実行可能な汎用コンピュータ・システムに対して、コンピュータ可読な形式で提供する記憶媒体、通信媒体によって提供可能なコンピュータ・プログラムである。このようなプログラムをコンピュータ可読な形式で提供することにより、コンピュータ・システム上でプログラムに応じた処理が実現される。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本発明の構成によれば、ホームネットワーク内のクライアント機器であるコンテンツ再生装置としてのＤＭＰが、ホームネットワーク外のコンテンツ提供サーバからのコンテンツを受領して再生することが可能となる。すなわち、本発明の情報処理装置であるホームＩＭＳゲートウェイが、コンテンツ提供サーバとの通信を実行して、コンテンツ提供サーバを仮想的なホームネットワーク機器としてマッピングし、ホームネットワーク内のコンテンツ再生装置からの機器発見要求の受信に応じてコンテンツ提供サーバのサーバ情報を、サービス受領可能な機器情報としてコンテンツ再生機器に提供する。さらに、外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行することが可能となる。

ＤＬＮＡの提案するホームネットワークの例を示す図である。ＩＰＴＶ，ＶＯＤサービスの概念図を示す図である。本発明の情報通信システムの一構成例について説明する図である。ＤＬＮＡ機器が準拠するＤＬＮＡガイドラインの機能コンポーネントについて説明する図である。ホームＩＭＳゲートウェイのハードウェア構成例を示す図である。ホームＩＭＳゲートウェイのソフトウェアモジュールの一構成例について説明する図である。ＡＳ（ＩＰＴＶ）の加入手続きのシーケンスについて説明する図である。ＡＳ（ＩＰＴＶ）の加入手続きのシーケンスについて説明する図である。ＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスの一例について説明する図である。ＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスの一例について説明する図である。コンテンツ利用処理におけるデータ通信の全体概要について説明する図である。ホームＩＭＳゲートウェイのソフトウェアモジュールの一構成例について説明する図である。ＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスの一例について説明する図である。ＡＳ（ＩＰＴＶ）の提供するサービス画面およびストリーミング再生処理時における画面表示例について説明する図である。ＩＰＴＶサービスを受領するために必要とする機能であるＩＰＴＶターミナル機能の構成要素ついて説明する図である。ＩＭＳ（ＩＰマルチメディアサブシステム）の主要機能であるＣＳＣＦ、ＨＳＳ、ＡＳについて説明する図である。ＩＰＴＶサービスをホームネットワーク内の機器において受領するためにネットワーク構成において利用される機能について説明する図である。通信データの品質管理処理について説明する図である。クライアントがＩＰＴＶサービスを受領するために実行する通信シーケンスについて説明する図である。クライアントがＩＰＴＶサービスを受領するために実行する通信シーケンスついて説明する図である。クライアントがＩＰＴＶサービスを受領するために実行する通信シーケンスついて説明する図である。クライアントがＩＰＴＶサービスを受領するために実行する通信シーケンスついて説明する図である。クライアントがＩＰＴＶサービスを受領するために実行する通信シーケンスついて説明する図である。ＩＰＴＶサービスを受領するためのクライアントのネットワーク接続処理シーケンスについて説明する図である。ＩＰＴＶサービスを受領するためのクライアントのネットワーク接続処理シーケンスについて説明する図である。ＩＰＴＶサービスを受領するためのクライアントのネットワーク接続処理シーケンスについて説明する図である。

以下、図面を参照しながら、本発明の情報処理装置、および情報処理方法、並びにコンピュータ・プログラムの詳細について説明する。説明は以下の項目について、順次行なう。
１．ホームネットワーク内機器によるＩＰＴＶサービスの受領構成
２．ＩＰＴＶサービスに適用する機能の説明
３．ＩＰＴＶサービスの具体的処理例について
３−１．通信処理の具体的処理例について
３−２．各種サービスの具体的処理例について

［１．ホームネットワーク内機器によるＩＰＴＶサービスの受領構成］
まず、図３を参照して、本発明の情報通信システムの一構成例について説明する。ＩＰＴＶサービスのシステムとしては、米国マイクロソフト社などさまざまなベンダーが開発、商用化しているが、本実施例ではＩＰマルチメディアサブシステム（ＩＭＳ：ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍ）を利用したＩＰＴＶサービスのアーキテクチャを用いた例について説明する。

ＩＭＳは、元来、携帯電話の無線通信インフラにおいて音声による電話サービスにおいて、例えば３台以上の複数の携帯電話による会話を実現するプッシュ・トゥー・トーク（ｐｕｓｈｔｏｔａｌｋ）会議システム、インスタントメッセージのようなコミュニケーション、さらに、マルチメディアの付加サービスを提供するための基盤技術として、第３世代移動体通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）で開発されている。

ＩＭＳはＩＰ技術をベースとしており、固定通信系のインターネットのインフラとの親和性が高く、ＦＭＣ（ＦｉｘｅｄＭｏｂｉｌｅＣｏｎｖｅｒｇｅｎｃｅ）と呼ばれる有線、無線の通信ネットワークインフラをＩＰにて統合する動向もあり、その中で、ＩＭＳを利用したＩＰＴＶのシステムは注目されている。

ＩＭＳはＩＥＴＦ（ＴｈｅＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）のＲＦＣ−３２６１で規定されるＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づくＣＳＣＦ（ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）と呼ばれる機能要素を核として、ホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）、アプリケーションサーバ（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）などの機能要素から構成される。

図３に示すＩＭＳネットワーク２３０は、これらの各機能要素としてのＣＳＣＦ２３１、ＨＳＳ２３２、ＡＳ（ＩＰＴＶ）２３３を有しており、モバイルフォンネットワーク２４０を介して携帯電話２６０に対するサービスを提供する。

ＣＳＣＦ２３１は、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づき、ユーザの登録やセッション設定の制御を行なう。さらに、ＨＳＳ２３２に登録されているユーザプロファイルの設定に従い、必要なサービス処理の起動を実行する。ＨＳＳ２３２は、ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースを有する。ＡＳ２３３は、個々のサービスの処理を実行するサーバであり、各ユーザのサービス加入状況に応じてＣＳＣＦ２３１によって起動され、ユーザに対するサービス提供を行なう。

このようにＩＭＳでは、ユーザＩＤが設定された端末はＣＳＣＦ２３１をアクセスして端末の登録、セッションの設定制御を行い、ＨＳＳ２３２に登録されたユーザプロファイルに設定に従って必要なサービスの起動を行い、ＡＳ２３３は実際に個々のサービスの処理を行う。

例えば、ＩＭＳを利用したサービスの代表例としては、「ＰｕｓｈＴｏＴａｌｋ」がある。「ＰｕｓｈＴｏＴａｌｋ」では、ユーザ端末は、ＩＭＳネットワーク２３０の「ＰｕｓｈＴｏＴａｌｋ」サービスを実行するアプリケーションサーバ（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）ＡＳと接続し、登録済のグループメンバーに対してＡＳから複数メンバーとのセッションを確立し、ＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩＰ）を使って中継サーバ経由でメンバー間の通話を行う構成となっている。

ＩＰＴＶの視聴サービスにおいては、ＩＭＳネットワーク２３０に設定されたＩＰＴＶサービスのＡＳが利用される。図３に示すＡＳ（ＩＰＴＶ）２３３は、このＩＰＴＶサービスの実行ＡＳに相当する。ＡＳ（ＩＰＴＶ）２３３は実際にはＩＰＴＶサービス（ＩＰＴＶＳｅｒｖｉｃｅ）の実行主体、すなわち、コンテンツの提供主体としてのＩＰＴＶサービス２５０と連携してユーザ端末に対するサービスを実行することになる。

ＩＰＴＶサービス２５０は、コンテンツリスト等の番組情報ガイドであるＥＰＧ（ＥｌｅｃｔｒｏｎｉｃＰｒｏｇｒａｍＧｕｉｄｅ（電子プログラムガイド））の提供サーバであるＥＰＧサーバ２５１と、映像コンテンツの提供サーバであるビデオサーバ２５２を有し、それぞれのサーバとＩＭＳネットワーク２３０のＡＳ（ＩＰＴＶ）２３３との連携によって、ユーザ端末に対するコンテンツリストの提供サービス、コンテンツの提供サービスを実現している。

本発明のシステムにおいて、ホームネットワーク２１０は、基本構成としては、先に、図１、図２を参照して説明した従来型のホームネットワーク、すなわち、既存のＤＬＮＡ（ＤｉｇｉｔａｌＬｉｖｉｎｇＮｅｔｗｏｒｋＡｌｌｉａｎｃｅ）機器によって構成される。図３には、ホームネットワーク内の機器がＩＰブロードバンドネットワーク２２１に接続するネットワーク接続機器でありブリッジとして利用されるレジデンシャルゲートウェイ（ＲＧ：ＲｅｓｉｄｅｎｔｉａｌＧａｔｅｗａｙ）２１１と、ホームネットワーク２１０内の機器（例えばＴＶ（ＤＭＰ）２１３などのコンテンツ再生機器）に対して、ホームネットワーク外のサーバの提供サービスの利用を可能とするための処理を実行するホームＩＭＳゲートウェイ２１２と、コンテンツを受領して再生するクライアント機器であるデジタルメディアプレーヤ（ＤＭＰ：ＤｉｇｉｔａｌＭｅｄｉａＰｌａｙｅｒ）としてのＴＶ２１３を示している。

ブロードバンドＩＰネットワーク２２０は、ＩＰＴＶサービス２５０、ＩＭＳネットワーク２３０、ホームネットワーク２１０の相互通信を可能とするインターネット等のネットワークである。

なお、本発明のシステムでは、ホームＩＭＳゲートウェイ２１２が、ＩＭＳネットワークのサービスを受領する端末として設定される。ホームＩＭＳゲートウェイ２１２にはＩＭＳのユーザＩＤが設定される。すなわち、ホームＩＭＳゲートウェイ２１２のユーザＩＤおよびユーザプロファイルが、ＩＭＳネットワーク２３０のホームサブスクライバサブシステム（ＨＳＳ）２３２に登録される。

ホームＩＭＳゲートウェイ２１２は、携帯電話２６０がＩＰＴＶサービスを実行する場合と同様の処理を実行することで、ＩＰＴＶのサービスを受領する。すなわち、ＣＳＣＦ２３１をアクセスして端末の登録、セッションの設定制御を行い、ＨＳＳ２３２に登録されたユーザプロファイルに設定に従って必要なサービスの起動を行い、ＡＳ（ＩＰＴＶ）２３３を利用したサービス受領を行う。ホームＩＭＳゲートウェイ２１２は、このようなＩＭＳのサービスと接続するという機能の他、ＩＰＴＶサービス２５０が提供するビデオコンテンツにＤＬＮＡ機器、例えば図に示すＴＶ（ＤＭＰ）２１３がアクセスするためのゲートウェイの機能を実行する。すなわち、ホームＩＭＳゲートウェイ２１２は、
（ａ）ＩＭＳのサービスとの接続機能
（ｂ）ゲートウェイ機能
これらの機能を保持する。これらの機能は、ネットワーク通信機能と基本的な情報処理装置構成およびソフトウェアを用いて実現される機能であり、ホームＩＭＳゲートウェイ２１２は、ネットワーク通信機能を持つ既存のホームＩＰネットワークに接続された様々な機器に実装することが可能である。

なお、ホームＩＭＳゲートウェイ２１２がＩＰＴＶサービス２５０が提供するビデオコンテンツなどをＤＬＮＡ機器、例えば図に示すＴＶ（ＤＭＰ）２１３に対して中継する処理を実行する場合は、さらに、
（ｃ）コンテンツ提供処理を実行する機能としてのＤＭＳ機能
を有することになる。ただし、この機能は、必須ではなく、コンテンツの送受信は、ホームＩＭＳゲートウェイ２１２を介することなく、ＤＬＮＡ機器としてのＤＭＰと外部サーバとの間の通信によって実行する構成も可能であり、この場合は、ホームＩＭＳゲートウェイ２１２はＤＭＳ機能を持つ必要がない。これらの具体的な処理構成については後述する。

ホームネットワーク内に、ＩＭＳネットワークのサービス受領機能を持つホームＩＭＳゲートウェイ２１２を設定することにより、既存のＤＬＮＡ機器（例えば図に示すＴＶ（ＤＭＰ）２１３）は、ホームネットワーク内のＤＭＳ、すなわち、ホームＩＭＳゲートウェイ２１２からコンテンツ提供を受けるとほぼ同様の処理で、ＩＰＴＶのビデオコンテンツを受領することが可能となる。

ホームネットワーク内のクライアント機器であるＴＶ（ＤＭＰ）２１３は、ホームネットワーク外の機器からのコンテンツ提供処理として実行されるＩＰＴＶサービスを、ホームネットワーク内のＤＭＳ、すなわち、ホームＩＭＳゲートウェイ２１２からコンテンツ提供を受けると同様のコンテンツ利用処理によって実行可能となる。

ホームＩＭＳゲートウェイ２１２は、ＤＬＮＡ機器におけるコンテンツ提供サーバとしてのＤＭＳ（ＤｉｇｉｔａｌＭｅｄｉａＳｅｒｖｅｒ）機能を実装しており、ＤＭＰ（ＤｉｇｉｔａｌＭｅｄｉａＰｌａｙｅｒ）が実装されたＴＶ２１３からホームＩＭＳゲートウェイ２１２へアクセスが行われ、ＩＭＳゲートウェイ２１２は、ＩＭＳネットワーク２３０を介して受領するＩＰＴＶサービスをＴＶ２１３に提供することができる。

前述したように、ホームＩＭＳゲートウェイ２１２は、ネットワーク通信機能を持つ既存のホームＩＰネットワークに接続された様々な機器に実装することが可能である。例えば、ネットワーク回線の提供業者である電話会社やケーブルＴＶ会社などのアクセスラインのベンダーから供給されるレジデンシャルゲートウェイ（ＲＧ：Ｒｅｓｉｄｅｎｔｉａｌ）にＩＭＳネットワークサービス受領機能を実装させることも可能である。この場合、図３に示すＲＧ２１１とホームＩＭＳゲートウェイ２１２は一体化される。

あるいは、先に図１を参照して説明した従来型のホームネットワーク構成において、コンテンツの提供を行なう機器をデジタルメディアサーバ（ＤＭＳ）として機能するＤＶＲ（ＤｉｇｉｔａｌＶｉｄｅｏＲｅｃｏｒｄｅｒ）やＰＣにＩＭＳネットワークサービス受領機能を実装させることも可能である。

このように、本発明の構成では、ＩＭＳネットワークサービス受領機能の実装可能な機器が限定されることがないため、オープンなインターネットでのＩＰＴＶサービスへの対応が可能となり、また、ネットワークトポロジーについても限定されることなく、任意のホームネットワーク構成に対応可能となる。

以下、ホームＩＭＳゲートウェイの構成例およびホームＩＭＳゲートウェイを利用したＩＰＴＶサービスの受領処理について詳細に説明する。まず、ホームＩＭＳゲートウェイの説明に先立ち、ＤＬＮＡ機器が準拠するＤＬＮＡガイドラインの機能コンポーネントについて、図４を参照して説明する。

図４にＤＬＮＡのガイドラインの機能コンポーネントを示す。上段から、メディアフォーマット層（ＭｅｄｉａＦｏｒｍａｔ）、メディア転送層（ＭｅｄｉａＴｒａｎｓｐｏｒｔ）、デバイスディスカバリ制御及びメディア制御層（ＤｅｖｉｃｅＤｉｓｃｏｖｅｒｙ，Ｃｏｎｔｒｏｌ，ａｎｄＭｅｄｉａＭａｎａｇｅｍｅｎｔ）、ネットワーク層（ＮｅｔｗｏｒｋＳｔａｃｋ）、ネットワーク接続層（ＮｅｔｗｏｒｋＣｏｎｎｅｃｔｉｖｉｔｙ）の各構成が定義されている。ホームネットワークの機器（ＤＬＮＡ機器）は、この図４に示す基本コンポーネントに従ってＤＬＮＡ（Digital Living Network Alliance）のガイドラインに準拠したネットワークプロトコルに従ったデータ通信を実行する。

まず、最下層のネットワーク接続（ＮｅｔｗｏｒｋＣｏｎｎｅｃｔｉｖｉｔｙ）はホームネットワークの物理層、リンク層の規定である。ＤＬＮＡ機器には、ＩＥＥＥ８０２．３ｕ，８０２．２１１ａ／ｂ／ｇ規格に従った通信機能が実装されるが、ホームネットワークのインフラとしてはＰＬＣ（Ｐｏｗｅｒｌｉｎｅｃｏｍｍｕｎｉｃａｔｉｏｎ）などＩＰ接続が可能な構成であれば、通信規格が限定されることはない。

ネットワーク層はＩＰｖ４のプロトコルが利用され、ＴＣＰ，ＵＤＰを利用して各ＤＬＮＡ機器は通信を行う。デバイスディスカバリ制御及びメディア制御層に規定されるＵＰｎＰ（登録商標）ＤｅｖｉｃｅＡｒｃｈｉｔｅｃｔｕｒｅ１．０では機器発見のＳＳＤＰ（ＳｉｍｐｌｅＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙＰｒｏｔｏｃｏｌ）や制御を行うＳＯＡＰ（ＳｉｍｐｌｅＯｂｊｅｃｔＡｃｃｅｓｓＰｒｏｔｏｃｏｌ）などが規定されており、ＵＰｎＰＤＡ（ＵＰｎＰＤｅｖｉｃｅＡｒｃｈｉｔｅｃｔｕｒｅ）の上にＵＰｎＰＡＶが実装される。ＵＰｎＰＡＶバージョン１はＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）と、ＵＰｎＰメディアレンダラー（ＵＰｎＰＭｅｄｉａＲｅｎｄｅｒｅｒ）を規定しているが、ＤＬＮＡ規定のコンテンツ提供サーバであるＤＭＳは、ＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）を実装し、ＤＬＮＡ規定のコンテンツ再生機器であるＤＭＰは、ＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）のコントローラを実装する。

ＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）には、主となるコンテンツディレクトリサービス（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）が実装され、コンテンツリストおよびメタデータの取得方法が提供される。コンテンツディレクトリサービス（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）を利用することで、ＤＬＮＡ規定のコンテンツ再生機器であるＤＭＰは、ＤＬＮＡ規定のコンテンツ提供サーバであるＤＭＳがストリーミングするコンテンツリストの取得を行う。

次の上位層であるメディア転送（ＭｅｄｉａＴｒａｎｓｐｏｒｔ）層の規定として、ストリーミング再生にＨＴＴＰ１．０／１．１が利用されることが規定されている。メディアフォーマットとしては、ビデオコンテンツであれば、ＤＬＮＡが規定したＭＰＥＧ２−ＰＳのプロファイルに従ったＭｅｄｉａＦｏｒｍａｔｓのコンテンツがＤＭＳからＤＭＰに対してストリーミング転送行われることが規定されている。ＤＬＮＡ規定のコンテンツ再生機器であるＤＭＰは、例えばストリーミング伝送により受信したＭＰＥＧ２−ＰＳデータを、順次デコードして再生を行うことでユーザはコンテンツを視聴することができる。

図３を参照して説明したホームＩＭＳゲートウェイ２１２のハードウェア構成例を図５に示す。先に説明したように、ホームＩＭＳゲートウェイ２１２は、
（ａ）ＩＭＳのサービスとの接続機能
（ｂ）ゲートウェイ機能
これらの機能を保持するが、これらの機能は、ネットワーク通信機能と基本的な情報処理装置構成およびソフトウェアで実現される。図５に示すハードウェアは、これら（ａ）〜（ｂ）の機能を実現するハードウェア構成例を示している。

ホームＩＭＳゲートウェイ２１２は、図５に示すように、各種ソフトウェア（コンピュータ・プログラム）を実行するデータ処理部としてのＣＰＵ３０１、プログラムの格納領域としてのＲＯＭ、データ処理実行時のワークエリア等に利用されるＲＡＭなどによって構成されるメモリ３０２、ネットワーク接続部としてのネットワークＩ／Ｆ３０３、さらにこれらの各構成部間のコマンド、データ転送用のバス３０４によって構成される。

ネットワークＩ／Ｆ３０３は、例えば、ＩＥＥＥ８０２．３ｕのような有線ＬＡＮのネットワークＩ／Ｆであり、ＯＳおよびその他ソフトウェアプログラムは、メモリ３０２を構成するＦｌａｓｈ−ＲＯＭに格納されており、これらのプログラムは、メモリ３０２を構成するＲＡＭにコピーされて実行される。また、ＩＭＳのセッション確立処理において必要となるユーザＩＤや各種設定情報もメモリ３０２を構成するＦｌａｓｈ−ＲＯＭに保存される。

次に、図６を参照してホームＩＭＳゲートウェイ２１２のソフトウェアモジュールの構成例について説明する。ソフトウェアモジュールは、図に示すように、
（１）ネットワークモジュール
（２）プロトコルモジュール
（３）アプリケーションモジュール
の３つに分類される。

（１）ネットワークモジュールは、ＩＰネットワークにおける通信制御を担当するモジュールである。
（２）プロトコルモジュールは、ＩＭＳ，ＤＬＮＡの各機能、すなわちＩＭＳ側ではＩＭＳ側で規定されるプロトコルに従った通信を実行するための制御を行い、ＤＬＮＡ側ではＤＬＮＡ側で規定されるプロトコルに従った通信を実行するための制御を行うプロトコル制御を担当するモジュールである。ＩＭＳ側とＤＬＮＡ側では異なるプロトコルに従った通信が実行されるため、異なるプロトコルに対応した構成を持つ。
（３）アプリケーションモジュールは、プロトコルモジュールを利用して実際のゲートウェイ機能、すなわちホームネットワーク側のＤＬＮＡ側とホームネットワーク外のネットワークであるＩＭＳネットワークの中継を実現するモジュールである。

図においては、ホームネットワーク側のＤＬＮＡ側と、ホームネットワーク外のネットワークであるＩＭＳネットワークにおいて利用される機能区分を分かりやすくするため、破線で領域区分を行い、破線の左側にＩＭＳ／ＩＰＴＶ側で適用するソフトウェアモジュールを示し、右側にＤＬＮＡ側で適用するソフトウェアモジュールを示している。ただし、ネットワークモジュールについては、両ネットワークにおいて共通に利用される。以下、各モジュールの詳細について説明する。

まず、ネットワークモジュールはＩＰｖ４ＴＣＰ／ＩＰスタックとＵＰｎＰＤＡに規定されるＩＰアドレス設定処理を行なうためのＡｕｔｏＩＰ／ＤＨＣＰ（Dynamic Host Configuration Protocol）Ｃｌｉｅｎｔモジュールが実装される。ネットワークモジュールはＩＭＳ，ＤＬＮＡとも同じものが利用可能である。

ホームＩＭＳゲートウェイ２１２は、基本的に、ホームＩＰネットワークに接続されていればよいので、ネットワークＩ／Ｆも別々に設定することは必須とはならない。ただし、レジデンシャルゲートウェイと一体化した構成とする場合などには、ホームネットワーク接続Ｉ／Ｆと外部ネットワーク接続Ｉ／Ｆとを別構成としてもよい。

プロトコルモジュールは、ホームネットワーク側のＤＬＮＡ側と、ホームネットワーク外のネットワークであるＩＭＳネットワークにおいて利用されるプロトコルが、現状では異なっているため、それぞれのプロトコルに対応した個別の設定となる。
ＤＬＮＡ側はＵＰｎＰＤＡで規定するＳＯＡＰ，ＧＥＮＡ（ＧｅｎｅｒｉｃＥｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＡｒｃｈｉｔｅｃｔｕｒｅ），ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）サーバによるＰｒｅｓｅｎｔａｔｉｏｎＰａｇｅ，ＤｅｖｉｃｅＤｅｓｃｒｉｐｔｉｏｎのモジュールと、機器発見処理としてのＤｅｖｉｃｅＤｉｓｃｏｖｅｒｙを司るＳＳＤＰ，それとホームネットワーク内でコンテンツを実装するために必要とされるＤＴＣＰ−ＩＰ（ＤｉｇｉｔａｌＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｅｎｔＰｒｏｔｅｃｔｉｏｎ − ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）の認証および鍵交換（ＡＫＥ：ＡｕｔｈｅｎｔｉｃａｔｉｏｎａｎｄＫｅｙＥｘｃｈａｎｇｅ）を実行するＡＫＥモジュールにより構成される。

ＩＭＳ側はＩＭＳのサービス提供サーバであるＡＳ（ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）とのセッション確立を行うＳＩＰ／Ｍｏｄｕｌｅと、ＡＳとのメッセージ通信を行うＳＯＡＰ，ＧＥＮＡのモジュールにより構成される。また、ＩＭＳ側はオープンなインターネットでの通信を想定しているため、セキュリティのためにＩＥＴＦＲＦＣ２２４６で規定されるところのＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）プロトコル上にＳＩＰ，ＳＯＡＰなどの通信実行プロトコルが実装され、セキュアな環境下での通信が実行されるプロトコル設定となっている。

本発明の情報処理装置であるホームＩＭＳゲートウェイ２１２の特徴の１つは、ＤＬＮＡ側機器において利用される機器発見処理機能としてのＤｅｖｉｃｅＤｉｓｃｏｖｅｒｙＣｏｎｔｒｏｌと呼ばれる機能を利用して、ＩＭＳのＡＳ（ＩＰＴＶサービス）をＵＰｎＰデバイス（ＵＰｎＰＤｅｖｉｃｅ）としてマッピングする処理を実行する構成を持つことである。すなわち、ホームＩＭＳゲートウェイ２１２は、ホームネットワーク外のサーバを仮想的なホームネットワーク機器としてマッピングする。具体的には、ホームＩＭＳゲートウェイ２１２は、ホームＩＭＳゲートウェイ２１２にアプリケーションモジュールとして設定されるＵＰｎＰＤｅｖｉｃｅＰｒｏｘｙＭａｎａｇｅｒ（図６参照）などを利用して、外部サーバであるＡＳ（ＩＰＴＶ）に対応するＵＰｎＰＭｅｄｉａＳｅｒｖｅｒインスタンスを生成してメモリに記録する。

このように、ホームＩＭＳゲートウェイ２１２は、ホームネットワークには存在しない外部機器であるＩＭＳのＡＳ（ＩＰＴＶサービス）をＤＬＮＡのＤＭＳとしてマッピングして設定する。この処理は、ＩＭＳのＡＳ（ＩＰＴＶサービス）が、あたかもホームネットワーク内にある１つのコンテンツ提供サーバ（ＤＭＳ）であるように設定する処理である。

このマッピング処理によって、ホームネットワーク内のＤＬＮＡ機器、例えばＴＶなどのコンテンツ再生実行機器としてのＤＭＰがＵＰｎＰに従った機器発見処理を実行した場合、ホームＩＭＳゲートウェイ２１２は、ＡＳ（ＩＰＴＶ）に対応するＵＰｎＰＭｅｄｉａＳｅｒｖｅｒインスタンスに基づくサービス提供機能を持つことをＤＭＰに通知することが可能となり、ＤＭＰはこの通知に基づいて、ＩＭＳのＡＳ（ＩＰＴＶサービス）を、ホームネットワーク内のコンテンツ提供サーバ（ＤＭＳ）と同様の機器として認識することが可能となり、ホームネットワーク内からのコンテンツ提供に基づくサービス受領と同様の処理で、外部ネットワークであるＩＭＳのＡＳ（ＩＰＴＶサービス）のサービスを受領することが可能となる。

なお、本発明の情報処理装置であるホームＩＭＳゲートウェイ２１２は、ホームネットワーク内のコンテンツ再生実行機器としてのＤＭＰに対して、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継処理を行なう構成とするか否かは任意の設定が可能である。コンテンツの中継を行なうことなく、ＤＬＮＡ機器（コンテンツ再生実行機器としてのＤＭＰ）とＩＭＳのＡＳ（ＩＭＳ）のバックエンドのＶｉｄｅｏＳｅｒｖｅｒとの通信によってＤＭＰがコンテンツデータを外部ネットワークから直接取得する設定とすることが可能である。これらの具体的な処理例については後述する。

ホームＩＭＳゲートウェイ２１２が、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継を行なう場合は、ＭｅｄｉａＭａｎａｇｅｍｅｎｔと呼ばれる機能、例えば、コンテンツリストのメタデータの取得を行うＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスや、ＤＬＮＡのＭｅｄｉａＴｒａｎｓｐｏｒｔと呼ばれるビデオコンテンツの転送を行うプロトコルが実装されるが、ホームＩＭＳゲートウェイ２１２が、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継を行なわない構成においては、これらの機能、すなわち、ＭｅｄｉａＭａｎａｇｅｍｅｎｔ機能はホームＩＭＳゲートウェイ２１２に実装する必要がない。

また、ホームネットワーク内のクライアント機器、すなわち、コンテンツ再生実行機器としてのＤＭＰからのコンテンツリスト要求も、ホームＩＭＳゲートウェイ２１２が中継処理を行なわず、クライアント機器（ＤＭＰ）から直接ＡＳ（ＩＰＴＶサービス）等の外部サーバにコンテンツリスト要求を行わせる設定も可能であり、この構成では、ホームＩＭＳゲートウェイ２１２はクライアントからの機器発見要求に応答可能な構成であればよい。なお、クライアントからの要求をホームＩＭＳゲートウェイ２１２を経由させず、直接、外部サーバに送信させるためには、ＵＰｎＰのDevice Architectureにおいて規定されるデバイス情報［Device Description］の［controlURL］、［eventSubURL］の指定するＵＲＬをホームＩＭＳゲートウェイではなく、外部サーバのＵＲＬに設定することで実現される。ホームＩＭＳゲートウェイ２１２は、このような設定を持つデバイス情報［Device Description］をクライアント機器に提供することで、その後、クライアントがデバイス情報を参照してコンテンツリスト要求や、各種の要求を行う相手がＡＳ（ＩＰＴＶサービス）等の外部サーバに設定される。この場合はホームＩＭＳゲートウェイは機器発見のみの担当するモデルになり、さらに負荷が軽くなる。なお、ＵＰｎＰのDevice Architectureにおいて規定される機器情報取得のためのＵＲＬ［SCPDURL］についてもホームＩＭＳゲートウェイ２１２ではなく外部サーバのＵＲＬ設定とすることも可能である。

アプリケーションモジュールはプロトコルモジュールを利用してゲートウェイ機能、すなわち、ホームネットワーク内のＤＬＮＡ機器とホームネットワーク外のサーバとの通信環境の設定機能を実行する。アプリケーションモジュールは、大きく分けてＩＭＳのＡＳ（ＩＰＴＶ）サービスをＤＬＮＡのＤＭＳとして設定するマッピング処理を行うモジュール群と、マッピングされたＤＬＮＡのＤＭＳ（実体はＩＭＳのＡＳ（ＩＰＴＶ）サービス）に対して、例えばホームネットワーク内のコンテンツ再生機器であるＤＭＰから送信される要求を、ＩＭＳのＡＳ（ＩＰＴＶ）サービスに仲介するモジュール群である。

前者のマッピング処理を行うモジュール群は、ＡＳＤｉｓｃｏｖｅｒｙ，ＳｅｒｖｉｃｅＭａｎａｇｅｒ，ＵＰｎＰＤｅｖｉｃｅＰｒｏｘｙＭａｎａｇｅｒであり、後者の要求転送処理を実行するモジュールは、ＵＰｎＰＭｅｓｓａｇｅＰｒｏｘｙ，ＡＫＥＰｒｏｘｙである。

上述したように、本発明の情報処理装置であるホームＩＭＳゲートウェイ２１２は、ホームネットワークには存在しない外部機器であるＩＭＳのＡＳ（ＩＰＴＶサービス）をＤＬＮＡのＤＭＳとしてマッピングする処理を行なう。ホームＩＭＳゲートウェイ２１２は、さらに、このマッピング処理に際して、ユーザの選択したサービス主体［ＡＳ（ＩＰＴＶ）］のみを選択的にマッピングする機能を持つ。

すなわち、外部ネットワークに、ＩＭＳ／ＩＰＴＶのＡＳ（ＩＰＴＶ）が複数存在し、それぞれがコンテンツ提供を行なっている構成において、ユーザがＩＭＳの課金システムを利用して購買し選択したＡＳ（ＩＰＴＶ）のみを選択してＤＬＮＡのＤＭＳにマッピングする。

マッピング処理を行うアプリケーションモジュール中、図６に示すＩＭＳ／ＩＰＴＶ側のモジュールであるＡＳＤｉｓｃｏｖｅｒｙは、ＩＭＳシステムにより提供するＩＰＴＶサービスを発見する処理を実行し、ＤＬＮＡ側モジュールであるＵＰｎＰＤｅｖｉｃｅＰｒｏｘｙＭａｎａｇｅｒは、ＡＳＤｉｓｃｏｖｅｒｙによって発見、取得されたＡＳのリストを管理し、このリストをユーザに提示してＡＳ（ＩＰＴＶ）の購買や選択処理を実行させる。

具体的には、本発明の情報処理装置であるホームＩＭＳゲートウェイ２１２がＨＴＴＰサーバになり、ＵＰｎＰＤＡで規定されるＰｒｅｓｅｎｔａｔｉｏｎの仕組みを利用し、ＨＴＭＬブラウザ搭載のＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔと接続し、ユーザがブラウザ機能を利用して表示されたＨＴＭＬ画面から所望のＩＰＴＶサービスを選択し、サービスへの加入手続きを行う。具体的には、例えば、ホームネットワーク内のＤＬＮＡ機器として設定されたブラウザ機能を持つＰＣやＴＶを利用して、ホームＩＭＳゲートウェイ２１２の持つリストをディスプレイに提示してＩＰＴＶサービスの選択を行なうことができる。

さらに、このＩＰＴＶサービスの受領を受ける手続きにおいては、先に説明した要求転送処理を実行モジュールとしてのＵＰｎＰＭｅｓｓａｇｅＰｒｏｘｙを利用することで、ＩＭＳシステムが提供する課金システムを連携させることが可能であり、ホームＩＭＳゲートウェイ２１２に対応するＩＤとして設定済みのＩＭＳユーザＩＤの顧客情報からユーザに対する課金が行われる。

ホームＩＭＳゲートウェイ２１２は、このように、ユーザのＡＳ（ＩＰＴＶ）への加入手続を条件として、アプリケーションモジュールであるＵＰｎＰＤｅｖｉｃｅＰｒｏｘｙＭａｎａｇｅｒの処理によって、加入手続きのなされたＩＰＴＶサービスを選択してＤＬＮＡＤＭＳにマッピングするといった選択的なマッピングを行なうことが可能となる。ただし、無料コンテンツの提供を行なうＡＳ（ＩＰＴＶ）など加入手続きを行なうことが必要とされないＡＳ（ＩＰＴＶ）などがある場合は、ユーザの加入手続き処理が不要であり、マッピングの条件としてユーザ選択が必須となるものではない。

ホームネットワーク内のＤＬＮＡ機器であるコンテンツ再生機器としてのＤＭＰは、ホームＩＭＳゲートウェイ２１２においてマッピング処理の完了したＡＳ（ＩＰＴＶ）をホームネットワーク内のコンテンツ提供サーバ（ＤＭＳ）と解釈して、ＡＳ（ＩＰＴＶ）のサービスを受領することができるようになる。

アプリケーションモジュールであるＵＰｎＰＭｅｓｓａｇｅＰｒｏｘｙは、ＤＬＮＡＤＭＰより供給されたメッセージをＡＳ（ＩＰＴＶ）に中継する。このためのプロトコルとしてＵＰｎＰと同等のＳＯＡＰ，ＧＥＮＡが使われ、ＡＳはＵＰｎＰＡＶで規定されるところのＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ，ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスのメッセージを直接処理するか、もしくは、ＵＰｎＰＭｅｓｓａｇｅＰｒｏｘｙにおいてＡＳ（ＩＰＴＶ）のプロトコルの変換をおこなうなどして相互互換性を図る。

なお、図６に示すホームＩＭＳゲートウェイ２１２のソフトウェアモジュールの構成例は、ホームＩＭＳゲートウェイが、ＩＭＳ／ＩＰＴＶ側の通信プロトコルに従った通信と、ホームネットワーク内のＤＬＮＡ側の通信プロトコルに従った通信のいずれをも実行可能とし、ホームＩＭＳゲートウェイ２１２は、ＩＭＳ／ＩＰＴＶ側とＤＬＮＡ側との通信において必要に応じたプロトコル変換を実行する場合のソフトウェアモジュールの構成である。

通信プロトコルの変換処理は、ホームＩＭＳゲートウェイ２１２において行なう構成の他、例えば、ホームＩＭＳゲートウェイ２１２側と通信を直接実行する外部サーバ、例えばＩＭＳ側のＡＳやＩＰＴＶサービスの実行サーバにおいて実行する構成としてもよい。このように外部サーバにおいて、必要なプロトコル変換を実行する構成では、ホームＩＭＳゲートウェイ２１２は、ＤＬＮＡ側のプロトコルモジュール、アプリケーションモジュールを持てばよい。なお、このような構成とした場合、外部サーバのマッピング処理は、ＤＬＮＡ規定によるＳＳＤＰプロトコルに従った機器発見処理を実行することで実行される。

また、ホームネットワーク内のクライアント機器、すなわちコンテンツ再生実行機器としてのＤＭＰが実行するコンテンツリストおよびメタデータの取得処理においては、以下、説明する実施例では、ＡＳがＵＰｎＰＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙサービスを直接処理する方法をとっている。実施例ではＨＴＭＬブラウザを実装したＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔにてサービスの加入手続きを行うことにしているが、これはＤＬＮＡのＤＭＰであってもよいが、必ずしもＤＬＮＡのＤＭＰであることは必要でなく、第三者、例えば、パソコンのＨＴＭＬブラウザでも同様の処理が行える。また、携帯電話等がＨＴＭＬブラウザを実装している場合は同様に購入手続きが行える。

また、ホームＩＭＳゲートウェイ２１２自体が表示装置、入力部などのユーザインタフェースを持つ設定とすることにより、ユーザインタフェースにＡＳ（ＩＰＴＶ）から取得したリストを直接提示してユーザの入力情報を入力することが可能であり、ＨＴＭＬブラウザによる制御によらずともサービス加入の手続きを行うことができる。

なお、ＡＳ（ＩＰＴＶ）の加入手続の態様は様々な態様が可能である。すなわち、ＡＳ（ＩＰＴＶ）自体の選択としてのサービス単位の選択の他、ＡＳ（ＩＰＴＶ）の提供するコンテンツ単位の選択など、様々な設定が可能である。これらは、ＡＳ（ＩＰＴＶ）の設定に基づいてコンテンツ単位で購買を選択する仕組みをＰｒｅｓｅｎｔａｔｉｏｎＰａｇｅにより提供され、選択情報が、ユーザプロファイル情報の構成データとして、ＩＭＳ側に登録され、ＡＳ（ＩＰＴＶ）側は登録情報に従ったコンテンツ提供を行なうことになる。

上述したように、ホームＩＭＳゲートウェイ２１２は、ホームネットワーク内のコンテンツ再生実行機器としてのＤＭＰに対して、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継処理を行なう構成とする場合と、行わない構成とする場合のいずれの設定も可能であり、後者の場合、アプリケーションレベルでのサービスロジック処理、例えばＡＳ（ＩＰＴＶ）サービスの提供するサービスの解釈やＤＭＰの理解可能なフォーマットへの変換処理などの各サービスに対応したデータ処理が不要であり、また、コンテンツデータの一時保存や、変換処理も不要であるため、非常に安価なソフトウェア、ハードウェア構成の装置でホームＩＭＳゲートウェイを実現することができる。

ゲートウェイ装置がサービスロジック処理を不要とすることで、これらの処理を行う構成に比べて、サービスの拡張性を高くすることができる。例えば、コンテンツの提供主体であるＡＳ（ＩＰＴＶ）は、コンテンツのメタデータの追加などを行なうことがあるが、ゲートウェイ装置がサービスロジック処理を行なう構成では、ゲートウェイがその追加メタデータの解釈、処理を実行可能とするため、例えばプログラムの更新が必要となる。しかし、本発明のホームＩＭＳゲートウェイではこのような処理を行わない設定が可能であり、ゲートウェイ自体の変更を行なうことなく配信サービス側の変更のみで様々なサービスロジックの変更が可能となる。

前述したように、ホームＩＭＳゲートウェイ２１２の処理態様としては、
（１）ホームネットワーク内のコンテンツ再生実行機器（ＤＭＰ）に、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継処理を行なう構成、
（２）ホームネットワーク内のコンテンツ再生実行機器（ＤＭＰ）に、ＩＭＳのＡＳ（ＩＰＴＶサービス）の提供コンテンツの中継処理を行なわず、ＤＭＰとＡＳ（ＩＰＴＶサービス）間の通信によってコンテンツ再生を行なわせる構成、
これらの２つの構成があると説明した。

上記（２）のＤＭＰとＡＳ（ＩＰＴＶサービス）間の通信によってコンテンツ再生を行なわせる構成では、コンテンツ伝送はインターネット上のコンテンツ配信サービスから直接、再生機器であるＤＭＰに行われる。従って、ホームサーバに一時ダウンロードして家庭内に再配信する方式と異なり、オンデマンドにコンテンツ再生ができるためにユーザにとっても利便性が高い。さらに、このコンテンツ伝送を仲介しない方式では、ホームネットワーク内でコンテンツデータ伝送の重複がおきないために、無駄な帯域使用を防ぐことができる。また、ホームネットワークのトポロジーに制限がなくなり、ゲートウェイ機能を実装する商品形態が多様となるという利点がある。

以下、上記（２）の処理、すなわち、ＤＭＰとＡＳ（ＩＰＴＶサービス）間の通信によってコンテンツ再生を行なわせる場合の、処理シーケンスについて、図７〜図１０のシーケンス図を参照して説明する。なお、図７〜図１０のシーケンス図は、以下の各処理のシーケンスを説明する図である。
（Ａ）ＡＳ（ＩＰＴＶ）の加入手続きのシーケンス（図７，図８）
（Ａ１）ＩＭＳ登録処理
（Ａ２）機器発見処理
（Ａ３）ＡＳ（ＩＰＴＶ）選択処理
（Ｂ）ＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンス（図９，図１０）
（Ｂ１）機器発見処理
（Ｂ２）コンテンツリスト取得処理
（Ｂ３）認証、鍵交換処理
（Ｂ４）コンテンツストリーミング処理

まず、図７、図８を参照して、ＡＳ（ＩＰＴＶ）の加入手続きのシーケンスについて説明する。図７、図８は、左側から、
（１）ＩＭＳネットワークにおいてＩＰＴＶ対応のコンテンツ提供サービスを実行するアプリケーションサーバとしてＡＳ１，ＡＳ２，ＡＳ３の３つのＩＰＴＶサービス、
（２）ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースを持つＨＳＳ
（３）ＩＭＳネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づき、ユーザの登録やセッション設定の制御を行なうＣＳＣＦ、
（４）ホームＩＭＳゲートウェイ、
（５）ＵＰｎＰコントロールポイントとしてのＨＴＭＬブラウザ（ユーザインタフェース）
これらの各構成要素を示している。また、各ステップに示す［Ｃｘ］［ＳＩＰ］［ＳＳＤＰ］［ＨＴＴＰ］は各通信に適用されるプロトコルを示している。

図７、図８に示すＡＳ（ＩＰＴＶ）の加入手続きシーケンスは、以下の３つのフェーズに分けられる。
（Ａ１）ＩＭＳ登録処理
（Ａ２）機器発見処理
（Ａ３）ＡＳ（ＩＰＴＶ）選択処理
以下、各処理について説明する。

（Ａ１）ＩＭＳ登録処理
第１のフェーズであるＩＭＳ登録処理において、まず、ホームＩＭＳゲートウェイは、ステップＳ１１において、予めホームＩＭＳゲートウェイに設定されているＩＭＳユーザＩＤをＩＭＳネットワークのＣＳＣＦに送信し、ステップＳ１２において登録確認を受領してＩＭＳネットワークに対する登録を行う。次にステップＳ１３において構成情報（ｃｏｎｆｉｇ）をＣＳＣＦに提示して、ステップＳ１４において確認応答を受領する。

ＣＳＣＦは、ステップＳ１５において、ユーザプロファイル情報を管理するデータベースを持つＨＳＳにＩＭＳユーザＩＤに対応して登録された利用可能なサービス情報を要求して取得（ステップＳ１６）し、ＣＳＣＦは、ステップＳ１７において、取得した利用可能なサービス一覧をホームＩＭＳゲートウェイに送信する。ステップＳ１８においてホームＩＭＳゲートウェイはＣＳＣＦに受領確認を送信する。

ホームＩＭＳゲートウェイはこのようにして利用可能なサービスリストを取得しメモリに格納する。ホームＩＭＳゲートウェイはこのようにして取得されたＩＰＴＶのサービスリストからＨＴＭＬドキュメントを生成し、以降のＨＴＭＬブラウザによるＡＳの設定に備える。

（Ａ２）機器発見処理
第２のフェーズは機器発見処理である。初期の時点では利用するＡＳがユーザによって選択されていない。従ってこの時点では、ホームＩＭＳゲートウェイは、ＡＳ（ＩＰＴＶ）をＤＬＮＡＤＭＳとしてマッピングしておらず、ホームネットワーク内のコンテンツ再生機器としてのＤＭＰはＡＳ（ＩＰＴＶ）をＤＭＳと解釈してコンテンツ受領を行なうことはできない。

前述したように、ＡＳ（ＩＰＴＶ）の選択を実行する際、ホームＩＭＳゲートウェイはＨＴＴＰサーバになり、ＵＰｎＰＤＡで規定されるＰｒｅｓｅｎｔａｔｉｏｎの仕組みを利用し、ＨＴＭＬブラウザ搭載のＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔと接続してユーザがブラウザ機能を利用して表示されたＨＴＭＬ画面から所望のＩＰＴＶサービスを選択する。図７に示す（Ａ２）機器発見処理は、この処理のシーケンスである。

ＡＳ（ＩＰＴＶ）の選択を実行するユーザは、例えばブラウザ機能を持つＰＣなどのＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔから、ＵＰｎＰで規定された機器発見のプロトコルに従った処理、すなわち、ステップＳ１９のＳＳＤＰＭ−Ｓｅａｒｃｈを送信し、ステップＳ２０においてその応答であるＳＳＤＰＭ−Ｒｅｓｐｏｎｃｅを受領することにより、ホームネットワーク上にホームＩＭＳゲートウェイが接続されていることを発見する。ステップＳ２１、ステップＳ２２は、具体的な機器情報の要求および受領ステップである。

（Ａ３）ＡＳ（ＩＰＴＶ）選択処理
図８には、続いて実行されるＡＳ（ＩＰＴＶ）選択処理のシーケンスを示している。このフェーズでは、ユーザが、ＰＣなどのＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔから、ホームＩＭＳゲートウェイが第１のフェーズで取得したＡＳ（ＩＰＴＶ）のサービスリストを閲覧してサービス（ＡＳ）選択を実行する。

まず、ステップＳ２３、Ｓ２４において、ＨＴＴＰサーバとしてのホームＩＭＳゲートウェイに対してＨＴＴＰＧＥＴに基づいて、ＨＴＭＬドキュメントを取得しＨＴＭＬページを表示する。その画面においてＡＳ（ＩＰＴＶ）のサービスリストが表示される。

ユーザはそのリストからサービスを受領したいＡＳ（ＩＰＴＶ）あるいはコンテンツを選択するとステップＳ２５において、この要求情報がホームＩＭＳゲートウェイに入力され、ホームＩＭＳゲートウェイは、ステップＳ２６において、ＩＭＳのＣＳＣＦに対して、サービスの加入を要求する。ＣＳＣＦは、ステップＳ２７において、ホームＩＭＳゲートウェイにおけるサービス加入要求に基づいて、ＨＳＳにユーザ対応の登録情報として、このサービス加入要求に対応する情報登録を実行する。サービス加入登録処理が完了すると処理完了応答が、ステップＳ２８において、ＨＳＳからＣＳＣＦに通知され、ステップＳ２９において、ＣＳＣＦからホームＩＭＳゲートウェイに通知され、さらに、ステップＳ３０において、ＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔであるＰＣなどのユーザインタフェースを持つ装置に送信され、ユーザによって確認される。

なお、この（Ａ３）ＡＳ（ＩＰＴＶ）選択処理においては、例えば課金処理などが行われる場合もあり、この場合には、課金処理に必要な情報の入力、通信が実行される。

このように、（Ａ）ＡＳ（ＩＰＴＶ）の加入手続きのシーケンスは、
（Ａ１）ＩＭＳ登録処理
（Ａ２）機器発見処理
（Ａ３）ＡＳ（ＩＰＴＶ）選択処理
これら３つの処理によって構成され、これらの各処理が完了することでＡＳ（ＩＰＴＶ）の加入手続きが完了する。

このＡＳ（ＩＰＴＶ）の加入手続きが完了すると、ホームＩＭＳゲートウェイは、選択されたＡＳ（ＩＰＴＶ）をＤＬＮＡＤＭＳとするマッピングを実行し、ホームネットワーク内のコンテンツ再生機器としてのＤＭＰが、選択ＡＳ（ＩＰＴＶ）をＤＭＳと解釈してコンテンツ受領を行なうことができる設定とする。すなわち、ホームＩＭＳゲートウェイは、図６に示したＵＰｎＰＤｅｖｉｃｅＰｒｏｘｙＭａｎａｇｅｒなどを利用して、選択されたＡＳ（例ではＡＳ３）に対応したＵＰｎＰＭｅｄｉａＳｅｒｖｅｒのインスタンスを生成してメモリに記録する。

このマッピング処理により、ホームネットワーク外にあるＩＭＳのアプリケーションサーバとしてのＡＳ（ＩＰＴＶ）は、ホームネットワーク内のコンテンツ提供サーバと同様のＤＭＳ（ＤＬＮＡＭｅｄｉａＳｅｒｖｅｒ）と同様の扱いがなされ、ホームネットワーク内のコンテンツ再生機器であるＤＭＰ（ＤＬＮＡＭｅｄｉａＰｌａｙｅｒ）から利用可能となる。

以下、図９、図１０を参照して、ホームネットワーク内のコンテンツ再生機器であるＤＭＰによるＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスについて説明する。
図９、図１０は、左側から、
（１）ＩＰＴＶサービス（ＡＳ）（コンテンツ提供主体）
（２）ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースを持つＨＳＳ
（３）ＩＭＳネットワークにおいて、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づき、ユーザの登録やセッション設定の制御を行なうＣＳＣＦ、
（４）ホームＩＭＳゲートウェイ、
（５）ホームネットワーク内のコンテンツ再生機器であるＤＭＰ（ＤＬＮＡＭｅｄｉａＰｌａｙｅｒ）
これらの各構成要素を示している。なお、（１）ＩＰＴＶサービス（ＡＳ）は、ＩＰＴＶサービスのみ、あるいはＩＰＴＶサービスとＡＳとの組み合わせであり、いずれの態様も可能である。また、各ステップに示す［ＳＳＤＰ］［ＨＴＴＰ］［ＳＯＡＰ］［ＡＫＥ］は各通信に適用されるプロトコルを示している。

図９、図１０に示すＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスは、以下の４つのフェーズに分けられる。
（Ｂ１）機器発見処理
（Ｂ２）コンテンツリスト取得処理
（Ｂ３）認証、鍵交換処理
（Ｂ４）コンテンツストリーミング処理
以下、各処理について説明する。

（Ｂ１）機器発見処理
第１の処理は、機器発見フェーズである。先に図７、図８を参照して説明したＡＳの加入シーケンスにより既にホームＩＭＳゲートウェイはＡＳ（ＩＰＴＶ）をＤＬＮＡＤＭＳとしてマッピングし、ホームネットワーク内の各機器ＤＬＮＡ機器に対して、ＡＳ（ＩＰＴＶ）がＤＬＮＡＤＭＳとして利用可能であることが公開されている。すなわち、ホームネットワークに接続されたすべてのコンテンツ再生機器であるＤＭＰはＵＰｎＰＤＡで規定された機器発見シーケンスによりホームＩＭＳゲートウェイから、ＤＭＳとしてＡＳ（ＩＰＴＶ）情報を取得することができる。この機器発見シーレンスがステップＳ３１〜Ｓ３４の処理である。

コンテンツ再生機器であるＤＭＰは、ＵＰｎＰで規定された機器発見のプロトコルに従った処理、すなわち、ステップＳ３１のＳＳＤＰＭ−ＳｅａｒｃｈをホームＩＭＳゲートウェイに送信し、ステップＳ３２においてその応答であるＳＳＤＰＭ−ＲｅｓｐｏｎｃｅをホームＩＭＳゲートウェイから受領することにより、ＤＭＳとして設定されたＡＳ（ＩＰＴＶ）を発見する。ステップＳ３３、ステップＳ３４は、具体的な機器情報の要求および受領ステップである。

なお、ホームＩＭＳゲートウェイは、この機器発見処理において、ホームＩＭＳゲートウェイがマッピング処理において生成したＡＳ（ＩＰＴＶ）に対応するＵＰｎＰＭｅｄｉａＳｅｒｖｅｒインスタンスに基づく情報、すなわちＡＳ（ＩＰＴＶ）に対応するサーバ情報をコンテンツ再生機器であるＤＭＰに提供する。ＤＭＰは、この情報を受領することで、ＡＳ（ＩＰＴＶ）がホームネットワーク内のコンテンツ提供サーバ（ＤＭＳ）であるものと解釈する。

（Ｂ２）コンテンツリスト取得処理
第２の処理は、ＤＭＳとして設定されたＡＳ（ＩＰＴＶ）からのコンテンツリスト取得処理である。既にＡＳの加入シーケンスに示した例のようにホームＩＭＳゲートウェイはＩＭＳネットワークにセッション確立していると想定する。もし、セッション確立していない場合、切れている場合は、コンテンツ取得などの要求をトリガーとして再接続を行う。ＩＭＳネットワークとのセッション確立により加入済みのＡＳの情報は取得済みである。

ステップＳ３５において、ＤＭＰは、第１フェーズで発見済みのＤＭＳとして設定されたＡＳ（ＩＰＴＶ）に対してＵＰｎＰのＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅのＢｒｏｗｓｅアクションを発行する。ＤＭＰからＢｒｏｗｓｅアクションを受領したホームＩＭＳゲートウェイは、ステップＳ３６において、この要求を中継し、ＩＰＴＶ（ＡＳ）に転送する。

ＩＰＴＶ（ＡＳ）は、このＢｒｏｗｓｅアクションの内容を解釈し、バックエンドの電子番組情報格納サーバ（ＥＰＧサーバ）などからビデオコンテンツのリストを生成して、ホームＩＭＳゲートウェイ経由で、ＤＭＰにレスポンスを送る（ステップＳ３７、Ｓ３８）。例えばコンテンツリストが階層化されている場合は、複数のＢｒｏｗｓｅアクションが発行される。なお、ＵＰｎＰＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅの規定どおり、コンテンツリストはＤＩＤＬ−Ｌｉｔｅと呼ばれるＸＭＬＳｃｈｅｍａに準拠したＸＭＬドキュメントで表現されるが、各コンテンツのビデオデータのリソース情報（ＵＲＩ）はＡＳのバックエンドのＶｉｄｅｏＳｅｒｖｅｒが提供するビデオコンテンツを示している。

なお、先に説明したように、ＤＭＰからのコンテンツリスト要求を、ホームＩＭＳゲートウェイが中継処理を行なわず、クライアント機器（ＤＭＰ）から直接ＡＳ（ＩＰＴＶサービス）等の外部サーバにコンテンツリスト要求を行わせる設定も可能である。このためには、ＵＰｎＰのDevice Architectureにおいて規定されるデバイス情報［Device Description］の［controlURL］、［eventSubURL］の指定するＵＲＬをホームＩＭＳゲートウェイではなく、外部サーバのＵＲＬに設定する。ホームＩＭＳゲートウェイは、このようなＵＲＬ設定を持つデバイス情報［Device Description］をクライアント機器に提供することで、その後、クライアントがデバイス情報を参照してコンテンツリスト要求や、各種の要求を行う相手がＡＳ（ＩＰＴＶサービス）等の外部サーバに設定される。

（Ｂ３）認証、鍵交換処理
第３のフェーズは認証、鍵交換である。ＤＬＮＡではコピープロテクトされたコンテンツを伝送する場合にはＤＴＣＰ−ＩＰに従って暗号化して伝送することになる。ＡＳ（ＩＰＴＶ）のビデオサーバからのストリーミングにおいてもＤＴＣＰ−ＩＰ準拠の暗号化がなされて暗号化コンテンツが送信される。

コンテンツの暗号化に適用する鍵は、ＤＴＣＰ−ＩＰの規定に従った認証および鍵交換（ＡＫＥ）処理によって生成される。図６に示したようにホームＩＭＳゲートウェイはＤＴＣＰ−ＩＰＡＫＥＰｒｏｘｙの機能を有しており、コンテンツ再生機器であるＤＭＰはコンテンツの受信に際して、ＤＭＰがコンテンツの提供サービス主体として認識しているＤＭＳを持つホームＩＭＳゲートウェイと認証、鍵交換を行うことになる。

（Ｂ２）のコンテンツリスト取得処理において取得したリストに設定されているコンテンツのリソースＵＲＩはＡＳのビデオサーバのＩＰアドレスを含む設定であるが、これらのコンテンツ取得を実行するために必要とする認証、鍵交換処理、すなわちＡＫＥプロセスの実行対象としてのアドレスはホームＩＭＳゲートウェイに設定される。すなわち、ＤＭＰは、コンテンツの提供サービス主体として認識しているＤＭＳのインスタンスが登録されたホームＩＭＳゲートウェイと認証、鍵交換を行う。

なお、ＤＭＰにおいて認証、鍵交換の実行対象は、暗号化コンテンツの送信主体、すなわち、コンテンツのリソースＵＲＩに含まれるＡＳのビデオサーバのＩＰアドレスとされることが多いが、本発明の構成では、（Ｂ２）のコンテンツリスト取得処理においてＤＭＰに提供されるコンテンツリストに含まれるコンテンツの取得要求に際してＤＭＰが実行するＡＫＥ処理対象はホームＩＭＳゲートウェイに設定される。

これは、例えば、コンテンツ対応のメタデータをＡＫＥ対象をホームＩＭＳゲートウェイとする設定とするメタデータを含めることで可能となる。ホームＩＭＳゲートウェイがＩＰＴＶサービス（ＡＳ）から受領するコンテンツリストの設定は、予めこのような設定としたリストとするか、あるいはホームＩＭＳゲートウェイにおいてメタデータの追加あるいは変更を行なう構成としてもよい。あるいはホームＩＭＳゲートウェイがＤＭＰに対するコンテンツリストの提供時にＡＫＥ対象をホームＩＭＳゲートウェイとする旨の通知を実行する構成としてもよい。

認証、鍵交換処理はＤＴＣＰ―ＩＰの規定する認証および鍵交換（ＡＫＥ：ＡｕｔｈｎｔｉｃａｔｉｏｎａｎｄＫｅｙＥｘｃｈａｎｇｅ）処理シーケンスに従って実行される。

本発明の構成では、図１０に示すステップＳ３９〜Ｓ４６の処理、すなわち、
Ｓ３９：ＡＫＥＣｈａｌｌｅｎｇｅ＆Ｒｅｓｐｏｎｓｅ
Ｓ４０：ＡＫＥ
Ｓ４１：ＲＴＴ（ＲｏｕｎｄＴｒｉｐＴｉｍｅ）Ｃｈｅｃｋｒｅｑｕｅｓｔ
Ｓ４２：ＲＴＴＣｈｅｃｋｒｅｓｐｏｎｓｅ
Ｓ４３：ＡＫＥＫｅｙＥｘｃｈａｎｇｅ
Ｓ４４：ＫｅｙＥｘｃｈａｎｇｅ
Ｓ４５：ＫｅｙＥＸｃｈａｎｇｅ
Ｓ４６：ＡＫＥＫｅｙＥｘｃｈａｎｇｅ
これらの処理によって、ＤＭＰとホームＩＭＳゲートウェイとの認証、鍵交換が完了する。

この認証、鍵交換処理過程ではＡＫＥの対象であるホームＩＭＳゲートウェイがＤＭＰの近傍にあることを確認するためにＩＰパケットのＴＴＬ（ＴｉｍｅＴｏＬｉｖｅ）の確認とレスポンス時間の確認がステップＳ４１，Ｓ４２におけるＲＴＴ計測として行なわれる。
また、ステップＳ４４、Ｓ４５は、本発明の構成における特徴的な処理であり、暗号鍵として適用される鍵をコンテンツ提供主体としてのＩＰＴＶサービス（ＡＳ）と、コンテンツ利用主体としてのＤＭＰが共有するため、ＡＫＥシーケンスで、ホームＩＭＳゲートウェイとＤＭＰが共有した鍵をＩＰＴＶサービス（ＡＳ）に渡す処理である。このステップＳ４４、Ｓ４５の処理を加えることで、コンテンツ提供主体としてのＩＰＴＶサービス（ＡＳ）と、コンテンツ利用主体としてのＤＭＰが暗号鍵を共有することができる。ここで、このＩＰＴＶサービス（ＡＳ）は鍵の共有を許可された正規のサービスであり、ステップＳ４４、Ｓ４５はセキュアな通信によってなされるものである。

（Ｂ４）コンテンツストリーミング処理
最後、第４のフェーズはコンテンツのストリーミング処理である。コンテンツ再生機器であるＤＭＰは、ステップＳ４７において、先の（Ｂ２）コンテンツリスト取得処理において取得したリソースのＵＲＬを適用してＨＴＴＰＧＥＴに基づくコンテンツ要求を発行し、ＨＴＴＰストリーミングを要求する。

ＩＰＴＶサービス（ＡＳ）のビデオサーバは先のＡＫＥフェーズにおいてＤＭＰと共有する鍵を適用してコンテンツデータを暗号化し、ステップＳ４８においてホームネットワーク内のＤＬＮＡ機器であるＤＭＰに対してコンテンツのストリーミング伝送を開始する。

ホームネットワーク内のコンテンツ再生機器であるＤＭＰはＩＰＴＶサービス（ＡＳ）から受信したデータを先のＡＫＥフェーズでＩＰＴＶサービス（ＡＳ）と共有した暗号鍵を適用して復号を行ない、デコードすることでコンテンツ再生を実行する。

本発明の処理構成では、
（Ｂ３）認証、鍵交換処理と、
（Ｂ４）コンテンツストリーミング処理
これらの第３、４のフェーズにおいて、ＡＫＥモジュールの適用するＩＰアドレスがコンテンツ提供主体としてのサーバとは実体が異なるホームＩＭＳゲートウェイに設定される点が異なる以外、ＤＬＮＡ規定のＤＴＣＰ−ＩＰによるストリーミング再生に準拠する処理である。

図９、図１０を参照して説明したコンテンツ利用処理におけるデータ通信の全体概要について図１１を参照して説明する。図１１には、ホームネットワーク５００内の機器として、コンテンツ再生機器としてのＤＭＰ５０１、ホームＩＭＳゲートウェイ５０２、レジデンシャルゲートウェイ（ＲＧ）５０３を示している。さらにホームネットワーク５００の外部の構成として、ＩＰマルチメディアサブシステム（ＩＭＳ）５１０、ＩＰＴＶサービス５２０を示している。

ＩＰマルチメディアサブシステム（ＩＭＳ）５１０は、先に、図３を参照して説明したように、第３世代移動体通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｈｅｒｓｈｉｐＰｒｏｊｅｃｔ）で開発されている携帯電話の無線通信インフラにおける基盤であり、ＣＳＣＦ（ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）と呼ばれる機能要素を核として、ホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）、アプリケーションサーバ（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）などの機能要素から構成されている。図１１には、アプリケーションサーバ（ＡＳ）５１１を示している。アプリケーションサーバ（ＡＳ）５１１は、サービス提供サーバの関数登録などの処理を行なうディレクトリサービス実行部としてのＣＤＳ（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）５１２を含む。

ＩＰＴＶサービス５２０は、コンテンツリスト等の番組情報ガイドであるＥＰＧ（ＥｌｅｃｔｒｏｎｉｃＰｒｏｇｒａｍＧｕｉｄｅ）の提供サーバであるＥＰＧサーバ５２１と、映像コンテンツの提供サーバであるビデオサーバ５２２を有し、それぞれのサーバとＡＳ（ＩＰＴＶ）５１１のＣＤＳ５１２との連携によって、ユーザ端末であるＤＭＰ５０１に対するコンテンツリストの提供サービス、コンテンツの提供サービスを実現している。

ホームネットワーク５００内のコンテンツ再生機器であるＤＭＰ５０１がホームネットワーク外のＩＰＴＶサービス５２０からのコンテンツを取得する場合の基本的な処理の流れについて説明する。先に図７、図８を参照して説明したＡＳの加入シーケンスにより既にホームＩＭＳゲートウェイ５０２はＩＰＴＶサービス（ＡＳ）をＤＬＮＡＤＭＳとしてマッピングしている。

まず、ステップＳ１０１において、ＤＭＰ５０１は、ＵＰｎＰアクションとしての機器発見を実行して、ホームＩＭＳゲートウェイ５０２からＤＭＳとして設定されたＡＳ（ＩＰＴＶ）の情報を取得する。ホームＩＭＳゲートウェイ５０２は、機器発見処理において、ホームＩＭＳゲートウェイ５０２がマッピング処理において生成したＡＳ（ＩＰＴＶ）に対応するＵＰｎＰＭｅｄｉａＳｅｒｖｅｒインスタンスに基づく情報をコンテンツ再生機器であるＤＭＰ５０１に提供する。ＤＭＰ５０１は、この情報を受領することで、ＡＳ（ＩＰＴＶ）がホームネットワーク内のコンテンツ提供サーバ（ＤＭＳ）であると解釈する。

さらに、ＤＭＰ５０１は、ＤＭＳとして設定されたＡＳ（ＩＰＴＶ）に対してＵＰｎＰのＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅのＢｒｏｗｓｅアクションを発行する。ＤＭＰ５０１からＢｒｏｗｓｅアクションを受領したホームＩＭＳゲートウェイ５０２は、この要求をＡＳ５１１（ＣＤＳ５１２）に中継する。ＡＳ５１１（ＣＤＳ５１２）は、ＩＰＴＶサービス５２０のＥＰＧサーバ５２１の提供するビデオコンテンツのリストを取得して、ホームＩＭＳゲートウェイ５０２で、ＤＭＰ５０１にレスポンスとしてコンテンツリストを送信する。

なお、先に説明したように、このコンテンツリストには、メタデータとしてコンテンツの取得に適用するコンテンツＵＲＬと、コンテンツ取得の前提として実行する認証および鍵交換（ＡＫＥ）処理の対象機器情報が記録されており、鍵交換（ＡＫＥ）処理の対象機器情報はホームＩＭＳゲートウェイ５０２に設定されている。あるいは、コンテンツメタデータを用いることなく、鍵交換（ＡＫＥ）処理の対象機器がホームＩＭＳゲートウェイ５０２であることをホームＩＭＳゲートウェイ５０２からＤＭＰ５０１に通知する設定としてもよい。

ＤＭＰ５０１は、コンテンツ受信に先立ち、ステップＳ１０２において、ＤＴＣＰ−ＩＰの規定に従った認証および鍵交換（ＡＫＥ）処理を実行する。ＤＭＰは、認証、鍵交換の実行対象をホームＩＭＳゲートウェイ５０２として処理を実行する。ただし、この認証および鍵交換（ＡＫＥ）処理において、ホームＩＭＳゲートウェイ５０２は、コンテンツの暗号鍵として適用される鍵を、ステップＳ１０３において、コンテンツ提供主体としてのＩＰＴＶサービス５２０のビデオサーバ５２２に提供する。この処理によって、認証および鍵交換（ＡＫＥ）処理の完了時には、コンテンツ提供主体としてのＩＰＴＶサービス５２０のビデオサーバ５２２と、コンテンツ利用主体としてのＤＭＰが鍵を共有することになる。

次に、ステップＳ１０４において、コンテンツ再生機器であるＤＭＰ５０１は、コンテンツリスト取得処理において取得したリソースのＵＲＬを適用してＨＴＴＰＧＥＴに基づくコンテンツ要求を発行し、ビデオサーバ５２２に対してＨＴＴＰストリーミングを要求する。ＩＰＴＶサービス５２０のビデオサーバ５２２は先のＡＫＥフェーズにおいてＤＭＰ５０１と共有した鍵を適用してコンテンツデータを暗号化し、ＤＭＰ５０１に送信する。ＤＭＰ５０１はＩＰＴＶサービス５２０から受信したデータに対して共有暗号鍵を適用した復号処理を実行してコンテンツ再生を実行する。

以上、説明したように、本発明の構成により、ホームネットワーク内のコンテンツ再生装置としてのＤＭＰが、ホームネットワーク外のコンテンツ提供サーバからのコンテンツを受領して再生することが可能となる。

この処理を可能とするため、ホームネットワーク内に設置されたホームＩＭＳゲートウェイが、コンテンツ提供サーバとの通信を実行して、コンテンツ提供サーバを仮想的なホームネットワーク機器としてマッピング、すなわち外部サーバのサーバ情報を記録したインスタンスを生成して記憶部に格納し、ホームネットワーク内のコンテンツ再生装置からＵＰｎＰ規定に従った機器発見要求の受信に応じて、インスタンスに基づいてコンテンツ提供サーバに対応するサーバ情報を、サービス受領可能な機器情報としてコンテンツ再生機器に提供する処理を実行する。

さらに、ホームＩＭＳゲートウェイは、コンテンツ再生装置からのコンテンツ取得要求、すなわち、コンテンツ提供サーバの提供コンテンツの取得要求を受信した場合に、この要求をコンテンツ提供サーバに転送してコンテンツ提供サーバからコンテンツをコンテンツ再生装置に送信させて、コンテンツ再生装置におけるコンテンツ受信および再生を可能とした。

また、ＤＬＮＡにおいて規定されるコンテンツ送信条件として実行が要請される認証および鍵交換については、コンテンツ再生装置とホームＩＭＳゲートウェイの間で規定どおりの処理（ＡＫＥ）を実行して、生成した鍵をホームＩＭＳゲートウェイが、コンテンツ提供サーバに送信する構成としたので、コンテンツ提供サーバとコンテンツ再生装置は、認証および鍵交換処理において生成した鍵を共有することが可能となり、ホームネットワーク内のＤＭＳの実行するコンテンツ送信処理と同様、暗号化を施したコンテンツがコンテンツ提供サーバからコンテンツ再生装置に対して送信され、安全なコンテンツ送受信が実現される。

なお、このコンテンツ伝送方式はＨｏｍｅｔｏＨｏｍｅのコンテンツ伝送にも応用できる。図１１のＩＰＴＶサービス５２０のビデオサーバ５２２に替わって、別の家庭のホームサーバが同様のサービスを提供することにより、その家庭のコンテンツの伝送を行うことができる。このように商用でないコンテンツの伝送では、暗号化を施さずに送る場合もある。

以上、図４に示されるＤＬＮＡガイドラインに準拠したコンテンツ再生機器であるＤＭＰがＩＰＴＶサービスを受領するためのホームＩＭＳゲートウェイについての実施例を説明した。先に図４を参照して説明したように、ＤＬＮＡ規定のコンテンツ提供サーバであるＤＭＳは、ＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）を実装し、ＵＰｎＰメディアサーバ（ＵＰｎＰＭｅｄｉａＳｅｒｖｅｒ）には、主となるコンテンツディレクトリサービス（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）が実装されており、これを適用したコンテンツリストおよびメタデータの取得を可能としている。すなわち、コンテンツディレクトリサービス（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）を利用することで、ＤＬＮＡ規定のコンテンツ再生機器であるＤＭＰは、ＤＬＮＡ規定のコンテンツ提供サーバであるＤＭＳがストリーミングするコンテンツリストの取得が行われる。図９を参照して説明した実施例は、ＵＰｎＰコンテンツディレクトリサービス（ＣｏｎｔｅｎｔＤｉｒｅｃｔｏｒｙＳｅｒｖｉｃｅ）によるコンテンツリスト取得処理を、ＵＰｎＰＤＡで規定するＳＯＡＰ，ＧＥＮＡのメッセージ通信を適用して行った実施例である。次に、ＵＰｎＰＤＡで規定されるプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）の仕組みを利用した処理例について説明する。

［ＵＰｎＰＤＡで規定されるプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）の仕組みを利用した処理例］
以下において説明する実施例は、本発明の情報処理装置である図３に示すホームＩＭＳゲートウェイ２１２がＨＴＴＰサーバになり、ＵＰｎＰＤＡで規定されるプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）の仕組みを利用してＨＴＭＬブラウザ搭載のＵＰｎＰＣｏｎｔｒｏｌＰｏｉｎｔと接続して、ユーザがブラウザ機能を利用して表示したＨＴＭＬ画面から所望のＩＰＴＶサービスを選択してサービスを受領する実施例である。

すなわち、先に説明したＵＰｎＰＤＡで規定されるプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）の仕組みを適用して、ホームＩＭＳゲートウェイ２１２からコンテンツ再生機器であるＤＭＰ、例えば図３に示すＴＶ（ＤＭＰ）２１３に対して、例えばコンテンツリストやコンテンツ情報などを含むサービス画面を記述したＨＴＭＬデータを提供する処理を実行して、ＨＴＭＬデータからなるサービス画面をコンテンツ再生機器であるＤＭＰ側のディスプレイに表示して、表示データに基づいてユーザがコンテンツ選択を行い、ＩＰＴＶサービスを受領する処理例である。すなわち、例えば、ホームネットワーク内のＤＬＮＡ機器として設定されたブラウザ機能を持つＰＣやＴＶを利用して、ホームＩＭＳゲートウェイ２１２の持つリストをディスプレイに提示してＩＰＴＶサービスの選択を行ないサービスの受領を行なう。

この実施例では、コンテンツ再生機器、すなわち、例えば図３に示すＴＶ（ＤＭＰ）２１３はＵＰｎＰＤＡ規定のプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）機能を実現するためのＨＴＭＬブラウザを実装する。本実施例では、ＵＰｎＰコンテンツディレクトリ（UPnP Content Directory）サービスは使用されないが、コンテンツ再生機器は、ストリーミング再生機能のためにＤＬＮＡのメディア転送の規定やコンテンツプロテクションのＤＴＣＰ−ＩＰ規定に基づく実装となっている。

ＡＳ（ＩＰＴＶ）提供コンテンツの利用シーケンスは、以下の４つのフェーズに分けられる。
（Ｂ１）機器発見処理
（Ｂ２a）サービス画面取得
（Ｂ３）認証、鍵交換処理
（Ｂ４）コンテンツストリーミング処理
上記フェーズ中、（Ｂ１），（Ｂ３），（Ｂ４）の各フェーズの処理は、先の実施例において、図９、図１０を参照して説明した処理と同じである。図９、図１０を参照して説明した処理では、図９を参照して説明したステップＳ３５〜Ｓ３８の（Ｂ２）コンテンツリスト取得処理を実行していたが、ＵＰｎＰＤＡで規定されるプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）の仕組みを利用した本実施例では、この（Ｂ２）コンテンツリスト取得処理の代わりに、（Ｂ２ａ）サービス画面取得処理が行われる。

この（Ｂ２ａ）サービス画面取得処理を行うためのホームＩＭＳゲートウェイ２１２のソフトウェアモジュールの構成例を図１２に示す。このサービス画面操作方式の実施例では、ＨＴＭＬブラウザの機能を利用しサービス画面を取得するため、図６を参照して説明したＳＯＡＰ，ＧＥＮＡのソフトウェアモジュールは実装されず、さらに図６を参照して説明したＵＰｎＰメッセージプロキシ（UPnP Message Proxy）の代わりにＨＴＴＰサーバ、ＨＴＴＰクライアントの間でＨＴＭＬデータを中継するＨＴＴＰプロキシ（HTTP Proxy）が実装される。

図１３に示すシーケンス図を参照して、本実施例における
（Ｂ１）機器発見処理
（Ｂ２ａ）サービス画面取得処理
これらのシーケンスについて説明する。
（Ｂ１）機器発見処理は、先に図９を参照して説明した処理と同様であり、コンテンツ再生装置であるＤＭＰ（例えば図３に示すＴＶ（ＤＭＰ）２１３）は、ＵＰｎＰで規定された機器発見のプロトコルに従った処理ステップＳ３１〜Ｓ３４によって機器発見処理を行う。この処理によりコンテンツ再生機器としてのＤＭＰは、ホームＩＭＳゲートウェイに実装されたコンテンツ提供サーバ（ＤＭＳ）を発見し、ＵＰｎＰＤＡの規定に従いＤＭＳのデバイス情報（Device Description）により、ＤＭＳに実装されたＨＴＴＰサーバの提供するＨＴＭＬデータを取得するためのプレゼンテーションＵＲＬ（Presentation URL）を取得する。

次に実行される（Ｂ２ａ）サービス画面取得処理では、まず、コンテンツ再生機器としてのＤＭＰは、（Ｂ１）機器発見処理において取得したプレゼンテーションＵＲＬ（Presentation URL）を利用してステップＳ２０１において、ＨＴＴＰ：ＧＥＴリクエストをＤＭＳのＨＴＴＰサーバに送信する。

ホームＩＭＳゲートウェイに実装されたＨＴＴＰプロキシ（HTTP Proxy）は、ステップＳ２０２において、コンテンツ再生機器としてのＤＭＰからＨＴＴＰサーバが受信したＨＴＴＰ：ＧＥＴリクエストをＩＰＴＶサービスのアプリケーションサーバ（ＡＳ）に伝達する。

ＩＰＴＶサービスのアプリケーションサーバ（ＡＳ）はＥＰＧサーバから取得したコンテンツ情報を利用してコンテンツリストを含んだサービス画面をＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）データとして生成し、ステップＳ２０３において、サービス画面を表現したＨＴＭＬデータをＨＴＴＰ：ＯＫレスポンスとしてホームＩＭＳゲートウェイに返信する。

ホームＩＭＳゲートウェイは、ステップＳ２０４において、ＩＰＴＶサービスのアプリケーションサーバ（ＡＳ）から受信したＨＴＭＬデータを含むレスポンスを、ＨＴＴＰプロキシ（HTTP Proxy）により、コンテンツ再生機器としてのＤＭＰに転送する。

コンテンツ再生機器としてのＤＭＰは、ホームＩＭＳゲートウェイを介して転送されたＩＰＴＶサービスのアプリケーションサーバ（ＡＳ）の送信したＨＴＭＬデータに対してＨＴＭＬブラウザを適用した描画処理を行いコンテンツリスト等からなるサービス画面を生成してユーザに表示する。このサービス画面には、ＩＰＴＶサービスのコンテンツリストが含まれており、ユーザは、このコンテンツリストから再生するコンテンツを選ぶ。

このコンテンツ選択処理は例えば画面上に表示されたコンテンツリストをリモコンやスイッチ、あるいはキーボード、マウスなどのポインタによって選択する処理として実行される。このコンテンツ選択処理により、ＨＴＭＬデータに含まるコンテンツのリソースＵＲＬが特定される。この選択コンテンツ対応のＵＲＬを利用してその後の処理、すなわち、先に、図１０を参照して説明した
（Ｂ３）認証、鍵交換処理、
（Ｂ４）コンテンツストリーミング処理、
これらの各処理が行われる。これらの処理によりコンテンツ再生機器としてのＤＭＰはコンテンツ再生を行う。すなわち、クライアント装置は、サービス画面に含まれるコンテンツリストに対するユーザのコンテンツ選択情報を入力し、このコンテンツ選択情報に基づいて、選択コンテンツ対応のＵＲＬ、すなわち、ＨＴＭＬデータに含まるコンテンツのリソースＵＲＬを特定し、ＵＲＬに基づく認証、鍵交換処理やコンテンツストリーミング処理を実行する。

なお、図１３に示すシーケンス図では、ステップＳ２０１〜Ｓ２０４において実行するサービス画面の取得処理は１回の処理としているが、サービス画面は複数のＨＴＭＬデータで表現された構造的なメニュー構成をとることが可能であり、ユーザによるＨＴＭＬブラウザの操作に基づいてサービス画面の再取得を実行することが可能となる。すなわち、ステップＳ２０１〜Ｓ２０４の処理と同等の処理を繰り返し実行する構成とすることが可能であり、様々なサービス画面をＩＰＴＶサービスのＡＳからＤＭＰに対して提供することが可能であり、ＤＭＰ側のユーザは、様々なサービス画面に提示されるコンテンツリストから任意のコンテンツを選択することができる。

また、ＩＰＴＶサービスの提供するコンテンツ提供処理がビデオオンデマンドサービスのような場合や、ユーザのコンテンツ視聴権利の購買に対する課金確認が行われる場合にも、確認画面を表現するＨＴＭＬデータがホームＩＭＳゲートウェイを介してＩＰＴＶサービスのＡＳからＤＭＰに対して伝送される。

ユーザはＤＭＰのディスプレイに表示されたサービス画面を操作し、対話的（インタラクティブ）な処理を行いながら様々なＩＰＴＶサービスの提供サービスを受領することができる。

図１４にＩＰＴＶサービスのＡＳからＤＭＰに対して提供され、ＤＭＰのディスプレイに表示されるサービス画面およびストリーミング再生画面の例を示す。
図１４（１）は、図１３のシーケンス図において説明したステップＳ２０１〜Ｓ２０４の（Ｂ２）のサービス画面取得処理においてＤＭＰのディスプレイに表示されるサービス画面の例である。
図１４（２）は、その後のコンテンツストリーミング処理時にＤＭＰのディスプレイに表示される画面の例である。すなわち、図１０を参照して説明した（Ｂ４）コンテンツストリーミング処理を行っている場合のコンテンツ再生装置の表示画面の例である。
なお、図１４に示す２つの画面、すなわち、
（１）サービス画面、
（２）コンテンツストリーミング画面、
これら２つの処理画面は、ユーザ操作により適時、切換え可能であり、サービス画面提示、およびコンテンツストリーミング処理は繰返し実行可能である。

なお、ここで説明した実施例はＵＰｎＰＤＡに規定されるプレゼンテーションの仕組みを利用した処理例として説明したが、例えばＣＥＡ−２０１４規格で規定されるＨＴＭＬブラウザ（HTML Browser）の仕組みを利用した構成においても、同様の処理が可能である。

ＣＥＡ−２０１４規格について簡単に説明する。ＣＥＡ−２０１４規格は、ウェブベースのプロトコルおよびフレームワークの規格であり、ＵＰｎＰネットワークおよびインターネットを利用したリモートユーザインタフェースのための規格である。このＣＥＡ−２０１４規格は、例えばネットワーク等によって接続された遠隔デバイスの制御のもとでユーザインタフェースを提供するために必要となる機構を定義した規格である。ユーザインタフェースを提供するデバイスの基本的処理は、ＵＰｎＰネットワークおよびホーム内ＵＰｎＰについての規定であるＵＰｎＰデバイスアーキテクチャ（ｖ１．０）に準拠した処理である。ＣＥＡ−２０１４規格は、ホーム内のＵＰｎＰデバイスに対してサードパーティのインターネットサービスによって提供されるユーザインタフェースの遠隔表示処理についても容認しており、ＴＶやモバイルフォン、さらにポータブルデバイスにおいて利用される様々なＵＩ機能について規定している。なおＣＥＡ−２０１４規格は、ホームネットワークにおけるＵＩ規格であるＣＥＡ−２０２７−Ａの具体的仕様に対応する規定を含む規格として構成されている。

ＣＥＡ−２０１４規格で規定されるＨＴＭＬブラウザ（HTML Browser）を実装した機器においては、ＨＴＭＬブラウザ（HTML Browser）を利用したサービス画面の取得によって、図１３を参照して説明した処理と同様の処理が実現される。なお、この場合はホームＩＭＳゲートウェイのＵＰｎＰデバイスクラス（UPnP Device class）はリモートＵＩサーバ（Remote UI Server）となり、ＣＥＡ−２０１４規定のＨＴＭＬブラウザプロファイルに従ったＨＴＭＬデータが使用される。

［２．ＩＰＴＶサービスに適用する機能の説明］
以上、インターネットへのアクセスラインやゲートウェイなどのインフラに依存しないオープンなインターネット接続環境において、既存のＤＬＮＡ機器を適用してＩＰＴＶサービスなどのホームネットワーク外の外部サーバの提供するコンテンツを視聴可能とする構成について説明してきた。以下、外部サーバからのＩＰＴＶサービスをホームネットワーク内の機器において受領するために利用される機能について、下記に示す各項目別に説明する。
２−Ａ．ＩＰＴＶサービス受領クライアントの機能
２−Ｂ．ＩＭＳ（ＩＰマルチメディアサブシステム）の機能
２−Ｃ．ネットワーク構成において利用される機能

［２−Ａ．ＩＰＴＶサービス受領クライアントにおける機能］
まず、ＩＰＴＶサービス受領クライアントの機能について説明する。先に図３を参照して説明したように、ホームネットワーク２１０内には、
ホームネットワーク内の機器がＩＰブロードバンドネットワーク２２１に接続するネットワーク接続機器でありブリッジとして利用されるレジデンシャルゲートウェイ（ＲＧ：ＲｅｓｉｄｅｎｔｉａｌＧａｔｅｗａｙ）２１１と、
ホームネットワーク２１０内の機器（例えばＴＶ（ＤＭＰ）２１３などのコンテンツ再生機器）に対して、ホームネットワーク外のサーバの提供サービスの利用を可能とするための処理を実行するホームＩＭＳゲートウェイ２１２と、
コンテンツを受領して再生するクライアント機器であるデジタルメディアプレーヤ（ＤＭＰ：ＤｉｇｉｔａｌＭｅｄｉａＰｌａｙｅｒ）ＴＶ２１３、
これらの各機器が存在するが、
これらの各機器は、物理的に区分された個別の装置であっても、１つの装置として構成されてもよい。

すなわち、ホームネットワーク２１０の機器構成は、様々な設定が可能となる。ただし、そのような様々な機器構成において、ＩＰＴＶサービスを受領するために必要とする機能は、いずれかの装置が備えていることが必要である。

ホームネットワーク内に接続されたクライアントとしての１つの情報処理装置、あるいは複数の情報処理装置の組み合わせは、基本的にホームネットワークを介した通信処理を実行する通信部と、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、外部サーバの提供するコンテンツ提供サービスの受領処理を実行するデータ処理部を有する。以下、このホームネットワーク内に接続された情報処理装置がＩＰＴＶサービスを受領するために必要とする機能や有効となる機能、すなわち、ＩＰＴＶサービス受領クライアントの機能について説明する。

ＩＰＴＶサービス受領クライアントが、ＩＰＴＶサービスを受領するために必要となる機能はＩＰＴＶターミナル機能である。ＩＰＴＶターミナル機能はＩＰＴＶサービスの論理エンドポイントに必要とされる機能であり、例えば、図３に示す構成例では、ＲＧ２１１、ホームＩＭＳゲートウェイ２１２、ＴＶ（ＤＭＰ）２１３の各々がこのＩＰＴＶターミナル機能の一部をそれぞれ実行する。これらの各機器が、それぞれの役割に応じてＩＰＴＶターミナル機能の一部を実行して、外部サーバからの提供サービスを受領して、ホームネットワーク内のデバイス、例えば図３に示すＴＶ（ＤＭＰ）２１３において提示することが可能となる。なお、図３には示していないが、さらに、その他のホームネットワーク機器に外部サーバからのサービスを提供して保管、印刷、表示などの処理も実現される。

図１５にＩＰＴＶサービスを受領するために必要とする機能であるＩＰＴＶターミナル機能の構成要素を示す。図１５に示すように、ＩＰＴＶターミナル機能は、
（Ａ１）ＩＰＴＶクライアント
（Ａ２）ＩＭＳゲートウェイ
（Ａ３）その他
これらの各コンポーネントに区分できる。以下、これらの各コンポーネントに含まれる機能要素について説明する。

（Ａ１）ＩＰＴＶクライアント
ＩＰＴＶクライアントは、ＩＰＴＶデバイス、例えば図３に示すＴＶ（ＤＭＰ）２１３において、確実にＩＰＴＶサービスを受け取ることができるようにするコンポーネントである。ＩＰＴＶクライアントは、図１５に示すように、
ＩＰＴＶアプリケーションクライアント
ＩＭＳコミュニケーションクライアント
ＩＰＴＶナビゲーションクライアント
コンテンツプロテクションクライアント
ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイ
これらの機能要素としてのサブコンポーネントを有している。以下、これらの機能要素（サブコンポーネント）について説明する。

ＩＰＴＶアプリケーションクライアントは、メディア信号を受信し、それを表示システムに送るコンポーネントであり、例えばリモコンなどを介するユーザからのコマンドを受信して、コマンドに従った処理を実行する。具体的には、例えばＥＰＧ（電子プログラムガイド）の表示、ＥＰＧを利用したチャンネル指定、変更処理などを行なう。

ＩＭＳコミュニケーションクライアントは、メッセージ、ビデオデータなどのメッセージ情報、および、ＩＰＴＶに関連しないその他のＩＭＳに基づくサービス情報などを配信するために使用される一組のＩＭＳアプリケーションである。

ＩＰＴＶナビゲーションクライアントは、ＥＰＧ（電子プログラムガイド）、ＶｏＤ（ビデオオンデマンド）に対応するコンテンツリスト、その他のメタデータをダウンロードし、これらをコンテンツ選択のため専用のＧＵＩで表示するのに使用される。
ＩＰＴＶナビゲーションクライアントは、放送ＴＶやＤＬＮＡホームネットワークなどのソースから他のメタデータの統合処理などを実行する。
コンテンツプロテクションクライアントは、ＩＰＴＶサービによって提供されるコンテンツの保護、例えばコンテンツオーナーの著作権を保護するための暗号処理、暗号鍵の管理処理などを実行する。

ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、例えばＩＰＴＶクライアントからメディアとＥＰＧ（電子プログラムガイド）を受け取り、これをＤＬＮＡ機器で使用できるフォーマットに変換し、ＥＰＧ（電子プログラムガイド）などを、ネットワークを介して送信する処理などを実行する。

ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）クライアントとして行動し、ホームネットワークに接続されたその他のホームデバイスのための登録処理を実行する。例えば、家族メンバやデバイス登録を実行する。

（Ａ２）ＩＭＳゲートウェイ
次に、図１５に示す（Ａ２）ＩＭＳゲートウェイの機能要素について説明する。これは、図３に示す構成においては、ホームＩＭＳゲートウェイ２１２の持つ機能に相当する。ホームＩＭＳゲートウェイ２１２は、ホームネットワーク内のデバイスをＩＭＳネットワークに接続するコンポーネントであり、必要に応じてさまざまな信号プロトコル間を変換してホームネットワーク内のデバイスと、ホームネットワーク外の装置間のメッセージの仲介を実行する。

ホームＩＭＳゲートウェイには、図に示すように、
ＩＭＳＢ２ＢＵＡ、
ＩＭＳプロキシ、
ＩＭＳクライアント、
ＧＢＡクライアント、
ホームルータインタフェース、
これらの機能要素（サブコンポーネント）を含んでいる。以下、これらの機能要素（サブコンポーネント）について説明する。

ＩＭＳＢ２ＢＵＡは、純粋なＳＩＰクライアントとＩＭＳシステム間のワーキング間ユニットとして機能し、ＳＩＰメッセージとＩＭＳメッセージ間の変換、メッセージ転送等の処理を実行する。
ＩＭＳプロキシは、Ｂ２ＢＵＡのようにメッセージ変換を行なうことなく単にメッセージを送り、経路を決定する処理、ＩＰアドレス（ローカルおよびグローバル）とポートナンバのマッピング処理などを実行する。
ＩＭＳクライアントは、クライアントの識別情報などを適用したクライアント登録処理（ＩＭＳ登録処理）を実行する。また、認証処理、ＣＳＣＦとのＩＰＳｅｃセキュリティ接続設定などの処理のサポートを行なう。
ホームルータインタフェース機能は、ＮＡＴ機能の提供などのルータ機能を提供する。例えばＳＩＰサーバＤＨＣＰオプション［ＤＨＣＰ−ＳＩＰ］、またはＳＲＶレコードによるＤＮＳルックアップによってＰ−ＣＳＣＦアドレスを取得し、ＵＰｎＰに規定されるコントロール信号のポートとユニキャストメディアストリーム用のポートの開閉処理などを実行する。

（Ａ３）その他
ＩＰＴＶターミナル機能は、上述した、
（Ａ１）ＩＰＴＶクライアント
（Ａ２）ＩＭＳゲートウェイ
これらのコンポーネントの他、図１５に示す
（Ａ３）その他
の機能要素（サブコンポーネント）として、
ＨＴＴＰプロキシ
キャッシング機能
マルチキャストデータチャネルコントロール機能
を有する。以下、これらの機能要素（サブコンポーネント）について説明する。

ＨＴＴＰプロキシは、［ＨＴＴＰ］のプロトコル規定に従った処理を実行し、他のクライアント（ＨＴＴＰクライアント）の代わりにリクエストを行う目的でサーバとクライアントの両方として行動する中間プログラムである。このＨＴＴＰプロキシは、例えば、外部に送られるＨＴＴＰＧＥＴに割り込み、要求されるＵＲＩによって参照可能なデータをキャッシングして利用することが可能である。また、ＨＴＴＰプロキシはＨＴＴＰクライアントとして行動し、要求されるＵＲＩに基づくデータ検索などを実行する。

キャッシング機能は、ユニキャストダウンロードや、マルチキャストによってクライアントが受け取ったデータをキャッシュするために使用される。キャッシング機能は、ウェブページ（ＥＰＧその他のＩＰＴＶのメニュー）、イメージ、メタデータなどのデータを一時的に記録するキャッシュ処理を実行する。
キャッシング機能は、例えばユーザのインタラクション待ち時間を最小限にすること、ＩＰＴＶアプリケーションとコントロール機能からのユニキャストダウンロードの量を最小限にするなどのために利用される。キャッシング機能は、クライアントが直接アクセスすることが可能であり、ＩＰＴＶクライアントとキャッシング機能が同じネットワーク内で物理的に離れている場合などにおいては、例えば新たなキャッシュデータの発生などの事象について、ＤＬＮＡの定義に従って、ＧＥＮＡプロトコルを使用して、キャッシング機能からＩＰＴＶクライアントに通知を行うことができる。

マルチキャストデータチャネル（ＭＤＣ）コントロール機能は、キャッシング機能と、クライアントにインストールされたアプリケーション間の仲介を行なう機能であり、マルチキャストデータチャネル（ＭＤＣ：ＭｕｌｔｉｃａｓｔＤａｔａＣｈａｎｎｅｌ）挿入機能を含む。ＭＤＣ挿入機能は、さまざまなアプリケーションからＭＤＣへのコンテンツリクエストを受け取り、コンテンツをマルチキャストチャネルでマルチキャストして配信する。

マルチキャストデータチャネル（ＭＤＣ）コントロール機能は、様々なアプリケーションからのリクエストをタグによって識別する。たとえば、クライアント側で実行するブラウザにおいてはＥＰＧページタグを指定して要求を行うことでＥＰＧの取得が可能となる。ＭＤＣコントロール機能は着信ＭＤＣをフィルタにかけ、申し込まれたタグと共にＭＤＣオブジェクトをそれぞれのアプリケーションに送る。

なお、マルチキャストデータチャネル（ＭＤＣ）コントロール機能は、ＭＤＣプロキシを含み、ＭＤＣプロキシがＥＰＧページなどの一定のオブジェクトに関する特定数のリクエストを登録している場合、ＭＤＣコントロール機能に対してこのＥＰＧページをＭＤＣに入れることを要求できる。すなわちマルチキャストによって複数のクライアントに同一のデータを配信することができ、各クライアントからのユニキャストチャネルによるデータリクエストの必要性を排除可能となり処理が効率化される。

［２−Ｂ．ＩＭＳ（ＩＰマルチメディアサブシステム）の機能］
次に、外部サーバからのＩＰＴＶサービスをホームネットワーク内の機器において受領するために利用されるＩＭＳ（ＩＰマルチメディアサブシステム）の機能について説明する。すなわち、図３に示すＩＭＳネットワーク２３０の機能である。

先に説明したように、ＩＭＳは、ＩＰ技術をベースとしており、固定通信系のインターネットのインフラとの親和性が高い。ＩＭＳはＩＥＴＦ（ＴｈｅＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）のＲＦＣ−３２６１で規定されるＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づくＣＳＣＦ（ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）と呼ばれる機能要素を核として、ホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）、アプリケーションサーバ（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）などの機能要素から構成される。

このようにＩＭＳでは、例えばユーザＩＤが登録されたユーザが、クライアント装置を利用してＣＳＣＦ２３１をアクセスして端末（クライアント）の登録、セッションの設定制御を行い、ＨＳＳ２３２に登録されたユーザプロファイルに設定に従って必要なサービスの起動を行い、ＡＳ２３３は実際に個々のサービスの処理を行う。

ＩＰＴＶサービス２５０は、コンテンツリスト等の番組情報ガイドであるＥＰＧ［ＥｌｅｃｔｒｏｎｉｃＰｒｏｇｒａｍＧｕｉｄｅ（電子プログラムガイド）］の提供サーバであるＥＰＧサーバ２５１と、ＡＶコンテンツの提供サーバであるビデオサーバ２５２を有し、それぞれのサーバとＩＭＳネットワーク２３０のＡＳ（ＩＰＴＶ）２３３との連携によって、ユーザ端末に対するコンテンツリストの提供サービス、コンテンツの提供サービスを実現している。

ＩＭＳ（ＩＰマルチメディアサブシステム）の機能の主要部分には、図３を参照して説明したように、ＣＳＣＦ（ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）２３１、ホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）２３２、アプリケーションサーバ（ＡＳ：ＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ）２３３が含まれる。ＣＳＣＦ２３１は、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に基づき、ユーザの登録やセッション設定の制御を行ない、ＨＳＳ２３２に登録されているユーザプロファイルの設定に従い、必要なサービス処理の起動を実行する。ＨＳＳ２３２は、ＩＭＳで用いるユーザＩＤの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各ＩＭＳサービス利用可否の管理、ユーザ移動管理のためのデータベースを有する。ＡＳ（ＩＰＴＶ）２３３は、ＩＰＴＶサービス（ＩＰＴＶＳｅｒｖｉｃｅ）の実行主体、すなわち、コンテンツの提供主体としてのＩＰＴＶサービス２５０と連携してユーザ端末に対するサービスを実行する。

図１６は、ＩＭＳ（ＩＰマルチメディアサブシステム）の主要機能、
（Ｂ１）ＣＳＣＦ
（Ｂ２）ＨＳＳ
（Ｂ３）ＡＳ
を示す図である。以下、これらの（Ｂ１）ＣＳＣＦ、（Ｂ２）ＨＳＳ、（Ｂ３）ＡＳの持つ機能について個別に説明する。

（Ｂ１．ＣＳＣＦ）
ＣＳＣＦ（ＣａｌｌＳｅｓｓｉｏｎＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）は、図１６に示すように、３つの論理エンティティ、すなわち、プロキシ（Ｐｒｏｘｙ）ＣＳＣＦ，問合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ、およびサービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦに分割される。

プロキシ（Ｐｒｏｘｙ）ＣＳＣＦは、例えばＩＭＳターミナルとしてのホームネットワーク内のクライアント、例えば図３に示すホームＩＭＳゲートウェイ２１２から外部ネットワークへのエントリの最初のポイントとなる。プロキシＣＳＣＦは、ＩＭＳターミナルとしてのホームネットワーク内のクライアント、例えば図３に示すホームＩＭＳゲートウェイ２１２とＩＰＳｅｃセキュリティ関係を確立するためにサービングＣＳＣＦから取得したキーを使用する。

ターミナル、例えば図３に示すホームＩＭＳゲートウェイ２１２から来る各ＩＰＳｅｃ通信によって保護されたＳＩＰメッセージについて、プロキシＣＳＣＦは完全性を検証し、それを解読する。例えばメッセージが暗号化されている場合、復号により解読を行なう。解読に成功すると、プロキシＣＳＣＦは、クライアント識別子の確認処理などを実行する。

問い合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦは、例えばＨＳＳに対する問い合わせなどを実行し、加入者情報（ユーザプロファイルなど）を取得して登録処理をサポートする。さらに、ＳＩＰメッセージや、料金請求の経路決定についての処理も実行する。

サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦはホームネットワークとのコンタクトポイントであり、ＳＩＰレジストラとして機能し、ユーザの位置と記録のユーザＳＩＰアドレス間の結合を維持するＳＩＰサーバとして機能する。ＨＳＳからクライアントの認証に適用するデータであるＡＫＡ認証ベクタ（ＡＶ）やユーザプロファイル／サービスプロファイルを取得する処理などを行なう。サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦはＩＭＳＡＫＡプロトコルを使用してクライアンントの認証処理を実行し、認証に成功した後、ＡＫＡ認証ベクタ（ＡＶ）に含まれるキーをプロキシＣＳＣＦに提供する。

また、サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦは、ＩＭＳターミナル、例えばクライアントとの間のすべてのＳＩＰメッセージを検査し、メッセージの経路を決定する。この処理は、ＨＳＳから取得されるユーザサービスプロファイルに基づくトリガ規則／イベントを考慮した処理として実行することが可能である。

（Ｂ２．ＨＳＳ）
ホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）は、ＩＭＳ加入者情報、ユーザプロファイルなどに関連するクライアント（ユーザ）情報のリストを保持する。なお、クライアントには、複数の識別情報として、プライベートユーザアイデンティティ（ＩＭＰＩ）、および公共ユーザアイデンティティ（ＩＭＰＵ）が設定され、これらの識別情報の少なくいずれかに対応付けてユーザ情報が記録、管理される。

例えばＩＰＴＶサービスの加入者プロファイルは、クライアント（ユーザ）識別情報であるＩＭＰＩに結合され、各クライアントに対応するサービスプロファイルを含む。サービスプロファイルには、１以上の公共ユーザアイデンティティ（ＩＭＰＵ）、コアネットワーク認証情報（オプション）、１以上のフィルタ基準情報などが含まれる。

前述のサービングＣＳＣＦは、ＨＳＳの保持するこれらのフィルタ基準を使用して、ＡＳ（アプリケーションサーバ）に経路を定めるのが適切であるかどうか、これが一定のＳＩＰリクエストに対して要求されるのかどうか等を決定し、フィルタリングを実施する。なお、フィルタに適用するための情報は各ユーザに関してＡＳごとに保存され通知される。例えば、ＩＰＴＶに関して、ＨＳＳはＩＰＴＶサービスの提供主体やサービス識別子に関する情報を保持して、これらに基づいてフィルタリングを実行する。また、ＨＳＳは、正規のＩＭＳ登録手順の間に使用されるＡＫＡ認証ベクタ（ＡＶ）の生成も行なう。

（Ｂ３．ＡＳ）
ＩＭＳ（ＩＰマルチメディアサブシステム）の主要機能のもう１つの要素は、ＩＭＳアプリケーションサーバ（ＡＳ）である。ＩＭＳアプリケーションサーバ（ＡＳ）は、以下のＩＰＴＶ機能を有している。
＊サービス発見機能
ＩＰＴＶサービスを提供するＩＭＳＡＳのためのアクセスポイントの位置を決定する機能である。
ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）機能
ユーザに代わる受信データの記録機能、およびｎＰＶＲ機能に関連する料金請求、認可およびその他のサービスの提供機能である。
＊参加機能
通信パスに滞在し、様々なサービスの実施、料金請求などを実行する機能である。
＊コントロール機能
ＳＩＰトラフィックの終結、メディアストリームのセットアップ調整、エンドユーザ、ロギングなどにおいて設定された情報の記録、ＩＰＴＶサービスからの料金請求、認可およびその他のサービスの処理、これらのサービスや機能をＩＭＳネットワークに接続された外部機器への委託処理などを実行する機能である。

［２−Ｃ．ネットワーク構成において利用される機能］
次に、外部サーバからのＩＰＴＶサービスをホームネットワーク内の機器において受領するためにネットワーク構成において利用される機能について説明する。図１７に示すように、ネットワーク構成において利用される機能には、
（Ｃ１）メディアサーバ
（Ｃ２）トランスコーディング機能
（Ｃ３）ホームルータ
これらの機能要素がある。これらの各機能は、ネットワーク上に分散して配置可能であり、例えば、（Ｃ１）メディアサーバ、（Ｃ２）トランスコーディング機能は、図３におけるＩＰＴＶサービス２５０内に構成してもよいし、その他ネットワーク接続機器に独立した構成として設定してもよい。（Ｃ３）ホームルータは、図３の構成においては、ホームネットワーク２１０内の機器に備えられ、例えばホームＩＭＳゲートウェイ２１２に備えられる。以下、これらの
（Ｃ１）メディアサーバ、
（Ｃ２）トランスコーディング機能、
（Ｃ３）ホームルータ、
の処理について説明し、さらに、
（Ｃ４）ネットワークを介した通信処理の詳細
について説明する。

（Ｃ１．メディアサーバ）
メディアサーバは、メディアレイヤの最も重要なコンポーネントであり、例えばＶｏＤ（ビデオオンデマンド）コンテンツの保存、出力や、各クライアントにおいてクライアント固有のコンテンツ記録処理として実行するネットワーク・パーソナルビデオレコーディング（ｎＰＶＲ）のためのコンテンツの保持などを実行する。さらに、メディアサーバは、例えばＶｏＤ（ビデオオンデマンド）などにおいて、スロー再生や高速送り、巻き戻し、スキップチャプタなどのトリックプレーを行うとき、必要なメディアストリーム処理を行なう。ＶｏＤ（ビデオオンデマンド）コンテンツは、コンテンツ管理システムからメディアサーバに入力される。

（Ｃ２．トランスコーディング）
トランスコーディング機能は、例えば、標準画質であるＳＤ（ＳｔａｎｄａｒｄＤｅｆｉｎｉｔｉｏｎ）および高品質画質であるＨＤ（ＨｉｇｈＤｅｆｉｎｉｔｉｏｎ）に対応するデータの変換や符号化を実行する機能である。例えば、クライアントはＳＩＰセッションセットアップで通常のＳＩＰＳＤＰネゴシエーションを使用してＩＰＴＶサービス提供サーバに対して、ストリームのコーディング態様などを交渉し、クライアントに適合した形態でコーディングされたデータを受領することができる。トランスコーディング機能は、ネットワークの利用可能な符号化態様や、ストリームのパスで利用可能な帯域幅も考慮したコーディングを実行し、クライアントの画面サイズや解像度などの適合性を考慮した処理を実行する必要がある。

（Ｃ３．ホームルータ）
多くの場合、ホームネットワークは、ＮＡＴ／ＮＡＰＴ（ネットワークアドレス変換／ネットワークアドレスポート変換）機能を提供するホームルータによって配信ネットワークに接続される。ホームルータは、フルサポートと限定されたホームルータの二つのプロファイルに分類することができる。例えば、ＩＰＴＶのサービスを受けるためには、
＊ＵＰｎＰＩＧＤ、
＊ＩＰマルチキャストパススルー、ＩＧＭＰプロキシおよびＩＧＭＰＳＮＯＯＰＩＮＧ、
＊ＤＳＣＰからレイヤ２優先タグ（８０２．１ｐ、ＷＭＭ）へのマッピングを含む優先順位を付けたＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅｓ）サポート、
＊ＤＨＣＰサーバ機能によるパラメータに従ったリレー、
これらの能力をサポートする構成とすることが好ましい。

（Ｃ４．ネットワークを介した通信処理の詳細）
次に、上述した各機能、すなわち、
（Ｃ１）メディアサーバ、
（Ｃ２）トランスコーディング機能、
（Ｃ３）ホームルータ、
これらの各機能を利用したネットワーク通信の詳細について説明する。

（通信とセッションセットアップ）
ホームルータを介した通信処理では、例えば、ＮＡＴ（ネットワークアドレス変換）、ＮＡＰＴ（ネットワークアドレスポート変換）が利用される。ＮＡＴは、プライベートアドレスをグローバルアドレスに変換するために使用され、ＮＡＰＴは、多くのネットワークアドレスとＴＣＰ／ＵＤＰポートとの変換に利用される。これらの処理はホームルータによって実行されてもよく、ネットワーク上のＮＡＴ／ＮＡＰＴルータによって実行されてもよい。

例えば、図３に示すホームネットワーク２１０内のホームＩＭＳゲートウェイ２１２などのＩＭＳクライアントとＩＭＳネットワーク２３０中のＣＳＣＦ２３１内のプロキシＣＳＣＦ間のＳＩＰメッセージはＩＰｓｅｃを使用して転送される。それらの間にＮＡＴ／ＮＡＰＴルータが存在する場合、ＩＰｓｅｃＥＳＰパケット［ＥＳＰ］のＵＤＰカプセルが使用される。

ＮＡＴ／ＮＡＰＴルータは、ホームルータを通してマルチキャストストリーミング配信をサポートするため、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）プロキシおよびＩＧＭＰスヌーピング機能性も有する。ホームルータにＮＡＴ／ＮＡＰＴ経路決定機能性が備えられる場合、ＩＭＳゲートウェイによって管理される。ＩＧＭＰスヌーピング機能が正しく作動するため、ＩＰマルチキャストパケットの受信を希望するデバイスによって、ＩＧＭＰメンバーシップレポートが生成されなければならない。たとえば、マルチキャストストリーミングのＩＧＭＰメンバーシップレポートは、ＩＭＳゲートウェイによってではなく、ＩＰＴＶクライアントによって生成される。

（ＳＮＴＰ（ＳｉｍｐｌｅＮｅｔｗｏｒｈＴｉｍｅＰｒｏｔｏｃｏｌ）の利用）
ＩＰＴＶシステム内のクライアント、例えば図３に示すホームＩＭＳゲートウェイ２１２やＴＶ２１３は、タイムスタンプを設定し記録を開始するなどのために例えば０．１秒単位の正確な時間を必要とする。ＩＰＴＶシステムでは、クライアントは、シンプルネットワークタイムプロトコルクライアント［ＳＮＴＰ］をインプリメントする。ＳＮＴＰクライアントは、定義されるマルチキャストチャネルでタイム信号を受け取ることができる。

（プロトコル）
ＩＰＴＶサービスにおいてメディア（番組）通信に利用するメディアプロトコルは、メディアプレーンのリアルタイムオーディオ／ビデオストリーミングのトランスポートとコントロール機能を提供することが必要であり、例えば以下のプロトコルが利用される。

＊ＭＰＥＧ−２ＴＳ
ＩＰＴＶの放送ＴＶとＶｏＤサービスのすべてのメディアストリーミングは、ＭＰＥＧトランスポートストリーム（ＭＰＥＧ−２ＴＳ）に従う。メディア同期には、ＭＰＥＧタイムスタンプが使用される。

＊ＲＴＰ（Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）
ＭＰＥＧ−２ＴＳパケットは、ＲＦＣ３５５０とＲＦＣ２２５０に適合するＲＴＰプロトコルによって搬送される。

＊ＲＴＣＰ（Ｒｅａｌ−ｔｉｍｅＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）
ＲＴＣＰは、オプションとしてメディアサーバとクライアントの両方に適用できる。ユニキャストまたはマルチキャストの何れかに関して、ＲＴＣＰプロトコルはＲＦＣ３５５０に適合するものとする。互換性を達成するため、すべてのメディアサーバとクライアントはＲＴＣＰのサポートありとなしの両方のインプリメンテーションを前提とする。たとえば、メディアサーバはセンダレポートを送ることができますが、クライアントはレシーバレポートによって応答することができない。また、ＲＴＣＰ情報は、ストリーミングの前にＳＤＰによって無視されることができる。

＊ＦＥＣ（ＦｏｒｗａｒｄＥｒｒｏｒＣｏｒｒｅｃｔｉｏｎ（フォワードエラーコレクション））
ＩＰＴＶネットワークにおけるパケットのロスは、現行のインターネットに比較してそれほど頻繁には発生しないが、高いビットレート（例えばＨＤストリーミング）でのデータ送信を実行する場合には、頑丈なトランスポートが必要であり、パケットロス率の基準として、例えば「２時間のコンテンツ当たりパケットロス率１以下」を用いる。２時間のＨＤコンテンツは約１０Ｍ−ＩＰパケットを含み、したがって、パケットロス率は１０−７以下であることが要求される。
オーディオ／ビデオの品質を維持するため、パケットロス率が上記定義よりも大きい場合、パケットのロスは回復できる。ＩＰＴＶはフォワードエラーコレクション（ＦＥＣ）を採用し、エラー修正を行なう。なお、互換性を達成するため、もとのＲＴＰストリームから別のＩＰポートでＦＥＣが送られます。ＦＥＣトランスポートフォーマットはＲＦＣ２３７７とその拡張に基づくものとする。ＦＥＣ情報は将来別のバージョンを可能にするようにＳＤＰによって記述される。

＊ＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅＳｔｒｅａｍｉｎｇＰｒｏｔｏｃｏｌ）
すべてのメディアサーバとクライアントは、例えば、スロー再生や高速送り、巻き戻し、スキップチャプタなどのトリックプレーを含む再生制御を実現するため、ＲＴＳＰ（ＲＦＣ２３２６）をサポートする。ＲＴＳＰのトランスポートのためにはＴＣＰが使用される。マルチキャストの場合、ＲＴＳＰは使用されない。
ＩＰＴＶシステムでは、クライアントはＳＩＰプロトコルでメディアセッションを確立し、セッションセットアップの後、プレイバックコントロールのためＲＴＳＰが使用される。

（メディアコンテンツのフォーマットおよび配信）
ビデオコンテンツのメディアコーディックのためには、ＭＰＥＧ−２パート２とＭＰＥＧ−４パート１０（ＡＶＣまたはＨ．２６４としても知られる）が使用される。ＴＶ番組などメディアの配信は、クライアントとサーバ間のセッション設定後、専用のメディアサーバによって管理するが可能であり、配信データのトランスコーディングや符号化もメディア配信用のネットワークを介して実行される。

（ユニキャストストリーミングによるデータ送受信処理）
例えばＶｏＤ（ビデオオンデマンド）やＥＰＧ取得などに際しては、クライアントからの要求により、ユニキャストストリームがブラウジングによってセットアップされる。例えば、クライアント側のユーザがＶｏＤタイトルを選択する場合、ストリームを識別するＳＩＰ−ｉｎｖｉｔｅが、クライアント側のＩＰＴＶコントロール機能によって、クライアントからたとえばＲＴＳＰなどのプロトコルを利用して希望のコンテンツを持つメディアサーバ（例えば図３に示すＩＰＴＶサービス２５０）に送られる。

セッションの開始準備ができると、クライアントのＩＰＴＶコントロール機能はクライアントのＳＩＰｉｎｖｉｔｅに応答し、ストリームがクライアントからのＲＴＳＰＰＬＡＹで、直接メディアサーバに対して、またはＲＴＳＰプロキシとして行動するＩＰＴＶコントロール機能を介して始動する。

ユニキャストストリームは、たとえばｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）やＶｏＤ（ビデオオンデマンド）において利用される。ＩＰＴＶのユニキャストストリームは、ＭＰＥＧ−２トランスポートストリームとしてＭＰＥＧ−２またはＭＰＥＧ−４パート１０フレームをカプセル化し、次にＲＴＰパケットとして設定される。ＲＴＰパケットはＵＤＰ／ＩＰで転送される。

（マルチキャストストリーミングによるデータ送受信処理）
マルチキャストストリーミングは、通常、ＴＶ放送の視聴を実現するために使用される。マルチキャストのリソース保存には次の２つのオプションがある。
（ａ）ＳＩＰＳＤＰからプロキシＣＳＣＦによってなされるリソースリクエスト、
（ｂ）ＩＧＭＰからのＩＰエッジからなされるリソースリクエスト（ＩＰエッジデバイスは、アクセスと総合ネットワークのアップストリームエッジに位置するホームネットワークとＩＰバックボーンネットワーク間の最初のＩＰノードである。

上記の（ａ）のシナリオでは、ユーザが特定のＩＰＴＶプロバイダから最初にＴＶの視聴を開始するとき（どのチャネルが利用可能かを確認するためＥＰＧをブラウジングする）、例えば図３に示すクライアントとしてのホームＩＭＳゲートウェイ２１２またはＴＶ２１３は、例えば図３に示すＩＭＳネットワーク２３０のＡＳ２３３や、ＩＰＴＶサービス２５０のＩＰＴＶコントロール機能に対するＳＩＰｉｎｖｉｔｅを実行し、ネットワークから利用可能なリソースを獲得する。クライアントは、外部サーバの提供可能なコンテンツに対応するコンテンツリストを外部サーバから受信する処理において、外部サーバに対するユーザプロファイルまたはクライアントプロファイルの提供に基づいて、提供プロファイルに応じて選択されるチャネルに対応するコンテンツリストを取得する処理を実行する。

利用可能なリソースの識別子であるリソースＩＤはＥＰＧメタデータに記入されている。リソースが割り当てられると、クライアントは該当のマルチキャストグループに結合するため、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）において規定されるＩＧＭＰ−ｊｏｉｎ（ＩＧＭＰ加入）メッセージを送る。加入するマルチキャストグループはリンキングメカニズムでＥＰＧから検索される。クライアントは、外部サーバの提供可能なコンテンツに対応するコンテンツリストを外部サーバから受信する処理において、外部サーバに対するユーザプロファイルまたはクライアントプロファイルの提供に基づいて、提供プロファイルに応じて選択されるチャネルに対応するコンテンツリストを取得する処理を実行する。

例えば、クライアント側のユーザが、同じリソースＩＤを持つ同じＩＰＴＶサービスプロバイダに所属する異なるチャネル間を切換えると、追加のＳＩＰメッセージ送信は実行されない。これは、チャネル切換え／ザッピングでの余分な潜伏を避けるためである。チャネル切換えは、古いチャネルのために、ＩＧＭＰ−ｌｅａｖｅ（ＩＧＭＰ離脱）を、新しいチャネルのためにＩＧＭＰ−ｊｏｉｎ（ＩＧＭＰ加入）を送ることによって実行される。しかし、ユーザがリソース要件の異なるチャネルに切り換えると、クライアントはセッションパラメータの変化を通知し、プロキシＣＳＣＦにリソース割当ての変更を可能にさせるため、ＩＰＴＶコントロール機能にＳＩＰＵＰＤＡＴＥを送る。リソースが変更されると、クライアントは新しいマルチキャストグループのためにＩＧＭＰ加入メッセージを送信する。このように、クライアントは、チャネル切換えがサービスプロバイダの切換えを伴う場合にＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）に従ったＳＩＰメッセージ送信を実行し、同一のサービスプロバイダの提供コンテンツのチャネル切換えにおいては、ＳＩＰメッセージ送信を実行しない。

上記の（ｂ）のシナリオでは、リソース要件の異なるチャネル変更の間にＳＩＰ更新メッセージが不要であることを例外として、チャネル変更動作は同じとなる。さらに、すべてのリソースリクエストはＩＧＭＰレポートの結果としてＩＰエッジデバイスによって行われる。リソースがチャネル変化のために不十分な場合は、マルチキャスト結合は行われない。（ｂ）のシナリオでは、ＳＩＰセッションはリソース管理のためというより、むしろサービス監視が目的となる。

クライアントは、例えば図３に示すＨＳＳ２３３の保持する加入者プロファイルに従ってユーザが参加することを許可されるＩＧＭＰチャネルを限定する機能を含む。さらに、ネットワークのアクセスノードは、オプションとして、加入者が一定のチャネルに参加することを許可される検証を実行できる。マルチキャストストリームの通信メカニズムの基本はユニキャストと同じであるが、ＩＰレイヤでのソースと目的地アドレスはメディアサーバとマルチキャストグループに従って設定される。

クライアント側で実行するマルチキャスト配信コンテンツと、ユニキャスト配信コンテンツの切換え処理についてまとめる。クライアント装置のデータ処理部は、例えば図３に示すＩＰＴＶサービス２５０などの外部サーバの提供するマルチキャスト配信コンテンツの受信に際して、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）に従ったメッセージとして、ＩＧＭＰ−ｊｏｉｎ（ＩＧＭＰ加入）メッセージを前記外部サーバまたは管理サーバに送信し、マルチキャスト配信コンテンツの受信を停止し、ユニキャスト配信コンテンツの受信を開始する場合には、ＩＧＭＰに従ったメッセージとして、ＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）メッセージを外部サーバまたは管理サーバに送信する処理を実行する。

また、クライアントのデータ処理部は、ＴＶ放送受信においてはマルチキャスト配信コンテンツの受信処理を実行し、ＶｏＤ（ビデオオンデマンド）の実行に際してユニキャスト配信への切換え処理を実行する。さらに、ユーザ固有のコンテンツ記録処理として実行されるｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の処理に際してユニキャスト配信への切換え処理を実行する。また、コンテンツの特殊再生処理としてのトリックプレーの実行に際してもユニキャスト配信への切換え処理を実行する。なお、クライアントのデータ処理部は、ユーザプロファイルまたはクライアントプロファイルに対応したコンテンツリスト受信のための処理として、ユニキャスト配信への切換え処理を実行する。

（サービス品質の管理）
ＩＰＴＶシステムでは、ホームネットワーク内を除き、すべてのネットワークセグメントのサービスの品質を管理できる。トラヒック管理は、図３に示すネットワーク構成においてネットワークを介した通信において実行される。通信データの品質管理処理について図１８を参照して説明する。ＩＰＴＶのＱｏＳ（ＱｕｏｒｉｔｙｏｆＳｅｒｖｉｃｅｓ）コントロール／管理は、図１８に示すように、ＲＡＣＳ（リソースおよびアドミッションコントロールサブシステム）に基づいて実行される。ＲＡＣＳは、ポリシーコントロール、リソース保存およびアドミッションコントロールを担当する。これは、サービスがＲＡＣＳを介してトランスポートリソースをリクエストすることを可能にする。現行のＲＡＣＳ範囲は、ＩＰＴＶシステムで利用される複数のネットワークの相互接続を含む。ＲＡＣＳアーキテクチャは、ＳＰＤＦ（サービスポリシー決定機能）とＡ−ＲＡＣＦ（アクセスリソースおよびアドミッションコントロール機能）を含む。

通信実行アプリケーション（たとえば図３に示すＩＭＳネットワーク２３０のＣＳＣＦ２３１のプロキシＣＳＣＦ）は、アプリケーションレイヤＱｏＳ情報（たとえばＳＤＰに定義されるパラメータ）を、ＳＰＤＦに送られるＱｏＳ情報にマップする。ＳＰＤＦはプロキシＣＳＣＦまたは別の物理的ノードの論理エンティティとすることができ、この処理に必要な情報はユーザがマルチキャストチャネルまたはユニキャストセッションを要求する際に、クライアントから送られるＳＩＰｉｎｖｉｔｅメッセージから得られる。

アクセスネットワークに位置するＡ−ＲＡＣＦは、ＳＰＤＦからリクエストを受け取り、これらのリクエストとＡ−ＲＡＣＦに保存されるポリシー情報に基づいて、Ａ−ＲＡＣＦはそのコントロール内にあるトランスポートリソースに対するこれらのリクエストを受入れまたは拒否することができる。これは、ＩＰエッジとアクセスノードを含み、最終的に応答が生成されアプリケーションに提供される。

（リソース保存の失敗および失敗通知について）
ＲＡＣＳはリソース保存に責任がある。以下、リソース保存の失敗と、失敗通知処理について説明する。ＲＡＣＳはリソース保存に失敗した場合、すなわち、ＳＰＤＦがＡ−ＲＡＣＦから保存失敗通知を受け取ると、ＳＰＤＦは、通信エラーコードの通知処理として、Ｅｘｐｅｒｉｍｅｎｔａｌ−Ｒｅｓｕｌｔ−ＣｏｄｅＡＶＰを次の値と共に通信実行アプリであるプロキシＣＳＣＦに戻す。
＊失敗したリソース保存の場合、ＩＮＳＵＦＦＩＣＩＥＮＴ＿ＲＥＳＯＵＲＣＥＳ
＊リソース保存を変更できなかった場合、ＭＯＤＩＦＩＣＡＴＩＯＮ＿ＦＡＩＬＵＲＥ

通信実行アプリであるプロキシＣＳＣＦは、受け取ったエラーコードを、ＳＩＰエラーコードにマップし、それをターミナル（クライアント）に送り返す、すなわち、ＳＩＰＩＮＶＩＴＥまたはＳＩＰＵＰＤＡＴＥを拒否する必要がある。なお、この処理の［ＳＥＴＵＰ］のために、"ＰｒｅｃｏｎｄｉｔｉｏｎＦａｉｌｕｒｅ" ＳＩＰステータスコードが使用できる。

（通信データの順位付けについて）
たとえばホームネットワーク内の通信データの優先順位は、優先マーキングに基づいて行なうことができる。このアプローチは、ＤＬＮＡガイドラインに従っている。例えば通信データの種類（トラヒックタイプ）と優先度（優先［ＤＬＮＡ］）とのマッピング規則が設定され、この規則に基づいて通信データの優先度が決定される。

［３．ＩＰＴＶサービスの具体的処理例について］
次に、ＩＰＴＶサービスの具体的処理例について、以下の２項目に分けて、順次説明する。
３−１．通信処理の具体的処理例について
３−２．各種サービスの具体的処理例について

［３−１．通信処理の具体的処理例について］
ＩＰＴＶサービスにおいて番組などのコンテンツとしてのメディアはＩＰネットワークで配布され、アイデンティティ（識別子）管理、認証、および認可などにＩＭＳを使用する。ＩＰＴＶシステムは、データ通信が信頼性のある、認証され、認可された方法で取り扱われるのを保証するためにＩＭＳを使用する。ＩＰＴＶサービスでは、メディアストリームの配信に際してＳＩＰを使用し、他の機能を実行するためにもＳＩＰ使用する。ＩＭＳ利用の利点は、すべてのＳＩＰメッセージが自動的にＩＭＳプロキシを通過することであり、このことは、メッセージのコンテンツとヘッダが、たとえばサービスの正しい品質の設定のような自動化されたインタラクションのために使用できるということを意味する。

ＩＰＴＶアーキテクチャは、ＳＩＰに変換されるＤＬＮＡ通信とも相互接続するように設計されており、システムの他の部分では、たとえばコンテンツ管理機能のコンポーネントと相互に作用するとき、ＩＰＴＶアプリケーション機能はＳＩＰ信号通信をＩＰＴＶコントロール機能から受け取り、それを別のプロトコル（ＨＴＴＰなど）に変換する。これらの処理は主にＩＭＳのアプリケーションサーバ（ＡＳ）によって行われる。

以下、３つのＩＰＴＶサービスの具体的展開例として、
３−１−１．展開シナリオ１
３−１−２．展開シナリオ２
３−１−３．展開シナリオ３
これらの３種類の展開シナリオについて説明し、さらに、
３−１−４．クライアントのネットワーク接続処理
３−１−５．クライアントのネットワーク切断処理
３−１−６．クライアントのサービス発見処理
これらについて説明する。

以下に説明する展開シナリオ１と２は非常に似ているように見えるが、実際には非常に異なる。主要な相違は、シナリオ１では、各ターミナルが独自のプライベートＩＭＳ識別子（アイデンティティ）を所有していると仮定されるが、シナリオ２ではターミナルが同じプライベートＩＭＳ識別子を共有する点である。ユーザの観点からは、これは見えないが、オペレータにとっては、ネットワーク管理の方法と加入の処理方法の大きな相違になる。なお、以下説明するシナリオは相互に排他的ではなく、補足的であり、同じネットワークで同時に発生可能である。

（３−１−１．展開シナリオ１：各クライアントがＩＭＳターミナルとして構成される場合）
まず、図１９以下を参照して、各クライアントがＩＭＳターミナルとして構成される場合の処理例について説明する。

図１９には、クライアント（ホームネットワーククライアント）７１０、ＩＭＳネットワーク７２０、ホームネットワーク７３０、ＩＰネットワーク７４０を示している。クライアント（ホームネットワーククライアント）７１０は、ＩＰＴＶサービスを受領する構成としてＴＶ（ＤＭＰ）７１１とホームＩＭＳゲートウェイ７１２を有し、ＩＭＳネットワーク７２０は、図３を参照して説明したようにＣＳＣＦ７２１、ＨＳＳ７２２、ＡＳ７２３を有している。また、これらは、コンテンツ制御を実行するコントロールマネージメントファンクション、サービス提供を行なうサービス提供ファンクション、およびその他の登録処理や通信仲介などの制御を実行するＩＭＳコア部分に分割して示している。様々な処理は（ａ）アプリケーション層、（ｂ）コントロール層、（ｃ）メディア層に区分して、各層間の通信を伴う処理として行われる。

まず、展開シナリオ１は、クライアント（ホームネットワーククライアント）７１０内のＴＶ（ＤＭＰ）７１１とホームＩＭＳゲートウェイ７１２間に物理的境界がなく、これらの装置が一体化されている場合の処理例である。図１９は、クライアントの登録処理例であり、クライアントとしてのＴＶ（ＤＭＰ）７１１からホームＩＭＳゲートウェイ７１２を介して登録要求が、ＩＭＳネットワーク７２０のＩＭＳコアに送られ、サービス提供ファンクションにおいて登録処理が実行される。

登録が行われた後、クライアントであるＴＶ（ＤＭＰ）７１１は［ＳＩＰＳＵＢＳＣＲＩＢＥ］をＩＭＳネットワーク７２０のコンテンツマネージメントファンクションに含まれるＩＰＴＶコントロール機能に送ると、図２０に示すように、コンテンツマネージメントファンクションのＩＰＴＶコントロール機能は、マルチキャストデータチャネルのアドレスとＥＰＧのＵＲＬを含む［ＳＩＰＮＯＴＩＦＹ］をクライアントに提供する。

ＳＩＰＮＯＴＩＦＹを受信した後、クライアントであるＴＶ（ＤＭＰ）７１１はマルチキャストチャネルで聞き取りを開始する。また、ＥＰＧの最初のページをダウンロードし、これを表示し（ユーザがＥＰＧで開始するように構成されている場合）、場合によっては多くのページをダウンロードする。ＥＰＧ受信後、ユーザは見るチャネルを選択する。このとき［ＴＳＩＰＩＮＶＩＴＥ］がＩＰＴＶコントロール機能に送られ、この機能はそれを捕捉して正しいＱｏＳをセットアップする。ユーザは次にチャネルを見始め、マルチキャストチャネル間を切り換える。図２１は、ユーザによるチャネル選択処理を実行した際の通信シーケンスについて示している。

ユーザがストリームを要求するとき、ＱｏＳは、［ＳＩＰＩｎｖｉｔｅ］から取られる情報を使用するプロキシＣＳＣＦからのリクエストにより、または、ＩＧＭＰとマルチキャストストリームの要件の知識を使用するＩＰエッジデバイスからのリクエストにより、Ａ−ＲＡＣＦ（図１８参照）が管理する。プロキシＣＳＣＦがアクセスリソースを要求するときのオプションのために、ユーザが、同じリソースの要件を持つチャネルのグループ内のチャネルを切り換えるとき、ＳＩＰメッセージはＩＰＴＶコントロール機能に送られないが、ユーザが、例えばｐａｙ−ｐｅｒ−ｖｉｅｗチャネルに切り換えるとき、または異なるリソースの要件を持つグループ内のチャネルに切り換えるとき、ＩＰＴＶコントロール機能は、Ｐ−ＣＳＣＦがリソースの必要条件を変更できるため、通知を受け取る必要がある。ＩＰエッジデバイスがリソースへのアクセスを要求するオプションで、ＳＩＰメッセージはユーザがｐａｙ−ｐｅｒ−ｖｉｅｗに切り換える時のみ必要となる。

（３−１−２．展開シナリオ２：クライアントがＳＩＰクライアントであるがＩＭＳクライアントではない場合）
次に、展開シナリオ２では、図２２に示すようにＩＰＴＶクライアントであるＴＶ（ＤＭＰ）７１１とホームＩＭＳゲートウェイ７１２間には物理的分離があり一体化されていない個別の装置である場合について説明する。ＩＰＴＶクライアントには分離したＩＳＩＭ（ＩＰＭｕｌｔｉｍｅｄｉａＳｅｒｖｉｃｅｓＩｄｅｎｔｉｔｙＭｏｄｕｌｅ）はない。ＩＭＳＧＷのＩＳＩＭはすべてのクライアントによって共有される。

この場合、ホームＩＭＳゲートウェイ７１２はプロキシとして使用され、ＩＰＴＶクライアントであるＴＶ（ＤＭＰ）７１１はＩＭＳコアに直接登録するが、ホームＩＭＳゲートウェイ７１２はメッセージをＩＭＳコアに渡す。コントロール情報は、ホームＩＭＳゲートウェイ７１２を通してＳＩＰを使用して渡され、メディアは、メディアサーバ（コンテンツプロバイダドメイン内の）からＩＰＴＶクライアントに直接配信される。サービスにアクセスするには、ＩＭＳ識別情報（ＩＭＳＰＵＩＤ）が必要となる。この場合のフローは、基本的には展開シンリオ１の流れと同じで、主な相違は、登録がホームＩＭＳゲートウェイ７１２を通して行われることである。ユーザはＥＰＧおよびメディアストリームをシナリオ１と同様にして取得する。

（３−１−３．展開シナリオ３：ＤＬＮＡ−ＩＰＴＶの相互接続の場合）
ホームネットワークがＤＬＮＡを使用する場合、ＩＰＴＶシステムのＳＩＰ通信とＤＬＮＡシステムのＨＴＴＰ通信の間、およびＩＰＴＶシステムのＩＰ（ＤＶＢカプセス化を使用する）によるメディア配信とＤＬＮＡシステムのＨＴＴＰをベースとするメディア配信の間をブリッジする必要がある。この目的で、二つの異なるシステムをブリッジするゲートウェイ、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイがある。

図２３に示すように、ＤＬＮＡデバイス７１３がＩＰＴＶサービスプロバイダからメディアストリームを要求するとき、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイはホームＩＭＳゲートウェイ７１２に接続し、シナリオ２と同様に、ＩＭＳクライアントを持たないＳＩＰクライアントとして同様に登録する。例えば図２３に示す例では、ＴＶ（ＤＭＰ）７１１がＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイとして機能する。ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＩＭＳクライアントを持たない場合と同様にＳＩＰクライアントとしてネットワークに接続するときも登録することができる。

この展開シナリオ３は２つの方法で実現できる。一つは展開シナリオ１に基づく方法であり、もう一つは展開シナリオ２に基づく処理として実現する。図２３に示す点線７１５は、ＩＰＴＶクライアントであるＴＶ７１１とホームＩＭＳゲートウェイ７１２が、物理的に一体でも分離可能でもよいことを意味する。以下、ＩＰＴＶおよびＤＬＮＡアプリケーションゲートウェイの５つのユースケースについて説明する。ＩＰＴＶシステムの観点から、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイはＩＰＴＶクライアントとして行動する。

この展開シナリオ３において実行される以下の具体的処理例について説明する。
３−１−３ａ．２ＢＯＸＰＵＬＬ
３−１−３ｂ．３ＢＯＸＰＵＬＬ
３−１−３ｃ．ダウンロード
３−１−３ｄ．２ＢＯＸＰＵＳＨ
３−１−３ｅ．アップロード

（３−１−３ａ．２ＢＯＸＰＵＬＬ）
ＤＬＮＡで規定される２ＢＯＸＰＵＬＬシナリオ、すなわち、ＤＭＳ（デジタルメディアサーバ）とＤＭＰ（デジタルメディアプレーヤ）が１対１で接続して処理を行なう構成では、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＵＰｎＰＡＶメディアサーバ（ＵＰｎＰデバイス）をインプリメントするＤＬＮＡデジタルメディアサーバ（ＤＭＳ）として機能する。ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＤＬＮＡデジタルメディアプレーヤ（ユーザによって操作される）のリクエストに応じて、ＥＰＧ／ＶｏＤコンテンツリストやその他の番組コンテンツなどのメディアのフォーマットおよびプロトコルを、ＤＬＮＡプロトコルに変換する。

（３−１−３ｂ．３ＢＯＸＰＵＬＬ）
ＤＬＮＡで規定される３ＢＯＸＰＵＬＬシナリオ、すなわち、ＤＭＳとＤＭＰおよびＤＭＣ（デジタルメディアコントローラ）が接続して処理を行なう構成では、３ＢＯＸＰＵＬＬシナリオでは、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、２ＢＯＸＰＵＬＬのユースケースと同様、ＤＬＮＡデジタルメディアサーバとして機能する。しかし、２ＢＯＸＰＵＬＬシナリオとは違いがある。ユーザは、ＤＬＮＡデジタルメディアコントローラ（ＤＭＣ）を操作してＥＰＧ／ＶｏＤコンテンツリストをブラウズし、デジタルメディアレンダラにビデオコンテンツをプレイさせる。

（３−１−３ｃ．ダウンロード）
ダウンロード処理においては、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは２ＢＯＸＰＵＬＬユースケースと同様に、ＤＬＮＡデジタルメディアサーバとして機能する。２ＢＯＸＰＵＬＬとの相違は、ダウンロードコントローラ（＋ＤＮ＋）がＤＭＳよって提供されるビデオコンテンツをダウンロードすることである。コンテンツはＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイに出力できないが、その代わりにリクエストに応じてダウンロードされる（たとえばＶｏＤサービスのため）。

（３−１−３ｄ．２ＢＯＸＰＵＳＨ）
ＤＬＮＡで規定される２ＢＯＸＰＵＳＨユースケース、すなわち、コンテンツ配信機能を持つコントローラと、再生機能を持つデジタルメディアレンダラー（ＤＭＬ）とが１対１で接続して処理を行なう２ＢＯＸＰＵＳＨユースケースでは、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＵＰｎＰＡＶレンダラのためにＵＰｎＰコントロールポイントをインプリメントするＤＬＮＡＰｕｓｈコントローラ（＋ＰＵ＋）として機能する。

一般に、ユーザは、クライアントデバイスを操作して、ＩＰＴＶサービスのＥＰＧ／ＶｏＤに対応するコンテンツリストをブラウズし、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイのＤＬＮＡＰｕｓｈコントローラによって提供されるビデオストリーミングを伝えるためにＤＬＮＡＰｕｓｈコントローラがＤＬＮＡメディアレンダラをコントロールする方法で、ＤＬＮＡデジタルメディアレンダラに、選択されたビデオコンテンツをプレイさせることができる。

（３−１−３ｅ．アップロード）
アップロード処理では、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイは、ＵＰｎＰＡＶサーバ（ＵＰｎＰデバイス）のためにＵＰｎＰコントロールポイントをインプリメントするＤＬＮＡアップロードコントローラ（＋ＵＰ＋）として機能する。一般に、ユーザはクライアントデバイスを操作してＩＰＴＶサービスのＥＰＧ／ＶｏＤコンテンツリストをブラウズすることができる。ＤＬＮＡデジタルメディアサーバは、ＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイのＤＬＮＡアップロードコントローラによって提供される選択ビデオコンテンツを保存する。

（３．１．４．クライアントのネットワーク接続処理）
次に、ＩＰＴＶサービスを受領するためのクライアントのネットワーク接続処理例について、図２４以下を参照して説明する。

図２４は、クライアントのネットワーク接続処理の一例を示すシーケンス図である。左から例えば図３に示すＴＶ（ＤＭＰ）に対応するクライアント、ホームＩＭＳゲートウェイ、さらに、ＩＭＳネットワークの構成要素であるＣＳＣＦ、ＨＳＳ、ＡＳ（ＩＰＴＶ）を示している。なお、ＩＭＳネットワークのＣＳＣＦについては先に説明したプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）を個別に示してある。

まず、ステップＳ５０１においてクライアントはＩＰアドレスを取得し、ステップＳ５０２において登録要求を出力する。登録要求は、ホームＩＭＳゲートウェイからＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）に通知され、ステップＳ５０３において、Ｓ−ＣＳＣＦにおいてＨＳＳからのユーザプロファイル取得が実行され、ステップＳ５０４においてクライアントに要求応答通知が行われる。

この後、ステップＳ５０５においてクライアントとＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）間にＩＰＳｅｃ通信が可能とする設定がなされ、これ以後の通信はＩＰＳｅｃに従って実行される。ステップＳ５０６では、クライアントからＩＰＴＶサービスの登録要求が出力され、これをＩＭＳネットワークの構成要素であるＣＳＣＦのサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）が受領して、ステップＳ５０７においてＡＳの選択処理を行い、ステップＳ５０８において、選択されたＡＳに登録要求を行なう。

ＡＳ（ＩＰＴＶ）は、ステップＳ５０９においてＩＰＴＶプロファイルを取得して、ステップＳ５１０においてクライアントに対して登録完了通知を行なう。クライアントは登録完了通知の受領に基づいて、ステップＳ５１１においてコンテンツ取得要求をＡＳに出力し、ステップＳ５１２においてＡＳからコンテンツを取得する。

図２５は、クライアントによる登録処理ではなく、ホームＩＭＳゲートウェイによる登録処理が行われる場合のシーケンス図である。まず、ステップＳ５２１においてホームＩＭＳゲートウェイはＩＰアドレスを取得し、ステップＳ５２２において、登録要求を出力する。登録要求は、ホームＩＭＳゲートウェイからＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）に通知され、ステップＳ５２３において、Ｓ−ＣＳＣＦにおいてＨＳＳからのユーザプロファイル取得が実行され、ステップＳ５２４においてホームＩＭＳゲートウェイに要求応答通知が行われる。

この後、ステップＳ５２５においてホームＩＭＳゲートウェイとＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）間にＩＰＳｅｃ通信が可能とする設定がなされ、これ以後の通信はＩＰＳｅｃに従って実行される。ステップＳ５２６では、ホームＩＭＳゲートウェイからＩＰＴＶサービスの登録要求が出力され、これをＩＭＳネットワークの構成要素であるＣＳＣＦのサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）が受領して、ステップＳ５２７においてＡＳの選択処理を行い、ステップＳ５２８において、選択されたＡＳに登録要求を行なう。

ＡＳ（ＩＰＴＶ）は、ステップＳ５２９においてＩＰＴＶプロファイルを取得して、ステップＳ５３０においてホームＩＭＳゲートウェイに対して登録完了通知を行なう。

図２６は、クライアントとホームＩＭＳゲートウェイとの通信と、ホームＩＭＳゲートウェイとＩＭＳネットワークとの通信を個別に実行する場合のシーケンス例である。まず、ステップＳ５４１においてクライアントはホームＩＭＳゲートウェイに対して、登録要求を送信する。この場合のクライアントアドレスは、ホームネットワーク内のアドレス（＠ｈｏｍｅ）である。ホームＩＭＳゲートウェイはクライアントからの登録要求を受信すると、グローバルアドレス（＠ｏｐ．ｃｏｍ）に変換した後、登録要求をＩＭＳネットワークに出力する。登録要求は、ＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービング（Ｓｅｒｖｉｎｇ）ＣＳＣＦ（Ｓ−ＣＳＣＦ）に通知され、ステップＳ５４２において、Ｓ−ＣＳＣＦにおいてＨＳＳからのユーザプロファイル取得が実行され、ステップＳ５４３においてホームＩＭＳゲートウェイに要求応答通知が行われる。

この後、ステップＳ５４４においてホームＩＭＳゲートウェイとＩＭＳネットワークの構成要素であるＣＳＣＦのプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）間にＩＰＳｅｃ通信が可能とする設定がなされ、これ以後の通信はＩＰＳｅｃに従って実行される。ステップＳ５４５では、ホームＩＭＳゲートウェイからＩＰＴＶサービスの登録要求が出力され、これをＩＭＳネットワークの構成要素であるＣＳＣＦのサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）が受領して、ステップＳ５４６においてＡＳの選択処理を行い、ステップＳ５４７において、選択されたＡＳに登録要求を行なう。

ＡＳ（ＩＰＴＶ）は、ステップＳ５４８においてＩＰＴＶプロファイルを取得して、ステップＳ５４９においてホームＩＭＳゲートウェイに対して登録完了通知を行なう。この通知は、ホームＩＭＳゲートウェイからホームネットワークを介してクライアントに通知される。クライアントは登録完了通知の受領に基づいて、ステップＳ５５０においてコンテンツ取得要求をホームＩＭＳゲートウェイに出力する。ホームＩＭＳゲートウェイには、この要求をＡＳに出力し、ステップＳ５５１においてＡＳからコンテンツを取得し取得コンテンツをクライアントに転送する。

なお、先に図２３を参照して説明したようなＤＬＮＡデバイス７１３に対するＩＰＴＶサービスの提供を可能とする設定を行なう場合は、ホームＩＭＳゲートウェイはＩＰＴＶコントロール機能を発見し、ＥＰＧデータを受け取った後、ＤＬＮＡデバイスとＩＰＴＶサービスの間の相互接続を実行するための［ＩＰＴＶＤＬＮＡａｐｐＧＷ］を有効化（イネーブル）する。［ＩＰＴＶＤＬＮＡａｐｐＧＷ］がＵＰｎＰデバイスとして、すなわちＤＬＮＡメディアサーバとして機能する場合、ＩＰＴＶＤＬＮＡａｐｐＧＷはＵＰｎＰコントロールポイント［ＳＳＤＰ］によって発見されるＳＳＤＰ（ＳｉｍｐｌｅＳｅｒｖｉｃｅＤｉｓｃｏｖｅｒｙプロトコル）を始動する。ＩＰＴＶＤＬＮＡａｐｐＧＷがＵＰｎＰコントロールポイントとして、すなわち、ＤＬＮＡＰｕｓｈコントローラとして機能する場合、ＩＰＴＶＤＬＮＡａｐｐＧＷは、ＵＰｎＰデバイスのＳＳＤＰを始動する必要はなく、その代わりにＵＰｎＰデバイスを発見するため、ＵＰｎＰコントロールポイントのＳＳＤＰを始動する。

なお、ＤＬＮＡプロトコル、すなわち、ＵＰｎＰデバイスアーキテクチャのデバイス発見とデバイスコントロールはセッションレス通信に基づくので、ＵＰｎＰコントロールポイントがＵＰｎＰデバイスと通信を行うセッションを設立するという概念はない。デジタルメディアサーバ、すなわちＵＰｎＰデバイスがネットワークで利用可能な間、デジタルメディアプレーヤとデジタルメディアレンダラ、すなわちＵＰｎＰコントロールポイントは、いつでも、メディアストリーミングに関するコントロールとＨＴＴＰリクエストのためにＳＯＡＰメッセージを要求することができ、ＩＰＴＶＤＬＮＡａｐｐＧＷのＤＭＳは、例えば最悪でも３０秒以内にリクエストに応答しなければならない。

ＩＰＴＶＤＬＮＡａｐｐＧＷのＤＭＳがネットワークで利用可能な間、ＩＰＴＶＤＬＮＡａｐｐＧＷは、ＩＭＳコア（ＣＳＣＦ）およびＩＰＴＶコントロール機能へのセッションを維持することができるが、ＩＰＴＶＤＬＮＡａｐｐＧＷは、セッションが終結された場合、ＤＭＰからのＳＯＡＰリクエストとＨＴＴＰリクエストの要求のあるとき、セッションを再設定することができる。ＩＰＴＶＤＬＮＡａｐｐＧＷが、Ｐｕｓｈコントローラとして、すなわち、ＵＰｎＰコントロールポイントとして行動する場合、セッションが維持される長さを知ることができる。

ＩＰＴＶサービスのチャネルを変更する場合、ＤＬＮＡデバイスからのチャネル変更のＨＴＴＰリクエストは、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）に変換される。例えばＩＰＴＶ−ＤＬＮＡアプリケーションゲートウェイによってＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）に変換される。

（３−１−５．クライアントのネットワーク切断）
次に、ＩＰＴＶサービスからの切断処理について説明する。ＩＰＴＶサービス受領クライアントにおいてディスプレイがオフにしてクライアントをネットワークから切断することができる。このＩＰＴＶサービスからの切断処理は、例えば以下のシーケンスに従って実行される。
（ステップ１）
クライアントがメディア受信を停止する。
なお、マルチキャストの場合、ＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）を使用して、ユーザが見ていたチャネルと関連するマルチキャストストリームから離脱することになる。
（ステップ２）
クライアントはＳＩＰＢＹＥをＩＰＴＶサービス提供主体に送り、メディア受信に関連するＳＩＰセッションを完成させる。
なお、ユニキャストの場合は、ＩＰＴＶサービス提供主体はＲＴＳＰＴＥＡＲＤＯＷＮコマンドを実行してＲＴＰユニキャストフローを停止し、メディアサーバがＳＩＰプロトコルに気付いていない場合はポートを閉じる。
（ステップ３）
クライアントはＥｘｐｉｒｅ０でＳＩＰＳＵＢＳＣＲＩＢＥをＩＰＴＶサービス提供主体に送り、ＩＰＴＶＡＳにクライアント側でスイッチオフされることを知らせる。
（ステップ４）
クライアントはサービス満了時間と共にＳＩＰＲＥＧＩＳＴＥＲを送り、クライアント識別子の登録を解除する。なおこの登録情報の取得にはサービングＣＳＣＦからの受領データ（ＧＲＵＵ：ＧｌｏｂａｌｌｙＲｏｕｔａｂｌｅＵｓｅｒＡｇｅｎｔＵＲＩ）が必要となる。
（ステップ５）
クライアントはコントロールチャネルのためにＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）を送る。
（ステップ６）
ＩＰＴＶサービスおよびＩＭＳから切断される。

（ＩＰＴＶサービスからの無制御の切断）
例えば停電の発生などの場合、上述したシーケンスを実行することなく切断がなされる場合がある。すなわちＩＰＴＶサービスからの無制御の切断がなされることがある。この場合、送信されている番組などのメディアフローは停止することが必要となる。しかし、この場合には以下の事項、すなわち、
（ａ）メディアフローの停止処理
（ｂ）ネットワークのＳＩＰダイアログ
これらを考慮した処理を行なうことが必要である。以下、これらについて説明する。

（ａ）メディアフローの停止処理
クライアントがマルチキャストメディアストリームを受信している場合、これらのメディアストリームを停止する唯一の方法は、ＩＧＭＰｖ３のデフォルトのタイムアウト（［ＩＧＭＰ］に従ったグループメンバーシップインターバルで２２５秒）が適用可能である。
ユニキャスト送信の場合、メディアのユニキャストトランスポートメカニズムのほとんどは、フィードバック情報を受信する処理が行われ、このフィードバック情報にタイムアウト時間が設定され、このタイムアウト時間を利用した停止処理が可能となる。

（ｂ）ネットワークのＳＩＰダイアログ
ネットワークのすべてのＳＩＰ状態は、通常デフォルトの満了値が３６００秒である。この状態はＳＩＰＲＥＧＩＳＴＥＲ、ＳＵＢＳＣＲＩＢＥ、およびＩＮＶＩＴＥに関連する。タイムアウトメカニズムは、ＩＭＳコアの状態をクリア（タイムアウト以内に再接続が発生した場合に起こるのは、新しい登録の後にタイマが増す）する。
ＳＩＰの状態が１時間アクティブに維持されるという事実は、トラヒックが１時間送られるということを意味しない。事実、目的地に達しない最初のＮＯＴＩＦＹの後、ＩＭＳコアは、クライアントの利用不能について通知され、それに従って状態をクリアする。

（３−１−６．クライアントのサービス発見処理）
ＩＭＳネットワークでＩＰＴＶサービスプロバイダの発見を行なう処理について説明する。ＩＰＴＶサービスプロバイダは、例えば下記のようにして発見され、ユーザに提示され、ユーザによる選択が可能となる。なお、この処理は、ユーザがＩＭＳ登録を終了していることが前提条件となる。

クライアントは最初にＩＭＳプロバイダに要求してＩＰＴＶサービスプロバイダの発見を試みる。これが失敗した場合、ＩＭＳプロバイダ以外のエンティティ、例えば、ルートに要求を行うことも可能である。サーバプロバイダ発見プロセスは、ＩＰＴＶサービスを提供するＩＰＴＶサービスプロバイダの発見から始まる。

ＩＭＳネットワークでＩＰＴＶサービスプロバイダを発見するために使用できる多くのモデルがあるが、これらはすべて、ネットワークには、サービスを提供する能力のあるアプリケーションサーバ（ＡＳ（ＩＰＴＶ））が存在するということ、および、ＩＰＴＶサービスプロバイダが、ＰＳＩ、特徴タグ、またはその他のＳＩＰヘッダで識別できるということを前提にしている。

サービスプロバイダ発見のステップは、例えば、「ＩＰベースネットワークでのＭＰＥＧ−２ＴＳベースＤＶＢサービスのトランスポート」の高レベルの記述に従って実行する。ユーザ認証の通信としてＳＩＰを使用し、情報をブートストラップするための、たとえばＰ−Ａｓｓｅｒｔｅｄ−ＩｄｅｎｔｉｔｙなどのＩＭＳトラストモデルを使用する。サービスＩＰＴＶで始まるＤＶＢＩＰデルを使用するＳＩＰリクエストは、ＩＰＴＶプロバイダとなることができる。たとえば、ＳＰＣＡＮＡＬ＋はドメイン名、で識別し、サービスはサービス対応の名前を割り当てることができる。

これが失敗した場合、下記のプロセスが実行される。
ＩＰＴＶアプリケーションが開始されたときにＩＰＴＶサーバが割り当てられていない場合、ＩＰＴＶアプリケーションは、ＩＰＴＶサービスブートストラップサービスまたはデフォルトのアドレスを使用する。
ＩＰＴＶクライアントによってＩＰＴＶＳＩＰダイアログのコントロール信号通信が設定され、ＩＭＳネットワークＣＳＣＦに経路が定められる。これは、サービスの正確なアドレスは後に追加できるので知る必要がないということも意味する。ＩＭＳネットワークでは、ＣＳＣＦは、ＩＰＴＶＳＩＰダイアログがＩＰＴＶダイアログであることを理解し、その経路をＩＰＴＶＣＦ（ＣｏｎｔｒｏｌＦｕｎｃｔｉｏｎ）に定める必要がある。これでＩＰＴＶＣＦはサービスプロバイダと提供されるサービスに関する発見情報を提供できる。

ＩＰＴＶサービスプロバイダに関する情報（例えばＳＩＰＵＲＩなど）がＳＩＰダイアログを使用してユーザに提供され、ユーザがＩＰＴＶサービスプロバイダを発見すると、これらのプロバイダがユーザに提示される。ユーザは次にＩＰＴＶサービスプロバイダの提供するＥＰＧ（あるいはＶｏＤとｎＰＶＲコンテンツリストなど）を受け取ることができる。

（ＵＰｎＰでのサービス発見）
次にＵＰｎＰによるサービス発見処理について説明する。
ＩＰＴＶクライアントはプロキシＣＳＣＦのＩＰアドレスをＳＩＰのＤＨＣＰオプションから取得し、またはＩＭＳオペレータのＩＳＩＭ（ＩＰＭｕｌｔｉｍｅｄｉａＳｅｒｖｉｃｅｓＩｄｅｎｔｉｔｙＭｏｄｕｌｅ）カードに記載されるプロキシＣＳＣＦのデフォルトのＩＰアドレスを使用する。

あるいは、ＩＰＴＶクライアントはＵＰｎＰ発見メカニズムを使用してホームＩＭＳゲートウェイを発見する。ホームＩＭＳゲートウェイはＵＰｎＰサービスであるＵＰｎＰＩＭＳＧＷサービスをインプリメントする。ＵＰｎＰＩＭＳＧＷサービスを発見するために、ＩＰＴＶクライアントは、ＳＳＤＰ：Ｍ−Ｓｅａｒｃｈの送信またはＳＳＤＰを受信するなどＳＳＤＰを使用した処理を行なう。ＩＰＴＶクライアントがＵＰｎＰＩＭＳＧＷサービスを発見すると、ＩＰＴＶクライアントは、ＩＭＳＧＷのＩＭＳＢ２ＢＵＡのＩＰアドレスとポートの取得要求を行い、次に、ＩＰＴＶクライアントは、ホームＩＭＳＧＷを介してＩＭＳコアとのＳＩＰセッションを開始し、ＩＰＴＶサービスを発見する。

例えば図２３を参照して説明したＤＬＮＡデバイスによるサービス発見の場合の処理シーケンスは以下のようになる。ＤＬＮＡデバイスのＵＰｎＰコントロールポイントは、前述した２ＢＯＸＰＵＬＬ、ＤＯＷＮＬＯＡＤ、および３ＢＯＸＰＵＬＬの場合にＩＰＴＶＤＬＮＡａｐｐＧＷでＤＭＳを発見できる。ＩＰＴＶサービスのサービス発見は、前述と同じ方法でホームＩＭＳＧＷによって実行される。複数のＩＰＴＶサービスを展開する方法はベンダによって異なる。たとえば、ＩＰＴＶＤＬＮＡａｐｐＧＷは、それぞれＩＰＴＶサービスに対応する複数のＤＭＳを使用できる。各ＤＭＳには、ユーザがＩＰＴＶサービスのために適切なＤＭＳを選択できるように、対応のＩＰＴＶサービスを識別できるＵＰｎＰデバイスとしての名前が設定される。
２ＢＯＸＰＵＳＨおよびＵＰＬＯＡＤの場合は、ＩＰＴＶ−ＤＬＮＡアプリケーションＧＷは、ＩＰＴＶ−ＤＬＮＡアプリケーションＧＷが発見されるＵＰｎＰデバイスをインプリメントする必要がないように、ＤＬＮＡデバイスのＵＰｎＰデバイスをコントロールする。

［３−２．各種サービスの具体的処理例について］
次に、ＩＰＴＶサービスにおいて実行される様々なサービスについて説明する。以下の各項目について順次、説明する。
３−２−１．ＴＶ放送
３−２−２．ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）
３−２−３．ＶｏＤ（ビデオオンデマンド）
３−２−４．コンテンツフィルタリングおよびパーソナライゼーション
３−２−５．ＴＶとのインタラクション
３−２−６．プロファイル管理
３−２−７．デバイス能力に対する適合処理

（３−２−１．ＴＶ放送）
ＩＰＴＶサービスにおいては、チャネル切換えだけではなく、ＥＰＧの閲覧も、ＴＶ放送と同程度に迅速にユーザに提供することが必要である。ＥＰＧメタデータ送信によるユーザメタデータ待ち時間を最小限にするため、ある期間（例えば８日間）のプログラムに関するＥＰＧメタデータをクライアントにプリロードし、ＥＰＧ配信のシステムの１秒当りのトランザクションと必要帯域幅を最小限にするため、サービス情報、すなわちＴＶチャネル情報とＥＰＧ、すなわちＴＶプログラム情報は、マルチキャストデータチャネルを介して配信する。図１５を参照して説明したクライアントのＩＰＴＶコンテンツブラウザとＩＰＴＶナビゲーションアプリケーションは、ＭＤＣコントロール機能を使用してＥＰＧメタデータを検索する。

ＥＰＧメタデータはユニキャストによっても配信される。ＩＰＴＶサービスの提供する番組に対応する基本的なプログラムに対応するＥＰＧメタデータや、統計的に人気のあるプログラムなどのＥＰＧメタデータは、マルチキャストによって配信されるが、その他のプログラム情報やサムネールイメージのようなさらにリッチな情報の高度なＥＰＧメタデータは、ユニキャストを使用して検索により取得することができる。

ＩＰＴＶサービスプロバイダによって提供されるＥＰＧメタデータは、単独のマルチキャストデータチャネルによって定期的に配信される。図１５を参照して説明したクライアントのマルチキャストチャネルコントロール機能は、チャネル加入のような、タグ付きのＥＰＧメタデータを、クライアント構成に従ってフィルタにかけ、フィルタにかけられたＥＰＧメタデータをメモリに保存する。ＩＰＴＶサービスブラウザとＩＰＴＶナビゲーションアプリケーションは、ＥＰＧデータを検索するのにＭＤＣコントロール機能を使用する。ＥＰＧメタデータを送信するサイクルタイムは情報のタイプによって異なる。

ＴＶチャネルのマルチキャストチャネルアドレスと、現在放送中のコンテンツ（番組）と次のコンテンツに関するＥＰＧメタデータを含むサービス情報は、たとえば２秒ごとのように頻繁に送信される。今日の番組プログラムに対応するＥＰＧメタデータは、たとえば３０秒ごとに送信される。

放送ＴＶサービスのＴＶプログラムは、予めスケジュールが決定されるので、クライアントは、一日に一度、将来のプログラムの新しいＥＰＧメタデータを検索すれば十分となる。しかし、緊急ニュースや野球ゲームの延長戦など臨時に発生するプログラムスケジュールの変更をクライアントに通知するため、ＥＰＧメタデータの更新も、たとえば２秒ごとなど定期的にマルチキャストデータチャネルを通して配信される。クライアントは、ＥＰＧメタデータの更新を受け取るために、マルチキャストチャネルを通してメディアストリームを受け取るとき、ＥＰＧメタデータのマルチキャストデータチャネルを監視する。

マルチキャストデータチャネルを通して配信されるＥＰＧメタデータは、番組情報であるプログラムに関する基本的な情報を含むデータであり、プログラムに関する詳細情報と、プログラムの基本情報にリンクされるプログラムに関する関連情報を取得するために、クライアントはＥＰＧサーバへのユニキャストリクエストを使用することができる。プログラム情報はテキスト、映像、音声などによって構成され、これらのプログラム提示におけるユーザとのインタラクションは、双方向ユニキャストコミュニケーションで実現可能である。なお、ＥＰＧや番組情報のメニューにおいては、メニューを表示するクライアントのディスプレイにサブ画面を設定してプレビュービデオストリームが表示可能である。

なお、ＥＰＧは、ユーザあるいはクライアント毎のパーソナライズ、すなわち、ユーザやクライアントに対応する固有のＥＰＧの設定として提示することが可能となる。例えば、チャネルごとのＥＰＧのパーソナライゼーションは、ユーザプロファイルに関するチャネル加入に従ってＥＰＧが構成されるのと同様に実現することができる。ユーザプロファイルによっては、特定チャネルに関するプログラム情報は表示されない。ＥＰＧメニューに関するチャネルの表示順序も、ユーザプロファイルに従ったパーソナライズ、すなわち各ユーザ対応の処理が可能となる。

ＴＶ放送チャネルの切換え
ＩＰＴＶサービスの提供においては、例えばネットワークによるジッタの除去など、再生処理をスムーズに行なうためクライアントにおいてパケットのバッファリングが行われる。クライアントはＩＰＴＶサービスの提供サーバから受信するデータを一定の閾値になるまでバッファに蓄積し、その後に再生のための復号などのプロセスを実行する。また画像の再構成のためマルチキャスト送りでイントラフレームの送受信が実行される場合がある。

また、帯域幅の消耗を避けるため、チャネル切換えに際しては、前の視聴の終了した古いチャネルの終結処理も行なう。この処理はＩＧＭＰ参加に類似する処理であるＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）によって実行可能である。この処理に際してはすべてのＩＧＭＰａｗａｒｅノードでチェックされ、古いマルチキャストデータを受け取るノード・リストとの比較が実行され、あるノードがマルチキャストデータの受信を停止する場合、マルチキャストツリーからノードが切り取られる処理が行われる。

クライアントにおいて、受信するビデオストリームの復号、再生を実行するためには、受信ストリームから多くの情報を収集する必要がある。これらの情報は、特定の周波数で送られる。特に、新しいビデオ送りの映像の表示を開始するには、デコーダはイントラフレームがビデオストリームで到着するまで待つ必要がある。イントラフレームは、完全な映像を再構成するため、それ自体に十分な情報を含むフレームとして構成される。これらは通常、符号化タイプによって、０．５〜５秒周期で送信される。

ＩＰＴＶサービスにおけるデータ通信において発生する可能性のある遅延には様々なものがある。例えば、新しいストリームの設定時のＳＩＰインタラクションの処理も遅延要因となり得る。例えばＳＩＰインタラクションの処理において実行するＳＩＰＩＮＶＩＴＥに関する処理が遅延要因として考えられる。従ってＳＩＰインタラクションの処理を削減することが遅延解消の１つの対策としてある。具体的には、マルチキャストストリームの特性が、マルチキャストチャネル間で変化するときのみＳＩＰダイアログが発生する設定とすることが有効である。このアイデアに従って、クライアントが通常の放送チャネルに合わせるとき、ストリーム特性を持つマルチキャスト送信を要求してＳＩＰセッションを設立し、それ以外のマルチキャストチャネルの変化は、ＳＩＰ介入のないＩＧＭＰインタラクションのみを必要とする設定とし、受信ストリームの特性が異なる場合のみ、ＳＩＰダイアログと交換する構成とする。さらに、新しいチャネル用のＳＩＰＩＮＶＩＴＥとＩＧＭＰ参加を送る。ＩＧＭＰのセットアップにおいて発生する遅延は、エンドユーザにできるだけ近いところでマルチキャストチャネルを利用可能にすることによって改善できる。しかし、これは、アクセスネットワークでより多くの帯域幅を消費する。

ＭＰＥＧストリームの復号を開始するために必要とするイントラフレームの遅延も改善されるべき点である。ネットワークにおいてクライアントから比較的近いポイントからｐｕｌｌメカニズムでイントラフレームを取得する構成や、帯域外メカニズムによってクライアントにイントラフレームを提供することによって、イントラフレームの遅延を解消することが可能となる。

（３−２−２．ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング））
次にＩＰＴＶサービスにおいて利用可能なサービスの１つであるｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）について説明する。

ｎＰＶＲの記録
ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）によるコンテンツの記録は、様々な方法で開始できる。これは主としてＩＰＴＶサービスプロバイダによって異なる。
＊番組などのプログラムを記録する最も簡単な方法は、ＥＰＧで番組を選択し、ユーザの所有するリモコンで記録ボタンを押すことである。また、ユーザが記録する時間、日、長さなどを入力する構成としてもよい。
あるいは、クライアントに提供される番組をすべて記録する設定としてもよい。これは、ＩＰＴＶサービスプロバイダがすべてを記録し、それを予め指定された時間サーバに保存することを意味する。このようにして、ユーザは記録に悩まされることがなく、過去の通常のＥＰＧと同様に見えるｎＰＶＲＥＰＧを見ることができる。

ＩＰＴＶアーキテクチャがサポートする必要があるのは、記録すべきプログラムを識別するインタフェースと、これをＥＰＧで達成するための識別メカニズムである。リンクのメカニズムは、できればＴＶ放送と同じとして、記録処理のためのコマンド通信は、ＲＴＳＰＲＥＣＯＲＤコマンドか、または記録の詳細を含むｎＰＶＲへのＳＩＰＩＮＶＩＴＥなどを利用可能である。

例えばユーザがＩＰＴＶサービスにおいて受信再生しているコンテンツについて個人的な録画を要求する場合の処理としてトリックプレーがある。例えば、クライアントがリモコンでポーズボタンを押すことでｎＰＶＲ記録機能を実行させ、次に、ピクチャをフリーズし、マルチキャストチャネルからＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）を実行する。さらに、クライアントはコンテンツを保存する。なお、データ保存は、サーバにおいて実行する構成とすることもできる。後に、ユーザがそれをもう一度見たくなったとき、ｎＰＶＲ検索を実行してＲＴＳＰＰＬＡＹコマンドで再生を行なうことができる。

ｎＰＶＲにおいて利用可能なコンテンツリスト（目次）は、ＥＰＧおよびＶｏＤと同じコンテンツフォーマットとメタデータを使用可能である。ＶｏＤの場合のように、ユニキャストソースを識別するために、リンキングがＩＰＴＶコントロール機能によって行われることを除いて、ＴＶ放送と同じリンキングメカニズムを使用しなければならない。ｎＰＶＲコンテンツリストの検索は、通常ＨＴＴＰＧＥＴとして実行される。クライアントが利用可能なｎＰＶＲコンテンツの検索処理のために、ＩＰＴＶサービスプロバイダは、サーバをベースとする検索機能を提供する。検索ページのインタフェースは完全にサービスプロバイダに依存する。

ｎＰＶＲにおいて記録したコンテンツの再生処理においては、最初に目的のｎＰＶＲコンテンツを選択することが必要となる。ｎＰＶＲコンテンツリストのリンクをクリックすることで検索される。コンテンツ検索は、ユニキャストストリームとして実行される。すなわち、ユーザが"ｐｌａｙ"を押すか、またはコンテンツリストのリンクをクリックすると、ストリームが開始する。

ユーザ固有のコンテンツ記録処理として実行するｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の処理を実行する場合の、クライアントの装置構成は、例えば以下のような構成となる。クライアントとしての情報処理装置は、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、外部サーバの提供するコンテンツ提供サービスの受領処理を実行するデータ処理部を有し、データ処理部は、外部サーバの提供するコンテンツについてのユーザ固有のコンテンツ記録処理として実行するｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の処理制御を行なう。

データ処理部は、外部サーバの提供するＴＶ放送受信においてはマルチキャスト配信コンテンツの受信処理を実行し、ユーザ固有のコンテンツ記録処理として実行されるｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の処理に際してユニキャスト配信への切換え処理を実行する。また、ユニキャスト配信コンテンツの受信を開始する場合には、ＩＧＭＰ（ＩｎｔｅｒｎｅｔＧｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）に従ったメッセージとして、ＩＧＭＰｌｅａｖｅ（ＩＧＭＰ離脱）メッセージを外部サーバまたは管理サーバに送信する。

さらに、クライアントのデータ処理部は、ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）に際して、外部サーバ、または他のネットワーク接続サーバに依頼して、これらのサーバの記憶手段を利用してコンテンツ記録を実行させることも可能である。この場合、記録コンテンツ情報、時間情報などの記録に必要とする情報をこれらのサーバに提供する。また、クライアントのデータ処理部は、ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の実行可能なコンテンツに対応するコンテンツリストを外部サーバから受信する処理において、外部サーバに対するユーザプロファイルまたはクライアントプロファイルの提供に基づいて、提供プロファイルに応じて選択されるコンテンツリストを取得する処理を行なう。さらに、クライアントのデータ処理部は、ｎＰＶＲ（ネットワーク・パーソナルビデオレコーディング）の実行に際して、ＥＰＧ（電子プログラムガイド）におけるコンテンツ選択情報、または、記録時間指定情報を外部サーバまたは管理サーバに出力する処理を実行する。このような処理によってｎＰＶＲが実行される。

また、クライアントは、ホームネットワークではないパブリックネットワークを介して提供されたＩＰＴＶに関するコンテンツを受信する情報処理装置であり、パブリックネットワークに接続された外部サーバを、仮想的なホームネットワーク機器として設定する手段と、外部サーバをユーザ固有のコンテンツを記録または再生するパーソナルビデオレコーダとして機能させるように、外部サーバにおけるコンテンツの記録または再生処理を、パブリックネットワークを介して制御する制御手段とを有している。さらに、クライアントの制御手段は、特定のコンテンツを特定のユーザのみに提供するユニキャストを実現するために、外部サーバにおけるコンテンツの再生処理をパブリックネットワークを介して制御する処理を行ない、さらに、外部サーバを、ユーザコンテンツを記録するパーソナルビデオレコーダとして機能させるように、外部サーバにおけるコンテンツの記録または再生処理をパブリックネットワークを介して制御する処理を行なう。

（３−２−３．ＶｏＤ（ビデオオンデマンド））
ＶｏＤ（ビデオオンデマンド）は、クライアント側のユーザのリクエストに応じてコンテンツを配信する仕様である。基本的にユニキャストで実行される。ＶｏＤで配信されるコンテンツ（メディア）に対して広告の挿入や、広告に基づく検索は、放送サービスやＥＰＧと同じように実行することができる。

また、ＶｏＤに利用可能なコンテンツリスト（目次）については、クライアント側でブラウズできる。このコンテンツリスト（目次）は、ユーザが見ることを許可されているものに限定される、すなわちフィルタをかけた結果を閲覧できる設定とする。フィルタリングはネットワーク内で実行できるが、その場合、ＶｏＤコンテンツリストはユニキャストでなければならず、または、クライアントは、ＶｏＤコンテンツリストのキャッシュをプリロードするためマルチキャストを使用できる。ＶｏＤコンテンツリストの取得は、部分的にＥＰＧ情報取得と同様である。

利用可能なＶｏＤコンテンツの検索は、クライアントがネットワークに対して問合わせ操作を実行できることを必要とする。コンテンツ検索はコンテンツメタデータで実行される。

ＶｏＤによるコンテンツ再生を行なう場合、クライアントは、ＶｏＤコンテンツリストから、見ることが認可されている利用可能なコンテンツの一つを選択してコンテンツリクエストを出力することが必要となる。たとえばコンテンツリストのコンテンツを指定すると、ＶｏＤサービスのＵＲＩのリンクが起動しＩＰＴＶコントロール機能がリクエストを処理し、ユーザがコンテンツをすでに購入しているかどうか、検証し、コンテンツが購入されていない場合は、コンテンツに関する料金を検証し、それ以外の場合は、コンテンツリクエストは拒否される。

（３−２−４．コンテンツフィルタリングおよびパーソナライゼーション）
次にＩＰＴＶサービスで実行されるコンテンツのフィルタリングとパーソナライゼーションについて説明する。コンテンツのフィルタリングとは、エンドユーザのＩＭＳおよびＩＰＴＶプロファイルと加入された一組のチャネルに基づいてエンドユーザに提供されるコンテンツをユーザに適合したもののみとするコンテンツ選択処理であり、パーソナライゼーションとは、ユーザのプロファイルに基づいてユーザに提供するコンテンツを選択する処理である。例えばユーザプロファイルに基づいた個人を対象としたメッセージと広告の配信処理が含まれる。

コンテンツのフィルタリングによって、例えばユーザが支払ったチャネルのみがユーザの取得するＥＰＧやＶｏＤリストに表示される。コンテンツフィルタリングによりログインユーザのプロファイルに合わせたＥＰＧの生成、表示が可能となる。ユーザのプロファイルは、ログインのとき、ＸＣＡＰを使用して、プロファイルを格納しているサーバ、例えば図３に示すＩＭＳネットワーク２３０のＨＳＳ２３２からダウンロードされ、ユーザ装置に保存される。ＶｏＤについては、コンテンツのフィルタリングは、サーバで提供されるＶｏＤのビューを生成するとき、またはクライアントでＶｏＤメタデータを受け取るとき適用される。なお、ユーザ側の装置であるクライアントにユーザプロファイルを格納しておいてこれを利用してもよい。

外部サーバ、あるいはクライアント装置にあるユーザプロファイル情報は、コンテンツを提供するサーバに提示され、コンテンツ提供サーバは、ユーザプロファイルに基づいて、コンテンツを選択、編集してユーザに対応するコンテンツを生成して提供するコンテンテツパーソナライゼーションを実行する。あるいは、これらのハーソナライゼーション処理は、クライアント側で実行する構成としてもよい。

コンテンツのパーソナライゼーションは、ユーザプロファイルに基づいた個人を対象としたメッセージと広告の配信処理が含まれる。これらの特定ユーザ向けのデータはユーザの装置で画面にオーバーレイされ、例えばＰｉｎＰ（ｐｉｃｔｕｒｅｉｎｐｉｃｔｕｒｅ）モードで表示される。パーソナライゼーションは、ユーザが放送のショーまたはＶｏＤコンテンツを見ている間に、ショーが広告ポーズに入るとき、目標の広告を挿入することによって実行される。インタラクティビティもユーザプロファイルに基づく一つの形のパーソナライゼーションと言える。インタラクティビティデータに含まれる情報は、個人メッセージまたは広告と同じ手段で、すなわち、オーバーレイまたは専用のウィンドウを使用して表示される。パーソナライゼーションは、専用のユニキャストチャネルを通して、またはプロファイルセット（位置の情報、年令、性別、所得範囲その他）を対象とするもっと小さなマルチキャストグループで配信される。

（３−２−５．ＴＶとのインタラクション）
例えば、クライアント側のユーザがＩＰＴＶサービスを見ながら、意見を送信する処理や、投票するといったＴＶプログラムとのインタラクションについて説明する。テレビジョンプログラムとのインターアクティビティのため、ユーザは、投票などのユーザからのデータを送ることができる（たとえばＳＭＳを介して）、例えば投票は番組に関するフィードバック情報の作成などのため集計され利用される。

なお、既存のデジタル放送システムにおいてもトリガをＭＰＥＧ−ＴＳストリームに挿入してＨＴＭＬ、ＢＭＬなどのインタラクティブオブジェクトをトリガのタイミングで与えるメカニズムによりＴＶプログラムとのインタラクションをすでにサポートしているものがある。インタラクティブオブジェクトは、通常、ＴＶプログラムと共に、ＭＰＥＧ−ＴＳストリームに埋め込まれるが、デジタル放送システムが、ＭＰＥＧ−ＴＳストリーム配信から切り離された双方向通信チャネルを介してインタラクティブオブジェクトを配信することも可能である。

ＩＰＴＶサービスに適用するブラウザを使用したメカニズムがＴＶプログラムとのインタラクションのために利用される。例えばプログラムのインタラクションを表わすＸＨＴＭＬ文書への参照情報を番組コンテンツのメタデータに埋め込む。ユーザがプログラム（番組）を見る間、インタラクティビティシステムは、プログラム（番組）とのインタラクションのためにＩＰＴＶサービスブラウザを呼び出す。ＸＨＴＭＬ文書はマルチキャストデータチャネルとユニキャスト通信を介して配信される。インタラクションのフィードバックは、ユニキャスト通信によるＩＰＴＶサービスブラウザによって実現される。

（３−２−６．プロファイル管理）
ＩＰＴＶサービスにおいては、クライアントのユーザプロファイルなど様々なプロファイルが管理される。例えば、
＊オペレータのサービスに関するサービスプロファイルとユーザプロファイル
例えば料金請求、ユーザ識別子、認証処理に利用される認証ベクタ、サービストリガなどのプロファイルは、図３に示すＩＭＳネットワーク２３０のＨＳＳ２３２に格納され保持される。
＊ユーザ自身のプロファイル
ユーザ自身のプロファイルは、ユーザ側のクライアント装置に保存される。
ＩＰＴＶプロバイダがＩＭＳプロバイダと異なる場合は、ＩＰＴＶプロバイダは、ＩＰＴＶ特有のユーザプロファイルを自身のデータベースに保存できる。
＊ＩＰＴＶプロバイダプロファイル
ＩＰＴＶプロバイダに関する情報としてのＩＰＴＶプロバイダプロファイルは、クライアント側に保存可能であり、ＩＰＴＶプロバイダ自身のデータベースにも保存される。

ユーザプロファイルには、例えば、ＳＩＰ識別子、言語、国籍、年令、（オペレータによって提供されるものとユーザによって提供されるもの）、Ｅメールアドレス、電話番号、興味と趣味（趣味嗜好情報）、ＩＰＴＶ固有パラメータなどが含まれる。これらのユーザプロファイルはサービスのパーソナライゼーション用に使用される。具体的には、ユーザの好みに基づいて、ユーザ対応のデータ（マイ・・・）の設定、提供が可能となる。例えば、マイチャネルの設定、スタートアップチャネルの設定、さらに、マイＶｏＤ、マイＰａｙＴＶ、チャネルへのボタンの個人的マッピング処理、局部的なコントロールなどがユーザプロファイルを利用して実行可能となる。

ＩＰＴＶプロバイダプロファイルは、例えば、
＊どのユーザがどのチャネルにアクセスできるかの情報、
＊ユーザが見ることを許可されるものと許可されないものを決定するために使用される加入者プロファイル、
などが含まれる。

エンドユーザであるクライアント側では、ユーザ管理と、ユーザプロファイル管理を実行する。ユーザ管理とは、ユーザがドメインにユーザを追加し、変更し、または削除できることを意味し、ユーザプロファイル管理とは、ユーザがユーザプロファイルの情報を変更できることを意味する。

クライアントのエンドユーザがユーザ管理を行なう場合の処理ステップは以下のようになる。
１．エンドユーザはＨＴＴＰポータルに新しいユーザ情報を提供する。
２．情報はＨＴＴＰポータルによってユーザ管理を実行するＩＭＳネットワーク２３０（図３参照）に送られ、ＨＳＳおよびＩＰＴＶデータベースを更新する。

クライアントのエンドユーザが実行するユーザプロファイル管理は、例えば以下の処理によって実行される。
１．新しいユーザプロファイル情報がクライアント装置に入力される。
２．クライアントはユーザプロファイル情報を管理するサーバ、例えば図３に示すＩＭＳネットワーク２３０のＨＳＳ２３２、ＩＰＴＶサービス２５０等など、予め設定されたプロファイル出力先にデータを送信し、これらのデータを受信した側において登録、更新処理が実行される。
３．情報更新を実行した各サーバは、クライアント、その他の関連サーバにデータ更新の完了を通知する。
４．クライアントは、更新されたユーザプロファイルをダウンロードする。

なお、ユーザプロファイルの登録や更新は、ＩＰＴＶサービスポータルを通して行うこともできる。この場合ユーザプロファイルは、クライアントからＩＰＴＶサービスポータルに提供され、その後、ＩＰＴＶサービスポータルが、これらのデータを、ユーザプロファイル管理サーバ（例えば図３に示すＩＭＳネットワーク２３０のＨＳＳ２３２、ＩＰＴＶサービス２５０等）に送信する。

このように、クライアントとしての情報処理装置のデータ処理部は、外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行する。クライアントのデータ処理部は、例えばＨＳＳ等の管理サーバに予め格納済みのユーザプロファイルを取得し、取得したユーザプロファイルをコンテンツ提供サーバなどの外部サーバに提供する。また、クライアント装置において更新したユーザプロファイルをＨＳＳ等の管理サーバに送信して、管理サーバに格納されたユーザプロファイルの更新処理を実行する。

クライアントのデータ処理部は、コンテンツ提供サーバなどの外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたコンテンツリスト、広告情報、ＶｏＤ（ビデオオンデマンド）対応コンテンツなどを受信して表示部に表示する処理を実行する。なお、ユーザプロファイルは、前述したようにユーザの使用言語、国籍、年令、アドレス、電話番号、趣味嗜好情報の少なくともいずれかの情報を含む。

（３−２−７．デバイス能力に対する適合処理）
クライアントには、様々な装置が設定可能であり、それぞれのクライアントの実行できる処理はクライアントに応じて異なることになる。すなわちクライアントのデバイス能力は多様なものとなる。このような様々クライアントとＩＰＴＶサービス間の相互運用性を確保するために、一組のデバイス能力プロファイルが指定され、クライアントに要求される能力が規定される。

クライアントに配信されるコンテンツがクライアントで良好に再生するためには、そのクライアントの能力を明確にすることが必要となる。クライアントデバイス能力としては、例えばスクリーンサイズ、スクリーン解像度、利用可能なメモリのサイズ、サポートするコーデックの種類などがある。

クライアントデバイスが最初にサービスの登録をするとき、ＩＭＳネットワーク２３０のＣＳＣＦ２３１デバイスの説明をダウンロードし、ダウンロードされた説明とそのＵＲＩをデータベースやリポジトリに記録し、各サーバなど他のエンティティと共有される。なお、Ｗ３ＣＤＣＩリポジトリのようなグローバルなリポジトリが利用可能な場合は、そのリポジトリを使用してもよい。

クライアントデバイスに対するＡＶコンテンツの適合処理には、適切なコンテンツバージョンの選択を必要とする場合がある。例えばテキストコンテンツの適合は、ハージョンに応じた変形、組合せ、フォーマッティング（たとえばＸＳＬＴ）などを利用することで実現される。適合処理の実行エンティティ（たとえばターゲットサーバ、トランスコーディングを行うプロキシ）は、デバイス能力を受信し、文書メタデータに表現されている一組の規則に従って文書を適合させる処理を実行する。これは、コンテンツメタデータが、適用しなければならない変形に関する規則を含まなければならないことを意味し、サービスプロファイルが、適用トランスポート、ターミナルなどに関する制約を含まなければならないということも意味する。

このように、コンテンツ提供サーバと、コンテンツ受信クライアントとを有するコンテンツ提供システムにおいて、コンテンツ受信クライアントのデータ処理部は、クライアントのデバイス情報を取得して、ホームネットワーク外にあるデータベース、例えば、ＩＰマルチメディアシステム（ＩＭＳ）において規定されるホームサブスクライバサブシステム（ＨＳＳ：ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｕｂｓｙｓｔｅｍ）に送信して登録する処理を実行する。コンテンツ提供サーバは、このＨＳＳに登録されたクライアントのデバイス情報を取得して、デバイスに適合したコンテンツをクライアントに提供する処理を実行する。具体的には、デバイス情報は、クライアントのスクリーンサイズ、スクリーン解像度、利用可能なメモリサイズ、サポートするコーデックの種類、少なくともいずれかのデバイス情報を含み、コンテンツ提供サーバは、これらのデバイス情報を取得して、デバイスにおいて再生可能なコンテンツをクライアントに提供する処理を実行する。

以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が各実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ(Local Area Network)、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本発明の構成によれば、ホームネットワーク内のクライアント機器であるコンテンツ再生装置としてのＤＭＰが、ホームネットワーク外のコンテンツ提供サーバからのコンテンツを受領して再生することが可能となる。すなわち、本発明の情報処理装置であるホームＩＭＳゲートウェイが、コンテンツ提供サーバとの通信を実行して、コンテンツ提供サーバを仮想的なホームネットワーク機器としてマッピングし、ホームネットワーク内のコンテンツ再生装置からの機器発見要求の受信に応じてコンテンツ提供サーバのサーバ情報を、サービス受領可能な機器情報としてコンテンツ再生機器に提供する。さらに、外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行することが可能となる。

Claims

情報処理装置であり、
ホームネットワークを介した通信処理を実行する通信部と、
ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ提供サービスの受領処理を実行するデータ処理部を有し、
前記データ処理部は、
前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信する処理を実行する構成であることを特徴とする情報処理装置。
前記データ処理部は、
管理サーバに予め格納済みのユーザプロファイルを取得し、取得したユーザプロファイルを前記外部サーバに提供する処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
前記データ処理部は、
情報処理装置において更新したユーザプロファイルを前記管理サーバに送信して、前記管理サーバに格納されたユーザプロファイルの更新処理を実行する構成であることを特徴とする請求項２に記載の情報処理装置。
前記データ処理部は、
前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたコンテンツリストを受信して表示部に表示する処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
前記データ処理部は、
前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定された広告情報を受信して表示部に表示する処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
前記データ処理部は、
前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたＶｏＤ（ビデオオンデマンド）対応コンテンツを受信して表示部に表示する処理を実行する構成であることを特徴とする請求項１に記載の情報処理装置。
前記ユーザプロファイルは、
ユーザの使用言語、国籍、年令、アドレス、電話番号、趣味嗜好情報の少なくともいずれかの情報を含む構成であることを特徴とする請求項１〜６いずれかに記載の情報処理装置。
情報処理装置において実行する情報処理方法であり、
通信部が、ホームネットワークを介した通信処理を実行する通信ステップと、
データ処理部が、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ受信処理を実行するコンテンツ受信ステップと、
前記データ処理部が、前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信するコンテンツ制御処理ステップと、
を実行することを特徴とする情報処理方法。
前記情報処理方法において、さらに、
前記データ処理部は、管理サーバに予め格納済みのユーザプロファイルを取得し、取得したユーザプロファイルを前記外部サーバに提供する処理を実行することを特徴とする請求項８に記載の情報処理方法。
前記情報処理方法において、さらに、
前記データ処理部は、情報処理装置において更新したユーザプロファイルを前記管理サーバに送信して、前記管理サーバに格納されたユーザプロファイルの更新処理を実行することを特徴とする請求項９に記載の情報処理方法。
前記情報処理方法において、さらに、
前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたコンテンツリストを受信して表示部に表示する処理を実行することを特徴とする請求項８に記載の情報処理方法。
前記情報処理方法において、さらに、
前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定された広告情報を受信して表示部に表示する処理を実行することを特徴とする請求項８に記載の情報処理方法。
前記情報処理方法において、さらに、
前記データ処理部は、前記外部サーバから、ユーザプロファイルに基づいてパーソナライズデータとして設定されたＶｏＤ（ビデオオンデマンド）対応コンテンツを受信して表示部に表示する処理を実行することを特徴とする請求項８に記載の情報処理方法。
前記ユーザプロファイルは、ユーザの使用言語、国籍、年令、アドレス、電話番号、趣味嗜好情報の少なくともいずれかの情報を含むことを特徴とする請求項８〜１３いずれかに記載の情報処理方法。
情報処理装置において情報処理を実行させるコンピュータ・プログラムであり、
通信部に、ホームネットワークを介した通信処理を実行させる通信ステップと、
データ処理部に、ホームネットワーク外にある外部サーバを仮想的なホームネットワーク機器として設定したマッピング情報を適用して、前記外部サーバの提供するコンテンツ受信処理を実行させるコンテンツ受信ステップと、
前記データ処理部に、前記外部サーバからのデータを、予め登録されたユーザ情報であるユーザプロファイルに基づいて選択または編集されたパーソナライズデータとして受信させるコンテンツ制御処理ステップと、
を実行させることを特徴とするコンピュータ・プログラム。