JP2004272595A

JP2004272595A - Communication system, server, mobile apparatus, program, and recording medium

Info

Publication number: JP2004272595A
Application number: JP2003062419A
Authority: JP
Inventors: Masaru Kamiya; 大神谷; Kazuhiro Yamada; 和宏山田; Takashi Kondo; 隆近藤
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2003-03-07
Filing date: 2003-03-07
Publication date: 2004-09-30
Anticipated expiration: 2023-03-07
Also published as: JP4323190B2

Abstract

<P>PROBLEM TO BE SOLVED: To provide a mechanism for sharing data among a plurality of programs, while keeping security of data to be stored. <P>SOLUTION: A plurality of data servers 2 distribute a plurality of programs to a mobile apparatus 3 via a mobile packet communication network 1. In this case, at least one data server 2 transmits information to the mobile apparatus 3, by which correspondence to the program capable of sharing data among a plurality of programs is determined. When the program is downloaded, the mobile apparatus 3 assigns a memory area exclusive to the program. The apparatus 3 writes data to be shared with another program into the memory area to be accessible under the execution of a plurality of programs. Besides, the mobile apparatus 3 performs an authentication processing by referring to determination information corresponding to the program under execution, when reading data from the memory area to be accessible under the performance of a plurality of programs. <P>COPYRIGHT: (C)2004,JPO&NCIPI

Description

