JP2007164604A - 携帯電話のソフトウエア更新結果の表示方法およびソフトウエア更新結果を表示可能な携帯電話 - Google Patents

Abstract

【課題】携帯電話のソフトウェアの予約更新において、更新の成功／不成功に関する詳しい情報を利用者に提示できるようにする。
【解決手段】ダウンロードおよびインストールの過程で表示されるガイダンスから更新処理が行えなかった原因を示しているガイダンスを選定し携帯電話内の待避バッファに保存する（１１３）。後刻利用者の要求に基づいて、待避バッファのデータからガイダンスを作成し表示する（１２２）。
【選択図】図１２

Description

本発明は携帯電話のソフトウエアの更新に関するものである。

携帯電話により提供される機能は、従来の音声通話に加え、メールの送受信、インターネットへの接続、コンテンツの購入等多種多様の機能が提供されている。この結果として、携帯電話を制御し各種の機能を提供するソフトウエア（ファームウエア）は大きく且つ複雑となり、プロクラムの修正あるいは新らたな機能の追加を行う必要が増している。この要求に対応するため、通信ネットワークにソフトウエアの更新サーバを設け、ネットワークを利用して携帯電話に更新用のソフトウエアを配信することが行われている。

ソフトウエアの更新は、利用者が携帯電話から更新サーバに更新すべきソフトウエアが存在するか否かを確認することにより開始される。更新すべきソフトウエアが存在した場合、利用者は直ちにソフトウエアの更新を行うか、あるいは後刻日時を定めて更新を行う予約更新とするかを選択する。予約更新を選択した場合、利用者は更新を行う日時を更新サーバに登録し、更新サーバとの通信を終了する。
予約日時になると、更新サーバは予約した携帯電話との通信を開始する。携帯電話では、更新サーバからの通信要求により受信準備を整え、更新サーバとのセッションを確立する。その後、更新サーバから携帯電話へ更新ソフトウエアをダウンロードし、携帯電話では受信した更新ソフトウエアにより自己のソフトウエアを更新する。
ネットワーク機器およびプログラム自動更新に関する文献には以下のものがある。
特開２００４−６２５５５号公報

ソフトウエアの更新期間中は携帯電話を利用することができない。しかし、予約更新の機能を利用し、ソフトウエアの更新日時を任意の日時に設定することにより、携帯電話が利用不可能となることによる不利益を避けることができる。従って、予約更新の更新日時は就寝時間等、携帯電話を使用する可能性が低い時間に設定される。ソフトウエアの予約更新は、利用者の介入無しで全て自動的に行う構成となっている。
予約更新の処理は、予約日時に更新サーバから携帯電話にソフトウエアの更新を開始する通知を出すことにより開始される。更新開始の通知を受信した携帯電話は、サーバとの接続を採り、所定の手順に従って更新プログラムのダウンロードとインストールを行い、その結果を更新サーバに報告して全ての処理を終了する。
更新処理の過程で、携帯電話のバッテリ残量は充分か、あるいは海外ローミング中ではないか等、幾つかの条件を検査し、それら条件が全て満足された時に更新プログラムのダウンロードとインストールを行う。また、いずれかの条件が満足されない時、あるいは、プログラムのダウンロード等の更新作業中に何らかの障害が発生した時、更新サーバは更新処理を中止し、携帯電話との接続を切断する。

予約更新を行った携帯電話は、その結果を「更新成功」あるいは「更新失敗」と表示して利用者に知らせる。しかし、上述したように更新処理が失敗する原因は複数存在する。従って、「更新失敗」と結果のみを提示する構成では、利用者が再度更新を行う場合、失敗の原因を取り除くことが困難であり、同じ失敗を繰り返す可能性がある。
本発明は、携帯電話のソフトウエアの更新を開始する日時を予約し、予約時間となると利用者の介入無しで全て自動的に更新処理を行う予約更新において、更新の成功／不成功に関する詳しい情報を利用者に提示する装置および方法を提供するものである。また本発明は、提示する情報をソフトウエアの更新過程でサーバから送信された情報、あるいは携帯電話内で選択された情報を利用することにより、複雑な構成を必要としない装置および方法を提供するものである。

携帯電話の予約更新では、予約日時となるとサーバが携帯電話に予約更新の開始を通知することにより開始される。その後は、更新の成功／失敗にかかわらず更新処理が終了するまで自動的に進行する。予約更新は、利用者の介入無しに行われるため、更新結果を利用者に告知する機能を有している。しかし、更新が失敗した場合、失敗の原因を取り除きソフトウエアの更新を再度実行する必要があり、利用者に失敗の原因を特定するための詳細な情報が提示されることが望ましい。
予約更新の実行過程で各種のガイダンスが表示され、課程の情報が提供される。また、予約更新の実行が不可能と判断された時、その理由等がガイダンスとして表示され、利用者に提示される。ソフトウエアの更新が失敗した原因を知らせる方法として、上記のガイダンスが表示された状態で更新処理を中断し、ガイダンス表示を維持する方法が考えられる。しかし、処理をガイダンス表示のステップで止めると、携帯電話の処理機能がソフトウエアの更新処理に占有された状態のままとなり、着信等、他の処理を行うことができなくなる可能性がある。

