JP2008537822A - ロケーションベースの緊急通報 - Google Patents

Abstract

【課題】ロケーションベースの緊急通報
【解決手段】サーバからクライアントデバイスへ緊急通報を送信し受信するシステム及び方法を開示する。通報は、クライアントデバイスのロケーション及び／又は指定された時間枠に基づき送信できる。クライアントデバイス上のアナウンスメントマネージャは受信した通報を表示、格納、及び管理でき、緊急通報の内容に基づきさらなるアプリケーションを作動させることができる。
【選択図】 図３

Description

［分野］
本発明は一般的に、リモートクライアントデバイス及びサーバ間通信に関する。本発明はより具体的に、無線ネットワークを介し少なくとも１つのクライアントデバイスに向けて緊急通報を作成、送信、及び閲覧することに関する。

［背景］
技術の進歩は個人用演算処理装置の小型化と高性能化をもたらした。例えば、いずれも小さく、軽量で、ユーザーが容易く持ち運ぶことのできる携帯型無線電話機、個人用デジタル補助装置（ＰＤＡ）、及びページング装置等、無線演算処理装置を含む様々な携帯型個人用演算処理装置が現在存在する。より具体的に、例えば携帯型無線電話機はさらに、無線ネットワーク上で音声及びデータパケットを通信するセル方式電話機を含む。さらに、このようなセル方式電話機の多くは演算処理能力を比較的大幅に増大させながら製造されており、結果的に小型パーソナルコンピュータやハンドヘルド型ＰＤＡに匹敵しつつある。しかし、これらの小型化・高性能化する個人用演算装置は一般的にリソースがひどく制約されている。例えば、画面のサイズ、使用可能メモリ及びファイルシステム空間の量、入力・出力能力の量、及び処理能力はそれぞれ装置の小さいサイズによって制限されることがある。極度のリソース制約のため、例えばこのような遠隔個人用演算処理装置（クライアントデバイス）に備わるソフトウェアアプリケーションやその他情報の限られたサイズ及び量を維持することが一般的にはしばしば望まれる。

一部の個人用演算処理装置は、ランタイム環境及びソフトウェアプラットフォームと呼ばれることがあるアプリケーションプログラミングインターフェイス（ＡＰＩ）を利用しており、前記ＡＰＩはそのローカルコンピュータプラットフォームにインストールされ、例えば、デバイス固有リソースのため汎用コールを提供する等によって、このようなデバイスのオペレーションの簡素化に役立てられている。さらに、このようなＡＰＩのいくつかは、このようなデバイスで完全に実行できるソフトウェアアプリケーションを作成する能力をソフトウェア開発者に提供することで知られている。加えて、このようなＡＰＩのいくつかは、演算処理装置システムソフトウェアとソフトウェアアプリケーションとの間に位置し、これによりソフトウェア開発者が特定の演算処理装置システムソースコードを用意せずとも、ソフトウェアアプリケーションは演算処理装置の演算処理機能を利用できることが知られている。さらに、いくつかのＡＰＩは、安全な暗号情報を用いてこのような個人用デバイス（すなわちクライアント）とリモートデバイス（つまりサーバ）との安全通信機構を提供することで知られている。

カリフォルニア州サンディエゴのクアルコム社（ＱＵＡＬＣＯＭＭ，Ｉｎｃ．）によって開発されたＢｉｎａｒｙ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｗｉｒｅｌｅｓｓ（登録商標）（ＢＲＥＷ（登録商標））はこのようなＡＰＩの一例であり、このようなＡＰＩのいくつかは後ほど詳述する。ＢＲＥＷ（登録商標）のバージョンは演算処理装置（例えば無線セル方式電話機）のオペレーティングシステムと協働でき、数ある特徴の中でとりわけ、特に個人用演算処理装置に見られるハードウェア装備に対するインターフェイスを提供できる。ＢＲＥＷ（登録商標）はまた、デバイスリソース需要に比べて、そしてＢＲＥＷ（登録商標）ＡＰＩを内蔵するデバイスに消費者が支払う価格に比べて、相対的に低いコストで、これらのインターフェイスをこのような個人用演算処理装置上に提供できる。ＢＲＥＷ（登録商標）のさらなる特徴として、これのエンド・ツー・エンドソフトウェア配布プラットフォームがあり、これは無線サービス事業者とソフトウェア開発者と演算処理装置消費者とに様々な利益を提供する。現在入手可能である少なくとも１つのこのようなエンド・ツー・エンドソフトウェア配布プラットフォームは、サーバ・クライアントアーキテクチャ上で配布されるロジックを含み、ここでサーバは、例えば課金、セキュリティ、及びアプリケーション配布機能を遂行し、クライアントは、例えばアプリケーション実行、セキュリティ、及びユーザーインターフェース機能を遂行する。

無線クライアントデバイスに対する改良として、緊急事態システムにアクセスがあったときに緊急職員がクライアントデバイスの位置を特定することを可能にするシステムがある。したがって、多くの無線クライアントデバイスにロケーション判定能力が取り入れられた。例えば、連邦情報通信委員会（ＦＣＣ）によって公布された無線強化９１１（Ｅ９１１）規則は、無線９１１コールについて９１１ディスパッチャに補足情報を提供することによって無線９１１サービスの有効性と信頼性の改善を図る。

無線Ｅ９１１プログラムは２つの部分に、すなわちフェーズＩとフェーズＩＩとに分けられる。フェーズＩは、現地緊急応答地点（ＰＳＡＰ）からしかるべき要求があり次第、無線９１１コーラーの電話番号と、前記コールを受信したアンテナのロケーションとを報告することを通信事業者に義務付ける。フェーズＩＩは、ほとんどの場合は５０から１００メートル以内で、より正確なロケーション情報を提供することを無線通信事業者に義務付ける。

Ｅ９１１の展開にともない、現地９１１ ＰＳＡＰの改良と、公安当局、無線通信事業者、技術供給業者、機器製造業者、及び現地有線通信事業者間の連携とが要求された。ＦＣＣは、２００１年１０月１日に始まり２００５年１２月３１日に完了する４年間のフェーズＩＩ導入スケジュールを立てた。

従って、現在使われている多くのクライアントデバイスはすでにフェーズＩＩの所要条件に従ってロケーション情報を提供できる。現在のＥ９１１システムは緊急コールを受けるときにロケーション情報だけを提供する。しかし、現在のＥ９１１システムは緊急時に何百万もの無線デバイスユーザーを活用しない。

上記の関連技術の説明は、公知のＡＰＩ使用のいくつかを概説し、本発明の実施形態に使用できるＢＲＥＷ（登録商標）プラットフォームを案内するものとして意図されているに過ぎない。ただし本発明は、特定の実施、オペレーティングシステム、又は環境に限定されると解釈されるべきものではない。

［例示的な実施形態の概要］
本発明の例示的な実施形態は、ネットワークを介しクライアントデバイスに向けて緊急通報を作成、送信、及び閲覧するためのシステム及び方法を指向する。

本発明の少なくとも一実施形態は緊急通報を通信する無線通信システムを含み、前記無線通信システムはクライアントデバイスを備え、前記クライアントは、トランシーバと、トランシーバへ作動可能な状態で結合され目標地理領域を規定するロケーションデータを含む緊急通報を受信するよう構成されたロジックと、クライアントデバイスの地理位置が目標地理領域の中にあると判定した時点でクライアントデバイス上に緊急通報を表示するよう構成されたロジックとを備える。

