説明

放送システムにおいて放送コンテンツおよびスケジュールを決定する方法および装置

【課題】クライアントの要求で編成されたコンテンツを提供する放送システム、方法および装置。
【解決手段】放送システムは、複数のクライアントに向けてメタデータを放送するサーバを含み、該メタデータは、前記サーバによって放送されるか、放送される可能性のある複数のデータ・ファイルを記述する。各クライアントは、該メタデータを受信し、ローカルのメタデータ・テーブルならびにコンテンツ評価テーブルの更新および維持を行い、該クライアントが以前にアクセスしたデータ・ファイルおよびクライアントがオプションとして行った分類に基づいて、前記メタデータによって記述されたデータ・ファイルのそれぞれの評価をサーバに送り返す。その後、サーバは、クライアントから受信した評価に基づいて、データ・ファイルを放送するか否かの決定、および放送スケジュールの決定を行う。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概して放送システムに関し、より詳細に述べれば、本発明は放送システムにおいてオン・デマンドでコンテンツを提供することに関する。
【背景技術】
【0002】
放送システムは、伝統的に、サーバから複数のクライアント・システムにデータを一方向に送信している。クライアント・システムのユーザは、通常、サーバ・システムから信号が放送されるとき、それらを受信して使用する。ユーザにオン・デマンドでコンテンツが提供される1つのパラダイムは、同一のデータを連続的に、かつ/または部分的に間隔をずらして放送するサーバ・システムを必要とする。ユーザがオン・デマンドで特定のデータ・ファイルの利用を希望する場合には、そのユーザは、反復されるデータ・ファイルの放送の1つに「チャンネルを合わせる」。このパラダイムの一例を、ケーブルまたは衛星テレビジョン・プロバイダから提供される今日の「有料」ムービーに見ることができる。たとえば、ケーブル・テレビジョン・プロバイダは、一般に、複数のチャンネル上において同一のムービーを、部分的に間隔をずらして繰り返し放送している。特定のムービーの鑑賞を「オン・デマンド」で希望するユーザは、希望するムービーが放送される時間帯の1つの開始時に、そのムービーが放送されるチャンネルの1つに、単純にチャンネルを合わせる。同一データもしくはプログラムの連続的かつ反復的な放送は、放送帯域幅の非常に非効率的な使用をもたらす。複数チャンネル上における同一データの反復した放送に使用される帯域幅は、それを行わなければ別のデータの放送に使用することができる。
【0003】
放送システムにおけるオン・デマンドのコンテンツ提供に関する別のパラダイムでは、ユーザが特定のデータ・ファイルを記録し、その後そのデータ・ファイルに「オン・デマンド」でアクセスする。上記の説明のテレビジョン放送の場合であれば、このパラダイムの一例は、ユーザが、希望するテレビジョン・プログラムの録画を行うために各自のビデオ・カセット・レコーダ(VCR)をセットすることとなる。その後、そのユーザがテレビジョン・プログラムを「オン・デマンド」で見ることを希望するとき、そのユーザは、そのユーザのVCRから録画済みのプログラムを単純に再生する。近年、伝統的なVCRによって使用されるビデオ・カセット・テープに代えて内蔵ハード・ドライブ上にテレビジョン放送を録画する、より進んだディジタル・ビデオ録画装置が入手可能になった。しかしながら、ディジタル・ビデオ録画装置の使用は、内蔵ハード・ドライブ上にいずれの放送を録画するかということを決定するために使用されている基準(たとえば、日付、時刻)をユーザが明示的にセットする必要があるという点において伝統的なVCRと類似である。
【0004】
今日の放送システムに伴うもう1つの限界は、クライアント・システムのユーザのほとんどにとって、プログラムに関するフィードバックを放送者に提供することが困難なことである。たとえば、上記の説明のテレビジョン放送の場合であれば、今日のテレビジョン放送者の多くは、放送のプログラミングおよび/またはスケジューリングの決定をニールソン(Neilson)評価に頼っている。ニールソン(Neilson)評価は、概して社会の断面の小さなサンプリングのみを基礎としている。その結果、多くのテレビジョン視聴者は、放送スケジュールおよび/またはコンテンツに比較的わずかな影響力しか持たないか、あるいはまったく影響力を持たない。
【0005】
本発明は、限定の意味ではなく、例示の手段として添付図面に示されている。

