JP2008518528A - 無線通信ネットワークと関連ネットワークおよびそのコンピュータ・プログラム生成物を介して無線端末を設定する方法 - Google Patents

Abstract

通信システムに従い動作する通信ネットワークを介して再設定可能な無線端末を設定する方法であって、通信システムを用いて通信ネットワークの少なくとも１個のノードと情報を交換すべく無線端末が設定されている。本方法は、通信ネットワークの１個のノードに、通信システムのプロトコル層（ＲＲ、ＧＭＭ）を用いるべく、且つ無線端末（ＭＳ）を再設定するのに適したプロトコル・スタックの少なくとも一組の要素により無線端末（ＵＥ／ＭＳ）を設定するための一組の基本ソフトウェア・モジュールを含めるべく設定されたサーバ・エンティティ（ＯＴＡサーバ）を関連付けるステップと、無線端末（ＭＳ）に、サーバ・エンティティ（ＯＴＡサーバ）のプロトコル層（ＲＲ、ＧＭＭ）に対応する各々のプロトコル層を用いるべく設定されたクライアント・エンティティ（ＯＴＡクライアント）を関連付けるステップと、プロトコル層を用いて、無線端末（ＵＥ／ＭＳ）とサーバ（ＯＴＡサーバ）エンティティとの間に地上波接続を確立するステップと、無線端末（ＵＥ／ＭＳ）を少なくとも部分的に設定すべく、基本ソフトウエア・モジュールの組の少なくとも１個のモジュールをサーバ（ＯＴＡサーバ）から無線端末（ＵＥ／ＭＳ）へダウンロードするステップとにより特徴付けられている。

Description

本発明は一般に、無線通信ネットワークおよび無線通信ネットワークを用いる再設定可能な無線端末に関する。

より具体的には、本発明は無線端末の再設定に注目し、前記再設定は、無線通信ネットワークから地上波（ＯＴＡ）を介してダウンロードした基本ソフトウェアを前記無線端末にインストールすることにより実行される。

文献（Ｊ．ミトラ（Ｍｉｔｏｌａ）、「ソフトウェア無線アーキテクチャ」、ＩＥＥＥ 通信学会誌、１９９５年５月、およびＥ．ブラッチーニ（Ｂｕｒａｃｃｈｉｎｉ）、「ソフトウェア無線の概念」、ＩＥＥＥ通信学会誌、２０００年９月）により、端末、基地局、およびネットワーク・ノード等の再設定可能なシステムは、基本動作モードが再設定可能な設備であることが知られている。例えば、ＧＳＭ／ＧＰＲＳ（移動通信用グローバルシステム／汎用パケット無線サービス）等の第二世代システム（２Ｇ）で動作できる再設定可能な無線端末は、ＵＭＴＳ（ユニバーサル移動電気通信システム）またはＣＤＭＡ２０００（符号分割多重アクセス２０００）等の第三世代システム（３Ｇ）、ＤＶＢ−Ｔ（デジタルビデオ地上波放送）、またはＷＬＡＮ（無線ローカル・エリア・ネットワーク）システム等で動作可能にすべく再設定することが可能である。

本開示において、用語「システム」は、例えば通信ネットワークとして動作する特定の機能を実行すべく所定の基準に従い相互に調整された、すなわちある「標準」に従い調整されている複数の要素を意図している。

本明細書において、システムの例としてＧＳＭシステム、ＧＰＲＳシステム、ＵＭＴＳシステム、ＷＬＡＮシステム等があり、その各々が対応する標準に準拠している。

端末の再設定を実行するには、上述の文献によれば、再設定可能な技術により端末の動作機能が実現されることが必要である。これに注目するならば、再設定可能な端末または装置には、例えば、複数のＦＰＧＡ（フィールド・プログラム可能ゲートアレイ）、ＤＳＰ（デジタル信号プロセッサ）およびマイクロプロセッサで構成された再プログラム可能なハードウェアが備えられていて、装置の個々の機能は、最低水準であっても、ソフトウェア・コードにより実行される。その結果、再プログラム可能な装置を再設定するには、装置自体のハードウェアを管理している基本ソフトウェアを交換すれば十分である。用語「基本ソフトウェア」は、本明細書の記述では、ライブラリとして編成されたソフトウェアを意味し、例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳ等の考慮対象システムのプロトコル・スタックの無線インターフェース（例：Ｌ１、Ｌ２、Ｌ３）および上位層（例：Ｌ４からＬ７まで）を定義している。

公知のように、電気通信分野において、機能群のグループ化を行なうために最もよく利用される方法がＯＳＩモデル（開放型システム相互接続）である。機能群は、スタックの形式で表わされる機能平面にグループ化される。

プロトコル・スタックの各層は、直上の層に対してサービスを提供し、ここに当該サービスは直下の層が提供するサービスの改善されたものである。

最下位層（層１）は一般に、情報の物理的送信を目的とする。

ＯＳＩ仕様によれば、標準的な層の数は７であり、各々物理、接続、ネットワーク、トランスポート、セッション、プレゼンテーション、およびアプリケーション層である。

例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳ等の各システムは、ＯＳＩプロトコル・スタックの必要な部分を実装している。

無線端末を考慮する場合、再設定可能なハードウェアを使用する際の利点は多いが、一つの利点が明らか即効的である。すなわち、無線端末は、当該端末が位置する領域（動作領域）をカバーするシステムにより再設定可能である。従って、端末がＧＳＭ／ＧＰＲＳ等の第二世代システムがカバーする領域内で用いられた場合、前記システムを受信可能にすべく当該端末を再設定することができる。同様に、ＵＭＴＳ等の第三世代システムがカバーする領域内では端末を適宜設定することができる。

文献（ＡＡ．ＶＶ．「ソフトウェア無線：再設定可能な端末の課題」、電気通信年報２００２年７月／８月、ＧＥＴエルメス（Ｈｅｒｍｅｓ）、Ｅ．ブラッチーニ（Ｂｕｒａｃｃｈｉｎｉ）「ソフトウェア無線の概念」）により、下記のように少なくとも３種の異なる方法でソフトウェア・コードを端末へ転送またはダウンロードできることが知られている。
−無線移動端末に組込まれたＳＩＭ（加入者識別モジュール）を用いることによりスマートカードを介する方法。
−例えば赤外線／シリアル／ＵＳＢ（ユニバーサル・シリアルバス）ポート経由でのパソコンとのリンクを使用する外部接続を介する方法。
−特定の無線チャネルを用いることにより無線または地上波（ＯＴＡ）を介する方法。
ソフトウェアのダウンロードに関して、端末へのソフトウェアのダウンロードを管理可能にする一般的なプロトコルの基本的なステップは、ｗｗｗ．ｓｄｒｆｏｒｕｍ．ｏｒｇというＵＲＬを介して入手可能なソフトウェア無線フォーラム（ＳＤＲフォーラム）のフレームワークに定義されている。

ＳＤＲＦで定義されているプロトコルは、公知のクライアント−サーバ方式のものである。

ダウンロードのプロトコル・ステップは以下の通りである。
−ダウンロード開始：ソフトウェアのダウンロードを開始する意図を以って、ダウンロードされるソフトウェアが常駐しているサーバと端末が通信するステップ。
−相互認証：端末とサーバは互いに認証しなければならない。
−能力相互通知：サーバは、ダウンロードされるソフトウェアに関する能力情報を通知し、端末は当該ソフトウェアを端末メモリへのロード、インストールおよび実行が可能であるか否かを検証する。
−ダウンロード受理：サーバが端末との間で、ダウンロード、インストール、および支払請求オプションを通信する。端末は、サーバから提供された指示が受理可能か否かを決定する。
−ダウンロードおよび完全性テスト：ソフトウェアをダウンロードする間、受信されたコードをテストしなければならない。端末は、不正確に受信された無線ブロックの再送を要求する。
−インストール：インストールステップの間、ソフトウェアの支払請求およびライセンス条件がサーバから提供される。
−現場テスト：ソフトウェアの実行を開始する前に、端末は、ソフトウェア・コードと共にダウンロードされたテスト・ベクトルの支援を受けていくつかのテストを実施する。
−否認防止相互通知：一旦ソフトウェア・コードがインストールされて、テストされたならば、端末はサーバに対し、インストールが成功した旨を確認して支払請求手続きを開始する。

従来技術、例えばＥ．ブラッチーニ（Ｂｕｒａｃｃｈｉｎｉ）、「ソフトウェア無線の概念」、ＩＥＥＥ通信学会誌２０００年９月）により、無線またはＯＴＡを介したソフトウェアのダウンロードは無線チャネルの端末による利用を想定していることが知られている。上述した文献によれば、無線チャネルの種別に応じてソフトウェア・コードを２種の異なる方式のダウンロードすることが知られている。
−「帯域外」方式：現行システムから独立した「ユニバーサル」チャネルにより、端末がスイッチ・オンされた際に、自動的に当該チャネルに同調して、動作領域で動作しているシステムに関する基本ソフトウェアのダウンロードを実行する。
−「帯域内」方式：各々ＧＳＭ／ＧＰＲＳおよびＵＭＴＳ等である、第二および第三世代の標準セルラー・システムの無線チャネルを用いて、これらのチャネルで既に動作している端末が、現在使用されているものとは異なるシステムに関する基本ソフトウェアを受信する。例えば、ＧＳＭ／ＧＰＲＳ等の第二世代システムにより動作する再設定可能な端末が、自身が動作している第二世代の無線チャネルを用いて、ＵＭＴＳ等第三世代システムのダウンロードを実行することができる。

「帯域外」ソフトウェアのダウンロードの例が、例えば日本特許出願第２００１０６１１８６号公報に記載されている。当該文献は、ソフトウェア・コンテンツを地上波経由でダウンロードするシステムおよび方法を記述している。無線端末がスイッチ・オンされた際に、当該動作領域における現行システムが何であるかをユニバーサル・チャネルに問い合わせ、指示されたシステムに関するソフトウェアをダウンロードする。

「帯域外」モードを考慮するに、従来技術によれば専用の無線チャネルの実装が必要であり、従って、その実施のためのネットワークにおける専用設備が必要である。

「帯域内」ソフトウェアのダウンロードの例が、例えば米国特許出願公開第２００３／０１６３５５１号に記載されている。当該文献は、サーバと端末間の交渉（能力相互通知、認証、支払請求等）ステップの間に専用チャネルを用いて、且つ利用可能な無線リソースに負荷をかけることなく極力多くのユーザーに対して同時にダウンロード・サービスを提供すべくダウンロード・手続きの間に共有共通チャネルを用いて、地上波経由でソフトウェアをダウンロードするシステムおよび方法を記述している。

