JPH11507152A - リモート・プロキシ・システムおよび方法 - Google Patents

Abstract

(57)【要約】 保護されているコンピュータまたはコンピュータ・ネットワーク（５２）とワールド・ワイド・ウェブ(Ｗorld Ｗide Ｗeb - ＷＷＷ)(６８)との間のインタフェースが開示されている。このインタフェースは分割プロキシ・システム（６５、６６）を含み、このシステムはＴＣＰ／ＩＰ伝送を高レイテンシ・システムで起こる問題に影響されないスクリプト伝送にカプセル化することによって、ワイヤレス・モデムまたは他の低バンド幅ネットワークからのＷＷＷアクセスを大幅に向上している。この分割プロキシ・インタフェース（５６、６６）は圧縮、暗号化およびフィルタリングを行う能力も備え、ＷＷＷアクセス・ソフトウェアを自動的に更新または構成するといった目的のために、非送信請求伝送をサービス・プロバイダから受信することを可能にしている。

Description

【発明の詳細な説明】 リモート・プロキシ・システムおよび方法発明の背景 関連特許出願 米国特許出願第08/309,336号（1994年9月19日出願、発明者：Ｄavid Ｍathew Ｐepe、Ｌisa Ｂ.Ｂlitzer、Ｊames Ｊoseph Ｂrockman、Ｗilliam Ｃruz、Ｄwi ght Ｏmar Ｈakim、ＭichaelＫramar、ＤawnＤianＰetr、Ｊosefa Ｒamaroson、 Ｇerardo Ｒamirez、Ｙang-ＷeiＷang、およびＲobert Ｇ.Ｗhite）は本件出 願に関連する主題を開示しており、この米国出願を引用することにより、本明細 書の一部を構成するものである。 発明の分野 本発明は、私用コンピュータまたは私用コンピュータ・ネットワークと、ワイ ヤライン（有線）接続とワイヤレス（無線）接続の両方を使用するワールド・ワ イド・ウェブ（Ｗorld Ｗide Ｗeb-ＷＷＷ）との間の改良インタフェースに関す る。特に、本発明は、プロトコル変換、セキュリティおよび自動構成の特徴を備 えた改良ＷＷＷインタフェースに関する。 関連技術の説明 この５０年の間、人々が夢見ていたことは汎用情報データベースである。すな わち、世界中の人達がアクセス可能であるだけでなく、関連情報が容易に見つか るように、さらに、特定の要求を満たす最も関連のあるデータがユーザによって 即時に見つけられて、アクセスされるように編成されたデータである。 1960年代には、この考え方はさらに検討され、「ドキュバース(docuverse)」と いうビジョンが生まれ、あらゆる側面から見た人間と情報とのやりとりに、特に 教育分野において大変革がもたらされるになった。これらのビジョンを現実化し 、地球規模でこのビジョンを実現化することを可能にするテクノロジが現れたの はつい最近のことである。 インターネット(Ｔhe Ｉnternet)は大学、企業および政府の共同作業によって 発 達してきた。数年前に、米国国防総省は共同で研究を実施していた大学と私的団 体および、時には、企業のコンピュータ・ネットワークを相互接続することを開 始した。このネットワークのネットワークは、やがては、一般にインターネット またはワールド・ワイド・ウェブ(Ｗorld Ｗide Ｗeb-ＷＷＷ)と呼ばれているグ ローバル・ネットワークに発達するに至った。ＷＷＷの正式の説明は、「大規模 のドキュメントへの汎用アクセスを可能にすることを目的とした広域ハイパーメ ディア情報検索イニシアティブ」となっている。 ＷＷＷが普及して、一般に広く使用されるようになると、米国国防総省はＷＷ Ｗへの関与を縮小していった。今日では、インターネット上の多くの政府資金に 基づくリンクは、大学、会社などの間のローカル・エリア・ネットワ(Ｌocal Ａ rea Ｎetwork-ＬＡＮ)の相互接続を運営している商業目的の企業に移譲されてい る。 ＷＷＷは企業にとって極めて貴重な資源であること（電子メール（ｅメール） による通信、オンラインによる情報アクセスなどの目的のために）が実証されつ つあるが、企業が関心を持っているのは、コンピュータ・ネットワーク上にスト アされている自社の知的財産権、トレードシークレット、財務記録およびその他 の機密情報のセキュリティ（安全保護）である。また、電子破壊（コンピュータ 化情報を破壊または歪曲する目的でＷＷＷ上でコンピュータ・ネットワークに無 許可でアクセスすること）にも関心を持っている。 これらの関心事に応えるために、ＷＷＷへのある種の接続（コネクション）は「 ネットワーク・セキュリティ・ファイアウォール(Ｎetwork Ｓecurity Ｆirewa lls)」で保護されている。図１に示すように、ファイアウォールとは、私用コン ピュータまたはコンピュータ・ネットワーク（ＬＡＮ）１０とＷＷＷ １２との 間の接続をブリッジする特定のハードウェア部分および／またはソフトウェア部 分のことである。ファイアウォールの主目的は、保護すべきネットワークに入出 力されるデータ・トラフィックをスクリーニングすることである。ネットワーク 侵入者が検出されたとき、ファイアウールはデータ・トラフィックにふるいをか けて、侵入者のアクセスを不能にする機能をもっている。初期形態のインターネ ット・ファイアウォールでは、どのデータ・トラフィックが正しいか、正しくな いか、つまり、企業ユーザに関係するものか侵入者に関係するものかを確かめる ことが 一般的に困難であった。このことは、ファイル転送プロトコル(Ｆile Ｔransfer Ｐrotocol-ＦＴＰ)などのインターネット・アプリケーションの企業ユーザ（企 業内ＬＡＮ内の）にとっては、そのアプリケーションがファイアウォールによっ て誤ってブロックされることがあるために問題となっていた。望ましいトラフィ ックが妨げられないようにするためには、ファイアウォールは、ファイアウォー ルを通り抜けるアプリケーション・データに関するより多くの情報を必要として いた。 インターネットのエンジニアは、この要求に応えるためにインターネット・フ ァイアウォール上に「プロキシ(proxy)」サービスを設計した。これらのプロキ シは、ＦＴＰアプリケーションのような特定アプリケーションを完全に理解する コンピュータ・プロセスである。企業内ユーザが実行したいと思っているアプリ ケーションのタイプに基づいて複数のプロキシをファイアウォール・システムに 追加することは、ネットワーク管理者にとっては容易な問題となった。例えば、 ＷＷＷブラウザ（後に述べる）はハイパーテキスト・トランスポート・プロトコ ル(Ｈyper Ｔext Ｔransport Ｐrotocol-ＨＴＴＰ)プロキシを使用してハイパー テキスト・マークアップ言語(Ｈyper Ｔext Ｍarkup Ｌanguage-ＨＴＭＬ)ドキ ュメントを転送している。 ＷＷＷの使用を容易にするために、「ブラウジング」ソフトウェア６が開発さ れた。よく知られたＮetscape（商標）ブラウザやＭosaic（商標）ブラウザのよ うなブラウザを使用すると、ＷＷＷユーザはＷＷＷにリンクされたコンピュータ 上で利用可能な情報をブラウズすることができる。米国特許出願第08/309,336号 （以下、’３３６出願という）に記載されている、本件出願の被譲渡人による関 連発明では、コンピュータ・ネットワーク上のユーザが、統一化された手段を使 用して種々のメディアに単純な方法でアクセスすることを可能にしている。'３ ３６出願の発明では、ブラウジング・ソフトウェアを利用することにより、人々 による情報の表示方法と作成方法を変更した。つまり、この発明は最初の真のグ ローバル・ハイパーメディア・ネットワークを構築した。 ＨＴＴＰプロキシが受け持つ１つの役割は、保護ネットワーク１０内のブラウ ザまたはソフトウェア・アプリケーションからの要求を受信し、その要求をＷＷ Ｗ １２に中継することである。このプロキシはＷＷＷ １２からの保護コンピ ュータまたはネットワーク１０へのアクセスもモニタしている。従って、プロキ シ４を使用すると、システム管理者は保護ネットワーク１０とＷＷＷ １２の間 を流れる情報と要求をモニタすることができる。違法なアクティビティが見つか ると、プロキシ４はＷＷＷ １２との接続を中断することができる。このプロキ シ駆動型ファイアウォール（proxy-driven firewall）２，４を使用すると、企 業および類似の関心事をもつ企業はある程度のセキュリティを保ちながら、ＷＷ Ｗ１２の貴重資源を利用することができる。 コンピュータとソフトウェア・アプリケーションとを結ぶリンクをＷＷＷ上で 実現するために、コンピュータ化データの伝送を規律するプロトコルがいくつか 開発されている。あるプロトコルはＷＷＷ上を伝送されるデータを、受信側コン ピュータが認識できる標準的方法で編成している。コンピュータ・プロトコルの 開放型システム間相互接続（ＯＳＩ）モデルは７つの層からなっている。各層は 付加的な編成上の機能を追加していき、データの伝送を容易化している。 インターネット・プロトコル(Ｉnternet Ｐrotocol-ＩＰ)はＯＳＩモデルの第 ３層であり、インターネット上で話される基本的「言語」となっている。第４層 である伝送制御プロトコル(Ｔransmission Ｃontrol Ｐrotocol-ＴＣＰ)はＩＰ に含まれる、より特殊化されたプロトコルである。ＷＷＷを使用するには、コン ピュータはＩＰ、従って、ＴＣＰを組み込んでいるプロトコルを使用して通信で きなければならない。 インターネット・アクセスを取り巻くＷＷＷとテクノロジは爆発的な成長を遂 げている。多くの企業は、加入者が標準テレホニを使用してＷＷＷにアクセスす ることを可能にするまでに発達している。インターネット・サービス・プロバイ ダ(Ｉnternet Ｓervice Ｐrovider-ＩＳＰ)と呼ばれるグループは、これらのサ ービス・プロバイダの多くを代表している。 インターネット・アクセスのさらなる拡張が見込まれる分野として、広域ワイ ヤレス・データ・ネットワークがある。ワイヤレス・ネットワークには、セルラ ・ディジタル・パケット・データ(cellular digital packet data-ＣＤＰＤ。セ ルラキャリヤから提供されている）ネットワーク、Ｍobitex（商標）ネットワー ク（米国内のＲＡＭ Ｍobile dataによって提供されている）などの回線交換セ ルラ・ネ ットワーク、Ａrdis(商標)ネットワーク、および各国で台頭している多数のワイ ヤレス・データ・プロバイダがある。 上述したデータ・ネットワーク・プロバイダはすべて従来のインターネット・ プロトコル（ＩＰ）サービスを提供し、ＷＷＷと統合化できる能力を備えている 。データ速度は4,800 bpsから28,800bpsの範囲であり、そのレイテンシはミリ秒 単位から10秒の範囲である。 ＷＷＷの人気にもかかわらず、インターネットにアクセスするとき解決しなけ ればならない技術上の問題と、セキュリティ上の問題が残っている。これらの問 題のいくつかは、ＷＷＷにアクセスしようとするワイヤレス・システムの場合に は特に深刻である。 問題１ 最初の問題はデータ・レイテンシが原因で起こる問題である(詳細は後述する) 。データ・レイテンシとは、データがＷＷＷ内の種々のノードを通過するとき複 数のホップ(hop)と低速リンクで引き起こされる時間遅延のことである。この特 殊な問題はＷＷＷがワイヤレス・モデムを使用してアクセスされるときは、さら に悪化している。大部分の広域ワイヤレス・データ・ネットワークと一部のワイ ヤライン・データ・ネットワークは、元来ＴＣＰ／ＩＰプロトコルをサポートす る設計になっていない。レイテンシはＩＰデータをネットワークのオリジナル・ データ・プロトコルにカプセル化するとさらに増加する。 ＴＣＰはＷＷＷ上で伝送するデータを編成するとき、そのデータを離散的情報 「パケット」に分割する。そのあと、ＴＣＰは個々のパケットを送信する。各パ ケットは受信側システムに対する指示を含み、パケットはこの指示に従って完全 データ構造に再組み立てされて、送信される。また、各パケットは巡回冗長チェ ックも含んでおり、パケットが伝送中に壊されなかったか、あるいは分断されな かったかを受信側システムがチェックできるようになっている。 ＴＣＰは、複数のパケットを送信したあと、そのパケットが正しく受信された との受信側システムからの確認通知を待つように構成されているのが一般的であ る。データ・パケットを送信してから、その到着確認通知を受信するまでに要す る時間量はシステムの「レイテンシ」として知られている。 ＴＣＰはデータ・パケットが正しく受信されたとの確認通知を受信しないとき は、パケットが送信中に失われたものとみなして、パケットを再送信する。シス テムのレイテンシが余りに高くなると、ＴＣＰはパケットが失われたものと早合 点するため、オリジナル・パケットがそのデスティネーション（宛て先）に到着 する前にネットワークは同じデータ・パケットの再送であふれることになる。多 くのサービス・プロバイダは送信されるデータ・パケットごとにユーザに料金請 求しているので、これも１つの問題となっている。ＴＣＰが、まだ送信中のパケ ットと重複する不要なパケットでシステムをあふれさせると、ユーザの費用負担 は大幅に増加することになる。従って、ＴＣＰは高レイテンシの接続では正しく 動作できないことになる。システムのレイテンシがほぼ３秒から５秒の範囲を越 えると、ＴＣＰは誤動作を始めることになる。 ＷＷＷがＴＣＰをサポートしていない標準電話回線でアクセスされるときは、 ＴＣＰデータグラムは電話回線で送信できる形式にカプセル化（つまり、変換） されなければならない。このデータグラムは受信側コンピュータでアンパックさ れてから使用される。この手法は効果的であるが、伝送のレイテンシが増加する ことになる。 ワイヤレス・モデムを使用してＷＷＷにアクセスするとき起こる、もう１つの 問題はワイヤレス・ネットワークによって引き起こされるレイテンシの増加であ る。ワイヤレス・データ・ネットワークがサービスするエリアが広くなると、伝 送のバンド幅（bps 単位）が低下するのが一般的傾向である。例えば、米国で使 用されている現存ワイヤレス通信システムは毎秒4,800ビットのデータを送信す る能力をもっている。この結果、レイテンシは10秒までに達している。 ワイヤレスＷＷＷアクセスに関する現存の関連技術として次のものがある。 1.Ｃarnegie ＭellonＵniversityのＩnformation Ｎetworking Ｉnstitute,Ｗir eless Ａndrew Ｉnitiative、2．ＲutgersＵniversityのＷinlab，Ｄataman pro ject、3.Ｕniversity ofＷashingtonのＣＳ＆Ｅ，Ｍobisaic、4．Ｘerox社のＰa lo Ａlto Ｒesearch Ｃenter,ＲＤＡおよびvirtual officec omputing concepts 、5.Ｃomputer Ｎetworks＆ＩＳＤＮ Ｓystems Ｖolume 0028,Ｎumber 1-2 ＩＳ ＳＮ:0169-7552,Ｄec'98,"ＰＤＡs as Ｍobile ＷＷＷ Ｂrowsers",Ｇessler Ｓ .,Ｋotulla Ａ.、6.Ｇeneral Ｍagic社のＭagicap ＯＳ version of a ＷＷＷ browser with enhancements fo r Ｔelescript agent technology(Ｔelescriptエージエント・テクノロジ用の強 化機能を備えたＭagicap ＯＳバージョンのＷＷＷブラウザ)。 上記のプロジェクトおよび論文のすべては、ブラウザの修正、新しいプロトコ ルの規格（この場合もＴＣＰをベースとする）、またはワイヤレスおよび低バン ド幅のネットワークをインターネットに接続してＷＷＷアクセスを可能にする一 般的インタネットワーキング規格の定義を必要としている。 従って、高レイテンシのワイヤレスおよびワイヤライン・ネットワーク上のコ ネクションにおいて、ＴＣＰを変換する方法が要望されている。 問題２ 第２の問題は、現存のＷＷＷアクセス・ソフトウェアには、圧縮、暗号化、ま たはフィルタリングのための標準的メカニズムが備わっていないことである。圧 縮を行うと、情報の内容を変更することなくデータ・サイズが縮小されてネット ワーク上を伝送される。圧縮をサポートする大部分のプロトコルはブラウザから の外部ユーティリティを必要とし、データを伸張したあとで、多目的インターネ ット・メール・エクステンション(Ｍulitpurpose Ｉnternet Ｍail Ｅxtension-Ｍ ＩＭＥ、Ｎathaniel Ｂorenstein et.al ＲＦＣ1521)タイプの使用を通して有用 な出力をブラウザに戻すようにしている。 暗号化は、データ伝送を符号化したものである。暗号化を行うと、暗号化され たデータ伝送を無許可の当事者が理解し、アクセスすることがはるかに困難にな るのでセキュリティ（機密保護）が得られる。残念ながら、これらの望ましいサ ービスの一般的で、開放型の標準を、すべてのＷＷＷクライアント要求をサポー トするように作成できるという見通しがない。ＷＷＷソフトウェア（つまり、セ キュア・ソケット層(Ｓecure Ｓocket Ｌayer-ＳＳＬ)）での暗号化に関する標 準は発展途上にある。しかし、現在のコンピュータ・ハッキングのレベルでは、 暗号化に関するどの開放型標準も、インテグリティ（保全性）を長時間保持でき るという見通しがない。 従って、大部分のアドバンスド・ブラウジング・テクノロジは自社所有暗号化 方式をインストールしているため、その暗号化方式をサポートするＷＷＷサーバ の間でしか働くことができない。このオプションはＷＷＷの開放型標準設計に逆 行するものである。 フィルタリングとは、ＷＷＷ応答をデータのサイズ、タイプまたは他の特性に 基づいてグローバルで制御することであり、これによってユーザはデータの受信 をカストマイズすることができる。作業は、ＷＷＷサーチ・エンジン、アドバン スド・ブラウザ上の特殊化されたキャッシング・ユーティリティなどを通してこ のエリアで行われている。 ここで言うフィルタリングは、余りに多いデータを要求するか、擬似情報を検 索することにより、あるいはＷＷＷ要求が原因で起こるその他の望ましくない副 作用によって、ワイヤレス／低バンド幅データ・ネットワークを誤用するおそれ のある、不注意なユーザのためのグローバル・セーフティ・ネットである。例え ば、ユーザは、送信するには極めて大きく、おそらくコストがかかかるとユーザ が気づいていないデータ・オブジェクトをＷＷＷに要求することがある。セーフ ティ・ネットでは、ユーザは特定の要求が実行されるのを自動的に防止するよう にフィルタを構成することができる。 従って、圧縮、暗号化およびフィルタリングの機能をＷＷＷインタフェースに 実装することが要望されている。 問題３ 第３の問題は、ＷＷＷアクセス・ソフトウェアが非同期または非送信請求(uns olicited)更新をネットワークから受信するための標準的方法がないことである 。Ｎetscape(商標)、Ｍosaic(商標)、Ｌynx（商標）ブラウザなどの最も人気の あるブラウザは人気度の劣る他のブラウザと同様に、応答データがそれぞれのブ ラウザに送られる前にユーザがなんらかの形態の応答を出すことを要求している 。 例えば、望ましいことは、ＷＷＷへのアクセス権を持つ企業が、加入者のＷＷ Ｗアクセス・システムをネットワーク内からリモートで構成できるようにするこ とである。正規のブラウザはこの機能を備えていないので、加入者は各自のアク セス・ソフトウエアを手作業で構成し、更新しなければならない。これを行うに は、従来の音声カストマ・サポート・ラインまたはユーザのホスト・システム上 のカスタム・エージェント・ソフトウェアを通して、サービス・プロバイダのサ ポートが必要になる（この問題の詳しい説明は、「ＩＳＧ：統合化サービス・ゲ ートウェイ(ＩＳＧ:Ｉntegrated Ｓervices Ｇateway)」、Ｂellcore ＴＭ-2485 6に記載されている)。 従って、特に、ネットワークをアクセスするためのソフトウエアの構成を自動 化するために、ネットワークまたはサービス・プロバイダからの非送信請求伝送 を受信し、実現できるＷＷＷインタフェースが要望されている。発明の概要 以上に鑑みて、本発明の目的は、上述した要求およびその他のことに応えるこ とである。本発明の目的は、ＷＷＷとのインタフェースとなって、高レイテンシ 環境でＴＣＰ／ＩＰをサポートし、圧縮、暗号化およびフィルタリング・サービ スを提供し、ＷＷＷまたはサービス・プロバイダからの非送信請求メッセージ(u nsolicited message)を受け取って、実現する方法およびシステムを提供するこ とである。 本発明のその他の目的、利点および新規の特徴は後述する説明に記載されてい るが、これらはその説明を読み、本発明を実施することによりこの分野の当業者 に容易に理解されるはずである。本発明の目的と利点は、請求の範囲に記載され ている事項によって実現し、達成することが可能である。 上述した目的およびその他の目的を達成するために、また以下で具現化され、 広義に説明されている本発明の目的によれば、本発明のシステムと方法は、第１ ロケーションに置かれていて、ブラウザとローカル・プロキシをもつホスト・コ ンピュータ、第２ロケーションに置かれていて、低バンド幅ネットワークを通し てローカル・プロキシと通信するリモート・プロキシ、ブラウザ上で照会(query )を出し(initiate)、アプリケーション層プロトコルを使用してその照会をロー カル・プロキシに送信する手段、照会のアプリケーション層プロトコルを低バン ド幅ネットワーク上で送信するのに適したトランスポート・プロトコルに変換す る手段、照会を低バンド幅ネットワークを通してローカル・プロキシからリモー ト・プロシキに送信する手段、および、トランスポート・プロトコルをコンピュ ータ・ネットワーク上で照会を実行するのに適したアプリケーション層プロトコ ルに変 換する手段、を利用している。 また、好ましくは、本発明のシステムと方法は、照会をネットワーク・サーバ に伝達し、その照会を実行し、データ・オブジェクトをリモート・プロキシに返 送する手段、そのデータ・オブジェクトを低バンド幅ネットワーク上で送信する のに適したトランスポート・プロトコルに変換する手段、データ・オブジェクト を低バンド幅ネットワークを通してリモート・プロキシからローカル・プロシキ に送信する手段、データ・オブジェクトのトランスポート・プロトコルをローカ ル・プロキシでアプリケーション層プロトコルに変換する手段、および、アプリ ケーション層プロトコルを使用してデータ・オブジェクトをブラウザに伝送する 手段を含んでいる。 また、好ましくは、本発明のシステムと方法は圧縮、フィルタリングおよび暗 号化の設定をもつ照会スクリプトを作成する手段、照会スクリプトをカプセル化 (encapsulating)して低バンド幅ネットワークを通してローカル・プロキシから リモート・プロキシに送信する手段、照会スクリプトにおける設定に従ってデー タ・オブジェクトを圧縮し、フィルタリングし、暗号化する手段、および、デー タ・オブジェクトを応答スクリプトに入れて低バンド幅ネットワークを通してリ モート・プロキシからローカル・プロキシに送信する手段を含んでいる。 本発明の他の形態では、その目的と用途によれば、本発明のシステムは、コン ピュータ・ネットワークと通信するシステムを含むことも可能であり、このシス テムは、ユーザ・インタフェースのためのブラウザをもつホスト・コンピュータ 、アプリケーション層プロトコルを使用してブラウザと通信するローカル・プロ キシ手段(このローカル・プロキシ手段はアプリケーション層プロコトルをトラ ンスポート・プロトコルに変換する手段を含んでいる)、および、トランスポー ト・プロトコルを使用してローカル・プロキシ手段と通信するリモート・プロキ シ手段を含んでいる。リモート・プロキシ手段は、トランスポート・プロトコル をアプリケーション層プロトコルに変換する手段、および、アプリケーション層 プロトコルを使用してコンピュータ・ネットワークと通信する手段を含んでいる 。図面の簡単な説明 以下では、本発明の理解を容易にするために添付図面を参照して本発明の内容 を開示しながら説明する。添付図面において、 図１は、私用コンピュータ・ネットワークとＷＷＷとの間の、従来技術による 、ファイアウォール・インタフェースを示すブロック図である。 図２は、本発明の分割プロキシ・インタフェースを示すブロック図である。 図３は、本発明のローカル・プロキシ・インタフェースによって実行されるプ ロトコル変換を示す説明図である。 図４は、本発明のリモート・プロキシ・インタフェースによって実行されるプ ロトコル変換を示す説明図である。 図５は、本発明のプロキシ・インタフェースにおける実施（インプリメンテー ション）を示すフローチャートである。好適実施例の詳細な説明 以下、添付図面に図示している例を参照して、本発明の好適実施例について詳 しく説明する。 ＷＷＷの構築はコンピュータ革命であり、これはワイヤレス・データ・ネット ワークが爆発的なインターネットの人気に直接に参加できるようにする潜在的触 媒ともなっている。本発明は、私用コンピュータまたは私用コンピュータ・ネッ トワークをＷＷＷと結ぶインタフェースとなって、高レイテンシ環境でＴＣＰ／ ＩＰをサポートし、圧縮、暗号化およびフィルタリング・サービスをサポートし 、サービス・プロバイダによって送信される非送信請求メッセージの受信と実現 をサポートする方法およびシステムを提供する。また、本発明によれば、ラップ トップ(Ｌaptop)またはパーソナル・ディジタル・アシスタント(Ｐersonal Ｄi gital Ａssistant-ＰＤＡ)が移動通信（ワイヤレス）端末からＷＷＷに直接アク セスすることを可能にしている。 例えば、本発明によるＷＷＷとのインタフェースは、必要とする機能を実行す るようにプロキシ（図１のエレメント４）を改良することにより実現することが 可能である。この改良型プロキシは分割プロシキのシステム（米国特許出願第08 /309,336号に記載されているように、エージェント・テクノロジと呼ばれること もある）になり、これはファイアウォール上に実現することも、あるいはワイヤ レスまたはワイヤライン・ネットワークからＷＷＷにアクセスできる個人コ ンピュータ（ラップトップでもよい）上でバックグランドで実行されるアプリケ ーションにすることもできる。 図２に示すように、本発明のインタフェースは改良型分割プロキシ(modified split proxy)である。分割プロキシはローカル・プロキシ５６とリモート・プロ キシ６６を含み、これらのプロキシはＷＷＷ要求の変換(translation)と復元(re storation)を可能にするソフトウェア・モジュールである。 モバイル端末５２を操作するユーザはＴＣＰ／ＩＰを使用してＷＷＷと通信す るＷｅｂブラウザ５４を使用している。ローカル・プロキシ５６は、ユーザ端末 ５２上でバックグランドで実行されるソフトウェア・パッケージである。高レイ テンシが問題になっている場合は、ローカル・プロシキ５６は、本発明の原理に よれば、ブラウザによって使用されるＴＣＰ／ＩＰプロトコルと、通信ネットワ ーク上をリモート・プロキシまでデータを運ぶのに十分強固なプロトコルとの間 でデータ要求／伝送を変換する。 図２に示す実施例では、ユーザはワイヤレス・ネットワークを通してＷＷＷに アクセスしている。例えば、ワイヤレス・モデム５８はＡirＢoss（商標）ワイ ヤレス・トランスポート・プロトコルなどの、低バンド幅最適化プロトコル(low -bandwidth optimized protocol)を使用して、ベースステーシヨン（基地局）６ ０と通信している。従って、ローカル・プロキシ５６は低バンド幅最適化プロト コルをＴＣＰ／ＩＰに変換する。 ローカル・プロキシのカプセル化要求スクリプト（図５の一般ブラウザ使用フ ローを参照）はワイヤレス・ネットワーク６２を通してリモート・プロキシ６６ に送信される。リモート・プロキシ６６はＴＣＰ／ＩＰと、ＡirＢoss（商標） トランスポート・プロトコルなどの低バンド幅最適化プロトコルとの間で必要な プロコトル変換を行って、ユーザをＷＷＷ ６８に接続する。 本発明には、プロキシ・サービスをサポートする標準Ｗｅｂブラウザを、ワイ ヤレスおよび低バンド幅のＷｅｂブラウジングに適応できるようにするメソッド がいくつか用意されている。以下の本発明の説明では、上述した第１、第２、お よび第３の問題にそれぞれ関係する３セットのメソッドについて説明する。 メソッド・セット１ 解消すべき第１の問題は例えば、約３秒から５秒を越える高レイテンシを引き 起こすネットワーク上をＴＣＰ／ＩＰを使用してデータを伝送する場合である。 問題１を解決するために使用される方法とシステムでは、プロトコル変換が行わ れる。プロトコル変換とは、要求と応答が１つのペアになっているＴＣＰアプリ ケーション要求（つまり、ＨＴＴＰ、ＳＭＴＰ、Ｇopher、およびＷＡＩＳ）を 、データを伝送する通信ネットワーク、特にワイヤレス・ネットワークやその他 の低バンド幅ネットワーク上で起こる高レイテンシでも機能できるだけの強固な 、適切なコネクション型プロトコル(connection-oriented protocol)にカプセル 化することである。 プロトコル変換は分割プロキシによって達成される。ローカル・プロキシはホ ストで始動され、そこではユーザは標準Ｗｅｂブラウザも起動している。Ｗｅｂ ブラウザはローカル・プロキシと通信するように、ユーザまたはローカル・プロ キシによって構成されている。後者の構成オプションの方が好ましいのは、この オプションを選ぶと、かなり込み入ったプロキシ構成上の問題がユーザから隠さ れるためである。しかし、プロキシはどのブラウザが使用されているかを知って いなければならない。 ローカル・プロキシとＷｅｂブラウザが起動され、正しく構成されると、ブラ ウザはすべてのＷＷＷ要求をローカル・プロキシに渡していく。ローカル・プロ キシはブラウザのＷＷＷ要求を受け取ると、その要求を使用中のネットワークに 見合った低バンド幅最適化プロトコルに変換する(例えば、ＵＤＰ／ＩＰをベー スとするＡirＢoss（商標）ワイヤレス・トランスポート・プロトコル)。 リモート・プロキシは変換されたスクリプト形式をローカル・プロキシから受 信し、ブラウザによって行われたオリジナル要求のためにオペレーションを遂行 する能力を備えている。変換された要求からデータがリモート・プロキシで受信 されると、そのデータはオリジナル・スクリプトに基づいて暗号化され、圧縮さ れ、フィルタリングされ、および／または最適化プロトコルにカプセル化され、 ローカル・プロキシに返送される(これらのサービスは下述するメソッド２と３ の個所で詳しく説明されている)。ローカル・プロキシはカプセル化された応答 を受信し、それをアンパッケージし、最終的応答をブラウザに戻す。 次に図３を参照して、ＷＷＷデータの要求例について説明する。Ｗｅｂブラウ ザ５４は、ＴＣＰ／ＩＰを構成しているアドバンストＯＳＩプロトコル層または アプリケーション層プロトコル７０に置かれている要求を出力する。この要求は ローカル・プロキシ５６に送られ、そこで要求はＡirＢoss（商標）ワイヤレス ・トランスポート・プロトコルなどのように、ＵＤＰ／ＩＰをベースとする低バ ンド幅最適化プロトコル７２に変換される。次に、カプセル化された要求(以下 、「カプセル化要求」という)はネットワーク・アクセス・デバイス５８（例えば 、モデム）を経由して低バンド幅ネットワークに渡される。 図４に示すように、要求は低バンド幅ネットワークを通り抜けて、総称(gener ic)サービス・ノード７４に到達する。そのあと、カプセル化要求はリモート・ プロキシ６６に渡され、そこでカプセル化要求は低バンド幅最適化プロトコル（ 例えば、ＡirＢoss（商標）トランスポート・プロトコル）から、Ｗｅｂブラウ ザが作成した元のアプリケーション層プロトコルに変換され、ブラウザの要求が インターネットに渡される。 リモート・プロキシとローカル・プロキシとの間の通信に関しては、マルチス レッディング(multi-threading)が重要である。ここでマルチスレッディングと は、アプリケーションが複数のオペレーションを同時に実行しているように見え るようにするプログラミング／オペレーティング・システム・パラダイムのこと である。本発明の開発過程で分かったことは、分割プロキシに要求／応答のペア をマルチスレッディングできる能力をもたせることである。大部分のＷＷＷブラ ウザはマルチスレッドされたクライアント要求／応答をサポートしているので、 分割プロキシにも同じことができる能力をもたせて、ＷＷＷアクセス体制にシー ムレスに統合化できるようにする必要がある。 本発明の分割プロキシでマルチスレッディングを実現するためには、要求をカ プセル化している内部スクリプトを、ブラウザを宛先とする応答スクリプトと突 き合わせるためのトランザクション・システムがローカル・プロキシとリモート ・プロキシの間に必要である。これらのプロキシの間にどのようなトランザクシ ョン・システムが実現されるかは重要ではなく、また、トランザクション・シス テムが本発明の開示内容に基づいてどのように構築されるかは、この分野の通常 の 知識を有するものには自明のことである。メソッド・セット１と２に説明されて いるプロトコルとトランザクション・メカニズムは’３３６出願に記載されてい るパーソナル・コミュニケーションズ・インターネット(Ｐersonal Ｃommunicat ions Ｉnternet-ＰＣＩ)作業システムをベースにしている。 トランザクション・システムが高精度化すれば、本発明のシステムと方法はそ れだけ効率化するので、エンドユーザが低バンド幅ネットワーク上でＷＷＷをブ ラウズすることが可能になる。以下に説明する本発明のメソッドは上記事実に基 づいている。 マルチスレッドされた要求／応答ペアをサポートする利点は、複数のブラウザ を単一のローカル・プロキシによってホスト上でサポートできることである。メソッド・セット２ 開発されたＷＷＷと既存プロトコルはユーザのデータ伝送要求に応えるように 相互の上に階層化されていたので、Ｗｅｂブラウザは既存プロトコルを利用する ように作られていた。現存ＷＷＷアクセス・ソフトウェアでは、データ・セキュ リティとコンパクト化の要求は大部分が無視されていた。その結果、ＴＣＰ／Ｉ Ｐを使用するＷｅｂブラウザは伝送すべきデータを暗号化し、圧縮し、あるいは フィルタリングする機能を備えていない。 ＷＷＷの主要コンソーシアムであるＷ３Ｃは、ＷＷＷ上のデータ伝送の安全保 護に関する標準を検討している。しかし、このようなＷｅｂワイドの標準には、 この標準がいったん公表されると、ハッカがそのプロトコル仕様の中に押し入っ ていき、安全保護措置を打ち破る方法を見つけるという問題がある。 従って、本発明の目的は、ＷＷＷがオープンであるとの性格をすべてまだ利用 している自社所有体制において、プロキシ・ソフトウェアに圧縮、暗号化、およ びフィルタリングの各ツールを組み入れたことである。従って、リモート・プロ キシとローカル・プロキシの間のトランザクション・システムは圧縮および暗号 化アルゴリズムを備えているので、自社カストマが使用するようにサービス・プ ロバイダによって設計された自社所有システムにすることができる。 フィルタリング・ツールは分割プロキシによって実現することも可能である。 本発明でフィルタリングというときは、低バンド幅ネットワーク上のグローバル 制御のことである。例えば、ブラウザが情報要求を出すとき、どれだけの情報が 検索されるかが分かっていないのが一般である。本発明の原理によれば、ローカ ル・プロキシがフィルタリング構成命令をユーザから受け取ると、その命令はリ モート・プロシキに送られて、そこで実行される。この場合、リモート・プロキ シは、ユーザのデータ要求に対する応答を調べたり、例えば、不当に大きなデー タ・オブジェクトがユーザのシステムを圧倒するのを防止するといった、機能を 実行することができる。 一般的に、暗号化および圧縮アルゴリズムは、新しいＷｅｂブラウザに置いて おくのではなく、ローカル・プロキシとリモート・プロキシの間に置いた方が好 都合である。上述したように、この種のアルゴリズムは自社所有体制で保護する ことができる。この分野の通常の知識を有する者ならば、暗号化および圧縮アル ゴリズムは独自のアルゴリズム・セットを望んでいるサービス・プロバイダのた めに周知の原理に基づいて容易に設計することが可能である。 これに対して、この種のアルゴリズムに関するオープンで、広く知られた標準 は、例えば、Ｗ３Ｃで検討されているものと同じように、批判されているにもか かわらず、例えば、相互運用性(interoperability)といった長所をもっている。 相互運用性とは、プロキシの異なる作成者が一緒に機能するリモート・プロキシ とローカル・プロキシを作成できるようにすることである。また、異種コンピュ ータ・プラットフォームのメーカが自社プラットフォームを他社プラットフォー ムとブリッジさせることも可能にする。 圧縮、暗号化およびフィルタリングを実現するスクリプトは、それが自社所有 であるか、オープンであるかに関係なく、少なくとも次のことを実行するフィー ルドを含んでいる必要がある。 Ａ．暗号化のサポート。例えば、電子データの通貨取引を安全保護するＭＤ５ 暗号化(cipher)アルゴリズム。 Ｂ．複数のタイプの圧縮のサポート(どのタイプの圧縮を選択するかはスクリ プトに含まれるデータのタイプに基づいて行う必要がある)。例えば、テキスト ・データにはＬＺＷ圧縮アルゴリズムが使用できる。 Ｃ．少なくとも負フィルタまたは正フィルタのサポート。例えば、次のフィル タリング・アルゴリズムの１つまたは２つ以上が使用できる。 負フィルタ − 応答スクリプトはどのバイナリ・データも含んでいてはなら ない。また、応答スクリプトはこのサイズより大であってはならない。 正フィルタ − 応答はそこに「ワイヤレス」が入っているすべてのテキスト 行を含んでいなければならない。 リモート・プロキシとローカル・プロキシの間の通路上のいずれかの箇所に、 なんらかの障害が起こったとき、特にワイヤレス環境では、ローカル・プロキシ とリモート・プロキシの間のトランザクション・システムはその障害に見合う応 答ができなければならない。例えば、スクリプトをワイヤレス・ネットワークに 渡すことができないとか、あるいはスクリプトがリモート・プロキシに到達でき ないとか、あるいはリモート・プロキシがインターネットへのアクセス権を得る ことができないときは、トランザクション・システムはそれに見合う応答ができ なければならない。 メソッド・セット３ 最後の問題は、ＷＷＷアクセス・ソフトウェアであるＷｅｂブラウザが最初か らクライアントとして働くように設計されていたために発生するものである。ク ライアント・ソフトウェアはそれ自体、ネットワークからの非同期または非送信 請求更新を受信できないのが一般的である。これは、サービス・プロバイダが加 入者にアクセス・ソフトウェアを提供した後で、そのソフトウェアの構成をユー ザのためにリモートで（ネットワーク内から）管理したい場合に問題となる。本 発明の特徴によれば、大規模のサービス・プロバイダはカストマの要求に合わせ て拡張可能なＷＷＷアクセスを提供することができる。 上述したように、現在使用されているＷｅｂブラウザはこのような更新を受信 し、それを実現する設計になっていない。その代わりに、サービス・プロバイダ は新しい更新済みソフトウェアを配布している。ユーザが大規模で稼働している 場合には、更新を実現するためには、ソフトウェアを再インストールし、ソフト ウェアを再構成し、その障害診断を行うために派遣されたサービス・エンジニア が必要になる場合さえある。別の方法として、カストマはカストマ・サポート・ ラインに電話し、更新のインストールをサポートする口頭の指示を待たなければ ならない場合もある。 本発明の原理によれば、もっと単純で、もっと効率的な解決方法は分割プロキ シ・インタフェースを使用してサービス・プロバイダから提供される。サービス ・プロバイダのシステム用に設計された暗号化およびセキュリティ・プロトコル を使用すると、サービス・プロバイダはユーザ自身のシステムに置かれているユ ーザのＷＷＷアクセス・ソフトウェアにアクセスし、そのソフトウェアを即時に インストールし、構成し、あるいは更新することができる。このメソッドには、 サービス・プロバイダによってとられたアクションをユーザに知らせるメッセー ジを組み入れることもできる。 本発明の解決方法(solution)は、ソフトウェア更新、構成の変更、または新規 サービスの広告といった事柄に合わせてエンドユーザのホスト・システムを変更 することを目的としたスクリプトを非同期／非送信請求で受信できるようにロー カル・プロキシを構成することである。ローカル・プロキシはユーザのシステム のバックグラウンドで実行させて、Ｗｅｂブラウジング・ソフトウェアが実行中 でない場合でも、上記のような通知を受信して、実現するようにすることが理想 である。 ローカル・プロキシはブラウザの一部ではないため、これらの非同期ネットワ ーク・アップロードを受信するために常時実行させておく必要があるので、本発 明はシステム・リソースの量を制限するために小サイズで、モジュール構造の設 計になっている。この特徴は、インストールされている他のソフトウェアとの望 ましくないやりとりから保護する(つまり、メモリ割り振り、ＩＰポート割り当 てなど)。好適な実施（インプリメンテーション） 以下では、図５を参照して本発明のフロー・ダイヤグラムについて説明する。 図５に示したフロー・ダイヤグラムは、本発明の主要コンポーネントに対応する 一連のエンティティが上段にリストされている。つまり、Ｗｅｂブラウザ５４、 ローカル・プロキシ５６、リモート・プロキシ６６、およびＷＷＷの外部Ｗｅｂ サーバ６８である。このフロー・ダイヤグラムはスタートアップ・プロセス期間 、一般ブラウザ使用プロセス期間、およびサービス更新プロセス期間のそれぞれ に おいて、これらのコンポーネントがどのように作用し合うかを示している。 Ｗｅｂブラウザ５４とローカル・プロキシ５６は、同じホスト・コンピュータ またはユーザ端末５２上に共存して実行される設計になっている。しかし、リモ ート・プロキシ６６と外部Ｗｅｂサーバは必ずしも共存させる必要はない。リモ ート・プロキシ６６は外部Ｗｅｂサーバだけにアクセスして、通信できるように なっていなければならない。 図５の矢印はデータが一方のエンティティから他方のエンティティに通知また は転送されることを示している。矢印のヘッドはアクションが指示される方向を 示している。上から下へのラインはプロセス・ステップが実行されるときの時間 ラインと順序を示している。 図５に示す最初のフローはスタートアップ・フローである。これは基本的に、 システムがエンドユーザのホスト・コンピュータでどのようにアクチベートされ るかを示している。ここでは、リモート・プロキシと外部Ｗｅｂサーバは、以下 のフロー説明のいずれにおいても、すでに実行中であると想定している(これら のシステムは、エンドユーザ側から見たとき、どのやりとりもしないで、システ ム管理者が保守し、始動できるようになっている)。最初に行われるアクション はエンドユーザがローカル・プロキシを始動することである。これは、マルチス レッド・オペレーティング・システムのバックグラウンドで始動され、実行され るアプリケーションを起動することを意味するだけである。オペレーティング・ システムは、例えば、Ｗindows（商標）バージョン3.1オペレーティング・シス テムにすることができる。 ローカル・プロキシが始動された後、ローカル・プロキシは２つのことを行う 責任がある。ブラウザ・タイプがユーザのホスト・コンピュータで指定されてい れば、ローカル・プロキシはそのブラウザを構成して始動しなければならない。 ブラウザには、その起動前に構成しておかなければならないものと、起動してか ら構成しなければならないものとがある。これはどのブラウザ・タイプが使用さ れるかによって決まる。ブラウザはプロキシ・サービスをサポートする従来のブ ラウザ・タイプならば、どのタイプであっても構わない。 どのブラウザ・タイプであるかが分かっていないときは、エンドユーザはその ブラウザを手作業で始動して、ローカル・プロキシ用に構成する必要がある。こ の場合、エンドユーザは使用しようとするＷｅｂブラウザに関する情報が十分に 分かっていて、プロキシ・サービス用にそのブラウザを手作業で構成できるよう になっていなければならない。 図５に示す第２のフローは一般ブラウザ使用フローである。このフローはブラ ウザが始動され、構成された後の本発明のプロセス・ステップを示している。エ ンドユーザはまず標準Ｗｅｂ要求を渡す。これは、基本的には、ユーザがハイパ ーリンクでポイントし、クリックするか、あるいはダイアログ・ボックスをオー プンし、一般に汎用リソース・ロケータ(universal resource locator-ＵＲＬ) と呼ばれているものに入ることを意味している。例えば、これはインターネット ・コミュニティがＷＷＷ上のデータ・オブジェクトをどのように識別し、アクセ スするかの方法である。 一般ブラウズ使用のフローの次のステップは、ブラウザから起動された照会が ローカル・プロキシに渡されることである。ローカル・プロキシは照会スクリプ トを作成し、データ・オブジェクトで使用される圧縮のタイプまたは利用できる 圧縮のタイプを定義している設定値をそのスクリプトに入れる。ローカル・プロ キシは、そのデータ・オブジェクトに適用されるフィルタと暗号化のタイプに関 する設定値もスクリプトに入れる。これらの設定値はセキュリティを提供し、照 会に対する応答として戻される情報をユーザが制御できるようにもする。 そのスクリプトが作成されると、これはリモート・プロキシに送付される。リ モート・プロキシは照会スクリプトを解析し、ブラウザから最初に渡されたパッ ケージ化照会を抜き出す。リモート・プロキシは、次に、標準Ｗｅｂデータ・オ ブジェクト要求の中の照会を実行する。 外部Ｗｅｂサーバは照会を受信した後、その照会に関連する該当データ・オブ ジェクトを返却する。この時点では、他の特殊な強化機能は不要である。これは どの該当ＷＷＷプロトコルでも使用できるコンピュータ・ネットワーク上の従来 のクライアント／サーバ要求にすぎないからである。例えば、ハイパーテキスト 転送プロトコル、ファイル・トランスポート・プロトコル、シンプル・メール・ トランスポート・プロトコル、またはポストオフィス・プロトコルが使用できる 。 データ・オブジェクトがリモート・プロキシに戻されると、リモート・プロキ シはオリジナル照会スクリプトの中で指定されていた圧縮、フィルタ、および暗 号化を適用する。この中には、データ・オブジェクトをローカル・プロキシに渡 すのに正しい形式に入れるためにデータ・オブジェクトに対して実行されるアク ションが含まれる。圧縮、フィルタ、および暗号化は形式化されて応答スクリプ トに入れられる。 アクションが完了し、ローカル・プロキシに渡されると、ローカル・プロキシ は応答スクリプトを要求スクリプトと突き合わせる。応答スクリプトが要求スク リプトと突き合わされた後、該当ブラウザと、その情報をブラウザに送るべき場 所を知ることになる。次に、ローカル・プロキシは応答スクリプト全体にわたっ て解析し、内部データ・オブジェクトを抜き出す。従って、ローカル・プロキシ 側では、応答スクリプトについて２つのことが行われる必要がある。応答スクリ プトは要求と突き合わされなければならず、ローカル・プロキシはデータ・オブ ジェクトを抜き出し、それをオペレーティング・システム内の該当場所に送って ブラウザがオブジェクトをそのビュアで表示できるようになっていなければなら い。 図５に示す第３のフローはサービス更新またはサービス・スクリプト・フロー である。これは、更新されたサービスを実現することに関心を持つネットワーク 管理者がネットワーク内からリモートでエンドユーザのホスト・システムを構成 できるような場合に行われる。リモート・プロキシはサービス・スクリプトを作 成する。例えば、新しいＨＴＭＬホームページが送付され、エンドユーザのリモ ート・システム側に構成される場合には、ＨＴＭＬファイルを配布(distributio n)の中に書くようにローカル・プロキシに指示するサービス・スクリプトが作成 されることになる。このサービス・スクリプトはＨＴＭＬページをデータ・オブ ジェクトとして含んでおり、このスクリプトが適切な形式で完成すると、ローカ ル・プロキシに送られる。 ローカル・プロキシはサービス・スクリプト全体を解析し、アクションおよび そのアクションに関連するデータ・オブジェクトを共に抜き出し、要求アクショ ンを完了する責任がある。そこで、この例を終了するために、ローカル・プロキ シはどのアクションが要求されたかを知るために全体を解析し(新しいＨＴＭＬ ホームページを書く)、データ・オブジェクト（新しいＨＴＭＬホームページ） を抜き出し、データ・オブジェクトをローカル・ファイル配布に書き込む。矢印 は、該当する場合には、情報をブラウザに表示することがあることを示している 。それが可能でないこともあるので、ローカル・プロキシは適切なアクションの ダイアログ・ボックスまたは他のユーザ・インタフェース通知を表示する。非同 期更新を受信できるブラウザにはその時点で通知することができ、ローカル・プ ロキシはそのアクションを開始し、適切なユーザ・インタフェース・コントロー ルがあれば、それをブラウザに送信してローカル・ホスト・システムで実行され たばかりのアクションをユーザに表示する。 本発明によって提供されるユーザとＷＷＷとの間のインタフェースはプロトコ ル変換、圧縮、暗号化、フィルタリングおよび自動サービス更新の機能を備えて いるので、この非常に高価なリソースとのコネクションが大幅に向上される。圧 縮に関しては、本発明のプロキシ・サービスをワイヤレス・ネットワーキング環 境で要求するときのエンドユーザの直接費用が節減されることになる。大部分の ワイヤレス・ネットワーク・プロダイダはパケット当たりの料金を提供し、大量 （バルク）使用については均一料金（例えば、ＩＭＢデータまで一定料金）を提 供している。直接費用節減はそのリンク上のデータが圧縮されているとき実現す ることができる。実験に基づく測定で明らかになったことは、標準ＨＴＭＬデー タはスクリプトのオーバヘッドを含めて、オリジナル・ペイロードの５０−６０ ％まで正規に圧縮できることである。このことは、カストマは同じ価格で２倍の ＷＷＷデータを検索できることを意味する。 本発明によれば、ネットワーク管理者はカストマのホスト構成を直接に管理す ることができるので、問題診断のために信頼度の低いテクニカル・サポート・ラ インを無視でき、まはソフトウェアの込み入った設定値をカストマに学ばせる必 要がなくなる。また、新しいサービスの配備は本発明によって自動化される。 本発明で具現化されているテクノロジはＩＳＰ、ＰＤＡとラップトップのメー カ、ワイヤレス・ネットワーク・プロバイダ、ワイヤレス・システム統合業者、 およびＩＳＰになることを希望しているテレホニ・プロバイダが使用するのに最 も適している。このテクノロジを他のプロダクト・ラインと統合化すると、ＷＷ Ｗと強い結び付きをもち、移動可能コンポーネントをもつプロジェクトを強化す ることも可能である。 以上の説明から理解されるように、本発明は上述し、添付図面に図示されてい る正確な構成またはプロセス・ステップに限定されるものではなく、本発明の範 囲と精神を逸脱しない限り種々態様に改良および変更を行うことが可能である。 また、本発明の範囲と精神は請求の範囲に記載されている事項によってのみ限定 されるものである。

