JP7170751B2

JP7170751B2 - デジタル・データを複数のレシーバにブロードキャストするためのシステム及び方法

Info

Publication number: JP7170751B2
Application number: JP2020567460A
Authority: JP
Inventors: ヨークスミス、コリン
Original assignee: シーイーダブリューアイネットワークス、インコーポレイテッド
Priority date: 2018-02-26
Filing date: 2019-02-26
Publication date: 2022-11-14
Anticipated expiration: 2039-02-26
Also published as: CA3091833C; CN111788779B; US20200404457A1; US10848925B2; US20190268728A1; EP3759840B1; JP2021519047A; EP3759840A1; US11206512B2; BR112020017337B1; BR112020017337A2; AU2019225246A1; AU2019225246B2; EP3759840A4; WO2019165431A1; CN111788779A; CA3091833A1

Description

本出願は、２０１８年２月２６日に出願の「Methodology Developed for the Transfer of Digital Information by Broadcasting to an Unlimited Number of Receivers」という名称の米国仮特許出願第６２／６３５，１０４号、及び、２０１９年１月１４日に出願の「System and Method for Broadcasting Digital Data to Receivers」という名称の米国仮特許出願第６２／７９２，００３号の優先権を主張し、その全体を参照により組み込む。

本発明は、特に、双方向通信が可能でない、又は実用的でない環境における、複数のレシーバへのデジタル情報のワイヤレス・ブロードキャストに関する。

スポーツ・イベント、集会、講演、コンサート、等など、多くの人々が集まる環境では、携帯電話及びワイヤレス・デバイスを使用したデジタル・データへのアクセスは信頼性が低い。

このような事例では、多くのモバイル・デバイスが、セルラー・ネットワークの近くのアンテナに注意を向けさせるために競争する。モバイル・デバイスのユーザには、利用可能な信号があることを示すデバイスの画面上のバーが見えている可能性があるが、データは、一貫してセルラー・ネットワークから受信されておらず、返信されていない。このようなネットワークは、大量のネットワーク帯域幅を消費する音声、写真、メディア、及びビデオ共有など、データが重いアプリケーション及びマルチメディアを受信者１２０が使用する傾向があるときに、このようなイベントが頻繁に起こるので、「高トラフィック」によってさらに負担をかけられる可能性がある。

類似のネットワーク過負荷は、緊急事態において、又は災害中に発生する。ボストン・マラソン爆破事件の後、例えば、数千もの人々がボストン地域の最愛の人と連絡を取ろうとしたので、携帯電話キャリアにはトラフィックが殺到した。自然災害、テロリストの攻撃、及び世界中の他のこのような事件の余波で、テレコミュニケーション・ネットワークは、音声電話容量又はデータ・トラフィック（例えば、テキスト／ＳＭＳ、及びマルチメディア・メッセージ）の急激な増加に、全く対処することができない。あらゆる主要なモバイル・キャリアの受信者１２０は、この出来事の中で、ボストン大都市圏における機能停止を報告した。その結果、携帯電話の時間で爆弾を遠隔爆発させるのを阻止するために、モバイル・サービスがボストンで停止されたことをＡｓｓｏｃｉａｔｅｄＰｒｅｓｓが間違ってレポートしたことなど、メディアによって事実として受け取られた確証のないうわさが拡散した。

自然災害により、セルラー・ネットワークの信頼性が低くなることがある。ハリケーン・サンディの直後、例えば、ＦＣＣは、嵐によってモバイル・サービスが大きな打撃を受けたと警告した（https://www.fastcompany.com/3002578/post-sandy-fcc-warns-worsening-cell-phone-networks）。サンディは、ネットワーク容量が大きくなるのとは全く異なるモバイル・ネットワーク・インフラストラクチャの物理的破壊を伴ったが、基本的要素は同じである。

災害に襲われるとき、ネットワークの非集中性は、特に、出来事に関連した地域内の中央の（例えば、ニュースの、政府の）情報源からのリアル・タイム情報を求める受信者１２０によってネットワーク使用量が増加したことにより、地理的地域全体が危険にさらされる可能性があることを意味する。キャリア・サイトで帯域幅に負担がかかると、受信者１２０は、電話をすること、及びデジタル・データ、特にマルチメディア・データを通信することを阻止される。

同様に、悪い接続環境では、モバイル・デバイスと、モバイル・ネットワーク又は他のネットワークとの間の通信は、特に、建設現場、医療施設、ショッピング・モール、コンベンション・センター、等などの「高密度」のロケーションと組み合わされると、信頼性が低下する可能性がある。

これらの試練にもかかわらず、受信者１２０は、いつでも、また、どこでも、自分のモバイル・デバイスを介して接続されたままであることを期待する。セルラー及びネットワーク会社は、このような状況下での信頼性を向上させるための様々な戦略を展開してきた。例えば、現在のセルラー技術は、セル・タワー又は分散アンテナ・システム（ＤＡＳ）のセクタあたり、最大およそ２，０００の同時接続を可能にすることになる。スタジアムでのフットボール・ゲームのような大きなイベントでは、５０，０００人のファンに同時に達するために、２５基のセル・フォン・タワーが必要になる。ネットワークの中には、収容能力が大きい会場又はその近くに、及び近くのセル・タワーに、アンテナを追加又はアップグレードしてきたものもあり、中には、スポーツ・スタジアムのような大観衆の会場の中に、容量を改善するために、「小規模セル」を設置してきたものもある。小規模セルは、通常のセル・タワーより範囲が狭いが、高密度エリアにおける容量を増大させるために、これらのタワーを補うことができる。ネットワークは、ネットワーク接続性を増大させるために、「セル・オン・ホイール」すなわちｃｏｗと呼ばれることもある一時的なセル・サイトも収容能力が大きい会場に配置する。

より新しい会場は、セル・フォン・ネットワークに対する負荷を軽減するＷｉ－Ｆｉを有する可能性も高い。しかし歴史的に、Ｗｉ－Ｆｉ機器は、天井又は壁の高いところに設置されてきた。その結果、鋼鉄及び他の建設資材からの障害物によって信号が遮られることがある。また、モバイル・デバイスの受信者１２０は、ネットワークとの通信を備えるルータから比較的遠く離れている可能性がある。Ｗｉ－Ｆｉ容量も小さくなる傾向があり、現在のＷｉ－Ｆｉ技術は、アクセス・ポイント（アンテナ）あたり２００の同時接続も可能にしていない。アクセス・ポイントも典型的には、３０．４８ｍ（１００フィート）離してあるだけである。

しかし、これらのネットワークの改善は、例えば、写真、ビデオ、及びマルチメディア・コンテンツといった、特にデジタル・データの通信について、混雑したエリアのネットワーク・サービスを一貫して信頼できるものにしてこなかった。配置済みのインフラストラクチャを改善しても、複数のトランスミッタの近接、ファンの行動、及び他の複雑性と関連付けられた技術的課題及び限界が、参加者の全てに同時に達することを不可能にする。

ＴＣＰＩＰ、Ｂｌｕｅｔｏｏｔｈ、及び他のプロトコルなど、現在のデジタル・ファイル転送プロトコルは、正しいファイルの受信をデジタル承認するためのバック・チャネルを提供するために、双方向通信リンクが機能することを要求する。例えばセル・タワーとモバイル・デバイスとの間の通信の双方向性は、通信に割込みがある場合、通信又は送信が途絶える可能性があることを意味する。ＵＤＰなど、双方向フィードバックを要求しない一定のファイル転送プロトコルが存在するが、これらのプロトコルは、破損していないデータが送信され、受信エンドで成功裏に受信されることを保証するために、ファイル全体の連続的で割り込まれない受信を依然として要求する。したがって、信号が完全に連続的で割り込まれないわけではない場所でさえも、破損していないデジタル・データの受信を可能にするファイル転送プロトコルが必要である。

緊急事態及び自然災害について、議会は、現在ＷＥＡとして知られるナショナル・モバイル・アラート・システムの創設のためのプロセスの確立を指示しており、参加している商業モバイル・サービス（「ＣＭＳ」：ｃｏｍｍｅｒｃｉａｌｍｏｂｉｌｅｓｅｒｖｉｃｅ）プロバイダは、その加入者に、ＷＥＡで緊急警報を送信する。それ以来、ＣＭＳプロバイダが多く参加しており、４つの主要なワイヤレス・キャリアの全てがシステムに参加しており、提供されている米国人口の９８．６％を占める。しかし、国のほとんどの地域が現在カバーされているにもかかわらず、ＷＥＡメッセージの内容、表現方法、及び地理的対象についての懸念が引き続きある。

近年、委員会は、ＷＥＡメッセージの配信の内容及び方法を改善するという問題にかなりの時間と努力を費やしてきた。例えば、ＷＥＡメッセージの能力は、２０１６年に、メッセージの文字長を３６０文字に増やすことによって高められている。これは、非常事態中に大衆が利用できる情報の質を改善し、理解しにくい略語によって生じる大衆の混乱を減らす。しかし、特に、提供される情報の内容を改善するだけでなく、（アラート中の地図を示すことなどによって）緊急事態の実際の性質及びロケーションをさらに識別するのを支援することもできるマルチメディアについて、ＷＥＡ警報メッセージングの質を改善する必要がまだある。最近、ハワイへのミサイル攻撃が想定されることについて、ＷＥＡ警報メッセージが間違っていたことにより混乱が生じたことが、マルチメディアを含めることによってメッセージングを改善するというこの努力を強めてきた。同様に、サンタ・バーバラ地域の最近のカリフォルニア州の火災の場合、住民及び第１対応要員（ｆｉｒｓｔｒｅｓｐｏｎｄｅｒ）は、避難命令の影響を受ける地域をもっと明確に描いた地図など、マルチメディアから恩恵を受けることができたはずである。

テレコミュニケーション業界におけるＣＭＳキャリアなどは、ＷＥＡ警報へマルチメディアを入れることがまだ実現可能ではないと主張している。業界の標準団体である、ＡｌｌｉａｎｃｅｆｏｒＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＩｎｄｕｓｔｒｙＳｏｌｕｔｉｏｎｓ（「ＡＴＩＳ」）は、「セル（［ｃ］ｅｌｌ）ブロードキャスト技術は、マルチメディアのためにデザインされていない」、また、「技術的に実現不可能でなくても、ＷＥＡ通知内のマルチメディア・コンテンツの表現を扱いにくくすることになる多くの問題がある」（非特許文献１のコメント）と主張している。ＡＴＩＳは、「ＷＥＡ通知内の地図、写真、ハザード記号などのマルチメディア・コンテンツの表現は、技術的に実現不可能でなくても、扱いにくい（［ｉｓ］ｐｒｏｂｌｅｍａｔｉｃ）［。］」（同書、１０時）とさらに主張している。

The Alliance for Telecommunications Industry Solutions in PS Docket 15-91, January 13, 2016

特に緊急事態において、又は非常に込み合っている悪い接続環境において、デジタル・データをブロードキャストするための改善されたシステム及び方法が望まれる。

追加として、特に緊急事態において、又は収容能力が大きい会場において、マルチメディアをブロードキャストするための改善されたシステム及び方法が望まれる。

さらに、イベント又は緊急時に関する暗号メッセージをブロードキャストするための改善されたシステム及び方法が望まれ、追加として、例えば一定の緊急時対応要員といった、選ばれたレシーバにメッセージをブロードキャストすることが望ましい。

