JP2005157912A - コンテンツ配信サーバ、コンテンツ配信方法およびコンテンツ配信用プログラム - Google Patents

Abstract

【課題】 コンテンツプロバイダから携帯端末に対して提供するサービスのひとつとして着メロなどのコンテンツダウンロードを位置付けた場合にも効率的な通信を実現できるようすることを課題とする。
【解決手段】 コンテンツ配信システムは、ウェブサーバが携帯電話からの着メロ要求に応じて着メロの送信を行うが（ステップＳ２０８）、携帯電話にダウンロード可能なアプリケーションのバージョンが備わっていない場合には（ステップＳ２０２、Ｓ２０３）、携帯電話側に一旦アプリケーションのアップデート（ステップＳ１０６）をさせてからダウンロード処理を実行させるものである。
【選択図】 図７

Description

本発明は、たとえば、コンテンツ配信サーバ、コンテンツ配信方法およびコンテンツ配信用プログラムに関する。

今日、携帯電話の普及に伴って膨大な数、種類の着信メロディ（以下、着メロという）や着信ボイス（以下、着ボイスという）が用意されている。着メロや着ボイスなどのデジタルコンテンツは、コンテンツプロバイダにより提供されることが一般的である。

コンテンツプロバイダは、インターネットにサーバを接続させ、携帯電話網から携帯電話によりアクセスしてくるユーザに対してデジタルコンテンツを提供する。ユーザが着メロをダウンロードする場合には、たとえば携帯電話の画面にブラウザを表示させ、ボタン操作により所望の着メロを選択することにより入手することが可能となる。

最近、コンテンツプロバイダは各種のＪＡＶＡ（登録商標）アプリケーションをユーザに提供してサービスの拡充を図ろうとしている。着メロをダウンロードするだけのサービス提供であれば、ユーザの携帯電話に対してブラウザを通じて着メロをダウンロードさせるだけでよい。

携帯電話の記憶容量が増えてくると、着メロなどのデジタルコンテンツを豊富に揃えることが可能となる。このような事情からユーザが頻繁にサービスサイトにアクセスして着メロなどのデジタルコンテンツをダウンロードする機会は増加傾向になる。そこで、会員を対象としたサービスとして、ダウンロード対象のコンテンツを圧縮し、ダウンロード時のパケット量を削減する技術が提案されている（特許文献１）。

上述したように、サーバ側でコンテンツを準備して必要な圧縮をかけてから携帯電話にダウンロードさせ、パケット割引を管理するには、会員へのサービスとしてデータの削減実績を会員情報データベースに管理させることが重要な構成要件となる。それゆえ、会員情報データベースに対して会員に対応付けてデータの削減実績を記憶する必要が生じる。

特許第３４１６６４７号公報

しかしながら、会員情報データベースへの削減実績の保存は単に圧縮率をユーザに提示するだけの目的では不要となる。また、データ圧縮後にさらにサーバによるデータベースへのアクセスを行うことはサーバの処理負担が増大する虞があった。さらに、サーバ側の処理負荷に応じて携帯電話に対する応答が遅れた場合には、ユーザ側に僅かでも待ち時間を与えることになるので、ユーザのストレスが危惧される。

また、最近は、着メロのダウンロード以外のスケジューラなどの機能も含めて統合したサービスを提供するとなると、携帯電話のアプリケーション上ですべてのサービスを実現できるほうがユーザフレンドリであってインタフェースの統一化や容易な機能追加を実現することが可能である。

このようなことから、今日、着メロのダウンロードを含めて携帯電話とサービスを提供するサーバとの間で効率的なダウンロード通信を実現できることが期待されている。

本発明の目的は、コンテンツプロバイダから携帯端末に対して提供するサービスのひとつとして着メロなどのコンテンツダウンロードを位置付けた場合にも効率的な通信を実現することが可能なコンテンツ配信サーバ、コンテンツ配信方法およびコンテンツ配信用プログラムを提供することになる。

