JP2009194941A - 無線周波数インタフェース資源の共有 - Google Patents

Abstract

【課題】アプリケーションは、その資源の利用可能容量を超える、プロセッサ・ベースのシステム上のその無線周波数インタフェース資源に対してアクセスしようとする場合がある。
【解決手段】2つ以上のアプリケーションが同時にRFインタフェース資源に対するアクセスを必要とし、RFインタフェース資源の利用可能な容量がこれらの要求全てを認めることを可能にしない場合、競合解決を備え得る。一実施例では、競合解決は、RFインタフェース資源をアクセスしようとする各アプリケーションの優先度を判定する工程と、その優先度に基づいてアクセスを付与する工程とを包含し得る。
【選択図】図２

Description

本発明は、一般的に、メディアに対するアクセスを備える無線周波数（RF）インタフェース資源に関する。

「RFインタフェース資源」の句は、電磁スペクトルの無線周波数領域によって通信される信号を送受信するか、この信号において搬送されるデータを処理するか、伝統的なデータ・ネットワーク又はソフトウェア・インタフェースを介したものなどの他の手段によって通信される信号を送受信するアプリケーションによって用いられる送信器、受信器及び送受信器のハードウェア構成部分とソフトウェア構成部分とを表す。このデータは、オーディオ、ビデオ、音声、データやそれらの何れかの組み合わせの形式であり得る。RF信号によって搬送されるメディアを用いるアプリケーションの例として、TVの視聴、音楽ラジオの聴取、並びに音声/データの通信及び交換がある。RF信号は、オーバ・ザ・エア地上ソース、衛星ソース及び無線通信ネットワークを含む種々の通信リンクによって搬送し得る。RF周波数によって搬送されることに加え、RFインタフェース資源によって処理されるデータは、伝統的な、銅線ベース又は光ファイバ・ベースのデータ通信ネットワークによって搬送されるパケット・ベースのデータの形式で通信し得る。例えば、RFインタフェース資源によって処理されるデータは、テレビジョン・アンテナ、DSLモデム、ケーブル・モデム、同軸ケーブルのTV接続によって信号として通信し得る。あるいは、逆多重化装置によって処理されるMPEG-2トランスポート・ストリームなどの、RFインタフェース資源によって処理されるデータは、USB接続によって、ネットワーク・インタフェース・カード（NIC）によって、又はソフトウェア・プログラミング・インタフェースによっても通信されるデータとして搬送し得る。

パーソナル・コンピュータ（PC）は、PC上でTV番組の視聴を備える、テレビジョン（TV）のアドイン・カードをインストールさせている場合がある。放送されるままでのTVの視聴に加えて、今日の新しいカードの多くは、番組を記憶するようハード・ディスクを用いて、後に視聴するよう、放映時にTV番組を記録するなどの、ビデオ・カセット・レコーダに似た機能を備える。一部のTVカードは、アナログ・テレビジョンの視聴のサポートもディジタル・テレビジョンの視聴のサポートも備える。ディジタル・テレビジョンの登場によって、TV信号は、通常のTV番組に加えて、データ・サービスも搬送することが可能である。データ・サービスの例の一部としては、映画、音楽、ソフトウェア、ゲーム、ニュースやインターネットのコンテンツの配信及びダウンロードがある。このコンテンツを受信するアプリケーションは、ユーザが関心を持っているコンテンツのみを受信するというユーザ選好によってカスタム化可能である。ＴＶ番組のように、これらのデータ・サービスは、多くの種々のＲＦ周波数すなわち「ＴＶチャンネル」に散在している場合がある。

別々のＴＶチャンネルに同時に合わせたい複数のアプリケーションの間で競合が生じる。ＴＶ視聴者アプリケーションをチャンネル5にしてユーザがＴＶを視聴しているのと同時に、ＴＶ番組記録アプリケーションは、チャンネル3に合わせて予め設定された番組を記録したい場合がある。同時に、ＰＣゲーム・ダウンロード・サービス・アプリケーションは、ユーザが要求したゲームを取得するようチャンネル10に合わせる必要があり得る。この例での第１の競合は、チューナをそのチャンネルに合わせることができるそのアプリケーションはどれかということである。システムは、その各々がそれ自身の復調器及び逆多重化装置を備えている、その３つの別個のチューナを有していても、第２の競合が、保護コンテンツ又は暗号化コンテンツを、各アプリケーションが利用可能な形式に変換することが必要な共通復号器の利用をめぐって起こり得る。

