JP2001325163A - 安全なネットワーク環境でデータを転送するシステム - Google Patents

Abstract

(57)【要約】 【課題】 エージェント２２、８２とコンソール２４、
７２の間の安全でないパス３８、８４を介して、データ
を安全に通信するネットワーク通信システム２０を提供
する。 【解決手段】 エージェント８２は安全なネットワーク
・セグメント７６の中にあり、コンソール７２はＬＡＮ
７０の別の場所のネットワーク・セグメント７４の中に
ある。エージェント２２が安全なＬＡＮ２８の中にあ
り、コンソール２４がＬＡＮ３４の中でもよい。インタ
ーネット２６などの広域ネットワークであるパス３８を
伴う。データは、電子メール、ＦＴＰ、ＨＴＴＰまたは
ＶＰＮなどのトネリング・プロトコル、またはプロプラ
エタリ・プロトコルを使用する種々の方法で通信でき
る。慣例として割り当てられたポートを静的またはダイ
ナミックに使用する場合もあり、またはネットワーク通
信システム２０がプログラムによって開いたポートを見
つける場合もある。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般に、電子コンピ
ュータおよびディジタル処理システムの動作に関し、よ
り詳細には、安全ではないネットワーク・セグメントを
使用するこのようなシステム内で安全に通信するための
プロセスおよび装置に関する。

【０００２】

【従来の技術】コンピュータ・システムでの通信は困っ
た問題であり、特にこのようなコンピュータ・システム
がネットワークに接続され、さらに、このようなネット
ワークの一部のセグメントが本質的に安全ではない場合
には困った問題である。最近、パーソナル・コンピュー
タおよび組織のコンピュータのシステムをインターネッ
トに接続することが成長しており、このことをよく示し
ている。インターネットは本質的に安全ではなく、少な
くとも、今日これを一般的に使用している個人および組
織にとっては安全ではない。それにもかかわらず、イン
ターネットのような大きなネットワークを介したデータ
の転送はますます望ましくなっており、場合によっては
必要とさえ見なされている。したがって今日、このよう
なネットワーク内でデータを転送するアーキテクチャを
開発し向上させることが非常に必要とされている。

【０００３】セキュリティの増大という利点を得るため
には、ほとんど常に犠牲を払わなければならず、通常は
一部の自由をあきらめるという形で犠牲を払う。コンピ
ュータおよびネットワークのコンテキストでは、この犠
牲を払ってセキュリティという利益を得る手法は、さも
なければ有効である目的を妨害することがあり得るセキ
ュリティのために不信用および過度に煩わしい保護とい
う諸要素を許容することを意味する。

【０００４】今日これが見られる１つの例は遠隔コンピ
ュータ・システムおよびネットワーク管理である。他に
も多くの可能性のある例があるが、このような管理は通
常、このようなシステムのもっとも攻撃されやすいレベ
ルにアクセスすることを必要とするので、この例は特に
役に立つ例である。

【０００５】図１（背景技術）は、このような遠隔コン
ピュータ・システムおよびネットワーク管理のために現
在使用されている従来のシステム１を描いた概略図であ
る。エージェント２は遠隔ローカル・エリア・ネットワ
ーク（ＬＡＮ３）の中に置かれている。このエージェン
ト２および従来のシステム１内で他の場所にあるコンソ
ール４は、広域ネットワーク（ＷＡＮ５）を介して通信
できることが望ましい。広域ネットワークは典型的には
インターネットである。ＬＡＮ３はゲートウェイ６を介
してＷＡＮ５に接続している。示されたように、コンソ
ール４は異なるＬＡＮ７に位置し、そのＬＡＮのゲート
ウェイ８を介して到達できるコンピュータ・システムで
ある。エージェント２とコンソール４の間の通信のため
のパス９も示されている。

【０００６】エージェント２は通常はＬＡＮ３の中に置
かれが、ＬＡＮ３の中に置かれることが必ずしも必要で
ない。エージェント２は、これが報告すべき、またはＬ
ＡＮ３の間でアクティビティを監視するハードウェアの
特定の一部またはサブ・システム上で実行するようにな
っていてもよい。このスキームが使用される典型的なシ
ナリオは、性能およびセキュリティの監視の中である。
たとえば、エージェント２は、ＬＡＮ３内の特定のコン
ピュータ・システムまたはデバイスが故障した理由を診
断するために使用される場合がある。別法としては、エ
ージェント２は、ＬＡＮ３内に常駐する重要なデータベ
ースへのアクセスを監視するために使用される場合もあ
る。

【０００７】このようなエージェント２の種々の使用方
法は非常に多いので、おそらくここに一覧できない。ま
た、読者は上記に使用された遠隔コンピュータ・システ
ムおよびネットワーク管理の例に限定されると考えるべ
きではない。そのかわりにここで理解されるべき顕著な
ポイントは、このようなエージェント２は典型的には、
開始、停止、再タスクしたりできなければならず、また
エージェント２が発見したことを通信できる必要がある
ことである。ここではコンソール４である遠隔エンティ
ティを使用する時に、これらの動作は必ず、ＷＡＮ５な
どの安全ではない媒体を介した、ＬＡＮ３の外部の通信
を必要とする。

【０００８】この従来のシステム１が抱える問題は、エ
ージェント２およびコンソール４の通信を許可し、同時
にＬＡＮ３内のセキュリティを維持する方法である。セ
キュリティの心配は、簡単に言えば、プライバシを維持
し、（悪意のまたは単に許可されない）妨害を防ぐこと
と分類できる。たとえば、他人の手に渡さないことが望
ましい、特別に許可された情報がＬＡＮ３内に存在する
場合がある。ＬＡＮ３内の情報の統合性およびその動作
自体も、外部の妨害によって混乱されないようにしなけ
ればならない。

【０００９】ＬＡＮ３のセキュリティが適切に維持され
ていない場合、エージェント２自体さえも不正な目的の
道具として使用される可能性がある。エージェント２の
１つまたは多数のインスタンスが不適切に開始され、Ｌ
ＡＮ３の性能を低下させる可能性がある。または、エー
ジェント２が再タスクされ、特別に許可された情報を嗅
ぎ出し、それをＬＡＮ３の外部に通信する可能性があ
る。エージェント２の特に強力なインスタンスまたはま
ずく設計されたインスタンスは、ＬＡＮ３内の記憶場所
に存在するか転送中である重要な情報を変更する可能性
もある。

【００１０】明らかに、ＬＡＮ３とＷＡＮ５の間のすべ
ての接続を切断することは１つの解決法である。しか
し、インターネットなどのＷＡＮが急速に発展している
ように、ますます「接続度を増している」通信環境で
は、外部の接続を避けることはますます受け入れ難い選
択肢である。たとえば、エージェント２およびコンソー
ル４が性能またはセキュリティ監視のために使用され、
これらが通信するパス９は必ずＷＡＮ５などの安全では
ない媒体を通過する必要がある可能性がある。組織が多
くの別の場所に拡大したり、通信媒体のグローバリゼー
ションが次第に進むと、エージェント２およびコンソー
ル４などのエンティティは同じ組織によって所有され、
全く同じ人々によって制御されるが、物理的には全く離
れた場所にある場合もある。または、組織の中心的でな
いサービスをアウトソーシングすることが次第に広まる
につれて、エージェント２がクライアントの場所にあり
コンソール４が遠隔のサービス・プロバイダの場所にあ
るという可能性もある。

