JP6131817B2 - 通信端末、通信処理方法および通信処理プログラム - Google Patents

Description

本発明は、通信端末、通信処理方法および通信処理プログラムに関する。

通信端末の一例として、スマートフォンや携帯電話、タブレット端末等がある。近年の通信端末は、単に通信を行うだけでなく、通信端末でアプリケーションを実行することが可能になってきている。

通信端末で実行されるアプリケーションの一例として、ネイティブアプリケーション（native application）と称されるアプリケーションがある。このネイティブアプリケーションは、通信端末のＯＳ(Operating System）で実行されるアプリケーションである。従って、ネイティブアプリケーションは通信端末のＯＳ依存性が高い。

また、通信端末で実行されるアプリケーションの一例として、Ｗｅｂアプリケーションと称されるアプリケーションがある。Ｗｅｂアプリケーションは、通信端末のブラウザで実行されるアプリケーションである。従って、Ｗｅｂアプリケーションは、ＯＳ依存性が低い。

Ｗｅｂアプリケーションの一例として、ＨＴＭＬ（Hyper Text Markup Language）５アプリケーションがある。ＨＴＭＬ５アプリケーションは、Ｗ３Ｃ（World Wide Web Consortium)が提唱するＨＴＭＬ５の規格による準拠しているアプリケーションである。

ＨＴＭＬ５には、オリジンが使用される。Ｗ３Ｃが提唱する規格では、オリジンは、プロトコルとドメイン（ホスト）とポート番号とを有する。オリジンに関連する技術として、Ｗｅｂページを構成するＨＴＭＬ文書内で、文書の部分ごとにそのオリジンに基づいたアクセス制御を行う技術が提案されている（例えば、特許文献１参照）。

特開２００８−２９９４１４号公報

アプリケーションの利用形態の一例として、アプリケーション本体を外部のＷｅｂサーバに設置する利用形態では、通信端末は外部のＷｅｂサーバと通信を行い、外部のＷｅｂサーバに設置されているアプリケーションを実行する。従って、通信端末はアプリケーションを取得することなく、アプリケーションを実行する。

通信端末がアプリケーションを実行するときに、アプリケーションは、通信端末が有する記憶装置に情報を記憶する。このとき、アプリケーションは、オリジンごとに異なる記憶領域を使用することとＷ３Ｃの規格で定められている。この記憶領域はローカルストレージとも称される。

従って、外部のＷｅｂサーバと通信端末とが通信を行うことにより通信端末がアプリケーションを実行する場合、複数のアプリケーションはオリジンが異なる。このため、各アプリケーションは異なるローカルストレージを使用する。

一方、アプリケーションの利用形態の一例として、通信端末が外部のＷｅｂサーバからアプリケーションを取得（ダウンロード）して利用する形態がある。通信端末は、取得したアプリケーションを記憶装置に保存する。通信端末がアプリケーションを実行するときには、記憶したアプリケーションを呼び出して、アプリケーションを実行する。通信端末は複数のアプリケーションを取得することが可能である。

通信端末にアプリケーションが取得されると、アプリケーションのオリジンは、外部のＷｅｂサーバではなく、通信端末を示すようになる。上述したように、ローカルストレージはオリジンごとに異なる記憶領域を使用する。

従って、複数のアプリケーションのオリジンが同じ通信端末を示すと、複数のアプリケーションは同一の記憶領域を使用する。この記憶領域は、ローカルストレージとも称される。従って、この場合、同一のローカルストレージが使用されることになる。

このため、複数のアプリケーションのそれぞれが、他のアプリケーションが使用する情報を参照や更新することができる。例えば、１つのアプリケーションが書き込んだ情報を他のアプリケーションが参照することがある。また、１つのアプリケーションが書き込んだ情報に対して他のアプリケーションが上書きをすることがある。この場合、上書きされる前の情報は失われる。

１つの側面では、本発明は、通信端末に取得されたアプリケーションが、通信端末の異なる記憶領域を使用することを目的とする。

１つの案では、通信端末は、取得部、記憶部、設定部、実行部および処理部を備える。取得部は、アプリケーションを取得する。記憶部は、前記取得部が取得したアプリケーションごとに前記通信端末の内部で使用されるオリジンを含む情報を記憶する。設定部は、前記記憶部に記憶されていないオリジンのアプリケーションを前記取得部が取得したときに、前記取得部が取得したアプリケーションに対して前記記憶部が記憶している前記オリジンを含む情報と異なるオリジンを含む情報を設定する。実行部は、前記アプリケーションを実行する。処理部は、前記実行部が要求したオリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力する。

通信端末に取得されたアプリケーションが、通信端末の異なる記憶領域を使用することができる。

通信端末の構成の一例を示す図である。 アプリケーション使用領域部の一例を示すブロック図である。 実施形態の処理の一例を示すフローチャートである。 端末内Ｗｅｂサーバを設けた構成の一例を示す図である。 リクエストフック部を設けた構成の一例を示す図である。 通信端末のハードウェア構成の一例を示す図である。 実施例１の処理の一例を示すシーケンス図である。 実施例１のテーブルの一例を示す図である。 実施例１のアプリケーション使用領域部の一例を示す図である。 実施例２の処理の一例を示すシーケンス図である。 実施例２のテーブルの一例を示す図である。 実施例３の処理の一例を示すシーケンス図である。 実施例４の処理の一例を示すシーケンス図である。 実施例５の通信端末の構成一例を示す図である。 実施例５のアプリケーション使用領域部の一例を示す図である。

以下、図面を参照して、実施形態について説明する。図１は、実施形態の通信端末の構成の一例を示している。図１の一例で示すように、通信端末１は外部サーバ２と通信を行う。通信端末１は、アプリケーションを実行可能な環境を有している。通信端末１の一例として、スマートフォン等を適用することができる。

実施形態では、アプリケーションは、Ｗｅｂブラウザで実行されるＷｅｂアプリケーションであるものとする。また、一例として、Ｗｅｂアプリケーションは、Ｗ３Ｃで提唱されているＨＴＭＬ５を利用したＨＴＭＬ５アプリケーションであるものとする。以下、ＨＴＭＬ５アプリケーションを単にアプリケーションと称して説明する。

