(57)【要約】対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新可能な移動通信システムを提供する。  サーバはソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、端末種別とソフトウェアのバージョン情報とを含むＯＴＡＳＰ要求をＧＧＳＮに送信する。ＯＴＡＳＰ要求はＧＧＳＮ、ＳＧＳＮ、ＲＮＣを介して携帯端末（ＵＥ＃１，ＵＥ＃２）に転送される。携帯端末（ＵＥ＃１，ＵＥ＃２）は自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致すると、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｑｕｅｓｔをＲＮＣに送信する。
2004107797.tif 000002
【特許請求の範囲】
【請求項１】
無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有することを特徴とする移動通信システム。
【請求項２】
前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項１記載の移動通信システム。
【請求項３】
無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有することを特徴とする移動通信システム。
【請求項４】
前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別する機能と、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを前記携帯端末に含むことを特徴とする請求項３記載の移動通信システム。
【請求項５】
前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを前記携帯端末に含むことを特徴とする請求項３または請求項４記載の移動通信システム。
【請求項６】
前記サーバは、前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項５記載の移動通信システム。
【請求項７】
前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を前記携帯端末に含むことを特徴とする請求項３から請求項６のいずれか記載の移動通信システム。
【請求項８】
無線を利用して携帯端末との間でデータ送受信を行うサーバであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を有することを特徴とするサーバ。
【請求項９】
前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項８記載のサーバ。
【請求項１０】
無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行うサーバであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を有することを特徴とするサーバ。
【請求項１１】
前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項１０記載のサーバ。
【請求項１２】
少なくとも自端末の端末種別及び自端末のソフトウェアのバージョン情報を含むページングを受信した時に動作することを特徴とする携帯端末。
【請求項１３】
無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が行われる移動通信システムの携帯端末であって、前記ＯＴＡＳＰが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを有することを特徴とする携帯端末。
【請求項１４】
前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを含むことを特徴とする請求項１３記載の携帯端末。
【請求項１５】
前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を含むことを特徴とする請求項１３または請求項１４記載の携帯端末。
【請求項１６】
無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムのデータ転送方法であって、前記サーバ側に、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出すステップを有することを特徴とするデータ転送方法。
【請求項１７】
前記要求に、前記端末種別とともに前記携帯端末内のソフトウェアのバージョン情報を付加することを特徴とする請求項１６記載のデータ転送方法。
【請求項１８】
無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップを有することを特徴とするデータ転送方法。
【請求項１９】
前記携帯端末側に、前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別するステップと、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新するステップとを含むことを特徴とする請求項１８記載のデータ転送方法。
【請求項２０】
前記携帯端末側に、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別するステップと、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信するステップと、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信するステップとを含むことを特徴とする請求項１８または請求項１９記載のデータ転送方法。
【請求項２１】
前記サーバが前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項２０記載のデータ転送方法。
【請求項２２】
前記携帯端末側に、前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止するステップを含むことを特徴とする請求項１８から請求項２１のいずれか記載のデータ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法に関し、特に携帯電話機内のソフトウェアの更新を行うためのデータ転送方法に関する。
【背景技術】
【０００２】  近年、携帯電話システムにおいては、携帯電話端末の加入者が飛躍的に増大しているが、携帯端末の不具合を修正するために、販売済みの携帯端末を回収するという出来事も生じている。【０００３】  このような携帯端末の回収処理を避けるという目的も含めて、無線を利用して携帯端末のソフトウェアを書換えるというＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が３ＧＰＰ２（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  ２）で検討されている（例えば、非特許文献１参照）。【０００４】  この場合、ソフトウェアを書換える携帯端末を特定する技術としては、ページング技術がある。ページング技術では、携帯端末に対して着信があった時に、その旨を携帯端末に通知する必要があり、携帯端末が位置登録している位置登録エリア内の全ての携帯端末に対して着信があったことを同報的に通知する。すると、携帯端末では待ち受け状態にあっても、呼び出し用のチャネルを常に監視しているため、自端末に対するページングを認識することが可能となる（例えば、非特許文献２参照）。【０００５】  しかしながら、携帯端末一つ一つにデータを転送しているのでは効率が悪くなるため、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する技術も提案されている（例えば、特許文献１，２参照）。
【特許文献１】特開２００１−２８７８７号公報（第７，８、図１）
【特許文献２】特開２００３−５１７９６号公報（第６〜８、図１）
【非特許文献１】３ＧＰＰ２  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅｓ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｒｅｌｅａｓｅ  Ａ，Ｊｕｎｅ，２０００
【非特許文献２】「Ｗ−ＣＤＭＡ移動通信方式  ４  ネットワーク方式  ４−３  ネットワーク制御・信号方式」（立川敬二  監修、丸善株式会社刊、平成１３年６月２５日発行、第２５４〜２５６頁）
【発明の開示】
【発明が解決しようとする課題】
【０００６】  しかしながら、上記の３ＧＰＰ２で検討されているＯＴＡＳＰでは、携帯端末毎にデータを送信しており、複数の携帯端末が同時に同じデータを受信することができるという無線の性質が最大限に利用されていない。この場合、携帯端末毎にデータを送信することは、移動通信システム自体の輻輳を招いてしまう。【０００７】  また、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する方法では、ソフトウェアを書換える必要がない携帯端末でもそのデータを受信し、必要でないと判定した時に当該データを破棄する動作が必要になる。つまり、この方法では、ソフトウェアを書換える必要がない場合でもそのデータの受信動作と判定動作とを行わなければならず、携帯端末の消費電力の増大を招くという問題がある。【０００８】  そこで、本発明の目的は上記の問題点を解消し、対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法を提供することにある。
【課題を解決するための手段】
【０００９】  本発明による移動通信システムは、無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに備えている。【００１０】  本発明による他の移動通信システムは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに備えている。【００１１】  本発明によるサーバは、無線を利用して携帯端末との間でデータ送受信を行うサーバであって、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出す機能を備えている。【００１２】  本発明による他のサーバは、無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行うサーバであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を備えている。【００１３】  本発明による携帯端末は、無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が行われる移動通信システムの携帯端末であって、前記ＯＴＡＳＰが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを備えている。【００１４】  本発明によるデータ転送方法は、無線を利用してサーバと携帯端末との間でデータ送受信を行う移動通信システムのデータ転送方法であって、前記サーバ側に、少なくとも前記携帯端末の端末種別を当該携帯端末への要求に付加して送信することで対象とする携帯端末を呼出すステップを備えている。【００１５】  本発明による他のデータ転送方法は、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップを備えている。【００１６】  すなわち、本発明の移動通信システムは、移動通信のブロードキャストまたはマルチキャストにおいて、サーバが携帯端末からの要求を受けることなく、対象となる携帯端末群にデータの配信を行い、携帯端末のソフトウェアを修正することを特徴とする。この場合、一度修正したソフトウェアは、何度も修正しないようにすることも特徴とする。【００１７】  通常、ブロードキャストにおいては、全ての携帯端末がデータを受信することが可能であるが、本発明では対象となる携帯端末のみがデータの受信を可能とする方式を実現するものである。【００１８】  また、通常、マルチキャストでは、携帯端末が自らの意思でサービスにＪｏｉｎ（参加）を行い、データの受信を行うが、本発明では、サーバが携帯端末特有の情報［例えば、ＩＭＥＩ−ＳＶ（Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ  ａｎｄ  Ｓｏｆｔｗａｒｅ  Ｖｅｒｓｉｏｎ  Ｎｕｍｂｅｒ）］を用いてネットワーク側から携帯端末を呼出すことを提案している。【００１９】  さらに、本発明では、ソフトウェアの正常性の確認を行うことで、成功した時に今後同じデータを受信しないように、失敗した時に改めてデータを受信可能とする機能を有している。【００２０】  ブロードキャストを用いたＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）では、対象となる携帯端末の存在を確認する必要がなく、ネットワーク側は携帯端末からの応答の受信もない。そのため、ネットワーク側での負荷が軽減される。しかしながら、対象となる携帯端末がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、ＯＴＡＳＰは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるためのものである。【００２１】  一方、マルチキャストを用いたＯＴＡＳＰでは、ネットワーク側は対象となる携帯端末が存在することを確認する必要があるので、携帯端末からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。しかしながら、対象となる携帯端末が存在しないエリアにデータを送信することを避けることが可能となる。【００２２】  そこで、最初の数回は対象となる携帯端末が多いことが予想されるため、ブロードキャストを利用し、ブロードキャストを数回適用した後で、マルチキャストを適用することが考えられる。これによって、効率の良いＯＴＡＳＰが実現可能となる。【００２３】  現在、３ＧＰＰではＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）が検討されている。ＭＢＭＳの目的は、無線リソースの有効利用であり、あるデータをあるエリア全体に送信するブロードキャストと、あるデータをそのデータの受信を望んでいる携帯端末のグループのみに送信するマルチキャストが考えられている。これらの技術を利用することで、特定の携帯端末のグループのみに必要なデータを送信することが可能となる。【００２４】  現状の３ＧＰＰの仕様では、呼出し通知チャネル（ＰＩＣＨ：Ｐａｇｅ  Ｉｎｄｉｃａｔｉｏｎ  Ｃｈａｎｎｅｌ）における自端末が登録されたビットを確認し、そのビットが「１」であれば、呼出しチャネル（ＰＣＨ：Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）の情報を読出し、自端末の着信かどうかを判断している。本発明では、現状の３ＧＰＰの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって、呼出し通知チャネルの間欠受信を行っている。【００２５】  特定の携帯端末のソフトウェア修正を行う場合には、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに「１」を設定する。また、呼出しチャネルには対象となる携帯端末の機種（端末種別）とソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョンの情報とを含ませる。【００２６】  呼出し通知チャネルによって呼出しチャネルを受信することを指示された全ての携帯端末は、自端末の機種及びソフトウェアバージョンと、呼出しチャネルに含まれている機種（端末種別）及びソフトウェアバージョンとを比較する。その比較結果、それらが異なっている携帯端末はその時点で待ち受け状態に戻る。また、それらが一致した携帯端末は、呼出しチャネルの情報を基に、必要なデータをマルチキャスト、またはブロードキャストで受信する。マルチキャストか、ブロードキャストかの判断は、呼出し時にネットワーク側から違いがわかるように設定されている。【００２７】  マルチキャストを行う場合には、一つでも携帯端末からの応答があれば、データ転送を開始するが、一つも応答がなければ、データ転送を行わず、ＯＴＡＳＰを終了する機能を有している。【００２８】  ソフトウェアバージョンの更新が成功した携帯端末は、自端末のソフトウェアバージョンを更新する。ソフトウェアバージョンの更新が失敗した携帯端末は、受信したデータを破棄し、ソフトウェアバージョンを更新しない。この動作によって、更新が成功した携帯端末では再度同じデータを受信することはないが、更新が失敗した携帯端末では成功するまで再度同じデータを受信することが可能である。
【発明の効果】
【００２９】  以上説明したように本発明は、上記のような構成及び処理手順とすることで、携帯端末において無駄な電力消費を行わせることなく、対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができるという効果が得られる。
【発明を実施するための最良の形態】
【００３０】  次に、本発明の実施例について図面を参照して説明する。図１及び図２は本発明の一実施例による移動通信システムの動作例を示す図である。図１において、本発明の一実施例による移動通信システムでは、移動通信のブロードキャストまたはマルチキャストにおいて、図示せぬサーバ（Ｓｅｒｖｅｒ）が携帯端末１−１〜１−５からの要求を受けることなく、対象となる携帯端末群にデータの配信を行い、携帯端末１−１〜１−５のソフトウェアを修正することを特徴とする。また、一度修正したソフトウェアは、何度も修正しないようにすることも特徴である。【００３１】  通常のブロードキャストでは、全ての携帯端末１−１〜１−５においてデータの受信が可能であるが、本実施例では対象となる携帯端末１−１，１−３のみがデータの受信を可能としている。【００３２】  また、通常のマルチキャストでは、携帯端末１−１〜１−５が自らの意思でサービスにＪｏｉｎ（参加）を行ってデータの受信を行うが、本実施例では、サーバが携帯端末１−１〜１−５特有の情報［例えば、ＩＭＥＩ−ＳＶ（Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ  ａｎｄ  Ｓｏｆｔｗａｒｅ  Ｖｅｒｓｉｏｎ  Ｎｕｍｂｅｒ）］を用いてネットワーク側から携帯端末１−１〜１−５を呼出すようにしている。「ＩＭＥＩ−ＳＶ」については、３ＧＰＰ  ＴＳ２３．００３  Ｖ５．５．１（２００３−１）の６．２．２章に記載されている。【００３３】  携帯端末１−１〜１−５ではソフトウェアの正常性の確認を行うことで、ソフトウェアの更新に成功した時に今後同じデータを受信しないように、またソフトウェアの更新に失敗した時に改めてデータを受信可能とする機能を備えている。【００３４】  図１において、サーバからのデータ（端末タイプＡ用のソフトウェアのバージョン“ｎ”のデータ）はＮｏｄｅＢ（基地局）２から携帯端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１−１〜１−５に送信されるが、そのデータは端末タイプＡでソフトウェアのバージョンが“ｎ”の携帯端末１−１，１−３のみで受信され、端末タイプＢの携帯端末１−４や端末タイプＡでソフトウェアのバージョンが“ｎ”より古い携帯端末１−２、端末タイプＡでソフトウェアのバージョンが“ｎ”より新しい携帯端末１−５では受信されない。【００３５】  ブロードキャストを用いたＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）では、対象となる携帯端末１−１，１−３の存在を確認する必要がなく、ネットワーク側は携帯端末１−１，１−３からの応答の受信もない。そのため、ネットワーク側での負荷が軽減される。しかしながら、対象となる携帯端末１−１，１−３がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、ＯＴＡＳＰは、無線を利用してサーバから送られてくるデータで携帯端末１−１〜１−５のソフトウェアを書換えるためのものである。「ＯＴＡＳＰ」については、３ＧＰＰ  ＴＲ２３．８４６  ６．１．０（２００２−１２）に記載されている。【００３６】  一方、マルチキャストを用いたＯＴＡＳＰでは、ネットワーク側が対象となる携帯端末１−１，１−３が存在するこ���を確認する必要があるので、携帯端末１−１，１−３からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。しかしながら、対象となる端末１−１，１−３が存在しないエリアにデータを送信することを避けることができる。【００３７】  そこで、本実施例では、最初の数回、対象となる携帯端末が多いことが予想されるため、ブロードキャストを利用して、ブロードキャストを数回適用した後、続いてマルチキャストを適用するようにしている。これによって、本実施例では効率の良いＯＴＡＳＰを実現することができる。【００３８】  図２においては、本実施例によるブロードキャスト及びマルチキャストの適用例を示している。この例では、携帯端末ＵＥ＃１〜ＵＥ＃１０へのソフトウェアの書換え動作を示しており、ソフトウェアのバージョン「３」からバージョン「４」への書換え例を示している。【００３９】  まず、サーバは１日目にブロードキャストにてソフトウェアのバージョン「４」のデータを配信する。端末を呼び出す時には、現在のバージョン「３」を利用し、端末タイプとバージョンとが一致した端末が反応する。この場合、携帯端末ＵＥ＃１，ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９は電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「４」のデータを書込む。他の携帯端末ＵＥ＃２〜ＵＥ＃４，ＵＥ＃６，ＵＥ＃１０では電源を入れていなかったので、サーバからのソフトウェアのバージョン「４」のデータが書込まれない。【００４０】  続いて、サーバは２日目にもブロードキャストにてソフトウェアのバージョン「４」のデータを配信する。この場合、携帯端末ＵＥ＃１，ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９はすでにデータが書込まれており、バージョンが一致しないので、そのブロードキャストに対して反応することはない。一方、携帯端末ＵＥ＃２〜ＵＥ＃４では電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「４」のデータを書込む。他の携帯端末ＵＥ＃６，ＵＥ＃１０ではまだ電源を入れていなかったので、サーバからのソフトウェアのバージョン「４」のデータが書込まれない。【００４１】  サーバは上記のブロードキャストを予め設定されたＮ−１日だけ適用すると、Ｎ日目にはマルチキャストにて携帯端末ＵＥ＃６，ＵＥ＃１０へのソフトウェアのバージョン「４」のデータ配信を行う。この場合、他の携帯端末ＵＥ＃１〜ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９はすでにデータが書込まれているので、そのマルチキャストに対して反応することはない。【００４２】  図３は本発明の一実施例による移動通信システムの構成を示すブロック図である。図３において、本発明の一実施例による移動通信システムは携帯端末（ＵＥ）１と、ＮｏｄｅＢ（基地局）２−１，２−２と、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）３と、ＳＧＳＮ［Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）Ｓｕｐｐｏｒｔ  Ｎｏｄｅ］４と、ＧＧＳＮ（Ｇａｔａｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）５と、サーバ６と、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク１００とから構成されている。
ここで、以下の説明では、簡略化のために、呼出し通知チャネルをＰＩＣＨ（Ｐａｇｅ  Ｉｎｄｉｃａｔｉｏｎ  Ｃｈａｎｎｅｌ）、呼出しチャネルをＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）とし、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）に特化した用語を用いるものとする。【００４３】  図４は図３のサーバ６の構成を示すブロック図である。図４において、サーバ６はデータ入出力部６１と、データ蓄積部６２と、データ送信制御部（スケジューラ）６３と、マルチキャスト部６４と、ブロードキャスト部６５とから構成されている。【００４４】  データ入出力部６１は他装置（例えば、携帯端末１に搭載する制御プログラム、アプリケーションプログラム等のプログラム製作会社の装置）からそれらのプログラムのアップデート用のデータ等が入力されると、そのデータをデータ蓄積部６２に蓄積する。また、データ入出力部６１はデータ蓄積部６２に蓄積されたデータを読出してデータ送信制御部６３に送出することで、当該データによるアップデートの指示を行う。【００４５】  データ送信制御部６３はデータ入出力部６１からデータを受取ると、上述したようなブロードキャスト及びマルチキャストによるそのデータの配信スケジュールを作成し、そのスケジュールにしたがってデータをマルチキャスト部６４及びブロードキャスト部６５に渡す。【００４６】  マルチキャスト部６４はデータ送信制御部６３で作成されたスケジュールにしたがってマルチキャストにて携帯端末１にデータ配信を行うために、データをＧＧＳＮ５に送信する。マルチキャスト部６４ではＧＧＳＮ５からの応答を待つ必要があり、応答を受信しない時には対象となる端末が配下に一つも存在しないと判断し、データ送信自体をやめる機能を持つ。ブロードキャスト部６５はデータ送信制御部６３で作成されたスケジュールにしたがってブロードキャストにて携帯端末１にデータ配信を行うために、データをＧＧＳＮ５に送信する。ブロードキャスト部６５では、マルチキャスト部６４とは異なり、ＧＧＳＮ５からの応答を待つ必要がない。マルチキャスト部６４及びブロードキャスト部６５はそれぞれ端末の受信準備が整ったと思われる一定時間後、データ送信を開始する。【００４７】  図５は図３の携帯端末（ＵＥ）１の構成を示すブロック図である。図５において、携帯端末１はアンテナ１１と、無線通信部１２と、制御部１３と、ベースバンド部１８と、音声入出力部１９と、表示部２０と、キー操作部２１とから構成されている。尚、アンテナ１１、無線通信部１２、ベースバンド部１８、音声入出力部１９、表示部２０、キー操作部２１各々の動作は公知であるので、それらの説明は省略する。【００４８】  制御部１３はＣＰＵ（中央処理装置）１４と、ＣＰＵ１４で動作する制御プログラムやアプリケーションプログラム等を格納するメモリ１５と、転送方式判定部１６と、データ転送制御部１７とから構成されている。【００４９】  転送方式判定部１６はサーバ６からソフトウェアのバージョンアップのデータ等が上述したブロードキャストで転送されてくるのか、あるいはマルチキャストで転送されてくるのかを判定し、その判定結果にしたがってＣＰＵ１４及びデ���タ転送制御部１７が動作する。【００５０】  サーバ６からソフトウェアのバージョンアップのデータ等がブロードキャストやマルチキャストで転送されてくる場合、ＣＰＵ１４及びデータ転送制御部１７は自端末のソフトウェアのバージョンと送られてくるデータのバージョンとを比較し、そのバージョンが一致しない場合には動作を終了する。ＣＰＵ１４及びデータ転送制御部１７はそのバージョンが一致した場合、マルチキャストであれば応答をネットワーク側に送信し、ブロードキャストであればネットワーク側になにも返送しないで、そのデータの取込み動作を準備して開始する。【００５１】  その際、携帯端末１は呼び出し用のチャネルの監視と上記の比較判定動作のみを行っていればよく、データの取込みを行う際に必要な部位に電源を供給すればよいため、従来のブロードキャストによるデータ受信時のように、装置全体に電源を供給する必要はない。【００５２】  図６は本発明におけるＰＩＣＨの構成及びＰＩＣＨとＰＣＨとの関係を示す図である。図６において、ＲＮＣ３と個別の通信を行うことができない状態の携帯端末１｛ｉｄｌｅ，Ｃｅｌｌ／ＵＲＡ［ＵＴＲＡＮ（ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）Ｒｅｇｉｓｔｒａｔｉｏｎ  Ａｒｅａ］＿ＰＣＨ｝はＲＮＣ３から指示されたタイミングでＰＩＣＨの間欠受信を行っている。これは携帯端末１が着信を受けるために必要な動作である。【００５３】  携帯端末１がＰＩＣＨを受信するタイミングは携帯端末１の識別子［ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）］等の値から計算される。ＰＩＣＨの１つのフレームは３００ビットで構成され、そのうちの後半１２ビットはリザーブとなっている。【００５４】  さらに、各携帯端末１がＰＩＣＨ内のどのビットを監視するかも、携帯端末１の識別子（ＩＭＳＩ）等の値から計算される。携帯端末１が監視すべきＰＩＣＨ内のビットが“１”になっていた場合には、携帯端末１がＰＩＣＨと対になっているＰＣＨを受信する。【００５５】  現状の３ＧＰＰの仕様は、呼出し通知チャネル（ＰＩＣＨ）の自端末を登録したビットを確認し、「１」であれば呼出しチャネル（ＰＣＨ）の情報を読出し、自端末の着信かどうか判断している。本実施例では、現状の３ＧＰＰの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって呼出し通知チャネルの間欠受信を行っている（図６及び図７参照）。【００５６】  図７〜図９は本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。図７〜図９において、ＰＩＣＨのフレーム番号数（０〜４０９５）、ＰＩＣＨ内のビット数（２８８）の制限から、必ずしも、ＰＩＣＨ内の各ビットに１つのＵＥが割当てられるとは限らない。【００５７】  仮に、ＰＩＣＨ内のあるビットに３つのＵＥが割当てられているとすると、そのビットを“１”にすることで３つのＵＥがＰＣＨの受信を行う。しかしながら、３つのＵＥが同時に着信を受けることは非常に稀であり、そのビットの“１”はどのＵＥを対象にしているかを示す方法が必要である。それを実現しているものがＰＣＨに含まれるＵＥ  Ｉｄｅｎｔｉｔｙである。ＰＣＨを受信したＵＥは必ずＵＥ  Ｉｄｅｎｔｉｔｙをチェックし、自端末宛の着信であるかどうかを確認する。【００５８】  ここでは、１つのデータを転送し、それを複数のＵＥに同時に受信させることを想定しているので、データ転送の対象となる複数のＵＥ（特定の機種、ソフトウェアバージョン）に同時に着信を行う必要がある。各ＵＥは異なる識別子を有するので、全てのＵＥに着信を行うために、まず、ＰＩＣＨの全てのビットを“１”に設定する。しかしながら、現状のＰＣＨのＵＥ  Ｉｄｅｎｔｉｔｙでは、個々のＵＥのＵＥ  Ｉｄｅｎｔｉｔｙが設定されてしまうため、複数のＵＥに同時に着信を行うには不向きである。【００５９】  そこで、ＵＥ  ＩｄｅｎｔｉｔｙにＩＭＥＩ−ＳＶを追加し、データの転送の対象となるＵＥの端末種別及びソフトウェアのバージョン情報をＵＥ識別子に用いる。これによって、対象となるＵＥをグループとして扱うことができる。ＩＭＥＩ−ＳＶには個々のＵＥを識別するためのシリアルナンバが含まれているが、ここでは特定のＵＥのグループに着信を行うことが目的であるので、シリアルナンバの情報は用いない。【００６０】  また、上記のようにＰＩＣＨの全てのビットを“１”に設定することで、対象となるＵＥが一斉にページングに対する応答を行い、上りの無線容量の圧迫、ネットワーク側での処理負荷の増大が懸念されるため、必ずしもＰＩＣＨの全てのビットを“１”と設定することが最良ではない場合も考えられる。例えば、ソフトウェアのダウンロードが完了する時間を見計らって、数分おきに“１”と設定するＰＩＣＨのビットを１０ｂｉｔずつシフトするということもできる。【００６１】  さらに、ＵＥ  ＩｄｅｎｔｉｔｙとしてＩＭＥＩ−ＳＶ以外のパラメータを設定することで、例えば、ミドルウェアやアプリケーションのアップデートに対しても上記の技術を適用することができる。【００６２】  本実施例では、上述したように、特定の携帯端末のソフトウェア修正を行う場合、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに“１”を設定する。また、呼出しチャネルには対象となる携帯端末の機種及びソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョン情報を含ませる（図７〜図９参照）。【００６３】  図１０は図３のサーバ６による処理手順を示すフローチャートである。これら図１〜図１０を参照して本発明の一実施例によるサーバ６による処理手順について説明する。
サーバ６はバージョンアップ等によるソフトウェアの変更が発生すると（図１０ステップＳ１）、予め設定されたブロードキャストの配信時刻（例えば、携帯端末１の使用が減る深夜等）になると（図１０ステップＳ２）、ソフトウェアの変更内容をブロードキャスト部６５からブロードキャストにて配信する（図１０ステップＳ３）。【００６４】  サーバ６はブロードキャストの配信回数が予め設定した回数（＝Ｌ）になるまで（図１０ステップＳ４）、上記の処理を繰返し行う。また、サーバ６はブロードキャストの配信日数が予め設定した日数（＝Ｍ）（例えば、１週間や１か月等）になるまで（図１０ステップＳ５）、毎日、上記の処理を配信時刻となる毎に行う。【００６５】  サーバ６はブロードキャストの配信日数が予め設定した日数（＝Ｍ）になり（図１０ステップＳ５）、予め設定したマルチキャストの配信時刻になると（図１０ステップＳ６）、マルチキャストによるＯＴＡＳＰ要求を送信する（図１０ステップＳ７）。【００６６】  サーバ６はその要求に対して応答する端末が一つでもあれば（図１０ステップＳ８）、ソフトウェアの変更内容をマルチキャスト部６４からマルチキャストにて配信する（図１０ステップＳ９）。サーバ６はマルチキャストの配信日数が予め設定した日数（＝Ｋ）（例えば、１週間や１か月等）になるまで（図１０ステップＳ１０）、毎日、上記の処理を配信時刻となる毎に行う。【００６７】  マルチキャストによるソフトウェアの配信が終了した後は、位置登録情報等の情報を利用して、個々の端末にソフトウェアのバージョンアップを促すことが可能である。【００６８】  図１１は図３の携帯端末１による処理手順を示すフローチャートである。これら図１〜図９と図１１とを参照して本発明の一実施例による携帯端末１の処理手順について説明する。【００６９】  携帯端末１は上述した従来と同様の処理でＰＣＨを受信する（図１１ステップＳ２１〜Ｓ２３）。携帯端末１は受信したＰＣＨを解析し、従来の着信、従来のＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）、ブロードキャストでのＯＴＡＳＰ、マルチキャストでのＯＴＡＳＰのいずれであるのかを認識する（図１１ステップＳ２４，Ｓ２５）。ここで、ＭＢＭＳの仕様は未決定であるので、ＰＣＨ以外のＣＨが用いられる可能性もある。「ＭＢＭＳ」については、３ＧＰＰ  ＴＳ２３．２４６  Ｖ０．３２．０１（２００２−０６）に記載されている。【００７０】  携帯端末１はブロードキャストでのＯＴＡＳＰの場合（図１１ステップＳ２４）、ネットワーク側がＯＴＡＳＰの対象となる携帯端末の存在を認識することを要求されないので、ネットワーク側からの信号に対する応答を行わずに、ＯＴＡＳＰのデータを受信する準備を行う（図１１ステップＳ３０）。データを受信するための情報はＰＣＨに含まれている。【００７１】  携帯端末１はマルチキャストでのＯＴＡＳＰの場合（図１１ステップＳ２５）、ネットワーク側がＯＴＡＳＰの対象となる携帯端末の存在を認識することが要求されるので、ページングの応答として、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔを送信し（図１１ステップＳ２７）、ＯＴＡＳＰのデータを受信する準備を行う（図１１ステップＳ２８）。【００７２】  但し、携帯端末１はブロードキャストでのＯＴＡＳＰの場合、またはマルチキャストでのＯＴＡＳＰの場合、自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種（端末種別）及びソフトウェアのバージョンとを比較する（図１１ステップＳ２６，Ｓ２９）。【００７３】  携帯端末１は上記の比較結果が異なっていれば、その時点で待ち受け状態に戻り、上記の比較結果が一致していれば、呼出しチャネルの情報を基に必要なデータをマルチキャスト、またはブロードキャストで受信する（図１１ステップＳ２８，Ｓ３０）。マルチキャストか、ブロードキャストかの判断は、上述したように、呼出し時にネットワーク側から違いがわかるように設定されている。【００７４】  図１２は本発明の一実施例によるＯＴＡＳＰでのデータ送信手順（マルチキャストでＯＴＡＳＰを行う場合の手順）を示すシーケンスチャートである。これら図３及び図１２を参照して本発明の一実施例によるマルチキャストでＯＴＡＳＰを行う場合の手順について説明する。【００７５】  サーバ６はソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、ＯＴＡＳＰ要求をＧＧＳＮ５に送信する（図１２のａ１）。このメッセージには、端末種別とソフトウェアのバージョン情報とが含まれ、さらに携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答をサーバ６に転送するためにサーバ６の識別子も含まれている。この場合にはデータの転送モードも指定され、この転送モードによってＲＮＣ３の動作が異なる。この例では転送モードにマルチキャストが設定されている。【００７６】  ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ要求を受信すると、ＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）−ＣメッセージでＯＴＡＳＰ要求をＳＧＳＮ４に転送する（図１２のａ２）。【００７７】  ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ要求を受信すると、ＲＡＮＡＰ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐａｒｔ）のＰａｇｉｎｇメッセージでＯＴＡＳＰ要求をＲＮＣ３に転送する（図１２のａ３）。【００７８】  マルチキャスト転送はＲＮＣ３が対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）を意識したい時に用いられるので、ＲＮＣ３はＲＲＣのＰａｇｉｎｇメッセージを携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し（図１２のａ４）、対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答を期待する。この時のＰａｇｉｎｇには、上記の図６〜図９によって説明した方法が用いられる。【００７９】  マルチキャストの場合には、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔが携帯端末（ＵＥ＃１，ＵＥ＃２）からＲＮＣ３に送信される（図１２のａ６）。本実施例では、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｑｕｅｓｔがＲＮＣ３に送信されるのは、上記のように、携帯端末（ＵＥ＃１，ＵＥ＃２）が自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合である（図１２のａ５）。【００８０】  この後、携帯端末（ＵＥ＃１，ＵＥ＃２）は���ーバ６に対してＪｏｉｎ（参加）を行うためのデフォルトのトンネルを確立し（図１２のａ７）、サーバ６に対してＯＴＡＳＰのデータを受信する意思があることを知らせるためにＪｏｉｎを行う（図１２のａ８）。これらの処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。【００８１】  サーバ６は携帯端末（ＵＥ＃１，ＵＥ＃２）のうちの一つでもＪｏｉｎの応答があった場合、ＯＴＡＳＰのデータの送信を開始する（図１２のａ９）。ネットワークの各装置はＭＢＭＳの手順にしたがってデータを送信する。【００８２】  サーバ６はＯＴＡＳＰのデータの送信が終わると、ＧＧＳＮ５にＯＴＡＳＰ終了通知でデータ送信の終了を通知する（図１２のａ１０）。この時、ＯＴＡＳＰ終了通知にはＯＴＡＳＰ要求に含まれていた機種及びソフトウェアのバージョン情報が含まれる。【００８３】  ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ終了通知を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ終了通知をＳＧＳＮ４に転送する（図１２のａ１１）。ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ終了通知を受信すると、ＲＡＮＡＰメッセージでＯＴＡＳＰ終了通知をＲＮＣ３に転送する（図１２のａ１２）。【００８４】  ＲＮＣ３はＳＧＳＮ４からのＯＴＡＳＰ終了通知を受信すると、ＲＲＣメッセージで、ＯＴＡＳＰ終了通知を対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し（図１２のａ１３）、データ送信が終了したことを通知する。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。【００８５】  携帯端末（ＵＥ＃１，ＵＥ＃２）は上記のＯＴＡＳＰのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図１２のａ１４）。【００８６】  図１３は本発明の一実施例によるＯＴＡＳＰでのデータ送信手順（ブロードキャストでＯＴＡＳＰを行う場合の手順）を示すシーケンスチャートである。これら図３及び図１３を参照して本発明の一実施例によるブロードキャストでＯＴＡＳＰを行う場合の手順について説明する。【００８７】  サーバ６はソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、ＯＴＡＳＰ要求をＧＧＳＮ５に送信する（図１３のａ２１）。このメッセージには端末種別及びソフトウェアのバージョン情報が含まれ、さらに、データの転送モードも指定され、この転送モードによってＮＣ３の動作が異なる。この場合には、サーバ６が携帯端末（ＵＥ＃１，ＵＥ＃２）からの信号を受信する必要がないので、サーバ６への信号転送のための情報は含まない。【００８８】  ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ要求を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ要求をＳＧＳＮ４に転送する（図１３のａ２２）。ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ要求を受信すると、ＲＡＮＡＰのＰａｇｉｎｇメッセージでＯＴＡＳＰ要求をＲＮＣ３に転送する（図１３のａ２３）。【００８９】  ブロードキャスト転送はネットワークが対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）を意識しなくても良い時に用いられるので、ＲＮＣ３は対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答を期待する通常のページングではなく、ブロードキャス���を示すページングを行う（図１３のａ２４）。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。また、これらの処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。【００９０】  携帯端末（ＵＥ＃１，ＵＥ＃２）は、上記のように、自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合（図１３のａ２５）、ＯＴＡＳＰのデータを受信する準備を行う（図１３のａ２６）。この処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。【００９１】  この後、サーバ６はＯＴＡＳＰのデータの送信を行う（図１３のａ２７）。ネットワークの各装置は、３ＧＰＰ標準のＭＢＭＳの手順にしたがってデータを送信する。【００９２】  サーバ６はＯＴＡＳＰのデータの送信が終わると、ＯＴＡＳＰ終了通知でＧＧＳＮ５にデータ送信の終了を通知する（図１３のａ２８）。この時、ＯＴＡＳＰ終了通知には上記のＯＴＡＳＰ要求に含まれていた端末種別及びソフトウェアのバージョン情報が含まれている。【００９３】  ＧＧＳＮ５はサーバ６からＯＴＡＳＰ終了通知を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ終了通知をＳＧＳＮ４に転送する（図１３のａ２９）。ＳＧＳＮ４はＧＧＳＮ５からＯＴＡＳＰ終了通知を受信すると、ＲＡＮＡＰメッセージでＯＴＡＳＰ終了通知をＲＮＣ３に転送する（図１３のａ３０）。【００９４】  ＲＮＣ３はＳＧＳＮ４からＯＴＡＳＰ終了通知を受信すると、ＲＲＣメッセージで、ＯＴＡＳＰ終了通知を対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し、データ送信が終了したことを通知する（図１３のａ３１）。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。【００９５】  携帯端末（ＵＥ＃１，ＵＥ＃２）は上記のＯＴＡＳＰのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図１３のａ３２）。【００９６】  図１４は図３のサーバ６側での処理手順（マルチキャストでＯＴＡＳＰを行う場合の手順）を示すフローチャートである。これら図３及び図１４を参照してサーバ６側でマルチキャストにてＯＴＡＳＰを行う場合の手順について説明する。【００９７】  マルチキャストでは対象の携帯端末１が存在しない時にデータの送信を行わないので、サーバ６はＯＴＡＳＰ要求を行うと同時に（図１４ステップＳ４１）、携帯端末１からの応答を待ち受けるタイマ（図示せず）を起動する。【００９８】  サーバ６はタイマが満了するまでに携帯端末１からの応答がなければ（図１４ステップＳ４２，Ｓ４３）、ＯＴＡＳＰを終了する（図１４ステップＳ４５）。このタイマは対象の携帯端末１が存在するかを確認するだけではなく、対象となる携帯端末群からの応答を収集するという目的も含まれている。【００９９】  一方、サーバ６はタイマが満了するまでに携帯端末１からの応答があれば（図１４ステップＳ４２，Ｓ４３）、ＯＴＡＳＰデータの送信を開始する（図１４ステップＳ４４）。【０１００】  サーバ６はマルチキャストを行う場合、上記のように、一つでも携帯端末１からの応答があればＯＴＡＳＰデータの転送を開始するが、一つも応答がなければデータ転送を行わず、ＯＴＡＳＰを終了する機能を有する。【０１０１】  尚、上記のマルチキャストによる端末ページングは、上述したようなソフトウェアのバージョンアップだけでなく、使用するソフトウェアのバージョンを使用している端末数の統計データの取得やその端末への特定ソフトウェアの提供等にも使用することが可能であり、これらに限定されるものではない。【０１０２】  図１５は図３の携帯端末１でのデータの処理手順を示すフローチャートである。これら図３及び図１５を参照して携帯端末１におけるデータの処理手順について説明する。【０１０３】  携帯端末１はＯＴＡＳＰ終了のメッセージが到達しない場合を考慮して、ＯＴＡＳＰ終了メッセージ待ちタイマをＯＴＡＳＰのデータの受信を開始したら起動する（図１５ステップＳ５１，Ｓ５２）。【０１０４】  携帯端末１はＲＲＣメッセージにてＯＴＡＳＰ終了が通知され（図１５ステップＳ５３）、ソフトウェアのアップデートに成功すると（図１５ステップＳ５４）、自端末のソフトウェアのバージョンを更新する（図１５ステップＳ５５）。【０１０５】  これはＯＴＡＳＰ終了通知に含まれる機種及びソフトウェアバージョンが、ＯＴＡＳＰ要求に含まれていた機種及びソフトウェアバージョンを用いるため、ＯＴＡＳＰ終了通知を受信する前にソフトウェアバージョンを書換えてしまうと、終了通知を受信することができなくなってしまうからである。【０１０６】  携帯端末１はソフトウェアのアップデートが成功する前に、ＯＴＡＳＰ終了タイマが満了したり（図１５ステップＳ５２）、ＯＴＡＳＰ終了が通知されると（図１５ステップＳ５３，Ｓ５４）、そこまで受信したＯＴＡＳＰデータを破棄し（図１５ステップＳ５６）、アップデートの手順を終了して機種及びソフトウェアのバージョン情報として以前のものを用いる。ソフトウェアのアップデートが失敗する場合としては、携帯端末１でのデータの受信が完了する前に、ＯＴＡＳＰ終了が通知されることも考えられる。【０１０７】  上記のように、携帯端末１はソフトウェアのアップデートが成功すると、自端末のソフトウェアのバージョン情報を更新する。また、携帯端末１はソフトウェアのアップデートが失敗すると、受信したデータを破棄し、ソフトウェアのバージョンを更新しない。【０１０８】  これらの動作によって、ソフトウェアの更新が成功した携帯端末１は再度同じデータを受信することはないが、更新が失敗した携帯端末１は成功するまでソフトウェアのバージョンを更新しないので、再度同じデータを受信することが可能となる。【０１０９】  このように、本実施例では、ソフトウェアのバージョンアップ等におけるプログラムの書換えを行うためのＯＴＡＳＰにＭＢＭＳを利用することで、携帯端末１において無駄な電力消費を行わせることなく、対象となる携帯端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる。【０１１０】  また、本実施例では、携帯端末に特有の情報（例えば、ＩＭＥＩ−ＳＶに含まれている機種及びソフトウェアのバージョン情報）を利用することで、携帯端末１のグループ化を効果的に行うことができる。【０１１１】  さらに、本実��例では、ソフトウェアの更新が完了した携帯端末１が自端末のソフトウェアのバージョンを更新することで、同じデータの重複受信を避けることができる。
【図面の簡単な説明】
【０１１２】［図１］本発明の一実施例による移動通信システムの動作例を示す図である。
［図２］（ａ）〜（ｃ）は本発明の一実施例による移動通信システムの動作例を示す図である。
［図３］本発明の一実施例による移動通信システムの構成を示すブロック図である。
［図４］図３のサーバの構成を示すブロック図である。
［図５］図３の携帯端末の構成を示すブロック図である。
［図６］本発明におけるＰＩＣＨの構成及びＰＩＣＨとＰＣＨとの関係を示す図である。
［図７］本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
［図８］本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
［図９］本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
［図１０］図３のサーバによる処理手順を示すフローチャートである。
［図１１］図３の携帯端末による処理手順を示すフローチャートである。
［図１２］本発明の一実施例によるＯＴＡＳＰでのデータ送信手順を示すシーケンスチャートである。
［図１３］本発明の一実施例によるＯＴＡＳＰでのデータ送信手順を示すシーケンスチャートである。
［図１４］図３のサーバ側での処理手順を示すフローチャートである。
［図１５］図３の携帯端末でのデータの処理手順を示すフローチャートである。
【符号の説明】
【０１１３】  １，１−１〜１−５  携帯端末
２，２−１，２−２  ＮｏｄｅＢ
３  ＲＮＣ
４  ＳＧＳＮ
５  ＧＧＳＮ
６  サーバ
１１  アンテナ
１２  無線通信部
１３  制御部
１４  ＣＰＵ
１５  メモリ
１６  転送方式判定部
１７  データ転送制御部
１８  ベースバンド部
１９  音声入出力部
２０  表示部
２１  キー操作部
６１  データ入出力部
６２  データ蓄積部
６３  データ送信制御部
６４  マルチキャスト部
６５  ブロードキャスト部
１００  ＩＰネットワーク
【図１】
2004107797.tif 000003
【図２】
2004107797.tif 000004
【図３】
2004107797.tif 000005
【図４】
2004107797.tif 000006
【図５】
2004107797.tif 000007
【図６】
2004107797.tif 000008
【図７】
2004107797.tif 000009
【図８】
2004107797.tif 000010
【図９】
2004107797.tif 000011
【図１０】
2004107797.tif 000012
【図１１】
2004107797.tif 000013
【図１２】
2004107797.tif 000014
【図１３】
2004107797.tif 000015
【図１４】
2004107797.tif 000016
【図１５】
2004107797.tif 000017
【手続補正書】
【提出日】平成18年1月12日(2006.1.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有し、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを前記携帯端末に含むことを特徴とする移動通信システム。
【請求項２】
前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別する機能と、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを前記携帯端末に含むことを特徴とする請求項１記載の移動通信システム。
【請求項３】
前記サーバは、前記携帯端末との間で互いに認識し合うために用いた既知のＩＤを使用して前記マルチキャストを行うことを特徴とする請求項１又は２記載の移動通信システム。
【請求項４】
前記サーバは、前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項１から３のいずれか１項記載の移動通信システム。
【請求項５】
前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を前記携帯端末に含むことを特徴とする請求項１から請求項４のいずれか記載の移動通信システム。
【請求項６】
無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行うサーバであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を有し、前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とするサーバ。
【請求項７】
前記携帯端末との間で互いに認識し合うために用いた既知のＩＤを使用して前記マルチキャストを行うことを特徴とする請求項６記載のサーバ。
【請求項８】
無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が行われる移動通信システムの携帯端末であって、前記ＯＴＡＳＰが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを有し、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを含むことを特徴とする携帯端末。
【請求項９】
前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止する機能を含むことを特徴とする請求項８記載の携帯端末。
【請求項１０】
無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップと、前記携帯端末側に、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別するステップと、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信するステップと、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信するステップとを有することを特徴とするデータ転送方法。
【請求項１１】
前記携帯端末側に、前記端末種別と前記バージョン情報とを基に前記要求が自端末に対するものかを判別するステップと、前記要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新するステップとを含むことを特徴とする請求項１０記載のデータ転送方法。
【請求項１２】
前記サーバは、前記携帯端末との間で互いに認識し合うために用いた既知のＩＤを使用して前記マルチキャストを行うことを特徴とする請求項１０又は１１記載のデータ転送方法。
【請求項１３】
前記サーバが前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うことを特徴とする請求項１０から１２のいずれか１項記載のデータ転送方法。
【請求項１４】
前記携帯端末側に、前記データにて前記ソフトウェアの更新が終了するまで当該ソフトウェアのバージョン情報の更新を抑止するステップを含むことを特徴とする請求項１０から請求項１３のいずれか１項記載のデータ転送方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法に関し、特に携帯電話機内のソフトウェアの更新を行うためのデータ転送方法に関する。
【背景技術】
【０００２】
近年、携帯電話システムにおいては、携帯電話端末の加入者が飛躍的に増大しているが、携帯端末の不具合を修正するために、販売済みの携帯端末を回収するという出来事も生じている。
【０００３】
このような携帯端末の回収処理を避けるという目的も含めて、無線を利用して携帯端末のソフトウェアを書換えるというＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が３ＧＰＰ２（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  ２）で検討されている（例えば、非特許文献１参照）。
【０００４】
この場合、ソフトウェアを書換える携帯端末を特定する技術としては、ページング技術がある。ページング技術では、携帯端末に対して着信があった時に、その旨を携帯端末に通知する必要があり、携帯端末が位置登録している位置登録エリア内の全ての携帯端末に対して着信があったことを同報的に通知する。すると、携帯端末では待ち受け状態にあっても、呼び出し用のチャネルを常に監視しているため、自端末に対するページングを認識することが可能となる（例えば、非特許文献２参照）。
【０００５】
しかしながら、携帯端末一つ一つにデータを転送しているのでは効率が悪くなるため、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する技術も提案されている（例えば、特許文献１，２参照）。
【特許文献１】特開２００１−２８７８７号公報（第７，８、図１）
【特許文献２】特開２００３−５１７９６号公報（第６〜８、図１）
【非特許文献１】３ＧＰＰ２  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅｓ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｒｅｌｅａｓｅ  Ａ，Ｊｕｎｅ，２０００
【非特許文献２】「Ｗ−ＣＤＭＡ移動通信方式  ４  ネットワーク方式  ４−３  ネットワーク制御・信号方式」（立川敬二  監修、丸善株式会社刊、平成１３年６月２５日発行、第２５４〜２５６頁
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記の３ＧＰＰ２で検討されているＯＴＡＳＰでは、携帯端末毎にデータを送信しており、複数の携帯端末が同時に同じデータを受信することができるという無線の性質が最大限に利用されていない。この場合、携帯端末毎にデータを送信することは、移動通信システム自体の輻輳を招いてしまう。
【０００７】
また、ソフトウェアを書換える必要がある携帯端末全てにブロードキャストにてデータを伝送する方法では、ソフトウェアを書換える必要がない携帯端末でもそのデータを受信し、必要でないと判定した時に当該データを破棄する動作が必要になる。つまり、この方法では、ソフトウェアを書換える必要がない場合でもそのデータの受信動作と判定動作とを行わなければならず、携帯端末の消費電力の増大を招くという問題がある。
【０００８】
そこで、本発明の目的は上記の問題点を解消し、対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる移動通信システム、サーバ、携帯端末及びそれに用いるデータ転送方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明による移動通信システムは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を前記サーバに有し、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを前記携帯端末に備えている。
【００１０】
本発明によるサーバは、無線を利用してデータを送信し、当該データで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行うサーバであって、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出す機能を有し、前記ブロードキャストで前記データ転送を繰返した後に前記マルチキャストにて前記データ転送を行うものである。
【００１１】
本発明による携帯端末は、無線を利用してサーバから送られてくるデータで自端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）が行われる移動通信システムの携帯端末であって、前記ＯＴＡＳＰが行われる際の要求に付加された端末種別と前記ソフトウェアのバージョン情報とを基に当該要求が自端末に対するものかを判別する機能と、当該要求が自端末に対するものと判別した時に前記サーバからのデータで前記ソフトウェアを更新する機能とを有し、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別する機能と、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信する機能と、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信する機能とを備えている。
【００１２】
本発明によるデータ転送方法は、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）を行う移動通信システムのデータ転送方法であって、前記サーバ側に、前記ＯＴＡＳＰを行う際の要求に前記携帯端末の端末種別と前記ソフトウェアのバージョン情報とを付加して送信することで対象とする携帯端末を呼出すステップと、前記携帯端末側に、前記要求に付加された情報を基に前記データがマルチキャスト及びブロードキャストのいずれかで転送されてくるかを判別するステップと、前記マルチキャストと判別した時に前記要求に対する応答を送信してから前記データを受信するステップと、前記ブロードキャストと判別した時に前記応答の送信を行わずにそのまま前記データを受信するステップとを備えている。
【００１３】
すなわち、本発明の移動通信システムは、移動通信のブロードキャストまたはマルチキャストにおいて、サーバが携帯端末からの要求を受けることなく、対象となる携帯端末群にデータの配信を行い、携帯端末のソフトウェアを修正することを特徴とする。この場合、一度修正したソフトウェアは、何度も修正しないようにすることも特徴とする。
【００１４】
通常、ブロードキャストにおいては、全ての携帯端末がデータを受信することが可能であるが、本発明では対象となる携帯端末のみがデータの受信を可能とする方式を実現するものである。
【００１５】
また、通常、マルチキャストでは、携帯端末が自らの意思でサービスにＪｏｉｎ（参加）を行い、データの受信を行うが、本発明では、サーバが携帯端末特有の情報［例えば、ＩＭＥＩ−ＳＶ（Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ  ａｎｄ  Ｓｏｆｔｗａｒｅ  Ｖｅｒｓｉｏｎ  Ｎｕｍｂｅｒ）］を用いてネットワーク側から携帯端末を呼出すことを提案している。
【００１６】
さらに、本発明では、ソフトウェアの正常性の確認を行うことで、成功した時に今後同じデータを受信しないように、失敗した時に改めてデータを受信可能とする機能を有している。
【００１７】
ブロードキャストを用いたＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）では、対象となる携帯端末の存在を確認する必要がなく、ネットワーク側は携帯端末からの応答の受信もない。そのため、ネットワーク側での負荷が軽減される。しかしながら、対象となる携帯端末がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、ＯＴＡＳＰは、無線を利用してサーバから送られてくるデータで携帯端末のソフトウェアを書換えるためのものである。
【００１８】
一方、マルチキャストを用いたＯＴＡＳＰでは、ネットワーク側は対象となる携帯端末が存在することを確認する必要があるので、携帯端末からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。しかしながら、対象となる携帯端末が存在しないエリアにデータを送信することを避けることが可能となる。
【００１９】
そこで、最初の数回は対象となる携帯端末が多いことが予想されるため、ブロードキャストを利用し、ブロードキャストを数回適用した後で、マルチキャストを適用することが考えられる。これによって、効率の良いＯＴＡＳＰが実現可能となる。
【００２０】
現在、３ＧＰＰではＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）が検討されている。ＭＢＭＳの目的は、無線リソースの有効利用であり、あるデータをあるエリア全体に送信するブロードキャストと、あるデータをそのデータの受信を望んでいる携帯端末のグループのみに送信するマルチキャストが考えられている。これらの技術を利用することで、特定の携帯端末のグループのみに必要なデータを送信することが可能となる。
【００２１】
現状の３ＧＰＰの仕様では、呼出し通知チャネル（ＰＩＣＨ：Ｐａｇｅ  Ｉｎｄｉｃａｔｉｏｎ  Ｃｈａｎｎｅｌ）における自端末が登録されたビットを確認し、そのビットが「１」であれば、呼出しチャネル（ＰＣＨ：Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）の情報を読出し、自端末の着信かどうかを判断している。本発明では、現状の３ＧＰＰの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって、呼出し通知チャネルの間欠受信を行っている。
【００２２】
特定の携帯端末のソフトウェア修正を行う場合には、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに「１」を設定する。また、呼出しチャネルには対象となる携帯端末の機種（端末種別）とソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョンの情報とを含ませる。
【００２３】
呼出し通知チャネルによって呼出しチャネルを受信することを指示された全ての携帯端末は、自端末の機種及びソフトウェアバージョンと、呼出しチャネルに含まれている機種（端末種別）及びソフトウェアバージョンとを比較する。その比較結果、それらが異なっている携帯端末はその時点で待ち受け状態に戻る。また、それらが一致した携帯端末は、呼出しチャネルの情報を基に、必要なデータをマルチキャスト、またはブロードキャストで受信する。マルチキャストか、ブロードキャストかの判断は、呼出し時にネットワーク側から違いがわかるように設定されている。
【００２４】
マルチキャストを行う場合には、一つでも携帯端末からの応答があれば、データ転送を開始するが、一つも応答がなければ、データ転送を行わず、ＯＴＡＳＰを終了する機能を有している。
【００２５】
ソフトウェアバージョンの更新が成功した携帯端末は、自端末のソフトウェアバージョンを更新する。ソフトウェアバージョンの更新が失敗した携帯端末は、受信したデータを破棄し、ソフトウェアバージョンを更新しない。この動作によって、更新が成功した携帯端末では再度同じデータを受信することはないが、更新が失敗した携帯端末では成功するまで再度同じデータを受信することが可能である。
【発明の効果】
【００２６】
以上説明したように本発明は、上記のような構成及び処理手順とすることで、携帯端末において無駄な電力消費を行わせることなく、対象となる端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができるという効果が得られる。
【発明を実施するための最良の形態】
【００２７】
次に、本発明の実施例について図面を参照して説明する。図１及び図２は本発明の一実施例による移動通信システムの動作例を示す図である。図１において、本発明の一実施例による移動通信システムでは、移動通信のブロードキャストまたはマルチキャストにおいて、図示せぬサーバ（Ｓｅｒｖｅｒ）が携帯端末１−１〜１−５からの要求を受けることなく、対象となる携帯端末群にデータの配信を行い、携帯端末１−１〜１−５のソフトウェアを修正することを特徴とする。また、一度修正したソフトウェアは、何度も修正しないようにすることも特徴である。
【００２８】
通常のブロードキャストでは、全ての携帯端末１−１〜１−５においてデータの受信が可能であるが、本実施例では対象となる携帯端末１−１，１−３のみがデータの受信を可能としている。
【００２９】
また、通常のマルチキャストでは、携帯端末１−１〜１−５が自らの意思でサービスにＪｏｉｎ（参加）を行ってデータの受信を行うが、本実施例では、サーバが携帯端末１−１〜１−５特有の情報［例えば、ＩＭＥＩ−ＳＶ（Ｔｈｅ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ  Ｅｑｕｉｐｍｅｎｔ  Ｉｄｅｎｔｉｔｙ  ａｎｄ  Ｓｏｆｔｗａｒｅ  Ｖｅｒｓｉｏｎ  Ｎｕｍｂｅｒ）］を用いてネットワーク側から携帯端末１−１〜１−５を呼出すようにしている。「ＩＭＥＩ−ＳＶ」については、３ＧＰＰ  ＴＳ２３．００３  Ｖ５．５．１（２００３−１）の６．２．２章に記載されている。
【００３０】
携帯端末１−１〜１−５ではソフトウェアの正常性の確認を行うことで、ソフトウェアの更新に成功した時に今後同じデータを受信しないように、またソフトウェアの更新に失敗した時に改めてデータを受信可能とする機能を備えている。
【００３１】
図１において、サーバからのデータ（端末タイプＡ用のソフトウェアのバージョン"ｎ"のデータ）はＮｏｄｅＢ（基地局）２から携帯端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１−１〜１−５に送信されるが、そのデータは端末タイプＡでソフトウェアのバージョンが"ｎ"の携帯端末１−１，１−３のみで受信され、端末タイプＢの携帯端末１−４や端末タイプＡでソフトウェアのバージョンが"ｎ"より古い携帯端末１−２、端末タイプＡでソフトウェアのバージョンが"ｎ"より新しい携帯端末１−５では受信されない。
【００３２】
ブロードキャストを用いたＯＴＡＳＰ（Ｏｖｅｒ  Ｔｈｅ  Ａｉｒ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｓｉｏｎｉｎｇ）では、対象となる携帯端末１−１，１−３の存在を確認する必要がなく、ネットワーク側は携帯端末１−１，１−３からの応答の受信もない。そのため、ネットワーク側での負荷が軽減される。しかしながら、対象となる携帯端末１−１，１−３がそのエリアに存在しなくても、データを送信する場合が生じる。ここで、ＯＴＡＳＰは、無線を利用してサーバから送られてくるデータで携帯端末１−１〜１−５のソフトウェアを書換えるためのものである。「ＯＴＡＳＰ」については、３ＧＰＰ  ＴＲ２３．８４６  ６．１．０（２００２−１２）に記載されている。
【００３３】
一方、マルチキャストを用いたＯＴＡＳＰでは、ネットワーク側が対象となる携帯端末１−１，１−３が存在することを確認する必要があるので、携帯端末１−１，１−３からの応答を受信する必要がある。そのため、ネットワーク側での負荷が高くなる。しかしながら、対象となる端末１−１，１−３が存在しないエリアにデータを送信することを避けることができる。
【００３４】
そこで、本実施例では、最初の数回、対象となる携帯端末が多いことが予想されるため、ブロードキャストを利用して、ブロードキャストを数回適用した後、続いてマルチキャストを適用するようにしている。これによって、本実施例では効率の良いＯＴＡＳＰを実現することができる。
【００３５】
図２においては、本実施例によるブロードキャスト及びマルチキャストの適用例を示している。この例では、携帯端末ＵＥ＃１〜ＵＥ＃１０へのソフトウェアの書換え動作を示しており、ソフトウェアのバージョン「３」からバージョン「４」への書換え例を示している。
【００３６】
まず、サーバは１日目にブロードキャストにてソフトウェアのバージョン「４」のデータを配信する。端末を呼び出す時には、現在のバージョン「３」を利用し、端末タイプとバージョンとが一致した端末が反応する。この場合、携帯端末ＵＥ＃１，ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９は電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「４」のデータを書込む。他の携帯端末ＵＥ＃２〜ＵＥ＃４，ＵＥ＃６，ＵＥ＃１０では電源を入れていなかったので、サーバからのソフトウェアのバージョン「４」のデータが書込まれない。
【００３７】
続いて、サーバは２日目にもブロードキャストにてソフトウェアのバージョン「４」のデータを配信する。この場合、携帯端末ＵＥ＃１，ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９はすでにデータが書込まれており、バージョンが一致しないので、そのブロードキャストに対して反応することはない。一方、携帯端末ＵＥ＃２〜ＵＥ＃４では電源を入れていたので、自端末にサーバからのソフトウェアのバージョン「４」のデータを書込む。他の携帯端末ＵＥ＃６，ＵＥ＃１０ではまだ電源を入れていなかったので、サーバからのソフトウェアのバージョン「４」のデータが書込まれない。
【００３８】
サーバは上記のブロードキャストを予め設定されたＮ−１日だけ適用すると、Ｎ日目にはマルチキャストにて携帯端末ＵＥ＃６，ＵＥ＃１０へのソフトウェアのバージョン「４」のデータ配信を行う。この場合、他の携帯端末ＵＥ＃１〜ＵＥ＃５，ＵＥ＃７〜ＵＥ＃９はすでにデータが書込まれているので、そのマルチキャストに対して反応することはない。
【００３９】
図３は本発明の一実施例による移動通信システムの構成を示すブロック図である。図３において、本発明の一実施例による移動通信システムは携帯端末（ＵＥ）１と、ＮｏｄｅＢ（基地局）２−１，２−２と、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）３と、ＳＧＳＮ［Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）Ｓｕｐｐｏｒｔ  Ｎｏｄｅ］４と、ＧＧＳＮ（Ｇａｔａｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）５と、サーバ６と、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワーク１００とから構成されている。
【００４０】
ここで、以下の説明では、簡略化のために、呼出し通知チャネルをＰＩＣＨ（Ｐａｇｅ  Ｉｎｄｉｃａｔｉｏｎ  Ｃｈａｎｎｅｌ）、呼出しチャネルをＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）とし、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）に特化した用語を用いるものとする。
【００４１】
図４は図３のサーバ６の構成を示すブロック図である。図４において、サーバ６はデータ入出力部６１と、データ蓄積部６２と、データ送信制御部（スケジューラ）６３と、マルチキャスト部６４と、ブロードキャスト部６５とから構成されている。
【００４２】
データ入出力部６１は他装置（例えば、携帯端末１に搭載する制御プログラム、アプリケーションプログラム等のプログラム製作会社の装置）からそれらのプログラムのアップデート用のデータ等が入力されると、そのデータをデータ蓄積部６２に蓄積する。また、データ入出力部６１はデータ蓄積部６２に蓄積されたデータを読出してデータ送信制御部６３に送出することで、当該データによるアップデートの指示を行う。
【００４３】
データ送信制御部６３はデータ入出力部６１からデータを受取ると、上述したようなブロードキャスト及びマルチキャストによるそのデータの配信スケジュールを作成し、そのスケジュールにしたがってデータをマルチキャスト部６４及びブロードキャスト部６５に渡す。
【００４４】
マルチキャスト部６４はデータ送信制御部６３で作成されたスケジュールにしたがってマルチキャストにて携帯端末１にデータ配信を行うために、データをＧＧＳＮ５に送信する。マルチキャスト部６４ではＧＧＳＮ５からの応答を待つ必要があり、応答を受信しない時には対象となる端末が配下に一つも存在しないと判断し、データ送信自体をやめる機能を持つ。ブロードキャスト部６５はデータ送信制御部６３で作成されたスケジュールにしたがってブロードキャストにて携帯端末１にデータ配信を行うために、データをＧＧＳＮ５に送信する。ブロードキャスト部６５では、マルチキャスト部６４とは異なり、ＧＧＳＮ５からの応答を待つ必要がない。マルチキャスト部６４及びブロードキャスト部６５はそれぞれ端末の受信準備が整ったと思われる一定時間後、データ送信を開始する。
【００４５】
図５は図３の携帯端末（ＵＥ）１の構成を示すブロック図である。図５において、携帯端末１はアンテナ１１と、無線通信部１２と、制御部１３と、ベースバンド部１８と、音声入出力部１９と、表示部２０と、キー操作部２１とから構成されている。尚、アンテナ１１、無線通信部１２、ベースバンド部１８、音声入出力部１９、表示部２０、キー操作部２１各々の動作は公知であるので、それらの説明は省略する。
【００４６】
制御部１３はＣＰＵ（中央処理装置）１４と、ＣＰＵ１４で動作する制御プログラムやアプリケーションプログラム等を格納するメモリ１５と、転送方式判定部１６と、データ転送制御部１７とから構成されている。
【００４７】
転送方式判定部１６はサーバ６からソフトウェアのバージョンアップのデータ等が上述したブロードキャストで転送されてくるのか、あるいはマルチキャストで転送されてくるのかを判定し、その判定結果にしたがってＣＰＵ１４及びデータ転送制御部１７が動作する。
【００４８】
サーバ６からソフトウェアのバージョンアップのデータ等がブロードキャストやマルチキャストで転送されてくる場合、ＣＰＵ１４及びデータ転送制御部１７は自端末のソフトウェアのバージョンと送られてくるデータのバージョンとを比較し、そのバージョンが一致しない場合には動作を終了する。ＣＰＵ１４及びデータ転送制御部１７はそのバージョンが一致した場合、マルチキャストであれば応答をネットワーク側に送信し、ブロードキャストであればネットワーク側になにも返送しないで、そのデータの取込み動作を準備して開始する。
【００４９】
その際、携帯端末１は呼び出し用のチャネルの監視と上記の比較判定動作のみを行っていればよく、データの取込みを行う際に必要な部位に電源を供給すればよいため、従来のブロードキャストによるデータ受信時のように、装置全体に電源を供給する必要はない。
【００５０】
図６は本発明におけるＰＩＣＨの構成及びＰＩＣＨとＰＣＨとの関係を示す図である。図６において、ＲＮＣ３と個別の通信を行うことができない状態の携帯端末１｛ｉｄｌｅ，Ｃｅｌｌ／ＵＲＡ［ＵＴＲＡＮ（ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）  Ｒｅｇｉｓｔｒａｔｉｏｎ  Ａｒｅａ］＿ＰＣＨ｝はＲＮＣ３から指示されたタイミングでＰＩＣＨの間欠受信を行っている。これは携帯端末１が着信を受けるために必要な動作である。
【００５１】
携帯端末１がＰＩＣＨを受信するタイミングは携帯端末１の識別子［ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）］等の値から計算される。ＰＩＣＨの１つのフレームは３００ビットで構成され、そのうちの後半１２ビットはリザーブとなっている。
【００５２】
さらに、各携帯端末１がＰＩＣＨ内のどのビットを監視するかも、携帯端末１の識別子（ＩＭＳＩ）等の値から計算される。携帯端末１が監視すべきＰＩＣＨ内のビットが"１"になっていた場合には、携帯端末１がＰＩＣＨと対になっているＰＣＨを受信する。
【００５３】
現状の３ＧＰＰの仕様は、呼出し通知チャネル（ＰＩＣＨ）の自端末を登録したビットを確認し、「１」であれば呼出しチャネル（ＰＣＨ）の情報を読出し、自端末の着信かどうか判断している。本実施例では、現状の３ＧＰＰの仕様と同様に、待ち受け中の携帯端末がネットワークからの指示にしたがって呼出し通知チャネルの間欠受信を行っている（図６及び図７参照）。
【００５４】
図７〜図９は本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。図７〜図９において、ＰＩＣＨのフレーム番号数（０〜４０９５）、ＰＩＣＨ内のビット数（２８８）の制限から、必ずしも、ＰＩＣＨ内の各ビットに１つのＵＥが割当てられるとは限らない。
【００５５】
仮に、ＰＩＣＨ内のあるビットに３つのＵＥが割当てられているとすると、そのビットを"１"にすることで３つのＵＥがＰＣＨの受信を行う。しかしながら、３つのＵＥが同時に着信を受けることは非常に稀であり、そのビットの"１"はどのＵＥを対象にしているかを示す方法が必要である。それを実現しているものがＰＣＨに含まれるＵＥ  Ｉｄｅｎｔｉｔｙである。ＰＣＨを受信したＵＥは必ずＵＥ  Ｉｄｅｎｔｉｔｙをチェックし、自端末宛の着信であるかどうかを確認する。
【００５６】
ここでは、１つのデータを転送し、それを複数のＵＥに同時に受信させることを想定しているので、データ転送の対象となる複数のＵＥ（特定の機種、ソフトウェアバージョン）に同時に着信を行う必要がある。各ＵＥは異なる識別子を有するので、全てのＵＥに着信を行うために、まず、ＰＩＣＨの全てのビットを"１"に設定する。しかしながら、現状のＰＣＨのＵＥ  Ｉｄｅｎｔｉｔｙでは、個々のＵＥのＵＥ  Ｉｄｅｎｔｉｔｙが設定されてしまうため、複数のＵＥに同時に着信を行うには不向きである。
【００５７】
そこで、ＵＥ  ＩｄｅｎｔｉｔｙにＩＭＥＩ−ＳＶを追加し、データの転送の対象となるＵＥの端末種別及びソフトウェアのバージョン情報をＵＥ識別子に用いる。これによって、対象となるＵＥをグループとして扱うことができる。ＩＭＥＩ−ＳＶには個々のＵＥを識別するためのシリアルナンバが含まれているが、ここでは特定のＵＥのグループに着信を行うことが目的であるので、シリアルナンバの情報は用いない。
【００５８】
また、上記のようにＰＩＣＨの全てのビットを"１"に設定することで、対象となるＵＥが一斉にページングに対する応答を行い、上りの無線容量の圧迫、ネットワーク側での処理負荷の増大が懸念されるため、必ずしもＰＩＣＨの全てのビットを"１"と設定することが最良ではない場合も考えられる。例えば、ソフトウェアのダウンロードが完了する時間を見計らって、数分おきに"１"と設定するＰＩＣＨのビットを１０ｂｉｔずつシフトするということもできる。
【００５９】
さらに、ＵＥ  ＩｄｅｎｔｉｔｙとしてＩＭＥＩ−ＳＶ以外のパラメータを設定することで、例えば、ミドルウェアやアプリケーションのアップデートに対しても上記の技術を適用することができる。
【００６０】
本実施例では、上述したように、特定の携帯端末のソフトウェア修正を行う場合、全ての携帯端末が着信動作を行えるように、ネットワークが呼出し通知チャネルの全てのビットに"１"を設定する。また、呼出しチャネルには対象となる携帯端末の機種及びソフトウェアのバージョンアップが必要な携帯端末の現在のソフトウェアバージョン情報を含ませる（図７〜図９参照）。
【００６１】
図１０は図３のサーバ６による処理手順を示すフローチャートである。これら図１〜図１０を参照して本発明の一実施例によるサーバ６による処理手順について説明する。
【００６２】
サーバ６はバージョンアップ等によるソフトウェアの変更が発生すると（図１０ステップＳ１）、予め設定されたブロードキャストの配信時刻（例えば、携帯端末１の使用が減る深夜等）になると（図１０ステップＳ２）、ソフトウェアの変更内容をブロードキャスト部６５からブロードキャストにて配信する（図１０ステップＳ３）。
【００６３】
サーバ６はブロードキャストの配信回数が予め設定した回数（＝Ｌ）になるまで（図１０ステップＳ４）、上記の処理を繰返し行う。また、サーバ６はブロードキャストの配信日数が予め設定した日数（＝Ｍ）（例えば、１週間や１か月等）になるまで（図１０ステップＳ５）、毎日、上記の処理を配信時刻となる毎に行う。
【００６４】
サーバ６はブロードキャストの配信日数が予め設定した日数（＝Ｍ）になり（図１０ステップＳ５）、予め設定したマルチキャストの配信時刻になると（図１０ステップＳ６）、マルチキャストによるＯＴＡＳＰ要求を送信する（図１０ステップＳ７）。
【００６５】
サーバ６はその要求に対して応答する端末が一つでもあれば（図１０ステップＳ８）、ソフトウェアの変更内容をマルチキャスト部６４からマルチキャストにて配信する（図１０ステップＳ９）。サーバ６はマルチキャストの配信日数が予め設定した日数（＝Ｋ）（例えば、１週間や１か月等）になるまで（図１０ステップＳ１０）、毎日、上記の処理を配信時刻となる毎に行う。
【００６６】
マルチキャストによるソフトウェアの配信が終了した後は、位置登録情報等の情報を利用して、個々の端末にソフトウェアのバージョンアップを促すことが可能である。
【００６７】
図１１は図３の携帯端末１による処理手順を示すフローチャートである。これら図１〜図９と図１１とを参照して本発明の一実施例による携帯端末１の処理手順について説明する。
【００６８】
携帯端末１は上述した従来と同様の処理でＰＣＨを受信する（図１１ステップＳ２１〜Ｓ２３）。携帯端末１は受信したＰＣＨを解析し、従来の着信、従来のＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）、ブロードキャストでのＯＴＡＳＰ、マルチキャストでのＯＴＡＳＰのいずれであるのかを認識する（図１１ステップＳ２４，Ｓ２５）。ここで、ＭＢＭＳの仕様は未決定であるので、ＰＣＨ以外のＣＨが用いられる可能性もある。「ＭＢＭＳ」については、３ＧＰＰ  ＴＳ２３．２４６  Ｖ０．３２．０１（２００２−０６）に記載されている。
【００６９】
携帯端末１はブロードキャストでのＯＴＡＳＰの場合（図１１ステップＳ２４）、ネットワーク側がＯＴＡＳＰの対象となる携帯端末の存在を認識することを要求されないので、ネットワーク側からの信号に対する応答を行わずに、ＯＴＡＳＰのデータを受信する準備を行う（図１１ステップＳ３０）。データを受信するための情報はＰＣＨに含まれている。
【００７０】
携帯端末１はマルチキャストでのＯＴＡＳＰの場合（図１１ステップＳ２５）、ネットワーク側がＯＴＡＳＰの対象となる携帯端末の存在を認識することが要求されるので、ページングの応答として、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔを送信し（図１１ステップＳ２７）、ＯＴＡＳＰのデータを受信する準備を行う（図１１ステップＳ２８）。
【００７１】
但し、携帯端末１はブロードキャストでのＯＴＡＳＰの場合、またはマルチキャストでのＯＴＡＳＰの場合、自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種（端末種別）及びソフトウェアのバージョンとを比較する（図１１ステップＳ２６，Ｓ２９）。
【００７２】
携帯端末１は上記の比較結果が異なっていれば、その時点で待ち受け状態に戻り、上記の比較結果が一致していれば、呼出しチャネルの情報を基に必要なデータをマルチキャスト、またはブロードキャストで受信する（図１１ステップＳ２８，Ｓ３０）。マルチキャストか、ブロードキャストかの判断は、上述したように、呼出し時にネットワーク側から違いがわかるように設定されている。
【００７３】
図１２は本発明の一実施例によるＯＴＡＳＰでのデータ送信手順（マルチキャストでＯＴＡＳＰを行う場合の手順）を示すシーケンスチャートである。これら図３及び図１２を参照して本発明の一実施例によるマルチキャストでＯＴＡＳＰを行う場合の手順について説明する。
【００７４】
サーバ６はソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、ＯＴＡＳＰ要求をＧＧＳＮ５に送信する（図１２のａ１）。このメッセージには、端末種別とソフトウェアのバージョン情報とが含まれ、さらに携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答をサーバ６に転送するためにサーバ６の識別子も含まれている。この場合にはデータの転送モードも指定され、この転送モードによってＲＮＣ３の動作が異なる。この例では転送モードにマルチキャストが設定されている。
【００７５】
ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ要求を受信すると、ＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）−ＣメッセージでＯＴＡＳＰ要求をＳＧＳＮ４に転送する（図１２のａ２）。
【００７６】
ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ要求を受信すると、ＲＡＮＡＰ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐａｒｔ）のＰａｇｉｎｇメッセージでＯＴＡＳＰ要求をＲＮＣ３に転送する（図１２のａ３）。
【００７７】
マルチキャスト転送はＲＮＣ３が対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）を意識したい時に用いられるので、ＲＮＣ３はＲＲＣのＰａｇｉｎｇメッセージを携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し（図１２のａ４）、対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答を期待する。この時のＰａｇｉｎｇには、上記の図６〜図９によって説明した方法が用いられる。
【００７８】
マルチキャストの場合には、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔが携帯端末（ＵＥ＃１，ＵＥ＃２）からＲＮＣ３に送信される（図１２のａ６）。本実施例では、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＲｅｑｕｅｓｔがＲＮＣ３に送信されるのは、上記のように、携帯端末（ＵＥ＃１，ＵＥ＃２）が自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合である（図１２のａ５）。
【００７９】
この後、携帯端末（ＵＥ＃１，ＵＥ＃２）はサーバ６に対してＪｏｉｎ（参加）を行うためのデフォルトのトンネルを確立し（図１２のａ７）、サーバ６に対してＯＴＡＳＰのデータを受信する意思があることを知らせるためにＪｏｉｎを行う（図１２のａ８）。これらの処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。
【００８０】
サーバ６は携帯端末（ＵＥ＃１，ＵＥ＃２）のうちの一つでもＪｏｉｎの応答があった場合、ＯＴＡＳＰのデータの送信を開始する（図１２のａ９）。ネットワークの各装置はＭＢＭＳの手順にしたがってデータを送信する。
【００８１】
サーバ６はＯＴＡＳＰのデータの送信が終わると、ＧＧＳＮ５にＯＴＡＳＰ終了通知でデータ送信の終了を通知する（図１２のａ１０）。この時、ＯＴＡＳＰ終了通知にはＯＴＡＳＰ要求に含まれていた機種及びソフトウェアのバージョン情報が含まれる。
【００８２】
ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ終了通知を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ終了通知をＳＧＳＮ４に転送する（図１２のａ１１）。ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ終了通知を受信すると、ＲＡＮＡＰメッセージでＯＴＡＳＰ終了通知をＲＮＣ３に転送する（図１２のａ１２）。
【００８３】
ＲＮＣ３はＳＧＳＮ４からのＯＴＡＳＰ終了通知を受信すると、ＲＲＣメッセージで、ＯＴＡＳＰ終了通知を対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し（図１２のａ１３）、データ送信が終了したことを通知する。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。
【００８４】
携帯端末（ＵＥ＃１，ＵＥ＃２）は上記のＯＴＡＳＰのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図１２のａ１４）。
【００８５】
図１３は本発明の一実施例によるＯＴＡＳＰでのデータ送信手順（ブロードキャストでＯＴＡＳＰを行う場合の手順）を示すシーケンスチャートである。これら図３及び図１３を参照して本発明の一実施例によるブロードキャストでＯＴＡＳＰを行う場合の手順について説明する。
【００８６】
サーバ６はソフトウェアのバージョンアップが必要な携帯端末（ＵＥ＃１，ＵＥ＃２）がある時に、ＯＴＡＳＰ要求をＧＧＳＮ５に送信する（図１３のａ２１）。このメッセージには端末種別及びソフトウェアのバージョン情報が含まれ、さらに、データの転送モードも指定され、この転送モードによってＮＣ３の動作が異なる。この場合には、サーバ６が携帯端末（ＵＥ＃１，ＵＥ＃２）からの信号を受信する必要がないので、サーバ６への信号転送のための情報は含まない。
【００８７】
ＧＧＳＮ５はサーバ６からのＯＴＡＳＰ要求を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ要求をＳＧＳＮ４に転送する（図１３のａ２２）。ＳＧＳＮ４はＧＧＳＮ５からのＯＴＡＳＰ要求を受信すると、ＲＡＮＡＰのＰａｇｉｎｇメッセージでＯＴＡＳＰ要求をＲＮＣ３に転送する（図１３のａ２３）。
【００８８】
ブロードキャスト転送はネットワークが対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）を意識しなくても良い時に用いられるので、ＲＮＣ３は対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）からの応答を期待する通常のページングではなく、ブロードキャストを示すページングを行う（図１３のａ２４）。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。また、これらの処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。
【００８９】
携帯端末（ＵＥ＃１，ＵＥ＃２）は、上記のように、自端末の機種及びソフトウェアのバージョンと、呼出しチャネルに含まれている機種及びソフトウェアのバージョンとを比較して両者が一致した場合（図１３のａ２５）、ＯＴＡＳＰのデータを受信する準備を行う（図１３のａ２６）。この処理は３ＧＰＰ標準のＭＢＭＳの手順に合わせる。
【００９０】
この後、サーバ６はＯＴＡＳＰのデータの送信を行う（図１３のａ２７）。ネットワークの各装置は、３ＧＰＰ標準のＭＢＭＳの手順にしたがってデータを送信する。
【００９１】
サーバ６はＯＴＡＳＰのデータの送信が終わると、ＯＴＡＳＰ終了通知でＧＧＳＮ５にデータ送信の終了を通知する（図１３のａ２８）。この時、ＯＴＡＳＰ終了通知には上記のＯＴＡＳＰ要求に含まれていた端末種別及びソフトウェアのバージョン情報が含まれている。
【００９２】
ＧＧＳＮ５はサーバ６からＯＴＡＳＰ終了通知を受信すると、ＧＴＰ−ＣメッセージでＯＴＡＳＰ終了通知をＳＧＳＮ４に転送する（図１３のａ２９）。ＳＧＳＮ４はＧＧＳＮ５からＯＴＡＳＰ終了通知を受信すると、ＲＡＮＡＰメッセージでＯＴＡＳＰ終了通知をＲＮＣ３に転送する（図１３のａ３０）。
【００９３】
ＲＮＣ３はＳＧＳＮ４からＯＴＡＳＰ終了通知を受信すると、ＲＲＣメッセージで、ＯＴＡＳＰ終了通知を対象となる携帯端末（ＵＥ＃１，ＵＥ＃２）に送信し、データ送信が終了したことを通知する（図１３のａ３１）。この時のメッセージにも、上記の図６〜図９によって説明した方法が用いられる。
【００９４】
携帯端末（ＵＥ＃１，ＵＥ＃２）は上記のＯＴＡＳＰのデータの受信が正常に行われ、ソフトウェアのアップデートが完了すると、自端末内のソフトウェアのバージョン情報を更新する（図１３のａ３２）。
【００９５】
図１４は図３のサーバ６側での処理手順（マルチキャストでＯＴＡＳＰを行う場合の手順）を示すフローチャートである。これら図３及び図１４を参照してサーバ６側でマルチキャストにてＯＴＡＳＰを行う場合の手順について説明する。
【００９６】
マルチキャストでは対象の携帯端末１が存在しない時にデータの送信を行わないので、サーバ６はＯＴＡＳＰ要求を行うと同時に（図１４ステップＳ４１）、携帯端末１からの応答を待ち受けるタイマ（図示せず）を起動する。
【００９７】
サーバ６はタイマが満了するまでに携帯端末１からの応答がなければ（図１４ステップＳ４２，Ｓ４３）、ＯＴＡＳＰを終了する（図１４ステップＳ４５）。このタイマは対象の携帯端末１が存在するかを確認するだけではなく、対象となる携帯端末群からの応答を収集するという目的も含まれている。
【００９８】
一方、サーバ６はタイマが満了するまでに携帯端末１からの応答があれば（図１４ステップＳ４２，Ｓ４３）、ＯＴＡＳＰデータの送信を開始する（図１４ステップＳ４４）。
【００９９】
サーバ６はマルチキャストを行う場合、上記のように、一つでも携帯端末１からの応答があればＯＴＡＳＰデータの転送を開始するが、一つも応答がなければデータ転送を行わず、ＯＴＡＳＰを終了する機能を有する。
【０１００】
尚、上記のマルチキャストによる端末ページングは、上述したようなソフトウェアのバージョンアップだけでなく、使用するソフトウェアのバージョンを使用している端末数の統計データの取得やその端末への特定ソフトウェアの提供等にも使用することが可能であり、これらに限定されるものではない。
【０１０１】
図１５は図３の携帯端末１でのデータの処理手順を示すフローチャートである。これら図３及び図１５を参照して携帯端末１におけるデータの処理手順について説明する。
【０１０２】
携帯端末１はＯＴＡＳＰ終了のメッセージが到達しない場合を考慮して、ＯＴＡＳＰ終了メッセージ待ちタイマをＯＴＡＳＰのデータの受信を開始したら起動する（図１５ステップＳ５１，Ｓ５２）。
【０１０３】
携帯端末１はＲＲＣメッセージにてＯＴＡＳＰ終了が通知され（図１５ステップＳ５３）、ソフトウェアのアップデートに成功すると（図１５ステップＳ５４）、自端末のソフトウェアのバージョンを更新する（図１５ステップＳ５５）。
【０１０４】
これはＯＴＡＳＰ終了通知に含まれる機種及びソフトウェアバージョンが、ＯＴＡＳＰ要求に含まれていた機種及びソフトウェアバージョンを用いるため、ＯＴＡＳＰ終了通知を受信する前にソフトウェアバージョンを書換えてしまうと、終了通知を受信することができなくなってしまうからである。
【０１０５】
携帯端末１はソフトウェアのアップデートが成功する前に、ＯＴＡＳＰ終了タイマが満了したり（図１５ステップＳ５２）、ＯＴＡＳＰ終了が通知されると（図１５ステップＳ５３，Ｓ５４）、そこまで受信したＯＴＡＳＰデータを破棄し（図１５ステップＳ５６）、アップデートの手順を終了して機種及びソフトウェアのバージョン情報として以前のものを用いる。ソフトウェアのアップデートが失敗する場合としては、携帯端末１でのデータの受信が完了する前に、ＯＴＡＳＰ終了が通知されることも考えられる。
【０１０６】
上記のように、携帯端末１はソフトウェアのアップデートが成功すると、自端末のソフトウェアのバージョン情報を更新する。また、携帯端末１はソフトウェアのアップデートが失敗すると、受信したデータを破棄し、ソフトウェアのバージョンを更新しない。
【０１０７】
これらの動作によって、ソフトウェアの更新が成功した携帯端末１は再度同じデータを受信することはないが、更新が失敗した携帯端末１は成功するまでソフトウェアのバージョンを更新しないので、再度同じデータを受信することが可能となる。
【０１０８】
このように、本実施例では、ソフトウェアのバージョンアップ等におけるプログラムの書換えを行うためのＯＴＡＳＰにＭＢＭＳを利用することで、携帯端末１において無駄な電力消費を行わせることなく、対象となる携帯端末群のソフトウェアを、ソフトウェアの書換えを必要とする場合のみ効率的に更新することができる。
【０１０９】
また、本実施例では、携帯端末に特有の情報（例えば、ＩＭＥＩ−ＳＶに含まれている機種及びソフトウェアのバージョン情報）を利用することで、携帯端末１のグループ化を効果的に行うことができる。
【０１１０】
さらに、本実施例では、ソフトウェアの更新が完了した携帯端末１が自端末のソフトウェアのバージョンを更新することで、同じデータの重複受信を避けることができる。
【図面の簡単な説明】
【０１１１】
【図１】本発明の一実施例による移動通信システムの動作例を示す図である。
【図２】（ａ）〜（ｃ）は本発明の一実施例による移動通信システムの動作例を示す図である。
【図３】本発明の一実施例による移動通信システムの構成を示すブロック図である。
【図４】図３のサーバの構成を示すブロック図である。
【図５】図３の携帯端末の構成を示すブロック図である。
【図６】本発明におけるＰＩＣＨの構成及びＰＩＣＨとＰＣＨとの関係を示す図である。
【図７】本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
【図８】本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
【図９】本発明におけるＰＣＨ内のＵＥ識別子の変更イメージを示す図である。
【図１０】図３のサーバによる処理手順を示すフローチャートである。
【図１１】図３の携帯端末による処理手順を示すフローチャートである。
【図１２】本発明の一実施例によるＯＴＡＳＰでのデータ送信手順を示すシーケンスチャートである。
【図１３】本発明の一実施例によるＯＴＡＳＰでのデータ送信手順を示すシーケンスチャートである。
【図１４】図３のサーバ側での処理手順を示すフローチャートである。
【図１５】図３の携帯端末でのデータの処理手順を示すフローチャートである。
【符号の説明】
【０１１２】
１，１−１〜１−５    携帯端末
２，２−１，２−２    ＮｏｄｅＢ
３    ＲＮＣ
４    ＳＧＳＮ
５    ＧＧＳＮ
６    サーバ
１１    アンテナ
１２    無線通信部
１３    制御部
１４    ＣＰＵ
１５    メモリ
１６    転送方式判定部
１７    データ転送制御部
１８    ベースバンド部
１９    音声入出力部
２０    表示部
２１    キー操作部
６１    データ入出力部
６２    データ蓄積部
６３    データ送信制御部
６４    マルチキャスト部
６５    ブロードキャスト部
１００    ＩＰネットワーク
【国際調査報告】
2004107797.tif 000018
2004107797.tif 000019
2004107797.tif 000020