本発明は、着信等、他の処理に影響を与えることなく、且つ簡単な構成により、予約更新の結果と不成功となった原因に関する詳細な情報を利用者に提示する構成を提供するものである。具体的には、予約更新の過程で表示される、失敗の原因等、重要な情報を提示するガイダンスのデータを保存し、後刻利用者の要求により、保存されたデータに基づいて、ガイダンスを再表示するものである。

本発明は、利用者の介入無しに自動的に実行されるソフトウエアの予約更新において、更新の処理過程で表示される重要な情報を提示するガイダンスのデータを保持し、後刻、利用者の要求により前記データからガイダンスを再表示する構成により、着信等他の処理に影響を与えることなく、利用者に実行された予約更新に関する詳細な情報を提示することが可能となる。

図１は、携帯電話のソフトウエア（ファームウエア）を更新するシステムの概要図である。更新サーバはデバイスマネイジメントサーバ（DMサーバ１１）とダウンロードサーバ（DLサーバ１２）からなる。DMサーバ（１１）は携帯電話（１０）からの更新要求により、携帯電話（１０）内の更新機能（DMクライアント）と接続を採り、両者間で制御および更新プログラム等の授受を行う。また、更新の予約がなされている場合は、予約日時に携帯電話（１０）に更新の開始を通知することにより、携帯電話（１０）のDMクライアントを起動させ、両者間で制御および更新プログラム等の授受を行う。
DMサーバ（１１）には、携帯電話システムで利用される電話機の機種毎に利用可能なソフトウエアの情報を記憶する機種テーブルが設けられている。図１（ｂ）は機種テーブルの例であり、携帯電話の機種１が利用可能な最新プログラムはソフトウエアＡのバージョン2.5であり、機種２はソフトウエアＢのバージョン1.8である等の情報が記録されている。
DLサーバ（１２）は更新ソフトウエアを保持しており、DMサーバ（１１）の指示により、要求されたソフトウエアをDMサーバ（１１）を介して、あるいは直接、携帯電話（１０）にダウンロードする。特定の機種のソフトウエアが更新されると機種テーブルの対応箇所が修正されると供にDLサーバ（１２）に記憶される。

DMサーバ（１１）と携帯電話（１０）の間の接続形式には、図２（ａ）に示される、OMA-DM（Open Mobile Alliance Device Management）により行う形式と、図２（ｂ）に示される、OMA-DLにより行う形式がある。
OMA-DMによる場合の開始通知は、ＤＭサーバ（１１）、プッシュ プロキシ サーバ（１４）、ショート メッセージ サービス センタ（１３）、携帯電話（１０)の経路でなされ、ソフトウエアダウンロードは、ＤＭサーバ（１１）、ＷＡＰプロキシ（１７）、ＧＰＲＳ ゲートウェイ ノード（１６）、:ＧＰＲＳ サービス ノード（１５）、携帯電話（１０）の経路でなされる。
OMA-DLによる場合の開始通知は、ＤＭサーバ（１１）、プッシュ プロキシ サーバ（１４）、ショート メッセージ サービス センタ（１３）、携帯電話（１０)の経路でなされ、ソフトウエアダウンロードは、ＤＬサーバ（１２）、ＷＡＰプロキシ（１７）、ＧＰＲＳ ゲートウェイ ノード（１６）、:ＧＰＲＳ サービス ノード（１５）、携帯電話（１０）の経路でなされる。

図２（ａ）に示される形式の概要は以下の通りである。
（１）ソフトウエアの更新は、利用者が携帯電話のメニュー画面からソフトウエアの更新を選択し、ＤMサーバに更新要求を出すことにより開始される場合と、利用者が予約した更新日時となり、DMサーバが携帯電話に更新開始の通知を出すことにより開始される場合がある。
（２）携帯電話は自己の機種とインストールされているソフトウエアの情報をDMサーバに送信する。DMサーバは、図１（ｂ）に例示される機種テーブルを参照して、当該機種に対する適切な更新ソフトウエアを決定する。この段階で利用者に暗証番号の入力を要求し利用者の正当性を検証する。
（３）決定された更新ソフトウエアをDLサーバから取得して携帯電話に送信する。
（４）ソフトウエアのダウンロードが終了すると、DMサーバはソフトウエアのインストールの実行を指示する。この指示により、携帯電話はダウンロードした更新ソフトウエアのインストールを行い、自己のソフトウエアを更新する。
（５）ソフトウエアの更新が完了すると、携帯電話はDMサーバへ結果を通知する。

