JP2004215253A - フレーム・プロトコルおよびスケジューリング・システム - Google Patents

Abstract

【課題】 メモリ容量が限られた無線デバイスがメッセージを受信できるようにする。
【解決手段】 放送サービス（ＢＳ）から、共用データ、プライベート・データまたは制御データなどのシリアル化データがクライアント・デバイス（ＣＤ）への伝送用に放送サーバに送られる。データはＱＯＳメトリックを含む加重優先順位に基づきスケジューリングされて伝送される。伝送フレームは共用データに関する目次インデクシング・システムの規定を含むフレーム・プロトコルに従って配列され、共用データのパケットは特定のＢＳに既知の判断基準およびＣＤに常駐する対応アプリケーション（ＡＰＬ）に基づきフォーマットされる。ＣＤはトランスポート層で目次を受けて次フレームで使用可となるデータをＡＰＬに通知する。ＡＰＬは優先順位付きの要求をトランスポート層に提出し、データを要求する。トランスポート層からのデータは各ＡＰＬのハンドラでシリアル化解除される。
【選択図】 図４Ａ

Description

本発明は、一般にブロードキャスト・システムに関する。より詳細には、本発明は、ブロードキャスト・サーバから１つまたは複数のクライアント・デバイスへのデータ・ストリームの伝送をスケジューリングするシステムおよび方法に関する。データ・ストリームは、サービス品質メトリックを含む加重優先順位に基づいて伝送に関してスケジューリングされる。伝送ストリームは、プライベート・データ、共用データ、および制御データをサポートするフレーム・プロトコルに従って配置される。共用データ伝送ストリームは、アプリケーション固有の、柔軟に定義される目次に従ってインデクシングされる。

社会がますます移動性社会になるにつれて、モバイル・コンピューティング・デバイスは、普及と成長の高まりを享受している。セル（携帯）電話、無線ＰＤＡ、無線ラップトップ、および他のモバイル通信デバイスが、主流の顧客に見事に浸透している。しかし、この成長を制限し、顧客満足を制限しているのが、真に適切な広カバレッジ・エリアの、安価で小さくバッテリ効率のよい無線通信システムがないことである。セルデータ伝送電話ベースの解決策（cellular data-transmit telephony-based solutions）は、電力効率からほど遠く、使い物にならなくさせる（相対的な）コストおよびサイズに負担を強いている。同様に、この問題を解決する他の試みは、同様に不適当であることがわかっている。たとえば、少数のエンティティが、周波数変調（ＦＭ）副搬送波を介して情報を受信するモバイル・デバイスの利用を試みた。ＦＭ副搬送波（「ＳＣＡ（Subsidiary Communications Authorization）」、下位通信許可権とも称する）では、ＦＭステーションの使用可能変調帯域幅内のＦＭステレオを超える使用可能周波数が利用される。副搬送波は、通常は、無線ステーションから賃貸され、ＦＣＣまたは他の国内規制の対象である。

ＦＭ副搬送波システムの例の一部に、ハンドヘルド・モバイル・デバイスに株式市況を配信する、Ｄａｔａ Ｂｒｏａｄｃａｓｔ Ｃｏｒｐｏｒａｔｉｏｎ（ＤＢＣ）社によって所有され、維持されるＱＵＯＴＲＥＫシステムが含まれる。しかし、ＱＵＯＴＲＥＫシステムは、株式市況（stock quotes）の受信に限定された単一目的システムである。このシステムは、モバイル・コンピューティング・デバイスとしては使用可能で無くするさまざまな他の制約を有している。同様に、Ｓｅｉｋｏ Ｃｏｒｐｏｒａｔｉｏｎ社が、ＦＭ副搬送波システムを導入し、このシステムでは、ショートメッセージが腕に取り付けられるデバイスに伝送される。しかし、それに使用されるハードウェアおよび通信方式は、メッセージ伝送に過度の冗長性を必要とする結果を生じて、比較的単純（primitive）であった。Ｓｅｉｋｏ社のシステムに現れたこれらおよび他の短所は、許容しえないものであった。同様に、Ｒａｄｉｏ Ｄａｔａ Ｓｙｓｔｅｍ（ＲＤＳ）社のシステムまたはＭｏｂｉｌｅ Ｂｒｏａｄｃａｓｔｉｎｇ Ｓｙｓｔｅｍ（ＭＢＳ）社のシステムなどのある種のページング・システムは、ＦＭ副搬送波の使用に基づいている。しかし、これらのシステムは、データ・レートが制限されたブロードキャストの形で伝送されるショートメッセージに関係している。残念ながら、許容可能なモバイル・デバイス解決策は、当業者から見逃されてきていた。

手短に述べると、本発明は、伝送あるいは伝送される情報（transmissions）をスケジューリングするシステムおよび方法に関する。データ・ストリームは、ブロードキャスト・サーバから１つまたは複数のクライアント・デバイスに伝送される。サービスによって、ブロードキャスト・サーバ内のスケジューラに、シリアル化されたデータが供給される。シリアル化されたデータは、共用データ（shared data）、プライベート・データ、または制御データに対応するものとすることができる。データ・ストリームは、サービス品質メトリックを含む加重優先順位に基づいて、伝送のためにスケジューリングされる。伝送フレームは、フレーム・プロトコルに従って配置され、このフレーム・プロトコルには、共用データの柔軟な目次（table of contents）インデクシング・システムに対する規定が含まれる。共用データのパケットは、特定のブロードキャスト・サービスに、およびクライアント・デバイスに常駐する対応するアプリケーションに、既知の判断基準に基づいてフォーマットされる。クライアント・デバイスは、トランスポート層で目次を受信し、次のフレームで使用可能となるデータをアプリケーションに通知する。アプリケーションは、優先順位付きのリクエストをトランスポート層にサブミット（提出）し、次のフレームのデータを要求する。データが、トランスポート層によって各アプリケーションに対して引き出され、各アプリケーションのハンドラによってシリアル化が解除される。プライベート・データは、各加入者がプライベート・データ・スロットの一意の組を有するように、伝送フレームのパーティション内のスロットに擬似ランダムに割り当てられる。プライベート・データは、許可されない受信を防ぐためにそれ相応に暗号化される。

本発明およびその改良についてのより完全な理解は、下記に手短に要約された添付図面、下記の本発明の例示的実施形態についての詳細な説明、および請求の範囲を参照することによって得ることができる。

本発明は、無線クライアント・デバイスを含む通信システムについてのコンテクストで説明される。説明される実施形態では、以下で詳細に説明するように、クライアント・デバイスを、通信信号を受信するように特に構成された腕時計型デバイスとすることができる。以下の詳細な説明を読めば明らかになるように、クライアント・デバイスは、１つまたは複数のブロードキャスト塔からブロードキャスト伝送を受信する。ブロードキャスト伝送される情報（broadcast transmissions）は、以下でさらに説明するフレーム・プロトコルに従って供給される。フレームの構造は、メモリ容量が限られた無線デバイスがメッセージを受信できるように、共用データに関して目次を有するように配置されている。

本明細書では、腕時計ベースのシステムのコンテクストで説明するが、本願の教示は、ポータブル・コンピュータ、デスクトップ・コンピュータ、携帯情報端末（ＰＤＡ）、セル電話機、目覚まし時計、キー・ホルダ、冷蔵庫に付ける磁石、壁掛け時計、および類似物などの、他のすべてのモバイル・デバイスまたは非モバイル・デバイスに等しく適用可能であることを理解されたい。腕時計の使用は、以下の説明を単純にするのみの例示的な目的のものであって、「モバイル・デバイス」および／または「クライアント・デバイス」と交換可能に使用することができる。用語「クライアント」および「加入者」は、サービスのユーザを表す、交換可能な用語である。各クライアント（または加入者）は、複数のクライアント・デバイスを有することができ、各クライアント・デバイスは、クライアント（または加入者）と同一であると見なされる。

「コンピュータ可読媒体」は、クライアント／サーバ・デバイスによってアクセスすることができるすべての使用可能な媒体とすることができる。制限ではなく例として、コンピュータ可読媒体に、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータなどの情報を保管する任意の方法または技術で実装された、揮発性および不揮発性の、取外し可能および取外し不能の媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、または他の磁気ストレージ・デバイス、あるいは所望の情報を保管するのに使用でき、クライアント／サーバ・デバイスによってアクセスできる他の媒体が含まれるが、これに制限はされない。通信媒体は、通常は、搬送波または他のトランスポート機構などの変調されたデータ信号内の、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータを具体的に示し、通信媒体には、すべての情報配信媒体が含まれる。用語「変調されたデータ信号」は、信号内で情報をエンコードする形で１つまたは複数の特性をセットまたは変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワーク接続または直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。上記のいずれかの組合せが、コンピュータ可読媒体の範囲に含まれる。

フレーム・プロトコルの全体的な動作環境を、以下で図１〜図３を参照して説明する。

動作環境
図１に、本発明の例示的な動作環境（１００）を示す。図からわかるように、ＦＭトランシーバ、すなわち（そこからの）ＦＭブロードキャストは、通信チャネル（１１０）を介してさまざまな電子デバイスに伝送される。ＦＭ受信器またはＦＭトランシーバを有する電子デバイスの例に、デスクトップ・コンピュータ、腕時計、ポータブル・コンピュータ、無線セル電話機（セル電話機）、および携帯情報端末（ＰＤＡ）を含めることができる。電子デバイスは、ＦＭブロードキャストから情報を受信するように配置される。ＦＭブロードキャストは、標準ＦＭ伝送、副搬送波ＦＭ伝送、または望ましい可能性のある他のタイプのＦＭ伝送を含む複数のタイプのいずれかとすることができるが、これに制限されない。

ＦＭ副搬送波を、しばしば、Ｓｕｂｓｉｄｉａｒｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｕｔｈｏｒｉｚａｔｉｏｎの米国連邦通信委員会（ＦＣＣ）用語によって識別されるように、ＳＣＡと呼ばれる。ＦＭ副搬送波では、ＦＭステーションに関するＦＭステレオ帯域で、別な方法では未使用の帯域幅が使用される。米国では、ＦＣＣは、その変調帯域幅をＦＭステーションの変調帯域幅内のおおむね５３ＫＨｚから１００ＫＨｚまでとすることを要求している。

対話モデルに従って動作するように配置された電子システムを含むことができる電子デバイスのいくつかの例が、図１に示されている。この電子システムでは、上で説明したＦＭ伝送システムなどの無線インターフェースを使用することができる。電子システムのそれぞれが、通信チャネルを介してメッセージ・ストリームを受信する。

ブロードキャストされるそれぞれの伝送情報は、１つまたは複数のフレーム伝送情報に対応する。各フレームに、複数のメッセージを含めることができ、このメッセージには、パブリック・ブロードキャスト（「グローバル」メッセージまたは「共用」メッセージとも称する）と、クライアント固有メッセージ（「パーソナル」メッセージまたは「プライベート」メッセージとも称する）がある。指定されたサービス地域内に位置するすべてのクライアントは、共用データを受信することができるが、単一のクライアントが、プライベート・データをデコードすることができる。前に説明したように、加入者（またはクライアント）は、複数のクライアント・デバイスを有することができ、各クライアント・デバイスは、加入者によってアクセス可能な伝送情報（transmissions）を受信できる。

電子デバイス（たとえば、無線腕時計デバイス）によって、クライアント・デバイスに向けられた複数のパケットが受信される。複数のパケットは、論理スロット（またはチャネル）エントリ番号に従ってグループに編成される。複数のスロットは、チャネルのステーションに対応するブロードキャスト・サービスに関連付けられている。各電子デバイスを、チャネルの異なるグループを受信するように構成することができる。これらのチャネルのそれぞれに関連付けられたパケットは、クライアント・デバイスで受信され、処理され、保管される。保管されたパケットは、クライアント・デバイスに常駐するアプリケーションによって引き出される。クライアント・デバイス上の各アプリケーションは、ブロードキャスト・サーバおよび特定のチャネルに関連付けられた特定のサービスに関連付けられる。複数のチャネルの例には、時刻チャネル、メッセージ・チャネル、連絡チャネル、カレンダ・チャネル、天気チャネル、株式チャネル、ニュース・チャネル、およびゲーム・チャネルが含まれる。

例示的電子システム
図２は、本発明に従って配置された電子デバイス（２００）の機能コンポーネントを示す概略図である。電子デバイス（２００）は、プロセッサ（２６０）、メモリ（２６２）、ディスプレイ（２２８）、およびユーザ・インターフェース（２３２）を有する。メモリ（２６２）には、一般に、揮発性メモリ（たとえばＲＡＭ）および不揮発性メモリ（たとえば、ＲＯＭ、フラッシュ・メモリ、または類似物）の両方が含まれる。電子デバイス（２００）には、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ社のＷｉｎｄｏｗｓ（登録商標） ＣＥオペレーティング・システムまたは別のオペレーティング・システムなどの、メモリ（２６２）に常駐し、プロセッサ（２６０）によって実行されるオペレーティング・システム（２６４）が含まれる。ユーザ・インターフェース（２３２）は、一連の押しボタン、スクロール・ホィール、数字ダイヤリング・パッド（普通の電話機にあるものなど）、または別のタイプのユーザ・インターフェース手段とすることができる。ディスプレイ（２２８）は、前に説明したように、液晶ディスプレイまたは他のタイプのディスプレイとすることができる。１例では、ディスプレイ（２２８）を、入力デバイスとして働く接触感知型とすることができる。

１つまたは複数のアプリケーション・プログラム（２６６）が、メモリ（２６２）にロードされ、オペレーティング・システム（２６４）上で走行する。アプリケーション・プログラムの例には、電話ダイヤラ・プログラム、電子メール・プログラム、スケジューリング／カレンダリング・プログラム、ＰＩＭ（個人情報管理）プログラム、インターネット・ブラウザ・プログラムなどが含まれる。電子デバイス（２００）には、メモリ（２６２）内に配置される、不揮発性ストレージ（２６８）も含まれる。不揮発性ストレージ（２６８）は、電子デバイス（２００）の電源が切られている場合に失われてはならない永続的情報を保管するのに使用することができる。アプリケーション（２６６）によって、電子メールまたは電子メール・アプリケーションによって使用される他のメッセージ、ＰＩＭによって使用される連絡先情報、スケジューリング・プログラムによって使用される面会予約情報、ワードプロセッシングアプリケーションによって使用される文書、インスタント・メッセージング・アプリケーションのインスタント・メッセージ、テキスト・メッセージング・アプリケーションのテキスト・メッセージなどの情報を使用し、ストレージ（２６８）に保管することができる。

