JP2006011906A - ソフトウェアインストール方法 - Google Patents

Abstract

【課題】 不揮発性メモリの使用量を抑えながらＩＰ電話、携帯電話、ＰＤＡ等の電子機器上で稼動するソフトウェアを安全にアップデートするソフトウェアインストール方法を提供する。
【解決手段】 ブロックＡ１４２に格納されるアプリケーションプログラムのアップデート機能を含むアプリケーションＡ部はブートローダにブロックＢ１４１のデータを消去させ、ネットワークインタフェース１２０を介してコンピュータ２００から受信した新しいアプリケーションＡ部をブロックＢ１４１に書き込ませ、ブロックＡ１４２のデータを消去させ、ブロックＢ１４１からブロックＡ１４２へ新しいアプリケーションＡ部をコピーさせ、ブロックＢ１４１のデータを消去させ、ネットワークインタフェース１２０を介してコンピュータ２００から受信した新しいアプリケーションプログラムのアプリケーションＡ部以外の部分をブロックＢ１４１に書き込ませる。
【選択図】 図１

Description

本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）等の電子機器上で稼動するソフトウェアをアップデートするためのソフトウェアインストール方法に関する。

一般に使用されるＩＰ電話や携帯電話、あるいはＰＤＡ等の上で稼動するソフトウェアは、機能拡張や不良修正に伴うアップデートが必要となることがある。しかし、こうしたソフトウェアのアップデートの際には、特許文献１の技術のように、既存のソフトウェアと、新しいソフトウェアとが同時に電子機器の不揮発性メモリ上に格納された状態となるタイミングがあり、不揮発性メモリの容量の不足が発生しやすい問題点がある。ソフトウェアのアップデートの際に不揮発性メモリの容量の不足が発生すると、当該ソフトウェアのアップデートができないため、ユーザはいつまでも古いソフトウェアを使用しなければならないといった不都合がある。

また、特許文献２に記載の技術は、予めソフトウェアを自身の起動と基本動作とに不可欠な「基本部分」と、「基本部分」を除く付加機能や拡張機能の実行に必要な「拡張部分」とに分けて不揮発性メモリに格納するものである。そして、特許文献２においては、ソフトウェアのアップデートの際に、新しい「基本部分」を不揮発性メモリ上の古い「拡張部分」が格納されていた領域に書き込み、その後、新しい「拡張部分」を不揮発性メモリ上の古い「基本部分」が格納されていた領域に書き込むものである。

しかし、特許文献２に記載の技術では上述の問題点は緩和されるものの、「基本部分」を配置する領域と、「拡張部分」を配置する領域とが同じサイズでなければならないという制約がある問題点がある。
特開２００３−１１４８０７号公報 特開平８−６９３７６号公報

本発明は上記の事情を考慮してなされたもので、その目的は、不揮発性メモリの使用量を抑えながらＩＰ電話、携帯電話、ＰＤＡ等の電子機器上で稼動するソフトウェアを安全にアップデートするソフトウェアインストール方法を提供することである。

この発明は前述の課題を解決するためになされたもので、請求項１の発明は、アプリケーションプログラムを格納する不揮発性メモリと、新しいバージョンのアプリケーションプログラムを外部から受信する受信手段とを備える電子機器におけるアプリケーションプログラムのインストール方法であって、ユーザまたは新しいバージョンのアプリケーションプログラムを保持する外部機器からアップデートの開始要求を受け、アプリケーションプログラムのアップデート機能部以外の機能からなる拡張部を格納するための前記不揮発性メモリ中の領域である第１のブロックからデータを消去し、前記受信手段が受信した新しいバージョンのアプリケーションプログラムのアップデート機能部を前記第１のブロックへ書き込み、アプリケーションプログラムのアップデート機能部を格納するための前記不揮発性メモリ中の領域である第２のブロックからデータを消去し、 前記第１のブロックから前記新しいバージョンのアップデート機能部を読み出して前記第２のブロックへ書き込み、前記第１のブロックからデータを消去し、前記受信手段が受信した新しいバージョンのアプリケーションプログラムの拡張部を前記第１のブロックへ書き込むことを特徴とするインストール方法である。

