JP5461441B2 - 改良されたアプリケーションリソース更新 - Google Patents

Description

背景
本発明はソフトウェア環境に関し、特にそのような環境におけるソフトウェアコンポーネントの更新に関する。

一般に、「ソフトウェアコンポーネント」とは、Ｊａｖａ（登録商標）、コンポーネントオブジェクトモデル（ＣＯＭ）、分散コンポーネントオブジェクトモデル（ＤＣＯＭ）等の仕様に準拠するコンピュータプログラムオブジェクトまたはオブジェクトの集まりである。ソフトウェアコンポーネントを使用する利点には、モジュール性、分散処理システムへの対応、および言語からの独立性が含まれ、これは異なるコンピュータプログラミング言語で実装されたソフトウェアコンポーネントが協働できることを意味する。

Ｊａｖａ Ｍｉｃｒｏ Ｅｄｉｔｉｏｎ（ＪＭＥ）は、デジタル通信システムにおける携帯電話およびその他の端末のように限られた処理資源を有する装置で用いられることが多いプラットフォームまたは環境である。Ｊａｖａで書かれたソフトウェアコンポーネント、すなわちＪａｖａアプリケーションはミッドレット（ｍｉｄｌｅｔｓ）とも呼ばれ、そのような装置内のプロセッサにより実行され、そのようなコンポーネントは多くの装置機能、例えば、画像またはテキストファイルの表示、音声またはビデオファイルの再生等を実施する。Ｊａｖａアプリケーションは通常、一組のコンパイルされたＪａｖａファイル（すなわちクラスファイル）としてダウンロードされる。実行中に、アプリケーションのクラスがバーチャル・マシン（ＶＭ）にロードされる。

プログラム通信装置へのＪＭＥの利用は、例えば、「ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒｓ．ｓｕｎ．ｃｏｍ／ｍｏｂｉｌｉｔｙ／ｍｉｄｐ／ａｒｔｉｃｌｅｓ／ｍｉｄｐｗａｐ２／？ｆｅｅｄ＝ＤＳＣ」から入手可能な、Ｑ． Ｈ． Ｍａｈｍｏｕｄ， “Ｍｏｂｉｌｅ Ｄｅｖｉｃｅ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｌａｔｆｏｒｍｓ”， Ａｕｇ． ２００６、および、「ｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒｓ．ｓｕｎ．ｃｏｍ／ｍｏｂｉｌｉｔｙ／ｍｉｄｐ／ａｒｔｉｃｌｅｓ／ｍｉｄｐｗａｐ／」で入手可能な、Ｑ． Ｈ． Ｍａｈｍｏｕｄ， “Ｊ２ＭＥ ＭＩＤＰ ａｎｄ ＷＡＰ Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｔｅｃｈｎｏｌｏｇｉｅｓ”， Ｆｅｂ． ２００２に記述されている。ミッドレットは、Ｊａｖａ記述子（ＪＡＤ）ファイルに記述されていて、動作環境を提供するミッドレット管理ソフトウェア内で動作する。動作が終了したならば、ミッドレットは消去されるまで装置上にインストールされたままである。

Ｊａｖａアプリケーションおよび類似のソフトウェアコンポーネントの開発は継続的な処理であるため、既に装置にインストールされているアプリケーションを更新または改良されたバージョンで置き換えることが度々ある。ＪＭＥ環境は現在、装置のユーザーに、（１）自装置に最も適したＪａｖａアプリケーションの別のバージョンを探させ、（２）当該別バージョンをダウンロードさせ、（３）Ｊａｖａアプリケーションの代替バージョンをインストールさせることにより、ミッドレットの更新またはアップグレードを提供する。

現在の更新手順では、アプリケーション内で１個のリソースファイル、例えば音声ファイルだけを更新すればよい場合であっても、Ｊａｖａアプリケーション全体がダウンロードされる。従って、現在の更新手順は、時間および通信システムの帯域幅を浪費する恐れがある。更に、ユーザーは全更新手順を実行し、次いでアプリケーションが自分の装置に適しているか、すなわち装置が十分なメモリを有するか否かを判定できる前にアプリケーションを実行する必要がある。ここでもユーザーの時間を浪費して、ユーザーの装置に関して不満が生じる恐れがある。
英国特許出願公開第２ ３６０ ３７６号は、ファイル内にソース識別子が存在するか否かを判定し、当該ファイルの新規バージョンを探してソースを定期的に調べて、これをダウンロードしてパーソナルコンピュータ上で当該ファイルを代替することによりコンピュータシステム内でファイルを最新状態に保つ方法を記述している。当該ファイル内にソース識別子が存在しない場合、ソース参照先を添付してもよい。ソース識別子はまた、当該ファイルの拡張属性に配置されていてよく、ＵＲＬであってよい。