【００１１】次に図２（背景技術）を参照すると、接続
の分断の選択的な形が描かれ、これは実際には今日使用
されているもっとも普通のセキュリティ技法である。図
２のスキームは特に、ファイアウォール１０が追加さ
れ、ＬＡＮ３を安全なＬＡＮ１１にしている点で図１と
は異なる。ファイアウォールはもっとも広く使用されて
いるＷＡＮおよびインターネットのセキュリティ・メカ
ニズムであって、イントラネット（たとえば安全なＬＡ
Ｎ１１）とＷＡＮまたはインターネット（たとえばＷＡ
Ｎ５）の間のゲートウェイにあるハードウェアおよびソ
フトウェアの組合せを使用している。これらはイントラ
ネット内の人々およびシステムがイントラネットを使用
し、通常はＷＡＮまたはインターネットも使用するが、
その他の場所からイントラネット内の一部またはすべて
にアクセスしようとする人々およびシステムを阻止す
る。典型的には、コンソールもファイアウォールを有す
るが、本議論には関係がない。また、ここではファイア
ウォールは強調のために別に描かれているが、ゲートウ
ェイとして使用される同じハードウェア内に統合される
ことも多い。

【００１２】ファイアウオールはそのもっとも簡単な形
態では、ソース・アドレスおよび宛先アドレスに基づい
てデータ・パケットの移動をフィルタリングすることに
よって動作する。より複雑な形態では他のユーザ指定の
基準に基づいてフィルタリングする場合もある。たとえ
ば、図２の中のファイアウォール１０は、ＬＡＮ７内で
発生したと識別されるデータ・パケットを安全なＬＡＮ
１１の中へ通過させるように構成されている場合があ
る。これは、パケットがＬＡＮ７の中で発生している場
合は機能するが、データ・パケットがＬＡＮ７内で発生
したと間違えて識別された場合はどうなるだろうか。デ
ータ・パケットの基本的なソース・アドレス指定である
故意の間違いであるスプーフィングは、ファイアウォー
ルのセキュリティが破られる１つの方法である。

【００１３】また、ファイアウォールはデータ・パケッ
トの宛先アドレスに基づいてデータ・パケットをフィル
タリングするように構成されていることも多い。したが
って、安全なＬＡＮ１１内のアドレスを外からアドレス
指定する有効な目的がない場合、このようなアドレスに
向けられた任意のデータ・パケットは簡単にブロックで
きる。しかし、たとえばコンソール４によって外部アク
セスのために新しく作成された有効な目的などによっ
て、エージェント２のインスタンスが特定のブロックさ
れたイントラネット・アドレスにおけるデバイス上で実
行される必要がある場合にこれは問題になる。結局、コ
ンピュータ・システムの主な用途の１つは、これらが新
しいタスクにダイナミックに適用されることである。

【００１４】現在使用されている洗練の次のレベルは、
ファイアウォール１０が安全なＬＡＮ１１内のアドレス
において所定のポートに向けられた外部データ・パケッ
トのみを通過するように構成することである。ポートと
は、データが出入りする番号付きのアクセス・ポイント
であり、物理的な接続ではない。１０２４以下のポート
番号が一般に指定されるか、非公共用途およびサービス
へのアクセスを提供する。しかし１０２４〜６５５３５
の間のポートはプライベートとは考えられず、一般に使
用可能である。したがって、ファイアウォール１０は特
定のシステム上で入力データ・パケットをポート番号２
３に渡すように構成され、たとえば、安全なＬＡＮ１１
内のそのシステムへテレネット・タイプの遠隔アクセス
を可能にする場合がある。

【００１５】しかし、今日では、この形の静的なフィル
タリングでさえも洗練が不十分で適切なセキュリティを
提供しない。特定のターゲット・アドレスにおいてすべ
てのポートを反復してポールし、現在開いているポート
を決定することのできるポート検知（port sniffing）
ユーティリティが幅広く使用されている。開いているポ
ートが見つかると、そのようなポートが入口となってい
る動作を実行するデータ・パケットを送ることができ
る。または、その入口で内部的な保護を通過できないデ
ータ・パケットでポートがあふれてしまう場合もある。
たとえば、テレネット・アクセスはほとんど常に、テレ
ネット・パスワードを必要とするように構成されてい
る。このようなポートは異なるパスワードを試みる繰り
返されたログイン要求であふれてしまうか、または単に
データ・パケットであふれてしまってシステムに負担に
なるかまたはシステムを止めてしまい（「サービス開始
の否定」と呼ばれることも多い）、したがって、有効な
データ・パケットへのアクセスを拒否するかまたはシス
テムの性能を低下させる場合もある。

【００１６】さらに洗練された手法はダイナミックフィ
ルタリングであり、ファイアウォール１０は必要とされ
るポートを知ってこれらを開き、一方他のポートをすべ
て閉じることによって、データ・パケット・トラフィッ
クのニーズに適用される。ファイアウォール１０はポー
トを開く要求を監視し、正当な通信セッションが必要と
される時、そのセッションの長さの間、必要とされるだ
けこれらのポートを開く。ここで、あるポートを介した
トラフィックのボリュームが過剰になった場合、たとえ
ばポートが検知されてそれをスワンプする試みが行われ
た場合、ポートを閉じることによってさらなる洗練が適
用できる。

【００１７】前述の論議はすべてのファイアウォール・
セキュリティ機能を網羅したものではない。実際にはフ
ァイアウォール機能は不断に洗練され新しいファイアウ
ォールが作成されているので、網羅することは可能では
ない。ここでの議論は主な問題の枠組みを決める役割を
果たすのみである。安全なＬＡＮ１１内で外部システム
に届くポートが開かれていない時に、コンソール４のよ
うな外部システムがエージェント２と通信ダイアログを
開始するにはどうしたらいいのか。図２はエージェント
２への要求を行っているが、ファイアウォール１０によ
ってアクセスを阻止されているコンソール４を説明する
波線のパス１２をも含んでいる。

【００１８】今日、ファイアウォールのユーザは多くお
り、大きな企業ユーザおよび急速に増大する、ディジタ
ル加入者線（ＤＳＬ）およびケーブル・モデム・アクセ
スを使用してＷＡＮまたはインターネットに接続してい
る家庭または小さなオフィスのユーザが含まれている。
大部分、これらのユーザは、これらのポートのすべてで
はなくてもほとんどを、侵入を防ぐために外部者に対し
て閉じるように「構成」している。単に人間的な惰性お
よびしばしばファイアウォールを正しく構成することの
大変な複雑さは、ファイアウォールの構成または再構成
を必要とする可能性のあるなにかを実装または変更する
強力な阻害要因を提供することによって、問題を悪化さ
せている。

【００１９】より小さな、より洗練されていないユーザ
または組織においては、ＤＳＬおよびケーブル・モデム
・アクセスのために使用されている、普通になった簡単
なファイアウォールの多くには、高度に前設定されたセ
キュリティがデフォルトとして付属しているので、設定
は意識的に考え抜かれていない場合が多い。また、意思
決定がさらに中心化され急速になり、外部のネットワー
ク・プロフェッショナルを招き入れるコスト、または自
分で学んでそこでファイアウォールの構成の変更を実装
するコストは深刻な阻害要因となり、コンピュータ・シ
ステムのダイナミックな使用を下げるかまたは、ネット
ワーク・セキュリティを故意に回避する動機になる場合
もある。

