(57)【要約】【課題】悪意のある実行ファイルにより、他の実行ファイルが不正に実行される事態を防止する。【解決手段】配信される実行ファイルのデータ量が、配信先に応じて定められた容量制限値に達するように、無効なバイナリデータを配信サーバ内でオリジナルの実行ファイルに追加する。これにより、配信用の実行ファイルを生成し、生成された配信用の実行ファイルを配信先の携帯端末に送信する。【選択図】図４
2010271833.tif 000002
【特許請求の範囲】
【請求項１】
携帯端末に対して実行ファイルを配信する配信サーバにおいて、
配信される実行ファイルのデータ量が、配信先に応じて定められた容量制限値に達するようにオリジナルの実行ファイルに対して無効なバイナリデータを追加し、配信用の実行ファイルを生成する容量調整手段と、
前記配信用の実行ファイルを配信先の携帯端末に対して送信する配信手段と
を有する配信サーバ。
【請求項２】
配信を要求した携帯端末が接続する携帯事業者を識別する事業者識別手段を有し、
前記容量調整手段は、識別された携帯事業者名に固有の容量制限値に基づいて、オリジナルの実行ファイルに追加する無効なバイナリデータのデータ量を調節する
ことを特徴とする請求項１に記載の配信サーバ。
【請求項３】
配信を要求した携帯端末の機種名を識別する機種識別手段を有し、
前記容量調整手段は、識別された機種に固有の容量制限値に基づいて、オリジナルの実行ファイルに追加する無効なバイナリデータのデータ量を調節する
ことを特徴とする請求項１に記載の配信サーバ。
【請求項４】
前記実行ファイルは、ウェブブラウザ上で実行される
ことを特徴とする請求項１〜３のいずれか１項に記載の配信サーバ。
【請求項５】
携帯端末に対して実行ファイルを配信する配信サーバ上で実行されるプログラムにおいて、
配信される実行ファイルのデータ量が、配信先に応じて定められた容量制限値に達するようにオリジナルの実行ファイルに対して無効なバイナリデータを追加し、配信用の実行ファイルを生成する処理と、
前記配信用の実行ファイルを配信先の携帯端末に対して送信する処理と
をコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯端末にアプリケーションプログラム（以下、「アプリケーション」ともいう。）を配信するサーバに関する。また、携帯端末にアプリケーションを配信するサーバ上で実行して好適なプログラムに関する。
【背景技術】
【０００２】
携帯端末向けアプリケーションを利用した認証システムが、特許文献１に開示されている。この認証システムは、オンラインサービスの利用者認証に用いられる。認証システムは、利用者認証に使用するパスワードを暗号化し、利用者が操作する携帯端末に対して配信する。一方、携帯端末は、暗号化されたパスワードを、端末内に保持されている秘密鍵を用いて復号化する。利用者は、復号化されたパスワードを情報端末に入力し、オンラインサービスの提供者に送信する。オンラインサービスの提供者は、受信したパスワードにより利用者を認証する。
【０００３】
ところで、携帯端末に対する通信サービスの提供者（以下、「携帯事業者」という。）間において、携帯端末上におけるアプリケーションの実行環境は統一されていない。すなわち、携帯事業者毎に、携帯端末上におけるアプリケーションの実行環境が個別に指定されている。このため、１つのアプリケーションを複数の携帯事業者に提供するためには、各携帯事業者の実行環境に対応した複数種類のアプリケーションを開発する必要がある。このことが、開発コストと開発者の労力の増大を招いている。
【０００４】
例えばＮＴＴドコモ(日本電信電話株式会社の登録商標)の実行環境はJava(サンマイクロシステムズ社の登録商標)であり、ａｕ（ＫＤＤＩ株式会社の登録商標）の実行環境はBREW(クアルコム・インコーポレーテッドの登録商標)である。これらの実行環境の間に互換性は無い。
【０００５】
そこで、実行環境に依存することなく、アプリケーションを実行できる技術が求められている。この種の技術の一つに RIA（リッチインターネットアプリケーション）がある。
【０００６】
RIAはウェブブラウザ上で実行されるアプリケーションであり、ウェブブラウザのプラグインを導入すれば、どの携帯端末でも実行が可能である。
【０００７】
携帯端末向けのRIAとして市場占有率の高いものに、 Adobe（アドビシステムズ，インコーポレイテッドの登録商標）が開発しているFlash Lite（アドビシステムズ，インコーポレイテッドの登録商標）がある。このFlash Liteコンテンツを動的に生成するシステムが特許文献２に開示されている。
【０００８】
携帯端末は、パーソナルコンピュータ（personal computer：PC ）等の情報端末に比べ、ネットワーク上での通信速度が遅く、また、通信量に応じて課金される料金プランが大半を占めている。このため、携帯事業者では、Flash Liteアプリケーションのデータ容量（バイト数）に制限を設け、ユーザのストレスと利用料金の増大を防いでいる。
【０００９】
Flash Liteアプリケーションの容量制限は、アプリケーションとそのアプリケーションから読み込まれる全てのファイル（画像ファイルやテキストファイル、Flash Liteアプリケーションファイルなど）の合計量に対して設けられている。また、携帯端末の製造会社毎に異なる容量制限値が設けられる可能性もある。
【００１０】
上記の制限はあるものの、Flash Liteは、利用者の携帯端末内に永続データを保存するための機能としてローカル共有オブジェクトを利用でき、特許文献１で示したような携帯端末内に秘密鍵のような永続データの保存が必要なアプリケーションの開発も可能である。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００７―２４９７２６号公報
【特許文献２】特開２００９−２６２８１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
ただし、Flash Lite（登録商標）には、ローカル共有オブジェクトが他者に盗難される可能性がある。具体的には、攻撃者が悪意のあるアプリケーションをあるユーザに実行させ、ユーザが携帯端末内に保存しているFlash LiteアプリケーションＸを、悪意のあるアプリケーション上に読み込ませ、アプリケーションＸのスクリプトに記述されている変数やメソッドの変更、呼び出しを行うことで、アプリケーションＸが保存したローカル共有オブジェクトの内容を盗み見る可能性である。すなわち、携帯端末向けに用いられているFlash Liteでは、携帯端末内に保存した永続データの機密性を確保できない。
【課題を解決するための手段】
【００１３】
そこで、本発明は、携帯端末に対する実行ファイルの配信に先立って、オリジナルの実行ファイルに無効なバイナリデータを追加した配信用の実行ファイルを生成する手法を提供する。このとき、無効なバイナリデータのデータ量は、配信先に応じて定められている容量制限値になるように調節する。
【発明の効果】
【００１４】
本発明により、配信された実行ファイルが、携帯端末上の他の実行ファイルから読み込まれると、２つの実行ファイルの総データ量が容量制限値を超過し、他の実行ファイルの実行を強制的に停止させることができる。これにより、利用者の意図しない実行ファイルの不正な読み出しを防止することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態に係る携帯端末向けのアプリケーション配信システムの全体構成を示す図である。
【図２】各携帯事業者に対して実行ファイルを配信するアプリケーション配信サーバの概略構成例を示す図である。
【図３】携帯事業者情報テーブルの一例を示す図表である。
【図４】非圧縮の実行ファイルを携帯事業者用の実行ファイルに変換する動作を説明する図である。
【図５】圧縮されている実行ファイルを携帯事業者用の実行ファイルに変換する動作を説明する図である。
【図６】各携帯端末用に実行ファイルを配信するアプリケーション配信サーバの概略構成例を示す図である。
【図７】携帯端末情報テーブルの一例を示す図である。
【図８】配信用に用意された実行ファイルを携帯事業者用又は携帯端末用のアプリケーションに変換する処理を示すフローチャートである。
【図９】各携帯事業者用に生成された実行ファイルの配信処理手順を説明するフローチャートである。
【図１０】各携帯端末用に生成された実行ファイルの配信処理手順を説明するフローチャートである。
【図１１】悪意のある実行ファイルから正規に配信された実行ファイルが呼び出された場合の動作内容を説明するフローチャートである。
【発明を実施するための形態】
【００１６】
以下、図面に基づいて、本発明の実施の形態を説明する。なお、本発明の実施の形態における説明や図面は、専ら発明を説明することを目的としたものであり、既知の技術との組み合わせや置換も可能である。
【００１７】
（１）システムの全体構成
図１に、本発明の実施の形態に係る携帯端末向けのアプリケーション配信システムの全体構成を示す。形態例に係るアプリケーション配信システムは、アプリケーション配信サーバ１００、利用者の携帯端末１１０ａ、１１０ｂ、１１０ｃ、インターネット１２０、各携帯事業者の閉域網１３０ａ、１３０ｂ、１３０ｃ、各携帯事業者のゲートウェイ１４０ａ、１４０ｂ、１４０ｃで構成される。作図の都合により、図１には個々の携帯事業者に対して１台の携帯端末が収容された例を表しているが、勿論、現実には多数の携帯端末が収容される。また、各携帯事業者向けに携帯端末を提供する製造会社も１社に限らない。
【００１８】
アプリケーション配信サーバ１００と携帯端末１１０ａ、１１０ｂ、１１０ｃとは、インターネット１２０と携帯事業者閉域網１３０ａ、１３０ｂ、１３０ｃとを介して接続される。インターネット１２０と携帯事業者閉域網１３０ａ、１３０ｂ、１３０ｃとは、携帯事業者の通信機器であるゲートウェイ１４０ａ、１４０ｂ、１４０ｃを介して接続される。
【００１９】
本発明の実施の形態の場合、携帯端末１１０ａ、１１０ｂ、１１０ｃからのアプリケーション（実行ファイル）の配信要求は、それぞれ対応する閉域網１３０ａ、１３０ｂ、１３０ｃ及びインターネット１２０を通じてアプリケーション配信サーバ１００に通知される。アプリケーション配信サーバ１００は、アプリケーションの配信先である携帯事業者又は携帯端末の種類に応じて配信用の実行ファイル（以下、「配信用実行ファイル」という。）を動的に生成し、又は事前に用意しておいたものをストレージから読み出して送信する。配信用実行ファイルの生成方法については後述する。
【００２０】
携帯端末１１０ａ、１１０ｂ、１１０ｃは、それぞれ契約した携帯事業者との間で通信（実行ファイルのダウンロードを含む。）を実行する通信処理部１１１ａ、１１１ｂ、１１１ｃと，ウェブブラウザ１１２ａ、１１２ｂ、１１２ｃと、アプリケーション実行プラグイン１１３ａ、１１３ｂ、１１３ｃを有している。なお、携帯端末１１０ａ、１１０ｂ、１１０ｃは、いわゆる携帯電話機だけでなく、携帯情報端末その他の携帯事業者が提供する閉域網を通じてサービスの提供を受ける携帯型の電子機器であっても良い。
【００２１】
（２）アプリケーション配信サーバ
（２−１）実施例１
図２を用い、アプリケーション配信サーバ１００の１つ目の実施例を説明する。このアプリケーション配信サーバ１００は、アプリケーションの配信事業者が管理運営する。実施例１においては、携帯事業者毎に専用の配信用実行ファイルを生成する機能を搭載するアプリケーション配信サーバ１００について説明する。
【００２２】
なお、アプリケーション配信サーバ１００は、コンピュータと、ストレージシステムと、通信装置とを基本システムとし、後述する各種の機能はコンピュータ上で実行されるプログラムを通じて実現される。なお、プログラムは、不図示の記憶領域又は記憶装置に格納されている。
【００２３】
図２に示すアプリケーション配信サーバ１００は、携帯事業者情報テーブル２０１と、実行ファイル２０２と、携帯事業者別実行ファイル２０３と、アプリケーション容量調節部２０４と、携帯事業者識別部２０５と、アプリケーション配信部２０６とで構成される。
【００２４】
携帯事業者情報テーブル２０１は、携帯事業者名と、アプリケーションに要求される容量制限値と、携帯事業者ゲートウェイのＩＰアドレスとを対応付けて格納するデータテーブルである。図３に、携帯事業者情報テーブル２０１の一例を示す。図３の場合、Ａ社の容量制限値は１００ＫＢ、Ｂ社の容量制限値は１５０ＫＢ、Ｃ社の容量制限値は１２０ＫＢである。
【００２５】
実行ファイル２０２は、携帯端末向けに配信されるアプリケーションのオリジナルファイルである。ここで、「オリジナル」と表記したのは、配信用に無効なバイナリデータを追加する前の意味又は実行ファイル本体の意味で使用する。なお、実行ファイル２０２と携帯事業者別実行ファイル２０３はそれぞれ不図示の記憶領域又は記憶装置に格納される。
【００２６】
本発明の実施の形態の場合、バイナリフォーマットは、 Adobeが公表しているFlashバイナリファイルの仕様書「Flash File Format Specification」に従う。「Flash File Format Specification」の場合、Flashのバイナリファイルは、ヘッダとタグ領域から構成され。ヘッダには、ZLIB（RFC 1950 ZLIB Compressed Data Format Specification）形式による圧縮の有無、バージョン番号、ファイル容量等の情報が格納される。タグ領域には、図形や画像を描画又は操作するためのタグ等の情報が格納される。それぞれのタグには、タグの識別子（identifier：ID）、サイズ、内容が格納される。
【００２７】
携帯事業者別実行ファイル２０３は、配信用に実行ファイル２０２から生成された携帯事業者別の配信用実行ファイルの集合体である。この配信用実行ファイルは、アプリケーション容量調節部２０４が生成する。前述したように、発明の実施の形態では、携帯事業者がＡ社、Ｂ社、Ｃ社の３社の場合を想定する。この明細書の場合、各社向けの配信用実行ファイルを、Ａ社用実行ファイル２０３ａ、Ｂ社用実行ファイル２０３ｂ、Ｃ社用実行ファイル２０３ｃとして表記する。
【００２８】
アプリケーション容量調節部２０４は、各携帯事業者の容量制限値（図３）を参照して、実行ファイルを配信用実行ファイルに変換する。ここで、アプリケーション容量調節部２０４は、実行ファイル２０２に対して無効なバイナリデータを付加することにより、携帯事業者用実行ファイル２０３を生成する。なお、付加される無効なバイナリデータのバイト数は、実行ファイル２０２のバイト数と各携帯事業者の容量制限値（図３）との差分に応じて決定される。
【００２９】
図４及び図５を用いて、アプリケーション容量調節部２０４の処理動作を説明する。なお、図４は、実行ファイル２０２が非圧縮のバイナリデータの場合の動作例を示し、図５は、実行ファイル２０２がZLIB形式で圧縮処理されているバイナリデータの場合の動作例を示す。なお、いずれの場合も、実行ファイル２０２を、Ａ社用実行ファイル２０３ａに変換する場合について示す。
【００３０】
図４（Ａ）に示す実行ファイル２０２は、ヘッダ４１０ａとタグ領域４２０ａとで構成される。ヘッダ４１０ａには、タグ領域４２０ａのデータが圧縮されているかどうかを示す圧縮情報４１１（３バイト）、バージョン情報４１２（１バイト）、ファイルサイズ情報４１３（４バイト）が含まれている。
【００３１】
図４（Ｂ）に示すＡ社用実行ファイル２０３ａは、ヘッダ４１０ｂと、タグ領域４２０ｂと、容量調節のための付加バイナリ（以下、「容量調節バイナリ」という。）４３０とで構成される。ヘッダ４１０ｂには、変換後のファイルサイズ情報４１３ｂが含まれる。
【００３２】
データが非圧縮の場合、圧縮情報４１１は「４６ ５７ ５３」となる。また、ファイルサイズ情報４１３がリトルエンディアンであるとすると、実行ファイル２０２のファイルサイズは１６進数でＥ５１１であり、１０進数に直すと６２７３７バイトである。従って、図４の場合、容量調節バイナリ４３０は３７ＫＢである。なお、容量調節バイナリ４３０には、バイナリデータの実行時に無効なデータとして扱われるデータが追加的に書き込まれる。この無効なデータの追加により、Ａ社用実行ファイル２０３ａのバイト数は、１００ＫＢに変更される。
【００３３】
図５（Ａ）に示す実行ファイル２０２は、ヘッダ５１０ａとタグ領域５２０ａとで構成される。ヘッダ５１０ａには、タグ領域５２０ａのデータが圧縮されているかどうかを示す圧縮情報５１１（３バイト）、バージョン情報５１２（１バイト）、ファイルサイズ情報５１３（４バイト）が含まれている。
【００３４】
図５（Ｂ）に示すＡ社用実行ファイル２０３ａは、ヘッダ５１０ｂと、タグ領域５２０ｂと、容量調節バイナリ５３０とで構成される。
【００３５】
データが圧縮されている場合、圧縮情報５１１は「４３ ５７ ５３」となる。また、ファイルサイズ情報５１３は、データを解凍した際の想定サイズを表しており、実行ファイル２０２のサイズと同じである必要は無い。なお、データが圧縮されている場合、圧縮された状態におけるＡ社用実行ファイル２０３ａのバイト数が１００ＫＢになるように、容量調節バイナリ５３０のバイト数が決定される。図５の場合、容量調節バイナリ５３０は２６ＫＢである。このことは、実行ファイル２０２のバイト数が７４ＫＢであることを意味する。
【００３６】
携帯事業者識別部２０５は、携帯端末１１０ａ、１１０ｂ、１１０ｃからアプリケーションのダウンロードが要求された場合に、通信経路となる携帯事業者を識別する処理部である。携帯事業者識別部２０５は、例えば通信ログから携帯事業者ゲートウェイ１４０のＩＰアドレスを取得し、携帯事業者情報テーブル２０１（図３）と比較する。前述したように、携帯事業者情報テーブル２０１には、携帯事業者名と携帯事業者ゲートウェイのＩＰアドレスとが対応付けられている。従って、携帯事業者識別部２０５は、携帯事業者ゲートウェイのＩＰアドレスの比較により、実行ファイル２０２のダウンロードを要求した携帯端末１１０ａ、１１０ｂ、１１０ｃが接続されている携帯事業者を特定する。携帯事業者識別部２０５は、特定した携帯事業者の情報をアプリケーション配信部２０６に通知する。
【００３７】
アプリケーション配信部２０６は、通知された携帯事業者の情報に基づいて、対応する配信用実行ファイルを携帯事業者別実行ファイル２０３から読み出す。また、アプリケーション配信部２０６は、配信用実行ファイルを、対応する携帯事業者のゲートウェイを通じて各携帯電話１１０ａ、１１０ｂ、１１０ｃに配信する。
【００３８】
（２−２）実施例２
図６を用い、アプリケーション配信サーバ１００の２つ目の実施例を説明する。このアプリケーション配信サーバ１００も、アプリケーションの配信事業者が管理運営する。実施例２においては、携帯端末毎に専用の配信用実行ファイルを生成する機能を搭載するアプリケーション配信サーバ１００について説明する。この実施例は、機種毎に容量制限値が異なる可能性がある場合を考慮したものである。
【００３９】
図６に示すアプリケーション配信サーバ１００は、携帯端末情報テーブル６０１と、実行ファイル２０２と、携帯端末別実行ファイル６０２と、アプリケーション容量調節部６０３と、携帯端末識別部６０４と、アプリケーション配信部６０５とで構成される。
【００４０】
携帯端末情報テーブル６０１は、携帯事業者名と、携帯端末の機種名と、アプリケーションの容量制限値とを対応付けて格納するデータテーブルである。図７に、携帯端末情報テーブル６０１の一例を示す。図７の場合、機種「Ａ１００」の容量制限値は１００ＫＢ、機種「Ａ１０１」の容量制限値は１１０ＫＢ、機種「Ｂ１０００」の容量制限値は１５０ＫＢ、機種「Ｂ１００１」の容量制限値は１５０ＫＢ、機種「Ｃ５０」の容量制限値は１２０ＫＢ、機種「Ｃ５１」の容量制限値は１２５ＫＢである。
【００４１】
携帯端末別実行ファイル６０２は、配信用に実行ファイル２０２から生成された携帯端末別の配信用実行ファイルの集合体である。この配信用実行ファイルは、アプリケーション容量調節部６０３が生成する。この明細書の場合、携帯端末別に生成又は用意する配信用実行ファイルを、Ａ１００用実行ファイル６０２ａ、Ａ１０１用実行ファイル６０２ｂ、Ａ１０２用実行ファイル６０２ｃとして表記する。
【００４２】
アプリケーション容量調節部６０３は、各携帯端末の容量制限値（図７）を参照して、実行ファイルを配信用実行ファイルに変換する。ここで、アプリケーション容量調節部６０３は、実行ファイル２０２に対して無効なバイナリデータを付加することにより、携帯端末別実行ファイル６０２を生成する。携帯端末別実行ファイル６０２の具体的な生成方法は実施例１と同じである。
【００４３】
携帯端末識別部６０４は、携帯端末１１０ａ、１１０ｂ、１１０ｃからアプリケーションのダウンロードが要求された場合に、例えばＨＴＴＰ（HyperText Markup Language）リクエストから機種名を識別する処理部である。携帯端末識別部６０４は、取得された機種名の情報をアプリケーション配信部６０５に通知する。
【００４４】
アプリケーション配信部６０５は、通知された機種名に基づいて、対応する配信用実行ファイル等を携帯端末別実行ファイル６０２から読み出す。また、アプリケーション配信部６０５は、配信用実行ファイル等を、対応する携帯事業者のゲートウェイを通じて各携帯電話１１０ａ、１１０ｂ、１１０ｃに配信する。
【００４５】
（３）配信用実行ファイルの生成動作
続いて、実行ファイルを、各携帯事業者に適した又は各携帯端末に適した配信用の実行ファイルに変換する処理（生成動作）を説明する。図８に、生成動作の概要を示す。まず、ステップＳ８０１では、アプリケーション容量調節部が、実行ファイルのヘッダから圧縮情報を読み取る。ステップＳ８０２において、アプリケーション容量調節部は、読み出した圧縮情報に基づいて実行ファイル２０２が圧縮されているか否かを判定する。
【００４６】
圧縮されていないと判定された場合（ステップＳ８０２で否定結果が得られた場合）、アプリケーション容量調節部は、ステップＳ８０３に進む。一方、圧縮されていると判定された場合（ステップＳ８０２で肯定結果が得られた場合）、アプリケーション容量調節部は、ステップＳ８０４に進む。
【００４７】
例えば図４（Ａ）の場合、圧縮情報４１１は「４６ ５７ ５３」である。これは実行ファイル２０２が圧縮されていないことを表すため、アプリケーション容量調節部は、ステップＳ８０３に進む。一方、図５の場合、圧縮情報５１１は「４３ ５７ ５３」である。これは実行ファイル２０２が圧縮されていることを表すため、アプリケーション容量調節部は、ステップＳ８０４に進む。
【００４８】
ステップＳ８０３に進んだアプリケーション容量調節部は、ヘッダ４１１のファイルサイズ情報４１３ａの値を、携帯事業者又は携帯端末の容量制限値に書き換える。図４の場合、ファイルサイズ情報４１３ａの値を、Ａ社の容量制限値が１００ＫＢである。例えば１０進数表示であれば「１０２４００」に、１６進数表示であれば「１９０００」に書き換える。
【００４９】
ステップＳ８０４では、コンパイル後の実行ファイルの容量（バイナリデータのバイト数）が、携帯事業者又は携帯端末の容量制限値になるように、実行ファイル２０２の末尾に無効データ（以下、「０バイナリ」という。）を付加する。例えば、図４の場合、アプリケーション容量調節部は、容量調節バイナリ４３０に３９６６３バイトを付加する。すなわち、配信用実行ファイルの容量を１０進数表記の「１０２４００」、すなわち１００ＫＢにする。なお、付加した０バイナリは、実行ファイルの実行時には無視される。
【００５０】
（４）実行ファイルの配信動作
続いて、実行ファイルの配信時に、携帯端末１１０ａ、１１０ｂ、１１０ｃとアプリケーション配信サーバ１００においてそれぞれ実行される動作を説明する。
【００５１】
（４−１）実施例１
図９に、携帯事業者別にファイルサイズを調整した配信用実行ファイルを配信する場合の処理動作を説明する。
【００５２】
ステップＳ９０１において、利用者は、携帯端末に対する操作入力を通じてアプリケーションのダウンロードを要求する。この操作入力に従い、携帯端末は、指定されたアプリケーションのダウンロードを要求する通信信号をアプリケーション配信サーバ１００に送信する。
【００５３】
ステップＳ９０２において、携帯事業者識別部２０５は、ダウンロードを要求する通信信号が通過した携帯事業者ゲートウェイ１４０ａ、１４０ｂ、１４０ｃのＩＰアドレスを取得する。
【００５４】
ステップＳ９０３において、携帯事業者識別部２０５は、携帯事業者情報テーブル２０１を参照し、ステップＳ９０２で取得したＩＰアドレスを有する携帯事業者名を抽出する。例えばステップＳ９０２で取得したＩＰアドレスが「124.xxx.xxx.xxx」であった場合を考える。図３の携帯事業者情報テーブル２０１には、Ａ社の携帯事業者ゲートウェイ１４０ａのＩＰアドレスに「124.xxx.xxx.xxx」が含まれている。このため、携帯事業者識別部２０５は、実行ファイルのダウンロードを要求している携帯端末１１０ａが、Ａ社の携帯事業者閉域網１３０ａに接続されていると判定する。
【００５５】
ステップＳ９０４において、アプリケーション配信部２０６は、携帯事業者識別部２０５から通知を受けた携帯事業者の情報に基づいて、対応する携帯事業者別実行ファイル２０３を対応する携帯端末に配信する。ステップＳ９０３の例の場合であれば、アプリケーション配信部２０６は、Ａ社用実行ファイル２０３ａを携帯端末１１０ａに配信する。
【００５６】
ステップＳ９０５において、アプリケーションの利用者は、アプリケーション配信サーバ１００から受信した携帯事業者別実行ファイル２０３を自身の携帯端末の保存領域に保存する。
【００５７】
（４−２）実施例２
図１０に、携帯端末別にファイルサイズを調整した配信用実行ファイルを配信する場合の処理動作を説明する。
【００５８】
ステップＳ１００１において、利用者は、携帯端末に対する操作入力を通じてアプリケーションのダウンロードを要求する。この操作入力に従い、携帯端末は、指定されたアプリケーションのダウンロードを要求する通信信号をアプリケーション配信サーバ１００に送信する。
【００５９】
ステップＳ１００２において、携帯端末識別部６０４は、ダウンロードを要求する通信信号の送信元である携帯端末１１０ａ、１１０ｂ、１１０ｃのＨＴＴＰリクエストの中から機種名を取得する。
【００６０】
ステップＳ１００３において、アプリケーション配信部６０５は、携帯端末識別部６０４において取得された機種名に基づき、携帯端末別実行ファイル６０２を携帯端末に配信する。例えばステップＳ１００２で取得した機種名が「Ａ１００」であった場合を考える。この場合、アプリケーション配信部６０５は、Ａ１００用実行ファイル６０２ａを携帯端末１１０ａに配信する。
【００６１】
ステップＳ１００４において、アプリケーションの利用者は、アプリケーション配信サーバ１００から受信した携帯端末別実行ファイル６０２を自身の携帯端末の保存領域に保存する。
【００６２】
（５）不正読み出し防止動作
図１１に、悪意のある実行ファイルにより、前述した配信用実行ファイルの読み出しが不正に実行される場合における携帯端末内の動作を説明する。
【００６３】
ステップＳ１１０１において、攻撃者が、携帯端末からデータを盗むために悪意のある実行ファイルを携帯端末等に配信する。例えばメール等によって悪意のある実行ファイルを掲載するホームページに誘導し、利用者による画面メモ機能の実行を通じて携帯端末に悪意のある実行ファイルを保存させる。ここで、「画面メモ」とは、Ｗｅｂサイトが閲覧可能な携帯端末において、表示中のＷｅｂページの内容をタイトル、ＵＲＬ、画像データとともに携帯端末に保存する機能のことである。
【００６４】
ステップＳ１１０２において、携帯端末の利用者がダウンロードした悪意のある実行ファイルを実行する。ステップＳ１００１の例の場合では、保存した画面メモを開く。
【００６５】
ステップＳ１１０３において、悪意のある実行ファイルが携帯端末に保存されているアプリケーションを呼び出す。
【００６６】
ステップＳ１１０４において、ウェブブラウザは、読み込まれているファイルの総量（バイナリデータの総バイト数）が、携帯事業者又は携帯端末の容量制限値以下であるか否かを判定する。この際、前述した配信用実行ファイルはそれ自体で容量制限値に一致している。従って、悪意のある実行ファイルと読み込まれた配信用実行ファイルの総バイト数は、必ず携帯事業者又は携帯端末の容量制限値を超えることになる。この場合、悪意のある実行ファイルの実行は強制的に停止される。
【００６７】
例えば携帯事業者が図３で示したＡ社であれば、容量制限値は１００ＫＢである。そして、図８で説明した実行ファイルの容量調節処理により、携帯端末に配信された配信用実行ファイルの容量は１００ＫＢである。このため、悪意のある実行ファイルが先の配信用実行ファイルを不正に読み出すと、その総バイト数は１００ＫＢを超えてしまう。この結果、悪意のある実行ファイルの実行が強制的に停止される。
【００６８】
（６）まとめ
以上説明したように、本発明の実施の形態の場合には、携帯事業者や携帯端末毎に設定されている容量制限値に着目し、Flash Liteアプリケーションが、他のアプリケーションから読み込まれる場合には必ず総バイトするが容量制限値を超えるように、Flash Liteアプリケーションのファイル容量を配信前に調整する。
【００６９】
この調整機能を用いれば、悪意のあるアプリケーションによるローカル共有オブジェクトの参照を防ぐことが可能となる。結果的に、Flash Liteアプリケーションから携帯端末内に保存した永続データの機密性を向上させることができる。
【００７０】
（７）他の実施の形態
前述した実施の形態では、アプリケーションを配布する事業者が運営するアプリケーション配信サーバ１００に、実行ファイルの容量調節機能を搭載する場合について説明した。しかしながら、各携帯事業者が運営するサーバ上において、実行ファイルの容量を調節することにしても良い。
【００７１】
本発明は前述した実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々の変更が可能であることは言うまでもない。
【符号の説明】
【００７２】
１００：アプリケーション配信サーバ
１１０ａ、１１０ｂ、１１０ｃ：携帯端末
１１１ａ、１１１ｂ、１１１ｃ：通信処理部
１１２ａ、１１２ｂ、１１２ｃ：ウェブブラウザ
１１３ａ、１１３ｂ、１１３ｃ：アプリケーション実行プラグイン
１２０：インターネット
１３０ａ、１３０ｂ、１３０ｃ：携帯事業者閉域網
１４０ａ、１４０ｂ、１４０ｃ：携帯事業者ゲートウェイ
２０１：携帯事業者情報テーブル
２０２：実行ファイル
２０３：携帯事業者別実行ファイル
２０４：アプリケーション容量調節部
２０５：携帯事業者識別部
２０６：アプリケーション配信部
４１０ａ、４１０ｂ：ヘッダ
４１１：圧縮情報
４１２：バージョン情報
４１３ａ、４１３ｂ：ファイルサイズ情報
４２０ａ、４２０ｂ：タグ領域
４３０：容量調節バイナリ
５１０ａ、５１０ｂ：ヘッダ
５１１：圧縮情報
５１２：バージョン情報
５１３：ファイルサイズ情報
５２０ａ、５２０ｂ：タグ領域
５３０：容量調節バイナリ
６０１：携帯端末情報テーブル
６０２：携帯端末別実行ファイル
６０３：アプリケーション容量調節部
６０４：携帯事業者識別部
６０５：アプリケーション配信部
【図１】
2010271833.tif 000003
【図２】
2010271833.tif 000004
【図３】
2010271833.tif 000005
【図４】
2010271833.tif 000006
【図５】
2010271833.tif 000007
【図６】
2010271833.tif 000008
【図７】
2010271833.tif 000009
【図８】
2010271833.tif 000010
【図９】
2010271833.tif 000011
【図１０】
2010271833.tif 000012
【図１１】
2010271833.tif 000013