上述した課題を解決し、上記目的を達成するため、請求項１の発明に係るコンテンツ配信サーバは、ネットワークを介して携帯端末にサービスを提供するコンテンツ配信サーバであって、コンテンツデータを記憶する第１記憶手段と、携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションを記憶する第２記憶手段と、前記携帯端末から前記第１記憶手段に記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記第２記憶手段に記憶されているアプリケーションのバージョンとを比較する比較手段と、前記比較手段の比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記第１記憶手段に記憶されているコンテンツデータを配信するコンテンツ配信手段と、を備えたことを特徴とするものである。

請求項２の発明は、請求項１において、前記コンテンツ配信手段は、前記第１記憶手段に記憶されているコンテンツデータを所定のサイズに圧縮して配信するようにしてもよい。

請求項３の発明は、請求項２の発明において、前記コンテンツ配信手段は、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信するようにしてもよい。

請求項４の発明は、請求項２または３において、前記コンテンツ配信手段は、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信するようにしてもよい。

請求項５の発明は、請求項１〜４のいずれか１つにおいて、前記比較手段の比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記第２記憶手段に記憶されているアプリケーションを配信するアプリケーション配信手段をさらに有したものでもよい。

また、請求項６の発明に係るコンテンツ背信方法は，ネットワークを介して携帯端末にサービスを提供するコンテンツ配信方法であって、コンテンツデータと携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションとがメモリに記憶されており、前記携帯端末から前記メモリに記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記メモリに記憶されているアプリケーションのバージョンとを比較する第１ステップと、前記第１ステップの比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記メモリに記憶されているコンテンツデータを配信する第２ステップと、を含んだことを特徴とするものである。

請求項７の発明は、請求項６において、前記第２ステップは、前記メモリに記憶されているコンテンツデータを所定のサイズに圧縮して配信するようにしてもよい。

請求項８の発明は、請求項７において、前記第２ステップは、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信するようにしてもよい。

請求項９の発明は、請求項７または８において、前記第２ステップは、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信するようにしてもよい。

請求項１０の発明は、請求項６〜９のいずれか１つにおいて、前記第１ステップの比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記メモリに記憶されているアプリケーションを配信する第３ステップをさらに含んだものでもよい。

また、請求項１１の発明に係るコンテンツ配信用プログラムは、ネットワークを介して携帯端末にサービスを提供するコンテンツ配信サーバのコンピュータにより実行可能なコンテンツ配信用プログラムであって、前記コンピュータに、コンテンツデータと携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションとがメモリに記憶されており、前記携帯端末から前記メモリに記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記メモリに記憶されているアプリケーションのバージョンとを比較する第１ステップと、前記第１ステップの比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記メモリに記憶されているコンテンツデータを配信する第２ステップと、を実行させることを特徴とするものである。

請求項１２の発明は、請求項１１において、前記第２ステップは、前記メモリに記憶されているコンテンツデータを所定のサイズに圧縮して配信するようにしてもよい。

請求項１３の発明は、請求項１２において、前記第２ステップは、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信するようにしてもよい。

請求項１４の発明は、請求項１２または１３において、前記第２ステップは、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信するようにしてもよい。

請求項１５の発明は、請求項１１〜１４のいずれか１つにおいて、前記コンピュータに、さらに、前記第１ステップの比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記メモリに記憶されているアプリケーションを配信する第３ステップを実行させるようにしてもよい。

本発明によれば、コンテンツプロバイダから携帯端末に対して提供するサービスのひとつとして着メロなどのコンテンツダウンロードを位置付けた場合にも効率的な通信を実現することが可能な携帯端末、サーバ、ダウンロードシステム、ダウンロード方法およびダウンロード用プログラムを提供できるという効果を奏する。

以下に添付図面を参照して、本発明の一実施の形態について詳述する。

まず、全体について説明する。図１は本発明の一実施の形態によるコンテンツ配信システムを示す構成図である。本実施の形態によるコンテンツ配信システムは、サーバが携帯電話などの携帯端末からのコンテンツ要求に応じてコンテンツ配信を行うが、携帯端末にダウンロード可能なアプリケーションのバージョンが備わっていない場合には、携帯端末側に一旦アプリケーションのアップデートをさせてからダウンロード処理を実行させるものである。

このコンテンツ配信システムは、たとえば図１に示したように、携帯端末の１種である携帯電話とウェブサーバ２とにより構成され、携帯電話網４およびインターネット５で通信可能に接続される。