【００２０】しばしばより洗練されている大きな組織の
場合には、設定および変更はより一般的に選択肢となる
が、典型的にはフレキシブルでない方針によってやはり
重荷となっている。このような組織では、１つの目的の
ために変更と広範囲な効果を有する場合があるので、フ
ァイアウォール構成の変更を得るためには検討と承認が
必要である場合がある。構成の変更が適切であると一度
決定されても、そうでなくても忙しいネットワークのプ
ロが変更を実装するように仕事を課され、かなり時間を
とる可能性がある。

【００２１】したがって、今日必要とされているのは、
ネットワークの安全なセグメントと安全でないセグメン
トの中のエンティティの間でデータを通信するための向
上したアーキテクチャである。

【００２２】

【発明が解決しようとする課題】したがって、本発明の
目的は、ネットワークの安全なセグメントの中にあるエ
ンティティと安全でないセグメントの中にあるエンティ
ティの間でデータを通信するための、改良されたアーキ
テクチャを提供することである。

【００２３】本発明の別の目的は、ネットワークの安全
なセグメント内のセキュリティを犠牲にしないアーキテ
クチャを提供することである。

【００２４】本発明の別の目的は、最初に実装するため
に洗練されたネットワークのプロなど貴重な人材のかか
わり合いを過度に必要としないアーキテクチャを提供す
ることである。

【００２５】本発明の別の目的は、このアーキテクチャ
を使用したエージェントをダイナミックに追加、再構成
または再タスク、または削除するために、継続的にネッ
トワークのプロを雇用するかかわり合いを過度に必要と
しないアーキテクチャを提供することである。

【００２６】

【課題を解決するための手段】簡単に言えば、本発明の
好ましい実施態様は、ネットワーク内における通信のた
めの方法である。この方法は、セキュリティ・システム
によって保護されているネットワークの第１のセグメン
ト内にエージェントを置くステップを含む。メッセージ
・データはついでそのエージェントによって第１のネッ
トワーク・セグメント内で収集される。次に、通信はそ
のエージェントによって開始される。最後に、エージェ
ントはネットワークの第１のセグメントの外でメッセー
ジ・データを、ネットワークの第２のセグメント内のコ
ンソール・ユニットに通信して、コンソール・ユニット
またはネットワークの第１のセグメントの外部の任意の
場所から要求する状況がセキュリティ・システムによっ
て妨げられることを防ぐ。

【００２７】簡単に言えば、本発明の別の好ましい実施
態様は、メッセージ・データを安全に通信するためのシ
ステムである。セキュリティ・システムによって保護さ
れ、エージェントを含んでいる、ネットワークの第１の
セグメントが提供される。コンソール・ユニットを含む
ネットワークの第２のセグメントが提供される。エージ
ェントは、エージェント自体とコンソール・ユニットの
間で通信を開始する論理を含む。エージェントはさら
に、メッセージ・データがネットワークの第１のセグメ
ントから第２のセグメントへ外へ向かって進行し、これ
によってセキュリティ・システムから妨害されないよう
に、メッセージ・データをコンソール・ユニットに通信
する論理を含む。

【００２８】本発明の利点は、ネットワークの安全なセ
グメントの中にあるエンティティと安全でないセグメン
トの中にあるエンティティの間で通信するための改良さ
れたアーキテクチャを効果的に提供することにある。

【００２９】本発明の別の利点は、本発明が提供するア
ーキテクチャが経済的であることである。これは本質的
にコンピュータ・ソフトウェア内だけで、わずかな資本
投資しか必要としないように具体化することもできる。
また、最初の実装のため、または一度使用された後の維
持のために、高価なネットワークのプロのかかわり合い
をほとんど要求しない方法で具体化することもできる。

【００３０】本発明の別の利点は、ファイアウォールな
どのネットワーク・セキュリティ機能の再構成を要求し
ないことである。本発明の最初の実装は、セキュリティ
の効果に関して本質的にわずかな検討しか必要とせず、
この発明のアーキテクチャが使用されると、このような
セキュリティ検討の必要性は本質的に除去される。特
に、一度設定されると、セキュリティ問題が存在する場
合には通常必要とされるしばしば困った検討および許可
の手順なく、アーキテクチャの大きな変更を安全で確実
に行うことが可能である。

【００３１】本発明の別の利点は、安全なネットワーク
・セグメントのセキュリティをむしばむ誘因を提供しな
いことである。本発明のアーキテクチャのユーザは、自
分の仕事を実行するためにセキュリティを回避する必要
はない。遅延の原因および組織の方針の問題としてのセ
キュリティの検討および許可は、本質的に除去される。
ネットワークのプロがほとんど必要とされないため、セ
キュリティを維持するためのコスト上の阻害要因も最小
化され、遅延はさらに縮小される。

【００３２】本発明のこれらの目的および利点、他の目
的および利点はここに説明され、また図面のいくつかの
図に示されたような、本発明を実行する現在知られた最
良の実施例としての説明と、好ましい実施形態の産業上
の適用可能性を考慮すると、当業者に明らかになるであ
ろう。

【００３３】本発明の目的および利点は次の詳細な説明
と付随する図面から明らかになる。

【００３４】

【発明の実施の形態】本発明の好ましい実施形態はネッ
トワーク通信システムである。本明細書の種々の図面、
特に図３の図面に示されたように、本発明のデバイスの
好ましい実施形態は一般的な参照文字１０によって描か
れている。

【００３５】図３は、実施形態のネットワーク通信シス
テム２０を描く概念図であり、この中でエージェント２
２およびコンソール２４はインターネット２６（または
別のタイプのＷＡＮ）など安全でない媒体を介して通信
することができる。

【００３６】エージェント２２は安全なローカル・エリ
ア・ネットワーク（安全なＬＡＮ２８）の中にあり、安
全なローカル・エリア・ネットワークはファイアウォー
ル３０およびゲートウェイ３２を介してインターネット
２６に接続している。エージェント２２は開始および終
了できる１つまたは複数のアプリケーションで、特に一
定のタイプのデータをコンソール２４に通信する必要が
ある。ファイアウォール３０およびゲートウェイ３２は
図３では異なるものとして描かれているが、多くの実装
の中で、これらはハードウェアの１つの物理的な部品内
に統合できる。

【００３７】コンソール２４は第２のローカル・エリア
・ネットワーク（ＬＡＮ３４）の中にある。第２のロー
カル・エリア・ネットワークはここではゲートウェイ３
６を介してインターネット２６に接続している。理論的
には、ゲートウェイ３６はコンソール２４に物理的に統
合され、ＬＡＮ３４は簡単に省略することもできる。し
かしこのような簡単な実装が典型的な場合であることは
まれである。

【００３８】エージェント２２、安全なＬＡＮ２８、フ
ァイアウォール３０、ゲートウェイ３２、インターネッ
ト２６、ゲートウェイ３６、ＬＡＮ３４およびコンソー
ル２４はこのように完全な通信パスを形成し、これは図
３の中で形態上、パス３８として示されている。