不慣れなユーザーでもアクセスし易いように、且つ、ユーザーが自分のアプリケーションの正しいバージョンを確実にインストールできるように支援すべく、現在の更新手順を改良することに利点があろう。また、更新手順が可変なメディアリソースを分離することにより、更新されたアプリケーションの断片化の抑制を支援することにも利点があろう。

要約
本発明の態様によれば、通信システム用のユーザー機器内の電子プロセッサにより実行可能なソフトウェアアプリケーションに使用されるリソースファイルを更新する方法を提供する。本方法は、リソースファイルに関する課題を探索するステップと、リソースファイルに対応するアプリケーションのプロバイダへ、利用可能な通信ネットワークを介して送信するための報告メッセージ（レポートメッセージ）を生成するステップと、報告メッセージを送信するステップと、報告メッセージに応答してリソースファイルをユーザー機器において受信するステップと、受信したリソースファイルをユーザー機器にインストールするステップとを含んでいる。プロバイダは、リソースファイルに対応する記述子ファイルの属性値により識別される。

本発明の更なる態様によれば、通信システム用のユーザー機器内の電子プロセッサにより実行可能なソフトウェアアプリケーションに使用されるリソースファイルを更新する装置を提供する。本装置は、リソースファイルに関する課題を探索し、リソースファイルに対応するアプリケーションのプロバイダへ、利用可能な通信ネットワークを介して送信するための報告メッセージを生成し、ユーザー機器に報告メッセージを送信させ、報告メッセージに応答して受信されたリソースファイルをユーザー機器にインストールするように構成されたプロセッサを含んでいる。プロバイダは、リソースファイルに対応する記述子ファイルの属性値により識別される。

本発明の更なる態様によれば、実行時に、通信システム用のユーザー機器内の電子プロセッサにより実行可能なソフトウェアアプリケーションに使用されるリソースファイルを更新する方法をコンピュータに実行させる命令が格納されているコンピュータ可読媒体を提供する。本方法は、リソースファイルに関する課題を探索するステップと、利用可能な通信ネットワークを介して、リソースファイルに対応するアプリケーションのプロバイダに送信するための報告メッセージを生成するステップと、報告メッセージを送信するステップと、報告メッセージに応答してリソースファイルをユーザー機器において受信するステップと、受信したリソースファイルをユーザー機器にインストールするステップとを含んでいる。プロバイダは、リソースファイルに対応する記述子ファイルの属性値により識別される。

本発明の各種の特徴、目的、および効果は、図面と合わせて以下の説明を読めば明らかになろう。

アプリケーションリソースを更新する方法のフロー図である。 通信システムを示す図である。 通信システム用のユーザー機器のブロック図である。 通信システムのアプリケーションリソースを更新する方法の使用事例を示す図である。

詳細な説明
発明者らは、ＪＭＥ等のＪａｖａ実行環境が、ＪＡＤファイルの典型的な定義を変更することにより、異なる装置によるＪａｖａリソース、例えば音声ファイル、画像ファイル、ビデオクリップ等の扱いに関して改良可能であることを認識していた。そのような変更はＪａｖａ仕様に違反するものではなく、その定義が既存のものと矛盾しない限り新規属性の定義が許されることが理解されよう。

従って、発明者らは、Ｊａｖａアプリケーションに使用される特定のリソースファイルに関するユーザー装置からのエラーレポートをＪａｖａアプリケーションのプロバイダへ返すことができる手順を開発した。セキュリティ面での理由により、当該手順が、ユーザーの装置に関する情報をアプリケーションプロバイダへ送信する前に必ずユーザーとの対話が介在することが現時点では好適である。しかし、アプリケーションを更新する前に常にユーザーに尋ねる（問う）必要がないことは理解されたい。Ｊａｖａアプリケーションが信頼できるドメイン（例：ＵＥ製造業者、ネットワークオペレータ、または特定の第三者）の一部である場合、装置が更新内容を自動的にダウンロードしてインストールすることにより自身を更新するように構成することができる。Ｊａｖａアプリケーションが信頼できないドメインの一部である場合、自動更新は許可されない。Ｊａｖａセキュリティフレームワークは、Ｊａｖａ仕様要求（ＪＳＲ）２４８に定義されている。

