JP2007104654A - コンテンツロケーション解決方法及びコンテンツ配信方法 - Google Patents

Abstract

【課題】本発明は、双方向通信を実現する形でコンテンツを放送する場合に、高いセキュリティを実現しつつ、ユーザに対して適切なコンテンツを提供できるようにするとともに、コンテンツの差し替えや変更にも対処できるようにする技術の提供を目的とする。
【解決手段】双方向通信を実現する形でコンテンツを放送する場合に、ハイパーリンクを実現するにあたって、放送するコンテンツに、それからリンクするコンテンツのコンテンツ参照ＩＤを埋め込んで放送する。そして、コンテンツ参照ＩＤを指定してコンテンツの視聴要求がある場合に、ＲＡＲサーバで、そのコンテンツのロケーションの解決を行うＬＲサーバを特定し、その特定したＬＲサーバで、視聴要求で指定されたコンテンツ参照ＩＤを対応するロケーションに変換して、その変換したロケーションの指すコンテンツサーバから視聴要求元装置に対してコンテンツを配信するようにする。
【選択図】図１

Description

本発明は、コンテンツを放送するシステムで用いられるコンテンツのロケーション解決方法及び配信方法に関し、特に、高いセキュリティを実現しつつ、ユーザに対して時刻やユーザの位置やユーザの興味に応じた適切なコンテンツを提供できるようにするとともに、コンテンツの急な差し替えや変更にも対処できるようにするコンテンツのロケーション解決方法及び配信方法に関する。

現在、ＡＲＩＢ（社団法人電波産業会）の地上デジタル放送双方向通信の仕様においては、ＨＴＴＰが採用されることになっている。それに伴い、データ放送から直接インターネット上のＷＥＢサイトにアクセスが可能となることから、セキュリティ上に問題がでることで、番組やＣＭの双方向サービスの管理が不可能となる恐れがある。

また、アクセスするためのＵＲＬも判別できてしまうので、直接そのＵＲＬを使用してアクセスしたり、悪意を持ってＷＥＢサイトを攻撃するという事態が考えられる。特に、放送という媒体の関係上、大量なアクセスが考えられることから、ＷＥＢサイトへの攻撃を防止しなければいけないという課題が顕在する。

以上のような観点から、番組を管理する放送局としては、インターネット、携帯網を使用した双方向サービスにおいて、ある程度のセキュリティを有し、双方向データの管理ができるコンテンツ技術の確立が課題となっている。しかも、その技術はＡＲＩＢとして取り込み可能な技術である必要もある。

一方、ＡＲＩＢとして取り込み可能な技術として、ＴＶ−Ａnytimeで採用されているＣＲＩＤ（コンテンツ参照ＩＤ：Content Reference Identifier）がある。

このＣＲＩＤの技術は蓄積型サービスのメタデータ、コンテンツ管理を目的とする技術であり、ＴＶ−Ａnytimeでは、メタデータを使ってコンテンツを検索することでそのコンテンツを特定するためのＣＲＩＤを取得するようにして、そのＣＲＩＤを使ってコンテンツのロケーション（コンテンツの実際の所在）を得ることで、ユーザが自分の見たいコンテンツを視聴できるようにしている（例えば、非特許文献１参照）。
新しいコンテンツ視聴環境を実現するＴＶ−Ａnytime〔平成17年７月20日検索〕、インターネット＜ＵＲＬ： http://www.jagat.or.jp/VEHICLE/TITLE/188kameyama.asp ＞

上述したように、ＡＲＩＢの地上デジタル放送双方向通信の仕様においては、ＨＴＴＰが採用されることになっており、リンク先もＵＲＬを使って記述されることになる。しかしながら、リンク先がＵＲＬを使って記述されていると、そのＵＲＬの書き替えによるコンテンツの改ざんが行われたり、直接そのＵＲＬを使用してアクセスしたり、悪意を持ってＷＥＢサイトを攻撃することが起こるという問題がある。

しかも、リンク先がＵＲＬを使って記述されていると、そのＵＲＬの指す固定的なコンテンツしか表示できないことから、ユーザに対して時刻やユーザの位置やユーザの興味に応じた適切なコンテンツを提供できないという問題もある。

これから、地上デジタル放送双方向通信を実用的なものとするためには、このような問題の解決を図る新たな技術を構築していく必要がある。

一方、この新たな技術の構築にあたっては、リンク先のコンテンツの急な差し替えや変更に対処できるようにしていく必要がある。

今後実用化されることになる携帯端末向けの地上デジタル放送双方向通信では、放送と通信の画面を携帯端末で一体的に表示したり、一方だけを表示できるようにして、例えば、放送の画面である商品のＣＭを流しているときに、通信の画面でその商品の説明を行うようにするというようなことが行われることになる。このとき、通信の画面に、その商品の詳細な説明の表示を要求するボタンを表示するようにして、ユーザがそのボタンを操作すると、通信の画面だけを表示するようにして、そこに、その商品の詳細な説明を表示するというような処理を行うことが考えられる。

このような形でＣＭの表示を行う場合、ＣＭの性格上、ＣＭの内容の一部が急に変更されたり、ＣＭの内容が全面的に急に差し替えられることがある。

これから、上述した新たな技術の構築にあたっては、このようなことを考慮して、リンク先のコンテンツの急な差し替えや変更に対処できるようにしていく必要がある。

さらに、ＣＭを放送する場合、放送したＣＭの効果に応じた広告料を広告主から徴収することが合理的である。しかるに、リンク先がＵＲＬを使って記述されていると、ユーザがリンクするＣＭを直接視聴することになるので、放送者側としてはユーザがＣＭに関心を持ったのか否かを知ることができない。

これから、リンク先をＵＲＬを使って記述するという従来技術に従っていると、放送したＣＭの効果に応じた広告料を広告主から徴収するというようなビジネスモデルを構築できないことになる。

本発明はかかる事情に鑑みてなされたものであって、デジタル放送双方向通信のような双方向通信を実現する形でコンテンツを放送する場合に、高いセキュリティを実現しつつ、ユーザに対して時刻やユーザの位置やユーザの興味に応じた適切なコンテンツを提供できるようにするとともに、コンテンツの急な差し替えや変更にも対処できるようにし、これに加えて、ＣＭの広告効果などについても測定可能にする新たなコンテンツ技術の提供を目的とする。

この目的を達成するために、本発明では、ＴＶ−Ａnytimeで採用されているＣＲＩＤ（コンテンツ参照ＩＤ）を活用して、
（ｉ）インターネット放送やデジタル放送などのような放送において、ＥＰＧ（電子番 組案内）などのようなコンテンツの一覧を放送する場合に、そのコンテンツ一覧 に、それらのコンテンツに対応付けられるコンテンツ参照ＩＤを埋め込んで放送 したり、
（ii）インターネット放送やデジタル放送などのような放送において、ハイパーリンク を実現するにあたって、放送するコンテンツに、それからリンクするコンテンツ のコンテンツ参照ＩＤを埋め込んで放送する
という構成を採る。

〔１〕上述の（ｉ）の構成を採る場合の本発明の構成
上述の（ｉ）の構成を採る場合には、本発明のコンテンツロケーション解決方法は、（１）コンテンツの一覧を放送する場合に、そのコンテンツ一覧に、それらのコンテンツに対応付けられるコンテンツ参照ＩＤを埋め込んで放送する過程と、（２）そのコンテンツ一覧の中から選択されたコンテンツを指定して、コンテンツのロケーションの解決要求がある場合に、その解決要求を受け付ける受付サーバで、そのコンテンツのロケーションの解決を行う解決サーバを特定する過程と、（３）その特定した解決サーバで、解決要求で指定されたコンテンツに対応付けられるコンテンツ参照ＩＤを対応するロケーションに変換する過程と、（４）その変換したロケーションを解決要求元の装置に通知する過程とを備えるように構成する。

この構成を採るときにあって、解決サーバが上位サーバと複数の下位サーバとで階層的に構成されることがあり、この場合には、変換する過程では、上位サーバで、解決要求で指定されたコンテンツに対応付けられるコンテンツ参照ＩＤに基づいて、どの下位サーバを用いるのかを特定して、その特定した下位サーバで、そのコンテンツ参照ＩＤを対応するロケーションに変換するように処理することになる。