また、請求項２の発明は、アプリケーションプログラムを格納する不揮発性メモリと、新しいバージョンのアプリケーションプログラムを外部から受信する受信手段とを備える電子機器におけるアプリケーションプログラムのインストール方法であって、ユーザまたは新しいバージョンのアプリケーションプログラムを保持する外部機器からアップデートの開始要求を受け、アプリケーションプログラムのアップデート機能部以外の機能からなる拡張部を格納するための前記不揮発性メモリ中の領域である第１のブロックからデータを消去し、アプリケーションプログラムのアップデート機能部を格納するための前記不揮発性メモリ中の領域である第２のブロックから既存のアップデート機能部を読み出し、前記読み出したアップデート機能部を前記第１のブロックへ書き込み、前記第２のブロックからデータを消去し、前記受信手段が受信した前記新しいバージョンのアプリケーションプログラムのアップデート機能部を前記第２のブロックへ書き込み、前記第１のブロックからデータを消去し、前記受信手段が受信した新しいバージョンのアプリケーションプログラムの拡張部を前記第１のブロックへ書き込むことを特徴とするインストール方法である。

また、請求項３の発明は、請求項１または請求項２に記載のインストール方法であって、前記第１のブロックへのデータの書き込み時に、第１の書き込みチェック情報を前記第１のブロックへ更に書き込み、前記第２のブロックへのデータの書き込み時に、第２の書き込みチェック情報を前記第２のブロックへ更に書き込み、前記電子機器の起動時に、前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とをチェックし、データが正しく格納されていないことを検知した時、前記アプリケーションプログラムのアップデートを行うことを特徴とするものである。

また、請求項４の発明は、請求項３に記載のインストール方法であって、前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とは巡回冗長検査のためのデータであることを特徴とするものである。

また、請求項５の発明は、請求項３に記載のインストール方法であって、前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とは前記アプリケーションプログラムのバージョン情報であることを特徴とするものである。

請求項１または請求項２の発明によれば、既存のアプリケーションプログラムが格納されていた記憶領域を使用してアップデートを行うため、不揮発性メモリなどを節約できる効果がある。また、特許文献２のようにアップデート機能部と、拡張部とが同じ大きさでなければならないといった制限も無い。

請求項３〜請求項５の発明によれば、アップデート中に何らかのトラブルが発生した場合でも、再度アップデートを実行するため、電子機器が再起動できなくなるなどの不都合を抑止できる効果がある。

以下、図面を参照し、この発明の実施の形態について説明する。以降では第１の実施の形態と、第２の実施の形態とについて説明する。図１は第１の実施の形態におけるシステムの構成図である。また、第２の実施の形態についても構成は同様である。

図１において、符号１００はＩＰ電話である。ユーザインタフェース１１０はユーザからの指示を受け付けるためのＩＰ電話１００のキーボードである。ネットワークインタフェース１２０はＩＰ電話１００がネットワークを介してデータの送受信を行うためのインタフェース機能である。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１３０はＩＰ電話１００の中央処理装置であり、アプリケーションプログラム等を実行する。

フラッシュＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１４０はＩＰ電話１００のアプリケーションプログラムを格納する書き換え可能な不揮発性のメモリである。フラッシュＲＯＭ１４０に格納されるアプリケーションプログラムはアプリケーションＡ部と、アプリケーションＢ部とから構成される。アプリケーションＡ部はアプリケーションプログラム自身のアップデート処理における制御機能であり、詳細は後述する。アプリケーションＢ部（拡張部）はアプリケーションプログラムのアプリケーションＡ部以外の機能である。

フラッシュＲＯＭ１４０中のブロックＡ１４２はアプリケーションＡ部を格納するための領域であり、ブロックＢ１４１はアプリケーションＢ部を格納するための領域である。また、ブロックＡ１４２はアプリケーションＡ部と共にＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ、巡回冗長検査）チェック用のデータであるＣＲＣデータと、アプリケーションＡ部のバージョン情報とを格納する。ブロックＢ１４１も同様である。

