JP2005056096A - 通信システム及び通信方法、並びにサーバ装置及び携帯電話端末機 - Google Patents

Abstract

【課題】 極めて厳しい制約のある携帯電話端末機のアプリケーション環境においても高機能のアプリケーションを実現することができる全く新規な仕組みを提案する。
【解決手段】 通信システムは、所定のパケット通信網ＮＴ_１に対して接続された携帯電話端末機１０と、インターネット網ＮＴ_２に対して接続されたＷＷＷサーバ２０と、携帯電話端末機１０がパケット通信網ＮＴ_１を介して直接アクセス可能とされるプロキシサーバ３０とを備える。プロキシサーバ３０は、携帯電話端末機１０からのコンテンツの閲覧リクエストに応じて当該コンテンツを格納するＵＲＬを復号し、ＷＷＷサーバ２０と通信を行って当該コンテンツを取得し、取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントＳＴを携帯電話端末機１０に対して送信する。
【選択図】 図５

Description

本発明は、インターネット網を介してデータの授受を行う通信システム及び通信方法、並びにこれら通信システム及び通信方法に用いられるサーバ装置及び携帯電話端末機に関する。

近年、モバイルネットワークの技術の急速な発展にともない、インターネット網に接続可能な携帯電話端末機が著しく普及している。このような携帯電話端末機は、所定のブラウザを搭載し、このブラウザを介して単独でインターネット網に接続可能とされ、コンテンツとして提供される各種アプリケーションプログラムをダウンロードして実行したり、電子メールの授受を行ったりすることが可能とされる。

このような携帯電話端末機を用いたシステムにおいては、携帯電話会社が提供する所定のパケット通信網を通過するパケット数に応じて課金されるのが通常である。したがって、この種のシステムにおいては、通信量が増加するのにともないパケット数が増加し、通信費が高騰することになる。そこで、このような携帯電話端末機のユーザの負担を軽減すべく、送受信されるデータを圧縮することによってパケット通信網を通過するパケット数を削減し、通信費を抑制する技術が開発されている（例えば、特許文献１参照。）。

特開２００３−１３４１７５号公報

この特許文献１には、送信側携帯端末で圧縮されたデータを移動パケット通信網及びインターネット網を介して受信側携帯端末に対して送信する圧縮メール通信システムが開示されている。特に、この圧縮メール通信システムは、インターネット網上に圧縮データを伸長する中継サーバを備えることにより、受信側携帯端末に伸長機能を設ける必要がなく、当該受信側携帯端末の通信費の低減を図ることができるとしている。

ところで、携帯電話端末機においては、極めて厳しい制約がある資源を用いて各種プログラムを実行する必要があるアプリケーション環境であることから、実装できるプログラム容量に自ずと制限が生じ、高い処理能力を必要とする高機能のアプリケーションを実現することは極めて困難であった。また、携帯電話端末機においては、上述したように、コンテンツとしての各種アプリケーションプログラムをダウンロードすることができるが、パケット通信網を介して一度に送受信することができる容量は例えばウェブサイトのブラウジングのために１０ｋバイト、並びに電子メールの送信のために約０．５ｋバイト及び電子メールの受信のために約４ｋバイトといった制限があることから、通信速度の高速化が望めず、また、コンテンツの作成者にとっても制約が生じる事態を招来している。

本発明は、このような実情に鑑みてなされたものであり、極めて厳しい制約のある携帯電話端末機のアプリケーション環境においても高機能のアプリケーションを実現することができる全く新規な仕組みを提案する通信システム及び通信方法を提供することを目的とする。また、本発明は、これら通信システム及び通信方法に用いられるサーバ装置及び携帯電話端末機を提供することを目的とする。

上述した目的を達成する本発明にかかる通信システムは、インターネット網を介してデータの授受を行う通信システムであって、所定のパケット通信網に対して接続された携帯電話端末機と、上記インターネット網に対して接続された各種コンテンツを格納するコンテンツサーバと、上記携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされ、上記コンテンツサーバからコンテンツを取得し、上記パケット通信網を介して上記携帯電話端末機に対して配信代行を行うプロキシサーバとを備え、上記プロキシサーバは、上記携帯電話端末機からの上記コンテンツの閲覧リクエストに応じて当該コンテンツを格納するＵＲＬを復号し、当該コンテンツを格納する上記コンテンツサーバと通信を行い、当該コンテンツを取得し、取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信し、上記携帯電話端末機は、上記コンテンツの木構造の組み立てを行い、組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行い、所定の表示画面に表示させることを特徴としている。

このような本発明にかかる通信システムは、従来であれば携帯電話端末機によって行っていた負荷の高いコンテンツの解析処理をプロキシサーバによって行うことから、処理の負荷を分散させることができる。

ここで、上記プロキシサーバは、上記ＵＲＬを当該ＵＲＬを識別する識別子であるＵＲＬＩＤに圧縮して上記携帯電話端末機に対して送信し、上記携帯電話端末機は、上記コンテンツの閲覧リクエストを行う際にＵＲＬＩＤを上記プロキシサーバに対して送信する。

これにより、本発明にかかる通信システムにおいては、プロキシサーバと携帯電話端末との間で授受される通信量を削減することができ、通信費の低減を図ることができる。

また、上記プロキシサーバは、上記コンテンツサーバから取得したコンテンツを解析した結果、上記パケット通信網を提供する携帯電話会社が公認するウェブサイトに関する管理を行うために必要な当該携帯電話会社が発行したユーザＩＤを識別する記述がＵＲＬに含まれていることを検知した場合には、ＵＲＬをＵＲＬＩＤに圧縮する際に、検知したユーザＩＤを付加したＵＲＬＩＤに変換し、上記携帯電話端末機に対して送信する。

このように、本発明にかかる通信システムにおいては、プロキシサーバによってコンテンツサーバから取得したコンテンツを解析して得られたＵＲＬをＵＲＬＩＤに圧縮して携帯電話端末機に対して受け渡す際に、ユーザＩＤを付加したＵＲＬＩＤに変換することにより、ユーザＩＤをパケット通信網に供給することができ、携帯電話会社が公認するウェブサイトの会員ユーザの管理を何ら支障なく行うことが可能となる。

さらに、上記プロキシサーバは、上記携帯電話端末機からのリクエストに応じて、上記コンテンツサーバを検索して接続し、当該コンテンツサーバからコンテンツをダウンロードした後、当該コンテンツサーバとの接続を切断し、上記コンテンツサーバからダウンロードした上記コンテンツを解析し、参照する画像ファイルのＵＲＬを示す一覧リストを取得し、取得した上記画像ファイルのＵＲＬに基づいて、当該画像ファイルを格納するコンテンツサーバを検索して接続し、当該コンテンツサーバから画像ファイルをダウンロードした後、当該コンテンツサーバとの接続を切断する処理を、取得すべき画像ファイルの数だけ繰り返し行い、取得したコンテンツと画像ファイルとをアーカイブする。そして、上記携帯電話端末機は、上記プロキシサーバからアーカイブされたデータをダウンロードした後、当該プロキシサーバとの接続を切断してアーカイブされたデータを取得し、アーカイブされたデータからコンテンツと画像ファイルとを分離抽出する。

これにより、本発明にかかる通信システムにおいては、携帯電話端末機とプロキシサーバとの間での接続及び切断の回数が１回で済むことから、プロキシサーバを検索して接続し、当該プロキシサーバからデータをダウンロードする、という携帯電話端末機における負荷の高い処理を１回で済ませることができ、処理の高速化を図ることができる。

さらにまた、上記携帯電話端末機及び上記プロキシサーバは、当該携帯電話端末機と当該プロキシサーバとの間でデータの送受信を行う際のライブラリを１つのレイヤとして構築し、上記携帯電話端末機は、上記コンテンツサーバに対して制限以上の容量のデータをアップロードデータとしてアップロードする場合には、当該アップロードデータを送信可能な容量に分割し、分割したデータ毎に、上記プロキシサーバとの間でセッションを確立して当該データを送信し、上記プロキシサーバは、セッション毎にキャッシュを生成して所定のアップロードキャッシュに追記し、上記携帯電話端末機から全てのデータの送信が完了すると、上記アップロードデータを復元し、アップロードすべき上記コンテンツサーバに対して当該アップロードデータを送信する。

一方、上記プロキシサーバは、上記コンテンツサーバに格納されている制限以上の容量のデータをダウンロードデータとして上記携帯電話端末に対してダウンロードする場合には、当該コンテンツサーバから当該ダウンロードデータを取得して所定のダウンロードキャッシュに格納し、上記ダウンロードキャッシュから送信可能な容量のデータを読み出すことによって上記ダウンロードデータを分割し、上記携帯電話端末との間で分割したデータ毎にセッションを確立して当該携帯電話端末機に対して当該データを送信し、上記携帯電話端末機は、上記プロキシサーバから全てのデータの送信が完了すると、上記ダウンロードデータを復元する。

このように、本発明にかかる通信システムにおいては、携帯電話端末機とプロキシサーバとの間でデータの送受信を行う際のライブラリを１つのレイヤとして構築することにより、アプリケーション側からみて仮想的に制限以上の容量のデータを送受信できるような仕組みを構築することができ、アプリケーションの制限がなくなり、また、プラットフォームを移行もライブラリの変更のみに集約することができることから極めて容易となる。

また、上記コンテンツサーバは、ロジック部分であるプログラム本体と、非ロジック部分であるテキストファイル並びに画像ファイル及び音声ファイルとからなるコンテンツとして作成されたアプリケーションプログラムを、上記ロジック部分と上記非ロジック部分とに分割するとともに、分割したロジック部分に所定のアーカイブライブラリを付与して格納し、上記携帯電話端末機は、上記アプリケーションプログラムをダウンロードする際に、上記プロキシサーバを介して上記アーカイブライブラリが付与された上記ロジック部分のみをダウンロードして保存し、上記アーカイブライブラリを起動して、上記非ロジック部分を上記プロキシサーバを介して上記コンテンツサーバから取得する。

このように、本発明にかかる通信システムにおいては、コンテンツの作成側でアプリケーションプログラムをロジック部分と非ロジック部分とに分割し、携帯電話端末機によってロジック部分のみを先にダウンロードすることにより、非ロジック部分の容量だけより大きな容量のアプリケーションプログラムを作成することが可能となることから、高機能のアプリケーションプログラムを実現することができる。

ここで、上記アプリケーションプログラムとしては、上記携帯電話端末機で実行可能なブラウザとメーラとを統合したソフトウェアであり、当該アプリケーションプログラムを待ち受け画面として待機させたまま、所定のサービスを利用可能とされるものを適用することができる。