携帯電話網４は、パケット網４Ａ、ゲートウェイサーバ４Ｂなどを備えている。パケット網４Ａは、たとえば図示せぬ基地局を通じて携帯電話との間で無線通信を行うとともに、インターネット５に接続される各種の端末とゲートウェイサーバ４Ｂを介して通信を行う。ゲートウェイサーバ４Ｂは、インターネット５に接続され、インターネット５に接続されるウェブサーバ２などの端末とパケット網４Ａに無線接続される携帯電話などの携帯端末間の通信を制御する。

携帯電話１は、各種通信端末の代表例を示しており、音声通話、データ通信などを行う機能を備えている。この携帯電話１は、ウェブページを表示させるためのディスプレイ１１、ウェブ閲覧のための操作を司るキー群１２などにより構成される。

ウェブサーバ２は、各種サーバの代表例を示しており、携帯電話からの要求に応じてホームページ閲覧、着メロ、着ボイス、画像などのデジタルコンンテンツのダウンロード、電子商取引などのサービスを提供する。このウェブサーバ２は、ウェブページ、デジタルコンテンツなどの情報を格納したコンテンツデータベース（以下、コンテンツＤＢという）３を接続している。

本実施の形態においては、携帯電話１側のクライアントアプリケーション（以下にアプリケーションという）によりブラウザ形式でブラウザ表示を実現するため、ウェブサーバ２より携帯電話１に対してウェブページが提供される。また、本実施の形態においては、ウェブサーバ２より着メロなどのデジタルコンテンツを携帯電話１に対してダウンロードさせることができる。さらに、本実施の形態においては、データ量の多いデジタルコンテンツについては、ウェブサーバ２側で送信前のデジタルコンテンツについてデータ圧縮を行い、携帯電話１に対してたとえば順次分割転送を行うものである。

つぎに、本実施の形態によるコンテンツ配信システムを構成する各部について詳述する。まずウェブサーバ２について説明する。図２は本実施の形態によるウェブサーバの一構成例を示すブロック図であり、図３は本実施の形態によるリソースの一例を示す図である。

ウェブサーバ２は、インターネット５に接続され、このインターネット５を介して携帯電話、パーソナルコンピュータなどの端末との間の通信を司る通信制御部２０１、ＣＰＵ、ＲＯＭ、ＲＡＭなどを備え、サーバ全体の制御を司る制御部２０２、サーバ全体の制御を行うためのプログラムのほか本実施の形態によるコンテンツ提供のためのサーバ側のアプリケーション２０４、クライアントである携帯電話に供給するための、クライアント側でデジタルコンテンツをダウンロードするためのクライアントアプリケーション２０５、クライアントアプリケーションで使用する共通データからなるリソース２０６などを記憶した記憶部２０３、コンテンツＤＢ３との間でインタフェースを司るＤＢインタフェース２０７などにより構成される。

制御部２０２は、インターネット５を介して他の機器の要求に応じてデジタルコンテンツを提供したり、インターネット５を介して、もしくは、図示せぬドライバを介してデジタルコンテンツの内容を更新する処理も実行する。コンテンツＤＢ３は、着メロデータファイル２０８のほか画像、着ボイス、音楽などのデジタルコンテンツのファイル、ウェブページを構成するためのウェブページ情報などを保存している。

また、記憶部２０３においては、携帯電話との間で共有するダウンローダ（携帯電話が着メロなどのデジタルコンテンツをウェブサーバ２よりダウンロードするためのアプリケーション）であるクライアントアプリケーション２０５、リソース２７を更新可能に格納している。

リソース２０６は、たとえば図３に示したように、リソースサイズ部、データ部などにより構成される。リソースサイズ部は、データ部のサイズを示すものであり、リソースサイズ部とデータ部とは一例として１〜Ｎ（Ｎは自然数）個の対応関係を有している。データ部は、テキストまたは画像データであり、リソースサイズ部の各データサイズによりバイト数が示される。データサイズは２バイトであり、データ部は可変となっている。