図２（ｂ）に示される形式の概要は以下の通りである。
（１）ソフトウエアの更新は、利用者が携帯電話のメニュー画面からソフトウエアの更新を選択し、ＤMサーバに更新要求を出すことにより開始される場合と、利用者が予約した更新日時となり、DMサーバが携帯電話に更新開始の通知を出すことにより開始される場合がある。
（２）携帯電話は自己の機種とインストールされているソフトウエアの情報をDMサーバに送信する。DMサーバは、図１（ｂ）に例示される機種テーブルを参照して、当該機種に対する適切な更新ソフトウエアを決定する。この段階で利用者に暗証番号の入力を要求し利用者の正当性を検証する。
（３）DMサーバは、前記決定された更新ソフトウエアの情報と更新ソフトウエアを記憶するDLサーバのアドレス情報を携帯電話に送信する。
（４）DMサーバは携帯電話に更新ソフトウエアのダウンロードを指示する。
（５）携帯電話はDMサーバから送信されたDLサーバのアドレスに基づいてDLサーバに更新ソフトウエアに関するダウンロード情報を要求する。
（６）DLサーバは携帯電話にダウンロード情報を送信する。
（７）携帯電話は送信されたダウンロード情報に基づいて、DLサーバに更新ソフトウエアのダウンロードを要求する。
（８）携帯電話はDLサーバから更新ソフトウエアをダウンロードする。
（９）携帯電話はDLサーバにダウンロードの結果情報を送信する。
（１０）携帯電話はダウンロードされた更新ソフトウエアをインストールし、その結果をDMサーバに報告する。

図３−１および図３−２は、利用者が携帯電話のメニュー画面からソフトウエアの更新を選択することにより、更新サーバから更新ソフトウエアをダウンロードして携帯電話のソフトウエア（ファームウエア）を更新する処理を示すものである。図３−１は、制御データの授受およびプロクラムのダウンロードの両者をDMサーバとDMクライアント間でOMA-DMを用いて行う、図２（ａ）に示される形式の処理を示している。また、図３−２は、制御データの授受をDMサーバとDMクライアント間でOMA-DMを用いて行い、プロクラムのダウンロードをDLサーバとDLクライアント間でOMA-DLを用いて行う、図２（ｂ）に示される形式の処理を示している。
図４−１ないし図４−５は図３−１および図３−２に示される処理において、携帯電話に表示される表示画面に基づいて処理のフローの詳細を示すものである。以下、図４−１ないし図４−５を参照しつつ、図３−１の処理を説明する。

図３−１（１）：図４−１の画面[A-N-01]は携帯電話のメニュー画面の一例である。利用者がカーソルを「ソフトウエア更新」に移動させ「選択」キーを操作することにより、ソフトウエアの更新処理が開始される。
更新処理が開始されるとバッテリの残量が検査される。ソフトウエアの更新中、特にソフトウエアの書き換え中にバッテリ切れとなり、書き換えが正常に終了しなかった場合、起動不能等、携帯電話に致命的な障害が発生する。従って、ソフトウエア更新の処理を開始する前に、バッテリの残量を検査する。バッテリの残量が少なく、ソフトウエアの更新作業を完了し得ない可能性があると判断されると画面[A-N-03]に進み、警告画面を提示した後、図４−５画面[D-N-01]の待ち受け状態になる。
バッテリの残量が充分と判断されると、画面[A-N-02]によりソフトウエア更新時の注意が与えられる。利用者が「いいえ」を選択してソフトウエアの更新を中止すると、画面[A-N-04]を介して図４−５画面[D-N-01]の待ち受け状態になる。利用者が「はい」を選択すると、携帯電話の制御プログラムはソフトウエアの更新処理を担当するDMクライアントを起動し、制御を移行する。
DMサーバは携帯電話がローミング中か否かを検査する。ローミング中はソフトウエアの更新を行うことができないため、画面[A-D-04]を提示して更新処理を終了する。

図３−１（２）：携帯電話がローミング中でない場合、DMサーバは携帯電話のDMクライアントとの間でソフトウエアの更新処理を開始する。DMサーバは利用者に規約を提示し応答を求めるガイダンスを表示することを指示するコマンドを送信する。
図３−１（３）：DMクライアントは上記コマンドに従って画面[A-D-01]を表示し、利用者の応答をDMサーバに送信する。利用者が契約を承諾しなかった場合（「いいえ」を選択）、画面[A-D-09]を表示する。
図３−１（４）：利用者が契約を承諾した場合（「はい」を選択）、画面[A-D-02]を表示して暗証番号を要求する。利用者が「中止」を選択した時、画面[A-D-10]を表示する。
図３−１（５）：利用者が暗証番号（PIN）を入力し「決定」のキー操作を行うと、入力された暗証番号はDMサーバに送信され、携帯電話に対応して記憶されている暗証番号と比較される。暗証番号に誤りがあると、画面[A-D-07]または[A-D-08]、[A-D-12]を表示する。