この場合、上記携帯電話端末機は、上記アプリケーションプログラムを実行し、上記ブラウザを介して所定のコンテンツサーバから取得した待ち受け画面用の画像ファイル及び／又は着信音声用の音声ファイルを所定の保存領域に保存し、この保存領域を上記メーラと共用するのが望ましい。

これにより、本発明にかかる通信システムにおいては、携帯電話端末機がブラウザを介して所定のコンテンツサーバから取得した待ち受け画面用の画像ファイルや着信音声用の音声ファイルを、メーラの待ち受け画面や電子メール着信時の音声にも共用することができ、携帯電話端末機とプロキシサーバとの間で授受される通信量を結果として削減することができることから、通信費の低減に寄与することができる。

また、上記携帯電話端末機は、上記アプリケーションプログラムを実行し、上記メーラを介して所定のコンテンツサーバから電子メールのヘッダ情報からなる新着メールの一覧リストを取得し、本文の閲覧を希望したメール本文をページ毎に分割し、必要なページのみを受信するとともに、必要な添付ファイルをダウンロードすることもできる。

これにより、本発明にかかる通信システムにおいては、通信量を最小限に削減することができる極めて効率のよいメーラの機能を携帯電話端末機上で実現することができる。

さらに、上記携帯電話端末機は、上記アプリケーションプログラムを実行し、所定の表示画面に表示されたコンテンツをのうち画面範囲を超過する分について、上下方向にページ単位でスクロールさせるようにしてもよい。

これにより、本発明にかかる通信システムにおいては、携帯電話端末機の機種に依存せずにスクロール動作を効率よく行わせることができる。

さらにまた、上記携帯電話端末は、上記アプリケーションプログラムを実行し、格納しているアドレス帳を上記プロキシサーバにアップロードし、上記パケット通信網及び／又は上記インターネット網に接続される他の機器に対してインポート可能に、当該プロキシサーバに確保された所定の保存領域に格納させることもできる。

これにより、本発明にかかる通信システムにおいては、プロキシサーバを介して複数の携帯電話端末機やパーソナルコンピュータ等との間でアドレス帳を連動させることができることから、最適なアドレス帳のバックアップ手段を提供することができ、携帯電話端末機の紛失や機種変更時の手間を格段に省くことができる。

また、上述した目的を達成する本発明にかかる通信方法は、インターネット網を介してデータの授受を行う通信方法であって、所定のパケット通信網に対して接続された携帯電話端末機からのコンテンツの閲覧リクエストに応じて、上記携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされるプロキシサーバによって当該コンテンツを格納するＵＲＬを復号し、当該コンテンツを格納する上記インターネット網に対して接続されたコンテンツサーバと上記プロキシサーバとが通信を行い、当該プロキシサーバによって当該コンテンツを取得し、上記プロキシサーバによって取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信し、上記携帯電話端末機によって上記コンテンツの木構造の組み立てを行い、上記携帯電話端末機によって組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行い、所定の表示画面に表示させることを特徴としている。

このような本発明にかかる通信方法は、従来であれば携帯電話端末機によって行っていた負荷の高いコンテンツの解析処理をプロキシサーバによって行うことから、処理の負荷を分散させることが可能となる。

さらに、上述した目的を達成する本発明にかかるサーバ装置は、所定のパケット通信網に対して接続された携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされ、インターネット網に対して接続された各種コンテンツを格納するコンテンツサーバからコンテンツを取得し、上記パケット通信網を介して上記携帯電話端末機に対して配信代行を行うサーバ装置であって、上記携帯電話端末機からの上記コンテンツの閲覧リクエストに応じて当該コンテンツを格納するＵＲＬを復号するＵＲＬ復号手段と、当該コンテンツを格納する上記コンテンツサーバと通信を行い、当該コンテンツを取得するクライアント処理手段と、上記クライアント処理手段によって取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信するコンテンツ解析手段とを備えることを特徴としている。

このような本発明にかかるサーバ装置は、従来であれば携帯電話端末機によって行っていた負荷の高いコンテンツの解析処理を自己が行うことにより、システム全体における処理の負荷を分散させることが可能となる。

さらにまた、上述した目的を達成する本発明にかかる携帯電話端末機は、所定のパケット通信網に対して接続され、インターネット網に対して接続されたコンテンツサーバに格納されたコンテンツをプロキシサーバを介して取得する携帯電話端末機であって、上記プロキシサーバによって上記コンテンツサーバから取得したコンテンツの木構造を組み立てるのに必要な最低限のイベントを当該プロキシサーバから受信して、上記コンテンツの木構造の組み立てを行う木構造組立手段と、上記木構造組立手段によって組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行うレイアウト処理手段と、所定の表示画面に表示させる表示処理手段とを備えることを特徴としている。

このような本発明にかかる携帯電話端末機は、従来であれば自己が行っていた負荷の高いコンテンツの解析処理をプロキシサーバによって行わせることにより、システム全体における処理の負荷を分散させることが可能となる。

本発明は、従来であれば携帯電話端末機によって行っていた負荷の高い処理をプロキシサーバによって行わせて処理の負荷を分散させるとともに、各種新たな仕組みを備えたプラットフォームを提供することにより、極めて厳しい制約のある携帯電話端末機のアプリケーション環境においても高機能のアプリケーションを実現を図ることができ、結果として、処理の高速化や通信費の低減をも図ることができる。

以下、本発明を適用した具体的な実施の形態について図面を参照しながら詳細に説明する。

この実施の形態は、インターネット網に接続可能な携帯電話端末機を用いた通信システムである。この通信システムは、極めて厳しい制約のある携帯電話端末機のアプリケーション環境においても高機能のアプリケーションを実現することができる全く新規な仕組みを提案するものである。

具体的には、通信システムは、図１に示すように、所定のパケット通信網ＮＴ_１に対して接続された複数の携帯電話端末機１０_１，１０_２，１０_３，・・・と、インターネット網ＮＴ_２に対して接続された各種コンテンツを格納するコンテンツサーバとしての複数のＷＷＷ（World Wide Web）サーバ２０_１，２０_２，２０_３，・・・と、携帯電話端末機１０_１，１０_２，１０_３，・・・がパケット通信網ＮＴ_１を介して直接アクセス可能とされるプロキシサーバ３０とを備えるものである。

このような通信システムにおいては、携帯電話端末機１０_１，１０_２，１０_３，・・・のそれぞれからのリクエストに応じて、プロキシサーバ３０がインターネット網ＮＴ_２を介して所望のＷＷＷサーバ２０_１，２０_２，２０_３，・・・にアクセスする。そして、プロキシサーバ３０は、アクセスしたＷＷＷサーバから所望のＣＨＴＭＬ（Compact Hyper Text Markup Language）文書等のコンテンツを取得し、このコンテンツをパケット通信網ＮＴ_１を介して当該携帯電話端末機１０_１，１０_２，１０_３，・・・のそれぞれに対してダウンロードすることにより、コンテンツの配信代行を行う。これにより、携帯電話端末機１０_１，１０_２，１０_３，・・・は、それぞれ、所定のブラウザを介してウェブサイトの閲覧を行うことができ、また、各種アプリケーションプログラムをダウンロードして実行することが可能となる。

なお、ＣＨＴＭＬとは、いわゆるＨＴＭＬ（Hyper Text Markup Language）のサブセットであり、限られたサイズの表示画面の中で反映可能なタグのみ残して他の部分を切り捨てたものである。例えば株式会社ＮＴＴドコモが提供するサービスであるｉモード（登録商標）においては、ｉモード用ＨＴＭＬを採用しており、これは携帯電話端末機に必要な機能を絞り込み、約３０種類のタグが使用され、また、画像についても２段階調節のＧＩＦ（Graphics Interchange Format）ファイルが推奨される等の限定条件がある。

ＷＷＷサーバ２０_１，２０_２，２０_３，・・・は、それぞれ、このようなＣＨＴＭＬや、移動体通信用のプロトコルであるＷＡＰ（Wireless Application Language）にて使用される記述言語であるＨＤＭＬ（Handheld Device Markup Language）又はＷＭＬ（Wireless Markup Language）等を用いることにより、表示領域や表示能力に制限がある携帯電話端末機１０_１，１０_２，１０_３，・・・で閲覧することが可能なコンテンツを作成することができる。

さて、以下では、このような通信システムの詳細な説明に先だって、携帯電話端末機１０_１，１０_２，１０_３，・・・の機能を明確化すべく、当該携帯電話端末機１０_１，１０_２，１０_３，・・・について説明する。なお、以下では、これら携帯電話端末機１０_１，１０_２，１０_３，・・・を携帯電話端末機１０と総称するとともに、インターネット網ＮＴ_２に接続されるＷＷＷサーバ２０_１，２０_２，２０_３，・・・をＷＷＷサーバ２０と総称するものとする。

携帯電話端末機１０としては、例えば図２に外観を示すように、中央のヒンジ部５１を境界にして表示部５２と本体５３とに大別されて構成され、さらに、ヒンジ部５１を介して折り畳み可能に構成されるものがある。

表示部５２には、上端左部に送受信用のアンテナ５４が引出し及び収納可能な状態に取り付けられる。携帯電話端末機１０は、このアンテナ５４を介して基地局との間で電波の送受信を行う。また、表示部５２には、所定の角度範囲で回動自在とされるカメラ部５５が設けられる。携帯電話端末機１０は、このカメラ部５５を構成するＣＣＤ（Charge Coupled Devices）カメラ５６によって所望の被写体を撮影することができる。さらに、表示部５２には、その正面にＬＣＤ（Liquid Crystal Display）５８が設けられる。携帯電話端末機１０は、電界強度に応じた電波の受信状態や電池残量等の各種状態、アドレス帳として登録されている相手先名や電話番号及び発信履歴、電子メールの内容、ウェブサイト、カメラ部５５におけるＣＣＤカメラ５６によって撮影した画像等をＬＣＤ５８に表示することができる。

一方、本体５３には、"０"から"９"までの数字キー、発呼キー、リダイヤルキー、終話及び電源キー、クリアキー、電子メールキー、カーソルキー、実行キー、ダウンロードした各種アプリケーションプログラムを活性化するための活性化キー等の複数の操作キー５９が設けられる。携帯電話端末機１０においては、この操作キー５９を介して、各種指示が入力される。特に、携帯電話端末機１０は、ユーザによるカーソルキーの押下操作に応じて、ＬＣＤ５８に表示されるアドレス帳や電子メールのスクロール動作、ウェブサイトの握り動作、及び画像の送り動作といった種々の動作を実行することができる。また、本体５３には、メモボタン６０やマイクロフォン６１が設けられる。携帯電話端末機１０は、このメモボタン６０によって通話中における音声を録音することができ、また、マイクロフォン６１によって通話時におけるユーザの音声を集音することができる。なお、本体５３には、背面側に着脱可能とされる図示しないバッテリパックが装着される。携帯電話端末機１０は、このバッテリパックが本体５３に対して装着された状態で、操作キー５９における終話及び電源キーがオン状態になると、このバッテリパックから内部の各回路部に対して電力が供給され、動作可能な状態に起動する。さらにまた、本体５３には、電気的にデータの書き換えや消去が可能である不揮発性メモリからなる半導体記録媒体６２を着脱自在に装着するためのスロット６３が設けられる。携帯電話端末機１０は、上述したメモボタン６０が押下されると半導体記録媒体６２に対して通話中の相手の音声を記録したり、又はユーザの操作に応じて電子メール、ウェブサイト、ＣＣＤカメラ５６によって撮影して得られた画像等を記録したりすることができる。