「帯域内」ダウンロード方式を考慮する際に、文献ＡＡ．ＶＶ．「再設定可能端末に対応したＩＰ利用に基づくネットワーク要素のアーキテクチャ」、ＳＣＯＵＴワークショップ、２００３年９月１６日、およびＩＳＴ−２００１−３４０９１ＳＣＯＵＴ、Ｄ４．１．１、「セルラーおよびアドホック・ネットワークにおけるＩＰ原理に基づくダウンロード・トラフィックに対するネットワークおよびセキュリティ・アーキテクチャ要件並びにトラフィック管理スキーム」で、ある種のプロトコルおよびある種のネットワーク・ノードを大幅に変更することを提案している。例：基本ソフトウェアのダウンロードの管理を可能にすべく、コア・ネットワークがＩＰ（インターネット・プロトコル）に完全準拠しているＵＭＴＳのリリース５以降に基づく無線アクセス・ノードおよび／またはコア・ネットワーク・ノード。

このような変更は、設備製造業者およびネットワーク・オペレータの相当な努力を要し、既存のセルラー・システムの標準に劇的な影響を及ぼす恐れがある。

従って、既知の「帯域内」技術には、例えばＧＳＭ／ＧＰＲＳまたはＵＭＴＳ等の既存のセルラー・ネットワークに再設定可能な端末の基本ソフトウェアのダウンロード管理の追加が求められた場合に、プロトコルおよびネットワーク・ノードに対する大幅な変更が必要になるという制限を示す。

出願人は、「帯域内」方式および「帯域外」方式の両方の場合において公知の従来技術では、ある種のプロトコルおよびある種のネットワーク・ノードに大幅な変更が施される点に注目する。

公知の従来技術における更なる問題は、現行標準によるシステム間ハンドオーバーの管理である。
−ＧＳＭ／ＧＰＲシステムからＵＭＴＳシステムへのハンドオーバー
−ＵＭＴＳシステムからＣＤＭＡ２０００システムへのハンドオーバー
−ＵＭＴＳシステムからＧＳＭ／ＧＰＲシステムへのハンドオーバー
−ＣＤＭＡ２０００システムからＵＭＴＳシステムへのハンドオーバー

公知の標準によれば、システム間ハンドオーバーは、多モード端末、すなわちＡＳＩＣ（特定用途向け集積回線）技術を用いて各々のセルラー・システムのプロトコル・スタック全体をサポートする端末を必要とする。

例えば図１を参照するに、ＲＡＴ−ＧＳＭ／ＧＰＲＳと呼ばれるＧＳＭ／ＧＰＲＳシステムの全体的な無線プロトコル・スタック、ＲＡＴ−ＵＭＴＳと呼ばれるＵＭＴＳシステムの全体的な無線プロトコル・スタック、およびＲＡＴ−ＣＤＭＡ２０００と呼ばれるＣＤＭＡ２０００システムの全体的な無線プロトコル・スタックを含む多モード端末を示している。

公知の解決策には、電力消費が多い、装置サイズが大きい、および実装コストが高い等、いくつかの短所がある。
日本特許出願第２００１０６１１８６号公報 米国特許出願公開第２００３／０１６３５５１号 Ｊ．ミトラ（Ｍｉｔｏｌａ）、「ソフトウェア無線アーキテクチャ」、ＩＥＥＥ 通信学会誌、１９９５年５月 Ｅ．ブラッチーニ（Ｂｕｒａｃｃｈｉｎｉ）、「ソフトウェア無線の概念」、ＩＥＥＥ通信学会誌、２０００年９月 ＡＡ．ＶＶ．「ソフトウェア無線：再設定可能な端末の課題」、電気通信年報２００２年７月／８月、ＧＥＴエルメス（Ｈｅｒｍｅｓ）、Ｅ．ブラッチーニ（Ｂｕｒａｃｃｈｉｎｉ）「ソフトウェア無線の概念」

要約すれば、出願人は公知の従来技術について以下の点に注目する。
−例えば新規のノードやインターフェースの追加、および標準により定義されたデータのシグナリングおよび転送プロトコルの変更等、無線リソースの非効率的な利用につながるネットワーク・ノードに対する大幅な変更なしにはソフトウェアをダウンロードする課題が解決されない。
−システム間ハンドオーバーの管理のために再設定可能な端末を利用することができない。

従って、ネットワーク・ノードおよび関連プロトコルを大幅に変更することなく無線端末を設定する基本ソフトウェアをダウンロードする方法および通信ネットワークを提供することが本発明の目的である。

更に、設定可能な端末を用いてシステム間ハンドオーバー手続きを可能にする方法および通信ネットワークを提供することも本発明の更なる目的である。

上述の目的は、添付の請求項に記載されている方法および通信ネットワークにより達成される。

更に、本発明の目的は、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物の組により達成され、当該生成物は少なくとも１個のコンピュータのメモリにロード可能であって、請求項に従い当該生成物がコンピュータ上で実行された場合に本発明の方法のステップを実行するソフトウェア・コード部分を含んでいる。以下で用いるように、そのようなコンピュータ・プログラム生成物への参照は、本発明の方法の実行を調整すべくコンピュータ・システムを制御する命令を含むコンピュータ可読媒体への参照と等価である。「少なくとも１個のコンピュータ」との表現は明らかに、本発明の方法が分散モジュール方式で実装される可能性を強調することを意図している。

好適な実施形態において、無線端末を再設定する基本ソフトウェアのダウンロードは、標準に関して、端末内および、例えばネットワークのＢＳＣ（基地局コントローラ）またはＲＮＣ（無線ネットワーク・コントローラ）の無線コントローラ等、ネットワーク内の少なくとも１個のノード内の無線プロトコル・スタックの単一の層だけを変更することにより実現される。

本発明によれば、変更された層のプロトコルは、ＳＤＲ−Ｆｏｒｕｍから提供される推奨事項と整合している。

本発明の好適な実施形態によれば、そこから基本ソフトウェアをダウンロードが可能であるサーバは、ネットワークの無線コントローラ、例えばＢＳＣまたはＲＮＣ等に常駐している。

本発明がもたらす利点には以下のものがある。
−ソフトウェアのダウンロード・サービスは透過的であり、他の任意のシグナリングおよびトラフィック・データフローとしてネットワークから見える。
−既存且つ将来の標準の全ての特徴を完全に利用することにより、無線リソースの効果的且つ柔軟な利用が可能である。
−呼を中断することなく基本ソフトウェアをダウンロードするために、例えば回線呼の最中にパケット接続を確立することが可能である。
−異なるデータフロー同士を区別して、それらの優先順位（例：音声、データおよびソフトウェアのダウンロード）を管理することが可能である。例えば、音声通話の優先順位がソフトウェアのダウンロードの優先順位より高い場合、ソフトウェアのダウンロード自体を一時的に中断して、逐次前記ダウンロードを再開することができる。

更に、本発明は、再設定可能端末を利用してシステム間ハンドオーバーの管理を可能にする。

実際に、本発明の好適な実施形態によれば、サポート対象システム上で測定を実行するための最小限の機能だけが端末の物理層に実装されていれば十分である。

例えば、ＧＳＭ／ＧＰＲＳシステムにより動作すべく設定されていて、ＵＭＴＳシステムへのシステムハンドオーバーを管理する準備が整っている端末を想定する。本発明によれば、ＧＳＭ／ＧＰＲＳシステムの無線インターフェースの全体的なプロトコル・スタックにより設定されている端末は、ＵＭＴＳシステムの能力測定を実行するための最小限の物理層機能だけを備えている。

システム間ハンドオーバーは、ＧＳＭ／ＧＰＲＳ無線チャネルを介してＵＭＴＳ基本ソフトウェア全体を端末内にダウンロードし、ＵＭＴＳシステムに従い端末を再設定して、ＧＳＭ／ＧＰＲＳシステム上で能力測定を実行するための最小限の物理層機能を提供することにより管理される。

本発明を、その好適な、ただし限定的ではない実施形態の添付図面を参照しながら以下に開示する。

全ての図を通じて、同等であるか、または実質的に等価な機能を実装する構成要素を示すために同一参照番号を用いている。

図２を参照するに、再設定可能な端末または移動局ＭＳ、基地送受信局ＢＴＳすなわちＢＴＳノード、および基地局コントローラＢＳＣすなわちＢＳＣノードを含むＧＳＭ／ＧＰＲＳシステムのネットワーク・アーキテクチャを示す。

ネットワークは更に、例えば、図２に示していない移動スイッチング・センター（ＭＳＣ）および／またはサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）および／またはゲートウェイＧＰＲＳ サポート・ノード（ＧＧＳＮ）等のコア・ネットワーク・ノードを含んでいる。

端末ＭＳは、ＢＳＣノードに接続されているＢＴＳノードに、無線インターフェースを介して接続されている。

本発明の好適な実施形態によれば、端末ＭＳは、ＯＴＡクライアントと呼ばれる第一のエンティティと、無線リソース・プロトコルＲＲと呼ばれる公知の種類の第二のエンティティとを含んでいる。ＯＴＡクライアントは、無線リソース・プロトコルＲＲと同一プロトコル・レベルまたは層にあってこれと協働する。

ＲＲエンティティは、例えば、ＧＳＭ／ＧＰＲＳ標準ＥＴＳＩ０４．１８に従い動作し、以下に開示するように、基地局コントローラＢＳＣ内でＯＴＡクライアントおよびＲＲ対応エンティティと通信するための機能を含んでいる。

ＯＴＡクライアントは、基本ソフトウェアの全体または一部を、ＯＴＡサーバと呼ばれる基地局コントローラＢＳＣ内のＯＴＡ対応エンティティからダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。

ＢＳＣは、ＯＴＡサーバと呼ばれる第一のエンティティ、および無線リソース・プロトコルＲＲと呼ばれる公知の種類の第二のエンティティを含んでいる。

ＯＴＡサーバは、同一プロトコル・レベルにあって、無線リソース・プロトコルＲＲと協働する。

ＲＲエンティティは、例えば、ＧＳＭ／ＧＰＲＳ標準ＥＴＳＩ０４．１８に従い動作し、以下に開示するように、移動端末ＭＳ内でＯＴＡサーバおよびＲＲ対応エンティティと通信するための機能を含んでいる。

ＯＴＡサーバは、基本ソフトウェアの全体または一部をＯＴＡクライアントへダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。

ＯＴＡサーバは更に、基本ソフトウェアを含んでいるか、または、これを修復することが可能である。