図３−１（６）：暗証番号が正当と判断されると、DMサーバは携帯電話の機種とソフトウエアのバージョン等の情報をDMクライアントに要求する。
図３−１（７）：DMクライアントは携帯電話の機種と現在のソフトウエアのバージョンに関する情報等をDMサーバに送信する。DMサーバは、図１（ｂ）に例示される機種テーブルを参照し、当該携帯電話に利用可能な更新ソフトウエアが存在するか否かを検出する。携帯電話が使用しているソフトウエアが最新のものであり、利用可能な更新ソフトウエアが存在しない場合、図４−３画面[A-D-05]を表示し更新処理を終了する。
また、DMサーバは、当該電話機にソフトウエアの更新の予約がなされているか否かを検査する。既に予約がなされている場合、利用者に画面[A-D-06]を表示し、ソフトウエアの更新処理を続けるか否かの回答を求める。利用者がソフトウエアの更新処理を続けないとした場合は、画面[A-D-11]を表示する。

図３−１（８）：機種テーブルを検索することにより、当該電話機に更新すべきソフトウエアが存在すると判断されると、DMサーバは携帯電話に画面[A-D-03]を表示し、利用者にソフトウエアの更新方法の指定を求める。ここに示される例の選択肢は「１．今すぐ更新」「２．予約更新」「３．予約キャンセル」の三つである。
「１．今すぐ更新」はソフトウエアの更新を続けて行うものであり、「２．予約更新」は利用者がソフトウエアの更新を行う日時を指定し予約するものである。予約された日時となると、DMサーバは予約した携帯電話に接続し、ソフトウエアの更新を行う。図５および図６に予約更新のフローが示されている。「３．予約キャンセル」は予約更新により設定された予約日時を変更するものである。図７および図８に予約キャンセルのフローが示されている。画面[A-D-03]で中止を選択すると、画面[A-D-13]を表示する。

図３−１（９）：画面[A-D-03]で「１．今すぐ更新」を選択すると、ソフトウエアの更新処理が開始される。更新サーバは更新サーバあるいは通信システムの使用状況を検査する。これらが輻輳状態にあり、直ちに更新処理を開始することは不可能と判断されると画面[C-D-01]を表示する。更新処理は可能と判断すると、DMサーバは更新ソフトウエアのダウンロードを開始する。
以下は、図２（ａ）に示される、DMサーバからDMクライアントに更新ソフトウエアをダウンロードする処理の例である。
図３−１（１０）：DMサーバは、携帯電話の機種と使用中のプロクラムのバージョン情報に基づいて機種テーブルから選定した更新ソフトウエアをDLサーバから取得し、DMクライアントにダウンロードする。その際、携帯電話では図４−４画面[C-N-01]が表示される。
図３−１（１１）：ダウンロードが終了すると、DMクライアントはDMサーバにダウンロードの結果を報告する。

図３−１（１２）：ダウンロードが正常に終了すると、DＭサーバはDMクライアントにダウンロードしたソフトウエアのインストールを指示する。DMクライアントは画面[C-N-02]および[C-N-03]を表示し、利用者にソフトウエアの書き換え中で在ることを知らせる。ソフトウエアの書き換えが終了すると画面[C-N-04]を表示し、携帯電話を再起動する。
図３−１（１３）：再起動した携帯電話は画面[C-N-05]を表示すると共に、更新ソフトウエアが正常に機能しているか否かを検査し、検査結果をDMサーバに報告する。

図３−２（１０'）：DMサーバはDMクライアントにDLサーバのアドレスと更新ソフトウエアに関する情報を送信する。
図３−２（１１'）：DMクライアントはDMサーバに（１０'）の応答を返信する。
図３−２（１２'）：DMサーバはDMクライアントに更新ソフトウエアのダウンロードと、ダウンロードされた更新ソフトウエアのインストールを指示する。
図３−２（１３'）：DMクライアントはDMサーバに（１２'）の応答を返す。
図３−２（１４'）：DLクライアントは、（１０'）でDMサーバから送信されたDLサーバのアドレスに基づいてDLサーバに更新ソフトウエアをダウンロードするための情報を要求する。
図３−２（１５'）：DLサーバはDLクライアントに（１４'）の情報を返す。
図３−２（１６'）：DLクライアントは（１５'）で返信された情報に基づいてDLサーバに更新ソフトウエアのダウンロードを要求する。
図３−２（１７'）：DLサーバはDLクライアントに更新ソフトウエアをダウンロードする。
図３−２（１８'）：更新ソフトウエアのダウンロードが終了すると、ダウンロードした結果を報告する。
図３−２（１９'）：DLサーバは（１８'）の応答を返す。また、携帯電話はソフトウエアをインストールする。
図３−２（２０'）：DMクライアントはDMサーバに更新処理の終了を報告する。