このような外観を呈する携帯電話端末機１０は、内部的には図３に示すように、表示部５２及び本体５３における各部を統括的に制御する主制御部７１に対して、操作入力制御部７２、画像エンコーダ７３、カメラインターフェース（Ｉ／Ｆ）部７４、表示制御部７５、画像デコーダ７６、多重分離部７７、記録再生部７８、変復調回路部７９、及び音声コーデック８０が、所定のバスを介して互いに接続されて構成される。

携帯電話端末機１０は、通話時には、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等からなる主制御部２０１の制御のもとに、マイクロフォン６１によって集音したアナログの音声信号を音声コーデック８０によってディジタル音声データに変換し、さらに変復調回路部７９によって所定の変調処理を施し、得られたデータに対して、送受信回路部８１によってディジタル−アナログ変換処理及び周波数変換処理等を施した後、アンテナ５４を介して送信する。また、携帯電話端末機１０は、アンテナ５４によって受信した受信信号を送受信回路部８１によって増幅して周波数変換処理及びアナログ−ディジタル変換処理等を施し、得られたデータに対して、変復調回路部７９によって所定の復調処理を施し、さらに音声コーデック８０によってアナログの音声信号に変換した後、スピーカ５７を介して外部に出力する。

また、携帯電話端末機１０は、データ通信時において電子メールを送信する場合には、ユーザによる操作キー５９の操作に応じて入力された電子メールのテキストデータを操作入力制御部７２を介して主制御部７１に供給する。そして、携帯電話端末機１０は、主制御部７１の制御のもとに、テキストデータに対して、変復調回路部７９によって所定の変調処理を施し、さらに送受信回路部８１によってディジタル−アナログ変換処理及び周波数変換処理等を施した後、アンテナ５４を介して外部に送信する。一方、携帯電話端末機１０は、電子メールを受信する場合には、アンテナ５４を介して受信した受信信号に対して、変復調回路部７９によって所定の復調処理を施して元のテキストデータを復元した後、表示制御部７７を介してＬＣＤ５８に電子メールとして表示する。

さらに、携帯電話端末機１０は、データ通信モード時においてＣＣＤカメラ５６によって撮影されて得られた動画像データを送信する場合には、ＣＣＤカメラ５６によって撮影されて得られた画像データをカメラインターフェース部７４を介して画像エンコーダ７３に供給し、この画像エンコーダ７３によって画像データを所定の符号化方式に基づいて圧縮符号化し、得られた符号化画像データを多重分離部７７に供給する。これと同時に、携帯電話端末機１０は、ＣＣＤカメラ５６による画像データの撮影中にマイクロフォン６１によって集音した音声を音声コーデック８０を介してディジタル音声データに変換し、これを多重分離部７７に供給する。そして、携帯電話端末機１０は、画像エンコーダ７３から供給された符号化画像データと音声コーデック８０から供給されたディジタル音声データとに対して、多重分離部７７によって所定の方式で多重化を施し、得られた多重化データを変復調回路部７９及び送受信回路部８１並びにアンテナ５４を介して外部に送信する。

さらにまた、携帯電話端末機１０は、データ通信モード時において例えばウェブサイト等にリンクされた動画像ファイルのデータを受信する場合には、アンテナ５４を介して受信した受信信号に対して、変復調回路部７９によって所定の変調処理を施し、得られた多重化データを多重分離部７７に供給する。続いて、携帯電話端末機１０は、多重分離部７７によって多重化データを符号化画像データとディジタル音声データとに分離し、符号化画像データを画像デコーダ７６に供給するとともに、ディジタル音声データを音声コーデック８０に供給する。そして、携帯電話端末機１０は、画像デコーダ７６によって符号化画像データを所定の符号化方式に対応した復号方式によって伸長復号して再生動画像データを生成し、これを表示制御部７５を介してＬＣＤ５８に供給する。これにより、携帯電話端末機１０は、動画像ファイルに含まれる動画像データをＬＣＤ５８に表示することができる。また、携帯電話端末機１０は、これと同時に、音声コーデック８０によってディジタル音声データをアナログ音声信号に変換してスピーカ５７に供給する。これにより、携帯電話端末機１０は、動画像ファイルに含まれる音声データをスピーカ５７を介して出力することができる。なお、携帯電話端末機１０は、ユーザの操作に応じて、受信した動画像ファイルを記録再生部７８を介して半導体記録媒体６２に記録することも可能である。

さて、このような携帯電話端末機１０は、プログラミング言語として例えばいわゆるＪａｖａ（登録商標）を用いたサービスを提供するアプリケーションプログラムを、上述したプロキシサーバ３０を介して所望のＷＷＷサーバ２０からダウンロードすることにより、各種機能を実現することができる。

ここで、携帯電話端末機１０は、全メモリの容量が少ない、消費電力に限りがある、途切れやすい無線ネットワークに接続されたり帯域幅が限られている何らかのネットワークに接続されたりする、サービスのために最適化されたユーザインターフェースが必要となる、といったように、種々の厳しい制約を有するデバイスである。このような携帯電話端末機１０において動作する各種アプリケーションプログラムとしては、株式会社ＮＴＴドコモが提供するサービスであるｉモード対応Ｊａｖａコンテンツ（通称、ｉアプリ（登録商標））等がある。なお、以下では、説明の便宜上、携帯電話端末機１０は、このｉモード対応Ｊａｖａコンテンツを適用するものとし、このｉモード対応Ｊａｖａコンテンツに対応するアプリケーションプログラムをプロキシサーバ３０を介してダウンロードするものとする。

携帯電話端末機１０におけるアプリケーション環境は、例えば図４に示すように、オペレーティングシステム１０１の上層に、当該携帯電話端末機１０のネィティブアプリケーション１０２とのインターフェースであるネィティブアプリケーションインターフェース１０３が構築され、このネィティブアプリケーションインターフェース１０３の上層に、ＣＬＤＣ（Connected, Limited Device Configuration）クラスライブラリ１０５、Ｊａｖａ拡張ライブラリ１０６、及びメーカ拡張ライブラリ１０７からなるバーチャルマシン１０４が構築され、さらに、ネィティブアプリケーション１０２とバーチャルマシン１０４とがＪａｖａアプリケーションマネージャ（以下、ＪＡＭという。）１０８を介して接続されて構成される。また、携帯電話端末機１０におけるアプリケーション環境は、これらと独立して、ＪＡＲ（Java Archive）ストレージ１０９、及びスクラッチパッド（Scratch Pad）と称されるデータストレージ１１０が構築されて構成される。

携帯電話端末機１０においては、通常の電話やブラウザベースのｉモードサービスについては、オペレーティングシステム１０１及びネィティブアプリケーション１０２を用いて行われる。

バーチャルマシン１０４は、携帯電話端末機１０のように資源等に制約があるデバイス向けに設計されたコンパクトで移植性の高いＪａｖａバーチャルマシンである。バーチャルマシン１０４は、３つのアプリケーションプログラムインターフェース（Application Program Interface；以下、ＡＰＩという。）、すなわち、ＣＬＤＣクラスライブラリ１０５、Ｊａｖａ拡張ライブラリ１０６、及びメーカ拡張ライブラリ１０７から構成される。

ＣＬＤＣクラスライブラリ１０５は、いわゆるＪ２ＳＥ（Java 2 Standard Edition）から継承されたサブセットクラスを含み、上位エディションのＪａｖａ実行環境に含まれる機能の多くを共有するものの、携帯電話端末機１０のような小型デバイスの要件を満足するように、小型デバイスの制約にあわせて最適化されたものである。

Ｊａｖａ拡張ライブラリ１０６は、ＣＬＤＣクラスライブラリ１０５が小型組み込みデバイスで共有して使用可能なアプリケーション基盤を提供するのに対して、ＣＬＤＣクラスライブラリ１０５を土台として、Ｊａｖａ対応ｉモードサービスに特化したアプリケーション基盤を提供する。このＪａｖａ拡張ライブラリ１０６は、ユーザインターフェースを定義するコンポーネントであるユーザインターフェース１０６_１、いわゆるＨＴＴＰ（HyperText Transfer Protocol）やＨＴＴＰＳ（Secure HTTP）によるネットワーク接続を行うネットワーキング／外部入出力１０６_２、アプリケーションデータの保存に用いるローカルな記憶装置モデルであるスクラッチパッド１０６_３、及びシフトＪＩＳ（Japan Industrial Standard）コードへのテキスト変換処理を行うテキスト変換１０６_４の４つのＡＰＩに分類される。

メーカ拡張ライブラリ１０７は、携帯電話端末機１０の製造業者が当該携帯電話端末機１０の機種に備えられる特殊機能をサポートするために提供する独自の拡張ＡＰＩである。

ＪＡＭ１０８は、ＪＡＲファイルとしてインストールされて格納されている個々のＪａｖａアプリケーションの管理やバーチャルマシンとの通信を行う。具体的には、ＪＡＭ１０８は、格納されているＪａｖａアプリケーションのリスト表示、Ｊａｖａアプリケーションの起動や強制終了といった実行管理、Ｊａｖａアプリケーションのインストール又は更新、及びユーザの明示的な指示に基づく既存のＪａｖａアプリケーションの削除を行う。ＪＡＭ１０８は、バーチャルマシン１０４から独立して構築されるコンポーネントであり、アプリケーションから制御することは不可能とされるものである。

ＪＡＲストレージ１０９は、ＪＡＭ１０８によって割り当てられたＪＡＲファイルを保存するメモリ上の記憶領域である。ここで、ＪＡＲは、アプリケーションプログラムを構成するクラスファイルとリソースファイルとを圧縮形式で格納するための標準のＪａｖａアーカイブ機能である。ＪＡＲファイルにおいては、当該ＪＡＲファイルに含まれる内容によって圧縮率は変動するものの、アプリケーションファイルの容量が約４０％乃至５０％削減される。これにより、携帯電話端末機１０においては、必要なアプリケーション保管容量が減るだけでなく、アプリケーションプログラムのダウンロード時間も少なくなる。ＪＡＲファイルにパッケージングされた個々のファイルは、必要に応じて、ＪＡＭ１０８によってアンパックされる。