外部サーバ２は、アプリケーションを保持している。図１は、外部サーバ２が１つのアプリケーションを保持している一例を示しているが、外部サーバ２は複数のアプリケーションを保持していてもよい。

図１に一例として示した通信端末１は、制御部３と実行部４とアプリケーション使用領域部５と表示部６とを備えている。通信端末１は他の構成を備えていてもよい。制御部３は、通信部１０とアプリケーション取得部１１とアプリケーション保存部１２と端末内ＵＲＬ設定部１３とテーブル記憶部１４とアプリケーション使用領域部５リクエスト処理部１６とロード要求部１７とを備えている。

実行部４は、Ｗｅｂブラウザでアプリケーションを実行する機能を有している。実行部４は、ＨＴＭＬレンダリングエンジンと称されることもある。ＨＴＭＬレンダリングエンジンは、ウェブページ記述用言語で書かれたデータを解釈して、アプリケーションを実行する。ＨＴＭＬレンダリングエンジンの一例にＷｅｂＫｉｔがある。

アプリケーション使用領域部５は、アプリケーションが使用する記憶領域である。この領域は、ローカルストレージと称されることもある。一例として、ローカルストレージは、１つの記憶装置の記憶領域を論理的に分割した領域とすることができる。

アプリケーションは、ＩＤやパスワードといったパラメータ等の情報をローカルストレージに書き込む。アプリケーション使用領域部５は、オリジンごとに複数のローカルストレージを有している。

図２は、アプリケーション使用領域部５の一例を示している。図２の一例では、アプリケーション使用領域部５は、アプリケーションＡのローカルストレージ１５ＡとアプリケーションＢのローカルストレージ１５Ｂとを有している。

図２に一例として示すように、アプリケーションＡの端末内ＵＲＬに含まれるオリジンとアプリケーションＢの端末内ＵＲＬに含まれるオリジンとは異なる。
アプリケーションＡ："http://localhost:10000/"（端末内ＵＲＬは"http://localhost:10000/app"）
アプリケーションＢ："http://localhost:10001/"（端末内ＵＲＬは"http://localhost:10001/app"）
従って、アプリケーションＡとアプリケーションＢとはオリジンが異なるため、異なるローカルストレージが使用される。

表示部６は、通信端末１に備えられる表示装置である。表示部６は、アプリケーションを実行するときに種々の情報を表示する。表示部６は、入力機能を有していてもよい。一例として、表示部６はタッチパネルを適用することができる。

通信部１０は、外部サーバ２と通信を行う。通信部１０はアプリケーション取得部１１により制御される。アプリケーション取得部１１は、通信部１０を制御して、外部サーバ２からアプリケーションを取得する。アプリケーション取得部１１がアプリケーションを外部サーバ２から取得することは、ダウンロードとも称される。アプリケーション取得部１１は、取得部の一例である。

アプリケーション保存部１２は、アプリケーション取得部１１が取得したアプリケーションを保存する。アプリケーション保存部１２には複数のアプリケーションを保存することが可能である。アプリケーション保存部１２は、保存部の一例である。

端末内ＵＲＬ設定部１３は、アプリケーション取得部１１が取得したアプリケーションに対して端末内ＵＲＬを設定する。端末内ＵＲＬは、通信端末１の内部で使用されるオリジンを含む。

端末内ＵＲＬ設定部１３は、複数のアプリケーションのそれぞれのオリジンが異なるように、端末内ＵＲＬを設定する。これにより、設定された端末内ＵＲＬは、各アプリケーションの端末内ＵＲＬと重複しない。端末内ＵＲＬ設定部１３は設定部の一例である。

端末内ＵＲＬは、一例として、プロトコルとドメイン（ホスト）とポート番号とパスを有する。実施形態では、端末内ＵＲＬ設定部１３は、プロトコルに"http"を使用するものとする。ただし、プロトコルは"http"には限定されない。また、パスは省略してもよい。従って、端末内ＵＲＬ設定部１３は、複数のアプリケーションのオリジンが重複しないように、ドメインとポート番号とのうち少なくとも一方を設定する。ただし、端末内ＵＲＬ設定部１３は、プロトコルを設定してもよい。端末内ＵＲＬのプロトコルとドメイン（ホスト）とポート番号とがオリジンを示すものであり、端末内ＵＲＬはオリジン情報を含んだものとなる。

テーブル記憶部１４は、アプリケーションごとに端末内ＵＲＬを記憶する。一例として、実施形態では、外部サーバ２が保持していたアプリケーションの提供元の情報と端末内ＵＲＬとを関連付けて記憶する。アプリケーションの提供元の情報は、ＵＲＬ（Uniform Resource Locator）を適用することができる。以下、このＵＲＬをアプリケーションＵＲＬと称することもある。

リクエスト処理部１６は、実行部４がアプリケーションを要求したときに、アプリケーションを実行部４に出力する処理を行う。実行部４は、アプリケーションを要求するときに、端末内ＵＲＬを出力する。リクエスト処理部１６は、端末内ＵＲＬとアプリケーションとを関連付けて、アプリケーションと共に端末内ＵＲＬを実行部４に出力する。リクエスト処理部１６は、処理部の一例である。

ロード要求部１７はアプリケーションを実行部４に対して、実行部４がアプリケーションを読み出すように要求を出す。この要求に応じて、実行部４は、アプリケーション保存部１２に保存されているアプリケーションを読み出す。ロード要求部１７は要求部の一例である。

次に、図３を参照して、実施形態の処理について説明する。通信部１０は、外部サーバ２と通信を行う。アプリケーション取得部１１は、外部サーバ２からアプリケーションおよびアプリケーションＵＲＬを取得する（ステップＳ１）。アプリケーションは、任意の形式で取得されてよく、一例として、ファイル形式で取得されてもよい。

アプリケーション取得部１１が取得したアプリケーションは、アプリケーション保存部１２に保存される。また、アプリケーション取得部１１は、アプリケーションＵＲＬを端末内ＵＲＬ設定部１３に出力する。

端末内ＵＲＬ設定部１３は、テーブル記憶部１４のテーブルの中からアプリケーションＵＲＬを検索する（ステップＳ２）。端末内ＵＲＬ設定部１３は、アプリケーション取得部１１が取得したアプリケーションＵＲＬがテーブルの中にあるか否かを判定する（ステップＳ４）。

