JPH11250009A

JPH11250009A - サーバ装置及びウェブデータ変換方式

Info

Publication number: JPH11250009A
Application number: JP10052443A
Authority: JP
Inventors: Hiroshi Nagashima; 啓長島; Yuuichi Watanabe; 優市渡辺; Mitsuhiro Nishimura; 光博西村
Original assignee: Uniden Corp
Current assignee: Uniden Corp
Priority date: 1998-03-04
Filing date: 1998-03-04
Publication date: 1999-09-17

Abstract

(57)【要約】【課題】ワールド・ワイド・ウェブを携帯情報端末装
置で閲覧できるようにするウェブサーバ装置を提供す
る。【解決手段】ウェブサーバ装置は、各端末装置の要求
に応じてページデータをインターネット上のウェブサー
バから取得する。取得したページデータを転送先の端末
装置のリソース情報に基づいて該端末装置に適合するよ
うにデータ変換する。変換したページデータを端末装置
に転送する。それにより、移動環境下でのウェブデータ
の閲覧が容易なインターネットサービスが得られる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータネッ
トワークの集合体であるインターネットやイントラネッ
ト上のネットワークサーバの技術に関し、特に、携帯情
報端末装置（ＰＤＡ）等のハードウェアに一定の制限が
あるネットワーク接続機器にサービスを提供するネット
ワークサーバ装置に好適な技術に関する。

【０００２】

【従来の技術】インターネットやイントラネット等のネ
ットワークには、多数のウェブサーバが接続されてお
り、電子メール、ネットニュース、ファイル転送（ＦＴ
Ｐ）、テレネット（Telenet）、ゴーファー（Gophe
r）、ワールド・ワイド・ウェブ（ＷＷＷ）等の情報サ
ービスを提供している。

【０００３】ワールド・ワイド・ウェブのドキュメント
（ページ）のテキスト、静止画、音声、動画等のデータ
は、通常、パーソナル・コンピュータ（パソコン）で閲
覧することを前提に作成される。そして、マルチメディ
ア化の進展と共に、画像サイズや色数が増加し、ウェブ
ページのデータ（ウェブデータ）が増加する傾向にあ
る。

【０００４】ところで、パソコンよりも手軽に持ち運べ
る携帯情報端末装置を使用する人が増えている。携帯情
報端末装置は、一般に、個人向けの比較的に簡単な情報
処理機能と電子メール等の通信機能を備えている。

【０００５】

【発明が解決しようとする課題】しかしながら、携帯情
報端末装置は、装置の小型化や消費電力の節減による使
用時間の長時間化を図るなどの必要性から、パソコンに
比べて、画素数や色数が少ない画面表示器が採用され
る。このため、ウェブページの一部しか表示できず、ウ
ェブページ内の移動が困難である。

【０００６】また、搭載するメモリの容量が少なく、Ｃ
ＰＵの処理能力も低い。このため、画像データのように
ファイルサイズが大きいものを扱うことが難しい。

【０００７】更に、携帯情報端末装置をインターネット
に接続するためには、インターネット・サービス・プロ
バイダ（ＩＳＰ）を経由する必要がある。該サービス・
プロバイダに公衆通信回線を介して接続するモデムのデ
ータ伝送速度は、携帯電話（Personal Degital Cellula
r、以下、ＰＤＣと称する）やパーソナルハンディホン
（Personal Handy-phone System、以下、ＰＨＳと称す
る）を用いても９．６Ｋ〜２９．２Ｋbps程度が限度で
ある。通信の電波状況が悪い場合には、伝送速度は大き
く低下し、データ伝送に長時間を要する。

【０００８】一方、ウェブページ制作者が、携帯情報端
末装置で閲覧することを前提にウェブページを作成する
ことが考えられるが、ウェブページの自由な作成を制約
する。パソコン用と携帯情報端末装置用のページを別々
に準備すると制作者の負担が大きい。

【０００９】また、ウェブサーバが特定のメーカの携帯
情報端末装置の仕様に専用化すると、仕様の異なる他の
メーカの端末装置では、その性能を十分に発揮し難い。
例えば、ウェブサーバがモノクロ表示器の端末装置に特
化してサービスを提供する場合、他のメーカの端末装置
の表示器がカラーであっても、カラー画像を得ることは
出来ず、その本来の性能を生かすことが出来ない。

【００１０】また、もともと携帯情報端末装置で閲覧さ
れることを予定していない既存のウェブページを自由に
携帯情報端末装置で閲覧できることが望まれる。

【００１１】よって、本発明は、携帯情報端末装置で所
望のウェブページを閲覧することが出来るように、リク
エストに係るウェブデータを当該端末装置の仕様に適合
するように変換して提供するようにしたネットワーク・
サーバ装置を提供することを目的とする。

【００１２】また、本発明は、携帯情報端末装置によっ
てウェブページの閲覧をより高速で行い得るようにウェ
ブデータを変換するウェブデータの変換方式を提供する
ことを目的とする。

【００１３】

【課題を解決するための手段】上記目的を達成するた
め、本発明のサーバ装置は、公衆通信回線を介してサー
バに接続される端末装置とネットワークに接続された複
数のウェブサーバ相互間のデータ転送を行うサーバ装置
において、上記端末装置とのデータ通信を担う接続装置
と、上記データ通信の内容から上記端末装置のリソース
情報を得るリソース情報取得部と、上記端末装置の要求
に応じたドキュメントのデータを上記ネットワークに接
続された複数のウェブサーバのいずれかから取得する要
求処理部と、取得した上記ドキュメントのデータを上記
リソース情報に基づいて上記端末装置のリソースに適合
するようにデータ変換し、変換したドキュメントのデー
タを上記接続装置に転送する最適化処理部と、を備え
る。

【００１４】かかる構成とすることによって、ウェブデ
ータを端末装置のリソース（ハードウェア、ソフトウェ
ア資源）に適合するように処理して端末装置に与えるこ
とが出来、携帯型情報端末装置のように、装置性能に制
限があるものであっても、インターネット、イントラネ
ット、ＬＡＮ等のネットワークへのアクセスやレスポン
スの改善が可能となる。

【００１５】サーバが上記端末装置のリソース情報を入
手出来るようにするため、好ましくは、上記データ通信
の内容には、通信フォーマットのサブアドレス領域に記
録された上記端末装置のリソース情報が含まれる。上記
リソース情報取得部は、上記サブアドレス領域から上記
リソース情報を抽出する。

【００１６】かかる構成によれば、通信プロトコルとし
て定義されている部分（サブアドレス）を活用してリソ
ース情報を端末装置からサーバに送ることが可能とな
る。

【００１７】好ましくは、上記データ通信の内容には、
例えば、上記端末装置のリソース情報であることを表す
コマンド部分と、そのパラメータ部分としてのリソース
情報とが含まれる。上記リソース情報取得部は、上記パ
ラメータ部分から上記リソース情報を抽出する。

【００１８】かかる構成によれば、端末装置からサーバ
にコマンド形式によって端末装置のリソース情報を伝達
可能となる。サブアドレスを使用しない電話回線にも適
用可能である。

【００１９】好ましくは、上記サーバ装置は、更に、各
クライアントの識別符号に対応付られた各クライアント
のリソース情報を集めたデータベースを記憶する記憶部
を備える。上記リソース情報取得部は、上記データ通信
の内容に含まれるクライアントの識別符号（ＩＤ）を抽
出し、上記データベースの中から、上記識別符号に対応
するリソース情報を得る。