【０００１】
【従来の技術】
従来より、移動通信網を介してダウンロードしたプログラムを実行可能な移動機が知られている。このような移動機として、例えば、Ｊａｖａプログラミング言語によって記述されたプログラムを実行可能なものがある。この移動機の場合、所謂サンドボックスを用いて、移動機内部に記憶されるデータが外部サーバ等に流出しないように保護している。サンドボックスと称せられる技術に関しては、例えば特許文献１に記載されている。
【０００２】
【特許文献１】
特開平１０−２５４７８３号公報
【０００３】
サンドボックスを利用したデータ保護の場合、移動機にインストールされる各々のプログラム毎に、排他的なメモリ領域が割り当てられる。そのため、移動機は、あるプログラムを実行中に、他のプログラムに割り当てられたメモリ領域にアクセスすることができない。くわえて、サンドボックスによるデータ保護では、移動機があるプログラムを実行中に通信可能な外部サーバは、実行中のプログラムの配信元サーバのみとされる。このため、サンドボックスを用いると、移動機に記憶されるデータが、信頼できない第三者の外部サーバに流出することがなくなる。
【０００４】
【発明が解決しようとする課題】
ところが、データセキュリティとデータを扱う際の自由度とは、トレードオフの関係にある。上記のように、サンドボックスを利用してデータ保護を行った場合、複数のプログラム間でデータを共有することが不可能となる。その結果、移動機にインストールされた複数のプログラムがデータを共用しつつ連携して動作することができなくなる、つまり、移動機におけるプログラムの拡張性が制限されてしまうという問題が生じる。
本発明は、かかる実情に鑑み、複数のプログラムが、セキュリティを維持しつつデータを共用することが可能な、通信システム、サーバ、移動機、プログラムおよび記録媒体を提供する。
【０００５】
【課題を解決するための手段】
上記の課題を解決するため、本発明は、移動通信網に収容される移動機と、前記移動機が実行可能なプログラムを前記移動通信網を介して前記移動機に送信する複数のサーバとを備え、少なくとも１つの前記サーバは、前記プログラムと、当該プログラムに対して前記移動機におけるメモリ領域をどのように割り当てるかということを前記移動機が判断するための判断情報を送信し、前記移動機は、前記複数のサーバから送信されてくる複数の前記プログラムと、前記少なくとも１つのサーバから送信されてくる前記判断情報を受信する受信手段と、受信した前記複数のプログラムの各々に対しては、各プログラム専用のメモリ領域を割り当てる個別領域割当手段と、受信した前記判断情報に基づいて判断される特定の複数プログラムに対しては、当該特定の複数プログラムによって共有可能なメモリ領域を割り当てる共有領域割当手段と、実行対象のプログラムに対し前記個別領域割当手段及び前記共有領域割当手段によって割り当てられたメモリ領域を用いて、当該プログラムを実行する制御手段とを備えることを特徴とする通信システムを提供する。
【０００６】
そして、本発明は、移動通信網に収容される移動機に対して、当該移動機が前記移動通信網を介して受信したプログラムに対してどのようにメモリ領域を割り当てるかということを当該移動機に対して指定することを特徴とするサーバを提供する。
【０００７】
さらに、本発明は、複数のサーバから送信されてくる複数の実行可能なプログラムと、少なくとも１つのサーバから送信され前記プログラムに対してどのようにメモリ領域を割り当てるかということを判断するための判断情報とを受信する受信手段と、受信した前記複数のプログラムの各々に対しては、各プログラム専用のメモリ領域を割り当てる個別領域割当手段と、受信した前記判断情報に基づいて判断される特定の複数プログラムに対しては、当該特定の複数プログラムによって共有可能なメモリ領域を割り当てる共有領域割当手段と、実行対象のプログラムに対し前記個別領域割当手段及び前記共有領域割当手段によって割り当てられたメモリ領域を用いて、当該プログラムを実行する制御手段とを備えることを特徴とする移動機を提供する。
【０００８】
好ましい態様において、前記制御手段は、前記共有領域割当手段によって割り当てられたメモリ領域にデータを書き込む際に、当該データに前記判断情報を付加する記録手段と、前記共有領域割当手段によって割り当てられたメモリ領域からデータを読み出す際に、読み出すべきデータに付加された前記判断情報に基づいて読出し可否を判別する判別手段と、前記判別手段による判別結果がデータ読出しを許可するものであった場合に前記共有領域割当手段によって割り当てられたメモリ領域にアクセスする読出手段とを備える。
【０００９】
また、別の好ましい態様において、前記制御手段は、前記共有領域割当手段によって割り当てられたメモリ領域にデータを書きこむ際に、実行中の前記プログラムに対応する前記判断情報を、書きこむべきデータに対応する前記判断情報と対応付けて記憶する記憶手段と、前記共有領域割当手段によって割り当てられたメモリ領域からデータを読み出す際に、実行中の前記プログラムに対応する前記判断情報と、読み出すべきデータに対応付けられて前記記憶手段によって記憶されている前記判断情報とに基づいて読出し可否を判別する判別手段と、前記判別手段による判別結果がデータ読出しを許可するものであった場合に前記共有領域割当手段によって割り当てられたメモリ領域にアクセスする読出手段とを備える。
【００１０】
また、別の好ましい態様において、前記判断情報は、前記プログラムの配信元サーバを一意に示すアドレスである。
また、別の好ましい態様において、前記判断情報は、データ共有の対象であるプログラムの配信元サーバを一意に示すアドレスである。
また、別の好ましい態様において、前記判断情報は、データ共有の対象であるプログラムのプログラム名である。
また、別の好ましい態様において、前記プログラムはＪａｖａ（登録商標）によって記述されており、前記判断情報はＡＤＦ（ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒＦｉｌｅ）に記述されている。
【００１１】
そして、本発明は、コンピュータに、複数のサーバから送信されてくる複数のプログラムと、少なくとも１つのサーバから送信され前記プログラムに対してどのようにメモリ領域を割り当てるかということを判断するための判断情報とを受信する機能と、受信した前記複数のプログラムの各々に対しては、各プログラム専用のメモリ領域を割り当てる機能と、受信した前記判断情報に基づいて判断される特定の複数プログラムに対しては、当該特定の複数プログラムによって共有可能なメモリ領域を割り当てる機能と、実行対象のプログラムに対し前記各プログラム専用のメモリ領域および前記特定の複数プログラムによって共有可能なメモリ領域を用いて、当該プログラムを実行する機能とを実現させるためのプログラムおよび当該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供する。
【００１２】
【発明の実施の形態】
＜１．第１実施形態＞
＜１−１．第１実施形態の構成＞
＜１−１−１．システム構成＞
図１は、本発明の一実施形態に係る通信システム１００の全体構成を示す図である。図１に示すように、通信システム１００は、移動パケット通信網１と、複数のデータサーバ２−１〜２−ｎ（ｎ＝自然数。以下、特に個々の機器を区別する必要のない場合、データサーバ２と称する）と、移動機３とを備えている。なお、図１においては、図面が煩雑になることを防ぐため、通信システム１００の構成を理解するのに必要な装置のみが示されている。
【００１３】
移動パケット通信網１は、移動機３に対して、パケット通信サービスを提供する。図１に示すように、移動パケット通信網１は、交換局１１を備えており、各交換局１１には、基地局１２が接続されている。基地局１２は、移動機３との通信に用いる電波を出力しており、この電波の到達範囲内が無線セルとして形成される。基地局１２は、自身が形成する無線セル内に在圏する移動機３との間で、無線パケット通信を行う。
なお、通信システム１００は、移動パケット通信網１に加え、移動電話網（図示せず）を備えている。移動通信網は、移動機３に対して、一般的な移動電話網の通話サービスを提供する。
【００１４】
＜１−１−２．データサーバの構成＞
図２は、データサーバ２の構成を示すブロック図である。図２に示すように、データサーバ２は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０と、ＲＯＭ（Ｒｅａｄ−ＯｎｌｙＭｅｍｏｒｙ）２１と、ＲＡＭ（Ｒａｎｄｏｍ−ＡｃｃｅｓｓＭｅｍｏｒｙ）２２と、通信インターフェイス２３と、ハードディスク２４と、システムバス２５とを備えている。
ＣＰＵ２０は、ＲＯＭ２１に記憶される各種プログラムの記述に従い、ＲＡＭ２３を一時的な作業領域として用いつつ、データサーバ２の各構成部を中枢的に制御する。通信インターフェイス２３は、移動パケット通信網１を介して、データサーバ２が移動機３とパケット通信を行う際に用いられるポートである。データサーバ２に備わる各部は、システムバス２５を介して各種のデータを伝送する。そして、ハードディスク２４には、データサーバ２が移動機３に提供する各種のプログラムが記憶されている。このプログラムは、Ｊａｖａプログラミング言語によって記述されている。これを以下、ＪａｖａＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）と称する。ハードディスク２４に記憶されるＪａｖａＡＰは、ＪＡＲ（ＪａｖａＡＲｃｈｉｖｅ）ファイルと、ＡＤＦ（ＡｐｐｌｉｃａｔｉｏｎＤｅｓｃｒｉｐｔｏｒＦｉｌｅ）とに大別される。
【００１５】
ＪＡＲファイルは、プログラム本体であるクラスファイルと、プログラム本体を実行する際に必要となるリソースファイルのアーカイブである。リソースファイルとは、クラスファイルに記述された手順を実行する際に用いられるテキストデータ、楽音データ、画像データおよび動画データ等の参照データを意味する。一方、ＡＤＦとは、移動機３にＪａｖａＡＰをインストールする際に必要となる制御情報を記述した設定ファイルである。ＡＤＦに記述される具体的な制御情報としては、例えば、ＪａｖａＡＰの配信元サーバのＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＬｏｃａｔｏｒ）や、ＪａｖａＡＰインストール時に必要となるメモリ容量等が挙げられる。
【００１６】
＜１−１−３．移動機の構成＞
移動機３は、自機が在圏する無線セルを形成する基地局１２との間で、無線通信によるパケット通信および音声通話を行う。移動機３は、パケット通信によって、データサーバ２に記憶されるＪＡＲファイルをダウンロードする。このダウンロードに当たり、まず、移動機３は、データサーバ２からＡＤＦを受信する。そして、移動機３は、ＡＤＦに記述された制御情報を参照し、必要なメモリ容量を識別する等して、ＪａｖａＡＰをインストール可能であるか否かを判別する。移動機３は、ＪａｖａＡＰのインストールが可能であると判断できた場合のみ、ＪＡＲファイルをダウンロードする。
【００１７】
図３は、移動機３の構成を示すブロック図である。図３に示すように、移動機３は、アンテナ３０と、無線部３１と、ベースバンド処理部３２と、音声入出力部３３と、制御部３４と、表示部３５と、操作部３６と、電源部３７とを備えている。
【００１８】
アンテナ３０は、送受信アンテナである。無線部３１は、受信部、送信部および周波数シンセサイザ等を備えており、アンテナ３０を介して、基地局１２との間で無線通信を行う。このとき、無線部３１は、アナログ信号を、ベースバンド信号処理部３２との間で授受する。ベースバンド信号処理部３２は、マルチメディアインターフェイス、音声コーデックおよび画像コーデック等を備えており、各種のデータ処理を行う。
【００１９】
音声入出力部３３は、マイクロホンおよびスピーカを備えている。音声入出力部３３は、マイクロホンが集音した音声信号をベースバンド信号処理部３２に供給する。また、音声入出力部３３は、ベースバンド信号処理部３２から音声信号を供給されると、この音声信号に基づいて、スピーカから放音する。
【００２０】
制御部３４は、移動機３に備わる各部の動作を中枢的に制御する。この制御部３４は、ＭＰＵ（ＭｉｃｒｏＰｒｏｃｅｓｓｏｒＵｎｉｔ）として構成されており、ＣＰＵと、ＲＡＭと、ＲＯＭと、ＦｌａｓｈＲＯＭとを備えている。ＣＰＵは、ＲＡＭを一時的な作業領域とし、ＲＯＭおよびＦｌａｓｈＲＯＭに記憶される各種プログラムを実行する。ＲＯＭには、例えば、移動機３のオペレーティングシステム（以下、ＯＳと略称する）や、ＪａｖａＡＰの実行環境を構築するための各種プログラム等が記憶されている。一方、ＦｌａｓｈＲＯＭには、移動機３のネイティブコンポーネントが記憶されている。ここで、ネイティブコンポーネントとは、移動機３のＯＳに備わる機能のみによって実行可能なプログラムを意味する。また、ＦｌａｓｈＲＯＭには、データサーバ２からダウンロードされたＪａｖａＡＰが記憶される。
【００２１】
表示部３５は、液晶パネルおよびパネル駆動回路を有しており、制御部３４による制御の下で、各種情報を表示する。操作部３６は、テンキーおよび各種制御キーからなるキーパッドやキー検出回路を有しており、利用者のキー操作に対応する制御信号を制御部３４に出力する。電源部３７は、移動機３に備わる各部が動作するために必要な電力を供給する。
【００２２】
＜１−１−４．プログラム実行環境＞
図４は、移動機３におけるプログラム実行環境を示した図である。
ＪＡＭ（ＪａｖａＡｐｐｌｉｃａｔｉｏｎＭａｎａｇｅｒ）は、ＪａｖａＡＰを管理するための処理手順が記述されたソフトウェアモジュールである。このＪＡＭには、ＪａｖａＡＰを管理するための処理手順が記述されている。例えば、ＪＡＭには各ＪａｖａＡＰのＡＤＦを管理するための処理が記述されており、制御部３４は、ＪＡＭに記述された手順に従って各ＪａｖａＡＰのＡＤＦをＦｌａｓｈＲＯＭに記憶する。
ＫＶＭ（ＫＶｉｒｔｕａｌＭａｃｈｉｎｅ）は、ＪａｖａＡＰを実行するための処理手順が記述されたソフトウェアモジュールである。このＫＶＭをロードすることで、制御部３４は、ＪａｖａＡＰに記述されたコードを、実行コードであるバイトコードに翻訳することができるようになる。
【００２３】
ＣＬＤＣクラスライブラリ、オリジナル拡張ライブラリおよびメーカ拡張ライブラリは、制御部３４が必要に応じて参照する各種クラスファイルの集合である。ＣＬＤＣ（Ｃｏｎｎｅｃｔｅｄ，ＬｉｍｉｔｅｄＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）クラスライブラリは、Ｊ２ＭＥの標準として実装されるものであり、バイトコード生成のために必要とされる最も基本的な機能が定義されたクラスファイルの集合である。また、オリジナル拡張ライブラリは、移動パケット通信網１を運営する通信事業者が提供するサービスを享受するために必要となる機能、つまり、移動機３が移動パケット通信網１を介してパケット通信を行う最に必要となる各種機能等が定義されたクラスファイルの集合である。そして、メーカ独自拡張ライブラリは、移動機３の各製造メーカ毎の独自機能を実現する際に必要となる各種機能が定義されたクラスファイルの集合である。
【００２４】
ＪＡＲストレージは、データサーバ２から移動機３にＪＡＲファイルがダウンロードされた場合に、そのＪＡＲファイルを記憶する領域である。このＪＡＲストレージは、ＦｌａｓｈＲＯＭ内の一部の領域を用いて形成されている。移動機３は、データサーバ２からＪＡＲファイルをダウンロードすると、これをＪＡＲストレージに書きこむ。そして、ＪａｖａＡＰ実行の際には、制御部３４は、ＪＡＲストレージからプログラム本体であるクラスファイルを読み出し、これに記述された処理を実行する。
【００２５】
そして、制御部３４は、データサーバ２からＪＡＲファイルをダウンロードする際に、ＪａｖａＡＰ実行時に参照されるデータを格納可能な領域として、個別スクラッチパッド９０を形成する。この個別スクラッチパッド９０は、ＦｌａｓｈＲＯＭ内の一部の領域を用いて形成されており、各ＪａｖａＡＰに排他的に割り当てられる領域である。従って、制御部３４は、あるＪａｖａＡＰを実行中に、他のＪａｖａＡＰに割り当てられた個別スクラッチパッド９０にアクセスすることはできない。
【００２６】
個別スクラッチパッド９０が各ＪａｖａＡＰの専有領域として割り当てられる理由は次の通りである。
移動機３にインストール可能なＪａｖａＡＰは複数存在し得るが、その中には、高い秘匿性が要求されるデータを取り扱うものがある。例えば銀行振込を実行するアプリケーションプログラム等である。一般的なサンドボックスモデルでは、移動機はＪａｖａＡＰを実行中に、そのＪａｖａＡＰの配信元サーバとの間で通信を行うことが許されている。ここで、個別スクラッチパッド９０のようなＪａｖａＡＰ毎の専用記憶領域を設けないで共通の記憶領域のみを設けるとすれば、ＪａｖａＡＰはその共通の記憶領域を利用して互いにデータをやり取りすることが可能となる。この結果、仮に移動機が悪意のあるプログラマによって作成されたＪａｖａＡＰを実行してしまうと、そのＪａｖａＡＰの配信元サーバに対し他のＪａｖａＡＰのみが取り扱うべき秘匿性の高いデータを送信してしまう虞が生じてくる。このような事態を防止するため、移動機３では、個別スクラッチパッド９０を各ＪａｖａＡＰの専有領域とし、各々のＪａｖａＡＰが取り扱うデータを保護しているのである。
【００２７】
さらに、本実施形態の移動機３においては、複数のＪａｖａＡＰを連動させ、利用者にあたかも一つのＪａｖａＡＰが実行されているかのように認識させることが可能となっている。例えばデータサーバ２からダウンロードされたＪａｖａＡＰが、ロールプレイングゲームを定義したプログラム（以下、ＲＰＧアプリと記述する）であったと仮定する。制御部３４は、このＲＰＧアプリに記述された手順に従って、利用者が操作部３６を介して操作可能な数々のキャラクタ（ＲＰＧアプリの登場人物）表示部３５に表示させる。そして、利用者が操作するキャラクタが別のキャラクタと出会った場合には、制御部３４は、ＲＰＧアプリに記述された手順に従って、キャラクタ同士が会話する等の様子を表示部３５に表示させる。
【００２８】
ここで、利用者が操作する主人公のキャラクタと、その主人公と敵対するキャラクタとが出会った場合にはこれらキャラクタが格闘を開始する、というゲーム展開を利用者が所望したとする。この処理は、ＲＰＧアプリにキャラクタ同士の格闘が定義されていなければ実行することができない。そこで、このような場合、本実施形態では、移動機３がキャラクタ同士の格闘処理を実行するＪａｖａＡＰ（以下、格闘アプリと称する）をデータサーバ２からダウンロードし、これをインストールして、ＲＰＧアプリの実行中に割込み起動することが可能である。そして、移動機３がこのＲＰＧアプリと格闘アプリという二つのＪａｖａＡＰを切り換えながら実行することで、利用者にあたかも一つのＪａｖａＡＰが実行されているように認識させることができる。
【００２９】
上記のようなＪａｖａアプリの連動処理は以下のようにして実現される。
制御部３４がＲＰＧアプリを実行する際には、例えばゲームの難易度の設定や起動オプション等を定義するための初期設定ファイルや、ＲＰＧアプリを実行した結果として生成された得点データ等を記述するための処理結果ファイルが生成されることになる。制御部３４は、これらのファイル形式のデータを参照することで、ＲＰＧアプリをゲーム途中で中断し格闘アプリに遷移したような場合であっても、その中断した時のゲーム状況に合うような場面から格闘アプリを開始させることが可能となる。例えば、ＲＰＧアプリによるゲーム展開において主人公のキャラクタが取得した武器を格闘アプリによる格闘シーンにおいても利用することが可能となる。つまり、制御部３４の行う各々の処理の間に、一貫性を持たせることができるようになる。
【００３０】
このように、上記のように、二つのＪａｖａＡＰを切り換えつつ実行する場合には、ＲＰＧアプリによって生成されたファイルの内容を格闘アプリから参照し得るようにしなければならないし、またはその逆に、格闘アプリによって生成されたファイルの内容をＲＰＧアプリから参照し得るようにしなければならない。しかしながら、これらのＲＰＧアプリと格闘アプリとはＪａｖａＡＰとしては別々のものである。従って、例えば格闘アプリが生成したファイルを、格闘アプリに割り当てられた個別スクラッチパッド９０に記憶してしまうと、そのファイルを二つのＪａｖａＡＰ間で共有することができなくなってしまう。
そこで、本実施形態では、複数のＪａｖａＡＰが共有するファイルを記憶する領域を移動機３のＦｌａｓｈＲＯＭに設けるようにしている。これが、図４に示す共通スクラッチパッド９１である。この共通スクラッチパッド９１には格闘アプリが生成したファイルが記憶されるので、制御部３４は、そのファイルを、格闘アプリ実行中の場合であっても、ＲＰＧアプリ実行中の場合であっても、参照することができるようになる。
【００３１】
ただし、共通スクラッチパッドに記憶されたデータを不特定多数のＪａｖａＡＰが参照することができてしまうと望ましくない。なぜなら、共通スクラッチパッド９１においても、個別スクラッチパッド９０と同様に、秘匿性を保つことが要求されるデータが記憶され得る。そのため、共通スクラッチパッド９１へのアクセスについて、何らかの制限を設け、データが第三者の外部サーバに送信されないようにする必要がある。そこで、本実施形態の移動機３では、以下のような処理を行う。
【００３２】
まず、制御部３４は、共通スクラッチパッド９１にデータを書きこむ際には、実行中のＪａｖａＡＰのＡＤＦを参照し、プログラム配信元サーバのＵＲＬを識別する。そして、制御部３４は、データに識別したＵＲＬを付加して、共通スクラッチパッド９１に書きこむ。一方、共通スクラッチパッド９１からデータを読み出すに当たっては、制御部３４は、上記と同様にＡＤＦを参照して実行中のＪａｖａＡＰの配信元サーバのＵＲＬを識別するとともに、識別したＵＲＬが読み出すべきデータに付加されているＵＲＬと一致するか否かを判別する。そして、２つのＵＲＬが一致した場合にのみ、制御部３４は、共通スクラッチパッド９１からデータを読み出す。
【００３３】
さらに具体的に説明すると、制御部３４は、共通スクラッチパッド９１に格闘アプリのデータを書きこむ際には、格闘アプリのＡＤＦを参照して格闘アプリの配信元サーバのＵＲＬを識別する。そして、制御部３４は、識別したＵＲＬを付加して、データを共通スクラッチパッド９１に書きこむ。一方、このデータをＲＰＧアプリを実行中に参照する場合には、制御部３４は、ＲＰＧアプリのＡＤＦを参照して当該アプリの配信元サーバのＵＲＬを識別し、これを共通スクラッチパッド９１から読み出すべきデータに付加されたＵＲＬ、すなわち、格闘アプリのＵＲＬと比較する。そして、２つのＵＲＬが一致すれば、制御部３４は、共通スクラッチパッドからデータを読み出す。
【００３４】
上記の仕組みを備えることにより、本実施形態の移動機３では、同一サーバからダウンロードされたＪａｖａＡＰ間のみでデータ共有を実現することを可能とすると共に、個別スクラッチパッドを利用した場合とほぼ同等のデータ保護を行うことが可能となっているのである。
【００３５】
＜１−２．実施形態の動作＞
以下においては、説明を具体的に行うため、ＲＰＧアプリおよび格闘アプリを例に挙げ、移動機３の動作を中心に説明する。
＜１−２−１．ＪａｖａＡＰのインストールおよび実行＞
図５は、移動機３にＪａｖａＡＰをインストールする際の、制御部３４の動作を示すフローチャートである。
まず、操作部３６における利用者の操作に従って、移動機３は、データサーバ２からＲＰＧアプリのＡＤＦを受信する。これを詳述すると、制御部３４は、ＡＤＦのＵＲＬを引数とするＨＴＴＰ（ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）のＧＥＴ命令を、データサーバ２に送信する（ステップＳ１０１）。この結果として、制御部３４は、データサーバ２からＡＤＦを受信する（ステップＳ１０２）。次に、制御部３４は、受信したＡＤＦの記述内容からインストールに必要なメモリ容量を識別し、ＲＰＧアプリを移動機３にインストール可能であるか否かを判断する（ステップＳ１０３）。
【００３６】
そして、制御部３４は、移動機３においてＲＰＧアプリをインストール可能であると判断した場合に（ステップＳ１０３；Ｙｅｓ）、ＡＤＦをＦｌａｓｈＲＯＭに書きこみ（ステップＳ１０４）、ＡＤＦに記述されるＵＲＬを引数とするＧＥＴ命令を、データサーバ２に送信する（ステップＳ１０５）。この結果として、制御部３４は、データサーバ２からＲＰＧアプリのＪＡＲファイルを受信する（ステップＳ１０６）。制御部３４は、ＪＡＲファイルを受信すると、これをまずＪＡＲストレージに書きこむ（ステップＳ１０７）。そして、制御部３４は、ＡＤＦによって指定された容量のメモリ領域の個別スクラッチパッド９０をＦｌａｓｈＲＯＭに作成し（ステップＳ１０８）、ＲＰＧアプリに割り当てる（ステップＳ１０９）。さらに、制御部３４は、作成した個別スクラッチパッド９０に、ＲＰＧアプリの初期設定ファイルを書きこむ（ステップＳ１１０）。これで、ＲＰＧアプリのダウンロードおよびインストールが完了する。
【００３７】
上記のようにしてインストールされたＲＰＧアプリは、次のようにして実行される。まず、利用者の操作に基づき、操作部３６から制御部３４に、ＲＰＧアプリの実行を指令する制御信号が供給される。すると、これをトリガとして、制御部３４がＲＰＧアプリの実行処理を開始する。制御部３４は、ＪＡＭおよびＫＶＭをロードして、ＪａｖａＡＰ実行環境を構築する。そして、制御部３４は、ＲＰＧアプリに割り当てられた個別スクラッチパッド９０から初期設定ファイルを読み出し、その記述内容から、ＲＰＧアプリの実行条件を識別する。その後、制御部３４は、ＪＡＲストレージからＲＰＧアプリ本体であるクラスファイルを読み出し、これを実行する。
【００３８】
＜１−２−２．ＪａｖａＡＰの追加インストールおよびデータ共有＞
図６は、移動機３にＪａｖａＡＰを追加インストールし、データ共有する際の、制御部３４の動作を示すフローチャートである。
まず、移動機３においてＲＰＧアプリを実行中に、利用者が操作部３６を介して所定の操作を行うと、これをトリガとして、インストール処理が開始される。制御部３４は、無線部３０を介して、データサーバ２に対して、ＲＰＧアプリとデータ共有可能なＪａｖａＡＰの一覧を示すファイルのＵＲＬを引数とするＧＥＴ命令を送信する（ステップＳ２０１）。そして、データ共有可能なＪａｖａＡＰの一覧を受信すると、制御部３４は、このデータを表示部３５に表示する（ステップＳ２０２）。そして、制御部３４は、操作部３６を介した利用者の入力を待機する（ステップＳ２０３）。
【００３９】
ステップＳ２０３において、利用者が操作部３６を介して、格闘アプリを選択する操作を行うと（ステップＳ２０３；Ｙｅｓ）、制御部３４は、無線部３０を介して、格闘アプリのＡＤＦのＵＲＬを引数とするＧＥＴ命令を、データサーバ２に送信する（ステップＳ２０４）。そして、制御部３４は、格闘アプリのＡＤＦを受信すると（Ｓ２０５）、このＡＤＦの記述内容を解釈し、格闘アプリをダウンロード、実行するために必要な条件を判別する（ステップＳ２０６）。以下、ステップＳ２０７〜Ｓ２１０までの動作は、上述のステップＳ１０４〜Ｓ１０７までの動作と同様であるため、その説明を省略する。
【００４０】
その後、制御部３４は、ＲＰＧアプリの初期設定ファイルに格闘アプリを割込み起動する際の条件を書き込むとともに、格闘アプリの個別スクラッチパッド９０に初期設定ファイルを書込み（ステップＳ２１１）、処理を終了する。この後、制御部３４は、初期設定ファイルに記述された条件が成立した場合に、実行中のＲＰＧアプリを待機状態に遷し、格闘アプリを割込み起動するようになる。
【００４１】
さて、上記の手順でインストールされた格闘アプリは、次の手順で割込み起動され、実行される。
図７は、追加インストールされたＪａｖａＡＰを実行する際の制御部３４の動作を示すフローチャートである。
【００４２】
まず、格闘アプリの割込み起動が初めてであった場合（ステップＳ３０１；Ｙｅｓ）、制御部３４は、格闘アプリの個別スクラッチパッド９０から初期設定ファイルを読出し（ステップＳ３０２）、その記述内容を判別する（ステップＳ３０３）。そして、制御部３４は、格闘アプリの初期設定ファイルに、ＲＰＧアプリのゲーム難度等共有すべき設定を追加し、これを共通スクラッチパッド９１に書き込む（ステップＳ３０４）。その後、制御部３４は、ＪＡＲストレージから格闘アプリのクラスファイルを読出し（ステップＳ３０５）、これを実行する（ステップＳ３０６）。
【００４３】
このとき、格闘アプリの実行に伴なって得点データ等のデータが生成された場合、制御部３４は、共通スクラッチパッド９１に処理結果ファイルを作成し、このファイルに、生成されたデータを追加していく（ステップＳ３０７）。また、制御部３４は、処理結果ファイルに、格闘アプリのＡＤＦに記述されている配信元サーバのＵＲＬを、処理結果ファイルに追加する（ステップＳ３０７）。その後、制御部３４は、格闘アプリの実行を終了すると、待機状態にあるＪａｖａＡＰを再実行する（ステップＳ３０８）。
【００４４】
また、格闘アプリの割込み起動が２回目以降である場合には（ステップＳ３０１；Ｎｏ）、制御部３４は、共通スクラッチパッド９１から格闘アプリの初期設定ファイルを読み出す（ステップＳ３０９）。そして、制御部３４は、初期設定ファイルの記述内容を識別し（ステップＳ３１０）、これに基づいて、格闘アプリを実行する。
【００４５】
さて、格闘アプリの実行結果として生成されたデータを、ＲＰＧアプリ実行中に利用する場合、制御部３４は、上記ステップＳ３０７において作成された共通スクラッチパッド９１に書きこまれた処理結果ファイルを読出し、これを利用する。
図８は、制御部３４が共通スクラッチパッド９１にアクセスする際の動作を示すフローチャートである。
まず、制御部３４は、読み出すべきファイル中から、ファイルが書きこまれた際に実行中であったＪａｖａＡＰの配信元サーバのＵＲＬを取得する（ステップＳ４０１）。上記の例では、制御部３４は、ＲＰＧアプリの配信元サーバのＵＲＬを取得することとなる。そして、制御部３４は、取得したＵＲＬを、現在実行中のＪａｖａＡＰの配信元サーバのＵＲＬと比較する（ステップＳ４０２）。そして、２つのＵＲＬが一致した場合のみ（ステップＳ４０２；Ｙｅｓ）、制御部３４は、共通スクラッチパッド９１からデータを読み出す（ステップＳ４０３）。一方、２つのＵＲＬが一致しなかった場合（ステップＳ４０２；Ｎｏ）には、制御部３４は、共通スクラッチパッド９１からのデータ読出しを中止し、処理を終了する。
【００４６】
なお、格闘アプリには、個別スクラッチパッド９０が割り当てられているため、格闘アプリを単体で起動することも可能である。格闘アプリを単体で起動する場合には、制御部３４は、初期設定ファイルおよび処理結果ファイルの読出しおよび書き込みを、格闘アプリに割り当てられた個別スクラッチパッド９０に対して行う。そうすることで、格闘アプリ実行の際に生成されるデータを、通常のＪａｖａＡＰと同様に保護することが可能となる。
【００４７】
＜３．変形例＞
なお、本発明の通信システム、サーバ、移動機およびデータ記憶方法は、上述の実施形態に限定されるものではなく、本発明の技術的思想の範囲内で種々の変更を加えることが可能である。
【００４８】
（変形例１）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しについて、データ書込み時に付加された配信元サーバのＵＲＬと、実行中のＪａｖａＡＰのＡＤＦに記述される配信元サーバのＵＲＬとを比較し、２つのＵＲＬが一致した場合に、データ共有を許可する態様を採って説明を行った。しかし、共通スクラッチパッド９１からのデータ読出しをプログラム配信元サーバに限らず、プログラム配信元サーバと同一ドメインに属する複数のサーバに拡張する態様を採っても構わない。要は、本発明は、共通スクラッチパッド９１に記憶されたデータを複数のプログラム間で共有する際に、特定のセキュリティポリシーに基づいて、共通スクラッチパッド９１からのデータ読出しを認証する態様であれば、認証が成立する対象の範囲は問わない。
【００４９】
（変形例２）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しの際の認証に、ＵＲＬを用いる態様を例に採って説明を行った。しかし、認証に利用する情報は、ＵＲＬには限られない。認証には、例えば、ＩＰアドレスやＭＡＣアドレス等、プログラム配信元サーバを一意に特定可能な情報であれば、どのようなものを用いても構わない。要は、本発明は、特定のセキュリティポリシーに基づいて、共通スクラッチパッド９１からのデータ読出しを認証を行う態様であれば、認証に用いる情報はどのようなものであっても構わない。
【００５０】
（変形例３）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しは、制御部３４がＡＤＦを参照して実行中のＪａｖａＡＰの配信元サーバのＵＲＬを取得し、これを読み出すべきデータに付加されたＵＲＬと比較することによって認証された。しかし、共通スクラッチパッド９１からのデータ読出しの認証方法は、これに限られるものではない。例えばファイル名等、共通スクラッチパッド９１に書きこまれるデータを一意に識別可能な情報と、データの読出し権限が与えられるＪａｖａＡＰの配信元サーバのＵＲＬとを対応付けた管理テーブルをＦｌａｓｈＲＯＭに記憶し、これを共通スクラッチパッド９１からのデータ読出しにおいて用いることも可能である。この場合であれば、共通スクラッチパッド９１からのデータ読出しに当たって、制御部３４は、実行中のＪａｖａＡＰの配信元サーバのＵＲＬと、管理テーブルにおいて読み出すべきデータと対応付けられているＵＲＬとを比較し、２つのＵＲＬが一致した場合にのみ、データ読出しを行うようにすればよい。要は、本発明は、特定のセキュリティポリシーに基づき、共通スクラッチパッド９１からのデータ読出しの認証を行うことの出来る態様であれば、その認証に用いる情報は何処に記憶されていても良い。
【００５１】
（変形例４）上述の実施形態においては、制御部３４が、実行中のＪａｖａＡＰの配信元サーバからデータ共有可能なＪａｖａＡＰの一覧を示すファイルをダウンロードし、このファイルの記述に基づいて、共通スクラッチパッド９１を利用したデータ共有を実現する態様を採って説明を行った。しかし、データ共有可能なＪａｖａＡＰのＵＲＬ乃至プログラム名を予めＡＤＦに記述しておき、これに基づいて共通スクラッチパッド９１にアクセスする態様を採っても構わない。要は、本発明は、特定のセキュリティポリシーに基づき、共通スクラッチパッド９１からのデータ読出しの認証を行うことの出来る態様であれば、その認証条件は、サーバ２において決定されるものであっても、移動機３において選択されるものであっても良い。
【００５２】
【発明の効果】
以上、説明したように、本発明によれば、各プログラムの実行中に利用されるデータのセキュリティを保持するとともに、複数のプログラム間のデータ共有を可能とし、データを扱う際の自由度を向上させることが可能である。
【図面の簡単な説明】
【図１】通信システムの全体構成を示す図である。
【図２】データサーバの構成を示すブロック図である。
【図３】移動機の構成を示すブロック図である。
【図４】移動機におけるプログラム実行環境を示した図である。
【図５】移動機にＪａｖａＡＰをインストールする際の制御部の動作を示すフローチャートである。
【図６】移動機にＪａｖａＡＰを追加インストールしデータ共有する際の、制御部の動作を示すフローチャートである。
【図７】追加インストールされたＪａｖａＡＰを実行する際の制御部の動作を示すフローチャートである。
【図８】制御部が共通スクラッチパッドにアクセスする際の動作を示すフローチャートである。
【符号の説明】
１００…通信システム、１…移動パケット通信網、２…データサーバ、３…移動機、３４…制御部、９０…個別スクラッチパッド、９１…共通スクラッチパッド。[0001]
[Prior art]
BACKGROUND ART Conventionally, a mobile device capable of executing a program downloaded via a mobile communication network has been known. As such a mobile device, for example, there is a mobile device capable of executing a program described in a Java programming language. In this mobile device, a so-called sandbox is used to protect data stored in the mobile device from leaking to an external server or the like. The technique referred to as a sandbox is described in Patent Document 1, for example.
[0002]
[Patent Document 1]
JP-A-10-254783
[0003]
In the case of data protection using a sandbox, an exclusive memory area is allocated to each program installed in a mobile device. Therefore, the mobile device cannot access a memory area allocated to another program while executing a certain program. In addition, in the data protection by the sandbox, the only external server with which the mobile device can communicate while a certain program is being executed is the distribution source server of the program being executed. Therefore, the use of the sandbox prevents data stored in the mobile device from leaking to an untrusted third party external server.
[0004]
[Problems to be solved by the invention]
However, there is a trade-off between data security and the degree of freedom in handling data. As described above, when data protection is performed using a sandbox, it becomes impossible to share data between a plurality of programs. As a result, there arises a problem that a plurality of programs installed in the mobile device cannot operate in cooperation with each other while sharing data, that is, there is a problem that the extensibility of the program in the mobile device is limited.
In view of such circumstances, the present invention provides a communication system, a server, a mobile device, a program, and a recording medium that allow a plurality of programs to share data while maintaining security.
[0005]
[Means for Solving the Problems]
In order to solve the above problems, the present invention provides a mobile device accommodated in a mobile communication network, and a plurality of servers that transmit a program executable by the mobile device to the mobile device via the mobile communication network. Wherein the at least one server transmits the program and determination information for the mobile device to determine how to allocate a memory area in the mobile device to the program; A plurality of the programs transmitted from the plurality of servers, a receiving means for receiving the determination information transmitted from the at least one server, for each of the plurality of received programs, An individual area allocating means for allocating a memory area dedicated to each program, and a plurality of specific programs determined based on the received determination information. The shared area allocating means for allocating a memory area sharable by the specific plurality of programs, and the memory area allocated to the program to be executed by the individual area allocating means and the shared area allocating means. And a control means for performing the following.
[0006]
The present invention relates to a method for assigning a memory area to a program received by the mobile device via the mobile communication network, for the mobile device accommodated in the mobile communication network. A server is provided which is designated for.
[0007]
Further, the present invention provides a plurality of executable programs transmitted from a plurality of servers and a determination for determining how to allocate a memory area to the programs transmitted from at least one server. Receiving means for receiving information, individual area allocating means for allocating a memory area dedicated to each program for each of the plurality of programs received, and a plurality of specific areas determined based on the received determination information. For a program, a shared area allocating means for allocating a memory area sharable by the specific plurality of programs, and a memory area allocated to the program to be executed by the individual area allocating means and the shared area allocating means are used. And a control unit for executing the program. Subjected to.
[0008]
In a preferred aspect, the control means, when writing data in the memory area allocated by the shared area allocating means, a recording means for adding the judgment information to the data, and a memory allocated by the shared area allocating means When reading data from an area, determining means for determining readability based on the determination information added to the data to be read; and sharing the data if the determination result by the determination means permits data reading. Reading means for accessing the memory area allocated by the area allocating means.
[0009]
In another preferred aspect, the control means, when writing data to the memory area allocated by the shared area allocating means, stores the determination information corresponding to the program being executed in the data to be written. Storage means for storing in association with the corresponding determination information; and when reading data from the memory area allocated by the shared area allocation means, the determination information corresponding to the program being executed and the data to be read. Determining means for determining whether or not reading is possible based on the determination information stored in association with the storage means; and assigning the shared area when the determination result by the determining means permits data reading. Reading means for accessing the memory area allocated by the means.
[0010]
In another preferred aspect, the determination information is an address that uniquely indicates a distribution source server of the program.
In another preferred aspect, the determination information is an address uniquely indicating a distribution source server of a program to be shared.
In another preferred aspect, the determination information is a program name of a program to be shared.
In another preferred embodiment, the program is described in Java (registered trademark), and the determination information is described in an ADF (Application Descriptor File).
[0011]
The present invention provides a computer with a plurality of programs transmitted from a plurality of servers and a determination for determining how to allocate a memory area to the programs transmitted from at least one server. A function of receiving information, a function of allocating a memory area dedicated to each program to each of the plurality of programs received, and a function of assigning a specific program determined based on the received determination information. A function of allocating a memory area sharable by the specific programs and a memory area dedicated to each program and a memory area sharable by the specific programs for a program to be executed, A program for realizing the function to be executed and the program A computer-readable recording medium recording a beam.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
<1. First Embodiment>
<1-1. Configuration of First Embodiment>
<1-1-1. System Configuration>
FIG. 1 is a diagram illustrating an overall configuration of a communication system 100 according to an embodiment of the present invention. As shown in FIG. 1, a communication system 100 includes a mobile packet communication network 1 and a plurality of data servers 2-1 to 2-n (n = natural number. Hereinafter, when there is no need to distinguish individual devices, Server 2) and a mobile device 3. In FIG. 1, only devices necessary for understanding the configuration of the communication system 100 are shown to prevent the drawing from being complicated.
[0013]
The mobile packet communication network 1 provides the mobile device 3 with a packet communication service. As shown in FIG. 1, the mobile packet communication network 1 includes switching stations 11, and a base station 12 is connected to each switching station 11. The base station 12 outputs a radio wave used for communication with the mobile device 3, and the range of the radio wave is formed as a radio cell. The base station 12 performs wireless packet communication with the mobile device 3 located in a wireless cell formed by the base station 12.
The communication system 100 includes a mobile telephone network (not shown) in addition to the mobile packet communication network 1. The mobile communication network provides the mobile device 3 with a general mobile telephone network communication service.
[0014]
<1-1-2. Configuration of Data Server>
FIG. 2 is a block diagram showing the configuration of the data server 2. As shown in FIG. 2, the data server 2 includes a CPU (Central Processing Unit) 20, a ROM (Read-Only Memory) 21, a RAM (Random-Access Memory) 22, a communication interface 23, a hard disk 24, A system bus 25 is provided.
The CPU 20 centrally controls each component of the data server 2 according to the description of various programs stored in the ROM 21 while using the RAM 23 as a temporary work area. The communication interface 23 is a port used when the data server 2 performs packet communication with the mobile device 3 via the mobile packet communication network 1. Each unit provided in the data server 2 transmits various data via the system bus 25. The hard disk 24 stores various programs provided by the data server 2 to the mobile device 3. This program is described in the Java programming language. This is hereinafter referred to as Java AP (Application). The Java AP stored on the hard disk 24 is roughly classified into a JAR (Java Archive) file and an ADF (Application Descriptor File).
[0015]
The JAR file is an archive of a class file, which is the main body of the program, and resource files necessary for executing the main body of the program. The resource file refers to reference data such as text data, musical sound data, image data, and moving image data used when executing the procedure described in the class file. On the other hand, the ADF is a setting file in which control information necessary for installing Java AP on the mobile device 3 is described. Specific control information described in the ADF includes, for example, a URL (Uniform Resource Locator) of a Java AP distribution source server, a memory capacity required at the time of Java AP installation, and the like.
[0016]
<1-1-3. Configuration of mobile device>
The mobile device 3 performs wireless communication packet communication and voice communication with the base station 12 forming a wireless cell in which the mobile device 3 is located. The mobile device 3 downloads the JAR file stored in the data server 2 by packet communication. Upon this download, first, the mobile device 3 receives the ADF from the data server 2. Then, the mobile device 3 refers to the control information described in the ADF, identifies the necessary memory capacity, and determines whether the Java AP can be installed. The mobile device 3 downloads the JAR file only when it is determined that the Java AP can be installed.
[0017]
FIG. 3 is a block diagram illustrating a configuration of the mobile device 3. As shown in FIG. 3, the mobile device 3 includes an antenna 30, a radio unit 31, a baseband processing unit 32, a voice input / output unit 33, a control unit 34, a display unit 35, an operation unit 36, And a power supply unit 37.
[0018]
The antenna 30 is a transmitting / receiving antenna. The wireless unit 31 includes a receiving unit, a transmitting unit, a frequency synthesizer, and the like, and performs wireless communication with the base station 12 via the antenna 30. At this time, the wireless unit 31 transmits and receives an analog signal to and from the baseband signal processing unit 32. The baseband signal processing unit 32 includes a multimedia interface, an audio codec, an image codec, and the like, and performs various data processing.
[0019]
The audio input / output unit 33 includes a microphone and a speaker. The audio input / output unit 33 supplies the audio signal collected by the microphone to the baseband signal processing unit 32. When the audio input / output unit 33 is supplied with the audio signal from the baseband signal processing unit 32, the audio input / output unit 33 emits sound from a speaker based on the audio signal.
[0020]
The control unit 34 centrally controls the operation of each unit included in the mobile device 3. The control unit 34 is configured as an MPU (Micro Processor Unit), and includes a CPU, a RAM, a ROM, and a FlashROM. The CPU uses the RAM as a temporary work area and executes various programs stored in the ROM and the FlashROM. The ROM stores, for example, an operating system (hereinafter abbreviated as OS) of the mobile device 3 and various programs for constructing an execution environment of JavaAP. On the other hand, native components of the mobile device 3 are stored in the FlashROM. Here, the native component means a program that can be executed only by a function included in the OS of the mobile device 3. The FlashROM stores JavaAP downloaded from the data server 2.
[0021]
The display unit 35 has a liquid crystal panel and a panel drive circuit, and displays various information under the control of the control unit 34. The operation unit 36 has a keypad including a numeric keypad and various control keys and a key detection circuit, and outputs a control signal corresponding to a user's key operation to the control unit 34. The power supply unit 37 supplies electric power required for each unit included in the mobile device 3 to operate.
[0022]
<1-1-4. Program execution environment>
FIG. 4 is a diagram illustrating a program execution environment in the mobile device 3.
JAM (Java Application Manager) is a software module in which a processing procedure for managing Java AP is described. This JAM describes a processing procedure for managing a Java AP. For example, a process for managing the ADF of each JavaAP is described in the JAM, and the control unit 34 stores the ADF of each JavaAP in the FlashROM according to the procedure described in the JAM.
KVM (K Virtual Machine) is a software module in which a processing procedure for executing Java AP is described. By loading the KVM, the control unit 34 can translate the code described in the Java AP into a bytecode which is an execution code.
[0023]
The CLDC class library, the original extension library, and the manufacturer extension library are a set of various class files that the control unit 34 refers to as needed. The CLDC (Connected, Limited Device Configuration) class library is implemented as a J2ME standard, and is a set of class files in which the most basic functions required for bytecode generation are defined. Further, the original extension library is a function necessary for enjoying the service provided by the communication carrier operating the mobile packet communication network 1, that is, the mobile device 3 performs packet communication via the mobile packet communication network 1. It is a set of class files in which various functions and the like that are needed most are defined. The manufacturer-specific extension library is a set of class files in which various functions necessary for realizing the functions unique to each manufacturer of the mobile device 3 are defined.
[0024]
The JAR storage is an area for storing a JAR file when the JAR file is downloaded from the data server 2 to the mobile device 3. This JAR storage is formed using a part of the area in the FlashROM. When the mobile device 3 downloads the JAR file from the data server 2, it writes this in the JAR storage. Then, at the time of JavaAP execution, the control unit 34 reads a class file, which is a program main body, from the JAR storage and executes the processing described therein.
[0025]
Then, when downloading the JAR file from the data server 2, the control unit 34 forms the individual scratch pad 90 as an area in which the data referred to when executing the Java AP can be stored. The individual scratch pad 90 is formed by using a part of the area in the FlashROM, and is an area exclusively assigned to each Java AP. Therefore, the control unit 34 cannot access the individual scratch pad 90 assigned to another Java AP while executing a certain Java AP.
[0026]
The reason why the individual scratch pad 90 is allocated as the exclusive area of each Java AP is as follows.
There can be a plurality of Java APs that can be installed in the mobile device 3, and some of them handle data that requires high confidentiality. For example, it is an application program for executing a bank transfer. In a general sandbox model, a mobile device is allowed to perform communication with a Java AP distribution source server while executing a Java AP. Here, if only a common storage area is provided without providing a dedicated storage area for each Java AP such as the individual scratch pad 90, the Java APs can exchange data with each other using the common storage area. It becomes. As a result, if the mobile device executes a Java AP created by a malicious programmer, there is a possibility that highly confidential data that should be handled only by other Java APs will be transmitted to the distribution server of the Java AP. Come up. In order to prevent such a situation, in the mobile device 3, the individual scratch pad 90 is used as an exclusive area of each Java AP, and the data handled by each Java AP is protected.
[0027]
Further, in the mobile device 3 of the present embodiment, it is possible to link a plurality of Java APs and make the user recognize as if one Java AP is being executed. For example, it is assumed that the Java AP downloaded from the data server 2 is a program that defines a role playing game (hereinafter, referred to as an RPG application). The control unit 34 causes a number of characters (characters of the RPG application) displayed by the user via the operation unit 36 to be displayed on the display unit 35 in accordance with the procedure described in the RPG application. Then, when the character operated by the user encounters another character, the control unit 34 causes the display unit 35 to display, for example, a state in which the characters have a conversation in accordance with the procedure described in the RPG application.
[0028]
Here, it is assumed that the user desires a game development in which, when a hero character operated by the user and a character opposing the hero character meet, the characters start fighting. This process cannot be executed unless fighting between characters is defined in the RPG application. Therefore, in such a case, in the present embodiment, the mobile device 3 downloads a Java AP (hereinafter, referred to as a fighting application) for executing the fighting process between the characters from the data server 2, installs it, and installs the RPG application. It is possible to start an interrupt during execution. The mobile device 3 switches and executes the two Java APs, the RPG application and the fighting application, so that the user can be recognized as if one Java AP is being executed.
[0029]
The interlocking processing of the Java application as described above is realized as follows.
When the control unit 34 executes the RPG application, the control unit 34 describes, for example, an initial setting file for defining the difficulty level of the game and an activation option, and score data generated as a result of executing the RPG application. Is generated. The control unit 34 refers to the data in these file formats, so that even in the case where the RPG application is interrupted in the middle of the game and transitions to the fighting application, a scene that matches the game situation at the time of the interruption is displayed. It is possible to start a fighting app from. For example, it is possible to use the weapon acquired by the hero character in the game development by the RPG application also in the fighting scene by the fighting application. That is, consistency can be provided between the processes performed by the control unit 34.
[0030]
As described above, when two Java APs are executed while being switched as described above, the content of the file generated by the RPG application must be referred to from the fighting application, or vice versa. The content of the file generated by the application must be referred to from the RPG application. However, these RPG applications and fighting applications are different as JavaAP. Therefore, for example, if a file generated by the fighting application is stored in the individual scratchpad 90 assigned to the fighting application, the file cannot be shared between the two Java APs.
Therefore, in the present embodiment, an area for storing files shared by a plurality of Java APs is provided in the FlashROM of the mobile device 3. This is the common scratch pad 91 shown in FIG. Since the file generated by the fighting application is stored in the common scratch pad 91, the control unit 34 stores the file regardless of whether the fighting application is being executed or the RPG application is being executed. You can refer to it.
[0031]
However, it is not desirable that an unspecified number of Java APs can refer to the data stored in the common scratch pad. This is because, similarly to the individual scratch pad 90, data required to maintain confidentiality can be stored in the common scratch pad 91 as well. Therefore, it is necessary to set some restrictions on access to the common scratch pad 91 so that data is not transmitted to a third party external server. Therefore, the mobile device 3 of the present embodiment performs the following processing.
[0032]
First, when writing data to the common scratch pad 91, the control unit 34 refers to the ADF of the running Java AP and identifies the URL of the program distribution server. Then, the control unit 34 writes the identified URL to the common scratch pad 91 by adding the identified URL to the data. On the other hand, when reading data from the common scratch pad 91, the control unit 34 identifies the URL of the Java AP distribution server being executed with reference to the ADF in the same manner as described above, and adds the identified URL to the data to be read. It is determined whether or not it matches the added URL. Then, only when the two URLs match, the control unit 34 reads data from the common scratch pad 91.
[0033]
More specifically, when writing the data of the fighting application to the common scratch pad 91, the control unit 34 refers to the ADF of the fighting application and identifies the URL of the distribution server of the fighting application. Then, the control unit 34 writes the data into the common scratch pad 91 by adding the identified URL. On the other hand, when referring to this data during the execution of the RPG application, the control unit 34 refers to the ADF of the RPG application, identifies the URL of the distribution source server of the application, and reads this from the common scratch pad 91. This is compared with the URL added to the power data, that is, the URL of the fighting application. If the two URLs match, the control unit 34 reads data from the common scratch pad.
[0034]
By providing the above mechanism, in the mobile device 3 of the present embodiment, it is possible to realize data sharing only between Java APs downloaded from the same server, and it is substantially equivalent to the case where an individual scratch pad is used. It is possible to protect data.
[0035]
<1-2. Operation of Embodiment>
In the following, in order to specifically explain, the operation of the mobile device 3 will be mainly described by taking an RPG application and a fighting application as examples.
<1-2-1. Installation and execution of Java AP>
FIG. 5 is a flowchart illustrating the operation of the control unit 34 when installing the Java AP in the mobile device 3.
First, the mobile device 3 receives the ADF of the RPG application from the data server 2 according to a user operation on the operation unit 36. More specifically, the control unit 34 transmits an HTTP (Hypertext Transfer Protocol) GET command using the URL of the ADF as an argument to the data server 2 (step S101). As a result, the control unit 34 receives the ADF from the data server 2 (Step S102). Next, the control unit 34 identifies the memory capacity required for the installation from the received description content of the ADF, and determines whether the RPG application can be installed on the mobile device 3 (step S103).
[0036]
When the control unit 34 determines that the RPG application can be installed in the mobile device 3 (step S103; Yes), the control unit 34 writes the ADF into the FlashROM (step S104), and uses the URL described in the ADF as an argument. The GET command to be transmitted to the data server 2 (step S105). As a result, the control unit 34 receives the JAR file of the RPG application from the data server 2 (Step S106). When receiving the JAR file, the control unit 34 first writes the JAR file into the JAR storage (step S107). Then, the control unit 34 creates the individual scratch pad 90 in the memory area having the capacity designated by the ADF in the FlashROM (step S108), and assigns it to the RPG application (step S109). Further, the control unit 34 writes an RPG application initialization file in the created individual scratch pad 90 (step S110). This completes the download and installation of the RPG application.
[0037]
The RPG application installed as described above is executed as follows. First, a control signal for instructing execution of the RPG application is supplied from the operation unit 36 to the control unit 34 based on a user operation. Then, using this as a trigger, the control unit 34 starts the execution process of the RPG application. The control unit 34 loads the JAM and the KVM and constructs a JavaAP execution environment. Then, the control unit 34 reads the initialization file from the individual scratch pad 90 assigned to the RPG application, and identifies the execution condition of the RPG application from the description content. Thereafter, the control unit 34 reads a class file, which is the main body of the RPG application, from the JAR storage and executes the class file.
[0038]
<1-2-2. Additional installation and data sharing of Java AP>
FIG. 6 is a flowchart showing the operation of the control unit 34 when a Java AP is additionally installed in the mobile device 3 and data is shared.
First, when the user performs a predetermined operation via the operation unit 36 during execution of the RPG application in the mobile device 3, the installation process is started with this as a trigger. The control unit 34 transmits a GET command to the data server 2 via the wireless unit 30 with the URL of a file indicating a list of Java APs that can share data with the RPG application as an argument (step S201). Then, when receiving the list of JavaAPs that can share data, the control unit 34 displays this data on the display unit 35 (step S202). Then, the control unit 34 waits for a user input via the operation unit 36 (step S203).
[0039]
In step S203, when the user performs an operation of selecting a fighting application via the operation unit 36 (step S203; Yes), the control unit 34 sends the URL of the ADF of the fighting application via the wireless unit 30 as an argument. Is transmitted to the data server 2 (step S204). Then, when receiving the ADF of the fighting application (S205), the control unit 34 interprets the description content of the ADF, and determines conditions necessary for downloading and executing the fighting application (step S206). Hereinafter, the operations in steps S207 to S210 are the same as the operations in steps S104 to S107 described above, and a description thereof will be omitted.
[0040]
Thereafter, the control unit 34 writes a condition for interrupting and starting the fighting application in the initial setting file of the RPG application, writes the initial setting file in the individual scratchpad 90 of the fighting application (step S211), and ends the process. Thereafter, when the condition described in the initialization file is satisfied, the control unit 34 shifts the running RPG application to a standby state and interrupts and starts the fighting application.
[0041]
Now, the fighting application installed in the above procedure is started by interruption in the following procedure and executed.
FIG. 7 is a flowchart illustrating the operation of the control unit 34 when executing the Java AP additionally installed.
[0042]
First, when interrupting activation of the fighting application is the first time (step S301; Yes), the control unit 34 reads an initialization file from the individual scratch pad 90 of the fighting application (step S302), and determines the description content (step S302). Step S303). Then, the control unit 34 adds a setting to be shared, such as the game difficulty of the RPG application, to the initial setting file of the fighting application, and writes the setting to the common scratch pad 91 (step S304). After that, the control unit 34 reads out the class file of the fighting application from the JAR storage (step S305) and executes it (step S306).
[0043]
At this time, if data such as score data is generated along with the execution of the fighting application, the control unit 34 creates a processing result file in the common scratch pad 91, and adds the generated data to this file. (Step S307). Further, the control unit 34 adds the URL of the distribution source server described in the ADF of the fighting application to the processing result file (step S307). After that, when the execution of the fighting application ends, the control unit 34 re-executes the Java AP in the standby state (Step S308).
[0044]
In addition, when the interrupt activation of the fighting application is the second or subsequent time (Step S301; No), the control unit 34 reads the initial setting file of the fighting application from the common scratch pad 91 (Step S309). Then, the control unit 34 identifies the description content of the initialization file (step S310), and executes the fighting application based on the identification content.
[0045]
When the data generated as the execution result of the fighting application is used during the execution of the RPG application, the control unit 34 reads the processing result file written in the common scratch pad 91 created in step S307, Take advantage of this.
FIG. 8 is a flowchart showing an operation when the control unit 34 accesses the common scratch pad 91.
First, the control unit 34 acquires the URL of the distribution server of the Java AP that was being executed when the file was written from among the files to be read (step S401). In the above example, the control unit 34 acquires the URL of the distribution source server of the RPG application. Then, the control unit 34 compares the obtained URL with the URL of the distribution server of the currently executing JavaAP (step S402). Only when the two URLs match (step S402; Yes), the control unit 34 reads data from the common scratch pad 91 (step S403). On the other hand, if the two URLs do not match (step S402; No), the control unit 34 stops reading data from the common scratch pad 91 and ends the processing.
[0046]
In addition, since the individual scratch pad 90 is allocated to the fighting application, the fighting application can be started alone. When starting the fighting application alone, the control unit 34 reads and writes the initial setting file and the processing result file to the individual scratch pad 90 assigned to the fighting application. By doing so, it is possible to protect the data generated during the execution of the fighting application in the same way as a normal Java AP.
[0047]
<3. Modification>
Note that the communication system, server, mobile device, and data storage method of the present invention are not limited to the above-described embodiments, and various changes can be made within the technical idea of the present invention. .
[0048]
(Modification 1) In the above-described embodiment, for reading data from the common scratch pad 91, the URL of the distribution server added at the time of writing the data and the URL of the distribution server described in the ADF of the running Java AP are described. , And an explanation has been given of a mode in which data sharing is permitted when the two URLs match. However, a mode in which data reading from the common scratch pad 91 is extended to a plurality of servers belonging to the same domain as the program distribution source server is not limited to the program distribution source server. In short, the present invention is an embodiment that authenticates data reading from the common scratch pad 91 based on a specific security policy when sharing data stored in the common scratch pad 91 among a plurality of programs. The range of the target for which the authentication is established does not matter.
[0049]
(Modification 2) In the above-described embodiment, an example has been described in which the URL is used for authentication when reading data from the common scratch pad 91. However, information used for authentication is not limited to a URL. For authentication, for example, any information such as an IP address and a MAC address that can uniquely identify the program distribution source server may be used. In short, according to the present invention, any information used for authentication may be used as long as data reading from the common scratch pad 91 is authenticated based on a specific security policy.
[0050]
(Modification 3) In the above-described embodiment, the data is read from the common scratch pad 91 by the control unit 34 referring to the ADF to acquire the URL of the Java AP distribution server being executed, and to read the data. Authenticated by comparing with the URL appended to the URL. However, the authentication method for reading data from the common scratch pad 91 is not limited to this. For example, a management table in which information uniquely identifying data written in the common scratch pad 91, such as a file name, and a URL of a distribution server of the Java AP to which data read authority is given is stored in FlashROM, This can be used in reading data from the common scratch pad 91. In this case, in reading data from the common scratch pad 91, the control unit 34 compares the URL of the Java AP distribution source server being executed with the URL associated with the data to be read in the management table. The data reading may be performed only when the two URLs match. In short, according to the present invention, as long as authentication of data reading from the common scratch pad 91 can be performed based on a specific security policy, information used for the authentication may be stored anywhere.
[0051]
(Modification 4) In the above-described embodiment, the control unit 34 downloads a file indicating a list of JavaAPs that can share data from the distribution server of the running JavaAP, and performs common scratch based on the description of this file. The description has been given of an aspect in which data sharing using the pad 91 is realized. However, the URL or the program name of the Java AP that can share data may be described in the ADF in advance, and the common scratch pad 91 may be accessed based on the URL. In short, according to the present invention, as long as authentication of data reading from the common scratch pad 91 can be performed based on a specific security policy, the authentication condition may be determined in the server 2. , May be selected in the mobile device 3.
[0052]
【The invention's effect】
As described above, according to the present invention, security of data used during execution of each program is maintained, data can be shared among a plurality of programs, and flexibility in handling data is improved. It is possible to do.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an overall configuration of a communication system.
FIG. 2 is a block diagram illustrating a configuration of a data server.
FIG. 3 is a block diagram illustrating a configuration of a mobile device.
FIG. 4 is a diagram showing a program execution environment in a mobile device.
FIG. 5 is a flowchart illustrating an operation of a control unit when JavaAP is installed in a mobile device.
FIG. 6 is a flowchart illustrating an operation of a control unit when a Java AP is additionally installed on a mobile device and data is shared.
FIG. 7 is a flowchart illustrating an operation of a control unit when executing an additionally installed Java AP.
FIG. 8 is a flowchart showing an operation when the control unit accesses a common scratch pad.
[Explanation of symbols]
100: Communication system, 1: Mobile packet communication network, 2: Data server, 3: Mobile device, 34: Control unit, 90: Individual scratch pad, 91: Common scratch pad.