テーブルにアプリケーションＵＲＬが記憶されている場合（ステップＳ３でＹＥＳ）、リクエスト処理部１６はアプリケーションＵＲＬに対応する端末内ＵＲＬをテーブル記憶部１４から取得する（ステップＳ４）。

一方、テーブルにアプリケーションＵＲＬが記憶されていない場合（ステップＳ３でＮＯ）、端末内ＵＲＬ設定部１３は、アプリケーションＵＲＬに対応する端末内ＵＲＬを設定する（ステップＳ５）。端末内ＵＲＬ設定部１３は、テーブル記憶部１４に記憶されている端末内ＵＲＬと異なる端末内ＵＲＬを設定する。

端末内ＵＲＬ設定部１３は、設定した端末内ＵＲＬをアプリケーションＵＲＬと関連付けて、テーブル記憶部１４のテーブルに記憶する（ステップＳ６）。これにより、テーブル記憶部１４のテーブルに新たに１つの端末内ＵＲＬおよび対応するアプリケーションＵＲＬが追加される。

リクエスト処理部１６は、端末内ＵＲＬを取得する（ステップＳ７）。ステップＳ３でＹＥＳの場合には、ステップＳ４でリクエスト処理部１６は端末内ＵＲＬを取得する。リクエスト処理部１６は、端末内ＵＲＬとアプリケーションとを関連付ける（ステップＳ８）。リクエスト処理部１６は、ロード要求部１７に対して、関連付けが完了したことを通知すると共に、設定された端末内ＵＲＬをロード要求部１７に出力する（ステップＳ９）。

ロード要求部１７は、外部サーバ２から取得したアプリケーションを読み出すように実行部４に要求すると共に、端末内ＵＲＬを実行部４に出力する（ステップＳ１０）。実行部４は、ロード要求部１７の要求に応じて、リクエスト処理部１６に端末内ＵＲＬを出力する。

ロード要求部１７が実行部４にアプリケーションを読み出すように要求することにより、通信端末１がアプリケーションを取得したときに、自動的に実行部４がアプリケーションを実行することができる。

リクエスト処理部１６は、入力した端末内ＵＲＬに関連付けられたアプリケーションを実行部４に出力する。実行部４は、入力したアプリケーションを実行する（ステップＳ１１）。以上に示した一例の処理により、通信端末１が外部サーバ２からアプリケーションを取得し、取得したアプリケーションを実行する手順が終了する。

端末内ＵＲＬ設定部１３が、新たなアプリケーションＵＲＬに対応する端末内ＵＲＬをテーブル記憶部１４に設定するときには、既に設定されているアプリケーションＵＲＬの端末内ＵＲＬと新たに設定する端末内ＵＲＬとが異なるように設定する。

一例として、外部サーバ２が保持しているアプリケーションのアプリケーションＵＲＬが"http://app.example.com/app"であるものとする。端末内ＵＲＬ設定部１３は、一例として、端末内ＵＲＬを"http://localhost:10000/app"に設定する。端末内ＵＲＬ設定部１３は、このアプリケーションとは異なるアプリケーションに対しては、端末内ＵＲＬを"http://localhost:10001/app"に設定する。

従って、アプリケーションの端末内ＵＲＬが重複することがない。アプリケーション使用領域部５は、通信端末１が取得した各アプリケーションが使用する領域である。アプリケーション使用領域部５は、オリジンごとに使用する領域が異なる。

アプリケーションＡのオリジンとアプリケーションＢのオリジンとが異なれば、アプリケーションＡとアプリケーションＢとは同一の領域を使用しない。この場合、アプリケーション使用領域部５には、図２に示したように、アプリケーションＡのローカルストレージとアプリケーションＢのローカルストレージとが生成される。

このため、通信端末１が外部サーバ２から複数のアプリケーションを通信端末１に取得したとしても、各アプリケーションの実行時にアプリケーション使用領域部５の同一の領域を使用することがない。

テーブル記憶部１４は、アプリケーションＵＲＬと端末内ＵＲＬとを関連付けて記憶している。従って、通信端末１が同一のアプリケーションＵＲＬから再び同一のアプリケーションＡを取得したとしても、同一のアプリケーションＡはアプリケーション使用領域部５の同一の領域を継続的に使用することができる。

一方、アプリケーションＡとは異なるアプリケーションＢは、アプリケーションＡが使用する領域を使用することができない。一例として、アプリケーションＢは、アプリケーションＡが使用する領域を参照や更新等を行うことはできなくなる。つまり、アプリケーション使用領域部５の各領域の情報を保護することができる。

実行部４がＷｅｂブラウザでアプリケーションを実行するときに、リクエスト処理部１６に対してアプリケーションを読み出す要求を行う。このとき、実行部４は、端末内ＵＲＬを制御部３のリクエスト処理部１６に出力する。

端末内ＵＲＬとアプリケーションとは関連付けがされており、リクエスト処理部１６は、実行部４から出力された端末内ＵＲＬに対応するアプリケーションを実行部４に出力する。これにより、実行部４はアプリケーションを実行することができる。

そして、実行部４が実行するアプリケーションは、アプリケーション使用領域部５の異なる領域を使用することから、複数のアプリケーションが同一の領域を使用することがなくなる。従って、複数のアプリケーションのうち、１つのアプリケーションが使用している情報を、他のアプリケーションが参照や更新等ができないようにすることができる。

図４は、図１の変形例を示している。図４に示す一例では、リクエスト処理部１６は２つの端末内Ｗｅｂサーバ１８を有している。リクエスト処理部１６は、少なくともテーブル記憶部１４のテーブルに記憶されている端末内ＵＲＬの個数分の端末内Ｗｅｂサーバ１８を有している。端末内Ｗｅｂサーバ１８は、端末内サーバの一例である。

実行部４は、端末内Ｗｅｂサーバ１８に対して、端末内ＵＲＬに対応するアプリケーションを要求する。端末内Ｗｅｂサーバ１８は仮想的なＷｅｂサーバとして機能し、実行部４の要求に対して、端末内ＵＲＬに対応するアプリケーションを実行部４に出力する。実行部４は端末内Ｗｅｂサーバ１８から入力したアプリケーションを実行する。

