(57)【特許請求の範囲】
【請求項１】
ユーザの個人関心事に基づいてインタラクティブサービスを推奨するための前記インタラクティブサービスの特性を示す選好クライテリア（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ）を含み、前記インタラクティブサービスを記述するサービスフラグメントを含む、ＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）情報を受信するステップと、
放送信号を介してＰＤＩ（Ｐｒｏｆｉｌｅｓ、Ｄｅｍｏｇｒａｐｈｉｃｓ、Ｉｎｔｅｒｅｓｔｓ）テーブルを受信するステップであって、前記ＰＤＩテーブルは、前記インタラクティブサービスのためのユーザの個人関心事に関連した複数のＰＤＩ質問を含み、前記複数のＰＤＩ質問の一つのＰＤＩ質問は、前記ＰＤＩ質問を識別する質問識別子を含む、ステップと、
前記ＰＤＩ質問に対するＰＤＩ答弁を取得するステップと、
前記取得されたＰＤＩ答弁を前記ＰＤＩテーブルに追加するステップと、
前記ＰＤＩテーブルを保存するステップと、
前記ＥＳＧ情報から前記選好クライテリアをパーシングするステップであって、前記選好クライテリアは複数のクライテリオン(criterion)を含み、前記複数のクライテリオンの一つのクライテリオンは前記クライテリオンを識別するクライテリオンＩＤと前記クライテリオンに対する答弁を示すクライテリオン値を含み、前記選好クライテリアは前記インタラクティブサービスを推奨するかを決定するための決定クライテリアを示すマッチングバウンダリ情報を含む、ステップと、
前記パーシングした選好クライテリアからの前記クライテリオンのクライテリオンＩＤが、保存したＰＤＩテーブルからの前記ＰＤＩ質問の質問ＩＤとマッチングするかを質問するステップと、
前記質問するステップが前記クライテリオンの前記クライテリオンＩＤが前記ＰＤＩ質問の質問ＩＤとマッチングすることを示す時、前記パーシングした選好クライテリアからの前記クライテリオンのクライテリオン値を、前記保存したＰＤＩテーブルからの前記質問ＩＤに識別される前記ＰＤＩ質問に対応する前記ＰＤＩ答弁とを比較するステップと、
前記比較するステップが、前記クライテリオンの前記クライテリオン値が前記クライテリオンＩＤにより識別された前記ＰＤＩ質問に対応する前記ＰＤＩ答弁とマッチングすることを示す時、前記クライテリオンをマッチングしたクライテリオンと決定するステップと、
前記選好クライテリアの前記複数のクライテリオンの中の前記マッチングしたクライテリオンの数を計算するステップと、
前記マッチングしたクライテリオンの数がＥＳＧを介した前記決定クライテリアより多い時、前記インタラクティブサービスを推奨するステップと、を含む、インタラクティブサービス提供方法。
【請求項２】
受信機がＥＳＧ情報の受信を支援することを示す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受信するステップであって、前記通知は、ＥＳＧサーバーのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を含む、ステップと、
前記ＥＳＧサーバーに前記ＥＳＧ情報を要求するステップと、
をさらに含む、請求項１に記載のインタラクティブサービス提供方法。
【請求項３】
前記選好クライテリアは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキマー（ｓｃｈｅｍａ）又はデスクリプタタイプを有する、請求項１に記載のインタラクティブサービス提供方法。
【請求項４】
受信機を用いるユーザを識別するユーザ識別子を取得するステップと、
前記ユーザ識別子を用いてユーザを識別するステップと、
前記ＰＤＩテーブルに前記ユーザ識別子を保存するステップをさらに含み、
前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁の取得は、前記ユーザ識別子に基づき、
前記ＰＤＩテーブルの前記取得された答弁の保存は、前記ユーザ識別子に基づいている、請求項１に記載のインタラクティブサービス提供方法。
【請求項５】
クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信するステップと、
前記付加選好情報によってＰＤＩ質問を生成するステップと、
前記ＰＤＩテーブルに前記生成されたＰＤＩ質問を追加するステップと、
をさらに含む、請求項１に記載のインタラクティブサービス提供方法。
【請求項６】
前記付加選好情報は、クローズドキャプション言語の選好されるタイプに関する情報、視覚障害者のためのオーディオモードに関する情報、及びサイン言語の選好されるタイプに関する情報を含む、請求項５に記載のインタラクティブサービス提供方法。
【請求項７】
ユーザの個人関心事に基づいてインタラクティブサービスを推奨するための前記インタラクティブサービスの特性を示す選好クライテリア（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ）を含み、前記インタラクティブサービスを記述するサービスフラグメントを含む、ＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）情報を受信する第１受信プロセッサと、
放送信号を介してＰＤＩ（Ｐｒｏｆｉｌｅｓ、Ｄｅｍｏｇｒａｐｈｉｃｓ、Ｉｎｔｅｒｅｓｔｓ）テーブルを受信する第２受信プロセッサであって、前記ＰＤＩテーブルは、インタラクティブサービスのためのユーザの個人関心事に関連した複数のＰＤＩ質問を含み、前記複数のＰＤＩ質問の一つのＰＤＩ質問は、前記ＰＤＩ質問を識別する質問識別子を含む、第２受信プロセッサと、
前記ＰＤＩ質問に対するＰＤＩ答弁を取得する取得プロセッサと、
前記ＰＤＩテーブルへの前記取得されたＰＤＩ答弁を追加する追加プロセッサと、
前記ＰＤＩテーブルを保存する保存プロセッサと、
前記ＥＳＧ情報から前記選好クライテリアをパーシングする決定プロセッサであって、前記選好クライテリアは複数のクライテリオン(criterion)を含み、前記複数のクライテリオンの一つのクライテリオンは前記クライテリオンを識別するクライテリオンＩＤと前記クライテリオンに対する答弁を示すクライテリオン値を含み、前記選好クライテリアは前記インタラクティブサービスを推奨するかを決定するための決定クライテリアを示すマッチングバウンダリ情報を含む、決定プロセッサと、
前記決定プロセッサは、前記パーシングした選好クライテリアからの前記クライテリオンのクライテリオンＩＤが、保存したＰＤＩテーブルからの前記ＰＤＩ質問の質問ＩＤとマッチングするかを質問し、
前記決定プロセッサは、前記クライテリオンの前記クライテリオンＩＤが前記ＰＤＩ質問の質問ＩＤとマッチングする時、前記パーシングした選好クライテリアからの前記クライテリオンのクライテリオン値を、前記保存したＰＤＩテーブルからの前記質問ＩＤで識別される前記ＰＤＩ質問に対応する前記ＰＤＩ答弁とを比較し、
前記決定プロセッサは、前記クライテリオンの前記クライテリオン値が前記クライテリオンＩＤにより識別された前記ＰＤＩ質問に対応する前記ＰＤＩ答弁とマッチングする時、前記クライテリオンをマッチングしたクライテリオンと決定し、
前記決定プロセッサは、前記選好クライテリアの前記複数のクライテリオンの中の前記マッチングしたクライテリオンの数を計算し、
前記マッチングしたクライテリオンの数がＥＳＧを介した前記決定クライテリアより多い時、前記インタラクティブサービスを推奨するプリゼンティング（ディスプレイ）プロセッサと、
を備える、インタラクティブサービス提供装置。
【請求項８】
受信機がＥＳＧ情報の受信を支援することを示す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受信する通知受信プロセッサであって、前記通知は、ＥＳＧサーバーのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を含む、通知受信プロセッサと、
前記ＥＳＧサーバーに前記ＥＳＧ情報を要求するリクエスティングプロセッサと、をさらに備える、請求項７に記載のインタラクティブサービス提供装置。
【請求項９】
前記選好クライテリアは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキマー（ｓｃｈｅｍａ）又はデスクリプタタイプを有する、請求項７に記載のインタラクティブサービス提供装置。
【請求項１０】
受信機を用いるユーザを識別するユーザ識別子を取得するユーザ識別子取得プロセッサと、
前記ユーザ識別子を用いてユーザを識別する識別プロセッサと、をさらに備え、
前記保存プロセッサは前記ＰＤＩテーブルに前記ユーザ識別子を保存し、
前記取得プロセッサは、前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁を前記ユーザ識別子に基づいて取得し、
前記保存プロセッサは、前記取得された答弁を前記ユーザ識別子に基づいて前記ＰＤＩテーブルに保存する、請求項７に記載のインタラクティブサービス提供装置。
【請求項１１】
クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信する第３受信プロセッサと、
前記付加選好情報によってＰＤＩ質問を生成する生成プロセッサと、
前記ＰＤＩテーブルに前記生成されたＰＤＩ質問を追加する追加プロセッサと、
をさらに備える、請求項７に記載のインタラクティブサービス提供装置。
【請求項１２】
前記付加選好情報は、クローズドキャプション言語の選好されるタイプに関する情報、視覚障害者のためのオーディオモードに関する情報、及びサイン言語の選好されるタイプに関する情報を含む、請求項１１に記載のインタラクティブサービス提供装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、放送信号送信装置、放送信号受信装置、放送信号を送受信する方法に関する。
【背景技術】
【０００２】
アナログ放送信号の送信が終了することにより、デジタル放送信号を送受信する様々な技術が開発されている。デジタル放送信号は、アナログ放送信号に比べてより多量のビデオ／オーディオデータを含むことができ、ビデオ／オーディオデータに加えて、様々なタイプの追加データをさらに含むことができる。
【０００３】
すなわち、デジタル放送システムは、高画質（ＨＤ；ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ）映像、マルチチャネルオーディオ、及び様々な追加サービスを提供することができる。しかしながら、デジタル放送のために、多量のデータの送信のためのデータ送信効率、送受信ネットワークのロバスト性（ｒｏｂｕｓｔｎｅｓｓ）、及びモバイル受信装備を考慮したネットワーク柔軟性が改善される必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、放送信号を送信して時間ドメインで２個以上の別個の放送サービスを提供する放送送受信システムのデータをマルチプレクスし、マルチプレクスされたデータを同じＲＦ信号帯域幅で送信する装置及び方法、及びそれに対応する放送信号を受信する装置及び方法を提供することにある。
【０００５】
本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して、サービスに対応するデータをコンポーネント別に分類し、各コンポーネントに対応するデータをデータパイプとして送信し、データを受信及び処理する方法を提供することにある。
【０００６】
本発明の他の目的は、放送信号を送信する装置、放送信号を受信する装置、及び放送信号を送受信して放送信号を提供するために必要なシグナリング情報をシグナルする方法を提供することにある。
【課題を解決するための手段】
【０００７】
本発明の一実施例に係るインタラクティブサービス又はコンテンツ提供方法は、ユーザの個人関心事に基づいてユーザにインタラクティブサービス又はコンテンツを推奨するための前記インタラクティブサービス又はコンテンツの特性を示す選好クライテリア（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ）を含むＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）情報を受信するステップと、放送信号を介してＰＤＩ（Ｐｒｏｆｉｌｅｓ、Ｄｅｍｏｇｒａｐｈｉｃｓ、Ｉｎｔｅｒｅｓｔｓ）テーブルを受信するステップであって、前記ＰＤＩテーブルは、インタラクティブコンテンツのためのユーザの個人関心事に関連した複数のＰＤＩ質問を含む、前記複数のＰＤＩ質問のそれぞれは、前記複数のＰＤＩ質問のそれぞれを識別する質問識別子を含む、ステップと、前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁を取得するステップと、前記取得された答弁を前記ＰＤＩテーブルに保存するステップと、前記選好クライテリアと前記取得された答弁とを比較して推奨インタラクティブサービス又はコンテンツを決定するステップと、前記決定された推奨インタラクティブサービス又はコンテンツをＥＳＧで表現するステップを含む。
【０００８】
好ましくは、前記選好クライテリアと前記取得された答弁とを比較して推奨インタラクティブサービス又はコンテンツを決定するステップは、前記ＥＳＧ情報から前記選好クライテリアをパースするステップであって、前記選好クライテリアは、複数のクライテリオン（ｃｒｉｔｅｒｉｏｎ）を含み、前記複数のクライテリオンのそれぞれは、前記複数のクライテリオンをそれぞれ識別するクライテリオン識別子を有するクライテリオン質問及び前記クライテリオン質問に対する答弁を示すクライテリオン値を含む、ステップと、前記クライテリオン識別子及び前記質問識別子を用いて前記ＰＤＩテーブルからＰＤＩ質問に対する答弁を持ってくるステップであって、前記持ってきた答弁に対する前記ＰＤＩ質問は前記クライテリオン質問とマッチされる、ステップと、前記持ってきた答弁と前記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定するステップを含む。
【０００９】
好ましくは、前記選好クライテリアは、インタラクティブサービス又はコンテンツが推奨されるか否かを決定するためのバウンダリ（ｂｏｕｎｄａｒｙ）を示すマッチングバウンダリ情報（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ  ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記取得した答弁と前記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定するステップは、前記取得した答弁とマッチされるクライテリオンの個数を計算するステップと、前記取得した答弁とマッチされるクライテリオンの個数が、前記マッチングバウンダリ情報が示す個数よりも大きいと、推奨インタラクティブサービス又はコンテンツを決定するステップをさらに含む。
【００１０】
好ましくは、前記インタラクティブサービス又はコンテンツ提供方法は、受信機がＥＳＧ情報受信を支援することを示す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受信するステップであって、前記通知はＥＳＧサーバーのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を含む、ステップと、前記ＥＳＧサーバーに前記ＥＳＧ情報をリクエストするステップをさらに含む。
【００１１】
好ましくは、前記選好クライテリアは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキマー（ｓｃｈｅｍａ）又はデスクリプタタイプを有する。
【００１２】
好ましくは、前記インタラクティブサービス又はコンテンツ提供方法は、受信機を用いるユーザを識別するユーザ識別子を取得するステップと、前記ユーザ識別子を用いてユーザを識別するステップと、前記ＰＤＩテーブルに前記ユーザ識別子を保存するステップであって、前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁は、前記ユーザ識別子に基づいて取得され、前記取得された答弁は前記ユーザ識別子に基づいて前記ＰＤＩテーブルに保存される、ステップをさらに含む。
【００１３】
好ましくは、前記インタラクティブサービス又はコンテンツ提供方法は、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信するステップと、前記付加選好情報によってＰＤＩ質問を生成するステップと、前記ＰＤＩテーブルに前記生成されたＰＤＩ質問を追加するステップをさらに含む。
【００１４】
好ましくは、前記付加選好情報は、クローズドキャプション言語の選好されるタイプに関する情報、視覚障害者のためのオーディオモードに関する情報、及びサイン言語の選好されるタイプに関する情報を含む。
【００１５】
本発明の他の実施例に係るインタラクティブサービス又はコンテンツ提供装置は、ユーザの個人関心事に基づいてユーザにインタラクティブサービス又はコンテンツを推奨するための前記インタラクティブサービス又はコンテンツの特性を示す選好クライテリア（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ）を含むＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）情報を受信する第１受信モジュールと、放送信号を介してＰＤＩ（Ｐｒｏｆｉｌｅｓ、Ｄｅｍｏｇｒａｐｈｉｃｓ、Ｉｎｔｅｒｅｓｔｓ）テーブルを受信する第２受信モジュールであって、前記ＰＤＩテーブルは、インタラクティブコンテンツのためのユーザの個人関心事に関連した複数のＰＤＩ質問を含み、前記複数のＰＤＩ質問のそれぞれは、前記複数のＰＤＩ質問のそれぞれを識別する質問識別子を含む、第２受信モジュールと、前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁を取得する取得モジュールと、前記取得された答弁を前記ＰＤＩテーブルに保存する保存モジュールと、前記選好クライテリアと前記取得された答弁とを比較して推奨インタラクティブサービス又はコンテンツを決定する決定モジュールと、前記決定された推奨インタラクティブサービス又はコンテンツをＥＳＧで表現する表現モジュールを備える。
【００１６】
好ましくは、前記決定モジュールは、前記ＥＳＧ情報から前記選好クライテリアをパースするパースし、前記選好クライテリアは、複数のクライテリオン（ｃｒｉｔｅｒｉｏｎ）を含み、前記複数のクライテリオンのそれぞれは、前記複数のクライテリオンをそれぞれ識別するクライテリオン識別子を有するクライテリオン質問及び前記クライテリオン質問に対する答弁を示すクライテリオン値を含み、前記クライテリオン識別子及び前記質問識別子を用いて前記ＰＤＩテーブルからＰＤＩ質問に対する答弁を持って来て、前記持ってきた答弁に対する前記ＰＤＩ質問は前記クライテリオン質問とマッチされ、前記持ってきた答弁と前記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定する。
【００１７】
好ましくは、前記選好クライテリアは、インタラクティブサービス又はコンテンツが推奨されるか否かを決定するためのバウンダリ（ｂｏｕｎｄａｒｙ）を示すマッチングバウンダリ情報（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ  ｉｎｆｏｒｍａｔｉｏｎ）を含み、前記決定モジュールは、前記取得した答弁とマッチされるクライテリオンの個数を計算し、前記取得した答弁とマッチされるクライテリオンの個数が、前記マッチングバウンダリ情報が示す個数よりも大きいと、推奨インタラクティブサービス又はコンテンツを決定する。
【００１８】
好ましくは、前記インタラクティブサービス又はコンテンツ提供装置は、受信機がＥＳＧ情報受信を支援することを示す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受信する通知受信モジュールであって、前記通知は、ＥＳＧサーバーのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を含む、通知受信モジュールと、前記ＥＳＧサーバーに前記ＥＳＧ情報をリクエストするリクエスティングモジュールをさらに備える。
【００１９】
好ましくは、前記選好クライテリアは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキマー（ｓｃｈｅｍａ）又はデスクリプタタイプを有する。
【００２０】
好ましくは、前記インタラクティブサービス又はコンテンツ提供装置は、受信機を用いるユーザを識別するユーザ識別子を取得するユーザ識別子取得モジュールと、前記ユーザ識別子を用いてユーザを識別する識別モジュールと、をさらに備え、前記保存モジュールは、前記ＰＤＩテーブルに前記ユーザ識別子を保存し、前記取得モジュールは、前記複数のＰＤＩ質問のうち少なくとも一つに対する答弁を前記ユーザ識別子に基づいて取得し、前記保存モジュールは、前記取得された答弁を前記ユーザ識別子に基づいて前記ＰＤＩテーブルに保存する。
【００２１】
好ましくは、前記インタラクティブサービス又はコンテンツ提供装置は、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信する第３受信モジュールと、前記付加選好情報によってＰＤＩ質問を生成する生成モジュールと、前記ＰＤＩテーブルに前記生成されたＰＤＩ質問を追加する追加モジュールをさらに備える。
【００２２】
好ましくは、前記付加選好情報は、クローズドキャプション言語の選好されるタイプに関する情報、視覚障害者のためのオーディオモードに関する情報、及びサイン言語の選好されるタイプに関する情報を含む。
【発明の効果】
【００２３】
本発明は、各サービス又はサービスコンポーネントに対するＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅｓ）を制御するサービス特性によってデータを処理して様々な放送サービスを提供することができる。
【００２４】
本発明は、同じＲＦ信号帯域幅で様々な放送サービスを送信することによって、送信柔軟性を達成することができる。
【００２５】
本発明は、データ送信効率を改善し、ＭＩＭＯシステムを用いて放送信号の送受信のロバスト性を増加させることができる。
【００２６】
本発明によれば、モバイル受信装備で又は屋内環境でも誤りなしでデジタル放送信号を受信できる放送信号送信及び受信方法及び装置を提供することができる。
【図面の簡単な説明】
【００２７】
本発明の追加の理解を提供するために含まれ、本出願の一部に含まれたり、その一部を構成する添付の図面は、本発明の原理を説明する説明と共に、本発明の実施例を示す。
【図１】本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。
【図２】本発明の一実施例に係る入力フォーマッティングブロックを示す図である。
【図３】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図４】本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【図５】本発明の実施例に係るＢＩＣＭブロックを示す図である。
【図６】本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【図７】本発明の一実施例に係るフレーム形成ブロックを示す図である。
【図８】本発明の実施例に係るＯＦＭＤ生成ブロックを示す図である。
【図９】本発明の実施例によって未来の放送サービスのための放送信号を受信する装置の構造を示す図である。
【図１０】本発明の実施例に係るフレーム構造を示す図である。
【図１１】本発明の実施例に係るフレームのシグナリング層構造を示す図である。
【図１２】本発明の実施例に係るプリアンブルシグナリングデータを示す図である。
【図１３】本発明の実施例に係るＰＬＳ１データを示す図である。
【図１４】本発明の実施例に係るＰＬＳ２データを示す図である。
【図１５】本発明の他の実施例に係るＰＬＳ２データを示す図である。
【図１６】本発明の実施例に係るフレームの論理構造を示す図である。
【図１７】本発明の実施例に係るＰＬＳマッピングを示す図である。
【図１８】本発明の実施例に係るＥＡＣマッピングを示す図である。
【図１９】本発明の実施例に係るＦＩＣマッピングを示す図である。
【図２０】本発明の実施例に係るＤＰのタイプを示す図である。
【図２１】本発明の実施例に係るＤＰマッピングを示す図である。
【図２２】本発明の実施例に係るＦＥＣ構造を示す図である。
【図２３】本発明の実施例に係るビットインターリービングを示す図である。
【図２４】本発明の実施例に係るセル―ワードデマルチプレキシングを示す図である。
【図２５】本発明の実施例に係る時間インターリービングを示す図である。
【図２６】本発明の実施例に係るツイスト行―列ブロックインターリーバーの基本動作を示す図である。
【図２７】本発明の他の実施例に係るツイスト行―列ブロックインターリーバーの動作を示す図である。
【図２８】本発明の実施例に係るツイスト行―列ブロックインターリーバーの対角線方向判読パターンを示す図である。
【図２９】本発明の一実施例に係るそれぞれのインターリービングアレイからインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。
【図３０】自動コンテンツ認識へースＥＴＶ（ｅｎｈａｎｃｅｄ  ｔｅｌｅｖｉｓｉｏｎ）サービスシステムを示す図である。
【図３１】本発明の一実施例に係るデジタルウォーターマーキング技術の流れを示す図である。
【図３２】本発明の一実施例に係る自動コンテンツ認識クエリー結果フォーマットを示す図である。
【図３３】本発明の一実施例に係るコンテンツ識別子の構文（ｓｙｎｔａｘ）を示す図である。
【図３４】本発明の一実施例に係る受信機の構造を示す図である。
【図３５】本発明の他の実施例に係る受信機の構造を示す図である。
【図３６】本発明の一実施例に係るデジタル放送システムを示す図である。
【図３７】本発明の他の実施例に係るデジタル放送システムを示す図である。
【図３８】本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
【図３９】本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
【図４０】本発明の一実施例に係るＰＤＩテーブルを示す図である。
【図４１】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４２】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４３】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４４】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４５】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４６】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４７】本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【図４８】本発明の一実施例に係るフィルタリング基準テーブルを示す図である。
【図４９】本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
【図５０】本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
【図５１】本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
【図５２】本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
【図５３】本発明の一実施例に係るＰＤＩテーブルセクションを示す図である。
【図５４】本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【図５５】本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【図５６】本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【図５７】本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
【図５８】本発明の他の実施例に係るＦＤＴインスタンスのＸＭＬスキーマを示す図である。
【図５９】本発明の一実施例に係るキャパビリティ記述語構文を示す図である。
【図６０】本発明の一実施例に係る消費モデルを示す図である。
【図６１】本発明の一実施例に係るフィルタリング基準記述語構文を示す図である。
【図６２】本発明の他の実施例に係るフィルタリング基準記述語構文を示す図である。
【図６３】本発明の他の実施例に係るデジタル放送システムのフローチャートを示す図である。
【図６４】本発明の一実施例に係るＨＴＴＰ要求テーブルを示す図である。
【図６５】本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【図６６】本発明の一実施例に係るＵＲＬリストテーブルを示す図である。
【図６７】本発明の一実施例に係るＴＰＴを示す図である。
【図６８】本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【図６９】本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【図７０】本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【図７１】本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【図７２】本発明の一実施例に係る受信機対象基準テーブルを示す図である。
【図７３】本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
【図７４】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図７５】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図７６】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図７７】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図７８】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図７９】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図８０】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図８１】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図８２】本発明の他の実施例に係る先登録ＰＤＩ質問を示す図である。
【図８３】本発明の一実施例に係るＰＤＩ ＡＰＩを示す図である。
【図８４】本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。
【図８５】本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。
【図８６】本発明の実施例に係る次世代放送システム用プロトコルスタックを示す図である。
【図８７】本発明の実施例に係るＵＰｎＰタイプアクションメカニズムを示す図である。
【図８８】本発明の実施例に係るＲＥＳＴメカニズムを示す図である。
【図８９】本発明の実施例に係る受信機及びコンパニオン装置間のユーザデータの交換を示す構造図である。
【図９０】本発明の実施例に係るＰＤＩユーザデータの一部を示す図である。
【図９１】本発明の実施例に係るＰＤＩユーザデータの他の部分を示す図である。
【図９２】本発明の実施例に係るサービスのサービスタイプ及びサービスＩＤを示す図である。
【図９３】本発明の実施例に係るＵｓｅｒＤａｔａサービスの状態変数を示す図である。
【図９４】本発明の一実施例に係るＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造を示す図である。
【図９５】本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクション（ａｃｔｉｏｎ）を示す図である。
【図９６】本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを説明する図である。
【図９７】本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａを説明する図である。
【図９８】本発明の一実施例に係るＵｓｅｒＤａｔａサービスの拡張された状態変数を示す図である。
【図９９】本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＳｅｔＵｓｅｒＤａｔａを説明する図である。
【図１００】本発明の一実施例に係る、ＵｓｅｒＤａｔａサービスの追加された状態変数を示す図である。
【図１０１】本発明の一実施例に係る、ＵｓｅｒＤａｔａサービスの他の追加された状態変数を示す図である。
【図１０２】本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスの状態変数を示す図である。
【図１０３】本発明の一実施例に係るＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造を示す図である。
【図１０４】本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクション（ａｃｔｉｏｎ）を示す図である。
【図１０５】本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａＱＡを説明する図である。
【図１０６】本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクションのうち、ＳｅｔＵｓｅｒＤａｔａＱＡを説明する図である。
【図１０７】本発明の一実施例に係るＰＤＩユーザデータがブロードバンドチャネルで伝達されるシーケンスダイヤグラムを示す図である。
【図１０８】本発明の一実施例に係るＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの状態変数を示す図である。
【図１０９】本発明の一実施例に係るＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスのアクションを説明する図である。
【図１１０】本発明の一実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの拡張された状態変数を説明する図である。
【図１１１】本発明の他の実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの拡張された状態変数を説明する図である。
【図１１２】本発明の他の実施例に係る受信機とコンパニオンデバイスの間のユーザデータ交換の構造を示す図である。
【図１１３】本発明の他の実施例に係るサービスの、サービスタイプ及びサービスＩＤを示す図である。
【図１１４】本発明の一実施例に係るＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの状態変数を示す図である。
【図１１５】本発明の一実施例に係るＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスのアクションを説明する図である。
【図１１６】本発明の一実施例に係るＦＣがブロードバンドチャネルで伝達されるシーケンスダイヤグラムを示す図である。
【図１１７】本発明の一実施例に係る、ＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの状態変数を示す図である。
【図１１８】本発明の一実施例に係るＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスのアクションを説明する図である。
【図１１９】本発明の一実施例に係るＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの拡張された状態変数を説明する図である。
【図１２０】本発明の他の実施例に係るＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの拡張された状態変数を説明する図である。
【図１２１】本発明の一実施例に係る放送受信機を示す図である。
【図１２２】本発明の他の実施例に係る放送受信機を示す図である。
【図１２３】本発明の一実施例に係るプレゼンテーション選好度（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）を示す図である。
【図１２４】本発明の一実施例に係るクローズドキャプション選好度（Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）のシーケンスダイヤグラムを示す図である。
【図１２５】本発明の他の実施例に係るクローズドキャプション選好度のシーケンスダイヤグラムを示す図である。
【図１２６】本発明の一実施例に係るクローズドキャプション選好度において、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの拡張されたフィールドを示す図である。
【図１２７】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプション使用に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１２８】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプション言語に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１２９】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションのフォントに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３０】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションの文字サイズに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３１】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションの整列に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３２】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションのプリントされる方向に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３３】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションのスクロールされる方向に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３４】本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションのイージーリーダ（ｅａｓｙ  ｒｅａｄｅｒ）モードに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３５】本発明の一実施例に係るオーディオ選好度（Ａｕｄｉｏ  Ｐｒｅｆｅｒｅｎｃｅ）のシーケンスダイヤグラムを示す図である。
【図１３６】本発明の他の実施例に係るオーディオ選好度のシーケンスダイヤグラムを示す図である。
【図１３７】本発明の一実施例に係るオーディオ選好度において、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒの拡張されたフィールドを示す図である。
【図１３８】本発明の一実施例に係るオーディオ選好度において、オーディオの言語に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１３９】本発明の一実施例に係るオーディオ選好度において、オーディオの聴覚障害者のためのモードを使用するか否かに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１４０】本発明の一実施例に係るオーディオ選好度において、オーディオの視覚障害者のためのモードを使用するか否かに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１４１】本発明の一実施例に係る接近性＆手話プレゼンテーション（Ａｃｃｅｓｓｉｂｉｌｉｔｙ  ＆  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）のシーケンスダイヤグラムを示す図である。
【図１４２】本発明の他の実施例に係る接近性＆手話プレゼンテーションのシーケンスダイヤグラムを示す図である。
【図１４３】本発明の一実施例に係る接近性＆手話プレゼンテーションにおいて、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒを示す図である。
【図１４４】本発明の一実施例に係る接近性＆手話プレゼンテーション選好度（Ａｃｃｅｓｓｉｂｉｌｉｔｙ  ＆  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ  Ｐｒｅｆｅｒｅｎｃｅ）において、接近性＆手話プレゼンテーションの使用に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１４５】本発明の一実施例に係る接近性＆手話プレゼンテーション選好度において、手話言語の選好度に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１４６】本発明の一実施例に係る接近性＆手話プレゼンテーション選好度において、手話の位置の選好度に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【図１４７】本発明の一実施例に係るプレゼンテーション選好度（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）において、答弁のアップデートのためのメニュー画面を示す図である。
【図１４８】本発明の他の実施例に係る受信機とコンパニオンデバイスの間のユーザデータ交換の構造を示す図である。
【図１４９】本発明の一実施例に係る、ユーザＩＤフィールドをさらに含むＰＤＩＵｓｅｒＤａｔａを示す図である。
【図１５０】本発明の一実施例に係る、ユーザＩＤを用いてＰＤＩ  Ｑｕｅｓｔｉｏｎに対する答弁を得るシーケンスダイヤグラムを示す図である。
【図１５１】本発明の一実施例に係る、ユーザＩＤを用いてフィルタリングクライテリアを適用するシーケンスダイヤグラムを示す図である。
【図１５２】本発明の一実施例に係る、ユーザＩＤを割り当てる方法を示す図である。
【図１５３】本発明の一実施例に係るチャネル或いはプログラムの推奨に用いる選好度クライテリア（Ｐｒｅｆｅｒｅｎｃｅ  Ｃｒｉｔｅｒｉａ）のＸＭＬスキマー（Ｓｃｈｅｍａ）のダイヤグラムを示す図である。
【図１５４】本発明の一実施例に係るチャネル或いはプログラムの推奨に用いる選好度クライテリアのＸＭＬスキマーを示す図である。
【図１５５】本発明の一実施例に係るチャネル或いはプログラムの推奨に用いる選好度クライテリアのデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）を示す図である。
【図１５６】本発明の一実施例に係る、サービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーの拡張ダイヤグラムを示す図である。
【図１５７】本発明の一実施例に係る、サービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーを示す図である。
【図１５８】本発明の一実施例に係る、コンテンツレベルで選好度クライテリアを伝送するためのＸＭＬスキマーの拡張ダイヤグラムを示す図である。
【図１５９】本発明の一実施例に係る、コンテンツレベルで選好度クライテリアを伝送するためのＸＭＬスキマーを示す図である。
【図１６０】本発明の一実施例に係る、ＥＳＧと共に伝達された選好度クライテリアを用いてユーザにサービス／コンテンツを推奨するシーケンスダイヤグラムを示す図である。
【図１６１】本発明の他の実施例に係る、ＥＳＧと共に伝達された選好度クライテリアを用いてユーザにサービス／コンテンツを推奨するシーケンスダイヤグラムを示す図である。
【図１６２】本発明の一実施例に係る、選好度クライテリアとＰＤＩユーザデータとを比較する方法を示す図である。
【図１６３】本発明の一実施例に係る、選好度クライテリアとＰＤＩユーザデータとを比較するためのマッチングバウンダリ（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ）フィールドを示す図である。
【図１６４】本発明の一実施例に係る、推奨されたサービス／コンテンツを提供するＵＩを示す図である。
【図１６５】本発明の一実施例に係る、インタラクティブサービス又はコンテンツを提供する方法を示す図である。
【発明を実施するための形態】
【００２８】
以下、添付の図面を参照して本発明の好適な実施例を説明する。添付の図面を参照して以下に説明する詳細な説明は、本発明によって具現可能な実施例だけをを示すものではなく、本発明の例示的な実施例を説明するためのものである。次の詳細な説明は、本発明の完壁な理解を提供するために特定の細部事項を含む。しかし、本発明は、このような特定の細部事項なしでも実可能であることは当業者にとって明らかである。
【００２９】
本発明で使われる大部分の用語は、本技術で広く使われるものから選択されたが、一部の用語は出願人によって任意に選択されたものもあり、その意味は必要によって次の説明で詳細に説明する。したがって、本発明は、単純な名称又は意味ではなく、用語の意図する意味に基づいて理解しなければならない。
【００３０】
本発明は、将来の放送サービスのための放送信号を送受信する装置及び方法を提供する。本発明の実施例に係る将来の放送サービスは、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを含む。本発明は、一実施例によって、ノン−ＭＩＭＯ（ｍｕｌｔｉｐｌｅ  ｉｎｐｕｔ  ｍｕｌｔｉｐｌｅ  ｏｕｔｐｕｔ）又はＭＩＭＯを用いて将来の放送サービスのための放送信号を処理することができる。本発明の実施例に係るノン−ＭＩＭＯ方式は、ＭＩＳＯ（ｍｕｌｔｉｐｌｅ  ｉｎｐｕｔ  ｓｉｎｇｌｅ  ｏｕｔｐｕｔ）方式、ＳＩＳＯ（ｓｉｎｇｌｅ  ｉｎｐｕｔ  ｓｉｎｇｌｅ  ｏｕｔｐｕｔ）方式などを含むことができる。
【００３１】
ＭＩＳＯまたはＭＩＭＯは、説明の便宜上、以下で２個のアンテナを使用するが、本発明は、２個以上のアンテナを用いるシステムに適用することができる。
【００３２】
本発明は、特定の使用ケースに要求される性能を獲得しながら、受信機の複雑度を最小化するのにそれぞれ最適化された３個の物理層（ＰＬ）プロファイル（ベース、ハンドヘルド及びアドバンスドプロファイル）を定義することができる。物理層（ＰＨＹ）プロファイルは、該当受信機が具現しなければならない全ての構成のサブセットである。
【００３３】
３個のＰＨＹプロファイルは、機能ブロックのほとんどを共有するが、特定ブロック及び／またはパラメーターにおいて少し異なる。追加のＰＨＹプロファイルを未来に定義することができる。また、システム進化のために、未来のプロファイルは、未来拡張フレーム（ＦＥＦ；ｆｕｔｕｒｅ  ｅｘｔｅｎｓｉｏｎ  ｆｒａｍｅ）を通じて単一ＲＦチャンネルで既存のプロファイルとマルチプレキシングすることができる。以下では、それぞれのＰＨＹプロファイルの細部事項について説明する。
【００３４】
１．ベースプロファイル
ベースプロファイルは、通常、ルーフトップ（ｒｏｏｆ―ｔｏｐ）アンテナに接続された固定受信装置に対する主要な使用ケースを示す。また、ベースプロファイルは、いずれかの場所まで移動可能であるが、比較的停止した受信カテゴリーに属する携帯用装置を含む。ベースプロファイルの使用は、任意の改善された具現例ごとにハンドヘルド装置または車両に拡張可能であるが、このような使用ケースは、ベースプロファイル受信機の動作用に期待されない。
【００３５】
受信のターゲットＳＮＲ範囲は約１０ｄＢ〜２０ｄＢであって、これは、既存の放送システム（例えば、ＡＴＳＣ  Ａ／５３）の１５ｄＢ  ＳＮＲ受信能力を含む。受信機の複雑度及び消費電力は、ハンドヘルドプロファイルを使用するバッテリー動作ハンドヘルド装置の場合のように重要ではない。以下では、ベースプロファイルに対する重要なシステムパラメーターを表１に列挙する。
【００３６】
【表１】
0006348184.tif 000002
【００３７】
２．ハンドヘルドプロファイル
ハンドヘルドプロファイルは、バッテリー電力で動作するハンドヘルド及び車両装置に用いられるように設計される。装置は、歩行者または車両速度で移動することができる。受信機の複雑度のみならず、消費電力はハンドヘルドプロファイルの装置の具現のために非常に重要である。ハンドヘルドプロファイルのターゲットＳＮＲ範囲は約０ｄＢ〜１０ｄＢであるが、より深い室内受信のために意図されるとき、０ｄＢ未満に到逹するように構成することができる。
【００３８】
低いＳＮＲ能力に加えて、受信機の移動度によってもたらされるドップラー（Ｄｏｐｐｌｅｒ）効果に対する許容力（ｒｅｓｉｌｉｅｎｃｅ）は、ハンドヘルドプロファイルの最も重要な性能属性である。以下では、ハンドヘルドプロファイルに対する重要なシステムパラメーターを表２に列挙する。
【００３９】
【表２】
0006348184.tif 000003
【００４０】
３．アドバンスドプロファイル
アドバンスドプロファイルは、より多くの具現複雑度を犠牲し、最も高いチャンネル容量を提供する。このプロファイルは、ＭＩＭＯ送受信を利用するように要求し、ＵＨＤＴＶサービスは、このプロファイルが特別に設計されたターゲット使用ケースである。与えられた帯域幅で増加した数のサービス、例えば、多数のＳＤＴＶまたはＨＤＴＶサービスを許容するように、増加した容量を使用することができる。
【００４１】
アドバンスドプロファイルのターゲットＳＮＲ範囲は、約２０ｄＢ〜３０ｄＢである。ＭＩＭＯ送信は、初期に既存の楕円偏波送信装備を利用することができ、未来に全出力（ｆｕｌｌ―ｐｏｗｅｒ）交差偏波送信に拡張される。以下では、アドバンスドプロファイルに対する重要なシステムパラメーターを表３に列挙する。
【００４２】
【表３】
0006348184.tif 000004
【００４３】
この場合、ベースプロファイルは、地上波放送サービス及びモバイル放送サービスのためのプロファイルに使用することができる。すなわち、ベースプロファイルは、モバイルプロファイルを含むプロファイルの概念を定義するのに使用することができる。また、アドバンスドプロファイルは、ＭＩＭＯを有するベースプロファイルのためのアドバンスドプロファイル、及びＭＩＭＯを有するハンドヘルドプロファイルのためのアドバンスドプロファイルに分割することができる。また、３個のプロファイルは、設計者の意図によって変更可能である。
【００４４】
次の用語及び定義を本発明に適用することができる。次の用語及び定義は、設計によって変更可能である。
【００４５】
補助ストリーム：未だに定義されていない変調及びコーディングのデータを伝達するセルのシーケンスであって、未来拡張のために、または、放送社またはネットワークオペレーターによる要求に応じて使用することができる。
【００４６】
ベースデータパイプ：サービスシグナリングデータを伝達するデータパイプ
【００４７】
ベースバンドフレーム（またはＢＢＦＲＡＭＥ）：一つのＦＥＣエンコーディングプロセス（ＢＣＨ及びＬＤＰＣエンコーディング）への入力を形成するＫｂｃｈのセット
【００４８】
セル：ＯＦＤＭ送信の一つのキャリアによって伝達される変調値
【００４９】
コーディングブロック：ＰＬＳ１データのＬＤＰＣエンコーディングブロック及びＰＬＳ２データのＬＤＰＣエンコーディングブロックのうち一つ
【００５０】
データパイプ：サービスデータまたは関連メタデータを伝達する物理層内の論理チャンネルであって、一つまたは多数のサービスまたはサービスコンポーネントを伝達することができる。
【００５１】
データパイプ単位：フレーム内のＤＰにデータセルを割り当てる基本単位
【００５２】
データシンボル：プリアンブルシンボルでないフレーム内のＯＦＤＭシンボル（フレームシグナリングシンボル及びフレームエッジシンボルはデータシンボルに含まれる。）
【００５３】
ＤＰ＿ＩＤ：この８ビットフィールドは、ＳＹＳＴＥＭ＿ＩＤによって識別されるシステム内でＤＰを固有に識別する。
【００５４】
ダミーセル：ＰＬＳシグナリング、ＤＰまたは補助ストリームに使用されない残りの容量を充填するのに使用される擬似ランダム値を伝達するセル
【００５５】
非常警戒（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ）チャンネル：ＥＡＳ情報データを伝達するフレームの一部
【００５６】
フレーム：プリアンブルで開始し、フレームエッジシンボルで終了する物理層時間スロット
【００５７】
フレーム反復単位：スーパーフレームで８回繰り返される、ＦＥＦを含む同一または異なる物理層プロファイルに属するフレームセット
【００５８】
速い情報チャンネル：サービスと該当ベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャンネル
【００５９】
ＦＥＣＢＬＯＣＫ：ＤＰデータのＬＤＰＣエンコーディングビットのセット
【００６０】
ＦＦＴサイズ：基本期間Ｔのサイクルで表現されるアクティブシンボル期間Ｔｓと同一の、特定モードに使用される公称ＦＦＴサイズ
【００６１】
フレームシグナリングシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）及び分散型（ｓｃａｔｔｅｒｅｄ）パイロットパターンの所定の組み合わせにおいてフレームの開始で使用されるより高いパイロット密度を有するＯＦＤＭシンボルであって、ＰＬＳデータの一部を伝達する。
【００６２】
フレームエッジシンボル：ＦＦＴサイズ、保護区間（ｇｕａｒｄ  ｉｎｔｅｒｖａｌ）及び分散型パイロットパターンの所定の組み合わせにおいてフレームのエンドで使用されるより高いパイロット密度を有するＯＦＤＭシンボル
【００６３】
フレームグループ：スーパーフレームで同一のＰＨＹプロファイルタイプを有する全てのフレームのセット
【００６４】
未来拡張フレーム：未来拡張に使用可能なスーパーフレーム内の物理層時間スロットであって、プリアンブルで開始する。
【００６５】
ヒューチャーキャスト（ｆｕｔｕｒｅｃａｓｔ）ＵＴＢシステム：入力が一つ以上のＭＰＥＧ２―ＴＳ、ＩＰまたは一般ストリームであって、出力がＲＦ信号である提案された物理層放送システム
【００６６】
入力ストリーム：システムによってエンドユーザーに伝達されるサービスのアンサンブルのためのデータのストリーム
【００６７】
ノーマルデータシンボル：フレームシグナリングシンボル及びフレームエッジシンボルを除いたデータシンボル
【００６８】
ＰＨＹプロファイル：該当受信機が具現しなければならない全ての構成のサブセット
【００６９】
ＰＬＳ：ＰＬＳ１及びＰＬＳ２で構成される物理層シグナリングデータ
【００７０】
ＰＬＳ１：固定サイズ、コーディング及び変調を有するＦＳＳシンボルで伝達されるＰＬＳデータの第１のセットであって、ＰＬＳ２をデコーディングするのに必要なパラメーターのみならず、システムに対する基本情報を伝達する。
【００７１】
注釈：ＰＬＳ１データは、フレームグループのデュレーションの間に一定に維持される。
【００７２】
ＰＬＳ２：ＦＳＳシンボルで送信されるＰＬＳデータの第２のセットであって、システム及びＤＰに対するより詳細なＰＬＳデータを伝達する。
【００７３】
ＰＬＳ２動的データ：フレーム別に動的に変化可能なＰＬＳ２データ
【００７４】
ＰＬＳ２静的データ：フレームグループのデュレーションの間に静的に維持されるＰＬＳ２データ
【００７５】
プリアンブルシグナリングデータ：プリアンブルシンボルによって伝達され、システムの基本モードを識別するのに使用されるシグナリングデータ
【００７６】
プリアンブルシンボル：基本ＰＬＳデータを伝達し、フレームの開始部分に位置する固定長さパイロットシンボル
【００７７】
注釈：プリアンブルシンボルは、主に速い初期バンドスキャンに使用され、システム信号、そのタイミング、周波数オフセット及びＦＦＴサイズを検出する。
【００７８】
未来使用のために留保：本文書によって定義されないが、未来に定義可能である。
【００７９】
スーパーフレーム：８個のフレーム反復単位のセット
【００８０】
時間インターリービングブロック（ＴＩブロック）：時間インターリーバーメモリの一つの使用に対応して時間インターリービングが行われるセルのセット
【００８１】
ＴＩグループ：特定ＤＰに対する動的容量割り当てが行われる単位であって、整数で構成され、ＸＦＥＣＢＬＯＣＫの数を動的に変更する。
【００８２】
注釈：ＴＩグループは、一つのフレームに直接マッピングされたり、多数のフレームにマッピングされ得る。ＴＩグループは、一つ以上のＴＩブロックを含むことができる。
【００８３】
タイプ１  ＤＰ：全てのＤＰがＴＤＭ方式でフレームにマッピングされるフレームのＤＰ
【００８４】
タイプ２  ＤＰ：全てのＤＰがＦＤＭ方式でフレームにマッピングされるフレームのＤＰ
【００８５】
ＸＦＥＣＢＬＯＣＫ：一つのＬＤＰＣ  ＦＥＣＢＬＯＣＫの全てのビットを伝達するＮｃｅｌｌｓセルのセット
【００８６】
図１は、本発明の実施例によって未来の放送サービスのための放送信号を送信する装置の構造を示す図である。
【００８７】
本発明の実施例によって未来の放送サービスのための放送信号を送信する装置は、入力フォーマッティングブロック１０００、ＢＩＣＭ（ｂｉｔ  ｉｎｔｅｒｌｅａｖｅｄ  ｃｏｄｉｎｇ  ＆  ｍｏｄｕｌａｔｉｏｎ）ブロック１０１０、フレーム構造ブロック１０２０、ＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ）生成ブロック１０３０、及びシグナリング生成ブロック１０４０を含むことができる。以下では、放送信号を送信する装置の各ブロックの動作を説明する。
【００８８】
ＩＰストリーム／パケット及びＭＰＥＧ２―ＴＳはメイン入力フォーマットで、他のストリームタイプは一般ストリームとして処理される。これらデータ入力に加えて、管理情報が入力され、各入力ストリームに対する該当帯域幅のスケジューリング及び割り当てを制御する。一つまたは多数のＴＳストリーム、ＩＰストリーム及び／または一般ストリームの入力が同時に許容される。
【００８９】
入力フォーマッティングブロック１０００は、各入力ストリームを一つまたは多数のデータパイプにデマルチプレキシングすることができ、それぞれのデータパイプには独立的なコーディング及び変調が適用される。データパイプ（ＤＰ）は、ロバスト性制御のための基本単位であって、ＱｏＳに影響を与える。一つまたは多数のサービスまたはサービスコンポーネントは単一ＤＰによって伝達することができる。入力フォーマッティングブロック１０００の動作の細部事項については後で説明する。
【００９０】
データパイプは、サービスデータまたは関連メタデータを伝達する物理層内の論理チャンネルであって、一つまたは多数のサービスまたはサービスコンポーネントを伝達することができる。
【００９１】
また、データパイプ単位は、フレーム内でデータセルをＤＰに割り当てる基本単位である。
【００９２】
ＢＩＣＭブロック１０１０において、エラー訂正のためにパリティデータが付加され、エンコーディングされたビットストリームは複素数値の星状シンボルにマッピングされる。シンボルは、該当ＤＰに使用される特定インターリービング深さにわたってインターリービングされる。アドバンスドプロファイルに対して、ＭＩＭＯエンコーディングがＢＩＣＭブロック１０１０で行われ、ＭＩＭＯ送信のために、出力で追加のデータ経路が付加される。ＢＩＣＭブロック１０１０の細部事項については後で説明する。
【００９３】
フレーム形成ブロック１０２０は、入力ＤＰのデータセルをフレーム内のＯＦＤＭシンボルにマッピングすることができる。マッピング後、周波数インターリービングは、周波数ドメインダイバーシティに使用され、特に、周波数選択フェーディングチャンネルを防止する。フレーム形成ブロック１０２０の動作の細部事項については後で説明する。
【００９４】
それぞれのフレームの開始部分でプリアンブルを挿入した後、ＯＦＤＭ生成ブロック１０３０は、保護区間としてＣＰ（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）を有する従来のＯＦＤＭ変調を適用することができる。アンテナ空間ダイバーシティのために、送信機にわたって分散型ＭＩＳＯ方式が適用される。また、ＰＡＰＲ（ｐｅａｋ―ｔｏ―ａｖｅｒａｇｅ  ｐｏｗｅｒ  ｒｅｄｕｃｔｉｏｎ）方式が時間ドメインで行われる。柔軟なネットワーク計画のために、この提案は、多様なＦＦＴサイズ、保護区間長さ及び該当パイロットパターンのセットを提供する。ＯＦＤＭ生成ブロック１０３０の動作の細部事項については後で説明する。
【００９５】
シグナリング生成ブロック１０４０は、それぞれの機能ブロックの動作に使用される物理層シグナリング情報を生成することができる。また、このシグナリング情報は、関心のあるサービスが受信側で適切に回復されるように送信される。シグナリング生成ブロック１０４０の動作の細部事項については後で説明する。
【００９６】
図２、図３及び図４は、本発明の実施例に係る入力フォーマッティングブロック１０００を示す。各図面に対して説明する。
【００９７】
図２は、本発明の一実施例に係る入力フォーマッティングブロックを示す図である。図２は、入力信号が単一入力ストリームである場合の入力フォーマッティングブロックを示す。
【００９８】
図２に示した入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に該当する。
【００９９】
物理層への入力は、一つまたは多数のデータストリームで構成することができる。それぞれのデータストリームは一つのＤＰによって伝達される。モード適応モジュールは、入ってくるデータストリームをベースバンドフレーム（ＢＢＦ）のデータフィールドにスライスする。システムは、３つのタイプの入力データストリーム、すなわち、ＭＰＥＧ２―ＴＳ、インターネットプロトコル（ＩＰ）及び一般ストリーム（ＧＳ）をサポートする。ＭＰＥＧ２―ＴＳは、固定長さ（１８８バイト）パケットで特徴付けられ、第１のバイトはシンクバイト（０ｘ４７）である。ＩＰストリームは、ＩＰパケットヘッダー内でシグナリングされることによって、可変長さＩＰデータグラムパケットで構成される。システムは、ＩＰストリームに対してＩＰｖ４及びＩＰｖ６をサポートする。ＧＳは、カプセル化パケットヘッダー内でシグナリングされる可変長さパケットまたは固定長さパケットで構成することができる。
【０１００】
（ａ）は、信号ＤＰに対するモード適応ブロック２０００及びストリーム適応２０１０を示し、（ｂ）は、ＰＬＳ生成ブロック２０２０、及びＰＬＳデータを生成して処理するＰＬＳスクランブラー２０３０を示す。以下では、各ブロックの動作を説明する。
【０１０１】
入力ストリームスプリッターは、入力ＴＳ、ＩＰ、ＧＳストリームを多数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離する。モード適応モジュール２０１０は、ＣＲＣエンコーダー、ＢＢ（ベースバンド）フレームスライサー及びＢＢフレームヘッダー挿入ブロックで構成される。
【０１０２】
ＣＲＣエンコーダーは、ユーザーパケット（ＵＰ）レベルでエラー訂正のための３種類のＣＲＣエンコーディング、すなわち、ＣＲＣ―８、ＣＲＣ―１６及びＣＲＣ―３２を提供する。計算されたＣＲＣバイトはＵＰの後に添付される。ＣＲＣ―８はＴＳストリームに使用され、ＣＲＣ―３２はＩＰストリームに使用される。ＧＳストリームがＣＲＣエンコーディングを提供しない場合、提案されたＣＲＣエンコーディングが適用されなければならない。
【０１０３】
ＢＢフレームスライサーは、入力を内部論理ビットフォーマットにマッピングする。第１の受信ビットはＭＢＳであると定義される。ＢＢフレームスライサーは、利用可能なデータフィールド容量と同一の多数の入力ビットを割り当てる。ＢＢＦペイロードと同一の多数の入力ビットを割り当てるために、ＵＰパケットストリームがＢＢＦのデータフィールドに合わせてスライスされる。
【０１０４】
ＢＢフレームヘッダー挿入ブロックは、２バイトの固定長さＢＢＦヘッダーをＢＢフレームの前に挿入することができる。ＢＢＦヘッダーは、ＳＴＵＦＦＩ（１ビット）、ＳＹＮＣＤ（１３ビット）及びＲＦＵ（２ビット）で構成される。固定２バイトＢＢＦヘッダーに加えて、ＢＢＦは、２バイトＢＢＦヘッダーのエンドに拡張フィールド（１または３バイト）を有することができる。
【０１０５】
ストリーム適応２０１０は、スタッフィング（ｓｔｕｆｆｉｎｇ）挿入ブロック及びＢＢスクランブラーで構成される。
【０１０６】
スタッフィング挿入ブロックは、ＢＢフレームのペイロードにスタッフィングフィールドを挿入することができる。ストリーム適応への入力データがＢＢフレームを充填するのに十分である場合、ＳＴＵＦＦＩは「０」に設定され、ＢＢＦはスタッフィングフィールドを有さない。その一方、ＳＴＵＦＦＩが「１」に設定されると、スタッフィングフィールドがＢＢＦヘッダーの直後に挿入される。スタッフィングフィールドは、２バイトのスタッフィングフィールドヘッダー及び可変サイズのスタッフィングデータを含む。
【０１０７】
ＢＢスクランブラーは、エネルギー分散のために完全なＢＢＦをスクランブリングする。スクランブリングシーケンスはＢＢＦと同期する。スクランブリングシーケンスは、フィードバックシフトレジスタによって生成される。
【０１０８】
ＰＬＳ生成ブロック２０２０は、ＰＬＳ（ｐｈｙｓｉｃａｌ  ｌａｙｅｒ  ｓｉｇｎａｌｉｎｇ）データを生成する。ＰＬＳは、物理層ＤＰをアクセスする手段を受信機に提供する。ＰＬＳデータは、ＰＬＳ１データ及びＰＬＳ２データで構成される。
【０１０９】
ＰＬＳ１データは、固定サイズ、コーディング及び変調を有するフレーム内のＦＳＳシンボルで伝達されるＰＬＳデータの第１のセットであって、ＰＬＳ２データをデコーディングするのに必要なパラメーターのみならず、システムに関する基本情報を伝達する。ＰＬＳ１データは、ＰＬＳ２データの受信及びデコーディングを可能にするのに要求されるパラメーターを含む基本送信パラメーターを提供する。また、ＰＬＳ１データは、フレームグループのデュレーションの間に一定に維持される。
【０１１０】
ＰＬＳ２データは、ＦＳＳシンボルで送信されるＰＬＳデータの第２のセットであって、システム及びＤＰに対するより詳細なＰＬＳデータを伝達する。ＰＬＳ２は、受信機が望むＤＰをデコーディングするのに十分な情報を提供するパラメーターを含む。また、ＰＬＳ２シグナリングは、２つのタイプのパラメーター、すなわち、ＰＬＳ２静的データ（ＰＬＳ２―ＳＴＡＴデータ）及びＰＬＳ２動的データ（ＰＬＳ２―ＤＹＮデータ）で構成される。ＰＬＳ２静的データは、フレームグループのデュレーションの間に静的なＰＬＳ２データであって、ＰＬＳ２動的データは、フレームごとに動的に変更可能なＰＬＳ２データである。
【０１１１】
ＰＬＳデータの細部事項については後で説明する。
【０１１２】
ＰＬＳスクランブラー２０３０は、エネルギー分散のために生成されたＰＬＳデータをスクランブリングすることができる。
【０１１３】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１１４】
図３は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【０１１５】
図３に示した入力フォーマッティングブロックは、図１を参照して説明する入力フォーマッティングブロック１０００の実施例に該当する。
【０１１６】
図３は、入力信号が多数の入力ストリームに対応する場合の入力フォーマッティングブロックのモード適応ブロックを示す。
【０１１７】
多数の入力ストリームを処理する入力フォーマッティングブロックのモード適応ブロックは、多数の入力ストリームを独立的に処理することができる。
【０１１８】
図３を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、入力ストリームスプリッター３０００、入力ストリーム同期化器３０１０、補償遅延ブロック３０２０、ヌルパケット削除ブロック３０３０、ヘッド圧縮ブロック３０４０、ＣＲＣエンコーダー３０５０、ＢＢフレームスライサー３０６０及びＢＢヘッダー挿入ブロック３０７０を含むことができる。以下では、モード適応ブロックのそれぞれのブロックを説明する。
【０１１９】
ＣＲＣエンコーダー３０５０、ＢＢフレームスライサー３０６０及びＢＢヘッダー挿入ブロック３０７０の動作は、図２を参照して説明したＣＲＣエンコーダー、ＢＢフレームスライサー及びＢＢヘッダー挿入ブロックに対応するので、それに対する説明は省略する。
【０１２０】
入力ストリームスプリッター３０００は、入力ＴＳ、ＩＰ  ＧＳストリームを多数のサービスまたはサービスコンポーネント（オーディオ、ビデオなど）ストリームに分離することができる。
【０１２１】
入力ストリーム同期化器３０１０はＩＳＳＹと称することができる。ＩＳＳＹは、任意の入力データフォーマットに対してＣＢＲ（ｃｏｎｓｔａｎｔ  ｂｉｔ  ｒａｔｅ）及び一定のエンド―ツー―エンド送信遅延を保障する適切な手段を提供することができる。ＩＳＳＹは、常にＴＳを伝達する多数のＤＰの場合に使用され、選択的に、ＧＳストリームを伝達するＤＰに使用される。
【０１２２】
補償遅延ブロック３０２０は、ＩＳＳＹ情報の挿入後の分離されたＴＳパケットストリームを遅延させ、受信機で追加のメモリを要求せずにＴＳパケット再結合メカニズムを許容することができる。
【０１２３】
ヌルパケット削除ブロック３０３０は、ＴＳ入力ストリームケースにのみ使用される。任意のＴＳ入力ストリームまたは分離されたＴＳストリームは、ＣＢＲ  ＴＳストリームにＶＢＲ（ｖａｒｉａｂｌｅ  ｂｉｔ―ｒａｔｅ）を収容するために存在する多数のヌルパケットを有することができる。この場合、不要な送信オーバーヘッドを避けるために、ヌルパケットが識別されて送信されないこともある。受信機において、除去されたヌルパケットは、送信時に挿入されたＤＮＰ（ｄｅｌｅｔｅｄ  ｎｕｌｌ―ｐａｃｋｅｔ）カウンターを参照し、ヌルパケットが本来あった正確な場所に再挿入することができ、一定のビットレートを保障し、時間―スタンプ（ＰＣＲ）アップデートに対する必要性を回避する。
【０１２４】
ヘッド圧縮ブロック３０４０は、パケットヘッダー圧縮を提供し、ＴＳまたはＩＰ入力ストリームに対する送信効率を増加させることができる。受信機がヘッダーの所定部分に対する先験的（ａ  ｐｒｉｏｒｉ）情報を有し得るので、この既知の情報が送信機で削除され得る。
【０１２５】
伝送ストリームに対して、受信機は、シンクバイト構成（０ｘ４７）及びパケット長さ（１８８バイト）に関する先験的情報を有する。入力ＴＳストリームが一つのＰＩＤ、すなわち、一つのサービスコンポーネント（ビデオ、オーディオなど）またはサービスサブコンポーネント（ＳＶＣベース層、ＳＶＣインヘンスメント層、ＭＶＣベースビューまたはＭＶＣ従属ビュー）を有するコンテンツを伝達すると、ＴＳパケットヘッダー圧縮を伝送ストリームに（選択的に）適用することができる。入力ストリームがＩＰストリームであると、ＩＰパケットヘッダー圧縮が選択的に使用される。
【０１２６】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１２７】
図４は、本発明の他の実施例に係る入力フォーマッティングブロックを示す図である。
【０１２８】
図４に示した入力フォーマッティングブロックは、図１を参照して説明した入力フォーマッティングブロック１０００の実施例に対応する。
【０１２９】
図４は、入力信号が多数の入力ストリームに対応する場合の入力フォーマッティングモジュールのストリーム適応ブロックを示す。
【０１３０】
図４を参照すると、多数の入力ストリームをそれぞれ処理するモード適応ブロックは、スケジューラー４０００、１フレーム遅延ブロック４０１０、スタッフィング挿入ブロック４０２０、インバンドシグナリング４０３０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０及びＰＬＳスクランブラー４０６０を含むことができる。以下では、ストリーム適応ブロックのそれぞれのブロックを説明する。
【０１３１】
スタッフィング挿入ブロック４０２０、ＢＢフレームスクランブラー４０４０、ＰＬＳ生成ブロック４０５０及びＰＬＳスクランブラー４０６０の動作は、図２を参照して説明したスタッフィング挿入ブロック、ＢＢスクランブラー、ＰＬＳ生成ブロック及びＰＬＳスクランブラーの動作に対応するので、それに対する説明は省略する。
【０１３２】
スケジューラー４０００は、それぞれのＤＰのＦＥＣＢＬＯＣＫの量から全体のフレームにわたって全体のセル割り当てを決定することができる。ＰＬＳ、ＥＡＣ及びＦＩＣに対する割り当てを含めて、スケジューラーは、フレームのＦＳＳでインバンドシグナリングまたはＰＬＳセルとして送信されるＰＬＳ２―ＤＹＮデータの値を生成する。ＦＥＣＢＬＯＣＫ、ＥＡＣ及びＦＩＣの細部事項については後で説明する。
【０１３３】
１フレーム遅延ブロック４０１０は、入力データを一つの送信フレームだけ遅延させ、ＤＰに挿入されるインバンドシグナリング情報に対して現在のフレームを通じて次のフレームに関するスケジューリング情報を送信させることができる。
【０１３４】
インバンドシグナリング４０３０は、ＰＬＳ２データの非遅延（ｕｎ―ｄｅｌａｙｅｄ）部分をフレームのＤＰに挿入することができる。
【０１３５】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１３６】
図５は、本発明の実施例に係るＢＩＣＭブロックを示す図である。
【０１３７】
図５に示したＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に対応する。
【０１３８】
上述したように、本発明の実施例に係る未来の放送サービスのための放送信号を送信する装置は、地上波放送サービス、モバイル放送サービス、ＵＨＤＴＶサービスなどを提供することができる。
【０１３９】
ＱｏＳは、本発明の実施例に係る未来の放送サービスのための放送信号を送信する装置によって提供されるサービスの特性に依存するので、それぞれのサービスに対応するデータは、異なる方式を通じて処理される必要がある。よって、本発明の実施例に係るＢＩＣＭブロックは、ＳＩＳＯ、ＭＩＳＯ及びＭＩＭＯ方式をデータ経路にそれぞれ対応するデータパイプに独立的に適用することによって、入力されるＤＰを独立的に処理することができる。結果的に、本発明の実施例に係る未来の放送サービスのための放送信号を送信する装置は、それぞれのＤＰを通じて送信されるそれぞれのサービスまたはサービスコンポーネントに対するＱｏＳを制御することができる。
【０１４０】
（ａ）は、ベースプロファイル及びハンドヘルドプロファイルによって共有されたＢＩＣＭブロックを示し、（ｂ）は、アドバンスドプロファイルのＢＩＣＭブロックを示す。
【０１４１】
ベースプロファイル及びハンドヘルドプロファイルによって共有されるＢＩＣＭブロック及びアドバンスドプロファイルのＢＩＣＭブロックは、それぞれのＤＰを処理する複数の処理ブロックを含むことができる。
【０１４２】
以下では、ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロック及びアドバンスドプロファイルのためのＢＩＣＭブロックの各処理ブロックを説明する。
【０１４３】
ベースプロファイル及びハンドヘルドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００は、データＦＥＣエンコーダー５０１０、ビットインターリーバー５０２０、星状マッパー５０３０、ＳＳＤ（ｓｉｇｎａｌ  ｓｐａｃｅ  ｄｉｖｅｒｓｉｔｙ）エンコーディングブロック５０４０及び時間インターリーバー５０５０を含むことができる。
【０１４４】
データＦＥＣエンコーダー５０１０は、入力ＢＢＦに対してＦＥＣエンコーディングを行い、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。外部コーディング（ＢＣＨ）は選択的なコーディング方法である。データＦＥＣエンコーダー５０１０の動作の細部事項については後で説明する。
【０１４５】
ビットインターリーバー５０２０は、データＦＥＣエンコーダー５０１０の出力をインターリービングし、効率的に具現可能な構造を提供しながらＬＤＰＣコード及び変調方式の組み合わせで最適化された性能を達成することができる。ビットインターリーバー５０２０の動作の細部事項については後で説明する。
【０１４６】
星状マッパー５０３０は、ベース及びハンドヘルドプロファイル内のビットインターリーバー５０２０からの各セルワード及びアドバンスドプロファイル内のセル―ワードデマルチプレクサー５０１０―１からのセルワードをＱＰＳＫ、ＱＡＭ―１６、不均一ＱＡＭ（ＮＵＱ―６４、ＮＵＱ―２５６、ＮＵＱ―１０２４）または不均一星状（ＮＵＣ―１６、ＮＵＣ―６４、ＮＵＣ―２５６、ＮＵＣ―１０２４）を用いて変調し、パワー正規化（ｐｏｗｅｒ―ｎｏｒｍａｌｉｚｅｄ）星状ポイント（ｅｌ）を提供することができる。この星状マッピングはＤＰに対してのみ適用される。ＱＡＭ―１６及びＮＵＱが四角形状で、ＮＵＣは任意の形状であることを観察する。それぞれの星状が９０度の任意の倍数だけ回転すると、回転した星状は正確に本来の星状と重畳する。この「回転―感覚（ｒｏｔａｔｉｏｎ―ｓｅｎｓｅ）」対称性質は、実数及び虚数成分の平均パワー及び容量を互いに同一にする。ＮＵＱ及びＮＵＣは、それぞれコードレートに対して特別に定義され、使用される特定の一つがＰＬＳ２データ内にファイリングされたパラメーター（ＤＰ＿ＭＯＤ）によってシグナリングされる。
【０１４７】
ＳＳＤエンコーディングブロック５０４０は、２次元（２Ｄ）、３次元（３Ｄ）及び４次元（４Ｄ）でセルをプリコーディングし、異なるフェーディング条件下で受信ロバスト性を増加させることができる。
【０１４８】
時間インターリーバー５０５０はＤＰレベルで動作し得る。時間インターリービング（ＴＩ）のパラメーターは、それぞれのＤＰごとに異なる形に設定することができる。時間インターリーバー５０５０の動作の細部事項については後で説明する。
【０１４９】
アドバンスドプロファイルのためのＢＩＣＭブロックの処理ブロック５０００―１は、データＦＥＣエンコーダー、ビットインターリーバー、星状マッパー及び時間インターリーバーを含むことができる。しかし、処理ブロック５０００―１は、セル―ワードデマルチプレクサー５０１０―１及びＭＩＭＯエンコーディングブロック５０２０―１をさらに含むという点で処理ブロック５０００と区別される。
【０１５０】
また、処理ブロック５０００―１内のデータＦＥＣエンコーダー、ビットインターリーバー、星状マッパー及び時間インターリーバーの動作は、データＦＥＣエンコーダー５０１０、ビットインターリーバー５０２０、星状マッパー５０３０及び時間インターリーバー５０５０の動作に対応するので、それに対する説明は省略する。
【０１５１】
セル―ワードデマルチプレクサー５０１０―１は、アドバンスドプロファイルのＤＰに使用され、単一セル―ワードストリームをＭＩＭＯ処理のためのデュアルセル―ワードストリームに分離する。セル―ワードデマルチプレクサー５０１０―１の動作の細部事項については後で説明する。
【０１５２】
ＭＩＭＯエンコーディングブロック５０２０―１は、ＭＩＭＯエンコーディング方式を用いてセル―ワードデマルチプレクサー５０１０―１の出力を処理することができる。ＭＩＭＯエンコーディング方式は、放送信号の送信のために最適化された。ＭＩＭＯ技術は、容量増加を得る有望な方式であるが、チャンネル特性に依存する。特に、放送のために、チャンネルの強いＬＯＳ成分または異なる信号伝播特性によって誘発された２個のアンテナ間の受信信号パワー差は、ＭＩＭＯから容量利得を得ることを困難にする。提案されたＭＩＭＯエンコーディング方式は、ＭＩＭＯ出力信号のうち一つの位相ランダム化及び回転基盤プリコーディングを用いてこの問題を克服する。
【０１５３】
ＭＩＭＯエンコーディングは、送信機及び受信機で少なくとも２個のアンテナを要求する２ｘ２  ＭＩＭＯシステムのために意図される。２個のＭＩＭＯエンコーディングモード、すなわち、ＦＲ―ＳＭ（ｆｕｌｌ―ｒａｔｅ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）及びＦＲＦＤ―ＳＭ（ｆｕｌｌ―ｒａｔｅ  ｆｕｌｌ―ｄｉｖｅｒｓｉｔｙ  ｓｐａｔｉａｌ  ｍｕｌｔｉｐｌｅｘｉｎｇ）がこの提案で定義される。ＦＲ―ＳＭエンコーディングは、受信側で比較的小さい複雑度の増加と共に容量の増加を提供するが、ＦＲＦＤ―ＳＭエンコーディングは、受信側で大きい複雑度の増加と共に、容量の増加及び追加のダイバーシティ利得を提供する。提案されたＭＩＭＯエンコーディング方式は、アンテナ極性設定に制限を有さない。
【０１５４】
アドバンスドプロファイルフレームにＭＩＭＯ処理が要求され、これは、アドバンスドプロファイルフレーム内の全てのＤＰがＭＩＭＯエンコーダーによって処理されることを意味する。ＭＩＭＯ処理はＤＰレベルで適用される。星状マッパー出力ＮＵＱ（ｅ1,i及びｅ2,i）のペアがＭＩＭＯエンコーダーの入力に供給される。ＭＩＭＯエンコーダー出力（ｇ1,i及びｇ2,i）ペアは、それぞれのＴＸアンテナの同一のキャリア（ｋ）及びＯＦＤＭシンボル（ｌ）によって送信される。
【０１５５】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１５６】
図６は、本発明の他の実施例に係るＢＩＣＭブロックを示す図である。
【０１５７】
図６に示したＢＩＣＭブロックは、図１を参照して説明したＢＩＣＭブロック１０１０の実施例に対応する。
【０１５８】
図６は、物理層シグナリング（ＰＬＳ）、非常警戒チャンネル（ＥＡＣ）及び速い情報チャンネル（ＦＩＣ）の保護のためのＢＩＣＭブロックを示す。ＥＡＣは、ＥＡＳ情報データを伝達するフレームの一部であって、ＦＩＣは、サービスとその対応ベースＤＰとの間のマッピング情報を伝達するフレーム内の論理チャンネルである。ＥＡＣ及びＦＩＣの細部事項については後で説明する。
【０１５９】
図６を参照すると、ＰＬＳ、ＥＡＣ及びＦＩＣの保護のためのＢＩＣＭブロックは、ＰＬＳ  ＦＥＣエンコーダー６０００、ビットインターリーバー６０１０、星状マッパー６０２０及び時間インターリーバー６０３０を含むことができる。
【０１６０】
また、ＰＬＳ  ＦＥＣエンコーダー６０００は、スクランブラー、ＢＣＨエンコーディング／ゼロ挿入ブロック、ＬＤＰＣエンコーディングブロック及びＬＤＰＣパリティパンクチャリングブロックを含むことができる。以下では、ＢＩＣＭブロックの各ブロックを説明する。
【０１６１】
ＰＬＳ  ＦＥＣエンコーダー６０００は、スクランブリングされたＰＬＳ  １／２データ、ＥＡＣ及びＦＩＣセクションをエンコーディングすることができる。
【０１６２】
スクランブラーは、ＢＣＨエンコーディング、短縮及びパンクチャリングされたＬＤＰＣエンコーディング前にＰＬＳ１データ及びＰＬＳ２データをスクランブリングすることができる。
【０１６３】
ＢＣＨエンコーディング／ゼロ挿入ブロックは、ＰＬＳ保護のための短縮されたＢＣＨコードを用いてスクランブリングされたＰＬＳ  １／２データに対して外部エンコーディングを行い、ＢＣＨエンコーディング後にゼロビットを挿入することができる。ＰＬＳ１データのみのために、ＬＤＰＣエンコーディング前にゼロ挿入の出力ビットがパーミュティング（ｐｅｒｍｕｔｅ）され得る。
【０１６４】
ＬＤＰＣエンコーディングブロックは、ＬＤＰＣコードを用いてＢＣＨエンコーディング／ゼロ挿入ブロックの出力をエンコーディングすることができる。完全なコーディングブロック（Ｃldpc）を生成するために、パリティビット（Ｐldpc）は、ゼロ挿入されたＰＬＳ情報ブロック（Ｉldpc）から体系的にエンコーディングされ、その後に添付される。
【０１６５】
【数１】
0006348184.tif 000005
【０１６６】
ＰＬＳ１及びＰＬＳ２に対するＬＤＰＣコードパラメーターは、表４の通りである。
【０１６７】
【表４】
0006348184.tif 000006
【０１６８】
ＬＤＰＣパリティパンクチャリングブロックは、ＰＬＳ１データ及びＰＬＳ２データに対してパンクチャリングを行うことができる。
【０１６９】
ＰＬＳ１データ保護に短縮が適用されると、ＬＤＰＣエンコーディング後に一部のＬＤＰＣパリティビットがパンクチャリングされる。また、ＰＬＳ２データの保護のために、ＬＤＰＣエンコーディング後にＰＬＳ２のＬＤＰＣパリティビットがパンクチャリングされる。これらパンクチャリングされたビットは送信されない。
【０１７０】
ビットインターリーバー６０１０は、それぞれ短縮及びパンクチャリングされたＰＬＳ１データ及びＰＬＳ２データをインターリービングすることができる。
【０１７１】
星状マッパー６０２０は、ビットインターリービングされたＰＬＳ１データ及びＰＬＳ２データを星状にマッピングすることができる。
【０１７２】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１７３】
図７は、本発明の一実施例に係るフレーム形成ブロックを示す図である。
【０１７４】
図７に示したフレーム形成ブロックは、図１を参照して説明したフレーム形成ブロック１０２０の実施例に対応する。
【０１７５】
図７を参照すると、フレーム形成ブロックは、遅延補償ブロック７０００、セルマッパー７０１０及び周波数インターリーバー７０２０を含むことができる。以下では、フレーム形成ブロックのそれぞれのブロックを説明する。
【０１７６】
遅延補償ブロック７０００は、データパイプと対応するＰＬＳデータとの間のタイミングを調節し、送信端で同一の時間にあるように（ｃｏ―ｔｉｍｅｄ）保障することができる。ＰＬＳデータは、入力フォーマッティングブロック及びＢＩＣＭブロックによって誘発されたデータパイプの遅延を処理することによって、データパイプと同一の量だけ遅延される。ＢＩＣＭブロックの遅延は、主に時間インターリーバー５０５０のためである。インバンドシグナリングデータは、次のＴＩグループの情報を伝達し、シグナリングされるＤＰより一つのフレームの前で伝達され得る。よって、遅延補償ブロックは、インバンドシグナリングデータを遅延させる。
【０１７７】
セルマッパー７０１０は、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルをフレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングすることができる。セルマッパー７０１０の基本機能は、もしあれば、ＤＰ、ＰＬＳセル及びＥＡＣ／ＦＩＣセルのそれぞれに対してＴＩによって生成されたデータセルをフレーム内のＯＦＤＭシンボルのそれぞれに対応するアクティブＯＦＤＭセルのアレイにマッピングすることである。サービスシグナリングデータ（ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＳＩなど）は、個別的に収集され、データパイプによって伝送され得る。セルマッパーは、スケジューラーによって生成された動的情報及びフレーム構造の設定によって動作する。フレームの細部事項については後で説明する。
【０１７８】
周波数インターリーバー７０２０は、セルマッパー７０１０から受信されたデータセルをランダムにインターリービングし、周波数ダイバーシティを提供する。また、周波数インターリーバー７０２０は、異なるインターリービングシード（ｓｅｅｄ）順序を用いて２個の順次的なＯＦＤＭシンボルで構成されるＯＦＤＭシンボルペアに対して動作し、単一フレームで最大のインターリービング利得を得ることができる。周波数インターリーバー７０２０の動作の細部事項については後で説明する。
【０１７９】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１８０】
図８は、本発明の実施例に係るＯＦＤＭ生成ブロックを示す図である。
【０１８１】
図８に示したＯＦＤＭ生成ブロックは、図１を参照して説明したＯＦＤＭ生成ブロック１０３０の実施例に対応する。
【０１８２】
ＯＦＤＭ生成ブロックは、フレーム形成ブロックによって生成されたセルによってＯＦＤＭキャリアを変調し、パイロットを挿入し、送信される時間ドメイン信号を生成する。また、このブロックは、後続に保護区間を挿入し、ＰＡＰＲ低減処理を適用して最終ＲＦ信号を生成する。
【０１８３】
図８を参照すると、フレーム形成ブロックは、パイロット及び予約トーン挿入ブロック８０００、２Ｄ―ｅＳＦＮエンコーディングブロック８０１０、ＩＦＦＴ（ｉｎｖｅｒｓｅ  ｆａｓｔ  Ｆｏｕｒｉｅｒ  ｔｒａｎｓｆｏｒｍ）ブロック８０２０、ＰＡＰＲ低減ブロック８０３０、保護区間挿入ブロック８０４０、プリアンブル挿入ブロック８０５０、他のシステム挿入ブロック８０６０及びＤＡＣブロック８０７０を含むことができる。以下では、フレーム形成ブロックのそれぞれのブロックを説明する。
【０１８４】
パイロット及び予約トーン挿入ブロック８０００は、パイロット及び予約トーンを挿入することができる。
【０１８５】
ＯＦＤＭシンボル内の多様なセルは、パイロットとして知られた基準情報で変調され、これは、受信機で先験的に知られた値を送信する。パイロットセルの情報は、分散されたパイロット、継続するパイロット（ｃｏｎｔｉｎｕａｌ  ｐｉｌｏｔ）、エッジパイロット、ＦＳＳ（ｆｒａｍｅ  ｓｉｇｎａｌｉｎｇ  ｓｙｍｂｏｌ）パイロット及びＦＥＳ（ｆｒａｍｅ  ｅｄｇｅ  ｓｙｍｂｏｌ）パイロットで構成される。それぞれのパイロットは、パイロットタイプ及びパイロットパターンによって特定の上昇パワーレベルで送信される。パイロット情報の値は、一連の値である基準シーケンスから派生され、これは、任意の与えられたシンボル上の送信キャリアに対するものである。パイロットは、フレーム同期化、周波数同期化、時間同期化、チャンネル推定及び送信モード識別に使用することができ、また、位相雑音に従うのに使用することができる。
【０１８６】
基準シーケンスから取得された基準情報は、フレームのプリアンブル、ＦＳＳ及びＦＥＳを除いた全てのシンボルで分散されたパイロットセルで送信される。継続するパイロットは、フレームの全てのシンボルで挿入される。継続するパイロットの数と位置は、ＦＦＴサイズ及び分散されたパイロットパターンに依存する。エッジキャリアは、プリアンブルシンボルを除いた全てのシンボル内のエッジパイロットである。これらは、スペクトルのエッジまで周波数補間を許容するために挿入される。ＦＳＳパイロットがＦＳＳに挿入され、ＦＥＳパイロットがＦＥＳに挿入される。これらは、フレームのエッジまで時間補間を許容するために挿入される。
【０１８７】
本発明の実施例に係るシステムは、ＳＦＮネットワークをサポートし、分散型ＭＩＳＯ方式は、選択的に非常にロバストな送信モードをサポートするのに使用される。２Ｄ―ｅＳＦＮは、多数のＴＸアンテナを用いる分散型ＭＩＳＯ方式であって、それぞれのＴＸアンテナはＳＦＮネットワークで異なる送信側に位置する。
【０１８８】
２Ｄ―ｅＳＦＮエンコーディングブロック８０１０は、ＳＦＮ構成で時間及び周波数ダイバーシティを生成するために２Ｄ―ｅＳＦＮ処理を行い、多数の送信機から送信された信号の位相を歪曲することができる。そのため、長い時間の間の低いフラットフェーディングまたは深いフェーディングによるバーストエラーを緩和することができる。
【０１８９】
ＩＦＦＴブロック８０２０は、ＯＦＤＭ変調方式を用いて２Ｄ―ｅＳＦＮエンコーディングブロック８０１０からの出力を変調することができる。パイロットとして（または予約トーンとして）指定されていないデータシンボル内の任意のセルは、周波数インターリーバーからのデータセルのうち一つを伝達する。セルはＯＦＤＭキャリアにマッピングされる。
【０１９０】
ＰＡＰＲ低減ブロック８０３０は、時間ドメインで多様なＰＡＰＲ低減アルゴリズムを用いて入力信号に対してＰＡＰＲ低減を行うことができる。
【０１９１】
保護区間挿入ブロック８０４０は保護区間を挿入し、プリアンブル挿入ブロック８０５０は信号の前にプリアンブルを挿入することができる。プリアンブルの構造の細部事項については後で説明する。他のシステム挿入ブロック８０６０は、時間ドメインで複数の放送送受信システムの信号をマルチプレキシングし、放送サービスを提供する２個以上の異なる放送送受信システムのデータが同一のＲＦ信号帯域幅で同時に送信され得る。この場合、２個以上の異なる放送送受信システムは、異なる放送サービスを提供するシステムを称する。異なる放送サービスは、地上波放送サービス、モバイル放送サービスなどを称する。それぞれの放送サービスと関連するデータは、異なるフレームを通じて送信され得る。
【０１９２】
ＤＡＣブロック８０７０は、入力デジタル信号をアナログ信号に変換し、アナログ信号を出力することができる。ＤＡＣブロック８０７０から出力された信号は、物理層プロファイルによって多数の出力アンテナを介して送信され得る。本発明の実施例に係るＴＸアンテナは、垂直または水平極性を有することができる。
【０１９３】
上述したブロックは、省略したり、類似または同一の機能を有するブロックに取り替えることができる。
【０１９４】
図９は、本発明の実施例に係る未来の放送サービスのための放送信号を受信する装置の構造を示す図である。
【０１９５】
本発明の実施例に係る未来の放送サービスのための放送信号を受信する装置は、図１を参照して説明した未来の放送サービスのために放送信号を送信する装置に対応し得る。
【０１９６】
本発明の実施例に係る未来の放送サービスのための放送信号を受信する装置は、同期化及び復調モジュール９０００、フレームパーシングモジュール９０１０、デマッピング及びデコーディングモジュール９０２０、出力プロセッサ９０３０及びシグナリングデコーディングモジュール９０４０を含むことができる。以下では、放送信号を受信する装置のそれぞれのモジュールの動作を説明する。
【０１９７】
同期化及び復調モジュール９０００は、ｍ個のＲｘアンテナを介して入力信号を受信し、放送信号を受信する装置に対応するシステムに対して信号検出及び同期化を行い、放送信号を送信する装置によって行われる手順の逆手順に対応する復調を行うことができる。
【０１９８】
フレームパーシングモジュール９１００は、入力信号フレームをパーシングし、ユーザーによって選択されたサービスが送信されるデータを抽出することができる。放送信号を送信する装置がインターリービングを行うと、フレームパーシングモジュール９１００は、インターリービングの逆手順に対応する逆インターリービングを行うことができる。この場合、抽出される必要がある信号及びデータの位置は、シグナリングデコーディングモジュール９４００から出力されたデータをデコーディングし、放送信号を送信する装置によって生成されたシグナリング情報を回復することによって得ることができる。
【０１９９】
デマッピング及びデコーディングモジュール９２００は、入力信号をビットドメインデータに変換した後、必要に応じてデインターリービングを行うことができる。デマッピング及びデコーディングモジュール９２００は、送信効率のために適用されたマッピングのためにデマッピングを行い、デコーディングを通じて送信チャンネルに対して生成されるエラーを訂正することができる。この場合、デマッピング及びデコーディングモジュール９２００は、シグナリングデコーディングモジュール９４００から出力されたデータをデコーディングすることによって、デマッピング及びデコーディングに必要な送信パラメーターを得ることができる。
【０２００】
出力プロセッサ９３００は、放送信号を送信する装置によって適用された多様な圧縮／信号処理手順の逆手順を行い、送信効率を改善することができる。この場合、出力プロセッサ９３００は、シグナリングデコーディングモジュール９４００から出力されたデータから必要な制御情報を得ることができる。出力プロセッサ８３００の出力は、放送信号を送信する装置に入力される信号に対応し、ＭＰＥＧ―ＴＳ、ＩＰストリーム（ｖ４またはｖ６）及び一般ストリームであり得る。
【０２０１】
シグナリングデコーディングモジュール９４００は、同期化及び復調モジュール９０００によって復調された信号からＰＬＳ情報を得ることができる。上述したように、フレームパーシングモジュール９１００、デマッピング及びデコーディングモジュール９２００及び出力プロセッサ９３００は、シグナリングデコーディングモジュール９４００から出力されたデータを用いてその機能を実行することができる。
【０２０２】
図１０は、本発明の実施例に係るフレーム構造を示す図である。
【０２０３】
図１０は、スーパーフレーム内のフレームタイプ及びＦＲＵの例示的な構成を示す。（ａ）は、本発明の実施例に係るスーパーフレームを示し、（ｂ）は、本発明の実施例に係るＦＲＵ（ｆｒａｍｅ  ｒｅｐｅｔｉｔｉｏｎ  ｕｎｉｔ）を示し、（ｃ）は、ＦＲＵ内の可変ＰＨＹプロファイルのフレームを示し、（ｄ）はフレームの構造を示す。
【０２０４】
スーパーフレームは８個のＦＲＵで構成することができる。ＦＲＵは、フレームのＴＤＭのための基本マルチプレキシング単位であって、スーパーフレーム内で８回繰り返される。
【０２０５】
ＦＲＵ内のそれぞれのフレームは、ＰＨＹプロファイル（ベース、ハンドヘルド、アドバンスド）のうち一つまたはＦＥＦに属する。ＦＲＵ内のフレームの最大許容数は４であり、与えられたＰＨＹプロファイルは、ＦＲＵで０番から４番までの任意の回数だけ表れ得る（例えば、ベース、ハンドヘルド、アドバンスド）。ＰＨＹプロファイルの定義は、必要であれば、プリアンブルでＰＨＹ＿ＰＲＯＦＩＬＥの留保値を用いて拡張することができる。
【０２０６】
ＦＥＦ部分は、含まれるならば、ＦＲＵの端に挿入される。ＦＥＦがＦＲＵに含まれるとき、スーパーフレームでＦＥＦの最小数は８である。ＦＥＦ部分が互いに隣接することは推薦しない。
【０２０７】
一つのフレームは、多数のＯＦＤＭシンボル及びプリアンブルにさらに分離される。（ｄ）に示したように、フレームは、プリアンブル、一つ以上のフレームシグナリングシンボル（ＦＳＳ）、ノーマルデータシンボル及びフレームエッジシンボル（ＦＥＳ）を含む。
【０２０８】
プリアンブルは、速いフューチャーキャストＵＴＢシステム信号の検出が可能であり、信号の効率的な送受信のための基本送信パラメーターのセットを提供する特殊シンボルである。プリアンブルについては後で詳細に説明する。
【０２０９】
ＦＳＳの主要目的はＰＬＳデータを伝達することにある。速い同期化及びチャンネル推定、及びＰＬＳデータの速いデコーディングのために、ＦＳＳは、ノーマルデータシンボルより密集したパイロットパターンを有する。ＦＥＳは、正確にＦＳＳと同一のパイロットを有するが、これは、ＦＥＳに先行するシンボルに対して外挿せず、ＦＥＳ及び時間補間内で周波数のみの補間を可能にする。
【０２１０】
図１１は、本発明の実施例に係るフレームのシグナリング層構造を示す図である。
【０２１１】
図１１は、３個の主要部分、すなわち、プリアンブルシグナリングデータ１１０００、ＰＬＳ１データ１１０１０及びＰＬＳ２データ１１０２０に分離されたシグナリング層構造を示す。全てのフレームでプリアンブルシンボルによって伝達されるプリアンブルの目的は、そのフレームの送信タイプ及び基本送信パラメーターを指示することにある。ＰＬＳ１は、受信機がＰＬＳ２データをアクセス及びデコーディングするようにし、これは、関心のあるＤＰをアクセスするパラメーターを含む。ＰＬＳ２は、全てのフレームで伝達され、２個の主要部分、すなわち、ＰＬＳ２―ＳＴＡＴデータ及びＰＬＳ２―ＤＹＮデータに分離される。ＰＬＳ２データの静的及び動的部分には、必要であればパディングが後に来る。
【０２１２】
図１２は、本発明の実施例に係るプリアンブルシグナリングデータを示す図である。
【０２１３】
プリアンブルシグナリングデータは、受信機がＰＬＳデータをアクセスし、フレーム構造内のＤＰをトレースさせるのに必要な２１ビットの情報を伝達する。プリアンブルシグナリングデータの細部事項は次の通りである。
【０２１４】
ＰＨＹ＿ＰＲＯＦＩＬＥ：この３ビットフィールドは、現在のフレームのＰＨＹプロファイルタイプを示す。異なるＰＨＹプロファイルタイプのマッピングは、以下の表５に記載される。
【０２１５】
【表５】
0006348184.tif 000007
【０２１６】
ＦＦＴ＿ＳＩＺＥ：この２ビットフィールドは、以下の表６に記載したように、フレームグループ内の現在のフレームのＦＦＴサイズを示す。
【０２１７】
【表６】
0006348184.tif 000008
【０２１８】
ＧＩ＿ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、以下の表７に記載したように、現在のスーパーフレーム内の保護区間分数（ｆｒａｃｔｉｏｎ）値を示す。
【０２１９】
【表７】
0006348184.tif 000009
【０２２０】
ＥＡＣ＿ＦＬＡＧ：この１ビットフィールドは、ＥＡＣが現在のフレームで提供されるか否かを示す。このフィールドが「１」に設定されると、ＥＡＳ（ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｓｅｒｖｉｃｅ）が現在のフレームで提供される。このフィールドが「０」に設定されると、ＥＡＳが現在のフレームで伝達されない。このフィールドは、スーパーフレーム内で動的に切り替えることができる。
【０２２１】
ＰＩＬＯＴ＿ＭＯＤＥ：この１ビットフィールドは、現在のフレームグループ内の現在のフレームの間、パイロットモードがモバイルモードであるか、それとも固定モードであるかを示す。このフィールドが「０」に設定されると、モバイルパイロットモードが用いられる。フィールドが「１」に設定されると、固定パイロットモードが用いられる。
【０２２２】
ＰＡＰＲ＿ＦＬＡＧ：この１ビットフィールドは、現在のフレームグループ内の現在のフレームにＰＡＰＲ低減が利用されるか否かを示す。このフィールドが「１」に設定されると、ＰＡＰＲ低減にトーン予約が用いられる。このフィールドが「０」に設定されると、ＰＡＰＲ低減が用いられない。
【０２２３】
ＦＲＵ＿ＣＯＮＦＩＧＵＲＥ：この３ビットフィールドは、現在のスーパーフレームに存在するフレーム反復単位（ＦＲＵ）のＰＨＹプロファイルタイプ構成を示す。現在のスーパーフレームで伝達される全てのプロファイルタイプは、現在のスーパーフレーム内の全てのプリアンブル内のこのフィールドで識別される。３ビットフィールドは、以下の表８に示したように、それぞれのプロファイルに対する異なる定義を有する。
【０２２４】
【表８】
0006348184.tif 000010
【０２２５】
ＲＥＳＥＲＶＥＤ：この７ビットフィールドは、未来の使用のために留保される。
【０２２６】
図１３は、本発明の実施例に係るＰＬＳ１データを示す図である。
【０２２７】
ＰＬＳ１データは、ＰＬＳ２の受信及びデコーディングを可能にするのに必要なパラメーターを含む基本送信パラメーターを提供する。上述したように、ＰＬＳ１データは、一つのフレームグループの全体のデュレーションの間に変わらない。ＰＬＳ１データのシグナリングフィールドの詳細な定義は次の通りである。
【０２２８】
ＰＲＥＡＭＢＬＥ＿ＤＡＴＡ：この２０ビットフィールドは、ＥＡＣ＿ＦＬＡＧを除いたプリアンブルシグナリングデータの写本である。
【０２２９】
ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵ：この２ビットフィールドは、ＦＲＵごとのフレームの数を示す。
【０２３０】
ＰＡＹＬＯＡＤ＿ＴＹＰＥ：この３ビットフィールドは、フレームグループで伝達されるペイロードデータのフォーマットを示す。ＰＡＹＬＯＡＤ＿ＴＹＰＥは、表９に示したようにシグナリングされる。
【０２３１】
【表９】
0006348184.tif 000011
【０２３２】
ＮＵＭ＿ＦＳＳ：この２ビットフィールドは、現在のフレーム内のＦＳＳシンボルの数を示す。
【０２３３】
ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮ：この８ビットフィールドは、送信された信号フォーマットのバージョンを示す。ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮは、メジャーバージョン及びマイナーバージョンである２個の４ビットフィールドに分離される。
【０２３４】
メジャーバージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＭＳＢ４ビットは、メジャーバージョン情報を示す。メジャーバージョンフィールドの変化は、非逆方向互換可能変化（ｎｏｎ―ｂａｃｋｗａｒｄ―ｃｏｍｐａｔｉｂｌｅ  ｃｈａｎｇｅ）を示す。デフォルト値は「００００」である。この標準に記載したバージョンに対して、値は「００００」に設定される。
【０２３５】
マイナーバージョン：ＳＹＳＴＥＭ＿ＶＥＲＳＩＯＮフィールドのＬＳＢ４ビットは、マイナーバージョン情報を示す。マイナーバージョンフィールドの変化は逆方向互換可能である。
【０２３６】
ＣＥＬＬ＿ＩＤ：これは、ＡＴＳＣネットワーク内の地理的セルを固有に識別する１６ビットフィールドである。ＡＴＳＣセルカバレッジ領域は、フューチャーキャストＵＴＢシステムごとに使用される周波数の数によって一つ以上の周波数で構成することができる。ＣＥＬＬ＿ＩＤの値が知られていないか、指定されていない場合、このフィールドは「０」に設定される。
【０２３７】
ＮＥＴＷＯＲＫ＿ＩＤ：これは、現在のＡＴＳＣネットワークを固有に識別する１６ビットフィールドである。
【０２３８】
ＳＹＳＴＥＭ＿ＩＤ：この１６ビットフィールドは、ＡＴＳＣネットワーク内のフューチャーキャストＵＴＢシステムを固有に識別する。フューチャーキャストＵＴＢシステムは、入力が一つ以上の入力ストリーム（ＴＳ、ＩＰ、ＧＳ）であって、出力がＲＦ信号である地上波放送システムである。フューチャーキャストＵＴＢシステムは、もしあれば、一つ以上のＰＨＹプロファイル及びＦＥＦを伝達する。同一のフューチャーキャストＵＴＢシステムは、異なる入力ストリームを伝達し、異なる地理的領域で異なるＲＦ周波数を用いてローカルサービス挿入を許容する。フレーム構造及びスケジューリングは、一つの位置で制御され、フューチャーキャストＵＴＢシステム内の全ての送信に対して同一である。一つ以上のフューチャーキャストＵＴＢシステムは、同一の物理層構造及び構成を有することを意味する同一のＳＹＳＴＥＭ＿ＩＤを有することができる。
【０２３９】
次のループは、各フレームタイプの長さ及びＦＲＵ構成を示すのに使用されるＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ、ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ、ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ及びＲＥＳＥＲＶＥＤで構成される。ループサイズは固定され、４個の（ＦＥＦを含む）ＰＨＹプロファイルはＦＲＵ内でシグナリングされる。ＮＵＭ＿ＦＲＡＭＥ＿ＦＲＵが４より小さいと、使用されないフィールドはゼロで充填される。
【０２４０】
ＦＲＵ＿ＰＨＹ＿ＰＲＯＦＩＬＥ：この３ビットフィールドは、連関したＦＲＵの（ｉ＋１）番目（ｉは、ループインデックスである）のフレームのＰＨＹプロファイルタイプを示す。このフィールドは、表８に示したように、同一のシグナリングフォーマットを使用する。
【０２４１】
ＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨ：この２ビットフィールドは、連関したＦＲＵの（ｉ＋１）番目のフレームの長さを示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮと共にＦＲＵ＿ＦＲＡＭＥ＿ＬＥＮＧＴＨを用いて、フレームデュレーションの正確な値を得ることができる。
【０２４２】
ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮ：この３ビットフィールドは、連関したＦＲＵの（ｉ＋１）番目のフレームの保護区間分数値を示す。ＦＲＵ＿ＧＩ＿ＦＲＡＣＴＩＯＮは、表７によってシグナリングされる。
【０２４３】
ＲＥＳＥＲＶＥＤ：この４ビットフィールドは、未来の使用のために留保される。
【０２４４】
次のフィールドは、ＰＬＳ２データをデコーディングするパラメーターを提供する。
【０２４５】
ＰＬＳ２＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、ＰＬＳ２保護によって使用されたＦＥＣタイプを示す。ＦＥＣタイプは、表１０によってシグナリングされる。ＬＤＰＣコードの細部事項については後で説明する。
【０２４６】
【表１０】
0006348184.tif 000012
【０２４７】
ＰＬＳ２＿ＭＯＤ：この３ビットフィールドは、ＰＬＳ２によって使用された変調タイプを示す。変調タイプは、表１１によってシグナリングされる。
【０２４８】
【表１１】
0006348184.tif 000013
【０２４９】
ＰＬＳ２＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、現在のフレームグループで伝達されるＰＬＳ２に対する全体（ｆｕｌｌ）コーディングブロックの集合（ｃｏｌｌｅｃｔｉｏｎ）のサイズ（ＱＡＭセルの数として特定される）Ｃtotal_partial_blockを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５０】
ＰＬＳ２＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、現在のフレームグループに対するＰＬＳ２―ＳＴＡＴのビットサイズを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５１】
ＰＬＳ２＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、現在のフレームグループに対するＰＬＳ２―ＤＹＮのビットサイズを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５２】
ＰＬＳ２＿ＲＥＰ＿ＦＬＡＧ：この１ビットフラグは、現在のフレームグループでＰＬＳ２反復モードが使用されるか否かを示す。このフィールドが値「１」に設定されると、ＰＬＳ２反復モードが活性化される。このフィールドが値「０」に設定されると、ＰＬＳ２反復モードが非活性化される。
【０２５３】
ＰＬＳ２＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２反復が使用されるとき、現在のフレームグループの全てのフレームで伝達されるＰＬＳ２に対する部分コーディングブロックの集合のサイズ（ＱＡＭセルの数として特定される）Ｃtotal_partial_blockを示す。反復が使用されない場合、このフィールドの値は０と同一である。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５４】
ＰＬＳ２＿ＮＥＸＴ＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用されるＦＥＣタイプを示す。ＦＥＣタイプは、表１０によってシグナリングされる。
【０２５５】
ＰＬＳ２＿ＮＥＸＴ＿ＭＯＤ：この３ビットフィールドは、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に使用される変調タイプを示す。変調タイプは、表１１によってシグナリングされる。
【０２５６】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＦＬＡＧ：この１ビットフィールドは、ＰＬＳ２反復モードが次のフレームグループで使用されるか否かを示す。このフィールドが値「１」に設定されると、ＰＬＳ２反復モードが活性化される。このフィールドが値「０」に設定されると、ＰＬＳ２反復モードが非活性化される。
【０２５７】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２反復が使用されるとき、次のフレームグループの全てのフレームで伝達されるＰＬＳ２に対する全体コーディングブロックの集合のサイズ（ＱＡＭセルの数として特定される）Ｃtotal_partial_blockを示す。次のフレームグループで反復が使用されない場合、このフィールドの値は０と同一である。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５８】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＳＴＡＴ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２―ＳＴＡＴのビットサイズを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２５９】
ＰＬＳ２＿ＮＥＸＴ＿ＲＥＰ＿ＤＹＮ＿ＳＩＺＥ＿ＢＩＴ：この１４ビットフィールドは、次のフレームグループに対するＰＬＳ２―ＤＹＮのビットサイズを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２６０】
ＰＬＳ２＿ＡＰ＿ＭＯＤＥ：この２ビットフィールドは、現在のフレームグループ内のＰＬＳ２に追加のパリティが提供されるか否かを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。下記の表１２は、このフィールドの値を提供する。このフィールドが「００」に設定されると、現在のフレームグループ内のＰＬＳ２に追加のパリティが使用されない。
【０２６１】
【表１２】
0006348184.tif 000014
【０２６２】
ＰＬＳ２＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、ＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２６３】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＭＯＤＥ：この２ビットフィールドは、次のフレームグループの全てのフレームでＰＬＳ２シグナリングに追加のパリティが提供されるか否かを示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。表１２は、このフィールドの値を定義する。
【０２６４】
ＰＬＳ２＿ＮＥＸＴ＿ＡＰ＿ＳＩＺＥ＿ＣＥＬＬ：この１５ビットフィールドは、次のフレームグループの全てのフレームでのＰＬＳ２の追加のパリティビットのサイズ（ＱＡＭセルの数として特定される）を示す。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２６５】
ＲＥＳＥＲＶＥＤ：この３２ビットフィールドは、未来の使用のために留保される。
【０２６６】
ＣＲＣ＿３２：全体のＰＬＳ１シグナリングに適用される３２ビットエラー検出コード
図１４は、本発明の実施例に係るＰＬＳ２データを示す図である。
【０２６７】
図１４は、ＰＬＳ２データのＰＬＳ２―ＳＴＡＴデータを示す。ＰＬＳ２―ＳＴＡＴデータは、フレームグループ内で同一であるが、ＰＬＳ２―ＤＹＮデータは現在のフレームに対して特定の情報を提供する。
【０２６８】
ＰＬＳ２―ＳＴＡＴデータのフィールドの細部事項は次の通りである。
【０２６９】
ＦＩＣ＿ＦＬＡＧ：この１ビットフィールドは、現在のフレームグループにＦＩＣが使用されるか否かを示す。このフィールドが「１」に設定されると、現在のフレームでＦＩＣが提供される。このフィールドが「０」に設定されると、現在のフレームでＦＩＣが伝達されない。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２７０】
ＡＵＸ＿ＦＬＡＧ：この１ビットフィールドは、現在のフレームグループで補助ストリームが使用されるか否かを示す。このフィールドが「１」に設定されると、補助ストリームが現在のフレームで提供される。このフィールドが「０」に設定されると、補助ストリームが現在のフレームで伝達されない。この値は、現在のフレームグループの全体のデュレーションの間に一定である。
【０２７１】
ＮＵＭ＿ＤＰ：この６ビットフィールドは、現在のフレーム内で伝達されるＤＰの数を示す。このフィールドの値は、１〜６４の範囲内にあり、ＤＰの数はＮＵＭ＿ＤＰ＋１である。
【０２７２】
ＤＰ＿ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内のＤＰを固有に識別する。
【０２７３】
ＤＰ＿ＴＹＰＥ：この３ビットフィールドはＤＰのタイプを示す。これは、以下の表１３によってシグナリングされる。
【０２７４】
【表１３】
0006348184.tif 000015
【０２７５】
ＤＰ＿ＧＲＯＵＰ＿ＩＤ：この８ビットフィールドは、現在のＤＰが連関したＤＰグループを識別する。これは、同一のＤＰ＿ＧＲＯＵＰ＿ＩＤを有する、特定サービスと連関したサービスコンポーネントのＤＰをアクセスするために受信機によって使用することができる。
【０２７６】
ＢＡＳＥ＿ＤＰ＿ＩＤ：この６ビットフィールドは、管理層で使用されるサービスシグナリングデータ（ＰＳＩ／ＳＩなど）を伝達するＤＰを示す。ＢＡＳＥ＿ＤＰ＿ＩＤによって指示されたＤＰは、サービスシグナリングデータのみを伝達する専用ＤＰまたはサービスデータと共にサービスシグナリングデータを伝達するノーマルＤＰであり得る。
【０２７７】
ＤＰ＿ＦＥＣ＿ＴＹＰＥ：この２ビットフィールドは、連関したＤＰによって使用されたＦＥＣタイプを示す。ＦＥＣタイプは、以下の表１４によってシグナリングされる。
【０２７８】
【表１４】
0006348184.tif 000016
【０２７９】
ＤＰ＿ＣＯＤ：この４ビットフィールドは、連関したＤＰによって使用されたコードレートを示す。コードレートは、以下の表１５によってシグナリングされる。
【０２８０】
【表１５】
0006348184.tif 000017
【０２８１】
ＤＰ＿ＭＯＤ：この４ビットフィールドは、連関したＤＰによって使用された変調を示す。変調は、以下の表１６によってシグナリングされる。
【０２８２】
【表１６】
0006348184.tif 000018
【０２８３】
ＤＰ＿ＳＳＤ＿ＦＬＡＧ：この１ビットフィールドは、連関したＤＰでＳＳＤモードが利用されるか否かを示す。このフィールドが値「１」に設定されると、ＳＳＤが使用される。このフィールドが値「０」に設定されると、ＳＳＤが使用されない。
【０２８４】
次のフィールドは、ＰＨＹ＿ＰＲＯＦＩＬＥがアドバンスドプロファイルを示す「０１０」と同一である場合のみに表れる。
【０２８５】
ＤＰ＿ＭＩＭＯ：この３ビットフィールドは、いずれのタイプのＭＩＭＯエンコーディングプロセスが連関したＤＰに適用されるのかを示す。ＭＩＭＯエンコーディングプロセスのタイプは、表１７によってシグナリングされる。
【０２８６】
【表１７】
0006348184.tif 000019
【０２８７】
ＤＰ＿ＴＩ＿ＴＹＰＥ：この１ビットフィールドは、時間インターリービングのタイプを示す。「０」の値は、一つのＴＩグループが一つのフレームに対応し、一つ以上のＴＩブロックを含むことを示す。「１」の値は、一つのＴＩグループが１より多いフレームで伝達され、一つのＴＩブロックのみを含むことを示す。
【０２８８】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：２ビットフィールドの使用（許容される値は１、２、４、８のみである）の使用は、次のようにＤＰ＿ＴＩ＿ＴＹＰＥフィールド内に設定された値によって決定される。
【０２８９】
ＤＰ＿ＴＩ＿ＴＹＰＥが値「１」に設定されると、このフィールドは、それぞれのＴＩグループがマッピングされたフレームの数（ＰＩ）を示し、ＴＩグループごとに一つのＴＩブロックがある（ＮＴＩ＝１）。２ビットフィールドを有する許容されたＰＩ値は、以下の表１８で定義される。
【０２９０】
ＤＰ＿ＴＩ＿ＴＹＰＥが値「０」に設定されると、このフィールドは、ＴＩグループごとのＴＩブロックの数（ＮＴＩ）を示し、フレームごとに一つのＴＩグループがある（ＰＩ＝１）。２ビットフィールドを有する許容されたＰＩ値は、以下の表１８で定義される。
【０２９１】
【表１８】
0006348184.tif 000020
【０２９２】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ：この２ビットフィールドは、連関したＤＰに対するフレームグループ内のフレーム間隔（ＩJUMP）を示し、許容される値は１、２、４、８である（該当２ビットフィールドは、それぞれ「００」、「０１」、「１０」、または「１１」である）。フレームグループの全てのフレームで表れないＤＰに対して、このフィールドの値は連続的なフレーム間の間隔と同一である。例えば、フレーム１、５、９、１３などでＤＰが表れると、このフィールドは「４」に設定される。全てのフレームで表れるＤＰに対して、このフィールドが「１」に設定される。
【０２９３】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ：この１ビットフィールドは、時間インターリーバーの利用可能性を決定する。時間インターリービングがＤＰに使用されない場合、これは「１」に設定される。その一方、時間インターリービングが使用される場合、これは「０」に設定される。
【０２９４】
ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸ：この５ビットフィールドは、現在ＤＰが発生したスーパーフレームの第１のフレームのインデックスを示す。ＤＰ＿ＦＩＲＳＴ＿ＦＲＡＭＥ＿ＩＤＸの値は０〜３１の範囲内にある。
【０２９５】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ：この１０ビットフィールドは、このＤＰに対するＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳの最大値を示す。このフィールドの値は、ＤＰ＿ＮＵＭ＿ＢＬＯＣＫＳと同一の範囲を有する。
【０２９６】
ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されるペイロードデータのタイプを示す。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥは、以下の表１９によってシグナリングされる。
【０２９７】
【表１９】
0006348184.tif 000021
【０２９８】
ＤＰ＿ＩＮＢＡＮＤ＿ＭＯＤＥ：この２ビットフィールドは、現在のＤＰがインバンドシグナリング情報を伝達するか否かを示す。インバンドシグナリングタイプは、以下の表２０によってシグナリングされる。
【０２９９】
【表２０】
0006348184.tif 000022
【０３００】
ＤＰ＿ＰＲＯＴＯＣＯＬ＿ＴＹＰＥ：この２ビットフィールドは、与えられたＤＰによって伝達されたペイロードのプロトコルタイプを示す。これは、入力ペイロードタイプが選択されるとき、以下の表２１によってシグナリングされる。
【０３０１】
【表２１】
0006348184.tif 000023
【０３０２】
ＤＰ＿ＣＲＣ＿ＭＯＤＥ：この２ビットフィールドは、ＣＲＣエンコーディングが入力フォーマッティングブロックで使用されるか否かを示す。ＣＲＣモードは、以下の表２２によってシグナリングされる。
【０３０３】
【表２２】
0006348184.tif 000024
【０３０４】
ＤＮＰ＿ＭＯＤＥ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定されるとき、連関したＤＰによって使用されたヌル―パケット削除モードを示す。ＤＮＰ＿ＭＯＤＥは、以下の表２３によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でない場合、ＤＮＰ＿ＭＯＤＥは値「００」に設定される。
【０３０５】
【表２３】
0006348184.tif 000025
【０３０６】
ＩＳＳＹ＿ＭＯＤＥ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定されるとき、連関したＤＰによって使用されたＩＳＳＹモードを示す。ＩＳＳＹ＿ＭＯＤＥは、以下の表２４によってシグナリングされる。ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）でない場合、ＩＳＳＹ＿ＭＯＤＥは値「００」に設定される。
【０３０７】
【表２４】
0006348184.tif 000026
【０３０８】
ＨＣ＿ＭＯＤＥ＿ＴＳ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定されるとき、連関したＤＰによって使用されるＴＳヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤ＿ＴＳは、以下の表２５によってシグナリングされる。
【０３０９】
【表２５】
0006348184.tif 000027
【０３１０】
ＨＣ＿ＭＯＤＥ＿ＩＰ：この２ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＩＰ（「０１」）に設定されるときのＩＰヘッダー圧縮モードを示す。ＨＣ＿ＭＯＤＥ＿ＩＰは、以下の表２６によってシグナリングされる。
【０３１１】
【表２６】
0006348184.tif 000028
【０３１２】
ＰＩＤ：この１３ビットフィールドは、ＤＰ＿ＰＡＹＬＯＡＤ＿ＴＹＰＥがＴＳ（「００」）に設定され、ＨＣ＿ＭＯＤＥ＿ＴＳが「０１」または「１０」に設定されるときのＴＳヘッダー圧縮のためのＰＩＤ番号を示す。
【０３１３】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために留保される。
【０３１４】
次のフィールドは、ＦＩＣ＿ＦＬＡＧが「１」と同一である場合のみに表れる。
【０３１５】
ＦＩＣ＿ＶＥＲＳＩＯＮ：この８ビットフィールドは、ＦＩＣのバージョン番号を示す。
【０３１６】
ＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：この１３ビットフィールドは、ＦＩＣのバイト長さを示す。
【０３１７】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために留保される。
【０３１８】
次のフィールドは、ＡＵＸ＿ＦＬＡＧが「１」と同一である場合のみに表れる。
【０３１９】
ＮＵＭ＿ＡＵＸ：この４ビットフィールドは、補助ストリームの数を示す。ゼロは、補助ストリームが使用されないことを意味する。
【０３２０】
ＡＵＸ＿ＣＯＮＦＩＧ＿ＲＦＵ：この８ビットフィールドは、未来の使用のために留保される。
【０３２１】
ＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥ：この４ビットフィールドは、現在の補助ストリームのタイプを示すための未来の使用のために留保される。
【０３２２】
ＵＸ＿ＰＲＩＶＡＴＥ＿ＣＯＮＦＩＧ：この２８ビットフィールドは、補助ストリームをシグナリングするための未来の使用のために留保される。
【０３２３】
図１５は、本発明の他の実施例に係るＰＬＳ２データを示す図である。
【０３２４】
図１５は、ＰＬＳ２データのＰＬＳ２―ＤＹＮデータを示す。ＰＬＳ２―ＤＹＮデータの値は、一つのフレームグループのデュレーションの間に変わり得るが、フィールドのサイズは一定である。
【０３２５】
ＰＬＳ２―ＤＹＮデータのフィールドの細部事項は次の通りである。
【０３２６】
ＦＲＡＭＥ＿ＩＮＤＥＸ：この５ビットフィールドは、スーパーフレーム内の現在のフレームのフレームインデックスを示す。スーパーフレームの第１のフレームのインデックスは「０」に設定される。
【０３２７】
ＰＬＳ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成が変更される位置の前のスーパーフレームの数を示す。構成において、変化する次のスーパーフレームは、このフィールド内でシグナリングされる値によって指示される。このフィールドが値「００００」に設定されると、これは、スケジューリングされた変化が予想されないことを意味し、例えば、値「１」は、次のスーパーフレームで変化があることを意味する。
【０３２８】
ＦＩＣ＿ＣＨＡＮＧＥ＿ＣＯＵＮＴＥＲ：この４ビットフィールドは、構成（すなわち、ＦＩＣのコンテンツ）が変更される位置の前のスーパーフレームの数を示す。構成において、変化する次のスーパーフレームは、このフィールド内でシグナリングされた値によって指示される。このフィールドが値「００００」に設定されると、これは、スケジューリングされた変化が予想されないことを意味し、例えば、値「０００１」は、次のスーパーフレームで変化があることを意味する。
【０３２９】
ＲＥＳＥＲＶＥＤ：この１６ビットフィールドは、未来の使用のために留保される。
【０３３０】
次のフィールドはＮＵＭ＿ＤＰ以上のループで表れ、現在のフレームで伝達されるＤＰと連関したパラメーターを記述する。
【０３３１】
ＤＰ＿ＩＤ：この６ビットフィールドは、ＰＨＹプロファイル内のＤＰを固有に示す。
【０３３２】
ＤＰ＿ＳＴＡＲＴ：この１５ビット（または１３ビット）フィールドは、ＤＰＵアドレッシング方式を用いて１番目のＤＰの開始位置を示す。ＤＰ＿ＳＴＡＲＴフィールドは、以下の表２７に示したように、ＰＨＹプロファイル及びＦＦＴサイズによって異なる長さを有する。
【０３３３】
【表２７】
0006348184.tif 000029
【０３３４】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ：この１０ビットフィールドは、現在のＤＰに対する現在のＴＩグループ内のＦＥＣブロックの数を示す。ＤＰ＿ＮＵＭ＿ＢＬＯＣＫの値の範囲は０〜１０２３である。
【０３３５】
ＲＥＳＥＲＶＥＤ：この８ビットフィールドは、未来の使用のために留保される。
【０３３６】
次のフィールドは、ＥＡＣと連関したＦＩＣパラメーターを示す。
【０３３７】
ＥＡＣ＿ＦＬＡＧ：この１ビットフィールドは、現在のフレームでのＥＡＣの存在を示す。このビットは、プリアンブル内のＥＡＣ＿ＦＬＡＧと同一の値である。
【０３３８】
ＥＡＳ＿ＷＡＫＥ＿ＵＰ＿ＶＥＲＳＩＯＮ＿ＮＵＭ：この８ビットフィールドは、ウェイクアップ指示のバージョン番号を示す。
【０３３９】
ＥＡＣ＿ＦＬＡＧフィールドが「１」と同一である場合、ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥフィールドのために次の１２ビットが割り当てられる。ＥＡＣ＿ＦＬＡＧフィールドが「０」と同一である場合、ＥＡＣ＿ＣＯＵＮＴＥＲのために次の１２ビットが割り当てられる。
【０３４０】
ＥＡＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥ：この１２ビットフィールドは、ＥＡＣのバイト長さを示す。
【０３４１】
ＥＡＣ＿ＣＯＵＮＴＥＲ：この１２ビットフィールドは、ＥＡＣが到逹するフレーム前のフレームの数を示す。
【０３４２】
ＡＵＸ＿ＦＬＡＧフィールドが「１」と同一である場合にのみ次のフィールドが表れる。
【０３４３】
ＡＵＸ＿ＰＲＩＶＡＴＥ＿ＤＹＮ：この４８ビットフィールドは、補助ストリームをシグナリングするための未来使用のために留保される。このフィールドの意味は、設定可能なＰＬＳ２―ＳＴＡＴ内のＡＵＸ＿ＳＴＲＥＡＭ＿ＴＹＰＥの値に依存する。
【０３４４】
ＣＲＣ＿３２：全体のＰＬＳ２に適用される３２ビットエラー検出コード
図１６は、本発明の実施例に係るフレームの論理構造を示す図である。
【０３４５】
上述したように、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーセルは、フレーム内のＯＦＤＭシンボルのアクティブキャリアにマッピングされる。ＰＬＳ１及びＰＬＳ２は、まず、一つ以上のＦＳＳにマッピングされる。その後、もしあれば、ＥＡＣセルがＰＬＳフィールドの直後にマッピングされ、その後、もしあれば、ＦＩＣセルがマッピングされる。もしあれば、ＰＬＳ、ＥＡＣ、ＦＩＣの後にＤＰがマッピングされる。まず、タイプ１  ＤＰが後に来た後、タイプ２  ＤＰが後に来る。ＤＰのタイプの細部事項については後で説明する。任意の場合、ＤＰは、ＥＡＳに対する任意の特殊データまたはサービスシグナリングデータを伝達する。もしあれば、補助ストリームまたは各ストリームがＤＰの後に来た後、ダミーセルが後に来る。上述した順序、すなわち、ＰＬＳ、ＥＡＣ、ＦＩＣ、ＤＰ、補助ストリーム及びダミーデータセルの順に全てマッピングし、フレーム内のセル容量を正確に充填する。
【０３４６】
図１７は、本発明の実施例に係るＰＬＳマッピングを示す図である。
【０３４７】
ＰＬＳセルは、ＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳによって占有されるセルの数によって、一つ以上のシンボルがＦＳＳとして指定され、ＦＳＳの数（ＮFSS）は、ＰＬＳ１内のＮＵＭ＿ＦＳＳによってシグナリングされる。ＦＳＳは、ＰＬＳセルを伝達する特殊シンボルである。ロバスト性及びレイテンシー（ｌａｔｅｎｃｙ）がＰＬＳで重要な問題であるので、ＦＳＳは、ＦＳＳ内で速い同期化及び周波数専用補間を許容するより高い密度のパイロットを有する。
【０３４８】
ＰＬＳセルは、図１７の例に示したように、トップ―ダウン（ｔｏｐ―ｄｏｗｎ）方式でＮFSS個のＦＳＳのアクティブキャリアにマッピングされる。ＰＬＳ１セルは、セルインデックスの増加順に第１のＦＳＳの第１のセルから先にマッピングされる。ＰＬＳ１の最後のセルの直後にＰＬＳ２セルが来て、マッピングは、第１のＦＳＳの最後のセルインデックスまで下向きに継続される。要求されるＰＬＳセルの総数が一つのＦＳＳのアクティブキャリアの数を超えると、マッピングは、次のＦＳＳに進行し、第１のＦＳＳと正確に同一の方式で継続される。
【０３４９】
ＰＬＳマッピングの完了後、ＤＰが次に伝達される。ＥＡＣ、ＦＩＣまたはＥＡＣ及びＦＩＣの両方が現在のフレームに存在すると、これらはＰＬＳと「ノーマル」ＤＰとの間に配置される。
【０３５０】
図１８は、本発明の実施例に係るＥＡＣマッピングを示す図である。
【０３５１】
ＥＡＣは、ＥＡＳに対するＤＰへのリンク及びＥＡＳメッセージを伝達する専用チャンネルである。ＥＡＳサポートが提供されるが、ＥＡＣ自体は全てのフレームに存在することもあり、存在しないこともある。もしあれば、ＥＡＣはＰＬＳ２セルの直後にマッピングされる。ＰＬＳセル以外のＦＩＣ、ＤＰ、補助ストリーム及びダミーセルのうちいずれもＥＡＣに先行しない。ＥＡＣセルをマッピングする手順は、ＰＬＳのマッピング手順と正確に同一である。
【０３５２】
ＥＡＣセルは、図１８の例に示したように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＥＡＳメッセージサイズによって、ＥＡＣセルは、図１８に示したように数個のシンボルを占有することができる。
【０３５３】
ＥＡＣセルは、ＰＬＳ２の最後のセルの直後に来て、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに継続される。要求されるＥＡＣセルの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは次のシンボルに進行し、ＦＳＳと正確に同一の方式で継続される。この場合、マッピングされる次のシンボルはノーマルデータシンボルであって、これは、ＦＳＳより多くのアクティブキャリアを有する。
【０３５４】
ＥＡＣマッピングの完了後、もし存在すれば、ＦＩＣが次に伝達される。（ＰＬＳ２フィールドでシグナリングされるように）ＦＩＣが送信されないと、ＤＰはＥＡＣの最後のセルの直後に来る。
【０３５５】
図１９は、本発明の実施例に係るＦＩＣマッピングを示す図である。
【０３５６】
（ａ）は、ＥＡＣがないＦＩＣセルの例示的なマッピングを示し、（ｂ）は、ＥＡＣがあるＦＩＣセルの例示的なマッピングを示す。
【０３５７】
ＦＩＣは、速いサービス獲得及びチャンネルスキャニングを可能にする交差階層（ｃｒｏｓｓ―ｌａｙｅｒ）情報を伝達する専用チャンネルである。この情報は、主に各放送社のＤＰとサービスとの間のチャンネル結合情報を含む。速いスキャンのために、受信機は、ＦＩＣをデコーディングし、放送社ＩＤ、サービスの数及びＢＡＳＥ＿ＤＰ＿ＩＤなどの情報を得ることができる。速いサービス獲得のために、ＦＩＣに加えて、ベースＤＰがＢＡＳＥ＿ＤＰ＿ＩＤを用いてデコーディングされ得る。それが伝達するコンテンツ以外に、ベースＤＰは、ノーマルＤＰと正確に同一の方式でエンコーディングされ、フレームにマッピングされる。そのため、ベースＤＰに追加の説明が要求されない。ＦＩＣデータが管理層で生成されて消費される。ＦＩＣデータのコンテンツは、管理層の明細書に記載した通りである。
【０３５８】
ＦＩＣデータは選択的であり、ＦＩＣの使用は、ＰＬＳ２の静的部分のＦＩＣ＿ＦＬＡＧパラメーターによってシグナリングされる。ＦＩＣが使用されると、ＦＩＣ＿ＦＬＡＧが「１」に設定され、ＦＩＣのためのシグナリングフィールドはＰＬＳ２の静的部分で定義される。このフィールドでは、ＦＩＣ＿ＶＥＲＳＩＯＮ及びＦＩＣ＿ＬＥＮＧＴＨ＿ＢＹＴＥがシグナリングされる。ＦＩＣは、ＰＬＳ２と同一の変調、コーディング及び時間インターリービングパラメーターを使用する。ＦＩＣは、ＰＬＳ２＿ＭＯＤＥ及びＰＬＳ２＿ＦＥＣなどの同一のシグナリングパラメーターを共有する。もしあれば、ＦＩＣデータは、ＰＬＳ２または、もしあれば、ＥＡＣの直後にマッピングされる。任意のノーマルＤＰ、補助ストリームまたはダミーセルがＦＩＦに先行しない。ＦＩＣセルをマッピングする方法はＥＡＣのマッピング方法と正確に同一であり、これはＰＬＳと同一である。
【０３５９】
ＰＬＳの後にＥＡＣがなく、ＦＩＣセルは、（ａ）の例に示したように、セルインデックスの増加順にＰＬＳ２の次のセルからマッピングされる。ＦＩＣデータサイズによって、ＦＩＣセルは、（ｂ）に示したように、数個のシンボル上にマッピングされる。
【０３６０】
ＦＩＣセルは、ＰＬＳ２の最後のセルの直後に来て、マッピングは、最後のＦＳＳの最後のセルインデックスまで下向きに継続される。要求されるＦＩＣセルの総数が最後のＦＳＳの残りのアクティブキャリアの数を超えると、マッピングは次のシンボルに進行し、ＦＳＳと正確に同一の方式で継続される。この場合、マッピングされる次のシンボルは、ＦＳＳより多くのアクティブキャリアを有するノーマルデータシンボルである。
【０３６１】
ＥＡＳメッセージが現在のフレームで送信されると、ＥＡＣはＦＩＣに先行し、ＦＩＣセルは、（ｂ）に示したように、セルインデックスの増加順にＥＡＣの次のセルからマッピングされる。
【０３６２】
ＦＩＣマッピングの完了後、一つ以上のＤＰがマッピングされ、その後、もしあれば、補助ストリーム及びダミーセルがマッピングされる。
【０３６３】
図２０は、本発明の実施例に係るＤＰのタイプを示す図である。
【０３６４】
（ａ）はタイプ１  ＤＰを示し、（ｂ）はタイプ２  ＤＰを示す。
【０３６５】
先行チャンネル、すなわち、ＰＬＳ、ＥＡＣ及びＦＩＣがマッピングされた後、ＤＰのセルがマッピングされる。ＤＰは、マッピング方法によって２個のタイプのうち一つに分類される。
【０３６６】
タイプ１  ＤＰ：ＤＰがＴＤＭによってマッピングされる。
【０３６７】
タイプ２  ＤＰ：ＤＰがＦＤＭによってマッピングされる。
【０３６８】
ＤＰのタイプは、ＰＬＳ２の静的部分のＤＰ＿ＴＹＰＥフィールドによって指示される。図２０は、タイプ１  ＤＰ及びタイプ２  ＤＰのマッピング順序を示す。タイプ１  ＤＰは、まず、セルインデックスの増加順にマッピングされ、最後のセルインデックスに到逹した後、シンボルインデックスが１ずつ増加する。次のシルボル内で、ＤＰは、ｐ＝０から開始し、セルインデックスの増加順に継続してマッピングされる。一つのフレーム内で共にマッピングされる多数のＤＰに対して、タイプ１  ＤＰのそれぞれは、ＤＰのＴＤＭマルチプレキシングと類似する形に時間でグループ化される。
【０３６９】
タイプ２  ＤＰは、まず、シンボルインデックスの増加順にマッピングされ、フレームの最後のＯＦＤＭシンボルに到逹した後、セルインデックスが１ずつ増加し、シンボルインデックスが利用可能な第１のシンボルに戻り、そのシンボルインデックスから増加する。一つのフレーム内で多数のＤＰを共にマッピングした後、タイプ２  ＤＰのそれぞれは、ＤＰのＦＤＭマルチプレキシングと類似する形に周波数で共にグループ化される。
【０３７０】
タイプ１  ＤＰ及びタイプ２  ＤＰは、一つの制限が充足されると、すなわち、タイプ１  ＤＰが常にタイプ２  ＤＰに先行するとフレームで共存し得る。タイプ１及びタイプ２  ＤＰを伝達するＯＦＤＭセルの総数は、ＤＰの送信のために利用可能なＯＦＤＭセルの総数を超えることができない。
【０３７１】
【数２】
0006348184.tif 000030
【０３７２】
ここで、ＤDP1は、タイプ１  ＤＰによって占有されたＯＦＤＭセルの数であり、ＤDP2は、タイプ２  ＤＰによって占有されたセルの数である。ＰＬＳ、ＥＡＣ、ＦＩＣは、いずれもタイプ１  ＤＰと同一の方式でマッピングされるので、これらは「タイプ１マッピング規則」に従う。そのため、タイプ１マッピングは、常にタイプ２マッピングに先行する。
【０３７３】
図２１は、本発明の実施例に係るＤＰマッピングを示す図である。
【０３７４】
（ａ）は、タイプ１  ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示し、（ｂ）は、タイプ２  ＤＰをマッピングするためのＯＦＤＭセルのアドレッシングを示す。
【０３７５】
タイプ１  ＤＰ（０、…、ＤDP1―１）をマッピングするためのＯＦＤＭセルのアドレッシングは、タイプ１  ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ１  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。また、これは、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。
【０３７６】
ＥＡＣ及びＦＩＣなしで、アドレス０は、最後のＦＳＳでＰＬＳを伝達する最後のセルの直後に来るセルを称する。該当フレームでＥＡＣが送信され、ＦＩＣが送信されない場合、アドレス０は、ＥＡＣを伝達する最後のセルの直後のセルを称する。ＦＩＣが該当フレームで送信されると、アドレス０は、ＦＩＣを伝達する最後のセルの直後のセルを称する。タイプ１  ＤＰに対するアドレス０は、（ａ）に示したように、２個の異なるケースを考慮して算出することができる。（ａ）に示した例において、ＰＬＳ、ＥＡＣ及びＦＩＣが全て送信されると仮定する。ＥＡＣ、ＦＩＣまたは両方とも省略される場合への拡張は簡単である。（ａ）の左側に示したように、全てのセルをＦＩＣまでマッピングした後、ＦＳＳに残りのセルがある。
【０３７７】
タイプ２  ＤＰ（０、…、ＤDP2―１）をマッピングするためのＯＦＤＭセルのアドレッシングは、タイプ２  ＤＰのアクティブデータセルのために定義される。アドレッシング方式は、タイプ２  ＤＰのそれぞれに対するＴＩからのセルがアクティブデータセルに割り当てられる順序を定義する。また、これは、ＰＬＳ２の動的部分内のＤＰの位置をシグナリングするのに使用される。
【０３７８】
（ｂ）に示したように、３個の少し異なるケースが可能である。（ｂ）の左側に示した第１のケースに対して、最後のＦＳＳ内のセルはタイプ２  ＤＰマッピングに利用可能である。中間に示した第２のケースに対して、ＦＩＣがノーマルシンボルのセルを占有するが、そのシンボル上のＦＩＣセルの数はＣFSSより大きくない。（ｂ）の右側上に示した第３のケースは、そのシンボル上にマッピングされたＦＩＣセルの数がＣFSSを超えることを除いては第２のケースと同一である。
【０３７９】
ＰＬＳ、ＥＡＣ及びＦＩＣがタイプ１  ＤＰと同一の「タイプ１マッピング規則」に従うので、タイプ１  ＤＰがタイプ２  ＤＰに先行する場合への拡張は簡単である。
【０３８０】
データパイプユニット（ＤＰＵ）は、フレームでデータセルをＤＰに割り当てる基本単位である。
【０３８１】
ＤＰＵは、フレームでＤＰを位置させるシグナリング単位として定義される。セルマッパー７０１０は、ＤＰのそれぞれに対してＴＩによって生成されたセルをマッピングすることができる。時間インターリーバー５０５０は、一連のＴＩブロックを出力し、それぞれのＴＩブロックは、セルのセットで構成される可変数のＸＦＥＣＢＬＯＣＫを含む。ＸＦＥＣＢＬＯＣＫ内のセルの数（Ｎcells）は、ＦＥＣＢＬＯＣＫサイズ（Ｎldpc）及び星状シンボル当たりに送信されるビットの数に依存する。ＤＰＵは、与えられたＰＨＹプロファイルでサポートされるＸＦＥＣＢＬＯＣＫ内のセルの数（Ｎcells）の全ての可能な値の最大公約数として定義される。セル内のＤＰＵの長さはＬDPUとして定義される。それぞれのＰＨＹプロファイルが星状シンボル当たりに異なる数のビット数及びＦＥＣＢＬＯＣＫサイズの異なる組み合わせをサポートするので、ＬDPUはＰＨＹプロファイルごとに定義される。
【０３８２】
図２２は、本発明の実施例に係るＦＥＣ構造を示す図である。
【０３８３】
図２２は、ビットインターリービング前の本発明の実施例に係るＦＥＣ構造を示す。上述したように、データＦＥＣエンコーダーは、入力ＢＢＦに対してＦＥＣエンコーディングを行い、外部コーディング（ＢＣＨ）及び内部コーディング（ＬＤＰＣ）を用いてＦＥＣＢＬＯＣＫ手順を生成することができる。図示したＦＥＣ構造はＦＥＣＢＬＯＣＫに対応する。また、ＦＥＣＢＬＯＣＫ及びＦＥＣ構造は、ＬＤＰＣコードワードの長さに対応する同一の値を有する。
【０３８４】
図２２に示したように、ＢＣＨエンコーディングがそれぞれのＢＢＦ（Ｋbchビット）に適用された後、ＬＤＰＣエンコーディングがＢＣＨエンコーディングされたＢＢＦ（Ｋldpcビット＝Ｎbchビット）に適用される。
【０３８５】
Ｎldpcの値は、６４８００ビット（長いＦＥＣＢＬＯＣＫ）または１６２００ビット（短いＦＥＣＢＬＯＣＫ）である。
【０３８６】
以下の表２８及び表２９は、それぞれ長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するＦＥＣエンコーディングパラメーターを示す。
【０３８７】
【表２８】
0006348184.tif 000031
【０３８８】
【表２９】
0006348184.tif 000032
【０３８９】
ＢＣＨエンコーディング及びＬＤＰＣエンコーディングの動作の細部事項は次の通りである。
【０３９０】
１２エラー訂正ＢＣＨコードは、ＢＢＦの外部エンコーディングに使用される。短いＦＥＣＢＬＯＣＫ及び長いＦＥＣＢＬＯＣＫに対するＢＣＨ生成器多項式は、全ての多項式を掛けることによって得られる。
【０３９１】
ＬＤＰＣコードは、外部ＢＣＨエンコーディングの出力をエンコーディングするのに使用される。完了したＢldpc（ＦＥＣＢＬＯＣＫ）を生成するために、Ｐldpc（パリティビット）がそれぞれのＩldpc（ＢＣＨエンコーディングＢＢＦ）から体系的にエンコーディングされ、Ｉldpcに添付される。完了したＢldpc（ＦＥＣＢＬＯＣＫ）は次の数式として表現される。
【０３９２】
【数３】
0006348184.tif 000033
【０３９３】
長いＦＥＣＢＬＯＣＫ及び短いＦＥＣＢＬＯＣＫに対するパラメーターは、前記表２８及び表２９にそれぞれ与えられる。
【０３９４】
長いＦＥＣＢＬＯＣＫのためのＮldpc−Ｋldpcパリティビットを算出する詳細な手順は次の通りである。
【０３９５】
１）パリティビットを初期化する。
【０３９６】
【数４】
0006348184.tif 000034
【０３９７】
２）パリティチェックマトリックスのアドレスの第１の行に特定されたパリティビットアドレスで第１の情報ビット（ｉ0）を累算する。パリティチェックマトリックスのアドレスの細部事項については後で説明する。例えば、レート１３／１５に対して、
【０３９８】
【数５】
0006348184.tif 000035
【０３９９】
３）次の３５９個の情報ビット（ｉs）（ｓ＝１、２、…、３５９）に対して、次の数式６を用いてパリティビットアドレスでｉsを累算する。
【０４００】
【数６】
0006348184.tif 000036
【０４０１】
ここで、ｘは、第１のビット（ｉ0）に対応するパリティビット累算器のアドレスを示し、Ｑldpcは、パリティチェックマトリックスのアドレスで特定されたコードレート従属定数である。例えば、継続して、レート１３／１５に対してＱldpc＝２４であって、情報ビット（ｉ1）に対して次の動作が行われる。
【０４０２】
【数７】
0006348184.tif 000037
【０４０３】
４）３６１番目の情報ビット（ｉ360）に対して、パリティビット累算器のアドレスは、パリティチェックマトリックスのアドレスの第２の行に与えられる。類似する方式で、次の３５９個の情報ビット（ｉs）（ｓ＝３６１、３６２、…、７１９）に対するパリティビット累算器のアドレスは数式６を用いて得られる。ここで、ｘは、情報ビット（ｉ360）、すなわち、パリティチェックマトリックスのアドレスの第２の行内のエントリーに対応するパリティビット累算器のアドレスである。
【０４０４】
５）類似する方式で、３６０個の新たな情報ビットの全てのグループに対して、パリティチェックマトリックスのアドレスからの新たな行がパリティビット累算器のアドレスを探すのに使用される。
【０４０５】
情報ビットが全部枯渇されると、最終パリティビットが次のように得られる。
【０４０６】
６）ｉ＝１で開始する次の動作を順次行う。
【０４０７】
【数８】
0006348184.tif 000038
【０４０８】
ここで、ｐi（ｉ＝０、１、…、Ｎdpc−Ｋldpc−１）の最終コンテンツは、パリティビット（ｐi）と同一である。
【０４０９】
【表３０】
0006348184.tif 000039
【０４１０】
短いＦＥＣＢＬＯＣＫに対するこのＬＤＰＣエンコーディング手順は、表３０を表３１に取り替え、長いＦＥＣＢＬＯＣＫに対するパリティチェックマトリックスのアドレスを短いＦＥＣＢＬＯＣＫに対するパリティチェックマトリックスのアドレスに取り替えることを除いては、長いＦＥＣＢＬＯＣＫに対するＬＤＰＣエンコーディング手順に従って行われる。
【０４１１】
【表３１】
0006348184.tif 000040
【０４１２】
図２３は、本発明の実施例に係るビットインターリービングを示す図である。
【０４１３】
ＬＤＰＣエンコーダーの出力はビットインターリービングされ、これは、パリティインターリービング、その後のＱＣＢ（ｑｕａｓｉ―ｃｙｃｌｉｃ  ｂｌｏｃｋ）インターリービング及び内部グループインターリービングで構成される。
【０４１４】
（ａ）は、ＱＣＢインターリービングを示し、（ｂ）は、内部グループインターリービングを示す。
【０４１５】
ＦＥＣＢＬＯＣＫはパリティインターリービングされ得る。パリティインターリービングの出力で、ＬＤＰＣコードワードは、長いＦＥＣＢＬＯＣＫ内の１８０個の隣接ＱＣブロック及び短いＦＥＣＢＬＯＣＫ内の４５個の隣接ＱＣブロックで構成される。長いまたは短いＦＥＣＢＬＯＣＫ内のそれぞれのＱＣブロックは３６０個のビットで構成される。パリティインターリービングされたＬＤＰＣコードワードは、ＱＣＢインターリービングによってインターリービングされる。ＱＣＢインターリービングの単位はＱＣブロックである。パリティインターリービングの出力でのＱＣブロックは、図２３に示したように、ＱＣＢインターリービングによってパーミュテーションされ、ここで、ＦＥＣＢＬＯＣＫ長さによってＮcells＝６４８００／ηｍｏｄまたは１６２００／ηｍｏｄである。ＱＣＢインターリービングパターンは、変調タイプ及びＬＤＰＣコードレートの各組み合わせに固有である。
【０４１６】
ＱＣＢインターリービング後、以下の表３２に定義された変調タイプ及び順序（ηｍｏｄ）に従って内部グループインターリービングが行われる。また、一つの内部グループに対するＱＣブロックの数（ＮQCB_IG）が定義される。
【０４１７】
【表３２】
0006348184.tif 000041
【０４１８】
ＱＣＢインターリービング出力のＮQCB-IG個のＱＣブロックで内部グループインターリービングが行われる。内部グループインターリービングは、３６０個の列とＮQCB_IG個の行を用いて内部グループのビットを記入及び判読するプロセスを有する。記入動作において、ＱＣＢインターリービング出力からのビットが行方向に記入される。判読動作は列方向に行われ、各行からｍ個のビットを判読し、ここで、ｍは、ＮＵＣに対して１と同一であり、ＮＣＱに対して２と同一である。
【０４１９】
図２４は、本発明の実施例に係るセル―ワードデマルチプレキシングを示す図である。
【０４２０】
（ａ）は、８及び１２ｂｐｃｕ  ＭＩＭＯに対するセル―ワードデマルチプレキシングを示し、（ｂ）は、１０ｂｐｃｕ  ＭＩＭＯに対するセル―ワードデマルチプレキシングを示す。
【０４２１】
（ａ）に示したように、ビットインターリービング出力のそれぞれのセルワード（ｃ0,l, ｃ1,l，…，ｃnmod―1,1）は、（ｄ1,0,m, ｄ1,1,m，…, ｄ1,nmod―1,m）及び（ｄ2,0,m，ｄ2,1,m，…，ｄ2,nmod―1,m）にデマルチプレキシングされ、これは、一つのＸＦＥＣＢＬＯＣＫに対するセル―ワードデマルチプレキシングプロセスを記述する。
【０４２２】
ＭＩＭＯエンコーディングのための異なるタイプのＮＵＱを用いる１０ｂｐｃｕ  ＭＩＭＯケースに対して、ＮＵＱ―１０２４のためのビットインターリーバーが再使用される。（ｂ）に示したように、ビットインターリーバー出力の各セルワード（ｃ0,l， ｃ1,l，…，ｃ9,l）は、（ｄ1,0,m，ｄ1,1,m，…，ｄ1,3,m）及び（ｄ2,0,m，ｄ2,1,m，…，ｄ2,5,m）にデマルチプレキシングされる。
【０４２３】
図２５は、本発明の実施例に係る時間インターリービングを示す図である。
【０４２４】
（ａ）〜（ｃ）は、ＴＩモードの例を示す。
【０４２５】
時間インターリーバーはＤＰレベルで動作する。時間インターリービング（ＴＩ）のパラメーターは、各ＤＰに対して異なる形に設定することができる。
【０４２６】
ＰＬＳ２―ＳＴＡＴデータの一部に表れる次のパラメーターはＴＩを構成する。
【０４２７】
ＤＰ＿ＴＩ＿ＴＹＰＥ（許容される値：０または１）：ＴＩモードを示し、「０」は、ＴＩグループごとに多数のＴＩブロック（１より多いＴＩブロック）を有するモードを示す。この場合、一つのＴＩグループは一つのフレーム（フレーム間のインターリービングはない）に直接マッピングされる。「１」は、ＴＩグループ当たり一つのみのＴＩブロックを有するモードである。この場合、ＴＩブロックは、１より多いフレームにわたって拡散され得る（フレーム間のインターリービング）。
【０４２８】
ＤＰ＿ＴＩ＿ＬＥＮＧＴＨ：ＤＩ＿ＴＩ＿ＴＹＰＥ＝「０」である場合、このパラメーターは、ＴＩグループ当たりのＴＩブロックの数（ＮＴＩ）である。ＤＰ＿ＴＩ＿ＴＹＰＥ＝「１」に対して、このパラメーターは、一つのＴＩグループから拡散されたフレームの数（ＰＩ）である。
【０４２９】
ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸ（許容される値：０〜１０２３）：ＴＩグループ当たりのＸＦＥＣＢＬＯＣＫの最大数を示す。
【０４３０】
ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ（許容される値：１、２、４、８）：与えられたＰＨＹプロファイルの同一のＤＰを伝達する２個の連続フレーム間のフレームの数（ＩＪＵＭＰ）を示す。
【０４３１】
ＤＰ＿ＴＩ＿ＢＹＰＡＳＳ（許容される値：０または１）：時間インターリービングがＤＰに使用されない場合、このパラメーターは「１」に設定される。時間インターリービングが使用される場合、「０」に設定される。
【０４３２】
さらに、ＰＬＳ２―ＤＹＮデータからのパラメーター（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ）は、ＤＰの一つのＴＩグループによって伝達されるＸＦＥＣＢＬＯＣＫの数を示すのに使用される。
【０４３３】
時間インターリービングがＤＰに使用されない場合、次のＴＩグループ、時間インターリービング動作及びＴＩモードが考慮されない。しかし、スケジューラーからの動的構成情報に対する補償ブロックは依然として要求される。それぞれのＤＰにおいて、ＳＳＤ／ＭＩＭＯエンコーディングから受信されたＸＦＥＣＢＬＯＣＫはＴＩグループにグルーピングされる。すなわち、それぞれのＴＩグループは、整数のＸＦＥＣＢＬＯＣＫのセットであり、動的に可変する数のＸＦＥＣＢＬＯＣＫを含む。インデックス（ｎ）のＴＩグループ内のＸＦＥＣＢＬＯＣＫの数（ｎ）はＮxBLOCK_Group_（ｎ）で表示され、ＰＬＳ２―ＤＹＮデータ内のＤＰ＿ＮＵＭ＿ＢＬＯＣＫとしてシグナリングされる。ＮxBLOCK_Group_（ｎ）は、０の最小値から最も大きい値が１０２３である最大値（ＮxBLOCK_Group_MAX）（ＤＰ＿ＮＵＭ＿ＢＬＯＣＫ＿ＭＡＸに対応）に変更可能であることに注目すべきである。
【０４３４】
それぞれのＴＩグループは、一つのフレームに直接マッピングされたり、ＰＩ個のフレームにわたって拡散され得る。また、それぞれのＴＩグループは、１より多いＴＩブロック（ＮＴＩ）に分離され、それぞれのＴＩブロックは、時間インターリーバーメモリの１回の使用に対応する。ＴＩグループ内のＴＩブロックは、少し異なる数のＸＦＥＣＢＬＯＣＫを含むことができる。ＴＩグループが多数のＴＩブロックに分離されると、一つのフレームのみに直接マッピングされる。以下の表３３に示したように、（時間インターリービングをスキップする追加のオプションを除いて）、時間インターリービングに対して３個のオプションが存在する。
【０４３５】
【表３３】
0006348184.tif 000042
【０４３６】
それぞれのＤＰにおいて、ＴＩメモリは、入力ＸＦＥＣＢＬＯＣＫ（ＳＳＤ／ＭＩＭＯエンコーディングブロックからの出力ＸＦＥＣＢＬＯＣＫ）を格納する。入力ＸＦＥＣＢＬＯＣＫは、
【数９】
0006348184.tif 000043
として定義されると仮定し、
ここで、ｄn,s,r,qは、ｎ番目のＴＩグループのｓ番目のＴＩブロックでｒ番目のＸＦＥＣＢＬＯＣＫのｑ番目のセルであって、次のようにＳＳＤ及びＭＩＭＯエンコーディングの出力を示す。
【０４３７】
【数１０】
0006348184.tif 000044
また、時間インターリーバーからの出力ＸＦＥＣＢＬＯＣＫは、次のように定義される。
【０４３８】
【数１１】
0006348184.tif 000045
【０４３９】
一般に、時間インターリーバーは、フレーム形成プロセス前にＤＰデータに対するバッファとして動作する。これは、それぞれのＤＰに対する２個のメモリバンクによって達成される。第１のＴＩブロックは第１のバンクに記入される。第１のバンクが判読される間、第２のＴＩブロックが第２のバンクに記入される。
【０４４０】
ＴＩは、ツイスト行―列ブロックインターリーバーである。ｎ番目のＴＩグループのｓ番目のＴＩブロックに対して、ＴＩメモリの行の数（Ｎr）はセルの数（Ｎcell）と同一であって、すなわち、Ｎr＝Ｎcellであるが、列の数（Ｎc）は数（ＮxBLOCK_TI（ｎ，ｓ））と同一である。
【０４４１】
図２６は、本発明の実施例に係るツイスト行―列ブロックインターリーバーの基本動作を示す図である。
【０４４２】
（ａ）は、時間インターリーバーの記入動作を示し、（ｂ）は、時間インターリーバーの判読動作を示す。（ａ）に示したように、第１のＸＦＥＣＢＬＯＣＫは、ＴＩメモリの第１の列に列方向に記入され、第２のＸＦＥＣＢＬＯＣＫは次の列に記入される。その後、インターリービングアレイにおいて、セルは対角線方向に判読される。第１の行から最後の行まで対角線方向に判読（最左側の列から始めて行に沿って右側に）する間、（ｂ）に示したようにＮr個のセルが判読される。より詳細には、順次判読されるＴＩメモリセル位置としてＺn,s,i（ｉ＝０、…、ＮrＮc）を想定し、このようなインターリービングアレイでの判読プロセスは、次の数式のように、行インデックス（Ｒn,s,i）、列インデックス（Ｃn,s,i）及び連関したツイストパラメーター（Ｔn,s,i）を算出することによって行われる。
【０４４３】
【数１２】
0006348184.tif 000046
【０４４４】
ここで、Ｓshiftは、ＮxBLOCK_TI（ｎ，ｓ）とは関係なく、対角線方向判読プロセスに対する共通シフト値であって、次の数式のように、ＰＬＳ―ＳＴＡＴで与えられたＮxBLOCK_TI_MAXによって決定される。
【０４４５】
【数１３】
0006348184.tif 000047
【０４４６】
結果的に、判読されるセル位置は、Ｚn,s,i＝ＮrＣn,s,i＋Ｒn,s,iとして座標によって算出される。
【０４４７】
図２７は、本発明の他の実施例に係るツイスト行―列ブロックインターリーバーの基本動作を示す図である。
【０４４８】
特に、図２７は、ＮxBLOCK_TI（０，０）＝３、ＮxBLOCK_TI（１，０）＝６、ＮxBLOCK_TI（２，０）＝５であるとき、仮想のＸＦＥＣＢＬＯＣＫを含む、それぞれのＴＩグループに対するＴＩメモリ内のインターリービングアレイを示す。
【０４４９】
変数（ＮxBLOCK_TI（ｎ，ｓ）＝Ｎr）は、Ｎ’xBLOCK_TI_MAXより小さいか同じであり得る。よって、受信側で単一メモリデインターリービングを達成するために、ＮxBLOCK_TI（ｎ，ｓ）とは関係なく、ツイスト行―列ブロックインターリーバーで使用されるインターリービングアレイは、仮想のＸＦＥＣＢＬＯＣＫをＴＩメモリに挿入することによってＮr×Ｎc＝Ｎcells×Ｎ’xBLOCK_TI_MAXのサイズに設定され、判読プロセスは次の数式として達成される。
【０４５０】
【数１４】
0006348184.tif 000048
【０４５１】
ＴＩグループの数は３に設定される。時間インターリーバーのオプションは、ＤＰ＿ＴＩ＿ＴＹＰＥ＝「０」、ＤＰ＿ＦＲＡＭＥ＿ＩＮＴＥＲＶＡＬ＝「１」及びＤＰ＿ＴＩ＿ＬＥＮＧＴＨ＝「１」、すなわち、ＮTI＝１、ＩJUMP＝１及びＰ1＝１によってＰＬＳ２―ＳＴＡＴデータでシグナリングされる。ＴＩグループごとにそれぞれＮcells＝３０個のセルを有するＸＦＥＣＢＬＯＣＫの数は、ＮxBLOCK_TI（０，０）＝３、ＮxBLOCK_TI（１，０）＝６、ＮxBLOCK_TI（２，０）＝５によってそれぞれＰＬＳ２―ＤＹＮデータでシグナリングされる。ＸＦＥＣＢＬＯＣＫの最大数は、ＮxBLOCK_Group_MAXによってＰＬＳ２―ＳＴＡＴデータでシグナリングされ、これは、
【数１５】
0006348184.tif 000049
【０４５２】
図２８は、本発明の実施例に係るツイスト行―列ブロックインターリーバーの対角線方向判読パターンを示す図である。
【０４５３】
特に、図２８は、Ｎ’xBLOCK_TI_MAX＝７及びＳshift＝（７−１）／２＝３のパラメーターを有するそれぞれのインターリービングアレイからの対角線方向判読パターンを示す。上述した擬似コードとして示した判読プロセスにおいて、Ｖi≧ＮcellsＮxBLOCK_TI（ｎ，ｓ）であると、Ｖiの値がスキップされ、Ｖiの次に算出された値が使用される。
【０４５４】
図２９は、本発明の一実施例に係るそれぞれのインターリービングアレイからインターリービングされたＸＦＥＣＢＬＯＣＫを示す図である。
【０４５５】
図２９は、Ｎ’xBLOCK_TI_MAX＝７及びＳshift＝３のパラメーターを有するそれぞれのインターリービングアレイからインターリービングされたＸＦＥＣＢＬＯＣＫを示す。
【０４５６】
図３０は、自動コンテンツ認識へースＥＴＶ（ｅｎｈａｎｃｅｄ  ｔｅｌｅｖｉｓｉｏｎ）サービスシステムを示す図である。
【０４５７】
図３０に示す自動コンテンツ認識へースＥＴＶサービスシステムは、放送局又はコンテンツプロバイダ１００、多チャネル放送事業者１０１、セットトップボックス１０２、デジタルＴＶ受信機などの受信機１０３、自動コンテンツ認識サーバー（又は、自動コンテンツ認識ソリューションプロバイダ）１０４を含むことができる。受信機１０３は、ＡＴＳＣ（ａｄｖａｎｃｅｄ  ｔｅｌｅｖｉｓｉｏｎ  ｓｙｓｔｅｍ  ｃｏｍｍｉｔｔｅｅ）の定義に従って動作することができ、自動コンテンツ認識機能を支援することができる。実時間放送サービス１１０は、オーディオ／ビデオコンテンツを含むことができる。
【０４５８】
デジタル放送サービスは、放送局１００によって提供される地上波放送サービスと、多チャネル放送事業者１０１によって提供されるケーブル放送又は衛星放送などの多チャネル放送サービスと、に大別できる。放送局１００は、実時間放送サービス１１０及びエンハンスメントデータ（又は、付加データ）１２０を共に伝送することができる。この場合、図３０に示すように、受信機１０３は、多チャネル放送事業者１０１及びセットトップボックス１０２を介して実時間放送サービス１１０のみを受信し、エンハンスメントデータ１２０は受信できないことがある。
【０４５９】
したがって、エンハンスメントデータ１２０を受信するために、受信機１０３は、オーディオ／ビデオコンテンツ出力を実時間放送サービス１１０として分析及び処理し、放送プログラム情報及び／又は放送プログラム関連メタデータを確認する。確認された放送プログラム情報及び／又は放送プログラム関連メタデータを用いて、受信機１０３は、放送局１００又は自動コンテンツ認識サーバー１０４からエンハンスメントデータを受信することができる（１４０）。この場合、エンハンスメントデータは、インターネットプロトコルネットワーク１５０を介して伝送するすることができる。
【０４６０】
エンハンスメントデータが別の自動コンテンツ認識サーバー１０４から受信されると、（１４０）、自動コンテンツ認識サーバー１０４と受信機１０３間のメカニズムにおいて、ＡＴＳＣ ２．０標準で定義したＴＤＯ（ｔｒｉｇｇｅｒｅｄ  ｄｅｃｌａｒａｔｉｖｅ  ｏｂｊｅｃｔ）モデルのうち要求／応答モデルを自動コンテンツ認識サーバー１０４に適用することができる。ＴＤＯ及び要求／応答モデルは後述する。
【０４６１】
ＴＤＯは、放送コンテンツに含まれた付加情報を表す。ＴＤＯは、放送コンテンツ内で付加情報を適時にトリガリングする役割を有する。例えば、オーディオプログラムが放送されると、視聴者が好むオーディション参加者の現在順位が放送コンテンツと共に表示される。この時、オーディション参加者の現在順位の付加情報はＴＤＯになり得る。このようなＴＤＯは、視聴者との相互作用によって変更されてもよく、視聴者の意図によって提供されてもよい。
【０４６２】
標準ＡＴＳＣ ２．０の要求／応答自動コンテンツ認識モデルで、デジタル放送受信機１０３は、周期的に（例えば、５秒ごとに）コンテンツのシグネチャー（ｓｉｇｎａｔｕｒｅ）を生成し、当該シグネチャーを含む要求を自動コンテンツ認識サーバー１０４に伝送するようになっている。自動コンテンツ認識サーバー１０４は、デジタル放送受信機１０３から要求を受けると応答を送る。通信セッションは要求と応答間で開放されない。このモデルで、自動コンテンツ認識サーバー１０４はクライアントに対するメッセージを開始することができない。
【０４６３】
デジタル衛星放送の導入によって、デジタルデータ放送が新しい付加サービスとして出現した。代表的な双方向サービスである双方向データ放送は、様々な付加サービスを提供するために、データ信号だけでなく既存の放送信号を加入者に伝送することができる。
【０４６４】
デジタルデータ放送は、仮想チャネルを用いた独立型サービスと、ＥＴＶを通した放送関連サービスと、に大別できる。独立型サービスは、放送イメージ信号無しでテキストとグラフィックのみを含み、既存のインターネットウェブページと類似のフォーマットで提供される。独立型サービスの代表例として、天気及び株式情報提供サービス、ＴＶ金融サービス、商取り引きサービスなどを挙げることができる。放送関連サービスは、放送イメージ信号だけでなく付加的なテキスト及びグラフィック情報も伝送する。視聴者は、放送関連サービスを通して視聴する放送プログラムに関連した情報を得ることができる。例えば、視聴者がドラマを視聴しながら以前ストーリや撮影場所を見ることができるようにするサービスがある。
【０４６５】
デジタルデータ放送の放送関連サービスでは、ＥＴＶサービスが自動コンテンツ認識技術に基づいて提供されてもよい。自動コンテンツ認識とは、装置がオーディオ／ビデオコンテンツを再生する際、コンテンツに隠れている情報から自動でコンテンツを認識する技術のことを指す。
【０４６６】
自動コンテンツ認識技術を施行するとき、コンテンツに関する情報を得るために、ウォーターマーキング（ｗａｔｅｒｍａｒｋｉｎｇ）やフィンガープリンティング（ｆｉｎｇｅｒ  ｐｒｉｎｔｉｎｇ）方式を用いることができる。ウォーターマーキングは、デジタルコンテンツプロバイダを示す情報をデジタルコンテンツに挿入する技術のことをいう。フィンガープリンティングは、特定情報がデジタルコンテンツに挿入される点はウォーターマーキングと同一であるが、コンテンツプロバイダに関する情報ではなくコンテンツ購買者に関する情報が挿入される点がウォーターマーキングと異なる。
【０４６７】
図３１は、本発明の一実施例に係るデジタルウォーターマーキング技術の流れを示す図である。
【０４６８】
デジタル衛星放送の導入によって、デジタルデータ放送が新しい付加サービスとして出現した。代表的な双方向サービスである双方向データ放送は、様々な付加サービスを提供するために、データ信号だけでなく既存の放送信号を加入者に伝送することができる。
【０４６９】
デジタルデータ放送は、仮想チャネルを用いた独立型サービスと、ＥＴＶを通した放送関連サービスと、に大別できる。独立型サービスは、放送イメージ信号無しでテキストとグラフィックのみを含み、既存のインターネットウェブページと類似のフォーマットで提供される。独立型サービスの代表例として、天気及び株式情報提供サービス、ＴＶ金融サービス、商取り引きサービスなどを挙げることができる。放送関連サービスは、放送イメージ信号だけでなく付加的なテキスト及びグラフィック情報も伝送する。視聴者は、放送関連サービスを通して視聴する放送プログラムに関連した情報を得ることができる。例えば、視聴者がドラマを視聴しながら以前ストーリや撮影場所を見ることができるようにするサービスがある。
【０４７０】
デジタルデータ放送の放送関連サービスでは、ＥＴＶサービスが自動コンテンツ認識技術に基づいて提供されてもよい。自動コンテンツ認識とは、装置がオーディオ／ビデオコンテンツを再生する際、コンテンツに隠れている情報から自動でコンテンツを認識する技術のことを指す。
【０４７１】
自動コンテンツ認識技術を施行するとき、コンテンツに関する情報を得るために、ウォーターマーキングやフィンガープリンティング方式を用いることができる。ウォーターマーキングは、デジタルコンテンツプロバイダを示す情報をデジタルコンテンツに挿入する技術のことをいう。フィンガープリンティングは、特定情報がデジタルコンテンツに挿入される点はウォーターマーキングと同一であるが、コンテンツプロバイダに関する情報ではなくコンテンツ購買者に関する情報が挿入される点がウォーターマーキングと異なる。
【０４７２】
以下、図３１と関連してウォーターマーキング技術について具体的に説明する。
【０４７３】
デジタルウォーターマーキングは、除去され難い方式でデジタル信号に情報を埋め込む過程である。例えば、信号としては、音声、画面、又は映像を挙げることができる。信号が複製されると、情報も複製された信号に乗せられる。一つの信号は同時に複数の異なるウォーターマークを乗せることができる。
【０４７４】
視覚的ウォーターマーキングにおいて、情報は画面又は映像で可視できる。一般に、情報は、メディアの所有者を識別するテキストやロゴである。ＴＶ放送局が、伝送される映像のコーナーにロゴを追加すると、これも視覚的ウォーターマークである。
【０４７５】
非視覚的ウォーターマーキングにおいて、情報はデジタルデータとして音声、画面、又は映像に追加される。若干の情報が隠されていることは感知できても、それ自体を認知することはできない。ウォーターマークは、広く使用されるためのものであって、検索しやすくなっていてもよく、又は、ある団体がデジタル信号に埋め込まれた秘密メッセージを授受するステガノグラフィの形態であってもよい。いずれの場合であれ、視覚的ウォーターマーキングと同様、目的は、所有主や他の記述情報を除去され難い方式で信号に付着することにある。隠されている埋め込み情報を、個々人間の通信を切り替えるための手段として用いることもできる。
【０４７６】
ウォーターマーキングの一つの応用として、デジタルメディアの非承認複製を防止又は阻止するための著作権保護システムがある。この用途では、複製装置が複製前に信号からウォーターマークを検索し、ウォーターマークのコンテンツによって複製をするか否かを決定する。他の応用としてはソース追跡がある。
【０４７７】
ウォーターマークは配布の度にデジタル信号に埋め込まれる。著作物の複製物が後で発見されると、ウォーターマークを複製物から検索でき、配布のソースを見つける。報道によると、この技術は、不正に複製された映画のソースを見つけるために用いられている。
【０４７８】
記述情報を持つデジタル写真のアノテーションは、非視覚的ウォーターマーキングの更に他の応用である。
【０４７９】
デジタルメディアに対するファイル形式の一部がメタデータと呼ばれる付加情報を含むことができるのに対し、デジタルウォーターマーキングはデータが信号自体で伝達される。
【０４８０】
一部の文脈でデジタルウォーターマークという言葉がウォーターマーキングされた信号とカバー信号との相違を意味するが、埋め込まれる情報はデジタルウォーターマークと呼ばれる。ウォーターマークの埋め込まれる信号はホスト信号と呼ばれる。
【０４８１】
ウォーターマーキングシステムは、主に、埋め込み（２０１）、攻撃（２０２）、検出（又は、抽出）（２０３）の、３つの別個の段階に区別される。
【０４８２】
埋め込み（２０１）で、アルゴリズムは、ホスト及び埋め込まれるデータを取り込み、ウォーターマーキングされた信号を生成する。
【０４８３】
ウォーターマーキングされた信号は伝送又は記憶されるが、主に、他の人に伝送される。この人が変更を加えると、これは攻撃（２０２）と呼ばれる。変更が悪意的でない場合もあるが、攻撃という用語は、著作権侵害者が変更によってデジタルウォーターマークを除去しようとする著作権保護アプリケーションから発生する。様々な変更が可能である。例えば、データの非可逆圧縮、イメージ又は映像のクロッピング、又は意図的に加える雑音などがありうる。
【０４８４】
検出（２０３）は、攻撃された信号からウォーターマークを抽出するために攻撃された信号に適用するアルゴリズムである。信号が伝送中に変更されなかった場合、ウォーターマークは依然として存在し、ウォーターマークの抽出が可能である。堅固なウォーターマーキングアプリケーションでは、変更が強力であっても抽出アルゴリズムはウォーターマークを正しく生成できるはずである。脆弱なウォーターマーキングでは、信号にいかなる変更が加えられても抽出アルゴリズムは失敗するだろう。
【０４８５】
埋め込まれた情報が数回の変形によって劣化しても、マーキングされた信号から確実に検出されると、デジタルウォーターマークは変形に対して堅固てあるという。典型的なイメージ劣化は、ＪＰＥＧ圧縮、回転（ｒｏｔａｔｉｏｎ）、クロッピング、付加的な雑音及び量子化である。ビデオコンテンツにおいて、一時的な変更及びＭＰＥＧ圧縮が主にここに含まれる。ウォーターマーキングされたコンテンツが、本来のウォーターマーキングされていないコンテンツと知覚的に同等であると、ウォーターマークは感知できないという。一般に、堅固なウォーターマーク又は感知できないウォーターマークは生成しやすいが、堅固であり且つ感知できないウォーターマークは生成し難しと知られている。堅固であり且つ感知できないウォーターマークは、デジタルコンテンツの保護のための道具、例えば、専門的なビデオコンテンツで埋め込まれた”複製不許”フラグとして提案された。
【０４８６】
デジタルウォーターマーキング技術は、いくつかの方式に分類できる。
【０４８７】
第一に、ウォーターマークは、若干の変形後に検出されないと脆弱であるという（堅固性）。脆弱なウォーターマークは通常、タンパー検出（完全性立証）のために用いられる。明らかに明確な原著作物に加えた変形は、普通、ウォーターマークと呼ばれず、一般化したバーコードと呼ばれる。陽性変形には抵抗力があるが、悪性変形後には検出に失敗するウォーターマークは、やや脆弱であるという。やや脆弱なウォーターマークは、通常、悪性変形を検出するために用いられる。指定された部類の変形に抵抗力があるウォーターマークは堅固であるという。堅固なウォーターマークは、複製物を伝達し、制御情報に接続するために、複製防止アプリケーションで用いることができる。
【０４８８】
第二に、本来のカバー信号とマーキングされた信号とが知覚的に区別されないと（区別され難いと）、ウォーターマークは感知できないという（知覚性）。マーキングされた信号での存在が明らかであるが、非侵害的であると、ウォーターマークは感知できるという。
【０４８９】
第三に、容量に関して、埋め込まれたメッセージの長さは、２つの異なる主部類のウォーターマーキング方式を決定する。
【０４９０】
メッセージは概念上０ビットの長さを有し、システムは、マーキングされたオブジェクトからウォーターマークの存在有無を検出するために設計される。この種のウォーターマーキング方式は、主に、イタリック０ビット又はイタリック存在ウォーターマーキング方式と呼ばれる。しばしばこの種のウォーターマーキング方式は、１がウォーターマークの存在を示すため（０は不在）、１ビットウォーターマークと呼ばれる。
【０４９１】
メッセージはｎビット長のストリーム（ｎ＝｜ｍ｜又はＭ＝｛０，１｝ｎ）であり、ウォーターマークで変調される。この種の方式は主に、多重ビットウォーターマーキング又は非零ビットウォーターマーキング方式と呼ばれる。
【０４９２】
第四に、埋め込み段階にはいくつかの方式がある。マーキングされた信号が付加的な変形によって得られると、ウォーターマーキング方法は帯域拡散と呼ばれる。帯域拡散ウォーターマークは適当に堅固であると知られているが、ホスト干渉によって低い情報容量を有するとも知られている。マーキングされた信号が量子化によって得られると、ウォーターマーキング方法は、量子化タイプのものという。量子化ウォーターマークは低い堅固性を有するが、ホスト干渉の排除によって高い情報容量を有する。マーキングされた信号が帯域拡散法と類似の付加的な変形によって埋め込まれるが、特別に空間領域で埋め込まれると、ウォーターマーキング方法は振幅変調と呼ばれる。
【０４９３】
図３２は、本発明の一実施例に係る自動コンテンツ認識クエリー結果フォーマットを示す図である。
【０４９４】
既存の自動コンテンツ認識サービス処理システムによれば、放送局が実時間サービスのためのコンテンツとＥＴＶサービスのためのエンハンスメントデータを共に伝送し、ＴＶ受信機がコンテンツとＥＴＶサービスを受信する場合、実時間サービスのためのコンテンツは受信できるが、エンハンスメントデータは受信できない。
【０４９５】
この場合、本発明の一実施例によれば、インターネットプロトコルネットワークを用いた独立したインターネットプロトコルシグナリングチャネルを用いて、既存の自動コンテンツ認識処理システムの問題を解決することができる。すなわち、ＴＶ受信機は、多チャネル放送事業者を通して実時間サービスのためのコンテンツを受信することができ、独立したインターネットプロトコルシグナリングチャネルを介してエンハンスメントデータを受信することができる。
【０４９６】
この場合、本発明の一実施例によれば、インターネットプロトコルシグナリングチャネルは、ＰＳＩＰストリームがバイナリストリームの形態で伝達及び処理されるように構成される。このとき、インターネットプロトコルシグナリングチャネルは、プル（ｐｕｌｌ）方法やプッシュ（ｐｕｓｈ）方法を用いるように構成される。
【０４９７】
プル方法のインターネットプロトコルシグナリングチャネルは、ＨＴＴＰ要求／応答方法によって構成することができる。ＨＴＴＰ要求／応答方法によれば、ＰＳＩＰバイナリストリームは、ＨＴＴＰ要求信号に対するＨＴＴＰ応答信号に含まれ、ＳｉｇｎａｌｉｎｇＣｈａｎｎｅｌＵＲＬを通して伝送されてもよい。この場合、ポーリングサイクルは、自動コンテンツ認識クエリー結果として伝達されたメタデータでＰｏｌｌｉｎｇ＿ｃｙｃｌｅによって周期的に要求されてもよい。また、更新される時間及び／又は周期に関する情報は、シグナリングチャネルに含まれて伝送されてもよい。この場合、受信機は、インターネットプロトコルシグナリングチャネルから受信した更新時間及び／又は周期情報に基づいてサーバーにシグナリング情報を要求することができる。
【０４９８】
プッシュ方法のインターネットプロトコルシグナリングチャネルは、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔアプリケーションプログラミングインターフェースを用いて構成することができる。ＸＭＬＨＴＴＰＲｅｑｕｅｓｔアプリケーションプログラミングインターフェースが用いられると、サーバーから非同期で最新情報を受信することができる。これは、受信機にとっては、ＸＭＬＨＴＴＰＲｅｑｕｅｓｔオブジェクトを通してサーバーに非周期的にシグナリング情報を要求する方法であり、サーバーにとっては、シグナリング情報が変更された場合は、要求に応答してこのチャネルを介してシグナリング情報を提供する方法である。セッションの待ち時間に制限があると、セッションタイムアウト応答が生成され、受信機はセッションタイムアウト応答を認識し、シグナリング情報を再び要求し、受信機とサーバー間でシグナリングチャネルを維持することができる。
【０４９９】
インターネットプロトコルシグナリングチャネルを介してエンハンスメントデータを受信するために、受信機はウォーターマーキングとフィンガープリンティングを用いて動作することができる。フィンガープリンティングは、コンテンツ購買者に関する情報をコンテンツプロバイダの代わりにコンテンツに挿入する技術のことを指す。フィンガープリンティングが用いられると、受信機は、コンテンツを確認するために参照データベースを検索することができる。コンテンツを確認した結果は、自動コンテンツ認識クエリー結果と呼ばれる。自動コンテンツ認識クエリー結果は、ＴＶ視聴者に提供されたクエリーを含み、自動コンテンツ認識機能を実行するためにクエリーの情報に対して対応することができる。受信機は、自動コンテンツ認識クエリー結果に基づいてＥＴＶサービスを提供することができる。
【０５００】
自動コンテンツ認識クエリー結果に関する情報は、ウォーターマーク基盤自動コンテンツ認識システム上でオーディオ／ビデオコンテンツに挿入／埋め込みされて送信されてもよい。受信機は、ウォーターマーク抽出器を通して自動コンテンツ認識クエリー結果情報を抽出及び取得した後、ＥＴＶサービスを提供することができる。この場合、ＥＴＶサービスを別途の自動コンテンツ認識サーバー無しで提供することができ、インターネットプロトコルネットワークを通したクエリーは省略することができる。
【０５０１】
図３２は、本発明の一実施例に係る自動コンテンツ認識クエリー結果を示すＸＭＬスキーマの図である。図３２に示すように、自動コンテンツ認識クエリー結果のＸＭＬフォーマットは、結果コード部３１０を含むことができ、自動コンテンツ認識クエリー結果タイプ３００は、コンテンツ識別子部３０１、ＮＴＰ（ｎｅｔｗｏｒｋ  ｔｉｍｅ  ｐｒｏｔｏｃｏｌ）タイムスタンプ部３０２、シグナリングチャネル情報部３０３、サービス情報部３０４、その他識別子部３０５を含むことができる。シグナリングチャネル情報部３０３は、シグナリングチャネルＵＲＬ部３１３、更新モード部３２３、ポーリングサイクル部３３３を含むことができ、サービス情報部３０４は、サービスネーム部３１４、サービスロゴ部３２４、サービス記述部３３４を含むことができる。
【０５０２】
次に、図３２に示す自動コンテンツ認識クエリー結果のＸＭＬスキーマの図を詳しく説明し、ＸＭＬスキーマの例を説明する。
【０５０３】
結果コード部３１０は、自動コンテンツ認識クエリーの結果値を示すことができる。これはクエリー成功又は失敗、クエリーに失敗すると失敗理由をコード値の形態で示すことができる。例えば、結果コード部３１０の値が２００であれば、これはクエリーに成功し、それに該当するコンテンツ情報が応答されたということを示す。結果コード部３１０の値が４０４であれば、これは、コンテンツが発見されなかったということを示す。
【０５０４】
コンテンツ識別子部３０１は、全世界で唯一にコンテンツを識別するための識別子を示し、サービスを識別するための識別子であるグローバルサービス識別子部を含むことができる。
【０５０５】
ＮＴＰタイムスタンプ部３０２は、自動コンテンツ認識クエリーに用いられるサンプルフレーム間隔の特定時点がＮＴＰタイムスタンプの形態で提供されるということを示すことができる。ここで、特定時点は、サンプルフレームの始点又は終点であってもよい。ＮＴＰは、インターネットを通してコンピュータの時間をレファレンスクロックに合わせるためのプロトコルのことをいい、タイムサーバーとコンピューターネットワーク上に分配されたクライアント間の時間同期化のために用いることができる。ＮＴＰがＵＴＣ（ｕｎｉｖｅｒｓａｌ  ｔｉｍｅ  ｃｏｏｒｄｉｎａｔｅｄ）時間を使用し、１０ｍｓの正確度を保障することから、受信機はフレーム同期化動作を正確に処理することができる。
【０５０６】
シグナリングチャネル情報部３０３は、ＥＴＶサービスのためのインターネットプロトコルネットワーク上の独立したシグナリングチャネルのアクセス情報を示すことができる。
【０５０７】
より具体的に、シグナリングチャネル情報部３０３の下位部であるシグナリングチャネルＵＲＬ部３１３は、シグナリングチャネルのＵＲＬ情報を示すことができる。シグナリングチャネルＵＲＬ部３１３は、更新モード部３２３及びポーリングサイクル部３３３を下位部として含むことができる。更新モード部３２３は、インターネットプロトコルシグナリングチャネルを介して情報を取得する方法を示す。例えば、プルモードで、受信機は情報を取得するためにプル方法によって周期的にポーリングを行うことができ、プッシュモードで、サーバーはプッシュ方法によって受信機に情報を送信することができる。ポーリングサイクル部３３３は、更新モード部３２３がプルモードであればプル方法によって受信機の基本ポーリングサイクル値を示すことができる。その後、受信機は基本ポーリングサイクル値を特定し、任意時間間隔で要求信号をサーバーに送信することで、サーバーが要求によって過負荷となることを防止することができる。
【０５０８】
サービス情報部３０４は、放送チャネルに関する情報を示すことができる。コンテンツＩＤ部３０１は、視聴者によって現在視聴されているサービスの識別子を示すことができ、サービス情報部３０４は、放送チャネルに関する具体的な情報を示すことができる。例えば、サービス情報部３０４が示す具体的な情報は、チャネル名、ロゴ、又はテキスト説明であってもよい。
【０５０９】
より具体的に、サービス情報部３０４の下位部であるサービスネーム部３１４は、チャネル名を示すことができ、サービスロゴ部３２４は、チャネルロゴを示すことができ、サービス記述部３３４は、チャネルテキスト説明を示すことができる。
【０５１０】
次に、本発明の一実施例に係る図３２に示した自動コンテンツ認識クエリー結果のエレメントのＸＭＬスキーマを示す。
【０５１１】
<xs:complexType name="ACR-ResultType">
<xs:sequence>
<xs:element name="ContentID" type="xs:anyURI"/>
<xs:element name="NTPTimestamp" type="xs:unsignedLong"/>
<xs:element name="SignalingChannelInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="SignalingChannelURL" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="UpdateMode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Pull"/>
<xs:enumeration value="Push"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="PollingCycle" type="xs:unsignedInt"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServiceInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="ServiceName" type="xs:string"/>
<xs:element name="ServiceLogo" type="xs:anyURI" minOccurs="0"/>
<xs:element name="ServiceDescription" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ResultCode" type="xs:string" use="required"/>
<xs:anyAttribute processContents="skip"/>
</xs:complexType>
【０５１２】
図３３は、本発明の一実施例に係るコンテンツ識別子の構文を示す図である。
【０５１３】
図３３は、本発明の一実施例に係るＡＴＳＣ標準に基づくコンテンツ識別子の構文を示す。ＡＴＳＣコンテンツ識別子は、受信機によって受信したコンテンツを識別するための識別子として用いることができる。
【０５１４】
また、図３３に示すコンテンツ識別子の構文は、図３２で説明した自動コンテンツ認識質疑結果フォーマットのコンテンツ識別子部の構文である。
【０５１５】
ＡＴＳＣコンテンツ識別子は、唯一の周期を有し、ＴＳＩＤ（Ｔｒａｎｓｍｉｔｔｉｎｇ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）及びハウスナンバーで構成された構造である。ハウスナンバーは、ここに制約された通り、ＴＳＩＤの保有者が所望するいずれかのナンバーである。ナンバーは、ＴＳＩＤのそれぞれの値に対して唯一である。ＡＴＳＣコンテンツ識別子構造の構文は、図３３に定義した通りである。
【０５１６】
１６ビットの符号無し整数フィールドであるＴＳＩＤは、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄの値を含むだろう。米国においてこの値の割当権限はＦＣＣにある。メキシコ、カナダ、米国に対する範囲は、これら国家間の公式協約によって設定された。他の地域の値は任意の権限によって設定される。
【０５１７】
５ビットの符号無し整数であるｅｎｄ＿ｏｆ＿ｄａｙフィールドは、放送日が終了するＵＴＣでその日の時間と設定されるはずであり、暫くしてｃｏｎｔｅｎｔ＿ｉｄ値がｕｎｉｑｕｅ＿ｆｏｒによって再使用されうる。このフィールドの値は、０乃至２３の範囲にあるだろう。このとき、このフィールドの値は放送局ごとに固定されると予想される。
【０５１８】
９ビットの符号無し整数であるｕｎｉｑｕｅ＿ｆｏｒフィールドは、日数と設定され、最後桁の数が切り上げられ、ｃｏｎｔｅｎｔ＿ｉｄ値が他のコンテンツに再割当されないｅｎｄ＿ｏｆ＿ｄａｙが示す時間に関して測定される。その値は１乃至５１１の範囲にあるだろう。０は禁止されるだろう。５１１は”無期限”という特別な意味がある。このとき、このフィールドの値は、ハウスナンバリング方法が変更される時にのみ変更され、放送局ごとに本質的に固定されると予想される。また、デコーダは、ｕｎｉｑｕｅ＿ｆｏｒフィールドが満了するまで、記憶されたｃｏｎｔｅｎｔ＿ｖａｌｕｅｓを唯一のものと取扱うことができ、これは、記憶された全てのｕｎｉｑｕｅ＿ｆｏｒフィールドが０になるまで、ｅｎｄ＿ｏｆ＿ｄａｙに毎日１ずつ減少させることによって実行できる。
【０５１９】
可変長フィールドであるｃｏｎｔｅｎｔ＿ｉｄフィールドは、ハウスナンバーシステムやＴＳＩＤの値のためのシステムによって識別子の値に設定できる。このような各値は、ｅｎｄ＿ｏｆ＿ｄａｙ及びｕｎｉｑｕｅ＿ｆｏｒフィールドの値によって設定された唯一の期間内で他のコンテンツに割り当てることができない。当該識別子は、人が読み取りでき、及び／又は２進値のいずれかの組合せになることができ、２４２バイトを越えないようにハウスナンバーの形態と完全に一致する必要はない。
【０５２０】
また、本発明の一実施例に係る受信機が、図３３に示したコンテンツ識別子の構文からサービスを全世界的に唯一に識別できない場合、本発明の一実施例に係る受信機は、グローバルサービス識別子を用いてサービスを識別することができる。本発明の一実施例に係るグローバルサービス識別子は、図３２で説明した自動コンテンツ認識質疑結果フォーマットのコンテンツ識別子部に含めることができる。
【０５２１】
以下、［例示１］は、本発明の一実施例に係るＵＲＩフォーマットのグローバルサービス識別子を示す。［例示１］のグローバルサービス識別子は、ＡＴＳＣ−Ｍ／Ｈサービスのために用いることができる。
【０５２２】
［例示１］urn:oma:bcast:iauth:atsc:service:<region>:<xsid>:<serviceid>
【０５２３】
＜ｒｅｇｉｏｎ＞は、ＩＳＯ ６３９−２によって特定されたような２文字国際国家コードである。
【０５２４】
＜ｘｓｉｄ＞は、当該地域で定義された通り、ローカルサービスに対してはＴＳＩＤの１０進エンコーディングと定義される。＜ｘｓｉｄ＞は、地域サービスに対しては（ｍａｊｏｒ＞６９）、”０”と定義される。
【０５２５】
＜ｓｅｒｖｉｃｅｉｄ＞は、＜ｍａｊｏｒ＞．＜ｍｉｎｏｒ＞と定義される。ここで、＜ｍａｊｏｒ＞は主チャネルナンバーを示すことができ、＜ｍｉｎｏｒ＞は副チャネルナンバーを示すことができる。
【０５２６】
上述したグローバルサービス識別子は、次のようなＵＲＩフォーマットで表現することができる。
【０５２７】
［例示２］urn:oma:bcast:iauth:atsc:service:us:1234:5.1
【０５２８】
［例示３］urn:oma:bcast:iauth:atsc:service:us:0:100.200
【０５２９】
また、本発明の一実施例に係る受信機は、上述したグローバルサービス識別子に基づいて、グローバルコンテンツ識別子を用いてコンテンツを識別することができる。
【０５３０】
以下、［例示４］は、本発明の一実施例に係るＵＲＩフォーマットのグローバルコンテンツ識別子を示す。［例示４］のグローバルサービス識別子は、ＡＴＳＣサービスのために用いることができる。具体的に、［例示４］は、本発明の一実施例に係るグローバルコンテンツ識別子としてＡＴＳＣコンテンツ識別子が用いられた場合を示す。
【０５３１】
［例示４］
urn:oma:bcast:iauth:atsc:content:<region>:<xsidz>:<contentid>:<unique_for>:<end_of_day>
【０５３２】
＜ｒｅｇｉｏｎ＞は、ＩＳＯ ６３９−２［４］によって特定されたような２文字国際国家コードである。
【０５３３】
＜ｘｓｉｄｚ＞は、当該地域で定義された通り、ローカルサービスに対してはＴＳＩＤの１０進エンコーディングと定義される。ここには、放出する放送局が＜ｓｅｒｖｉｃｅｉｄ＞を使用せず、グローバルコンテンツ識別子の唯一性を保障できない限り、”．”＜ｓｅｒｖｉｃｅｉｄ＞が続く。＜ｘｓｉｄｚ＞は、地域サービスに対しては（ｍａｊｏｒ＞６９）、＜ｓｅｒｖｉｃｅｉｄ＞と定義される。
【０５３４】
両者の場合で、＜ｓｅｒｖｉｃｅｉｄ＞は、セクションＡ１でコンテンツを伝達するサービスに対して定義された通りである。＜ｃｏｎｔｅｎｔ＿ｉｄ＞は、ｃｏｎｔｅｎｔ＿ｉｄフィールドを２進列（ｂｉｎａｒｙ  ｓｔｒｉｎｇ）と考慮した図３３で定義したｃｏｎｔｅｎｔ＿ｉｄフィールドのｂａｓｅ６４［５］エンコーディングである。＜ｕｎｉｑｕｅ＿ｆｏｒ＞は、図３３で定義したｕｎｉｑｕｅ＿ｆｏｒフィールドの１０進エンコーディングである。＜ｅｎｄ＿ｏｆ＿ｄａｙ＞は、図３３で定義したｅｎｄ＿ｏｆ＿ｄａｙフィールドの１０進エンコーディングである。
【０５３５】
上述した例示の通りに定義されたフォーマットを持つＡＴＳＣコンテンツ識別子を、自動コンテンツ認識処理システム上でコンテンツを識別するために用いることができる。
【０５３６】
以下、本発明の一実施例に係る図３４及び図３５と関連して、ウォーターマーキング及びフィンガープリンティング技術を具現できるように設計された受信機を説明する。図３４及び図３５の構成は設計者の意図によって変更されてもよい。
【０５３７】
図３４は、本発明の一実施例に係る受信機の構造を示す図である。
【０５３８】
具体的に、図３４は、ウォーターマーキングを用いて自動コンテンツ認識へースＥＴＶサービスを支援する受信機の構成の一例を示す。
【０５３９】
図３４に示すように、本発明の一実施例に係る自動コンテンツ認識へースＥＴＶサービスを支援する受信機は、入力データプロセッサ、ＡＴＳＣメインサービスプロセッサ、ＡＴＳＣ ＭＨ（ｍｏｂｉｌｅ  ｈａｎｄｈｅｌｄ）サービスプロセッサ、及び／又は自動コンテンツ認識サービスプロセッサを含むことができる。入力データプロセッサは、チューナー／復調器４００及び／又は残留側波帯デコーダ４０１を含むことができる。ＡＴＳＣメインサービスプロセッサは、トランスポートプロトコル（ＴＰ）デマルチプレクサ４０２、非実時間ガイド情報プロセッサ４０３、ＤＳＭ−ＣＣ（ｄｉｇｉｔａｌ  ｓｔｏｒａｇｅ  ｍｅｄｉａ  ｃｏｍｍａｎｄａｎｄ  ｃｏｎｔｒｏｌ）アドレス指定可能セクションパーサー４０４、ＩＰ／ＵＤＰ（ｉｎｆｏｒｍａｔｉｏｎ  ｐｒｏｖｉｄｅｒ／ｕｓｅｒ  ｄａｔａｇｒａｍ  ｐｒｏｔｏｃｏｌ）パーサー４０５、ＦＬＵＴＥ（ｆｉｌｅ  ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  ｔｒａｎｓｐｏｒｔ）パーサー４０６、メタデータモジュール４０７、ファイルモジュール４０８、ＥＳＧ（ｅｌｅｃｔｒｏｎｉｃ  ｓｅｒｖｉｃｅ  ｇｕｉｄｅ）／ＤＣＤ（ｄａｔａ  ｃａｒｒｉｅｒ  ｄｅｔｅｃｔ）ハンドラー４０９、記憶制御モジュール４１０、ファイル／トランスポートプロトコルスイッチ４１１、再生制御モジュール４１２、第１記憶装置４１３、インターネットプロトコルパケット記憶制御モジュール４１４、インターネット接続制御モジュール４１５、インターネットプロトコルインターフェース４１６、ライブレコーディングスイッチ４１７、ファイル（オブジェクト）デコーダ４１８、トランスポートプロトコル／ＰＥＳ（ｐａｃｋｅｔｉｚｅｄ  ｅｌｅｍｅｎｔａｒｙ  ｓｔｒｅａｍ）デコーダ４２０、ＰＳＩ（ｐｒｏｇｒａｍ  ｓｐｅｃｉｆｉｃ  ｉｎｆｏｒｍａｔｉｏｎ）／ＰＳＩＰ（ｐｒｏｇｒａｍ  ａｎｄ  ｓｙｓｔｅｍ  ｉｎｆｏｒｍａｔｉｏｎ  ｐｒｏｔｏｃｏｌ）デコーダ４２１、及び／又はＥＰＧ（ｅｌｅｃｔｒｏｎｉｃ  ｐｒｏｇｒａｍ  ｇｕｉｄｅ）ハンドラー４２２を含むことができる。ＡＴＳＣ ＭＨサービスプロセッサは、メイン／ＭＨ／非実時間スイッチ４１９、ＭＨベースバンドプロセッサ４２３、ＭＨ物理的適応プロセッサ４２４、インターネットプロトコルスタック４２５、ファイルハンドラー４２６、ＥＳＧハンドラー４２７、第２記憶装置４２８、及び／又はストリーミングハンドラー４２９を含むことができる。自動コンテンツ認識サービスプロセッサは、メイン／ＭＨ／非実時間スイッチ４１９、オーディオ／ビデオデコーダ４３０、オーディオ／ビデオ処理モジュール４３１、外部入力ハンドラー４３２、ウォーターマーク抽出器４３３、及び／又はアプリケーション４３４を含むことができる。
【０５４０】
次に、各プロセッサの各モジュールの動作について説明する。
【０５４１】
入力データプロセッサで、チューナー／復調器４００は、アンテナから受信した放送信号をチューニング及び復調することができる。この過程によって、残留側波帯シンボルを抽出することができる。残留側波帯デコーダ４０１は、チューナー／復調器４００によって抽出された残留側波帯シンボルをデコーディングすることができる。
【０５４２】
残留側波帯デコーダ４０１は、デコーディングによるＡＴＳＣメインサービスデータ及びＭＨサービスデータを出力することができる。ＡＴＳＣメインサービスデータはＡＴＳＣメインサービスプロセッサに伝達されて処理され、ＭＨサービスデータはＡＴＳＣ ＭＨサービスプロセッサに伝達されて処理されうる。
【０５４３】
ＡＴＳＣメインサービスプロセッサは、ＭＨ信号を除くメインサービスデータを自動コンテンツ認識サービスプロセッサに伝達するためにメインサービス信号を処理することができる。トランスポートプロトコルデマルチプレクサ４０２は、残留側波帯信号を介して送信されたＡＴＳＣメインサービスデータの送信パケットを逆多重化して他の処理モジュールに伝達することができる。すなわち、トランスポートプロトコルデマルチプレクサ４０２は、放送信号のエレメントがそれぞれ放送受信機のモジュールによって処理されるように、伝送パケットに含まれた様々な情報を逆多重化して伝達することができる。逆多重化されたデータは、実時間ストリーム、ＤＳＭ−ＣＣアドレス指定可能セクション、及び／又は非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを含むことができる。より具体的に、図３４に示すように、トランスポートプロトコルデマルチプレクサ４０２は、実時間ストリームをライブレコーディングスイッチ４１７に出力でき、ＤＳＭ−ＣＣアドレス指定可能セクションをＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４に出力でき、非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを非実時間ガイド情報プロセッサ４０３に出力することができる。
【０５４４】
非実時間ガイド情報プロセッサ４０３は、トランスポートプロトコルデマルチプレクサ４０２から非実時間サービステーブル／Ａ／９０＆９２シグナリングテーブルを受信し、ＦＬＵＴセッション情報を抽出してＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４に伝達することができる。ＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４は、トランスポートプロトコルデマルチプレクサ４０２からＤＳＭ−ＣＣアドレス指定可能セクションを受信し、非実時間ガイド情報プロセッサ４０３からＦＬＵＴセッション情報を受信し、ＤＳＭ−ＣＣアドレス指定可能セクションを処理することができる。ＩＰ／ＵＤＰパーサー４０５は、ＤＳＭ−ＣＣアドレス指定可能セクションパーサー４０４からデータ出力を受信し、ＩＰ／ＵＤＰによって伝送されたＩＰデータグラムをパーシングすることができる。ＦＬＵＴＥパーサー４０６は、ＩＰ／ＵＤＰパーサー４０５から出力されたデータを受信し、ＡＬＣ（ａｓｙｎｃｈｒｏｎｏｕｓ  ｌａｙｅｒｅｄ  ｃｏｄｉｎｇ）オブジェクトの形態で伝送されたデータサービスを伝送するためのＦＬＵＴＥデータを処理することができる。メタデータモジュール４０７及びファイルモジュール４０８は、ＦＬＵＴＥパーサー４０６から出力されたデータを受信し、メタデータ及び復元されたファイルを処理することができる。ＥＳＧ／ＤＣＤハンドラー４０９は、メタデータモジュール４０７から出力されたデータを受信し、放送プログラムに関連した電子サービスガイド及び／又は下りリンクチャネル記述語を処理することができる。復旧されたファイルは、レファレンスフィンガープリント及びＡＴＳＣ ２．０コンテンツのようなファイルオブジェクトの形態で記憶制御モジュール４１０に伝達されうる。ファイルオブジェクトは、記憶制御モジュール４１０によって処理され、正常ファイル及びトランスポートプロトコルファイルに分離されて第１記憶装置４１３に記憶されうる。再生制御モジュール４１２は、記憶されたファイルオブジェクトを更新し、ファイルオブジェクトをファイル／トランスポートプロトコルスイッチ４１１に伝達して、正常ファイル及びトランスポートプロトコルファイルをデコーディングすることができる。ファイル／トランスポートプロトコルスイッチ４１１は、正常ファイル及びトランスポートプロトコルファイルが互いに異なる経路を通じてデコーディングされるように、正常ファイルはファイルデコーダ４１８に伝達し、トランスポートプロトコルファイルはライブレコーディングスイッチ４１７に伝達する。
【０５４５】
ファイルデコーダ４１８は、正常ファイルをデコーディングして自動コンテンツ認識サービスプロセッサに伝達することができる。デコーディングされた正常ファイルは、自動コンテンツ認識サービスプロセッサのメイン／ＭＨ／非実時間スイッチ４１９に伝達することができる。トランスポートプロトコルファイルは、ライブレコーディングスイッチ４１７の制御下に、トランスポートプロトコル／ＰＥＳデコーダ４２０に伝達することができる。トランスポートプロトコル／ＰＥＳデコーダ４２０は、トランスポートプロトコルファイルをデコーディングし、ＰＳＩ／ＰＳＩＰデコーダ４２１は、デコーディングされたトランスポートプロトコルファイルを再びデコーディングする。ＥＰＧハンドラー４２２は、デコーディングされたトランスポートプロトコルファイルを処理し、ＡＴＳＣによってＥＰＧサービスを処理することができる。
【０５４６】
ＡＴＳＣ ＭＨサービスプロセッサは、ＡＴＳＣ ＭＨサービスデータを自動コンテンツ認識サービスプロセッサに送信するためにＭＨ信号を処理することができる。より具体的に、ＭＨベースバンドプロセッサ４２３は、ＡＴＳＣ ＭＨサービスデータを送信に適したパルス波形に切り替えることができる。ＭＨ物理的適応プロセッサ４２４は、ＡＴＳＣ ＭＨサービスデータをＭＨ物理的階層に適した形態として処理することができる。
【０５４７】
インターネットプロトコルスタック４２５は、ＭＨ物理的適応プロセッサ４２４から出力されたデータを受信し、インターネット送信／受信のための通信プロトコルによって処理することができる。ファイルハンドラー４２６は、インターネットプロトコルスタック４２５から出力されたデータを受信し、応用階層のファイルを処理することができる。ＥＳＧハンドラー４２７は、ファイルハンドラー４２６から出力されたデータを受信し、モバイルＥＳＧを処理することができる。また、第２記憶装置４２８は、ファイルハンドラー４２６から出力されたデータを受信し、ファイルオブジェクトを記憶することができる。また、インターネットプロトコルスタックモジュール４２５から出力されたデータの一部は、ＡＴＳＣによるモバイルＥＳＧサービスの代わりに受信機の自動コンテンツ認識サービスのためのデータになり得る。この場合、ストリーミングハンドラー４２９は、ＲＴＰ（ｒｅａｌ−ｔｉｍｅ  ｔｒａｎｓｐｏｒｔ  ｐｒｏｔｏｃｏｌ）を通して受信されたリアルストリーミングを処理して自動コンテンツ認識サービスプロセッサに伝達することができる。
【０５４８】
自動コンテンツ認識サービスプロセッサのメイン／ＭＨ／非実時間スイッチ４１９は、ＡＴＳＣメインサービスプロセッサ及び／又はＡＴＳＣ ＭＨサービスプロセッサから出力された信号を受信することができる。オーディオ／ビデオデコーダ４３０はメイン／ＭＨ／非実時間スイッチ４１９から受信された圧縮オーディオ／ビデオデータをデコーディングすることができる。デコーディングされたオーディオ／ビデオデータは、オーディオ／ビデオ処理モジュール４３１に伝達できる。
【０５４９】
外部入力ハンドラー４３２は、外部入力を通して受信されたオーディオ／ビデオコンテンツを処理してオーディオ／ビデオ処理モジュール４３１に伝送することができる。
【０５５０】
オーディオ／ビデオ処理モジュール４３１は、オーディオ／ビデオデコーダ４３０及び／又は外部入力ハンドラー４３２から受信されたオーディオ／ビデオデータを処理してスクリーンに表示することができる。この場合、ウォーターマーク抽出器４３３は、オーディオ／ビデオデータからウォーターマークの形態で挿入されたデータを抽出することができる。抽出されたウォーターマークデータは、アプリケーション４３４に伝達できる。アプリケーション４３４は、自動コンテンツ認識機能に基づくエンハンスメントサービスを提供し、放送コンテンツを確認し、そこに関連したエンハンスメントデータを提供することができる。アプリケーション４３４がエンハンスメントデータをオーディオ／ビデオ処理モジュール４３１に伝達すると、オーディオ／ビデオ処理モジュール４３１は、受信したオーディオ／ビデオデータを処理して画面に表示することができる。
【０５５１】
具体的には、図３４に示すウォーターマーク抽出器４３３は、外部入力を介して受信されたオーディオ／ビデオデータから、ウォーターマークの形態で挿入されたデータ（又は、ウォーターマーク）を抽出することができる。ウォーターマーク抽出器４３３は、オーディオデータからウォーターマークを抽出したり、ビデオデータからウォーターマークを抽出したり、又はオーディオデータ及びビデオデータからウォーターマークを抽出することができる。ウォーターマーク抽出器４３３は、抽出されたウォーターマークからチャネル情報及び／又はコンテンツ情報を取得することができる。
【０５５２】
本発明の一実施例に係る受信機は、ウォーターマーク抽出器４３３が取得したチャネル情報及び／又はコンテンツ情報を用いて、ＡＴＳＣ ＭＨチャネルをチューニングし、当該コンテンツ及び／又はメタデータを受信することができる。また、本発明の一実施例に係る受信機は、インターネットを通して当該コンテンツ及び／又はメタデータを受信することもできる。その後、受信機は、トリガーなどを用いて、受信したコンテンツ及び／又はメタデータをディスプレイすることができる。
【０５５３】
図３５は、本発明の他の実施例に係る受信機の構造を示す図である。
【０５５４】
より具体的には、図３５は、ウォーターマーキングを用いて自動コンテンツ認識へースＥＴＶサービスを支援する受信機の構成の一例を示す。
【０５５５】
図３５に示す本発明の一実施例に係る受信機の基本構造は、図３４に図示された受信機に基本構造と同一である。ただし、図３５に示す受信機は、本発明の一実施例によってフィンガープリント抽出器５３５及び／又はフィンガープリント比較器５３６をさらに含むことができるという相違点がある。また、図３５に示す受信機は、図３４に示した構成エレメントのうち、ウォーターマーク抽出器４３３を含めなくてもよい。
【０５５６】
図３５の基本的な構成は、図３４に示した受信機の基本的な構成と同一であり、その説明を省略する。以下、フィンガープリント抽出器５３５及び／又はフィンガープリント比較器５３６を中心に受信機の動作を説明する。
【０５５７】
フィンガープリント抽出器５３５は、外部入力を介して受信されたＡ／Ｖコンテンツに挿入されたデータ（又は、シグネチャー）を抽出することができる。本発明の一実施例に係るフィンガープリント抽出器５３５は、オーディオコンテンツからシグネチャーを抽出したり、ビデオコンテンツからシグネチャーを抽出したり、又はオーディオコンテンツ及びビデオコンテンツからシグネチャーを抽出することができる。
【０５５８】
フィンガープリント比較器５３６は、Ａ／Ｖコンテンツから抽出されたシグネチャーを用いてチャネル情報及び／又はコンテンツ情報を取得することができる。本発明の一実施例に係るフィンガープリント比較器５３６は、ローカルサーチ（ｌｏｃａｌ  ｓｅａｒｃｈ）及び／又は遠隔サーチ（ｒｅｍｏｔｅ  ｓｅａｒｃｈ）によってチャネル情報及び／又はコンテンツ情報を取得することができる。
【０５５９】
具体的には、図３５に示すように、フィンガープリント比較器５３６が記憶装置５３７にアクセスして動作するルートをローカルサーチという。また、図３５に示すように、フィンガープリント比較器５３６がインターネット接続制御モジュール５３８にアクセスして動作するルートを遠隔サーチという。以下、ローカルサーチ及び遠隔サーチについて説明する。
【０５６０】
本発明の一実施例に係るローカルサーチによれば、フィンガープリント比較器５３５は、抽出されたシグネチャーと記憶装置５３７に記憶された基準フィンガープリントとを比較することができる。基準フィンガープリントは、フィンガープリント比較器５３６が抽出されたシグネチャーを処理するためにさらに受信するデータである。
【０５６１】
具体的には、フィンガープリント比較器５３６は、抽出されたシグネチャーと基準フィンガープリントとをマッチングさせて両者が同一であるか否か比較し、チャネル情報及び／又はコンテンツ情報を取得することができる。
【０５６２】
比較の結果、抽出されたシグネチャーと基準フィンガープリントとが同一である場合、フィンガープリント比較器５３６は、比較の結果をアプリケーションに伝達することができる。アプリケーションは、比較の結果を用いて、抽出されたシグネチャーと関連したチャネル情報及び／又はコンテンツ情報を受信機に伝達することができる。
【０５６３】
比較の結果、抽出されたシグネチャーと基準フィンガープリントとがマッチングしないか、又は基準フィンガープリントが不足している場合、フィンガープリント比較器５３６は、ＡＴＳＣ ＭＨチャネルを介して新しい基準フィンガープリントを受信することができる。その後、フィンガープリント比較器５３６は、抽出されたシグネチャーと基準フィンガープリントとを再び比較することができる。
【０５６４】
また、本発明の一実施例に係る遠隔サーチによれば、フィンガープリント比較器５３６は、インターネット上のシグネチャーデータベースサーバーからチャネル情報及び／又はコンテンツ情報を受信することができる。
【０５６５】
具体的には、フィンガープリント比較器５３６は、インターネット接続制御モジュール５３８を介してインターネットに接続してシグネチャーデータベースサーバーにアクセスすることができる。その後、フィンガープリント比較器５３６は、抽出されたシグネチャーをクエリーパラメータとしてシグネチャーデータベースサーバーに伝達することができる。
【０５６６】
全て放送局が一つの統合されたシグネチャーデータベースサーバーを用いる場合、フィンガープリント比較器５３６は、当該シグネチャーデータベースサーバーにクエリーパラメータを伝達することができる。放送局が個別にシグネチャーデータベースサーバーを運営する場合、フィンガープリント比較器５３６は、それぞれのシグネチャーデータベースにクエリーパラメータを伝達することができる。又は、フィンガープリント比較器５３６は、２つ以上のシグネチャーデータベースサーバーに同時にクエリーパラメータを伝達することもできる。
【０５６７】
本発明の一実施例に係る受信機は、フィンガープリント比較器５３６が取得したチャネル情報及び／又はコンテンツ情報を用いて、ＡＴＳＣ Ｍ／Ｈチャネルをチューニングし、該当のコンテンツ及び／又はメタデータを受信することができる。その後、受信機は、トリガーなどを用いて、受信されたコンテンツ及び／又はメタデータをディスプレイすることができる。
【０５６８】
図３６は、本発明の一実施例に係るデジタル放送システムを示す図である。
【０５６９】
具体的には、図３６は、パーソナリゼーションサービス（個人化サービス）のためのデジタル放送受信機（又は、受信機）を含む個人化放送システムを示す。本発明の一実施例に係る個人化サービスは、使用者情報に基づいて使用者に適したコンテンツを選別して提供するサービスである。また、本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０或いは個人化されたサービスを提供する次世代放送サービスを提供することができる。
【０５７０】
本発明では、使用者情報の一実施例として、使用者のプロファイル、人口統計及び興味情報（又は、ＰＤＩデータ）を定義する。以下では、個人化放送システムの構成エレメントについて説明する。
【０５７１】
アンケートに対する回答（ａｎｓｗｅｒ）は、総合すると、使用者のプロファイル、人口統計、興味（ＰＤＩ；ｐｒｏｆｉｌｅｓ、ｄｅｍｏｇｒａｐｈｉｃｓ、ａｎｄ  ｉｎｔｅｒｅｓｔｓ）を示す。アンケート及び特定使用者によって与えられた回答を要約したデータ構造は、ＰＤＩアンケート又はＰＤＩテーブルと呼ばれる。データ構造は、使用可能なとき、回答を含むことができるが、ＰＤＩテーブルは、ネットワーク、放送局、又はコンテンツプロバイダによって提供されるため、回答データを含まない。ＰＤＩテーブルにおいてエントリーの質問（ｑｕｅｓｔｉｏｎ）部分は、非公式的に、”ＰＤＩ−質問”又は”ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する回答は、非公式的に、”ＰＤＩ−Ａ”と呼ばれる。フィルタ基準の集合は、非公式的に、”ＰＤＩ−ＦＣ”と呼ばれる。
【０５７２】
ＡＴＳＣ ２．０可能受信機のようなクライアント装置は、アンケートで質問に対する回答の生成を可能にする機能を含む（ＰＤＩ−Ａインスタンス）。このＰＤＩ生成機能は、ＰＤＩ−Ｑインスタンスを入力として用い、ＰＤＩ−Ａインスタンスを出力として生成する。ＰＤＩ−Ｑインスタンス及びＰＤＩ−Ａインスタンスの両方とも、受信機の不揮発性記憶装置に記憶される。クライアントは、ＰＤＩ−ＡインスタンスとＰＤＩ−ＦＣインスタンスとを比較し、どのコンテンツアイテムがダウンロード及び使用に適合するかを決定するフィルタリング機能を提供する。
【０５７３】
図示のように、サービスプロバイダ側では、ＰＤＩテーブルを維持及び分配するための機能が施行される。コンテンツと共にコンテンツメタデータが生成される。メタデータの一部がＰＤＩテーブルにおいて質問に基づくＰＤＩ−ＦＣインスタンスである。
【０５７４】
図３６に示すように、個人化放送システムは、コンテンツプロバイダ（又は、放送局）７０７及び／又は受信機７００を含むことができる。本発明の一実施例に係る受信機７００は、ＰＤＩエンジン７０１、フィルタリングエンジン７０２、ＰＤＩ記憶装置７０３、コンテンツ記憶装置７０４、宣言コンテンツモジュール７０５及び／又はＵＩモジュール（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ  ｍｏｄｕｌｅ）７０６を含むことができる。また、図３６に示すように、本発明の一実施例に係る受信機７００は、コンテンツプロバイダ７０７からコンテンツなどを受信することができる。上述した個人化放送システムの構造は設計者の意図によって変更されてもよい。
【０５７５】
本発明の一実施例に係るコンテンツプロバイダ７０７は、コンテンツ、ＰＤＩアンケート（ＰＤＩ  ｑｕｅｓｔｉｏｎｎａｉｒｅ）及び／又はフィルタリング基準を受信機７００に伝送することができる。アンケート及び特定使用者によって与えられた回答を要約したデータ構造はＰＤＩアンケートと呼ばれる。本発明の一実施例に係るＰＤＩアンケートは、使用者のプロファイル、人口統計、興味などに関する質問（又は、ＰＤＩ質問）を含むことができる。
【０５７６】
受信機７００は、コンテンツプロバイダ７０７から受信したコンテンツ、ＰＤＩアンケート及び／又はフィルタリング基準を処理することができる。以下、図３６に示す受信機７００に含まれたモジュールの動作を中心に説明する。
【０５７７】
本発明の一実施例に係るＰＤＩエンジン７０１は、まず、コンテンツプロバイダ７０７が提供するＰＤＩアンケートを受信することができる。ＰＤＩエンジン７０１は、受信したＰＤＩアンケートに含まれたＰＤＩ質問をＵＩモジュール７０６に伝達することができる。当該ＰＤＩ質問に関する使用者の入力がある場合、ＰＤＩエンジン７０１は、当該ＰＤＩ質問に対する使用者の回答とその他の情報（以下、ＰＤＩ回答）をＵＩモジュール７０６から受信することができる。その後、ＰＤＩエンジン７０１は、個人化サービスを提供するためにＰＤＩ質問及びＰＤＩ回答を処理してＰＤＩデータを生成することができる。すなわち、本発明の一実施例に係るＰＤＩデータは、上述したＰＤＩ質問及び／又はＰＤＩ回答を含むことができる。したがって、ＰＤＩアンケートに対するＰＤＩ回答は、総合すると、使用者のプロファイル、人口統計、興味（又は、ＰＤＩ）を表す。
【０５７８】
また、本発明の一実施例に係るＰＤＩエンジン７０１は、受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。具体的には、ＰＤＩエンジン７０１は、ＰＤＩ回答のＩＤを用いて、ＰＤＩデータを削除、追加及び／又は修正することができる。本発明の一実施例に係るＰＤＩ回答のＩＤの具体的な内容は後述する。また、他のモジュールでＰＤＩデータの受信を要求する場合、ＰＤＩエンジン７０１は、当該要求に適したＰＤＩデータを当該モジュールに伝達することができる。
【０５７９】
本発明の一実施例に係るフィルタリングエンジン７０２は、ＰＤＩデータとフィルタリング基準によってコンテンツをフィルタリングすることができる。フィルタリング基準とは、ＰＤＩデータを用いて使用者に適したコンテンツのみをフィルタリングするための基準（フィルタリング基準）の集合を意味する。具体的には、フィルタリングエンジン７０２は、ＰＤＩエンジン７０１からＰＤＩデータを受信することができ、コンテンツプロバイダ７０７からコンテンツ及び／又はフィルタリング基準を受信することができる。また、コンテンツプロバイダ７０７は、宣言コンテンツに関するパラメータを伝送する時、当該宣言コンテンツと関連したフィルタリング基準テーブルを併せて伝送することができる。その後、フィルタリングエンジン７０２は、フィルタリング基準とＰＤＩデータとをマッチングさせて比較し、比較の結果を用いてコンテンツをフィルタリングしてダウンロードすることができる。ダウンロードしたコンテンツは、コンテンツ記憶装置７０４に記憶することができる。フィルタリング方法及びフィルタリング基準に関する具体的な内容は、図３８及び図３９で後述する。
【０５８０】
本発明の一実施例に係るＵＩモジュール７０６は、ＰＤＩエンジン７０１から受信したＰＤＩ質問をディスプレイし、当該ＰＤＩ質問に対して使用者からＰＤＩ回答を受信することができる。使用者は、ディスプレイされたＰＤＩ質問に対してリモコンを用いてＰＤＩ回答を受信機７００側に伝達することができる。ＵＩモジュール７０６は、受信したＰＤＩ回答をＰＤＩエンジン７０１に伝達することができる。
【０５８１】
本発明の一実施例に係る宣言コンテンツモジュール７０５は、ＰＤＩエンジン７０１にアクセスしてＰＤＩデータを取得することができる。また、図３６に示すように、宣言コンテンツモジュール７０５は、コンテンツプロバイダ７０７が提供する宣言コンテンツを受信することができる。本発明の一実施例に係る宣言コンテンツは、受信機７００で実行されるアプリケーションに関するコンテンツであって、ＴＤＯのようなＤＯを含むことができる。
【０５８２】
また、図３６には示していないが、本発明の一実施例に係る宣言コンテンツモジュール７０５は、ＰＤＩ記憶装置７０３にアクセスしてＰＤＩ質問及び／又はＰＤＩ回答を取得することができる。この場合、宣言コンテンツモジュール７０５は、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を用いることができる。具体的には、宣言コンテンツモジュール７０５はＡＰＩを用いてＰＤＩ記憶装置７０３を検索（ｒｅｔｒｉｅｖｅ）することによって、少なくとも一つ以上のＰＤＩ質問を取得することができる。その後、宣言コンテンツモジュール７０５は、ＵＩモジュール７０６を介してＰＤＩ質問を伝達したり、又はＰＤＩ回答を受信し、受信したＰＤＩ回答をＰＤＩ記憶装置７０３に伝達することができる。
【０５８３】
本発明の一実施例に係るＰＤＩ記憶装置７０３は、ＰＤＩ質問及び／又はＰＤＩ回答を記憶することができる。
【０５８４】
本発明の一実施例に係るコンテンツ記憶装置７０４は、フィルタリングされたコンテンツを記憶することができる。
【０５８５】
上述した通り、図３６に示すＰＤＩエンジン７０１は、コンテンツプロバイダ７０７からＰＤＩアンケート（Ｑｕｅｓｔｉｏｎｎａｉｒｅ）を受信することができる。受信機７００は、ＵＩモジュール７０６を介して受信したＰＤＩアンケートのＰＤＩ質問をディスプレイし、当該ＰＤＩ質問に対するＰＤＩ回答を使用者から受信することができる。ＰＤＩエンジン７０１は、ＰＤＩ質問及び／又はＰＤＩ回答を含むＰＤＩデータをフィルタリングエンジン７０２に伝達することができる。フィルタリングエンジン７０２は、ＰＤＩデータとフィルタリング基準を用いてコンテンツをフィルタリングすることができる。したがって、受信機７００は、フィルタリングされたコンテンツを使用者に提供することによって個人化サービスを具現することができる。
【０５８６】
図３７は、本発明の他の実施例に係るデジタル放送システムを示す図である。
【０５８７】
具体的には、図３７は、個人化サービスのための受信機を含む個人化放送システムの構造を示すものである。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０サービスを提供することができる。以下では、個人化放送システムの構成エレメントについて説明する。
【０５８８】
図３７に示すように、個人化放送システムは、コンテンツプロバイダ（又は、放送局）８０７及び／又は受信機７００を含むことができる。本発明の一実施例に係る受信機８００は、ＰＤＩエンジン８０１、フィルタリングエンジン８０２、ＰＤＩ記憶装置８０３、コンテンツ記憶装置８０４、宣言コンテンツモジュール８０５、ＵＩモジュール８０６、使用モニタリングエンジン８０８及び／又は使用ログモジュール８０９を含むことができる。また、図３６に示すように、本発明の一実施例に係る受信機は、コンテンツプロバイダ８０７からコンテンツなどを受信することができる。図３７の基本的なモジュールは、図３６のモジュールと同一であり、但し、図３７の放送システムは、使用モニタリングエンジン８０８及び／又は使用ログモジュール８０９をさらに含む点が図３６の放送システムと異なる。上述した個人化放送システムの構造は設計者の意図によって変更されてもよい。以下、使用モニタリングエンジン８０８及び使用ログモジュール８０９を中心に説明する。
【０５８９】
本発明の一実施例に係る使用ログモジュール８０９は、使用者の放送サービス使用内訳に関する情報（又は、ヒストリー情報）を記憶することができる。ヒストリー情報は２つ以上の使用データを含むことができる。本発明の一実施例に係る使用データは、一定時間で使用者がどのような放送サービスを用いたかに関する情報を意味する。具体的には、使用データは、午後９時にニュースを４０分間視聴したという情報、午後１１時に恐怖映画をダウンロードしたという情報などを含むことができる。
【０５９０】
本発明の一実施例に係る使用モニタリングエンジン８０８は、使用者の放送サービス使用現況を持続してモニタリングすることができる。その後、使用モニタリングエンジン８０８は、モニタリング結果を用いて、使用ログモジュール８０９に記憶された使用データを削除、追加及び／又は修正することができる。また、本発明の一実施例に係る使用モニタリングエンジン８０８は使用データをＰＤＩエンジン８０１に伝達でき、ＰＤＩエンジン８０１は、伝達されてきた使用データを用いてＰＤＩデータを更新することができる。
【０５９１】
図３８は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０５９２】
具体的には、図３８は、図３６及び図３７で説明した個人化放送システムのフィルタリングエンジン及びＰＤＩエンジンの動作を示すフローチャートである。
【０５９３】
図３８に示すように、本発明の一実施例に係る受信機９００は、フィルタリングエンジン９０１及び／又はＰＤＩエンジン９０２を含むことができる。以下、本発明の一実施例に係るフィルタリングエンジン９０１及びＰＤＩエンジン９０２の動作を説明する。上述した受信機の構造は設計者の意図によって変更されてもよい。
【０５９４】
図３６で説明した通り、コンテンツをフィルタリングするために、本発明の一実施例に係る受信機９００はフィルタリング基準とＰＤＩデータとをマッチングさせて比較することができる。
【０５９５】
具体的に、本発明の一実施例に係るフィルタリングエンジン９０１は、コンテンツプロバイダからフィルタリング基準を受信し、ＰＤＩエンジン９０２にＰＤＩデータを要求する信号（又は、ＰＤＩデータ要求信号）を伝達することができる。本発明の一実施例に係るＰＤＩエンジン９０２は、受信したＰＤＩデータ要求信号によって、当該ＰＤＩデータ要求信号に対応するＰＤＩデータを検索することができる。
【０５９６】
図３８に示すフィルタリングエンジン９０１は、基準ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を含むＰＤＩデータ要求信号をＰＤＩエンジン９０２に伝達することができる。上述した通り、フィルタリング基準は、フィルタリング基準の集合であり、それぞれのフィルタリング基準は、フィルタリング基準を識別するための基準ＩＤを含むことができる。また、本発明の一実施例に係る基準ＩＤは、ＰＤＩ質問及び／又はＰＤＩ回答を識別するために用いることができる。
【０５９７】
ＰＤＩデータ要求信号を受信したＰＤＩエンジン９０２は、ＰＤＩ記憶装置にアクセスしてＰＤＩデータを検索することができる。本発明の一実施例に係るＰＤＩデータは、ＰＤＩ質問及び／又はＰＤＩ回答を識別するためのＰＤＩデータＩＤを含むことができる。図３８に示すＰＤＩエンジン９０２は、基準ＩＤとＰＤＩデータＩＤとをマッチングさせ、基準ＩＤとＰＤＩデータＩＤとが同一であるか否かを比較することができる。
【０５９８】
マッチングの結果、基準ＩＤとＰＤＩデータＩＤとが同一であり、これに対する値が同一である場合、受信機９００は、該当のコンテンツをダウンロードすることができる。具体的には、本発明の一実施例に係るフィルタリングエンジン９０１は、コンテンツをダウンロードするためのダウンロード要求信号をコンテンツプロバイダに伝達することができる。
【０５９９】
マッチングの結果、基準ＩＤとＰＤＩデータＩＤとが同一でない場合、図３８に示すように、ＰＤＩエンジン９０２はフィルタリングエンジン９０１にヌル（ｎｕｌｌ）ＩＤ（ｉｄｅｎｔｉｆｉｅｒ）を伝達することができる。ヌルＩＤを受信したフィルタリングエンジン９０１は、新しいＰＤＩデータ要求信号をＰＤＩエンジン９０２に伝達することができる。この場合、新しいＰＤＩデータ要求信号は、新しい基準ＩＤを含むことができる。
【０６００】
本発明の一実施例に係る受信機９００は、上述の方法によって、フィルタリング基準に含まれた全てのフィルタリング基準とＰＤＩデータとをマッチングさせることができる。マッチングの結果、全てのフィルタリング基準がＰＤＩデータとマッチングする場合、フィルタリングエンジン９０１は、コンテンツをダウンロードするためのダウンロード要求信号をコンテンツプロバイダに伝達することができる。
【０６０１】
図３９は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０６０２】
具体的には、図３９は、図３６及び図３７で説明した個人化放送システムにおけるフィルタリングエンジン及びＰＤＩエンジンの動作を示すフローチャートである。
【０６０３】
図３９に示すように、本発明の一実施例に係る受信機１０００は、フィルタリングエンジン１００１及び／又はＰＤＩエンジン１００２を含むことができる。上述した受信機の構造は設計者の意図によって変更されてもよい。図３９に示すフィルタリングエンジン１００１及びＰＤＩエンジン１００２の基本的な動作は、図３８で説明したものと同一である。
【０６０４】
ただし、フィルタリング基準とＰＤＩデータとのマッチングの結果、基準ＩＤとＰＤＩデータＩＤとが同一でない場合、図３９に示す受信機１０００は、該当のコンテンツをダウンロードしないことを一実施例とすることができる。
【０６０５】
具体的には、本発明のフィルタリングエンジン１００１は、ヌルＩＤを受信する場合、新しいＰＤＩデータ要求信号をＰＤＩエンジン１００２に伝達しないことを一実施例とすることができる。また、フィルタリング基準に含まれた全てのフィルタリング基準がＰＤＩデータとマッチングされない場合、本発明のフィルタリングエンジン１００１は、ダウンロード要求信号をコンテンツプロバイダに伝達しないことを一実施例とすることができる。
【０６０６】
図４０は、本発明の一実施例に係るＰＤＩテーブルを示す図である。
【０６０７】
上述した図３６の個人化放送システムは、個人化サービスを提供するためにＰＤＩデータを使用する。ＰＤＩデータは、ＰＤＩテーブル形式で処理することができる。アンケート及び特定使用者によって与えられた回答を要約したデータ構造は、ＰＤＩアンケート又はＰＤＩテーブルと呼ばれる。データ構造は、使用可能な時に回答を含むことができるが、ＰＤＩテーブルは、ネットワーク、放送局、又はコンテンツプロバイダによって提供されることから、回答データを含まない。ＰＤＩテーブルでエントリーの質問部分は、非公式的に、”ＰＤＩ−質問”又は”ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する回答は、非公式的に、”ＰＤＩ−Ａ”と呼ばれる。フィルタ基準の集合は、非公式的に、”ＰＤＩ−ＦＣ”と呼ばれる。本発明のＰＤＩテーブルはＸＭＬスキーマで表現されることを一実施例とする。本発明の一実施例に係るＰＤＩテーブルのフォーマットは、設計者の意図によって変更されてもよい。
【０６０８】
図４０に示すように、本発明の一実施例に係るＰＤＩテーブルは、属性（ａｔｔｒｉｂｕｔｅｓ）１１１０及び／又はＰＤＩタイプエレメントを含むことができる。本発明の一実施例に係る属性１１１０は、ｔｒａｎｓａｃｔｉｏｎａｌ（取引）属性１１００、ｔｉｍｅ（時間）属性１１０１を含むことができる。本発明の一実施例に係るＰＤＩタイプエレメントは、ＱＩＡ（Ｑｕｅｓｔｉｏｎ  ｗｉｔｈ  Ｉｎｔｅｇｅｒ  Ａｎｓｗｅｒ）エレメント１１０２、ＱＢＡ（Ｑｕｅｓｔｉｏｎ  ｗｉｔｈ  Ｂｏｏｌｅａｎ  Ａｎｓｗｅｒ）エレメント１１０２、ＱＳＡ（Ｑｕｅｓｔｉｏｎ  ｗｉｔｈ  Ｓｅｌｅｃｔｉｏｎ  Ａｎｓｗｅｒ）エレメント１１０４、ＱＴＡ（Ｑｕｅｓｔｉｏｎ  ｗｉｔｈ  Ｔｅｘｔ  Ａｎｓｗｅｒ）エレメント１１０５及び／又はＱＡＡ（Ｑｕｅｓｔｉｏｎ  ｗｉｔｈ  Ａｎｙ−ｆｏｒｍａｔ  Ａｎｓｗｅｒ）エレメント１１０６を含むことができる。以下、図４０に示すＰＤＩテーブルの構成エレメントについて説明する。
【０６０９】
具体的には、図４０に示す属性１１１０は、本発明の一実施例に係るＰＤＩテーブル自体の属性情報を示すことができる。そのため、ＰＤＩテーブルが含むＰＤＩタイプエレメントが変わっても、属性１１１０は、本発明の一実施例に係るＰＤＩテーブルに同一に表現されうる。例えば、本発明の一実施例に係るｔｒａｎｓａｃｔｉｏｎａｌ属性１１００は、ＰＤＩ質問の目的に関する情報を示すことができる。本発明の一実施例に係るｔｉｍｅ属性１１０１は、ＰＤＩテーブルが生成されたりアップデートされた時間に関する情報を示すことができる。この場合、それぞれ異なるＰＤＩタイプエレメントを含むＰＤＩテーブルは、ＰＤＩタイプエレメントが変わってもｔｒａｎｓａｃｔｉｏｎａｌ属性１１００及び／又はｔｉｍｅ属性１１０１を含むことができる。
【０６１０】
また、本発明の一実施例に係るＰＤＩテーブルは、ルートエレメント（ｒｏｏｔ  ｅｌｅｍｅｎｔ）として１つ又は２つ以上のＰＤＩタイプエレメント１１０２を含むことができる。この場合、ＰＤＩタイプエレメント１１０２は、リスト形式で表現されてもよい。
【０６１１】
本発明の一実施例に係るＰＤＩタイプエレメントは、ＰＤＩ回答のタイプによって区別できる。例えば、本発明の一実施例に係るＰＤＩタイプエレメントは、”ＱｘＡ”エレメントと呼ぶことができ、この場合、”ｘ”は、ＰＤＩ回答のタイプによって決定することができる。本発明の一実施例に係るＰＤＩ回答のタイプは、整数タイプ、ブール（Ｂｏｏｌｅａｎ）タイプ、選択タイプ、テキストタイプ、及びこれら４つのタイプ以外のいずれかの形態の回答を含むタイプを含むことができる。
【０６１２】
本発明の一実施例に係るＱＩＡエレメント１１０３は、一つのＰＤＩ質問及び／又は当該ＰＤＩ質問に対する整数タイプのＰＤＩ回答を含むことができる。
【０６１３】
本発明の一実施例に係るＱＢＡエレメント１１０４は、一つのＰＤＩ質問及び／又は当該ＰＤＩ質問に対するブールタイプのＰＤＩ回答を含むことができる。
【０６１４】
本発明の一実施例に係るＱＳＡエレメント１１０５は、一つのＰＤＩ質問及び／又は当該ＰＤＩ質問に対する多重選択（ｓｅｌｅｃｔｉｏｎ）タイプのＰＤＩ回答を含むことができる。
【０６１５】
本発明の一実施例に係るＱＴＡエレメント１１０６は、一つのＰＤＩ質問及び／又は当該ＰＤＩ質問に対する文字列（ｔｅｘｔ）タイプのＰＤＩ回答を含むことができる。
【０６１６】
本発明の一実施例に係るＱＡＡエレメント１１０７は、一つのＰＤＩ質問及び／又は当該ＰＤＩ質問に対する整数、ブール、多重選択及び文字列形態以外の形態のＰＤＩ回答を含むことができる。
【０６１７】
図４１は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６１８】
具体的には、図４１は、図４０で説明したＰＤＩタイプエレメントのうち、ＱＩＡエレメントのＸＭＬスキーマを示す図である。
【０６１９】
図４１に示すように、ＱＩＡエレメントは、ＰＤＩ質問タイプと関連した特徴に関する情報を示す属性１２１０、ｉｄ属性１２２０、質問エレメント１２３０及び／又は回答エレメント１２４０を含むことができる。
【０６２０】
具体的には、本発明の一実施例に係る属性１２１０は、ＰＤＩ質問の言語を示すｌａｎｇ属性を含むことができる。また、本発明の一実施例に係るＱＩＡエレメントの属性１２１０は、ＰＤＩ回答が有し得る最小の整数値を示すｍｉｎＩｎｃｌｕｓｉｖｅ属性１２３０、及び／又はＰＤＩ回答が有し得る最大の整数値を示すｍａｘＩｎｃｌｕｓｉｖｅ属性１２４０を含むことができる。
【０６２１】
また、本発明の一実施例に係るｉｄ属性１２２０は、ＰＤＩ質問及び／又はＰＤＩ回答を識別するのに用いることができる。
【０６２２】
また、本発明の一実施例に係る質問エレメント１２３０は、ＰＤＩ質問自体を含むことができる。図４１に示すように、質問エレメント１２３０は、ＰＤＩ質問に関する情報を示す属性を含むことができる。例えば、質問エレメント１２３０は、ＰＤＩ質問が生成された時間又はＰＤＩ質問が伝送された時間を示すｔｉｍｅ属性１２３１及び／又はＰＤＩ質問の有効時間を示すｅｘｐｉｒａｔｉｏｎ（満了）属性１２３２を含むことができる。
【０６２３】
また、本発明の一実施例に係る回答エレメント１２４０は、ＰＤＩ回答自体を含む。図４１に示すように、回答エレメント１２４０は、ＰＤＩ回答に関する情報を示した属性を含むことができる。例えば、図４１に示すように、回答エレメント１２４０は、それぞれのＰＤＩ回答を認識するために使用可能なｉｄ属性１２４１及び／又はそれぞれのＰＤＩ回答が生成されたり修正された時間を示すｔｉｍｅ属性１２４２を含むことができる。
【０６２４】
図４２は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６２５】
具体的には、図４２は、図４０で説明したＰＤＩタイプエレメントのうち、ＱＢＡエレメントのＸＭＬスキーマを示す図である。
【０６２６】
図４２に示すように、ＱＢＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは図４１で説明した通りであり、その具体的な説明は省略する。
【０６２７】
図４３は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６２８】
具体的には、図４３は、図４０で説明したＰＤＩタイプエレメントのうち、ＱＳＡエレメントのＸＭＬスキーマを示す図である。
【０６２９】
図４３に示すＱＳＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは図４１で説明した通りであり、その具体的な説明は省略する。
【０６３０】
ただし、多重選択質問の特性によって、本発明の一実施例に係るＱＳＡエレメントの属性は、ｍｉｎＣｈｏｉｃｅ属性１４１１及び／又はｍａｘＣｈｏｉｃｅ属性１４１２をさらに含むことができる。本発明の一実施例に係るｍｉｎＣｈｏｉｃｅ属性１４１１は、使用者が選択できるＰＤＩ回答の最小個数を示すことができる。本発明の一実施例に係るｍａｘＣｈｏｉｃｅ属性１４１２は、使用者が選択できるＰＤＩ回答の最大個数を示すことができる。
【０６３１】
図４４は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６３２】
具体的には、図４４は、図４０で説明したＰＤＩタイプエレメントのうち、ＱＡＡエレメントのＸＭＬスキーマを示す図である。
【０６３３】
図４４に示すように、ＱＡＡエレメントを示しているＸＭＬスキーマの基本的な構成エレメントは図４１で説明した通りであり、その具体的な説明は省略する。
【０６３４】
図４５は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６３５】
具体的には、図４５は、図４０乃至図４４で説明したＰＤＩテーブルと同様に、ＰＤＩテーブルの拡張されたフォーマットをＸＭＬスキーマで示す図である。
【０６３６】
上述した通り、本発明では、個人化サービスを提供するためにＰＤＩテーブルを使用することを一実施例とする。しかし、同一の使用者であっても、使用者の属した状況によって好むコンテンツが変わることがある。
【０６３７】
そこで、本発明では、上述した問題点を解決するために、ＰＤＩテーブルに、使用者の状況情報を示す構成エレメントをさらに含むことを一実施例とすることができる。
【０６３８】
図４５に示すＰＤＩテーブルは、使用者の状況情報を示す構成エレメントとして状況エレメント１６００をさらに含むことができる。図４５に示すＰＤＩテーブルの基本的なＸＭＬスキーマは、図４０乃至図４４で説明した通りであり、具体的な説明は省略する。以下、状況エレメント１６００を説明する。
【０６３９】
本発明の一実施例に係る状況エレメント１６００は、使用者の状況情報として時間帯及び／又は位置に関する情報を示すことができる。図４５に示すように、状況エレメント１６００は、時間エレメント１６１０、位置エレメント１６２０及び／又は使用者の状況情報を示すその他のエレメントをさらに含むことができる。以下、各エレメントを説明する。
【０６４０】
本発明の一実施例に係る時間エレメント１６１０は、使用者の属した地域の時間と関連した情報を含むことができる。例えば、本発明の一実施例に係る時間エレメント１６１０は、”ｙｙｙｙ−ｍｍ−ｄｄ”形式の時間情報を示すｔｉｍｅ属性１６１１及び／又は使用者の属した地域の時間帯を示すｔｉｍｅｚｏｎｅ属性１６１２を含むことができる。
【０６４１】
本発明の一実施例に係る位置エレメント１６２０は、使用者が属している地域の位置情報を含むことができる。例えば、図４５に示すように、場所エレメント１６２０は、当該位置の情報を示すｌｏｃａｔｉｏｎ−ｄｅｓｃ属性１６２１、当該位置の緯度情報を示すｌａｔｉｔｕｄｅ属性１６２２及び／又は当該位置の経度情報を示すｌｏｎｇｉｔｕｄｅ属性１６２３を含むことができる。
【０６４２】
図４６は、本発明の他の実施例に係るＰＤＩテーブルを示す図である。
【０６４３】
具体的には、図４６は、本発明の実施例に対して図４０乃至図４５を参照して説明したＸＭＬスキマーでＰＤＩテーブルを示す。
【０６４４】
図４６は、ＰＤＩテーブルと呼ばれるルートエレメントに対するＸＭＬスキマー定義であり、ＰＤＩテーブルインスタンスドキュメントの構造を定義する。本発明の実施例によれば、ＰＤＩテーブルインスタンスドキュメントは、ＰＤＩテーブルをＸＭＬスキマーで実現することによって得られる実際ドキュメントを意味する。
【０６４５】
図４６は、ＰＤＩアプリケーションプログラミングインターフェース（ＡＰＩ）を用いてＤＯ及び根源的な受信機の間で伝達可能な個別質問を示すルートエレメントＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ又はＱＡＡに対するＸＭＬスキマー定義を示す。本実施例に係るＰＤＩ  ＡＰＩが具体的に記述される。図４６に示すエレメントは、名前空間“ｈｔｔｐ：／／ｗｗｗ．ａｔｓｃ．ｏｒｇ／ＸＭＬＳｃｈｅｍａｓ／ｉｓｓ／ｐｄｉ／１”を有するＸＭＬスキマーの定義に従うことができる。
【０６４６】
ＰＤＩ質問（又はＰＤＩ−Ｑ）及びＰＤＩ答弁（又はＰＤＩ−Ａ）間の差異は、スキマー自体よりはむしろ使用規則で特定される。ＴＤＩテーブル内のエントリーの質問部分は、非公式的に”ＰＤＩ質問”又は”ＰＤＩ−Ｑ”と呼ばれる。与えられたＰＤＩ質問に対する答弁は、非公式的に”ＰＤＩ−Ａ”と呼ばれる。例えば、スキマーが様々なタイプの質問の”ｑ”エレメントに対してｍｉｎＯｃｃｕｒｓ＝”０”を示すが、スキマーがＰＤＩ−Ｑに用いられると、この場合の”ｑ”エレメントの使用は義務的である。スキマーがＰＤＩ−Ａに用いられると、”ｑ”エレメントを含むことは選択的である。
【０６４７】
ＰＤＩ−Ｑインスタンスドキュメントは、その名前空間でＡＴＳＣ２．０標準の一部である”ＰＤＩテーブル”ＸＭＬスキマーにしたがうことができ、その定義は、任意の差異の場合、ここに提供される説明に優先する。本発明の実施例によれば、ＰＤＩ−Ｑインスタンスドキュメントは、ＰＤＩ−Ｑを含むＰＤＩテーブルをＸＭＬスキマーで実現することによって得られる実際ドキュメントである。
【０６４８】
ＰＤＩ−Ｑインスタンスドキュメントは、ＱＩＡ（ｉｎｔｅｇｅｒ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、ＱＢＡ（Ｂｏｏｌｅａｎ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、ＱＳＡ（ｓｅｌｅｃｔｉｏｎ−ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）及び／又はＱＴＡ（ｔｅｘｔｕａｌ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）の一つ以上のエレメントで構成される。
【０６４９】
それらの上位レベルエレメントの”Ａ”（答弁）下位エレメントがＰＤＩ−Ｑインスタンスに存在しなくてもよい。
【０６５０】
これらの各エレメント内の識別子属性（”ｉｄ”）は、ＰＤＩ−Ａインスタンスドキュメント内の該当のエレメントに対する基準又はリンクとして機能することができる。本発明の実施例によれば、ＰＤＩ−Ａインスタンスドキュメントは、ＰＤＩ−Ａを含むＰＤＩテーブルをＸＭＬスキマーで実現することによって得られる実際ドキュメントである。
【０６５１】
ＰＤＩ−Ａインスタンスドキュメントは、その名前空間でＡＴＳＣ２．０標準の一部である”ＰＤＩテーブル”ＸＭＬスキマーにしたがうことができ、その定義は、任意の差異の場合、ここに提供される説明に優先する。
【０６５２】
ＰＤＩ−Ａインスタンスドキュメントは、ＱＩＡ（ｉｎｔｅｇｅｒ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、ＱＢＡ（Ｂｏｏｌｅａｎ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、ＱＳＡ（ｓｅｌｅｃｔｉｏｎ−ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、ＱＴＡ（ｔｅｘｔｕａｌ−ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）、及び／又はＱＡＡ（ａｎｙ−ｆｏｒｍａｔ  ａｎｓｗｅｒ  ｔｙｐｅ  ｑｕｅｓｔｉｏｎ）の一つ以上のエレメントで構成される。
【０６５３】
これらの各エレメントは、少なくとも一つの”Ａ”（答弁）下位エレメントを有する。それらは任意の”Ｑ”（質問ストリング）下位エレメントを含まなくてもよい。
【０６５４】
これらの各エレメント内の識別子属性（”ｉｄ”）は、ＰＤＩ−Ｑインスタンスドキュメント内の該当のエレメントに対する基準又はリンクとして機能することができる。
【０６５５】
以下、図４６に示すＰＤＩテーブル内に含まれるエレメント及び属性のセマンティックスを説明する。
【０６５６】
図４６に示すように、本実施例に係るＰＤＩテーブルで、”＠”は属性名の前に表示されて属性及びエレメントを区別することができる。
【０６５７】
本実施例に係るＰＤＩテーブルは、ＰＤＩタイプエレメントを含むことができる。具体的に、ＰＤＩタイプエレメントは、図４０を参照して説明したように、ＱＩＡエレメント、ＱＢＡエレメント、ＱＳＡエレメント、ＱＴＡエレメント及び／又はＱＡＡエレメントを含むことができる。
【０６５８】
図４６に示すように、本実施例に係るＰＤＩテーブルは、質問タイプエレメントにかかわらずにｐｒｏｔｏｃｏｌｖｅｒｓｉｏｎ属性、ｐｄｉｔａｂｌｅｉｄ属性、ｐｉｄｔａｂｌｅｖｅｒｓｉｏｎ属性及び／又はｔｉｍｅ属性を含むことができる。
【０６５９】
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ及び／又はＱＡＡエレメントのｉｄ属性は、それらエレメントのそれぞれの満了属性と同様に、いずれも同じセマンティックスを有する。同様に、Ｑエレメントのそれぞれのｌａｎｇ属性は、Ａエレメントの各時間属性のように、同じセマンティックスを有する。また、ｉｄ属性は、図３８を参照して説明したＰＤＩデータ識別子を意味することができる。
【０６６０】
ＰＤＩＴａｂｌｅエレメントは、一つ以上の質問エレメントのリストを含む。それらはそれぞれ、ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ又はＱＡＡのフォーマットである。基数（０，…，Ｎ）を有する＜チョイス＞構成の使用は、任意の数のＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ及びＱＡＡエレメントが任意の順序で表示可能であるということを意味する。
【０６６１】
ＰＤＩＴａｂｌｅエレメントのｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ属性は、２ ｈｅｘ数字で構成される。上位４ビットは、テーブル定義のメジャーバージョン番号を示す。下位４ビットは、テーブル定義のマイナーバージョン番号を示す。この標準のこのバージョンに対するメジャーバージョン番号は１に設定される。受信機は、支援しないメインバージョン値を示すＰＤＩのインスタンスを廃棄することが予想される。標準のこのバージョンに対するマイナーバージョン番号は０に設定される。受信機は、支援されないマイナーバージョン値を示すＰＤＩのインスタンスを廃棄しないことが予想される。この場合、支援されない任意の個別エレメント又は属性を無視することが予想される。
【０６６２】
ＰＤＩＴａｂｌｅエレメントのｐｄｉＴａｂｌｅＩｄ属性は、このＰＤＩテーブルエレメントのグローバルユニーク識別子であってもよい。
【０６６３】
ＰＤＩＴａｂｌｅエレメントの８ビットを有するｐｄｉＴａｂｌｅＶｅｒｓｉｏｎ属性は、このＰＤＩテーブルエレメントのバージョンを示す。初期値は０であってもよい。値は、このＰＤＩテーブルエレメントが変更される度に１ずつ増加してもよく、２５５の次に０に戻る。
【０６６４】
ＰＤＩＴａｂｌｅエレメントのｔｉｍｅ属性は、このＰＤＩテーブル内の任意の質問に対する最も最近の変更の日時を示す。
【０６６５】
ＱＩＡエレメントは、質問の整数答弁タイプを示す。これは、答弁の最大及び最小の許容値を特定する選択的な制限を含む。
【０６６６】
ＱＩＡのＱＩＡ．ｌｏＥｎｄ属性は、このＱＩＡエレメントの”Ａ”下位エレメントの最小可能値を示す。すなわち、”Ａ”エレメントの値はｌｏＥｎｄに比べて小さくない。ｌｏＥｎｄ属性が存在しないと、最小がないことを示す。
【０６６７】
ＱＩＡのＱＩＡ．ｈｉＥｎｄ属性は、このＱＩＡエレメントの”Ａ”下位エレメントの最大可能値を示す。すなわち、答弁の値はｈｉＥｎｄに比べて大きくない。ｈｉＥｎｄ属性が存在しないと、最大がないことを示す。
【０６６８】
ＱＩＡ．Ｑエレメントは、ＱＩＡエレメントの下位エレメントである。ＱＩＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、整数タイプ答弁を有するように表現されなければならない。このエレメントの複数のインスタンスがそれぞれ別個の言語で存在してもよい。
【０６６９】
ＱＩＡエレメントの下位エレメントとしてのＱＩＡ．Ａエレメントは、整数値を有することができる。ＱＩＡ．Ａエレメントは、ＱＩＡ．Ｑで質問に対する答弁を示すことができる。
【０６７０】
ＱＢＡエレメントは、質問のブール答弁タイプを示す。
【０６７１】
ＱＢＡ．Ｑエレメントは、ＱＢＡエレメントの下位エレメントである。ＱＢＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、答弁のはい／いいえ又は真／偽タイプを有するように表現されてもよい。このエレメントの複数のインスタンスがそれぞれ別個の言語で存在してもよい。
【０６７２】
ＱＢＡエレメントの下位エレメントとしてのＱＢＡ．Ａエレメントは、ブール（Ｂｏｏｌｅａｎ）値を有することができる。ＱＢＡ．Ａエレメントは、ＱＢＡ．Ｑで質問に対する答弁を示すことができる。
【０６７３】
ＱＳＡエレメントは、質問の選択答弁タイプを示す。
【０６７４】
ＱＳＡエレメントのＱＳＡ．ｍｉｎＣｈｏｉｃｅｓ属性は、ユーザが行い得る選択の最小番号を特定することができる。
【０６７５】
ＱＳＡエレメントのＱＳＡ．ｍａｘＣｈｏｉｃｅｓ属性は、ユーザが行い得る選択の最大番号を特定することができる。
【０６７６】
ＱＳＡ．Ｑエレメントは、ＱＳＡエレメントの下位エレメントである。ＱＳＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、提供される選択チョイスの一つ以上に対応する答弁を有するように表現することができる。
【０６７７】
ＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎエレメントは、ＱＳＡ．Ｑエレメントの下位エレメントである。ＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎエレメントの値は、ユーザに提示される可能な選択を示すことができる。同じＱＳＡエレメントの複数のＱＳＡ．Ｑ下位エレメント（それぞれ別個の言語の）が存在すれば、それらはそれぞれ、同じ意味を有する同じ数の選択下位エレメントを有する。
【０６７８】
ＱＳＡ．Ｑ．ＳｅｌｅｃｔｉｏｎのＱＳＡ．Ｑ．Ｓｅｌｅｃｔｉｏｎ．ｉｄ属性は、ＱＳＡ．Ｑの範囲内の固有の選択エレメントに対する識別子であってもよい。同じＱＳＡエレメントの複数のＱＳＡ．Ｑ下位エレメント（別個の言語の）が存在すれば、同じ意味を有する該当の選択エレメントを有するその選択エレメントのｉｄ属性間に一対一対応が存在してもよい。
【０６７９】
ＱＳＡ．Ａは、ＱＳＡエレメントの下位エレメントである。ＱＳＡエレメントのこの下位エレメントのそれぞれのインスタンスは、選択のエレメントのうち一つのｉｄ値の形態でこの選択タイプ質問に対する一つの許容答弁を特定することができる。
【０６８０】
ＱＴＡエレメントは、質問のテキスト答弁（自由形態エントリー）タイプを示す。
【０６８１】
ＱＴＡ．Ｑエレメントは、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ｑエレメントの値は、ユーザに提示される質問ストリングを示すことができる。質問は、自由形態テキスト答弁を有するように表現されてもよい。
【０６８２】
ＱＴＡ．Ａエレメントは、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ａエレメントの値は、ＱＴＡ．Ｑ内の質問に対する答弁を示すことができる。
【０６８３】
ＱＡＡエレメントは、データベース内のエントリーのように様々なタイプの情報を維持するために用いることができる。
【０６８４】
ＱＡＡ．Ａエレメントは、ＱＡＡエレメントの下位エレメントである。ＱＡＡ．Ａエレメントの値は任意の形態の情報を含む。
【０６８５】
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ及びＱＡＡエレメントのｉｄ属性は、それが現れるエレメントに対するグローバルユニーク識別子であるＵＲＩであってもよい。
【０６８６】
ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ及びＱＡＡエレメントの満了エレメントは、それが現れたエレメントがそれ以上関連しないでテーブルから削除される日時を示す。
【０６８７】
ＱＩＡ．Ｑ、ＱＢＡ．Ｑ、ＱＳＡ．Ｑ、ＱＴＡ．Ｑ及びＱＴＡ．Ａエレメントのｌａｎｇ属性は、質問又は答弁ストリングの言語を示すことができる。ＱＳＡ．Ｑの場合、ｌａｎｇ属性はまた、ＱＳＡ．Ｑの選択下位エレメントの言語を示すことができる。Ｌａｎｇ属性が存在しないと、これは、言語が英語であることを示すことができる。
【０６８８】
ＱＩＡ．Ａ、ＱＢＡ．Ａ、ＱＳＡ．Ａ、ＱＴＡ．Ａ及びＱＡＡ．Ａエレメントのｔｉｍｅ属性は、答弁がテーブルに入力される日時を示すことができる。
【０６８９】
図４６には図示していないが、本実施例に係るＰＤＩテーブルは、ＱＩＡＤエレメント、ＱＢＡＤエレメント、ＱＳＡＤエレメント、ＱＴＡＤエレメント及び／又はＱＡＡＤエレメントをさらに含むことができる。上述したエレメントは総称してＱｘＡＤエレメントという。以下、ＱｘＡＤエレメントを説明する。
【０６９０】
ルートエレメントとしてのＱＩＡＤエレメントは、ＱＩＡ下位エレメント内の質問の整数答弁タイプを含む。ＱＩＡは、答弁の最大及び最小の許容値を特定する選択的制限を含む。
【０６９１】
ルートエレメントとしてのＱＢＡＤエレメントは、質問のブール答弁タイプを示す。
【０６９２】
ルートエレメントとしてのＱＳＡＤエレメントは、質問の選択答弁タイプを示す。
【０６９３】
ルートエレメントとしてのＱＴＡＤエレメントは、質問のテキスト答弁（自由形態エントリー）タイプを示す。
【０６９４】
ルートエレメントとしてのＱＡＡＤエレメントは、データベース内のエントリーのように、様々なタイプの情報を保持するために用いることができる。
【０６９５】
図４６には図示していないが、それぞれのＰＤＩタイプエレメントは、ＱＴｅｘｔエレメント及び／又はｔｉｍｅ属性をさらに含むことができる。
【０６９６】
ＱＩＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＩＡ．Ｑエレメントの下位エレメントである。ＱＩＡ．Ｑ．ＱＴｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示す。質問は、整数タイプ答弁を有するように表現されなければならない。
【０６９７】
ＱＩＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＩＡ．Ａエレメントの整数値属性である。ＱＩＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＩＡ．Ｑ．ＱＴｅｘｔエレメント内の質問に対する答弁を示す。
【０６９８】
ＱＢＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＢＡ．Ｑエレメントの下位エレメントである。ＱＢＡ．Ｑ．ＱＴｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示す。質問は、答弁のはい／いいえ又は真／偽タイプを有するように表現されなければならない。このエレメントの複数のインスタンスがそれぞれ別個の言語で存在してもよい。
【０６９９】
ＱＢＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＢＡ．Ａエレメントのブール値属性である。ＱＢＡ．Ａ．＠ａｎｓｗｅｒ属性は、ＱＢＡ．Ｑ．ＱＴｅｘｔエレメント内の質問に対する答弁を示す。
【０７００】
ＱＳＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＳＡ．Ｑエレメントの下位エレメントである。ＱＳＡ．Ｑ．ＱＴｅｘｔエレメントは、ユーザに提示される質問ストリングを示す。質問は、提供される選択チョイスの一つ以上に対応する答弁を有するように表現されなければならない。このエレメントの複数のインスタンスが別個の言語で存在してもよい。
【０７０１】
ＱＳＡ．Ａ下位エレメントのＱＳＡ．Ａ．ａｎｓｗｅｒ属性は、選択エレメントのうち一つのｉｄ値の形態でこの選択タイプ質問に対する一つの許容答弁を特定する。
【０７０２】
ＱＴＡ．Ｑ．ＱＴｅｘｔエレメントは、ＱＴＡ．Ｑエレメントの下位エレメントである。ＱＴＡ．Ｑ．ＱＴｅｘｔエレメントの値は、ユーザに提示される質問ストリングを示す。質問は、自由形態テキスト答弁を有するように表現されなければならない。
【０７０３】
ＱＴＡ．Ａ．ａｎｓｗｅｒ属性は、ＱＴＡエレメントの下位エレメントである。ＱＴＡ．Ａ．ａｎｓｗｅｒエレメントの値は、ＱＴＡ．Ｑ．ＱＴｅｘｔエレメント内の質問に対する答弁を示す。
【０７０４】
図４７は、本発明の他の実施例に係るＰＤＩテーブルを示す。
【０７０５】
具体的には、図４７は、図４０乃至４５を参照して説明したＸＭＬスキマーでＰＤＩテーブルの構造を示す。
【０７０６】
図４７に示すＰＤＩテーブルの基本構造及び基本エレメント及び属性のセマンティックスは、図４６と同一である。ただし、図４６に示すＰＤＩテーブルと違い、図４７のＰＤＩテーブルは、ｘａｃｔｉｏｎＳｅｔＩｄ属性及び／又はｔｅｘｔ属性をさらに含むことができる。以下、ｘａｃｔｉｏｎＳｅｔＩｄ属性及び／又はｔｅｘｔ属性についてＰＤＩテーブルを説明する。
【０７０７】
ＱｘＡエレメントのｘａｃｔｉｏｎＳｅｔＩｄ属性は、質問が質問のトランザクションセットに属することを示し、ここで、質問のトランザクションセットは、質問に答弁する目的で、単位として取り扱われるセットである。これはまた、質問の属するトランザクションセットに対する識別子を提供する。したがって、ｘａｃｔｉｏｎＳｅｔＩｄ属性の同じ値を有するＰＤＩテーブル内の全質問のセットは、”全体又はゼロ（ａｌｌ  ｏｒ  ｎｏｔｈｉｎｇ）”ベースで答弁されてもよい。
【０７０８】
ＱｘＡエレメントのｔｅｘｔ属性は、ＱｘＡ．Ｑエレメントの下位エレメントである。Ｔｅｘｔ属性の値は、ユーザに提示される質問ストリングを示すことができる。
【０７０９】
図４８は、本発明の一実施例に係るフィルタリング基準テーブルを示す図である。上述した図３６の個人化放送システムは、個人化サービスを提供するためにフィルタリング基準を使用することができる。図３６、図３８及び図３９で説明したフィルタリング基準は、フィルタリング基準テーブルの形式とすることができる。本発明のフィルタリング基準テーブルはＸＭＬスキーマで表現されることを一実施例とする。
【０７１０】
また、本発明のフィルタリング基準テーブルは、ＰＤＩデータとフィルタリング基準とを效率的に比較するために、ＰＤＩテーブルのフォーマットと類似のフォーマットを有することを一実施例とすることができる。本発明の一実施例に係るフィルタリング基準テーブルのフォーマットは、設計者の意図によって変更されてもよい。
【０７１１】
図４８に示すように、本発明の一実施例に係るフィルタリング基準テーブルは、フィルタリング基準（ｆｉｌｔｅｒｉｎｇ  ｃｒｉｔｅｒｉｏｎ）エレメント１９００を含むことができ、フィルタリング基準エレメント１９００は、識別子（ｉｄｅｎｔｉｆｉｅｒ）属性１９０１、基準タイプ（ｃｒｉｔｅｒｉｏｎ  ｔｙｐｅ）属性１９０２及び／又は基準値（ｃｒｉｔｅｒｉｏｎ  ｖａｌｕｅ）エレメント１９０３を含むことができる。本発明のフィルタリング基準は、上述したＰＤＩ質問に対応する概念として使われてもよい。以下、図４８に示すフィルタリング基準テーブルの構成エレメントについて説明する。
【０７１２】
本発明の一実施例に係るフィルタリング基準エレメント１９００は、ＰＤＩ質問に対応するフィルタリング基準を示すことができる。
【０７１３】
本発明の一実施例に係る識別子属性１９０１は、フィルタリング基準に対応するＰＤＩ質問を識別することができる。
【０７１４】
本発明の一実施例に係る基準タイプ属性１９０２は、フィルタリング基準のタイプを示すことができる。フィルタリング基準のタイプに関する具体的な内容は後述する。
【０７１５】
本発明の一実施例に係る基準値エレメント１９０３は、フィルタリング基準が有する値を示すことができる。各基準値は、ＰＤＩ質問に対する可能な回答である。
【０７１６】
具体的には、本発明に係るフィルタリング基準のタイプは、整数タイプ、ブールタイプ、選択タイプ、テキストタイプ及び／又は任意タイプのうち一つのタイプを一実施例とすることができる。
【０７１７】
整数タイプのフィルタリング基準（又は、整数タイプ基準）は、整数タイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
【０７１８】
ブールタイプのフィルタリング基準（又は、ブールタイプ基準）は、ブールタイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
【０７１９】
選択タイプのフィルタリング基準（又は、選択タイプ基準）は、選択タイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
【０７２０】
テキストタイプのフィルタリング基準（又は、テキストタイプ基準）は、テキストタイプのＰＤＩ回答に対応するフィルタリング基準を意味する。
【０７２１】
任意タイプのフィルタリング基準（又は、任意タイプ基準）は、上述した４つのタイプ以外のいずれかの形態のＰＤＩ回答に対応するフィルタリング基準を意味する。
【０７２２】
以下、［例示５」は、図４８に示すフィルタリング基準テーブルのＸＭＬスキーマを示す本発明の一実施例である。
【０７２３】
［例示５］
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="FilterCriterion" type="FilterCriterionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="FilterCriterionType">
<xs:sequence>
<xs:element name="CriterionValue" type="xs:base64Binary" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:anyURI" use="required"/>
<xs:attribute name="CriterionType" type="xs:unsignedByte" use="required"/>
</xs:complexType>
</xs:schema>
【０７２４】
図４９は、本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
【０７２５】
具体的には、図４９は、図４８で説明したフィルタリング基準テーブルの拡張されたフォーマットをＸＭＬスキーマで表現した図である。図４８に示すフィルタリング基準のＸＭＬスキーマによってフィルタリング基準テーブルを構成する場合、本発明の一実施例に係るフィルタリング基準のタイプと各タイプ別細部属性を設定できないという問題点がある。そこで、図４９では、フィルタリング基準のタイプを表現し、各タイプ別属性を設定したＸＭＬスキーマを提示する。本発明の一実施例に係る個人化放送システムは、図４９のＸＭＬスキーマによって構成されたフィルタリング基準テーブルを用いて、より精密にコンテンツをフィルタリングすることができる。
【０７２６】
図４９に示すように、フィルタリング基準テーブルは属性２０００及び／又はフィルタリング基準タイプエレメントを含むことができる。本発明の一実施例に係る属性２０００は、ｔｉｍｅ属性２００１を含むことができる。本発明の一実施例に係るフィルタリング基準タイプエレメントは、整数タイプ基準エレメント（Ｉｎｔｅｇｅｒ  Ｔｙｐｅ  Ｃｒｉｔｅｒｉｏｎエレメント）（又は、ＱＩＡ基準エレメント）２０１０、ブールタイプ基準エレメント（Ｂｏｏｌｅａｎ  Ｔｙｐｅ  Ｃｒｉｔｅｒｉｏｎエレメント）（又は、ＱＢＡ基準エレメント）２０２０、選択タイプ基準エレメント（Ｓｅｌｅｃｔｉｏｎ  Ｔｙｐｅ  Ｃｒｉｔｅｒｉｏｎ  ｅｌｅｍｅｎｔ）（又は、ＱＳＡ基準エレメント）２０３０、テキストタイプ基準エレメント（Ｔｅｘｔ  Ｔｙｐｅ  Ｃｒｉｔｅｒｉｏｎ  ｅｌｅｍｅｎｔ）（又は、ＱＴＡ基準エレメント）２０４０及び／又は任意タイプ基準エレメント（Ａｎｙ  Ｔｙｐｅ  Ｃｒｉｔｅｒｉｏｎ  ｅｌｅｍｅｎｔ）（又は、ＱＡＡ基準エレメント）２０５０を含むことができる。以下、図４９に示すフィルタリング基準テーブルの構成エレメントについて説明する。
【０７２７】
具体的には、図４９に示す属性２０００は、本発明の一実施例に係るフィルタリング基準テーブル自体の属性情報を示すことができる。したがって、フィルタリング基準テーブルが含むフィルタリング基準タイプエレメントが変わっても、同一に表現されうる。例えば、本発明の実施例に係るｔｉｍｅ属性２００１は、フィルタリング基準が生成された時間又は更新された時間を示すことができる。この場合、互いに異なるフィルタリング基準タイプエレメントを含むフィルタリング基準テーブルは、フィルタリング基準タイプエレメントが変わってもｔｉｍｅ属性２００１を含むことができる。
【０７２８】
また、本発明の一実施例に係るフィルタリング基準テーブルは、１つ又は２つ以上のフィルタリング基準タイプエレメントを含むことができる。本発明の一実施例に係るフィルタリング基準タイプエレメントは、フィルタリング基準のタイプを示すことができる。フィルタリング基準のタイプは、図４８で説明したものと同一である。この場合、フィルタリング基準タイプエレメントはリスト形式で表現されてもよい。
【０７２９】
本発明の一実施例に係るフィルタリング基準タイプエレメントは、”ＱｘＡ”基準と呼ぶことができ、この場合、”ｘ”は、フィルタリング基準のタイプによって決定することができる。
【０７３０】
図４９に示すように、それぞれのフィルタリング基準タイプエレメントは、識別子属性及び／又は基準値エレメントを含むことができる。図４９に示す識別子属性及び基準値エレメントの具体的な内容は、図４８で説明したものと同一である。
【０７３１】
ただし、図４９に示すように、整数タイプ基準エレメント２０１０は、ｍｉｎ ｉｎｔｅｇｅｒ属性２０１１及び／又はｍａｘ ｉｎｔｅｇｅｒ属性２０１２をさらに含むことができる。本発明の一実施例に係るｍｉｎ ｉｎｔｅｇｅｒ属性２０１１は、整数タイプの回答として表現されたフィルタリング基準の最小値を示すことができる。本発明の一実施例に係るｍａｘ ｉｎｔｅｇｅｒ属性２０１２は、整数タイプの回答として表現されたフィルタリング基準の最大値を示すことができる。
【０７３２】
また、図４９に示すように、ｓｅｌｅｃｔｉｏｎ ｔｙｐｅ ｃｒｉｔｅｒｉｏｎエレメント２０３０及び／又はｔｅｘｔ ｔｙｐｅ ｃｒｉｔｅｒｉｏｎエレメント２０４０は、ｌａｎｇ属性２０３１を含むことができる。本発明の一実施例に係るｌａｎｇ属性２０３１は、文字列形態で表現されたフィルタリング基準の値を示すことができる。
【０７３３】
次の［例示６」は、図４９に示すフィルタリング基準テーブルのＸＭＬスキーマを示す本発明の一実施例である。
【０７３４】
［例示６］
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="FilterCriteriaTable" type="FilterCriteriaTableType"/>
<xs:complexType name="FilterCriteriaTableType">
<xs:choice maxOccurs="unbounded">
<xs:element name="IntegerTypeCriterion" type="IntegerCriterionOption"/>
<xs:element name="BooleanTypeCriterion" type="BooleanCriterionOpntion"/>
<xs:element name="SelectionTypeCriterion" type="StringCriterionOption"/>
<xs:element name="TextTypeCriterion" type="StringCriterionOption"/>
<xs:element name="AnyTypeCriterion" type="AnyTypeCriterionOption"/>
</xs:choice>
<xs:attribute name="time" type="xs:dateTime"/>
</xs:complexType>
<xs:complexType name="IntegerCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="minInteger" type="xs:integer"/
<xs:attribute name="maxInteger" type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BooleanCriterionOpntion">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" type="xs:boolean"/>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="StringCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" default="EN-US"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnyTypeCriterionOption">
<xs:sequence>
<xs:element name="id" type="xs:anyURI"/>
<xs:sequence>
<xs:element name="CriterionValue" maxOccurs="unbounded"/>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="any" type="xs:anySimpleType"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:sequence>
</xs:sequence>
</xs:complexType></xs:schema>
【０７３５】
図５０は、本発明の他の実施例に係るフィルタリング基準テーブルを示す図である。
【０７３６】
具体的には、図５０は、図４８及び図４９で説明したＸＭＬスキーマによるフィルタリング基準テーブルの一実施例を示す図である。図５０に示すフィルタリング基準テーブルの基本的な構成エレメントは、図４８及び図４９で上述したものと同一である。以下、図５０に示すフィルタリング基準テーブルに含まれたエレメント及び属性のセマンティクスについて説明する。
【０７３７】
図５０に示すように、本発明の一実施例に係るフィルタリング基準テーブルでは、属性の名称の前に”＠”を表示することによって属性とエレメントを区別することができる。
【０７３８】
テーブルで＠ｉｄ属性が現れる各位置で、ＰＤＩテーブルで質問の＠ｉｄ属性があり、これで、＠ｉｄ属性が現れるフィルタリング基準に該当する質問を識別する。
【０７３９】
ＱＩＡ Ｃｒｉｔｅｒｉｏｎエレメントは、整数値を有する質問に該当するフィルタリング基準を表すはずである。
【０７４０】
ＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントが＠ｅｘｔｅｎｔエレメントを含まないと、これは、フィルタリング基準に該当する質問に対する整数回答を表すはずである。ＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントが＠ｅｘｔｅｎｔ属性を含むと、これは、質問に対する回答の数範囲の下位点を表すはずであり、＠ｅｘｔｅｎｔ属性はその範囲で整数の個数を表すはずである。
【０７４１】
ＱＢＡ Ｃｒｉｔｅｒｉｏｎエレメントは、ブール値を有する質問に該当するフィルタリング基準を表すはずである。
【０７４２】
ＱＢＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対するブール回答を表すはずである。
【０７４３】
ＱＳＡ Ｃｒｉｔｅｒｉｏｎエレメントは、選択値を有する質問に該当するフィルタリング基準を表すはずである。
【０７４４】
ＱＳＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対する選択回答の識別子を表すはずである。
【０７４５】
ＱＴＡ Ｃｒｉｔｅｒｉｏｎエレメントは、ストリング値を有する質問に該当するフィルタリング基準を表すはずである。
【０７４６】
ＱＴＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する質問に対するテキスト回答を表すはずである。
【０７４７】
ＱＡＡ Ｃｒｉｔｅｒｉｏｎエレメントは、質問無しでテキスト”回答”のみを有する”質問”に該当するフィルタリング基準を表すはずである。
【０７４８】
ＱＡＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位エレメントは、フィルタリング基準に該当する”質問”に対するテキスト”回答”を表すはずである。
【０７４９】
Ｆｉｌｔｅｒｉｎｇ Ｃｒｉｔｅｒｉａエレメントに一つのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントのみがあれば、Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値が（質問がＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントを含むエレメントのｉｄ属性によって示される）Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントを含むエレメントに該当する質問に対するＰＤＩ−Ａにおける質問の中の値と一致する場合、サービスやコンテンツアイテムがフィルタを通過するかに対するフィルタリング決定は”真”（はい）となり、そうでない場合、”偽”（いいえ）になるだろう。
【０７５０】
”ｅｘｔｅｎｔ”属性が存在するＱＩＡ ＣｒｉｔｅｒｉｏｎエレメントのＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ下位要素の場合、質問の値がＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅ及びｅｘｔｅｎｔ属性によって定義される区間に存在すると、Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値は、該当するＰＤＩ−Ａにおける回答のいずれかの値と一致すると見なされるはずである。
【０７５１】
Ｆｉｌｔｅｒｉｎｇ ＣｒｉｔｅｒｉａエレメントでＣｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの総数が１よりも大きいと、各Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅエレメントの値は、（ｉｄ値によって示されるように）Ｃｒｉｔｅｒｉｏｎ Ｖａｌｕｅがフィルタリング基準に該当する質問に対するＰＤＩ−Ａにおける回答のいずれかの値と一致する場合、”真”を答える中間用語と評価されるはずであり、そうでない場合、”偽”を答える中間用語と評価されるはずである。このような中間用語のうち、上位エレメント識別子（ＱＩＡ．ｉｄ、ＱＢＡ．ｉｄなど）の同一値を有する用語は、各ターゲット基準に対する中間結果を得るために論理和され、これらの中間結果は、最終結果を決定するために論理積されるはずである。最終結果が受信機に対して”真”と評価されると、これは関連コンテンツアイテムがフィルタを通過した旨を意味する。
【０７５２】
図５１は、本発明の他の実施例に係るフィルタリング基準テーブルを表す図である。
【０７５３】
具体的には、図５１に示すフィルタリング基準テーブルは、図５０に示すフィルタリング基準テーブルの拡張された構造を示す。図５１に示すフィルタリング基準テーブルの基本的な構成エレメントは、図５０で説明したものと同一である。以下、図５０で説明したフィルタリング基準テーブルとの差異点を中心に、図５１に示すフィルタリング基準テーブルを説明する。
【０７５４】
図５１に示すフィルタリング基準テーブルは、フィルタリング基準の集合の様々なインスタンスを許容する。それぞれの集合は、フィルタリング基準の様々なインスタンスを含む。それぞれのフィルタリング基準は、一部のフィルタリング基準に対して提供される複数の値を許容する。フィルタリング論理は、フィルタリング基準の集合の複数のインスタンスのうち、”ＯＲ”論理である。フィルタリング基準の各集合内で、フィルタリング論理は、同一のフィルタリング基準に対する複数の値のうち、”ＯＲ”論理であり、互いに異なるフィルタリング基準の中では”ＡＮＤ”論理である。
【０７５５】
例えば、フィルタリング基準が（（年齢（ａｇｅ）＝２０）及び（ジャンル（ｇｅｎｒｅ）＝”スポーツ（ｓｐｏｒｔ）”））であるか、（（年齢（ａｇｅ）＝１０）及び（ジャンル（ｇｅｎｒｅ）＝”アニメーション（ａｎｉｍａｔｉｏｎ）”））であれば、フィルタリング基準テーブルは、次の［例示７］のように表すことができる。
【０７５６】
［例示７］
<FilterCriteriaTable time="2012-09-03T09:30:47.0Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FilterCriterionSet>
<IntegerTypeCriterion id="abc.tv/age/">
<CriterionValue>20</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre/">
<CriterionValue>sport</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
<FilterCriterionSet>
<IntegerTypeCriterion id= "abc.tv/age/">
<CriterionValue>10</CriterionValue>
</IntegerTypeCriterion>
<TextTypeCriterion id = "abc.tv/genre//">
<CriterionValue>animation</CriterionValue>
</TextTypeCriterion>
</FilterCriterionSet>
</FilterCriteriaTable>
【０７５７】
図５２は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０７５８】
具体的には、図５２は、本発明の一実施例に係る受信機が放送網を介してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
【０７５９】
本発明の一実施例に係る個人化放送システムの基本的な構造は、図３６乃至図３９で説明したものと同一である。本発明の一実施例に係るＰＤＩテーブルは、図３８乃至図４７で説明したものと同一である。本発明の一実施例に係るフィルタリング基準テーブルは、図４８乃至図５１で説明したものと同一である。
【０７６０】
図５２に示すように、本発明の一実施例に係る個人化放送システムは、ＳＳＣ（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｃｈａｎｎｅｌ）２３００、ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）セッション２３１０、フィルタリングエンジン２３２０、ＰＤＩエンジン２３３０及び／又はＵＩ ２３４０を含むことができる。本発明の一実施例に係る受信機は、ＤＳＭ−ＣＣ（Ｄｉｇｉｔａｌ  Ｓｔｏｒａｇｅ  Ｍｅｄｉａ  Ｃｏｍｍａｎｄａｎｄ  Ｃｏｎｔｒｏｌ）セクションを介してＰＤＩテーブルを受信することができる。この場合、本発明の一実施例に係る受信機は、ＦＬＵＴＥセッション２３１０を通してＰＤＩテーブルを受信することができる。上述した個人化放送システムの構造は設計者の意図によって変更されてもよい。以下、図５２に示す各構成エレメントの動作について説明する。
【０７６１】
本発明の一実施例に係る受信機は、まず、ＳＳＣ ２３００を通してＰＤＩテーブルセクションを受信することができる。具体的には、本発明の一実施例に係る受信機は、ＤＳＭ−ＣＣセクションを通して受信されるＩＰデータグラムのうち、ＳＳＣ ２３００に該当するＩＰデータグラムをパーシングしてＰＤＩテーブルセクションを受信することができる。この場合、本発明の一実施例に係る受信機は、ＳＳＣ ２３００が有する周知のＩＰアドレス及び／又はＵＤＰポートナンバーを用いてＰＤＩテーブルセクションを受信することができる。本発明の一実施例に係るＰＤＩテーブルセクションは、ＰＤＩテーブルを放送網を介して伝達するために、本発明の一実施例に係るＰＤＩテーブルを圧縮したテーブルを意味する。ＰＤＩテーブルセクションに関する具体的な内容は後述する。
【０７６２】
本発明の一実施例に係る受信機は、ＳＳＣ ２３００を介して受信したＰＤＩテーブルセクションをパーシングしてＰＤＩテーブルを取得することができる。その後、本発明の一実施例に係る受信機は、ＰＤＩエンジン２３３０にＰＤＩテーブルを伝達することができる。
【０７６３】
本発明の一実施例に係るＰＤＩエンジン２３３０は、受信したＰＤＩテーブルを処理し、当該ＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン２３３０は、抽出されたＰＤＩ質問をＵＩ ２３４０に伝達することができる。
【０７６４】
本発明の一実施例に係るＵＩ ２３４０は、受信したＰＤＩ質問をディスプレイし、当該ＰＤＩ質問に対するＰＤＩ回答を受信することができる。この場合、本発明の一実施例に係るＵＩ ２３４０は、リモコンを介してＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン２３３０は、ＵＩ ２３４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。その具体的な内容は、図３６及び図３７で説明したものと同一である。
【０７６５】
また、本発明の一実施例に係る受信機は、ＳＳＣ ２３００を介してＳＭＴ（Ｓｅｒｖｉｃｅ  Ｍａｐ  Ｔａｂｌｅ）及び／又はＮＲＴ−ＩＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）を受信することができる。本発明の一実施例に係るＳＭＴは、個人化サービスのためのシグナリング情報を含むことができる。本発明の一実施例に係るＮＲＴ−ＩＴは、個人化サービスのための報知情報（ａｎｎｏｕｎｃｅｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ）を含むことができる。
【０７６６】
その後、本発明の一実施例に係る受信機は、受信したＳＭＴ及び／又はＮＲＴ−ＩＴをパーシングしてフィルタリング基準記述語を取得することができる。受信機は、フィルタリング基準記述語を用いて、フィルタリングエンジン２３２０にフィルタリング基準を伝達することができる。この場合、本発明のフィルタリング基準は、ｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図５０及び図５１で具体的に説明した。
【０７６７】
その後、本発明の一実施例に係るフィルタリングエンジン２３２０は、ＰＤＩエンジン２３３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン２３３０は、ＰＤＩデータ要求信号を受信すると、当該ＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン２３２０に伝達することができる。その結果、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。本発明の一実施例に係るフィルタリング後の過程については図３８及び図３９で具体的に説明した。
【０７６８】
図５３は、本発明の一実施例に係るＰＤＩテーブルセクションを示す図である。
【０７６９】
具体的には、図５３は、図５２で説明したＰＤＩテーブルセクションの構文である。
【０７７０】
ＰＤＩテーブルが放送ストリームで伝達されると、図５２に定義されたテーブルのＸＭＬ形式はＤＥＦＬＡＴＥ圧縮アルゴリズムを用いて圧縮される。得られた圧縮されたテーブルは、図５３のテーブルに示すようにブロックに区分されてセクションに挿入されることによって、ＮＲＴスタイルの専用セクションに要約される。
【０７７１】
結論として、本発明の一実施例に係る受信機は、同一のシーケンスナンバーを有するセクション番号順にＰＤＩ−Ｑインスタンス文書のブロックを組み合わせて圧縮を解除することができる。本発明の一実施例に係る受信機は、圧縮を解除した結果としてＰＤＩ−Ｑインスタンス文書を生成することができる。その後、受信機は、ＰＤＩ−Ｑインスタンス文書を本発明の一実施例に係るＰＤＩエンジンに伝達することができる。その具体的な方法は、図５２で上述したものと同一である。
【０７７２】
以下、図５３に示すＰＤＩテーブルセクションの構文について説明する。
【０７７３】
ブロックは、昇順のｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールド値のセクションに挿入されるはずである。”ＳＳＣ”及び”ＩＰサブネット”という用語は、ＡＴＳＣ ＮＲＴ標準で定義されるため、専用セクションは、ＰＤＩテーブルが関連した仮想チャネルのＩＰサブネットのＳＳＣで伝達される。当該セクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同一のＳＳＣで伝達される互いに異なるＰＤＩテーブルインスタンスを区別するために用いられる。
【０７７４】
８ビットのｔａｂｌｅ＿ｉｄフィールドは、当該テーブルセクションがＰＤＩテーブルインスタンスに属すると識別するように設定されるはずである。８ビットのｔａｂｌｅ＿ｉｄフィールドは、当該テーブルセクションがＰＤＩテーブルインスタンスに属すると識別するように設定されるはずである。ｔａｂｌｅ＿ｉｄフィールドは、図５３に示すＰＤＩテーブルセクションが本発明の一実施例に係るＰＤＩテーブルに関する情報を含んでいることを示すことができる。
【０７７５】
本実施例に係るｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒフィールドは、ＰＤＩテーブルセクションのフォーマットを示すことができる。
【０７７６】
本実施例に係るｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒフィールドは、使用者に対するビット情報を示すことができる。
【０７７７】
本実施例に係るｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドは、ＰＤＩテーブルセクションでバイトの数を示すことができる。
【０７７８】
本実施例に係るｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールドは、ＰＤＩテーブルセクションを識別することができる。
【０７７９】
本実施例に係るｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、ＰＤＩテーブル構文のプロトコルバージョンを含むことができる。
【０７８０】
８ビットのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドの値は、ＰＤＩ−Ｑインスタンスの他の全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと同一であり、ＳＳＣで伝達される他のＰＤＩ−Ｑインスタンスの全てのセクションのｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒと異なる。ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドは、同時にＳＳＣで伝達されるＰＤＩ−Ｑの互いに異なるインスタンスに属するセクションを区別するために用いられる。
【０７８１】
５ビットのＰＤＩＱ＿ｄａｔａ＿ｖｅｒｓｉｏｎフィールドは、ｐｄｉＴａｂｌｅＩｄ値によって定義されるＰＤＩ−Ｑインスタンスのバージョンナンバーを示す。ＰＤＩ−Ｑインスタンスのいずれかのエレメント又は属性が変化すると、バージョンナンバーは、１ ｍｏｄｕｌｏ ３２ずつ増分する。
【０７８２】
１ビットのｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒフィールドは、ＰＤＩ−Ｑセクションに対しては常に１に設定され、ＰＤＩ−Ｑが常にｓｅｇｍｅｎｔ＿ｉｄによって識別されるセグメントに対して現在ＰＤＩ−Ｑであることを示す。
【０７８３】
８ビットのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、ＰＤＩ−Ｑインスタンスの当該セクションのセクションナンバーを提供する。ＰＤＩ−Ｑインスタンスの最初のセクションのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは０ｘ００に設定される。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、ＰＤＩ−Ｑインスタンスのそれぞれの追加セクションによって１ずつ増分する。
【０７８４】
８ビットのｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドは、当該セクションが一部であるＰＤＩ−Ｑインスタンスの最後のセクション（すなわち、最高のｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒのセクション）のナンバーを提供する。
【０７８５】
１６ビットのｓｅｒｖｉｃｅ＿ｉｄフィールドは、当該ＰＤＩ−Ｑインスタンスが、或る特定サービスではなく、それが現れる仮想チャネルでの全てのデータサービスに適用されるということを示すために、０ｘ００００に設定される。
【０７８６】
可変長を有するｐｄｉｑ＿ｂｙｔｅｓ（）フィールドは、当該セクションによって部分的に伝達されるＰＤＩ−Ｑインスタンスのブロックで構成される。当該テーブルインスタンスの全てのセクションのｐｄｉｑ＿ｂｙｔｅｓ（）フィールドがそれらのｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒフィールドの順に連結されると、結果は完全なＰＤＩ−Ｑインスタンスである。
【０７８７】
図５４は、本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【０７８８】
具体的には、図５４は、図５２で説明したＰＤＩテーブルセクションの構文であって、基本的な内容は、図５３で説明したものと同一である。ただし、図５３に示すＰＤＩテーブルセクションとは違い、図５４に示すＰＤＩテーブルセクションはｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドを含まなくてもよい。以下、図５４に示すＰＤＩテーブルセクションの構文について説明する。
【０７８９】
本発明の一実施例に係るｎｕｍ＿ｑｕｅｓｔｉｏｎｓフィールドは、ＰＤＩテーブルに含まれたＰＤＩ質問の数を示すことができる。
【０７９０】
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、一つのＰＤＩ質問のＩＤの長さを示すことができる。
【０７９１】
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｉｄ＿ｖａｌｕｅフィールドは、一つのＰＤＩ質問のＩＤが有する値を示すことができる。
【０７９２】
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｔｅｘｔ＿ｌｅｎｇｔｈフィールドは、ｑｕｅｓｔｉｏｎ＿ｔｅｘｔの長さを示すことができる。
【０７９３】
本発明の一実施例に係るｑｕｅｓｔｉｏｎ＿ｔｅｘｔフィールドは、一つのＰＤＩ質問の実際内容を含むことができる。
【０７９４】
本発明の一実施例に係るａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、ＰＤＩ質問に対するＰＤＩ回答のタイプを示すことができる。具体的には、本発明の一実施例に係るａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、次の表１に表現された回答タイプコードを含むことができる。次の表３４に示すそれぞれの回答タイプコードは、図４０で説明したＰＤＩ回答のタイプを示すことができる。
【０７９５】
【表３４】
0006348184.tif 000050
【０７９６】
本発明の一実施例に係るｎｕｍ＿ａｎｓｗｅｒフィールドは、ＰＤＩ質問に対するＰＤＩ回答の数を示すことができる。
【０７９７】
本発明の一実施例に係るａｎｓｗｅｒ＿ｖａｌｕｅ＿ｌｅｎｇｔｈフィールドは、ａｎｓｗｅｒ＿ｖａｌｕｅの実際の長さを示すことができる。
【０７９８】
本発明の一実施例に係るａｎｓｗｅｒ＿ｖａｌｕｅフィールドは、ａｎｓｗｅｒ＿ｔｙｐｅ＿ｃｏｄｅと表現されるＰＤＩ回答の実際内容を含むことができる。
【０７９９】
図５５は、本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【０８００】
具体的に、図５５は、図５２で説明したＰＤＩテーブルセクションの構文であって、基本的な内容は、図５３及び図５４で説明したものと同一である。図５５の構文を構成するフィールドは、図５４の構文を構成するフィールドと同一であり、以下、その具体的な説明は省略する。
【０８０１】
図５６は、本発明の他の実施例に係るＰＤＩテーブルセクションを示す図である。
【０８０２】
具体的に、図５６は、図５２で説明したＰＤＩテーブルセクションの構文であって、基本的な内容は、図５３及び図５４で説明したものと同一である。図５６の構文を構成する基本的なフィールドは、図５４のｓｙｎｔａｘを構成するフィールドと同一であり、以下、その具体的な説明は省略する。
【０８０３】
ただし、図５４の構文に比べて、図５６の構文は、ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドをさらに含むことができる。本発明の一実施例に係るｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドについての説明は、図５３で上述したものと同一である。
【０８０４】
図５７は、他の実施例に係るデジタル放送システムのフローチャートである。
【０８０５】
具体的に、図５２で説明した個人化放送システム上のＦＬＵＴＥセッション、フィルタリングエンジン及び／又はＰＤＩエンジンの動作に関する本発明の一実施例を示す図である。
【０８０６】
図５７に示すように、本発明の一実施例に係る個人化放送システムは、ＦＬＵＴＥセッション２８００、フィルタリングエンジン２８１０及び／又はＰＤＩエンジン２８２０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０サービス及び次世代放送サービスなどを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。
【０８０７】
図５２で上述した通り、本発明の一実施例に係る受信機は、ＦＬＵＴＥセッションを通してＰＤＩテーブルを受信することができる。以下、図５７では、本発明の一実施例に係る受信機がＦＬＵＴＥセッションを通してＰＤＩテーブルを受信する方法を説明する。
【０８０８】
本発明の一実施例に係る受信機は、ＦＬＵＴＥセッション２８００を通してＦＤＴインスタンスを受信することができる。ＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）インスタンスは、同一のＦＬＵＴＥセッション２８００を通して伝送されるコンテンツの伝送単位を意味する。本発明の一実施例に係るＦＤＴインスタンスは、コンテンツのタイプを示すコンテンツタイプ属性を含むことができる。具体的には、本発明の一実施例に係るコンテンツタイプ属性は、ＦＬＵＴＥセッション２８００を通して伝送されるファイルがＰＤＩ−Ｑインスタンス文書（又は、ＰＤＩテーブル）であることを示す内容を含むことができる。本発明の一実施例に係るコンテンツタイプ属性に関する具体的な内容は後述する。
【０８０９】
本発明の一実施例に係る受信機は、ＦＤＴインスタンスを用いて、ＦＬＵＴＥセッション２８００を通して伝送されるファイルがＰＤＩ−Ｑインスタンス文書であることを認知できる。その後、本発明の一実施例に係る受信機は、ＰＤＩ−Ｑインスタンス文書をＰＤＩエンジン２８２０に伝達することができる。その具体的な内容は、図５２で説明したものと同一である。
【０８１０】
図５８は、本発明の他の実施例に係るＦＤＴインスタンスのＸＭＬスキーマを示す図である。
【０８１１】
具体的には、図５８は、図５７で説明したＦＤＴインスタンスのＸＭＬスキーマを示す図である。以下、上述したコンテンツタイプ属性（２９００）について説明する。
【０８１２】
図５８に示すように、本発明の一実施例に係るＦＤＴインスタンスは、ＦＤＴインスタンス自体の属性情報を示す属性２９００及び／又はＦＬＵＴＥセッションを通して伝送されるファイルを示すｆｉｌｅエレメント２９１０を含むことができる。図５８に示すｆｉｌｅエレメント２９１０は、ファイルに関する属性情報を示す属性を含むことができる。図５８に示すように、ｆｉｌｅエレメント２９１０は、本発明の実施例に係るｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０を含むことができる。
【０８１３】
図５７で説明した通り、本発明の実施例に係る受信機は、ｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０に含まれた値を用いてＰＤＩ−Ｑインスタンス文書を識別することができる。例えば、図５８に示すｃｏｎｔｅｎｔ ｔｙｐｅ属性２９２０は、”ａｐｐｌｉｃａｔｉｏｎ／ａｔｓｃ−ｐｄｉｑ”又は”ｔｅｘｔ／ａｔｓｃ−ｐｄｉｑ＋ｘｍｌ”で表現されるＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ  Ｉｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）プロトコル形態の値などを有することができる。
【０８１４】
図５９は、本発明の一実施例に係るキャパビリティ記述語構文を示す図である。
【０８１５】
具体的には、図５９は、図５２で説明した個人化放送システムにおいて、本発明の一実施例に係る受信機がＰＤＩテーブルを識別するための構文を示している。
【０８１６】
本発明の一実施例に係るキャパビリティ記述語は、ＳＭＴサービスレベルでのサービス又はＮＲＴ−ＩＴコンテンツレベルでのコンテンツがＰＤＩテーブルであるか否かを示すために用いることができる。本発明の一実施例に係る受信機は、当該情報を用いてサービス／コンテンツがＰＤＩテーブルであるか否かを知り、当該サービス／コンテンツがダウンロードされるべきかをＰＤＩエンジンを支援するなどのキャパビリティによって判断する。
【０８１７】
次の表２に表現されたコードは、ＰＤＩテーブルシグナリングに対するキャパビリティ記述語でｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅに追加することができる。本発明の一実施例に係るｃａｐａｂｌｉｌｔｙ＿ｃｏｄｅ値は、他の値に割り当てることができない。次の表３５に表現されたｃａｐａｂｉｌｉｔｙ＿ｃｏｄｅ値は、設計者の意図によってその設定が変更されてもよい。
【０８１８】
【表３５】
0006348184.tif 000051
【０８１９】
図６０は、本発明の一実施例に係る消費モデルを示す図である。
【０８２０】
具体的には、図６０は、図５２で説明した個人化放送システムにおいて、本発明の一実施例に係る受信機でＰＤＩテーブルを識別するためにＳＭＴ上に追加されたフィールドを示す。
【０８２１】
ＮＲＴサービス記述語は、ＮＲＴ ＳＭＴのサービスレベルに位置し、そのＮＲＴ＿ｓｅｒｖｉｃｅ＿ｃａｔｅｇｏｒｙは、サービスがＰＤＩテーブルを提供すると、０ｘ０４（ＰＤＩ）となる。したがって、受信機は、フィールド値が０ｘ０４であると、ＰＤＩテーブルが提供されることがわかる。
【０８２２】
図６０に示す消費モデルの値は、設計者の意図によってその設定が変更されてもよい。
【０８２３】
図６１は、本発明の一実施例に係るフィルタリング基準記述語構文を示す図である。
【０８２４】
具体的には、図６１は、図５２で説明した個人化放送システム上で、本発明の一実施例に係る受信機がフィルタリング基準テーブルを受信するためのフィルタリング基準記述語のビットストリーム構文を示している。
【０８２５】
本発明の一実施例に係るフィルタリング基準は、本発明の一実施例に係る受信機がコンテンツをダウンロードするか否かを判断するよう、ダウンロード可能なコンテンツと関連付けられる。ＡＴＳＣ ２．０環境には、ダウンロード可能なコンテンツに２種のカテゴリーがある。独立型のＮＲＴサービスにおけるＮＲＴコンテンツ及び附属双方向データサービスでＴＤＯによって使われるＮＲＴコンテンツアイテムがある。
【０８２６】
以下、図６１では、独立型のＮＲＴサービスにおけるＮＲＴコンテンツをフィルタリングするためのフィルタリング基準について説明する。
【０８２７】
本発明の一実施例に係るＮＲＴサービス及びコンテンツアイテムに対するフィルタリング基準で、以下に定義されたフィルタリング基準記述語の一つ以上のインスタンスは、受信機が使用者にＮＲＴサービスを提供するか否かを決定するようにするために、ＳＭＴでサービスレベル記述語ループに含まれてもよく、受信機が当該特定コンテンツアイテムをダウンロードして使用者に使用可能にさせるか否かを決定するようにＮＲＴ−ＩＴでコンテンツアイテムレベル記述語ループに含まれてもよい。
【０８２８】
フィルタリング基準記述語の一つ以上のインスタンスは、複数値が同一の又は異なるターゲット基準に対して提供されるようにする。意図するターゲット論理は、同一のターゲット基準に対して複数値間の論理和であり、異なるターゲット基準間の論理積である。
【０８２９】
以下、図６１に示すフィルタリング基準記述語のビットストリーム構文における各フィールドのセマンティック定義について説明する。
【０８３０】
８ビットフィールドであるｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドは、記述語が本発明の一実施例に係るフィルタリング基準記述語である旨を示すために０ｘＴＢＤに設定することができる。
【０８３１】
８ビット符号無し整数フィールドであるｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドは、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールド自身に続くバイト数を示すことができる。
【０８３２】
８ビットフィールドであるｎｕｍ＿ｆｉｌｔｅｒ＿ｃｒｉｔｅｒｉａフィールドは、図６１に示した当該記述語に含まれたフィルタリング基準の数を示すことができる。
【０８３３】
８ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈフィールドは、ｃｒｉｔｅｒｉｏｎ＿ｉｄフィールドの長さを示すことができる。
【０８３４】
可変長フィールドであるｃｒｉｔｅｒｉｏｎ＿ｉｄフィールドは、当該記述語が現れる仮想チャネルのＰＤＩテーブルで質問（ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡエレメント）のｉｄ属性にマッチングするＵＲＩの形態で当該フィルタリング基準の識別子を提供することができる。
【０８３５】
３ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、次の表３６によって当該基準（質問）のタイプを提供することができる。
【０８３６】
【表３６】
0006348184.tif 000052
【０８３７】
５ビットフィールドであるｎｕｍ＿ｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅｓフィールドは、各値がｃｒｉｔｅｒｉｏｎ＿ｉｄによって識別される質問（ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＡＡ）に対する可能な回答である当該フィルタリング基準に対するループでターゲット基準値の数を提供する。
【０８３８】
８ビットフィールドであるｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅ＿ｌｅｎｇｔｈフィールドは、当該ターゲット基準値を表す必要があるバイトの数を提供する。
【０８３９】
可変長フィールドであるｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅフィールドは、当該ターゲット基準値を提供する。
【０８４０】
本発明の一実施例に係るフィルタリング基準記述語は、サービスやコンテンツアイテムと関連した特定ターゲット基準に対する値を示す。ＡＴＳＣ ２．０送出において、上記の定義されたｆｉｌｔｅｒｉｎｇ＿ｃｒｉｔｅｒｉａ＿ｄｅｓｃｒｉｐｔｏｒ（）の一つ以上のインスタンスは、ＳＭＴにおいてＮＲＴサービスの記述語ループ又はＮＲＴ−ＩＴにおいてコンテンツアイテムの記述語ループに入ることができる。前者の場合、それらはサービス自体（全てのコンテンツアイテム）に適用することができる。後者の場合、それらは個別コンテンツアイテムに適用することができる。
【０８４１】
記述語ループに一つのフィルタリング基準記述語のみがあり、それが一つの基準値のみを有すると、サービス又はコンテンツアイテムがフィルタを通過するか否かの決定は、当該基準値が（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって示されるように）フィルタリング基準に該当する質問に対するＰＤＩ−Ａで質問のいずれかの値と一致する場合は”真”（はい）になり、そうでない場合は”偽”（いいえ）になるはずである。
【０８４２】
単一記述語ループの全てのフィルタリング基準記述語において総基準値の数が１より大きいと、各基準値の結果は、基準値が（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって示されるように）フィルタリング基準に該当する質問に対するＰＤＩ−Ａで回答のいずれかの値と一致する場合は、”真”を答える中間用語として評価されるはずであり、そうでない場合は”偽”を答える中間用語として評価されるはずである。これらの中間用語のうち、（ｃｒｉｔｅｒｉｏｎ＿ｉｄによって決定されるように）フィルタリング基準の同一値を有するものは、各ターゲット基準に対する中間結果を得るために論理和されるはずであり、これらの中間結果は、最終結果を決定するために論理積されるはずである。最終結果が受信機に対して”真”と評価されると、これは、関連したＮＲＴサービス又はコンテンツアイテムがフィルタを通過して受信機にダウンロードされてもよいことを意味する。
【０８４３】
図６２は、本発明の他の実施例に係るフィルタリング基準記述語構文を示す図である。
【０８４４】
具体的には、図６２は、図５２で説明した個人化放送システム上で、本発明の一実施例に係る受信機がフィルタリング基準テーブルを受信するためのフィルタリング基準記述語のビットストリーム構文を示している。
【０８４５】
図６２に示すフィルタリング基準記述語構文の基本的な内容は、図６１で説明したものと同一である。
【０８４６】
しかし、ｃｒｉｔｅｒｉｏｎ＿ｔｙｐｅ＿ｃｏｄｅフィールドは、下記の表３７によって当該基準（質問）のタイプを提供することができる。
【０８４７】
【表３７】
0006348184.tif 000053
【０８４８】
図６３は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０８４９】
具体的には、図６３は、本発明の一実施例に係る受信機が放送網を通してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
【０８５０】
本発明の一実施例に係る個人化放送システムの基本的な構造は、図３６乃至図３９で説明したものと同一である。本発明の一実施例に係るＰＤＩテーブルは、図３８乃至図４７で説明したものと同一である。本発明の一実施例に係るフィルタリング基準テーブルは、図４８乃至図５１で説明したものと同一である。
【０８５１】
図６３に示すように、本発明の一実施例に係る個人化放送システムは、シグナリングサーバー３４１０、フィルタリングエンジン３４２０、ＰＤＩエンジン３４３０及び／又はＵＩ ３４４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。
【０８５２】
本発明の一実施例に係るＰＤＩテーブル及びフィルタリング基準を処理するためのフィルタリングエンジン３４２０、ＰＤＩエンジン３４３０及び／又はＵＩ ３４４０の動作は、図５２で説明したものと同一である。以下、図６３に示すシグナリングサーバー３４１０の動作を中心に説明する。
【０８５３】
本発明の一実施例に係る受信機は、まず、ＰＤＩテーブルセクションを受信するための要求信号をシグナリングサーバー３４１０に伝送することができる。この場合、本発明の一実施例に係る受信機は、クエリー用語を用いて要求信号を伝送することができる。クエリーに関する具体的な内容は後述する。
【０８５４】
本発明の一実施例に係るシグナリングサーバー３４１０は、当該クエリーに応じたＰＤＩテーブルセクションを受信機に伝送することができる。ＰＤＩテーブルセクションに関する具体的な内容は、図５３乃至図５６で説明したものと同一である。
【０８５５】
図６４は、本発明の一実施例に係るＨＴＴＰ要求テーブルを示す図である。
【０８５６】
具体的には、図６４は、本発明の一実施例に係る受信機が図６３で説明したシグナリングサーバーにクエリーを伝送するためのＨＴＴＰプロトコルを示す。
【０８５７】
放送局によって支援されると、図６４に示すプロトコルは、２つのキャパビリティを提供することができる。第一に、圧縮されないオーディオ又はビデオのみを伝達する経路を通してＤＴＶ放送信号を受ける装置に対して、当該プロトコルは一般に放送局の独立型ＮＲＴサービスに接続する唯一の方法である。第二に、完全な放送ストリームに接続できる装置に対しても、当該プロトコルはローカル放送領域で使用可能な全ての放送ストリームを循環して所望のテーブルが現れることを待たずに、プログラム／サービスガイドを埋めるデータを検索する方法を提供する。これは、また、別のチューナーを必要とせず、視聴者がＴＶを視聴している間にも、いつでもこのようなデータの検索を可能にする。
【０８５８】
図６４に示すＨＴＴＰ要求テーブルは、受信しようとするテーブルの種類及び当該テーブルを受信するためのベースＵＲＬを示すクエリー用語を含むことができる。
【０８５９】
本発明の一実施例に係る受信機は、図６４に示すＨＴＴＰ要求テーブルのクエリー用語を用いて特定ｔａｂｌｅを受信することができる。具体的に、本発明の一実施例に係る受信機は、”？ｔａｂｌｅ＝ＰＤＩＴ［＆ｃｈａｎ＝＜ｃｈａｎ＿ｉｄ＞］”というクエリー用語を用いてシグナリングサーバーに要求信号を送ることができる。その具体的な内容は図６３で説明したものと同一である。
【０８６０】
図６５は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０８６１】
具体的には、図６５は、本発明の一実施例に係る受信機がインターネットを通してＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムのフローチャートである。
【０８６２】
本発明の一実施例に係る個人化放送システムの基本的な構造は、図３６乃至図３９で説明したものと同一である。本発明の一実施例に係るＰＤＩテーブルは、図３８乃至図４７で説明したものと同一である。本発明の一実施例に係るフィルタリング基準テーブルは、図４８乃至図５１で説明したものと同一である。
【０８６３】
インターネットを通して伝達される時、ＰＤＩテーブルインスタンスは、ＨＴＴＰ又はＨＴＴＰＳを通して伝達されるはずである。ＨＴＴＰ応答ヘッダーでＰＤＩテーブルのコンテンツタイプは”ｔｅｘｔ／ｘｍｌ”になるだろう。
【０８６４】
インターネットを通してＰＤＩテーブルを検索するために使われるＵＲＬは、ＤＴＶ字幕放送チャネルで標準字幕サービス＃６で移動するＳＤＯＰｒｉｖａｔｅＤａｔａＵＲＩＳｔｒｉｎｇ命令語を介して伝達されてもよく、ＴＰＴと共に伝達されるＵｒｌＬｉｓｔＸＭＬエレメントで伝達されてもよい。
【０８６５】
ＴＰＴ（ＴＤＯパラメータテーブル）は、セグメントのＴＤＯに関するメタデータ及びそれらをターゲットとするイベントを含む。ＴＤＯという用語は、トリガリングされた双方向付加データサービスでトリガーによって開始されたＤＯ（Ｄｅｃｌａｒａｔｉｖｅ  Ｏｂｊｅｃｔ）又はトリガーによって開始されたＤＯによって開始されたＤＯなどを反復して指定するために使われる。トリガーは、シグナリングを識別し、双方向イベントの再生のタイミングを設定する機能を有するシグナリングエレメントである。
【０８６６】
図６５に示すように、本発明の一実施例に係る個人化放送システムは、ＰＤＩサーバー３６００、コンテンツサーバー３６５０及び／又は受信機を含むことができる。本発明の一実施例に係る受信機はＴＰＴ（ＴＤＯ  Ｐａｒａｍｅｔｅｒｓ  Ｔａｂｌｅ）クライアント３６１０、フィルタリングエンジン３６２０、ＰＤＩエンジン３６３０及び／又はＵＩ３６４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図６５に示す各構成エレメントの動作について説明する。
【０８６７】
本発明の一実施例に係るＴＰＴクライアント３６１０は、ＴＰＴ及び／又はＵＲＬリストテーブルを受信することができる。本発明の一実施例に係るＴＰＴは、セグメントのＴＤＯに関するメタデータ及びそれらをターゲットとするイベントを含む。本発明の一実施例に係るＴＰＴは、ＰＤＩテーブル及びフィルタリング基準テーブルに関する情報を含むことができる。本発明の一実施例に係るＵＲＬリストテーブルは、ＰＤＩサーバー３６００のＵＲＬ情報を含むことができる。ＴＰＴ及びＵＲＬリストテーブルに関する具体的な内容は後述する。
【０８６８】
また、本発明の一実施例に係るＴＰＴクライアント３６１０は、ＵＲＬリストテーブルからＰＤＩサーバー３６００のＵＲＬ情報を取得することができる。ＴＰＴクライアント３６１０は、取得したＵＲＬ情報を用いてＰＤＩサーバー３６００にアクセスし、本発明の一実施例に係るＰＤＩテーブルの伝送を要求することができる。本発明の一実施例に係るＰＤＩサーバー３６００は、ＴＰＴクライアント３６１０の要求によって当該ＰＤＩテーブルをＴＰＴクライアント３６１０に伝送することができる。
【０８６９】
図６５に示すように、本発明の一実施例に係るＴＰＴクライアント３６１０は、受信したＰＤＩテーブルをＰＤＩエンジン３６３０に伝達することができる。本発明の一実施例に係るＰＤＩエンジン３６３０は、受信したＰＤＩテーブルを処理し、当該ＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン３６３０は、抽出されたＰＤＩ質問をＵＩ ３６４０に伝達することができる。
【０８７０】
本発明の一実施例に係るＵＩ ３６４０は、受信したＰＤＩ質問をディスプレイし、当該ＰＤＩ質問に対するＰＤＩ回答を受信することができる。本発明の一実施例に係るＵＩ ３６４０はリモコンによってＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン３６３０は、ＵＩ ３６４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。その具体的な内容は、図３６及び図３７で説明したものと同一である。
【０８７１】
また、本発明の一実施例に係るＴＰＴクライアント３６１０は、ＴＰＴをパーシングしてフィルタリング基準を取得することができる。図６５に示すように、ＴＰＴクライアント３６１０は、フィルタリング基準をフィルタリングエンジン３６２０に伝達することができる。この場合、本発明のフィルタリング基準は、ｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図５０及び図５１で具体的に説明した。
【０８７２】
その後、本発明の一実施例に係るフィルタリングエンジン３６２０は、ＰＤＩエンジン３６３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン３６３０はＰＤＩデータ要求信号を受信すると、当該ＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン３６２０に伝達することができる。本発明の一実施例に係るフィルタリング以降の過程については図３８及び図３９で具体的に説明した。
【０８７３】
結果的に、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。さらにいうと、ＴＰＴクライアント３６１０は、フィルタリング結果をフィルタリングエンジン３６２０から受信し、ＴＤＯ及び／又はコンテンツダウンロード要求信号をコンテンツサーバー３６５０に伝達することができる。コンテンツサーバー３６５０はＴＤＯ及び／又はコンテンツダウンロード要求信号に応じてＴＤＯ及び／又はコンテンツをＴＰＴクライアント３６１０に伝送することができる。
【０８７４】
図６６は、本発明の一実施例に係るＵＲＬリストテーブル示す図である。
【０８７５】
具体的には、図６６は、本発明の一実施例に係る受信機がインターネットを通してＰＤＩテーブル及び／又はフィルタリング基準を受信するためのＵＲＬ情報を含んでいるテーブルである。本発明の一実施例に係るＵＲＬリストテーブルの送受信過程は、図６５で具体的に説明した。
【０８７６】
ＵＲＬリストテーブルは、インターネットを通して伝達される時、マルチパート（ｍｕｌｔｉｐａｒｔ）ＭＩＭＥメッセージの形態でＴＰＴと共にＨＴＴＰを通して伝達されうる。
【０８７７】
インターネットを通して伝達される時、ＴＰＴはＨＴＴＰを通して伝達されてもよい。現セグメントのＴＰＴに関するＵＲＬ情報は、ＤＴＶ字幕サービス＃６又は自動コンテンツ認識サーバーを介して伝達され、トリガーに現れるはずである。ＴＰＴの要求に対する応答は、現セグメントに対するＴＰＴのみで構成されてもよく、要求されたＴＰＴが一番目のパート、セグメントに対するＡＭＴが選択的に二番目のパート、ＵｒｌＬｉｓｔＸＭＬ文書が選択的にその次のパートであるマルチパートＭＩＭＥメッセージで構成されてもよい。
【０８７８】
以下、本発明の一実施例に係るＵＲＬリストテーブルに含まれた各エレメントのセマンティクスについて説明する。
【０８７９】
図６６に示すＵｒｌＬｉｓｔエレメントは、本発明の一実施例に係る受信機に有用なＵＲＬのリストを含む。
【０８８０】
図６６に示すＵｒｌＬｉｓｔエレメントのＴｐｔＵｒｌエレメントは、現双方向付加サービスで将来のセグメントに対するＴＰＴのＵＲＬ情報を含むことができる。複数のＴｐｔＵｒｌエレメントが含まれると、それらは放送でセグメントの出現順に整列されるはずである。
【０８８１】
図６６に示すＵｒｌＬｉｓｔエレメントのＮｒｔＳｉｇｎａｌｉｎｇＵｒｌエレメントは、受信機が当該標準のセクション１８に定義された要求プロトコルを用いて現伝送ストリームで全ての仮想チャネルに対するＮＲＴシグナリングテーブルを取得できるサーバーのＵＲＬ情報を含むことができる。
【０８８２】
図６６に示すＵｒｌＬｉｓｔエレメントのＵｒｓＵｒｌエレメントは、受信機が当該標準のセクション１０に定義されたプロトコルを用いて使用（視聴率調査）レポートを伝送できるサーバーのＵＲＬ情報を含むことができる。
【０８８３】
図６６に示すＵｒｌＬｉｓｔエレメントのＰｄｉＵｒｌエレメントは、ＰＤＩＴａｂｌｅのＵＲＬ情報を含むことができる。すなわち、本発明の一実施例に係るＰｄｉＵｒｌエレメントは、ＰＤＩテーブル及び／又はフィルタリング基準を伝送できるサーバーのＵＲＬ情報を示すことができる。
【０８８４】
上述した図６６のＵＲＬリストテーブルは、次の表３８のようなフォーマットで構成することができる。
【０８８５】
【表３８】
0006348184.tif 000054
【０８８６】
図６７は、本発明の一実施例に係るＴＰＴを示す図である。
【０８８７】
具体的には、図６７に示すＴＰＴは、ＰＤＩテーブル及び／又はフィルタリング基準のＵＲＬ情報を含むことができる。本発明の一実施例に係るＴＰＴの送受信過程は、図６５で具体的に説明した。以下、ＴＰＴに含まれたフィルタリング基準に関するエレメントを説明する。
【０８８８】
具体的には、図６７に示すＦｉｌｔｅｒ Ｃｒｉｔｅｒｉｏｎエレメントは、フィルタリング基準に関する情報を含むことができる。
【０８８９】
本発明の一実施例に係るｉｄ属性は、当該フィルタリング基準に関するＰＤＩ質問を示すことができる。
【０８９０】
本発明の一実施例に係る基準タイプ属性は、フィルタリング基準タイプ（又は、フィルタリング基準タイプエレメント）を示すことができる。本発明の一実施例に係るフィルタリング基準のタイプに関しては図４９で具体的に説明した。
【０８９１】
本発明の一実施例に係るｃｒｉｔｅｒｉｏｎ ｖａｌｕｅ属性は、上述した基準タイプ属性によるフィルタリング基準の値を示すことができる。
【０８９２】
図６８は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０８９３】
具体的には、図６８は、本発明の一実施例に係る受信機が自動コンテンツ認識システム上でＰＤＩテーブル及び／又はフィルタリング基準テーブルを受信するための個人化放送システムを示す図である。
【０８９４】
本発明の一実施例に係る自動コンテンツ認識システムは、図５９で説明したものと同一である。本発明の一実施例に係る個人化放送システムの基本的な構造は、図３６乃至図３９で説明したものと同一である。本発明の一実施例に係るＰＤＩテーブルは、図３８乃至図４７で説明したものと同一である。本発明の一実施例に係るフィルタリング基準テーブルは、図４８乃至図５１で説明したものと同一である。
【０８９５】
図６８に示すように、本発明の一実施例に係る個人化放送システムは、自動コンテンツ認識サーバー３９００、ＴＰＴサーバー３９５０、ＰＤＩサーバー３９６０、コンテンツサーバー３９７０、自動コンテンツ認識クライアント３９１０、フィルタリングエンジン３９２０、ＰＤＩエンジン３９３０及び／又はＵＩ ３９４０を含むことができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図６８に示す各構成エレメントの動作について説明する。
【０８９６】
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、フィンガープリントからシグネチャーを抽出し、シグネチャーと共に要求を自動コンテンツ認識サーバー３９００に伝送することができる。本発明の一実施例に係る自動コンテンツ認識サーバー３９００はシグネチャーを受信し、該シグネチャーと関連したトリガーなどと共に応答を自動コンテンツ認識クライアント３９１０に伝送することができる。上述した内容は図５９乃至図３５で具体的に説明した。
【０８９７】
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、受信したトリガーなどを用いて、ＴＰＴサーバー３９５０にＴＰＴ及び／又はＵＲＬリストテーブルを要求することができる。本発明の一実施例に係るＴＰＴサーバー３９５０は、自動コンテンツ認識クライアント３９１０の要求に応じて、自動コンテンツ認識クライアント３９１０にＴＰＴ及び／又はＵＲＬリストテーブルを伝送することができる。ＴＰＴ及び／又はＵＲＬリストテーブルに関する具体的な内容は、上述した通りである。その後、本発明の一実施例に係るＴＰＴサーバー３９５０は、受信したＴＰＴ及び／又はＵＲＬリストテーブルを自動コンテンツ認識クライアント３９１０に伝達することができる。
【０８９８】
本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、ＵＲＬリストテーブルからＰＤＩサーバー３９６０のＵＲＬ情報を取得することができる。自動コンテンツ認識クライアント３９１０は、取得したＵＲＬ情報を用いてＰＤＩサーバー３９６０にアクセスし、本発明の一実施例に係るＰＤＩテーブルの伝送を要求することができる。本発明の一実施例に係るＰＤＩサーバー３９６０は、自動コンテンツ認識クライアント３９１０の要求に応じて当該ＰＤＩテーブルを自動コンテンツ認識クライアント３９１０に伝送することができる。
【０８９９】
図６３に示すように、本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、受信したＰＤＩテーブルをＰＤＩエンジン３９３０に伝達することができる。本発明の一実施例に係るＰＤＩエンジン３９３０は、受信したＰＤＩテーブルを処理し、当該ＰＤＩテーブルに含まれたＰＤＩ質問を抽出することができる。その後、本発明の一実施例に係るＰＤＩエンジン３９３０は、抽出されたＰＤＩ質問をＵＩ ３９４０に伝達することができる。
【０９００】
本発明の一実施例に係るＵＩ ３９４０は、受信したＰＤＩ質問をディスプレイし、当該ＰＤＩ質問に対するＰＤＩ回答を受信することができる。本発明の一実施例に係るＵＩ ３９４０はリモコンを介してＰＤＩ回答を受信することができる。その後、本発明の一実施例に係るＰＤＩエンジン３９３０はＵＩ ３９４０から受信したＰＤＩ回答を用いてＰＤＩデータを更新することができる。その具体的な内容は、図３６及び図３７で説明したものと同一である。
【０９０１】
また、本発明の一実施例に係る自動コンテンツ認識クライアント３９１０は、ＴＰＴをパーシングしてフィルタリング基準を取得することができる。図６８に示すように、自動コンテンツ認識クライアント３９１０は、フィルタリング基準をフィルタリングエンジン３９２０に伝達することができる。この場合、本発明のフィルタリング基準はｘｍｌ文書フォーマットのフィルタリング基準テーブルを一実施例とすることができ、フィルタリング基準テーブルについては図５０及び図５１で具体的に説明した。
【０９０２】
その後、本発明の一実施例に係るフィルタリングエンジン３９２０は、ＰＤＩエンジン３９３０にＰＤＩデータ要求信号を伝達することができる。本発明の一実施例に係るＰＤＩエンジン３９３０はＰＤＩデータ要求信号を受信すると、当該ＰＤＩデータ要求信号に対応するＰＤＩデータを検索してフィルタリングエンジン３９２０に伝達することができる。本発明の一実施例に係るフィルタリング以降の過程については図３８及び図３９で具体的に説明した。
【０９０３】
結果的に、本発明の一実施例に係る受信機は、フィルタリング結果を用いてコンテンツをダウンロードすることができる。具体的には、自動コンテンツ認識クライアント３９１０は、フィルタリング結果をフィルタリングエンジン３９２０から受信し、ＴＤＯ及び／又はコンテンツダウンロード要求信号をコンテンツサーバー３９７０に伝達することができる。コンテンツサーバー３９７０は、ＴＤＯ及び／又はコンテンツダウンロード要求信号によってＴＤＯ及び／又はコンテンツを自動コンテンツ認識クライアント３９１０に伝送することができる。
【０９０４】
図６９は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０９０５】
具体的には、図６９は、ＰＤＩ回答の重複防止のための個人化放送システムの一実施例を示す図である。
【０９０６】
さらにいうと、図６９は、本発明の一実施例に係る受信機が複数の放送局及びコンテンツプロバイダから同一のＰＤＩ質問を受信する場合、あらがじめ記憶しているＰＤＩ回答を用いてＰＤＩデータを更新できる個人化放送システムを示す。図６９に示す個人化放送システムによって、使用者は同一のＰＤＩ質問に対して重複してＰＤＩ回答を入力する面倒さを減らすことができる。
【０９０７】
図６９に示すように、本発明の一実施例に係る個人化放送システムは、２つ以上の放送局（又は、コンテンツプロバイダ）及び／又は受信機を含むことができる。本発明の一実施例に係る２つ以上の放送局は、放送局Ａ ４０１０及び／又は放送局Ｂ４０２０を含むことができる。本発明の一実施例に係る受信機は、ＰＤＩエンジン４０３０及び／又はＵＩ ４０４０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０サービスを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図６９に示す各構成エレメントの動作を説明する。
【０９０８】
まず、本発明の一実施例に係る受信機は、放送局Ａ ４０１０から第１のＰＤＩテーブル４０１１を受信することができる。第１のＰＤＩテーブル４０１１を受信した受信機は、ＰＤＩエンジン４０３０に第１のＰＤＩテーブル４０１１を伝達することができる。本発明の一実施例に係る第１のＰＤＩテーブル４０１１は、第１のＰＤＩタイプエレメント４０１２を含むことができる。本発明の一実施例に係る第１のＰＤＩタイプエレメント４０１２のそれぞれは、図４６及び図４７で上述した通り、第１識別子エレメント（又は、第１のＩＤ）及び／又は第１のＰＤＩ質問を含むことができる。また、図６９に示すように、第１のＰＤＩテーブル４０１１は、それぞれ異なる第１のＩＤを有する２つ以上の第１のＰＤＩタイプエレメント４０１２を含むことができる。
【０９０９】
本発明の一実施例に係るＰＤＩエンジン４０３０は、第１のＰＤＩタイプエレメント４０１２から第１のＰＤＩ質問を抽出し、抽出した第１のＰＤＩ質問をＵＩ ４０４０に伝達することができる。その後、本発明の一実施例に係るＵＩ ４０４０は、使用者から第１のＰＤＩ質問に対する第１のＰＤＩ回答を受信することができる。ＰＤＩエンジン４０３０は第１のＰＤＩ回答を第１のＰＤＩタイプエレメント４０１２に追加及び／又は修正することができる。本発明の一実施例に係るＰＤＩエンジン４０３０及びＵＩ ４０４０の具体的な動作は、図５２で説明したものと同一である。
【０９１０】
また、本発明の一実施例に係るＰＤＩエンジン４０３０は、放送局Ｂ４０２０から第２のＰＤＩテーブル４０２１を受信することができる。本発明の一実施例に係る第２のＰＤＩテーブル４０２１は、第２のＰＤＩタイプエレメント４０２２を含むことができる。図４６及び図４７で上述した通り、第２のＰＤＩタイプエレメント４０２２は第２識別子エレメント（又は、第２のＩＤ）及び／又は第２のＰＤＩ質問を含むことができる。
【０９１１】
第２のＰＤＩテーブルを受信したＰＤＩエンジン４０３０はＰＤＩ記憶装置にアクセスし、あらかじめ記憶されている第１のＰＤＩテーブルを探索することができる。その後、本発明の一実施例に係るＰＤＩエンジン４０３０は、第２のＩＤと第１のＩＤとを比較することができる。比較の結果、第２のＩＤと第１のＩＤとが同一であれば、第１のＰＤＩ回答を第２のＰＤＩタイプエレメント４０２２に追加及び／又は修正することができる。
【０９１２】
結論的に、本発明の一実施例に係る受信機は、あらかじめ記憶されているＰＤＩ質問と同一のＰＤＩ質問を受信する場合、ＰＤＩ質問を重複してディスプレイせず、あらかじめ記憶されているＰＤＩ回答を用いて処理することができる。したがって、本発明の一実施例に係る個人化放送システム上で、使用者は同一のＰＤＩ質問に対して同一の内容のＰＤＩ回答を重複して入力しなくて済むため、使用者はより便利に個人化サービスを受けることができる。
【０９１３】
図７０は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０９１４】
具体的には、図７０は、ＰＤＩ回答の重複防止のための個人化放送システムの一実施例を示す図である。図６９で説明した個人化放送システムは、ＰＤＩ回答の重複防止のために、本発明の一実施例に係る受信機にあらかじめ記憶されているＰＤＩテーブルを用いることができる。ＰＤＩ回答の重複防止のための他の実施例として、図７０ではＰＤＩ質問登録を用いる個人化放送システムを提示する。
【０９１５】
消費者が本質的に同一の質問に対して反復して急に答えないようにそれぞれ異なる放送局によって質問を再使用することを支援するために、質問は、ＡＴＳＣによって指定されるレジストラ（ｒｅｇｉｓｔｒａｒ）に登録されてもよい。各登録記録は、図４６及び図４７に明示された通り、全世界的に唯一の質問ＩＤに関する情報、質問タイプ（ＱＩＡ、ＱＢＡ、ＱＳＡ、又はＱＴＡ）、一つ以上の言語からなる質問テキスト、登録日、及び／又は登録のために質問を提出した団体に対する連絡先情報を含むことができる。また、ＱＳＡの場合、各登録記録（又は、先登録ＰＤＩ質問）は、各選択の識別子のような許容される選択、及び一つ以上の言語からなる各選択のテキストを含むことができる。
【０９１６】
ＰＤＩテーブルは、登録された質問及び登録されていない質問の混合を含むことができる。
【０９１７】
登録された質問及び登録されていない質問はいずれも複数のＰＤＩテーブルに現れてもよい。使用者が複数のＰＤＩテーブルに現れた質問に答える度に、受信機が提供する機能による場合であれ、又はアプリケーションが提供する機能による場合であれ、回答は、それが現れる全てのアンケートにある質問の全てのインスタンスに伝播されると予想される。したがって、使用者はそれが互いに異なるアンケートに何回現れるかにかかわらず、与えられた質問に１回のみ回答すればよい。
【０９１８】
使用者に質問が殺到することを防止するために、アンケート生成者は、可能な度に、登録された質問を使用し、登録された質問を得ることのできない特別なターゲット要求がある時にのみ、登録されていない質問を使用するように推奨される。
【０９１９】
本発明の一実施例に係る受信機は、受信機ターゲット基準を用いて先登録ＰＤＩ質問を抽出することができる。本発明の一実施例に係る受信機ターゲット基準は、ＡＴＳＣ ＮＲＴ標準であるＡ／１０３に従う。
【０９２０】
図７０に示すように、本発明の一実施例に係る個人化放送システムはＳＳＣ ４１００、ＦＬＵＴＥセッション４１１０、フィルタリングエンジン４１２０、ＰＤＩエンジン４１３０及び／又はＵＩ ４１４０を含むことができる。本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０サービスを提供することができる。上述した個人化放送システムの構造は、設計者の意図によって変更されてもよい。以下、図７０に示す個人化放送システムについて説明する。
【０９２１】
本発明の一実施例に係る受信機は、ＳＳＣ ４１００を介してＳＭＴ及び／又はＮＲＴ−ＩＴを受信し、ＳＭＴ及び／又はＮＲＴ−ＩＴに含まれた受信機ターゲット基準を取得することができる。本発明の受信機ターゲット基準は、受信機ターゲット記述語又は受信機ターゲット基準テーブルを一実施例とすることができる。
【０９２２】
その後、本発明の一実施例に係るＰＤＩエンジン４１３０は、取得した受信機ターゲット基準を変換してＰＤＩ質問を生成することができる。本発明の一実施例に係るＵＩ ４１４０は、ＰＤＩエンジン４１３０から上述のＰＤＩ質問を受け取ってディスプレイし、使用者のＰＤＩ回答を受信することができる。本発明の一実施例に係るＰＤＩエンジン４１３０及びＵＩ ４１４０の具体的な動作は、図５２で説明したものと同一である。
【０９２３】
図７１は、本発明の他の実施例に係るデジタル放送システムのフローチャートである。
【０９２４】
具体的には、図７１は、ＰＤＩ質問登録を用いた個人化放送システムを示す。
【０９２５】
図７１に示すように、本発明の一実施例に係る個人化放送システムは、シグナリングサーバー４２００、受信機４２１０、フィルタリングエンジン４２２０、ＰＤＩエンジン４２３０及びＵＩ ４２４０を含むことができる。受信機４２１０は、フィルタリングエンジン４２２０、ＰＤＩエンジン４２３０及び／又はＵＩ ４２４０を含む概念として用いることができ、これは、設計者の意図によって変更されてもよい。また、本発明の一実施例に係る個人化放送システムは、ＡＴＳＣ ２．０サービスを提供することができる。以下、図７１に示す個人化放送システムについて説明する。
【０９２６】
基本的な構成エレメントの動作は、図７０で説明したものと同一である。ただし、図７１に示す受信機４２１０は、シグナリングサーバー４２００にＳＭＴ及び／又はＮＲＴ−ＩＴを要求することができる。本発明の一実施例に係る受信機４２１０の要求に応じて、シグナリングサーバー４２００は当該ＳＭＴ及び／又はＮＲＴ−ＩＴを受信機４２１０に伝送することができる。
【０９２７】
本発明の一実施例に係る受信機がＳＭＴ及び／又はＮＲＴ−ＩＴを受信した後の、受信機４２１０、ＰＤＩエンジン４２３０及び／又はＵＩ ４２４０の具体的な動作は、図７０で説明したものと同一である。
【０９２８】
図７２は、本発明の一実施例に係る受信機対象基準テーブルを示す図である。
【０９２９】
具体的には、図７２は、図７０及び図７１で説明した受信機ターゲット基準をテーブル形式で表現した図である。
【０９３０】
図７２に示すように、受信機対象基準テーブルは、ターゲット基準タイプコード（ｔａｒｇｅｔｉｎｇ  ｃｒｉｔｅｒｉｏｎ  ｔｙｐｅ  ｃｏｄｅ）、ターゲット値長（ｔａｒｇｅｔｉｎｇ  ｖａｌｕｅ  ｌｅｎｇｔｈ）及び／又はターゲット値（ｔａｒｇｅｔｉｎｇ  ｖａｌｕｅ）に関する情報を含むことができる。図７２に示すターゲット基準タイプコードは、それぞれのターゲット基準を識別するためのコードを意味する。図７２に示すターゲット値長は、ターゲット基準値を示すためのバイト数を意味する。図７２に示すターゲット値は、ターゲット基準が示す情報を意味する。
【０９３１】
本発明の一実施例に係る受信機は、ターゲット基準タイプコードによってターゲット基準を変換して先登録ＰＤＩ質問を取得することができる。
【０９３２】
具体的に、本発明の一実施例に係るターゲット基準タイプコードが０ｘ００である場合、ターゲット値は保有し、ターゲット値長は定められない。
【０９３３】
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０１の場合、ターゲット値は下位３バイトのみを使用するＡ／６５の表６．２１に定義された地理的位置であり、ターゲット値長は３バイトである。上述したＡ／６５は、ＰＳＩＰ（Ｐｒｏｇｒａｍ  ａｎｄ  Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）に関するＡＴＳＣ標準である。その詳細な内容は後述する。
【０９３４】
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０２の場合、ターゲット値は当該領域に適切なバイト数（８まで）を使用するＡ／６５のセクション６．７．２に定義されたような文字と数字で書かれた郵便番号であり、ターゲット値長は可変である。その詳細な内容は後述する。
【０９３５】
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０３の場合、ターゲット値は、下位２バイトのみを使用するＡ／６５の表６．１８に定義されたような人口統計学的カテゴリーであり、ターゲット値長は２バイトである。その詳細な内容は後述する。
【０９３６】
本発明の一実施例に係るターゲット基準タイプコードが０ｘ０４−０ｘ０Ｆである場合、ターゲット値は、将来ＡＴＳＣ使用のために保有され、ターゲット値長は定められない。
【０９３７】
本発明の一実施例に係るターゲット基準タイプコードが０ｘ１０−０ｘ１Ｆである場合、ターゲット値は、私的使用が可能であり、ターゲット値長さは定められない。
【０９３８】
図７３乃至図７６は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
【０９３９】
具体的に、図７３乃至図７６は、図７２で上述したターゲット基準タイプコードが０ｘ０１である場合に、本発明の一実施例に係る先登録ＰＤＩ質問を示すテーブルである。
【０９４０】
図７３乃至図７６に示すように、ターゲット基準タイプコードが０ｘ０１の場合、本発明の一実施例に係るターゲット基準テーブルは、地理的位置に関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、下位３バイトのみを用いてターゲット基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。
【０９４１】
図７３は、ターゲット基準タイプコードが０ｘ０１である場合に、位置コード（ｌｏｃａｔｉｏｎ  ｃｏｄｅ）に関する先登録ＰＤＩ質問を示すテーブルである。図７３に示す先登録ＰＤＩ質問テーブルに含まれた先登録ＰＤＩ質問情報は、図７０で説明したものと同一である。
【０９４２】
具体的には、図７３に示すように、ターゲット基準タイプコードが０ｘ０１の場合、本発明の一実施例に係る質問ＩＤは、位置コードに関する情報を含むことができる。また、図７３に示す先登録ＰＤＩ質問はＱＴＡタイプであり、位置コードに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９４３】
次の［例示８」は、図７３に示すテーブルをＸＭＬスキーマで表す一実施例である。
【０９４４】
［例示８］
<a20:QTA id="atsc.org/PDIQ/location-code">
<a20:Q xml:lang="en-us">
<a20:Text>What is your location code?</a20:Text>
</a20:Q>
</a20:QTA>
【０９４５】
図７４は、ターゲット基準タイプコードが０ｘ０１である場合に、ＦＩＰＳ（Ｆｅｄｅｒａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｔａｎｄａｒｄｓ  Ｐｕｂｌｉｃａｔｉｏｎ）ｓｔａｔｅに関する先登録ＰＤＩ質問を示すテーブルである。図７４に示す先登録ＰＤＩ質問が含む基本的な内容は、図７０で説明したものと同一である。ただし、図７４に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
【０９４６】
具体的には、図７４に示すように、ターゲット基準タイプコードが０ｘ０１の場合に、本発明の一実施例に係る質問ＩＤは、ＦＩＰＳ ｓｔａｔｅに関する情報を含むことができる。また、図７４に示す先登録ＰＤＩ質問はＱＴＡタイプであり、ＦＩＰＳ ｓｔａｔｅに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９４７】
次の［例示９］は、図７４に示すテーブルをＸＭＬスキーマで表す一実施例である。
【０９４８】
［例示９］
<a20:QTA id="atsc.org/PDIQ/state" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What state are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
【０９４９】
図７５は、ターゲット基準タイプコードが０ｘ０１である場合に、ＦＩＰＳ ｃｏｕｎｔｒｙに関する先登録ＰＤＩ質問を示すテーブルである。図７５に示す先登録ＰＤＩ質問が含む基本的な内容は、図７０で説明したものと同一である。ただし、図７５に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
【０９５０】
具体的には、図７５に示すように、ターゲット基準タイプコードが０ｘ０１の場合に、本発明の一実施例に係る質問ＩＤは、ＦＩＰＳ ｃｏｕｎｔｒｙに関する情報を含むことができる。また、図７５に示す先登録ＰＤＩ質問はＱＴＡタイプであり、ＦＩＰＳ ｃｏｕｎｔｒｙに対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９５１】
次の［例示１０」は、図７５に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９５２】
［例示１０］
<a20:QTA id="atsc.org/PDIQ/county" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What county are you located in?</a20:Text>
</a20:Q>
</a20:QTA>
【０９５３】
図７６は、ターゲット基準タイプコードが０ｘ０１の場合に、カウンティ細分（ｃｏｕｎｔｙ  ｓｕｂｄｉｖｉｓｉｏｎ）に関する先登録ＰＤＩ質問を示すテーブルである。図７６に示す先登録ＰＤＩ質問が含む基本的な内容は、図７０で説明したものと同一である。ただし図７６に示す先登録ＰＤＩ質問は、ｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する情報をさらに含むことができ、本発明の一実施例に係るｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄに関する具体的な内容は後述する。
【０９５４】
具体的には、図７６に示すように、ターゲット基準タイプコードが０ｘ０１の場合に、本発明の一実施例に係る質問ＩＤは、自治州細分に関するセクター情報を含むことができる。また、図７６に示す先登録ＰＤＩ質問はＱＳＡタイプであり、自治州細分に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９５５】
また、本発明の一実施例に係るＱＳＡタイプの先登録ＰＤＩ質問は、ＰＤＩ回答に対する選択肢（ｓｅｌｅｃｔｉｏｎ）情報を含むことができる。例えば、図７６に示す自治州細分に関する先登録ＰＤＩ質問は、北西、北中、北東、西中、中央、東中、南西、南中、及び南東に対する９つの選択情報を含むことができる。
【０９５６】
次の［例示１１」は、テーブルをＸＭＬスキーマで表した一実施例である。
【０９５７】
［例示１１］
<a20:QSA id="atsc.org/PDIQ/sector" xactionSetId="1">
<a20:Q xml:lang="en-us">
<a20:Text>What part of your county are you located in?
</a20:Text>
<a20:Selection id="1">NW</a20:Selection>
<a20:Selection id="2">NC</a20:Selection>
<a20:Selection id="3">NE</a20:Selection>
<a20:Selection id="4">WC</a20:Selection>
<a20:Selection id="5">C</a20:Selection>
<a20:Selection id="6">EC</a20:Selection>
<a20:Selection id="7">SW</a20:Selection>
<a20:Selection id="8">SC</a20:Selection>
<a20:Selection id="9">SE</a20:Selection>
</a20:Q>
</a20:QTA>
【０９５８】
上述した図７４乃至図７６に示すｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄは、類似の内容を含むＰＤＩ質問の集合を示すことができる。本発明の一実施例に係る受信機は、同一のｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄを含む先登録ＰＤＩ質問を組み合わせて個人化放送サービスに用いることができる。
【０９５９】
例えば、図７３に示す受信機ターゲット基準は、同じｑｕｅｓｔｉｏｎ ｘａｃｔｉｏｎＳｅｔＩｄを有する図７４乃至図７６の受信機ターゲット基準と表現されてもよい。本発明の一実施例に係る受信機は、図７３に示す受信機ターゲット基準及び／又は図７４乃至図７６の受信機ターゲット基準を組み合わせた結果を用いて個人化放送サービスを提供することができる。
【０９６０】
図７７及び図７８は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
【０９６１】
具体的には、図７７及び図７８は、図７２で上述したターゲット基準タイプコードが０ｘ０２の場合に、先登録ＰＤＩ質問を示すテーブルである。
【０９６２】
図７７及び図７８に示すように、ターゲット基準タイプコードが０ｘ０２の場合に、本発明の一実施例に係るターゲット基準テーブルは文字と数字で書かれた郵便番号に関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、領域による適切な数のバイトを用いて目標基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。本発明の一実施例に係る受信機は、目標基準テーブル変換のために最大８バイトを使用することができる。
【０９６３】
図７７は、ターゲット基準タイプコードが０ｘ０２の場合に、５桁の郵便番号に関する先登録ＰＤＩ質問を示すテーブルである。５桁の郵便番号は、米国で使用する文字と数字で書かれた郵便番号を意味する。図７７に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９６４】
具体的には、図７７に示すように、ターゲット基準タイプコードが０ｘ０２の場合に、本発明の一実施例に係る質問ＩＤは、郵便番号に関する情報を含むことができる。また、図７７に示す先登録ＰＤＩ質問はＱＴＡタイプであり、郵便番号に対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９６５】
次の［例示１２］は、図７７に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９６６】
［例示１２］
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
【０９６７】
図７８は、ターゲット基準タイプコードが０ｘ０２の場合に、数字で表された郵便番号に関する先登録ＰＤＩ質問を示すテーブルである。数字で表された郵便番号は、米国以外の地域で使用する文字と数字で書かれた郵便番号を意味する。図７８に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９６８】
具体的には、図７８に示すように、ターゲット基準タイプコードが０ｘ０２の場合、本発明の一実施例に係る質問ＩＤは、郵便番号に関する情報を含むことができる。また、図７８に示す先登録ＰＤＩ質問はＱＴＡタイプであり、郵便番号に対するテキストタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９６９】
次の［例示１３］は、図７８に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９７０】
［例示１３］
<a20:QTA id="atsc.org/PDIQ/ZIPcode">
<a20:Q xml:lang="en-us">
<a20:Text>What is your 5-digit ZIP code?</a20:Text>
</a20:Q>
</a20:QTA>
【０９７１】
図７９乃至図８２は、本発明の一実施例に係る先登録ＰＤＩ質問を示す図である。
【０９７２】
具体的には、図７９乃至図８２は、図７２で上述したターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係る先登録ＰＤＩ質問を示すテーブルである。
【０９７３】
図７９乃至図８２に示すように、ターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係るターゲット基準テーブルは、使用者の人口統計カテゴリーに関する先登録ＰＤＩ質問情報を含むことができる。この場合、本発明の一実施例に係る受信機は、下位２バイトのみを用いてターゲット基準テーブルを変換し、先登録ＰＤＩ質問を取得することができる。
【０９７４】
図７９は、ターゲット基準タイプコードが０ｘ０３の場合に、使用者の性別に関する先登録ＰＤＩ質問を示すテーブルである。図７９に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９７５】
具体的には、図７９に示すように、ターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係る質問ＩＤは、性別に関する情報を含むことができる。また、図７９に示す先登録ＰＤＩ質問はＱＳＡタイプであり、使用者の性別に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９７６】
また、図７９に示す先登録ＰＤＩ質問はＱＳＡタイプであるから、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図７９に示す性別に関する先登録ＰＤＩ質問は、男性及び女性に対する２つの選択情報を含むことができる。
【０９７７】
次の［例示１４］は、図７９に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９７８】
［例示１４］
<a20:QSA id="atsc.org/PDIQ/gender" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>What is your gender?</a20:Text>
<a20:Selection id="1">Male</a20:Selection>
<a20:Selection id="2">Female</a20:Selection>
</a20:Q>
</a20:QSA>
【０９７９】
図８０は、ターゲット基準タイプコードが０ｘ０３の場合に、使用者の年齢層（ａｇｅ  ｂｒａｃｋｅｔ）に関する先登録ＰＤＩ質問を示すテーブルである。図８０に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９８０】
具体的には、図８０に示すように、ターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係る質問ＩＤは、年齢層に関する情報を含むことができる。また、図８０に示す先登録ＰＤＩ質問はＱＳＡタイプであり、年齢層に関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９８１】
また、図８０に示す先登録ＰＤＩ質問はＱＳＡタイプであるから、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図８０に示す年齢層に関する先登録ＰＤＩ質問は、２−５才、６−１１才、１２−１７才、１８−３４才、３５−４９才、５０−５４才、５５−６４才、６５才以上に関する８つの選択情報を含むことができる。
【０９８２】
次の［例示１５］は、図８０に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９８３】
［例示１５］
<a20:QSA id="atsc.org/PDIQ/age-bracket" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text> What age bracket are you in</a20:Text>
<a20:Selection id="1">Ages 2-5</a20:Selection>
<a20:Selection id="2">Ages 6-11</a20:Selection>
<a20:Selection id="3">Ages 12-17</a20:Selection>
<a20:Selection id="4">Ages 18-34</a20:Selection>
<a20:Selection id="5">Ages 35-49</a20:Selection>
<a20:Selection id="6">Ages 50-54</a20:Selection>
<a20:Selection id="7">Ages 55-64</a20:Selection>
<a20:Selection id="8">Ages 65+</a20:Selection>
</a20:Q>
</a20:QSA>
【０９８４】
図８１は、ターゲット基準タイプコードが０ｘ０３の場合に、使用者が勤労しているか否かに関する先登録ＰＤＩ質問を示すテーブルである。図８１に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９８５】
具体的には、図８１に示すように、ターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係る質問ＩＤは、勤労に関する情報を含むことができる。また、図８１に示す先登録ＰＤＩ質問はＱＳＡタイプであり、使用者が勤労しているか否かに関する選択タイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９８６】
また、図８１に示す先登録ＰＤＩ質問はＱＳＡタイプであるから、ＰＤＩ回答に対する選択情報を含むことができる。例えば、図７９に示す勤労に関する先登録ＰＤＩ質問は、はい及びいいえに関する２つの選択情報を含むことができる。
【０９８７】
次の［例示１６］は、図８１に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９８８】
［例示１６］
<a20:QSA id="atsc.org/PDIQ/working" minChoices="1">
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Text>
<a20:Selection id="1">Yes</a20:Selection>
<a20:Selection id="2">No</a20:Selection>
</a20:Q>
</a20:QSA>
【０９８９】
図８２は、ターゲット基準タイプコードが０ｘ０３の場合に、使用者の性別に関する先登録ＰＤＩ質問を示すテーブルである。図８２に示す先登録ＰＤＩ質問が含む内容は、図７０で説明したものと同一である。
【０９９０】
具体的には、図８２に示すように、ターゲット基準タイプコードが０ｘ０３の場合に、本発明の一実施例に係る質問ＩＤは、勤労に関する情報を含むことができる。また、図８２に示す先登録ＰＤＩ質問はＱＢＡタイプであり、使用者が勤労しているか否かに関するブールタイプのＰＤＩ回答を要求する内容の質問テキストを含むことができる。
【０９９１】
次の［例示１７］は、図８２に示すテーブルをＸＭＬスキーマで表した一実施例である。
【０９９２】
［例示１７］
<a20:QBA id="atsc.org/PDIQ/working" >
<a20:Q xml:lang="en-us">
<a20:Text>Are you working at a paying job?
</a20:Q>
</a20:QBA>
【０９９３】
図８３は、本発明の一実施例に係るＰＤＩ ＡＰＩを示す図である。
【０９９４】
具体的には、図８３は、上述した宣言コンテンツオブジェクト（ＤＯ）などのアプリケーションがＰＤＩデータを用いるための関数を示す図である。本発明の一実施例に係るＰＤＩ ＡＰＩは、本発明の一実施例に係る受信機がＰＤＩ記憶装置にアクセスするためのインターフェースを意味する。
【０９９５】
ＡＴＳＣ ２．０クライアント装置は、ＰＤＩ質問に対する接近（例えば、検索及び更新）を可能にするためにＰＤＩ ＡＰＩを支援する。
【０９９６】
ＡＴＳＣ ２．０ ＤＡＥの一環として提供されるＡＰＩは、記憶装置から当該質問のテキストを読み出し、（可能ならば）当該質問に対して既に提供された回答を読み出し、当該質問に対する回答を記憶するために与えられた質問のＩＤを考慮してＤＯを許容する。
【０９９７】
ＴＤＯが或る特定質問又は回答に対して接近したり記録することを防止する或る規則を定義したり実施する試みは行われない。複数の個体が与えられたチャネルで使用可能なアンケートを提供できると構想される。このような客体は、国家の伝送網事業者、ローカル放送局系列会社、様々なプログラム生産者／供給者を含むことができるが、これに制限されない。
【０９９８】
ＡＴＳＣ ２．０クライアント装置は、ＰＤＩデータ記憶及び検索のためのＡＰＩを実現する。ＰＤＩ機能を実行するために、装置は、ネイティブアプリケーション、ファイルシステム／データベースを使用したり遠隔サービスを使用してＰＤＩデータベースを提供することができる。ＰＤＩ記憶装置は、ＡＴＳＣクライアントに拘束されている。一つのＰＤＩ記憶装置インスタンスのみがクライアントのために存在する。ＰＤＩ記憶装置は、ＤＯがクライアントのＰＤＩデータに接続できるようにし、また、使用者がネイティブアプリケーションを用いて互いに異なるサービスプロバイダにわたって持続的にＰＤＩ質問を管理（例えば、更新、追加、又は削除）できるようにする。
【０９９９】
図８３は、本発明の一実施例に係るＰＤＩ ＡＰＩを示すテーブルである。本発明の一実施例に係る受信機は図８３に示すＰＤＩ ＡＰＩを用いてＰＤＩテーブルリストを取得することができる。
【１０００】
以下、図８３に示すＡＰＩについて説明する。
【１００１】
図８３に示すＡＰＩの名称は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）であり、これは設計者の意図によって変更可能な事項である。図８３に示す説明は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数の詳細内容を示す。図８３に示す引数（ａｒｇｕｍｅｎｔｓ）は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数の媒介変数を参照する。
【１００２】
より具体的には、図８３に示す説明は、ｇｅｔＰＤＩＴａｂｌｅＬｉｓｔ（）ＡＰＩ関数がそれぞれに対してｐｄｉＴａｂｌｅＩｄを提供し、ＰＤＩテーブルのリストを有するＸＭＬ構造を応答するということを示す。ＸＭＬ構造は、次のＸＭＬスキーマの通りである。一つのｐｄｉＴａｂｌｅＩｄ下位エレメントを有するｐｄｉＴａｂｌｅＬｉｓｔエレメントはカーディナリティ０を有し、無限である。０ ｐｄｉＴａｂｌｅＩｄインスタンスは、放送局がＰＤＩテーブルを提供していないということを示す。
【１００３】
図８３に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルの全世界的に唯一の識別子であるということをＵＲＩの形態で示す。
【１００４】
したがって、本発明の一実施例に係る受信機は、ＸＭＬスキーマによるテーブルフォーマットのＰＤＩテーブルリストを受信することができる。図８３に示すように、ＰＤＩテーブルリストはｐｄｉＴａｂｌｅＩｄエレメントを含むことができる。図８３に示すｐｄｉＴａｂｌｅＩｄエレメントのカーティナリティが０を示す場合は、本発明の一実施例に係る受信機が放送局からＰＤＩテーブルを受信していないということを意味できる。
【１００５】
図８４は、本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。
【１００６】
具体的には、図８４は、本発明の一実施例に係る受信機がＰＤＩテーブルを取得するためのＰＤＩ ＡＰＩを示す図である。
【１００７】
以下、図８４に示すＡＰＩについて説明する。
【１００８】
図８４に示すＡＰＩの名称はｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）であり、これは設計者の意図によって変更可能な事項である。図８４に示す説明は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の詳細内容を示す。図８４に示す引数は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の媒介変数を参照する。
【１００９】
より具体的には、図８４に示す説明は、ｇｅｔＰＤＩＴａｂｌｅ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数が受信機に対してＰＤＩテーブルＸＭＬ文書を応答するためのものであることを示す。各ｐｄｉＴａｂｌｅは、当該方法に対する入力として提供された全世界的に唯一のｐｄｉＴａｂｌｅＩｄ識別子によって識別されたのと関連している。応答された値は、連載されたＰＤＩテーブルＸＭＬインスタンスを含み、選択的にＰＤＩ−Ｑ又はＰＤＩ−Ａ ＸＭＬインスタンスを含むストリングである。
【１０１０】
図８４に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルの全世界的に唯一の識別子であるということをＵＲＩの形態で示す。
【１０１１】
したがって、本発明の一実施例に係る受信機は、図８３で説明したＰＤＩテーブルリストを受信した後に、ＰＤＩテーブルを受信することができる。具体的には、ＰＤＩテーブルリストを受信した受信機は、図８３に示すｐｄｉＴａｂｌｅＩｄに関連したＰＤＩテーブルＸＭＬ文書を受信することができる。
【１０１２】
具体的には、図８４に示すＰＤＩ ＡＰＩによる受信機の動作は、図３６乃至１０、図５２、図６３、図６５、及び図６８乃至図７１で説明したものと同一である。また、図８４に示すＰＤＩ ＡＰＩによる受信機は、図４０乃至図４７で説明したＰＤＩテーブルフォーマットによるＰＤＩテーブルリストを受信することができる。
【１０１３】
図８５は、本発明の他の実施例に係るＰＤＩ ＡＰＩを示す図である。
【１０１４】
具体的には、図８５は、本発明の一実施例に係る受信機がＰＤＩ回答を取得するためのＰＤＩ ＡＰＩを示す図である。
【１０１５】
以下、図８５に示すＡＰＩについて説明する。
【１０１６】
図８５に示すＡＰＩの名称はｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）であり、これは設計者の意図によって変更可能な事項である。図８５に示す説明は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の詳細内容を示す。図８５に示す引数は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数の媒介変数を参照する。
【１０１７】
より具体的には、図８５に示す説明は、ｇｅｔＰＤＩＡ（Ｓｔｒｉｎｇ  ｐｄｉＴａｂｌｅＩｄ）ＡＰＩ関数が受信機に対してＰＤＩ−Ａ ＸＭＬ文書を応答するためのものであることを示す。各ｐｄｉＴａｂｌｅは、当該方法に対する入力として提供された全世界的に唯一のｐｄｉＴａｂｌｅＩｄ識別子によって識別されたものと関連している。応答された値は、連載されたＰＤＩ−Ａ ＸＭＬインスタンスを含むストリングである。
【１０１８】
図８５に示す引数は、ｐｄｉＴａｂｌｅＩｄがＰＤＩテーブルの全世界的に唯一の識別子であるということをＵＲＩの形態で示す。
【１０１９】
したがって、図８３で説明したＰＤＩテーブルリストを受信した受信機は、図８３に示すｐｄｉＴａｂｌｅＩｄに関連したＰＤＩ−ＡテーブルのＸＭＬ文書（又は、ＰＤＩ−Ａインスタンス文書）を受信することができる。本発明の一実施例に係るＰＤＩ−Ａインスタンス文書は、図４６で説明したものと同一である。
【１０２０】
具体的には、図８５に示すＰＤＩ ＡＰＩによる受信機の動作は、図３６乃至１０、図５２、図６３、図６５、及び図６８乃至図７１で説明したものと同一である。
【１０２１】
図８３乃至５６に示してはいないが、本実施例に係るＰＤＩ ＡＰＩは、次の表３９及び／又は表４０のように記述できる。
【１０２２】
【表３９】
0006348184.tif 000055
【１０２３】
【表４０】
0006348184.tif 000056
【１０２４】
図８６は、本発明の一実施例に係る、次世代放送システムのためのプロトコルスタック（Ｐｒｏｔｏｃｏｌ  Ｓｔａｃｋ）を示す図である。
【１０２５】
本発明は、地上波放送網とインターネット網連動ベースの次世代ハイブリッド放送環境において、前述したＰＤＩ情報を、受信機とコンパニオンデバイスとの間で交換するための方案を提案することができる。本発明では、前述したＰＤＩ情報が受信機でのみ活用されず、コンパニオンデバイスに提供されてもよい。ユーザは、コンパニオンデバイスを活用して、ＰＤＩ情報が反映されたインタラクティブサービスの提供を受けることができる。
【１０２６】
しかし、一人のユーザが複数のコンパニオンデバイスを使用してもよい。この場合、各コンパニオンデバイスごとにＰＤＩユーザデータを設定するのなら、そのユーザは重複の応答を続けなければならない。このため、ＰＤＩユーザデータが複数のコンパニオンデバイス間に共有される必要がある。したがって、本発明は、受信機と複数個のコンパニオンデバイスとの間にＰＤＩ情報を交換／共有する方案を提案する。ここで、交換／共有されるＰＤＩ情報としては、前述したＰＤＩ  Ｑｕｅｓｔｉｏｎ、Ａｎｓｗｅｒ及び／又はフィルタリングクライテリア（Ｆｉｌｔｅｒｉｎｇ  Ｃｒｉｔｅｒｉａ）などを挙げることができる。
【１０２７】
また、本発明は、複数のユーザのＰＤＩ情報を提供／保存し、且つそれらを活用してフィルタリングされたインタラクティブサービスを提供する方法を提案する。
【１０２８】
また、本発明は、表れる値情報に対する選好度、すなわち、プレゼンテーション選好度（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）を個人化するために、受け取った関連情報をＰＤＩ  Ｑｕｅｓｔｉｏｎに変換してユーザに示す方案を提案する。また、本発明は、既に設定されたプレゼンテーション選好度をアップデートする方案も提案する。
【１０２９】
本発明に係る放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）中心ブロードキャストネットワーク（ＩＰ  ｃｅｎｔｒｉｃ  ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ）とブロードバンド（ｂｒｏａｄｂａｎｄ）とが結合されたハイブリッド放送システムとすることができる。
【１０３０】
本発明に係る放送システムは、既存のＭＰＥＧ−２ベースの放送システムとの互換性を維持するように設計されてもよい。
【１０３１】
本発明に係る放送システムは、ＩＰ中心ブロードキャストネットワーク（ＩＰ  ｃｅｎｔｒｉｃ  ｂｒｏａｄｃａｓｔ  ｎｅｔｗｏｒｋ）、ブロードバンド（ｂｒｏａｄｂａｎｄ）ネットワーク、及び／又は移動通信ネットワーク（ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｎｅｔｗｏｒｋ又はｃｅｌｌｕｌａｒ  ｎｅｔｗｏｒｋ）の結合に基づくハイブリッド放送システムであってもよい。
【１０３２】
図面を参照すると、物理層（Ｐｈｙｓｉｃａｌ  ｌａｙｅｒ）は、ＡＴＳＣシステム及び／又はＤＶＢシステムのような放送システムで採用する物理的プロトコルを用いることができる。例えば、本発明に係る物理層では、送／受信機は、地上波放送信号を送信／受信し、放送データを含む伝送フレーム（ｔｒａｎｓｐｏｒｔ  ｆｒａｍｅ）を適切な形態に変換することができる。
【１０３３】
暗号化（Ｅｎｃａｐｓｕｌａｔｉｏｎ）層では、物理層から取得された情報から、ＩＰデータグラム（ｄａｔａｇｒａｍ）を取得したり、取得されたＩＰデータグラムを特定フレーム（例えば、ＲＳ  Ｆｒａｍｅ、ＧＳＥ−ｌｉｔｅ、ＧＳＥ或いは信号フレームなど）に変換する。ここで、フレームは、ＩＰデータグラムの集合を含むことができる。例えば、暗号化層で送信機は、物理層で処理されたデータを伝送フレームに含めたり、受信機は、物理層から取得した伝送フレームからＭＰＥＧ−２ＴＳ、ＩＰデータグラムを抽出する。
【１０３４】
ＦＩＣ（ｆａｓｔ  ｉｎｆｏｒｍａｔｉｏｎ  ｃｈａｎｎｅｌ）は、サービス及び／又はコンテンツに接近可能にするための情報（例、サービスＩＤとフレーム間のマッピング情報など）を含む。ＦＩＣは、ＦＡＣ（Ｆａｓｔ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）と呼ぶこともできる。
【１０３５】
本発明の放送システムは、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＡＬＣ／ＬＣＴ（Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ／Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ  Ｔｒａｎｓｐｏｒｔ）、ＲＣＰ／ＲＴＣＰ（Ｒａｔｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）などのプロトコルを用いることができる。これらのプロトコル間のスタック（ｓｔａｃｋ）は、図面に示す構造を参照することができる。
【１０３６】
本発明の放送システムで、データは、ＩＳＯＢＭＦＦ（ＩＳＯ  ｂａｓｅ  ｍｅｄｉａ  ｆｉｌｅ  ｆｏｒｍａｔ）形態で伝送することができる。ＥＳＧ（Ｅｌｅｃｔｒｉｃａｌ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、ＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）、Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）及び／又は一般データをＩＳＯＢＭＦＦの形態で伝送することができる。
【１０３７】
ブロードキャストネットワークによるデータの伝送は、リニアコンテンツ（ｌｉｎｅａｒ  ｃｏｎｔｅｎｔ）の伝送及び／又はノン−リニアコンテンツ（ｎｏｎ−ｌｉｎｅａｒ  ｃｏｎｔｅｎｔ）の伝送を含むことができる。
【１０３８】
ＲＴＰ／ＲＴＣＰベースのＡ／Ｖ、Ｄａｔａ（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｍｅｓｓａｇｅなど）伝送は、リニアコンテンツの伝送に該当し得る。
【１０３９】
ＲＴＰ  ｐａｙｌｏａｄは、ＮＡＬ（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ）が含まれたＲＴＰ／ＡＶストリーム形態及び／又はＩＳＯＢＭＦＦで暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＲＴＰ  ｐａｙｌｏａｄの伝送は、リニアコンテンツの伝送に該当し得る。ＩＳＯＢＭＦＦで暗号化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧ  ＤＡＳＨメディアセグメントを含むことができる。
【１０４０】
ＦＬＵＴＥベースＥＳＧの伝送、ノン−タイムドデータ（ｎｏｎ−ｔｉｍｅｄ  ｄａｔａ）の伝送、ＮＲＴコンテンツの伝送は、ノン−リニアコンテンツの伝送に該当し得る。これらは、ＭＩＭＥタイプのファイル形態及び／又はＩＳＯＢＭＦＦで暗号化（ｅｎｃａｐｓｕｌａｔｉｏｎ）された形態で伝送されてもよい。ＩＳＯＢＭＦＦで暗号化された形態の伝送は、Ａ／Ｖなどに対するＭＰＥＧ  ＤＡＳＨメディアセグメントを含むことができる。
【１０４１】
ブロードバンドネットワークによる伝送は、コンテンツに対する伝送とシグナリングデータに対する伝送とに区分して考えることができる。
【１０４２】
コンテンツの伝送は、リニアコンテンツ（Ａ／Ｖ、ｄａｔａ、ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ、ｅｍｅｒｇｅｎｃｙ  ａｌｅｒｔ  ｍｅｓｓａｇｅなど）の伝送とノン−リニアコンテンツ（ＥＳＧ、ｎｏｎ−ｔｉｍｅｄ  ｄａｔａなど）の伝送、ＭＰＥＧ  ＤＡＳＨベースのメディアセグメント（Ａ／Ｖ、ｄａｔａ）伝送を含む。
【１０４３】
シグナリングデータの伝送は、放送網で伝送されるシグナリングテーブル（ｓｉｇｎａｌｉｎｇ  ｔａｂｌｅ）（ＭＰＥＧ  ＤＡＳＨのＭＰＤを含む。）を含む伝送が可能である。
【１０４４】
本発明の放送システムでは、放送網で伝送されたリニア／ノン−リニアコンテンツ間の同期化、或いは放送網で伝送されるコンテンツとブロードバンドで送信されたコンテンツ間の同期化を支援することができる。例えば、一つのＵＤコンテンツが放送網とブロードバンドとに分けて同時に伝送される場合、受信機は、伝送プロトコルに依存したタイムラインを調整し、放送網のコンテンツとブロードバンドのコンテンツを同期化した後、一つのＵＤコンテンツとして再構成することができる。
【１０４５】
本発明の放送システムのアプリケーション（Ａｐｐｌｉｃａｔｉｏｎｓ）層は、両方向性（Ｉｎｔｅｒａｃｔｉｖｉｔｙ）、個人化（Ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）、セカンドスクリーン（Ｓｅｃｏｎｄ  Ｓｃｒｅｅｎ）、ＡＣＲ（ａｕｔｏｍａｔｉｃ  ｃｏｎｔｅｎｔ  ｒｅｃｏｇｎｉｔｉｏｎ）などの技術的特徴を具現することができる。このような特徴は、例えば、北−米放送標準であるＡＴＳＣ２．０からＡＴＳＣ３．０への拡張において重要な特徴である。例えば、両方向性の特徴のために、ＨＴＭＬ５を用いることができる。
【１０４６】
本発明の放送システムのプレゼンテーション（Ｐｒｅｓｅｎｔａｔｉｏｎ）層では、コンポーネント間又は両方向アプリケーション間の空間的、時間的関係を識別するために、ＨＴＭＬ及び／又はＨＴＭＬ５を用いることができる。
【１０４７】
本発明で、シグナリング（Ｓｉｇｎａｌｉｎｇ）は、コンテンツ及び／又はサービスの効果的な取得を支援するためのシグナリング情報を含む。シグナリングデータは、バイナリ或いはＸＭＬ形態などで表現することができ、地上波放送網或いはブロードバンドで伝達することができる。
【１０４８】
実時間放送Ａ／Ｖコンテンツ及び／又はデータ（Ｄａｔａ）の場合、ＩＳＯＢＭＦＦなどで表現することができる。この場合、放送Ａ／Ｖコンテンツ及び／又はデータは、地上波放送網を介して実時間で伝達されてもよく、ＩＰ／ＵＤＰ／ＦＬＵＴＥに基づいて非実時間で伝達されてもよい。又は、放送Ａ／Ｖコンテンツ及び／又はデータは、インターネット網を介してＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）などによって実時間でストリーミングされてもよく、要求に応じて提供されてもよい。本発明の一実施例に係る放送システムは、このようにして受け取った放送Ａ／Ｖコンテンツ及び／又はデータを組み合わせて、両方向性サービス、セカンドスクリーンサービスなどの様々な向上したサービス（ｅｎｈａｎｃｅｄ  ｓｅｒｖｉｃｅ）を視聴者に提供することができる。
【１０４９】
図８７は、本発明の一実施例に係るＵＰｎＰ方式のアクション（Ａｃｔｉｏｎ）メカニズムを示す図である。
【１０５０】
まず、本発明における機器間コミュニケーションについて説明する。
【１０５１】
機器間コミュニケーションとは、機器間にメッセージ／命令（ｃｏｍｍａｎｄ）／コール（ｃａｌｌ）／アクション（ａｃｔｉｏｎ）／要求（ｒｅｑｕｅｓｔ）／応答（ｒｅｓｐｏｎｓｅ）を交換することを意味することができる。
【１０５２】
機器間にメッセージを所望の対象機器に安定して伝達するために、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）の他にも、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）などの様々なプロトコルを適用することができる。このとき、本発明は特定プロトコルに限定されない。
【１０５３】
機器間コミュニケーションに用いられるメッセージに様々な情報を含めるために、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）、ＸＭＰＰ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍｅｓｓａｇｉｎｇ  ａｎｄ  Ｐｒｅｓｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などの様々なプロトコルを適用することができる。このとき、本発明は特定プロトコルに限定されない。
【１０５４】
機器間コミュニケーションに用いられるメッセージを伝達するとき、各プロトコルが定義するメッセージヘッダー／メッセージボディーなどの様々なコンポーネントを活用することができる。すなわち、各メッセージコンポーネントにデータを保存して伝達することができ、特定メッセージコンポーネントに限定されない。また、メッセージで伝達されるデータは、各プロトコルが定義する様々なタイプ（ｓｔｒｉｎｇ、ｉｎｔｅｇｅｒ、ｆｌｏａｔｉｎｇ  ｐｏｉｎｔ、ｂｏｏｌｅａｎ、ｃｈａｒａｃｔｅｒ、ａｒｒａｙ、ｌｉｓｔなど）で伝達されてもよい。複雑な内容のデータを構造的に表現／伝達／保存するために、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、ＸＨＴＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｈｙｐｅｒｔｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）などのマークアップ（Ｍａｒｋｕｐ）方式、或いはテキスト、イメージフォーマットなどを適用することができる。このとき、本発明は特定方式に限定されない。
【１０５５】
また、機器間コミュニケーションに用いられるメッセージは、データを圧縮して伝達してもよいが、本発明は、特定方式の圧縮機術を適用することに限定されない。
【１０５６】
前述した本発明における機器間コミュニケーションに関する説明の一方式であるＵＰｎＰ方式について説明する。ＵＰｎＰ方式は、前述した機器間コミュニケーションに関する説明のうち、ＩＰ−ＴＣＰ／ＵＤＰ−ＨＴＴＰのプロトコルが組み合わされた場合に当たる。
【１０５７】
図示された本発明の一実施例に係るＵＰｎＰ方式のアクション（Ａｃｔｉｏｎ）メカニズムとは、ＵＰｎＰコントロールポイントとＵＰｎＰデバイス間のコミュニケーションメカニズムを意味することができる。ここで、ＵＰｎＰコントロールポイントｔ８７０１０は、ＨＴＴＰクライアントとし、ＵＰｎＰデバイスｔ８７０２０は、ＨＴＴＰサーバーとすることができる。ＵＰｎＰコントロールポイントｔ８７０１０は、アクションだと呼ばれる一種のメッセージを、ＵＰｎＰデバイスｔ８７０２０に伝達し、ＵＰｎＰデバイスｔ８７０２０に特定の動作を行わせることができる。
【１０５８】
ここで、ＵＰｎＰコントロールポイントｔ８７０１０とＵＰｎＰデバイスｔ８７０２０は、ペアリングされていてもよい。ペアリングは、各デバイス間にディスカバリ及びデスクリプション伝達過程を行ってなることができる。ＵＰｎＰコントロールポイントは、ペアリング過程によってコントロールＵＲＬを取得することができる。
【１０５９】
ＵＰｎＰコントロールポイントｔ８７０１０は、各アクションをＸＭＬの形態で表示することができる。ＵＰｎＰコントロールポイントｔ８７０１０は、ＨＴＴＰで定義したＰＯＳＴメソッドｔ８７０３０を用いて、取得したコントロールＵＲＬに伝達することができる。各アクションは、一種のメッセージであって、実際に伝達しようとするデータであってもよく、これは、ＨＴＴＰ  ＰＯＳＴメッセージボディーにＸＭＬ形態で伝達されてもよい。ここで、各アクションは、名前（Ｎａｍｅ）、アーギュメント（ａｒｇｕｍｅｎｔｓ）、及び関連データを含むことができる。ＨＴＴＰ  ＰＯＳＴメッセージボディーは、各アクションの名前及び／又はアーギュメントを伝達することができる。
【１０６０】
このとき、各アクションは、同じコントロールＵＲＬに伝達されてもよい。ＵＰｎＰデバイスｔ８７０２０は、受け取ったアクションをＸＭＬパーサー（ｐａｒｓｅｒ）を用いてパーシングを行うことができる。ＵＰｎＰデバイスｔ８７０２０は、パースした各アクションによって該当の動作を行うことができる。
【１０６１】
ＵＰｎＰプロトコルの場合、各アクションを名前（Ｎａｍｅ）によって定義して用いることができる。また、ＨＴＴＰ  ＰＯＳＴメッセージボディーにアクション名（Ｎａｍｅ）も共に伝達されるため、対象機器に対するＵＲＬが一つのみ存在し、ＨＴＴＰ  ＰＯＳＴメソッドも一つのみ用いられても、無限な種類のアクションを交換することができる。
【１０６２】
図８８は、本発明の一実施例に係るＲＥＳＴメカニズムを示す図である。
【１０６３】
前述した本発明における機器間コミュニケーションに関する説明の一方式であるＲＥＳＴ方式について説明する。
【１０６４】
図示された本発明の一実施例に係るＲＥＳＴメカニズムは、ＲＥＳＴクライアントｔ８８０１０とＲＥＳＴサーバーｔ８８０２０間のコミュニケーションメカニズムを意味することができる。ここで、ＲＥＳＴクライアントｔ８８０１０はＨＴＴＰクライアントであり、ＲＥＳＴサーバーｔ８８０２０はＨＴＴＰサーバーであってもよい。前述と同様に、ＲＥＳＴクライアントは、アクションと呼ばれる一種のメッセージを、ＲＥＳＴサーバーｔ８８０２０に伝達し、ＲＥＳＴサーバーｔ８８０２０に特定の動作を行わせることができる。
【１０６５】
本実施例で、ＲＥＳＴクライアントｔ８８０１０は、各アクションをＵＲＩを介してＲＥＳＴサーバーｔ８８０２０に伝達することができる。各アクションにはアクション名（Ｎａｍｅ）が必須でなくてもよい。各アクションは、アーギュメントとデータだけを含んでもよい。
【１０６６】
ここで、ＨＴＴＰメソッドのうち、ＰＯＳＴの他にも、ＧＥＴ、ＨＥＡＤ、ＰＵＴ、ＤＥＬＥＴＥ、ＴＲＡＣＥ、ＯＰＴＩＯＮＳ、ＣＯＮＮＥＣＴ、ＰＡＴＣＨなどの様々なメソッドが用いられてもよい。また、コミュニケーションを行う対象機器に接近するＵＲＩが複数個定義されてもよい。これらの特徴から、アクション名の定義なしでもアクションを伝達することができる。かかるＲＥＳＴ方式に必要な複数のＵＲＩ値は、ディスカバリ或いはデスクリプション伝達過程で取得することができる。
【１０６７】
伝達が必要なデータ又はアーギュメントが、該当のＵＲＩに付加して（ａｐｐｅｎｄｅｄ）伝達されてもよく、又はＨＴＴＰボディーに様々な形態（ＸＭＬ、ＪＳＯＮ、ＨＴＭＬ、ＴＥＸＴ、ＩＭＡＧＥなど）で含まれて伝達されてもよい。
【１０６８】
ＲＥＳＴサーバーｔ８８０２０は、受け取ったアクションによって特定動作を行うことができる。
【１０６９】
前述した機器間コミュニケーションは一実施例に過ぎず、本発明で提案する全ての内容はＵＰｎＰ方式などに限定されない。
【１０７０】
図８９は、本発明の一実施例に係る受信機とコンパニオンデバイス間のユーザデータ交換の構造を示す図である。
【１０７１】
前述したように、本発明は、ＰＤＩユーザデータを、レシーバと他のコンパニオンデバイスの間で交換／伝達する方法を提案する。
【１０７２】
ここで、コンテンツプロバイダ又はブロードキャスタｔ８９０１０、ＰＤＩ質問紙ｔ８９０２０、ＰＤＩエンジンｔ８９０３０、ＰＤＩストアｔ８９０４０は、前述した同名のモジュールと同一であってもよい。
【１０７３】
前述したように、コンテンツプロバイダ又はブロードキャスタｔ８９０１０が生成したＰＤＩ質問紙ｔ８９０２０を受信機ｔ８９０５０に伝達することができる。ＰＤＩエンジンｔ８９０３０はユーザに当該質問紙を提供して答弁（Ａｎｓｗｅｒ）を受け、それをＰＤＩストアｔ８９０４０に保存することができる。実施例によって、ユーザに質問の答弁を誘導せず、受信機内で自動で答弁が書き込まれてもよい。
【１０７４】
ユーザにＱｕｅｓｔｉｏｎａｒｅを見せ、答弁を保存するメカニズムは、前述した実施例と同一であってもいが、これは一実施例にすぎない。本発明はこれに限定されない。
【１０７５】
前述したように、ＰＤＩストアｔ８９０４０は受信機ｔ８９０５０内に含まれている。しかし、実施例によって、受信機の外部にＰＤＩクラウドストアｔ８９０７０が存在してもよい。ＰＤＩクラウドストアｔ８９０７０は、前述したＰＤＩストアｔ８９０４０と同じ動作を行うことができる。ただし、ＰＤＩクラウドストアｔ８９０７０は、受信機ｔ８９０５０の外部に位置して、クラウドサーバーとして動作することができる。
【１０７６】
本実施例で、受信機ｔ８９０５０は、コンパニオンデバイスモジュールｔ８９０６０をさらに含むことができる。保存されたＰＤＩユーザデータは、コンパニオンデバイスモジュールｔ８９０６０を介してコンパニオンデバイスｔ８９０８０に伝達することができる。逆に、コンパニオンデバイスモジュールｔ８９０６０を介して、コンパニオンデバイスで設定された答弁がレシーバに伝達されてもよい。
【１０７７】
本発明は、ＵＰｎＰに基づいて、受信機とコンパニオンデバイス間のコミュニケーション実施例を説明する。
【１０７８】
しかし、受信機とコンパニオンデバイス間のコミュニケーションプロトコルは、これに限定されない。
【１０７９】
図９０は、本発明の一実施例に係るＰＤＩユーザデータの一部を示す図である。
【１０８０】
図９１は、本発明の一実施例に係るＰＤＩユーザデータの他の一部を示す図である。
【１０８１】
両図は一つの図であるが、紙面上の制約によって２つの図に分けて示す。
【１０８２】
図示されたＰＤＩユーザデータは、前述したＰＤＩＴａｂｌｅの他の実施例であってもよい（ＸＭＬ形態）。すなわち、交換されるＰＤＩユーザデータの一実施例は、前述したＰＤＩテーブルであってもよい。
【１０８３】
ＰＤＩＵｓｅｒＤａｔａは、一つ以上の質問エレメントを含むルートエレメントであってもよい。
【１０８４】
＠ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、前述したＰＤＩＴａｂｌｅ内の＠ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと同一であってもよい。＠ｕｓｅｒＤａｔａＩｄは、前述したＰＤＩＴａｂｌｅ内の＠ｐｄｉＴａｂｌｅＩｄと同一であってもよい。＠ｕｓｅｒＤａｔａＶｅｒｓｉｏｎは、前述したＰＤＩＴａｂｌｅ内の＠ｐｄｉＴａｂｌｅＶｅｒｓｉｏｎと同一であってもよい。＠ｔｉｍｅは、前述したＰＤＩＴａｂｌｅ内の＠ｔｉｍｅと同一であってもよい。
【１０８５】
ＱｘＡ（すなわち、ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、ＱＡＡ）は、前述したＰＤＩＴａｂｌｅ内のＱｘＡの他の実施例であってもよい。本実施例で、各ＱｘＡは、前述と同じ意味を有するが、内部構造はやや異なってもよい。各ＱｘＡの内部構造は、ＱｘＡＴｙｐｅエレメントに表現されている。例えば、ＱＩＡの構造はＱＩＡＴｙｐｅフィールドに表現されている。
【１０８６】
ＱｘＡ下の＠ｉｄは、前述したＰＤＩＴａｂｌｅ内の＠ｉｄと同一であってもよい。ＱｘＡ下の＠ｅｘｐｉｒｅは、前述したＰＤＩＴａｂｌｅ内の＠ｅｘｐｉｒｅと同一であってもよい。
【１０８７】
ＱｘＡ下のＱは、前述したＰＤＩＴａｂｌｅ内のＱと同一であってもよい。本実施例で、Ｑエレメントは、質問のテキストを表現するＱＴｅｘｔエレメントを有することができる。ＱｘＡ下の＠ｌａｎｇは、前述したＰＤＩＴａｂｌｅ内の＠ｌａｎｇと同一であってもよいが、本実施例ではＱＴｅｘｔエレメント下に位置してもよい。
【１０８８】
ＱｘＡ下のＡは、前述したＰＤＩＴａｂｌｅ内のＡと同一であってもよい。本実施例で、Ａエレメントは、実際答弁情報を有する＠ａｎｓｗｅｒを有することができる。ＱｘＡ下の＠ｔｉｍｅは、前述したＰＤＩＴａｂｌｅ内の＠ｔｉｍｅと同一であってもよい。
【１０８９】
ＱＩＡ下の＠ｌｏＥｎｄ、＠ｈｉＥｎｄは、前述したＰＤＩＴａｂｌｅ内の＠ｌｏＥｎｄ、＠ｈｉＥｎｄと同一であってもよいが、本実施例ではＱエレメント下に位置してもよい。
【１０９０】
ＱＳＡ下の＠ｍｉｎＣｈｏｉｃｅｓ、＠ｍａｘＣｈｏｉｃｅｓは、前述したＰＤＩＴａｂｌｅ内の＠ｍｉｎＣｈｏｉｃｅｓ、＠ｍａｘＣｈｏｉｃｅｓと同一であってもよいが、本実施例ではＱエレメント下に位置してもよい。ＱＳＡ下のＳｅｌｅｃｔｉｏｎエレメント及び＠ｓｅｌｅｃｔｉｏｎＩｄは、前述したＰＤＩＴａｂｌｅ内のＳｅｌｅｃｔｉｏｎエレメント及びその下位の＠ｉｄと同一であってもよい。
【１０９１】
ＱＴＡ下のＡは、＠ｌａｎｇを有することができるが、これは、前述したＰＤＩＴａｌｂｅのＱＴＡのＡエレメントの＠ｌａｎｇと同一であってもよい。
【１０９２】
前述したように、ＱＡＡの場合、Ｑエレメントがなくてもよい。
【１０９３】
ＱｘＡＤは、答弁のデータタイプによって分類されるＱ＆Ａドキュメントを意味することができる。すなわち、ＱｘＡＤには、実際の質問と答弁に関連したＱｘＡエレメントと＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎが含まれてもよい。ｘは、データタイプによって、Ｉ（ｉｎｔｅｇｅｒ）、Ｂ（Ｂｏｏｌｅａｎ）、Ｓ（Ｓｅｌｅｃｔｉｏｎ）、Ｔ（ｔｅｘｔ）、Ａ（ｗｉｔｈｏｕｔ  ｑｕｅｓｔｉｏｎ）の一つに該当し得る。
【１０９４】
図示されたＰＤＩユーザデータのうち、ｔ９１０１０で表示された部分は実施例によって省略されてもよい。
【１０９５】
前述したＰＤＩユーザデータは、ＰＤＩユーザデータの一実施例に過ぎず、本発明のＰＤＩユーザデータは特別な形態に限定されない。
【１０９６】
図９２は、本発明の一実施例に係るサービスの、サービスタイプ及びサービスＩＤを示す図である。
【１０９７】
まず、ＰＤＩユーザデータを交換するためには、受信機とコンパニオンデバイス間の互換性のためにデバイスタイプが定義される必要がある。デバイスタイプの一実施例は、次のとおりである。
【１０９８】
ＵＰｎＰ  Ｄｅｖｉｃｅ  Ｔｙｐｅ：ｕｒｎ：ａｔｓｃ．ｏｒｇ：ｄｅｖｉｃｅ：ａｔｓｃ３．０ｒｃｖｒ
【１０９９】
定義されたデバイスタイプと合わないときには、本発明で提案するＰＤＩユーザデータ交換に関連したサービスを活用できない場合がありうる。
【１１００】
定義されたデバイスタイプを支援する受信機とコンパニオンデバイスの間に、ＰＤＩユーザデータを交換するためには、サービスタイプ及び／又はサービスＩＤが定義される必要がある。ＵｓｅｒＤａｔａサービスを定義することができるが、ここで、ＵｓｅｒＤａｔａサービスとは、定義されたデバイスタイプを支援する受信機とコンパニオンデバイスの間にＰＤＩユーザデータを交換するためのサービスを意味することができる。ＵｓｅｒＤａｔａサービスによってＰＤＩユーザデータ又はＰＤＩテーブルをコンパニオンデバイスに伝達したり、伝達を受けることができる。
【１１０１】
図示されたサービスタイプ及びサービスＩＤの両実施例ｔ９２０１０、ｔ９２０２０で、サービス名は”ＵｓｅｒＤａｔａ”、サービスタイプは”ａｔｓｃ３．０ｕｓｅｒｄａｔａ：１”、サービスＩＤはそれぞれ”ｕｒｎ：ａｔｓｃ．ｏｒｇ：ｓｅｒｖｃｅＩｄ：ａｔｓｃ３．０ｕｓｅｒｄａｔａ１”又は”ｕｒｎ：ａｔｓｃ．ｏｒｇ：ｓｅｒｖｃｅＩｄ：ａｔｓｃ３．０ｕｓｅｒｄａｔａ”であってもよい。
【１１０２】
図９３は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスの状態変数（ｓｔａｔｅ  ｖａｒｉａｂｌｅ）を示す図である。
【１１０３】
前述したＵＰｎＰ  ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータを交換するために、ＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔ、ＵｓｅｒＤａｔａＬｉｓｔ及び／又はＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａ状態変数を定義することができる。
【１１０４】
データ伝達に関して、イベント方式とアクション方式を挙げることができる。イベント方式は、コンパニオンデバイスが受信機に自身を登録しておけば、受信機が、特定の情報が変わったりした場合、自動でコンパニオンデバイスに伝達する方式を意味することができる。アクション方式は、コンパニオンデバイスが受信機に特定の情報を要求する方式を意味することができる。
【１１０５】
前述した４つのＵｓｅｒＤａｔａサービスの状態変数は、必須状態変数（Ｒｅｑ）であって、前述したイベント方式ではなくアクション方式にしたがうことができ、そのために、様々なアクションのアーギュメントとして用いられてもよい。
【１１０６】
ＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、デバイスが支援するＵｓｅｒＤａｔａサービスのプロトコルバージョンを示すことができる。ボン状態変数から、各デバイス（受信機、コンパニオンデバイスなど）が個人化（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）のためのＵｓｅｒＤａｔａサービスを支援するか否かが分かる。この状態変数は、ｂｉｎ又はｈｅｘのデータタイプを有することができる。最初の４ビットはメジャーバージョンナンバー、その次の４ビットはマイナーバージョンナンバーを意味することができる。例えば、０００１００１０の値を有する場合、バージョン１．２であることが分かる（メジャーバージョンナンバー：１、マイナーバージョンナンバー：２）。このバージョン情報は、前述したＰＤＩユーザデータの＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ又は後述するＵｓｅｒＤａｔａＬｉｓｔ状態変数のｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ情報とマッチさせるために用いることができる。
【１１０７】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔは、前述したＰＤＩストアに保存されているＰＤＩユーザデータのＩＤを含むリストを示すことができる。後述するＵｓｅｒＤａｔａＬｉｓｔ状態変数のｕｓｅｒＤａｔａＩｄをストリング（ｓｔｒｉｎｇ）形態のリストで表現することができる。したがって、ＵｓｅｒＤａｔａＬｉｓｔ状態変数のｕｓｅｒＤａｔａＩｄに関連したアクションのために活用されてもよい。この状態変数は、Ｌｉｓｔデータタイプ（例えば、ＣＳＶ）を有することができる。
【１１０８】
ＵｓｅｒＤａｔａＬｉｓｔは、ＰＤＩユーザデータを含めるリストの役割を担うことができる。この状態変数は、複数個の質問紙と答弁を含むことができる。この状態変数は、後述するＧｅｔＵｓｅｒＤａｔａ（）アクションで活用されてもよい。この状態変数の詳細な構造については後述する。
【１１０９】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａは、前述したＵｓｅｒＤａｔａＬｉｓｔの一フラグメントであってもよい。このとき、両状態変数は同じマークアップ言語（ｍａｒｋ  ｕｐ  ｌａｎｇｕａｇｅ）にしたがうことができる。例えば、ＵｓｅｒＤａｔａＬｉｓｔ状態変数がＸＭＬ文書である場合、Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａは、そのＸＭＬ文書の一フラグメントになり得る。この状態変数は、複数個のＰＤＩＵｓｅｒＤａｔａエレメントと属性（ａｔｔｒｉｂｕｔｅｓ）を有することができる。また、この状態変数は、用いられるアクションの用途によってサブエレメントを含むことができる。Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａは、実施例によって省略されてもよい。
【１１１０】
図９４は、本発明の一実施例に係るＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造を示す図である。
【１１１１】
ＵｓｅｒＤａｔａＬｉｓｔは、複数個のＰＤＩＵｓｅｒＤａｔａを含むことができる。各ＰＤＩＵｓｅｒＤａｔａは、前述したＰＤＩユーザデータ又はＰＤＩテーブルに該当し得る。ＰＤＩＵｓｅｒＤａｔａのエレメント及び属性（ａｔｔｒｉｂｕｔｅ）は、前述のとおりである。実施例によって、他の形態でＰＤＩＵｓｅｒＤａｔａの構造が変更されてもよい。
【１１１２】
一番目のＵｓｅｒＤａｔａＬｉｓｔ（ｔ９４０１０）は、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”であるＰＤＩＵｓｅｒＤａｔａと、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ２”であるＰＤＩＵｓｅｒＤａｔａを含むことができる。
【１１１３】
ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”であるＰＤＩＵｓｅｒＤａｔａは、ＱＩＡタイプを有するｑｕｅｓｔｉｏｎ１を含むことができる。ｑｕｅｓｔｉｏｎ１は、”ｗｈａｔ  ｉｓ  ｙｏｕｒ  ａｇｅ”のような質問を有することができ、また、２０１４年６月２日に答えた”２１”という答弁を有することができる。”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ２”であるＰＤＩＵｓｅｒＤａｔａも、前述したＰＤＩＵｓｅｒＤａｔａによって、情報を有することができる。
【１１１４】
二番目のＵｓｅｒＤａｔａＬｉｓｔ（ｔ９４０２０）は、ｕｓｅｒＤａｔａＩｄがそれぞれ”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”，”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ２”、”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａを含むことができる。各ＰＤＩＵｓｅｒＤａｔａも、前述したＰＤＩＵｓｅｒＤａｔａによって、情報を有することができる。
【１１１５】
ＵｓｅｒＤａｔａＬｉｓｔは、前述した２つの実施例のような形式で複数個のＰＤＩＵｓｅｒＤａｔａを含むことができ、各ＰＤＩＵｓｅｒＤａｔａは、前述したＰＤＩユーザデータの構造又は、実施例によって別の形態の構造を有することができる。
【１１１６】
図９５は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクション（ａｃｔｉｏｎ）を示す図である。
【１１１７】
前述したＵｓｅｒＤａｔａサービスは、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔ、ＧｅｔＵｓｅｒＤａｔａ、及び／又はＳｅｔＵｓｅｒＤａｔａアクションを含むことができる。ここで、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、非必須（Ｏｐｔｉｏｎａｌ）のアクションであってもよく、残りの３個のアクションは、必須（Ｒｅｑｕｉｒｅｄ）のアクションであってもよい。実施例によって、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、省略されてもよい。また、実施例によって、追加のアクションがさらに定義されてもよい。
【１１１８】
各アクションについては後述する。
【１１１９】
図９６は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを説明する図である。
【１１２０】
ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎアクションは、ＰＤＩユーザデータを持ってくるためのプロトコルのバージョンを確認するために用いられるアクションであってもよい。ここで、プロトコルは、受信機（或いは、Ｐｒｉｍａｒｙ  Ｄｅｖｉｃｅ）が支援しているプロトコルを意味することができる。コンパニオンデバイスは、ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎアクションから、受信機が支援するプロトコルのバージョンが分かる。
【１１２１】
ＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを用いるために、ＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎアウトプットアーギュメント（ａｒｇｕｍｅｎｔ）が定義されてもよい。
【１１２２】
ＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、デバイスによって支援されるＵｓｅｒＤａｔａサービスのプロトコルバージョン情報であり、前述したＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ状態変数と関連付いてもよい。
【１１２３】
図９７は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔ及びＧｅｔＵｓｅｒＤａｔａを説明する図である。
【１１２４】
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションを説明する。
【１１２５】
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションは、前述したＰＤＩストアに保存されたＰＤＩユーザデータのＩＤを持ってくるために用いられるアクションであってもよい。コンパニオンデバイスは、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションを用いて、受信機の内部／外部に存在するＰＤＩストアから、ＰＤＩユーザデータのＩｄ情報を持ってくることができる。このとき、ＰＤＩユーザデータのプロトコルバージョンが参照され、該当のプロトコルを支援するＰＤＩユーザデータのＩＤだけを持ってくることができる。
【１１２６】
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションを用いるために、ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎインプットアーギュメントとＵｓｅｒＤａｔａＩｄｓＬｉｓｔアウトプットアーギュメントが定義されてもよい（ｔ９７０１０）。ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎインプットアーギュメントは、ＰＤＩユーザデータのプロトコルバージョン情報であり、前述したＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａＩｄｓＬｉｓｔアウトプットアーギュメントは、ストリング（ｓｔｒｉｎｇ）形態であるＰＤＩユーザデータのＩＤのリストであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔ状態変数と関連付いてもよい。
【１１２７】
ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションが用いられると、ＵｓｅｒＤａｔａＬｉｓｔ状態変数のＰＤＩＵｓｅｒＤａｔａエレメントのうち、＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ値とインプットアーギュメントであるＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎの値とが一致するエレメントがあれば、その一致するＰＤＩＵｓｅｒＤａｔａエレメントのうち、＠ｕｓｅｒＤａｔａＩｄ値がリストとして出力されてもよい。その出力は、前述したＵｓｅｒＤａｔａＬｉｓｔアウトプットアーギュメントであり、受信機からコンパニオンデバイスに伝達されてもよい。
【１１２８】
ＧｅｔＵｓｅｒＤａｔａアクションを説明する。
【１１２９】
ＧｅｔＵｓｅｒＤａｔａアクションは、前述したＰＤＩストアに保存されたＰＤＩユーザデータを持ってくるために用いられるアクションであってもよい。コンパニオンデバイスは、ＧｅｔＵｓｅｒＤａｔａアクションを用いて、受信機の内部／外部に存在するＰＤＩストアから、ＰＤＩユーザデータを持ってくることができる。この時、前述したＵｓｅｒＤａｔａＩｄｓＬｉｓｔが参照され、そのＰＤＩＵｓｅｒＤａｔａＩｄにマッチされるＰＤＩＵｓｅｒＤａｔａだけをフラグメント形態で持ってくることができる。
【１１３０】
ＧｅｔＵｓｅｒＤａｔａアクションを用いるために、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔインプットアーギュメントとＵｓｅｒＤａｔａアウトプットアーギュメントが定義されてもよい（ｔ９７０２０）。ＵｓｅｒＤａｔａＩｄｓＬｉｓｔアーギュメントは、前述したとおりであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａアウトプットアーギュメントは、前述したＵｓｅｒＤａｔａＬｉｓｔ状態変数のフラグメントであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａアーギュメントは、ＰＤＩＵｓｅｒＤａｔａエレメントなどの情報を有することができ、ＵｓｅｒＤａｔａＬｉｓｔのデータタイプに従うことができる（例えば、ＸＭＬ）。
【１１３１】
例えば、ＧｅｔＵｓｅｒＤａｔａ（ＵｓｅｒＤａｔａＩｄｓＬｉｓｔ＝”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”、”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”）のような内容のアクションが用いられたとすれば、前述したＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造で、ＵｓｅｒＤａｔａＬｉｓｔに含まれる複数個のＰＤＩＵｓｅｒＤａｔａのうち、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”であるものと、”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるものがリターンされてもよい。このとき、リターンされるＵｓｅｒＤａｔａのＸＭＬ構造は、ｕｓｅｒＤａｔａＩｄがそれぞれ”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”、”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａだけを有することができ、”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ２”のｕｓｅｒＤａｔａＩｄを有するＰＤＩＵｓｅｒＤａｔａエレメントはなくてもよい。
【１１３２】
ここで、ＧｅｔＵｓｅｒＤａｔａアクションにおいて、アウトプットアーギュメントであるＵｓｅｒＤａｔａのＰＤＩＵｓｅｒＤａｔａエレメントの数は、インプットアーギュメントであるＵｓｅｒＤａｔａＩｄｓＬｉｓｔ内のＰＤＩＵｓｅｒＤａｔａＩｄの個数より少ない又は等しくてもよい。
【１１３３】
実施例によって、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔインプットアーギュメントを”ＡＬＬ”に設定すれば、ＰＤＩＵｓｅｒＤａｔａＩｄとは無関係に全ＰＤＩＵｓｅｒＤａｔａが要求されてもよい。
【１１３４】
前述したＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１１３５】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。また、コンパニオンデバイスは既に、活用可能なプロトコルバージョンを知っていると仮定する。
【１１３６】
前述したコンテンツプロバイダ又はブロードキャスタは、個人化されたサービスの提供のために、ＰＤＩユーザデータを受信機に伝達することができる（ｔｓ９７０１０）。ここで、ＰＤＩユーザデータは、複数個の質問であるか、或いは複数個の質問紙と答弁（Ａｎｓｗｅｒ）の組合せであってもよい。
【１１３７】
受信機は、受け取ったＰＤＩユーザデータを、前述したＰＤＩエンジンに伝達することができる（ｔｓ９７０２０）。ＰＤＩエンジンはユーザに質問紙を見せ、ユーザから各質問に該当する答弁を得ることができる（ｔｓ９７０３０）。ＰＤＩエンジンは、答弁を得たＱ＆Ａを、前述したＰＤＩストアに保存することができる（ｔｓ９７０４０）。
【１１３８】
前述したコンパニオンデバイスは、受信機からＰＤＩユーザデータを得るために、前述したＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションを行うことができる（ｔｓ９７０５０）。コンパニオンデバイスは、前述した受信機内のコンパニオンデバイスモジュールに、ＰＤＩユーザデータのＩＤを要求することができる。
【１１３９】
コンパニオンデバイスモジュールは、ＰＤＩエンジンに、コンパニオンデバイスから要求されたＰＤＩユーザデータのＩＤを要求することができる（ｔｓ９７０６０）。ＰＤＩエンジンは、該当するＰＤＩユーザデータのＩＤをＰＤＩストアから検索することができる（ｔｓ９７０７０）。その後、ＰＤＩエンジンは、検索されたＰＤＩユーザデータのＩＤを、コンパニオンデバイスモジュールに伝達することができる（ｔｓ９７０８０）。
【１１４０】
コンパニオンデバイスモジュールは、受け取ったＰＤＩユーザデータのＩＤをコンパニオンデバイスに伝達することができる（ｔｓ９７０９０）。
【１１４１】
ＰＤＩユーザデータのＩＤを得たコンパニオンデバイスは、ＰＤＩユーザデータを得るために、前述したＧｅｔＵｓｅｒＤａｔａアクションを活用することができる（ｔｓ９７１００）。コンパニオンデバイスは、受け取ったＰＤＩユーザデータのＩＤを用いて、又はインプットアーギュメントとして用いてＰＤＩユーザデータを要求することができる。
【１１４２】
コンパニオンデバイスモジュールは、ＰＤＩエンジンに該当のＰＤＩユーザデータを要求することができる（ｔｓ９７１１０）。コンパニオンデバイスモジュールは、ＰＤＩストアから該当のＰＤＩユーザデータを検索し（ｔｓ９７１２０）、検索されたＰＤＩユーザデータをコンパニオンデバイスモジュールに伝達することができる（ｔｓ９７１３０）。
【１１４３】
コンパニオンデバイスモジュールは、受け取ったＰＤＩユーザデータをコンパニオンデバイスに伝達することができる（ｔｓ９７１４０）。コンパニオンデバイスは、受け取ったＰＤＩユーザデータを保存することができる。保存されたＰＤＩユーザデータは半永久的に保存されて用いられてもよく、仮にコンパニオンデバイスに格納所がない場合には、メモリなどの空間に一時的に保存してもよい。
【１１４４】
本発明で、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａアクションを行う時点は、特定時点に限定されない。実施例によって、コンパニオンデバイスと受信機とがペアリングされた直後に各アクションが行われてもよい。また、実施例によって、コンパニオンデバイスが受信機に周期的にポーリング（ｐｏｌｌｉｎｇ）しながら要求することもできる。
【１１４５】
図９８は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスの拡張された状態変数を示す図である。
【１１４６】
特定ＵｓｅｒＤａｔａＩｄを有するＰＤＩユーザデータがアップデートされる場合、新しいＸＭＬドキュメントが生成されてもよく、新しいＸＭＬドキュメントが生成されないでｕｓｅｒＤａｔａＶｅｒｓｉｏｎだけが増加してもよい。
【１１４７】
新しいＸＭＬドキュメントが生成されないでｕｓｅｒＤａｔａＶｅｒｓｉｏｎだけが増加する方法に従う場合、前述したアクションを用いればいいが、ＰＤＩユーザデータがアップデートされる度にＸＭＬドキュメントが新しく生成される方法に従う場合には、ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎの他、特定ＰＤＩユーザデータのｕｓｅｒＤａｔａＶｅｒｓｉｏｎも参照される必要がある。
【１１４８】
そのために、前述したＵｓｅｒＤａｔａＬｉｓｔ状態変数は、Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔに拡張されてもよい。Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔは必須状態変数であってもよく、前述したアクション方式にしたがうことができる。
【１１４９】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔのデータタイプは、ストリングからストリングのリストに変更されてもよい。ストリングのリストとは、ＰＤＩストアに保存されているＰＤＩユーザデータのＩＤと当該ＩＤを有するＸＭＬドキュメントのｕｓｅｒＤａｔａＶｅｒｓｉｏｎを含むリストを意味することができる。このリストは、様々な形態で表現することができ、（ｕｓｅｒＤａｔａＩｄ，ｕｓｅｒＤａｔａＶｅｒｓｉｏｎ）形態のペアで表現されるものを一実施例とする。ＰＤＩユーザデータがアップデートされる度に新しくＸＭＬドキュメントを生成する方法に従う場合には、同じｕｓｅｒＤａｔａＩｄのＰＤＩユーザデータであっても、ｕｓｅｒＤａｔａＶｅｒｓｉｏｎによって様々なＸＭＬドキュメントがＰＤＩストアに存在してもよい。
【１１５０】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔに状態変数が拡張される場合、前述したＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔアクションのアーギュメントのうち、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔは（ｕｓｅｒＤａｔａＩｄ，ｕｓｅｒＤａｔａＶｅｒｓｉｏｎ）形態のストリングのリストを返還することができる。また、インプットアーギュメントであるＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを００００００００に設定すれば、ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎによらず、全てのｕｓｅｒＤａｔａＩｄとｕｓｅｒＤａｔａＶｅｒｓｉｏｎのペア形態のリストが要求されてもよい。また、インプットアーギュメントであるＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎを１１１１１１１１に設定すれば、最も最新のＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎに該当するｕｓｅｒＤａｔａＩｄとｕｓｅｒＤａｔａＶｅｒｓｉｏｎのペア形態のリストが要求されてもよい。
【１１５１】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔに状態変数が拡張される場合、前述したＧｅｔＵｓｅｒＤａｔａアクションのアーギュメントのうち、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔも、（ｕｓｅｒＤａｔａＩｄ，ｕｓｅｒＤａｔａＶｅｒｓｉｏｎ）形態のストリングのリストをインプットとし、全ＵｓｅｒＤａｔａＩｄｓＬｉｓｔのうち、特定のｕｓｅｒＤａｔａＩｄとｕｓｅｒＤａｔａＶｅｒｓｉｏｎとがマッチされるＰＤＩＵｓｅｒＤａｔａだけをフラグメント形態で要求することができる。さらに、インプットアーギュメントであるＵｓｅｒＤａｔａＩｄｓＬｉｓｔを”ＡＬＬ”に設定すれば、ｕｓｅｒＤａｔａＩｄ及びｕｓｅｒＤａｔａＶｅｒｓｉｏｎによらず、全ＰＤＩＵｓｅｒＤａｔａが要求されてもよい。
【１１５２】
図９９は、本発明の一実施例に係るＵｓｅｒＤａｔａサービスのアクションのうち、ＳｅｔＵｓｅｒＤａｔａを説明する図である。
【１１５３】
ＳｅｔＵｓｅｒＤａｔａアクションは、逆に、コンパニオンデバイスでＰＤＩユーザデータが設定／保存され、この設定されたＰＤＩユーザデータが受信機に伝達される時に用いられるアクションであってもよい。ＳｅｔＵｓｅｒＤａｔａアクションは、ＵｓｅｒＤａｔａＬｉｓｔをインプットアーギュメントとして有し、前述したＵｓｅｒＤａｔａＬｉｓｔ状態変数と関連付いてもよい（ｔ９９０１０）。
【１１５４】
ＳｅｔＵｓｅｒＤａｔａアクションによって伝達されたＰＤＩユーザデータを用いて、受信機内に既に保存されているＵｓｅｒＤａｔａＬｉｓｔを修正／アップデートすることができる。受信機は、受け取ったＰＤＩユーザデータを、ＰＤＩストアに保存されているＰＤＩユーザデータと比較することができる。該当のＰＤＩユーザデータがない場合、受け取ったＰＤＩユーザデータを追加することができる。該当のＰＤＩユーザデータがある場合、ＰＤＩＵｓｅｒＤａｔａの＠ｕｓｅｒＤａｔａＶｅｒｓｉｏｎを相互比較し、受け取ったＰＤＩユーザデータの＠ｕｓｅｒＤａｔａＶｅｒｓｉｏｎが高いと、受け取ったＰＤＩユーザデータにアップデートすることができる。
【１１５５】
ＳｅｔＵｓｅｒＤａｔａアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１１５６】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１１５７】
前述したコンテンツプロバイダ又はブロードキャスタは、個人化されたサービス提供のために、ＰＤＩユーザデータをコンパニオンデバイスに伝達することができる（ｔｓ９９０１０）。ここで、ＰＤＩユーザデータは、複数個の質問紙であるか、或いは複数個の質問紙と答弁（Ａｎｓｗｅｒ）の組合せであってもよい。
【１１５８】
コンパニオンデバイスはユーザに質問紙を見せ、ユーザから各質問に該当する答弁を得ることができる（ｔｓ９９０２０）。コンパニオンデバイスは、ＳｅｔＵｓｅｒＤａｔａアクションによって設定されたＰＤＩユーザデータを、前述した受信機内のコンパニオンデバイスモジュールに伝達することができる（ｔｓ９９０３０）。
【１１５９】
コンパニオンデバイスモジュールは、受け取ったＰＤＩユーザデータをＰＤＩエンジンに伝達することができる（ｔｓ９９０４０）。ＰＤＩエンジンは、ＰＤＩストアに既に保存されているＰＤＩユーザデータがあるか否か検索することができる（ｔｓ９９０５０）。ＰＤＩエンジンは検索の結果、既存の保存されているＰＤＩユーザデータがないと、新しいＰＤＩユーザデータを保存し、既存の保存されているＰＤＩユーザデータがあると、バージョン情報に従ってＰＤＩユーザデータをアップデートすることができる（ｔｓ９９０６０）。
【１１６０】
例えば、受信機のＰＤＩストアには、前述したＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造に、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”であるＰＤＩＵｓｅｒＤａｔａが保存されていてもよい。コンパニオンデバイスには、前述したＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造に、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａが保存されていてもよい。
【１１６１】
ＳｅｔＵｓｅｒＤａｔａアクションによってコンパニオンデバイスは、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａを受信機に伝達することができる。受信機のＰＤＩエンジンは、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａがＰＤＩストアに存在しないため、当該ＰＤＩＵｓｅｒＤａｔａを追加してＰＤＩストアに保存することができる。最終的に受信機のＰＤＩストアには、前述したＵｓｅｒＤａｔａＬｉｓｔのＸＭＬ構造に、ｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ１”であるＰＤＩＵｓｅｒＤａｔａ、及びｕｓｅｒＤａｔａＩｄが”ａｔｓｃ．ｏｒｇ／ｕｓｅｒｄａｔａ３”であるＰＤＩＵｓｅｒＤａｔａが共に保存されてもよい。
【１１６２】
図１００は、本発明の一実施例に係る、ＵｓｅｒＤａｔａサービスの追加された状態変数を示す図である。
【１１６３】
前述したＵＰｎＰ  ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータに変化がある場合にのみコンパニオンデバイスにＰＤＩユーザデータを伝達するために、追加の状態変数ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅを設定することができる（ｔ１０００１０）。
【１１６４】
ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅ状態変数は、ＰＤＩユーザデータが最後に修正された時間を示すことができる。この状態変数は、前述したイベント方式に従うことができ、したがって、コンパニオンデバイスが受信機にサブスクライビング（Ｓｕｂｓｃｒｉｂｉｎｇ）をしておけば、ＰＤＩユーザデータが修正される度に自動でコンパニオンデバイスに該当の状態変数が伝達される。この状態変数は必須（Ｒｅｑ）状態変数であってもよく、データタイプはｄａｔｅＴｉｍｅであってもよい。
【１１６５】
ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅ状態変数の動作シーケンスダイヤグラムの一実施例を説明する。
【１１６６】
この実施例では、新しいＰＤＩユーザデータがコンテンツプロバイダから伝達される場合を想定したが、ＰＤＩユーザデータが変更される状況はこれに限定されない。この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１１６７】
コンパニオンデバイスはＵｓｅｒＤａｔａサービスを、前述したコンパニオンデバイスモジュールにサブスクライビング（ｓｕｂｓｃｒｉｂｉｎｇ）しておくことができる（ｔｓ１０００１０）。これは、前述したイベント方式に従ったものであり、サブスクライビングによって、ＵｓｅｒＤａｔａサービスのイベント方式による通知／伝達などの動作を受けることができる。サブスクライビングは、ＰＤＩユーザデータの変更時点の前に行われさえすれば、ＰＤＩユーザデータの変更がある度に通知などを受けることができる。実施例によって、サブスクライビングはペアリングの直後になされてもよく、他の時点になされてもよい。
【１１６８】
前述したコンテンツプロバイダ又はブロードキャスタは、新しいＰＤＩユーザデータを受信機に伝達することができる（ｔｓ１０００２０）。受信機はＰＤＩエンジンに、受け取った新しいＰＤＩユーザデータを伝達することができる（ｔｓ１０００３０）。前述したように、ＰＤＩエンジンはユーザから答弁を受け（ｔｓ１０００４０）、そのＱ＆ＡをＰＤＩストアに保存することができる（ｔｓ１０００５０）。
【１１６９】
この場合、新しいＰＤＩユーザデータが伝達されたため、既に保存されていたＰＤＩユーザデータに変更が発生した。このため、ＰＤＩエンジンは、状態変数であるＵｓｅｒＤａｔａＩｄｘＣｏｕｎｔをアップデートすることができる。また、ＰＤＩエンジンは、ＵｓｅｒＤａｔａＩｄｘＣｏｕｎｔがアップデートされると、ＵｓｅｒＤａｔａＭｏｄｅｆｉｅｄＴｉｍｅ状態変数のアップデートをコンパニオンデバイスモジュールに伝達することができる（ｔｓ１０００６０）。コンパニオンデバイスモジュールは、サブスクライブされたコンパニオンデバイスに、イベントを用いて、ＰＤＩユーザデータの変化が発生したことを知らせることができる（ｔｓ１０００７０）。
【１１７０】
変化の発生が通知された後に（ｔｓ１０００７０）、コンパニオンデバイスは、前述したＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａなどのアクションによってＰＤＩユーザデータを持ってくることができる。
【１１７１】
この実施例で、新しいＰＤＩユーザデータが伝達されるのではなく、既存の保存されていたＰＤＩユーザデータの答弁が変更される場合は、ｔｓ１０００２０、ｔｓ１０００３０を除外した次の段階から行うことができる。
【１１７２】
図１０１は、本発明の一実施例に係る、ＵｓｅｒＤａｔａサービスの他の追加された状態変数を示す図である。
【１１７３】
前述したＵＰｎＰ  ＵｓｅｒＤａｔａサービスは、ＰＤＩユーザデータに変化がある場合にのみコンパニオンデバイスにＰＤＩユーザデータを伝達するために、他の追加の状態変数ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔを設定することができる（ｔ１０１０１０）。
【１１７４】
ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔ状態変数は、ＰＤＩユーザデータＩＤとそれに該当するＰＤＩユーザデータバージョンのペア形態のリストであってもよい。例えば、この状態変数は（ＵｓｅｒＤａｔａＩｄ＃１，１．０）のような形態で表現されてもよい。ＰＤＩユーザデータＩＤの変化があるか、又はＰＤＩユーザデータバージョンの変化がある場合、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔがアップデートされてもよい。ＰＤＩユーザデータＩＤの場合は、追加或いは削除されてもよく、ＰＤＩユーザデータバージョンの場合、修正される都度１ずつ増加してもよい。
【１１７５】
実施例によって、この状態変数は、ＣＳＶリストの形態であってもよい。この状態変数は、前述したイベント方式に従うことができ、このため、コンパニオンデバイスが受信機にサブスクライビング（Ｓｕｂｓｃｒｉｂｉｎｇ）をしておけば、ＰＤＩユーザデータの変化がある度に自動でコンパニオンデバイスに該当の状態変数が伝達される。この状態変数は、必須（Ｒｅｑ）状態変数であってもよい。
【１１７６】
ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔ状態変数の動作シーケンスダイヤグラムの一実施例を説明する。
【１１７７】
この実施例では、既存に保存されていたＰＤＩユーザデータの答弁（ａｎｓｗｅｒ）が変更される場合を想定したが、ＰＤＩユーザデータが変更される状況は、これに限定されない。この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１１７８】
コンパニオンデバイスがサブスクライブする過程（ｔｓ１０１０１０）は、前述したとおりである。ＰＤＩエンジンは、新しく答弁を受け、既存に保存されていた質問紙の答弁を変更することができる（ｔｓ１０１０２０）。このとき、既存のＰＤＩユーザデータが変更されたため、ＰＤＩユーザデータのバージョンもアップデートされてもよい。答弁の完了したＱ＆Ａは、ＰＤＩストアに保存されてもよい（ｔｓ１０１０３０）。
【１１７９】
ＰＤＩエンジンは、変更されたＰＤＩユーザデータバージョンに従って、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔの値をアップデートすることができる。ＰＤＩエンジンは、ＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔ状態変数のアップデートをコンパニオンデバイスモジュールに伝達することができる（ｔｓ１０１０４０）。コンパニオンデバイスモジュールは、サブスクライブされたコンパニオンデバイスに、イベントを用いて、ＰＤＩユーザデータの変化が発生したことを知らせることができる（ｔｓ１０１０５０）。
【１１８０】
コンパニオンデバイスは、変更されたＵｓｅｒＤａｔａＵｐｄａｔｅｄＬｉｓｔを参照して、既存に保存されていたＰＤＩユーザデータとそのバージョンを互いに比較することができる（ｔｓ１０１０６０）。コンパニオンデバイスは、バージョンが変更されたＰＤＩユーザデータに対して、そのＰＤＩユーザデータを持ってくるようにアクションを行うことができる。このとき、変更されたＰＤＩユーザデータだけを持ってきてもよく、全ＰＤＩユーザデータを持ってきてもよい。ＰＤＩユーザデータ要求に、前述したＧｅｔＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ、ＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａなどのアクションが用いられてもよい。
【１１８１】
図１０２は、本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスの状態変数を示す図である。
【１１８２】
受信機とコンパニオンデバイス間のＰＤＩユーザデータの交換がなされるとき、多量のデータが交換されるとオーバーロードの発生につながりうる。これを防止するために、質問と答弁のペア単位でＰＤＩユーザデータの交換を行うこともできる。Ｑ＆Ａペアを交換するために、Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ、ＵｓｅｒＤａｔａＱＡＬｉｓｔ、及び／又はＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡ状態変数が定義されてもよい。これらの状態変数は、必須状態変数（Ｒｅｑ）であり、前述したイベント方式ではなくアクション方式にしたがうことができ、このため、様々なアクションのアーギュメントとして用いられてもよい。
【１１８３】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔは、ＰＤＩストアに保存されているＱ＆ＡペアのＩＤのリストを示すことができる。この状態変数は、前述したＱｘＡＤエレメントのＱｘＡの＠ｉｄと関連したアーギュメントを用いるアクションに活用されてもよい。また、後述するＵｓｅｒＤａｔａＱＡＬｉｓｔ状態変数の＠ｉｄをリストと表現することができる。この状態変数は、実施例によって、ＣＳＶストリングの形態であってもよい。
【１１８４】
ＵｓｅｒＤａｔａＱＡＬｉｓｔは、ＰＤＩストアに保存されているＱ＆Ａペアセットを示すことができる。この状態変数は、複数個のＱｘＡＤエレメントを有することができる。この状態変数は、後述する様々なアクションで活用されてもよい。この状態変数の詳細な構造については後述する。この状態変数は、実施例によって、ストリングの形態であってもよい。
【１１８５】
Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡは、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔの一フラグメントであってもよい。このとき、両状態変数は、同じマークアップ言語（ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）にしたがうことができる。例えば、ＵｓｅｒＤａｔａＱＡＬｉｓｔ状態変数がＸＭＬ文書である場合、Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡは、そのＸＭＬ文書の一フラグメントになり得る。この状態変数は、複数個のＱｘＡＤエレメントと属性（ａｔｔｒｉｂｕｔｅｓ）を有することができる。また、この状態変数は、用いられるアクションの用途によってサブエレメントを含むことができる。Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡは、実施例によって省略されてもよい。この状態変数は、実施例によって、ストリングの形態であってもよい。
【１１８６】
図１０３は、本発明の一実施例に係るＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造を示す図である。
【１１８７】
ＵｓｅｒＤａｔａＱＡＬｉｓｔは、複数個のＱｘＡＤエレメントを含むことができる。各ＱｘＡＤエレメント及び属性（ａｔｔｒｉｂｕｔｅ）は、前述のとおりである。実施例によって、他の形態にＱｘＡＤエレメントの構造が変更されてもよい。
【１１８８】
一番目のＵｓｅｒＤａｔａＱＡＬｉｓｔ（ｔ１０３０１０）は、ＱＩＡＤとＱＢＡＤを含むことができる。ＱＩＡＤのＩＤは、”ｑｕｅｓｔｉｏｎ１”であってもよく、ｑｕｅｓｔｉｏｎ１は”ｗｈａｔ  ｉｓ  ｙｏｕｒ  ａｇｅ”のような質問を有することができる。ＱＢＡＤも、前述したような方式で情報を有することができる。
【１１８９】
二番目のＵｓｅｒＤａｔａＱＡＬｉｓｔ（ｔ１０３０２０）は、ＱＩＡＤ、ＱＢＡＤ、ＱＴＡＤを含むことができる。各ＱｘＡＤも、前述したような方式で情報を有することができる。
【１１９０】
ＵｓｅｒＤａｔａＱＡＬｉｓｔは、前述した両実施例のような形式で複数個のＱｘＡＤを含むことができ、各ＱｘＡＤは、前述したＱｘＡＤの構造、又は、実施例によって他の形態の構造を有することができる。
【１１９１】
図１０４は、本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクション（ａｃｔｉｏｎ）を示す図である。
【１１９２】
前述したＵｓｅｒＤａｔａサービスは、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ、ＧｅｔＵｓｅｒＤａｔａＱＡ、及び／又はＳｅｔＵｓｅｒＤａｔａＱＡアクションを含むことができる。これらのアクションは、必須（Ｒｅｑｕｉｒｅｄ）のアクションであってもよい。実施例によって、追加のアクションがさらに定義されてもよい。各アクションについては後述する。
【１１９３】
図１０５は、本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクションのうち、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ及びＧｅｔＵｓｅｒＤａｔａＱＡを説明する図である。
【１１９４】
ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションを説明する。
【１１９５】
ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションは、前述したＰＤＩストアに保存されたＱ＆ＡペアのＩＤを持ってくるために用いられるアクションであってもよい。すなわち、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションは、ＵｓｅｒＤａｔａＱＡＬｉｓｔ状態変数のＱｘＡＤエレメントのＱｘＡの＠ｉｄ値のリストを持ってくるアクションであってもよい。このリストは、ストリング形態（例えば、ＣＳＶ）であってもよく、他の形態であってもよい。コンパニオンデバイスは、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションを用いて、受信機の内部／外部に存在するＰＤＩストアから、Ｑ＆ＡペアのＩＤ情報を持ってくることができる。このとき、ＰＤＩユーザデータのプロトコルバージョンが参照され、ＱｘＡＤエレメントの＠ｐｒｏｔｏｃｏｌＶｅｒｓｉｏｎ値とマッチされる＠ｉｄをコンパニオンデバイスに持ってくることができる。
【１１９６】
ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションを用いるために、ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎインプットアーギュメントとＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアウトプットアーギュメントが定義されてもよい（ｔ１０５０１０）。ＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎアーギュメントは、前述したとおりであり、前述したＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアウトプットアーギュメントは、ＱｘＡＤエレメントのＱｘＡの＠ｉｄ値のリストであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔは、ストリング形態のリスト（例えば、ＣＳＶ）であってもよい。
【１１９７】
ＧｅｔＵｓｅｒＤａｔａＱＡアクションを説明する。
【１１９８】
ＧｅｔＵｓｅｒＤａｔａＱＡアクションは、前述したＰＤＩストアに保存されたＱ＆Ａペアを持ってくるために用いられるアクションであってもよい。コンパニオンデバイスは、ＧｅｔＵｓｅｒＤａｔａＱＡアクションを用いて、受信機の内部／外部に存在するＰＤＩストアから、Ｑ＆Ａペアを持ってくることができる。このとき、前述したＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔが参照され、そのＩＤにマッチされるＱｘＡＤだけをフラグメント形態で持ってくることができる。
【１１９９】
ＧｅｔＵｓｅｒＤａｔａＱＡアクションを用いるために、ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔインプットアーギュメント及びＵｓｅｒＤａｔａＱＡアウトプットアーギュメントが定義されてもよい（ｔ１０５０２０）。ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアーギュメントは、前述したとおりであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａＱＡアウトプットアーギュメントは、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔ状態変数のフラグメントであり、前述したＡ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡ状態変数と関連付いてもよい。ＵｓｅｒＤａｔａＱＡアーギュメントは、ＱｘＡＤエレメントなどの情報を有することができ、ＵｓｅｒＤａｔａＱＡＬｉｓｔのデータタイプに従うことができる（例えば、ＸＭＬ）。
【１２００】
例えば、ＧｅｔＵｓｅｒＤａｔａＱＡ（ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ＝”ｑｕｅｓｔｉｏｎ１”，”ｑｕｅｓｔｉｏｎ３”）のような内容のアクションが用いられた場合には、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造において、ＵｓｅｒＤａｔａＱＡＬｉｓｔに含まれる複数個のＱｘＡＤのうち、ｉｄが”ｑｕｅｓｔｉｏｎ１”であるものと、”ｑｕｅｓｔｉｏｎ３”であるものがリターンされてもよい。このとき、リターンされるＵｓｅｒＤａｔａのＸＭＬ構造はｉｄがそれぞれ”ｑｕｅｓｔｉｏｎ１”、”ｑｕｅｓｔｉｏｎ３”であるＱｘＡＤだけを有することができ、”ｑｕｅｓｔｉｏｎ２”のｉｄを有するＱｘＡＤエレメントはなくてもよい。
【１２０１】
ＧｅｔＵｓｅｒＤａｔａＱＡアクションにおいて、アウトプットアーギュメントであるＵｓｅｒＤａｔａＱＡのＱｘＡＤエレメントの数は、インプットアーギュメントであるＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ内の＠ｉｄの個数より少ない又は等しくてもよい。
【１２０２】
前述したＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔとＧｅｔＵｓｅｒＤａｔａＱＡアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１２０３】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。また、コンパニオンデバイスは既に、活用可能なプロトコルバージョンを知っていると仮定する。
【１２０４】
ここで、コンテンツプロバイダが受信機にＰＤＩユーザデータを伝達し、ＰＤＩユーザデータがさらにＰＤＩエンジンに伝達され、答弁を受けてＱ＆Ａを保存する過程（ｔｓ１０５０１０、ｔｓ１０５０２０、ｔｓ１０５０３０、ｔｓ１０５０４０）は、前述のとおりである。
【１２０５】
前述したコンパニオンデバイスは受信機からＱ＆Ａペアを得るために、前述したＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔアクションを行うことができる（ｔｓ１０５０５０）。コンパニオンデバイスは、前述した受信機内のコンパニオンデバイスモジュールに、Ｑ＆ＡペアのＩＤを要求することができる。
【１２０６】
コンパニオンデバイスモジュールはＰＤＩエンジンに、コンパニオンデバイスから要求されたＱ＆ＡペアのＩＤを要求することができる（ｔｓ１０５０６０）。ＰＤＩエンジンは、該当するＱ＆ＡペアのＩＤをＰＤＩストアから検索することができる（ｔｓ１０５０７０）。その後、ＰＤＩエンジンは、検索されたＱ＆ＡペアのＩＤを、コンパニオンデバイスモジュールに伝達することができる（ｔｓ１０５０８０）。
【１２０７】
コンパニオンデバイスモジュールは、受け取ったＱ＆ＡペアのＩＤをコンパニオンデバイスに伝達することができる（ｔｓ１０５０９０）。
【１２０８】
Ｑ＆ＡペアのＩＤを得たコンパニオンデバイスは、Ｑ＆Ａペアを得るために、前述したＧｅｔＵｓｅｒＤａｔａＱＡアクションを活用することができる（ｔｓ１０５１００）。コンパニオンデバイスは、受け取ったＱ＆ＡペアのＩＤを用いて、又はインプットアーギュメントとして用いて、Ｑ＆Ａペアを要求することができる。
【１２０９】
コンパニオンデバイスモジュールはＰＤＩエンジンに該当のＱ＆Ａペアを要求することができる（ｔｓ１０５１１０）。コンパニオンデバイスモジュールはＰＤＩストアから該当のＱ＆Ａペアを検索し（ｔｓ１０５１２０）、検索されたＱ＆Ａペアをコンパニオンデバイスモジュールに伝達することができる（ｔｓ１０５１３０）。
【１２１０】
コンパニオンデバイスモジュールは、受け取ったＱ＆Ａペアをコンパニオンデバイスに伝達することができる（ｔｓ１０５１４０）。コンパニオンデバイスは、受け取ったＱ＆Ａペアを保存することができる。保存されたＱ＆Ａペアは半永久的に保存されて活用されてもよく、仮にコンパニオンデバイスに格納所がない場合には、メモリなどの空間に一時的に保存されてもよい。
【１２１１】
本発明で、ＧｅｔＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔ及びＧｅｔＵｓｅｒＤａｔａＱＡアクションを行う時点は、特定の時点に限定されない。実施例によって、コンパニオンデバイスと受信機がペアリングされた直後に各アクションが行われてもよい。また、実施例によって、コンパニオンデバイスが受信機に周期的にポーリング（ｐｏｌｌｉｎｇ）しながら要求することもできる。
【１２１２】
図１０６は、本発明の一実施例に係る、質問と答弁のペア単位伝達のための、ＵｓｅｒＤａｔａサービスのアクションのうち、ＳｅｔＵｓｅｒＤａｔａＱＡを説明する図である。
【１２１３】
ＳｅｔＵｓｅｒＤａｔａＱＡアクションは、前述したＳｅｔＵｓｅｒＤａｔａアクションと同様に、逆にコンパニオンデバイスでＰＤＩユーザデータが設定／保存され、この設定されたＰＤＩユーザデータのＱ＆Ａが受信機に伝達される時に用いられるアクションであってもよい。ＳｅｔＵｓｅｒＤａｔａＱＡアクションは、ＵｓｅｒＤａｔａＱＡＬｉｓｔをインプットアーギュメントとして有し、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔ状態変数と関連付いてもよい（ｔ１０６０１０）。
【１２１４】
ＳｅｔＵｓｅｒＤａｔａＱＡアクションによって伝達されたＱ＆Ａを用いて、受信機内に既に保存されているＱ＆Ａが修正／アップデートされてもよい。受信機は、受け取ったＱ＆ＡをＰＤＩストアに保存されているＱ＆Ａと比較することができる。該当のＱ＆Ａがない場合、受け取ったＱ＆Ａを追加することができる。該当のＱ＆Ａがある場合、ＱｘＡＤエレメントのＱｘＡのＡの＠ｔｉｍｅと比較し、Ｑ＆Ａの答弁書込み時間が相対的に最新である方を維持することができる。
【１２１５】
ＳｅｔＵｓｅｒＤａｔａＱＡアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１２１６】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１２１７】
ここで、コンテンツプロバイダがＰＤＩユーザデータをコンパニオンデバイスに伝達し、答弁を得る過程（ｔｓ１０６０１０、ｔｓ１０６０２０）は、前述のとおりである。
【１２１８】
コンパニオンデバイスは、ＳｅｔＵｓｅｒＤａｔａＱＡアクションによって設定されたＱ＆Ａを、前述した受信機内のコンパニオンデバイスモジュールに伝達することができる（ｔｓ１０６０３０）。
【１２１９】
コンパニオンデバイスモジュールは、受け取ったＱ＆ＡをＰＤＩエンジンに伝達することができる（ｔｓ１０６０４０）。ＰＤＩエンジンは、ＰＤＩストアに既に保存されているＱ＆Ａがあるか否か検索することができる（ｔｓ１０６０５０）。ＰＤＩエンジンは検索の結果、既存に保存されているＱ＆ＡがないとＱ＆Ａを保存し、既存に保存されているＱ＆Ａがあると、＠ｔｉｍｅ情報に従ってＱ＆Ａをアップデートすることができる（ｔｓ１０６０６０）。
【１２２０】
例えば、受信機のＰＤＩストアには、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造に、ｉｄが”ｑｕｅｓｔｉｏｎ１”であるＱｘＡＤが保存されていてもよい。コンパニオンデバイスには、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造にｉｄが”ｑｕｅｓｔｉｏｎ３”であるＱｘＡＤが保存されていてもよい。
【１２２１】
ＳｅｔＵｓｅｒＤａｔａＱＡアクションー用いてコンパニオンデバイスは、ｉｄが”ｑｕｅｓｔｉｏｎ３”であるＱｘＡＤを受信機に伝達することができる。受信機のＰＤＩエンジンは、ｉｄが”ｑｕｅｓｔｉｏｎ３”であるＱｘＡＤがＰＤＩストアに存在しないため、該当のＱｘＡＤを追加してＰＤＩストアに保存することができる。最終的に、受信機のＰＤＩストアには、前述したＵｓｅｒＤａｔａＱＡＬｉｓｔのＸＭＬ構造に、ｉｄが”ｑｕｅｓｔｉｏｎ１”であるＱｘＡＤ、及びｉｄが”ｑｕｅｓｔｉｏｎ３”であるＱｘＡＤが共に保存されてもよい。
【１２２２】
図１０７は、本発明の一実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達されるシーケンスダイヤグラムを示す図である。
【１２２３】
ブロードキャスタチャネルは支援されず、ブロードバンドチャネル（例えば、インターネット）だけが支援される環境でも、受信機はＰＤＩユーザデータを受け取ることができる。このような環境でもブロードバンドチャネルを介してＰＤＩユーザデータを受け取るために別途のＰＤＩサーバーが存在してもよい。
【１２２４】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１２２５】
前述した環境で、受信機は、現在支援されるサービスのリストがシグナルされる過程で、ブロードバンドチャネルでＰＤＩユーザデータを受け取ることができるという通知を受けることができる（ｔｓ１０７００１）。受信機は、この通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）を受信してパースすることができる。
【１２２６】
受信機は、ＰＤＩユーザデータをＰＤＩサーバーに要求することができる（ｔｓ１０７００５）。このとき、前述したパーシングの結果として得たＵＲＬを用いてＰＤＩサーバーにアクセスすることができる。このとき、受信機の内部／外部のサービスリストクライアントがＰＤＩサーバーと通信することができる。要求を受けたＰＤＩサーバーは、要求を受けたＰＤＩユーザデータを受信機に伝達することができる（ｔｓ１０７０１０）。サービスリストクライアントはＰＤＩユーザデータをＰＤＩエンジンに伝達することができる（ｔｓ１０７０２０）。
【１２２７】
その後、ＰＤＩエンジンがＰＤＩストアに答弁を保存し、コンパニオンデバイスがＧｅｔＵｓｅｒＤａｔａＩｄｓＬｉｓｔ及びＧｅｔＵｓｅｒＤａｔａアクションを活用してＰＤＩユーザデータを持ってくる過程（ｔｓ１０７０２０〜ｔｓ１０７１４０）は、前述したとおりである。
【１２２８】
上記のような方式により、ブロードキャスタチャネルは支援されずにブロードバンドチャネルだけが支援される環境でも、受信機はＰＤＩユーザデータを受け取ることができる。
【１２２９】
ＰＤＩサーバーは、ＰＤＩユーザデータだけを伝達する独立した役割を担当してもよく、シグナリングのための各種テーブルが保存されている統合シグナリングサーバーの役割を担当してもよい。仮に、ＰＤＩユーザデータが伝達される旨の通知（ｎｏｔｉｆｉｃａｔｉｏｎ）がない場合、受信機は、ＰＤＩサーバーと持続して要求／答弁（ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）の過程を行うことができる。ただし、この場合、受信機はＰＤＩサーバーのＵＲＬをあらかじめ知っている必要がある。
【１２３０】
図１０８は、本発明の一実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの状態変数を示す図である。
【１２３１】
これらの状態変数は、コンパニオンデバイスが直接ＰＤＩサーバーに要求をしてＰＤＩユーザデータを受ける場合の状態変数であってもよい。この状況で、ＰＤＩＵｓｅｒＤａｔａＮｏｔｉｆｉｃａｔｉｏｎ及び／又はＰＤＩＳｅｒｖｅｒＵｒｌ状態変数が定義されてもよい。
【１２３２】
ＰＤＩＵｓｅｒＤａｔａＮｏｆｉｔｉｃａｔｉｏｎ状態変数は、ブロードバンドチャネルでＰＤＩユーザデータを受け取る旨の通知を受けた時間を示すことができる。この状態変数は、必須状態変数であって、データタイプはｄａｔａＴｉｍｅであり、イベント方式に従うことができる。イベントタイプであることにより、通知を受け取った時間が変更されると、すなわち、新しく通知を受けると、それをコンパニオンデバイスに知らせることができる。
【１２３３】
ＰＤＩＳｅｒｖｅｒＵｒｌ状態変数は、ブロードバンドチャネルでＰＤＩユーザデータを受け取ることができるＰＤＩサーバーのＵＲＬを示すことができる。この状態変数は、必須状態変数であって、データタイプはストリング又はａｎｙＵＲＩであり、アクション方式に従うことができる。このため、コンパニオンデバイスがアクション等を用いて該当のＵＲＬを得る必要がある。これについては後述する。
【１２３４】
図１０９は、本発明の一実施例に係るＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスのアクションを説明する図である。
【１２３５】
このような状況で、ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌというアクションが定義されてもよい（ｔ１０９０１０）。ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌアクションは、ＰＤＩサーバーのＵＲＬを持ってくるために用いられるアクションであってもよい。ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌアクションは、ＰＤＩＳｅｒｖｅｒＵｒｌというアウトプットアーギュメントを有することができる（ｔ１０９０２０）。ＰＤＩＳｅｒｖｅｒＵｒｌアーギュメントは、前述したＰＤＩＳｅｒｖｅｒＵｒｌ状態変数と関連付いてもよい。このアーギュメントは、ＰＤＩサーバーのＵＲＬを保存することができる。
【１２３６】
ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１２３７】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。また、コンパニオンデバイスはＵｓｅｒＤａｔａサービスに既にサブスクライブされていると仮定する。
【１２３８】
ここで、受信機がブロードバンドチャネルを介してＰＤＩユーザデータを受け取ることができる旨の通知を受ける段階（ｔｓ１０９０１０）は、前述のとおりである。
【１２３９】
受信機のサービスリストクライアントはコンパニオンデバイスモジュールにパースされたＰＤＩサーバーのＵＲＬを伝達し、ＰＤＩユーザデータを受け取ることができる旨を知らせることができる（ｔｓ１０９０２０）。
【１２４０】
コンパニオンデバイスモジュールは、ＰＤＩＵｓｅｒＤａｔａＮｏｔｉｆｉｃａｔｉｏｎ状態変数をアップデートする（ｔｓ１０９０３０）。通知を新しく受け取ったためである。イベント方式によって、コンパニオンデバイスモジュールはコンパニオンデバイスに、ＰＤＩＵｓｅｒＤａｔａＮｏｔｉｆｉｃａｔｉｏｎ状態変数が変更されたことを知らせることができる（ｔｓ１０９０４０）。
【１２４１】
コンパニオンデバイスは、ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌアクションを行って（ｔｓ１０９０５０）、該当のＰＤＩサーバーのＵＲＬを受け取ることができる（ｔｓ１０９０６０）。コンパニオンデバイスは、このＵＲＬを用いてＰＤＩサーバーに接近することができる。ＰＤＩサーバーにＰＤＩユーザデータを要求し（ｔｓ１０９０７０）、該当のＰＤＩユーザデータを得ることができる（ｔｓ１０９０８０）。
【１２４２】
コンパニオンデバイスは質問に対する答弁をユーザから得ることができる（ｔｓ１０９０９０）。その後、コンパニオンデバイスは、前述したＳｅｔＵｓｅｒＤａｔａ又はＳｅｔＵｓｅｒＤａｔａＱＡアクションを用いて、受信機のＰＤＩストアに該当のＰＤＩユーザデータをアップデートさせることができる（ｔｓ１０９１００〜ｔｓ１０９１３０）。この過程は、前述したとおりである。
【１２４３】
前述したように、ＧｅｔＰＤＩＳｅｒｖｅｒＵｒｌアクションが活用されてもよい。
【１２４４】
図１１０は、本発明の一実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの拡張された状態変数を説明する図である。
【１２４５】
ＰＤＩサーバーは複数個存在してもよい。このため、ＰＤＩサーバーＵＲＬも複数個存在してもよい。受信機は、コンパニオンデバイスが接続すべきＰＤＩサーバーを特定し、そのＰＤＩサーバーのＵＲＬを伝達することができる。
【１２４６】
このとき、接続可能な全ＰＤＩサーバーのＵＲＬが全てコンパニオンデバイスに伝達されてもよい。この場合、コンパニオンデバイスがＰＤＩサーバーの一つを選択して接続することができる。複数個のＵＲＬを伝達するために、前述したＰＤＩＳｅｒｖｅｒＵＲＬを活用することができる。ただし、この場合、ＰＤＩＳｅｒｖｅｒＵＲＬは拡張されて、データタイプが”Ｌｉｓｔ  ｏｆ  ｓｔｒｉｎｇ”又は”Ｌｉｓｔ  ｏｆ  ａｎｙＵＲＩ”に変更されてもよい。
【１２４７】
実施例によって、ＰＤＩＳｅｒｖｅｒＵｒｌはＣＳＶ形態であってもよく、（ｈｔｔｐ：／／ｐｄｉｓｅｒｖｅｒ１．ｃｏｍ、ｈｔｔｐ：／／ｐｄｉｓｅｒｖｅｒ２．ｃｏｍ、…、）などのように表現されてもよい。
【１２４８】
図１１１は、本発明の他の実施例に係る、ＰＤＩユーザデータがブロードバンドチャネルで伝達される状況で、ＵｓｅｒＤａｔａサービスの拡張された状態変数を説明する図である。
【１２４９】
前述したＰＤＩＳｅｒｖｅｒＵｒｌ状態変数は、アクション方式ではなくイベント方式に従うように拡張することができる。この場合、ＧｅｔＰＤＩＳｅｒｖｅｒアクションを行うことなく直ちにＰＤＩサーバーＵＲＬをコンパニオンデバイスに伝達することができる。
【１２５０】
コンパニオンデバイスがＵｓｅｒＤａｔａサービスにサブスクライブした直後、又はＰＤＩサーバーのＵＲＬが変更される場合に、ＰＤＩサーバーのＵＲＬがコンパニオンデバイスに伝達されてもよい。このとき、ＰＤＩサーバーのＵＲＬは、ＰＤＩＳｅｒｖｅｒＵｒｌ状態変数の形態で伝達されてもよい。
【１２５１】
前述したように、ＰＤＩサーバーのＵＲＬが複数個である場合、受信機が特定ＵＲＬだけを伝達してもよく、全ＵＲＬを伝達してもよい。これによって、ＰＤＩＳｅｒｖｅｒＵｒｌのデータタイプは、ｓｔｒｉｎｇ、ａｎｙＵＲＩ、Ｌｉｓｔ  ｏｆ  ｓｔｒｉｎｇｓ、及び／又はＬｉｓｔ  ｏｆ  ａｎｙＵＲＩであってもよい。
【１２５２】
図１１２は、本発明の他の実施例に係る、受信機とコンパニオンデバイスの間のユーザデータ交換の構造を示す図である。
【１２５３】
前述したように、ユーザが指定したＰＤＩユーザデータを用いて、個人化されたサービスを提供することができる。そのために、フィルタリングクライテリア（Ｆｉｌｔｅｒｉｎｇ  Ｃｒｉｔｅｒｉａ）が提供されてもよい。フィルタリングクライテリアを用いて受信機／コンパニオンデバイスは、ユーザに合わせたコンテンツを提供することができる。
【１２５４】
ここで、コンテンツプロバイダ又はブロードキャスタｔ１１２０１０、ＰＤＩ質問紙ｔ１１２０２０、ＰＤＩエンジンｔ１１２０３０、ＰＤＩストアｔ１１２０４０、ＰＤＩクラウドストアｔ１１２０７０、コンパニオンデバイスモジュールｔ１１２０６０、コンパニオンデバイスｔ１１２０８０は、前述した同名のモジュールと同一であってもよい。
【１２５５】
ここで、受信機ｔ１１２０５０は、前述した構造図と違い、フィルタリングエンジンｔ１１２０９０、コンテンツ／サービスストアｔ１１２１００をさらに含むことができる。フィルタリングエンジンは、各コンテンツ／サービスのフィルタリングクライテリアと、保存されたＰＤＩユーザデータを比較して、ユーザに合うコンテンツ／サービスを選別することができる。フィルタリングクライテリアは、コンパニオンデバイスにも伝達されてもよい。
【１２５６】
実施例によって、フィルタリングクライテリアによって選別されたデータがコンパニオンデバイスに伝達されてもよく、フィルタリングクライテリアをコンパニオンデバイスに伝達して、コンパニオンデバイスが直接フィルタリングをしてもよい。
【１２５７】
フィルタリングクライテリアのＸＭＬ構造については前述した。ただし、前述した構造によって限定されず、実施例によって、他の構造のフィルタリングクライテリアが用いられてもよい。以下、フィルタリングクライテリアをＦＣと略称することもできる。
【１２５８】
コンテンツ／サービスストアｔ１１２１００は、受信したコンテンツ／サービスを保存する空間である。実施例によって、フィルタリングエンジンによってフィルタリングされたコンテンツ／サービスが、コンテンツ／サービスストアｔ１１２１００に保存されてもよい。また、実施例によって、全てのコンテンツ／サービスがコンテンツ／サービスストアに保存された後、後にフィルタリングエンジンがフィルタリングを行って、さらにコンテンツ／サービスストアに保存することもできる。
【１２５９】
図１１３は、本発明の他の実施例に係るサービスの、サービスタイプ及びサービスＩＤを示す図である。
【１２６０】
受信機がコンパニオンデバイスにフィルタリングクライテリアを伝達するために、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａというサービスが定義されてもよい。このサービスのサービスタイプは、ａｔｓｃ３．０ｆｉｌｔｅｒｉｎｇ：１であってもよい。
【１２６１】
各サービスは別個のサービスＩＤを有することができるが、実施例によって、ｕｕｒｎ：ａｔｓｃ．ｏｒｇ：ｓｅｒｖｉｃｅＩｄ：ａｔｓｃ３．０ｆｉｌｔｅｒｉｎｇ１（ｔ１１３０１０）、又はｕｕｒｎ：ａｔｓｃ．ｏｒｇ：ｓｅｒｖｉｃｅＩｄ：ａｔｓｃ３．０ｆｉｌｔｅｒｉｎｇ（ｔ１１３０２０）を有することができる。
【１２６２】
ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスについては後述する。
【１２６３】
図１１４は、本発明の一実施例に係るＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの状態変数を示す図である。
【１２６４】
ＦｉｌｔｒｉｎｇＣｒｉｔｅｒｉａサービスの一状態変数としてＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａ状態変数を定義することができる。
【１２６５】
ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａ状態変数は、コンテンツ／サービスのフィルタリングのために、フィルタリングクライテリアをコンパニオンデバイスに伝達するために用いられてもよい。ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａ状態変数は、必須状態変数であって、データタイプはＳｔｒｉｎｇタイプ（ＸＭＬ、Ｊａｓｏｎなど）であってもよい。また、前述したアクション方式に従って様々なアクションで用いられてもよい。
【１２６６】
図１１５は、本発明の一実施例に係るＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスのアクションを説明する図である。
【１２６７】
ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスは、ＧｅｔＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａアクションを有することができる（ｔ１１５０１０）。このアクションは、コンパニオンデバイスが受信機からフィルタリングクライテリアを持ってくるためのアクションであってもよい。
【１２６８】
ＧｅｔＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａアクションは、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａをアウトプットアーギュメントとして有することができる（ｔ１１５０２０）。このアクションは、前述したＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａ状態変数と関連付いてもよい。このアクションを用いると、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａをコンパニオンデバイスに出力することができる。
【１２６９】
前述したＧｅｔＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａアクションの動作及びフィルタリングクライテリアを用いた個人化サービス提供のシーケンスダイヤグラムの一実施例を説明する。
【１２７０】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１２７１】
コンテンツプロバイダ又はブロードキャスタは、コンパニオンデバイスで行われるコンテンツやサービスを受信機に伝達することができる（ｔｓ１１５０１０）。このとき、コンテンツプロバイダ又はブロードキャスタはＦＣも受信機に伝達することができる。
【１２７２】
受信機はフィルタリングエンジンにＦＣを伝達することができる（ｔｓ１１５０２０）。また、受信機はコンパニオンデバイスモジューロコンパニオンデバイスのためのコンテンツ／サービスが存在すると知らせることができる（ｔｓ１１５０３０）。コンパニオンデバイスモジュールは、これをコンパニオンデバイスに知らせることができる（ｔｓ１１５０４０）。
【１２７３】
コンパニオンデバイスモジュールは、前述したＧｅｔＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａアクションを用いることができる（ｔｓ１１５０５０）。このアクションを用いて、コンパニオンデバイスモジュールは、ＦＣをコンパニオンデバイスモジュールに要求することができる。ＦＣは、コンパニオンデバイスがコンテンツ／サービスを受信する前にユーザの設定したＰＤＩユーザデータを参照するために用いられてもよい。
【１２７４】
コンパニオンデバイスモジュールはフィルタリングエンジンにＦＣを要求することができる（ｔｓ１１５０６０）。フィルタリングエンジンはＦＣをコンパニオンデバイスに伝達することができる（ｔｓ１１５０７０）。コンパニオンデバイスモジュールはＦＣをコンパニオンデバイスに伝達することができる（ｔｓ１１５０８０）。
【１２７５】
コンパニオンデバイスはＰＤＩユーザデータをコンパニオンデバイスモジュールに要求することができる（ｔｓ１１５０９０）。ＰＤＩユーザデータを要求するために、前述したアクションを活用することができる。
【１２７６】
コンパニオンデバイスモジュールはＰＤＩエンジンに、質問紙に対する答弁を要求することができる（ｔｓ１１５１００）。ＰＤＩエンジンは、ＰＤＩストアに既に保存された質問紙に対する答弁を検索することができる（ｔｓ１１５１１０）。ＰＤＩエンジンは、検索の完了した答弁をコンパニオンデバイスモジュールに伝達することができる（ｔｓ１１５１２０）。コンパニオンデバイスモジュールは、ＰＤＩユーザデータである該当の答弁をコンパニオンデバイスに伝達することができる（ｔｓ１１５１３０）。
【１２７７】
コンパニオンデバイスは、ＦＣとユーザが既に設定した答弁を比較することができる（ｔｓ１１５１４０）。ＦＣがユーザの答弁、すなわち、ＰＤＩユーザデータに満足する場合、該当のコンテンツ／サービスをユーザに提供することができる。そうでない場合、該当のコンテンツ／サービスがユーザに提供されなくてもよい。
【１２７８】
コンパニオンデバイスは、ＦＣがユーザの答弁に符合する場合、受信機から該当のコンテンツ／サービスを持ってくることができる。このとき、該当のコンテンツ／サービスの伝達は、コンパニオンデバイスモジュールを介して行われてもよい（ｔｓ１１５１５０、ｔｓ１１５１６０）。実施例によって、ＦＣがユーザの答弁に符合する場合、コンパニオンデバイスは、該当のコンテンツ／サービスをサービスプロバイダ又はブロードキャスタのサーバーから直接受信することもできる。
【１２７９】
その後、コンパニオンデバイスは、ＰＤＩユーザデータに合うＦＣを有するコンテンツ／サービスをユーザに露出させることができる。
【１２８０】
図１１６は、本発明の一実施例に係るＦＣがブロードバンドチャネルで伝達されるシーケンスダイヤグラムを示す図である。
【１２８１】
前述したように、、ブロードキャスタチャネルは支援されずにブロードバンドチャネル（例えば、インターネット）だけが支援される環境でも、受信機はＦＣを受け取ることができる。このような環境でもブロードバンドチャネルを介してＦＣを受けるために別途のＦＣサーバーが存在してもよい。
【１２８２】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。
【１２８３】
前述した環境で、受信機は、現在支援されるサービスのリストがシグナルされる過程で、ブロードバンドチャネルでＦＣを受け取ることができるという通知を受けることができる（ｔｓ１１６００１）。実施例によって、受信機又はサービスリストクライアントは、ブロードキャストチャネルのシグナリング情報を要求することができるが、この要求によってシグナリング情報を受ける過程で、受信機は、前述した通知を受けることができる。以下、受信機乃至サービスリストクライアントを受信機と呼ぶこともできる。受け取った通知がパースされ、ＦＣサーバーのＵＲＬを得ることができる。
【１２８４】
受信機はＦＣを、ＦＣサーバーに要求することができる（ｔｓ１１６００５）。このとき、パースされたＦＣサーバーのＵＲＬが活用されてもよい。要求を受けたＦＣサーバーは、要求を受けたＦＣを受信機に伝達することができる（ｔｓ１１６０１０）。ＦＣがブロードバンドチャネルで伝達される場合、ＦＣはシグナリングチャネルを介して伝達されてもよく、ＦＣはＢｉｎａｒｙ又はＸＭＬ形態で伝達されてもよい。このとき、ブロードバンドチャネルには様々な種類があり、一実施例として、ＳＭＴ、ＮＲＴ−ＩＴなどのチャネルを用いることができる。受信機又はサービスリストクライアントはＦＣをフィルタリングエンジンに伝達することができる（ｔｓ１１６０２０）。
【１２８５】
その後、コンパニオンデバイスにコンテンツ／サービスの存在を知らせ、ＧｅｔＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａアクションによってＦＣがコンパニオンデバイスに伝達され、ＰＤＩユーザデータがコンパニオンデバイスに伝達され、ＦＣとＰＤＩユーザデータとを比較して、個人化サービスを提供する過程（ｔｓ１１６０３０〜ｔｓ１１６１６０）は、前述のとおりである。
【１２８６】
上記のような方式により、ブロードキャスタチャネルは支援されずにブロードバンドチャネルだけが支援される環境でも、受信機はＦＣを受け取ることができる。
【１２８７】
ＦＣサーバーは、ＦＣだけを伝達する独立した役割を担当してもよく、シグナリングのための各種テーブルが保存されている統合シグナリングサーバーの役割を担当してもよい。仮にＦＣを受け取るようとの通知（ｎｏｔｉｆｉｃａｔｉｏｎ）がない場合、受信機はＦＣサーバーと持続して要求／答弁（ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）の過程を行うことができる。ただし、この場合、受信機はＦＣサーバーのＵＲＬをあらかじめ知っていなければならない。
【１２８８】
図１１７は、本発明の一実施例に係る、ＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの状態変数を示す図である。
【１２８９】
これらの状態変数は、コンパニオンデバイスがＦＣサーバーに直接要求をしてＦＣを受ける場合の状態変数であってもよい。この状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａＮｏｔｉｆｉｃａｔｉｏｎ及び／又はＦＣＳｅｒｖｅｒＵｒｌ状態変数が定義されてもよい。
【１２９０】
ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａＮｏｔｉｆｉｃａｔｉｏｎ状態変数は、ブロードバンドチャネルでＦＣを受け取ることができる旨の通知を受けた時間を示すことができる。この状態変数は、必須状態変数であって、データタイプはｄａｔａＴｉｍｅであり、イベント方式に従うことができる。イベントタイプであることにより、通知を受け取った時間が変更されると、すなわち、新しく通知を受けると、これをコンパニオンデバイスに知らせることができる。
【１２９１】
ＰＤＩＳｅｒｖｅｒＵｒｌ状態変数は、ブロードバンドチャネルでＦＣを受け取ることができるＦＣサーバーのＵＲＬを示すことができる。この状態変数は、必須状態変数であって、データタイプはストリング又はａｎｙＵＲＩであり、アクション方式に従うことができる。したがって、コンパニオンデバイスがアクション等を用いて該当のＵＲＬを得る必要がある。これについては後述する。
【１２９２】
図１１８は、本発明の一実施例に係るＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスのアクションを説明する図である。
【１２９３】
このような状況で、ＧｅｔＦＣＳｅｒｖｅｒＵｒｌというアクションが定義されてもよい（ｔ１１８０１０）。ＧｅｔＦＣＳｅｒｖｅｒＵｒｌアクションは、ＦＣサーバーのＵＲＬを持ってくるために用いられるアクションであってもよい。ＧｅｔＦＣＳｅｒｖｅｒＵｒｌアクションは、ＦＣＳｅｒｖｅｒＵｒｌというアウトプットアーギュメントを有することができる（ｔ１１８０２０）。ＦＣＳｅｒｖｅｒＵｒｌアーギュメントは、前述したＦＣＳｅｒｖｅｒＵｒｌ状態変数と関連付いてもよい。このアーギュメントは、ＦＣサーバーのＵＲＬを保存することができる。
【１２９４】
ＧｅｔＦＣＳｅｒｖｅｒＵｒｌアクションの動作シーケンスダイヤグラムの一実施例を説明する。
【１２９５】
この動作シーケンスダイヤグラムにおいてコンパニオンデバイスと受信機は既にペアリングされており、ペアリングする過程は省略されている。また、コンパニオンデバイスはＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスに既にサブスクライブされていると仮定する。
【１２９６】
ここで、受信機がブロードバンドチャネルを介してＦＣを受け取ることができる旨の通知を受ける段階（ｔｓ１１８０１０）は、前述のとおりである。
【１２９７】
受信機のサービスリストクライアントはコンパニオンデバイスモジュールに、パースされたＦＣサーバーのＵＲＬを伝達し、ＦＣを受け取ることができる旨を知らせることができる（ｔｓ１１８０２０）。
【１２９８】
コンパニオンデバイスモジュールは、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａＮｏｔｉｆｉｃａｔｉｏｎ状態変数をアップデートする（ｔｓ１１８０３０）。通知を新しく受け取ったためである。イベント方式に従って、コンパニオンデバイスモジュールはコンパニオンデバイスに、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａＮｏｔｉｆｉｃａｔｉｏｎ状態変数が変更されたことを知らせることができる（ｔｓ１１８０４０）。
【１２９９】
コンパニオンデバイスはＧｅｔＦＣＳｅｒｖｅｒＵｒｌアクションを行い（ｔｓ１１８０５０）、該当のＦＣサーバーのＵＲＬを受け取ることができる（ｔｓ１１８０６０）。コンパニオンデバイスはこのＵＲＬを用いてＦＣサーバーに接近することができる。ＦＣサーバーにＦＣを要求し（ｔｓ１１８０７０）、該当のＦＣを得ることができる（ｔｓ１１８０８０）。
【１３００】
その後、コンパニオンデバイスモジュールがＰＤＩユーザデータを要求して該当の答弁を得、ＦＣとＰＤＩユーザデータとを比較して、個人化サービスを提供する過程（ｔｓ１１８０９０〜ｔｓ１１８１６０）は、前述のとおりである。
【１３０１】
上記のような方式により、ブロードキャスタチャネルは支援されずにブロードバンドチャネルだけが支援される環境で、コンパニオンデバイスはＦＣサーバーからＦＣを直接受け取って個人化サービスを提供することができる。
【１３０２】
図１１９は、本発明の一実施例に係る、ＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの拡張された状態変数を説明する図である。
【１３０３】
ＦＣサーバーは複数個存在してもよい。このため、ＦＣサーバーＵＲＬも複数個存在してもよい。受信機は、コンパニオンデバイスが接続すべきＦＣサーバーを特定し、そのＰＤＩサーバーのＵＲＬを伝達することができる。
【１３０４】
このとき、接続可能な全ＦＣサーバーのＵＲＬが全てコンパニオンデバイスに伝達されてもよい。この場合、コンパニオンデバイスがＦＣサーバーの一つを選択して接続することができる。複数個のＵＲＬを伝達するために前述のＦＣＳｅｒｖｅｒＵｒｌを活用することもできる。ただし、この場合、ＦＣＳｅｒｖｅｒＵｒｌは、拡張されてデータタイプが”Ｌｉｓｔ  ｏｆ  ｓｔｒｉｎｇ”又は”Ｌｉｓｔ  ｏｆ  ａｎｙＵＲＩ”に変更されてもよい。
【１３０５】
実施例によって、ＦＣＳｅｒｖｅｒＵｒｌは、ＣＳＶ形態であってもよく、（，，…，）などのように表現されてもよい。
【１３０６】
図１２０は、本発明の他の実施例に係る、ＦＣがブロードバンドチャネルで伝達される状況で、ＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスの拡張された状態変数を説明する図である。
【１３０７】
前述したＦＣＳｅｒｖｅｒＵｒｌ状態変数は、アクション方式ではなくイベント方式に従うように拡張されてもよい。この場合、ＧｅｔＦＣＳｅｒｖｅｒＵｒｌアクションが行われる必要はなく、ＦＣサーバーＵＲＬがコンパニオンデバイスに直接伝達されてもよい。
【１３０８】
コンパニオンデバイスがＦｉｌｔｅｒｉｎｇＣｒｉｔｅｒｉａサービスにサブスクライブした直後、又はＦＣサーバーのＵＲＬが変更される場合に、ＦＣサーバーのＵＲＬがコンパニオンデバイスに伝達されてもよい。このとき、ＦＣサーバーのＵＲＬは、ＦＣＳｅｒｖｅｒＵｒｌ状態変数の形態で伝達されてもよい。
【１３０９】
前述したように、ＦＣサーバーのＵＲＬが複数個である場合、受信機が特定のＵＲＬだけを伝達してもよく、全ＵＲＬを伝達してもよい。これにより、ＦＣＳｅｒｖｅｒＵｒｌのデータタイプは、ｓｔｒｉｎｇ、ａｎｙＵＲＩ、Ｌｉｓｔ  ｏｆ  ｓｔｒｉｎｇｓ、及び／又はＬｉｓｔ  ｏｆ  ａｎｙＵＲＩであってもよい。
【１３１０】
図１２１は、本発明の一実施例に係る放送受信機を示す図である。
【１３１１】
本発明の一実施例に係る放送受信機は、サービス／コンテンツ取得制御器Ｊ２０１０、インターネットインターフェース（Ｉｎｔｅｒｎｅｔ  ｉｎｔｅｒｆａｃｅ）Ｊ２０２０、放送網インターフェース（Ｂｒｏａｄｃａｓｔ  ｉｎｔｅｒｆａｃｅ）Ｊ２０３０、シグナリングデコーダＪ２０４０、サービスマップデータベースＪ２０５０、デコーダＪ２０６０、ターゲッティングプロセッサＪ２０７０、プロセッサＪ２０８０、管理ユニット（Ｍａｎａｇｉｎｇ  ｕｎｉｔ）Ｊ２０９０、及び／又は再分配モジュール（ｒｅｄｉｓｔｒｉｂｕｔｉｏｎ  ｍｏｄｕｌｅ）Ｊ２１００を含む。図面では、放送受信機の外部及び／又は内部に存在し得る外部管理装置（Ｅｘｔｅｒｎａｌ  Ｍａｎａｇｅｍｅｎｔ）Ｊ２１１０が示されている。
【１３１２】
サービス／コンテンツ取得制御器Ｊ２０１０は、放送／ブロードバンド（ｂｒｏａｄｃａｓｔ／ｂｒｏａｄｂａｎｄ）チャネルを介してサービス及び／又はコンテンツ、これと関連したシグナリングデータを受信する。又は、サービス／コンテンツ取得制御器Ｊ２０１０は、サービス及び／又はコンテンツ、これと関連したシグナリングデータを受信するための制御を行うことができる。
【１３１３】
インターネットインターフェースＪ２０２０は、インターネットアクセスコントロールモジュール（Ｉｎｔｅｒｎｅｔ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍｏｄｕｌｅ）を含むことができる。インターネットアクセスコントロールモジュールは、ブロードバンドチャネルを介してサービス、コンテンツ及び／又はシグナリングデータを受信する。又は、インターネットアクセスコントロールモジュールは、サービス、コンテンツ及び／又はシグナリングデータを取得するための受信機の動作を制御することができる。
【１３１４】
放送網インターフェー（Ｊ２０３０は、物理層モジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｍｏｄｕｌｅ）及び／又は物理層インターフェースモジュール（Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ  Ｉ／Ｆ  Ｍｏｄｕｌｅ）を含むことができる。物理層モジュールは、放送チャネルを介して放送関連信号を受信する。物理層モジュールは、放送チャネルを介して受信した放送関連信号を処理（復調、復号など）する。物理層インターフェースモジュールは、物理層モジュールから取得した情報から、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）データグラムを取得したり、取得されたＩＰデータグラムを用いて特定フレーム（例えば、放送フレーム、ＲＳフレーム、又はＧＳＥなど）に変換する。
【１３１５】
シグナリングデコーダＪ２０４０は、放送チャネルなどで取得したシグナリングデータ又はシグナリング情報（以下、’シグナリングデータ’という。）をデコードする。
【１３１６】
サービスマップデータベースＪ２０５０は、デコードされたシグナリングデータを保存したり、受信機の他の装置（例えば、シグナリングパーサーなど）で処理されたシグナリングデータを保存する。
【１３１７】
デコーダＪ２０６０は、受信機で受信した放送信号又はデータをデコードする。デコーダＪ２０６０は、スケジュールドストリーミングデコーダ（Ｓｃｈｅｄｕｌｅｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）、ファイルデコーダ（Ｆｉｌｅ  Ｄｅｃｏｄｅｒ）、ファイルデータベース（Ｆｉｌｅ  ＤＢ）、オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）、コンポーネント同期化器（Ｃｏｍｐｏｎｅｎｔ  Ｓｙｎｃｈｒｏｎｉｚｅｒ）、警報シグナリングパーサー（Ａｌｅｒｔ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）、ターゲッティングシグナリングパーサー（Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）、サービスシグナリングパーサー（Ｓｅｒｖｉｃｅ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）及び／又はアプリケーションシグナリングパーサー（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）を含むことができる。
【１３１８】
スケジュールドストリーミングデコーダは、ＩＰデータグラムなどから、実時間Ａ／Ｖ（Ａｕｄｉｏ／Ｖｉｄｅｏ）ストリーミングのためのオーディオ／ビデオデータを抽出し、これをデコードする。
【１３１９】
ファイルデコーダは、ＩＰデータグラムから、ＮＲＴデータ及びアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）などのファイル形態データを抽出し、これをデコードする。
【１３２０】
ファイルデータベース（Ｆｉｌｅ  ＤＢ）は、ファイルデコーダから抽出したデータを保存する。
【１３２１】
オンデマンドストリーミングデコーダ（Ｏｎ−Ｄｅｍａｎｄ  Ｓｔｒｅａｍｉｎｇ  Ｄｅｃｏｄｅｒ）は、ＩＰデータグラムなどからユーザ要求（ｏｎ−ｄｅｍａｎｄ）ストリーミングのためのオーディオ／ビデオデータを抽出し、これをデコードする。
【１３２２】
コンポーネント同期化器は、スケジュールドストリーミングデコーダ、ファイルデコーダ及び／又はオンデマンドストリーミングデコーダでデコードされたデータに基づいて、コンテンツを構成する要素間の同期化を行ったり、サービスを構成する要素間の同期化を行い、コンテンツ又はサービスを構成する。
【１３２３】
警報シグナリングパーサーは、ＩＰデータグラムなどから、警報（ａｌｅｒｔｉｎｇ）と関連したシグナリング情報を抽出し、これをパースする。
【１３２４】
ターゲッティングシグナリングパーサーは、ＩＰデータグラムなどから、サービス／コンテンツ個人化、又はターゲッティングに関連したシグナリング情報を抽出し、これをパースする。ここで、ターゲッティングは、特定の視聴者の条件に合うコンテンツ又はサービスを提供することであり、該当の視聴者の条件に合うコンテンツ又はサービスを識別してそれを提供する。
【１３２５】
サービスシグナリングパーサーは、ＩＰデータグラムなどから、サービススキャン及び／又はサービス／コンテンツなどに関連したシグナリング情報を抽出し、これをパースする。サービス／コンテンツなどに関連したシグナリング情報は、放送システム情報及び／又は放送シグナリング情報を含む。
【１３２６】
アプリケーションシグナリングパーサーは、ＩＰデータグラムなどからアプリケーション取得に関連したシグナリング情報を抽出し、これをパースする。アプリケーション取得に関連したシグナリング情報は、トリガー（Ｔｒｉｇｇｅｒ）、ＴＰＴ（ＴＤＯ  ｐａｒａｍｅｔｅｒ  ｔａｂｌｅ）及び／又はＴＤＯパラメータエレメントを含むことができる。
【１３２７】
ターゲッティングプロセッサＪ２０７０は、ターゲッティングシグナリングパーサーでパースされたサービス／コンテンツターゲッティング関連情報を処理する。
【１３２８】
プロセッサＪ２０８０は、受信したデータをディスプレイするための一連の処理を行う。プロセッサＪ２０８０は、警報プロセッサ（Ａｌｅｒｔ  Ｐｒｏｃｅｓｓｏｒ）、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｃｅｓｓｏｒ）及び／又はオーディオ／ビデオプロセッサ（Ａ／Ｖ  Ｐｒｏｃｅｓｓｏｒ）を含むことができる。
【１３２９】
警報プロセッサは、警報に関連したシグナリング情報を用いて、警報データを取得するように受信機を制御し、警報データをディスプレイするための処理を行う。
【１３３０】
アプリケーションプロセッサは、アプリケーション関連情報を処理し、ダウンロードされたアプリケーションの状態及びアプリケーションに関連したディスプレイパラメータを処理する。
【１３３１】
オーディオ／ビデオプロセッサは、デコードされたオーディオデータ、ビデオデータ及び／又はアプリケーションデータに基づいてオーディオ／ビデオレンダリング関連動作を行う。
【１３３２】
管理ユニットＪ２０９０は、装置マネジャー（ｄｅｖｉｃｅ  ｍａｎａｇｅｒ）及び／又はデータ通信及びシェアリングユニット（Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｔ）を含む。
【１３３３】
装置マネジャーは、接続及びデータ交換などを含む連動可能な外部装置の追加／削除／更新など、外部装置に対する管理を行う。
【１３３４】
データ通信及びシェアリングユニットは、受信機と外部装置（例えば、ｃｏｍｐａｎｉｏｎ  ｄｅｖｉｃｅ）間のデータ伝送及び交換関連情報を処理し、それに関連した動作を行う。伝送及び交換可能なデータは、シグナリングデータ、ＰＤＩテーブル、ＰＤＩユーザデータ、ＰＤＩ  Ｑ＆Ａ及び／又はＡ／Ｖデータであってもよい。
【１３３５】
再分配モジュールＪ２１００は、受信機が放送信号を直接受信できない場合、放送サービス／コンテンツ関連情報及び／又はサービス／コンテンツデータ取得を行う。
【１３３６】
外部管理装置Ｊ２１１０は、放送サービス／コンテンツサーバーのような、放送サービス／コンテンツ提供のための放送受信機の外部のモジュールを意味する。外部管理装置の役割を担うモジュールは、放送受信機の内部に設けられてもよい。
【１３３７】
図１２２は、本発明の他の実施例に係る放送受信機を示す図である。
【１３３８】
図示の受信機は、前述した受信機及び受信機に含まれる装置に類似しているので、同じ名称を有する装置に関する説明は、前述した説明に代える。
【１３３９】
前述したターゲッティングシグナリングパーサは、ユーザデータシェアリング及びターゲッティングシグナリングパーサー（Ｕｓｅｒ  Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｔａｒｇｅｔｉｎｇ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）と命名することができ、前述したユーザデータ（例えば、ＰＤＩユーザデータ又はＱ＆Ａ）をパースする役割をさらに担うことができる。
【１３４０】
前述したターゲッティングプロセッサは、ユーザデータシェアリング及びターゲッティングプロセッサ（Ｕｓｅｒ  Ｄａｔａ  Ｓｈａｒｉｎｇ  ＆  Ｔａｒｇｅｔｉｎｇ  Ｐｒｏｃｅｓｓｏｒ）と命名することができ、前述したユーザデータ（例えば、ＰＤＩユーザデータ又はＱ＆Ａ）を処理する役割をさらに担うことができる。
【１３４１】
本発明の他の実施例に係る受信機は、ユーザデータデータベース（Ｕｓｅｒ  Ｄａｔａ  ＤＢ）をさらに含むことができる。ユーザデータデータベースは、処理されたユーザデータを保存する。
【１３４２】
図１２３は、本発明の一実施例に係るプレゼンテーション選好度（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）を示す図である。
【１３４３】
プレゼンテーション選好度とは、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ（ａｕｄｉｏ）、接近性（Ａｃｃｅｓｓｉｂｉｌｉｔｙ）及び／又は手話（Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）などにおいて、放送視聴時に該当のクローズドキャプションなどが表示されることに関する選好度を意味することができる。
【１３４４】
ユーザのプレゼンテーション選好度が、個人化された情報として受信機に保存されると、放送視聴の際にそのユーザに合わせたサービス提供が可能である。ユーザは、関連情報を毎度セッティングする必要がなく、自身の選好度（ｐｒｅｆｅｒｅｎｃｅ）に合わせられたサービスの提供を受けることができる。実施例によって、ユーザプレゼンテーション選好度は、放送視聴前、又は放送視聴中にプレレジステッド（ｐｒｅ−ｒｅｇｉｓｔｅｒｅｄ）されてもよい。
【１３４５】
また、設定されたプレゼンテーション選好度は、受信機の他に、コンパニオンデバイスにも共有されて活用されてもよい。逆に、コンパニオンデバイスで設定されたプレゼンテーション選好度が受信機に共有されてもよい。
【１３４６】
本発明では、プレゼンテーション選好度のうち、クローズドキャプション、オーディオ、接近性＆手話プレゼンテーションについて説明する。しかし、プレゼンテーション選好度に関連したサービスは様々であり、本発明は、上記の３つの項目のプレゼンテーション選好度に限定されない。
【１３４７】
図１２４は、本発明の一実施例に係る、クローズドキャプション選好度（Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）のシーケンスダイヤグラムを示す図である。
【１３４８】
前述したクローズドキャプションの選好度と関連して、ユーザは、クローズドキャプションを使用するか否か、クローズドキャプションの言語選好、フォント選好、フォントサイズ選好などを設定することができる。これらの情報は、クローズドキャプションをシグナルする過程で伝達されるデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）又はテーブルを参照することができる。クローズドキャプションに関連した情報が伝達されるチャネル、デスクリプタ又はテーブルは、様々な形態で表現することができ、本発明はいずれかの形態に限定されない。
【１３４９】
クローズドキャプションに関連した情報が伝達されるデスクリプタを、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒと称する。このデスクリプタは、クローズドキャプションに関連した基本的な情報を伝達するデスクリプタであってもよい。このデスクリプタは、従来技術で用いられる、クローズドキャプション関連デスクリプタの情報を含み、これに加えて、本発明で提案するフィールド／情報などをさらに含むことができる。すなわち、既存クローズドキャプション関連デスクリプタの変形であってもよい。
【１３５０】
このｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒは、クローズドキャプションが提供される放送がある場合、ＰＭＴ／ＥＩＴで伝達することができる。ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの情報を用いて、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒはあらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換されてもよい。受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒを受信すると、これをあらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換して、答弁を受けることができる。
【１３５１】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴでｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１３５２】
ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴ又はＥＩＴに含まれてもよい（ｔｓ１２４０１０）。前述したように、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴ又はＥＩＴで伝達することができる。ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒが受信機に受信されると（ｔ１２４０２０）、受信機の内部／外部のシグナリングパーサーは、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒを受信機の内部／外部のＰＤＩエンジンに伝達することができる（ｔｓ１２４０３０）。
【１３５３】
ＰＤＩエンジンは、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの情報によって、ＰＤＩ  Ｑｕｅｓｔｉｏｎを自動で生成することができる（ｔｓ１２４０４０）。この過程は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒをＰＤＩ  Ｑｕｅｓｔｉｏｎに自動で変換するとも表現することができる。ＰＤＩエンジンは、ＩＤを用いて、該当の質問に対する答弁が既存に存在するか否かを確認し、存在しない場合、完成されたＰＤＩ  ＱｕｅｓｔｉｏｎをＵＩに送り（ｔｓ１２４０５０）、ユーザから答弁を受けることができる。
【１３５４】
ユーザは、ＵＩを介して該当のＰＤＩ  Ｑｕｅｓｔｉｏｎに対する答弁を設定し（ｔｓ１２４０６０）、ＵＩは、この答弁をＰＤＩエンジンにリターンすることができる（ｔｓ１２４０７０）。ＰＤＩエンジンは、該当の内容をＰＤＩストアに追加又はアップデートすることができる（ｔｓ１２４０８０）。
【１３５５】
実施例によって、既存に質問に対する答弁がある場合であっても、ユーザの選好度に変化がありうるため、ＵＩを介して該当の質問に対する答弁を再び受けることもできる。この場合、新しい答弁は、既存の答弁と答弁時刻などの側面で比較され、新しい答弁が既存の答弁に置き換わってもよい。
【１３５６】
図１２５は、本発明の他の実施例に係るクローズドキャプション選好度のシーケンスダイヤグラムを示す図である。
【１３５７】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴをシグナリングサーバーに要求し、ＰＭＴ或いはＥＩＴでｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１３５８】
受信機はシグナリングサーバーにＰＭＴ又はＥＩＴを要求することができる（ｔｓ１２５０１０）。シグナリングサーバーは、要求されたＰＭＴ又はＥＩＴを受信機に伝達することができる（ｔｓ１２５０２０）。受信機は、ＰＭＴ、ＥＩＴ内のｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒをＰＤＩエンジンに伝達することができる（ｔｓ１２５０３０）。
【１３５９】
その後、ＰＤＩエンジンがＰＤＩ  Ｑｕｅｓｔｉｏｎを生成し、ＵＩを介して質問に対する答弁を受ける。答弁をＰＤＩストアに追加／アップデートする動作（ｔｓ１２５０４０〜ｔｓ１２５０８０）は、前述のとおりである。
【１３６０】
図１２６は、本発明の一実施例に係る、クローズドキャプション選好度において、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの拡張されたフィールドを示す図である。
【１３６１】
本発明のｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒは、前述したように、既存のｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの拡張又は変更であってもよい。
【１３６２】
本発明のｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒは、Ｆｏｎｔフィールド、Ｆｏｎｔ  Ｓｉｚｅフィールド、Ａｌｉｇｎｍｅｎｔフィールド、Ｐｒｉｎｔ  Ｄｉｒｅｃｔｉｏｎフィールド、及び／又はＳｃｒｏｌｌ  Ｄｉｒｅｃｔｉｏｎフィールドなどをさらに含むことができる（ｔ１２６０１０）。
【１３６３】
Ｆｏｎｔフィールドは、クローズドキャプションの字体を示すことができる。キャプションは、Ｆｏｎｔフィールドが０である場合には基本値、１の場合にはＭｏｎｏｓｐａｃｅｄ  ｗｉｔｈ  ｓｅｒｉｆｓ、２の場合にはＰｒｏｐｏｒｔｉｏｎａｌｌｙ  ｓｐａｃｅｄ  ｗｉｔｈ  ｓｅｒｉｆｓ、３の場合にはＭｏｎｏｓｐａｃｅｄ  ｗｉｔｈｏｕｔ  ｓｅｒｉｆｓ、４の場合にはＰｒｏｐｏｒｔｉｏｎａｌｌｙ  ｓｐａｃｅｄ  ｗｉｔｈｏｕｔ  ｓｅｒｉｆｓ、５の場合にはＣａｓｕａｌ  ｆｏｎｔ  ｔｙｐｅ、６の場合にはＣｕｒｓｉｖｅ  ｆｏｎｔ  ｔｙｐｅ、７の場合にはＳｍａｌｌ  ｃａｐｉｔａｌｓの字体を有することができる。Ｆｏｎｔフィールドは３ビットのフィールドであり、ｕｉｍｓｂｆフォーマットを有するものを一実施例とすることができる。
【１３６４】
Ｆｏｎｔ  Ｓｉｚｅフィールドは、クローズドキャプションの字サイズを示すことができる。キャプションは、Ｆｏｎｔ  Ｓｉｚｅフィールドが０の場合には基本値、１の場合にはＳｔａｎｄａｒｄ、２の場合にはＳｍａｌｌ、３の場合にはＬａｒｇｅ、の字サイズを有することができる。Ｆｏｎｔ  Ｓｉｚｅフィールドは２ビットのフィールドであり、ｕｉｍｓｂｆフォーマットを有するものを一実施例とすることができる。
【１３６５】
Ａｌｉｇｎｍｅｎｔフィールドは、クローズドキャプションの整列方法を示すことができる。キャプションは、Ａｌｉｇｎｍｅｎｔフィールドが０の場合には基本値、１の場合にはＬｅｆｔ、２の場合にはＲｉｇｈｔ、３の場合にはＣｅｎｔｅｒ、４の場合にはＦｕｌｌ、に整列されてもよい。Ａｌｉｇｎｍｅｎｔフィールドが５〜７である場合には、将来の使用のために残すことができる。Ａｌｉｇｎｍｅｎｔフィールドは３ビットのフィールドであり、ｕｉｍｓｂｆフォーマットを有するものを一実施例とすることができる。
【１３６６】
Ｐｒｉｎｔ  Ｄｉｒｅｃｔｉｏｎフィールドは、クローズドキャプションのプリントされる方向を示すことができる。キャプションは、Ｐｒｉｎｔ  Ｄｉｒｅｃｔｉｏｎフィールドが０の場合には基本値、１の場合にはＬｅｆｔ  ｔｏ  Ｒｉｇｈｔ、２の場合にはＲｉｇｈｔ  ｔｏ  Ｌｅｆｔ、３の場合にはＴｏｐ  ｔｏ  Ｂｏｔｔｏｍ、４の場合にはＢｏｔｔｏｍ  ｔｏ  Ｔｏｐ、の方向にプリントされてもよい。Ｐｒｉｎｔ  Ｄｉｒｅｃｔｉｏｎフィールドが５〜７である場合には、将来の使用のために残すことができる。Ｐｒｉｎｔ  Ｄｉｒｅｃｔｉｏｎフィールドは３ビットのフィールドであり、ｕｉｍｓｂｆフォーマットを有するものを一実施例とすることができる。
【１３６７】
Ｓｃｒｏｌｌ  Ｄｉｒｅｃｔｉｏｎフィールドは、クローズドキャプションのスクロールされる方向を示すことができる。キャプションは、Ｓｃｒｏｌｌ  Ｄｉｒｅｃｔｉｏｎフィールドが０の場合には基本値、１の場合にはＬｅｆｔ  ｔｏ  Ｒｉｇｈｔ、２の場合にはＲｉｇｈｔ  ｔｏ  Ｌｅｆｔ、３の場合にはＴｏｐ  ｔｏ  Ｂｏｔｔｏｍ、４の場合にはＢｏｔｔｏｍ  ｔｏ  Ｔｏｐ、の方向にスクロールされてもよい。Ｓｃｒｏｌｌ  Ｄｉｒｅｃｔｉｏｎフィールドが５〜７である場合には、将来の使用のために残すことができる。Ｓｃｒｏｌｌ  Ｄｉｒｅｃｔｉｏｎフィールドは３ビットのフィールドであり、ｕｉｍｓｂｆフォーマットを有するものを一実施例とすることができる。
【１３６８】
前述したように、受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒの各フィールドを参照して、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成／変換することができる。
【１３６９】
実施例によって、クローズドキャプションは、ビデオストリームのｕｓｅｒ＿ｄａｔａ領域に伝達されてもよい。クローズドキャプションがｕｓｅｒ＿ｄａｔａ領域に伝達されたことにもかかわらず、ＰＭＴ又はＥＩＴにｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒが伝達されない場合がある。この場合、受信機は、ｕｓｅｒ＿ｄａｔａ領域のクローズドキャプションデータを直接パースし、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎに変換してユーザに示すことができる。
【１３７０】
また、ＰＭＴ又はＥＩＴで伝達されるｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒに、前述した追加フィールドが含まれない場合がある。この場合、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒには、クローズドキャプションを使用するか否か、キャプション言語、イージーリーダモードなどに関連したフィールドだけがあってもよい。受信機は、クローズドキャプションを使用するか否か、キャプション言語、イージーリーダモードなどに関するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成／変換してユーザに示すことができる。受信機は、残りのプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎは、ビデオストリームのｕｓｅｒ＿ｄａｔａ領域に伝達されるクローズドキャプションをパースする過程でユーザに示すことができる。
【１３７１】
図１２７は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションの使用に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３７２】
デスクリプタがｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒである場合、当該デスクリプタのｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドが０ｘ８６の値を有することができる。当該デスクリプタがｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒである場合、受信機は、クローズドキャプションがあると、そのクローズドキャプションを見るか否かに対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは、該当のＰＤＩ  Ｑｕｅｓｔｉｏｎを用いてクローズドキャプションを使用するか否かを設定することができる。
【１３７３】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは、”Ａｒｅ  ｙｏｕ  ｕｓｉｎｇ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ？”のようであればよく、ユーザはそれに対して”Ｙｅｓ”又は”Ｎｏ”の答弁ができる。
【１３７４】
図１２８は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプション言語に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３７５】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｌａｎｇｕａｇｅフィールドを参照して、ユーザにとってクローズドキャプションの選好言語を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは、当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションに用いられる言語を設定することができる。
【１３７６】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎがが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｌａｎｇｕａｇｅ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｅｎｇｌｉｓｈ”、”Ｆｒｅｎｃｈ”、”Ｉｔａｌｉａｎ”又は”Ｅｔｃ”の答弁ができる。ユーザが答弁して設定された選好言語のクローズドキャプションが提供されない場合なら、受信機は、基本値（ｄｅｆａｕｌｔ）として提供される言語を用いてクローズドキャプションを提供することができる。
【１３７７】
図１２９は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションのフォントに対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３７８】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｆｏｎｔフィールドを参照して、ユーザにとってクローズドキャプションの選好フォントを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは、当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションに用いられるフォントを設定することができる。
【１３７９】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｆｏｎｔ  ｏｆ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｄｅｆａｕｌｔ”、”Ｍｏｎｏｓｐａｃｅｄ  ｗｉｔｈ  ｓｅｒｉｆｓ”、”Ｐｒｏｐｏｒｔｉｏｎａｌｌｙ  ｓｐａｃｅｄ  ｗｉｔｈ  ｓｅｒｉｆｓ”などの答弁ができる。
【１３８０】
ユーザが答弁して設定された選好フォントのクローズドキャプションが提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供されるフォントを用いてクローズドキャプションを提供することができる。また、実施例によって、受信機は、受信機で設定されたフォントにクローズドキャプションを強制的に変換して表示することもできる。
【１３８１】
図１３０は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションの文字サイズに対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３８２】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｆｏｎｔ＿ｓｉｚｅフィールドを参照して、ユーザにとってクローズドキャプションの選好文字サイズを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは、当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションに用いられる文字サイズを設定することができる。
【１３８３】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｆｏｎｔ  ｓｉｚｅ  ｏｆ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｄｅｆａｕｌｔ”、”Ｓｍａｌｌ”、”Ｎｏｒｍａｌ”又は”Ｂｉｇ”などの答弁ができる。
【１３８４】
ユーザが答弁して設定された選好文字サイズのクローズドキャプションが提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供される文字サイズを用いてクローズドキャプションを提供することができる。また、実施例によって、受信機は、受信機で設定された文字サイズにクローズドキャプションを強制的に変換して表示することもできる。
【１３８５】
図１３１は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションの整列に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３８６】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのａｌｉｇｎｍｅｎｔフィールドを参照して、ユーザにとってクローズドキャプションの選好整列を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションの整列を設定することができる。
【１３８７】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ａｌｉｇｎｍｅｎｔ  ｏｆ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｄｅｆａｕｌｔ”、”Ｌｅｆｔ”、”Ｒｉｇｈｔ”などの答弁ができる。
【１３８８】
ユーザが答弁して設定された選好整列方式のクローズドキャプションが提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供される整列方式を用いてクローズドキャプションを提供することができる。また、実施例によって、受信機は、受信機から設定された整列方式にクローズドキャプションを強制的に変換して表示することもできる。
【１３８９】
図１３２は、本発明の一実施例に係るクローズドキャプション選好度において、クローズドキャプションのプリントされる方向に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３９０】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｐｒｉｎｔ＿ｄｉｒｅｃｔｉｏｎフィールドを参照して、ユーザにとってクローズドキャプションの選好プリント方向を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションのプリント方向を設定することができる。
【１３９１】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｐｒｉｎｔ  ｄｉｒｅｃｔｉｏｎ  ｏｆ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｄｅｆａｕｌｔ”、”Ｌｅｆｔ  ｔｏ  Ｒｉｇｈｔ”、”Ｒｉｇｈｔ  ｔｏ  Ｌｅｆｔ”などの答弁ができる。
【１３９２】
ユーザが答弁して設定された選好プリント方向のクローズドキャプションが提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供されるプリント方向を用いてクローズドキャプションを提供することができる。また、実施例によって、受信機は、受信機で設定されたプリント方向にクローズドキャプションを強制的に変換して表示することもできる。
【１３９３】
図１３３は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションのスクロールされる方向に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３９４】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｓｃｒｏｌｌ＿ｄｉｒｅｃｔｉｏｎフィールドを参照して、ユーザにとってクローズドキャプションの選好スクロール方向を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションのスクロール方向を設定することができる。
【１３９５】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｓｃｒｏｌｌ  ｄｉｒｅｃｔｉｏｎ  ｏｆ  Ｃｌｏｓｅｄ  Ｃａｐｔｉｏｎ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｄｅｆａｕｌｔ”、”Ｌｅｆｔ  ｔｏ  Ｒｉｇｈｔ”、”Ｒｉｇｈｔ  ｔｏ  Ｌｅｆｔ”などの答弁ができる。
【１３９６】
ユーザが答弁して設定された選好スクロール方向のクローズドキャプションが提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供されるスクロール方向を用いてクローズドキャプションを提供することができる。また、実施例によって、受信機は、受信機で設定されたスクロール方向にクローズドキャプションを強制的に変換して表示することもできる。
【１３９７】
図１３４は、本発明の一実施例に係る、クローズドキャプション選好度において、クローズドキャプションのイージーリーダ（ｅａｓｙ  ｒｅａｄｅｒ）モードに対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１３９８】
受信機は、ｃａｐｔｉｏｎ＿ｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒのｅａｓｙ＿ｒｅａｄｅｒフィールドを参照して、ユーザにとってクローズドキャプションのイージーリーダ（ｅａｓｙ  ｒｅａｄｅｒ）モードを用いるか否かを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、クローズドキャプションのイージーリーダモードを使用するか否かを設定することができる。
【１３９９】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ａｒｅ  ｙｏｕ  ｕｓｉｎｇ  Ｅａｓｙ  Ｒｅａｄｅｒ  Ｍｏｄｅ？”のようであればよく、ユーザはそれに対して”Ｙｅｓ”、”Ｎｏ”などの答弁ができる。
【１４００】
ユーザが答弁して設定されたイージーリーダ形態のクローズドキャプションが提供されない場合なら、次のような実施例によって受信機が動作すればよい。第一の実施例として、受信機がイージーリーダの形態にクローズドキャプションを強制的に変換して表示することができる。第二の実施例として、受信機は、イージーリーダ形態のクローズドキャプションを提供する別途のサーバーからキャプションを受信してユーザに提供することができる。第三の実施例として、受信機は第３者（ｔｈｉｒｄ  ｐａｒｔｙ）のサーバーに接近して、様々なバージョンのクローズドキャプションを受け取ることができる。イージーリーダ形態のクローズドキャプションは、人の音声の他、ナレーション、効果音のような音も提供することができる。このような様々なクローズドキャプションは、放送局で提供しない場合、前述した第３者のサーバーから受けて、受信機がイージーリーダの形態に変換、表示することができる。
【１４０１】
図１３５は、本発明の一実施例に係るオーディオ選好度（Ａｕｄｉｏ  Ｐｒｅｆｅｒｅｎｃｅ）のシーケンスダイヤグラムを示す図である。
【１４０２】
前述したオーディオの選好度と関連して、ユーザはオーディオトラックの言語選好、視聴覚障害者のためのモードを使用するか否かなどを設定することができる。これらの情報は、オーディオをシグナルする過程で伝達されるデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）又はテーブルを参照することができる。クローズドキャプションに関連した情報が伝達されるチャネル、デスクリプタ又はテーブルは様々な形態で表現することができ、本発明はいずれかの一形態に限定されない。
【１４０３】
オーディオに関連した情報が伝達されるデスクリプタを、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒと称する。このデスクリプタは、オーディオに関連した基本的な情報を伝達するデスクリプタであってもよい。このデスクリプタは、従来技術で用いられる、オーディオ関連デスクリプタの情報を含み、これに加えて本発明で提案するフィールド／情報なども含むことができる。すなわち、既存のオーディオ関連デスクリプタの変形であってもよい。
【１４０４】
このＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴ／ＥＩＴで伝達することができる。このデスクリプタの情報を用いて、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、あらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換されてもよい。受信機はＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを受信すると、これをあらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換し、答弁を受けることができる。
【１４０５】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴでＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１４０６】
ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴ又はＥＩＴに含まれてもよい（ｔｓ１３５０１０）。前述したように、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、ＰＭＴ又はＥＩＴで伝達されてもよい。ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒが受信機に受信されると（ｔ１３５０２０）、受信機の内部／外部のシグナリングパーサーは、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを受信機の内部／外部のＰＤＩエンジンに伝達することができる（ｔｓ１３５０３０）。
【１４０７】
その後、ＰＤＩエンジンがＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを用いてＰＤＩ  Ｑｕｅｓｔｉｏｎを生成し、ＵＩを介して質問に対する答弁を受け、答弁をＰＤＩストアに追加／アップデートする動作（ｔｓ１３５０４０〜ｔｓ１３５０８０）は、前述のとおりである。
【１４０８】
実施例によって、既存に質問に対する答弁がある場合であっても、ユーザの選好度の変化がありうるため、ＵＩを介して該当の質問に対する答弁を再び受けることもできる。この場合、新しい答弁は、既存の答弁と答弁時刻などの側面で比較され、新しい答弁を既存の答弁に代えることができる。
【１４０９】
図１３６は、本発明の他の実施例に係る、オーディオ選好度のシーケンスダイヤグラムを示す図である。
【１４１０】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴをシグナリングサーバーに要求し、ＰＭＴ或いはＥＩＴでＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１４１１】
受信機はシグナリングサーバーにＰＭＴ又はＥＩＴを要求することができる（ｔｓ１３６０１０）。シグナリングサーバーは、要求されたＰＭＴ又はＥＩＴを受信機に伝達することができる（ｔｓ１３６０２０）。受信機は、ＰＭＴ、ＥＩＴ内のＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒをＰＤＩエンジンに伝達することができる（ｔｓ１３６０３０）。
【１４１２】
その後、ＰＤＩエンジンがＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒを用いてＰＤＩ  Ｑｕｅｓｔｉｏｎを生成し、ＵＩを介して質問に対する答弁を受け、答弁をＰＤＩストアに追加／アップデートする動作（ｔｓ１３６０４０〜ｔｓ１３６０８０）は、前述のとおりである。
【１４１３】
図１３７は、本発明の一実施例に係る、オーディオ選好度において、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒの拡張されたフィールドを示す図である。
【１４１４】
本発明のＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、前述したように、既存のオーディオ関連デスクリプタの拡張又は変更であってもよい。
【１４１５】
本発明のＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒは、ｌａｎｇｃｏｄフィールド、及び／又はｂｓｍｏｄフィールドなどをさらに含むことができる。
【１４１６】
ｌａｎｇｃｏｄフィールドはオーディオの言語コードを示すことができる。オーディオは、ｌａｎｇｃｏｄフィールドの値によってそれぞれ別個の言語で表現されてもよい。ｌａｎｇｃｏｄフィールドは８ビットのフィールドであり、ｂｓｌｂｆフォーマットを有するものを一実施例とすることができる。
【１４１７】
ｂｓｍｏｄフィールドは、視聴覚障害者のためのモードを使用するか否かを示すことができる。例えば、ｂｓｍｏｄフィールドの値が０００である場合には、ｃｏｍｐｌｅｔｅ  ｍａｉｎオーディオサービスを提供することができる。ｂｓｍｏｄフィールドの値が００１で場合には、ｍｕｓｉｃ  ａｎｄ  ｅｆｆｅｃｔｓオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールドの値が０１０である場合には、ｖｉｓｕａｌｌｙ  ｉｍｐａｉｒｅｄオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールドの値が０１１である場合には、ｈｅａｒｉｎｇ  ｉｍｐａｉｒｅｄオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールドの値が１００である場合には、ｄｉａｌｏｇｕｅオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールドの値が１０１である場合には、ｃｏｍｍｅｎｔａｒｙオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールドの値が１１０である場合にはｅｍｅｒｇｅｎｃｙオーディオサービスが提供されてもよい。ｂｓｍｏｄフィールド値が１１１である場合には、将来の使用のために残したり、他のオーディオサービス提供の表示に割り当てられてもよい。ｂｓｍｏｄフィールドは３ビットのフィールドであり、ｂｓｌｂｆフォーマットを有するものを一実施例とすることができる。
【１４１８】
前述したように、受信機は、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒの各フィールドを参照して、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成／変換することができる。
【１４１９】
実施例によって、オーディオはオーディオストリームで伝達されてもよい。このとき、ＰＭＴ又はＥＩＴでＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒが伝達されなくてもよい。この場合、受信機はオーディオストリームのオーディオを直接パースし、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎに変換してユーザに示すことができる。
【１４２０】
また、ＰＭＴ又はＥＩＴで伝達されるＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒに、前述した追加フィールドが伝達されなくてもよい。この場合、受信機は、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを、オーディオストリームのオーディオをパースする過程でユーザに示すことができる。
【１４２１】
図１３８は、本発明の一実施例に係る、オーディオ選好度において、オーディオの言語に対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４２２】
受信機は、ＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒのｌａｎｇｃｏｄフィールドを参照して、ユーザにとってオーディオの選好言語を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、オーディオに用いられる言語を設定することができる。
【１４２３】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ａｕｄｉｏ  ｌａｎｇｕａｇｅ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ？”のようであればよく、ユーザはそれに対して”Ｅｎｇｌｉｓｈ”、”Ｆｒｅｎｃｈ”、”Ｉｔａｌｉａｎ”又は”Ｅｔｃ”の答弁ができる。ユーザが答弁して設定された選好言語のオーディオが提供されない場合なら、受信機は基本値（ｄｅｆａｕｌｔ）として提供される言語を用いてクローズドキャプションを提供することができる。
【１４２４】
図１３９は、本発明の一実施例に係る、オーディオ選好度において、オーディオの聴覚障害者のためのモードを使用するか否かに対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４２５】
受信機はＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒのｂｓｍｏｄフィールドを参照して、ユーザにとってオーディオの聴覚障害者のためのモードを使用するか否かを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。ここで、聴覚障害者とは、聴覚を完全に失っているわけではないが、十分にその機能を果たし難い状態のユーザを意味することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、オーディオの聴覚障害者のためのモードを使用するか否かを設定することができる。
【１４２６】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ａｒｅ  ｙｏｕ  ｕｓｉｎｇ  ａｕｄｉｏ  ｈｅａｒｉｎｇ  ｉｍｐａｉｒｅｄ  ｍｏｄｅ？”のようであればよく、ユーザはそれに対して”Ｙｅｓ”、”Ｎｏ”の答弁ができる。オーディオの聴覚障害者のためのモードが提供されない場合、受信機は基本的なモードでオーディオを提供することができる。
【１４２７】
図１４０は、本発明の一実施例に係る、オーディオ選好度において、オーディオの視覚障害者のためのモードを使用するか否かに対するプレレジステッド（Ｐｒｅ−Ｒｅｇｉｓｔｅｒｅｄ）ＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４２８】
受信機はＡＣ−３＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｄｅｓｃｒｉｐｔｏｒのｂｓｍｏｄフィールドを参照して、ユーザにとってオーディオの視覚障害者のためのモードを使用するか否かを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。ここで、視覚障害者とは、視覚を完全に失っているわけではないが、十分にその機能を果たし難い状態のユーザを意味することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、オーディオの視覚障害者のためのモードを使用するか否かを設定することができる。
【１４２９】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ａｒｅ  ｙｏｕ  ｕｓｉｎｇ  ａｕｄｉｏ  ｖｉｓｕａｌｌｙ  ｉｍｐａｉｒｅｄ  ｍｏｄｅ？”のようであればよく、ユーザはそれに対して”Ｙｅｓ”、”Ｎｏ”の答弁ができる。オーディオの視覚障害者のためのモードが提供されない場合、受信機は基本的なモードでオーディオを提供することができる。
【１４３０】
図１４１は、本発明の一実施例に係る、接近性＆手話プレゼンテーション（Ａｃｃｅｓｓｉｂｉｌｉｔｙ  ＆  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）のシーケンスダイヤグラムを示す図である。
【１４３１】
前述した接近性＆手話プレゼンテーションの選好度と関連して、ユーザは、聴覚障害者のための接近性サービス又は手話サービスを使用するか否かなどを設定することができる。ここでいう聴覚障害者は、前述した聴覚障害者と違い、聴覚の損傷が深刻であり、手話サービスを利用しなければならないユーザを意味することができる。このとき、当該サービスを使用するか否か、手話の選好度（ＡＳＬ、ＫＳＬなど）を設定することができる。これらの情報は、接近性＆手話プレゼンテーション関連シグナリング過程で伝達されるデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）又はテーブルを参照することができる。接近性＆手話プレゼンテーションに関連した情報が伝達されるチャネル、デスクリプタ又はテーブルは様々な形態で表現することができ、本発明はいずれかの一形態に限定されない。
【１４３２】
接近性＆手話プレゼンテーションに関連した情報が伝達されるデスクリプタを、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒと称する。このデスクリプタは、接近性＆手話プレゼンテーションに関連した基本的な情報を伝達するデスクリプタであってもよい。このデスクリプタは、従来技術で用いられる、接近性＆手話プレゼンテーション関連デスクリプタの情報を含み、これに加えて、本発明で提案するフィールド／情報などをさらに含むことができる。すなわち、既存の接近性＆手話プレゼンテーション関連デスクリプタの変形であってもよい。
【１４３３】
このｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒは、手話サービスなどが提供される放送がある場合、ＰＭＴ／ＥＩＴで伝達されてもよい。ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒの情報を用いて、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒをあらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換することができる。受信機は、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒを受信すると、これをあらかじめ定義されたＰＤＩ  Ｑｕｅｓｔｉｏｎに変換し、答弁を受けることができる。
【１４３４】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴでｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１４３５】
このシーケンスにおいて、デスクリプタがＰＭＴ／ＥＩＴで伝達される過程及びシグナリングパーサーがデスクリプタをＰＤＩエンジンに伝達する過程（ｔｓ１４１０１０〜ｔｓ１４１０３０）は、前述した過程と同一であってもよい。ただし、この場合は、デスクリプタがｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒである点が異なる。
【１４３６】
その後、ＰＤＩエンジンがＰＤＩ  Ｑｕｅｓｔｉｏｎを生成し、ＵＩを介して質問に対する答弁を受け、答弁をＰＤＩストアに追加／アップデートする動作（ｔｓ１４１０４０〜ｔｓ１４１０８０）は、前述のとおりである。
【１４３７】
図１４２は、本発明の他の実施例に係る、接近性＆手話プレゼンテーションのシーケンスダイヤグラムを示す図である。
【１４３８】
この実施例のシーケンスは、受信機がＰＭＴ又はＥＩＴをシグナリングサーバーに要求し、ＰＭＴ或いはＥＩＴでｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒを受信する状況を想定した。
【１４３９】
このシーケンスにおいて、受信機がシグナリングサーバーにＰＭＴ又はＥＩＴを要求し、ＰＭＴ又はＥＩＴを受け取り、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒをＰＤＩエンジンに伝達する過程（ｔｓ１４２０１０〜ｔｓ１４２０３０）は、前述した過程と同一であってもよい。ただし、この場合は、デスクリプタがｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒである点が異なる。
【１４４０】
その後、ＰＤＩエンジンがＰＤＩ  Ｑｕｅｓｔｉｏｎを生成し、ＵＩを介して質問に対する答弁を受け、答弁をＰＤＩストアに追加／アップデートする動作（ｔｓ１４２０４０〜ｔｓ１４２０８０）は、前述のとおりである。
【１４４１】
図１４３は、本発明の一実施例に係る、接近性＆手話プレゼンテーションにおいて、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒを示す図である。
【１４４２】
ここで、ｄｅｓｃｒｉｐｔｏｒ  ｔａｇフィールドは、８ビットのフィールドであり、このデスクリプタが手話サービスを提供するためのデスクリプタであることを示すフィールドであってもよい。ｄｅｓｃｒｉｐｔｏｒ  ｌｅｎｇｔｈフィールドは、このｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒの長さを示すフィールドであり、８ビットの長さを有することができる。
【１４４３】
ｎｕｍｂｅｒ  ｏｆ  ｓｅｒｖｉｃｅｓフィールドは、５ビットのフィールドであり、種々の手話のサービスを受けるためのサービスナンバーを示すことができる。ｌａｎｇｕａｇｅフィールドは、該当の手話の言語（例えば、ＡＳＬ（Ａｍｅｒｉｃａｎ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ、ＫＳＬ（Ｋｏｒｅａｎ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）など）を示すフィールドであってもよい。
【１４４４】
ｒｅｓｏｌｕｔｉｏｎフィールドは、手話サービスの解像度を示し、ｃｏｄｅｃフィールドは、手話サービスのコーデックを示すことができる。ｌｏｃａｔｉｏｎフィールドは、手話サービスを画面に表示するための位置を示し、自動（Ａｕｔｏ  ｓｅｌｅｃｔｉｏｎ）、左下端（Ｌｏｗｅｒ  ｌｅｆｔ）、右下端（Ｌｏｗｅｒ  ｒｉｇｈｔ）、左上端（Ｕｐｐｅｒ  ｌｅｆｔ）、右上端（Ｕｐｐｅｒ  ｒｉｇｈｔ）などの値を有することができる。
【１４４５】
前述したように、受信機は、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒの各フィールドを参照して、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成／変換することができる。
【１４４６】
実施例によって、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒが受信機に伝達されない場合、受信機は、受信された手話サービス関連データを直接パースし、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎに変換してユーザに示すことができる。
【１４４７】
図１４４は、本発明の一実施例に係る、接近性＆手話プレゼンテーション選好度（Ａｃｃｅｓｓｉｂｉｌｉｔｙ  ＆  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ  Ｐｒｅｆｅｒｅｎｃｅ）において、接近性＆手話プレゼンテーションの使用に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４４８】
受信機は、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒのｄｅｓｃｒｉｐｔｏｒ＿ｔａｇフィールドを参照して、ユーザにとって接近性＆手話プレゼンテーションを使用するか否かを設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、接近性＆手話プレゼンテーションを使用するか否かを設定することができる。
【１４４９】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ａｒｅ  ｙｏｕ  ｕｓｉｎｇ  ｓｉｇｎ  ｌａｎｇｕａｇｅ  ｍｏｄｅ？”のようであればよく、ユーザはそれに対して”Ｙｅｓ”、”Ｎｏ”などの答弁ができる。
【１４５０】
図１４５は、本発明の一実施例に係る、接近性＆手話プレゼンテーション選好度において、手話言語の選好度に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４５１】
受信機は、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒのｌａｎｇｕａｇｅフィールドを参照して、ユーザにとって手話サービスの選好言語を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、手話サービスに用いられる言語を設定することができる。
【１４５２】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｓｉｇｎ  ｌａｎｇｕａｇｅ  ａｒｅ  ｙｏｕ  ｕｓｉｎｇ？”のようであればよく、ユーザはそれに対して”ＡＳＬ（Ａｍｅｒｉｃａｎ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）”、”ＬＳＦ（Ｆｒｅｎｃｈ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）”、”ＬＳＭ（Ｍｅｘｉｃａｎ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）”などの答弁ができる。
【１４５３】
ユーザが答弁して設定された選好手話言語が提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供される手話言語を用いて手話サービスを提供することができる。また、実施例によって、受信機は、様々なバージョンの手話言語を提供する第３者（ｔｈｉｒｄ  ｐａｒｔｙ）のサーバーに接近して該当の手話言語サービスを受け取り、画面に表示することもできる。
【１４５４】
図１４６は、本発明の一実施例に係る、接近性＆手話プレゼンテーション選好度において、手話の位置の選好度に対するプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを示す図である。
【１４５５】
受信機は、ｓｉｇｎ＿ｌａｎｇｕａｇｅ＿ｄｅｓｃｒｉｐｔｏｒのｌｏｃａｔｉｏｎフィールドを参照して、ユーザにとって手話が画面上に現れる選好位置を設定できるプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎを生成することができる。受信機は、生成されたＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示し、それに対する答弁を保存することができる。ユーザは当該ＰＤＩ  Ｑｕｅｓｔｉｏｎを用いて、手話が表示される位置を設定することができる。
【１４５６】
この実施例で、ＱＳＡ形態のＰＤＩ  Ｑｕｅｓｔｉｏｎが生成されてユーザに示されてもよい。質問のテキストは”Ｗｈｉｃｈ  ｌｏｃａｔｉｏｎ  ｏｆ  ｓｉｇｎ  ｌａｎｇｕａｇｅ  ｄｏ  ｙｏｕ  ｐｒｅｆｅｒ  ｔｏ  ｐｒｅｓｅｎｔ？”のようであればよく、ユーザはそれに対して”Ｌｏｗｅｒ  Ｌｅｆｔ”、”Ｌｏｗｅｒ  Ｒｉｇｈｔ”、”Ｕｐｐｅｒ  Ｌｅｆｔ”などの答弁ができる。
【１４５７】
ユーザが答弁して設定された選好手話位置が提供されない場合なら、実施例によって、受信機は、基本値（ｄｅｆａｕｌｔ）として提供される手話位置に手話サービスを提供することができる。また、実施例によって、受信機は、受信機で設定された位置に強制的に手話サービスを表示することもできる。
【１４５８】
図１４７は、本発明の一実施例に係る、プレゼンテーション選好度（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｐｒｅｆｅｒｅｎｃｅ）において、答弁のアップデートのためのメニュー画面を示す図である。
【１４５９】
ユーザがプレゼンテーション選好度に関連したプレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎに答弁をすると、それ以降では、そのプレゼンテーション選好度に関連したサービスの提供時に同一Ｑｕｅｓｔｉｏｎがユーザに露出されなくてもよい。この場合、そのプレゼンテーション選好度に関連したサービスの提供時に、既に保存された答弁が活用され、そのサービスを提供するか否かなどが制御されてもよい。
【１４６０】
しかしながら、この場合には、一度保存された答弁を変更することができず、よって、ユーザの選好度が変わる場合に答弁をアップデートする方案が必要である。答弁のアップデートのために、満了フィールド（Ｅｘｐｒｉｅ  ｆｉｅｌｄ）が用いられたり、又は、ビューイングプリファレンスメニュー（Ｖｉｅｗｉｎｇ  Ｐｒｅｆｅｒｅｎｃｅ  Ｍｅｎｕ）が提供されてもよい。実施例によって、アップデートに他の方法が用いられてもよい。
【１４６１】
まず、満了フィールドについて説明する。
【１４６２】
ＰＤＩ  Ｑｕｅｓｔｉｏｎは、満了フィールド（Ｅｘｐｒｉｅ  ｆｉｅｌｄ）を有することができる。プレゼンテーション選好度に関連したＰＤＩ  Ｑｕｅｓｔｉｏｎをユーザに示すとき、満了フィールドを適切に設定することができる。満了フィールドに設定された時間が過ぎると、受信機はユーザに該当のＰＤＩ  Ｑｕｅｓｔｉｏｎを再び見せることができる。ユーザは、再び見せられた質問に対して返答をし、答弁をアップデートすることができる。
【１４６３】
ＰＤＩ  Ｑｕｅｓｔｉｏｎに対する答弁は、一定時間が過ぎると自動で消滅してもよい。その後、受信機が関連サービスを受け取ると、ＰＤＩストアに保存された質問及び答弁があるか確認した後、プレレジステッドＰＤＩ  Ｑｕｅｓｔｉｏｎの形態で再びユーザに露出させることができる。
【１４６４】
ビューイングプリファレンスメニューについて説明する。
【１４６５】
受信機はビューイングプリファレンスメニューを提供することができる。ビューイングプリファレンスメニューは、ユーザが確認／変更できるネイティブ（Ｎａｔｉｖｅ）形態のメニューであってもよい。ユーザは、所望時にはいつでも当該メニューに接近してプレゼンテーション選好度を変更することができる。
【１４６６】
ビューイングプリファレンスメニューが活性化されると、受信機は、ＰＤＩストアからプレゼンテーション選好度に関連した質問の答弁を確認し、保存された答弁をＵＩを介してユーザに示すことができる（ｔ１４７０１０）。ユーザは、ビューイングプリファレンスメニューを介してプレゼンテーション選好度の値を変更することができる。変更された値は、該当のプレレジステッドＰＤＩ  ＱｕｅｓｔｉｏｎのＩＤを参照してＰＤＩストアに保存され、既に保存された答弁をアップデートさせることができる。
【１４６７】
図１４８は、本発明の更に他の実施例に係る、受信機とコンパニオンデバイスの間のユーザデータ交換の構造を示す図である。
【１４６８】
既存のＰＤＩシステムは、一人のユーザに個人化されたサービスを提供する形態であったため、複数のユーザ間の選好度及びＱ＆Ａを管理することは不可能だった。本発明では、ＰＤＩユーザデータを複数のユーザ間に別々に設定し、ユーザによって個人化されたサービスを提供する方法を提案する。
【１４６９】
この構造図で、コンテンツプロバイダ又はブロードキャスタ、ＰＤＩ質問紙、ＰＤＩエンジン、ＰＤＩストア、ＰＤＩクラウドストア、コンパニオンデバイスモジュール、コンパニオンデバイス、フィルタリングエンジン、コンテンツ／サービスストアは、前述した同名のモジュールと同一であってもよい。
【１４７０】
この構造図で、受信機ｔ１４８０２０は、前述した構造図と違い、ユーザマネジメントエンジン（Ｕｓｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｇｉｎｅ）ｔ１４８０１０をさらに含むことができる。
【１４７１】
ユーザマネジメントエンジンｔ１４８０１０は、複数のユーザ間にＰＤＩユーザデータを管理する役割を担うことができる。複数のユーザごとに選好度が異なりうるため、ユーザマネジメントエンジンｔ１４８０１０は、ユーザを区分し、各ユーザに合うように答弁保存及び／又はフィルタリングされたコンテンツ及びサービスを伝達することができる。実施例によって、ユーザマネジメントエンジンｔ１４８０１０の動作は、ＰＤＩエンジン又は別途のモジュールで処理されてもよい。
【１４７２】
図１４９は、本発明の一実施例に係る、ユーザＩＤフィールドをさらに含むＰＤＩＵｓｅｒＤａｔａを示す図である。
【１４７３】
受信機が複数のユーザを区分し、それぞれのユーザの選好度に合わせてコンテンツ／サービスを提供するためには、ユーザマネジメントエンジンが複数のユーザを識別する必要がある。ユーザマネジメントエンジンが複数のユーザを識別する方案は、次のとおりである。複数のユーザを識別する方案は、実施例によって様々なものが選択されてもよい。
【１４７４】
まず、ログイン（ｌｏｇ  ｉｎ）方式は、ユーザにＰＤＩ  Ｑｕｅｓｔｉｏｎを見せる前に、ユーザがログインする方式を意味することができる。ユーザマネジメントエンジンは、ＵＩを介してログインウィンドウをユーザに露出することができる。ログインウィンドウが露出される時点は、実施例によって、受信機がついた直後、又はＰＤＩ質問紙を受信した時点であってもよい。
【１４７５】
ユーザは、ログインウィンドウが露出されると、自身のユーザＩＤでログインすることができる。ユーザＩＤが存在しない場合、ユーザは自身のユーザＩＤを生成すればよく、ユーザＩＤの生成及び管理はユーザマネジメントモジュールで行うことができる。実施例によって、ログインウィンドウは、コンパニオンデバイスで露出されてもよい。この場合、ユーザはコンパニオンデバイスを介してログインしてもよい。
【１４７６】
次に、自動識別（Ａｕｔｏｍａｔｉｃ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）方式は、ユーザがユーザＩＤを直接入力するのではなく、受信機内ユーザマネジメントエンジンが自動でユーザを識別する方式を意味することができる。ユーザを自動で識別するために、顔認識（Ｆａｃｅ  Ｒｅｃｏｇｎｉｔｉｏｎ）又は音声認識（Ｖｏｉｃｅ  Ｒｅｃｏｇｎｉｔｉｏｎ）方式を用いることができる。
【１４７７】
ユーザが自動識別方式によって識別されると、当該ユーザのユーザＩＤで自動ログインされてもよい。ユーザが初めて認識された場合には、ユーザマネジメントエンジンは当該ユーザのユーザＩＤを生成して管理することができる。
【１４７８】
ユーザが自身のＩＤでログインされた状態では、自身固有のＰＤＩ  Ｑ＆Ａを作成することができる。そのために、前述したＰＤＩユーザデータ（ＰＤＩＵｓｅｒＤａｔａ）は図示のように変形されてもよい。
【１４７９】
まず、ＰＤＩＵｓｅｒＤａｔａは、＠ｕｓｅｒ＿ｉｄフィールドをさらに有することができる（ｔ１４９０１０）。＠ｕｓｅｒ＿ｉｄフィールドは、ｓｔｒｉｎｇタイプのフィールドであり、ユーザＩＤを示すフィールドであってもよい。また、各ＱｘＡ、すなわち、ＰＤＩ  Ｑｕｅｓｔｉｏｎもまた＠ｕｓｅｒ＿ｉｄフィールドをさらに有することができる（ｔ１４９０２０）。ＱｘＡＴｙｐｅには、＠ｕｓｅｒ＿ｉｄフィールドが追加される。図示のＱｘＡはＱＩＡであるが、他の形態のＱｕｅｓｔｉｏｎにも＠ｕｓｅｒ＿ｉｄフィールドを追加することができる。
【１４８０】
図１５０は、本発明の一実施例に係る、ユーザＩＤを用いてＰＤＩ  Ｑｕｅｓｔｉｏｎに対する答弁を得るシーケンスダイヤグラムを示す図である。
【１４８１】
コンテンツプロバイダ又はブロードキャスタはＰＤＩテーブルを受信機に伝達することができる（ｔｓ１５００１０）。このとき、ＰＤＩテーブルをブロードキャスト又はブロードバンドチャネルで伝達することができる。受信機は、伝達されたＰＤＩテーブルをＰＤＩエンジンに伝達することができる（ｔｓ１５００２０）。ＰＤＩエンジンはユーザマネジメントエンジンにＰＤＩテーブルが受信されたことを知らせることができる（ｔｓ１５００３０）。
【１４８２】
ユーザマネジメントエンジンは、ユーザがログインされているか否かのログイン状態をチェックすることができる（ｔｓ１５００４０）。ログインされていない状態の場合、ユーザマネジメントエンジンはＵＩを介してログインＵＩをユーザに露出させることができる（ｔｓ１５００５０）。ユーザはログインＵＩを介してログインプロセスを行うことができる（ｔｓ１５００９６０）。又は、実施例によって、受信機が顔認識／音声認識などを用いて自動でユーザを認識することもできる。ＵＩは、入力されたユーザＩＤ情報をユーザマネジメントエンジンに伝達することができる（ｔｓ１５００７０）。
【１４８３】
万一、ユーザが既にログインされている状態であれば、ユーザマネジメントエンジンはログインプロセスを省略してもよい。この場合、前述したｔｓ１５００４０〜ｔｓ１５００７０段階は省略されてもよい。ユーザマネジメントエンジンは、ユーザがログインされている事実を持続的に記憶していてもよい。
【１４８４】
ユーザマネジメントエンジンは、ユーザＩＤが有効であるか否かを確認することができる（ｔｓ１５００８０）。仮に、受け取ったＩＤが登録されていないＩＤであれば、別途の登録（ｒｅｇｉｓｔｒａｔｉｏｎ）過程を行うことができる。この登録過程は、ＵＩを介して、ユーザの情報を受け取り、ユーザＩＤを生成する過程であってもよい。
【１４８５】
受け取ったＩＤが有効であれば、ユーザマネジメントモジュールは、このＩＤをＰＤＩエンジンに伝達することができる（ｔｓ１５００９０）。ＰＤＩエンジンは、受け取ったユーザＩＤをＰＤＩテーブルに保存することができる（ｔｓ１５０１００）。このとき、前述したＰＤＩテーブル内の＠ｕｓｅｒ＿ｉｄフィールドが用いられてもよい。また、各Ｑｕｅｓｔｉｏｎ別ＱｘＡフィールドの＠ｕｓｅｒ＿ｉｄフィールドにもユーザＩＤが保存されてもよい。
【１４８６】
ＰＤＩエンジンはＵＩを介してＰＤＩ  Ｑｕｅｓｔｉｏｎを露出させることができる（ｔｓ１５０１１０）。ユーザはＵＩを介して答弁を入力し（ｔｓ１５０１２０）、ＵＩはこの答弁をＰＤＩエンジンに伝達することができる（ｔｓ１５０１３０）。ＰＤＩエンジンは該当の答弁をＰＤＩストアに保存することができる（ｔｓ１５０１４０）。このＰＤＩユーザデータは、後にユーザ別個人化サービスを提供する時に活用することができる。
【１４８７】
ユーザに重複質問が露出されることを防止する方法を説明する。
【１４８８】
ユーザがログインされた後に、同一ＰＤＩ  Ｑｕｅｓｔｉｏｎが受信機に伝達されると、ユーザが既に答えたＰＤＩ  Ｑｕｅｓｔｉｏｎが再びユーザに露出されることがある。これを防止するために、次のような方法を考慮することができる。
【１４８９】
まず、受け取ったＰＤＩ  ＱｕｅｓｔｉｏｎのＩＤと同じＩＤを有するＰＤＩ  Ｑｕｅｓｔｉｏｎとその答弁が、既にＰＤＩストアに保存されているか確認することができる。
【１４９０】
第一に、該当のＰＤＩ  Ｑｕｅｓｔｉｏｎの答弁が既に保存されていない場合、当該ＰＤＩ  ＱｕｅｓｔｉｏｎはＵＩを介してユーザに露出され、ユーザは該当の質問に答弁することができる。
【１４９１】
第二に、該当のＰＤＩ  Ｑｕｅｓｔｉｏｎの答弁が既に保存されているが、そのＰＤＩ  Ｑｕｅｓｔｉｏｎの＠ｕｓｅｒ＿ｉｄが現在ログインされたユーザのＩＤと異なる場合、当該ＰＤＩ  ＱｕｅｓｔｉｏｎはＵＩを介してユーザに露出され、ユーザは該当の質問に答弁することができる。既に保存された答弁は他のユーザの答弁であるためである。
【１４９２】
第三に、該当のＰＤＩ  Ｑｕｅｓｔｉｏｎの答弁が既に保存されており、そのＰＤＩ  Ｑｕｅｓｔｉｏｎの＠ｕｓｅｒ＿ｉｄが、現在ログインされたユーザのＩＤと同一である場合、当該ＰＤＩ  Ｑｕｅｓｔｉｏｎはユーザに露出されなくてもよい。該当のユーザが該当りＰＤＩ  Ｑｕｅｓｔｉｏｎに既に答弁をした状態であるためである。この場合、既に保存された答弁を、受け取ったＰＤＩ  Ｑｕｅｓｔｉｏｎの答弁として保存することができる。
【１４９３】
図１５１は、本発明の一実施例に係る、ユーザＩＤを用いてフィルタリングクライテリアを適用するシーケンスダイヤグラムを示す図である。
【１４９４】
フィルタリングクライテリアによってコンテンツ／サービスをフィルタリングする場合にも、ユーザＩＤを用いて複数のユーザを区分する必要がある。複数のユーザの選好度に合わせてコンテンツ／サービスを提供するためには、入力されたユーザ別Ｑ＆Ａを用いてＦＣを適用しなければならない。
【１４９５】
このシーケンスダイヤグラムにおいて、ユーザは既にログインされた状態であると仮定する。
【１４９６】
コンテンツプロバイダ又はブロードキャスタはＦＣを受信機に伝達することができる（ｔｓ１５１０１０）。このとき、ＦＣをブロードキャスト又はブロードバンドチャネルで伝達することができる。受信機は、受け取ったＦＣデスクリプタ又はテーブルをシグナルし、これをパースした後、ＦＣ集合をＦＣエンジンに伝達することができる（ｔｓ１５１０２０）。
【１４９７】
ＦＣエンジンはユーザマネジメントエンジンにユーザＩＤを要求することができる（ｔｓ１５１０３０）。ユーザマネジメントエンジンは、要求されたユーザＩＤをリターンすることができる（ｔｓ１５１０４０）。実施例によって、ＰＤＩテーブルがユーザＩＤを要求し、それを受けることもできるる。
【１４９８】
ＦＣエンジンはＰＤＩエンジンに、受け取ったユーザＩＤを有するＰＤＩ  Ｑ＆Ａを要求することができる（ｔｓ１５１０５０）。ＰＤＩエンジンは当該ＰＤＩ  Ｑ＆ＡをＰＤＩストアから検索することができる（ｔｓ１５１０６０）。ＰＤＩエンジンは、検索されたＰＤＩ  Ｑ＆ＡをＦＣエンジンに伝達することができる（ｔｓ１５１０７０）。
【１４９９】
ＦＣエンジンは、受け取ったＰＤＩデータとＦＣ集合とを比較することができる（ｔｓ１５１０８０）。この比較から、該当のコンテンツ／サービスが該当のユーザに適したコンテンツ／サービスであるかを判断することができる。ＦＣ集合にマッチされるコンテンツ／サービスであれば、ＦＣエンジンはＦＬＵＴＥセッションから該当のコンテンツ／サービスをダウンロードすることができる。実施例によって、ＦＬＵＴＥセッションではなく他のソースからダウンロードされてもよい。
【１５００】
現在ログインされているユーザに適しないコンテンツ／サービスであっても、ユーザマネジメントエンジンによって管理されるユーザのうち、当該コンテンツ／サービスを好むユーザがある場合には、将来の使用のために当該コンテンツ／サービスをダウンロードしておいてもよい。ユーザマネジメントエンジンによって管理されるユーザのうち、当該コンテンツ／サービスを好むユーザがいないと、当該コンテンツ／サービスをダウンロードしなくてもよい。
【１５０１】
図１５２は、本発明の一実施例に係る、ユーザＩＤを割り当てる方法を示す図である。
【１５０２】
前述したように、ユーザを区分するためにｕｓｅｒ＿ｉｄフィールドを用いることができる。このとき、ｕｓｅｒ＿ｉｄフィールドに保存されるユーザＩＤは、ローカルユニークＩＤ方式（Ｌｏｃａｌ  Ｕｎｉｑｕｅ  ＩＤ  Ｍｅｔｈｏｄ）又はグローバルユニークＩＤ方式（Ｇｌｏｂａｌｌｙ  Ｕｎｉｑｕｅ  ＩＤ  Ｍｅｔｈｏｄ）によって保存することができる。実施例によって、ユーザＩＤは、他の方式で保存されてもよい。
【１５０３】
ローカルユニークＩＤ方式は、受信機及びホームネットワーク環境の範囲でユニークなＩＤを用いる方式を意味できる。このとき、ユーザＩＤは、ｓｔｒｉｎｇデータタイプを有することができ、ユーザマネジメントエンジンによって管理されてもよい。
【１５０４】
前述したログイン方式にしたがう場合、すなわち、ユーザが手動でユーザＩＤでログインする場合、ローカルユニークＩＤをユーザによって制約なしでｓｔｒｉｎｇ形態で登録することができる。ユーザマネジメントエンジンは、登録しようとするＩＤが重複するＩＤであれば、ユーザに再登録を要求することができる。
【１５０５】
前述した自動識別方式にしたがう場合、ユーザマネジメントエンジンは、新しく認識されたユーザに自動でランダムにユーザＩＤを設定／割り当てしておくことができる。
【１５０６】
グローバルユニークＩＤ方式は、グローバルな範囲でユニークなＩＤを用いる方式を意味できる。このとき、ユーザＩＤは同様に、ｓｔｒｉｎｇデータタイプを有することができ、ユーザマネジメントエンジンによって管理されてもよい。
【１５０７】
ここで、グローバルな範囲とは、ホームネットワークを越えて他の受信機も含まれた範囲をいうこともでき、サービスプロバイダのシステムが及ぶ範囲であってもよく、全世界を範囲とすることもできる。これにより、本発明に係るＰＤＩシステムが適用された受信機が位置する場所ではどこでも、ユーザは自身のＩＤでログインした後、自身のＰＤＩ  Ｑｕｅｓｔｉｏｎに合わせてコンテンツ／サービスの提供を受けることができる。そのためには、ユーザＩＤ及びこれによるＱ＆Ａを保存可能な共用ストレージを備える必要がある（例えば、クラウドストレージ）。
【１５０８】
前述したログイン方式及び自動識別方式にしたがう場合、ローカルユニークＩＤ方式のような方式で動作できる。
【１５０９】
グローバルユニークＩＤ生成のために、ユーザＩＤを次のような方式で組み合わせることができる。
【１５１０】
ｕｓｅｒ＿ｉｄ：＜ｍａｎｕａｌｌｙ  ａｓｓｉｇｎｅｄ  ｉｄ  ｂｙ  ｕｓｅｒ＞＿＜ｕｎｉｑｕｅｌｙ  ｉｄｅｎｔｉｆｉａｂｌｅ  ｄａｔａ＞
【１５１１】
ここで、＜Ｍａｎｕａｌｌｙ  ａｓｓｉｇｎｅｄ  ｉｄ  ｂｙ  ｕｓｅｒ＞は、ユーザによって直接指定されるＩＤであってもよい。また、ここで、＜Ｕｎｉｑｕｅｌｙ  ｉｄｅｎｔｉｆｉａｂｌｅ  ｄａｔａ＞は、ユーザによって直接指定されたり、或いは直接指定されないものの、ＩＤをグローバルにユニークに区別させるデータであってもよい。実施例によって、＜Ｕｎｉｑｕｅｌｙ  ｉｄｅｎｔｉｆｉａｂｌｅ  ｄａｔａ＞は、ユーザのイメールアドレス、電話番号又はデバイスのＭＡＣアドレスなどを含むことができる。
【１５１２】
グローバルユニークＩＤは、＜ｍａｎｕａｌｌｙ  ａｓｓｉｇｎｅｄ  ｉｄ  ｂｙ  ｕｓｅｒ＞及び＜ｕｎｉｑｕｅｌｙ  ｉｄｅｎｔｉｆｉａｂｌｅ  ｄａｔａ＞の組合せによってグローバルにユニークとなり得る。＜ｍａｎｕａｌｌｙ  ａｓｓｉｇｎｅｄ  ｉｄ  ｂｙ  ｕｓｅｒ＞は、複数のユーザ間に同一であってもよく、＜ｕｎｉｑｕｅｌｙ  ｉｄｅｎｔｉｆｉａｂｌｅ  ｄａｔａ＞によって全グローバルユニークＩＤはグローバルにユニークとなってもよい。
【１５１３】
図１５３は、本発明の一実施例に係るチャネル或いはプログラムの推奨に用いる選好度クライテリア（Ｐｒｅｆｅｒｅｎｃｅ  Ｃｒｉｔｅｒｉａ）のＸＭＬスキマー（Ｓｃｈｅｍａ）のダイヤグラムを示す図である。
【１５１４】
次世代放送システムで提供するＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）は、ＥＰＧのようなコンテンツ番組表の情報を伝達することができる。これに加えて、次世代放送システムで提供するＥＳＧは、ユーザが好むようなチャネル又はプログラムを推奨することができる。
【１５１５】
このような機能を提供するために、前述したＰＤＩストアに保存されたＰＤＩユーザデータを活用することができる。前述したＰＤＩシステムを用いて、ユーザはＰＤＩ質問に対してＰＤＩ答弁を保存しておいてもよい。これらの答弁は、ユーザの選好度が反映されたままＰＤＩストアに保存されていてもよい。サービスプロバイダは、送信するチャネル又はプログラムごとにそのコンテンツの選好度情報をタグ付け（ｔａｇｇｉｎｇ）することができる。このタグ情報をＰＤＩストアの答弁と比較し、ユーザの好むコンテンツを選別することができる。すなわち、ユーザが既に作成したＱ＆Ａを用いて、ユーザの選好度に合うチャネル又はプログラムを推奨することができる。
【１５１６】
本発明は、ＰＤＩストアに保存されているユーザのＰＤＩ  Ｑ＆Ａを用いてＥＳＧを提供する方案を提案する。
【１５１７】
前述したように、ＰＤＩ質問（Ｑｕｅｓｔｉｏｎ）は、ＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、又はＱＴＡタイプを有することができる。ＱＩＡは、整数形態の答弁が可能なＱ＆Ａ、ＱＢＡはブール（Ｂｏｏｌｅａｎ）形態で答弁可能なＱ＆Ａ、ＱＳＡは選択（Ｓｅｌｅｃｔｉｏｎ）形態で答弁可能なＱ＆Ａ、ＱＴＡはテキスト（Ｔｅｘｔ（ｓｔｒｉｎｇ））形態で答弁可能なＱ＆Ａ、ＱＡＡはその他の形態で答弁可能なＱ＆Ａ（例えば、イメージなど）を意味することができる。
【１５１８】
前述したような様々な形態のＱ＆Ａ情報をＰＤＩストアに保存することができる。したがって、選好度クライテリアも同様に、各タイプのＱ＆Ａによるクライテリオンを含むことができる。これは、チャネル或いはプログラムごとに選好度情報をタグする時、各質問タイプに合わせてタグ可能にするためである。
【１５１９】
すなわち、図示の選好度クライテリアのＸＭＬダイヤグラムは、前述したＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、及び／又はＱＴＡタイプのクライテリオンを含むことができる。実施例によって、選好度クライテリアは、各タイプのクライテリオンの一部だけを含み、一部のタイプのクライテリオンは省略されてもよい。
【１５２０】
ここで、選好度クライテリアは、フィルタリングクライテリアと呼ぶこともできる。
【１５２１】
図１５４は、本発明の一実施例に係るチャネル或いはプログラムの推奨に用いる選好度クライテリアのＸＭＬスキマーを示す図である。
【１５２２】
同図のＸＭＬスキマーは、前述したＸＭＬダイヤグラムの内容をＸＭＬ文書で作成している。
【１５２３】
選好度クライテリアは、それぞれＱＩＡ、ＱＢＡ、ＱＳＡ、ＱＴＡ、及び／又はＱＴＡタイプのクライテリオンを含むことができる。各クライテリオンは、選好度値（ＣｒｉｔｅｒｉｏｎＶａｌｕｅ）、タイプ（ｔｙｐｅ）、必須／選択（ｒｅｑｕｉｒｅｄ／ｏｐｔｉｏｎａｌ）などの情報を含むことができる。
【１５２４】
このＸＭＬスキマーは、一実施例に過ぎず、実施例によって他の方式で作成されてもよい。
【１５２５】
図１５５は、本発明の一実施例に係る、チャネル或いはプログラムの推奨に用いる選好度クライテリアのデスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）を示す図である。
【１５２６】
前述した選好度クライテリアは、デスクリプタを用いてバイナリ（ｂｉｎａｒｙ）形態で伝達されてもよい。選好度クライテリアのデスクリプタは、前述したＸＭＬダイヤグラムの構造及び情報を各フィールドに含めて伝達することができる。
【１５２７】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、８ビットのフィールドであり、当該デスクリプタが選好度クライテリアデスクリプタ（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ  ｄｅｓｃｒｉｐｔｏｒ）であるかを示すことができる。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、８ビットのフィールドであり、当該デスクリプタの長さを示すことができる。ｎｕｍ＿ｐｒｅｆｅｒｅｎｃｅ＿ｃｒｉｔｅｒｉａは、８ビットのフィールドであり、当該デスクリプタが表現する選好度クライテリアが含む選好度クライテリオンの個数を示すことができる。
【１５２８】
選好度デスクリプタは、そのデスクリプタが含む各選好度クライテリオンの情報を、ｆｏｒ文を用いて示すことができる。ｆｏｒ文は、そのデスクリプタが含むそれぞれの選好度クライテリオンの個数分だけ反復されてもよい。
【１５２９】
ｃｒｉｔｅｒｉｏｎ＿ｉｄ＿ｌｅｎｇｔｈは、８ビットのフィールドであり、当該クライテリオンのＩＤの長さを示すことができる。ｃｒｉｔｅｒｉｏｎ＿ｉｄは、変更可能なサイズのフィールドであり、当該クライテリオンのＩＤを示すことができる。このＩＤ情報は、ＰＤＩ質問（Ｑｕｅｓｔｉｏｎ）ＩＤとマップしてコンテンツの選別に活用されてもよい。
【１５３０】
ｃｒｉｔｅｒｉｏｎ＿ｔｙｐｅ＿ｃｏｄｅは、３ビットのフィールドであり、当該クライテリオンのタイプを示すことができる。すなわち、０ｘ０１の場合、選択ＩＤを含む整数タイプ、０ｘ０２はブールタイプ、０ｘ０３はストリングタイプを示すことができる。０ｘ００、０ｘ０４−０ｘ０７は、将来の使用のために残すことができる（ｒｅｓｅｒｖｅｄ）。ここで、実施例によって、０ｘ０１は、当該クライテリオンが前述のＱＩＡ、ＱＳＡに該当することを示すことができ、０ｘ０２は、当該クライテリオンがＱＢＡに該当することを示し、０ｘ０３は、当該クライテリオンが前述のＱＴＡに該当することを示すことができる。
【１５３１】
ｎｕｍ＿ｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅｓは、５ビットのフィールドであり、当該クライテリオンが有する値（ｖａｌｕｅ）の個数を意味することができる。当該クライテリオンが複数個の値を有する場合、各値に関する情報がｆｏｒ文で表現されてもよい。
【１５３２】
ｃｒｉｔｅｒｉｏｎ＿ｖａｌｕｅ＿ｌｅｎｇｔｈは、該当値の長さ情報を示すフィールドであり、８ビットの長さを有することができる。ｃｒｉｔｅｒｉｏｎ  ｖａｌｕｅは、該当値を示すフィールドであり、変更可能な長さを有することができる。ｃｒｉｔｅｒｉｏｎ  ｖａｌｕｅは、ユーザ推奨のためにＰＤＩユーザデータのＰＤＩ答弁とマッチすべき値を有することができる。
【１５３３】
ここで、各フィールドの長さ及びフォーマットは、実施例によって変更されてもよい。
【１５３４】
図１５６は、本発明の一実施例に係る、サービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーの拡張ダイヤグラムを示す図である。
【１５３５】
前述した選好度クライテリアは、ＥＳＧを提供するために受信機に伝送されるシグナリング情報（ｓｉｇｎａｌｉｎｇ  ｉｎｆｏｒｍａｔｉｏｎ）と共に伝送されてもよい。前述したように、選好度クライテリアは、該当のサービス／コンテンツが既に保存されたＰＤＩユーザデータによってフィルタリング又は選別されるように活用されてもよい。これによって、ユーザの選好度に合うサービス／コンテンツ、すなわち、チャネル／プログラムを推奨することができる。
【１５３６】
ＥＳＧを提供するシステムは、チャネル或いはプログラムに関する情報を伝達することができる。一実施例として、ＥＳＧを提供するシステムにはＯＭＡ−ＢＣＡＳＴがある。ＥＳＧを提供するシステムは、チャネル或いはプログラム別にエンハンスメント情報（ｅｎｈａｎｃｅｍｅｎｔ  ｉｎｆｏｒｍａｔｉｏｎ）を提供するために、サービス／コンテンツ別に関連情報をＸＭＬ形態で伝達することができる。このチャネル或いはプログラムに関する情報のＸＭＬは拡張され、それぞれ、チャネル又はプログラムに対する選好度クライテリアをさらに含んで伝送することができる。
【１５３７】
それぞれ、チャネル又はプログラムに対して選好度がタグ付け（ｔａｇｇｉｎｇ）されて受信機に伝達されることにより、ユーザの好むサービス／コンテンツ、すなわち、チャネル／プログラムを選別することができる。
【１５３８】
図示のサービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーの拡張ダイヤグラムにおいて、ＸＭＬスキマーダイヤグラムは、該当のサービスに対するエンハンスメント情報、すなわち、デスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）、オーディオ言語（ＡｕｄｉｏＬａｎｇｕａｇｅ）などの情報を有することができる。これに加えて、ＸＭＬスキマーダイヤグラムは、該当のサービスに対する選好度をタグ付けした、選好度クライテリアをさらに含むことができる（ｔ１５６０１０）。この選好度クライテリアは、前述した選好度クライテリアを一実施例とすることができる。
【１５３９】
図１５７は、本発明の一実施例に係る、サービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーを示す図である。
【１５４０】
これは、前述した、サービスレベルで選好度クライテリアを伝送するためのＸＭＬスキマーダイヤグラムをＸＭＬドキュメントで示したものである。これは、一実施例に過ぎず、本発明はこの実施例に限定されない。前述した選好度クライテリアが、同様に、ＸＭＬの形態で含まれることが分かる（ｔ１５７０１０）。
【１５４１】
図１５８は、本発明の一実施例に係る、コンテンツレベルで選好度クライテリアを伝送するためのＸＭＬスキマーの拡張ダイヤグラムを示す図である。
【１５４２】
図示のＸＭＬスキマーダイヤグラムは、該当のコンテンツに対するエンハンスメント情報、すなわち、デスクリプション（ｄｅｓｃｒｉｐｔｉｏｎ）、オーディオ言語（ＡｕｄｉｏＬａｎｇｕａｇｅ）などの情報を有することができる。これに加えて、ＸＭＬスキマーダイヤグラムは、該当のコンテンツに対する選好度をタグ付けした、選好度クライテリアをさらに含むことができる（ｔ１５８０１０）。この選好度クライテリアは、前述した選好度クライテリアを一実施例とすることができる。
【１５４３】
図１５９は、本発明の一実施例に係る、コンテンツレベルで選好度クライテリアを伝送するためのＸＭＬスキマーを示す図である。
【１５４４】
これは、前述した、コンテンツレベルで選好度クライテリアを伝送するためのＸＭＬスキマーダイヤグラムを、ＸＭＬドキュメントで示したものである。これは一実施例に過ぎず、本発明は、この実施例に限定されない。前述した選好度クライテリアが同様にＸＭＬの形態で含まれることが分かる（ｔ１５９０１０）。
【１５４５】
図１６０は、本発明の一実施例に係る、ＥＳＧと共に伝達された選好度クライテリアを用いてユーザにサービス／コンテンツを推奨するシーケンスダイヤグラムを示す図である。
【１５４６】
ＥＳＧ関連データと共に伝達された選好度クライテリアと、ＰＤＩストアに保存されたＰＤＩユーザデータとを比較し、ＥＳＧのうち、ユーザが好むようなサービス／コンテンツを推奨することができる。ここで、ユーザは、既にＰＤＩ質問に対して答弁しており、これらのＰＤＩ答弁はＰＤＩストアに保存されている状態であることを仮定する。答弁を保存するシーケンスは省略されている。
【１５４７】
コンテンツプロバイダ又はブロードキャスタはＥＳＧエンジンにＥＳＧ情報を伝達することができる（ｔ１６００１０）。ここで、ＥＳＧエンジンは、ＥＳＧ関連データ処理をするモジュールであってもよい。ＥＳＧエンジンは、受信機の内部又は外部に位置してもよい。ＥＳＧエンジンが行う動作は、他のモジュールで処理されてもよい。ＥＳＧ情報は、ブロードキャスタチャネルで伝達されてもよく、モバイル又はブロードバンドチャネルで伝達されてもよい。実施例によって、ＥＳＧ情報は、他のチャネルで伝達されてもよい。
【１５４８】
ＥＳＧエンジンは、受け取ったＥＳＧ情報から選好度クライテリアをパースすることができる（ｔ１６００２０）。前述したように、選好度クライテリアは、ＥＳＧのＸＭＬ拡張の形態で伝達されてもよい。一実施例によれば、選好度クライテリアは、ＥＳＧと別個に伝送されてもよい。この場合、選好度クライテリアは、コンテンツプロバイダ又はブロードキャスタからＥＳＧエンジンに直接伝達されてもよい。ＥＳＧエンジンは、サービス／コンテンツ推奨に活用されるＰＤＩ質問を確認することができる。
【１５４９】
ＥＳＧエンジンは、ＰＤＩエンジンに特定質問に対する答弁を要求することができる（ｔ１６００３０）。ＥＳＧエンジンがパースした選好度クライテリアは、前述したように、複数個のクライテリオンを含むことができる。各クライテリオンに含まれるＰＤＩ質問の答弁がＰＤＩエンジンに要求されてもよい。このとき、要求は、ＰＤＩ質問のＩＤを用いて行われてもよい。
【１５５０】
ＰＤＩエンジンは、要求されたＰＤＩ答弁を、ＰＤＩストアから検索することができる（ｔ１６００４０）。同様に、ＰＤＩ質問のＩＤが活用されてもよい。ＰＤＩエンジンは、当該質問の答弁が存在する場合、ＰＤＩストアからその答弁に対する応答を受けることができる（ｔ１６００５０）。
【１５５１】
ＰＤＩエンジンは、検索した答弁をＥＳＧエンジンに伝達することができる（ｔ１６００６０）。ＥＳＧエンジンは、受け取ったＰＤＩ答弁又はＰＤＩユーザデータと、選好度クライテリオンとをそれぞれ比較することができる（ｔ１６００７０）。この選好度クライテリアは、コンテンツプロバイダ又はブロードキャスタがサービス／コンテンツ別にタグしておいたものであってもよい。ユーザが実際に作成した答弁と選好度クライテリアとを比較し、当該サービス／コンテンツが、ユーザが好むようなものであるか判断することができる。
【１５５２】
ＥＳＧエンジンは、比較の作業から、当該サービス／コンテンツがユーザの選好度に合うサービス／コンテンツであると判断されると、それをＵＩを介してユーザに露出することができる（ｔ１６００８０）。ユーザはＵＩを介してＥＳＧのうちの推奨サービス／コンテンツを受け取ることができる。
【１５５３】
図１６１は、本発明の他の実施例に係る、ＥＳＧと共に伝達された選好度クライテリアを用いてユーザにサービス／コンテンツを推奨するシーケンスダイヤグラムを示す図である。
【１５５４】
放送網による受信が不可能な環境で、モバイル又はブロードバンドチャネルでもＥＳＧ情報を直接受信できない場合であっても、ＥＳＧ情報を受けて、選好度クライテリアを用いたサービス／コンテンツ推奨を行うことができる。ここで、ユーザは、既にＰＤＩ質問に対して答弁しており、このＰＤＩ答弁はＰＤＩストアに保存された状態であると仮定する。答弁を保存するシーケンスは省略されている。
【１５５５】
この場合、まず、受信機は、ＥＳＧ情報を受信できる通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受けることができる（ｔ１６１０１０）。受信機は、ＥＳＧ情報伝達が可能か否かに対する通知を受けるために、関連したサービスを支援を受けていてもよい。受信機は、受け取った通知をパースし、ＥＳＧサーバーのＵＲＬを抽出することができる。これらの動作は受信機のＥＳＧエンジンで行うことができる。
【１５５６】
ＥＳＧエンジンは、ＥＳＧサーバーのＵＲＬを用いてＥＳＧサーバーに接近してＥＳＧ情報を要求することができる（ｔ１６１０１１）。ＥＳＧサーバーは、要求されたＥＳＧ情報をＥＳＧエンジンに伝達することができる。ここで、ＥＳＧサーバーは、ＥＳＧ情報だけを伝達する独立した役割を担うサーバーであってもよく、シグナリングのための各種の情報及びテーブルが保存されている統合シグナリングサーバーの役割を担うサーバーであってもよい。
【１５５７】
その後、受信機は、受け取ったＥＳＧ情報を用いて、選好度クライテリアを得て、これを用いてユーザの選好度と比較し、サービス／コンテンツを推奨することができる。これらの過程（ｔ１６１０２０〜ｔ１６１０８０）は、前述のとおりである。
【１５５８】
図１６２は、本発明の一実施例に係る、選好度クライテリアとＰＤＩユーザデータとを比較する方法を示す図である。
【１５５９】
前述したように、既に保存されたユーザの選好度情報と、選好度クライテリアを用いて、選好度に合うサービス／コンテンツを推奨することができる。
【１５６０】
選好度クライテリアの一実施例（ｔ１６２０１０）は、２個のＱＳＡクライテリオンと１個のＱＢＡクライテリオンを含むことができる。
【１５６１】
この実施例で、選好度クライテリアは、ユーザの年齢帯に関する情報を有するＱＳＡクライテリオンを含むことができる。この実施例で、ユーザの年齢帯に関する情報を有するＱＳＡクライテリオンが４の値を有するので、当該サービス／コンテンツは１８歳〜３４歳のユーザに向くコンテンツであることが分かる。
【１５６２】
同様に、この実施例に係る選好度クライテリアは、ユーザの性別に関する情報を有するＱＳＡクライテリオンを含むことができる。この実施例で、ユーザの性別に関する情報を有するＱＳＡクライテリオンが１の値を有するので、当該サービス／コンテンツは、男性がより一層好むコンテンツであることが分かる。
【１５６３】
また、この実施例に係る選好度クライテリアは、ユーザの職業有無に関する情報を有するＱＢＡクライテリオンを含むことができる。この実施例で、ユーザの職業の有無に関する情報を有するＱＢＡクライテリオンがＴＲＵＥの値を有するので、当該サービス／コンテンツは、職業を有するユーザがより一層好むコンテンツであることが分かる。
【１５６４】
ＰＤＩストアに保存されたＰＤＩユーザデータの一実施例（ｔ１６２０２０）は、それぞれ２個のＱＳＡタイプのＱ＆Ａと、１個のＱＢＡタイプのＱ＆Ａを含むことができる。
【１５６５】
この実施例で、ＰＤＩストアは、ユーザの年齢帯に関する情報を有するＰＤＩユーザデータ、すなわち、ユーザのＰＤＩ答弁を有することができる。この実施例で、ユーザは４と答えたため、ユーザは１８歳〜３４歳の年齢であることが分かる。
【１５６６】
また、この実施例で、ＰＤＩストアは、ユーザの性別に関する情報を有するＰＤＩユーザデータ、すなわち、ユーザのＰＤＩ答弁を有することができる。この実施例で、ユーザは２と答えたため、ユーザは女性であることが分かる。
【１５６７】
また、この実施例で、ＰＤＩストアは、ユーザの職業の有無に関する情報を有するＰＤＩユーザデータ、すなわち、ユーザのＰＤＩ答弁を有することができる。この実施例で、ユーザはＴＲＵＥと答えたため、ユーザは職業を有することが分かる。
【１５６８】
選好度クライテリアの実施例（ｔ１６２０１０）とＰＤＩストアに保存されたＰＤＩユーザデータの実施例（ｔ１６２０２０）とを比較すれば、年齢帯と職業の有無は一致するか、性別に関する情報がマッチされないことが分かる。このような比較・マッチング作業は、前述したように、選好度クライテリオンのＩＤにマッチされるＰＤＩ質問及びそれによるＰＤＩ答弁がある場合に行うことができる。実施例によって、該当のＰＤＩデータが保存されていない場合、ユーザに質疑することができる。
【１５６９】
ユーザにサービス／コンテンツを推奨するための基準を様々に設定することができる。
【１５７０】
例えば、選好度クライテリオンの値とＰＤＩ質問の答弁とが全て一致する場合、該当のサービス／コンテンツをユーザに推奨することができる。また、選好度クライテリオンの値とＰＤＩ質問の答弁が部分的に一致する場合、該当のサービス／コンテンツをユーザに推奨することができる。また、選好度クライテリオンの値とＰＤＩ質問の答弁が一致する項目が特定のパーセント以上である場合、該当のサービス／コンテンツをユーザに推奨することができる。また、選好度クライテリオンの値とＰＤＩ質問の答弁とが、あるレベル以上類似にマッチされる場合（例えば、年齢帯の値が２以下と異なる場合）に、該当のサービス／コンテンツをユーザに推奨することができる。また、ＰＤＩデータに異なる比重をおき、ある特定のＰＤＩデータが選好度クライテリオンの値と一致すると、他の項目が一致するか否かにかかわらずに推奨されるようにしてもよい。このような基準は、様々に設定することができ、上記に提示した内容を組み合わせて用いてもよい。
【１５７１】
全て一致する場合にのみサービス／コンテンツを推奨する場合、上記実施例（ｔ１６２０１０，ｔ１６２０２０）で、性別がマッチされないため、上記実施例のサービス／コンテンツを推奨することができない。一部のみ一致してもサービス／コンテンツを推奨する場合、上記実施例のサービス／コンテンツは性別が合わないにもかかわらず、推奨することができる。
【１５７２】
図１６３は、本発明の一実施例に係る、選好度クライテリアとＰＤＩユーザデータとを比較するためのマッチングバウンダリ（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ）フィールドを示す図である。
【１５７３】
前述したように、ユーザにサービス／コンテンツを推奨するための基準が様々に設定されてもよい。実施例によって、この基準は受信機でユーザによって設定され、受信機に保存されてもよい。他の実施例によれば、この基準は、サービスプロバイダ又はブロードキャスタによって選好度クライテリアに含まれて共に受信機に伝達されてもよい。
【１５７４】
ユーザにサービス／コンテンツを推奨するための基準が選好度クライテリアに含まれて受信機に伝達される場合、この基準に関連した情報はマッチングバウンダリフィールド（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ）によって伝送されてもよい（ｔ１６３０１０）。
【１５７５】
受信機は、マッチングバウンダリフィールドをパースした後、これによって、ユーザにサービス／コンテンツを推奨することができる。マッチングバウンダリフィールドが有する情報は様々な形態を有することができ、この情報は、前述した推奨基準に関する情報であってもよい。
【１５７６】
本発明の一実施例によれば、マッチングバウンダリフィールドは、特定の個数情報を有することができる。ユーザが設定した答弁とマッチされるクライテリオンの個数がマッチングバウンダリフィールドが示す特定の個数よりも多い場合、当該サービス／コンテンツをユーザに推奨することができる。これは、マッチングバウンダリフィールドの一実施例に過ぎず、マッチングバウンダリフィールドが受信機に推奨基準を伝達する方式は、実施例によって変更されてもよい。
【１５７７】
図１６４は、本発明の一実施例に係る、推奨されたサービス／コンテンツを提供するＵＩを示す図である。
【１５７８】
前述したように、ＰＤＩストアのＰＤＩユーザデータとＥＳＧの選好度クライテリアを用いて、サービス／コンテンツを選別することができる。ＥＳＧから選別されたサービス／コンテンツは、受信機のＵＩを介しててユーザに露出されてもよい。
【１５７９】
特定チャネル（例えば、チャネル７）が推奨される場合には、その特定チャネルがＥＳＧ内でハイライトで表示されてもよい（ｔ１６４０１０）。同様に、特定プログラム、コンテンツ（例えば、プログラムＡ、Ｆ）が推奨される場合には、その特定プログラムがＥＳＧ内でハイライトで表示されてもよい（ｔ１６４０２０）。
【１５８０】
実施例によって、推奨されるチャネル、プログラムは、ＥＳＧの推奨専用ページＵＩを介して、ユーザに露出されてもよい（ｔ１６４０３０）。この場合、ＥＳＧの推奨項目内で、推奨されるチャネル（例えば、チャネル７、１２、２４）、及び／又は推奨されるプログラム（例えば、プログラムＡ、Ｆ、Ｈ、Ｔ、Ｘ）がリステトされて表現されてもよい。
【１５８１】
ここで、チャネルはサービス、プログラムはコンテンツに対応してもよい。しかし、文脈によって、チャネル、サービス、プログラム、コンテンツなどの用語が混用されてもよい。
【１５８２】
実施例によって、本明細書で前述した状態変数ＰＤＩＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎは、ＵｓｅｒＤａｔａＰｒｏｔｏｃｏｌＶｅｒｓｉｏｎと呼ぶことができる。
【１５８３】
また、実施例によって、本明細書で前述した状態変数Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＩｄｓＬｉｓｔは、ＵｓｅｒＤａｔａＩｄｓＬｉｓｔと呼ぶことができる。
【１５８４】
また、実施例によって、本明細書で前述した状態変数ＵｓｅｒＤａｔａＬｉｓｔは、ＵｓｅｒＤａｔａと呼ぶことができる。
【１５８５】
また、実施例によって、本明細書で前述した状態変数Ａ＿ＡＲＧ＿ＴＹＰＥ＿ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔは、ＵｓｅｒＤａｔａＱＡＩｄｓＬｉｓｔと呼ぶことができる。
【１５８６】
また、実施例によって、本明細書で前述した状態変数ＵｓｅｒＤａｔａＱＡＬｉｓｔは、ＵｓｅｒＤａｔａＱＡと呼ぶことができる。
【１５８７】
図１６５は、本発明の一実施例に係る、インタラクティブサービス又はコンテンツを提供する方法を示す図である。
【１５８８】
本発明の一実施例に係るインタラクティブサービス又はコンテンツを提供する方法は、ＥＳＧ情報を受信する段階（ｓｔ１６５０１０）、ＰＤＩテーブルを受信する段階（ｓｔ１６５０２０）、少なくとも一つのＰＤＩ質問に対する答弁を取得する段階（ｓｔ１６５０３０）、上記取得された答弁を保存する段階（ｓｔ１６５０４０）、推奨インタラクティブサービス又はコンテンツを決定する段階（ｓｔ１６５０５０）、及び／又は上記決定された推奨インタラクティブサービス又はコンテンツをＥＳＧに表現する段階（ｓｔ１６５０６０）を含むことができる。
【１５８９】
ｓｔ１６５０１０段階で、上述したＥＳＧエンジンの第１受信モジュールは、ユーザの個人関心事に基づいてユーザにインタラクティブサービス又はコンテンツを推奨するための上記インタラクティブサービス又はコンテンツの特性を示す選好クライテリア（ｐｒｅｆｅｒｅｎｃｅ  ｃｒｉｔｅｒｉａ）を含むＥＳＧ（Ｅｎｈａｎｃｅｍｅｎｔ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）情報を受信することができる。ＥＳＧエンジンは第１受信モジュールを含むことができ、ＥＳＧエンジン及び第１受信モジュールはハードウェアに該当してもよい。そして、第１受信モジュールはＥＳＧエンジン又は上述した受信機内で処理されてもよい。
【１５９０】
ｓｔ１６５０２０段階で、上述したＰＤＩエンジンの第２受信モジュールは、放送信号を通じてＰＤＩ（Ｐｒｏｆｉｌｅｓ、Ｄｅｍｏｇｒａｐｈｉｃｓ、Ｉｎｔｅｒｅｓｔｓ）テーブルを受信することができる。ここで、上記ＰＤＩテーブルは、インタラクティブコンテンツのためのユーザの個人関心事に関連した複数のＰＤＩ質問を含み、ここで、上記複数のＰＤＩ質問のそれぞれは、上記複数のＰＤＩ質問のそれぞれを識別する質問識別子を含むことができる。ＰＤＩエンジンは第２受信モジュールを含むことができ、ＰＤＩエンジン及び第２受信モジュールはハードウェアに該当してもよい。そして、第２受信モジュールはＰＤＩエンジン又は上述した受信機内で処理されてもよい。
【１５９１】
ｓｔ１６５０３０段階で、上述したＰＤＩエンジンの取得モジュールは、複数のＰＤＩ質問のうち少なくとも一つに対する答弁を取得することができる。ＰＤＩエンジンは取得モジュールを含むことができ、ＰＤＩエンジン及び取得モジュールはハードウェアに該当してもよい。そして、取得モジュールは、ＰＤＩエンジン又は上述した受信機内で処理されてもよい。
【１５９２】
ｓｔ１６５０４０段階で、ＰＤＩエンジンの保存モジュールは、上記取得された答弁を上記ＰＤＩテーブルに保存することができる。ＰＤＩエンジンは保存モジュールを含むことができ、ＰＤＩエンジン及び保存モジュールはハードウェアに該当してもよい。そして、保存モジュールは、ＰＤＩエンジン又は上述した受信機内で処理されてもよい。
【１５９３】
ｓｔ１６５０５０段階で、ＥＳＧエンジンの決定モジュールは、上記選好クライテリアと上記取得された答弁とを比較し、推奨インタラクティブサービス又はコンテンツを決定することができる。ＥＳＧエンジンは決定モジュールを含むことができ、ＥＳＧエンジン及び決定モジュールはハードウェアに該当してもよい。そして、決定モジュールは、ＥＳＧエンジン又は上述した受信機内で処理されてもよい。
【１５９４】
ｓｔ１６５０６０段階で、ディスプレイプロセッサ又はスクリーンの表現モジュールは、上記決定された推奨インタラクティブサービス又はコンテンツをＥＳＧで表現することができる。ディスプレイプロセッサ又はスクリーンは表現モジュールを含むことができ、ディスプレイプロセッサ、スクリーン及び表現モジュールは、ハードウェアに該当してもよい。そして、表現モジュールは、ディスプレイプロセッサ、スクリーン又は上述した受信機内で処理されてもよい。
【１５９５】
本発明の他の実施例によれば、上記選好クライテリアと上記取得された答弁とを比較して推奨インタラクティブサービス又はコンテンツを決定する段階は、上記ＥＳＧ情報から上記選好クライテリアをパースする段階、上記クライテリオン識別子及び上記質問識別子を用いて、上記ＰＤＩテーブルからＰＤＩ質問に対する答弁を持ってくる段階、及び／又は上記持ってきた答弁と上記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定する段階を含むことができる。ＥＳＧエンジンは、選好クライテリアをＥＳＧ情報からパースすることができ、ここで、上記選好クライテリアは複数のクライテリオン（ｃｒｉｔｅｒｉｏｎ）を含むことができ、ここで、上記複数のクライテリオンのそれぞれは、上記複数のクライテリオンをそれぞれ識別するクライテリオン識別子を有するクライテリオン質問及び上記クライテリオン質問に対する答弁を示すクライテリオン値を含むことができる。ＥＳＧエンジンは、上記クライテリオン識別子及び上記質問識別子を用いて、上記ＰＤＩテーブルからＰＤＩ質問に対する答弁を持ってくることができる。ここで、持ってきた答弁に対する上記ＰＤＩ質問は、上記クライテリオン質問とマッチされてもよい。ＥＳＧエンジンは、上記持ってきた答弁と上記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定することができる。
【１５９６】
本発明の他の実施例によれば、上記選好クライテリアは、インタラクティブサービス又はコンテンツが推奨されるか否かを決定するためのバウンダリ（ｂｏｕｎｄａｒｙ）を示すマッチングバウンダリ情報（ｍａｔｃｈｉｎｇ  ｂｏｕｎｄａｒｙ  ｉｎｆｏｒｍａｔｉｏｎ）を含むことができる。上記持ってきた答弁と上記クライテリオン値とを比較して推奨インタラクティブサービス又はコンテンツを決定する段階は、上記持ってきた答弁とマッチされるクライテリオンの個数を計算する段階、及び／又は上記持ってきた答弁とマッチされるクライテリオンの個数が、上記マッチングバウンダリ情報が示す個数よりも大きいと、推奨インタラクティブサービス又はコンテンツを決定する段階を含むことができる。
【１５９７】
本発明の他の実施例によれば、ＥＳＧエンジンの通知受信モジュールは、受信機がＥＳＧ情報受信を支援することを示す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）を受信することができる。ここで、上記通知は、ＥＳＧサーバーのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を含むことができる。ＥＳＧエンジンのリクエスティングモジュールは、上記ＥＳＧサーバーに上記ＥＳＧ情報をリクエストすることができる。ＥＳＧエンジンは、通知受信モジュール及びリクエスティングモジュールを含むことができる。ＥＳＧエンジン、通知受信モジュール及びリクエスティングモジュールは、ハードウェアであってもよい。通知受信モジュール及び／又はリクエスティングモジュールは、ＥＳＧエンジン又は受信機内で処理されてもよい。
【１５９８】
本発明の他の実施例によれば、上記選好クライテリアは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）スキマー（ｓｃｈｅｍａ）又はデスクリプタタイプを有することができる。
【１５９９】
本発明の他の実施例によれば、上記インタラクティブサービス又はコンテンツ提供方法は、受信機を用いるユーザを識別するユーザ識別子を取得する段階、上記ユーザ識別子を用いてユーザを識別する段階、及び／又は上記ＰＤＩテーブルに上記ユーザ識別子を保存する段階を含むことができる。ＰＤＩエンジンのユーザ識別子取得モジュールは、ユーザ識別子を取得することができる。ＰＤＩエンジンの識別モジュールは、ユーザを識別することができる。保存モジュールは、ユーザ識別子をＰＤＩテーブルに保存することができる。取得モジュールは、上記複数のＰＤＩ質問のうち少なくとも一つに対する答弁を、上記ユーザ識別子に基づいて取得することができる。保存モジュールは、上記取得された答弁を上記ユーザ識別子に基づいて上記ＰＤＩテーブルに保存することができる。ＰＤＩエンジンは、ユーザ識別子取得モジュール及び識別モジュールを含むことができる。ＰＤＩエンジン、ユーザ識別子取得モジュール及び識別モジュールは、ハードウェアであってもよい。ユーザ識別子取得モジュール及び／又は識別モジュールは、ＰＤＩエンジン又は受信機内で処理されてもよい。
【１６００】
本発明の他の実施例によれば、上記インタラクティブサービス又はコンテンツ提供方法は、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信する段階、上記付加選好情報によってＰＤＩ質問を生成する段階、及び／又は上記ＰＤＩテーブルに上記生成されたＰＤＩ質問を追加する段階を含むことができる。ＰＤＩエンジンの第３受信モジュールは、クローズドキャプション（ｃｌｏｓｅｄ  ｃａｐｔｉｏｎ）、オーディオ及びサイン言語（ｓｉｇｎ  ｌａｎｇｕａｇｅ）に対する選好を含む付加選好情報を受信することができる。ＰＤＩエンジンの生成モジュールは、上記付加選好情報によってＰＤＩ質問を生成することができる。追加モジュールは上記ＰＤＩテーブルに、上記生成されたＰＤＩ質問を追加することができる。ＰＤＩエンジンは、第３受信モジュール、生成モジュール及び／又は追加モジュールを含むことができる。ＰＤＩエンジン、第３受信モジュール、生成モジュール及び／又は追加モジュールは、ハードウェアであってもよい。第３受信モジュール、生成モジュール及び／又は追加モジュールは、ＰＤＩエンジン又は受信機内で処理されてもよい。
【１６０１】
本発明の他の実施例によれば、上記付加選好情報は、クローズドキャプション言語の選好されるタイプに関する情報、視覚障害者のためのオーディオモードに関する情報、及びサイン言語の選好されるタイプに関する情報を含むことができる。
【１６０２】
上述した段階は、設計によって省略されてもよく、類似又は同一の機能を果たす段階に代替されてもよい。
【１６０３】
本発明の説明は、明瞭化のために、添付の各図面を参照して説明してきたが、添付の図面に示す実施例を併合することによって新しい実施例を設計することも可能である。上記の説明で言及された実施例を実行するプログラムが記録されたコンピュータ読み取り可能記録媒体が当業者の必要によって設計されると、これも、添付した特許請求の範囲及びその同等範囲に属するといえる。
【１６０４】
本発明に係る装置及び方法は、上記の説明で言及された実施例の構成及び方法に制限されない。上記の説明で言及された実施例は、全体的に又は部分的に互いに選択的に結合される方式によって様々に変形して構成することも可能である。
【１６０５】
また、本発明に係る方法は、ネットワーク装置に提供されるプロセッサ読み取り可能記録媒体でプロセッサ読み取り可能コードによって具現することができる。プロセッサ読み取り可能媒体は、プロセッサで読み取り可能なデータを格納できるいずれの種類の記録装置をも含むことができる。プロセッサ読み取り可能記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピーディスク、光データ記憶装置などがあり、また、インターネットを介した伝送などのようなキャリアウェーブの形態で具現されるものも含む。また、プロセッサ読み取り可能記録媒体は、ネットワークを介して接続したコンピュータシステムに分散されて、分散方式でプロセッサ読み取り可能コードが保存され、実行されてもよい。
【１６０６】
当業者にとって、本発明の思想及び範囲から逸脱しない限度内で本発明の様々な変形及び変更が可能であることは明らかである。したがって、本発明は、添付する特許請求の範囲及びその同等範囲内で提供される本発明の変形及び変更をカバーする。
【１６０７】
装置及び方法の発明が本明細書に言及されており、それらの装置及び方法の発明に関する説明は、相互補完的に適用されてもよい。
〔実施例〕
【１６０８】
様々な実施例を、本発明を実施するための形態で記載した。
【産業上の利用可能性】
【１６０９】
本発明は、放送信号提供フィールドで有用である。
【１６１０】
本発明の思想又は範囲から逸脱することなく本発明の様々な変形及び変更が可能であることが当業者には自明である。したがって、本発明は、添付する特許請求の範囲及びその同等範囲内で提供される本発明のいずれの変形及び変更もカバーするものとして意図される。
【図１】
0006348184.tif 000057
【図２】
0006348184.tif 000058
【図３】
0006348184.tif 000059
【図４】
0006348184.tif 000060
【図５】
0006348184.tif 000061
【図６】
0006348184.tif 000062
【図７】
0006348184.tif 000063
【図８】
0006348184.tif 000064
【図９】
0006348184.tif 000065
【図１０】
0006348184.tif 000066
【図１１】
0006348184.tif 000067
【図１２】
0006348184.tif 000068
【図１３】
0006348184.tif 000069
【図１４】
0006348184.tif 000070
【図１５】
0006348184.tif 000071
【図１６】
0006348184.tif 000072
【図１７】
0006348184.tif 000073
【図１８】
0006348184.tif 000074
【図１９】
0006348184.tif 000075
【図２０】
0006348184.tif 000076
【図２１】
0006348184.tif 000077
【図２２】
0006348184.tif 000078
【図２３】
0006348184.tif 000079
【図２４】
0006348184.tif 000080
【図２５】
0006348184.tif 000081
【図２６】
0006348184.tif 000082
【図２７】
0006348184.tif 000083
【図２８】
0006348184.tif 000084
【図２９】
0006348184.tif 000085
【図３０】
0006348184.tif 000086
【図３１】
0006348184.tif 000087
【図３２】
0006348184.tif 000088
【図３３】
0006348184.tif 000089
【図３４】
0006348184.tif 000090
【図３５】
0006348184.tif 000091
【図３６】
0006348184.tif 000092
【図３７】
0006348184.tif 000093
【図３８】
0006348184.tif 000094
【図３９】
0006348184.tif 000095
【図４０】
0006348184.tif 000096
【図４１】
0006348184.tif 000097
【図４２】
0006348184.tif 000098
【図４３】
0006348184.tif 000099
【図４４】
0006348184.tif 000100
【図４５】
0006348184.tif 000101
【図４６】
0006348184.tif 000102
【図４７】
0006348184.tif 000103
【図４８】
0006348184.tif 000104
【図４９】
0006348184.tif 000105
【図５０】
0006348184.tif 000106
【図５１】
0006348184.tif 000107
【図５２】
0006348184.tif 000108
【図５３】
0006348184.tif 000109
【図５４】
0006348184.tif 000110
【図５５】
0006348184.tif 000111
【図５６】
0006348184.tif 000112
【図５７】
0006348184.tif 000113
【図５８】
0006348184.tif 000114
【図５９】
0006348184.tif 000115
【図６０】
0006348184.tif 000116
【図６１】
0006348184.tif 000117
【図６２】
0006348184.tif 000118
【図６３】
0006348184.tif 000119
【図６４】
0006348184.tif 000120
【図６５】
0006348184.tif 000121
【図６６】
0006348184.tif 000122
【図６７】
0006348184.tif 000123
【図６８】
0006348184.tif 000124
【図６９】
0006348184.tif 000125
【図７０】
0006348184.tif 000126
【図７１】
0006348184.tif 000127
【図７２】
0006348184.tif 000128
【図７３】
0006348184.tif 000129
【図７４】
0006348184.tif 000130
【図７５】
0006348184.tif 000131
【図７６】
0006348184.tif 000132
【図７７】
0006348184.tif 000133
【図７８】
0006348184.tif 000134
【図７９】
0006348184.tif 000135
【図８０】
0006348184.tif 000136
【図８１】
0006348184.tif 000137
【図８２】
0006348184.tif 000138
【図８３】
0006348184.tif 000139
【図８４】
0006348184.tif 000140
【図８５】
0006348184.tif 000141
【図８６】
0006348184.tif 000142
【図８７】
0006348184.tif 000143
【図８８】
0006348184.tif 000144
【図８９】
0006348184.tif 000145
【図９０】
0006348184.tif 000146
【図９１】
0006348184.tif 000147
【図９２】
0006348184.tif 000148
【図９３】
0006348184.tif 000149
【図９４】
0006348184.tif 000150
【図９５】
0006348184.tif 000151
【図９６】
0006348184.tif 000152
【図９７】
0006348184.tif 000153
【図９８】
0006348184.tif 000154
【図９９】
0006348184.tif 000155
【図１００】
0006348184.tif 000156
【図１０１】
0006348184.tif 000157
【図１０２】
0006348184.tif 000158
【図１０３】
0006348184.tif 000159
【図１０４】
0006348184.tif 000160
【図１０５】
0006348184.tif 000161
【図１０６】
0006348184.tif 000162
【図１０７】
0006348184.tif 000163
【図１０８】
0006348184.tif 000164
【図１０９】
0006348184.tif 000165
【図１１０】
0006348184.tif 000166
【図１１１】
0006348184.tif 000167
【図１１２】
0006348184.tif 000168
【図１１３】
0006348184.tif 000169
【図１１４】
0006348184.tif 000170
【図１１５】
0006348184.tif 000171
【図１１６】
0006348184.tif 000172
【図１１７】
0006348184.tif 000173
【図１１８】
0006348184.tif 000174
【図１１９】
0006348184.tif 000175
【図１２０】
0006348184.tif 000176
【図１２１】
0006348184.tif 000177
【図１２２】
0006348184.tif 000178
【図１２３】
0006348184.tif 000179
【図１２４】
0006348184.tif 000180
【図１２５】
0006348184.tif 000181
【図１２６】
0006348184.tif 000182
【図１２７】
0006348184.tif 000183
【図１２８】
0006348184.tif 000184
【図１２９】
0006348184.tif 000185
【図１３０】
0006348184.tif 000186
【図１３１】
0006348184.tif 000187
【図１３２】
0006348184.tif 000188
【図１３３】
0006348184.tif 000189
【図１３４】
0006348184.tif 000190
【図１３５】
0006348184.tif 000191
【図１３６】
0006348184.tif 000192
【図１３７】
0006348184.tif 000193
【図１３８】
0006348184.tif 000194
【図１３９】
0006348184.tif 000195
【図１４０】
0006348184.tif 000196
【図１４１】
0006348184.tif 000197
【図１４２】
0006348184.tif 000198
【図１４３】
0006348184.tif 000199
【図１４４】
0006348184.tif 000200
【図１４５】
0006348184.tif 000201
【図１４６】
0006348184.tif 000202
【図１４７】
0006348184.tif 000203
【図１４８】
0006348184.tif 000204
【図１４９】
0006348184.tif 000205
【図１５０】
0006348184.tif 000206
【図１５１】
0006348184.tif 000207
【図１５２】
0006348184.tif 000208
【図１５３】
0006348184.tif 000209
【図１５４】
0006348184.tif 000210
【図１５５】
0006348184.tif 000211
【図１５６】
0006348184.tif 000212
【図１５７】
0006348184.tif 000213
【図１５８】
0006348184.tif 000214
【図１５９】
0006348184.tif 000215
【図１６０】
0006348184.tif 000216
【図１６１】
0006348184.tif 000217
【図１６２】
0006348184.tif 000218
【図１６３】
0006348184.tif 000219
【図１６４】
0006348184.tif 000220
【図１６５】
0006348184.tif 000221