JP2000504892A

JP2000504892A - 音声インターネット伝送システム

Info

Publication number: JP2000504892A
Application number: JP9528574A
Authority: JP
Inventors: ウィルクス，ティー・クレイ; ラデュロビック，アレックス
Original assignee: アイ―リンク・ワールドワイド・インコーポレーテッド
Priority date: 1996-02-09
Filing date: 1997-02-05
Publication date: 2000-04-18
Also published as: KR20070102757A; US20020067739A1; CN1167243C; CN1214835A; JP2009284539A; EP0878086A1; US6438124B1; KR100923483B1; KR100847335B1; AU2251497A; WO1997029581A1; JP2006325171A; KR20080074998A; KR19990082421A; EP0878086A4; KR100892950B1

Abstract

(57)【要約】会話のいずれの側でもコンピュ−タを用いる必要がなく、また、会話をしている者の間の距離に関係なく長距離電話料金を発生させることなく、インタ−ネット（１６）を介して会話をすることを可能にするボイス・インタ−ネット送信システムである。好適実施例では、この装置は、インタ−ネット能力を有していない２つのデバイスから構成されている。これらのデバイスは、インタ−ネット（１６）に接続されており、デュ−プレックス又はシンプレックスのどちらかで、デジタル化され圧縮され暗号化された変換を含むインタ−ネット・フォ−マットされたデ−タのパケットを、デバイスの間で送信する。換言すると、両者の間の距離とは無関係に、長距離電話料金を発生させずに、通常の電話（３０）を取り上げて、相手側と会話することができるのである。特別な電話は必要なく、コンピュ−タが特別なソフトウェアを動かしているのでもない。これを可能にする装置は、インタ−ネット・アクセス・ノ−ド、すなわち、ボイスエンジンVoiceEngines（３２、３４）である。これらのロ−カルなインタ−ネット・ボイスエンジン（３２、３４）は、デジタル化され圧縮され暗号化された、デュ−プレックス又はシンプレックスな、インタ−ネット音声通信サ−ビスが与えられる。

Description