ブートローダ格納領域１４３はアプリケーションプログラムの起動を行うプログラムであるブートローダを格納するためのフラッシュＲＯＭ１４０中の領域である。このブートローダは、更に、アプリケーションプログラムのアップデート時にアプリケーションプログラムからの要求に応じてフラッシュＲＯＭ１４０をアクセスする。ブートローダはまた、ＣＲＣデータと、バージョン情報との変更も行う。

ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１５０はアプリケーションプログラムがデータを一時保存するためのメモリである。コンピュータ２００はネットワークを経由してＩＰ電話１００から新しいバージョンのアプリケーションプログラムの送信要求を受け、該当するプログラムと、当該プログラムのバージョン情報とを記憶部３００から読み出して送信する。

次に、図を参照して第１の実施の形態における処理の流れと、第２の実施の形態における処理の流れとを説明する。
＜第１の実施の形態＞
図２と、図３とは第１の実施の形態における処理の流れを表している。いま、ＩＰ電話１００のフラッシュＲＯＭ１４０には、図２のＳＴＥＰ１実行前の状態のように古いバージョンのアプリケーションプログラムが格納されている。図２のＳＴＥＰ１実行前の状態において、ブロックＡ１４２には古いバージョンのアプリケーションＡ部である“Ａ１”が、ブロックＢ１４１には古いバージョンのアプリケーションＢ部である“Ｂ１”が格納されている。ＩＰ電話１００はこの“Ａ１”と“Ｂ１”とからなるアプリケーションプログラムを実行している。

ＩＰ電話１００のユーザはアプリケーションプログラムのＡ部の動作中において、アップデートの指示をユーザインタフェース１１０に入力する。"Ａ１"はユーザの指示をユーザインタフェース１１０経由で受け、ネットワークインタフェース１２０経由でコンピュータ２００に新しいアプリケーションプログラムの取得要求を送信する。

コンピュータ２００はネットワークを経由してＩＰ電話１００からの要求を受信し、記憶部３００をアクセスして新しいアプリケーションプログラムのアプリケーションＡ部である"Ａ２"と、アプリケーションＢ部である"Ｂ２"と、当該アプリケーションプログラムのバージョン情報とを読み出し、読み出したデータをネットワーク経由でＩＰ電話１００へ送信する。

ＩＰ電話１００の"Ａ１"はネットワークインタフェース１２０経由でコンピュータ２００から"Ａ２"と、"Ｂ２"と、バージョン情報とを受信し、受信した"Ａ２"と、"Ｂ２"と、バージョン情報とをＲＡＭ１５０に書き込む。"Ａ１"はＲＡＭ１５０に格納された"Ａ２"およびバージョン情報を読み出し、ブートローダに"Ａ２"およびバージョン情報を出力してブロックＢ１４１のデータの消去と、"Ａ２"およびバージョン情報の書き込みとの要求を出力する。ブートローダは"Ａ１"からの要求を受け、フラッシュＲＯＭ１４０のブロックＢ１４１に格納された"Ｂ１"を消去し（図２のＳＴＥＰ１、図３のステップＳ０１）、入力した"Ａ２"をブロックＢ１４１に書き込み（図２のＳＴＥＰ２、図３のステップＳ０２）、バージョン情報と、ＣＲＣデータとの更新を行う。

このように、ＩＰ電話１００は、図２のＳＴＥＰ２の時点では古いアプリケーションプログラムの“Ａ１”をフラッシュＲＯＭ１４０のブロックＡ１４２に残したままにする。これにより、図２のＳＴＥＰ１またはＳＴＥＰ２でＩＰ電話１００に電源断などのトラブルが発生し、“Ｂ１”の削除や“Ａ２”の書き込みが中途半端な状態となった場合であっても、ユーザがＩＰ電話１００を再起動する際にブートローダがこれをＣＲＣチェックで検知し、“Ａ１”を起動してアップデートの再実行を“Ａ１”に要求し、実行することが可能である。これにより、アップデートが確実に実行されると共に、ＩＰ電話１００が再起動できない等の問題の発生を抑止することができる。