【発明の概要】
【0006】
本発明の1つの側面においては、放送システム内のオン・デマンドでコンテンツを提供するためのシグナリング方法および装置が開示されている。本発明のもう1つの側面においては、サーバから放送されるか、あるいは放送される可能性のあるコンテンツを評価するための方法および装置が開示されている。本発明のさらに別の側面においては、サーバの放送するコンテンツおよび/またはスケジュールを動的に決定するための方法および装置が開示されている。以下の説明は、本発明の完全な理解を提供するために、多くの具体的な詳細を示している。しかしながら、当業者であれば、本発明の実施に、必ずしもこれらの具体的な詳細を採用する必要のないことを認識されよう。他方、周知の資料もしくは方法については、本発明の不明瞭化を避けるために詳細な説明を行っていない。
【図面の簡単な説明】
【0007】
【図1A】本発明の教示に従った放送システムの一実施形態を図示したブロック図である。
【図1B】本発明の教示に従った放送システムの別の実施形態を図示したブロック図である。
【図1C】本発明の教示に従った放送システムのさらに別の実施形態を図示したブロック図である。
【図2】本発明の教示に従ったクライアントまたはサーバを表すコンピュータ・システムの一実施形態を示したブロック図である。
【図3】本発明の教示に従ったメタデータおよびデータ・ファイルの放送時におけるサーバおよびクライアント内のイベントのフローの一実施形態を示したフローチャートである。
【図4】本発明の教示に従ったサーバから放送されるメタデータを処理し、メタデータ・テーブルならびにコンテンツ評価テーブルを処理するときの、クライアント内のイベントのフローの一実施形態を示したフローチャートである。
【図5】本発明の教示に従ってサーバにより放送される、記述するためのメタデータの一例を示した説明図である。
【図6】本発明の教示に従ってクライアントにより更新ならびに維持が行われるメタデータ・テーブルの一例を示した説明図である。
【図7】本発明の教示に従ってクライアントにより更新ならびに維持が行われるコンテンツ評価テーブルの一例を示した説明図である。
【図8】本発明の教示に従ってユーザにより分類が行われるデータ・ファイルの一実施形態を示した説明図である。
【図9】本発明の教示に従ってユーザの分類に応じて更新が行われるメタデータ・テーブルの一実施形態を示した説明図である。
【図10】本発明の教示に従ってユーザのアクセスの後に更新が行われるメタデータ・テーブルの一実施形態を示した説明図である。
【図11】本発明の教示に従ってユーザのアクセスの後に更新が行われるコンテンツ評価テーブルの一実施形態を示した説明図である。
【図12】本発明の教示に従ってユーザの別のアクセスの後に更新が行われるメタデータ・テーブルの別の実施形態を示した説明図である。
【図13】本発明の教示に従ったメタデータならびにデータ・ファイルの放送時、およびサーバがクライアント(1ないしは複数)から評価を受信するときのサーバおよびクライアント内のイベントのフローの一実施形態を示したフローチャートである。
【発明を実施するための形態】
【0008】
図1Aは、本発明の教示に従った放送システムの一実施形態を図示している。図示の実施形態に示されているように、サーバ103は、複数のクライアント105、107、109に向けて情報を放送するように構成されている。図1Aに示されている実施形態においては、クライアント105が、放送アンテナ111からのリンク115を介してサーバ103から放送を受信する。同様にクライアント107は、放送アンテナ111からのリンク117を介してサーバ103から放送を受信し、クライアント109は、リンク119を介してサーバ103から放送を受信する。一実施形態においては、リンク115、117、119は、放送アンテナからの一方向ワイヤレス無線周波数(RF)リンクであり、限定する意図ではないが、たとえば大気を介して放送が行われる周知の振幅変調(AM)もしくは周波数変調(FM)のラジオ信号、テレビジョン(TV)信号、ディジタル・ビデオ放送(DVB)信号等である。
【0009】
一実施形態においては、サーバ103は、クライアント105、107、109によって受信が可能な複数のデータ・ファイルを放送するように構成されている。一実施形態においては、これらのデータ・ファイルを、たとえばビデオ、オーディオ、グラフィック、テキスト、マルチメディア等を含む多数の異なるタイプのファイルの組み合わせとすることができる。説明を目的として、この開示において本発明の説明の補助として提供される例の多くは、サーバによって放送されるデータ・ファイルが、たとえば動きのあるイメージならびにサウンドを伴うムービー等のオーディオ/ビデオ・ファイルであることを前提としている。しかしながら、本発明の教示に従って放送されるデータ・ファイルが、オーディオ/ビデオ・ファイルのみに限定されないことを認識されるであろう。
【0010】
図1Aの実施形態に例示されているように、サーバ103とクライアント105、107、109の間には一方向または単方向リンクが存在する。しかしながら、別の実施形態においては、サーバ103と各クライアント105、107、109の間に、それぞれ通信リンクが備えられる可能性もあることが理解できるであろう。詳細には、図1Bに、各クライアント105、107、109とサーバ103の間の「裏チャネル」すなわち通信リンクの追加を伴う図1Aの放送システムを例示する。より詳細に述べれば、図1Bに例示した実施形態は、クライアント105、107、109がそれぞれ、サーバ103に情報を送り返すために使用することができるリンク121、123、125を示している。しかしながら、一実施形態においては、リンク121、123、125が、本発明の教示に従って使用されてはいない。後に論じるが、別の実施形態においては、リンク121、123、125が本発明の教示に従って使用される。図1Bには、クライアント105、107、109とサーバ103の間における直接リンクとしてリンク121、123、125が例示されているが、クライアント105、107、109が、限定する意図ではないが、たとえば放送ワイヤレス信号、ネットワーク通信等といった間接リンクを介してサーバ103に情報を伝達できることが理解できるであろう。
【0011】
図1Cは、本発明の教示に従った放送システムのさらに別の実施形態を例示している。これに示されているように、サーバ103は、ネットワーク113を介して複数のクライアント105、107、109に情報の放送を行うように結合されている。一実施形態においては、ネットワーク113を、限定する意図ではないが、たとえばインターネット、ワイド・エリア・ネットワーク(WAN)、ローカル・エリア・ネットワーク(LAN)、イントラネット等の、複数の異なるデバイスが通信を行うことができる任意のタイプの通信ネットワークとすることができる。
【0012】
図1Cに例示されている実施形態においては、クライアント105は、リンク115を介してサーバ103から放送される情報を受信するように結合されている。同様にクライアント107がリンク117を介してサーバ103から放送される情報を受信するように結合されており、クライアント109がリンク119を介してサーバ103から放送される情報を受信するように結合されている。ここで気づかれようが、図1Cに例示されている実施形態においてはリンク115、117、119が、ネットワーク113からクライアント105、107、109に向かう単方向リンクとして示されている。別の実施形態においては、リンク115、117、119が双方向リンクであり、クライアント105、107、109からサーバ103に対して情報を伝達することが可能になる。
【0013】
図2は、本発明の教示に従ってサーバ103、またはクライアント105、107、もしくは109に使用することができるマシン201の一実施形態を例示したブロック図である。一実施形態においてマシン201は、コンピュータまたはセットトップ・ボックスであり、バス207に結合されたプロセッサ203を備える。一実施形態においては、メモリ205、ストレージ211、ディスプレイ・コントローラ209、通信インターフェース213、入力/出力コントローラ215、およびオーディオ・コントローラ227もまたバス207に結合されている。
【0014】
一実施形態においては、マシン201が通信インターフェース213を介して外部システムとインターフェースする。通信インターフェース213は、AM、FM、TV、ディジタルTV、DVB、ワイヤレス電話信号、あるいはこれらに類似のものと互換性のある無線トランシーバなどを含んでいる。また通信インターフェース213は、アナログ・モデム、総合ディジタル通信サービス・ネットワーク(ISDN)モデム、ケーブル・モデム、ディジタル加入者回線(DSL)モデム、T−1ライン・インターフェース、T−3ライン・インターフェース、光搬送波インターフェース(たとえばOC−3)、トークン・リング・インターフェース、衛星送信インターフェース、ワイヤレス・インターフェースあるいはそのほかの1つのデバイスと別のデバイスを結合するためのインターフェースを備えることもできる。
【0015】
一実施形態においては、搬送波信号223が通信インターフェース213によって受信され、放送アンテナ111との通信が行われる。一実施形態においては、通信インターフェース213とネットワーク113の間において搬送波信号225の受信/送信が行われる。一実施形態においては、マシン201と別のコンピュータ・システム、ネットワーク・ハブ、ルータ等とのインターフェースに通信信号225が使用されることもある。一実施形態においては、搬送波信号223および225がマシン可読メディアであると考えられ、ワイヤ、ケーブル、光ファイバまたは空中等を介してそれを送信することができる。
【0016】
一実施形態においては、プロセッサ203を、限定を意図するわけではないが、たとえばIntel x86(インテルx86)またはPentium(ペンティアム)ファミリ・マイクロプロセッサ、Motorola(モトローラ)ファミリ・マイクロプロセッサといった従来のマイクロプロセッサとすることができる。メモリ205は、ダイナミック・ランダム・アクセス・メモリ(DRAM)等のマシン可読メディアとすることが可能であり、スタティック・ランダム・アクセス・メモリ(SRAM)を備えることもある。ディスプレイ・コントローラ209は、従来の形態に従ってディスプレイ219をコントロールし、一実施形態においてはそれを陰極線管(CRT)、液晶ディスプレイ(LCD)、アクティブ・マトリクス・ディスプレイ、テレビジョン・モニタ等とすることができる。入力/出力コントローラ215に結合されている入力/出力デバイス217は、キーボード、ディスク・ドライブ、プリンタ、スキャナ、およびそのほかの、テレビジョン・リモート・コントローラ、マウス、トラックボール、ジョイスティック等を含めた入力および出力デバイスとすることができる。一実施形態においては、オーディオ・コントローラ227が、従来の形態に従ってオーディオ出力231をコントロールする。それには、たとえばオーディオ・スピーカ、ヘッドフォン、オーディオ・レシーバ、増幅器等を含めることができる。一実施形態においては、コントローラが、従来の形態に従ってオーディオ入力229のコントロールも行い、それには、たとえばマイクロフォンまたはオーディオもしくはミュージック・デバイス等からの入力を含めることができる。
【0017】
一実施形態におけるストレージ211は、限定する意図ではないが、磁気ハードディスク、フロッピーディスク、光ディスク、スマート・カード、あるいはそのほかの形式のデータ用ストレージ等のマシン可読メディアを備えることができる。一実施形態においては、ストレージ211が、リムーバブル・メディア、読み出し専用メディア、読み出し/書き込み可能メディア等を備えることもある。データの一部は、コンピュータ・システム201におけるソフトウエアの実行間に、ダイレクト・メモリ・アクセス(DMA)プロセスによってメモリ205内に書き込まれることもある。ここで認識されることであるが、ソフトウエアは、ストレージ211もしくはメモリ205内に常駐することもあり、またモデムもしくは通信インターフェース213を介して送信または受信されることもある。なお、この明細書の目的から、「マシン可読メディア」という用語は、データ、情報、プロセッサ203による実行のためのインストラクションのエンコードしたシーケンスをストアし、プロセッサ203に本発明の方法を実行させることができる任意のメディアを含むものと解釈するべきである。また「マシン可読メディア」という用語は、限定を意図するわけではないが、ソリッド・ステート・メモリ、光および磁気ディスク、搬送波信号等を含むものと解釈するべきである。
【0018】
一実施形態における、たとえば図1A〜1Cのいずれかに示されているものに類似の放送システムは、複数のクライアント105、107、109に向けた複数のデータ・ファイルの放送をサーバ103に行わせるように構成されている。以下に詳細を述べるように、複数のデータ・ファイルのそれぞれは、本発明の一実施形態の教示に従ってメタデータを用いて記述されている。概してメタデータは、記述子のセット、つまりサーバ103から放送され、もしくは放送される可能性のあるデータ・ファイルのコンテンツを記述する属性値のセットとして考えることができる。本発明のメタデータは、サーバ103によって後に放送されることになるデータ・ファイルのコンテンツに関して、クライアント105、107、109が推理し、かつ情報に基づく決定を行うことを可能にする情報を提供する。後に論じるように、本発明の各種実施形態は、クライアント側におけるフィルタリング、ストレージ・マネジメント、およびそのほかのパーソナル化テクニックをはじめ、サーバによる将来の放送スケジュールならびに放送のコンテンツを決定するためにメタデータを使用する。
【0019】
図3は、本発明の一実施形態の教示に従って実行されるプロセスを例示したフローチャートである。図3は、クライアント・システムが放送コンテンツを突き止めて、その取り込みができるように信号が送信されるシグナリング・プロトコルの一実施形態を例示している。これは、サーバ103によるクライアント・システム105、107、109に対するメタデータのプレ放送を含む。詳細に述べれば、図3のプロセス・ブロック303は、サーバがメタデータ放送スケジュールをクライアントに向けて放送することを示している。一実施形態においては、メタデータ放送スケジュールは、本発明の実際のメタデータがサーバによって放送される将来の時点を示す。一実施形態においては、クライアント・システムが、たとえばプログラムおよびシステム情報プロトコル(program and system information protocol:PSIP)、DVB、サービス広告プロトコル(service advertising protocol:SAP)等に使用されるポートのような既知のポートを使用してサーバから到来するサービスのアナウンスの視聴を行う。
【0020】
一実施形態においては、各クライアント105、107、109は、周知のスケジューリング・サービス、すなわち特定の時刻におけるウェイクアップもしくはアクティブ化の要求を受け入れて、サーバによって放送される情報を受信するスケジューリング・サービスを含む。このスケジューリング・サービスによって、クライアントは指定時刻にウェイクアップし、指定のサービスを選択する。たとえば、一実施形態においては、この選択プロセスを、たとえば先進テレビジョン・システム委員会(Advanced Television System Committee)またはDVBトランスポンダ等の場合のように、特定の周波数への同調によって達成することができる。一実施形態においては、この選択プロセスは、たとえばマルチキャスト・インターネット・プロトコル(IP)アドレス等のサーバを明確に示すデータのセットを基礎とすることができる。
【0021】
一実施形態においては、クライアント・アプリケーションが、特定のコンテンツ・プロバイダから信号を受信するために、クライアント・シグナリング・システムへの登録を行う。クライアント・シグナリング・システムは、特定のコンテンツ・プロバイダに関連づけられているアプリケーションのテーブルを維持している。一実施形態においては、各クライアントが既知のアドレスを使用できるように既知のアドレスにサーバからの情報が放送される。
【0022】
プロセス・ブロック305は、クライアントがサーバからメタデータ放送スケジュールを受信することを示している。一実施形態においては、クライアント105、107、109が、このプレ放送の情報の取り込みならびに処理を行って、いつウェイクアップしてコンテンツを受信するか、どこでそのコンテンツを受信するか、さらにいずれのコンテンツを受信するかについて決定する。一実施形態においては、メタデータ放送スケジュールがクライアントによって受信されたとき、クライアント内の登録済みアプリケーションに、メタデータ放送スケジュールを受信するように通知が行われる。
【0023】
一実施形態においては、メタデータ放送スケジュール内に示された指定の時刻にクライアントがウェイクアップし、サーバからメタデータを受信する。プロセス・ブロック307は、その後、メタデータ放送スケジュール内に指定された時刻において、実際にサーバからクライアントに向けてメタデータが放送されることを示している。プロセス・ブロック309は、クライアントがサーバからのメタデータの放送を受信することを示している。以下においても論じるが、メタデータは、サーバ・システムによって後に放送されるか、放送される可能性のある複数のデータ・ファイルの記述を含んでいる。
【0024】
プロセス・ブロック311は、続いてクライアント・システムがメタデータ・テーブルならびにコンテンツ評価テーブル(content rating table)を更新することを示している。一実施形態においては、メタデータ・テーブルならびにコンテンツ評価テーブルが、各クライアント・システムにより本発明の教示に従って内部的に、またはローカルに更新され、維持される。
【0025】
一実施形態においては、クライアント・システムのユーザが、受信したメタデータによって記述されている複数のデータ・ファイルの1ないしは複数の分類をオプションとして行うことができる。以下に論じるが、メタデータ・テーブルならびにコンテンツ評価テーブルは、ユーザの分類が行われると、クライアントによって更新される。図3においてはこれが、プロセス・ブロック313として示されている。
【0026】
一実施形態においては、クライアントがウェイクアップして、サーバからデータ・ファイル放送スケジュールを受信する。一実施形態においては、このデータ・ファイル放送スケジュールが、前もって放送済みのメタデータ内に記述されている特定のデータ・ファイルがサーバによって放送される将来の時刻を示す。プロセス・ブロック315は、その後、データ・ファイル放送スケジュール内に指定された時刻に、サーバからクライアントに向けて実際にそのデータ・ファイルが放送されることを示している。プロセス・ブロック317は、クライアントがデータ・ファイル放送スケジュールの放送をサーバから受信することを示している。
【0027】
一実施形態においては、データ・ファイル放送スケジュール内に示された、あらかじめ指定された時刻にクライアントがウェイクアップし、サーバからデータ・ファイルを受信する。プロセス・ブロック319は、その後、データ・ファイル放送スケジュール内に指定された時刻において、実際にサーバからクライアントに向けてデータ・ファイルが放送されることを示している。
【0028】
一実施形態においては、プロセス・ブロック321が、サーバから放送されたデータ・ファイルをクライアントが受信することを示す。一実施形態においては、プロセス・ブロック323に示されるように、本発明に従ったクライアント側フィルタリングが、コンテンツ評価テーブルに従って選択的にデータ・ファイルをストアするクライアントによって行われる。別の実施形態においては、クライアント側フィルタリングがコンテンツ評価テーブルに従って選択的にウェイクアップするクライアントによって行われ、サーバから放送されるデータ・ファイルを選択的に受信する。この実施形態においては、その後クライアントが、コンテンツ評価テーブルに従ってクライアントが選択的に受信したデータ・ファイルをストアする。
【0029】
一実施形態においては、プロセス・ブロック325が、その後ストア済みデータ・ファイルに対するユーザ・アクセスがあった場合に、クライアントがメタデータ・テーブルならびにコンテンツ評価テーブルを更新することを示す。この開示の目的から、ユーザ・アクセスには、ユーザが行うデータ・ファイルとのインタラクション、データ・ファイルを眺める、見る、聞く、読む、使うといった行為を含めることができる。たとえば、ユーザが行うデータ・ファイルへのアクセスの一例を、クライアント内のストア済みデータ・ファイルの1つによって提供される特定のムービーをユーザが鑑賞すること、もしくは特定の歌を聴くこととすることができる。一実施形態においては、ユーザ・アクセスによってクライアント上のメタデータ・テーブルならびにコンテンツ評価テーブルのローカルな更新がもたらされることになる。
【0030】
図4は、本発明の教示に従ってサーバからのメタデータ放送を処理し、メタデータ・テーブルならびにコンテンツ評価テーブルの更新ならびに維持を行うときのクライアント内におけるイベントのフローの一実施形態をより詳細に示したフローチャートである。詳細に述べれば、プロセス・ブロック403は、サーバから放送されたメタデータ内に含まれている属性ならびに属性値を用いてメタデータ・テーブルが更新されることを表している。プロセス・ブロック405は、続いてコンテンツ評価テーブルが、サーバから放送されたメタデータによって記述されるデータ・ファイルのそれぞれに関するエントリを用いて更新されることを表している。
【0031】
一実施形態においては、メタデータ・テーブル、コンテンツ評価テーブル、および複数のデータ・ファイルが、すでにクライアント・システム内に存在しているものとする。一実施形態においては、メタデータ・テーブル、コンテンツ評価テーブル、および複数のデータ・ファイルが、クライアント・システムのメモリ205内、ストレージ211内にストアされ、維持されるものとしてもよく、あるいはそれを、図2の実施形態に例示されているような、マシン201を伴うローカル・ネットワーク等に対するアクセスによるものとすることができる。
【0032】
本発明のメタデータの側面の例示を容易にするため、図5を、サーバ103がクライアント105、107、109に向けて放送することができるメタデータ501の実施形態の一例とする。説明を目的として、この例においてサーバ103によって放送されるデータ・ファイルが、たとえばムービーまたはTVプログラムのようなオーディオ/ビデオ・ファイルであると仮定する。前述したように、限定する意図ではないが、データ・ファイルを、たとえばオーディオ、グラフィック、テキスト、マルチメディアといったそのほかのタイプのファイルとしてもよい。
【0033】
図5のメタデータ501は、4つのムービーまたはデータ・ファイルが、サーバ103から放送される予定であることを示している。この例に示されているこれらのムービーは、「Action Dude(アクション・デュード)」、「The Funny Show(ザ・ファニー・ショー)」、「Blast ’Em(ブラスト・ゼム)」および「Hardy Har Har(ハーディ・ハー・ハー)」である。メタデータ501は、サーバ103によってその後に放送される予定のムービーのそれぞれを記述する属性ならびに属性値を含む。図示の例においては、メタデータ501内の各ムービーを記述する2つの属性が提供されている。図5に示した属性は「俳優」および「ジャンル」である。ここで認識されようが、本発明の別の実施形態においては別の属性をはじめ別の属性値が含まれることもある。たとえば、網羅的な意味ではないが、ムービーの説明に使用可能なこのほかの属性のリストに「監督」、「制作年」、「効果」、「結末」等を含めることができる。一実施形態においては、本発明の教示に従って、たとえば40〜50の異なる属性がムービーの説明のために提供される。
【0034】
図5に示されている特定の実施形態に戻るが、「Action Dude(アクション・デュード)」は、俳優「Joe Smith(ジョー・スミス)」が主演する「アクション」ムービーである。「The Funny Show(ザ・ファニー・ショー)」は、女優「Jane Doe(ジェーン・ドウ)」が主演する「コメディ」ムービーである。「Blast ’Em(ブラスト・ゼム)」は、女優「Jane Doe(ジェーン・ドウ)」が主演する「アクション」ムービーである。「Hardy Har Har(ハーディ・ハー・ハー)」は、俳優「Joe Smith(ジョー・スミス)」が主演する「コメディ」ムービーである。
【0035】
本発明のメタデータ・テーブルの態様を説明するための図6は、各クライアント105、107、109によってローカルに更新ならびに維持が行われるメタデータ・テーブル601の実施形態の一例である。例示の実施形態においては、図6のメタデータ・テーブル601内に、サーバ103からすでに放送されたメタデータ501内に含まれていたデータが収められている。一実施形態においては、メタデータ・テーブル601が属性、属性値、および対応する関連値ならびに信頼性係数のリストを含んでいる。詳細に述べれば、メタデータ・テーブル601は、属性値「Joe Smith(ジョー・スミス)」、「Jane Doe(ジェーン・ドウ)」、「アクション」、および「コメディ」を含む。この時点においては、図6の、属性値「Joe Smith(ジョー・スミス)」、「Jane Doe(ジェーン・ドウ)」、「アクション」、および「コメディ」に関する関連値ならびに信頼性係数がすべてゼロである。以下に示すように、一実施形態においては、ユーザがクライアント・システムとインタラクションを行うと、本発明の関連値ならびに信頼性係数が更新され、維持される。
【0036】
一実施形態においては、メタデータ・テーブル601内の関連値が、関連づけされた属性ならびに属性値が、特定のユーザの振る舞いを予測する上でどの程度関連するかということを示すインジケータになる。たとえば、関連値は、ユーザがその特定の属性値を理由として特定のムービーを見る可能性がどの程度であるかについて示す。一実施形態においては、メタデータ・テーブル601内の関連値が、たとえば−10から10までの範囲内の値になる。以下に述べるように、たとえばユーザが特定のムービーを見た場合、あるいは少なくともその特定の属性値を有する特定のムービーに関心を示した場合には、関連値を増加させることができる。その逆に、たとえばユーザが特定のムービーを見なかった場合、あるいはユーザが、その特定の属性値を有する特定のムービーを見ることを、そのユーザ自身が欲していない旨を明示的に示した場合には、関連値を減少させることになろう。
【0037】
一実施形態においては、メタデータ・テーブル601内の信頼性係数が、その特定の属性値を有する特定のデータ・ファイルにユーザが実際にアクセスするか否かの評価または予測を行う場合に、特定の属性および属性値のペアに適用される重み付け係数になる。一実施形態においては、メタデータ・テーブル601内の信頼性係数がたとえば−10から10までの範囲内の値になる。一実施形態においては、たとえば属性値によって、ユーザが関心を示したデータ・ファイルが正確に予測された場合に、信頼性係数を増加させることができる。逆に、特定の属性値が異なる内容を示しているにもかかわらず、ユーザがそのデータ・ファイルに関心を持った場合には、その信頼性係数を減少させてもよい。
【0038】
一実施形態においては、メタデータ・テーブル601内のエントリがサーバ103から放送される可能性のあるコンテンツもしくはデータ・ファイルに関連づけされたすべてのメタデータ501から構成される。一実施形態においては、メタデータ・テーブル601内のエントリが、ユーザの明示的な要求に基づいて更新される。それに加えて、メタデータ・テーブル601に対する更新を、ユーザが特定のムービーを明示的に分類するか否かによらず、特定の属性値を有する特定のデータ・ファイルにアクセスするか否かに基づいて暗黙的に行うこともできる。
【0039】
本発明のメタデータの態様を説明するための図7は、一実施形態において各クライアント105、107、109によってローカルに更新ならびに維持が行われるコンテンツ評価テーブル701の実施形態の一例である。例示の実施形態においては、図7のコンテンツ評価テーブル701が、メタデータ501内に記述されているデータ・ファイルのリストをはじめ、現在、クライアントによってローカルにストアもしくはキャッシュが行われている追加のデータ・ファイルのリストを含む。
【0040】
一実施形態においては、データ・ファイルが、たとえば図2のメモリ205、ストレージ211、またはマシン201によるローカルなアクセスが可能なネットワーク内にクライアントによってローカルにストアされる。開示を目的として、クライアントによってローカルにストアされるデータ・ファイルを、サーバから独立した周知のネットワーク・ストレージ構成内にクライアントによって「ローカルに」ストアされるデータ・ファイルを含むものと解釈することもできる。この開示の目的から、クライアントによってストアもしくはキャッシュされるデータ・ファイルは、その後のアクセス、取り出しもしくは使用のためにストアされるものとする。一実施形態においては、本発明のローカル・キャッシュが第1レベルのキャッシュであると見なされる。したがって、本発明のローカル・キャッシュは、それに応じてサイズ設定が行われて、単一ヒットの確率を向上させることができる。
【0041】
オーディオ/ビデオ・ファイルを表すデータ・ファイルの例に戻るが、クライアントによってムービーがローカルにストアされる。ユーザがムービーを見た後は、そのムービーによって占められていたストレージ・スペースは、その後の任意の時点に放送される別のムービーのストアに使用可能になると一般に考えられる。つまり、ここで認識されることは、クライアント・システムのローカル・キャッシュが、本発明の教示に従い、単一使用システムとして、たとえばファイア・アンド・フォゲット(fire and forget)としてモデリングされることである。一実施形態においては、ユーザがデータ・ファイルにアクセスするとき、そのユーザが同一のデータ・ファイルに再度アクセスを希望する可能性は低いと仮定する。ユーザが特定のムービーをまだ見ていない場合には、そのムービーによって占有されるストレージ・スペースは、一般には別のムービーのストアに使用できない。しかしながら、使用可能な追加のストレージ・スペースがなく、より高い評価のムービーの放送がある場合には、本発明の教示に従って、まだ見られていないが評価のより低いムービーが、より高い評価のムービーに置き換えられる。
【0042】
図7に戻って、それに示したコンテンツ評価テーブル701の実施形態を参照するが、各ムービーは、関連づけされた評価、評価タイプ・インジケータ、キャッシュ内インジケータ、次処理インジケータも含んでいる。一実施形態においては、この評価が、関連づけされたデータ・ファイルに関する評価値を示す。一実施形態における評価値は、ユーザによって明示的に入力されるか、クライアント・システムによってその特定のデータ・ファイルに関連づけされたメタデータが処理されることにより暗黙的に生成される。一実施形態においては、評価値が比較的高いとき、その特定のデータ・ファイルにユーザが関心を示す可能性のあることが予測される。その逆に、一実施形態においては、評価値が比較的低いとき、その特定のデータ・ファイルにユーザが関心を示す可能性が低いことが予測される。
【0043】
一実施形態においては、評価タイプ・インジケータが、この特定のデータ・ファイルの評価値がユーザによって明示的に入力されたものであるか、あるいはその評価値がクライアント・システムによって暗黙的に生成されたものであるかを示す。つまり、一実施形態においては、コンテンツ評価テーブル701の評価タイプ・インジケータが明示、暗黙、もしくはデータ・ファイルまたはムービーの評価がまだ行われていなければ、そのいずれでもないことを示すN/Aになる。一実施形態においては、ユーザによってデータ・ファイルが明示的に分類されていれば、それ以降、データ・ファイルの属性値の評価値が、クライアント・システムによって暗黙的に更新されることはない。しかしながらデータ・ファイルが分類されていないか、クライアント・システムによる暗黙的な評価だけが行われている場合には、それ以降においても、データ・ファイルの属性値の評価が、クライアント・システムによって更新もしくは調整されることがある。
【0044】
一実施形態においては、キャッシュ内インジケータが、その特定のデータ・ファイルが現在、クライアントによってローカルにストアもしくはキャッシュされているか否かを示す。図7に例示した実施形態においては、ムービー「Action Dude(アクション・デュード)」、「The Funny Show(ザ・ファニー・ショー)」、および「Blast ’Em(ブラスト・ゼム)」が、すでにクライアント・システムのローカル・ストレージ内に存在する。これに対して、図7に例示した例においては、ムービー「Hardy Har Har(ハーディ・ハー・ハー)」がまだクライアント・システムのローカル・ストレージ内にストアされていない。
【0045】
一実施形態においては、次処理インジケータが特定のデータ・ファイルに関してとられるべき将来のアクションを追跡するために使用される。たとえば、ユーザがムービーをすでに見ている場合には、次処理インジケータが「置き換え」となり、その特定のムービーによって占有されているストレージ・スペースが別のムービーのストレージとして使用可能であることを示す。一実施形態においては、ユーザがまだそのムービーを見ていない場合には、次処理インジケータが「保存」を示すことになる。一実施形態においては、クライアントによってまだそのムービーがローカルにストアされてなく、その特定のムービーにユーザが関心を示す可能性のあることが評価値によって予測される場合には、次処理インジケータが「取り込み」を示すことになる。一実施形態においては、サーバによってムービーがまだ放送されてなく、そのムービーにユーザが関心を示す可能性が低いことが評価値によって予測される場合には、次処理インジケータが「無視」を示すことになる。
【0046】
図4に戻るが、すでに説明したようにプロセス・ブロック403および405は、メタデータ・テーブルおよびコンテンツ評価テーブルが、サーバからのメタデータ放送に従って更新されることを示している。判断ブロック407は、続いてデータ・ファイルのいずれかに対するユーザによる分類の有無を判断する。ここで簡単に図8を参照するが、この例は、メタデータ501に関して説明したように、ユーザがいくつかのムービーに分類を行ったところを示している。より詳細に述べれば、ユーザは、ムービー「Action Dude(アクション・デュード)」の受信を希望する旨を示すことによってそのムービーに対する関心を示す。この例においては、ユーザが、ムービー「The Funny Show(ザ・ファニー・ショー)」に拒否を示すことによってそのムービーに関心がまったくないことを示している。この例においては、ユーザが、残りのムービーに関する情報もしくは分類をまだ与えていない。
【0047】
図4に戻るが、ユーザがデータ・ファイルのいずれかの分類を行っている場合には、プロセス・ブロック409が示すように、メタデータ・テーブル601内の分類済みデータ・ファイルの、その特定の属性の関連値が増加される。プロセス・ブロック411は、ユーザによる分類(1ないしは複数)に応答して調整された関連値を伴う属性値を有するデータ・ファイルの評価も調整されることを示している。一実施形態においては、ユーザがまだいずれのデータ・ファイルの分類も行っていないとき、プロセス・ブロック409および411がスキップされる。
【0048】
ユーザがデータ・ファイルの分類を行うときの例を示すために、図9に、ユーザの分類によって更新もしくは調整が行われるメタデータ・テーブル601を示した。図8に示した例において、ユーザは、ムービー「Action Dude(アクション・デュード)」に関心を示している。また図5のメタデータ501は、「Action Dude(アクション・デュード)」が俳優「Joe Smith(ジョー・スミス)」の主演する「アクション」ムービーであることを示している。したがって、図9のメタデータ・テーブル601を参照すると、属性値「Joe Smith(ジョー・スミス)」および「アクション」に関する関連値が調整されて、ユーザが明示的に「Action Dude(アクション・デュード)」に関心を示したことが反映されている。一実施形態においては、関連値を増加してユーザが感心を示したことを反映する。以下に論じるように、一実施形態においては、その特定の属性値を有するデータ・ファイルにユーザがアクセスするまで、各属性値に関連づけされている信頼性係数が更新されない。
【0049】
引き続き図8の例を参照すると、ユーザは、ムービー「The Funny Show(ザ・ファニー・ショー)」に関心がないことを示している。また図5のメタデータ501は、「The Funny Show(ザ・ファニー・ショー)」が女優「Jane Doe(ジェーン・ドウ)」の主演する「コメディ」ムービーであることを示している。したがって、図9に戻ってメタデータ・テーブル601を参照すると、属性値「Jane Doe(ジェーン・ドウ)」および「コメディ」に関する関連値が調整されて、ユーザが「The Funny Show(ザ・ファニー・ショー)」に関心がないと明示的に示したことが反映されている。一実施形態においては、関連値を減少してユーザの感心がないことを反映する。
【0050】
引き続き図8の例を参照すると、ユーザは、ムービー「Blast ’Em(ブラスト・ゼム)」および「Hardy Har Har(ハーディ・ハー・ハー)」に関する情報をまだ提供していない。したがって、メタデータ・テーブル601内の「Blast ’Em(ブラスト・ゼム)」および「Hardy Har Har(ハーディ・ハー・ハー)」に関連づけされた属性値の関連値は更新されない。
【0051】
以下に論じるように、一実施形態においては、コンテンツ評価テーブル701内の評価に対する更新が、プロセス・ブロック411内に示されるように、メタデータ・テーブル601内にリストされている属性値の関連値ならびに信頼性係数に関係する。プロセス・ブロック411内において行われる処理の詳細な説明については、以下のプロセス・ブロック417の説明の中で述べる。
【0052】
図4に戻るが、ユーザがいずれかのデータ・ファイルにアクセスすると、たとえばユーザがムービーを見ると、判断ブロック413においてそれが判断され、プロセス・ブロック415に示されるように、メタデータ・テーブル601内のユーザがアクセスしたデータ・ファイルの、特定の属性の関連値ならびに信頼性係数が更新される。プロセス・ブロック417は、ユーザのアクセス(1ないしは複数)に応答して調整された関連値を伴う属性値を有するデータ・ファイルの評価も調整されることを示している。ユーザがまだ、いずれのデータ・ファイルにもアクセスしていなければプロセス・ブロック415および417がスキップされる。
【0053】
ユーザがデータ・ファイルへのアクセスを行うときの例を示すために、ユーザがムービー「Action Dude(アクション・デュード)」を見るものと仮定する。図5のメタデータ501は、「Action Dude(アクション・デュード)」が俳優「Joe Smith(ジョー・スミス)」の主演する「アクション」ムービーであることを示している。一実施形態においては、ユーザが特定のデータ・ファイルにアクセスするか、関心を示すと、そのファイルの属性値の信頼性係数が調整もしくは更新される。一実施形態においては、属性値がゼロより大きい関連値を有する場合に、その属性値が、ユーザがアクセスするデータ・ファイルを予測した予測子として正確に機能したことから、その属性値に関する信頼性係数が増加される。一実施形態においては、属性値がゼロより小さい関連値を有する場合に、その属性値は、ユーザがアクセスするデータ・ファイルを予測した予測子として正確に機能しなかったことから、その属性値に関する信頼性係数が減少される。したがって、図10に示されるように、ユーザの「Action Dude(アクション・デュード)」へのアクセスに応答してメタデータ・テーブル601の更新もしくは調整が行われる。この例においては、「Joe Smith(ジョー・スミス)」および「アクション」の属性値がゼロより大きいことから、それらの信頼性係数が増加される。
【0054】
一実施形態においては、メタデータ・テーブル601内の暗黙的に評価されたデータ・ファイルに関連づけされた関連値も、ユーザのアクセスに応答して増加される。しかしながら、図10のメタデータ・テーブル601内に示される例においては、「Action Dude(アクション・デュード)」がユーザによって明示的に分類されている。一実施形態においては、ユーザにより明示的に分類されたデータ・ファイルに対して、ユーザのアクセスに応答したメタデータ・テーブル601内の関連値の更新は行われない。
【0055】
図11は、コンテンツ評価テーブル701を示しており、プロセス・ブロック417に示されているように、「Action Dude(アクション・デュード)」に対するユーザのアクセスに応答してそれが更新される。すでに述べたように、コンテンツ評価テーブル701は、本発明の教示に従ってプロセス・ブロック411においても更新される。図11のコンテンツ評価テーブル701を参照すると、「Action Dude(アクション・デュード)」は評価値1を有している。「Action Dude(アクション・デュード)」の評価タイプは、図8との関連から前述したように、ユーザが明示的に「Action Dude(アクション・デュード)」の分類を行ったことから「明示」である。キャッシュ内インジケータは、現在「Action Dude(アクション・デュード)」がクライアント・システムによってローカルにストアされていることを示している。次処理インジケータは、ユーザがすでに「Action Dude(アクション・デュード)」を見終わっていることから「置き換え」になっている。
【0056】
一実施形態においては、コンテンツ評価テーブル701内の評価値が、次に述べるようにして決定される。メタデータ501は、「Action Dude(アクション・デュード)」が属性値「Joe Smith(ジョー・スミス)」および「アクション」を有していることを示している。図10のメタデータ・テーブル601は、「Joe Smith(ジョー・スミス)」が「1」の関連値および「1」の信頼性係数を有していることを示している。また図10のメタデータ・テーブル601は、「アクション」が「1」の関連値および「1」の信頼性係数を有していることも示している。一実施形態においては、特定のデータ・ファイルの評価値が、そのデータ・ファイルのすべての属性値に関して、すべての関連値とそのそれぞれの信頼性係数の結合を考慮して決定される。たとえば、一実施形態においては、1つのデータ・ファイルの評価値が、そのデータ・ファイルの属性値に関する各関連値と、それに対応する信頼性係数の積をすべて平均した値に等しくなる。
【0057】
例示のため、図11のコンテンツ評価テーブル701内の「Action Dude(アクション・デュード)」を参照すると、「Joe Smith(ジョー・スミス)」の関連値と信頼性係数の積は1×1であり、結果の値は「1」になる。「アクション」の関連値と信頼性係数の積は1×1であり、結果の値は「1」になる。積1と積1の平均は「1」である。したがって、図11のコンテンツ評価テーブル701内の「Action Dude(アクション・デュード)」の評価は「1」になる。
【0058】
同様に、コンテンツ評価テーブル701内の「Blast ’Em(ブラスト・ゼム)」について考えると、「Blast ’Em(ブラスト・ゼム)」は、属性値「Jane Doe(ジェーン・ドウ)」および「コメディ」を有している。図10のメタデータ・テーブル601内の「Jane Doe(ジェーン・ドウ)」に関する関連値および信頼性係数は、それぞれ「−1」および「0」である。したがって、コンテンツ評価テーブル701内の「Blast ’Em(ブラスト・ゼム)」の評価は、1×0と1×1の平均、すなわち「0.5」になる。図11に例示されているコンテンツ評価テーブル701内の「The Funny Show(ザ・ファニー・ショー)」および「Hardy Har Har(ハーディ・ハー・ハー)」についても本発明の一実施形態において類似の形態から決定されている。
【0059】
ここで注意が必要であるが、前述の図8においてユーザがムービー「Action Dude(アクション・デュード)」および「The Funny Show(ザ・ファニー・ショー)」の分類を行っていることから、これらのムービーは、図11のコンテンツ評価テーブル701内に示されるように評価タイプ「明示」を有している。また、ユーザがムービー「Blast ’Em(ブラスト・ゼム)」および「Hardy Har Har(ハーディ・ハー・ハー)」の分類を行っていないことから、これらのムービーはコンテンツ評価テーブル701内に「暗黙」の評価を有している。
【0060】
上記の説明は、コンテンツ評価テーブル701内の評価値が本発明に従ってどのように決定されるかについての一例を提供していることが理解できるであろう。ここで注意することは、評価値が、データ・ファイルの各属性値に関して関連値および信頼性係数を考察する本発明の教示に従った別の方法によっても決定可能なことである。
【0061】
一実施形態においては、コンテンツ評価テーブル701内の次処理に関するエントリが、部分的に、特定のデータ・ファイルに関する評価およびキャッシュ内の値によって決定される。たとえば一実施形態において、ゼロより大きい評価は、その特定のムービーにユーザが少なくともいくらかは関心を有すると予測されているものとする。つまりユーザは、ムービー「Blast ’Em(ブラスト・ゼム)」および「Hardy Har Har(ハーディ・ハー・ハー)」に興味を持つ可能性がある。したがって次処理は、ムービー「Blast ’Em(ブラスト・ゼム)」をストレージ内に保持すること、およびムービー「Hardy Har Har(ハーディ・ハー・ハー)」を、その後サーバによって放送されたときに取り込むことを示している。前述したように、ムービー「Action Dude(アクション・デュード)」は、すでにユーザが見終わっていることから、次処理フィールド内が「置き換え」としてマークされている。
【0062】
一実施形態においては、ユーザによるクライアント・システムとの将来のインタラクションが上記に類似の処理をもたらす。たとえば、ここでユーザがムービー「Blast ’Em(ブラスト・ゼム)」を見ていると仮定する。この特定の実施形態においてユーザは、ムービー「Blast ’Em(ブラスト・ゼム)」を見る前にそのムービーの分類を行っていない。一実施形態においては、図12のメタデータ・テーブル601に示されるように、分類されていないデータ・ファイルにアクセスがあると、その属性値に関して関連値および信頼性係数の両方が更新される。ここで図5から、ムービー「Blast ’Em(ブラスト・ゼム)」は、女優「Jane Doe(ジェーン・ドウ)」が主演する「アクション」ムービーであったことを思い出されたい。図10に示されているように、ユーザが「Blast ’Em(ブラスト・ゼム)」を見る前の「Jane Doe(ジェーン・ドウ)」の関連値はゼロより小さい値、つまり「−1」である。しかしながら、この実施形態においてユーザは、「Blast ’Em(ブラスト・ゼム)」が女優「Jane Doe(ジェーン・ドウ)」の主演するムービーであるという事実にもかかわらず、それを見ている。その結果、「Jane Doe(ジェーン・ドウ)」属性値の信頼性係数が下方に調整されるが、これは、この特定の属性値が、そのユーザの傾向を予測するときにあまり適切でないか、あまり関連性がなくなったと考えられることによる。一実施形態においては、関連値がすでにゼロより低いことから、さらに信頼性係数を下方に調整することはない。しかしながら、ユーザが「Blast ’Em(ブラスト・ゼム)」を見る前に、すでに属性値「アクション」がゼロより大きい関連値を有していたことから属性値「アクション」に関する関連値および信頼性係数が上方に調整される。つまり、この例においては、関連値が「1」から「2」に上方に調整され、かつ信頼性係数も「1」から「2」に上方に調整される。したがってこの時点において、図12のメタデータ・テーブル601は、「アクション」ムービーはユーザが見る可能性がより高いムービーであることを予測している。
【0063】
一実施形態においては、ユーザがクライアント・システムとインタラクションを行うごとに、メタデータ・テーブル601およびコンテンツ評価テーブル701が更新される。メタデータ・テーブル601およびコンテンツ評価テーブル701に対する更新は、ユーザがデータ・ファイルにアクセスしたときをはじめ、ユーザが明示的にデータ・ファイルを分類したときに行われる。ここで認識されることであるが、メタデータ・テーブル601およびコンテンツ評価テーブル701が本発明の教示に従って更新されるために、ユーザには明示的にデータ・ファイルを分類することが求められない。結局、コンテンツ評価テーブルは、時間の経過とともに、ユーザが関心を示すデータ・ファイルをより正確に予測することになる。
【0064】
一実施形態においては、ユーザがもっとも関心を示すと予測されたデータ・ファイルをはじめ、関心があると明示的にユーザが分類したデータ・ファイルが、クライアント・システム上にローカルにキャッシュされるデータ・ファイルになる。結局、ユーザが見ることを望む可能性のもっとも高いムービーが自動的にローカルにストアされるが、ユーザが、前もってそれらのムービーを明示的に要求する必要はなく、あるいはそれらのムービーの識別に使用される評価基準を明示的に指定する必要はなく、本発明の教示に従って「オン・デマンド」で使用可能になる。
【0065】
ここで認識されることは、各クライアント上にローカルにデータ・ファイルをストアすることによって、本発明の教示に従って放送帯域幅がより効率的に使用されることである。実際にユーザがクライアントのローカル・ストレージからムービーを見る場合には、追加の放送帯域幅がまったく使用されない。それに加えて、本発明の教示に従い、システム内において実行される処理のかなりの部分が、それぞれのメタデータ・テーブルおよびコンテンツ評価テーブルを更新するときに各クライアント・システム上において実行される。本発明のこの分散処理は、それぞれの追加のクライアントに関するサーバの増加コストがゼロであることから、現在開示している放送システムを非常に多数のユーザにわたってスケーリングすることを可能にする。
【0066】
別の実施形態においては、評価値、たとえば本発明のクライアント・システムによって維持ならびに更新が行われるコンテンツ評価テーブル内に生成される評価値を、本発明の教示に従って、サーバによる放送コンテンツおよびスケジュールの決定に使用することができる。たとえば、図1Bに示して前述したような放送システムを例に説明する。図示の実施形態に示されているように、サーバ103は、複数のクライアント105、107、109に向けて情報の放送を行う。図示の例においては、各クライアント105、107、109が、それぞれサーバ103に戻る通信リンク121、123、125も備えている。一実施形態においては、通信リンク121、123、125が、サーバ103によって使用されて、各クライアント105、107、109からそれぞれの評価を受信する。一実施形態においては、各クライアントから受信される評価が、前述と類似した方法において生成される。一実施形態においては、サーバ103が、各クライアントから受信した評価を集計するプロセスを含み、したがって、もっとも高く評価されたデータ・ファイルを識別することができる。一実施形態においてはサーバ103が、その後もっとも高く評価されたデータ・ファイルを放送する。一実施形態においては、データ・ファイルをサーバ103が放送する順序もしくは時刻が、少なくとも部分的に、各クライアントから受信され、集計された評価によって決定される。
【0067】
たとえば、図13は、本発明の教示に従い、クライアントの評価に応答して放送コンテンツおよびスケジュールが決定される放送システムにおけるサーバおよびクライアント内のイベントのフローを一形態で示したフローチャートである。これに示されているように、図13のプロセス・ブロック1303は、サーバがメタデータ放送スケジュールをクライアントに向けて放送することを示している。一実施形態においては、メタデータ放送スケジュールが、メタデータがサーバによって放送される将来の時点を示す。
【0068】
プロセス・ブロック1305は、クライアントがメタデータ放送スケジュールをサーバから受信することを示している。一実施形態においては、クライアント・システム105、107、109が、いつコンテンツを受信するか、どこでコンテンツを受信するか、またいずれのコンテンツを受信するかということを決定するために、このプレ放送されたメタデータ情報の取り込みおよび処理を行う。一実施形態においては、メタデータ放送スケジュール内に示された指定の時刻にクライアントがウェイクアップし、サーバからメタデータを受信する。一実施形態においては、メタデータが、サーバによってその後に放送される可能性のある複数のデータ・ファイルを記述する。プロセス・ブロック1307は、その後、メタデータ放送スケジュール内に指定されている時刻において、サーバからクライアントに向けて実際にメタデータが放送されることを示している。プロセス・ブロック1309は、クライアントがサーバからメタデータの放送を受信することを示している。
【0069】
プロセス・ブロック1311は、一実施形態において、その後クライアント・システムがメタデータ・テーブルならびにコンテンツ評価テーブルを更新することを示している。プロセス・ブロック1313は、一実施形態においてはオプションとして、クライアント・システムのユーザが、メタデータによって記述されている複数のデータ・ファイルの1ないしは複数の分類を行うことが可能であることを示している。一実施形態においては、ユーザの分類があると、メタデータ・テーブルおよびコンテンツ評価テーブルがクライアントによって更新される。一実施形態においては、プロセス・ブロック1311および1313に記述されているメタデータ・テーブルならびにコンテンツ評価テーブルに対する更新が、たとえば図1〜12に関して説明した方法と類似の方法において実行される。
【0070】
プロセス・ブロック1315は、その後クライアントがデータ・ファイルの評価をサーバに送信することを示している。一実施形態においては、放送ネットワーク内の各クライアントが、すでにサーバによって放送されているメタデータによって記述された複数のデータ・ファイルのすべてに関する評価を送信する。一実施形態においては、各クライアントが、クライアント・システム上に維持されているコンテンツの評価の一部もしくは全部を送信する。
【0071】
プロセス・ブロック1317は、放送システム内のクライアント(1ないしは複数)からサーバがデータ・ファイルの評価を受信することを示している。プロセス・ブロック1319は、その後サーバが、クライアント・システムによって決定された、もっとも高い評価を有するデータ・ファイルを選択することを示している。一実施形態においては、サーバが、クライアントから受信されたすべての評価を集計するプロセスを含む。一実施形態においては、集計されたランキングに応じてデータ・ファイルがストアされる。
【0072】
プロセス・ブロック1319は、一実施形態におけるサーバが、その後、すべてのクライアントから受信されたランキングに応じてデータ・ファイルを選択することを示している。一実施形態においては、その後、放送されることになるデータ・ファイルが、そのランキングに応じて決定される。その結果、本発明の教示に従ったサーバの一実施形態は、カスタマ・ベースで、つまりクライアントにとってもっとも適切な、あるいはもっとも関連のあるデータ・ファイルだけを放送することになる。たとえば、一実施形態においては、高いランキングを有するデータ・ファイルだけが放送され、もっとも低いランキングを有するデータ・ファイルは放送されない。一実施形態においては、放送スケジュールもランキングに応じて決定される。たとえば、一実施形態においては、もっとも高くランクされたデータ・ファイルが、より低くランクされているデータ・ファイルより前に放送される。別の実施形態においては、もっとも高くランクされたデータ・ファイルが、高いランクのデータ・ファイルの送信にもっとも適していると考えられる時刻に放送される。たとえば、放送者が、木曜日の夕方のゴールデンタイムを、放送に関してもっとも高い評価を有する、もっとも重要な時間帯であると考えている例を仮定する。この例において、本発明の教示に従ったサーバは、もっとも高いランキングのデータ・ファイルを、木曜日の夕方のゴールデンタイムの間に放送する。ここで認識されようが、当然のことながら、この例は説明のみを目的としたものであり、クライアントから受信した評価に応じた別の方法に従ってサーバが放送スケジュールを決定することも可能である。
【0073】
一実施形態においては、本発明の教示に従って、放送するデータ・ファイルまたは放送スケジュールが、サーバによってクライアント(1ないしは複数)から受信される評価に応じて動的に決定される。したがって一実施形態においては、いずれのデータ・ファイルをサーバから入手できるか、またいずれのコンテンツもしくはデータ・ファイルがクライアントによってアクセスおよび/または分類されるかということに基づいて放送スケジュールを時間の経過とともに変更することができる。
【0074】
放送するデータ・ファイルおよび放送スケジュールが、サーバによって決定されると、プロセス・ブロック1321に示されるように、その後サーバがクライアントに向けてデータ・ファイル放送スケジュールを放送する。プロセス・ブロック1323は、続いてクライアントがサーバからデータ・ファイル放送スケジュールを受信することを示している。
【0075】
一実施形態においては、データ・ファイル放送スケジュール内に示されている、あらかじめ指定された時刻にサーバからデータ・ファイルを受信するようにクライアントがウェイクアップする。プロセス・ブロック1325は、その後データ・ファイル放送スケジュール内に指定されている時刻に、サーバからクライアントに向けてそのデータ・ファイルが実際に放送されることを示している。
【0076】
一実施形態においては、プロセス・ブロック1327が、クライアントがサーバからデータ・ファイルの放送を受信することを示している。一実施形態においては、プロセス・ブロック1329が、クライアントがコンテンツ評価テーブルに従って選択的にデータ・ファイルをストアすることを示している。別の実施形態においては、クライアントが選択的にウェイクアップし、コンテンツ評価テーブルに従ってサーバから放送されるデータ・ファイルを選択的に受信する。この実施形態においては、その後クライアントによって、コンテンツ評価テーブルに従ってクライアントが選択的に受信したデータ・ファイルがストアされる。一実施形態においては、プロセス・ブロック1331が、その後、ストア済みのデータ・ファイルに対するユーザのアクセスがある場合に、クライアントがメタデータ・テーブルならびにコンテンツ評価テーブルの更新を行うことを示している。
【0077】
ここで認識されることは、図13に述べられている実施形態のクライアント・システムが、クライアント・システムが評価をサーバに返すことを除いて前述の実施形態に述べられているクライアント・システムと類似しているということである。またここで認識されることであるが、本発明の教示に従ってクライアント・システムの変形実施形態を使用することもできる。一実施形態においては、クライアント・システムが、サーバから放送されるデータ・ファイルのクライアント側フィルタリングを備えていない。しかしながらクライアント・システムは、本発明の教示に従ってサーバからメタデータ放送を受信し、データ・ファイルを評価し、その評価をサーバに返す。
【0078】
以上の詳細な説明においては、具体的に例示した実施形態を参照して本発明の方法および装置を説明してきた。しかしながら、より広い本発明の精神ならびに範囲から逸脱することなくそれらに対して各種の変形および変更を行い得ることは明らかである。したがってこの明細書は、限定ではなく例示と考えるべきである。