スポンサ及びマーケティング担当者は、大きなイベント（例えば、スポーツ・イベント又はコンサート）において、モバイル・デバイス上で受信者に接続してブランド活性化キャンペーンを実行するための、より良い仕様を同様に模索している。

本発明は、その１つの形式では、デジタル情報、また、いくつかの事例では、マルチメディア情報を正確に転送するために、フィードバック・ループの必要性、又はデータ・ストリームの割り込まれない受信の必要性をなくした、デジタル・データをブロードキャストするためのシステム、プロトコル、及び方法を含む。より詳細には、本発明は、双方向通信が可能ではない、又は実用的でない環境における、複数のレシーバへのデジタル情報のワイヤレス・ブロードキャストを可能にする。

別の形式では、本明細書で開示される本発明は、双方向フィードバックを要求しない連続データ・ストリームを送信するためのシステム、方法、及び通信プロトコルを提供する。

さらに別の形式では、本発明は、斬新なコンテナ・フォーマット又はヘッダ情報を使用して、１対多（１：ＭＡＮＹ）構成で多くのデバイスとデータを通信するためのシステム及び方法を含む。これは、デジタル・デバイスのコマンド及び制御のためにその後使用されることが可能な、デジタル・ファイル及び媒体、ストリーミング・データ、並びにデジタル機能、を含むがこれらに限定されない任意のタイプのデジタル情報を、特定の会場における又は選ばれた半径の中にある複数のレシーバに「プッシュすること」を可能にする。

１つの一般的な態様は、複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムを含み、マルチメディア・データを２つ以上のデジタル・データ・セグメントにセグメント化すること、２つ以上のデジタル・データ・セグメントをヘッダ情報と共にカプセル化すること、及び、複数のリモート・モバイル・レシーバへのブロードキャストのために、リモート・データ・サーバに２つ以上のデジタル・データ・セグメントを通信することを行うように動作可能な中央サービスを含み、ここで、ヘッダ情報は、会場識別子、会場における複数のモバイル・レシーバの全てにマルチメディア・データが向けられているかどうかを識別する少なくとも１つのオクテット、データ型指標、デジタル・データ・セグメントが連続のうちの１つであるか否かを示す連続指標、２つ以上のデジタル・データ・セグメントのそれぞれにおけるオクテットの総数を示す総オクテット数指標、及び／又は、２つ以上のデジタル・データ・セグメントのそれぞれが記憶されることになる位置を示すアドレス位置情報を含む。ヘッダ情報は、チェックサムも含む。リモート・データ・サーバは、２つ以上のデジタル・データ・セグメントを受信すること、２つ以上のデジタル・データ・セグメントを記憶すること、及び、複数のリモート・モバイル・レシーバへのブロードキャストのために、２つ以上のデジタル・データ・セグメントをトランスミッタに繰り返し送信することを行うように動作可能である。システムは、リモート・データ・サーバから受信した２つ以上のデジタル・データ・セグメントを複数のモバイル・レシーバにブロードキャストするように動作可能なトランスミッタも含む。複数のモバイル・レシーバはそれぞれ、アンテナ及び一意の識別子を含み、少なくとも１つのホスト・デバイスとペアにされ、２つ以上のデジタル・データ・セグメントをトランスミッタから受信すること、及び、２つ以上のデジタル・データ・セグメントを、少なくとも１つのペアにされたホスト・デバイスに再送信することを行うように動作可能である。各ホスト・デバイスは、ディスプレイを含み、２つ以上のデジタル・データ・セグメントを受信すること、２つ以上のデジタル・データ・セグメントをマルチメディア・データに再フォーマットすること、及び、マルチメディア・データを表示することを行うように動作可能である。本態様の他の実施例は、方法のアクションを行うようにそれぞれ構成された、対応するコンピュータ・システム、装置、及び、１つ又は複数のコンピュータ・ストレージ・デバイスに記録されたコンピュータ・プログラムを含む。

実装形態は、トランスミッタを含まない代替通信ネットワークを介して、少なくとも１つのペアにされたホスト・デバイスから中央サービスへのリターン・チャネルという特徴の１つ又は複数を含むことができ、前記代替通信ネットワークが、複数のモバイル・レシーバの少なくとも１つから中央サービスへのＴＣＰ／ＩＰ通信チャネル、及び／又は、複数のモバイル・レシーバの少なくとも１つの範囲内の複数の短距離近接レシーバ（ｓｈｏｒｔｒａｎｇｅｐｒｏｘｉｍｉｔｙｒｅｃｅｉｖｅｒ）を含む。システムは、複数のモバイル・レシーバのそれぞれに関連付けられたユーザ・プロフィールをさらに含む。中央サービスは、所定の期間、リモート・データ・サーバへのブロードキャストのために、２つ以上のデジタル・データ・セグメントをさらに再配信することができる。記述された技法の実装形態は、ハードウェア、方法若しくは処理、又は、コンピュータ・アクセス可能媒体上のコンピュータ・ソフトウェアを含んでもよい。

別の一般的な態様は、複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストする方法を含み、中央サービスにおいて、マルチメディア・データを少なくとも２つのデジタル・データ・セグメントにセグメント化することと、少なくとも２つのデジタル・データ・セグメントのそれぞれをヘッダ情報と共にカプセル化することであって、ヘッダ情報が、所与の位置における複数のモバイル・レシーバの全てにマルチメディア・データが向けられているかどうかを識別する少なくとも１つのオクテット、データ・テーブル又はメモリ・マップのセル内のデータ位置を識別する少なくとも１つのオクテット、及び、前記セルのデータを有する少なくとも１つのオクテットを含む、カプセル化することと、所定の期間にわたる複数のリモート・モバイル・レシーバへのブロードキャストのために、少なくとも２つのデジタル・データ・セグメントをリモート・データ・サーバに繰り返し送信することと、リモート・データ・サーバにおいて少なくとも２つのデジタル・データ・セグメントを受信することと、リモート・データ・サーバにおいて少なくとも２つのデジタル・データ・セグメントを記憶することと、複数のリモート・モバイル・レシーバへのブロードキャストのために、少なくとも２つのデジタル・データ・セグメントを、カルーセル・バッファを介してトランスミッタに通信することと、少なくとも２つのデジタル・データ・セグメントを複数のモバイル・レシーバにブロードキャストすることと、複数のモバイル・レシーバの少なくとも１つによって、複数のモバイル・レシーバの少なくとも１つとペアにされたホスト・デバイスに少なくとも２つのデジタル・データ・セグメントを送信することと、ホスト・デバイスにおいて少なくとも２つのデジタル・データ・セグメントを受信することと、少なくとも２つのデジタル・データ・セグメントをキャッシュすることと、マルチメディア・データが表示可能になるように、少なくとも２つのデジタル・データ・セグメントを組み立てることと、マルチメディア・データをホスト・デバイスに表示することと、を行うステップを含む。本態様の他の実施例は、方法のアクションを行うようにそれぞれ構成された、対応するコンピュータ・システム、装置、及び、１つ又は複数のコンピュータ・ストレージ・デバイスに記録されたコンピュータ・プログラムを含む。

さらなる態様は、複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムを含み、マルチメディア・データをデジタル・データ・セグメントにセグメント化すること、デジタル・データ・セグメントを第１のヘッダ情報と共にカプセル化すること、及び複数のリモート・モバイル・レシーバへのブロードキャストのために、デジタル・データ・セグメントをリモート・データ・サーバに通信することを行うように動作可能な中央サービスを含む。システムは、中央サービスから複数のリモート・モバイル・レシーバにデジタル・データ・セグメント及び第１のヘッダ情報と共にブロードキャストするために、第２のヘッダ情報を有するリモート・サービス・データをリモート・データ・サーバに通信するように動作可能なリモート・サービスも含む。リモート・データ・サーバは、デジタル・データ・セグメント及び第１のヘッダ情報を中央サービスから受信すること、リモート・サービス・データ及び第２のヘッダ情報をリモート・サービスから受信すること、並びに、デジタル・データ・セグメント、第１のヘッダ情報、第２のヘッダ情報、及びリモート・サービス・データを記憶することを行うようにさらに動作可能であってもよい。リモート・データ・サーバは、複数のモバイル・レシーバへのブロードキャストのために、デジタル・データ・セグメント、第１のヘッダ情報、第２のヘッダ情報、及びリモート・サービス・データをトランスミッタに、カルーセル・バッファを介して繰り返し送信することができる。トランスミッタは、デジタル・データ・セグメント、第１のヘッダ情報、第２のヘッダ情報、及びリモート・サービス・データを複数のモバイル・レシーバにブロードキャストするように動作可能である。本態様の他の実施例は、方法のアクションを行うようにそれぞれ構成された、対応するコンピュータ・システム、装置、及び、１つ又は複数のコンピュータ・ストレージ・デバイスに記録されたコンピュータ・プログラムを含む。

しかし、さらなる一般的な態様は、複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムを含み、マルチメディア・データをデジタル・データ・セグメントにセグメント化すること、各デジタル・データ・セグメントをヘッダ情報と共にカプセル化すること、及び複数のリモート・モバイル・レシーバへのブロードキャストのために、各デジタル・データ・セグメントをヘッダ情報と共にリモート・データ・サーバに通信することを行うように動作可能なトランスミッタ・プログラムを動かす中央サービスを含む。ヘッダ情報は、会場識別子、デジタル・データ・セグメント・タイプ指標、モバイル・レシーバ識別子、各デジタル・データ・セグメントが連続のうちの１つであるか否かを示す連続指標、各デジタル・データ・セグメント内のオクテットの総数を示す総オクテット数指標、デジタル・データ・セグメントが記憶されることになる位置を示すアドレス位置情報、及びチェックサムを含み、データ・サーバは、デジタル・データ・セグメントが中央サービスによって変更又は除去されるまで、トランスミッタによる連続的なブロードキャストのために、デジタル・データ・セグメントを受信すること、及びデジタル・データ・セグメントをカルーセル・バッファに追加することを行うように動作可能である。本態様の他の実施例は、方法のアクションを行うようにそれぞれ構成された、対応するコンピュータ・システム、装置、及び、１つ又は複数のコンピュータ・ストレージ・デバイスに記録されたコンピュータ・プログラムを含む。

別の一般的な態様は、モバイル・レシーバのデータを処理する方法を含み、方法は、第１のコンテナ及び第１のデジタル・データ・セグメントを含む第１のＦＭブロードキャスト信号を受信して復調することであって、第１のコンテナが９オクテットから６０オクテットまでであり、会場識別子、デジタル・データ・セグメント・タイプ指標、モバイル・レシーバ識別子、第１のデジタル・データ・セグメントが連続のうちの１つであることを示す連続指標、第１のデジタル・データ・セグメント内のオクテットの総数を示す総オクテット数指標、第１のデジタル・データ・セグメントが記憶されることになる位置を示すアドレス位置情報、及びチェックサムを含む、第１のＦＭブロードキャスト信号を受信して復調することと、第２のコンテナ及び第２のデジタル・データ・セグメントを含む第２のＦＭブロードキャスト信号を受信して復調することであって、第２のコンテナが９オクテットから６０オクテットまでであり、会場識別子、デジタル・データ・セグメント・タイプ指標、モバイル・レシーバ識別子、第２のデジタル・データ・セグメントが連続の中の２番目であることを示す連続指標、第２のデジタル・データ・セグメント内のオクテットの総数を示す総オクテット数指標、第２のデジタル・データ・セグメントが記憶されることになる位置を示す第２のアドレス位置情報、及び第２のチェックサムを含む、第２のＦＭブロードキャスト信号を受信して復調することと、を含む。本態様の他の実施例は、方法のアクションを行うようにそれぞれ構成された、対応するコンピュータ・システム、装置、及び、１つ又は複数のコンピュータ・ストレージ・デバイスに記録されたコンピュータ・プログラムを含む。