図４−３の画面[A-D-03]が表示された時、利用者が「２．予約更新」を選択すると、図５および図６に示される予約処理が開始される。DMサーバには各携帯電話対応に更新予約の登録がなされているか否か、および登録がなされている場合には登録日時を記憶する予約テーブルが設けられている。予約処理を行うことにより、予約テーブルの予約処理を行った携帯電話に対応する欄に、予約更新が登録されていることを示す情報と登録日時が記憶される。以下図６を参照しつつ、図５の処理を説明する。

図５（１）：携帯電話から予約更新の指示を受けたDMサーバは、携帯電話に図６画面[B-D-01]を表示し、利用者が希望する予約日時、即ちソフトウエア更新を希望する日時を求める。日時の指定は利用者が数字キーを用いて直接入力する方法、あるいはDMサーバが幾つかの候補日時を提示し、利用者が選択する方法等がある。画面[B-D-01]はDMサーバが候補日時を提示する形式のものである。
図５（２）：利用者が選択した予約希望日時をDMサーバに送信する。DMサーバは指定された日時にソフトウエアの更新処理が可能か否かを判別する。何らかの理由によりソフトウエアの更新処理が行えない時は、画面[B-D-04]を表示し、他の日時の選択、あるいは予約処理の終了を求める。
図５（３）：利用者が指定した日時に更新処理が可能な時は、画面[B-D-02]の予約時の注意を提示し利用者の確認を求める。
図５（４）：利用者が確認することにより、DMサーバは指定された日時を当該携帯電話のソフトウエア更新の予約日時として予約テーブルに登録する。
図５（５）：サーバは携帯電話に画面[B-D-03]を表示し予約の登録が完了したことを通知し、処理を終了する。

図４−３の画面[A-D-03]が表示された時、利用者が「３．予約キャンセル」を選択すると、図７および図８に示される予約キャンセルの処理が開始される。
図７（１）：携帯電話から予約キャンセルの指示を受けたDMサーバは、携帯電話に対応して登録されている更新予約日時を予約テーブルから読み出す。予約テーブルに更新予約日時が登録されていない場合は図８画面[B-D-08]を表示する。登録されている更新予約日時から画面[B-D-06]を作成し携帯電話に送信する。
図７（２）：利用者は画面[B-D-06]を確認し、予約キャンセルの確認をDＭサーバに送信する。
図７（３）：確認を受信したDMサーバは登録されている更新予約日時を消去し、画面[B-D-07]を表示して予約のキャンセルが終了したことを通知し処理を終了する。

DＭサーバには各携帯電話対応に更新予約の登録がなされているか否か、および登録がなされている場合には登録日時を記憶する予約テーブルが設けられている。DMサーバはこの予約テーブルを監視することにより、登録日時となった携帯電話に対して予約更新を実行する。図９および図１０に予約更新の処理が示されている。以下図１０を参照しつつ、図９に示される処理を説明する。

図９（１）：予約テーブルに登録されている更新予約時間となったことが検出されると、DMサーバはショートメッセージ・サービスセンタ（SMSC）を介して当該携帯電話にソフトウエア更新の開始を通知する。これにより、携帯電話ではDMクライアントが起動される。DMクライアントは携帯電話のバッテリ残量を検査し、更新ソフトウエアのダウンロードおよびインストールを行うに充分な残量か否かを判別する。バッテリ残量が充分ではないと判断されると図１０画面[C-D-03]を表示して更新処理を終了する。バッテリの残量が充分と判断されると画面[C-D-02]を表示しソフトウエアの更新を続行する。
図９（２）：DMクライアントは画面[C-D-02]を表示し、更新処理の実行を利用者に通知する。利用者が「いいえ」を選択すると更新処理は中止される。利用者が「はい」を選択した、あるいは所定時間内に応答しなかった場合、DMサーバに更新処理の続行を要求する。
図９（３）：携帯電話のDMクライアントから更新処理続行の要求が送信されると、DMサーバは携帯電話がローミング中か否かを検査する。ローミング中の時は画面[C-D-04]を表示してソフトウエアの更新を終了する。DMサーバは携帯電話の機種とソフトウエアのバージョン情報をDMクライアントから取得し、当該携帯電話に利用可能な更新ソフトウエアが存在するか否かを検出する。携帯電話が使用しているソフトウエアが最新の場合、画面[C-D-05]を表示し更新処理を終了する。ダウンロードしインストールすべきソフトウエアが決定されると、図４−４の画面[C-N-01]からの処理が実行される。
図９（４）：携帯電話は更新ソフトウエアが正常に機能しているか否かを検査し、検査結果をDMサーバに報告する。