ＯＴＡサーバのアーキテクチャは、以下に開示するように、アクティブなダウンロード・セッションを有する各ＯＴＡクライアントに対してクライアント・コンテキストと呼ばれるコンテキストを提供する。

図３に、本発明に従い設定された端末ＭＳを示す。

端末ＭＳは、ＧＳＭ／ＧＰＲＳプロトコルの上位層および下位層を含んでいる。

下位層はＲＡＴ（無線アクセス技術）ＧＳＭ／ＧＰＲＳと呼ばれ、ＧＳＭ／ＧＰＲＳ標準に従いＯＴＡクライアント、無線リソースＲＲ、物理（Ｌ１）およびＤＬ（データリンク）（Ｌ２）の各エンティティを含んでいる。

端末ＭＳは、更なる標準、例えばＵＭＴＳ標準に従い物理層（Ｌ１Ｕ）を含み、少なくとも当該更なる標準に準拠して層１の測定を実行する機能を更に含んでいる。

開示した端末ＭＳは、以下に開示するように更なる標準の基本ソフトウェアをダウンロードすることにより再設定可能である。

本発明の好適な実施形態で想定されているように、基本ソフトウェアは一組の基本ソフトウェア・モジュール、好適には所定の通信システムに従い端末ＭＳを設定する複数のソフトウェア・モジュールを含んでいる。

本発明は、例えば更に所定の通信システムに従って無線端末ＭＳを設定するために用いるプロトコル・スタックを構成する全ての基本ソフトウェア・モジュールのダウンロードを可能にする。

当業者には理解されるように、本発明の更なる実施形態によれば、使用中の通信システムまたは別の通信システムに対応するプロトコル・スタックの一部だけで構成されたソフトウェア・モジュールをダウンロードすることも可能である。

そのような更なる実施形態は、例えば、端末ＭＳに新規機能、更新版またはバグ修正を加える目的に有用であろう。

図４を参照するに、端末ＭＳにおけるＯＴＡクライアントの状態遷移図を示す。

状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
本発明の好適な実施形態によれば、ＯＴＡクライアントの状態およびその間の遷移は以下の通りである。
−「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡクライアントはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、ＯＴＡクライアントはこの状態に戻る。
−「ダウンロード開始」状態：ネットワークが基本ソフトウェアのダウンロード手続きの開始を要求した場合、ＯＴＡクライアントはこの状態に入ってタイマーＴ１００を起動する。状態遷移が生じた場合にはタイマーＴ１００は停止される。状態遷移の前にタイマーＴ１００の時刻に過ぎた場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「相互認証」状態：この状態で、ＯＴＡクライアントはＯＴＡサーバとの相互認証を実行する。ＯＴＡサーバから認証要求が来たならば、ＯＴＡクライアントはこの状態に入る。ＯＴＡクライアントはタイマーＴ２００を起動する。タイマーＴ２００は状態遷移が生じた場合に停止される。状態遷移の前にタイマーＴ２００の設定期限が過ぎたか、または認証が失敗した場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「能力要求」状態：この状態で、ＯＴＡクライアントはＯＴＡサーバに自身の能力を提示する。ＯＴＡクライアントは、ＯＴＡサーバが自身の能力を要求した場合にこの状態に入る。ＯＴＡクライアントがタイマーＴ３００を起動する。タイマーＴ３００は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーＴ３００設定期限が過ぎた場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「ダウンロード受理」状態：この状態で、ＯＴＡクライアントは、ＯＴＡサーバが受信した情報に従いダウンロードを続けるか否かを決定する。ＯＴＡクライアントは、ＯＴＡサーバから実行すべきダウンロード・プロファイルを受信したならばこの状態に入る。受信したプロファイルが拒否された場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「ソフトウェア・ダウンロード」状態：この状態で、ＯＴＡクライアントは、ソフトウェアのダウンロードを実行する。ダウンロード・プロファイルが受理されたならば、ＯＴＡクライアントはこの状態に入る。ＯＴＡクライアントはタイマーＴ４００を起動する。タイマーＴ４００は、ＯＴＡサーバから受信された各ソフトウェア・ブロックでリセットされて再開される。タイマーＴ４００は、状態遷移が生じたならば停止される。状態遷移の前にタイマーＴ４００の設定期限が過ぎたか、またはダウンロードが失敗した、あるいはダウンロードされたソフトウェアが能力に準拠していない場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「インストール」状態：この状態で、ＯＴＡクライアントは、ＯＴＡサーバに対しライセンス要求を送信して基本ソフトウェアをインストールする。ＯＴＡクライアントは、ダウンロード終了時点でこの状態に入る。ＯＴＡクライアントは、タイマーＴ５００を起動する。状態変更が生じた場合、タイマーＴ５００は停止される。状態変更の前にタイマーＴ５００の設定期限が過ぎたか、またはライセンスが受理されなかった場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「現場テスト」状態：この状態で、ＯＴＡクライアントは、ＯＴＡサーバが受信したいくつかのテスト・ベクトルを用いて、ダウンロードされたソフトウェアに対していくつかのテストを実行する。基本ソフトウェアがインストールされたならば、ＯＴＡクライアントはこの状態に入る。一旦テストが終了したならば、ＯＴＡクライアントは「アイドル」状態に戻る。

図５を参照するに、ＯＴＡサーバが管理するクライアント・コンテキストの状態遷移図を示す。

先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。

クライアント・コンテキストの状態および相対遷移は以下の通りである。
−「アイドル」状態：アクティブなソフトウェア・ダウンロード・手続きが存在しない場合、ＯＴＡサーバが管理するＯＴＡクライアント・コンテキストはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、ＯＴＡクライアント・コンテキストはこの状態に戻る。
−「ダウンロード開始」状態：この状態で、ＯＴＡクライアント・コンテキストはＯＴＡクライアントにダウンロードを実行するよう指示する。基本ソフトウェアのダウンロードを実行することが必要な場合、ＯＴＡクライアント・コンテキストはこの状態に入ってタイマーＴ１００を起動する。状態遷移の前にタイマーＴ１００は停止される。状態遷移の前にタイマーＴ１００の時刻に過ぎた場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
−「相互認証」状態：この状態で、ＯＴＡクライアント・コンテキストは自身を認証し、ＯＴＡクライアントに対して自身を認証するよう要求する。ＯＴＡクライアントからダウンロード確認を受信したならば、ＯＴＡクライアント・コンテキストはこの状態に入る。ＯＴＡクライアント・コンテキストはタイマーＴ２０１を起動する。タイマーＴ２０１は状態遷移が生じた場合に停止される。状態遷移の前にタイマーＴ２０１の設定期限が過ぎたか、または認証が失敗した場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
−「能力要求」状態：この状態で、ＯＴＡクライアント・コンテキストはＯＴＡクライアントに対しその能力の提示を要求する。認証が完了したならばＯＴＡクライアント・コンテキストはこの状態に入る。ＯＴＡクライアント・コンテキストがタイマーＴ３０１を起動する。タイマーＴ３０１は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーＴ３０１の設定期限が過ぎたか、または能力に起因してダウンロードが不可能な場合、ＯＴＡクライアントは「アイドル」状態に戻る。
−「ダウンロード受理」状態：この状態で、ＯＴＡクライアント・コンテキストは、ダウンロード・プロファイルをＯＴＡクライアントに通知する。ＯＴＡクライアント・コンテキストは、端末能力を受信して、当該能力が受理されたならばこの状態に入る。ＯＴＡクライアント・コンテキストがタイマーＴ３０２を起動する。タイマーＴ３０２は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーＴ３０２の設定期限が過ぎたか、または提案されたダウンロードをＯＴＡクライアントが拒否した場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
−「ソフトウェア・ダウンロード」状態：この状態で、ＯＴＡクライアント・コンテキストは、ＯＴＡクライアントへのソフトウェアのダウンロードを実行する。ダウンロード・プロファイルがＯＴＡクライアントにより受理された場合、ＯＴＡクライアント・コンテキストはこの状態に入る。ＯＴＡクライアント・コンテキストは、タイマーＴ４０１を開始する。タイマーＴ４０１はリセットされて、クライアントから受信された各々の確認応答信号Ａｃｋで再開される。状態遷移が生じた場合、タイマーＴ４０１は停止される。状態遷移の前にタイマーＴ４０１の設定期限が過ぎたか、またはダウンロードが失敗した場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
−「インストール」状態：この状態で、ＯＴＡクライアント・コンテキストは、ＯＴＡクライアントがダウンロードされたソフトウェアのインストールおよびテストを実行するまで、ライセンス条件をＯＴＡクライアントへ通知して待機する。ダウンロードが終了したならば、ＯＴＡクライアント・コンテキストはこの状態に入る。ＯＴＡクライアント・コンテキストがタイマーＴ５０１を起動する。状態遷移が生じたならばタイマーＴ５０１は停止される。状態遷移の前にタイマーＴ５０１の設定期限が過ぎたか、またはライセンスがＯＴＡクライアントにより受理されなかった場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。ＯＴＡクライアント・コンテキストは、ＯＴＡクライアントによるインストールの成功に関する確認応答信号を受信したならば、「アイドル」状態に戻る。

ＧＳＭ／ＧＰＲＳの場合、本発明の好適な実施形態において、ＲＲプロトコルは、以下に図６〜１７を参照しながら詳述するように、新規プロトコル・メッセージを導入することにより変更され、関連するフィールドをＯＴＡサーバとＯＴＡクライアントの間で交換される。

異なるシステムの場合、当業者には理解されるように、例えばＵＭＴＳシステムにおけるＲＲＣ（無線リソース制御）等の無線リソース・プロトコルが同様の方法で変更される。

以下に、メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。

図６を参照するに、「パケット・ダウンロード要求」メッセージの構造を記述している。このメッセージは、基地局コントローラＢＳＣ側にある無線リソースＲＲから端末ＭＳ側の無線リソースＲＲへ送信される。

ＯＴＡサーバはこのメッセージを用いて、ＯＴＡクライアントに対しダウンロード・セッションを開始するよう指示する。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、少なくとも以下のうち１組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロード要求）を識別する。
−ＯＴＡクライアントＩＤ：要求を実行する対象であるＯＴＡクライアントを識別する。
−ＰＤＣＨ（パケット・データチャネル）：ソフトウェアのダウンロードが実行されるネットワークにより割当てられたチャネルを指定する。
−ＲＲＢＰ（相対予約ブロック期間）：標準ＧＰＲＳで既に定義されている通り、端末ＭＳ側の無線リソースＲＲが応答する無線ブロックを指定する。
−要求されたダウンロード：この要素は、ネットワークによる要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。