データストレージ１１０は、スクラッチパッドとも称され、ＪＡＭ１０８によって割り当てられたメモリ上のローカルな記憶領域である。データストレージ１１０は、アプリケーションプログラムの終了後も保持され続けるデータである永続データを確保する記憶領域である。ＪＡＭ１０８によって個々のアプリケーションプログラム用に個別に割り当てられたデータストレージ１１０の領域は、他のアプリケーションプログラムからはアクセスすることができないものとされる。

このようなアプリケーション環境から構成される携帯電話端末機１０は、所望のウェブサイトへのアクセスを希望する場合や、所望のアプリケーションプログラムのダウンロードを希望する場合等、所望のコンテンツを格納するＷＷＷサーバ２０に対してアクセスする必要がある場合には、プロキシサーバ３０に対してアクセスし、このプロキシサーバ３０によるコンテンツの配信代行により、当該コンテンツを享受することになる。

さて、以下では、このような携帯電話端末機１０を備える通信システムについて詳細に説明するものとする。

本発明の実施の形態として示す通信システムは、従来であれば携帯電話端末機１０によって行っていた負荷の高い処理をプロキシサーバ３０によって行わせて処理の負荷を分散させるようなプラットフォームを提供することを基本的な思想とし、これにより、携帯電話端末機１０のアプリケーション環境においても高機能のアプリケーションの実現を図るものである。

まず、ブラウジングの際のプロキシサーバ３０と携帯電話端末機１０との連携処理について説明する。なお、以下では、説明の便宜上、ＷＷＷサーバ２０は、コンテンツとしてＨＴＭＬ文書を提供するものとする。

通常、プロキシサーバは、コンテンツの配信代行を行うものであることから、携帯電話端末機からＨＴＭＬ文書の閲覧リクエストがあると、当該ＨＴＭＬ文書を格納する外部のＷＷＷサーバから当該ＨＴＭＬ文書を取得し、このＨＴＭＬ文書を当該携帯電話端末機に対して送信するものとして構成される。したがって、携帯電話端末機は、図４に示したようなアプリケーション環境を用いて受信したＨＴＭＬ文書を解析するという高度な処理を行う必要があることから、これを行うためのＪａｖａプログラムの容量が大きくなるとともに、通信速度の高速化を妨げる要因となっていた。

そこで、本発明の実施の形態として示す通信システムにおいては、このような高度な処理についてはプロキシサーバ３０によって行い、携帯電話端末機１０においては最終的にコンテンツを表示するために必要な処理を行うことにより、これらの問題の解決を図る。具体的には、通信システムにおいては、図５に示すように、携帯電話端末機１０によって行う処理とプロキシサーバ３０によって行う処理とを分担する。

すなわち、プロキシサーバ３０は、携帯電話端末機１０からのＨＴＭＬ文書ＤＯＣの閲覧リクエストに応じて当該ＨＴＭＬ文書ＤＯＣを格納するＵＲＬ（Uniform Resource Locator）を復号するＵＲＬ復号部１５１と、ＨＴＴＰプロトコルにしたがって当該ＨＴＭＬ文書ＤＯＣを格納するＷＷＷサーバ２０と通信を行うＨＴＴＰクライアントを実行して当該ＨＴＭＬ文書ＤＯＣを取得するＨＴＴＰクライアント処理部１５２と、このＨＴＴＰクライアント処理部１５２によって取得したＨＴＭＬ文書ＤＯＣを解析するＨＴＭＬ解析部１５３とを備える。なお、ＨＴＭＬ解析部１５３は、ＨＴＴＰクライアント処理部１５２によって取得したＨＴＭＬ文書ＤＯＣを構成する字句を解析する字句解析部１５４と、当該ＨＴＭＬ文書ＤＯＣの構文を解析する構文解析部１５５とに大別され、構文解析部１５５は、当該ＨＴＭＬ文書ＤＯＣのデータ形式をプログラムが想定している正しい形式の状態である正規化状態に修復する正規化修復部１５６と、ＵＲＬを圧縮するＵＲＬ圧縮部１５７とからなる。

一方、携帯電話端末機１０は、Ｊａｖａプログラムの機能として、ＨＴＭＬ文書ＤＯＣの木構造の組み立てを行う木構造組立部１５８と、この木構造組立部１５８によって組み立てられたＨＴＭＬ木構造ファイルＴＲに基づいて表示の際のレイアウト処理を行うレイアウト処理部１５９と、上述した表示画面としてのＬＣＤ５８に表示させる表示処理部１６０とを備える。

このような通信システムにおいては、プロキシサーバ３０が携帯電話端末機１０から送信されたＨＴＭＬ文書ＤＯＣの閲覧リクエストを受信すると、ＵＲＬ復号部１５１によってリクエストに含まれるＵＲＬを復号し、アクセスすべきＵＲＬを復元する。そして、プロキシサーバ３０は、ＨＴＴＰクライアント処理部１５２によって復号したＵＲＬに該当するＷＷＷサーバ２０に対してアクセスして当該ＨＴＭＬ文書ＤＯＣを取得し、ＨＴＭＬ解析部１５３によって当該ＨＴＭＬ文書ＤＯＣの字句及び構文の解析を行う。

ここで、ＷＷＷサーバから取得したＨＴＭＬ文書は、作成者がタグを付け忘れたり、誤った文字を入力したりすることにより、正規化状態にないことが通常である。そして、従来においては、このような正規化状態にないＨＴＭＬ文書については、そのまま携帯電話端末機によってエラー表示をさせるのではなく、当該携帯電話端末機によって正規化修復処理を行い、可能な限り最善の状態での表示を行うのが通常である。

これに対して、通信システムにおいては、プロキシサーバ３０に正規化修復部１５６を設けることにより、当該プロキシサーバ３０によって正規化修復処理を行う。具体的には、プロキシサーバ３０は、図６に示すように、ＨＴＭＬ文書ＤＯＣの構文解析の結果検知した開始タグをスタックに入れ、この開始タグに対応する閉じタグを検知した場合には、当該開始タグをスタックから除去していくことによって未だ閉じていないタグのスタックを形成することにより、開始タグ及び閉じタグのそれぞれについての異常を検知して正規化処理を行い、正常な順序で開始タグ及び閉じタグを出力することにより、正規化修復処理を行う。

ここで、このような正規化修復処理についてより具体的に説明するために、タグの属性として、閉じタグを有しないタグ、すなわち、子要素を有さずに自動的に閉じるタグである閉じタグ必須と、子要素を有しないタグである空要素タグと、不正なタグではないが未対応であるためにスキップすべきタグである未対応タグと、対応するＨＴＭＬの仕様で定義されていない不正なタグである未定義タグと、同一タグがネストしないはずのタグであるネストタグと、ＨＴＭＬ文書の中で一度しか出現しないはずのタグであるワンスタグとを定義する。

このような定義のもと、プロキシサーバ３０は、開始タグについては、以下のような処理を行う。すなわち、プロキシサーバ３０は、未定義タグを検知した場合には、当該未定義タグをスキップする。また、プロキシサーバ３０は、スタックを形成するタグのうち最上位に位置するタグであるスタックトップタグが空要素タグであるにもかかわらず閉じないで次のタグが検知された場合には、当該スタックトップタグを強制的に閉じて出力する。さらに、プロキシサーバ３０は、ネストできないタグがネストしている場合には、具体的なタグに応じて処理を変化させる。具体的には、プロキシサーバ３０は、タグ＜ｂｏｄｙ＞やタグ＜ａ＞がネストしている場合には、不正とみなしてネストしている元のタグを強制的に閉じる。また、プロキシサーバ３０は、タグ＜ｆｏｒｍ＞がネストしている場合には、当該タグ＜ｆｏｒｍ＞をスキップし、タグ＜ｈｅａｄ＞やタグ＜ｈｔｍｌ＞がネストしている場合には、未対応タグであることから無視する。さらにまた、プロキシサーバ３０は、ワンスタグが二度以上出現した場合にも、具体的なタグに応じて処理を変化させる。具体的には、プロキシサーバ３０は、タグ＜ｔｉｔｌｅ＞が二度以上出現した場合には、当該タグ＜ｔｉｔｌｅ＞をスキップし、タグ＜ｂｏｄｙ＞が二度以上出現した場合には、それ以後の出力を停止し、タグ＜ｈｔｍｌ＞やタグ＜ｈｅａｄ＞が二度以上出現した場合には、未対応タグであることから無視する。

一方、プロキシサーバ３０は、閉じタグについては、以下のような処理を行う。すなわち、プロキシサーバ３０は、未定義タグや閉じタグ必須を検知した場合には、当該未定義タグや当該閉じタグをスキップする。また、プロキシサーバ３０は、閉じタグ必須を検知した場合には、当該閉じタグをスキップする。

通信システムにおいては、プロキシサーバ３０によってこのような正規化修復処理を行うと、ＵＲＬ圧縮部１５７によってＵＲＬを当該ＵＲＬを識別する識別子であるＵＲＬＩＤに圧縮し、ＨＴＭＬ文書ＤＯＣの木構造を組み立てるのに必要な最低限のイベントＳＴのみを携帯電話端末機１０に対して送信する。これに応じて、携帯電話端末機１０は、Ｊａｖａプログラムを実行し、木構造組立部１５８によってＨＴＭＬ文書ＤＯＣの木構造の組み立てを行い、この木構造組立部１５８によって組み立てられたＨＴＭＬ木構造ファイルＴＲに基づいて表示の際のレイアウト処理をレイアウト処理部１５９によって行い、表示処理部１６０を介してＬＣＤ５８に表示する。

このように、通信システムにおいては、ＨＴＭＬ文書ＤＯＣの解析という高度な処理をプロキシサーバ３０によって行うことにより、携帯電話端末機１０が実行するＪａｖａプログラムの容量の削減及び処理の高速化を図ることができる。また、通信システムにおいては、ＨＴＭＬ文書ＤＯＣの木構造を組み立てるのに必要な最低限のイベントＳＴのみをプロキシサーバ３０から携帯電話端末機１０に対して送信することにより、通信速度の高速化を図ることができるとともに、パケット通信網ＮＴ_１を通過するパケット数の削減による通信費の低減を図ることができる。

つぎに、パケット通信網を提供する携帯電話会社が公認するウェブサイトであるいわゆる公式サイト用のユーザＩＤの取得について説明する。

通常、公式サイトにおいては、会員ユーザが購読しているか否かを管理するために、携帯電話会社が発行したユーザＩＤを用いる必要がある。このユーザＩＤは、携帯電話端末機が公式サイトを形成するＨＴＭＬ文書の閲覧リクエストを行った際に、パケット通信網にて付与される。