ソフトウエアの更新中は携帯電話を使用することは出来ない。従って、更新処理を行う時間を就寝中等、携帯電話を利用する可能性が小さい時間帯に予約することが考えられる。このような場合、例えば、図１０の画面[C-D-02]等、利用者に入力を要求する状況となっても、利用者がこの要求に応答することは不可能である。従って、利用者の応答を待つ時間を設定するタイマーを設け、利用者からの応答が前記タイマーの設定時間内に無かった場合、利用者から是認の応答があったとみなし、予約更新の処理を続行する構成とする。また、予約日時となり更新処理が開始されると、更新処理が正常に終了したか否かにかかわらず、更新予約の登録情報は消去される。

ソフトウエア更新処理中に携帯電話に、図１０画面［C-D-02］の「予約済時刻になりましたソフトウエア更新を開始します」、あるいは画面［C-D-04］の「海外ローミング中のお客様は本サービスをご利用頂けません」等の文章が表示される。表示される文章のデータには、携帯電話内にテーブル形式で保持され、DMクライアントが処理の進行に即して適宜選択して表示するものと、更新サーバから送信されるコマンド中に設定されている文章を、DMクライアントが抽出して表示するものとがある。図１０では「予約済時刻になりましたソフトウエア更新を開始します」が前者であり、「海外ローミング中のお客様は本サービスをご利用頂けません」が後者である。

