(57)【要約】【課題】  古いアプリケーション（データも含む）と最新のアプリケーション間の差異に適した必要最小限のバージョンアップを行うことにより効率的な通信を実現できるようにすることを課題とする。【解決手段】  携帯電話のＲＡＭに、アプリケーションで使用するデータを取得したかどうかを示す共通データ取得フラグと、メジャーな変更からマイナーな変更までをそれぞれ独立させて管理するためのバージョン番号と、クライアントアプリケーション固有のデータと、クライアントアプリケーションで使用する共通データとを保存する。携帯電話は、ネットワークを介してウェブサーバに接続した際に、ＲＡＭに記憶されたバージョン情報にしたがって各リソース、クライアントアプリケーションについて更新の可否を判断し、更新を必要とする対象をウェブサーバに対して要求して更新を行う。【選択図】  図６
2005157885.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してサーバに接続可能な携帯端末であって、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとを記憶する記憶手段と、
第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて更新の有無を判断する第１判断手段と、
第２のトリガに応じて前記記憶手段に記憶されたリソースについて更新有無を判断する第２判断手段と、
前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、
を備えたことを特徴とする携帯端末。
【請求項２】
ネットワークを介してサーバに接続可能な携帯端末であって、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとをそれぞれのバージョン情報とともに記憶する記憶手段と、
第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１判断手段と、
第２のトリガに応じて前記記憶手段に記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２判断手段と、
前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、
を備えたことを特徴とする携帯端末。
【請求項３】
前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２判断手段は前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記更新手段は少なくとも更新が必要な更新項目について更新を実行することを特徴とする請求項２に記載の携帯端末。
【請求項４】
前記更新手段は、前記第1判断手段で更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行することを特徴とする請求項１，２または３に記載の携帯端末。
【請求項５】
ネットワークを介してサーバと携帯端末間で通信を行うアップデートシステムであって、
前記携帯端末においては、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとを記憶する記憶手段と、
第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて更新の有無を判断する第１判断手段と、
第２のトリガに応じて前記記憶手段に記憶されたリソースについて更新有無を判断する第２判断手段と、
前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、
を備え、
前記サーバにおいては、
前記携帯端末に供給するクライアントアプリケーションと当該アプリケーションで使用するリソースとを更新可能に記憶するデータベースと、
前記更新手段の要求に該当する更新対象を前記データベースから取り出して前記携帯端末に送信する送信手段と、
を備えたことを特徴とするアップデートシステム。
【請求項６】
ネットワークを介してサーバと携帯端末間で通信を行うアップデートシステムであって、
前記携帯端末においては、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとをそれぞれのバージョン情報とともに記憶する記憶手段と、
第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１判断手段と、
第２のトリガに応じて前記記憶手段に記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２判断手段と、
前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、
を備え、
前記サーバにおいては、
前記携帯端末に供給するクライアントアプリケーションと当該アプリケーションで使用するリソースとを更新可能に記憶するデータベースと、
前記更新手段の要求に該当する更新対象を前記データベースから取り出して前記携帯端末に送信する送信手段と、
を備えたことを特徴とするアップデートシステム。
【請求項７】
前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２判断手段は前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記更新手段は少なくとも更新が必要な更新項目について更新を実行することを特徴とする請求項６に記載のアップデートシステム。
【請求項８】
前記更新手段は、前記第1判断手段で更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行することを特徴とする請求項５，６または７に記載のアップデートシステム。
【請求項９】
ネットワークを介してサーバに接続可能な携帯端末によるアップデート方法であって、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがメモリに記憶されており、第１のトリガに応じて前記メモリに記憶されたクライアントアプリケーションについて更新の有無を判断する第１ステップと、
第２のトリガに応じて前記メモリに記憶されたリソースについて更新有無を判断する第２ステップと、
前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、
を含んだことを特徴とするアップデート方法。
【請求項１０】
ネットワークを介してサーバに接続可能な携帯端末によるアップデート方法であって、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがそれぞれのバージョン情報とともにメモリに記憶されており、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１ステップと、
第２のトリガに応じて前記メモリに記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２ステップと、
前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、
を含んだことを特徴とするアップデート方法。
【請求項１１】
前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２ステップは前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記第３ステップは少なくとも更新が必要な更新項目について更新を実行することを特徴とする請求項１０に記載のアップデート方法。
【請求項１２】
前記第３ステップは、前記第1ステップで更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行することを特徴とする請求項９，１０または１１に記載のアップデート方法。
【請求項１３】
ネットワークを介してサーバに接続可能な携帯端末のコンピュータで実行可能なアップデート用プログラムであって、
前記コンピュータに、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがメモリに記憶されており、第１のトリガに応じて前記メモリに記憶されたクライアントアプリケーションについて更新の有無を判断する第１ステップと、
第２のトリガに応じて前記メモリに記憶されたリソースについて更新有無を判断する第２ステップと、
前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、
を実行させることを特徴とするアップデート用プログラム。
【請求項１４】
ネットワークを介してサーバに接続可能な携帯端末のコンピュータで実行可能なアップデート用プログラムであって、
前記コンピュータに、
クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがそれぞれのバージョン情報とともにメモリに記憶されており、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１ステップと、
第２のトリガに応じて前記メモリに記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２ステップと、
前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、
を実行させることを特徴とするアップデート用プログラム。
【請求項１５】
前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２ステップは前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記第３ステップは少なくとも更新が必要な更新項目について更新を実行することを特徴とする請求項１４に記載のアップデート用プログラム。
【請求項１６】
前記第３ステップは、前記第1ステップで更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行することを特徴とする請求項１３，１４または１５に記載のアップデート用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえば、携帯端末、アップデートシステム、アップデート方法およびアップデート用プログラムに関する。
【背景技術】
【０００２】
今日、携帯電話の普及に伴って膨大な数、種類の着信メロディ（以下、着メロという）や着信ボイス（以下、着ボイスという）が用意されている。着メロや着ボイスなどのデジタルコンテンツは、コンテンツプロバイダにより提供されることが一般的である。
【０００３】
コンテンツプロバイダは、インターネットにサーバを接続させ、携帯電話網から携帯電話によりアクセスしてくるユーザに対してデジタルコンテンツを提供する。ユーザが着メロをダウンロードする場合には、たとえば携帯電話の画面にブラウザを表示させ、ボタン操作により所望の着メロを選択することにより入手することが可能となる。
【０００４】
最近、コンテンツプロバイダは各種のＪＡＶＡ（登録商標）アプリケーションをユーザに提供してサービスの拡充を図ろうとしている。着メロをダウンロードするだけのサービス提供であれば、ユーザの携帯電話に対してブラウザを通じて着メロをダウンロードさせるだけでよい。
【０００５】
これに対して、着メロのダウンロード以外のスケジューラなどの機能も含めて統合したサービスを提供するとなると、アプリケーション上ですべてのサービスを実現できるほうがによるユーザフレンドリなインタフェースの統一化や機能追加の容易さが得られる。
【０００６】
このようなサービス提供を踏まえると、ユーザの携帯電話上でアプリケーションを継続的に利用してもらう必要がある。そこで、アプリケーションに対して機能追加、バージョンアップなどの変更が加えられると、当然に携帯電話のアプリケーションに対してアップデートが必要となる。
【０００７】
アップデートの手法として、携帯電話に保存されているアプリケーションのバージョン情報をサーバ側で確認し、最新のバージョンにアップしたり（特許文献１）、アプリケーションのバージョンが更新されると、メールなどによりバージョンアップしたアプリケーションを携帯電話に通知するものがある（特許文献２）。
【０００８】
【特許文献１】特開２００３−１２２５７６号公報
【特許文献１】特開２００３−１３４５５１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述した従来例では、アプリケーションのバージョンをひとつの単位として捕らえているので、古いアプリケーション（データも含む）と最新のアプリケーション間のバージョンアップの程度によってはバージョンアップ処理に無駄が多くなり、効率が悪かった。
【００１０】
本発明の目的は、古いアプリケーション（データも含む）と最新のアプリケーション間の差異に適した必要最小限のバージョンアップを行うことにより効率的な通信を実現することが可能な携帯端末、アップデートシステム、アップデート方法およびアップデート用プログラムを提供することになる。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、上記目的を達成するため、請求項１の発明に係る携帯端末は、ネットワークを介してサーバに接続可能な携帯端末であって、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとを記憶する記憶手段と、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて更新の有無を判断する第１判断手段と、第２のトリガに応じて前記記憶手段に記憶されたリソースについて更新有無を判断する第２判断手段と、前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、を備えたことを特徴とするものである。
【００１２】
また、請求項2の発明に係る携帯端末は、ネットワークを介してサーバに接続可能な携帯端末であって、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとをそれぞれのバージョン情報とともに記憶する記憶手段と、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１判断手段と、第２のトリガに応じて前記記憶手段に記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２判断手段と、前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、を備えたことを特徴とするものである。
【００１３】
請求項３の発明は、請求項２の発明において、前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２判断手段は前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記更新手段は少なくとも更新が必要な更新項目について更新を実行するようにしてもよい。
【００１４】
請求項４の発明は、請求項１，２または３において、前記更新手段は、前記第1判断手段で更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行するようにしてもよい。
【００１５】
また、請求項５の発明に係るアップデートシステムは、ネットワークを介してサーバと携帯端末間で通信を行うアップデートシステムであって、前記携帯端末においては、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとを記憶する記憶手段と、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて更新の有無を判断する第１判断手段と、第２のトリガに応じて前記記憶手段に記憶されたリソースについて更新有無を判断する第２判断手段と、前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、を備え、前記サーバにおいては、前記携帯端末に供給するクライアントアプリケーションと当該アプリケーションで使用するリソースとを更新可能に記憶するデータベースと、前記更新手段の要求に該当する更新対象を前記データベースから取り出して前記携帯端末に送信する送信手段と、を備えたことを特徴とするものである。
【００１６】
また、請求項６の発明に係るアップデートシステムは、ネットワークを介してサーバと携帯端末間で通信を行うアップデートシステムであって、前記携帯端末においては、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとをそれぞれのバージョン情報とともに記憶する記憶手段と、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１判断手段と、第２のトリガに応じて前記記憶手段に記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２判断手段と、前記第1または第２判断手段で更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する更新手段と、を備え、前記サーバにおいては、前記携帯端末に供給するクライアントアプリケーションと当該アプリケーションで使用するリソースとを更新可能に記憶するデータベースと、前記更新手段の要求に該当する更新対象を前記データベースから取り出して前記携帯端末に送信する送信手段と、を備えたことを特徴とするものである。
【００１７】
請求項７の発明は、請求項６において、前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２判断手段は前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記更新手段は少なくとも更新が必要な更新項目について更新を実行するようにしてもよい。
【００１８】
請求項８の発明は、請求項５，６または７において、前記更新手段は、前記第1判断手段で更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行するようにしてもよい。
【００１９】
また、請求項９の発明に係るアップデート方法は、ネットワークを介してサーバに接続可能な携帯端末によるアップデート方法であって、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがメモリに記憶されており、第１のトリガに応じて前記メモリに記憶されたクライアントアプリケーションについて更新の有無を判断する第１ステップと、第２のトリガに応じて前記メモリに記憶されたリソースについて更新有無を判断する第２ステップと、前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、を含んだことを特徴とするものである。
【００２０】
また、請求項１０の発明に係るアップデート方法は、ネットワークを介してサーバに接続可能な携帯端末によるアップデート方法であって、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがそれぞれのバージョン情報とともにメモリに記憶されており、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１ステップと、第２のトリガに応じて前記メモリに記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２ステップと、前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、を含んだことを特徴とするものである。
【００２１】
請求項１１の発明は、請求項１０の発明において、前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２ステップは前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記第３ステップは少なくとも更新が必要な更新項目について更新を実行するようにしてもよい。
【００２２】
請求項１２の発明は、請求項９，１０または１１において、前記第３ステップは、前記第1ステップで更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行するようにしてもよい。
【００２３】
また、請求項１３の発明に係るアップデート用プログラムは、ネットワークを介してサーバに接続可能な携帯端末のコンピュータで実行可能なアップデート用プログラムであって、前記コンピュータに、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがメモリに記憶されており、第１のトリガに応じて前記メモリに記憶されたクライアントアプリケーションについて更新の有無を判断する第１ステップと、第２のトリガに応じて前記メモリに記憶されたリソースについて更新有無を判断する第２ステップと、前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、を実行させることを特徴とするものである。
【００２４】
また、請求項１４の発明に係るアップデート用プログラムは、ネットワークを介してサーバに接続可能な携帯端末のコンピュータで実行可能なアップデート用プログラムであって、前記コンピュータに、クライアントアプリケーションと当該クライアントアプリケーションで使用するリソースとがそれぞれのバージョン情報とともにメモリに記憶されており、第１のトリガに応じて前記記憶手段に記憶されたクライアントアプリケーションについて当該クライアントアプリケーションのバージョン情報に基づいて更新の有無を判断する第１ステップと、第２のトリガに応じて前記メモリに記憶されたリソースについて当該リソースのバージョン情報に基づいて更新有無を判断する第２ステップと、前記第1または第２ステップで更新が必要であるという判断がなされた場合、前記サーバとの通信を通じて少なくとも更新が必要な対象のみ更新を実行する第３ステップと、を実行させることを特徴とするものである。
【００２５】
請求項１５の発明は、請求項１４において、前記リソースに対して複数種の更新項目があらかじめ決められ、前記各更新項目に対応させてバージョン情報が設定されており、前記第２ステップは前記各更新項目のバージョン情報に基づいて更新有無を判断し、前記第３ステップは少なくとも更新が必要な更新項目について更新を実行するようにしてもよい。
【００２６】
請求項１６の発明は、請求項１３，１４または１５において、前記第３ステップは、前記第1ステップで更新が必要であるという判断がなされた場合、クライアントアプリケーションについての更新を併せて実行するようにしてもよい。
【発明の効果】
【００２７】
本発明によれば、古いアプリケーション（データも含む）と最新のアプリケーション間の差異に適した必要最小限のバージョンアップを行うことにより効率的な通信を実現することが可能な携帯端末、アップデートシステム、アップデート方法およびアップデート用プログラムを提供できるという効果を奏する。
【発明を実施するための最良の形態】
【００２８】
以下に添付図面を参照して、本発明の一実施の形態について詳述する。
【００２９】
まず、全体について説明する。図１は本発明の一実施の形態によるアップデートシステムを示す構成図である。本実施の形態によるアップデートシステムは、携帯端末側に格納されるアプリケーションをサーバから供給されるアプリケーションでアップデート（更新）するためのものである。
【００３０】
このアップデートシステムは、たとえば図１に示したように、携帯端末の１種である携帯電話とウェブサーバ２とにより構成され、携帯電話網４およびインターネット５で通信可能に接続される。
【００３１】
携帯電話網４は、パケット網４Ａ、ゲートウェイサーバ４Ｂなどを備えている。パケット網４Ａは、たとえば図示せぬ基地局を通じて携帯電話との間で無線通信を行うとともに、インターネット５に接続される各種の端末とゲートウェイサーバ４Ｂを介して通信を行う。ゲートウェイサーバ４Ｂは、インターネット５に接続され、インターネット５に接続されるウェブサーバ２などの端末とパケット網４Ａに無線接続される携帯電話などの携帯端末間の通信を制御する。
【００３２】
携帯電話１は、各種通信端末の代表例を示しており、音声通話、データ通信などを行う機能を備えている。この携帯電話１は、ウェブページを表示させるためのディスプレイ１１、ウェブ閲覧のための操作を司るキー群１２などにより構成される。
【００３３】
ウェブサーバ２は、各種サーバの代表例を示しており、携帯電話からの要求に応じてホームページ閲覧、着メロ、着ボイス、画像などのデジタルコンンテンツのダウンロード、電子商取引などのサービスを提供する。このウェブサーバ２は、ウェブページ、デジタルコンテンツなどの情報を格納したコンテンツデータベース（以下、コンテンツＤＢという）３を接続している。
【００３４】
本実施の形態においては、携帯電話１側のクライアントアプリケーション（以下にアプリケーションという）によりブラウザ形式でブラウザ表示を実現するため、ウェブサーバ２より携帯電話１に対してウェブページが提供される。また、本実施の形態においては、ウェブサーバ２より着メロなどのデジタルコンテンツを携帯電話１に対してダウンロードさせることができる。さらに、本実施の形態においては、データ量の多いデジタルコンテンツについては、ウェブサーバ２側で送信前のデジタルコンテンツについてデータ圧縮を行い、携帯電話１に対してたとえば順次分割転送を行うものである。
【００３５】
つぎに、本実施の形態によるアップデートシステムを構成する各部について詳述する。まずウェブサーバ２について説明する。図２は本実施の形態によるウェブサーバの一構成例を示すブロック図であり、図３は本実施の形態によるリソースの一例を示す図である。
【００３６】
ウェブサーバ２は、インターネット５に接続され、このインターネット５を介して携帯電話、パーソナルコンピュータなどの端末との間の通信を司る通信制御部２０１、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備え、サーバ全体の制御を司る制御部２０２、サーバ全体の制御を行うためのプログラムのほか本実施の形態によるコンテンツ提供のためのサーバ側のアプリケーション２０４、クライアントである携帯電話に供給するための、クライアント側でデジタルコンテンツをダウンロードするためのクライアントアプリケーション２０５、クライアントアプリケーションで使用する共通データからなるリソース２０６などを記憶した記憶部２０３、コンテンツＤＢ３との間でインタフェースを司るＤＢインタフェース２０７などにより構成される。
【００３７】
制御部２０２は、インターネット５を介して他の機器の要求に応じてデジタルコンテンツを提供したり、インターネット５を介して、もしくは、図示せぬドライバを介してデジタルコンテンツの内容を更新する処理も実行する。コンテンツＤＢ３は、着メロデータファイル２０８のほか画像、着ボイス、音楽などのデジタルコンテンツのファイル、ウェブページを構成するためのウェブページ情報などを保存している。
【００３８】
また、記憶部２０３においては、携帯電話との間で共有するダウンローダ（携帯電話が着メロなどのデジタルコンテンツをウェブサーバ２よりダウンロードするためのアプリケーション）であるクライアントアプリケーション２０５、リソース２７を更新可能に格納している。
【００３９】
リソース２０６は、たとえば図３に示したように、リソースサイズ部、データ部などにより構成される。リソースサイズ部は、データ部のサイズを示すものであり、リソースサイズ部とデータ部とは一例として１〜Ｎ（Ｎは自然数）個の対応関係を有している。データ部は、テキストまたは画像データであり、リソースサイズ部の各データサイズによりバイト数が示される。データサイズは２バイトであり、データ部は可変となっている。
【００４０】
このリソース２０６は、初回起動時とアップデート時に取得され、後述するがアップデート有無はクライアントアプリケーションの起動の度に確認される。また、本実施の形態において、クライアントアプリケーション２０５は、リソース２０６がアップデートされる場合には必ずアップデートされるように設定されているが、本発明はこれに限定されるものではなく、クライアントアプリケーション２０５に対してリソース２０５のアップデートが影響しない、もしくは、影響が小さい場合には、アップデートを必要としない設定にしてもよいことは謂うまでもない。
【００４１】
つづいて携帯端末の一例について説明する。図４は本実施の形態による携帯電話１の内部構成を示すブロック図、図５は本実施の形態によるバージョン番号を説明する図、そして、図６は本実施の形態によるアプリケーション１８Ａを含むメモリのデータ構造を説明する図である。
【００４２】
本実施の形態の携帯電話１は、たとえば図４に示したように、内部バス２３に、ディスプレイ１１、キー群１２、音声処理部１３、ＣＰＵ１６、ＲＯＭ１７、ＲＡＭ１８、通信処理部１９、赤外線通信部２１、カメラ２２などを接続させ、データ、アドレス信号、制御信号などを伝送させることで各種の処理を実現する構成である。
【００４３】
通信処理部１９は、アンテナ１８に接続され、アンテナ１８を介して携帯電話網４と通信を行うものである。この通信処理部１９により、音声通話やウェブサーバ２との通信（ｉモード（登録商標）など）を実現することができる。音声処理部１３は、音声出力のためのスピーカ１４、音声入力のためのマイク１５をそれぞれ接続させており、受話時や送話時の音声処理を行うものである。
【００４４】
ＣＰＵ１６は、携帯電話１全体の制御をＲＯＭ１７に格納されたＯＳにしたがって行うものである。ＲＯＭ１７は、あらかじめインストールされているＯＳなどのプログラムを格納している。このＣＰＵ１６は、携帯電話用の各種アプリケーション（たとえばＪＡＶＡ（登録商標）アプリケーション）によりウェブ閲覧、着メロなどのデジタルコンテンツのダウンロード、リソースのアップデートなどを制御する。また、このＣＰＵ１６は、キー群１２からの入力を受け付けて各種の処理を実行させたり、各種の処理に応じて表示を制御する。
【００４５】
ＲＡＭ１８は、カメラ２２による撮像画像を記憶するエリア、各種処理を行うためのワークエリアなどを備えているほか、ウェブサーバ２よりダウンロードしたクライアントアプリケーションに相当するアプリケーション１８Ａ、ウェブサーバ２よりダウンロードした着メロデータ１８Ｂや他のデジタルコンテンツを記憶する。本実施の形態によるウェブブラウザ機能は、アプリケーション１８ＡのうちのたとえばＪＡＶＡ（登録商標）アプリケーションにより実現される。
【００４６】
キー群１２は、電話番号、アドレスなどの入力を行ったり、表示画面上のウェブブラウザに対してページの選択、ページの切り替え、リンク先の指定、着メロなどのデジタルコンテンツのダウンロード指示などを行うための各種キーを備えている。ディスプレイ１１は、ウェブブラウザ、着メロなどのデジタルコンテンツのダウンロードにかかる表示遷移、電話やメールの機能を使うときに表示画面を形成したり、カメラ２２の撮像画像を表示するものである。
【００４７】
赤外線通信部２１は、所定の赤外線規格にしたがって同規格で赤外線通信可能な他の機器とのデータ通信を行うものであり、カメラ２２は、キー群１２の操作にしたがって撮像画像をデジタル画像として取り込むものである。
【００４８】
本実施の形態では、携帯電話側に着メロなどのデジタルコンテンツをダウンロードするためのアプリケーション（リソース）に対してバージョン番号をもたせている。図５には、バージョン番号の意味が示されている。バージョン番号の形式は、一例として、ＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤの４種類であり、それぞれ０〜２５５の数字を当て嵌める。
【００４９】
携帯電話１は、このバージョン番号を所持しており、ウェブサーバ２との間でたとえば着メロのダウンロード要求を行った際に、ウェブサーバ２に通知する。ウェブサーバ２は、ダウンロードのアプリケーションについて最新のバージョン番号を所持しているので、両者を比較して携帯電話１が所持しているアプリケーションのバージョン番号が古ければエラーを返すことになる。
【００５０】
一方、携帯電話１では、前回共通データ（アプリケーション１８Ａで使用するデータ）を取得したときのバージョン番号と今回ウェブサーバ２側で準備されているバージョン番号とを比較し、その差異に応じて共通データを再取得したり、共通リソースにかかるデータを削除したり、クライアントアプリケーションのみの更新によりデータに対する処理を実施しないという処理がなされる。
【００５１】
一例として、ＡＡＡＡはメジャーバージョンを示し、この場合、アプリケーションの大幅な変更を意味することからアップデートを必要とする。ＢＢＢＢは機能のアップグレードを示し、この場合、メジャーバージョンと同様にアップデートを必要とし、画面構成やデータ構造の変更を意味する。ＣＣＣＣはデザインなどのマイナーな変更を示し、この場合、共通リソースの再取得が必要となる。ＤＤＤＤはバグフィックスを示し、この場合、データに変更がないことを意味する。
【００５２】
アップデートに関しては、ウェブサーバ２においてバージョン情報のうちＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤの順に比較を行い、ウェブサーバ２側の数字がひとつでも大きいものがあれば、更新の必要があると判断する。すなわち、バージョン番号は更新のたびに大きくなる。ここで、アプリケーション１８Ａはバージョン情報のうちのひとつでも更新があれば、アップデートされる。
【００５３】
ＲＡＭ１８においては、たとえば図６に示したように、メモリの位置がバイト単位で示されている。０バイト目の位置には、共通データ取得フラグが格納される。これは画面を構成するなどのアプリケーションで使用されるデータを取得したかどうかを示す。この場合、０（ゼロ）は未取得、１は取得済みである。
【００５４】
１バイト目、２バイト目、３バイト目、４バイト目の位置には、それぞれバージョン番号ＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤが格納される。５バイト目以降の位置には、アプリケーション固有のデータ（固定長）、共通データ（可変長の画像データなど）が格納される。ここで、アプリケーション固有のデータはアプリケーション１８Ａを示し、共通データ取得フラグ、バージョン情報、共通データは図示せぬがＲＡＭ１８に格納される。
【００５５】
つぎに動作について説明する。図７および図８は本実施の形態によるダウンロード動作を説明するフローチャート、図９は本実施の形態によるアプリケーションのアップデート動作を説明するフローチャート、図１０は本実施の形態によるレスポンスデータのフォーマットを説明する図、そして、図１１は本実施の形態によるダウンロード時の画面遷移を説明する図である。
【００５６】
以下、携帯電話１の処理は、アプリケーション１８Ａにより実行され、ウェブサーバ２の処理は、アプリケーション２０４により実行される。携帯電話１によりウェブサーバ２へのアクセスが行われ、ユーザの操作により所望の着メロがダウンロード対象として選択されると、まずダウンロード中画面がディスプレイ１１に表示形成される（ステップＳ１０１）。そして、ウェブサーバ２に対して着メロのダウンロード要求（第１のトリガ）が送信される（ステップＳ１０２）。
【００５７】
このダウンロード要求時、携帯電話１からウェブサーバ２に対して、あらかじめユーザに対して割り当てられたユーザを特定するための情報（ユーザＩＤ）、着メロを特定するための着メロＩＤ、着メロなどのデジタルコンテンツをウェブサーバ２よりダウンロードするためのアプリケーションに関するバージョン番号などが送信される。
【００５８】
ウェブサーバ２においては、ダウンロード要求が受け付けられると（ステップＳ２０１）、バージョン番号に基づいてバージョンチェックが行われる（ステップＳ２０２）。ここでは、携帯電話１より受信されたバージョン番号とリソース２０６のバージョン番号とが比較され、アップデートの要否が判断される。
【００５９】
アップデートが不要と判断された場合には（ステップＳ２０３のＮＯルート）、携帯電話１に格納されている現状のアプリケーション１８Ａにより正常に着メロをダウンロードすることが可能である。したがって、処理はステップＳ２０４に移行してユーザのチェックが行われる。このチェックは、携帯電話１から受信されたユーザＩＤが図示されぬ会員データベースに登録されているかどうかにより判断される。
【００６０】
ここで、会員データベースは、ウェブサーバ２にＤＢインタフェース２０７を介して接続されてもよく、あるいは、インターネット５に接続されてウェブサーバ２からアクセス可能な環境下におかれていてもよい。
【００６１】
もし会員登録されていた場合には（ステップＳ２０５のＹＥＳルート）、着メロデータファイル２０８からユーザのリクエストに応じた着メロデータが取得される。この場合、着メロデータのＤＢ検索に着メロＩＤが使用される。
【００６２】
着メロデータファイル２０８から取得された着メロデータは、携帯電話１がダウンロード可能なサイズに圧縮される。圧縮はたとえばＪＡＲ（ＺＩＰ）フォーマットで圧縮し、携帯電話が１回の通信で取得できる最大サイズがたとえば２０Ｋの場合、その２０Ｋを超えるものは２０Ｋずつに分割してダウンロードされるように処理される。そのときの圧縮率は、着メロデータの元ファイルと圧縮後のファイルとの比較により算出される（ステップＳ２０７）。
【００６３】
このようにして、ステータス、圧縮率、圧縮された着メロデータが揃うと、レスポンスデータが生成される。ここで、レスポンスデータとは、たとえば図１０に示したように、先頭１バイトにステータスコードが格納され、２バイト目に圧縮率が格納され、残りの部分に圧縮された着メロデータが格納される。エラー時には、２バイト目以降にデータは格納されない。この場合、ユーザが非会員などのエラー条件がある場合には、エラーを示す情報がレスポンスデータにセットされる。
【００６４】
ステータスコードとは、正常かそれともエラーかを示す情報、ユーザが会員か非会員かを示す情報、アプリケーションのアップデートの要否を示す情報などのフラグにより構成される。圧縮率とは、正常処理時の着メロデータ部分の圧縮率を示す。着メロデータとは、たとえばＪＡＲ圧縮された着メロデータを示す。
【００６５】
一方、ステップＳ２０３においてアップデートが必要と判断されると（ＹＥＳルート）、携帯電話１側で現行のアプリケーションにより着メロデータのダウンロードが完遂できないため、以降はアプリケーションのアップデート処理を優先して行う処理の流れとなる。また、ステップＳ２０５において非会員であると判断がなされると（ＮＯルート）、着メロのダウンロード資格がないためエラー条件のひとつとしてユーザにレスポンスデータを送る必要がある。
【００６６】
ステップＳ２０３、ステップＳ２０５のＮＯルートでは、処理はステップS208に移行してレスポンスデータの生成および携帯電話１への送信が行われる。アップデートが必要な際は、レスポンスデータにおいて、ステータスコードに要アップデートの情報がセットされて送信され、２バイト目以降はデータはセットされず、送信されないことになる。また、非会員の際は、レスポンスデータにおいて、ステータスコードに非会員の情報がセットされて送信され、２バイト目以降はデータはセットされず、送信されないことになる。
【００６７】
そして、携帯電話１においては、ウェブサーバ２から送信されたレスポンスデータが受信されると、まず先頭の２バイト（ステータスコード、圧縮率）が読み込まれる（ステップＳ１０４）。１バイト目のステータスコードからアップデートか否かの判断がなされ、アップデートが必要な場合には（ステップＳ１０５のＹＥＳルート）、処理はステップＳ１０６に移行してアプリケーションのアップデートが実行される。
【００６８】
ここで、ステップＳ１０５において、アップデートなしという判断が下された場合には（ＮＯルート）、処理はステップＳ１１１（図８参照）に移行してステータスコードのうち正常か否かのフラグをチェックする。このとき、異常の際は、エラー情報のダイアログが画面に表示される（ステップＳ１１２）。
【００６９】
一方、正常の際は、さらに２バイト目の圧縮率がチェックされ、圧縮率“０”の際は、そのままダウンロードが実行される（ステップＳ１１５）。圧縮率から圧縮がなされている際は、圧縮率がたとえば図１１（Ａ）のように表示され、ダウンロードが実行される（ステップＳ１１５）。
【００７０】
さて、アップデート処理は図９に示される。携帯電話１では、起動時（第２のトリガ）、図６に示す先頭１バイト目から５バイト分のデータが取得される（ステップＳ３０１）。
アップデートが必要な場合、ステップＳ３０２において、現在ＲＡＭ１８に格納されているアプリケーション１８Ａが所持しているバージョン番号と前回ウェブサーバ２より共通データを取得したときにＲＡＭ１８に格納されたバージョン番号とが比較される。
【００７１】
図６において、１バイト目、２バイト目のバージョン情報（ＡＡＡＡ、ＢＢＢＢ）、３バイト目のバージョン情報（ＣＣＣＣ）、４バイト目のバージョン情報（ＤＤＤＤ）が参照される。そして、メジャーバージョン（ＡＡＡＡ）と機能アップグレード（ＢＢＢＢ）とのいずれか１つでも変更があれば（ステップＳ３０３）、図６で示すデータ構成はすべてゼロで埋められ、処理はステップＳ３０６に移行する（ステップＳ３０４）。
【００７２】
また、デザインなどの変更（ＣＣＣＣ）があれば（ステップＳ３０３）、先頭１バイトにゼロが書き込まれ、処理ステップＳ３０６に移行する（ステップＳ３０５）。また、バグフィックス部分の変更（ＤＤＤＤ）か、あるいは、ＡＡＡＡ、ＢＢＢＢ，ＣＣＣＣ，ＤＤＤＤのいずれも変更がないのであれば（ステップＳ３０３）、処理はステップＳ３０６に移行する。
【００７３】
そして、図６に示した先頭１バイト目の共通データ取得フラグが取得され（ステップＳ３０６）、その値が“０”（未取得）か“１”（取得済み）かを確認する（ステップＳ３０７）。共通データ取得フラグが“１”の場合には（ステップＳ３０７のＮＯルート）、共通データは取得済みと判断され、アップデート処理は終了する。
【００７４】
一方、共通データ取得フラグが“０”の場合には（ステップＳ３０７のＹＥＳルート）、共通データは未取得と判断され、ウェブサーバ２に対してアクセスがなされ、共通リソースが要求される（ステップＳ３０８）。ウェブサーバ２では、その「要求が受け付けられ（ステップＳ４０１）、リソース２０６が読み出されて携帯電話１に対して送信される（ステップＳ３０８）。
【００７５】
携帯電話１では、ウェブサーバ２からの共通リソースが取得されると（ステップＳ３０９）、その共通リソースはＲＡＭ１８の所定の領域に保存され（ステップＳ３１０）、さらにアプリケーションのバージョン番号が保存される（ステップＳ３１１）。その後、図６の先頭１バイト目（０位置）に取得済みを示す“１”が書き込まれる（ステップＳ３１２）。このようにして、アップデート処理が終了する。
【００７６】
なお、ウェブサーバ２側で圧縮された着メロデータは携帯電話１にダウンロードされたときに伸張されるものである。
【００７７】
以上説明したように本実施の形態によれば、携帯電話に保存されているアプリケーション（データも含む）とウェブサーバ側で用意される最新のアプリケーション間の差異に適した必要最小限のバージョンアップを行うことにより、携帯電話とウェブサーバ間の効率的な通信を実現することが可能である。
【産業上の利用可能性】
【００７８】
本発明は、携帯端末、アップデートシステム、アップデート方法およびアップデート用プログラムを製造する産業で利用される。
【図面の簡単な説明】
【００７９】
【図１】本発明の一実施の形態によるアップデートシステムを示す構成図である。
【図２】本実施の形態によるウェブサーバの一構成例を示すブロック図である。
【図３】本実施の形態によるリソースの一例を示す図である。
【図４】本実施の形態による携帯電話１の内部構成を示すブロック図である。
【図５】本実施の形態によるバージョン番号を説明する図である。
【図６】本実施の形態によるデータ構造を説明する図である。
【図７】本実施の形態によるダウンロード動作を説明するフローチャートである。
【図８】本実施の形態によるダウンロード動作を説明するフローチャートである。
【図９】本実施の形態によるアプリケーションのアップデート動作を説明するフローチャートである。
【図１０】本実施の形態によるレスポンスデータのフォーマットを説明する図である。
【図１１】本実施の形態によるダウンロード時の画面遷移を説明する図である。
【符号の説明】
【００８０】
１  携帯電話
２  ウェブサーバ
３  コンテンツＤＢ
１１  ディスプレイ
１２  キー群
１６  ＣＰＵ
１７  ＲＯＭ
１８  ＲＡＭ
１８Ａ  アプリケーション
１８Ｂ  着メロデータ
１９  通信処理部
２０１  通信制御部
２０２  制御部
２０３  記憶部
２０４  アプリケーション
２０５  クライアントアプリケーション
２０６  リソース
２０７  ＤＢインタフェース
２０８  着メロデータファイル
【図１】
2005157885.tif 000003
【図２】
2005157885.tif 000004
【図３】
2005157885.tif 000005
【図４】
2005157885.tif 000006
【図５】
2005157885.tif 000007
【図６】
2005157885.tif 000008
【図７】
2005157885.tif 000009
【図８】
2005157885.tif 000010
【図９】
2005157885.tif 000011
【図１０】
2005157885.tif 000012
【図１１】
2005157885.tif 000013