【発明の詳細な説明】音声インタ−ネット伝送システム発明の背景１．発明の分野本発明は、広くは、必要とされるインタ−ネット通信プロトコルを使用して情報を伝達する能力を欠いているので、インタ−ネット用に用意されていないデバイス間の通信に関する。特に、本発明は、従来の長距離交換式電話ネットワ−ク回線を用いるのと対照的に、音声信号がインタ−ネットを介して伝達される電話を用いる音声通信を可能にする。２．従来技術種々の技術を組み合せる場合の１つの欠点は、それらの技術がその構成のための共通のハ−ドウェア基盤を多くの場合共有していないことにある。このことは特に通信技術において真実である。というのは、通信技術では、典型的に、デ− タが伝送のためにフォ−マットされる専用の（プロプライエタリな）プロトコルを有し、またデ−タが移動するハ−ドウェア構成に互換性がないからである。しかし、種々の技術のそれぞれが他の技術に優る利点を与える場合もあり得る。通信用の経路を与える共通のゴ−ルを共有する２つの技術は、公共的に交換式電話ネットワ−ク（ＰＳＴＮ）と、インタ−ネットとである。電話は典型的に音声通信デバイスであるが、同一の電話回線を介してファクシミリ及びモデム・デ −タ通信の融合が成功してきたことは周知である。これに対して、インタ−ネットは、最近までコンピュ−タによるデ−タ通信の専用であった。しかし、これらの技術は共に、望ましい特性を有している。すなわち、−方は、信頼性が高く簡単な音声通信であり、他方は、長距離電話料金を発生させずに世界中に高速のコンピュ−タ・デ−タ通信を可能にしている。ここで、他方の技術は、通信技術を特にそのために設計されてはいない伝達媒体に強制する際の固有の欠点に拘らず、この望ましい特性を大まかに利用するように作られている。例えば、ＰＳＴＮを介するコンピュ−タ・デ−タ伝送は、ＰＳＴＮラインに接続されたモデムを備えたコンピュ−タを介して、遅いとまでは言わないが、成功裏に達成される。そのようなコンピュ−タは、そのように設備された別のコンピュ−タにアクセスして、情報を直接交換することができる。その主たる欠点は、コンピュ−タが相互にロ−カル・テレフォン・コ−ルよりはるかに離れて設置されている場合に、呼出し人が長距離の通話料金を負担しなければならないことである。ＰＳＴＮを介するコンピュ−タ・データ伝送におけるわずかな改善は、モデムを介してアクセスされる多数のサ−ビスがロ−カル・テレフォン・アクセスを提供し始めたときに行われた。これは、そのサービスにアクセスする人口の多い多数のセンタ−のまわりにロ−カル・テレフォン番号を付与することによって達成された。長距離のテレフォン・レ−トに対して包括契約を取り決めることによって、このサ−ビスは、長距離の通話料金をかけずにそれが達成される手段を提供した。しかし、この改善にも拘らず、コンピュ−タ・デ−タを伝送するためにＰＳＴＮを使用する場合には幾つかの欠点が存在する。例えば、最も重大な制約の１つは、デ−タ伝送の速度が専用のコンピュ−タ・ネットワ−クの速度より劣ることである。しかし、先に述べたように、インタ−ネットは、インタ−ネットを構成する物理的伝送媒体の性質の故に、ＰＳＴＮでは成し得ない幾つかのユニ−クな利点を提供する。これらの利点を理解するために、インタ−ネットの開発の背景について理解することが助けとなる。軍部は、全ての状況、特に戦時において、通信ラインを開放しておく重要性を常に認識してきた。政府の関心は、それがＤＡＲＰＡプロジェクトを開始するほど敏感であった。ＤＡＲＰＡは、その存在に関し、単−のノ−ド又はケ−ブルには依存しないコンピュ−タ・ネットワ−クから構成されていた。それどころか、それは、特に、出発点から目的地に至る、複数の通信経路を提供するように設計されていた。このようすれば、デ−タは、様々な経路に沿ってル−ティングすることが可能になる。メッセ−ジの伝送を成功させるためには、そのメッセ−ジの大部分が目的地に到達することに関して、単−の経路に依存する必要はない。ＤＡＲＰＡプロジェクトの後継プロジェクトが、今日ではより広く知られ広く用いられているインタ−ネットである。ＰＳＴＮとインタ−ネットとの間のもう１つの認識すべき重要な相違は、ＰＳＴＮが典型的にはアナログ・デ−タ伝送媒体であり、他方、インタ−ネットはディジタル・デ−タだけを伝送する点である。ＰＳＴＮは、ある状況では、ディジタル・デ−タも伝送可能であるが、ＰＳＴＮを介してディジタル・コンピュ−タ・デ−タを伝送するには、典型的には、そのデ−タを周波数変調されたアナログ信号に翻訳することが必要である。同様に、インタ−ネットを介してアナログ音声デ−タを伝送するには、そのデ−タをディジタル・フォ−マットに翻訳することが必要である。インタ−ネットを介して音声デ−タを伝送することは、音声デ−タのディジタル化が可能という理由だけでなく、ＰＳＴＮのように、インタ−ネットが、ＰＳＴＮがカバ−する範囲を実質的にカバ−する地球規模の伝送媒体であるからである。しかし、インタ−ネットを介する音声伝送を改善するためのはずみを与える動機となる要因は、インタ−ネットの使用に関連するコスト構造にある。良く知られているように、長距離テレフォン・コ−ルには長距離通話料金がかかる。他方、インタ−ネットでは、それに関連する長距離通信料金がかからない。これは、インタ−ネットの能力を拡大することが望ましいとする要点である。この単純なコスト／便益の分析は、インタ−ネットを活用しようとする種々の営利企業の注目を逃さなかった。しかしながら、商業的な努力が実行可能になったのは極く最近のことである。この実行可能性の理由は、極めて短時間の間にインタ−ネットのユ−ザ−数が実質的に増大したからである。テレビジョン広告・印刷媒体スポンサ−及び営利企業は、今日では、ソフィスティケ−トされていはいるが使用の容易なソフトウェア・ツ−ルを用いてインタ−ネット・ユ−ザ−がアクセスできるワ−ルドワイドウェブのＵＲＬアドレスを持っている。インタ− ネットが日常生活で益々普及しているのは、インタ−ネットを利用しアクセスする能力が増大するにつれて、インタ−ネットを利用する人数が増加したからである。インタ−ネットを介しての音声送信能力の提供は、これまでは、必須の付属品（アクセサリ）を備えたコンピュ−タ上でソフトウェアを走らせるコンピュ−タ・ユ−ザ−に焦点を合わせていた。これらの付属品は、音声をディジタル化するソフトウェアと、ディジタル化されるべき音声を受け取るマイクロホンである。コンピュ−タが、インタ−ネットにアクセスするための通路として機能するというのは、全く論理的である。その理由は、これが、インタ−ネットが利用可能となる唯−の方法だからである。こういう言い方の重要性は、インタ−ネットを介して他のデバイスと通信すべきデバイスに対する特定の通信要件にある。即ち、インタ−ネットを介して通信する全てのデバイスは、インタ−ネット通信プロトコルを用いて通信を行う。インタ−ネット通信プロトコルは、インタ−ネットを介しての伝送に適したディジタル・デ−タ・パケットを作成する方法である。当業者であれば認識するところであるが、最も普及したインタ−ネット通信プロトコルは、トランスポ−ト・コネクト・プロトコル／インタ−ット・プロトコル、即ちＴＣＰ／ＩＰである。要するに、インタ−ネットを介して通信するデバイスはＴＣＰ／ＩＰ可能なデバイスである。こうした背景に鑑みて、ＴＣＰ／ＩＰ可能なコンピュ−タを持つ必要なく、インタ−ネットを介して音声デ−タを送信するための方法と装置を提供することは、現状の技術水準に対して優る利益である。即ち、長距離電話料金を発生させることなく、また、いずれかの伝送端にコンピュ−タを必要とすることなく、普通であれば長距離電話をかける距離離れている別の人と話すことは利益である。発明の目的及び概要この発明の目的は、デバイスが音声をディジタル化し適切なインタ−ネット通信プロトコルを用いてその音声を送信することができないものであっても、インタ−ネットを介して、デバイス間で、ディジタル化された音声を送信するための方法及び装置を提供することである。この発明の他の目的は、音声をディジタル化することができず、又は、適切なインタ−ネット通信プロトコルを用いてその音声を送信することができないデバイス間で、ディジタル化された音声を送信するための方法及び装置を提供することである。この発明の更に他の目的は、普通ならば長距離電話料金がかかる距離でインタ −ネットを介して通話するための方法及び装置を提供することである。この発明の別の目的は、コンピュ−タと特別のソフトウェアを必要とする現在のインタ−ネット伝送システムの複雑さを回避することである。この発明の更に別の目的は、電話機を有する者であれば誰でも利用可能な長距離で会話をするための方法及び装置を提供することである。この発明の更に別の目的は、通話者間の会話に対する現行の長距離電話料金に比較して低コストで上記方法及び装置を提供することである。上記方法及び装置の別の目的は、音質の低下のような、コンピュ−タ実施型音声インタ−ネット伝送の制限を回避するシステムを作ることである。この発明のこれらの及び他の目的は、会話のいずれかの側でコンピュ−タを使用する必要なく、及び、会話を行っている人達の距離に無関係に長距離電話料金を招来することなく、インタ−ネットを介して会話することを可能にする音声インタ−ネット伝送システムにおいて提供される。最も広い意味では、この発明の装置は、インタ−ネットに接続し且つデバイス間でディジタル化された会話を含むデ−タのパケットを双方向に伝送することが可能な２つの非ＴＣＰ／ＩＰデバイスからなる。換言するならば、通常の電話機を取り上げ、相手との距離に無関係に、長距離電話料金を招来することなく、会話することができる。特別の電話機は不要であり、特別のソフトウェアを走らせるコンピュ−タも不要である。これを可能にする装置は、インタ−ネット・アクセス・ノ−ド即ちエンジンである。これらのロ−カルなインタ−ネット・アクセス・エンジンは、ディジタル双方向インタ−ネット通信サ−ビスを提供する。ユ−ザ−は、自分にとってロ−カルなインタ−ネット・アクセス・エンジンの電話番号をダイアルすることが好ましい。もしロ−カルでなければ、ユ−ザ−は最小の長距離電話料金を招来するインタ−ネット・アクセス・エンジンにダイアルする。インタ−ネット・アクセス・エンジンに接続した後、ユ−ザ−は、直接ダイアルであれば、宛先電話番号をダイアルする。ロ−カルのインタ−ネット・アクセス・エンジンは、宛先電話番号にとってロ−カルな第２のインタ−ネット・アクセス・エンジンを探し当てて通信を行うか、または、呼びを完了したときに最小の長距離電話料金を招来するエンジンを探し当てる。この第２のインタ− ネット・アクセス・エンジンは宛先電話番号にダイアルし、会話が開始できる。音声はディジタル化され、インタ−ネットを介して伝送される。この方法及び装置は、ユ−ザ−に対する複雑性を回避するばかりでなく、この発明を利用することができるユ−ザ−の数を実質的に増加させる。音声通信をマイクロホン付きのコンピュ−タを所有する人に限定する代わりに、電話機を所有する人であれば誰でもが今や長距離電話料金を回避することができる。この発明のこれらの及び他の目的、特徴、利点及び代替の見方は、添付の図面と結合しての以下の詳細な説明の考察から当業者には明らかになろう。図面の簡単な説明図１は、現在の技術水準による音声インタ−ネット伝送システムの構成要素のブロック図である。図２は、本発明の原理に従って構成された装置のブロック図。図３は、本発明の実施例の音声伝送の送信プロセスを図解する流れ図である。図４は、本発明の原理に従って構成されたボイスエンジン（voiceEngine）の構成要素のブロック図である。図５は、主なボイスエンジンのプロセスの流れ図である。図６は、ボイスポ−ト（voiceport）確立フェ−ズ・プロセスの流れ図である。図７は、ボイスポ−ト（Ｉ／Ｏデュ−プレックス）送信及び受信プロセスの流れ図である。図８は、ボイスポ−ト（Ｉ／Ｏシンプレックス）送信及び受信プロセスの流れ図である。図９Ａは、ボイスポ−トがマルチプレクサとして動作し、信号を同時に単−のボイスエンジンからの複数のボイスエンジンに送信する構成要素のブロック図である。図９Ｂは、ボイスポ−トがマルチプレクサとして動作し、信号を同時に単−のボイスエンジンでの複数のボイスエンジンから受信する構成要素のブロック図。図１０は、本発明により提供される電話会議サ−ビスの流れ図である。図１１は、本発明により提供される長距離配達サ−ビスの流れ図である。図１２は、本発明により提供される仮想電話サ−ビスの流れ図である。発明の詳細な説明ここで図面を参照するが、図面では、本願発明の種々の要素に、参照番号が与えられ、当業者が本願発明を実施できるように本願発明が説明されている。現在の技術水準を論じる場合には、インタ−ネットに結合されたパ−ソナルコンピュ−タ上でソフトウエアを実行するユ−ザが、常に含まれる。図１に示されるように、現時点での技術水準では、マイクロホン１２とスピ−カ１４とを備えたコンピュ−タ１０を含む。コンピュ−タ１０は、−般的にロ−カルなアクセス・プロバイダ（図示せず）を介して、インタ−ネット１６に接続されている。会話の相手方は、マイクロホン２０とスピ−カ２２とを有する同様のコンピュ−タ・システム１８を有し、そのインタ−ネット・プロバイダ（図示せず）を介してインタ−ネットに接続されている。これらのコンピュ−タ１０、１８は、インタ −ネットで用いるように設計された仕様を有する通信プロトコルで、通信するようになっている。即ち、これらのコンピュ−タは、デジタル情報の小さいパケットを作成することによって、インタ−ネットを介して通信する。これらのパケットは目的地に伝送され、そこで、パケットは、パケットに分解される前のオリジナルなデ−タと等しい−体性を有するデ−タに統合される。コンピュ−タ１０、１８の内部には、アナログ音声デ−タをデジタルデ−タに、及びその逆に翻訳するデジタル信号プロセッサ２４（ＤＳＰ）が存在する。ＤＳＰ２４は、ソフトウェアとして実現されているが、その理由は、汎用コンピュ −タが、そのプログラムを実行するように用いられているからである。従って、プロセスのスル−プットを増加させるための特別なハ−ドウエアは備えられていない。現在の技術水準を停滞させ、電話通信媒体としてのインタ−ネットのより広範囲な使用を妨げている重要な欠点が複数存在する。例えば、現在の技術水準では、前もって、計画しておくことが要求される。これは、図１に示されているような現在のシステムでは、別のコンピュ−タ以外の別のデバイスに宛てて電話をかけるのは不可能であるからである。従って、通話したいと思う人は、コンピュ−タ上で動作する同じ電話ソフトウエアを備えなければならないばかりか、接続を完了させるために、同時にインタ−ネットに向けて電話しなければならない。従って、システムは、意図された受信者に、通話着信を知らせることができない。通話は、予期されなければならない。この理由により、同時にインタ−ンネット上で両方の相手とつながるために、最初の通話者は自分が話したい相手と長距離電話をしなければならない場合がしばしばある。理解できるように、このプロセスは、ユ−ザにとっては、著しく不便なことである。常に電話をしなければならないという事実は、また、電話する側にとって不都合に働く。この理由は、長距離電話が最も高価であるのは、最初の１分であるからである。通話の長さが僅かに２秒であり、通話者が「ネットに接続して下さい」としかいわない場合でも、最初の１分の分の課金はなされてしまう。ほとんどの電話において、これは、それほど重要ではないが、地球の反対側への電話の場合には、些細なことではない。現在の技術における別の短所としては、最良の場合でも、音質が悪いことである。これは、デジタル化された音声デ−タにおいて常に実行されなければならない圧縮によるものである。処理を高速化し、伝送されるべきデ−タの量を、音声伝送がリアルタイムでなされるように、典型的な１４．４モデムによって扱うためには、圧縮が必要になる。また、他の欠点は、両方のコンピュ−タが、インタ−ネット上に存在しなければならないということである。もし、ある理由でインタ−ネット・プロバイダがダウンし、又は、より可能性が高いことであるが、コンピュ−タへの全てのポ− トがビジ−であれば、通話はラインが空くまで完了しない。ある音声インタ−ネット・システムでは、また、両方の相手が電子メ−ル・アドレスをもつことが要求される。電子メ−ル・アドレスは、インタ−ネットに知られている通話の対象となる人間の−意的な識別子として機能する。これによって、インタ−ネット・アクセス・プロバイダを介してすでにインタネットへのアクセスを持っている者だけに、この特別なシステムの使用が厳しく制限されてしまう。最近の新聞の記事にあったように、現在の技術水準は、自分のコンピュ−タとインタ−ネット・アクセスとを用いて無料で電話をかけるという新技術を利用することを好む趣味人（ホビイスト）に向けられてしまっている。しかし、インタ −ネット電話ソフトウエアを規則的に用いるのは、現在では、約２万人に限定されている。簡明に述べれば、本発明は、本発明の加入者が、交換式電話ネットワ−クを介して長距離電話で会話をする時に−般的に発生する長距離電話料金を回避することを可能にする。しかし、上述のシステムと違って、本発明は、ユ−ザにとって複雑でなく、より便利であり、音質が改良され、使用を前もって通知することを必要としない。これらの目的は、図２に示した装置によって実現される。本発明は、インタ− ネット接続可能ではないデバイスがインタ−ネットを介して通信可能であるという点で、他のシステムと大きく相違している。従って、本発明は、従来例のコンピュ−タ電話と対比して、極めて相違しかつより大きな作用効果を奏する電話サ −ビスを提供することができる。このような作用効果は、好適な実施例のシステム構成要素を観察することによって明らかになる。呼出側においては、汎用の電話３０が使用される。これは、マイクロフォンとスピ−カとを備えた他のコンピュ−タのような呼出側デバイスを単に備えた従来例と全く相違している。作用効果は直ちに明らかである。複雑なソフトウエアをセットアップしてランさせる必要がない。外部マイクロフォン及びスピーカを、コンピュ−タ用に購入する必要がない。電話３０は、例えば、公共又は個人的な交換電話ネットワ−ク（ＰＳＴＮ）、セルラ・スイッチ、ＰＣＳ、ケ−ブル電話、または無線機３１等を介して、呼出側ボイスエンジン３２（オ−ディオ・エンジン）を呼び出すために用いられる。呼出側ボイスエンジン３２は、ロ−カルな電話コ−ルのレンジ内に配置されていることが好ましい。ボイスエンジン３２は、本発明の主要な構成要件であり、本発明の大部分の目的を達成することを可能にする。ボイスエンジン３２は、米国特許出願第０８／５８５６２８号に開示されたファックス・エンジンと同様な機能を有しており、この米国特許は、本明細書において参照されている。ボイスエンジン３２はいくつかのタスクを実行し、これらのタスクはソフトウエア及びハ−ドウエアによって、同時に実行される。例えば、ボイスエンジン３２は、呼出者のロ−カル位置にあるか、または、該呼出の受信者のロ−カル位置にある。タスクは、呼出側の電話３０から到来する呼出を受信するためのものである。送信側ボイスエンジン３２は、受信側の電話３８の番号を入力するために呼出者を補助するか、または、補助をすることなく呼出者が受信側の番号を入力するのを待機するかのいずれかである。そして、呼出側ボイスエンジン３２は、受信側ボイスエンジン３４の位置を計算するが、該位置は、呼出者によって入力された受信側の電話３８のエリア・コ−ド及び最初の３つの数字を用いて計算される。位置の計算が行われた後、送信側ボイスエンジン３２は、受信側の電話３８のロ−カル位置にあることが好ましい受信側ボイスエンジン３４にコンタクトする。受信側の電話３８に物理的に最も近接している受信側ボイスエンジン３４と、受信側の電話３８へのロ−カル電話呼出をしている受信側ボイスエンジン３４が存在しない場合に最も小額の長距離電話料金を発生させる受信側ボイスエンジン３４とを、区別することが重要である。この区別は、より近接するボイスエンジン３４を使用するとより高価になるので、重要である。したがって、エリア・コ −ド及び最初の３つの数字から受信側ボイスエンジン３４の位置を判定することは、最も安価な料金を呼出者に保証するための最良の方法である。電話呼出を確立する目的で送信側ボイスエンジン３２が受信側ボイスエンジン３４にコンタクトした後で、受信側の電話のすべての番号が、インタ−ネットを介して受信側ボイスエンジン３４へ送信される。すると、受信側ボイスエンジン３４は、例えば、公共または個人的な交換電話ネットワ−ク（ＰＳＴＮ）、セルラ・スイッチ、ＰＣＳ、ケ−ブル電話、または無線機３１を介して、受信側の電話番号をダイアルする。このとき、ボイスエンジン３２、３４は、−方向通信（シンプレックス）又は好適には双方向通信（デュ−プレックス）を用いて、電話３０と電話３８との間でスピ−チ音声又は他の音声を送信するために準備される。受信側の電話３８には、該呼出がＰＳＴＮ３１を介しての電話通信から生じたものであることは、何ら示されていない。しかしながら、受信側の電話３８において、呼出側識別等のサ−ビスにより、呼出側の電話３０の代わりに、ボイスエンジン３２又は３４を識別することができる。これは、インタ−ネット１６を介してＡＮＩ情報は送信されないからである。しかしながら、呼出側識別情報をボイス送信とともに送信することも可能である。これにより、送信側の電話３０についての正しい呼出側識別情報を、受信側の電話が表示することが可能になる。受信側の電話３８が応答した場合、ボイスエンジン３２及び３４は複数の機能を同時に実行して、呼出者と該呼出を受け取った人との間でリアル・タイムでのボイス通信を可能にする。これは、２つの観点において、従来例と相違している。すなわち、２つの観点とは、全体的なバンド幅とレイテンシイ限定とである。例えば、コンピュ−タは−般に、圧縮デ−タを送信するために、１４．４又は２８．８Ｋｂａｕｄモデムの制限を有しており、これは、デ−タがインタ−ネットを介すると同様にＰＳＴＮを介して送信されるからである。これに対して、ボイスエンジン３２、３４は、このような限定を有していない。これらのボイスエンジンは、インタ−ネット上のノ−ドに備えられていないため、−般的な１４．４Ｋｂａｕｄの伝送速度の制限なしに、極めて高速度で通信を行うことができる。これにより、デ−タ圧縮の要求が緩和される。−般に、デ−タ圧縮は、リアル・タイム変換速度の要求を満足するために必要である。しかしながら、本発明においては、圧縮はさほど厳密なものではなく、したがって、高品質の音声スル− プットを得ることができる。ボイスエンジン３２、３４は専用のデバイスであるので、それにより、従来例の多数のコンピュ−タ電話サ−ビスにおいて−般的であるソフトウエアに依存するのではなく、備えられたデジタル信号処理ハ−ドウエアを用いて、圧縮を実行することができる。それは、コスト上の制約及び処理すべき呼出数に応じて変更可能であるが、コスト的には−般にソフトウエア圧縮を選択すべきである。それにもかかわらず、高速で安価なハ−ドウエア圧縮の効果は、より遅いソフトウエア圧縮速度に勝る場合がある。レイテンシは、従来例のコンピュ−タ電話にとって１つの問題点であり、これは、伝送速度が１４．４Ｋｂａｕｄに限定されている場合に、より長いビルトイン遅延をもたらすからである。通常、ある人が話してから他の人がそれを聞くまでに１．５秒程度かかる。これにより、相手側が今にも話し始めるかどうかを話者が知ることがないため、途切れ途切れの文章となる。本発明においては、デジタル化されたデ−タの代わりにボイス・アナログ信号のみをＰＳＴＮを介して伝送するため、文章が明瞭となる。双方向通信が通話者の間で行われる場合には、本発明の方法は以下のように実行される。ある人が電話３０または３８に対して話しているとき、送信側の電話３０からのアナログ・ボイス送信すなわち信号は、ボイスエンジン３２、３４にＰＳＴＮ３１を介して送信される。ボイスエンジン３２、３４は、通常のアナログ・ボイス信号を、デジタル信号処理（ＤＳＰ）手段（ソフトウエア又はハ−ドウエア）によってデジタル化する。デジタル化された信号は次に、圧縮手段（ソフトウエア又はハ−ドウエア）によって圧縮される。そして、ボイスエンジン３２、３４は、インタ−ネットを介して圧縮されたデ−タを送信するための準備をして、ＴＣＰ／ＩＰプロトコルを用いて離散的なパケットを生成する。これらのパケットは、インタ−ネットの種々のル−トを介して、反対側（送信側又は受信側）のボイスエンジン３２、３４に送信される。該反対側のボイスエンジン３２又は３４は、圧縮されデジタル化されて送信されたメッセ−ジを送信された元の順番に再構築し、送信されたデ−タを解凍し、そして、デジタル信号処理手段によりデジタル／アナログ変換を行って、送信された音声デ−タを再生する。上述のプロセスは、発信者と受信者が実時間で識別可能な限り、その発生による時間的な制約によって更に複雑化する。これがたぶん、本願発明の方法および装置が解決する技術的課題の克服に対して市場が手間取っている理由である。しかしながら、本願発明を現実化するシステムの鍵は、「VoiceEngine（ボイスエンジン」の創造である。専用のボイスエンジンは、入力する音声デ−タ（−般的には人間の声）を捕らえ、音をデジタル化し、それを転送のために圧縮し、他のボイスエンジンにおいてデ−タの圧縮を解き、デジタル化された音をアナログ信号に戻し、それを少しの遅延で再生することができる。好適な実施例において、ボイスエンジンはまたデ−タを暗号化し、会話がインタ−ネットを介して転送される場合に保護され、秘密を保持されるようにする。ボイスエンジンはまた、単−のインタ−ネット接続において複数の音声接続を多重化することができる。従って、ボイスエンジンに対して音声又は他の音響デ −タが実際に転送される時にのみ、信号はインタ−ネットを介して転送される。着信電話３８がこのシステムの加入者である必要がないことに注意されたい。予め定義された発信者電話番号のデ−タベ−スを作ること、又は発信を認められたパスワ−ドを伴う任意の電話番号を許可することのみが必要である。要約すれば、上述の好適な実施例は、非インタ−ネット・プロトコル通信装置が、他の非インタ−ネット・プロトコル通信装置（以下非ＴＣＰ／ＩＰ可能装置と称する）に対して、インタ−ネットを介してアナログデ−タを転送できるシステムを説明する。このシステムは世界中のどこでも、長距離電話料金の課金無しに、コンピュ−タ・テレフォニ−技術の典型的な状態での複雑な発信プロセス無しに、デ−タを転送できる。加えるに、発信者だけがこの説明されたインタ−ネット電話システムの加入者である必要があるのみである。本願発明は、更に好適な実施例を修正する。ある人が電話交換網３１上の電話を用いて、電話交換網３１上の他の電話に対して発信することを可能にすることに加えて、発信者はまたインタ−ネット上のコンピュ−タ４０に対して発信することもできる。このプロセスのための方法と装置は、既に説明したものと少し異なる。しかしながら、このプロセスには発信側のボイスエンジン３２が接続できるように、インタ−ネット上のコンピュ−タの位置をマッピングすることが必要であることが明白である。例えば、発信者がインタ−ネット上のコンピュ−タ（実際上、人がそのコンピュ−タのところに座っており、彼は発信者の声を聞くことができる）を呼び出そうと望むとき、発信者は再度発信側のボイスエンジン３２に対して呼び出しをかける。しかしながら、促されてボイスエンジン３２に着信側の電話の市外局番と電話番号を入力する代わりに、発信者はコンピュ−タにダイアルするオプションを与えるメニュ−から選択することができる。コンピュ−タの位置は、呼び出しを完結するために決定可能でなければならない。これは当業者に公知の任意の方法で可能である。−つの方法は、インタ−ネット・プロトコル（ＩＰ）アドレスを用いることである。大抵のコンピュ−タはインタ−ネットのノ−ドである。全てのノ−ドは、たとえそれがインタ−ネット・プロバイダを介してインタ−ネットに接続する時に−時的にそのコンピュ−タを位置決めする場合であっても、ＩＰアドレスを有する。従ってこの方法は、発信側のボイスエンジン３２を呼び出す発信者の要求によって開始される。発信者は、そこでＩＰアドレスを入力するように促され得る。ボイスエンジン３２はそこで、指定されたＩＰアドレスのノ −ドをアクセスし、ノ−ド上にある発信側のボイスエンジン３２と互換性のある予め配布されたソフトウエアとリンクを確立する。従って、このプロセスは、着信側のコンピュ−タ４０がソフトウエアを走らせており、該コンピュ−タ４０がデジタル的に信号を処理し、圧縮し、圧縮を解除し、暗号化するために必要なアクセサリ−を有するべきであることだけが、以前のものと異なる。事実上、非ＴＣＰ／ＩＰ装置３０（電話）が都合よくＴＣＰ／ＩＰ装置（コンピュ−タ）と継ぎ目なく通信できる。もうひとつの方法は、インタ−ネット上の任意のコンピュ−タ・ノ−ドのアドレスを識別するために、既にインタ−ネット上で確立されているドメイン名サ− ビス（ＤＮＳ）を利用することであろう。この方法では、インタ−ネット本来のアドレス・マッピング能力が、実際のサ−ビスを創造することなく利用される。マルチメディア・コンピュ−タ４０のような、ＴＣＰ／ＩＰ装置に特定すれば、ボイスエンジン３２、３４はデ−タを、インタ−ネット１６に接続された他のほとんどのマルチメディア・コンピュ−タ４０によって容易に理解できる、適応差分パルスコ−ド変調（ＡＤＰＣＭ）形式に符号化する事ができる。これは、サウンド・カ−ド、マイクロフォンおよびボイスエンジン３２、３４と通信するために必要なソフトウエアを有する、インタ−ネット１６上のコンピュ−タ４０から、又はそれに対する呼び出しを可能にする。他の実施例において提供される、上述のプロセスの変更もある。例えば、着信側のコンピュ−タ４０のＩＰアドレスを入力する代わりに、発信者は電子メ−ルアドレスを入力することもできる。当業者には公知のように、電子メ−ルアドレスは、その電子メ−ルアドレスの持ち主がその時にインタ−ネット上にいるかどうかを決定するために問い合わせられることができる。もしユ−ザ−がインタ− ネット上のコンピュ−タ・ノ−ドにいれば、電話呼び出しがコンピュ−タ４０と発信側のボイスエンジン３２との間で開始される。電話交換網上の人とインタ− ネット上のコンピュ−タユ−ザとの間において、電話呼び出しを開始する、当業者に公知の他の方法があることが認められ、これらも本願明細書の範囲に入ることが考慮されるべきである。上述のプロセスの含意は、インタ−ネット１６上のコンピュ−タ・ノ−ド４０が電話交換網３１上の電話３８に、インタ−ネット１６を介して電話呼び出しもする事ができるということである。このプロセスは、既に説明した逆の状況と同等以下の複雑さである。これは、着信側の電話３８の位置決めが非常に簡単だからである。例えば、コンピュ−タ・ノ−ド４０は、そのコンピュ−タをボイスエンジン・デ−タベ−スに接続する実行中のソフトウエアによって、着信側のボイスエンジン３４にアクセスする。そのソフトウエアは、ユ−ザに着信側の電話３８の市外局番と電話番号を入力するように促し、ボイスエンジン・デ−タベ−スはその呼び出しのための着信ボイスエンジン３４として働くボイスエンジンがどれであるかを決定する。そこで着信側のボイスエンジン３４は、その電話が接続されている電話交換網３１を介する電話呼び出しを完結するように命令される。本願発明は、このようにして、二つの非ＴＣＰ／ＩＰ装置の間および、非ＴＣＰ／ＩＰ装置とＴＣＰ／ＩＰ装置との間における非ＴＣＰ／ＩＰ装置が電話発信を開始したりＴＣＰ／ＩＰ装置が呼び出しを開始したりの、インタ−ネット１６を介する通信を可能にする。全ての通信は、もし発信および着信側の両方のボイスエンジン３２、３４が夫々発信および着信側電話３０、３８の近距離呼び出し内にあっても、長距離電話料金を支払う必要無しに発生する。これは、単−の電話３０、３８のみがプロセスの−部にあって、発信者又は着信者がインタ−ネット１６上のコンピュ−タ４０の場合であっても変わらない。もちろん、送信側あるいは受信側のボイスエンジン３２、３４がロ−カルの電話呼び出し距離内にない場合には、長距離電話課金を避けることができないときがある。しかし、ボイスエンジン３２、３４を理想的に分布させて、呼び出し者の多数の者が本発明が提供するサービスの利益を享受できるようにする。本開示は、当業者が本発明を実施できる程度に十分に詳細を示しているが、本発明に特有の詳細部分があり、これは、好ましい実施形態を実施できるようにするためには知っておくと有利である。その詳細は、フロ−チャ−トとブロック図で示すが、これは、主としてコ−ルの間に実行される内部的ボイスエンジン・プロセスについて説明するものである。図３から始めると、フロ−チャ−トは、受信側の電話手段の電話番号をダイアルするときに加入者が従うべきプロセスを記述している。分かるように、このプロセスは、今日の直接ダイアルする電話コ−ルと比べほんのわずかだけ複雑になったに過ぎない。事実、長距離電話産業の規制緩和がされてから出現した複雑なアクセスコ−ドをもつ種々の長距離電話会社では、このプロセスは、比較するとすれば、相対的に簡単である。ボイスエンジン３２には、ステップ４４に示すように、好ましくはロ−カルのボイスエンジン・アクセス番号をダイアルすることによりアクセスし、これは、交換式電話ネットワ−クに、このボイスエンジンへのアクセスを与える。ステップ４６は、加入者が、予めプログラムされ許可された加入者からコールをしているかどうか判定するのに必要である。加入者が予めプログラムされた番号からコ −ルをしている場合、ステップ４８のように、この加入者は、単に、受信側電話番号を入力するだけでよい。セキュリティを増すため、ステップ５０で示すように、本発明のこのプロセスでは、送信側電話番号がボイスエンジン３２が認識するものではない場合に、パスワ−ド検証を要求する。パスワ−ド検証の後、加入者は、ステップ４８に進む。このプロセスは、ステップ５２、５４において複数の異なった電話と同時に通信するオプションを選択できるようにする点で有利である。希望であれば、加入者は、ステップ５４において、単に追加の宛先（受信側）電話番号の入力を続ける。宛先番号を追加するこのプロセスは、全ての希望の番号を入力するまで続き、そしてステップ５６において、電話コ−ルを行う。このプロセス全体は、少なくとも２つの電話番号をダイアルする点で、最良の場合のシナリオにおける通常の長距離ダイアリングとは異なっている。その第１の番号は、好ましくはロ−カルのロ−カル・ボイスエンジン・アクセス番号である。第２の番号は、宛先番号である。図４は、本発明の目的にしたがって構築したボイスエンジン３２の主ハ−ドウェア・コンポ−ネントのブロック図形態の分割である。ボイスエンジン３２は、図２に示した送信側ボイスエンジン３２だけでなく受信側ボイスエンジン３４とすることができる。ボックス５８は、ボイスエンジン３２のコンポ−ネントの周りに描いて示しており、機能上の分割を示す。ボイスエンジン自体は、専用の割り込み駆動型のコンピュ−タ・システムである。好ましい実施形態においては、このコンピュ−タは、インテルベ−スのコンプレックス命令セット・コンピュ−タ（ＣＩＳＣ）のコンピュ−タ・システムである。しかし、これは、縮小命令セット・コンピュ− タ（ＲＩＳＣ）ベ−スのシステムを使用できないことを意味するものではない。コンピュ−タ・システムは、オペレ−ティング・システムにより制御するが、この発明においては、Windows NT Version 3.5 (59)の下で実装している。同じく、これは、ＵＮＩＸあるいはその種々の形態の内の任意のもののようなその他のオペレ−ティング・システムを使用することを除外するものではない。本発明にとって重要なことは、オペレ−ティング・システムが、マルチタスキング動作環境を提供する能力をもっていることである。本発明の方法を実装するソフトウェアは、この特許の主題であるコ−ド構造を使用するものとしてそれ自体考えるべきではない。むしろ、このソフトウェアが実施する特定の機能が重要なのであり、したがってこれについて以下に説明する。ボイスエンジン３２は、機能的には、少なくとも１つのボイスポ−ト（オ−ディオ・ポ−ト）６０、少なくとも１つのボイス・ボ−ド（デジタル信号プロセッサＤＳＰ）６１、およびインタ−ネット・インタ−フェ−ス６２から成るものと考えることができる。ボイスポ−ト６２は、信号（スピ−チのような音を表すオ −ディオデ−タ）の送信および受信の双方に関して、ボイスエンジン３２に対し、少なくとも１つのボイス・ボ−ド６１を介して交換式電話ネットワ−ク回線６３への通信アクセスを与える。ボイスポ−ト６０はまた、インタ−ネット１６を介する伝達のためインタ−ネット・パケットとしてカプセル化した信号を送信および受信するため、ボイスエンジン３２にインタ−ネット・アクセスを提供する。ボイスポ−ト６０は、上記のように二重の機能をもっている。これらは両方とも、交換式電話ネットワ−ク３１を介して信号を送受すると共に、インタ−ネット・インタ−フェ−ス６２を介してインタ−ネット１６と通信する。電話回線からボイスポ−ト６０への通信は、スレッド６４上で生起し、この各スレッド６４は、デ−タの送信および受信の両方を行う能力をもっている。ボイスエンジン３２の内部で生じる特定のプロセスについては、後述のフロ−チャ−トにおいて説明する。ボイスエンジン３２は、図５に示す主ボイスエンジン・プロセス６５により制御する。このプロセス６５により、ボイスエンジン３２は、ボイスエンジン３２の制御および管理のためおよび記述する必須のサブプロセスのための中央プロセッサとして活動できるようになる。スタ−トアップ時に、主ボイスエンジン・プロセス６５は、必要なハ−ドウェア全てを初期化するが、これはステップ７０として示している。ステップ７２は、ボイスポ−ト・スレッド６４の活性化を含んでいる。それらスレッド６４は、インタ−フェ−ス接続６２、６１全てを管理する。主ボイスエンジン・プロセス６５は、イベントの告知を待機するル−プ７６内に留まる。開始したプロセスの任意のものからの告知を受けると、信号７８を送って、告知信号の検証を開始する。まず始めに、コンピュ−タ・システムは、ステップ８０において、その告知が有効でありかつハ−ドウェア誘起のエラ−でないことを検証する。この検証８０は、当業者に知られた多くの方法で行うことができ、したがってこの特許の主題ではない。エラ−がない場合には、プロセス６５は、別のイベント告知を待機するル−プ７６に戻る。例えば、イベント告知アラ−ムは、診断ソフトウェアを実行すべきことを示すシステム警報とすることができる。次にステップ８２は、ハ−ドウェアをテストし診断することである。ステップ８２は、システムが自動診断ソフトウェアにより自動的に実行するものとしたり、あるいはメッセ−ジあるいはその他のインジケ−タがコンピュ−タ・システム管理者にシステムがサービスを必要としているという警報を発するようにすることができる。この診断ステップ８２が自動的なものである場合、ステップ８４において、故障したハ−ドウェアをコンピュ−タ・システムがディセ−ブルして、コンピュ−タ・システムの動作を妨害しないようにする。図５で示しているように、ステップ７２は、Ｉ／Ｏル−プ確立フェ−ズ９９、Ｉ／Ｏル−プ・デュ−プレックス・フェ−ズ１７０、およびＩ／Ｏル−プ・シンプレックス・フェ−ズ２００を活性化する。図６に示す確立フェーズ９９は、ボイスエンジン３４が送信側電話３０からの入コ−ルへの応答並びに受信側電話３８へのコ−ルを行わなければならないとき、受信側ボイスエンジン３４内において生起するステップとして定義する。ステップ１０４において入コ−ルの告知がＤＳＰ６１からあったとき、ボイスポ−ト・スレッド６４は、そのユ−ザをネットワ−クに対し認証する。この認証を行うため、ステップ１０８において、ボイスポ−ト・スレッド６４は、ＡＮＩを用いてＤＳＰ６１から送信側電話３０の番号を検索し、そしてステップ１０９においてそのコ−ルをログする。送信側電圧３０の番号が、ステップ１１０において判定するようにボイスエンジン・デ−タベ−ス内の予めプログラムされた番号である場合、ステップ１１２において、呼び出し者に対し、受信側電話３８の宛先番号についてのプロンプトを行う。また、発信元の電話３０の番号を得るプロセスは、発信元の電話３０の電話線３１にデバイスを取り付ける。デバイスは、発信元の電話３０の番号を自動的に送信する。もし発信元の電話３０が予め定義したデ−タベ−スにないならば、ステップ１１６においてボイスポ−ト（ＶｏｉｃｅＰｏｒｔ）・スレッド６４が挨拶を流し、例えばタッチト−ン（ＤＴＭＦ）信号を通じてのユ−ザからのパスワ −ドを要求し、このパスワ−ドを用いて呼出側の証明が行われる。ステップ１１８において、もし呼出側が適正に証明を行えば、プロセスはステップ１１２に続く。そうでない場合には、ステップ１１９において、呼出側にパスワ−ドが無効である事が通知され、パスワ−ドを再入力することが要求される。ステップ１２０において失敗の数が多すぎると判定された場合には、ステップ１２２において呼出側にパスワ−ドが無効であることが通知され、ラインが切られ（ハングアップされ）、ステップ１２４においてプロセスが再開される。しかしながら、成功裏に完了した呼び出し（コ−ル）が無かった場合には、ステップ１３８においてコ−ルが通知され、電話線６３がハングアップされ、ステップ１４０においてプロセスがリセットされる。呼出側が適切に証明を行った場合には、ステップ１１２において、ボイスポ− ト・スレッド６４は宛先側の電話の番号（１又は複数）を検索する。ユ−ザは、カンファレンス（会議）・コ−ルを完了するために１つ以上の数を入力する。次に、ボイスエンジン３２はすべての関係者を呼び出して同時に共にリンクされるようにする。次に、ステップ１１４において受信側のボイスエンジン３４に連絡がとられてコ−ルが完了される。少なくとも１つのコ−ルが受信側の電話３８に対して成功裏に完了したことがステップ１１６において判定された場合には、プロセスはステップ１１８においてＩ／Ｏル−プ・フェ−ズ１７０、２００のうちの１つに進む。ステップ１２０においてコ−ルは会計（アカウンティング）にログされ、ラインはハングアップされ、プロセスはコ−ルが完了したときに再開される。ステップ１２２において。また、上述の発信元のボイスエンジン３２は、受信側のボイスエンジン３４として働く。この場合、ステップ１２４において外に向かうコ−ルの通知が行われると、ボイスエンジン３２はＤＳＰ６１に、ステップ１２６において、リセットを行うように知らせ、ステップ１２８において、受信側の電話３８の番号をダイヤルするように知らせる。ステップ１３０においてコ−ルに応答があったと判定された場合には、接続が成功裏に完了し、ステップ１３２においてコ−ルはＩ／Ｏル−プ・フェ−ズ１７０、２００の１つに入る。そうでない場合には、ボイスエンジン３２は、ステップ１３４において、コ−ルが完了しなかったことを発信元の電話３０に通知し、情報はアカウンティングにログされ、電話線３１はハングアップされ、ボイスポ−ト確立フェ−ズがステップ１３６において新たに開始する。Ｉ／Ｏル−プ・フェ−ズは２つの異なるタイプのプロセス、即ち、デュ−プレックス１７０とシンプレックス２００、に分けることができ、ＤＳＰ６１およびインタ−ネット１６からのデ−タの入力および出力を制御する。これはＤＳＰを記録（レコ−ド、record）および再生（プレイ、play）の両方に対して制御することによって達成される。即ち、Ｉ／Ｏル−プ・フェ−ズ１７０、２００はＤＳＰ６１を、レコ−ドとプレイを同時に行うデュ−プレックス・モ−ドで、またはデ−タがレコ−ドされるかプレイされるかの何れかであってそれらが同時に行われないシンプレックス・モ−ドで動作させることができる。図７に示したデュ−プレックス・モ−ドは、このシステムの動作の好適なモ− ドであり、ボイスポ−ト６４がデュ−プレックスで動作するよう要求することによって選択可能である。このモ−ドにおいて、ユ−ザは、ボイスエンジンが発信元のボイスエンジン３２である場合には発信元の電話３０から、また、ボイスエンジンが受信側のボイスエンジン３４である場合には受信側の電話３８から、声／音のデ−タのプレイとレコ−ドの両方を同時に行うことができる。デュ−プレックスは、非ブロッキング・コ−ルをＤＳＰ６１に発行することによって、ＰＳＴＮ３１からのデータを待っている間にデータをレコードするようにして、達成される。Ｉ／Ｏル−プ・フェ−ズ１７０は、レコ−ド・イベント又はプレイ・イベントが発生するのを待ち、処理を行う。Ｉ／Ｏル−プ・デュ−プレックス・プロセス１７０は、ステップ１７２において、イベントが発生するのを待つことによって開始する。３つのイベントに対して応答が行われる。第１のイベント・パスは、データがＰＳＴＮ３１を経由で受け取られたときである。このイベントにおいて、Ｉ／Ｏル−プ１７０はＤＳＰ６０に、ステップ１７６において、ＰＳＴＮ３１を経由して受信したデータをレコ −ドするように要求する。ステップ１７６において、このデ−タはデジタル化され、圧縮され、暗号化される。この点で、デ−タは、適当なインタ−ネット・プロトコルを用いるカプセル化の後に、送信されることができ、次に、ステップ１７８において、受信側のボイスエンジン３４に送られることができる。送信の後に、プロセス１７０は、ステップ１８０に示すように、コ−ルがまだアクティブであるか否か（従って、更なる処理が発生するか否か）を判定する。コ−ルがアクティブである場合には、プロセスはステップ１７２にル−プして戻り、イベントの通知を待つ。他方、コ−ルがアクティブではない場合には、プロセスは終了し、遠隔のボイスエンジンには接続のブレイク（解除）が通知される。ステップ１９０において。第２のパスは、デ−タがＰＳＴＮ３１を経由して電話３０、３８から受け取られるときである。デ−タは、インタ−ネット・インタ−フェ−ス６２を経由して受信され、ＤＳＰ６１に渡され、ステップ１８２に示すように、そこでレコ−ドされる。ＤＳＰ６１は、ステップ１８４において、元の信号を得るために、デ− タを解読（復号化）し、圧縮解除し、最終的にデジタル化処理の逆の処理をしなければならない。次に、信号は、非ブロッキング・コ−ルをＤＳＰ６１に発行することによってステップ１８６において信号を電話３０、３８にＰＳＴＮ３１を経由して転送することによってＤＳＰ６１によってプレイされる。発生する他のイベント・パスは、ステップ１８８に示すようにハングアップするロ−カルの電話上のパ−ティである。このイベントが発生すると、遠隔のボイスエンジンに通知され、プロセスはリセットされる。図８に例示するシンプレックス・モ−ドは本システムの動作の好適なモ−ドではないが、ボイスポ−ト・スレッド６４を要求することによってシンプレックス動作を選択することも可能である。このモ−ドでは、ユ−ザは、ボイスエンジンが発信元ボイスエンジンである場合には発信元電話３０からの、あるいはボイスエンジンが受信ボイスエンジン３４である場合には受信電話３８からの、ボイス／サウンド・デ−タを再生または記録することができる。シンプレックスは非ブロッキング・コ−ルをＤＳＰ６１に発送しないことによって達成され、デ−タの記録または再生のみを可能にする。Ｉ／Ｏル−プ・シンプレックス・プロセス２００は記録イベントまたは再生イベントの発生を待って、それに従って処理を行う。Ｉ／Ｏル−プ・シンプレックス・プロセス２００は、ステップ２０２に示すように、電話３０、３８からＰＳＴＮ３１を介して受信したデ−タを５００ミリ秒の間記録するか、１０ミリ秒の間作動させない（ライン上をサイレントにする）ことによって開始する。プロセスは、次にステップ２０４においてコ−ルが依然としてアクティブか否かを判定する。アクティブでなければ、リモ−ト・ボイスエンジンがステップ２０６において通知される。しかし、コ−ルがアクティブであれば、プロセスはステップ２０８においてデ −タが記録されたか否かを判定する。もしデ−タがＤＳＰ６１によって記録されていれば、ステップ２１０に示すように好適実施例ではデ−タはディジタル化され、圧縮され、そして暗号化される。そのデ−タは、次にステップ２１２においてインタ−ネット１６を通してリモ−ト（受信または発信元）ボイスエンジンに伝送される。ステップ２０８においてデ−タが記録されていない場合には、ステップ２１４において、プロセスはＤＳＰ６１によって再生されるべきデータがあるか否かを確認する。もしなければ、プロセスはステップ２０２に戻る。しかし、再生されるべきデ−タがある場合には、そのデ−タはステップ２１６において暗号解読され、圧縮解除され、そしてディジタル化処理が逆に行われる。次にステップ２１８において、ＤＳＰ６１は電話３０、３８にＰＳＴＮ３１を介して信号を送ることによってデ−タを再生する。コ−ルが依然としてアクティブであることがステップ２２０において判定される場合には、プロセスはステップ２１４に戻り、デ −タが更に再生される。そうでなければ、リモ−ト・ボイスエンジンがステップ２２２において通知され、プロセスはリセットを行う。ボイスポ−ト６０はマルチタスク・オペレ−ティング・システム５９の利点を生かし処理を同時に実行することを可能にするマルチプレクサであることを注目すべきである。従って、図９Ａに示す送信モ−ドにおいては、ボイスエンジン３４は単−の発信元ボイスエンジン３２からのボイス・デ−タを受信することが可能となる。同様に、図９Ｂにおいて、単−発信元ボイスエンジン３２は、発信元ボイスエンジン３２として動作しない複数の受信ボイスエンジン３４からデ−タを同時に受信することが可能となる。デ−タはミックスされて単−にデ−タ・ストリ−ムを形成し、そしてリモ−ト・ボイスエンジン３２に送られる。これまでの説明は本発明の主要な特徴であるインタ−ネットを介する非ＴＣＰ／ＩＰデバイスからの送信について的を絞ってきたが、非ＴＣＰ／ＩＰデバイスとＴＣＰ／ＩＰデバイスとの間のデ−タ伝送のほかに、本発明によって実現可能にされそして望ましい幾つかの他のサ−ビスがある。これらは、インタ−ネットを介するコ−ル転送、長距離通信、及び仮想電話である。電話会議サ−ビスが図１０に示され、該サ−ビスはインタ−ネットを通して１パ−ティ−以上で会話を行うことを可能にする。ボイスエンジン３２は、発信元電話３０から加入者によって入力される複数の宛先に信号を分配することが課せられる。図１０は、複数の異なる受信電話３８に到達するために１つよりも多い受信ボイスエンジン３４が介在する可能性を示している。図１１に示される長距離通信サ−ビスは、すべての受信ボイスエンジン３４から離れたロ−カル交換電話ネットワ−ク・コ−ルよりも更に先に位置する受信電話３８に対するものである。このような状況は通常はまれであるが、可能性があることも確かである。従って、本発明は、受信ボイスエンジン３４の位置を決定し、受信電話３８に長距離コ−ル２６０を行う場合に料金が最低のレ−トになるように補償する。長距離電話料金は、長距離電話プロバイダと契約をして、単− パ−ティ−が得られるよりも低コスト、高ボリュ−ム契約を獲得することによって、更に低減される。これによって、発信者が直接的にダイヤルしインタ−ネット１６をバイパスする場合よりも常に低いコストで信号が送られることを、発信者に保証する。図１２に示す仮想電話は、高価な、即ち非常に多くの長距離電話をかけるリソ −スがないクライアントや他の人々に適合し、別の便益を加入者に与える。特に、加入者は発信元電話３０からのロ−カル電話コールである仮想電話２６８を「創造（ｃｒｅａｔｅ）」する。新しい電話２６８は実際には単なるロ−カル・ボイスエンジン３２である。しかし、発信者に受信電話３８に対する長距離電話番号を入力することを要求しないで、発信元ボイスエンジン３２は、発信元電話３０によってコ−ルされた電話をマッピングして発信元ボイスエンジン３２をアクセスするシステムを有している。発信元ボイスエンジン３２は、アクセスに使用されたその電話に関連するインストラクションを有することになり、それによって加入者の受信電話３８にインタ−ネットを介して接続する。このようにして、発信元ボイスエンジン３２はすべてのクライアントの発信元電話番号によるプリプログラミング（ｐｒｅ−ｐｒｏｇｒａｍｍｉｎｇ）を必要としない。例えば、ニュ−ヨ−クのビジネス業者はロサンゼルスの多数の小さなクライアントにロサンゼルスのロ−カル電話番号をダイヤルすることによって電話をかけることができることを望んでいる。そのロ−カル・ロサンゼルス仮想電話２６８は５５５−０１２３をダイヤルすることによって呼び出すことができる。ボイスエンジン３２はビジネス業者の受信電話３８に向けられている番号へのすべてのコ−ルをマッピングする。従って、クライアントの発信元電話３０が仮想電話２６８をコ−ルするとき、ボイスエンジン３２はニュ−ヨ−クのビジネス業者の受信電話３８に信号を直ちに転送する。有利なことには、クライアントはロ−カル電話コ−ルのみを行い、ビジネス業者は長距離信号伝送の課金がされない。前述した実施例は本発明の原理の適用例を例示するのみであることを理解すべきである。多くの修正及び代替構成が本発明の精神及び範囲内で当業者には可能である。請求の範囲はそれらの修正及び代替構成を含むものである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者ラデュロビック，アレックスアメリカ合衆国ユタ州84020，ドレィパー, イースト・ウォズワース・パーク・ドライブ 65，スイート 202 【要約の続き】４）は、デジタル化され圧縮され暗号化された、デュ− プレックス又はシンプレックスな、インタ−ネット音声通信サ−ビスが与えられる。

