JPWO2009081502A1

JPWO2009081502A1 - 通信端末

Info

Publication number: JPWO2009081502A1
Application number: JP2009546916A
Authority: JP
Inventors: 信洋鴛海; 英和槇野; 伊藤　雄二; 雄二伊藤; 友一勝呂
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2007-12-26
Filing date: 2007-12-26
Publication date: 2011-05-06
Anticipated expiration: 2027-12-26
Also published as: US20100262960A1; US8392907B2; WO2009081502A1; JP5006941B2

Abstract

本発明は、ソフトウェア更新の放置を回避するために、所定の提供元からソフトウェアを通信ネットワークを介して入手して更新する更新部と、上記更新部によるソフトウェアの更新を妨げる障害の有無を監視する障害監視部と、上記更新部による更新に際して上記障害が存在していて未完の更新となった場合にその未完の更新の存在を記録する更新記録部と、上記障害監視部による監視結果が障害有から障害無へと変化した場合に、上記更新記録部によって存在が記録されている更新の上記更新部による実行を促す更新促進部とを備えた。

Description

本発明は、通信端末に関する。

従来より、移動体端末と称される通信端末が知られており、例えばモバイルパソコンや携帯電話などがこの移動体端末の例である。このような移動体端末にはソフトウェア（ＯＳ、アプリケーションプログラム）が組み込まれており、移動体端末に様々な機能を発揮させるために動作している。

また、情報処理装置の分野では、装置に組み込んだソフトウェアを適宜に更新して使用する形態が一般化しており、移動体端末のソフトウェアについても、不具合修正、設定変更、機能追加、保持情報の改訂などといった目的で製品出荷後に行うソフトウェア更新の需要が高まっている。

このようなソフトウェア更新を行うため従来提案されている種々の技術を以下に記す。
（１）端末からの問合せに対して、ソフトウェアの重要度、ソフトウェアの更新時間、機種、バージョン情報をサーバが応答する技術（例えば特許文献１参照）。
（２）端末から送信されるファイルごとの操作履歴情報に基づいてサーバが優先度を決定し、優先度の高いファイルをダウンロードする技術（例えば特許文献２参照）。
（３）端末から送信される世代情報を含む要求データを受信したサーバが優先度を含む応答データを返信する技術（例えば特許文献３参照）。
（４）タスク起動前に、競合制御部に開始可否の問合せを行うことで複数タスク間の競合を判断し、タスクの開始可否を判断する技術（例えば特許文献４参照）。
（５）イベント通知によるアプリケーション起動における、複数タスク間の競合を制御する技術（例えば特許文献５および特許文献６参照）。
（６）ダウンロードに通信時間がかかり過ぎるような大きなプログラムの場合に、装置の使用状況が空いてる時間帯、あるいは通信料金の安価な時間帯を選んでダウンロードする技術（例えば特許文献７参照）。
（７）各端末に端末ソフトウェアの更新日付時刻を記憶させ、ホストコンピユ−タにログイン時にホストコンピユ−タがその情報をもとに判断し、必要に応じて端末に新しいソフトウェアを自動転送することにより、端末ソフトウェアを自動更新可能にする技術（例えば特許文献８参照）。
特開２００６−３４０１９６特開２０００−２２２２９６特開２００５−１９６２６９特開２００３−１７７９２６特開２００５−２８４９０４特開２００６−１５５２２５特開２００３−０７８６３７特開平０３−２４４０３０

上述した（１）〜（７）の技術を含めて、移動体端末におけるソフトウェア更新の技術は、ユーザ手動による更新方式、サーバ通知による即時更新方式、サーバ通知による時刻指定更新方式等といったいくつかの方式に分類される。このうち、サーバ通知による時刻指定更新方式は、多くの移動体端末によって実行されるソフトウェア更新のタイミングをサーバ側で調整することができるので、サーバの負荷分散という観点で他の方式よりも有利である。しかし、以下のようなケースでは、サーバが指定した時刻におけるソフトウェア更新を実施できない。
〔ケース１〕ネットワーク状態が異常の場合
サーバが指定した時刻において、端末の存在している場所が、サーバと通信するための通信ネットワークにとって圏外状態となっている場合や、その通信ネットワークが通信の規制を行っている場合には、ネットワーク通信が行えない為、更新ファイルをサーバからダウンロードすることができない。
〔ケース２〕端末状態が異常の場合
サーバが指定した時刻において、電池残容量が少なく、更新ファイルをサーバからダウンロード中に、あるいはソフトウェア更新処理中に電池切れを起こした場合はソフトウェア更新が正常に終了できない。

また、更新されるソフトウェアとしては、ＯＳ系ソフトウェアやアプリケーション系ソフトウェアという具合に、各々別系統のサーバによって更新されるソフトウェアが存在する。このような場合、各系統での更新時刻が競合する時は、ＯＳ系ソフトウェアの更新をアプリケーション系ソフトウェアよりも優先させる必要がある。この結果、以下のようなケースにおいても、サーバの指定時刻通りのソフトウェア更新を自動で実施することができない。
〔ケース３〕ＯＳ系ソフトウェアを更新する処理の最中にアプリケーション系ソフトウェアの更新開始時刻になった場合
先発のＯＳ系ソフトウェアを更新するための処理が優先的に実行され、後発のアプリケーション系ソフトウェアの更新処理が破棄される。
〔ケース４〕アプリケーション系ソフトウェアの更新中にＯＳ系ソフトウェアの更新開始時刻になった場合
後発のＯＳ系ソフトウェアの更新処理が優先的に実行され、先発のアプリケーション系ソフトウェアの更新処理が途中で破棄され、正常に終了できない。