また、受付サーバで受け付けたコンテンツ参照ＩＤのログデータを集計分析したり、解決サーバで変換したコンテンツ参照ＩＤのログデータを集計分析する過程を備えることがある。

〔２〕上述の（ii）の構成を採る場合の本発明の構成
上述の（ii）の構成を採る場合には、本発明のコンテンツ配信方法は、（１）放送するコンテンツに、それからリンクするコンテンツのコンテンツ参照ＩＤを埋め込んで放送する過程と、（２）コンテンツ参照ＩＤを指定して、コンテンツの視聴要求がある場合に、その視聴要求を受け付ける受付サーバで、そのコンテンツのロケーションの解決を行う解決サーバを特定する過程と、（３）その特定した解決サーバで、視聴要求で指定されたコンテンツ参照ＩＤを対応するロケーションに変換する過程と、（４）その変換したロケーションの指すコンテンツサーバから、視聴要求元の装置に対してコンテンツを配信する過程とを備えるように構成する。

この構成を採るときにあって、解決サーバが上位サーバと複数の下位サーバとで階層的に構成されることがあり、この場合には、変換する過程では、上位サーバで、視聴要求で指定されたコンテンツ参照ＩＤに基づいて、どの下位サーバを用いるのかを特定して、その特定した下位サーバで、そのコンテンツ参照ＩＤを対応するロケーションに変換するように処理することになる。

また、放送する過程では、少なくとも放送局のＩＤと送出時刻とについて記述するコンテンツ参照ＩＤを埋め込んで放送したり、少なくとも放送局のＩＤと送出時刻の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送したり、少なくとも放送局のＩＤと視聴要求元装置の位置情報（経緯度情報など）の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送したり、少なくとも放送局のＩＤと視聴要求元装置のユーザ情報（年齢や性別などのユーザの属性情報や、視聴要求元装置で行ったユーザの行動履歴の情報など）の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送することがある。

ここで、コンテンツ参照ＩＤに位置情報やユーザ情報の取得指示が記述されている場合には、視聴要求元装置は、コンテンツ参照ＩＤを指定してコンテンツの視聴要求を発行する際などに、その取得指示に従って、搭載するＧＰＳなどにより検出される位置情報やメモリに記録されるユーザ情報に従って該当する情報を取得して、それをコンテンツ参照ＩＤに記入するように処理することになる。なお、ユーザ情報については、受付サーバで取得して、受付サーバがそれをコンテンツ参照ＩＤに記入するように処理してもよい。

また、コンテンツ参照ＩＤに送出時刻の取得指示が記述されている場合には、視聴要求元装置は、コンテンツの放送を受信する際などに、その取得指示に従って、時計により検出される送出時刻情報を取得して、それをコンテンツ参照ＩＤに記入するように処理することになる。

さらに、受付サーバで受け付けたコンテンツ参照ＩＤのログデータを集計分析したり、解決サーバで変換したコンテンツ参照ＩＤのログデータを集計分析する過程を備えることがある。

〔３〕本発明の構成の特徴とそれにより実現される特有の効果
このように、本発明では、デジタル放送双方向通信のような双方向通信を実現する形でコンテンツを放送する場合に、ＵＲＬを使ってリンク先を記述するのではなくて、
ＣＲＩＤ：／／＜ａｕｔｈｏｒｉｔｙ＞／＜ｄａｔａ＞
ただし、＜ａｕｔｈｏｒｉｔｙ＞は、＜ＤＮＳ ｎａｍｅ＞；＜ｐａｔｈ＞
という記述形式のコンテンツ参照ＩＤを使って、リンク先を記述するということを基本的な構成とする。

すなわち、これまでコンテンツ参照ＩＤは蓄積型サービスのメタデータ、コンテンツ管理を目的とする技術で用いられていたのに対して、本発明では、コンテンツ参照ＩＤを双方向通信に応用していることに大きな特徴がある。

このように、コンテンツ参照ＩＤを使ってリンク先を記述するという構成を採ると、ユーザに対して実コンテンツの存在するコンテンツサーバのＵＲＬを隠蔽することができることになり、しかも、コンテンツ参照ＩＤが放送局ＩＤや送出時刻などのような直接コンテンツサーバに関わらないデータから生成できるという性質があることから、高いセキュリティを実現できるようになる。

そして、コンテンツ参照ＩＤに時刻情報や位置情報やユーザ情報を記述し、その記述内容に応じて配信するコンテンツを切り替えるようにするという構成を採ることが可能になるので、ユーザに対して時刻やユーザの位置やユーザの興味に応じた適切なコンテンツを提供できるようになる。

そして、コンテンツ参照ＩＤを使うことにより、リンク先としてのコンテンツという概念とその物理的所在とを明確に区別することができることで、リンク先のコンテンツを書き替えたり差し替えることができるようになるので、コンテンツの急な差し替えや変更にも簡単に対処できるようになる。

そして、コンテンツ参照ＩＤからそのコンテンツ参照ＩＤの指すコンテンツのロケーションを解決する機構を備えるという構成を採ることが可能になるので、コンテンツの視聴記録のログデータを収集できるようになり、これにより、例えば、放送したＣＭの効果に応じた広告料を広告主から徴収するというような新たなビジネスモデルを構築できるようになる。

以上に説明したように、本発明によれば、デジタル放送双方向通信のような双方向通信を実現する形でコンテンツを放送する場合に、高いセキュリティを実現しつつ、ユーザに対して時刻やユーザの位置やユーザの興味に応じた適切なコンテンツを提供できるようになるとともに、コンテンツの急な差し替えや変更にも対処できるようになり、これに加えて、ＣＭの広告効果などについても測定することができるようになる。

しかも、本発明によれば、ＡＲＩＢとして取り込み可能な技術を使って、これを実現できるようになる。

これから、本発明によれば、デジタル放送双方向通信のような双方向通信を実現する形でコンテンツを放送するシステムの実用性を高めることができるようになる。

以下、デジタル放送双方向通信システムに適用した実施の形態に従って本発明を詳細に説明する。

図１に、本発明を具備するデジタル放送双方向通信システムのシステム構成を図示する。

この図に示すように、本発明を具備するデジタル放送双方向通信システムは、放送局１と、携帯端末２と、コンテンツサーバ３と、ＬＲシステム(Location Resolutionシステム) ４と、ＲＡＲシステム（Resolving Authority Recordシステム）５と、インターネット６とを備える。

この放送局１は、（１）放送局ＩＤ（コンテンツ参照ＩＤの持つ“authority ”のＤＮＳネーム部分となるもの）、送出時刻、番組ＩＤ、ＣＭＩＤなどからコンテンツ参照ＩＤを生成して、それを番組やＣＭなどのコンテンツに埋め込むという処理を行うＣＲＩＤ生成システム１０と、（２）カルーセル、ＰＥＳによるデータ放送伝送方式により、コンテンツ参照ＩＤの埋め込まれた番組やＣＭなどのコンテンツをデジタル放送するという処理を行う送出システム１１とを備えることで、コンテンツ参照ＩＤの埋め込まれたコンテンツをデジタル放送する。

携帯端末２は、携帯網を介して放送されてくる放送局１のデジタル放送を受信して、それを視聴する。

コンテンツサーバ３は、実コンテンツを蓄積するコンテンツデータベース３０を備えて、ユーザの要求するコンテンツを携帯端末２に配信する。

ＬＲシステム４は、（１）コンテンツ参照ＩＤをコンテンツのロケーションに対応付ける表であるＬＲテーブル４０と、（２）ＬＲテーブル４０を参照することで、コンテンツ参照ＩＤの指すコンテンツのロケーションを解決するという処理を行うＬＲサーバ４１と、（３）ＬＲサーバ４１の処理したコンテンツ参照ＩＤのログデータを記録するログファイル４２とを備えることで、ＲＡＲシステム５から解決要求のあったコンテンツのロケーションを解決して、それをＲＡＲシステム５に返信する。

