JP2001265645A - モジュラー・プロキシ・サーバによるリフォーマット方法 - Google Patents

Abstract

(57)【要約】 【課題】 ウェブ・コンテンツをリフォーマットするよ
うに容易に修正されカスタマイズされるプロキシ・サー
バ・プラットフォームを提供すること。 【解決手段】 プロキシ・サーバ１０８は、オペレータ
により変更可能な規則を評価し、要求側クライアントの
能力や要求変数に基いて、要求側クライアントに適する
ようウェブ・コンテンツをリフォーマットする方法を決
定する。プラットフォームは、コンテンツのリフォーマ
ッティングを行うモジュール１０２、１０３、１０４を
有する。モジュールは、稼働時に、実行するプロキシ・
サーバ・プラットフォームのソフトウエアへ動的にリン
ク可能である。プラットフォームは、他のモジュールに
影響を及ぼすことなくモジュールの加除が可能であるた
め、オペレータにより容易にカスタマイズ可能である。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、モジュラー・プロ
キシ・サーバ及びそのリフォーマット方法に関する。

【０００２】

【従来の技術】図１（従来技術）は、ウェブＴＶサーバ
６を介するインターネット５に対する複数のウェブＴＶ
クライアント２−４のアクセスを行う、ウェブＴＶネッ
トワークとして公知であるシステム１の図である。ウェ
ブＴＶクライアント２−４は、米国カリフォルニア州Ｍ
ｏｕｎｔａｉｎ ＶｉｅｗのＷｅｂＴＶ Ｎｅｔｗｏｒ
ｋｓ社から入手可能なウェブＴＶ・セット・トップ・ボ
ックス・インターネット端末である。ウェブＴＶサーバ
６は、インターネットにアクセスする目的のためクライ
アント２−４のために「プロキシ・サーバ」として機能
する。プロキシ・サーバを含むこのようなウェブＴＶネ
ットワークの詳細については、米国特許第５，９１８，
０１３号及び同第５，９３５，２０７号に記載されてい
る。

【０００３】１つの運用例において、クライアント２
が、インターネットの遠隔サーバ７に置かれたウェブ・
コンテンツ（例えば、ＨＴＭＬドキュメント）にアクセ
スしようと試みる。クライアント２は、ウェブＴＶサー
バ６に対して所望のＨＴＭＬドキュメントを識別する要
求を発する。要求されたＨＴＭＬドキュメントがウェブ
ＴＶサーバにおけるプロキシ・キャッシュ８に記憶され
ると、ウェブＴＶサーバ６がそのプロキシ・キャッシュ
８に記憶されるような要求されたＨＴＭＬドキュメント
を再びクライアント２へ送ることによってクライアント
２に応答する。クライアント２におけるブラウザは、Ｈ
ＴＭＬドキュメントがクライアント２のディスプレイに
表示されるようにさせる。このような意味で、ウェブＴ
Ｖサーバ６はプロキシ・サーバである。

【０００４】一方、要求されたＨＴＭＬドキュメントが
プロキシ・キャッシュ８になければ、ウェブＴＶサーバ
６が遠隔サーバ７に対してＨＴＭＬドキュメント要求を
発する。遠隔サーバ７は、ＨＴＭＬドキュメントをウェ
ブＴＶサーバ６へ戻すことにより応答する。ウェブＴＶ
サーバ６は、更に、最初に要求を行ったクライアント２
へＨＴＭＬドキュメントを送る。次いで、クライアント
２におけるブラウザが、ＨＴＭＬドキュメントをクライ
アント２のディスプレイに表示されるようにする。この
ＨＴＭＬドキュメントがクライアント２−４により頻繁
にアクセスされることが多いドキュメントであるなら
ば、ウェブＴＶサーバ６がこのＨＴＭＬドキュメントの
コピー９をプロキシ・キャッシュ８に記憶する。

【０００５】ウェブＴＶサーバ６はまた、ウェブ・コン
テンツをリフォーマットするように働く。一例におい
て、クライアント２が遠隔サーバ７からイメージ・デー
タにアクセスしようとする。しかし、イメージ・データ
は、クライアント２に不適正なイメージ・フォーマット
である。例えば、遠隔サーバ７における要求されたイメ
ージ・データが、クライアント２が解読表示できないフ
ォーマットであるという意味で不適正である。クライア
ント２がこのようなイメージ・データを表示しようとす
るならば、クライアント２はこのイメージの表示に失敗
するか或いは表示することができないことになる。

【０００６】或いはまた、このイメージ・データが必要
以上に高い解像度であるという意味において不適正であ
る。クライアント２は、例えば、ディスプレイ装置とし
てテレビジョン・スクリーンを使用しているかもしれな
い。通常のテレビジョンは、一般に多くのコンピュータ
のモニターの場合より低いピクセル解像度を持ってい
る。インターネットにおけるイメージ・データの多くが
コンピュータのモニターで表示するためのものであるか
ら、インターネットにおける多くのイメージはクライア
ント２−４の低解像度ディスプレイに対して転送される
必要がない比較的高い解像度のイメージを有する。

【０００７】遠隔サーバ７からのこのような不適正或い
は不必要なイメージ・データが同じフォーマットでウェ
ブＴＶサーバ６を単に素通りさせられるならば、クライ
アント２は不適正或いは不必要なイメージ・データを受
取ることになる。クライアント２がこのフォーマットを
解読できなければ、クライアント２はこのイメージの表
示に失敗するかこれを表示することができない。クライ
アント２が表示することができない大量の高解像度イメ
ージ・データが存在するものとすると、クライアント２
に対するイメージ・データの通信は不必要に多くの時間
を要することがあり得る。

【０００８】従って、ウェブＴＶサーバ６は、イメージ
・データを不適正なフォーマットから適正なフォーマッ
トへリフォーマットする「トランスコーダ」と呼ばれる
ソフトウエア１０を含んでいる。クライアント２は、最
初に遠隔サーバ７におけるイメージ・データに対する要
求をウェブＴＶサーバ６へ発する。イメージ・データが
プロキシ・キャッシュ８においてキャッシュされないも
のとすると、ウェブＴＶサーバ６は遠隔サーバ７に対し
てイメージ・データの要求を発する。遠隔サーバ７は、
不適正なフォーマットにおけるイメージ・データをウェ
ブＴＶサーバ６へ送ることによって応答する。トランス
コーダ・ソフトウエア１０は、このイメージ・データを
クライアント２が解読できる適正なフォーマットへリフ
ォーマットする。次いで、ウェブＴＶサーバ６はこのリ
フォーマットされたイメージ・データをクライアント２
へ送る。従って、クライアント２は、たとえインターネ
ットにおける遠隔サーバ７で入手可能であるようなイメ
ージ・データがクライアント２が解読表示ができるフォ
ーマットでなくとも、インターネットからイメージ・デ
ータにアクセスすることが可能である。

【０００９】ウェブＴＶサーバ６はイメージ・データを
リフォーマットするだけでなく、ＨＴＭＬドキュメント
のＨＴＭＬをリフォーマット（すなわち、「書き直
し」）する。遠隔サーバ７における要求されたウェブ・
コンテンツが「バグ」又は「クアーク（ｑｕｉｒｋ）」
を含むＨＴＭＬドキュメントであるとする。バグはクラ
イアントのブラウザの障害を生じるおそれがある。クア
ークは、クライアントのブラウザを破壊することはなく
とも、望ましくないか予期しない挙動を生じるおそれが
ある。従って、ウェブＴＶサーバ６は、このようなバグ
及びクアークを排除するよう、ＨＴＭＬの違法部分を書
き直す「ＨＴＭＬリライタ」と呼ばれるソフトウエア１
１を含んでいる。

【００１０】１つの運用例では、クライアント２は、ウ
ェブＴＶサーバ６に対して所望のＨＴＭＬドキュメント
に対する要求を発する。所望のＨＴＭＬドキュメントが
プロキシ・キャッシュ８においてキャッシュされないも
のとすれば、ウェブＴＶサーバ６は遠隔サーバ７からの
所望のＨＴＭＬドキュメントに対する要求を発する。遠
隔サーバ７は、バグ又はクアークを含むＨＴＭＬドキュ
メントをウェブＴＶサーバ６へ送り返すことにより応答
する。バグ又はクアークを含むＨＴＭＬドキュメントを
クライアント２−４へ送り返す代わりに、ＨＴＭＬリラ
イタ・ソフトウエア１１は、バグ又はクアークを排除す
るようにＨＴＭＬをリフォーマットする（書き直す）。
次いで、ウェブＴＶサーバ６は、クライアント２におけ
るブラウザがＨＴＭＬドキュメントを問題のないものに
することができるように、バグ又はクアークのないリフ
ォーマットされたＨＴＭＬドキュメントをクライアント
２へ送り返す。

【００１１】ＨＴＭＬリライタ・ソフトウエア１１はま
た、クライアント２のユーザにより時おり経験されるデ
ッドタイム（「知覚される待ち時間」）を短縮或いは除
去するようにも機能する。クライアント２におけるブラ
ウザは、ブラウザがイメージに対するサイズ情報を有す
るならば、イメージを含むウェブ・ページを作るように
始動することができる。ブラウザがイメージに対するサ
イズ情報を持つならば、ブラウザは、以後到着するイメ
ージ・データに対する適切なサイズの空白を残してバッ
クグラウンド・ページのレイアウトを開始することがで
きる。ブラウザがこのようなサイズ情報を持たなけれ
ば、クライアント２はウェブ・ページの要求がなされる
時からイメージに対するイメージ・データがクライアン
トに実際に受取られてブラウザがこのページを作り始め
るまでのデッドタイム（「知覚される待ち時間」）を経
験する。クライアントにおけるこのような知覚される待
ち時間を避けるため、ウェブＴＶサーバ６はイメージに
関するサイズ情報をキャッシュ８に記憶する。クライア
ント２がイメージを含むウェブ・ページを要求すると
き、ウェブＴＶサーバ６はそのキャッシュからサイズ情
報を回収し、このサイズ情報を含むようにウェブ・ペー
ジのＨＴＭＬを書き直し、このＨＴＭＬをクライアント
２へ受け渡す。従ってクライアント２におけるブラウザ
は、バックグラウンド・ページに対するＨＴＭＬを受信
すると、ウェブ・ページにおける任意のイメージに対す
るサイズ情報を用いてウェブ・ページを作り始めること
ができる。ブラウザは、バックグラウンド・ページのＨ
ＴＭＬを解読し、イメージのタグを識別し、このイメー
ジ・タグにより識別されるイメージ・データに対する要
求を発行し、サイズ情報を持つ実際のイメージ・データ
を受取るまで待つ必要がない。このサイズ情報は、元の
ＨＴＭＬと共に受取られる。従って、ＨＴＭＬの書き直
しの結果が、クライアント２における「知覚される待ち
時間」の短縮をもたらす結果となる。

【００１２】

【発明が解決しようとする課題】現在商業的に用いられ
るウェブＴＶサーバ６のコードは、１つのタイプのクラ
イアント（即ち、特定のソフトウェアを走らせるウェブ
ＴＶインターネット端末）を典型的にはサポートするモ
ノリシック・コードである。このコードは、適応及び改
変の融通性がなくまた困難である。例えば、第１のタイ
プのクライアントを要求するために１つの方法でコンテ
ンツをリフォーマットしながら、第２のタイプのクライ
アントを要求するために第２の方法でリフォーマットす
るよう、このコードを適応させることは困難である。こ
のような改変は一般に、ウェブＴＶサーバのコードの多
く或いは全てをコンパイルし直すことが必要となる。そ
れには、ウェブＴＶサーバのコードの内部構造をつぶさ
に知ることを必要とする。従って、ウェブＴＶサーバ６
は、独立のオペレータ（モノリシック・コードの内部構
造に習熟しないウェブＴＶ以外のオペレータ）による運
用、保守及びカスタマイズに充分に適するものとは考え
られない。プラットフォーム・ソフトウエアの他の部分
を変更することなく、かつプラットフォーム・ソフトウ
エアの内部構造の詳細な知識を持つ必要もなく、オペレ
ータがプラットフォーム・ソフトウエアの各部を比較的
容易に改変、削除及び（又は）追加できるように、この
ような独立のオペレータにより運用することが可能であ
るウェブＴＶサーバ・プラットフォームが望まれる。

【００１３】

【課題を解決するための手段】プロキシ・サーバの内部
動作に十分習熟していない対話型テレビジョン・サービ
ス・オペレータ（「オペレータ」）により容易に改変、
カスタマイズ及び保守が可能であるプロキシ・サーバ・
「プラットフォーム」が提供される。このプラットフォ
ームは、コンテンツのリフォーマットが１つ以上の「モ
ジュール」により行われる「モジュラー」アーキテクチ
ャを有する。モジュールは、稼働時に、実行中のプロキ
シ・サーバ・プラットフォーム・ソフトウエアへ動的に
リンク可能である。オペレータは、プロキシ・サーバの
動作をカスタマイズするため、モジュールの追加又は削
除することができる。一つの実施の形態においては、モ
ジュールは、他のモジュールを改変又は再コンパイルす
ることなく、個々のモジュールの取外し、交換及び（又
は）付加が可能なように、ＣＯＭモジュラー・プログラ
ミング規格に従って書かれる。個々のモジュールはオー
サー（ａｕｔｈｅｒ）が異なってもよい。モジュール
は、オペレータ又はウェブＴＶ又は他のエンティティに
よって書かれ得る。モジュールのオーサーとは無関係
に、個々のモジュールの実現に際してＣＯＭ規格に従う
ならば、複数のモジュールをプロキシ・サーバ・プラッ
トフォームにおいて一緒に働くよう作ることができる。