Claims

【特許請求の範囲】１．音声（voice/sound）をインタ−ネットを介して送信するオ−ディオ送信システムであって、音を表すアナログ信号を、第１の交換式電話ネットワ−クを介して送信する少なくとも１つの送信側電話手段と、前記アナログ信号を前記第１の交換式電話ネットワ−クを介して受信し、前記信号をデジタル化し、前記信号を圧縮し、前記信号を、メッセ−ジがインタ−ネットを介する送信に適するように、インタ−ネット・プロトコルを用いて少なくとも１つのインタ−ネット・パケットの中に封止し、前記信号をインタ−ネットを介して送信する少なくとも１つの送信側のオ−ディオ・エンジン手段と、前記送信側のオ−ディオ・エンジン手段によって送信された前記少なくとも１つのインタ−ネット・パケットを受信し、前記少なくとも１つのインタ−ネット・パケットの封止を解いて前記信号をリトリ−ブし、前記信号を解凍し、前記信号をアナログ形式に変換して戻し、前記アナログ信号を第２の交換式電話ネットワ−クを介して送信する少なくとも１つの受信側オ−ディオ・エンジン手段と、前記アナログ信号を前記第２の交換式電話ネットワ−クを介して受信する少なくとも１つの受信側電話手段と、を備えていることを特徴とするオ−ディオ送信システム。２．請求項１記載のシステムにおいて、前記少なくとも１つの送信側電話手段と前記少なくとも１つの受信側電話手段とは、デュ−プレックス又はシンプレックス・モ−ドで交換式電話ネットワ−クを介してオ−ディオ情報を双方向的に通信するように設計された電話であることを特徴とするシステム。３．請求項２記載のシステムにおいて、前記少なくとも１つの送信側電話手段と前記少なくとも１つの受信側電話手段とは、インタ−ネット・プロトコルに従ってインタ−ネットを介しての送信に適したインタ−ネット・パケット内にアナログ信号を封止することができない電話であることを特徴とするシステム。４．請求項１記載のシステムにおいて、前記少なくとも１つの送信側電話手段と前記少なくとも１つの受信側電話手段とは、相互から離れた距離に配置されており、それらの間の直接通話には、長距離電話料金が適用されることを特徴とするシステム。５．請求項１記載のシステムにおいて、前記少なくとも１つの送信側オ−ディオ・エンジン手段は、オ−ディオ・ポ−ト・スレッドによって前記第１の交換式電話ネットワ−クに結合された少なくとも１つのオ−ディオ・ポ−トを有することを特徴とするシステム。６．請求項１記載のシステムにおいて、前記少なくとも１つの受信側オ−ディオ・エンジン手段は、オ−ディオ・ポ−ト・スレッドによって前記第２の交換式電話ネットワ−クに結合された少なくとも１つのオ−ディオ・ポ−トを有することを特徴とするシステム。７．請求項１記載のシステムにおいて、前記少なくとも１つの送信側オ−ディオ・エンジン手段は、専用接続を介してインタ−ネットに結合されたインタ−ネット・インタ−フェ−スにオ−ディオ・ポ−ト・スレッドによって結合されたオ −ディオ・ポ−トを有することを特徴とするシステム。８．請求項１記載のシステムにおいて、前記少なくとも１つの受信側オ−ディオ・エンジン手段は、専用接続を介してインタ−ネットに結合されたインタ−ネット・インタ−フェ−スにオ−ディオ・ポ−ト・スレッドによって結合されたオ −ディオ・ポ−トを有することを特徴とするシステム。９．請求項１記載のシステムにおいて、前記少なくとも１つの送信側電話手段と前記少なくとも１つの受信側電話手段とは、交換式電話ネットワ−ク電話とセルラ電話とケ−ブル電話とから成るグル−プから選択されることを特徴とするシステム。１０．請求項１記載のシステムにおいて、前記少なくとも１つの送信側オ−ディオ・エンジン手段と前記少なくとも１つの受信側オ−ディオ・エンジン手段とは、機能的に相互交換可能であることを特徴とするシステム。１１．請求項１０記載のシステムにおいて、種々の専用インタ−ネット・サイトに分散された複数の送信側及び受信側オ−ディオ・エンジン手段が存在することを特徴とするシステム。１２．請求項１記載のシステムにおいて、前記少なくとも１つの送信側オ−ディオ・エンジン手段と前記少なくとも１つの受信側オ−ディオ・エンジン手段とは、交換式電話ネットワ−クへのアクセスを提供する少なくとも１つのオ−ディオ・ポ−ト・スレッドと、インタ−ネット・インタ−フェ−ス手段へのアクセスを提供する少なくとも第２のオ−ディオ・ポ−ト・スレッドとを有する少なくとも１つのオ−ディオ・ポ−トと、交換式電話ネットワ−クを介して受信された複数の第１の信号を処理し、インタ−ネットを介して受信された複数の第２の信号を処理して、それによって、前記複数の第１の信号を、インタ−ネットを介しての送信のための準備をさせ、前記複数の第２の信号を、前記交換式電話ネットワ−クを介しての送信のための準備をさせる、オ−ディオ処理手段と、オ−ディオ・エンジン・メモリにおいて動作し、前記オ−ディオ・エンジン手段の成分の動作を調整するメイン・オ−ディオ・エンジン・プロセスと、から構成されることを特徴とするシステム。１３．請求項１２記載のシステムにおいて、前記オ−ディオ処理手段は、前記交換式電話ネットワ−クを介して受信されたアナログ信号をデジタル化し、前記デジタル化された信号をインタ−ネットを介しての送信のために圧縮することができるデジタル信号プロセッサを備えていることを特徴とするシステム。１４．請求項１３記載のシステムにおいて、前記オ−ディオ処理手段は、インタ−ネットを介して受信されたデジタル化された信号を解凍し、前記デジタル化された信号を前記交換式電話ネットワ−クを介しての送信のためにアナログ信号に変換することができるデジタル信号プロセッサを備えていることを特徴とするシステム。１５．請求項１４記載のシステムにおいて、前記オ−ディオ・エンジン手段は、マルチタスク・オペレ−ティング・システムを実行するコンピュ−タであることを特徴とするシステム。１６．請求項１５記載のシステムにおいて、前記マルチタスク・オペレ−ティング・システムは、ウィンドウズＮＴ、ＵＮＩＸ、ＵＮＩＸの変形などのオペレ −ティング・システムのグル−プから選択されることを特徴とするシステム。１７．音声（voice/sound）をインタ−ネットを介して送信するオ−ディオ送信システムであって、音を表すアナログ信号を、第１の交換式電話ネットワ−クを介して送信する少なくとも１つの送信側電話手段と、前記アナログ信号を前記第１の交換式電話ネットワ−クを介して受信し、前記信号をデジタル化し、前記信号を圧縮し、前記信号を、メッセ−ジがインタ−ネットを介する送信に適するように、インタ−ネット・プロトコルを用いて少なくとも１つのインタ−ネット・パケットの中に封止し、前記信号をインタ−ネットを介して送信する少なくとも１つの送信側のオ−ディオ・エンジン手段と、前記送信側のオ−ディオ・エンジン手段によって送信された前記少なくとも１つのインタ−ネット・パケットを受信し、前記少なくとも１つのインタ−ネット・パケットの封止を解いて前記信号をリトリ−ブし、前記信号を解凍し、前記信号をアナログ信号に変換し、前記アナログ信号を再生する受信側コンピュ−タ手段と、を備えていることを特徴とするオ−ディオ送信システム。１８．音声（voice/sound）をインタ−ネットを介して送信するオ−ディオ送信システムであって、アナログ信号をデジタル化することによって処理し、前記信号を圧縮し、前記信号を、メッセ−ジがインタ−ネットを介する送信に適するように、インタ−ネット・プロトコルを用いて少なくとも１つのインタ−ネット・パケットの中に封止し、前記信号をインタ−ネットを介して送信する送信側のコンピュ−タ手段と、前記送信側のオ−ディオ・エンジン手段によって送信された前記少なくとも１つのインタ−ネット・パケットを受信し、前記少なくとも１つのインタ−ネット・パケットの封止を解いて前記信号をリトリ−ブし、前記信号を解凍し、前記信号をアナログ形式に変換して戻し、前記アナログ信号を第２の交換式電話ネットワ−クを介して送信する少なくとも１つの受信側オ−ディオ・エンジン手段と、前記アナログ信号を前記第２の交換式電話ネットワ−クを介して受信する少なくとも１つの受信側電話手段と、を備えていることを特徴とするオ−ディオ送信システム。１９．インタ−ネット通信プロトコルを用いて情報を送信することのない通信装置を用いて、インタ−ネットを介して情報を送信するシステムであって、非インタ−ネット封止されたデ−タを、第１の交換式電話ネットワ−クを介して送信する少なくとも１つの送信側電話手段と、前記非インタ−ネット封止されたデ−タを前記交換式ネットワ−クを介して受信し、前記デ−タを、このデ−タがインタ−ネットを介する送信に適するように、インタ−ネット・プロトコルを用いて少なくとも１つのインタ−ネット・パケットの中に封止し、前記インタ−ネット・パケットをインタ−ネットを介して送信する少なくとも１つの送信側のインタ−ネット翻訳エンジン手段と、前記送信側のインタ−ネット翻訳エンジン手段によって送信された前記インタ −ネット・パケットを受信し、前記インタ−ネット・パケットの封止を解き、前記非インタ−ネットデ−タを第２の交換式電話ネットワ−クを介して送信する少なくとも１つの受信側インタ−ネット・エンジン手段と、前記デ−タを前記第２の交換式電話ネットワ−クを介して受信する少なくとも１つの受信側通信手段と、を備えていることを特徴とするシステム。２０．請求項１９記載のシステムにおいて、前記少なくとも１つの送信側通信手段と前記少なくとも１つの受信側通信手段とは、デ−タを交換式電話ネットワ −クを介して同時に送受信するように設計された非インタ−ネット通信装置から選択されることを特徴とするシステム。２１．請求項２０記載のシステムにおいて、前記少なくとも１つの送信側通信手段と前記少なくとも１つの受信側通信手段とは、電話であることを特徴とするシステム。２２．請求項１９記載のシステムにおいて、前記少なくとも１つの送信側通信手段と前記少なくとも１つの受信側通信手段とは、相互から離れた距離に配置されており、それらの間の直接通話には、長距離電話料金が適用されることを特徴とするシステム。２３．請求項１９記載のシステムにおいて、前記少なくとも１つの送信側インタ−ネット翻訳エンジン手段と前記少なくとも１つの受信側インタ−ネット翻訳エンジン手段とは、機能的に相互交換可能であることを特徴とするシステム。２４．請求項１９記載のシステムにおいて、種々の専用インタ−ネット接続サイトに分散された複数の送信側及び受信側インタ−ネット翻訳エンジンが存在することを特徴とするシステム。２５．請求項１９記載のシステムにおいて、前記少なくとも１つの送信側インタ−ネット翻訳エンジン手段は、前記交換式電話ネットワ−クを介して受信されたアナログ信号をデジタル化し、前記デジタル化された信号をインタ−ネットを介しての送信のために圧縮することができるデジタル信号プロセッサを備えていることを特徴とするシステム。２６．請求項２５記載のシステムにおいて、前記少なくとも１つの受信側インタ−ネット翻訳手段は、インタ−ネットを介して受信されたデジタル化された信号を解凍し、前記デジタル化された信号を前記交換式電話ネットワ−クを介しての送信のためにアナログ信号に変換することができるデジタル信号プロセッサを備えていることを特徴とするシステム。２７．インタ−ネットを介して音声を送信する方法であって、ａ）音を表すアナログ信号を第１の交換式電話ネットワ−クを介して送信する送信側電話手段を提供するステップと、ｂ）前記信号を前記第１の交換式電話ネットワ−クを介して受信し前記信号をインタ−ネットを介して送信する送信側オ−ディオ・エンジン手段を提供するステップと、ｃ）前記信号をインタ−ネットを介して受信し前記信号を第２の交換式電話ネットワ−クを介して送信する受信側オ−ディオ・エンジン手段を提供するステップと、ｄ）前記信号を前記第２の交換式電話ネットワ−クを介して受信する受信側電話手段を提供するステップと、を含むことを特徴とする方法。２８．請求項２７記載の方法において、前記ステップｂ）は、メイン・オ−ディオ・エンジン・プロセスを開始するより特定のステップを含み、このプロセスは、ａ）オ−ディオ・エンジン手段受信ハ−ドウェアを含むすべてのオ−ディオ・エンジン手段ハ−ドウェアを初期化するステップと、ｂ）信号が受信されているときにはイベント告知信号を提供するオ−ディオ・エンジン手段受信イベント・ル−プを付勢するステップと、ｃ）前記イベント告知信号を待機するステップと、ｄ）前記イベント告知信号が受信されるときに前記オ−ディオ・エンジン手段ハ−ドウェアが誤動作していないことを確認するステップと、ｅ）前記オ−ディオ・エンジン手段ハ−ドウェアの確認が失敗したときには、誤動作しているオ−ディオ・エンジン手段ハ−ドウェアを消勢するステップと、を含むことを特徴とする方法。２９．請求項２８記載の方法において、前記ステップｂ）は、信号が前記交換式電話ネットワ−クから受信されており、インタ−ネットを介して送信されることを示しており、更に、ａ）前記受信されている信号は、承認されたオ−ディオ・エンジン加入者から来ていることを確認するステップと、ｂ）前記送信側電話から前記受信側電話の少なくとも１つの番号を取得するステップと、ｃ）前記信号をデジタル化するステップと、ｄ）前記信号を圧縮するステップと、ｅ）前記信号を、その信号がインタ−ネットを介して送信できるように、少なくとも１つのインタ−ネット・パケットの中に封止するステップと、ｆ）前記信号をインターネットを介して受信側オ−ディオ・エンジン手段に送信するステップと、を含むことを特徴とする方法。３０．請求項２９記載の方法において、前記信号を、インターネットを介して送信する前に暗号化する追加的なステップを含むことを特徴とする方法。３１．請求項３０記載の方法において、前記ステップａ）は、ａ）前記送信側電話手段の電話番号を取得するステップと、ｂ）前記送信側電話手段の電話番号を、承認されたオ−ディオ・エンジン加入者の予め定義されたリストと比較するステップと、ｃ）前記送信側電話手段の前記電話番号が前記予め定義されたリスト上にない場合には、前記加入者からパスワ−ドを要求し、オ−ディオ・エンジン加入者がこのシステムを任意の交換式電話ネットワ−ク位置から用いることができることを特徴とする方法。３２．請求項３１記載の方法において、前記ステップａ）は、自動番号識別（ＡＮＩ）又はＤＴＭＦ信号を用いて決定されることを特徴とする方法。３３．請求項２９記載の方法において、前記ステップｂ）は、前記送信側電話手段における加入者に受信側の電話の追加的な番号を促し、前記信号が複数の異なる受信側電話手段に同じに送信されることを特徴とする方法。３４．請求項２９記載の方法において、前記信号を暗号化するステップは、ＲＳＡ暗号化アルゴリズムを用いて前記信号前記信号の秘密性を保護する更に特定のステップを含むことを特徴とする方法。３５．請求項２９記載の方法において、前記ステップｅ）は、受け入れられたインタ−ネット・プロトコルにしたがって準備された少なくとも１つのインタ− ネット・パケット内に前記信号を封止するステップを含むことを特徴とする方法。３６．請求項３５記載の方法において、受け入れられたインタ−ネット・プロトコルにしたがって準備された少なくとも１つのインタ−ネット・パケット内に前記信号を封止する前記ステップは、ＴＣＰ／ＩＰを用いる更に特定のステップを含むことを特徴とする方法。３７．請求項２９記載の方法において、前記ステップｆ）は、好ましくは目的地の電話手段からのロ−カルな電話コ−ルである受信側オ−ディオ・エンジン手段を探すことによってどの受信側オ−ディオ・エンジン手段が前記信号を受信すべきかを判断する更なるステップを含むことを特徴とする方法。３８．請求項３７記載の方法において、好ましくは目的地の電話手段からのロ −カルな電話通話である受信側オ−ディオ・エンジン手段を探すことによってどの受信側オ−ディオ・エンジン手段が前記信号を受信すべきかを判断する前記ステップは、前記受信側電話手段からのロ−カルな電話コ−ルである受信側オ−ディオ・エンジン手段を見つけることができない場合には、前記受信側電話手段へのもっとも安価な長距離電話コ−ルをかけることができるオ−ディオ・エンジン手段を見つける追加的なステップを含むことを特徴とする方法。３９．請求項２９記載の方法において、前記受信側オ−ディオ・エンジン手段から前記受信側電話手段へ前記第２の交換式電話ネットワ−クを介して前記信号を送信する受信側オ−ディオ・エンジン手段を提供する前記ステップは、メイン・オ−ディオ・エンジン・プロセスを初期化する更に特定のステップを含み、このプロセスは、ａ）オ−ディオ・エンジン手段受信ハ−ドウェアを含むすべてのオ−ディオ・エンジン手段ハ−ドウェアを初期化するステップと、ｂ）信号が受信されているときにはイベント告知信号を提供するオ−ディオ・エンジン送信イベント・ル−プを付勢するステップと、ｃ）前記イベント告知信号を待機するステップと、ｄ）前記イベント告知信号が受信されるときに前記オ−ディオ・エンジン手段ハ−ドウェアが誤動作していないことを確認するステップと、ｅ）前記ハ−ドウェアの確認が失敗したときには、誤動作しているオ−ディオ・エンジン手段ハ−ドウェアを消勢するステップと、を含むことを特徴とする方法。４０．請求項３９記載の方法において、前記ステップｂ）は、信号が前記受信側オ−ディオ・エンジン手段から前記受信側電話手段に前記交換式電話ネットワ −クを介して送信されることを示しており、更に、ａ）インタ−ネットを介して前記受信されている信号は、承認されたオ−ディオ・エンジン加入者から来ていることを確認するステップと、ｂ）前記少なくとも１つのインタ−ネットパケットを前記信号にリアセンブル（再度組み立てる）するステップと、ｃ）前記信号から少なくとも１つの受信側電話番号を取得するステップと、ｄ）前記第２の交換式電話ネットワ−クを介して、前記受信側電話手段への接続を開くステップと、ｅ）前記受信側電話手段への接続が成功である場合には、前記信号を復号化するステップと、ｆ）前記信号を前記受信側電話手段に送信するステップと、を含むことを特徴とする方法。４１．請求項２９記載の方法において、前記ステップｂ）は、前記送信側電話手段における前記加入者によって提供された受信側電話手段に対して複数の番号を取得し、前記信号が、その電話番号が前記加入者によって提供されるすべての受信側電話手段に同じに送信されることを特徴とする方法。４２．請求項２９記載の方法において、前記ステップｂ）は、前記送信側オ− ディオ・エンジン手段を予めプログラムして、前記信号が、その電話番号が前記送信側オ−ディオ・エンジン手段に前に提供されている複数の受信側電話手段に送信されるようにすることを特徴とする方法。４３．請求項２７記載の方法において、前記信号をインタ−ネットを介して受信し前記信号を第２の交換式電話ネットワ−クを介して受信側電話手段に送信する受信側オ−ディオ・エンジン手段を提供する前記ステップは、このシステムが信号を新たな受信側電話手段に−時的に再度経路決定するように命じられるときには、前記受信側電話手段からの信号を新たな受信側電話手段に再度方向付けする更なるステップを含むことを特徴とする方法。４４．請求項２７記載の方法において、信号を第１の交換式電話ネットワ−クを介して送信する送信側電話手段を提供し、前記信号を第１の交換式電話ネットワ−クを介して受信し、前記信号をインタ−ネットを介して送信する送信側のオ −ディオ・エンジン手段を提供する前記ステップは、仮想的な電話手段を作成して、前記送信側電話手段を用いている加入者が前記送信側オ−ディオ・エンジン手段のマップされた電話番号をコ−ルし、受信側のオ−ディオ・エンジン手段は、前記マップされた電話番号に送信されたすべての信号を、インタ−ネットを介して予め定義された受信電話手段に自動的に送信することを特徴とする方法。４５．交換式電話ネットワ−クを介して送信するが、インタ−ネットを介しての送信のためにインタ−ネット・パケットの中にデ−タを封止することはない装置からデ−タを送信する方法において、ａ）第１の交換式電話ネットワ−クを介して通信する送信側の通信手段を提供するステップと、ｂ）前記送信側通信手段からのデ−タを前記第１の交換式電話ネットワ−クを介して受信し、前記デ−タを送信する送信側インタ−ネット・エンジン手段を提供するステップと、ｃ）前記デ−タをインタ−ネットから受信し、前記デ−タを第２の交換式電話ネットワ−クを介して送信する受信側インタ−ネット・エンジン手段を提供するステップと、ｄ）前記第２の交換式電話ネットワ−クを介して典型的に通信する受信側通信手段を提供し、前記デ−タを前記受信側インタ−ネット・エンジン手段から受信するステツプと、を含むことを特徴とする方法。４６．請求項４５記載の方法において、前記デ−タをインタ−ネットを介して送信する前記ステップは、前記デ−タをインタ−ネット・プロトコルに従って少なとも１つのインタ−ネット・パケットの中に封止して前記信号がインタ−ネットを介して送信することができるようにするステップを含むことを特徴とする方法。４７．インタ−ネットを介して音声を送信する方法であって、ａ）音を表すアナログ信号を第１の交換式電話ネットワ−クを介して送信する送信側電話手段を提供するステップと、ｂ）前記信号を前記第１の交換式電話ネットワ−クを介して受信し前記信号をインタ−ネットを介して送信する送信側オ−ディオ・エンジン手段を提供するステップと、ｃ）前記信号をインタ−ネットを介して受信し前記信号を可聴的に再生する受信側コンピュ−タ手段を提供するステップと、を含むことを特徴とする方法。４８．インタ−ネットを介して音声を送信する方法であって、ａ）音を表すアナログ信号をインタ−ネットを介して送信する送信側コンピュ −タ手段を提供するステップと、ｂ）前記信号をインタ−ネットを介して受信し前記信号を交換式電話ネットワ −クを介して送信する受信側オ−ディオ・エンジン手段を提供するステップと、ｃ）前記信号を前記交換式電話ネットワ−クを介して受信する受信側電話手段を提供するステップと、を含むことを特徴とする方法。