ここで、上述したように、プロキシサーバ３０によってＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣを解析して得られたＵＲＬをＵＲＬＩＤに圧縮して携帯電話端末機１０に対して受け渡すような通信システムにおいては、携帯電話端末機１０から公式サイトに対してアクセスするためにプロキシサーバ３０に対してリクエストを行う際にも、ＵＲＬＩＤを用いることになる。したがって、通信システムにおいては、図７に示すように、ユーザＩＤをＵＩＤと表すものとすると、"＜ＵＲＬＩＤ＞？ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"といったように、パケット通信網ＮＴ_１にてユーザＩＤがＵＲＬＩＤに付加される必要があり、このユーザＩＤが付加されたＵＲＬＩＤをプロキシサーバ３０によって"＜ＵＲＬＩＤ＞？ＵＩＤ＝＜ＵｓｅｒＩＤ＞"といった圧縮された形式でＵＲＬを認識することにより、ＷＷＷサーバ２０から該当するＨＴＭＬ文書ＤＯＣを取得することが必要となる。

しかしながら、通信システムにおいては、プロキシサーバ３０によってＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣを解析して得られたＵＲＬを単純にＵＲＬＩＤに圧縮して携帯電話端末機１０に対して受け渡す場合には、ＵＲＬＩＤに"ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"といったユーザＩＤを具体的に識別する記述が含まれないことから、このＵＲＬＩＤに基づいて、携帯電話端末機１０が公式サイトを形成するＨＴＭＬ文書ＤＯＣの閲覧リクエストを行った際に、ユーザＩＤがＵＲＬＩＤに付加されない事態を招来する。

このような問題を解決するためには、プロキシサーバ３０にユーザ毎のユーザＩＤを格納するデータベースを設けることが考えられるが、処理の負荷が高くなるという別の問題が発生する。

そこで、通信システムにおいては、プロキシサーバ３０によってＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣを解析して得られたＵＲＬをＵＲＬＩＤに圧縮して携帯電話端末機１０に対して受け渡す際に、以下のような工夫を取り入れる。

すなわち、通信システムにおいては、プロキシサーバ３０がＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣをＨＴＭＬ解析部１５３によって解析した結果、ＵＲＬに"ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"といったユーザＩＤを具体的に識別する記述が含まれていることを検知した場合には、ＵＲＬ圧縮部１５７によってＵＲＬをＵＲＬＩＤに圧縮する際に、"＜ＵＲＬＩＤ＞？ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"といったように、検知したユーザＩＤを付加したＵＲＬＩＤに変換し、携帯電話端末機１０に対して送信するようにする。

これにより、携帯電話端末機１０は、公式サイトを形成するＨＴＭＬ文書ＤＯＣの閲覧リクエストを行う際に、プロキシサーバ３０から送信された"＜ＵＲＬＩＤ＞？ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"をパケット通信網ＮＴ_１に供給することができる。

なお、通信システムにおいては、プロキシサーバ３０がＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣをＨＴＭＬ解析部１５３によって解析した結果、ＵＲＬに"ＵＩＤ＝ＮＵＬＬＧＷ＊＊＊＊＊"といったユーザＩＤを具体的に識別する記述が含まれていないことを検知した場合には、当該ＨＴＭＬ文書ＤＯＣによって形成されるウェブサイトはユーザＩＤを必要としない公式サイト以外のものであることから、ＵＲＬ圧縮部１５７によってＵＲＬを"＜ＵＲＬＩＤ＞"といった形式に圧縮し、携帯電話端末機１０に対して送信すればよい。

このように、通信システムにおいては、プロキシサーバ３０によってＷＷＷサーバ２０から取得したＨＴＭＬ文書ＤＯＣを解析して得られたＵＲＬをＵＲＬＩＤに圧縮して携帯電話端末機１０に対して受け渡す際に、ユーザＩＤを付加したＵＲＬＩＤに変換することにより、ユーザＩＤをパケット通信網ＮＴ_１に供給することができ、会員ユーザの管理を何ら支障なく行うことが可能となる。

つぎに、ＨＴＭＬ文書と当該ＨＴＭＬ文書が参照する画像ファイルとをダウンロードする際の高速化の手法について説明する。

従来、所定のＷＷＷサーバに格納されているＨＴＭＬ文書と当該ＨＴＭＬ文書が参照する画像ファイルとをダウンロードする際には、図８に示すように、携帯電話端末機がプロキシサーバを検索して接続してリクエストを行うのに応じて、プロキシサーバがＷＷＷサーバを検索して接続し、当該ＷＷＷサーバからＨＴＭＬ文書をダウンロードした後、当該ＷＷＷサーバとの接続を切断することにより、ＨＴＭＬ文書を当該プロキシサーバが格納する。そして、携帯電話端末機は、プロキシサーバからＨＴＭＬ文書をダウンロードした後、当該プロキシサーバとの接続を切断することにより、ＨＴＭＬ文書を取得する。

その後、携帯電話端末機は、ダウンロードしたＨＴＭＬ文書を解析し、参照する画像ファイルのＵＲＬを示す一覧リストを取得すると、このＵＲＬに基づいて、プロキシサーバを検索して接続してリクエストを行う。これに応じて、プロキシサーバは、ＷＷＷサーバを検索して接続し、当該ＷＷＷサーバから画像ファイルをダウンロードした後、当該ＷＷＷサーバとの接続を切断することにより、画像ファイルを当該プロキシサーバが格納する。そして、携帯電話端末機は、プロキシサーバから画像ファイルをダウンロードした後、当該プロキシサーバとの接続を切断する、という処理を取得すべき画像ファイルの数だけ繰り返し行うことにより、必要な画像ファイルを取得する。

すなわち、従来のシステムにおいては、携帯電話端末機とプロキシサーバとの間での接続と切断とを繰り返し行うことにより、ＨＴＭＬ文書と画像ファイルとのダウンロードが行われていた。

ここで、パケット通信網を介した携帯電話端末機の通信速度は遅いことから、このように携帯電話端末機とプロキシサーバとの接続及び切断を繰り返し行うことによって細切れにデータをダウンロードするシステムにおいては、同図中斜線部で示すように、プロキシサーバを検索して接続し、当該プロキシサーバからデータをダウンロードする、という負荷の高い処理を携帯電話端末機が繰り返し行うことになり、処理の低速化を招来することになる。

そこで、本発明の実施の形態として示す通信システムにおいては、上述したように、プロキシサーバ３０によってＨＴＭＬ文書ＤＯＣを解析することを利用し、携帯電話端末機１０とプロキシサーバ３０との間での接続及び切断の回数を最小限に抑制する。

具体的には、通信システムにおいては、図９に示すように、携帯電話端末機１０がプロキシサーバ３０を検索して接続してリクエストを行うのに応じて、プロキシサーバ３０がＷＷＷサーバ２０を検索して接続し、当該ＷＷＷサーバ２０からＨＴＭＬ文書ＤＯＣをダウンロードした後、当該ＷＷＷサーバ２０との接続を切断することにより、ＨＴＭＬ文書ＤＯＣを当該プロキシサーバ３０が格納する。続いて、プロキシサーバ３０は、ダウンロードしたＨＴＭＬ文書を解析し、参照する画像ファイルのＵＲＬを示す一覧リストを取得すると、このＵＲＬに基づいて、ＷＷＷサーバ２０を検索して接続し、当該ＷＷＷサーバ２０から画像ファイルＩＭをダウンロードした後、当該ＷＷＷサーバ２０との接続を切断する、という処理を取得すべき画像ファイルの数だけ繰り返し行う。そして、プロキシサーバ３０は、取得したＨＴＭＬ文書ＤＯＣと画像ファイルＩＭとをアーカイブする。

その後、携帯電話端末機１０は、プロキシサーバ３０からアーカイブされたデータをダウンロードした後、当該プロキシサーバ３０との接続を切断することにより、アーカイブされたデータを取得する。そして、携帯電話端末機１０は、アーカイブされたデータからＨＴＭＬ文書ＤＯＣと画像ファイルＩＭとを分離抽出する。

すなわち、通信システムにおいては、携帯電話端末機１０とプロキシサーバ３０との間での接続及び切断の回数が１回で済むことになる。したがって、通信システムにおいては、同図中斜線部で示すように、プロキシサーバ３０を検索して接続し、当該プロキシサーバ３０からデータをダウンロードする、という負荷の高い処理を１回で済ませることができる。

このように、通信システムにおいては、プロキシサーバ３０によってＨＴＭＬ文書ＤＯＣを解析することを利用し、ＨＴＭＬ文書ＤＯＣと画像ファイルＩＭとを一括取得することにより、携帯電話端末機１０とプロキシサーバ３０との間での接続及び切断の回数を最小限に抑制することができ、処理の高速化を図ることができる。

つぎに、容量が制限された通信環境にて透過的に無制限の容量の通信を行う手法について説明する。

パケット通信網は、通常、アップロード又はダウンロードできる容量に例えば１０ｋバイトといった制限がある。そのため、従来のシステムにおいては、制限以上の容量のデータを送受信する場合には、図１０(ａ)に概念を示すように、データを分割し、分割のシーケンス毎に、同図中黒丸で示すようにファンクションを埋め込んで送受信せざるを得ない。例えば、従来のシステムにおいては、１０ｋバイトの制限があるパケット通信網を介して１００ｋバイトからなる１０００件のアドレス帳を送受信する場合には、トランザクションを制御するシステムによって１００件毎にアドレス帳を分割して送受信を行う必要がある。

このような環境においては、コンテンツの作成者にとって、送受信するデータに応じてサーバ側とクライアント側との関係を考慮したシステムを構築する必要があり、極めて労力を要するという問題があった。また、アップロード又はダウンロードできる容量は、アプリケーションのバージョンやキャリアに応じて異なることが通常であることから、プラットフォームの移行も極めて困難となる。

そこで、本発明の実施の形態として示す通信システムにおいては、図１０(ｂ)に概念を示すように、分割したデータを同図中黒丸で示す１つのライブラリを介して通信を行うことにより、アプリケーション側からみて仮想的に制限以上の容量のデータを送受信できるような仕組みを設ける。具体的には、通信システムにおいては、図１１に示すように、携帯電話端末機１０とプロキシサーバ３０との間でデータの送受信を行う際のライブラリＬを１つのレイヤとして構築する。

このような通信システムにおいては、携帯電話端末機１０からＷＷＷサーバ２０に対して制限以上の容量のデータをアップロードする場合には、携帯電話端末機１０によってセッションキーを発行し、アップロードデータを送信可能な容量に分割する。続いて、通信システムにおいては、携帯電話端末１０とプロキシサーバ３０との間で、分割したデータ毎にセッションキーとＡＣＫ（ACKnowledgement）との授受を行うことによってセッションを確立し、携帯電話端末機１０からプロキシサーバ３０に対してパケット通信網ＮＴ_１を介して当該データを送信する。このとき、プロキシサーバ３０は、セッション毎にキャッシュを生成し、所定のアップロードキャッシュに追記する。そして、通信システムにおいては、携帯電話端末機１０からプロキシサーバ３０に対する全てのデータの送信が完了すると、プロキシサーバ３０によってアップロードデータを復元し、アップロードすべきＷＷＷサーバ２０に対してＨＴＴＰリクエストを行い、インターネット網ＮＴ_２を介してアップロードデータを送信する。