発明者らにより変更された属性の定義には、リソースファイル更新用のサービスポイントの生成が含まれる。当業者には、サービスポイントが、装置のユーザーまたは装置自体が非互換性を探索した場合に更新可能なリソースファイルを提供する値を有する属性であることが理解されよう。例えば、サービスポイント属性１は、以下のようにＪＡＤファイルの形式を有していてよい。

ミッドレットサービスポイント属性１：ミッドレットサービスポイント属性値１、但し左辺はサービスポイント識別子、右辺はサービスポイントのアドレスまたは他の位置識別子である。

発明者らは、サービスポイントプロバイダ属性がＪＡＤファイルでも定義でき、従ってＪａｖａアプリケーションは属性情報を用いて、定義済みのＪａｖａアプリケーションプロバイダからリソースの更新を要求できることを認識した。例えば、適当なサービスポイントプロバイダ属性１は、以下のようにＪＡＤファイルの形式であってよい。
Ｍｉｄｌｅｔ−Ｓｅｒｖｉｃｅ−Ｐｏｉｎｔ−Ａｔｔｒｉｂｕｔｅ−１：Ｍｉｄｌｅｔ−Ｓｅｒｖｉｃｅ−Ｐｏｉｎｔ−Ａｔｔｒｉｂｕｔｅ−Ｖａｌｕｅ−１

そのようなサービスポイントリソースプロバイダ属性は、関連付けられたリソースファイル属性と共に用いて、時折更新されるリソースファイルを分離し、更新対象のリソースファイルにダウンロードを絞ってアプリケーション全体のダウンロードを避けることにより、更新プロセスを合理化することができる。以下の例は、そのようなリソースプロバイダ属性および関連付けられたリソースファイル属性を示す。

実施例１：
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｐｒｏｖｉｄｅｒ−１：ｗｗｗ．ｅｒｉｃｓｓｏｎ．ｃｏｍ
Ｍｉｄｌｅｔ−Ｕｐｄａｔｅ−Ｒｅｓｏｕｒｃｅ−Ａｕｄｉｏ−１：Ａｕｄｉｏ＿Ａｌｐｈａ．ｍｐ３

実施例２：
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｐｒｏｖｉｄｅｒ−１：ｗｗｗ．ｅｒｉｃｓｓｏｎ．ｃｏｍ
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ａｕｄｉｏ−２：Ａｕｄｉｏ＿Ｂｅｔａ．ｍｐ３

実施例３：
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｐｒｏｖｉｄｅｒ−１：ｗｗｗ．ｅｒｉｃｓｓｏｎ．ｃｏｍ
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｖｉｄｅｏ−１：Ｖｉｄｅｏ＿Ｇａｍｍａ．ｊｐｅｇ

実施例４：
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｐｒｏｖｉｄｅｒ−１：ｗｗｗ．ｅｒｉｃｓｓｏｎ．ｃｏｍ
Ｍｉｄｌｅｔ−Ｕｐｇｒａｄｅ−Ｒｅｓｏｕｒｃｅ−Ｂｉｔｍａｐ−１：Ｐｉｃｔｕｒｅ＿Ｄｅｌｔａ．ｍｐ３

ＪＡＤファイルに含めることが可能な上記実施例の各々において、特定のプロバイダアドレス（上記例ではｗｗｗ．ｅｒｉｃｓｓｏｎ．ｃｏｍ）を指すサービスポイントリソースプロバイダ属性は、Ｊａｖａアプリケーション内の特定のリソースファイル（上記実施例ではＭＰ３またはＪＰＥＧファイル）を指すサービスポイントリソースファイル属性に関連付けられている。プロバイダ属性およびリソース属性がペアで提供され、そのようなペアを多数提供できる点に注意されたい。

装置のユーザーまたは装置自体が、Ｊａｖａアプリケーションの正常な実行を阻害しないエラーを探索した場合、アプリケーションは好適には実行を続けるが、適当な警告メッセージを表示して、Ｊａｖａアプリケーションプロバイダへエラー情報を送信するか否かをユーザーに尋ねることにより、ユーザーにエラーを報告する。エラー情報と共に、装置の制約（例：メモリ容量、オペレーティングシステム等）に関する情報もまたプロバイダへ送信される利点がある。ユーザーへのエラーレポートが好適には、問題になっているリソースファイルの更新可能性についてユーザーの装置にテキストメッセージ等の短いメッセージを「プッシュ」方式で返信するためにプロバイダが装置の電話番号を必要とするため、当該電話番号がＪａｖａアプリケーションプロバイダへ送信される旨をユーザーに警告する点を理解されたい。