【００１４】一つの態様において、プロキシ・サーバ
は、要求側のクライアントの「クライアント能力」を表
わす情報を用いて、コンテンツが要求側のクライアント
へ中継される前に、どのモジュールがコンテンツを処理
するかを決定する。第１のクライアントは、遠隔サーバ
に記憶されたウェブ・コンテンツに対する第１の要求を
プロキシ・サーバへ発する。この第１の要求は、第１の
クライアントの「クライアント能力」を表わす情報（例
えば、第１のクライアントのハードウエア能力、ソフト
ウエア・バージョン番号及びソフトウエア作成番号）を
含む。プロキシ・サーバは、クライアント能力を表わす
情報を用いて、第１のクライアントに適する第１のフォ
ーマットを決定する。要求されたウェブ・コンテンツが
この第１のフォーマットにおいてプロキシ・サーバにキ
ャッシュされるならば、プロキシ・サーバがこのウェブ
・コンテンツを第１のクライアントへ送る。要求された
コンテンツが第１のフォーマットでキャッシュされなけ
れば、プロキシ・サーバは適切なモジュールを用いてウ
ェブ・コンテンツを第１のフォーマットにリフォーマッ
トする。リフォーマットされると、ウェブ・コンテンツ
は要求側の第１のクライアントへ送られる。ウェブ・コ
ンテンツがプロキシ・サーバにおいてキャッシュされな
い場合、或いはキャッシュされたウェブ・コンテンツが
他の或る理由（例えば、古すぎ）で使われない場合、プ
ロキシ・サーバはウェブ・コンテンツに対する要求を遠
隔サーバへ発し、このウェブ・コンテンツを検索する。
このウェブ・コンテンツが第１のフォーマットでなけれ
ば、プロキシ・サーバは適切なモジュールを用いてウェ
ブ・コンテンツを第１のフォーマットへリフォーマット
する。リフォーマットされると、プロキシ・サーバは、
このウェブ・コンテンツを要求側の第１のクライアント
へ送り返す。

【００１５】次に、第１のクライアントとは異なるクラ
イアント能力を持つ第２のクライアントが、ウェブ・コ
ンテンツに対する第２の要求をプロキシ・サーバに発す
る。この第２の要求は、第２のクライアントのクライア
ント能力を表わす情報を含む。プロキシ・サーバは、こ
の第２の要求を受取って、第２のクライアントに適する
第２のフォーマットを第２のクライアントのクライアン
ト能力を表わす情報を用いて決定する。

【００１６】要求されたウェブ・コンテンツがプロキシ
・サーバにおいて第２のフォーマットでキャッシュされ
ると、プロキシ・サーバはウェブ・コンテンツを第２の
クライアントへ送る。要求されたコンテンツが第２のフ
ォーマットでキャッシュされなければ、プロキシ・サー
バは適切なモジュールを用いてウェブ・コンテンツを第
２のフォーマットへリフォーマットする。リフォーマッ
トされると、ウェブ・コンテンツは要求側の第２のクラ
イアントへ送られる。キャッシュされたウェブ・コンテ
ンツが（例えば、古すぎるため）用いられなければ、プ
ロキシ・サーバは遠隔サーバに対してウェブ・コンテン
ツの要求を発して、ウェブ・コンテンツを検索する。遠
隔サーバから検索されたウェブ・コンテンツが第２のフ
ォーマットでなければ、プロキシ・サーバは適切なモジ
ュールを用いてウェブ・コンテンツを第２のフォーマッ
トへリフォーマットする。リフォーマットされると、プ
ロキシ・サーバがウェブ・コンテンツを要求側の第２の
クライアントへ送り返す。従って、プロキシ・サーバ
は、少なくとも部分的には要求側のクライアントのクラ
イアント能力を表わす情報に基いて、ウェブ・コンテン
ツが要求側のクライアントへ送り返されるフォーマット
を決定することが判る。

【００１７】別の態様によれば、プロキシ・サーバは、
第１のモジュールと第２のモジュールとを含む。第１の
モジュールは第１の方法でコンテンツをリフォーマット
し、第２のモジュールは第２の方法でコンテンツをリフ
ォーマットする。第２のモジュールではなく、第１のモ
ジュールが、第１のクライアントへ供給されるウェブ・
コンテンツをリフォーマットする。第１のモジュールで
はなく、第２のモジュールが、第２のクライアントへ供
給されるウェブ・コンテンツをリフォーマットする。第
１のモジュール及び第２のモジュールは各々、稼働時に
プロキシ・サーバに独立的に動的にリンク可能である実
行可能コードの一部である。

【００１８】更に別の態様によると、所与の要求側のク
ライアントへ供給されるリフォーマットされたコンテン
ツのタイプの決定は、オペレータにより変更可能な規則
の組を用いて行われる。最初に、プロキシ・サーバは、
ＨＴＴＰヘッダ又は要求のフォーム・データにおいて、
クライアント能力を表わす情報を受取る。プロキシ・サ
ーバは、この情報を用いてルックアップ・テーブル又は
データベースからクライアント能力の組を調べる。この
ように決定されたクライアント能力は、オペレータによ
り変更可能な規則の以降の評価のための入力として用い
られる。規則の評価は、どのモジュールが要求されたウ
ェブ・コンテンツを処理するか、及び（又は）これらモ
ジュールがどのように要求されたウェブ・コンテンツを
処理するかを、特定のクライアント能力を持つ要求側ク
ライアントに対して決定する。規則は、比較的理解し易
いテキスト形式で書かれる。このテキスト形式の規則
は、種々のモジュールの動作がモジュール自体のコード
を改変することなく変更されるように、プロキシ・サー
バ・ソフトウエアへ読み込まれる。オペレータは、規則
を変更し及び（又は）モジュールを追加又は削除するた
めに、モジュールの内部動作の詳細な知識を持つ必要が
ない。

【００１９】モジュラー・リフォーマット・ソフトウエ
アは、プロキシ・サーバ・アプリケーション以外のアプ
リケーションにより用いられる。一態様においては、イ
ーメール・サーバ・アプリケーションは、このリフォー
マット・ソフトウエアを用いて、イーメールを受け取る
クライアントに対して不適切な第１のフォーマットから
イーメールを受け取るクライアントに適する第２のフォ
ーマットへイーメールの添付書類をリフォーマットす
る。リフォーマットにより、イーメール・クライアント
は、添付書類がリフォーマットされなかったならば読む
ことができなかったイーメール添付書類を読むことがで
きる。リフォーマット・サーバは、クライアントにより
サーバへ送られるイーメール・クライアントのクライア
ント能力を表わす情報を用いて、クライアントに適切な
フォーマットになるように、添付書類をリフォーマット
する方法を決定する。

【００２０】本発明の他の態様及び他の実施の形態につ
いては、以降の詳細な記述において記載される。ここに
記載した発明の概要は本発明を限定するものではない。
本発明は、頭書の特許請求の範囲によって規定される。

【００２１】

【発明の実施の形態】図２は、本発明の一態様によるシ
ステム１００の図である。システム１００は、複数のク
ライアント１０２−１０４を含む第１の対話型テレビジ
ョン・ネットワーク１０１を含む。クライアント１０２
−１０４は、クライアント／サーバ接続線１０５−１０
７と第１のモジュラー・プロキシ・サーバ１０８とを介
してインターネット１０９に結合される。クライアント
／サーバ接続線１０５−１０７は、ダイアルアップ接
続、ＩＳＤＮ接続、Ｔ１接続、ＤＳＬ接続、或いはケー
ブル・モデム接続を含む任意の適切なタイプのものでよ
い。第１のプロキシ・サーバ１０８は、第１のオペレー
タにより動作される。クライアント１０２−１０４のユ
ーザは、典型的には、第１のモジュラー・プロキシ・サ
ーバ１０８を介してインターネット１０９にアクセスす
る能力を含む、提供される種々のサービスについて第１
のオペレータに支払う顧客である。図２の事例において
は、第１の対話型テレビジョン・ネットワーク１０１は
ウェブ・ネットワークであり、クライアント１０２−１
０４は米国カルフォルニァ州Ｍｏｕｎｔａｉｎ Ｖｉｅ
ｗのＷｅｂＴＶ Ｎｅｔｗｏｒｋｓ社から入手可能なウ
ェブＴＶセット・トップ・インターネット端末である。
従って、第１のプロキシ・サーバ１０８のオペレータは
米国カルフォルニァ州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＷ
ｅｂＴＶ Ｎｅｔｗｏｒｋｓ社である。ウェブＴＶ セ
ット・トップ・ボックス・インターネット端末について
の更なる情報については、米国特許出願第０９／２９
５，７４６号及び同第０９／２３８、１３３号を参照さ
れたい（これら米国特許出願の主題は、参考のため本文
に援用される）。クライアント／サーバ対話型テレビジ
ョン・ネットワークの構造及び動作のプロキシ・サーバ
についての更なる一般的情報については、米国特許第
５，９１８，０１３号及び同第５，９３５，２０７号を
参照されたい（これら米国特許の主題は参考のため本文
に援用される）。

【００２２】本発明の一態様によれば、第２の対話型テ
レビジョン・ネットワーク１１０が提供される。第２の
ネットワーク１１０のプロキシ・サーバ１１１における
ソフトウエアは、第１のネットワークのプロキシ・サー
バ１０８におけるソフトウエアと高度の共通性を共有す
るが、第２のネットワーク１１０は第２のオペレータに
より動作させられる。第１のネットワーク１０１のプロ
キシ・サーバ１０８のソフトウエアと、第２のネットワ
ーク１１０のプロキシ・サーバ１１１のソフトウエアと
は、適応可能かつカスタマイズ可能なモジュラー・ソフ
トウエア・プラットフォームであり、このソフトウエア
・プラットフォームは、第１のネットワーク１０１にお
ける第１のプロキシ・サーバ１０８としての動作に対し
て第１の方法で適応され且つカスタマイズされ、このソ
フトウエア・プラットフォームは第２のネットワーク１
１０における第２のプロキシ・サーバ１１１としての動
作に対して第２の方法で適応され且つカスタマイズされ
る。

【００２３】同じプラットフォーム・ソフトウエアが２
つのネットワーク１０１、１１０のプロキシ・サーバで
実行されても、この２つのネットワークは、２つのネッ
トワークのユーザの視点からは、別個の異なるネットワ
ークである。２つのネットワークのプロキシ・サーバの
内部構造の共通性は、２つのネットワークのいずれのユ
ーザからも容易に明らかになるものではない。第２のネ
ットワーク１１０のユーザは、第１のオペレータではな
く第２のオペレータの顧客である。図２の事例において
は、クライアント１１２−１１４は、クライアント１０
２−１０４とは異なる製造及び構造の対話型テレビジョ
ン・インターネット端末である。クライアント１１２−
１１４は、クライアント／サーバ接続線１１５−１１７
と第２のモジュラー・プロキシ・サーバ１１１とを介し
てインターネット１０９に結合される。

【００２４】図３は、図２のシステム１００の動作に従
う方法のフローチャートである。第１のネットワーク１
０１のクライアント１０２−１０４は、ウェブ・コンテ
ンツが第１のフォーマットで提供されるときに、遠隔サ
ーバ１１８におけるウェブ・コンテンツを最もよく利用
することができるクライアントである。他方、第２のネ
ットワーク１１０のクライアント１１２−１１４は、ウ
ェブ・コンテンツが第２のフォーマットで提供されると
きに遠隔サーバ１１８におけるウェブ・コンテンツを最
もよく利用できるクライアントである。

【００２５】一例において、クライアント１０２−１０
４のディスプレイは、クライアント１１２−１１４のデ
ィスプレイよりも低解像度のものである。遠隔サーバ１
１８におけるウェブ・コンテンツはイメージのためのイ
メージ・データであり、このイメージ・データはクライ
アント１０２−１０４又はクライアント１１２−１１４
のディスプレイに表示することができるよりも高解像度
のものである。従って、イメージ・データを要求側のク
ライアントへ転送する必要があるイメージの情報量を減
じるために、イメージ・データがクライアント１１２−
１１４へ送られる場合よりもクライアント１０２−１０
４へ送られる場合の方が、イメージ・データ量が多く低
減される。モジュラー・プロキシ・サーバ・ソフトウエ
ア・プラットフォームと共に最初に提供された第１の動
的にリンク可能なイメージ・リフォーマット・モジュー
ル（ＭＯＤＵＬＥ １）は、クライアント１０２−１０
４に対する適切な量の低減を行う。従って、第１のネッ
トワーク１０１の第１のオペレータは、このＭＯＤＵＬ
Ｅ １を用いてイメージ・データをリフォーマットす
る。しかし、このイメージ・データは、第２のオペレー
タにより当該目的のために特に書かれる動的にリンク可
能なイメージ・リフォーマット・モジュール（ＭＯＤＵ
ＬＥ ４）を用いて、第２のネットワーク１１０のクラ
イアント１１２−１１４に対してリフォーマットされ
る。このプラットフォームにより提供される元のイメー
ジ・リフォーマット・モジュール（ＭＯＤＵＬＥ １）
は第２のプロキシ・サーバ１１１から除去され、その代
り、特別に書かれたＭＯＤＵＬＥ４が用いられる。この
２つのモジュール（ＭＯＤＵＬＥ １及びＭＯＤＵＬＥ
４）は、ＣＯＭプログラミング規格に従って書かれた動
的にリンク可能なモジュールである。