【手続補正書】特許法第１８４条の８第１項 【提出日】１９９８年３月１１日 【補正内容】 請求の範囲 １．第１ロケーションに置かれておりクライアント・アプリケーションをも つホスト・コンピュータと、第２ロケーションに置かれているサーバ・アプリケ ーションとの間でコミュニケーション・パスを通して通信する方法であって、該 方法は、 ローカル・プロキシを前記第１ロケーションに設置し、 前記コミュニケーション・パスを通して前記ローカル・プロキシと通信する リモート・プロキシを前記第２ロケーションに設置し、 前記クライアント・アプリケーションで照会を開始し、アプリケーション層 プロトコルを使用して前記照会を前記ローカル・プロキシに送信し、 前記照会のアプリケーション層プロトコルをトランスポート・プロトコルに 変換し、 前記トランスポート・プロトコルにおける前記照会を前記コミュニケーショ ン・パスを通して前記ローカル・プロキシから前記リモート・プロキシに伝送し 、前記伝送された照会のトランスポート・プロトコルを、前記照会を前記サーバ ・アプリケーションで実行するためのアプリケーション層プロトコルに変換する ことを含むことを特徴とする方法。 ２．請求項１に記載の方法において、前記コミュニケーション・パスは高レ イテンシ・コミュニケーション・パスであることを特徴とする方法。 ３．請求項１に記載の方法において、前記コミュニケーション・パスはワイ ヤレス・ネットワークであることを特徴とする方法。 ４．請求項１に記載の方法において、さらに、 前記照会を前記サーバ・アプリケーションで実行し、データ・オブジェクト を前記リモート・プロキシに戻すステップを含むことを特徴とする方法。 ５．請求項４に記載の方法において、さらに、 前記データ・オブジェクトをトランスポート・プロトコルに変換し、 前記データ・オブジェクトを前記トランスポート・プロトコルに入れて、コ ミュニケーション・パスを通して前記リモート・プロキシから前記ローカル・プ ロキシに伝送し、 伝送されたデータ・オブジェクトの前記トランスポート・プロトコルを前記 ローカル・プロキシでアプリケーション層プロトコルに変換し、 前記データ・オブジェクトを前記アプリケーション層プロトコルを使用して 前記クライアント・アプリケーションに伝達するステップを含むことを特徴とす る方法。 ６．請求項１に記載の方法において、さらにスタートアップ・オペレーショ ンを含み、該スタートアップ・オペレーションは、 前記ホスト・コンピュータで前記ローカル・プロキシを始動し、 前記ローカル・プロキシを使用して前記クライアント・アプリケーションを 構成し、始動するステップを含むことを特徴とする方法。 ７．請求項１に記載の方法において、前記照会の前記アプリケーション層プ ロトコルを変換する前記ステップは、さらに、 圧縮、フィルタ、および暗号化に関する設定をもつ照会スクリプトを作成し 、 前記照会スクリプトをカプセル化して、前記コミュニケーション・パスを通 して前記ローカル・プロキシから前記リモート・プロキシに伝送するステップを 含むことを特徴とする方法。 ８．請求項７に記載の方法において、前記データ・オブジェクトの前記アプ リケーション層プロトコルを変換する前記ステップは、さらに、 前記照会スクリプトに含まれる前記設定に従って前記データ・オブジェクト を圧縮し、フィルタリングし、暗号化し、 前記データ・オブジェクトを応答スクリプトに入れて、前記コミュニケーシ ョン・パスを通して前記リモート・プロキシから前記ローカル・プロキシに伝送 するステップを含むことを特徴とする方法。 ９．請求項８に記載の方法において、さらに、 前記応答スクリプトを前記ローカル・スクリプトで受信したとき前記応答ス クリプトを前記照会スクリプトと突き合わせ、 前記応答スクリプトを前記クライアント・アプリケーションに送付し、 前記データ・オブジェクトを前記応答スクリプトからアンパッケージし、 前記データ・オブジェクトを前記第１ロケーションで表示するステップを含 むことを特徴とする方法。 10．請求項１に記載の方法において、さらに、 サービス・スクリプトを前記リモート・プロキシで作成し、 前記サービス・スクリプトを前記リモート・プロキシから前記ローカル・プ ロキシに伝送し、 前記サービス・スクリプトを解析し、要求アクションとデータ・オブジェク トを前記サービス・スクリプトから抜き出し、 サービス・アクションを前記ローカル・プロキシで実行するステップを含む ことを特徴とする方法。 11．第１ロケーションに置かれておりクライアント・アプリケーションをも つホスト・コンピュータと、第２ロケーションに置かれているサーバ・アプリケ ーションと間で、コミュニケーション・パスを通して通信するシステムであって 、該システムは、 第１ロケーションに置かれているローカル・プロキシと、 第２ロケーションに置かれており前記コミュニケーション・パスを通して前 記ローカル・プロキシと通信するリモート・プロキシと、 前記クライアント・アプリケーションで照会を開始し、アプリケーション層 プロコトルを使用して前記照会を前記ローカル・プロキシに送信する手段と、 前記照会のアプリケーション層プロトコルをトランスポート・プロトコルに 変換する手段と、 前記照会を前記トランスポート・プロコトルに入れて、前記コミュニケーシ ョン・パスを通して前記ローカル・プロキシから前記リモート・プロキシに伝送 する手段と、 前記トランスポート・プロトコルを、前記サーバ・アプリケーションで前記 照会を実行するためのアプリケーション層プロトコルに変換する手段と を備えていることを特徴とするシステム。 12．請求項１１に記載のシステムにおいて、前記照会を実行する手段と、デ ータ・オブジェクトを前記リモート・プロキシに戻す手段とをさらに備えている ことを特徴とするシステム。 13．請求項１２に記載のシステムにおいて、さらに、 前記データ・オブジェクトをトランスポート・プロトコルに変換する手段と 、 前記データ・オブジェクトを前記コミュニケーション・パスを通して前記リ モート・プロキシから前記ローカル・プロキシに伝送する手段と、 前記データ・オブジェクトのトランスポート・プロトコルを前記ローカル・ プロキシでアプリケーション層プロトコルに変換する手段と、 前記アプリケーション層プロトコルを使用して前記データ・オブジェクトを 前記クライアント・アプリケーションに伝達する手段と を備えていることを特徴とするシステム。 14．請求項１１に記載のシステムにおいて、さらに、 前記ローカル・プロキシを前記クライアント・アプリケーションで始動する 手段と、 前記ローカル・プロキシを使用して前記クライアント・アプリケーションを 構成し、始動する手段と を備えていることを特徴とするシステム。 15．請求項１１に記載のシステムにおいて、前記照会の前記アプリケーショ ン層プロコトルを変換する前記手段は、さらに、 圧縮、フィルタ、および暗号化に関する設定をもつ照会スクリプトを作成す る手段と、 前記照会スクリプトをカプセル化し、前記コミュニケーション・パスを通し て前記ローカル・プロキシから前記リモート・プロキシに伝送する手段と を含んでいることを特徴とするシステム。 16．請求項１５に記載のシステムにおいて、前記データ・オブジェクトの前 記アプリケーション層プロトコルを変換する前記手段は、さらに、 前記照会スクリプトに含まれる設定に従って前記データ・オブジェクトを圧 縮し、フィルタリングし、暗号化する手段と、 前記データ・オブジェクトを応答スクリプトに入れて、前記コミュニケーシ ョン・パスを通して前記リモート・プロキシから前記ローカル・プロキシに伝送 する手段と を含んでいることを特徴とするシステム。 17．請求項１６に記載のシステムにおいて、さらに、 前記応答スクリプトを前記ローカル・プロキシで受信したとき前記応答スク リプトを前記照会スクリプトと突き合わせる手段と、 前記応答スクリプトを前記クライアント・アプリケーションに送付する手段 と、 前記データ・オブジェクトを前記応答スクリプトからアンパッケージする手 段と、 前記データ・オブジェクトを前記第１ロケーションで表示する手段と を備えていることを特徴とするシステム。 18．請求項１１に記載のシステムにおいて、さらに、 サービス・スクリプトを前記リモート・プロキシで作成する手段と、 前記サービス・スクリプトを前記リモート・プロキシから前記ローカル・プ ロキシに伝送する手段と、 前記サービス・スクリプトを解析し、要求アクションとデータ・オブジェク トを前記サービス・スクリプトから抜き出す手段と を備えていることを特徴とするシステム。 19．請求項１１に記載のシステムにおいて、前記コミュニケーション・パス は高レイテンシ・コミュニケーション・パスであることを特徴とするシステム。 20．請求項１９に記載のシステムにおいて、前記コミュニケーション・パス はワイヤレス・ネットワークを含むことを特徴とするシステム。 21．リモート・サーバと通信するシステムであって、該システムは、 ユーザ・インタフェースのためのクライアント・アプリケーションをもつホ スト・コンピュータと、 アプリケーション層プロトコルを使用して前記クライアント・アプリケーシ ョンと通信するローカル・プロキシであって、該ローカル・プロキシ手段は前記 アプリケーション層プロコトルをトランスポート層プロトコルに変換する手段を もつものと、 トランスポート・プロトコルを使用して前記ローカル・プロキシと通信する リモート・プロキシであって、該リモート・プロキシは前記トランスポート・プ ロトコルを前記アプリケーション層プロトコルに変換する手段を含み、さらに、 該リモート・プロキシは前記アプリケーション層プロトコルを使用して前記リモ ート・サーバと通信する手段を含むものとを備えていることを特徴とするシステ ム。 22．請求項２１に記載のシステムにおいて、前記ローカル・プロキシと前記 リモート・プロキシは高レイテンシ・コミュニケーション・パスを通して通信す ることを特徴とするシステム。 23．請求項２１に記載のシステムにおいて、前記ローカル・プロキシと前記 リモート・プロキシはワイヤレス・ネットワークを通して通信することを特徴と するシステム。 24．請求項２１に記載のシステムにおいて、前記プロキシはデータ伝送を暗 号化するための少なくとも１つの暗号化アルゴリズムを備えていることを特徴と するシステム。 25．請求項１に記載の方法において、前記プロキシにデータ伝送を暗号化す るための少なくとも１つの暗号化アルゴリズムを装備することを、さらに含むこ とを特徴とする方法。 26．請求項２１に記載のシステムにおいて、前記リモート・プロキシは前記 ホスト・コンピュータへのデータ伝送をフィルタリングすることを特徴とするシ ステム。 27．請求項１に記載の方法において、前記サーバ・アプリケーションから前 記ホスト・コンピュータへのデータ伝送を前記リモート・プロキシでフィルタリ ングすることを、さらに含むことを特徴とする方法。 28．請求項２１に記載のシステムにおいて、前記プロキシは前記サーバ・ア プリケーションと前記ホスト・コンピュータとの間のデータ伝送を圧縮すること を特徴とするシステム。 29．請求項１に記載の方法において、前記サーバ・アプリケーションと前記 ホスト・コンピュータとの間のデータ伝送を前記プロキシで圧縮するステップを さらに含むことを特徴とする方法。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ブリッツァー，リサ，ビー. アメリカ合衆国 07726 ニュージャージ ー州 マナラパン グラマーシー レーン 10 (72)発明者 ブロックマン，ジェームズ，ジョーゼフ アメリカ合衆国 08535 ニュージャージ ー州 ペリネヴィル ランニング ブルッ ク ドライブ 15 (72)発明者 クルツ，ウィリアム アメリカ合衆国 07724 ニュージャージ ー州 イートンタウン ヴィオラント コ ート ９ (72)発明者 ハキム，ドワイト，オマール アメリカ合衆国 07747 ニュージャージ ー州 マタワン ティナ プレイス 20 (72)発明者 ホーヴェイ，リチャード，レイド アメリカ合衆国 08876 ニュージャージ ー州 サマーヴィル ノース ブリッジ ストリート 168 (72)発明者 クラマー，マイケル アメリカ合衆国 10471 ニューヨーク州 ブロンクス フィールドストン ロード 6136 (72)発明者 ペトル，ドーン，ダイアン アメリカ合衆国 08812 ニュージャージ ー州 グリーン ブローク ヘリテイジ ドライブ 18 (72)発明者 ラマロッソン，ジョセファ アメリカ合衆国 07728 ニュージャージ ー州 フリーホールド テランス テラス 23 (72)発明者 ラミレス，ジェラルド アメリカ合衆国 08807 ニュージャージ ー州 ブリッジウォーター サニー スロ ープ ロード 3505 (72)発明者 ワン，ヤン―ウェイ アメリカ合衆国 07731 ニュージャージ ー州 ハウエル ケンブリッジ ドライブ 10 (72)発明者 ホワイト，ロバート，ジー. アメリカ合衆国 07960 ニュージャージ ー州 モーリスタウン ノウルウッド ド ライブ 20