【００３９】ファイアウォール３０は安全なＬＡＮ２８
を保護するものなので、この中で特に注目される。ファ
イアウォール３０は、有効なセキュリティの役割を実行
する際にコンソール２４とエージェント２２の間でいく
らか通信の妨害となる可能性がある。前に背景技術セク
ションで説明したように、直接安全なＬＡＮ２８の外側
のコンソールで発した通信は非常に疑わしい。このよう
な通信がここで許可されても、ファイアウォール３０は
かなりの複雑さを実行して、本当に外部のコンソール２
４で発した有効な通信のみを通過させる必要がある。さ
らに、今日の規準によってすべての可能な複雑さがファ
イアウォール３０によって使用されているとしても、明
日の新しい形の脅威に向かうためにさらに複雑さが必要
とされないという保証はない。したがって、コンソール
２４で発する通信は疑わしいのみでなく、好ましくな
い。したがって、本ネットワーク通信システム２０はこ
れらを最小限に押さえ、場合によっては、これらの使用
を完全に除去できる。

【００４０】ネットワーク通信システム２０は１つの非
常に重要な点で従来技術のシステムとは異なって動作す
る。それは、コンソール２４がエージェント２２（また
は安全なＬＡＮ２８内のエンティティ）と通信を開始し
ないということである。通信が要求された時、これを決
定し開始するのはエージェント２２である。エージェン
ト２２は連続的に実行できるか、安全なＬＡＮ２８の別
の場所にあるデバイスまたはシステムによって要求を起
動するなど、イベントに応答して開始することができ
る。このような起動要求は、エージェント２２が最後に
停止してから、特定の時間の到来まで、または安全なＬ
ＡＮ２８内のハードウェアまたはシステムの一部の項目
の障害または異常動作までの時間の経過に応答する場合
がある。この起動の一覧表は網羅的なものではないこと
に注意されたい。本発明の真の精神は、なにが使用を起
動するかではなく、本発明が一度起動されたらどのよう
な方法で実行するかにある。

【００４１】安全なＬＡＮ２８はインターネット２６に
接続されているので、安全なＬＡＮ２８へ入力する通信
がファイアウォール３０によって絶対的に拒否されて
も、出力する通信の一部の形態が安全なＬＡＮ２８から
起きることが可能でなければならない。さもなければ、
安全なＬＡＮ２８をインターネット２６に接続させる意
味がない。したがって、ファイアウォール３０は外部の
電子メールまたはウェブ・サイト・アクセスを許可でき
る。すなわち、一般的に安全に許可できる最小の外部サ
ービスを許可するか、または特定のポートを静的な方法
で開いたままにしておく場合もある。しかし、これらす
べてが禁じられている場合でも、ファイアウォール３０
は内部の要求に応じてポートをダイナミックに開くよう
に構成される可能性がある。ファイアウォール３０はエ
ージェント２２から時々出力するデータ・バーストのた
めにポートを一時的に開くことを許可するように構成さ
れる場合もあり、または、エージェント２２がコンソー
ル２４とのトネリング・リンクを開始し、暗号化または
他の方法を使用してエージェント２２およびコンソール
２４のみが確立されたリンクを介して互いに通信できる
ように許可する場合もある。

【００４２】本発明のネットワーク通信システム２０が
動作する方法の一部の特定の例をさらに詳細に論じる前
に、これは一部のローカル・エリア・ネットワーク（Ｌ
ＡＮ）コンテキスト内でも使用できることに注意された
い。図４から図６はこれを示している。

【００４３】図４（背景技術）は、ローカル・エリア・
ネットワーク（ＬＡＮ）内で時々使用される従来のシス
テム５１を描いた概念図である。コンソール５２は最終
的なデータ受信側であり、第１のネットワーク・セグメ
ント５３の中に存在する。第１のネットワーク・セグメ
ント５３はルータ５５を介して第２のネットワーク・セ
グメント５４に接続されている。エージェント５６は最
終的なデータの提供側であり、第２のネットワーク・セ
グメント５４の中に設けられている。したがって、パス
５７はコンソール５２とエージェント５６の間にある。
この従来のスキームでは、コンソール５２はデータを要
求でき、エージェント５６はパス５７上でデータを提供
できる。

【００４４】図５（背景技術）は、図４の従来のシステ
ム５１に伴う問題を描いた概念図である。ファイアウォ
ール５８が追加され、第２のネットワーク・セグメント
５４を安全なセグメント５９にしている。

【００４５】たとえば、第１のネットワーク・セグメン
ト５３は管理情報サービス（ＭＩＳ）部に関し、安全な
セグメント５９は、人事部（ＨＲ）に関する場合があ
る。ＨＲ部は典型的には給与のリストなどの微妙なデー
タを有するのでファイアウォール５８を有し、全ＬＡＮ
の他の場所からの侵入を防ぐ。

【００４６】しかし図５の従来のシステム５１に伴う問
題は、図２（背景技術）の従来のシステム１に伴う問題
と同じままで残る。ファイアウォール５８が追加された
ので、図４の便利なパス５７ではなくコンソール５２と
エージェント５６の間には不完全なパス６０しか許可で
きず、コンソールからエージェントへの通信は発生でき
ない。

【００４７】図６はローカル・エリア・ネットワーク
（ＬＡＮ７０）内で使用されるネットワーク通信システ
ム２０を描いた概念図であり、すなわち、本発明によっ
て図５の従来のシステム５１を変更したものである。コ
ンソール７２はネットワーク・セグメント７４上に存在
する。ネットワーク・セグメント７４は、ルータ７８を
介して安全なネットワーク・セグメント７６および、安
全なネットワーク・セグメント７６を保護するファイア
ウォール８０に接続されている。エージェント８２は、
安全なネットワーク・セグメント７６の中に存在し、本
発明の特徴的な方法は、ＬＡＮ７０を介してパス８４を
介してコンソール７２との通信を開始できることであ
る。

【００４８】図６に描かれたネットワーク通信システム
２０の実施形態の中では、図３の実施形態に関してと同
じように、データはエージェント８２とコンソール７２
の間で多くの方法で通信できる。限定なしに、これらは
従来の電子メールのバージョン、ファイル転送プロトコ
ル（ＦＴＰ）、トネリング・プロトコル、プロプラエタ
リ・プロトコル、これらの組合せ、および慣例に従わな
いポートまたはダイナミックな開いたポートの検索の使
用を含む。議論は次に、本発明のネットワーク通信シス
テム２０内で使用されるいくつかの具体的な、可能性の
ある例に移る。

【００４９】図７は、電子メールおよびネットワーク通
信システム２０を使用したデータ送信側のプロセスの流
れ１１０を描いたフロー・チャートであり、同時に図３
も参照されたい。

【００５０】ステップ１１２では、スケジュール・サブ
・プロセスが実行され、ネットワーク通信システム２０
はエージェント２２に対して、コンソール２４へ向けて
データを送信するべき時を指定する。ステップ１１４で
は、送信されるべきデータが準備される。これは暗号化
またはフォーマット化を含む場合もあるか、またはオプ
ションであってこのステップは簡単に省略される場合も
ある。ステップ１１６では、データはエージェント２２
によって「送信される」。ステップ１１２、１１４、１
１６は、ここでは機能面を強調するために別に表されて
いることに注意されたい。当業者であれば、ネットワー
ク通信システム２０の実際の実施形態内で多かれ少なか
れこれらを統合できることが理解されるであろう。