現行システムは各アプリケーションがこれらの資源に対する直接のアクセスを得ることを可能にするので、1つのアプリケーションは他のアプリケーションの正しい動作を妨げ、問題が生じた理由についてユーザは分からないままであり得る。例えば、切り替えたいときにはいつでもＴＶチャンネルを切り替えることをユーザにさせるという理由で、ＴＶ視聴アプリケーションは、ＴＶ記録アプリケーションが所望の番組を記録することを不可能にする場合があり、ＰＣゲーム・サービスが（ユーザがサービスに対する支払いを行っていても）ゲームのダウンロードを正常に行うことを不可能にする場合がある。これらの共有資源の利用をめぐる競合が理由で、ユーザは通常、（特に、まず第１にユーザがＴＶカードに投資した理由がそれであっても）その、他のアプリケーションがうまくいかない理由について全く分からない状態におかれる。この結果は、収益を回収するためにコンテンツのダウンロードが正常に行われることに依拠している、データ・サービスのプロバイダやオペレータにとって同様に納得のいかないものである。

よって、RFインタフェース資源の利用を必要とするアクティブなアプリケーションの数が利用可能なRFインタフェース資源の数を超える場合に競合を解決する方法に対する必要性が存在する。

本発明の一実施例を示す動作図である。 本発明の一実施例を示す構成図である。 本発明の一実施例によるソフトウェアの流れ図である。 本発明の別の実施例によるソフトウェアの流れ図である。 本発明の一実施例によって解決可能な潜在的競合状況を示す概略図である。

〔実施例〕
図1を参照すれば、プラットフォームは、各々が単一方向又は双方向の通信リンク・インタフェース102に結合される、資源100A及び100Bなどの1つ又は複数の無線周波数（RF）インタフェース資源を含み得る。信号及びデータは、オーバ・ザ・エア地上ソース、衛星ソース、無線通信ネットワーク、並びに銅線ベース又は光ファイバ・ベースのデータ通信ネットワークを含む種々の通信リンクによって搬送し得る。それが処理する信号及びデータを通信するのにRFインタフェース資源によって用いられる通信リンク・インタフェース102の例は、RFインタフェース資源100と、ソフトウェア・プログラム又はオペレーティング・システムとの間でデータを通信する、テレビジョン・アンテナ、DSLモデム、ケーブル・モデム、同軸ケーブルのTV接続、USB接続、ネットワーク・インタフェース・カード（NIC）若しくはアプリケーション・プログラミング・インタフェースAPI又は別のソフトウェア・インタフェース機構を含む。資源100A及び100Bは、送信器、受信器若しくは送受信器、又は、チューナ104、符号器105、復号器105、多重化装置106、逆多重化装置107、暗号化装置108、復号装置109、変調器110及び復調器111のうちの1つ又は複数などの、それらの個々の構成部分であり得る。

RFインタフェース資源100は調停モジュール32に結合し得る。調停モジュール32は、プラットフォーム上でアクティブ状態にある、アプリケーション30a、30b及び30cなどのアプリケーションから資源100の要求全てを受信する。調停モジュール32は、無線周波数インタフェース資源100との間でのアクセスを制御する。一部の実施例では、調停モジュール32は、ソフトウェア構成部分である場合があり、一部の場合では、オペレーティング・システムの一部分であり得る。調停モジュール32は、資源100に対するアクセスを選択的に可能にする場合がある。調停モジュール32は、1つ又は複数のRFインタフェース資源100に対するアクセスが付与されるアプリケーション30がどれであるかを判定する優先度手法を実施する。

一部の場合には、Nの資源がMのアプリケーションにアクセス可能な場合があり、その場合に、MはNよりも大きいこととする。よって、競合が生じる場合があり、調停モジュール32は、優先度手法によってMのアプリケーションによるNの資源に対するアクセスを繰り返し申し出る役割を果たし得る。

本発明の一部の実施例は、限られた数のRFインタフェース資源によって制約される環境において、種々の時点で種々の無線周波数によって送受信される種々のメディア・サービスをサポートし得る。