本発明の別の実施形態は緊急通報を無線通信する方法を含み、前記方法は、ロケーションデータを含む緊急通報を生成することと、緊急通報の中にあるロケーションデータとクライアントデバイスのロケーションとに基づき緊急通報を受信するべきクライアントデバイスを識別することと、クライアントデバイスへ緊急通報を送信することと、クライアントデバイスにて緊急通報を受信することと、ロケーションデータによって規定される目標地理領域の中にクライアントデバイスがあると判定した時点でクライアントデバイス上に緊急通報を表示することとを備える。

本発明の別の実施形態は無線クライアントデバイスを含み、前記クライアントデバイスは、トランシーバと、ユーザーインターフェースと、ロケーションデータを含む緊急通報を受信するよう構成され、緊急通報に収容されたロケーションデータによって規定される目標地理領域の中にクライアントデバイスがあるか否かを判定するよう構成され、且つクライアントデバイスが目標地理領域の中にある場合に緊急通報の受信時にユーザーインターフェース上で通知デバイスを作動させるよう構成されたキャリアアナウンスメントマネージャ（ＣＡＭ）とを備える。

本発明の別の実施形態は、ロケーションベースの緊急通報を無線通信するコンピュータプログラムを格納するコンピュータ可読媒体を含み、前記コンピュータプログラムは、少なくとも１つの演算処理装置によって実行されるときに、地理領域を規定するロケーションデータを含む緊急通報を受信することと、クライアントデバイスの地理位置を判定することと、緊急通報の中にあるロケーションデータによって規定される地理領域の中にクライアントデバイスがあるか否かを判定することと、クライアントデバイスの地理位置が地理領域の中にあると判定した時点でクライアントデバイス上に緊急通報を表示することと、の各プロセスを演算処理装置に遂行させる命令を備える。

本発明の別の実施形態は緊急通報を無線通信するサーバを含み、前記サーバは、地理領域を規定するロケーションデータを含む緊急通報を生成する手段と、緊急通報を受信するべきクライアントデバイスを地理領域とクライアントデバイスの地理的ロケーションとに基づき識別する手段と、クライアントデバイスへ緊急通報を送信する手段とを備える。

本発明の別の実施形態は緊急通報を無線受信するクライアントデバイスを含み、前記クライアントデバイスは、地理領域を規定するロケーションデータを含む緊急通報を受信する手段と、クライアントデバイスの地理位置が地理領域の中にあると判定した時点でクライアントデバイス上に緊急通報を表示する手段とを備える。

本発明の実施形態とこれに付随する多数の利点とは、以降の詳細な説明を、専ら例証のため提示され本発明を制限するものではない添付の図面との関係で勘案しながら参照することにより、理解が深まるため、これのより万全な認識は容易く得られる。

［望ましい実施例の詳細な記載］
本発明の特定の実施形態に向けた以降の説明と関係図面にて本発明の態様を開示する。本発明の範囲から逸脱せずに代替の実施形態を考案できる。加えて、関連性のある本発明の詳細が曖昧にならないようにするため、本発明の周知の構成要素は詳しく説明されないか、又は省かれる。

本明細書で用いる単語「例示的」（ｅｘｅｍｐｌａｒｙ）は、「例、事例、又は例証として役立つ」を意味する。本明細書で「例示的」（ｅｘｅｍｐｌａｒｙ）であるものとして説明する実施形態は必ずしも、他の実施形態より好ましいもの、又は有利なもの、と解釈されるべきものではない。同様に、用語「本発明の実施形態」は、論述される特徴、利点、又は動作モードが本発明の全ての実施形態に盛り込まれることを要求するものではない。

さらに、多くの実施形態は、例えば演算処理装置の構成要素によって遂行される、一連のアクションとして説明されている。本明細書で説明する種々のアクションを、特定の回路（例えば特定用途向け集積回路（ＡＳＩＣ））によって、１つ以上のプロセッサによって実行されるプログラム命令によって、又は両方の組み合わせによって、遂行できることは認識される。加えて、本明細書で説明するこれらの一連のアクションは、対応する１組のコンピュータ命令を格納する何らかの形をとるコンピュータ可読格納媒体の中で全面的に具現されるものとみなすことができ、前記１組のコンピュータ命令は、実行に際し、本明細書で説明する機能を関連プロセッサに遂行させる。よって、本発明の様々な態様は、請求される題材の範囲内で構想された数々の異なる形態で具現できる。加えて、本明細書で説明する実施形態の各々につき、このような実施形態の対応する形態を、例えば記載されたアクションを遂行「するよう構成されたロジック」として、本明細書で説明する場合がある。

本発明の１つ以上の実施形態は、演算処理装置上で実行するランタイム環境（例えばＡＰＩ）と併せて使用できる。上述したＢｉｎａｒｙ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｗｉｒｅｌｅｓｓ（登録商標）（ＢＲＥＷ（登録商標））ソフトウェアはこのようなランタイム環境のひとつである。しかし本発明の１つ以上の実施形態は、例えば無線クライアント演算処理装置上でアプリケーションの実行を制御するよう作動する別種のランタイム環境（ＡＰＩ）とともに使用できる。

図１は、本発明の少なくとも一実施形態による無線システム１００の一例示的な実施形態のブロック図を示す。システム１００は、無線ネットワーク１０４を介して少なくとも１つのアプリケーションダウンロードサーバ１０６と通信するセル方式電話機１０２等のクライアントデバイスを含むことができ、前記アプリケーションダウンロードサーバは、無線通信ポータルか、又は無線ネットワーク１０４に至る他のデータアクセスを介して無線デバイスへソフトウェアアプリケーション及びコンポーネントを選択的に送信する。ここに示すように、無線（クライアント）デバイスは、セル方式電話機１０２、個人用デジタル補助装置１０８、ここで双方向テキストページャとして図示されているページャ１１０であってもよく、あるいは無線通信ポータルを有する別個のコンピュータプラットフォーム１１２であってもよい。よって本発明の実施形態は、無線モデム、ＰＣＭＣＩＡカード、パーソナルコンピュータ、アクセス端末、電話機、又はこれらの任意の組み合わせ又は副組み合わせを無制限に含む、無線通信ポータルを含むいかなる形態のクライアントデバイスにおいても実現できる。

アプリケーションダウンロードサーバ１０６はここで、無線ネットワーク１０４と通信する他のコンピュータ構成要素とともにネットワーク１１６上に図示されている。そこには独立型サーバ１２２があってもよく、各サーバは無線ネットワーク１０４を介してクライアントデバイス１０２、１０８、１１０、１１２へ別々のサービス及びプロセスを提供できる。そこにはまた好ましくは１つの格納アプリケーションデータベース１１８があり、前記格納アプリケーションデータベースは、無線デバイス１０２、１０８、１１０、１１２からダウンロードできるソフトウェアアプリケーションを保持する。しかし、当業者は、図１に図示された構成が例示的であるに過ぎないことを認める。したがって、本発明の実施形態は、説明する機能の全てをそれぞれ遂行でき、且つ必要全ハードウェア及びソフトウェアを収容でき、又は選択された機能だけを収容できる、１つ以上のサーバを含み得る。