図７を参照するに、「パケット・ダウンロードＡｃｋ」メッセージの構造を記述している。このメッセージはＯＴＡクライアントからＯＴＡサーバへ送信される。

ＯＴＡクライアントは、このメッセージを用いて、ダウンロード・セッションの開始の確認をＯＴＡサーバに通知する。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、少なくとも以下のうち１組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロードＡｃｋ）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。
−ＯＴＡクライアント・チャレンジ番号：相互認証の第一ステップを実行すべく、ＯＴＡサーバが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズム（高度暗号化標準）を以って暗号化する乱数である。

図８を参照するに、「パケット・ダウンロードＮａｃｋ」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバにダウンロード・セッションを開始することができない旨を通知する。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、少なくとも以下のうち１組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロードＮａｃｋ）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

図９を参照するに、「パケット認証要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージを用いて、ＯＴＡサーバは、自身の証明をＯＴＡクライアントに通知し、ＯＴＡクライアントにそれを確認することが要求する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット認証要求）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信するＯＴＡクライアントを識別する。
−ＯＴＡサーバ応答番号：相互認証の第一のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
−ＯＴＡサーバ・チャレンジ番号：相互認証の第二ステップを実行すべく、ＯＴＡクライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを以って暗号化する乱数である。
−ＲＲＢＰ：標準ＧＰＲＳで既に定義されているように、端末ＭＳ側の無線リソースＲＲが応答する無線ブロックを指定する。

図１０を参照するに、「パケット認証応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、既にＯＴＡサーバを認証した状態で、ＯＴＡクライアントは自身の証明をＯＴＡサーバに通知する。ＧＳＭ／ＧＰＲＳの場合に提供されるフィールドは、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット認証応答）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。
−ＯＴＡクライアント応答番号：相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。

図１１を参照するに、「パケット能力要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージを用いて、ＯＴＡサーバは、ＯＴＡクライアントに対しその再設定可能性オプションを要求する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット能力要求）を識別する。
−ＯＴＡクライアントＩＤ：メッセージの宛先であるＯＴＡクライアントを識別する。
−ＲＲＢＰ：標準ＧＰＲＳに既に定義されている通り、端末ＭＳ側の無線リソースＲＲが応答する無線ブロックを指定する。

図１２を参照するに、「パケット能力応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントは、自身の再設定可能性オプションをＯＴＡサーバに通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット能力応答）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。
−ＯＴＡクライアント能力：端末の再設定可能性オプションを記述する。

図１３を参照するに、「パケット・ダウンロード記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージを用いて、ＯＴＡサーバは、ダウンロードに関するデータをＯＴＡクライアントに報告する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロード記述）を識別する。
−ＯＴＡクライアントＩＤ：メッセージの宛先であるＯＴＡクライアントを識別する。
−ダウンロード・リスト：各ダウンロードにつきＯＴＡクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号：ＯＴＡクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準：起こり得るダウンロード支払請求に関する基準である。
−インストール基準：ソフトウェアのインストールに関する基準である。
−ＲＲＢＰ：標準ＧＰＲＳに既に定義されている通り、端末ＭＳ側の無線リソースＲＲが応答する無線ブロックを指定する。

再び図８を参照するに、「パケット・ダウンロード受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントがダウンロードを確認する。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロード受理）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

再び図８を参照するに、「パケット・ダウンロード拒否」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはダウンロードを拒否する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ダウンロード拒否）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

再び図８を参照するに、「パケット・ライセンス要求」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ライセンス要求）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

図１４を参照するに、「パケット・ライセンス応答」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージを用いて、ＯＴＡサーバは、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵をＯＴＡクライアントに通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ライセンス応答）を識別する。
−ＯＴＡクライアントＩＤ：メッセージの宛先であるＯＴＡクライアントを識別する。
−復号化鍵：基本ソフトウェアを復号化するために用いられる鍵である。

再び図８を参照するに、「パケット・ライセンス受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化された旨をＯＴＡサーバに通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ライセンス受理）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

再び図８を参照するに、「パケット・ライセンス失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨をＯＴＡサーバに通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・ライセンス失敗）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

図１５を参照するに、「パケット・テスト記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージを用いて、ＯＴＡサーバはＯＴＡクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に実行すべきテストを指示する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・テスト記述）を識別する。
−ＯＴＡクライアントＩＤ：メッセージの宛先であるＯＴＡクライアントを識別する。
−テスト・リスト：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル：テストの記述を含んでいる。

再び図８を参照するに、「パケット・インストール成功」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・インストール成功）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

再び図８を参照するに、「パケット・インストール失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（パケット・インストール失敗）を識別する。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。

基本ソフトウェアは、好適な実施形態において、例えば、以下に述べるＢｌｏｃｋおよびＡｃｋと呼ばれる２種類の基本プロトコル・データ・ユニットすなわちＰＤＵに基づいて公知の種類のウィンドウ・プロトコルを使用することにより、ＯＴＡサーバからＯＴＡクライアントへ送信される。

図１６を参照するに、基本ソフトウェアが分割される無線ブロックＢｌｏｃｋの構造を記述している。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：ブロック種別を識別する。
−ブロック番号：無線ブロックのシーケンス番号を識別する。ＯＴＡクライアントがこのシーケンス番号を用いて、基本ソフトウェア全体を再構成する。
−データ：基本ソフトウェア全体のいくつかの部分を含むフィールドである。

図１７を参照するに、端末の受信状態を示すために用いるメッセージＡｃｋの構造を記述している。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−メッセージ種別：送信されたメッセージの種別（Ａｃｋ）を識別する。
−Ａｃｋビットマップ：基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「１」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「０」にセットされる。

本発明の好適な実施形態が想定するＲＲプロトコルに対する変更は、ＯＴＡクライアントと端末ＭＳ側の無線リソースＲＲとの間にプリミティブを導入し、またＯＴＡサーバと基地局コントローラＢＳＣ側の無線リソースＲＲとの間にプリミティブを導入することに基づいている。

プリミティブおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。

最初に、ＯＴＡクライアントと端末ＭＳ側の無線リソースＲＲとの間のプリミティブを記述する。

プリミティブ「ダウンロード要求Ｉｎｄ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：要求の実行対象であるＯＴＡクライアントを識別する。
−要求されたダウンロード：この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。

プリミティブ「ダウンロードＡｃｋＩｎｄ」は、ＯＴＡクライアントにより端末ＭＳ側の無線リソースＲＲへ送信される。このプリミティブで提供されるフィールドには、以下のものがある。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡクライアント・チャレンジ番号：相互認証の第一ステップを実行すべく、ＯＴＡサーバが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを以って暗号化する乱数である。

プリミティブ「ダウンロードＮａｃｋＩｎｄ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「認証Ｒｅｑ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

このプリミティブで提供されるフィールドには以下のものがある。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡサーバ応答番号：相互認証の第一のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
−ＯＴＡサーバ・チャレンジ番号：相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを以って暗号化する乱数である。

プリミティブ「認証Ｒｓｐ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。
提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡクライアント応答番号：相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。

プリミティブ「能力Ｒｅｑ」は、ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「能力Ｒｓｐ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。
−ＯＴＡクライアント能力：端末の再設定可能性オプションを記述する。

プリミティブ「ダウンロード記述Ｒｅｑ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ダウンロード・リスト：各ダウンロードにつきＯＴＡクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号：ＯＴＡクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準：起こり得るダウンロード支払請求に関する基準である。
−インストール基準：ソフトウェアのインストールに関する基準である。

プリミティブ「ダウンロード受理Ｃｎｆ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ダウンロード受理Ｒｅｊ」は、ＯＴＡ端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｅｑ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｓｐ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−復号化鍵：基本ソフトウェアを復号化するために用いられる鍵である。

プリミティブ「ライセンスＣｎｆ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｅｊ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「テスト記述Ｒｅｑ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−テスト・リスト：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル：テストの記述を含んでいる。

プリミティブ「インストールＣｎｆ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
プリミティブ「インストールＲｅｊ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「データＩｎｄ」は、端末ＭＳ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの１個。

プリミティブ「データＲｅｑ」は、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−Ａｃｋの無線ブロック。

ＯＴＡサーバと基地局コントローラＢＳＣ側の無線リソースＲＲとの間で交換されるプリミティブについて以下に記述する。

プリミティブ「ダウンロード開始Ｉｎｄ」は、ＯＴＡクライアントから基地局コントローラ機構ＢＳＣ側の無線リソースＲＲへ送信される。
提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：要求の実行対象であるＯＴＡクライアントを識別する。
−要求されたダウンロード：この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。

プリミティブ「ダウンロードＡｃｋＩｎｄ」は、基地局コントローラ機構ＢＳＣ側の無線リソースＲＲによりＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡクライアント・チャレンジ番号：相互認証の第一ステップを実行すべく、ＯＴＡサーバが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを以って暗号化する乱数である。

プリミティブ「ダウンロードＮａｃｋＩｎｄ」は、基地局コントローラ機構ＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「認証Ｒｅｑ」は、ＯＴＡクライアントから基地局コントローラ機構ＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡサーバ応答番号：相互認証の第一のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
−ＯＴＡサーバ・チャレンジ番号：相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを以って暗号化する乱数である。

プリミティブ「認証Ｒｓｐ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ＯＴＡクライアント応答番号：相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。

プリミティブ「能力Ｒｅｑ」は、ＯＴＡクライアントから基地局コントローラＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「能力Ｒｓｐ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：メッセージを送信しているＯＴＡクライアントを識別する。
−ＯＴＡクライアント能力：端末の再設定可能性オプションを記述する。

プリミティブ「ダウンロード記述Ｒｅｑ」は、ＯＴＡクライアントから基地局コントローラＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−ダウンロード・リスト：各ダウンロードにつきＯＴＡクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号：ＯＴＡクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準：起こり得るダウンロード支払請求に関する基準である。
−インストール基準：ソフトウェアのインストールに関する基準である。

プリミティブ「ダウンロード受理Ｃｎｆ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ダウンロード受理Ｒｅｊ」は、基地局コントローラ機構ＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｅｑ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｓｐ」は、ＯＴＡクライアントにより基地局コントローラＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−復号化鍵：基本ソフトウェアを復号化するために使用する鍵である。

プリミティブ「ライセンスＣｎｆ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「ライセンスＲｅｊ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「テスト記述Ｒｅｑ」は、ＯＴＡサーバから基地局コントローラＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−テスト・リスト：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル：テストの記述を含んでいる。

プリミティブ「インストールＣｎｆ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「インストールＲｅｊ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。