一方、通信システムにおいては、ＷＷＷサーバ２０に格納されている制限以上の容量のデータを携帯電話端末機１０に対してダウンロードする場合には、プロキシサーバ３０からＷＷＷサーバ２０に対してＨＴＴＰリクエストを行うことにより、インターネット網ＮＴ_２を介してプロキシサーバ３０がダウンロードデータを取得し、所定のダウンロードキャッシュに格納する。続いて、通信システムにおいては、プロキシサーバ３０がキャッシュから送信可能な容量のデータを読み出すことによってダウンロードデータを分割した上で、携帯電話端末１０とプロキシサーバ３０との間で分割したデータ毎にセッションを確立し、プロキシサーバ３０から携帯電話端末機１０に対してパケット通信網ＮＴ_１を介して当該データを送信する。そして、通信システムにおいては、プロキシサーバ３０から携帯電話端末機１０に対する全てのデータの送信が完了すると、携帯電話端末機１０によってダウンロードデータを復元する。

このように、通信システムにおいては、携帯電話端末機１０とプロキシサーバ３０との間でデータの送受信を行う際のライブラリＬを１つのレイヤとして構築することにより、アプリケーション側からみて仮想的に制限以上の容量のデータを送受信できるような仕組みを構築することができ、アプリケーションの制限がなくなり、また、プラットフォームを移行もライブラリＬの変更のみに集約することができることから極めて容易となる。

以上のように、通信システムにおいては、従来であれば携帯電話端末機１０によって行っていた負荷の高い処理をプロキシサーバ３０によって行わせて処理の負荷を分散させるとともに、上述した各種新たな仕組みを備えたプラットフォームを提供することにより、携帯電話端末機１０のアプリケーション環境においても高機能のアプリケーションの実現を図ることができる。

以下、このような通信システムによって提供されるアプリケーション環境において実現することができる高機能のアプリケーションプログラムの例について説明する。

このアプリケーションプログラムは、携帯電話端末機１０で実行可能なブラウザとメーラとを統合したソフトウェアであり、当該アプリケーションプログラムを待ち受け画面として待機させたまま、電話の発着信や電子メールの送受信といった所定のサービスを利用することができるいわゆる待ち受けアプリとして提供されるものである。このアプリケーションプログラムは、上述した通信システムの仕組みを利用することによってはじめて実現可能となったものである。

ここで、このアプリケーションプログラムの説明に先だって、携帯電話端末機１０によってアプリケーションプログラムをダウンロードして実行する際の一般的な過程について説明する。

携帯電話端末機１０は、このようなアプリケーションプログラムを実行するために、ＷＷＷサーバ２０から当該アプリケーションプログラムをダウンロードしてインストールする必要がある。携帯電話端末機１０においては、アプリケーションプログラムがダウンロードされると、このアプリケーションプログラムを保存するために必要な記憶領域を、先に図４に示したＪＡＭ１０８によって割り当て、ＪＡＲファイルとアプリケーションのスクラッチパッドとを、ともに図示しないメモリに格納する。

具体的には、携帯電話端末機１０においては、通常、ＷＷＷサーバ２０からアプリケーションプログラムをダウンロードする際には、ユーザによって上述したＬＣＤ５８に所定のブラウザを表示し、ユーザによるこのブラウザの操作を契機として開始される。携帯電話端末機１０においては、ダウンロードを行うためのウェブサイトには、通常、アプリケーションプログラムの説明文や、ダウンロードを開始するために選択するリンクが表示される。リンクには、アプリケーションプログラムに関する各種設定情報を記述したＪＡＭファイルとも称されるアプリケーションディスクリプタファイル（Application Descriptor File；ＡＤＦ）への参照が含まれる。

ここで、この設定ファイルであるＪＡＭファイルは、シフトＪＩＳコードのテキストファイルであり、アプリケーション情報を表すキーと値との対が１行ずつ記述されたものである。具体的には、ＪＡＭファイルには、最大１６バイトでアプリケーションプログラムの名称を記述する必須キーである"AppName"、アプリケーションプログラムのバージョンを記述するオプショナルキーである"AppVer"、最大２５５バイトでＪＡＲファイルの位置情報であるＵＲＬ（Uniform Resource Locator）を記述する必須キーである"PackageURL"、バイト単位の整数値でＪＡＲファイルの容量を記述する必須キーである"AppSize"、アプリケーションプログラムの起動に用いられるメインクラスの名称を記述する必須キーである"AppClass"、メインクラスの起動パラメータを記述するオプショナルキーである"AppParam"、バーチャルマシンのバージョンを記述するオプショナルキーである"KvmVer"、バイト単位の整数値でスクラッチパッドの容量を記述するオプショナルキーである"SPsize"、アプリケーションプログラムの最終変更日時をＪＳＴ（Japan Standard Time）で記述する必須キーである"LastModified"、ネットワーク機能を使用する場合に通信方式を指定するオプショナルキーである"UseNetwork"、ターゲットとする携帯電話端末機の機種名を指定するオプショナルキーである"TargetDevice"、及びアプリケーションプログラムに自動起動を行わせる場合にその起動タイミングを指定するオプショナルキーである"LaunchAt"といった、各種キーのエントリが指定される。このＪＡＭファイルは、アプリケーションプログラムのダウンロードの開始前に、選択されたアプリケーションプログラムを正確にダウンロード及び実行することが可能であるか否かをＪＡＭによって判定するために用いられる。

携帯電話端末機１０は、ユーザによってリンクが選択されるのに応じて、アプリケーションプログラムのインストールプロセスを開始する。すなわち、携帯電話端末機１０は、ユーザによるリンクの選択に応じて、ブラウザからＪＡＭ１０８に対してＪＡＭファイルが存在する位置を示すＵＲＬが渡され、以降、アプリケーションプログラムのダウンロード及びインストールをＪＡＭ１０８の制御のもとに行う。携帯電話端末機１０は、ＪＡＭ１０８によってＪＡＭファイルの内容を検査し、アプリケーションプログラムのインストールの可否を確認する。すなわち、携帯電話端末機１０は、ＪＡＭ１０８の制御のもとに、指定されたＪＡＭファイルに全ての必須キーが指定されているか否かを検査し、このＪＡＭファイルの記述内容、すなわち、アプリケーションプログラムの容量、スクラッチパッドの容量、アプリケーションプログラムがターゲットとする機種情報等に基づいて、そのアプリケーションプログラムをインストールすることが可能であるか否かを判定する。なお、携帯電話端末機１０においては、ＪＡＭファイルにおける"AppName"キーに記述されたインストールしようとするアプリケーションプログラムと同一の名称を有するアプリケーションプログラム、及びＪＡＭファイルにおける"PackageURL"キーに記述されたＪＡＲファイルのＵＲＬを有するアプリケーションプログラムが、既にインストールされている場合には、そのアプリケーションプログラムは同一とみなされ、通常であればインストールすることができないものとされる。

そして、携帯電話端末機１０は、ＪＡＭ１０８による検査の結果、アプリケーションプログラムをインストールすることが可能であるものと判定した場合には、ＪＡＭ１０８によってアプリケーションプログラムをダウンロードする。すなわち、携帯電話端末機１０は、ＪＡＭ１０８によってＪＡＭファイルにおける"PackageURL"キーを用いてＪＡＲファイルのＵＲＬを入手し、ダウンロードプロセスを開始する。なお、携帯電話端末機１０は、ダウンロードプロセス中にユーザによる中断指示や通信エラーが発生した場合には、ＪＡＭ１０８によってダウンロード中のアプリケーションプログラムを破棄し、ダウンロードが行われる前の状態に戻す。そして、携帯電話端末機１０は、ＪＡＭ１０８によってインストール済みのアプリケーションプログラムのリストにダウンロードしたアプリケーションプログラムを追加することにより、当該リストを更新し、ＪＡＭファイルの情報とアプリケーションプログラムのＪＡＲファイルとをメモリ上に保存し、一連の処理を終了する。

携帯電話端末機１０は、このような一連の処理を経ることにより、ＷＷＷサーバ２０からアプリケーションプログラムをダウンロードすることができる。インストールされたアプリケーションプログラムは、ユーザの嗜好に応じて起動することが可能とされる。携帯電話端末機１０においては、ダウンロードしてインストールしたアプリケーションプログラムを起動する際には、通常、ユーザの指示に応じて、インストール済みのアプリケーションプログラムのリストをＪＡＭ１０８の制御のもとにＬＣＤ５８に表示し、ユーザによって当該リストから起動するアプリケーションプログラムを選択する。そして、携帯電話端末機１０は、ＪＡＭ１０８によってＪＡＭファイルにおける"AppClass"キーで示されるアプリケーションプログラムのメインクラス名を指定して、バーチャルマシン１０４を起動して当該アプリケーションプログラムを実行し、ＬＣＤ５８に当該アプリケーションプログラムの画面を表示することになる。

ここで、通信システムにおいては、高機能のアプリケーションプログラムを実現するために、上述した各種仕組みを利用するのは勿論のこと、当該アプリケーションプログラムの構造にも工夫を取り入れている。すなわち、通信システムにおいては、アプリケーションプログラムをロジック部分と非ロジック部分とに分割することにより、容量の小さい携帯電話端末機１０用にプログラムとして利用できる領域を増加させる。

具体的には、通信システムにおいては、図１２に示すように、ＪＡＲファイルとして作成されたアプリケーションプログラムが、ロジック部分であるプログラム本体と、非ロジック部分である説明文等のテキストファイル並びに画像ファイル及び音声ファイルとに大別されることに着目し、コンテンツの作成側で、ＪＡＲファイルを所定のプログラムを用いて機械的にロジック部分としてのＪＡＲファイルと非ロジック部分としてのデータアーカイブとに分割した形態で、ＷＷＷサーバ２０において提供するようにする。このとき、ＪＡＲファイルには、所定のアーカイブライブラリが付与される。

そして、通信システムにおいては、携帯電話端末機１０がアプリケーションプログラムをダウンロードする際には、同図では図示しないプロキシサーバ３０を介してＪＡＲファイルのみをダウンロードして上述したＪＡＲストレージ１０９に保存し、バーチャルマシン１０４によってダウンロードしたＪＡＲファイルに付与されているアーカイブライブラリを起動することにより、分割されたデータアーカイブを取得し、データストレージ１１０に保存するようにする。