本発明は、添付の図面を参照しながら開示される。

本発明の１つの実施例によるシステム・アーキテクチャの一部を示す図である。本発明の１つの実施例によるシステム・アーキテクチャの一部を示す図である。本発明の１つの実施例による実例のモバイル・レシーバ及びホスト・デバイスを示す図である。本発明の１つの実施例によるホスト・デバイス上の実例のディスプレイを示す図である。本発明の１つの実施例による表示のための実例のスキーマの例証的な図である。本発明の１つの実施例による実例の参照テーブル（Ａ）の例証的な図である。本発明の１つの実施例による実例の参照テーブルの別の例証的な図である。本発明の１つの実施例による実例の参照テーブル（Ａ）の別の例証的な図である。本発明の１つの実施例によるホスト・デバイス上の実例のディスプレイを示す注釈つきの図であり、参照番号は、参照テーブル内の位置情報を指す。本発明の１つの実施例による実例のメッセージ構造スキーマの例証的な図である。本発明の１つの実施例による実例のメッセージ構造の例証的な図である。本発明の１つの実施例による方法を示すフローチャートである。本発明の１つの実施例による緊急警報を送信するためのシステム・アーキテクチャの一部を示す図である。エクステンシブル・マークアップ・ランゲージ（ＸＭＬ：ｅｘｔｅｎｓｉｂｌｅｍａｒｋｕｐｌａｎｇｕａｇｅ）を使用するＣｏｍｍｏｎＡｌｅｒｔＰｒｏｔｏｃｏｌ、Ｖｅｒ．１．２に指定されたような実例の緊急警報メッセージを示す図である。図９ＡのＸＭＬメッセージ内の情報が本発明の１つの実施例によるテーブル・フォーマットに、どのようにコンバートされ得るかを示す図である。本発明の１つの実施例による方法を示すフローチャートである。本発明の１つの実施例による実例のハードウェア実装形態を示すブロック図である。本発明の１つの実施例による実例の実装形態の機能を示すブロック図である。

対応する参照文字は、いくつかの図の全体にわたって対応する部分を示す。本明細書で示される実例は本発明のいくつかの実施例を示すが、いずれかの手法で本発明の範囲を限定するものとして解釈されるべきではない。

次に図１に移ると、１対多構成で多くのデバイスとデータを通信するためのシステムが提供される。システムは、デジタル・デバイスのコマンド及び制御のために後で使用されることが可能な、デジタル・ファイル、ストリーミング・データ、マルチメディア・ファイル、及びデジタル機能、を含むがこれらに限定されない任意のタイプのデジタル情報をプッシュするように動作可能である。

図１は、モバイル・レシーバ１３０をそれぞれ有する大勢の受信者１２０にデジタル・データを通信するために会場１１０に配置されたシステム１００を示す。会場１１０は、データをワイヤレスでブロードキャストするためのデータ・サーバ１４０及びトランスミッタ１５０を装備される。トランスミッタ１５０は、会場１１０に配置された小型（例えば、１２１．９２ｃｍ（４フィート））アンテナであってもよい。１つの実施例において、トランスミッタ１５０及びデータ・サーバ１４０は、同じ物理デバイスに統合される。代替として、トランスミッタ１５０は、リモート・コンピュータ・デバイスで動作するソフトウェアによって制御及び／又は構成される。各モバイル・レシーバ１３０は、携帯電話などのホスト・デバイス１６０にデータを再送信すること、又は、データを使用して他の機器をコマンド／制御することができる。１つの実施例において、モバイル・レシーバ１３０及びホスト・デバイス１６０は、同じ物理デバイスに統合される。ホスト・デバイス１６０は、使用されると、モバイル・レシーバ１３０からデータが受信されたホスト・デバイス１６０上で表示された、又はそうでなければ利用可能にされたアプリケーション１７０を動かすように動作可能であり、ホスト・デバイス１６０が利用できるネットワークで、好ましくはＴＣＰ／ＩＰネットワークで、モバイル・レシーバ１３０へのレスポンスの送信を可能にする。システム１００は、他のアクセス・ネットワークと相互接続することができるが、簡略化のために、これらのエンティティ／インターフェースは示されない。図示されるように、システム１００は、パケット交換型サービスを提供する。

１つの実施例において、受信者１２０は、図２に詳述された中央サービスを受信者１２０のモバイル・レシーバ１３０に登録することによって、受信者１２０のモバイル・レシーバ１３０にだけ向けられた暗号化又は符号化メッセージを受信する。

図２に示された１つの実施例において、（データ・ブロードキャスト・プログラミングを含み得る）データ・フィードが、ネットワーク化された中央サービス２００からインターネットを介して会場１１０に提供される。中央サービス２００は、サーバを含むことができ、サーバは、オーディオ／ビデオ／テキスト／コマンド・ストリーミング・アプリケーションのために作られたウェブ・サーバ又はストリーミング・サーバであることが可能である。サーバ上のファイルは、オーディオ／ビデオのテキスト／コマンド・コンテンツのいずれかのタイプを収めることができる。中央サービス２００は、ファイルをソケットに送ることによって、オーディオ／ビデオのテキスト／コマンド・ファイルをクライアントに向ける。ＴＣＰとＵＤＰの両方のソケット接続が使用されてもよい。オーディオ／ビデオ・ファイルをネットワークに送る前に、ファイルはセグメント化され、セグメントは、下記でさらに詳細に記述される、オーディオ／ビデオのテキスト／コマンド・トラフィックに適したヘッダ情報と共にカプセル化される。データ初期化及び生成は、中央サービス２００、又は会場に局所的な類似のサービスにおいて行われてもよい。代替として、中央サービス２００は、会場１１０にあってもよい。会場１１０は、下記に記述される、中央サービス及び／又はローカル・サービスを装備されてもよい。データ・サーバ１４０は、２つ以上のサーバ（中央サービス２００、又は１つ若しくは複数のローカル・サービス）からコンテンツを受信することができる。１つの実施例において、データ・サーバ１４０は、「カルーセル」タイプのバッファに全てのメッセージを記憶し、トランスミッタ１５０を介してバッファの内容を絶えずブロードキャストする。「カルーセル」タイプは、データ・パケットのセットが１つ又は複数のレシーバによって受信されることを保証するために、徐々にデータ・パケットのセットを繰り返しブロードキャストするセッション・プロトコルを指す。

中央サービスのオペレータが、１要素ずつカプセル化データ要素を手動で入力してもよく、又は代替として、中央サービスが、カプセル化データを自動的に入力するように動作可能であってもよい。

会場１１０では、データ・フィードはデータ・サーバ１４０で受信され、例えば、イーサネット接続上のＵＤＰプロトコルを介して、トランスミッタ１５０に通信される。データ・サーバ１４０は、サービング・ゲートウェイ及びパケット・データ・ネットワーク（ＰＤＮ）ゲートウェイ、並びに、中央サービス２００又はローカル・サービスと、モバイル・レシーバ１３０との間のシグナリングを処理する制御ノードを含むことができる。トランスミッタ１５０は、例えば、３．５平方マイル／６平方ｋｍのエリア（半径１マイル／１．６ｋｍ）といった、選ばれた距離を越えてＲＦ信号を送出する恒久的に取り付けられたアリーナ送信アンテナであってもよい。トランスミッタ１５０は、１つの実施例において、２１７ＭＨｚ～２２０ＭＨｚ（２００ｋｂｐｓ）の間でブロードキャストされる１方向データを送信する。ＦＣＣの認可があれば、選ばれた距離は、より大きくなってもよい。当技術分野で知られたような送信メカニズムのいくつかのタイプが用いられてもよく、ＦＭ無線信号でのパルス符号変調（ＰＣＭ）、ＩＳＤＢ－Ｔ、ＩＳＤＢ－Ｔ、マルチメディア・ブロードキャスティング、デジタル・システムＥ、Ｔ－ＤＭＢ、ＤＶＢ－Ｈ、ＤＶＢ－ＳＨ、ＦＬＯ、ＲＡＶＩＳ、及びＤＶＢ－Ｔ２Ｌｉｔｅを含む。

図３に移ると、モバイル・レシーバ１３０及びホスト・デバイス１６０が示される。モバイル・レシーバ１３０は、別個の非デジタル・デバイスをインターフェースし、制御するように設計された、独立したレシーバであってもよい。別の形式では、モバイル・レシーバ１３０は、例えばＢｌｕｅｔｏｏｔｈといった、有線又はワイヤレス通信プロトコルを介してホスト・デバイス１６０にデータを中継するように動作可能である。さらに別の実施例において、モバイル・レシーバ１３０は、ホスト・デバイス１６０に統合される。１つの実施例において、モバイル・レシーバ１３０は、車両に取り付けられるように設計され、車の電気システムによって作動し、車が走っているときに起動される。別の実施例において、モバイル・レシーバ１３０は、携帯型であり、バッテリで作動し、ユーザによってオンにされる。モバイル・レシーバ１３０の動作は、デジタル通信を維持できるいずれかのＲＦ周波数を使用することができる。１つの実施例において、モバイル・レシーバ１３０は、２１７ＭＨｚの周波数で動作する。

モバイル・レシーバ１３０は、独自のレシーバ／アンテナを通じてブロードキャスト・データを受信する。各モバイル・レシーバ１３０は、ＲＦ搬送波に変調された情報を復元し、モバイル・レシーバ１３０又はホスト・デバイス１６０において、コントローラ／プロセッサに情報を提供する。コントローラ／プロセッサは、プログラム・コード及びデータを記憶するメモリに関連付けられることが可能である。メモリは、コンピュータ可読媒体と呼ばれることもある。ホスト・デバイス１６０において、制御装置／プロセッサは、輸送チャネルと論理チャネルの間の逆多重化、パケット再構成、解読、ヘッダ解凍、及び制御信号処理を行う。コントローラ／プロセッサは、エラー検出を担うこともできる。

