(57)【要約】  セキュアなＩＰテレビセッションを確立する方法。アプリケーション・サーバ（ＡＳ）は、ＩＰＴＶセッションを確立するために、移動体電話機やセット・トップ・ボックス（ＳＴＢ）といったＩＰＴＶ受信ノードから招待メッセージを受信する。招待メッセージは、受信ノードと関連づけられたブートストラップ・トランザクション識別子（ＢＴＩＤ）を含む。ＡＳは、ＢＴＩＤを含む認証要求をサービス接続保護サーバに送信する。ＡＳは、サービス接続保護サーバから、ＩＰＴＶ受信ノードと関連づけられ、ＩＰＴＶ受信ノードに予め与えられた長期鍵を含む認証応答を受信する。要求がＩＰＴＶコンテンツ・プロバイダ・ノードに送信され、当該要求はＩＰＴＶ受信ノードを識別する。ＡＳは、メディアを暗号化するためにＩＰＴＶコンテンツ・プロバイダ・ノードが利用するメディア暗号鍵を、受信した長期鍵で暗号化する。暗号化されたメディア暗号鍵を含む招待応答がＩＰＴＶ受信ノードに送信される。【選択図】図２
2011523283.tif 000002
【特許請求の範囲】
【請求項１】
セキュアなＩＰテレビセッションを確立する方法であって、
アプリケーション・サーバが、ＩＰテレビセッションを確立するために、ＩＰテレビ受信ノードと関連づけられたブートストラップ・トランザクション識別子を含む招待メッセージを、該ＩＰテレビ受信ノードから受信する工程と
前記ブートストラップ・トランザクション識別子を含む認証要求をサービス接続保護サーバに送信する工程と、
前記サービス接続保護サーバから、前記ＩＰテレビ受信ノードと関連づけられた長期鍵であって前記ＩＰテレビ受信ノードに予め与えられた長期鍵を含む認証応答を受信する工程と、
ＩＰテレビ・コンテンツ・プロバイダ・ノードに要求を送信する工程であって、前記要求は前記ＩＰテレビ受信ノードを識別する、工程と、
メディアを暗号化するために前記ＩＰテレビ・コンテンツ・プロバイダ・ノードが利用するメディア暗号鍵を、受信した前記長期鍵で暗号化する工程と、
暗号化された前記メディア暗号鍵を含む招待応答メッセージを前記ＩＰテレビ受信ノードに送信する工程と
を備えることを特徴とする方法。
【請求項２】
前記招待メッセージは、セッション開始プロトコルのＩｎｖｉｔｅメッセージであって、
前記ブートストラップ・トランザクション識別子は、プロキシ認証ヘッダに含まれる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＩＰテレビ・セッションは、モバイルＩＰテレビ・セッションであって、アプリケーション・サーバはモバイルＩＰテレビ・アプリケーション・サーバであることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ＩＰテレビ・セッションは、リニアＩＰテレビ・ブロードキャスト、リニアＩＰテレビ・ユニキャストおよびビデオ・オン・デマンド・ユニキャストのうちの１つから選択されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記サービス接続保護サーバは、ブートストラップ・サーバ機能であることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記メディア暗号鍵は、グループ鍵およびコンテンツ鍵のうちの１つから選択されることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記メディア暗号鍵は、前記アプリケーションサーバから前記ＩＰテレビ・コンテンツ・プロバイダ・ノードに対して送信されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記メディア暗号鍵は、前記アプリケーションサーバが前記ＩＰテレビ・コンテンツ・プロバイダ・ノードから受信することを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項９】
アプリケーション・サーバであって、
ＩＰテレビセッションを確立するために、ＩＰテレビ受信ノードと関連づけられたブートストラップ・トランザクション識別子を含む招待メッセージを、該ＩＰテレビ受信ノードから受信する第１の受信器と
前記ブートストラップ・トランザクション識別子を含む認証要求をサービス接続保護サーバに送信する第１の送信器と、
前記サービス接続保護サーバから、前記ＩＰテレビ受信ノードと関連づけられた長期鍵であって前記ＩＰテレビ受信ノードに予め与えられた長期鍵を含む認証応答を受信する第２の受信器と、
ＩＰテレビ・コンテンツ・プロバイダ・ノードに要求を送信する第２の送信器であって、前記要求は前記ＩＰテレビ受信ノードを識別する、第２の送信器と、
メディアを暗号化するために前記ＩＰテレビ・コンテンツ・プロバイダ・ノードが利用するメディア暗号鍵を、受信した前記長期鍵で暗号化するプロセッサと、
暗号化された前記メディア暗号鍵を含む招待応答メッセージを前記ＩＰテレビ受信ノードに送信する第３の送信器と
を備えることを特徴とするアプリケーション・サーバ。
【請求項１０】
前記メディア暗号鍵を含むメッセージを前記ＩＰテレビ・コンテンツ・プロバイダ・ノードから受信する第３の受信器をさらに備えることを特徴とする請求項９に記載のアプリケーション・サーバ。
【請求項１１】
前記第２の送信器は、前記メディア暗号鍵を、前記ＩＰテレビ・コンテンツ・プロバイダ・ノードへの前記要求に含めて送信するように構成されていることを特徴とする請求項９に記載のアプリケーション・サーバ。
【請求項１２】
前記アプリケーション・サーバは、モバイルＩＰテレビ・アプリケーション・サーバであって、前記ＩＰテレビ・セッションは、モバイルＩＰテレビ・セッションであることを特徴とする請求項９乃至１１のいずれか１項に記載のアプリケーション・サーバ。
【請求項１３】
前記ＩＰテレビ・セッションは、リニアＩＰテレビ・ブロードキャスト、リニアＩＰテレビ・ユニキャストおよびビデオ・オン・デマンド・ユニキャストのうちの１つから選択されることを特徴とする請求項９乃至１２のいずれか１項に記載のアプリケーション・サーバ。
【請求項１４】
ＩＰテレビ受信ノードであって、
前記ＩＰテレビ受信ノードと関連づけられたブートストラップ・トランザクション識別子および長期鍵とを格納するメモリと、
アプリケーション・サーバに、ＩＰテレビ・セッションを開始するための、前記ブートストラップ・トランザクション識別子を含む招待メッセージを送信する送信器と、
前記長期鍵を用いて暗号化されたメディア暗号鍵を含む応答メッセージを、前記アプリケーション・サーバから受信する第１の受信器と
格納された前記長期鍵を用いて前記メディア暗号鍵を復号する第１のプロセッサと、
ＩＰテレビ・コンテンツ・プロバイダ・ノードから、前記メディア暗号鍵を用いて暗号化されたＩＰテレビ・メディア・コンテンツを受信する第２の受信器と、
前記ＩＰテレビ・メディア・コンテンツを、復号された前記メディア暗号鍵を用いて復号する第２のプロセッサと
を備えることを特徴とするＩＰテレビ受信ノード。
【請求項１５】
ユーザ機器であることを特徴とする請求項１４に記載のＩＰテレビ受信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワークにおけるＩＰＴＶの分野に関連する。また、セキュアなＩＰＴＶセッション確立のための分野に関連する。
【背景技術】
【０００２】
ＩＰネットワークを介してブロードキャストされるＴＶサービスのことをＩＰＴＶと呼んでいる。ＩＰＴＶは、典型的にはブロードバンド・アクセス・ネットワークを利用したブロードキャストである。そこでは、チャンネルがブロードバンド・ネットワークを介して送信され、スーパー・ヘッドエンドからエンド・ユーザのセット・トップ・ボックス（ＳＴＢ）へ送信される。ＩＰＴＶサービスは、例えばブロードキャストＴＶである。最も一般的なＩＰＴＶチャンネルは、
普及度の低い追加的なチャンネルも同様であるが、ブロードバンド・ネットワークを介して、スーパー・ヘッドエンドからエンドユーザのセット・トップ・ボックス（ＳＴＢ）へ送信される。これらの送信のために必要とされる帯域幅を最小化するためには、ネットワークを介してマルチキャスト技術を利用することが望ましい。
【０００３】
同様に、移動体ネットワークでは、モバイルＴＶ（ＭＴＶ）のブロードキャスト／マルチキャスト伝送を利用することが望ましい。マルチメディア・ブロードキャスト・マルチキャスト・サービス（ＭＢＭＳ）及びデジタル・ビデオ・ブロードキャスティング−ハンドヘルド（ＤＶＢ−Ｈ）は、ＭＴＶブロードキャスト技術の一例である。ＭＴＶクライアント機能を有する移動体電話機（例えば、ユーザ機器：ＵＥ）は、スーパー・ヘッドエンドからコンテンツを受信するＭＴＶ環境においてＳＴＢと同等のものとみなすことができる。
【０００４】
典型的な構成では、コンテンツは、モバイルＴＶ用のＩＰマルチメディア・サブシステム（ＩＭＳ）アプリケーションサーバ（ＡＳ）、或いは、（ユニキャスト又はマルチキャスト伝送を利用する）ＩＰＴＶ用のＩＭＳ ＡＳにより制御されているコンテンツ伝送サーバであるところのメディア伝送機能（ＭＤＦ）により伝送される。
【０００５】
以下では、簡単のためにＵＥについて説明するが、当該説明は、ＳＴＢのような別のタイプのＩＰＴＶ受信機でＩＰＴＶを受信する場合にも同様に適用可能なことが理解されよう。図１を参照すると、ＭＤＦとＵＥ１との間の通信が開始される前に、ＵＥ１とコンテンツ伝送制御機能（ネットワーク・アプリケーション機能：ＮＡＦ２、これはＭＴＶ ＡＳやＩＰＴＶ ＡＳであってもよい）とは、汎用ブートストラップ認証（ＧＢＡ）手順に、認証及びサービス保護のためのＧＢＡ鍵（Ｋｓ_ｎａｆ:これよりＭＵＫ及びＭＲＫが導出される。Ｋｓ_ｎａｆについては後述する。）を確立するために参加しなければならない。
【０００６】
ＧＢＡ手順に成功すると、ブートストラップ・サーバ機能（ＢＳＦ）３によりブートストラップ・トランザクション識別子（ＢＴＩＤ）が生成され、共有鍵Ｋｓ_ｎａｆは、ブートストラップの間にＵＥ１のＵＳＩＭ／ＳＩＭ４によりローカルで生成される（Ｓ５）。図１のステップＳ４に示すように、ＢＴＩＤは、ＵＥ１によってＢＳＦ３からＨＴＴＰを利用してプルされる。Ｋｓ_ｎａｆ及びＢ_ＴＩＤは、ＵＥコンテキストの一部としてＵＥ内の安全な領域に格納される（Ｓ４）。Ｋｓ_ｎａｆは、ＵＥ１に伝送された場合に、アプリケーション特有鍵（ＭＵＫ、ＭＲＫ）を取り出し、長期鍵（ＭＳＫ）を暗号化するために後に利用できる。
【０００７】
ＢＳＦ３は、コンテキスト鍵（Ｃｋ）及びインテグリティ鍵（Ｉｋ）を取得する。これらは、ＧＢＡ手順の間に、認証ベクトルの一部としてホーム加入者サーバ（ＨＳＳ）から送信される。Ｋｓ_ｎａｆは、ＣｋとＩｋとを連結することでＢＳＦ３により計算され（同様の処理はＵＥ１内のＵＳＩＭ／ＳＩＭ４により実行される）、ＵＥ１が将来参照するのに備えてＢＳＦ３内に格納される。
【０００８】
ＭＴＶ ＡＳ／ＩＰＴＶ ＡＳ／ＢＭ−ＳＣ（ＮＡＦ）からＨＴＴＰを利用して伝送されたデータを取得するために、ＵＥはまずＭＴＶ ＡＳによって認証されなければならない。そのようなデータには、例えば、電子プログラムガイド（ＥＰＧ）や、電子サービスガイド’（ＥＳＧ）などが含まれる。ＵＥを認証するためにＵＥは、ＵＥ１からＭＴＶ ＡＳへ送信されるＨＴＴＰリクエスト（ＲＦＣ２６１７で定義されたＨＴＴＰダイジェスト認証）内でＢＴＩＤ及びＫｓ_ｎａｆを通知する。
【０００９】
ＧＢＡが認証目的で利用されるところのＨＴＴＰシグナリング手順に、ＵＥ１が含まれる場合、ＵＥ１は、図１では不図示の認証プロキシ（ＡＰ）と呼ばれる機能的なエンティティとインタラクトする。ＡＰは、このプロセスにおいてＵＥ１を表すＢＴＩＤと、ＢＴＩＤに対応するＫｓ_ｎａｆとを知っている。
【００１０】
図２を参照すると、ＮＡＦのようなノードが長期鍵を取得するための手順が示されている。ＭＴＶシグナリング手順は、ＵＥ１へ送信されるべきＩＰＴＶコンテンツの保護のために長期鍵の伝送を要求する。これらのシグナリング手順では、ＵＥ１は、先のシグナリング手順において使用されたＢＴＩＤを知らないＭＴＶ ＡＳとインタラクトする。しかしながら、ＭＴＶ ＡＳは、コンテンツ・アクセス手順の一部として長期のコンテンツ鍵の暗号化に利用するためにＫｓ_ｎａｆを要求する。
【００１１】
しかしながら、ＭＴＶ ＡＳは、ＢＳＦ２に格納されているＫｓ_ｎａｆへのアクセス権を有していないので、その時点では不可能である。
【発明の概要】
【００１２】
発明者は、ユーザ機器あるいはＩＰＴＶ受信装置のセッション開始前の認証における問題を認識している。そこで、ＵＥと関連付けられたＢＴＩＤをモバイルＴＶアプリケーション・サーバに提供し、ＭＴＶ ＡＶにＧＢＡアーキテクチャにおけるネットワーク・アプリケーション機能として動作することを可能にするための方法を提案する。
【００１３】
本発明の第１の側面によれば、セキュアなＩＰテレビセッションを確立する方法が提供される。アプリケーション・サーバ（ＡＳ）は、ＩＰテレビセッションを確立するために、移動体電話機やセット・トップ・ボックス（ＳＴＢ）といったＩＰＴＶ受信ノードから招待メッセージを受信する。招待メッセージは、ＩＰＴＶ受信ノードと関連づけられたブートストラップ・トランザクション識別子（ＢＴＩＤ）を含む。ＡＳは、認証要求をサービス接続保護サーバに送信し、当該認証要求にはＢＴＩＤが含まれている。ＡＳは、サービス接続保護サーバから認証応答を受信する。当該認証応答には、ＩＰＴＶ受信ノードと関連づけられた長期鍵が含まれ、長期鍵はＩＰＴＶ受信ノードに予め与えられたものである。要求がＩＰＴＶコンテンツ・プロバイダ・ノードに送信され、当該要求はＩＰＴＶ受信ノードを識別する。ＡＳは、メディアを暗号化するためにＩＰＴＶコンテンツ・プロバイダ・ノードが利用するメディア暗号鍵を、受信した長期鍵で暗号化する。招待応答メッセージはＩＰＴＶ受信ノードに送信され、当該応答は暗号化されたメディア暗号鍵を含んでいる。本発明は、メディア暗号鍵を暗号化するのに利用可能な長期鍵をＡＳに提供する。
【００１４】
招待メッセージは、セッション開始プロトコルの招待メッセージでもよく、ブートストラップ・トランザクション識別子は、プロキシ認証ヘッダに含まれてもよいる。サービス接続保護サーバは、ブートストラップ・サーバ機能（ＢＳＦ）でもよい。本発明は、モバイルＩＰＴＶの分野における利用に特に適している。また、別のオプションとして、ＩＰＴＶセッションがモバイルＩＰテレビ・セッションであり、ＡＳがモバイルＩＰＴＶ ＡＳであってもよい。。
【００１５】
また、ＩＰＴＶセッションは、リニアＩＰＴＶブロードキャスト、リニアＩＰＴＶユニキャストおよびビデオ・オン・デマンド・ユニキャストのうちのいずれかであってもよい。
【００１６】
また、もしＩＰＴＶセッションがユニキャストであれば、メディア暗号鍵はコンテキスト鍵でよく、もしＩＰＴＶセッションがブロードキャストであれば、メディア暗号鍵はグループ鍵でよい。
【００１７】
随意的な実施形態では、メディア暗号鍵は、ＡＳからＩＰＴＶコンテンツ・プロバイダ・ノードに対して送信され、代替的な実施形態では、メディア暗号鍵は、ＡＳがＩＰＴＶコンテンツ・プロバイダ・ノードから受信する。メディア暗号鍵は、ＩＰＴＶコンテンツ・プロバイダ・ノードが、後にＩＰＴＶ受信ノードに送信されるメディアを暗号化するのに利用するために、ＡＳからＩＰＴＶコンテンツ・プロバイダ・ノードへ送信されてもよい。また、メディア暗号鍵は、ＩＰＴＶコンテンツ・プロバイダ・ノードが生成してＡＳに提供することで、ＡＳが長期鍵を使用してメディア暗号鍵を暗号化し、ＩＰＴＶ受信ノードに送信できるようにしてもよい。メディア暗号鍵がコンテンツ鍵の場合、ＡＳは、暗号化されたコンテンツ鍵をＩＰＴＶコンテンツ・プロバイダ・ノードへ送信することもできる。
【００１８】
本発明の第２の側面によれば、ＡＳが提供される。ＡＳは、ＩＰＴＶセッションを確立するために、ＩＰＴＶ受信ノードから招待メッセージを受信する第１の受信器を備える。招待メッセージは、ＩＰＴＶ受信ノードと関連づけられたＢＴＩＤを含む。また、認証要求をサービス接続保護サーバに送信するために第１の送信器が提供され、認証要求には、ブートストラップ・トランザクション識別子が含まれる。サービス接続保護サーバから認証応答を受信するために第２の受信器が提供され、認証応答はＩＰＴＶ受信ノードと関連づけられた長期鍵を含む。ここで、当該長期鍵はＩＰＴＶ受信ノードに予め与えられたものであることに留意すべきである。ＩＰＴＶコンテンツ・プロバイダ・ノードに要求を送信するために第２の送信器が利用され、当該要求はＩＰＴＶ受信ノードを識別するものである。メディア暗号鍵を受信した長期鍵で暗号化するために、プロセッサが提供される。メディア暗号鍵は、ＩＰＴＶ受信ノードに送信されるＩＰＴＶコンテンツを暗号化するために、ＩＰＴＶコンテンツ・プロバイダ・ノードによって利用される鍵である。招待応答メッセージをＩＰＴＶ受信ノードに送信するために第３の送信器が提供され、招待応答メッセージは、暗号化されたメディア暗号鍵を含む。これにより、ＩＰＴＶ受信ノードは、ＩＰＴＶコンテンツ・プロバイダ・ノードから後に送信されるメディアを復号するためのメディア暗号鍵にアクセスすることができる。
【００１９】
ＩＰＴＶコンテンツ・プロバイダ・ノードがメディア暗号鍵を生成する場合、ＡＳはさらに、メディア暗号鍵を含むメッセージをＩＰＴＶコンテンツ・プロバイダ・ノードから受信する第３の受信器をさらに備える。また、第２の送信器は、ＩＰＴＶ受信ノードに送信されるメディアをＩＰＴＶコンテンツ・プロバイダ・ノードが後に暗号化するために使用するのに備えて、メディア暗号鍵をＩＰＴＶコンテンツ・プロバイダ・ノードへの要求に含めて送信するように構成される。
【００２０】
また、招待メッセージは、ＳＩＰ Ｉｎｖｉｔｅメッセージであってもよく、ＢＴＩＤはプロキシ認証ヘッダ内に含まれてもよい。ＡＳがモバイルＩＰＴＶ ＡＳであって、ＩＰＴＶセッションは、モバイルＩＰＴＶセッションであってもよい。ＩＰＴＶセッションは、リニアＩＰＴＶブロードキャスト、リニアＩＰＴＶユニキャスト、あるいは、ビデオ・オン・デマンド・ユニキャストのいずれかであってもよい。
【００２１】
発明の第３の側面によれば、ＩＰＴＶ受信ノードと関連づけられたブートストラップ・トランザクション識別子および長期鍵とを格納するメモリを備えるＩＰＴＶ受信ノードが提供される。ＡＳにＩＰＴＶセッションを開始するための招待メッセージを送信するための送信器が提供され、招待メッセージはＢＴＩＤを含んでいる。応答メッセージをＡＳから受信するために第１の受信器が提供され、当該応答メッセージは長期鍵を用いて暗号化されたメディア暗号鍵を含んでいる。メディア暗号鍵は、格納された長期鍵を用いて第１のプロセッサにより復号することができる。ＩＰＴＶコンテンツ・プロバイダ・ノードから、ＩＰＴＶメディア・コンテンツを受信するために第２の受信器が提供され、当該ＩＰＴＶメディア・コンテンツはメディア暗号鍵を用いて暗号化されている。第２のプロセッサとが、ＩＰＴＶメディア・コンテンツを、復号されたメディア暗号鍵を用いて復号するために用いられる。これにより、視聴者はＩＰＴＶメディアを視聴することができる。
【００２２】
また、ＩＰＴＶ受信ノードはユーザ機器であってもよい。さらに、招待メッセージはＳＩＰ Ｉｎｖｉｔｅメッセージであってもよく、ＢＴＩＤはプロキシ認証ヘッダ内に含まれてもよい。
【図面の簡単な説明】
【００２３】
【図１】汎用ブートストラップ認証の構造及びシグナリングを示すブロック図である。
【図２】ＮＡＦが長期鍵を取得するために必要とされるシグナリングを示す信号図である。
【図３】発明の実施形態に従う、ブロードキャストＩＰＴＶチャンネルをＭＴＶクライアントと確立するために必要とされるシグナリングを示す信号図である。
【図４】発明の実施形態に従う、ビデオ・オン・デマンド・ユニキャスト・セッションを確立するために必要とされるシグナリングを示す信号図である。
【図５】発明の実施形態に従う、リニアＴＶユニキャスト・セッションを確立するために必要とされるシグナリングを示す信号図である。
【図６】発明の実施形態に従うアプリケーション・サーバのブロック図である。
【図７】発明の実施形態に従うＩＰＴＶ受信ノードのブロック図である。
【発明を実施するための形態】
【００２４】
ＵＥ（或いは、ＩＰＴＶを受信するための他のあらゆる受信ノード）のような端末は、（ブロードキャスト、ユニキャスト、マルチキャスト、ビデオ・オン・デマンド、或いは、メディアコンテンツ保護を必要とする他のあらゆるタイプの伝送方法により伝送される）ＩＰＴＶチャンネルにアクセスすることを希望し、ＳＩＰ Ｉｎｖｉｔｅメッセージを送信する。ＩＭＳネットワークでは、ＳＩＰ Ｉｎｖｉｔｅメッセージはプロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）に送信される。ＳＩＰ Ｉｎｖｉｔｅメッセージは、モバイルＴＶアプリケーション・サーバ（ＭＴＶ ＡＳ）のようなアプリケーション・サーバ（ＡＳ）へルーティングされる。本発明によれば、ＵＥは、ＳＩＰ Ｉｎｖｉｔｅメッセージのプロキシ認証ヘッダ内にＢＴＩＤを含める。ＢＴＩＤは、ＭＴＶ ＡＳがＢＳＦからＫｓ_ｎａｆを取得することを可能とする。ＭＴＶ ＡＳは、長期コンテキスト鍵をＵＥに伝送する場合には、Ｋｓ_ｎａｆを使用して長期コンテキスト鍵を暗号化する。
【００２５】
図３を参照すると、発明の第１の特定の実施形態に従う、リニアＴＶブロードキャストをＭＴＶクライアント６と確立するためのシグナリングが図示されている。本例でのブロードキャストはＭＴＶ環境下でのものであって、よってＭＴＶクライアント６はＵＥ１の一部である。以下のシグナリングは、リニアＴＶブロードキャストを、ＳＴＢといった他のＩＰＴＶ受信ノードと確立するために修正されても良いことは理解されよう。以下におけるナンバリングは、図２におけるナンバリングと対応する。
【００２６】
Ｓ９：  ＭＴＶクライアント６は、ＳＩＰ ＩｎｖｉｔｅメッセージをＰ−ＣＳＣＦ７へ送信する。ＳＩＰ  Ｉｎｖｉｔｅメッセージはリニア・ブロードキャストＩＰＴＶ伝送を要求する指示を含んでいる。ＢＴＩＤは、ＧＢＡブートストラップ手順においてＵＥに予め提供されており、ＳＩＰメッセージのプロキシ認証ヘッダに含められる。
【００２７】
Ｓ１０：ＳＩＰ Ｉｎｖｉｔｅメッセージは、Ｐ−ＣＳＣＦ７からＩＭＳネットワーク内のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）８へ転送される。
【００２８】
Ｓ１１：Ｓ−ＣＳＣＦ８は、ＳＩＰ ＩｎｖｉｔｅメッセージをＭＴＶ ＡＳ９へ転送する。
【００２９】
Ｓ１２−１３：ＭＴＶ ＡＳ９は受信したＢＴＩＤを利用して、ＢＳＦ３と共にＭＴＶクライアント６を認証すると共に、Ｋｓ_ｎａｆ及びＫｓ_ｎａｆの特定の属性をＢＳＦ３から取得する。そのような属性には、Ｋｓ_ｎａｆの有効期間、タイムスタンプ等が含まれる。
【００３０】
Ｓ１４−１５：ＭＴＶ ＡＳ９はＭＳＫ（ＭＢＭＳセッション鍵）とＭＴＫ（ＭＢＭＳトラヒック鍵）とを、ＢＭ−ＳＣ１０内での暗号化のために提供する。ＭＴＫ、ＭＳＫは、ＭＴＫあるいは（ＭＳＫ）及びＭＢＭＳトラヒック鍵（ＭＴＫ）で共に暗号化される。ＢＭ−ＳＣ１０は、リニアブロードキャストＴＶのＭＴＶクライアント６に対する提供と、更新されたトラヒック鍵のＭＢＭＳセッションへアクセスするクライアントへの分配について、責任を負っている。
【００３１】
Ｓ１６：ＭＴＶ ＡＳ９は取得したＫｓ_ｎａｆを用いてセッション鍵を暗号化する。
【００３２】
Ｓ１６ａ：ＳＩＰ ２００ ＯＫメッセージが、ＭＴＶ ＡＳ９からＳ−ＣＳＣＦ８へ送信される。２００ＯＫメッセージは、取得したＫｓ_ｎａｆを用いて暗号化されたセッション鍵ＭＳＫを含む。
【００３３】
Ｓ１７：ＳＩＰ ２００ ＯＫメッセージは、Ｓ−ＣＳＣＦ８からＰ−ＣＳＣＦ７へ送信される。
【００３４】
Ｓ１８−Ｓ１９：ＩＭＳポリシ及び課金制御（ＰＣＣ）機能が利用される。一方、ＰＣＲＦ１１はブロードキャストまたはマルチキャストによるＩＰＴＶ伝送のために、いかなるポリシ実行、リソース予約或いはベアラ割当（ＱｏＳ要求により定義）も行わない。
【００３５】
Ｓ２０：ＳＩＰ ２００ ＯＫメッセージは、Ｐ−ＣＳＣＦ７からＭＴＶクライアント６へ送信され、ＭＴＶクライアントにセッション鍵ＭＳＫが提供される。
【００３６】
Ｓ２１：暗号化されたメディアコンテンツは、ＢＭ−ＳＣ１０からＭＴＶクライアント６へ伝送される。ＭＴＶクライアント６は受信したＭＳＫを利用して、コンテンツ鍵を復号する。コンテンツ鍵は、メディアコンテンツの一部として送信される。これにより、ＭＴＶクライアント６によるメディアコンテンツの復号が可能となる。エンドユーザは、メディアコンテンツを視聴することができる。
【００３７】
コンテンツ鍵は、その後にリフレッシュされてもよい点には留意すべきである。これは、ＭＳＫで暗号化したトラヒック鍵ＭＴＫを、ＭＴＶクライアントに送信されるメディアデータに含めることによって実現できる。
【００３８】
発明の第１の側面の実施形態によれば、ＭＴＶ ＡＳが、ＧＢＡアーキテクチャにおけるＮＡＦとして機能することができるように、ＭＴＶ ＡＳ６はＵＥと関連するＢＴＩＤと鍵材料を受信することができる。ゆえにＭＴＶ ＡＳには、後にＢＳＦ３からＫｓ_ｎａｆを取得するために利用されるＢＴＩＤが提供され、また、Ｋｓ_ｎａｆはＭＴＶクライアント６で使用するためにセッション鍵ＭＳＫを暗号化するのに利用される。
【００３９】
ここで図４を参照すると、発明の第２の特定の実施形態に対応するビデオ・オン・デマンド（ＶｏＤ）ユニキャストを確立するためのシグナリングが図示されている。以下におけるナンバリングは、図３におけるナンバリングと対応する。
【００４０】
Ｓ２２：ＭＴＶクライアント６はＳＩＰ ＩｎｖｉｔｅメッセージをＰ−ＣＳＣＦ７へ送信する。ＳＩＰ Ｉｎｖｉｔｅメッセージは、ＶｏＤ ＩＰＴＶ伝送要求の指示を含む。ＢＴＩＤは、ＧＢＡブートストラップ手順においてＵＥに予め提供されており、ＳＩＰメッセージのプロキシ認証ヘッダに含められる。
【００４１】
Ｓ２３：ＳＩＰ Ｉｎｖｉｔｅメッセージは、Ｐ−ＣＳＣＦ７からＩＭＳネットワーク内のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）８へ転送される。
【００４２】
Ｓ２４：Ｓ−ＣＳＣＦ８は、ＳＩＰ ＩｎｖｉｔｅメッセージをＭＴＶ ＡＳ９へ転送する。
【００４３】
Ｓ２５−２６：ＭＴＶ ＡＳ９は受信したＢＴＩＤを利用して、ＢＳＦ３と共にＭＴＶクライアント６を認証すると共に、Ｋｓ_ｎａｆ及びＫｓ_ｎａｆの特定の属性をＢＳＦ３から取得する。そのような属性には、Ｋｓ_ｎａｆの有効期間、タイムスタンプ等が含まれる。
【００４４】
Ｓ２７−２８：ＭＴＶ ＡＳ９と、ＶｏＤメディアをＭＴＶクライアント６に提供するコンテンツ・サーバ１２とは、コンテンツ鍵について交渉する。
【００４５】
Ｓ２９−３２：ＭＴＶ ＡＳ９とコンテンツ・サーバ１２は、コンテンツ・サーバ１２と端末との間で音声・ビデオストリームを提供するためのＲＴＳＰ設定手順を起動することにより、ＲＴＰ／ＵＤＰ接続を介したコンテンツ伝送に関してコンテンツサーバ１２を設定する。
【００４６】
Ｓ３３：ＭＴＶ ＡＳ９は、取得したＫｓ_ｎａｆを用いてコンテンツ鍵を暗号化する。
【００４７】
Ｓ３３ａ：ＳＩＰ ２００ ＯＫメッセージが、ＭＴＶ ＡＳ９からＳ−ＣＳＣＦ８へ送信される。２００ＯＫメッセージは、取得したＫｓ_ｎａｆを用いて暗号化されたコンテンツ鍵を含む。
【００４８】
Ｓ３４：ＳＩＰ ２００ ＯＫメッセージは、Ｓ−ＣＳＣＦ８からＰ−ＣＳＣＦ７へ送信される。
【００４９】
Ｓ３５−Ｓ３６：ＩＭＳポリシ及び課金制御（ＰＣＣ）機能は、ポリシ制御および実行、並びにリソース予約を行う。ＰＣＣルール基づき、ＰＣＲＦ１１は、ユニキャストＩＰＴＶ伝送のためにＶｏＤストリームをベアラに搬送させるべく、二次的なＰＤＰコンテキストを起動するようにＧＧＳＮに指令する。
【００５０】
Ｓ３７：ＳＩＰ ２００ ＯＫメッセージは、Ｐ−ＣＳＣＦ７からＭＴＶクライアント６へ送信され、ＭＴＶクライアントにコンテンツ鍵が提供される。コンテンツ鍵は、ＭＴＶクライアント６がＫｓ_ｎａｆを用いて復号できる。
【００５１】
Ｓ３８−Ｓ４１：ＩＭＳ ＰＣＣ機能は、適切なベアラ（ＱｏＳで定義）をユニキャストＩＰＴＶ伝送のために割り当てるのに利用される。これらのステップは、ネットワーク制御によるベアラ確立／ＰＤＰコンテキストを示すが、ＵＥ制御によるベアラ確立も本発明に同様に適用できよう。
【００５２】
Ｓ４２：ＭＴＶクライアント６は、ＶｏＤコンテンツをコンテンツ・サーバ１２に要求する。
【００５３】
Ｓ４３：コンテンツ・サーバ１２は、２００ＯＫメッセージで応答する。
【００５４】
Ｓ４４：暗号化されたＶｏＤメディア・コンテンツは、コンテンツ・サーバ１２からＭＴＶクライアント６へ伝送される。ＭＴＶクライアント６は、復号されたコンテンツ鍵を利用して、メディアコンテンツを復号する。これによりエンドユーザは、メディアコンテンツを視聴することができる。
【００５５】
図５を参照すると、発明の第３の特定の実施形態に従う、リニアＴＶユニキャストを確立するためのシグナリングが図示されている。以下におけるナンバリングは、図４におけるナンバリングと対応する。
【００５６】
Ｓ４５：ＭＴＶクライアント６はＳＩＰ ＩｎｖｉｔｅメッセージをＰ−ＣＳＣＦ７へ送信する。ＳＩＰ Ｉｎｖｉｔｅメッセージは、ユニキャスト・リニア伝送要求の指示を含む。ＢＴＩＤは、ＧＢＡブートストラップ手順においてＵＥに予め提供されており、ＳＩＰメッセージのプロキシ認証ヘッダに含められる。
【００５７】
Ｓ４６：ＳＩＰ Ｉｎｖｉｔｅメッセージは、Ｐ−ＣＳＣＦ７からＩＭＳネットワーク内のサービング呼セッション制御機能（Ｓ−ＣＳＣＦ）８へ転送される。
【００５８】
Ｓ４７：Ｓ−ＣＳＣＦ８は、ＳＩＰ ＩｎｖｉｔｅメッセージをＭＴＶ ＡＳ９へ転送する。
【００５９】
Ｓ４８−４９：ＭＴＶ ＡＳ９は受信したＢＴＩＤを利用して、ＢＳＦ３と共にＭＴＶクライアント６を認証すると共に、Ｋｓ_ｎａｆ及びＫｓ_ｎａｆの特定の属性をＢＳＦ３から取得する。そのような属性には、Ｋｓ_ｎａｆの有効期間、タイムスタンプ等が含まれる。
【００６０】
Ｓ５０−５１：ＭＴＶ ＡＳ９と、ＶｏＤメディアをＭＴＶクライアント６に提供するコンテンツ・サーバ１３とは、コンテンツ鍵について交渉する。
【００６１】
Ｓ５２−５５：ＭＴＶ ＡＳ９とコンテンツ・サーバ１３は、音声およびビデオのためにＲＴＳＰ設定について交渉する。
【００６２】
Ｓ５６：ＭＴＶ ＡＳ９は、取得したＫｓ_ｎａｆを使用してセッション鍵を暗号化する。
【００６３】
Ｓ５６ａ：ＳＩＰ ２００ ＯＫメッセージが、ＭＴＶ ＡＳ９からＳ−ＣＳＣＦ８へ送信される。２００ＯＫメッセージは、取得したＫｓ_ｎａｆを用いて暗号化されたコンテンツ鍵を含む。
【００６４】
Ｓ５７：ＳＩＰ ２００ ＯＫメッセージは、Ｓ−ＣＳＣＦ８からＰ−ＣＳＣＦ７へ送信される。
【００６５】
Ｓ５８−Ｓ５９：ＩＭＳポリシ及び課金制御（ＰＣＣ）機能は、ポリシ制御および実行、並びにリソース予約を行う。ＰＣＣルール基づき、ＰＣＲＦ１１は、ＩＰＴＶ伝送のためにユニキャスト・ストリームをベアラに搬送させるべく、二次的なＰＤＰコンテキストを起動するようにＧＧＳＮに指令する。
【００６６】
Ｓ６０：ＳＩＰ ２００ ＯＫメッセージは、Ｐ−ＣＳＣＦ７からＭＴＶクライアント６へ送信され、ＭＴＶクライアントにコンテンツ鍵が提供される。コンテンツ鍵は、ＭＴＶクライアント６がＫｓ_ｎａｆを用いて復号できる。
【００６７】
Ｓ６１−Ｓ６４：ＩＭＳ ＰＣＣ機能は、適切なベアラ（ＱｏＳで定義）をユニキャストＩＰＴＶ伝送のために割り当てるのに利用される。これらのステップは、ネットワーク制御によるベアラ確立／ＰＤＰコンテキストを示すが、ＵＥ制御によるベアラ確立も本発明に同様に適用できよう。
【００６８】
Ｓ６５：ＭＴＶクライアント６は、リニア・ユニキャスト・コンテンツをコンテンツ・サーバ１３に要求する。
【００６９】
Ｓ６６：コンテンツ・サーバ１３は、２００ＯＫメッセージで応答する。
【００７０】
Ｓ６７：暗号化されたユニキャスト・リニアＩＰＴＶメディアは、コンテンツ・サーバ１３からＭＴＶクライアント６へ伝送される。ＭＴＶクライアント６は、復号されたコンテンツ鍵を利用して、メディアコンテンツを復号する。これによりエンドユーザは、メディアコンテンツを視聴することができる。
【００７１】
図６を参照すると、発明の実施形態に対応するアプリケーション・サーバの構成例が示されている。上記のようにアプリケーション・サーバはＭＴＶ ＡＳ９である。ＭＴＶ ＡＳ９には、ＭＴＶクライアント６からＳＩＰ Ｉｎｖｉｔｅメッセージを受信するための第１の受信器１４が提供される。上記のように、ＳＩＰ Ｉｎｖｉｔｅメッセージは、ＢＴＩＤをプロキシ認証ヘッダに含む。第１の送信器１５が、認証要求をＢＳＦ３に送信するために提供され、第２の受信器１６が、ＢＳＦ３からの応答を受信するために提供される。当該応答は、Ｋｓ_ｎａｆを含む。第２の送信機１７は、要求を送信するために提供され、当該要求は、ＭＳＫとＭＴＫのようなメディア暗号鍵、あるいは、ＭＳＫ暗号化されたＭＴＫとＢＭ−ＤＳＣ１０またはコンテンツサーバ１３向けのＭＴＫを含んでもよい。第３の受信器１８は、ＩＰテレビコンテンツ・プロバイダ・ノードからメディア暗号鍵を含む応答を受信するために提供される。プロセッサ１９は、メディア暗号鍵を受信したＫｓ_ｎａｆを用いて暗号化するために利用され、第３の送信器２０は、ＳＩＰ ２００ ＯＫメッセージをＭＴＶクライアント６に送信するために提供される。ＳＩＰ ２００ ＯＫメッセージは、Ｋｓ_ｎａｆで暗号化されたメディア暗号鍵を含んでいる。もちろん、これらの送信器が単一の送信器として実現されてもよいし、これらの受信器が単一の受信器として実現されてもよい。メモリ２１は、受信したＢＴＩＤとＫｓ_ｎａｆのような情報を格納するために提供される。
【００７２】
図７は、発明の実施形態に対応するＩＰＴＶ受信ノードを示す。上述のＭＴＶネットワークにおいて、ＩＰＴＶ受信ノードは、ＭＴＶクライアント６を有するＵＥである。ＵＥ２２には、ＧＢＡ手順において提供されたＢＴＩＤとＫｓ_ｎａｆとを格納するためのメモリ２３が提供されている。メモリはまた、Ｋｓ_ｎａｆの有効期間といったＫｓ_ｎａｆの関連情報も格納する。送信器２４は、ＳＩＰ ＩｎｖｉｔｅメッセージをＭＴＶ ＡＳ９に送信するために提供される。ＳＩＰ Ｉｎｖｉｔｅメッセージは、プロキシ認証ヘッダ内にＢＴＩＤを含む。第１の受信器２５は、ＳＩＰ ２００ ＯＫメッセージをＭＴＶ ＡＳ９から受信するために提供され、ＳＩＰ ２００ ＯＫメッセージはＫｓ_ｎａｆで暗号化されたメディア暗号鍵を含む。第１のプロセッサ２６は、メディア暗号鍵をメモリ２３から受信したＫｓ_ｎａｆを用いて復号するために提供される。第２の受信器２７は、コンテンツ・サーバ１３またはＭＢ−ＳＣ１０から送信されたＩＰＴＶメディアコンテンツを後に受信するために提供される。コンテンツは、メディア暗号鍵を用いて暗号化される。第２のプロセッサ２８は、ＩＰＴＶメディアコンテンツを、復号されたメディア暗号鍵を用いて復号するために提供される。もちろん、これら２つのプロセッサが単一のプロセッサで実現されてもよいし、２つの受信器が単一の受信器として実施されてもよい。
【００７３】
本発明は、ＭＴＶ ＡＳのようなアプリケーション・サーバに、コンテンツ・アクセス手順の間にＢＴＩＤを確実に受信させる。これにより、ＭＴＶ ＡＳはＫｓ_ｎａｆを、ＢＳＦから取得することができ、ＮＡＦを包含する必要がないので必要とされるシグナリングが減る。Ｋｓ_ｎａｆは、ＭＴＶ ＡＳによって、コンテンツ保護の一部を形成するサービス鍵（ＭＳＫ）を暗号化するために利用される。このことは、サービスアクセスの種別とは無関係に、サービスおよびコンテンツ保護のために、Ｋｓ_ｎａｆを取得し、ＭＴＶ ＡＳ／ＩＰＴＶに格納するための単一の共通ＩＭＳ手順を提供することになる。さらに、ＧＢＡ手順においてクライアントに提供されるＢＴＩＤを、ＨＴＴＰやＳＩＰシグナリングのような、いくつかの種類のシグナリングに再利用することができる。
【００７４】
当業者は、発明の範囲から逸脱することなく、上記の実施形態に対して様々な修正を行うことが可能なことを理解するであろう。たとえば、以上では、モバイルＴＶネットワークとの関連で発明を説明したが、発明を固定接続のＩＰＴＶネットワークに適用可能なことは理解されよう。本発明は、セルラーを介したプッシュ・ツー・トーク（ＰｏＣ）ネットワークにおけるマルチキャスト／ブロードキャストの会議サービスのようなサービスでも利用可能である。
【符号の説明】
【００７５】
ＢＭ−ＳＣ：ブロードキャスト・マルチキャスト・サービス・センタ
ＢＳＦ：ブートストラップ・サーバ機能
ＢＴＩＤ：ブートストラップ・トランザクションＩＤ
ＣＫ：コンテンツ鍵
ＥＰＧ：電子プログラム・ガイド
ＥＳＧ：電子サービス・ガイド
ＧＡＡ：汎用認証構造
ＧＢＡ：汎用ブートストラップ認証
ＨＳＳ：ホーム加入者サーバ
ＨＴＴＰ：ハイパーテキスト転送プロトコル
ＩＫ：インテグリティ鍵
ＩＰＴＶ ＡＳ：ＩＰＴＶアプリケーション・サーバ
Ｋｓ_ｎａｆ：ＧＢＡ手順の結果としてＢＳＦにより生成された長期鍵
リニアＢＶ ＴＶ：ブロードキャスト・ベアラを介して分配されるＴＶチャンネル
ＭＢＭＳ：マルチメディア・ブロードキャスト・マルチキャスト・サービス
ＭＣＦ：メディア制御機能
ＭＤＦ：メディア伝送機能
ＭＳＫ：ＭＢＭＳセッション鍵
ＭＴＫ：ＭＢＭＳトラヒック鍵
ＭＴＶ ＡＳ：モバイルＴＶアプリケーション・サーバ
ＭＵＫ：ＭＢＭＳユーザ鍵
ＮＡＦ：ネットワーク・アプリケーション機能
ＳＲＴＰ：セキュア・リアルタイム転送プロトコル
ＳＴＢ：セット・トップ・ボックス
ＵＥ：ユーザ機器
ＵＲＩ：ユニフォーム・リソース識別子
ＶｏＤ：ビデオ・オン・デマンド
【図１】
2011523283.tif 000003
【図２】
2011523283.tif 000004
【図３】
2011523283.tif 000005
【図４】
2011523283.tif 000006
【図５】
2011523283.tif 000007
【図６】
2011523283.tif 000008
【図７】
2011523283.tif 000009
【国際調査報告】
2011523283.tif 000010
2011523283.tif 000011
2011523283.tif 000012