このリソース２０６は、初回起動時とアップデート時に取得され、後述するがアップデート有無はクライアントアプリケーションの起動の度に確認される。また、本実施の形態において、クライアントアプリケーション２０５は、リソース２０６がアップデートされる場合には必ずアップデートされるように設定されているが、本発明はこれに限定されるものではなく、クライアントアプリケーション２０５に対してリソース２０５のアップデートが影響しない、もしくは、影響が小さい場合には、アップデートを必要としない設定にしてもよいことは謂うまでもない。

つづいて携帯端末の一例について説明する。図４は本実施の形態による携帯電話１の内部構成を示すブロック図、図５は本実施の形態によるバージョン番号を説明する図、そして、図６は本実施の形態によるアプリケーション１８Ａを含むメモリのデータ構造を説明する図である。

本実施の形態の携帯電話１は、たとえば図４に示したように、内部バス２３に、ディスプレイ１１、キー群１２、音声処理部１３、ＣＰＵ１６、ＲＯＭ１７、ＲＡＭ１８、通信処理部１９、赤外線通信部２１、カメラ２２などを接続させ、データ、アドレス信号、制御信号などを伝送させることで各種の処理を実現する構成である。

通信処理部１９は、アンテナ１８に接続され、アンテナ１８を介して携帯電話網４と通信を行うものである。この通信処理部１９により、音声通話やウェブサーバ２との通信（ｉモード（登録商標）など）を実現することができる。音声処理部１３は、音声出力のためのスピーカ１４、音声入力のためのマイク１５をそれぞれ接続させており、受話時や送話時の音声処理を行うものである。

ＣＰＵ１６は、携帯電話１全体の制御をＲＯＭ１７に格納されたＯＳにしたがって行うものである。ＲＯＭ１７は、あらかじめインストールされているＯＳなどのプログラムを格納している。このＣＰＵ１６は、携帯電話用の各種アプリケーション（たとえばＪＡＶＡ（登録商標）アプリケーション）によりウェブ閲覧、着メロなどのデジタルコンテンツのダウンロード、リソースのアップデートなどを制御する。また、このＣＰＵ１６は、キー群１２からの入力を受け付けて各種の処理を実行させたり、各種の処理に応じて表示を制御する。

ＲＡＭ１８は、カメラ２２による撮像画像を記憶するエリア、各種処理を行うためのワークエリアなどを備えているほか、ウェブサーバ２よりダウンロードしたクライアントアプリケーションに相当するアプリケーション１８Ａ、ウェブサーバ２よりダウンロードした着メロデータ１８Ｂや他のデジタルコンテンツを記憶する。本実施の形態によるウェブブラウザ機能は、アプリケーション１８ＡのうちのたとえばＪＡＶＡ（登録商標）アプリケーションにより実現される。

キー群１２は、電話番号、アドレスなどの入力を行ったり、表示画面上のウェブブラウザに対してページの選択、ページの切り替え、リンク先の指定、着メロなどのデジタルコンテンツのダウンロード指示などを行うための各種キーを備えている。ディスプレイ１１は、ウェブブラウザ、着メロなどのデジタルコンテンツのダウンロードにかかる表示遷移、電話やメールの機能を使うときに表示画面を形成したり、カメラ２２の撮像画像を表示するものである。

赤外線通信部２１は、所定の赤外線規格にしたがって同規格で赤外線通信可能な他の機器とのデータ通信を行うものであり、カメラ２２は、キー群１２の操作にしたがって撮像画像をデジタル画像として取り込むものである。

本実施の形態では、携帯電話側に着メロなどのデジタルコンテンツをダウンロードするためのアプリケーション（リソース）に対してバージョン番号をもたせている。図５には、バージョン番号の意味が示されている。バージョン番号の形式は、一例として、ＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤの４種類であり、それぞれ０〜２５５の数字を当て嵌める。

携帯電話１は、このバージョン番号を所持しており、ウェブサーバ２との間でたとえば着メロのダウンロード要求を行った際に、ウェブサーバ２に通知する。ウェブサーバ２は、ダウンロードのアプリケーションについて最新のバージョン番号を所持しているので、両者を比較して携帯電話１が所持しているアプリケーションのバージョン番号が古ければエラーを返すことになる。