電子デバイス（２００）は、電源（２７０）を有し、電源（２７０）は、１つまたは複数の電池として実装することができる。電源（２７０）に、さらに、ＡＣアダプタまたは電池を補足するか充電する電源付きドッキング・クレードルなどの外部電源を含めることができる。

電子デバイス（２００）は、２タイプの外部通知機構すなわち、ＬＥＤ（２４０）およびオーディオ・インターフェース（２７４）も有するものとして図示されている。これらのデバイスは、電源（２７０）に直接に結合することができ、その結果、アクティブ化された時に、これらが、プロセッサ（２６０）および他のコンポーネントが電池電力節約のためにシャットダウンされる場合であっても、通知機構によって指示される持続時間の間オンのままになる。ＬＥＤ（２４０）は、ユーザがデバイスの電源オン情況を示す処置を講じるまで無期限にオンになるようにプログラムすることができる。オーディオ・インターフェース（２７４）は、ユーザとの間で可聴信号を提供し、受け取るのに使用される。たとえば、電話の会話を容易にするため、または音声認識を使用するユーザ・インターフェースとしてなど、オーディオ・インターフェース（２７４）を、可聴出力を供給するためにスピーカに結合でき、可聴入力を受け取るためにマイクロホンに結合することができる。

電子デバイス（２００）には、ラジオ周波数通信の受信および／または伝送の機能を実行するラジオ・インターフェース層（２７２）も含まれる。ラジオ・インターフェース層（２７２）によって、電子デバイス（２００）と外部の世界の間の、通信キャリアまたはサービス・プロバイダを介する無線接続性が容易になる。ラジオ・インターフェース層（２７２）への、およびラジオ・インターフェース層（２７２）からの伝送は、オペレーティング・システム（２６４）の制御の下で行われる。言い換えると、ラジオ・インターフェース層（２７２）によって受信される通信を、オペレーティングシステム（２６４）を介してアプリケーション・プログラム（２６６）におよびその逆に散布することができる。

例示的な腕時計ベースの電子システム
図３に、本発明に従って動作するように構成された電子システム（３１０）を含む例示的な腕時計デバイス（３００）を示す。腕時計デバイス（３００）には、時計バンドに取り付けられるか時計バンド（３０４）内に一体式に形成されるかのいずれかであるアンテナ（３０２）を含む時計バンド（３０４）が含まれる。アンテナ（３０２）は、腕時計に含まれる電子システム（３１０）に結合される。電子システム（３１０）は、図３に示されているようにベゼル（bezel）に、または腕時計デバイスの他の部分（図示せず）に、含めることができる。

電子システム（３１０）は、受信器タイプまたはトランシーバ・タイプのいずれかのデバイスとして動作するように配置される。図からわかるように、電子システムには、トランシーバ（３２０）、マイクロ・コンピュータ・ユニット（ＭＣＵ ３３０）、およびアナログラジオ（３４０）が含まれる。アンテナは、トランシーバ（３２０）に結合され、これによって制御される。ＭＣＵ（３３０）とラジオ・コンポーネントの間のトランザクションは、ＭＣＵディジタル・トランシーバ・インターフェースを介して仲介される。腕時計デバイス（３００）のコンポーネントは、腕時計サイズのエンクロージャに収納され、動作について電池電力に頼る。

トランシーバ（３２０）には、一般に、ディジタル信号プロセッサ（ＤＳＰ ３２４）およびリアル・タイム・デバイス（ＲＴＤ ３２６）が含まれ、ＤＳＰ（３２４）は、トランシーバの制御、スケジューリング、および後処理タスクを実行し、ＲＴＤ（３２６）には、ディジタルラジオ、システム・タイミング、およびリアル・タイム・イベント・ディスパッチが含まれる。ＤＳＰ（３２４）は、ＭＣＵ（３３０）に結合され、トランシーバ・タスクは、ＭＣＵ（３３０）によって指令される。

ＤＳＰのタスクの１つによって、副搬送波位相復元、ボー復元および／またはトラッキング、フェージング効果の補償、復調、インターリーブ解除、チャネル状態推定、およびエラー訂正などの目的で受信データを処理することができる。パケットの後処理は、パケット全体が受信された時または後続の別の時に行うことができる。ＤＳＰ（３２４）によって、伝送されたデータ・パケットが分析され、ＲＴＤ（３２６）のローカル・クロックに関するステーションの信号タイミングを判定する。ローカル・クロックを、送信器のクロック信号に同期させて、信号サンプリングの完全性を維持する。受信器は、周期的に送信器とのシンボル同期化の状態にされて、受信データの誤読を最小にする。

ＲＴＤ（３２６）のディジタル部分に、ＭＣＵ（３３０）およびＤＳＰ（３２４）にシステムクロックを供給する水晶発振器などのシステム・タイム・ベース・ジェネレータを含めることができる。タイム・ベースによって、伝送動作および受信動作のボー・タイミングおよびサンプル・タイミング、ラジオ動作の開始／停止制御が提供され、ＭＣＵ（３３０）およびＤＳＰ（３２４）へのクロック中断（periods of clock suspension）の期間が制御される。ＲＴＤ（３２６）によって、ラジオ動作も実行され、追加動作も実行することができる。ラジオ（３４０）は、パケットに配置されたデータのセグメントを受信するように配置される。

図２および３に示された動作環境は、適する動作環境の例にすぎず、本発明の使用または機能性の範囲に関する制限を暗示することを意図されたものではない。本発明と共に使用するのに適する可能性がある他の周知のコンピューティング・システム、環境、および／または構成には、パーソナル・コンピュータ、サーバ・コンピュータ、ハンドヘルド・デバイス、ラップトップ・デバイス、マルチ・プロセッサ・システム、マイクロ・プロセッサ・ベースのシステム、プログラマブル消費者電子製品、ネットワークＰＣ、ミニ・コンピュータ、メインフレーム・コンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。

ブロードキャスト・サービス
各ブロードキャスト伝送塔（broadcast transmitter tower）は、サービス地域内の無線クライアント・デバイスによる受信のために構成された通信信号を供給するように配置される。サービス地域は、１つまたは複数のブロードキャスト伝送塔（図１参照）によってサービスされる地理的区域である。ＦＭブロードキャスト塔によって、図４Ａに示されたブロードキャスト・サーバ・デバイスによる指示どおりに信号が伝送される。ブロードキャスト・サーバ・デバイス（「ジェネレータ」とも称する）は、ネットワーク通信リンクを介してスケジューラと通信することができる。

スケジューラは、１つまたは複数のサービスを選択する手段として構成される。１例では、クライアント・デバイスのユーザが、スケジューラ・インターフェースと対話して、ニュース、株価、天気などのサービス、ならびにパーソナル・カレンダ、アドレス帳、および類似物などの他の機能を選択する。スケジューリング・インターフェースは、ブロードキャスト・サービスの加入者へのカスタマイズの供給を含むウェブ・ベースのインターフェースとすることもできる。選択されたサービスが、スケジューラに通信され、後の伝送のためにキューイングされる。指定された時刻（または時間間隔）に、スケジューラによって、１つまたは複数の選択されたサービス（services）（たとえばＳＲＶＣ １〜ＳＲＶＣ Ｎ）からシリアル化されたデータが引き出される。スケジューラによって、以下で詳細に説明するように、伝送情報（transmissions）についてのスケジューリングの優先順位が決められる。スケジューリングされた伝送情報（transmissions）は、ブロードキャスト・サーバに通信されて、選択されたサービスに関するデータの伝送シーケンスが開始される。ブロードキャスト・サーバによって、その後、シリアル化されたデータが、１つまたは複数の無線クライアント・デバイスに対するメッセージ・ストリームにフォーマットされ、伝送用のデータがキューイングされ、キューイングされたデータは伝送用のＭブロードキャスト塔に通信される。スケジューラは、ブロードキャスト・サーバと一緒に統合するか、別々のコンポーネントとすることができる。

ブロードキャストされるそれぞれの伝送情報は、フレーム・プロトコルに従って配置されるフレームの伝送に対応する。各フレームに、１つのフレーム・ヘッダおよび複数のデータ・ストリームが含まれる。フレーム・ヘッダによって、フレーム番号識別子、伝送時刻、タイム・ゾーン識別子、サービス地域識別子などのパラメータならびに他の環境情報に関する伝送環境が記述される。フレーム・ヘッダによって、フレーム内の共用データについての１つまたは複数の目次の位置も記述される。

複数のストリームは、共用データ（ブロードキャスト・ストリームとも称する）、または特定のクライアント（加入者）によって識別されるプライベート・データ（パーソナル・データとも称する）として分類することができる。各フレームは、次に伝送されるフレーム内の位置で、共用データ・ストリームが配置される位置を示す目次が含まれる。

スケジューラの例
例示的なスケジューラは、コンピューティング・デバイスとして実装することができる。また、ブロードキャスト・サーバをも、コンピューティング・デバイスとして実装することができる。例示的なコンピューティング・デバイス（４００）を、図４Ｂに示す。

基本構成では、コンピューティング・デバイス（４００）に、通常は、少なくとも１つの処理ユニット（４０２）と、システム・メモリ（４０４）が含まれる。コンピューティング・デバイスの正確な構成およびタイプに応じて、システム・メモリ４０４は、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュ・メモリなど）、またはこの２つの組合せとすることができる。システム・メモリ４０４には、通常は、オペレーティング・システム（４０５）、１つまたは複数のプログラム・モジュール（４０６）が含まれ、プログラム・データ（４０７）を含めることができる。この基本構成は、図４Ｂで、破線４０８内のコンポーネントによって示されている。

コンピューティング・デバイス４００は、追加の特徴または機能（additional features or functionality）を有することもできる。たとえば、コンピューティング・デバイス４００に、たとえば磁気ディスク、光ディスク、またはテープなどの追加データ・ストレージ・デバイス（取外し可能および／または取外し不能）を含めることもできる。そのような追加ストレージは、図４Ｂでは、取外し可能ストレージ４０９および取外し不能ストレージ４１０によって示されている。コンピュータ記憶媒体に、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータなどの情報を保管する任意の方法または技術で実装された、揮発性および不揮発性の、取外し可能および取外し不能の媒体が含まれる。システム・メモリ４０４、取外し可能ストレージ４０９、および取外し不能ストレージ４１０のすべてが、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、または他の磁気ストレージ・デバイス、あるいは所望の情報を保管するのに使用でき、コンピューティング・デバイス４００によってアクセスできる他の媒体が含まれるが、これに制限はされない。そのようなコンピュータ記憶媒体のどれであっても、デバイス４００の一部にすることができる。コンピューティング・デバイス４００は、キーボード、マウス、ペン、音声入力デバイス、接触入力デバイスなどの入力デバイス４１２も有することができる。ディスプレイ、スピーカ、プリンタなどの出力デバイス４１４も、含めることができる。これらのデバイスのすべてが、当技術分野で既知であり、ここで詳細には説明しない。

コンピューティング・デバイス４００には、通信接続４１６も含まれ、これによって、このデバイスが、ネットワークを介するなど、他のコンピューティング・デバイス４１８と通信できるようになる。通信接続４１６は、通信媒体の例である。通信媒体は、通常、搬送波変調されたデータ信号内の、または他のトランスポート機構などにおけるコンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータを具体的に示し、すべての情報配信媒体が含まれる。用語「変調されたデータ信号」は、信号内に情報をエンコードする形で１つまたは複数の特性を設定または変更された信号を意味する。制限ではなく例として、通信媒体に、有線ネットワーク接続または直接配線接続などの有線媒体と、音響媒体、ＲＦ媒体、赤外線媒体、および他の無線媒体などの無線媒体が含まれる。本明細書で使用される用語コンピュータ可読媒体には、記憶媒体と通信媒体の両方が含まれる。

伝送フォーマット
図４Ａに、フレーム伝送の例も示されている。各フレームは、複数のセグメント（Ｍ個）に分割される。各セグメントの最初の部分に、同期化（Sync）シンボルが含まれる。フレームは、データの完全性（data integrity）が改善されるように、Ｍ個のセグメント（Ｓ０〜ＳＭ）に分散される。クライアント・デバイスの受信器は、同期シンボルを用いて、データ信号の受信のタイミング機能を確立する。各セグメントに、ある数（Ｎ個）のパケットが含まれる。さまざまなパケットおよびセグメントの伝送の順序は、複数のフレームがインターリーブされるかあるいは連続するように修正（変更）することができる。

図４Ｃは、フレーム伝送シーケンスの例を示す図であり、このシーケンスでは、各フレームに、インターリーブされたセグメントとして伝送される１６個のセグメント・グループが含まれる。各セグメントには、１２８０個のパケットが含まれ、フレーム全体に２０４８０個のセグメントが含まれる。図４Ｃに示された例について、所与のセグメント（Ｓｘ）のすべてのパケット（Ｐｘ）が、次セグメントのパケットが伝送される前に、順番に伝送される。例示的なフレームの伝送シーケンスは、（Ｓ０Ｐ０、Ｓ０Ｐ１、…、Ｓ０Ｐ１２７９）、（Ｓ１Ｐ０、Ｓ１Ｐ１、…、Ｓ１Ｐ１２７９）、…（Ｓ１５Ｐ０、Ｓ１５Ｐ１、…、Ｓ１５Ｐ１２７９）である。図４Ｃに示された例によれば、新しいフレームの伝送は、前のフレームの２０４８０個のセグメントが完了した後に開始される。

図４Ｄは、もう１つの例示的なフレーム伝送シーケンスを示す図であり、このシーケンスでは、各フレームは、１６個のセグメント・グループの１つについて８０個のパケットのブロックに分割される。図４Ｄに示された例に関して、所与のセグメント（Ｓｘ）のパケット（Ｐｘ）は、次セグメントのパケットとインターリーブされたシーケンスで伝送される。各伝送ブロックは、特定のセグメントについて８０個のパケットからなる。フレームの伝送シーケンスは、（Ｓ０Ｐ０、Ｓ０Ｐ１、…、Ｓ０Ｐ８０）、（Ｓ１Ｐ８０、Ｓ１Ｐ８１、…、Ｓ１Ｐ１５９）、…などとして図示されている。図４Ｄに示された例によれば、２０４８０個のセグメントすべてのフレーム受信は、フレームがローリング・ベース（rolling basis）で完了するようにインターリーブされる。