上記のようなケース１〜ケース４においては、サーバが指定した時刻におけるソフトウェアの自動更新ができない為、その失敗したソフトウェア更新の再開をユーザの手動操作に委ねざるを得ず、更新が可能になった時点で手動操作によるソフトウェア更新が行われることとなるが、以下の課題が存在する。
〔課題１〕ユーザ手動操作によるソフトウェア更新が、多数同時刻に一斉に実施された場合にはサーバに負荷が集中してしまう。
〔課題２〕ユーザが手動更新を忘れてしまう可能性があるため、重要なソフトウェア更新であっても確実なアップデートが保障できない。

これらの課題のうち、課題２は特に重要であるが、上述した（１）〜（７）のいずれの技術でも、ソフトウェア更新に一度失敗してしまうと、その後の更新については保障できない。

このような課題は、移動体端末に限らない通信端末一般で生じる課題である。

本発明は、上記事情に鑑み、ソフトウェア更新の確実性が高い通信端末を提供することを目的とする。

上記目的を達成する本発明の通信端末は、
所定の提供元からソフトウェアを通信ネットワークを介して入手して更新する更新部と、
上記更新部によるソフトウェアの更新を妨げる障害の有無を監視する障害監視部と、
上記更新部による更新に際して上記障害が存在していて未完の更新となった場合にその未完の更新の存在を記録する更新記録部と、
上記障害監視部による監視結果が障害有から障害無へと変化した場合に、上記更新記録部によって存在が記録されている更新の上記更新部による実行を促す更新促進部とを備えたことを特徴とする。

本発明の通信端末によれば、障害によってソフトウェア更新が失敗した場合であっても、障害が無くなったときにその更新が促されるため、ソフトウェアの確実な更新が期待できる。また、本発明では、単に更新処理を繰り返すのでは無く、障害を監視し、障害が無くなったときに更新を促すので、無駄な処理や無駄な通信の発生を防ぎ、より確実で効率の良い更新を実現することができる。

ここで、更新記録部によって存在が記録される更新は、上述したサーバ通知による時刻指定更新方式による更新には限られず、ユーザの手動操作による更新方式による更新であってもよい。

また、更新促進部による更新の促進は、更新部に対して直接に実行を促してもよいが、上記提供元が、上記更新部に対して更新時刻を割り当てるものであり、上記更新部が、上記提供元から割り当てられた更新時刻になったら更新を開始するものである場合には、上記更新促進部は、上記提供元に更新時刻の再割り当てを要求するものであることが好適である。

このような更新促進部を備えることにより、上記提供元（一般的にはサーバ）に対する付加の集中を回避して、上述した課題１も解決することができる。

また、上記障害監視部は、
この通信端末の内部及び又は外部の状態を監視する状態監視部と、
上記状態監視部による監視結果が登録される、登録されている監視結果が変更された場合に通知を発する登録部と、
上記登録部に登録されている監視結果に基づいて上記障害の有無を判定する、上記通知が発せられた場合には、上記更新記録部によって存在が記録されている更新に対する障害の有無を判定する障害判定部とを備えたものであることが好適である。

このような障害監視部は、ソフトウェア更新の障害が解消したことを、上記通知を利用して確実かつ効率よく確認することができるため、このような障害監視部を備えた通信端末ではソフトウェアが確実かつ効率よく更新されることとなる。

また、障害監視部によって監視される障害としては、物理的障害、処理制御上の障害、通信端末の内部要因、外部要因などというように様々な障害が考えられるが、
上記障害監視部が、上記障害として、上記更新部と上記提供元との間での通信不良を監視するものであることや、
上記障害監視部が、上記障害として、上記更新部による更新よりも優先度の高い処理の存在を監視するものであることや、
上記障害監視部が、上記障害として、更新処理を妨げるこの通信端末の内部的物理的状況を監視するものであることが好ましい。

これらの障害を監視する障害監視部を備えることで、例えば電波通信環境などの悪化による更新の失敗が生じた場合や、ＯＳ系ソフトウェアの更新に妨げられてアプリケーション系ソフトウェアの更新に失敗した場合や、電池切れなどによって更新に失敗した場合にも再度の更新を促すことができる。

以上説明したように、本発明の通信端末によれば、ソフトウェア更新の確実性が高い。

本発明の一実施形態が組み込まれるソフトウェア更新システムを概念的に示す図である。図１に示す携帯電話の内部機能を示す機能ブロック図である。状態管理ＤＢにおける登録の例を表す図である。第１の状況における処理フロー図である。第２の状況における処理フロー図である。第３の状況における処理フロー図である。第４の状況における処理フロー図である。

以下図面を参照して本発明の実施の形態を説明する。