【００５１】ステップ１１６の後、電子メール・メッセ
ージとして送信されるべきデータは、典型的には従来の
電子メール・クライアントに渡され、従来の電子メール
・サーバを介して送信されるが、これは必ずしも必要で
はない。ネットワーク通信システム２０の実装は簡単
に、既存の通信サブ・プロセスが存在する場合はそれを
使用し（たとえば、ＵＮＩＸ（登録商標）、Ｌｉｎｕ
ｘ、Ｍｉｃｒｏｓｏｆｔおよび他のＯＳに関して使用可
能な、広く使用されているＯｕｔｌｏｏｋ（ＴＭ）また
はＯｕｔｌｏｏｋ Ｅｘｐｒｅｓｓ（ＴＭ）ｃｌｉｅｎ
ｔｓ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ Ｓｅｒ
ｖｅｒ（ＴＭ）、ＵＮＩＸの「ｓｅｎｄｍａｉｌ」）ま
たは、ネットワーク通信システム２０はこれらの従来の
バージョンをそれが使用するために提供することができ
る。別法としては、プロプラエタリ電子メールシステム
でも使用できる。

【００５２】ステップ１１８では、電子メール・メッセ
ージは電子メール・クライアント・サブプロセスによっ
てエージェント２２から公式に送信される。ステップ１
１２〜１１８は典型的には同じコンピュータ・システム
内で実行されるが、これもまた必ずしも必要ではない。
たとえば、明らかな変形例はステップ１１４が、データ
を提供する安全なＬＡＮ２８内の種々のコンピュータ・
システム上ですべてまたは一部を処理される場合であ
る。

【００５３】ステップ１２０では、電子メール・メッセ
ージは公式に送信されインターネット２６を介してコン
ソール２４（すなわち、上のシナリオ内で目的とされる
受信側）がファイルを受信できる場所まで移動する。図
７に描かれたように、ＳＭＴＰサーバを使用することが
できる。ＳＭＴＰは今日使用されているもっとも普及し
ているタイプの電子メール・サーバである。しかし別の
システムも使用される場合がある。もっとも簡単な場合
では、電子メール・サーバはエージェント２２を実行し
ている全く同じコンピュータ・システム上にある場合も
ある。別法としては、安全なＬＡＮ２８内に電子メール
・サーバがない場合、外部のインターネット・サービス
・プロバイダ（ＩＳＰ）のところに存在する場合もあ
る。しかしもっとも典型的なのは、電子メール・サーバ
が安全なＬＡＮ２８内で、エージェント２２を実行して
いる同じコンピュータ・システム以外の場所にあること
である。

【００５４】図８は、電子メールおよびネットワーク通
信システム２０を使用するデータ受信側のプロセスの流
れ１３０を描いたフロー・チャートである。図７に関し
て説明されたように、電子メール・メッセージはエージ
ェント２２において作成され、インターネット２６を介
して送信される。

【００５５】ステップ１３２では、電子メール・メッセ
ージが受信され電子メール・サーバに格納される。描か
れたように、普及しているＳＭＴＰ／ＰＯＰ３タイプの
サーバが使用される可能性があるが、他のサーバが使用
される可能性もある。簡単な場合では、電子メール・サ
ーバは、ステップ１２０で電子メール・メッセージを最
初に通信したエージェント２２と同じものである可能性
もある。しかし一般的には、これはネットワークの別の
場所に位置する異なる電子メール・サーバである。電子
メール・サーバはＬＡＮ３４の外部、たとえばＩＳＰに
ある。しかし一般的にはＬＡＮ３４の中にあり、コンソ
ール２４を実行している同じコンピュータ・システム上
かまたは別の場所にある（これがおそらくもっとも一般
的な場合である）。

【００５６】ステップ１３４では、スケジューリングま
たは「ウォッチ・ドッグ」サブ・プロセスは、エージェ
ント２２からの電子メール・メッセージをチェックする
時を決定する（もちろん、１つ以上のメッセージが蓄積
し、検索できるようになっている）。ステップ１３６で
は、ステップ１３４におけるサブ・プロセスからの命令
があると、電子メールのクライアント・サブ・プロセス
はメッセージを要求し１つまたは複数を受信して戻すこ
とにより、電子メール・サーバから電子メール・メッセ
ージを検索する。

【００５７】ステップ１３８では、受信された電子メー
ルが最初に処理される。特に、これは電子メールとして
の特性を失い、エージェント２２から受信されたデータ
となる。ステップ１４０では、データが暗号化されてい
る場合には復号化されるか、または場合によってはフォ
ーマット化される。これが必要でない場合、ステップ１
４０はオプションで簡単に省略される場合もある。最後
にステップ１４２では、データが準備されコンソール２
４によって使用される。

【００５８】機能面を強調するためにステップ１３８、
１４０および１４２は別に表されているが、これらはネ
ットワーク通信システム２０の実際の実施形態内で多か
れ少なかれ統合できる。

【００５９】図７および図８をまとめてみると、エージ
ェント２２は電子メールを使用してエージェント２２が
収集したデータをコンソール２４に通信する。エージェ
ント２２によって収集されたデータが特に重要ではない
場合、従来の開いた電子メールによって（および共通に
割り当てられたポート２５を介して）送信される。たと
えば、データは非常に簡単なネットワーク性能統計であ
る可能性がある。あるいは、エージェント２２によって
収集されたデータがプライバシを保護したい動機となる
なんらかの属性を有する場合、受信された電子メール・
メッセージが解読できる限りにおいて、エージェント２
２はプロプラエタリ・システムまたは広く使用可能な任
意のシステムを使用して暗号化された電子メールを使用
することができる。

【００６０】図９はハイパーテキスト転送プロトコル
（ＨＴＴＰ）トネリングおよびネットワーク通信システ
ム２０を使用するデータ送信側のプロセスの流れ１５０
を描いたフロー・チャートである。

【００６１】ステップ１５２では、スケジュール・サブ
・プロセスが実行され、ネットワーク通信システム２０
はエージェント２２に対して、コンソール２４へ向けて
データを送信するべき時を指定する。ステップ１５４で
は、送信されるべきデータが準備される（たとえば暗号
化されるかまたはフォーマット化される。またはこのス
テップはオプションで省略される場合もある）。ステッ
プ１５６では、データはエージェント２２によって「送
信される」。

【００６２】図７の場合と同じく、これらのステップは
その機能面を強調するためにここでは別に表わされてい
る。当業者であれば、ネットワーク通信システム２０の
実際の実施形態内で多かれ少なかれこれらを統合できる
ことが容易に理解されるであろう。さらに、ステップ１
５２、１５４および１５６は、図７のステップ１１２、
１１４および１１６と本質的に同じであり、同じリソー
スを使用している場合もある。

【００６３】ステップ１５８では、データはデータを含
むＨＴＴＰ要求としてウェブ・クライアントのサブ・プ
ロセスによって、インターネット２６を介して、ＬＡＮ
３４内にあるウェブ・サーバへ送信される。ここで顕著
なポイントは、データは従来通りにＨＴＴＰ要求の一部
として移動するのではないが、その他の点では従来のＨ
ＴＴＰ通信要求として本質的に同じであることである。
最終的に、ＨＴＴＰを使用する時の従来の方法で、要求
を受信するウェブ・サーバから応答が受信して戻され
る。

