JP4323190B2

JP4323190B2 - Communication terminal

Info

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

Description

【０００１】
【従来の技術】
従来より、移動通信網を介してダウンロードしたプログラムを実行可能な移動機が知られている。このような移動機として、例えば、Ｊａｖａプログラミング言語によって記述されたプログラムを実行可能なものがある。この移動機の場合、所謂サンドボックスを用いて、移動機内部に記憶されるデータが外部サーバ等に流出しないように保護している。サンドボックスと称せられる技術に関しては、例えば特許文献１に記載されている。
【０００２】
【特許文献１】
特開平１０−２５４７８３号公報
【０００３】
サンドボックスを利用したデータ保護の場合、移動機にインストールされる各々のプログラム毎に、排他的なメモリ領域が割り当てられる。そのため、移動機は、あるプログラムを実行中に、他のプログラムに割り当てられたメモリ領域にアクセスすることができない。くわえて、サンドボックスによるデータ保護では、移動機があるプログラムを実行中に通信可能な外部サーバは、実行中のプログラムの配信元サーバのみとされる。このため、サンドボックスを用いると、移動機に記憶されるデータが、信頼できない第三者の外部サーバに流出することがなくなる。
【０００４】
【発明が解決しようとする課題】
ところが、データセキュリティとデータを扱う際の自由度とは、トレードオフの関係にある。上記のように、サンドボックスを利用してデータ保護を行った場合、複数のプログラム間でデータを共有することが不可能となる。その結果、移動機にインストールされた複数のプログラムがデータを共用しつつ連携して動作することができなくなる、つまり、移動機におけるプログラムの拡張性が制限されてしまうという問題が生じる。
本発明は、かかる実情に鑑み、複数のプログラムが、セキュリティを維持しつつデータを共用することが可能な、通信システム、サーバ、移動機、プログラムおよび記録媒体を提供する。
【０００５】
【課題を解決する手段】
上記の課題を解決するため、本発明は、配信元から配信されてくるプログラムを受信する受信手段と、前記受信手段によって受信されたプログラムを記憶するプログラム記憶手段と、前記プログラム記憶手段に記憶されているプログラムが実行されることによって生成されたデータを記憶するデータ記憶手段と、前記プログラムが実行されることによって生成されたデータを前記データ記憶手段に書き込むデータ書込手段と、前記プログラムが実行される場合に、前記データ記憶手段に記憶されているデータを読み出すデータ読出手段とを備えた通信端末であって、前記データ書込手段は、前記データを前記データ記憶手段に書き込むとともに、当該データを生成するときに実行されたプログラムの配信元を一意に特定する特定情報を、当該データの読み出しを認証するための認証情報として書き込み、前記データ読出手段は、前記データ記憶手段に記憶されているデータを読み出すときに、当該データの認証情報を用いて、当該データの読み出しを認証する手段であり、実行対象となるプログラムの配信元を一意に特定する特定情報と、読み出しの対象となるデータの認証情報として書き込まれた前記特定情報とが一致すると、当該読み出しの対象となるデータを読み出すことを特徴する通信端末を提供する。
また、本発明は、配信元から配信されてくるプログラムを受信する受信手段と、前記受信手段によって受信されたプログラムを記憶するプログラム記憶手段と、前記プログラム記憶手段に記憶されているプログラムが実行されることによって生成されたデータを記憶するデータ記憶手段と、前記プログラムが実行されることによって生成されたデータを前記データ記憶手段に書き込むデータ書込手段と、前記プログラムが実行される場合に、前記データ記憶手段に記憶されているデータを読み出すデータ読出手段とを備えた通信端末であって、前記データ書込手段は、前記データを前記データ記憶手段に書き込むとともに、当該データを生成するときに実行されたプログラムの配信元のドメイン名を、当該データの読み出しを認証するための認証情報として書き込み、前記データ読出手段は、前記データ記憶手段に記憶されているデータを読み出すときに、当該データの認証情報を用いて、当該データの読み出しを認証する手段であり、実行対象となるプログラムの配信元のドメイン名と、読み出しの対象となるデータの認証情報として書き込まれたドメイン名とが一致すると、当該読み出しの対象となるデータを読み出すことを特徴とする通信端末を提供する。
また、本発明は、配信元から配信されてくるプログラムを受信する受信手段と、前記受信手段によって受信されたプログラムを記憶するプログラム記憶手段と、前記プログラム記憶手段に記憶されているプログラムが実行されることによって生成されたデータを記憶するデータ記憶手段と、前記プログラムが実行されることによって生成されたデータを前記データ記憶手段に書き込むデータ書込手段と、前記プログラムが実行される場合に、前記データ記憶手段に記憶されているデータを読み出すデータ読出手段とを備えた通信端末であって、前記データ書込手段は、前記データを前記データ記憶手段に書き込むとともに、当該データを生成するときに実行されたプログラムが配信されたときの当該プログラムのファイルに記述されていたアドレスデータを、当該データの読み出しを認証するための認証情報として書き込み、前記データ読出手段は、前記データ記憶手段に記憶されているデータを読み出すときに、当該データの認証情報を用いて、当該データの読み出しを認証する手段であり、実行対象となるプログラムの配信元のアドレスと、読み出しの対象となるデータの認証情報として書き込まれたアドレスとが一致すると、当該読み出しの対象となるデータを読み出すことを特徴とする通信端末を提供する。
【００１２】
【発明の実施の形態】
＜１．第１実施形態＞
＜１−１．第１実施形態の構成＞
＜１−１−１．システム構成＞
図１は、本発明の一実施形態に係る通信システム１００の全体構成を示す図である。図１に示すように、通信システム１００は、移動パケット通信網１と、複数のデータサーバ２−１〜２−ｎ（ｎ＝自然数。以下、特に個々の機器を区別する必要のない場合、データサーバ２と称する）と、移動機３とを備えている。なお、図１においては、図面が煩雑になることを防ぐため、通信システム１００の構成を理解するのに必要な装置のみが示されている。
【００１３】
移動パケット通信網１は、移動機３に対して、パケット通信サービスを提供する。図１に示すように、移動パケット通信網１は、交換局１１を備えており、各交換局１１には、基地局１２が接続されている。基地局１２は、移動機３との通信に用いる電波を出力しており、この電波の到達範囲内が無線セルとして形成される。基地局１２は、自身が形成する無線セル内に在圏する移動機３との間で、無線パケット通信を行う。
なお、通信システム１００は、移動パケット通信網１に加え、移動電話網（図示せず）を備えている。移動通信網は、移動機３に対して、一般的な移動電話網の通話サービスを提供する。
【００１４】
＜１−１−２．データサーバの構成＞
図２は、データサーバ２の構成を示すブロック図である。図２に示すように、データサーバ２は、ＣＰＵ（Central Processing Unit）２０と、ＲＯＭ（Read-Only Memory）２１と、ＲＡＭ（Random-Access Memory）２２と、通信インターフェイス２３と、ハードディスク２４と、システムバス２５とを備えている。
ＣＰＵ２０は、ＲＯＭ２１に記憶される各種プログラムの記述に従い、ＲＡＭ２３を一時的な作業領域として用いつつ、データサーバ２の各構成部を中枢的に制御する。通信インターフェイス２３は、移動パケット通信網１を介して、データサーバ２が移動機３とパケット通信を行う際に用いられるポートである。データサーバ２に備わる各部は、システムバス２５を介して各種のデータを伝送する。そして、ハードディスク２４には、データサーバ２が移動機３に提供する各種のプログラムが記憶されている。このプログラムは、Ｊａｖａプログラミング言語によって記述されている。これを以下、ＪａｖａＡＰ（Application）と称する。ハードディスク２４に記憶されるＪａｖａＡＰは、ＪＡＲ（Java ARchive）ファイルと、ＡＤＦ（Application Descriptor File）とに大別される。
【００１５】
ＪＡＲファイルは、プログラム本体であるクラスファイルと、プログラム本体を実行する際に必要となるリソースファイルのアーカイブである。リソースファイルとは、クラスファイルに記述された手順を実行する際に用いられるテキストデータ、楽音データ、画像データおよび動画データ等の参照データを意味する。一方、ＡＤＦとは、移動機３にＪａｖａＡＰをインストールする際に必要となる制御情報を記述した設定ファイルである。ＡＤＦに記述される具体的な制御情報としては、例えば、ＪａｖａＡＰの配信元サーバのＵＲＬ（Uniform Resource Locator）や、ＪａｖａＡＰインストール時に必要となるメモリ容量等が挙げられる。
【００１６】
＜１−１−３．移動機の構成＞
移動機３は、自機が在圏する無線セルを形成する基地局１２との間で、無線通信によるパケット通信および音声通話を行う。移動機３は、パケット通信によって、データサーバ２に記憶されるＪＡＲファイルをダウンロードする。このダウンロードに当たり、まず、移動機３は、データサーバ２からＡＤＦを受信する。そして、移動機３は、ＡＤＦに記述された制御情報を参照し、必要なメモリ容量を識別する等して、ＪａｖａＡＰをインストール可能であるか否かを判別する。移動機３は、ＪａｖａＡＰのインストールが可能であると判断できた場合のみ、ＪＡＲファイルをダウンロードする。
【００１７】
図３は、移動機３の構成を示すブロック図である。図３に示すように、移動機３は、アンテナ３０と、無線部３１と、ベースバンド処理部３２と、音声入出力部３３と、制御部３４と、表示部３５と、操作部３６と、電源部３７とを備えている。
【００１８】
アンテナ３０は、送受信アンテナである。無線部３１は、受信部、送信部および周波数シンセサイザ等を備えており、アンテナ３０を介して、基地局１２との間で無線通信を行う。このとき、無線部３１は、アナログ信号を、ベースバンド信号処理部３２との間で授受する。ベースバンド信号処理部３２は、マルチメディアインターフェイス、音声コーデックおよび画像コーデック等を備えており、各種のデータ処理を行う。
【００１９】
音声入出力部３３は、マイクロホンおよびスピーカを備えている。音声入出力部３３は、マイクロホンが集音した音声信号をベースバンド信号処理部３２に供給する。また、音声入出力部３３は、ベースバンド信号処理部３２から音声信号を供給されると、この音声信号に基づいて、スピーカから放音する。
【００２０】
制御部３４は、移動機３に備わる各部の動作を中枢的に制御する。この制御部３４は、ＭＰＵ（Micro Processor Unit）として構成されており、ＣＰＵと、ＲＡＭと、ＲＯＭと、ＦｌａｓｈＲＯＭとを備えている。ＣＰＵは、ＲＡＭを一時的な作業領域とし、ＲＯＭおよびＦｌａｓｈＲＯＭに記憶される各種プログラムを実行する。ＲＯＭには、例えば、移動機３のオペレーティングシステム（以下、ＯＳと略称する）や、ＪａｖａＡＰの実行環境を構築するための各種プログラム等が記憶されている。一方、ＦｌａｓｈＲＯＭには、移動機３のネイティブコンポーネントが記憶されている。ここで、ネイティブコンポーネントとは、移動機３のＯＳに備わる機能のみによって実行可能なプログラムを意味する。また、ＦｌａｓｈＲＯＭには、データサーバ２からダウンロードされたＪａｖａＡＰが記憶される。
【００２１】
表示部３５は、液晶パネルおよびパネル駆動回路を有しており、制御部３４による制御の下で、各種情報を表示する。操作部３６は、テンキーおよび各種制御キーからなるキーパッドやキー検出回路を有しており、利用者のキー操作に対応する制御信号を制御部３４に出力する。電源部３７は、移動機３に備わる各部が動作するために必要な電力を供給する。
【００２２】
＜１−１−４．プログラム実行環境＞
図４は、移動機３におけるプログラム実行環境を示した図である。
ＪＡＭ（Java Application Manager）は、ＪａｖａＡＰを管理するための処理手順が記述されたソフトウェアモジュールである。このＪＡＭには、ＪａｖａＡＰを管理するための処理手順が記述されている。例えば、ＪＡＭには各ＪａｖａＡＰのＡＤＦを管理するための処理が記述されており、制御部３４は、ＪＡＭに記述された手順に従って各ＪａｖａＡＰのＡＤＦをＦｌａｓｈＲＯＭに記憶する。
ＫＶＭ（K Virtual Machine）は、ＪａｖａＡＰを実行するための処理手順が記述されたソフトウェアモジュールである。このＫＶＭをロードすることで、制御部３４は、ＪａｖａＡＰに記述されたコードを、実行コードであるバイトコードに翻訳することができるようになる。
【００２３】
ＣＬＤＣクラスライブラリ、オリジナル拡張ライブラリおよびメーカ拡張ライブラリは、制御部３４が必要に応じて参照する各種クラスファイルの集合である。ＣＬＤＣ（Connected, Limited Device Configuration）クラスライブラリは、Ｊ２ＭＥの標準として実装されるものであり、バイトコード生成のために必要とされる最も基本的な機能が定義されたクラスファイルの集合である。また、オリジナル拡張ライブラリは、移動パケット通信網１を運営する通信事業者が提供するサービスを享受するために必要となる機能、つまり、移動機３が移動パケット通信網１を介してパケット通信を行う最に必要となる各種機能等が定義されたクラスファイルの集合である。そして、メーカ独自拡張ライブラリは、移動機３の各製造メーカ毎の独自機能を実現する際に必要となる各種機能が定義されたクラスファイルの集合である。
【００２４】
ＪＡＲストレージは、データサーバ２から移動機３にＪＡＲファイルがダウンロードされた場合に、そのＪＡＲファイルを記憶する領域である。このＪＡＲストレージは、ＦｌａｓｈＲＯＭ内の一部の領域を用いて形成されている。移動機３は、データサーバ２からＪＡＲファイルをダウンロードすると、これをＪＡＲストレージに書きこむ。そして、ＪａｖａＡＰ実行の際には、制御部３４は、ＪＡＲストレージからプログラム本体であるクラスファイルを読み出し、これに記述された処理を実行する。
【００２５】
そして、制御部３４は、データサーバ２からＪＡＲファイルをダウンロードする際に、ＪａｖａＡＰ実行時に参照されるデータを格納可能な領域として、個別スクラッチパッド９０を形成する。この個別スクラッチパッド９０は、ＦｌａｓｈＲＯＭ内の一部の領域を用いて形成されており、各ＪａｖａＡＰに排他的に割り当てられる領域である。従って、制御部３４は、あるＪａｖａＡＰを実行中に、他のＪａｖａＡＰに割り当てられた個別スクラッチパッド９０にアクセスすることはできない。
【００２６】
個別スクラッチパッド９０が各ＪａｖａＡＰの専有領域として割り当てられる理由は次の通りである。
移動機３にインストール可能なＪａｖａＡＰは複数存在し得るが、その中には、高い秘匿性が要求されるデータを取り扱うものがある。例えば銀行振込を実行するアプリケーションプログラム等である。一般的なサンドボックスモデルでは、移動機はＪａｖａＡＰを実行中に、そのＪａｖａＡＰの配信元サーバとの間で通信を行うことが許されている。ここで、個別スクラッチパッド９０のようなＪａｖａＡＰ毎の専用記憶領域を設けないで共通の記憶領域のみを設けるとすれば、ＪａｖａＡＰはその共通の記憶領域を利用して互いにデータをやり取りすることが可能となる。この結果、仮に移動機が悪意のあるプログラマによって作成されたＪａｖａＡＰを実行してしまうと、そのＪａｖａＡＰの配信元サーバに対し他のＪａｖａＡＰのみが取り扱うべき秘匿性の高いデータを送信してしまう虞が生じてくる。このような事態を防止するため、移動機３では、個別スクラッチパッド９０を各ＪａｖａＡＰの専有領域とし、各々のＪａｖａＡＰが取り扱うデータを保護しているのである。
【００２７】
さらに、本実施形態の移動機３においては、複数のＪａｖａＡＰを連動させ、利用者にあたかも一つのＪａｖａＡＰが実行されているかのように認識させることが可能となっている。例えばデータサーバ２からダウンロードされたＪａｖａＡＰが、ロールプレイングゲームを定義したプログラム（以下、ＲＰＧアプリと記述する）であったと仮定する。制御部３４は、このＲＰＧアプリに記述された手順に従って、利用者が操作部３６を介して操作可能な数々のキャラクタ（ＲＰＧアプリの登場人物）表示部３５に表示させる。そして、利用者が操作するキャラクタが別のキャラクタと出会った場合には、制御部３４は、ＲＰＧアプリに記述された手順に従って、キャラクタ同士が会話する等の様子を表示部３５に表示させる。
【００２８】
ここで、利用者が操作する主人公のキャラクタと、その主人公と敵対するキャラクタとが出会った場合にはこれらキャラクタが格闘を開始する、というゲーム展開を利用者が所望したとする。この処理は、ＲＰＧアプリにキャラクタ同士の格闘が定義されていなければ実行することができない。そこで、このような場合、本実施形態では、移動機３がキャラクタ同士の格闘処理を実行するＪａｖａＡＰ（以下、格闘アプリと称する）をデータサーバ２からダウンロードし、これをインストールして、ＲＰＧアプリの実行中に割込み起動することが可能である。そして、移動機３がこのＲＰＧアプリと格闘アプリという二つのＪａｖａＡＰを切り換えながら実行することで、利用者にあたかも一つのＪａｖａＡＰが実行されているように認識させることができる。
【００２９】
上記のようなＪａｖａアプリの連動処理は以下のようにして実現される。
制御部３４がＲＰＧアプリを実行する際には、例えばゲームの難易度の設定や起動オプション等を定義するための初期設定ファイルや、ＲＰＧアプリを実行した結果として生成された得点データ等を記述するための処理結果ファイルが生成されることになる。制御部３４は、これらのファイル形式のデータを参照することで、ＲＰＧアプリをゲーム途中で中断し格闘アプリに遷移したような場合であっても、その中断した時のゲーム状況に合うような場面から格闘アプリを開始させることが可能となる。例えば、ＲＰＧアプリによるゲーム展開において主人公のキャラクタが取得した武器を格闘アプリによる格闘シーンにおいても利用することが可能となる。つまり、制御部３４の行う各々の処理の間に、一貫性を持たせることができるようになる。
【００３０】
このように、上記のように、二つのＪａｖａＡＰを切り換えつつ実行する場合には、ＲＰＧアプリによって生成されたファイルの内容を格闘アプリから参照し得るようにしなければならないし、またはその逆に、格闘アプリによって生成されたファイルの内容をＲＰＧアプリから参照し得るようにしなければならない。しかしながら、これらのＲＰＧアプリと格闘アプリとはＪａｖａＡＰとしては別々のものである。従って、例えば格闘アプリが生成したファイルを、格闘アプリに割り当てられた個別スクラッチパッド９０に記憶してしまうと、そのファイルを二つのＪａｖａＡＰ間で共有することができなくなってしまう。
そこで、本実施形態では、複数のＪａｖａＡＰが共有するファイルを記憶する領域を移動機３のＦｌａｓｈＲＯＭに設けるようにしている。これが、図４に示す共通スクラッチパッド９１である。この共通スクラッチパッド９１には格闘アプリが生成したファイルが記憶されるので、制御部３４は、そのファイルを、格闘アプリ実行中の場合であっても、ＲＰＧアプリ実行中の場合であっても、参照することができるようになる。
【００３１】
ただし、共通スクラッチパッドに記憶されたデータを不特定多数のＪａｖａＡＰが参照することができてしまうと望ましくない。なぜなら、共通スクラッチパッド９１においても、個別スクラッチパッド９０と同様に、秘匿性を保つことが要求されるデータが記憶され得る。そのため、共通スクラッチパッド９１へのアクセスについて、何らかの制限を設け、データが第三者の外部サーバに送信されないようにする必要がある。そこで、本実施形態の移動機３では、以下のような処理を行う。
【００３２】
まず、制御部３４は、共通スクラッチパッド９１にデータを書きこむ際には、実行中のＪａｖａＡＰのＡＤＦを参照し、プログラム配信元サーバのＵＲＬを識別する。そして、制御部３４は、データに識別したＵＲＬを付加して、共通スクラッチパッド９１に書きこむ。一方、共通スクラッチパッド９１からデータを読み出すに当たっては、制御部３４は、上記と同様にＡＤＦを参照して実行中のＪａｖａＡＰの配信元サーバのＵＲＬを識別するとともに、識別したＵＲＬが読み出すべきデータに付加されているＵＲＬと一致するか否かを判別する。そして、２つのＵＲＬが一致した場合にのみ、制御部３４は、共通スクラッチパッド９１からデータを読み出す。
【００３３】
さらに具体的に説明すると、制御部３４は、共通スクラッチパッド９１に格闘アプリのデータを書きこむ際には、格闘アプリのＡＤＦを参照して格闘アプリの配信元サーバのＵＲＬを識別する。そして、制御部３４は、識別したＵＲＬを付加して、データを共通スクラッチパッド９１に書きこむ。一方、このデータをＲＰＧアプリを実行中に参照する場合には、制御部３４は、ＲＰＧアプリのＡＤＦを参照して当該アプリの配信元サーバのＵＲＬを識別し、これを共通スクラッチパッド９１から読み出すべきデータに付加されたＵＲＬ、すなわち、格闘アプリのＵＲＬと比較する。そして、２つのＵＲＬが一致すれば、制御部３４は、共通スクラッチパッドからデータを読み出す。
【００３４】
上記の仕組みを備えることにより、本実施形態の移動機３では、同一サーバからダウンロードされたＪａｖａＡＰ間のみでデータ共有を実現することを可能とすると共に、個別スクラッチパッドを利用した場合とほぼ同等のデータ保護を行うことが可能となっているのである。
【００３５】
＜１−２．実施形態の動作＞
以下においては、説明を具体的に行うため、ＲＰＧアプリおよび格闘アプリを例に挙げ、移動機３の動作を中心に説明する。
＜１−２−１．ＪａｖａＡＰのインストールおよび実行＞
図５は、移動機３にＪａｖａＡＰをインストールする際の、制御部３４の動作を示すフローチャートである。
まず、操作部３６における利用者の操作に従って、移動機３は、データサーバ２からＲＰＧアプリのＡＤＦを受信する。これを詳述すると、制御部３４は、ＡＤＦのＵＲＬを引数とするＨＴＴＰ（Hypertext Transfer Protocol）のＧＥＴ命令を、データサーバ２に送信する（ステップＳ１０１）。この結果として、制御部３４は、データサーバ２からＡＤＦを受信する（ステップＳ１０２）。次に、制御部３４は、受信したＡＤＦの記述内容からインストールに必要なメモリ容量を識別し、ＲＰＧアプリを移動機３にインストール可能であるか否かを判断する（ステップＳ１０３）。
【００３６】
そして、制御部３４は、移動機３においてＲＰＧアプリをインストール可能であると判断した場合に（ステップＳ１０３；Ｙｅｓ）、ＡＤＦをＦｌａｓｈＲＯＭに書きこみ（ステップＳ１０４）、ＡＤＦに記述されるＵＲＬを引数とするＧＥＴ命令を、データサーバ２に送信する（ステップＳ１０５）。この結果として、制御部３４は、データサーバ２からＲＰＧアプリのＪＡＲファイルを受信する（ステップＳ１０６）。制御部３４は、ＪＡＲファイルを受信すると、これをまずＪＡＲストレージに書きこむ（ステップＳ１０７）。そして、制御部３４は、ＡＤＦによって指定された容量のメモリ領域の個別スクラッチパッド９０をFlashＲＯＭに作成し（ステップＳ１０８）、ＲＰＧアプリに割り当てる（ステップＳ１０９）。さらに、制御部３４は、作成した個別スクラッチパッド９０に、ＲＰＧアプリの初期設定ファイルを書きこむ（ステップＳ１１０）。これで、ＲＰＧアプリのダウンロードおよびインストールが完了する。
【００３７】
上記のようにしてインストールされたＲＰＧアプリは、次のようにして実行される。まず、利用者の操作に基づき、操作部３６から制御部３４に、ＲＰＧアプリの実行を指令する制御信号が供給される。すると、これをトリガとして、制御部３４がＲＰＧアプリの実行処理を開始する。制御部３４は、ＪＡＭおよびＫＶＭをロードして、ＪａｖａＡＰ実行環境を構築する。そして、制御部３４は、ＲＰＧアプリに割り当てられた個別スクラッチパッド９０から初期設定ファイルを読み出し、その記述内容から、ＲＰＧアプリの実行条件を識別する。その後、制御部３４は、ＪＡＲストレージからＲＰＧアプリ本体であるクラスファイルを読み出し、これを実行する。
【００３８】
＜１−２−２．ＪａｖａＡＰの追加インストールおよびデータ共有＞
図６は、移動機３にＪａｖａＡＰを追加インストールし、データ共有する際の、制御部３４の動作を示すフローチャートである。
まず、移動機３においてＲＰＧアプリを実行中に、利用者が操作部３６を介して所定の操作を行うと、これをトリガとして、インストール処理が開始される。制御部３４は、無線部３０を介して、データサーバ２に対して、ＲＰＧアプリとデータ共有可能なＪａｖａＡＰの一覧を示すファイルのＵＲＬを引数とするＧＥＴ命令を送信する（ステップＳ２０１）。そして、データ共有可能なＪａｖａＡＰの一覧を受信すると、制御部３４は、このデータを表示部３５に表示する（ステップＳ２０２）。そして、制御部３４は、操作部３６を介した利用者の入力を待機する（ステップＳ２０３）。
【００３９】
ステップＳ２０３において、利用者が操作部３６を介して、格闘アプリを選択する操作を行うと（ステップＳ２０３；Ｙｅｓ）、制御部３４は、無線部３０を介して、格闘アプリのＡＤＦのＵＲＬを引数とするＧＥＴ命令を、データサーバ２に送信する（ステップＳ２０４）。そして、制御部３４は、格闘アプリのＡＤＦを受信すると（Ｓ２０５）、このＡＤＦの記述内容を解釈し、格闘アプリをダウンロード、実行するために必要な条件を判別する（ステップＳ２０６）。以下、ステップＳ２０７〜Ｓ２１０までの動作は、上述のステップＳ１０４〜Ｓ１０７までの動作と同様であるため、その説明を省略する。
【００４０】
その後、制御部３４は、ＲＰＧアプリの初期設定ファイルに格闘アプリを割込み起動する際の条件を書き込むとともに、格闘アプリの個別スクラッチパッド９０に初期設定ファイルを書込み（ステップＳ２１１）、処理を終了する。この後、制御部３４は、初期設定ファイルに記述された条件が成立した場合に、実行中のＲＰＧアプリを待機状態に遷し、格闘アプリを割込み起動するようになる。
【００４１】
さて、上記の手順でインストールされた格闘アプリは、次の手順で割込み起動され、実行される。
図７は、追加インストールされたＪａｖａＡＰを実行する際の制御部３４の動作を示すフローチャートである。
【００４２】
まず、格闘アプリの割込み起動が初めてであった場合（ステップＳ３０１；Ｙｅｓ）、制御部３４は、格闘アプリの個別スクラッチパッド９０から初期設定ファイルを読出し（ステップＳ３０２）、その記述内容を判別する（ステップＳ３０３）。そして、制御部３４は、格闘アプリの初期設定ファイルに、ＲＰＧアプリのゲーム難度等共有すべき設定を追加し、これを共通スクラッチパッド９１に書き込む（ステップＳ３０４）。その後、制御部３４は、ＪＡＲストレージから格闘アプリのクラスファイルを読出し（ステップＳ３０５）、これを実行する（ステップＳ３０６）。
【００４３】
このとき、格闘アプリの実行に伴なって得点データ等のデータが生成された場合、制御部３４は、共通スクラッチパッド９１に処理結果ファイルを作成し、このファイルに、生成されたデータを追加していく（ステップＳ３０７）。また、制御部３４は、処理結果ファイルに、格闘アプリのＡＤＦに記述されている配信元サーバのＵＲＬを、処理結果ファイルに追加する（ステップＳ３０７）。その後、制御部３４は、格闘アプリの実行を終了すると、待機状態にあるＪａｖａＡＰを再実行する（ステップＳ３０８）。
【００４４】
また、格闘アプリの割込み起動が２回目以降である場合には（ステップＳ３０１；Ｎｏ）、制御部３４は、共通スクラッチパッド９１から格闘アプリの初期設定ファイルを読み出す（ステップＳ３０９）。そして、制御部３４は、初期設定ファイルの記述内容を識別し（ステップＳ３１０）、これに基づいて、格闘アプリを実行する。
【００４５】
さて、格闘アプリの実行結果として生成されたデータを、ＲＰＧアプリ実行中に利用する場合、制御部３４は、上記ステップＳ３０７において作成された共通スクラッチパッド９１に書きこまれた処理結果ファイルを読出し、これを利用する。
図８は、制御部３４が共通スクラッチパッド９１にアクセスする際の動作を示すフローチャートである。
まず、制御部３４は、読み出すべきファイル中から、ファイルが書きこまれた際に実行中であったＪａｖａＡＰの配信元サーバのＵＲＬを取得する（ステップＳ４０１）。上記の例では、制御部３４は、ＲＰＧアプリの配信元サーバのＵＲＬを取得することとなる。そして、制御部３４は、取得したＵＲＬを、現在実行中のＪａｖａＡＰの配信元サーバのＵＲＬと比較する（ステップＳ４０２）。そして、２つのＵＲＬが一致した場合のみ（ステップＳ４０２；Ｙｅｓ）、制御部３４は、共通スクラッチパッド９１からデータを読み出す（ステップＳ４０３）。一方、２つのＵＲＬが一致しなかった場合（ステップＳ４０２；Ｎｏ）には、制御部３４は、共通スクラッチパッド９１からのデータ読出しを中止し、処理を終了する。
【００４６】
なお、格闘アプリには、個別スクラッチパッド９０が割り当てられているため、格闘アプリを単体で起動することも可能である。格闘アプリを単体で起動する場合には、制御部３４は、初期設定ファイルおよび処理結果ファイルの読出しおよび書き込みを、格闘アプリに割り当てられた個別スクラッチパッド９０に対して行う。そうすることで、格闘アプリ実行の際に生成されるデータを、通常のＪａｖａＡＰと同様に保護することが可能となる。
【００４７】
＜３．変形例＞
なお、本発明の通信システム、サーバ、移動機およびデータ記憶方法は、上述の実施形態に限定されるものではなく、本発明の技術的思想の範囲内で種々の変更を加えることが可能である。
【００４８】
（変形例１）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しについて、データ書込み時に付加された配信元サーバのＵＲＬと、実行中のＪａｖａＡＰのＡＤＦに記述される配信元サーバのＵＲＬとを比較し、２つのＵＲＬが一致した場合に、データ共有を許可する態様を採って説明を行った。しかし、共通スクラッチパッド９１からのデータ読出しをプログラム配信元サーバに限らず、プログラム配信元サーバと同一ドメインに属する複数のサーバに拡張する態様を採っても構わない。要は、本発明は、共通スクラッチパッド９１に記憶されたデータを複数のプログラム間で共有する際に、特定のセキュリティポリシーに基づいて、共通スクラッチパッド９１からのデータ読出しを認証する態様であれば、認証が成立する対象の範囲は問わない。
【００４９】
（変形例２）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しの際の認証に、ＵＲＬを用いる態様を例に採って説明を行った。しかし、認証に利用する情報は、ＵＲＬには限られない。認証には、例えば、ＩＰアドレスやＭＡＣアドレス等、プログラム配信元サーバを一意に特定可能な情報であれば、どのようなものを用いても構わない。要は、本発明は、特定のセキュリティポリシーに基づいて、共通スクラッチパッド９１からのデータ読出しを認証を行う態様であれば、認証に用いる情報はどのようなものであっても構わない。
【００５０】
（変形例３）上述の実施形態においては、共通スクラッチパッド９１からのデータ読出しは、制御部３４がＡＤＦを参照して実行中のＪａｖａＡＰの配信元サーバのＵＲＬを取得し、これを読み出すべきデータに付加されたＵＲＬと比較することによって認証された。しかし、共通スクラッチパッド９１からのデータ読出しの認証方法は、これに限られるものではない。例えばファイル名等、共通スクラッチパッド９１に書きこまれるデータを一意に識別可能な情報と、データの読出し権限が与えられるＪａｖａＡＰの配信元サーバのＵＲＬとを対応付けた管理テーブルをＦｌａｓｈＲＯＭに記憶し、これを共通スクラッチパッド９１からのデータ読出しにおいて用いることも可能である。この場合であれば、共通スクラッチパッド９１からのデータ読出しに当たって、制御部３４は、実行中のＪａｖａＡＰの配信元サーバのＵＲＬと、管理テーブルにおいて読み出すべきデータと対応付けられているＵＲＬとを比較し、２つのＵＲＬが一致した場合にのみ、データ読出しを行うようにすればよい。要は、本発明は、特定のセキュリティポリシーに基づき、共通スクラッチパッド９１からのデータ読出しの認証を行うことの出来る態様であれば、その認証に用いる情報は何処に記憶されていても良い。
【００５１】
（変形例４）上述の実施形態においては、制御部３４が、実行中のＪａｖａＡＰの配信元サーバからデータ共有可能なＪａｖａＡＰの一覧を示すファイルをダウンロードし、このファイルの記述に基づいて、共通スクラッチパッド９１を利用したデータ共有を実現する態様を採って説明を行った。しかし、データ共有可能なＪａｖａＡＰのＵＲＬ乃至プログラム名を予めＡＤＦに記述しておき、これに基づいて共通スクラッチパッド９１にアクセスする態様を採っても構わない。要は、本発明は、特定のセキュリティポリシーに基づき、共通スクラッチパッド９１からのデータ読出しの認証を行うことの出来る態様であれば、その認証条件は、サーバ２において決定されるものであっても、移動機３において選択されるものであっても良い。
【００５２】
【発明の効果】
以上、説明したように、本発明によれば、各プログラムの実行中に利用されるデータのセキュリティを保持するとともに、複数のプログラム間のデータ共有を可能とし、データを扱う際の自由度を向上させることが可能である。
【図面の簡単な説明】
【図１】通信システムの全体構成を示す図である。
【図２】データサーバの構成を示すブロック図である。
【図３】移動機の構成を示すブロック図である。
【図４】移動機におけるプログラム実行環境を示した図である。
【図５】移動機にＪａｖａＡＰをインストールする際の制御部の動作を示すフローチャートである。
【図６】移動機にＪａｖａＡＰを追加インストールしデータ共有する際の、制御部の動作を示すフローチャートである。
【図７】追加インストールされたＪａｖａＡＰを実行する際の制御部の動作を示すフローチャートである。
【図８】制御部が共通スクラッチパッドにアクセスする際の動作を示すフローチャートである。
【符号の説明】
１００…通信システム、１…移動パケット通信網、２…データサーバ、３…移動機、３４…制御部、９０…個別スクラッチパッド、９１…共通スクラッチパッド。[0001]
[Prior art]
Conventionally, a mobile device that can execute a program downloaded via a mobile communication network is known. As such a mobile device, for example, there is a mobile device that can execute a program described in the Java programming language. In the case of 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. A technique called sandbox is described in, for example, Patent Document 1.
[0002]
[Patent Document 1]
Japanese Patent Laid-Open No. 10-254783
[0003]
In the case of data protection using a sandbox, an exclusive memory area is assigned to each program installed in the mobile device. Therefore, the mobile device cannot access a memory area allocated to another program while executing a certain program. In addition, in data protection using a sandbox, the only external server that can communicate during execution of a program with a mobile device is the distribution source server of the program being executed. For this reason, when the sandbox is used, data stored in the mobile device does not leak 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 when handling data. As described above, when data protection is performed using a sandbox, it is impossible to share data among a plurality of programs. As a result, there is a problem that a plurality of programs installed in the mobile device cannot operate in cooperation while sharing data, that is, the scalability 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 in which a plurality of programs can share data while maintaining security.
[0005]
[Means for solving the problems]
  In order to solve the above-mentioned problems, the present invention stores reception means for receiving a program distributed from a distribution source, program storage means for storing a program received by the reception means, and program storage means. Data storage means for storing data generated by executing the program being executed, data writing means for writing data generated by execution of the program to the data storage means, and execution by the program And a data reading means for reading data stored in the data storage means, wherein the data writing means writes the data to the data storage means,Specific information that uniquely identifies the distribution source of the program executed when generating the data,Authentication information for authenticating reading of the dataAsWhen writing and reading the data stored in the data storage means, the data reading means authenticates the reading of the data using the authentication information of the dataIf the specific information that uniquely identifies the distribution source of the program to be executed matches the specific information written as the authentication information of the data to be read, the data to be read is read outA communication terminal is provided.
  Further, the present invention executes a receiving unit that receives a program distributed from a distribution source, a program storage unit that stores a program received by the receiving unit, and a program stored in the program storage unit. Data storage means for storing the data generated by the program, data writing means for writing the data generated by the execution of the program to the data storage means, and when the program is executed, A communication terminal comprising a data reading means for reading data stored in the data storage means, wherein the data writing means is executed when writing the data into the data storage means and generating the data For authenticating the domain name of the distributed program The data reading means is means for authenticating the reading of the data using the authentication information of the data when reading the data stored in the data storage means, and is to be executed. Provided is a communication terminal characterized in that when a domain name of a program distribution source matches a domain name written as authentication information of data to be read, the data to be read is read.
  Further, the present invention executes a receiving unit that receives a program distributed from a distribution source, a program storage unit that stores a program received by the receiving unit, and a program stored in the program storage unit. Data storage means for storing the data generated by the program, data writing means for writing the data generated by the execution of the program to the data storage means, and when the program is executed, A communication terminal comprising a data reading means for reading data stored in the data storage means, wherein the data writing means is executed when writing the data into the data storage means and generating the data The program described in the program file when the Less data is written as authentication information for authenticating the reading of the data, and the data reading means uses the authentication information of the data to read the data stored in the data storage means. When the address of the distribution source of the program to be executed matches the address written as the authentication information of the data to be read, the data to be read is read. A communication terminal is provided.