【００２６】第１のステップ２００（図３参照）におい
て、第１のモジュラー・プロキシ・サーバ１０８は、
１）遠隔サーバ１１８におけるウェブ・コンテンツに対
する第１のクライアント１０２からの要求と、２）第１
のクライアントのクライアント能力を表わす情報とを受
取る。クライアント能力を表わす情報は、例えば、ＨＴ
ＴＰ要求のヘッダ又はフォーム・データに含まれる。ク
ライアント能力を表わす情報は、クライアントによりプ
ロキシ・サーバ１０８へ送られるクライアント能力であ
り、或いは、クライアント能力を表わす情報は、クライ
アント能力を決定するために使用可能な他の情報であり
得る。当例においては、当該情報は、第１のクライアン
ト１０２のディスプレイの特定の解像度を表わす情報
（ブラウザのタイプ、ソフトウエアのバージョン番号、
及びソフトウエアの作成番号）である。この情報はディ
スプレイの解像度ではないが、実施の形態によっては解
像度であり得る。

【００２７】第２のステップ２０１において、第１のモ
ジュラー・プロキシ・サーバ１０８は、要求されたウェ
ブ・コンテンツをイメージ・リフォーマット・モジュー
ル（ＭＯＤＵＬＥ １）を用いてリフォーマットするこ
とを決定するため、クライアント１０２の能力を表わす
前記情報を用いる。クライアント能力を表わす情報か
ら、当例における第１のプロキシ・サーバ１０８は、第
１のクライアントが特定の解像度のディスプレイを持
ち、従ってＭＯＤＵＬＥ １によりリフォーマットされ
たイメージ・データが最もよく提供されるものと決定す
る。要求されたウェブ・コンテンツが第１のプロキシ・
サーバ１０８に存在しなければ、第１のプロキシ・サー
バ１０８は、このウェブ・コンテンツに対する要求を遠
隔サーバ１１８に対して発する。遠隔サーバ１１８は、
要求されたウェブ・コンテンツ（この場合は、イメージ
・データ）を第１のプロキシ・サーバ１０８へ送り返す
ことにより応答する。

【００２８】次に（ステップ２０２）、第１のプロキシ
・サーバ１０８は、第１のモジュール（ＭＯＤＵＬＥ
１）を用い且つ第２のモジュール（ＭＯＤＵＬＥ ４）
は用いずに、ウェブ・コンテンツを第１のリフォーマッ
トされたコンテンツにリフォーマットする。当例では、
第１のリフォーマットされたコンテンツはクライアント
１０２のディスプレイに対して適切な解像度を持つ。次
いで（ステップ２０３）、第１のプロキシ・サーバ１０
８は、第１のリフォーマットされたコンテンツを要求す
る第１のクライアント１０２へ送り返す。

【００２９】次に（ステップ２０４）、第２のネットワ
ーク１１０の第２のモジュラー・プロキシ・サーバ１１
１は、１）遠隔サーバ１１８におけるウェブ・コンテン
ツに対する要求を第２のクライアント１１２から受取
り、２）第２のクライアント１１２のクライアント能力
を表わす情報を受取る。当例では、この情報は要求のヘ
ッダに含まれ、第２のクライアント１１２のディスプレ
イの解像度を表わしている。

【００３０】次に（ステップ２０５）、第２のモジュラ
ー・プロキシ・サーバ１１１は、第２のクライアント１
１２のクライアント能力を表わす情報を用いて、要求さ
れたウェブ・コンテンツを第２のモジュール（ＭＯＤＵ
ＬＥ ４）を用いてリフォーマットすることを決定す
る。当例では、第２のモジュールが、第２のクライアン
ト１１２のディスプレイの解像度に対する適切な解像度
を持つように、要求されたイメージ・データをリフォー
マットする。要求されたウェブ・コンテンツが第２のプ
ロキシ・サーバ１１１に存在しなければ、第２のプロキ
シ・サーバ１１１がウェブ・コンテンツに対する要求を
遠隔サーバ１１８に対して発する。遠隔サーバは、要求
されたウェブ・コンテンツを第２のプロキシ・サーバ１
１１へ送り返すことにより応答する。次いで（ステップ
２０６）、第２のモジュラー・プロキシ・サーバ１１１
は、第２のモジュール（ＭＯＤＵＬＥ ４）を用い且つ
第１のモジュール（ＭＯＤＵＬＥ １）は用いずに、ウ
ェブ・コンテンツを第２のリフォーマットされたコンテ
ンツにリフォーマットする。次いで（ステップ２０
７）、第２のモジュラー・プロキシ・サーバ１１１が、
第２のリフォーマットされたコンテンツを第２のクライ
アント１１２へ与える。従って、第１のネットワーク１
０１におけるプロキシ・サーバ・プラットフォームの第
１の事例が、特定のモジュール（ＭＯＤＵＬＥ １）を
用いて、要求されたウェブ・コンテンツをリフォーマッ
トし、第２のネットワーク１１０におけるプロキシ・サ
ーバ・プラットフォームの第２の事例が、異なるモジュ
ール（ＭＯＤＵＬＥ ４）を用いて、まさに同じ要求さ
れたウェブ・コンテンツをリフォーマットすることが判
る。

【００３１】図４は、図２のシステム１００の動作に従
う別の方法のフローチャートである。当該方法において
は、ウェブ・コンテンツが、要求側のクライアントの異
なるクライアント能力に依存して、同じ対話型テレビジ
ョン・ネットワーク内で異なる方法においてフォーマッ
トされる。

【００３２】第１のステップ（ステップ３００）におい
ては、モジュラー・プロキシ・サーバ１０８が遠隔サー
バ１１８におけるウェブ・コンテンツに対する要求を第
１のクライアント１０２から受取る。このモジュラー・
プロキシ・サーバ１０８もまた、第１のクライアント１
０２のクライアント能力を表わす情報を第１のクライア
ント１０２から受取る。クライアント能力を表わすこの
情報は、当例では、要求のヘッダに存在しており、第１
のクライアント１０２が第１の圧縮フォーマットで圧縮
されたイメージを取扱うよう動作可能にされることを示
す。

【００３３】次に（ステップ３０２）、モジュラー・プ
ロキシ・サーバ１０８は、要求されたウェブ・コンテン
ツを第１のモジュール（ＭＯＤＵＬＥ １）を用いてリ
フォーマットすることを決定するため、クライアント能
力を表わす情報を用いる。この第１のモジュールは、例
えば、イメージ・データを第１の圧縮フォーマットで圧
縮されたイメージ・データへリフォーマットする。

【００３４】要求されたウェブ・コンテンツがプロキシ
・サーバ１０８に存在しなければ、プロキシ・サーバ１
０８はウェブ・コンテンツに対する要求を遠隔サーバ１
１８へ発する。遠隔サーバ１１８は、要求されたウェブ
・コンテンツをプロキシ・サーバ１０８へ送り返すこと
により応答する。次いで（ステップ３０３）、モジュラ
ー・プロキシ・サーバ１０８は、第１のモジュール（Ｍ
ＯＤＵＬＥ １）を用い且つ第２のモジュール（ＭＯＤ
ＵＬＥ ３）は用いずに、ウェブ・コンテンツを第１の
リフォーマットされたコンテンツへリフォーマットす
る。当例では、第１のリフォーマットされたコンテンツ
は、第１の圧縮フォーマットにおけるイメージ・データ
である。いったん生成されると、この第１のリフォーマ
ットされたコンテンツは、要求する第１のクライアント
１０２へ送り返される。従って、イメージ・データは、
第１のクライアント１０２により好まれる第１の圧縮フ
ォーマットをしている。

【００３５】次に、モジュラー・プロキシ・サーバ１０
８は、遠隔サーバ１１８における同じウェブ・コンテン
ツに対する要求をネットワーク１０１の第２のクライア
ント１０３から受取る。このモジュラー・プロキシ・サ
ーバ１０８もまた、第２のクライアント１０３のクライ
アント能力を表わす情報を受取る。この情報は再び、要
求のヘッダに存在し得る。

【００３６】次いで、モジュラー・プロキシ・サーバ１
０８は、ウェブ・コンテンツを第２のモジュール（ＭＯ
ＤＵＬＥ ３）を用いてリフォーマットすることを決定
するため、第２のクライアント１０３のクライアント能
力を表わす情報を用いる。プロキシ・サーバ１０８によ
りすでに回収された要求されるウェブ・コンテンツは、
サーバ１０８のキャッシュ１１９において（遠隔サーバ
１１８に記憶される如き）その元のフォームでキャッシ
ュされ得る。このようにキャッシュされたウェブ・コン
テンツが古すぎなければ、プロキシ・サーバ１０８はこ
のコンテンツを用いるのであり、遠隔サーバ１１８から
ウェブ・コンテンツを回収する必要はない。さもなけれ
ば、プロキシ・サーバ１０８はウェブ・コンテンツに対
する要求を遠隔サーバ１１８に対して発する。遠隔サー
バ１１８は、要求されたウェブ・コンテンツをプロキシ
・サーバ１０８へ送り返すことにより応答する。

【００３７】次に（ステップ３０８）、モジュラー・プ
ロキシ・サーバ１０８は、第２のモジュール（ＭＯＤＵ
ＬＥ ３）を用い且つ第１のモジュール（ＭＯＤＵＬＥ
１）は用いずに、ウェブ・コンテンツを第２のリフォ
ーマットされたコンテンツへリフォーマットする。当例
における第２のモジュールは、イメージ・データを、第
２のクライアント１０３により好まれる第２の圧縮フォ
ーマットの圧縮イメージ・データへリフォーマットす
る。第２のリフォーマットされたコンテンツがいったん
生成されると、モジュラー・プロキシ・サーバ１０８
は、第２のリフォーマットされたコンテンツを第２のク
ライアント１０３へ与える（ステップ３０９）。

【００３８】従って、当該方法においては、モジュラー
・プロキシ・サーバは、ウェブ・コンテンツが第１のク
ライアント能力を持つ第１のクライアントにより要求さ
れると、第１のモジュールを用いて１つの方法でウェブ
・コンテンツをリフォーマットするが、ウェブ・コンテ
ンツが第２のクライアント能力を持つ第２のクライアン
トにより要求されると、第２のモジュールを用いて第２
の方法で同じウェブ・コンテンツをリフォーマットする
ことが判る。第１のクライアントは、例えば、第２のタ
イプの圧縮フォーマットをデコードする能力を持たない
簡単な装置（例えば、ＰａｌｍＰｉｌｏｔ、パーソナル
・オーガナイザ、或いはセルラー電話）でよい。第２の
クライアントは、例えば、第２のタイプの圧縮フォーマ
ットをデコードする能力を有するウェブＴＶインターネ
ット端末でよい。

【００３９】図５は、モジュラー・プロキシ・サーバ１
０８の動作例を示しており、クライアント１０２は、イ
メージを含むＨＴＭＬウェブ・ページを要求する。イメ
ージに対するイメージ・データは、第１のクライアント
１０２のスクリーンに表示できるよりも高い解像度を持
つ。イメージに対するＨＴＭＬイメージ・タグはイメー
ジに対するサイズ情報を含まないので、ＨＴＭＬが欠如
サイズ情報なしにクライアント１０２へ送られたなら
ば、バックグラウンド・ページの作成と関連する「知覚
される待ち時間」の問題が、クライアント１０２におい
て生じ得る。

【００４０】モジュラー・プロキシ・サーバ１０８は、
プロキシ・サーバ・アプリケーション４００、コンテン
ツ・リフォーマット（ＣＲＦ）・オブジェクト４０１、
複数のコンテンツ・リフォーマット・モジュール（ＣＲ
Ｍ）・オブジェクト４０２−４０５、及びＣＲＦ管理コ
ンフィギュレーション・インターフェース・システム
（ＣＡＣＩＳ）４０６を含む。ＣＲＦ４０１は、コンテ
ンツ・リフォーマット・プロセスを制御する。ＣＲＦ４
０１は、コンテンツのリフォーマットが当該サーバにお
いてどのように行われるべきかについての情報を記憶す
る関連コンフィギュレーション・オブジェクト４０７を
有する。この情報は、１組の規則４０８と存在するＣＲ
Ｍ（及び任意のサブＣＲＭ）のリスト４０９とを含む。

【００４１】規則４０８は、人間が読めるテキスト・フ
ァイル４１０としてのテキスト・フォームで、或いはグ
ラフィカル・ユーザ・インターフェース（ＧＵＩ）４１
１を介して、オペレータによりＣＡＣＩＳ４０６へ入れ
られる。ＣＡＣＩＳ４０６は更に、この規則をコンフィ
ギュレーション・オブジェクト４０７の規則部４０８へ
ロードする。各規則は、条件（ブール代数表現の組）と
結果として得る表現とを有する。結果として得る表現
は、各ＣＲＭへ進む入力パラメータを持つＣＲＭリスト
（通常は１つのみであるが、いくつか存在し得る）であ
る。「真」と評価される全ての規則が実行され、これら
規則の実行順序は、これらがテキスト・ファイル４１０
に現われる順序に従う。

【００４２】図６は、テキスト・ファイル４１０の一例
である。プロキシ・サーバ１０８が初期化されると、Ｃ
ＡＣＩＳ４０６がテキスト・ファイル４１０を読出し、
次に規則をコンフィギュレーション・オブジェクト４０
７の規則部４０８へロードする。ＣＡＣＩＳ４０６はま
た、存在するＣＲＭ４０２−４０５のリストをリスト４
０９にロードする。

【００４３】規則部４０８は、動作時間に、入力として
要求変数及び（又は）クライアント能力を用いて評価さ
れる。要求変数は、コンテンツ長、コンテンツ・タイ
プ、及びユーザ・エージェントを含む（コンテンツ長及
びコンテンツ・タイプは、要求自体から直接生じるので
はなく、要求に対する応答から生じるものであるとして
も、「要求変数」と見なされる。これらが、要求により
要求される情報を記述するという意味で、要求と関連す
るからである）。クライアント能力は、オペレータが拡
張可能である。各変数については、許容値又は値の範囲
が存在する。

