JP2004531782A - リアルタイムなビジネス・コラボレーションの方法 - Google Patents

Abstract

データの伝送を最適化するため、および好ましくは持続的接続が異なるファイアウォールを横切って維持できるようにするために、別個の転送プロトコル間でデータが少なくとも部分的に変換されるような、コンピュータ・ネットワーク通信用のコンピュータ・アーキテクチャおよびソフトウェア。好ましい実施形態として、転送プロトコル変換は、第１のファイアウォールのポート８０を横切って生じる持続的接続を可能にするためのＨＴＴＰ１．１プロトコルと、第２のファイアウォールを横切る持続的接続を可能にするための異なるプロトコルとの間で、データを変換させることができる。本発明のプロトコル変換は、コラボレーティブ・アプリケーション・ソフトウェアに関連して特に有用であり、コラボレーティブ・サーバおよびその関連付けられたクライアントは、それぞれ異なる転送プロトコルに、より適したものである。

Description

【０００１】
本発明は、インターネットなどのコンピュータ・ネットワークに関し、より詳細には、ネットワーク通信プロトコルおよびリアルタイムなコラボレーションのためにコンピュータ・ネットワークを介して通信されるデータのデータ形式の操作に関する。
【０００２】
（発明の背景）
コンピュータ・ネットワークは、ビジネス、娯楽、行政にとって重要な通信手段となった。たとえば、大企業の従業員はネットワーク化されたコンピュータのイントラネットを介して通信することができる。また、より広範囲にわたるコンピュータ・ネットワークもある。もちろん、インターネットは現在最も普及しているコンピュータ・ネットワークである。インターネットは、非常に多くの個人用コンピュータ、イントラネット、および他の小規模ネットワークを広大なグローバル・ネットワークに接続する、一種のメタネットワーク（ｍｅｔａ−ｎｅｔｗｏｒｋ）としての役割を果たす。インターネットの技術的詳細は、経時的に変化または進化していく可能性があるが、おそらく小規模コンピュータ・ネットワークならびに地球規模の１つまたは複数のコンピュータ・ネットワークは引き続き存在していくであろう。
【０００３】
インターネットおよび他のコンピュータ・ネットワークを介した大量のデータ通信は、伝送制御プロトコル（「ＴＣＰ」）仮想回路接続を通じて実行される。仮想回路接続では、通信中の２つのコンピュータは、電話線などの単一の静的通信パスによって接続されているかのように、コンピュータ・ネットワークを介してデータを送信および受信する。ただし、実際の通信は、どんな単一の専用の有線または無線パスを介しても実行されないのが一般的である。代わりに、どのパスがデータの伝送に最も利用しやすいかに依存した、様々なパスを介してデータ通信の様々な部分を送信するパケット交換の複雑なシステムがある。仮想回路接続の特徴は、すべてのデータを信頼できるインオーダ送達（ｉｎ−ｏｒｄｅｒ ｄｅｌｉｖｅｒｙ）で搬送することである。
【０００４】
仮想回路接続のインターネット世界には、通常、間欠的および持続的という２種類の通信がある。間欠的通信では、通信する２つのコンピュータが、時間の経過と共に複数の仮想接続を間欠的に確立し、切断し、再度確立する。持続的通信では、実在的なデータがどちらの方向にも送られていない休止中であっても、単一の仮想回路接続が維持される。
【０００５】
この間欠的通信には利点がある。基本的に間欠的通信のコンテキストでは、通信の両端にあるコンピュータは、持続的接続を維持しないことによってそれら自体のリソースの使用を節約する。サーバ・コンピュータは、インターネットに接続された（世界中の）多数のクライアント・コンピュータからの多くの重複する要求を処理する必要があるので、このような節約がサーバ・コンピュータ側では特に重要になる場合がある。
【０００６】
ただし、間欠的通信にはいくつかの欠点もある。たとえば、２人またはそれ以上の個人がリアルタイムの通信を望む場合、理論的には高速の連続する間欠的な接続で実行することができる。この１つの例がポーリングと呼ばれ、クライアント・コンピュータは、サーバ・エンド側にクライアントがアクセスしたいような新しいデータがないことを確認するために、継続的かつ連続的にサーバ・コンピュータとの短時間接続を確立するものである。
【０００７】
ただし、サーバ・エンドで追加された任意の新しいデータが、（リアルタイム・コラボレーションを容易にするために）クライアント・エンドで即時に要求および受信されることを保証するためには、多くの連続する間欠的通信が必要であり、これによって、個々のクライアント・コンピュータ・システムのコンピュータ・システム・リソース、ならびにネットワーク・リソース（たとえばインターネット帯域幅）を大量に消費させる可能性がある。この問題がより深刻になるのは、クライアント・コンピュータ・システムのユーザがリアルタイムでデータを受信していると感じられるように、十分な速さで任意の新しい関連するサーバ・データがクライアント・システムに到達しなければならない場合である。相互に通信している通信者の数が増えるに従って、これらの問題もますます深刻になる。
【０００８】
従来の間欠的ネットワーク通信の制限には、様々な方法で対処してきた。たとえば、データ（たとえばオーディオ・ビデオ・データ）をサーバからクライアントへ持続的に伝送するために、サーバ・コンピュータからクライアントへのインターネットを介したストリーミング供給を供給することができる。異なる例として、チャット・ルームをセットアップするために、インターネット・リレー・チャット（「ＩＲＣ」）などの専用ソフトウェアが使用され、このソフトウェアでは、多数のリモート・コンピュータがチャット・ルームの設定でテキストベース・メッセージをリアルタイムで相互に送信することが可能であり、サーバは所与の参加者によりシステムに入力された新しいチャット・データを配布するためにクライアントにコールバックする。
【０００９】
オーディオ・ビデオ・ストリーミングおよびチャット・ルームなどのいくつかのタイプの接続には、それ自体の欠点がある。たとえばこれらの通信タイプが、非標準ネットワーク・ポートの使用および／またはサーバからクライアントへの接続開始（サーバ・コールバック）によるファイアウォールの使用、ならびに／あるいはデータを通信する際に従うプロトコルと矛盾する可能性がある。これらの潜在的な解決策には、通信可能なデータのタイプに関する制限もある。これらの潜在的な解決策は、２つまたは複数の互いに遠隔なクライアントが並行してかつ同時に、コンピュータ・ネットワークを介して１つまたは複数のファイアウォールを横切り、アプリケーション（たとえばリモート・サーバ・マシン上のワード・プロセッシング・アプリケーション）にアクセスしてこれを制御する、インターネットを介したコンピュータ・ネットワークのアプリケーション・コラボレーションには特に適していないと考えられる。
【００１０】
（発明の概要）
本発明は、コンピュータ・ネットワーク転送プロトコルの操作に対処するものであり、その結果、転送プロトコルは、特に互いに遠隔なユーザによるアプリケーションのコラボレーティブな使用を可能にするのに必要な通信をネットワーク化するために、効果的なネットワーク通信で最適化される。
【００１１】
この最適化には、クライアント・コンピュータおよびファイアウォールが動作する方法に対して敏感であることが含まれ、その結果、持続的接続、読取りブロック通信（ｂｌｏｃｋｉｎｇ−ｏｎ−ａ−ｒｅａｄ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、キープアライブ通信（ｋｅｅｐ−ａｌｉｖｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ステートフル通信（ｓｔａｔｅｆｕｌ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）などを、様々なタイプのファイアウォールを介して有効とすることができる。この最適化には、サーバ・コンピュータのネットワーク内で高速かつ効率的な通信を容易にするために、転送プロトコルに対する敏感さも含むことができる。多くの場合、クライアント・コンピュータ・サブシステムにとって最良の転送プロトコルは、サーバ・コンピュータ・サブシステムにとって最良の転送プロトコルと同じではない。
【００１２】
このような課題が与えられたため、本発明のいくつかの実施形態にはプロトコル間での変換のためのコンピュータ・プログラムがあり、その結果、データ通信は、コンピュータ・システムのサーバ・エンドおよびクライアント・エンドの両方で異なる最適な転送プロトコルを明らかにする。たとえば、一部のファイアウォール（通常はクライアント・ファイアウォール）は、ポート８０を介したステートフルなＨＴＴＰ１．１キープアライブ接続に非常に適している。他のタイプのファイアウォール（通常はサーバ・ファイアウォール）は、オブジェクト直列化用プロトコルなどの他のプロトコルの下で、非予約ネットワーク・ポートを介してステートフルで持続的な通信が可能なように構成される。本発明は、選択された転送プロトコルが関連するファイアウォールを介した持続的通信に適するように、転送プロトコル間でデータを変換することにより、これらおよび／または他のタイプのプロトコルを有するコンピュータ・ネットワークを介した持続的（かつ好ましくはリアルタイムな）通信の達成を助けることができる。
【００１３】
本発明のいくつかの実施形態には、複数のスレッドを有し、１つまたは複数のクライアント・コンピュータ・システムへの持続的な接続を介してデータを送信する、サーバが含まれる。たとえば、リアルタイムのコラボレーティブ・アプリケーション（たとえばコラボレーティブ・スケジューリング・プログラム）用のサーバ・コンピュータ・システムは、複数のクライアント・コラボレータ・コンピュータ・システム用の複数のスレッドを使用し、ＨＴＴＰ１．１プロトコルの下で、各クライアントのファイアウォールのポート８０を介して生じた持続的、ステートフル、キープアライブ接続を介してリアルタイムに、これらのクライアント・コラボレータにデータを返送することができる。
【００１４】
本発明は、リアルタイム通信を容易にするためのコンピュータ・ネットワークのアーキテクチャおよびソフトウェアに対処するものである。本発明は、１つまたは複数のファイアウォールを含むコンピュータ・システムのコンテキストでのリアルタイム通信のコンテキストで、特に役立つと考えられる。本発明の最も好ましい実施形態には、リアルタイム・アプリケーション・コラボレーションが含まれる。
【００１５】
少なくとも本発明のいくつかの実施形態は、以下の目的、利点、および特典のうちの１つまたは複数を示すことができる。
（１）インターネットなどのコンピュータ・ネットワークを介したリアルタイム通信および／またはコラボレーション、
（２）インターネットなどのコンピュータ・ネットワークを介した、高スケーラブルな通信および／またはコラボレーション、
（３）セキュリティ機能およびファイアウォールに非常に適した方法での、コンピュータ・ネットワークを介したコラボレーションおよび／または通信、
（４）コンピュータ・ネットワーク通信および／またはコラボレーションを達成するために必要なファイアウォール構成アクティビティの削減、
（５）コンピュータ・ネットワークを介した持続的な通信および／またはコラボレーションを実行するために必要なクライアント・コンピュータ・リソースの削減、
（６）コンピュータ・ネットワークを介した持続的な通信および／またはコラボレーションを実行するために必要なサーバ・コンピュータ・リソースの削減、ならびに
（７）コラボレーティブなネットワークベース・アプリケーションのコンテキストで、共用アプリケーションの内容に関してリアルタイムで真に協働可能な２つの互いに遠隔なクライアント・コラボレータ。
【００１６】
本発明の一態様によれば、コンピュータ・システムには、第１のコンピュータ・ネットワーク、第１のコンピュータ・サブシステム、第２のコンピュータ・サブシステム、および第２のサブシステム・ファイアウォールが含まれる。第１のコンピュータ・サブシステムにはコラボレーティブ・アプリケーション・ソフトウェアが含まれ、このコラボレーティブ・アプリケーション・ソフトウェアは、コンピュータ・ネットワークを介してアプリケーション出力データを送信するためのマシン読取り可能命令を含む。第２のコンピュータ・サブシステムは、アプリケーション出力データを受信するように構成される。第２のサブシステム・ファイアウォールは、第２のアプリケーション・サブシステムの前方に配置される。第２のサブシステム・ファイアウォールは、コラボレーション実施中はオープンになっているハイパーテキスト転送プロトコルのキープアライブ接続を介して、アプリケーション出力データを第２のコンピュータ・サブシステムへ送るように構成される。
【００１７】
本発明の他の応用例は、詳細な説明および添付の図面を再検討すれば明らかになろう。説明および例には本発明の好ましい実施形態が示されているが、これらの説明および例は本発明の範囲を限定することを意図するものではなく、当分野の技術者であれば、本発明の精神および範囲内での様々な変更および修正が明らかであろう。
【００１８】
本発明は、以下の詳細な説明、ならびに例示のためにのみ与えられたものであって本発明の範囲を制限するものとして解釈されるものではない添付の図面から、より完全に理解されよう。
【００１９】
図の説明を始める前に、いくつかの用語について定義する。
【００２０】
（好ましい実施形態の詳細な説明）
定義
ゲートウェイ・ソフトウェア：２つの異なるプロトコル間でデータ（たとえばデータ・パケット）を変換するためのマシン読取り可能命令。「ゲートウェイ」は、本明細書では適切に確立された主格の意味で使用されており、品物、サービス、または任意の特定の商用エンティティを指すものではないことに留意されたい。
コンピュータ・ネットワーク：有線ネットワーク、無線ネットワーク、ならびに無線部分および有線部分を含むハイブリッド・ネットワークのすべてを含む。
コンピュータ・システム：コンピュータまたはコンピュータのネットワーク。
コンピュータ・サブシステム：コンピュータまたはコンピュータのネットワーク。一般に大規模システムの一部。
転送プロトコル：データがファイアウォールで処理される方法に影響を与える、任意のコンピュータ・データ・プロトコル。従来のプロトコルは、伝送制御レベル・プロトコル、インターネット・レベル・プロトコル、ＩＰレベル・データ・プロトコル、データ・パケット・プロトコルなどのいくつかのレベルのプロトコル階層に従って編成されたが、本明細書で使用される転送プロトコルは、必ずしもこの階層内の任意の１レベルを指すものではなく、データがファイアウォールでどのように処理されるかに影響を与える任意のレベルでのプロトコル・データであって、現在および将来、ファイアウォールは現存する階層の複数のレベルでプロトコルを詳細に調べることが可能であり、本明細書で使用される転送プロトコルは、ファイアウォールを通過しようとするデータをどのように処理するかを決める際に、ファイアウォールが使用するプロトコル、またはプロトコルの一部、あるいはプロトコルの一部の組合せで構成されるものであることに留意されたい。
アプリケーション：少なくとも１つのマシン読取り可能命令を含む、マシン読取り可能コードのセット。
コラボレーティブ・アプリケーション：２つの異なるコンピュータの少なくとも２人から入力を受信し、この２人に出力を提供することが同時にできるアプリケーション。
リアルタイム：データ伝送の遅延がかなり短い（全体として）ことを特徴とし、その結果、分別のある人物がいかなる遅延もなく伝送を実施しているかのように知覚する。
持続的：持続的な仮想回路接続。
ステートレスおよびステートフル：ステートフルおよびステートレスは、コンピュータ・ネットワーク通信システムが、所与の対話シーケンスにおいて、１つまたは複数の先行イベントを記憶しているように設計されているか否かを示す。ステートフルとは、通常その目的用に指定した記憶フィールドの値を設定することにより、システムが対話の状態を追跡することを意味する。ステートレストとは、以前の対話の記録がなく、対話要求ごとに、付随する情報のみに基づいて処理しなければならないことを意味する。
第１の．．．情報：特許請求の範囲が第１の通信、第２の通信、第３の通信などに関して述べる場合、「第１」、「第２」、「第３」などのラベルは、（任意の所与の特許請求の範囲は、全体として読むと、通信の何らかの相対的タイミングを暗黙的または明示的に含意しているが）通信の相対的タイミングに関するいずれかのことを含意することを意図しておらず、言い換えれば、この相対的タイミングが残りのすべての特許請求の範囲の言語と矛盾していない限り、「第３のネットワーク通信」は「第１のネットワーク通信」よりも早い時間に発生することが可能であって、「第１の．．．情報」という句は、コンピュータ・システム内にそれ以前の通信がなかったことを含意するものではなく、本発明のほとんどとまでは行かないが多くの実施形態では、通信は任意の所与の特許請求の範囲で対処される「第１の．．．通信」より前に発生することになる。
スレッド：単一のコンピュータ・プログラム内で、コンピュータ・プログラム命令の他のシーケンスとは無関係に実行するようにスケジューリングされた、コンピュータ・プログラム命令のシーケンスであり、たとえば、現代のコンピュータ・プログラミング言語（たとえばＪａｖａ）では、並行プログラミングおよびプログラム・マルチタスキングの外観改善を容易にするために、スレッドに言語サポートを提供する。
通信ソフトウェア：コンピュータ・システム内のどこにでも配置または配布されたネットワーク通信の制御を助けるソフトウェア。
【００２１】
上記の定義が通常の、明白な、習慣的（とりわけ、辞書および／または技術辞典によって一般に明示されるような）意味と矛盾しない限り、上記の定義は補足的性格のものとみなすものとする。上記の定義が通常の、明白な、習慣的（とりわけ、辞書および／または技術辞典によって一般に明示されるような）意味と矛盾する場合、上記の定義が制限する。上記の定義が、何らかの面で通常の、明白な、習慣的意味よりも広範囲にわたる場合、上記定義は、少なくともその広範囲な面について制限することになる。
【００２２】
特許権所有者が該当する法律の下でそれ自体の辞書編集者として活動できる限り、上記に定義された用語を除き、特許請求の範囲の項に示されたすべての用語は、その通常の、明白な、習慣的（とりわけ、辞書および／または技術辞典によって一般に明示されるような）意味を呈するものであり、本明細書で具体的に定義されるとはみなされるものでないことがここでさらに指示される。「特別な定義」の推論に関するこの制限にもかかわらず、特許明細の範囲で使用される単語または用語が複数の代替の通常の、明白な、習慣的意味を有し、代替の意味の中から選択する場合に本明細書が役立つ状況では、本明細書は、該当する通常の、明白な、習慣的（とりわけ、辞書および／または技術辞典によって一般に明示されるような）意味を明示するために使用することができる。
【００２３】
好ましいコンピュータ・アーキテクチャ
図１は、本発明に従った例示的コンピュータ・システム１００を示す図である。図１に示されるように、サーバ・コンピュータ・サブシステム１０２、クライアントＡコンピュータ・サブシステム１０６、およびクライアントＢコンピュータ・サブシステム１０８が、ワイド・エリア・ネットワーク（「ＷＡＮ」）１３２によって接続される。サーバ・コンピュータ・サブシステム１０２は、ビジネス・コラボレーション・ソフトウェアを実行するように設計されたコンピュータ・システムであって、複数の相互に遠隔な場所にいる複数のユーザが、単一セットのコンピュータ・アプリケーション・データ（たとえば、ワード・プロセッシング文書）にアクセスし、これを操作できるようにするものである。従来の音声通信（たとえば電話）、電子メール通信、またはコンピュータ・ファイル転送では達成できない、ある種のある品質のビジネス通信および／またはあるレベルの共同作業を可能にするために、様々なユーザの操作がリアルタイムで効率的に他のユーザに送られることが好ましい。
【００２４】
クライアントＡコンピュータ・サブシステム１０６およびクライアントＢコンピュータ・サブシステム１０８は、それぞれ２人の互いに遠隔なコラボレータによってビジネス・コラボレーションを実行するために使用されるコンピュータ・サブシステムである。ＷＡＮ１３２は、サーバ・コンピュータ・サブシステム１０２の仲介によって、ユーザを互いにコラボレーティブに接続する。ＷＡＮ１３２はインターネットであることが好ましい。あるいはＷＡＮ１３２は、現在存在するかまたは将来開発される可能性のあるリモート・コンピュータを接続することのできる、任意の他の種類のコンピュータ・ネットワークであってよい。ＷＡＮ１３２は、有線ベース、無線、またはこれらのタイプの組合せであってよい。
【００２５】
ここで、サーバ・コンピュータ・サブシステム１０２のアーキテクチャについて詳細に論じる。サーバ・コンピュータ・サブシステム１０２は、サーバ・コンピュータ１１０、サーバ・ファイアウォール１２０、ローカル・エリア・ネットワーク（「ＬＡＮ」）１３０、ゲートウェイ・コンピュータ１１２、およびゲートウェイ・ファイアウォール１２２を含む。
【００２６】
サーバ・コンピュータ１１０は、中央処理ユニット（ＣＰＵ）１４０、コラボレーティブ・アプリケーション・ソフトウェア１５０、およびコラボレーティブ・アプリケーション・データベース１６０を含む。図１ではサーバ・コンピュータは単一のブロックとして示されているが、多くの代替実施形態では、サーバ・コンピュータ１１０はいくつかの相互接続されたコンピュータを介して分散されることになる。たとえばコラボレーティブ・アプリケーション・データベース１６０は、ＯＲＡＣＬＥデータベース・ソフトウェアなどのデータベース管理ソフトウェアを備えた別のコンピュータ上に常駐することが可能である。ＯＲＡＣＬＥという単語は商標権の対象となる可能性があることに留意されたい。
【００２７】
一般に、サーバ・コンピュータ１１０は、クライアントＡおよびクライアントＢなどの、互いに遠隔なユーザによってコラボレーティブに使用されるアプリケーションをホストする。このアプリケーションはワード・プロセッサ、タスク・スケジューリング・ツール、グラフィックス・プログラム、プレゼンテーション・プログラム、スプレッドシート、ゲーム、音楽スタジオ、あるいは、従来型または開発の可能性がある任意の他のタイプのコンピュータ・アプリケーションであってよい。どのようなアプリケーションであっても、本発明はクライアントＡおよびクライアントＢが共用アプリケーションの内容に関して、好ましくはリアルタイムで真に協働するのを助けることができる。たとえばその内容は、テキスト文書、グラフィック、ゲーム・パフォーマンス、または歌であってよい。
【００２８】
サーバ・コンピュータ１１０は、従来型サーバまたはミニサーバ・コンピュータであることが好ましい。サーバ・コンピュータは、アプリケーション・サーバが完全にＪＡＶＡで書かれた「Ｊａｖａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｏｒｉｅｎｔｅｄ Ｔｅｃｈｎｏｌｏｇｙ（Ｊａｖａ分散指向技術）」（すなわち「ＪＤＯＴ」）を使用することが好ましい。ＪＡＶＡおよびＪＤＯＴという単語および／または「Ｊａｖａ Ｄｉｓｔｒｉｂｕｔｅｄ Ｏｒｉｅｎｔｅｄ Ｔｅｃｈｎｏｌｏｇｙ」という句は、商標権の対象となる可能性があることに留意されたい。
【００２９】
高いレベルから、ＪＤＯＴサーバは、２次記憶域（ＳＱＬデータベースおよびＬＤＡＰディレクトリの両方）とインターフェースするきめ細かいデータ・セキュリティのためのフレームワーク、トランザクション管理、キャッシング、および特有のビジネス論理サービスを構築するための標準アーキテクチャ・フレームワークを提供する。ＪＤＯＴサーバの最も重要な特徴の１つが、複数のネットワーク化されたクライアントを効率的にリアルタイムで［たとえば１秒未満（ｓｕｂ−ｓｅｃｏｎｄ）］更新し、最終的には複数の参加者の間でのリアルタイム・ネットワーク・コラボレーションを容易にすることである。ＪＤＯＴによれば、コラボレーティブ・データ配布サービスは、Ｅｒｉｃｈ Ｇａｍｍａ等による「Ｄｅｓｉｇｎ Ｐａｔｔｅｒｎｓ：Ｅｌｅｍｅｎｔｓ ｏｆ Ｒｅｕｓａｂｌｅ Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ」に記載されているように、アルゴリズム的に最高レベルでのオブザーバ・パターンに基づくものである。ＪＤＯＴサーバのサービスは、効率的な、ファイアウォール適合の、分散型オブザーバ・システムを実施する。
【００３０】
そのため、ＪＤＯＴサーバおよび他の同様のサーバは、ロー・ソケット・データ（ｒａｗ ｓｏｃｋｅｔ ｄａｔａ）、オブジェクトのシリアル化用プロトコル、および／またはリモート方式呼出しプロトコルを使用する、持続的ネットワーク通信に最も適していることが多い。ＪＤＯＴサーバは、ＨＴＴＰ１．１プロトコル・データおよびファイアウォールのポート８０を介して生じるタイプの関連付けられた持続的接続には、あまり適していないことが多い。
【００３１】
ＣＰＵ１４０は、クライアントＡおよびクライアントＢからデータを受信し、このデータを使用して、クライアントＡおよびクライアントＢが協働しているテキスト文書などのコラボレーティブ・アプリケーション・データを操作する。ＣＰＵ１４０は、コラボレーティブ・アプリケーション・ソフトウェア１５０のマシン読取り可能命令に従うことによって、コラボレーティブ・アプリケーション作業を実行する。
【００３２】
コラボレーティブ・アプリケーション・ソフトウェア１５０はアプリケーションである。他の好ましい実施形態では、複数の種類のアプリケーションがサーバ・コンピュータ・サブシステム１０２で使用可能な場合があり、これら複数のアプリケーションは、ＬＡＮ１３０によって接続された別々のサーバ・コンピュータ上に格納するか、または格納しなくてよい。コラボレーティブ・アプリケーション・ソフトウェアは、従来のように、読取り専用メモリ、ランダム・アクセス・メモリ、データ記憶媒体、またはこれら記憶手段の組合せに格納することができる。以下で論じるように、コラボレーティブ・アプリケーション・ソフトウェア１５０は、クライアントＡ、クライアントＢ、および他のクライアントからデータを受信するように設計され、このデータは、何らかの所定の転送プロトコルによって特徴付けられる。この所定の転送プロトコルのアイデンティティは、コンピュータ・システム１００の残りのアーキテクチャおよび機能について以下で論じる場合に、重要となる。
【００３３】
コラボレーティブ・アプリケーション・データベース１６０は、前述のように、従来のコンピュータ・データベースであることが好ましい。コラボレーティブ・アプリケーションン・データベース１６０は、コラボレーティブ・アプリケーションに関するデータを格納する。たとえば、アプリケーションがコラボレーティブ・ワード・プロセッサの場合、ワード・プロセッサ・プログラムは、コラボレーティブ・アプリケーション・ソフトウェア１５０を含み、ワード・プロセッシング・ファイル（すなわち、実際の文書のテキストおよびフォーマットを表すマシン読取り可能データ）は、コラボレーティブ・アプリケーション・データベース１６０を含む。コラボレーティブ・アプリケーション・データベース１６０は、コラボレーティブ・アプリケーション・ソフトウェア１５０の利用が正当に許可されたリモート・コンピュータおよび／またはユーザのリストなどの、コラボレーティブ・アプリケーション・ソフトウェアに関する他のデータを格納することができる。
【００３４】
図１に示されるように、サーバ・コンピュータ１１０はサーバ・ファイアウォール１２０の後方に配置される。サーバ・ファイアウォール１２０は、従来のハードウェア・ベースおよび／またはソフトウェア・ベースのファイアウォールである。いくつかの例を提供するために、サーバ・ファイアウォール１２０は、サーバ・コンピュータ１１０上に常駐するソフトウェアまたは専用コンピュータ上のソフトウェアの形を取るか、あるいはハードウェア構成要素の形を取ることができる。
【００３５】
従来のファイアウォールと同様に、サーバ・ファイアウォール１２０は複数の「ポート」を有するように構成される。各ポートには、ポートを介して渡そうとするデータ・パケットを綿密に調べるための関連付けられた規則セットがある。たとえば、ポートは一定のプロトコルのデータしか通過させられない場合がある。また規則により、ファイアウォールは、データのコンテンツに関するチェックを実行するために、データ・パケットから実際のデータを抽出しなければならない場合がある。多くのファイアウォールに共通なように、サーバ・ファイアウォール１２０は、サーバ１１０に着信するデータ・パケットに対して、サーバ・コンピュータ１１０から発信するデータ・パケットに対するものとは異なる、より厳しい規則を適用する。ただし、持続的接続が確立されると、データの流れは、どちらの方向にも持続的、高速、かつ効率的である。
【００３６】
サーバ・ファイアウォール１２０は、ローカル・エリア・ネットワーク（ＬＡＮ１３０）とサーバ・コンピュータ（サーバ・コンピュータ１１０）との間に位置することに留意されたい。実際問題として、これが、サーバ・コンピュータ・サブシステム１０２のオペレータがサーバ・ファイアウォール１２０をどのように構成するかを選択する際に影響を与える可能性がある。たとえば、ファイアウォールはインターネットに隣接していないため、好ましいサーバ・ファイアウォール構成に影響を与える可能性がある。また、サーバ・コンピュータ（およびそのデータベース）に格納されたデータが極度に敏感であるため、ファイアウォール構成に影響を与える可能性もある。
【００３７】
そのため、サーバ・ファイアウォール１２２は、この種の理由のために、ゲートウェイ・ファイアウォール１２２、クライアントＡファイアウォール１２４、およびクライアントＢファイアウォール１２６などの、図１に示されたコンピュータ・システム１００の他のファイアウォールとは異なるように構成することができる。サーバ・ファイアウォール１２２は異なるように構成されるため、他のファイアウォールと同じ様々な持続的接続を確立できない場合があり、これが、以下でより詳細に説明するように転送プロトコル変換（ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｃｏｎｖｅｒｓｉｏｎまたはｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｔｒａｎｓｌａｔｉｏｎ）が実行される理由の１つである。
【００３８】
次にＬＡＮ１３０に移ると、この構成要素は、従来のローカル・エリア・ネットワークまたはイントラネットとして形成される。このＬＡＮ１３０および残りのサーバ・コンピュータ・システム１０２は、コラボレータであるクライアントＡおよびクライアントＢを雇用する企業によって維持されるか、あるいは、第三者のコンピュータ・サービス・プロバイダによって維持される場合がある。
【００３９】
この好ましい実施形態では、ＬＡＮ１３０は、コラボレーティブ・アプリケーションに関するデータの通信を、サーバ・コンピュータ１１０とゲートウェイ・コンピュータ１１２との間で通信できるようにするものである。他の好ましい実施形態では、ＬＡＮは、ゲートウェイ・コンピュータ１１２と、コラボレーティブ・アプリケーションの実施を協働的に共用するいくつかのサーバ・コンピュータとの間の通信を可能にする。他の実施形態では、ＬＡＮがまったく含まれない。たとえば、一部の実施形態では、サーバ・コンピュータ・サブシステム１０２が、ゲートウェイ・ソフトウェア１５２とコラボレーティブ・アプリケーション・ソフトウェア１５０の両方を有する単一のコンピュータの形式を取る場合があり、これによってサーバ側でのネットワーク化の必要がなくなる。
【００４０】
ゲートウェイ・コンピュータ１１２は、ＣＰＵ１４２およびゲートウェイ・ソフトウェア１５２を含む。ゲートウェイ・コンピュータ１１２はスタンドアロン型コンピュータ、サーバ・コンピュータ、またはミニサーバ・コンピュータとして実施されることが好ましい。ゲートウェイ・コンピュータ１３８は、キープアライブ機能でＨＴＴＰプロトコルをサポートするＷｅｂサーバ・ソフトウェアを備えたＷｅｂサーバであることが好ましい。
【００４１】
ゲートウェイ・ソフトウェア１５２は、ＣＰＵ１４２によって実行されるマシン読取り可能命令のセットである。ゲートウェイ・ソフトウェア１４２は、従来のように、読取り専用メモリ、ランダム・アクセス・メモリ、データ記憶媒体、またはこれら記憶手段の組合せに格納することができる。ゲートウェイ・ソフトウェア１５２は、ＷＡＮ１３２からサーバ・コンピュータ・サブシステム１０２に着信するデータ・パケット、ならびにサーバ・コンピュータ・サブシステム１０２からＷＡＮ１３２に発信するデータ・パケットをルーティングおよび操作する。第１に、ルーティング機能について簡単に説明し、次に着信するデータ・パケットおよび発信するデータ・パケットの操作について説明する。ゲートウェイ・ソフトウェア１４２は、ゲートウェイ・コンピュータ１１２内のＷｅｂサーバ・ソフトウェア（別々に図示せず）へのプラグインとして配置構成されることが好ましい。
【００４２】
ゲートウェイ・ソフトウェア１５２のルーティング機能は、主に、データ・パケットが正しいサーバ・コンピュータに到達することを保証する。もちろん、図１の実施形態ではサーバ・コンピュータ１１２が１つしかないため、この実施形態ではこのルーティング機能はそれほど重要でない。ただし、コラボレーティブ・アプリケーション・データベースが（多くの好ましい実施形態の場合のように）コラボレーティブ・アプリケーション・ソフトウェアとは別のコンピュータに格納された場合、ゲートウェイ・ソフトウェア１５２は、データ・パケットが適切なコンピュータに到達するように、そのルーティングを制御することになる。このルーティング機能は、実際のサーバのハードウェアおよびソフトウェアのセットアップに大幅に依存するものであるため、またいったんサーバのセットアップが決定されると、ルーティング機能は通常の日常的スキルの問題であるとみなされるため、本明細書では詳細に説明しない。
【００４３】
ゲートウェイ・ソフトウェア１５２は、（ＷＡＮ１３２から）着信するデータ・パケットと、（ＬＡＮ１３０から）発信するデータ・パケットの両方の転送プロトコルも変更する。この転送プロトコルの変換は、本発明の一部の実施形態では重要な部分であり、ゲートウェイ・ソフトウェア１５２の転送プロトコルおよびプロトコル変換については、本明細書の処理流れの項でより詳細に論じる。
【００４４】
さしあたり、ゲートウェイ・ソフトウェア１５２によって実行される転送プロトコル変換の特有の好ましい例について説明する。ゲートウェイ・ソフトウェア１５２は、ハイパーテキスト転送プロトコル１．１（「ＨＴＴＰ１．１」）と呼ばれる転送プロトコルを有する着信データ・パケットを、オブジェクト・シリアル化（図１ではＯＳと表示）用のプロトコルを有する対応するデータ・パケットに変換する。着信パケットは変換された後、ＬＡＮ１３０、サーバ・ファイアウォール１２０、およびサーバ・コンピュータ１１０に適宜送信される。さらにゲートウェイ・ソフトウェア１５２は、オブジェクト・シリアル化ＯＳ用のプロトコル中の発信データ・パケットも、ＨＴＴＰ１．１転送プロトコルを有する対応するデータ・パケットに変換する。発信パケットは変換された後、ゲートウェイ・ファイアウォール１２２、ＷＡＮ１３２、およびクライアントに適宜送信される。転送プロトコル変換の結果、図１に示されるように、ゲートウェイ・コンピュータ１１２のサーバ・コンピュータ側にあるデータ伝送接続はＯＳとラベル表示され、ゲートウェイ・コンピュータ１１２のクライアント側にあるデータ伝送接続はＨＴＴＰ１．１とラベル表示される。
【００４５】
このプロトコル変換ステップの最も重要な理由の１つが、コンピュータ・システム１００のサーバ側およびクライアント側で、異なる転送プロトコルがそれぞれより適切に働くことであり、次にこれについて論じる。ＨＴＴＰ１．１データ・パケットは、ゲートウェイ・ファイアウォール１２２、クライアントＡファイアウォール１２４、およびクライアントＢファイアウォール１２６でより適切に働く。ＨＴＴＰ１．１パケットは、ファイアウォールを再構成する必要なしに、多くの典型的なクライアント・ファイアウォールが事前に構成される、ポート８０を介して発生する持続的な「キープアライブ」接続と共に使用できるという意味で、より適切に働く。他方で、オブジェクト・シリアル化ＯＳ用のプロトコルは、多くの典型的なサーバ・ハードウェアでより適切に働く。たとえば、多くのサーバ・ファイアウォールは、ＯＳ転送プロトコル・データ・パケットが未予約ポート（たとえばポート８８９９）を介して自由に通過できるように構成される。さらに、多くのコラボレーティブ・アプリケーション・ソフトウェアは、ＯＳデータ・パケットまたはロー・ソケットなどの他の転送プロトコルに従ったデータと、互換性があるかまたはより効率的に働く。
【００４６】
転送プロトコル変換を実行することにより、特にコラボレーティブ・アプリケーションのコンテキストでは、データ・パケットは、一般的にコンピュータ・システムに見られる様々なファイアウォールを横切る持続的接続にとって、より適したものとなる。これらの持続的接続は、クライアント側およびサーバ側の両方でソケットでの読取りをブロックするスレッドを使用するために、非常に効果的に使用することができる。この読取りブロックは、クライアント側またはサーバ側のどちらでも、クライアント・コンピュータおよびサーバ・コンピュータのリソースを大量に使用せずに、新しいデータを即時に受信できるようにするものである。
【００４７】
転送プロトコル変換をサーバ・コンピュータ１１０で実行するのに対して、専用のゲートウェイ・コンピュータ１５２でこの変換を実行することによって達成される、潜在的な利点もいくつかある。第１に、ゲートウェイ・コンピュータは、ＷＡＮ１３２とサーバ・コンピュータ１１０の感知可能情報との間に特別なセキュリティ層を追加する。転送プロトコルはゲートウェイ・コンピュータで変更されるため、未許可の当事者（たとえばハッカー）がＷＡＮ１３２からサーバ・コンピュータ１１０にアクセスするのはかなり困難になると考えられる。第２に、プロトコルを変換するため、またはそうでなければコラボレーティブ・アプリケーション・ソフトウェア１５０が好む転送プロトコル（たとえばＯＳ）を示さない着信データに対処するために、サーバ・コンピュータ１１０のリソースを使用する必要がなくなる。第３に、いくつかのサーバ・コンピュータが存在する実施形態では、必要な転送プロトコル変換が、サーバ・サブシステムのいくつかの異なる場所ではなく、１つの中央位置（すなわちゲートウェイ・コンピュータ１５２）で実行される。
【００４８】
ゲートウェイ・ファイアウォール１２２は、ＷＡＮ１３２とゲートウェイ・コンピュータ１１２との間に置かれる。ゲートウェイ・ファイアウォール１２２は、ＨＴＴＰ１．１転送プロトコル・データ用の持続的な、読取りをブロックする、キープアライブ・タイプの接続を可能にするように構成される。この種の持続的接続は、ファイアウォールのポート８０を介して発生することが好ましい。ゲートウェイ・ファイアウォール１２２は、従来型のハードウェア・ベースおよび／またはソフトウェア・ベースのファイアウォールである。ゲートウェイ・ファイアウォール１２２は、ゲートウェイ・コンピュータ１１２に着信するデータ・パケットに対して、ゲートウェイ・コンピュータ１１２から発信するデータ・パケットに対するものとは異なる、より厳しい規則を適用する。ただし、キープアライブ接続が（適切な転送プロトコルを備えたデータに対して）確立されると、データの流れは、どちらの方向にも持続的、高速、かつ効率的である。
【００４９】
次に、クライアントＡコンピュータ・サブシステム１０６について論じる。クライアントＡコンピュータ・サブシステム１０６には、クライアントＡファイアウォール１２４、クライアントＡコンピュータ１１４、ディスプレイ・デバイス１７４、および入力デバイス１８４が含まれる。
【００５０】
クライアントＡファイアウォール１２４は、データがＨＴＴＰ１．１転送プロトコルを示す限り、持続的な、読取りをブロックする、キープアライブ接続が可能なように構成される。この持続的接続は、ファイアウォールのポート８０を介して発生することが好ましい。本発明のいくつかのコラボレーティブ・アプリケーション・ソフトウェア・システムの実施形態にとっては、ファイアウォールを横切る持続的接続を有することが重要な機能である。本発明のいくつかの実施形態にとっては、ファイアウォールを横切る持続的接続が、ファイアウォールの背後にあるコンピュータが、ポーリングの実施に必要なリソースを消費しなければならない代わりに、読取りをブロックできるようにすることが重要である。従来のコラボレーティブ・アプリケーション・ソフトウェアの応用例では、ポーリングなどの間欠的接続が使用される。これらの間欠的接続は、一般に、クライアント・コンピュータのコンピューティング・リソースが大量に必要とするものであり、コラボレーティブ・アプリケーションへの参加を希望する遠隔ユーザの増加に合わせて増えていくものではない。クライアントＡファイアウォール１２４は、コールバックとも呼ばれる、クライアントＡの外部にあるコンピュータ・システムからクライアントＡへの接続も許可しない。
【００５１】
スレッドおよび関連する読取りブロック・タイプの接続が使用されることは、本発明のいくつかのコラボレーティブ・アプリケーション・ソフトウェア実施形態の重要な特徴である。この種の接続は、システム全体で、特にクライアントＡコンピュータ１１４で、コンピューティング・リソースを節約する。これは、ＷＡＮ１３２を介してサーバ・コンピュータ・サブシステム１０２から新しいデータが受信されない限り、およびこれが受信されるまで、読取りブロック接続がクライアントＡコンピュータのスレッドを「スリープ」にできるためである。
【００５２】
クライアントＡ１１４コンピュータは、従来のデスクトップ型またはラップトップ型パーソナル・コンピュータであることが好ましい。ディスプレイ・デバイス１７４は、モニタまたはＬＣＤディスプレイを含むことが好ましく、さらにプリンタ、オーディオ・スピーカなどの他の出力デバイスも含むことができる。入力デバイス１８４は、キーボードおよびマウスを含むことが好ましく、スキャナなどの他の入力デバイスを含むことができる。
【００５３】
クライアントＢコンピュータ・システム１０８には、クライアントＢファイアウォール１２６、クライアントＢコンピュータ１１６、ディスプレイ・デバイス１７６、および入力デバイス１８６が含まれる。クライアントＢコンピュータ・システム１０８の構成要素は、クライアントＡコンピュータ・システムの対応する構成要素と同様であるため、ここではこれ以上論じない。
【００５４】
図１を終える前に、ディスプレイ・デバイス１７４、ディスプレイ・デバイス１８４、およびコラボレーティブ・アプリケーション・データベース１６０の「笑顔」の表示について論じる。この例示的実施形態では、コラボレーティブ・アプリケーション・ソフトウェアはグラフィックス・プログラムである。クライアントＡおよびクライアントＢは新しいグラフィックの生成でコラボレートしており、これが笑顔となる。図１の時点では、クライアントＡは自分の入力デバイス１８４を使用して笑顔に第２の眼を追加する作業を行っている。
【００５５】
クライアントＡが入力デバイス１８４を操作して第２の眼の追加を示すと、クライアントＡコンピュータ１１４はこの入力を該当するＨＴＴＰ１．１データ・パケットに変換する。これらのデータ・パケットには、コラボレーティブ・アプリケーション・ソフトウェア１５０およびコラボレーティブ・アプリケーション・データベース１６０によって使用され、最終的にＷＡＮ１３２上の他のコラボレータによって使用される、実際のアプリケーション入力データが含まれる。これらのＨＴＴＰ１．１パケットは、妨害を受けずにクライアントＡファイアウォール１２４のキープアライブ接続、さらにＷＡＮ１３２を通過し、（ここでも妨害を受けずに）ゲートウェイ・ファイアウォール１２２のキープアライブ接続を通過した後、ゲートウェイ・コンピュータ１１２に到達する。これでゲートウェイ・コンピュータは、読取りブロック接続を介してこの通信を受信する準備のできたクライアント・スレッドを確立した。
【００５６】
ゲートウェイ・コンピュータ１１２では、ゲートウェイ・ソフトウェア１５２がこれらのデータ・パケットを、ＨＴＴＰ１．１転送プロトコルからＯＳプロトコルに変換し、対応するＯＳパケットをＬＡＮ１３０、サーバ・ファイアウォール１２０、さらに最終的にサーバ・コンピュータ１１０へと送信する。前述のように、ＯＳパケットは妨害を受けずにサーバ・ファイアウォール１２０の未予約ポートを通過する。これでサーバ・コンピュータは、通信が到達したときにサーバ・コンピュータ１１０の該当する構成要素を起動させることによってこの通信を受信する準備のできたクライアントＡスレッドを確立した。サーバ・コンピュータは、クライアントＢなどの他のコラボレータ用の他のスレッドも確立した。これらのスレッドは、様々なソースから新しいアプリケーション入力データを受信する準備のできた状態でありながら、新しいデータが着信しない限り、および新しいデータが着信するまで、構成要素をスリープ状態にしておくことができるため、サーバ・コンピュータのコンピューティング・リソースをそれほど多く占有しない。
【００５７】
サーバ・コンピュータ１１０では、コラボレーティブ・アプリケーション・ソフトウェア１５０が、クライアントＡスレッド上で受信されたデータ・パケットが、笑顔のイメージに第２の眼を追加するように設計されていることを認識する。図１の参照番号１９０で示されるように、笑顔のイメージに対応するアプリケーション・データ・ファイルが、コラボレーティブ・アプリケーション・データベース１６０で更新される。少なくともサーバ・コンピュータ・サブシステム１０２では笑顔が完成する。
【００５８】
ただし、第２の眼のデータは、なおもコラボレータであるクライアントＡおよびクライアントＢのコンピュータに戻る必要がある。したがって、サーバ・コンピュータ１１０はこのデータを、最初はＯＳデータ・パケットとして返送する。ＯＳデータ・パケットは、ゲートウェイ・コンピュータ１１２で対応するＨＴＴＰ１．１データ・パケットに変換され、その後、残りの道のりをクライアントＡコンピュータ１１４およびクライアントＢコンピュータ１１６まで返送される。図１の時点では、ＨＴＴＰ１．１パケットはまだクライアントＡコンピュータ１１４およびクライアントＢコンピュータ１１６まで到達していないため、まだディスプレイ・デバイス１７４およびディスプレイ・デバイス１８４には第２の眼が表示されていない。
【００５９】
第２の眼のデータ・パケットは、クライアントＡおよびクライアントＢがリアルタイムでコラボレートしていることを知覚するように、十分な速度（たとえば１秒未満）でクライアント・コンピュータに到達することが好ましい。この高速な、好ましくはリアルタイムなビジネス・コラボレーションは、クライアント・コンピュータがそれぞれのファイアウォールを横切る持続的なキープアライブ接続を介してデータを受信し、ゲートウェイ・ソフトウェア１５２が転送プロトコルを変換することにより、コンピュータ・システム１００の、異なって構成されたファイアウォール１２０、１２２、１２４、および１２６を横切って、必要なデータ転送が即時に実行できるという事実によって容易になる。
【００６０】
さらに、持続的およびステートフルな接続によって、スレッドおよび読取りブロック・タイプ接続の使用が可能になり、コンピュータ・システム１００内のすべてのコンピュータでのコンピューティング・リソースが節約される。データ・パケットがネットワーク通信のすべての段階で適切な転送プロトコルを確実に有するようにすることによって、これらの持続的およびステートフルな接続ならびに関連付けられたスレッドおよび読取りブロックの使用が可能になる。
【００６１】
持続的接続をセットアップするための処理流れ
前述のように、クライアント・コンピュータとゲートウェイとの間、ならびにゲートウェイ・コンピュータとサーバ・コンピュータとの間には、持続的なデータ伝送接続がある。次に、（図２の流れ図に示されるような）これらの持続的接続を確立するための例示的な処理流れについて論じる。
【００６２】
ステップＳ１では、クライアントＡコンピュータ１１２がクライアントＡコンピュータにアプリケーション・データ・スレッドを作成する。処理はステップＳ２に進み、クライアントＡコンピュータのアプリケーション・データ・スレッドが「セットアップ」コマンドでＨＴＴＰ１．１ＧＥＴを開始し、このＧＥＴおよびセットアップ・コマンドをＷＡＮ１３２およびゲートウェイ・ファイアウォール１２２を介してゲートウェイ・コンピュータ１１２に送信する。ゲートウェイ・ファイアウォール１２２は、こうしたＧＥＴおよび「セットアップ」コマンドなどの通過を許可するように構成される。ＧＥＴおよびセットアップ・コマンドは、接続がクライアントＡファイアウォール１２４のポート８０を介して発生する持続的データ伝送に好適な、キープアライブ接続であることを要求する。
【００６３】
処理はステップＳ３に進み、ゲートウェイ・コンピュータ１１２はＧＥＴおよび「セットアップ」コマンドに応答して２つのスレッドを作成する。ゲートウェイ・コンピュータ１１２は、クライアントＡコンピュータ１１４と通信するためのクライアント・プロキシ・スレッドを作成する。ゲートウェイ・コンピュータ１１２は、サーバ・コンピュータ１１０と通信するためのサーバ・プロキシ・スレッドも作成する。ステップＳ３で、ゲートウェイ・コンピュータ１１２は、「セットアップ」コマンドでサーバ・コンピュータ１１０へのＴＣＰ接続も開始する。このＴＣＰ接続は、（ＨＴＴＰ１．１に対して）ＯＳプロトコルに従ったデータ用の持続的データ通信パスであり、それはこの転送プロトコルがサーバ・コンピュータ１１０でより適切に働くためである。
【００６４】
処理はステップＳ４に進み、ゲートウェイ・コンピュータ１１４のクライアント・プロキシ・スレッドはクライアントＡコンピュータ１１４のクライアント・アプリケーション・データ・スレッドにハンドシェイク応答を書き込んだ後、スリープになる。
【００６５】
処理はステップＳ５に進み、サーバ・コンピュータ１２６はゲートウェイ・コンピュータ１１４から「セットアップ」コマンドを備えた新しいＴＣＰ接続を受入れた後、クライアントＡコンピュータ１１４との（ゲートウェイ・コンピュータ１１２を介した）通信のためのクライアントＡ同期スレッドを作成する。サーバ・コンピュータ１１０は、各クライアントについて１つのスレッドを有することが好ましい。クライアントＡだけがコラボレーティブ・アプリケーション上で動作している場合、サーバ・コンピュータはクライアント同期スレッドを１つだけ有することができる。
【００６６】
もちろん、コラボレーティブ・アプリケーションは、複数のクライアントが同時に動作するように設計されているため、サーバ・コンピュータ１１０はしばしば複数のクライアント同期スレッドをセットアップし、これを維持する必要がある。スレッドおよび関連付けられた読取りブロック・タイプの接続手段により、サーバ・コンピュータ側の複数のクライアント同期スレッドが、サーバ・コンピュータのコンピューティング・リソースをそれほど多く使用せずに多くの当事者との通信を可能にするため、コラボレーティブ・アプリケーションはかなりスケーラブルとなる。最後にステップＳ５で、サーバ・コンピュータ１１０は、ゲートウェイ・コンピュータのサーバ・プロキシ・スレッドにハンドシェイクを書き込み返す。
【００６７】
処理はステップＳ６に進み、クライアントＡ同期スレッドがスリープに入り、他の通信およびクライアントＡコンピュータ・システムへの配布を要求するデータを待つ。クライアント同期スレッドは持続的接続のコンテキストでスリープに入ることができるため、これによってサーバ・コンピュータのコンピューティング・リソースが節約される。
【００６８】
処理はステップＳ７に進み、クライアントＡコンピュータ１１４のクライアント・アプリケーション・データ・スレッドが、ステップＳ４でゲートウェイ・コンピュータ１１２によって送信されたハンドシェイク応答を受信する。ハンドシェイク応答を受信すると、クライアントＡコンピュータ１１４は図のＳ１からの最初のＨＴＴＰ１．１ ＧＥＴを送信する際に使用したソケットの読取りをブロックする。これによって、アプリケーション・データがゲートウェイ・コンピュータ１１４から受信されない場合に、コンピューティング・リソースを節約するために、たとえクライアント・アプリケーション・データ・スレッドがスリープに入っても、ゲートウェイ・コンピュータ１１４（および最終的にはサーバ・コンピュータ１１０）とクライアントＡコンピュータ１１４との間の持続的なキープアライブ接続が可能になる。
【００６９】
処理はステップＳ８に進み、ゲートウェイ・コンピュータ１１４のサーバ・プロキシ・スレッドは、サーバ・コンピュータ１１０とのそのＴＣＰ接続の読取りをブロックする。これにより、アプリケーション・データがゲートウェイからサーバに送信されない場合に、コンピューティング・リソースを節約するために、たとえサーバ・プロキシ・スレッドがスリープに入っても、ゲートウェイ・コンピュータ１１２とサーバ・コンピュータ１１０との間の持続的ＯＳ接続が可能になる。
【００７０】
ゲートウェイに関する処理流れ
次に、ゲートウェイ・ソフトウェアの例示的な処理流れについて、図３から５に関連して論じる。この処理流れは、様々なファイアウォールを横切る様々な種類の持続的接続を維持するために本発明で使用される、「プロトコル・トンネル」（ｐｒｏｔｏｃｏｌ ｔｕｎｎｅｌｉｎｇ）と呼ばれるよく知られた処理を示すものである。ステップＳ１００では、ゲートウェイ・ソフトウェアがクライアントＡから（ＷＡＮ１３２を介して）接続およびデータを受信する。処理はステップＳ１０１に進む。
【００７１】
ステップＳ１０１では、ゲートウェイ・ソフトウェアが、クライアントＡから受信したデータ・パケットの転送プロトコルを検証する。この単純化された例では、ＨＴＴＰ１．１およびＯＳの比較的複雑な好ましい転送プロトコルを使用する代わりに、例示の目的で仮想上の転送プロトコルであるプロトコル０およびプロトコル１が使用される。本発明によれば、転送プロトコル０と転送プロトコル１の間の変換は、（１）ゲートウェイ・ソフトウェアの一方の側の構成要素が、（転送プロトコル１データではなく）転送プロトコル０データに関して持続的接続を許可するように設計されている場合、および（２）ゲートウェイ・ソフトウェアの他方の側の構成要素が、（転送プロトコル０データではなく）転送プロトコル１データに関して持続的なファイアウォール適合の接続を許可するように設計されている場合に、特に有利である。
【００７２】
図４は、転送プロトコル０に従ったデータ・パケット２００を示す図である。この例では、転送プロトコル０はゲートウェイ・コンピュータ１１２とクライアントＡコンピュータ１１４との間の通信用に使用される転送プロトコルである。転送プロトコル０データ・パケットは、値０００の３ビット・ヘッダ２０２を有することから識別可能である。転送プロトコル０は、パケットから抽出可能な実際のデータを備えたデータ部分２０４も有する。
【００７３】
この例では、ステップＳ１０１で、ゲートウェイ・ソフトウェア１５２が、ヘッダを調べて値が０００であるかどうかを判定することによって、クライアントＡから受信したデータ・パケットの転送プロトコルが転送プロトコル０であることを検証する。より複雑な転送プロトコルが使用される場合、転送プロトコルの性質に応じて、転送プロトコルを検証するための処理もさらに複雑になる可能性があるが、転送プロトコルの特徴が知られている限りは、通常の日常的スキルの範囲内となる。ステップＳ１０１では、ソースまたはルーティング情報などのデータ・パケットの他の面を調べることができる。
【００７４】
次に処理はステップＳ１０２に進み、データ・パケット２００からデータ２０４が抽出される。これは、パケットの転送プロトコルをゲートウェイ・コンピュータ１１２のサーバ側により適したものに変えるために実行されるが、実際のデータは真のままである。
【００７５】
次に処理はステップＳ１０３に進み、転送プロトコル０データ・パケットが、図５に示されるようなプロトコル１データ・パケット２０１として再フォーマットされる。さらに図５に示されるように、転送プロトコル１データ・パケット２０１は３ビット・ヘッダ２０６も有する。ただしこのヘッダは、パケット２０１を転送プロトコル１パケットとして識別するために、値００１を取る。ゲートウェイ・ソフトウェア１４２は、ステップＳ１０３で変換されたデータ・パケットにこのヘッダを追加する。データ・パケット２００からの実際のデータは、転送プロトコル１データ・パケット２０１の実際のデータ部分２０８として使用される。
【００７６】
ただしこの例では、パケット２０１のデータはデータ・パケット２００のデータと順序が逆である（図４と図５を比較）。これは、転送プロトコル０および１がそれぞれ、異なるデータ順序を偶然に指示したためである。この仮想上の例の特徴は、ゲートウェイ・ソフトウェアが、単にヘッダを変更することに加えて、実際のデータを同一に保つために他の処理を実行する必要が生じる可能性があることを示すものである。様々な転送プロトコルが、全体として、データ・パケットの構造に大きな影響を与える可能性がある。ゲートウェイ・ソフトウェア１５２は、必要なすべてのデータ・パケット構造変更の実行を処理しなければならない。
【００７７】
処理はステップＳ１０４に進み、プロトコル１データ・パケットがゲートウェイ・コンピュータ１１２からサーバ・コンピュータ１１０に送信される。これでパケットは、持続的接続によってサーバ・コンピュータ１００に送られる適切な転送プロトコル１を有することになる。
【００７８】
次に処理はステップＳ１０５に進み、ゲートウェイ・ソフトウェア１５２がサーバ・コンピュータから応答データ・パケットを受信するために、読取りをブロックする。サーバからの（ＬＡＮ１３０を介した）データがあれば、処理はステップＳ１０６に進む。
【００７９】
この例では、ステップＳ１０６で、ゲートウェイ・ソフトウェア１５２がヘッダを調べて値が００１であるかどうかを判定することによって、転送プロトコルが転送プロトコル１であることを検証する。ステップＳ１０６では、ソースまたはルーティング情報などのデータ・パケットの他の面も調べることができる。
【００８０】
次に処理はステップＳ１０７に進み、データ・パケット２０１からデータ２０８が抽出される（図５を参照）。これは、パケットの転送プロトコルをゲートウェイ・コンピュータ１１２のクライアント側により適したものに変えるために実行されるが、実際のデータは真のままである。
【００８１】
次に処理はステップＳ１０８に進み、転送プロトコル１データ・パケットが転送プロトコル０パケットとして再フォーマットされる（図４に例を図示）。ゲートウェイ・ソフトウェア１５２は、ステップＳ１０８で、新しいパケットを転送プロトコル０パケットとして識別する０００ヘッダを追加する。データ・パケット２０１からの実際のデータは、転送プロトコル０データ・パケット２００の実際のデータ部分２０６として使用されるが、（前述の理由により）データの順序は逆である。
【００８２】
処理はステップＳ１０９に進み、転送プロトコル０データ・パケットがゲートウェイ・コンピュータ１１２からクライアントＡコンピュータ１１４およびクライアントＢコンピュータ１１６に送信される。これでパケットは、クライアント・ファイアウォール１２４、１２６およびクライアント・コンピュータ１１４、１１６に適した転送プロトコル０を有するため、持続的接続によってクライアント・コンピュータ１１４、１１５に移動することができる。より具体的に言えば、パケットはクライアントに戻り、クライアントによって正しいプロトコル０応答であることが認識される。
【００８３】
前述の例示的な処理流れの実施形態は、転送プロトコル変換の概念をよりはっきりと示すために単純化されていた。転送プロトコル変換を達成するための処理は、他にも数多くある。たとえば、サーバからクライアントに進むデータは、（サーバからクライアント方向の持続的接続を維持するために）転送プロトコル変換の対象となり、クライアントからサーバに進むデータは、転送プロトコル変換または持続的接続を必要としないことができる。
【００８４】
代替実施形態
図６は、本発明によるコンピュータ・システム３００の代替実施形態を示す図である。この代替実施形態は、ゲートウェイ・ソフトウェアによって提供可能なサーバ・データのルーティングおよび多重化機能を実証するため、ならびに、異なるサーバ・コンピュータに、または異なるサーバ・コンピュータからルーティングされたデータ、あるいは同じサーバ・コンピュータにルーティングされた異なるタイプのデータが、異なる転送プロトコルに従って構成されるようにゲートウェイ・ソフトウェアが制御可能であることを実証するための、２重サーバ・コンピュータ・アーキテクチャを特徴とするものである。
【００８５】
コンピュータ・システム３００の構成要素３０６、３０８、および３３２はそれぞれ、図１の実施形態に関連して上記で論じた構成要素１０６、１０８、および１３２と同様であるため、この代替実施形態に関連しては詳細に論じない。
【００８６】
ゲートウェイ・コンピュータ３１２は、ＣＰＵ３４２およびゲートウェイ・ソフトウェア３５２を含む。ゲートウェイ・コンピュータ３１２のサーバ側には２つのサーバ・コンピュータ、サーバＡコンピュータ３１１およびサーバＢコンピュータ３１３がある。サーバＡ３１１はサーバＡのファイアウォール３２１の後方に位置する。サーバＢ３１３はサーバＢのファイアウォール３２３の後方に位置する。
【００８７】
この例示的実施形態では、サーバＡコンピュータ３１１が接続制御データを処理し、サーバＢコンピュータ３１３がデータ転送データを処理する。サーバＡコンピュータ３１１およびサーバＡファイアウォール３２１の構成方法により、接続制御データはＯＳ転送プロトコル（上記で考察）に従って最適に構成される。他方で、サーバＢコンピュータ３１３およびサーバＢファイアウォール３２３は、ロー・ソケット転送プロトコルの形のアプリケーション・データを処理するように構成される。より具体的に言えば、ロー・ソケット・データはいっさいプロトコルを持たないとみなされることがあるが、データがロー・ソケットとして配置構成されるという事実により、一般にデータがファイアウォールで処理される方法に影響を与えることになるため、本発明では、ロー・ソケット・データは転送プロトコルの１つのタイプであるとみなされる（上記の転送プロトコルの定義を参照）。おそらくロー・ソケット・データは、転送プロトコルが縮退する場合（ｄｅｇｅｎｅｒａｔｅ ｃａｓｅ）に最適であるとみなされる。
【００８８】
サーバＡファイアウォール３２１は、持続的接続を介して移動するデータがＯＳ転送プロトコルを示す限り、持続的接続を許可するように構成される。他方で、サーバＢファイアウォール３２３は、データがロー・ソケットＲＳの形式を取る限り、持続的接続がそれを通じて確立されるように構成される。
【００８９】
この実施形態には２つのサーバ・コンピュータがあるため、ゲートウェイ・ソフトウェアには、ＷＡＮ３３２から着信するデータ・パケットが、サーバＡコンピュータ３１１に送信されるための接続制御データであるか、またはサーバＢコンピュータ３１３に送信されるためのデータ転送データ・パケットであるかを、ＣＰＵ３４２が判定できるようにするコードが含まれる。ゲートウェイ・ソフトウェア３５２には、データ・パケットをルーティングするための論理が適宜含まれる。ゲートウェイ・ソフトウェアには、サーバＡコンピュータ３１１およびサーバＢコンピュータ３１３への持続的接続によって２つのサーバ同期スレッドを処理するコードが含まれる。
【００９０】
これらのパケットのルーティングに加えて、ゲートウェイ・ソフトウェア３５２は転送プロトコル変換も実行する。ただし、単にすべてのデータ・パケットをＯＳ転送プロトコル形式に変換する代わりに、ゲートウェイ・ソフトウェアは、サーバＡコンピュータ３１１に向かうデータ・パケットを、ＨＴＴＰ１．１転送プロトコルからＯＳ転送プロトコルに変換し、その結果、これらのパケットはサーバＡファイアウォール３２１で持続的接続を通過することができる。他方で、ゲートウェイ・ソフトウェア３５２は、サーバＢコンピュータ３１３に向かうデータ・パケットを、ＨＴＴＰ１．１転送プロトコルからロー・ソケットに変換し、その結果、このデータはサーバＢファイアウォール３２３で持続的接続を通過することができる。これら２つの持続的およびステートフルな接続により、サーバが複数のクライアント・スレッドを確立し、多くの異なるコラボレータからのデータの間欠的受信を効率良く処理できるようにする。
【００９１】
もちろん、現在または将来、他の転送プロトコルも使用可能である。本発明のいくつかの実施形態に好ましい転送プロトコルの１つが、ＪＡＶＡオブジェクト・シリアル化である。他の好ましい転送プロトコルは、Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＣＯＲＢＡ）のプロトコル・ファミリーにある。将来は、他のタイプのプロトコルおよびおそらく新しい階層のプロトコルも開発され、これがファイアウォールの将来のデータ処理方法に影響を与える可能性があると予想される。これは実際には、将来新しい転送プロトコルが登場することを意味する。ただしそれでも、コンピュータ・ネットワークの一部で持続的なファイアウォールに適合する接続を確立するために１つのタイプの転送プロトコルが使用可能であり、コンピュータ・システムの異なる部分で持続的なファイアウォールに適合する接続を確立するために別の転送プロトコルが使用可能である場合に、本発明は有用であると考えられる。
【００９２】
以上説明したコンピュータ・システムには多くの変形形態が可能である。こうした変形形態は、本発明の精神および範囲から逸脱するものとはみなされず、むしろ、該当する法律によって許可される最大の範囲内で、添付の特許請求の範囲内に含まれることを意図する修正であるとみなされる。
【図面の簡単な説明】
【図１】
本発明によるコンピュータ・システムの第１の実施形態を示す構成図である。
【図２】
本発明による持続的接続を確立するための例示的な処理流れを示す流れ図である。
【図３】
本発明によるゲートウェイ・ソフトウェアの例示的な処理流れを示す流れ図である。
【図４】
例示的な転送プロトコル０データ・パケットを示す図である。
【図５】
例示的な転送プロトコル１データ・パケットを示す図である。
【図６】
本発明によるコンピュータ・システムの第２の実施形態を示す構成図である。