【００６４】図１０はＨＴＴＰトネリングおよびネット
ワーク通信システム２０を使用するデータ受信側のプロ
セスの流れ１７０を描いたフロー・チャートである。図
９に関して説明したように、データはインターネット２
６を介して送信されたＨＴＴＰ要求内に埋め込まれ、エ
ージェント２２によって送信されている。

【００６５】ステップ１７２では、データはＬＡＮ３４
内でウェブ・サーバにおいてステップ１５８のウェブ・
クライアントのサブ・プロセスからの要求の一部として
受信される。ウェブ・サーバは完全に従来のものでもよ
い。ステップ１７４では、ウェブ・サーバと共に実行し
ているアプレットが、要求がエージェント２２からデー
タと共に受信されたことを識別し、データを別に分離す
る。アプレットは市販のソフトウェアである場合もあ
り、またはネットワーク通信システム２０のプロプラエ
タリである場合もある。

【００６６】ステップ１７６では、アプレットから受信
されたデータが最初に処理される。ステップ１７８で
は、データが暗号化されている場合は復号化されるか、
または場合によってはフォーマット化される（またはこ
のステップはオプションで簡単に省略される場合もあ
る）。最後にステップ１８０では、データが準備されコ
ンソール２４によって使用される。

【００６７】ここでも、図および議論はステップ１７
６、１７８および１８０の機能面を強調する。これらは
ネットワーク通信システム２０の実際の実施形態内で多
かれ少なかれ統合できる。

【００６８】図９および図１０をまとめてみると、エー
ジェント２２は従来のポート８０を使用するハイパーテ
キスト転送プロトコル（ＨＴＴＰ）トネリングなどのト
ネリング・プロトコルを使用する場合もあり、またはパ
ブリック・プライベート・キー・スキームを使用してセ
ッションを確立する仮想専用線（ＶＰＮ）である場合も
ある。

【００６９】図１１はファイル転送プロトコル（ＦＴ
Ｐ）およびネットワーク通信システム２０を使用するデ
ータ送信側のプロセスの流れ１９０を描いたフロー・チ
ャートである。多くの点で、これらは上記の図７および
図８と同じく、電子メールを使用してデータを送達する
方法と同じである。

【００７０】ステップ１９２では、スケジュール・サブ
・プロセスが実行され、ネットワーク通信システム２０
がエージェント２２に対して、コンソール２４へ向けて
データを送信するべき時を指定する。ステップ１９４で
は、送信されるべきデータが準備される。ステップ１９
６では、データはＦＴＰクライアントに渡されて送信さ
れることによって、エージェント２２によって「送信さ
れる」。これらのステップ１９２、１９４および１９６
は統合することもでき、また図７のステップ１１２、１
１４および１１６と本質的に同じであり同じリソースを
使用している場合もある。

【００７１】ステップ１９８では、ファイルはＦＴＰク
ライアントのサブ・プロセスによってエージェント２２
から公式に送信され、インターネット２６を介してコン
ソール２４（すなわち、上のシナリオで目的とされる受
信側）がファイルを受信できる場所まで移動する。ＦＴ
Ｐクライアントは典型的には従来のものであるが、必ず
しも従来のものである必要はない。ネットワーク通信シ
ステム２０はプロプラエタリＦＴＰクライアントを使用
することもできるが、適切な従来の通信システムが普及
しているので、おそらくプロプラエタリＦＴＰクライア
ントによる実施形態はまれであろう。

【００７２】図１２は、ＦＴＰおよびネットワーク通信
システム２０を使用するデータ受信側のプロセスの流れ
２１０を描いたフロー・チャートである。図１１に関し
て説明されたように、ファイルはエージェント２２（す
なわち送信側）において作成され、インターネット２６
を介して送信される。

【００７３】ステップ２１２では、ファイルがＦＴＰサ
ーバにおいて受信され格納される。ＦＴＰサーバはＬＡ
Ｎ３４の外部にある可能性がある。しかし、もっとも普
通には、図１２で示されたようにＬＡＮ３４の中にあ
り、コンソール２４を実行している同じコンピュータ・
システム上かまたは別の場所にある（別の場所にある方
が普通である）。

【００７４】ステップ２１４では、スケジューリング・
サブ・プロセスはエージェント２２によって送信された
ファイルをチェックする時を決定する（複数のファイル
が蓄積し、検索できるようになっている）。ステップ２
１６では、ステップ２１４におけるサブ・プロセスから
の命令があると、ＦＴＰクライアントのサブ・プロセス
はこのようなファイルを要求し、１つまたは複数を受信
して戻すことにより、ＦＴＰサーバからファイルを検索
する。ステップ２１８では、受信されたファイルが最初
に処理される。特に、これはファイルとしての特性をこ
こで失い、エージェント２２から受信されたデータとな
る。ステップ２２０では、データが暗号化されている場
合には復号化されるか、または場合によってはフォーマ
ット化される（またはこのステップはオプションであり
簡単に省略される場合もある）。最後にステップ２２２
では、データが準備されコンソール２４によって使用さ
れる。

【００７５】図１１および図１２をまとめてみると、エ
ージェント２２はまたＦＴＰを使用して（典型的には共
通に割り当てられたポート２１を介して）データをコン
ソール２４に通信する。使用されるＦＴＰシステムは安
全なＬＡＮ２８の外の、望ましいセキュリティの程度に
よって動機づけられて、無名のログインを使用するかま
たは強力なパスワードに基づいたログインを使用する。

【００７６】図１３はプロプラエタリ・プロトコルをネ
ットワーク通信システム２０の一部として使用するデー
タ送信側のプロセスの流れ２３０を描いたフロー・チャ
ートである。多くの点でこれは、図７〜図８および図１
１〜図１２を参照して上述された、データを送達するた
めの電子メールまたはＦＴＰの使用と同じであってもよ
い。

【００７７】ステップ２３２では、スケジュール・サブ
・プロセスが実行され、ネットワーク通信システム２０
データが送信されるべき時を指定する。ステップ２３４
では、送信されるべきデータが準備される（望ましい場
合には）。ステップ２３６では、データはプロプラエタ
リ・クライアントに渡されて実際に送信されることによ
って、エージェント２２によって「送信される」。ステ
ップ２３８では、データはプロプラエタリ・クライアン
トのサブ・プロセスによってエージェント２２から公式
に送信され、インターネット２６を介してコンソール２
４がデータを受信できる場所まで移動する。

【００７８】図１４は、図１３のプロプラエタリ・プロ
トコルをネットワーク通信システム２０の中で使用する
データ受信側のプロセスの流れ２５０を描いたフロー・
チャートである。図１３に関して説明されたように、デ
ータはエージェント２２において作成され、インターネ
ット２６を介して送信される（「ファイル」または「メ
ッセージ」はほぼ意味論の問題である）。

【００７９】ステップ２５２では、スケジューリング・
サブ・プロセスはエージェント２２からのデータをチェ
ックする時を決定する。ステップ２５４では、ステップ
２５２におけるサブ・プロセスからの命令があると、プ
ロプラエタリ・クライアントのサブ・プロセスはエージ
ェント２２によって送信されたデータを検索する。ステ
ップ２５６では、受信されたデータが最初に処理され
る。ステップ２５８では、データはオプションとして復
号化されるかまたはフォーマット化される。ステップ２
６０では、データが準備されコンソール２４によって使
用される。