オーディオ、ビデオ、音声若しくはデータ、又はそれらの何れかの組み合わせの形式におけるメディアは、データを搬送する信号によって通信することが可能である。信号及びデータを搬送し得る方法の例としては、オーバ・ザ・エア地上伝送若しくは衛星伝送、及び銅線ネットワーク若しくは光ファイバ・ネットワークがある。メディア・サービスの例には、視聴するよう、映画のコンテンツがMPEG-2トランスポート・ストリームにおいてPC又はセット・トップ・ボックスに配信されるビデオ・オン・デマンドのアプリケーションの配信がある。メディア・サービスの別の例は、コンテンツが携帯電話機又は携帯情報端末（PDA）に配信されるリッチ・マルチメディア・インターネット・アプリケーションである。メディア・サービスの別の例は、ゲームやその他のソフトウェアが、ハンドヘルド型コンピュータ若しくはポータブル・コンピュータ、デスクトップ型PC又は無線機器に配信されるゲーム・アプリケーション又はソフトウェア・アプリケーションである。更に別の例としては、携帯電話機又はPDAによってキャプチャされ、アップロードされる写真が誰か他の人に送信される、携帯電話機上又はPDA上でMP3.の音楽又はMPEG-4のビデオのコンテンツが受信される場合又はその逆の場合がある。

TV番組に対するテレビジョン・チャンネルが多く存在するように、種々のメディア・サービスを種々のRF周波数すなわち「チャンネル」として備える場合がある。実際に、テレビジョン・プログラミングは、メディア・サービスのもう１つの例に過ぎず、メディアは、テレビジョンに確保されている複数のRF周波数上で供給されるテレビジョン番組である。テレビジョン番組を搬送することに加えて、まさにそのテレビジョンRF周波数は、ビデオ・オン・デマンド又は上記の別のデータ・サービスのような別のメディア・サービスを搬送するのにも用い得る。しかし、一般的にはテレビジョン番組と違って、メディア・サービスは、連続した、1日24時間、週7日体制で供給されなくてよい。むしろ、一部のメディア・サービスは、特定の時間間隔でのみ利用可能な場合がある。このことは、アナログ・テレビジョンやディジタル・テレビジョンによって現在供給されているデータ・サービスの場合に多い。ビデオ、ゲーム、ソフトウェア、インターネット、ニュース、株価情報などのものを含み得るデータ・コンテンツは、多くの場合、一日にわたる、離散的な、引き続いていない時間ブロック中に放送される。データ・サービスが連続して放送される場合でも、データは通常、データが受信されるようにするために一時間間隔にわたって繰り返し再放送される。多くのメディア・サービス・アプリケーションは、ユーザ選好に一致させるよう、実際に受信されるコンテンツを特化する、すなわち、特定のコンテンツが故意に飛ばされるか無視される。

例として、単一の無線周波数チューナのみを有する、テレビジョン、PC、PDAや携帯電話機などのプラットフォームは、一度に単一の無線周波数搬送波にしか合わせることが可能でない。一部の場合には、2つ以上の所定の種類のRFインタフェース資源が備えられるが、その場合でも、何れかの所定のプラットフォームは、何れかの所定の時点で有限数の無線周波数上でしか送受信することが可能でなく、更に、同時に処理することが可能なデータ信号の数に対して、所定の資源の数が可能にする限りの数まで同様に制限される。実際に、RFインタフェース資源を同時に利用する数は、常に、何れかの実用的なシステムにおいて利用可能なRFインタフェース資源の数を超える。

種々のRF周波数を用いるサービスが同時に動作しようとする場合、コンテンツを送受信するのに用いるRFインタフェース資源をめぐって競合が生じ得る。アプリケーション間の同様な競合は、視聴するか、レンダリングするか、再生するよう、コンテンツを、それが受信された後かそれが送信されることになる前に処理するのに用いる符号器又は復号器などの特定の資源をめぐって生じ得る。この競合は、2つ以上のアプリケーションが何れかの所定の時点で同じRFインタフェース資源の利用を必要とし得る理由で生じ得る。例えば、各々がそのコンテンツを受信するようそのチャンネルに合わせたい、その３つの別々のデータ・サービス・アプリケーションが、そのTVチューナに対して競合する場合がある。資源の同時要求数が利用可能なRFインタフェース資源の数を超える場合、問題が生じる。