ＲＡＲシステム５は、（１）コンテンツ参照ＩＤを発行した“authority ”をＬＲシステム４に結び付ける表であるＲＡＲテーブル５０と、（２）ＲＡＲテーブル５０を参照することで、携帯端末２から送られてきたコンテンツ参照ＩＤを処理するＬＲシステム４を特定して、その特定したＬＲシステム４に対してそのコンテンツ参照ＩＤを転送してロケーションの解決を要求するという処理を行うとともに、その解決結果に基づいて、コンテンツサーバ３に対して携帯端末２へのコンテンツの配信を要求するという処理を行うＲＡＲサーバ５１と、（３）ＲＡＲサーバ５１の処理したコンテンツ参照ＩＤのログデータを記録するログファイル５２とを備えることで、携帯端末２から送られてきたコンテンツ参照ＩＤを処理するＬＲシステム４に対して、そのコンテンツ参照ＩＤの指すコンテンツのロケーションの解決を要求し、その解決結果に従って、コンテンツサーバ３に対して携帯端末２へのコンテンツの配信を要求する。

このように構成される本発明を具備するデジタル放送双方向通信システムでは、放送局１は、放送局ＩＤなどから、例えば、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤを生成して、それを番組やＣＭなどのコンテンツに埋め込んでデジタル放送する。

携帯端末２は、このデジタル放送を受信しているときに、ユーザが視聴中のコンテンツの持つボタンを操作することで、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤを指定してコンテンツの視聴要求を発行すると、この“CRID:// ・・・”の記述に従ってＲＡＲシステム５に接続する。

この接続を受けて、ＲＡＲシステム５は、ＲＡＲテーブル５０を使って、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤの持つ“authority ”のＤＮＳネーム部分の“tbs.co.jp ”が、例えば、
“tbs.co.jp ”＝“res-service.com ”
であることで、“res-service.com ”のＵＲＬを持つＬＲシステム４に対して、コンテンツのロケーションの解決を要求する必要のあることが分かるので、そのＬＲシステム４に対して、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤの指すコンテンツのロケーションの解決を要求する。

このロケーションの解決要求を受けて、ＬＲシステム４は、ＬＲテーブル４０を使って、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤから、例えば、そのコンテンツのロケーションが、
drama/時代劇＝http://nttdata.co.jp/archive/1234
であることを解決する。

このロケーションの解決結果を受けて、ＲＡＲシステム５は、この解決結果に基づいて、“http://nttdata.co.jp”というコンテンツサーバ３に対して、“archive/1234”という場所に格納されるコンテンツを携帯端末２へ配信することを要求し、これを受けて、そのコンテンツサーバ３は、“archive/1234”という場所に格納されるユーザの視聴要求するコンテンツを携帯端末２に配信する。

このようにして、本発明を具備するデジタル放送双方向通信システムは、図２に示すようなタイムチャートに従って、ユーザの視聴要求するコンテンツを携帯端末２に配信するように処理するのである。

すなわち、本発明を具備するデジタル放送双方向通信システムでは、携帯端末２は、放送局ＩＤや送出時刻などから生成されたコンテンツ参照ＩＤによりＲＡＲシステム５に接続し、これを受けて、ＲＡＲシステム５は、該当するＬＲシステム４に対して、そのコンテンツ参照ＩＤの指すコンテンツのローケションの解決を要求し、これを受けて、ＬＲシステム４は、そのコンテンツ参照ＩＤよりローケションの解決を行い実際のアドレスに変換してＲＡＲシステム５に返信し、これを受けて、ＲＡＲシステム５は、その変換されたアドレスに従ってコンテンツサーバ３に接続してコンテンツの配信を要求し、これを受けて、コンテンツサーバ３は、その配信要求のあるコンテンツを携帯端末２に配信することで、ユーザの視聴要求するコンテンツを携帯端末２に配信するのである。

以上に説明したことから分かるように、本発明を具備するデジタル放送双方向通信システムでは、ユーザからのコンテンツの視聴要求時に、そのコンテンツを提供するコンテンツサーバ３を隠蔽することが可能となるとともに（ＵＲＬを見せないで済む）、放送局ＩＤや送出時刻など直接コンテンツサーバ３に関わらないデータからコンテンツ参照ＩＤを生成することから、セキュアな通信によるコンテンツ提供サービスが可能となる。

これに加えて、本発明を具備するデジタル放送双方向通信システムでは、ＲＡＲシステム５、ＬＲシステム４によりポータルサイトとしての存在が可能となることから、コンテンツ参照ＩＤのログデータを採取することができるようになることで、どのコンテンツがどの位の回数視聴されたのかを知ることができるようになり、実際にサービスを提供する放送局１などが双方向サービスを管理することができるようになる。

上述したように、本発明を具備するデジタル放送双方向通信システムでは、放送局ＩＤの他に、送出時刻を含める形でコンテンツ参照ＩＤを生成することができる。

このように送出時刻を含める形でコンテンツ参照ＩＤを生成すると、図３に示すように、その送出時刻をもとにコンテンツのロケーションを解決することで、ユーザのアクション時の放送内容に対応したコンテンツを提供することができるようになる。例えば、あるＣＭの視聴要求がある場合に、朝なら朝にあったＣＭをユーザに提供し、夕方なら夕方にあったＣＭをユーザに提供するというように、ユーザに対して、その送出時刻にあったＣＭを提供することができるようになる。

これ以外にも、例えば、ＣＭの視聴要求がある場合に、ユーザの位置にあったＣＭを提供できるようになれば有効であるし、ユーザの興味の持つＣＭを提供できるようになれば有効である。すなわち、同じ番組を放送していても、放送先の地域に合ったＣＭを提供できるようになれば有効であるし、同じ番組を放送していても、ユーザの性別などにあったＣＭを提供できるようになれば有効である。

このようなことを実現する場合には、放送局１は、ユーザの位置情報の取得指示について記述するコンテンツ参照ＩＤを生成したり、ユーザ情報の取得指示について記述するコンテンツ参照ＩＤを生成するようにし、これを受けて、携帯端末２は、コンテンツの視聴要求に応答してＲＡＲシステム５に対してコンテンツ参照ＩＤを転送する際などに、搭載するＧＰＳなどにより検出される位置情報やメモリに記録されるユーザ情報に従って該当する情報を取得して、それをコンテンツ参照ＩＤに記入することでコンテンツ参照ＩＤを完成させるようにする。

これにより、ユーザの位置情報をもとにコンテンツのロケーションを解決することができるようになることで、ユーザの位置情報にあったＣＭを提供できるようになったり、ユーザ情報をもとにコンテンツのロケーションを解決することができるようになることで、ユーザの興味のあるＣＭを提供できるようになる。

このようにして、本発明を具備するデジタル放送双方向通信システムでは、図４に示すように、コンテンツ参照ＩＤの持つあるＩＤ項目αの値がａである場合には、ロケーションａを得ることで、コンテンツサーバａに管理されるコンテンツａを配信コンテンツとして決定し、そのＩＤ項目αの値がｂである場合には、ロケーションｂを得ることで、コンテンツサーバｂに管理されるコンテンツｂを配信コンテンツとして決定するということを実現し、これにより、ユーザがアクションを起こしたタイミングの時点におけるＩＤ項目の値に応じて配信コンテンツを決定することができるようになるので、ユーザに対して適切なコンテンツを提供できるようになるのである。

さらに、本発明を具備するデジタル放送双方向通信システムでは、同じコンテンツ参照ＩＤで複数のＣＭが指定可能となる場合には、どのＣＭを放送するのかを示す情報（例えば、“広告会社の識別フラグ＋ＣＭＩＤ”で構成される情報）を含める形でコンテンツ参照ＩＤを生成することができるし、同じコンテンツ参照ＩＤで複数の番組が指定可能となる場合には、どの番組を放送するのかを示す情報（例えば、番組ＩＤで構成される情報）を含める形でコンテンツ参照ＩＤを生成することができる。