このように、通信システムにおいては、コンテンツの作成側でアプリケーションプログラムをロジック部分と非ロジック部分とに分割し、携帯電話端末機１０によってロジック部分のみを先にダウンロードすることにより、非ロジック部分の容量だけより大きな容量のアプリケーションプログラムを作成することが可能となることから、高機能のアプリケーションプログラムを実現することができる。

さて、ブラウザとメーラとを統合した待ち受けアプリとして提供される高機能のアプリケーションプログラムは、このような仕組みを利用することによって実現されるものである。以下では、このアプリケーションプログラムの概念を明確化すべく、当該アプリケーションプログラムに基づいて携帯電話端末機１０のＬＣＤ５８に表示される主な画面内容について説明するものとする。

携帯電話端末機１０は、このアプリケーションプログラムをインストールし、待ち受け設定を行うことにより、当該アプリケーションプログラムを利用することが可能となる。アプリケーションプログラムは、待ち受けモード時には、例えば図１３(ａ)に示すような任意の待ち受け画面を携帯電話端末機１０のＬＣＤ５８に表示することができ、この状態で電子メールの着信をスクロールテキストで報知することが可能とされる。そして、アプリケーションプログラムは、携帯電話端末機１０の操作キー５９を構成する所定の活性化キーをユーザが押下することによって活性化されてアプリモードへと移行する。アプリケーションプログラムは、アプリモードに移行すると、所定の音声をスピーカ５７から出力するとともに、ＬＣＤ５８に表示する画面を遷移させ、例えば図１３(ｂ)に示すように、待ち受けモード時に表示されていた待ち受け画面に複数のメニューアイコンが重畳された画面を表示させる。そして、アプリケーションプログラムは、ユーザがこれらメニューアイコンを選択することにより、当該選択されたメニューアイコンに割り当てられたコンテンツを実行することになる。

このように、非活性化時には待ち受け画面として機能するとともに活性化時には所定のコンテンツを実行するアプリケーションプログラムの主な機能としては、まず、ブラウザとメーラとを統合し、携帯電話端末機１０がブラウザを介して所定のＷＷＷサーバ２０から取得した待ち受け画面用の画像ファイルや着信音声用の音声ファイルを、メーラの待ち受け画面や電子メール着信時の音声にも共用することが挙げられる。具体的には、このアプリケーションプログラムは、図１４に示すように、携帯電話端末機１０がブラウザを介して所定のＷＷＷサーバ２０から取得した待ち受け画面用の画像ファイルや着信音声用の音声ファイルを所定の保存領域に保存し、この保存領域をメーラと共用するとともに、メーラとブラウザとの機能も共用することにより、この機能を実現することができる。

ここで、活性化時に実行することができるコンテンツが割り当てられたメニューアイコンとしては、メーラを起動するメールアイコンと、当該アプリケーションプログラムの起動時及び起動終了時や電子メールの着信時等に出力させる音声を設定する音声設定アイコンと、ブラウザの設定を行うブラウザ設定アイコンと、その他各種設定を行う設定アイコンとの他、例えばニュースや天気情報や所定の占いといった各種コンテンツのウェブサイトにアクセスするためにブラウザを連動起動する各種アイコンが実装される。

アプリケーションプログラムにおいては、これらメニューアイコンのうち、メールアイコンが選択された場合にはメーラが起動され、例えば図１５に示すように、メールサーバに対する新着メールの問い合わせ、電子メールの新規作成及び送受信等の基本的なメール機能の他、メールフォルダやアドレス帳の閲覧や登録、ＰＯＰ（Post Office Protocol）を含む閲覧可能とする複数のメールアカウントの設定等を行うためのメニューを携帯電話端末機１０のＬＣＤ５８に表示させ、これらメニューに応じた機能を実行する。

特に、アプリケーションプログラムは、新着メールの問い合わせを行うことにより、例えば図１６に示すように、新着メールの一覧リストを表示することができるが、この際、本文はダウンロードせずにヘッダのみをダウンロードする。すなわち、従来においては、新着メールを問い合わせた場合には、全ての電子メールのヘッダと本文及び添付ファイルとを一括してダウンロードしていたが、閲覧しなくてもよい電子メールが含まれている場合等には、不必要にパケット数が増加して通信費の高騰を招来していた。

そこで、このアプリケーションプログラムは、図１７に示すように、携帯電話端末機１０がメーラを介して所定のＷＷＷサーバ２０から、例えば、日付、件名、差出人アドレス（Ｆｒｏｍ）、宛先アドレス（Ｔｏ）、メールＩＤ、添付ファイル名といったヘッダ情報からなる新着メールの一覧リストを取得する。そして、このアプリケーションプログラムは、ユーザが本文の閲覧を希望したメール本文をページ毎に分割し、必要なページのみを受信するとともに、必要な添付ファイルをダウンロードすることにより、通信量を最小限に削減することができる極めて効率のよいメーラの機能を実現することができる。

なお、アプリケーションプログラムは、受信した電子メールやウェブサイト等を携帯電話端末機１０のＬＣＤ５８に表示させ、画面範囲を超過する分についてはスクロールさせることができるが、この際、図１８(ａ)中斜線部で示すように、操作キー５９を構成するカーソル上下キーを用いて１行分乃至数行分程度スクロールさせるのみならず、図１８(ｂ)中斜線部で示すように、＊キーを押下することによって上方向に１ページ分スクロールさせるとともに、＃キーを押下することによって下方向に１ページ分スクロールさせる、といったように、携帯電話端末機１０の機種に依存せずにスクロール動作を効率よく行わせることができる。

また、このアプリケーションプログラムは、作成したアドレス帳をプロキシサーバ３０にアップロードすることができ、複数の携帯電話端末機やパーソナルコンピュータ等との間で連動させることができる。具体的には、このアプリケーションプログラムは、図１９に示すように、携帯電話端末機１０に格納されているアドレス帳をバックアップとしてプロキシサーバ３０にパケット通信網ＮＴ_１を介してアップロードし、当該プロキシサーバ３０に確保された所定の保存領域に格納させることができる。そして、このアプリケーションプログラムは、携帯電話端末機１０を紛失した場合や機種変更を行った場合等に、プロキシサーバ３０からアップロードされているアドレス帳を、パケット通信網ＮＴ_１を介して新たな携帯電話端末機１０'にインポートしたり、インターネット網ＮＴ_２に接続されているパーソナルコンピュータＰＣ等にインポートしたりすることができる。

このように、このアプリケーションプログラムは、プロキシサーバ３０を介して複数の携帯電話端末機やパーソナルコンピュータ等との間でアドレス帳を連動させることができることから、最適なアドレス帳のバックアップ手段を提供することができ、携帯電話端末機１０の紛失や機種変更時の手間を格段に省くことができる。

以上詳細に説明したように、本発明の実施の形態として示した通信システムにおいては、従来であれば携帯電話端末機１０によって行っていた負荷の高い処理をプロキシサーバ３０によって行わせて処理の負荷を分散させるとともに、各種新たな仕組みを備えたプラットフォームを提供することにより、極めて厳しい制約のある携帯電話端末機１０のアプリケーション環境においても高機能のアプリケーションを実現することができ、結果として、処理の高速化や通信費の低減をも図ることができる。

なお、本発明は、上述した実施の形態に限定されるものではない。例えば、上述した実施の形態では、アプリケーションプログラムの例として、パケット数の削減を図ることができるブラウザとメーラとを統合したソフトウェアを用いて説明したが、本発明は、上述した通信システムの仕組みを利用することによって実現することができる高機能のアプリケーションプログラムであれば、いかなるものであっても適用することができる。

また、上述した実施の形態では、携帯電話端末機によってＪａｖａアプリケーションを実行するものとし、また、ｉモード対応Ｊａｖａコンテンツを適用するものとして主に説明したが、本発明は、これらに限定されるものではなく、他のプログラミング言語をベースとするアプリケーションや他のサービスを適用してもよい。

このように、本発明は、その趣旨を逸脱しない範囲で適宜変更が可能であることはいうまでもない。

本発明の実施の形態として示す通信システムの構成を説明する図である。 携帯電話端末機の外観構成を説明する斜視図である。 同携帯電話端末機の内部構成を説明するブロック図である。 同携帯電話端末機におけるアプリケーション環境を説明する図である。 同通信システムの構成を説明する図であり、高度な処理についてはプロキシサーバによって行い、携帯電話端末機においては最終的にコンテンツを表示するために必要な処理を行う様子を説明するための図である。 同通信システムにおけるプロキシサーバによって行われる正規化修復処理の内容を説明するための図である。 同通信システムの構成を説明する図であり、プロキシサーバによってＷＷＷサーバから取得したＨＴＭＬ文書を解析して得られたＵＲＬをＵＲＬＩＤに圧縮して携帯電話端末機に対して受け渡す際に、ユーザＩＤを付加したＵＲＬＩＤに変換する様子を説明するための図である。 従来のシステムの構成を説明する図であり、携帯電話端末機とプロキシサーバとの間での接続と切断とを繰り返し行う様子を説明するための図である。 同通信システムの構成を説明する図であり、携帯電話端末機とプロキシサーバとの間での接続及び切断の回数を最小限に抑制する様子を説明するための図である。 従来のシステムにおいて、制限以上の容量のデータを送受信する場合における概念を説明する図である。 同通信システムにおいて、アプリケーション側からみて仮想的に制限以上の容量のデータを送受信できるような仕組みの概念について説明する図である。 同通信システムの構成を説明する図であり、携帯電話端末機とプロキシサーバとの間でデータの送受信を行う際のライブラリを１つのレイヤとして構築する様子を説明するための図である。 同通信システムの構成を説明する図であり、アプリケーションプログラムをロジック部分と非ロジック部分とに分割することにより、容量の小さい携帯電話端末機用にプログラムとして利用できる領域を増加させる様子を説明するための図である。 アプリケーションプログラムが待ち受けモード時である場合において、携帯電話端末機のＬＣＤに表示される画面内容例を説明する図である。 アプリケーションプログラムがアプリモード時である場合において、携帯電話端末機のＬＣＤに表示される画面内容例を説明する図である。 同通信システムの構成を説明する図であり、アプリケーションプログラムの主な機能として、携帯電話端末機がブラウザを介して所定のＷＷＷサーバから取得した待ち受け画面用の画像ファイルや着信音声用の音声ファイルを、メーラの待ち受け画面や電子メール着信時の音声にも共用する様子を説明するための図である。 アプリケーションプログラムにおけるメールアイコンが選択されてメーラが起動した場合において、携帯電話端末機のＬＣＤに表示される画面内容例を説明する図である。 アプリケーションプログラムを実行して新着メールの問い合わせを行った場合において、携帯電話端末機のＬＣＤに表示される画面内容例を説明する図である。 同通信システムの構成を説明する図であり、アプリケーションプログラムを実行して新着メールの問い合わせを行った場合において、ヘッダ情報からなる新着メールの一覧リストを取得する様子を説明するための図である。 携帯電話端末機の正面図であり、カーソル上下キーを用いて表示内容をスクロールさせる様子を説明するための図である。 携帯電話端末機の正面図であり、＊キー及び＃キーを用いて表示内容をスクロールさせる様子を説明するための図である。 同通信システムの構成を説明する図であり、アプリケーションプログラムを実行してプロキシサーバを介して複数の携帯電話端末機やパーソナルコンピュータとの間でアドレス帳を連動させる様子を説明するための図である。