図２には、無線ネットワーク１０４のコンポーネントと本発明の例示的な実施形態の構成要素の相互関係とを含む、システム１００をより詳しく図示するブロック図が示されている。システム１００は例示的であるに過ぎず、無線クライアント演算処理装置１０２、１０８、１１０、１１２等のリモートクライアントデバイスが相互に、及び／又は無線ネットワーク通信事業者及び／又はサーバを無制限に含む無線ネットワーク１０４を介して接続されるコンポーネントとの間で、無線で通信することを可能にするシステムなら何であれ含み得る。アプリケーションダウンロードサーバ１０６と格納アプリケーションデータベース１１８は、セル方式通信サービスを提供するために使われる通報発送サーバ１３０等、他の何らかのサーバとともに、インターネット、セキュアＬＡＮ、ＷＡＮ、又はその他ネットワーク等のデータリンクを通じて通信事業者ネットワーク２００と通信する。図示される実施形態において、サーバ１２０はアプリケーションダウンロードサーバ１０６、通報発送サーバ１３０及び格納アプリケーションデータベース１１８を含むことができる。しかし、これらのサーバは独立したデバイスであってもよい。通報発送サーバ１３０は、クライアントデバイス１０２、１０８、１１０、１１２の各々の構成に基づきさらなる通報サービスを提供できる。

通信事業者ネットワーク２００は、メッセージングサービスコントローラ（「ＭＳＣ」）２０２へ送信される（典型的にはデータパケットとして送信される）メッセージを制御する。通信事業者ネットワーク２００は、ネットワーク、インターネット、及び／又は公衆交換電話網（ＰＳＴＮ）によってＭＳＣ ２０２と通信する。典型的に、通信事業者ネットワーク２００とＭＳＣ ２０２との間のネットワーク又はインターネット接続はデータを転送し、ＰＳＴＮは音声情報を転送する。ＭＳＣ ２０２は複数の基地局（「ＢＴＳ」）２０４へ接続できる。通信事業者ネットワークと同様、ＭＳＣ ２０２は典型的には、データ転送及び／又は音声情報のためネットワーク、インターネット、及び／又はＰＳＴＮによってＢＴＳ ２０４へ接続する。ＢＴＳ ２０４は、ショートメッセージングサービス（「ＳＭＳ」）、又は当分野で公知の他のオーバー・ザ・エア（ＯＴＡ）法により、データメッセージをセル方式電話機１０２等のクライアントデバイスへ無線でブロードキャストできる。以降の説明では、クライアントデバイス上に常駐するアプリケーションを起動するためのコードを含むＯＴＡメッセージを示すため用語ＡＰＩ指向、指向、及びＢＲＥＷ指向ＳＭＳを互換的に使用する。

セル方式電話機１０２等のクライアントデバイス（ここでは無線クライアント演算処理装置）は、アプリケーションダウンロードサーバ１０６、通報発送サーバ１３０、及び／又はサーバ１２０から送信されたソフトウェアアプリケーション及び／又はコマンドを受信でき、実行できるコンピュータプラットフォーム２０６を有する。コンピュータプラットフォーム２０６は、特定用途向け集積回路（「ＡＳＩＣ」２０８）、又はその他プロセッサ、マイクロプロセッサ、論理回路、又はその他データ処理デバイスを含み得る。ＡＳＩＣ ２０８又はその他プロセッサは、無線デバイスのメモリ２１２の常駐プログラムと連動するアプリケーションプログラミングインターフェイス（「ＡＰＩ」）２１０層を実行する。メモリ２１２は、読み取り専用又はランダムアクセスメモリ（ＲＡＭ及びＲＯＭ）、ＥＥＰＲＯＭ、フラッシュカード、又はコンピュータプラットフォームにとって一般的な何らかのメモリで構成できる。ＡＰＩ ２１０はまた、キャリアアナウンスメントマネージャモジュール（ＣＡＭ）３１０を含み、前記キャリアアナウンスメントマネージャは、通信事業者ネットワーク２００から送信される特別なＯＴＡ（例えばＳＭＳ）通報を処理するよう構成されたロジックを含む。コンピュータプラットフォーム２０６はまた、メモリ２１２にて活発に使われていないアプリケーションを保持できるローカルデータベース２１４を含む。ローカルデータベース２１４は典型的にはフラッシュメモリセルであり、ただし磁気媒体、ＥＥＰＲＯＭ、光学媒体、テープ、ソフト又はハードディスク等、当分野で公知の何らかの二次格納デバイスであってもよい。

セル方式電話機１０２等の無線クライアント演算処理装置は、ゲーム、ニュース、ストックモニター等、１つ以上のソフトウェアアプリケーションを、これにインストールし、さもなければダウンロードし、有する。例えばセル方式電話機１０２は、アプリケーションダウンロードサーバ１０６からダウンロードされた１つ以上のソフトウェアアプリケーションを受信できる。ソフトウェアアプリケーションは、使用されていないときにローカルデータベース２１４に格納できる。セル方式電話機１０２をはじめとする無線演算処理装置は、ローカルデータベース２１４に格納された常駐アプリケーションを、ＡＰＩ ２１０上での実行のため、これをユーザーが望むときに、又は別のＡＰＩが呼び出すときに、メモリ２１２へアップロードできる。

本明細書で使われている「クライアントデバイス」、「無線デバイス」、又は「クライアント演算処理装置」は、例えば常駐する構成されたロジックを実行する１つ以上の処理回路を含み、ここでこのような演算処理装置は、例えばマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、マイクロコントローラ、携帯型無線電話機、個人用デジタル補助装置（ＰＤＡ）、及びページング装置、又はクライアントデバイスとサーバとの間で伝達される緊急通報に向けて本明細書で説明するオペレーションを少なくとも実行するよう構成されたプロセッサ及びロジックを含むハードウェア、ソフトウェア、及び／又はファームウェアの何らかの適切な組み合わせを、含む。クライアント演算処理装置は、少なくともこのような緊急通報に関して、少なくとも１つのリモートサーバによって応対できる。本発明の実施形態に従い使用できる「無線デバイス」のいくつかの例として、セル方式電話機又はその他無線通信ユニット、ＰＤＡ、ページング装置、ナビゲーション装置（例えばＧＰＳに基づく装置）、ハンドヘルド型ゲーム装置、音楽又は映像コンテンツダウンロードユニット、及び他の同類の無線通信装置がある。

クライアントデバイス１０２とＢＴＳ ２０４との間の無線通信は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、移動通信用グローバルシステム（ＧＳＭ）、又は無線通信ネットワーク又はデータ通信ネットワークの中で使用できるその他プロトコル等、様々な技術に基礎を置くことができる。典型的に、クライアントデバイス１０２、ＢＴＳ ２０４、及びＭＳＣ ２０２間はデータ通信である。ＭＳＣ ２０２は、通信事業者ネットワーク２００、ＰＳＴＮ、インターネット、仮想プライベートネットワーク等、複数のデータネットワークへ接続でき、従ってより広範な通信ネットワークへのアクセスをクライアントデバイスに許す。上述したように、クライアントデバイスには、音声送信に加えて、ＳＭＳか又は当分野で公知の他のＯＴＡ法により、データを送信できる。簡便を図るため、説明の中では大抵、用語ＳＭＳを使用する。ただし上で指摘したように、本発明はＳＭＳに限定されない。

しかし、本発明の実施形態は、基礎的メッセージを配信することに加え、クライアントデバイスの強化機能へアクセスするためＡＰＩを利用することができる。さらに、基礎的ＡＰＩへのアクセスを可能にするこれらのＡＰＩ指向ＳＭＳメッセージは従来のＳＭＳメッセージから分けることができ、関係する強化ＳＭＳメッセージの整理、格納、回収を容易にするため別個の受信箱の中に格納できる。したがって、本発明の実施形態の一態様は、これ以降キャリアアナウンスメントマネージャ（ＣＡＭ）と呼ぶ、これらの強化ＳＭＳメッセージを管理する専用ＡＰＩを含む。