フレーム・プロトコルの構造および相互作用
クライアント・デバイスは、ＯＳＩネットワーキング・モデルに類似する一連の層に編成される。層には、物理層、リンク層、ネットワーク層、トランスポート層、およびアプリケーション層が含まれる。物理層によって、ＦＭ副搬送波によって伝送された情報が受信され、リンク層に複数のシンボルが供給される。リンク層によって、複数のシンボルがセグメントに分割され、ビタビ・コーディング、データ・ホワイトニング（data whitening）、およびインターリーブ機能が処理される。ネットワーク層によって、セグメントが受け取られ、論理パケットが作成される。ネットワーク層によって、ＣＲＣ、暗号化、およびリードソロモン・コーディングも処理される。トランスポート層によって、論理パケットがデコードされて、目次が取り出される。このトランスポート層には、アプリケーション層への通信を処理するデータ・ハンドラが含まれる。アプリケーション層には、クライアント・デバイスに常駐し、ブロードキャスト・サービスへの加入に関連する一連のアプリケーションが含まれる。

フレーム構造は、図５を参照して以下で説明する複数のパケットを含む。本明細書で示す例では、各フレームに、２０４８０個のセグメントが含まれ、これが、１２８０個のセグメントから成る１６個のセグメント・グループに分解され（たとえば図４Ｃ参照）、各セグメントに、６８個のシンボルが含まれ、各シンボルが、１つのパケット・データ・ビットを表す。各シンボルは、各フレーム伝送が約２分の時間間隔で開始されるように、１２ｋビット／秒のビット・レートで伝送される。セグメントは、論理パケットにマッピングされ、２０４８０個のセグメントが、１２８０個の論理パケットに、または１６個のセグメントからなる１２８バイトにマッピングされる。ストリーム内のパケットの位置（location）を、スロットと称する。

クライアント・デバイスが予測可能な形でフレーム・ヘッダ・パケットを取り出すことができるように、フレーム・ヘッダは各伝送フレームの所定のスロット（たとえば、フレーム伝送の最初のパケット）に現れる。フレーム・ヘッダ・パケットには、フレーム番号、タイム・スタンプ、タイム・ゾーン・オフセット、地域定義、および目次（ＴＯＣ）位置定義の複数のフィールドを含めることができる。ＴＯＣ位置定義フィールド（ＴＯＣ位置）は、フレーム伝送シーケンスに現れる１つまたは複数の目次のスロット位置を識別する。各後続フレーム伝送には、異なる数の目次を参照することができる別のヘッダが含まれる。フレーム・ヘッダ・パケットを除いて、複数のパケットは、識別されるサービスおよびクライアント・デバイスに常駐する対応するアプリケーションによってフレキシブルに定義される。

フレーム・ヘッダがある伝送から受信されない、いくつかの例において、ある種のパラメータは、前回（最後に）受信されたフレーム・ヘッダに基づいて推定されることができる。１例では、フレーム番号を、現在時刻および最後の既知のフレーム番号に基づいて推定することができる。もう１つの例では、現在時刻が、最後に受信したフレーム・ヘッダに関連する時刻に基づいて推定される。本明細書に記載の議論において、用語「フレーム番号」および「現在時刻」は、推定されたフレーム番号および推定された時刻も指す。

フレーム番号は、０から始まり、各後続のフレーム伝送に比例して増分される通し番号である。フレーム番号は、実用上、後続の伝送シーケンスで繰り返されない。たとえば、新しいフレーム伝送が２分ごとに行われると、ある４バイトのフレーム番号は、１５０００年経たなければ現れない。フレーム番号は、暗号化および他のセキュリティ保護のシード（種）として使用することができる。

タイム・スタンプは、世界時（ユニバーサル・タイム）フォーマット（ＵＴＣ）であり、これによって、フレーム伝送の開始の世界時が指定される。ブロードキャスト・サーバは、サーバ側での、伝送についてのネットワーク待ち時間を考慮に入れて、伝送用のタイム・スタンプを調整する。クライアント・デバイスは、フレームのブロードキャスト・タイムおよび処理タイムを補正しなければならない。クライアント・デバイスは、クライアント・デバイスを現行のブロードキャスト地域の現在時刻と同期化する手段としてタイム・スタンプを使用することができる。

タイム・ゾーン・オフセットは、フレーム伝送が行われる地理的区域のタイム・ゾーンを示す。すべてのフレーム伝送が、特定の地理的区域内で行われる。１例では、地域が、グリニッジ標準時（ＧＭＴ）指定子に関連して定義される。

地域定義には、地域ＩＤ、コード・ネーム、および周波数のリストが含まれる。地域ＩＤの一つの例は、１６ビット値であり、クライアントが移動、通勤、および旅行のシナリオを管理できるように、現行のブロードキャスト地域を一意に識別する。クライアント・デバイスに、ホーム地理区域識別子を含めることができる。クライアント・デバイスは、地域ＩＤを識別し、ホーム地域に基づいてステーションを選択的に取り除くことができる。コード・ネームは、表示および／または情報の目的で現行のブロードキャスト地域のテキスト説明を提供する文字列である。周波数のリストは、現行のブロードキャスト（またはサービス）地域内で使用可能な（複数の）ラジオ周波数に対応する。ニューヨーク市などの大都市には多数のブロードキャスト・ステーションが含まれる可能性があるけれども、通常のシナリオでは、各地理的区域内にはわずかな数のブロードキャスト・ステーションしか含まれない。ステーション・リストについての各エントリの値は、ベースライン周波数からのオフセットに関して表すことができる。例示的なステーション・リスト・エントリは、８８ＭＨｚベースライン伝送周波数から、１００ｋＨｚオフセットで、１０８ＭＨｚまでの範囲（ＦＭブロードキャスト・スペクトル）にわたるそれぞれに対応する複数のエントリを含めることができる。したがって、１１３のステーション・リスト値は、８８ＭＨｚからの１１．３ＭＨｚオフセットに、または９９．３ＭＨｚの周波数に対応する。特殊な値（たとえば０ｘＦＦ）を使用して、ステーションなしを示すことができ、別の特殊な値（たとえば０ｘ００）を使用して、（１６個以上のステーションが存在する地域用に）ステーション・リストが次のフレーム伝送で継続されることを示すことができる。

クライアント・デバイスは、ステーション情報が使用して、ステーション割り当て手順を使用してそれ自体を特定の周波数に割り当てる。割り当て未完のクライアント・デバイスは、周波数範囲全体（たとえば、８８ＭＨｚ〜１０８ＭＨｚ）をスキャンして、フレームを見つける。フレームが識別されると、クライアント・デバイスは、ステーション・リストを受信し、ステーション割り当て手順を使用してステーション（たとえばホームステーション）を選択する。その後、クライアント・デバイスは、選択されたステーションからのパケット受信を開始する。クライアント・デバイスがステーション割り当てを行うと、クライアント・デバイスは、信号を見失うか、サーバがリストを変更する（たとえば、目次内のフラグがヘッダの変更を示すようにセットされる）まで、後続フレーム中のステーション・リストを無視することができる。

ステーションが、地理的区域内で使用不能になると、フェールオーバー状態が発生する。たとえば、サービス地域内のブロードキャスト塔の数が、変更される場合があり、特定のブロードキャスト塔が、使用不能になる場合がある。フェールオーバー状態は、予期されない形でブロードキャスト塔がオフラインになるか、他の障害状態の結果として生じる。ステーション・リストは、フェールオーバー条件が発生した際に、または追加のステーションが使用可能になった際に、地域ＩＤによって与えられる現行の地理的地域内で使用可能なステーションを発見する手段として役立つ。

フレーム番号（または推定されたフレーム番号）およびパケット番号は、暗号化アルゴリズムの初期化ベクトルを決定するのにも使用することができる。暗号化処理では、サービス鍵および初期化ベクトルを使用して、パケットを暗号化し、暗号化解除する。たとえば、共用データ・サービスのパケットの暗号化および暗号化解除に、１２８ビットのサービス鍵が必要になる場合がある。クライアント・デバイスは、すべての登録されたブロードキャスト・サービスのサービス鍵を有する。登録されたブロードキャスト・サービスのデータ・ストリームを、その１２８ビットサービス鍵から暗号化解除することができる。

ブロードキャスト・サーバ（スケジューラとも称する）によって、すべての連続するフレーム伝送について、フレーム番号が増分される。例示的なフレーム番号フィールドは、４バイトの長さである。クライアント・デバイスは、フレーム番号をフレーム・ヘッダから抽出し、そのフレーム番号を評価して、そのフレームがリプレイ・アタック（replay attack）であるかどうかを判定する。リプレイ・アタックは、オリジナルのフレーム伝送からの複数のフレームを記録し、後に、同一のフレーム番号を用いてそれらのフレームをブロードキャストする攻撃者によって構成される認識されないブロードキャストに対応する。

攻撃者は、フレームのフレーム番号を許容可能な値に変更することによって、リプレイ・アタックのバリエーションを試みることができる。しかし、フレーム番号が、フィードバック・モード・パケット暗号化における初期値を計算するシードとして使用される場合には、この攻撃者のリプレイ・アタックのバリエーションは、有効でない。オリジナルのフレーム・ブロードキャスト伝送は、フレーム番号を使用するパケット暗号化を含んでいるので、攻撃者のリプレイ・アタックのバリエーションには、正しい暗号化が含まれないことになり、この結果、クライアント・デバイスは、そのパケットを無効として破棄することになる。このように、フレーム番号を、パケット暗号化の手段として使用することができる。

ＴＯＣ位置定義は、フレーム伝送で見つかる目次の数およびフレーム内での目次の位置を指定する。フレーム・ヘッダ内で識別される目次の位置は、フレーム・ヘッダによって指定される伝送シーケンス内の変化する位置に現れる可能性がある。ＴＯＣ位置定義は、フレームに、可変サイズ構造を作り出す。ＴＯＣ位置は、リストまたは配列として維持することができる。このリストまたは配列の各要素は、伝送されるフレーム内で目次を見つけられる論理パケットへの参照（たとえばインデックス）を含む。ＴＯＣ位置定義に、ＴＯＣのフォーマット・タイプ、エラー訂正モード、およびエラー訂正設定を含めることができる。フォーマット・タイプの例は、ＰＤＡ、ポケットＰＣ、ＸＢＯＸなどのタイプによってデバイスの機能に関連付けられるクラス記述子である。フォーマット・タイプのもう１つの例が、プロトコル・バージョン番号によってデバイス機能に関連付けられるクラス記述子である。

目次（ＴＯＣ）
各目次は、次のフレーム伝送に現れる共用データ・ストリームを識別する。クライアント・デバイスは、優先順位に基づいて、共用データ・ストリームの受信をスケジューリングする。多くのクライアント・デバイスが、限られたリソースを有するので、優先順位付けは、ユーザとの対話（user interaction）によって、またはブロードキャストされるサービスへの加入に関連する予め定められた選択によって、決定することができる。

各ＴＯＣパケットは、前に説明したように、ＴＯＣ位置定義で記述される特定の論理パケットに配置される。ＴＯＣパケットには、フラグの組および図５に示されたＴＯＣ範囲記述子（range descriptor）が含まれる。フラグは、８ビットの範囲とすることができ、ＴＯＣ範囲記述子は、３２エントリまでの配列（またはリスト）とすることができる。ＴＯＣ範囲記述子は、ＴＯＣパケットに関する最も外側の記述子であり、単に、範囲記述子の集合（たとえばＴＯＣ Ｒａｎｇｅｓ［ ］）を参照する。各ＴＯＣ範囲記述子（たとえば、ＴＯＣ Ｒａｎｇｅ０）は、初期位置およびＴＯＣスロット指定子（たとえば、ＴＯＣ ｓｌｏｔｓ［ ］）を有する。範囲記述子の初期位置は、伝送されるフレーム内の範囲についての初めのパケット・オフセットを示す１１ビット値とすることができる。ＴＯＣスロット記述子は、範囲内のスロットの組（たとえば、ＴＯＣ スロット０：ＴＯＣ スロットＮ）を記述する配列（またはリスト）とすることができる。

フレーム内のＴＯＣ範囲記述子の例を、図６に示す。データのストリームが、フレーム内で経時的に伝送される。範囲０は、初期位置（位置１）と、０から２までの番号の３つのスロットによって定義される。スロット０（Ｒ０）には、４つの論理パケットが含まれ、スロット１（Ｒ０）には、２つの論理パケットが含まれ、スロット２（Ｒ０）には、４つの論理パケットが含まれる。範囲１は、伝送のギャップの後に受信される。伝送ギャップは、プライベート・データ・ストリームなどの共用データ・ストリーム以外のサービスまたはなんらかの他の副サービスによって使用することができる。範囲１は、初期位置（位置２）およびスロット０から３までの番号の４つのスロットによって定義される。スロット０（Ｒ１）に、８つの論理パケットが含まれ、スロット１および２（Ｒ１）のそれぞれに、２つの論理パケットが含まれ、スロット３（Ｒ１）に、４つの論理パケットが含まれる。この例によって示されるように、各範囲は、ＴＯＣ範囲記述子による指定される異なった初期位置を有することができ、異なる数の関連スロットを有することができる。スロットのそれぞれが、すべての範囲について同一サイズである必要はなく、所与の範囲についてＴＯＣスロット記述子によって識別されるように、その範囲を変えることができる。

ＴＯＣスロット記述子に、サービスＩＤ、ストリーム・ロケータ、パケット・カウント、エラー訂正設定、およびフレーム予約というフィールドを含めることができる。サービスＩＤは、ストリーム・タイプを指示する１６ビット値によって特定の放送サービスを指定することができる。ストリーム・ロケータは、アプリケーション・レベル・データ・ハンドラによって使用される１６ビット不透明値（opaque value）とすることができる。パケット・カウントは、スロットに含まれるパケットの数を示す２ビット値とすることができる。エラー訂正設定は、ストリームによって使用されるエラー訂正方法のタイプを識別する３ビット値とすることができる。フレーム予約は、スロット割り当てが複数のフレームに関する所与のサービスＩＤについて有効であることをスケジューラが保証する長さを示す３ビット値とすることができる。

共用データおよびデータ・ハンドラ
共用データは、複数のクライアントについて企図されたデータ・ストリームに関連付けられ、ブロードキャスト・サービスに関連付けられる。共用データにアクセスする各クライアントは、暗号化鍵、適当なクライアント側アプリケーション、および制御データという形の有効なアクセス（権）を有しなければならない。共用データは、アプリケーション層セマンティクスを複数のパケット・リクエストおよびメッセージ再組み立てに変換する複数のハンドラから成るセットを介して管理される。

