(57)【要約】【課題】移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供する。【解決手段】ソフトウエア配信システムは、移動端末からサービス追加要求メッセージを受信する。このメッセージには、移動端末のスペックを表す端末プロファイルが含まれている。ソフトウエア配信システムは、端末プロファイルに基づいて基本ソフトウエア（ソースプログラムなど）を変換して、移動端末のスペックに合わせて最適化されたサービス実現ソフトウエアを生成し、これを移動端末に送信する。【選択図】  図７
2004362090.tif 000002
【特許請求の範囲】
【請求項１】
基本ソフトウエアを記憶しているソフトウエア記憶手段と、
移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信する要求受信手段と、
受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成する生成手段と、
生成された特定ソフトウエアを移動端末に配信する配信手段と、
を有する移動端末向けソフトウエア配信システム。
【請求項２】
基本ソフトウエアは引数を変えてコンパイルすることにより移動端末の種々のスペックまたは／および使用状態に対応可能なソースプログラムまたは中間プログラムであり、
生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な引数で基本ソフトウエアをコンパイルする請求項１記載の移動端末向けソフトウエア配信システム。
【請求項３】
基本ソフトウエアは設定ファイルにより移動端末の種々のスペックまたは／および使用状態に対応可能な汎用ソフトウエアであり、
生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な設定ファイルを作成する請求項１記載の移動端末向けソフトウエア配信システム。
【請求項４】
配信可能なソフトウエアの一覧を移動端末に通知する一覧通知手段をさらに有する請求項１〜３のうちいずれか１項記載の移動端末向けソフトウエア配信システム。
【請求項５】
端末プロファイルは、移動端末のスペックとして、画面解像度、グラフィック性能、ＣＰＵ性能、および、記憶媒体の空き容量のうち少なくとも１つを含む請求項１〜４のうちいずれか１項記載の移動端末向けソフトウエア配信システム。
【請求項６】
端末プロファイルは、移動端末の使用状態として処理負荷を含む請求項１〜５のうちいずれか１項記載の移動端末向けソフトウエア配信システム。
【請求項７】
受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断する判断手段と、
リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるリソース制御手段と、
をさらに有する請求項６記載の移動端末向けソフトウエア配信システム。
【請求項８】
リソースを割り当て不可と判断された場合に、特定ソフトウエアの動作品質を保証するために割り当てるべきリソースを移動端末に通知するリソース通知手段をさらに有する請求項７記載の移動端末向けソフトウエア配信システム。
【請求項９】
ソフトウエア配信システムに対してソフトウエア配信要求を送信する手段と、
ソフトウエア配信システムから、配信要求したソフトウエアの動作品質を保証するために割り当てるべきリソースを受信する手段と、
現在実行中のサービスのうちどのサービスを停止させれば上記リソースを確保できるか判断する手段と、
その判断結果をユーザに通知する手段と、
を有する移動端末。
【請求項１０】
コンピュータシステムが、
基本ソフトウエアを記憶するステップと、
移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信するステップと、
受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成するステップと、
生成された特定ソフトウエアを移動端末に配信するステップと、
を含む移動端末向けソフトウエア配信方法。
【請求項１１】
コンピュータシステムが、
基本ソフトウエアを記憶するステップと、
移動端末から、ソフトウエア配信要求と共に、移動端末のスペックおよび処理負荷を表す端末プロファイルを受信するステップと、
受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックに合わせて最適化された特定ソフトウエアを生成するステップと、
受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断するステップと、
リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるステップと、
生成された特定ソフトウエアを移動端末に配信するステップと、
を含む移動端末向けソフトウエア配信方法。
【請求項１２】
コンピュータシステムに、
基本ソフトウエアを記憶するステップと、
移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信するステップと、
受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成するステップと、
生成された特定ソフトウエアを移動端末に配信するステップと、
を実行させる移動端末向けソフトウエア配信プログラム。
【請求項１３】
コンピュータシステムに、
基本ソフトウエアを記憶するステップと、
移動端末から、ソフトウエア配信要求と共に、移動端末のスペックおよび処理負荷を表す端末プロファイルを受信するステップと、
受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックに合わせて最適化された特定ソフトウエアを生成するステップと、
受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断するステップと、
リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるステップと、
生成された特定ソフトウエアを移動端末に配信するステップと、
を実行させる移動端末向けソフトウエア配信プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、車載端末などの移動端末に対してソフトウエアを配信する技術に関する。
【０００２】
【従来の技術】
携帯電話やＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙ−ｐｈｏｎｅ  Ｓｙｓｔｅｍ）を利用してインターネットに接続可能な移動端末が登場している。最近では、ＤＳＲＣ（Ｄｅｄｉｃａｔｅｄ  Ｓｈｏｒｔ  Ｒａｎｇｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）や無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの狭域無線通信を利用した移動端末向けの狭域通信サービスの検討も始まっている。
【０００３】
この種の移動端末では、インターネット上のソフトウエア配信システムにアクセスし、ソフトウエアをダウンロードすることで、新たな機能を追加することが可能となる。移動端末にソフトウエアを配信するシステムとしては、特許文献１、２などが提案されている。
【０００４】
【特許文献１】
特開２００３−８７８３７号公報
【特許文献２】
特開２００３−６５７８５号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、移動端末は、一般に携帯性を重視した構成となっており、ＣＰＵ性能、画面解像度、グラフィック性能、メモリやハードディスクの容量などは通常のパーソナルコンピュータに比べて貧弱であることが多い。したがって、移動端末のスペックや使用状態（リソース容量など）に応じたソフトウエアをダウンロードしなければ、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないこともある。
【０００６】
特に、車両に設置された車載端末にあっては、この問題が顕著となる。車載端末は、車両に設置されるという構成上、モバイルパソコンなどの移動端末に比べてスペックやリソース容量の制限が大きいこと、また、買い換え周期が長く、古いスペックの端末がいつまでも使用され続ける可能性が高いこと、などがその理由である。しかも、新たに追加したソフトウエアにより、車両の運転に必要な他の機能（たとえば、ナビゲーション機能やラジオ機能など）の動作が阻害されては、運転に支障がでるおそれもある。
【０００７】
とはいえ、移動端末の個々のスペックや使用状態に合わせて、網羅的に何十〜何百種類ものバージョンのソフトウエアを予め用意しておくとすれば、ソフトウエア配信システム側に膨大なディスクスペースが必要となるため、とても現実的ではない。
【０００８】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、移動端末上で最適な動作を保証し得るソフトウエアを配信可能な技術を提供することにある。
【０００９】
【課題を解決するための手段】
上記目的を達成するために本発明のソフトウエア配信システムは、以下の手段ないし手順により移動端末にソフトウエアを配信する。なお、ソフトウエア配信処理に係る以下の手段ないし手順は、プログラムがコンピュータシステムに読み込まれ実行されることにより具体的に実現されるものである。
【００１０】
ソフトウエア配信システムは、ソフトウエア記憶手段によって、基本ソフトウエアを記憶している。ここで、基本ソフトウエアとは、引数を変えてコンパイルすることにより移動端末の種々のスペックまたは／および使用状態に対応可能なソースプログラムまたは中間プログラムであるか、あるいは、設定ファイルにより移動端末の種々のスペックまたは／および使用状態に対応可能な汎用ソフトウエアである。
【００１１】
ソフトウエア配信システムは、要求受信手段によって、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信する。
【００１２】
端末プロファイルに含まれる移動端末のスペックとしては、画面解像度、グラフィック性能、ＣＰＵ性能、記憶媒体の空き容量などの情報が考えられ、また、移動端末の使用状態としては、処理負荷などの情報が考えられる。端末プロファイルにいずれの情報を含めるかは、システム構成などに応じて適宜変更可能である。
【００１３】
そして、ソフトウエア配信システムは、生成手段によって、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成する。
【００１４】
たとえば、基本ソフトウエアがソースプログラムまたは中間プログラムの場合には、生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な引数で基本ソフトウエアをコンパイルするとよい。
【００１５】
一方、基本ソフトウエアが汎用ソフトウエアの場合には、生成手段は端末プロファイルに基づいて移動端末のスペックまたは／および使用状態に最適な設定ファイルを作成するとよい。
【００１６】
そして、ソフトウエア配信システムは、配信手段によって、生成された特定ソフトウエアを移動端末に配信すればよい。
【００１７】
このような構成によれば、ソフトウエア配信システムでは、１つないし少数の基本ソフトウエアを保有しておけば足りるので、移動端末の個々のスペックなどに合わせて数多くのバージョンのソフトウエアを用意しておく必要がなくなり、ディスクスペースの削減、ひいては、システムコストの削減を図ることができる。
【００１８】
また、基本ソフトウエアから移動端末のスペックや使用状態に合致した最適な特定ソフトウエアを得ることができ、移動端末上で最適な動作を保証し得るソフトウエアを配信することが可能となる。
【００１９】
ソフトウエア配信システムは、一覧通知手段によって、配信可能なソフトウエアの一覧を移動端末に通知することも好ましい。ソフトウエアの一覧を閲覧することにより、移動端末のユーザは追加可能なソフトウエアを知ることができるので、システムの利便性が向上する。
【００２０】
また、ソフトウエア配信システムは、判断手段によって、受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断することも好ましい。これにより、特定ソフトウエアを配信する前に、移動端末上で特定ソフトウエアを実用的に動作させることが可能か、さらには、特定ソフトウエアが移動端末上で現在動作中の他のソフトウエアの動作を阻害することがないか、などを確認し配信処理に活用することができる。
【００２１】
ここで、リソースを割り当て可能と判断された場合に、リソース制御手段によって、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させることも好ましい。たとえば、特定ソフトウエアの動作に必要なＣＰＵリソースやメモリリソースを確保させることによって、特定ソフトウエアの実用的な動作品質を保証することができる。
【００２２】
逆に、リソースを割り当て不可と判断された場合には、リソース通知手段によって、特定ソフトウエアの動作品質を保証するために割り当てるべきリソースを移動端末に通知することも好ましい。たとえば、特定ソフトウエアの動作に必要なＣＰＵリソースやメモリリソースを移動端末に通知すれば、移動端末のユーザはその情報に基づいて、現在動作中のソフトウエアを終了させてリソースを解放したりすることが可能となる。
【００２３】
なお、本発明は、上記手段の少なくとも一部を有する移動端末向けソフトウエア配信システムとして捉えることができる。また、本発明は、上記手順の少なくとも一部を含む移動端末向けソフトウエア配信方法、または、かかる方法を実現するためのプログラムとして捉えることもできる。さらに、本発明は、上記ソフトウエア配信システムを利用する移動端末として捉えることもできる。なお、上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【００２４】
たとえば、本発明の一態様としての移動端末向けソフトウエア配信システムは、基本ソフトウエアを記憶しているソフトウエア記憶手段と、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信する要求受信手段と、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成する生成手段と、生成された特定ソフトウエアを移動端末に配信する配信手段と、を有することが好ましい。
【００２５】
また、本発明の一態様としての移動端末向けソフトウエア配信システムは、基本ソフトウエアを記憶しているソフトウエア記憶手段と、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックおよび処理負荷を表す端末プロファイルを受信する要求受信手段と、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックに合わせて最適化された特定ソフトウエアを生成する生成手段と、受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断する判断手段と、リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるリソース制御手段と、生成された特定ソフトウエアを移動端末に配信する配信手段と、を有することも好ましい。
【００２６】
また、本発明の一態様としての移動端末は、ソフトウエア配信システムに対してソフトウエア配信要求を送信する手段と、ソフトウエア配信システムから、配信要求したソフトウエアの動作品質を保証するために割り当てるべきリソースを受信する手段と、現在実行中のサービスのうちどのサービスを停止させれば上記リソースを確保できるか判断する手段と、その判断結果をユーザに通知する手段と、を有することが好ましい。
【００２７】
また、本発明の一態様としての移動端末向けソフトウエア配信方法では、コンピュータシステムが、基本ソフトウエアを記憶するステップと、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信するステップと、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成するステップと、生成された特定ソフトウエアを移動端末に配信するステップと、を含むことが好ましい。
【００２８】
また、本発明の一態様としての移動端末向けソフトウエア配信方法では、コンピュータシステムが、基本ソフトウエアを記憶するステップと、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックおよび処理負荷を表す端末プロファイルを受信するステップと、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックに合わせて最適化された特定ソフトウエアを生成するステップと、受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断するステップと、リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるステップと、生成された特定ソフトウエアを移動端末に配信するステップと、を含むことも好ましい。
【００２９】
また、本発明の一態様としての移動端末向けソフトウエア配信プログラムでは、コンピュータシステムに、基本ソフトウエアを記憶するステップと、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックまたは／および使用状態を表す端末プロファイルを受信するステップと、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックまたは／および使用状態に合わせて最適化された特定ソフトウエアを生成するステップと、生成された特定ソフトウエアを移動端末に配信するステップと、を実行させることが好ましい。
【００３０】
また、本発明の一態様としての移動端末向けソフトウエア配信プログラムでは、コンピュータシステムに、基本ソフトウエアを記憶するステップと、移動端末から、ソフトウエア配信要求と共に、移動端末のスペックおよび処理負荷を表す端末プロファイルを受信するステップと、受信された端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末のスペックに合わせて最適化された特定ソフトウエアを生成するステップと、受信された端末プロファイルに基づいて、移動端末が特定ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断するステップと、リソースを割り当て可能と判断された場合に、移動端末に特定ソフトウエアの動作品質を保証し得るだけのリソースを確保させるステップと、生成された特定ソフトウエアを移動端末に配信するステップと、を実行させることも好ましい。
【００３１】
【発明の実施の形態】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００３２】
（第１の実施形態）
図１は、本発明の一実施形態に係るソフトウエア配信システムの構成を示す図である。
【００３３】
ソフトウエア配信システム１は、移動端末２に対してソフトウエアを配信し、移動端末２の機能追加を行うシステムである。ソフトウエア配信システム１は、広域ネットワークであるインターネット３に接続されており、インターネット３を介して移動端末２とデータの送受信を行う。
【００３４】
ソフトウエア配信システム１が対象とする移動端末２には、車載端末、モバイルパソコン、情報携帯端末（ＰＤＡ）、携帯電話などが含まれる。図１では、移動体である車両２０に設置され、ＤＳＲＣもしくは無線ＬＡＮの基地局４を介してインターネット３に接続する車載端末２ａと、やはり車両２０に設置され、携帯電話基地局５を介してインターネット３に接続する車載端末２ｂと、携帯電話基地局５を介してインターネット３に接続する情報携帯端末２ｃとが例示されている。このように、移動端末２の種類は多岐にわたり、個々の端末によってスペックや使用状態が異なる。
【００３５】
本実施形態のソフトウエア配信システム１では、センター１０が移動端末２のスペックなどに合わせて最適なソフトウエアを生成し、配信する処理を行う。ここで、配信するソフトウエアの元となる基本ソフトウエアは、ソフトウエア記憶手段である基本ソフトウエアＤＢ（データベース）１１が記憶し管理している。
【００３６】
基本ソフトウエアＤＢ１１には、移動端末上で種々のサービス機能を実現するためのソフトウエアが格納されている。サービス機能としては、たとえば、ナビゲーション機能、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｎ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などが想定される。基本ソフトウエアＤＢ１１では、これらのサービス機能を実現するソフトウエアを、ソースプログラム、中間プログラム、汎用ソフトウエアなどの基本ソフトウエアの形式で記憶している。
【００３７】
基本ソフトウエアとしてのソースプログラムや中間プログラムは、移動端末２が採り得るスペックや使用状態を考慮して冗長的かつ汎用的にコーディングされている。センター１０がソースプログラムや中間プログラムをコンパイル引数やリンク引数を変えてコンパイルすることで、移動端末２のスペックや使用状態に合わせて最適化された特定プログラムを生成することができる。
【００３８】
また、基本ソフトウエアとしての汎用ソフトウエアは、移動端末２が採り得るスペックや使用状態を考慮して冗長的かつ汎用的な機能を有している。通常は、動作オプションなどが記述された設定ファイルとセットで用いられる。汎用ソフトウエアはその起動時などに設定ファイルを読み込み、それにしたがって動作態様を切り替え可能に作成されている。センター１０は、移動端末２のスペックや使用状態に合わせて汎用ソフトウエアの動作態様が最適化されるように、設定ファイルを生成することができる。
【００３９】
ソフトウエア配信システム１の各機能は、基本ハードウエアとして、ＣＰＵ（中央演算処理装置）、メモリ、ハードディスク、通信ＩＦ（インターフェース）などを備える汎用のコンピュータシステムにおいて、ハードディスクに記憶されたプログラムがＣＰＵに読み込まれ実行されることにより実現されるものである。センター１０と基本ソフトウエアＤＢ１１は一台のコンピュータにより構成することもできるし、ネットワークで接続された複数台のコンピュータで構成することもできる。
【００４０】
次に、ソフトウエア配信システム１の各機能の具体的な構成および処理の流れについて詳しく説明する。
【００４１】
センター１０は、配信可能なソフトウエアの一覧を移動端末２に通知する一覧通知手段として機能する。センター１０では、図２のフローチャートに示すプロセスが常に動作しており、移動端末２から「サービス確認メッセージ」を受信すると（ステップＳ１）、その移動端末２に「サービス一覧メッセージ」を送信する（ステップＳ２）。サービス一覧メッセージは、たとえば、ナビゲーション機能、ＶｏＩＰ機能、インターネットラジオ機能、インターネットテレビ機能、通信カラオケ機能などのサービス機能の名称がリストになっている情報である。ここでセンター１０は、「サービス一覧メッセージ」を作成するため、基本ソフトウエアＤＢ１１に問い合せてもよい。
【００４２】
図３（ａ）〜（ｃ）は、移動端末２のユーザが追加機能を選択する際の処理シーケンスを表している。移動端末２は、（ａ）〜（ｃ）のうちいずれのシーケンスを用いてもよい。
【００４３】
（ａ）のシーケンスでは、移動端末２が、一定時間ごとにセンター１０に「サービス確認メッセージ」を送信し、「サービス一覧メッセージ」を受け取ることで、常に最新のサービス機能一覧を保有している。そして、ユーザから「機能確認メッセージ」を受け取ったときに、サービス機能一覧を画面に表示する。ユーザは、一覧を閲覧することにより、追加可能なソフトウエアを知ることでできるので、システムの利便性が向上する。ユーザがサービス機能一覧画面において追加機能を選択すると、移動端末２に「機能追加メッセージ」が入力されることになる。
【００４４】
（ｂ）のシーケンスでは、ユーザから「機能確認メッセージ」の入力があったときに、移動端末２がセンター１０にサービス機能一覧を取得しにいく。このシーケンスでは、移動端末２とセンター１０の間の通信が必要なときにしか行われないため、通信コストを削減することができるという利点がある。通信ＩＦとして従量制の携帯電話を用いている場合には、通信コストを抑えることのできる（ｂ）のシーケンスを利用することが好ましい。
【００４５】
（ｃ）のシーケンスでは、（ａ）のシーケンスと同様、移動端末２が自動的にサービス機能一覧を更新する。そして、新しいサービス機能を見つけた場合に、移動端末２からユーザに対してサービス機能一覧が表示される。このシーケンスでは、ユーザが明示的に機能確認を行わなくても新しいサービス機能の一覧が表示されるので、操作性が向上する。
【００４６】
上記（ａ）〜（ｃ）のうちいずれかのシーケンスによって、ユーザから「機能追加メッセージ」が入力された後の処理について、図４〜図７を参照して説明する。図４は、ソフトウエア配信処理のシーケンスを表すタイミングチャートであり、図５は、サービス追加要求メッセージのデータ構造を表す図であり、図６は、ソフトウエア配信処理に係る移動端末側の処理を表すフローチャートであり、図７は、ソフトウエア配信処理に係るセンター側の処理を表すフローチャートである。
【００４７】
移動端末２は、ユーザから「機能追加メッセージ」の入力を受けると（ステップＳ１０）、「サービス追加要求メッセージ」を生成し、センター１０に送信する（ステップＳ１１）。そして、サービス実現ソフトウエアを受信するまで待機する（ステップＳ１２）。
【００４８】
「サービス追加要求メッセージ」は、図５に示すように、ソフトウエア配信要求である「要求サービス」と、移動端末２のスペックである「画面解像度」、「グラフィック性能」、「ＣＰＵ性能」、「記憶媒体空き容量」などを含む「端末プロファイル」とから構成される。「要求サービス」には、サービス機能を一意に特定可能な識別記号などが記述される。
【００４９】
センター１０は、移動端末２から「サービス追加要求メッセージ」を受信すると（ステップＳ２０）、要求サービスに対応した基本ソフトウエアを基本ソフトウエアＤＢ１１から取得する（ステップＳ２１）。たとえば、要求サービスとして「ナビゲーション機能」が指定された場合には、ナビゲーション機能を実現するための基本ソフトウエアとして、ソースプログラム、中間プログラムもしくは汎用ソフトウエア、または、それらの組み合わせが取り出される。
【００５０】
続いて、センター１０は、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末２に配信するためのサービス実現ソフトウエアを生成する（ステップＳ２２）。
【００５１】
基本ソフトウエアがソースプログラムや中間プログラムの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適なコンパイル引数やリンク引数で基本ソフトウエアをコンパイルする。また、汎用ソフトウエアの場合には、センター１０は、端末プロファイルに含まれる移動端末２の各種スペックを参照し、それらのスペックに合致した最適な設定ファイルを生成するのである。これにより、汎用的な基本ソフトウエアから、移動端末のスペックに合わせて最適化された特定ソフトウエア（サービス実現ソフトウエア）を得ることができる。
【００５２】
ここでいう最適化とは、たとえば、サービス実現ソフトウエアの表示画面のサイズが移動端末２の「画面解像度」よりも小さくなるようにしたり、移動端末２の「グラフィック性能」が低い場合には表示画面の色数や画像を削減したり、「ＣＰＵ性能」が低い場合や「記憶媒体空き容量」が少ない場合には機能の一部を削ってライトバージョンのソフトウエアを構成したりすることをいう。
【００５３】
センター１０は、このようにして生成されたサービス実現ソフトウエアを、移動端末２に送信する（ステップＳ２３）。このとき、サービス実現ソフトウエアが利用する設定ファイルも併せて送信する。
【００５４】
移動端末２では、センター１０からサービス実現ソフトウエアを受信すると（ステップＳ１２）、それの組み込み（インストール）を実行する（ステップＳ１３）。そして、組み込みが完了すると、「機能追加完了メッセージ」を画面表示してユーザに通知する（ステップＳ１４）。
【００５５】
本実施形態のソフトウエア配信システム１では、１つないし少数の汎用的な基本ソフトウエアを保有しておけば足りるので、移動端末２の個々のスペックなどに合わせて数多くのバージョンのソフトウエアを用意しておく必要がなくなり、ディスクスペースの削減、ひいては、システムコストの削減を図ることができる。
【００５６】
また、基本ソフトウエアから移動端末２のスペックに合致した最適なサービス実現ソフトウエアを得ることができ、移動端末２上で最適な動作を保証し得るソフトウエアを配信することが可能となる。
【００５７】
すなわち、従来システムでは、新たなソフトウエアをダウンロードしインストールしても、動作しなかったり、あるいは、動作が遅すぎて実用に耐えないという問題が発生することがあったのに対し、本実施形態のシステムでは、移動端末２のスペックに合わせて最適化されたソフトウエアが自動的に生成・配信されるので、必ず最適な動作品質が保証されるのである。
【００５８】
（第２の実施形態）
次に、本発明の第２の実施形態に係るソフトウエア配信システムについて説明する。
【００５９】
上記第１の実施形態では、端末プロファイルとして移動端末のスペックに関する情報のみを受信していたが、本実施形態では、図８に示すように移動端末のスペックに加えて移動端末の使用状態に関する情報（処理負荷）も受信する。「処理負荷」は、移動端末のＣＰＵ使用量やリソース使用量などを表す情報である。そして、本実施形態では、この端末プロファイルに基づいて、移動端末がサービス実現ソフトウエアの動作品質を保証し得るだけのリソースを割り当て可能か否かを判断し、その判断結果に応じて配信処理を制御する。
【００６０】
なお、それ以外の部分については上記第１の実施形態とほぼ同様であるので、ここでは本実施形態に特徴的な処理内容について詳しく説明し、第１の実施形態と重複する部分については説明を省略する。
【００６１】
図９は、ソフトウエア配信処理に係るセンター側の処理を表すフローチャートである。
【００６２】
センター１０は、移動端末２から「サービス追加要求メッセージ」を受信すると（ステップＳ３０）、そのメッセージに含まれる端末プロファイルに基づいて移動端末２が要求のあったサービスを享受可能か否か判断する（ステップＳ３１）。詳しくは、センター１０は、端末プロファイルから移動端末の処理負荷およびスペックを抽出し、それらの情報に基づいて、移動端末２がサービス実現ソフトウエアの動作品質を保証し得るだけのリソース（ＣＰＵリソースやメモリリソースなど）を割り当てることができるかどうかを判断するのである。
【００６３】
移動端末２の処理負荷が小さく、ＣＰＵリソースやメモリリソースに十分な余裕がある場合には、問題なくサービス実現ソフトウエアを動作させることができるであろうし、逆に、移動端末２の処理負荷が高く、サービス実現ソフトウエアに対してＣＰＵリソースやメモリリソースを割り当てるだけの余裕がない場合もある。後者の場合には、サービス実現ソフトウエアを移動端末２に配信したとしても、動作品質を保証できないばかりか、現在実行中の他のソフトウエアの動作に支障をきたすおそれもある。
【００６４】
そこで、センター１０は、リソース割り当て可能と判断された場合のみサービス実現ソフトウエアの配信処理に移行する。まず、センター１０は、「リソース制御メッセージ」を生成する（ステップＳ３２）。「リソース制御メッセージ」は、サービス実現ソフトウエアの動作品質を保証するために確保すべきリソースが記述された情報である。たとえば、「ＣＰＵリソースをＮｍｓｅｃに１回Ｍｍｓｅｃ割り当てる」、「メモリリソースをＸｋｂｙｔｅ割り当てる」などの情報が記述されている。そして、センター１０は、リソース制御メッセージを移動端末２に送信して、必要なリソースを移動端末２に事前に確保させるのである（ステップＳ３３）。
【００６５】
その後、センター１０は、サービス実現ソフトウエアの配信処理を実行する（ステップＳ３４）。この処理は、図７のフローチャートにおけるステップＳ２１〜Ｓ２３の処理と同様の内容である。
【００６６】
一方、ステップＳ３１において、リソース割り当て不可と判断された場合には、センター１０は配信処理を実行せず、「サービス不能メッセージ」を移動端末２に送信する（ステップＳ３５）。続いて、センター１０は、「サービス享受要求仕様メッセージ」を生成し（ステップＳ３６）、移動端末２に送信する（ステップＳ３７）。
【００６７】
「サービス享受要求仕様メッセージ」は、サービス実現ソフトウエアの動作品質を保証するために割り当てるべきリソースに関する情報である。たとえば、図１０に示すように、サービス機能名称、処理負荷（割り当てるべきＣＰＵリソースやメモリリソースなど）、グラフィック性能（割り当てるべきグラフィックメモリなど）、記憶媒体空き容量（組み込みに必要なディスクスペース）などを含んでいる。移動端末２側では、サービス享受要求仕様メッセージの通知を受けることで、サービス機能の追加を断念するか、あるいは、現在実行中の他のソフトウエアを終了したり削除したりして新たなサービス機能のためのリソースを確保するか、などの判断を行うことができる。
【００６８】
では、タイミングチャートを参照して、リソース割り当て可能な場合とリソース割り当て不可の場合のそれぞれの処理シーケンスについて説明する。
【００６９】
図１１は、リソース割り当て可能な場合のソフトウエア配信処理のシーケンスを表すタイミングチャートである。
【００７０】
移動端末２は、定期的に自身の端末プロファイルを更新している。この処理は、たとえば図１２に示すプロセスによって行うことができる。まず、現在の時刻を「ｔｉｍｅＦｌａｇ」に代入し（ステップＳ４０）、次に、「ｔｉｍｅＦｌａｇ」の値と現在の時刻との差分が所定の値以上になるまで、すなわち、一定の時間が経過するまでループを行う（ステップＳ４１）。一定の時間が経過したら、移動端末２は、ＣＰＵリソースやメモリリソースなどの処理負荷を取得し、端末プロファイルを更新する（ステップＳ４２）。
【００７１】
移動端末２は、ユーザから「機能追加メッセージ」の入力を受けると、「サービス追加要求メッセージ」を生成し、センター１０に送信する。
【００７２】
センター１０は、端末プロファイルに基づいて移動端末２のサービス享受可否判断、つまり、リソースの割り当てが可能か否かを判断する。ここでは、リソース割り当て可能と判断され、「リソース制御メッセージ」が生成され、移動端末２に送信される。
【００７３】
移動端末２は、「リソース制御メッセージ」を受信すると、それにしたがってリソース制御を実行し、サービス実現ソフトウエアの動作品質を保証する。
【００７４】
センター１０では、端末プロファイルに基づいて基本ソフトウエアを変換して、移動端末２のスペックおよび使用状態に合わせて最適化されたサービス実現ソフトウエアを生成し、移動端末２に配信する。
【００７５】
移動端末２では、サービス実現ソフトウエアの組み込みが行われ、「機能追加完了メッセージ」が表示される。
【００７６】
一方、図１３は、リソース割り当て不可の場合のソフトウエア配信処理のシーケンスを表すタイミングチャートである。また、図１４は、この場合の移動端末側の処理を表すフローチャートである。
【００７７】
移動端末２は、ユーザから「機能追加メッセージ」の入力を受けると（ステップＳ５０）、「サービス追加要求メッセージ」を生成し、センター１０に送信する（ステップＳ５１）。
【００７８】
移動端末２から「サービス追加要求メッセージ」を受信すると、センター１０では、端末プロファイルに基づいて移動端末２のサービス享受可否判断、つまり、リソースの割り当てが可能か否かを判断する。ここでは、リソース割り当て不可と判断され、移動端末２に対して「サービス不能メッセージ」と「サービス享受要求仕様メッセージ」とが送信される。なお、「サービス不能メッセージ」と「サービス享受要求仕様メッセージ」は１つのメッセージにまとめても構わない。
【００７９】
移動端末２は、「サービス不能メッセージ」と「サービス享受要求仕様メッセージ」とを受信すると（ステップＳ５２，Ｓ５３）、「サービス享受要求仕様メッセージ」に基づいて、要求中のサービス機能を実行するためには、すなわち、サービス実現ソフトウエアの動作品質を保証するために割り当てるべきリソースを確保するためには、現在実行中のサービス機能のどれを停止させればよいかを調べる。そして、図１５に示すように、「停止機能確認メッセージ」を画面表示し、ユーザからの入力を待つ（ステップＳ５４）。
【００８０】
「停止機能確認メッセージ」では、現在実行中のサービス機能の情報がリスト表示されるとともに、「サービス１を停止すれば、サービスＡを実行できます。サービス１を停止しますか？」のようなガイダンスが表示される。ユーザが、「停止」ボタンまたは「キヤンセル」ボタンを押下すると、「停止機能選択メッセージ」が入力される。
【００８１】
移動端末２は、「停止機能選択メッセージ」を受信すると（ステップＳ５５）、ユーザが機能変更（機能停止）を選択したか否かを調べる（ステップＳ５６）。ユーザが「キヤンセル」ボタンを選択していた場合には、特別な処理は行わず、ステップＳ５０に戻る。ユーザが「停止」ボタンを選択していた場合には、機能変更、つまり、サービス１を停止することによってリソースを解放する（ステップＳ５７）。そして、移動端末２は、端末プロファイルを更新して（ステップＳ５８）、あらためてセンター１０に「サービス追加要求メッセージ」を再送する（ステップＳ５１）。
【００８２】
この場合、移動端末２は、新たに追加するサービス実現ソフトウエアに対してリソース割り当てが可能な使用状態となっているので、以降は図１１の処理シーケンスと同様にしてソフトウエアの配信処理が遂行される。
【００８３】
以上述べた本実施形態によっても、第１の実施形態と同様の作用効果を奏することができる。
【００８４】
加えて、本実施形態では、移動端末２にサービス実現ソフトウエアの動作品質を保証し得るだけのリソースを予め確保させるので、サービス実現ソフトウエアを移動端末２上で実用的に動作させることができる。
【００８５】
また、リソース割り当て不可と判断された場合には、まずその旨が通知され、サービス実現ソフトウエアの配信はすぐには行われないので、サービス実現ソフトウエアの組み込みによって、他のソフトウエアの動作に支障がでるなどの問題を回避することができる。
【００８６】
さらに、サービス実現ソフトウエアの動作品質を保証するために割り当てるべきリソースに関する情報が移動端末に通知されるので、移動端末のユーザはその情報に基づいて、現在動作中のソフトウエアを終了させてリソースを解放し、代りに新たなソフトウエアを組み込むことが可能となる。
【００８７】
なお、上記各構成は本発明の一実施形態を例示したものにすぎない。本発明の範囲は上記実施形態に限られるものではなく、その技術思想の範囲内で種々の変形が可能である。
【００８８】
たとえば、上記各実施形態で示したタイミングチャートやフローチャートの手順、メッセージの構造などはいずれも一例であり、必要に応じて適宜変形することが可能である。
【００８９】
また、端末プロファイルに含める移動端末のスペックとしては、通信ＩＦの通信速度その他の情報を含めてもよい。また、移動端末の使用状態としては、移動端末を使用しているユーザに関する情報やユーザ設定などを含めてもよい。
【００９０】
【発明の効果】
以上説明したように、本発明によれば、移動端末上で最適な動作を保証し得るソフトウエアを配信することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るソフトウエア配信システムの構成を示す図である。
【図２】ソフトウエア配信システムにおける一覧通知処理のフローチャートである。
【図３】移動端末のユーザが追加機能を選択する際の処理シーケンスを表すタイミングチャートである。
【図４】第１の実施形態に係るソフトウエア配信処理のシーケンスを表すタイミングチャートである。
【図５】第１の実施形態に係るサービス追加要求メッセージのデータ構造を表す図である。
【図６】第１の実施形態に係るソフトウエア配信処理に係る移動端末側の処理を表すフローチャートである。
【図７】第１の実施形態に係るソフトウエア配信処理に係るセンター側の処理を表すフローチャートである。
【図８】第２の実施形態に係るサービス追加要求メッセージのデータ構造を表す図である。
【図９】第２の実施形態に係るソフトウエア配信処理に係るセンター側の処理を表すフローチャートである。
【図１０】サービス享受要求仕様メッセージのデータ構造を表す図である。
【図１１】第２の実施形態においてリソース割り当て可能な場合のソフトウエア配信処理のシーケンスを表すタイミングチャートである。
【図１２】移動端末における端末プロファイル更新処理のフローチャートである。
【図１３】第２の実施形態においてリソース割り当て不可の場合のソフトウエア配信処理のシーケンスを表すタイミングチャートである。
【図１４】第２の実施形態においてリソース割り当て不可の場合の移動端末側の処理を表すフローチャートである。
【図１５】停止機能確認メッセージの画面表示例である。
【符号の説明】
１  ソフトウエア配信システム
２  移動端末
２ａ，２ｂ  車載端末
２ｃ  情報携帯端末
３  インターネット
４  基地局
５  携帯電話基地局
１０  センター
１１  基本ソフトウエアＤＢ
２０  車両
【図１】
2004362090.tif 000003
【図２】
2004362090.tif 000004
【図３】
2004362090.tif 000005
【図４】
2004362090.tif 000006
【図５】
2004362090.tif 000007
【図６】
2004362090.tif 000008
【図７】
2004362090.tif 000009
【図８】
2004362090.tif 000010
【図９】
2004362090.tif 000011
【図１０】
2004362090.tif 000012
【図１１】
2004362090.tif 000013
【図１２】
2004362090.tif 000014
【図１３】
2004362090.tif 000015
【図１４】
2004362090.tif 000016
【図１５】
2004362090.tif 000017