【特許請求の範囲】
【請求項1】
ネットワークに結合された1つまたは複数のコンピュータ・システムにより実行される方法であって、
1ないしは複数のクライアント・システムからフィードバックを受信するステップであって、前記フィードバックは1つまたは複数のファイルに関連するステップと、
1つまたは複数の関連値および1つまたは複数の信頼性実行と同様に前記受信したフィードバックに部分的に基づいて前記1ないしは複数のファイルの評価を調整するステップと、
前記クライアント・システムのユーザからの要求の有無によらず、前記調整された評価に基づいて予測情報を表示のために前記クライアント・システムに自動的に提供するステップと、そして
前記予測情報に関連した1セットのデータ・ファイル中の各データ・ファイルへのアクセスを提供するステップであって、前記予測情報は前記ユーザに関心のある情報を含むステップと、
を含む方法。
【請求項2】
ネットワークに結合された1つまたは複数のコンピュータ・システムにより実行される方法であって、
1ないしは複数のクライアント・システムからフィードバックを受信するステップであって、前記フィードバックは1つまたは複数のファイルに関するステップと、
1つまたは複数の関連値および1つまたは複数の信頼性係数と同様に前記受信したフィードバックに部分的に基づいて前記1つまたは複数のファイルの評価を調整するステップと、
前記クライアント・システムのユーザからの要求の有無によらず、前記調整された評価に基づいて予測情報を表示のために前記クライアント・システムに自動的に提供するステップと、そして
前記予測情報に関連した1セットのデータ・ファイル中の各データ・ファイルへのアクセスを提供するステップであって、前記1セットのデータ・ファイルは前記ネットワークに結合された1つまたは複数のコンピュータ・システム以外のコンピュータから伝送されるステップと、
を含む方法。
【請求項3】
前記予測情報が、これと関連する前記1セットのデータ・ファイル中の各データ・ファイルの記述を含む請求項1または2の方法。
【請求項4】
前記予測情報が、これと関連する前記1セットのデータ・ファイル中の各データ・ファイルのタイトルを含む請求項1または2の方法。
【請求項5】
前記1つまたは複数のファイルおよび前記1セットのデータ・ファイルが1つまたは複数のビデオ、オーディオ、画像そしてテキストを含む請求項1または2の方法。
【請求項6】
前記予測情報を提供するステップは前記調整された評価に基づいたより高い評価を有するファイルを選択するステップに基づいている請求項1または2の方法。
【請求項7】
前記1つまたは複数のファイルの評価リストを生成するために多数のクライアント・システムからの評価を結合するステップをさらに含む請求項1または2の方法。
【請求項8】
前記1つまたは複数の関連値が1つまたは複数のユーザのファイル選択行為の予測可能性のインジケータを含み、かつ前記1つまたは複数の信頼性係数が前記関連値のための重み付け係数を含む請求項1または2の方法。
【請求項9】
1つまたは複数のプロセッサを備えるコンピュータ・システムであって、
前記1つまたは複数のプロセッサは、
1ないしは複数のクライアント・システムから、1つまたは複数のファイルに関連するフィードバックを受信し、
1つまたは複数の関連値および1つまたは複数の信頼性係数と同様に前記受信したフィードバックに部分的に基づいて前記1ないしは複数のファイルの評価を調整し、
クライアント・システムのユーザからの要求の有無によらず、前記調整された評価に基づいて、前記予測結果を表示のために前記クライアント・システムに自動的に提供するように要求し、そして
前記予測結果に関連した1セットのコンテンツ中の各コンテンツへのアクセスを提供するように要求する
コンピュータ・システム。
【請求項10】
前記予測結果が、これと関連する前記1セットのコンテンツ中の各コンテンツのタイトルを含む請求項9のコンピュータ・システム。
【請求項11】
前記予測結果が、これと関連する前記1セットのコンテンツ中の各コンテンツの記述を含む請求項9のコンピュータ・システム。
【請求項12】
前記1つまたは複数の関連値が1つまたは複数のユーザのファイル選択行為の予測可能性のインジケータを含み、かつ前記1つまたは複数の信頼性係数が前記関連値のための重み付け係数を含む請求項9のコンピュータ・システム。
【請求項13】
前記1つまたは複数のファイルおよび前記1セットのデータ・ファイルが1つまたは複数のビデオ、オーディオ、画像そしてテキストを含む請求項9のコンピュータ・システム。
【請求項14】
予測結果を提供するように要求することが前記調整された評価に基づいたより高い評価を有するファイルを選択することに基づいている請求項9のコンピュータ・システム。
【請求項15】
前記1つまたは複数のプロセッサが、
前記クライアント・システムに命令を伝送し、前記命令は前記クライアント・システムに、前記クライアント・システムのユーザからの予測結果に対する要求の有無によらず、前記予測結果を要求するように指示し、自動的な前記要求は前記クライアント・システムにより実施された前記命令からの要求に応答して生じる請求項9のコンピュータ・システム
【請求項16】
請求項1および請求項3−8のいずれかに記載の方法を前記プロセッサに実施させる命令を記憶したコンピュータ可読記憶媒体。
【請求項17】
請求項2および請求項3−8のいずれかに記載の方法を前記プロセッサに実施させる命令を記憶したコンピュータ可読記憶媒体。

【図1A】
image rotate

【図1B】
image rotate

【図1C】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate


【公開番号】特開2012−95307(P2012−95307A)
【公開日】平成24年5月17日(2012.5.17)
【国際特許分類】
【出願番号】特願2011−251497(P2011−251497)
【出願日】平成23年11月17日(2011.11.17)
【分割の表示】特願2001−568616(P2001−568616)の分割
【原出願日】平成13年1月16日(2001.1.16)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.PENTIUM
2.ペンティアム
3.フロッピー
【出願人】(591003943)インテル・コーポレーション (1,101)
【Fターム(参考)】