(57)【要約】パケットがコミュニケーション・セッションの部分である、音声や映像データを含むデータ・パケットを検出するコンピュータ・ネット・ワークを管理したり、要求によってこれらのパケットを保管したり、コミュニケーション・セッションを再構築するためのシステムや方法。システムが、たとえばＶｏｉｃｅＯｖｅｒＩＰ環境のようなコミュニケーション・セッションをセットアップするのに用いられるプロトコルのパケットを独立して格納することを可能にするために、システムはコンピュータ・ネットワークのゲートキーパーへのリンクを含んでいる。
2004509563.tif 000002
【特許請求の範囲】
【請求項１】
ゲートキーパーを含むコンピュータ・ネットワーク上のコミュニケーション・セッションを管理するためのシステムであって以下から成る。
（ａ）コンピュータ・ネットワークに接続するための、およびコンピューター・ネットワークからデータ・パケットを受理するためのネットワーク・コネクター、
（ｂ）前記データ・パケットがコミュニケーション・セッションの少なくとも１つの部分を形成し、および前記データ・パケットが選択されたデータ・パケットであるというような、前記データ・パケットが音声データおよび映像データから成るグループから選択されたデータを含む場合のみ、前記データ・パケットをフィルターにかけるための、および前記データ・パケットを受理するためのフィルタリング・ユニット，
（ｃ）前記選択されたデータ・パケットは格納データ・パケットであるというような、前記選択されたデータ・パケットの格納及び前記選択されたデータ・パケットの受理のための管理ユニット，及び
（ｄ）前記コミュニケーション・セッションの少なくとも１つの部分が格納されるような、前記管理ユニットからの前記データ・パケットの受理および格納のための格納媒体，及び
（ｅ）前記データ・パケットに関する情報をゲートキーパーから前記管理ユニットまで転送するための、ゲートキーパーと前記管理ユニット間のリンク。
【請求項２】
請求項１のシステムであってさらに以下を含む。
（ｆ）前記コミュニケーション・セッションの少なくとも１つの部分を検索し表示するためのデータ復元ユニット、前記管理ユニットを通して前記格納媒体から前記データ・パケットを要求する前記データ復元ユニット、及び前記コミュニケーション・システムの少なくとも１つの部分を表示する前記データ・パケットを再構築する前記データ復元ユニット。
【請求項３】
前記データ復元ユニットがさらに前記コミュニケーション・セッションの少なくとも１つの部分を表示するためのコミュニケーション・セッション表示ユニットを含むことを特徴とする請求項２のシステム。
【請求項４】
前記コミュニケーション・セッション表示ユニットが映像ユニット及び音声ユニットから成るグループから選択されることを特徴とする請求項３のシステム。
【請求項５】
請求項２のシステムであってさらに以下を含む。
（ｇ）コミュニケーション・セッションがモニターされる参加者の、少なくとも一つのＩＰアドレスを含むフィルタリング情報を格納するための前記フィルタリング・ユニットに接続されたデータベース。
前記データ・パケットが前記フィルタリング情報を満たす場合、実質的に前記データ・パケットを単に受理する前記フィルタリング・ユニットのような、前記フィルタリング情報に沿って前記データ・パケットを受理することを特徴とする。
【請求項６】
請求項５のシステムであってさらに以下を含む。
（ｈ）前記ユーザーが前記少なくとも一つの前記ユーザーの命令に従って前記フィルタリング情報を決定するような、前記ユーザーに情報を表示し、少なくとも一つの命令を受理するユーザー・コンピュータ。
【請求項７】
コンピュータ・ネットワークがＬＡＮ（ローカル・エリア・ネットワーク）及びＷＡＮ（ワイド・エリア・ネットワーク）から成るグループから選択されることを特徴とする請求項６のシステム。
【請求項８】
コンピュータ・ネットワークがＬＡＮ（ローカル・エリア・ネットワーク）であることを特徴とする請求項７のシステム。
【請求項９】
ＬＡＮが少なくとも２つのセグメントに分割されることを特徴とする請求項８のシステムであって、そのシステムはさらに以下から成る。
（ｉ）前記フィルタリング・ユニット及び前記管理ユニットを含み、各セグメントのためのローカル管理ユニット，及び
（ｊ）前記ローカル管理ユニットをコントロールする中央管理ユニットで、前期中央管理ユニットは前記格納媒体中への格納をコントロールする。
【請求項１０】
前記ネットワーク・コネクターがネットワーク・インターフェース・カードであることを特徴とする請求項１のシステム。
【請求項１１】
パケットの送信源及びパケットの宛先間でのコンピュータ・ネットワーク上のコミュニケーション・セッションを管理するための方法であって以下のステップから成る。
（ａ）第１プロトコル・スイートに従ってコミュニケーション・セッションをセットアップするステップ，及び
（ｂ）前記第１プロトコル・スイートと異なる第２プロトコル・スイートに従って、コミュニケーション・セッションの少なくとも１つの部分を格納するステップであって、データ処理装置によって実行される格納のステップ。
【請求項１２】
前記プロトコル・スイートがＩＰプロトコル・スイートであることを特徴とする請求項１１の方法。
【請求項１３】
前記格納が以下から成るステップによってもたらされることを特徴とする請求項１１の方法。
（Ｉ）データ・パケットをコンピュータ・ネットワーク上のパケット源から受け取るステップ
（ＩＩ）前記パケットが第２プロトコル・スイートに従っているかどうかデータ・パケットを分析するステップ
（ＩＩＩ）前記格納されたデータ・パケットがコミュニケーション・セッションの少なくとも１つの部分を形成するように格納されたデータ・パケットを形成するための前記データ・パケットを格納するステップ
【請求項１４】
前記データ・パケットの分析ステップが前記データ・パケットのヘッダを検査することで行なわれることを特徴とする請求項１３の方法。
【請求項１５】
前記コミュニケーション・セッションの少なくとも１つの部分を格納するステップがさらに以下のステップから成ることを特徴とする請求項１３の方法。
（ＩＶ）前記分析に続き、前記データ・パケットが第２プロトコル・スイートに従っている場合、前期データ・パケットのタイプを決定するために前記データ・パケットをフィルターにかけるステップ。
【請求項１６】
前記データ・パケットのヘッダを検査することによって前記データ・パケットを分析するステップを行うことを特徴とする請求項１５の方法。
【請求項１７】
前記データ・パケットの前記ヘッダを検査することによって前記データ・パケットをフィルターにかけるステップ行うことを特徴とする請求項１６の方法。
【請求項１８】
前記第２のプロトコル・スイートがＩＰプロトコル・スイートであることを特徴とし、前記第２プロトコル・スイートに従った前記データ・パケットがＩＰパケットであることを特徴とし、前記ＩＰパケットをフィルターにかけるステップはさらに、
（Ａ）前記パケット送信元のＩＰアドレスを決定するために前記ＩＰパケットの前記ヘッダを検査する方法；
（Ｂ）もし前記ＩＰアドレスが既知アドレスであれば決定する；
（Ｃ）もし前記ＩＰアドレスが前記既知アドレスであれば単に実質的な認可ＩＰパケットを構成するために前記ＩＰパケットをパスする、および、
（Ｄ）あるいは、前記ＩＰパケットをダンプする；
から成り立つことを特徴とする請求項１７の方法。
【請求項１９】
前記ＩＰアドレスと送信元パケットからのＩＰアドレスのリストとを比較することによって、つまりは、もし前記ＩＰアドレスが前記リストに含まれていれば前記アドレスは前記既知のＩＰアドレスであることによって、前記ＩＰアドレスが前記既知ＩＰアドレスであるかどうか決定する方法を特徴とする請求項１８の方法。
【請求項２０】
もし前記パスＩＰパケットがＲＴＰパケットであれば、前記ＲＴＰパケットを格納することを特徴とする請求項１８の方法。
【請求項２１】
もし前記パスＩＰパケットがＲＴＣＰパケットであれば、前記ＲＴＣＰパケットを格納することを特徴とする請求項１８の方法。
【請求項２２】
前記データ・パケットの前記タイプによって前記データ・パケットの前記格納が影響を受けることを特徴とする請求項１５の方法。
【請求項２３】
コミュニケーション・セッションの少なくとも一部分を格納するステップはさらに、
（ｉｖ）　検索されたデータ・パケットを構成するために前記格納されたデータ・パケットを検索する、および、
（ｖ）　前記検索されたデータ・パケットによってコミュニケーション・セッションの少なくとも一部分を再構築する、
から成り立つことを特徴とする請求項１３の方法。
【請求項２４】
前記第２のプロトコル・スイートがＩＰプロトコル・スイートであることを特徴とし、前記データ・パケットを検索するステップとして、
（Ａ）　送信元パケットの送信元ＩＰアドレス、コミュニケーション・セッション開始時刻、コミュニケーション・セッション終了時刻を受信する；および、
（Ｂ）　前記送信元ＩＰアドレス、前記開始時刻と前記終了時刻に従って、少なくとも１つのコミュニケーション・セッションを選択する、
を含むことを特徴とする請求項２３の方法。
【請求項２５】
前記第２プロトコル・スイートがＩＰプロトコル・スイートであることを特徴とし、前記データ・パケットを検索するステップとして、
（Ａ）　コミュニケーション・セッション、コミュニケーション・セッションの開始時刻、コミュニケーション・セッション終了時刻に関係した身元確認情報を受信する；
（Ｂ）　 前記身元確認情報から送信元ＩＰアドレスを推論する、および、
（Ｃ）　前記送信元ＩＰアドレス、前記開始時刻と前記終了時刻に従って、少なくとも１つのコミュニケーション・セッションを選択する、
を含むことを特徴とする請求項２３の方法。
【請求項２６】
コミュニケーション・セッションの少なくとも一部分を再構築するステップは表示している音声データを含むことを特徴とする請求項２３の方法。
【請求項２７】
コミュニケーション・セッションの少なくとも一部分を再構築するステップは表示している映像データを含むことを特徴とする請求項２３の方法。
【請求項２８】
前記第２プロトコル・スイートがＩＰプロトコル・スイートであることを特徴とし、コミュニケーション・セッションの少なくとも一部分を再構築するステップはさらに、
（Ａ）　単に実質的にＲＴＰパケットを検索する；
（Ｂ）　どの前記ＲＴＰパケットのためにもタイム・スタンプを決定するのに前記ＲＴＰパケットのヘッダを検査する、および、
（Ｃ）　前記のタイム・スタンプによって順番に前記ＲＴＰパケットを表示する、
から成り立つことを特徴とする請求項２３の方法。
【発明の詳細な説明】
【０００１】
（分野及び背景）
本発明は、コンピュータ・ネットワークを基にした、電話通信のための、そして、特に音声及び／又は、映像データを含むパケットの識別のための通信セッションの管理のための、及びこれらパケットの記憶装置のための、及び必要とされる音声及び／又は映像ディスプレイのための選択された通信セッションの再構築のための方法及びシステムである。
オフィス通信システムへのコンピュータの統合は、個別の装置を結合してコンピュータを通じて操作される１つの管理システムにするために分離することにより以前から行われていた多くの機能を可能にしてきた。例えば、コンピュータを基礎とした音声ロギング・システムはコンピュータに通常の電話通信ネットワークにハードウェア接続を通して音声コミュニケーションを受け取り、少なくとも２人の参加者が行う会話、あるいは少なくとも１人の参加者から１つあるいはそれ以上の参加者へのメッセージを記録し、これらの記録されたメッセージあるいは会話をリクエストにより再生することができる。これらボイス・ロギング・システムは留守番電話機械と置き換えることができる。
【０００２】
コンピュータボイス・ロギング・システムは、留守番電話機械より、多くの利点がある。例えば、ボイス・メッセージは通常の音声カセットより大きい記憶装置能力を持つ、ＤＡＴカセットのような、コンピュータを基礎とした記憶媒体に格納することができる。
更に、格納されたボイス・メッセージは、データベースにおいて、メッセージを例えば時間、日付、チャンネル、ダイヤル・ナンバー数、または、呼び出し人の識別に従い復元できるように組織化することができる。このような組織は留守番電話機械では不可能である。それゆえ、ボイス・メッセージのためのコンピュータ・ロギング・システムは留守番電話機械より多くの利点を持つ。
【０００３】
残念ながら、現在利用可能なコンピュータ・ロギング・システムは、ＬＡＮ（ローカル・エリア・ネットワーク）あるいはＷＡＮ（広域ネットワーク）を通して行われる音声通信が、会話あるいはメッセージであるかに関わらず、電話通信セッションを記録することが不可能であることが不利な点である。これらロギング・システムはＬＡＮを通して遠隔ユーザーに対しボイス・メッセージを再生することができるが、例えば、もしＬＡＮを基とした電話によって伝達されるなら、このようなメッセージを記録することはできない。地元の通常の電話通信ネットワーク・サービスに対して支払うことなく、従って節約することができ、物理的に切り離されたサイトにおいて種々のグループの間で行うことができるので、このようなＬＡＮとＷＡＮを基とする電話通信は最近いっそう人気が高くなっている。
【０００４】
さらに、ＬＡＮとＷＡＮを基とする電話通信は音声情報と同様、映像の送信を容易にする。映像情報は確かに現在利用可能なコンピュータ・ロギング・システムで記録することができない。それゆえ、電話通信が、映像と音声データの両方を含め、ＬＡＮあるいはＷＡＮを通して行われることに関して、電話通信セッションを記録することをコンピュータ・ロギング・システムで行うことができないことはこれらシステムの重要な不利な点である。
【０００５】
音声と映像情報の両方を記録し、これら情報を整理し、そして次にこれら情報をリクエストによって示すシステムと、ＬＡＮあるいはＷＡＮのような、コンピュータ・ネットワーク上で行われる電話通信セッションを記録するための方法を得ることは必要であり、そして大いに有利となる。
【０００６】
スイッチング産業は、ＩＰの分野へと向かっている。この動きは遠距離通信産業に強い影響を与えている。この動きの完全な影響を理解するにはあまりにも早すぎて不可能である。国際遠距離通信の組合が、異なった販売者から製品を取り替える間の互換性を保証するＨ．３２３標準を発表したとき、ＩＰマルチメディアの開始はその勢いを得た。Ｈ．３２３標準はインターネットを含むＩＰを基としたネットワークに渡って、音声、映像及びデータ・コミュニケーションのための基盤を提供する。
【０００７】
ルセント、シーメンス、ノーテル及びアルカテルのような大部分の主なスイッチング販売者は、ＩＰを彼らのスィッチング・プラットフォームに統合することを決定した。かなり近いうちに、これら販売者は市場にＩＰ技術に基づく新しいスイッチ・プラットホームを発表するだろう。
現在の記録の解決法の全ては、この中央マトリックスを介して送られた、全ての呼出に関してＰＢＸ、又は中央オフィスが中央スイッチング・マトリックスを利用するという事実に基づいている。このマトリックスによる統合は、ＰＢＸ、又は中央オフィスによって送られた全ての呼出がスイッチ・マトリックスに接続を持つデジタル記録システムによって記録されることを保証する。これは、しかしながら本来分散されるＩＰ環境と一致しない。
【０００８】
従って、中央スイッチング・マトリックスから独立して、ＬＡＮあるいはＷＡＮのようなコンピュータ・ネットワーク上でシステム及び電話通信セッションを記録するための方法を得ることは必要性があり、非常に有利であろう。
【０００９】
（発明の要約）
コンピュータ・ネットワーク上で行われる通信セッションを記録するためのシステム及び方法を提供することが、本発明の１つの目的である。
記録のための音声及び映像データを検出するために、コンピュータ・ネットワーク上に送られたデータを分析するためのシステム及び方法を提供することが、本発明の他の目的である。
記録された映像及び音声データをリクエストによって表示するためのシステム及び方法を提供することが、本発明のまた別の目的である。
【００１０】
ＬＡＮを基礎とした電話システムによって行なわれた通信セッションを分析、記録、表示するためのシステム及び方法を提供することが、本発明の更にもう一つの目的である。
これら及び本発明の他の目的は以下提供される図面、記述及び請求項でさらに詳しく説明される。
本発明はコンピュータ・ネットワークを基礎とした“電話”システムを持つ通信セッションをログすることができるような、格納された情報を整理するため、リクエストにより格納された情報を示すため、選択的に音声を記録するためのコンピュータ・ネットワークと映像データ・パケットでデータ・パケットを分析するためのシステム及び方法を提供する。
【００１１】
本発明の教義によれば、コンピュータ・ネットワーク上で通信セッションを管理するシステムが提供され、システムは以下のことからなる。（ａ）コンピュータ・ネットワークにつなげるための及びコンピュータ・ネットワークからデータ・パケットを受信するためのネットワーク・コネクター、（ｂ）データ・パケットが音声データと映像データから成り立っているグループから選択した、データを含む場合に限り、データ・パケットをフィルターするための、及び十分にデータ・パケットを受け入れるためのフィルター・ユニット、つまり、データ・パケットが通信セッションの少なくとも一部分を構成するように、そしてデータ・パケットが選択されたデータ・パケットである。（ｃ）選択されたデータ・パケットを受信するための、及び選択されたデータ・パケットを格納するための管理ユニット、つまり、選択されたデータ・パケットが格納されたデータ・パケット。及び（ｄ）受信するための、及び管理ユニットから格納されたデータ・パケットを格納するための記憶媒体、つまり、少なくとも、通信セッションの一部分が格納される。
【００１２】
好ましくは、システムはさらに次のことも含む。（ｅ）少なくとも通信セッションの一部を検索し、表示するための、データ復元ユニット、記憶媒体から管理ユニットまでデータ・パケットを要求するデータ復元ユニット、及びデータ・パケットを再構築する、通信セッションの少なくとも一部分を表示するためのデータ復元ユニット。
【００１３】
より好ましくは、データ復元ユニットは、少なくとも通信セッションの一部分を表示するための通信セッション表示ユニットからなる。最も好ましくは、通信セッション表示ユニットは映像ユニット及び音声ユニットのグループから選択される。
【００１４】
本発明の好適な実施例によると、システムは更に次のことも含む。（ｆ）フィルター情報に沿ってデータ・パケットを受け取る場合、通信セッションが監視される、ある参加者の少なくとも１つのＩＰアドレスを含むフィルター情報、つまり、フィルターをかけられた情報を格納するための、フィルター・ユニットと接続されたデータベース、フィルター・ユニットがもしデータ・パケットがフィルター情報を満たすなら、フィルター・ユニットは実質上ただデータ・パケットを受け入れるだけである。
【００１５】
好ましくは、システムは更に、以下のことを含む。（ｇ）ユーザーの少なくとも１つのコマンドを受信し、ユーザーに情報を表示するためのためのユーザー・コンピュータ、つまり、ユーザーが、ユーザーの少なくとも１つのコマンドに沿ったフィルター情報を決定する。
【００１６】
更に好ましくは、コンピュータ・ネットワークは、ＬＡＮ（ローカル・エリア・ネットワーク）、及び、ＷＡＮ（広域ネットワーク）からなるグループの中から選択される。最も好ましくは、コンピュータ・ネットワークは、ＬＡＮ（ローカル・エリア・ネットワーク）である。
本発明の更なる実施例に沿って、ＬＡＮは少なくとも２つの部分に分けられ、システムは更に以下のことを含む。（ｈ）各部分のためのローカル管理ユニット、フィルター・ユニット及び管理ユニットを含むローカル管理ユニット、（ｉ）ローカル管理ユニットを管理するための、中央管理ユニット、格納を管理する格納媒体中の中央管理ユニット。
【００１７】
好ましくは、ネットワーク・コネクターはネットワーク・インターフェース・カードである。
本発明の他の実施例に沿って、コンピュータ・ネットワークに関して行われた通信セッションの部分を少なくとも格納するための方法が提供され、通信セッションはパケットの情報源とパケット送信先の間で行われ、方法の各ステップはデータ・プロセッサーで行われ、方法は以下のステップからなる。（ａ）コンピュータ・ネットワークのパケットの発信元からデータ・パケットを受信する、（ｂ）データ・パケットがＩＰパケットかどうかを決定するためにデータ・パケットを分析する、（ｃ）もしデータ・パケットがＩＰパケットならば、ＩＰパケットの種類を決定するためにＩＰパケットをフィルターにかける、（ｄ）種類に沿った格納データ・パケットを形成するためにＩＰパケットを格納する、つまり、格納されたデータ・パケットが通信セッションの少なくとも１つの部分を形成する。
好ましくは、データ・パケットの分析のステップはデータ・パケットのヘッダの検査をすることにより行われる。
【００１８】
本発明の好適な実施例に沿って、ＩＰパケットをフィルターにかけるステップはＩＰパケットのヘッダの検査をすることにより行われる。
好ましくは、ＩＰパケットをフィルターにかけるステップは以下のステップからなる。（ｉ）パケット送信元のＩＰアドレスを決定するためにＩＰパケットのヘッダの検査をする、（ｉｉ）ＩＰアドレスが既知のＩＰアドレスかどうかを決定する、（ｉｉｉ）ＩＰアドレスが既知のＩＰアドレスのときのみ、実質的にパスしたＩＰパケットを形成するためにＩＰパケットをパスする、（ｉｖ）あるいはまた、ＩＰパケットをダンプする。
【００１９】
更に好ましくは、ＩＰアドレスが既知のＩＰアドレスかどうかを決定するステップはＩＰアドレスをパケット送信元からのＩＰアドレスのリストと比較することにより行われ、つまり、もしＩＰアドレスがリストの中に含まれるなら、ＩＰアドレスは既知のＩＰアドレスである。
【００２０】
また、好ましくはＩＰパケットをフィルターにかけるステップはさらに以下のステップからなる。（ｖ）パスしたＩＰパケットがＨ．２２５パケット、Ｈ．２４５パケット、ＲＴＰパケットあるいはＲＴＣＰパケットかどうかを決定する、（ｖｉ）パスしたＩＰパケットの種類がＨ．２２５パケットならば、Ｈ．２２５パケットはセットアップ・パケットあるいは接続パケットかどうかを決定する、（ｖｉｉ）もしＨ．２２５パケットがセットアップ・パケットならば、ステータス・フラグを、“セッション・リクエストを開始する”のように配置する（ｖｉｉｉ）あるいはまた、もしＨ．２２５パケットが接続パケットであり、ステータス・フラグが、セッション・リクエストを開始する、ならば、通信セッションの少なくとも１つの項目を格納する、（ｉｘ）ステータス・フラグを、“ロジック・チャンネルを待つ”というように配置する。
【００２１】
更に好ましくは、更にＩＰパケットにフィルターをかけるステップは以下のステップからなる。（ｘ）あるいはまた、もしパスしたＩＰパケットの種類がＨ．２４５パケットなら、Ｈ．２４５パケットがオープン・ロジカル・チャンネル・リクエスト・パケットかどうかを決定する、オープン・ロジカル・チャンネル認識パケットあるいはターミナル機能セット・パケット、（ｘｉ）もしＨ．２４５パケットがオープン・ロジカル・チャンネル・リクエスト・パケット及びステータス・フラグが“ロジック・チャンネルを待つ”ならば、ステータス・フラグを“認識を待つ”に配置する、（ｘｉｉ）あるいはまた、もしＨ．２４５パケットがオープン・ロジカル・チャンネル認識パケット及びステータス・フラグが“認識を待つ”ならば、（Ａ）ステータス・フラグを“ターミナルへの機能を待つ”に配置する、（Ｂ）通信セッションの宛先への移送アドレスを保存する、を行う、（ｘｉｉｉ）あるいはまた、もしＨ．２４５パケットがターミナルへの機能を持つセット・パケットならば、（Ａ）ターミナルへの機能を持つパケットから、パケットの宛先への利用性を格納する、（Ｂ）ステータス・フラグを“コール・プロセス中”に配置することを行う。
【００２２】
最も好ましくは、もしステータス・フラグが“コール・プロセス中”及びパスしたＩＰパケットがＲＴＰパケットならば、ＲＴＰパケットは格納される。さらに最も好ましくは、もしステータス・フラグが“コール・プロセス中”及びパスしたＩＰパケットがＲＴＣＰパケットならば、ＲＴＣＰパケットは格納される。
本発明の他の好ましい実施例によれば、方法はさらに以下のステップからなる。（ｅ）検索されたデータ・パケットを形成するために格納されたデータ・パケットを回収する、（ｆ）検索されたデータ・パケットに沿った、通信セッションの少なくとも１つの部分を再構築する。
【００２３】
好ましくは、データ・パケットを検索するステップは以下のステップを含む。（ｉ）パケット送信元の、送信元のＩＰアドレスを受信する、通信セッションの開始時刻及び通信セッションの終了時刻のステップ、及び（ｉｉ）送信元のＩＰアドレス、開始時刻及び終了時刻に沿って、少なくとも１つの通信セッションを選択する。
また、好ましくは、少なくとも通信セッションの一部分を再構築するステップは音声データを示すことを含む。
また、好ましくは、少なくとも通信セッションの一部分を再構築するステップは映像データを示すことを含む。
より好ましくは、少なくとも通信セッションの一部分を再構築するステップは以下のステップを含む。（ｉ）ＲＴＰパケットのみを実質的に検索する、（ｉｉ）各ＲＴＰパケットのためのタイム・スタンプを決定するためのＲＴＰパケットのヘッダを検査する、（ｉｉｉ）タイム・スタンプに沿うために、ＲＴＰパケットを表示する。
【００２４】
本発明の教義によれば、ゲートキーパーを含むコンピュータ・ネットワークで通信セッションを管理するためのシステムが提供され、システムは以下のことからなる。（ａ）コンピュータ・ネットワークに接続し、コンピュータ・ネットワークからデータ・パケットを受信するためのネットワーク連結装置、（ｂ）データ・パケットをフィルターにかけるため、及びデータ・パケットが音声データと映像データから成り立っているグループから選択されたデータを含む場合に限り、実質的にデータ・パケットを受け入れるためのフィルター・ユニット、つまり、データ・パケットが少なくとも通信セッションの一部を形成し、データ・パケットが選択されたデータ・パケットである、（ｃ）選択されたデータ・パケットを受信し、格納するための管理ユニット、つまり、選択されたデータ・パケットが格納されたデータ・パケット、（ｄ）管理ユニットから格納されたデータ・パケットを受信し、格納するための記憶媒体、つまり、少なくとも通信セッションの一部が格納される、（ｅ）ゲートキーパーから管理ユニットへデータ・パケットに関する情報を転送するためのゲートキーパーと管理ユニットの間のリンク。
【００２５】
好ましくは、システムはさらに以下のことからなる。（ｆ）少なくとも通信セッションの一部を検索し表示するためのデータ復元ユニット、管理ユニットを通し記憶媒体からデータ・パケットをリクエストするためのデータ復元ユニット、及び少なくとも通信セッションの一部を示すためのデータ・パケットを再構築するデータ復元ユニット。
さらに好ましくは、データ復元ユニットはさらに、少なくとも通信セッションの一部を示すための通信セッション表示ユニットからなる。最も好ましくは、通信セッション表示ユニットは映像ユニット及び音声ユニットからなるグループから選択される。
【００２６】
本発明の好適な実施例に沿って、システムはさらに、以下のことからなる。（ｇ）フィルター情報に沿った、データ・パケットを受け取る、フィルターにかける情報を格納するためのフィルター・ユニットに接続したデータベース、通信セッションが監視されているグループの、少なくとも１つのＩＰアドレスを含んだフィルターにかける情報、つまり、フィルター・ユニットが、もしデータ・パケットがフィルターにかける情報を満たすならば、フィルター・ユニットが実質的にデータ・パケットだけを受け入れる。
【００２７】
好ましくは、システムはさらに、以下のことからなる。（ｈ）ユーザーの少なくとも１つのコマンドを受信し、ユーザーに情報を示すためのユーザー・コンピュータ、つまり、ユーザーが少なくとも１つのユーザーのコマンドに沿ったフィルターにかける情報を決定する。
さらに好ましくは、コンピュータ・ネットワークはＬＡＮ（ローカル・エリア・ネットワーク）及びＷＡＮ（広域ネットワーク）からなるグループから選択される。
最も好ましくは、コンピュータ・ネットワークはＬＡＮ（ローカル・エリア・ネットワーク）である。
本発明のさらに好適な実施例に沿って、ＬＡＮは少なくとも２つの部分に分けられ、システムはさらに、以下のことからなる。（ｉ）各部分のためのローカル管理ユニット、フィルター・ユニットを含むローカル管理ユニット、（ｊ）ローカル管理ユニットをコントロールするための中央管理ユニット、記憶媒体中の記憶をコントロールするための中央管理ユニット。
【００２８】
好ましくは、ネットワーク連結装置はネットワーク・インターフェース・カードである。
本発明の他の実施例に沿って、（ａ）最初のプロトコル・スイートに沿って通信セッションを開始する、（ｂ）パケット送信元とパケットの目的場所の間でコンピュータ・ネットワークによって通信セッションを行うための方法が以下に提供され、つまり、最初のプロトコル・スイートと異なる第２プロトコル・スイートに沿って、少なくとも通信セッションの一部分を格納し、格納はデータ・プロセッサーによって行われる、というステップからなる。例えば、第２プロトコル・スイートは、ＩＰプロトコル・スイートであることもできる。
【００２９】
通信セッションの一部分を格納することは、以下のことを含むステップによって行われる。（ｉ）コンピュータ・ネットワークのパケット送信元からデータ・パケットを受信する、（ｉｉ）もしデータ・パケットが、第２プロトコル・スイートに一致するならば、決定するためにデータ・パケットを分析する、（ｉｉｉ）格納されたデータ・パケットを形成するためにデータ・パケットを格納する、つまり、格納されたデータ・パケットが少なくとも通信セッションの一部を形成する。好ましくは、データ・パケットの分析のステップはデータ・パケットのヘッダを検査することにより影響を受ける。
【００３０】
本発明の他の好ましい実施例に沿って、少なくとも通信セッションの一部を格納するステップはさらに、以下のことからなる。（ｉｖ）分析の後、もしデータ・パケットが第２プロトコル・スイートに沿うならば、データ・パケットの種類を決定するため、データ・パケットをフィルターにかける。
好ましくは、データ・パケットのヘッダを検査することにより、データ・パケットを分析するステップは行われ、データ・パケットのヘッダを検査することにより、データ・パケットをフィルターにかけるステップは行われる。
【００３１】
好ましくは、第２プロトコル・スイートはＩＰプロトコル・スイートであり、ＩＰパケットのフィルターにかけるステップはさらに、以下のことからなる。（ｉ）パケット送信元のＩＰアドレスを決定するためのＩＰパケットのヘッダを検査する、（ｉｉ）ＩＰアドレスが既知のＩＰアドレスかどうかを決定する、（ｉｉｉ）ＩＰアドレスが既知のＩＰアドレスである場合にのみ、実質的にパスしたＩＰパケットを形成するために、ＩＰパケットを通す、（ｉｖ）あるいはまた、ＩＰパケットをパスする。
【００３２】
さらに好ましくは、ＩＰアドレスが既知のＩＰアドレスかどうかを決定するステップはＩＰアドレスをパケット送信元とのＩＰアドレスのリストと比較することにより行われ、つまり、もしＩＰアドレスがリストの中に含まれ、ＩＰアドレスが記録されたＩＰアドレスである。
最も好ましくは、もしＩＰパケットがＲＴＰパケットならば、ＲＴＰパケットは格納される。さらに最も好ましくは、もしパスしたＩＰパケットがＲＴＣＰパケットならば、ＲＴＣＰパケットは格納される。
【００３３】
好ましくは、データ・パケットの格納はデータ・パケットの種類により影響を受ける。
本発明の他の好適な実施例に沿って、通信セッションの少なくとも一部を格納するステップはさらに、以下のステップからなる。（ｉｖ）検索されたデータ・パケットを形成するために、格納されたデータ・パケットを検索する、（ｖ）検索されたデータ・パケットに沿って、通信セッションの少なくとも一部を再構築する。
【００３４】
好ましくは、第２プロトコル・スイートは、ＩＰプロトコル・スイートであり、データ・パケットを検索するステップは（Ａ）パケット送信元のＩＰアドレス送信元を検索する、通信セッションの開始時刻、通信セッションの終了時刻、（Ｂ）ＩＰアドレス、開始時刻、終了時刻に沿った、少なくとも１つの通信セッションを選択する。
又、好ましくは、通信セッションの少なくとも一部を再構築するステップは音声データの表示を含む。
あるいは又、さらに好ましくは、通信セッションの少なくとも一部を再構築するステップは映像データの表示を含む。
【００３５】
もっとも好ましくは、通信セッションの少なくとも一部分を再構築するステップはさらに以下のことからなる。（Ａ）実質的にＲＴＰパケットだけを検索する、（Ｂ）各ＲＴＰパケットのためのタイム・スタンプを決定するためにＲＴＰパケットのヘッダを検査する、（Ｃ）タイム・スタンプに沿って順番通りにＲＴＰパケットを表示する。
以下、用語“通信セッション”は、“リアルタイム”で音声及び／又は映像情報を交換することにより、少なくとも２人の参加者が会話する会話及び少なくとも１人の参加者が後日少なくとも他の１人の参加者により、このような音声及び／又は映像情報を受信するための記録するメッセージの両方を含む。
【００３６】
以下、用語“インターネット”は全世界にコンピュータを結ぶために一般に使われる何千というネットワークに広範囲にリンクされたＷｅｂを指定するために用いられる。ここで用いられるように、用語“イントラネット”は他のタイプの、ＬＡＮ（ローカル・エリア・ネットワーク）のような、コンピュータ・ネットワークあるいはＷＡＮ（広域ネットワーク）を含む。
用語“コンピュータ・ネットワーク”は、インターネットとイントラネットの両方を含めて、データの送信を可能とする、少なくとも２つのコンピュータ間のどのような接続も含む。
用語“通常の電話通信ネットワーク”は通常の電話サービスプロバイダーを通してサービスを提供するＰＯＴＳ （普通の電話システム）及び、どのような種類のコンピュータ・ネットワークを通してでも機能を発揮する特に音声及び／又は映像通信を除外するが、通常の電話サービスプロバイダーを通してサービスを提供する、実質的に他のいかなるタイプの電話回線網を含む。
【００３７】
以下、用語“コンピュータ”はＤＯＳ、Ｗｉｎｄｏｗｓ（登録商標）、ＯＳ／２（登録商標）あるいはＬｉｎｕｘ（登録商標）のようなオペレーティング・システムを持つパーソナル・コンピュータ（ＰＣ）に限らず、Ｍａｃｋｉｎｔｏｓｈ（登録商標）コンピュータ、ＪＡＶＡ（登録商標）ＯＳをオペレーティング・システムとして持つコンピュータ、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）及びＳｉｌｉｃｏｎ・Ｇｒａｐｈｉｃｓ（登録商標）のコンピュータのようなグラフィック・ワークステーション、及びＳｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）のＡＩＸあるいはＳＯＬＡＲＩＳ（登録商標）のようなＵＮＩＸオペレーティング・システムのあるバージョンを持つ他のコンピュータ、あるいは他の知られている及び利用できるオペレーティング・システムを含む。以下、用語“Ｗｉｎｄｏｗｓ（登録商標）”はマイクロソフト株式会社（シアトル、ワシントン、米国）によるウィンドーズ（登録商標）９５、ｘが１のような整数を表す、Ｗｉｎｄｏｗｓ（登録商標）３．ｘ、Ｗｉｎｄｏｗｓ（登録商標）ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ及びこれらオペレーティング・システムのアップグレード・バージョンに限定されないが含む。
【００３８】
以下、用語“ロギング”は音声及び／又は映像データの位置を定めるためにネットワーク上でデータ・パケットを分析すること、組織化されたシステムでこれらデータを記録する過程に関する。以下、用語“ディスプレイ”は、映像データのビジュアル・ディスプレイと、音声データのための音の生産の両方を含む。
【００３９】
（発明の属する技術分野）
以下の記述は、本発明の方法およびシステムの中で任意に使用することができる、特定の背景方法および技術の説明を提供するためのものである。本発明は特にこれらの方法および技術のみに寄せられるものではない。むしろそれは本発明の目的である、コンピュータ・ネットワーク上のデータ・パケットを分析し、選択的に音声および映像データ・パケットを記録し、またこれら格納情報を系統化し必要に応じて表示を行ない、コンピュータ・ネットワークに基づいた「電話」システムを持ったコミュニケーション・セッションの接続ができるようなシステムと方法を遂行する道具として使用される。
【００４０】
本発明のシステムおよび方法は特に、無保証のサービス品質を提供するローカル・エリア・ネットワーク用の視覚的電話システム及び設備に対するＩＴＵ−Ｔ企画Ｈ．３２３に沿って構築されたコンピュータ・ネットワークと作動するためのものである。Ｈ．３２３規格はここで、このようなコンピュータ・ネットワーク用のハードウェア必要条件および操作のプロトコルについてさらに記述するために参照として取り入れられ、以下「Ｈ．３２３」と呼ばれる。
【００４１】
Ｈ．３２３は、保証されたサービス品質を提供しないローカル・エリア・ネットワーク（ＬＡＮ）上のマルチメディア・コミュニケーションのためのターミナル、設備およびサービスについて説明する。Ｈ．３２３を満たすコンピュータ・ターミナルおよび設備は、テレビ電話通信を含むリアルタイムの音声、データおよび映像、あるいは任意の組合せを運ぶ。
【００４２】
このようなターミナルが通信するＬＡＮは単独セグメントとなるか輪になり、あるいは任意に複雑な位相を持った多数のセグメントを含みうる。これらのターミナルは、コンピュータへ任意に統合されるか、あるいはテレビ電話のような独立装置中に実行される。ボイス・データのサポートが必要である一方、一般的なデータおよび映像データのサポートは任意であるが、もしサポートされれば特定の共通作用モードを使用する能力が、特定のメディア・タイプをサポートするターミナル全てが通信できるように要求される。Ｈ．３２３規格は、各タイプの１本以上のチャンネルが使用されることを認可する。参照として取り入れられるＨ．３２３シリーズ中の他の規格はＨ．２２５．０パケットおよび同調化、Ｈ．２４５コントロール、Ｈ．２６１およびＨ．２６３映像コーデック、Ｇ．７１１、Ｇ．７２２、Ｇ．７２８、Ｇ．７２９およびＧ．７２３音声コーデック、そしてマルチ・メディア通信プロトコルのＴ．１２０シリーズを含む。
【００４３】
ＩＴＵ−Ｔ規格Ｈ．２４５．０は、視覚的電話システムのためのメディア・ストリーム・パケット化および同調化の定義にあてはまる。ＩＴＵ−Ｔ勧告Ｈ．２４５．０は、マルチメディア・コミュニケーションのためのコントロール・プロトコルを定義し、以下「Ｈ．２４５」と呼ばれる。またここに十二分に述べられるように、Ｈ．２４５は参照として取り入れられる。
【００４４】
Ｈ．２４５のロジカル・チャンネル信号処理は、チャンネルが開かれる時の各ロジカル・チャンネルの内容を説明する。処理手順は送信が受信機によって解読可能な情報に限られるように、及び受信機が送信機に特別の希望モードを要求するように、受信機と送信機との機能的性能のコミュニケーションのために供給される。
【００４５】
Ｈ．２４５信号はエンドポイントとマルチポイント・コントローラー、あるいはエンドポイントおよびゲートキーパーといった２つのエンドポイント間で確立される。エンドポイントはエンドポイントが関係する呼出の各々に対して、正確な１つのＨ．２４５コントロール・チャンネルを確立する。それゆえチャンネルはＨ．２４５に従って作動しなければならない。多数の呼出、およびそれゆえ多数のＨ．２４５コントロール・チャンネルのサポートが考えられる。
【００４６】
ＲＡＳ信号機能は登録、承認、帯域幅変更、ステータス、またエンドポイントとゲートキーパーとの間の解除手順を実行するのにＨ．２２５．０メッセージを使用する。ゲートキーパーを持たないＬＡＮ環境ではＲＡＳ信号チャンネルが使用されない。ＬＡＮが少なくとも１つのゾーンを含むような、ゲートキーパーを含むＬＡＮ環境ではＲＡＳ信号チャンネルがエンドポイントとゲートキーパーとの間で開かれる。ＲＡＳ信号チャンネルは、Ｈ．３２３エンドポイント間のいかなる他のチャンネルの確立にも先立って開かれる。
【００４７】
呼出信号機能は、２つのＨ．３２３エンドポイント間の接続を確立するためにＨ．２２５．０呼出信号を使用する。呼出信号チャンネルは、ＲＡＳチャンネルおよびＨ．２４５コントロール・チャンネルから独立している。呼出信号チャンネルはＨ．２４５チャンネル、およびＨ．３２３エンドポイント間のいかなる他のロジカル・チャンネルの確立にも先立って開かれる。ゲートキーパーを持たないシステムでは呼出信号チャンネルは、その呼出に含まれる２つのエンドポイント間で開かれる。ゲートキーパーを含むシステムでは、呼出信号チャンネルはエンドポイントとゲートキーパーとの間、あるいはゲートキーパーによって選ばれたようにエンドポイントそれら自身の間で開かれる。
【００４８】
Ｈ．３２３によって定義された様々なチャンネルに対応するのは、Ｈ．３２３プロトコル・スイートを集団的に構成する対応プロトコルである。これらのプロトコルは、セッション・セット・アップのためのＨ．２２５とＨ．２４５のプロトコルおよび実際のデータ交換のためのＲＴＰとＲＴＣＰのプロトコルを含んでいる。
【００４９】
（好適な実施例の記載）
本発明はコンピュータ・ネットワーク上のデータ・パケットを分析し、選択的に音声および映像データ・パケットを記録し、これらの格納情報を系統化し必要に応じて表示する、コンピュータ・ネットワークに基づいた「電話」システムを持ったコミュニケーション・セッションの接続ができるようなシステムおよび方法を提供する。
【００５０】
本発明によるシステムと方法の原理および作用は、図面および添付の記述を参照することでより良く理解することができる。
【００５１】
図１を参照すると、図１はコンピュータ・ネットワーク上に実行されたコミュニケーション・セッションからの音声および／または視覚的データをログし表示するための典型的システムのブロック図である。コンピュータ・ロギング・システム１０は、コミュニケーション・セッション管理ユニット１３に接続されたユーザー・コンピュータ１２を特徴とする。コミュニケーション・セッション管理ユニット１３は、ネットワーク・インターフェース・カード（ＮＩＣ）１６を通して順にイントラネット１４に接続される。
【００５２】
ユーザー・コンピュータ１２はユーザー・インターフェース１８を含み、それは好ましくはＧＵＩ（グラフィカル・インターフェース）であり表示ユニット２０に表示される。ユーザー・インターフェース１８は好ましくはユーザーに対し、その呼出がモニターおよび／またはログされるべき参加者の定義といった情報を入力することを可能とし、またユーザーがコミュニケーション・セッションの検索および表示のために少なくとも１つのコマンドを入力することを可能とする。
【００５３】
表示ユニット２０は好ましくはコンピュータ・モニターである。ユーザーは、データ・エントリー・デバイス２２を通してデータとコマンドを入力することにより、ユーザー・コンピュータ１２と対話することができる。データ・エントリー・デバイス２２は好ましくは少なくとも１つのキーボードあるいはマウスのようなポインティング装置を含んでおり、更に好ましくはキーボードとポインティング装置の両方を含む。本発明の好ましい一つの実施例によれば、ユーザー・コンピュータ１２はＰＣ（パーソナル・コンピュータ）である。またあるいはユーザー・コンピュータ１２は、ＩＰに基づいたネットワーク上で通信ができるようなネット・コンピュータである「シン・クライアント」である。そのようなネット・コンピュータの１つの例として、サン・マイクロシステムズのＪａｖａＳｔａｔｉｏｎ（登録商標）がある。こういったネット・コンピュータの利点はユーザーが複雑で洗練されたソフトウェア・プログラムと対話することを、一般には現在利用可能なＰＣコンピュータの優れたコンピュータ性能を全て持っているわけではないのにもかかわらず、可能にする点である。
【００５４】
例えば、イントラネット１４はＬＡＮあるいはＷＡＮでありうる。コミュニケーション・セッション管理ユニット１３とイントラネット１４の接続はＮＩＣ１６を通してもたらされる。ＮＩＣ１６は好ましくはコミュニケーション・セッション管理ユニット１３を適切なコンピュータ・ネットワークに接続することができる、例えばＥｔｈｅｒｌｉｎｋ ＩＩ、ＩＳＡ／ＰＣＭＣＩＡアダプター、あるいは３−Ｃｏｍ（登録商標）のＥｔｈｅｒｌｉｎｋ ＩＩＩ ＰＣＩバスマスター・アダプター（３ｃ５９０）、あるいはＮｏｖｅｌｌ（登録商標）のＮＥ２０００アダプター、あるいは他のそのような適切製品といった任意の標準既製商品である。このような適切なコンピュータ・ネットワークの例は、これに限定されないが、イーサネット（ＩＥＥＥ標準８０２．３）、ファーストイーサネット（ＩＥＥＥ標準８０２．１０）、トークン・リング（ＩＥＥＥ標準８０２．５）およびＦＤＤＩのような任意の標準ＬＡＮを含む。
【００５５】
イントラネット１４上の全てのデータ・パケット・トラフィックはＮＩＣ１６を通してフィルタリング・モジュール２４にパスされる。図３により詳細に詳述されるように、フィルタリング・モジュール２４はどのデータ・パケットが次の基準を満たすか決定するためにデータ・パケットを検査する。簡単に言うと、データ・パケットは音声および／または映像トラフィックを表示し、Ｈ．２２５とＨ．２４５の基準に従ったヘッダを備えたＩＰパケットでなければならない。上述されるように、これらの基準はメディア・ストリーム・パケットの構築及び視覚的電話システムのための同調化、及びマルチ・メディア通信用のコントロール・プロトコルを定義する。
【００５６】
フィルタリング・モジュール２４は、その後管理モジュール２８へ実質上その基準を満たすデータ・パケットのみをパスする。下記の図７中に示されるように本発明のシステムのゾーン構成では、フィルタリング・モジュール２４はまた、他のコミュニケーション・セッション管理ユニットからメッセージを転送する。
【００５７】
管理モジュール２８は、フィルタリング・モジュール２４を通してパスされたデータ・パケットを受け取り、受信データ・パケットを分析する。任意にそして好ましくは、例えばデータベース２６はコミュニケーション・セッションがログされるべき参加者のＩＰアドレスといった情報を、例えば各参加者を少なくとも一つのＩＰアドレスに関連づける換算表同様に格納する。その呼出がログされるべき参加者を表すＩＰアドレスの格納リストは、好ましくはユーザーによって定義される。ここで使用されるように、「参加者」はコンピュータ・ネットワークに基づいた電話システムによって通信する人（複数可）のことを指す。後の好ましい要求は、ユーザーが興味を持つデータだけを含むことによって格納データの量を著しく減らす。管理モジュール２８は適用可能なＨ．２２５およびＨ．２４５仕様書に従ってデータを分析及び管理し、「従来技術の記述」の欄で詳述されるようにＨ．２４５コントロール機能（ＲＡＳ信号機能および呼出信号機能）を本質的に含む。
【００５８】
管理モジュール２８はデータ・パケットが属する特定のコミュニケーション・セッションを決定するため、使用されているデータ圧縮のタイプ（もしあれば）、及びデータ・パケットがモニターされるべきＩＰアドレスから送られたかどうかなどについてパケットを分析する。フィルタリング・モジュール２４は単に上記に詳述された基準を満たすデータ・パケットを全てパスするので（より詳細に関しては図３Ａ〜３Ｄを参照のこと）、管理モジュール２８はこの分析を実行しなければならない。これらのパケットは、データベース２６に格納された情報のうちの何にも配慮せずにパスされるので、管理モジュール２８はデータベース２６の規則を、受信パケットを格納するか決定するために、各パケットのパケット・ヘッダの中にある情報と比較しなければならない。
【００５９】
その後データベース２６の規則を満たす受信パケットは、好ましくはハードディスク磁気格納装置、光学ディスク、ＣＤ−ＲＯＭ、ＺＩＰ、ＤＶＤドライブ、あるいはＤＡＴカセットのような高性能デジタル式データ格納装置、あるいは特定アプリケーションの作動上の必要性に応じたこれらの装置の組合せ、あるいは他の適切な格納メディアの組合せにといった格納媒体３０に格納される。好ましくは、各データ・パケットが関連づけられた特定のコミュニケーション・セッションあるいは「電話呼出」もまた、後にそのセッションが再構築されて表示されるために格納される。
【００６０】
ユーザーからの要求に応じて、その後管理モジュール２８は１つ以上のコミュニケーション・セッションに関係している格納媒体３０から１つ以上のデータ・パケットを検索することができる。その後、検索されたパケット（複数可）はデータ復元モジュールに転送される。データ復元モジュール３２は好ましくは検索されたパケットを、ＲＴＰ（リアル・タイム・プロトコル）の使用により、特定コミュニケーション・セッションを復元するために操作することができる。図４Ｃおよび５に関してより詳細に以下詳述されるように、ＲＴＰに続くこのようなシステムでは、データ・パケットは単なる一連の数字というよりヘッダ中のタイム・スタンプと共に送信される。このようなタイム・スタンプは音声および映像データ・ストリーム・データのために必要であり、データ・パケットがデータ・ストリームの全面的なタイミングが維持されるように再集合化されるために必要である。このようなタイム・スタンプなしでは、適切なタイミングは維持されず、音声及び映像ストリームも正確に再構築されない。
【００６１】
コミュニケーション・セッションは、適用可能な音声およびまたは映像コーデックの使用により復元されたデータ・パケット・ストリームから復元される。コーデックはアナログ及びデジタル式データ転換用の非線形方法である。したがって例えば音声コーデックにより、相当するデータ・パケット中にデジタル化された音声データは、ユーザーへの表示のためのアナログ音声データに聴解音として変換される。適切なコーデックは、図５に関してより一層詳しく以下に記述される。
【００６２】
ユーザーが再構築されたコミュニケーション・セッションの表示を受け取るために、システム１０は音声ユニット３４および映像ユニット３６を特徴づけ、集合的に「コミュニケーション・セッション表示装置」と呼ばれる。より好ましくは、音声ユニット３４および映像ユニット３６の両方は、音声入力あるいは映像入力の両方をそれぞれ受信し、音声および映像出力を表示することができる。少なくとも、音声ユニット３４および映像ユニット３６は音声あるいは映像出力をそれぞれ表示できなければならない。例えば音声ユニット３４は任意に、入力のためのマイクロホンおよび出力用のスピーカーあるいはイヤホンを含むことができる。例えば映像ユニット３６は任意に、出力用の映像モニターあるいは表示スクリーン、および入力用のビデオカメラを含むことができる。
【００６３】
図２は図１０中のシステム１の図式ブロック図であり、システム１０のソフトウェア・モジュールの全面的なシステムをより詳細に示す。さらに、異なるタイプのデータ・パケットのヘッダについての記述（図４Ａ〜４Ｄ）と同様に、これらのソフトウェア・モジュールの作用（図３Ａ〜３Ｄおよび図５）を示す適切なところであるフローチャートに参照がなされる。
【００６４】
示されるように、システム１０は再びＮＩＣ１６を通してイントラネット１４への接続を含む。パケットがイントラネット１４を通して送信されるとともに、ＮＩＣ１６はこれらのデータ・パケットを遮り、それらをフィルタリング・モジュール２４へパスする。
【００６５】
フィルタリング・モジュール２４は２つのコンポーネントを持つ。第１フィルタリング・コンポーネント３８はデータ・パケット・ヘッダを検査し、それは後記の図４Ａ中に示されるように、正しいヘッダを持つＩＰタイプ・パケットでなければならない。次に、第１フィルタリング・コンポーネント３８はデータ・パケットを別のフィルタリング・コンポーネント４０へパスする。そして第２フィルタリング・コンポーネント４０はＩＰデータ・パケットのタイプを決定するが、それらはＨ．２２５、Ｈ．２４５、ＲＴＰあるいはＲＴＣＰ基準によって構築される。
【００６６】
図３Ａに関して詳述されるように、第１フィルタリング・コンポーネント３８及び第２フィルタリング・コンポーネント４０は以下のように作動する。ステップ１ではパケットがフィルタリング・モジュール２４により受け取られる。そのパケットは第１フィルタリング・コンポーネント３８に渡され、そのパケットがＩＰタイプ・パケットかどうかステップ２で決定する。このような決定はデータ・パケットのヘッダの構造へと実行され、その例は図４Ａの中で示される。ヘッダ４２は多数の箱として示され、その各々はヘッダの「フィールド」あるいは部分を表わす。それぞれの部分に占められたバイト数もまた示されるが、各層は３２ビットから成ると理解される。ヘッダの第一部分である「ＶＥＲＳ」部分４４は、プロトコル・バージョン数である。次に、「Ｈ．ＬＥＮ」部分４６は、ヘッダ中の３２ビット量の数を示す。「ＳＥＲＶＩＳ・ＴＹＰＥ」部分４８は、送信源が最小の遅れのあるルートか最大の処理能力があるルートのどちらの伝達データグラムを好むかを示す。「ＴＯＴＡＬ・ＬＥＮＧＴＨ」部分５０は、ヘッダおよびデータの両方中のオクテット総数を示す。
【００６７】
次の層では、「ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ」部分５２がパケット自体を識別する。「ＦＬＡＧＳ」部分５４は、データグラムがセグメントあるいは完全なデータグラムかどうかを示す。「ＦＲＡＧＭＥＮＴ・ＯＦＦＳＥＴ」部分５６は、データグラムが破砕した場合にオリジナルデータグラム中でのこのセグメントの位置を指定する。次の層では「ＴＩＭＥ・ＴＯ・ＬＩＶＥ」部分５８が、１から２５５間の正の整数を含み、通過された各ルートで次第にディクリメントされる。値が０になる場合、パケットはもはやパスされずに送信源に返送される。「ＴＹＰＥ」部分６０はパスされたデータのタイプを示す。「ＨＥＡＤＥＲ・ＣＨＥＣＫＳＵＭ」部分６２はパケットの完全体が部分６２に記録された値と実際のチェックサムとの比較により検査できるようにする。
【００６８】
ヘッダ４２の次の層は送信源ＩＰアドレス６４を含み、次の層はその後に宛先ＩＰアドレス６６を含む。任意のＩＰ・ＯＰＴＩＯＮ部分６８が存在し、その後にパディング（必要であれば）およびそのデータを含むパケットのデータ部分７０が始まる。
【００６９】
データ・パケットのヘッダの構造は、第１フィルタリング・コンポーネント３８によって、このヘッダがヘッダ４２に従った構造を持つデータ・パケットのヘッダのように、正しい命令における必要データ・フィールドを持っているかどうか決定するために検査される。ステップ３Ａの中で示されるように、第１フィルタリング・コンポーネント３８は単に、これらの正確なヘッダ構造を持つパケットがパスすることを認可する。もしそうでなければステップ３Ｂの中で示されるようにパケットはダンプされる。
【００７０】
その後正確なヘッダを持つそれらのパケット、あるいは「ＩＰパケット」は第２フィルタリング・コンポーネント４０に渡される。そして第２フィルタリング・コンポーネント４０は、フィルタリング・ステップの残りを実行する。ステップ３Ａでは、第２フィルタリング・コンポーネント４０がＩＰパケットを、図４Ａの中で示されるようにパケットのデータ部分からそれらのタイプを識別するために検査する。パケットは以下の４カテゴリー、Ｈ．２２５、Ｈ．２４５、ＲＴＰおよびＲＴＣＰのうちの１つでありうる。残るパケット・タイプの処理が図３Ｂ〜３Ｄの中でそれぞれ示される一方、Ｈ．２２５パケットのための方法のステップは図３Ａの中で示される。
【００７１】
一旦パケットのタイプが決定されると、図２の中で示されるように、パケット自身およびそのパケット・タイプに関する情報の両方は、管理モジュール２８に共にパスされる。図２中にまた示される通り、記録プロセスが実行されるように、パケットはその後管理モジュール２８内の適切なコンポーネントにパスされる。図３Ｃおよび３Ｄに関してより一層詳しく下記に詳述されるように、記録されたパケットは格納モジュール３０に格納される。
【００７２】
パケットがそのパケットのヘッダによりＨ．２２５パケットであると判明した場合（図４Ｂを参照のこと）、図２中で示されるように、パケットは管理モジュール２８内のＨ．２２５呼出コントロール・モジュール７８にパスされる。管理方法のステップは図３Ａを参照し、以下のとおりである。図３Ａのステップ４Ａでは、Ｈ．２２５パケットが、それがセット・アップ・パケットかどうか判別されるために、パケット中のデータの構造によって検査される。この構造はＨ．２２５．０規格で指定され、少なくとも次のタイプの情報を含む。
プロトコル・アイデンティファー（サポートされるＨ．２２５．０のバージョン），
ｈ２４５アドレス（呼出のエンドポイントかゲートキーパーによってＨ．２４５信号が確立されるための特定輸送アドレス）、
ソース・アドレス（送信源Ｈ．３２３＿ＩＤ），
ソース・インフォ（呼出される参加者が、その呼出がゲートキーパーを含むかどうか決定できるようなエンドポイント・タイプを含む），
宛先アドレス（これはエンドポイントが接続を望むアドレスである）
Ｈ．２２５．０規格で指定されるように、他のタイプのデータもまた要求される。Ｈ．２２５呼出コントロール・モジュール７８は、パケットがセット・アップ・パケットかどうかこのデータ構造によって決定することができる。
【００７３】
このパケットがセット・アップ・パケットである場合、方法の第一枝がそれに続く。送信源ポートはＨ．２２５ヘッダ７２の送信源ポート・フィールド７４から取られ、また宛先ポートは宛先ポート・フィールド７６から取られる（図４Ｂを参照のこと）。ステップ５Ａでは、図１のデータベース２６が、その対応ターミナルのどれかが記録ターミナルとして定義されるかどうか、すなわちこのターミナルのＩＰアドレスによって開始されたコミュニケーション・セッションがモニターされるべきかどうかを決定するために検査される。真の場合、ステップ６Ａでターミナルのステータスは送信源ポートに対応するターミナルからのスタート・セッション・リクエストとしてセットされる。
【００７４】
あるいはまた、パケットはステップ４Ｂにおいて接続パケットであるかどうか検査され、それはパケット中のデータ構造によって決定される。この構造はＨ．２２５．０規格で指定され、少なくとも次のタイプの情報を含んでいる。
プロトコル・アイデンティファー（サポートされるＨ．２２５．
０のバージョン），
ｈ２４５アドレス（呼出のエンドポイントかゲートキーパーによってＨ．２４５信号が確立されるための特定輸送アドレス），
宛先アドレス（呼出者が、その呼出がゲートキーパーを含むかどうか決定できるようにするエンドポイント・タイプを含む），
コンフェランスＩＤ（特別のコンフェランスを識別するため唯一のＩＤ数を含む）
パケットが接続パケットである場合、方法の第２枝がそれに続く。ステップ５Ｂではターミナルのステータスを示すフラグが、ターミナルのステータスがスタート・セッション・リクエストとしてセットされているかどうかを決定するため検査される。ステップ６Ｂでは、呼出信号の詳細が格納媒体３０中の呼出進行データベース７８中に格納される（図２を参照のこと）。これらの詳細は好ましくは、送信源及び宛先ＩＰアドレス、送信源および宛先ポート、コミュニケーション・セッションの開始タイムおよびその他の適切な情報を含む。ステップ７Ｂでは、ターミナルのステータスは「ロジック・チャンネルを待つ」にセットされている。
【００７５】
パケットが第２フィルタリング・コンポーネント４０によりＨ．２４５パケットであると判明した場合、図２中で示されるようにパケットは管理モジュール２８中のＨ．２４５呼出コントロール・モジュール８２にパスされる。このようなＨ．２４５パケットはＨ．２４５信号のために必要である。Ｈ．２４５信号はエンドポイントおよびマルチポイント・コントローラー、あるいはエンドポイントおよびゲートキーパーといった２つのエンドポイント間で確立される。（そのようなエンドポイントの例および記述に関しては下図６および７を参照のこと）各エンドポイントはコミュニケーション・セッションの一部として、呼出の実行及び呼出の受信をすることができる。しかしながら、本発明のシステムはそのようなコミュニケーション・セッションを開始するというよりも、単にモニターするものである。したがって、本発明のシステムは、セッションの格納装置および後の再構築に必要なデータ・パケットを有効に記録するために、コミュニケーション・セッションがいつ開始したか決定する目的でＨ．２４５信号を使用する。
【００７６】
Ｈ．２４５パケットの管理方法のステップは、図３Ｂに関して、以下のとおりである。図３Ｂのステップ１Ａでは、Ｈ．２４５パケットは、それがオープン・ロジカル・チャンネル要求パケットかどうかを決定するために検査される。それがそうである場合、それからステップ２Ａで、ターミナル・ステータスはステータスが「ロジカル・チャンネルを待つ」であるかどうかを決定するために検査される。もしそうであれば、ステップ３Ａでターミナル・ステータスは、「認識を待つ」にセットされる。
【００７７】
あるいはまた、Ｈ．２４５パケットはステップ１Ｂに示されるように、それがオープン・ロジカル・チャンネル認識パケットかどうかを決定するために検査される。そうである場合、それからステップ２Ｂで、ターミナル・ステータスはステータスが「認識を待つ」であるかどうかを決定するために調べられる。もしそうであれば、それからステップ３Ｂでターミナル・ステータスは、「ターミナル能力を待つ」にセットされる。ステップ４Ｂにおいて、「呼出した」の輸送アドレス、又は、宛先ターミナルは保存される。この輸送アドレスは、ヘッダ７２の宛先ポート・フィールド７６から受け取られる（図４Ｂを参照）。Ｈ．２２５とＨ．２４５のパケットが同一のヘッダ構造を持っていることが注目されるべきである。
【００７８】
さらにあるいはまた、Ｈ．２４５パケットはステップ１Ｃに示されるように、それがターミナル能力セット・パケットかどうかを決定するために検査される。それがそうである場合、それからステップ２Ｃでは、ターミナル能力は呼出進行データベース８０に保存される（図２を参照）。ステップ３Ｃにおいて、ターミナル・ステータスは、コミュニケーション・セッションが開かれると決定し、管理モジュール２８がＲＴＰデータ・パケットをすぐに受け取ることができるような「呼出プロセス中」にセットされる。
【００７９】
パケットが第２のフィルタリング・コンポーネント４０によってＲＴＰパケットとなることが決定されている場合、図２に示されるように、パケットは管理モジュール２８内のＲＡＳ（登録、許可及びステータス）コントロール・モジュール８４にパスされる。ＲＴＰパケット用の管理方法のステップは、図３Ｃに関して、以下のとおりである。図３Ｃのステップ１において、ターミナル・ステータスは、それが「呼出プロセス中」であるかどうかを確かめるために検査される。もしそうであれば、それからステップ２で、ＲＴＰパケットは格納媒体３０内のＲＴＰデータベース８６に保存される（図２を参照）。図４Ｃは、パケットが得られたコミュニケーション・セッションを識別するために使用することができるＲＴＰパケット・ヘッダの構造を示す。
【００８０】
最後に、パケットが第２のフィルタリング・コンポーネント４０によってＲＴＣＰパケットであると決定された場合、図２の中で示されるように、パケットは管理モジュール２８内のＲＴＣＰコントロール・モジュール８８にパスされる。ＲＴＣＰパケット用の管理方法のステップは、図３Ｄに関して、以下のとおりである。図３Ｄのステップ１において、ターミナル・ステータスは、それが「呼出プロセス中」であるかどうかを確かめるために検査される。もしそうであれば、それからステップ２において、ＲＴＣＰパケットは格納媒体３０内の呼出進行データベース８０の中で保存される（図２を参照）。図４Ｄは、パケットが得られたコミュニケーション・セッションを識別するために使用することができるＲＴＣＰパケット・ヘッダの構造を示す。
【００８１】
したがって、図３Ａ〜３Ｄは、図１及び２の中で示されるような本発明のシステムによって記録されるように、記録されたコミュニケーション・セッションを構成するデータ・パケットのフィルタリングや格納に関する本発明の方法を例示する。もちろん、そのようなコミュニケーション・セッションの記録に加えて、本発明のシステムはまたユーザーへ対してこれらのコミュニケーション・セッションを検索し再生することができる。格納されたデータ・パケットから構成された、格納されたコミュニケーション・セッションは、音声ユニット３４および映像ユニット３６と関連する図２のデータ復元ユニット３２によって検索され、表示される。興味のある検索及び再実行のセッションの方法は、本発明にかかるシステムの一定の他の相当する部分が図２に示されている一方で、図５に示される。
【００８２】
図５のステップ１において、ユーザーは、検索され再び実行されるコミュニケーション・セッションに関する情報を入力する。この情報はなるべくターミナル数、又は興味のあるコミュニケーション・セッションの参加者の少なくとも１人に関する他の指示情報すなわち、セッションがスタートした時間及びセッションが終了した時間を含んでいる。しかしながら、あるいはまた、十分な情報が興味のあるコミュニケーション・セッションが識別されるために提供される限り、他の情報はこの情報の代わりに含まれる。
【００８３】
図５のステップ２において、呼出進行データベース８０（図２を参照）は、指定された時間範囲にコミュニケーション・セッション（複数可）の詳細を見つけるためにデータ復元ユニット３２によって探索される。その後、これらの詳細は、呼出範囲の興味のある少なくとも１つのコミュニケーション・セッションを見つけるためにユーザーによって入力された情報と比較される。
【００８４】
ステップ３において、格納媒体３０（図２を参照）のＲＴＰデータベース８６は、指定された呼出範囲の少なくとも１つのコミュニケーション・セッションからのすべてのデータ・パケットを本質的に見つけるために、データ復元ユニット３２によって再び探索される。ステップ４において、任意に及びなるべく、音声部分コミュニケーション・セッションがステレオに記録された場合、その時、次にデータ・パケットは異なる音声チャンネルに分割される。
【００８５】
ステップ５において、データ・パケットは、データ復元ユニット３２内のＲＴＰ（リアル・タイム・プロトコル）ソフトウェア・モジュール９１を通って、データ復元ユニット３２によって復元される。ＲＴＰソフトウェア・モジュール９１は、各パケットのタイムスタンプに関する各チャンネル内のデータ・パケットを要求する。図４Ｃに示すように、ＲＴＰパケット・ヘッダ９２はいくつかの重要なフィールド、すなわちタイムスタンプ・フィールド９４、同調送信元（ＳＳＲＣ）確認フィールド９６、及び提供送信元（ＣＳＲＣ）確認フィールド９８を特色とする。ＳＳＲＣフィールド９６は、独特な識別アドレス（ＳＳＲＣ確認器）を持っているＲＴＰパケット（送信器）の送信元を決定するために使用される。ＣＳＲＣフィールド９８でのＣＳＲＣ確認器は、多数の参加者との会議の中で使用され、すべての参加者のＳＳＲＣ確認器を示す。タイムスタンプ・フィールド９４は、各パケット中のデータが表示されるべき相対的な時間を決定するために、ＲＴＰソフトウェア・モジュール９１によって使用される。
【００８６】
例えば、むしろ、１人の音声スピーチの音声ストリーム・データは、映像ストリーム（「唇同調」として知られているプロセス）に示されるようにその人の唇の動きと同調される。音声および映像データ・パケットは同時に到着できず、したがってわずかに異なるタイムスタンプを持っているので、そのような同調は、ある相対的な時点において音声及び映像データを単に再生する以上のことを要求する。
【００８７】
一旦データ・パケットが正確に同調したならば、音声データの表示のコントロールは、その後１又はそれ以上の音声コーデック（図２を参照）に関するデータ復元ユニット３２の音声コンポーネント１０２によって実行される。映像データの表示のコントロールは、その後、１又はそれ以上の映像コーデック（図２を参照）に関する映像コンポーネント１００よって実行される。
【００８８】
好適なコーデックとしては特に限定はされないが、ボイス周波数のパルス・コード・モデュレーション（ＰＣＭ）であるＣＣＩＴＴ規格Ｇ．７１１を使用する音声コーデック（１９８８）、６４ｋｂｉｔ／ｓ中の７ｋＨｚ音声コーディングであるＣＣＩＴＴ規格Ｇ．７２２を使用する音声コーデック（１９８８）、スピーチコーダー、即ち５．３及び６．３Ｋｂｐｓにおいて送信しているマルチメディア・コミュニケーションのための二重のレート・スピーチ・コーダーであるＩＴＵ−Ｔ規格Ｇ．７２３．１を使用する音声コーデック（１９９６）、低遅延符号励振線形予測を使用する１６ＫｂｐｓにおいてのスピーチのコーディングであるＣＣＩＴＴ規格Ｇ．７２８を使用する音声コーデック（１９９２）、共役構造代数符号励振線形予測（ＣＳ−ＡＣＥＬＰ）を使用する８ＫｂｐｓにおいてのスピーチのコーディングであるＩＴＵ−Ｔ規格Ｇ．７２９（１９９６）を使用する音声コーデック、ｐ×６４ｋｂｉｔ／ｓにおいて音声聴覚サービスのための映像コーデックであるＩＴＵ−Ｔ規格Ｈ．２６１（１９９３）を使用する映像コーデック、低ビットレート・コミュニケーションのための映像コーディングであるＩＴＵ−Ｔ規格Ｈ．２６３を使用する映像コーデック（１９９６）、及びほとんどのいかなる他の同類のコーディング・スタンダードを含む。
【００８９】
図２に示すように、音声データは、例えば、拡声器を含むことができる音声ユニット３４によって表示される。映像データは、例えば、ディスプレイ・モニター・スクリーンを含むことができる映像ユニット３６によって表示される。十分に全体のコミュニケーション・セッションが表示されるように、図５のステップ５はその時好適に繰り返される。ステップ６に示すように、コミュニケーション・セッションの各々のデータ・パケットは呼出時間が終了しているかどうかを確認するために検査される。もし個別のセッションが完了しなかったなら、好適にステップ５が繰り返される。あるいはまた、そして好適に、もし呼出時間が終了しているなら、その呼出進行データベース８０は、ステップ７に示すように、他のコミュニケーション・セッションが所定の時間内に記録されたかどうかを確認するために検索される。もし少なくとも１つの他のそのようなコミュニケーション・セッションがあるならば、その時好適に図５の方法は、ステップ２から始まって、繰り返される。
【００９０】
本発明の望ましい実施形態によると、コンピュータ・ロギング・システムのいくつかの構成が可能であり、その例が図６及び７に示される。
【００９１】
図６に示す本発明に係るシステムの最初の実施形態によると、本発明によれば、典型的な基本的構成システム１０４は、図１及び２に示されるように十分に、一つのコミュニケーション・セッション管理ユニット１３を含む。コミュニケーション・セッション管理ユニット１３はＬＡＮ１０６のような独立イントラネットにおいてコミュニケーションを管理する。ＬＡＮ１０６は、コミュニケーション・セッション管理ユニット１３、及びＨ．３２３プロトコルに従う「Ｔ１」、「Ｔ２」などと呼ばれる多数のターミナル１０８の両方に接続されている。各々のターミナル１０８はリアルタイムに備えるＬＡＮ１０６上のエンドポイントであり、そしてそれは、他のターミナル１０８、ゲートウェイ１１０、又はマルチポイント・コントロール・ユニット（ＭＣＵ）１１２を持つ両方向のコミュニケーションである。このコミュニケーションはコントロール、表示、音声ストリーム、映像ストリーム、及び／又はデータから成る。ターミナル１０８は音声のみ、音声とデータ、音声と映像、あるいは音声、データと映像に対するそのようなコミュニケーションを任意で提供することができるだけである。「従来技術の記述」の欄で前述したとおり、Ｈ．３２３実体は「ＬＡＮ電話」として音声及び／又は映像コミュニケーションを提供することができるターミナルとなることができるが、同じく独立音声や映像電話となることもできる。
【００９２】
ゲートウェイ１１０（ＧＷ）はＨ．３２３に従って構築され、リアルタイムに備えるＬＡＮ１０６上のエンドポイントであり、そしてそれはＬＡＮ１０６上のターミナル１０８とＷＡＮ（示されていない）上の他の適当なターミナル、又は他のそのようなゲートウェイ（示されていない）の間の両方向のコミュニケーションである。他の適切なターミナルは規格Ｈ．３１０（Ｂ−ＩＳＤＮの上のＨ．３２０）、Ｈ．３２０（ＩＳＤＮ）、Ｈ．３２１（ＡＴＭ）、Ｈ．３２２（ＧＱＯＳ−ＬＡＮ）、Ｈ．３２４（ＧＳＴＮ）、Ｈ．３２４Ｍ（モバイル）、及びＶ．７０（ＤＳＶＤ）に従っているこれらを含む。
【００９３】
ＭＣＵ１１２は３あるいはそれ以上のターミナル１０８及びゲートウェイ１１０が、マルチポイントの会議に参加することができるようにするＬＡＮ１０６上のエンドポイントである。
【００９４】
好適に、システム１０４はまたゲートキーパー（ＧＫ）１１４を特徴とし、そしてそれはアドレス翻訳を提供し、ターミナル１０８、ゲートウェイ１１０及びＭＣＵｓ１１２に対しＬＡＮ１０６へのアクセスをコントロールするＬＡＮ１０６上のＨ．３２３実体である。ゲートキーパー１１４もまた、ターミナル１０８、ゲートウェイ１１０、及び帯域管理やロケーティング・ゲートウェイ１１０のようなＭＣＵ１１２に対して他のサービスを提供することができる。好適に、正しいＩＰアドレスが「その場その場で」決定されるように、ゲートキーパー１１４はＬＡＮ１０６上にターミナル１０８のＩＰアドレスに決定される。
【００９５】
加えて、ＬＡＮ１０６は電子ホワイトボード、さらにイメージ転送、ファイル交換、データベース・アクセスなどのような通常のＴ．１２０データアプリケーションのために非音声の視覚の装置をサポートすることができる。
【００９６】
基本的なシステム１０４において、一つの、独立コミュニケーション・セッション管理ユニット１３は、ＬＡＮ１０６上の２又はそれ以上のターミナル１０８間のどちらか、又はターミナル１０８の１又はそれ以上が参加者であるいかなる呼出の音声及び／又は視覚呼出のモニタリング、ロギング、及び検索のために使われる。
【００９７】
しかし、ゲートキーパー１１４を含む図６でのシステムの好適な実施例において、図７でも同様であるが、一度コミュニケーション・セッションが開かれれば、好ましくＲＡＳコントロール・モジュール８４も管理コントロール・モジュールとシステムの構成に必要なＮＩＣ１６との間でＲＡＳの信号伝送を実行する。エンドポイントとゲートキーパー間での登録、認可、帯域幅変換、ステータスを実行したり、手順を自由にするために、その信号伝送はＨ．２２５．０メッセージを使用している。これらのメッセージはＲＡＳ信号チャンネルを通り、それは呼出信号チャンネルとＨ．２４５コントロール・チャンネルから独立している。Ｈ．２４５がオープン・ロジカル・チャンネルの手順ではＲＡＳ信号チャンネルを確立するために使用することはできない。ゲートキーパー（ゾーン）を含んだＬＡＮ環境下で、ＲＡＳ信号チャンネルはエンドポイントからゲートキーパーまでの間で開かれている。ＲＡＳ信号チャンネルはＨ．３２３エンドポイント間ではどの他のチャンネルの確立よりも優先して開かれることになる。
【００９８】
図７はシステム１１６が構成するゾーンとして本発明におけるシステムの２番目の実施例を示す。ゾーン１１８は、たった１つのゲートキーパー１１４がコントロールしているターミナル（Ｔｘ）１０８、ゲートウェイ（ＧＷ）１１０、マルチコントロールユニット（ＭＣＵｓ）１１２の集合体である。ゾーン１１８では少なくとも１つのターミナル１０８が含むが、しかし、一以上のゲートウェイ１１０もしくはＭＣＵｓ１１２が含まれなければならない必要はない。ゾーン１１８には例示したように１つのゲートキーパー１１４を含む。しかし、例示した好適な実施例では、ゾーン１１８はＬＡＮトポロジーから独立しておいたほうが好ましいし、ルーター（Ｒ）１２２もしくは他の類似した装置のようなものを用いるために接続したマルチＬＡＮセグメント１２０を含んでおいたほうが好ましい。
【００９９】
本発明によって、どの監視下にあるＬＡＮセグメント１２０はローカル・コミュニケーション管理ユニット１２４が存在し、以下に２つ例を示す。本発明によって、中央管理ユニット１２６が全てのローカル・コミュニケーション管理ユニット１２４をコントロールする。集中データベースとコントロール・サービスに加えて、中央管理ユニット１２６によって一つのポイントから音声や映像コミュニケーション・セッションのリアルタイム管理やオフライン復元のために用いることができる。中央管理ユニット１２６が任意的であり好ましくは格納機能のないローカル・コミュニケーション・ユニット１２４を構築することにおいて類似した専用のユニットであるか、もしくは、一つのステーションにおけるローカル・コミュニケーション管理ユニット１２４と中央管理ユニット１２６との両方の機能を供給するため、中央管理ユニット１２６はあるいは好ましくはローカル・コミュニケーション管理ユニット１２４を統合したものである。ローカル・コミュニケーション管理ユニット１２４は図１、２に示したように実質的に好ましくコミュニケーション管理ユニット１３になっているか、または好んでローカルなコミュニケーション・セッションを検索したり表示したりする能力の無いシンプルなユニットになっているかである。
【０１００】
また、本発明の他の好適な実施例（図示せず）としてクライアント・サーバーのアーキテクチャーをベースとしたマルチ・ユーザー・オペレーションは基本的なシステム１０４とゾーン・システム１１６のために好ましくサポートされている。どの特定ユーザーにも認可レベルによって決定された監視／検索と管理機能を供給できれば、ＬＡＮ上どこででも“クライアント”ステーションは無制限に接続可能となる。
【０１０１】
図８において、まだ本発明の他の好適な実施例を、図８に示したが、スイッチング環境により分割されたインターネット・プロトコル（ＩＰ）環境の課題をアドレスする。
【０１０２】
ＩＰ環境下とインターフェイスさせたとき、記録システムでは次のような課題が経験される。
セントラル・スイッチング・マトリックスがないので、 記録システムが位置付けしてあるサイトでの呼出を保存する方法を供給することなしにＷＡＮを通って、どのような拡張子のＡおよびＢ間でのボイスストリームを送ることができる。
ＩＰネットワークはスイッチ・ボックス、ルーターとブリッジから成り立っているので、ネットワーク・トポロジーには記録することにネガティブな影響がある。
ほとんどのマルチ・メディアＩＰプロトコル・スイートはコード変換を含んではいない。特に、Ｈ．３２３プロトコル・スイートはコード変換に欠けている。記録システムが信号を無変換であるためには、記録システムが記録された呼出とともに“リーガル”参加者として役割を果たす必要がある。記録された呼出である“リーガル”参加者となる唯一の方法は、呼出が記録システムが会議のメンバーの一員となっている会議電話へと変わることである。マルチ・メディアＩＰプロトコルは音声や映像ＣＯＤＥＣＳ（Ｇ．７１１、Ｇ．７２２、Ｇ．７２８，Ｇ．７２３，Ｇ．７２９、ＩＩ．２６１、ＩＩ．２６３）のいくつかを定義している。このようにして、例えば、もしボイスや映像を異なったＣＯＤＥＣＳをもちいて記録したり格納したりしても、記録プレイバック操作において記録システムはあるＣＯＤＥＣＳから他のエンドポイントごとの他のものに変換する機能を持つはずである。
【０１０３】
図６のシステム１０４は標準Ｈ．３２３環境下で使用を予定するものである。ターミナル１０８は電話会話それ自体の間か、もしくはゲートウェイ１１０を通ったＰＯＴＳ電話での電話会話を伝える。これらの呼出をするために、目的のターミナルまたは、Ｈ．２２５プロトコル下の呼出をセットアップしたり、Ｈ．２４５プロトコル下のＲＴＰストリーム・キャラクターをやり取りするためのＲＡＳプロトコルを使用するＬＡＮ上でのゲートウェイを見つけるために、ターミナル１０８はゲートキーパー１１４とコミュニケーションをする。これらすべてのプロトコルはＨ．３２３に帰属していることに注意しておかなければならない。ＲＡＳ、Ｈ．２２５、Ｈ．２４５プロトコル下でゲートキーパー１１４とのコミュニケーションは呼出の信号部分であり、実際のボイスや映像を伝送するのに使用する呼出のＲＴＰやＲＴＣＰストリームを確立するために使用されている。ＭＣＵ１１２は３もしくはそれ以上の参加者で会議をすることを可能としてくれる。前述のコミュニケーション全てをＬＡＮ１０６上で行われる。
【０１０４】
コミュニケーション・セッション管理ユニット１３によって信号パケットとＲＴＰもしくはＲＴＣＰパケットのどちらでも、全てのパケット会話を区別する方法では、コミュニケーション・セッション管理ユニット１３はＬＡＮ１０６に接続されている。従来技術の接続方法は以下に含む。
ハブを用いる。その場合、全てのパケットはハブの中の全てのポートをパスする；および、
スイッチされたハブでの他のポートによってスイッチされたハブの戦略的なポートを監視する。
おそらく二番目の選択では戦略的なポートは、１つ以上のゲートウェイ１１０へと接続したスイッチされるハブのポートであり、その場合、全ての外への呼出は記録されることとなる。この例示として、ゲートウェイ１１０はスイッチング・ハブが監視するポートに接続され、コミュニケーション・セッション管理ユニット１３はスイッチング・ハブが監視するポートに接続されている。
【０１０５】
コミュニケーション・セッション管理ユニット１３はＲＴＰやＲＴＣＰの会話パケットを区別したり、これらのパケットからボイスや映像データを抽出する。これらのデータと電話拡張ナンバーもしくは、拡張子での個人名と関連付けるために、Ｈ．３２３信号は解析されなければならない。この解決方法は、Ｈ．３２３プロトコル・スイート内に信号プロトコルがないＶｏｉｃｅＯｖｅｒＩＰシステムでは機能しない。そのような信号プロトコルにはＳＩＰ、ＭＧＣＰ、シスコが所有するスキニー・プロトコルを含んでいる。
【０１０６】
信号プロトコルに依存してはいない本発明システムの３番目の実施例１５０を、図８に示す。システム１５０のおいて、ボイスや映像データは、図６のシステム１０４のように、コミュニケーション・セッション管理ユニット１３がＲＴＰやＲＴＣＰパケットを区別することで記録される。システム１５０の革新はコミュニケーション・セッション管理ユニット１３とゲートキーパー１１４との間のリンク１６０を加えた点にある。特にリンク１６０はコミュニケーション・セッション管理ユニット１３の管理モジュール２８とゲートキーパー１１４と接続する。リンク１６０はコミュニケーション・セッション管理ユニット１３へのＣＴＩ（コンピュータ電話統合）のデータやＣＤＲ（呼出データ記録）のデータを供給する。これらのデータは図６のシステム１０４でのＨ．３２３プロトコルを解析することで検索されるデータを置き換えることができる。これらのデータは話者のＩＰアドレスを含み、他の身元確認情報、たとえば、拡張子ナンバー、話者の名前、リンク１６０を通り到達した全ての情報も含んでいる。任意で話者のＩＰアドレスも他の身元確認情報から推定できる。これらのデータは拡張子ナンバー、話者の名前、リンク１６０を通り到達したあらゆる他の情報を呼出に関連付けるコミュニケーション・セッション管理ユニット１３によって用いられる。
リンク１６０はいくつかの方法で実施できるであろう論理的リンクである。また、次のことを含んでいる。
ＶｏｉｃｅＯｖｅｒＩＰ呼出のために用いられる同じＬＡＮである。この方法ではコミュニケーション・セッション管理ユニット１３にハードウェアを加える必要はない。
ＶｏｉｃｅＯｖｅｒＩＰ呼出のために用いられるＬＡＮから分割されたＬＡＮである。この選択では、コミュニケーション・セッション管理ユニット１３にはリンク１６０のための特別に用いる追加ネットワークアダプターである、ＮＩＣ１６に類似したもの、を含んでいる。
コミュニケーション・セッション管理ユニット１３のシリアル・ポートの１つを用いられるシリアル接続である。
なぜなら、リンク１６０は論理的なリンクであり、図８にはこれらの実施方法の３つともすべて示してある。
図８のシステム１５０は次の点において有益である。
ＶｏｉｃｅＯｖｅｒＩＰシステムで用いられる信号のタイプに依存していない。システム１５０はすべての信号タイプに機能する。
リンク１６０はＨ．３２３信号プロトコルで検索できるよりもさらに多くの情報を伝送することができる。たとえば、この情報は保険証書番号などの特別なアプリケーション情報が保険会社のコール・センターを構成であるシステム１５０の場合として当てはまることができる。
コミュニケーション・セッション管理ユニット１３に届くメッセージはより少なくなるので、システム１５０はコミュニケーション・セッション管理ユニット１３によるＣＰＵの負荷を減じることができ、結果として、同時に記録できるチャンネル数が増大する。
【０１０７】
図８のシステム１５０は次のような市販の入手可能な部品を用いることにより実施のための費用が削減できる。
ゲートキーパー１１４：ＣａｌｌＭａｎａｇｅｒ（登録商標）３．０　ＣｉｓｃｏＳｙｓｔｅｍｓ，Ｉｎｃ．，Ｓａｎ Ｊｏｓｅ ＣＡ
リンク１６０：ＣａｌｌＭａｎａｇｅｒ（登録商標）３．０を接続するＡ　ＪＴＡＰＩ（登録商標）
ターミナル１０８：ＶＩＰ（登録商標）３０もしくはＳＰ（登録商標）１２＋、両方ともにＣｉｓｃｏＳｙｓｔｅｍｓ，Ｉｎｃ．，Ｓａｎ Ｊｏｓｅ ＣＡ
ゲートウェイ１１０：Ｃａｔａｌｙｓｔ（登録商標）３６４０、Ｃｉｓｃｏ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，Ｓａｎ Ｊｏｓｅ ＣＡ
ＭＣＵ１１２：ＣａｌｌＭａｎａｇｅｒ（登録商標）３．０用会議プラグ
コミュニケーション・セッション・管理ユニット１３：Ｎｉｃｅｌｏｇ（登録商標）、ＮｉｃｅＳｙｓｔｅｍｓ Ｌｔｄ．，Ｒａ‘ａｎａｎａ，ＩｓｒａｅｌＬＡＮ１０６：Ｓｗｉｔｃｈ　Ｈｕｂ　Ｃａｔａｌｙｓｔ（登録商標）２９２４、ＣｉｓｃｏＳｙｓｔｅｍｓ，Ｉｎｃ．，Ｓａｎ Ｊｏｓｅ ＣＡ
上述したものは単に例としてあげることを意図し、多くの他の実施例が本発明の趣旨と範囲内にあれば可能である。
【図面の簡単な説明】
【図１】
本発明における模範的なコミュニケーション・セッション監視システムの略ブロック図である。
【図２】
図１のシステムを実行するために必要なソフトウェア・モジュールの略ブロック図である。
【図３Ａ】
本発明における模範的なフィルターをかける方法と記録方法をフローチャートに表したものである。
【図３Ｂ】
本発明における模範的なフィルターをかける方法と記録方法をフローチャートに表したものである。
【図３Ｃ】
本発明における模範的なフィルターをかける方法と記録方法をフローチャートに表したものである。
【図３Ｄ】
本発明における模範的なフィルターをかける方法と記録方法をフローチャートに表したものである。
【図４Ａ】
本発明と関係したＨ．２２５（図４Ａ）のヘッダを表した略ブロック図である。
【図４Ｂ】
本発明と関係したＨ．２４５（図４Ｂ）のヘッダを表した略ブロック図である。
【図４Ｃ】
本発明と関係したＲＴＰ（図４Ｃ）のヘッダを表した略ブロック図である。
【図４Ｄ】
本発明と関係したＲＴＣＰ（図４Ｄ）のヘッダを表した略ブロック図である。
【図５】
本発明における模範的なコミュニケーション・セッション・プレイバック方法のフローチャートである。
【図６】
本発明における図１．２でのコミュニケーション・セッション監視システムをもちいる基本的なシステムを模範的な１番目の実施例を略ブロック図で表したものである。
【図７】
本発明におけるゾーン・システムの模範的な２番目の実施例を略ブロック図で表したものである。
【図８】
本発明を他の実施例に用いた場合における模範的なパッシブ記録システムを略ブロック図で表したものである。
【図１】
2004509563.tif 000003
【図２】
2004509563.tif 000004
【図３Ａ】
2004509563.tif 000005
【図３Ｂ】
2004509563.tif 000006
【図３Ｃ】
2004509563.tif 000007
【図３Ｄ】
2004509563.tif 000008
【図４Ａ】
2004509563.tif 000009
【図４Ｂ】
2004509563.tif 000010
【図４Ｃ】
2004509563.tif 000011
【図４Ｄ】
2004509563.tif 000012
【図５】
2004509563.tif 000013
【図７】
2004509563.tif 000014
【国際公開パンフレット】
2004509563.tif 000015
2004509563.tif 000016
2004509563.tif 000017
2004509563.tif 000018
2004509563.tif 000019
2004509563.tif 000020
2004509563.tif 000021
2004509563.tif 000022
2004509563.tif 000023
2004509563.tif 000024
2004509563.tif 000025
2004509563.tif 000026
2004509563.tif 000027
2004509563.tif 000028
2004509563.tif 000029
2004509563.tif 000030
2004509563.tif 000031
2004509563.tif 000032
2004509563.tif 000033
2004509563.tif 000034
2004509563.tif 000035
2004509563.tif 000036
2004509563.tif 000037
2004509563.tif 000038
2004509563.tif 000039
2004509563.tif 000040
2004509563.tif 000041
2004509563.tif 000042
2004509563.tif 000043
2004509563.tif 000044
2004509563.tif 000045
2004509563.tif 000046
2004509563.tif 000047
2004509563.tif 000048
2004509563.tif 000049
2004509563.tif 000050
2004509563.tif 000051
2004509563.tif 000052
2004509563.tif 000053
2004509563.tif 000054
2004509563.tif 000055
2004509563.tif 000056
2004509563.tif 000057
2004509563.tif 000058
2004509563.tif 000059
2004509563.tif 000060
【国際公開パンフレット（コレクトバージョン）】
2004509563.tif 000061
2004509563.tif 000062
【国際公開パンフレット（コレクトバージョン）】
2004509563.tif 000063
2004509563.tif 000064
【国際調査報告】
2004509563.tif 000065
2004509563.tif 000066
2004509563.tif 000067
2004509563.tif 000068
2004509563.tif 000069
2004509563.tif 000070