(57)【要約】【課題】保安署名方法、保安認証方法及びＩＰＴＶシステムを提供する。【解決手段】保安署名方法は、ディジタル署名ヘッダフィールドを準備して属性をセッティングし、ハッシングアルゴリズムを用いて前記コンテンツのハッシュダイジェストを計算し、その計算されるハッシュ値をディジタル署名ヘッダのメッセージダイジェストフィールドに格納し、メッセージダイジェストを秘密鍵を使用して暗号化してディジタル署名ヘッダの署名フィールドに挿入して、ディジタル署名ヘッダをコンテンツにプレフィックスしてコンテンツと連係させる。保安認証方法は、コンテンツのディジタル署名ヘッダのフォーマット及び値が適切かどうかをチェックして、ハッシングアルゴリズムを用いてコンテンツのハッシュダイジェストを計算し、そのハッシュ値をディジタル署名ヘッダのメッセージダイジェストフィールドと比較して、ディジタル署名ヘッダの署名フィールドのハッシュ値を証明書フィールドから抽出される公開鍵を使用して復号化した後、メッセージダイジェストと比較する。【選択図】図５
2010539782.tif 000002
【特許請求の範囲】
【請求項１】
ディジタル署名ヘッダフィールドを準備して属性をセッティングする段階と、
ハッシングアルゴリズムを用いてコンテンツのハッシュダイジェストを計算する段階と、
計算されたハッシュ値を前記ディジタル署名ヘッダのメッセージダイジェストフィールドに格納する段階と、
前記メッセージダイジェストを秘密鍵を使用して暗号化し、前記暗号化されたメッセージダイジェストを前記ディジタル署名ヘッダの署名フィールドに挿入する段階と、を含み、
前記ディジタル署名ヘッダは、前記コンテンツより前に位置することを特徴とする保安署名方法。
【請求項２】
前記ハッシングアルゴリズムは、前記ディジタル署名ヘッダのダイジェストアルゴリズムフィールド内で識別されることを特徴とする請求項１に記載の保安署名方法。
【請求項３】
サイナーの証明書を前記ディジタル署名ヘッダフィールドの証明書フィールドに挿入する段階をさらに含み、
前記サイナーの証明書は、前記サイナーの識別情報、前記暗号化されたメッセージダイジェストの復号化に使用可能な公開鍵、及びハイレバルの信頼性のある認証局によって署名されたディジタル署名を含むことを特徴とする請求項１に記載の保安署名方法。
【請求項４】
前記サイナーの証明書を承認する認証局の証明書を前記ディジタル署名ヘッダフィールドの証明書フィールドに挿入する段階をさらに含むことを特徴とする請求項２に記載の保安署名方法。
【請求項５】
コンテンツのディジタル署名ヘッダのフォーマット及び値が適切かどうかをチェックする段階と、
ハッシングアルゴリズムを用いて前記コンテンツのハッシュダイジェストを計算する段階と、
計算されたハッシュ値を前記ディジタル署名ヘッダのメッセージダイジェストフィールドと比較する段階と、
前記ディジタル署名ヘッダの署名フィールドのハッシュ値を証明書フィールドから抽出される公開鍵を使用して復号化する段階と、
前記復号化されたハッシュ値を前記メッセージダイジェストと比較する段階と、
を含むことを特徴とする保安認証方法。
【請求項６】
前記ハッシングアルゴリズムは、前記ディジタル署名ヘッダのダイジェストアルゴリズムフィールド内で識別されることを特徴とする請求項５に記載の保安認証方法。
【請求項７】
コンテンツのハッシュダイジェストを計算してディジタル署名ヘッダのメッセージダイジェストフィールドに格納し、前記メッセージダイジェストを秘密鍵を使用して暗号化して前記ディジタル署名ヘッダの署名フィールドに挿入し、前記ディジタル署名ヘッダを前記コンテンツにプレフィックスして送信するサーバサイドシステムと、
前記ディジタル署名ヘッダを受信して前記ディジタル著名ヘッダのフォーマット及び値が適切かどうかをチェックし、前記コンテンツのハッシュダイジェストを計算して前記ディジタル署名ヘッダのメッセージダイジェストフィールドと比較し、前記ディジタル署名ヘッダの署名フィールドのハッシュ値を証明書フィールドから抽出される公開鍵を使用して復号化する認証プロセスを実行するＩＰＴＶ受信デバイスと、
を含むことを特徴とするＩＰＴＶシステム。
【請求項８】
前記サーバサイドシステムは、前記証明書フィールドに前記サイナーの証明書を挿入して、前記ＩＰＴＶ受信デバイスは、前記証明書フィールドに挿入された前記サイナーの証明書から前記公開鍵を抽出することを特徴とする請求項７に記載のＩＰＴＶシステム。
【請求項９】
前記認証プロセスは、前記ＩＰＴＶ受信デバイスのネイティブ保安ソリューションによって実行されることを特徴とする請求項７に記載のＩＰＴＶシステム。
【請求項１０】
前記ＩＰＴＶ受信デバイスは、ＩＰＴＶ受信デバイスの保安特性を予め決められた基準に従って等級化した保安ソリューションレベルと連係されることを特徴とする請求項７に記載のＩＰＴＶシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保安署名方法、保安認証方法及びＩＰＴＶシステムに関し、もう詳しくは、保安ダウンロードやメッセージの保安伝送の際、サイニングプロセス及び認証プロセスを容易に実行することができるようにする保安技術及びその基盤システムに関する。
【背景技術】
【０００２】
最近、ディジタル放送環境が構築されて高画質及び様々な付加サービスに対する要求が急増しており、ディジタル放送サービスが商用化されている。ディジタル放送サービスは、既存のアナログ放送サービスでは提供できなかった良質のサービスを提供することが可能である。
【０００３】
特に、ＩＰネットワークを介して放送サービスを提供するＩＰＴＶ(Internet Protocol Television)サービスは、高画質で放送コンテンツが提供できるだけでなく、両方向サービスが可能であるため、ユーザが視聴プログラムの種類や視聴時間などを能動的に選択することができる。
【０００４】
また、ＩＰＴＶサービスは、このような両方向性に基づいて様々な付加サービス、例えば、インターネット検索、ホームショッピング、オンラインゲームなどを放送と連係して提供することもできる。
【０００５】
このようなＩＰＴＶサービスのためには、サービスシステム及びユーザシステムが要求されることができる。サービスシステムは、コンテンツプロバイダから様々なコンテンツの提供を受けることができ、サービスコンテンツ目録、放送スケジュール、プリビューなどを含むガイド情報、例えば、ＥＰＧ(Electronic Program Guide：電子番組ガイド)、ＩＰＧ(Interactive Program Guide：インタラクティブプログラムガイド)、ＣＰＧ(Content Program Guide：コンテンツプログラムガイド)などを生成した後、これをＩＰネットワークを介してユーザシステムに提供することができる。
【０００６】
ユーザシステムは、ＩＰＴＶデバイス(例えば、ＩＰＴＶセットトップボックス)などを備える。ユーザシステムは、サービスプロバイダから提供されるガイド情報を表示し、ユーザによって選択されたコンテンツまたはサービスをサービスシステムに要求することができる。一方、ユーザシステムは、ユーザドメインを含むこともできる。ＩＰＴＶデバイスによってユーザ側に受信されるコンテンツは、ユーザドメイン内のデバイス、例えば、ホームネットワークデバイスと共有することもできる。
【０００７】
このようなＩＰＴＶシステムを安定的に運営するためにはＩＰＴＶサービスと関連のあるコンテンツ、例えば、マルチメディアコンテンツ、ＤＲＭコード、ソフトウェア、メッセージなどをユーザシステムにダウンロードする時、これらを不法な行為から安全に保護することができる保安体系が必須的に要求される。この保安体系は、認証に使われる署名(Signature)構造、証明書(Certificate)構造などを定義して、効率的なサイニング(Signing：サイニング)プロセス及び認証(Authentication)プロセスを提示して迅速性及び安全性を高めることによって、ＩＰＴＶサービスの信頼性が保障できなければならない。従って、該当分野の技術開発が緊急に要求されている。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が解決しようとする目的は、デバイスに保安ダウンロード、保安メッセージなどを伝送する時、コンテンツの安全性が保障できる保安署名方法と保安認証方法を提供し、その基盤システムを提供することである。
【課題を解決するための手段】
【０００９】
このような目的を達成するために、本発明は、一態様において、保安署名方法を提供する。この保安署名方法は、ディジタル署名ヘッダフィールドを準備して属性をセッティングする段階と、ハッシングアルゴリズムを用いてコンテンツのハッシュダイジェストを計算する段階と、計算されたハッシュ値をディジタル署名ヘッダのメッセージダイジェストフィールドに格納する段階と、メッセージダイジェストを秘密鍵を使用して暗号化し、ディジタル署名ヘッダの署名フィールドに挿入する段階と、ディジタル署名ヘッダをコンテンツにプレフィックスしてコンテンツと連係させる段階と、を含む。このハッシングアルゴリズムは、ディジタル署名ヘッダのダイジェストアルゴリズムフィールド内で識別されることができる。
【００１０】
この保安署名方法は、サイナー（ｓｉｇｎｅｒ）の証明書をディジタル署名ヘッダフィールドの証明書フィールドに挿入する段階をさらに含むことができる。サイナーの証明書は、サイナーの識別情報、暗号化されたメッセージダイジェストの復号化に使用可能な公開鍵及びハイレバルの信頼性のある認証局によって署名されたディジタル署名を含むことができる。
【００１１】
この保安署名方法は、サイナーの証明書を承認する認証局の認証書をディジタル署名ヘッダフィールドの証明書フィールドに挿入する段階をさらに含むこともできる。
【００１２】
前述した目的を達成するために、本発明は、他の態様において、保安認証方法を提供する。保安認証方法は、コンテンツのディジタル署名ヘッダのフォーマット及び値が適切かどうかをチェックする段階と、ハッシングアルゴリズムを用いてコンテンツのハッシュダイジェストを計算する段階と、計算されたハッシュ値をディジタル署名ヘッダのメッセージダイジェストフィールドと比較する段階と、ディジタル署名ヘッダの署名フィールドのハッシュ値を証明書フィールドから抽出される公開鍵を使用して復号化する段階と、復号化されるハッシュ値をメッセージダイジェストと比較する段階と、を含むことができる。ハッシングアルゴリズムは、ディジタル署名ヘッダのダイジェストアルゴリズムフィールド内で識別することができる。
【００１３】
前述した目的を達成するために、本発明は、他の態様において、ＩＰＴＶシステムを提供する。ＩＰＴＶシステムは、コンテンツのハッシュダイジェストを計算してディジタル署名ヘッダのメッセージダイジェストフィールドに格納し、メッセージダイジェストを秘密鍵を使用して暗号化し、ディジタル署名ヘッダの署名フィールドに挿入し、ディジタル署名ヘッダをコンテンツにプレフィックスして送信するサーバサイドシステム、及び、ディジタル署名ヘッダを受信してフォーマット及び値が適切かどうかをチェックし、コンテンツのハッシュダイジェストを計算してディジタル署名ヘッダのメッセージダイジェストフィールドと比較して、ディジタル署名ヘッダの署名フィールドのハッシュ値を証明書フィールドから抽出される公開鍵を使用して復号化する認証プロセスを実行するＩＰＴＶ受信デバイスを含むことができる。
【００１４】
サーバサイドシステムは、証明書フィールドにサイナーの証明書を挿入し、ＩＰＴＶ受信デバイスは、証明フィールドに挿入されたサイナーの証明書から公開鍵を抽出することができる。
【００１５】
認証プロセスは、ＩＰＴＶ受信デバイスのネイティブ保安ソリューションによって実行することができる。ＩＰＴＶ受信デバイスは、ＩＰＴＶ受信デバイスの安全特性を予め決められた基準に従って等級化した保安ソリューションレベルと連係されることもできる。
【発明の効果】
【００１６】
以上、説明した通り、本発明によると、保安ダウンロードまたは保安メッセージの伝送の際、保安ソリューション認証プロセスを提供することができる。特に、本発明は、実行可能なソフトウェアの保安ダウンロード、ＤＲＭコードの保安ダウンロード、構成ファイルや一回性命令の保安伝送、ＥＡＳメッセージの保安伝送などの実行に容易に適用することができる。
【図面の簡単な説明】
【００１７】
【図１】ＩＰＴＶサービスのためのＤＲＭ(Digital Rights Management：ディジタル著作権管理)コンポーネントを示すブロック図である。
【図２】ＩＰＴＶシステムにおける保安ソリューション認証プロセスを説明するための例示図である。
【図３】ディジタル署名及び署名されたコンテンツのフォーマットを表すテーブルを示す例示図である。
【図４】図３に示す「signeddata」のフィールド構造を表すテーブルを示す例示図である。
【図５】図２に示す保安ソリューション認証プロセスのサイニングプロセスを説明するためのフローチャートである。
【図６】図２に示す保安ソリューション認証プロセスの認証プロセスを説明するためのフローチャートである。
【図７】デバイスの保安ソリューションレベルを指定する基準になる保安ソリューションレベルテーブルを示す例示図である。
【図８】ＩＰＴＶシステムにおけるコンテンツの共有のためのシステムの構成を概略的に示すブロック図である。
【図９】ＳＲＭを介してデバイス間にコンテンツを伝送するシナリオを示すフローチャートである。
【図１０】ＳＲＭを介してデバイス間に複数個のコンテンツを伝送するシナリオを示すフローチャートである。
【図１１】リアルタイム放送サービスとオンデマンドサービスを連動してサービスを提供する実施例を示すフローチャートである。
【図１２】権限インジェクタを用いて権限レポジトリにユーザの権限を格納する例を示す例示図である。
【発明を実施するための形態】
【００１８】
以下、本発明の属する分野に通常の知識を有する者が、本発明が容易に実施できるように、本発明の望ましい実施例を添付図面を参照して詳細に説明する。以下に説明する本発明の望ましい実施例では内容の明瞭性のためで特定の技術用語を使用する。しかしながら、本発明は、その選択された特定用語に限定することではなく、各々の特定用語が類似の目的を達成するために類似の方式に動作する全ての技術同義語を含むことを予め明らかにする。
【００１９】
図１は、ＩＰＴＶサービスのためのＤＲＭ(Digital Rights Management：ディジタル著作権管理)コンポーネントを示すブロック図であり、ＩＰＴＶサービスを提供するためのＩＰＴＶシステムの構成を安全に必要な要素を中心に示している。
【００２０】
図１に示すように、サーバサイドＤＲＭシステム(Server Side DRM System)３０は、放送コンテンツサーバ１０またはＶＯＤ(Video On Demand：ビデオオンデマンド)レポジトリ(Repository)２０からコンテンツの提供を受ける。サーバサイドＤＲＭシステム３０は、リアルタイム暗号化モジュール(Real-Time Encryption Module)３２、鍵管理モジュール(Key Management Module)３４、オフライン暗号化モジュール(Off-line Encryption Module)３６、ＤＲＭシステム管理サーバ(DRM System Management Server)３８などを備えることができる。
【００２１】
リアルタイム暗号化モジュール３２は、鍵管理モジュール３４によって提供される鍵を使用して放送コンテンツサーバ１０またはＶＯＤレポジトリ２０から提供されるメディアコンテンツをリアルタイムで暗号化し、暗号化されたリアルタイムコンテンツのストリームを出力することができる。リアルタイム暗号化モジュール３２から出力されるコンテンツストリームは、ＩＰＴＶ受信デバイス(IPTV Receiving Device)７０に伝達される。リアルタイム暗号化モジュール３２は、放送コンテンツサーバ１０またはＶＯＤレポジトリ２０とアプリケーションレベルでインタフェースすることができ、必要に応じてサーバサイドＤＲＭシステム３０の構成要素と連動することもできる。
【００２２】
オフライン暗号化モジュール３６は、特定時間の間にＶＯＤサーバ４０に格納されるようになるメディアコンテンツを放送コンテンツサーバ１０またはＶＯＤレポジトリ(２０)から受信して暗号化し、これをＶＯＤサーバ４０に提供する。このようなオフライン暗号化モジュール３６は、ＶＯＤサーバ４０の入力ポートと連結される。オフライン暗号化モジュール３６は、放送コンテンツサーバ１０またはＶＯＤレポジトリ２０とアプリケーションレベルにインタフェースすることができ、必要に応じてサーバサイドＤＲＭシステム３０の構成要素と連動することができる。
【００２３】
鍵管理モジュール３４は、リアルタイム暗号化モジュール(３２)、オフライン暗号化モジュール３６またはＩＰＴＶ受信デバイス７０に適する暗号化鍵を提供して管理することができる。鍵管理モジュール３４からのストリームは、ＩＰＴＶ受信デバイス７０に伝達されることができ、ＩＰＴＶ受信デバイス７０とアプリケーションレベルでインタフェースすることができる。
【００２４】
ＤＲＭシステム管理サーバ３８は、ＤＲＭコンポーションの中心コア(Central Core)役割を実行する。例えば、ＤＲＭシステム管理サーバ３８は、サーバサイドＤＲＭシステム３０のサブエレメント、例えば、リアルタイム暗号化モジュール３２、鍵管理モジュール３４、オフライン暗号化モジュール３６などを適切に制御し、サーバサイドミドルウェア ５０と連動することができる。また、ＤＲＭシステム管理サーバ３８は、サーバサイドＤＲＭシステム３０の構成要素またはＩＰＴＶ受信デバイス７０のＤＲＭコンポーネント７２などに保安サービス、例えば、認証などを提供することができる。
【００２５】
ＶＯＤサーバ４０は、暗号化されたコンテンツを格納し、サーバサイドミドルウェアー５０の命令に従って暗号化されたコンテンツを提供することができる。ＩＰＴＶネットワーク６０は、サーバサイドＤＲＭシステム３０またはＶＯＤサーバ４０から送信される様々なパケットストリームがそのＩＰアドレスに従ってＩＰＴＶ受信デバイス７０に適切に伝送されることができるようにルートを提供する。
【００２６】
ＩＰＴＶ受信デバイス７０は、クライアントサイドに備えられることができる。ＩＰＴＶ受信デバイス７０は、ユーザがユーザの視覚装置(Viewing Device)、例えば、ＴＶなどにユーザに権限が付与された(例えば、メディアコンテンツの購入などを介して権限を得ることができる)メディアコンテンツが視聴できるように該当機能を提供する。ＩＰＴＶ受信デバイス７０は、ＩＰネットワーク６０と連結されてサーバサイドＤＲＭシステム３０またはＶＯＤサーバ４０から受信される暗号化されたコンテンツを処理して再生または格納することができ、場合によってはホームネットワークなどに基づいて構成されるユーザドメインのデバイスにコンテンツを再分配することもできる。
【００２７】
ＩＰＴＶ受信デバイス７０は、コンテンツの保護と関連のある機能を実行するＩＰＴＶ受信デバイスＤＲＭコンポーネント７２、コンテンツの使用と関連のある機能を実行するＩＰＴＶ受信デバイスソフトウェア７４などを含むことができる。このようなＩＰＴＶ受信デバイス７０は、例えば、ＩＰＴＶセットトップボックスまたはＩＰＴＶセットトップボックスに相応する機能が備えられたネットワークデバイスなどであることがある。
【００２８】
一方、サーバサイドではＩＰＴＶ受信デバイス７０に保安ダウンロード(Secure Download)または保安メッセージ(Secure Message)と関連されている様々なデータを伝送することができる。このようなデータの伝送のためには保安ソリューション認証(Security Solution Authentication)が要求される。保安ソリューション認証の要求されるデータは、大いに非永続的データ(Non-Persistent Data)と永続的データ(Persistent Data)とに区分されることができる。
【００２９】
非永続的データは、ＩＰＴＶ受信デバイス７０に受信されるレセプションタイム(Reception Time)にだけ使われるデータを意味することができる。非永続的データであるＥＡＳ(Emergency Alert System：緊急警報)メッセージの保安伝送、一回性命令(One-Time Commands)の保安伝送、エンドツーエンド(End-to-End)通信などでは保安ソリューション認証が要求される。一方、永続的データは、レセプションタイム後にもＩＰＴＶ受信デバイス(７０)内に保存されるデータを意味することができる。永続的データである実行可能なソフトウェア(Executable Software)の保安ダウンロード、ＤＲＭコードの保安ダウンロード、コンフィギュレーションファイル(Configuration Files)の保安伝送、証明書階層体系(Certificate Hierarchy)のアップデートなどでは保安ソリューション認証が要求される。
【００３０】
以下、前述した保安ダウンロードまたは保安メッセージの伝送のために必須的に要求される保安ソリューション認証手順に関して説明する。
【００３１】
図２は、ＩＰＴＶシステムにおける保安ソリューション認証プロセスを説明するための例示図である。
【００３２】
図２に示すように、保安ソリューション認証プロセスは、サイニングプロセス(Signing Process)(段階：Ｓ１)と認証プロセス(Authentication Process)(段階：Ｓ２)とを含む。サイニングプロセス(段階：Ｓ１)は、サーバサイドの特定システム、例えば、サーバサイドＤＲＭシステムなどで実行することができる。認証プロセス(段階：Ｓ２)は、ＩＰＴＶ受信デバイスの特定要素、例えば、ネイティブ保安ソリューション(Native Security Solution)などで実行することができる。
【００３３】
ネイティブ保安ソリューションは、ＩＰＴＶ受信デバイスの生産時(Manufacturing Time)にハードウェア、ソフトウェア、またはハードウェアとソフトウェアとが混合された形態でＩＰＴＶ受信デバイスに備えられることもできる。ネイティブ保安ソリューションは、保安ソリューション認証のための認証プロセス、完全性チェッキング(Integrity Checking)などを実行することができる。
【００３４】
ＩＰＴＶ受信デバイスにコンテンツを伝送するために、サーバサイドは、伝送するオリジナルコンテンツにディジタル署名ヘッダ(Digital Signature Header)を連係させるサイニングプロセス(段階：Ｓ１)を実行して、署名されたコンテンツ(Signed Content)をＩＰネットワークを介してＩＰＴＶ受信デバイスに伝送する。ＩＰＴＶ受信デバイスは、署名されたコンテンツを受信して認証プロセス(段階：Ｓ２)を実行することによってコンテンツを検証することができる。
【００３５】
コンテンツは、保安伝送されるソフトウェア、保安メッセージなどであってもよく、非永続的データであってもよく、永続的データであってもよい。例えば、ＥＡＳメッセージの保安伝送、一回性命令の保安伝送、エンドツーエンド通信、実行可能なソフトウェアの保安ダウンロード、ＤＲＭコードの保安ダウンロード、コンフィギュレーションファイル(Configuration Files)の保安伝送、証明書階層体系(Certificate Hierarchy)のアップデートなどでは図２に示す保安ソリューション認証が実行されることができる。
【００３６】
サイニングプロセス(段階：Ｓ１)及び認証プロセス(段階：Ｓ２)には数学的にお互いに関連されている鍵ペア(Key Pair)が使われることができる。例えば、サイニングプロセス(段階：Ｓ１)が実行されるサイニングタイム(Signing Time)には秘密個人鍵が使われることができ、認証プロセス(段階：Ｓ２)が実行される認証タイム(Authentication Time)には公開鍵が使われることができる。コンテンツのハッシュダイジェスト(Hash Digest)、すなわち、ハッシュ値(Value)は、サイニングタイムと認証タイムで計算することができる。サイニングタイムで計算されるハッシュ値は、個人鍵を使用して暗号化されてディジタル署名(Digital Signature)の一部分に挿入される。これは認証タイムで個人鍵を使用して復号化され、認証タイムで新たに計算されたハッシュと比較することができる。
【００３７】
一方、承認されたサイナー(Authorized Signer)は、公開鍵、識別情報、上位レベルの信頼性のある認証局(Trusted Certificate Authority)によってサインされたディジタル署名などを含む証明書を特定個体から与えられることができる。サイナーの証明書は、サイニングプロセス(段階：Ｓ１)時にディジタル署名ヘッダに含まれることができる。
【００３８】
図３は、ディジタル署名及び署名されたコンテンツのフォーマットを表すテーブルを示す例示図である。
【００３９】
図３に示すように、ディジタル署名である「signature｛｝」は、署名されたコンテンツにヘッダとしてプレフィックス(Prefixed)される。ディジタル署名「signature｛｝」は、コンテンツ情報、コンテンツタイプ、署名されたデータを各々表すフィールドである「contentinfo」、「contenttype」、「signeddata」を含むことができる。このとき、前記「signeddata」フィールドは、後に図４を参照して詳細に説明する。
【００４０】
署名されたコンテンツである「signedcontent｛｝」は、コンテンツが挿入される「content()」フィールドを含むことができる。「content()」フィールドにはディジタル的に署名されたソフトウェアイメージまたはメッセージが挿入されることができる。例えば、「content()」フィールドは、ソフトウェアイメージまたはメッセージのための８ビット配列(Octet)のシークエンスを含むことができる。署名されたコンテンツは、ディジタル署名の外部にいなければならず、ディジタル署名に付加されなければならない。
【００４１】
図４は、図３に示す「signeddata」のフィールド構造を表すテーブルを示す例示図である。
【００４２】
図４に示すように、署名されたデータ「signeddata」フィールドは、サイナー(Signer)の証明書(certificate)を挿入するための「certificates｛｝」フィールド、サイナー情報を挿入するための「signerinfo｛｝」フィールドなどを含むことができる。
【００４３】
「certificates｛｝」は、コンテンツのために適当なサイナーの証明書が含まれる。サイナーの証明書は、「certificated｛｝」内の「contentsignerCVC」フィールドに挿入されることができる。また、オプションとしてサイナーの証明書を承認した認証局証明書(Certificate Authority Certificate)を含むこともできる。認証局証明書は「certificated｛｝」内の「CVC CA」フィールドに挿入されることができる。
【００４４】
「signerinfo｛｝」は、バージョン情報が挿入される「version」フィールド、サイナーの識別情報を含む「sid」フィールド、コンテンツのハッシュダイジェスト計算に使用するハッシングアルゴリズムの情報が挿入される「digestAlgrithm」フィールド、署名された属性関連情報が挿入される「signAttrs」フィールド、署名アルゴリズム関連情報が挿入される「signatureAlgorithm」フィールド、署名が挿入される「signature」フィールドなどを含むことができる。「signAttrs」フィールドは、コンテンツタイプ情報を挿入する「contenttype」フィールド、計算されたハッシュ値を格納するための「messageDigest」フィールドを含み、オプションにサイニングタイム情報を挿入するための「signingTime」フィールドなどをさらに含むこともできる。上記「messageDigest」は、個人鍵によって暗号化された後「signature」フィールドに格納されることができる。
【００４５】
図５は、図２に示す保安ソリューション認証プロセスのサイニングプロセス(段階：Ｓ１)を説明するためのフローチャートである。
【００４６】
図５に示すように、サイニングプロセスは、署名されたコンテンツにヘッダとしてプレフィックスされるディジタル署名を生成することができる。このとき、サイナーは、個人鍵と、認証局によって発行された公開鍵証明書などとを有していなければならない。
【００４７】
サイニングプロセスは、サーバサイドの特定システムで実行されることができる。サイニングプロセスが始められる場合、まずコンテンツにヘッダとして付けられるディジタル署名のフィールドが準備され、フィールドの属性が図４に示すテーブルのようにセッティングされる(段階：Ｓ１１)。
【００４８】
次に、コンテンツのハッシュダイジェストが計算される。例えば、「signAttrs」及び「content()」をカバーするハッシュダイジェストが計算されることができる(段階：Ｓ１２)。このとき、ハッシュダイジェストの計算に使われるハッシングアルゴリズムは、「signerinfo」の「digestAlgorithm」フィールド内で識別されることができる。ハッシュダイジェストが計算されれば、計算されたハッシュ値(すなわち、ハッシュダイジェスト)は、「signerinfo」内のメッセージダイジェストフィールド、すなわち、「messageDigest」に格納される(段階：Ｓ１３)。
【００４９】
次に、メッセージダイジェストフィールド「messageDigest」の内容は、秘密個人鍵を使用して暗号化された後(段階：Ｓ１４)、「signature」フィールドに挿入される(段階：Ｓ１５)。また、サイナーの証明書のコピーは、証明書フィールドである「certificates｛｝」内に挿入されるようになる(段階：Ｓ１６)。サイナーの証明書には認証プロセスで使用することができる公開鍵が含まれている。一方、「certificates｛｝」内には認証局の証明書がさらに挿入されることもできる。サイナーの証明書は、信頼された管理階層体系(Trusted Management Hierarchy)にリンクされることもできる。
【００５０】
次に、前述した過程を介して生成されるディジタル署名ヘッダは、コンテンツ「content()」にプレフィックスされ、図３に示すテーブルのようなフォーマットになるように合わせられる(段階：Ｓ１７)。
【００５１】
ディジタル署名ヘッダがプレフィックスされた署名されたコンテンツは、通信網を介してサーバサイドからＩＰＴＶ受信デバイスに伝送される。ＩＰＴＶ受信デバイスは、署名されたコンテンツを受信することができる。従って、このとき、保安ソリューション認証プロセスの認証プロセスが実行されることができる。
【００５２】
図６は、図２に示す保安ソリューション認証プロセスの認証プロセス(段階：Ｓ２)を説明するためのフローチャートである。
【００５３】
図６に示すように、認証プロセスは、受信されるディジタル署名ヘッダをチェッキングする過程、サイニングタイムで計算されたハッシュ値とディジタル署名ヘッダのデータに基づいて計算したハッシュ値を比較して同一かどうかを検証する等の過程を含むことができる。このような認証プロセスは、ＩＰＴＶ受信デバイス内のネイティブ保安ソリューション(Native Security Solution)によって実行されることができる。
【００５４】
認証プロセスが始まれば、ＩＰＴＶ受信デバイスは、サインされたコンテンツにヘッダとしてプレフィックスされているディジタル署名が図４のテーブルに記述されている内容と比較して正当なフォーマットと値を有するかをチェックすることができる(段階：Ｓ２１)。例えば、ＩＰＴＶ受信デバイスは、署名されたコンテンツのディジタル署名ヘッダに対する完全性チェックなどを実行することができる。
【００５５】
次に、ＩＰＴＶ受信デバイスは、コンテンツのハッシュダイジェストを計算する(段階：Ｓ２２)。例えば、ＩＰＴＶ受信デバイスは、「signAttrs」及び「content()」をカバーするハッシュダイジェストを計算することができる。このとき、ハッシュダイジェストの計算に使われるハッシングアルゴリズムは、「signerinfo」の「digestAlgorithm」フィールド内で識別されることができる。ハッシュダイジェストが計算されれば、ＩＰＴＶ受信デバイスは、計算されたハッシュ値(すなわち、ハッシュダイジェスト)を「signerinfo」内のメッセージダイジェストフィールド、すなわち、「messageDigest」と比較することができる(段階：Ｓ２３)。
【００５６】
また、ＩＰＴＶ受信デバイスは、ディジタル署名の「signature」フィールドに挿入されている暗号化されたハッシュ(すなわち、暗号化された「messageDigest」)を「certificates」フィールド内で抽出可能な公開鍵を使用して復号化し(段階：Ｓ２４)、復号化された値を「signerinfo」内のメッセージダイジェストフィールド、すなわち、「messageDigest」と比較することができる(段階：Ｓ２５)。例えば、ＩＰＴＶ受信デバイスは、「signature」フィールドから暗号化されたハッシュを抽出し、「certificates」フィールドからサイナーの証明書に含まれている公開鍵を抽出した後、抽出された公開鍵を使用して抽出された暗号化されたハッシュ値を復号化して「messageDigest」と比較することができる。「certificates」フィールドに挿入されているサイナーの証明書は、信頼性のある管理階層体系(Trusted Management Hierarchy)にリンクされることもできる。
【００５７】
ＩＰＴＶ受信デバイスは、比較結果、計算されたハッシュ値または復号化されたハッシュ値「messageDigest」と異なる場合、認証エラーを発生させることができ、この場合、サーバサイドにエラーメッセージ、再伝送要求メッセージなどを伝送することもできる。
【００５８】
一方、前述した通り、認証プロセスは、ＩＰＴＶ受信デバイスのネイティブ保安ソリューションによって実行され、ＩＰＴＶ受信デバイスごとに備えられたネイティブ保安ソリューションの実行環境(Execution Environment)が異なることがある。その理由は、ＩＰＴＶ受信デバイスは、相異するデバイス生産者によってデザインされることができ、これによって相異するアプリケーション、保安能力値などを有するためである。
【００５９】
従って、保安ソリューション認証の信頼性を高めるためにはＩＰＴＶ受信デバイスの安全水準を表す情報が要求される。これに伴い、保安ソリューションレベル(Security Solution Level)の概念を導入することができる。保安ソリューションレベルは、デバイスの保安特性を予め決められた基準に従って等級化した情報を意味することができる。保安ソリューションレベルは、保安ソリューション認証のためのデバイスの実行環境を表す保安ソリューションプロファイルであることがある。デバイスは、そのデバイスの保安ソリューション認証プロセスの安全水準に従って指定される保安ソリューションレベルと連係されることができる。前記予め決められた基準とは、保安ソリューションレベルテーブルであることがある。
【００６０】
図７は、デバイスの保安ソリューションレベルを指定する基準になる保安ソリューションレベルテーブルを示す例示図である。
【００６１】
図７に示すように、保安ソリューションレベルテーブル(SSLT)は、例示的に５個の等級の保安ソリューションレベルを定義することができる。
【００６２】
レベル０は、非安全実行環境(Non-Secured Execution Environment)で保安ソリューション認証プロセスの認証(Authentication)及び安全性(Integrity)チェックを実行しない安全水準を意味することができる。保安ソリューションレベルがレベル０であるデバイスは、保安ソリューション認証プロセスを認証せず、保安ソリューション認証プロセスを開始(Initiate)する。従って、デバイスの保安ソリューションレベルがレベル０である場合、そのデバイスは、安全性が相当脆弱なデバイスということができる。レベル０は、定義された保安ソリューションレベルのうち最も信頼度が低いレベルである。
【００６３】
レベル１は、非安全遂行環境でデバイスのソフトウェアエレメント (例えば、ネイティブ保安ソリューションのソフトウェアエレメント)を使用して保安ソリューション認証プロセスの認証及び完全性チェックを検証する水準の保安ソリューションレベルを意味することができる。レベル１における保安ソリューション認証プロセスは、デバイスのソフトウェアエレメントによって認証された後開始されることができる。このようなレベル１は、レベル０よりは安全性の高いということができる。
【００６４】
レベル２は、非安全実行環境でデバイスのハードウェアエレメント(例えば、ネイティブ保安ソリューションのハードウェアエレメント)を使用して直接的に保安ソリューション認証プロセスの認証及び完全性チェックを検証するレベルを意味することができる。レベル２における保安ソリューション認証プロセスは、デバイスのハードウェアエレメントによって認証された後開始することができる。このようなレベル２は、レベル１よりは安全性の高いということができる。
【００６５】
レベル３は、安全実行環境(Secured Execution Environment)でデバイスのソフトウェアエレメントを使用して保安ソリューション認証プロセスの認証及び完全性チェックを検証する保安ソリューションレベルを意味することができる。レベル３における保安ソリューション認証プロセスは、安全遂行環境下でデバイスのソフトウェアエレメントによって認証された後開始されることができる。このようなレベル３は、レベル２よりは安全性の高いということができる。
【００６６】
レベル４は、安全実行環境でデバイスのハードウェアエレメントを使用して直接的に保安ソリューション認証プロセスの認証及び完全性チェックを検証する保安ソリューションレベルを意味することができる。レベル４における保安ソリューション認証プロセスは、保安実行環境下でデバイスのハードウェアエレメントによって認証された後開始されることができる。このようなレベル４は、レベル３より安全性が高く、定義された保安ソリューションレベル等級の中最も信頼度が高いということができる。
【００６７】
ＩＰＴＶ受信デバイスは、該当デバイスの安全水準に従って前述した基準に対応する保安ソリューションレベルを有することができる。このような保安ソリューションレベルは、デバイスの証明書内の特定フィールドに挿入されることによって該当デバイスと連係されることもでき、またはデバイスの保安ソリューションレベルを表す証明書であるデバイスプロファイル証明書(Device Profile Certificate)に挿入されることによって該当デバイスと連係されることもできる。
【００６８】
保安ソリューション認証プロセスの時にはＩＰＴＶ受信デバイスの保安ソリューションレベルを考慮することができる。例えば、ＩＰＴＶ受信デバイスに、保安ダウンロードや保安メッセージが署名されたコンテンツとして伝送する時、ＩＰＴＶ受信デバイスの保安ソリューションレベルが必要な保安ソリューションレベルを満たさなければ、認証を承認しないこともある。ＩＰＴＶ受信デバイスの保安ソリューションレベルは、サーバサイドまたはＩＰＴＶ受信デバイスで格納または管理されることができ、保安ソリューションレベルの含まれた証明書は、サーバサイドで発行した後、ＩＰＴＶ受信デバイスに格納されることができる。
【００６９】
一方、ＩＰＴＶ受信デバイスは、サーバサイドから受信されるコンテンツ(例えば、映画、音源、イメージなどのようなメディアコンテンツ等)及びコンテンツ関連情報(例えば、ライセンス、メッセージ等)をドメインに含まれた他のデバイスに伝送することによってコンテンツの共有を可能にすることもできる。
【００７０】
このようなコンテンツの共有のためにドメインの概念を導入する。ドメインは、承認されたデバイス(Authorized Device)であるドメインデバイスの集合であり、ドメインサービスが適用される範囲を意味することができる。ドメイン内に含まれたドメインデバイス間には許容された権限に従ってコンテンツを共有して使用することができる。
【００７１】
このようなドメインは、物理的、論理的または物理的及び論理的な範囲内に存在するデバイスを結合して構成することができる。このようなドメインを構成するためにはローカル環境が要求されることができる。このとき、ローカル環境とは、特定のローカル領域内に属するデバイスが相互連動されることができる物理的なネットワークが備えられており、この物理的なネットワークが外部のネットワークとも連動できる環境を意味することができる。
【００７２】
このようなローカル環境を提供することができる例として、ホームネットワークシステムを挙げることができる。ホームネットワークシステムは、有線または無線のローカルネットワークを介して家庭内の家電機器、各種センサ、保安機器などの相互連動が可能であり、ホームゲートウェイのような通信ノードを介してインターネットなどのような外部ネットワークとも連動できる。ローカル環境は、このようなホームネットワークシステムだけでなく、相互連動可能な２個以上のネットワークデバイスが存在すれば構成可能である。
【００７３】
以下、このようなローカル環境が備えられた領域をドメイン領域という。ドメイン領域内には多数のデバイスが存在できる。ユーザは、このようなデバイスを用いてドメインを構成し、ドメインデバイス間にコンテンツを共有して使用することができる。
【００７４】
一方、ユーザは、多数のドメインを構成し、ドメイン間にデータを共有することもできる。例えば、ユーザは、ホームネットワークＡを用いて１つもしくはそれより多い認証されたサービスドメイン(Authorized Service Domain)を構成することができ、ホームネットワークＢを介して１つもしくはそれより多い認証されたサービスドメインを構成することができる。この場合、ユーザは、認証されたサービスドメインを含むサブスクライバの認証されたサービスドメイン(Subscriber「s Authorized Service Domain)を構成してドメイン間の共有サービスの提供を受けることもできる。
【００７５】
承認されたサービスドメインは、該当ドメインを管理するドメインマネージャによって作られて管理されることができる。ドメインマネージャは、ドメインへのデバイス登録及び解約などを管理することができる。サブスクライバの承認されたサービスドメインは、サブスクライバの承認されたサービスドメインのマネージャによって作られて管理されることができる。マネージャは、該当サブスクライバの承認されたサービスドメイン内に含まれた承認されたサービスドメインを各々管理するドメインマネージャと連動することができる。
【００７６】
図８は、ＩＰＴＶシステムにおけるコンテンツの共有のためのシステムの構成を概略的に示すブロック図である。
【００７７】
図８に示すように、ＩＰＴＶ受信デバイス２２０は、ＩＰネットワークを介してサービスプロバイダ１００と連動することができる。また、ＩＰＴＶ受信デバイス２２０は、ホームデバイス２４０と連動することもできる。
【００７８】
ＩＰＴＶ受信デバイス２２０及びホームデバイス２４０は、コンテンツの共有のためにドメイン２００に加入することができる。すなわち、ＩＰＴＶ受信デバイス２２０及びホームデバイス２４０は、ドメインデバイスであることがある。ドメイン２００に加入するためにＩＰＴＶ受信デバイス２２０及びホームデバイス２４０は各々のサービスプロバイダ１００にドメイン２００への加入を要求し、サービスプロバイダ１００は、該当デバイスを認証した後、そのデバイスに証明書を発給してドメイン２００に登録することができる。上記記載ではサービスプロバイダ１００がドメインマネージャを含む例を説明したが、これは限定的な意味ではなく、ドメインマネージャは、サービスプロバイダとは別個のサーバとして運営されてもよく、またはドメイン内に含まれてもよい。
【００７９】
ドメイン２００が構成されれば、ＩＰＴＶ受信デバイス２２０は、サービスプロバイダ１００からコンテンツ案内情報を要求して受信することができる。このとき、コンテンツ案内情報は、サービスコンテンツの日程、目録、付加情報などを案内する情報であり、例えば、ＥＰＧ(Electronic Program Guide)、ＣＰＧ(Content Program Guide)、ＶｏＤコンテンツガイド、ＩＰＧ(Interactive Program Guide)などであることがある。
【００８０】
ＩＰＴＶ受信デバイス２２０は、サービスプロバイダ１００から受信したコンテンツ案内情報をユーザインタフェースに適するように加工して表示することができる。ユーザは、表示されたコンテンツ案内情報で所望のコンテンツを選択することができる。そうすると、ＩＰＴＶ受信デバイス２２０は、選択されたコンテンツをサービスプロバイダ１００に要求することができる。
【００８１】
ＩＰＴＶ受信デバイス２２０からの要求に従ってサービスプロバイダ１００は、該当コンテンツをＩＰＴＶ受信デバイス(２２０)に伝送する。このとき、サービスプロバイダ１００は、上記コンテンツとともに上記コンテンツの使用のために必要なコンテンツ関連情報、例えば、保安情報(Security Information)、使用権限情報(Usage Rights Information)、取消リスト情報(Revocation List Information)などをＩＰＴＶ受信デバイス２２０に伝送することもできる。
【００８２】
ＩＰＴＶ受信デバイス２２０は、コンテンツを受信した後、格納または再生することができ、ホームデバイス２４０に伝送することもできる。デバイス間には様々なルートを介してコンテンツを伝送することができる。例えば、コンテンツを送信するデバイスと受信するデバイス間に保安認証チャネル(Secure Authentication Channel)を形成した後、その保安認証チャネルを介してコンテンツを伝送してもよく、またはスマートカードなどのような格納媒体を介してコンテンツを伝送してもよい。
【００８３】
コンテンツの伝送のためにはドメインクライアント(Domain Client)、コンテンツメディエータ(Content Mediator)、コンテンツエクスポータ(Content Exporter)、コンテンツインポータ(Content Importer)などのモジュールが必要である。モジュールは、様々なデバイスに設置されることができ、ドメインクライアントとコンテンツエクスポータとは送信デバイスに、コンテンツインポータは受信デバイスに、コンテンツメディエータは送信デバイスに、受信デバイスまたは第３のデバイスに設置されることが容易である。しかしながら、これは限定された事項ではなく、モジュールの設置位置は実施環境に従って多様に変形され得る。
【００８４】
図９は、ＳＲＭ(Secure Removable Media：安全なリムーバブルメディア)を介してデバイス間にコンテンツを伝送するシナリオを示すフローチャートである。ＳＲＭ３４０は、スマートカードのようにホストデバイスに接続可能なポータブルメディアを意味することができる。ＳＲＭ内にはコンテンツの共有を支援するためのソフトウェアモジュールと証明書などが格納されている。
【００８５】
図９を参照すると、本実施例ではコンテンツエクスポータ３３０は、送信デバイスに備えられ、コンテンツインポータ３５０は、受信デバイスに備えられていると仮定する。ドメインクライアント３１０とコンテンツメディエータ３２０の場合、送信デバイスに備えられることが望ましいが、限定事項ではない。
【００８６】
まず、ドメインクライアント３１０は、コンテンツメディエータ３２０にコンテンツの伝送を要求する(段階：Ｓ３１)。すると、コンテンツメディエータ３２０は、コンテンツエクスポータ３３０及びコンテンツインポータ３５０に各々コンテンツのエクスポート及びインポートを要求する要求メッセージを送信することができる(段階：Ｓ３２、Ｓ３３)。
【００８７】
次に、送信デバイスにＳＲＭ３４０が挿入された後、コンテンツエクスポータ３３０は、ＳＲＭ３４０を認識して(段階：Ｓ３４)、認証を実行する(段階：Ｓ３５、Ｓ３６)。認証メカニズムは、例えば、ＰＫＩ(Public Key Infrastructure：公開鍵基盤)認証メカニズムに従うことができる。コンテンツエクスポータ３３０、コンテンツインポータ３５０、ＳＲＭ３４０は、信頼性のある機関(例えば、サーバサイドの特定個体等)から各々証明書の発給を受ける。認証プロシージャでは、相互認証が実行されることができる。認証時にはデバイスの識別、能力値識別、証明書の検証(例えば、証明書の交換、証明書の取消チェック等)などが実行されることができる。また、認証の際、コンテンツエクスポータ３３０またはＳＲＭ３４０は必要に応じて外部のＯＣＳＰ(On-line Certificate Status Protocol：オンライン証明状態プロトコル)サーバ(図示せず)と連動することもできる。
【００８８】
認証が完了すれば、コンテンツエクスポータ３３０は、エクスポート機能を用いてＳＲＭ３４０にコンテンツを伝送し(段階：Ｓ３７)、ＳＲＭ３４０は、コンテンツを格納した後(段階：Ｓ３８)、確認メッセージを送信する(段階：Ｓ３９)。これを介してコンテンツエクスポータ３３０は、コンテンツ及びＤＲＭ情報をＳＲＭ３４０に伝送することができる。すると、目的地である受信デバイスに伝送するためのコンテンツがＳＲＭ３４０に格納されるようになる。コンテンツの伝送の際、コンテンツエクスポータ３３０及びＳＲＭ３４０はセッション鍵を用いた保安認証チャネルを設立することもできる。
【００８９】
次に、受信デバイスにＳＲＭ３４０が挿入された後、コンテンツインポータ３５０は、ＳＲＭ３４０を認識し (段階：Ｓ４０)、認証を実行する(段階：Ｓ４１、Ｓ４２)。認証プロシージャでは、デバイスの識別、能力値識別、証明書の交換、証明書の取消チェックなどを介する証明書の有効性検証などが実行されることができる。認証時コンテンツインポータ３５０またはＳＲＭ３４０は、必要に応じてＯＣＳＰサーバと連動することもできる。認証が完了されれば、コンテンツインポータ３５０はインポート機能を用いてＳＲＭ３４０からコンテンツを受信してインポートする(段階：Ｓ４３、Ｓ４４、Ｓ４５)。このとき、コンテンツインポータ３５０は、ＳＲＭ３４０からコンテンツ及びＤＲＭ情報を取ってくることができる。
【００９０】
図１０は、ＳＲＭを介してデバイス間に複数個のコンテンツを伝送するシナリオを示すフローチャートである。
【００９１】
図１０を参照すると、本実施例ではコンテンツエクスポータ３３０は、送信デバイスに備えられ、コンテンツインポータ３５０は、受信デバイスに備えられていると仮定する。ドメインクライアント３１０とコンテンツメディエータ３２０の場合、送信デバイスに備えられることが望ましいが、限定的な事項ではない。
【００９２】
図１０に示すように、多数のコンテンツを伝送するための全体的な伝送手順は前述した図９に示す手順とほぼ同一であるが、本実施例では多数のコンテンツを伝送するため、コンテンツエクスポータ３３０とＳＲＭ３４０の認証後、コンテンツエクスポータ３３０からＳＲＭ３４０にコンテンツが順次伝送され、ＳＲＭ３４０とコンテンツインポータ３５０の認証後、ＳＲＭ３３０からコンテンツインポータ３５０にコンテンツが順次伝達される。
【００９３】
例えば、ドメインクライアント３１０は、コンテンツメディエータ３２０に多数のコンテンツの伝送を要求する。すると、コンテンツメディエータ３２０は、コンテンツエクスポータ３３０及びコンテンツインポータ３５０に各々多数のコンテンツのエクスポート及びインポートを要求する要求メッセージを送信する。送信デバイスにＳＲＭ３４０が挿入されれば、コンテンツエクスポータ３３０は、ＳＲＭ３４０を認識した後、認証を実行する。認証が完了されると、コンテンツエクスポータ３３０は、エクスポート機能を用いて第１のコンテンツから最後のコンテンツまで一つずつ順次伝送し、ＳＲＭ３４０は、これらを一つずつ受信して格納した後、確認メッセージを各々送信する。次に、受信デバイスにＳＲＭ３４０が挿入されれば、コンテンツインポータ３５０は、ＳＲＭ３４０を認識した後、認証を実行する。認証が完了されれば、コンテンツインポータ３５０は、インポート機能を用いて第１のコンテンツから最後のコンテンツまで一つずつＳＲＭ３４０から取ってきてインポートすることができる。
【００９４】
一方、ＩＰＴＶシステムは、リアルタイム放送サービスとオンデマンドサービスを連動して様々なサービスを提供することができる。例えば、ＩＰＴＶシステムは、リアルタイム放送を視聴してきたユーザがいかなる理由で該当放送を放送時間に制約無しにオンデマンドコンテンツの形態で提供を受けたり伝達できるようにするサービスを提供することができる。
【００９５】
リアルタイム放送サービスとオンデマンドサービスとの連動を介して提供できるサービスは、次のような例がある。
【００９６】
シナリオ１.
【００９７】
ユーザがリアルタイム放送を視聴中であり、現在視聴中である放送プログラムを時間制約なしに視聴しようとする。ユーザは、視聴中である放送プログラムに対応するオンデマンドコンテンツの提供をサービスプロバイダに要求する。すると、サービスプロバイダは、該当コンテンツに対するオンデマンドサービスを提供し、ユーザは、今後所望の時間にオンデマンドコンテンツを視聴することができる。また、ユーザが所望する場合、直ちにオンデマンドコンテンツサービスに切り換えることもできる。
【００９８】
シナリオ２.
【００９９】
ユーザＡは、リアルタイム放送プログラムＡ１を視聴しており、現在視聴中である放送プログラムＡ１をユーザＢに知らせようとする。ユーザＡは、視聴中である放送プログラムＡ１に対する情報とユーザＢに対する情報(例えば、ID、電子メール ID、電話番号、SMS、MMS、IMID等)とをサービスプロバイダに伝達する。すると、サービスプロバイダは、ユーザＡが視聴中である放送プログラムＡ１に対する情報をユーザＢに送信し、ユーザＢも放送プログラムＡ１を受信することができる。
【０１００】
シナリオ３.
【０１０１】
シナリオ１またはシナリオ２にブックマーク機能を提供する。例えば、サービスプロバイダは、ユーザが見ていた放送の全体をオンデマンドサービスを介して提供したり、ユーザが視聴中断した部分の放送からオンデマンドサービスを介して見ることができるオンデマンドサービスビュー機能を提供する。
【０１０２】
シナリオ４.
【０１０３】
シナリオ１〜シナリオ３にトリックモード(Trick Mode)機能を提供する。例えば、現在視聴中である放送をトリックモードまたはブックマークを介して所望の場面または区間に移動することができる。
【０１０４】
図１１は、リアルタイムリアルタイム放送サービスとオンデマンドサービスとを連動してサービスを提供する実施例を示すフローチャートである。
【０１０５】
図１１に示すように、まずユーザＡはサービスプロバイダから放送サービスを受信している(段階：Ｓ５１)。このとき、ユーザＡはオンデマンドサービスが可能かどうかを検査することができる(段階：Ｓ５２)。もし、可能な場合、ユーザＡはサービスプロバイダにオンデマンドサービスを要求することができる(段階：Ｓ５３)。要求時にはデバイスまたはユーザＩＤ、コンテンツＩＤ、ブックマーク情報などをサービスプロバイダに提供することができる。
【０１０６】
すると、サービスプロバイダは、ユーザＡにオンデマンドサービスを提供する(段階：Ｓ５４)。このとき、ダウンロードサービスを提供するか、あるいはストリーミングサービスを提供するかは、ユーザＡの要求に従って決められることができ、ユーザＡによって要求された形態でサービスを提供することができる。
【０１０７】
一方、ユーザＡは、友人情報を確認した後(段階：Ｓ５５)、ユーザＢに視聴中である(または所望の)プログラムを知らせるためにサービスプロバイダにサービスを要求することができる(段階：Ｓ５６)。このとき、ユーザＡは、プログラム情報(例えば、コンテンツID、ブックマーク情報、ユーザＢの情報、伝送タイプなど）をサービスプロバイダに提供することができる。
【０１０８】
サービスプロバイダは、該当プログラムの情報をユーザＢに伝送し(段階：Ｓ５７)、ユーザＢは、プログラムに対する要求をサービスプロバイダに伝送する(段階：Ｓ５８)。すると、サービスプロバイダは、ユーザＢから要求された放送プログラムをユーザＢに伝送する(段階：Ｓ５９)。
【０１０９】
一方、ドメイン内でコンテンツを共有する時は、ＤＲＭ相互運用システム(DRM Interoperable System)が適用されることができる。ＤＲＭ相互運用システムにおいて権限情報を效率的に処理することが要求される。以下、ＤＲＭ相互運用システムにおいて権限情報を格納して著作権満了コンテンツを処理する過程を説明する。
【０１１０】
ＤＲＭ相互運用システムの構成要素を記述すると、次の通りである。
【０１１１】
クライアント：ドメインデバイスに含まれるモジュールであり、ＤＲＭコンテンツの変換が必要な時、ＤＲＭ相互運用システムにコンテンツ及びライセンスの変換を要求することができる。すなわち、クライアントが属するデバイスのＤＲＭシステムに適するコンテンツ及びライセンスファイルを要求することができる。
【０１１２】
権限メディエータ(Rights Mediator)：クライアントからライセンス変換要求情報を受信し、クライアントに対する認証及び変換要求情報に適する権限を確認するモジュールである。
【０１１３】
権限レジストリ(Righst Registry)：ＤＲＭ相互運用システムで流通される権限トークン(Rights Token)を格納するレポジトリである。権限トークンは、複数のネイティブＤＲＭシステムのライセンス情報を抽出することができる情報であり、ＤＲＭ相互運用時にライセンスの中間媒介体の役割をする。権限トークンは、サービスプロバイダが所有した様々なＤＲＭのライセンスフォーマットに関係なく中立的なＸＭＬ形態のデータ構造を有し、相異するサービスプロバイダ間の異質的なＤＲＭライセンス表記法をお互いに互換性があるようにするための役割を担当する。
【０１１４】
ＤＲＭクライアント：ＭＳ-ＤＲＭクライアントおよびＯＭＡ-ＤＲＭクライアントなどのように特定のネイティブＤＲＭ技術のクライアントを意味することができる。
【０１１５】
安全データベース(Secure DB)：クライアントにおいてネイティブＤＲＭのライセンスを格納するための安全な空間を意味することができる。
【０１１６】
ＤＲＭライセンスサーバ(DRM License Server)：ネイティブＤＲＭのライセンスを発給する個体であり、ＤＲＭライセンスサーバからユーザ装置にネイティブＤＲＭのライセンスを発給することができる。
【０１１７】
アプリケーションサーバ(Application Server)：コンテンツサービスプロバイダがコンテンツの販売を目的として実現したモジュール(例えば、ウェブページ等)を意味することができる。
【０１１８】
承認サーバ(Authorization Server)：特定ユーザに対するコンテンツ購入如何(例えば、権限)を確認するサーバを意味することができる。
【０１１９】
権限データベース(Rights DB)：ユーザがコンテンツサービスプロバイダのコンテンツを購入した権限情報を格納するサーバを意味することができる。
【０１２０】
このようなシステムの処理の流れを説明すると次の通りである。まずクライアントＡが所有したＤＲＭに適するＤＲＭライセンスを要求する。権限メディエータは、クライアントＡの要求を受信して権限レポジトリに格納された権限トークンを介してクライアントＡがコンテンツ使用権限があるかどうかを点検する。権限レポジトリは、サービスプロバイダＡのコンテンツの中、クライアントＡが保有した権限情報を有している権限トークンを格納しようとする。権限トークンの内部情報である使用モデル(Usage Model)情報にはネイティブＤＲＭライセンスと同じ情報が記述される。権限メディエータは、権限レポジトリに格納された権限トークンの使用モデル情報の点検を介してクライアントＡのライセンス変換要求の受け入れを決定することができる。
【０１２１】
使用モデル情報の中「ＤＲＭ-disabled」属性は、使用モジュールに対応されるコンテンツの著作権が満了したか否かを表示するブールタイプ(Boolean Type)のデータであり、著作権が満了したコンテンツの場合、「Ｔｒｕｅ」値を、満了していないコンテンツの場合は「Ｆａｌｓｅ」値を保有する。もし、使用モデルの点検を介してクライアントＡがコンテンツに対する使用権限が無いことが判明しても「ＤＲＭ-ｄｉｓａｂｌｅｄ」の値が「Ｔｒｕｅ」の場合、クライアントＡが要求したＤＲＭライセンス要求に対応する権限をクライアントＡが有していると判断し、相互運用処理を継続することができる。
【０１２２】
権限メディエータは、ユーザの権限情報が含められた権限トークンをサービスプロバイダのＤＢに格納する時、Ｕｓａｇｅ-Ｍｏｄｅｌの「ＤＲＭ-Ｄｉｓａｂｌｅｄ」属性が「Ｔｒｕｅ」に設定された場合、該当コンテンツに対するユーザ権限を無限に設定することができる。例えば、コンテンツが実行できる時間及び実行回数の制限を除去した後、権限トークンを格納することができる。
【０１２３】
権限メディエータは、クライアントＡが要求した形態の実際ＤＲＭライセンスが取得できるＵＲＬ情報を受信してクライアントＡのクライアントモジュールに伝達する。クライアントモジュールは、受信したＵＲＬ情報をネイティブＤＲＭクライアントに伝達し、ＤＲＭクライアントは対応ＵＲＬに接続する。
【０１２４】
次に、認証サーバは以前に格納された権限トークンを再確認し、その結果、正当な権限を有していると判断されれば、ＤＲＭライセンスサーバにＤＢに格納されている権限に対応するクライアントＡのＤＲＭクライアントが解釈できるネイティブＤＲＭライセンスの生成を要求する。また、生成されたライセンスをクライアントＡのＤＲＭクライアントに伝達することができる。すると、クライアントＡのＤＲＭクライアントは、伝達されたライセンスを使用してコンテンツを実行することができる。
【０１２５】
以下、ユーザがストアフロント(Store Front)を介してコンテンツライセンスを購入する場合、ユーザの権限を権限インジェクタ(Rights Injector)を用いてＤＲＭ相互運用システムの権限レポジトリに格納する過程を説明する。
【０１２６】
図１２は、権限インジェクタを用いて権限レポジトリにユーザの権限を格納する例を示す例示図である。
【０１２７】
図１２に示すように、ユーザは、ストアフロントからライセンスを購入する(段階：Ｓ６１)。ストアフロントは、権限インジェクタ(Rights Injector)から購入されたライセンス情報と信任状(Credential)とを伝達する(段階：Ｓ６２)。このとき、ストアフロントは、権限インジェクタと、権限インジェクタで使用するデータフォーマットを用いて通信することができる。望ましくは、ストアフロント及び権限インジェクタは、同じデバイス(Same Box)に備えられることができ、従って、ネットワークを介する通信を実行しない。しかしながら、本発明はこれに限定されるものではない。
【０１２８】
権限インジェクタは、上記情報を受信した後、プリンシパルマネージャ(Principal Manager)に「Ｑｕｅｒｙ  Ｐｒｉｎｃｉｐａｌ Ｒｅｌａｔｉｏｎｓ Ｉｎｔｅｒｆａｃｅ」を使用して質疑する(段階：Ｓ６３)。プリンシパルマネージャは、信任状を検証し、ユーザと連係されている様々な他のプリンシパルを含むプリンシパルチェーン(Chain)のリストを送る(段階：Ｓ６４)。
【０１２９】
権限インジェクタは、信任状の有効性をチェックする(段階：Ｓ６５)。もし、信任状の有効性が成功裏に検証されば(段階：Ｓ６６)、権限インジェクタは、権限レポジトリに「Ｒｅｇｉｓｔｅｒ Ｒｉｇｈｔｓ」インタフェースを呼び出してユーザによって購入された権限を登録することを要求した後(段階：Ｓ６７)、その応答を権限レポジトリから受信する(段階：Ｓ６８)。このとき、権限の登録が成功裏に行われた場合、権限インジェクタは、権限が成功裏に登録されたことを知らせるメッセージを、ストアフロントに伝送する(段階：Ｓ６９)。ストアフロントは、ユーザに受信したメッセージを伝達する(段階：Ｓ７０)。
【０１３０】
以上、本発明に対してその望ましい実施例を図面を参照して説明したが、該当技術分野の熟練された当業者は、特許請求の範囲に記載された本発明の技術的思想及び領域から外れない範囲内で本発明を多様に修正及び変更させて実施できることを理解することができる。従って、本発明の今後の実施例等の変更は、本発明の技術を外れないことができない。
【図１】
2010539782.tif 000003
【図２】
2010539782.tif 000004
【図３】
2010539782.tif 000005
【図４】
2010539782.tif 000006
【図５】
2010539782.tif 000007
【図６】
2010539782.tif 000008
【図７】
2010539782.tif 000009
【図８】
2010539782.tif 000010
【図９】
2010539782.tif 000011
【図１０】
2010539782.tif 000012
【図１１】
2010539782.tif 000013
【図１２】
2010539782.tif 000014
【国際調査報告】
2010539782.tif 000015
2010539782.tif 000016