モバイル・レシーバ１３０は、充電及びデータ・アップロードのためのポート又はコネクタ（例えばＵＳＢ）を有し、例えばボタンといったスイッチを制御して、様々な機能をアクティブにし、制御することができる。例えば光といったステータス指標／データ送信指標が提供されてもよい。モバイル・レシーバ１３０は、ホスト・デバイス１６０への、ＩＲ、短距離ＥＭＦ、近距離送信、等を含むがこれらに限定されないＢｌｕｅｔｏｏｔｈ又は他の通信リンクを介した小規模フォブの形であってもよい。モバイル・レシーバ１３０は、ブロードキャスト・データをトランスミッタ１５０から受信するように動作可能であってもよい。モバイル・レシーバ１３０は、承認信号又は制御信号などのデータをホスト・デバイス１６０と通信するため、又はそうでなければ、送受信するためのトランシーバをさらに含んでもよい。１つの実施例において、モバイル・レシーバ１３０もホスト・デバイス１６０も、中央サービス２００に戻すブロードバンド・バック・チャネル／ブロードバンド・リバース・チャネル能力を有しておらず、むしろ、ホスト・デバイス１６０は、短距離通信又は狭帯域バック・チャネルを介してモバイル・レシーバ１３０と通信する。モバイル・レシーバ１３０は、この目的のために会場１１０の周辺にある複数の固定トランシーバとも通信することができる。モバイル・レシーバ１３０は、８８ＭＨＺ～１０８ＭＨＺの周波数帯域の標準ＦＭ無線ブロードキャストを受信するように動作可能な無線レシーバ又はチップをさらに含んでもよい。１つの実施例において、モバイル・レシーバ１３０は、ＦＭ無線レシーバを含むホスト・デバイス１６０上のモジュールの構成である。

モバイル・レシーバ１３０は、ＭＡＣアドレス、又は、ＥＭＥＩ若しくは同等物などの他の識別コードなどの識別情報を割り当てられてもよい。全てのデバイスに全体的にブロードキャストすることと、識別したモバイル・レシーバ１３０に明確に向けることとの両方を行うよう意図されたデータ・ブロードキャスト送信を、特定のモバイル・レシーバ１３０が受信できるように、モバイル・レシーバ１３０に割り当てられた識別情報が使用されてもよい。代替として、ＭＡＣアドレス、又はホスト・デバイス１６０からの他の識別情報は、個々又は一群の受信者１２０への直接送信を指定するために使用されることが可能である。

１つの実施例において、モバイル・レシーバ１３０は、中央サービス２００からの送信を受信し、任意選択として、これらをデコードし、これらをホスト・デバイス１６０にさらに送信するように動作可能な中間レシーバ／トランシーバとして構成される。モバイル・レシーバ１３０からホスト・デバイス１６０への送信は、ホスト・デバイス１６０で利用可能な任意の通信リンクによって、又は、Ｂｌｕｅｔｏｏｔｈアダプタなどのデバイス上のポートが利用可能な場合、プラグイン・モジュールによって行われてもよい。モバイル・レシーバ１３０は、ホスト・デバイス１６０上で動くアプリケーション１７０を介して、又は、Ｍｉｃｒｏｓｏｆｔ（Ｒ）からのＲｅｍｏｔｅＤｅｓｋｔｏｐなどの端末エミュレータ・プログラムを介して、ホスト・デバイス１６０と通信するように動作可能である。アプリケーション１７０は、ホスト・デバイス１６０に事前に記憶されることが可能な画面を制御するためのコンパクト・メッセージ通信を可能にする。

図４に移ると、ディスプレイ４１０を有するホスト・デバイス１６０が示される。ホスト・デバイス１６０は、セルラー携帯電話、スマート・フォン、セッション確立プロトコル（ＳＩＰ）電話、ラップトップ、パーソナル・デジタル・アシスタント（ＰＤＡ）、衛星無線、全地球測位システム、マルチメディア・デバイス、車両無線若しくはナビゲーション・システム若しくはコンピュータ、ビデオ・デバイス、デジタル・オーディオ・プレーヤ（例えば、ＭＰ３プレーヤ）、カメラ、ゲーム機、又は他の任意の類似のデバイスであってもよい。また、ホスト・デバイス１６０は、当業者によって、移動局、加入者局、モバイル・ユニット、加入者ユニット、ワイヤレス・ユニット、リモート・ユニット、モバイル・デバイス、ワイヤレス・デバイス、ワイヤレス通信デバイス、リモート・デバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザ・エージェント、モバイル・クライアント、クライアント、又は他のいくつかの適切な名前として呼ばれることもある。ホスト・デバイス１６０は、会場１１０でブロードキャストされたデータを受信又は処理するように、アプリケーション１７０によって構成されてもよい。１つの実施例において、受信者１２０は、適切なアプリケーション・プロバイダ又はアプリ・ストアから、アプリケーション１７０をホスト・デバイス１６０にダウンロードする。受信者１２０がアプリケーション１７０を開くと、アプリケーション１７０は、（有線又はワイヤレスで、例えば、Ｂｌｕｅｔｏｏｔｈを介して）モバイル・レシーバ１３０と同期、又はそうでなければ通信するように構成可能である。モバイル・レシーバ１３０は、アプリケーション１７０によって処理されたブロードキャスト・データをホスト・デバイス１６０に送信する。メディア・プレーヤのような別個の又は統合されたヘルパー・アプリケーションが、オーディオ／ビデオ・データを再生するために用いられてもよい。アプリケーション１７０は、再生中にその場でオーディオ／ビデオをさらに解凍すること、パケット・ジッターを抑制すること、受信者への表示のためにグラフィカル・ユーザ・インターフェースを提供すること、等ができる。

１つの実施例において、アプリケーション１７０は、従来のウェブサイト又はモバイル・アプリと同様に受信者１２０によって見ることができ得るディスプレイ４１０にブロードキャスト・データを表示する。１つの実施例において、アプリケーション４２０は、ホスト・デバイス１６０に関連付けられたユーザ・プロフィールを含んでもよい。ユーザ・プロフィールは、例えば好ましい言語を含んだ、ユーザの好みを含んでもよい。特定のブロードキャストが、個々の又はグループのメッセージを送ることができることが必要になることが予想される場合、アドレスに一致するレシーバによってのみ実行可能になる特定のメッセージ及び命令が無線で配信されることが可能になるアドレス提供が定義されることになる。ブロードキャスト・データは、ユーザ・プロフィールで指定された言語で表示されてもよい。いくつかの実施例において、ホスト・デバイス１６０は、基地局、ベース・トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービス・セット（ＢＳＳ）、拡張サービス・セット（ＥＳＳ）、又は、他のいくつかの適切な専門用語であってもよい。１つの実施例において、ホスト・デバイス１６０及びモバイル・レシーバ１３０は、同じ物理デバイス内に構成される。

１つの例示的な実施例において、システム１００は、小型（例えば、２．５４ｃｍ×２．５４ｃｍ（１インチ×１インチ））のＢｌｕｅｔｏｏｔｈ搭載フォブ、又はポケット・レシーバの形のモバイル・レシーバ１３０をそれぞれ有したゲーム参加者の受信者１２０にデジタル・データを通信するために、フットボール・スタジアムに配置される。フットボール・スタジアムは、データ・サーバ１４０及びトランスミッタ１５０、モバイル・レシーバ１３０にワイヤレスでデータをブロードキャストするための１２１．９２ｃｍ（４フィート）の高さのアンテナを装備される。各モバイル・レシーバ１３０は、例えば、ゲーム・スコア及び統計情報、ビデオ・ハイライト及びリプレイ、メッセージ、ファン・コンテスト、広告、発表、最新の気象情報、カスタム・プログラム、宣伝、ライブ・ビデオ、等を含むブロードキャスト・データをトランスミッタ１５０から受信し、携帯電話、タブレット、コンピュータ、又は他のワイヤレス・デバイスを含むペアにされたホスト・デバイス１６０に、Ｂｌｕｅｔｏｏｔｈを介してブロードキャスト・データを再送信する。

例えば、ホスト・チーム又はスタジアム所有者は、イベント中にモバイル・レシーバを通じて得られた売上の一部を要求すること、又は、ゲーム中にブロードキャストされたスポンサーシップ又は広告に課金することによって収入を生み出すことができる。ホスト・デバイス１６０は、例えばＡｐｐｌｅＳｔｏｒｅ又はＡｎｄｒｏｉｄＡｐｐＳｔｏｒｅから、ゲーム前又はゲーム中にダウンロードされたアプリなどのアプリケーション１７０を動かすように動作可能である。受信者によってアクティブにされると、アプリケーションは、モバイル・レシーバ１３０のフォブからデータが受信されたホスト・デバイス１６０上で利用可能になったブロードキャスト・データを処理して表示する。

ホスト・デバイス１６０上で動くアプリケーションは、ブロードキャストで提供された命令に基づいて、ディスプレイ４１０に情報を表示するように構成可能である。これらの命令は、例えば図５Ａ～図５Ｄに示されるように、表示することになる特定の情報を収めるテーブルを参照することができる。ブロードキャスト・データが使用される手法は、モバイル・レシーバ１３０とペアにされたホスト・デバイス１６０のプログラミングに依存することになる。データを小さいインクリメントに編成しておくために、一連の「テーブル」内にメモリ・マップが編成されてもよい。１つの構成では、テーブルあたり２５５行２５５列までの、２５５個までの異なるテーブルが存在することが可能である。テーブル内の各「セル」は、ホスト・デバイス１６０上のアプリケーション１７０によって個別にアドレス指定されることが可能な単一の項目を収めることになる。各テーブルに記憶されたデータが本質的に類似のものになるように、テーブルを編成することが、必要ではないが、好ましい可能性がある。ホスト・デバイス１６０上で動くアプリケーション１７０は、図示のように、データセットがテーブルのうちの１つに記憶されることによって、変化することになる表示情報の任意の一部が制御されることになるように、書かれることになる。

これらの実例では、オクテットに対して「Ｂ」、また、文字列に対して「Ｓ」でデータ型が示される。例えば、グループＩＤの評価を要求するグループでフィルタにかけられた１つ又は複数のメッセージを指す｛ＧＦ｝、及び、この実例では、ホスト・デバイス１６０にブロードキャストされた命令が偽に変えることを示しても、一度「真」にセットされると偽に変えられるべきではないことを意味する｛Ｓｔｉｃｋｙ｝といった、一定の特徴についてのシンボルが同様に表されてもよい。「バイト」に対して８ビット以外を使用するシステムとの混乱を回避するため、本開示、又は図表が「バイト」に言及する場合、それは「オクテット」又は８ビットを指していることが理解されるべきである。

図５Ａに示される１つの実例では、行１２列Ｅにおいて、ブロードキャストは、適切な「ホーム・チーム」の登録選手名簿（この場合、テーブル３）を、行１２列Ｆにおいて、「ビジター・チーム」の登録選手名簿（テーブル４）を見つけるためにアプリケーションが見るべき場所を示す。各列は、このチームの登録選手名簿を収めるテーブルに対応する「チームＩＤ」（オクテット）を有する。このような登録選手名簿の特定のデータを収めることになる実例のテーブル構成が図５Ｂに示される。図５Ａに戻ると、行１１列Ｃにおいてビデオ・ディスプレイが参照される。例示的な参照テーブルＴ２００が、図５Ｃに示される。この実例では、テーブル内の第１のセルは、完全なビデオを構築するために、どれだけの追加セルが必要になるかを示す。写真又は他のマルチメディア・ファイルが同様に提供されてもよい。画面色などの他の情報が探索テーブル内で同様に提供されることが可能であり、図５Ｄに例示的な探索テーブルが示される。セルあたりのデータ量は、小さく保たれるのが好ましい。テーブルは何度も再び作り出され、例えば１秒あたり２００キロビットの速さで、トランスミッタ・ストリームからそれぞれ送信される。１つの実例では、あらゆるテーブルのあらゆるセルが、５秒毎に再び書かれる。したがって、ディスプレイ全体を再レンダリングすることなく、新しい情報が表示されることが可能である。