Claims (18)

1. 第１のコンピュータ・ネットワークと、
   コンピュータ・ネットワークを介してアプリケーション出力データを送信するためのマシン読取り可能命令を含むコラボレーティブ・アプリケーション・ソフトウェアを備えた第１のコンピュータ・サブシステムと、
   アプリケーション出力データを受信するように構成された第２のコンピュータ・サブシステムと、
   第２のアプリケーション・サブシステムの前方に配置され、コラボレーション実施中はオープンになっているハイパーテキスト転送プロトコルのキープアライブ接続を介して、アプリケーション出力データを第２のコンピュータ・サブシステムに送るように構成された、第２のサブシステム・ファイアウォールと、
   を含むコンピュータ・システム。
2. コンピュータ・システムが、アプリケーション出力データを受信するために第２のコンピュータ・サブシステムの第１のサブシステム・スレッドをオープンにしておくためのマシン読取り可能命令を含む通信ソフトウェアをさらに含む、請求項１に記載のコンピュータ・システム。
3. 第２のコンピュータ・サブシステムが、アプリケーション出力データを受信するように構成された第２のサブシステム・ソケットを含み、
   通信ソフトウェアが、第２のサブシステム・ソケットに読取りをブロックさせるためのマシン読取り可能命令をさらに含む、請求項２に記載のコンピュータ・システム。
