(57)【要約】【課題】本発明は、実行可能なウェブコンテンツを端末に提供するシステムであって、宣言的言語からなる宣言的言語部及び非宣言的部分を含む実行可能なウェブコンテンツを提供するサーバと、前記実行可能なウェブコンテンツを前記サーバから転送を受けて前記端末のウェブブラウザで実行できる形態に変換して前記端末に転送するゲートウェイを含むシステムを提供する。【選択図】図１
2008527564.tif 000002
【特許請求の範囲】
【請求項１】
実行可能なウェブコンテンツを端末に提供するシステムにおいて、
宣言的な言語からなる宣言的言語部及び非宣言的部分を含む実行可能なウェブコンテンツを提供するサーバと、
前記実行可能なウェブコンテンツを前記サーバから転送を受け、前記端末のウェブブラウザで実行できる形態に変換し、前記端末に転送するゲートウェイと
を備えるシステム。
【請求項２】
前記端末は、無線通信端末であり、前記ウェブコンテンツは、無線ウェブコンテンツである請求項１記載のシステム。
【請求項３】
前記ウェブサーバと前記ゲートウェイは、有線ネットワークにより連結され、前記ゲートウェイは、無線ネットワークを介して端末に連結される請求項１記載のシステム。
【請求項４】
前記端末は、無線ウェブブラウザを備え、
前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、
前記ウェブコンテンツは、１つ以上のファイルを含み、
前記サーバへのウェブコンテンツの要請は、前記１つ以上のファイルの要請を含み、
前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つ以上のファイルを一回のトランザクションで端末に転送する請求項３記載のシステム。
【請求項５】
前記ウェブコンテンツを構成する１つ以上のファイルは、ウェブコンテンツファイルと少なくとも１つのリソースファイルを含み、
前記ウェブコンテンツの要請は、ウェブコンテンツファイルの要請と、前記少なくとも１つのリソースファイルの要請を含む請求項４記載のシステム。
【請求項６】
前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうちの１つ以上を含む請求項１記載のシステム。
【請求項７】
前記非宣言的部分は、手続的コードを含み、
前記ゲートウェイは、宣言的言語部を手続的コードに変換する手段と、手続的コードをコンパイルして実行可能なファイルに変換する手段を備える請求項１記載のシステム。
【請求項８】
前記非宣言的部分は、手続的コードを含み、前記ゲートウェイは、宣言的言語部をコンパイルする手段と、手続的コードをコンパイルする手段と、前記宣言的言語部をコンパイルした結果と、手続的コードをコンパイルした結果をマージ（ｍｅｒｇｅ）して実行可能なファイルを生成する手段を備える請求項１記載のシステム。
【請求項９】
前記ゲートウェイは、端末のウェブブラウザで実行できる形態に変換されたウェブコンテンツ内にセキュリティポリシーに違反する機能が含まれているかを検出する手段を備える請求項１記載のシステム。
【請求項１０】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含められている場合、該当ファイルを端末に転送しないことを特徴とする請求項９記載のシステム。
【請求項１１】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含められている場合、該当ファイルを端末に転送するに先立って端末ユーザーの許諾を受けることを特徴とする請求項９記載のシステム。
【請求項１２】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含められている場合、該当ファイルに、ランタイム時に所定の動作を行うようにするコードを挿入し、
前記所定の動作は、システムの既に設定されたセキュリティポリシーによって決定されることを特徴とする請求項９記載のシステム。
【請求項１３】
実行可能なウェブコンテンツを端末に提供するシステムにおいて、
実行可能なウェブコンテンツを提供するサーバと、
前記実行可能なウェブコンテンツを前記サーバから転送を受け、前記端末のウェブブラウザで実行できる形態に変換して前記端末に転送するゲートウェイと
を備え、前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうちの１つ以上を含み、
前記ゲートウェイは、宣言的言語及び手続的コードをコンパイルするシステム。
【請求項１４】
前記手続的コードのソースコードは、ジャバコードを含み、前記実行可能な二進ファイルはｊａｒファイルを含むことを特徴とする請求項６または請求項１３に記載のシステム。
【請求項１５】
実行可能なウェブコンテンツをサーバから受け、端末のウェブブラウザで実行できる形態に変換するゲートウェイであって、前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうちの１つ以上を含み、
前記ゲートウェイは、宣言的言語及び手続的コードをコンパイルして実行可能なファイルに変換する手段を備えるゲートウェイ。
【請求項１６】
前記端末は、無線通信端末であり、前記ウェブコンテンツは、無線ウェブコンテンツである請求項１５記載のゲートウェイ。
【請求項１７】
前記ゲートウェイは、有線ネットワークによって前記サーバと通信し、前記ゲートウェイは、無線ネットワークを介して端末と通信することを特徴とする請求項１５記載のゲートウェイ。
【請求項１８】
前記端末は、無線ウェブブラウザを備え、
前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、
前記ウェブコンテンツは、１つ以上のファイルを含み、
前記サーバへのウェブコンテンツの要請は、前記１つ以上のファイルの要請を含み、
前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つ以上のファイルを一回のトランザクションで端末に転送することを特徴とする請求項１７記載のゲートウェイ。
【請求項１９】
前記ウェブコンテンツを構成する１つ以上のファイルは、ウェブコンテンツ本文とリソースファイルを含み、
前記ウェブコンテンツの要請は、ウェブコンテンツの本文の要請と、リソースファイルの要請とを含む請求項１８記載のゲートウェイ。
【請求項２０】
前記手続的コードのソースコードは、ジャバコードを含み、前記実行可能な二進ファイルは、ｊａｒファイルを含む請求項１５記載のゲートウェイ。
【請求項２１】
宣言的言語部を手続的コードに変換させる変換部と、
手続的コードをコンパイルするコンパイラと、
ウェブサーバから受けた実行可能な二進ファイルを分析し、追加の外部ファイルを参照する場合、前記外部ファイルを取り込む処理部と、
ウェブサーバから受けたウェブコンテンツに、セキュリティに問題になる機能が含まれているかを決定するセキュリティ管理部と
を備える請求項１５記載のゲートウェイ。
【請求項２２】
端末のウェブブラウザで実行できる形態に変換されたウェブコンテンツ内にセキュリティポリシーに違反する機能が含まれているかを検出する手段を備える請求項１５記載のゲートウェイ。
【請求項２３】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルを端末に転送しないことを特徴とする請求項２２記載のゲートウェイ。
【請求項２４】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルを端末に転送するに先立って端末ユーザーの許諾を受けることを特徴とする請求項２２記載のゲートウェイ。
【請求項２５】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルに、ランタイム時に所定の動作を行うようにするコードを挿入し、
前記所定の動作は、システムの既に設定されたセキュリティポリシーによって決定されることを特徴とする請求項２２記載のゲートウェイ。
【請求項２６】
前記端末は、無線ウェブブラウザを備え、
前記ウェブコンテンツは、１つまたはそれ以上のファイルを含み、
前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、
前記所定のウェブコンテンツの要請は、ウェブコンテンツのうちブラウザに既にキャッシングされているファイルの名称及び最終変更時間の情報を含み、
前記ゲートウェイは、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、
前記サーバへのウェブコンテンツの要請は、前記１つまたはそれ以上のファイルの要請を含み、
前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つまたはそれ以上のファイルを受信し、前記キャッシングされているファイルの名称及び最終変更時間の情報と比較してキャッシングされたファイルから変更されたり新たに追加されたファイルのみを端末に転送することを特徴とする請求項１７記載のゲートウェイ。
【請求項２７】
実行可能なウェブコンテンツをブラウジングするためのウェブブラウザを格納するコンピュータ格納媒体であって、前記ウェブブラウザは、バイナリ実行コード形態のウェブコンテンツを受信して実行することを特徴とする格納媒体。
【請求項２８】
実行可能なウェブコンテンツをブラウジングするためのウェブブラウザを備える端末であって、前記ウェブブラウザは、バイナリ実行コード形態のウェブコンテンツを受信して実行することを特徴とする端末。
【請求項２９】
前記ウェブコンテンツは、１つ以上のファイルを含み、前記１つ以上のファイルは、他のファイルで参照される共有リソースファイルを含み、
前記端末は、キャッシュを含み、
前記共有リソースファイルが前記キャッシュにキャッシングされるとき、前記共有リソースファイルが如何に多くの他のファイルで参照されるかを示す参照回数が共に格納されることを特徴とする請求項２８記載の端末。
【請求項３０】
前記端末が前記キャッシングされた共有リソースファイルのキャッシングされたバージョンよりも新たなバージョンのファイルを含むウェブコンテンツの転送を受けた場合、前記新たなバージョンの共有リソースファイルをキャッシュに格納し、前記既に格納された共有リソースファイルの参照回数を１減少することを特徴とする請求項２９記載の端末。
【請求項３１】
前記減少後に参照回数が０であれば、前記既に格納された共有リソースファイルを削除することを特徴とする請求項３０記載の端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、携帯電話などデータ通信のためのネットワーク接続が可能な携帯用端末において、多様なコンテンツ及びサービスを提供することができる方法及びシステムを提供するためのものである。より具体的には、ウェブ方式及びダウンロードアプリケーション方式の技術的特徴と長所を提供することができる無線インターネットプラットフォームを提供するためのものである。
【背景技術】
【０００２】
従来は、携帯用端末でインターネットを用いるためにＷＡＰ（Ｗｉｒｅｌｅｓｓ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）ブラウザに代表される無線インターネット専用のブラウザが用いられた。ＷＡＰブラウザの複数のバージョンのうち、１.ｘバージョンと２.ｘバージョンは、動作する方式が大きく異なっている。ＷＡＰ  １.ｘバージョンでは、ＷＭＬ（Ｗｉｒｅｌｅｓｓ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）とＷＭＬＳｃｒｉｐｔという固有のコンテンツ形式を用いる。即ち、有線インターネットのマークアップ言語であるＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）に該当するＷＭＬを用い、簡単なコードを端末で実行するためには、有線インターネットのジャバスクリプト（ＪａｖａＳｃｒｉｐｔ（登録商標））に該当するＷＭＬＳｃｒｉｐｔを用いる。このような形式で表現されたコンテンツは、まず有線ネットワークを介してＷＡＰゲートウェイに伝達され、ゲートウェイでよりコンパクトかつ効率的なバイナリ形式（「ＷＢＸＭＬ」と称する）に変換された後、無線ネットワークを介して転送される。
【０００３】
一方、ＷＡＰ  ２.ｘバージョンは、有線インターネットのＨＴＭＬ標準に、より近いＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ  ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）Ｍｏｂｉｌｅ  Ｐｒｏｆｉｌｅ（ＸＨＴＭＬＭＰ）マークアップ言語を用い、ジャバスクリプトと類似のエクマスクリプト（ＥＣＭＡＳｃｒｉｐｔ）が間もなく導入されると見通されている。
【０００４】
有無線に関係なくブラウザは、基本的に語彙が制限され、宣言的な文法を有するマークアップ言語をコンテンツ形式で用いるため、表現形式の自由度が高いコンテンツを作り難い。このような制約を克服するために、次のような技術が既に導入され、若しくは導入される予定である。
【０００５】
スクリプト：ジャバスクリプトに代表されるスクリプトは、テキスト形式になっているプログラムコードをウェブサーバに載せておけば、テキスト形式そのままでブラウザに転送されるか、あるいはＷＡＰの場合、ゲートウェイでバイトコードに変換されてブラウザに転送される。スクリプトは、マークアップ言語に比べて相対的に強力な機能を有するプログラミング言語であって、ＨＴＭＬ、ＷＭＬなど宣言的文法形式では具現が不可能な機能を端末で具現するために用いられる。
【０００６】
アプレット（Ａｐｐｌｅｔ）：サン・マイクロシステムズ社で開発したジャバアプレット（Ｊａｖａ（登録商標）  Ａｐｐｌｅｔ）は、ジャバ言語で作成された小さなプログラムである。このようなアプレットを予めコンパイルしてウェブサーバに載せておけば、ブラウザがこれをダウンロードし、ブラウザ内のジャバ仮想マシンを用いて実行し、その結果を他のコンテンツと共に画面に示す。
【０００７】
プラグイン（Ｐｌｕｇ−ｉｎ）：例えば、マイクロソフト社のウィンドウズ（登録商標）のアクティブエックス（ＡｃｔｉｖｅＸ）プラグインは、端末プラットフォームに固有の固有コードとして作られ、大体ＤＬＬ（Ｄｙｎａｍｉｃ  Ｌｏａｄ  Ｌｉｂｒａｒｙ）形式を有する。ブラウザによりダウンロードされた後、動的にロードされて実行され、端末プラットフォームが提供する全てのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を用いることができ、強力かつ多様な機能を提供できるが、それに対し、ポインタ演算が可能であり、プログラムの機能を予め検査し難いなどの理由で、ウイルスや悪性ソフトウェア（ｍａｌｗａｒｅ）などがクライアントコンピュータで実行されることを防止し難いという短所を有する。
【０００８】
ＨＴＭＬ系列のマークアップ言語は、本来単純なテキストのディスプレイを主目的として作ったものであって、これに伴う基本的な限界を有している。このようなマークアップ言語の限界を克服するために、前述したような技術がＨＴＭＬあるいはＷＭＬを主言語とするコンテンツに補助的に導入されており、これらはそれぞれ互いに異なる長短所を有するため、最近のＰＣ用ブラウザでは、前記技術を全てサポートしている。従って、ブラウザの構造が複雑になり、サイズも大きくなり、前記のような技術を用いるにおいてセキュリティ問題が発生することがあり、また、ブラウザが不安定になる可能性がある。携帯電話のように相対的にＰＣなどに比べてコンピュータパワーが弱く、メモリなどのリソースが不足した携帯用端末においても、益々多様なブラウザの機能が要求されており、従って、ＰＣ用ブラウザと類似の機能が漸進的に導入されている。しかし、携帯電話においては、ＰＣに比べてブラウザのサイズと複雑度、不安定性の問題がより大きな制約として作用する。
【０００９】
ＰＣの場合、前述したブラウザ及びマークアップ言語の限界と短所を克服するために、従来のＨＴＭＬと全く異なる方式の技術が提案されている。ロングｈｏｒｎ（Ｌｏｎｇｈｏｒｎ，ビスタと呼ばれる）というコード名のオペレーションシステムには、「ＸＡＭＬ（ｅｘｔｅｎｓｉｂｌｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）」と呼ばれる新たなマークアップ形式をサポートするブラウザが搭載される予定である。「ＸＡＭＬ」は、「Ｃ＃」プログラミング言語コードとなっている部分をその一部として含むことができ、マイクロソフトドットネット（.ＮＥＴ）フレームワークのＣＬＲ（Ｃｏｍｍｏｎ  Ｌａｎｇｕａｇｅ  Ｒｕｎｔｉｍｅ）で実行可能な媒介言語（ＩＬ：Ｉｎｔｅｒｍｅｄｉａｔｅ  Ｌａｎｇｕａｇｅ）バイトコードに変換されてから実行される。このような変換は、予めオフラインで行われ、バイトコードを直接サーバからブラウザに転送することもでき、またはテキスト形態でブラウザに転送されたコンテンツがブラウザ内でバイトコードに変換されて実行されることもできる。いずれにせよプログラミング言語（Ｃ＃など）と宣言的マークアップ言語（ＸＡＭＬ）で作成されたコンテンツは、最終的に直接実行が可能な媒介言語（ＩＬ）バイトコードに変換され、ブラウザにより動的にローディングされて実行される。このような技術を用いれば、マークアップ言語が有する長所、即ち、コンパクトかつ易しい表現形式及び既存のウェブ開発方式との互換性を維持しながらも汎用プログラミング言語の長所（多様な機能とユーザーインターフェースの提供）を必要に応じて受容することができる。従って、現在ＨＴＭＬ及び付加言語（スクリプト、プラグインなど）により作られるウェブサイトに比べて、はるかに強力かつ便利なユーザーインターフェースを提供することができると予想される。しかし、このような技術は、強力なＣＰＵと大容量のメモリを有するＰＣを対象として開発される技術であって、演算力が小さく、メモリ容量も少ない携帯電話のような携帯用端末に具現されるには適していない。
【００１０】
一方、有線インターネットの場合、ウイルスや個人情報の流出防止のために、ユーザーがダウンロードするコンテンツやプログラムに対して所定のセキュリティ装置が必要であり、幅広く具現されている。無線ネットワークは、有線ネットワークに比べて通信費用が高価で、ユーザーが通信量に応じて使用料を負担する場合が多いので、もしユーザーがダウンロードしたコンテンツがユーザーの知らない内に所期の動作を行う場合、ユーザーが所望しない通信費用が発生し得る。従って、即ち、有線インターネットの場合のウイルス配布や、個人情報流出などの問題に加えてユーザーに直接的な金銭的被害を与えることがある。
【００１１】
セキュリティ機能の必要性及び従来の具現方法をより具体的に詳察すれば、ジャバアプレット、アクティブａｘｅなどのように、ネットワークからダウンロードされたコードを直接実行する際には、このコードがどんなことをするのか端末側で予め分かりにくいため、セキュリティ機能が必要である。一般のバイナリコードをダウンロードして実行する場合、即ち、ＡｃｔｉｖｅＸのようなネイティブコード（ＣＰＵが直接行うコード）の場合は、そのコードがどんなことを行うのか端末側で予め検査したりランタイムに特定のセキュリティポリシーを強制することができない。従って、ウイルスや悪性ソフトウェアが端末側で行われることを防止するために、このコードをダウンロードする際に認証を受けるようにする手続を経るようにすることができる。
【００１２】
一方、ジャバの代表的なエディションである「Ｊａｖａ（登録商標）  ２  Ｓｔａｎｄａｒｄ  Ｅｄｉｔｉｏｎ（Ｊ２ＳＥ）」には、最初からネットワークを介してコードをダウンロードすることを前提として規格が作られたため、ＡｃｔｉｖｅＸの場合よりも精巧なセキュリティ機能を有しているが、この機能は、主にコードがどのサーバからダウンロードされたのかによって、該当コードの実行時に、許容される機能が制限される方式をとる。
【００１３】
モバイル装置のためのジャバ（Ｊａｖａ（登録商標）  ２  Ｍｏｂｉｌｅ  Ｅｄｉｔｉｏｎ，  Ｊ２ＭＥ）、特にこの中でも携帯電話のようにメモリとプロセシングパワーが制約された装置のためのコンフィギュレーション、即ち、ＣＬＤＣ（Ｃｏｎｎｅｃｔｅｄ  Ｌｉｍｉｔｅｄ  Ｄｅｖｉｃｅ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）の仮想マシン（ＶＭ）とランタイムライブラリは、メモリ使用量を減らし、実行速度を向上させるために、前述したＪ２ＳＥと比較すれば、さらに簡単なセキュリティ機能を有している。ＭＩＤＰ  １.ｘバージョンでは、認証を受けたアプリケーションなのか否かによって敏感な機能への接近を許容または遮断する簡単な区分のみ可能である。最近定義されたＭＩＤＰ  ２.０バージョンの規格では、機能別に許否のポリシーを設定することができる。
【００１４】
従来のモバイル用ジャバのセキュリティメカニズムは、いずれも１つのアプリケーションが１つのサーバからダウンロードされることを仮定し、このサーバの住所によってセキュリティポリシーが選択されて適用され、このポリシーは、そのアプリケーションと仮想マシンが終了するまで変更できないという限界点を有する。従って、１つのウェブコンテンツのアプリケーションを構成するコードが複数のサーバからダウンロードされ得る場合は、前述したような既存のジャバのセキュリティメカニズムを用いては適切なセキュリティ機能を具現することができない。また、その他の面においても、十分に場合に応じて多様に適用できる精巧なセキュリティ機能を提供することができなかった。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明の目的は、実行可能なウェブコンテンツを提供するための新たなウェブプラットフォームに関するものであって、具体的には携帯用端末の低いプロセシング速度とメモリの限界を克服し、豊富かつ多様な機能及び形態を有するコンテンツを無線ネットワークを介して提供し、端末で実行できるようにする方法及びシステムを提供することにある。
【００１６】
本発明の他の目的は、無線ネットワークを介して転送される無線コンテンツ及びこれを実行するための端末のセキュリティ機能を強化し、精巧にする方法及びシステムを提供することにある。
【００１７】
本発明のその他の目的は、無線ネックワークを介したウェブコンテンツ転送の効率性を改善する方法及びシステムを提供することにある。
【００１８】
本発明のその他の目的は、無線ウェブコンテンツをキャッシングするにおいて、キャッシュの一貫性を具現するための方法及びシステムを提供することにある。
【課題を解決するための手段】
【００１９】
前記目的を達成するために、本発明の一面によれば、実行可能なウェブコンテンツを端末に提供するシステムであって、
宣言的言語となっている宣言的言語部及び非宣言的部分を含む実行可能なウェブコンテンツを提供するサーバと、
前記実行可能なウェブコンテンツを前記サーバから転送を受け、前記端末のウェブブラウザで実行できる形態に変換し、前記端末に転送するゲートウェイを備えるシステムを提供する。
【００２０】
前記端末は、無線通信端末であり、前記ウェブコンテンツは、無線ウェブコンテンツである。
【００２１】
前記ウェブサーバと前記ゲートウェイは、有線ネットワークによって連結され、前記ゲートウェイは、無線ネットワークを介して端末に連結される。
【００２２】
前記端末は、無線ウェブブラウザを備え、
前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、
前記ウェブコンテンツは、１つ以上のファイルを含み、
前記サーバへのウェブコンテンツの要請は、前記１つ以上のファイルの要請を含み、
前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つ以上のファイルを一回のトランザクションで端末に転送する。
【００２３】
前記ウェブコンテンツを構成する１つ以上のファイルは、ウェブコンテンツファイルと少なくとも１つのリソースファイルを含み、
前記ウェブコンテンツの要請は、ウェブコンテンツファイルの要請と、少なくとも１つのリソースファイルの要請を含む。
【００２４】
前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうち１つ以上を含む。
【００２５】
前記非宣言的部分は、手続的コードを含み、
前記ゲートウェイは、宣言的言語部を手続的コードに変換する手段と、手続的コードをコンパイルして実行可能なファイルに変換する手段を備えることができる。
【００２６】
前記非宣言的部分は、手続的コードを含み、前記ゲートウェイは、宣言的言語部をコンパイルする手段と、手続的コードをコンパイルする手段と、前記宣言的言語部をコンパイルした結果と、手続的コードをコンパイルした結果をマージして実行可能なファイルを生成する手段とを備えることができる。
【００２７】
前記ゲートウェイは、端末のウェブブラウザで実行できる形態に変換されたウェブコンテンツ内にセキュリティポリシーに違反する機能が含まれているかを検出する手段を備える。
【００２８】
前記検出手段は、ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルを端末に転送しないか、該当ファイルを端末に転送するに先立って端末ユーザーの許諾を受けるか、該当ファイルに、ランタイム時に、システムの既に設定されたセキュリティポリシーによって決定される所定の動作を行うようにするコードを挿入する。
【００２９】
本発明の他の一面によれば、実行可能なウェブコンテンツを端末に提供するシステムであって、
実行可能なウェブコンテンツを提供するサーバと、
前記実行可能なウェブコンテンツを前記サーバから転送を受け、前記端末のウェブブラウザで実行できる形態に変換し、前記端末に転送するゲートウェイを備え、前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうち１つ以上を含み、
前記ゲートウェイは、宣言的言語及び手続的コードをコンパイルして実行可能なファイルに変換する手段を備えるシステムを提供する。
【００３０】
前記手続的コードのソースコードは、ジャバコードを含み、前記実行可能な二進ファイルは、ｊａｒファイルを含むことができる。
【００３１】
本発明の他の一面によれば、実行可能なウェブコンテンツをサーバから受け、端末のウェブブラウザで実行できる形態に変換するゲートウェイであって、前記ウェブコンテンツは、静的ファイル、動的に生成されるファイル、手続的コードのソースコード、実行可能な二進ファイル、マルチメディアファイルのうち１つ以上を含み、宣言的言語及び手続的コードをコンパイルして実行可能なファイルに変換する手段を備えるゲートウェイを提供する。
【００３２】
前記ゲートウェイは、有線ネットワークによって前記サーバと通信し、前記ゲートウェイは、無線ネットワークを介して端末と通信する。
【００３３】
前記端末は、無線ウェブブラウザを備え、前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、前記ウェブコンテンツは、１つ以上のファイルを含み、前記サーバへのウェブコンテンツの要請は、前記１つ以上のファイルの要請を含み、前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つ以上のファイルを一回のトランザクションで端末に転送する。
【００３４】
前記ウェブコンテンツを構成する１つ以上のファイルは、ウェブコンテンツ本文とリソースファイルを含み、前記ウェブコンテンツの要請は、ウェブコンテンツの本文の要請と、リソースファイルの要請を含む。
【００３５】
前記手続的コードのソースコードは、ジャバコードを含み、前記実行可能な二進ファイルはｊａｒファイルを含む。
【００３６】
ゲートウェイは、宣言的言語部を手続的コードに変換させる変換部と、手続的コードをコンパイルするコンパイラとウェブサーバから受けた実行可能な二進ファイルを分析し、追加の外部ファイルを参照する場合、これを取り込む処理部とウェブサーバから受けたウェブコンテンツに、セキュリティに問題になる機能が含まれているかを決定するセキュリティ管理部を備える。
【００３７】
ゲートウェイは、端末のウェブブラウザで実行できる形態に変換されたウェブコンテンツ内にセキュリティポリシーに違反する機能が含まれているかを検出する手段をさらに備える。
【００３８】
ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルを端末に転送しない。
【００３９】
ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルを端末に転送するに先立って端末ユーザーの許諾を受ける。
【００４０】
ウェブコンテンツ内にセキュリティポリシーに違反する機能を有するファイルが含まれている場合、該当ファイルに、ランタイム時に所定の動作を行うようにするコードを挿入し、前記所定の動作は、システムの既に設定されたセキュリティポリシーによって決定される。
【００４１】
前記端末は、無線ウェブブラウザを備え、前記ウェブコンテンツは、１つまたはそれ以上のファイルを含み、前記ゲートウェイは、前記無線ウェブブラウザからの所定のウェブコンテンツの要請を無線ネットワークを介して受信し、前記所定のウェブコンテンツの要請は、ウェブコンテンツのうちブラウザに既にキャッシングされているファイルの名称及び最終変更時間の情報を含み、前記ゲートウェイは、有線ネットワークを介して前記所定のウェブコンテンツを前記サーバに要請し、前記サーバへのウェブコンテンツの要請は、前記１つまたはそれ以上のファイルの要請を含み、前記ゲートウェイは、前記サーバへの要請に従ってサーバから受信した、ウェブコンテンツを構成する１つまたはそれ以上のファイルを受信し、前記キャッシングされているファイルの名称及び最終変更時間の情報と比較してキャッシングされたファイルから変更されたり新たに追加されたファイルのみを端末に転送する。
【００４２】
本発明の他の一面によれば、実行可能なウェブコンテンツをブラウジングするためのウェブブラウザを格納するコンピュータ格納媒体であって、前記ウェブブラウザは、バイナリ実行コード形態のウェブコンテンツを受信して実行することを特徴とする格納媒体が提供される。
【００４３】
本発明の他の一面によれば、実行可能なウェブコンテンツをブラウジングするためのウェブブラウザを備える端末であって、前記ウェブブラウザは、バイナリ実行コード形態のウェブコンテンツを受信して実行することを特徴とする端末が提供される。
【００４４】
前記ウェブコンテンツは、１つ以上のファイルを含み、前記１つ以上のファイルは、他のファイルで参照される共有リソースファイルを含み、前記端末は、キャッシュを含み、前記共有リソースファイルが前記キャッシュにキャッシングされるとき、前記共有リソースファイルが如何に多くの他のファイルで参照されるかを示す参照回数が共に格納される。
【００４５】
前記端末が前記キャッシングされた共有リソースファイルのキャッシングされたバージョンよりも新たなバージョンのファイルを含むウェブコンテンツの転送を受けた場合、前記新たなバージョンの共有リソースファイルをキャッシュに格納し、前記既に格納された共有リソースファイルの参照回数を１減少する。
【００４６】
前記減少後、参照回数が０であれば、前記既に格納された共有リソースファイルを削除する。
【発明の効果】
【００４７】
端末３００で直ちに実行が可能な形態に変換されたウェブコンテンツがゲートウェイ２００から端末３００に転送されるので、処理能力に限界がある端末でもコンテンツの迅速な実行及びディスプレイが可能である。
【００４８】
宣言的文法により生成されるコードと手続的コードが同一のＡＰＩとオブジェクトを用いるので、両者の連動がより直接的かつ効率的である。
【００４９】
端末のブラウザにより制限されることなく、ジャバ仮想マシン（ＪＶＭ）及び端末ライブラリが有する全てのＡＰＩ及び機能を用いることができ、端末ではウェブページファイルをパーシングする過程なしに直ちにコードを実行するだけでよい。
【００５０】
コンテンツを表現するマークアップ言語に新たな文法が追加されなければならないときにも、端末のブラウザに該当機能を追加するなどの変更が必要ではない。
【００５１】
無線区間の通信回数を最小化し、キャッシュの効率的使用によりトラフィック量を低減するなどの方法で通信効率を高めることができる。キャッシュの効率性を維持しながらもキャッシュされたファイルの一貫性を維持し、バージョンの不一致現象を防止することができる。
【発明を実施するための最良の形態】
【００５２】
本発明では、新たな方式のマークアップ言語である実行可能なコンテンツ用マークアップ言語（ＸＣＭＬ：ｅＸｅｃｕｔａｂｌｅ  Ｃｏｎｔｅｎｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を提案し、これを用いてウェブコンテンツを提供する方法及びシステムを提供する。本発明で提案するＸＣＭＬは、既存の無線インターネットコンテンツの標準形式であるＷＭＬあるいはＸＨＴＭＬと同様にＸＭＬを基盤とするマークアップ言語である。即ち、ＸＣＭＬは、ＨＴＭＬやＷＭＬと同様に、宣言的形式を有する宣言的言語部（タグを用いて表現されるという意味で、以下、「タグ部」と称することもある）を主な内容とし、ＨＴＭＬ内にジャバスクリプトが含まれるのと同様に、宣言的文法で表現できない内容（非宣言的部分）は、ジャバスクリプトのような手続的コードにより表現し、テキスト形態でウェブコンテンツファイル内に含むか（「ジャバコード部」）、外部のジャバファイルをファイル内で参照できるようにしたマークアップ言語の形式である。
【００５３】
本発明による、ＸＣＭＬ形式のコンテンツ及びその他のウェブコンテンツを提供するためのネットワークシステムは、図１に示すように、まずウェブサーバ１００と有線ネットワークで連結されたゲートウェイ２００でコンテンツをジャバなどの実行コード（ジャバの場合、一般にジャババイトコードと称する）に変換した後、無線ネットワークを介して端末３００に転送、実行するように構成されている。従って、従来のネックワークシステムがウェブサーバ（サーバ団）とブラウザ（クライアント団）で構成されるのに対し、本発明によるネットワークシステムは、ウェブサーバと、ゲートウェイ及びブラウザ（クライアント）で構成されている。
【００５４】
図１は、このように構成されたネットワークシステムを示すブロック図であり、図２は、図１に示す各構成要素である、ウェブサーバ１００、ゲートウェイ２００、端末３００をそれぞれさらに詳細に示したブロック図である。
【００５５】
以下、図１〜２の各部分について説明する。以下でプログラミング言語としてはジャバを、実行コードとしてジャババイトコードを仮定しているが、本発明は、これに限定されず、類似の性格の他の言語も適用することができる。
【００５６】
図１及び図２でウェブサーバ１００は、ＨＴＴＰプロトコルにより一般のウェブあるいはＷＡＰのコンテンツを提供する一般のウェブサーバであってもよい。ウェブサーバが提供するコンテンツは、静的なテキストやイメージファイルであってもよく、ＣＧＩ（Ｃｏｍｍｏｎ  Ｇａｔｅｗａｙ  Ｉｎｔｅｒｆａｃｅ）やサブレット（Ｓｅｒｖｌｅｔ）などにより動的に生成されるファイルであってもよい。このようなファイルは、本発明によるＸＣＭＬ形式のテキストファイル（図２の１２０、１３０）やジャバソースコードファイル１４０、ｊａｒファイル（１５０、１つ以上のジャバクラスファイル及びその他リソースファイルが１つに合わせられたファイル）、またはイメージ、音楽、動画像ファイル１６０などを含むことができる。ウェブサーバ１００が提供するＸＣＭＬファイルは、多様な実行可能な要素を自由に含むことができ、既存の無線インターネットコンテンツに比べて強力な機能を遂行することができるコンテンツの提供が可能である。本明細書でファイルとは、従来のコンピュータファイルシステムで用いられるファイルの概念のみならず、ネットワークを介して１つの単位で転送されるデータ（プログラムコード、二進ファイルなど含む）の集合を含む概念である。本発明によれば、端末のブラウザが提供する機能に限定されず、無線端末のプラットフォーム（オペレーションシステム）自体で提供される多様な機能を用いるコンテンツの開発及び提供が可能になる。例えば、端末に格納された電話番号情報を用いて所定の動作を行うコンテンツのように、既存のブラウザでは用いることができなかったコンテンツの提供が可能である。
【００５７】
本発明のゲートウェイでは、端末のキャッシュ格納内容の更新要否をウェブサーバと多数（即ち、無線区間である端末−ゲートウェイ間の無線通信よりも多い回数）の通信で確認する。有線区間では、数回のトランザクションが起こってもそれほど時間が要されないが、無線区間では、往復時間が長いため、複数回にわたって情報が分けられて伝達されるようになれば、時間遅延が非常に大きくなるという点を用いるために、無線区間の単位通信（トランザクション）の回数を減らすためである。このような方式によれば、端末のキャッシュの機能を完全に用いながらも、ゲートウェイと端末間（即ち、無線区間）のトラフィックの回数を減らして効率性を高める。このようにキャッシングを用いた通信の効率性向上については、図５〜図８を参照してさらに詳細に説明する。
【００５８】
図２を参照して、ＸＣゲートウェイ２００内の各ブロックの機能を詳細に考察すれば、次の通りである。ＸＣＭＬジャバ変換部２１０は、本発明によるＸＣＭＬ形式からなっているテキストファイルを予め定められた方法でジャバコードに変換する機能を遂行する。この時に生成されるジャバコードは、テキスト形式のジャバソースコードであるか、あるいはソースコードの断片（ｆｒａｇｍｅｎｔ）を含む所定の表現形式のコードであってもよい。前述したように、ＸＣＭＬにはＸＣＭＬ固有のタグからなる部分（既に説明した「タグ部」）とテキスト形態で含まれたジャバコード部がある。ＸＣＭＬタグからなる宣言的部分は、ゲートウェイ２００でジャバコードに変換され、サーバ側１００で最初からジャバで作成された部分（ジャバコード部）と合わせられてコンパイルされ、ジャバクラスをなすようになる。このようにタグ部とジャバコード部を合わせてジャバクラスとしてコンパイルするための方法は様々なものがあるが、その１つは、タグ部をジャバソースコードテキストに変換した後、既存のジャバコード部と結合して１つの完全なジャバプログラムソースを生成した後、これをコンパイルするものである。このような方式でＸＣＭＬジャバ変換部２１０は、ＸＣＭＬテキストファイルのうちタグ部をテキスト形式のジャバソースコードに転換し、既存のジャバコード部と合わせてジャバコンパイラ２２０に伝達する役割をし、ジャバコンパイラ２２０は、ジャバソースコードをコンパイルしてジャバクラスファイルとして作る役割をする。
【００５９】
本発明の他の実施例によれば、タグ部をジャバソースコード形態に変換する代わりに、直ちにジャババイトコードに変換し、本来ジャバコードで作成されたジャバコード部は、別途にコンパイルし、タグ部のバイトコードと結合することにより、１つのジャバクラスを作ることができる。この場合、ＸＣＭＬジャバ変換部２１０は、ＸＣＭＬファイルのうちタグ部をバイトコードに転換し、ジャバコンパイラ２２０は、ジャバコード部をコンパイルし、かつタグ部のバイトコードと結合してジャバクラスファイルを生成する役割をする。
【００６０】
ＸＣＭＬファイルのうちジャバコード（図２の１４０）を参照する場合、ゲートウェイではウェブサーバにジャバコード１４０を要請し、この転送を受ける。この場合、ＸＣＭＬジャバ変換部２１０で生成されたジャバコードとウェブサーバから取り込まれたジャバコードを結合して実行ファイルを作る。この場合、ジャバコンパイラ２２０は、ＸＣＭＬジャバ変換部２１０で生成されたジャバコードのみならず、ウェブサーバで取り込んだジャバコードもともにコンパイルして結合する役割をする。
【００６１】
ＸＣＭＬファイルの中では、ジャバコード（図２の１４０）のみならず、ｊａｒファイルを直接参照する場合もあり得る。この場合、ゲートウェイがＸＣＭＬファイルを解析し、必要なｊａｒファイルをウェブサーバに要請して転送を受ける。また、ブラウザがゲートウェイを通じてサーバに要求する新たなウェブコンテンツがＸＣＭＬではなく、最初からジャバで作成、別途コンパイルされたｊａｒファイルで構成されている場合もある。ｊａｒファイル処理部２３０は、このようにウェブサーバ１００からダウンロードされたファイルがコンパイルの不要なｊａｒファイルである場合、ジャバコンパイラ２２０の代わりにダウンロードされたファイルを処理するブロックである。ｊａｒファイル処理部２３０では、ｊａｒファイルが参照する外部ファイルがある場合、そのリストを抽出してウェブサーバ１００から取り込むようにする。
【００６２】
これと同様にウェブサーバ１００からのＸＣＭＬファイルに、このファイルが参照する別途のファイルがある場合、このようなリソースもウェブサーバ１００から取り込まれる。このように参照される外部リソースファイル取り込みのための別途のリソース取り込み部（図示せず）がＸＣゲートウェイ２００内に具現できる。
【００６３】
キャッシュ部２６０は、ウェブサーバ１００から取り込んできたファイルやコンパイルされた結果のバイナリファイルなどを保管するなど、格納機能を遂行する空間であって、多様な機能を遂行するように設計できることが当業者に知られているので、その詳細な連結関係や機能は図示しない。キャッシュ部２６０は、ＨＴＴＰプロトコル規格によりキャッシュの有効性をチェックするという点で、従来のウェブキャッシュと類似しているが、ウェブサーバから受けた形式ではなく、コンパイルされた結果を格納する場合があるという点では差がある。
【００６４】
セキュリティ管理部２４０は、バイトコードがクライアント側、即ち、端末３００に転送される前にセキュリティ上問題になるコードを含んでいるかを検査する。もし転送されるバイトコードがセキュリティ上問題になるコードを含んでいれば、ダウンロードを拒否するか、あるいは端末ユーザーの同意を得てダウンロードされるようにすることができる。具体的なセキュリティ管理方法については、以下で詳細に説明する。
【００６５】
プロトコルスタック２５０は、通信プロトコルの各層を具現したプログラム要素のセットであって、端末との接続のための無線インターネットの特性を考慮し、往復距離を最小化できるように変形されたＨＴＴＰプロトコルを用いる。本発明によるこのようなプロトコルのより具体的な事項については、以下で詳細に説明する。
【００６６】
次に、端末３００側の構成要素をさらに詳細に説明する。端末３００は、携帯電話、ＰＤＡ（ｐｅｒｓｏｎａｌ  ｄｉｇｉｔａｌ  ａｓｓｉｓｔａｎｃｅ）など、無線インターネットコンテンツをダウンロードして実行し、ディスプレイするための多様な種類の装置を含むことができる。
【００６７】
図１及び図２のＸＣブラウザ（ｅＸｅｃｕｔａｂｌｅ  Ｃｏｎｔｅｎｔ  Ｂｒｏｗｓｅｒ，  ＸＣＢ，  ３１０）は、ＸＣゲートウェイ２００と接続し、バイトコードを主内容とするコンテンツのダウンロードを受けて実行するクライアントアプリケーションであって、端末３００で実行される。
【００６８】
ユーザーインターフェース３２０は、共通のメニューなどブラウザ３１０自体のユーザーインターフェースを意味する。即ち、コンテンツと関連なく、ブラウザが本来有している共通のユーザーインターフェース要素を意味する。例えば、戻る、更新、ＵＲＬのオープン、ブックマーク、ヒストリー、オプションなどがこれに含まれる。
【００６９】
図２で、ページ１、ページ２などは、ウェブサーバ１００からダウンロードされて実行されるコンテンツの単位を示すブロックである。各ページは、ＵＲＬにより固有に定義され、１つ以上のジャバクラス及びリソースファイルで構成できる。
【００７０】
ＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）要素３６０は、ラベル（１行のテキストボックス）、ボタンなどのようなＵＩの要素を意味し、ＸＣＭＬあるいはジャバプログラムで用いたり相続できる。具体的に本発明の一実施例によれば、ＸＣＭＬでは、各ＵＩ要素をこれに該当する１つのタグを用いて表現することができる。例えば、「Ｈｅｌｐ」というテキストが表示されるボタンを作るためには、
＜ｂｕｔｔｏｎ  ｔｅｘｔ＝“Ｈｅｌｐ”／＞
のように記述することができ、このタグは、特定クラス、例えば、ＵＩ要素である「ｗｉｄｅｒｔｈａｎ．ｘｃｂ．Ｘｂｕｔｔｏｎ」クラスの１つのインスタンスを生成するコードに変換される。本発明によれば、コンテンツ内でシステム（ＸＣＢ）が提供する基本ＵＩ要素３６０の外観や機能を拡張または変更することが可能になる。即ち、基本ＵＩ要素を拡張または変更するために、ＵＩ要素に該当するジャバクラスを新たなクラスに相続して一部機能を追加または変更することができる。例えば、ｗｉｄｅｒｔｈａｎ．ｘｃｂ．ＸＢｕｔｔｏｎクラスを相続するＭｙＢｕｔｔｏｎというクラスを、ＸＣＭＬコンテンツ内の「ｈｅａｄｅｒ」部分で定義し、このクラスを用いるためにＸＣＭＬコンテンツの「ｂｏｄｙ」部分では、
＜ｂｕｔｔｏｎ  ｔｅｘｔ＝“Ｈｅｌｐ”ｃｌａｓｓ＝“ＭｙＢｕｔｔｏｎ”／＞
のように記述することができる。
【００７１】
レイアウト管理者３５０（あるいはレイアウトエンジンと称することもある）は、ＵＩ構成要素３６０を、コンテンツにより決定された条件に応じて画面上に配置する役割をする。例えば、画面の左側に所定の形態のボタン構成要素が配置されるものとしてウェブサーバのコンテンツに記述されている場合、このコンテンツがゲートウェイ２００で変換されたバイトコードがＸＣブラウザ３１０で実行されるとき、レイアウト管理者３５０は、本来のコンテンツに合うように構成要素を配置する役割をする。
【００７２】
キャッシュ２７０は、サーバからダウンロードされたジャババイトコード及びその他のリソースファイルをキャッシングする役割をする。以下でさらに詳細に記述するように、適切なキャッシング機能を通じてゲートウェイ２００と端末３００間の無線区間の通信量を少なくすることができる。
【００７３】
ブラウザ３１０のプロトコルスタックは、ＸＣゲートウェイ２００のプロトコルスタックに対応する。
【００７４】
前述したように、ＸＣＭＬは、ＨＴＭＬやＷＭＬと同様に宣言的形式を有する部分を主内容とし、ＨＴＭＬ内にジャバスクリプトが含まれるのと同様に、宣言的文法で表現できないコンテンツは、ジャバコードにより表現し、ウェブコンテンツファイル内に含めるか、またはウェブコンテンツファイル（ＸＣＭＬファイル）内で外部ジャバファイルを参照することができる。
【００７５】
従来のウェブサーバと端末で構成されたネットワークシステムにおいて、宣言的マークアップ言語とジャバスクリプト部分を含むウェブコンテンツファイルが最終的に端末画面に表示される過程の一例は次の通りである。
【００７６】
（１）端末のブラウザがウェブサーバに特定ＵＲＬにより指定されるウェブコンテンツファイルを要求する。
（２）ウェブサーバでウェブコンテンツファイルを生成するか、あるいはＵＲＬにより指定されるウェブコンテンツファイルを読み出してネットワークに転送する。
（３）端末のブラウザが前記ファイルをダウンロードしてパーシングする。
（４）パーサーが定められた方法によりＵＩコンポーネントを生成し、ファイルで指定する形式により初期化する。
（５）ジャバスクリプト部分は、実行可能な内部表現形式に変換し、格納される。
（６）ユーザーの入力は、各ＵＩコンポーネントを初期化するとき、指定された属性によって処理するか、またはＵＩコンポーネントの基本機能ではない、機能を遂行しようとする場合には、ＵＩコンポーネントに連結されたジャバスクリプトを呼び出して処理する。例えば、ボタン入力などにより複数のＵＩのうち特定のＵＩコンポーネントにフォーカスが当たるように動作させたとき、色相が変更されるように初期化するのは、次のようなコードで具現できる。
＜ａ  ｈｒｅｆ＝“ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ”
ｏｎｆｏｃｕｓ＝“ｊａｖａｓｃｒｉｐｔ：ｔｈｉｓ．ｓｔｙｌｅ．ｂａｃｋｇｒｏｕｎｄｃｏｌｏｒ＝’ｙｅｌｌｏｗ’“＞
Ｌｉｎｋ
＜／ａ＞
【００７７】
このような初期化内容に従って、特定のコンポーネントにフォーカスを移動させるユーザーの入力は、色相変更という動作を引き起こすように指定される。
【００７８】
これに比べて本発明によるＸＣＭＬファイルを端末にダウンロードして行うためには、例えば、次のような過程を経るようになる。
【００７９】
（１）ブラウザ（端末）が予め指定されたＸＣゲートウェイ２００に接続し、特定のＵＲＬにより指定されるＸＣＭＬファイルの要請をゲートウェイに転送する。
（２）ゲートウェイがサーバ１００に端末３００で要請したＸＣＭＬファイルを要請する。
（３）サーバ１００でＸＣＭＬファイルを生成するか、またはＵＲＬにより指定されたファイルを読み出してネットワークに転送する。
（４）ゲートウェイ２００がＸＣＭＬファイルをダウンロードし、パーシングしてジャバ実行コードを生成する。このとき、生成されるコードは、上記従来のブラウザがＵＩコンポーネントを生成して初期化するのと同一の動作を行うコードである。
（５）ゲートウェイが、ダウンロードされたＸＣＭＬファイル内に含まれるジャバコードやＸＣＭＬファイルが参照する外部ジャバコードを共にジャババイトコードとしてコンパイルし、端末３００のＸＣブラウザに転送する。
（６）ＸＣブラウザ３１０は、ジャババイトコードのダウンロードを受け、ジャババイトコードに該当するクラスを動的にローディングし、このコードを実行する。即ち、ＸＣブラウザ３１０は、ジャババイトコードをネットワークからダウンロードした後、現在実行中であるジャババーチャルマシンにローディングし、アプリケーションでこのバイトコードにより定義されるクラスを用いることができるようにした後、このコードを実行する。このコード実行過程でＵＩコンポーネントが生成され初期化される。
（７）ユーザー入力は、前記（６）の過程で生成されたＵＩコンポーネントが処理するか、または別途に含まれたジャバコードが処理する。
即ち、従来のウェブサーバと端末のブラウザを用いたブラウジング方式と本発明の方式の代表的な差異は次の通りである。
【００８０】
（ｉ）既存のブラウザでは、ブラウザ内にウェブコンテンツファイルを解析し、ＵＩコンポーネント３６０を生成、初期化する機能が含まれているのに対し、本発明による方式では、このような機能がゲートウェイ２００側にある。即ち、ゲートウェイがジャバコードを生成して端末側にダウンロードし、クライアントでは単にこのコードを実行するだけである。
（ｉｉ）既存のブラウザで手続的要素は、ジャバスクリプトで表現され、このようにジャバスクリプトで表現された部分は、これを実行可能な形式（主に固有のバイトコード）に変換するジャバスクリプトコンパイラ及びバイトコード解釈器により行われる。それに対し、本発明によれば、ジャバで表現された手続的コードが宣言的言語部と共にコンパイルされ、同一にジャババイトコードに変換された後、端末のジャバ仮想マシン（ＪＶＭ）で実行されるという点である。
【００８１】
このような本発明の方式の長所は、次のような点を含む。
−（宣言的言語部の）宣言的文法により生成されるコードと（非宣言的部分の）手続的コードが同一のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を用いるので、両者間の連動がより直接的かつ効率的である。
−端末のブラウザにより制限されることなく、ジャバ仮想マシン（ＪＶＭ）及び端末ライブラリが有する全てのＡＰＩ及び機能を用いることができ、端末では、ウェブページファイルをパーシングする過程なしに直ちにコードを実行すればよい。
−コンテンツを表現するマークアップ言語に新たな文法が追加されなければならないときにも、端末のブラウザに該当機能を追加するなどの変更が必要ではない。
【００８２】
［セキュリティ機能］
以下では、図３を参照して本発明によるセキュリティ機能を説明する。
【００８３】
図３は、本発明により実行可能なウェブコンテンツ（ＸＣ）を提供するためのネットワークシステムの概略図であって、本発明によるセキュリティ機能を例示的に説明するためのものである。図３の場合と同様に、コンテンツ提供者（ＣＰ）のサーバＢのＰというページを端末で実行しようとするとき、Ｐが通信事業者のサーバＡにあるライブラリＬを参照する場合、ＸＣゲートウェイ２００は、ＰとＬが合わせられたジャバアプリケーションをクライアント（ＸＣ  Ｂｒｏｗｓｅｒ，  ３１０）にダウンロードする。このとき、通信事業者のライブラリと、コンテンツ提供者のプログラムには、異なる水準のセキュリティポリシーが適用され得る。即ち、通信事業者によりその内容が管理されるＬに対しては、端末の全ての機能を用いることができるように許容をし、Ｐに対しては、電話をかけることや住所録など特定機能に対する接近を遮断するセキュリティポリシーが必要となり得る。
【００８４】
本発明によれば、このように１つのコンテンツ（Ｐ＋Ｌ）内においても、互いに異なるセキュリティポリシーを具現することが可能な新たなセキュリティメカニズムを提供する。本発明では、既存の場合と異なり、ゲートウェイが各サーバからダウンロードを受けたジャバコードを静的に検査し、各サーバ別に指定されたセキュリティポリシーに違反するコードが含まれている場合、ダウンロードを禁止したり、ユーザーの許諾を受けるようにする方案を提示する。
【００８５】
以下では、本発明によるセキュリティメカニズムを詳細に説明する。対象になるページがジャバコードではなく、マークアップ言語で作成されている場合、ゲートウェイ２００がこのファイルをパーシングし、ジャバコードを生成する過程でセキュリティポリシーを強制する場合、具体的な方法は知られているので、この場合に関する詳細な説明は省略し、以下では、ジャバクラスファイルの構造及びこれによるセキュリティメカニズムについて説明する。
【００８６】
ゲートウェイ２００があるサーバ１００からジャバソースコードあるいはバイナリファイル（クラスファイルあるいはクラスファイルを含むｊａｒファイル）をダウンロードした場合、ゲートウェイでセキュリティ機能を具現するために、ゲートウェイがダウンロードしたコードが端末のいかなる機能にアクセスするかを判断し、これを制御することができなければならない。このためには、ゲートウェイがジャバクラスファイルを分析する必要がある。図４は、ジャバのクラスファイルの構造の一例を示す。このうち、実際に実行されるバイトコードは、「ｍｅｔｈｏｄｓ」領域に含まれている。任意のメモリに対するアクセスが可能なネイティブコード（例えば、アセンブリコード）とは異なり、ジャバインタープリターやＪＩＴ（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）コンパイラを経て実行されるジャババイトコードは、クラスファイル内のコンスタントプール（ｃｏｎｓｔａｎｔ  ｐｏｏｌ：図４参照）により指定されるクラスと関数のみをアクセスすることができる。
【００８７】
一旦あるコードがポリシー上、接近が禁止されたクラスや関数に接近しているということ（例えば、電話帳への読み出し動作を禁止することが可能）をゲートウェイ２００が発見すれば、このコードの使用を禁止したり端末のユーザーに該当機能の使用に対する許可を受けるなどの機能を遂行しなければならず、このようにするのには、様々な方法があり得る。このような方法のいくつかの例を下記に説明する。このような多数の方法のうち、いかなる方法を適用するかは、通信事業者のポリシーあるいはセキュリティドメイン別に指定されるセキュリティポリシーにより決定され得る。
【００８８】
（ａ）ダウンロードを禁止する方法：ユーザー（即ち、クライアント）がダウンロードしようとするページをなすクラスファイルのうち、セキュリティポリシーに違反するコードが含まれている場合、このファイルのゲートウェイから端末へのダウンロードを中止させ、ユーザーと管理者にそのような事実を通知する。図１及び２に示された実施例では、セキュリティマネージャ２４０により前記のような機能が行われる。
【００８９】
（ｂ）ダウンロード時にユーザーの確認を受けるようにする方法：ユーザーが要請するページがいかなる機能に接近するのかをユーザーにまず知らせ、ユーザーがこれを承認する場合にのみそのページに移動する。例えば、クライアントがゲートウェイに要求したページが電話かけ関数を参照する場合、ゲートウェイはまずこのような事実をユーザーに知らせ（例えば、「このプログラムは電話をかける機能が含まれています。続けますか。」というメッセージを端末装置側に送る）、ユーザーの承諾如何をクライアントが再びゲートウェイに知らせ、ユーザーが承諾する場合にのみ、該当ページを端末にダウンロードする。
【００９０】
(ｃ)ランタイム時にユーザーの確認を受ける方法：上記２つの方法は、あるコードが実際にセキュリティポリシーに違反することをする前にダウンロードが根本的に遮断されるという特徴を有している。しかし、実際にそのコードを実行するとき、これを遮断したり承諾を受けるようにすることがさらに望ましい場合がある。即ち、一律的に所定の機能のコードが遮断されるようにするのではなく、実行時に具体的にどんなことをするかによってセキュリティポリシーを異なって適用するのが望ましい場合として、例えば、全てのサーバへの接続を統制する代わりに、所定のサーバへの接続のみを許容したり、端末側ファイルにアクセスするコードを全面的に遮断する代わりに、所定のファイル（所定のディレクトリ内のファイル）のアクセスのみを許容することなどがある。このようにランタイム時に異なる条件に応じてセキュリティポリシーが選択的に適用されるようにすることは、ゲートウェイでは不可能で、端末でのランタイム時にだけ可能である。従って、ゲートウェイでは、ランタイム時に所定の動作を行うようにするコードをプログラムに挿入することにより、所望の機能を具現することができる。ランタイム時に確認する方法をプログラムで具現する方法の実施例は次の通りである。即ち、第一の方法は、参照されるクラスを入れ替える方法であって、所定の無線ウェブページＰのあるコードが、セキュリティポリシー上接近が禁止されたクラスＣの関数Ｆにアクセスするとき、クラスＣを相続し、関数Ｆをオーバーライドする新たなクラスＣ１を予め端末に設けておくか、またはＰに含ませてダウンロードする。端末では、クラスＣ１の関数Ｆは、ユーザーの承諾を受けたときにのみＣの関数Ｆを呼び出す。このようなセキュリティ機能の具現のためのゲートウェイの動作を詳察すれば、Ｐに含まれたクラスのコンスタントプール（ｃｏｎｓｔａｎｔ  ｐｏｏｌ）でＣを参照する項目を、代わりにＣ１を参照するように修正し、修正されたバージョンをクライアントにダウンロードする。Ｃ１はＣを相続するため、Ｆ以外の全ての関数はＣの関数がそのまま呼び出されるようになり、Ｆの実行を除けば、いずれも本来のページＰの機能が全て行われる。上記方法は、クラスＣや関数Ｆが最終的な属性を有している場合、オーバーライドが不可能な場合もあり、そのような場合は適用することができないという短所がある。
【００９１】
第二の方法は、このような短所を克服するための方法であって、Ｃを相続するＣ１ではない、新たなクラスＤを作り、ＤのＦがユーザーの承諾を受けた後、ＣのＦを呼び出すようにする。ＤはＣを相続するクラスではなく、単にＦのみを呼び出す役割をするものであるので、上記のようにコンスタントプールのＣに対する参照をＤに差し替えれば、Ｆ以外の関数を呼び出すことができなくなる。従って、コンスタントプールにＤのための新たな項目を作り、メソッド（ｍｅｔｈｏｄ）領域のバイトコードをスキャンし、問題になるクラスＣのＦを呼び出すコードを、代わりにクラスＤのＦを呼び出すように修正する一方、ＤのＦには、ＣのＦを呼び出す前にユーザーの承諾を受けるようにするコードを挿入する。
【００９２】
上記方法によれば、コードの一部に対してのみ、それぞれ異なるセキュリティポリシーを設定し、強制することができるようになる。即ち、例えば、１つのページがそれぞれ異なるサーバからダウンロードされる場合もこのコードに対してそれぞれ異なるセキュリティポリシーを設定し、強制することができる。
【００９３】
以上説明したものの他にもランタイム時の条件に応じてセキュリティポリシーを適用する多様な方法があり得る。
【００９４】
［通信効率の改善］
無線インターネットで既存の方式（ＷＡＰ、特にｗｅｂ）のブラウザを用いれば、反応速度が有線インターネットと比較して大変遅いが、これは、無線インターネットの遅い転送速度と共に、特に転送速度に比べてもさらに遅い往復時間（ＲＴＴ）に起因する。既存のブラウザの場合、ＨＴＭＬあるいはＷＭＬで書かれた本文をサーバからダウンロードし、パーシングしてからこそそのページが必要とする他のファイル、例えば、イメージファイル、ジャバスクリプトファイル、ＣＳＳ（ｃａｓｃａｄｅ  ｓｔｙｌｅ  ｓｈｅｅｔ）ファイルなどをサーバに要求することができるため、１ページを示すために複数回のトランザクション（要求と応答を含む）を行わなければならない。有線（ＰＣ）ブラウザの場合、複数のファイルのダウンロードを受ける時間を減らすために、ＨＴＴＰ  １.１のパイプラインプロトコルを用いたり、サーバと２以上のＴＣＰ連結を開ける方法を用いる。無線インターネットで用いるＷＡＰブラウザの場合、具現上の問題により大部分ＨＴＴＰ  １.１のパイプラインや複数のＴＣＰ連結を用いない。また、たとえ具現が可能であっても、複数のＴＣＰ連結を開けるようになれば、各連結ごとに初期接続に必要な遅延及び初期速度の遅いＴＣＰの特性に応じたオーバーヘッドを有するようになるので、特にこのような遅延やオーバーヘッドの影響が大きく示される無線インターネットでは効率的でない。また、ＨＴＴＰ  １.１のパイプライニングは、全体的なページローディングの時間を減らす効果があるが、この場合にも外部ファイルを参照するウェブページの場合、少なくとも２回のトランザクションに必要な時間（即ち、ページ本文を受けるためのトランザクションと、本文のパーシング後に把握された残りのリソース／ファイルを要請するトランザクション）と受信したファイルをパーシングするのに要される時間の和が必要である。
【００９５】
後述する本発明の一実施例による、改善されたプロトコルを用いれば、トランザクションの数を最小化しながらも転送量が増加しないようにし、ページローディングの時間を低減することができる。
【００９６】
図５及び６は、本発明の一実施例によりトランザクションの数を減らす基本的な方法を説明するための図面である。即ち、図５は、従来の無線インターネットサーバとブラウザにおいて、多数のファイルを含む１つのウェブページがブラウザにダウンロードされる過程を示し、図６は、本発明の一実施例により多数のファイルを含む１つのウェブページをブラウザにダウンロードする過程を示すものである。図５で１つの矢印は１回のトランザクションを意味し、小さな長方形は１つのファイルを示す。図５に示す方法によれば、ブラウザがまず所定のページの本文ファイルをもってきて、これを解釈した後、ページ内で参照するファイルを順にもってきて、従って、１つのファイル当たり１回のトランザクションが発生し、全てのトランザクションは、無線ネットワークを介して行われる。たとえゲートウェイがサーバとブラウザ間にあるシステム（図５において点線で示すゲートウェイがシステム内に存在する場合）であっても、従来のゲートウェイは、ファイル要請とその結果をそのまま通過させるだけであり、サーバからいかなるファイルを転送するかは全てブラウザで決定されるので、無線トランザクションの数には影響を与えない。
【００９７】
一方、図６に示す本発明の一実施例によれば、ブラウザ３１０がゲートウェイ２００に所定のウェブページを要求すれば、ゲートウェイ２００は、ブラウザの介入なしでも前記ページが必要とする他のファイルまで全てサーバから取り込んで一度にブラウザに転送する。このような方式が可能になるためには、特定のページで必要とするファイルが何かをゲートウェイ２００が把握することができなければならない。所定のページで必要とするファイルを全てゲートウェイが分るというのは、ブラウザが特定のページを代表する１つのＵＲＬ（代表ＵＲＬ）のみを明示してページを要求する場合、ゲートウェイがこのページで必要とする他のファイルが何かを探し出すという意味である。本発明によるＸＣゲートウェイ２００は、ブラウザ３１０から転送される代表ＵＲＬに該当するＸＣＭＬファイルをサーバから取り込んでこれをパーシングするため、ＸＣＭＬファイルから静的に参照する外部ファイルが分り、そのため、ブラウザの要求なしでもウェブサーバ１００にこれらファイルを再び要求し、ページ本文のファイルと共に全て集めて端末のブラウザ３１０に一度にダウンロードすることができる。このようにすれば、有線区間で複数回のトランザクションによりゲートウェイがサーバから集めたデータを無線区間では一回のトランザクションで端末に転送させるようになる。図５と図６は、いずれも３つのファイルが１つのウェブページに含まれている場合を想定した例であって、トランザクション数を比較すれば、図５の場合（ゲートウェイがない場合）、３回の無線トランザクションを含むのに対し、図６は、１回の無線トランザクションと３回の有線トランザクションを含む。一般に有線ネットワークでのＲＴＴは無線のＲＴＴよりはるかに短いため、有線ネットワーク区間で複数回のトランザクションをすることは、全体の応答時間に大きな影響を及ぼさない。従って、全体的に無線区間のトランザクション数が少ない図６の方法は、図５の方法に比べて通信効率がさらに高い。
【００９８】
また、本発明の他の実施例によれば、通信方式をさらに効率的に作るために、既にブラウザの該当ページの最新バージョンのファイルが、端末内のキャッシュにキャッシングされている場合、これを再びダウンロードしないようにして通信に要される時間を最小化する。
【００９９】
無線インターネットの場合、大体ユーザーに転送容量に比例するパケット当たりの課金をするため、不要なダウンロードがなされる場合、不当に過多な料金が請求され得、応答時間も遅くなるため、既にあるファイルがブラウザにキャッシュされている場合、これを再びダウンロードしないのが望ましい。図７及び図８は、本発明の一実施例による、キャッシュを用いて不要な転送を防止するアルゴリズムを説明するための図面であって、それぞれブラウザ側及びゲートウェイ側で実行されるアルゴリズムを示す。以下では、図７及び８を参照してブラウザ及びゲートウェイそれぞれの動作を説明するのに先んじて、本発明のキャッシュ利用アルゴリズムを概括的に説明する。
【０１００】
１．ブラウザ１００が特定のページを代表するＵＲＬを利用し、ゲートウェイ２００にこのがページを要求するとき、このページが端末にキャッシュされている場合には、
−キャッシュされたウェブコンテンツファイルの最終の変更時間、このページで参照するファイルのうち現在キャッシュに残っているファイルの名称及びそれぞれの最終の変更時間を含む「キャッシングされたページファイルリスト」を共にゲートウェイに知らせる。このためにブラウザは、各ページの関連ファイル（メインページ及び参照ファイル）と共にキャッシングされたページファイルリストを共にキャッシュに格納する。本発明の一実施例によれば、キャッシュに格納されたファイルは、ページ単位で満了されキャッシュから削除されるので、殆どの場合、所定のページが必要とする参照ファイルは、該当ページのメインページファイルと共にキャッシュに格納されているようになるが、ページが更新され新たなファイルをページで参照する場合は、キャッシュに格納されたファイルと実際の参照ファイルに差が出るようになる。
【０１０１】
ゲートウェイは、ブラウザが要求した代表ＵＲＬに相応するウェブコンテンツファイルを要求する。
【０１０２】
２ａ．ゲートウェイがサーバから受けたメインページがＸＣＭＬ形式の場合：ＸＣＭＬをパーシングする。パーシングの結果でこのページで参照するファイルのリストであるページファイルリストが得られる。このページファイルリストは、前述したものと類似して所定のページで必要とするファイル名とファイルの最終の変更時間を含む。このリストで明示されたファイルの最新バージョンをサーバからもってきてゲートウェイキャッシュに格納する。このとき、ゲートウェイキャッシュの内容が最新の場合、ＨＴＴＰ  Ｉｆ−Ｍｏｄｉｆｉｅｄ−Ｓｉｎｃｅプロトコルにより実際に内容のダウンロードが起こりはしない。それと同時に、ページファイルリストには、各ファイルの最終の変更時間情報が加えられる。ゲートウェイは、上記１段階でブラウザが転送したブラウザにキャッシングされたページファイルリストとゲートでパーシングの結果で得たページファイルリストを比較する。比較の結果、ゲートウェイはキャッシングされたファイルから変更されたり新たに追加されたファイルをゲートウェイで得たページファイルリストと共にダウンロードし、サーバ側からなくなったファイルは削除することを端末のブラウザに指示する。ブラウザにキャッシングされたファイルと、サーバにあるファイルのファイル名及び最終の変更時間が同一の場合は、変更されていないものと判断してダウンロードしない。
【０１０３】
２ｂ．サーバから受けたメインページファイルがバイナリファイルの場合：このようなバイナリファイルは、ジャバクラスファイルと共に該当ページのメタ情報を共に有しているように構成されている。例えば、ジャバプログラムのパッケージングと転送に標準的に用いるｊａｒファイルの場合、ＭＥＴＡ−ＩＮＦという内部ディレクトリにＭＡＮＩＦＥＳＴ．ＭＦという名称のテキストファイルを含んでおり、このファイルには、バージョン、プログラムの名称、開始クラスなどが明示されている。本発明の一実施例によれば、ＭＡＮＩＦＥＳＴ．ＭＦファイルに、従来含まれる情報に追加で該当ページが参照する他のファイルの目録を表記するようにする。この場合、ゲートウェイは、このようなメタ情報ファイルをパーシングし、メインページが必要とする参照ファイル名と最終の変更時間を含むページファイルリストを得て、その後メインページがＸＣＭＬの場合と同一の手続により新たにダウンロードが必要なファイルのみを（即ち、ブラウザにキャッシングされたものと異なるファイルのみを）ブラウザにダウンロードする。
【０１０４】
但し、２ａと２ｂにおいて、１段階でブラウザが代表するページＵＲＬのみを転送し、ページファイルリストを転送しない場合、即ち、ブラウザが該当ページをキャッシングしていない場合には、ゲートウェイはブラウザにページファイルリストのみを先に転送し、実際のファイルを転送しない。これは、ブラウザが該当ページをキャッシングしてはいないが、このページで参照するファイル中の一部が他のページでも参照され、ブラウザのキャッシュに存在する場合、不要なダウンロードを防ぐためである。
【０１０５】
３．前記のような動作によりブラウザは、ゲートウェイが送るファイルとページファイルリストを受ける（Ｓ６０）。もしリスト内に含まれたファイルを別途に受けていないのにこのファイルがキャッシュにも格納されていないか、またはキャッシュに格納されたファイルの最終の変更時間がリストに表示された最終の変更時間よりも前である場合、このようなファイルをゲートウェイに新たに要求する（Ｓ８０）。
【０１０６】
４．ブラウザは、これまでキャッシュになかったファイルをキャッシュに格納し、更新されたファイルの場合、キャッシュを更新する。ページで参照するファイル目録などを含むページファイルリストも受信した情報により更新する（Ｓ１００）。
【０１０７】
５．ファイルのダウンロード及び格納が完了すれば、ページに該当するジャバクラスをロードして実行する（Ｓ１１０）。
このようなアルゴリズムによれば、ブラウザとゲートウェイ間に最大２回のトランザクションにより必要な全てのファイルを不要な転送なしにダウンロードすることができる。
【０１０８】
以下では、図７を参照して前記のようなアルゴリズムを具現するために、端末側でなされる動作を詳察する。
【０１０９】
段階Ｓ１０でユーザーが過去のページまたはブックマークで所定のリンクをクリックする等の方法で新たなページを要請すれば、段階Ｓ２０で端末のキャッシュに選択された該当ページの内容がキャッシュされているかを判断する。選択されたページがキャッシュにない場合、段階Ｓ５０で該当ページをゲートウェイに要求する。該当ページがキャッシュされている場合、ブラウザは、キャッシュからキャッシングされたページファイルリストをもってきて（Ｓ３０）、選択されたページをゲートウェイに要請すると同時にキャッシングされたページファイルリストをゲートウェイに転送する（Ｓ４０）。ブラウザの要請に従ってゲートウェイで送るメインページファイル、参照ファイル及びページファイルリストを段階Ｓ６０で受信し、段階Ｓ７０では、ゲートウェイから受けたリスト内に含まれてはいるものの、キャッシングされていないファイルがあるか確認する。キャッシングされていないファイルがある場合は、追加で必要なファイルをゲートウェイに要求して（Ｓ８０）受信し（Ｓ９０）、受信が完了し、これ以上受けるファイルがなければ、受信したファイルをキャッシュに格納（Ｓ１００）した後、メインページファイルを実行する（Ｓ１１０）。
【０１１０】
次は、図８を参照して、本発明の一実施例により前記のようなアルゴリズムを具現するために、ゲートウェイ側で行われる動作を考察する。
【０１１１】
段階Ｓ２１０でゲートウェイは端末が接続し、通信を開始することを待機し、端末が接続してきたら、所定の接続手続により通信を開始させ、段階Ｓ２２０に移る。段階Ｓ２２０では、端末からの要求を待って要求があればこれを受信する。段階Ｓ２３０では、受信された要求が接続終了の要求なのかを判断し、接続終了の要求である場合には、該当端末の接続に関連した動作を終了する。接続終了の要求ではない場合には、代表ＵＲＬの要求なのかを判断する（Ｓ２４０）。代表ＵＲＬの要求とは、ユーザーがＵＲＬを入力したり、リンクをクリックするなどの方法で所定のページを新たに要請する場合、この該当ＵＲＬのデータを要請することを意味する。代表ＵＲＬの要求は、ブラウザで所期のページのファイルを一部受けた後、不足したファイルをさらに要求することと相対する概念である。即ち、前述したように、１つのメインページファイルの実行に必要なファイルがブラウザに転送された後、ブラウザが１つのページを完成させるのに必要なファイルが全てあるかを確認し、不足したファイルがあれば、これを要請するようになり、ブラウザのゲートウェイに対する要求は、接続要求、接続終了の要求などの通信のための基本的は要求以外に、代表ＵＲＬの要求及び前述した個別ファイルの要求（ページを作るための一部ファイルが不足した場合）などを含む。代表ＵＲＬの要求の場合、ゲートウェイは、ブラウザから該当ページに必要なファイルのうちキャッシュされているファイルの名称及びファイルの最終の変更時間を含むキャッシングされたページファイルリストをともに受信する。
【０１１２】
ブラウザからの要求が代表ＵＲＬの要求である場合、ゲートウェイは、該当ＵＲＬのメインページの内容をウェブサーバに要求する（Ｓ２５０）。ゲートウェイは、メインページファイル（ウェブコンテンツファイル）を受信した後、受信したページの種類を確認し（Ｓ２６０）、ＸＣＭＬタイプのファイルの場合は、このファイルをパーシングし、その結果でページファイルリストを作成する（Ｓ２７０）。受信したファイルがｊａｒファイルのようなバイナリファイルである場合は、ＭＡＮＩＦＥＳＴファイルをパーシングしてページファイルリストを作成する（Ｓ２８０）。ページファイルリストの作成後、ブラウザから受けたキャッシングされたページファイルリストと比較して、ブラウザに新たにダウンロードすべきファイルの目録を作成する（Ｓ２９０）。ダウンロードするファイルが決定された後には、これをサーバあるいはゲートウェイ内のキャッシュからもってきた後（Ｓ３００）、ファイルリストと共にブラウザに転送する（Ｓ３１０）。
【０１１３】
段階Ｓ２４０でブラウザからの要請が代表ＵＲＬではない場合は、ブラウザが不足したファイルを要請する場合である。この場合は、段階Ｓ３００に戻って該当ファイルをサーバまたはキャッシュからもってきた後（Ｓ３００）、該当ファイルをブラウザに転送する（Ｓ３１０）。
【０１１４】
陳述した方法の他にも、端末側のキャッシュを効率的に用いるために、ゲートウェイに予め端末に格納されたファイルに関する情報を与え、ゲートウェイは必要なファイルのみを転送する他の具体的な方法があり得る。
【０１１５】
［共有リソース管理機能］
一般ウェブの場合と同様に、ＸＣＢでも複数のページ間に共通するライブラリやイメージなどは共有をしてキャッシュの使用率を高めることがページローディングの速度やパケット料金、キャッシュ使用量などいくつかの理由で望ましい。ところが、互いに異なるページ間にライブラリやイメージなどのリソース（以下、「共有リソース」という）を共有すれば、バージョンが合わない状況が発生し得る。
【０１１６】
図９は、従来技術のブラウザの共有リソースを管理する方法を示す図面である。ａ．ｘｈｔｍｌとｂ.ｘｈｔｍｌは、それぞれ異なるページを示すＸＨＴＭＬファイルであり、ジャバスクリプトライブラリｃ.ｊｓを共に共有している。
【０１１７】
図９（ａ）は、サーバに各ｘｈｔｍｌファイルのバージョン１.０があり、このファイルがｘ.ｊｓバージョン１.０を共有し、全てのファイルが端末にキャッシングされている状況を示している。
【０１１８】
サーバのファイルが全てバージョン１.１にアップグレードされたとき、図９（ｂ）は、端末がサーバとオンラインで接続した状態でａ.ｘｈｔｍｌページにアクセスし、端末キャッシュのａ.ｘｈｔｍｌとｃ.ｊｓファイルがそれぞれｖｅｒ  １.１にアップグレードされた状況を示す。
【０１１９】
この状態で端末がオフライン状態になれば、ユーザーがｂ.ｘｈｔｍｌページを用いようとするとき、ｂ.ｘｈｔｍｌはバージョン１.０であるが、ｃ.ｊｓはバージョン１.１であって、図９（ｃ）に示すようにバージョンの不一致現象が発生する。
【０１２０】
このようにあるリソースを互いに異なるページで共に共有するときに発生し得るバージョンの不一致問題は、単にウェブページだけでなく、一般のデスクトップオペレーションシステムに複数のアプリケーションを設けるときにも現われる現象である。このような問題を解決するための最も簡単な方法は、ウェブページ間にリソースを共有せずにウェブページ別に互いに異なる位置に各自の個別的なコピーファイルをおくことであるが、この方法は、端末のメモリが制限されており、特に小さなサイズのページが多い場合には適用し難い。
【０１２１】
本発明の一実施例によれば、前記したようなバージョンの不一致問題を解決するために図１０に示すような方法を用いる。
【０１２２】
図１０（ａ）は、図９（ａ）と同様にサーバにバージョン１.０のａ.ｘｃｍｌ、ｂ.ｘｃｍｌ、ｃ.ｊａｖａファイルがあり、クライアントのキャッシュにも同じバージョンがキャッシングされている状況を示す。このとき、本発明の一実施例で、共有できる全てのリソースファイルは該当ファイルの参照回数値を有するようにする。参照回数は、該当リソースファイルが如何に多くの他のファイルで参照されるかを示す数字であって、図１０（ａ）でｃ.ｊａｖａの参照回数は２である。
【０１２３】
図１０（ｂ）では、端末がオンライン上態でａ.ｘｃｍｌページにアクセスし、ａ.ｘｃｍｌとｃ.ｊａｖａのバージョン１.１ファイルをもってくる。このとき、前述したように実際に端末に伝達、格納されるファイルは、ＸＣＭＬとジャバのソースファイルではなく、これらファイルがゲートウェイで処理され生成されたクラスファイルであるが、便宜上図１０ではソースファイルの名称で表現することにする。このとき、バージョン１.１のｃ.ｊａｖａファイルを端末に格納する前に、既存のキャッシュに格納されていたバージョン１.０  ｃ.ｊａｖａの参照回数を１だけ減少する。このとき、図１０（ｂ）に示すように、減少後に既存バージョンの参照回数が０ではなければ、バージョン１.０のｃ.ｊａｖａを削除することなく、バージョン１.１のｃ.ｊａｖａを別途に格納する。バージョン１.１  ａ.ｘｃｍｌは、バージョン１.０  ａ.ｘｃｍｌに取って代わってバージョン１.１  ｃ.ｊａｖａにアクセスすることができるリンクを有する。
【０１２４】
図１０（ｃ）に示すように、クライアントがオフライン状態でｂ.ｘｃｍｌにアクセスすれば、本来リンクされていたバージョン１.０のｃ.ｊａｖａが共に用いられる。ａ.ｘｃｍｌにアクセスすれば、バージョン１.１のｃ.ｊａｖａが共にアクセスされる。
【０１２５】
もし参照回数が１であった共有リソースファイルが更新されれば、更新されたファイルのみが残り、本来のリソースファイルは削除する（本来のリソースファイルの参照回数が０になったため）。このような方法によれば、複数のページで同じリソースの同じバージョンを共有する場合、１つのファイルのみを格納し、効率を高めかつバージョンが異なるようになれば、互いに異なるバージョンを格納してバージョンの不一致を防止することができる。
【０１２６】
以下は、前記のような動作を具現するためのアルゴリズムの例を示す疑似コードである。以下で「ｐａｇｅ」は該当「ｕｒｌ」が示すページファイルを意味し、「ｒｅｓｏｕｒｃｅｓ」は「ｐａｇｅ」が必要とするリソースファイルのリストである。
【０１２７】
ｆｕｎｃｔｉｏｎ  ｄｏｗｎｌｏａｄ＿ｐａｇｅ（ｕｒｌ）：
ｐａｇｅ，  ｒｅｓｏｕｒｃｅｓ＝ｒｅｑｕｅｓｔ＿ｐａｇｅ（ｕｒｌ）
ｆｏｒ  ｒ  ｉｎ  ｒｅｓｏｕｒｃｅｓ：
ｃａｃｈｅ＿ｒｅｓｏｕｒｃｅ（ｒ）
ｃａｃｈｅ＿ｐａｇｅ（ｐａｇｅ）
ｆｕｎｃｔｉｏｎ  ｃａｃｈｅ＿ｐａｇｅ（ｐａｇｅ）：  
ｉｆ  ｐａｇｅ．ｕｒｌ  ｉｎ  ｃａｃｈｅ：
；ｕｎｌｉｎｋ  ｐｒｅｖｉｏｕｓ  ｐａｇｅ
ｆｏｒ  ｒ  ｉｎ  ａｃｈｅ［ｐａｇｅ．ｕｒｌ］．ｒｅｓｏｕｒｃｅｓ：
ｒ．ｒｅｆ＿ｃｏｕｎｔ−−；
ｉｆ  ｒ．ｒｅｆ＿ｃｏｕｎｔ＝＝０：
ｄｅｌｅｔｅ  ｃａｃｈｅ［ ｒ．ｕｒｌ＋  ｒ．ｖｅｒｓｉｏｎ］
；ｐｕｔ  ｎｅｗ  ｐａｇｅ
ｃａｃｈｅ［ｐａｇｅ．ｕｒｌ］＝ｐａｇｅ
ｆｏｒ  ｒ  ｉｎ  ｐａｇｅ．ｒｅｓｏｕｒｃｅｓ：
ｃａｃｈｅ［ｒ．ｕｒｌ＋ｒ．ｖｅｒｓｉｏｎ］．ｒｅｆ＿ｃ  ｏｕｎｔ＋＋
ｆｕｎｃｔｉｏｎ  ｃａｃｈｅ＿ｒｅｓｏｕｒｃｅ（ｒ）：
ｃａｃｈｅ［ｒ．ｕｒｌ＋ｒ．ｖｅｒｓｏｉｎ］＝ｒ
【０１２８】
本明細書で図面に示す各ブロックは、プログラムの機能を表示するためのものであって、実際のプログラムで具現する過程で１つのブロックが１つまたはそれ以上のプログラム部分（要素）で具現されることができ、または複数のブロックの機能が１つのプログラム要素により具現されることができ、複数のプログラム要素により複合的に具現され得る。具体的な機能ブロックを具現する方法は、当業者により多様な変形と組合わせが可能である。
【図面の簡単な説明】
【０１２９】
【図１】本発明により実行可能なウェブコンテンツ（ＸＣ）を提供するためのネットワークシステムの概略図である。
【図２】図１の詳細な細部ブロック図である。
【図３】本発明により実行可能なウェブコンテンツ（ＸＣ）を提供するためのネットワークシステムの他の概略図であって、本発明によるセキュリティ機能を説明するための概略図である。
【図４】ジャバのクラスファイルの構造の一例を示す図である。
【図５】本発明の一実施例によりトランザクションの数を低減する基本的な方法を説明するためのネットワークシステムの概略図である。
【図６】本発明の一実施例によりトランザクションの数を低減する基本的な方法を説明するためのネットワークシステムの概略図である。
【図７】本発明の一実施例による、キャッシュを用いて不要な転送を防止するアルゴリズムを説明するための図であって、ブラウザ側のアルゴリズムを示す図である。
【図８】本発明の一実施例による、キャッシュを用いて不要な転送を防止するアルゴリズムを説明するための図であって、ゲートウェイ側で実行されるアルゴリズムを示す図である。
【図９】従来技術のブラウザの共有リソースを管理する方法を示す図である。
【図１０】本発明の一実施例により共有リソースを管理する方法を示す図である。
【符号の説明】
【０１３０】
１００  ウェブサーバ
２００  ゲートウェイ
２１０  ＸＣＭＬ−ジャバ変換部
２２０  ジャバコンパイラ
２３０  ｊａｒ処理部
２４０  セキュリティ管理部
２５０  プロトコルスタック
２６０  キャッシュ
３００  端末
３１０  ブラウザ
【図１】
2008527564.tif 000003
【図２】
2008527564.tif 000004
【図３】
2008527564.tif 000005
【図４】
2008527564.tif 000006
【図５】
2008527564.tif 000007
【図６】
2008527564.tif 000008
【図７】
2008527564.tif 000009
【図８】
2008527564.tif 000010
【図９】
2008527564.tif 000011
【図１０】
2008527564.tif 000012
【国際調査報告】
2008527564.tif 000013