図３には、キャリアアナウンスメントマネージャ（ＣＡＭ）アーキテクチャとのシステム相互作用の一例が図示されている。ＣＡＭ ３１０はクライアントデバイス３００の中にインストールできる。本発明の少なくとも一実施形態において、（例えば通信事業者ネットワーク上に常駐する）サーバ１２０は、ショートメッセージサービスセンター（ＳＭＳＣ）及び通報発送サーバとして働くことができる。しかしＳＭＳＣと通報発送サーバは、通信事業者ネットワークへ作動可能な状態で結合される独立したデバイス及び／又はネットワーク上に常駐することもできる。サーバ１２０は、様々な手法を用いてＣＡＭ ３１０へ緊急通報を送信できる。例えばサーバ１２０は、クライアントデバイス３００上にあらかじめ存在する規定ＨＴＭＬテンプレートの中に挿入すべきデータを含むＡＰＩ指向ＳＭＳメッセージを送信できる。通報はその後、エンドユーザーからの働きかけをともなわず、クライアントデバイスのユーザーインターフェース／ディスプレイ３１２上に出現できる。したがって、ＣＡＭ ３１０は、ＳＭＳメッセージの中で送信される限りあるデータだけを使用しながら、魅力的且つ有益な通報としてクライアントデバイス３００上に通報を表示３３６できる。ＳＭＳメッセージテキストは、テキスト、ＵＲＬ、又は両方であってもよい。例えばＳＭＳメッセージ３３０は、テキストと、さらなる情報のため特定サイトへの接続をクライアントデバイス３００のユーザーに許す関連ＵＲＬとを収容できる。

別の例でサーバ１２０は、サーバ１２０（通報発送サーバ１３０又はその他リモートサーバ）へのコールバックを実行するため、ＵＲＬを含むＡＰＩ指向ＳＭＳメッセージ３３０を送信できる。例えばＣＡＭ ３１０は、サーバ１２０への接続３３２を開始して関連ＨＴＭＬページ（例えば交通事故を示す地図）３３４をクライアントデバイス３００へダウンロードするため、このメッセージを受信でき、該当するＡＰＩ（例えばブラウザ）をコールできる。ＨＴＭＬページがダウンロードされた後には、クライアントデバイス３００のディスプレイ３１２にページを表示できる。この実施形態におけるＨＴＭＬコールバックは、簡素なＳＭＳテキストのみ通報の代わりに、サーバに格納されたグラフィック通報をクライアントデバイス３００のメイン画面に置くことを可能にする。このＡＰＩ指向ＳＭＳメッセージ形式は通報ダウンロードリクエスト（ＡＤＲ）と呼ぶことができる。純粋なＳＭＳ法と違ってＡＤＲは、それ自体に表示データを収容しない。代わりに、これのペイロードはサーバ１２０又はその他リモートサーバ上にある通報を指し示すＵＲＬである。ＣＡＭ ３１０は、ＡＤＲによって与えられたＵＲＬから通報をダウンロードし、あらかじめ定められたルールセットに従ってこれを提示できる。サーバ１２０には各種クライアントデバイス（例えば、特定の送受話機、ＰＤＡ、ランタイム環境等）につき別個のＨＴＭＬ通報をキャッシュでき、あるいはサーバ１２０は、ＨＴＭＬ通報を即座に構築してクライアントデバイス３００の能力に合わせて通報を調整するアプリケーションを有することができる。

柔軟性を向上させるため、通信事業者は、ダウンロード時間とネットワーク負荷と格納空間とを最小限に抑えるダイレクトＡＰＩ指向ＳＭＳ通報と、品質がより高く、より恵まれた環境を備え、ただしダウンロード時間はより長く、ネットワーク負荷を増大させるＨＴＭＬコールバック通報とのいずれかを選ぶことができる。

ＣＡＭ受信箱は、通報を格納し一連のスクロールするオンライン見出しとしてこれを提示するために使用することができる。通報そのもので分かりやすい見出しを規定することができる。例えば、デフォルトの見出しはＳＭＳペイロードの最初の数文字であってもよい。エンドユーザーは、通常のクライアントデバイス上にある上／下矢印キーを、又はその他のナビゲーションキーを、使用して通報から通報にかけて移動できる。ＣＡＭ受信箱の最初のアクセスに際しては、ＣＡＭ受信箱から退出することを、又は通報を管理することを、ユーザーに許す２つのソフトキー（例えば「退出」と「管理」）を提示できる。例えば管理が選択される場合には、選択された見出しのため、「開く」と「削除」等、２つのソフトキーを提示できる。「二枚貝」スタイルの電話機の外部画面に見出しを提示することもできる。しかし、これらの例は専ら例証の目的で提示されており、本発明は特定のメニュー構造、ラベル、又は機能的関係に限定されない。当業者は、数多くの代替メニュー構造、キーの組み合わせ、及びラベルを使用できることを認めるであろう。

通報を閲覧し、これに働きかける見込みを高めるため、一実施形態において通報は最初の提示／通知の際に削除できず、必ずＣＡＭ受信箱へ送られる。通報は、ＣＡＭ受信箱画面から削除でき、又はＣＡＭ受信箱の平常メンテナンスのときに削除できる。加えて、ユーザーによって、又は通報の送信者によって、通報にロックをかけることにより、通報のロックが解除されるまでは重要緊急メッセージの削除を防ぐことができる。エンドユーザーが緊急通報を閲覧する見込みをさらに高めるため、ＣＡＭは、緊急通報の受信時に呼び出し音、ブザー、バイブレータ、ライト、又はクライアントデバイス上のその他通知デバイスを作動させることができる。

本発明の少なくとも一実施形態で、ＣＡＭは、クアルコム社のＢＲＥＷ（登録商標）（Ｂｉｎａｒｙ Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｗｉｒｅｌｅｓｓ）に対応する無線電話機等の、クライアントデバイスにプレインストールできる。しかし、他のＡＰＩ及びデバイスを使用でき、本発明は特定のプラットフォーム又はデバイスに限定されない。加えて、ＣＡＭシステムは通信事業者を通じてクライアントデバイスへ任意にプッシュでき、あるいはエンドユーザーが自発的にＣＡＭシステムをダウンロードできる。ＣＡＭシステムがインストールされたデバイスは、本明細書で説明するように通報を受信でき、エンドユーザーにこれを提示できる。

本発明は特定のデバイスに限定されないが、ＣＡＭがインストールされているデバイスのタイプを知ることは、通報の効果的な提示に役立つ。例えば、どれくらい多くの情報を表示できるか、そして情報の内容をどれくらい充実させることができるかは、画面サイズ、入力デバイス、メモリ、常駐ＡＰＩ等、デバイス固有の装備によって決まる。通常、より大きい画面のデバイスは、画像やその他のグラフィックを任意に含む、より豊かな通報を可能にする。特定の用途に基づき、例えば最低デバイス画面サイズを、メッセージタイプの基礎として選ぶことができる。

緊急通報は、デバイスによるメッセージの受信を可能にする様々なプッシュ機構を用いてクライアントデバイスへ送信できる。本発明の一例示的な実施形態においてはＡＰＩ指向ＳＭＳをプッシュ機構として使用できる。例えばＢＲＥＷ指向ＳＭＳは、ＢＲＥＷアプリケーションのクラスＩＤと、アプリケーションがＳＭＳを受信するときに回収できるデータとを含み得る。ＳＭＳの中で送信されるデータは、通報ページに表示されるテキストと、アプリケーションのＩＤとを収容でき、前記ＩＤは、例えば緊急情報にアクセスできるページまでエンドユーザーを導くために使われる。