Claims

A mobile device accommodated in a mobile communication network;
A plurality of servers that transmit a program executable by the mobile device to the mobile device via the mobile communication network,
The at least one server transmits the program and determination information for the mobile device to determine how to allocate a memory area in the mobile device to the program,
The mobile device,
A plurality of the programs transmitted from the plurality of servers; and a receiving unit configured to receive the determination information transmitted from the at least one server;
For each of the plurality of programs received, individual area allocating means for allocating a memory area dedicated to each program,
For a specific plurality of programs determined based on the received determination information, a shared area allocating unit that allocates a memory area that can be shared by the specific plurality of programs,
A communication system comprising: control means for executing a program to be executed using a memory area allocated by the individual area allocating means and the shared area allocating means for the shared area allocating means.

For a mobile device accommodated in a mobile communication network, specifying to the mobile device how to allocate a memory area to a program received by the mobile device via the mobile communication network. A server characterized by the above-mentioned.

Reception for receiving a plurality of executable programs transmitted from a plurality of servers and determination information transmitted from at least one server for determining how to allocate a memory area to the programs. Means,
For each of the plurality of programs received, individual area allocating means for allocating a memory area dedicated to each program,
For a specific plurality of programs determined based on the received determination information, a shared area allocating unit that allocates a memory area that can be shared by the specific plurality of programs,
A mobile device comprising: control means for executing a program to be executed using a memory area allocated by the individual area allocating means and the shared area allocating means for the program.