一方、携帯電話１では、前回共通データ（アプリケーション１８Ａで使用するデータ）を取得したときのバージョン番号と今回ウェブサーバ２側で準備されているバージョン番号とを比較し、その差異に応じて共通データを再取得したり、共通リソースにかかるデータを削除したり、クライアントアプリケーションのみの更新によりデータに対する処理を実施しないという処理がなされる。

一例として、ＡＡＡＡはメジャーバージョンを示し、この場合、アプリケーションの大幅な変更を意味することからアップデートを必要とする。ＢＢＢＢは機能のアップグレードを示し、この場合、メジャーバージョンと同様にアップデートを必要とし、画面構成やデータ構造の変更を意味する。ＣＣＣＣはデザインなどのマイナーな変更を示し、この場合、共通リソースの再取得が必要となる。ＤＤＤＤはバグフィックスを示し、この場合、データに変更がないことを意味する。

アップデートに関しては、ウェブサーバ２においてバージョン情報のうちＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤの順に比較を行い、ウェブサーバ２側の数字がひとつでも大きいものがあれば、更新の必要があると判断する。すなわち、バージョン番号は更新のたびに大きくなる。ここで、アプリケーション１８Ａはバージョン情報のうちのひとつでも更新があれば、アップデートされる。

ＲＡＭ１８においては、たとえば図６に示したように、メモリの位置がバイト単位で示されている。０バイト目の位置には、共通データ取得フラグが格納される。これは画面を構成するなどのアプリケーションで使用されるデータを取得したかどうかを示す。この場合、０（ゼロ）は未取得、１は取得済みである。

１バイト目、２バイト目、３バイト目、４バイト目の位置には、それぞれバージョン番号ＡＡＡＡ、ＢＢＢＢ、ＣＣＣＣ、ＤＤＤＤが格納される。５バイト目以降の位置には、アプリケーション固有のデータ（固定長）、共通データ（可変長の画像データなど）が格納される。ここで、アプリケーション固有のデータはアプリケーション１８Ａを示し、共通データ取得フラグ、バージョン情報、共通データは図示せぬがＲＡＭ１８に格納される。

つぎに動作について説明する。図７および図８は本実施の形態によるダウンロード動作を説明するフローチャート、図９は本実施の形態によるアプリケーションのアップデート動作を説明するフローチャート、図１０は本実施の形態によるレスポンスデータのフォーマットを説明する図、そして、図１１は本実施の形態によるダウンロード時の画面遷移を説明する図である。

以下、携帯電話１の処理は、アプリケーション１８Ａにより実行され、ウェブサーバ２の処理は、アプリケーション２０４により実行される。携帯電話１によりウェブサーバ２へのアクセスが行われ、ユーザの操作により所望の着メロがダウンロード対象として選択されると、まずダウンロード中画面がディスプレイ１１に表示形成される（ステップＳ１０１）。そして、ウェブサーバ２に対して着メロのダウンロード要求が送信される（ステップＳ１０２）。

このダウンロード要求時、携帯電話１からウェブサーバ２に対して、あらかじめユーザに対して割り当てられたユーザを特定するための情報（ユーザＩＤ）、着メロを特定するための着メロＩＤ、着メロなどのデジタルコンテンツをウェブサーバ２よりダウンロードするためのアプリケーションに関するバージョン番号などが送信される。

ウェブサーバ２においては、ダウンロード要求が受け付けられると（ステップＳ２０１）、バージョン番号に基づいてバージョンチェックが行われる（ステップＳ２０２）。ここでは、携帯電話１より受信されたバージョン番号とリソース２０６のバージョン番号とが比較され、アップデートの要否が判断される。

アップデートが不要と判断された場合には（ステップＳ２０３のＮＯルート）、携帯電話１に格納されている現状のアプリケーション１８Ａにより正常に着メロをダウンロードすることが可能である。したがって、処理はステップＳ２０４に移行してユーザのチェックが行われる。このチェックは、携帯電話１から受信されたユーザＩＤが図示されぬ会員データベースに登録されているかどうかにより判断される。