次に、ブートローダはＩＰ電話１００を再起動する。この時、フラッシュＲＯＭ１４０においては“Ｂ１”の削除と“Ａ２”の書き込みが完了し、“Ａ１”が残った状態である。ブートローダは再起動後にこの状態をバージョンチェックで検知し、新しいバージョンであるブロックＢ１４１に書かれた“Ａ２”を起動してアップデートの続行を“Ａ２”に要求する。

次に、“Ａ２”はブートローダに、ブロックＡ１４２のデータの消去と、ブロックＢ１４１に格納された“Ａ２”のブロックＡ１４２への書き込みとの要求を出力する。ブートローダは“Ａ２”からの要求を受け、フラッシュＲＯＭ１４０のブロックＡ１４２をアクセスしてデータを消去し（図２のＳＴＥＰ３、図３のステップＳ０３）、ブロックＢ１４１に格納された“Ａ２”を読み出してブロックＡ１４２に書き込む（図２のＳＴＥＰ４、図３のステップＳ０４）。

このように、ＩＰ電話１００は、アプリケーションプログラムの“Ａ２”がフラッシュＲＯＭ１４０のブロックＢ１４１に確実に格納された後で、“Ａ２”のブロックＡ１４２への書き込みを行う。これにより、図２のＳＴＥＰ３またはＳＴＥＰ４でＩＰ電話１００に電源断などのトラブルが発生し、“Ａ１”の削除や“Ａ２”のブロックＡ１４２への書き込みが中途半端な状態となった場合であっても、ユーザがＩＰ電話１００を再起動する際にブートローダがＣＲＣチェックによってブロックＡ１４２の状態の不正を検知し、ブロックＢ１４１に格納された“Ａ２”を起動してアップデートの再実行を“Ａ２”に要求する。これにより、アップデートが確実に実行されると共に、ＩＰ電話１００が再起動できない等の問題の発生を抑止することができる。

次に、ブートローダはＩＰ電話１００を再起動する。この時、フラッシュＲＯＭ１４０においてはブロックＢ１４１と、ブロックＡ１４２との両方に“Ａ２”が格納された状態である。ブートローダは再起動後にこの状態をバージョンチェックで検知し、ブロックＢ１４１と、ブロックＡ１４２とに同じバージョンの“Ａ２”が格納されていることから、ブロックＡ１４２に書かれた“Ａ２”を起動してアップデートの続行を“Ａ２”に要求する。

次に、“Ａ２”はＲＡＭ１５０に格納された“Ｂ２”と、バージョン情報とを読み出し、ブートローダに“Ｂ２”と、バージョン情報とを出力してブロックＢ１４１のデータの消去と、“Ｂ２”の書き込みとの要求を出力する。ブートローダは“Ａ２”からの要求を受け、フラッシュＲＯＭ１４０のブロックＢ１４１に格納された“Ａ２”を消去し（図２のＳＴＥＰ５、図３のステップＳ０５）、入力した“Ｂ２”をブロックＢ１４１に書き込み（図２のＳＴＥＰ６、図３のステップＳ０６）、ＣＲＣデータと、バージョン情報との更新を行う。ここまでの処理により、アプリケーションプログラムのアップデートは完了する。

＜第２の実施の形態＞
図４は第２の実施の形態における処理の流れを表している。いま、ＩＰ電話１００のフラッシュＲＯＭ１４０には、図２のＳＴＥＰ１実行前の状態のように古いバージョンのアプリケーションプログラムが格納されている。図２のＳＴＥＰ１実行前の状態において、ブロックＡ１４２には古いバージョンのアプリケーションＡ部である“Ａ１”が、ブロックＢ１４１には古いバージョンのアプリケーションＢ部である“Ｂ１”が格納されている。ＩＰ電話１００はこの“Ａ１”と“Ｂ１”とからなるアプリケーションプログラムを実行している。