装置のユーザーがエラーレポートを受信しなくてもリソースファイルの更新を要求できることに利点があることを理解されたい。この場合、Ｊａｖａリソースファイルは装置のＪａｖａ実行環境および制約と互換性を有するが、Ｊａｖａアプリケーションプロバイダから入手可能であればユーザーは引き続きリソースファイルの改良版をダウンロードすることができる。

上述のように、アプリケーション全体ではなく、アプリケーションリソースを更新する方法は以下のステップを含んでいてよく、これらを図１のフロー図に示す。ステップ１０２において、装置またはそのユーザーがリソース、例えば音声ファイル、ビットマップ（画像）ファイルに関する課題を探索する。課題（Ｑｕｅｓｔｉｏｎ）は、アプリケーション実行中の問題（ｐｒｏｂｌｅｍ）、またはリソースの更新を探したいユーザーの要望のいずれかの結果として生じうる。課題が問題に起因する場合、探索された問題を装置のＪａｖａ実行環境、例えばＪＭＥ等が適当な警告メッセージとしてユーザーに報告する。

ステップ１０４において、装置のＪａｖａ実行環境がユーザーに対し、探索された問題に対応するアプリケーションのプロバイダへ、利用可能な通信ネットワークを介して情報を送信するか否かを尋ねる。上述のように、適当な属性値により関連したＪＡＤファイル内で当該プロバイダのアドレスその他の居所が識別される。Ｊａｖａアプリケーションが信頼できるドメインの一部である場合、装置は、更新を自動的にダウンロードしてインストールすることにより自身を更新すべく構成できるため、ステップ１０４を破線で示している。課題がユーザーに報告されて、ユーザーがプロバイダへ連絡しない旨を選択した場合（ステップ１０４：Ｎｏ）、方法のフローは、単に戻るだけである。しかし、ユーザーがプロバイダへ連絡する旨を選択した場合（ステップ１０４：Ｙｅｓ）、プロバイダへ送信すべく適当な報告メッセージが装置により生成される（ステップ１０６）。

適切に構成された報告メッセージを、例えばＧＳＭ、汎用パケット無線システム（ＧＰＲＳ）、または第三世代（３Ｇ）セルラ電話ネットワーク、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇ／ｎ（ＷｉＦｉ）ネットワーク等、広範な通信ネットワークを介して送信することができる。報告メッセージは、Ｊａｖａアプリケーションプロバイダ−ユーザーリクエストメッセージとも呼ばれ、以下の情報要素、すなわち
ユーザーの装置とリソースファイルの間の不整合の詳細を示すエラーコード、
例えば音声、ビデオ、画像等のドメイン、
リソースファイル名、
ユーザーの装置を識別する装置名および他の特徴、
移動電話番号、ＴＣＰ／ＩＰアドレス、または装置の他の適当な識別子
を１個以上含んでいることに利点がある。

報告メッセージは、対応するＪＡＤファイル内で注目するリソースファイルに対応するサービスポイント属性を読むことに基づいて用意される。上で説明したように、サービスポイント値は、Ｊａｖａアプリケーションプロバイダを識別するアドレスであって、通常はインターネットアドレスである。

ステップ１０８において、装置は報告メッセージをネットワークおよびＪａｖａアプリケーションプロバイダへ送信する。ネットワークは報告メッセージを直接プロバイダへ転送しても、あるいはネットワークはメッセージを自身の適当なプロバイダプロキシデータベース宛てへ送信してもよい。プロキシの場合、ユーザーの要求に合致するプロキシデータベース内にリソースファイルが既に存在するならば、プロキシは当該リソースファイルをユーザーへ送信する。ネットワークプロキシによりまだ送信されていない場合、ＪａｖａアプリケーションプロバイダがＪａｖａアプリケーション用の対応リソースファイルをユーザーへ送信する。

いずれの場合も、報告メッセージに応答するリソースファイルがユーザーの装置に、例えば、移動電話番号、ＴＣＰ／ＩＰアドレス、または報告メッセージに含まれる装置の他の識別子の１個を用いて送信される。リソースは、既に確立した通信サービス、例えば、ショートメッセージサービス（ＳＭＳ）メッセージ、電子メールメッセージ、またはＷｅｂ／ＷＡＰプロトコルメッセージを介してメッセージとして送信できる。ネットワークがリソースファイルのデータベースを保持している場合、アプリケーションプロバイダにより送信されるリソースファイルをネットワークにより保存することができる。