Claims (1)

1. 【特許請求の範囲】 １．コンピュータ・ネットワークと通信する方法であって、 ブラウザとローカル・プロキシをもつホスト・コンピュータを第１ロケーショ ンに設置し、 低バンド幅ネットワークを通して前記ローカル・プロキシと通信するリモート ・プロキシを第２ロケーションに設置し、 前記ブラウザで照会を開始し、アプリケーション層プロトコルを使用して前記 照会を該ローカル・プロキシに送信し、 該照会の前記アプリケーション層プロトコルを前記低バンド幅ネットワーク上 を伝送するのに適したトランスポート・プロトコルに変換し、 該照会を該低バンド幅ネットワークを利用して該ローカル・プロキシから前記 リモート・プロキシに伝送し、 前記トランスポート・プロトコルを前記コンピュータ・ネットワークで該照会 を実行するのに適したアプリケーション層プロトコルに変換することを含むこと を特徴とする方法。 ２．請求項１に記載の方法において、前記照会をネットワーク・サーバに伝達 し、該照会を実行し、データ・オブジェクトを前記リモート・プロキシに戻す前 記ステップをさらに含むことを特徴とする方法。 ３．請求項２に記載の方法において、さらに、 前記データ・オブジェクトを前記低バンド幅ネットワーク上を伝送するのに適 したトランスポート・プロトコルに変換し、 該データ・オブジェクトを該低バンド幅ネットワークを利用して前記リモート ・プロキシから前記ローカル・プロキシに伝送し、 該データ・オブジェクトの前記トランスポート・プロトコルを該ローカル・プ ロキシでアプリケーション層プロトコルに変換し、 該データ・オブジェクトを前記アプリケーション層プロトコルを使用して前記 ブラウザに伝達する前記ステップを含むことを特徴とする方法。 ４．請求項１に記載の方法において、スタートアップ・オペレーションをさら に含み、該スタートアップ・オペレーションは、 前記ホスト・コンピュータで前記ローカル・プロキシを始動し、 該ローカル・プロキシを使用して前記ブラウザを構成し、始動する前記ステッ プを含むことを特徴とする方法。 ５．請求項１に記載の方法において、前記照会の前記アプリケーション層プロ トコルを変換する前記ステップは、さらに、 圧縮、フィルタ、および暗号化に関する設定値をもつ照会スクリプトを作成し 、 前記照会スクリプトをカプセル化して、前記低バンド幅ネットワークを利用し て前記ローカル・プロキシから前記リモート・プロキシに伝送する前記ステップ を含むことを特徴とする方法。 ６．請求項５に記載の方法において、前記データ・オブジェクトの前記アプリ ケーション層プロトコルを変換する前記ステップは、さらに、 前記照会スクリプトに含まれる前記設定値に従って該データ・オブジェクトを 圧縮し、フィルタリングし、暗号化し、 該データ・オブジェクトを応答スクリプトに入れて、前記低バンド幅ネットワ ークを利用して前記リモート・プロキシから前記ローカル・プロキシに伝送する 前記ステップを含むことを特徴とする方法。 ７．請求項６に記載の方法において、さらに、 前記応答スクリプトを前記ローカル・スクリプトで受信したとき該応答スクリ プトを前記照会スクリプトと突き合わせ、 該応答スクリプトを前記ブラウザに送付し、 前記データ・オブジェクトを該応答スクリプトからアンパッケージし、 該データ・オブジェクトを該ブラウザのビュアで表示する前記ステップを含む ことを特徴とする方法。 ８．請求項１に記載の方法において、さらに、 サービス・スクリプトを前記リモート・プロキシで作成し、 前記サービス・スクリプトを該リモート・プロキシから前記ローカル・プロキ シに伝送し、 該サービス・スクリプトを解析し、要求アクションとデータ・オブジェクトを 該サービス・スクリプトから抜き出し、 サービス・アクションを該ローカル・プロキシで実行する前記ステップを含む ことを特徴とする方法。 ９．請求項１に記載の方法において、前記コンピュータ・ネットワークは、Ｗ orld Ｗide Ｗebであることを特徴とする方法。 10．コンピュータ・ネットワークと通信するシステムであって、 第１ロケーションに置かれていて、ブラウザとローカル・プロキシをもつホス ト・コンピュータと、 第２ロケーションに置かれていて、低バンド幅ネットワークを通して前記ロー カル・プロキシと通信するリモート・プロキシと、 前記ブラウザで照会を開始し、アプリケーション層プロコトルを使用して前記 照会を該ローカル・プロキシに送信するリモート・プロキシと、 該照会の前記アプリケーション層プロトコルを前記低バンド幅ネットワーク上 を伝送するのに適したトランスポート・プロトコルに変換する手段と、 該照会を該低バンド幅ネットワークを利用して該ローカル・プロキシから前記 リモート・プロキシに伝送する手段と、 前記トランスポート・プロトコルを前記コンピュータ・ネットワーク上で該照 会を実行するのに適したアプリケーション層プロトコルに変換する手段とを備え ていることを特徴とするシステム。 11．請求項１０に記載のシステムにおいて、前記照会をネットワーク・サーバ に伝達し、該照会を実行し、データ・オブジェクトを前記リモート・プロキシに 戻す手段をさらに備えていることを特徴とするシステム。 12．請求項１１に記載のシステムにおいて、さらに、 前記データ・オブジェクトを前記低バンド幅ネットワーク上を伝送するのに適 したトランスポート・プロトコルに変換する手段と、 該データ・オブジェクトを該低バンド幅ネットワークを利用して前記リモート ・プロキシから前記ローカル・プロキシに伝送する手段と、 該データ・オブジェクトのトランスポート・プロトコルを該ローカル・プロキ シでアプリケーション層プロトコルに変換する手段と、 前記アプリケーション層プロトコルを使用して該データ・オブジェクトを前記 ブラウザに伝達する手段とを備えていることを特徴とするシステム。 13．請求項１０に記載のシステムにおいて、さらに、 前記ローカル・プロキシを前記ホスト・コンピュータで始動する手段と、 該ローカル・プロキシを使用して前記ブラウザを構成し、始動する手段とを備 えていることを特徴とするシステム。 14．請求項１０に記載のシステムにおいて、前記照会の前記アプリケーション 層プロコトルを変換する前記手段は、さらに、 圧縮、フィルタ、および暗号化に関する設定値をもつ照会スクリプトを作成す る手段と、 前記照会スクリプトをカプセル化し、前記低バンド幅ネットワークを利用して 前記ローカル・プロキシから前記リモート・プロキシに伝送する手段とを含んで いることを特徴とするシステム。 15．請求項１４に記載のシステムにおいて、前記データ・オブジェクトの前記 アプリケーション層プロトコルを変換する前記手段は、さらに、 前記照会スクリプトに含まれる設定値に従って前記データ・オブジェクトを圧 縮し、フィルタリングし、暗号化する手段と、 該データ・オブジェクトを応答スクリプトに入れて、前記低バンド幅ネットワ ークを利用して前記リモート・プロキシから前記ローカル・プロキシに伝送する 手段とを含んでいることを特徴とするシステム。 16．請求項１５に記載のシステムにおいて、さらに、 前記応答スクリプトを前記ローカル・プロキシで受信したとき該応答スクリプ トを前記照会スクリプトと突き合わせる手段と、 該応答スクリプトを前記ブラウザに送付する手段と、 該データ・オブジェクトを該応答スクリプトからアンパッケージする手段と、 該データ・オブジェクトを該ブラウザのビュアで表示する手段とを備えている ことを特徴とするシステム。 17．請求項１０に記載のシステムにおいて、さらに、 サービス・スクリプトを前記リモート・プロキシで作成する手段と、 前記サービス・スクリプトを該リモート・プロキシから前記ローカル・プロキ シに伝送する手段と、 該サービス・スクリプトを解析し、要求アクションとデータ・オブジェクトを 該サービス・スクリプトから抜き出す手段と、 サービス・アクションを該ローカル・プロキシで実行する手段とを備えている ことを特徴とするシステム。 18．請求項１０に記載のシステムにおいて、前記低バンド幅ネットワークはワ イヤレス・ネットワークを含むことを特徴とするシステム。 19．請求項１０に記載のシステムにおいて、前記コンピュータ・ネットワーク はＷorld Ｗide Ｗebを含むことを特徴とするシステム。 20．コンピュータ・ネットワークと通信するシステムであって、 ユーザ・インタフェースのためのブラウザをもつホスト・コンピュータと、 アプリケーション層プロトコルを使用して前記ブラウザと通信するローカル・ プロキシ手段であって、該ローカル・プロキシ手段は前記アプリケーション層プ ロコトルをトランスポート・プロトコルに変換する手段をもつものと、 前記トランスポート・プロトコルを使用して該ローカル・プロキシ手段と通信 するリモート・プロキシ手段であって、該リモート・プロキシ手段は前記トラン スポート・プロトコルを該アプリケーション層プロトコルに変換する手段をもち 、該リモート・プロキシ手段は該アプリケーション層プロトコルを使用して前記 コンピュータ・ネットワークと通信する手段をもつものとを備えていることを特 徴とするシステム。 21．請求項２０に記載のシステムにおいて、前記ローカル・プロキシと前記リ モート・プロキシは低バンド幅ネットワークを通して通信することを特徴とする システム。 22．請求項２０に記載のシステムにおいて、前記ローカル・プロキシと前記リ モート・プロキシはワイヤレス・ネットワークを通して通信することを特徴とす るシステム。 23．セキュアド・コンピュータ・ネットワーク・インタフェースであって、 保護コンピュータまたはコンピュータ・ネットワークと、 公衆コンピュータ・ネットワークと、 前記保護コンピュータまたはコンピュータ・ネットワークと通信ネットワーク とを接続するローカル・プロキシと、 前記通信ネットワークと前記公衆コンピュータ・ネットワークとを接続するリ モート・プロキシとを備え、 前記プロキシはデータ伝送を暗号化する少なくとも１つの暗号化アルゴリズム を備えていることを特徴とするセキュアド・コンピュータ・ネットワーク・イン タフェース。 24．請求項２３に記載のセキュアド・コンピュータ・ネットワーク・インタフ ェースにおいて、前記コンピュータ・ネットワークと前記公衆コンピュータ・ネ ットワークとの間のコネクションを所有または維持管理するサービス・プロバイ ダをさらに含み、前記少なくとも１つの暗号化アルゴリズムは前記サービス・プ ロバイダが前記保護コンピュータまたはコンピュータ・ネットワークにアクセス できるように該サービス・プロバイダに知られていることを特徴とするセキュア ド・コンピュータ・ネットワーク・インタフェース。 25．請求項２４に記載のセキュアド・コンピュータ・ネットワーク・インタフ ェースにおいて、前記サービス・プロバイダは前記保護コンピュータまたはコン ピュータ・ネットワーク上のソフトウェアを更新または構成する目的で保護コン ピュータまたはコンピュータ・ネットワークにアクセスすることを特徴とするセ キュアド・コンピュータ・ネットワーク・インタフェース。 26．コンピュータ・ネットワーク・インタフェースを安全保護する方法であっ て、 保護すべきコンピュータまたはコンピュータ・ネットワークを準備し、 前記保護コンピュータまたはコンピュータ・ネットワークと通信ネットワーク をローカル・プロキシと接続し、 前記通信ネットワークと公衆コンピュータ・ネットワークをリモート・プロキ シと接続し、 前記ローカル・プロキシと前記ローカル・プロキシにデータ伝送を暗号化する 少なくとも１つの暗号化アルゴリズムを装備させるステップを含むことを特徴と するコンピュータ・ネットワーク・インタフェースを安全保護する方法。 27．請求項２６に記載のコンピュータ・ネットワーク・インタフェースを安全 保護する方法において、さらに、 前記通信ネットワークと前記公衆コンピュータ・ネットワークとの間のコネク ションを管理し、 該通信ネットワークと該公衆コンピュータ・ネットワークとの間の前記コネク ションを管理するサービス・プロバイダに少なくとも１つの暗号化アルゴリズム を提供するステップを含むことを特徴とする方法。 28．請求項２７に記載のセキュアド・コンピュータ・ネットワーク・インタフ ェースにおいて、前記少なくとも１つの暗号化アルゴリズムを使用して前記保護 コンピュータまたはコンピュータ・ネットワークにアクセスして、前記サービス ・プロバイダが該保護コンピュータまたはコンピュータ・ネットワーク上のソフ トウェアを更新または構成できるようにするステップをさらに含むことを特徴と するセキュアド・コンピュータ・ネットワーク・インタフェース。 29．フィルタリング・コンピュータ・ネットワーク・インタフェースであって 、 保護コンピュータまたはコンピュータ・ネットワークと、 公衆コンピュータ・ネットワークと、 前記保護コンピュータまたはコンピュータ・ネットワークと通信ネットワーク とを接続するローカル・プロキシと、 前記通信ネットワークと前記公衆コンピュータ・ネットワークとを接続するリ モート・プロキシとを備え、 前記リモート・プロキシは該公衆コンピュータ・ネットワークから該保護コン ピュータまたはコンピュータ・ネットワークへのデータ伝送をフィルタリングす ることを特徴とするフィルタリング・コンピュータ・ネットワーク・インタフェ ース。 30．コンピュータ・ネットワーク・インタフェースを通してデータをフィルタ リングする方法であって、 保護コンピュータまたはコンピュータ・ネットワークを準備し、 前記保護コンピュータまたはコンピュータ・ネットワークと通信ネットワーク をローカル・プロキシと接続し、 前記通信ネットワークと公衆コンピュータ・ネットワークをリモート・プロキ シと接続し、 前記公衆コンピュータ・ネットワークから該保護コンピュータまたはコンピュ ータ・ネットワークへのデータ伝送を前記リモート・プロキシでフィルタリング するステップを含むことを特徴とする方法。 31．データを圧縮するコンピュータ・ネットワーク・インタフェースであって 、 加入者コンピュータまたはコンピュータ・ネットワークと、 公衆コンピュータ・ネットワークと、 前記加入者コンピュータまたはコンピュータ・ネットワークと通信ネットワー クとを接続するローカル・プロキシと、 前記通信ネットワークと前記公衆コンピュータ・ネットワークとを接続するリ モート・プロキシとを備え、 前記プロキシは該公衆コンピュータ・ネットワークと該加入者コンピュータま たはコンピュータ・ネットワークとの間のデータ伝送を圧縮することを特徴とす るデータを圧縮するコンピュータ・ネットワーク・インタフェース。 32．コンピュータ・ネットワーク・インタフェースを使用してデータを圧縮す る方法であって、 加入者コンピュータまたはコンピュータ・ネットワークを準備し、 前記加入者コンピュータまたはコンピュータ・ネットワークと通信ネットワー クをローカル・プロキシと接続し、 前記通信ネットワークと公衆コンピュータ・ネットワークをリモート・プロキ シと接続し、 前記公衆コンピュータ・ネットワークと該加入者コンピュータまたはコンピュ ータ・ネットワークとの間のデータ伝送を前記ローカル・プロシキと前記リモー ト・プロキシで圧縮するステップを含むことを特徴とするコンピュータ・ネット ワーク・インタフェースを使用してデータを圧縮する方法。 付録Ａ 頭字語一覧 ＣＤＰＤ セルラ・ディジタル・パケット・データ（Ｃellular Ｄigital Ｐa cket Ｄata） ＦＴＰ ファイル転送プロトコル（Ｆile Ｔransfer Ｐrotocol） ＨＴＭＬ ハイパーテキスト・マークアップ言語（Ｈyper Ｔext Ｍarkup Ｌa nguage） ＨＴＴＰ ハイパーテキスト・トランスポート・プロトコル（Ｈyper Ｔext Ｔransport Ｐrotocol） ＩＰ インターネット・プロトコル（Ｉnternet Ｐrotocol） ＩＳＤＮ 統合サービス・ディジタル網（Ｉntegrated Ｓervices Ｄigital Ｎetwork） ＩＳＧ 統合サービス・ゲートウェイ（Ｉntegrated Ｓervices Ｇateway） ＩＳＰ インターネット・サービス・プロバイダ（Ｉnternet Ｓervice Ｐrov ider） ＬＡＮ ローカル・エリア・ネットワーク（Ｌocal Ａrea Ｎetwork） ＬＰ ローカル・プロキシ（Ｌocal Ｐroxy） ＬＺＷ Ｌev-Ｚempel-Ｗelch ＯＳＩ 開放型システム間相互接続（Ｏpen Ｓystems Ｉnterconnection） ＰＣＩ パーソナル・コミュニケーションズ・インターネットワーク（Ｐerso nal Ｃommunications Ｉnternetwork） ＰＤＡ パーソナル・ディジタル・アシスタント（Ｐersonal Ｄigital Ａssi stant） ＲＰ リモート・プロキシ（Ｒemote Ｐroxy） ＳＭＴＰ シンプル・メール転送プロトコル（Ｓimple Ｍail Ｔransfer Ｐro tocol） ＳＳＬ セキュア・ソケット層（Ｓecure Ｓocket Ｌayer） ＴＣＰ 伝送制御プロトコル（Ｔransmission Ｃontrol Ｐrotocol） ＵＤＰ ユーザ・データグラム・プロトコル（Ｕser Ｄatagram Ｐrotocol） ＵＲＬ 汎用リソース・ロケータ（Ｕniversal Ｒesource Ｌocator） ＷＡＩＳ 広域情報検索（Ｗide Ａrea Ｉnformation Ｓearch） ＷＷＷ ワールド・ワイド・ウェブ（Ｗorld Ｗide Ｗeb）