【００２０】かかる構成によれば、端末装置とサーバの
通信の確立（認証）の際に使用されるクライアントのＩ
Ｄによって、予めデータベース化された各クライアント
のリソース情報の中から該当するリソース情報が選択可
能となる。

【００２１】好ましくは、上記サーバ装置は、更に、各
クライアントの発信者番号に対応付られた各クライアン
トのリソース情報を集めたデータベースを記憶する記憶
部を備える。上記リソース情報取得部は、上記データ通
信の内容に含まれる発信者番号を抽出し、上記データベ
ースから上記発信者番号に対応するリソース情報を得
る。

【００２２】かかる構成とすることによって、いわゆる
発信者番号表示サービスを利用して端末装置とインター
ネットサービスプロバイダとの接続形態を識別可能とす
る。よって、予めデータベース化された各クライアント
のリソース情報の中から該当するリソース情報が選択可
能となる。

【００２３】好ましくは、上記データベースの各クライ
アントのリソース情報は、サーバ装置が提供するウェブ
ページを介して、クライアントによる登録、追加及び変
更のうち少なくともいずれかが可能になされる。

【００２４】かかる構成とすることによって、クライア
ントは、適宜にデータベースのリソース情報を、新規設
定、追加、削除、変更等が可能となる。

【００２５】好ましくは、上記リソース情報には、端末
装置の表示装置の解像度、表示階調、表示色数等の表示
装置の性能、ブラウザが対応しているＨＴＭＬのバージ
ョン等のソフトウェアの情報、端末装置が使用するフォ
ントサイズの種類、最小フォントサイズ等のフォント情
報、端末装置とサーバ装置との接続に関する接続速度等
の接続情報のうちいずれかまたはこれ等の組み合せを含
む。

【００２６】かかるリソース情報は、端末装置におけ
る、ウェブデータの表示、データ伝送時間、データ処理
時間等に関係する。

【００２７】好ましくは、上記最適化処理部は、上記リ
ソース情報に基づいて、取得した上記ドキュメントのデ
ータに、画像サイズの縮小、色数、階調減少、無フレー
ムページの生成、ＨＴＭＬバージョンの差異に対応した
データの置換えの処理、のうちいずれかまたはこれ等を
組み合わせた処理を行う。

【００２８】また、本発明のデータ変換方式は、公衆通
信回線を介してアクセスしてきた端末装置とネットワー
クに接続された複数のウェブサーバ装置との間のデータ
中継を行うネットワークサーバ装置におけるデータ変換
方式において、上記端末装置のリソース情報を取込むリ
ソース情報取得過程と、上記端末装置からの要求に基づ
きネットワークに接続されたウェブサーバからドキュメ
ントのデータを取込む要求処理過程と、上記ドキュメン
トのデータを上記端末装置のリソース情報に適合するよ
うに変換する最適化処理過程と、変換されたデータを上
記端末装置に転送するデータ転送過程と、を含む。

【００２９】かかるデータ変換方式によれば、端末装置
のリソースに対応してインターネット、イントラネット
等のウェブデータが加工されるので、相対的に性能の低
い端末装置であってもウェブの閲覧が容易になる。

【００３０】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態について説明する。図１は、本発明のサーバ装
置の構成例を概略的に説明するブロック図である。

【００３１】同図において、１は携帯型情報端末装置、
２は公衆通信回線、３はインターネット・サービス・プ
ロバイダ（ＩＳＰ）、４はプロキシ(Proxy)・サーバ、
５は専用線、６はインターネット、７はウェブサーバで
ある。

【００３２】携帯型情報端末装置１は、小型画面の表示
器を持つコンピュータシステムである。このコンピュー
タシステムはブラウザソフトウェア１ａによってダイヤ
ルアップＩＰ接続によるインターネットの端末装置とし
て機能する。端末装置１は、モデム等を介してＰＨＳあ
るいはＰＤＣ（携帯電話）１ｂに接続される。端末装置
１は、公衆電話回線２を介して、インターネット・サー
ビス・プロバイダ３に接続される。

【００３３】なお、ＰＨＳ１ｂと端末装置１とは一体化
が可能である。また、無線回線に変えて、公衆電話機等
を用いた有線回線を使用できる。

【００３４】インターネット・サービス・プロバイダ３
は、アクセス・ルータ３ａ、認証サーバ３ｂ、ルータ３
ｃ、プロキシサーバ４等によって構成される。

【００３５】アクセス・ルータ３ａは、公衆通信回線２
を介して接続された複数の端末装置１とプロキシサーバ
４と間のデータを中継する。アクセス・ルータ３ａはコ
ンピュータ・システムにより構成される一種のパケット
交換機であり、着信の発信者番号とこの番号に続くサブ
アドレスを解析し、その結果を認証サーバ３ｂに提供す
る機能を有する。解析結果（サブアドレス等の情報）
は、認証サーバ３ｂから更にプロキシサーバに提供され
る。後述するように、サブアドレスには端末装置のリソ
ース情報を含めることが可能であり、ルータ３ａはこれ
を読取る。また、発信者番号の頭３桁が“０３０”等
（他に０１０、０２０、０８０がある。１９９９年以降
より、０９０となる予定である。）であることから、端
末装置に携帯電話を接続して、インターネット・サービ
ス・プロバイダに接続していることを推定する機能を備
える。ルータ３ａは、これ等の端末装置１との通信に関
する情報をプロキシサーバ４に伝える。

【００３６】プロキシサーバ４は、いわゆるダイヤルア
ップＩＰ接続による、複数のクライアントの端末装置１
をインターネット６に接続するサービスを提供する。こ
のため、ドメインネームサービス（ＤＮＳ）を提供する
プログラムを使用して、一時的なＩＰアドレスが割当て
られたクライアントの端末装置１と、この端末装置１と
交信する外部の全てのウェブサーバ（コンピュータ）７
とのデータ中継を行う。

【００３７】プロキシサーバ４は、ＣＰＵ４１、キャッ
シュ記憶装置４２、データベース記憶装置４３を含んで
いる。ＣＰＵ４１は、上述したプロキシサーバとしての
基本機能、すなわち、クライアントからのウェブリクエ
ストを他のウェブサーバに回送して、このサーバからの
レスポンスをクライアントに返すという機能、を担うリ
クエスト処理部４１ａと、端末装置のリソース情報を取
得するリソース情報取得部４１ｂと、ドキュメントデー
タを端末装置のハードウェア及びソフトウェア性能に適
合するように最適化処理を行う最適化処理部４１ｃと、
を備えている。

【００３８】キャッシュ記憶装置４２は、必要により設
けられもので、プロキシサーバがキャッシング・プロキ
シサーバとして動作するときに、クライアントがリクエ
ストしたドキュメントのコピーを保存する。データベー
ス記憶装置４３は、クライアントのリソース情報、ドメ
インネーム等のデータベースを記憶している。これ等の
記憶装置４２及び４３は、高速のハードディスク装置、
半導体メモリ装置等によって構成される。

【００３９】ルータ３ｃは、プロキシサーバ４とインタ
ーネット６とを専用線５で接続する。

【００４０】インターネット６は、相互に接続されたコ
ンピュータネットワークの集合体である。ウェブサーバ
７は、インターネット６に接続されてブラウザ１ａで閲
覧可能なドキュメント等の情報を提供する。