報告メッセージへの応答を受信したならば（ステップ１１０）、装置のＪａｖａ実行環境は、受信したリソースファイルをインストールして、既存のリソースファイルを代替する。Ｊａｖａアプリケーションの実行は、既存のリソースファイルを修正版で代替するために中断する場合があり、ユーザーが選択したならばＪａｖａ実行環境は、次いでＪａｖａアプリケーションを再開することができる。

そのような更新方法は、ＧＰＲＳおよびＧＳＭエボリューション用の拡張データレート（ＥＤＧＥ）等の拡張に準拠するセルラ無線電話システム等の時分割多重アクセス（ＴＤＭＡ）、およびＩＳ−９５、ｃｄｍａ２０００、および広帯域ＣＤＭＡ（ＷＣＤＭＡ）データ通信標準に準拠するセルラ無線電話システム等の符号分割多重アクセス（ＣＤＭＡ）システム等、多くのデジタル通信システムで使用できることに利点がある。デジタル通信システムはまた、ユニバーサル移動体通信システム（ＵＭＴＳ）標準に準拠するセルラ無線電話システム等の「混合された」ＴＤＭＡおよびＣＤＭＡシステムを含んでいて、国際電気通信連合（ＩＴＵ）のＩＭＴ−２０００フレームワーク内の欧州電気通信標準化機構（ＥＴＳＩ）により開発中の３Ｇ移動体システムを指定する。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＵＭＴＳ、ＷＣＤＭＡ、およびＧＳＭ通信システムを公布している。

図２に、セルラ無線電話システム１０を表す。基地局コントローラ（ＢＳＣ）１２および無線ネットワークコントローラ（ＲＮＣ）１４は、例えば無線アクセスベアラ設定、ダイバシティハンドオーバー等、各種の無線ネットワーク機能を制御する。より一般的に、ＢＳＣおよびＲＮＣは、移動局（ＭＳ）１６と携帯電話その他の遠隔端末であるユーザー機器（ＵＥ）１８との間の接続を、ダウンリンク（すなわちＢＴＳ／ノードＢからＭＳ／ＵＥへの）、およびアップリンク（すなわちＭＳ／ＵＥからＢＴＳ／ノードＢへの）チャネルを介して各ＭＳおよびＵＥと通信する適切な基地受送信局（ＢＴＳ）およびノードＢを介して制御する。ＢＳＣ１２をＢＴＳ２０，２２に接続された状態で示し、ＲＮＣ１４をノードＢ２４，２６に接続された状態で示す。各々のＢＴＳ／ノードＢは、１個以上のセルに分割できる地理的領域にサービスを提供する。ＢＴＳ／ノードＢは、専用電話線、光ファイバリンク、マイクロ波リンク等により、対応するＢＳＣ／ＲＮＣに接続されている。ＢＳＣおよびそれが接続されているＢＴＳは一般に、図２の破線で示すように基地局システム（ＢＳＳ）を含んでいる。

ＢＳＣ１２およびＲＮＣ１４は、コアネットワーク２８内の１個以上のノードを介して公衆交換電話網（ＰＳＴＮ）、インターネット等の外部ネットワークに接続されている。図２に示すように、コアネットワーク２８は移動スイッチングセンタ（ＭＳＣ）３０、およびＧＰＲＳサポートノード（ＳＧＳＮ）３２，３４、およびゲートウェイＧＰＲＳサポートノード３６を等のパケット無線サービスノードを含んでいる。アプリケーション／リソースプロキシデータベース３８は図２に示すセルラインフラから独立できるデータリポジトリであるが、１個以上のＳＧＳＮ３２，３４にデータ（例：１個以上のリソースファイル）をキャッシュして更新性能を向上させることができる。無論、図２に示す装置が様々な名称が付されていることは理解されようが、簡潔のため本出願では端末１６，１８を共通にＵＥと呼ぶことにする。