クライアント・デバイスのアプリケーションは、トランスポート層に登録される。トランスポート層は、登録されたアプリケーションごとにデータ・ハンドラを維持し、ネットワーク層から受け取られる論理パケットからＴＯＣを取り出す。トランスポート層は、登録されたアプリケーションに、サービスＩＤを用いて識別される次のフレーム伝送でデータ・ストリームが使用可能になることを通知する。各アプリケーション・プログラムによって、一連のメトリックスが適用されて、データ・ストリームの受信の優先順位が決定され、このデータ・ストリームは、クライアント・デバイスのトランスポート層にサブミットされる。優先順位付けは、優先データ（preferred data）、エラー訂正要件、ならびに、ベースの順位レベルおよび高められた優先順位レベルなどの判断基準に基づいて、クライアント・デバイスの各アプリケーションによって独立に実行される。トランスポート層によって、すべてのリクエストが再検討（review）され、どのリクエストが受け入れられるかが判断され、受け入れられたリクエストがネットワーク層へのパケット・リクエストに変換される。ネットワーク層によって、次のフレーム伝送内の関連するパケットが引き出され、そのパケットが、データ・ハンドラを介して関連する登録されたアプリケーションに渡される。

フィード（feed）は、クライアント・デバイスの対応するアプリケーションによって処理することができる完全なデータ・ストリームに対応し、特定のブロードキャスト・サービスに関連する完全なデータ・ストリームに、対応する。共用データ・ストリームは、フィードに関連付けられたタイプによるフレーム伝送内に配置される。クライアント・デバイスには、そのデバイスに常駐するアプリケーションごとの、特定のブロードキャスト・サービスに関連付けられている、データ・ハンドラが含まれる。クライアント・デバイスは、ＴＯＣスロット記述子から受け取られるサービスＩＤに基づいて、特定のブロードキャスト・サービスを識別する。以下で説明するデータ・ハンドラの例に、ｃｏｍｐａｃｔタイプ、ｓｐａｒｓｅタイプ、およびｌｏｎｇタイプが含まれる。しかし、フレーム・プロトコルに影響せずに、データ・ハンドラを変更でき、かつ／または追加データ・ハンドラを追加することができる。各アプリケーションおよび一致するブロードキャスト・サービスによって、ＴＯＣスロット記述子のサービスＩＤによって識別されるような特定のタイプのデータを処理する挙動を定義することができる。

ｃｏｍｐａｃｔデータ・タイプは、メッセージ全体が、単一のパケットに含まれるように、パケットとメッセージの間の１対１関係を有する。ｃｏｍｐａｃｔデータ・タイプは、ヘッダ情報を全く必要としない。ｃｏｍｐａｃｔデータ・ハンドラは、ＴＯＣスロット記述子からのストリーム・ロケータを使用して、スロット内の最初のｃｏｍｐａｃｔメッセージの開始位置を決定する。後続の１パケット・メッセージは、開始位置に続き、１度に１パケットだけオフセットされる。ＴＯＣスロット記述子のパケット・カウントは、ブロードキャスト・サービスに関連付けられたｃｏｍｐａｃｔメッセージの総数を示す。ｃｏｍｐａｃｔメッセージの例が、株式チャネル・ブロードキャスト・サービスの株式市況（stock quote）である。株式チャネルのブロードキャスト・サービスは、クライアント・デバイスのアプリケーションについてインデクシングされる、一連の予約された株式市況（たとえば、ＭＳＦＴ、ＩＢＭ、ＯＲＣＬなど）を有することができる。このタイプのデータ・ストリームについて、ストリーム・ロケータは、クライアント・デバイスの株式チャネルアプリケーションに基づく株式市況メッセージの開始位置を識別する。それぞれの後続する株式市況は、ストリーム・ロケータによって識別される開始位置の後に、順番に続く別々のメッセージである。

ｓｐａｒｓｅデータ・タイプは、複数のパケットを介して配布されるデータ・ストリームである。クライアント・デバイスのアプリケーションは、ＴＯＣから取り出される情報（たとえばサービスＩＤ）に基づいて、データをトランスポート層に要求する。ｓｐａｒｓｅデータは、複数、通常は６つ未満のパケットにまたがって、データ保全性およびサービス品質を保証することができる。ｓｐａｒｓｅデータ・ストリームの各パケットは、フラグメントと呼ばれ、各メッセージが、少なくとも１つのフラグメントを有する。各パケットのヘッダは、クライアント・デバイスの対応するアプリケーションによって引き出され、フラグメントの番号が識別されて、完全なメッセージおよびメッセージ内の現行のパケットのフラグメント番号が形成される。ＴＯＣ範囲記述子のストリーム・ロケータによって、ｓｐａｒｓｅデータ・ストリーム内の最初のフラグメント（またはパケット）の位置が示される。各個々のパケットは、最初のパケット位置からのオフセットとして見られる。

ｓｐａｒｓｅデータ・ストリーム・メッセージの例は、ニュース・チャネル・ブロードキャスト・サービスのニュース記事である。ニュース・チャネルのブロードキャスト・サービスは、ニュース記事に関連するテキストのすべてをクライアント・デバイスに転送するのに、情報の複数のパケットを必要とする場合がある。ニュース記事は、単一の伝送フレームにおさまらない可能性がある複数のパケットに分割され、各パケットには、データ・ストリーム全体のどこに特定のパケット（またはフラグメント）が配置されるかを識別するパケット（またはフラグメント）番号と、ニュース・ストリームを識別するサービスＩＤとが含まれる。

ｓｐａｒｓｅデータ・タイプのＴＯＣスロット記述子の例を、図７に示す。ＴＯＣスロット記述子は、クライアント・デバイスに、特定のアプリケーションに関連付けられたサービスＩＤ（service ＩＤ）、データ・ストリーム内のストリーム・ロケータ（stream locator）、およびそれに続くパケット番号（packet count）を提供する。図７に示された例では、ブロードキャスト・サーバ・アプリケーションによって、４つのパケットが与えられ、メッセージ＃５６９の最後の２つのフラグメントおよびメッセージ＃５７０の２つのフラグメントの送信が選択されている。これは、このブロードキャスト・サーバ・アプリケーションに４つのパケットが最後に与えられた時に、＃５６８および＃５６９の最初の２つの送信が選択されたと仮定している。アプリケーション層に関する内容をシリアル化解除する前に、クライアントによってメッセージのすべてのパケットが収集される。

ｌｏｎｇデータ・タイプは、ファイルの転送など、メッセージ全部が、多量のパケットを介して分配されるデータ・ストリームである。ｌｏｎｇデータ・タイプは、サービスＩＤとメッセージ番号の間に１対１の関係を有する。ｌｏｎｇデータ・ストリームに対して、エラー訂正コードが、そのデータ・ストリームの末尾に追加されて、通信チャネルを介するデータ保全性が保証される。ＴＯＣスロット記述子内のストリーム・ロケータが、パケットの範囲を複数のスロットにまたがって延長するシーケンス番号を表すのに使用される。たとえば、ｌｏｎｇデータ・ストリームが、６Ｋのデータを必要とする場合がある。しかし、サーバ側のスケジューラ・プロセスが、各フレームの４スロットをｌｏｎｇデータ・ストリームに割り当て、各スロットに８パケットが含まれる場合がある。ｌｏｎｇデータ・ハンドラは、６Ｋのデータを８つのパケット・ブロックに分割し、各ブロックに０から始まるシーケンス番号を割り当てる。

プライベート・データ
特定の加入者に充てられるデータは、プライベートであるとみなされる。プライベート・データは、加入者によって識別されるすべてのデバイス（たとえば、複数のデバイス）に、または単一の加入者デバイスに、向けることができる。プライベート・データは、複数のパケットにまたがることができるメッセージとして供給され、各パケットが、メッセージ全体の１フラグメントを構成する。プライベート・データを、プライベート・メッセージまたはパーソナル・メッセージと称する場合もある。パーソナル・メッセージは、サービスＩＤがなく、共用メッセージに関して説明した目次が使用されない。

プライベート・メッセージには、メッセージＩＤ、メッセージ内のフラグメント、フラグメント・インデックス、フレームごとのプライベート・パケット、およびデータのフィールドを含むヘッダが含まれる。サーバは、１０ビット値のメッセージＩＤを確立して、メッセージを識別し、重複を防ぐ。各プライベート・メッセージは、メッセージ内のフラグメントの６ビット値によって識別される複数のパケットとして編成される。各パケットは、現行のパケットがプライベート・メッセージ内のパケットの総数のどこにおさまるかを示すフラグメント・インデックスの６ビット値によってインデクシングされる。フレームごとのプライベート・パケット・フィールドは、クライアントが要求しなければならないパケット数を示す２ビット・フィールドに対応する。データ・フィールドは、プライベート・メッセージについてフラグメントのすべてが受信された後にシリアル化が解除される実際のデータ・バイトである。

プライベート・メッセージについての許可されない受信を防ぐために、プライベート・メッセージは、暗号化鍵を用いて暗号化され、各クライアントに、プライベート・メッセージが配置されるフレーム内の位置の組（set）が割り当てられる。その位置は、（単一の加入者に属するすべてのデバイスによって使用される）加入者ＩＤおよび現行のフレーム番号の組合せを使用して、アルゴリズムによって決定される。クライアントのプライベート・メッセージが配置されるフレーム内の特定の位置（たとえばスロット）の決定に、ハッシュ関数（hash function）が適用される。サーバおよびクライアントの両方が、一切情報を通信することなく加入者ＩＤを知っており、この結果、伝送フレーム内のプライベート・メッセージの位置に、直接の相互作用なしで到達することができる。

プライベート・メッセージは、単一のフレーム時間（たとえば２分）を超えることがない、待ち時間を有する。単一の加入者が特定のパケット位置をめぐって競合する場合はほとんどないので、サーバは、上昇する（escalating）優先順位を使用して、すべての加入者がデータを公平に受信するようにする。フレーム内を多少ランダムにジャンプすることによって、高い優先順位の競合者とのコンフリクト（conflict）の繰返しという悪化した事例が回避される。

デフォルトで、各フレームが、複数のパーティションに分割される。クライアントは、サーバが伝送に関して示したプライベート・パケットの数に従って、１つからｎ個までのパケットを要求する。要求された各パケットが、擬似ランダム的に割り当てられたスロットおよびパーティションにマッピングされる。各加入者は、プライベート・メッセージが許可されないクライアントによって再構成されないように、伝送フレームごとにスロット／パーティション割り当ての一意の組を有しなければならい。複数のパーティションは、等しい量または等しくない量のサイズにすることができる。特定のクライアントは、１つのパーティションに、あるいは、擬似ランダム割り当て方法に基づいて異なるパーティションに、そのスロット割り当てを配置させることができる。

１例では、スロットおよびパーティションの割り当ては、下記のアルゴリズムによって決定される。
１）一意ＩＤおよびスロット・インデックスを使用して、パーティション割り当てのためのハッシュ値を計算する。
２）フレーム伝送内のパーティションの総数によってパーティション割り当てのためのハッシュ値を切り詰めて、一意ＩＤの初期位置を定義する。
３）切り詰められたハッシュ値にフレーム番号を加算し、その結果、各デバイスがすべてのパーティションをサイクル（循環）するようにする。
４）パーティションの開始位置および終了位置を明示する。
５）一意ＩＤ、フレーム番号、およびスロット・インデックスを使用して、パーティション内のスロット割り当てのためのハッシュ値を計算する。
６）スロット割り当てのハッシュ値を縮小（collapse）して、この結果、縮小された値が、選択されたパーティションのサイズにおさまるようにする。
７）パーティションの開始位置を縮小されたハッシュ値に加算して、要求されたスロットのパケット番号を決定する。
８）インデックス０、１、２および３について、ステップ１から７を繰り返す。

パーティションおよびスロットの判定のアルゴリズムの例を、下に擬似コードによって示す。このアルゴリズムでは、一意ＩＤ、フレーム番号、および伝送フレーム内にあるパーティションの数を使用して、パーティション位置およびスロット位置を擬似ランダムに選択する。このアルゴリズムは、下に記載されているように、４つの部分（ComputePacketSlot、Hash、HashArray、およびCollapse）に分解される。
public ushort ComputePacketSlot(
byte[] uniqueID,
uint frame,
uint index,
int numOfPartitions,
ushort[] PartitionStart,
ushort[] PartitionEnd)
{
uint partition = (Hash( uniqueID, 0xFFFFFFFF, index ) + frame) % numOfPartitions;
uint slot = Hash(uniqueID, frame, index);
ushort selectedPartitionStart = PartitionStart[partition];
usbort selectedPartitionEnd = PartitionEnd[partition];
ushort selectedPartitionSize = selectedPartitionStart - selectedPartitionEnd;
return (ushort)Collapse( slot, selectedPartitionSize ) + selectedPartitionStart;
}

static public uint Hash( byte[] data, uint frame, uint slot)
{
byte[] val = data + frame + slot;
return HashArray( val);
}

static public uint HashArray( byte[] data)
{
uint hash = 0;
int offset = 0;
int len = data.Length;
while(len-- > 0)
{
hash += data[offset++];
hash += (hash << 10);
hash ^= (hash >> 6);
}
hash += (hash << 3);
hash ^= (hash >> 11);
hash += (hash << 15);
return hash;
}

static private uint Collapse( uint slot, uint size)
{
uint res = 0;
uint rem;
while(slot != 0)
{
rem = slot % size;
slot /= size;
res ^= rem;
}
return res % size;
}

特定のクライアントのプライベート・メッセージの例を、図８に示す。フレームは、パーティション（たとえば、５つの等しいサイズまたは等しくないサイズのパーティション。）に分割される。クライアント（または加入者）に関連付けられた各プライベート・データ・パケットが、第１のハッシュ関数を使用して、パーティションの１つに擬似ランダムに割り当てられる。クライアント（または加入者）に関連付けられた各プライベート・データ・パケットは、それぞれのパーティション内の擬似ランダムに選択されたスロット位置に割り当てられる。このスロット位置は、第２のハッシュ関数から決定される。図８に示されているように、スロットおよびパーティションの割り当ては、フレーム番号、一意ＩＤ、および要求されたパケット数（スロットごとに１パケット）から決定される。

各クライアント・デバイスは、「デバイス鍵（device key）」と称する一意の１２８ビット鍵を有する。デバイス鍵は、変更できなくするために工場でチップをレーザバーニングするなど、変更できない永久的な鍵であることが好ましい。デバイス鍵は、アクティベーション（activation）メッセージを暗号化するのに使用される。デバイス鍵は、特定のクライアント・デバイス（同一の加入者に登録されたすべてのデバイスではなく）宛のメッセージを暗号化するのにも使用される。

各加入者は、「加入鍵（subscription key）」（または「制御鍵（control key）」）と称する一意の１２８ビット鍵を有する。加入鍵は、ユーザがプライベート・メッセージング・サービスに加入する時に生成される。デバイス・アクティベーション中に、加入鍵が、デバイス鍵を用いて暗号化されてクライアント・デバイスに伝送される。その加入者に関するすべての後続のパーソナル・メッセージが、加入鍵を使用して暗号化される。