本発明の別の例示的な実施形態では、サーバへのネットワーク接続をプッシュ機構として使用できる。この実施形態におけるＣＡＭアプリケーションは、新しい通報の有無をチェックするため、定期的に（例えば５分毎に）、又は手動で起動されるときに、サーバへ自動的に接続できる。この実施形態は、通報が入手可能であるときに、グラフィック、テキスト、ハイパーリンク、マルチメディア等を盛り込むことができるより豊かな通報の直接的ダウンロードを可能にする。

本発明の別の例示的な実施形態においては、ＡＰＩ指向ＳＭＳとネットワーク接続の両方をプッシュ機構として使用できる。ＳＭＳトリガ（例えば、ＣＡＭを作動させ、所望のリモートサーバロケーションを指し示すＵＲＬを含む指向ＳＭＳメッセージ）は、覚醒しサーバへ接続することをアプリケーションに指示する。そしてアプリケーションはサーバへ接続し、テキスト、写真、及びアプリケーションＩＤ等、詳細通報データを回収する。

例えば、ＢＲＥＷ（登録商標）対応デバイスでアプリケーションをコールする典型的フォーマットは／／ＢＲＥＷ：＜ＡＰＰ ＩＤ＞：＜Ｐａｙｌｏａｄ＞である。このＡｐｐ ＩＤはＢＲＥＷ（登録商標）アプリケーションを識別する一意な数字である。Ｐａｙｌｏａｄは、コールされるアプリケーションのためのデータである。したがって、本発明の少なくとも一実施形態はＣＡＭ固有のコール（Ａｐｐ ＩＤ）とペイロードとを含み得る。例えば、アンバーアラートのＣＡＭ対応デバイスのユーザーに対するシステム通知は、「／／ＢＲＥＷ：＜ＣＡＭ ＩＤ＞：［Ｘ］［Ｙ］［Ｒ］［Ｐｏｐｕｐ Ｔｅｘｔ］［Ｓｅｃｕｒｅ ＵＲＬ］」等のフォーマットを含むことができ、ここで「［］及び「」」は区切り文字であり、Ｘ及びＹは注目する円の中心を規定し、Ｒは注目する円の半径であり、Ｐｏｐｕｐ Ｔｅｘｔはユーザーに見せるメッセージ（例えば「新しいアンバーアラート。詳細を見るにはＹＥＳをクリックしてください」）であり、Ｓｅｃｕｒｅ ＵＲＬはクライアントデバイスがアンバーアラートに関する情報（例えば誘拐被害者の写真、不審な自動車の記述、ナンバープレート、その他）を回収するため接続できるセキュアＵＲＬ（例えば「ｈｔｔｐｓ：／／ａｍｂｅｒ．ｃａｒｒｉｅｒ．ｃｏｍ／２００４／１２／０９／ｘｙｚ」）である。したがって、フォーマット／／ＢＲＥＷ：０１００９ＦＦＯ：［１３４］［４５６］［７８９］［「新しいアンバーアラート。詳細を見るにはＹＥＳをクリックしてください」］［「ｈｔｔｐｓ：／／ａｍｂｅｒ．ｃａｒｒｉｅｒ．ｃｏｍ／２００４／１２／０９／ｘｙｚ」］にて緊急通報の一例を提示できる。当業者は、他の緊急通報構成を使用できること、そして注目地理領域を規定するため様々なタイプのデータを使用できることを認める。例えば、緊急通報の失効日付／時刻を伝える日付／時刻情報、通報の配信を追跡するための通報ＩＤ、そして本明細書で論述するＣＡＭシステムの装備を作動させるさらなるコードをペイロードに収容できる。さらに、ロケーション情報は目標領域を定める情報であればどのようなタイプであってもよく、緯度及び経度座標に限定されない。

図４はＣＡＭ受信箱４００の例示的図である。ＣＡＭシステムは、ＳＭＳ受信箱に類似する受信箱の中へ通報を送ることができる。図４は、受信箱インターフェイスに出現できる選択肢（例えば４３２）のメニューの一例を図示する。エンドユーザーはここで、メニューオプションの内１つをクリックすることにより選択された通報を表示できる。例えば図４で、ユーザーは「アンバーアラート」４３２をクリックすることにより同メニュー項目に関係する通報を見ることができる。加えて、ＣＡＭ受信箱メニューから退出するため、そしてこれの管理へアクセスするため、それぞれソフトキー４２２及び４２４が設けられる。ただし本発明は、論述する特定の構成とソフトキー機能とに限定されない。当業者によって認められるように、他のソフトキー機能（例えばロック、削除等）及びメニューレイアウトを容易く構成できる。

本発明の別の例示的な実施形態においては、時間及びロケーションベースの緊急通報を提供するため前述したＣＡＭシステムの装備を活用できる。例えば、エンドユーザーのロケーション及び／又はイベントの時間に基づきエンドユーザーへ緊急メッセージを送信するため、ＣＡＭシステムを利用できる。したがって、緊急通報を受信する、又はこれを表示する、クライアントデバイスがどれなのかを判定するため、クライアントデバイスのロケーションを利用できる。ロケーションベースの通報装備の使用により、ネットワークトラフィックは最小限に抑えることができ、最も妥当な対象者に向けて通報を配信でき、これは緊急通報の有効性を高める。

上述したＥ９１１装備等、無線クライアントデバイスには位置特定能力がますます導入されている。加えて、デバイスの世代が新しくなるたびに位置特定装備の精度は向上している。ネットワークベースのロケーション情報、クライアントベースのロケーション情報、及びハイブリッドロケーション情報等、無線位置特定情報を提供する様々なシステムが知られている。ネットワークベースのソリューションは、クライアントデバイスから送信され多数の固定基地局にて受信される信号に依拠しており、位置の判定にあたっては到来角（ＡＯＡ）と到来時刻（ＴＯＡ）とを使用する。クライアントベースのソリューションは、全地球測位システム（ＧＰＳ）を、すなわち２４時間衛星とその地上局とからなる全世界システムを、利用する。４つ以上の衛星からの距離を正確に測定することにより、受信器は自身の位置を地球上のどこであれ入手できる。クアルコム社のｇｐｓＯｎｅ（登録商標）をはじめとするハイブリッドソリューションは、ネットワークベースのソリューションとＧＰＳソリューションを組み合わせたものを提供する。例えば、農村地域や郊外地域にあって送受話機から信号を受信できる基地局は多くはないが、ＧＰＳ受信器ならしばしば４つ以上の衛星からデータを受信できる。逆に、密集した都市地域や建物の中にあってＧＰＳ受信器は十分な数の衛星を検出できないことがあるが、無線送受話機なら２つ以上の基地局と交信できる。

無線クライアントデバイスのロケーション判定に用いる技術にかかわりなく、ロケーション情報は、典型的にはロケーション位置データにアクセスするよう設計されたＡＰＩによって、アクセスできる。したがって、ＡＰＩ指向ＳＭＳ通報は、クライアントデバイスのロケーションを判定するためクライアントデバイスにてロケーションＡＰＩ（又はその他のロケーションアプリケーション）を起動できる。あるいは代わりに、あらかじめサーバに格納されたデータからクライアントデバイスのロケーションを判定できる。