図３は、上述の更新方法を実装可能なＵＥ１８のブロック図である。ＵＥ１８は、ネットワーク（図３に示さず）内で無線信号をＢＴＳ／ノードＢとやり取りするのに適したトランシーバ３０２を含んでいる。これらの信号により搬送される情報は、１個以上の副プロセッサを含んでいて、本出願に記述する方法を実行するべく、１個以上のソフトウエアモジュールおよびアプリケーションを実行するプロセッサ３０４により処理される。ＵＥ１８へのユーザー入力は、キーパッドその他の装置により与えられ、情報はディスプレイ３０６上でユーザーに提示することができる。組み込みモバイル機器および機器間通信モジュール等、いくつかの装置はキーパッドまたはディスプレイを必要としない場合があるため、キーパッド／ディスプレイ３０６はオプションとみなすことができるため、破線で示す。ソフトウェアアプリケーションは適当なアプリケーションメモリ３０８に保存することができ、本装置はまた、所望の情報を適当なメモリ３１０にダウンロードおよび／またはキャッシュすることができる。ＵＥ１８はまた、ＵＥ１８にコンピュータ、キーボード等、他のコンポーネントを接続すべく使用できるインターフェース３１２を含んでいてよい。

図４に、通信システム内のアプリケーションリソースを更新する方法の典型的な使用事例を示す。図４において、ユーザーがＪａｖａアプリケーションと共にリソースファイルを使用している際に、再生できない音声ファイル等のエラーを発見した。ユーザー、より具体的にはユーザーのＵＥ１８は、エラーを報告してリソースファイルの更新を求めるメッセージ４０２をネットワークオペレータ４０４へ送信する。上述のように、報告メッセージ４０２は好適には、エラーコード等、リクエストを生起させたエラーの記述、ドメイン（当該使用事例では音声）、リソースファイル名、ユーザーの装置を識別する装置名およびその他の特徴、および移動電話番号、ＴＣＰ／ＩＰアドレス、または他の適当な装置の識別子を含んでいる。図４で示すように、リクエストメッセージは、オペレータその他の受信者４０４により処理（Ｐ１）されて、必要に応じてリクエストの扱い、特に、要求されたリソースファイルをどこで取得するかを決定（Ｄ１）する。

上述のように、ネットワーク４０４は、報告メッセージまたは他の適当なメッセージ４０６をアプリケーションプロバイダ４０８に直接転送することを決定しても、またはネットワーク４０４は自身のプロバイダプロキシデータベースまたはリポジトリ３８（図４に示さず）を用いて報告メッセージを処理してもよい。ネットワークがリクエスト４０６の送信を決定した場合、当該リクエストは必要に応じてプロバイダ４０８により処理（Ｐ２）され、リクエストの扱いを決定する。この結果、図に示すように要求されたリソースファイルが適当なメッセージ４１０によりネットワークオペレータ４０４に提供される。提供されたリソースファイルメッセージ４１０は、必要に応じてネットワークオペレータ４０４により処理（Ｐ３）されて、ＵＥ１８が受信したリソースファイルを更新すべく必要に応じて処理（Ｐ４）する旨のメッセージ４１２を介してＵＥ１８にリソースファイルを提供する。ネットワークにアクセス可能なプロバイダプロキシの場合、ユーザーの要求４０２に合致するプロキシデータベース内にリソースファイルが既に存在するのであれば、ネットワーク４０４は、リソースファイルをリポジトリから取り出してユーザーへ送信するべくリクエストを処理（Ｐ３）する。いずれの場合も、報告メッセージ４０２に応答するリソースファイルは、例えば移動電話番号、ＴＣＰ／ＩＰアドレス、または報告メッセージに含まれる装置の他の識別子の１個を用いて、ユーザーの装置へ送信される。リソースは、既に確立した通信サービス、例えばＳＭＳメッセージ、電子メールメッセージ、またはＷｅｂ／ＷＡＰプロトコルメッセージ等を介してメッセージとして送信することができる。ネットワーク４０４がリソースファイルのデータベースを保持していれば、アプリケーションプロバイダ４０８により送信されたリソースファイルをネットワーク上で保存することができる。

報告メッセージ４０２がメッセージの理由、例えばユーザーがエラーを発見した旨を示すこともできるが、逆に装置がエラーを発見したという理由でもよい点を理解されたい。更に、報告メッセージ４０２は、ユーザーも装置もエラーを発見していないが、リソースファイルの更新可能性ついて問い合わせている旨を示すことができる。

当業者は、上述の手順が、例えば送信器と受信器の間で通信チャネルが時間的に変動する性質に対応すべく必要に応じて繰り返し実行される点を理解されよう。理解を容易にすべく、本発明の多くの態様は、例えばプログラム可能なコンピュータシステムの要素により実行可能な動作シーケンスの観点から記述されている。各種の動作が、専用回路（例：専用機能を実行すべく相互接続された離散論理ゲートまたは特定用途向け集積回路）により、１個以上のプロセッサにより実行されるプログラム命令により、または両者の組合せにより、実行可能であることが認識されよう。