図５Ｅに移ると、ホスト・デバイス１６０及びディスプレイ４１０が、アプリケーション１７０のための例示的な「ホームページ」と共に示される。表示されるべき適切なデータへのアプリケーション１７０の参照番号を示すコメントが重ねられている。例えば、５１０に表示された第１のチームの図形記号又はロゴは、テーブル１、行０、列２にマッピングされる。参照要素は図形記号（又は写真、ロゴ、等）なので、テーブル１内の参照セル位置のデータは、特定の図形記号ファイルに割り当てられることになる。別の実例では、ゲーム時間５２０（「東部時間午後３時」）が、テーブル１、行０、列１にあるセル内で見つかる。各位置におけるセル内の情報は、やがて変更又は除去されるので、表示は、新しい情報で更新することになる。１つの実施例において、テーブル、行、及び列位置において指定されたデータは、テーブル・セル（例えば、テキスト又は番号）にデータが現れるので、アプリケーション１７０によって表示されることになる。別の実施例において、参照テーブル・セルに含まれるデータは、他のいくつかのデータを表示するためのコマンドに相当する。例えば、Ａｌａｂａｍａ対Ｃｌｅｍｓｏｎのゲームの「ゲーム・ステータス」は、番号４を収めるテーブル１、行１、列１にあるデータによって示される。この実例では、テーブル１、行１、列１の内容は、テーブル１に示されるように、表示されるべき特定のテキスト、又は追加アクションを参照する。

アプリケーション１７０は、次に、テーブル１、行１、列１というセルに番号４が含まれるとき、５Ｅに示されるように、テキスト「確定」を表示する。

１つの実施例において、受信者１２０は、ディスプレイ４１０に示されたデータと対話することができる。例えば、そのセルにリンクされたディスプレイ４１０のセクションを、ユーザが「クリック」若しくはタップ、又はそうでなければ、セクションと対話するとき、インターネットへのある程度の接続があると仮定すると、ホスト・デバイス１６０は、ＵＲＬに接続し、受信者１２０の連絡先情報と共にリクエストを中継することになる。例えば、これは、購入リクエストを含んでもよい。このように、ブロードキャスト・コンテンツは、インターネットを使用してコンテンツをダウンロードしなくても、カタログ又はメニューをユーザがブラウズし、その後、インターネットで購入リクエストを中継できるようにすることができる。

図６Ａに移ると、双方向通信を必要とせずにブロードキャスト・データの送信を可能にする例示的なメッセージ・カプセル化プロトコル５００が示される。メッセージ・プロトコルは、デジタル命令、ファイル、ストリーミング・データ、又は他の任意のタイプのデジタル情報を複数のデバイスに同時に送信することを可能にする。

１つの実施例において、ブロードキャストされるデジタル情報は、意図したモバイル・レシーバ１３０のアドレス情報、及び、適切な場合、より大きいファイル内のデータの位置を含むプリアンブルを有するメッセージに、データの各オクテットが収められるように構造化される。このアドレス情報は、全ネットワークのタスクを行うのに必要な任意のシーケンスでデータが送信されるのを可能にする。バイナリ・データは、より大きいファイルを破壊せずに、より大きいデータ・ファイルと混ぜられることが可能である。アドレス情報は、例えば、データベース・アドレス、テーブル構造、又はメモリ・マップの形であることが可能である。送信される各メッセージは、意図したモバイル・レシーバ１３０が、ブロードキャスト・データを解釈し、実行又は記憶するのに必要な全てのアドレス情報を収める。

データ送信が中央サービス２００からブロードキャストされるとき、どのスタジアム／会場にデータ送信が達する予定であるかを識別する、特に会場ＩＤを識別するプリアンブル（又はポストアンブル）を伴うマルチ・オクテット・メッセージ・データ構造を有することになるのが好ましい。同時に、またごく近くで行われている複数のイベントがある可能性があるので、モバイル・レシーバ１３０は、一定の実施例において、アクティブにされたときに特定のイベント／会場に事前設定されてもよい。また、この構造は、会場１１０に対するあらゆるモバイル・レシーバ１３０によって受信されることになる「全体的なブロードキャスト」、又は、モバイル・レシーバ１３０のＭＡＣアドレスの一致など、モバイル・レシーバ１３０の識別情報を一致させることによって決定され得る、特定のモバイル・レシーバ１３０に対する「特定」などのメッセージ・タイプを含むことができる。１つの実施例において、ホスト・デバイス１６０上で動作するアプリケーションは、アプリケーションが動作している中央サービス２００に、及び、アプリケーションがブロードキャストを受信している会場ならどのような場所へでも、自動的に通信するようにプログラムされる。中央サービス２００は、次に、例えば、ユーザのホスト・デバイスにアプリケーションが最初にインストールされたときに作り出された受信者１２０のデータベースに、この情報をリンクする。モバイル・レシーバ１３０のＭＡＣアドレスは、データベース内の会場に関連付けられ、中央サービス２００が個々の／グループのメッセージを伝える必要がある場合／ときを指すことができる。この構造は、特定タイプのメッセージの場合、モバイル・レシーバ１３０の識別情報（例えば、ＭＡＣアドレス）を有するさらなるオクテットをさらに含んでもよい。この構造は、また、メモリ・マップ又はメッセージ・タイプ識別子を含むことができ、これらは、ブロードキャスト・データがどのように使用されるべきか、及び／又は、事前定義されたメモリ・マップのどこに記憶されるべきかについて、（適切な場合）モバイル・レシーバ１３０及び／又はホスト・デバイス１６０に知らせる。１つの実施例において、この情報は、ホスト・デバイス１６０にインストールされたとき、アプリケーション内で定義される。（以下に記述される）事前定義されたセル位置に記憶されたアドレス情報が、モバイル・レシーバ１３０のＭＡＣアドレスに一致すると、この特定のメッセージのペイロードの内容は、アプリケーションで定義されたものとして実行されてもよい。この構造は、メッセージ・データをさらに含むことになる。ビデオ又は画像の場合、メッセージは、単一又は一群のピクセルであってもよい。

１つの実施例において、バック・チャネル帯域幅の不足を考慮に入れるために、バック・チャネル承認信号のないメッセージ配信を保証するために調節が行われてきた。中央サービス２００は、全てのメッセージがホスト・デバイスによって長く受信されてきたとしても、全てのメッセージを所定の期間、連続的に送信することになるのが好ましい。これは、第１の送信で失われた可能性のあるメッセージ・データの「バックフィル」を可能にすることになるが、承認の欠如が原因で、どのデータが欠落しているのかを知るための仕様が現在ある。所定の期間、継続的に再送信することによって、ほとんどのメッセージは、承認の必要なく、最終的に完全に配信されることになる。スポーツの用途では、例えば、変化しない限り／変化するまで、スコアが絶えず再送信されることになる。この点において、見直されたスコアは、カルーセル・ブロードキャストの一部になることになる。アプリケーションによって使用されるコンテンツは、任意の所与の時点で、最新の情報がユーザに利用可能になるように、このカルーセル法を使用して絶えず再ブロードキャストされることになる。

図６Ａに、本明細書又は他において説明されるシステム及び方法と共に使用するためにデータ・ストリームを送信するための例示的なコンテナ・フォーマット又はヘッダ情報６１０が示される。メッセージは、９オクテットのような少量から、６０オクテットまで、様々な長さであることが可能である。

各メッセージの「０」オクテット６１１は、「メッセージＩＤ」を収める。この番号は、続くメッセージのタイプを示す。「０１」オクテット６１２は、「会場ＩＤ」である。上述のように、これは、トランスミッタ・プログラムによってセットされ、中央サービス４００によって送られる番号であり、各イベント／会場、及び／又はイベント／会場／日付に一意のものである。トランスミッタ・プログラムは、１つの実施例において、中央サービス２００上で、又は、特定のイベントで使用される任意のローカル・サービス上で動くソフトウェア・プログラムである。トランスミッタ・プログラム（及びローカル・サービスのトランスミッタ・プログラム）は、特定のイベントでブロードキャストされることになる全てのメッセージ・パケットを作り出すことを担う。これらのメッセージ・パケットは、次に、データ・サーバ１４０に通信され、ここで、メッセージ・パケットは、（例えば、中央サービス２００又はローカル・サービスによって）変更又は除去されるまで、トランスミッタ１５０による連続的なブロードキャストのためにカルーセル・バッファに追加される。ホスト・デバイス１６０内のソフトウェアは、各メッセージの「０１」オクテットを、保存した会場ＩＤ番号と比較するように、メモリ（例えばＮＶＲＡＭ）に会場ＩＤ番号を保存する。保存した番号が、メッセージのオクテット「０１」に収められた番号と同じである場合、保存した番号は無視されることが可能であり、メッセージは、普通に処理される、すなわち、構文解析され、メモリに保存されるべきである。メッセージのオクテット「０１」に収められた番号が、メモリに保存されていたものと異なる場合、テーブル全てに記憶された全てのデータはクリアされ、新しい番号が保存されることになる。新しいテーブルが次に作り出され、その後の受信メッセージ内のデータと共にロードされる。１つの実施例において、この処理を使用すると、受信者が新しいイベント、ロケーション、又は会場にいくと、受信者のホスト・デバイスのディスプレイに記憶される可能性のある古いデータは「クリアされる」。別の実施例において、会場ＩＤ＝０のとき、例外が行われる。この場合、メモリ・リセットは開始されず、受信したメッセージは、特定のモバイル・レシーバ１３０に向けられた「個々のアドレス」又はメッセージとして処理される。「個々のアドレス」メッセージの最初の６つのオクテットは、例えば、意図したモバイル・レシーバ１３０のＭＡＣアドレス又は他のＩＤといった、モバイル・レシーバ１３０の識別情報を示すために使用されてもよい。他の全てのモバイル・レシーバ１３０は、その後、このメッセージを無視することになる。

オクテット「０２」６１３は、続くデータが、テーブルのうちの１つにおけるセルの全内容になるか否か、又は、続くデータが、セルをポピュレートするために使用されることになる一連のメッセージのうちの１つであるかどうかを示す番号（Ｃ_Ｌ）を収める。例えば、Ｃ_Ｌが「０」である場合、続くデータがセルの全内容になる。このメッセージの内容は、（もしあれば）セルに現在記憶されているデータを上書きすることになる。Ｃ_Ｌが「１」である場合、このメッセージの内容は、最終的にこのセル内の一連の文字になるものの第１の部分であることになる。Ｃ_Ｌが「２」である場合、内容は、以前のメッセージ内で送られたものの最後に添付されることになる、などである。１つの実例では、Ｃ_Ｌが「０」又は「１」にセットされるときはいつでも、セルに現在記憶されている全てのデータが上書きされる。

オクテット「０３」６１４は、どれだけ多くの総オクテットがメッセージ内にあるかを示す番号を収める。この番号は、８＋Ｐ_Ｌであり、ここで、Ｐ_Ｌは、メッセージの実際のペイロード内のオクテットの数を示す。Ｐ_Ｌ＝０は、１オクテットのペイロードを示し、Ｐ_Ｌ＝１は、２オクテットのペイロードを示す、等である。チェックサムは、メッセージ長の計算ではカウントされない。