通報送信者は通信事業者であってもよく、又はネットワークアクセスを備える信頼機関（例えば、警察、ＦＥＭＡ、公安役員、ＰＳＡＰ、政府機関、指定民間機関等）であってもよい。送信者は、クライアントデバイスのロケーション及び／又はイベントの時間に基づいて目標となる対象者を判定できる。例えば送信者は、所望の対象者のため緯度と経度と半径とを指定できる。したがって、送信者によって指定されるロケーション範囲の中にあるアクティブなクライアントデバイスはどれも通報を受信できる。例えば、誘拐現場の５マイル半径の中にあるアクティブクライアントはどれも、誘拐犯の逮捕に役立つ情報（例えば、被害者の記述、免許証番号等）を記述する通報を受信できるであろう。さらなる精緻化として、緊急通報をロケーションによって限定するとともに、特定の時間枠の中だけで（例えば悪天候のときに特定の郡へ）これを送信することができる。代わりに、特定の陸上目印及び／又は直接隣接区域によってロケーションを識別できる。例えば、ワシントンＤＣにあるナショナルモールを指定し、ナショナルモール区域の中にある全てのクライアントデバイスに緊急通報を受信させることができるであろう。

加えて、通報の機能をさらに高めるため、受信されＣＡＭ受信箱に格納された後に通報をロケーション・時間感応性にできる。例えば、クライアントデバイスが指定したロケーションパラメータの中から外れた（例えば、エンドユーザーが事故区域を通り過ぎた）時点で、ＣＡＭ受信箱から自動的に通報を削除できる。さらに、時間的条件に基づき通報を自動的に削除できる。例えば、所定の時間に通報を自動的に削除できる（例えば、悪天候警報を深夜に終わらせる）。関連性のない通報を自動的に削除することにより、ＣＡＭ受信箱のメンテナンスを減らすことができ、関連性のある緊急通報だけがここに格納されるよう徹底できる。

図５Ａは、本発明の少なくとも一実施形態に従い送信者が緊急通報の配信にあたって使用できるシステムのブロック図である。クライアントデバイス３００は、上述したようにＣＡＭシステム３１０に作動可能な状態で結合されたユーザーインターフェース３１２（例えば、キーパッド、ボタン、スピーカー、表示灯、ディスプレイ等）を含み得る。通報生成システム５２０は、送信者がシステム５２０へアクセスしてロケーションベースのデータ（例えば、特定の経度、緯度、及び半径）を含む通報を生成することを可能にするＣＡＭコンソール５２２を含み得る。ＣＡＭコンソールは、通信事業者ネットワークにあってもよく、又は遠隔地の信頼できる送信者（例えば、９１１コールセンター、現地警察、ＦＢＩ、ＦＥＭＡ等）にあってもよい。任意に、ＣＡＭコンソール５２２と通報発送サーバ１３０との間にアクセスゲートウェイ５２４を結合できる。アクセスゲートウェイ５２４は、暗号化及び／又は当分野で公知のその他手法を用いてＣＡＭコンソール５２２と通報発送サーバ１３０との間で安全な通信を提供するよう構成できる。さらにＣＡＭコンソールは、インターネット、ＶＰＮ、ＰＳＴＮ、無線リンク等を介してアクセスゲートウェイへ結合できる。

代わりに、ＣＡＭコンソール５２２が通信事業者ネットワークにある場合には、通報生成システム５２０を１つのコンピュータベースのシステムにまとめることができ、前記コンピュータベースのシステムは、ＣＡＭコンソールと通報発送サーバの機能を含み得る。さらに、ショートメッセージサービスセンター（ＳＭＳＣ）５２８を通報生成システム５２０の一部としてもよく、クライアントデバイス３００へ指向ＳＭＳメッセージを送信するために使用することができる。しかし他のＯＴＡデータ送信手法を使用でき、本発明の全ての実施形態でＳＭＳＣ ５２８が要求されるわけではない。

図５Ｂを参照し、本発明の代替実施形態が図示されており、ここでＣＡＭコンソール５４０は、少なくとも１つの追加の通報発送サーバへ作動可能な状態で結合される。さらに、図示されたように、各々の通報発送サーバ（図示せず）は２つの異なる通信事業者ネットワーク５５０、５６０へ結合されるか、又はこれの中に収容される。図５Ｂの構成は、１つの共通ＣＡＭコンソールが異なる通信事業者ネットワーク５５０、５６０へアクセスし、最終的には各ネットワークと通信する、異なるクライアントデバイス５５２、５６２へアクセスすることを可能にする。この特徴により、集中ＣＡＭコンソール５４０は複数の通信事業者ネットワーク（例えば５５０、５６０）上に存在する複数のクライアントデバイス（例えば５５２、５６２）へアクセスでき、これは複数の通信事業者への緊急通報伝播を簡素化し、所望クライアントデバイスへの配信を増大させることができる。例えばアンバーアラートのときに、第一の通信事業者５５０と通信するクライアントデバイス５５２と第二の通信事業者５６０と通信するクライアントデバイス５６２とは同じ目標領域内にあるかもしれない。したがって、ＣＡＭコンソール５４０にてしかるべきアンバーアラート緊急通報を生成し、第一の通信事業者ネットワーク５５０と第二の通信事業者ネットワーク５６０とへこれを送信すれば、緊急通報を受信するクライアントデバイスの数を大幅に増やすことができる。通報発送サーバとクライアントデバイスとに対する不正アクセスの見込みを制限するため、セキュアリンク５５４、５６４によって通信事業者ネットワーク５５０、５６０をＣＡＭコンソール５４０へ接続できる。したがって、リンク５５４、５６４は当分野で公知のセキュア伝送機能を使用し、インターネット、仮想プライベートネットワーク（ＶＰＮ）、公衆交換電話網（ＰＳＴＮ）、及び／又は無線リンクを介する接続であってもよい。同様に、当業者は２つ以上のＣＡＭコンソール（例えば、警察ＣＡＭコンソール、交通ＣＡＭコンソール等）を通信事業者ネットワークへ接続できることを認める。

クライアントデバイスのロケーションは、例えばクライアントデバイスにて収容されるデータ、通信事業者にて収容されるデータ、及び／又は通信事業者又はその他リモートサーバへ伝達されるロケーションデータに基づき、判定できる。例えば図５Ａで、クライアントデバイス３００は外部ロケーションシステム５３０へアクセスできる。具体的に、ＣＡＭ ３１０は可視ＧＰＳ衛星５３２から位置データを取得でき、受信した位置データは位置判定体（ＰＤＥ）へ、例えば通信事業者ネットワーク内のサーバへ、中継できる。そしてＰＤＥ ５３４は位置データを解析でき、クライアントデバイス３００のロケーションを判定できる。クライアントデバイス３００のロケーション（例えば、経度及び緯度座標、そして任意に高度座標）はその後リモートサーバにて格納でき、及び／又はＣＡＭ３１０による格納及び／又は使用のためクライアントデバイス３００へ伝達できる。例えばＣＡＭ ３１０は、緊急通報の中にあるロケーションデータによって規定される指定地理領域内にクライアントデバイス３００があるか否かを判定するため、経度及び緯度座標を、そして任意に高度座標を、使用できる。

代わりに、デバイスロケーションはクライアントデバイス３００にて判定でき、外部サーバはクライアントデバイスの具体的ロケーションを知る必要はなく、これによりエンドユーザーのプライバシーを向上させることができる。例えば、公知の手法を使用し可視ＧＰＳ衛星５３２から直にクライアントデバイス３００のロケーションを判定できる。この実施形態においては、ロケーションデータ又は関係情報を、さらなる処理のため、リモートサーバへ送信する必要はない。したがって、クライアントデバイスは、緊急通報の中で送信されるロケーション情報によって規定される目標地理領域の中にあるか否かを判定するため、緊急通報に関連するロケーション情報を役立てることができる。クライアントデバイスが目標領域内にないと判定する場合には、エンドユーザーを邪魔せず緊急通報を破棄できる。