[0012]
DETAILED DESCRIPTION OF THE INVENTION
<1. First Embodiment>
<1-1. Configuration of First Embodiment>
<1-1-1. System configuration>
FIG. 1 is a diagram showing an overall configuration of a communication system 100 according to an embodiment of the present invention. As shown in FIG. 1, the 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 particularly distinguish individual devices, data 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 becoming complicated.
[0013]
The mobile packet communication network 1 provides a packet communication service to the mobile device 3. As shown in FIG. 1, the mobile packet communication network 1 includes an exchange station 11, and a base station 12 is connected to each exchange station 11. The base station 12 outputs radio waves used for communication with the mobile device 3, and the reach of the radio waves is formed as a radio cell. The base station 12 performs wireless packet communication with the mobile device 3 located in the wireless cell formed by itself.
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 a call service of a general mobile telephone network to the mobile device 3.
[0014]
<1-1-2. Data server configuration>
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, And a system bus 25.
The CPU 20 centrally controls each component of the data server 2 while using the RAM 23 as a temporary work area in accordance with descriptions of various programs stored in the ROM 21. 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 included in the data server 2 transmits various data via the system bus 25. The hard disk 24 stores various programs that the data server 2 provides to the mobile device 3. This program is written in the Java programming language. This is hereinafter referred to as Java AP (Application). Java AP stored in the hard disk 24 is roughly divided into a JAR (Java ARchive) file and an ADF (Application Descriptor File).
[0015]
The JAR file is an archive of a class file that is a program body and a resource file that is required when the program body is executed. The resource file means reference data such as text data, musical tone 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 in 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 when installing Java AP, and the like.
[0016]
<1-1-3. Configuration of mobile device>
The mobile device 3 performs packet communication and voice call by wireless communication with the base station 12 that forms the wireless cell in which the mobile device is located. The mobile device 3 downloads a JAR file stored in the data server 2 by packet communication. For this download, the mobile device 3 first receives an ADF from the data server 2. Then, the mobile device 3 refers to the control information described in the ADF, and determines whether or not Java AP can be installed by identifying necessary memory capacity or the like. The mobile device 3 downloads the JAR file only when it can be determined that Java AP can be installed.
[0017]
FIG. 3 is a block diagram showing the 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 transmission / reception antenna. The radio unit 31 includes a reception unit, a transmission unit, a frequency synthesizer, and the like, and performs radio communication with the base station 12 via the antenna 30. At this time, the radio unit 31 exchanges analog signals with 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 voice 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 an audio signal from the baseband signal processing unit 32, the audio input / output unit 33 emits sound from the speaker based on the audio signal.
[0020]
The control unit 34 centrally controls the operation of each unit provided 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 Flash ROM. The CPU uses the RAM as a temporary work area and executes various programs stored in the ROM and the Flash ROM. 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 for Java AP. On the other hand, the FlashROM stores a native component of the mobile device 3. Here, the native component means a program that can be executed only by the function provided in the OS of the mobile device 3. In addition, the Java ROM downloaded from the data server 2 is stored in the FlashROM.
[0021]
The display unit 35 includes a liquid crystal panel and a panel drive circuit, and displays various types of information under the control of the control unit 34. The operation unit 36 includes 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 power necessary for the operation of each unit included in the mobile device 3.
[0022]
<1-1-4. Program execution environment>
FIG. 4 is a diagram showing a program execution environment in the mobile device 3.
JAM (Java Application Manager) is a software module in which processing procedures for managing Java AP are described. This JAM describes a processing procedure for managing Java AP. For example, JAM describes processing for managing the ADF of each Java AP, and the control unit 34 stores the ADF of each Java AP in the Flash ROM 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 this KVM, the control unit 34 can translate the code described in Java AP into a byte code that 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 necessary. A 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. In addition, the original extension library is a function necessary for enjoying a service provided by a 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 that are necessary at the most are defined. The manufacturer-specific extension library is a set of class files in which various functions necessary for realizing the unique function for 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 by using a partial area in the FlashROM. When the mobile device 3 downloads the JAR file from the data server 2, the mobile device 3 writes it in the JAR storage. Then, when executing Java AP, the control unit 34 reads out a class file that is a program main body from the JAR storage, and executes processing described therein.
[0025]
Then, when the JAR file is downloaded from the data server 2, the control unit 34 forms the individual scratch pad 90 as an area that can store data referred to when executing Java AP. The individual scratch pad 90 is formed by using a part of the area in the FlashROM, and is an area that is 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, but some of them handle data that requires high confidentiality. For example, an application program for executing bank transfer. In a general sandbox model, a mobile device is allowed to communicate with a distribution source server of the Java AP while executing the 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 only other Java APs should handle can be transmitted to the Java AP distribution source server. Will arise. In order to prevent such a situation, the mobile device 3 uses the individual scratch pad 90 as a dedicated area for each Java AP to protect the data handled by each Java AP.
[0027]
Furthermore, in the mobile device 3 of the present embodiment, a plurality of Java APs can be linked so that the user can 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 the display unit 35 to display a number of characters (characters of the RPG application) that can be operated by the user via the operation unit 36 in accordance with the procedure described in the RPG application. When a character operated by the user meets another character, the control unit 34 causes the display unit 35 to display a state in which the characters talk with each other according to 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 meet, the characters start fighting. This process cannot be executed unless a fight between characters is defined in the RPG application. Therefore, in such a case, in this embodiment, the mobile device 3 downloads Java AP (hereinafter referred to as a fighting app) for executing the fighting process between characters from the data server 2, installs it, and installs the RPG app. An interrupt can be activated during execution. Then, the mobile device 3 executes the two Java APs, that is, the RPG application and the fighting application while switching them, so that the user can recognize as if one Java AP is being executed.
[0029]
The Java application linkage process as described above is realized as follows.
When the control unit 34 executes the RPG application, for example, an initial setting file for defining game difficulty settings and activation options, score data generated as a result of executing the RPG application, and the like are described. A processing result file for this is generated. The control unit 34 refers to the data in these file formats, so that even if the RPG application is interrupted in the middle of the game and transitioned to the fighting application, the scene matches the game situation at the time of the interruption. It becomes possible to start the fighting app from. For example, the weapon acquired by the hero character in the game development by the RPG application can be used also in the fighting scene by the fighting application. That is, it is possible to provide consistency between the processes performed by the control unit 34.
[0030]
As described above, when two Java APs are switched and executed, the content of the file generated by the RPG application must be referred to from the fighting application, or vice versa. The contents of the file generated by the application must be referred to from the RPG application. However, these RPG apps and fighting apps are separate as JavaAP. Therefore, for example, if a file generated by a fighting application is stored in the individual scratch pad 90 assigned to the fighting application, the file cannot be shared between two Java APs.
Therefore, in this embodiment, an area for storing files shared by a plurality of Java APs is provided in the Flash ROM 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 can execute the file 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 if an unspecified number of Java APs can refer to data stored in the common scratch pad. This is because the common scratch pad 91 can also store data required to maintain confidentiality, as with the individual scratch pad 90. Therefore, it is necessary to provide some restrictions for access to the common scratch pad 91 so that data is not transmitted to an external server of a third party. 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 JavaAP being executed, and identifies the URL of the program distribution source server. Then, the control unit 34 appends the identified URL to the data and writes it in the common scratch pad 91. On the other hand, when reading the data from the common scratch pad 91, the control unit 34 refers to the ADF in the same manner as described above to identify the URL of the Java AP distribution source server being executed, and the identified URL is the data to be read. It is determined whether or not the URL matches the added URL. 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 on the common scratch pad 91, the control unit 34 refers to the ADF of the fighting application and identifies the URL of the fighting application distribution source server. Then, the control unit 34 adds the identified URL and writes the data to the common scratch pad 91. On the other hand, when referring to this data while the RPG application is being executed, 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. It 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, the mobile device 3 of the present embodiment can realize data sharing only between Java APs downloaded from the same server, and is almost equivalent to the case of using an individual scratch pad. Data protection can be performed.
[0035]
<1-2. Operation of Embodiment>
In the following, for the sake of specific description, the RPG application and the fighting application will be taken as an example and the operation of the mobile device 3 will be mainly described.
<1-2-1. Installation and execution of Java AP>
FIG. 5 is a flowchart showing the operation of the control unit 34 when Java AP is installed in the mobile device 3.
First, the mobile device 3 receives the ADF of the RPG application from the data server 2 in accordance with a user operation on the operation unit 36. Specifically, the control unit 34 transmits an HTTP (Hypertext Transfer Protocol) GET command with the ADF URL 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 necessary for installation from the received description content of the ADF, and determines whether or not the RPG application can be installed in 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 ADF is written into the FlashROM (step S104), and the URL described in the ADF is used as an argument. A GET command to be transmitted is 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 the control unit 34 receives the JAR file, it first writes it in the JAR storage (step S107). Then, the control unit 34 creates an individual scratch pad 90 in the memory area having the capacity specified by the ADF in the Flash ROM (step S108), and assigns it to the RPG application (step S109). Further, the control unit 34 writes the initial setting file of the RPG application into 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, based on a user's operation, a control signal for instructing execution of the RPG application is supplied from the operation unit 36 to the control unit 34. Then, using this as a trigger, the control unit 34 starts execution processing of the RPG application. The control unit 34 loads JAM and KVM and constructs a Java AP execution environment. Then, the control unit 34 reads the initial setting 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 out the class file that is the RPG application main body from the JAR storage, and executes it.
[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 Java AP is additionally installed in the mobile device 3 and data is shared.
First, when the user performs a predetermined operation through the operation unit 36 while the mobile device 3 is executing the RPG application, the installation process is started using this as a trigger. The control unit 34 transmits a GET command with the URL of a file indicating a list of Java APs that can share data with the RPG application as an argument to the data server 2 via the wireless unit 30 (step S201). When receiving a list of Java APs 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 provides an argument with the URL of the ADF of the fighting application via the wireless unit 30. Is transmitted to the data server 2 (step S204). When receiving the ADF of the fighting app (S205), the control unit 34 interprets the description content of the ADF, and determines the conditions necessary for downloading and executing the fighting app (step S206). Hereinafter, the operations from Steps S207 to S210 are the same as the operations from Steps S104 to S107 described above, and thus the description thereof is omitted.
[0040]
Thereafter, the control unit 34 writes the conditions for interrupting and starting the fighting application in the initial setting file of the RPG application, and writes the initial setting file in the individual scratch pad 90 of the fighting application (step S211), and ends the process. Thereafter, when the condition described in the initial setting file is satisfied, the control unit 34 shifts the currently running RPG application to a standby state and interrupts and starts the fighting application.
[0041]
Now, the fighting application installed by the above procedure is interrupted and executed by the following procedure.
FIG. 7 is a flowchart showing the operation of the control unit 34 when executing the additionally installed Java AP.
[0042]
First, when the interrupt activation of the fighting application is the first time (step S301; Yes), the control unit 34 reads the initial setting file from the individual scratch pad 90 of the fighting application (step S302), and determines the description content (step S302). Step S303). And the control part 34 adds the setting which should be shared, such as the game difficulty of an RPG application, to the initial setting file of a fighting application, and writes this in the common scratchpad 91 (step S304). Thereafter, 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, when 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). Thereafter, when the execution of the fighting app is finished, the control unit 34 re-executes the Java AP in the standby state (step S308).
[0044]
When the interrupt activation of the fighting application is the second or later (step S301; No), the control unit 34 reads the initial setting file of the fighting application from the common scratch pad 91 (step S309). And the control part 34 identifies the description content of an initial setting file (step S310), and performs a fighting application based on this.
[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, Use 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, from the file to be read, the URL of the Java AP distribution source server that was being executed when the file was written (step S401). In the above example, the control unit 34 obtains the URL of the RPG application distribution source server. Then, the control unit 34 compares the acquired URL with the URL of the currently executing Java AP distribution source server (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 process.
[0046]
Since the individual scratch pad 90 is assigned to the fighting application, it is possible to start the fighting application alone. When the fighting application is activated alone, the control unit 34 reads and writes the initial setting file and the processing result file with respect 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 manner as normal Java AP.
[0047]
<3. Modification>
The communication system, server, mobile device, and data storage method of the present invention are not limited to the above-described embodiments, and various modifications can be made within the scope of the technical idea of the present invention. .
[0048]
(Modification 1) In the above-described embodiment, for data reading from the common scratch pad 91, the URL of the distribution source server added at the time of data writing and the URL of the distribution source server described in the ADF of the JavaAP being executed In the case where the two URLs coincide with each other, the description is made by taking a mode of permitting data sharing. However, a mode in which data reading from the common scratch pad 91 is not limited to the program distribution source server but may be extended to a plurality of servers belonging to the same domain as the program distribution source server. In short, the present invention is an aspect that authenticates reading of data from the common scratch pad 91 based on a specific security policy when data stored in the common scratch pad 91 is shared among a plurality of programs. The scope of the object for which authentication is established does not matter.
[0049]
(Modification 2) In the above-described embodiment, an example in which a URL is used for authentication when data is read from the common scratch pad 91 has been described. However, the information used for authentication is not limited to the URL. For the authentication, for example, any information such as an IP address or a MAC address may be used as long as the information can uniquely identify the program distribution source server. In short, as long as the present invention authenticates data reading from the common scratch pad 91 based on a specific security policy, any information may be used for authentication.
[0050]
(Modification 3) In the above-described embodiment, the data to be read from the common scratch pad 91 is the data to be read by the control unit 34 referring to the ADF and acquiring the URL of the JavaAP distribution source server being executed. Authenticated by comparing with the URL appended to. 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 that can uniquely identify data written on the common scratch pad 91 such as a file name and a URL of a Java AP distribution source server to which data read authority is given is stored in the FlashROM. This can also be used for reading data from the common scratch pad 91. In this case, when reading data from the common scratch pad 91, the control unit 34 compares the URL of the JavaAP distribution source server being executed with the URL associated with the data to be read in the management table. It is only necessary to read data only when the two URLs match. In short, as long as the present invention can authenticate data reading from the common scratch pad 91 based on a specific security policy, the 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 Java APs that can share data from the Java AP distribution source server being executed, and based on the description of the file, the common scratch is downloaded. The description has been given by taking the mode of realizing data sharing using the pad 91. However, a mode in which the URL or program name of a Java AP that can share data is described in advance in the ADF, and the common scratch pad 91 is accessed based on the URL or program name is described in advance. In short, if the present invention is an aspect capable of authenticating data read from the common scratch pad 91 based on a specific security policy, the authentication condition may be determined by the server 2. The mobile device 3 may be selected.
[0052]
【The invention's effect】
As described above, according to the present invention, while maintaining the security of data used during the execution of each program, it is possible to share data among a plurality of programs and improve the flexibility in handling data. It is possible to make it.
[Brief description of the drawings]
FIG. 1 is a diagram showing an overall configuration of a communication system.
FIG. 2 is a block diagram showing a configuration of a data server.
FIG. 3 is a block diagram showing 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 showing an operation of a control unit when Java AP is installed in a mobile device.
FIG. 6 is a flowchart showing the operation of the control unit when Java AP is additionally installed in a mobile device and data is shared.
FIG. 7 is a flowchart showing the operation of the control unit when executing the additionally installed Java AP.
FIG. 8 is a flowchart showing an operation when a control unit accesses a common scratch pad.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 100 ... Communication system, 1 ... Mobile packet communication network, 2 ... Data server, 3 ... Mobile device, 34 ... Control part, 90 ... Individual scratch pad, 91 ... Common scratch pad.

Claims

Receiving means for receiving a program distributed from a distribution source;
Program storage means for storing a program received by the receiving means;
Data storage means for storing data generated by executing a program stored in the program storage means;
Data writing means for writing data generated by execution of the program into the data storage means;
A data reading means for reading out data stored in the data storage means when the program is executed;
The data writing means writes the data into the data storage means, and authenticates the specific information for uniquely identifying the distribution source of the program executed when the data is generated, for authenticating the reading of the data Write as authentication information,
It said data reading means, when reading the data stored in the data storing means, using the authentication information of the data, a means for authenticating the reading of the data, the program distribution source to be executed A communication terminal which reads data to be read when the specific information to be uniquely specified matches the specific information written as authentication information of the data to be read .

Receiving means for receiving a program distributed from a distribution source;
Program storage means for storing a program received by the receiving means;
Data storage means for storing data generated by executing a program stored in the program storage means;
Data writing means for writing data generated by execution of the program into the data storage means;
Data reading means for reading data stored in the data storage means when the program is executed;
A communication terminal comprising:
The data writing means writes the data into the data storage means, and writes the domain name of the distribution source of the program executed when generating the data as authentication information for authenticating the reading of the data ,
The data reading means is means for authenticating reading of the data using the authentication information of the data when reading the data stored in the data storage means, and is a distribution source of the program to be executed When the domain name matches the domain name written as the authentication information for the data to be read, the data to be read is read
A communication terminal characterized by that.

Receiving means for receiving a program distributed from a distribution source;
Program storage means for storing a program received by the receiving means;
Data storage means for storing data generated by executing a program stored in the program storage means;
Data writing means for writing data generated by the execution of the program into the data storage means;
Data reading means for reading data stored in the data storage means when the program is executed;
A communication terminal comprising:
The data writing means writes the data into the data storage means, and the address data described in the file of the program when the program executed when the data is generated is distributed. Write as authentication information for authenticating the reading of
The data reading means is means for authenticating reading of the data using the authentication information of the data when reading the data stored in the data storage means, and is a distribution source of the program to be executed When the address matches the address written as the authentication information of the data to be read, the data to be read is read
A communication terminal characterized by that.