【００４４】クライアント能力は、或る実施の形態で
は、要求時にクライアントからプロキシ・サーバへ送る
ことができるが、ここに述べた実施の形態では、クライ
アント能力は、クライアント能力データベース（ＣＣ
Ｄ）を用いてプロキシ・サーバ・アプリケーション４０
０により決定される。要求側のクライアントから受取ら
れるクライアント能力を表わす情報（例えば、要求側の
クライアントにおいて実行するブラウザに対するブラウ
ザ識別子、ブラウザ・ソフトウエアのソフトウエア・バ
ージョン番号、及びブラウザ・ソフトウエアのソフトウ
エア作成番号）は、要求側のクライアントの対応クライ
アント能力を調べるのに用いられる。当例においては、
ブラウザ識別子、ソフトウエア改定番号及びソフトウエ
ア作成番号は、クライアント１０２から受取る如き要求
のヘッダに存在する。この情報は、ＷｅｂＴＶ−１．２
−ＸＸＸＸの形態である。「ＷｅｂＴＶ」部分は、ブラ
ウザ識別子である。他の可能性は、「ネットスケープ」
及び「モジラ（Ｍｏｚｉｌｌａ）」を含む。「１．２」
部分は、ソフトウエアの改定番号である。「ＸＸＸＸ」
部分は、４桁のソフトウエア作成番号である。当例で
は、プロキシ・サーバ・アプリケーション４００が、ク
ライアント能力を表わす情報から、クライアント１０２
が「クライアント能力」、すなわち、ｘ次元（水平次
元）におけるディスプレイ解像度、ｙ次元（垂直次元）
におけるディスプレイ解像度、カラー方式、ビット深
さ、接続速度、接続タイプ、メモリ量、キャッシュ・メ
モリ量、ディスク・スペース量、プロセッサ速度、サポ
ートされるイメージ・フォーマット、サポートされるオ
ーディオ・フォーマット、クライアントがステレオ音響
をサポートするか単にモノ音響だけか、のそれぞれに対
する特定値を持つことを決定する。

【００４５】いったんクライアント能力及び要求変数
（コンテンツ長、コンテンツ・タイプ及びユーザ・エー
ジェント）が特定の要求に対して判ると、プロキシ・サ
ーバ・アプリケーション４００が、新たな変換のためコ
ンテキスト・オブジェクト（ＣＴＸ）４１３を生成する
ために前記情報を入力として用いて、メソッド「Ｃｒｅ
ａｔｅＮｅｗＣｏｎｔｅｘｔ」４１５を呼出す。（用語
「変換」は、リフォーマット操作を示すため用いられ
る。）ＣＲＦ４０１は、新たなＣＴＸ４１３を照会し、
インターフェース・ポインタ（ＣＴＸ４１３に対するハ
ンドル）を取得し、これをプロキシ・サーバ・アプリケ
ーション４００へ与える。生成されると、ＣＴＸ４１３
はプロキシ・サーバ・アプリケーション４００が通信す
るオブジェクトである。

【００４６】当例においては、要求されたＨＴＭＬドキ
ュメントはキャッシュ４１４においてキャッシュされな
い。従って、プロキシ・サーバ１０８は、ＨＴＭＬドキ
ュメントに対する要求を遠隔サーバ１１８へ発する。遠
隔サーバ１１８は、ＨＴＭＬをプロキシ・サーバ１０８
へ送り返すことによって応答する。ＨＴＭＬ（データ）
がプロキシ・サーバ１０８へ戻り始めると、プロキシ・
サーバ・アプリケーション４００が標識によりＣＴＸ４
１３における「ＰｕｓｈＤａｔａ」関数４１６を呼出
す。この標識は、更に多くのデータが後に続くこと（デ
ータ・ストリーミングの場合のように）を示すか、或い
は全てのデータがコンテキストへプッシュされたことを
示す。ＣＴＸ４１３は、コンフィギュレーション・オブ
ジェクト４０７に対する参照を用い、決定されたクライ
アント能力及び要求変数を用いて、規則４０８の評価を
生じさせる。この規則評価の結果は、１）ＨＴＭＬを処
理するのに用いられるＣＲＭの順序付きリスト（順序
は、ＣＲＭが用いられる順序を示す）、及び２）ＣＲＭ
の挙動を制御する各ＣＲＭごとの入力制御パラメータで
ある。個々のＣＲＭの動作は、これに送られる入力制御
パラメータにより制御される。

【００４７】当例においてＨＴＭＬの処理のため用いら
れるＣＲＭは、ページ・パッチャＣＲＭ４０２及びトー
クナイザ（ｔｏｋｅｎｉｚｅｒ）ＣＲＭ４０３である。
ページ・パッチャＣＲＭ４０２に対する入力制御パラメ
ータの１つは、各構造が行われるべき特定のページ・パ
ッチを規定する構造のリストである。トークナイザＣＲ
Ｍは、入力制御パラメータを受取らない。

【００４８】ＣＴＸ４１３は、順序付きリストにおける
最初のＣＲＭへ進み、ＣＲＭにおけるＣｒｅａｔｅＮｅ
ｗＳｔａｔｅを呼出すことにより１つの状態（図示せ
ず）を生成する。（ＣＲＭにより行われる各動作ごとに
新たな状態が存在する。）次いでＣＴＸ４１３は、適切
な入力制御パラメータを当該ＣＲＭへ送り、その状態に
ついて関数「ｐｒｏｃｅｓｓ ｄａｔａ」４１７を呼出
す。当例においては、順序付きリストにおける最初のＣ
ＲＭはページ・パッチャＣＲＭ４０２である。クライア
ント１０２が特定のＨＴＭＬシーケンスに問題を有する
ことが判ると、ページ・パッチャＣＲＭ４０２はＨＴＭ
Ｌにおける特定の問題となるシーケンスを探し、これを
許容し得るシーケンスで置換する。次に、データはＣＴ
Ｘ４１３へ戻る（４１８）。ＣＴＸ４１３は、順序付き
リストにおける次のＣＲＭ（この場合、トークナイザＣ
ＲＭ４０３）へ進み、トークナイザＣＲＭ４０３の状態
（図示せず）を生成し、トークナイザの状態の関数「ｐ
ｒｏｃｅｓｓ ｄａｔａ」を呼出す（４１９）。

【００４９】当例においては、遠隔サーバ１１８から受
取られる如きＨＴＭＬウェブ・ページにおけるイメージ
・タグは、イメージ・サイズ情報を持たない。従って、
クライアント１０２は、ＨＴＭＬがクライアント１０２
において受取られるときにバックグラウンド・ページを
作ろうとすると、「知覚される待ち時間」を経験するこ
とになる。クライアント１０２は、そのとき、イメージ
に対するサイズ情報を持たないからである。一方、ＨＴ
ＭＬがサイズ情報を含んでいたならば、クライアント１
０２は、実際にイメージ・データ自体を受取る前に、イ
メージ・タグにおけるサイズ情報を用いてバックグラウ
ンド・ページを作り始め得る。バックグラウンド・ペー
ジの形成時のこのような「知覚される待ち時間」を除去
するため、ＨＴＭＬがクライアント１０２へ戻される前
に、トークナイザＣＲＭ４０３がサイズ情報をＨＴＭＬ
へ挿入する。

【００５０】従って、トークナイザの状態はＨＴＭＬタ
グをイメージ・タグについて探索し、イメージ・タグか
らイメージ・ネームを取得し、このイメージ・ネームを
用いて前に記憶された特定のイメージに対するサイズ情
報をキャッシュ４１４において探し、次に文字Ｈ＝
、Ｗ＝ を適切な場所におけるＨＴＭＬのストリー
ムへ付記してイメージ・タグがイメージのサイズを示す
ようにする。

【００５１】図７は、トークナイザの状態５００のこの
動作の図である。トークナイザの状態５００は、変換自
体を行うのではなく、トークナイザ５０１を用いてＨＴ
ＭＬテキスト５０２のストリームを概念的トークンのス
トリーム５０３へ変換する。これらのトークン５０３は
一連のトークナイザ・サブモジュール５０４、５０５へ
送られ、そこでトークンの修正、挿入、除去及び（又
は）作成が行われる。トークナイザ・サブモジュールの
組は、ＣＲＭの組と同じ方法で修正し得る演算子であ
る。当例においては、トークナイザ・サブモジュール５
０４は、イメージ・ネーム５０６をイメージ・タグから
キャッシュ４１４へ送る。このイメージ・ネームは、サ
ブモジュール５０４へ戻される（５０７）イメージに対
する記憶されたサイズ情報（高さと幅）を識別する。こ
のサイズ情報は、適切に修正されたトークン・ストリー
ム５０８を生じるように挿入される。この修正されたト
ークン・ストリーム５０８は、次に、トークナイザの状
態５００のデトークナイザ（ｄｅｔｏｋｅｎｉｚｅｒ）
５１０により，修正されたＨＴＭＬテキスト・ストリー
ム５０９へ変換される。この修正されたＨＴＭＬは、次
にＣＴＸ４１３へ返される（５０９、４２０）。

【００５２】ＣＴＸ４１３は、ＨＴＭＬデータを取り戻
すとき、規則４０８を再評価させる。このＣＴＸは、関
数「ＰｕｓｈＤａｔａ」の呼出しから戻り、修正された
ＨＴＭＬ（この時、イメージのサイズ情報を含んでお
り、誤って形成された或いはクアークで生じたＨＴＭＬ
が除去される）を再びプロキシ・サーバ・アプリケーシ
ョン４００へ送り返す（４２１）。次に、要求されたＨ
ＴＭＬは要求側のクライアント１０２へ戻される。クラ
イアント１０２は、このＨＴＭＬを受取り、イメージ・
タグにおけるサイズ情報を用いてバックグラウンド・ペ
ージを作り始める。クライアント１０２は、実際のイメ
ージ・データ自体を受取り或いは要求する前に、バック
グラウンド・ページを作り始める。従って、上記の「知
覚される待ち時間」の問題は解決される。

【００５３】次いで、クライアント１０２は、イメージ
・データに対する要求をプロキシ・サーバ１０８へ発す
る。プロキシ・サーバ１０８は、キャッシュ４１４を検
査し、このイメージ・データがそこにキャッシュされた
かどうかを判定する。イメージ・データがキャッシュさ
れると、プロキシ・サーバ１０８は、判定されたクライ
アント能力に基いて、適切なものとしてリフォーマット
されたイメージ・データを戻す。イメージの多くのバー
ジョンがキャッシュされ得、要求側のクライアントに対
して適切であるこれらバージョンの１つが、クライアン
ト能力により決定される。

【００５４】或いはまた、イメージ・データの唯一つの
バージョンがキャッシュされ、このバージョンが必要に
応じてリフォーマットされる。クライアント能力は、リ
フォーマットが要求側のクライアントに対してどのよう
に行われるべきかを決定するために用いられる。

【００５５】当例においては、プロキシ・サーバ１０８
は、要求されたイメージ・データをキャッシュしなかっ
た。従って、プロキシ・サーバ１０８は、遠隔サーバ１
１８からのイメージ・データについての要求を発する。
遠隔サーバ１１８がイメージ・データに応答すると、プ
ロキシ・サーバ１０８は、イメージ・データ要求に対す
るコンテンツ長、コンテンツ・タイプ、ユーザ・エージ
ェント及びクライアント能力を通すことにより、別のコ
ンテキストを生成する。次いで、プロキシ・サーバ・ア
プリケーション４００は、このコンテキストにおける
「ＰｕｓｈＤａｔａ」関数を呼出し、その結果を評価し
て、使用するＣＲＭのリストとリストされたＣＲＭ毎の
１組の入力制御パラメータとを生成する。当例において
は、１つのＣＲＭすなわちイメージＣＲＭ４０４によっ
て全てのイメージのリフォーマットが行われる。ＣＲＭ
４０５は、オーディオ・リフォーマッティングを行う。

【００５６】当例においては、遠隔サーバ１１８から受
取られる如きイメージ・データは、要求側のクライアン
トのディスプレイに表示できるよりも高い解像度のもの
である。イメージＣＲＭ４０４に要求側のクライアント
１０２のディスプレイに対して適切な解像度のイメージ
・データを出力させる入力パラメータを用いて、イメー
ジＣＲＭ４０４の新たな状態が生成される。コンテキス
トは、イメージ・データをイメージＣＲＭ状態へ送り、
処理されたイメージ・データを再び受取る。コンテキス
トは、プロキシ・サーバ・アプリケーション４００に対
して、処理されたイメージ・データ（要求側のクライア
ント１０２のディスプレイに適切な解像度である）を送
ることによって、「ＰｕｓｈＤａｔａ」関数の呼出しか
ら戻り、アプリケーション４００は要求側のクライアン
ト１０２にイメージ・データを送り返す。クライアント
１０２は、このイメージ・データを用いて、イメージに
対してバックグラウンド・ページに残された空きスペー
スを埋め、これにより完成されたウェブ・ページを作
る。イメージ・データは、一連の塊りとして処理するこ
とができる。個々の塊りはプロキシ・サーバ・アプリケ
ーション、コンテキスト及び適切なＣＲＭを用いて処理
されて、先に述べたように再びプロキシ・サーバ・アプ
リケーションへ戻される。これによりストリーミングが
容易になる。