端末内Ｗｅｂサーバ１８はそれぞれ異なる端末内ＵＲＬに対応している。それぞれ異なる端末内ＵＲＬはそれぞれ異なるオリジンをもつ。従って、実行部４がアプリケーションを実行するときには、アプリケーションはアプリケーション使用領域部５の異なる領域を使用する。

一例として、リクエスト処理部１６は、アプリケーションＡに対応する端末内Ｗｅｂサーバ１８ＡとアプリケーションＢに対応する端末内Ｗｅｂサーバ１８Ｂとを有しているものとする。実行部４が端末内Ｗｅｂサーバ１８Ａの端末内ＵＲＬを要求した場合、リクエスト処理部１６はアプリケーションＡを実行部４に出力する。

アプリケーション使用領域部５は、端末内Ｗｅｂサーバ１８Ａの端末内ＵＲＬに含まれるオリジンに対応した領域（ローカルストレージＡ）と端末内Ｗｅｂサーバ１８Ｂの端末内ＵＲＬに含まれるオリジンに対応した領域（ローカルストレージＢ）とを別個に有している。実行部４が実行するアプリケーションＡは、ローカルストレージＡを使用する。

なお、実行部４が端末内Ｗｅｂサーバに端末内ＵＲＬに対応するアプリケーションを要求する場合、端末内ＵＲＬのホスト（ドメイン）は、通信端末１を示すように設定する。一例として、端末内ＵＲＬは"http://localhost:10000/app"と設定することができる。

図５は、図１の他の変形例を示している。図５に示す一例では、リクエスト処理部１６は、リクエストフック部１９を有している。リクエストフック部１９は、実行部４から出力される端末内ＵＲＬの要求を監視している。実行部４がリクエスト処理部１６にアプリケーションの要求を出力した場合には、リクエストフック部１９が実行部４の要求を取得する。

リクエストフック部１９は、実行部４が要求した端末内ＵＲＬに関連付けられたアプリケーションをアプリケーション保存部１２から取得して、実行部４にアプリケーションを出力する。そして、実行部４はアプリケーションを実行する。

図５に示した一例のリクエスト処理部１６は、図４に示した一例の端末内Ｗｅｂサーバ１８を有していなくてもよい。端末内Ｗｅｂサーバ１８は所定のハードウェア資源を要する。通信端末１が端末内Ｗｅｂサーバ１８を有するためのハードウェア資源が不足している場合には、図５に一例で示したリクエストフック部１９を使用してもよい。

一方、リクエストフック部１９は実行部４からの要求を常に監視している必要があるため、処理の負担が大きい。従って、ハードウェア資源に余裕があれば、端末内Ｗｅｂサーバ１８を使用し、ハードウェア資源に余裕がなければ、リクエストフック部１９を使用することができる。

次に、図６を参照して、通信端末１のハードウェアの構成の一例を示す。図６に示すように、通信端末１は、バス２１に対して、プロセッサ２２とＲＡＭ（Random Access Memory）２３とＲＯＭ（Read Only Memory)２４と補助記憶装置２５と通信インタフェース２６と可搬型記憶装置接続部２７とが接続されている。

プロセッサ２２はＣＰＵ（Central Processing Unit)のような任意の処理回路である。プロセッサ２２はＲＡＭ２３に展開されたプログラムを実行する。ＲＯＭ２４はＲＡＭ２３に展開されるプログラムを記憶する不揮発性の記憶装置である。ＲＡＭ２３に展開されるプログラムは補助記憶装置２５に記憶されていてもよい。記憶装置の一例としては、半導体メモリやハードディスクドライブ等を適用することができる。

可搬型記憶装置接続部２７は、可搬型記憶装置と接続可能に設けられている。可搬型記憶装置としては、可搬型のメモリや光学式ディスク（例えば、ＣＤ（Compact Disk)やＤＶＤ（Digital Video Disk)等）を適用することができる。

ＲＡＭ２３、ＲＯＭ２４および補助記憶装置２５は、何れもコンピュータ読み取り可能な有形の記憶媒体の一例である。これらの有形な記憶媒体は、信号搬送波のような一時的な媒体ではない。

一例として、通信部１０は通信インタフェース２６により実現されてもよい。アプリケーション取得部１１、端末内ＵＲＬ設定部１３、リクエスト処理部１６およびロード要求部１７はプロセッサ２２により実現されてもよい。また、端末内Ｗｅｂサーバ１８、リクエストフック部１９および後述するストレージコピー部３０もプロセッサ２２により実現されてもよい。アプリケーション保存部１２およびテーブル記憶部１４は、ＲＡＭ２３、ＲＯＭ２４、補助記憶装置２５または可搬型記憶装置接続部１７に接続される可搬型記憶装置により実現されてもよい。

アプリケーション使用領域部５はＲＡＭ２３により実現されてもよい。アプリケーション使用領域部５の各ローカルストレージはＲＡＭ２３の異なる論理領域を使用することにより実現されてもよい。

次に、図７〜図９を参照して、実施例１について説明する。実施例１では、図４に一例として示した構成を適用する。つまり、リクエスト処理部１６が端末内Ｗｅｂサーバ１８を有しているものとする。ただし、図１の構成を実施例１に適用してもよい。

実施例１に示す一例では、通信端末１のアプリケーション保存部１２には既にアプリケーションＡおよびアプリケーションＢが保存されているものとする。そして、通信端末１は、外部サーバ２に設置されているアプリケーションＣにはアクセスしたことがないものとする。

図７は、実施例１の一例を示すシーケンス図である。図７において、アプリケーション取得部１１は取得部１１として示している。端末内ＵＲＬ設定部１３は設定部１３として示している。リクエスト処理部１６は処理部１６として示している。ロード要求部１７は要求部１７として示している。また、図７において、アプリケーションを「アプリ」として省略して示している場合もある。

図７に示すように、最初に、アプリケーションＣの実行要求が行われる（ステップＳ２１）。アプリケーションＣの実行要求の一例としては、ユーザがＵＩ（User Interface)を操作すること等により、アプリケーションＣの実行が要求される。

また、一例として、プッシュ配信の場合には、実行部４は自動的にアプリケーションＣの実行要求を行う。プッシュ配信の場合には、通信端末１を所持するユーザの操作がなくとも、外部サーバ２から自動的にアプリケーションＣが通信端末１に配信されて、アプリケーションＣの実行が要求される。