一実施例では、競合解決は、RFインタフェース資源をアクセスしたい各アプリケーションの優先度を判定する工程及び、その優先度に基づいてアクセスを付与する工程を包含し得る。優先度は、例えば緊急度又は重要度の順序による、1つのアプリケーションの別のものに対する順位に対する認識された権利である。優先度は、何れかの妥当な方法において割り当て得る。一部の実施例では、優先度は、ユーザ選好、アプリケーションが有料か無料か、アプリケーションが出てきた順序は選択されたものかインストールされたものか、アプリケーションが利用可能な時期若しくは場所、アプリケーションが装置の動作に重要であるか否か、又は、システム上に存在する場合も存在しない場合もあるその他のハードウェア資源若しくはソフトウェア資源をアプリケーションが必要とするか否かを含むがこれらには制約されない何れかの数の要因又は要因の組み合わせに基づくものであり得る。優先度は、いくつかの例をあげれば、ユーザ、アプリケーション若しくはシステム、又はそれらの何れかの組み合わせによって割り当てられる場合がある。

図2を参照すれば、プロセッサ・ベースのRF受信プラットフォーム10はプロセッサ・ベースのシステム12を含み得る。システム12は、一実施例では、RFインタフェース資源100及び調停モジュール32を含み得る。システム12は、いくつかの例をあげれば、パーソナル・コンピュータ、セット・トップ・ボックス、PDA又は携帯電話機であり得る。システム12は、テレビジョン受信機又はコンピュータ・モニタ、LCDパネルなどの内蔵ディスプレイなどの表示システムなどの出力装置16に結合し得るか、単に、出力するスピーカを用い得る。システム12は、キーボード、キーパッド、マウス、タッチパッド、ポインティング装置、リモコン装置又はマイクロフォンなどの入力装置37に結合されるか、それを含んで、ユーザからコマンド及び入力を受信する場合がある。一実施例では、入力装置37は放送TV受信器を備えているシステム上のチャンネルを切り替えるのに用い得る。信号は、一般的な例をあげれば、アンテナ、衛星受信器、ケーブル受信器又は、インターネットを含むコンピュータ・ネットワークからインタフェース100によって受信し得る。RFインタフェース資源100によって処理されるデータは、別のアプリケーションによってソフトウェア・プログラミング・インタフェースを介して通信される場合もある。

一実施例では、RFインタフェース資源100は、チューナ、復調器、逆多重化装置又は復号器を備えるPC上のテレビジョン・アドイン・カードであり得る。一部の実施例は、これらの構成部分の利用を個々に調停する場合があり、1つ又は複数の構成部分群において調停する場合もある。RFインタフェース資源100は、ハードウェア、ソフトウェア又は、ハードウェアとソフトウェアとの何れかの組み合わせで実施し得る。

システム12は、システム12を資源100とインタフェースさせるインタフェース24を含み得る。本発明の一実施例では、インタフェース24は、バス26に結合される場合があり、バス26は一実施例ではブリッジであり得るインタフェース36に同様に結合される場合がある。一アーキテクチャでは、インタフェース36は、記憶機構28、プロセッサ40及び入力装置37に結合し得る。一実施例では、出力装置16は、プロセッサ・ベースのシステム12に対するディスプレイとしての役割を果たす場合があり、メディアに対するディスプレイとしての役割を果たす場合がある一方、別の実施例では、別個のディスプレイが利用可能であり得る。更に、プロセッサ・ベースのシステム12の一アーキテクチャを図2に示す一方、本発明は何れかの利用可能なアーキテクチャに適用可能である。

本発明の一実施例では、記憶機構28は、ハード・ディスク・ドライブ（HDD）又はフラッシュ・メモリなどの非揮発性記憶装置であり得る。記憶機構28は、RFインタフェース資源100に対するアクセスを要求する複数のアプリケーション30を記憶し得る。更に、資源調停モジュール32を記憶機構28上に記憶させる場合もある。

本発明の一実施例によれば、インタフェース100にアクセスしようとするアプリケーション30間の競合を効果的な方法で解決し得る。同じRFインタフェース資源を同時に複数のアプリケーション30がアクセスしたいので、要求数がシステムの利用可能な資源の容量を超える場合があることが理由で、この競合が生じ得る。

図3を参照すれば、調停モジュール32は、資源100をアクセスするアプリケーション30の機能を制御する。資源に対する要求は、ブロック54に示すようにスケジューリングされる。本発明の一実施例によって種々のアプリケーション30によって要求される、所定の資源に対する所定の時間スロットを確保するスケジュールが備えられる。一実施例では、アプリケーション30は、例えば、データ・サービス放送の入手可能なスケジュールに基づいて、放送されることを期待しているデータを受信するのに必要な資源をアクセスするよう、アプリケーション30を時間スロットに割り当て得る。