ＩＰ電話１００のユーザはアプリケーションプログラムのＡ部の動作中において、アプリケーションプログラムのアップデートの指示をユーザインタフェース１１０に入力する。"Ａ１"はユーザの指示をユーザインタフェース１１０経由で受け、ネットワークインタフェース１２０経由でコンピュータ２００に新しいアプリケーションプログラムの取得要求を送信する。

コンピュータ２００はネットワークを経由してＩＰ電話１００からの要求を受信し、記憶部３００をアクセスして新しいアプリケーションプログラムのＡ部である"Ａ２"と、Ｂ部である"Ｂ２"と、バージョン情報とを読み出し、読み出したデータをネットワーク経由でＩＰ電話１００へ送信する。ＩＰ電話１００の"Ａ１"はネットワークインタフェース１２０経由でコンピュータ２００から"Ａ２"と、"Ｂ２"と、バージョン情報とを受信し、受信した"Ａ２"と、"Ｂ２"と、バージョン情報とをＲＡＭ１５０に書き込む。

次に、"Ａ１"はブートローダにフラッシュＲＯＭ１４０をアクセスさせ、ブロックＢ１４１に格納されたアプリケーションプログラムのＢ部である"Ｂ１"を消去させる（図４のステップＴ０１）。そして、"Ａ１"はブートローダに、ブロックＡ１４２に格納された"Ａ１"をブロックＢ１４１へコピーさせる（図４のステップＴ０２）。この時、ブートローダはブロックＡ１４２のバージョン情報もブロックＢ１４１にコピーし、また、ブロックＢ１４１のＣＲＣデータも更新する。

このように、ＩＰ電話１００は、この時点では古いアプリケーションプログラムの“Ａ１”をフラッシュＲＯＭ１４０のブロックＡ１４２に残したままにする。これにより、図４のステップＴ０１またはステップＴ０２でＩＰ電話１００に電源断などのトラブルが発生し、“Ｂ１”の削除や“Ａ１”の書き込みが中途半端な状態となった場合であっても、ユーザがＩＰ電話１００を再起動する際にブートローダがこれをＣＲＣチェックを行って検知し、“Ａ１”を再起動してアップデートの再実行を要求する。これにより、アップデートが確実に実行されると共に、ＩＰ電話１００が再起動できない等の問題の発生を抑止することができる。

次に、ブートローダはＩＰ電話１００を再起動する。この時、フラッシュＲＯＭ１４０においてはブロックＢ１４１と、ブロックＡ１４２との両方に“Ａ１”が格納された状態である。ブートローダは再起動後にこの状態をバージョンチェックで検知し、ブロックＢ１４１と、ブロックＡ１４２とに同じバージョンの“Ａ１”が格納されていることから、ブロックＢ１４１に書かれた“Ａ１”を起動してアップデートの続行を“Ａ１”に要求する。

次に、“Ａ１”はＲＡＭ１５０から“Ａ２”と、バージョン情報とを読み出し、ブートローダに“Ａ２”と、バージョン情報とを出力し、ブロックＡ１４２からのデータの消去と、ブロックＡ１４２への“Ａ２”の書き込みとを要求する。ブートローダは“Ａ１”の要求を受け、フラッシュＲＯＭ１４０のブロックＡ１４２に格納されたデータを消去し（図４のステップＴ０３）、入力した“Ａ２”と、バージョン情報とをブロックＡ１４２に書き込み（図４のステップＴ０４）、また、ＣＲＣデータを更新する。

このように、ＩＰ電話１００は、アプリケーションプログラムの“Ａ１”がフラッシュＲＯＭ１４０のブロックＢ１４１に確実に格納された後で、“Ａ２”のブロックＡ１４２への書き込みを行う。これにより、図４のステップＴ０３またはステップＴ０４でＩＰ電話１００に電源断などのトラブルが発生し、“Ａ１”の削除や“Ａ２”のブロックＡ１４２への書き込みが中途半端な状態となった場合であっても、ユーザがＩＰ電話１００を再起動する際にブートローダがこれをＣＲＣチェックによって検知し、“Ａ１”を起動してアップデートの再実行を要求する。これにより、アップデートが確実に実行されると共に、ＩＰ電話１００が再起動できない等の問題の発生を抑止することができる。