ＣＭを扱う場合、通常の場合、広告会社が複数となることが多い。そこで、このような場合には、図５に示すように、ＬＲシステムを、上位ＬＲシステム４ａと広告会社に対応付ける形で用意される下位ＬＲシステム４ｂというように階層的に構成して、上位ＬＲシステム４ａで、コンテンツ参照ＩＤに基づいて、どの下位ＬＲシステム４ｂを用いるのかを特定して、その特定した下位ＬＲシステム４ｂで、そのコンテンツ参照ＩＤを対応するロケーションに変換するという方法を用いるようにしてもよい。

このような階層的な構成を採ると、広告会社に対応付ける形で下位ＬＲシステム４ｂを用意することから、各広告会社の責任の下にロケーションの解決を行うことができるようになる。

以上に説明した実施の形態では、放送局１から放送されてくる番組やＣＭに埋め込まれたコンテンツ参照ＩＤを指定してコンテンツの視聴要求が発行されることを想定したが、本発明はインターネット放送などのような有線サービス放送のＥＰＧ（電子番組案内）に対しても適用可能である。

インターネット放送などのような有線サービス放送のＥＰＧについては、図１に示した放送局１から放送されてくる場合もあるし、インターネットを介して放送されてくる場合もあるが、ここでは、説明の便宜上、図１に示した放送局１から放送されてくることを想定する。

従来技術では、インターネット放送などのような有線サービス放送のＥＰＧについては、番組の提供元のＵＲＬを使って記述するようにしているが、本発明では、コンテンツ参照ＩＤを使って記述するという構成を採る。

このように構成されるＥＰＧの放送を受けて、携帯端末２は、ユーザがＥＰＧに記載される番組を選択することで、例えば、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤを指定して番組の録画の予約要求を発行すると、この“CRID:// ・・・”の記述に従ってＲＡＲシステム５に接続する。

この接続を受けて、ＲＡＲシステム５は、ＲＡＲテーブル５０を使って、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤの持つ“authority ”のＤＮＳネーム部分の“tbs.co.jp ”が、例えば、
“tbs.co.jp ”＝“res-service.com ”
であることで、“res-service.com ”のＵＲＬを持つＬＲシステム４に対して、コンテンツのロケーションの解決を要求する必要のあることが分かるので、そのＬＲシステム４に対して、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤの指すコンテンツのロケーションの解決を要求する。

このロケーションの解決要求を受けて、ＬＲシステム４は、ＬＲテーブル４０を使って、“CRID://tbs.co.jp;drama/ 時代劇”と記述されるコンテンツ参照ＩＤから、例えば、そのコンテンツのロケーションが、
drama/時代劇＝arib:channel6@8.00
であることを解決する。

このロケーションの解決結果を受けて、ＲＡＲシステム５は、携帯端末２に対して“arib:channel6@8.00”を返信することで、ユーザの録画要求する番組が“arib:channel6 ”の８時から放送されることになるということを返信し、これを受けて、携帯端末２は、その送られてきた“arib:channel6@8.00”を使って番組の録画を予約する。

このようにして、本発明を具備するデジタル放送双方向通信システムでは、コンテンツ参照ＩＤを使って有線サービス放送のＥＰＧを記載するようにして、そのＥＰＧの中から番組を選択して番組の録画の予約が発行されると、図６に示すようなタイムチャートに従って、その録画要求の番組を提供するロケーションを解決して、それに従って番組の録画を予約するように処理するのである。

このようなＥＰＧに対して本発明を適用する場合にも、コンテンツを提供するコンテンツサーバ３を隠蔽することが可能となるとともに（ＵＲＬを見せないで済む）、直接コンテンツサーバ３に関わらないデータからコンテンツ参照ＩＤを生成することから、セキュアな通信によるコンテンツ提供サービスが可能となる。

そして、ＲＡＲシステム５、ＬＲシステム４によりポータルサイトとしての存在が可能となることから、コンテンツ参照ＩＤのログデータを採取することができるようになることで、放送者側で、どの番組がどの位の回数視聴されたのかを知ることができるようになる。

次に、実施例に従って、本発明を具備するデジタル放送双方向通信システムについて詳細に説明する。

本発明を具備するデジタル放送双方向通信システムでは、放送局（図１に示す放送局１に相当するもの）は、例えば、図７に示すように、所定のタイムスケジュールに従って、映像とコンテンツ一覧とを多重化して放送し、これを受けて、視聴端末（図１に示す携帯端末２に相当するもの）は、この放送を受信すると、表示画面に、これらの映像とコンテンツとを表示するように動作する。

このとき視聴端末が受信するコンテンツ一覧はＢＭＬ（Broadcast Markup Language)などのマークアップ言語によって記述され、コンテンツへの各リンクはＣＲＩＤ（コンテンツ参照ＩＤ）によって記述されている。

ＣＲＩＤは、“CRID://<authority>/<data> ”という形で記述される。ここで、<authority> はコンテンツの参照先を示し、<authority> と対応する各コンテンツを実際に管理するＬＲサーバ（図１に示すＬＲサーバ４１）のアドレスに変換して、コンテンツのロケーションの問い合わせが行われることになる。また、<data>には、リンクの表示要求を行った送出時間や、コンテンツ一覧の中で表示される複数のリンクを識別するためのスレッドＩＤが記述される。

図７では、「10:00 〜10:15 」という時間帯に番組Ａとともに放送されるコンテンツに対して、“CRID://tbs.co.jp//1 ”というＣＲＩＤと、“CRID://tbs.co.jp//2 ”というＣＲＩＤと、“CRID://tbs.co.jp//3 ”というＣＲＩＤとが埋め込まれ、「10:15 〜10:17 」という時間帯にＣＭとともに放送されるコンテンツに対して、“CRID://tbs.co.jp//1 ”というＣＲＩＤが埋め込まれるという例を示してある。

この例では、ＣＲＩＤのデータ記述として、“ CRID://<authority>/< 送出時刻>/< スレッドＩＤ> ”というものを想定しているが、“送出時刻”については視聴端末の側で挿入することから、放送局から配信される段階では空白になっている。

なお、実施の形態で説明したように、“送出時刻”については放送局の側で挿入するという構成を採ることも可能である。

図８に、本発明を具備するデジタル放送双方向通信システムの一実施例を図示する。

図中、１００は視聴端末であって、図１に示す携帯端末２に相当するもの、２００はＲＡＲサーバであって、図１に示すＲＡＲサーバ５１に相当するもの、３００は複数備えられるＬＲサーバであって、図１に示すＬＲサーバ４１に相当するもの、４００は通信ネットワークであって、図１に示すインターネット６に相当するものである。

視聴端末１００は、放送局からの放送を受信する放送受信手段１０１と、放送受信手段１０１の受信した放送情報を表示画面に表示する表示手段１０２と、ＲＡＲサーバ２００やＬＲサーバ３００との間の通信処理を司る通信手段１０３と、ユーザからの指示を受け取る指示手段１０４と、規定の制御処理を実行する制御手段１０５とを備える。

ＲＡＲサーバ２００は、ＲＡＲテーブル２０１を記憶するＲＡＲテーブル記憶手段２０２と、視聴端末１００やＬＲサーバ３００との間の通信処理を司る通信手段２０３と、規定の制御処理を実行する制御手段２０４とを備える。

ＬＲサーバ３００は、ＬＲテーブル３０１を記憶するＬＲテーブル記憶手段３０２と、受信したロケーション解決要求で指定されるＣＲＩＤとその受信時刻の情報とを記録するログ記憶手段３０３（図１に示すログファイル４２に相当するもの）と、視聴端末１００やＲＡＲサーバ２００との間の通信処理を司る通信手段３０４と、規定の制御処理を実行する制御手段３０５とを備える。

ここで、ＬＲサーバ３００がログ記憶手段３０３を備えることで、どの放送局の放送したどのコンテンツがどの位閲覧されるのかを把握することが可能になる。

図９に、ＲＡＲテーブル２０１（図１に示すＲＡＲテーブル５０に相当するもの）のデータ構造の一例を図示し、図１０及び図１１に、ＬＲテーブル３０１（図１に示すＬＲテーブル４０に相当するもの）のデータ構造の一例を図示する。