オクテット「０４」６１５、「０５」６１６、及び「０６」６１７は、オクテット「０７」から「Ｐ_Ｌ＋７」までに収められた情報のアドレス位置を収める。１つの実例では、オクテット「０４」６１５は、テーブル番号を示し、オクテット「０５」６１６は、行番号を示し、オクテット「０６」６１７は、データが記憶されることになる位置の列番号を示す。Ｐ_Ｌは、セルに記憶されているオクテットの数を示すので、オクテット「０７」から「Ｐ_Ｌ＋７」までに収められた情報は、オクテット「０４」、「０５」、及び「０６」によって指定されたセルに順次記憶される。

最後のオクテット（Ｐ_Ｌ＋８）６１８は、常にチェックサムである。このオクテットは、受信した各メッセージを検証するために使用されるが、テーブルには記憶されない。

図６Ｂは、例示的なメッセージを示す。この構造では、ＭＩＤ＝Ｆ４＝可変長メッセージ、ＶＩＤ＝４８、ＰＩＤ＝１７、ＬＥＮ＝９、ＡＴ＝テーブル＃＝１７、ＡＲ＝行＃＝１、ＡＣ＝列＃＝１、データ＝Ｄ０＋Ｄ１＝０１、００、ＣＨＫ＝ＡＤである。

１つの実施例において、ブロードキャストされることになるメッセージの各パケットは、独立した項目である。上述のアドレス方式は、モバイル・レシーバ１３０によって正しく受信された任意のパケットが、他の内容が既に完全に送信されたか否かにかかわらず、他の任意の必要なパケットと共に、ペアにされたホスト・デバイス１６０によって保存され、組み立てられ、表示されることを可能にする。言い換えれば、警報メッセージのテキスト部分が、５つのパケットの間で分けられる場合、これら５つのパケットが受信されるとすぐ、メッセージは、例えば、写真又はビデオのような関連付けられたマルチメディア・ファイルに属する、より多くのパケットが依然としてブロードキャストされている可能性があったとしても、ホスト・デバイス１６０に表示されることが可能である。実例として、図５に示されるように、行０、列０は、ゲームにおいて全ての受信者１２０に送られた発表を表示するために使用される。メッセージ・パケットは、モバイル・レシーバ１３０によって必ずしも順番に受信される必要はなく、連続している必要もない。

１つの実施例において、システムは、任意のボー・レートで機能する。メッセージ間の時間遅延が影響を与えることはなく、ブロードキャスト送信の全体にわたって必ずしも同じレートでパケットが送られる必要もない。１つの実例では、メッセージ・フォーマットは、４８００ボーのボー・レートで送信される。

１つの実施例において、メッセージ・フォーマットは、マルチメディア・コンテンツのＲＦブロードキャストのために提供される。１つの代替実施例において、メッセージ・フォーマットは、ＵＤＰを介してインターネット全体にわたって同じタイプのコンテンツをブロードキャストすることを可能にするために使用される。データ・ストリーム内の個々のパケットは、任意の順序で受信されることが可能であり、受信の承認を必要としないので、パケットは、ＵＤＰ接続で送信されることが可能である。ＵＤＰの使用を可能にすると、速度を劇的に向上させること、及び、何百万もの同時受信者１２０にインターネットでコンテンツをサーブしようとしている人によって使用される典型的なインターネット・サーバのインフラストラクチャ要件を低減させることが可能になる。ＵＤＰは「コネクションレス」プロトコルなので、ＵＤＰで送信されるデータは、データへのユーザ需要に基づいて、サーバの帯域幅、又はルータ容量を増加させる必要なく、何百万もの受信者１２０によって同時に受信され、処理されることが可能である。また、データ受信承認の必要がないので、転送レートは、ネットワーク輻輳が低減することにより、劇的に上昇することになる。

さらなる実施例において、マルチメディア・メッセージ又はデジタル・データは、ＦＭトランスミッタから、モバイル・レシーバ１３０を有した受信者１２０に送信されてもよく、（ホスト・デバイス１６０に物理的に統合されていても、ホスト・デバイス１６０とは別個であっても）モバイル・レシーバ１３０は、ＦＭ無線チップを備える。セルラー電話、又は自動車制御パネル／カー無線若しくはステレオ、又は類似の組合せの無線／ナビゲーション・システムのようなホスト・デバイス１６０は、ＦＭ無線チップを収めることができる。デジタル・データ／マルチメディア情報は、上記で示されたように、ヘッダ情報を使用してセグメント化されてカプセル化され、ＦＭで送られるために変調され、その後、ＦＭトランスミッタから（例えば、カー・ステレオ・システムにおけるＦＭチューナ及び復調器チップ並びに関連モジュールのような）モバイル・レシーバ１３０に、例えば５６ｋｂ／ｓでブロードキャストされてもよい。カー・ステレオのモバイル・レシーバ１３０の場合、各パケットは、左右ステレオ・チャネルで交互になることが可能である。ホスト・デバイス１６０上のソフトウェア・アプリケーションは、ＦＭチップからデータを受信し（又は任意選択として、引き抜き）、メッセージを再現するためにセグメントをデコードして、再び組み立てることになる。このようなシステムの搬送波周波数は、国によって左右される可能性があり、当業者によって選択されてもよい。

さらなる実施例において、トランスミッタ１５０は、会場１１０におけるモバイル・レシーバ１３０によって使用されるブロードキャスト・データの構造全体を、絶えず送信及び再送信している。ブロードキャスト・データ（例えば、フットボール・ゲームのラップ・タイム、天候、スコア）が変化すると、セル内の以前にブロードキャストされたデータを上書きする新しいメッセージが送信され、その結果、更新されたブロードキャスト・データを反映するために、ホスト・デバイス１６０のディスプレイ４１０が変化する。ディスプレイ４１０に表示するために、アプリケーション１７０に情報を提供するためのブロードキャスト・データが使用されている場合、ディスプレイ４１０は、本来ディスプレイを生成するために使用されるデータセット全体を再送信する必要なく、すぐに変更されることが可能である。

ホスト・デバイス１６０は、モバイル・レシーバ１３０からホスト・デバイス１６０へのブロードキャスト・データを監視することによって、ディスプレイ４１０を絶えず再生成又はリフレッシュする。トランスミッタ１５０からの一連のメッセージによっていずれかのブロードキャスト・データが変更されると、ディスプレイ４１０は、これらのメッセージがモバイル・レシーバ１３０で受信されるとすぐに更新され、ホスト・デバイス１６０に送信され、アプリケーション１７０によって処理されて表示される。これは、ブロードキャスト・データの初期化を適用するか、好み情報（例えば画面色）を表示することができる。ディスプレイ４１０に示される情報のいずれかの部分は、イベントが発生したことを示すように変更されることが可能である（例えば、警戒警報下でレースが行われるときに画面を黄色に変化させる）。例示的なアプリケーション４２０は、公開者が制御又は変更できることを望むいずれかのコンテンツが、アプリケーション・プログラミング処理の始めに定義されたテーブル内で見つけられるように、構成されてもよい。これらの特徴は、テキスト、画像、画面レイアウト、（スマート・フォンのフラッシュ光のような）ホスト・デバイスの機器、又は、ホスト・デバイス１４０のスピーカで再生されることが可能な音を含むことができる。コンテンツ及び命令は、テーブルのセル内の特定の位置に送信されて記憶されることが可能であり、アプリケーションは、これらの定義されたセル内のコンテンツ／命令を探すように書かれることが可能である。

したがって、レシーバ１３０からトランスミッタ１５０に送り返される承認信号がなくても、ホスト・デバイス１６０のディスプレイ４１０は、ブロードキャスト・データが、送信時に最初に欠落、した又は失われたとしても、完全な意図したブロードキャスト・データを最終的に完全にポピュレートするはずである。

１つの実施例において、送信されるブロードキャスト・データは、図１に示されるように、会場１１０にあるデバイスを制御するために使用されることが可能なデジタル命令も含むことができる。これは、より大きいネットワークに配線で接続されていないことが望ましいデバイスにとって特に有用である可能性がある。送信される各メッセージは、どのモバイル・レシーバ１３０に各メッセージが向けられているかを指定するアドレス情報を収めるので、モバイル・レシーバ１３０は、他のデバイスをオン又はオフにするために、並びに、ブロードキャスト・データに埋め込まれているデジタル・コマンドでこれらのデバイスを構成及び／又は制御するために、制御信号を発するように構築されることが可能である。例えば、モバイル・レシーバ１３０は、より大きい画面デバイス、又はレール式可動証明（例えばＪｕｍｂｏｔｒｏｎ（Ｒ）デバイス）のためのコントローラとして動作可能であってもよい。レーストラックでは、例えば、各電光表示板にハードワイヤ・コントローラをセットアップするのが困難な可能性がある。代わりに、システム１００は、モバイル・レシーバ１３０から大きいデバイスを制御するために使用されることが可能であり、コントローラがワイヤ接続されることは必要ではなくなることになる。

図７において、複数のモバイル・レシーバにデータ７００をブロードキャストする方法が示される。ステップ７０１において、中央サービス２００は、例えば、スポーツのスコア、イベントの最新情報、緊急情報、マルチメディア、等といったコンテンツを含むデータを、会場１１０に配置されたシステムに、例えばインターネットを介して通信する。会場１１０は、データをワイヤレスでブロードキャストするためのデータ・サーバ１４０及びトランスミッタ１５０を装備される。ステップ７０２において、トランスミッタ１５０と通信しているデータ・サーバ１４０において中央サービス２００からのデータが受信される。ステップ７０３において、データ・サーバ１４０は、モバイル・レシーバ１３０をそれぞれ有する受信者１２０にブロードキャストされることになるブロードキャスト・データをトランスミッタ１５０に通信する。ステップ７０４において、トランスミッタ１５０は、少なくとも１つのトランシーバを収め、ホスト・デバイス１６０とペアにされたモバイル・レシーバ１３０に、ブロードキャスト・データを送信する。ステップ７０５において、モバイル・レシーバ１３０は、ブロードキャスト・データを受信し、ステップ７０６において、ブロードキャスト・データを処理及び／又は表示するためのアプリケーションを動かしているホスト・デバイス１６０に、ブロードキャスト・データを送信する。ステップ７０７において、ホスト・デバイス１６０からのレスポンスは、ＴＣＰ／ＩＰネットワークなどの、ホスト・デバイス１６０が利用できるネットワークを介して、（もしあれば）システム１００に送信して戻される。１つの実施例において、この特徴は、メニュー又はカタログ項目が受信者１２０にブロードキャストされる場合に使用されてもよく、メニュー又はカタログ項目から何かをユーザが購入したいと思う場合、ユーザは、（アプリケーション１７０を介して）項目を選択し、例えば支払情報と共に、購入リクエストが、ＴＣ／ＰＩＰネットワーク（例えば、セルラー又はＷｉ－Ｆｉ）を介して、ストアに中継して戻されることが可能である。

１つの実施例において、データ・サーバ１４０は、中央サービス２００から受信したデータを選択的に送信するように動作可能である。１つのロケーションにいる全ての受信者に権限付与されたデータは、全てのモバイル・レシーバ１３０への全体的なブロードキャストのためにトランスミッタ１５０に送信されてもよい。選ばれた受信者だけのために権限付与されたデータは、受信者が、例えば必要なコードを保有又は入力する場合のみ、ホスト・デバイス１６０によって、又は、別の実施例において、一定の識別情報を有するモバイル・レシーバ１３０に対してのみ、アクセス可能であってもよい。１つの実施例において、このサービスは、中央サービス２００又はローカル・サービスによって実現されてもよい。