符号の説明

１０，１０_１，１０_２，１０_３，・・・ 携帯電話端末機
２０_１，２０_２，２０_３，・・・ ＷＷＷサーバ
３０ プロキシサーバ
１５１ ＵＲＬ復号部
１５２ ＨＴＴＰクライアント処理部
１５３ ＨＴＭＬ解析部
１５４ 字句解析部
１５５ 構文解析部
１５６ 正規化修復部
１５７ ＵＲＬ圧縮部
１５８ 木構造組立部
１５９ レイアウト処理部
１６０ 表示処理部
ＮＴ_１ パケット通信網
ＮＴ_２ インターネット網

Claims (15)

1. インターネット網を介してデータの授受を行う通信システムであって、
   所定のパケット通信網に対して接続された携帯電話端末機と、
   上記インターネット網に対して接続された各種コンテンツを格納するコンテンツサーバと、
   上記携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされ、上記コンテンツサーバからコンテンツを取得し、上記パケット通信網を介して上記携帯電話端末機に対して配信代行を行うプロキシサーバとを備え、
   上記プロキシサーバは、
   上記携帯電話端末機からの上記コンテンツの閲覧リクエストに応じて当該コンテンツを格納するＵＲＬを復号し、
   当該コンテンツを格納する上記コンテンツサーバと通信を行い、当該コンテンツを取得し、
   取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信し、
   上記携帯電話端末機は、
   上記コンテンツの木構造の組み立てを行い、
   組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行い、所定の表示画面に表示させること
   を特徴とする通信システム。
2. 上記プロキシサーバは、上記ＵＲＬを当該ＵＲＬを識別する識別子であるＵＲＬＩＤに圧縮して上記携帯電話端末機に対して送信し、
   上記携帯電話端末機は、上記コンテンツの閲覧リクエストを行う際にＵＲＬＩＤを上記プロキシサーバに対して送信すること
   を特徴とする請求項１記載の通信システム。
3. 上記プロキシサーバは、上記コンテンツサーバから取得したコンテンツを解析した結果、上記パケット通信網を提供する携帯電話会社が公認するウェブサイトに関する管理を行うために必要な当該携帯電話会社が発行したユーザＩＤを識別する記述がＵＲＬに含まれていることを検知した場合には、ＵＲＬをＵＲＬＩＤに圧縮する際に、検知したユーザＩＤを付加したＵＲＬＩＤに変換し、上記携帯電話端末機に対して送信すること
   を特徴とする請求項２記載の通信システム。
4. 上記プロキシサーバは、
   上記携帯電話端末機からのリクエストに応じて、上記コンテンツサーバを検索して接続し、当該コンテンツサーバからコンテンツをダウンロードした後、当該コンテンツサーバとの接続を切断し、
   上記コンテンツサーバからダウンロードした上記コンテンツを解析し、参照する画像ファイルのＵＲＬを示す一覧リストを取得し、
   取得した上記画像ファイルのＵＲＬに基づいて、当該画像ファイルを格納するコンテンツサーバを検索して接続し、当該コンテンツサーバから画像ファイルをダウンロードした後、当該コンテンツサーバとの接続を切断する処理を、取得すべき画像ファイルの数だけ繰り返し行い、
   取得したコンテンツと画像ファイルとをアーカイブし、
   上記携帯電話端末機は、
   上記プロキシサーバからアーカイブされたデータをダウンロードした後、当該プロキシサーバとの接続を切断してアーカイブされたデータを取得し、
   アーカイブされたデータからコンテンツと画像ファイルとを分離抽出すること
   を特徴とする請求項１乃至請求項３のうちいずれか１項記載の通信システム。
5. 上記携帯電話端末機及び上記プロキシサーバは、当該携帯電話端末機と当該プロキシサーバとの間でデータの送受信を行う際のライブラリを１つのレイヤとして構築し、
   上記携帯電話端末機は、上記コンテンツサーバに対して制限以上の容量のデータをアップロードデータとしてアップロードする場合には、
   当該アップロードデータを送信可能な容量に分割し、
   分割したデータ毎に、上記プロキシサーバとの間でセッションを確立して当該データを送信し、
   上記プロキシサーバは、
   セッション毎にキャッシュを生成して所定のアップロードキャッシュに追記し、
   上記携帯電話端末機から全てのデータの送信が完了すると、上記アップロードデータを復元し、
   アップロードすべき上記コンテンツサーバに対して当該アップロードデータを送信すること
   を特徴とする請求項１乃至請求項４のうちいずれか１項記載の通信システム。
6. 上記プロキシサーバは、上記コンテンツサーバに格納されている制限以上の容量のデータをダウンロードデータとして上記携帯電話端末に対してダウンロードする場合には、
   当該コンテンツサーバから当該ダウンロードデータを取得して所定のダウンロードキャッシュに格納し、
   上記ダウンロードキャッシュから送信可能な容量のデータを読み出すことによって上記ダウンロードデータを分割し、
   上記携帯電話端末との間で分割したデータ毎にセッションを確立して当該携帯電話端末機に対して当該データを送信し、
   上記携帯電話端末機は、上記プロキシサーバから全てのデータの送信が完了すると、上記ダウンロードデータを復元すること
   を特徴とする請求項５記載の通信システム。
7. 上記コンテンツサーバは、ロジック部分であるプログラム本体と、非ロジック部分であるテキストファイル並びに画像ファイル及び音声ファイルとからなるコンテンツとして作成されたアプリケーションプログラムを、上記ロジック部分と上記非ロジック部分とに分割するとともに、分割したロジック部分に所定のアーカイブライブラリを付与して格納し、
   上記携帯電話端末機は、
   上記アプリケーションプログラムをダウンロードする際に、上記プロキシサーバを介して上記アーカイブライブラリが付与された上記ロジック部分のみをダウンロードして保存し、
   上記アーカイブライブラリを起動して、上記非ロジック部分を上記プロキシサーバを介して上記コンテンツサーバから取得すること
   を特徴とする請求項１乃至請求項６のうちいずれか１項記載の通信システム。
8. 上記アプリケーションプログラムは、上記携帯電話端末機で実行可能なブラウザとメーラとを統合したソフトウェアであり、当該アプリケーションプログラムを待ち受け画面として待機させたまま、所定のサービスを利用可能とされるものであること
   を特徴とする請求項７記載の通信システム。
9. 上記携帯電話端末機は、上記アプリケーションプログラムを実行し、上記ブラウザを介して所定のコンテンツサーバから取得した待ち受け画面用の画像ファイル及び／又は着信音声用の音声ファイルを所定の保存領域に保存し、この保存領域を上記メーラと共用すること
   を特徴とする請求項８記載の通信システム。
10. 上記携帯電話端末機は、上記アプリケーションプログラムを実行し、上記メーラを介して所定のコンテンツサーバから電子メールのヘッダ情報からなる新着メールの一覧リストを取得し、本文の閲覧を希望したメール本文をページ毎に分割し、必要なページのみを受信するとともに、必要な添付ファイルをダウンロードすること
    を特徴とする請求項８又は請求項９記載の通信システム。
11. 上記携帯電話端末機は、上記アプリケーションプログラムを実行し、所定の表示画面に表示されたコンテンツをのうち画面範囲を超過する分について、上下方向にページ単位でスクロールさせること
    を特徴とする請求項８乃至請求項１０のうちいずれか１項記載の通信システム。
12. 上記携帯電話端末は、上記アプリケーションプログラムを実行し、格納しているアドレス帳を上記プロキシサーバにアップロードし、上記パケット通信網及び／又は上記インターネット網に接続される他の機器に対してインポート可能に、当該プロキシサーバに確保された所定の保存領域に格納させること
    を特徴とする請求項８乃至請求項１１のうちいずれか１項記載の通信システム。
13. インターネット網を介してデータの授受を行う通信方法であって、
    所定のパケット通信網に対して接続された携帯電話端末機からのコンテンツの閲覧リクエストに応じて、上記携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされるプロキシサーバによって当該コンテンツを格納するＵＲＬを復号し、
    当該コンテンツを格納する上記インターネット網に対して接続されたコンテンツサーバと上記プロキシサーバとが通信を行い、当該プロキシサーバによって当該コンテンツを取得し、
    上記プロキシサーバによって取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信し、
    上記携帯電話端末機によって上記コンテンツの木構造の組み立てを行い、
    上記携帯電話端末機によって組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行い、所定の表示画面に表示させること
    を特徴とする通信方法。
14. 所定のパケット通信網に対して接続された携帯電話端末機が上記パケット通信網を介して直接アクセス可能とされ、インターネット網に対して接続された各種コンテンツを格納するコンテンツサーバからコンテンツを取得し、上記パケット通信網を介して上記携帯電話端末機に対して配信代行を行うサーバ装置であって、
    上記携帯電話端末機からの上記コンテンツの閲覧リクエストに応じて当該コンテンツを格納するＵＲＬを復号するＵＲＬ復号手段と、
    当該コンテンツを格納する上記コンテンツサーバと通信を行い、当該コンテンツを取得するクライアント処理手段と、
    上記クライアント処理手段によって取得したコンテンツを解析し、当該コンテンツのデータ形式を正規化状態に修復するとともに、当該コンテンツの木構造を組み立てるのに必要な最低限のイベントを上記携帯電話端末機に対して送信するコンテンツ解析手段とを備えること
    を特徴とするサーバ装置。
15. 所定のパケット通信網に対して接続され、インターネット網に対して接続されたコンテンツサーバに格納されたコンテンツをプロキシサーバを介して取得する携帯電話端末機であって、
    上記プロキシサーバによって上記コンテンツサーバから取得したコンテンツの木構造を組み立てるのに必要な最低限のイベントを当該プロキシサーバから受信して、上記コンテンツの木構造の組み立てを行う木構造組立手段と、
    上記木構造組立手段によって組み立てられた木構造ファイルに基づいて表示の際のレイアウト処理を行うレイアウト処理手段と、
    所定の表示画面に表示させる表示処理手段とを備えること
    を特徴とする携帯電話端末機。

Images