各ブロードキャスト・サービスは、「サービス鍵（service key）」と称する一意の１２８ビット鍵を有する。すべてのブロードキャスト・メッセージが、サービス鍵を用いて暗号化される。構成および使用法を単純にするために、サービスは、ティア（tiers）にグループ化される。あるティアのすべてのサービスが、同一の暗号化鍵を共用する。ユーザが、サービスに加入する時に、ユーザは、パーソナル・メッセージとして、加入鍵を用いて暗号化されたサービス鍵を受信する。サービス鍵は、請求期間ごとに１回など、周期的に変更され、その結果、サービスについて支払ったユーザだけがサービス鍵を受信するようにすることができる。

特殊なアルゴリズムが、鍵から値を導出するために使用される。このアルゴリズムは、鍵を用いて既知の文字列（たとえば「hello world」）を暗号化すること、および要求された数のビットを抽出することからなる。この導出された値は、「鍵署名（key signature）」と命名され、以下で説明するように、複数の目的に使用される。

デバイス鍵の署名は、デバイス識別子として使用される。ユーザは、デバイスを登録する時に、ウェブサイトにこの識別子を入力する。この鍵生成処理は、一意の署名を有する鍵だけが使用されることを保証する。デバイス鍵の署名は、（デバイスがアクティブ化される前に行われ、デバイスがまだ加入鍵を受信していない前に発生する）フレーム内でのアクティベーション・メッセージのスロット位置を計算するための種として使用される。

デバイス鍵の署名は、このデバイスのアクティベーション・ステーションを計算するための種としても使用される。１例では、一意の識別子が、クライアント・デバイスに関連付けられた一意の通し番号に対応する。一意のコードの例を、１２８ビット・コードとすることができ、この場合に、一意のコードの３２ビットが、サービス地域内で使用可能な塔のリストから塔割り当てを決定するオフセット量として使用される。たとえば、オフセット＝Ｎ ｍｏｄｕｌｏ ｎであり、このＮは、一意のコードからの３２ビットに対応し、ｎは、サービス地域内で使用可能なステーションの数である。

加入鍵の署名（署名ＩＤまたは一意ＩＤ）は、アクティベーションが受信された後にフレーム内のパーソナル・メッセージのスロット位置を計算するための種として使用される。加入鍵の署名は、（デバイスが、パーソナル・メッセージをリスンする）このデバイスの割り当てられるステーションを計算するためのシードとしても使用される。

ブロードキャスト・サーバは、特定のクライアントに伝送されるプライベート・メッセージを、上の説明に類似する方法でエンコードするように手配（arrange）される。ブロードキャスト・サーバは、すべてのクライアント・デバイスの一意の制御鍵を知っている。各パーソナル・メッセージは、クライアント・デバイス用の一意の制御鍵および一意識別子に従ってエンコードされる。パケット暗号化アルゴリズムは、２つの値を使用する。一方は、固定された値（鍵）であり、他方は、変数（初期化ベクトル、すなわち「ＩＶ」）である。このＩＶは、フレーム番号およびパケット番号を使用して計算される。フレーム番号は、フレームごとに増分されることが保証されているので、ＩＶは、必ず異なる。１例では、ブロードキャスト・サーバは、クライアント・デバイスによって計算される１２８ビットコードと同一の１２８ビットコードを計算する。ブロードキャスト塔およびパーソナル・メッセージ・チャネルの自動割り当ては、上で説明した自己割り当て手順を使用して決定される。

パーソナル・メッセージを取り出すデフォルトの方法は、フレームごとに４パケットを得ることを試みることである。これは、バッテリ寿命に対してコストが高い動作であるが、サインアップまたはデバイス・リセットなどの鍵シナリオでの待ち時間を減少させる。各プライベート・データ・パケット内のフレーム・フィールドごとのプライベート・パケットは、後続フレームでクライアントが取り出しを試みるパケット数を示すために、サーバによって使用することができる。このことは、サーバが実際にその数のパケットを移植することまたはクライアントが同数のパケットを成功裡に受信することになるを保証するのでないことを理解されたい。そうではなく、むしろ、これは、ヒント以上のものとして解釈される。

パケットは、上で説明したさまざまな鍵に基づいて、クライアントごとに暗号化される。１例では、その暗号化は、クライアント（または加入者）に対応する加入者鍵を使用してハッシュ（hash）を計算することによって達成される。このハッシュは、パケット伝送に含まれる。クライアント・デバイスは、プライベート・メッセージ・パケットで伝送されたハッシュが、クライアント・デバイスによって計算されたハッシュと一致しない時に、そのプライベート・メッセージ・パケットを無視する。プライベート・メッセージを正しく解釈するためには、プライベート・メッセージ・ペイロードが、クライアントの鍵（加入者鍵）を用いて暗号化される必要がある。暗号化に加えて、擬似ランダムのスロット割り当ておよびパーティション割り当ては、プライベート・メッセージの許可されない受信を防止する。ハッシュは、Ｄａｖｉｅｓ−Ｍｅｙｅｒ、ＭＤ５、ＳＨＡ１、または他の適当なハッシュ手順を使用して、計算することができる。

制御データ
クライアント・デバイスは、クライアント・デバイスのアプリケーションが使用に関して登録されるまで、ブロードキャスト・サービスを取り出すことができない。前に述べたように、正しい動作を可能にするために、暗号化鍵、アプリケーション、およびハンドラの組が、クライアント・デバイスに存在している。当初は、クライアント・デバイスは、制御データまたはメッセージの形の最小限の情報を取り出すことができる。制御メッセージは、動作情報（operational information）をクライアントに通信する手段を提供する。

アクティベーションおよびデアクティベーションの制御メッセージは、各加入サービスに対する暗号化鍵の取り出し、またはクライアント・デバイスからの加入の取消、に使用することができる。デフォルト・ブロードキャスト・チャネル割り当てと同じように、ホーム地域割り当ては、制御メッセージの形でクライアント・デバイスに通信される。

ブロードキャスト・サーバ・フレーム・スケジューリング
図４Ａから４Ｄに関して前に説明したように、ブロードキャスト・サーバは、各フレームで伝送されるデータを選択するように、手配される。所与の伝送フレームに対するデータの選択は、各ブロードキャスト・サービスによって割り当てられる優先順位レベルおよびフレーム・スケジューラによって適用されるサービス品質メトリックスに基づいて、決定される。

スケジューラは、伝送帯域幅が完全に利用されるように、優先順位スケジューリングを用いてトラフィックの負荷を平均化する。データ・ストリームは、プライベート・データ、共用データ、および制御データなどの異なるデータ・タイプのものとすることができる。前に説明したように、プライベート・データは、単一のユーザに向けられ、他方、共用データは、クライアント・デバイスの複数のグループにブロードキャストされる。制御データは、単一のクライアント・デバイス、またはクライアント・デバイスのグループに通信され、ブック・キーピング（bookkeeping）および構成の情報を通信する。

スケジューラは、分散モデルであり、スケジューリング機能のそれぞれの部分は、共用サービス、プライベート・メッセージ・サービス、および目次（ＴＯＣ）マネージャ用の複数のハンドラによって提供される。スケジューラは、図９を参照して説明するように、優先順位アルゴリズムに基づいて、次フレーム伝送内の複数のスロットに複数のパケットを割り当てる。

共用データのサービス・ハンドラおよびプライベート・データのサービス・ハンドラは、ＴＯＣマネージャに登録され、ＴＯＣマネージャは、スケジューラに登録される。伝送フレームを組み立てる前に、スケジューラは、スロットを生成するリクエストをＴＯＣマネージャにサブミットする（スロットを生成する）。ＴＯＣマネージャは、情報を更新して、最後の伝送シーケンスを反映する（スロットを再検討（review）する）。スロット割り当ての再検討は、以下で詳細に説明する。

クライアント・デバイスが、特定の情報についての指定されたスロット位置を当てにすることができるように、スロット割り当ては、複数の伝送シーケンスについて維持される。スロット記述子のフレーム予約フィールドは、スロット割り当てが持続する伝送シーケンスの数を指定する。ＴＯＣマネージャは、伝送シーケンスが完了すると、各スロット記述子のフレーム予約フィールドを減分することになる。０の値を有する対応するフレーム予約フィールドを有するすべてのスロットが、ＴＯＣマネージャによって、使用可能として再生利用される。しかし、以下でさらに詳細に説明するように、持続スロット割り当てをプライベート・メッセージによってオーバーライドすることができる。

スロット割り当てが再検討され、使用可能なスロットが再生利用された後に、ＴＯＣマネージャは、登録された共用データ・サービス・ハンドラに、スロットを更新するリクエストをサブミットする（スロット更新を要求する）。共用データ・サービス・ハンドラは、割り当てられたスロット記述子のロケータ・フィールドが更新されるように、リクエストを処理する（ロケータを更新する）。割り当てられたスロットに関連付けられたＴＯＣスロット記述子のフィールドは、ロケータ・フィールドの変化を反映するように更新され、ＴＯＣマネージャに返される。

ロケータ更新の例を、図７を参照して以下で説明する。メッセージ＃５６８から＃５７０は、ｓｅｒｖｉｃｅ ＩＤ １０２４によって識別される共用メッセージサービスに関連付けられる。メッセージ＃５６８に関する完全なメッセージに、２つのパケットが含まれる。メッセージ＃５６９に関する完全なメッセージに、４つのパケットが含まれる。メッセージ＃５７０に関する完全なメッセージに、２つのパケットが含まれる。前のニーズ・リクエスト（needs request）（以下の説明を参照）は、４パケットの長さ（packet count=4）のｓｅｒｖｉｃｅ ＩＤ １０２４によって識別されるサービスへのスロット割り当てを結果として生じさせた。最初の伝送シーケンスのＴＯＣスロット記述子は、１０２４の第１のｓｅｒｖｉｃｅ ＩＤ、１８の第１のｓｔｒｅａｍ ｌｏｃａｔｏｒ、および４の第１のｐａｃｋｅｔ ｃｏｕｎｔが含まれる。最初の伝送シーケンスの後に、共用サービス・ハンドラによって、ＴＯＣスロット記述子が更新され、第２の伝送シーケンスのＴＯＣスロット記述子に、１０２４の第２のｓｅｒｖｉｃｅ ＩＤ、２２の第２のｓｔｒｅａｍ ｌｏｃａｔｏｒ、および４の第２のｐａｃｋｅｔ ｃｏｕｎｔが含まれるようになる。メッセージ＃５６９は、２つのフラグメント（２つの別々の伝送）に分割される共用データ・ストリームの例である。

ＴＯＣスロット記述子が更新された後に、ＴＯＣマネージャは、登録された共用データ・サービス・ハンドラにニーズを要求するメッセージをサブミットする（ニーズを要求する）。共用データ・サービス・ハンドラは、その共用データ・サービスに関連付けられた伝送ヒストリを再検討し、次の伝送フレームに必要なスロットおよびパケットの数を決定する。共用データ・サービス・ハンドラは、それ自体のニーズ・リクエストに優先順位を付け、次のフレーム伝送のニーズ・リクエストを決定する。ニーズに関するリクエストには、要求される優先順位およびスロットに関連付けられるパケットの所望の数（たとえば、スロットについて、１、２、４、８、１６パケット）が含まれる。前に述べたように、各アプリケーションまたは各共用データ・サービスは、メッセージの伝送に関するそれ自体の優先順位を自由に決定できる。複数のニーズ・リクエスト（ニーズ）が、ＴＯＣマネージャに供給される。

次に、ＴＯＣマネージャは、プライベート・データ・サービス・ハンドラにオーバーライドを要求する（オーバーライドを要求する）。各プライベート・データ・サービス・ハンドラは、次のフレーム伝送に関するニーズを決定する。プライベート・データ・サービス・ハンドラは、前に説明した擬似ランダム割り当て方法に基づいて、スロット割り当てを決定する。プライベート・データ・サービス・ハンドラは、ある数のプライベート・データ・パケット・スロットを次の伝送フレーム内に予約するように要求する。いくつかの場合に、メッセージは、即座の伝送を要求する緊急の形のメッセージであり、あるいは、プライベート・メッセージは、伝送されずに長時間の間待ち続ける。この場合には、プライベート・データ・サービス・ハンドラは、ＴＯＣマネージャに対するオーバーライド・リクエストを行い、プライベート・データ・メッセージを次のフレームの伝送で送信しなければならないことを示すことによって、そのメッセージが次の伝送フレームで伝送されることを要求することができる。

ＴＯＣマネージャは、共用データ・サービス・ハンドラからのニーズ・リクエストのすべておよびプライベート・データ・サービス・ハンドラからのオーバーライド・リクエストのすべてを再検討する。すべてのリクエストを再検討した後に、ＴＯＣマネージャは、次のフレーム伝送で共用データに割り当てられるスロットを割り振る。スロット割振りは、サービス・ハンドラによって要求された優先順位レベルに緩く基づき、サービス品質ならびに他のメトリックに基づいてスケジューラによって調整される。スロット割振りが完了した後に、ＴＯＣマネージャは、共用データ・サービス・ハンドラにメッセージを送信して（パケット生成を要求する）、次の伝送フレームでの割り振られた共用データ・スロットに関するパケットを要求する。

パケット生成のリクエストに応答して、共用データ・サービス・ハンドラは、ＴＯＣスロット記述子によって識別されるパケットによって、割り振られたスロットを満たす（スロットを満たす）。これらのパケットは、共用サービス・ハンドラによって暗号化され、特定のブロードキャスト・サービスに加入したクライアント・デバイスだけが、そのメッセージを成功裡に暗号化解除できるようになっている。共用サービスに割り振られたスロットのすべてが満たされた後に、ＴＯＣマネージャは、次の伝送フレームについてパケットを予約し、現行のフレームについてＴＯＣを更新する。前に述べたように、ＴＯＣは、次のフレーム伝送で使用可能になる共用データを識別する順方向のインデックスである。ＴＯＣマネージャは、現行の伝送フレームの目次と共に、満たされた共用データ・スロットをスケジューラに返す。

スケジューラは、プライベート・データ・メッセージ・ハンドラにメッセージを送って、プライベート・データ・パケットを要求する（プライベート・パケット生成を要求する）。プライベート・データ・メッセージ・ハンドラは、指定された（擬似ランダム割り当て方法を使用して前に決定された）スロットにプライベート・メッセージ・パケットを供給する。スケジューラは、フレームの組み立てを完了し、完成したフレームを、伝送のためにブロードキャスト・サーバに供給する。