プリミティブ「データＲｅｑ」は、ＯＴＡサーバから基地局コントローラＢＳＣ側の無線リソースＲＲへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの１個。

プリミティブ「データＩｎｄ」は、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡサーバへ送信される。

提供されるフィールドは、ＧＳＭ／ＧＰＲＳの場合、以下のうち少なくとも一組である。
−ＯＴＡクライアントＩＤ：プリミティブに関連するＯＴＡクライアントを識別する。
−Ａｃｋの無線ブロック。

図４、５を参照するに、ＯＴＡクライアントとＯＴＡサーバとの間での手続き型の対話を、各々のＲＲが受信した各プリミティブについて、ＯＴＡクライアントまたはクライアント・コンテキストの状態に従う相対的な挙動を示すことにより記述している。

ＯＴＡクライアントおよびＯＴＡサーバの挙動はシステムから独立している。

ＯＴＡクライアントまたはＯＴＡサーバと、各々のＲＲとの間で交換されたプリミティブはシステムに依存しており、本例によればＧＳＭ／ＧＰＲＳシステムを参照している。

以下の記述において、タイマーの開始／停止動作は記述されていない。その理由は、先に述べたように、これらはエンティティの状態と関連付けられているためである。

ここで図４を参照するに、ＯＴＡクライアントの挙動を記載している。

一般に、ＯＴＡクライアントＩＤフィールドがプリミティブを受信しているＯＴＡクライアントの識別子と合致しない場合、当該プリミティブは無視される。

ＯＴＡクライアントがプリミティブ「ダウンロード要求Ｉｎｄ」を受信した場合、
−「アイドル」状態であれば、ＯＴＡクライアントは「ダウンロード開始」へ進む。
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−端末がダウンロードを実行することが可能ならば、
−乱数ＲＮＵＭが抽出されて保存される。
−ＯＴＡクライアント・チャレンジ番号フィールド内に抽出された数ＲＮＵＭの値を含むプリミティブ「ダウンロードＡｃｋＩｎｄ」が送信される。
−端末がダウンロードを実行することが可能でなければ、プリミティブ「ダウンロードＮａｃｋＩｎｄ」が送信され、ＯＴＡクライアントは「アイドル」状態に戻る。

ＯＴＡクライアントがプリミティブ「認証Ｒｅｑ」を受信した場合、
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数ＲＮＵＭが有効でなければ手続きは継続されない。
−ＯＴＡクライアントは状態「相互認証」へ進む。
−保存された乱数ＲＮＵＭの値は、選択された暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて、内部鍵ＣＩＫにより暗号化される。
−前段階で暗号化された値がＯＴＡサーバ応答番号フィールドの値と合致しない場合、ＯＴＡクライアントは「アイドル」状態に進み、手続きは継続されない。
−ＯＴＡサーバ・チャレンジ番号フィールドの値は、選択された暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて、内部鍵ＣＩＫ（クライアント識別鍵）により暗号化される。
−プリミティブ「認証Ｒｓｐ」は、ＯＴＡクライアント応答番号フィールド内の前段階で暗号化された値と共に送信される。

ＯＴＡクライアントがプリミティブ「能力Ｒｅｑ」を受信した場合、
−「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアントは「能力要求」状態に進む。
−プリミティブ「能力応答」が送信される。

ＯＴＡクライアントがプリミティブ「ダウンロード記述Ｒｅｑ」を受信した場合、
−「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアントは「ダウンロード受理」状態に進む。
−端末がソフトウェアをインストールすることが可能ならば、
−プリミティブ「ダウンロード受理Ｃｎｆ」が送信される。
−端末がソフトウェアをインストールすることが可能でなければ、
−プリミティブ「ダウンロード受理Ｒｅｊ」が送信される。
−ＯＴＡクライアントは「アイドル」状態に進む。

ＯＴＡクライアントがプリミティブ「ライセンスＲｓｐ」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ダウンロードされたソフトウェアは、復号化鍵フィールドに示された鍵を用いて復号化される。
−復号化が成功した場合、
−プリミティブ「ライセンスＣｎｆ」が送信される。
−ダウンロードされた基本ソフトウェアが保存される。
−復号化が成功しなかった場合、
−プリミティブ「ライセンスＲｅｊ」が送信される。
−手続きは「アイドル」状態に進む。

ＯＴＡクライアントがプリミティブ「テスト記述Ｒｅｑ」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアントは「現場テスト」状態に進む。
−受信されたテストは、先に保存された基本ソフトウェアに対して実行される。
−全てのテストが成功した場合、
−プリミティブ「インストールＣｎｆ」が送信される。
−新規の基本ソフトウェアがインストールされて開始される。
−少なくとも１個のテストが成功しなかった場合、
−インストールＲｅｊプリミティブが送信される。
−ダウンロードされた基本ソフトウェアがメモリから削除される。
−ＯＴＡクライアントは「アイドル」状態に進む。

再び図５を参照するに、ここでＯＴＡサーバの応答を記載している。

一般に、受信されたプリミティブの各々についてＯＴＡクライアントＩＤフィールドが分析され、前記識別子に関するＯＴＡクライアント・コンテキストであると見なされる。受信された識別子に対するＯＴＡクライアント・コンテキストが存在しない場合、当該プリミティブは無視される。

ＯＴＡサーバがプリミティブ「ダウンロードＡｃｋＩｎｄ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「相互認証」状態に進む。
−乱数が抽出されて保存される。
−ＯＴＡクライアント・チャレンジ番号フィールドの値が、選択された暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて、内部鍵ＳＩＫ（サーバ識別鍵）により暗号化される。
−プリミティブ「認証Ｒｅｑ」が、前段階でＯＴＡサーバ応答番号フィールド内の暗号化される値と共に、且つＯＴＡサーバ・チャレンジ番号フィールド内の抽出された番号の値と共にＯＴＡクライアントへ送信される。

ＯＴＡクライアント・コンテキストがプリミティブ「ダウンロードＮａｃｋＩｎｄ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。

ＯＴＡクライアント・コンテキストがプリミティブ「認証Ｒｓｐ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数の値が、選択された暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて、内部鍵ＳＩＫにより暗号化される。
−前段階で暗号化された値がＯＴＡクライアント応答番号フィールドの値と合致しない場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に進み、継続されない。
−ＯＴＡサーバは「能力要求」状態に進む。
−プリミティブ「能力Ｒｅｑ」が送信される。

ＯＴＡクライアント・コンテキストがプリミティブ「能力Ｒｓｐ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブに含まれる能力が、ダウンロードされるソフトウェアと互換性を有していない場合、ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。
−プリミティブに含まれる能力がダウンロードされるソフトウェアと互換性を有する場合、ＯＴＡクライアント・コンテキストは「ダウンロード受理」状態に進み、プリミティブ「ダウンロード記述Ｒｅｑ」が送信される。

ＯＴＡクライアント・コンテキストがプリミティブ「ダウンロード受理Ｃｎｆ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「ソフトウェア・ダウンロード」状態に進む。
−ソフトウェアのダウンロードが開始される。

ＯＴＡクライアント・コンテキストがプリミティブ「ダウンロード受理Ｒｅｊ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。

ＯＴＡクライアント・コンテキストがプリミティブ「ライセンスＲｅｑ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「ソフトウェア・ダウンロード」状態でなければプリミティブは無視され、手続きは継続されない。
−手続きは「インストール」状態に進む。
−復号化鍵を含む、プロトコル・プリミティブ「ライセンスＲｓｐ」が送信される。

ＯＴＡクライアント・コンテキストがプリミティブ「ライセンスＣｎｆ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブ「テスト記述Ｒｅｑ」が送信される。

ＯＴＡクライアント・コンテキストがプリミティブ「ライセンスＲｅｊ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。

ＯＴＡクライアント・コンテキストがプリミティブ「インストールＣｎｆ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。

ＯＴＡクライアント・コンテキストがプリミティブ「インストールＲｅｊ」を受信した場合、
−ＯＴＡクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「アイドル」状態に進む。

データがＯＴＡサーバからＯＴＡクライアントへ転送されるウィンドウ・プロトコルの動作について以下に記述する。

ＯＴＡサーバの観点から、ソフトウェアのダウンロードが開始された際に、基本ソフトウェアは、例えば、暗号化鍵および例えばＡＥＳアルゴリズム等、公知の種類の暗号化アルゴリズムにより暗号化される。

暗号化された基本ソフトウェアは、例えば、１〜２ｋＢｙｔｅｓ等の限られたサイズを有するブロックに分割される。基本ソフトウェアが分割された無線ブロックの個数に等しい個数のビットを有するビット・マスクＢＩＴＭＡＳＫが割当てられて、各々のビットに値「０」が設定される。マスクの各ビットは、無線ブロックに対応しており、その番号はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。基本ソフトウェアを構成する先頭のＮ個の無線ブロックＢＬＯＣＫが送信される。タイマーＴ４０１が始動される。各メッセージＡｃｋを受信したならば以下が行なわれる。
−タイマーＴ４０１が再開される。
−メッセージＡｃｋのビットマップに存在する各々の値「１」に対して、対応する位置に割当てられたマスクＢＩＴＭＡＳＫの値が「１」に設定される。
−未送信ブロックを最初に考慮して、マスクＢＩＴＭＡＳＫ内で値「０」に対応する高々先頭のＮ無線ブロック・ブロックが送信される。
−マスクＢＩＴＭＡＳＫの全てのビットが「１」に等しい値になった時点でダウンロードが終了する。

ＯＴＡクライアントの観点から、ソフトウェアのダウンロードが開始された際に、当該ソフトウェアが分割された無線ブロックの個数に等しいビット・マスクＢＩＴＭＡＳＫが割当てられて、各々のビットに値「０」が設定される。マスクの各ビットは、無線ブロックに対応しており、その数はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。次いで、タイマーＴ４００が始動される。各無線ブロックＢＬＯＣＫを受信したならば以下が行なわれる。
−タイマーＴ４００が再開される。
−受信した無線ブロックのブロック番号に対応するマスクＢＩＴＭＡＳＫのビットが「１」に設定される。
−マスクＢＩＴＭＡＳＫに対応するビットマップと共にメッセージＡｃｋが送信される。
−マスクＢＩＴＭＡＳＫの全てのビットが「１」に等しい値になった時点でダウンロードが終了する。