ここで、会員データベースは、ウェブサーバ２にＤＢインタフェース２０７を介して接続されてもよく、あるいは、インターネット５に接続されてウェブサーバ２からアクセス可能な環境下におかれていてもよい。

もし会員登録されていた場合には（ステップＳ２０５のＹＥＳルート）、着メロデータファイル２０８からユーザのリクエストに応じた着メロデータが取得される。この場合、着メロデータのＤＢ検索に着メロＩＤが使用される。

着メロデータファイル２０８から取得された着メロデータは、携帯電話１がダウンロード可能なサイズに圧縮される。圧縮はたとえばＪＡＲ（ＺＩＰ）フォーマットで圧縮し、携帯電話が１回の通信で取得できる最大サイズがたとえば２０Ｋの場合、その２０Ｋを超えるものは２０Ｋずつに分割してダウンロードされるように処理される。そのときの圧縮率は、着メロデータの元ファイルと圧縮後のファイルとの比較により算出される（ステップＳ２０７）。

このようにして、ステータス、圧縮率、圧縮された着メロデータが揃うと、レスポンスデータが生成される。ここで、レスポンスデータとは、たとえば図１０に示したように、先頭１バイトにステータスコードが格納され、２バイト目に圧縮率が格納され、残りの部分に圧縮された着メロデータが格納される。エラー時には、２バイト目以降にデータは格納されない。この場合、ユーザが非会員などのエラー条件がある場合には、エラーを示す情報がレスポンスデータにセットされる。

ステータスコードとは、正常かそれともエラーかを示す情報、ユーザが会員か非会員かを示す情報、アプリケーションのアップデートの要否を示す情報などのフラグにより構成される。圧縮率とは、正常処理時の着メロデータ部分の圧縮率を示す。着メロデータとは、たとえばＪＡＲ圧縮された着メロデータを示す。

一方、ステップＳ２０３においてアップデートが必要と判断されると（ＹＥＳルート）、携帯電話１側で現行のアプリケーションにより着メロデータのダウンロードが完遂できないため、以降はアプリケーションのアップデート処理を優先して行う処理の流れとなる。また、ステップＳ２０５において非会員であると判断がなされると（ＮＯルート）、着メロのダウンロード資格がないためエラー条件のひとつとしてユーザにレスポンスデータを送る必要がある。

ステップＳ２０３、ステップＳ２０５のＮＯルートでは、処理はステップS208に移行してレスポンスデータの生成および携帯電話１への送信が行われる。アップデートが必要な際は、レスポンスデータにおいて、ステータスコードに要アップデートの情報がセットされて送信され、２バイト目以降はデータはセットされず、送信されないことになる。また、非会員の際は、レスポンスデータにおいて、ステータスコードに非会員の情報がセットされて送信され、２バイト目以降はデータはセットされず、送信されないことになる。

そして、携帯電話１においては、ウェブサーバ２から送信されたレスポンスデータが受信されると、まず先頭の２バイト（ステータスコード、圧縮率）が読み込まれる（ステップＳ１０４）。１バイト目のステータスコードからアップデートか否かの判断がなされ、アップデートが必要な場合には（ステップＳ１０５のＹＥＳルート）、処理はステップＳ１０６に移行してアプリケーションのアップデートが実行される。

ここで、ステップＳ１０５において、アップデートなしという判断が下された場合には（ＮＯルート）、処理はステップＳ１１１（図８参照）に移行してステータスコードのうち正常か否かのフラグをチェックする。このとき、異常の際は、エラー情報のダイアログが画面に表示される（ステップＳ１１２）。

一方、正常の際は、さらに２バイト目の圧縮率がチェックされ、圧縮率“０”の際は、そのままダウンロードが実行される（ステップＳ１１５）。圧縮率から圧縮がなされている際は、圧縮率がたとえば図１１（Ａ）のように表示され、ダウンロードが実行される（ステップＳ１１５）。

さて、アップデート処理は図９に示される。携帯電話１では、起動時、図６に示す先頭１バイト目から５バイト分のデータが取得される（ステップＳ３０１）。
アップデートが必要な場合、ステップＳ３０２において、現在ＲＡＭ１８に格納されているアプリケーション１８Ａが所持しているバージョン番号と前回ウェブサーバ２より共通データを取得したときにＲＡＭ１８に格納されたバージョン番号とが比較される。