予約更新は携帯電話を使用しない日時、例えば就寝時間帯に設定される場合が多い。従って図９および図１０に示される予約更新の処理手順では、利用者による「はい」「いいえ」の選択、あるいは「確認」キーの操作を必須とせず、選択あるいはキー操作が所定時間行われなかった時は、利用者による承諾があったものとして処理を進める。就寝中等に行われた予約更新が成功したか否かを利用者に知らせるため、予約更新に失敗した時、図４−５（ｂ）の画面[D-N-01']に示される様な更新の失敗を知らせる画面とすることが行われている。
上記の方法では、利用者は予約更新に失敗した事実を知り得るのみであり、失敗の原因を知ることは出来ない。予約更新の進行に伴い、携帯電話の表示画面には利用者に更新の進捗状況に関する情報を提示する多くのガイダンスが表示される。これらのガイダンスには、ソフトウエアの更新に失敗した原因を知らせる情報が含まれている。本発明は、ガイダンスとして表示される詳細情報を携帯電話内に保存し、後刻利用者の要求により再表示する構成を採るものである。

図１１は、本実施例に係る表示制御の概要を示す図である。５０は携帯電話内に制御プログラムと共に記憶されているガイダンステーブルであり、プログラムの進行に伴い表示すべきガイダンスが適宜選択される。５１は、図４−４の画面[C-N-06]を表示するため、ガイダンステーブル５０から「ソフトウエアの更新を完了しました。」を選択した状態を示している。
携帯電話のガイダンスには、更新サーバから送信されるものがある。この形式は、サーバから送信されるコマンド内に表示すべきガイダンスを含ませ、コマンドを受信した携帯電話がコマンドに含まれるガイダンス文を抽出し表示するものである。図１１の５２は、ガイダンス文を含むコマンドの例であり、図１０の処理フローにおいて、DMサーバが当該携帯電話は海外ローミング中か否かをチェックし、海外ローミング中と判定した際、携帯電話に送信するコマンドである。同コマンドにはガイダンス文「海外ローミング中のお客様は本サービスを利用できません」が含まれており、ステップ５３で、当該ガイダンスが抽出される。
ガイダンステーブルから選択されたガイダンス、あるいはコマンドから抽出されたガイダンスは表示バッファ５４に格納され、表示制御部５５により表示される。５４はコマンド５２から抽出された「海外ローミング中のお客様は本サービスを利用できません」が格納され、表示されている例である。この例では、図１０の画面[C-D-04]が表示される。

本実施例では表示バッファ５４と並列に待避バッファ５６が設けられている。待避バッファ５６は独立したレジスタであっても、メモリ内にデータ領域として確保したものでも良い。予約更新の処理過程において、重要な情報を含むガイダンスを表示するステップには、当該ガイダンスのデータを表示バッファ５４に格納し表示を行うと共に待避バッファ５６に格納する構成となっている。図１１では、予約更新が行えなかった原因を示す「海外ローミング中のお客様は本サービスを実施できません」のガイダンスデータを表示バッファ５４に格納すると共に待避バッファ５６に格納する処理（５７）が示されている。後刻、利用者が予約更新の結果を確認する操作を行うと、待避バッファ５６に格納されているガイダンスデータは表示バッファ５４に転送される（５８）。この結果、携帯電話には「海外ローミング中のお客様は本サービスを実施できません」のガイダンスが表示され、利用者は予約更新が実行されなかったことと、その原因を知ることが可能となる。

図１２は本実施例に係る予約更新の処理フローである。また、図１３は処理の流れを表示画面により示すものであり、図４−５(ｂ)に相当する。本実施例の予約更新では、図１０の画面［C-D-02］、［C-D-03］、［C-D-04］、［C-D-05］、および、図４−４の画面［C-N-06］から進む（Ｅ１）は、図１３の（Ｅ１'）に変更される。以下、図１２および図１３により、本実施例の処理を解説する。
図１２に示される処理フローの詳細を説明する。

ステップ１０１：予約更新の登録日時となり、更新サーバから予約更新の開始が通知されると、携帯電話ではDMクライアントを起動し更新処理を開始する。
ステップ１０２：携帯電話のバッテリの容量がソフトウエアの更新処理に充分か否かを検査する。不充分の時はステップ１０３に進み、バッテリが充分の時はステップ１０４に進む。
ステップ１０３：図１０画面［C-D-03］のガイダンス、「バッテリ残量が不十分です、充電後再度ソフトウエア更新を行ってください」を表示し、ステップ１１３に進む。
ステップ１０４：図１０画面[C-D-02]を表示して所定時間待つ、時間内に利用者の応答が無い場合はステップ１０５に進む。
ステップ１０５：更新サーバは携帯電話がローミング中か否かを判別し、結果を携帯電話に送信する。ローミング中時はステップ１０６に進み、ローミング中ではない時はステップ１０７に進む。
ステップ１０６：図１０画面［C-D-04］の、ローミング中でありソフトウエアの更新が行えない旨のガイダンスを表示しステップ１１３に進む。
ステップ１０７：携帯電話は自己の機種とソフトウエアの情報を更新サーバに送信する。更新サーバは更新すべきソフトウエアの有無を検査し、結果を携帯電話に送信する。使用中のソフトウエアが最新のものである時はステップ１０８に進み、使用中のソフトウエアが最新のものではなく、ダウンロードしインストールすべきソフトウエアが存在する場合はステップ１０９に進む。
ステップ１０８：図１０画面［C-D-05］の、使用中のソフトウエアが最新のものであり更新を行う必要が無いことを示すガイダンスを表示し、ステップ１１３に進む。
ステップ１０９：更新サーバはネットワークが輻輳状態となっていないか否かを検査する。輻輳状態の時、携帯電話はステップ１１０に進み、ネットワークが輻輳状態に無い時ステップ１１１に進む。
ステップ１１０：携帯電話は、輻輳状態であり更新処理が不可能の旨を表示し、ステップ１１３に進む。
ステップ１１１：携帯電話は更新サーバから更新ソフトウエアをダウンロードしインストールする。
ステップ１１２：携帯電話は、図４−４画面［C-N-06］に示される更新結果を表示する。
ステップ１１３：ステップ１１３への到来は、図１３の（Ｅ１'）に相当する。このステップへの到来が、ステップ１０３、１０６、１０８、１１０からの場合は、携帯電話の表示器には更新を行わなかった原因を示すガイダンスが表示されている。また、ステップ１１２からの場合は、表示器には更新を実行した結果のガイダンスが表示されている。これらガイダンスの表示データは図１１の表示バッファ５４に保持されており、ステップ１１３でこの表示データを待避バッファ５６に待避する（図１３−３００）。
ステップ１１４：携帯電話は予約更新が行われたことを示す「お知らせ画面」を表示し、待ち受け状態となる（図１３−３０１）。

ステップ１２０：起床後等に、利用者は携帯電話のお知らせ画面により、予約更新が自動的に行われたことを認識し、ステップ１２１で確認のキーを操作する（図１３−３０２）。
ステップ１２２：携帯電話は待避バッファ５６に格納されている表示データを表示バッファ５４に転送し、表示回路を制御する（図１３−３０３）。この処理により、ステップ１１３で待避バッファ５６に待避された表示、即ち、更新を行わなかった原因、あるいは更新を実行した結果が表示画面に表示される（図１３−３０４）。
ステップ１２３：利用者は表示された情報を視認し、確認のキーを操作する。
ステップ１２４：携帯電話は待避バッファ５６の内容を消去し（図１３−３０５）、通常の待ち受け画面を表示する（図１３−３０６）。

上記の実施態様では、予約更新の作業において、表示画面に表示するガイダンスデータを表示バッファから待避バッファに複写する構成であった。他の構成として、表示データが図１１のガイダンステーブル５０から読み出された場合は、ガイダンステーブル５０の項番号、図１１の例では（Ｎ）を記憶し、ステップ１２２では、項番号からガイダンステーブルを検索して表示し、表示データがDMサーバからの受信コマンドからの場合は、受信バッファ内の受信データから表示文字列を抽出して表示する構成が可能である。
また、待避バッファにガイダンスデータを待避する構成に変えて、画面の一部あるいは全体を画像データとして待避し、利用者からの要求に基づいて画面を再現する構成も可能である。

携帯電話に更新ソフトウエアをダウンロードしインストールする方法として予約更新がある。この方法は、利用者が更新サーバに、就寝時間等、任意の日時を予約し、予約日時となった時、更新サーバから当該携帯電話を起動することにより、利用者の介入無しに更新ソフトウエアを更新サーバから携帯電話にダウンロードしインストールするものである。予約更新では、更新処理の失敗／成功にかかわらず、利用者の介入無しに処理が進行するため、就寝中等の利用者が更新処理に関する詳細な情報を知ることができない。携帯電話のソフトウエアの更新は重要な作業であり、更新処理が失敗した時には更新処理を再度行う必要がある。しかし、更新処理を失敗した原因を利用者が知ることができないため、更新処理を再実行したとしても、同じ原因により失敗を繰り返すことになる。
ソフトウエア更新処理では、更新過程で多くのガイダンスが表示される。ガイダンスして表示される情報には、携帯電話のバッテリの状態、更新システムの状態等、更新処理の失敗あるいは成功に関する多くの重要な情報が含まれている。本発明は更新ソフトウエアのダウンロードとインストールを利用者の介入無しに行う予約更新において、予約更新の処理過程で表示されるガイダンスから、更新処理の失敗あるいは成功に関する情報を含むガイダンスを選択し携帯電話内に保存する構成を有している。この構成により、ソフトウエアの予約更新が行われたことを認識した利用者が、携帯電話に保存されたガイダンス情報の再表示を指示することにより、予約更新の実行結果に関する詳細な情報を知ることが可能となり、更新処理を再実行したとしても、同じ原因により失敗を繰り返すことが無くなる。

本発明が適用されるソフトウエア更新システムの概要図 更新サーバと携帯電話と間の通信の概要図 ソフトウエア更新の第１の処理図 ソフトウエア更新の第２の処理図 ソフトウエア更新の処理フロー図（１） ソフトウエア更新の処理フロー図（２） ソフトウエア更新の処理フロー図（３） ソフトウエア更新の処理フロー図（４） ソフトウエア更新の処理フロー図（５） ソフトウエア予約更新の登録の処理を示す図 ソフトウエア予約更新の登録の処理フロー図 予約キャンセルの処理図 予約キャンセルの処理フロー図 予約更新実行の処理図 予約更新実行の処理フロー図 本発明に係るソフトウエア更新結果表示手段の概念図 発明に係るソフトウエア更新結果表示制御のフロー図 発明に係るソフトウエア更新結果表示制御が適応される表示処理図

Claims (4)

1. 更新サーバに記憶される更新ソフトウエアにより携帯電話のソフトウエアを自動的に更新するソフトウエア自動更新の更新情報を表示する方法であって、
   更新サーバから予約更新開始の通知を受信することにより更新サーバから更新ソフトウエアをダウンロードしダウンロードしたソフトウエアをインストールするステップと、
   ダウンロードおよびインストールの過程でガイダンスを表示するステップと、
   ダウンロードあるいはインストールの成功あるいは失敗を判定するステップと、
   前記判定ステップによりダウンロードあるいはインストールの成功あるいは失敗が判定された時に表示されているガイダンスの情報を待避するステップと、
   自動更新の更新情報の表示を要求するステップと、
   上記要求ステップに応答して上記待避されたガイダンスの情報を表示するステップからなる
   ソフトウエア自動更新の更新情報を表示する方法。
2. 請求項１記載の方法であって、
   ガイダンスの情報を待避するステップの終了に伴い携帯電話を待ち受け状態とすると供に自動更新の更新情報の表示を要求する画面を表示する方法。
3. 更新サーバに記憶される更新ソフトウエアによりソフトウエアを自動的に更新する携帯電話であって、
   更新サーバから予約更新開始の通知を受信することにより更新サーバから更新ソフトウエアをダウンロードしダウンロードしたソフトウエアをインストールする手段と、
   ダウンロードおよびインストールの過程でガイダンスを表示する手段と、
   ダウンロードあるいはインストールの成功あるいは失敗を判定する手段と、
   前記判定手段がダウンロードあるいはインストールの成功あるいは失敗を判定した時に表示されているガイダンスの情報を待避する手段と、
   自動更新の更新情報の表示を要求する手段と、
   上記要求手段の要求に応答して上記待避されたガイダンスの情報を表示する手段からなる携帯電話。
4. 請求項３記載の携帯電話であって、
   ガイダンスの情報を待避するステップの終了に伴い携帯電話を待ち受け状態とすると供に自動更新の更新情報の表示を要求する画面を表示する携帯電話。
   

Images