【００８０】図１３および図１４をまとめてみると、エ
ージェント２２はまた安全なＬＡＮ２８内のあらかじめ
決められた開いたポートを使用してデータをコンソール
２４に送信する（典型的には「割り当てられていない」
ポートであり、慣習としては１０２４より高い番号の付
けられたポートである）。安全なＬＡＮ２８上で使用さ
れるポートは、出力データを通信するためにのみ静的に
開くかまたは短い間開くことができる。しかし、このよ
うなあらかじめ定義されたポートは、あまり使用されな
いか、ネットワーク管理者によって割り当てられるかま
たは頻繁に再割り当てされることがあるため、エージェ
ント２２は、安全なＬＡＮ２８の中の有利な位置から使
用可能な開いた出力ポートをダイナミックに「検知（sn
iff）」することができる。この方法で、エージェント
２２が知られたパラメータおよび厳格に定義されたパラ
メータを使用するように、静的に設定する必要はない。
これはたとえばディスケットまたはＣＤ上で安全なＬＡ
Ｎ２８の比較的洗練されていないユーザに提供され、そ
のユーザがついでそれを実行する場合もある。エージェ
ント２２はコンソール２４と通信する使用可能な方法を
知的に検出できる。

【００８１】上記の議論は主に安全なＬＡＮ２８から外
部に向けられた通信に関するものであったが、エージェ
ント２２はまたコンソール２４とのインタラクティブな
通信を開始することもできる。エージェント２２が一意
的な一度だけの符号を、たとえば、電子メールおよびお
そらくハッシュ・コード（暗号ほど複雑ではない）でコ
ンソール２４に送信する場合、これはコンソール２４か
らの応答通信の有効性を確認するために使用できる。こ
のようにして、安全なＬＡＮ２８の洗練されていないユ
ーザの例を続けると、一度エージェント２２が安全なＬ
ＡＮ２８上でディスケットからロードすることによって
実行されると、エージェント２２は最初の分析を実行し
その結果発見されたことをパブリック・プライベート・
キーで暗号化された電子メールでハッシュ・コードと共
にコンソール２４に通信し、コンソール２４からは電子
メールの応答をさらなる動作の命令と共に戻して受け取
ることができる（オプションとしては、機密の方法を使
用するパブリック・プライベート・キー暗号化またはハ
ッシュ・マーク付き）。

【００８２】本発明のネットワーク通信システム２０に
よって使用可能なプロセスはまた、多くの場合簡単に拡
張可能であり結合可能である。エージェント２２は、た
とえば１つの適切に保護され１回応答トークンを含んだ
ＦＴＰファイルをコンソール２４に送信でき、コンソー
ル２４は命令のＦＴＰファイルを送信してエージェント
２２に戻す。この場合、ＦＴＰは安全なＬＡＮ２８内で
許可され、エージェント２２はこの動作を実行するため
の任意のパスワードおよび他の必要なデータを得てコン
ソール２４に送信できることが仮定されている。エージ
ェント２２はついで定期的または特定の時間に、コンソ
ール２４が応答したかどうかをチェックするのみであ
る。

【００８３】エージェント２２が上記のようにトネリン
グ・プロトコルを使用している場合、コンソール２４と
のインタラクティブな通信を開始することは非常に簡単
である。同様に、コンソール２４とのインタラクティブ
な通信のための、静的およびダイナミックなポートに基
づいた方法は、安全なＬＡＮ２８の中からエージェント
２２によって開始された時には簡単である。

【００８４】もちろん、これらの技法の組合せを使用す
ることもできる。たとえば、コンソール２４への電子メ
ールおよびそれから戻されるＦＴＰは、エージェント２
２がこれをどのように実行することができるかを決定す
る。あるいは、エージェント２２は、たとえばネットワ
ーク維持のための診断の役割を満たすことと調和して特
にフレキシブルに作成でき、安全なＬＡＮ２８の電子メ
ール構成要素が誤機能している時にダイナミックにＦＴ
Ｐに頼ることができる。または、安全なＬＡＮ２８内の
ＶＰＮ通信のために習慣上使用されているサーバに問題
がある時には、ポートの検出または使用可能な任意の依
然として機能している方法に頼る場合もある。

【００８５】種々の実施形態が上記に説明されたが、こ
れらは例としてのみ提示されているものであり限定では
ないことを理解されたい。したがって、好ましい実施形
態の広さと範囲は、上記の説明された例としての実施形
態のいずれによっても限定されるべきでなく、首記の特
許請求の範囲およびその同等物にしたがってのみ定義さ
れるべきである。

【００８６】本ネットワーク通信システム２０は、現代
の安全でないネットワーク内での用途によく適してい
る。これはローカル・エリア・ネットワーク（ＬＡＮ）
またはインターネットなどのグローバルＷＡＮを含む広
域ネットワーク（ＷＡＮ）内で使用できる。

【００８７】ネットワーク通信システム２０は、安全な
ネットワーク・セグメントのエンティティと別のネット
ワーク・セグメント内のエンティティの間でデータまた
はメッセージを渡すことが望まれている、幅広い通信目
的のために使用できる。メッセージの目的は本質的にネ
ットワーク通信システム２０に無関係である。１つのネ
ットワーク管理例がここに提供されているが、これは本
発明の可能性のある使用範囲を示すに過ぎない。

【００８８】ネットワーク通信システム２０は非常にフ
レキシブルであり、多くの異なるプロトコルを個別にも
または組み合わせて使用できる。さらに、本発明の洗練
された実施形態は適応性のある技法を使用して、所与の
場合に機能するプロトコルを検出することもでき、特に
使用可能なポートを自動的に発見し使用して、通信にお
けるその役割を実行することもできる。

【００８９】ネットワーク通信システム２０は本質的に
従来の技術を使用しており、強力な実施形態は簡単に作
成できる。限定的ではないが、このような従来技術の一
部の例は電子メール、ファイル転送プロトコル（ＦＴ
Ｐ）およびトネリング・プロトコル（たとえばＨＴＴＰ
およびＶＰＮ）を含む。別法としては、一般に任意の望
ましい程度で従来のプログラミング技術を使用するプロ
プラエタリ・プロトコルが使用される場合もある。

【００９０】本発明のネットワーク通信システム２０は
ソフトウェア内で完全に実装されるので、したがって非
常に再生可能であり簡単に搬送できるので、一般には非
常に経済的である。

【００９１】上記の理由および他の理由で、本発明のネ
ットワーク通信システム２０は産業用の広い用途を有す
ることになる。したがって、本発明の商業上の使用は広
範囲であり長く続くものとなろう。

【図面の簡単な説明】

【図１】エージェントを伴う通信用に使用される従来の
システムを描いた概念図である。

【図２】図１の従来の技術に伴う問題を描いた概念図で
ある。

【図３】本発明による、エージェントを伴う通信用のシ
ステムを描いた概念図である。

【図４】従来のシステムの変形例に基づいた、ローカル
・エリア・ネットワーク（ＬＡＮ）を描いた概念図であ
る。

【図５】図４の従来のシステムに伴う問題を描いた概念
図である。

【図６】本発明による、エージェントを伴う通信用のシ
ステムを描いた概念図である。

【図７】本発明による、電子メールを使用するデータ送
信側のプロセスの流れを描くフロー・チャートである。

【図８】図７に提供されたような、電子メールを使用す
るデータ受信側のプロセスの流れを描くフロー・チャー
トである。