菱形56での検査によって競合が存在しているか否かが判定される。限られた数の資源100に対するアクセスを2つの別々のアプリケーション30が同時に要求する場合に競合すなわちコンテンションが生じ、1つの一般的な例をあげれば、2つのテレビジョン・チューナのみが存在している場合に、3つのアプリケーションによって3つの別々のテレビジョン・チャンネルに合わせる要求などの、データ・サービスを受信する結果の資源利用要求の要求数がシステム10の容量を超える。いくつかの別の一般的な例には、HDTV復調器、MPEG-2トランスポート・ストリーム逆多重化装置、又はMPEG-4復号器をめぐる競合要求がある。生じる競合が何らない場合には、当該フローは、ブロック74に示す予め決められたスケジュールによって資源100の利用を認めるに過ぎない。

競合が識別される場合、本発明の一実施例によって、調停モジュール32は種々のアプリケーション30に対する要求を出してそれらの優先度を示し得る。あるいは、その優先度情報は既に調停モジュール32に存在していてもよく、アプリケーション30によってデータベースから別個にアクセス可能であってもよく、追加例として、情報を供給するようユーザがプロンプトすることを要求してもよい。

ブロック58に示すように、本発明の一実施例によって、優先度情報をアプリケーション30から受信し得る。本発明の一実施例によれば、ブロック60に示すように、競合解決は、別々のアプリケーション30の相対優先度に基づいて考案し得る。例えば、２つのアプリケーション30が同じ期間に資源を要求しており、全ての要求を備えるのに十分な資源が利用可能でない場合には、システム10は資源を、種々のアプリケーション30の優先度に基づいて割り当て得る。すなわち、より高い優先度を備えているアプリケーション30が要求資源を、それが利用可能な場合、取得する。

そのような場合では、ブロック62に示すように、要求資源を受信するアプリケーション30はそのように通知され、要求時間スロットを受信しなかったアプリケーションも通知される。一部の場合には、割り当てに対する応答は、ブロック64で、アプリケーション30から受信し得る。そのような場合では、要求が所定の時間スロットに対して行われた一方で、それが後に利用可能になる場合にアプリケーション30がその時間スロット又はその一部をなお所望しているということをアプリケーション30に通知する場合がある。更に、所定のアプリケーション30は、それが要求した利用可能時間の全てよりも少ない時間、アプリケーション30が用いることができる場合があるということを調停モジュール32に通知し得る。更に別の代替策として、優先度を受信する一部のアプリケーション30は、割り当て時間間隔の一部分にわたってその優先度をイールドすることができる場合がある。

所定のアプリケーションがその割り当てをイールドすることを可能にする状況には種々のものがある。一例として、それが達成することが必要な機能をそれが達成することを可能にする割り当て期間よりも少ない期間でアプリケーションは十分な情報を受信し得る。そのような場合には、アプリケーションはその場合、それが必要なデータを全て受信した後でそのアプリケーションをイールドする場合がある。

ブロック66に示すように、検査時間が設定される。検査時間は、割り当て資源の全部又は一部を、割り当てを受信したアプリケーションがイールドすることができ得るかを再検査するアプリケーション応答に基づいて作成される時間である。優先度に基づいて資源に割り当てることによって競合を解決する場合があっても、別のアプリケーションが後にその割り当て資源をイールドすることが可能であるか否かを判定するよう、アプリケーションによって再検査が要求された場合がある。一例では、一部の場合では、同じコンテンツを繰り返し放送し得る。アプリケーション30はよって、より早い時点で所定の時間スロットにおいてアクセスすることを意図している情報を受信する場合があり、よって、その後、その資源割り当てをイールドしたい場合がある。

菱形68での検査は、検査時間が現れたか否かを判定する。検査時間は資源競合の時間に相当する場合があり、その時間よりわずかに前である場合があり、その時間よりわずかに後である場合もある。

ブロック70では、検査時間が来た時点で、ブロック70に示すように、イールドの要求をより高い優先度のアプリケーションに備え得る。イールド要求が認められる場合、スケジュールはブロック72に示すように改訂し得る。その後、インタフェース14は、ブロック74に示すように、スケジュールによって動作される。