プライベート・データは、共用データの後の未使用スロットに追加されるので、プライベート・データが、次フレーム伝送から外れてスケジューリングされることが繰り返される可能性がある。オーバーライド機能は、スロット割り当てをスティッキー（sticky）なスロット割り当てから離れて共用データ・ストリームに積極的に割り振ることによって、プライベート・データ・ストリームが阻止されなくするのに役立つ。２つのタイプのスロット割り当てを、オーバーライドの結果として行うことができる（早期および晩期のスロット・オーバーライド）。早期スロット・オーバーライドは、スロット・オーバーライド・リクエストが、ＴＯＣの組み立ての前に受け取られた際に結果として生じ、その結果、スロット割り当ては、（スロットが共用データ・サービスに割り振られる前）プライベート・メッセージ・オーバーライドによって、阻止される。晩期スロット・オーバーライドは、スロット・オーバーライド・リクエストが、スロットを割り当てるＴＯＣが既に伝送された後に受け取られる時に、結果として生じる。

前に説明したように、ＴＯＣスロット記述子に、特定の共用データ・サービスに関連付けられた複数の連続フレーム伝送を指定するフレーム予約フィールドが含まれる。フレーム予約フィールドは、スケジューラと共用データ・サービスの間の契約を形成する。晩期スロット・オーバーライドは、この契約に違反する。というのは、スロットが後にもう一度使用可能になるまで、通常は、スロットを他のサービスに割り振ってはならないからである。ＴＯＣは、オーバーライドを識別するために更新されない。プライベート・データは、暗号化されたフォーマットで伝送されるので、ＴＯＣによってインデクシングされるスロットは、不正なクライアント・デバイスによって無視され、正しい暗号化解除鍵を有する所期のクライアント・デバイスによって受け入れられる。

図９によって示されるように、ＴＯＣマネージャに登録された各サービスは、それ自体の優先順位付けを決定することができる。複数のサービスが、次の伝送フレーム内の複数のスロットについて競合するので、ＴＯＣマネージャは、最終的に、どのサービスを次のフレーム伝送のスロットに割り振るかを決定する。

ストリームの優先順位重みづけは、使用可能な帯域幅の使用を最大にし、適当なサービス品質をクライアント・デバイスに提供するために、さまざまなパラメータを使用して決定される。特定のサービスの優先順位を決定するのに使用される判断基準には、データ満了時刻、タイム・スタンプ、サービス・キューの長さ、サービスへの加入者の数、サービス品質、事前割り当てスロットのプリファレンス、１フレーム内でクライアント・デバイスによって取り出し可能なスロットの最大個数、および満足を与えるユーザ経験を提供するのに必要である可能性がある他のルールが含まれる。

データ満了時刻は、特定のサービスに関連付けられる可能性があり、データは、ある時間期間の後に失効する。時間依存サービス（time sensitive services）の例に、株式レポート、交通レポート、天気予報、ヘッドライン・ニュース、および星占いが含まれる。株式市況は、取引時間中は数分間だけ有効であるが、株式取引所がしまっている間は、丸１日有効である。交通情報は、３０分までに限って有用である可能性がある。ヘッドライン・ニュースは、数時間にわたって有効である可能性があるが、星占いは、丸一日有効である。時間依存データ・タイプの優先順位は、時間に依存する度合いが低いデータ・タイプより高い。

タイム・スタンプは、データ満了時刻にリンクされ、メッセージに関連付けられた再伝送の数にリンクされる。最小の数の伝送を有するサービスは、データ満了時刻が近づくにつれて高い優先順位を有する。

長いメッセージは、単一の伝送でクライアント・デバイスによって取り出し可能ではなく、通信の完了に複数の伝送を必要とする。長い伝送シーケンスに高い優先順位を割り当てることによって、長いメッセージが、少数の（あるいはより多くの）連続する伝送においてキューから取り除かれる。そうでなければ、長い伝送シーケンスは、非常に長い時間にわたってフレームに分割される可能性がある。可変データフローは、サービス・キューの長さ（length of service queue）を使用して処理される。

あるサービスに加入する加入者の数も、優先順位に関連する。たとえば、非常に多数の加入者を有するサービスは、加入者が非常に少ないサービスより高い優先順位を有する。

サービス品質は、すべてのサービスが、メッセージが伝送されるタイムスロットを有することを要求する。たとえば、非常に少数の加入者を有するサービスは、繰り返して時間的に後ろに押しやられ、その結果、伝送の頻度が低くなりすぎる場合がある。そのような人気の低いサービスは、高いサービス品質を維持するために、最小限の個数のパケットを送信するタイムスロットを有することができなければならない。

一部のクライアント・デバイスは、限られたメモリを有し、したがって、限られた数のメッセージ・パケットを受信することだけができる。クライアント・デバイスが、すべてのパケットを取り出すことができないので、スケジューラは、各サービスについて過多なメッセージ・パケットを送信してはならない。メッセージ・パケットのグループがクライアントの取り出し可能な量で送信されるように、優先順位が、メッセージ・パケットに割り振られる。

スケジューラは、目次を失ったクライアント・デバイスが、最後の既知のスロット割り当てからメッセージの受信を試みられるようにするために、各サービスに関するスティッキーな割り当てを維持することを好む。しかしながら、スティッキーな割り当ては、高い優先順位のメッセージによってオーバーライドされる可能性がある。前に説明したＴＯＣスロット記述子のフレーム予約フィールドは、スティッキーな割り当てを表す。

各サービス・タイプは、重み付け関数（Ｐｓ）に従って割り当てられる優先順位レベルを有する。たとえば、サービス（Ｓ）は、Ｐ_Ｓ＝ｆ（Ｖ_Ｓ、Ｗ_Ｓ）によって与えられる優先順位レベル（Ｐ_Ｓ）を有し、ここで、Ｖ_Ｓは、サービスＳの判断基準の値の組、Ｗ_Ｓは、判断基準に割り当てられる重みの組である。スケジューラは、各サービスの重み付けの値を調整して、最大のサービス品質を提供することができる。重み付け関数の例を下に示す。

クライアント・トランスポート層処理
クライアント・トランスポート層の処理を、以下で図１０に関して説明する。前に説明したように、クライアント・デバイスは、所与の時間に、限られた量の情報を受信することだけができる。クライアント・デバイスは、ネットワークからのデータ・ストリームについて競合する一連の常駐アプリケーションを有する。各アプリケーションは、そのアプリケーションに関連付けられたパケットのフォーマットを自由に定義できる。トランスポート層は、アプリケーションが必要とするセマンティクス（semantics）を知らず、その代わりに、ネットワーク層からの論理パケットの受取および分配（disbursement）だけにかかわる。しかし、複数のアプリケーションが、パケットに関して競合するので、トランスポート層は、各アプリケーションからのデータについてのリクエストに優先順位を付けなければならない。

アプリケーションは、そのアプリケーション用のハンドラがアクティブになる（または接続される）ようにトランスポート層に登録される。トランスポート層は、ネットワーク層から論理パケットを受け取る。トランスポート層は、フレーム・ヘッダを抽出して、論理パケットに関する目次の位置を見つけ出す。

目次は、論理パケットから抽出され、次のフレーム伝送で見つけ出すことになる使用可能なパケットに関する通知が、登録されたアプリケーションに対して行われる。登録されたアプリケーションは、それ自体のメトリックに基づいて、ネットワークからのデータ・リクエストに関連付けられたそれ自身の優先順位レベルを決定する。登録されたアプリケーションは、対応するハンドラを介して、トランスポート層に優先順位付きのデータ・リクエストを送る。トランスポート層は、優先順位付きのリクエストのすべてを受け取り、どのパケットが次のフレーム伝送で取り出されることになるかを決定する。トランスポート層がクライアント・デバイス受信能力を完全に利用するのに十分なリクエストを有するまで、または伝送フレームの終りが受け取られるまで、追加の目次を取り出すことができる。したがって、トランスポート層によって、ネットワーク層へのパケット・リクエストが行われる。

前に説明したように、クライアント・デバイスは、優先順位付けに基づいて共用データ・ストリームの受信をスケジューリングする。多数のクライアント・デバイスが、限られたリソース（たとえば限られたメモリ）を有するので、すべての可能なデータ・リクエストを同一のフレーム伝送で受信することが可能でない場合がある。クライアント・デバイスは、ユーザ対話に基づいておよび／またはブロードキャストされるサービスへの加入に関連する所定の選択によって、要求に優先順位を付ける。１例では、あるチャネルで株式市況を監視し、別のチャネルで他のより低優先順位のコンテンツ（たとえば、毎日の星占い）を監視するように、ユーザがクライアント・デバイスを構成することができる。株式市況は、取引所の営業時間中にすばやく変化する。株式レポートは、時間に敏感（株価がすばやく変化する）なので、株式チャネルは、取引所の営業時間中に高い優先順位レベルを有し、取引所の営業が終わった後に低い優先順位を有することができる。

次のフレーム伝送で、論理パケットが、ネットワーク層からアプリケーション・ハンドラに転送され、アプリケーション・ハンドラによって、メッセージ・ストリームが組み立てられる。１例では、ハンドラによって、完成したメッセージが識別され、完成したメッセージが、さらなる処理のためにアプリケーションに転送される。もう１つの例では、ハンドラによって、メッセージが過度に長い時間にわたって未完成のままであることが識別され、そのメッセージが無効として破棄される。アプリケーションは、メッセージを受け取り、必要に応じてメッセージを処理する。一部のメッセージは、暗号化または、一致するブロードキャスト・サービスの特定のニーズによって指定されるフォーマットのための処理を必要とする。

メッセージ伝送の例を、前に図７を参照して説明した。フレーム伝送の第１の例では、ｓｅｒｖｉｃｅ ＩＤ １０２４に一致するアプリケーションが、ｃｏｍｐａｃｔメッセージ＃５６８を受信する。この例では、メッセージ全体が、伝送フレームの単一スロットで受信されるので、ハンドラによる追加処理は不要である。フレーム伝送の第２の例では、ｓｅｒｖｉｃｅ ＩＤ １０２４に一致するアプリケーションが、ストリーム・ロケータ２２および２３によって識別されるメッセージ＃５６９のフラグメントを受信する。ハンドラは、受信された特定のパケットが、４パケット伝送の論理パケット３および４に関連付けられていることを認識する。アプリケーションは、次のフレーム伝送でのパケット１および２の受信を要求する。１例では、このメッセージの第２のフラグメントが受信され、完了メッセージが、ハンドラによって組み立てられ、アプリケーションに転送される。もう１つの例では、第２のフラグメントが、タイムリーな形で受信されず、そのメッセージが失効し、完了していないメッセージが、破棄される。

トランスポート層は、平均データ・ストリームを、各アプリケーションによって作られる優先順位付きの複数のリクエストを使用してバランスをとるスケジューラとして働く。したがって、クライアントベースのスケジューリングが、サーバ側とクライアント側の両方にまたがって分散される。サーバ側は、加入者サービス、プライベート・メッセージ、および制御データの伝送の頻度を決定し、クライアント側は、使用可能なデータのどれを取り出すかを決定する。プライベート・メッセージ・パケットは、ヘッダレスであり、目次によって参照を付けられないので、プライベート・メッセージ・パケットは、ネットワーク層からアプリケーション層に転送される。

コンフリクト検出
パーソナル・メッセージのコンフリクトは、前に説明した擬似ランダム・スロット割り当て方法によって回避される。しかし、コンフリクトをもたらす他の問題と同じように、エラーがフレーム伝送に発生する可能性がある。１例では、パーソナル・メッセージへの晩期スロット割り当てが、ブロードキャスト・データの目次エントリをオーバーライドする。この例について、クライアントは、目次で識別されるスロット割り当てに対応するパケットを取り出し、受信したそのパケットをコンフリクトとして検出する。その特定のスロットからのブロードキャスト・データ・パケットは、エラーなしで暗号解除できないので、破棄される（または無視される）。

図１１は、本発明に従って配置（arrange）された、コンフリクト検出手順の例を示す処理流れ図である。処理は、ブロック１１０１で開始され、ブロック１１０２に進む。
ブロック１１０２で、暗号化解除処理を、受信したパケットに適用する。暗号化解除処理は、任意の適当な暗号化解除方法とすることができる。１例では、メッセージは、暗号化鍵を用いて暗号化され、クライアントは、暗号化解除用の一致する鍵を有する。処理は、ブロック１１０２からブロック１１０３に継続され、クライアント・デバイスが、暗号化解除されたパケットにＣＲＣ検証処理を適用する。判断ブロック１１０４に進み、クライアント・デバイスは、ＣＲＣ検証の結果を評価する。処理は、ＣＲＣが有効な時にはブロック１１０４からブロック１１１０に進む。その代わりに、ＣＲＣが無効な時には、処理は判断ブロック１１０４からブロック１１０５に進む。

ブロック１１０５で、エラー訂正方法をパケットに適用する。エラー訂正は、任意の適当なエラー訂正方法とすることができる。エラー訂正方法の１例が、リードソロモンである。処理は、ブロック１１０５から１１０６に進み、クライアント・デバイスが、エラー訂正されたパケットを暗号化解除する。ブロック１１０７に進んで、クライアント・デバイスが、エラー訂正され暗号化解除されたパケットにＣＲＣ検証処理を適用する。判断ブロック１１０８に進んで、クライアント・デバイスが、ＣＲＣ検証の結果を評価する。ＣＲＣが有効な時には、処理が、判断ブロック１１０８からブロック１１１０に進む。その代わりに、ＣＲＣが無効な時には、処理は判断ブロック１１０８からブロック１１０９に進む。

ブロック１１０９で、クライアント・デバイスが、受信されたパケットが、コンフリクトとして識別されていることを識別する。無効なパケットは、パケットを壊した環境内のノイズ、無効なパケット伝送、または前の伝送からの目次と一致しないパケット・スロット割り当て、の結果である可能性がある。そのスロットは、異なる暗号化解除鍵を有する異なるクライアント・デバイスに割り当てられていた可能性がある。１例では、そのスロット割り当てが、前に説明した晩期スロット・オーバーライドであった。

上記の明細書、例、およびデータは、本発明の構成の製造および使用についての完全な説明を提供するものである。本発明の多数の実施形態を、本発明の趣旨および範囲から逸脱せずに実施することができるので、本発明は、特許請求の範囲に存する。

動作環境を示す図である。 電子デバイスの機能コンポーネントを示す図である。 電子システムを含む腕時計デバイスを示す図である。 ブロードキャスト／スケジューリング・システムを示す図である。 例示的なコンピューティング・デバイスを示すブロック図である。 フレーム伝送シーケンスを示す図である。 フレーム伝送シーケンスを示す図である。 ＴＯＣを含むフレーム・ヘッダを示す図である。 ＴＯＣ範囲記述子（range descriptor）を示す図である。 ＴＯＣスロット記述子を示す図である。 プライベート・メッセージを示す図である。 サーバ側フレーム・スケジューリングの処理フローを示す図である。 クライアント側トランスポート層処理の処理フローを示す図である。 本発明に従って配置された、コンフリクト検出手順の例を示す処理流れ図である。