要約するに、上例によれば、ＯＴＡクライアントおよびＯＴＡサーバの機能的な挙動は以下の通りである。
−ダウンロード・手続きは、例えば、ＭＳＣ（移動スイッチングセンター）により基地局コントローラＢＳＣへ送信されたプロトコル・メッセージ「ハンドオーバー・コマンド」を受信した時点で開始される。
−ＯＴＡクライアントとＯＴＡサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い生起する。
−ダウンロードされる基本ソフトウェアは、トラフィック・チャネル、例えばＧＰＲトラフィック・チャネルへ送信される。
−ダウンロードされる基本ソフトウェアは、ＯＴＡサーバにより小さいサイズ（例：１または２キロバイト）のブロックに分割される。
−基本ソフトウェアの転送は簡単なウィンドウ・プロトコルにより管理され、その際にサイズ・ウィンドは基本ソフトウェアが分割されたブロックの個数と合致する。
−ダウンロードされた基本ソフトウェアは暗号化することができ、その場合、復号化およびインストールのために鍵が必要とされる。
−基本ソフトウェアを開始する前に、ＯＴＡクライアントは、例えばＯＴＡサーバにより提案された適切なテストによりこれを検証する。

図１８を参照するに、標準に定義されている通り、回線呼に対するＧＳＭからのＵＭＴＳへのシステム間ハンドオーバー手続きの適用可能な例を示しており、この中で端末ＭＳを再設定可能な基本ソフトウェアのダウンロード・手続きが導かれている。

図１９を参照するに、ネットワーク内に存在する異なるエンティティ間の相互作用を指し示しつつ、前記ソフトウェア・ダウンロード手続きが動作する様子を説明している。
１．ＯＴＡクライアント、および想定されるＯＴＡクライアントに関し、且つＯＴＡサーバに存在するＯＴＡクライアント・コンテキストは「アイドル」状態である。
２．移動スイッチングセンター（ＭＳＣ）からプロトコル・メッセージ「ハンドオーバー・コマンド」を受信した場合、ＯＴＡクライアント・コンテキストは「アイドル」状態から「ダウンロード開始」状態に遷移し、タイマーＴ１０１を始動して、要求されたダウンロードを示すと共に、プリミティブ「ダウンロード開始Ｉｎｄ」を無線リソースＲＲへ送信する。
３．無線リソースＲＲは、プリミティブ「ダウンロード開始Ｉｎｄ」を受信する。無線リソースＲＲは無線リソース管理ＲＲＭに対し、ソフトウェアのダウンロードを実行可能にするために必要なダウンリンク・リソースを要求する。
ａ．リソースが利用できる場合、無線リソースＲＲは制御チャネルＦＡＣＣＨ（高速付随制御チャネル）を介して端末ＭＳの無線リソースＲＲへプロトコル・メッセージ「パケット・ダウンロード要求」を送信して、端末がダウンロードを実行するチャネルＰＤＣＨ、相対予約ブロック期間ＲＲＢＰ、および要求されたダウンロードを指示する。
ｂ．リソースが利用できない場合、無線リソースＲＲはプリミティブ「ダウンロードＮａｃｋＩｎｄ」をＯＴＡクライアント・コンテキストへ送信する。
４．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット・ダウンロード要求」を受信してチャネルＰＤＣＨを設定し、プリミティブ「ダウンロード要求Ｉｎｄ」を送信する。
５．ＯＴＡクライアントは、プリミティブ「ダウンロード要求Ｉｎｄ」を受信する。ダウンロードの実行に端末が利用できる場合、ＯＴＡクライアントは「アイドル」状態から「ダウンロード開始」状態に遷移し、タイマーＴ１００を始動して、プリミティブ「ダウンロードＡｃｋＩｎｄ」を送信し、無線リソースＲＲに対し自身の識別子を指定する。無線リソースＲＲは、ＯＴＡクライアントの識別子をローカルに保存する。
６．無線リソースＲＲはプリミティブ「ダウンロードＡｃｋＩｎｄ」を受信して、相対予約ブロック期間ＲＲＢＰにより指定された時点でＰＡＣＣＨ（パケット付随制御チャネル）を介して基地局コントローラＢＳＣの無線リソースＲＲへプロトコル・メッセージ「パケット・ダウンロードＡｃｋ」を送信して、ＯＴＡクライアントの識別子を指示する。
７．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット・ダウンロードＡｃｋ」を受信して、プリミティブ「ダウンロードＡｃｋＩｎｄ」をＯＴＡクライアント・コンテキストへ送信して、ＯＴＡクライアントの識別子を指定する。
８．ＯＴＡクライアント・コンテキストは、プリミティブ「ダウンロードＡｃｋＩｎｄ」を受信する。ＯＴＡクライアント・コンテキストはタイマーＴ１０１を停止して、「ダウンロード開始」状態から「相互認証」状態に遷移する一方、タイマーＴ２０１を始動させる。プリミティブ「認証Ｒｅｑ」が無線リソースＲＲへ送信される。
９．無線リソースＲＲは、プリミティブ「認証Ｒｅｑ」を受信して、制御チャネルＰＡＣＣＨを介して、プロトコル・メッセージ「パケット認証要求」を端末ＭＳの無線リソースＲＲを送信して、ＲＲＢＰを指示する。
１０．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット認証要求」を受信して、プリミティブ「認証Ｒｅｑ」をＯＴＡクライアントへ送信する。
１１．ＯＴＡクライアントはプリミティブ「認証Ｒｅｑ」を受信し、タイマーＴ１００を停止して、タイマーＴ２００を始動すると共に、「相互認証」状態に進む。この段階でＯＴＡサーバの認証が実行される。
ａ．ＯＴＡサーバが認証されなかった場合、ＯＴＡクライアントはタイマーＴ２００を停止して、「アイドル」状態に戻る。
ｂ．ＯＴＡサーバが認証された場合、ＯＴＡクライアントはプリミティブ「認証Ｒｓｐ」を無線リソースＲＲへ送信する。
１２．無線リソースＲＲは、プリミティブ「認証Ｒｓｐ」を受信して、相対予約ブロック期間ＲＲＢＰにより指定された時点で、ＰＡＣＣＨを介して基地局コントローラＢＳＣの無線リソースＲＲへプロトコル・メッセージ「パケット認証応答」を送信する。
１３．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット認証応答」を受信して、プリミティブ「認証Ｒｓｐ」をＯＴＡクライアント・コンテキストへ送信する。
１４．ＯＴＡクライアント・コンテキストは、プリミティブ「認証Ｒｓｐ」を受信して、ＯＴＡクライアントの認証を確認する。
ａ．ＯＴＡクライアントが認証されなかった場合、タイマーＴ２０１が中断され、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
ｂ．ＯＴＡクライアントが認証された場合、タイマーＴ２０１が中断され、ＯＴＡクライアント・コンテキストはタイマーＴ３０１を始動すると共に、「能力要求」状態に進む。ＯＴＡクライアント・コンテキストは、プリミティブ「能力Ｒｅｑ」を無線リソースＲＲへ送信する。
１５．無線リソースＲＲは、プリミティブ「能力Ｒｅｑ」を受信し、制御チャネルＰＡＣＣＨを介して、端末ＭＳの無線リソースＲＲへ、ＲＲＢＰが指定されているプロトコル・メッセージ「パケット能力Ｒｅｑ」を送信する．
１６．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット能力Ｒｅｑ」を受信して、プリミティブ「能力Ｒｅｑ」をＯＴＡクライアントへ送信する。
１７．ＯＴＡクライアントはプリミティブ「能力ｒＲｅｑ」を受信し、タイマーＴ２００を停止して、タイマーＴ３００を始動すると共に、「能力要求」状態に進む、ＯＴＡクライアントは、プリミティブ「能力Ｒｓｐ」を無線リソースＲＲへ送信する。
１８．無線リソースＲＲは、プリミティブ「能力Ｒｓｐ」を受信し、ＲＲＢＰにより指定された時点で、ＰＡＣＣＨを介して基地局コントローラＢＳＣの無線リソースＲＲへプロトコル・メッセージ「パケット能力応答」を送信する。
１９．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット能力応答」を受信して、ＯＴＡクライアント・コンテキストへプリミティブ「能力Ｒｓｐ」を送信する。
２０．ＯＴＡクライアント・コンテキストは、プリミティブ「能力Ｒｓｐ」を受信して、端末能力を検証する。
ａ．当該能力がソフトウェアのダウンロードと互換性を有していない場合、タイマーＴ３０１が中断され、ＯＴＡクライアント・コンテキストは「アイドル」状態に戻る。
ｂ．当該能力がソフトウェアのダウンロードと互換性を有している場合、タイマーＴ３０１が中断され、ＯＴＡクライアント・コンテキストは、タイマーＴ３０２を始動すると共にダウンロード動作に関する情報（ダウンロードする無線ブロックの個数、支払請求、インストール等）が指示されているプリミティブ「ダウンロード記述Ｒｅｑ」を無線リソースＲＲへ送信すると共に、「ダウンロード受理」状態へ進む。
２１．無線リソースＲＲは、プリミティブ「ダウンロード記述Ｒｅｑ」を受信して、制御チャネルＰＡＣＣＨを介して、ＲＲＢＰが指定されているプロトコル・メッセージ「パケット・ダウンロード記述」を端末ＭＳの無線リソースＲＲへ送信する．
２２．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット・ダウンロード記述」を受信して、プリミティブ「ダウンロード記述Ｒｅｑ」をＯＴＡクライアントへ送信する。
２３．ＯＴＡクライアントは、プリミティブ「ダウンロード記述Ｒｅｑ」を受信し、タイマーＴ３００を停止して、「ダウンロード受理」状態へ進む。ＯＴＡクライアントは受信された情報を検証する。
ａ．ダウンロードが受理されなかった場合、ＯＴＡクライアントはプリミティブ「ダウンロード受理Ｒｅｊ」を無線リソースＲＲへ送信して、「アイドル」状態に戻る。
ｂ．ダウンロードが受理された場合、ＯＴＡクライアントはタイマーＴ４００を始動すると共に、プリミティブ「ダウンロード受理Ｃｎｆ」を無線リソースＲＲへ送信して、「ソフトウェア・ダウンロード」状態へ進む。
２４．無線リソースＲＲは、プリミティブ「ダウンロード受理Ｃｎｆ」を受信して、ＲＲＢＰにより指定された時点で、ＰＡＣＣＨを介して基地局コントローラＢＳＣの無線リソースＲＲへプロトコル・メッセージ「パケット・ダウンロード受理」を送信する。
２５．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット・ダウンロード受理」を受信して、プリミティブ「ダウンロード受理Ｃｎｆ」をＯＴＡクライアント・コンテキストへ送信する。
２６．ＯＴＡクライアント・コンテキストは、プリミティブ「ダウンロード受理Ｃｎｆ」を受信し、タイマーＴ３０２を停止して、ＯＴＡクライアント・コンテキストは、タイマーＴ４００を始動すると共に、「ソフトウェア・ダウンロード」状態に進む。ＯＴＡクライアント−コンテキストはダウンロードを開始して、無線リソースＲＲへプリミティブ「データＲｅｑ」を送信することにより、ダウンロードされるソフトウェアの各種のブロックの送信を開始する。無線ブロックの転送は、従来方式のウィンドウ・プロトコルにより生起する。無線ブロックは、チャネルＰＤＴＣＨ（パケットデータ転送チャネル）を介して送信される。
２７．ＯＴＡクライアントは、無線リソースＲＲからのプリミティブ「データＩｎｄ」の受信を通じて各々の無線ブロックを受信する。各々の受信ブロックで、タイマーＴ４００が再開される。ＯＴＡクライアントは、プリミティブ「データＲｅｑ」を周期的に無線リソースＲＲへ送信することにより、確認応答信号ＡｃｋをＯＴＡクライアント・コンテキストへ送信する。無線リソースＲＲは、関連付けられた制御チャネルＰＡＣＣＨを介してＡｃｋを送信する。ＯＴＡクライアントが、ダウンロードされる最後の無線ブロックに関するＡｃｋを送信する際に、タイマーＴ４００を停止して、タイマーＴ５００を始動すると共に「インストール」状態に進む。プリミティブ「ライセンスＲｅｑ」が無線リソースＲＲへ送信される。
２８．ＯＴＡクライアント・コンテキストは、無線リソースＲＲからのプリミティブ「データＩｎｄ」の受信を通じて各種のメッセージＡｃｋを受信する。受信された各々のＡｃｋにおいてタイマーＴ４０１が再開される。ＯＴＡクライアント・コンテキストが最後の無線ブロックに関するＡｃｋを受信する際に、タイマーＴ４０１を停止して、タイマーＴ５０１を始動すると共に「インストール」状態へ進む。
２９．無線リソースＲＲはプリミティブ「ライセンスＲｅｑ」を受信して、関連付けられた制御チャネルＰＡＣＣＨを介して、プロトコル・メッセージ「パケット・ライセンス要求」を基地局コントローラＢＳＣの無線リソースＲＲへ送信する。
３０．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット・ライセンス要求」を受信して、ＯＴＡクライアント・コンテキストに、プリミティブ「ライセンスＲｅｑ」を送信する。
３１．ＯＴＡクライアント・コンテキストは、プリミティブ「ライセンスＲｅｑ」を受信して、ソフトウェア復号化を実行するための鍵を示すプリミティブ「ライセンスＲｓｐ」を無線リソースＲＲへ送信する。
３２．無線リソースＲＲはプリミティブ「ライセンスＲｓｐ」を受信して、関連付けられた制御チャネルＰＡＣＣＨを介して、プロトコル・メッセージ「パケット・ライセンス応答」を端末ＭＳの無線リソースＲＲへ送信する。
３３．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット・ライセンス応答」を受信して、プリミティブ「ライセンスＲｓｐ」をＯＴＡクライアントへ送信する。
３４．ＯＴＡクライアントは、プリミティブ「ライセンスＲｓｐ」を受信して、受信した鍵を用いてソフトウェアを復号化する。
ａ．復号化動作が成功した場合、ＯＴＡクライアントはプリミティブ「ライセンスＣｎｆ」を無線リソースＲＲへ送信する。
ｂ．復号化動作が不成功であった場合、ＯＴＡクライアントはプリミティブ「ライセンスＲｅｊ」を無線リソースＲＲへ送信して、タイマーＴ５００を停止して、「アイドル」状態に戻る。
３５．無線リソースＲＲはプリミティブ「ライセンスＣｎｆ」を受信して、関連付けられた制御チャネルＰＡＣＣＨを介して、プロトコル・メッセージ「パケット・ライセンス受理」を基地局コントローラＢＳＣの無線リソースＲＲへ送信する。
３６．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット・ライセンス受理」を受信して、ＯＴＡクライアント・コンテキストに、プリミティブ「ライセンスＣｎｆ」を送信する。
３７．ＯＴＡクライアント・コンテキストは、プリミティブ「ライセンスＣｎｆ」を受信して、実行されるテストに関する情報を示すプリミティブ「テスト記述Ｒｅｑ」を無線リソースＲＲへ送信する。
３８．無線リソースＲＲはプリミティブ「テスト記述Ｒｅｑ」を受信して、関連付けられた制御チャネルＰＡＣＣＨを介してプロトコル・メッセージ「パケット・テスト記述」を端末ＭＳの無線リソースＲＲへ送信する。
３９．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット・テスト記述」を受信して、プリミティブ「テスト記述Ｒｅｑ」をＯＴＡクライアントへ送信する。
４０．ＯＴＡクライアントは、プリミティブ「テスト記述Ｒｅｑ」を受信し、タイマーＴ５００を停止して、「現場テスト」状態に進む。ＯＴＡクライアントは、ＯＴＡクライアント・コンテキストにより指示された通り、ダウンロードされたソフトウェアに対してテストを実行する。
ａ．テストが不成功であった場合、ＯＴＡクライアントはプリミティブ「インストールＲｅｊ」を無線リソースＲＲへ送信して、「アイドル」状態に戻る。
ｂ．テストが成功した場合、ＯＴＡクライアントはプリミティブ「インストールＣｎｆ」を無線リソースＲＲへ送信し、新規ソフトウェアを起動して、「アイドル」状態に戻る。
４１．無線リソースＲＲはプリミティブ「インストールＣｎｆ」を受信して、関連付けられた制御チャネルＰＡＣＣＨを介して、プロトコル・メッセージ「パケット・インストール受理」を基地局コントローラＢＳＣの無線リソースＲＲへ送信して、端末ＭＳの無線インターフェースを再設定する。
４２．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケット・インストール受理」を受信し、ＯＴＡクライアント・コンテキストへプリミティブ「インストールＣｎｆ」を送信して、標準に定義されたリソースを解放する手続きを開始し、当該手続きが終了したならば、標準に定義されたハンドオーバー手続きを継続する。
４３．ＯＴＡクライアント・コンテキストは、プリミティブ「インストールＣｎｆ」を受信して、「アイドル」状態に戻る。