代わりに、本発明の別の実施形態においては、地理領域の規定に役立つロケーション情報を緊急通報に含めることができる。目標領域（すなわち規定地理領域）の中にあるクライアントデバイスは、通信事業者ネットワーク内のサーバに格納されたロケーション情報から識別できる。例えばＣＡＭ対応クライアントデバイスは、クライアントデバイスのロケーションを計算できるリモートサーバへロケーションデータを提供するため、クライアントデバイスのロケーションを定期的に報告でき、又はアプリケーションを実行できる。格納されるロケーション情報は、例えば各クライアントデバイスの経度及び緯度座標を含む、表であってもよい。注目地理領域を規定するためロケーション情報（例えば、矩形領域を規定する４点の経度及び緯度座標）を含む緊急通報が生成されると、サーバは格納されたクライアントロケーション情報を用いて注目領域内にあるクライアントデバイスを識別できる。そして、識別されたクライアントデバイスへ緊急通報を送信できる。この実施形態では、緊急通報のロケーション情報をクライアントデバイスへ送信しなくてもよいが、上述したように、クライアントデバイス上のＣＡＭシステムは受信箱のメンテナンス（例えば、規定領域から外れたメッセージを削除すること）にロケーション情報を役立てることができる。代わりに、遠隔サーバにてクライアントデバイスロケーションが監視される場合には、通報生成システムは、クライアントデバイスロケーションに基づき特定の通報を削除することをクライアントデバイス上のＣＡＭシステムに指導する別のメッセージを生成できる。加えて、特定の通報を削除することをクライアントデバイス上のＣＡＭシステムに指導するメッセージは、被害者の位置が特定され次第アンバーアラート緊急通報を削除する等、イベントベースであってもよい。したがって、この態様は、クライアントデバイスロケーションデータが局所的に保守されるか遠隔的に保守されるかに係らず、使用できる。

クライアントデバイスロケーションを識別するプロセスは多数のバリエーションとサブプロセスとを含み得る。例えばデバイスのロケーションは、クライアントデバイスのロケーション情報にアクセスすることによって判定できる。次に、そのクライアントデバイスロケーションを使用して、通報の中にあるロケーションデータによって規定される地理領域の中にクライアントデバイスがあるか否かを判定できる。ロケーション情報はクライアントデバイスにて局所的に格納でき、及び／又は（例えば通信事業者ネットワーク上のサーバにて）遠隔的に格納できる。同様に、クライアントデバイスが地理領域内にあるか否かの判定は、クライアントデバイス又はリモートサーバにて判定できる。クライアントデバイスロケーション情報は、クライアントデバイスの経度及び緯度座標を含み得る。同様に、通報の中のロケーションデータは中心経度及び中心緯度座標と半径方向距離とを含み得る。この場合は、中心経度及び中心緯度座標から半径方向距離の中にある経度及び緯度座標として地理領域を判定できる。代わりに、通報の中にあるロケーションデータは、領域（例えば、三角形、正方形、及び矩形）を規定する少なくとも３つの経度及び緯度座標を含み得る。この場合は、少なくとも３つの経度及び緯度座標によって規定される領域の中にある経度及び緯度座標として地理領域を判定できる。

さらに、所望の精度に応じて基地局及び／又は通信塔を目標クライアントデバイスの判定に使用できる。この実施形態では、緊急通報の中で生成されるロケーションデータを上述した地理領域の規定に使用することができる。この場合、規定地理領域の中にある基地局／通信塔と通信するクライアントデバイスは目標地理領域の中にあるとみなすことができ、これに緊急通報を送信することができる。ただしこの態様は、上述したロケーションベースの緊急通報を配信する方法と組み合わせて使用できる。

例えば、緊急通報を直接的に送信する代わりに、各クライアントデバイス上でＣＡＭシステムを呼び出す「覚醒」メッセージをクライアントデバイスへ送信でき、前記ＣＡＭシステムはクライアントデバイスのロケーションを報告する。そしてサーバにより更新されたロケーション情報を使用して、実際に目標地理領域の中にあるデバイスだけを目標に定めることができる。代わりに、識別された基地局／通信塔と通信するクライアントデバイスへ緊急通報を送信でき、前記クライアントデバイス上のＣＡＭシステムは局所的地理的ロケーションデータを使用でき、又は地理的ロケーションを入手できる。クライアントデバイスは、これの地理的ロケーションと緊急通報の中で規定される地理領域とを使用し、上述したように自身が目標領域内にあるか否かを判定できる。クライアントデバイスを識別する第一の粒度レベルとして基地局／通信塔を使用すれば、ネットワークトラフィックをさらに減らすことができ、目標地理領域の中にある見込みが最も高いクライアントデバイスに向けて通報を絞ることができる。

上記の開示を鑑み、当業者は、本発明の実施形態が上述したアクション、オペレーション、及び／又は機能からなるシーケンスを遂行する方法を含むことを認識する。例えば図６Ａに図示されたように、緊急通報を無線通信する方法は、ブロック６１０にてロケーションデータを含む緊急通報を生成することを含み得る。ブロック６１０では、通報の中にあるロケーションデータとクライアントデバイスのロケーションとに基づいて、緊急通報を受信するべきクライアントデバイスを識別する。さらに、ブロック６３０ではクライアントデバイスへ緊急通報を送信できる。緊急通報はクライアントデバイス、ブロック６４０にて受信でき、緊急通報はクライアントデバイス、ブロック６５０上で表示できる。当業者は、図示されたフローチャートが逐次実行に限定されないこと、そしてブロック構成要素の順序を任意に変えることができることを認めるであろう。例えば、クライアントデバイスが緊急通報の中で規定される地理領域の中にあるか否かを判定するときの関係オペレーションを表すため、ブロック６４０とブロック６５０との間にブロック６２０を挿入することができる。

図６Ｂは、緊急通報の中にあるロケーションデータによって規定される地理領域に基づきクライアントデバイスを識別する方法を図示するフローチャートである。ブロック６２２では、緊急通報に収容されたロケーションデータを用いて目標地理領域を判定する。上述したように、この判定はクライアントデバイスにて、通信事業者ネットワーク上のサーバにて、及び／又は他のリモートサーバにて、遂行できる。ブロック６２４ではクライアントデバイスロケーション情報にアクセスする。上述したように、これもまたクライアントデバイスにて、通信事業者ネットワーク上のサーバにて、及び／又は他のリモートサーバにて、遂行できる。さらに、データにアクセスすることは本明細書で論述する方法（例えば、クライアントデバイスの中に、又はクライアントデバイスから離れたサーバ上に、あらかじめ格納された地理位置データにアクセスすること、（例えばｇｐｓＯｎｅ（登録商標）を用いて）クライアントデバイスのロケーションを入手するためクライアントデバイス上に常駐するロケーションＡＰＩを起動すること等）のいずれかを含み得る。その後ブロック６２６では、クライアントデバイスが目標領域の中にあるか否かを判定するため、クライアントデバイスの地理位置を目標領域に比較できる。同様に、上述したように、この判定はクライアントデバイスにて、通信事業者ネットワーク上のサーバにて、及び／又は他のリモートサーバにて、遂行できる。

例えば図６Ｃは、クライアントデバイスが目標地理領域の中にあるか否かを判定する本発明の一実施形態を図示するものである。上述したように、この構成におけるアクションのシーケンスは、クライアントデバイスが目標地理領域の中にあると識別される（例えば６２０）前にクライアントデバイスにて通報が受信（例えば６４０）される点が、図６Ａに図示するものと異なる。代わりにブロック６２０では、基地局／通信塔、都市、地域、又はその他の一般的に広域の地理的領域等によって、第一のレベルにてクライアントデバイスを識別できる。この場合は、図６Ｃに図示されたプロセスを、緊急通報が受信された後にクライアントレベルで遂行されるさらなる精緻化とすることができる。