更に、本発明はまた、コンピュータに基づくシステム、プロセッサ内蔵システム、または媒体から命令を取得して当該命令を実行可能な他のシステム等の命令実行システム、装置、または機器により、またはこれらに関連して用いられる適当な命令の組を格納している任意の形式のコンピュータ可読記憶媒体内に完全に具現化されているものと見なすことができる。本明細書で用いる「コンピュータ可読媒体」は、上記命令実行システム、装置、または機器により、またはこれらに関連して用いられるプログラムを含有、保存、送信、伝播、または搬送可能な任意の手段であってよい。コンピュータ可読媒体は例えば、電子系、磁気系、光系、電磁系、赤外線系、または半導体システム、装置、機器、または伝播媒体であってよいが、これらに限定されない。コンピュータ可読媒体のより具体的な例（非網羅的リスト）には、１個以上の導線を有する電気接続、携帯コンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、および光ファイバが含まれる。

従って、本発明は、多くの異なる形式（但しその全てを上で説明していない）において具現化可能であって、そのような形式は全て本発明の範囲内であると考えられる。本発明の各種の態様の各々について、そのような任意の形式を記述されている動作を実行すべく「構成された論理」、または代替的に記述されている動作を実行する「論理」と呼ばれてよい。

「含む」および「含んでいる」という用語を本出願で用いる場合、言及された特徴、整数、ステップ、または要素の存在を指定するが、１個以上の他の特徴、整数、ステップ、要素、またはそれらのグループの存在または追加を排除するものではない。

上述の特定の実施形態は、例示目的に過ぎず、一切限定的であると考えてはならない。本発明の範囲は、添付の請求項により決定され、請求項の範囲に含まれる全ての変更および等価物が包含されるものとする。

Claims (23)

1. 通信システム用のユーザー機器内の電子プロセッサにより実行可能なＪａｖａソフトウェアアプリケーションに使用されるリソースファイルを更新する方法であって、
   前記リソースファイルから生じるエラーを探索するステップであって、前記エラーはＪａｖａソフトウェアアプリケーションの実行エラーである、ステップと、
   前記エラーを有する前記リソースファイルに対応するアプリケーションのプロバイダであって、前記プロバイダのアドレスを示すプロバイダ属性と前記リソースファイルを示すリソース属性とを関連付ける記述子ファイルにより識別されるプロバイダへ、利用可能な通信ネットワークを介して送信するために報告メッセージを形成するステップと、
   前記報告メッセージを送信するステップと、
   前記報告メッセージに応答してリソースファイルを前記ユーザー機器において受信するステップと、
   前記エラーを修正するために前記受信したリソースファイルを前記ユーザー機器にインストールするステップと、を含む方法。
2. 前記リソースファイルは、音声ファイル、画像ファイル、またはビデオファイルである、請求項１に記述の方法。
3. 前記探索するステップは、アプリケーション実行中の問題に応答して実行される、請求項１に記載の方法。
4. 前記エラーを警告メッセージとしてユーザーに報告するステップと、前記アプリケーションのプロバイダへ前記報告メッセージを送信するか否かをユーザーに尋ねるステップとを更に含む、請求項１に記載の方法。
5. 前記報告メッセージは、前記ユーザー機器と前記リソースファイルとの不整合の詳細を示すエラーコード、リソースファイルのドメイン、リソースファイル名、前記ユーザー機器を識別する特徴、および前記ユーザー機器の識別子の少なくとも１つを含む、請求項１に記載の方法。
6. 前記報告メッセージを形成するステップは、前記対応する記述子ファイル内で、前記リソースファイルに対応する前記プロバイダのアドレスを読み込むステップを含む、請求項１に記載の方法。
7. 前記報告メッセージを送信するステップは、前記報告メッセージを前記プロバイダへ転送するステップ、または前記報告メッセージを前記通信ネットワーク内のプロキシデータベースへ送信するステップを含む、請求項１に記載の方法。
8. 前記受信したリソースファイルをインストールするステップは、前記ソフトウェアアプリケーションの実行を中断するステップと、前記受信したリソースファイルを用いて前記ソフトウェアアプリケーションの実行を再開するステップとを含む、請求項１に記載の方法。
9. 通信システム用のユーザー機器内の電子プロセッサにより実行可能なＪａｖａソフトウェアアプリケーションに使用されるリソースファイルを更新する装置であって、
   前記リソースファイルから生じるエラーであって、前記Ｊａｖａソフトウェアアプリケーションの実行エラーであるエラーを探索し、
   前記エラーを有する前記リソースファイルに対応するアプリケーションのプロバイダであって、前記プロバイダのアドレスを示すプロバイダ属性と前記リソースファイルを示すリソース属性とを関連付ける記述子ファイルにより識別されるプロバイダへ、利用可能な通信ネットワークを介して送信するための報告メッセージを形成し、
   前記ユーザー機器に前記報告メッセージを送信させ、
   前記報告メッセージに応答して受信されたリソースファイルを前記ユーザー機器にインストールするように構成されたプロセッサを含む装置。