実行部４は、アプリケーションＣの実行要求が行われた場合には、実行部４はアプリケーション取得部１１に対してアプリケーションＣを取得するように要求する（ステップＳ２２）。このとき、実行部４は、取得するアプリケーションのＵＲＬ（アプリケーションＵＲＬ）をアプリケーション取得部１１に出力する。

ここでは、アプリケーションＵＲＬの一例として"http://app.example.com/app"であるものとする。アプリケーション取得部１１は通信部１０を制御して、上記のアプリケーションＵＲＬとして外部サーバ２が保持していたアプリケーションＣを取得する（ステップＳ２３）。

アプリケーション取得部１１は、取得したアプリケーションＣと上記のアプリケーションＵＲＬとを端末内ＵＲＬ設定部１３に出力する（ステップＳ２４）。端末内ＵＲＬ設定部１３は、テーブル記憶部１４のテーブルに上記の"http://app.example.com/app"があるか否かを検索する（ステップＳ２５）。

実施例１では、通信端末１は"http://app.example.com/app"にアクセスしたことがない。従って、テーブル記憶部１４のテーブルには"http://app.example.com/app"はない。図８（Ａ）は、テーブル記憶部１４のテーブルの一例である。この中には、アプリケーションＣのアプリケーションＵＲＬはない。

端末内ＵＲＬ設定部１３は、テーブル記憶部１４のテーブルに記憶されている端末内ＵＲＬと異なるオリジンを含む端末内ＵＲＬを生成して、テーブルに記憶する（ステップＳ２６）。図８（Ａ）で示した一例では、下記の２つの端末内ＵＲＬが既に使用されている。
"http://localhost:10000/app"
"http://localhost:10001/app"

従って、端末内ＵＲＬ設定部１３は、これらの端末内ＵＲＬと異なるように、新たな端末内ＵＲＬを設定する。ここでは、"http://localhost:10002/app"が設定されるものとする。この端末内ＵＲＬは、"http://app.example.com/app"のアプリケーションＵＲＬと対応している。

従って、端末内ＵＲＬ設定部１３は、端末内ＵＲＬとアプリケーションＵＲＬとを対応付けて、新たにテーブル記憶部１４のテーブルに記憶する。図８（Ｂ）は、更新されたテーブルの一例を示している。図８（Ｂ）に示されるように、端末内ＵＲＬは全て異なっている。

端末内ＵＲＬ設定部１３は、端末内ＵＲＬとアプリケーションとをリクエスト処理部１６に出力する（ステップＳ２７）。リクエスト処理部１６は、端末内ＵＲＬとアプリケーションとを関連付ける（ステップＳ２８）。アプリケーションはアプリケーションＣであり、端末内ＵＲＬは"http://localhost:10002/app"である。よって、リクエスト処理部１６は、アプリケーションＣと端末内ＵＲＬ"http://localhost:10002/app"とを関連付ける。

ステップＳ２８の関連付けが完了すると、リクエスト処理部１６は関連付けが完了したことを端末内ＵＲＬ設定部１３に通知する（ステップＳ２９）。この通知を受けると、端末内ＵＲＬ設定部１３は、ロード要求部１７に上記の関連付けが完了したことを通知する（ステップＳ３０）。

ステップＳ３０の通知を受けると、ロード要求部１７は、端末内ＵＲＬのロード依頼を発行する（ステップＳ３１）。これは、実行部４に対して、端末内ＵＲＬが示すアプリケーションを読み出す要求である。ロード要求部１７がロード依頼を要求する端末内ＵＲＬは、"http://localhost:10002/app"である。

実行部４は、リクエスト処理部１６に端末内ＵＲＬ"http://localhost:10002/app"が示すアプリケーションを要求する（ステップＳ３２）。リクエスト処理部１６には、端末内ＵＲＬ"http://localhost:10002/app"を有する端末内Ｗｅｂサーバ１８が設定されている。

この端末内Ｗｅｂサーバ１８は、端末内ＵＲＬ"http://localhost:10002/app"に対応するアプリケーションＣを実行部４に出力する（ステップＳ３３）。従って、実行部４は新たに取得したアプリケーションＣを実行することができる。実行部４がアプリケーションＣを実行するときには、アプリケーション使用領域部５を使用する。一例として、ＩＤやパスワード等のパラメータが使用される。

図９は、アプリケーション使用領域部５の一例を示している。図９に示すように、アプリケーション使用領域部５は、アプリケーションＣのローカルストレージ１５Ｃが追加されている。このローカルストレージ１５ＣはアプリケーションＣの使用領域である。

図９に示した一例では、アプリケーション使用領域部５は、ローカルストレージ１５Ａとローカルストレージ１５Ｂとローカルストレージ１５Ｃとを有している。ローカルストレージ１５ＣはアプリケーションＣの使用領域であるため、アプリケーションＡおよびアプリケーションＢは使用することができない。つまり、アプリケーションＡおよびアプリケーションＢはローカルストレージ１５Ｃの情報を参照や更新等を行うことができない。これにより、アプリケーションＣが使用する情報の保護を図ることができる。

新たにアプリケーションが追加されたとしても、端末内ＵＲＬ設定部１３がテーブル記憶部１４に既に記憶されている端末内ＵＲＬに含まれるオリジンとは異なるオリジン情報を持つ端末内ＵＲＬを新たなアプリケーションに対して付与する。アプリケーション使用領域部５の使用領域はオリジンごとに付与されるため、新たなアプリケーションが使用する情報を他のアプリケーションから保護することができる。

次に、図１０および図１１を参照して、実施例２について説明する。実施例２では、図４に一例として示した構成を適用する。つまり、リクエスト処理部１６が端末内Ｗｅｂサーバ１８を有しているものとする。また、通信端末１が外部サーバ２からアプリケーションＣを取得する。通信端末１は、外部サーバ２のアプリケーションＣにアクセスしたことがないものとする。

図１０は、実施例２のシーケンス図を示している。実施例１で示した図７のシーケンス図と異なるのは、図７のシーケンス図のステップＳ２６である。実施例１では、端末内ＵＲＬ設定部１３は、ステップＳ２５において、テーブル記憶部１４を検索した結果、取得したアプリケーションＣのアプリケーションＵＲＬがなかった場合を示した。