図６Ｃの説明にあたって、同様の機能は同じ参照番号を維持する。したがって、ブロック６２２、６２４、及び６２６は上述したように、ただしクライアントデバイスにて、作用する。緊急通報を受信するクライアントデバイスが目標地理領域の中にない場合、通報は破棄される、ブロック６２７。目標地理領域の中にクライアントデバイスがある場合は、次いで、通報が表示されるか、又は関連する命令が実行される（例えば、ブラウザを起動し指定ページをダウンロードする）、ブロック６２８。表示という用語は、表示ユニット上でのテキスト及び／又はグラフィック表示、表示灯、可聴信号（例えば、ブザー、呼び出し音、音声メッセージ等）、振動、及び前記の組み合わせ等、あらゆるタイプの通知を含み得る。ブロック６２９では、メッセージを、後ほど再び呼び出すため、格納できる。ひとたび格納された緊急通報は、定期的に自動的に、又はユーザーの要請に応じて、再び呼び出すことができる。さらに通報は、上述したようにユーザーによる管理のため、及び／又はＣＡＭによる自動受信箱管理のため、指定された受信箱に格納できる。

前記から察することができるように、本発明の実施形態は、貴重な緊急情報をエンドユーザーと送信者（例えば、警察、政府機関等）とへ提供することにより緊急サービスを向上させるため、クライアントデバイスロケーション情報とＣＡＭ装備とを活用できる。例えば図５Ａに図示されたように、送信者（例えば、事業者又は政府機関）はＣＡＭコンソール５２２へログインでき、通信事業者ネットワークへ結合された通報発送サーバ１３０へ接続できる。次に送信者は、最後に判明したロケーション又は出現、及び捜索半径（例えば２マイル）等の情報を送信することにより、緊急事態（例えば、拉致又は「アンバーアラート」）に関する通報プッシュを生成できる。緊急通報を受信すべき加入者のＩＤは上述したように判定できる。通報発送サーバ１３０及び／又はＳＭＳＣ ５２８は、例えば拉致発生現場の規定半径の中にある全クライアントデバイスへ、緊急通報（例えば、ＢＲＥＷ（登録商標）指向ＳＭＳ）を送信できる。緊急通報（例えばＢＲＥＷ（登録商標）指向ＳＭＳ）はクライアントデバイス３００（例えばＢＲＥＷ（登録商標）対応電話機）上でＣＡＭ ３１０を作動させることができる。ＣＡＭ ３１０は、衛星コンステレーション５３２及び／又は位置判定体５３４を利用しながらＧＰＳを介してクライアントデバイス３００の位置を入手でき、クライアントデバイス３００が（例えば、誘拐現場及び半径によって規定される）目標領域の中にあるか否かを判定できる。ＣＡＭ ３１０は、クライアントデバイス３００が目標領域の中にある場合に、メッセージを表示でき、誘拐が発生したこと、そして緊急通報の中でその他関係情報が中継されることを音声で知らせる。加えて、ユーザーインターフェース３１２は、「もしもあなたが関係情報をつかんでいるならＯＫを押してそれを警察に報告してください」等、メッセージを収容できる。関係情報を有しているユーザーは「ＯＫ」を押すことができ、これによりＣＡＭ ３１０はユーザーのロケーションを警察サーバへ送信でき、警察官はそのロケーションまで移動できる。加えて、ユーザーに連絡をとって関係情報を有していることを確認できるようにするため、事業者９１１、コールセンター、又は政府機関に向けてダイレクト音声リンクを確立でき、又はコールバック情報を中継できる。したがって、本発明の実施形態は緊急通報の有効性をさらに高めるためダイレクトフィードバック機構を含み得る。例えばフィードバック機構は、タッチスクリーン、ソフトキー、ハードキー、ハイパーリンク、メニュー選択等のうちの１つであってもよい。

さらなる実施形態で、当業者は、コンピュータプラットフォームのメモリ等のコンピュータ可読媒体上で具現されるプログラムの実行によって前記の方法を実施できることを認める。命令は、様々なタイプの信号担架又はデータ格納一次、二次、又は三次媒体の中に存在できる。媒体は、例えばクライアントデバイス及び／又はサーバからアクセスできるか、又はこれの中に存在する、ＲＡＭを備えてもよい。ＲＡＭ、ディスケット、又はその他の二次格納媒体に収容されてもされなくても、命令は、ＤＡＳＤストレージ（例えば、従来の「ハードドライブ」又はＲＡＩＤアレイ）、磁気テープ、電子読み取り専用メモリ（例えば、ＲＯＭ又はＥＥＰＲＯＭ）、フラッシュメモリカード、光学式格納デバイス（例えば、ＣＤ−ＲＯＭ、ＷＯＲＭ、ＤＶＤ、デジタル光学テープ）、ペーパー「パンチ」カード、又はデジタル及びアナログ伝送媒体を含む他の適切なデータ格納媒体等、様々な機械可読データ格納媒体に格納できる。

前記の開示は本発明の例証的実施形態を明らかにするものであり、添付の請求項によって規定される本発明の範囲から逸脱せず様々な変更及び修正を施せることに注意されたい。本明細書で説明した本発明の実施形態に従う方法クレームの活動又はステップは、特定の順序で遂行される必要はない。さらに、本発明の構成要素は単数形で説明されるか、又は請求されることがあるが、単数形への限定が明言される場合を除き、複数形が想定される。

本発明の少なくとも一実施形態によるクライアントデバイス及びサーバをサポートする無線ネットワークアーキテクチャの図である。 本発明の少なくとも一実施形態によるクライアントデバイス及びサーバをサポートする無線ネットワークアーキテクチャのより詳細な図である。 本発明の少なくとも一実施形態によるＣＡＭシステムのアーキテクチャを表す図。 本発明の少なくとも一実施形態によるアナウンスメントマネージャの図解である。 本発明の実施形態による通報生成システムとクライアントデバイスとロケーションシステムとを図解する無線ネットワークアーキテクチャの図である。 本発明の実施形態による通報生成システムとクライアントデバイスとロケーションシステムとを図解する無線ネットワークアーキテクチャの図である。 本発明の実施形態に従い緊急通報を送受する方法を図解するフローチャートである。 本発明の実施形態に従い緊急通報を送受する方法を図解するフローチャートである。 本発明の実施形態に従い緊急通報を送受する方法を図解するフローチャートである。

Claims (45)

1. 緊急通報を通信する無線通信システムであって、
   クライアントデバイスを備え、このクライアントデバイスは、
   トランシーバと、
   前記トランシーバへ作動可能な状態で結合され、目標地理領域を規定するロケーションデータを含む緊急通報を受信するよう構成されたロジックと、
   前記クライアントデバイスの地理位置が前記目標地理領域の中にあると判定した時点で前記クライアントデバイス上に前記緊急通報を表示するよう構成されたロジックと、
   を備える、システム。
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. 前記クライアントデバイスにて前記緊急通報を格納する手段と、
    前記地理領域の外にある前記クライアントデバイスの現在ロケーションと、所定の時間と、イベントベースの通報削除リクエストのうちの少なくとも１つに基づき前記格納された緊急通報を自動的に削除する手段と、
    をさらに備える、請求項４４に記載のクライアントデバイス。

Images