4. 通信ソフトウェアが、第１のサブシステム・スレッドをスリープにさせる命令をさらに含む、請求項３に記載のシステム。
5. コラボレーティブ・アプリケーション・ソフトウェアが、アプリケーション出力データをステートフル通信として送信する、請求項１に記載のシステム。
6. アプリケーション出力データがＨＴＴＰ１．１プロトコルに従って構成および配置される、請求項５に記載のシステム。
7. 第２のサブシステム・ファイアウォールがポート８０を含み、
   アプリケーション出力データが、第２のサブシステム・ファイアウォールを横切り、ポート８０を介して生じる接続を通じて送られる、請求項６に記載のシステム。
8. 第１のコンピュータ・サブシステムが、
   サーバ・コンピュータと、
   Ｗｅｂサーバ・コンピュータと、
   サーバ・コンピュータとＷｅｂサーバ・コンピュータとの間のデータ通信を可能にするように構成された第２のコンピュータ・ネットワークとを含む、請求項１に記載のシステム。
9. サーバ・コンピュータがコラボレーティブ・アプリケーション・ソフトウェアの少なくとも一部を含み、
   Ｗｅｂサーバ・コンピュータが、第２のコンピュータ・ネットワークを介してサーバ・コンピュータからのアプリケーション出力データを受信し、第１のコンピュータ・ネットワークを介して第２のコンピュータ・サブシステムへアプリケーション出力データを送信するように構成される、請求項８に記載のシステム。