実施例２の一例では、アプリケーション取得部１１が外部サーバ２から取得したアプリケーションＣは既にアプリケーション保存部１２に保存されているものとする。端末内ＵＲＬ設定部１３は、ステップＳ２５において、テーブル記憶部１４を検索する。端末内ＵＲＬ設定部１３が検索するのは、アプリケーションＣのアプリケーションＵＲＬである。一例として、端末内ＵＲＬ設定部１３は、"http://app.example.com/app"を検索する。

図１１は、実施例２におけるテーブル記憶部１４に記憶されているテーブルの一例である。端末内ＵＲＬ設定部１３は、"http://app.example.com/app"がテーブルにあるか否かを検索する。図１１に示すように、テーブルには、"http://app.example.com/app"が記憶されている。

従って、端末内ＵＲＬ設定部１３は、テーブル記憶部１４のテーブルを参照して、上記の"http://app.example.com/app"に対応する端末内ＵＲＬを取得する（ステップＳ３４）。図１１に示す一例では、端末内ＵＲＬは、"http://localhost:10002/app"である。

端末内ＵＲＬ設定部１３は、新たに端末内ＵＲＬを設定することなく、既存の端末内ＵＲＬを使用する。つまり、端末内ＵＲＬ"http://localhost:10002/app"を継続的に使用する。

端末内ＵＲＬ"http://localhost:10002/app"が示すアプリケーションＣは既に通信端末１の内部で使用されている。従って、アプリケーション取得部１１が新たにアプリケーションＣを外部サーバ２から取得したときには、従前にアプリケーションＣが使用していた端末内ＵＲＬを使用する。すなわち、従前にアプリケーションＣが使用していたオリジンを使用する。

新たに取得したアプリケーションＣは、従前にアプリケーションＣが使用していたアプリケーション使用領域部５の同じ領域を使用する。つまり、新たに取得したアプリケーションＣは、従前にアプリケーションＣが使用していたローカルストレージ１５Ｃを継続的に使用する。

例えば、外部サーバ２が保持しているアプリケーションＣがバージョンアップ等した場合は、新たに取得したアプリケーションＣは従前に使用していたアプリケーションＣのパラメータ等の情報を使用することが好ましい。

上述したように、新たに取得したアプリケーションＣは、従前にアプリケーションＣが使用していたローカルストレージ１５Ｃを使用するため、パラメータ等の情報を継続的に使用することができる。

実施例１および実施例２では、リクエスト処理部１６の処理は端末内Ｗｅｂサーバ１８が行っていた。従って、実行部４からアプリケーションの要求があった場合には、要求があったアプリケーションに対応する端末内Ｗｅｂサーバ１８がアプリケーションを実行部４に出力していた。実施例３は、リクエスト処理部１６は、端末内Ｗｅｂサーバ１８を有しておらず、図５で説明したリクエストフック部１９を有している一例である。

また、実施例３では、通信端末１がアクセスしたことのないアプリケーションＣを取得する一例を示す。このため、端末内ＵＲＬ設定部１３は、新たに取得したアプリケーションＣのアプリケーションＵＲＬがテーブル記憶部１４のテーブルに記憶されているか否かを検索する。

実施例３では、テーブル記憶部１４にはアプリケーションＣのアプリケーションＵＲＬは記憶されていない。従って、端末内ＵＲＬ設定部１３は、テーブルに記憶されている端末内ＵＲＬと異なる端末内ＵＲＬを設定する。実施例３では、アプリケーションＣの端末内ＵＲＬは"http://localhost:10002/app"とする。

図１２は、実施例３のシーケンス図を示している。図１２のシーケンス図は、図７に示したシーケンス図のステップＳ３２の部分が異なる。リクエストフック部１９は、実行部４が出力する端末内ＵＲＬの要求を監視している。そして、リクエストフック部１９は、実行部４からアプリケーションＣの端末内ＵＲＬ"http://localhost:10002/app"の要求が出力されたときに、当該要求を取得する（ステップＳ３５）。

そして、リクエストフック部１９は、出力された端末内ＵＲＬの要求に対応して、端末内ＵＲＬ"http://localhost:10002/app"に対応するアプリケーションＣを実行部４に出力する。これにより、実行部４はアプリケーションＣを実行することができる。

通信端末１が端末内Ｗｅｂサーバ１８を設けるハードウェア資源に余裕がない場合には、リクエスト処理部１６のリクエストフック部１９により処理する。この場合でも、端末内ＵＲＬ設定部１３がアプリケーションごとにことなるオリジンを持つ端末内ＵＲＬを設定することで、各アプリケーションが使用するローカルストレージを保護することができる。

実施例４に示す一例では、リクエスト処理部１６は、端末内Ｗｅｂサーバ１８を有しておらず、リクエストフック部１９を有している。また、実施例３では、通信端末１が取得したことがあるアプリケーションＣを新たに取得する一例を示す。

このため、端末内ＵＲＬ設定部１３は、新たに取得したアプリケーションＣのアプリケーションＵＲＬがテーブル記憶部１４のテーブルに記憶されているか否かを検索する。実施例４では、テーブル記憶部１４にはアプリケーションＣのアプリケーションＵＲＬが記憶されている。従って、端末内ＵＲＬ設定部１３は、テーブルから端末内ＵＲＬを取得する。アプリケーションＣの端末内ＵＲＬは"http://localhost:10002/app"とする。

図１３は、実施例４のシーケンス図を示している。図１３のシーケンス図は、図１０に示したシーケンス図のステップＳ３２の部分が異なる。リクエストフック部１９は、実行部４が出力する端末内ＵＲＬの要求を監視している。そして、リクエストフック部１９は、実行部４からアプリケーションＣの端末内ＵＲＬ"http://localhost:10002/app"の要求が出力されたときに、当該要求を取得する（ステップＳ３６）。

そして、リクエストフック部１９は、出力された端末内ＵＲＬの要求に対応して、端末内ＵＲＬ"http://localhost:10002/app"に対応するアプリケーションＣを実行部４に出力する。これにより、実行部４はアプリケーションＣを実行することができる。