【００５７】リフォーマッティングが完了すると、メソ
ッドＤｅｌｅｔｅＣｏｎｔｅｘｔがプロキシ・サーバ・
アプリケーション４００により呼出される。コンテキス
トは初めから終りまでリフォーマット操作に従うので、
使用するプロキシ・サーバ・アプリケーション４００に
対するコンテキストに変換統計（総計算時間、二乗平均
誤差及び注目条件）を記憶することが可能である。この
理由から、プロキシ・サーバ・アプリケーション４００
は、コンテキストのライフタイムを完全に制御する。ＣＲＭ ＣＲＭは、コンテンツの変換に関係する特化された作業
を行う。マシンごとに１つのＣＲＭが例示されている
が、複数の線により、同じ事例を複数の変換上で同時に
働かせることができる。標準的なプロキシ・サーバ・プ
ラットフォームには４つのＣＲＭが設けられる。第１の
ＣＲＭはページ・パッチャである。第２のＣＲＭはトー
クナイザである。第３のＣＲＭはイメージ変換を取扱
い、データ・ストリーミングをサポートする。第４のＣ
ＲＭはオーディオ変換を取扱い、データ・ストリーミン
グをサポートする。これらＣＲＭの挙動は、各ＣＲＭに
固有の１組の入力制御パラメータを介して修正可能であ
る。要求ごとのこれら入力制御パラメータの選択は、規
則４０８を評価することによって行われる。各ＣＲＭの
設計者は、ＣＲＭが規則４０８に含まれるべきであるな
らば、サポートされる入力制御パラメータのリストを
（例えばＸＭＬファイルで）それらのデフォルト値及び
許容範囲と共に公開しなければならない。多くの場合に
おけるこれら入力制御パラメータは、それ自体のＣＲＭ
を書込む必要なく、オペレータに全ての必要な柔軟性を
与える。しかし、（例えば、特定のクライアントに見出
されるバグと取り組むため）非常に特化された処理の必
要が生じる場合、オペレータはカスタムＣＲＭ（カスタ
ムＣＲＭ及びカスタム・サブＣＲＭ）を書込む選択肢を
有する。これらカスタムＣＲＭは、プラットフォームに
提供されるＣＲＭの前に置くか、その後に置くか、或い
はこれを置換するかのいずれかである。存在するＣＲＭ
は、リスト４０９に示される。オペレータは、ＣＲＭを
リスト４０９へ付加することができる。オペレータはま
た、リスト４０９からＣＲＭを削除することもできる。

【００５８】オーディオ・モジュールのようなストリー
ミングＣＲＭが変換完了前に多数回呼出されるゆえに、
状態情報の一時的記憶が必須である。このような状態情
報は、モジュール状態オブジェクトに記憶され、コンテ
キスト自体に保持される。ストリーミング変換はまた、
複数のＣＲＭがデータ・ストリームの異なる部分で同時
に働く可能性をも生じる。従って、コンテキストはＣＲ
Ｍ識別子（割当てられたＩＤ又はＣＲＭポインタ）でア
クセスされるモジュール状態のリストを実際に保持す
る。同様に、ＣＲＭごとにバッファリングが行われ、こ
れらバッファはモジュール状態に記憶される。

【００５９】ＣＲＭインターフェースは、４つの関数、
すなわちＤｉｇｅｓｔＰａｒａｍｓ、ＣｒｅａｔｅＮｅ
ｗＳｔａｔｅ、ＤｅｌｅｔｅＳｔａｔｅ及びＩｎｉｔｉ
ａｌｉｚｅを含む。

【００６０】ＨＲＥＳＵＬＴ ＤｉｇｅｓｔＰａｒａｍ
ｓ（［ｉｎ］ＲａｗＰａｒａｍＴｙｐｅ ｒａｗＰａｒ
ａｍｓ、［ｏｕｔ］ＩＷｔｖＣＲＭＰａｒａｍＴｙｐｅ
＊＊ｄｉｇＰａｒａｍｓ）。この関数「ＤｉｇｅｓｔＰ
ａｒａｍｓ」は、規則がプロキシ・サーバ１０８の初期
設定時及び規則４０８がＣＡＣＩＳインターフェース４
０６で変更されるときに呼び出される。生のテキストの
入力制御パラメータは、タグ値の対の簡単なセミコロン
で区切られたストリング即ち他の構成であり、或いは、
これら入力制御パラメータはＣＲＭにより他の方法で個
々に調べられる。ＣＲＭは、生の入力制御パラメータを
構文解析し、これらの生の入力制御パラメータを、形態
がそれ自体及びそのモジュール状態に対してのみ知られ
ているコンパクトで最適化された構造へ変換する。この
ような最適化されたフォーマットは、要約されたパラメ
ータとして知られ、一般ＣＯＭインターフェース・ポイ
ンタを介してＣＲＭコンフィギュレーション・オブジェ
クトへ返される。このように、フレームワークは、要約
されたパラメータの内部構造を正確に指定し或いは知る
ことなく、前記パラメータから（コンテンツをログにダ
ンプするなどの）或るベース・レベルの機能を要求する
ことができる。これら要約されたパラメータは、コンフ
ィギュレーション・オブジェクト４０７の規則部４０８
における規則の内部表示（規則ツリー）にＣＲＭポイン
タと共に記憶される。コンテンツの変換が始められる毎
に、生のパラメータではなく要約されたパラメータが用
いられる。従って、入力パラメータの構文解析、圧縮、
最適化及び連結済み検査の作業は、システムの始動時に
各規則毎に１回だけ行われる。

【００６１】ＨＲＥＳＵＬＴ ＣｒｅａｔｅＮｅｗＳｔ
ａｔｅｓ （［ｉｎ］ＩＷｔｖＣＲＭＰａｒａｍＴｙｐ
ｅ＊ｐａｒａｍｓ、［ｉｎ］ＩＷｔｖＣＲＭＣｏｎｔｅ
ｘｔ＊ｃｏｎｔｅｘｔ、［ｏｕｔ］ＩＷｔｖＣＲＭＳｔ
ａｔｅｓ＊＊ｍｏｄｕｌｅＳｔａｔｅ）。この関数は、
変換に呼出される各ＣＲＭごとに１回コンテキストによ
り呼出される。このコンテキストは次に、モジュール状
態と相互作用してデータを処理する。ＣＲＭは、同じ変
換についての複数の呼出しを参照するため、パラメータ
をモジュール状態に記憶する。

【００６２】ＨＲＥＳＵＬＴ ＤｅｌｅｔｅＳｔａｔｅ
（［ｉｎ］ＩＷｔｖＣＲＭＳｔａｔｅ＊ｍｏｄｕｌｅＳ
ｔａｔｅ）。この関数は、変換が完了してＣＲＭの状態
情報がそれ以上必要でないときに呼出される。ＣＲＭ状態 ＣＲＭ状態は、到達するデータがしばしば塊りで処理さ
れるので，必要なオブジェクトである。このコンテキス
トは、新たなデータの到着を待ちながら、ＣＲＭの作業
状態（例えば、パラメータと一時データ）を記憶する方
法を必要とする。ＣＲＭＳｔａｔｅ自体は、変換作業
（この作業は図５において行われるように、ＣＲＭの内
部要素と見なすことができる）を行う。ＣＲＭＳｔａｔ
ｅインターフェースは４つの機能、すなわち、Ｐｒｏｃ
ｅｓｓＤａｔａ、ＩｓＳｔｒｅａｍｉｎｇ、Ｍｉｎｉｍ
ｕｍＩｎｐｕｔＤａｔａ、ＧｅｔＳｐｏｏｌ、及びＧｅ
ｔＳｔａｔｅを有する。データは、コンテキストにより
ＣＲＭＳｔａｔｅを通して送られ、ＰｒｏｃｅｓｓＤａ
ｔａと共にコンテキストへ返される。コンテキストは、
２つの関数「ＩｓＳｔｒｅａｍｉｎｇ」及び「Ｍｉｎｉ
ｍｕｍＩｎｐｕｔＤａｔａ」を用いて、どのように到来
データを最もよくバッファするかを決定する。部分的に
到来するデータは、ストリーミングが可能である場合に
のみ、且つ利用可能なデータ量がストリーミングのため
の最小入力データを越える場合に、ＣＲＭＳｔａｔｅへ
渡される。さもなければ、コンテキストはより多くのデ
ータが到来するまでデータをバッファする。ＧｅｔＳｐ
ｏｏｌは、コンテキストとモジュール状態間の不要なデ
ータ複写を避ける１つの方法である。要するに、これら
データは有効な方法で同じデータ領域を共有する。Ｇｅ
ｔＳｔａｔｅｓは、コンテキストがどんな種類の特定の
変換がモジュール状態により行われているかを知らない
としても、一般統計的情報をモジュールの状態から抽出
する１つの方法である。この統計は、統計構造に対する
或る最小要件（例えば、そのコンテンツをログ・ファイ
ルへ出力すること）を指示する一般ＣＯＭインターフェ
ース・ポインタを介して、コンテキストへ返される。従
って、プラットフォーム・ソフトウエアは、プラットフ
ォーム・オペレータ又は第三者のソフトウエア・ベンダ
により書かれた変換に対してさえも、計量の計算及び
（又は）コンテンツ変換統計の収納が可能である。コンテキスト コンテキストは、元の及びその時の要求変数、モジュー
ル状態及びバッファされた入力データを含む特定の変換
のための情報を記録する。データはしばしばサーバによ
り塊りで受取られるので、変換は更に多くのデータが得
られるまで留保される。コンテキストは、どのＣＲＭが
データ・ストリームについて働いているかを記録する。
これらＣＲＭがストリーミングしているならば、コンテ
キストはただちにデータを処理のためＣＲＭへ送る。非
ストリーミング変換では、コンテキストはＳＴＲＥＡＭ
ＥＮＤ標識が受取られるまでＣＲＭに対するデータを
バッファする。この時点で、コンテキストはＣＲＭを処
理のため呼出す。

【００６３】コンテキストは、変換が始まるとき、規則
４０８の評価により生成されるＣＲＭリストを維持する
ことによって、変換に関わったＣＲＭを追跡する。この
リストは、ポインタと、変換が進行するに伴いコンテキ
ストが更新しなければならない各ポインタごとのフラグ
とを含む。フラグは、１）ＣＲＭがデータ・ストリーム
に作用しているが一時停止されることを意味するＶａｌ
ｕｅ ＷＴＶ ＣＲＭ ＡＣＴＩＶＥ、２）ＣＲＭがスト
リーム又はデータ・セット全体についての作業を完了し
たことを意味するＶａｌｕｅ ＷＴＶ ＣＲＭ ＦＩＮ
ＩＳＨＥＤ、及び３）将来の呼出しのためにＣＲＭが予
定されることを意味するＶａｌｕｅＷＴＶ ＣＲＭ Ｐ
ＥＮＤＩＮＧの値を持つ。

【００６４】規則４０８の評価により生じるリストは、
要求変数及び（又は）クライアント能力の関数である。
このクライアント能力は、プロキシ・サーバ・アプリケ
ーションにより決定され（プロキシ・サーバはクライア
ント能力を表わす情報からクライアント能力を決定する
ことができ、或いはクライアント能力自体がクライアン
トからプロキシ・サーバへ送られ）て、変換中は一定の
ままであるが、要求変数の一部（すなわち、コンテンツ
・タイプ及びコンテンツ長）はリフォーマットの間に変
化し得る。要求変数が変化する場合は、規則は評価し直
され、これにより、おそらくは異なるＣＲＭリストを生
成する。ルーピングを阻止するために、コンテキストは
新たに生成されるリストからＷＴＶ ＣＲＭ ＰＥＮＤ
ＩＮＧに等しいフラグによりＣＲＭを呼出すだけであ
る。

【００６５】コンテキスト・インターフェースは、Ｐｕ
ｓｈＤａｔａ、Ｉｎｉｔｉａｌｉｚｅ、ＧｅｔＯｒｉｇ
ＣｏｎｔｅｎｔＬｅｎｇｔｈ、ＧｅｔＯｒｉｇＣｏｎｔ
ｅｎｔＴｙｐｅ、ＧｅｔＣｕｒＣｏｎｔｅｎｔＬｅｎｇ
ｔｈ、ＧｅｔＣｕｒＣｏｎｔｅｎｔＴｙｐｅ、ＧｅｔＵ
ｓｅｒＡｇｅｎｔ、ＧｅｔＣｌｉｅｎｔＣａｐａｂｉｌ
ｉｔｉｅｓ、ＳｅｔＣｕｒＣｏｎｔｅｎｔＬｅｎｇｔ
ｈ、及びＳｅｔＣｕｒＣｏｎｔｅｎｔＴｙｐｅの１０の
関数を呼出す。

【００６６】ＨＲＥＳＵＬＴ ＰｕｓｈＤａｔａ（［ｉ
ｎ］ＳｔｒｅａｍＴｙｐｅ＊ｐＩｎＳｔｒｅａｍ、［ｉ
ｎ］ＳｔｒｅａｍＴｙｐｅ＊ｐＯｕｔＳｔｒｅａｍ、Ｓ
ｔｒｅａｍＳｔａｔｕｓＴｙｐｅ＊ｓｔｒｅａｍＳｔａ
ｔｕｓ）。この関数は、プロキシ・サーバ・アプリケー
ションにより呼出されてデータをコンテキストへ送り、
データをコンテキストから回収する。変換が非ストリー
ミングのＣＲＭにより行われるならば、プロキシ・サー
バ・アプリケーションは、データを戻す前に（ｓｔｒｅ
ａｍＳｔａｔｕｓ＝ＳＴＲＥＡＭ ＥＮＤまで）データ
を数回プッシュすることを予期し得る。最後のＰｕｓｈ
Ｄａｔａ呼出しが戻るとき、ファイル全体が戻されねば
ならない。ストリーミング変換の場合は、データは呼出
し毎にＰｕｓｈＤａｔａへ戻される。ｓｔｒｅａｍＳｔ
ａｔｕｓは、１）更に多くのデータが予期されることを
意味するＶａｌｕｅ ＳＴＲＥＡＭ ＣＯＮＴ、２）デ
ータの適合性又は予期される終りを示すＶａｌｕｅ Ｓ
ＴＲＥＡＭ ＥＮＤ、及び３）データの早すぎるか予期
しない終り及び（又は）ネットワークの障害を示すＶａ
ｌｕｅ ＳＴＲＥＡＭ ＥＲＲＯＲの値のうちの１つを
持ち得る。