10. 前記リソースファイルは、音声ファイル、画像ファイル、またはビデオファイルである、請求項９に記載の装置。
11. 前記プロセッサは、アプリケーション実行中の問題に応答して前記リソースファイルに関する課題を探索するように構成されている、請求項９に記載の装置。
12. 前記プロセッサは、前記エラーを警告メッセージとしてユーザーに報告し、前記アプリケーションの前記プロバイダへ前記報告メッセージを送信するか否かをユーザーに尋ねるべく更に構成されている、請求項９に記載の装置。
13. 前記報告メッセージは、前記ユーザー機器と前記リソースファイルとの不整合の詳細を示すエラーコード、リソースファイルのドメイン、リソースファイル名、前記ユーザー機器を識別する特徴、および前記ユーザー機器の識別子の少なくとも１つを含む、請求項９に記載の装置。
14. 前記プロセッサは、前記対応する記述子ファイル内で、少なくとも前記リソースファイルに対応する前記プロバイダのアドレスを読み込むことにより、前記報告メッセージを形成するように構成されている、請求項９に記載の装置。
15. 前記プロセッサは、少なくとも前記ソフトウェアアプリケーションの実行を中断し、前記受信したリソースファイルを用いて前記ソフトウェアアプリケーションの実行を再開することによって、前記受信したリソースファイルをインストールするように構成されている、請求項９に記載の装置。
16. 実行時に、通信システム用のコンピュータ内の電子プロセッサにより実行可能なＪａｖａソフトウェアアプリケーションに使用されるリソースファイルを更新する方法をコンピュータに実行させる命令が格納されているコンピュータ可読媒体であって、前記方法が、
    前記リソースファイルから生じるエラーを探索するステップであって、前記エラーはＪａｖａソフトウェアアプリケーションの実行エラーである、ステップと、
    前記エラーを有する前記リソースファイルに対応する前記アプリケーションのプロバイダであって、前記プロバイダのアドレスを示すプロバイダ属性と前記リソースファイルを示すリソース属性とを関連付ける記述子ファイルにより識別されるプロバイダへ、利用可能な通信ネットワークを介して送信すべく報告メッセージを形成するステップと、
    前記報告メッセージを送信するステップと、
    前記報告メッセージに応答してリソースファイルを前記コンピュータにおいて受信するステップと
    前記受信したリソースファイルを前記コンピュータにインストールするステップと、を含む媒体。
17. 前記リソースファイルは、音声ファイル、画像ファイル、またはビデオファイルである、請求項１６に記載の媒体。
18. 前記探索するステップは、アプリケーション実行中の問題に応答して実行される、請求項１６に記載の媒体。
19. 前記方法は、前記エラーを警告メッセージとしてユーザーに報告するステップと、前記アプリケーションのプロバイダへ前記報告メッセージを送信するか否かをユーザーに尋ねるステップとを更に含む、請求項１６に記載の媒体。
20. 前記報告メッセージは、前記コンピュータと前記リソースファイルとの不整合の詳細を示すエラーコード、リソースファイルのドメイン、リソースファイル名、前記コンピュータを識別する特徴、および前記コンピュータの識別子の少なくとも１つを含む、請求項１６に記載の媒体。
21. 前記報告メッセージを形成するステップは、前記対応する記述子ファイル内で、前記リソースファイルに対応する前記プロバイダのアドレスを読み込むステップを含む、請求項１６に記載の媒体。
22. 前記報告メッセージを送信するステップは、前記報告メッセージを前記プロバイダへ転送するステップ、または前記報告メッセージを前記通信ネットワーク内のプロキシデータベースへ送信するステップを含む、請求項１６に記載の媒体。
23. 前記受信したリソースファイルをインストールするステップは、前記ソフトウェアアプリケーションの実行を中断するステップと、前記受信したリソースファイルを用いて前記ソフトウェアアプリケーションの実行を再開するステップとを含む、請求項１６に記載の媒体。

Images