図１は、本発明の一実施形態が組み込まれるソフトウェア更新システムを概念的に示す図である。

この図１には、本発明の通信端末の一実施形態として携帯電話１００が示されており、この携帯電話１００は、内部で種々の処理を実行するために、ＯＳ系ソフトウェアやアプリケーション系ソフトウェアの更新を必要とする。また、この携帯電話１００は、上述した更新方式のうち、サーバ通知による時刻指定更新方式が適用されたソフトウェア更新システム１に組み込まれている。この図１に示すソフトウェア更新システム１では、ソフトウェアの更新版を提供し、ソフトウェア更新を管理する１つのサーバ２００に対し、ソフトウェア更新を必要とする携帯電話１００が多数所属している。この図１に示すサーバ２００は、概念的に示されているものであって、ＯＳ系ソフトウェアを担うサーバであるかアプリケーション系ソフトウェアを担うサーバであるかは区別しないが、実際には各系統のサーバが存在している。

サーバ２００は携帯電話１００を、例えば「Ａ」「Ｂ」「Ｃ」といった複数のグループ１０Ａ，１０Ｂ，１０Ｃに分類し、各グループ１０Ａ，１０Ｂ，１０Ｃに対して個別の更新開始時刻を割り当てて、その更新開始時刻を書き込んだ更新通知を、各グループ１０Ａ，１０Ｂ，１０Ｃに属する各携帯電話１００に送る。各携帯電話１００は、サーバ２００から通知された時刻になったらソフトウェア更新を開始し、その結果、例えば「Ａ」というグループ１０Ａに属する携帯電話１００どうしは互いに同じ時刻にソフトウェア更新を実行するが、「Ｂ」というグループ１０Ｂに属する携帯電話１００とは異なる時刻にソフトウェア更新を実行することとなる。この結果、サーバ２００に対する負荷が分散されて効率の良い更新が実現する。

図２は、図１に示す携帯電話１００の内部機能を示す機能ブロック図である。

この図２には、携帯電話１００の機能ブロックが示されていると共に、この携帯電話１００に対してソフトウェアの更新版を提供する２つのサーバ２００＿１，２００＿２も示されている。これらのサーバ２００＿１，２００＿２は、本発明にいう提供元の例であると共に、図１に示すサーバ２００の具体例であって、サーバ通知による時刻指定更新方式でのソフトウェア更新に対応したサーバである。これらのサーバ２００＿１，２００＿２のうちの１つのサーバ（ＯＳソフトウェア更新管理サーバ）２００＿１は、ＯＳソフトウェアの更新を管理するものであり、もう１つのサーバ（ＯＥＭアプリソフトウェア更新管理サーバ）２００＿２は、携帯電話１００に販売時に組み込み済みのＯＥＭアプリケーションソフトウェアの更新を管理するものである。

携帯電話１００の内部機能としては、当然ながら電話機としての機能が存在し、更には電子メールの機能、インターネット端末としての機能、ゲーム機能、音楽再生機能なども存在するが、この図２の機能ブロック図ではそれらの機能の区別は特に行わず、ＯＳソフトウェアとＯＥＭアプリケーションソフトウェアによって包括的に担われるものとして図示している。また、各機能を発揮するためのハードウェアについては、従来の携帯電話に備えられているハードウェアと同じハードウェアが備えられているものとする。この図２に示す携帯電話１００の各機能については、後述する、本発明で新たに導入された機能も含めて、従来のハードウェア上でそのまま実行可能な機能であるため、ハードウェアについてのこれ以上の説明は省略する。

ここで、携帯電話１００の各機能ブロックの概略について説明する。携帯電話１００は、ＯＳソフトウェア更新部１０１、アプリソフトウェア更新部１０２、状態管理ＤＢ（データベース）１０３、競合制御部１０４、ＮＷ（ネットワーク）状態管理部１０５、端末状態管理部１０６、再ネゴシエーション部１０７、および無線通信制御部１０８を備えている。

ＯＳソフトウェア更新部１０１は、携帯電話１００のＯＳソフトウェアを更新する部位であると共に、その更新されたＯＳソフトウェアを実行して機能を発揮させる部位でもある。

アプリソフトウェア更新部１０２は、携帯電話１００のＯＥＭアプリケーションソフトウェアを更新する部位であると共に、その更新されたＯＥＭアプリケーションソフトウェアを実行して機能を発揮させる部位でもある。

これらＯＳソフトウェア更新部１０１およびアプリソフトウェア更新部１０２は、いずれも本発明にいう更新部の一例に相当するが、後述するように、ＯＳソフトウェア更新部１０１とアプリソフトウェア更新部１０２とではソフトウェア更新の競合が異なっている。

状態管理ＤＢ１０３は、携帯電話１００内外の各種状態を管理するためのデータベースであり、本発明にいう障害監視部内の登録部の一例に相当する。この状態管理ＤＢ１０３で管理される状態には、携帯電話１００の内部状態のみならず、この携帯電話１００が置かれている通信環境の状態なども含まれている。

