(57)【要約】      （修正有）【課題】  要求に応答したコンピュータネットワークを通じて得られるコンピュータネットワーク上のセッションを記録する。【解決手段】コンピュータネットワーク上を行き来するデータパケットを監視する。音声データ、映像データ、または音声映像データ（「データ」）を含む１つあるいは複数のデータパケットを選択するため、コンピュータネットワーク上を行き来するデータパケットを解析する。監視されているセッションを表す１つあるいは複数のＩＰアドレスに関連したデータパケットを特定する。特定されたデータパケットに含まれるそのデータを記憶する。特定されたデータパケットに含まれるデータを、データパケットが属するコンピュータネットワーク上の電話セッションの少なくとも一部を基にした特定の電話セッションへ整理する。整理されたデータパケットに含まれるデータは、特定の電話セッションに対するユーザの要求信号を受信した場合、出力する。【選択図】図１
2007014006.tif 000002
【特許請求の範囲】
【請求項１】
要求に応答した表示を行なうためにコンピュータネットワークを通じて得られる前記コンピュータネットワーク上の通信セッションを引き出すために前記コンピュータネットワーク上を行き来するデータパケットを監視する方法であって、
（ａ）音声データ、映像データ、または音声映像データを含む１つあるいは複数のデータパケットを選択するため、前記コンピュータネットワーク上を行き来する複数のデータパケット内のデータを解析し、
（ｂ）監視されているセッションを表す１つあるいは複数のＩＰアドレスに関連したデータパケットを特定し、
（ｃ）前記特定されたデータパケットに含まれる音声データ、映像データ、または音声映像データを記憶し、
（ｄ）前記特定されたデータパケットに含まれる音声データ、映像データ、または音声映像データを、前記データパケットが属するコンピュータネットワーク上の通信セッションの少なくとも一部を基にした特定の通信セッションへ整理し、
（ｅ）前記特定の通信セッションに対するユーザの要求信号を受信した場合、前記整理されたデータパケットに含まれる音声データ、映像データ、または音声映像データを出力する、ステップを含む監視方法。
【請求項２】
１つあるいは複数のＩＰアドレス、時刻、日付、チャネル、ダイアルされた番号、及び電話をかけた者の識別情報の群から選択された１つあるいは複数を含む前記受け取りデータパケットから引き出された情報をデータベースに含めるステップをさらに備える請求項１の監視方法。
【請求項３】
前記データは、前記コンピュータネットワークを介してアクセス可能な記録媒体に記憶される請求項１の監視方法。
【請求項４】
前記コンピュータネットワークは、ローカルエリアネットワークあるいはワイドエリアネットワークである請求項１の監視方法。
【請求項５】
前記出力ステップは、音声データ、映像データ、または音声映像データを出力する請求項１の監視方法。
【請求項６】
前記出力ステップは、コンピュータモニター、ビデオモニター、あるいは表示スクリーン上に前記整理されたデータパケットに含まれる映像を表示するステップをさらに備える請求項５の監視方法。
【請求項７】
前記出力ステップは、イヤホンあるいは拡声器を介した音声として前記整理されたデータパケットに含まれる音声を生成するステップをさらに備える請求項５の監視方法。
【請求項８】
前記特定されたデータパケットは、前記選択されたデータパケット内にある請求項１の監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワーク上の電話通信のための通信セッションの管理方法および管理システムに関し、特に音声および／または映像データを含むパケットの識別のため、これらのパケットの記憶のため、および必要に応じて音声および／または映像の表示のために選択された通信セッションの再構成のための通信セッションの管理方法および管理システムに関する。
【背景技術】
【０００２】
オフィス通信システムへのコンピュータの組み込みにより、以前には別々の装置によって行われていた多くの機能を結合してコンピュータにより操作される単一管理システムにすることが可能になった。例えば、コンピュータを基にした音声ログシステムは、コンピュータが、普通電話網へのハードウェア接続を通じて音声通信を受信すること、少なくとも２人が話している会話や、少なくとも１人から１人またはそれ以上の相手へのメッセージを記録すること、要求に応じてそれらの記録された会話やメッセージを再生することを可能にする。
コンピュータログシステムは、機械式の応答装置より多くの利点を持つ。例えば、音声メッセージは、コンピュータに基づく通常のオーディオカセットよりも大きな記憶容量を持つＤＡＴカセットのような記録媒体に記憶させることができる。さらに、記憶された音声メッセージはデータベース内で、それらが例えば時刻、日付、チャネル、ダイアルされた番号、電話をかけた者の識別情報により引き出すことができるように、整理することができる。このような整理は、機械式の電話応答システムではできない。このように、音声メッセージ用のコンピュータログシステムは、機械式の電話応答システムに比べて多くの利点を持つ。
【０００３】
不幸なことに、現在利用できるコンピュータログシステムは、ＬＡＮ（ローカルエリアネットワーク）またはＷＡＮ（ワイドエリアネットワーク）を通じて行われる音声通信のための電話通信セッションを、会話であるかメッセージであるかによらず、記録できないという不利な点がある。これらのログシステムは例えばＬＡＮを通じて遠隔ユーザに音声メッセージを再生することができるが、同様のメッセージをそれがＬＡＮを基にした電話によって送信されると記録することができない。このようなＬＡＮおよびＷＡＮを基にした電話通信は、最近ますます普及しつつある。なぜならこの電話通信は、地域の普通電話網サービスに料金を支払うことなく、それによって金を節約しながら物理的に離れているいろいろな人々の間の電話通信を可能にするからである。
さらにＬＡＮやＷＡＮ上の電話通信は、音声情報と同様に映像情報の送信をも容易にする。映像情報は現在利用できるコンピュータログシステムでは全く記録できない。このように音声データおよび映像データの両方を含むＬＡＮまたはＷＡＮで行われる電話通信のための電話通信セッションを記録するコンピュータログシステムの能力不足が、これらのシステムの大きな不利点である。
したがって、音声および映像情報の両方を記録し、それらの情報を整理し、そして要求に応じてそれらの情報を表示するような、ＬＡＮやＷＡＮなどのコンピュータネットワーク上で行われる電話の通信セッションを記録するためのシステムおよび方法に対するニーズがあり、またそれを持つことはきわめて有利であろう。
【０００４】
以下の説明は、本発明の方法とシステムにおいて随意に使用される若干の背景の方法および技術について説明を与えることを意図している。本発明は明確にこれらの方法や技術だけに帰着させられるものではない。むしろ、それらは、コンピュータネットワーク上のデータパケットを解析し、音声および映像パケットを選択的に記録し、その記憶された情報を整理し、要求に応じてその記憶された情報を表示するためのシステムおよび方法である本発明の目的を達成するためのツールとして使用される。そしてコンピュータネットワーク上の“電話”システムで行われる通信セッションをログ（記録）することができる。
本発明のシステムおよび方法は、特に、サービスの品質を保証しないローカルエリアネットワークのためのテレビ電話システムおよび装置のためのＩＴＵ−Ｔ推奨Ｈ.３２３に従って構成されたコンピュータネットワークと共に動作することを意図されている。
推奨Ｈ.３２３は、そのようなコンピュータネットワークのためのハードウェアに対する要求および動作プロトコルをさらに詳しく説明するために、この明細書に参照により組み入れられており、以後“Ｈ.３２３”と呼ばれる。
Ｈ.３２３は、品質が保証されたサービスを提供しないローカルエリアネットワーク（ＬＡＮ）上のマルチメディア通信のための端末、機器、サービスについて規定している。Ｈ.３２３の要求を満たすコンピュータ端末や機器は、リアルタイムの音声、データ、映像またはそれらの組み合わせ−テレビ電話も含む−を伝えることができる。
【０００５】
そのような端末どうしが通信できるＬＡＮは、単一セグメントまたはリングでもよいし、または複雑なトポロジーのマルチセグメントでもよい。これらの端末はコンピューに統合されていてもよいし、テレビ電話のようなスタンドアロンの装置として実現されてもよい。音声データにたいするサポートは不可欠とされているが、一般的なデータや映像データにたいするサポートは自由に選択できる。しかしながら、サポートされる場合には、そのメディアタイプをサポートしている全ての端末が通信できるようにするために、共通の動作モードを使用する能力が要求される。Ｈ.３２３推奨は各タイプの１つ以上のチャネルが使用されることを許容する。同様に参照によって組み入れられているＨ.３２３−シリーズ中の他の推奨には、Ｈ.２２５.０パケットおよび同期、Ｈ.２４５制御、Ｈ.２６１およびＨ.２６３ビデオコーデック、Ｇ.７１１，Ｇ.７２２，Ｇ.７２８，Ｇ.７２９およびＧ.７２３オーディオコーデック、およびマルチメディア通信プロトコルのＴ.１２０−シリーズが含まれる。
ＩＴＵ−Ｔ推奨Ｈ.２４５.０は、映像電話システムのためのメディアストリームのパケット化および同期についての規定を含む。ＩＴＵ−Ｔ推奨Ｈ.２４５.０はまたマルチメディア通信のための制御プロトコルを規定しており、以後“Ｈ.２４５”と呼ばれている。Ｈ.２４５は参照により組み入れられておりこの明細書中で十分に説明されている。
【０００６】
Ｈ.２４５の論理チャネルシグナリング手続きは、論理チャネルが開かれているときの各チャネルの内容を説明している。送信を受信側がデコードできる情報に制限するために、また受信側が送信側から所望のモードを要求してもよいようにするために、受信側および送信側の機能能力を知らせための手続が規定されている。
Ｈ.２４５のシグナリングは２つの端点；１つの端点とマルチポイントコントローラ、または１つの端点とゲートキーパーの間に開設される。端点はその端点が参加する各呼のために、正しく１つのＨ.２４５制御チャネルを開設する。そのチャネルはＨ.２４５に従って動作しなければならない。多重コールにたいするサポートしたがって複数のＨ.２４５制御チャネルにたいするサポートは可能である。
ＲＡＳシグナリング機能は、端点とゲートキーパーの間の登録、アドミッション、帯域幅の変更、ステータス、および解放手続きを行うために、Ｈ.２２５.０のメッセージを使用する。ゲートキーパーを持たないＬＡＮ環境では、ＲＡＳシグナリングチャネルは使用されない。ＬＡＮが少なくとも１つのゾーンを含む場合のように、ゲートキーパーを含むＬＡＮ環境では、ＲＡＳシグナリングチャネルが端点とゲートキーパーの間に開かれる。このＲＡＳシグナリングチャネルは、Ｈ.３２３端点間の他のチャネルが確立される前に開かれる。
コールシグナリング機能は、２つのＨ.３２３端点の間の接続を確立するために、Ｈ.２２５のコールシグナリングを使用する。このコールシグナリングチャネルはＲＡＳチャネルおよびＨ.２４５制御チャネルから独立している。コールシグナリングチャネルはＨ.２４５チャネルおよびＨ.３２３端点間の他の論理チャネルが確立される前に開かれる。ゲートキーパーを持たないシステムでは、コールシグナリングチャネルはその呼に関与している端点間に開かれる。ゲートキーパーを含むシステムでは、コールシグナリングチャネルは、端点とゲートキーパーの間またはゲートキーパーにより選択されている端点間に開かれる。
【特許文献１】米国特許第５５１５３７６号
【特許文献２】米国特許第５６６４２２６号
【特許文献３】国際公開ＷＯ９７／４１６７４
【特許文献４】欧州特許第０８４１８３２号
【非特許文献１】SCHULZRINNE et al., "RFC 1889:RTP: A Transport Protocol for Real-Time Applications," NETWORK WORKING GROUP REQUEST FOR COMMENTS, Jan. 1996 (complete document, page 1-75)
【非特許文献２】Madeline Bodin, "Keeping An eye on Your Agents," Call Center Magazine, Feb.1993, 4 pages
【発明の開示】
【発明が解決しようとする課題】
【０００７】
コンピュータネットワーク上で行われる通信セッションを記録するための１つのシステムおよび方法を提供することが本発明の１つの目的である。
記録するための音声および映像データを検出するために、コンピュータネットワーク上を送信されるデータを解析するためのシステムおよび方法を提供することが本発明のもう１つの目的である。
要求に応じて記録された映像および音声データを表示するためのシステムおよび方法を提供することが、本発明のさらにもう１つの目的である。
ＬＡＮに基づく電話システムで行われる通信セッションを解析し、記録し、表示するためのシステムおよび方法を提供することが、本発明のさらにもう１つの目的である。
本発明のこれらのそしてさらに他の目的は、図面、説明および請求項に関係してさらに詳しく説明される。
本発明は、コンピュータネットワーク上のデータパケットを解析するため、音声および映像データのパケットを選択的に記録するため、この記憶された情報を構成するため、および要求に応じて記憶された情報を表示するための、コンピュータネットワーク上の“電話”システムによる通信セッションを記録することができるような、システムおよび方法を提供する。
【課題を解決するための手段】
【０００８】
本発明の教示によれば、コンピュータネットワーク上の通信セッションを管理するための１つのシステムが提供される。このシステムは：（ａ）コンピュータネットワークに接続しかつそのコンピュータネットワークからデータパケットを受け取るためのネットワークコネクタ；（ｂ）データパケットをフィルタリングし、実質的にそのデータパケットが音声データおよび映像データから成るグループから選択されたデータを含む場合にだけそのデータパケットを受け入れるためのフィルタリングユニット、そのデータパケットは少なくとも通信セッションの１部分をなし、かつそのデータパケットは選択されたデータパケットである；（ｃ）選択されたデータパケットを受け取りかつその選択されたデータパケットを記憶するための管理ユニット、その選択されたデータパケットは記憶データパケットである；および（ｄ）管理ユニットから前記記憶データパケットを受け取りかつ記憶するための記憶媒体、通信セッションの少なくとも１部分が記憶される、を含む。
好ましくは、このシステムはさらに（ｅ）通信セッションの少なくとも１部分を引き出して表示するためのデータ復元ユニット、このデータ復元ユニットは管理ユニットを介して記録媒体からのデータパケットを要求する、そしてこのデータ復元ユニットは通信セッションの少なくとも１部分を表示するためにデータパケットを再構成する。
より好ましくは、このデータ復元ユニットはさらにその通信セッションの少なくとも１部分を表示するための通信セッション表示ユニットを含む。もっとも好ましくは、この通信セッション表示ユニットは、ビデオユニットおよびオーディオユニットから成るグループから選択される。
【０００９】
本発明の好ましい実施例によれば、このシステムはさらに（ｆ）フィルタリング情報を記憶するために前記フィルタリングユニットに接続されたデータベースを含み、フィルタリング情報は通信セッションが監視される相手のＩＰアドレスを少なくとも１つ含む。このフィルタリングユニットはフィルタリング情報に従ってデータパケットを受け入れる。本質的にデータパケットがフィルタリング情報を満たす場合にだけ、フィルタリングユニットはデータパケットを受け入れる。
好ましくは、このシステムはさらに（ｇ）少なくとも１つのユーザのコマンドを受け入れ、かつユーザに情報を表示するためのユーザコンピュータを含む。ユーザはその少なくとも１つのユーザのコマンドによりフィルタリング情報を決定する。
より好ましくは、コンピュータネットワークはＬＡＮ（ローカルエリアネットワーク）およびＷＡＮ（ワイドエリアネットワーク）から成るグループから選択される。もっとも好ましくは、コンピュータネットワークがＬＡＮ（ローカルエリアネットワーク）である。
【００１０】
本発明のさらに好ましい実施例によれば、ＬＡＮは少なくとも２つのセグメントに分割されており、システムがさらに（ｈ）各セグメントのためのローカル管理ユニット、このローカル管理ユニットはフィルタリングユニットと管理ユニットを含む、と（ｉ）それらのローカル管理ユニットを制御するための中央管理ユニット、この中央管理ユニットは記憶媒体中の記憶を制御する、を含む。
好ましくは、ネットワークコネクタはネットワークインタフェースカードである。
本発明のもう１つの実施例によれば、コンピュータネットワーク上で行われる通信セッションの少なくとも１部分を記憶するための方法が提供される。通信セッションはパケットの送信元とパケットの宛先の間で行われ、その方法のステップはデータ処理装置で行われる。この方法は：（ａ）コンピュータネットワーク上においてパケットの送信元からのパケットを受信する；（ｂ）データパケットがＩＰパケットであるかないか決定するためにデータパケットを解析する；（ｃ）データパケットがＩＰパケットである場合に、ＩＰパケットのタイプを決定するためにＩＰパケットをフィルタリングする；および（ｄ）タイプに従って記憶データパケットを構成するためにＩＰパケットを記憶する、その記憶データパケットは通信セッションの少なくとも１部分を構成する、ステップを含む。好ましくは、データパケットを解析するステップが、データパケットのヘッダを調べることにより行われる。
【００１１】
本発明の１実施例によれば、ＩＰパケットをフィルタリングするステップは、ＩＰパケットのヘッダを調べることにより行われる。
好ましくは、ＩＰパケットをフィルタリングするステップはさらに：（ｉ）ＩＰパケットのヘッダを調べてパケットの送信元のＩＰアドレスを決定する；（ii）そのＩＰアドレスが記録されたＩＰアドレスであるかないか決定する；(iii）実質的にＩＰアドレスが記録されたＩＰアドレスである場合にだけＩＰパケットを通して通過ＩＰパケットを形成する；（iv）そうでない場合にはＩＰパケットを放棄するステップを含む。
より好ましくは、ＩＰアドレスが記録されたＩＰアドレスであるかないか決定するステップが、そのＩＰアドレスをパケットの送信元からのＩＰアドレスのリストと比較することによって行われる。そのＩＰアドレスがそのリストに含まれている場合に、そのＩＰアドレスは記録ＩＰアドレスである。
また好ましくは、ＩＰパケットをフィルタリングするステップがさらに：（ｖ）通過ＩＰパケットがＨ.２２５パケット，Ｈ.２４５パケット，ＲＴＰパケットまたはＴＲＣＰパケットのどれであるか決定する；（vi）通過ＩＰパケットのタイプがＨ.２２５パケットである場合に、そのＨ.２２５パケットがセットアップパケットか接続パケットであるか決定する；（vii）そのＨ.２２５パケットがセットアップパケットである場合に、ステータスフラッグを“セッション開始要求”に設定する；（viii）他の場合として、そのＨ.２２５パケットが接続パケットであり、ステータスフラッグが“セッション開始要求”である場合に、その通信セッションの少なくとも１つの詳細を記憶する；および（ix）フラッグを“論理チャネル待ち”に設定するステップを含む。
【００１２】
より好ましくは、ＩＰパケットをフィルタリングするステップがさらに：（x）他の場合として、通過ＩＰパケットのタイプがＨ.２４５パケットである場合に、そのＨ.２４５パケットが論理チャネル開設要求パケット、論理チャネル開設確認パケットまたは端末能力設定パケットのどれであるか決定する；（xi）Ｈ.２４５パケットが論理チャネル開設要求パケットであり、かつステータスフラッグが“論理チャネル待ち”である場合に、ステータスフラッグを“確認待ち”に設定する；（xii）他の場合として、Ｈ.２４５パケットが論理チャネル開設確認パケットであり、かつステータスフラッグが“確認待ち”である場合に：（Ａ）ステータスフラッグを“端末能力待ち”に設定する；そして（Ｂ）その通信セッションの宛先のトランスポートアドレスを保存する；そして（xiii）また他の場合として、Ｈ.２４５パケットが端末能力設定パケットである場合に：（Ａ）その端末能力設定パケットからパケットの宛先の能力を記憶する；そして（Ｂ）ステータスフラッグを“通話中”に設定するステップを含む。
もっとも好ましくは、ステータスフラッグが“通話中”であり、かつ通過ＩＰパケットのタイプがＲＴＰパケットである場合に、そのＲＴＰパケットを記憶される。
【００１３】
本発明のもう１つの好ましい実施例によれば、この方法はさらに：（ｅ）記憶データパケットを引き出し、１つの引出しデータパケットを構成し；（ｆ）その引出しデータパケットにより通信セッションの少なくとも１部分を再構成するステップを含む。
好ましくは、データパケットを引き出すステップが：（ｉ）そのパケットの送信元の送信元ＩＰアドレス、その通信セッションの開始時間、およびその通信セッションの終了時間を受け取り；そして（ii）その送信元ＩＰアドレス、開始時間および終了時間に従って少なくとも１つの通信セッションを選択するステップを含む。
また好ましくは、通信セッションの少なくとも１部分を再構成するステップが音声データを表示することを含む。
別の方法でありかつ好ましくは、通信セッションの少なくとも１部分を再構成するステップが映像データを表示することを含む。
もっとも好ましくは、通信セッションの少なくとも１部分を再構成するステップがさらに：（ｉ）実質的にＲＴＰパケットだけを引き出す；（ii）それらのＲＴＰパケットのヘッダを調べて各ＲＴＰパケットのタイムスタンプを決定する；そして(iii）ＲＴＰパケットをそのタイムスタンプに従った順序で表示するステップを含む。
【発明を実施するための最良の形態】
【００１４】
本発明は、コンピュータネットワーク上のデータパケットを解析するため、音声および映像データパケットを選択的に記録するため、この記憶情報を整理するため、そして要求に応じて記憶情報を表示するための、コンピュータネットワークに基づく“電話”システムの通信セッションを記録できるような、システムおよび方法を提供する。
本発明による方法およびシステムの原理と動作は、図面とそれらの説明を参照することにより、より良く理解されるであろう。
図面を参照すると、図１はコンピュータネットワークを通じて行われる通信セッションからの音声および／または映像データを記録および表示するための代表的なシステムのブロック線図である。コンピュータログシステム１０は、通信セッション管理ユニット１３に接続されたユーザコンピュータ１２を主要な要素として含む。通信セッション管理ユニット１３はネットワークインタフェースカード（ＮＩＣ）１６を介して、イントラネット１４に接続されている。
ユーザコンピュータ１２は、ディスプレイユニット２０に表示されるユーザインタフェース１８を含む。ユーザインタフェースは、ＧＵＩ（グラフィッカルユーザインタフェース）が好ましい。ユーザインタフェース１８は、ユーザが、電話を監視および／またはログしたい相手の識別情報などの情報を入力することを可能にすることが好ましく、またユーザが通信セッションを引き出して表示するための少なくとも１つのコマンドを入力することを可能にすることが好ましい。
【００１５】
ディスプレイユニット２０は、好ましくはコンピュータのモニターである。ユーザは、データ入力装置２２でデータやコマンドを入力することにより、ユーザコンピュータ１２と対話することができる。データ入力装置２２は、好ましくは、少なくともキーボードまたはマウスのようなポインティングデバイスを含む。本発明の１つの好ましい実施例によれば、ユーザコンピュータ１２はＰＣ（パーソナルコンピュータ）である。それに代わるものでかつ好ましいものは、ＩＰに基づくネットワーク上で通信可能なコンピュータであるネットコンピュータのような“thin client”である。このようなネットコンピュータの１例はJavaStationTM（Sun Microsystems）である。このようなネットコンピュータの利点は、ユーザが複雑で高性能のソフトウェアプログラムと対話することを可能にしながら、通常現在入手可能なＰＣコンピュータの強力な計算能力の全てを持たないことである。
イントラネット１４は例えばＬＡＮまたはＷＡＮである。通信セッション管理ユニット１３とイントラネット１４の間の接続は、ＮＩＣ１６を介して発生する。ＮＩＣ１６は、通信セッション管理ユニット１３を適当なコンピュータネットワーク（例えば、3-ComTMのEtherlinkII ISA/PCMCIA AdapterまたはEtherlinkIII PCI Bus-Master AdapterまたはNovellTMのNE2000 Adapter、または他の同様の適当な製品）に接続できる標準的な市販品が好ましい。このような適当なコンピュータネットワークの例は、イーサネット（ＩＥＥ標準規格８０２.３）、高速イーサネット（ＩＥＥ標準規格８０２.１０）、トークンリング（ＩＥＥ標準規格８０２.５）およびＦＤＤＩなどの標準的なＬＡＮを含むが、それらに限定されない。
【００１６】
イントラネット１４上の全てのデータパケットのトラフィックは、ＮＩＣ１６を通してフィルタリングモジュール２４に伝えられる。下記の図３においてより詳しく示されているように、フィルタリングモジュール２４は、どのデータパケットが次の判断基準を満たすか決定するために、それらのデータパケットを調べる。簡潔に言えば、データパケットは、音声および／または映像のトラフィックであることを示すＨ.２２５またはＨ.２４５標準規格に従ったヘッダーを持つＩＰパケットでなければならない。先述したように、これらの標準規格は、テレビ電話システムのためのメディアストリームのパケット構造と同期、およびマルチメディア通信のための制御プロトコルを規定する。
フィルタリングモジュール２４は、実質的にこれらの判断基準を満たすデータパケットだけを管理モジュール２８に渡すことが好ましい。下記の図７に示されている本発明のシステムのゾーン構成において、フィルタリングモジュール２４は、他の通信セッション管理ユニットからのメッセージも転送することが好ましい。
管理モジュール２８は、フィルタリングモジュール２４によって通過させられたデータパケットを受け取り、その受け取ったデータパケットを解析する。任意でありかつ好ましくは、データベース２６は、例えば各相手に少なくとも１つのＩＰアドレスを対応させた変換表と共に、その通信セッションをログすべき相手のＩＰアドレスのような情報を記憶する。電話をログしたい相手を表すＩＰアドレスの記憶リストは、ユーザによって定義されることが好ましい。この明細書中で使用されているように、「相手」という語は、コンピュータネットワーク上の電話システムを通じて通信している１人または複数の人を言う。後者の好ましい要求は、ユーザが関心のあるデータだけを含めることにより、記憶されるデータの量を著しく少なくする。管理モジュール２８は、背景技術の説明のところに上記したように、Ｈ.２４５制御機能、ＲＡＳシグナリング機能およびコールシグナリング機能を含む，適用可能なＨ.２２５およびＨ.２４５の仕様に従って、データを解析しかつ管理する。
【００１７】
管理モジュール２８は、そられのデータパケットを、それらが属する通信セッション、使用されているデータ圧縮のタイプ（もし使用されていれば）、監視されるべきＩＰアドレスから送信されたかそうでないか決定するために解析する。フィルタリングモジュール２４は単に上で簡単に説明した判断基準を満たす全てのデータパケットを通過させるだけなので、管理モジュール２８がこの解析をしなければならない（より詳細は図３Ａ−図３Ｄを参照）。これらのパケットはデータベース２６に記憶されている情報のどれも考慮することなく通されるので、管理モジュール２８は、その受信パケットが記憶しなければならないものかそうでないか決定するために、データベース２６のルールを各パケットのパケットヘッダに在る情報と比較する。
データベース２６のルールを満たす受信パケットは、次に記憶媒体３０に記憶される。この記憶媒体は大容量のデジタルデータ記憶装置が好ましく、ハードディスク磁気記憶装置、光ディスク、ＣＤ−ＲＯＭ、ＺＩＰ、またはＤＡＴカセット、または特定の用途の運用の必要性に応じたそれらの組み合わせ、または他の適当な媒体である。好ましくは、各データパケットが関係づけられる特定の通信セッションすなわち“電話の呼出し”も、そのセッションを後で再構成して表示するために記憶される。
ユーザによる要求があると、管理モジュール２８は、それにより、記憶媒体３０から１つまたは複数の通信セッションに関係づけられる１つまたは複数のデータパケットを引き出すことができる。引き出されたパケットは、次にデータ復元モジュール３２に転送される。データ復元モジュール３２は、ＲＴＰ（リアルタイムプロトコル）を使って個別の通信セッションを復元するために、これらの引き出されたパケットを操作できることが好ましい。図４Ｃと図５に関して以下にさらに詳しく説明されるように、ＲＴＰに従うそれらのシステムにおいては、データパケットはただ順序番号だけでなく、ヘッダ中にタイムスタンプを入れて送信される。このようなタイムスタンプは、データパケットがデータのストリームの全体の時間関係が維持されるように再組立てされるためには、音声および映像のストリームデータにとって必要である。このようなタイムスタンプ無しでは、正しい時間関係は維持されないであろう。そして音声または映像ストリームは正確に再構成することができないであろう。
【００１８】
通信セッションは、使用可能なオーディオおよび／またはビデオコーデックを用いて、再構成されたデータパケットのストリームから復元される。コーデックはアナログデータとデジタルデータの変換のための非線形の方法である。例えば、あるオーディオコーデックは、関係するデータパケット中のデジタル化された音声データを、例えば可聴音としてユーザに表示するためのアナログデータに変換することを可能にする。適当なコーデックについて、図５に関連して以下に詳しく説明する。
ユーザが再構成された通信セッションの表示を受けるために、システム１０は、まとめて“通信セッション表示ユニット”と呼ばれているオーディオユニット３４とビデオユニット３６を主要な要素として含むことが好ましい。さらに好ましいのは、オーディオユニット３４およびビデオユニット３６の両方とも、それぞれが、音声入力または映像入力を取り込むことができかつ音声または映像出力を表示できることである。少なくとも、オーディオユニット３４およびビデオユニット３６は、それぞれ、音声または映像出力を表示できなくてはならない。例えば、オーディオユニット３４は、入力のためのマイクロフォンを選択的に含み、また出力のためのスピーカーまたはイヤフォンを含むことができる。ビデオユニット３６は、出力のためのビデオモニターまたは表示画面を含み、また入力のためのビデオカメラを選択的に含むことができる。
【００１９】
図２は図１のシステム１０の概略ブロック線図であり、システム１０のソフトウェアモジュールの全体的な構成をより詳細に示す。そうするのが適当なところでは、異なるタイプのデータパケットのヘッダの構成図（図４Ａ−図４Ｄ）に加えて、これらのソフトウェアモジュールの動作をより詳細に示すフローチャート（図３Ａ−図３Ｄ）を参照する。
図示のように、システム１０は再びＮＩＣ１６を介したイントラネット１４への接続を含む。パケットがイントラネット１４で送信されるとき、ＮＩＣ１６はこれらのデータパケットを傍受し、それらをフィルタリングモジュール２４に向けて通過させる。
フィルタリングモジュール２４は２つの構成部分を持つ。第１のフィルタリング部３８は、そのデータパケットのヘッダを調べる。データパケットは、下記の図４Ａに示されているような、正しいヘッダを持つＩＰタイプのパケットでなければならない。次に、第１のフィルタリング部３８は、そのデータパケットを第２のフィルタリング部４０に渡す。第２のフィルタリング部４０は次にＩＰデータパケットのタイプを決定する。ＩＰデータパケットのタイプは、Ｈ.２２５，Ｈ.２４５，ＲＴＰまたはＲＴＣＰ標準規格に従って構成され得るものである。
【００２０】
図３Ａを参照して示されるように、第１のフィルタリング部３８と第２のフィルタリング部４０は次のように動作する。ステップ１において、１つのパケットがフィルタリングモジュール２４により受け取られる。このパケットは第１のフィルタリング部３８に与えられ、第１のフィルタリング部３８は次にステップ２においてそのパケットがＩＰタイプのパケットであるか否か決定する。この決定は、そのデータパケットのヘッダの構成に従って行われる。ヘッダの１例が図４Ａに示されている。ヘッダ４２は複数の箱として示されており、それらの各々はヘッダの１部分すなわち“フィールド”を表している。各部分により占められるバイト数も示されており、各層は３２ビットから成ることが理解されるであろう。ヘッダの最初の部分、“バージョン番号”部４４は、プロトコルのバージョン番号である。次に“ヘッダ長”部４６は、ヘッダ中の３２ビット量の数を示す。“サービスタイプ”部４８は、送り手が、そのデータグラムが遅延が最小になるルートを進むことを好むか、またはスループットが最大になるルートを進むことを好むかを示す。“全長”部５０は、ヘッダおよびデータの両方中のオクテットの合計数を示す。
次の層において、“識別情報”部５２は、そのパケット自体の身元を示す。“フラッグ”は、そのデータグラムが１部分であるか、完全なデータグラムであるかを示す。“フラグメントオフセット”部５６は、元のデータグラム中のこの部分の場所を示す。次の層において、“生存時間”部５８は、１と２５５の間の正の整数を含み、この整数は進行した各ルートにおいて漸次に減じられる。その値が０になったとき、パケットはもはや伝送されず、送信者に戻される。“タイプ”部６０は、伝送されているデータのタイプを示す。“ヘッダチェックサム”部６２は、実際のチェックサムをこの部分６２の中に記録されている値と比較することによりパケットの完全性をチェックすることを可能にする。
【００２１】
ヘッダ４２の次の層は送信元のＩＰアドレスを含み、その次の層は宛先のＩＰアドレスを含む。続いて任意のＩＰオプション部６８があり、その後に埋草（必要な場合）があり、そしてデータを含むパケットのデータ部７０が始まる。
データパケットのヘッダの構成が第１のフィルタリング部３８によって調べられ、このヘッダが必要なデータフィールドを正しい順番で持つかどうか、すなわちデータパケットのヘッダがヘッダ４２に一致するかどうか決定される。第１のフィルタリング部３８は、ステップ３Ａに示されるように、正しいヘッダ構成を持つパケットだけを通過させる。そうでなければ、そのパケットは、ステップ３Ｂに示されるように放棄される。
正しいヘッダを持つパケット、すなわち“ＩＰパケット”は、次に第２のフィルタリング部４０に渡される。第２のフィルタリング部４０はフィルタリングステップの残りを行う。ステップ３Ａにおいて、第２のフィルタリング部４０は、ＩＰパケットを調べて、図４Ａに示されるようなパケットのデータ部からそれらのタイプを決定する。パケットは、Ｈ.２２５，Ｈ.２４５，ＲＴＣ，ＲＴＣＰのどれかである。Ｈ.２２５パケットのための方法のステップは図３Ａに示されており、それ以外のパケットタイプのための方法が、それぞれ、図３Ｂ−図３Ｄに示されている。
【００２２】
パケットのタイプが決定されると、図２に示されるように、パケット自体とパケットのタイプに関する情報の両方が、管理モジュール２８に渡される。パケットは、行われるべき記録工程のために、図２にも示されるように、管理モジュール２８内の関係する構成部分に渡される。記録されたパケットは、図３Ｃおよび３Ｄに関して以下に詳細に説明されるように、記憶モジュール３０に記憶される。
パケットがパケットのヘッダに従ってＨ.２２５パケットであると決定された場合には（図４Ｂ参照）、そのパケットは、図２に示されるように、管理モジュール２８内のＨ.２２５呼出し制御モジュール７８に渡される。管理方法のステップは、図３Ａを参照しながら、下記の通りである。図３Ａのステップ４Ａにおいて、そのＨ.２２５パケットがセットアップパケットであるかどうか調べられ、パケット中のデータの構成に従って決定される。この構成はＨ.２２５.０推奨に規定されており、少なくとも下記のタイプの情報を含む。
プロトコル識別子（サポートされるＨ.２２５.０のバージョン）
ｈ２４５アドレス（Ｈ.２４５信号が発呼側の端点またはゲートキーバーによりそこに確立されるべき特定のトランスポートアドレス）
送信元アドレス（送信元のためのＨ.３２３＿ＩＤ）
送信元情報（着呼側がその呼がゲートウェイを含むか含まないか決定することを可能にするための端点のタイプを含む）
宛先アドレス（その端点が接続されることを欲するアドレスである）
Ｈ.２２５.０に規定されるように、他のタイプのデータも必要とされる。このデータ構成は、Ｈ.２２５呼制御モジュール７８が、パケットがセットアップパケットであるかどうか決定することを可能にする。
【００２３】
このパケットがセットアップパケットの場合には、この方法の第１の分枝を辿る。まずＨ.２２５ヘッダ７２の送信元ポートフィールド７４から送信元ポートが取り出され、また宛先ポートフィールド７６から送信元ポート７６が取り出される（図４Ｂ）。ステップ５Ａにおいて、対応する端末のどれかが記録端末として指定されているかどうか、すなわちこの端末のＩＰアドレスによって開始された通信セッションが監視されるべきかどうか決定するために、図１のデータベース２６が調べられる。指定されている場合は、ステップ６Ａにおいて、端末のステータスが、送信元ポートに対応する端末からのセッション開始要求に設定される。
セットアップパケットでない場合には、そのパケットは、ステップ４Ｂにおいて、接続パケットであるか調べられ、パケット中のデータの構成により決定される。この構成はＨ.２２５.０推奨に規定されており、少なくとも下記のタイプの情報を含む。
プロトコル識別子（サポートされるＨ.２２５.０のバージョン）
ｈ２４５アドレス（Ｈ.２４５信号が発呼側の端点またはゲートキーバーによりそこに確立されるべき特定のトランスポートアドレス）
宛先情報（呼出し側がその呼がゲートウェイを含むか否かを決定することを可能にするための端点のタイプを含む）
会議ＩＤ（その特定の会議を識別するための唯一の識別番号を含む）  
【００２４】
パケットが接続パケットの場合には、この方法の第２の分枝を辿る。ステップ５Ｂにおいて、端末のステータスがセッション開始要求に設定されているかどうか決定するために、端末のステータスを示すフラッグが調べられる。ステップ６Ｂにおいて、呼信号の詳細情報が記憶媒体３０の呼進行データベース７８に保存される（図２参照）。これらの詳細情報は、送信元および宛先のアドレス、送信元および宛先のポート、その通信セッションが開始された時刻、その他の関係する情報を含むことが好ましい。ステップ７Ｂにおいて、端末のステータスが“論理チャネル待ち”に設定される。
第２のフィルタリング部４０によってパケットがＨ.２４５パケットであると決定された場合には、図２に示されているように、そのパケットは管理モジュール２８内のＨ.２４５呼制御モジュール８２に渡される。このようなＨ.２４５パケットは、Ｈ.２４５信号のために必要である。Ｈ.２４５信号は２つの端点、すなわち１つの端点と１つのマルチポイントコントローラ、または１つの端点と１つのゲートウェイ、の間に確立される（例えば以下の図６と図７およびこのような端点の説明を参照）。各端点は通信セッションの１方として、呼び出すことおよび呼び出されることができる。しかしながら、本発明のシステムは、このような通信セッションを開始するのでなく、監視するだけである。例えば、本発明のシステムは、記憶および後のセッションの再構成のために必要なデータパケットを効率的に記録するために、Ｈ.２４５信号を使ってその通信セッションがいつ始まったかを決定する。
Ｈ.２４５パケットの管理方法のステップは、図３Ｂを参照しつつ、下記のとおりである。図３Ｂのステップ１Ａにおいて、Ｈ.２４５パケットは、論理チャネル開要求パケットであるかどうか決定するために調べられる。そうである場合には、ステップ２Ａにおいて、ステータスが“論理チャネル待ち”であるかどうか決定するために、端末のステータスが調べられる。そうである場合には、ステップ３Ａにおいて、端末のステータスが“確認待ち”に設定される。
【００２５】
他の場合には、ステータス１Ｂに示されるように、論理チャネル開確認パケットであるかどうか決定するために調べられる。そうである場合には、ステップ２Ｂにおいて、ステータスが“確認待ち”であるかどうか決定するために、端末のステータスが調べられる。そうである場合には、ステップ３Ｂにおいて、端末のステータスが“端末能力待ち”に設定される。ステップ４Ｂにおいて、被呼側すなわち宛先端末のトランスポートアドレスが保存される。このトランスポートアドレスは、ヘッダ７２の宛先ポートフィール７６から取り出される（図４Ｂ参照）。Ｈ.２２５およびＨ.２４５パケットは同じヘッダ構成を持つことに気づかれたい。
さらに別の場合には、ステップ１Ｃにおいて、端末能力設定パケットであるかないか決定するために、そのＨ.２４５パケットが調べられる。そうである場合には、ステップ２Ｃにおいて、端末の能力が呼進行データベース８０に保存される（図２参照）。ステップ３Ｃにおいて、端末のステータスが、通信セッションが開かれることが決定されかつ管理モジュール２８がＲＴＰデータパケットを受信することができる“呼進行中”に設定される。
第２のフィルタリング部４０によってパケットがＲＴＰパケットであると決定された場合には、図２に示されるように、そのパケットは、管理モジュール２８内のＲＡＳ(レジストレーション、アドミッションおよびステータス）制御モジュール８４に渡される。
【００２６】
ＲＴＰパケットの管理方法のステップは、図３Ｃを参照しつつ、下記のとおりである。図３Ｃのステップ１において、端末のステータスが“呼進行中”であるかどうか調べられる。そうである場合には、ステップ２において、そのＲＴＰパケットが記憶媒体３０内のＲＴＰデータベース８６に保存される（図２参照）。図４ＣはＲＴＰパケットのヘッダの構成を示す。このヘッダは、そのパケットがそれから取り出された通信セッションを特定するために使うことができる。
最後に、第２のフィルタリング部４０によってパケットがＲＴＣＰパケットであると決定された場合には、図２に示されるように、そのパケットは、管理モジュール２８内のＲＴＣＰ制御モジュール８８に渡される。ＲＴＣＰパケットの管理方法のステップは、図３Ｄを参照しつつ、下記のとおりである。図３Ｄのステップ１において、端末のステータスが“呼進行中”であるかどうか調べられる。そうである場合には、ステップ２において、そのＲＴＣＰパケットが、記憶媒体３０内の呼進行データベース８０に保存される（図２参照）。図４ＤはＲＴＣＰパケットのヘッダの構成を示す。このヘッダは、そのパケットがそれから取り出された通信セッションを特定するために使うことができる。
このように、図３Ａ−図３Ｄは、図１および図２に示されている本発明のシステムにより記録された、記録された通信セッションを構成するデータパケットのフィルタリングと記憶に関する本発明の方法を説明している。もちろん、このような通信セッションを記録することに加えて、本発明のシステムはこれらの通信セッションを引き出してユーザに対して再生することもできる。記憶されたデータパケットから構成される記憶された通信セッションは、図２のデータ復元ユニット３２により引き出され、オーディオユニット３４およびビデオユニット３６と共同して再生される。関心を持つセッションを引き出して再生するための方法が図５に示されており、本発明のシステムの他の関係する部分が図２に示されている。
【００２７】
図５のステップ１において、ユーザは、引き出して再生しようとする通信セッションに関する情報を入力する。この情報は、端末番号、関心を持つ通信セッションの電話をかけた側とかけられた側のうち少なくとも１方に関する他の指定情報、そのセッションが始まった時刻、そのセッションが終了した時刻を含むことが好ましい。しかしながら、関心のある通信セッションを特定するために十分な情報が与えられるかぎり、この情報の代わりに、別の情報を含めることもできる。
図５のステップ２において、指定された時間範囲内の通信セッション（１つまたは複数）の詳細情報を見つけるために、データ復元ユニット３２により、呼進行データベース８０（図２参照）が検索される。これらの詳細情報は、次に、その呼範囲内の、少なくとも１つの関心が持たれている通信セッションを特定するために、ユーザにより入力された情報と比較される。
ステップ３において、指定された呼範囲中の少なくとも１つの通信セッションからのほぼ全てのデータパケットを見つけるために、再びデータ復元ユニット３２により、記憶媒体３０（図２参照）のＲＴＰデータベース８６が検索される。任意でありかつ好ましくは、ステップ４において、音声部分の通信セッションがステレオで記録される場合には、そのデータパケットはオーディオチャネル別に分けられる。
【００２８】
ステップ５において、データパケットは、データ復元ユニット３２により、データ復元ユニット３２内のＲＴＰ（リアルタイムプロトコル）ソフトウェアモジュール９１で復元される。ＲＴＰソフトウェアモジュール９１は、各チャネル内のデータパケットを、個々のパケットのタイムスタンプに従って順序づける。図４Ｃに示されているように、ＲＴＰパケットのヘッダ９２は、幾つかの重要なフィールド、すなわちタイムスタンプフィールド９４，同期源（ＳＳＲ）識別情報フィールド９６および貢献源（ＣＳＲＣ）識別情報フィールド９８を含む。ＳＳＲＣフィールド９６は、唯一の識別アドレス（ＳＳＲＣ識別情報）を持つＲＴＰパケットの発信源（送信側）を決定するために使用される。ＣＳＲＣフィールド９８のＣＳＲＣ識別情報は、複数人による会議において使用され、すべての参加者のＳＳＲＣ識別情報を示す。タイムスタンプフィールド９４は、ＲＴＰソフトウェアモジュール９１により、各パケット中のデータが表示されるべき相対時間を決定するために使われる。
例えば、ある人の話の音声ストリームは、映像ストリーム中に示されるその人の唇の動きに同期させられるのが好ましく、“唇同期”として知られている処理である。このような同期は、単に音声データと映像データをある相対時間点で再生する以上のことが要求される。なぜならその音声データと映像データは、同時に到着しないかも知れないし、そのために僅かに異なるタイムスタンプを持つかも知れないからである。
【００２９】
データパケットが正しく同期させられたら、音声データの表示の制御は、１つまたは複数のオーディオコーデックに従って、データ復元ユニット３２のオーディオ部１０２によって行われる（図２参照）。ビデオデータの表示の制御は、１つまたは複数のビデオコーデックに従って、データ復元ユニット３２のビデオ部１０４によって行われる（図２参照）。
適当なコーデックには下記のものが含まれるが、それらに限定されるわけではない。ＣＣＩＴＴ推奨Ｇ.７１１（１９８８），音声周波数のパルス符号変調（ＰＣＭ）を使ったオーディオコーデック、ＣＣＩＴＴ推奨Ｇ.７２２（１９８８），６４キロビット／秒以内の７kHzオーディオコーディングを使ったオーディオコーデック、ＩＴＵ―Ｔ推奨Ｇ.７２３.１（１９９６），音声符号器を使ったオーディオコーデック、５.３または６.３ Kbpsで送信するマルチメディア通信のための２速音声符号器、ＣＣＩＴＴ推奨Ｇ.７２８（１９９２），低遅延符号励起線形予測を用いる１６Kbpsの音声の符号化を使ったオーディオコーデック、ＩＴＵ―Ｔ推奨Ｇ.７２９（１９９６），共役構成代数的符号―励起線形予測（ＣＳ−ＡＣＥＬＰ）を使った８Kbpsの音声の符号化を使ったオーディオコーデック、ＩＴＵ―Ｔ推奨Ｈ.２６１（１９９３），ｐｘ６４キロビット／秒の音声映像サービスのためのビデオコーデック、ＩＴＵ―Ｔ推奨Ｈ.２６３（１９９６），低ビットレート通信のための映像符号化、および殆どすべての他の同様の符号化の標準規格。
【００３０】
図２に示されるように、音声データは、例えば拡声器を含んでもよいオーディオユニット３４により表示される。映像データは、例えばディスプレイモニタ画面を含んでもよいビデオユニット３６により表示される。図５のステップ５は、通信セッションのほぼ全体が表示されるように、繰り返されるのが好ましい。ステップ６に示されるように、通信セッションの各データパケットは、呼時間が終了したかどうか知るために調べられる。個々のセッションが完了していない場合には、ステップ５が繰り返されることが好ましい。その代わりにかつ好ましくは、ステップ７に示されるように、その指定された時間区間内に他のセッションが記録されていないか呼進行データベース８０を検索することである。少なくとも１つの他のこのような通信セッションが在る場合には、図５の方法がステップ２から始めて繰り返されることが好ましい。
本発明の好ましい実施例によれば、幾つかの構成のコンピュータログ生成システムが可能であり、その数例が図６および図７に示されている。
【００３１】
図６に示されている本発明のシステムの第１の実施例によれば、代表的な基本構成システム１０４は、本発明による、図１および図２に示されるものとほぼ同じ、１つの通信セッション管理ユニット１３を含む。通信セッション管理ユニット１３は、ＬＡＮ１０６のようなスタンド−アロンイントラネット内の通信を管理する。ＬＡＮ１０６は、通信セッション管理ユニット１３と、“Ｔ１”，“Ｔ２”および同様に示されている複数の端末１０８の両方に接続されており、それらはＨ.３２３に従っている。各端末１０８は、他の端末１０８，ゲートウェイ１１０またはマルチポイント制御ユニット１１２とのリアルタイム双方向通信が可能なＬＡＮ１０６上の端点である。この通信は、制御、指示、ステップストリーム、ビデオストリームおよび／またはデータから構成される。端末１０８は、音声のみ、音声とデータ、音声と映像、または音声、データ、映像のための同様の通信を提供することができてもよい。“背景技術の説明”の部分で先に言及したように、Ｈ.３２３装置は“ＬＡＮ電話”として音声および／または映像通信を提供することができる端末であってもよいし、スタンドアロンの音声またはテレビジョン電話であってもよい。
ゲートウェイ１１０（ＧＷ）はＨ.３２３に従って構成され、端末１０８およびＷＡＮ（示されていない）上の他の適する端末との間の、または別の同様のゲートウェイ（示されていない）に対するリアルタイム双方向通信を提供するＬＡＮ１０６上の端点である。他の適する端末には、推奨Ｈ.３１０（Ｂ−ＩＳＤＮ上のＨ.３２０），Ｈ.３２０（ＩＳＤＮ），Ｈ.３２１（ＡＴＭ），Ｈ.３２２（ＧＱＯＳ−ＬＡＮ），Ｈ.３２４（ＧＳＴＮ），Ｈ.３２４Ｍ（移動）およびＶ.７０（ＤＳＶＤ）などが含まれる。
【００３２】
マルチポイント制御ユニット（ＭＣＵ）１１２は、３またはそれ以上の端末１０８とゲートウェイ１１０が多点会議に参加することを可能にするＬＡＮ１０６上の端点である。
システム１０４もまた、端末１０８，ゲートウェイ１１０およびＭＣＵ１１２に対して、アドレス変換を提供しかつＬＡＮ１０６へのアクセスを制御するＬＡＮ１０６上の端点である、ゲートキーパー（ＧＫ）１１４を主要な要素として含むことが好ましい。ゲートキーパー１１４は、端末１０８，ゲートウェイ１１０およびＭＣＵ１１２に対して、帯域幅の管理やゲートウェイ１１０の特定などの他のサービスを提供してもい。ゲートキーパー１１４は、正しいＩＰアドレスが“自動的に”決定されることができるように、ＬＡＮ上の端末１０８のＩＰアドレスの決定を可能にすることが好ましい。
さらに、ＬＡＮ１０６は、電子白板、正画像転送、ファイル交換、データベースアクセスのような標準のＴ.１２０データアプリケーションのための非音声映像装置をサポートしてもよい。
【００３３】
基本システム１０４では、単一のスタンドアロン通信セッション管理ユニット１３が、ＬＡＮ１０６に接続された任意の２またはそれ以上の端末１０８の間の全ての音声および／または映像通話、または１またはそれ以上の端末１０８が１方の側である全ての通話の監視、ログの生成、引き出しのために使用されている。しかしながら、図７のシステムに対してと同様に、ゲートキーパー１１４を含む好ましい実施例である図６のシステムに対しても、ひとたび通信セッションが開かれたら、システムの構成のために必要である場合には、ＲＡＳ制御モジュール８４も、管理制御モジュールとＮＩＣ１６の間のＲＡＳシグナリング（通知）を行う。このシグナリングは、端点とゲートキーパーの間の登録、アドミッション、バンド幅の変更、ステータス、解放処理を行うために、Ｈ.２２５.０メッセージを使用する。これらのメッセージは、呼出シグナリングチャネルおよびＨ.２４５制御チャネルから独立の、ＲＡＳシグナリングチャネル上を通される。Ｈ.２４５の論理チャネル開手続きは、このＲＡＳシグナリングチャネルを開設するためには使われない。ゲートキーパーを含むＬＡＮ環境（ゾーン）の中では、ＲＡＳシグナリングチャネルは、端点とゲートキーパーの間に開かれる。ＲＡＳシグナリングチャネルは、Ｈ.３２３端点間のどのような他のチャネルの開設に先だって開かれる。
【００３４】
図７は本発明のシステムの第２の実施例をゾーン構成システム１１６として示す。ゾーン１１８は、単一のゲートキーパー（ＧＫ）１１４によって管理される全ての端末（Ｔｘ）１０８，ゲートウェイ（ＧＷ）１１０およびマルチポイント制御ユニット（ＭＣＵ）１１２の集合である。ゾーン１１８は少なくとも１つの端末１０８を含むが、１つまたは複数のゲートウェイ１１０またはＭＣＵ１１２は必ずしも含まなくてもよい。ゾーン１１８は、示されるように、ただ１つのゲートキーパー１１４を持つ。しかしながら、示されている好ましい実施例において、ゾーン１１８は、ＬＡＮのトポロジ―とは独立しており、示されているルータ（Ｒ）１２２または他の同様の装置を使って接続された複数のＬＡＮセグメント１２０を含むことが好ましい。
各監視されるＬＡＮセグメントは、本発明によるローカル通信管理ユニット１２４を持ち、その２つが示されている。本発明による中央管理ユニット１２６は、全てのローカル通信管理ユニット１２４を制御する。集中化されたデータベースと制御サービスに加えて、中央管理ユニット１２６は、単一の点からの音声および／または映像通信のリアルタイムの監視とオフラインの復元を行うために使用できる。中央管理ユニット１２６は、ローカル通信管理ユニット１２４と構成は似ているが記憶能力を持たない専用のユニットでもよいしかつ好ましい。またはローカル通信管理ユニット１２４と統合されていて、単一のステーションでローカル通信管理ユニット１２４と中央管理ユニット１２６の両方の機能を提供してもよくかつ好ましい。ローカル通信管理ユニット１２４は図１および２に示されているものとほぼ同じ通信管理ユニット１３であってもよいし、ローカルに通信セッションを引き出して表示するための能力を持たない、より簡単なユニットでもよい。
【００３５】
本発明のさらに他の好ましい実施例（示されていない）においては、基本システム１０４およびゾーン１１６にたいして、クライアント／サーバアーキテクチャに基づくマルチユーザ運用がサポートされることが好ましい。無制限の数の“クライアント”ステーションを、各ユーザの権限のレベルに従って決定される管理および監視／引出しの能力をユーザに提供しながら、ＬＡＮのどこにでも接続できる。
上記の説明は例として役立つことのみ意図されたものであり、本発明の趣旨と範囲の中で多数の他の実施例が可能であることは理解されるであろう。
【００３６】
なお、この明細書においては、“通信セッション”という語は、少なくとも２つのパーティが“リアルタイム”で音声および／または映像情報を交換することにより話をする会話、または少なくとも１つのパーティが、少なくとも１つの他のパーティが後で受信できるように同様の音声および／または映像情報を記録するメッセージの両方を含む。
この明細書において、“インターネット”という語は、世界中の全てのコンピュータを接続するために使用される世界的な規模の、数千のネットワークのリンクされたウエッブを一般的に言うために使用される。この明細書で使用されているように、“イントラネット”という語は、ＬＡＮ（ローカルエリアネットワーク）やＷＡＮ（ワイドエリアネットワーク）のような他のタイプのコンピュータネットワークを含み。“コンピュータネットワーク”という語は、少なくとも２つのコンピュータの間のデータの送信が可能なすべての接続を含み、インターネットもイントラネットも含まれる。“レギュラーテレフォンネットワーク（普通の電話網）”という語は、ＰＯＴＳ（プレインオールドテレフォンシステム：普通の古い電話システム）および普通の電話サービス提供業者を通じてサービスを提供する殆どすべての他のタイプの電話ネットワークを含むが、いかなるタイプのコンピュータネットワークであってもそれを通じて行われる音声および／または映像通信は明確に含まない。
【００３７】
この明細書において、“コンピュータ”という語は、ＤＯＳ，WindowsTM，OS/2TMまたはLinuxのようなＯＳを持つパーソナルコンピュータ（ＰＣ）；MachintoshTMコンピュータ；オペレーティングシステムとしてJAVATM−OSを持つコンピュータ；およびSun MicrosystemsTMやSilicon GraphicsTMのコンピュータのようなグラフィックワークステーション、およびSun MicrosystemsTMのAIXやSOLARISTMのようなUNIXオペレーティングシステムのバージョン，またはその他の知られており入手可能なオペレーティングシステムを持つ他のコンピュータを含む。この明細書において、“WindowsTM”という語は、Windows95TM, Windows3.xTM ただし“x”は“１”のような整数、Windows NTTM, Windows98TM, Windows CETMおよびMicrosoft社（米国ワシントン州シアトル）によるこれらのオペレーティングシステムのアプグレードされたバージョンを含むが、それら限定されない。
この明細書において、“ログ（記録）”という語は、ネットワーク上のデータパケットを解析して音声および／または映像データを見つけ出し、それらのデータを組織化されたシステムに記録する処理を言う。この明細書において、“表示（ディスプレイ）”という語は、映像データの視覚表示と音声データのための音の発生の両方を含む。
【図面の簡単な説明】
【００３８】
【図１】本発明による通信セッション監視システムの一例の概略のブロック線図である。
【図２】図１のシステムを動作させるために必要なソフトウェアモジュールの概略のブロック線図である。
【図３Ａ】本発明によるフィルタリングおよび記録方法の１例のフローチャートである。
【図３Ｂ】本発明によるフィルタリングおよび記録方法の１例のフローチャートである。
【図３Ｃ】本発明によるフィルタリングおよび記録方法の１例のフローチャートである。
【図３Ｄ】本発明によるフィルタリングおよび記録方法の１例のフローチャートである。
【図４Ａ】本発明に関係する、Ｈ.２２５パケットのヘッダを示す概略のブロック線図である。
【図４Ｂ】本発明に関係する、Ｈ.２４５パケットのヘッダを示す概略のブロック線図である。
【図４Ｃ】本発明に関係する、ＲＴＰパケットのヘッダを示す概略のブロック線図である。
【図４Ｄ】本発明に関係する、ＲＴＣＰパケットのヘッダを示す概略のブロック線図である。
【図５】本発明による通信セッションの再生方法の１例のフローチャートである。
【図６】本発明による図１および２の通信セッション監視システムを使った基本的なシステムの第１の実施例の概略のブロック線図である。
【図７】本発明によるゾーンシステムの第２の実施例の概略のブロック線図である。
【符号の説明】
【００３９】
１０  コンピュータ記録システム（システム、１２  ユーザコンピュータ、１３通信セッション管理ユニット（通信管理ユニット）  １４  イントラネット、１６  ネットワークインタフェースカード（ＮＩＣ）、１８  ユーザインタフェース、２０  ディスプレイユニット、２２  データ入力装置、２４  フィルタリングモジュール、２６  データベース、２８  管理モジュール、３０  記憶媒体（記憶モジュール）、３２  データ復元モジュール（データ復元ユニット）  ３４  オーディオユニット、３６  ビデオユニット、３８  第１のフィルタリング部、４０  第２のフィルタリング部、４２  ヘッダ、４４  “バージョン番号”部、４６  “ヘッダ長”部、４８  “サービスタイプ”部、５０  “全長”部、５２  “識別”部、５６  “フラグメントオフセット”部、５８  “生存時間”部、６０  “タイプ”部、６２  “ヘッダチェックサム”部、６８  ＩＰオプション部、７０  データ部、７２  ヘッダ、７４  送信元ポートフィールド、７６  宛先ポートフィールド（送信元ポート）、７８  呼出し制御モジュール（呼制御モジュール、呼進行データベース）、８０  呼進行データベース、８２  呼制御モジュール、８４  ＲＡＳ(レジストレーション、アドミッションおよびステータス)制御モジュール、８６  ＲＴＰデータベース、８８  ＲＴＣＰ制御モジュール、９１  ＲＴＰ（リアルタイムプロトコル）ソフトウェアモジュール、９２  ヘッダ、９４  タイムスタンプフィールド、９６  同期源（ＳＳＲ）識別情報フィールド、９８  貢献源（ＣＳＲＣ）識別情報フィールド、１０２  オーディオ部、１０４  ビデオ部（基本構成システム、基本システム、システム）、１０６  ＬＡＮ、１０８  端末、１１０  ゲートウェイ、１１２  マルチポイント制御ユニット（ＭＣＵ）、１１４  ゲートキーパー（ＧＫ）、１１６  ゾーン構成システム（ゾーン）、１１８  ゾーン、１２０  ＬＡＮセグメント、１２２  ルータ（Ｒ）、１２４  ローカル通信管理ユニット、１２６  中央管理ユニット
【図１】
2007014006.tif 000003
【図２】
2007014006.tif 000004
【図３Ａ】
2007014006.tif 000005
【図３Ｂ】
2007014006.tif 000006
【図３Ｃ】
2007014006.tif 000007
【図３Ｄ】
2007014006.tif 000008
【図４Ａ】
2007014006.tif 000009
【図４Ｂ】
2007014006.tif 000010
【図４Ｃ】
2007014006.tif 000011
【図４Ｄ】
2007014006.tif 000012
【図５】
2007014006.tif 000013
【図６】
2007014006.tif 000014
【図７】
2007014006.tif 000015