一部の実施例では、調停モジュール32は、オペレーティング・システムの一部であってもよく、オペレーティング・システム、アプリケーション・プログラム、又はアプリケーション・プログラム・インタフェース(API)の一部の上に階層化されていてもよい。調停されるRFインタフェース資源の例は、チューナ、復調器、変調器、逆多重化装置、多重化装置、符号器、復号器を含む。符号化及び復号化は、データを1つの形式から別の形式に変換することを意味する場合があり、データを暗号化形式から非暗号化形式に変換することを意味する場合もある。アプリケーションによるこれらの資源の調停された利用すなわち排他的な利用は、個々の資源として個々に制御されてもよく、1つの論理資源に組み合わせられるいくつかの構成部分の組み合わせとして制御されてもよい。一部の実施例では、復調器、逆多重化装置や復号化構成部分にもアクセスすることなくチューナに対するアクセスを有することが道理にかなわない場合があるので、それらは単一の論理資源として一緒にバンドルされる場合がある。別の実施例では、特定の組み合わせにおける構成部分の全て、例えば、（先行して記録されたコンテンツの）再生のみに必要な構成部分に対して、記憶させ、後に再生するよう、受信に必要なもの、を同時に利用することを可能にするよう、構成部分を別個にすることが道理にかなう場合がある。適切となる資源調停の細粒度すなわち範囲は、特定のシステム及びそのアプリケーションの必要性と目的とによって変わってくる。

アプリケーション30の各々は、図4に示すように、本発明の一実施例による、調停モジュール32と相互接続するモジュールを含み得る。当初、各アプリケーション30は、ブロック80に示すように、資源要求を調停モジュール32に転送する。よって、利用可能なスケジューリング情報に基づいて、特定の時間間隔について資源を必要とするということを所定のアプリケーション30は分かっている。したがって、アプリケーション30はこの資源の要求を調停モジュール32に対して行う。

その後、アプリケーション30は最終的には、競合が生じた場合、調停モジュール32から優先度情報の要求を受信する。優先度要求が何ら受信されない場合、時間の経過後、要求が認められたということを判定し得る。菱形82に示すように、優先度要求が受信される場合、要求優先度情報を、ブロック84に示すように、一実施例ではアプリケーション30から備え得る。その後、資源要求アプリケーション30は、菱形86において判定されるように競合解決を受信する。

菱形88に示すように、要求が満たされない場合、ブロック90に示すように一部の場合ではイールドを要求し得る。例えば、可能であれば資源を有していなければならないということをアプリケーション30が判定する場合、それは調停エージェント32に対して適切なイールド要求を示し得る。アプリケーション30はその場合、そのイールド要求に関する判定を待つ。

同時に、高優先度資源が割り当てられるアプリケーションは、ブロック92に示すように、調停エージェント32からイールド要求を受信し得る。イールド要求が受信される場合、アプリケーション30は、ブロック94に示すように、イールド判定を行う。更に、アプリケーション30はそのイールド判定を、ブロック96に示すように、調停エージェント32に通信する。

2つの例として、アプリケーションは、それが必要なデータを全て処理したか、それがなお有していないデータを全て競合が何ら存在しない将来の時間スロットで通信し得る場合にイールドし得る。何れの条件も、潜在的にイールドするアプリケーションとシステム12との一方又は両方によって分かり得る。それが必要なデータを全てそれが処理したということをそのアプリケーションが分かっているためには、必要なデータ資源を全て示すデータ・マニフェストのような追加メタデータを備え得る。マニフェストから判定されるようにそれが必要なデータを全てそのアプリケーション30が受信した場合があり、データは繰り返し通信し得る。メタデータは、どのデータが重要であり、どのデータが任意的であり、どれが別の手段によって利用可能であるかを示す場合もある。例として、ユーザが欲しいということをそれが分かっている映画をそれが受信した場合にそのビデオ・オン・デマンド・アプリケーションはイールドしない場合があるが、次週の映画予告でそのキャッシュが既に満たされているということをそれが分かっており、現在再放送されているのがそれである場合に、それはイールドする場合がある。

アプリケーション30（又はシステム12自体）は、データを通信し得る時点を示すスケジューリング情報が入手可能であることが理由で将来の時点まで資源が必要でない場合があるということが分かっている場合がある。このスケジューリング情報は、信号自体において搬送されるシステム情報又は電子番組ガイドの利用を含む種々の方法で入手可能とされ得る。どのデータがどの時点で繰り返し通信されることになるかに関する情報は、イールドが起こり得るか否かを判定するためにアプリケーション又はシステムに示し得る追加のメタデータに過ぎない場合がある。