競合制御部１０４は、状態管理ＤＢ１０３に現在の状態を問い合わせることにより、ソフトウェア更新に対する競合を判断する部位であり、本発明にいう障害監視部内の障害判定部の一例としての役割を担い、本発明にいう更新記録部の一例としての役割も有する。但し、ここで言う「競合」とは、ソフトウェア更新を妨げるような全ての要因を含んだ広い意味であり、狭い意味での「競合」、即ち更新処理との同時処理が不可能な他の処理が携帯電話１００内外で発生したことを当然に含む他、例えば、単に通信状態が不良となってソフトウェア更新のためのダウンロードが実行できないことや、携帯電話１００内のハードウェアの状態不良によってソフトウェア更新が実行できないことなども含んでいる。

ＮＷ状態管理部１０５は、携帯電話１００が接続する通信ネットワークにおける通信状態を、無線通信制御部１０８を介して監視する部位である。

端末状態管理部１０６は、携帯電話１００内部の状態を監視する部位である。

これらＮＷ状態管理部１０５および端末状態管理部１０６のそれぞれが、本発明にいう障害監視部内の状態監視部の各例に相当する。

再ネゴシエーション部１０７は、サーバ２００＿１，２００＿２に対してソフトウェア更新通知の再発行を要求する部位であり、この再ネゴシエーション部１０７は、本発明にいう更新促進部の一例に相当する。

無線通信制御部１０８は、携帯電話１００による無線通信の制御を行う部位である。

次に、これらの機能ブロックや携帯電話１００における情報などの流れについて説明する。

まず、上述したように、ＯＳソフトウェア更新管理サーバ２００＿１やＯＥＭアプリソフトウェア更新管理サーバ２００＿２は、携帯電話１００に対してソフトウェア更新の開始時刻を割り当て、その開始時刻を表した更新開始時刻データを含んだ更新通知を携帯電話１００に送信する。携帯電話１００側では、ＯＳソフトウェア更新部１０１およびアプリソフトウェア更新部１０２のそれぞれが、無線通信制御部１０８を介して、対応するサーバからの更新通知を受信して、その更新通知に含まれている更新開始時刻データが表している時刻を状態管理ＤＢ１０３に登録させる。

また、ＮＷ状態管理部１０５と端末状態管理部１０６は、各々、通信ネットワークの通信状態および携帯電話１００内部の状態を常時監視しており、ＮＷ状態管理部１０５は、例えばこの携帯電話１００が通信ネットワークの圏外に存在する場合や、通信ネットワークから通信の規制が掛かっている場合などのように、通信ネットワークとの通信が行えない状態を検出した時には、その状態を状態管理ＤＢ１０３に登録させる。端末状態管理部１０６は、例えば携帯電話１００の電池残容量が不足している場合や、携帯電話１００内部の各種処理のために用意されているメモリの残容量が不足している場合などのように、携帯電話１００内部にダウンロードを妨げる状態を検出した場合には、その状態を状態管理ＤＢ１０３に登録する。

ここで、状態管理ＤＢ１０３における登録の例について説明する。

図３は、状態管理ＤＢ１０３における登録の例を表す図である。

この図３には、状態管理ＤＢに用意されている管理テーブル３００が示されており、この管理テーブル３００には、更新開始時刻が登録される更新時刻部３１０と、各種状態が登録される状態部３２０が設けられている。

この図３に示す例では、更新時刻部３１０には、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２から割り当てられた開始時刻３１１と、ＯＳソフトウェア更新管理サーバ２００＿１から割り当てられた開始時刻３１２が登録され、これらの開始時刻３１１，３１２を表すフォーマットは、「年」／「月」／「日」「時」：「分」となっている。また、この図３に示す例では、状態部３２０には「ＯＳ更新実施中」「圏外」「規制」「電池残容量」という４つの状態種別それぞれについての現在の状態３２１，３２２，３２３，３２４が、「Ｙｅｓ」と「Ｎｏ」の２択、あるいは「ＯＫ」と「ＮＧ」の２択で登録される。なお、この図３の状態部３２０に示す状態の例は、以下の説明に必要なものを簡潔に示したものであり、実際にはもっと他の種類の状態も登録されることとなる。

図４に戻って説明を続ける。

サーバ２００＿１，２００＿２から割り当てられた開始時刻が状態管理ＤＢ１０３に登録された後、その開始時刻になったら、ＯＳソフトウェア更新部１０１やアプリソフトウェア更新部１０２は、競合制御部１０４に、ソフトウェア更新の実行可否を問い合わせ、問い合せを受けた競合制御部１０４は、状態管理ＤＢ１０３に問い合わせて登録されている各種状態と更新開始時刻とを確認する。そしてその各種状態と更新開始時刻とに基づいて競合制御部１０４が、ソフトウェアの更新を実行して良い状態にあるか否かを判定してＯＳソフトウェア更新部１０１やアプリソフトウェア更新部１０２に判定結果を応答する。

競合制御部１０４による判定結果が実行可を示している場合にはＯＳソフトウェア更新部１０１やアプリソフトウェア更新部１０２は無線通信制御部１０８を介してＯＳソフトウェア更新管理サーバ２００＿１やＯＥＭアプリソフトウェア更新管理サーバ２００＿２からソフトウェアの更新版をダウンロードしてソフトウェアを更新する。ソフトウェアを更新したＯＳソフトウェア更新部１０１やアプリソフトウェア更新部１０２は状態管理ＤＢ１０３に対して更新開始時刻の削除を依頼し、状態管理ＤＢ１０３はその更新開始時刻を削除する。