【００４１】なお、端末装置１は、携帯型に限られず、
デスクトップ型の端末装置であっても良い。デスクトッ
プ端末装置の性能が相対的に低いものであるときには、
端末装置の性能に合わせて送信するウェブデータの伝送
量を減らす本発明の適用は利益がある。

【００４２】次に、プロキシサーバ４の動作について説
明する。プロキシサーバは、一般的に、以下に述べるよ
うな手順で動作する。

【００４３】(1) クライアントは、ウェブブラウザか
らリクエストをプロキシサーバに送る。

【００４４】(2) プロキシサーバは、リクエストされ
たドキュメントのコピーをキャッシュに持っているかど
うかを調べる。持っていれば、このコピーを実際のサー
バから来たかのようにクライアントに送る。

【００４５】(3) ドキュメントがキャッシュにない場
合、プロキシサーバは、クライアントのリクエストを適
切なウェブサーバに送る。そのウェブサーバから送られ
てきたドキュメントをクライアントに転送する。

【００４６】(4) プロキシサーバは、当該ドキュメン
トを保存して、再びリクエストする必要がないようにす
る。

【００４７】このプロキシサーバが介在することによ
り、クライアントが同一ドキュメントをリクエストした
場合、一度だけインターネット上のウェブサーバからド
キュメントを取得するだけで済むようにしている。

【００４８】本発明のサーバ装置は、上述したキャッシ
ング・プロキシサーバの動作の他に、端末装置のリソー
スに対応した最適化処理を行う。すなわち、 (1) クライアントが端末装置をプロキシサーバにダイ
ヤルアップ接続したときに、プロキシサーバは当該端末
装置の性能に関連するハードウェアのリソース情報を取
得する。

【００４９】(2) プロキシサーバは、リクエストされ
たドキュメントのコピーをキャッシュに持っているかど
うかを調べる。持っている場合には、キャッシュから当
該ドキュメントを読出す。ドキュメントがキャッシュに
ない場合、プロキシサーバは、クライアントのリクエス
トを適切なインターネット上のウェブサーバに送り、リ
クエストされたドキュメントを当該ウェブサーバから取
得する。

【００５０】(3) プロキシサーバは、読出され、ある
いは取得されたドキュメントに、クライアントのハード
ウェア及びソフトウェアのリソース情報に基づいて最適
化処理を施す。最適化処理には、例えば、画像サイズの
縮小、色数の制限、フレーム処理等が含まれる。最適化
処理の詳細については後述する。

【００５１】(4) 最適化処理を行ったドキュメントの
データをレスポンスとしてクライアントに転送する。

【００５２】このようにすると、プロキシサーバが、ド
キュメントデータにクライアントのハードウェア・ソフ
トウェア性能に対応した処理を加えて転送するので、ク
ライアントの端末装置のメモリ容量やＣＰＵ性能が不足
しても、ウェブデータを比較的にスムースに閲覧可能と
なる。

【００５３】図２は、クライアントの端末装置１のリソ
ース情報を取得するための手順を示すフローチャートで
ある。

【００５４】まず、認証サーバ３ｂは、動作状態におい
て、端末装置１がアクセスルータ３ａに接続されたかど
うかを常に監視している。端末装置１がアクセスルータ
３ａに接続されると、接続の際に、着サブアドレス情報
が通知されたかどうかを判別する（Ｓ２２）。端末装置
１から着サブアドレス情報が通知された場合には（Ｓ２
２；Ｙｅｓ）、それからリソース情報を取出し（Ｓ２
６）、プロキシサーバに送信する。プロキシサーバは、
受信した情報を所定のレジスタにクライアントのIDある
いはアクセスに対応付けて記憶する（Ｓ２８）。

【００５５】図３は、リソース情報を直接通知する場合
の例を示している。同図（ａ）は、端末装置が、ＰＨ
Ｓ、ＰＤＨあるいはＩＳＤＮを介してサーバにダイヤル
アップ接続する場合に、いわゆる着番号のサブアドレス
部分を利用するものである。サブアドレスは、例えば、
サービス・プロバイダの電話番号の後に“＊”を介して
後続する。例えば、プロバイダの電話番号が“０３−１
２３４−５６８７”である場合、ダイヤルする番号は、
“０３−１２３４−５６８７＊０３２０…２９”のよう
になり、“＊”以降の番号がサブアドレスである。端末
装置側では、サブアドレス部分に予め決められたルール
に従ってリソース情報を書込む。

【００５６】リソース情報の内容としては、例えば、画
面表示器の横の解像度（４桁数値）、縦の解像度（４桁
数値）、表示装置の種類（モノクロ：０、カラー：
１）、表示器の階調（２：４階調、３：８階調、４：１
６階調、６：６４階調）、色数（２：１６色、３：２５
６色、４：６５５３６色、５：フルカラー）、ハードウ
ェア・ブラウザが対応するＨＴＭＬのバージョン（２桁
数値）、フレーム対応（０：未対応、１：対応、）、フ
ォントサイズの種類（１桁数値）、太文字の有無（な
し：０、有り：１）、イタリック体の有無（なし：０、
有り：１）、下線表示の可否（なし：０、有り：１）、
モデムの最高通信速度、等があげられる。

【００５７】例えば、情報端末装置の仕様（ハードウェ
ア、ソフトウェア）が、「解像度：３２０×２４０、表
示装置の種類：カラー、表示色数：６５５３６、端末装
置が対応するＨＴＭＬのバージョン：２．０、フレーム
対応未対応）、フォントサイズの種類：３、太文字の有
無：なし、イタリック体の有無：なし、下線表示の有
無：なし、モデム速度：２９．２Ｋb/s」の場合、送信
するサブアドレスは、「０３２００２４０１４２００３
１００２９」となる。

【００５８】一方、端末装置１から着サブアドレス情報
が通知されない場合には（Ｓ２２；Ｎｏ）、プロキシサ
ーバは、間接的なリソース情報の取得を試みる。まず、
予め各クライアントのリソース情報をデータベース４３
に登録しておく。データベース４３の中にクライアント
のデータが存在するか確認する（Ｓ２４）。存在しない
場合は（Ｓ２４；Ｎｏ）、通常処理を選択し、通常処理
のフラグを設定する（Ｓ３６）。該データが存在する
場合は（Ｓ２４；Ｙｅｓ）、クライアントの情報、例え
ば、発信者電話番号通知サービスにより得る発信者電話
番号（後述の図３（ｂ））、クライアントの識別符号
（ＩＤ）（後述の図３（ｃ））等を利用してデータベー
スを検索し、適切なリソース情報を取得する（Ｓ３
０）。抽出したリソース情報を所定のレジスタにクライ
アントのＩＤあるいはアクセスに対応付して記憶する
（Ｓ３２）。

【００５９】図３（ｂ）は、発信者番号表示サービスに
よる端末装置の電話番号の通知をリソース情報の取得に
利用する例を示している。この場合、クライアントは、
サービスプロバイダが開設するウェブページを使用して
データベース４３に端末装置のリソース情報を予め登録
する。このウェブページには、クライアントがサービス
プロバイダへの接続に使用する電話番号、通信回線の種
類（ＰＨＳ、ＰＤＣ、ＰＳＴＮ、ＩＳＤＮ等）、端末の
リソース情報等の入力欄が設けられている。クライアン
トが必要事項を記入して登録を選択すると、クライアン
ト情報のデータベース４３に保存される。これ以後、ク
ライアントがサービスプロバイダに接続すると、局交換
機によって通知される発信者番号から、当該端末装置の
リソース情報を抽出する。