別の実施例において、トランスミッタ１５０は、カルーセル法を使用して、モバイル・レシーバ１３０に通信されることになるデータの構造全体を絶えずブロードキャストしている。したがって、モバイル・レシーバ１３０から送られた承認信号がなくても、ホスト・デバイス１６０のディスプレイは、データが最初に欠落した／見失われたとしても、最終的に完全にポピュレートする。

図８に移ると、緊急時又は災害状況９００での用途に適した本発明の方法及びシステムの実施例が示される。米国においてＬＴＥ又は他のブロードキャスト技術が広範囲に配置されるまで、マルチメディア・コンテンツを収めるＷＥＡマルチキャスト・メッセージは、緊急事態において一般に利用可能ではない。ＷＥＡは、一定のワイヤレス電話及び他の互換モバイル・デバイスを所有する顧客が、彼らのエリアにおける安全性への差し迫った脅威を彼らにアラートする地理的に対象にされたテキストのようなメッセージを受信することを可能にする公開安全システムである。セル・フォンは、マルチメディア・ブロードキャスト・メッセージを受信するように現在装備されていない。本発明の１つの実施例は、システムを提供し、ＷＥＡマルチキャスト・メッセージを受信することを望む受信者は、パケットで送信されたメッセージを受信して、次に、Ｂｌｕｅｔｏｏｔｈ（Ｒ）プロトコルを使用してホスト・デバイス８２０（例えば、携帯電話）にメッセージを再送信するために使用される、例えば、小型のＢｌｕｅｔｏｏｔｈ（Ｒ）が装備されたデジタル・レシーバといった、モバイル・レシーバ８１０を提供される。ホスト・デバイス８２０上で、メッセージは、必要に応じて、メッセージ・パケットをコンパイルしてテキスト、バイナリ・コマンド、又はマルチメディア・コンテンツに戻すのに必要なコーデック及びＡＰＩを収めるソフトウェア・アプリケーションによって受信されて処理される。

実例として、ハリケーンでは、政府当局（例えばＦＥＭＡ）は、最新情報、天候及びニュース警報、又は、政府関係者からの緊急警報を、地図、ビデオ、写真、等などのマルチメディア情報で受信者が受信できるように、影響を受ける地域の救急隊員又は住民にモバイル・レシーバ８１０を配布することができる。マルチメディア・メッセージは、関連する地理、地域、又は会場（例えば避難所）に配置されたモバイル又は一時的なトランスミッタからモバイル・レシーバ８１０にブロードキャストされることが可能である。受信者は、例えばＢｌｕｅｔｏｏｔｈといった、任意の利用可能な通信チャネルを介して、モバイル・レシーバ８１０とペアにされることが可能な受信者の携帯電話又は他のホスト・デバイスに、災害の前にアプリケーションをダウンロードすることができる。

図９Ａ及び図９Ｂは、本発明のシステム及び方法を通じて送信された政府の警報メッセージについての例示的な情報を示す。図９Ａは、エクステンシブル・マークアップ・ランゲージ（ＸＭＬ）を使用したコモン・アラート・プロトコル、Ｖｅｒ．１．２の規格で指定されたような緊急警報メッセージの実例であり、この規格は、緊急警報メッセージを国内的及び国際的に配布するための広く一般に採用された方法である。図９Ｂは、本発明で記述されたブロードキャスト・フォーマットに準拠して、このＸＭＬメッセージ内の情報が、テーブル・フォーマットにどのようにコンバートされ得るかを示す。

本実施例において、トランスミッタ１５０は、テーブルに記憶された、示されたデータの構造全体を絶えず送出している。事態は変化するので（例えば、「ｕｒｇｅｎｃｙ」のレベル若しくは「ｃｅｒｔａｉｎｔｙ」のレベル、又は画像ファイル若しくはＧＩＦ）、ブロードキャスト・データのメッセージは、このデータが記憶されたセル内のデータを上書きすることになる。ホスト・デバイス１６０のディスプレイ４１０は、更新された情報を反映するために変更することになる。

１つ又は複数の例示的な実施例において、記述された機能は、ハードウェア、ソフトウェア、ファームウェア、又はこれらの任意の組合せで実現されてもよい。ソフトウェアで実現される場合、機能は、コンピュータ可読媒体に記憶されても、コンピュータ可読媒体で１つ又は複数の命令又はコードとしてエンコードされてもよい。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされることが可能な任意の利用可能な媒体であってもよい。実例として、また限定ではなく、このようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ－ＲＯＭ若しくは他の光ディスク・ストレージ、磁気ディスク・ストレージ若しくは他の磁気ストレージ・デバイス、又は、命令若しくはデータ構造の形で、所望のプログラム・コードを搬送若しくは記憶するために使用されることが可能な、及び、コンピュータによってアクセスされることが可能な他の任意の媒体を含むことができる。ディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、本明細書において使用されるように、コンパクト・ディスク（ＣＤ）、レーザ・ディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、及びフロッピー・ディスクを含み、ここで、ディスク（ｄｉｓｋ）は通常、データを磁気的に再現し、一方、ディスク（ｄｉｓｃ）は、データをレーザで光学的に再現する。上記の組合せも、コンピュータ可読媒体の範囲に含まれるべきである。

図１０に移ると、フローチャートが示される。ステップ１０００において、アプリケーション１７０を動かすホスト・デバイス１６０は、会場１０１でブロードキャスト・サービスのためにファイル配信セッションをアクティブにする。ホスト・デバイス１６０は、ファイル配信セッションのトランスポート・セッションＩＤと関連付けられた、定義されたネットワーク・アドレス及びポート上でコンテンツをダウンロードし始める。ステップ１００１において、ホスト・デバイス１６０は、会場１０１でブロードキャストされたデジタル・ファイルに関連付けられた少なくとも１つの第１の媒体セグメントを受信する。ステップ１００２において、ホスト・デバイス１６０は、会場１０１でブロードキャストされたデジタル・ファイルに関連付けられた少なくとも１つの第２の媒体セグメントを受信する。１つの実施例において、この方法は、デジタル・ファイル（例えば、画像、オーディオ、及びビデオを転送するために使用される。特定の会場では、テーブルに収められた一連のセルとして、所望のデジタル・ファイルを作り出すのに必要なデジタル情報を記憶するためにテーブルが定義される。デジタル・ファイルは、（例えば、それぞれ２０オクテット～６０オクテットの間の）セグメントに分割され、次に、各セグメントは、テーブル内の異なるセルに記憶される。ホスト・デバイス１６０上で動くアプリケーション１７０は、受信した媒体セグメントの内容を評価し、元のデジタル・ファイルがユーザによってアクセス可能又は可視になるように従って、媒体セグメントを正規の順序で組み合わせる。

図１１は、例示的な装置１１００における異なる構成要素間のデータ・フローを示す概念データのフローチャートを示す。装置は、ホスト・デバイス１６０であってもよい。装置１１００は、会場でブロードキャスト・ネットワークのセッションをアクティブにするように動作可能なブロードキャスト・データ管理モジュール１１０１を含む。装置１１００は、ネットワーク１１０３からセッション中にデータ・ストリームを受信するように動作可能なブロードキャスト・データ処理モジュール１１０２をさらに含む。データ・ストリームは、少なくとも１つのカプセル化デジタル・データ・ファイル・セグメントを含み、少なくとも１つのカプセル化デジタル・データ・ファイル・セグメントは、アドレス情報に関連付けられる。装置１１００は、少なくとも１つのカプセル化デジタル・データ・ファイル・セグメントをキャッシュするように動作可能なデータ・キャッシュ・モジュール１１０４をさらに含む。装置１１００は、キャッシュされたカプセル化デジタル・データ・ファイル・セグメントも使用しながら、再生のためのデジタル・データ・ファイル・セグメントをカプセル化したマルチメディアをデコードするために使用されるコンテンツ処理モジュール１１０５をさらに含む。ブロードキャスト・データ処理モジュール１１０２は、デジタル・データ・ファイルに関連付けられた追加のカプセル化デジタル・データ・ファイル・セグメントを受信するようにさらに動作可能であってもよい。したがって、前述のフローチャートの各ステップは、モジュールによって実行されてもよく、装置１１００は、これらのモジュールの１つ又は複数を含んでもよい。

図１２は、処理システム１２０１を用いる装置１２００のための実装形態の実例を示す図である。処理システム１１２０１は、バス・アーキテクチャで実現されてもよい。処理システム１２０１は、処理システム１２０１の特定の用途、及び全体的な設計制約に応じて、任意の数の相互接続バス及びブリッジを含んでもよい。処理システム１２０１は、プロセッサ１２０２、処理モジュール１２０３、１２０４、１２０５、及び１２０６、並びにコンピュータ可読媒体１２０７によって表された、１つ又は複数のプロセッサ及び／又はハードウェア・モジュールを含む様々な回路を互いにリンクする。処理システム１２０１は、当技術分野で知られたタイミング・ソース、周辺機器、電圧調整器、及び電源管理回路などの他の様々な回路もリンクすることができる。処理システム１２０１は、トランシーバ１２０８に連結されてもよい。トランシーバ１２０８は、１つ又は複数のアンテナ１２０９に連結される。トランシーバ１２０８は、送信媒体上で他の様々な装置と通信するための手段を提供する。処理システム１２０１は、コンピュータ可読媒体１２０７に連結されたプロセッサ１２０２を含む。プロセッサ１２０２は、コンピュータ可読媒体１２０７に記憶されたソフトウェアの実行を含む全体的な処理を担う。ソフトウェアは、プロセッサ１２０２によって実行されると、任意の特定の装置のための上述の様々な機能を処理システム１２０１に実行させる。また、コンピュータ可読媒体１２０７は、ソフトウェアを実行するときにプロセッサ１２０２によって操作されるデータを記憶するために使用されてもよい。モジュール１２０３、１２０４、１２０５、及び１２０６は、コンピュータ可読媒体１２０７に常駐した／記憶された、プロセッサ１２０２で動くソフトウェア・モジュール、プロセッサ１２０２に連結された１つ若しくは複数のハードウェア・モジュール、又は、これらのいくつかの組合せであってもよい。処理システム１２０１は、ホスト・デバイス１６０及び／又はモバイル・レシーバ１３０の構成要素であってもよく、他のメモリ及びプロセッサを含んでもよい。

開示された処理におけるステップの特定の順序又は階層は、例示的なアプローチの例証であるということが理解される。設計の優先度に基づいて、処理におけるステップの特定の順序又は階層は、再配列されてもよいということが理解される。さらに、ステップの中には、組み合わされてよいもの、又は省略されてよいものもある。添付の方法の請求項は、サンプルの順序で様々なステップの要素を提示するが、提示された特定の順序又は階層に限定されることを意味するものではない。