一方、競合制御部１０４による判定結果が実行不可を示している場合にはＯＳソフトウェア更新部１０１やアプリソフトウェア更新部１０２はソフトウェア更新を延期し、状態管理ＤＢ１０３に対して更新開始時刻の削除を依頼するとともに競合制御部１０４に対して再ネゴシエーション予約を発行する。この再ネゴシエーション予約は、未完のソフトウェア更新が存在することを表したフラグであり、競合制御部１０４によって、図示を省略したメモリに記録される。

その後状態管理ＤＢ１０３は、登録されている状態などに変化が生じると競合制御部１０４に状態変化を通知し、競合制御部１０４は、再ネゴシエーション予約のフラグが立っている場合に状態変化が通知されると、変化後の状態に基づいて、ソフトウェア更新の実行可否を改めて判定する。そして、競合制御部１０４が競合の解消を確認して実行可と判定した場合には、競合制御部１０４から再ネゴシエーション部１０７に対してソフトウェア更新再ネゴシエーション要求が発行される。このソフトウェア更新再ネゴシエーション要求を受領した再ネゴシエーション部１０７は、無線通信制御部１０８を通じて、その更新するべきソフトウェアに対応したサーバ２００＿１，２００＿２に対して、上述した更新通知の再発行を要求する。

更新通知の再発行を要求されたサーバ２００＿１，２００＿２は、携帯電話１００に対する開始時刻の割り当てをやり直し、その新たな開始時刻を表した更新開始時刻データを含んだ新たな更新通知を携帯電話１００に送信する。この結果、上述した手順が繰り返されてソフトウェア更新が実行される。このソフトウェア更新は、最初のソフトウェア更新とは異なり、競合制御部１０４で競合の解消が確認された後のソフトウェア更新であるため確実な実行が期待される。

以下、種々の具体的な状況下を想定し、本実施形態の携帯電話１００によるソフトウェア更新はどの様な状況下でも確実に実行されることを確認する。
［第１の状況］
まず第１の状況として、携帯電話１００とＯＥＭアプリソフトウェア更新管理サーバ２００＿２との間を媒介する通信ネットワークの状態異常がソフトウェア更新を妨げる状況を想定する。

図４は、第１の状況における処理フロー図である。

まず、ステップＳ１０１では、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２によって上述したようにソフトウェア更新の開始時刻が割り当てられ、その開始時刻を含んだ更新通知が無線通信制御部１０８を介してアプリソフトウェア更新部１０２へと送られる。そして、アプリソフトウェア更新部１０２は、その割り当てられた開始時刻を確認して状態管理ＤＢ１０３に知らせ、状態管理ＤＢ１０３では図３に示す更新時刻部３１０にその開始時刻が登録される。この時点では通信ネットワークの状態は正常であるが、その後ステップＳ１０２でＮＷ状態管理部１０５によって通信ネットワークの状態異常（ここでは一例として「圏外」）が検出されると、ＮＷ状態管理部１０５から状態管理ＤＢ１０３に、図３に示す「圏外」状態３２２として「Ｙｅｓ」を保存することが要求され、状態管理ＤＢ１０３は「圏外」状態に「Ｙｅｓ」を保存する。

次に、ソフトウェア更新の開始時刻になると、ステップＳ１０３で、アプリソフトウェア更新部１０２が競合制御部１０４に更新処理の実行可否を問い合わせ、競合制御部１０４は、状態管理ＤＢ１０３に対し、図３の管理テーブル３００にその時点で登録されている各データを要求し、状態管理ＤＢ１０３は登録されている各データを応答する。そして、競合制御部１０４では、その応答されたデータ中の状態が［ＯＳ更新実施中：圏外：規制：電池残容量］＝［Ｎｏ：Ｎｏ：Ｎｏ：ＯＫ］となっているか否かで更新処理の実行可否を判定してアプリソフトウェア更新部１０２に判定結果を応答する。ここでは、「圏外」状態が「Ｙｅｓ」であることに基づいて実行不可と判定されることとなる。なお、状態管理ＤＢ１０３から応答されたデータ中の更新開始時刻の使い方については後述する。

実行可否について判定結果の応答を受けたアプリソフトウェア更新部１０２は、ステップＳ１０４で、判定結果が「ＯＫ」であればＯＥＭアプリソフトウェア更新管理サーバ２００＿２から更新ファイルをダウンロードして更新処理を実行する。また、判定結果が「ＮＧ」である場合には、実行するべきソフトウェア更新が残っていることを表す再ネゴシエーション予約というフラグがアプリソフトウェア更新部１０２から競合制御部１０４に送られてメモリに記憶される。

その後、ステップＳ１０５でＮＷ状態管理部１０５により、「圏外」状態が解消して「圏内」状態になったことが検出されると、ＮＷ状態管理部１０５から状態管理ＤＢ１０３に、図３に示す「圏外」状態３２２として「Ｎｏ」を保存することが要求され、状態管理ＤＢ１０３は「圏外」状態に「Ｎｏ」を保存する。そしてステップＳ１０６で状態管理ＤＢ１０３は、登録されている状態の変化を検出して競合制御部１０４にＮｏｔｉｆｉｃａｔｉｏｎ通知を送る。このＮｏｔｉｆｉｃａｔｉｏｎ通知は、状態管理ＤＢ１０３に登録されている状態に変化が生じたことを通知するものである。