図６において、１バイト目、２バイト目のバージョン情報（ＡＡＡＡ、ＢＢＢＢ）、３バイト目のバージョン情報（ＣＣＣＣ）、４バイト目のバージョン情報（ＤＤＤＤ）が参照される。そして、メジャーバージョン（ＡＡＡＡ）と機能アップグレード（ＢＢＢＢ）とのいずれか１つでも変更があれば（ステップＳ３０３）、図６で示すデータ構成はすべてゼロで埋められ、処理はステップＳ３０６に移行する（ステップＳ３０４）。

また、デザインなどの変更（ＣＣＣＣ）があれば（ステップＳ３０３）、先頭１バイトにゼロが書き込まれ、処理ステップＳ３０６に移行する（ステップＳ３０５）。また、バグフィックス部分の変更（ＤＤＤＤ）か、あるいは、ＡＡＡＡ、ＢＢＢＢ，ＣＣＣＣ，ＤＤＤＤのいずれも変更がないのであれば（ステップＳ３０３）、処理はステップＳ３０６に移行する。

そして、図６に示した先頭１バイト目の共通データ取得フラグが取得され（ステップＳ３０６）、その値が“０”（未取得）か“１”（取得済み）かを確認する（ステップＳ３０７）。共通データ取得フラグが“１”の場合には（ステップＳ３０７のＮＯルート）、共通データは取得済みと判断され、アップデート処理は終了する。

一方、共通データ取得フラグが“０”の場合には（ステップＳ３０７のＹＥＳルート）、共通データは未取得と判断され、ウェブサーバ２に対してアクセスがなされ、共通リソースが要求される（ステップＳ３０８）。ウェブサーバ２では、その「要求が受け付けられ（ステップＳ４０１）、リソース２０６が読み出されて携帯電話１に対して送信される（ステップＳ３０８）。

携帯電話１では、ウェブサーバ２からの共通リソースが取得されると（ステップＳ３０９）、その共通リソースはＲＡＭ１８の所定の領域に保存され（ステップＳ３１０）、さらにアプリケーションのバージョン番号が保存される（ステップＳ３１１）。その後、図６の先頭１バイト目（０位置）に取得済みを示す“１”が書き込まれる（ステップＳ３１２）。このようにして、アップデート処理が終了する。

なお、ウェブサーバ２側で圧縮された着メロデータは携帯電話１にダウンロードされたときに伸張されるものである。

以上説明したように本実施の形態によれば、コンテンツプロバイダから携帯端末に対して提供するサービスのひとつとして着メロなどのコンテンツダウンロードを位置付けた場合にも効率的な通信を実現することが可能である。

本発明は、コンテンツ配信サーバ、コンテンツ配信方法およびコンテンツ配信用プログラムを製造する産業で利用される。

本発明の一実施の形態によるコンテンツ配信システムを示す構成図である。 本実施の形態によるウェブサーバの一構成例を示すブロック図である。 本実施の形態によるリソースの一例を示す図である。 本実施の形態による携帯電話１の内部構成を示すブロック図である。 本実施の形態によるバージョン番号を説明する図である。 本実施の形態によるアプリケーション１８Ａを含むメモリのデータ構造を説明する図である。 本実施の形態によるダウンロード動作を説明するフローチャートである。 本実施の形態によるダウンロード動作を説明するフローチャートである。 本実施の形態によるアプリケーションのアップデート動作を説明するフローチャートである。 本実施の形態によるレスポンスデータのフォーマットを説明する図である。 本実施の形態によるダウンロード時の画面遷移を説明する図である。

符号の説明

１ 携帯電話
２ ウェブサーバ
３ コンテンツＤＢ
１１ ディスプレイ
１２ キー群
１６ ＣＰＵ
１７ ＲＯＭ
１８ ＲＡＭ
１８Ａ アプリケーション
１８Ｂ 着メロデータ
１９ 通信処理部
２０１ 通信制御部
２０２ 制御部
２０３ 記憶部
２０４ アプリケーション
２０５ クライアントアプリケーション
２０６ リソース
２０７ ＤＢインタフェース
２０８ 着メロデータファイル