前の記述は、本明細書で記述される様々な態様を、当業者が実践できるようにするために提供される。これらの態様への様々な変更は、当業者には容易に明らかになり、本明細書で定義された包括的な原理は、他の態様に適用されてもよい。したがって、特許請求の範囲は、本明細書で示された態様に限定されることを意図するものではなく、言葉による請求項に一致した完全な範囲に合致されることを意図するものであり、単数形での要素への参照は、そのように具体的に示されない限り「唯一（ｏｎｅａｎｄｏｎｌｙｏｎｅ）」を意味することを意図するものではなく、むしろ「１つ又は複数」である。別途具体的に示されない限り、用語「いくつか（ｓｏｍｅ）」は、１つ又は複数を指す。当業者に既知の、又は後で既知になる本開示の全体にわたって記述された様々な態様の要素に対する全ての構造上及び機能的同等物は、参照により本明細書に明確に組み込まれ、特許請求の範囲によって包含されることを意図される。さらに、本明細書において開示されたものは、このような開示が特許請求の範囲において明示的に説明されるかどうかに関わらず、公開用に捧げられることを意図されない。句「のための手段（ｍｅａｎｓｆｏｒ）」を使用して要素が明確に説明されない限り、請求項の要素は、手段プラス機能として解釈されるべきではない。

したがって、本発明は、本発明を実行するために想定された最善のモードとして開示された特定の実施例に限定されず、本発明は、添付の特許請求の範囲及び精神に含まれる全ての実施例を含むことになるということが意図される。

Claims

複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムであって、
ａ．前記マルチメディア・データを２つ以上のデジタル・データ・セグメントにセグメント化し、前記２つ以上のデジタル・データ・セグメントをヘッダ情報と共にカプセル化し、及び、前記複数のモバイル・レシーバへのブロードキャストのために、リモート・データ・サーバに前記２つ以上のデジタル・データ・セグメントを通信するように動作可能な中央サービスであって、前記ヘッダ情報が、
ｉ．会場識別子、
ｉｉ．会場における前記複数のモバイル・レシーバの全てに前記マルチメディア・データが向けられているか否かを識別する少なくとも１つのバイト、
ｉｉｉ．データ型指標、
ｉｖ．前記デジタル・データ・セグメントが連続のうちの１つであるか否かを示す連続指標、
ｖ．前記２つ以上のデジタル・データ・セグメントのそれぞれにおけるバイトの総数を示す総バイト数指標、
ｖｉ．前記２つ以上のデジタル・データ・セグメントのそれぞれが記憶されることになる位置を示すアドレス位置情報、及び、
ｖｉｉ．チェックサム
を含む、中央サービス
を含み、
ｂ．前記リモート・データ・サーバが、前記２つ以上のデジタル・データ・セグメントを受信し、前記２つ以上のデジタル・データ・セグメントをカルーセル・バッファに記憶し、及び、前記複数のモバイル・レシーバへのブロードキャストのために、前記２つ以上のデジタル・データ・セグメントをトランスミッタに繰り返し送信するように動作可能であり、
ｃ．前記トランスミッタが、前記リモート・データ・サーバから受信した前記２つ以上のデジタル・データ・セグメントを前記複数のモバイル・レシーバにブロードキャストするように動作可能であり、
ｄ．前記複数のモバイル・レシーバがそれぞれ、
ｉ．アンテナ及び一意の識別子を含み、
ｉｉ．少なくとも１つのホスト・デバイスとペアにされ、
ｉｉｉ．前記２つ以上のデジタル・データ・セグメントを前記トランスミッタから受信し、及び、前記２つ以上のデジタル・データ・セグメントを、前記少なくとも１つのペアにされたホスト・デバイスに再送信するように動作可能であり、
ｅ．各ホスト・デバイスが、ディスプレイを含み、前記２つ以上のデジタル・データ・セグメントを受信し、前記２つ以上のデジタル・データ・セグメントを前記マルチメディア・データに再フォーマットし、及び、前記マルチメディア・データを表示するように動作可能である、
システム。
前記トランスミッタを含まない代替通信ネットワークを介して、前記少なくとも１つのペアにされたホスト・デバイスから前記中央サービスへのリターン・チャネルをさらに備える、請求項１に記載のシステム。
前記代替通信ネットワークが、前記複数のモバイル・レシーバの少なくとも１つから前記中央サービスへのＴＣＰ／ＩＰ通信チャネルを含む、請求項２に記載のシステム。
前記代替通信ネットワークが、前記複数のモバイル・レシーバの前記少なくとも１つの範囲内の複数の短距離近接レシーバを含む、請求項３に記載のシステム。
前記複数のモバイル・レシーバのそれぞれに関連付けられたユーザ・プロフィールをさらに備える、請求項１に記載のシステム。
前記中央サービスが、所定の期間、前記リモート・データ・サーバへのブロードキャストのために、前記２つ以上のデジタル・データ・セグメントを再配信する、請求項１に記載のシステム。
複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストする方法であって、
ａ．中央サービスにおいて、マルチメディア・データを少なくとも２つのデジタル・データ・セグメントにセグメント化するステップと、
ｂ．前記少なくとも２つのデジタル・データ・セグメントのそれぞれをヘッダ情報と共にカプセル化するステップであって、前記ヘッダ情報が、所与のロケーションにおける前記複数のモバイル・レシーバの全てに前記マルチメディア・データが向けられているか否かを識別する少なくとも１つのバイト、データ・テーブル又はメモリ・マップのセル内のデータ位置を識別する少なくとも１つのバイト、及び、前記セルのデータを有する少なくとも１つのバイトを含む、ステップと、
ｃ．所定の期間にわたる複数のモバイル・レシーバへのブロードキャストのために、前記少なくとも２つのデジタル・データ・セグメントをリモート・データ・サーバに繰り返し送信するステップと、
ｄ．前記リモート・データ・サーバにおいて前記少なくとも２つのデジタル・データ・セグメントを受信するステップと、
ｅ．前記リモート・データ・サーバにおいて前記少なくとも２つのデジタル・データ・セグメントを記憶するステップと、
ｆ．前記複数のモバイル・レシーバへのブロードキャストのために、前記少なくとも２つのデジタル・データ・セグメントを、カルーセル・バッファを介してトランスミッタに通信するステップと、
ｇ．前記少なくとも２つのデジタル・データ・セグメントを前記複数のモバイル・レシーバにブロードキャストするステップと、
ｈ．前記複数のモバイル・レシーバの少なくとも１つによって、前記複数のモバイル・レシーバの前記少なくとも１つとペアにされたホスト・デバイスに前記少なくとも２つのデジタル・データ・セグメントを送信するステップと、
ｉ．前記ホスト・デバイスにおいて前記少なくとも２つのデジタル・データ・セグメントを受信するステップと、
ｊ．前記少なくとも２つのデジタル・データ・セグメントをキャッシュするステップと、
ｋ．前記マルチメディア・データが表示可能になるように、前記少なくとも２つのデジタル・データ・セグメントを組み立てるステップと、
ｌ．前記マルチメディア・データを前記ホスト・デバイスに表示するステップと
を含む、方法。
複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムであって、
ａ．
ｉ．マルチメディア・データをデジタル・データ・セグメントにセグメント化し、
ｉｉ．前記デジタル・データ・セグメントを第１のヘッダ情報であって、所与のロケーションにおける前記複数のモバイル・レシーバの全てに前記マルチメディア・データが向けられているか否かを識別する少なくとも１つのバイト、データ・テーブル又はメモリ・マップのセル内のデータ位置を識別する少なくとも１つのバイト、及び、前記セルのデータを有する少なくとも１つのバイトを含む第１のヘッダ情報と共にカプセル化し、及び
ｉｉｉ．複数のモバイル・レシーバへのブロードキャストのために、前記デジタル・データ・セグメントをリモート・データ・サーバに通信する
ように動作可能な中央サービスと、
ｂ．前記中央サービスから前記複数のモバイル・レシーバに前記デジタル・データ・セグメント及び第１のヘッダ情報と共にブロードキャストするために、ブロードキャスト・データであって、前記ブロードキャスト・データに関連する第２のヘッダ情報を有するブロードキャスト・データを前記リモート・データ・サーバに通信するように動作可能なリモート・サービスと
を備え、
ｃ．前記リモート・データ・サーバが、
ｉ．前記デジタル・データ・セグメント及び第１のヘッダ情報を前記中央サービスから受信し、
ｉｉ．前記ブロードキャスト・データ及び第２のヘッダ情報を前記リモート・サービスから受信し、
ｉｉｉ．前記デジタル・データ・セグメント、前記第１のヘッダ情報、前記第２のヘッダ情報、及び前記ブロードキャスト・データを記憶し、並びに
ｉｖ．前記複数のモバイル・レシーバへのブロードキャストのために、前記デジタル・データ・セグメント、前記第１のヘッダ情報、前記第２のヘッダ情報、及び前記ブロードキャスト・データをトランスミッタに、カルーセル・バッファを介して繰り返し送信する
ように動作可能であり、
ｄ．前記トランスミッタが、前記デジタル・データ・セグメント、前記第１のヘッダ情報、前記第２のヘッダ情報、及び前記ブロードキャスト・データを前記複数のモバイル・レシーバにブロードキャストするように動作可能である、
システム。
複数のモバイル・レシーバにマルチメディア・データをワイヤレスでブロードキャストするためのシステムであって、
マルチメディア・データをデジタル・データ・セグメントにセグメント化し、各デジタル・データ・セグメントをヘッダ情報と共にカプセル化し、及び複数のモバイル・レシーバへのブロードキャストのために、各デジタル・データ・セグメントをヘッダ情報と共にリモート・データ・サーバに通信するように動作可能なトランスミッタ・プログラムを動かす中央サービス
を含み、
前記ヘッダ情報が、会場識別子、デジタル・データ・セグメント・タイプ指標、モバイル・レシーバ識別子、各デジタル・データ・セグメントが連続のうちの１つであるか否かを示す連続指標、各デジタル・データ・セグメント内のバイトの総数を示す総バイト数指標、前記デジタル・データ・セグメントが記憶されることになる位置を示すアドレス位置情報、及びチェックサムを含み、
リモート・データ・サーバが、前記デジタル・データ・セグメントが前記中央サービスによって変更又は除去されるまで、トランスミッタによる連続的なブロードキャストのために、前記デジタル・データ・セグメントを受信し、及び前記デジタル・データ・セグメントをカルーセル・バッファに追加するように動作可能である、
システム。
モバイル・レシーバのデータを処理する方法であって、
第１のコンテナ及び第１のデジタル・データ・セグメントを含む第１のＦＭブロードキャスト信号を受信して復調するステップであって、前記第１のコンテナが９バイトから６０バイトまでであり、会場識別子、デジタル・データ・セグメント・タイプ指標、モバイル・レシーバ識別子、前記第１のデジタル・データ・セグメントが連続のうちの１つであることを示す連続指標、前記第１のデジタル・データ・セグメント内のバイトの総数を示す総バイト数指標、前記第１のデジタル・データ・セグメントが記憶されることになる位置を示すアドレス位置情報、及びチェックサムを含む、ステップと、
第２のコンテナ及び第２のデジタル・データ・セグメントを含む第２のＦＭブロードキャスト信号を受信して復調するステップであって、前記第２のコンテナが９バイトから６０バイトまでであり、前記会場識別子、前記デジタル・データ・セグメント・タイプ指標、前記モバイル・レシーバ識別子、前記第２のデジタル・データ・セグメントが前記連続の中の２番目であることを示す連続指標、前記第２のデジタル・データ・セグメント内のバイトの総数を示す総バイト数指標、前記第２のデジタル・データ・セグメントが記憶されることになる位置を示す第２のアドレス位置情報、及び第２のチェックサムを含む、ステップと
を含む、方法。