Ｎｏｔｉｆｉｃａｔｉｏｎ通知を受け取った競合制御部１０４は、ステップＳ１０７で、再ネゴシエーション予約の有無を確認し、再ネゴシエーション予約が存在していたら、状態管理ＤＢ１０３に対し、図３の管理テーブル３００にその時点で登録されている各データを要求し、状態管理ＤＢ１０３は登録されている各データを応答する。競合制御部１０４は、応答された各データ中の状態を確認して、上述したように、更新処理の実行可否を判定する。そして、判定結果が「ＯＫ」であれば再ネゴシエーション部１０７に再ネゴシエーションの開始を指示し、再ネゴシエーション部１０７は、ソフトウェア更新再通知要求を作成する。このソフトウェア更新再通知要求は、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２に従来から備えられている機能のうち、ソフトウェアの初期設定などのために用意されている機能を利用するための要求であり、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２に対して更新開始時間の割り当てと通知を求めるものである。再ネゴシエーション部１０７で作成されたソフトウェア更新再通知要求は無線通信制御部１０８を介してＯＥＭアプリソフトウェア更新管理サーバ２００＿２に送られる。なお、このステップＳ１０７では、再ネゴシエーション予約が存在しなかった場合、および更新処理の実行可否について判定結果が「ＮＧ」であった場合には、状態管理ＤＢ１０３からのＮｏｔｉｆｉｃａｔｉｏｎ通知を待機する状態となる。

ＯＥＭアプリソフトウェア更新管理サーバ２００＿２がソフトウェア更新再通知要求を受け取ると、上述したステップＳ１０１からの処理が繰り返されるが、今度は、ステップＳ１０２の圏外検出は生じない可能性が高く、割り当てられた更新時刻になってステップＳ１０３、ステップＳ１０４の処理が実行されると更新ファイルのダウンロードと更新処理が正常に行われてソフトウェア更新が完了することが期待される。
［第２の状況］
次に第２の状況として、携帯電話１００の内部状態が不良となってソフトウェア更新を妨げる状況を想定する。

図５は、第２の状況における処理フロー図である。

まず、ステップＳ２０１では、図４のステップＳ１０１と全く同様に、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２による更新開始時刻の割り当てと通知、アプリソフトウェア更新部１０２による開始時刻の確認、および状態管理ＤＢ１０３による開始時刻の登録が行われる。この時点では携帯電話１００の内部状態は正常であるが、その後ステップＳ２０２で端末状態管理部１０６によって携帯電話１００の内部状態の異常（ここでは一例として「電池残容量」の低下）が検出されると、端末状態管理部１０６から状態管理ＤＢ１０３に、図３に示す「電池残容量」状態３２４として「ＮＧ」を保存することが要求され、状態管理ＤＢ１０３は「電池残容量」状態に「ＮＧ」を保存する。

次に、ソフトウェア更新の開始時刻になると、ステップＳ２０３では、図４のステップＳ１０３と全く同様に、競合制御部１０４による実行可否の判定や応答が行われ、ステップＳ２０４では、図４のステップＳ１０４と全く同様に、アプリソフトウェア更新部１０２による更新実行や再ネゴシエーション予約の発行が行われる。但し、この第２の状況では、「電池残容量」状態が「ＮＧ」であることに基づいて、実行不可の判定と再ネゴシエーション予約の発行が行われることとなる。

その後、ステップＳ２０５で端末状態管理部１０６により、「電池残容量」の回復が検出されると、端末状態管理部１０６から状態管理ＤＢ１０３に、図３に示す「電池残容量」状態３２４として「ＯＫ」を保存することが要求され、状態管理ＤＢ１０３は「電池残容量」状態に「ＯＫ」を保存する。そしてステップＳ２０６で状態管理ＤＢ１０３は、登録されている状態の変化を検出して競合制御部１０４にＮｏｔｉｆｉｃａｔｉｏｎ通知を送る。

ステップＳ２０７では、図４のステップＳ１０７と全く同様に、競合制御部１０４による再ネゴシエーション予約の有無の確認、競合制御部１０４による更新実行の可否判定、再ネゴシエーション部１０７によるソフトウェア更新再通知要求の作成・送付が行われ、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２がソフトウェア更新再通知要求を受け取ると、上述したステップＳ２０１からの処理が繰り返される。

今度は、ステップＳ２０２の電池残容量の低下検出は生じない可能性が高く、割り当てられた更新時刻になってステップＳ２０３、ステップＳ２０４の処理が実行されると更新ファイルのダウンロードと更新処理が正常に行われてソフトウェア更新が完了することが期待される。

