(57)【特許請求の範囲】
【請求項１】
モバイル・デバイス上において、無線受信機に情報を転送しかつ該無線受信機から情報を転送する、前記モバイル・デバイス上のプログラミング・インターフェースであって、  前記無線受信機に配信するメッセージを受信するように構成したメッセージ処理コンポーネントと、
前記メッセージ処理コンポーネントに結合したドライバ・コンポーネントと、
を含み、  前記メッセージ処理コンポーネントは、受信したメッセージ、前記無線受信機に転送するデータを収容する入力バッファの入力バッファ・ロケーション、前記入力バッファ内に収容する情報のバイト数、前記無線受信機から受信する情報を収容する出力バッファの出力バッファ・ロケーション、前記出力バッファ内に収容する情報の最大バイト数、および前記無線受信機から受信する実際のバイト数に基づいて、前記ドライバ・コンポーネントへの制御コールを実行し、実行する制御動作を指定するように構成してあり、
前記ドライバ・コンポーネントは、前記メッセージ処理コンポーネントから前記制御コールを受け取り、前記指定の制御動作を実行するように構成してある、プログラミング・インターフェース。
【請求項２】
前記制御動作は、前記無線受信機内に値をプログラムするプログラミング動作であり、前記制御コールはプログラミング・データ構造をドライバに渡し、該プログラミング・データ構造が、
前記プログラミング・データ構造のサイズを示す構造サイズ部と、
前記プログラミング・データ構造においてどの部分が有効かを示すマスク部と、
前記プログラミング動作が値をプログラムするのか、プログラムした値を解除するのかを示す動作コード部と、
プログラムする値または解除する値のタイプを示すタイプ・コード部と、
プログラムする値または解除する値を示すプログラム・データ部と、
前記プログラム・データの長さを示すプログラム・データ長部と、
を含む請求項１記載のプログラミング・インターフェース。
【請求項３】
前記タイプ・コード部が、プログラムする暗号キーまたは解除する暗号キーを示し、前記プログラム・データ部がキー・データ構造を備える請求項２記載のプログラミング・インターフェース。
【請求項４】
前記キー・データ構造が、
前記キー・データ構造のサイズを示す構造サイズ部と、
前記キー・データ構造の内どの部分が有効かを示すマスク部と、
前記暗号キーを示すキー部と、
前記暗号キーに対応する数値を示すキー番号部と、
前記暗号キーと共に用いる暗号アルゴリズムを示すアルゴリズム部と、
前記暗号キーの長さを示すキー長部と、
前記暗号キーを格納してあるロケーションを示すキー・タブ部と、
前記キータブ部の長さを示すキータグ長部と、
とを含む請求項３記載のプログラミング・インターフェース。
【請求項５】
前記モバイル・デバイスはアドレスを通じてメッセージを受信し、前記タイプ・コード部は、プログラムするアドレスまたは解除するアドレスを示し、前記プログラム・データ部はアドレス・データ構造を備える請求項２記載のプログラミング・インターフェース。
【請求項６】
前記アドレス・データ構造が、
前記アドレス・データ構造のサイズを示す構造サイズ部と、
前記アドレスデータの内どの部分が有効かを示すマスク部と、
前記アドレスを示すアドレス部と、
前記アドレスに対応する数値を示すアドレス数値部と、
前記アドレスのステータスを示すステータス部と、
前記アドレス部に関連するタグを示すアドレス・タグ部と、
前記アドレスに関連する期限日を示す期限日部であって、該期限部以降に前記アドレスを通じて受信した後続のメッセージを破棄するようにする、期限日部、
前記アドレス・タグ部の長さを示すアドレス・タグ部と、
を含む請求項５記載のプログラミング・インターフェース。
【請求項７】
前記アドレス・データ構造が、更に、
前記アドレスを通じて受信したメッセージを解読する際に用いる暗号キーを格納してあるロケーションを示すキー・タグ部と、
前記キー・タグ部の長さを示すキー・タグ長部と、
を含む請求項６記載のプログラミング・インターフェース。
【請求項８】
前記アドレス・データ構造が、更に、
前記アドレスの記述名称を示すアドレス名称部と、
前記アドレスを通じて受信したメッセージのテキスト記述を示す説明部と、
前記アドレス名称部の長さを示すアドレス名長さ部と、
前記説明部の長さを示す説明長部と、
を備える請求項６記載のプログラミング・インターフェース。
【請求項９】
前記モバイル・デバイスは、アドレスと、該アドレスに対応するグループ・コードとを通じてメッセージを受信し、前記タイプ・コード部は、プログラムするグループ・コードまたは解除するグループ・コードを示し、前記プログラム・データ部は、グループ・コード・データ構造を備える請求項２記載のプログラミング・インターフェース。
【請求項１０】
前記グループ・コード・データ構造が、
前記グループ・コード・データ構造のサイズを示す構造サイズ部と、
前記グループ・コード・データ構造の内どの部分が有効かを示すマスク部と、
前記グループ・コードを示すグループ・コード部と、
前記グループ・コードに対応する数値を示すグループ・コード数値部と、
前記グループ・コードのステータスを示すステータス部と、
前記グループ・コードに関連する期限日を示す期限日部であって、該期限日以降に前記グループ・コードを通じて受信した後続のメッセージを破棄するようにした、期限日部と、
前記グループ・コードに関連するタグを示すグループ・コード・タグ部と、
前記アドレスに関連するタグを示すアドレス・タグ部と、
前記アドレス・タグ部の長さを示すアドレス・タグ長部と、
前記グループ・タグ部の長さを示すグループ・タグ長と、
を含む請求項９記載のプログラミング・インターフェース。
【請求項１１】
前記グループ・コード・データ構造が、更に、
前記グループ・コードを通じて受信したメッセージを解読する際に用いる暗号キーを格納してあるロケーションを示すキー・タグ部と、
前記キー・タグ部の長さを示すキー・タグ長部と、
を含む請求項１０記載のプログラミング・インターフェース。
【請求項１２】
前記グループ・コード・データ構造が、更に、
前記グループ・コードの記述名称を示すグループ・コード名称部と、
前記グループ・コードを通じて受信したメッセージのテキスト記述を示す説明部と、
前記グループ・コード名称部の長さを示すグループ・コード名長さ部と、
前記記述部の長さを示す説明長部と、
を備える請求項１１記載のプログラミング・インターフェース。
【請求項１３】
前記モバイル・デバイスはキャリアからのアドレスを通じてメッセージを受信し、前記タイプ・コード部は、プログラムするキャリア指定または解除するキャリア指定を示し、前記プログラム・データ部はキャリア・データ構造を備える請求項２記載のプログラミング・インターフェース。
【請求項１４】
前記キャリア・データ構造が、
前記キャリア・データ構造のサイズを示す構造サイズ部と、
前記キャリア・データ構造の内どの部分が有効かを示すマスク部と、
前記キャリアから前記メッセージを受信する無線周波数を示す周波数部と、
前記キャリアの名称を示す名称部と、
前記キャリアから受信するメッセージ・タイプの記述を示す説明部と、
前記モバイル・デバイスのユーザに関連する識別番号を示すユーザ識別部と、
前記ユーザ識別部の長さを示すユーザ識別長部と、
前記名称部の長さを示す名称長さ部と、
前記説明部の長さを示す説明長部と、
を含む請求項１３記載のプログラミング・インターフェース。
【請求項１５】
前記無線受信機には既存値が格納してあり、プログラミング・データ部が、複数のフィールドを有するプログラミング・データ構造を備え、各フィールドが前記無線受信機上の値に対応し、各フィールドが、前記無線受信機にプログラムする新たな値を収容し、前記プログラミング・データ構造内の前記フィールドが前記既存値に対応するフィールドを有さない場合、前記無線受信機上の既存値を不変のままとする請求項２記載のプログラミング・インターフェース。
【請求項１６】
前記ドライバ・コンポーネントが、
前記指定の制御動作を実行する際に、前記ドライバが実行する関数の関数ライブラリを含む請求項１記載のプログラミング・インターフェース。
【請求項１７】
前記関数ライブラリが、
前記制御コール内において前記ドライバ・コンポーネントに供給した情報に基づいて暗号キーを導出する暗号キー導出コンポーネントを含み、前記ドライバ・コンポーネントは前記暗号キー導出コンポーネントを利用して前記暗号キーを導出し、該暗号キーを前記ドライバ・コンポーネントのキー・ロケーションに格納し、前記キー・ロケーションを示すキー・ハンドルを前記メッセージ処理コンポーネントに戻す請求項１６記載のプログラミング・インターフェース。
【請求項１８】
前記関数ライブラリが、
前記制御コール内において前記ドライバ・コンポーネントに供給した情報を解読し、その有効性を確認する解読および有効性確認コンポーネントを含み、前記ドライバ・コンポーネントは前記解読および有効性確認コンポーネントを利用して前記情報を解読しその有効性を確認して、前記情報が有効か否かを示す値を前記メッセージ処理コンポーネントに戻す請求項１６記載のプログラミング・インターフェース。
【請求項１９】
前記ドライバ・コンポーネントは、前記制御コールが指定する前記制御動作が行われたか否かを示す値を、前記メッセージ処理コンポーネントに戻すように構成してある請求項１記載のプログラミング・インターフェース。
【発明の詳細な説明】
【０００１】
（発明の背景）
本発明は、一般にモバイル・デバイスとして知られている、パーソナル・モバイル計算デバイスに関する。更に特定すれば、本発明は、情報をモバイル・デバイスに配信し、モバイル・デバイスをプログラムするシステムおよび方法に関するものである。
【０００２】
モバイル・デバイスは、多くの場合パーソナル・ディジタル・アシスタントと呼ばれている、小型電子計算デバイスのことである。このようなモバイル・デバイスの多くは、ハンド・ヘルド・デバイスまたは手の平サイズのデバイスであり、手の中にすんなり納まるようなものである。
【０００３】
一般に、モバイル・デバイスは、プロセッサ、ランダム・アクセス・メモリ（ＲＡＭ）、およびキーボードやディスプレイのような入力デバイスを含む。キーボードを接触感応ディスプレイとして組み込む場合等では、キーボードをディスプレイと一体化することができる。オプションとして、通信インターフェースを備え、デスクトップ・コンピュータと通信するために一般的に用いられている。交換可能なバッテリまたは再充電可能なバッテリがモバイル・デバイスに給電する。オプションとして、モバイル・デバイスは、内蔵バッテリを無視または再充電する、外部電源から電力を受けることが可能である。
【０００４】
従来のアプリケーションには、モバイル・デバイスをデスクトップ・コンピュータと共に用いるものもある。例えば、モバイル・デバイスのユーザは、仕事場または家庭、あるいは双方においてデスクトップ・コンピュータにアクセスし、使用する場合もある。ユーザは、通常、デスクトップ・コンピュータおよびモバイル・ユニット双方で同じ種類のアプリケーションを走らせる。したがって、モバイル・デバイスをデスクトップ・コンピュータと結合し、モバイル・デバイスと情報を交換したり、情報を共有するように設計することは非常に有利である。
【０００５】
このようなモバイル・デバイスに情報を提供する別の技法に、ワイヤレス伝送リンクを介するものがある。このような情報は、電子メールまたはニュース、天気予報、スポーツ、交通、および地域のイベント情報を含むことができる。この情報は、通常、インターネットに接続したデスクトップ・コンピュータから得られ、有線接続を介して配信される。しかしながら、このような情報を同様にワイヤレス接続を通じて配信することが望ましい場合もある。モバイル・デバイス上のワイヤレス受信機は、情報がモバイル・デバイスに向けて送られると、これを受信するように動作することができる。
【０００６】
モバイル・デバイスがページャであったり、あるいはページャを有する場合、所与のシステムにおける各ページャは１つ以上のアドレスを有する。ワイヤレス・チャネルを通じてメッセージを送信する場合、あるアドレスを宛先とする。当該ワイヤレス・チャネルに割り当てられるページャは全てそのメッセージを受信し、メッセージ内に含まれているアドレスをそれ自体のアドレスと突き合わせてチェックする。このアドレス照合アルゴリズムは、ハードウエアまたはソフトウエア、あるいはハードウエアおよびソフトウエアの組み合わせのいずれでも実現可能である。着信メッセージに関連するアドレスが、ページャ上のいずれのアドレスとも一致しない場合、メッセージを破棄する。しかしながら、アドレスがページャ上のアドレスの１つと一致した場合、そのメッセージを受け入れ、ページャ上のプロトコル・スタックにおける上位ソフトウエアに転送し、適切な処理を行なう。
【０００７】
アドレスには、通常、２つのタイプがあると考えられる。第１のタイプは、所与のワイヤレス・ネットワーク内部において一意の個人アドレスである（即ち、そのアドレスを有するページャは１つのみである）。個人アドレスは、メッセージを特定のページャに送るために用いられる。
【０００８】
第２タイプのアドレスは、ブロードキャスト・アドレスである。ブロードキャスト・アドレスは、通常、所与のワイヤレス・ネットワーク内の多数のページャにプログラムされている。したがって、ブロードキャスト・アドレスを通じて配信する単一のメッセージは、当該ネットワークにおける多数のページャが受信し受け入れる。このようなアドレスは、ニュース、交通、天気予報等、前述のサービスのようなブロードキャスト・サービスを実施するために用いる。
【０００９】
現在、ページャのようなモバイル・デバイスにおいてアドレスをプログラムし直す便利な方法がない。代わりに、ページャをサービス・センタに送り返し、ここで特殊工具を用いて、アドレスを格納してあるページャの内部ストレージにアクセスし、これを変更する。従来技術のシステムには、空中プログラミング（ｏｖｅｒ−ｔｈｅ−ａｉｒ  ｐｒｏｇｒａｍｉｎｇ）を達成しようとしたものもある。このようなシステムでは、ネットワーク所有者（即ち、キャリア）は、ページャに特殊メッセージを送り、当該ページャ内のアドレスを変更する。
【００１０】
しかしながら、今日までこれは全く普及していない。各ページャの製造業者は、それ自体の固有なメッセージ・フォーマットおよび方法を、ページャに関連する無線ハードウエアおよびソフトウエアに有している。したがって、異なる製造業者のページャ各々をプログラムし直すには、特殊なメッセージを特別にフォーマットする必要がある。加えて、製造業者の中には、２種類以上のページャ・モデル即ちスタイルを有し、各々がそれ自体の内部固有メッセージ・フォーマットおよび方法を有する。したがって、単一の製造業者のページャであっても、ユーザが使用しているページャの個々のタイプに基づいて、様々な特殊プログラミング・メッセージを送る必要がある。
【００１１】
更に空中プログラミングは、セキュリティに関して重大な難点がある。言い換えると、プログラムするブロードキャスト・サービスのプロバイダが、当該ブロードキャスト・サービスを受信するための料金または加入料をユーザに課金したい場合、プログラミング・メッセージは極秘としなければならない。さもなければ、不正なプログラミングをページャ・デバイスに行なってブロードキャスト・サービスを受信することが問題となる。
【００１２】
更に、インターネットのような世界的なコンピュータ・ネットワークの出現により、情報ブロードキャスト・サービスが広く普及し重要となっている。しかしながら、通常のページャは限られた数のアドレスしか有することができない（大抵の場合２ないし８）。ページャの様々なユーザの広範囲に及ぶ関心や要望を満たすためには、提供するブロードキャスト・サービスの数を大幅に増加させることが望ましい。その場合、個々のユーザが望むブロードキャスト・サービスを選択するアドレスをページャが含むように、個々のユーザは各々（サービス・センタに返送することによって）ページャをプログラムし直すことが必要となる。これは、ユーザがブロードキャスト・サービスの選択を追加、削除、または変更する度に行なわなければならない。これは、非常にコストがかかり非効率であるので、このようなブロードキャスト・サービスの成長や発展を少なくとも妨げることになろう。
【００１３】
また、空中プログラミングには、信頼性という別の重大な障害もある。例えば、プログラミング・メッセージを空中に伝送しても、プログラミング・メッセージは、一旦ページャが受信したなら、エラーを含む可能性があり、またはプログラミング・メッセージを送信したときに、ページャがサービス区域外にあったり、スイッチが切られている可能性もある。一方向ページング・システム（今日世界で最も普及しているシステム）では、発信側は、プログラミング・メッセージが実際に所望のページャによって確かに受信されたことを知る方法がない。
（発明の概要）
本発明は、一実施形態において、デバイス／プロトコル／ネットワークに独立したメッセージのモバイル・デバイスへの伝送、およびモバイル・デバイスのプログラミングを可能にする、プログラミング・インターフェースに関するものである。他の実施形態では、本発明は、モバイル・デバイス上に維持し、これに対応するデータ構造に関する。更に、別の実施形態において、本発明は、プログラミング・メッセージのセキュリティ、ならびにモバイル・デバイスがプログラミング・メッセージの受信および実施の成功を承認可能な承認チャネルを提供する。
（好適な実施形態の詳細な説明）
図１は、本発明を実現するシステム１０を一例として示す。システム１０は、コンテンツ・プロバイダ１２、ワイヤレス・キャリア１４、デスクトップ・コンピュータ１６およびモバイル・デバイス１８を含む。コンテンツ・プロバイダ１２は、データベースまたはその他のデータ・ソースから、適切なタイプのあらゆるデータを提供する。例えば、コンテンツ・プロバイダ１２は、モバイル・デバイス１８のユーザが望み得るワイヤレス・サービスまたはその他の種類のサービスのプロバイダとして、以降論ずることにする。このようなサービスの例には、ニュース、天気予報およびスポーツ・サービス、株価サービス、交通報告サービス等が含まれる。
【００１４】
ワイヤレス・キャリア１４については、本願では後程更に詳しく説明する。しかしながら、端的に言えば、ワイヤレス・キャリア１４は、サービス・コンテンツおよびプログラミング・メッセージ（以降コンテンツ）を、コンテンツ・プロバイダ１２から、ダイアル・アップまたは直接インターネット接続あるいはネットワーク接続によって受信するように構成してある。ワイヤレス・キャリア１４がコンテンツ・プロバイダ１２から情報を得る方法は、固有の方法および一般的な方法を含むことができる。例えば、例示の一実施形態では、ワイヤレス・キャリア１４は、本件特許出願人から入手可能なウェブ・ブラウザを用いて、コンテンツ・プロバイダのウェブ・サイトにおいて、アクティブ・チャネルに加入することができる。当該ウェブ・ブラウザのコンポーネントは、ウェブ・サイトからデータを引き出し、これをキャッシュに格納し、後にモバイル・デバイス１８に伝送する。
【００１５】
また、ワイヤレス・キャリア１４はワイヤレス情報サーバ（ＷＩＳ）１３も含む。サーバ１３は、同様にコンテンツ・プロバイダ１２からデータを引き出すことができるコンポーネントを有する。また、サーバ１３は、コンテンツ・プロバイダ１２から受信したコンテンツを、ワイヤレス・キャリア１４が用いる特定のタイプのトランスポートと互換性のある断片（ｐｉｅｃｅ）に分割する。例えば、サーバ１３は、用いるチャネル・タイプまたはトランスポート・タイプのために、データを分割し、最大パケット・サイズの制約、キャラクタ・セットに対する要求に合わせるようにすることができる。伝送に先立って、データを異なる形態に変換することが好ましい。本願では後に更に詳細に説明するが、このような変換は種々の形態の暗号を含むとよく、更に圧縮、符号化等も含むとよい。一旦データを適切に分割しトランスポートの制約に合わせたならば、次にワイヤレス・ネットワーク（ページング・チャネルを通じてというように）を通じて、空中を伝送し、モバイル・デバイス１８上で直接受信するように構成する。伝送データは、モバイル・デバイス１８上のワイヤレス受信機およびドライバ・コンポーネントが受信し、ここでモバイル・デバイス１８による使用のためにデータを調整する。
【００１６】
また、モバイル・デバイス１８はモデム２４を含むことも望ましい。したがって、ワイヤレス・キャリア１４を介して伝送するのではなく、サービス・コンテンツは、コンテンツ・プロバイダ１２から直接ダイアルアップ・モデム接続を通じて、モバイル・デバイス１８に伝送することができる。
【００１７】
デスクトップ・コンピュータ１６についても、この明細書では後に更に詳細に説明する。しかしながら、端的に言えば、デスクトップ・コンピュータは、標準的なウェブ・ブラウザを備えることが好ましい。その場合、デスクトップ・コンピュータ１６のユーザは、オフラインまたはオンラインで閲覧可能な所定のチャネル・コンテンツをユーザに提供するチャネルに、標準的な方法で加入することができるので好ましい。このように、デスクトップ・コンピュータ１６は、周期的に新たなコンテンツを検索し受信し、更にモバイル・デバイス１８に送信することができる。
【００１８】
また、デスクトップ・コンピュータ１６は、同期コンポーネント２６を含むことも好ましい。端的に言えば、同期コンポーネント２６は、モバイル・デバイス１８上の同様の同期コンポーネントと双方向処理を行い、同期対象のファイルが、デスクトップ・コンピュータ１６からモバイル・デバイス１８に、またはその逆に同期することを可能とする。一旦同期が取れたならば、双方のファイル（コンピュータ１６およびモバイル・デバイス１８上のファイル）は、最新のデータを含むことになる。
【００１９】
より具体的には、モバイル・デバイス１８は、好適な実施形態では、デスクトップ・コンピュータ１６、または他のモバイル・デバイス１８、あるいは双方と同期することができる。その場合、モバイル・デバイス１８上のオブジェクト・ストアに格納してあるオブジェクトのプロパティは、デスクトップ・コンピュータ１６または別のモバイル・デバイス１８上のオブジェクト・ストア上に格納してある同じオブジェクトの別のインスタンスのプロパティと同様となる。したがって、例えば、ユーザがデスクトップ・コンピュータ１６上のオブジェクト・ストアに格納してあるオブジェクトのあるインスタンスを変更すると、モバイル・デバイス１８を次回デスクトップ・コンピュータ１６に接続したときに、モバイル・デバイス１８のオブジェクト・ストア内の当該オブジェクトの第２インスタンスが更新されるので、同じオブジェクトの双方のインスタンスは最新のデータを含むことになる。これを同期と呼ぶ。
【００２０】
同期を取るためには、同期コンポーネント２６および２８をモバイル・デバイス１８およびデスクトップ・コンピュータ１６（または別のモバイル・デバイス１８）双方で走らせる。同期コンポーネントは、的確なインターフェースを介して互いに通信し、通信および同期を管理する。
【００２１】
尚、好適な実施形態では、モバイル・デバイス１８をデスクトップ・コンピュータ１６に結合可能であるが、別のモバイル・デバイスにも結合可能であることは、注記するに値しよう。この接続は、適当な商業的に入手可能ないずれの通信リンクを用いても、そして適当な通信プロトコルを用いて行なうことができる。例えば、好適な一実施形態では、モバイル・デバイス１８は、シリアル通信プロトコルを用いて通信を行なう物理的なケーブルによって、デスクトップ・コンピュータ１６または別のモバイル・デバイス１８と通信する。また、本発明によって、赤外線（ＩＲ）通信またはその他の適当な通信機構のような、別の通信機構も考えられる。
【００２２】
図２は、モバイル・デバイス１８の更に詳細なブロック図である。モバイル・デバイス１８は、マイクロプロセッサ３０、メモリ３２、入出力（Ｉ／Ｏ）コンポーネント３４、デスクトップ通信インターフェース３６、ワイヤレス受信機３７、およびアンテナ３９を含むことが好ましい。一実施形態では、これらのコンポーネントは、適切なバス３８を通じて、互いの通信のために結合してある。
【００２３】
メモリ３２は、バッテリ・バックアップ・モジュール（図示せず）を備えたランダム・アクセス・メモリ（ＲＡＭ）のような不揮発性電子メモリとして実現し、モバイル・デバイス１８全体の電力が停止した場合に、メモリ３２に格納してある情報を失わないようにすることができる。メモリ３２の一部は、プログラム実行のためにアドレス可能なメモリとして割り当てることが好ましく、一方メモリ３２の残りの部分は、ディスク・ドライブ上の格納をシミュレートするためというように、格納のために用いることが好ましい。
【００２４】
メモリ３２は、オペレーティング・システム４０、アプリケーション・プログラム４２（パーソナル情報マネージャ即ちＰＩＭ等）、およびオブジェクト・ストア４４を含む。動作中、オペレーティング・システムは、メモリ３２からプロセッサ３０によって実行することが好ましい。オペレーティング・システム４０は、モバイル・デバイス用に設計し、１組の外から見える（ｅｘｐｏｓｅｄ）アプリケーション・プログラミング・インターフェース（ＡＰＩ）およびメソッドを通じてＰＩＭ４２が利用可能なデータベース機能を実装することが好ましい。オブジェクト・ストア４４内のオブジェクトは、少なくとも部分的に、前述の外から見えるアプリケーション・プログラム・インターフェースおよびメソッドへのコールに応答して、ＰＩＭ４２およびオペレーティング・システム４０によって維持することが好ましい。
【００２５】
Ｉ／Ｏコンポーネント３４は、好適な一実施形態では、モバイル・デバイス１８のユーザからの入力および出力動作を簡便化するために備えたものである。Ｉ／Ｏコンポーネント３４については、図３および図４に関して更に詳細に説明する。
【００２６】
オプションとして、デスクトップ通信インターフェース３６は、あらゆる適当な通信インターフェースを提供する。好ましくは、インターフェース３６は、図１に関して説明したように、デスクトップ・コンピュータ１６、コンテンツ・プロバイダ１２、ワイヤレス・キャリア、そして任意に別のモバイル・デバイス１８と通信するために用いる。したがって、通信インターフェース３６は、デスクトップ・コンピュータ１６と通信するために同期コンポーネント２８、そしてコンテンツ・プロバイダ１２と通信するためにモデム２４を含むことが好ましい。ワイヤレス受信機およびドライバ２２は、ワイヤレス・キャリア１４と通信するために用いる。
【００２７】
図３は、本発明と共に使用可能なモバイル・デバイス１８の好適な一実施形態の概略構成図である。モバイル・デバイス１８は、図３に示すように、デスクトップ・アシスタントである。好適な一実施形態では、モバイル・デバイス１８は、小型化キーボード４３、ディスプレイ４５およびスタイラス４６を含む。小型化ディスプレイ４５は、スタイラス４６と共に用いる接触感応画面を有する液晶ディスプレイ（ＬＣＤ）である。スタイラス４６は、指定した座標においてディスプレイ４５を押下するかまたはディスプレイ４５に接触し、あるユーザ入力機能を実行するために用いる。小型化キーボード４３は、好ましくは、あらゆる適当かつ望ましい機能キーを有し、所定のユーザ入力機能を実行することも可能な、小型化英数字キーボードとして実施する。
【００２８】
図４は、本発明の別の好適な実施形態によるモバイル・デバイス１８の別の簡略構成図である。図４に示すように、モバイル・デバイス１８は、図３に関して説明した部品と同様のものを含み、同様に付番してある。例えば、図４に示すように、モバイル・デバイス１８は、接触感応スクリーン４５も含み、これをスタイラス４６と共に用いて、モバイル・デバイス１８をページャとしてする場合に、所定のユーザ入力機能を実行するために用いることができる。スクリーン４５が接触感応でない場合、スタイラス４６は不要である。
【００２９】
尚、図３および図４に示すモバイル・デバイス用ディスプレイ４５は、互いに同一サイズとすることも互いに異なるサイズとすることも可能であるが、通常は、デスクトップ・コンピュータと共に用いる従来からのディスプレイよりは遥かに小型であることを注記しておく。例えば、図３および図４に示すディスプレイは、２４０×３２０座標、または１６０×１６０座標、またはその他のいずれかの適当なサイズのマトリクスによって定義することができる。
【００３０】
また、図４に示すモバイル・デバイス１８は、多数のユーザ入力キーまたはボタン（スクロール・ボタン４７等）も含み、ユーザは、ディスプレイ４５上に表示いてあるメニュー・オプションまたはその他のディスプレイ・オプションによってスクロールすることができ、あるいは、ユーザはディスプレイ４５に接触することなく、アプリケーションを変更したり、ユーザ入力機能を選択することができる。加えて、図４にも示すモバイル・デバイス１８は、電源ボタン４９も含み、これを用いて、モバイル・デバイス１８への全体的な電力をオンおよびオフに切り替えることができるようにすることが好ましい。
【００３１】
尚、図４に示す実施形態では、モバイル・デバイスは、手書きエリア５１を含むことをも注記しておく。手書きエリア５１は、スタイラス４６と共に用い、ユーザがメッセージを書き込み、メモリ４２に格納して、モバイル・デバイス１８が後に用いるようにする。例示としての一実施形態では、手書きメッセージを単に手書き形態で格納し、後にユーザが呼び出してディスプレイ・スクリーン４５上に表示し、ユーザがモバイル・デバイス１８に入力した手書きメッセージを見直すことを可能にする。別の好適な実施形態では、モバイル・デバイス１８にはキャラクタ認識モジュールを備え、ユーザがスタイラス４６を用いてエリア５１上に英数字情報を書き込むことによって、モバイル・デバイス１８に英数字情報を入力可能とする。この場合、モバイル・デバイス１８内のキャラクタ認識モジュールは、英数字キャラクタを認識し、これらのキャラクタをコンピュータ認識可能な英数字キャラクタに変換し、これをモバイル・デバイス１８内のアプリケーション・プログラム４２が用いることができるようにする。
【００３２】
勿論、モバイル・デバイス１８をページャとして実施する場合、スタイラス４６および手書きエリア５１は不要である。代わりに、モバイル・デバイス１８には単にスクリーン４５、ユーザ入力ボタン４７および電源ボタン４９、またはその他の適当な部品を備えるだけでよい。
【００３３】
図５および関連する論述は、本発明を実現可能とするのに適したデスクトップ・コンピュータ１６の全体的な説明を手短に行うことを意図するものである。必須ではないが、本発明の説明は、少なくとも部分的に、パーソナル・コンピュータ１６またはモバイル・デバイス１８が実行するプログラム・モジュールのようなコンピュータ実行可能命令に関して概略的に行うこととする。一般に、プログラム・モジュールは、特定のタスクを実行したり、あるいは特定の抽象的データ形式を使用する、ルーチン・プログラム、オブジェクト、コンポーネント、データ構造等を含む。更に、本発明は、マルチプロセッサ・システム、マイクロプロセッサを用いた消費者用電子機器またはプログラム可能な消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む、その他のコンピュータ・システム・コンフィギュレーションとでも実施可能であることを当業者は認めよう。また、本発明は、分散型計算機環境において、通信ネットワークを通じてリンクしたリモート処理デバイスによってタスクを実行するという実施も可能である。分散型計算機環境では、プログラム・モジュールは、ローカルおよびリモート・メモリ記憶装置双方に配置することができる。
【００３４】
図５を参照すると、デスクトップ・コンピュータ１６を実現するためのシステム例は、従来のパーソナル・コンピュータ１６の形態とした汎用計算機を含み、コンピュータ演算装置（ＣＰＵ）４８、システム・メモリ５０、およびシステム・メモリ５０から演算装置４８までを含む種々のシステム・コンポーネントを結合するシステム・バス５２を含む。システム・バス５２は、種々のバス・アーキテクチャのいずれかを用いたメモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、数種類のバス構造のいずれでもよい。システム・メモリ５０は、リード・オンリ・メモリ（ＲＯＭ）５４、およびランダム・アクセス・メモリ（ＲＡＭ）５５を含む。起動中等においてデスクトップ・コンピュータ１６内のエレメント間の情報転送に供する基本ルーチンを収容する基本入出力システム（ＢＩＯＳ）５６は、ＲＯＭ５４に格納してある。また、デスクトップ・コンピュータ１６は、ハード・ディスク（図示せず）の読み取りおよび書き込みを行うハード・ディスク・ドライブ５８、リムーバブル磁気ディスク５９の読み取りおよび書き込みを行う磁気ディスク・ドライブ５８、ならびにＣＤ−ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク６１の読み取りおよび書き込みを行う光ディスク・ドライブ６０も含むことができる。ハード・ディスク・ドライブ５７、磁気ディスク・ドライブ５８、および光ディスク・ドライブ６０は、ハード・ディスク・ドライブ・インターフェース６２、磁気ディスク・ドライブ・インターフェース６３、および光ディスク・ドライブ・インターフェース６４によって、それぞれシステム・バス５２に接続してある。これらのドライブおよびそれに関連するコンピュータ読み取り可能媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびデスクトップ・コンピュータ１６用のその他のデータの不揮発性格納を行う。
【００３５】
ここに記載する環境の一例は、ハード・ディスク、リムーバブル磁気ディスク５９およびリムーバブル光ディスク６１を採用するが、磁気カセット、フラッシュ・メモリ・カード、ディジタル・ビデオ・ディスク（ＤＶＤ）、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等のような、コンピュータによるアクセスが可能なデータを格納することができる、他の種類のコンピュータ読み取り可能媒体も、動作環境の一例において使用可能であることは、当業者には認められよう。
【００３６】
多数のプログラム・モジュールを、ハード・ディスク、磁気ディクス５９、光ディスク６１、ＲＯＭ５４またはＲＡＭ５５上に格納することができ、オペレーティング・システム６５、（ＰＩＭを含む）１つ以上のアプリケーション・プログラム６６、（同期コンポーネント２６を含む）その他のプログラム・モジュール６７、およびプログラム・データ６８を含む。ユーザは、キーボード７０、ポインティング・デバイス７２およびマイクロフォンのような入力デバイスによって、コマンドおよび情報をデスクトップ・コンピュータ１６に入力することができる。他の入力デバイス（図示せず）として、ジョイスティック、ゲーム・パッド、衛星ディッシュ（ｓａｔｅｌｌｉｔｅ ｄｉｓｈ）、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バス５２に結合してあるシリアル・ポート・インターフェース７６を介して、演算装置４８に接続しているが、サウンド・カード、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ：ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）のようなその他のインターフェースによって接続することも可能である。モニタ７７または別の種類の表示装置も、ビデオ・アダプタ７８のようなインターフェースを介して、システム・バス５３に接続する。モニタ７７に加えて、デスクトップ・コンピュータは、通常、スピーカやプリンタのような、その他の周辺出力デバイスを含むこともできる。
【００３７】
デスクトップ・コンピュータ１６は、リモート・コンピュータ７９のような１つ以上のリモート・コンピュータ（モバイル・デバイス１８以外）への論理接続を用いて、有線またはワイヤレス・ネットワーク環境で動作することも可能である。リモート・コンピュータ７９は、別のパーソナル・コンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他のネットワーク・ノードとすることができ、通常、デスクトップ・コンピュータ１６に関して先に記載したエレメントの多くまたは全てを含むが、メモリ記憶装置８０だけを図５に示す。図５に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）８１およびワイド・エリア・ネットワーク（ＷＡＮ）８２を含む。このようなネットワーク環境は、事務所、企業規模のコンピュータ・ネットワーク・イントラネットおよびインターネットでは一般的である。
【００３８】
ＬＡＮネットワーク環境で用いる場合、デスクトップ・コンピュータ１６は、ネットワーク・インターフェースまたはアダプタ８３を介して、ローカル・ネットワーク８１に接続する。ＷＡＮネットワーク環境で用いる場合、デスクトップ・コンピュータ１６は通常モデム８４またはインターネットのようなワイド・エリア・ネットワーク８２上で通信を確立するその他の手段を含む。モデム８４は、内蔵型でも外付け型でもよく、シリアル・ポート・インターフェース７６を介してシステム・バス５２に接続する。ネットワーク環境では、デスクトップ・コンピュータ１６に関して図示したプログラム・モジュールまたは同期コンポーネント２６を含むその一部を、ローカルまたはリモート・メモリ記憶装置に格納することも可能である。図示のネットワーク接続は一例であり、コンピュータ間に通信リンクを確立するその他の手段も使用可能であることは認められよう。
【００３９】
デスクトップ・コンピュータ１６は、通常不揮発性メモリ５４に格納してあるオペレーティング・システムを走らせ、演算装置４８上で実行する。アプリケーション・プログラムは、プログラム・モジュール６７、揮発性メモリまたは不揮発性メモリ内に格納することが好ましく、あるいは、フロッピ・ディスケット５９、ＣＤＲＯＭ６１から図５に示すコンポーネントのいずれかにロードしたり、ネットワーク・アダプタ８３を介してネットワークからダウンロードしたり、またはその他の適当な機構を用いてロードすることも可能である。
【００４０】
動的リンク・ライブラリ（ＤＬＬ）は、複数の実行可能機能から成り、プロセッサ４８による実行のために、メモリ内のＰＩＭと関連付けてある。プロセッサ間およびコンポーネント間のコールは、コンポーネント・オブジェクト・モデル（ＣＯＭ）を用いることにより簡便化される。端的に言うと、ＣＯＭを用いる場合、ＤＬＬのようなソフトウエア・コンポーネントは多数のインターフェースを有する。各インターフェースは、複数のメソッドを露出（ｅｘｐｏｓｅ）させる。これらのメソッドは、個々にコールして、ソフトウエア・コンポーネントが提供する異なるサービスを利用することができる。加えて、任意に１つ以上のパラメータ引数を受け取りそして返す別のソフトウエア・コンポーネントから、メソッドまたは関数を呼び出すことを可能にするインターフェースを備える。
【００４１】
一般に、特定のＰＩＭまたはその他のプログラムと関連するＤＬＬは、特定的に当該ＰＩＭと共に動作し、デスクトップ同期インターフェースを露出させるように設計してある。デスクトップ同期インターフェースは、同期プロトコルにしたがって、先に引用した米国特許出願に詳細に記載されているように機能する。一方、ＤＬＬは、ＰＩＭによって露出されたインターフェースをコールし、オブジェクト・ストア内に維持してあるオブジェクトの個々のプロパティを表わすデータにアクセスする。勿論、オブジェクト・ストア６は、図４に関して記載した適当なメモリ素子のいずれにも常駐することができる。
【００４２】
図６は、発信元２００およびモバイル・デバイス１８の更に詳細なブロック図であり、本発明の一態様による、モバイル・デバイス１８のプログラミングを示す。尚、発信元は、コンテンツまたはサービス・プロバイダ１２、またはワイヤレス・キャリア１４、またはその他のいずれかの適当なブロードキャスト・サービス・プロバイダのような、いずれかのプログラミング情報源であり得ることを注記しておく。発信元２００は暗号化コンポーネント２０２、およびプログラミング・メッセージ発振コンポーネント（ＰＭＯＣ）２０４を含む。また、図６は、発信元２００およびモバイル・デバイス１８をリンクする伝送リンク２０６も示す。前述のように、伝送リンク２０６は、ワイヤレス伝送リンク、デスクトップ・コンピュータならびに同期コンポーネント２６および２８との同期による伝送、世界的なコンピュータ・ネットワーク（インターネット等）を通じた伝送、またはモデムを介したその他のソース、イントラネット、あるいは単に必要な情報を収容したフロッピ・ディスクの転送による伝送を含むことができる。
【００４３】
また、モバイル・デバイス１８も更に詳細に示してある。モバイル・デバイス１８は、無線ハードウエア（即ち、無線ＨＷ）２０８を含み、モバイル・デバイス１８内の実際の無線受信ハードウエアに対応する。また、モバイル・デバイス１８は、無線ＨＷ２０８とインターフェースし無線ＨＷ２０８に情報を受け渡し、無線ＨＷ２０８から情報を受け取る、ドライバ２１０も含む。また、デバイス１８は、プログラミング・メッセージ処理コンポーネント（ＰＭＰＣ）２１２も含み、モバイル・デバイス１８内のいずれか適当なメモリに実装することができる。ＰＭＰＣ２１２は、伝送リンク２０６を通じて伝送されたメッセージを受信し、以下に記載する技法にしたがってこれらを処理する。
【００４４】
図７は、本発明の一形態によるモバイル・デバイス１８のプログラミングを示すフロー・チャートである。図７は、図６も参照しながら説明する。図７は、具体的に、空中プログラミングを用いてモバイル・デバイス１８をプログラムするシステムを示す。最初に、発信元２００上のＰＭＯＣ２０４が、モバイル・デバイス１８をプログラムするための所望のプログラミングを受信する。これをブロック２１４で示す。
【００４５】
次に、ＰＭＯＣ２０４は、暗号化コンポーネント２０２にアクセスし、署名し暗号化したプログラミング・メッセージを作成し、伝送リンク２０６を通じてモバイル・デバイス１８に送信する。プログラミング・データの暗号化プログラミング・メッセージへの暗号化は、多数の適当な方法のいずれでも行なうことができる。暗号化を行なう方法の１つについて、以下で図９Ａないし図１１Ｂに関して更に詳細に説明する。プログラミング・データの暗号化プログラミング・メッセージへの暗号化をブロック２１６で示す。また、データには、圧縮、符号化等のような追加の処理も行なう。
【００４６】
次に、発信元２００からモバイル・デバイス１８にデータを送信する。図６に関して説明したように、データは、適当な伝送リンクであれば、そのいずれでも送信可能である。図７において記載する実施形態に関しては、伝送リンク２０６は、無線周波数ページング・チャネルのような、ワイヤレス伝送リンクであり、ＰＭＯＣ２０４は暗号化プログラミング・メッセージを無線送信機に供給し、これがモバイル・デバイス１８の無線ＨＷ２０８に送信し、モバイル・デバイス１８においてメッセージを受信する。暗号化プログラミング・メッセージのモバイル・デバイス１８への送信は、図７のブロック２１８で示してある。
【００４７】
以下で更に詳しく説明するが、暗号化プログラミング・メッセージには、ヘッダが添付してある。メッセージは、メッセージ・ルータ・コンポーネントに渡され、これが種々の処理ステップを通じてメッセージをＰＭＰＣ２１２に導出する。ヘッダは、送信前にメッセージに行なった処理の種類、および受信後にメッセージに行なう補完処理（復号、伸長等）の種類を示す。メッセージの受信をブロック２２０で示す。
【００４８】
ルータは、メッセージをモバイル・デバイス１８上のＰＭＰＣ２１２に渡す。これをブロック２２２で示す。ＰＭＰＣ２１２は、暗号化プログラミング・メッセージに対して必要なあらゆる変換を行なう。また、ＰＭＰＣ２１２は、ヘッダ情報に基づいて、そのメッセージがプログラミング・メッセージであり、適切な入出力（Ｉ／Ｏ）制御コールを呼び出し、メッセージを適正な形態に置き、ドライバ２１０に所望のフォーマットで戻すことができるようにする。好適な実施形態では、ＰＭＰＣ２１２は、適切なアプリケーション・プログラミング・インターフェース（ＡＰＩ）を用いてドライバ２１０へのＩ／Ｏ制御コールを呼び出す。アプリケーション・プログラミング・インターフェースについては、以下で更に詳しく説明する。例えば、ヘッダ情報は、プログラミング・メッセージが新たなアドレス・プログラミング・メッセージであることを識別することができる。その場合、ＰＭＰＣ２１２は、サブパラメータＡＤＤＲＥＳＳ＿ＰＲＯＧＲＡＭＭＩＮＧを有するＲＡＤＩＯ＿ＰＲＯＧＲＡＭＭＩＮＧ  Ｉ／Ｏ制御コールを呼び出し、新たなアドレスをプログラムする。暗号化プログラミング・データをドライバ２１０に渡し、ライブラリ関数ＤｅｃｒｙｐｔＡｎｄＶａｌｉｄａｔｅＰｇｍＤａｔａ（）をコールし、プログラミング・データを解読しその有効性を確認する。プログラミング・データを適正な形式でドライバ２１０に渡す動作は、ブロック２２４で示す。
【００４９】
ドライバ２１０がプログラミング・メッセージを解読し有効性を確認した後、プログラミング・データはその元の暗号化していない形態で得られる。次に、ドライバ２１０は、検索のために、実際のプログラミング・データをドライバ２１０内の適切な出力バッファ内に置くか、あるいは無線ＨＷ２０８上の入力バッファに入力する。次いで、無線ＨＷ２０８は、供給された実際のプログラミング・データに応じて、必要なプログラミングを実行することができる。これをブロック２２６および２２８で示す。
【００５０】
図８は、空中プログラミングを用いたモバイル・デバイス１８のプログラミングを示すフロー図である。最初に、モバイル・デバイス１８のユーザは、例示の一実施形態では、ユーザが望むサービスのブロードキャスト・サービス・プロバイダのウェブ・サイトにログオンする。ユーザは、デスクトップ・コンピュータ１６から、発信元２００のウェブ・サイトにおいて、認証情報を与える。このような認証情報は、一例では、ユーザ名およびプログラミングを行なおうとするモバイル・デバイス１８の個人識別番号（ＰＩＮ）を含む。これを図８のブロック２３０で示す。
【００５１】
次に、ユーザは、モバイル・デバイス１８上で受信する加入サービスの変更を要求する。このような変更は、サービスの追加、サービスの削除、またはサービスの変更を含むことができ、アドレスまたはモバイル・デバイス１８上に格納してある他の情報の再プログラミングを要求し、モバイル・デバイス１８が新たな加入サービスを受信可能とすること、または加入サービスを取消、もはやモバイル・デバイス１８には供給しないようにするという可能性もある。ユーザは、通常、発信元のウェブサイトにアクセスしたデスクトップ・コンピュータからこの情報を得る。
【００５２】
次に、発信元２００は、署名し暗号化したプログラミング・メッセージを作成し、最終的にモバイル・デバイス１８に送信する。これについては、以下で更に詳しく説明し、ブロック２３４で示す。
【００５３】
暗号化プログラミング・メッセージを発信元２００において作成した後、伝送リンク２０６を通じてモバイル・デバイス１８に送信する。図８に示す実施形態では、伝送リンク２０６は、ユーザのデスクトップ・コンピュータと発信元のウェブサイトとの間にインターネット接続を備えている。したがって、暗号化プログラミング・メッセージは、ブロック２３６で示すように、ユーザのデスクトップ・コンピュータに転送される。
【００５４】
次に、ユーザはモバイル・デバイス１８をデスクトップ・コンピュータに接続する。前述のように、この種の接続は、シリアル通信を用いたハードウエア接続（即ち、ケーブル）、赤外線伝送リンク、または他のいずれの適当な接続機構を通じてでも、いずれかの適当な方法で形成することができる。これをブロック２３８で示す。
【００５５】
次に、ユーザは、デスクトップ・コンピュータとモバイル・デバイス１８間の同期を要求する。前述のように、同期コンポーネント２６および２８は、同期プロトコルにしたがって双方向処理を行い、暗号化プログラミング・メッセージをモバイル・デバイス１８に同期化する。更に具体的には、同期コンポーネント２８は、暗号化メッセージをモバイル・デバイス１８上のＰＭＰＣ２１２に転送する。同期ステップをブロック２４０で示す。
【００５６】
この時点から、処理は、図７に明示した空中プログラミング・システムのブロック２２４から開始して行なうのと全く同一に進展する。即ち、ＰＭＰＣ２１２は、暗号化プログラミング・メッセージに必要なあらゆる変換を実行し、暗号化プログラミング・メッセージを適正な形態とし、ドライバ２１０に渡すことを可能とする。次に、ＰＭＰＣ２１２は適切なＡＰＩを用いてドライバ２１０へのＩ／Ｏ制御コールを呼び出し、暗号化プログラミング・メッセージをドライバ２１０に逆に渡し、解読および有効性確認を行なう。これをブロック２２４で示す。
【００５７】
一旦ドライバ２１０がデータを解読し有効性を確認したなら、暗号化されていない形態のプログラミング・データを適切なバッファに入力する。これをブロック２２６で示す。
【００５８】
次に、無線ＨＷ２０８は、ドライバ２１０から受け取ったプログラミング・データにしたがって、プログラミング動作を実行する。これをブロック２２８で示す。
【００５９】
尚、モバイル・デバイス１８上で無線ＨＷ２０８をプログラミングする本システムは、プロトコル、チャネル、およびデバイスには独立であることを注記しておく。言い換えると、一旦暗号化プログラミング・メッセージをＰＭＰＣ２１２に供給したなら、その情報をドライバ２１０に供給し、ドライバ２１０においてプログラミング・メッセージを解読し有効性を確認するプロセスは全く同一であり、どのような特定の無線ＨＷデバイス２０８を備えているかには無関係であり、更にプログラミング・メッセージを受信したチャネルまたは伝送プロトコルにも無関係である。
【００６０】
図９Ａおよび図９Ｂは、発信元２００上の暗号化コンポーネント２０２およびＰＭＯＣ２０４が実行する暗号化方式の一部を示す。勿論、他の適当な暗号化方式も利用可能であるが、図９Ａおよび図９Ｂは、例示としての一暗号化方式の一部を示す。即ち、図９Ａおよび図９Ｂは、本発明の一態様による暗号化方式において用いる暗号化キーの形成を示す。
【００６１】
暗号化キーを得るために、本発明は、メッセージ特定データ２４２、ベース・キー２４４、および暗号データ２４６を用いる。メッセージ特定データ２４２は、送られる各プログラミング・メッセージと交換する、要求プロパティを有するメッセージ自体の一部であることが好ましい。ベース・キー２４４は、例示の一実施形態では、モバイル・デバイス１８の電子識別（ＥＩＤ）である。しかしながら、ベース・キー２４４は同様に他のいずれのキーとすることも可能である。暗号データ２４６は、他の既知のバイトまたはデータ・ストリングで形成することが好ましい。ブロック２４２，２４４および２４６内の情報を、ハッシュ・メッセージ認証コード（ＨＭＡＣ）発生器２４８に供給する。ＨＭＡＣ発生器２４８は、キー導出アルゴリズムをシード（ｓｅｅｄ）またはバイアス（ｂｉａｓ）するために用いるハッシュ値を導出する。このバイアス・コンポーネントをキー導出コンポーネント２５０に供給する。これは、バイアス・コンポーネントに作用し、暗号キー２５２を得る。
【００６２】
図９Ｂは、図９Ａのブロック図に示したコンポーネントの動作を示すフロー図である。最初に、メッセージ特定データ２４２、ベース・キー２４４、および暗号データ２４６を得る。これをブロック２５４、２５６および２５８で示す。次に、ＨＭＡＣバイアス・コンポーネントを算出する。これをブロック２６０で示す。最後に、バイアス・コンポーネントを用いて暗号キー２５２を得る。これをブロック２６２で示す。例示の一実施形態では、ＡＰＩ ＣｒｙｐｔＤｒｉｖｅＫｅｙを用いて暗号キーを得る。ＡＰＩ ＣｒｙｐｔＤｒｉｖｅＫｅｙは、標準的な暗号アルゴリズムのキーを得る標準的なＷｉｎｄｏｗｓ（登録商標） ＡＰＩである。
【００６３】
尚、メッセージ特定データ２４２は各メッセージ毎に変化するので、得られる暗号キー２５２も各メッセージ毎に異なることを注記しておく。この技法がない場合、暗号化メッセージを解読したメッセージと比較し、これら２つのメッセージを単純に用いて後続のメッセージのキーを計算することができる。しかしながら、キーは各メッセージ毎に変化するので、１つのキーが得られても、これを用いて後のメッセージを解読することはできない。
【００６４】
図１０Ａおよび図１０Ｂは、本発明の一態様による署名キーの発生を示す。多数のブロックには、図９Ａおよび図９Ｂに示すものと同様に付番し、更に同様に付番してある。図９Ａに示した技法の場合と同様、本発明にしたがって、多数のコンポーネントを用いて署名キー２６６を形成する。メッセージ特定データ２４２、ベース・キー２４４および署名ストリング２６４をＨＭＡＣ発生器２４８に供給する。メッセージ特定データ２４２およびベース・キー２４４については、先に図９Ａおよび図９Ｂに関して説明した。署名ストリング２６４は、暗号ストリング２４６と同様である。しかしながら、署名ストリング２６４は、他の既知のバイトで形成され、データ・ストリングとして形成することが好ましい。ＨＭＡＣ発生器２４８は、この場合もシード値即ちバイアス値を発生し、ブロック２５０で示すように、署名キーを得るために供給する。図９Ａと同様、署名キーは、標準的なＷｉｎｄｏｗｓ（登録商標） ＡＰＩであるＣｒｙｐｔＤｅｒｉｖｅＫｅｙを用いて形成し、署名キー２６６を得ることが好ましい。
【００６５】
図１０Ｂは、図１０Ａのブロック図に示すコンポーネントの動作を示すフロー図である。最初に、メッセージ特定データ２４２、ベース・キー２４４および署名データ２６４を得る。これをブロック２６８、２７０および２７２で示す。次に、ＨＭＡＣ発生器２４８は、入力コンポーネントに基づいて、バイアス・コンポーネントを算出する。これをブロック２７４で示す。
【００６６】
次に、バイアス・コンポーネントを用いて署名キー導出アルゴリズムをバイアスし、署名キー２６６を得る。これをブロック２７６で示す。
【００６７】
一旦署名キーおよび暗号キーを得たなら、伝送リンク２０６を通じた送信のためにプログラミング・メッセージを準備することができる。図１１Ａおよび図１１Ｂは、伝送リンク２０６を通じた伝送のためのプログラミング・メッセージの準備を示す。プログラミング・データ２７８および署名キー２６６をＨＭＡＣ発生器２４８に供給する。これは、プログラミング・データ２７８および署名キー２６６に基づく署名値２８０を与える。次に、ブロック２８１で示すように、ディジタル署名２８０をプログラミング・データ２７８に追加する。次に、プログラミング・データ２７８を、その署名２８０と共に、暗号キー２５２を用いて暗号化する。言い換えると、プログラング・データ２７８を、その署名２８０および暗号キー２５２と共に、暗号コンポーネント２８２に供給し、いずれかの適当な暗号化技術を用いることができる。暗号コンポーネント２８２の出力は、暗号化メッセージ２８４であり、これは、暗号キー２５２によって、その署名２８０と共に暗号化されたプログラミング・データ２７８に対応する。
【００６８】
暗号化メッセージ２８４を、暗号化されていない形態（即ち平文形態）のメッセージ特定データ２４２に添付する。暗号化メッセージ２８４およびメッセージ特定データ２４２に、ヘッダを追加する。これをブロック２８６で示す。更に、圧縮、符号化等のような別の変換をメッセージに施すことができる。したがって、プログラミング・メッセージ２８８全体は、ヘッダ２９０、暗号化メッセージ２８４、およびメッセージ特定データ２４２を含む。ヘッダ２９０は、多数の目的に供する一連のバイトであることが好ましい。最初に、メッセージ２８８をプログラミング・メッセージとして識別する。次に、メッセージの暗号化部分２８４の先頭および末尾、ならびにメッセージのメッセージ特定データ部分２４２（暗号化されていない）の先頭および末尾を識別する。最後に、ヘッダ２９０は、ＥＩＤをベース・キーとして用いたか否かを識別する。
【００６９】
図１１Ｂは、図１１Ａに関して説明したプログラミング・メッセージの準備を示すフロー図である。最初に、ブロック２９２で示すように、プログラミング・メッセージを得る。次に、署名キー２６６を得る。これをブロック２９４で示す。次に、ＨＭＡＣコンポーネントを走らせ、署名２８０を得る。これをブロック２９６で示す。
【００７０】
次に、プログラミング・データをその署名と合体する。これをブロック２９８で示す。暗号キーを得て、プログラミング・データをその署名と共に、暗号キーを用いて暗号化し、暗号化メッセージを形成する。これをブロック３００および３０２で示す。メッセージ特定データ２４２を暗号化メッセージに添付し、ヘッダを追加してプログラミング・メッセージ全体を形成し、伝送リンク２０６を通じて送信する。送信に先立って、他の変換も行なうことができる。これらの最終ステップをブロック３０４および３０６で示す。
【００７１】
準備したメッセージを伝送リンク２０６を通じて伝送し、前述のように、最終的にＰＭＰＣコンポーネント２１２に至る。一旦ＰＭＰＣ２１２がプログラミング・メッセージを受信したなら、適正な形態として、ドライバ２１０に、そして最終的に無線ＨＷ２０８に受け渡し、ここでプログラミングを実際に実行する。
【００７２】
図１２Ａは、無線ＨＷ２０８およびドライバ２１０の更に詳細なブロック図であり、これらのコンポーネントにおける処理を示すものである。図１２Ａは、無線ＨＷ２０８が好ましくは複数のデータ構造を維持することを示す。図１２Ａの無線ＨＷ２０８に示すデータ構造は、テーブルとして示している。しかしながら、これは一例としての図に過ぎない。実際には、無線ＨＷ２０８は他の何らかの方法で自由にデータを格納し、格納またはアクセス速度を最適化する。
【００７３】
また、無線ＨＷ２０８はこれらのデータ構造全てを格納する必要もない。無線ＨＷ２０８をリムーバブル・ハードウエア製品（例えば、無線ＰＣＭＣＩＡ型カード）として実現する場合、これは単純に好適な実施態様となり得る。データ構造を無線ＨＷ２０８上の不揮発性メモリに格納することによって、ユーザは一方のモバイル・デバイス１８からカードを抜き取り、それを他方に差し込んで、情報を新たなデバイスに容易に移転させることが可能となる。また、無線ハードウエアにおける機能をより多く実現することも可能にする。しかしながら、デバイス・ドライバ２１０は、これらのデータ構造をシステム・メモリに格納し、ソフトウエアで機能を実行することも可能であるが、いくつかの観点において好ましくない場合もある。
【００７４】
いずれの場合でも、図１２Ａは、無線ＨＷ２０８がキー・テーブル２１０、アドレス・テーブル３１２、グループ情報テーブル３１４、グループ・インデックス・テーブル３１６、ならびにキャリアおよび製造業者情報テーブル３１８を維持する一実施形態を示す。これらのデータ構造について以下に詳しく説明する。・アドレス・テーブル。
【００７５】
このテーブルは、アドレス関連情報を格納するために用いる。
【００７６】
【表１】
0004691252.tif 000002
【００７７】
「＊」を付けたフィールドは、揮発性メモリ（例えば、レジストリ）に格納し、無線ＨＷの不揮発性メモリのメモリ・サイズを削減することができる。これらは、サイズ算出には含んでいない。
ステータス：これはフラグ・バイトである。以下にフラグの例を示す。
【００７８】
【表２】
0004691252.tif 000003
【００７９】
ドライバは、ＡＣおよびデバイスのＯＮ／ＯＦＦステータスの変化を検出し、ＡＤＤＲＥＳＳ＿ＦＬＡＧ＿ＡＣ＿ＯＮＬＹおよびＡＤＤＲＥＳＳ＿ＦＬＡＧ＿ＰＵ＿ＯＮＬＹに基づいて、アドレスをイネーブル／ディスエーブルすることが好ましい。
【００８０】
【表３】
0004691252.tif 000004
【００８１】
全体のサイズ＝（１＋１＋２＋８＋３２）＊１６＝７０４バイト（Ｆｌｅｘ無線の場合）。
・キー・テーブル
このテーブルは、セキュリティ関連情報を格納するために用いる。これは、例示として、１つ以上のサービス・グループまたはアドレスが同じキーを共有することができる、プール・リソースである。
【００８２】
【表４】
0004691252.tif 000005
【００８３】
【表５】
0004691252.tif 000006
【００８４】
全体のサイズ＝（８＋４＋１６）＊１６＝４４８バイト
・サービス・グループ情報テーブルおよびサービス・グループ・インデックス・テーブル
サービス・グループ・テーブルは、サービス・グループに関する情報を格納する。通常、サービス・グループ・コードおよび関連するキーの参照は、サービス・グループの挿入または削除よりも、頻度が高くしかも時間に厳しいタスクである。したがって、ドライバは、これに合わせて設計したデータ構造を有することが好ましい。
【００８５】
以下に提示する実施態様では、サービス・グループ・エントリをアドレス番号で、ついでサービス・グループ・コードでソートする。別個のサービス・グループ・インデックス・テーブルが、いずれの所与のアドレスについても最後のエントリに対するインデックスを格納する。（尚、これは単に実施態様の一例に過ぎないことを注記しておく。サービス・グループ・コードの参照に最適化し、格納の必要性を極力抑える。新たなサービス・グループを定義する毎に、テーブル・エントリをシフト・ダウンし、そのための余裕を作る必要がある。しかしながら、他の適当な実施態様も同様に使用可能である。
【００８６】
例示の一実施形態では、アドレスをディスエーブルすると、そのサービス・グループ・エントリが除去されるか、いずれかの方法で変更される（しかしながら、いずれにしてもカードがそのアドレスに対するメッセージを破棄するので、これらのエントリは用いられない）。
ＫｅｙＩｎｄｅｘは、このサービス・グループに関連するキー・テーブルへのインデックスである。インデックス０は、「キーが存在しない−このサービス・グループに対するコンテンツを暗号化しない。」ことを意味するために予約してある。
【００８７】
【表６】
0004691252.tif 000007
【００８８】
「＊」を付けたフィールドは、揮発性メモリ（例えば、レジストリ）に格納し、無線ＨＷの不揮発性メモリのメモリ・サイズを削減することができる。これらは、サイズ算出には含んでいない。
ＳｅｒｖｉｃｅＧｒｏｕｐＣｏｄｅ  ０ｘ２０および０ｘ７Ｅの印刷可能なＡＳＣＩＩ範囲におけるサービス・グループ・コード。
ステータス：これは、フラグ・バイトである。以下のフラグを一例として定義する。
【００８９】
【表７】
0004691252.tif 000008
【００９０】
ドライバは、ＡＣおよびデバイスのＯＮ／ＯＦＦステータスの変化を検出し、ＧＲＯＵＰ＿ＦＬＡＧ＿ＡＣ＿ＯＮＬＹおよびＧＲＯＵＰ＿ＦＬＡＧ＿ＰＵ＿ＯＮＬＹに基づいて、アドレスをイネーブル／ディスエーブルすることが好ましい。
【００９１】
【表８】
0004691252.tif 000009
【００９２】
インデックス・テーブルは、所与のアドレスに対するサービス・グループを素早く突き止めるために用いる。
全体のサイズ＝（１＋１＋１＋２＋８）＝８３２（サービス・グループ・テーブル）
（１）＊１６＝１６（インデックス・テーブル）＝８４８バイト
図１２Ａは、ドライバ２１０がシステムに対して汎用であるが、効率またはセキュリティ向上のためにはドライバ・レベルで実行することが好ましい、所定の関数を納めたライブラリに対応することも示す。図１２Ａに示す対応ライブラリは、ＡｎａｌｙｚｅＭｅｓｓａｇｅ関数３２０、ＤｅｒｉｖｅＥｎｃｒｙｐｔｉｏｎＫｅｙ関数３２２、およびＤｅｃｒｙｐｔＡｎｄＶａｌｉｄａｔｅＲａｄｉｏＰｇｍＤａｔａ関数３２４を含む。これらの関数については、本願では後に更に詳しく説明する。
【００９３】
また、好適な実施形態では、ＰＭＰＣ２１２は、種々の動作を実行するための多数のＩ／Ｏ制御コールを呼び出すように構成してある。ドライバ２１０は、既定のシンタックスおよび動作にしたがってＩ／Ｏ制御コールに対応し、実施する。これについても、以下で説明する。
【００９４】
ドライバＡＰＩにおいて用いる一般的なタイプの定義についてこれより説明する。尚、以下のタイプの殆どは、前述のデータ構造にほぼ直接マップするが、これは必ずしも必要ではない。
【００９５】
以下の基本タイプを用いる。
【００９６】
ＢＹＴＥ符号無し８ビット
ＷＯＲＤ符号付き１６ビット
ＤＷＯＲＤ符号付き３２ビット
ＢＹＴＥアレイに格納するＴＥＸＴストリング。ストリングの長さは大抵の場合他のフィールドで使用可能であるので、ヌルの終端は不要である。
以下のタイプ定義は、ドライバが対応する必要がある最小サイズの例を示す。ＡＰＩにおいて用いるストラクト（ｓｔｒｕｃｔ）は、別のフィールドにおいて実際の長さを有する。
【００９７】
ＲＡＤＩＯ＿ＴＡＧ  ストラクト
ＴＥＸＴ値［８］  タグを用いて個々のアドレス、サービス・グループ、またはキー・エントリを識別する。
【００９８】
ＲＡＤＩＯ＿ＫＥＹ  ストラクト
ＢＹＴＥ値［１６］  暗号キーを格納する。
【００９９】
ＲＡＤＩＯ＿ＮＡＭＥストラクト
ＴＥＸＴ値［３２］  キャリア名、製造業者名、アドレス名等を格納する。
【０１００】
ＲＡＤＩＯ＿ＤＥＳＣストラクト
ＴＥＸＴ値［６４］  カード、サービス、アドレス等の記載を格納する。
複素タイプ（ストラクト）
全ての構造は、最初に以下の２つのフィールドを有する。
Ｗｏｒｄ  ｓＳｔｒｕｃｔＳｉｚｅ  各ストラクトは固定サイズのフィールドを有し、その後に可変フィールドの長さが続く。可変フィールドはそれらの長さと同じ順序に従う。ｗＳｔｒｕｃｔＳｉｚｅフィールドは、ストラクトの固定部分のサイズをバイト単位で保持する（即ち、固定フィールドおよび可変フィールドの長さ）。このフィールドは、今後のリリースにおける下位互換性のために用いる、バージョン付け方法（ｖｅｒｓｉｏｎｉｎｇ  ｍｅｔｈｏｄ）も同様に与える。
ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどの固定サイズ・フィールドが有効でありかつ使用可能かを（可変サイズ・フィールドに対して）示すマスク（０の長さはフィールドが存在しないことを示す）。これによって、フィールドの一部が不要であっても、同じストラクトを用いることが可能となる。これは、他のフィールドの値を変更せずに、ストラクト内の単一フィールドをプログラムする場合に特に有用である。
加えて、可変長フィールドを終端側に集合化し、それらの各々に長さフィールドを備える。これによって、下位または上位互換性を失うことなく、これらの構造の拡張が可能となる。可変長フィールドにアクセスする場合、ドライバはｗＳｔｒｕｃｔＳｉｚｅフィールドの値を、最初の可変長フィールドの開始オフセットとして用いなければならない。これによって、追加のフィールドをストラクトに追加した場合に、上位互換性に対処する（ｗＳｔｒｕｃｔＳｉｚｅの使用は、これら新たなフィールドが旧来のドライバによって無視されることを保証する）。
ドライバＡＰＩの通常の動作では、多種多様の特定的なストラクト・タイプを用いるが、ここでは、プログラミングに関連するものについてのみ論ずることにする。このようなストラクトは以下を含む。
ストラクト  ＲＡＤＩＯ  ＡＤＤＲＥＳＳ
このストラクトは、アドレスに関する情報を収容する。
【０１０１】
【表９】
0004691252.tif 000010
【０１０２】
Ｗｏｒｄ  ｗＳｔｒｕｃｔＳｉｚｅ  ｓｅｉｚｅｏｆ（ＲＡＤＩＯ＿ＡＤＤＲＥＳＳ）
ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどのフィールドが有効かを示すマスク。以下の１つ以上のＯＲを取ることによって、値を構築する。
【０１０３】
０ｘ０００１  ＡｄｄｒｅｓｓＮｕｍｂｅｒフィールドが有効である。
【０１０４】
０ｘ０００２  Ｓｔａｔｕｓフィールドが有効である。
【０１０５】
０ｘ０００４  ＥｘｐｉｒａｔｉｏｎＤａｔｅフィールドが有効である。
ＢＹＴＥ  ＡｄｄｒｅｓｓＮｕｍｂｅｒ  アドレス・エントリ番号・アドレス・エントリには、０から付番する。
ＢＹＴＥ  Ｓｔａｔｕｓ  ステータス・フラグ
ＢＹＴＥ  ＥｘｐｉｒａｔｉｏｎＤａｔｅ［２］  期限日。ない場合は０。
ＢＹＴＥ  ＡｄｄｒｅｓｓＴａｇＬｅｎ  ＡｄｄｒｅｓｓＴａｇフィールドの長さ。
ＢＹＴＥ  ＫｅｙＴａｇＬｅｎ  ＫｅｙＴａｇフィールドの長さ。
ＢＹＴＥ  ＡｄｄｒｅｓｓＮａｍｅＬｅｎ  ＡｄｄｒｅｓｓＮａｍｅフィールドの長さ。
ＷＯＲＤ  ｗＡｄｄｒｅｓｓＤｅｓｃｒｉｐｔｉｏｎＬｅｎ  ＡｄｄｒｅｓｓＤｅｓｃｒｉｐｔｉｏｎフィールドの長さ。
ＷＯＲＤ  ｗＡｄｄｒｅｓｓＩｎｆｏＬｅｎ  ＡｄｄｒｅｓｓＩｎｆｏフィールドの長さ。
ＲＡＤＩＯ＿ＴＡＧ  ＡｄｄｒｅｓｓＴａｇ  アドレス・タグ。
ＲＡＤＩＯ＿ＴＡＧ  ＫｅｙＴａｇ  このアドレスに関連するキー。（このフィールドがない場合、アドレスに関連付けられたキーはない）。
ＲＡＤＩＯ＿ＤＥＳＣ  ＡｄｄｒｅｓｓＤｅｓｃｒｉｐｔｉｏｎ  アドレスについての説明。尚、この情報は、一例として、不揮発性メモリ内にある必要はないものとすることを注記しておく。これは、情報の目的のためにのみ、ユーザに表示する。
ＲＡＤＩＯ＿ＡＤＤＲＥＳＳ  ＡｄｄｒｅｓｓＩｎｆｏ  アドレスおよび関連情報フィールド。このストラクトは、プロトコルに特定である。ＦＬＥＸプロトコルでは、キャップコード情報符号化転化値、位相、アドレス等を含むことができる。
ストラクト  ＲＡＤＩＯ＿ＧＲＯＵＰ
このストラクトは、サービス・グループに関する情報を収容する。
【０１０６】
【表１０】
0004691252.tif 000011
【０１０７】
ＷＯＲＤ  ｗＳｔｒｕｃｔＳｉｚｅ  ｓｉｚｅｏｆ（ＲＡＤＩＯ＿ＧＲＯＵＰ）ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどのフィールドが有効かを示すマスク。以下の１つ以上のＯＲを取ることによって、値を構築する。
【０１０８】
０ｘ０００１  ＧｒｏｕｐＮｕｍｂｅｒフィールドが有効である。
【０１０９】
０ｘ０００２  Ｓｔａｔｕｓフィールドが有効である。
【０１１０】
０ｘ０００４  ＧｒｏｕｐＣｏｄｅフィールドが有効である。
【０１１１】
０ｘ０００８  ＥｘｐｉｒａｔｉｏｎＤａｔｅフィールドが有効である。
ＷＯＲＤ  ｗＧｒｏｕｐＮｕｍｂｅｒ  サービス・グループ番号。サービス・グループには、０から付番する。
ＢＹＴＥ  Ｓｔａｔｕｓ  ステータス・フラグ
ＢＹＴＥ  ＧｒｕｕｐＣｏｄｅ  サービス・グループ・コード。
ＢＹＴＥ  ＥｘｐｉｒａｔｉｏｎＤａｔｅ［２］  期限日。なければ０である。ＢＹＴＥ  ＧｒｏｕｐＴａｇＬｅｎ  ＧｒｏｕｐＴａｇフィールドの長さ。
ＢＹＴＥ  ＫｅｙＴａｇＬｅｎ  ＫｅｙＴａｇフィールドの長さ。
ＢＹＴＥ  ＡｄｄｒｅｓｓＴａｇＬｅｎ  ＧｒｏｕｐＴａｇフィールドの長さ。
ＢＹＴＥ  ＧｒｏｕｐＮａｍｅＬｅｎ  ＧｒｏｕｐＮａｍｅフィールドの長さ。
ＷＯＲＤ  ｗＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎＬｅｎ  ＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎフィールドの長さ。
ＲＡＤＩＯ＿ＴＡＧ  ＧｒｏｕｐＴａｇ  サービス・グループ・タグ。
ＲＡＤＩＯ＿ＴＡＧ  ＫｅｙＴａｇ  このサービス・グループの関連キー。（このフィールドがない場合、サービス・グループに関連付けられたキーはない）。ＲＡＤＩＯ＿ＴＡＧ  ＡｄｄｒｅｓｓＴａｇ  このサービス・グループが属するアドレス。
ＲＡＤＩＯ＿ＤＥＳＣ  ＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎ  サービス・グループについての説明。尚、この情報は、一例として、不揮発性メモリ内にある必要はないものとすることを注記しておく。これは、情報の目的のためにのみ、ユーザに表示する。
ストラクト  ＲＡＤＩＯ＿ＫＥＹ
このストラクトは、暗号キーに関する情報を収容する。
【０１１２】
【表１１】
0004691252.tif 000012
【０１１３】
ＷＯＲＤ  ｓＷｔｒｕｃｔＳｉｚｅ  ｓｅｚｅｏｆ（ＲＡＤＩＯ＿ＫＥＹ）
ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどのフィールドが有効かを示すマスク。以下の１つ以上のＯＲを取ることによって、値を構築する。
【０１１４】
０ｘ０００１  ＫｅｙＮｕｍｂｅｒＮｕｍｂｅｒフィールドが有効である。
【０１１５】
０ｘ０００２  ｄｗＡｌｇＣｏｄｅフィールドが有効である。
ＢＹＴＥ  ＫｅｙＮｕｍｂｅｒ  キー番号。キーには１から付番する。
ＤＷＯＲＤ  ｄｗＡｌｇＣｏｄｅ  暗号アルゴリズム・コード。
ＢＹＴＥ  ＫｅｙＴａｇＬｅｎ  ＫｅｙＴａｇフィールドの長さ。
ＢＹＴＥ  ＫｅｙＬｅｎ  キー・フィールドの長さ。
ＲＡＤＩＯ＿ＴＡＧ  ＫｅｙＴａｇ  キー・タグ。
ＲＡＤＩＯ＿ＫＥＹ  Ｋｅｙ  暗号キー。
ストラクト  ＲＡＤＩＯ＿ＰＧＭ
このストラクトは、アドレス、サービス・グループ、キー等をプログラムするために用いる。
【０１１６】
【表１２】
0004691252.tif 000013
【０１１７】
ＷＯＲＤ  ｗＳｔｒｕｃｔＳｉｚｅ  ｓｉｚｅｏｆ（ＲＡＤＩＯ＿ＰＧＭ）
ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどのフィールドが有効かを示すマスク。以下の１つ以上のＯＲを取ることによって、値を構築する。
【０１１８】
０ｘ０００１  ＯｐｅｒａｔｉｏｎＣｏｄｅフィールドが有効である。
【０１１９】
０ｘ０００２  ＴｙｐｅＣｏｄｅフィールドが有効である。
ＢＹＴＥ  ＯｐｅｒａｔｉｏｎＣｏｄｅ  実行する動作を定義する。可能な値は次の通りである。
【０１２０】
０ｘ０１  ＲＡＤＩＯ＿ＰＲＧ＿ＯＰＥＲＡＴＩＯＮ＿ＰＲＯＧＲＡＭ  プログラム
０ｘ０２  ＲＡＤＩＯ＿ＰＧＭ＿ＯＰＥＲＡＴＩＯＮ＿ＵＮＰＲＯＧＲＡＭ  アンプログラム（ｕｎｐｒｏｇｒａｍ）
ＢＹＴＥ  ＴｙｐｅＣｏｄｅ  実行するプログラミングのタイプ。可能な値は次の通りである。
【０１２１】
０ｘ０１  ＲＡＤＩＯ＿ＰＧＭ＿ＴＹＰＥ＿ＣＡＲＲＩＥＲ  ＲＡＤＩＯ＿ＣＡＲＲＩＥＲストラクトが続く。
【０１２２】
０ｘ０２  ＲＡＤＩＯ＿ＰＧＭ＿ＴＹＰＥ＿ＫＥＹ  ＲＡＤＩＯ＿ＫＥＹストラクトが続く。
【０１２３】
０ｘ０３  ＲＡＤＩＯ＿ＰＧＭ＿ＴＹＰＥ＿ＡＤＤＲＥＳＳ  ＲＡＤＩＯ＿ＡＤＤＲＥＳＳ  ストラクトが続く。
【０１２４】
０ｘ０４  ＲＡＤＩＯ＿ＰＧＭ＿ＴＹＰＥ＿ＧＲＯＵＰ  ＲＡＤＩＯ＿ＧＲＯＵＰストラクトが続く。
ＷＯＲＤ  ｗＰｒｏｇｒａｍＤａｔａＬｅｎ  ＰｒｏｇｒａｍＤａｔａフィールドの長さ
ＷＯＲＤ  ｗＣｈｅｃｋＳｕｍＬｅｎ  ２  （チェックサム・フィールドの長さ、必須ではないが、一貫性のために定義する）
ｖｏｉｄ  ＰｒｏｇｒａｍＤａｔａ  以下のデータ構造の１つ（ＴｙｐｅＣｏｄｅに基づく）：
ＲＡＤＩＯ＿ＣＡＲＲＩＥＲ  ＣａｒｒｉｅｒＩｎｆｏ；
ＲＡＤＩＯ＿ＡＤＤＲＥＳＳ  ＡｄｄｒｅｓｓＩｎｆｏ；
ＲＡＤＩＯ＿ＧＲＯＵＰ  ＧｒｏｕｐＩｎｆｏ；
ＲＡＤＩＯ＿ＫＥＹ  ＫｅｙＩｎｆｏ；
ＷＯＲＤ  ｗＣｈｅｃｋＳｕｍ  Ｃｈｅｃｋｓｕｍフィールド自体を除くストラクト全体のチェックサム。チェックサムを算出するには、ＷＯＲＤ内のバイトを１つずつストラクト全体で加算し、オーバーフローを無視する。
ストラクト  ＲＡＤＩＯ＿ＣＲＹＰＴ
このストラクトは、制御コールに関連する暗号機能性のために用いる。
【０１２５】
【表１３】
0004691252.tif 000014
【０１２６】
ＷＯＲＤ  ｗＳｔｒｕｃｔＳｉｚｅ  ｓｉｚｅｏｆ（ＲＡＤＩＯ＿ＣＲＹＰＴ）ＤＷＯＲＤ  ｄｗＭｅｍｂｅｒＶａｌｉｄＭａｓｋ  ストラクトのどのフィールドが有効かを示すマスク。以下の１つ以上のＯＲを取ることによって、値を構築する。
【０１２７】
０ｘ０００１  ｈＣｒｙｐｔｏＰｒｏｖフィールドが有効である。
【０１２８】
０ｘ０００２  ｄｗＣｒｙｐｔｏＦｌａｇｓフィールドが有効である。
【０１２９】
０ｘ０００４  ｄｗＣｒｙｐｔｏＡｌｇＩｄフィールドが有効である。
ＨＣＲＹＰＴＰＲＯＶ  ｈＣｒｙｐｔｏＰｒｏｖ  暗号サービス・プロバイダへのハンドル。
ＤＷＯＲＤ  ｄｗＣｒｙｐｔｏＡｌｇＩｄ  暗号アルゴリズムＩＤ。例えば、ＣＡＬＧ＿ＲＣ４。
ＤＷＯＲＤ  ｄｗＣｒｙｐｔｏＦｌａｇｓ  暗号関数ＣｒｙｐｔＤｅｒｉｖｅＫｅｙ（）のフラグ。例えば、ＣＲＹＰＴ＿ＥＸＰＯＲＴＡＢＬＥ。
ＢＹＴＥ  ＡｄｄｒｅｓｓＴａｇＬｅｎ  ＡｄｄｒｅｓｓＴａｇフィールドの長さ。ＲＡＤＩＯ＿ＴＡＧ  ＡｄｄｒｅｓｓＴａｇ  アドレス・タグ。
ＲＡＤＩＯ＿ＴＡＧ  ＧｒｏｕｐＴａｇ  サービス・グループ・タグ。
ＢＹＴＥ  ＭｓｇＳｐｅｃｉｆｉｃＤＡＴＡ［］  メッセージ特定データ
前述のように、Ｉ／Ｏ制御コールは、ＰＭＰＣ２１２からドライバ２１０に行い、所定の動作を実行する。種々のデータ構造の場合と同様に、ドライバＡＰＩにおいて種々のＩ／Ｏ制御コールに対応する。しかしながら、ドライバ２１０および無線カード２０８のプログラミングに関連するものについてのみ、ここでは論ずることにする。Ｉ／Ｏ制御コールは、次のシンタックスを有する。
【０１３０】
0004691252.tif 000015
パラメータ
【０１３１】
【表１４】
0004691252.tif 000016
【０１３２】
戻り値
デバイスがその指定Ｉ／Ｏ制御動作を完了し終えた場合、ＴＲＵＥを戻す。それ以外の場合、ＦＡＬＳＥを戻す。
ＲＡＤＩＯ＿ＰＲＯＧＲＡＭ
このＩＯＣＴＬコールは、コール元がアドレス、サービス・グループ、キー、またはキャリア情報をプログラムすること、プログラムを取り消すこと（ｕｎ−ｐｒｏｇｒａｍ）を許可する。
【０１３３】
0004691252.tif 000017
動作
ドライバは所与の項目をプログラムするか、プログラムを取り消す。セキュリティ上の理由のため、このＡＰＩに渡すＲａｄｉｏＰｇｍストラクトは常に暗号化する。ドライバは、一例として、ドライバ支援ライブラリに含まれる関数ＤｅｃｒｙｐｔＡｎｄＶａｌｉｄａｔｅＲａｄｉｏＰｇｍＤａｔａ（）をコールし、入力データを解読し、有効性を確認しなければならない。
注記
プログラミング動作を実行する場合（ＲａｄｉｏＰｇｍ．ＯｐｅｒａｔｉｏｎＣｏｄｅ＝ＲＡＤＩＯ＿ＰＧＭ＿ＯＰＥＲＡＴＩＯＮ＿ＰＲＯＧＲＡＭ）、情報ストラクトが必要なフィールド全てを有していない場合、ドライバは次のようにコマンドを処理する。
１．プログラムする項目が既に存在する場合、情報ストラクトに存在するフィールドのみを変更する。情報ストラクトにないフィールドはその古い値を保持する。例えば、アドレスをプログラムする場合、アドレスが既に存在し、ＡｄｄｒｅｓｓＤｅｓｃｒｉｐｔｉｏｎが情報ストラクトにないのであれば、このフィールドの古い値を保持する。これは、項目全体または個々のフィールドを変更することを可能にする。
２．プログラムする項目が存在する場合、ないフィールドに応じて、デフォルト値を取るか、あるいはプログラミング・コマンド全体を拒絶しなければならない。
新たなキャリアのプログラミング
【０１３４】
【表１５】
0004691252.tif 000018
【０１３５】
新たなアドレスのプログラミング
【０１３６】
【表１６】
0004691252.tif 000019
【０１３７】
新たなアドレスをプログラムする場合、ＡｄｄｒｅｓｓＮｕｍｂｅｒは不要であるが（次に得られる空エントリを用いる）、ＡｄｄｒｅｓｓＴａｇは実例では必要である。既存のアドレスを変更する場合、ＡｄｄｒｅｓｓＮｕｍｂｅｒまたはＡｄｄｒｅｓｓＴａｇを用いて所望のアドレスを指示する。双方共与えられている場合、ＡｄｄｒｅｓｓＮｕｍｂｅｒを用いる。
新たなサービス・グループのプログラミング
【０１３８】
【表１７】
0004691252.tif 000020
【０１３９】
新たなサービス・グループをプログラムする場合、ＷＧｒｏｕｐＮｕｍｂｅｒは不要であるが（次に得られる空エントリを用いる）、ＧｒｏｕｐＴａｇは実例では必要である。既存のサービス・グループを変更する場合、ＧｒｏｕｐＮｕｍｂｅｒまたはＧｒｏｕｐＴａｇを用いて所望のアドレスを指示する。双方共与えられている場合、ＧｒｏｕｐＮｕｍｂｅｒを用いる。
新たなキーのプログラミング
【０１４０】
【表１８】
0004691252.tif 000021
【０１４１】
新たなキーをプログラムする場合、ＫｅｙＮｕｍｂｅｒは不要であるが（次に得られる空エントリを用いる）、ＫｅｙＴａｇは実例では必要である。既存のサービス・グループを変更する場合、ＫｅｙＮｕｍｂｅｒまたはＫｅｙＴａｇを用いて所望のアドレスを指示する。双方共与えられている場合、ＫｅｙＮｕｍｂｅｒを用いる。
ＲＡＤＩＯ＿ＣＲＹＰＴ＿ＤＲＩＶＥ＿ＫＥＹ
このＩＯＣＴＬコールは、コール元が、アドレス、サービス・グループ、キー、またはキャリア情報をプログラムすること、またはプログラムを取り消すことを許可する。
【０１４２】
0004691252.tif 000022
動作
このＩ／Ｏ制御は、システムのセキュリティ・コンポーネントが用いる。キーへのハンドルを得るために用いる。これは、実例では、ドライバ外部には明示されてはならない電子ＩＤ（ＥＩＤ）へのアクセスを必要とする。関数ＤｅｒｉｖｅＥｎｃｒｙｐｔｉｏｎＫｅｙ（）が、実例ではドライバ支援ライブラリに用意されており、このＩ／Ｏ制御の動作を実行するために、以下で詳細に論ずる。ドライバはこの関数をコールし、それによって戻されるキー（ｈＫｅｙ）へのハンドルを渡さなければならない。このように、セキュリティ・コンポーネントは、ＥＩＤへのアクセスを得ることなく、キーへのハンドルを得ることができる。
Ｉ／Ｏ制御コールを実現するために、ドライバ２１０は、その支援ライブラリに格納してある多数の関数をコールする。このような関数について以下に記載する。
0004691252.tif 000023
ｐＭｓｇ    メッセージ・バイトへのポインタ
ｄｗＭｓｇＬｅｎ    メッセージの長さ
ｐＤｉｓｃａｒｄ    メッセージを破棄するか維持するかについて示すＢＯＯＬ値を受け取る。
【０１４３】
ｐＳｅｒｖｉｃｅＧｒｏｕｐＣｏｄｅは、サービス・グループ・コードを受け取る。
【０１４４】
戻り
サービス・グループ・コードを見つけた場合ＴＲＵＥを戻し、それ以外の場合ＦＡＬＳＥを戻す。
【０１４５】
説明
この関数は、メッセージを分析し、それがサービス・グループ・コードを有するか否かについて判定を行なう。また、他の特性についても分析し、このメッセージを維持するかまたは破棄するかについての判定を行なう。
0004691252.tif 000024
この関数に対するパラメータの一部は、コール元によって与えられ、ドライバは単にそれらをこの関数に渡す。残りのパラメータは、その内部データ構造において、ドライバが得ることができる。
ｐＣｒｙｐｔ＿Ｉｎｐｕｔ  ＲＡＤＩＯ＿ＣＲＹＰＴ＿ＤＥＲＩＶＥ＿ＫＥＹ  ＩＯＣＴＬコールへの入力。
【０１４６】
ｐｂＫｅｙＶａｌｕｅ  ＲＡＤＩＯ＿ＣＲＹＰＴ構造内のＡｄｄｒｅｓｓＴａｇおよびＧｒｏｕｐＴａｇフィールドに基づいて用いる必要があるキー（ＩＯＣＴＬコールへのコール元はこれら２つのフィールドを与え、ドライバはこれらを用いてキー・テーブルに格納されているキーを突き止め、次いでキーをｐｂＫｅｙパラメータに渡す必要がある）。
【０１４７】
ｄｗＫｅｙＳｉｚｅ  ｐｂＫｅｙＶａｌｕｅパラメータ内のバイト数。
戻り
この関数は、動作が成功した場合ＴＲＵＥを戻し、それ以外の場合ＦＡＬＳＥを戻す。成功の場合、与えられた情報から生成したキーに対するハンドルも戻す。
説明
暗号キーは、実例では、１つ以上の以下の情報に基づいて得られる。即ち、アドレスに関連するキー、サービス・グループに関連するキー、メッセージ特定データ、所定のフラグ、およびアルゴリズムＩＤである。この関数はこの全てを処理し、コールするプロセスが用いて暗号／解読動作を実行するキーに対するハンドルを生成する。
0004691252.tif 000025
【０１４８】
ｄｗＩｎＬｅｎ  渡したプログラミング・ストラクトのサイズ。
【０１４９】
ｐＫｅｙ  デバイスの電子ＩＤ（ＥＩＤ）またはキー・テーブル内の有効なキーとすることができるキーを保持するバッファへのポインタ。
【０１５０】
ｄｗＫｅｙＬｅｎ  渡したキーのサイズ。
【０１５１】
ｐＯｕｔＢｕｆ  解読したストラクトを受け取る出力バッファへのポインタ。
【０１５２】
ｄｗＯｕｔＬｅｎ  出力バッファのサイズ。ｄｗＩｎＬｅｎ以上でなければならない。
【０１５３】
ｐｄｗＡｃｔｕａｌＯｕｔ  実際に出力バッファに書き込んだバイト数を受け取る。
戻り
この関数は、入力ストラクトが有効なストラクトである場合ＴＲＵＥを戻す。解読したストラクトを出力バッファに入力する。データが適正に暗号化されていなかったことを関数が発見した場合、ＦＡＬＳＥを戻し、ドライバはプログラミング・コマンドを拒絶しなければならない。
【０１５４】
説明
ドライバ・プログラミングＡＰＩは、それに渡されるプログラミング情報が暗号化されていることを要求する。これによって、許可されたソースのみがデバイスをプログラムできることを確保する。この関数は、ドライバのＲＡＤＩＯ＿ＰＲＯＧＲＡＭ  ＩＯ制御コールに対する解読および有効性確認を行なう。
図１２Ｂは、無線ＨＷ２０８をプログラムする際の、ＰＭＰＣ２１２およびドライバ２１０の動作を示すフロー図である。最初に、適当な変換を行なった後、ＰＭＰＣ２１２に、図７および図８に関して先に説明した方法の１つで、プログラミング・メッセージを供給する（メッセージ・ルータを通じて）。ＰＭＰＣ２１２は、次に、ヘッダ情報に基づいて、メッセージがプログラミング・メッセージであることを検出し、適切なＩＯ制御コールを呼び出し、前述のデータ構造およびＩ／Ｏ制御コール・シンタックスに応じて、プログラミング・メッセージからの情報を適正な形態とする。これをブロック３２６で示す。
【０１５５】
次に、ＰＭＰＣ２１２は、ドライバ２１０に対するＲＡＤＩＯ＿ＰＲＯＧＲＡＭ制御コールを実行し、前述のように、Ｒａｄｉｏ＿Ｐｇｍストラクトを供給する。これをブロック３３４で示す。
【０１５６】
この制御コールに応答して、ドライバ２１０は、ドライバ支援ライブラリに格納してある、ＤｅｃｒｙｐｔＡｎｄＶａｌｉｄａｔｅＲａｄｉｏＰｇｍＤａｔａ関数３２４をコールする。この関数は、ＲＡＤＩＯ＿ＰＲＯＧＲＡＭ  Ｉ／Ｏ制御コール内に与えられているプログラム・メッセージを解読する。この関数が、入力ストラクトが有効なストラクトであったことを発見した場合、ＰＭＰＣ２１２に真値を戻し、解読したストラクトをその出力バッファに入力し、無線ＨＷ２０８によるアクセスを可能にする。この関数が、ストラクトが適正に暗号化されていなかったことを発見した場合、偽値を戻し、プログラミング・コマンドを拒絶する。これをブロック３３６および３３８で示す。
【０１５７】
使用する個々の無線ＨＷ２０８をプログラムするように構成したプログラミング・コンポーネントは、次にドライバ２１０の出力バッファ内にある情報にアクセスし、所望のプログラミング関数を実行する。
【０１５８】
尚、無線ＨＷ２０８に与える実際のプログラミング・データは、固有の形態に応じて与えることができ、無線ＨＷ２０８の実際のプログラミングは、いずれかの固有のパラメータまたは製造業者が賦課した制約にしたがって行なうことができる。したがって、製造業者は、いずれかの固有の方法に応じて、あらゆるプログラミング動作を自由に定義することができる。しかしながら、先に定義したデータ構造に対応することによって、無線ＨＷ２０８が用いる特定のプログラミング方式には無関係に、そしてプログラミング・メッセージをモバイル・デバイス１８に送信する特定の方法には無関係に、独立したオープン・アーキテクチャとして、無線ＨＷ２０８に固有のプログラミング・データを供給することができる。
【０１５９】
このデバイス／プロトコル／ネットワーク独立性が与えられても、なおも障害が１つ残る。現在、モバイル・デバイス１８が実際にプログラミング・メッセージを受信したか否かについて判定し、要求されたプログラミング動作を引き受ける効率的な方法がない。本発明の一実施形態によるシステムは、この障害にも対処する。
【０１６０】
一旦ドライバ２１０が、プログラミングが完了したことを示し、有効なストラクトを収容したプログラミング・メッセージを示す値を戻したなら、ＰＭＰＣ２１２は、発信元２００に向けて承認メッセージを発生し、プログラミングが行われたことを示すことが好ましい。このメッセージを、モバイル・デバイス１８上の同期コンポーネント２８（図１に示す）に供給する。ユーザがモバイル・デバイス１８をデスクトップ・コンピュータ１６に次回接続するとき、同期コンポーネント２６および２８は協働してデスクトップ・コンピュータ１６への承認の同期を取る。デスクトップ・コンピュータ１６が次回プログラミング・メッセージの発信元２００にアクセスするとき、発信元２００に承認メッセージを送信し、プログラミングが行われたことを示す。デスクトップ・コンピュータ１６にＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ４．０のようなウェブ・ブラウザを備えてある場合、Ｅ部・ブラウザが次にスケジューラを呼び出し発信元とのインターネット接続を確立する場合に、承認メッセージを発信元２００に返送する。
【０１６１】
このように、本発明は、モバイル・デバイス１８をプログラムすることができるデバイス／プロトコル／ネットワークに独立した機構を提供することが分かる。また、本発明は、発信元２００からモバイル・デバイス１８に暗号化し安全に送ることができるようにデータを暗号化する方法も提供する。この機構により、発信元は、アドレス、グループ、キー、有効期間、およびマクロタグを含む、モバイル・デバイス１８のあらゆる適当な部分をプログラムすることが可能となる。また、本発明は、発信元に、プログラミングが完了した承認を供給するバックチャネル確認も与える。
【０１６２】
以上好適な実施形態を参照しながら本発明について説明してきたが、本発明の精神および範囲から逸脱することなく、形態および詳細において変更が可能であることを当業者は認めよう。
【図面の簡単な説明】
【図１】  本発明によるシステムにおけるモバイル・デバイスの一実施形態を示す簡略ブロック図である。
【図２】  図１に示すモバイル・デバイスの一実施形態の更に詳細なブロック図である。
【図３】  図２に示すモバイル・デバイスの一実施形態の簡略構成図である。
【図４】  図２に示すモバイル・デバイスの別の実施形態の簡略構成図である。
【図５】  本発明の一態様によるデスクトップ・コンピュータの一実施形態のブロック図である。
【図６】  本発明の一態様による、発信元およびモバイル・デバイスの更に詳細なブロック図である。
【図７】  本発明の一態様による空中プログラミングを示すフロー図である。
【図８】  インターネットのようなグローバル・ネットワーク、またはワールド・ワイド・ウェブを用いた、モバイル・デバイスのプログラミングを示すフロー図である。
【図９Ａ】  本発明の一態様による暗号化方式の一部を示す図である。
【図９Ｂ】  本発明の一態様による暗号化方式の一部を示す図である。
【図１０Ａ】  本発明の一態様による暗号化方式の別の部分を示す図である。
【図１０Ｂ】  本発明の一態様による暗号化方式の別の部分を示す図である。
【図１１Ａ】  本発明の一態様によるプログラミング・メッセージの準備を示す図である。
【図１１Ｂ】  本発明の一態様によるプログラミング・メッセージの準備を示す図である。
【図１２Ａ】  本発明の一態様によるモバイル・デバイス上でのプログラミング・メッセージの処理を示す図である。
【図１２Ｂ】  本発明の一態様によるモバイル・デバイス上でのプログラミング・メッセージの処理を示す図である。
【図１】
0004691252.tif 000026
【図２】
0004691252.tif 000027
【図３】
0004691252.tif 000028
【図４】
0004691252.tif 000029
【図５】
0004691252.tif 000030
【図６】
0004691252.tif 000031
【図７】
0004691252.tif 000032
【図８】
0004691252.tif 000033
【図９Ａ】
0004691252.tif 000034
【図９Ｂ】
0004691252.tif 000035
【図１０Ａ】
0004691252.tif 000036
【図１０Ｂ】
0004691252.tif 000037
【図１１Ａ】
0004691252.tif 000038
【図１１Ｂ】
0004691252.tif 000039
【図１２Ａ】
0004691252.tif 000040
【図１２Ｂ】
0004691252.tif 000041