10. Ｗｅｂサーバ・コンピュータが、第２のコンピュータ・ネットワークを介してサーバ・コンピュータからのアプリケーション出力データを受信するように構成されたＷｅｂサーバ・ソケットを含み、
    通信ソフトウェアが、Ｗｅｂサーバ・ソケットに読取りをブロックさせるためのマシン読取り可能命令をさらに含む、請求項９に記載のシステム。
11. アプリケーション出力データを受信するように構成された第３のコンピュータ・サブシステムと、
    第３のコンピュータ・サブシステムの前方に配置され、ハイパーテキスト転送プロトコルのキープアライブ接続を介して、アプリケーション出力データを第３のコンピュータ・サブシステムに送るように構成された、第３のサブシステム・ファイアウォールとをさらに含む、請求項１に記載のシステム。
12. 第３のコンピュータ・サブシステムが、アプリケーション出力データを受信するように構成された第３のサブシステム・ソケットを含み、
    通信ソフトウェアが、第３のサブシステム・ソケットに読取りをブロックさせるためのマシン読取り可能命令をさらに含む、請求項１１に記載のコンピュータ・システム。
13. 第１のコンピュータ・サブシステムと、第２のコンピュータ・サブシステムと、第３のコンピュータ・サブシステムとの間の通信がリアルタイムである、請求項１１に記載のシステム。
14. コラボレーティブ・アプリケーション・ソフトウェアが、ワード・プロセッサ、タスク・スケジューリング・ツール、グラフィックス・プログラム、プレゼンテーション・プログラム、スプレッドシート、ゲーム、音楽スタジオのうち、少なくとも１つの機能を含む、請求項１１に記載のシステム。
15. コンピュータ・ネットワークを介して通信する方法であって、
    サーバ・コンピュータ上に常駐するコラボレーティブ・アプリケーション・ソフトウェアによって、アプリケーション出力通信を生成するステップと、
    第１のコンピュータ・ネットワークを介して、アプリケーション出力通信をクライアント・ファイアウォールに送信するステップと、
    アプリケーション出力通信を、クライアント・ファイアウォールを横切って、ハイパーテキスト転送プロトコルのキープアライブ接続を介して送るステップと、
    クライアント・コンピュータでアプリケーション出力データを受信するステップと、
    コラボレーション実施中は、ハイパーテキスト転送プロトコルのキープアライブ接続を維持するステップと、
    を含む方法。
16. クライアント・コンピュータが、アプリケーション出力データを待って受信する場合に読取りをブロックする、請求項１５に記載の方法。
17. クライアント・ファイアウォールを横切り、クライアント・ファイアウォールのポート８０を介した接続を生じさせるステップをさらに含む、請求項１５に記載の方法。
18. アプリケーション出力データが、送信ステップでＨＴＴＰ１．１に従って構成および配置された複数のデータ・パケットとして送信される、請求項１５に記載の方法。

Images