一実施例を示している図5では、３つの別々のRFテレビジョン周波数を表す３つの別々の物理チャンネルA上、物理チャンネルB上及び物理チャンネルC上で提供されている３つのデータ・サービスX、Y及びZが存在している。時間軸は24時間に及び、各サービス期間は毎日同じ時間に繰り返されるということをみなし得る。システム12は一度に1つのアプリケーションによって排他的に制御することが可能なテレビジョン・チューナを1つしか有していないということもみなし得る。

全てのサービス・アプリケーションX、Y及びZがシステム開始時点で実行し始める場合、各サービスは、その要求時間スロット中にその当該チャンネルに合わせるようシステムに要求する。サービスXの要求は、競合するアプリケーション資源要求が何らない理由で無条件に認められることになる。サービスYの要求とサービスZの要求は、一実施例では、各々の優先度に基づいて処理されることになる。サービスYが高優先度を有する場合、その要求は無条件に認められることになり、テレビジョン・チューナ14は、時間T3に始まって、時間T4までの、サービスYがその帯域を所望する限りの間、チャンネルBに合わせられることになる。サービスZは、時間T4までの間（か、サービスYがそれまでにチューナをイールドする場合それよりも早く）、テレビジョン・チューナでの可能性はないことになる。

サービスZがサービスYより高い優先度を有する場合、プラットフォーム10は、一実施例では、2つの方法のうちの１つにおいて応答し得る。プラットフォーム10は、それが時間T5までチャンネルBに合わせ得るということをサービスYに通知しそこにともかく合わせるか否かの選択をサービスYに委ねる場合がある。サービスZは、T5から開始してT6までチャンネルC上でそのデータを確かに得ることになる。サービスYはそれがチューナを得ることが可能である限りまでチューナを所望しない場合、時間T5の直前に、システムは、サービスZが時間T4までイールドしたいかを判定するよう、サービスZに確かめ得る。サービスZがイールドしたい場合には、システムは時間T4までチャンネルBに合わせ続け得る。サービスZがイールドしたくない場合には、プラットフォーム10は時間T5でチャンネルCに合わせ得る。サービスZが時間T4より前の何れかの時間にチューナをイールドする場合、システムは、サービスYが帯域をなお所望するかを確かめる場合があり、肯定の場合、チャンネルBにもう一度戻る。

本発明は限られた数の実施例に関して説明したが、当業者はそれらからの数多くの修正及び変形が分かるものである。本特許請求の範囲が本発明の真の趣旨及び範囲の範囲内に収まるそのような修正及び変形を全て網羅するということが意図されている。

２８ 記憶機構
４０ プロセッサ

Claims (19)

1. 方法であって：
   プラットフォームが両方の要求を認める資源を有していないという理由で競合をもたらす、少なくとも２つのアプリケーションからの無線周波数インタフェース資源要求をプラットフォーム上で受信する工程；
   該少なくとも２つのアプリケーションの優先度を判定する工程；
   該優先度に基づいて、該資源要求のうちの１つを一定期間の間、認める工程；及び
   前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する工程を含むことを特徴とする方法。
2. 請求項1記載の方法であって、前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する工程は、前記少なくとも２つのアプリケーションのうちの一アプリケーションが、前記資源をイールドすることが可能であるかを判定する工程を含むことを特徴とする方法。
3. 請求項1記載の方法であって、前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する工程は、認められた資源要求を備えたアプリケーションが、前記資源をイールドすることが可能であるかを判定する工程を含むことを特徴とする方法。
4. 請求項１記載の方法であって、該資源要求を該認める旨に対する応答を、要求が認められなかったアプリケーションから受信する工程を含み、前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する工程は、要求が認められたアプリケーションが前記認められた資源を調停モジュールにイールドし、前記調停モジュールが、前記イールドされた資源を、要求が認められなかったアプリケーションに対して認める旨を要求する工程を含むことを特徴とする方法。
5. 請求項１記載の方法であって、少なくとも１つのアプリケーションは、TVの記録又は視聴、音楽ラジオの記録又は聴取、ビデオ・コンテンツの記録又は再生、音声又はデータの通信及び交換、並びに、映画、音楽、ソフトウェア、ゲーム、ニュース及び／又はインターネットのコンテンツの配信又はダウンロードを含む群から選択されることを特徴とする方法。
6. システムであって：
   プロセッサ；
   前記プロセッサに応答するディスプレイ：並びに
   前記システムが両方の要求を認める資源を有していないという理由で競合をもたらす、少なくとも２つのアプリケーションからの無線周波数インタフェース資源要求を受信する機能；各アプリケーションの優先度を判定する機能；該優先度に基づいて、該資源要求のうちの１つを一定期間の間、認める機能；及び前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する機能を該プロセッサが行うことを可能にする命令を記憶する記憶機構を備えることを特徴とするシステム。