図１９に開示した手続きは、基本ソフトウェアのダウンロード・手続きを示すものである。

本手続きは、当業者には理解されるように、標準に定義された回線呼用のＧＳＭからＵＭＴＳへのシステム間ハンドオーバー手続きに組込まれていてよい。

特に、組込みは、ＭＳＣから基地局サブシステム・アプリケーション部（ＢＳＳＡＰ）プロトコルの「ハンドオーバー・コマンド」メッセージを受信してから、ＭＳへＲＲプロトコルの「システム間からＵＴＲＡＮへのハンドオーバー・コマンド」メッセージを送信する間に、ＲＲ層において行なうことができる。

本発明は、現在の基準により定義されている全ての可能なシステム間ハンドオーバー手続きに一般化することができる。

例えば、当業者には理解されるように、本手続きは、標準に定義の通り、回線呼用のＵＭＴＳからＧＳＭへのシステム間ハンドオーバー手続きに組込むことができる。特に、組込みは、ＭＳＣから無線アクセス・ネットワーク・アプリケーション部（ＲＡＮＡＰ）プロトコルの「再配置コマンド」メッセージを受信してから、ユーザー設備（ＵＥ）へ無線リソース制御（ＲＲＣ）プロトコルの「ＵＴＲＡＮからのハンドオーバー・コマンド」メッセージを送信するまでの間に、無線リソース制御（ＲＲＣ）層で行なうことができる。

本発明はまた、未だ標準化されていないシステム間ハンドオーバー手続き、例えば、国際移動通信２０００（ＩＭＴ２０００）およびＷＬＡＮまたはＩＥＥＥ８０２．１６あるいはＩＥＥＥ８０２．２０システム間のシステム間ハンドオーバー手続きとして一般化することができる。

当業者には明らかなように、本発明は、音声通話の場合、特に回線方式呼において、呼を中断することなく基本ソフトウェアのダウンロードの実行を可能にする。これは、例えば、１個以上のパケット・チャネル、例えばＰＤＴＣＨ ＧＰＲＳチャネルを割当てることにより、回線通信に利用される回線方式チャネル、例えばＴＣＨ（トラフィック・チャネル）ＧＳＭチャネルと並行して、ＧＳＭ／ＧＰＲＳの場合に可能である。

この特徴により、音声、データ、およびソフトウェアのダウンロードの間での優先順位付けを管理することができる。

本発明は、ＧＳＭ／ＧＰＲＳシステムを参照するに、上述のシステムの無線チャネルを用いることにより開示されているが、当業者には理解されるように、本発明は例えば「汎用」チャネルを用いて適用されてもよい。

「汎用」チャネルを用いることができる例として、文献に記載の通り、ＯＴＡサーバからＯＴＡクライアントへの基本ソフトウェアのダウンロード手続きへの「汎用」チャネルの使用が挙げられる。

システム間ハンドオーバーの場合、「汎用」チャネルを使用する実装方式により、例えば図１８に開示した手続きを採用して、ＯＴＡサーバからＯＴＡクライアントへの基本ソフトウェアのダウンロード手続きを上述の「汎用」チャネルを介して同時に利用しながら、例えばＧＳＭ／ＧＰＲＳシステム等のアクティブなシステムの無線チャネルを介したアクティブな接続を維持することが予見できる。

「汎用」チャネルは、基本ソフトウェアのダウンロード手続きの全体または一部、例えばＯＴＡサーバからＯＴＡクライアントへの基本ソフトウェアの送信、だけに利用することができる。

「汎用」チャネルを部分的に利用する場合、基本ソフトウェアのダウンロード手続きの残りの部分は、アクティブなシステムの無線チャネルを用いて実装することができる。

「汎用」チャネルを採用することにより、アクティブなシステムに関連付けられた無線リソースをより効率的にロードして、他のユーザーが利用できるようにして、基本ソフトウェアのダウンロード手続きをはるかに高速に実行することが可能になる。これは、「汎用」チャネルがこの種の動作専用のチャネルであるためである。

本発明の更なる実施形態として、当業者には公知のように、例えば、端末が「アイドル」状態である場合に、ＧＳＭ／ＧＰＲＳからＵＭＴＳへ等、２種のシステム間でセル再選択手続きをも管理可能にすることである。

先に述べたように、プリミティブおよび関連フィールドに名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。