次に、ブートローダはＩＰ電話１００を再起動する。この時、フラッシュＲＯＭ１４０においては “Ａ１”と、“Ａ２”とが格納された状態である。ブートローダは再起動の際にこの状態をバージョンチェックで検知し、新しいバージョンであるブロックＡ１４２に書かれた“Ａ２”を起動してアップデートの続行を“Ａ２”に要求する。

次に、“Ａ２”はＲＡＭ１５０に格納された“Ｂ２”と、バージョン情報とを読み出してブートローダへ出力し、ブロックＢ１４１からのデータの消去と、“Ｂ２”のブロックＢ１４１への書き込みを要求する。ブートローダは“Ａ２”からの要求を受け、フラッシュＲＯＭ１４０のブロックＢ１４１からデータを消去し（図４のステップＴ０５）、入力した“Ｂ２”をブロックＢ１４１に書き込み（図４のステップＴ０６）、ＣＲＣデータと、バージョン情報とを更新する。ここまでの処理により、アプリケーションプログラムのアップデートは完了する。

以上、図面を参照して本発明の実施の形態について詳述してきたが、具体的な構成はこの実施の形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。例えば、ＩＰ電話１００はコンピュータ２００から“Ａ２”と、“Ｂ２”とを１度に受信したが、これを“Ａ２”および“Ｂ２”の各々をフラッシュＲＯＭ１４０への書き込みの直前に行っても良い。ＩＰ電話１００はＲＡＭ１５０に“Ａ２”、あるいは“Ｂ２”を一旦格納することなくアプリケーションプログラムをアップデートできるため、メモリ不足等のトラブルを避けることができる効果がある。

また、ブートローダは図２のＳＴＥＰ２において、“Ａ２”のサイズに応じて“Ａ２”のブロックＢ１４１への書き込み開始アドレスを調整しても良い。例えば、“Ａ１”よりも“Ａ２”の方が大きい場合には、ブートローダが“Ａ２”のブロックＢ１４１への書き込み開始アドレスを“Ａ１”と、“Ａ２”とのサイズの差分だけ加算することにより、ＳＴＥＰ４でブロックＡ１４２への“Ａ２”の書き込みが可能となる。これにより、“Ａ１”が格納されていたアドレスと同じアドレスから“Ａ２”を書き込むことができるため、ブートローダがアプリケーションプログラムのアップデデートに伴ってアドレス切り替えなどを行う必要が無くなり、また、ＩＰ電話１００がこのアドレス切り替えのための回路を備える必要もなくなる効果がある。

また、本実施の形態においてはＣＲＣを用いてフラッシュＲＯＭ１４０に格納されているアプリケーションプログラムに問題がないことを確認したが、これをアプリケーションＡ部のバージョン情報と、アプリケーションＢ部のバージョン情報とで行っても良い。フラッシュＲＯＭ１４０への書き込みの成功時にバージョン情報をセットし、アプリケーションＡ部のバージョン情報と、アプリケーションＢ部のバージョン情報とを比較することにより、同様のチェックが可能である。例えば、図２のＳＴＥＰ２直後の状態では、ブロックＡ１４２と、ブロックＢ１４１とに格納された“Ａ１”と、“Ａ２”とのバージョンは異なる。このようにバージョンの違いを検知することにより、アプリケーションプログラムに問題があるか否かを確認できる。

また、本実施の形態においてはＩＰ電話に関するアプリケーションプログラムのインストール方法について説明したが、ＩＰ電話以外についても、例えば携帯電話やＰＤＡ、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）等についても、本実施の形態の適用が可能である。

また、本実施の形態においてはアプリケーションプログラムのうち、アップデート機能部がブートローダに随時、指示を出してフラッシュＲＯＭ１４０の消去及び書き込みを実行しているが、ブートローダ自体がアップデートの進行制御を行ってもよい。これにより、再起動の必要もなくなる効果がある。

