(57)【特許請求の範囲】
【請求項１】
コールループを停止させる方法であって、
被呼番号に対する第１の呼を受信するステップと、
前記被呼番号において受信された前記第１の呼の後に、前記被呼番号に対する第２の呼を受信するステップと、
前記第２の呼がループ状態にある可能性があるかどうかを判定するステップと、
前記第２の呼がループ状態にある可能性があると判定されると、前記第２の呼に関するコールタイマーの計時を開始させるステップと、
前記コールタイマーが終了すると、前記第１の呼が処理中であるか、又は、前記第１の呼がまだ応答されていないかどうかを判定するステップと、
前記第１の呼が処理中であるか、又は、前記第１の呼がまだ応答されていない場合に、前記第２の呼を応答不可のときの代替の宛先に送信するステップと、
前記第１の呼が処理中でなく、かつ、前記第１の呼がすでに応答されている場合は、前記第２の呼を前記被呼番号に送信するステップと
を含むことを特徴とする方法。
【請求項２】
前記第２の呼がループ状態にある可能性があるかどうかを判定するステップは、前記第１の呼が前記被呼番号へ呼び出し中であるかどうかを判定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記第２の呼がループ状態にある可能性があるかどうかを判定するステップは、前記第１の呼が前記被呼番号への呼び出しを待機しているかどうかを判定するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記第２の呼がループ状態にある可能性があるかどうかを判定するステップは、前記第１の呼が不在着信の保留リスト上にあるかどうかを確認するステップを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の呼が不在着信の保留リスト上にあるかどうかを確認するステップは、前記第１の呼における発信者番号と前記第２の呼における発信者番号とを比較するステップを含むことを特徴とする請求項４に記載の方法。
【請求項６】
不在着信の保留リスト上における前記第２の呼に関する情報を記憶するステップを含むことを特徴とする請求項１に記載の方法。
【請求項７】
切断指示を受信することで保留されている呼のリストから前記第２の呼を削除するステップをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
ループ状態にある呼を停止させるためのシステムであって、
前記システムは、
交換機へ機能的に接続されたサーバと、
前記サーバ上で実行される呼制御機能とを含み、
前記呼制御機能は、
被呼番号に対する着呼が前記被呼番号に対する前回の呼におけるループ状態にある呼であるかどうかを判定するステップと、
前記着呼が前記前回の呼におけるループ状態にある呼である可能性がある場合に、前記着呼に関するコールタイマーの計時を開始させるステップと、
前記コールタイマーが終了すると、前記前回の呼が処理中であるか、又は、前記前回の呼がまだ応答されていないかどうかを判定するステップと、
前記前回の呼が処理中であるか、又は、前記前回の呼がまだ応答されていない場合に、前記着呼を応答不可のときの代替の宛先に送信するステップと、
前記前回の呼が処理中でなく、かつ、前記前回の呼がすでに応答されている場合は、前記着呼を前記被呼番号に送信するステップと
を実行するようにプログラムされていることを特徴とするシステム。
【請求項９】
前記システムは、さらにメモリを含み、
前記呼制御機能は、前記前回の呼が処理中であるか、又は、前記前回の呼がまだ応答されていない場合に、前記着呼に関する情報を前記メモリに記憶するステップをさらに実行するようにプログラムされていることを特徴とする請求項８に記載のシステム。
【請求項１０】
前記呼制御機能は、前記呼制御機能が切断指示を受信した場合に、前記メモリから前記着呼に関する前記情報を削除するステップをさらに実行するようにプログラムされていることを特徴とする請求項９に記載のシステム。
【請求項１１】
前記システムは、前記呼制御機能と機能的に接続されたＰＢＸをさらに含むことを特徴とする請求項８に記載のシステム。
【請求項１２】
呼制御機能を有するコールループを停止させるシステムであって、
前記呼制御機能は、
被呼番号に対する第１の呼を受信するステップと、
前記第１の呼の処理中に、前記被呼番号に対する第２の呼であって、該第２の呼が前記第１の呼についてのループ状態にある呼である場合に、該第２の呼を受信するステップと、
前記第２の呼を受信すると、前記第２の呼に関するコールタイマーの計時を開始させるステップと、
前記コールタイマーが終了すると、前記第１の呼が処理中であるか、又は、前記第１の呼がまだ応答されていないかどうかを判定するステップと、
前記第１の呼が処理中であるか、又は、前記第１の呼がまだ応答されていない場合に、前記第２の呼を応答不可のときの代替の宛先に送信するステップと、
前記第１の呼が処理中でなく、かつ、前記第１の呼がすでに応答されている場合は、前記第２の呼を前記被呼番号に送信するステップと
を実行するようにプログラムされていることを特徴とするシステム。
【請求項１３】
前記呼制御機能は、保留された不在着信リスト上の前記第２の呼に関する情報を記憶するステップをさらに実行するようにプログラムされていることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記呼制御機能は、切断指示の受信に伴って前記保留された不在着信リストに関する前記情報を削除するステップをさらに実行するようにプログラムされていることを特徴とする請求項１３に記載のシステム。
【請求項１５】
コールループを停止させる通信ネットワークであって、
前記通信ネットワークは、
呼を受信するための交換機と、
前記交換機へ機能的に接続されたサーバと、
サーバ上で実行される呼制御機能を含み、
前記呼制御機能は、
被呼番号に対する着呼が前記被呼番号に対する前回の呼におけるループ状態にある可能性があるかどうかを判定するステップと、
前記着呼が前記前回の呼のループ状態にある呼における可能性がある場合に、前記着呼に関するコールタイマーの計時を開始させるステップと、
前記コールタイマーが終了すると、前記前回の呼が処理中であるか、又は、前記前回の呼がまだ応答されていないかどうかを判定するステップと、
前記前回の呼が処理中であるか、又は、前記前回の呼がまだ応答されていない場合に、前記着呼を応答不可のときの代替の宛先に送信するステップと、
前記前回の呼が処理中でなく、かつ、前記前回の呼がすでに応答されている場合は、前記着呼を前記被呼番号に送信するステップと
をプログラムされていることを特徴とする通信ネットワーク。
【請求項１６】
前記呼制御機能は、切断指示の受信に伴って保留されている不在着信リストから前記着呼を削除するステップをさらにプログラムされていることを特徴とする請求項１５に記載の通信ネットワーク。
【請求項１７】
前記通信システムは、前記呼制御機能へ機能的に接続されたＰＢＸをさらに含むことを特徴とする請求項１５に記載の通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的な通信ネットワークに関するものであり、特にコールループ（呼ループ）を制御する方法を採用する通信ネットワークに関する。
【背景技術】
【０００２】
通信ネットワークは、大抵の場合、呼の転送サービスのような様々な加入者サービスを含む。それらのサービスは加入者へ利便性を提供するものであるが、サービスプロバイダにとっては、いくつかの複雑さを取り込んでしまうことになる。例えば、呼の転送サービスは、「コールループ」を招くおそれがある。コールループは、呼が終了せずに端点間を複数回転送される場合に発生する。その結果、資源の浪費や通信路の輻輳を招くことになる。一例として、加入者が彼または彼女のサービスプロフィールを誤って設定する場面を想定する。そのような場面では、彼または彼女の移動機番号を呼び出す全ての着呼は、無条件に彼または彼女の固定電話番号へ転送されてしまう。さらに、彼または彼女の固定電話番号を呼び出す全ての着呼が、無条件に彼または彼女の移動機番号に転送されてしまう。このように、ループ状態にある呼は、発呼側がどちらかの番号をダイヤルしたときに発生しうる。それらの場面において、着呼は、単に移動機ネットワークと固定電話ネットワークとの間で行ったり来たり、繰り返し呼び出すだけである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これまでコールループを検出することや防ぐ試みがなされてきた。１つの方法としては、同時に発生する転送呼の最大数を指定するように、交換機で厳しい制限を強制する方法である。他の方法としては、ループ状態にある呼を検出するためにメッセージデータを検査する方法である。それらの方法は、完全にコールループを根絶することには成功していない。さらに、浪費される資源の問題を解決するには至っていない。その上、サービスプロバイダは、比較するメッセージデータの妥当性を常に信頼できるとは限らない。したがって、それらの方法は、発信者に不満をもたらす結果となり、加入者は問題が発生しているということを全く気付かないかもしれない。そのため、通信ネットワークにおいて、改良されたシステムやコールループを検出するおよび防ぐ方法が必要とされている。
【課題を解決するための手段】
【０００４】
通信ネットワークにおいて、コールループを防ぐ本発明のシステムおよび方法は、着呼を受信するための交換機と、交換機へ機能的に接続されたサーバと、サーバ上で実行される呼制御機能とを含む。呼制御機能は、交換機で受信され被呼番号に対する着呼がループ状態にある呼である可能性があるかどうかを判断するようにプログラムされている。呼制御機能は、所定の着呼が、現状処理されている前回受信された呼についてのループ状態にある呼である可能性が高いと判断する場合、故意に上記被呼番号への着呼の転送を遅延させる。その遅延は、同じ被呼番号が設定されている応答のない前回の呼が、着呼が転送される前に終了するよう、十分な時間がとられる。遅延された呼がループ状態にある呼である場合、最初の応答されない呼が終了される時に、その呼は終了されるであろう。遅延された呼がループ状態にある呼でない場合、前回決定された遅延期間が終了すると処理されうる。
【発明を実施するための最良の形態】
【０００５】
まず図１について説明をおこなう。図１は、本発明のループストッパ機能を採用した通信ネットワークの実施例について示している。１０は一般的なネットワークを示す。ネットワーク１０は交換機１２とサーバ１４を含む。一つの実施形態によれば、交換機１２、サーバ１４およびそれらの関連機能は、加入者宅内機器の一部である。しかしながら、本発明のループストッパ機能が、加入者宅内機器に使用されるのみではないということは理解されるであろう。実際に、プライベートおよびパブリックネットワークに使用されてもよい。
【０００６】
エンドユーザは、デスクトップコンピュータ２６を使用して、ローカルエリアネットワーク（ＬＡＮ）２４のようなイーサネット（登録商標）による接続を介してサーバ１４と通信をしてもよい。プロビジョニングコンピュータ２０および２２は、交換機１２およびサーバ１４へ機能的に接続される。プロビジョニングコンピュータ２０および２２は、システムオペレータによって使用される。例えば、サービスおよびデータの提供や、交換機１２およびサーバ１４の動作をモニタする少なくとも一方のために使用される。図１には分離されたエンティティとしてコンピュータ２０と２２とを示しているが、当業者には、これらの形態が必須でないということは理解されるであろう。コンピュータ２０および２２は、単一のコンピュータとしてもよいし、そうでなくてもよい。さらに、コンピュータ２０および２２は、交換機１２およびサーバ１４に直接接続されてもよいし、ネットワークを介して接続されてもよい。
【０００７】
交換機１２は、Ｔ１／Ｅ１／ＰＲＩ回線１３を介する公衆交換電話網（ＰＳＴＮ）において、セントレックス交換機２８のような他の交換機に接続される。多くの地上回線電話３８は、音声メールシステム３６や公衆陸上移動通信網（ＰＬＭＮ）３０と通信をおこなうようにセントレックス交換機２８に接続されてもよい。ＰＬＭＮ３０内に含まれる１以上のセルサイト３２は、移動体端末３４または同様の無線通信可能なデバイスを使用して通信をおこなう無線通信ユーザを可能にする。ＰＳＴＮとＰＬＭＮ３０の両方については、よく知られている通信ネットワークであるため、それら自体についての詳細な記載はしない。しかしながら、本発明のループストッパ機能は、様々な相互通信ネットワークからの複数タイプの呼に対応しうる。
【０００８】
サーバ１４は、当業者に知られているいくつかの計算デバイスを有しており、１以上のマイクロプロセッサ（図示せず）、ハードディスクドライブ（図示せず）、およびＣＤ−ＲＯＭドライブ（図示せず）の少なくとも１つを含んでもよい。さらに、サーバ１４は、通常、加入者サービスを提供するためのアプリケーションと同様にオペレーティングシステム、メモリ管理、フォールトトレランスなどのようなテレコミュニケーションサーバ上に含まれる機能を含んでいる。例えば、当該加入者サービスとは、呼の転送サービス、呼の詳細録音サービスおよび単一番号タイプのサービスなどがある。呼制御機能１８は、呼制御機能１８が着呼および発呼の両方を処理するような交換機１２との通信をメモリ１６へ記録する。
【０００９】
図２は、ネットワーク１０の他の構成例について示す。本構成例において、構内交換機（ＰＢＸ）４２は、交換機１２とＰＳＴＮ４０との間で機能的に配置される。また、ＰＢＸ４２は、１以上の地上回線電話３９を接続してもよい。さらに、ＰＢＸ４２は、加入者を音声メールシステム３７へ接続してもよい。図１のネットワーク構成のように、システム要員は、コンピュータ２０および２２を使用して交換機１２とサーバ１４とを提供したり整備したりしうる。それらは、エンドユーザがＬＡＮ２４を介してコンピュータ２６を使用し、サーバ１４へ接続する可能性がある間なされる。当然ながら、ＰＳＴＮ４０およびＰＬＭＮ３０は相互通信をおこなう。それによって、移動体端末３４を使用する無線加入者およびセルサイト３２が、地上回線電話３８および３９を使用する加入者へ通信をおこなうことを可能としている。
【００１０】
特に図示はしていないが、本発明は、同様に他のネットワークの相互通信についても考慮している。例えば、構内無線ネットワークや衛星ネットワークが、本発明によって提供される利益を享受してもよいちょうど２つのネットワークタイプである。実際に、本発明は、コールループに陥る可能性のあるいくつかのネットワークにおいて採用されてもよい。ネットワークまたはネットワーク構成におけるタイプのどのようなものにおいても使用されるが、呼制御機能１８は、着呼および発呼の両方を処理する交換機１２と通信をおこなう。
【００１１】
いくつかの先行技術におけるシステムは、所定の交換機が被呼番号へ転送するような呼び出し回数の最大制限を設定することでコールループを防止することを試みてきた。また、加入者におけるプロビジョニング時に特定の制限事項を課すことによってコールループの防止を試みてきた。今もなお他のシステムにおいては、ループ状態にある呼を検出し確実に特定しようとするために、着呼に関するメッセージデータと継続中の呼に関するデータとを検査している。何回かは成功するものの、それらの方法は、的確にネットワークにおける混雑状態の問題を解決するには至っていない。また、それらの方法は、ループ状態にある呼を検出するため頻繁に複雑なコーディングが要求されている。さらに、それらの方法は、ループ状態にある呼であるかまたはそうでないかにかかわらず、呼を転送してもよい。したがって、それらのシステムには能力に限界があるといえよう。
【００１２】
本発明の呼制御機能１８は、即座に呼を転送しないことによって、通信ネットワークにおけるコールループを防止するように設計されている。この手法は、前述した先行技術よりもさらに単純である。図３にこの手法を説明するため、ループストッパ機能を使用する呼のフローを示す。ここで記載するループストッパ機能は呼制御機能１８によって提供されるということを注意しなければならない。したがって、それらの用語は、同義のものとして使用されうる。
【００１３】
図３に示す方法は、交換機１２で受信される着呼によって開始される（ステップ１００）。状況に応じて、様々なタイプの呼の選別する処理（ステップ１１０）は、必要性のない呼処理を防ぐための「カットオフ」として、いくつかのシステムによって採用されてもよい。通話の詳細記録のような呼処理の他のタイプは、そのような要望がある場合、このステップで実行されてもよい。しかしながら、呼の選別や呼の詳細機能が本発明の一部でないことは理解されるであろう。したがって、詳細な説明はおこなわない。それらは、単に本発明に関連して使用されるであろういくつかの機能を示しているだけである。
【００１４】
呼び出しが受信（応答）され、何らかの任意の機能が実行されるとすぐに、呼は本発明におけるループストッパ機能に渡される（ステップ１２０）。ここで、サーバ１４上の呼制御機能１８は、以下でより詳細に説明する処理を使用して、コールループを検出して防止することを試みるであろう。しかしながら、ループストッパ機能の処理が完了した後で、交換機１２によって受信された着呼が、次の呼機能によって継続的に処理（ステップ１３０）されてもよいし、またはターミネート処理されてもよいことは、十分に注意されなければならない。どのようなケースにおいても、本発明はネットワーク全体を通して、着呼が継続的にループすることを防ぐであろう。その結果、貴重なネットワーク資源を確保することが可能となろう。
【００１５】
図４Ａおよび図４Ｂは、本発明におけるループストッパ機能１２０の可能性のある実施形態について図示している。着呼を受信次第、呼制御機能１８は、前回受信された呼と同じ被呼番号（着信側番号）が現状において処理されているか、または加入者によってまだ応答されていないのかを判定しようとしてもよい（ステップ１５０）。前回受信された呼が処理されている被呼番号と同じでない場合、または加入者によってまだ応答されていない前回受信された呼が無い場合には、処理は通常の呼処理へ返されるであろう（ステップ１５２）。そうでない場合、呼制御機能１８は、現状の着呼の発信側番号と、まだ加入者を待っている過去の着呼における発信側番号を比較してもよい（ステップ１５４）。
【００１６】
発信側番号の情報が、加入者による応答を待っている過去に受信されたいずれかの呼の情報と一致しない場合、オプションである「待機」のアナウンスが発信者に対して再生される（ステップ１５６）。これは、加入者が発信者を待たせたい場合におこなわれる。その場合、着呼は不在着信リストへ追加される（ステップ１６０）。しかしながら、加入者が発信者を待たせることを望んでいない場合、加入者が応答できないときに着呼が転送されることになっている宛先番号へと、着呼が送信される。この「応答不可」のときの宛先番号のタイプは、加入者によって提供されてもよい。例えば、呼を転送しないであろう宛先へ電話をかけるようにすることが好ましい。それは、「応答不可」のときの宛先番号で呼が受信されるとすぐに、応答または終了のどちらかがなされるということである。宛先番号におけるこのタイプの一例は、音声メールである。
【００１７】
ステップ１５４は任意であるということに注意しなければならない。このステップは、ループ状態にある呼に対していくつかの防護をおこなう機能を提供するかもしれない。しかしながら、その実装は複雑であり、また、着呼のメッセージに付随する呼のパラメータデータに依存してしまうおそれがある。前述で規定したように、いくつかのネットワークは、期待される発信側番号の情報をメッセージからメッセージへと伝播する必要はない。また、発信側番号の情報は、加入者回線に相対するものとして中継回線についての情報を含んでもよい。したがって、所定の着呼メッセージが発信側番号の情報を含んでいたとしても、着呼がループ状態にある呼である場合、確実に判定できるほどには十分に信頼できないかもしれない。その結果、この時点で、どのような呼であってもループ状態にある呼であると確実に特定することは不可能である。
【００１８】
しかしながら、本発明は、着呼をループ状態にある呼であるとして確実に特定することを必要としない。それどころか、所定の着呼がループ状態にある呼である可能性がある場合、単に判定しようと試みるだけである。加入者による応答を待っている以前に受信された呼が存在し、ステップ１５４の任意のパラメータチェックが発信側番号および着信側番号が重複している可能性が明らかな場合、結果として、着呼が呼制御機能１８によってループ状態にある可能性があるとして特定されうる。それは、着呼が以前に受信された呼におけるループ状態にある呼であるかもしれないし、ループ状態にある呼でないかもしれないが、そのようなものとして、不在着信リストに追加されて待たされることになる（ステップ１６０）。本発明は、どのような発信のコールレグも発生させないが、その代わりに着呼を被呼番号へ転送することを意図的に遅延させる。この呼を転送するための待機または遅延によって、本発明は、継続的なループ状態にある呼の発生を防止できる。
【００１９】
着呼が不在着信リストに追加された場合（ステップ１６０）、呼制御機能１８は、図４Ｂに示すように、着呼に対するコールタイマーを開始する（ステップ１６２）。コールタイマーの値は、不在着信リスト上にある以前の呼がすでに被呼番号へのコールを停止していることを保証するのに十分長い継続期間を定義する。一例として、不在着信リスト上にある前回の呼がすでに停止していると見なし、着呼を不在着信リストに追加する。さらに、それらの２つの呼がそれぞれコールタイマーＴ０とＴ１に結び付けられて考慮される。本実施形態によれば、Ｔ１の値は、Ｔ０の初期値よりも若干長く（例えば、３秒に）設定される。したがって、Ｔ０における初期値が３０秒であった場合、Ｔ１は、Ｔ０＋３秒または３３秒として設定されるであろう。他の実施形態によれば、Ｔ１の値は、コールタイマーＴ０の残り時間より若干長く設定される。したがって、前回の呼がそのコールタイマーに関して５秒の残り時間がある場合、Ｔ１の値は、Ｔ０＋３秒または８秒として設定されるであろう。しかしながら、当業者は、コールタイマーの値がネットワーク状態に対して適切に選択されるであろうということは容易に理解されるであろう。さらに、システムオペレータによって判定されること、または加入者プロビジョンニングを通してカスタマイズされるということは容易に理解されるであろう。また、コールタイマーは、呼の遅延設定に依存しているトラフィック量に従って動的に変更されてもよい。
【００２０】
コールタイマーによる計時を開始することに加えて、本発明による呼制御機能１８は、発信者へと再生されるアナウンスを発生させてもよい。このアナウンスは、待機していることを示す（ステップ１６２）。一例として、ネットワーク内の交換機または優れた周辺機器がこのアナウンスを再生してもよい。当業者は、着呼がループ状態にある呼でない場合に、ステップ１６２で再生されたアナウンスを発信者が聞くであろうことは十分理解されるであろう。しかしながら、着呼がループ状態にある呼であった場合、相手側が発信者でないかもしれない。このようなケースでは、アナウンスは単にそれを聞く相手側が誰もいない状態で再生されるかもしれない。
【００２１】
呼は、タイマーが満了したことまたは呼の破棄メッセージの受理に対応して、不在着信リストから削除される（ステップ１６４）。破棄メッセージまたは切断表示は、呼制御機能１８によって受信される。それらは、発信者側が電話を切断した場合または交換機１２が「応答不可」の宛先へ送信した場合に生成されるようにしてもよい。着呼がループ状態にある呼であり、呼制御機能１８が破棄メッセージを受信するような場合において、ループ状態にある呼は、不在着信リストから削除されるであろう（ステップ１６８）。それは、発信者が電話を切った場合、または交換機が加入者の「応答不可」の宛先へ呼を送信した場合になされる。結果の切断メッセージがネットワーク１０の各レグを通して伝播され、現状の接続が終了されるであろう。
【００２２】
タイマーが満了した場合は、呼制御機能１８は、すぐに以前受信された加入者への呼が現状において処理されているのか、または加入者によってまだ応答されていないのかを再び判定してもよい（ステップ１７０）。呼が処理されたか、または加入者によってまだ応答されていないかのどちらかである場合、呼制御機能１８は、タイマーが満了した呼を加入者によって提供された「応答不可」のときの宛先番号へと送信してもよい（ステップ１７２）。これは発信者を長い時間待たせないためである。前述したように、「応答不可」のときの宛先番号は、音声メールへの宛先番号であることが好ましい。例えば、呼が転送されないような番号へと誘導されるようにしてもよい。その結果、コールループが防止される。しかしながら、以前受信された呼が加入者を待たせているようなもので無い場合、呼はループ状態にある呼でないため、通常の呼処理へと送信されるようにすることが好ましい（ステップ１７４）。それらの呼はループ状態にある呼でないことが確実に特定されうる。なぜなら、どのようなループ状態にある呼であっても発信者側が電話を切った場合、または「応答不可」のときの宛先番号へと送信された場合は、切断メッセージの受信に対応して終了されているであろうからである。
【００２３】
前述したように、本発明は、ループ状態にある呼である可能性があるものの被呼番号への転送を遅延することによってコールループを防止する。また、当該遅延の時間は、以前の呼が終了されるか、または応答されるのに十分に長い時間とされる。この方法は、ネットワークの様々なタイプにおいて使用されうる。さらに、呼を転送するのに様々なタイプの呼転送を使用するネットワークにおいて、この手法はコールループを停止させるために使用されてもよい。例えば、いくつかのネットワークは、電話から電話へと呼を転送する。それは、最初にネットワークが電話Ａを呼び出すものである。加入者が電話Ａに応答しない場合、または電話Ａがビジー状態である場合、ネットワークは呼を電話Ｂへ転送してもよい。他のネットワークでは、同時に多数の電話を呼び出す方法を採用している。それらの状況において、ネットワークは、電話ＡおよびＢを呼び出し、加入者がどちらの電話にも応答しない場合やどちらかの電話がビジー状態である場合は呼を転送する。ネットワークのタイプまたは使用される呼転送のタイプに関わらず、本発明のシステムまたは方法は、コールループを防止するために使用されうる。
【００２４】
当業者は、すぐに本発明がハードウェア、ソフトウェアもしくは両方を使用して実装されてもよいということを十分に理解できるであろう。さらに、ソフトウェアの実装が異なる言語およびデータ構造を使用して変更されてもよいということを理解してもよい。例えば、１つの実施形態として、本発明のループストッパ機能１２０はＣまたはＣ＋＋で開発されてもよい。また、不在着信リストは先入れ先出し（ＦＩＦＯ）のキューとして実装されてもよい。しかしながら、本発明は、特定の言語および言語クラスの少なくともい一方に限定されるわけではなく、また、どのようなシングルデータ構造の移植にも限定されない。さらに、本発明は、発信および着信側で同じ交換機を共有する呼において、コールループを防止するということを注意しなければならない。また、発信および着信側が複数の交換機の括りで接続されている場合にも本発明は有効となる。
【００２５】
本発明は当然ながら、本発明の特徴の本質を逸脱しない範囲において他の特定の方法で実施されてもよい。したがって、本実施形態は、実施例で挙げた全ての点において考慮されており、限定されない。また、本実施形態は、添付のクレームと同等の範囲内でのあらゆる変化においても取り入れることを意図されている。
【図面の簡単な説明】
【００２６】
【図１】図１は、本発明の実施形態による通信ネットワークの可能な構成を示した図である。
【図２】図２は、本発明の実施形態による通信ネットワークの代替の構成を示した図である。
【図３】図３は、代表的な呼のフローの全体についての概要を示すフローチャートである。
【図４Ａ】図４Ａは、本発明の実施形態による詳細なフローを示すフローチャートである。
【図４Ｂ】図４Ｂは、本発明の実施形態による詳細なフローを示すフローチャートである。
【図１】
0004495149.tif 000002
【図２】
0004495149.tif 000003
【図３】
0004495149.tif 000004
【図４Ａ】
0004495149.tif 000005
【図４Ｂ】
0004495149.tif 000006