新たに取得したアプリケーションＣは、従前に使用していたアプリケーションＣと同じオリジンを持つ端末内ＵＲＬを使用する。従って、新たに取得したアプリケーションＣは、従前に使用していたローカルストレージ１５Ｃを使用することができ、パラメータ等の情報を継続的に使用することができる。

図１４および図１５を用いて、実施例５について説明する。図１４は実施例５の構成の一例を示す。図１４は図１の構成にストレージコピー部３０が追加されている。ストレージコピー部３０はコピー部の一例である。

図１４に示すように、外部サーバ２はアプリケーションを保持している。ブラウザで実行されるＷｅｂアプリケーションは、通信端末１にアプリケーションを取得（ダウンロード）して実行することができる。この実行方式を第１の実行方式と称することもある。

また、アプリケーションは外部サーバ２に設置し、通信端末１が外部サーバ２と通信することにより、ブラウザでアプリケーションを実行することもできる。この実行方式を第２の実行方式と称することもある。

通信端末１の実行部４は、第１の実行方式と第２の実行方式との何れの実行方式でも、アプリケーションを利用することができる。第１の実行方式では、通信端末１がアプリケーションを取得するため、外部サーバ２と頻繁に通信を行うことはない。

第２の実行方式では、通信端末１は外部サーバ２が保持するアプリケーションと通信を行うため、頻繁に通信が発生する。従って、外部サーバ２が保持するアプリケーションの最新情報を取得することができる。

上述してきたように、アプリケーション使用領域部５は、オリジンごとに使用する領域が異なる。このため、端末内ＵＲＬ設定部１３が、既存の端末内ＵＲＬと異なる端末内ＵＲＬを設定している。

第１の実行方式と第２の実行方式とでは、アプリケーション（アプリケーションＡとする）のオリジンが異なる。第１の実行方式では、アプリケーションＡは通信端末１に取得されるため、アプリケーションＡのオリジンは端末内ＵＲＬとなる。第２の実行方式では、アプリケーションＡは外部の外部サーバ２に設置されている。このため、アプリケーションＡのオリジンは外部サーバ２が保持するアプリケーションＡのオリジンとなる。

従って、同じアプリケーションＡであったとしても、第１の実行方式と第２の実行方式とでは、オリジンが異なる。このため、図１５に示すように、同じアプリケーションＡは異なるローカルストレージを使用する。

ローカルストレージ１５Ａは、第２の実行方式のときに使用されるローカルストレージである。オリジンは、端末内ＵＲＬではなく、アプリケーションＵＲＬである"http://app.example.com/app"に含まれる"http://app.example.com/"を示している。

一方、ローカルストレージ１５Ｂは、第１の実行方式のときに使用されるローカルストレージである。オリジンは、端末内ＵＲＬ"http://localhost:10002/app"に含まれる"http://localhost:10002/"を示している。このため、アプリケーションＡが使用するパラメータ等の情報の整合性を取ることができない。

図１４に一例として示すストレージコピー部３０は、同一のアプリケーションＡが使用する２つのローカルストレージの整合性を取るため、ローカルストレージの内容のコピーを行う。つまり、ストレージコピー部３０は、アプリケーション使用領域部５の領域の情報をコピーする。

ストレージコピー部３０がコピーを行うタイミングとしては、第１の実行方式から第２の実行方式に切り替えるタイミングがある。この場合、実行部４が要求するオリジンは、端末内ＵＲＬから外部サーバ２のオリジンに切り替わる。このタイミングで、ストレージコピー部３０はコピーを行うようにしてもよい。

また、ストレージコピー部３０がコピーを行うタイミングとしては、第２の実行方式から第１の実行方式に切り替えるタイミングがある。この場合、実行部が要求するオリジンは、外部サーバ２から端末内ＵＲＬに切り替わる。このタイミングで、ストレージコピー部３０はコピーを行うようにしてもよい。

ストレージコピー部３０は、ローカルストレージの全ての情報をコピーしてもよい。ただし、ローカルストレージの情報のうち現在から所定時間前までに更新された情報だけをコピーしてもよい。これにより、全ての情報をコピーする場合と比較して、コピーする情報量を少なくすることができる。

また、ストレージコピー部３０は、ローカルストレージ１５Ａとローカルストレージ１５Ｂとの情報を比較して、異なる情報をコピーするようにしてもよい。これにより、全ての情報をコピーする場合と比較して、コピーする情報量を少なくすることができる。

ストレージコピー部３０は、ローカルストレージの情報のコピーを行う。ただし、ローカルストレージの情報だけでなく、他の情報をコピーしてもよい。他の情報の一例としては、Cookie等の情報がある。

また、通信端末１の電波状況が良好なときには、第２の実行方式を使用し、電波状況が良好でないときには、第１の実行方式を使用することもできる。この場合には、通信端末１の電波状況に応じて、通信端末１が自律的に実行方式を切り替える。そして、実行方式を切り替えたときに、ストレージコピー部３０は情報のコピーを行うことができる。

従って、ストレージコピー部３０は、同一のアプリケーションに対して異なるオリジンが付与されている場合には、オリジンごとに設定されるローカルストレージの内容が同一になるようにコピーを行う。

開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。

