(57)【特許請求の範囲】
【請求項１】
情報配信装置からコンテンツデータを放送し、端末で前記コンテンツデータを受信する情報利用料課金機能付きデータ送受信方法において、
前記情報配信装置が放送するコンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含み、
前記端末は、当該端末の使用者に関する使用者特性データをあらかじめ記憶しており、前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定するとともに、当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録しておき、
ネットワークを介して前記端末と接続された課金サーバは、前記端末から前記記憶された使用履歴を受けとると、前記配信元特定情報で特定される情報配信元に課金する、
を特徴とする情報利用料課金機能付きデータ送受信方法。
【請求項２】
請求項１の情報利用料課金機能付きデータ送受信方法において、
前記使用者特定情報を用いた表示対象画像データの決定を許可するか否かを決定するための許可テーブルを有すること、
を特徴とするもの。
【請求項３】
請求項２の情報利用料課金機能付きデータ送受信方法において、
前記許可テーブルは、ユーザが修正可能であること、
を特徴とするもの。
【請求項４】
請求項３の情報利用料課金機能付きデータ送受信方法において、
前記情報配信元の信頼度をユーザに提示すること、
を特徴とするもの。
【請求項５】
請求項４の情報利用料課金機能付きデータ送受信方法において、
前記各情報配信元の信頼度は情報配信装置によって予め決定されること、
を特徴とするもの。
【請求項６】
請求項３の情報利用料課金機能付きデータ送受信方法において、
前記許可テーブルはユーザ特定項目ごとに利用可能か否かを設定できること、
を特徴とするもの。
【請求項７】
請求項５の情報利用料課金機能付きデータ送受信方法において、
前記許可テーブルは、各情報配信元に関する信頼度に基づき、自動生成されること、
を特徴とするもの。
【請求項８】
請求項７の情報利用料課金機能付きデータ送受信方法において、
前記ユーザ端末は、前記使用者特定情報を使用する時に、ユーザに問い合わせをし、ユーザから許可があった場合には、前記使用者特定情報を用いた決定を行うこと、
を特徴とするもの。
【請求項９】
請求項１の情報利用料課金機能付きデータ送受信方法において、
前記ユーザ端末は、前記使用者特定情報を使用するか否かを決定する許可リストを記憶しており、当該使用者特定情報読み出し指令を配信した情報配信装置が、かかる許可リストに存在するか否か判断し、存在する場合には、前記使用者特定情報を用いた決定を行うこと、
を特徴とするもの。
【請求項１０】
Ａ）コンテンツデータを放送する情報配信装置、
Ｂ）前記コンテンツデータを受信する受信手段を有する端末、
を備えたデータ送受信システムにおいて、
Ｃ）前記情報配信装置が放送するコンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含み、
Ｄ）前記端末は、
d1)当該端末の使用者に関する使用者特性データを記憶する使用者特性データ記憶手段、
d2)前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定する決定手段、
d3)当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録する履歴記憶手段、を有しており、
Ｅ）さらに、ネットワークを介して前記端末と接続されており、前記端末の履歴記憶手段に記憶された使用履歴を受けとり、この配信元特定情報で特定される情報配信元に課金する課金サーバを備えたこと、
を特徴とする情報利用料課金機能付きデータ送受信システム。
【請求項１１】
情報配信装置から放送されたコンテンツデータを受信する端末とネットワーク接続された課金サーバであって、
前記コンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含んでおり、
前記端末には、当該端末の使用者に関する使用者特性データがあらかじめ記憶されており、
前記端末は、前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定するとともに、当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録し、
前記端末から前記記憶された使用履歴を受けとって、前記配信元特定情報で特定される情報配信元に課金すること、
を特徴とする課金サーバ。
【発明の詳細な説明】
【０００１】
【発明の技術分野】
この発明はユーザ端末に記憶されたユーザ属性の利用料課金に関するものである。
【０００２】
【従来の技術】
今日、ＢＳデジタルのデータ放送にて、ユーザ属性を用いた画面切り替え処理が行われる。簡単に説明すると、ユーザ端末に当該ユーザの氏名、住所、生年月日などをユーザ属性として記憶しておく。放送局から送信するＢＭＬデータに、かかるユーザ属性を読み出すスクリプト（プログラム）を記述しておき、読み出したユーザ属性に応じて、画面を切り替える。たとえば、天気予報のデータ放送にて、読み込んだユーザの住所の詳細情報に自動的に切り替えることができる。
【０００３】
かかるユーザ属性をうまく利用することにより、ユーザにとっては、いちいち選択することなく自動的に利用頻度の高いデータが表示されるし、コンテンツ配信者にとっても、ユーザが興味のある画面まで自動的に切り替えられることにより、提供するサービスの質を向上させることができる。
【０００４】
そこで、発明者は、かかるユーザ属性の利用に対して、課金することを考えた。
【０００５】
【発明が解決しようとする課題】
しかし、課金手法について以下のような問題が考えられる。1)コンテンツ配信元に対してどの程度、受信機内のユーザ特性情報を参照するコンテンツを配信したかを記録させて、課金した場合、正確な申請がなされないおそれがある。2)申請は正確に行われるとしても配信元で特定できるのは、送信した回数であって、前記自動切替処理のためのユーザ属性の利用実績を把握することができない。なぜなら、放送は双方向ではないので、受信台数が不明であること、さらに、ユーザ属性を記録していないユーザも存在するからである。
【０００６】
上記問題点1)は、インターネットと接続されたコンテンツサーバから配信する場合も同様に問題となる。
【０００７】
この発明は上記の問題点を解決し、ユーザ属性の利用頻度に応じた課金が可能な情報利用料課金方法またはそのシステムを提供することを目的とする。
【０００８】
【課題を解決するための手段および発明の効果】
１）本発明にかかる情報利用料課金方法は、情報配信装置からコンテンツデータを放送し、端末で前記コンテンツデータを受信する情報利用料課金機能付きデータ送受信方法において、前記情報配信装置が放送するコンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含み、前記端末は、当該端末の使用者に関する使用者特性データをあらかじめ記憶しており、前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定するとともに、当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録しておき、ネットワークを介して前記端末と接続された課金サーバは、前記端末から前記記憶された使用履歴を受けとると、前記配信元特定情報で特定される情報配信元に課金する。
このように、前記使用者特定情報の使用履歴をその配信元特定情報と対応づけて記憶しておき、この履歴に基づいて課金サーバにて課金することにより、使用者特定情報の使用頻度に応じた課金が可能となる。
【０００９】
２）本発明にかかる情報利用料課金方法においては、前記使用者特定情報を用いた表示対象画像データの決定を許可するか否かを決定するための許可テーブルを有する。したがって、許可テーブルによって前記決定の許可が決定される。
【００１０】
３）本発明にかかる情報利用料課金方法においては、前記許可テーブルは、ユーザが修正可能である。したがって、ユーザが前記使用者特定情報を利用するか否かを決定することができる。
【００１１】
４）本発明にかかる情報利用料課金方法においては、前記情報配信元の信頼度をユーザに提示する。したがって、信頼度に基づきユーザは前記許可テーブルを修正することができる。
【００１２】
５）本発明にかかる情報利用料課金方法においては、前記各情報配信元の信頼度は情報配信装置によって予め決定される。したがって、前記各情報配信元の判断を尊重して、前記許可テーブルを修正することができる。
【００１３】
６）本発明にかかる情報利用料課金方法においては、前記許可テーブルはユーザ特定項目ごとに利用可能か否かを設定できる。したがって、使用するユーザ特性項目を詳細に設定することができる。
【００１４】
７）本発明にかかる情報利用料課金方法においては、前記許可テーブルは、各情報配信元に関する信頼度に基づき、自動生成される。したがって、前記信頼度に応じて前記使用者特定情報を使用するか否かを決定できる。
【００１５】
８）本発明にかかる情報利用料課金方法においては、前記ユーザ端末は、前記使用者特定情報を使用する時に、ユーザに問い合わせをし、ユーザから許可があった場合には、前記使用者特定情報を用いた決定を行う。したがって、前記使用者特定情報の使用はユーザの許可がない限り実行されず、使用者特定情報を利用したデータ処理について、ユーザのコントロールが可能となる。
【００１６】
９）本発明にかかる情報利用料課金方法においては、前記ユーザ端末は、前記使用者特定情報を使用するか否かを決定する許可リストを記憶しており、当該使用者特定情報読み出し指令を配信した情報配信装置が、かかる許可リストに存在するか否か判断し、存在する場合には、前記使用者特定情報を用いた決定を行う。したがって課金に対して支払う意思のある者を許可リストに登録しておくことにより、かかるリストに存在する場合に、前記使用者特定情報が使用されるので、確実に課金することができる。
【００１７】
１０）本発明にかかる情報利用料課金機能付きデータ送受信システムにおいては、Ａ）コンテンツデータを放送する情報配信装置、Ｂ）前記コンテンツデータを受信する受信手段を有する端末、を備え、Ｃ）前記情報配信装置が放送するコンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含み、Ｄ）前記端末は、d1)当該端末の使用者に関する使用者特性データを記憶する使用者特性データ記憶手段、d2)前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定する決定手段、d3)当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録する履歴記憶手段、を有しており、Ｅ）さらに、ネットワークを介して前記端末と接続されており、前記端末の履歴記憶手段に記憶された使用履歴を受けとり、この配信元特定情報で特定される情報配信元に課金する課金サーバを備えている。
このように、前記使用者特定情報の使用履歴をその配信元特定情報と対応づけて記憶しておき、この履歴に基づいて課金サーバにて課金することにより、使用者特定情報の使用頻度に応じた課金が可能となる。
【００２２】
１１）本発明にかかる課金サーバは、情報配信装置から放送されたコンテンツデータを受信する端末とネットワーク接続された課金サーバであって、前記コンテンツデータは、使用者特性データ読み出し指令を含むとともに、使用者特性データに応じて異なる提示をするためのスクリプトを含んでおり、前記端末には、当該端末の使用者に関する使用者特性データがあらかじめ記憶されており、前記端末は、前記情報配信装置から放送されたコンテンツデータを受信すると、前記スクリプトをよって当該使用者特性データに合致した提示データを決定するとともに、当該使用者特性データの使用履歴を前記コンテンツデータの配信元特定情報とともに記録し、前記端末から前記記憶された使用履歴を受けとって、前記配信元特定情報で特定される情報配信元に課金する。
このように、各端末にて前記使用者特定情報の使用履歴をその配信元特定情報と対応づけて記憶しておき、この履歴に基づいて課金することにより、使用者特定情報の使用頻度に応じた課金が可能となる。
【００３７】
この発明において、「受信装置」とは、送信装置からのデータを受信する機能を有する装置をいい、表示装置を持たないいわゆるセットトップボックスや、表示装置を有するテレビセットの双方を含む概念である。さらに、携帯電話、携帯端末、パソコンなども含む。
【００３８】
「通信路」とは、有線である場合はもちろん無線である場合も含む。
【００３９】
「通信路を介して取得する」とは、１対１の通信だけでなく、１対多の放送も含む。
【００４０】
「構造記述型言語記述データ」とは、文書データを表示する場合の配置位置、文字列の大きさ、参照する図形データに関する情報等の表示指定情報が付加されたデータをいい、実施形態では、ＢＭＬ言語で記述されたデータである場合について説明したが、ＨＴＭＬ，ＸＭＬ型データ、ＭＨＥＧ規格のデータ等を含む。
【００４１】
「ＢＭＬ言語」とは、データ放送にて用いられるコンテンツ記述言語の一種であり、ARIB（Association of Radio Indusries and Businesses）の規格 STD-B24 ver1.2で定められている。
【００４２】
「ユーザ特性情報」とは、実施形態ではユーザ属性が該当する。
【００４３】
「プログラムを記録した記録媒体」とは、プログラムを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。ＣＰＵに接続されて、記録されたプログラムが直接実行されるハードディスクのような記録媒体だけでなく、一旦ハードディスク等にインストールした後に実行されるプログラムを記録したＣＤ−ＲＯＭ等の記録媒体を含む概念である。
【００４４】
「プログラム」とは、ＣＰＵにより直接実行可能なプログラムだけでなく、ソース形式のプログラム、圧縮処理がされたプログラム、暗号化されたプログラム等を含む概念である。
【００４５】
「データを記録した記録媒体」とは、データを記録したＲＯＭ、ＲＡＭ、フレキシブルディスク、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の記録媒体をいう。また、電話回線、搬送路等の通信媒体も含む概念である。
【００４６】
「データ」とは、ＣＰＵが直接処理可能なデータだけでなく、暗号化されたデータ、パケット化されたデータ、搬送波にのせられたデータ（すなわちデータによって変調した搬送波）等を含む概念である。
【００４７】
【発明の実施の形態】
１．第１実施形態
(1)全体構成
図１に、この発明の一実施形態による受信装置を用いた送受信システムの全体構成を示す。コンテンツ提供者コンピュータ１３は、コンテンツデータを情報提供装置１５に与える。情報提供装置１５は衛星を介して、当該コンテンツデータを放送する。ユーザ端末１は、かかるコンテンツデータを受信部３で受信する。制御部５は、コンテンツデータ中にユーザ属性を読み出すスクリプトが存在するか否か判断し、存在する場合には、配信元がユーザ属性を利用する許可が与えられているか否かを許可ＵＲＩテーブル９ｃを参照して判断する。配信元が前記ユーザ属性を読み出す許可が与えられている場合には、ユーザ属性テーブル９ｂから読み出して、指定先に出力するとともに、履歴情報データテーブル９ａに、配信元特定ＩＤとともにユーザ属性の項目を記憶する。制御部５は所定の時期に履歴情報データテーブル９ａに記憶された履歴データを通信部７を介して、課金サーバ１１に送信する。課金サーバは、かかる履歴データを蓄積する。課金サーバ１１は、複数のユーザ端末から送信された履歴データを用いて、各テナントごとのユーザ属性利用料を演算して、コンテンツ提供者コンピュータ１３に送信する。
【００４８】
このように、ユーザ属性利用料をユーザ端末にて管理することにより、利用頻度に応じた課金をすることができる。
【００４９】
(2)情報配信装置のハードウェア構成
図２に、情報配信装置１５（送信装置）の機能ブロック図を示す。コンテンツ蓄積部３には、コンテンツが蓄積される。データ送信制御部５は、コンテンツ蓄積部３に記録された新たなコンテンツデータを、多重化部７に与える。多重化部７は、パケット化を行って、パケット化のための制御データＤＩＩを生成し、データＤＤＢとともに、送信部９に与える。送信部９は、所定のトランスポートストリームを用いて、前記データをカルーセル形式で送信する。
【００５０】
(3)受信装置のハードウエア構成
図３を用いて、図１に示すユーザ端末（受信装置）１のハードウエア構成について説明する。ハードウェア構成としては従来と同様である。受信装置１は、チューナ３２、トランスポートストリームデコーダ（ＴＳデコーダ）３４、ＡＶデコーダ３６、ＯＳＤ（On Screen Display）３８、ＲＯＭ４０、ＲＡＭ４２、ＣＰＵ４４、ハードディスク４６、モデム４８、リモコンからの信号を受信する信号受信部５０を備えている。信号受信部５０は、リモコン装置からの信号などを受信するためのものである。
【００５１】
ハードディスク４６には、ブラウザプログラム、ユーザ情報取得処理プログラム、履歴データ送信プログラムが記憶される。これらのプログラムによる処理については後述する。また、ハードディスク４６には、ユーザ属性テーブル、履歴情報データテーブル、許可ＵＲＩテーブルが記憶されている。ユーザ属性テーブルのデータ構造について説明する。この例では、図４に示すように、ユーザ属性テーブルは、ユーザ属性項目「氏名」、「住所」、「生年月日」、「趣味１」にそれぞれ「山田太郎」、「大阪府＊＊市＊＊＊町１−２−３」、「 昭和４０年５月２３日」、「旅行」が記録されている。かかるユーザ属性は、ユーザ端末を用いるユーザが予め登録したものである。
【００５２】
図５Ａに履歴情報データテーブルを示す。履歴情報データテーブルは、送信元特定情報であるＵＲＩおよび参照したユーザ属性項目が記憶されている。かかる履歴情報については後述する。
【００５３】
図６に許可ＵＲＩテーブルを示す。許可ＵＲＩテーブルは、ユーザ属性項目読み出しスクリプトが受信データ中に存在する場合に、そのＵＲＩで特定されるコンテンツ配信者に読み出し対象指令のユーザ属性項目の利用を許可するか否かを決定するテーブルである。
【００５４】
なお、蓄積部であるハードディスク４６に、後述する蓄積処理によって、受信したコンテンツを蓄積記憶してもよい。
【００５５】
なお、受信装置として、いわゆるセット・トップ・ボックスを示したが、モニタ（ＴＶセット）を含めて受信装置を構成してもよい。
【００５６】
なお、ユーザ属性テーブル、履歴情報データテーブル、許可ＵＲＩテーブルについては、受信機内部に不揮発性メモリを設け（図示せず）、これに記憶するようにしてもよい。
【００５７】
(4)課金サーバのハードウエア構成
課金サーバ１１は、図７に示すように、ＣＰＵ１２３、メモリ１２７、ハードディスク１２６、ＣＲＴ１３０、ＣＤＤ（ＣＤＲＯＭドライブ）１２５、キーボード１２８、通信ボード１３２およびバスライン１２９を備えている。ＣＰＵ１２３は、ハードディスク１２６に記憶された各プログラムにしたがいバスライン１２９を介して、各部を制御する。
【００５８】
ハードディスク１２６には、後述する課金のためのプログラム１２６pおよび図８に示すＵＲＩ・テナント変換テーブル１２６tが記億されている。図８に示すように、ＵＲＩ・テナント変換テーブルは、ＵＲＩとテナントコードとの対応が記憶されている。かかるテーブルを用いた処理については後述する。
【００５９】
(5)ユーザ属性項目を用いた履歴の記録処理
以下、図６に示す許可ＵＲＩテーブルに記憶されているコンテンツ配信者からのコンテンツデータを受信して、ユーザ属性を用いた課金のための履歴記録処理について説明する。なお、コンテンツ配信者が配信するコンテンツデータが、情報配信装置１５（図１参照）から、オリジナルネットワークid”0001”、トランスポートストリームid”1001”、サービスid”1000”、イベントid”1100”、コンポーネントid”40”で送信されるものとして説明する。
【００６０】
ユーザ端末１のユーザは、リモコン（図示せず）から希望するサービスを受信すべく、選局命令を入力する。これにより、ＣＰＵ４４は、図３に示すチューナ３２およびトランスポートストリームデコーダ３４に選局条件をセットする。受信したＢＭＬデータは、ＲＡＭ４２に順次記憶される。
【００６１】
ハードディスク４６には、図９に示すブラウザプログラムが記憶されており、かかるプログラムに基づいて、データを解釈して表示等の処理を行う。以下説明する。
【００６２】
ＣＰＵ４４は、ＢＭＬデータを受け取ったか否か判断しており（ステップＳ１）、データを受け取ると、その行がスクリプトであるか否か判断する（ステップＳ３）。例えば、図１０に示すＢＭＬデータを受け取った場合、行６５の記述”a=getAdditionalUserInfo(userId，４）”は、スクリプトであるので、スクリプトに基づく処理を行う（ステップＳ５）。かかるスクリプトは、ユーザ属性No４の項目のユーザ属性取得要求のスクリプトである。したがって、ＣＰＵ４４は、ユーザ属性〔４〕の項目取得処理を実行する。
【００６３】
ところで、ブラウザプログラムは、ユーザ属性の項目取得処理をする場合に、図１１に示すユーザ属性取得処理プログラムを有しており、このプログラムに基づき、ユーザ属性取得処理が実行される。
【００６４】
ＣＰＵ４４は、ユーザ属性取得処理プログラムに基づき、ユーザ属性読み出し要求が与えられるか否か判断しており（図１１ステップＳ１１）、ユーザ属性読み出し要求が与えられると、許可ＵＲＩテーブルのリストに、そのコンテンツデータの配信元が存在するか否か判断する（ステップＳ１３）。この場合、ネットワークid"0001"、トランスポートストリームid”1001”、サービスid”1000”、イベントid”1100”で送信されており、図６に示すリストには、ＵＲＩ"arib-dc://0001.1001.1000.1100"が存在する。したがって、リストに存在するので、読み出し対象項目にデータが存在するか否か判断する（ステップＳ１５）。この場合、取得指示がなされたユーザ属性項目〔４〕には、図４に示すようにデータ「旅行」が存在するので、読み出してメモリ領域に書き込む（ステップＳ１７）。ＣＰＵ４４は、ＵＲＩ"arib-dc://0001.1001.1000.1100"について、ユーザ属性項目〔４〕が読み出されたことを履歴情報データテーブルに追加する（ステップＳ１９）。これにより、図５Ｂに示すように、履歴情報データテーブルにユーザ属性〔４〕およびそのＵＲＩが追加される。これにより、スクリプトによる処理を終了する。
【００６５】
ＣＰＵ４４は、ＢＭＬデータが最終行であるか否か判断する（図９ステップＳ９）。この場合、最終でないので、注目行を１行進めて（ステップＳ１０）、当該行がスクリプトであるか否か判断する（ステップＳ３）。この場合、行６６は、スクリプトであるので、かかるスクリプトによる処理を実行する。このスクリプトは、ユーザ属性〔４〕の項目のデータが、「旅行」であれば、ファイル”／００００／旅行.bml”を、「ワイン」であればファイル”／００００／ ワイン.bml”を、それ以外は、ファイル”／００００／デフォルト.bml”を表示するというスクリプトである。ＣＰＵ４４は、既に読み込み済みのユーザ属性〔４〕の項目のデータをメモリから読み出して、上記判断を行う。この場合、図１０に示すスクリプトのうち、条件  「a〔４〕＝＝”旅行”」と一致するので、同じパスに存在するファイル”／００００／旅行.bml”を表示対象として決定する。これにより、モニタには、図１２Ｂに示す表示がなされる。このようにして、ユーザ属性項目の記述を用いて表示を切り換えることにより、ユーザ属性に応じた画面をモニタに表示することができる。また、かかる利用実績を履歴として配信元情報とともに記憶することができる。
【００６６】
以下、図９ステップＳ９以下の処理が繰り返される。ＣＰＵ４４は、ＢＭＬデータを受け取るか否か判断しており（図９ステップＳ１）、スクリプトでなければ、ＢＭＬデータに基づき表示基礎データを出力する（ステップＳ７）。
【００６７】
なお、ステップＳ１５にて、許可ＵＲＩテーブルのリストに、そのコンテンツデータの配信元が存在しない場合に、ステップＳ１７，ステップＳ１９の処理を行うことなく、ユーザ属性取得処理を終了する。ステップＳ１３にて、ユーザ属性項目〔４〕に、何も記録されていない場合も同様である。これらの場合は、ユーザ属性取得処理は実行されない。したがって、図１０に示す行６６によって、ファイル”arib-dc://0001.1001.1000.1100.40/0000/デフォルト.bml”が表示対象として決定され、これにより、モニタに、図１２Ａに示す表示がなされる。
【００６８】
また、ユーザ属性テーブルのユーザ属性項目〔４〕に、データ「ワイン」が記憶されていた場合の表示について説明する。プログラムに基づいて、上記と同様にして、読み出された履歴情報データテーブルに項目およびＵＲＩが履歴情報データテーブルに追加される。この場合、図１０に示す行６６に基づいて、読み込み済みのユーザ属性〔４〕の項目のデータが、条件”a〔４〕＝＝”ワイン”と一致するので、ブラウザの表示をファイル”／００００／ワイン.bml”を表示するように切り換える。これにより、モニターに、図１２Ｃに示す表示がなされる。
【００６９】
このようにして、ユーザ属性項目の記述を参照にした表示切り換えが実行される。
【００７０】
(6)履歴を用いた課金処理
ユーザ端末は予めセットされたタイマー条件に基づいて、履歴情報送信処理を行う。かかる履歴情報送信処理について図１３を用いて説明する。
【００７１】
ユーザ端末のＣＰＵ４４は、予めセットされたタイマー条件と一致すると、課金サーバと通信を確立した後、端末証明書を課金サーバ１１に送信する（ステップＳ３１）。課金サーバ１１のＣＰＵ１４４は、これを受信して確認完了メッセージをユーザ端末に送信する（ステップＳ３３）。ユーザ端末は、履歴情報を送信する（ステップＳ３５）。上記の場合であれば、図５Ｂに示す履歴情報が送信される。課金サーバ１１は、これを記憶する（ステップＳ３７）。また、ユーザ端末は履歴情報を送信した後、送信した履歴情報を削除する（ステップＳ３９）。課金サーバとの通信を切断し（ステップＳ４１）、タイマーを再設定する（ステップＳ４３）。かかる処理を各ユーザ端末について実行することにより、課金サーバ１１には複数のユーザ端末において利用されたユーザ属性の実績が、ＵＲＩごとに記憶される。
【００７２】
課金サーバ１１のＣＰＵ１４４は、履歴ごとに利用料金を演算する（ステップＳ５１）。例えば、項目番号１については１円／１回、項目番号２については２円／１回、項目番号３については０．１円／１回、・・・というように、単価を決めておけばよい。かかる単価は情報配信者によって違っていてもよい。
【００７３】
課金サーバのＣＰＵ１４４は、テナントごとの総利用料を演算する（ステップＳ５３）。これは、課金サーバ１１のハードディスク１４６に記憶されたＵＲＩ・テナント変換テーブルを用いて、同じテナントの利用料金の総計を演算するようにすればよい。例えば、ＵＲＩ"arib-dc://0001.1001.1000.1100"は、テナントコード００１／０１０１のコンテンツ提供者であるので、かかるＵＲＩの履歴情報を総計すればよい。なお、図８において、テナントコード００１／０１０１のコンテンツ提供者が、他のＵＲＩについても記述されているのは、後述するインターネット経由または蓄積型でコンテンツ配信を行う場合があるからである。
【００７４】
つぎに、ＣＰＵ１４４は、各テナントに利用料金を請求する（ステップＳ５７）。例えば、e-mailで請求額を報知してもよく、ファクシミリ等を用いて送信するようにしてもよい。
【００７５】
このようにして、ユーザ属性の利用実績に応じた課金が可能となる。
【００７６】
(7)蓄積、インターネット配信する場合の実施形態
上記実施形態においては、コンテンツ配信をＢＳデジタル放送でリアルタイムで行う場合について説明したが、以下に説明するようにユーザ端末のハードディスクに蓄積を行った場合、またはインターネット経由で配信する場合についても、同様に適用することができる。
【００７７】
前記蓄積手法とは、放送局から送信されてきたコンテンツデータをユーザ端末に予め蓄積しておき、ユーザが蓄積されたデータを適宜読み出して、表示する方式である。かかるコンテンツ蓄積型の通信方法は、カルーセル方式でデータを転送する場合であっても、大量のデータを転送することができるので、商品やサービスの販売を行う仮想店舗などへの利用が提案されている。具体的には、図１に示すようなディレクトリ構成のファイルがあらかじめ送信され、受信装置はこれらのデータをハードディスクに記憶しておく。
【００７８】
ＢＭＬデータについては、通常と同様であり、リンク先のＢＭＬデータが存在するＵＲＩが記述されている。かかるコンテンツ蓄積の場合には、ＢＭＬファイルの指定が、前記ＢＳ放送の場合と異なり、ハードディスク４６，すなわち、ローカルディスクとなる。現在のＢＳデジタル放送規格では、"arib-file://" の後ろに、絶対パスで記述することにより、どの蓄積ファイルであるかを特定することができる。例えば、ファイル”arib-file://ec/tvshopping/shop2.bml”というように記述される。
【００７９】
なお、インターネットに接続されたコンテンツサーバからコンテンツデータを取得する場合には、そのＵＲＩとして、例えば、ＵＲＩ”http://www.panasonictvshop.co.jp/・・・・”とすればよい。当然、放送から蓄積へ、蓄積からインターネットへ、と任意にそれぞれのリンク先を記述しておくことにより、コンテンツデータの取得先を切り換えることもできる。
【００８０】
インターネットでコンテンツデータを配信する場合にも、同様に、複数の条件分岐を予めＨＴＭＬデータ中にスクリプトを記述しておけばよい。ただ、インターネット配信では、完全な双方向性（インタラクティブ）を有するので、ユーザ属性を一旦、コンテンツサーバに返信して、コンテンツサーバにて、かかるユーザ属性データを用いて、コンテンツデータを送信するようにしてもよい。この場合、ユーザ属性データがユーザ端末の外部に出力されるので、個人情報が漏れるおそれがある。そこで、かかる問題を解決するために、ユーザに外部に出力されることを報知し、許可が与えられた場合のみ、コンテンツサーバに返信するようにしてもよい。この場合、ブラウザプログラムとして図１５に示すプログラムを記憶しておけばよい。
【００８１】
ＣＰＵ４４は目的のコンテンツサーバにコンテンツデータ取得要求送信する（ステップＳ６１）。かかるコンテンツサーバから返信があるか否か判断しており（ステップＳ６３）、返信があると、スクリプトが存在するか否か判断する（ステップＳ６５）。ＣＰＵ４４は、読み込んだ行が、スクリプトでなければ、表示処理を行う（ステップＳ６７）。スクリプトである場合には、当該スクリプトがユーザ属性取得スクリプトであるか否か判断する（ステップＳ６９）。ＣＰＵ４４は、当該スクリプトがユーザ属性取得スクリプトでない場合には、当該スクリプトに基づく処理を実行する（ステップＳ７１）。
【００８２】
一方、当該スクリプトがユーザ属性取得スクリプトである場合には、ＣＰＵ４４は、許可ＵＲＩテーブルのリストに、そのコンテンツデータの配信元が存在するか否か判断する（ステップＳ７３）。図６に示すリストに存在する場合には、ＣＰＵ４４は読み出し対象項目にデータが存在するか否か判断する（ステップＳ７５）。
【００８３】
ＣＰＵ４４は、指定されたユーザ属性項目にデータが存在するか否か判断し（ステップＳ７７）、存在する場合には、「個人情報として、項目〔４〕趣味旅行の送信要求を受けました。送信してもよろしいですか？」と警告表示をするための画像データを出力する（ステップＳ７７）。ユーザはモニタに表示された警告を見て、許可する場合には許可指令を行う。ＣＰＵ４４は、許可指令があるか否か判断しており（ステップＳ７９）、許可指令があれば、読み出して当該ユーザ属性項目のデータを送信し（ステップＳ８１）、履歴情報データテーブルに追加する（ステップＳ８３）。コンテンツデータの最終行であるか否か判断し（ステップＳ８５）、最終行でなければ、注目行を次の行として（ステップＳ８６）、ステップＳ６５以下の処理を繰り返す。最終行であれば処理を終了する。
【００８４】
これにより、上記と同様に、履歴情報データテーブルに、ユーザ属性および送信したＵＲＩが追加される。かかるユーザ属性を受け取ったコンテンツサーバはこれに基づき、コンテンツデータを送信すればよい。
【００８５】
また、インターネット配信のように、ユーザ属性データが送信元に送られる場合であっても、ユーザ属性の利用実績を履歴として記憶することができる。
【００８６】
なお、ステップＳ７３，ステップＳ７７，ステップＳ７９にて、それぞれ
リストに存在しない場合、指定されたユーザ属性項目には、データが存在しない場合、許可指令が与えられない場合には、拒否メッセージを返信する（ステップＳ８７）。これにより、外部にユーザ属性データが無許可で配信されることを防止することができる。
【００８７】
特に、上記放送、蓄積、インターネットによるコンテンツ配信は、ユーザにとってみれば、どのように切り換えられているかは認識することができないので、いつの間にか、インターネット配信に切り替わっており、個人情報が無断で流出することを防止することができる。
【００８８】
(8)その他
上記実施形態においては、指定されたユーザ属性項目にデータが記録されていた場合に履歴として記録するようにしているので、利用実績に合致した課金が可能となる。ただ、これに限定されず、ユーザ属性項目の読み出し指令があった場合には、当該項目にデータが存在しない場合でも、履歴に記録する様にしてもよい。
【００８９】
また、指定されたユーザ属性項目にデータが記録されているが、結局、デフォルトの画面を使用する場合もある。例えば、趣味が”ゴルフ”である場合は”００００／ゴルフ用品.bml”を表示するスクリプトが受信したＢＭＬデータに記述されており、ユーザ端末には趣味”音楽鑑賞”と記録されている場合、当該ユーザ属性項目からデータは読み出しているが、結局趣味が記録されていない場合と同じ結果となる。かかる問題を防止するためには、例えば、項目”趣味”に記録できるものが候補として複数記憶されており、かかる候補から選択するようにすればよい。
【００９０】
上記実施形態では、オンラインショッピングの場合を例として示したが、これに限定されず、ユーザ属性データを用いて表示画面を切り換えることが好ましいものであれば、他のコンテンツについても同様に適用することができる。
【００９１】
上記実施形態においては、ユーザ属性項目の記述を用いて表示を切り換えるようにしたが、新たに生成するようにしてもよい。
【００９２】
また、上記実施形態においては、送信元特定情報として放送の場合には、ネットワークid、トランスポートストリームid、およびサービスidで、蓄積データおよびインターネット配信データについては、ＵＲＩを用いたが、送信元を特定できるものであればどのようなものであってもよく、コンテンツ配信サーバであれば、ＩＰアドレス等であってもよい。
【００９３】
また、許可ＵＲＩテーブルについては、課金サーバから変更できるようにしてもよい。また、変更するスクリプトを含む放送データを放送し、変更するようにしてもよい。
【００９４】
また、上記実施形態においては、ＢＳ衛星放送を受信するセットトップボックスを例に説明したが、ＣＳ衛星でもよく、さらに、地上波デジタル放送の場合も適用可能である。
【００９５】
さらに、ユーザ端末は、上記専用機でなくても、例えば、パソコン（携帯パソコンを含む）、ＰＤＡ、さらには、ブラウザ機能つき携帯電話などであってもよい。ハードディスクを有しない機器の場合には、ユーザ属性データ、履歴情報等については、フラッシュメモリ等の不揮発性メモリに記憶するようにすればよい。  本実施形態においては、図１に示す機能を実現する為に、ＣＰＵを用い、ソフトウェアによってこれを実現している。しかし、その一部もしくは全てを、ロジック回路等のハードウェアによって実現してもよい。
【００９６】
なお、プログラムの一部の処理をオペレーティングシステム（ＯＳ）にさせるようにしてもよい。
【００９７】
２．第２の実施形態
上記実施形態においては、モニタへ出力する表示基礎データを切り換える場合を例として説明したが、外部の装置を制御することも可能である。例えば、天気予報に基づき、ユーザの居住地域ごとにエアコンの制御を異ならせることができる。図１６を用いて、説明する。
【００９８】
コンテンツ提供者コンピュータ１１３は、本日の天気予報をコンテンツデータとして情報提供装置１１５に与える。このコンテンツデータには、ユーザ属性項目”２”（住所）を読み出すスクリプト、および”本日の夕方の予想気温が２８度を超える場合には、エアコンをオンにする”というスクリプトを天気予報情報に含有させておく。
【００９９】
情報提供装置１５は衛星を介して、当該コンテンツデータを放送する。ユーザ端末１２１ａ、１２１b,・・・１２１nは、かかるコンテンツデータを受信する。各ユーザ端末１２１ａ、１２１b,・・・１２１nは、コンテンツデータ中にユーザ属性を読み出すスクリプトが存在するか否か判断する。この場合存在するので、配信元がユーザ属性を利用する許可が与えられているか否かを許可ＵＲＩテーブルを参照して判断する。この場合、配信元が当該ユーザ属性を読み出す許可が与えられているとすると、ユーザ属性テーブルから”住所”を読み出す。つぎに、”本日の夕方の予想気温が２８度を超える場合には、エアコンをオンにする”というスクリプトが実行される。もし、ユーザ端末１２１aのユーザの地域がかかる条件を満たす場合には、エアコン１２２aをオン状態とする信号が生成され出力される。他のユーザ端末１２１b,・・・１２１nについても同様である。
【０１００】
また、各ユーザ端末１２１ａ、１２１b,・・・１２１nは、履歴情報データテーブルに、配信元特定ＩＤとともに読み出したユーザ属性”２”の項目を記憶する。この履歴データは課金サーバ１１１に送信される。課金サーバは、かかる履歴データを蓄積する。課金サーバ１１１は、複数のユーザ端末から送信された履歴データを用いて、コンテンツ提供者コンピュータ１１３のユーザ属性利用料を演算して、コンテンツ提供者コンピュータ１３に送信する。
【０１０１】
このように、１のコンテンツデータを放送するだけで、個々のユーザ特性情報に応じて、外部の制御対象機器を制御することが可能である。
【０１０２】
なお、かかる制御対象機器としては、例えば、電子レンジ、洗濯機等の家庭用電気機器はもちろん、工場の生産設備等についても同様に適用できる。
【０１０３】
３．第３の実施形態
上記実施形態においては、各情報配信元について、許可ＵＲＩテーブルがすでに存在する場合について説明したが、これをユーザが設定できるようにしてもよい。例えば、ユーザ特性項目設定モードへの切り換え指令が与えられると、図１７Ａに示すような画面を表示し、特定の情報配信元について、ユーザ情報を出力するか否かをユーザに入力させて、結果を許可ＵＲＩテーブルに記憶するようにすればよい。
【０１０４】
なお、図１７Ａに示す設定画面の表示時期については、特に限定されず、例えば、ユーザ情報の読み出し指令が与えられた場合であってもよい。
【０１０５】
また、図１７Ａにおいて、領域２０２が選択された場合には、図１７Ｂに示すような詳細設定画面を表示して、ユーザ特性項目ごとに許可・非許可を設定できるようにしてもよい。なお、かかる詳細設定画面の表示時期は、図１７Ａに示す設定画面のあとに特に限定されない。例えば、ユーザ特性項目の詳細設定モードへの切り換え指令がユーザから与えられた場合であってもよい。これにより、ユーザはいつでも、出力するユーザ特性項目を修正することができる。
【０１０６】
図１８に、詳細設定をした場合の許可ＵＲＩテーブルの一例を示す。このように、ユーザ特性情報の各項目ごとに、出力するか否かが記憶される。
【０１０７】
また、図１９に示すように、各情報配信元ごとに信頼度を記憶しておき、信頼度に応じて出力する項目を別途決めておき、出力する際に、かかる信頼度の評価に応じて所定の項目について出力するようにしてもよい。
【０１０８】
また、前記コンテンツサーバ（情報配信元）の信頼度をユーザに提示するようにしてもよい。これにより、信頼度に基づきユーザは前記許可テーブルを修正することができる。
【０１０９】
また、前記各情報配信元の信頼度は、情報配信装置によって予め決定しておくようすればよい。また、信頼度の評価をユーザ端末へ記憶するには、例えば、放送データ中に混在させてもよく、別途、通信部７を介して課金サーバ１１から送信するようにしてもよい。また、情報配信元のコンテンツサーバに記憶させておき、コンテンツサーバからユーザ端末に送信するようにしてもよい。
【０１１０】
また、図６，図１８に示す前記許可テーブルは、各情報配信元に関する信頼度に基づき自動生成するようにしてもよい。
４．他の実施形態
上記実施形態においては、ユーザ端末内の処理プログラムへ指定されたユーザ属性の項目データを出力するようにしたが、ユーザ端末内の指定された処理部に渡すようにしてもよい。
【０１１１】
また、上記実施形態においてはユーザ属性の項目データを処理するプログラムはコンテンツデータにスクリプトとして記述している場合について説明したが、処理プログラムはユーザ端末内に予め記憶しておくこともできる。
【０１１２】
また、上記実施形態においては、ユーザ属性データを用いてユーザ知覚データとして、画像データを生成する場合について説明したが、音データを生成することもできる。例えば、衛星放送におけるＢＧＭをユーザの趣味に応じた種類に切り換えることもできる。
【０１１３】
また、上記実施形態においては、ユーザ端末外にユーザ情報を出力する場合として、コンテンツデータ配信元に出力する場合について説明したが、制御対象機器に出力して、かかる機器が与えられたユーザ属性データを用いてデータ処理するようにしてもよい。また、制御対象機器以外でも、データ処理装置であれば同様にユーザ属性データまたはユーザ属性データによる処理データを活用することができる。
【０１１４】
上記実施形態においては、ユーザ属性データを読み出し可能か否かについて、全ての項目について許可か非許可かとしたが、項目ごとに設定できるようにしてもよい。例えば、あるコンテンツサーバは、項目”１”〜”４”のみ、とか、あるコンテンツ提供者は、項目”２"のみというように設定するようにしてもよい。
【図面の簡単な説明】
【図１】この発明の概要を示す図である。
【図２】送信装置の機能ブロック図である。
【図３】受信装置のハードウエア構成を示す図である。
【図４】ユーザ属性テーブルのデータ構造を示す図である。
【図５】履歴情報データテーブルを示す図である。
【図６】許可ＵＲＩテーブルを示す図である。
【図７】課金サーバのハードウエア構成を示す図である。
【図８】ＵＲＩ・テナント変換テーブルを示す図である。
【図９】ブラウザプログラムのフローチャートを示す図である。
【図１０】ユーザ属性取得のスクリプトの一例である。
【図１１】ユーザ属性取得スクリプトが与えられた場合の処理プログラムのフローチャートである。
【図１２】ユーザ属性を用いて切り換えられる画面の一例である。
【図１３】履歴を課金サーバに送信する処理を説明するフローチャートである。
【図１４】課金サーバが情報配信者に対して課金する処理を説明するフローチャートである。
【図１５】ユーザ属性を外部に送信する場合のフローチャートである。
【図１６】この発明の他の実施形態の概要を示すブロック図である。
【図１７】この発明の他の実施形態における設定画面の一例を示す図である。
【図１８】許可ＵＲＩテーブルの他のデータ構造を示す図である。
【図１９】許可ＵＲＩテーブルの他のデータ構造を示す図である。
【符号の説明】
１・・・ユーザ端末
３・・・制御部
９a・・・履歴情報データテーブル
９b・・・ユーザ属性テーブル
９c・・・許可・ＵＲＬテーブル
１１・・・課金サーバ
【図１】
0004160791.tif 000002
【図２】
0004160791.tif 000003
【図３】
0004160791.tif 000004
【図４】
0004160791.tif 000005
【図５】
0004160791.tif 000006
【図６】
0004160791.tif 000007
【図７】
0004160791.tif 000008
【図８】
0004160791.tif 000009
【図９】
0004160791.tif 000010
【図１０】
0004160791.tif 000011
【図１１】
0004160791.tif 000012
【図１２】
0004160791.tif 000013
【図１３】
0004160791.tif 000014
【図１４】
0004160791.tif 000015
【図１５】
0004160791.tif 000016
【図１６】
0004160791.tif 000017
【図１７】
0004160791.tif 000018
【図１８】
0004160791.tif 000019
【図１９】
0004160791.tif 000020