【図９】ハイパーテキスト送信プロトコル（ＨＴＴＰ）
・トネリングを使用するデータ送信側のプロセスの流れ
を描くフロー・チャートである。

【図１０】図９に提供されたような、ＨＴＴＰトネリン
グを使用するデータ受信側のプロセスの流れを描くフロ
ー・チャートである。

【図１１】ファイル転送プロトコル（ＦＴＰ）を使用す
るデータ送信側のプロセスの流れを描くフロー・チャー
トである。

【図１２】図１１に提供されたような、ＦＴＰを使用す
るデータ受信側のプロセスの流れを描くフロー・チャー
トである。

【図１３】プロプラエタリ・プロトコルを使用するデー
タ送信側のプロセスの流れを描くフロー・チャートであ
る。

【図１４】図１３に提供されたような、プロプラエタリ
・プロトコルを使用するデータ受信側のプロセスの流れ
を描くフロー・チャートである。

【符号の説明】

２０ ネットワーク通信システム ２２ エージェント ２４ コンソール ２６ インターネット ２８ ＬＡＮ ３０ ファイアウォール ３２ ゲートウェイ ３４ ＬＡＮ ３６ ゲートウェイ ３８ パス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ルーク・シァンボリ アメリカ合衆国・95132・カリフォルニア 州・サン ホゼ・ミント ドライブ・2053

Claims (23)

【特許請求の範囲】
1. 【請求項１】 （ａ）セキュリティ・システムによって
   保護されているネットワークの第１のセグメント内にエ
   ージェントを置くステップと、 （ｂ）前記エージェントで第１のネットワーク・セグメ
   ント内でメッセージ・データを収集するステップと、 （ｃ）前記エージェントと通信を開始するステップと、 （ｄ）前記ネットワークの第２のセグメント内で前記エ
   ージェントからコンソールへ前記メッセージ・データを
   通信し、前記メッセージ・データが前記ネットワークの
   第１のセグメントから前記第２のセグメントへ外側に向
   いて進み、これによって前記セキュリティ・システムに
   よって妨害されないステップとを含むネットワーク内で
   通信する方法。
2. 【請求項２】 前記エージェントが受動的に前記メッセ
   ージ・データを受信する請求項１に記載の方法。
3. 【請求項３】 動作の間、前記メッセージが前記ネット
   ワークの前記第１のセグメントによって自動的に生成さ
   れる請求項２に記載の方法。
4. 【請求項４】 前記エージェントの制御下で、前記ネッ
   トワークの前記第１のセグメント内で少なくとも１つの
   サブ・ルーチンを実行することによって、前記エージェ
   ントが前記メッセージ・データを能動的に生成する請求
   項１に記載の方法。
5. 【請求項５】 前記エージェントの制御下で、前記ネッ
   トワークの前記第１のセグメント内で少なくとも１つの
   サブ・ルーチンを実行することによって、前記エージェ
   ントが能動的に前記メッセージ・データを別のエンティ
   ティから受信する請求項１に記載の方法。
6. 【請求項６】 前記ステップ（ｂ）が、前記メッセージ
   ・データのフォーマット化および暗号化のうち少なくと
   も１つを含む請求項１に記載の方法。
7. 【請求項７】 前記ステップ（ｂ）が、ある時間の間デ
   ータを前記メッセージ・データの中に蓄積することを含
   み、 前記ステップ（ｃ）が、スケジュールに基づいて開始す
   る請求項１に記載の方法。
8. 【請求項８】 前記ステップ（ｂ）がさらに、前記メッ
   セージ・データの各インスタンスに優先順位を割り当て
   ることを含み、 前記ステップ（ｃ）が、前記優先順位に基づいて開始す
   る請求項１に記載の方法。
9. 【請求項９】 前記ステップ（ｄ）が、電子メール、フ
   ァイル転送プロトコル、トネリング・プロトコルおよび
   プロプラエタリ・プロトコルのいずれかを介して前記メ
   ッセージ・データを通信することを含む請求項１に記載
   の方法。
10. 【請求項１０】 前記ステップ（ｄ）が、前記第１のセ
    グメント内のあらかじめ指定された開いたポートを介し
    て前記メッセージ・データを通信することを含む請求項
    １に記載の方法。
11. 【請求項１１】 前記ステップ（ｄ）が、前記第１のセ
    グメント内でプログラムによって決定されている開いた
    ポートを介して前記メッセージ・データを通信すること
    を含む請求項１に記載の方法。
12. 【請求項１２】 システムであって、 セキュリティ・システムによって保護され、エージェン
    トを含むネットワークの第１のセグメントと、 コンソール・ユニットを含む前記ネットワークの第２の
    セグメントとを備え、前記エージェントが通信を開始す
    る論理を含み前記エージェントは、前記メッセージ・デ
    ータを前記コンソール・ユニットに通信する論理をさら
    に含み、前記メッセージ・データは前記ネットワークの
    前記第１のセグメントから前記第２のセグメントへ外側
    に向いて進み、これによって前記セキュリティ・システ
    ムによって妨害されないメッセージ・データを安全に通
    信するシステム。
13. 【請求項１３】 前記エージェントが受動的であり前記
    メッセージ・データを受信する請求項１２に記載のシス
    テム。
14. 【請求項１４】 動作の間、前記メッセージが前記ネッ
    トワークの前記第１のセグメントによって自動的に生成
    される請求項１３に記載のシステム。
15. 【請求項１５】 前記エージェントが能動的であり、前
    記ネットワークの前記第１のセグメント内で少なくとも
    １つのサブ・ルーチンを実行して前記メッセージ・デー
    タを生成する請求項１２に記載のシステム。
16. 【請求項１６】 前記エージェントがさらに、前記メッ
    セージ・データのフォーマット化および暗号化のうち少
    なくとも１つを実行する論理を含む請求項１２に記載の
    システム。
17. 【請求項１７】 前記エージェントがさらに、ある時間
    の間データを前記メッセージ・データの中に蓄積し、つ
    いでスケジュールに基づいた時間に前記メッセージ・デ
    ータを通信する論理を含む請求項１２に記載のシステ
    ム。
18. 【請求項１８】 前記エージェントがさらに、前記メッ
    セージ・データの各インスタンスに優先順位を割り当
    て、ついで前記メッセージ・データを前記優先順位に基
    づいた時間に通信する論理を含む請求項１２に記載のシ
    ステム。
19. 【請求項１９】 前記エージェントが、電子メール、フ
    ァイル転送プロトコル、トネリング・プロトコルおよび
    プロプラエタリ・プロトコルのいずれかを介して前記メ
    ッセージ・データを通信する請求項１２に記載のシステ
    ム。
20. 【請求項２０】 前記エージェントが前記第１のセグメ
    ント内のあらかじめ指定された開いたポートを介して前
    記メッセージ・データを通信する請求項１２に記載のシ
    ステム。
21. 【請求項２１】 前記エージェントが、前記第１のセグ
    メント内でプログラムによって決定されている開いたポ
    ートを介して前記メッセージ・データを通信する請求項
    １２に記載のシステム。
22. 【請求項２２】 前記ネットワークがインターネットで
    ある請求項１２に記載のシステム。
23. 【請求項２３】 前記セキュリティ・システムがファイ
    アウォールを含む請求項１２に記載のシステム。