以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
通信端末であって、
アプリケーションを取得する取得部と、
前記取得部が取得したアプリケーションごとに前記通信端末の内部で使用されるオリジンを含む情報を記憶する記憶部と、
前記記憶部に記憶されていないオリジンのアプリケーションを前記取得部が取得したときに、前記取得部が取得したアプリケーションに対して前記記憶部が記憶している前記オリジンを含む情報と異なるオリジンを含む情報を設定する設定部と
前記アプリケーションを実行する実行部と、
前記実行部が要求したオリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力する処理部と、
を備える通信端末。
（付記２）
前記取得部が取得したアプリケーションのオリジンを含む情報が前記記憶部に記憶されているときに、前記処理部は前記記憶部に記憶されているオリジンを含む情報を使用する、
付記１記載の通信端末。
（付記３）
前記処理部は、前記オリジンを含む情報ごとに設定された端末内サーバを備え、
前記実行部が要求したオリジンを含む情報に対応する端末内サーバは、前記実行部が要求したオリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力する、
付記１記載の通信端末。
（付記４）
前記処理部は、前記実行部の要求を監視し、前記実行部が前記オリジンを含む情報を要求したときに、前記オリジンを含む情報を取得して、前記オリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力するリクエストフック部、
を備える付記１記載の通信端末。
（付記５）
前記設定部が前記オリジンを含む情報を設定したときに、前記実行部に対して、前記オリジンを含む情報に関連付けられたアプリケーションを読み出すように要求する要求部、
を備える付記１記載の通信端末。
（付記６）
前記オリジンを含む情報ごとに前記アプリケーションが使用する領域が設定され、１つの前記アプリケーションに同一の前記オリジンを含む情報が付与されているときには、前記領域の情報のコピーを行うコピー部、
を備える付記１記載の通信端末。
（付記７）
前記コピー部は、前記通信端末に保存されているアプリケーションを実行する第１の実行方式と外部のサーバに設置されているアプリケーション通信することにより前記アプリケーションを実行する第２の実行方式とを切り替えるときに、前記領域の情報のコピーを行う、
付記６記載の通信端末。
（付記８）
前記コピー部は、前記通信端末の電波状況に応じて、前記第１の実行方式と前記第２の実行方式とを切り替える、
付記７記載の通信端末。
（付記９）
前記アプリケーションは、ＨＴＭＬ５アプリケーションである、
付記１記載の通信端末。
（付記１０）
前記オリジンは、プロトコルとドメインとポート番号とを有し、
前記設定部は、前記ドメインと前記ポート番号との少なくとも一方を設定する、
付記１記載の通信端末。
（付記１１）
通信端末にアプリケーションを取得させ、
前記通信端末が前記アプリケーションを取得したときに、前記アプリケーションのオリジンを含む情報が記憶されているか否かを検索し、
前記オリジンを含む情報が記憶されていないときには、前記通信端末の内部で使用されるオリジンを含む情報を既に記憶されているオリジンを含む情報と異なるように設定する、
通信処理方法。
（付記１２）
通信端末にアプリケーションを取得させ、
前記通信端末が前記アプリケーションを取得したときに、前記アプリケーションのオリジンを含む情報が記憶されているか否かを検索し、
前記オリジンを含む情報が記憶されていないときには、前記通信端末の内部で使用されるオリジンを含む情報を既に記憶されているオリジンを含む情報と異なるように設定する、
処理をコンピュータに実行させる通信処理プログラム。
（付記１３）
プロセッサと記憶装置とを備える通信端末であって、
前記プロセッサは、
前記通信端末が前記アプリケーションを取得したときに、前記アプリケーションのオリジンを含む情報が記憶されているか否かを検索し、
前記オリジンを含む情報が記憶されていないときには、前記通信端末の内部で使用されるオリジンを含む情報を既に記憶されているオリジンを含む情報と異なるように設定する、
通信端末。

１ 通信端末
２ 外部サーバ
３ 制御部
４ 実行部
５ アプリケーション使用領域部
６ 表示部
１０ 通信部
１１ アプリケーション取得部
１２ アプリケーション保存部
１３ 端末内ＵＲＬ設定部
１４ リクエスト処理部
１６ リクエスト処理部
１７ ロード要求部
１８ 端末内Ｗｅｂサーバ
１９ リクエストフック部
２１ バス
２２ プロセッサ
２３ ＲＡＭ
２４ ＲＯＭ
２５ 補助記憶装置
２６ 通信インタフェース
２７ 可搬型記憶装置接続部
３０ ストレージコピー部

Claims (8)

1. 通信端末であって、
   アプリケーションを取得する取得部と、
   前記取得部が取得したアプリケーションごとに前記通信端末の内部で使用されるオリジンを含む情報を記憶する記憶部と、
   前記記憶部に記憶されていないオリジンのアプリケーションを前記取得部が取得したときに、前記取得部が取得したアプリケーションに対して前記記憶部が記憶している前記オリジンを含む情報と異なるオリジンを含む情報を設定する設定部と
   前記アプリケーションを実行する実行部と、
   前記実行部が要求したオリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力する処理部と、
   を備える通信端末。
2. 前記取得部が取得したアプリケーションのオリジンを含む情報が前記記憶部に記憶されているときに、前記処理部は前記記憶部に記憶されているオリジンを含む情報を使用する、
   請求項１記載の通信端末。
3. 前記処理部は、前記オリジンを含む情報ごとに設定された端末内サーバを備え、
   前記実行部が要求したオリジンを含む情報に対応する端末内サーバは、前記実行部が要求したオリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力する、
   請求項１または２記載の通信端末。
4. 前記処理部は、前記実行部の要求を監視し、前記実行部が前記オリジンを含む情報を要求したときに、前記オリジンを含む情報を取得して、前記オリジンを含む情報に関連付けられたアプリケーションを前記実行部に出力するリクエストフック部、
   を備える請求項１または２記載の通信端末。
5. 前記設定部が前記オリジンを含む情報を設定したときに、前記実行部に対して、前記オリジンを含む情報に関連付けられたアプリケーションを読み出すように要求する要求部、
   を備える請求項１乃至４のうち何れか１項に記載の通信端末。
6. 前記オリジンを含む情報ごとに前記アプリケーションが使用する領域が設定され、１つの前記アプリケーションに同一の前記オリジンを含む情報が付与されているときには、前記領域の情報のコピーを行うコピー部、
   を備える請求項１乃至５のうち何れか１項に記載の通信端末。
7. 通信端末にアプリケーションを取得させ、
   前記通信端末が前記アプリケーションを取得したときに、前記アプリケーションのオリジンを含む情報が記憶されているか否かを検索し、
   前記オリジンを含む情報が記憶されていないときには、前記通信端末の内部で使用されるオリジンを含む情報を既に記憶されているオリジンを含む情報と異なるように設定する、
   通信処理方法。
8. 通信端末にアプリケーションを取得させ、
   前記通信端末が前記アプリケーションを取得したときに、前記アプリケーションのオリジンを含む情報が記憶されているか否かを検索し、
   前記オリジンを含む情報が記憶されていないときには、前記通信端末の内部で使用されるオリジンを含む情報を既に記憶されているオリジンを含む情報と異なるように設定する、
   処理をコンピュータに実行させる通信処理プログラム。

Images