(57)【要約】  通信網と前記通信網に属する少なくとも１つの無線端末（ＵＥ／ＭＳ）とを含んだ、再設定可能な無線端末を設定するためのネットワークアーキテクチャー及び方法。このアーキテクチャーは、通信網に接続されたノード（ＯＴＡサーバ）を更に含み、該ノード（ＯＴＡサーバ）が、通信網に対してトランスペアレントに無線接続を介して無線端末（ＵＥ／ＭＳ）を再設定するのに適した基本ソフトウエアモジュールを含む。
2008518529.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信システムに従って動作可能であると共に少なくとも１つの無線端末（ＵＥ／ＭＳ）を含んだ通信網を含むネットワークアーキテクチャーであって、前記無線端末（ＵＥ／ＭＳ）は前記通信網に属すると共に前記所定の通信システムを用いることにより前記通信網内での情報の交換を管理するためのモジュールを含み、
-  前記通信網に接続された少なくとも１つのノード（ＯＴＡサーバ）が、
-  前記無線端末（ＵＥ／ＭＳ）を設定するためのプロトコルスタックの少なくとも１つの要素セットを実装するように構成された基本ソフトウエアモジュールのセット、
を備えること、及び
-  前記無線端末及び前記ノードがそれぞれ無線ソフトウェアモジュールを備え、該無線ソフトウェアモジュールが、前記通信網を介した前記無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線接続を管理すると共に前記無線端末（ＵＥ／ＭＳ）を少なくとも部分的に設定するための前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記通信網に対してトランスペアレントにダウンロードするよう構成されること、
を特徴とするネットワークアーキテクチャー。
【請求項２】
前記通信網が無線アクセスネットワークとコアネットワークからなり、前記ノードが前記コアネットワークに接続されることを特徴とする請求項１に記載のアーキテクチャー。
【請求項３】
前記無線アクセスネットワークが第二世代（ＧＥＲＡＮ）ネットワーク通信システムに従って動作することを特徴とする請求項２に記載のアーキテクチャー。
【請求項４】
前記無線アクセスネットワークが第三世代（ＵＴＲＡＮ）ネットワーク通信システムに従って動作することを特徴とする請求項２に記載のアーキテクチャー。
【請求項５】
前記コアネットワークがパケットドメインを含むことを特徴とする請求項２に記載のアーキテクチャー。
【請求項６】
前記パケットドメインが少なくとも１つのサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）と少なくとも１つのゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）とを含み、前記ノード（ＯＴＡサーバ）が前記少なくとも１つのゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）に直接接続されることを特徴とする請求項５に記載のアーキテクチャー。
【請求項７】
前記無線接続が前記通信網のユニバーサルチャンネルを介して確立されることを特徴とする請求項１に記載のアーキテクチャー。
【請求項８】
前記無線接続が前記通信網の無線チャンネルを介して確立されることを特徴とする請求項１に記載のアーキテクチャー。
【請求項９】
前記無線端末が少なくとも２つの基本ソフトウエアを記憶できるメモリを備えること、及び前記無線端末が前記少なくとも２つの基本ソフトウエア間で切り換えるためのマルチモード作動モジュールを備えることを特徴とする請求項１に記載のアーキテクチャー。
【請求項１０】
前記無線端末がクライアント（ＯＴＡクライアント）として設定され、前記ノード（ＯＴＡサーバ）がサーバとして設定されることを特徴とする請求項１に記載のアーキテクチャー。
【請求項１１】
前記情報が少なくとも前記基本ソフトウエアモジュールを含むことを特徴とする請求項１に記載のアーキテクチャー。
【請求項１２】
-  前記通信網がブロードキャスト／マルチキャスト能力を備え、
-  前記少なくとも１つの無線端末が前記ブロードキャスト／マルチキャスト能力を管理できるアプリケーションを備え、
そのために前記通信網が前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記少なくとも１つの無線端末にマルチキャストダウンロードできるように構成されることを特徴とする請求項１に記載のアーキテクチャー。
【請求項１３】
前記少なくとも１つの無線端末と前記ノードとの間で前記無線接続を確立するためにプロトコルＴＣＰ／ＩＰが用いられることを特徴とする請求項１に記載のアーキテクチャー。
【請求項１４】
前記基本ソフトウエアモジュールのセットが、別の通信システムを用いて前記無線端末（ＭＳ）を少なくとも部分的に再設定するのに適していることを特徴とする請求項１に記載のアーキテクチャー。
【請求項１５】
所定の通信システムに従って動作する通信網に属する少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）を設定するための方法であって、無線端末（ＵＥ／ＭＳ）は前記所定の通信システムを用いることにより前記通信網内で情報を交換でき、
-  プロトコルスタックの少なくとも１つの要素セットを用いて前記無線端末（ＵＥ／ＭＳ）を設定するための基本ソフトウエアモジュールのセットを備えた少なくとも１つのノード（ＯＴＡサーバ）を前記通信網に接続するステップ；
-  前記通信網を介する前記無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線（ＯＴＡ）接続を確立するステップ；
-  前記無線端末（ＵＥ／ＭＳ）を少なくとも部分的に設定するための前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記ノード（ＯＴＡサーバ）から前記再設定可能な無線端末（ＵＥ／ＭＳ）に前記通信網に対してトランスペアレントにダウンロードするステップ；
を特徴とする方法。
【請求項１６】
前記無線（ＯＴＡ）接続を確立するステップが、プロトコルステップを表す下記ステップからなる少なくとも１セット、すなわち
-  前記少なくとも１つのモジュールをダウンロードするよう要求するステップ；
-  前記少なくとも１つの無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）とが相互に認証するステップ；
-  前記ノードからダウンロード可能な前記少なくとも１つのモジュールを受理することについて前記無線端末の能力を検査するステップ；
-  ダウンロードオプションに関する情報を提供するステップ；
-  前記少なくとも１つのモジュールをブロックに分割するステップ；
-  前記ブロックを前記ノード（ＯＴＡサーバ）から前記少なくとも１つの無線端末（ＵＥ／ＭＳ）に送信するステップ；
-  プロトコルスタックの１つの要素セットを用いて前記無線端末（ＵＥ／ＭＳ）を設定すると共に前記要素セットをテストするために前記少なくとも１つのモジュールを再構成すべく前記ブロックを再アセンブルするステップ；
-  前記要素セットを前記無線端末にインストールするステップ；
を実行することによりプロトコルメッセージを交換することを含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記プロトコルメッセージを交換するステップが、
-  前記無線端末（ＵＥ／ＭＳ）にダウンロードされた前記ブロックの構造を監視するステップ；
を更に含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記プロトコルメッセージを交換するステップが、
-  無線（ＯＴＡ）接続の実行が可能な時間を制限するタイマーセット（Ｔ１００、Ｔ２００、Ｔ３００、Ｔ４００、Ｔ５００、Ｔ１０１、Ｔ２０１、Ｔ３０１、Ｔ３０２、Ｔ４０１、Ｔ５０１）を管理するステップ；
を更に含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記プロトコルメッセージを交換するステップが、
-  各プロトコルステップに少なくとも１対のタイマーを割り当てるステップであって、前記１対のタイマーのうち第１のタイマーは前記無線端末（ＵＥ／ＭＳ）により実行されたプロトコルステップを監視し、第２のタイマーは前記ノード（ＯＴＡサーバ）により実行されたプロトコルステップを監視し、前記タイマーの各々は１つのプロトコルステップが開始されたときスタートさせ、前記１つのプロトコルステップが実行されたとき停止させる前記ステップ；
を更に含むことを特徴とする請求項１６に記載の方法。
【請求項２０】
前記相互認証ステップが「チャレンジ応答」方式に基づいていることを特徴とする請求項１６に記載の方法。
【請求項２１】
前記少なくとも１つの基本ソフトウエアモジュールをブロックに分割する前記ステップが、１〜２キロバイトの大きさのブロックに分割するステップを含み、前記ブロックを送信する前記ステップが、ウインドウの大きさが少なくとも１つの基本ソフトウエアモジュールを分割して得たブロックの大きさに一致するウインドウプロトコルを管理するステップを含むことを特徴とする請求項１６に記載の方法。
【請求項２２】
前記要素セットを前記無線端末にインストールする前にライセンスを要求することを特徴とする請求項１６に記載の方法。
【請求項２３】
前記少なくとも１つの基本ソフトウエアモジュールを前記無線端末にダウンロードする前に鍵を用いて暗号化することを特徴とする請求項１５に記載の方法。
【請求項２４】
前記少なくとも１つの無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の前記無線接続を確立するためにＴＣＰ／ＩＰプロトコルを用いることを特徴とする請求項１５に記載の方法。
【請求項２５】
少なくとも２つの基本ソフトウエアを前記再設定可能な無線端末（ＵＥ／ＭＳ）に記憶する更なるステップを特徴とする請求項１５に記載の方法。
【請求項２６】
前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをダウンロードする前記ステップが、
-  別の通信システムを用いて前記無線端末（ＭＳ）を少なくとも部分的に再設定するのに適した基本ソフトウエアモジュールのセットをダウンロードするステップ；
を含むことを特徴とする請求項１５に記載の方法。
【請求項２７】
前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをダウンロードする前記ステップが、
-  前記無線端末（ＵＥ／ＭＳ）又は前記通信網から来る要求に応じて前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをインストールし実行させるステップ；
を含むことを特徴とする請求項１５に記載の方法。
【請求項２８】
請求項１５〜２７のいずれか一項に記載の方法を実行することにより設定可能な無線端末（ＵＥ／ＭＳ）。
【請求項２９】
請求項１５〜２７のいずれか一項に記載の方法を実行することにより設定可能な無線端末（ＵＥ／ＭＳ）を設定するためのネットワークノード（ＯＴＡサーバ）。
【請求項３０】
少なくとも１つのコンピュータのメモリにロードできると共に、請求項１５〜２７のいずれか一項に記載の方法を実行するためのソフトウェアコード部分を含んだコンピュータプログラムプロダクト又はコンピュータプログラムプロダクトのコンピュータプログラムセット。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に本発明は無線通信網及び無線通信網を使用する再設定可能な無線端末に関する。特に、本発明は再設定可能な無線端末の設定に関するものであり、この設定は、無線通信網から無線（ＯＴＡ）でダウンロードされた基本ソフトウエアを前記無線端末にインストールすることによって実行する。
【背景技術】
【０００２】
文献（非特許文献１及び非特許文献２）から、端末、基地局及びネットワークノードなどの再設定可能なシステムは、動作機能を随意に再設定できる装置であることが知られている。例えば、ＧＳＭ／ＧＰＲＳ（Global System for Mobile communication/General Packet Radio Service）などの第二世代システム（２Ｇ）と共に動作し得る再設定可能な無線端末は、ＵＭＴＳ（Universal Mobile Telecommunication System）又はＣＤＭＡ  ２０００（Code Division Multiple Access 2000）、又はＷＩ-ＦＩ（Wlrless Fidelity）又はＤＶＢ-Ｔ（Digital Video Broadcasting Terrestrial）システムなどのような第三世代システム（３Ｇ）と共に動作できるように再設定することができる。
【０００３】
「システム」とは、特定の機能（例えば、通信網として動作する機能）を実行するために所定の基準に従って相互に協調して働く（すなわち「規格」に従って協調して働く）複数の要素を意味する。
【０００４】
本明細書におけるシステムの例はＧＳＭシステム、ＧＰＲＳシステム、ＵＭＴＳシステム、ＷＬＡＮ（Wireless Local Area Network）システムなどであり、その各々は対応する規格に準拠している。
【０００５】
端末の再設定を実行するためには、端末の動作機能を再設定可能な技術を用いて実現する必要がある。このことに関し、再設定可能な端末又はデバイスは例えば、複数のＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）及びマイクロプロセッサにより構成された再プログラム可能なハードウェアを備えており、最低水準であっても該デバイスの単一機能はソフトウェアコードにより実行される。よって、再プログラム可能なデバイスを再設定するためには、デバイス自体のハードウェアを管理する基本ソフトウエアを取り換えるだけで十分である。
【０００６】
本明細書において「基本ソフトウエア」なる用語は、例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳなどのような当該システムのプロトコルスタックの無線インターフェース又は下位層（例えばＬ１、Ｌ２、Ｌ３）と上位層（例えばＬ４〜Ｌ７）との両方を定義すると共にライブラリに編成されたソフトウェアを意味する。
【０００７】
知られているように、電気通信分野では、機能の分類をするために最も用いられている方法はＯＳＩモデル（Open System Interconnection）である。機能は層のスタック形式で表された機能面又は機能層に分類される。
【０００８】
各層は、直ぐ下の層により提供されたサービスの改善となっているサービスを直ぐ上の層に提供する。
一般に最下層（層１）は情報を物理的に送信することを目的とする。
【０００９】
ＯＳＩ仕様によると、標準的な層数は７であり、それぞれ物理層、接続層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層及びアプリケーション層である。各システム、例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳなどは、前記標準スタックの必要部分を実装する。
【００１０】
無線端末を考えると、再設定可能なハードウェアを使用する場合に得られる利点は多いが、１つの利点は明らかに即効的なものであり、無線端末を該端末が位置する領域（動作範囲）をカバーするシステムに従って再設定できることである。したがって、端末がＧＳＭ／ＧＰＲＳのような第二世代システムによりカバーされる領域内で使用される場合には、前記システムを受信可能にすべく端末を設定でき、同様に、ＵＭＴＳのような第三世代システムによりカバーされた領域内では、それに応じて端末を設定できる。
【００１１】
ソフトウェアコードを下記の少なくとも３つの異なる方法で端末に転送又はダウンロードできることが知られている。
-  無線モバイル端末の内部に挿入されるＳＩＭ（加入者識別モジュール）を用いることによりスマートカードを介する方法。
-  例えば赤外線／シリアル／ＵＳＢポートを介したパーソナルコンピュータとのリンクを用いることにより外部接続を介する方法。
-  特定の無線チャンネルを用いることにより無線又は無線（ＯＴＡ）[over-the-air]を介する方法。
【００１２】
ソフトウェアのダウンロードに関して、ソフトウェアを端末にダウンロードすることを管理可能にする一般プロトコルの基本的なステップは、ＳＤＲフォーラム（Software Defined Radio Forum）のフレームワークにおいて定義されている（ＵＲＬ：www.sdrforum.org）。
ＳＤＲフォーラムにより定義されたプロトコルはクライアント-サーバ型である。
【００１３】
ダウンロードのプロトコル・ステップは以下の通りである。
-  ダウンロード開始：ダウンロードすべきソフトウェアが存在するサーバに対して、端末がソフトウェアのダウンロードの意思を伝えるステップ。
-  相互認証：端末とサーバが互いに認証する。
-  能力相互通知：サーバがダウンロードすべきソフトウェアについての能力情報を伝え、端末がソフトウェアを端末メモリにロード、インストール、及び実行が可能であるか否かを検証する。
-  ダウンロード受理：サーバが端末にダウンロード、インストール及び支払請求のオプションを伝える。端末はサーバにより示された指示が受理可能か否かを決める。
-  ダウンロード及び完全性テスト：ソフトウェアのダウンロード中、受信したコードがテストされる。端末は間違って受信した無線ブロックの再送信を要求する。
-  インストール：インストールステップ中、ソフトウェアの支払請求及びライセンシング条件がサーバから提供される。
-  現場テスト：ソフトウェアを開始する前に、端末はソフトウェアコードと共にダウンロードされたテストベクタを用いていくつかのテストを実行する。
-  否認防止相互通知：いったんソフトウェアコードがインストールされテストされると、端末はインストールが成功した旨をサーバに確認して例えば支払請求手順を開始する。
【００１４】
従来技術、例えば非特許文献２から、無線又はＯＴＡを介したソフトウェアのダウンロードでは無線チャンネルを端末が使用することが予想される。また、ソフトウェアコードのダウンロードは無線チャンネルの類型に依存して下記の２つの異なる方式で実行できることが知られている。
-  「帯域外」方式：現在のシステムから独立した「ユニバーサル」チャンネルによる。例えば端末がスイッチオンされたとき、前記チャンネルに自動的にチューニングし、動作範囲内で動作しているシステムに対して基本ソフトウエアのダウンロードを実行する。
-  「帯域内」方式：第二世代及び第三世代（それぞれＧＳＭ／ＧＰＲＳ及びＵＭＴＳなど）の標準的なセルラーシステムの無線チャンネルを用いることによる。この方式では、既にこれらのチャンネルの１つで動作している端末が、現在使用されているシステムとは異なるシステムに関する基本ソフトウエアを受信する。例えば、ＧＳＭ／ＧＰＲＳなどの第二世代システムで動作している再設定可能な端末は、自身が動作している第二世代無線チャンネルを使用することによりＵＭＴＳなどの第三世代システムのダウンロードを実行できる。
【００１５】
「帯域外」ソフトウェアダウンロードの例は、例えば日本国特許出願第２００１０６１１８６号に記載されている。この文献には、ソフトウェアコンテンツを無線でダウンロードするためのシステム及び方法が記載されている。無線端末がスイッチオンされると、無線端末は動作範囲内の現在のシステムは何であるかをユニバーサルチャンネル上で探り、指示されたシステムに関するソフトウェアダウンロードを実行する。
【００１６】
「帯域内」ソフトウェアダウンロードの例は、例えば米国特許出願第２００３／０１６３５５１号に記載されている。この文献には、下記のものを用いることによりソフトウェアを無線でダウンロードするためのシステム及び方法が記載されている。
-  サーバと端末との間での交渉ステップ（能力相互通知、認証、支払請求など）中における専用チャンネル、及び
-  利用可能な無線リソースに負担をかけることなく、できるだけ多くのユーザーにダウンロードサービスを同時に提供するために、ダウンロード手順中における共用共通チャンネル。
【００１７】
「帯域内」ダウンロード方式を考えると、非特許文献３には、基本ソフトウエアのダウンロードを管理できるように、いくつかのプロトコルといくつかのネットワークノード、例えば無線アクセスノード及び／又はコアネットワークノードを大幅に変更することが提案されている。
【００１８】
このような変更は設備製造業者及びネットワークオペレータに相当な努力を課するものであり、既存のセルラーシステムの規格に劇的な影響を与える。したがって、公知の技術が示す限界は、再設定可能な端末のための基本ソフトウエアのダウンロードの管理を既存のセルラーネットワーク（例えばＧＳＭ／ＧＰＲＳ又はＵＭＴＳ）に追加することが望まれるとき、プロトコル及びネットワークノードに対して大幅な変更が必要となることである。
【００１９】
帯域外の方式を考えると、従来技術によると、専用無線チャンネルを必要とし、よってその実装のためにネットワーク内に専用ネットワーク装置又はネットワークノードを実装する必要がある。
【００２０】
要するに、出願人は帯域内及び帯域外の両方のソフトウェアダウンロードの場合において公知の従来技術では再設定可能な無線端末を設定するためにいくつかのプロトコルといくつかのネットワークノードを大きく変更することに注目した。
【特許文献１】日本国特許出願第２００１０６１１８６号
【特許文献２】米国特許出願第２００３／０１６３５５１号
【非特許文献１】J.Mitola, 「The Software Radio Architecture」, IEEE Communications Magazine,１９９５年５月
【非特許文献２】E.Buracchini, 「The Software Radio Concept」, IEEE Communications Magazine,２０００年９月
【非特許文献３】AAVV,「Architecture of IP based Network Elements Supporting Reconfigurable Terminals」, SCOUT Workshop 16 September 2003
【発明の開示】
【発明が解決しようとする課題】
【００２１】
発明の概要
したがって本発明の目的はネットワークノードのアーキテクチャー及びプロトコルを変更することなく無線端末を再設定するために基本ソフトウエアのダウンロードを管理することである。
【課題を解決するための手段】
【００２２】
本発明の上記の目的は特許請求の範囲に記載の方法、ネットワークアーキテクチャー及びコンピュータプログラムプロダクトにより達成される。
【００２３】
本発明により、アーキテクチャー、方法及び関連のコンピュータプログラムプロダクト又はコンピュータプログラムプロダクトのセット（少なくとも１つのコンピュータのメモリにロード可能であり且つ該プロダクトがコンピュータ上で実行されるとき本発明の方法のステップを実行するためのソフトウェアコード部分を含む）が提供される。明細書においてこのようなコンピュータプログラムプロダクトというときは、本発明の方法の実行に協調するようコンピュータシステムを制御するための命令を含んだコンピュータ読取り可能な媒体を意味するものとする。「少なくとも１つのコンピュータ」といっているのは、明らかに本発明を分散モジュール式に実装する可能性を強調する意図である。
【００２４】
具体的には、本発明によると、好ましい態様において提供されるアーキテクチャー及び方法により、端末は無線を介して基本ソフトウエアのダウンロードを実行でき、該基本ソフトウエアによりモバイル無線端末を再設定でき、該アーキテクチャー及び方法は押しつけがましくない(not intrusive)。特に、ダウンロードは、第二世代（例えばＧＳＭ／ＧＰＲＳ、ＩＳ９５（Interim Standard 95）又はＰＤＣ（Phone Digital Cellular）など）、又は第三世代（例えばＩＭＴ  ２０００（International Mobile Telecommunications 2000）ファミリーの無線アクセスシステム）に属し得る使用中のセルラー無線アクセスシステムに対してトランスペアレントに実装できる。
【００２５】
本発明によると、アーキテクチャーは、既存のネットワークプロトコルに影響を与えることなく基本ソフトウエアの無線ダウンロードを管理できるネットワークに接続されたノードを備える。
【００２６】
本発明の好ましい態様によると、コンピュータプログラムプロダクトは、第二世代システムと第三世代システムの両方によってサポートされたＴＣＰ／ＩＰ（Transport Control Protocol/Internet Protocol）プロトコルを利用する。
【００２７】
本発明によると、提案したプロトコルはＳＤＲフォーラムにより与えられた勧告に整合している。
【００２８】
本発明によると、無線（Over The Air）ソフトウェアダウンロードはアクセスネットワークとコアネットワークとにトランスペアレントである。
【００２９】
本発明によると、アーキテクチャーは当該システムから独立しており、第二世代システム（例えばＧＳＭ／ＧＰＲＳ）、第三世代システム（例えばＵＭＴＳ）、及びその他（例えばＤＶＢ、ＷＬＡＮ、８０２．１６）などのような任意の現在又は将来のシステムにおいて実装できる。
【００３０】
本発明によると、基本ソフトウエアが常駐しているサーバ型のノードが提供され、該サーバ型のノードはネットワークに接続されると共に、無線端末上で基本ソフトウエアのダウンロードを実行できる。また、本発明によると、無線端末を再設定するために用いられる方法は押しつけがましくなく、ネットワークがサポートするすべての特徴を利用できる。
【００３１】
以下、好ましいが限定するものではない本発明の態様についての添付図面に関して本発明を説明する。
すべての図面において、同じ構成要素か又は実質的に同じ機能を実装する構成要素を示す際には同じ符号を使用した。
【発明を実施するための最良の形態】
【００３２】
発明の詳細な説明
図１には、第２世代（２Ｇ）及び第３世代（３Ｇ）システムにおいて実装された本発明の一態様が示される。特に、一般ＧＰＲＳ、一般ＵＭＴＳネットワーク（「ネットワーク」）及びサーバ（「ＯＴＡサーバ」）又はネットワークに接続されたノードを備えたネットワークアーキテクチャー又はアーキテクチャーが示されている。
【００３３】
このネットワークは、再設定可能な端末ＵＥ／ＭＳ（ユーザー装置/移動局）と、ＧＰＲＳシステムの無線アクセスネットワークＧＥＲＡＮ（GSM EDGE Radio Access Network）と、ＵＭＴＳシステムのＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と、例えばノードＳＧＳＮ（Serving GPRS Support Node）及びＧＧＳＮ（Gateway GPRS Support Node）により構成されたパケットドメインのコアネットワークとを更に備える。ノードＧＧＳＮは例えばサーバＰＲＯＸＹ（「プロクシ」）を介してインターネット型のネットワーク（「インターネット」）に接続される。
【００３４】
本発明の好ましい態様によると、端末ＵＥ／ＭＳはＯＴＡクライアントというソフトウェアアプリケーションを備え、このソフトウェアアプリケーションは、例えば、コアネットワークのノードＧＧＳＮに直接接続されたＯＴＡサーバからの基本ソフトウエアのダウンロードを管理することができる。当業者には理解されるように、ＯＴＡサーバはまた、例えば公知の種類の１以上の通信デバイスを介してコアネットワークに間接的に接続され得る。
【００３５】
ソフトウェアアプリケーションＯＴＡクライアント及び対応するノードＯＴＡサーバは、例えばトランスポートプロトコルＴＣＰ／ＩＰを利用する。
ＯＴＡサーバのアーキテクチャーはダウンロードセッションがアクティブである各ＯＴＡクライアントに対してコンテキストを与える。ソフトウェアアプリケーションが働くと、各ＯＴＡクライアントに対して、及びＯＴＡサーバにより管理されるクライアント・コンテキストとして定義された対応するコンテキストに対して状態図が与えられる。
【００３６】
好ましい態様によると、機能するソフトウェアは１組の機能するソフトウェアモジュール、好ましくは複数のソフトウェアモジュールからなる。本発明では無線端末ＵＥ／ＭＳを再設定するために、ネットワークにおいて用いられるプロトコルスタックの少なくとも１つの要素セットを実装する基本ソフトウエアモジュールをダウンロードする。
【００３７】
当業者には分かるように、新しい機能の組み込み、更新又はバグの修正を目的として１以上のプロトコル層又はプロトコルスタックの特定層の一部を更新するために、１つの基本ソフトウエアモジュールをダウンロードすることもできる。
【００３８】
図２を参照するに、端末ＵＥ／ＭＳ（端末側）にインストールされたソフトウェアアプリケーションＯＴＡクライアントの状態図を示す。
状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
【００３９】
本発明の好適な実施形態によれば、ＯＴＡクライアントの状態および相対遷移は以下の通りである。
-  「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡクライアント又はクライアントはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアントはこの状態に戻る。
-  「ダウンロード開始」状態：基本ソフトウェアのダウンロードを実行する必要があるとき、例えば、ユーザーがそれを要求するか、又はネットワークにより制御される場合、クライアントはこの状態に入ってタイマーＴ１００を起動する。状態変化が生じた場合にはタイマーＴ１００は停止される。状態変化の前にタイマーＴ１００が終了した場合、クライアントは「アイドル」状態に戻る。
-  「相互認証」状態：この状態で、クライアントはＯＴＡサーバとの相互認証を実行する。サーバから認証要求が来たならば、クライアントはこの状態に入る。クライアントはタイマーＴ２００を起動する。タイマーＴ２００は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２００が終了するか、または認証が失敗した場合、クライアントは「アイドル」状態に戻る。
-  「能力要求」状態：この状態で、クライアントはサーバに自身の能力を提示する。クライアントは、サーバが自身の能力を要求した場合にこの状態に入る。クライアントがタイマーＴ３００を起動する。タイマーＴ３００は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３００が終了した場合、クライアントは「アイドル」状態に戻る。
-  「ダウンロード受理」状態：この状態で、クライアントは、サーバが受信した情報に従いダウンロードを続けるか否かを決定する。クライアントは、サーバから実行すべきダウンロード・プロファイルを受信したならばこの状態に入る。受信したプロファイルが拒否された場合、クライアントは「アイドル」状態に戻る。
-  「ソフトウェア・ダウンロード」状態：この状態で、クライアントは、ソフトウェアのダウンロードを実行する。ダウンロード・プロファイルが受理されたならば、クライアントはこの状態に入る。クライアントはタイマーＴ４００を起動する。タイマーＴ４００は、サーバから受信された各ソフトウェア・ブロックでリセットされて再開される。タイマーＴ４００は、状態変化が生じたならば停止される。状態変化の前にタイマーＴ４００が終了したか、またはダウンロードが失敗した、あるいはダウンロードされたソフトウェアが能力に適合していない場合、クライアントは「アイドル」状態に戻る。
-  「インストール」状態：この状態で、クライアントは、サーバに対しライセンス要求を送信して基本ソフトウェアをインストールする。クライアントは、ダウンロード終了時点でこの状態に入る。クライアントは、タイマーＴ５００を起動する。状態変化が生じた場合、タイマーＴ５００は停止される。状態変化の前にタイマーＴ５００が終了したか、またはライセンスが受理されなかった場合、クライアントは「アイドル」状態に戻る。
-  「現場テスト」状態：この状態で、クライアントは、サーバが受信したいくつかのテスト・ベクトルを用いて、ダウンロードされたソフトウェアに対していくつかのテストを実行する。基本ソフトウェアがインストールされたならば、クライアントはこの状態に入る。一旦テストが終了したならば、クライアントは「アイドル」状態に戻る。
【００４０】
図３を参照するに、ＯＴＡサーバ（サーバー側）が管理するクライアント・コンテキストの状態図を示す。
先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
クライアント・コンテキストの状態および相対遷移は以下の通りである。
-  「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡサーバが管理するクライアント・コンテキストはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアント・コンテキストはこの状態に戻る。
-  「ダウンロード開始」状態：この状態で、クライアント・コンテキスト又はＯＴＡサーバはＯＴＡクライアントにダウンロードを実行するよう指示する。基本ソフトウェアのダウンロードを実行することが必要な場合（このダウンロードは例えばＯＴＡクライアントにより要求されるか、又は予定された周期的な更新に従って要求される）、クライアント・コンテキストはこの状態に入ってタイマーＴ１０１を起動する。状態変化の前にタイマーＴ１０１は停止される。状態変化の前にタイマーＴ１０１が終了した場合、クライアント・コンテキストは「アイドル」状態に戻る。
-  「相互認証」状態：この状態で、サーバは自身を認証し、ＯＴＡクライアントに対して自身を認証するよう要求する。クライアントからダウンロード確認を受信したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバはタイマーＴ２０１を起動する。タイマーＴ２０１は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２０１が終了するか、または認証が失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
-  「能力要求」状態：この状態で、ＯＴＡサーバはＯＴＡクライアントに対しその能力の提示を要求する。認証が完了したならばＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ３０１を起動する。タイマーＴ３０１は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０１が終了するか、または能力に起因してダウンロードが不可能な場合、クライアント・コンテキストは「アイドル」状態に戻る。
-  「ダウンロード受理」状態：この状態で、ＯＴＡサーバは、ダウンロード・プロファイルをＯＴＡクライアントに通知する。ＯＴＡサーバは、端末能力を受信して、当該能力が受理されたならばこの状態に入る。ＯＴＡサーバがタイマーＴ３０２を起動する。タイマーＴ３０２は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０２が終了するか、または提案されたダウンロードをＯＴＡクライアントが拒否した場合、クライアント・コンテキストは「アイドル」状態に戻る。
-  「ソフトウェア・ダウンロード」状態：この状態で、ＯＴＡサーバは、ＯＴＡクライアントへのソフトウェアのダウンロードを実行する。ダウンロード・プロファイルがＯＴＡクライアントにより受理された場合、ＯＴＡサーバはこの状態に入る。クライアントは、タイマーＴ４０１を開始する。タイマーＴ４０１はリセットされて、クライアントから受信された各々の肯定応答信号Ａｃｋで再開される。状態変化が生じた場合、タイマーＴ４０１は停止される。状態変化の前にタイマーＴ４０１が終了するか、またはダウンロードが失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
-  「インストール」状態：この状態で、ＯＴＡサーバは、クライアントがダウンロードされたソフトウェアのインストールおよびテストを実行するまで、ライセンス条件をＯＴＡクライアントへ通知して待機する。ダウンロードが終了したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ５０１を起動する。状態変化が生じたならばタイマーＴ５０１は停止される。状態変化の前にタイマーＴ５０１が終了するか、またはライセンスがＯＴＡクライアントにより受理されなかった場合、ＯＴＡクライアントは「アイドル」状態に戻る。ＯＴＡサーバは、ＯＴＡクライアントによるインストールの成功に関する肯定応答信号を受信したならば、「アイドル」状態に戻る。
【００４１】
以下、図４ａ〜４ｋに関して、ＯＴＡサーバとＯＴＡクライアントとの間で交換されるプロトコルメッセージの構造を詳しく説明する。
メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【００４２】
図４ａを参照するに、「ダウンロード開始要求」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバに送信される。端末はこのメッセージを用いて、サーバに対してダウンロード・セッションを開始するよう要求する。一般に各ダウンロード・セッションはＯＴＡサーバにより制御される。
【００４３】
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード開始要求」）を識別する。
-  「ＯＴＡクライアントＩＤ」：要求を実行するＯＴＡクライアントを識別する。
図４ｂを参照するに、「ダウンロード要求」メッセージの構造を記述している。このメッセージはＯＴＡサーバからＯＴＡクライアントに送信される。このメッセージにより、サーバはクライアントに対してダウンロード・セッションを開始するよう命令する。この場合に提供されるフィールドは、少なくとも以下のうち１組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード要求」）を識別する。
-  「ＯＴＡクライアントＩＤ」：要求の対象であるＯＴＡクライアントを識別する。
-  「利用可能なダウンロード」：可能なダウンロードのリストを含む。各要素は記述ストリングと数字識別子とを含む。このリスト中に存在する要素の数は可変である。
【００４４】
図４ｃを参照するに、「ダウンロードＡｃｋ」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバにダウンロード・セッションを開始する同意を通知する。
【００４５】
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロードＡｃｋ」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
-  「選択されたダウンロード」：ユーザーが選択したダウンロードのリストからなる。各要素は記述ストリングと数字識別子とを含む。リスト中に存在する要素数は可変である。
-  「ＯＴＡクライアント・チャレンジ番号」：ＯＴＡサーバが相互認証の第１ステップを実行するために自身の鍵及び適当な暗号化アルゴリズム（例えばＡＥＳ（Advanced Encryption Standard）アルゴリズム）を用いて暗号化する乱数である。
【００４６】
再び図４ａを参照するに、「ダウンロード拒否」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはダウンロード・セッションを開始できない旨をＯＴＡサーバに通知する。
【００４７】
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００４８】
図４ｄを参照するに、「認証要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバは、自身の証明をＯＴＡクライアントに通知し、ＯＴＡクライアントにそれを確認することが要求する。
【００４９】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「認証要求」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
-  「ＯＴＡサーバ応答番号」：相互認証の第１ステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
-  「ＯＴＡサーバ・チャレンジ番号」：相互認証の第２ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて暗号化する乱数である。
【００５０】
図４ｅを参照するに、「認証応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、既にサーバを認証した状態で、クライアントは自身の証明をＯＴＡサーバに通知する。
【００５１】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「認証応答」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
-  「ＯＴＡクライアント応答番号」：相互認証の第２および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。
【００５２】
再度図４ａを参照するに、「認証失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバ／ＯＴＡクライアントは、ＯＴＡサーバがＯＴＡクライアントを認証しなかった旨をＯＴＡクライアント／ＯＴＡサーバに通知する（その逆も同様）。
【００５３】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「認証失敗」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信／受信するＯＴＡクライアントを識別する。
【００５４】
再度図４ａを参照するに、「能力要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡクライアントは、ＯＴＡサーバに対しその再設定可能性オプションを要求する。
【００５５】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「能力要求」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
【００５６】
図４ｆを参照するに、「能力応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは、自身の再設定可能性オプションをＯＴＡサーバに知らせる。
【００５７】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「能力応答」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
-  「ＯＴＡクライアント能力」：端末の再設定可能性オプションを記述する。
【００５８】
図４ｇを参照するに、「ダウンロード記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバは、ダウンロードに関するデータをＯＴＡクライアントに報告する。
【００５９】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード記述」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
-  「ダウンロード・リスト」：各ダウンロードにつきクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
-  「ダウンロード・ブロック番号」：クライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
-  「支払請求基準」：起こり得るダウンロード支払請求に関する基準である。
-  「インストール基準」：ソフトウェアのインストールに関する基準である。
【００６０】
再び図４ａを参照するに、「ダウンロード受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは選択されたダウンロードを確認する。
【００６１】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード受理」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００６２】
再び図４ａを参照するに、「ダウンロード拒否」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは選択されたダウンロードを拒絶する。
【００６３】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００６４】
再び図４ａを参照するに、「ダウンロード失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ソフトウェアダウンロード手順において失敗がある旨を知らせる。
【００６５】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ダウンロード失敗」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００６６】
再び図４ａを参照するに、「ライセンス要求」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、クライアントはサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。
【００６７】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ライセンス要求」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００６８】
図４ｈを参照するに、「ライセンス応答」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバはＯＴＡクライアントに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を通知する。
【００６９】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ライセンス応答」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
-  復号化鍵：基本ソフトウェアを復号化するために用いられる鍵である。
【００７０】
再び図４ａを参照するに、「ライセンス受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアが正しく復号化された旨を通知する。
【００７１】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ライセンス受理」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００７２】
再び図４ａを参照するに、「ライセンス失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨を通知する。
【００７３】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「ライセンス失敗」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００７４】
図４ｉを参照するに、「テスト記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバはＯＴＡクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に該基本ソフトウェアに実行すべきテストを指示する。
【００７５】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「テスト記述」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージが送られるＯＴＡクライアントを識別する。
-  「テスト・リスト」：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
-  「テスト・ベクトル」：テストの記述を含んでいる。
【００７６】
再び図４ａを参照するに、「インストール成功」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。
【００７７】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「インストール成功」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００７８】
再び図４ａを参照するに、「インストール失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。
【００７９】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「インストール失敗」）を識別する。
-  「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
【００８０】
基本ソフトウェアをサーバからクライアントに送信するのに用いられるウィンドウ・プロトコルは、ＢｌｏｃｋおよびＡｃｋと呼ばれる２種類のプロトコル・データ・ユニットすなわちＰＤＵに基づいている。
【００８１】
図４ｊを参照するに、基本ソフトウェアが分割された無線ブロックＢｌｏｃｋの構造を記述している。
【００８２】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：ブロック種別を識別する。
-  「ブロック番号」：無線ブロックのシーケンス番号を識別する。このシーケンス番号は、ＯＴＡクライアントが基本ソフトウェア全体を再アセンブルするときに用いられる。
-  「データ」：無線ブロック中に含まれ、一般に１〜２キロバイトのサイズを有する。
【００８３】
図４ｋを参照するに、端末の受信状態を示すために用いるメッセージＡｃｋの構造を記述している。
【００８４】
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
-  「メッセージ種別」：送信されたメッセージの種別（「Ａｃｋ」）を識別する。
-  「ビットマスク・クライアント」：基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「１」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「０」のままである。
【００８５】
要約するに、上例によれば、ＯＴＡクライアントおよびＯＴＡサーバの機能的な挙動は以下の通りである。
-  ダウンロード手続きは、例えば、ＯＴＡサーバにより開始され、ＯＴＡクライアントはダウンロード手順の始動を要求できる。
-  クライアントとサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い行われる。
-  ダウンロードされる基本ソフトウェアは、例えば、サイズを縮小した（例えば、１〜２キロバイトの範囲）ブロックに分割される。
-  基本ソフトウェアの転送は例えば簡単なウィンドウ・プロトコルにより管理され、その際にウィンドウのサイズは基本ソフトウェアが分割されたブロックの個数と一致する。
-  ダウンロードされた基本ソフトウェアは暗号化することができ、例えば、復号化およびインストールのために鍵が必要とされる。
-  基本ソフトウェアを開始する前に、クライアントは、サーバにより提案された適切なテストによりこれを検査できる。
【００８６】
以下、図５ａ〜５ｊに関し、ＯＴＡクライアントとＯＴＡサーバとの間での手続上の相互作用を、受信した各プロトコルメッセージについてＯＴＡクライアント又はクライアント・コンテキストの状態に従った相対的な挙動を示すことによって説明する。図５ａ〜５ｊは可能なすべての手続上の相互作用の例を示す。
【００８７】
理解を容易にするため、上述したように、タイマーはＯＴＡクライアント又はクライアント・コンテキストが１つの状態から別の状態に移ったときに開始／停止させることに留意する。
【００８８】
図５ａでは、操作が実行されていないとき、ＯＴＡサーバにより管理された当該ＯＴＡクライアントに対してＯＴＡクライアント及びクライアント・コンテキストは「アイドル」状態にある（ステップ１００）。
【００８９】
ユーザー又はネットワークが新しい基本ソフトウエアのダウンロードを実行することを決めると（ステップ１０２）、無線接続が開かれ（ステップ１０４）タイマーＴ１００をスタートさせる。無線接続については後で図６を説明するとき更に詳細に説明する。
【００９０】
この段階で、ＯＴＡクライアントは「ダウンロード開始要求」プロトコルメッセージをＯＴＡサーバに送信することによりソフトウェアダウンロード手順を始めることができ（ステップ１０６）、その識別子はメッセージ中に示されているＯＴＡクライアントを識別する。原則として、ＯＴＡクライアントＩＤがプロトコルメッセージを受信するＯＴＡクライアントの識別子に対応しないならば、メッセージは無視される。
【００９１】
次に、ＯＴＡサーバが「ダウンロード開始要求」メッセージを受信し（ステップ１０８）、クライアント・コンテキストの状態が「アイドル」でないならば（ステップ１１０）、メッセージは無視されて手順は停止し（ステップ１１２）、そうでなければクライアント・コンテキストが「アイドル」状態から「ダウンロード開始」状態に移り（ステップ１１４）、タイマーＴ１０１をスタートし、そして様々な可能なダウンロードを示す「ダウンロード要求」プロトコルメッセージをクライアントに送信する（ステップ１１６）。ＯＴＡクライアントは「ダウンロード要求」メッセージを受信し（ステップ１１８）、ＯＴＡクライアントの状態が「アイドル」であるならば（ステップ１２０）、ＯＴＡクライアントは「アイドル」状態から「ダウンロード開始」状態に移り（ステップ１２４）、そうでなければメッセージが無視されて手順が停止する（ステップ１２２）。
【００９２】
次に図５ｂを参照すると、「ダウンロード要求」メッセージ中に示された利用可能なダウンロードの選択がユーザーに提示される（ステップ１２６）。ユーザーが少なくとも１つのダウンロードを選ぶと（ステップ１２８）、ＯＴＡクライアントが乱数ＲＮＵＭ１を取り出して記憶し（ステップ１４２）、取り出した数ＲＮＵＭ１の値を「ＯＴＡクライアント・チャレンジ番号」フィールド中に含んだ「ダウンロードＡｃｋ」メッセージをＯＴＡサーバに送信する（ステップ１４４）。
【００９３】
ユーザーがどのダウンロードも選ばないならば（ステップ１２８）、ＯＴＡクライアントはクライアント・コンテキストに「ダウンロード拒否」メッセージを送り（ステップ１３０）、「アイドル」状態に戻る（ステップ１３２）。次にＯＴＡサーバは「ダウンロード拒否」メッセージを受信する（ステップ１３４）。クライアント・コンテキストの状態が「ダウンロード開始」でないならば（ステップ１３６）、メッセージは無視され手順が停止し（ステップ１３８）、そうでないならばクライアント・コンテキストは「アイドル」状態に戻る（ステップ１４０）。
【００９４】
ＯＴＡサーバが「ダウンロードＡｃｋ」メッセージを受信すると（ステップ１４６）、クライアント・コンテキストの状態が「ダウンロード開始」でないならば（ステップ１４８）、メッセージは無視され手順は停止し（ステップ１５０）、そうでなければクライアント・コンテキストはタイマーＴ２０１をスタートさせる一方でタイマーＴ１０１を停止させて「ダウンロード開始」状態から「相互認証」状態に移る（ステップ１５２）。
【００９５】
次にＯＴＡサーバにより乱数ＲＮＵＭ２が取り出されて記憶される（ステップ１５４）。「ＯＴＡクライアント・チャレンジ番号」フィールドの値は、例えばＡＥＳなどの選択された暗号化アルゴリズムを用いることによりＯＴＡサーバ内部鍵で暗号化される（ステップ１５６）。
ＯＴＡサーバは、ステップ１５６で暗号化され「ＯＴＡサーバ応答番号」フィールドに書き込まれた値及び「ＯＴＡサーバ・チャレンジ番号」フィールド中の取り出された数ＲＮＵＭ２の値と共に「認証要求」プロトコルメッセージをＯＴＡクライアントに送信する（ステップ１５８）。
【００９６】
次に、図５ｃでは、ＯＴＡクライアントが「認証要求」メッセージを受信し（ステップ１６０）、タイマーＴ１００を停止する。ＯＴＡクライアントが「ダウンロード開始」状態にないならば（ステップ１６２）、メッセージは無視され手順が停止し（ステップ１６４）、そうでなければ、ＯＴＡクライアントは「ダウンロード開始」状態から「相互認証」状態に移り（ステップ１６６）、タイマーＴ２００をスタートさせる。
【００９７】
記憶された乱数ＲＮＵＭ１が有効でないならば（ステップ１６８）、「認証失敗」メッセージがＯＴＡクライアントによりクライアント・コンテキストに送られ（ステップ１７０）、ＯＴＡクライアントが「相互認証」状態から「アイドル」状態に移り（ステップ１７２）、タイマーＴ２００が停止される。次にクライアント・コンテキストが「認証失敗」メッセージを受信し（ステップ１７４）、タイマーＴ２０１を停止し、クライアント・コンテキストが「相互認証」状態にあるならば（ステップ１７６）、クライアント・コンテキストは「相互認証」状態から「アイドル」状態に移り（ステップ１８０）、そうでなければ手順が停止する（ステップ１７８）。
【００９８】
記憶された値ＲＮＵＭ１が有効であるならば（ステップ１６８）、選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより記憶された乱数ＲＮＵＭ１の値をＯＴＡクライアント内部鍵で暗号化する（ステップ１８２）。ステップ１８２で暗号化された値が「ＯＴＡサーバ応答番号」フィールドに含まれる値と一致しないならば（ステップ１８４）、ステップ１７０に手順が戻り、既に説明したようにステップ１７０〜１８０が実行される。
【００９９】
ステップ１８２で暗号化された値が「ＯＴＡサーバ応答番号」フィールドに含まれる値に一致するならば（ステップ１８４）、選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより「ＯＴＡサーバ・チャレンジ番号」フィールドの値がＯＴＡクライアント内部鍵で暗号化される（ステップ１８６）。次にステップ１８６で暗号化された値を「ＯＴＡクライアント応答番号」フィールド中に含む「認証応答」メッセージがＯＴＡクライアントによりクライアント・コンテキストに送られる（ステップ１８８）。
【０１００】
次にＯＴＡサーバが「認証応答」メッセージを受信し（ステップ１９０）、図５ｄにて、クライアント・コンテキストの状態が「相互認証」でないならば（ステップ１９２）、メッセージは無視され手順が停止し（ステップ１９４）、そうでなければ選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより記憶された乱数ＲＮＵＭ２の値がＯＴＡサーバ内部鍵で暗号化される（ステップ１９６）。
【０１０１】
ステップ１９６で暗号化された値が「ＯＴＡクライアント応答番号」フィールドの値に一致しないならば（ステップ１９８）、「認証失敗」メッセージがクライアント・コンテキストによりＯＴＡクライアントに送られ（ステップ２００）、クライアント・コンテキストが「相互認証」状態から「アイドル」状態に移る（ステップ２０２）。次にＯＴＡクライアントが「認証失敗」メッセージを受信し（ステップ２０４）、ＯＴＡクライアントが「相互認証」状態にあるならば（ステップ２０６）、ＯＴＡクライアントが「相互認証」状態から「アイドル」状態に移り（ステップ２１０）、そうでなければ手順が停止する（ステップ２０８）。
【０１０２】
ステップ１９６で暗号化された値が「ＯＴＡクライアント応答番号」フィールドの値に一致するならば（ステップ１９８）、クライアント・コンテキストはタイマーＴ２０１を停止し、「相互認証」状態から「能力要求」状態に移り（ステップ２１２）、タイマーＴ３０１を始動させる。次に「能力要求」プロトコルメッセージがクライアント・コンテキストによりＯＴＡクライアントに送られ（ステップ２１４）、ＯＴＡクライアントにより受信され（ステップ２１６）、ＯＴＡクライアントがタイマーＴ２００を停止する。ＯＴＡクライアントの状態が「相互認証」でなければ（ステップ２１８）、メッセージは無視され手順が停止し（ステップ２２０）、そうでなければＯＴＡクライアントが「相互認証」状態から「能力要求」状態に移り（ステップ２２２）、一方タイマーＴ３００をスタートさせる。次にＯＴＡクライアントはクライアント・コンテキストに「能力応答」メッセージを送り（ステップ２２４）、クライアント・コンテキストがそれを受信する（ステップ２２６）。
【０１０３】
図５ｅでは、クライアント・コンテキストの状態が「能力要求」でないならば（ステップ２２８）、メッセージは無視され手順が停止し（ステップ２３０）、そうでなければ、メッセージ中に含まれる能力がダウンロードされるソフトウェアに適合しないならば（ステップ２３２）、クライアント・コンテキストは「能力応答」状態から「アイドル」状態に移り（ステップ２３４）、タイマーＴ３０１が停止される。能力がダウンロードされるソフトウェアに適合するならば（ステップ２３２）、タイマーＴ３０１が停止され、クライアント・コンテキストが「能力要求」状態から「ダウンロード受理」状態に移り（ステップ２３６）、一方タイマーＴ３０２をスタートさせてＯＴＡクライアントに「ダウンロード記述」メッセージを送信する（ステップ２３８）。
【０１０４】
次にＯＴＡクライアントは「ダウンロード記述」メッセージを受信し（ステップ２４０）、タイマーＴ３００を停止する。ＯＴＡクライアントが「能力要求」状態にないならば（ステップ２４２）、メッセージは無視され手順が停止し（ステップ２４４）、そうでなければＯＴＡクライアントが「能力要求」状態から「ダウンロード受理」状態に移る（ステップ２４６）。支払請求、インストールなどのダウンロードオプションがユーザーに提示される（ステップ２４８）。図５ｆでは、ユーザーがダウンロードを拒否するならば（ステップ２５０）、ＯＴＡクライアントは「ダウンロード拒否」メッセージをクライアント・コンテキストに送り（ステップ２５２）、「ダウンロード受理」状態から「アイドル」状態に移る（ステップ２５４）。また、クライアント・コンテキストが「ダウンロード拒否」メッセージを受信し（ステップ２５６）、クライアント・コンテキストの状態が「ダウンロード受理」でないならば（ステップ２５８）、メッセージは無視され手順が停止し（ステップ２６０）、そうでなければクライアント・コンテキストが「ダウンロード受理」状態から「アイドル」状態に移る（ステップ２６２）。
【０１０５】
ユーザーがダウンロードを受理するならば（ステップ２５０）、ＯＴＡクライアントがクライアント・コンテキストに「ダウンロード受理」メッセージを送り（ステップ２６４）、ＯＴＡ-クライアントが「ダウンロード受理」状態から「ソフトウエア・ダウンロード」状態に移る（ステップ２６６）。
【０１０６】
次にクライアント・コンテキストが「ダウンロード受理」メッセージを受信し（ステップ２６８）、タイマーＴ３０２を停止する。クライアント・コンテキストの状態が「ダウンロード受理」でないならば（ステップ２７０）、メッセージは無視され手順が停止し（ステップ２７２）、そうでなければクライアント・コンテキストが「ダウンロード受理」状態から「ソフトウエア・ダウンロード」状態に移り（ステップ２７４）、一方タイマーＴ４００をスタートさせ、ソフトウェアダウンロードが始まる（ステップ２７６）。
【０１０７】
ソフトウェアダウンロードが成功でないならば（ステップ２７８）、ＯＴＡクライアント／クライアント・コンテキストがクライアント・コンテキスト／ＯＴＡクライアントに「ダウンロード失敗」メッセージを送り（ステップ２８０）、ＯＴＡクライアント／クライアント・コンテキストが「ダウンロード・ソフトウエア」状態から「アイドル」状態に移る（ステップ２８２）。ソフトウェアダウンロード（ステップ２７６）については後で詳しく説明する。
【０１０８】
ダウンロードが成功ならば（ステップ２７８）、ＯＴＡクライアントが「ソフトウエア・ダウンロード」状態から「インストール」状態に移る（ステップ２８４）。図５ｇでは、ＯＴＡクライアントがクライアント・コンテキストに「ライセンス要求」メッセージを送り（ステップ２８６）、ＯＴＡサーバがそれを受信する（ステップ２８８）。クライアント・コンテキストの状態が「ソフトウエア・ダウンロード」でないならば（ステップ２９０）、メッセージは無視され手順が停止し（ステップ２９２）、そうでなければクライアント・コンテキスト手順が「ソフトウエア・ダウンロード」状態から「インストール」状態に移り（ステップ２９４）、一方タイマーＴ５００をスタートさせ、基本ソフトウエアを復号化するための鍵を含んだ「ライセンス応答」メッセージをＯＴＡクライアントに送信する（ステップ２９６）。
【０１０９】
ＯＴＡクライアントは「ライセンス応答」メッセージを受信し（ステップ２９８）、ＯＴＡクライアントが「インストール」状態にないならば（ステップ３００）、メッセージは無視され手順が停止し（ステップ３０２）、そうでなければＯＴＡクライアントが「復号化鍵」フィールド中に示された鍵を用いることによりダウンロードされたソフトウェアを復号化する（ステップ３０４）。図５ｈでは、復号化が失敗ならば（ステップ３０６）、ＯＴＡクライアントが「ライセンス失敗」メッセージをクライアント・コンテキストに送り（ステップ３０８）、タイマーＴ５００を停止し、「インストール」状態から「アイドル」状態に移る（ステップ３１０）。また、クライアント・コンテキストが「ライセンス失敗」メッセージを受信し（ステップ３１２）、クライアント・コンテキストが「ソフトウエア・ダウンロード」状態にないならば（ステップ３１４）、手順が停止し（ステップ３１６）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移る（ステップ３１８）。
【０１１０】
復号化が失敗ならば（ステップ３０６）、ダウンロードされた基本ソフトウエアがクライアント又は端末中に記憶される（ステップ３２０）。
【０１１１】
ＯＴＡクライアントが「ライセンス受理」メッセージをクライアント・コンテキストに送り（ステップ３２２）、ＯＴＡサーバがそれを受信し（ステップ３２４）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３２６）、メッセージは無視され手順が停止し（ステップ３２８）、そうでなければクライアント・コンテキストが「テスト記述」プロトコルメッセージをＯＴＡクライアントに送り（ステップ３３０）、ＯＴＡクライアントがそれを受信する（ステップ３３２）。ＯＴＡクライアントが「インストール」状態にないならば（ステップ３３４）、メッセージは無視され手順が停止し（ステップ３３６）、そうでなければＯＴＡクライアントがタイマーＴ５００を停止させて「インストール」状態から「現場テスト」状態に移り（ステップ３３８）、該状態において受信されたテストが前に記憶された基本ソフトウエア上で実行される（ステップ３４０）。
【０１１２】
図５ｉでは、少なくとも１つのテストが失敗ならば（ステップ３４２）、ＯＴＡクライアントは基本ソフトウエアをメモリから消去し（ステップ３４４）、「インストール失敗」メッセージをクライアント・コンテキストに送り（ステップ３４６）、「現場テスト」状態から「アイドル」状態に移る（ステップ３４８）。また、クライアント・コンテキストは「インストール失敗」メッセージを受信し（ステップ３５０）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３５２）、メッセージは無視され手順が停止し（ステップ３５４）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移る（ステップ３５６）。
【０１１３】
基本ソフトウエア上で実行されるすべてのテストが成功ならば（ステップ３４２）、新しい基本ソフトウエアがＯＴＡクライアントにインストールされて開始される（ステップ３５８）。ＯＴＡクライアントは「インストール成功」メッセージをクライアント・コンテキストに送り（ステップ３６０）、「現場テスト」状態から「アイドル」状態に移る（ステップ３６２）。
【０１１４】
ＯＴＡサーバは「インストール成功」メッセージを受信し（ステップ３６４）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３６６）、メッセージは無視され手順が停止し（ステップ３６８）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移り（ステップ３７０）、それにより全体の手順を完了する（ステップ３７２）。
【０１１５】
図５ｊでは、ステップ２７６のダウンロード手順をさらに詳細に説明する。基本ソフトウエアは、暗号化アルゴリズム、例えばＡＥＳによって暗号化鍵を用いて暗号化される（ステップ４００）。次に暗号化された基本ソフトウエアは、約１〜２キロバイトの大きさに縮小したブロックに分割される（ステップ４０２）。
【０１１６】
ソフトウェアを分割して得た無線ブロックの数に等しい１ビットマスク「ビットマスク・サーバ」と１ビットマスク「ビットマスク・クライアント」が割り当てられ、各ビットマスクには「０」値が設定され、各マスクビットはビット位置に等しい数の無線ブロックに対応しており、すなわち、第１ビットは第１無線ブロックに対応し、第２ビットは第２無線ブロックに対応する等々（ステップ４０４及びステップ４０８）。
【０１１７】
ステップ４０６では「ビットマスク・サーバ」が「ビットマスク・クライアント」の内容に従って更新される。特に、「ビットマスク・クライアント」のビットが１に設定されていたならば、「ビットマスク・サーバ」の対応するビットも同様に１に設定される（ステップ４０６）。ダウンロード手順を初めて実行するとき、「ビットマスク・クライアント」及び「ビットマスク・サーバ」の全ビットは０に設定されるのでこのステップは意味がない。
【０１１８】
ステップ４１２では、ビットマーク「ビットマスク・サーバ」の全ビットが１に等しいか否かを調べる。肯定の場合には、基本ソフトウエアのダウンロードが終了し、すべてのブロックが成功裡に受信され（ステップ４１０）、そうでなければダウンロードはまだ終了せず、ＯＴＡサーバが「ビットマスク・サーバ」（ｉ）＝０であるすべてのブロックｉをＯＴＡクライアントに送信する（ステップ４１４）。明らかに、初めて手順を実行するとき、基本ソフトウエアを分割して得たＮ個すべてのブロックがクライアントに送られる。
【０１１９】
次にＯＴＡクライアントがＮ個のブロックを受信し（ステップ４１６）、各ブロックの受信時にタイマーＴ４００を再スタートさせる。ブロックｉが正しく受信される度に（ステップ４１８）、ビットマスク「ビットマスク・クライアント」（ｉ）の対応するビットが１に設定される。Ｎブロックすべてが送られると、ＯＴＡクライアントは、正しく受信したブロックに対応するビットｉが１に設定されているビットマスク「ビットマスク・クライアント」を含んだメッセージＡｃｋをＯＴＡサーバに送信する。メッセージ「Ａｃｋ」を受信すると、タイマーＴ４０１を再スタートさせる。
次に手順をステップ４０６に戻し、「ビットマスク・サーバ」ビットマスクを更新する。
【０１２０】
所望の基本ソフトウエアをダウンロードし端末に記憶すると、それを直ぐにインストールし実行する代わりに、ネットワーク又はユーザーから来る要求に応じて逐次インストールし実行させることもできる。無線端末ＵＥ／ＭＳが十分なメモリと処理能力を有するならば、ダウンロードした基本ソフトウエアを、現在動作中の既存のシステムと併存して記憶しインストールできる。このオプションは、端末ＵＥ／ＭＳのマルチモード動作を可能にするのに有効であり、換言すれば、このオプションでは、基本ソフトウエアをダウンロードする必要なく端末が１つのオペレーティングモードから別のオペレーティングモードに切り替わることができる。
【０１２１】
以下、図６に関して、ステップ１０４で実行した無線接続の開設について更に詳細に説明する。
端末においては、以下のモジュール：ＯＴＡクライアント・アプリケーション、ＴＣＰ／ＩＰプロトコル、非アクセス層ＮＡＳ（Non Access Stratum）モジュール及びアクセス層ＡＳ（Access Stratum）モジュールを考える。無線アクセスデバイスＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）及びＵＭＴＳ（ＵＴＲＡＮ）はそっくりそのまま全体として考える。同じ議論がコアネットワークノードにも当てはまる。ＯＴＡサーバノードはコアネットワークに接続される。端末ＵＥ／ＭＳから来るダウンロード要求の場合の動作の詳細を以下に説明する。
-  ＯＴＡクライアントがポートＸに接続をオープンするようプロトコルＴＣＰ／ＩＰに要求する。
-  ＴＣＰ／ＩＰは、接続をオープンする前に無線チャンネルを必要とするので対応する要求を端末のプロトコルＮＡＳに送信する。
-  端末のプロトコルＮＡＳは端末のモジュールＡＳに対して無線接続の開設を要求する。
-  端末のプロトコルＡＳが無線アクセスネットワークＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）又はＵＭＴＳ（ＵＴＲＡＮ）により無線接続をオープンし、ＮＡＳレベルでの開設を確認する。
-  モジュールＮＡＳがＰＤＰコンテキストを起動する。
-  ＵＭＴＳシステムの場合、コアネットワークがトランスポート用の無線アクセス・バリアＲＡＢ（Radio Access Bearer）を起動する。
-  モジュールＮＡＳがトランスポートチャンネルの開設をＴＣＰ／ＩＰに確認する。
-  プロトコルＴＣＰ／ＩＰが接続をオープンし、開設をＯＴＡクライアントに確認する。
【０１２２】
一般に、アプリケーション層によりダウンロードされたソフトウェアの管理は、使用される無線システムがマルチキャスト又はブロードキャスト型であるような別の方法によっても実行できる。
【０１２３】
特に、この変形は、例えば以下の様にして実装することもできる。
-  端末ＵＥ／ＭＳは、ブロードキャスト／マルチキャスト能力、例えば、３ＧＰＰ規格のリリース６に規定されたＭＢＭＳ（Multimedia Broadcast/Multicast Service）サービスを利用することによってＯＴＡ基本ソフトウエアのダウンロードを管理できるアプリケーションを備える。この場合、ネットワークのブロードキャスト／マルチキャスト能力を用いることにより、基本ソフトウエアを複数の端末にダウンロードすることができる。
-  このアプリケーション層は３ＧＰＰ規格に従って認証を実行する。
-  アクセスネットワーク及びコアネットワークの観点から、ソフトウェアのダウンロードサービスはトランスペアレントであり、例えば「ソフトウエア・ダウンロード」識別を有する何らかのＭＢＭＳサービスのように考えられる。
-  一定のダウンロード能力を保証するために例えばサービス品質（ＱｏＳ）などのような当該ネットワークの特徴をすべて利用できる。
-  このアーキテクチャーは当該アクセスネットワーク（ＧＥＲＡＮ／ＵＴＲＡＮ）から独立している。
-  ダウンロードの実行を望んでいるユーザーは、自身をサーバに登録することができる。
-  ダウンロードは登録されたすべてのユーザーに向けて同時に行なわれる。
【０１２４】
本発明の別の変形は、ユニバーサルチャンネルを用いてソフトウェアＯＴＡをダウンロードすることにある。この場合でも、前記ユニバーサルチャンネルを管理するネットワークアーキテクチャーを押しつけがましく変更することなく、基本ソフトウエアのダウンロードを実行するために本発明を適用できる。別法として、通信ネットワークの無線チャンネルを介してダウンロードが行われる。
【０１２５】
第２世代及び第３世代システムについて本発明を詳しく説明してきたが、他の種類のネットワーク、例えば無線ローカルエリアネットワーク（ＷＬＡＮ）、ＤＶＢなどにおいても本発明を実装することができる。実際、本発明により提示された解決策では、使用中のシステムの外部のＯＴＡサーバが与えられ、よって使用中のシステムは変更されない。
【０１２６】
また、本発明の好ましい態様によると、非常に多くのシステム又はネットワークにおいて広く使用されている周知のＴＣＰ／ＩＰプロトコルが用いられる。
【０１２７】
本発明の別の態様によると、本発明のアーキテクチャーに影響を与えることなく、ＴＣＰ／ＩＰとは異なるトランスポートプロトコル、例えばＵＤＰ（User Datagram Protocol）などを用いることもできる。
【図面の簡単な説明】
【０１２８】
【図１】一般ＧＰＲＳ又はＵＭＴＳネットワークにおいて実装された本発明の態様を示す。
【図２】無線端末側のコンピュータプログラムプロダクトにより実行されるプロトコルステップの状態図である。
【図３】ネットワーク側のサーバにより実行されるプロトコルステップの状態図である。
【図４ａ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｂ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｃ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｄ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｅ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｆ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｇ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｈ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｉ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｊ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図４ｋ】モバイル無線端末とサーバとの間で交換されるプロトコルメッセージの構造を示す。
【図５ａ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｂ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｃ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｄ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｅ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｆ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｇ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｈ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｉ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図５ｊ】無線モバイル端末にインストールされるべき基本ソフトウエアのダウンロード手順を詳細に示すフローチャートである。
【図６】ダウンロード手順のシーケンス図であり、特にモバイル無線端末とサーバとの間の無線接続の開設を示す。
【図１】
2008518529.tif 000003
【図２】
2008518529.tif 000004
【図３】
2008518529.tif 000005
【図４ａ】
2008518529.tif 000006
【図４ｂ】
2008518529.tif 000007
【図４ｃ】
2008518529.tif 000008
【図４ｄ】
2008518529.tif 000009
【図４ｅ】
2008518529.tif 000010
【図４ｆ】
2008518529.tif 000011
【図４ｇ】
2008518529.tif 000012
【図４ｈ】
2008518529.tif 000013
【図４ｉ】
2008518529.tif 000014
【図４ｊ】
2008518529.tif 000015
【図４ｋ】
2008518529.tif 000016
【図５ａ】
2008518529.tif 000017
【図５ｂ】
2008518529.tif 000018
【図５ｃ】
2008518529.tif 000019
【図５ｄ】
2008518529.tif 000020
【図５ｅ】
2008518529.tif 000021
【図５ｆ】
2008518529.tif 000022
【図５ｇ】
2008518529.tif 000023
【図５ｈ】
2008518529.tif 000024
【図５ｉ】
2008518529.tif 000025
【図５ｊ】
2008518529.tif 000026
【図６】
2008518529.tif 000027
【国際調査報告】
2008518529.tif 000028
2008518529.tif 000029
2008518529.tif 000030