符号の説明

４００ コンピューティング・デバイス
４０２ 処理ユニット
４０４ システム・メモリ
４０５ オペレーティング・システム
４０６ プログラム・モジュール
４０７ プログラム・データ
４０８ 破線
４０９ 取外し可能ストレージ
４１０ 取外し不能ストレージ
４１６ 通信接続
４１８ 他のコンピューティング・デバイス

Claims (70)

1. サーバ・デバイスからクライアント・デバイスへの複数の伝送フレームの通信に使用するデータ構造が格納されたコンピュータ可読媒体であって、前記データ構造は、
   現行の伝送フレームの所定のスロットに配置されたフレーム・ヘッダ・パケットであって、目次位置定義（table of contents locations definition）フィールドを含むフレーム・ヘッダ・パケットと、
   前記フレーム・ヘッダの前記目次位置定義フィールド内のエントリによって決定される、前記現行の伝送フレームのフレキシブルなスロット位置に配置された目次パケットであって、後続伝送フレームに配置される共用データ・ストリームを識別する目次パケットと、
   前記現行の伝送フレームの別のフレキシブルなスロット位置に配置され、前の伝送フレームからの別の目次パケット内のエントリに関連付けられるパケットと
   を備え、
   前記各目次パケットは、後続伝送フレーム内のパケットをインデクシングする順方向のインデックスであることを特徴とするコンピュータ可読媒体。
2. 前記各伝送フレームは、１２８０個のセグメントから成る１６個のセグメント・グループに分割される２０４８０個のセグメントを含み、前記セグメントのそれぞれは、６８個のシンボルを含み、前記フレームのそれぞれは、前記伝送フレーム内のスロットによって識別される１２８０個の論理パケットにマッピングされていることを特徴とする請求項１に記載のコンピュータ可読媒体。
3. 前記フレーム・ヘッダ・パケットは、前記伝送フレームの最初のスロットに配置されることを特徴とする請求項１に記載のコンピュータ可読媒体。
4. 前記フレーム・ヘッダのそれぞれは、さらに、フレーム番号、タイム・スタンプ、タイム・ゾーン・オフセット、および地域定義の各フィールドを備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
5. リプレイ・アタックがクライアント・デバイスによって検出されるように、前記フレーム・ヘッダ・パケットは、さらに、前のおよび後続の伝送フレームの対応するフレーム番号フィールドに関連付けられた値と異なる関連付けられた値を有するフレーム番号フィールドを備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
6. 前記フレーム・ヘッダ・パケットは、さらに、前記フレーム伝送の初めの時刻を指定するタイム・スタンプのフィールドを備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
7. 前記フレーム・ヘッダ・パケットは、さらに、前記各フレーム伝送が行われる地理的地域のタイム・ゾーンを示すタイム・ゾーン・オフセットのフィールドを備えることを特徴とする請求項１に記載のコンピュータ可読媒体。
8. 前記フレーム・ヘッダ・パケットは、さらに、地域ＩＤ、コード・ネーム、および周波数のリストを含む地域定義フィールドを備え、前記地域ＩＤは、現行のブロードキャスト地域を識別し、前記コード・ネームは、前記現行のブロードキャスト地域の説明を提供し、周波数の前記リストは、前記現行のブロードキャスト地域内で使用可能なラジオ周波数に対応することを特徴とする請求項１に記載のコンピュータ可読媒体。
9. 前記フレーム・ヘッダ・パケットは、さらに、タイム・スタンプおよびフレーム番号のフィールドを含み、前記タイム・スタンプおよび前記フレーム番号は、クライアント・デバイスが前記フレーム・ヘッダを認証して、バリエーションリプレイ・アタックに対応する伝送フレームを無視するように、前記伝送フレーム内のパケットを暗号化するのに使用されることを特徴とする請求項１に記載のコンピュータ可読媒体。
10. 前記暗号化されたパケットは、暗号化鍵および初期化ベクトルを用いて暗号化され、前記初期化ベクトルは、前記フレーム番号フィールドおよび前記タイム・スタンプ・フィールドのうちの少なくとも１つからの値によって決定されることを特徴とする請求項９に記載のコンピュータ可読媒体。
11. 前記各目次位置定義フィールドは、対応する目次の、スロット位置、フォーマット・タイプ、エラー訂正モード、およびエラー訂正設定を識別することを特徴とする請求項１に記載のコンピュータ可読媒体。
12. 前記各目次位置定義フィールドは、さらに、目次パケットへのインデックスを備え、前記各インデックスは、スロット位置およびフォーマット・タイプを含み、前記スロット位置は、前記伝送フレーム内の前記目次パケットの位置を識別し、前記フォーマット・タイプは、クライアント・デバイスの特定のクラスを識別することを特徴とする請求項１に記載のコンピュータ可読媒体。
13. 前記各目次パケットは、さらに、複数の範囲記述子から成る組を備え、前記範囲記述子のうちの各特定の範囲記述子は、特定の範囲に関連付けられた初期位置のフィールドおよびスロットの番号のフィールドを含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
14. 前記初期位置は、前記伝送フレーム内の前記特定の範囲の初めに関連付けられたパケット番号に対応することを特徴とする請求項１３に記載のコンピュータ可読媒体。
15. 前記特定の範囲に関連付けられた前記各スロットは、サービスＩＤ、パケット・カウント、ストリーム・ロケータ、エラー訂正設定、およびフレーム予約の各フィールドを含む対応するスロット記述子を有することを特徴とする請求項１３に記載のコンピュータ可読媒体。
16. 前記特定の範囲に関連付けられた前記各スロットは、サービスＩＤフィールドを含む対応するスロット記述子を有し、前記各サービスＩＤフィールドは、前記スロット記述子に関連付けられた論理パケットが特定のブロードキャスト・サービスにも関連付けられるように、前記スロットに関連付けられた前記特定のブロードキャスト・サービスを識別することを特徴とする請求項１３に記載のコンピュータ可読媒体。
17. 前記特定のブロードキャスト・サービスは、データ・タイプに関連付けられ、前記各論理パケットは、クライアント・デバイス上の、前記特定のブロードキャスト・サービスにも関連付けられたアプリケーション・プログラムによる使用のためのデータ・タイプに従ってフォーマットされていることを特徴とする請求項１６に記載のコンピュータ可読媒体。
18. 前記データ・タイプは、ｃｏｍｐａｃｔデータ・タイプ、ｓｐａｒｓｅデータ・タイプ、およびｌｏｎｇデータ・タイプのうちの１つに対応することを特徴とする請求項１７に記載のコンピュータ可読媒体。
19. 前記特定の範囲に関連付けられた前記各特定のスロットは、対応するスロット記述子を有し、前記スロット記述子は、前記フレーム伝送内の前記特定のスロットに関連付けられたパケットの数を識別するパケット・カウント・フィールドを含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
20. 前記特定の範囲に関連付けられた前記各特定のスロットは、対応するスロット記述子を有し、前記スロット記述子は、特定のブロードキャスト・サービスに関連付けられたアプリケーション・レベル・データ・ハンドラによって使用される不透明値に一致するストリーム・ロケータ・フィールドを含むことを特徴とする請求項１３に記載のコンピュータ可読媒体。
21. 前記範囲記述子に関連付けられた前記各スロットは、対応するスロット記述子を有し、前記スロット記述子は、サービスＩＤフィールドおよびフレーム予約フィールドを含み、前記サービスＩＤフィールドは、前記フレーム伝送内の前記特定のスロットに関連付けられた前記ブロードキャスト・サービスを識別し、前記フレーム予約フィールドは、前記ブロードキャスト・サービスに割り当てられる前記スロットのフレーム伝送の回数を示すことを特徴とする請求項１３に記載のコンピュータ可読媒体。
22. 前記伝送フレームは、５つのパーティションに分割され、前記５つの各パーティション内に擬似ランダムに割り当てられるスロットは、それぞれの伝送ごとに１つのクライアントに割り当てられ、前記伝送フレームは、前記擬似ランダムに割り当てられる複数のスロットのうちの少なくとも１つに、前記クライアントに関するプライベート・メッセージの少なくとも一部を含むことを特徴とする請求項１に記載のコンピュータ可読媒体。
23. 前記擬似ランダムに割り当てられるスロットは、前記クライアントに関連付けられた加入者ＩＤ、現行のフレーム番号、およびハッシュ関数のうちの少なくとも１つから決定されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
24. 前記プライベート・メッセージは、それぞれがプライベート・メッセージ・ヘッダを含む複数の論理パケットにまたがり、前記プライベート・メッセージ・ヘッダは、メッセージＩＤ、メッセージ内のフラグメント、およびフラグメント・インデックスの各フィールドを含み、前記プライベート・メッセージは、前記メッセージＩＤフィールドによって識別され、前記論理パケットの数は、メッセージ内の前記フラグメントによって識別され、前記論理パケットのそれぞれは、前記フラグメント・インデックスによって識別されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
25. サーバ・デバイスからクライアントへ複数の伝送フレームの通信に使用するためのデータ構造が格納されたコンピュータ可読媒体であって、前記データ構造は、前記伝送フレーム内の対応するスロットを用いて識別される論理パケットを含み、前記論理パケットはパーティションに分割され、前記クライアントはスロットに擬似ランダムに割り当てられ、前記各スロットは、前記パーティションに擬似ランダムに割り当てられ、前記擬似ランダムに割り当てられるスロットの１つに関連付けられた論理パケットは、前記クライアントに関するプライベート・メッセージの少なくとも一部を備えることを特徴とするコンピュータ可読媒体。
26. 前記各伝送フレームは、それぞれが１２８０個のセグメントから成る１６個のセグメント・グループに分割される２０４８０個のセグメントを含み、前記各セグメントは、６８個のシンボルを含み、前記各フレームは、１２８０個の論理パケットにマッピングすることを特徴とする請求項２５に記載のコンピュータ可読媒体。
27. 前記擬似ランダムに割り当てられるスロットは、前記クライアントに関連付けられた加入者ＩＤ、伝送フレームに関連付けられた現行のフレーム番号、およびハッシュ関数のうちの少なくとも１つから決定されることを特徴とする請求項２５に記載のコンピュータ可読媒体。
28. 前記プライベート・メッセージは、それぞれがプライベート・メッセージ・ヘッダを含む複数の論理パケットにまたがり、前記プライベート・メッセージ・ヘッダは、メッセージＩＤ、メッセージ内のフラグメント、およびフラグメント・インデックスの各フィールドを含み、前記プライベート・メッセージは、前記メッセージＩＤフィールドによって識別され、前記論理パケットの数は、前記メッセージ内のフラグメントによって識別され、前記各論理パケットは、前記フラグメント・インデックスによって識別されることを特徴とする請求項２５に記載のコンピュータ可読媒体。
29. 前記擬似ランダム・スロット割り当ては、加入者ＩＤと前記現行のフレーム番号とを連結して配列を形成し、前記配列からハッシュ値を生成し、前記ハッシュ値を前記各パーティションに関連付けられたサイズに制限することによって決定されることを特徴とする請求項２５に記載のコンピュータ可読媒体。
30. 前記現行のフレーム番号は、前記各クライアントに割り当てられる前記スロットの位置が後続の前記伝送フレームそれぞれについて変化するように、前記後続の伝送フレームのそれぞれで異なっていることを特徴とする請求項２９に記載のコンピュータ可読媒体。
31. 前記論理パケットは、プライベート・メッセージに関連付けられ、暗号化文字列および一意の制御鍵を用いて暗号化されることを特徴とする請求項２５に記載のコンピュータ可読媒体。
32. 一意の識別子が、前記クライアントに関連付けられ、前記一意の識別子は前記一意の制御鍵によって決定されることを特徴とする請求項３１に記載のコンピュータ可読媒体。
33. サーバからクライアント・デバイスへのフレーム伝送をスケジューリングする方法であって、
    後続伝送フレームについて候補のリストから複数のパケットを選択すること、
    次の伝送フレームについての目次に前記選択されたパケットを記述すること、
    前記次の伝送フレームについての前記目次を現行の伝送フレーム内のスロットに割り当てること、
    前の目次からの前のスロット割り当ておよび次の伝送フレームの前記目次への前記割り当てられたスロットに従って、前記現行の伝送フレーム内にパケットを組み立てること、および
    前記現行の伝送フレーム用の、前記現行の伝送フレームの前記目次の位置を参照するフレーム・ヘッダを組み立てること
    を備えることを特徴とする方法。
34. サーバからクライアント・デバイスへのフレーム伝送をスケジューリングする方法であって、
    複数のパケットを含む、伝送スロットの要求を受信すること、
    前記要求された伝送スロットに基づいて、次の伝送フレームのスロットを割り振ること、
    前記割り振られたスロットに基づいて、前記次の伝送フレームの目次を作成すること、
    前記次の伝送フレームの前記目次を、現行の伝送フレーム内のスロットに割り当てること、
    前の目次からの前のスロット割り当ておよび前記次の伝送フレームの前記目次の前記割り当てられたスロットに従って、前記現行の伝送フレーム内のパケットを組み立てること、および
    前記現行の伝送フレームの、前記現行の伝送フレームの前記目次の位置を参照するフレーム・ヘッダを組み立てること
    を備えることを特徴とする方法。
35. サーバからクライアント・デバイスへのフレーム伝送をスケジューリングする方法であって、
    登録されたブロードキャスト・サービスに関連付けられた共用データ・サービス・ハンドラに、ニーズに関するリクエストを送ること、
    前記リクエストに応答して前記共用データ・サービス・ハンドラから、要求される優先順位レベルおよびパケットの伝送スロットの要求される割振りを含む、前記共用データ・サービス・ハンドラによって要求されるニーズ、を受信すること、
    前記共用データ・サービス・ハンドラから受信された前記ニーズに優先順位を付けること、
    前記優先順位を付けられたニーズに基づいて次の伝送フレームのスロットを割り振ること、
    前記割り振られたスロットに基づいて前記次の伝送フレームの目次を作成すること、
    現行の伝送フレームのパケットを前記共用データ・サービス・ハンドラに要求すること、
    前の伝送フレームからの前の目次に関連付けられた、前記現行の伝送フレームの、パケットを前記共用データ・サービス・ハンドラから受信すること、
    前記現行の伝送フレーム内の未使用スロットに前記次の伝送の前記目次を割り当てること、
    前の目次からの前のスロット割り当ておよび前記次の伝送フレームの前記目次についての前記割り当てられたスロットに従って、前記現行の伝送フレーム内に複数のパケットを組み立てること、および
    前記現行の伝送フレーム用の、前記現行の伝送フレームの前記目次の位置を参照するフレーム・ヘッダを組み立てること
    を備えることを特徴とする方法。