【００６７】ＨＲＥＳＵＬＴ Ｉｎｉｔｉａｌｉｚｅ
（［ｉｎ］ ｕｎｓｉｇｎｅｄ ｉｎｔ ｃｏｎｔｅｎ
ｔＬｅｎｇｔｈ、［ｉｎ］ＢＳＴＲ ｃｏｎｔｅｎｔＴ
ｙｐｅ、［ｉｎ］ＢＳＴＲ ｕｓｅｒＡｇｅｎｔ、［ｉ
ｎ］ＣｌｉｅｎｔＣａｐＴｙｐｅ＊ｃｌｉｅｎｔＣａｐ
ｓ、［ｉｎ］ＣｏｎｆｉｇＴｙｐｅ＊ｃｕｒＣｏｎｆｉ
ｇ）。この関数は、ＣｒｅａｔｅＮｅｗＣｏｎｔｅｘｔ
関数により呼出される。コンテキストは、プロキシ・サ
ーバ・アプリケーション及びＣＲＭにより後で使用され
る先頭の４つの引数を記憶する。各コンテキストは、こ
れが生成されたコンフィギュレーションに対するポイン
タを保持する。このように、たとえ新たなコンフィギュ
レーションが変換の過程において生成されても、変換は
古いほうのコンフィギュレーションを使用し続けること
になる。

【００６８】次の６つの関数、即ち、ＨＲＥＳＵＬＴ
ＧｅｔＯｒｉｇＣｏｎｔｅｎｔＬｅｎｇｔｈ（［ｏｕ
ｔ］ ｕｎｓｉｇｎｅｄ ｉｎｔ＊ｏｒｉｇＣｏｎｔｅ
ｎｔＬｅｎｇｔｈ）；ＨＲＥＳＵＬＴ ＧｅｔＯｒｉｇ
ＣｏｎｔｅｎｔＴｙｐｅ（［ｏｕｔ］ＢＳＴＲ＊ｏｒｉ
ｇＣｏｎｔｅｎｔＴｙｐｅ）；ＨＲＥＳＵＬＴ Ｇｅｔ
ＣｕｒＣｏｎｔｅｎｔＬｅｎｇｔｈ（［ｏｕｔ］ ｕｎ
ｓｉｇｎｅｄ ｉｎｔ＊ｃｕｒＣｏｎｔｅｎｔＬｅｎｇ
ｔｈ）；ＨＲＥＳＵＬＴ ＧｅｔＣｕｒＣｏｎｔｅｎｔ
Ｔｙｐｅ（［ｏｕｔ］ＢＳＴＲ＊ｃｕｒＣｏｎｔｅｎｔ
Ｔｙｐｅ）；ＨＲＥＳＵＬＴ ＧｅｔＵｓｅｒＡｇｅｎ
ｔ（［ｏｕｔ］ＢＳＴＲ＊ｕｓｅｒＡｇｅｎｔ）及びＨ
ＲＥＳＵＬＴ ＧｅｔＣｌｉｅｎｔＣａｐａｂｉｌｉｔ
ｉｅｓ（［ｏｕｔ］ＣｌｉｅｎｔＣａｐＴｙｐｅ＊＊ｃ
ｌｉｅｎｔＣａｐｓ）は、元の及び更新された要求変数
を取得するためプロキシ・サーバ・アプリケーションに
より使用される。下記の２つの関数は、変換中に要求変
数を更新するためＣＲＭにより使用される。元の値とは
異なる値でこれらの関数を呼出すと、規則の再評価を生
じる。ｕｓｅｒＡｇｅｎｔ及びｃｌｉｅｎｔＣａｐｓ
は、所与の要求に対して変化せず、従ってこれらは類似
した「セット」関数を持たない。この２つの関数は、Ｈ
ＲＥＳＵＬＴ ＳｅｔＣｕｒＣｏｎｔｅｎｔＬｅｎｇｔ
ｈ（［ｉｎ］ ｕｎｓｉｇｎｅｄ ｉｎｔ ｎｅｗＣｏ
ｎｔｅｎｔＬｅｎｇｔｈ）及びＨＲＥＳＵＬＴ Ｓｅｔ
ＣｕｒＣｏｎｔｅｎｔＴｙｐｅ（［ｉｎ］ＢＳＴＲ ｎ
ｅｗＣｏｎｔｅｎｔＴｙｐｅ）である。要求変数のどれ
かが変換中に変更されると、この変数は規則の再評価及
び保留中のモジュール・リストにおける可能な変更に至
る。適合性の宣言 遠隔サーバ１１８におけるウェブ・コンテンツもまたキ
ャッシュ４１４にキャッシュされる。クライアントがウ
ェブ・コンテンツを要求すると、プロキシ・サーバ・ア
プリケーション４００は、キャッシュされたウェブ・コ
ンテンツが、遠隔サーバ１１８からウェブ・コンテンツ
を回収する代わりに要求側のクライアントへ戻すのに、
及び、この新たに回収されたウェブ・コンテンツを要求
側のクライアントへ戻すのに適するかどうかを判定す
る。一例では、第１のクライアント１０２がウェブ・コ
ンテンツを要求する。プロキシ・サーバ１０８は、ウェ
ブ・コンテンツを回収し、回収されたウェブ・コンテン
ツをリフォーマットし、リフォーマットされたウェブ・
コンテンツをキャッシュ４１４に格納し、またリフォー
マットされたウェブ・コンテンツを再び第１の要求側の
クライアント１０２へ送る。第２のクライアント１０３
は、同じウェブ・コンテンツをプロキシ・サーバから要
求する。このキャッシュされたウェブ・コンテンツが第
２のクライアント１０３のクライアント能力に対して適
切なフォーマットであるならば、プロキシ・サーバは、
このキャッシュされたウェブ・コンテンツを再び第２の
クライアント１０３へ戻してウェブ・コンテンツに対す
る第２のクライアントのアクセスを迅速にする。一方、
キャッシュされたウェブ・コンテンツが第２のクライア
ント１０３に対して不適切なフォーマットであるならば
（例えば、第２のクライアント１０３は、キャッシュ４
１４にキャッシュされたウェブ・コンテンツの解読及び
（又は）使用を試みるものとすると、望ましくない方法
で機能することになる）、プロキシ・サーバはキャッシ
ュ時にキャッシュされたウェブ・コンテンツを送るので
はなく、このウェブ・コンテンツを第２の要求側のクラ
イアント１０３に対して適切なフォーマットで送るべき
である。プロキシ・サーバは、キャッシュされたウェブ
・フォーマットを変形した後、リフォーマットされたウ
ェブ・コンテンツを要求側のクライアントへ送るか、或
いはプロキシ・サーバは、ウェブ・コンテンツを遠隔サ
ーバから回収し、新たに回収されたウェブ・コンテンツ
を適切なフォーマットへリフォーマットし、次いでこの
リフォーマットされたコンテンツを要求側のクライアン
トへ戻す。

【００６９】プロキシ・サーバ・アプリケーション４０
０は、一つの実施の形態においては、キャッシュされた
ウェブ・コンテンツに関する特定の情報を記憶すること
によって、特定のキャッシュされたウェブ・コンテンツ
が適するかどうかを決定する。第１のクライアントがウ
ェブ・コンテンツを要求し、プロキシ・サーバがこのウ
ェブ・コンテンツをリフォーマットすると、先に述べた
ように規則が評価される。要求の特定の要求変数及び
（又は）この要求に対して決定されたクライアント能力
に従って、個々の規則は真であるか、偽であるか評価さ
れる。真であると評価された各規則に対しては、リフォ
ーマットにおいて用いられるＣＲＭの順序付きリストと
ＣＲＭの動作を制御する入力制御パラメータとが、図５
に関して先に述べたように生成される。このような情報
と評価された特定の規則に対するポインタとは、キャッ
シュ４１４においてリフォーマットされたウェブ・コン
テンツと共にキャッシュされる。

【００７０】第２のクライアント１０３がプロキシ・サ
ーバ・アプリケーションからウェブ・コンテンツを要求
すると、第２の要求に対する要求変数及び（又は）クラ
イアント能力が、規則の評価のために用いられる。第１
の要求の場合と同様に、ＣＲＭのリスト及び関連した入
力制御パラメータが決定される。キャッシュされたウェ
ブ・コンテンツが第２のクライアント１０３に適するか
否かを判定するために、プロキシ・サーバ・アプリケー
ション４００は、真と評価された規則と、ＣＲＭのリス
トと、キャッシュされた関連する入力制御パラメータと
を、第２の要求に対して判定された規則と比較する。同
じ規則が用いられ、かつ同じ規則が真と評価されるなら
ば、キャッシュされたウェブ・ページが第２のクライア
ントへ送るのに適すると判定される。このような場合、
第２の要求に対して行われる処理は、第１の要求に対す
るものと同じである。

【００７１】一方、使用された規則又は真と評価された
規則が第１の要求に対する規則と違うならば、ウェブ・
コンテンツは第２のクライアントへ送るのに適さないと
判定される。従って、ウェブ・コンテンツは、第２の要
求に対して決定されたＣＲＭのリスト及び関連する入力
制御パラメータに従ってリフォーマットされる。

【００７２】適合性に対するこのような手法は第２の要
求に対する規則の再評価を介在させるが、他の手法も可
能である。１つの適切な手法では、要求側のクライアン
トのクライアント能力を用いて、キャッシュされた情報
が適切であるかどうかを判定する。例えば、一つの実施
の形態においては、第２のクライアント１０３のｘ軸の
解像度と、ｙ軸の解像度と、ビット深さのクライアント
能力とが用いられて、特定の解像度を持つキャッシュさ
れたイメージが第２のクライアントに適するか、或いは
このイメージが第２のクライアントへ与えられる前にリ
フォーマットされるべきかが決定される。イーメール・サーバ・アプリケーション モジュラーＣＲＦ及びＣＲＭリフォーマット・ソフトウ
エアが図５におけるプロキシ・サーバ・アプリケーショ
ン４００に関して記述されるが、プロキシ・サーバ・ア
プリケーション以外のアプリケーションも、このモジュ
ラーＣＲＦ及びＣＲＭリフォーマット・ソフトウエアを
使用することができる。イーメール・サーバ・アプリケ
ーションは、一つの実施の形態においては、このモジュ
ラーＣＲＦ及びＣＲＭリフォーマット・ソフトウエアを
用いて、イーメール・メッセージにおける添付書類をク
ライアントが解読できるフォーマットへリフォーマット
する。

【００７３】第１のステップにおいて、イーメール・メ
ッセージはプロキシ・サーバ１０８で走るメール・アプ
リケーションにより受取られる。このイーメール・メッ
セージは、メール記憶部に格納される。次に、クライア
ントは、サーバ１０８とイーメール・サーバとの接続を
確保する。このような接続が確保されると、クライアン
トはクライアント能力を表わす情報をイーメール・サー
バへ送る。実際のクライアント能力がサーバへ送られ、
或いはクライアント能力を表わす情報がサーバへ送られ
るので、サーバはクライアント能力データベース（ＣＣ
Ｄ）を用いて、関連するクライアント能力を決定する。
イーメール・サーバは、クライアントに対するイーメー
ル・メッセージをメール記憶部から回収し、クライアン
ト能力を入力として用いて規則を評価し、図５に関して
先に述べた事例においてＨＴＭＬが処理された方法と類
似する方法でイーメール・メッセージを処理する。この
場合にのみ、処理がイーメール・メッセージ自体で行わ
れる必要はない。従って、ＣＲＭは呼出されない。イー
メール・メッセージは、直ちにはクライアントへ戻され
ず、処理が添付書類について行われる。イーメール・サ
ーバは、添付書類をイーメール・メッセージから切り離
し、その後に添付書類をリフォーマットする。イメージ
が図５に関して先に述べた事例においてリフォーマット
された方法と同様に、新たなコンテキストが生成され、
クライアントのクライアント能力が用いられて、どのＣ
ＲＭが添付書類を処理するか、及びこれらＣＲＭの動作
を制御するためどの入力制御パラメータが用いられるか
を判定する。添付書類のデータは次に処理のため適切な
ＣＲＭへ入れられ、処理されたデータはコンテキストへ
戻される。いったん添付書類のリフォーマットが完了す
ると、添付書類はイーメール・メッセージへ再び挿入さ
れ、イーメール・メッセージがクライアントへ送られ
る。例えば、クライアントが第１のイメージ・フォーマ
ットの添付書類を解読することができないが第２のイメ
ージ・フォーマットのイメージは解読できるならば、ま
た、クライアントに対するイーメールが第１のイメージ
・フォーマットにおける添付書類を含むイーメール・サ
ーバで受取られるものとすれば、イーメール・サーバ
は、クライアント能力を用いて、クライアントへイーメ
ールを返送する前に添付書類を第２のイメージ・フォー
マットへリフォーマットする。従って、クライアント
は、元のリフォーマットされない添付書類は解読できな
くても、イーメールの添付書類を解読することができ
る。一部の実施の形態では、イーメールがリフォーマッ
トされ、イーメール記憶部にリフォーマットされたフォ
ームで格納され、その結果、クライアントが接続を確立
してイーメール・メッセージを回収するとき、クライア
ントはリフォーマットされたイーメール・メッセージを
受取る。他の実施の形態においては、イーメールはリフ
ォーマットされたフォーマットでは格納されず、元のフ
ォーマットでイーメール記憶部に格納される。クライア
ントがイーメールを要求すると、イーメール・メッセー
ジは、クライアントへ返送される直前に回収され、リフ
ォーマットされる。