ＲＡＲテーブル２０１は、ＣＲＩＤを発行したａｕｔｈｏｒｉｔｙをＬＲサーバ３００に結び付けるデータを管理するものであって、図９に示すように、ａｕｔｈｏｒｉｔｙとＬＲサーバアドレス（ＬＲサーバ３００のアドレス）との対応関係について記述するデータを管理する。

ＬＲテーブル３０１は、ＣＲＩＤをコンテンツのロケーションに対応付けるデータを管理するものであって、図１０に示すように、各時間帯に放送する各コンテンツ（スレッドＩＤで識別される）に対応付けて、そのコンテンツのアドレス情報について記述するデータを管理する。

ここで、１つのＬＲサーバ３００が複数のａｕｔｈｏｒｉｔｙのコンテンツロケーションを管理する場合には、そのＬＲサーバ３００の備えるＬＲテーブル３０１は、図１１に示すように、各ａｕｔｈｏｒｉｔｙ毎に、各時間帯に放送する各コンテンツに対応付けて、そのコンテンツのアドレス情報について記述するデータを管理するという構成を採ることになる。

また、ＬＲテーブル３０１は、図１０及び図１１に示すように、各時間帯に放送する各コンテンツに対応付けて、そのコンテンツのアドレス情報を管理することに加えて、そのコンテンツに割り当てられたロケータフラグを管理するという構成を採っている。

このロケータフラグに０が立っている場合には、ＬＲテーブル３０１に記憶されるアドレス情報がそのままコンテンツのロケーションを示していることを意味するのに対して、このロケータフラグに１が立っている場合には、別のＬＲサーバ３００がコンテンツのロケーションを管理することを意味しており、この場合には、ＲＡＲサーバ２００からコンテンツロケーションの解決要求を受け取ったＬＲサーバ３００は、ＬＲテーブル３０１に記憶されるアドレス情報に従ってＣＲＩＤのａｕｔｈｏｒｉｔｙ情報を書き換えて、ＲＡＲサーバ２００に対して、そのアドレス情報の指す別のＬＲサーバ３００に対して、コンテンツロケーションの解決要求を依頼するように動作する。

次に、図１２に示すタイムチャートに従って、このように構成される本実施例の処理について説明する。

図１２中の（１）で示すように、視聴端末１００が放送コンテンツを取得し、視聴端末１００を操作するユーザがその放送コンテンツ内のボタンを押すと、視聴端末１００は、図１２中の（２）で示すように、放送局ＲＡＲシステムのＲＡＲサーバ２００に対して、ＣＲＩＤパラメータ情報を渡してＣＲＩＤの解決を要求する。

このＣＲＩＤ解決要求を受けて、ＲＡＲサーバ２００は、ＣＲＩＤパラメータ情報からａｕｔｈｏｒｉｔｙの情報を抽出して、ＲＡＲテーブル２０１に対して、抽出したａｕｔｈｏｒｉｔｙの解決を要求する。

このａｕｔｈｏｒｉｔｙ解決要求を受けて、ＲＡＲテーブル２０１は、そのａｕｔｈｏｒｉｔｙの指すＬＲサーバ３００がどこにあるのかについて示す情報（図９に示すＬＲサーバアドレス）を検索してＲＡＲサーバ２００に返し、これを受けて、ＲＡＲサーバ２００は、図１２中の（４）で示すように、ＣＲＩＤに記述されるａｕｔｈｏｒｉｔｙの指すＬＲサーバ３００の存在場所を示すＬＲサーバアドレスを取得する。

このＬＲサーバアドレスを取得すると、ＲＡＲサーバ２００は、図１２中の（５）で示すように、そのＬＲサーバアドレスの指すＬＲサーバ３００を備える放送局ＬＲシステムに対して、コンテンツロケーションの解決を要求する。

このコンテンツロケーション解決要求を受けて、放送局ＬＲシステムのＬＲサーバ３００は、図１０や図１１に示すようなデータ構造を持つＬＲテーブル３０１を検索することで、コンテンツのアドレス情報を取得して、その取得したアドレス情報（コンテンツロケーション情報）を視聴端末１００に返すことになるが、このとき、検索したアドレス情報に対応付けて管理されるロケータフラグが１を示している場合には、その取得したアドレス情報に従ってＣＲＩＤのａｕｔｈｏｒｉｔｙ情報を書き換えることでコンテンツロケーション解決要求の再依頼情報を生成して、その生成した再依頼情報をＲＡＲサーバ２００に返すことになる。

ここで、この図１２に示すタイムチャートでは、ロケータフラグが１を示している場合を想定しており、これから、ＬＲサーバ３００からＲＡＲサーバ２００に対して、ａｕｔｈｏｒｉｔｙの変換情報が通知され、これを受けて、ＲＡＲサーバ２００は、図１２中の（６）で示すように、このａｕｔｈｏｒｉｔｙの変換情報を取得することで、実際にコンテンツロケーションの解決を要求しなければならないＬＲサーバ３００がどれであるのかを知ることになる。

これから、ＲＡＲサーバ２００は、ａｕｔｈｏｒｉｔｙ変換情報が通知される場合には、先に発行したコンテンツロケーションの解決要求ではコンテンツロケーションを解決できなかったことを判断して、図１２中の（７）で示すように、通知されたａｕｔｈｏｒｉｔｙ変換情報から特定されることになるＬＲサーバ３００に対して、コンテンツロケーションの解決を要求する。

ここで、このタイムチャートでは、ユーザの視聴要求したコンテンツが広告に関するものであり、広告については広告共通のＬＲシステムが用意されていることを想定しているので、ＲＡＲサーバ２００は、図１２中の（７）で示すように、広告共通ＬＲシステムのＬＲサーバ３００に対して、コンテンツロケーションの解決を要求することになる。

このコンテンツロケーション解決要求を受けて、広告共通ＬＲシステムのＬＲサーバ３００は、図１０や図１１に示すようなデータ構造を持つＬＲテーブル３０１を検索することで、コンテンツのアドレス情報を取得して、それを視聴端末１００を返し、これを受けて、視聴端末１００は、図１２中の（８）で示すように、実際のコンテンツロケーション情報を取得する。

このコンテンツロケーション情報を取得すると、視聴端末１００は、図１２中の（９）で示すように、その取得したコンテンツロケーション情報の指すコンテンツサーバ（図１に示すコンテンツサーバ３に相当するもの）に対してコンテンツを要求し、これを受けて、コンテンツサーバが要求されたコンテンツを視聴端末１００に送信してくるので、視聴端末１００は、図１２中の（１０）で示すように、その送信されてくる視聴要求のコンテンツを受信して表示画面に表示する。

次に、図１３ないし図１６に示す処理フローに従って、図１２のタイムチャートで実行する各処理の詳細について説明する。