また、本実施の形態においてはアップデートの開始をユーザが指示しているが、これをコンピュータ２００が行っても良い。アプリケーションプログラムのアップデートが遅滞無く行われるため、ユーザは常に最新のアプリケーションプログラムを使用できる効果がある。

この発明の実施の形態におけるソフトウェアインストール方法を使用するシステムの構成を示すブロック図である。 この発明の実施の形態における処理の流れを表す図である。 この発明の実施の形態における処理の流れを表すフローチャートである。 この発明の実施の形態における処理の流れを表すフローチャートである。

符号の説明

１００…ＩＰ電話、２００…コンピュータ、３００…記憶部、１１０…ユーザインタフェース、１２０…ネットワークインタフェース、１３０…ＣＰＵ、１４０…フラッシュＲＯＭ、１５０…ＲＡＭ、１４１…ブロックＢ、１４２…ブロックＡ、１４３…ブートローダ格納領域、ＮＷ…ネットワーク、Ｂ…バス

Claims (5)

1. アプリケーションプログラムを格納する不揮発性メモリと、新しいバージョンのアプリケーションプログラムを外部から受信する受信手段とを備える電子機器におけるアプリケーションプログラムのインストール方法であって、
   ユーザまたは新しいバージョンのアプリケーションプログラムを保持する外部機器からアップデートの開始要求を受け、
   アプリケーションプログラムのアップデート機能部以外の機能からなる拡張部を格納するための前記不揮発性メモリ中の領域である第１のブロックからデータを消去し、
   前記受信手段が受信した新しいバージョンのアプリケーションプログラムのアップデート機能部を前記第１のブロックへ書き込み、
   アプリケーションプログラムのアップデート機能部を格納するための前記不揮発性メモリ中の領域である第２のブロックからデータを消去し、
   前記第１のブロックから前記新しいバージョンのアップデート機能部を読み出して前記第２のブロックへ書き込み、
   前記第１のブロックからデータを消去し、
   前記受信手段が受信した新しいバージョンのアプリケーションプログラムの拡張部を前記第１のブロックへ書き込むことを特徴とするインストール方法。
2. アプリケーションプログラムを格納する不揮発性メモリと、新しいバージョンのアプリケーションプログラムを外部から受信する受信手段とを備える電子機器におけるアプリケーションプログラムのインストール方法であって、
   ユーザまたは新しいバージョンのアプリケーションプログラムを保持する外部機器からアップデートの開始要求を受け、
   アプリケーションプログラムのアップデート機能部以外の機能からなる拡張部を格納するための前記不揮発性メモリ中の領域である第１のブロックからデータを消去し、
   アプリケーションプログラムのアップデート機能部を格納するための前記不揮発性メモリ中の領域である第２のブロックから既存のアップデート機能部を読み出し、
   前記読み出したアップデート機能部を前記第１のブロックへ書き込み、
   前記第２のブロックからデータを消去し、
   前記受信手段が受信した前記新しいバージョンのアプリケーションプログラムのアップデート機能部を前記第２のブロックへ書き込み、
   前記第１のブロックからデータを消去し、
   前記受信手段が受信した新しいバージョンのアプリケーションプログラムの拡張部を前記第１のブロックへ書き込むことを特徴とするインストール方法。
3. 前記第１のブロックへのデータの書き込み時に、第１の書き込みチェック情報を前記第１のブロックへ更に書き込み、
   前記第２のブロックへのデータの書き込み時に、第２の書き込みチェック情報を前記第２のブロックへ更に書き込み、
   前記電子機器の起動時に、前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とをチェックし、データが正しく格納されていないことを検知した時、前記アプリケーションプログラムのアップデートを行うことを特徴とする請求項１または請求項２に記載のインストール方法。
4. 前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とは巡回冗長検査のためのデータであることを特徴とする請求項３に記載のインストール方法。
5. 前記第１の書き込みチェック情報と、前記第２の書き込みチェック情報とは前記アプリケーションプログラムのバージョン情報であることを特徴とする請求項３に記載のインストール方法。

Images