【００７４】本発明については教示の目的のため特定の
実施の形態に関して記述したが、本発明はこれに限定さ
れることはない。一部の実施の形態では、クライアント
能力を表わす情報は要求側のクライアントからサーバへ
送られる実際のクライアント能力であるが、他の実施の
形態においては、クライアント能力を表わす情報は要求
側のクライアントのクライアント能力を決定するためサ
ーバにより用いられる情報である。一部の実施の形態で
は、プロキシ・サーバは、クライアントから要求変数
（例えば、ユーザ・エージェント）を受取るが、他の要
求変数（例えば、コンテンツ長及びコンテンツ・タイ
プ）は遠隔サーバから受取る。ＣＯＭプログラミング規
格以外の従来のプログラミング手法は、本発明の特質に
よるモジュラー・サーバ・プラットフォームのモジュラ
ー特質を具現するために用いることができる。本発明に
よる方法の諸ステップを実施するソフトウエアは、コン
ピュータ読み取り可能媒体に格納することができる。コ
ンピュータ可読媒体の事例は、磁気記憶媒体、光学的記
憶媒体及び半導体メモリを含む。

【００７５】従って、本文に述べた実施の形態の諸特徴
の様々な修正、応用及び組合わせは、頭書の特許請求の
範囲に記載される如き発明の範囲から逸脱することなく
実施可能である。

【図面の簡単な説明】

【図１】コンテンツをリフォーマットするプロキシ・サ
ーバを含む従来技術のネットワークを示す図である。

【図２】本発明の一特質によるシステム１００を示す図
である。

【図３】図２のシステム１００の動作による本発明の方
法を示すフローチャートである。

【図４】図２のシステム１００の動作による別の方法を
示すフローチャートである。

【図５】図２のシステム１００のモジュラー・プロキシ
・サーバ１０８の動作例を示す図である。

【図６】規則のテキスト・ファイルの事例を示す図であ
る。

【図７】図５のトークナイザＣＲＭの動作を示す図であ
る。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェイ・ディー・ログ アメリカ合衆国カリフォルニア州95177, サンホゼ，オルセン・ドライブ 3382

Claims (52)

【特許請求の範囲】
1. 【請求項１】 第１のモジュールと第２のモジュールと
   を含むプロキシ・サーバで、遠隔サーバからコンテンツ
   を回収するステップと、 前記第１のモジュールを用い且つ前記第２のモジュール
   は用いずに、前記コンテンツをリフォーマットして第１
   のリフォーマットされたコンテンツを得るステップと、 前記第２のモジュールを用い且つ第１のモジュールは用
   いずに、前記コンテンツをリフォーマットして第２のリ
   フォーマットされたコンテンツを得るステップと、 第１のクライアントからのコンテンツに対する要求を前
   記プロキシ・サーバで受取るステップと、 前記プロキシ・サーバから前記第１のクライアントへ前
   記第１のリフォーマットされたコンテンツを供給するス
   テップと、 第２のクライアントからのコンテンツに対する要求を前
   記プロキシ・サーバで受取るステップと、 前記プロキシ・サーバから前記第２のクライアントへ前
   記第２のリフォーマットされたコンテンツを供給するス
   テップと、を含む方法。
2. 【請求項２】 前記第１のモジュールが、前記プロキシ
   ・サーバの稼働中に該プロキシ・サーバに動的にリンク
   される実行可能コードの一部であり、前記第２のモジュ
   ールが、前記プロキシ・サーバの稼働中に該プロキシ・
   サーバに動的にリンクされる実行可能コードの一部であ
   る、請求項１記載の方法。
3. 【請求項３】 前記プロキシ・サーバから前記第１のク
   ライアントに前記第１のリフォーマットされたコンテン
   ツを供給するステップが、該第１のリフォーマットされ
   たコンテンツを、前記第１のクライアントのクライアン
   ト能力を表わし且つ該第１のクライアントからの要求に
   存在する情報に少なくとも部分的に基いて第１のクライ
   アントへ供給することを決定するステップを含み、 前記プロキシ・サーバから前記第２のクライアントに前
   記第２のリフォーマットされたコンテンツを与える前記
   ステップが、該第２のリフォーマットされたコンテンツ
   を、前記第２のクライアントのクライアント能力を表わ
   し且つ該第２のクライアントからの要求に存在する情報
   に少なくとも部分的に基いて前記第２のクライアントへ
   供給することを決定するステップを含む、請求項２記載
   の方法。
4. 【請求項４】 前記第１のクライアントのクライアント
   能力が該第１のクライアントにおけるメモリの記憶スペ
   ース量の表示を含み、前記第２のクライアントのクライ
   アント能力が該第２のクライアントにおけるメモリの記
   憶スペース量の表示を含む、請求項３記載の方法。
5. 【請求項５】 前記第１のクライアントのクライアント
   能力が該第１のクライアントにおけるディスクの記憶ス
   ペース量の表示を含み、前記第２のクライアントのクラ
   イアント能力が該第２のクライアントにおけるディスク
   の記憶スペース量の表示を含む、請求項３記載の方法。
6. 【請求項６】 前記第１のクライアントのクライアント
   能力が該第１のクライアントのディスプレイの解像度の
   表示を含み、前記第２のクライアントのクライアント能
   力が該第２のクライアントのディスプレイの解像度の表
   示を含む、請求項３記載の方法。
7. 【請求項７】 前記第１のクライアントのクライアント
   能力が該第１のクライアントに対する接続の性能の表示
   を含み、前記第２のクライアントのクライアント能力が
   該第２のクライアントに対する接続の性能の表示を含
   む、請求項３記載の方法。
8. 【請求項８】 前記第１のクライアントに対する接続が
   ダイアルアップ接続であり、前記第２のクライアントに
   対する接続がダイアルアップ接続である、請求項７記載
   の方法。
9. 【請求項９】 前記第１のクライアントに対する接続が
   ＤＳＬ接続であり、前記第２のクライアントに対する接
   続がＤＳＬ接続である、請求項７記載の方法。
10. 【請求項１０】 前記第１のクライアントに対する接続
    がケーブル・モデム接続であり、前記第２のクライアン
    トに対する接続がケーブル・モデム接続である、請求項
    ７記載の方法。
11. 【請求項１１】 前記第１のクライアントのクライアン
    ト能力が該第１のクライアントにおけるキャッシュのメ
    モリ量の表示を含み、前記第２のクライアントのクライ
    アント能力が該第２のクライアントにおけるキャッシュ
    のメモリ量の表示を含む、請求項３記載の方法。
12. 【請求項１２】 前記第１のクライアントのクライアン
    ト能力が該第１のクライアントが特定のイメージ・デー
    タ・フォーマットに対して動作可能にされることの表示
    を含み、前記第２のクライアントのクライアント能力が
    該第２のクライアントが特定のイメージ・データ・フォ
    ーマットに対して動作可能にされることの表示を含む、
    請求項３記載の方法。
13. 【請求項１３】 前記第１のクライアントのクライアン
    ト能力が該第１のクライアントが特定のオーディオ・デ
    ータ・フォーマットに対して動作可能にされることの表
    示を含み、前記第２のクライアントのクライアント能力
    が該第２のクライアントが特定のオーディオ・データ・
    フォーマットに対して動作可能にされることの表示を含
    む、請求項３記載の方法。
14. 【請求項１４】 前記第１のクライアントのクライアン
    ト能力が該第１のクライアントのプロセッサのクロック
    速度の表示を含み、前記第２のクライアントのクライア
    ント能力が該第２のクライアントのプロセッサのクロッ
    ク速度の表示を含む、請求項３記載の方法。
15. 【請求項１５】 前記プロキシ・サーバから前記第１の
    クライアントに前記第１のリフォーマットされたコンテ
    ンツを供給する前記ステップが、該第１のリフォーマッ
    トされたコンテンツを、前記第１のクライアントからの
    要求の要求変数に少なくとも部分的に基いて、該第１の
    クライアントへ供給することを決定するステップを含
    み、 前記プロキシ・サーバから前記第２のクライアントに前
    記第２のリフォーマットされたコンテンツを供給する前
    記ステップが、該第２のリフォーマットされたコンテン
    ツを、前記第２のクライアントからの要求の要求変数に
    少なくとも部分的に基いて、該第２のクライアントへ供
    給することを決定するステップを含む、請求項２記載の
    方法。
16. 【請求項１６】 第１のクライアントと、第２のクライ
    アントと、プロキシ・サーバと、遠隔サーバとを含むコ
    ンピュータ・ネットワーク・システムにおける方法であ
    って、 前記遠隔サーバからのコンテンツに対する前記第１のク
    ライアントからの第１の要求を前記プロキシ・サーバで
    受取るステップと、 前記第１のクライアントの能力を表わす第１の情報を取
    得するステップと、 前記プロキシ・サーバから前記第１のクライアントへ、
    第１の方法でリフォーマットされたコンテンツを供給す
    るステップと、 前記遠隔サーバからのコンテンツに対する前記第２のク
    ライアントからの第２の要求を前記プロキシ・サーバで
    受取るステップと、 前記第２のクライアントの能力を表わす第２の情報を取
    得するステップと、 前記プロキシ・サーバから前記第２のクライアントへ、
    第２の方法でリフォーマットされたコンテンツを供給す
    るステップと、を含む方法。
17. 【請求項１７】 前記プロキシ・サーバが、動的にリン
    ク可能な実行可能コードの第１のモジュールと、動的に
    リンク可能な実行可能コードの第２のモジュールとを含
    み、 更に、 前記第１の方法でフォーマットされたコンテンツを生成
    するように前記遠隔サーバからのコンテンツをリフォー
    マットするため前記第１のモジュールを用いるが、前記
    第１の方法でリフォーマットされたコンテンツを生成す
    るためには前記第２のモジュールを用いないステップ
    と、 前記第２の方法でフォーマットされたコンテンツを生成
    するように前記遠隔サーバからのコンテンツをリフォー
    マットするため前記第２のモジュールを用いるが、前記
    第２の方法でリフォーマットされたコンテンツを生成す
    るためには前記第１のモジュールを用いないステップ
    と、を含む、請求項１６記載の方法。
18. 【請求項１８】 前記第１の情報が第１のソフトウエア
    作成番号を含み、前記第２の情報が第２のソフトウエア
    作成番号を含む、請求項１７記載の方法。
19. 【請求項１９】 前記第１の情報がソフトウエアのバー
    ジョン番号を含み、ぜんき第２の情報が第２のソフトウ
    エアのバージョン番号を含む、請求項１７記載の方法。
20. 【請求項２０】 前記プロキシ・サーバは、前記第１の
    情報の他に、前記第１の要求と関連するコンテンツ・タ
    イプの表示を受取って、前記第１のモジュールを用いて
    前記第１の方法でコンテンツをリフォーマットすること
    を決定するために前記コンテンツ・タイプの表示を用
    い、 前記プロキシ・サーバは、前記第２の情報の他に、前記
    第２の要求と関連するコンテンツ・タイプの表示を受取
    って、前記第２のモジュールを用いて前記第２の方法で
    コンテンツをリフォーマットすることを決定するために
    前記コンテンツ・タイプの表示を用いる、請求項１７記
    載の方法。
21. 【請求項２１】 前記第１の要求と関連するコンテンツ
    ・タイプの表示は遠隔サーバからの応答においてプロキ
    シ・サーバにより受取られ、前記第２の要求と関連する
    コンテンツ・タイプの表示は遠隔サーバからの応答にお
    いてプロキシ・サーバにより受取られる、請求項２０記
    載の方法。
22. 【請求項２２】 前記プロキシ・サーバは、前記第１の
    クライアントの能力を表わす情報を用いて第１のクライ
    アントのクライアント能力を決定し、該プロキシ・サー
    バは前記第１の要求と関連する要求変数情報を受取り、
    該プロキシ・サーバは、前記第１のモジュールを用いて
    前記遠隔サーバからのコンテンツをリフォーマットする
    ことを決定するために前記クライアント能力と前記要求
    変数情報とを用い、 前記プロキシ・サーバは、前記第２のクライアントの能
    力を表わす情報を用いて前記第２のクライアントのクラ
    イアント能力を決定し、該プロキシ・サーバは前記第２
    の要求と関連する要求変数の情報を受取り、該プロキシ
    ・サーバは、前記第２のモジュールを用いて前記遠隔サ
    ーバからのコンテンツをリフォーマットすることを決定
    するために前記クライアント能力と前記要求変数情報と
    を用いる、請求項１７記載の方法。
23. 【請求項２３】 前記第１の要求と関連する前記要求変
    数情報がコンテンツ・タイプであり、前記第２の要求と
    関連する要求変数の情報がコンテンツ・タイプである、
    請求項２２記載の方法。
24. 【請求項２４】 前記第１の要求と関連する前記要求変
    数情報がコンテンツ長であり、前記第２の要求と関連す
    る前記要求変数情報がコンテンツ長である、請求項２２
    記載の方法。
25. 【請求項２５】 前記第１の情報が前記第１のクライア
    ントのクライアント能力を含み、前記第２の情報が前記
    第２のクライアントのクライアント能力を含む、請求項
    １７記載の方法。
26. 【請求項２６】 前記第１の情報が前記第１のクライア
    ントとの接続の接続速度の表示を含み、前記第２の情報
    が前記第２のクライアントとの接続の接続速度の表示を
    含む、請求項１７記載の方法。
27. 【請求項２７】 前記第１の情報が前記第１のクライア
    ントのディスプレイの解像度の表示を含み、前記第２の
    情報が前記第２のクライアントディスプレイの解像度の
    表示を含む、請求項１７記載の方法。