なお、上記ステップＳ２０２の説明では電池残容量不足の判定手法については特に言及していないが、電池残容量パーセントに閾値を設けて判定する手法などに代表される従来手法が任意に採用可能である。また、上記ステップＳ２０５における電池残容量回復の判定手法についても、同じく閾値を設けた判定手法や１００％充電されたことを契機とした判定手法などに代表される従来手法が任意に採用可能である。
［第３の状況］
次に第３の状況として、ＯＳ系ソフトウェアの更新処理中にＯＥＭアプリケーション系ソフトウェアの更新開始時刻になった状況を想定する。

図６は、第３の状況における処理フロー図である。

まず、ステップＳ３０１では、ＯＳソフトウェア更新管理サーバ２００＿１およびＯＥＭアプリソフトウェア更新管理サーバ２００＿２のそれぞれによってソフトウェア更新の開始時刻が携帯電話１００に割り当てられ、その開始時刻を含んだ更新通知が無線通信制御部１０８を介してＯＳソフトウェア更新部１０１およびアプリソフトウェア更新部１０２それぞれへと送られる。そして、ＯＳソフトウェア更新部１０１およびアプリソフトウェア更新部１０２は、その割り当てられた開始時刻を確認して状態管理ＤＢ１０３に知らせ、状態管理ＤＢ１０３では図３に示す更新時刻部３１０にそれらの開始時刻が登録される。

その後、ＯＳ系ソフトウェアの更新の開始時刻になると、ステップＳ３０２でＯＳソフトウェア更新部１０１から状態管理ＤＢ１０３に、図３に示す「ＯＳ更新実施中」状態３２１として「Ｙｅｓ」を保存することが要求され、状態管理ＤＢ１０３は「ＯＳ更新実施中」状態に「Ｙｅｓ」を保存する。そしてステップＳ３０３でＯＳソフトウェア更新部１０１は、ＯＳソフトウェア更新管理サーバ２００＿１から更新ファイルをダウンロードして更新処理を実行する。なお、本来は、更新処理に先立って競合制御部１０４による実行可否の判定が行われるが、ここでは説明の煩雑を避けるため省略している。

次に、ＯＥＭアプリケーション系ソフトウェアの更新開始時刻になると、ステップＳ３０４では、図４のステップＳ１０３と全く同様に、競合制御部１０４による実行可否の判定や応答が行われ、ステップＳ３０５では、図４のステップＳ１０４と全く同様に、アプリソフトウェア更新部１０２による更新実行や再ネゴシエーション予約の発行が行われる。但し、この第３の状況では、「ＯＳ更新実施中」状態が「Ｙｅｓ」であることに基づいて、実行不可の判定と再ネゴシエーション予約の発行が行われることとなる。

その後、ＯＳソフトウェア更新部１０１における更新処理が終わるとステップＳ３０６で、ＯＳソフトウェア更新部１０１から状態管理ＤＢ１０３に、「ＯＳ更新実施中」状態として「Ｎｏ」を保存することが要求され、状態管理ＤＢ１０３は「ＯＳ更新実施中」状態に「Ｎｏ」を保存する。そしてステップＳ３０７で状態管理ＤＢ１０３は、登録されている状態の変化を検出して競合制御部１０４にＮｏｔｉｆｉｃａｔｉｏｎ通知を送る。

ステップＳ３０８では、図４のステップＳ１０７と全く同様に、競合制御部１０４による再ネゴシエーション予約の有無の確認、競合制御部１０４による更新実行の可否判定、再ネゴシエーション部１０７によるソフトウェア更新再通知要求の作成・送付が行われ、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２がソフトウェア更新再通知要求を受け取ると、上述したステップＳ３０１からの処理のうち、ＯＥＭアプリケーション系ソフトウェアに関わる処理が繰り返される。この結果、今度は、ＯＳ系ソフトウェアの更新処理は行われず、割り当てられたＯＥＭアプリケーション系ソフトウェアの更新時刻になってステップＳ３０４、ステップＳ３０５の処理が実行されると更新ファイルのダウンロードと更新処理が正常に行われて、ＯＥＭアプリケーション系ソフトウェアの更新が完了することとなる。
［第４の状況］
次に第４の状況として、ＯＥＭアプリケーション系ソフトウェアの更新処理中にＯＳ系ソフトウェアの更新開始時刻が来てしまう状況を想定する。

図７は、第４の状況における処理フロー図である。

まず、ステップＳ４０１では、図６のステップＳ３０１と全く同様に、各サーバ２００＿１，２００＿２による更新開始時刻の割り当てと通知、ＯＳソフトウェア更新部１０１およびアプリソフトウェア更新部１０２による開始時刻の確認、および状態管理ＤＢ１０３による開始時刻の登録が行われる。

その後、ＯＥＭアプリケーション系ソフトウェアの更新開始時刻になると、ステップＳ４０２では、図４のステップＳ１０３と全く同様に、競合制御部１０４による実行可否の判定や応答が行われるが、この第４の状況では、上記で説明を省略した更新開始時刻を使った判定が行われるので以下説明する。競合制御部１０４は、状態管理ＤＢ１０３から応答された各データのうち図３の更新時刻部３１０に登録されていた開始時刻３１１，３１２を確認する。そして、それらの開始時刻３１１，３１２の差分が所定の閾値以内となっている場合には、ＯＥＭアプリケーション系ソフトウェアの更新処理中にＯＳ系ソフトウェアの更新開始時刻が来てしまう可能性が高いので、ＯＥＭアプリケーション系ソフトウェアの更新処理について実行不可の判定を行いアプリソフトウェア更新部１０２に判定結果を応答する。