【００６０】図３（ｃ）は、サブアドレスも発信者電話
番号サービスも利用できない場合のリソース情報の取得
例を説明する説明図である。この例では、発信者番号に
変えて、サービスプロバイダに接続する際の認証手続に
使用するクライアントの識別符号（ＩＤ）を使用する。
この場合も、クライアントは、サービスプロバイダが開
設するウェブページを使用してデータベース４３に端末
装置のリソース情報を予め登録する。これ以後、クライ
アントがサービスプロバイダに接続すると、プロキシサ
ーバは、端末装置から通知されるクライアントの識別符
号ＩＤを取込み、データベース４３から当該端末装置の
リソース情報を抽出する。

【００６１】図３（ｄ）は、端末装置がサブアドレスを
使用できない通信方式の場合の他のリソース情報の通知
例を示す説明図である。

【００６２】この例では、端末装置１がサービスプロバ
イダ３に接続する場合、プロキシサーバにリソース情報
を通知するための専用コマンドを送信する。すなわち、
リソース情報を通知するコマンドの後に、コマンドのパ
ラメータとして上述したリソース情報が記述され、リソ
ース情報がプロキシサーバに識別可能に送信される。こ
のため、例えば、端末装置１のダイヤルアップ接続用の
ソフトウェアは、接続処理を行うときに、端末装置のリ
ソース情報を伝えるコマンドを発行する。リソース情報
を含むコマンドのパラメータは、予め端末装置のメーカ
ー若しくはクライアントが入力しておく。送ったコマン
ドはプロキシサーバにおいて実行され、リソース情報が
抽出される。

【００６３】なお、接続サービス利用中に、リソース情
報や最適化の処理条件を変更したい場合には、専用に設
けたウェブページにアクセスすることにより、設定され
ているリソース情報及び現在の最適処理の内容を変更す
る。

【００６４】次に、プロキシサーバ４は、リソース情報
に基づいて最適化処理を行うべきか否かを判断する（Ｓ
３４）。端末装置１が、６４０×４８０画素以上の解像
度で、カラーで２５６色以上表示できる表示装置を持
ち、かつ、端末装置のブラウザが対応するＨＴＭＬのバ
ージョンが最新バージョンで、フレーム対応である場合
は（Ｓ３４；Ｎｏ）、通常処理を選択するフラグを設定
する。これにより、ウェブサーバから送られてきたドキ
ュメントデータは、そのままプロキシサーバから端末装
置に送られる（Ｓ３６）。

【００６５】一方、接続されたクライアントの端末装置
が携帯型情報端末であるとき（ドキュメントを表示する
のにリソースが十分でないとき）（Ｓ３４；Ｙｅｓ）、
最適化処理を行うべきフラグを設定する（Ｓ３８）。

【００６６】このようにして、プロキシサーバにアクセ
スした端末装置のリソース情報が取得される。

【００６７】図４は、プロキシサーバにおける、リクエ
スト処理を説明するフローチャートである。

【００６８】プロキシサーバは、各端末装置の各リクエ
ストを処理するために各リクエストについて本ルーチン
を実行する。

【００６９】まず、端末装置からのリクエストが図示し
ないプロキシサーバのＦＩＦＯバッファメモリに蓄積さ
れている。プロキシサーバは、該バッファからリクエス
トを読込む（Ｓ４４）。要求しているドキュメントデー
タがキャッシュ４２に存在する場合には、キャッシュ４
２から読出す。存在しない場合には、該当する外部のウ
ェブサーバにリクエストを送出して該当するドキュメン
トを得る（Ｓ４６）。このリクエストを発した端末装置
に対応する最適化処理フラグ（Ｓ３６、３８）の有無を
判別する（Ｓ４８）。

【００７０】通常処理が選択されている場合は（Ｓ４
８；Ｎｏ）、得られたウェブのドキュメントデータをそ
のまま端末装置に転送する（Ｓ５６）。

【００７１】最適化処理が選択されている場合は（Ｓ４
８；Ｙｅｓ）、まず、取込んだドキュメントのデータが
テキストデータか否かを判別する（Ｓ５０）。データの
タイプは、例えば、ヘッダ部分のデータタイプがtext/h
tmlかどうかによって判断可能である。テキストデータ
である場合（Ｓ５０；Ｙｅｓ）、フレームページ処理を
行う（Ｓ５０）。フレームはリンクした複数のページを
１画面にまとめたように表示する機能である。このた
め、画面の狭い表示器に映し出すことは難しい。そこ
で、フレームのページを無フレームのページに変換して
表示するようにする（Ｓ５２）。このページ処理の具体
例については後に図５を参照して説明する。

【００７２】次に、ウェブサーバのドキュメントを作成
したＨＴＭＬのバージョンと、端末装置が対応するＨＴ
ＭＬのバージョンとが一致しない場合の適合化処理を行
う。携帯型端末装置では、ＣＰＵの処理能力が低かった
り、あるいはバージョンアップが行われない等の理由に
より、ドキュメントのＨＴＭＬのバージョンよりもブラ
ウザのＨＴＭＬのバージョンが古い（機能が低い）場合
がある。バージョンのより新しいＨＴＭＬでは、それよ
りも古いバージョンのＨＴＭＬにはない、新しいタグの
機能が提供されている。そこで、プロキシサーバは、端
末装置のブラウザのバージョンにない新規のタグを可能
な他の表現に変える等のＨＴＭＬのバージョン適合化処
理を行う（Ｓ５４）。また、端末装置のフォントサイズ
の種類、文字修飾の種類が少ないために、ドキュメント
本来の文字修飾が再現出来ない場合にもタグを置換して
近似した表現を行う。タグの置換例については、後述す
る。

【００７３】テキストデータについて、フレーム処理、
ＨＴＭＬバージョン処理を終えた後、端末装置にリクエ
ストデータを転送する。次のリクエスト処理を行う（Ｓ
５６）。

【００７４】ドキュメントのデータがテキストデータで
はない場合（Ｓ５０）、画像データかどうかを判別する
（Ｓ５８）。画像データでない場合、クライアントにリ
クエストデータを転送し（Ｓ５８；Ｎｏ）、次のリクエ
スト処理を行う。