Claims (15)

1. ネットワークを介して携帯端末にサービスを提供するコンテンツ配信サーバであって、
   コンテンツデータを記憶する第１記憶手段と、
   携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションを記憶する第２記憶手段と、
   前記携帯端末から前記第１記憶手段に記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記第２記憶手段に記憶されているアプリケーションのバージョンとを比較する比較手段と、
   前記比較手段の比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記第１記憶手段に記憶されているコンテンツデータを配信するコンテンツ配信手段と、
   を備えたことを特徴とするコンテンツ配信サーバ。
2. 前記コンテンツ配信手段は、前記第１記憶手段に記憶されているコンテンツデータを所定のサイズに圧縮して配信することを特徴とする請求項１に記載のコンテンツ配信サーバ。
3. 前記コンテンツ配信手段は、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信することを特徴とする請求項２に記載のコンテンツ配信サーバ。
4. 前記コンテンツ配信手段は、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信することを特徴とする請求項２または３に記載のコンテンツ配信サーバ。
5. 前記比較手段の比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記第２記憶手段に記憶されているアプリケーションを配信するアプリケーション配信手段をさらに有したことを特徴とする請求項１〜４のいずれか１つに記載のコンテンツ配信サーバ。
6. ネットワークを介して携帯端末にサービスを提供するコンテンツ配信方法であって、
   コンテンツデータと携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションとがメモリに記憶されており、前記携帯端末から前記メモリに記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記メモリに記憶されているアプリケーションのバージョンとを比較する第１ステップと、
   前記第１ステップの比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記メモリに記憶されているコンテンツデータを配信する第２ステップと、
   を含んだことを特徴とするコンテンツ配信方法。
7. 前記第２ステップは、前記メモリに記憶されているコンテンツデータを所定のサイズに圧縮して配信することを特徴とする請求項６に記載のコンテンツ配信方法。
8. 前記第２ステップは、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信することを特徴とする請求項７に記載のコンテンツ配信方法。
9. 前記第２ステップは、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信することを特徴とする請求項７または８に記載のコンテンツ配信方法。
10. 前記第１ステップの比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記メモリに記憶されているアプリケーションを配信する第３ステップをさらに含んだことを特徴とする請求項６〜９のいずれか１つに記載のコンテンツ配信方法。
11. ネットワークを介して携帯端末にサービスを提供するコンテンツ配信サーバのコンピュータにより実行可能なコンテンツ配信用プログラムであって、
    前記コンピュータに、
    コンテンツデータと携帯端末が前記第１記憶手段に記憶されているコンテンツデータをダウンロードするためのアプリケーションとがメモリに記憶されており、前記携帯端末から前記メモリに記憶されているコンテンツデータのダウンロード要求があった場合には、前記携帯端末から当該携帯端末が現在使用しているアプリケーションのバージョンを取得して、当該取得されたバージョンと前記メモリに記憶されているアプリケーションのバージョンとを比較する第１ステップと、
    前記第１ステップの比較結果に応じてダウンロードが可能な場合に前記携帯端末に対して前記メモリに記憶されているコンテンツデータを配信する第２ステップと、
    を実行させることを特徴とするコンテンツ配信用プログラム。
12. 前記第２ステップは、前記メモリに記憶されているコンテンツデータを所定のサイズに圧縮して配信することを特徴とする請求項１１に記載のコンテンツ配信用プログラム。
13. 前記第２ステップは、前記圧縮されたコンテンツデータが１回の送信サイズを超えている場合に分割して配信することを特徴とする請求項１２に記載のコンテンツ配信用プログラム。
14. 前記第２ステップは、前記圧縮されたコンテンツデータの圧縮率を算出して配信時に前記携帯端末に対して送信することを特徴とする請求項１２または１３に記載のコンテンツ配信用プログラム。
15. 前記コンピュータに、さらに、前記第１ステップの比較結果に応じてダウンロードが不可能な場合に前記携帯端末に対して前記メモリに記憶されているアプリケーションを配信する第３ステップを実行させることを特徴とする請求項１１〜１４のいずれか１つに記載のコンテンツ配信用プログラム。

Images