7. 請求項6記載のシステムであって、放送受信器、テレビジョン受信器、及びラジオ受信器のうちの少なくとも１つを含むことを特徴とするシステム。
8. 請求項６記載のシステムであって、セット・トップ・ボックスと、携帯情報端末と、デスクトップ型コンピュータと、ポータブル・コンピュータと、ハンドヘルド型コンピュータと、メディア・サーバと、メディア・ゲートウェイと、携帯電話機と、無線機器とのうちの少なくとも１つを含むことを特徴とするシステム。
9. 請求項６記載のシステムであって、該プロセッサに結合される無線周波数インタフェース資源を含み、該資源は、チューナと、変調器と、復調器と、多重化装置と、逆多重化装置と、符号器と、復号器とを含む群から選択される少なくとも１つの構成要素を含むことを特徴とするシステム。
10. 請求項６記載のシステムであって、特定の種類の第１資源を含み、該種類は、チューナと、変調器と、復調器と、多重化装置と、逆多重化装置と、符号器と、復号器との、装置と、該装置の何れかの組み合わせとを含む群から選択され、該資源が該プロセッサに結合されることを特徴とするシステム。
11. 請求項10記載のシステムであって、該第１資源と実質的に同じ種類の第２資源を含むことを特徴とするシステム。
12. 請求項６記載のシステムであって、前記少なくとも２つのアプリケーションのうちの１つは、前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定することを特徴とするシステム。
13. 請求項６記載のシステムであって、前記認められた資源要求を備えたアプリケーションが、前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定することを特徴とするシステム。
14. 請求項６記載のシステムであって、調停モジュールと、要求が認められたアプリケーションが前記認められた資源を前記調停モジュールにイールドし、前記調停モジュールは、前記イールドされた資源を、要求が認められなかったアプリケーションに対して認める旨を要求するための記憶された命令とを更に備えることを特徴とするシステム。
15. 請求項６記載のシステムであって、少なくとも１つのアプリケーションは、TVの記録又は視聴、音楽ラジオの記録又は聴取、ビデオ・コンテンツの記録又は再生、音声又はデータの通信及び交換、並びに、映画、音楽、ソフトウェア、ゲーム、ニュース及び／又はインターネットのコンテンツの配信又はダウンロードを含む群から選択される機能を行うことを特徴とするシステム。
16. 記録媒体であって、実行されると、プロセッサベースのシステムが、
    両方の要求を認めるには、利用可能なシステム資源が不十分であるという理由で競合をもたらす、少なくとも２つのアプリケーションからの無線周波数インタフェース資源要求を受信する機能；該少なくとも２つのアプリケーションの優先度を判定する機能；該優先度に基づいて、該資源要求のうちの１つを一定期間の間、認める機能；及び前記一定期間の終了前に前記認められた資源をイールドすることが可能であるかを判定する機能を
    行うことを可能にする命令を記憶した媒体を備えることを特徴とする記録媒体。
17. 請求項1６記載の記録媒体であって、前記少なくとも２つのアプリケーションのうちの一アプリケーションは、前記一定期間の終了前に前記資源をイールドすることが可能であるかを判定することを特徴とする記録媒体。
18. 請求項1６記載の記録媒体であって、認められた資源要求を備えたアプリケーションが、前記一定期間の終了前に前記資源をイールドすることが可能であるかを判定する工程を含むことを特徴とする記録媒体。
19. 請求項１６記載の記録媒体であって、前記プロセッサベースのシステムが、要求が認められたアプリケーションが前記認められた資源を調停モジュールにイールドし、前記調停モジュールが、前記イールドされた資源を、要求が認められなかったアプリケーションに対して認める旨を要求することを可能にする記憶された命令を更に備えることを特徴とする記録媒体。

Images