【００７５】クライアントに転送すべきデータが画像デ
ータである場合（Ｓ５８；Ｙｅｓ）、画像データの大き
さを判別する。例えば、コンテンツタイプがimage/*で
あることにより、判別可能である。画像データのサイズ
が大きすぎる場合には、もともと小画面の端末装置で表
示するに適しない。そこで、例えば、画像の面積が表示
画面のサイズの４倍を越えるときには（Ｓ５９ａ）、サ
ーバ装置は、端末装置に画像データが大きいためデータ
伝送に長時間を要する等のメッセージを送る。メッセー
ジは、文字表示あるいは画像表示により行うことが出来
る。この文字あるいは画像の部分に、オリジナル画像へ
のリンクを貼る（Ｓ５９ｂ）。こうすることにより、ク
ライアントが望めば、画像を閲覧することが出来る。

【００７６】オリジナルへのリンクを貼る際には、元の
ＵＲＬの前後にそれを示す文字（ここでは、originalと
する）を追加する。例えば、sample.gifのオリジナルデ
ータを要求する場合のＵＲＬは、original.sample.gif.
originalとなる。

【００７７】クライアントがsample.gifのオリジナルデ
ータをリクエストすると、プロキシサーバ側でorigina
l.sample.gif.originalがオリジナルデータを要求して
いる（最適化処理を行わない）と判断し（Ｓ４８；Ｎ
ｏ）、sample.gifのオリジナルデータをレスポンスとし
てクライアントに転送する。この方式により、クライア
ントが望めば、オリジナルのデータを送ることが出来
る。

【００７８】画像データのサイズが、所定値を越えない
場合（Ｓ５９ａ；Ｎｏ）、端末装置の表示器の小型の画
面サイズに適合化させるべく、画像データの画面サイズ
の縮小を行う（Ｓ６０）。例えば、縮小率は画像サイズ
と表示器の解像度とを比較して決める。画像サイズの縮
小の具体例については、後に図６を参照して説明する。

【００７９】次に、端末装置のリソース情報を参照して
画像のモノクロ化、階調の調整等の処理を行う（Ｓ６
２）。画像のモノクロ化、階調の程度を決定するパラメ
ータとして、表示器のモノクロ／カラー、表示器の階
調、色数、モデム速度等がある。この色・階調処理の具
体例については、後に図７を参照して説明する。

【００８０】このように、プロキシサーバは、取得した
リクエストデータの画像サイズ、表示階調等を変更する
処理を行ってクライアントに転送する（Ｓ５６）。その
後、次のリクエスト処理を行う。

【００８１】プロキシサーバは、端末装置の表示能力
（解像度、色数、階調）、端末装置のモデムの最高速
度、サービスプロバイダ及び端末装置相互間の実際のデ
ータの転送速度、等に基づいて画像サイズの縮小、色数
や階調の減少等の処理を行う。このような処理を行うこ
とによって、伝送すべきデータ量を削減し、伝送時間を
短縮することが可能になる。また、従来、端末装置で行
ってきた画像処理、例えば、モノクロ表示の端末装置が
フルカラーの画像データを表示する場合に行う減色等の
処理をサーバ側で負担するので、端末装置側で必要とす
るＣＰＵ処理量とメモリ容量を削減でき、動作速度の向
上が期待できる。

【００８２】図５は、フレームページから無フレームペ
ージの生成を説明するフローチャートである。

【００８３】最近のウェブページには、フレームを使用
したものが多く見られる。ウェブのコンテンツの制作者
の多くは、フレームを使用したページの他に、フレーム
未対応のブラウザでも閲覧出来るように、未対応ブラウ
ザ用のページを用意している。しかし、中には、そうで
ないウェブページもある。この場合には、フレーム未対
応ブラウザには何も表示されない。そこで、フレーム形
式しか用意されていないページを無フレームのページに
変換することで、フレーム未対応のブラウザでの閲覧を
可能とする。

【００８４】図５において、プロキシサーバは、データ
がフレームページかどうかを判別する（Ｓ７２）。これ
は、例えば、ページのＨＴＭＬ記述に、〈FRAMESET〉、
〈/FRAMESET〉のタグが存在するかによって判別可能で
ある。フレームページではない場合（Ｓ７２；Ｎｏ）、
本処理は必要ないので、後述のＨＴＭＬバージョン処理
（Ｓ５４）に移行する。

【００８５】フレームページである場合（Ｓ７２；Ｙｅ
ｓ）、プロキシサーバは、端末装置のブラウザがフレー
ムページ表示に対応しているどうかを判別する（Ｓ７
４）。これは、端末装置のリソース情報によって判別可
能である。対応していれば、次の処理に移行する（Ｓ７
４；Ｙｅｓ）。対応していない場合（Ｓ７４；Ｎｏ）、
ページ未対応ブラウザ用のページが存在するかを判別す
る（Ｓ７６）。ページ未対応ブラウザ用のページの存在
の有無は、〈NOFARAMES〉タグの有無により判別可能で
ある。ページ未対応ブラウザ用のページが存在する場合
には（Ｓ７６；Ｙｅｓ）、当該ページのデータを読込む
こととして次の処理（Ｓ５４）に移行する。

【００８６】リクエストデータ中にフレームページが存
在し、端末装置がフレームページに未対応であり、しか
も、ページ未対応ブラウザ用のページがないときは（Ｓ
７６；Ｎｏ）、プロキシサーバは、以下の無フレームペ
ージ化処理を行う。

【００８７】まず、ページ内のフレームの配置が左右方
向か、上下方向かを判別する（Ｓ７８）。フレームが左
右に配置されている場合には（Ｓ７８；左右）、左側の
フレームのデータを無フレーム化ページの上部に配置す
る。右側のフレームのデータは、無フレーム化ページの
下部に配置する。無フレーム化ページの各所にアンカー
を設けてページの最上部の位置に戻れるようにする（Ｓ
８０）。その後、次の処理（Ｓ５４）に移行する。

【００８８】フレーム配置が左右分割ではなく、上下方
向の分割である場合（Ｓ７８；上下）、更に、上側のフ
レームが他のページへのリンク用フレームであるかどう
かを判別する（Ｓ８２）。一般的に、リンク用のフレー
ムはページの上部に配置される場合が多いからである。
これは、例えば、上部フレームの上下方向の幅が下側の
フレームの上下方向の幅よりも狭いかどうかにより、あ
るいは、上部のフレームのＨＴＭＬのタグの記述の解析
により、リンク用フレームであることを判別可能であ
る。上側のフレームがリンク用フレームである場合（Ｓ
８２；Ｙｅｓ）、上側のリンク用フレームのデータが無
フレーム化ページの最上部に配置されるようにページデ
ータを処理する。下側のフレームが無フレーム化ページ
の下部に配置されるようにページデータを処理する。ペ
ージの各所にアンカーを設けてページの最上部の位置に
戻れるようにする（Ｓ８４）。その後、次の処理（Ｓ５
４）に移行する。

【００８９】上側のフレームがリンク用フレームではな
い場合（Ｓ８２；Ｎｏ）、上側のフレームのデータを無
フレーム化ページの上部に配置する。下側のフレームの
データは無フレーム化ページの下部に配置する。無フレ
ーム化ページの各所にアンカーを設けてページの最上部
の位置に戻れるようにする（Ｓ８６）。その後、次の処
理（Ｓ５４）に移行する。

【００９０】なお、上記無フレーム化処理では、説明の
便宜上、フレームが上下方向に２つ、または左右方向に
２つ配置された例で説明したが、この場合に限られな
い。複数のフレームの配置パターンに対応した無フレー
ム化アルゴリズムが予めライブラリとして用意される。

【００９１】次に、ＨＴＭＬバージョン処理（Ｓ５４）
の具体例について説明する。ＨＴＭＬでは、バージョン
アップの度にタグの種類が増えている。一方、携帯情報
端末装置においては、そのＣＰＵ処理能力の制限等によ
り、対応するＨＴＭＬのバージョンが更新されないまま
である場合が多い。そこで、サービスプロバイダ側で、
ページデータに端末装置のＨＴＭＬのバージョンにない
タグがある場合に、よりオリジナルに近い表現で表示出
来るようにタグを置換する。

【００９２】タグの置換えを、文字修飾タグの置換、文
字サイズタグの置換を例として説明する。

【００９３】まず、文字修飾タグの置換例について説明
する。ＨＴＭＬでは、文字スタイルを指定する方法とし
て、図６に示すような論理的スタイルのタグで指定する
方法と、図７に示すような実際の文字スタイルのタグで
指定する方法とがある。例えば、ＨＴＭＬ３．０では、
これ等の論理フォントがどのようなフォント、色、大き
さを使用するのかを、スタイルシートを使って指定でき
るようになっている。

【００９４】そこで、プロキシサーバは、端末装置がＨ
ＴＭＬ２．０にしか対応していないブラウザを搭載して
いる端末装置にページデータを転送する際には、このス
タイルシートの記述内容に従って、ＨＴＭＬ２．０のタ
グに置換える処理も行う。

【００９５】図８は、この置換え例を示している。例え
ば、取消文字を表すタグ〈Ｓ〉は、文字の色を薄く表示
するタグ〈FONT COLOR＝＃○○○…〉に置換えられる。
太文字を表すタグ〈Ｂ〉は、フォントサイズ〈Ｈ１〉ｏ
ｒ〈Ｈ２〉or…として、文字の大きさを周囲よりも大き
い文字にする。下線付文字を表示するタグ〈Ｕ〉は、フ
ォントサイズを表すタグ〈Ｈ１〉により置換えて、当該
下線部分の文字の大きさを周囲よりも大きく表示する。
あるいは、太文字を表示するタグ〈Ｂ〉に置換える。

【００９６】図９は、文字サイズタグの置換えの例を示
している。例えば、ページのデータにＨＴＭＬの文字の
大きさを変えるタグ〈Ｈ１〉〜〈Ｈ６〉が用いられ、文
字サイズが６種類使用されている。しかし、端末装置が
持つフォントサイズの種類が３種類（〈Ｈ１〉、〈Ｈ
３〉、〈Ｈ５〉）しかない。このような場合、タグ〈Ｈ
１〉〜〈Ｈ６〉を次のように置換える。

【００９７】〈Ｈ１〉→〈Ｂ〉〈Ｈ１〉、〈Ｈ２〉→
〈Ｈ１〉、〈Ｈ３〉→〈Ｂ〉〈Ｈ３〉、〈Ｈ４〉→〈Ｈ
３〉、〈Ｈ５〉→〈Ｂ〉〈Ｈ５〉、〈Ｈ６〉→〈Ｈ
５〉。

【００９８】ここで、〈Ｂ〉は太文字に表示するタグで
ある。このように、一つの文字サイズについて、通常文
字幅と太い文字幅との２種類の表現態様とし、２つの文
字サイズに便宜的に対応させる。

【００９９】これによって、ウェブのコンテンツ作成者
の表現意図に可及的に近い表現を行う。

【０１００】図１０及び図１１を参照して画像のサイズ
縮小処理（Ｓ６０）について説明する。この処理では、
画像サイズの縮小を行うための縮率を決定する。

【０１０１】まず、端末装置のリソース情報から表示器
の画面の横サイズＤwを読込む。また、ページの画像デ
ータの横サイズＩwを読込む（Ｓ１０２）。表示器画面
の右側辺及び下辺にそれぞれ縦方向及び横方向のスクロ
ールバーを表示するために、例えば、画面の表示領域の
横方向の８０％を実表示領域として使用可能とする。

【０１０２】画像データの横サイズＩwが実表示領域の
横幅０．８Ｄwに収るかどうかを判別する（Ｓ１０
４）。収る場合には、横縮小率Ｒwを１とする（Ｓ１０
６）。収らない場合には、横縮小率Ｒwを（実表示領域
の横幅／画像の横サイズＩw）により求める（Ｓ１０
８）。

【０１０３】次に、縦縮率の計算を行う。リソース情報
から表示器の画面の縦サイズＤdを読込む。また、画像
データの縦サイズＩdを読込む（Ｓ１１０）。表示器画
面に縦方向及び横方向のスクロールバーを表示するため
に、画面の表示領域の縦方向の８０％を実表示領域とし
て使用可能とする。画像データの横サイズＩdが実表示
領域の縦幅０．８Ｄdに収るかどうかを判別する（Ｓ１
１２）。収る場合には、縦縮小率Ｒdを１とする（Ｓ１
１４）。収らない場合には、縦縮小率Ｒdを（実表示領
域の縦幅／画像の縦サイズＩd）により求める（Ｓ１１
６）。

【０１０４】横縮率Ｒwと縦縮率Ｒdとの大小を比較する
（Ｓ１１８）。画像表示器の画面の縦横比と、画像の縦
横比とが異なる場合であっても縮小画像が表示器画面に
収るようにするべく、より縮小率の値の低い方を選択す
ることとする。横縮率Ｒwが縦縮率Ｒdより小さい場合に
は（Ｓ１１８；Ｙｅｓ）、面積縮率ＲをＲw×Ｒwとする
（Ｓ１２０）。横縮率Ｒwが縦縮率Ｒdより大きい場合に
は（Ｓ１１８；Ｎｏ）、面積縮率ＲをＲd×Ｒdとする
（Ｓ１２２）。得られた縮率Ｒに従って、画像の縮小処
理を行う。画像の縮小は、例えば、画像データの縮率に
応じたデータの間引によって行うことができる（Ｓ１２
４）。

【０１０５】図１２を参照して、モノクロ化・階調処理
（Ｓ６２）について説明する。

【０１０６】まず、プロキシサーバは、端末装置に転送
すべき画像データの量（画素数）が基準値（例えば、１
０２４）よりも、大きいか否かを判断する（Ｓ１３
２）。この基準値は、例えば、端末装置のメモリ容量、
端末装置のモデム速度、実データ転送速度による画像デ
ータの転送に要する時間が所定時間を越えないか、等に
よって定める。

【０１０７】画像データの量が少ないときは、端末装置
に表示可能である。また、サイズの小さい画像に処理を
加えても処理に要する演算時間が無視できず、メリット
が少ない。そこで、画像データ量が比較的に少ない場合
には（Ｓ１３２；Ｎｏ）、画像のデータを減色・階調処
理することなく、端末装置に転送する（Ｓ５６）。

【０１０８】画像データの量が大きいときは（Ｓ１３
２；Ｙｅｓ）、画像データの形式がＧＩＦか、ＪＰＥＧ
かを判別する（Ｓ１３４）。ＪＰＥＧ形式の場合は、色
・階調処理を行わないで縮小処理（Ｓ６０）された画像
データの転送（Ｓ５６）を行う（Ｓ１３４；Ｎｏ）。画
像データの形式がＧＩＦの場合（Ｓ１３４；Ｙｅｓ）、
画像データを更に減らすべく、色・階調処理を行う。画
像データがＪＰＥＧ形式の場合に、色・階調処理を行わ
ないのは、カラー画像データを白黒画像化してもファイ
ルサイズが１０％程度の減少に止まること、カラー画像
データの色数を落すような処理を後で加えると、かえっ
て、ファイルサイズが増加すること、等による。

【０１０９】次に、端末装置の表示器がカラーかモノク
ロかを判別する（Ｓ１３６）。カラー表示器である場合
（Ｓ１３６；Ｎｏ）は、リソース情報を参照して、必要
により、カラー表示器の性能やモデム速度等に適合する
ようにカラーデータの減色を行う（Ｓ１３９）。例え
ば、８ビットカラー（２５６色）のオリジナルを４ビッ
トカラー（１６色）に減色すると、データ量は約１／４
に減少する。なお、カラー表示器が２５６色以上に対応
している端末装置である場合には、画像が綺麗に表示さ
れることを重視して、敢て減色処理を行わないようにし
ても良い。処理したカラー画像データを端末装置に転送
する（Ｓ５６）。

【０１１０】モノクロ表示器である場合（Ｓ１３６；Ｙ
ｅｓ）は、カラー画像データをモノクロ画像データに変
換する（Ｓ１３８）。更に、モノクロ表示器の表示階調
に合うようにモノクロ画像データの階調度を下げる（Ｓ
１４０）。この処理された画像データが端末装置に転送
される（Ｓ５６）。端末装置では、小型のカラー／モノ
クロ画面に適合した表示態様でウェブのコンテンツが表
示され、また、ＣＰＵの負担の少ない処理が可能とな
る。

【０１１１】こうして、ＧＩＦ形式画像データ及びＪＰ
ＥＧ形式の画像データは、端末装置の表示器の画面サイ
ズに対応して画像サイズが縮小されて画像データ量が削
減される。更に、ＧＩＦ形式画像データは、表示器のモ
ノクロに対応して画像データのモノクロ化・低階調化さ
れ、画像データ量が削減される。

【０１１２】図１３は、画像データの削減結果を示すも
のである。同図には、ＧＩＦ形式の画像（８ビットカラ
ー（２５６色））をオリジナルとし、これに対して減色
処理、階調処理を行った場合のファイルサイズの量と、
各種変換を経たデータの伝送時間と、が示されている。
８ビットカラーのオリジナルを４ビットカラー（１６
色）に減色すると、データ伝送時間は約１／４に減少す
る。画像サイズを１／４にすると、データ伝送時間は約
１／５に減少する。画像サイズを１／４にし、かつ、１
６階調の白黒画像にすると、データ伝送時間は約１／１
０に減少する。

【０１１３】（具体例）上述したデータ変換手順による
ウェブデータ変換の具体例について説明する。この例
は、携帯情報端末装置（PDA）を携帯電話（PDC）に接続
して、インターネット・サービス・プロバイダ（ＩＳ
Ｐ）にアクセスする場合のものである。端末装置のリソ
ースは次のにように仮定し、リソース情報を書き込むサ
ブアドレスのフォーマットは図３（ａ）に示すものとす
る。

【０１１４】・携帯情報端末のリソース解像度：320×240 フォントサイズの種類：3 表示装置：モノクロ太文字の有無：あり階調：16階調イタリック体の有無：なし対応ＨＴＭＬバージョン：2.0 下線表示の有無：なしフレーム対応：未対応 (1) サブアドレスによるリソース情報取得最初に、インターネット・サービス・プロバイダにダイ
ヤルする。その際、サービス・プロバイダの番号の後に
リソース情報を伝えるためのサブアドレスを付ける。サ
ービス・プロバイダの番号が、例えば、03-1234-5678で
あるとすると，ダイヤルする番号は「0 3 1 2 3 4 5 6
7 8 * 0 3 2 0 0 2 4 0 0 4 2 0 0 3 10 0」となる。
“*”以降の番号がサブアドレスである。

【０１１５】サービス・プロバイダでは、ダイヤルアッ
プ・ルータ(Dialup Router)が受信した発信者番号とサ
ブアドレスを解析する。発信者番号の頭3桁が「０３
０」（他に０１０、０２０、０８０がある。１９９９年
以降より０９０となる予定がある。）であることから、
端末装置に携帯電話を接続して、インターネット・サー
ビス・プロバイダに接続していることを推定する機能を
備える。すなわち、通信速度は９６００bpsであること
が推測できる。次に、サブアドレスを解析して、端末の
リソース情報を取得する。

【０１１６】(2) クライアントからのリクエストその１ユーザがウェブサーバ “www.abc.co.jp”のページ “o
riginal.html”を見ようとしたとする．その際，クライ
アントのブラウザからプロキシサーバに対して以下のよ
うなリクエストが発せられる。

【０１１７】 GET http://www.abc.co.jp/original.html HTTP/1.0 Accept: text/plain Accept: text/html Accept: image/gif Accept: image/jpeg プロキシサーバは、まず、キャッシュ内にhttp://www.a
bc.co.jp/original.htmlのデータがあるかどうか調べ
る。ここではないものとする。

【０１１８】次に、プロキシサーバがウェブサーバ “w
ww.abc.co.jp”にリクエストを発する。

【０１１９】GET /original.html HTTP/1.0 Accept: text/html Accept: image/gif Accept: image/jpegリクエストを受け取ったWebサーバ
は，そのリクエストを解析する。

【０１２０】Method: GET Document: /original.html Protocol: HTTP, Version 1.0 Accept: text/plain, text/html, image/gif, image/jp
egメソット゛ GET を実行した結果 original.htmlが存在するこ
とが判明したので、プロキシサーバにレスポンスを送
る。レスポンスは，まず最初にヘッダが送られ、その後
ファイル(original.html)が送られる。

【０１２１】・ヘッダの内容 HTTP/1.0 200 Document follows Server: NCSA/1.4 Date: Wed, 28 Jan 1998 17:01:15 GMT Content-type: text/html Content-length: 82 Last-modified: Mon, 12 Jan 1998 09:23:32 GMT ・ファイル (original.html) の内容 <HEAD> <TITLE> E-Mail Phone </TITLE> </HEAD> <IMG SRC=“photo.gif”> <P> This is E-Mail Phone. (3) Proxyサーバからのレスポンスウェブサーバから受け取ったレスポンスのコンテンツ(C
ontent)タイプ(type)はテキスト(text/html)なので、Ｈ
ＴＭＬに関する最適化処理を行う。オリジナル(origina
l.html)は、フレームページでなく、また、ＨＴＭＬの
新しいバージョンにしかないタグもないため、何の処理
も行われない。そのままのデータがクライアントに送ら
れる。また、オリジナル(original.html)のデータをキ
ャッシュにコピーする。

【０１２２】(4) クライアントからのリクエストその２クライアントのブラウザが original.htmlのデータを表
示する際に、インラインイメージ (photo.gif) がある
ことがわかる。すると、ブラウザがこのインラインイメ
ージを獲得するためのリクエストを発する。

【０１２３】 GET http://www.abc.co.jp/photo.gif HTTP/1.0 ・ヘッダの内容 HTTP/1.0 200 Document follows Server: NCSA/1.4 Date: Wed, 28 Jan 1998 17:01:22 GMT Content-type: image/gif Content-length: 45573 Last-modified: Mon, 12 Jan 1998 11:45:52 GMT ・ファイルの内容 photo.gif のデータ (5) リソース情報に基づく、画像データの最適化処理ウェブサーバから受け取ったレスポンスのコンテンツタ
イプ(Content-type)がimage/gifであることから、この
画像データ (photo.gif) に対する処理を行う。

【０１２４】・photo.gif 画像サイズ：320 × 240 色数：256色・ヘッダの内容 : Content-type: image/gif Content-length: 13426 : ・ファイルの内容サイズを1/4に縮小し，白黒16階調にしたphoto.gif の
データこの画像データの最適化により、クライアントに渡す画
像データ量が４５５７３byteから１３４２６byteに削減
される（削減率：約７０％）。

【０１２５】以上説明したように、サーバ装置から端末
装置に転送されるウェブのページデータは、端末装置の
ブラウザのバージョンの性能に適合するようにデータが
訂正される。また、表示器の画面サイズに表示画像のサ
イズが適合化される。端末装置への転送データ量が削減
されるので、データ転送に要する時間が短縮されて具合
がよい。本発明は、特に、ハードウェアに制限のある携
帯型情報端末装置に用いて好ましい。

【０１２６】上記データベースの各クライアントのリソ
ース情報は、サーバ装置が提供するウェブページを介し
て、クライアントによる登録、追加及び変更のうち少な
くともいずれかが可能になされる。これにより、登録リ
ソース情報の修正や、使用中にデータ処理の種類の変更
等が可能となっている。

【０１２７】本発明は、上述したインターネットや、イ
ントラネット等のネットワーク上のサーバ装置に適用す
ることが出来るが、例示のプロキシサーバに限られるも
のではない。例えば、ウェブサーバ装置、ＬＡＮのサー
バ装置、ルータ等にも適用可能である。

【０１２８】また、プロキシサーバのキャッシュは本発
明に不可欠のものではない。

【０１２９】

【発明の効果】以上説明したように、本発明のサーバ装
置及びデータ変換方式によれば、端末装置に供給される
ドキュメント（ページ）データが、サーバ装置によって
端末装置のハードウェア・ソフトウェアに適合するよう
に加工されるので、小型あるいは携帯型の端末装置によ
るインターネット等のネットワーク上に開設されたウェ
ブページへのより快適なアクセスが可能となり、好まし
い。

【図面の簡単な説明】

【図１】図１は、本発明の全体構成を概略的に説明する
ブロック図である。

【図２】図２は、リソース情報の取得例を説明するフロ
ーチャートである。

【図３】図３（ａ）〜同図（ｄ）は、リソース情報の取
得を説明する説明図である。

【図４】図４は、リクエスト処理の例を説明するフロー
チャートである。

【図５】図５は、フレーページの無フレーム化処理を説
明するフローチャートである。

【図６】図６は、論理的スタイルのタグの例を説明する
説明図である。

【図７】図７は、文字スタイルのタグの例を説明する説
明図である。

【図８】図８は、文字修飾タグの置換の例を説明する説
明図である。

【図９】図９は、文字サイズタグの置換の例を説明する
説明図である。

【図１０】図１０は、画像サイズの縮小化の例を説明す
るフローチャートである。

【図１１】図１１は、図１０の画像サイズの縮小化の続
きを説明するフローチャートである。

【図１２】図１２は、色・階調処理の例を説明するフロ
ーチャートである。

【図１３】図１３は、画像変換によるデータ削減の効果
を説明する説明図である。

【符号の説明】

１端末装置３インターネット・サービス・プロバイダ４プロキシサーバ６インターネット７ウェブサーバ装置

Claims

【特許請求の範囲】

【請求項１】公衆通信回線を介してネットワークに接続
されるべき端末装置と前記ネットワークに接続された複
数のウェブサーバ相互間のデータ転送を行うサーバ装置
であって、前記端末装置とのデータ通信を担う接続装置と、前記データ通信の内容から前記端末装置のリソース情報
を得るリソース情報取得部と、前記端末装置の要求に応じたドキュメントのデータを前
記ネットワークに接続された複数のウェブサーバのいず
れかから取得する要求処理部と、取得した前記ドキュメントのデータを前記リソース情報
に基づいて前記端末装置のリソースに適合するようにデ
ータ変換し、変換されたドキュメントのデータを前記接
続装置に転送する最適化処理部と、を備えるサーバ装置。
【請求項２】前記データ通信の内容には、着信信号の着
番号に続くサブアドレス領域に記録された前記端末装置
のリソース情報が含まれ、前記リソース情報取得部は、前記サブアドレス領域から
前記リソース情報を抽出する、請求項１記載のサーバ装
置。
【請求項３】前記データ通信の内容には、前記端末装置
のリソース情報であることを表すコマンド部分と、その
パラメータ部分としてのリソース情報とが含まれ、前記リソース情報取得部は、前記パラメータ部分から前
記リソース情報を抽出する、請求項１記載のサーバ装
置。
【請求項４】前記サーバ装置は、更に、各クライアント
の識別符号に対応付られた各クライアントのリソース情
報を集めたデータベースを記憶する記憶部を備え、前記リソース情報取得部は、前記データ通信の内容に含
まれるクライアントの識別符号を抽出し、前記データベ
ースの中から、前記識別符号に対応するリソース情報を
得る、請求項１記載のサーバ装置。
【請求項５】前記サーバ装置は、更に、各クライアント
の発信者番号に対応付られた各クライアントのリソース
情報を集めたデータベースを記憶する記憶部を備え、前記リソース情報取得部は、前記データ通信の内容に含
まれる発信者番号を抽出し、前記データベースから前記
発信者番号に対応するリソース情報を得る、請求項１記
載のサーバ装置。
【請求項６】前記データベースの各クライアントのリソ
ース情報は、サーバ装置が提供するウェブページを介し
て、クライアントによる登録、追加及び変更のうち少な
くともいずれかが可能になされる、請求項４または５記
載のサーバ装置。
【請求項７】前記リソース情報には、端末装置の表示装
置の解像度、表示階調、表示色数等の表示装置の性能、
ブラウザが対応しているＨＴＭＬのバージョン等のソフ
トウェアの情報、端末装置が使用するフォントサイズの
種類、最小フォントサイズ等のフォント情報、端末装置
とサーバ装置との接続に関する接続速度等の接続情報の
うちいずれかまたはこれ等の組み合せを含む、請求項１
乃至６のいずれかに記載のサーバ装置。
【請求項８】前記最適化処理部は、前記リソース情報に
基づいて取得した前記ドキュメントのデータに、画像サ
イズの縮小、色数、階調減少、無フレームページの生
成、ＨＴＭＬバージョンの差異に対応したデータの置換
えの処理、のうちいずれかまたはこれ等を組み合わた処
理を行う、請求項１乃至７のいずれかに記載のサーバ装
置。
【請求項９】前記端末装置は、携帯型情報端末装置であ
る、請求項１乃至８のいずれかに記載されたサーバ装
置。
【請求項１０】公衆通信回線を介してアクセスしてきた
端末装置とネットワークに接続された複数のウェブサー
バ装置との間のデータ中継を行うネットワークサーバ装
置におけるデータ変換方式であって、前記端末装置のリソース情報を取込むリソース情報取得
過程と、前記端末装置からの要求に基づきネットワークに接続さ
れたウェブサーバからドキュメントのデータを取込む要
求処理過程と、前記ドキュメントのデータを前記端末装置のリソース情
報に適合するように変換する最適化処理過程と、変換されたデータを前記端末装置に転送するデータ転送
過程と、を含む備えるデータ変換方式。
【請求項１１】前記リソース情報取得過程は、前記端末
装置が前記ネットワークサーバ装置にアクセスする際に
発した前記端末装置のリソース情報を取込むものであ
る、請求項１０記載のデータ変換方式。
【請求項１２】前記リソース情報取得過程は、前記端末
装置が前記ネットワークサーバ装置にアクセスする際に
発した前記端末装置の識別情報を取込み、予め用意され
た各端末装置のリソース情報のデータベースから該当す
るリソース情報を選択するものである、請求項１０記載のデータ変換方式。
【請求項１３】前記端末装置は、携帯型情報端末装置で
ある、請求項１０乃至１２のいずれかに記載のデータ変
換方式。