36. プライベート・メッセージ・パケットのために、割り振られたスロット割り当てをオーバーライドすることをさらに備えることを特徴とする請求項３５に記載の方法。
37. 各プライベート・メッセージのスロット用に、擬似ランダムに割り当てられるパーティション内の擬似ランダムのスロット割り当てを決定すること、
    前記プライベート・メッセージのスロット割り当てに優先順位を付けること、および
    前記優先順位付けの際に未使用のスロットを前記プライベート・メッセージ・スロットに割り当てること
    をさらに備えることを特徴とする請求項３５に記載の方法。
38. 前記擬似ランダムのスロット割り当ておよび前記擬似ランダムのパーティション割り当ては、前記プライベート・メッセージの一意ＩＤ、フレーム番号、およびパケット番号を使用するハッシュによって決定されることを特徴とする請求項３５に記載の方法。
39. 前記擬似ランダムに割り当てられるパーティションを用いる擬似ランダム・スロット割り当てを決定することは、
    一意ＩＤおよびスロット・インデックスを使用してパーティション割り当てのためのハッシュ値を計算すること、
    前記フレーム伝送のパーティションの総数によって前記パーティション割り当てのための前記ハッシュ値を切り詰めて、前記一意ＩＤの初期位置を定義すること、
    各クライアントがすべての前記パーティションを介してサイクルするように、前記切り詰められたハッシュ値にフレーム番号を加算すること、
    前記パーティションの開始位置および終了位置を決定すること、
    前記一意ＩＤ、前記フレーム番号、および前記スロット・インデックスを使用してスロット割り当てのためのハッシュ値を計算すること、
    縮小された値が選択されたパーティションのサイズにおさまるように、前記スロット割り当ての前記ハッシュ値を縮小すること、および
    前記パーティションの前記開始位置を前記縮小されたハッシュ値に加算して、要求されたスロットのパケット番号を決定すること
    を備えることを特徴とする請求項３７に記載の方法。
40. 前記プライベート・メッセージに関連付けられたパケットを暗号化処理することをさらに備え、前記暗号化処理することは、暗号化処理の初期化ベクトルを決定するためにフレーム番号およびパケット番号のうちの少なくとも１つを使用し、前記暗号化処理は、暗号化に、前記初期化ベクトルおよび加入鍵を使用することを特徴とする請求項３７に記載の方法。
41. フレーム番号フィールドに、当該フレーム番号フィールドに関連付けられて、連続するフレームについて異なる、値を割り当てること、
    時刻フィールドに、当該時刻フィールドに関連付けられて、連続するフレームについて異なる値を割り当てること、および
    前記フレーム番号フィールド、目次ロケータ・フィールド、および前記時刻フィールドを含む、フレーム伝送内において同一の論理パケット番号で必ず発生するパケットに対応する、フレーム・ヘッダを配置すること、
    をさらに備えることを特徴とする請求項３５に記載の方法。
42. 前記割り振られたスロットに基づいて前記次の伝送の目次を作成することは、
    ブロードキャスト・サービスのスロット番号を決定すること、
    前記ブロードキャスト・サービスにスロット番号を割り当てること、および
    前記ブロードキャスト・サービスを示すために前記目次のエントリのサービス識別子フィールドをセットすること
    を備えることを特徴とする請求項３５に記載の方法。
43. 各共用データ・サービス・ハンドラによって要求される各ニーズは、スロット割り当てが持続する伝送シーケンスの数を指定する要求されたフレーム予約を含むことを特徴とする請求項３５に記載の方法。
44. 割り当てられたスロットごとにフレーム予約フィールドをセットすることをさらに備え、前記各フレーム予約は、スロット割り当てが持続する伝送シーケンスの数を指定することをさらに含むことを特徴とする請求項３５に記載の方法。
45. 前記割り当てられたスロットごとにフレーム予約フィールドをセットすることをさらに備え、前記フレーム予約は、スロット割り当てが持続する伝送シーケンスの数を指定することを特徴とする請求項３５に記載の方法。
46. 各前のフレーム伝送からの前記割り当てられたスロットごとに前記フレーム予約フィールドを減分すること、および
    ０の値を有する前記フレーム予約フィールドを有する各スロット割り当てを再生使用すること
    をさらに備えることを特徴とする請求項４５に記載の方法。
47. 前記割り当てられたスロットに関連付けられたロケータ・フィールドを更新することをさらに備えることを特徴とする請求項４５に記載の方法。
48. 前記各割り当てられたスロットに関連付けられたロケータ・フィールドを更新するために前記各共用データ・サービス・ハンドラへのリクエストをサブミットすること、および
    前記リクエストに応答して前記共用データ・サービス・ハンドラから更新されたロケータ・フィールドを受け取ること
    をさらに備えることを特徴とする請求項４５に記載の方法。
49. プライベート・データ・サービス・ハンドラからオーバーライド・リクエストを送ること、
    前記プライベート・データ・サービス・ハンドラからオーバーライド・リクエストを受信すること、および
    前記オーバーライド・リクエストに応答して前記次のフレーム伝送内のスロットをプライベート・メッセージに割り当てること
    をさらに備えることを特徴とする請求項４５に記載の方法。
50. クライアント・デバイスでのデータの取り出しをスケジューリングする方法であって、
    現行の伝送フレームから目次を抽出すること、
    登録されたアプリケーションを用いて前記目次のエントリを識別すること、
    後続の伝送フレーム内のスロットに関して、識別されたパケットを検索すること、
    前記取り出したパケットからメッセージを組み立てること、および
    前記メッセージが組み立てられた時に、前記クライアント・デバイスのアプリケーションに完成したメッセージを転送すること
    を備えることを特徴とする方法。
51. クライアント・デバイスでのデータの取り出しをスケジューリングする方法であって、
    現行の伝送フレームから目次を抽出すること、
    登録されたアプリケーションを用いて前記目次のエントリを識別すること、
    前記目次の前記エントリに関連付けられたリクエストを前記登録されたアプリケーションに送ること、
    要求される優先順位レベルを含むデータ・リクエストを前記アプリケーションから受け取ること、
    前記優先順位レベルに基づいて前記データ・リクエストをソートすること、
    後続伝送フレーム内のスロットを用いて識別される最高優先順位のパケットを、ネットワーク層に要求すること、
    前記後続伝送フレームに関連付けられたパケットを前記ネットワーク層から受け取ること、
    前記受け取られたパケットを前記登録されたアプリケーションの前記ハンドラに転送すること、
    前記登録されたアプリケーションの前記ハンドラを用いて前記受け取られたパケットからメッセージを組み立てること、および
    前記メッセージが組み立てられた時に前記ハンドラから前記アプリケーションに完成したメッセージを転送すること
    を備えることを特徴とするデータの検索をスケジューリングする方法。
52. アプリケーションを前記クライアント・デバイスのトランスポート層に登録すること、および
    前記登録されたアプリケーションのために前記トランスポート層にハンドラを接続すること
    をさらに備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
53. 前記アプリケーションからの終了リクエストに応答して、前記トランスポート層から前記ハンドラを切断することをさらに備えることを特徴とする請求項５２に記載のデータの検索をスケジューリングする方法。
54. 前記目次を抽出することは、
    現行の伝送フレームのフレーム・ヘッダを取り出すこと、
    前記フレーム・ヘッダから目次の位置定義を識別すること、および
    後続伝送フレームへの順方向のインデックスである前記目次を、前記現行の伝送フレーム内の前記識別された位置から取り出すこと
    を備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
55. 前記現行のフレーム伝送のフレーム・ヘッダからタイム・スタンプを検索すること、および
    前記タイム・スタンプに基づいて前記クライアント・デバイス内の内部クロックを同期化すること
    をさらに備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
56. リプレイ・アタックが前記クライアント・デバイスによって無視されるように、フレーム番号、およびタイム・スタンプに基づいて前記現行のフレーム伝送を認証することをさらに備え、前記フレーム番号は、前の伝送フレームから推定される番号、およびフレーム・ヘッダから抽出される番号のうちの少なくとも１つであることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
57. フレーム番号を計算することおよび前記現行のフレーム伝送のフレーム・ヘッダから前記フレーム番号を取り出すことのうちの少なくとも１つと、および
    リプレイ・アタックのバリエーションが前記クライアント・デバイスによって無視されるように、前記フレーム番号によってシードを与えられるフィードバック・モード・パケット暗号化を用いてパケットを暗号化解除すること
    をさらに備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
58. フレーム番号、タイム・スタンプ、およびパケット番号を使用して、暗号化鍵を使用する暗号化解除処理の初期値を生成することをさらに備え、前記暗号化鍵は、ブロードキャスト・サービスに関連付けられた取り出されたデータを検証するために前記クライアント・デバイスによって使用されることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
59. 取り出されたデータに関連付けられた論理パケットを認証することであって、
    前記論理パケットを暗号化解除すること、
    前記暗号化解除された論理パケットのＣＲＣを検査すること、
    前記暗号化解除された論理パケットについて無効なＣＲＣが識別された際に、エラー訂正を適用すること、
    前記エラー訂正された論理パケットを暗号化解除すること、
    前記暗号化解除されたエラー訂正されたパケットのＣＲＣを検査すること、
    前記暗号化解除された論理パケットおよび前記暗号化解除されたエラー訂正されたパケットが無効なＣＲＣを有する時に認証を失敗させること、および
    前記論理パケットおよび前記エラー訂正された論理パケットのうちの少なくとも１つが有効なＣＲＣを有する時に成功裡に認証すること
    を備える認証することをさらに備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
60. 登録されたアプリケーションを用いて前記目次のエントリを識別することは、前記目次のサービスＩＤを前記目次から抽出することをさらに備え、前記サービスＩＤは前記登録されたアプリケーションを識別することを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
61. サービス品質が、前記クライアント・デバイスのアプリケーションごとに維持されるように、前記要求される優先順位レベルに関連付けられた優先順位レベルを更新することをさらに備えることを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
62. 前記目次の取り出しに失敗し、前記受け取られたパケットに関連付けられた前記スロット割り当てがスティッキーであることを前の目次からのフレーム予約フィールドが示す時に、別の後続伝送フレームに関連付けられたパケットを前記ネットワーク層から受け取ることをさらに備えることを特徴とする請求項５１に記載のデータの取り出しをスケジューリングする方法。
63. 前記メッセージは、前記クライアント・デバイスの前記アプリケーションのハンドラに関連付けられたデータ・タイプに従ってフォーマットされ、前記データ・タイプは、ｃｏｍｐａｃｔデータ・タイプ、ｓｐａｒｓｅデータ・タイプ、およびｌｏｎｇデータ・タイプのうちの１つに対応することを特徴とする請求項５１に記載のデータの検索をスケジューリングする方法。
64. 前記ｃｏｍｐａｃｔデータ・タイプに対する前記ハンドラは、目次スロット記述子からのストリーム・ロケータを使用して前記スロット内の最初のｃｏｍｐａｃｔメッセージの開始位置を決定し、後続１パケット・メッセージは、前記開始位置に続き、１度に１パケットだけオフセットされることを特徴とする請求項６３に記載のデータの取り出しをスケジューリングする方法。
65. 前記ｓｐａｒｓｅデータ・タイプに対する前記ハンドラは、目次スロット記述子からのストリーム・ロケータを使用してｓｐａｒｓｅデータ・ストリームのフラグメントのスロット位置を決定し、後続フラグメントは、前記開始スロット位置に続き、最初のフラグメントからオフセットすることを特徴とする請求項６３に記載のデータの検索をスケジューリングする方法。
66. 前記ｌｏｎｇデータ・タイプに対する前記ハンドラは、目次スロット記述子からのストリーム・ロケータを使用して、ｌｏｎｇデータ・ストリームの各フラグメントのシーケンス番号を決定することを特徴とする請求項６３に記載のデータの検索をスケジューリングする方法。
67. クライアント・デバイスでのプライベート・データの取り出しをスケジューリングする方法であって、
    現行の伝送フレームからフレーム・ヘッダを取り出すこと、
    後続伝送フレームのフレーム番号と異なっている前記現行の伝送フレームのフレーム番号を、前記フレーム・ヘッダから抽出すること、
    前記クライアント・デバイスの加入者ＩＤを識別すること、
    前記フレーム番号および前記加入者ＩＤを用いて前記クライアント・デバイスのプライベート・メッセージのスロット割り当てを決定すること、
    前記伝送フレーム内の前記プライベート・メッセージのスロット割り当てから論理パケットを受信すること、
    前記論理パケットを認証すること、および
    前記認証された論理パケットを前記クライアント・デバイスのアプリケーション・ハンドラに転送すること
    を備えることを特徴とするプライベート・データの取り出しをスケジューリングする方法。
68. プライベート・メッセージのスロット割り当てを決定することは、前記加入者ＩＤおよび前記現行のフレーム番号からプライベート・メッセージのスロット割り当てを決定することをさらに備えることを特徴とする請求項６７に記載のプライベート・データの取り出しをスケジューリングする方法。
69. プライベート・メッセージのスロット割り当てを決定することは、
    前記加入者ＩＤおよび前記現行のフレーム番号を連結して複数バイトの配列を形成すること、
    複数バイトの前記配列からハッシュ値を作成すること、および
    複数バイトの前記配列からスロット割り当てを決定すること、
    をさらに含み、前記スロット割り当ては、前記伝送フレームの各パーティション内のスロットに対応することを特徴とする請求項６７に記載のプライベート・データの取り出しをスケジューリングする方法。
70. 前記論理パケットを認証することは、
    前記論理パケットを暗号化解除すること、
    前記暗号化解除された論理パケットのＣＲＣを検査すること、
    前記暗号化解除された論理パケットについての無効なＣＲＣが識別された際に、エラー訂正を適用すること、
    前記エラー訂正された論理パケットを暗号化解除すること、
    前記暗号化解除されたエラー訂正されたパケットの前記ＣＲＣを検査すること、
    前記暗号化解除された論理パケットおよび前記暗号化解除されたエラー訂正された論理パットが無効なＣＲＣを有する時に、認証を失敗させること、および
    前記論理パケットおよび前記エラー訂正された論理パットのうちの少なくとも１つが有効なＣＲＣを有する時に、成功裡に認証すること
    を備えることを特徴とする請求項６７に記載のプライベート・データの取り出しをスケジューリングする方法。

Images