先ず最初に、図１３の処理フローに従って、図１２のタイムチャートの（１)(２）における処理（図中に示す処理Ａ）の詳細について説明する。

視聴端末１００は、図１２のタイムチャートにおける処理Ａを実行する場合には、図１３の処理フローに示すように、ステップＳ１０で、映像データとＢＭＬなどで記述されたコンテンツ一覧データとが多重化された放送を受信すると、続くステップＳ１１で、その受信した映像とコンテンツ一覧とを表示画面に表示する。

この表示画面に表示するコンテンツ一覧を見て、ユーザが指示手段１０４を操作してコンテンツのリンクを選択してくるので、続いて、ステップＳ１２で、ユーザからの選択指示に従って、ユーザが視聴要求するコンテンツのリンクを選択する。

続いて、ステップＳ１３で、選択したリンクに埋め込まれたＣＲＩＤを抽出し、続くステップＳ１４で、時計を参照することで現在時刻を取得する。

続いて、ステップＳ１５で、抽出したＣＲＩＤに、取得した現在時刻を送出時刻として挿入することで新たなＣＲＩＤを生成する。例えば、“CRID://tbs.co.jp//1 ”というＣＲＩＤを抽出するとともに、“20050907&20:15”という現在時刻を取得した場合の例で説明するならば、“CRID://tbs.co.jp/20050907&20:15/1 ”という新たなＣＲＩＤを生成するのである。

続いて、ステップＳ１６で、新たに生成したＣＲＩＤと視聴端末識別子（ＩＰアドレスやポート情報などの返信に必要となる宛て先情報となるもの）とを含むＣＲＩＤ解決要求情報をＲＡＲサーバ２００に送信することで、図１２のタイムチャートにおける処理Ａを終了する。

次に、図１４の処理フローに従って、視聴端末１００からＣＲＩＤ解決要求を受信したときにＲＡＲサーバ２００が実行する処理（図１２中に示す処理Ｂ）の詳細について説明する。

ＲＡＲサーバ２００は、図１２のタイムチャートにおける処理Ａに従って、視聴端末１００からＣＲＩＤ解決要求を受信すると、図１４の処理フローに示すように、先ず最初に、ステップＳ２０で、視聴端末１００から送られてきたＣＲＩＤ解決要求情報からＣＲＩＤを抽出し、続くステップＳ２１で、その抽出したＣＲＩＤに記述されるａｕｔｈｏｒｉｔｙ情報を抽出する。

例えば、視聴端末１００から“CRID://tbs.co.jp/20050907&20:15/1 ”というＣＲＩＤが送られてきた場合には、“tbs.co.jp ”というａｕｔｈｏｒｉｔｙ情報を抽出するのである。

続いて、ステップＳ２２で、抽出したａｕｔｈｏｒｉｔｙ情報をキーにして、図９に示すようなデータ構造を持つＲＡＲテーブル２０１を参照することで、ユーザが視聴要求するコンテンツのロケーションを把握するＬＲサーバ３００のアドレスを特定する。

続いて、特定したアドレスのＬＲサーバ３００に対して、抽出したＣＲＩＤとＣＲＩＤの解決要求を行った視聴端末識別子とを含むコンテンツロケーション解決要求情報を送信することで、図１２のタイムチャートにおける処理Ｂを終了する。

次に、図１５の処理フローに従って、ＲＡＲサーバ２００からコンテンツロケーション解決要求を受信したときにＬＲサーバ３００が実行する処理（図１２中に示す処理Ｃ）の詳細について説明する。

ＬＲサーバ３００は、図１２のタイムチャートにおける処理Ｂに従って、ＲＡＲサーバ２００からコンテンツロケーション解決要求を受信すると、図１５の処理フローに示すように、先ず最初に、ステップＳ３０で、ＲＡＲサーバ２００から送られてきたコンテンツロケーション解決要求情報からＣＲＩＤを抽出し、続くステップＳ３１で、その抽出したＣＲＩＤに記述される送出時刻とスレッドＩＤとを抽出する。

続いて、ステップＳ３２で、抽出した送出時刻・スレッドＩＤをキーにして、図１０に示すようなデータ構造を持つＬＲテーブル３０１を参照することで、抽出した送出時刻・スレッドＩＤに対応付けられるロケータフラグ情報とアドレス情報とを特定する。

このとき、ＬＲテーブル３０１が図１１に示すように各ａｕｔｈｏｒｉｔｙ毎にデータを管理する構成を採るときには、ＣＲＩＤに記述されるａｕｔｈｏｒｉｔｙ情報に従って、どのＬＲテーブル３０１を参照するのかを決定することになる。

続いて、ステップＳ３３で、特定したロケータフラグ情報からロケータフラグが０を示しているのか否かを判断して、ロケータフラグが０を示していることを判断するときには、ステップＳ３４に進んで、特定したアドレス情報が自ＬＲサーバ３００の管理下にあるコンテンツのＵＲＬであると判断して、視聴端末１００に対して、そのＵＲＬを含むコンテンツロケーション情報を視聴端末識別子とともに送信して、図１２のタイムチャートにおける処理Ｃを終了する。

一方、ステップＳ３３の判断処理に従って、ロケータフラグが０を示していないことを判断するとき、すなわち、ロケータフラグが１を示していることを判断するときには、ステップＳ３５に進んで、別のＬＲサーバ３００（ＬＲテーブル３０１から特定したアドレス情報の指すＬＲサーバ３００）がコンテンツロケーションを管理していることを判断して、特定したアドレス情報と自ａｕｔｈｏｒｉｔｙ情報とに従ってＣＲＩＤを書き換えて、ＲＡＲサーバ２００に対して、その書き換えたＣＲＩＤを含むコンテンツロケーション解決要求の再依頼情報を送信して、図１２のタイムチャートにおける処理Ｃを終了する。

例えば、ＲＡＲサーバ２００から“CRID://tbs.co.jp/20050907&20:15/1 ”というＣＲＩＤが送られてきた場合にあって、ＬＲテーブル３０１から特定したアドレス情報が“advertising.co.jp ”で、自ａｕｔｈｏｒｉｔｙ情報が“tbs.co.jp ”であるという場合には、“advertising.co.jp ”がコンテンツロケーション再要求先のａｕｔｈｏｒｉｔｙ情報であると判断して、この“CRID://tbs.co.jp/20050907&20:15/1 ”を、“CRID://advertising.co.jp/20050907&20:15/1/tbs.co.jp ”と書き換えて、ＲＡＲサーバ２００に対して、その書き換えたＣＲＩＤを含むコンテンツロケーション解決要求の再依頼情報を送信して、図１２のタイムチャートにおける処理Ｃを終了するのである。

次に、ＬＲサーバ３００からコンテンツロケーション解決要求の再依頼を受信したときにＲＡＲサーバ２００が実行する処理（図１２中に示す処理Ｄ）について説明する。

このときＲＡＲサーバ２００が実行する処理は、基本的には、図１４の処理フローで実行する処理と同一である。

すなわち、ＲＡＲサーバ２００は、ＬＲサーバ３００からコンテンツロケーション解決要求の再依頼を受信すると、先ず最初に、ＬＲサーバ３００から送られてきた再依頼情報からＣＲＩＤを抽出して、その抽出したＣＲＩＤに記述されるａｕｔｈｏｒｉｔｙ情報を抽出する。そして、その抽出したａｕｔｈｏｒｉｔｙ情報をキーにして、図９に示すようなデータ構造を持つＲＡＲテーブル２０１を参照することで、ユーザが視聴要求するコンテンツのロケーションを把握する新たなＬＲサーバ３００のアドレスを特定する。そして、その特定した新たなＬＲサーバ３００に対して、抽出したＣＲＩＤと視聴端末識別子とを含むコンテンツロケーション解決要求情報を送信するのである。

このコンテンツロケーション解決要求を受信したときに新たなＬＲサーバ３００が実行する処理（図１２中に示す処理Ｅ）は、基本的には、図１５の処理フローで実行する処理と同一である。

すなわち、その新たなＬＲサーバ３００では、ＲＡＲサーバ２００から送られてきたコンテンツロケーション解決要求情報からＣＲＩＤを抽出し、その抽出したＣＲＩＤに記述されるａｕｔｈｏｒｉｔｙ情報、送出時刻、スレッドＩＤを抽出する。そして、そのａｕｔｈｏｒｉｔｙ情報の指すＬＲテーブル３０１を参照することで、その抽出した送出時刻・スレッドＩＤに対応付けられるロケータフラグ情報とアドレス情報とを特定して、それに基づいて、視聴端末１００に対してコンテンツロケーション情報を送信したり、ＲＡＲサーバ２００に対して、その書き換えたＣＲＩＤを含むコンテンツロケーション解決要求の再依頼情報を送信するのである。

次に、ＬＲサーバ３００からコンテンツロケーション情報を受信したときに視聴端末１００が実行する処理（図１２中に示す処理Ｆ）について説明する。

視聴端末１００は、図１２のタイムチャートにおける処理Ｅに従って、ＬＲサーバ３００からコンテンツロケーション情報を受信すると、図１６の処理フローに示すように、先ず最初に、ステップＳ４０で、受信したコンテンツロケーション情報に含まれるＵＲＬを抽出する。

続いて、ステップＳ４１で、その抽出したＵＲＬの指すコンテンツサーバ（図１に示すコンテンツサーバ３に相当するもの）からコンテンツを取得し、続くステップＳ４２で、その取得したコンテンツを表示画面に表示して、図１２のタイムチャートにおける処理Ｆを終了する。

このようにして、図８のように構成される本発明を具備するデジタル放送双方向通信システムによれば、コンテンツへのリンクをＣＲＩＤによって記述して、映像とコンテンツ一覧とを多重化して放送し、これを受けて、視聴端末が表示画面に映像とコンテンツとを表示するように動作するときに、送出時刻を含める形でＣＲＩＤを生成して、その送出時刻をもとにコンテンツのロケーションを解決するようにすることで、ユーザのアクション時の放送内容に対応したコンテンツの提供を実現することができるようになる。

（１）その他の実施例１
以上に説明した実施例では、ＣＲＩＤに記述された送出時刻、スレッドＩＤを元に、ＬＲサーバ３００からユーザの所望するコンテンツのＵＲＬを取得するようにしたが、その他の方法として、送出時刻、スレッドＩＤの他にユーザの個人情報を含めるようにしてもよい。

このようにすると、例えば、未成年者に対してお酒に関連したコンテンツの提供を行わないようにしたり、女性に対して女性をターゲットにした化粧品情報を提供できるようになるといったように、ユーザに応じたコンテンツを配信することができるようになる。

このような個人情報に合ったコンテンツの配信を実現するためには、例えば、視聴端末１００が、ユーザの個人情報（性別、年齢、嗜好情報、住所など）を記憶する個人情報記憶手段を備えるようにするとともに、ＬＲサーバ３００が、時間、スレッドＩＤの他に、個人情報ごとに、表示させたいコンテンツのＵＲＬや表示させたいコンテンツを管理する別のＬＲサーバ３００のａｕｔｈｏｒｉｔｙ情報を記録するＬＲテーブル３０１を備えるようにして、上述した処理Ａにおいて、視聴端末１００が送出時刻について記述するＣＲＩＤを生成するかわりに、送出時刻と、性別、年齢などの個人情報とについて記述するＣＲＩＤを生成するという方法を用いることになる。

この方法を用いることで、例えば、ユーザが２１歳の男性である場合には、“CRID://tbs.co.jp/20050907&20:15/1/m/21”というようなＣＲＩＤを生成することができ、これにより、上述した実施例と同様の処理に従って、上述のようなデータを管理するＬＲテーブル３０１を参照することで、視聴端末１００は、２１歳の男性に合ったコンテンツを取得して表示画面に表示することができるようになる。

また、別の方法として、視聴端末１００の側では、個人情報記憶手段を備えずに、端末ＩＤを記憶する端末ＩＤ記憶手段を備えることで端末ＩＤのみを管理するとともに、ＲＡＲサーバ２００の側で、端末ＩＤと個人情報との対応関係を記憶する記憶手段を備えることで端末ＩＤと個人情報との対応関係を管理して、視聴端末１００からＲＡＲサーバ２００に対してＣＲＩＤ解決要求を行う際に、ＣＲＩＤと端末ＩＤとを送信するようにして、ＲＡＲサーバ２００の側で、端末ＩＤに基づいてユーザの個人情報を読み出し、それをＣＲＩＤに付与するようにするという方法を用いることでも実現可能である。

ここで、このような実施例１の構成を採る場合に、ＣＲＩＤは必ずしも送出時刻について記述する必要はない。ただし、ＣＲＩＤが送出時刻についても記述するという構成を採ると、送出時刻及び個人情報に合ったコンテンツをユーザに配信することができるようになる。

（２）その他の実施例２
上述した実施例では、ＣＲＩＤに記述された送出時刻、スレッドＩＤを元に、ＬＲサーバ３００からユーザの所望するコンテンツのＵＲＬを取得するようにしたが、その他の方法として、送出時刻、スレッドＩＤの他に視聴端末１００の現在位置の情報を含めるようにしてもよい。

このようにすると、例えば、ユーザが東京にいるときには、東京に関連したコンテンツを提供し、ユーザが千葉にいるときには、千葉に関連したコンテンツを提供できるようになるといったように、ユーザの現在位置に応じたコンテンツを配信することができるようになる。

このようなユーザの現在位置に合ったコンテンツの配信を実現するためには、例えば、視聴端末１００がＧＰＳなどのような位置情報取得手段を備えるようにするとともに、上述した処理Ａにおいて、視聴端末１００が送出時刻と現在位置情報とについて記述するＣＲＩＤを生成するようにし、さらに、ＬＲサーバ３００にて、図１７に示すような地域ごとにアクセス先の異なるＵＲＬを記憶するＬＲテーブル３０１と、図１８に示すような緯度経度と地域との対応関係について記憶する地域変換テーブルとを備えるという方法を用いることになる。

この方法を用いることで、例えば、ユーザの現在位置が緯度35.5で経度135.2 である場合には、“CRID://tbs.co.jp/20050907&20:15/1/35.5&135.2”というようなＣＲＩＤを生成することができ、これにより、上述した実施例と同様の処理に従って、上述のようなデータを管理するＬＲテーブル３０１を参照することで、視聴端末１００は、ユーザが現在いる地域に合ったコンテンツを取得して表示画面に表示することができるようになる。

ここで、このような実施例２の構成を採る場合に、ＣＲＩＤは必ずしも送出時刻について記述する必要はない。ただし、ＣＲＩＤが送出時刻についても記述するようにすると、送出時刻及び位置情報に合ったコンテンツをユーザに配信することができるようになる。

（３）その他の実施例３
上述した実施例では説明しなかったが、放送時にコンテンツ一覧に記載されたＣＲＩＤに、現在視聴している番組の識別子を記述したり、ＣＭであればそのＣＭの広告枠を取り扱う広告代理店の識別子を記述したり、ＣＭの識別子を記述するようにしてもよい。

例えば、ＣＭＩＤが220021で、そのＣＭを取り扱う代理店の識別子がＨＨＤである場合に、“CRID://tbs.co.jp/20050907&20:15/1/HDD&220021”というようなＣＲＩＤを生成するようにしてもよい。

このようにすることで、ログデータを解析する際に、ＬＲサーバ３００を再度たどらなくても、どのＣＭやどの広告枠やどの番組に関連する情報が要求されたのかを簡単に把握することできるようになる。

また、同じ情報をコンテンツにも含めておくことにより、視聴端末１００の側でも、ロケーションの解決されたコンテンツと、ロケーションの解決要求を出したＣＲＩＤとを比較することによって、正しいコンテンツのロケーション解決が行われたのかを確認することができるようになる。

（４）その他の実施例４
（４−１）上述した実施例では、ＣＲＩＤの<data>部分に記述する情報については、その記述する情報ごとに記述位置が定められていることで説明した。同様に、その他の実施例１〜３でも、ＣＲＩＤの<data>部分に記述する情報については、その記述する情報ごとに記述位置が定められていることで説明した。

この<data>部分についての記述方法として、このような方法を用いずに、例えば、“CRID://tbs.co.jp/time:20050907&20:15/1/thread:1 ”というように、情報の種別に応じたタグとともに記述するという方法を用いることも可能である。

この方法を用いる場合には、各処理におけるＣＲＩＤの抽出については、視聴端末１００やＲＡＲサーバ２００やＬＲサーバ３００にタグの解析手段（パーサ）を備えるようにして、公知の方法を用いて、任意の情報をＣＲＩＤから抽出するようにする。

この方法を用いるようにすれば、ＣＲＩＤに記述される情報を柔軟に変更することができるようになる。

（４−２）また、上述した実施例では、ＣＲＩＤの<data>部分に記述する情報として、視聴端末１００やＲＡＲサーバ２００やＬＲサーバ３００に対して情報の取得を指示する要求情報を記述するようにはしていない。

この<data>部分についての記述方法として、例えば、“CRID://tbs.co.jp/<送出時刻要求>/1/< 年齢情報取得要求>/< 位置情報取得要求> ”というように、視聴端末１００やＲＡＲサーバ２００やＬＲサーバ３００に対して情報の取得を指示する要求情報を記述するようにしてもよい。ここで、< ・・・要求> は単なるフラグであってもよく、また、上述したタグによる方法と組み合わせてもよい。

この方法を用いる場合には、視聴端末１００やＲＡＲサーバ２００やＬＲサーバ３００に情報記入確認手段を備えるようにして、ＣＲＩＤを生成する際に、要求情報を確認して必要な情報を記載する処理を実行することになる。

この方法を用いるようにすれば、例えば、ユーザの個人情報などを不用意に流出させるという恐れを軽減できるようになる。

以上に説明した実施例では、放送局から放送されてくる番組やＣＭに埋め込まれたＣＲＩＤを指定してコンテンツの視聴要求が発行される場合を想定したが、インターネット放送などのような有線サービス放送のＥＰＧ（電子番組案内）に対しても同様の構成に従って実現可能であり、この場合には、ＬＲテーブル３０１は、時間ではなくて、ジャンルなどとコンテンツＵＲＬなどとが対応付けられるテーブルとなる。

本発明は、ＡＲＩＢの提案する地上デジタル放送双方向通信に適用可能である他に、デジタル放送双方向通信のような双方向通信を実現する形でコンテンツを放送するあらゆる放送システムに適用可能である。

本発明を具備するデジタル放送双方向通信システムのシステム構成図である。 本発明を具備するデジタル放送双方向通信システムの実行する処理のタイムチャートである。 本発明を具備するデジタル放送双方向通信システムの実行する処理の説明図である。 本発明を具備するデジタル放送双方向通信システムの実行する処理のタイムチャートである。 本発明を具備するデジタル放送双方向通信システムの実行する処理の説明図である。 本発明を具備するデジタル放送双方向通信システムの実行する処理のタイムチャートである。 本発明を具備するデジタル放送双方向通信システムで放送される放送情報の一例を示す図である。 本発明を具備するデジタル放送双方向通信システムの一実施例である。 ＲＡＲテーブルのデータ構造の一例を示す図である。 ＬＲテーブルのデータ構造の一例を示す図である。 ＬＲテーブルのデータ構造の一例を示す図である。 本発明を具備するデジタル放送双方向通信システムの実行する処理のタイムチャートの一実施例である。 視聴端末の実行する処理フローである。 ＲＡＲサーバの実行する処理フローである。 ＬＲサーバの実行する処理フローである。 視聴端末の実行する処理フローである。 ＬＲテーブルのデータ構造の他の一例を示す図である。 地域変換テーブルのデータ構造の一例を示す図である。

符号の説明

１ 放送局
２ 携帯端末
３ コンテンツサーバ
４ ＬＲシステム
５ ＲＡＲシステム
６ インターネット
１０ ＣＲＩＤ生成システム
１１ 送出システム
３０ コンテンツデータベース
４０ ＬＲテーブル
４１ ＬＲサーバ
４２ ログファイル
５０ ＲＡＲテーブル
５１ ＲＡＲサーバ
５２ ログファイル

Claims (11)

1. コンテンツを放送するシステムで用いられるコンテンツのロケーション解決方法であって、
   コンテンツの一覧を放送する場合に、そのコンテンツ一覧に、それらのコンテンツに対応付けられるコンテンツ参照ＩＤを埋め込んで放送する過程と、
   上記コンテンツ一覧の中から選択されたコンテンツを指定して、コンテンツのロケーションの解決要求がある場合に、その解決要求を受け付ける受付サーバで、そのコンテンツのロケーションの解決を行う解決サーバを特定する過程と、
   上記特定した解決サーバで、上記解決要求で指定されたコンテンツに対応付けられるコンテンツ参照ＩＤを対応するロケーションに変換する過程と、
   上記変換したロケーションを上記解決要求元の装置に通知する過程とを備えることを、
   特徴とするコンテンツロケーション解決方法。
2. 請求項１に記載のコンテンツロケーション解決方法において、
   上記解決サーバが上位サーバと複数の下位サーバとで階層的に構成され、
   上記変換する過程では、上位サーバで、上記解決要求で指定されたコンテンツに対応付けられるコンテンツ参照ＩＤに基づいて、どの下位サーバを用いるのかを特定して、その特定した下位サーバで、そのコンテンツ参照ＩＤを対応するロケーションに変換することを、
   特徴とするコンテンツロケーション解決方法。
3. 請求項１又は２に記載のコンテンツロケーション解決方法において、
   上記受付サーバで受け付けたコンテンツ参照ＩＤのログデータ、あるいは、上記解決サーバで変換したコンテンツ参照ＩＤのログデータを集計分析する過程を備えることを、
   特徴とするコンテンツロケーション解決方法。
4. コンテンツを放送するシステムで用いられるコンテンツの配信方法であって、
   放送するコンテンツに、それからリンクするコンテンツのコンテンツ参照ＩＤを埋め込んで放送する過程と、
   上記コンテンツ参照ＩＤを指定して、コンテンツの視聴要求がある場合に、その視聴要求を受け付ける受付サーバで、そのコンテンツのロケーションの解決を行う解決サーバを特定する過程と、
   上記特定した解決サーバで、上記視聴要求で指定されたコンテンツ参照ＩＤを対応するロケーションに変換する過程と、
   上記変換したロケーションの指すコンテンツサーバから、上記視聴要求元の装置に対してコンテンツを配信する過程とを備えることを、
   特徴とするコンテンツ配信方法。
5. 請求項４に記載のコンテンツ配信方法において、
   上記解決サーバが上位サーバと複数の下位サーバとで階層的に構成され、
   上記変換する過程では、上位サーバで、上記視聴要求で指定されたコンテンツ参照ＩＤに基づいて、どの下位サーバを用いるのかを特定して、その特定した下位サーバで、そのコンテンツ参照ＩＤを対応するロケーションに変換することを、
   特徴とするコンテンツ配信方法。
6. 請求項４又は５に記載のコンテンツ配信方法において、
   上記放送する過程では、少なくとも放送局のＩＤと送出時刻とについて記述するコンテンツ参照ＩＤを埋め込んで放送することを、
   特徴とするコンテンツ配信方法。
7. 請求項４又は５に記載のコンテンツ配信方法において、
   上記放送する過程では、少なくとも放送局のＩＤと送出時刻の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送し、
   上記視聴要求元装置は、コンテンツ参照ＩＤに上記取得指示が記述されている場合には、上記送出時刻を取得してコンテンツ参照ＩＤに記入することを、
   特徴とするコンテンツ配信方法。
8. 請求項４又は５に記載のコンテンツ配信方法において、
   上記放送する過程では、少なくとも放送局のＩＤと上記視聴要求元装置の位置情報の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送し、
   上記視聴要求元装置は、コンテンツ参照ＩＤに上記取得指示が記述されている場合には、上記位置情報を取得してコンテンツ参照ＩＤに記入することを、
   特徴とするコンテンツ配信方法。
9. 請求項４又は５に記載のコンテンツ配信方法において、
   上記放送する過程では、少なくとも放送局のＩＤと上記視聴要求元装置のユーザ情報の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送し、
   上記視聴要求元装置は、コンテンツ参照ＩＤに上記取得指示が記述されている場合には、上記ユーザ情報を取得してコンテンツ参照ＩＤに記入することを、
   特徴とするコンテンツ配信方法。
10. 請求項４又は５に記載のコンテンツ配信方法において、
    上記放送する過程では、少なくとも放送局のＩＤと上記視聴要求元装置のユーザ情報の取得指示とについて記述するコンテンツ参照ＩＤを埋め込んで放送し、
    上記受付サーバは、コンテンツ参照ＩＤに上記取得指示が記述されている場合には、上記ユーザ情報を取得してコンテンツ参照ＩＤに記入することを、
    特徴とするコンテンツ配信方法。
11. 請求項４ないし１０のいずれか１項に記載のコンテンツ配信方法において、
    上記受付サーバで受け付けたコンテンツ参照ＩＤのログデータ、あるいは、上記解決サーバで変換したコンテンツ参照ＩＤのログデータを集計分析する過程を備えることを、
    特徴とするコンテンツ配信方法。

Images