競合制御部１０４による判定結果の応答を受けたアプリソフトウェア更新部１０２は、図４のステップＳ１０４と全く同様に、更新実行や再ネゴシエーション予約の発行を行うが、ここでは、更新開始時刻の差分が所定の閾値以内となっていることに伴って再ネゴシエーション予約の発行が行われることとなる。

その後、ＯＳ系ソフトウェアの更新の開始時刻になると、ステップＳ４０４では、図６のステップＳ３０２、ステップＳ３０３、およびステップＳ３０６と同様に、「ＯＳ更新実施中」状態としての「Ｙｅｓ」の保存、ＯＳ系ソフトウェアの更新ファイルのダウンロード、更新処理、および「ＯＳ更新実施中」状態としての「Ｎｏ」の保存が順次に実行される。なお、状態管理ＤＢ１０３では、「ＯＳ更新実施中」状態としての「Ｎｏ」の保存とともにＯＳ系ソフトウェアの更新開始時刻の削除も行われる。そしてステップＳ４０５で状態管理ＤＢ１０３は、登録されている状態の変化を検出して競合制御部１０４にＮｏｔｉｆｉｃａｔｉｏｎ通知を送る。

ステップＳ４０６では、図４のステップＳ１０７と全く同様に、競合制御部１０４による再ネゴシエーション予約の有無の確認、競合制御部１０４による更新実行の可否判定、再ネゴシエーション部１０７によるソフトウェア更新再通知要求の作成・送付が行われ、ＯＥＭアプリソフトウェア更新管理サーバ２００＿２がソフトウェア更新再通知要求を受け取ると、上述したステップＳ４０１からの処理のうち、ＯＥＭアプリケーション系ソフトウェアに関わる処理が繰り返される。今度は、ＯＳ系ソフトウェアの更新の開始時刻は状態管理ＤＢ１０３から削除されているので、ＯＥＭアプリケーション系ソフトウェアの更新時刻になってステップＳ４０２、ステップＳ４０３の処理が実行されると更新ファイルのダウンロードと更新処理が正常に行われて、ＯＥＭアプリケーション系ソフトウェアの更新が完了することとなる。

以上説明したように、本実施形態の携帯電話１００によれば、想定されるいずれの状況下でもソフトウェア更新の確実性が高く、無駄な更新の試行による無駄な処理や通信の発生も回避されているので効率も良い。

なお、上記の実施形態では、好ましい形態として、状態管理ＤＢ１０３からＮｏｔｉｆｉｃａｔｉｏｎ通知が発行される例を説明したが、本発明では、競合制御部１０４が定期的に状態管理ＤＢ１０３の登録データを確認する形態もあり得る。

また、上記の実施形態では、好ましい形態として、再ネゴシエーション部１０７によるソフトウェア更新再通知要求に従ってＯＥＭアプリソフトウェア更新管理サーバ２００＿２で開始時刻の再度の割り当てが行われる例を説明したが、本発明では、競合制御部１０４によって競合の解消が確認された場合に、アプリソフトウェア更新部１０２によって直ちに更新ファイルのダウンロードや更新処理が行われる形態もあり得る。

Claims

所定の提供元からソフトウェアを通信ネットワークを介して入手して更新する更新部と、
前記更新部によるソフトウェアの更新を妨げる障害の有無を監視する障害監視部と、
前記更新部による更新に際して前記障害が存在していて未完の更新となった場合にその未完の更新の存在を記録する更新記録部と、
前記障害監視部による監視結果が障害有から障害無へと変化した場合に、前記更新記録部によって存在が記録されている更新の前記更新部による実行を促す更新促進部とを備えたことを特徴とする通信端末。
前記提供元が、前記更新部に対して更新時刻を割り当てるものであり、
前記更新部が、前記提供元から割り当てられた更新時刻になったら更新を開始するものであり、
前記更新促進部が、前記提供元に更新時刻の再割り当てを要求するものであることを特徴とする請求項１記載の通信端末。
障害監視部が、
この通信端末の内部及び又は外部の状態を監視する状態監視部と、
前記状態監視部による監視結果が登録される、登録されている監視結果が変更された場合に通知を発する登録部と、
前記登録部に登録されている監視結果に基づいて前記障害の有無を判定する、前記通知が発せられた場合には、前記更新記録部によって存在が記録されている更新に対する障害の有無を判定する障害判定部とを備えたものであることを特徴とする請求項１または２記載の通信端末。
前記障害監視部が、前記障害として、前記更新部と前記提供元との間での通信不良を監視するものであることを特徴とする請求項１から３のうちいずれか１項記載の通信端末。
前記障害監視部が、前記障害として、更新処理を妨げるこの通信端末の内部的物理的状況を監視するものであることを特徴とする請求項１から４のうちいずれか１項記載の通信端末。
前記障害監視部が、前記障害として、前記更新部による更新よりも優先度の高い処理の存在を監視するものであることを特徴とする請求項１から５のうちいずれか１項記載の通信端末。