28. 【請求項２８】 前記第１の情報が前記第１のクライア
    ントにおけるメモリ量の表示を含み、前記第２の情報が
    前記第２のクライアントにおけるメモリ量の表示を含む
    請求項１７記載の方法。
29. 【請求項２９】 前記プロキシ・サーバがトークナイザ
    ・モジュールとトークナイザ・サブモジュールとを含
    み、 前記プロキシ・サーバは、 トークンを出力するよう前記トークナイザ・モジュール
    にコンテンツを処理させるステップと、前記トークナイ
    ザ・サブモジュールにトークンを操作させるステップと
    により、前記第１の方法で、リフォーマットされたコン
    テンツを生成する、請求項１６記載の方法。
30. 【請求項３０】 プロキシ・サーバであって、 第１の方法でコンテンツをリフォーマットする第１の動
    的にリンク可能なモジュールと、 第２の方法でコンテンツをリフォーマットする第２の動
    的にリンク可能なモジュールと、 クライアントにより遠隔サーバから要求されるコンテン
    ツを回収し、第１のモジュールと第２のモジュールのど
    ちらを用いて、要求されたコンテンツをリフォーマット
    するかを決定するための手段であって、要求変数とクラ
    イアント能力とからなる群の１つに少なくとも部分的に
    基いて前記の決定を行う手段と、を備えるプロキシ・サ
    ーバ。
31. 【請求項３１】 前記手段が、前記群の１つを用いて、
    １組の規則を評価し、且つ、前記遠隔サーバからの要求
    されるコンテンツのリフォーマットに用いられるモジュ
    ールのリストを生成する、請求項３０記載のプロキシ・
    サーバ。
32. 【請求項３２】 前記規則を、前記第１のモジュール又
    は前記第２のモジュールを変更或いは再コンパイルする
    ことなく、変更することができる、請求項３１記載のプ
    ロキシ・サーバ。
33. 【請求項３３】 前記群の１つがクライアント能力であ
    る、請求項３２記載のプロキシ・サーバ。
34. 【請求項３４】 前記群の１つが、コンテンツ長、コン
    テンツ・タイプ及びユーザ・エージェントからなる群か
    ら得られる要求変数である、請求項３２記載のプロキシ
    ・サーバ。
35. 【請求項３５】 プロキシ・サーバであって、 クライアントにより要求されるコンテンツをリフォーマ
    ットする複数の方法のうちのどれかを決定するため規則
    のく身を評価する手段と、 前記規則の組を評価する前記手段を再コンパイルするこ
    となく、前記規則の組を変更する手段と、を備えるプロ
    キシ・サーバ。
36. 【請求項３６】 前記変更する手段が、規則情報を含む
    テキスト・ファイルを受取り、該変更する手段は、前記
    規則の組が変更されるように前記評価する手段へ前記規
    則情報を送る、請求項３５記載のプロキシ・サーバ。
37. 【請求項３７】 更に、 実行時に第１の方法でコンテンツをリフォーマットする
    第１の動的にリンク可能なモジュールと、 実行時に第２の方法でコンテンツをリフォーマットする
    第２の動的にリンク可能なモジュールと、を備え、 前記評価する手段が、前記第１の動的にリンク可能なモ
    ジュール或いは前記第２の動的にリンク可能なモジュー
    ルが、クライアントにより要求されるコンテンツをリフ
    ォーマットするかどうかを決定する、請求項３５記載の
    プロキシ・サーバ。
38. 【請求項３８】 インターネットに結合され且つ第１の
    オペレータにより動作される第１のモジュラー・プロキ
    シ・サーバであって、制御部と第１の組の規則と複数の
    動的にリンク可能なモジュールとを備え、前記制御部
    が、前記第１の組の規則の評価に基いて、前記複数の動
    的にリンク可能なモジュールのうちのどれが特定のウェ
    ブ・コンテンツを処理するかを決定する第１のモジュラ
    ー・プロキシ・サーバと、 インターネットに結合されて第２のオペレータにより動
    作される第２のモジュラー・プロキシ・サーバであっ
    て、制御部と第２の組の規則と複数の動的にリンク可能
    なモジュールとを備え、前記制御部が、前記第２の組の
    規則の評価に基いて、前記第１のモジュラー・プロキシ
    ・サーバには存在しない動的にリンク可能なモジュール
    を含む前記複数の動的にリンク可能なモジュールのうち
    のどれが特定のウェブ・コンテンツを処理するか、及び
    それが実質的に同じであるかを決定する第２のモジュラ
    ー・プロキシ・サーバと、を備えるシステム。
39. 【請求項３９】 前記第２の組の規則が前記第１の組の
    規則とは異なり、前記第２のオペレータが，前記第２の
    組の規則を変更し且つ前記第１の組の規則は変更しな
    い、請求項３８記載のシステム。
40. 【請求項４０】 前記第１のモジュラー・プロキシ・サ
    ーバの前記複数の動的にリンク可能なモジュールの１つ
    が、前記第２のモジュラー・プロキシ・サーバの前記複
    数の動的にリンク可能なモジュールの１つと同じであ
    り、 前記第１のモジュラー・プロキシ・サーバの前記複数の
    動的にリンク可能なモジュールの別のモジュールが前記
    第２のモジュラー・プロキシ・サーバの前記複数の動的
    にリンク可能なモジュールのいずれとも同じでない、請
    求項３８記載のシステム。
41. 【請求項４１】 前記第１のモジュラー・プロキシ・サ
    ーバが、トークナイザ・モジュールとトークナイザ・サ
    ブモジュールとを含み、前記トークナイザ・モジュール
    がウェブ・コンテンツをトークンへ変換し、前記トーク
    ナイザ・サブモジュールが前記トークン上で動作する、
    請求項３８記載のシステム。
42. 【請求項４２】 モジュラー・プロキシ・サーバをカス
    タマイズする方法であって、前記モジュラー・プロキシ
    ・サーバが、制御部と複数の動的にリンク可能なモジュ
    ールとを備え、該複数の動的にリンク可能なモジュール
    の第１のモジュールが第１の方法でコンテンツをリフォ
    ーマットし、前記複数の動的にリンク可能なモジュール
    の第２のモジュールが第２の方法でコンテンツをリフォ
    ーマットする方法において、 前記第１及び第２の動的にリンク可能なモジュールが前
    記モジュラー・プロキシ・サーバに存在した後に第３の
    動的にリンク可能なモジュールを生成するステップと、 前記第３の動的にリンク可能なモジュールを、前記制御
    部と前記第１の動的にリンク可能なモジュールと前記第
    ２の動的にリンク可能なモジュールと共に前記モジュラ
    ー・プロキシ・サーバに存在するように、前記モジュラ
    ー・プロキシ・サーバへロードするステップと、 前記制御部により、前記第３の動的にリンク可能なモジ
    ュールを用いて、前記モジュラー・プロキシ・サーバの
    クライアントにより要求されるコンテンツをリフォーマ
    ットするステップと、を含む方法。
43. 【請求項４３】 更に、（ａ）前記第３の動的にリンク
    可能なモジュールの生成前に、前記制御部と前記第１及
    び第２の動的にリンク可能なモジュールの少なくとも一
    方を用いてコンテンツをリフォーマットするステップを
    含み、 前記第３の動的にリンク可能なモジュールを生成する前
    記ステップが、前記制御部をコンパイルすることなく前
    記第３の動的にリンク可能なモジュールを取得するよう
    にコードをコンパイルすることを含み、 前記制御部により、前記第３の動的にリンク可能なモジ
    ュールを使用する前記ステップが、前記ステップ（ａ）
    において実行された同じ制御部を実行することを含み、
    該制御部が前記ステップ（ａ）後にはコンパイルされな
    い、請求項４２記載の方法。
44. 【請求項４４】 プロキシ・サーバであって、 複数のモジュールであって、該モジュールのうちの第１
    のモジュールが第１の方法でコンテンツをリフォーマッ
    トし、前記モジュールのうちの第２のモジュールが第２
    の方法でコンテンツをリフォーマットするモジュール
    と、 要求する第１のクライアントのクライアント能力に基い
    て、前記複数のモジュールのどれを前記第１のクライア
    ントにより要求されるコンテンツのリフォーマットにお
    いて用いるかを決定するソフトウエアと、 前記複数のモジュールのどれが前記第１のクライアント
    により要求されたコンテンツのリフォーマットにおいて
    用いられたかの表示と共に、前記要求されたコンテンツ
    を含むキャッシュと、を備えるプロキシ・サーバ。
45. 【請求項４５】 第２の要求側のクライアントのクライ
    アント能力に基いて、前記複数のモジュールのどれを前
    記第２のクライアントにより要求されたコンテンツのリ
    フォーマットにおいて用いるかを決定するソフトウエア
    を更に備え、該ソフトウエアもまた、前記第２のクライ
    アントにより要求されたコンテンツのリフォーマットに
    用いる前記複数のモジュールが、前記複数のモジュール
    のどれが前記第１のクライアントにより要求されたコン
    テンツのリフォーマットにおいて使用されたかの格納さ
    れた表示と一致するかを決定し、これが一致するなら
    ば、プロキシ・サーバがキャッシュされたコンテンツを
    前記第２の要求側のクライアントへ返すが、一致しなけ
    れば、前記プロキシ・サーバは、要求された前記コンテ
    ンツを遠隔サーバから回収し、該回収されたコンテンツ
    をリフォーマットし、次に回収されたコンテンツを前記
    第２のクライアントへ返す、請求項４４記載のプロキシ
    ・サーバ。
46. 【請求項４６】 前記第１のクライアントにより要求さ
    れたコンテンツのリフォーマットにおいて用いられたモ
    ジュールの動作を制御する入力制御パラメータが、前記
    第１のクライアントのクライアント能力に基いて決定さ
    れ、これら入力制御パラメータが、要求されたコンテン
    ツと、前記複数のモジュールのどれが前記第１のクライ
    アントにより要求されたコンテンツのリフォーマットに
    おいて用いられたかの表示と共に、キャッシュに格納さ
    れる、請求項４５記載のプロキシ・サーバ。
47. 【請求項４７】 前記第２のクライアントにより要求さ
    れたコンテンツのリフォーマットにおいて前記複数のモ
    ジュールのどれを用いるかを決定する前記ソフトウエア
    が、前記第２のクライアントの要求と関連する入力制御
    パラメータを決定し、前記第２のクライアントの要求に
    対して決定された前記入力制御パラメータがキャッシュ
    に格納された入力制御パラメータと一致するならば、キ
    ャッシュされた前記コンテンツのみが前記第２の要求側
    のクライアントへ返される、請求項４６記載のプロキシ
    ・サーバ。
48. 【請求項４８】 プロキシ・サーバにおいて、１組の規
    則の評価を実施して、第１のクライアントにより要求さ
    れるコンテンツのリフォーマットにおいて複数のモジュ
    ールのどれを用いるかを決定するステップと、 前記第１のクライアントにより要求されたコンテンツと
    関連して前記プロキシ・サーバにおけるキャッシュに格
    納される前記１組の規則の評価の結果を表わす情報を格
    納するステップと、 前記プロキシ・サーバにおいて、前記１組の規則の第２
    の評価を実施して、前記複数のモジュールのどれを第２
    のクライアントにより要求されるコンテンツのリフォー
    マットにおいて用いるかを決定するステップと、 前記１組の規則の前記第２の評価の結果を表わす情報を
    取得するステップと、 前記第２の評価の結果を表わす前記情報を、前記キャッ
    シュに格納された結果の評価を表わす情報と比較するス
    テップと、を含み、 前記比較が、前記第２の評価の結果を表わす情報が前記
    キャッシュに格納された評価を表わす情報と同じである
    ことを示すならば、該キャッシュに格納されたコンテン
    ツが前記第２のクライアントへ与えられるが、前記比較
    が、前記第２の評価の結果を表わす情報が前記キャッシ
    ュに格納された評価を表わす情報と同じでないことを示
    すならば、前記プロキシ・サーバが、前記第２の評価を
    表わす情報と一致するコンテンツをリフォーマットし、
    このようにリフォーマットされた該コンテンツを前記第
    ２のクライアントへ返す、方法。
49. 【請求項４９】 第１のフォーマットにおける添付書類
    は解読できないが第２のフォーマットにおける添付書類
    は解読することできるクライアントへ宛てられる第１の
    フォーマットにおける添付書類を持つイーメール・メッ
    セージをイーメール・サーバにおいて受取るステップ
    と、 前記クライアントのクライアント能力を表わす情報をク
    ライアントからイーメール・サーバにおいて受取るステ
    ップと、を含み、 前記イーメール・サーバが、クライアント能力を表わす
    情報を用いて添付書類を前記第２のフォーマットへリフ
    ォーマットし、 前記イーメール・サーバが、前記イーメール・メッセー
    ジと前記第２のフォーマットにおける添付書類とをクラ
    イアントへ与える、 方法。
50. 【請求項５０】 第１のフォーマットにおける添付書類
    は解読できず、第２のフォーマットにおける添付書類は
    解読することができるクライアントのクライアント能力
    を表わす情報に基いて、イーメールの添付書類を第１の
    フォーマットから第２のフォーマットへリフォーマット
    する手段と、 前記第２のフォーマットにおけるイーメール・添付書類
    をクライアントへ与える手段と、を備えるイーメール・
    サーバ。
51. 【請求項５１】 前記リフォーマット手段がページ・パ
    ッチャ・モジュールである、請求項５０記載のイーメー
    ル・サーバ。
52. 【請求項５２】 前記リフォーマット手段が、トークナ
    イザ・モジュールとトークナイザ・サブモジュールとを
    含み、前記トークナイザ・モジュールが添付書類をトー
    クンへ変換し、前記トークナイザ・サブモジュールが前
    記トークン上で動作する、請求項５０記載のイーメール
    ・サーバ。