The control means,
When writing data to the memory area allocated by the shared area allocating means, a recording means for adding the determination information to the data,
When reading data from the memory area allocated by the shared area allocating means, determining means for determining whether to be able to read based on the determination information added to the data to be read,
4. The mobile device according to claim 3, further comprising: reading means for accessing a memory area allocated by the shared area allocating means when a result of the determination by the determining means permits data reading. .

The control means,
Storage means for storing, when writing data in the memory area allocated by the shared area allocation means, the determination information corresponding to the program being executed in association with the determination information corresponding to the data to be written; When,
When reading data from the memory area allocated by the shared area allocation unit, the determination information corresponding to the program being executed and the determination information stored by the storage unit in association with the data to be read. Determining means for determining whether or not reading is possible based on
4. The mobile device according to claim 3, further comprising: reading means for accessing a memory area allocated by the shared area allocating means when a result of the determination by the determining means permits data reading. .

The mobile device according to claim 4, wherein the determination information is an address uniquely indicating a distribution source server of the program.

The mobile device according to claim 4, wherein the determination information is an address that uniquely indicates a distribution source server of a program to which data is to be shared.

The mobile station according to claim 4, wherein the determination information is a program name of a program to be shared.

4. The mobile device according to claim 3, wherein the program is described in Java (registered trademark), and the determination information is described in an ADF (Application Descriptor File).

On the computer,
A function of receiving a plurality of programs transmitted from the plurality of servers, and determination information transmitted from at least one server to determine how to allocate a memory area to the programs;
A function of allocating a memory area dedicated to each program to each of the plurality of programs received,
For a specific plurality of programs determined based on the received determination information, a function of allocating a memory area that can be shared by the specific programs,
A program for realizing a function of executing a program to be executed using a memory area dedicated to each of the programs and a memory area sharable by the specific programs.

A computer-readable recording medium on which the program according to claim 10 is recorded.