この拡張は、ＯＴＡクライアントと端末ＭＳ側の無線リソースＲＲとの間に以下のプリミティブを導入するものである。
−ダウンロード開始Ｒｅｑ：このメッセージは、ＯＴＡクライアントから端末ＭＳ側の無線リソースＲＲへ送信される。

ＧＳＭ／ＧＰＲＳの場合、このプリミティブに提供されるフィールドは少なくとも、
ＯＴＡクライアントＩＤ：要求を実行しているＯＴＡクライアントを識別する
および、ＯＴＡサーバと基地局コントローラＢＳＣ側の無線リソースＲＲとの間の以下のプリミティブの組の一つである。
−要求ダウンロード開始Ｉｎｄ：このメッセージは、基地局コントローラＢＳＣ側の無線リソースＲＲからＯＴＡクライアントへ送信される。

ＧＳＭ／ＧＰＲＳの場合、プリミティブに提供されるフィールドは、以下のうち少なくとも一組である。
ＯＴＡクライアントＩＤ：要求を実行しているＯＴＡクライアントを識別する。

以下に、プリミティブ「要求ダウンロード開始Ｉｎｄ」を受信した際のＯＴＡクライアント・コンテキストの端末ＭＳに関するコンテキストの応答を示す。
−ＯＴＡクライアント・コンテキストが「アイドル」状態ではない場合、プリミティブは無視され、手続きは継続されない。
−ＯＴＡクライアント・コンテキストは「ダウンロード開始」状態へ進む。
−プリミティブ「ダウンロード開始Ｉｎｄ」は、各種の可能なダウンロードを示すと共に、ＯＴＡクライアントへ送信される。

図１９を参照するに、ネットワークに存在する異なるエンティティ間の相互作用を指摘しつつ、セル再選択の場合における基本ソフトウェアのダウンロード手続きの動作を示す。手続き自体の残りの部分が図１８の記述と同一であるため、以下に、手続きの第一フェーズの動作を詳述する。
Ｉ．ＯＴＡクライアントおよび考慮しているＯＴＡクライアントに関するＯＴＡクライアント・コンテキストは「アイドル」状態である。
ＩＩ．物理層から到着したセル再選択命令を受信したならば、ＯＴＡクライアントは、「アイドル」状態から「ダウンロード開始」状態に進み、タイマーＴ１００を始動して、自身の識別子を指定するプリミティブ「ダウンロード開始Ｒｅｑ」を無線リソースＲＲへ送信する。無線リソースＲＲは、ＯＴＡクライアントの識別子をローカルに保存する。
ＩＩＩ．無線リソースＲＲは、プリミティブ「ダウンロード開始Ｒｅｑ」を受信する。無線リソースＲＲは、パケット・ランダム・アクセス・チャネルＰＲＡＣＨを介して、標準により定義されたプロトコル・メッセージ「パケットチャネル要求」を送信して、ユーザーによる基本ソフトウェアのダウンロード要求およびＯＴＡチャネルの識別子を指定する。オペレータによりインストールされたＧＰＲＳ設定が、パケット・ブロードキャスト制御チャネルＰＢＣＣＨおよびパケット共通制御チャネルＰＣＣＣＨにより構成されたマスターチャネルを提供しない場合、上述の手続きは、手続き自体の先頭の２個のメッセージを、上述のパケット・ランダム・アクセス・チャネルＰＲＡＣＨおよびパケット・アクセス許可チャネルＰＡＧＣＨではなく、ＧＳＭのランダム・アクセス・チャネルＲＡＣＨおよびアクセス許可チャネルＡＧＣＨにマッピングすることにより引き続き有効である。
ＩＶ．基地局コントローラＢＳＣの無線リソースＲＲは、プロトコル・メッセージ「パケットチャネル要求」を受信する。これはソフトウェアのダウンロード要求とみなさられるため、受信メッセージにより読まれるＯＴＡクライアントの識別子を指定するプリミティブ「要求・ダウンロード開始Ｉｎｄ」をＯＴＡクライアント・コンテキストへ送信する。
Ｖ．ＯＴＡサーバがプリミティブ「要求・ダウンロード開始Ｉｎｄ」を受信して検証し、その状態で指示されたＯＴＡクライアントに関するＯＴＡクライアント・コンテキストは、以下のように振舞う。
ａ．状態が「アイドル」である場合、ＯＴＡクライアント・コンテキストは「ダウンロード開始」状態へ進み、タイマーＴ１０１を始動して、要求されたダウンロードを示すと共に、プリミティブ「ダウンロード開始Ｉｎｄ」を無線リソースＲＲへ送信する。
ｂ．状態が「アイドル」でない場合、メッセージは無視される。
ＶＩ．無線リソースＲＲは、プリミティブ「ダウンロード開始Ｉｎｄ」を受信する。無線リソースＲＲは、無線リソース管理ＲＲＭに対し、当該ソフトウェアのダウンロードを可能にするために必要なダウンリンク・リソースを要求する。
ａ．リソースが利用可能である場合、無線リソースＲＲは制御チャネルＰＡＧＣＨを介して、プロトコル・メッセージ「パケット・ダウンロード要求」を端末ＭＳの無線リソースＲＲへ送信し、端末がダウンロードを実行するチャネルＰＤＣＨ、ＲＲＢＰ、および要求されたダウンロードを示す。
ｂ．リソースが利用できない場合、無線リソースＲＲはプリミティブ「ダウンロードＮａｃｋＩｎｄ」をＯＴＡクライアント・コンテキストへ送信する。
ＶＩＩ．端末ＭＳの無線リソースＲＲは、プロトコル・メッセージ「パケット・ダウンロード要求」を受信し、チャネルＰＤＣＨを設定して、プリミティブ「ダウンロード要求Ｉｎｄ」を送信する。
ＶＩＩＩ．ＯＴＡクライアントは、プリミティブ「ダウンロード要求Ｉｎｄ」を受信する。端末がダウンロードを実行可能である場合、ＯＴＡクライアントは、自身の識別子を指定するプリミティブ「ダウンロードＡｃｋＩｎｄ」を送信する。無線リソースＲＲは、ＯＴＡクライアントの識別子をローカルに保存する。

本手続きは、図１８に関して述べる手続きの第６番以降の段階を実行することにより継続される。

ＧＳＭ／ＧＰＲＳシステムのアクセス・ネットワークを参照しつつ、本発明に従い記述されたアーキテクチャおよび方法を開示してきた。

本発明はまた、ＵＭＴＳ、ＵＴＲＡＮ（ＵＭＴＳ地上波無線アクセス・ネットワーク）その他の任意のアクセス・ネットワーク、例えばＷＬＡＮ、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０等のアクセス・ネットワークにも適用することができる。

例えば、ＵＴＲＡＮの場合、本発明はＯＴＡクライアントとＯＴＡサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをＵＭＴＳシステムのＲＲＣ層に組込んで実装することができる。

本発明を、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて開示してきた。本発明はまた、コア・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて実装することもできる。この場合、例えばＧＳＭ／ＧＰＲＳおよびＵＭＴＳシステムのパケット・スイッチ・コア・ネットワークを考慮すれば、本発明は、ＯＴＡクライアントとＯＴＡサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをコア・ネットワークの端末およびサービス提供ＧＰＲＳサポート・ノード（ＳＧＳＮ）ノードの各々のＧＰＲＳ移動管理（ＧＭＭ）層に組込むことにより実装することができる。

より具体的には、ＧＳＭ／ＧＰＲＳの場合、ＧＰＲＳ移動管理（ＧＭＭ）層は、新規のプロトコル・メッセージを導入して関連フィールドをＯＴＡサーバとＯＴＡクライアントの間で交換することにより変更される。同じ方式をＵＭＴＳシステムに適用することもできる。

本発明を、システム間ハンドオーバー手続きの実行中における１個の基本ソフトウェアのダウンロードおよび起動を考慮することにより開示してきた。

当業者には明らかなように、当該基本ソフトウェアはインストールして直ちに動作させるのではなく、端末にダウンロードして保存してもよい。

この更なる実施形態によれば、ネットワークまたはユーザーからの要求があれば、基本ソフトウェアをインストールして引き続き実行させることが可能である。無線端末ＵＥ／ＭＳが十分なメモリおよび処理能力を有していれば、ダウンロードされた基本ソフトウェアを、現在動作中の既存システムと並行して保存およびインストールすることができる。

このオプションは、端末ＵＥ／ＭＳのマルチ・モード動作を可能にするために有用である。すなわち、このオプションにより、基本ソフトウェアをダウンロードする必要なしに、端末をある動作モードから別の動作モードへ切り替えることが可能になる。

要約すれば、本発明により、少なくとも以下の利点が得られる。
−ノードまたは物理的なインターフェースが既存のものに一切追加されないため、第二および第三世代ネットワークに存在しているプロトコルおよびノードに対する影響が最小限に抑えられる。
−手続きのシグナリング・フェーズが標準で定義されたものと同一のシグナリング・チャネルを使用する一方、ソフトウェアのダウンロード手続き用途にのみデータ・チャネルが割当てられるため、無線リソースの占有が最小限に抑えられる。
−本発明は既存の第二および第三世代ネットワークを利用するため、従来技術で言及されているように将来的なＩＰ利用ＵＭＴＳのリリースを待たなくてもよい。

特に、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を使用する場合、ＲＲ（無線リソース）プロトコルが、新規の基本ソフトウェアを端末がダウンロードできるようにする若干の変更と一体化されているため、ネットワークはソフトウェアのダウンロード手続きおよび関連する無線リソースを完全に制御することができ、これにより、例えば、ＧＳＭ／ＧＰＲＳ、ＩＳ９５、ＰＤＣ（デジタル・セルラー電話）、あるいは例えばファミリＩＭＴ２０００に属する第三世代セルラー方式等の第二世代のセルラー方式を実装することができる。

従来技術による多モード端末を表わす図である。 本発明の一実施形態によるＧＳＭ／ＧＰＲシステムのネットワーク・アーキテクチャを示す図である。 図１のアークテクチャの再設定可能な端末を表わす図である。 無線端末側でクライアントにより実行されるプロトコル・ステップの状態遷移図である。 基地局コントローラ側でサーバにより実行されるプロトコル・ステップの状態遷移図である; サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。 回線呼に対するＧＳＭからＵＭＴＳへのシステム間ハンドオーバー手続きを示す図である。 無線端末を再設定するソフトウェアのダウンロード手続きの詳細を示す図である。 セル再選択の場合における基本ソフトウェアのダウンロード手続きを示す図である。

Claims (29)

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. 少なくとも１個のコンピュータのメモリにロード可能であって、請求項１４〜２６に記載のステップのいずれかを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物のコンピュータ・プログラムの組。