マルチゲートウェイ・マルチキャリアネットワークにおけるアンチルーピング
【課題】ルーティングテーブルを更新する必要なしに、ルーピング状態を検出し、終了させることで、呼の遅れとシステムリソースの消費を改善させる。
【解決手段】本発明は、通信ネットワーク内で生じるルーピング状態を検出し、終了させるためのシステムと方法に関連し、交換機要素において、呼申込みに関連した呼識別データを有する呼申込みを受信し、ルーピング状態を検出するため、呼識別データを用いてルーピングエンジンに問合せし、所定時間フレーム内の呼識別データの発生回数を確認し、発生回数と所定カウントを比較し、比較結果に基づいて、メッセージを交換機要素に返送し、メッセージは、通信ネットワーク内にルーピング状態が存在するかどうかを示す。
【解決手段】本発明は、通信ネットワーク内で生じるルーピング状態を検出し、終了させるためのシステムと方法に関連し、交換機要素において、呼申込みに関連した呼識別データを有する呼申込みを受信し、ルーピング状態を検出するため、呼識別データを用いてルーピングエンジンに問合せし、所定時間フレーム内の呼識別データの発生回数を確認し、発生回数と所定カウントを比較し、比較結果に基づいて、メッセージを交換機要素に返送し、メッセージは、通信ネットワーク内にルーピング状態が存在するかどうかを示す。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、一般的に、電気通信（telecommunications）に関連し、特には、電気通信ネットワークにおけるルーピング（looping）状態を検出すること、及び終了させることに関連する。
【背景技術】
【０００２】
電気通信キャリアは、音声及びデータ通信などの電気通信アクセスを顧客に提供する。各電気通信キャリアは、呼（call）をそれらの目的地に、（それら自身のネットワークの使用を介して）直接的に、又は、必要であれば、その他の電気通信キャリアのネットワークにより非直接的に、ルート（route）するよう備えられている。
【０００３】
電気通信キャリアネットワークは、様々な形式の通信ネットワーク、及び、制限はされないが、交換機（switch）、ルータ、ハブ、リピータ、ブリッジ、サーバ等を含む装置を有することができる。そのようなネットワークは、パケット交換データネットワーク（例えば、インターネット、イントラネット、エクストラネット（extranet）、サブネット）、公衆交換電話ネットワーク（PSTN）、無線ネットワーク、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、ピアツーピア（peer-to-peer）ネットワーク、衛星ネットワーク、無線及びテレビブロードキャストネットワーク、光ネットワーク、メトロエリアネットワーク（MA）、コンピュータネットワーク、格子状（grid）ネットワーク、電話交換機（exchange）（例えば、構内交換機（PBX））、B-ISDN（broadband integrated data service network）アクセスネットワーク、デジタル加入者線（DSL）、ケーブルなどを含むことができる。
【０００４】
電気通信キャリアから電話番号を購入する電気通信サービス・プロバイダーは、顧客に番号を割り当て、通信アプリケーションの実装を顧客に提供し、呼申込み（call offer）を受信し、呼を確立し、及び呼をその目的地まで直接的に、又はその他のサービス・プロバイダーを介してルートすることができる。呼がルートされた時、呼が次のサービス・プロバイダーに受け渡され、その次のプロバイダーが、そこに到達するために呼により取られたパスに気づいていない場合、呼ループ（call loop）が生じる可能性がある。その結果、次のサービス・プロバイダーは、既にその呼を処理し、送り出した先のサービス・プロバイダーを介して、呼を送り返す可能性がある。この様に、呼は、その目的地に到達することなく、幾つかのプロバイダーの間を無制限にルート、及びリルート（re-route）され続け、この結果、不必要なルーティング（routing）とネットワーク資源の使用となってしまう。
【０００５】
そのようなルーピング状態を「解決（fix）」することを目指して、図１に示されるエンジン130などの装置が、ルーピング状態が生じた後、ルーピング状態に取り組むために開発されている。
【０００６】
図１を見ると、上記エンジン130を利用する従来システム100が図示されている。システム100は、顧客からの呼申込み101を受信するためのカスタマー側交換機（customer switch）110、呼申込み101を受信し、ルートするために、カスタマー側交換機110と接続されるネットワーク交換機120、データベース140を含み、ネットワーク交換機120と接続されるエンジン130、及びネットワーク交換機120と接続し、呼申込み101をその最終目的地までルートするためのベンダー側交換機（vender switch）150を含む。
【０００７】
実施において、カスタマー側交換機110は、呼申込み101を受信する。呼申込み101は、カスタマー側交換機110によってネットワーク交換機120にルートされる。そして、呼申込み101は、ネットワーク交換機120に格納されたルーティングテーブルに基づいてベンダー側交換機150にルートされる。ベンダー側交換機150は、呼申込み101が交換機110により既に処理されていることについて知らないために、呼申込み101はカスタマー側交換機110に送り返される可能性があり、同様に、カスタマー側交換機110は、呼申込み101をネットワーク交換機120に再送する。ネットワーク交換機120は、再び、呼申込み101を同一のベンダー側交換機150に送り、ベンダー側交換機150は、呼申込み101をカスタマー側交換機110に返送し、これにより、ルーピング状態が生成される。
【０００８】
ネットワーク交換機120が、呼申込み101をベンダー側交換機150にルートする度に、呼申込み101と関連する一定の情報103がエンジン130に送信され、データベース140に格納される。データベース140は、呼申込み101がネットワーク交換機120を通してルートされる回数を記録する。
【０００９】
所定時間期間内に、呼申込み101が、特定の回数、ネットワーク交換機120を介してルートされると、エンジン130は、ルーピング状態が生じていることをネットワーク交換機120に警告する（105）。ネットワーク交換機120は、続いて、カスタマー側交換機110に警告する（107）。そして、ネットワーク交換機120とカスタマー側交換機110の１つ又は両方が、続くループをブロックするため、及び同一の発生元と行き先を有する呼申込みが、ネットワーク交換機120に到着するのを防ぐために、各々のルーティングテーブルを更新する。
【００１０】
重要なことは、ルーピング状態が検出された後でさえ、例えば、１つ以上のネットワーク交換機（例えば、110、120）のルーティングテーブルを更新することによって、１つのブロックが設定されるまで、呼申込み101はシステム100を通してループし続けるであろうし、これは、重大な呼の遅れと不要なシステム資源の消費となる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
従って、ルーティングテーブルを更新する必要なしにリアルタイムで、ルーピング状態を検出し、終了させることが必要であり、これにより、従来技術における遅延と無駄な資源消費を回避する。
【課題を解決するための手段】
【００１２】
本明細書は、一般的に、通信ネットワーク内のルーピング状態を検出し、終了させることに関連する。典型的な実施例において、呼申込みと関連する呼識別データを有する呼申込みが、交換機要素（switching component）をそれ自身が含む交換機設備（switching infrastructure）で受信される。呼申込みをルートする前に、交換機設備は、ルーピング状態を検出するために、（呼識別データを用いて）ルーピングエンジンに問い合わせる。それに応じて、ルーピングエンジンは、所定時間フレーム内の呼識別データの発生回数を確認し、所定カウントと発生回数を比較し、比較結果に基づいて、交換機要素にメッセージを返送する。発生回数が、所定カウントと一致する、又は超えている場合、メッセージは、ルーピング状態が、通信ネットワーク内に存在することを示す。あるいは、発生回数が所定カウントよりも少ない場合、メッセージは、ルーピング状態が存在しないことを示す。
【００１３】
別の実施例では、電話番号に対応付けられた呼に対する呼申込みが、交換機設備にて受信される。この交換機設備は、交換機要素とルーティングエンジンを有する。そして、交換機設備は、ルーピング状態を確認するために、ルーティングエンジンを介して、ルーピングエンジンに問い合わせる。それに応じて、ルーピングエンジンは、ルーピング状態を確認し、ルーピング状態が存在することを示すメッセージをルーティングエンジンに返送する。このメッセージに応答して、ルーティングエンジンは、代替のルーティングに対して呼申込みを解放（release）する。
【００１４】
更にその他の実施例において、通信ネットワーク内のルーピング状態を検出するための典型的なシステムは、交換機要素をそれ自身が含む交換機設備、及び交換機要素と接続されるルーピングエンジンを有する。交換機要素は、各々が呼識別データを有する１つ以上の呼申込みを受信し、呼識別データを用いて、１つ以上の問合せを生成し、ルーピングエンジンに送信するように構成される。ルーピングエンジンは、交換機要素から１つ以上の問合せを受信し、所定時間フレーム内における少なくとも１つの呼申込みと関連した呼識別データの発生回数を確認し、発生回数と所定カウントを比較し、比較結果に基づいて、通信ネットワーク内にルーピング状態が存在するか否かを示すメッセージを交換機要素に返送することにより、ルーピング状態を検出するよう構成される。
【００１５】
その他の実施例において、ルーピング状態を終了させるための典型的なシステムは、交換機設備とルーピングエンジンを有する。交換機設備は、交換機要素とルーティングエンジンを有し、交換機要素は、１つ以上の呼申込みを受信し、１つ以上の問合せを生成し、送信するよう構成される。交換機設備と接続されているルーピングエンジンは、問合せを受信し、ルーピング状態を確認し、そして、少なくとも１つのルーピング状態が存在することを示すメッセージをルーティングエンジンに返送するよう構成される。そのような返送メッセージを受信すると、ルーティングエンジンは、代替のルーティングに対して少なくとも１つの呼申込みを解放するように更に構成される。
【図面の簡単な説明】
【００１６】
【図１】呼が確立された時点でルーピング状態を検出するための従来技術システムを示す。
【図２Ａ】通信ネットワーク内のルーピング状態を検出するための典型的な処理のフローチャートを示す。
【図２Ｂ】所定時間フレーム内における特定の呼識別データの発生回数を確認するための典型的な処理のフローチャートを示す。
【図３】通信ネットワーク内のルーピング状態を終了させるための典型的な処理のフローチャートを示す。
【図４】通信ネットワーク内のルーピング状態を検出し、終了させるための典型的なシステムのブロック図を示す。
【発明を実施するための形態】
【００１７】
当然のことではあるが、以下の記載は、図画内の説明のために選択された特定の構成例を参照することを意図するものであり、添付の特許請求の範囲以外で、開示を定義する、又は限定することを意図したものではない。
【００１８】
本発明は、通信ネットワークにおけるルーピング状態を検出し、終了させるための方法とシステムを提供する。特に、以下に記載される方法とシステムは、ルーピング状態が生じた時に（効果的には、リアルタイムにおいて）、それらを検出することができる。その結果、ルーピング状態を、従来技術による遅延と資源の無駄な使用なしに、即座に終了させることができる。更に、以下に記載の方法とシステムは、「疑わしい（suspicious）」呼申込み（例えば、以前にルーピング状態となった被呼（called）／発呼（calling）番号のペア）が処理されることを先制的にブロックしない。その代わり、過去にルーピング状態になった可能性のある呼申込みを含む、全ての呼申込みは、呼ごと（call-by-call）基準で処理され、これにより、通信ネットワーク内の成功率とルーティング効率は最大化される。
【００１９】
図２Ａを見ると、本発明による通信ネットワーク内のルーピング状態を検出するための典型的な処理200を示すフローチャートが示されている。典型的な処理200によれば、呼識別情報を含む呼申込みが、例えば、交換機設備で受信される（202）。この呼識別情報は、例えば、被呼／発呼番号ペアを含むことができる。呼申込みを受信すると（202）、交換機設備は、呼識別情報を使って、問合せ（query）を生成し、交換機設備と接続されるルーピングエンジンに送信する（204）。１つの実施例において、セッション開始プロトコル（SIP）、トランザクション能力応用部（transaction capabilities application part: TCAP）プロトコル、簡易オブジェクト・アクセス・プロトコル（SOAP）に従って、又は通信ネットワーク内での使用に適した任意のその他のプロトコル、標準、若しくは言語に従って構成されたセッション招待メッセージ（session invitation message）の一部として、問合せが生成され、送信される。
【００２０】
問合せに応答して、ルーピングエンジンは、所定の時間期間、又は時間フレーム内に、（呼申込みと関連した）呼識別データが交換機設備に到着した回数（または、発生回数）を確認する（206）。上記他の方法において、ルーピングエンジンは、所定の時間期間内に交換機設備で受信された同一の呼識別データを持っている呼申込みの数を確認する。この所定の時間期間は、「固定窓（fixed window）」（以下で定義する）、「スライディング窓（sliding window）」（以下で定義する）、又は、特定の実施例に適すると思われる任意のその他の適切な時間メトリック（metric）として定義することができ、そして、ユーザによって選択的に設定され、ルーピングエンジン内に格納することができる。
【００２１】
本発明において、「固定窓」は、呼申込みが受信された時に始まり、固定の時間期間の間続く所定の時間期間を言う。従って、例えば、特定の呼識別データを持つ呼申込みが、時間t=0で受信され、固定の時間期間が30秒である場合、時間t=0で開始された時間の初期固定窓は、時間t=0+30sで終わる。時間の初期固定窓が終了すると、その後（即ち、t>0+30）受信された次の呼申込み（同一の識別データを有している）は、次の呼申込みが受信された時に始まり、30秒間続く新たな固定窓を開始させる。
【００２２】
反対に、「スライディング窓」は、呼申込みが受信された時に始まる所定の時間期間を言うが、固定窓と異なり、スライディング窓は、所定期間と等しい時間長の間、（同一の識別データを有する）次の呼申込みが受信されなくなるまで、所定期間により持続的に延長される。例えば、30秒の所定期間を仮定すると、時間t=0で第１の呼申込みが受信された場合、時間のスライディング窓は、当初、t=0+30で終了するように設定される。しかし、時間t=0+30の前に、次の呼申込みが、例えば、時間t=0+5で受信された場合、スライディング窓は、t=0+5から30秒延長され、又は、t=0+35となる。スライディング窓は、このやり方で、30秒間連続して呼申込みが受信されなくなるまで、延長し続ける。従って、上記の例において、時間t=0+5で呼申込みが受信された後、時間t=0+40まで更なる呼申込みが受信されない場合、初期スライディング窓は、時間t=0+35で終了し、新たなスライディング窓が、時間t=0+40で始まる。
【００２３】
当業者には明白であろうが、固定窓とスライディング窓を使用すると、呼申込み発生の回数の大きな違いが確認される。この違いを説明するため、以下に表１を示す。
【表１】
【００２４】
表１において、固定窓とスライディング窓における所定期間は30秒と仮定し、これら窓内での発生回数に対するしきい値を３と仮定した。このため、固定窓またはスライディング窓内における３以上の発生は、失敗（FAIL）状態となる。
【００２５】
まず「固定窓」を見ると、時間t=0における第１の呼申込み発生が、時間t = 0 + 30で終了する所定期間を開始させる。上記のように、新たな固定窓は、時間t=0+30後に受信される（先の発生と同一の識別データを有する）呼申込みがあるまで開始されない。従って、表１に示されたケースにおいて、第２の固定窓は、時間t=0+35で開始し、時間t=0+65まで続く。発生を参照すると、呼申込み発生が、時間t=0、t=0+5、t=0+15で記録されていることになる。３つの発生全ては、第１の固定窓内に入るため、第３の発生（即ち、t=0+15におけるもの）は、失敗状態をもたらす。しかし、時間t=0+35における発生は、パス（PASS）状態を示し、時間t=0+35において、新たな固定窓（窓内で発生は累積される）が開始されたことを示している。
【００２６】
スライディング窓に移ると、時間t=0における呼申込み発生が、30秒の所定機関を開始させている。その他の呼申込みが受信されない場合、この初期スライディング窓は、時間t=0+30で終了する。しかし、時間t=0+5において、第２の呼申込み発生が受信され、これは、スライディング窓の終了時間を５秒延ばす。従って、第２の呼申込み後、スライディング窓の終了時間は、時間t=0+35に延長される。同様に、時間t=0+15で受信される第３の呼申込み発生は、更にスライディング窓を新たな15秒で延長させ、時間t=0+45までとする。スライディング窓は、このやり方により、30秒連続で呼申込みが受信されなくなるまで、延長が続けられる。
【００２７】
スライディング窓の結果の列を見ると、固定窓と同様に、第３の呼申込み発生が失敗状態となっている。しかし、固定窓の結果と異なり、第４、５、６の発生は、全て失敗状態となっている。これは、後に続く呼申込みが受信される度に、スライディング窓が延長され続けたことによる。実際に、第６の呼申込み発生の結果、スライディング窓は、時間t=0+95まで延長されている。第７の呼申込み発生は、時間t=0+100まで受信されていないため、第７の呼申込みは、パス状態となる。
【００２８】
図２Ａに戻ると、ルーピングエンジンは、所定時間期間内における特定の呼識別データの発生回数を確認するため（206）、任意の適切な方法、及び／又は処理を利用することができる。実際に、例えば、そのような１つの適切な処理250が図２Ｂに示されている。典型的な処理250によれば、ルーピングエンジンは、まず、ルーピングエンジンに含まれる、又はその一部であるルーピングデータベースに問い合わせることができる（252）。このルーピングデータベースは、呼識別データ、関連する時間スタンプと時間フレームデータ、及び呼申込みに関連する任意のその他タイプの情報を格納するために利用することができる。選択的には、ルーピングエンジンは、ルーピングデータベースから呼識別データの古い発生を削除するためのクリーンアップスレッド（clean-up thread）を有することもできる。これら古い発生は、例えば、関連する所定時間フレームが完了してしまっている呼識別データを含むことができる。
【００２９】
この問合せステップ252の結果として、ルーピングエンジンは、先の呼申込み発生の回数を確認することができる。そして、今の呼申込みを組み入れて、先の呼申込み発生の回数がインクリメントされる（254）。この最新の呼申込みと関連した時間スタンプは、呼申込み識別データと共に、今後の参照のために、データベースに記録される（256）。
【００３０】
特に、図２Ｂに示されるステップ252〜256の順序は、必須の順序を示すものではなく、所定時間期間内の呼識別データの発生回数を確認するための流れの１例を示している。実際に、この処理250は、例えば、呼識別データを初めに記録し（256）、そしてルーピングデータベースに問い合わせることができる（254）。
【００３１】
再度、図２Ａを参照すると、呼識別データの発生回数が確認されると（206）、ルーピングエンジンは、所定カウントと発生回数を比較し（208）、所定カウントは、例えば、ルーピング状態を示すしきい値を有することができる。この所定カウント、又はしきい値は、ユーザにより設定（及び／又は更新）することができ、ルーピングエンジン内に格納される。所定カウントと発生回数が比較されると（208）、発生回数が所定カウントと一致、又は超過しているかどうかについての決定が行われる（210）。発生回数が所定カウントと一致、又は超過していない（即ち、発生回数が所定カウントより少ない）ことが決定された場合、ルーピングエンジンは、ルーピング状態が存在しないことを示すメッセージを交換機設備に返送する（212）。しかし、発生回数が所定カウントと一致、又は超過していることが決定された場合、ルーピングエンジンは、ルーピング状態が存在することを示すメッセージを交換機設備に返送する（214）。
【００３２】
典型的な実施例によれば、ルーピングエンジンより返送される、ルーピング状態が存在することを示すメッセージは、例えば、交換機識別（switch identification: SWID）及びトランクグループ識別（trunk group identification: TGID）を含む２パラメータコード（two-parameter code）を有することができる。そのようなメッセージは、例えば、ループロック（loop lock）コマンドとして交換機要素により解釈され、次に、交換機要素が、代替のルーティングに対して呼申込みを解放させる。
【００３３】
あるいは、交換機設備に返送されるメッセージは、例えば、300リダイレクト応答メッセージ、又は通信ネットワーク内の通信に適したその他任意の形式のメッセージを有することができる。
【００３４】
図３を見ると、通信ネットワーク内のルーピング状態（検出されている）を終了するための典型的な処理300を説明するフローチャートが示されている。典型的な処理300によれば、呼識別情報を含み、電話番号先に対応付けられている呼申込みは、交換機設備で受信される302。本明細書の実施例によれば、この呼識別データは、例えば、被呼／発呼番号ペアを含むことができる。
【００３５】
呼申込みを受信すると（302）、交換機設備は、ルーピング状態が存在するかを決定するために、ルーピングエンジンに問い合わせる（304）。この問合せは、選択的に、呼識別データを含むことができ、SIP、TCAP、SOAP、又は通信ネットワーク内の通信に適したその他任意のプロトコル、標準、又は言語により設定されるセッション招待メッセージの一部として生成され、ルーピングエンジンに送信される。
【００３６】
選択的に、ルーピングエンジンは、呼識別データ、関連する時間スタンプと時間フレームデータ、及び呼申込みに関連するその他の情報を格納するための（ルーピングエンジンの一部、又はルーピングエンジンとは独立である）ルーピングデータベースを有することができる。更に、ルーピングエンジンは、選択的に、ルーピングデータベースから呼識別データの古い発生を削除するためのクリーンアップスレッドを有することができる。古い発生は、例えば、関連する所定時間が完了してしまっている呼識別データを含むことができる。
【００３７】
問合せ304に応答して、ルーピングエンジンは、ルーピング状態が存在するかを決定することができる（306）。特に、ルーピングエンジンは、そのような決定306を行うための任意の適切な手段を利用することができる。例えば、ルーピングエンジンが上記したようなルーピングデータベースを有する１つの実施例において、ルーピングエンジンは、ルーピング状態を確認するため、図２Ｂに示される典型的な処理350を利用することができる。即ち、ルーピングエンジンは、所定時間フレーム内の（特定の呼識別データの）発生回数を確認するため、ルーピングデータベースに問合せ、現在の呼申込みを組み入れるために発生回数をインクリメントし、呼識別データを時間スタンプと共にルーピングデータベース内に記録する。そして、発生回数が所定時間フレーム（例えば、固定窓、スライディング窓、又はその他任意の時間メトリック）内で所定カウント（又は、しきい値）と一致、又は超過している場合、ルーピングエンジンは、ルーピング状態が実際に存在することを決定することができる（306）。特に、所定カウント、及び／又は所定時間フレームは、要望通りに、ユーザにより設定、及び／又は更新できる。
【００３８】
特に、本発明によるルーピングエンジンは、図２Ｂの処理に限定されない。反対に、任意の適切なアルゴリズムが、ルーピング状態の存在を確認するために、実装され、ルーピングエンジンにより利用される。
【００３９】
ルーピング状態が存在することが決定されると（306）、ルーピングエンジンは、それを示すメッセージを交換機設備に返送する（308）。そのようなメッセージは、例えば、SWID及びTGIDを含む２パラメータコードを有することができ、ループロックコマンドとしてルーティングエンジンにより解釈され、その結果、ルーティングエンジンが代替のルーティングに対して呼申込みを解放する（310）。
【００４０】
図４を参照すると、通信ネットワーク内のルーピング状態を検出し、終了させるための典型的なシステム400が示される。典型的なシステム400は、交換機設備410とルーピングエンジン440を有し、交換機設備410は、交換機要素420とルーティングエンジン430を含み、呼申込みを受信し、呼申込みをルートし、問合せを生成及び送信し、問合せ応答メッセージを処理し、代替のルーティングに対して呼申込みを解放するように構成され、交換機設備410と接続されるルーピングエンジン440は、呼識別データ、関連する所定時間フレームと時間スタンプデータ、発生データ、及び呼申込みに関連するその他任意のデータ又は情報を格納するためのルーピングデータベース450を有する。この典型的なシステム400内のルーピングエンジン440は、問合せ（例えば、交換機設備410からの）を受信及び処理し、ルーピング状態を検出及び確認し、そして応答メッセージを生成して、交換機設備410に送信するよう構成される。
【００４１】
特に、交換機設備410は単一の構成として示されているが、当然のことであるが、設備410は、１以上の要素／装置を有することができ、それらの少なくとも１つは、命令を格納するためのメモリとそれら命令を実行するための少なくとも１つのプロセッサを有し、それら命令の実行は、交換機要素とルーティングエンジンの少なくとも１つに、以下の記載のように機能させる。そのような要素／装置は、サーバ、パソコン、携帯通信デバイス、携帯電話、ページャ、PDA、キオスク、WiFiアクセスポイント、ルータ、機械、設備、ハードウェア、及び／又はその他のコンピュータ装置を含むことができるが、これに制限されるものではない。同様に、ルーピングエンジンは、それ自身で、１つ以上のそのような要素／装置を有することができ、これにより、ルーピングエンジン、及び／又はルーピングデータベースに、更に以下の記載のように機能させる。
【００４２】
実施において、図４のシステム400は、設備410の交換機要素420を介して、呼申込み401を最初に受信することにより、ルーピング状態を検出するよう構成できる。この呼申込み401は、例えば、被呼／発呼番号ペア、及び／又は呼申込み401と関連したその他情報のような、呼申込み401と関連付けられた呼識別データを含むことができる。呼申込み401を受信すると、交換機要素420は、問合せ403を生成して、ルーピングエンジン440に問合せ403を送信する。選択的には、問合せ403は、呼申込み401の識別データを有することができ、例えば、セッション開始プロトコル（SIP）、トランザクション能力応用部（transaction capabilities application part: TCAP）プロトコル、簡易オブジェクト・アクセス・プロトコル（SOAP）に従って、又は通信ネットワーク内の通信に適したその他任意のプロトコル、標準、若しくは言語に従って、セッション招待メッセージの一部として、生成され、送信される。特に、交換機設備410が呼申込み401のルートを試みる前に、この問合せステップは望ましくは実行され、これにより、既に存在するかもしれない任意のルーピング状態を継続させることを回避する。
【００４３】
問合せ401を受信すると、ルーピングエンジン440は、所定時間フレーム内における、呼申込み401と関連した呼識別データの発生回数を確認する。そのため、ルーピングエンジン440は、ルーピングデータベースに以前に格納された（呼申込み401と関連した）発生と時間データを抽出するため、ルーピングデータベース450に問い合せるよう更に構成される。この発生データは、現在の呼申込み401を組み入れてインクリメントされ、そして、現在の呼申込み401の呼識別データは、時間スタンプと共に、今後の参照のために、ルーピングデータベース450に記録される。選択的には、ルーピングエンジン440は、ルーピングエンジン440に、ルーピングデータベース450から呼識別データの古い発生を削除させるクリーンアップスレッドを更に有することができ、古いデータは、関連する所定時間フレームが完了した呼識別データを有する。
【００４４】
発生回数が確認されると、ルーピングエンジン440は、発生回数と所定カウントを比較し、比較結果に基づき、メッセージ405を生成し、交換機要素420に返送する。典型的な実施例では、所定時間フレームと所定カウントの両方は、要望に従い、ユーザにより設定、及び／又は更新され、ルーピングデータベース450を介して格納される。所定時間フレームの場合、そのようなユーザは、上で定義されたような、固定窓、又はスライディング窓として、所定時間フレームを設定できる。
【００４５】
比較に続いて、発生回数が所定カウントと一致、又は超過していることを、ルーピングエンジン440が決定した場合、ルーピング状態が存在することを示すメッセージ405が生成され、交換機設備410に伝えられる。選択的には、そのようなメッセージ405は、例えば、呼407を解放するためのループロック（loop lock）コマンドとして交換機要素420により解釈される、交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有することができる。
【００４６】
しかし、発生回数が所定カウントより少ない場合、メッセージ405は、ルーピング状態が存在しないことを示す。どちらにしても、交換機要素420とルーピングエンジン440が、セッション開始プロトコル（SIP）に従い通信している場合、この返答メッセージ405は、任意に、300リダイレクト要求応答メッセージとして構成することができる。
【００４７】
別の実施例では、典型的なシステム400は、検出済みのルーピング状態を終了させるよう更に構成される。ルーピング状態が存在することを示すメッセージ405を受信すると、（ルーティングエンジン430を介して）交換機設備410は、代替のルーティングに対して呼申込み407を解放するよう更に構成される。メッセージ405が、上記の様に、ループロックコマンドとして解釈できる、交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有する場合、メッセージ405自身が、そのような解放407に対するきっかけとなることができる。そのようなループロックコマンドを解釈すると、交換機要素420は、呼申込みをルートすることを試みるよりむしろ、呼申込み407を解放するようにルーティングエンジン430に指示することができる。
【００４８】
装置と方式について、その特定の形式に関連して記載してきたが、当然のことであるが、添付の特許請求の範囲に記載された本発明の精神と範囲から逸脱することなしに、広範な同等物を、ここで記載された特定の要素と置き換えることができる。
【技術分野】
【０００１】
本明細書は、一般的に、電気通信（telecommunications）に関連し、特には、電気通信ネットワークにおけるルーピング（looping）状態を検出すること、及び終了させることに関連する。
【背景技術】
【０００２】
電気通信キャリアは、音声及びデータ通信などの電気通信アクセスを顧客に提供する。各電気通信キャリアは、呼（call）をそれらの目的地に、（それら自身のネットワークの使用を介して）直接的に、又は、必要であれば、その他の電気通信キャリアのネットワークにより非直接的に、ルート（route）するよう備えられている。
【０００３】
電気通信キャリアネットワークは、様々な形式の通信ネットワーク、及び、制限はされないが、交換機（switch）、ルータ、ハブ、リピータ、ブリッジ、サーバ等を含む装置を有することができる。そのようなネットワークは、パケット交換データネットワーク（例えば、インターネット、イントラネット、エクストラネット（extranet）、サブネット）、公衆交換電話ネットワーク（PSTN）、無線ネットワーク、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、ピアツーピア（peer-to-peer）ネットワーク、衛星ネットワーク、無線及びテレビブロードキャストネットワーク、光ネットワーク、メトロエリアネットワーク（MA）、コンピュータネットワーク、格子状（grid）ネットワーク、電話交換機（exchange）（例えば、構内交換機（PBX））、B-ISDN（broadband integrated data service network）アクセスネットワーク、デジタル加入者線（DSL）、ケーブルなどを含むことができる。
【０００４】
電気通信キャリアから電話番号を購入する電気通信サービス・プロバイダーは、顧客に番号を割り当て、通信アプリケーションの実装を顧客に提供し、呼申込み（call offer）を受信し、呼を確立し、及び呼をその目的地まで直接的に、又はその他のサービス・プロバイダーを介してルートすることができる。呼がルートされた時、呼が次のサービス・プロバイダーに受け渡され、その次のプロバイダーが、そこに到達するために呼により取られたパスに気づいていない場合、呼ループ（call loop）が生じる可能性がある。その結果、次のサービス・プロバイダーは、既にその呼を処理し、送り出した先のサービス・プロバイダーを介して、呼を送り返す可能性がある。この様に、呼は、その目的地に到達することなく、幾つかのプロバイダーの間を無制限にルート、及びリルート（re-route）され続け、この結果、不必要なルーティング（routing）とネットワーク資源の使用となってしまう。
【０００５】
そのようなルーピング状態を「解決（fix）」することを目指して、図１に示されるエンジン130などの装置が、ルーピング状態が生じた後、ルーピング状態に取り組むために開発されている。
【０００６】
図１を見ると、上記エンジン130を利用する従来システム100が図示されている。システム100は、顧客からの呼申込み101を受信するためのカスタマー側交換機（customer switch）110、呼申込み101を受信し、ルートするために、カスタマー側交換機110と接続されるネットワーク交換機120、データベース140を含み、ネットワーク交換機120と接続されるエンジン130、及びネットワーク交換機120と接続し、呼申込み101をその最終目的地までルートするためのベンダー側交換機（vender switch）150を含む。
【０００７】
実施において、カスタマー側交換機110は、呼申込み101を受信する。呼申込み101は、カスタマー側交換機110によってネットワーク交換機120にルートされる。そして、呼申込み101は、ネットワーク交換機120に格納されたルーティングテーブルに基づいてベンダー側交換機150にルートされる。ベンダー側交換機150は、呼申込み101が交換機110により既に処理されていることについて知らないために、呼申込み101はカスタマー側交換機110に送り返される可能性があり、同様に、カスタマー側交換機110は、呼申込み101をネットワーク交換機120に再送する。ネットワーク交換機120は、再び、呼申込み101を同一のベンダー側交換機150に送り、ベンダー側交換機150は、呼申込み101をカスタマー側交換機110に返送し、これにより、ルーピング状態が生成される。
【０００８】
ネットワーク交換機120が、呼申込み101をベンダー側交換機150にルートする度に、呼申込み101と関連する一定の情報103がエンジン130に送信され、データベース140に格納される。データベース140は、呼申込み101がネットワーク交換機120を通してルートされる回数を記録する。
【０００９】
所定時間期間内に、呼申込み101が、特定の回数、ネットワーク交換機120を介してルートされると、エンジン130は、ルーピング状態が生じていることをネットワーク交換機120に警告する（105）。ネットワーク交換機120は、続いて、カスタマー側交換機110に警告する（107）。そして、ネットワーク交換機120とカスタマー側交換機110の１つ又は両方が、続くループをブロックするため、及び同一の発生元と行き先を有する呼申込みが、ネットワーク交換機120に到着するのを防ぐために、各々のルーティングテーブルを更新する。
【００１０】
重要なことは、ルーピング状態が検出された後でさえ、例えば、１つ以上のネットワーク交換機（例えば、110、120）のルーティングテーブルを更新することによって、１つのブロックが設定されるまで、呼申込み101はシステム100を通してループし続けるであろうし、これは、重大な呼の遅れと不要なシステム資源の消費となる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
従って、ルーティングテーブルを更新する必要なしにリアルタイムで、ルーピング状態を検出し、終了させることが必要であり、これにより、従来技術における遅延と無駄な資源消費を回避する。
【課題を解決するための手段】
【００１２】
本明細書は、一般的に、通信ネットワーク内のルーピング状態を検出し、終了させることに関連する。典型的な実施例において、呼申込みと関連する呼識別データを有する呼申込みが、交換機要素（switching component）をそれ自身が含む交換機設備（switching infrastructure）で受信される。呼申込みをルートする前に、交換機設備は、ルーピング状態を検出するために、（呼識別データを用いて）ルーピングエンジンに問い合わせる。それに応じて、ルーピングエンジンは、所定時間フレーム内の呼識別データの発生回数を確認し、所定カウントと発生回数を比較し、比較結果に基づいて、交換機要素にメッセージを返送する。発生回数が、所定カウントと一致する、又は超えている場合、メッセージは、ルーピング状態が、通信ネットワーク内に存在することを示す。あるいは、発生回数が所定カウントよりも少ない場合、メッセージは、ルーピング状態が存在しないことを示す。
【００１３】
別の実施例では、電話番号に対応付けられた呼に対する呼申込みが、交換機設備にて受信される。この交換機設備は、交換機要素とルーティングエンジンを有する。そして、交換機設備は、ルーピング状態を確認するために、ルーティングエンジンを介して、ルーピングエンジンに問い合わせる。それに応じて、ルーピングエンジンは、ルーピング状態を確認し、ルーピング状態が存在することを示すメッセージをルーティングエンジンに返送する。このメッセージに応答して、ルーティングエンジンは、代替のルーティングに対して呼申込みを解放（release）する。
【００１４】
更にその他の実施例において、通信ネットワーク内のルーピング状態を検出するための典型的なシステムは、交換機要素をそれ自身が含む交換機設備、及び交換機要素と接続されるルーピングエンジンを有する。交換機要素は、各々が呼識別データを有する１つ以上の呼申込みを受信し、呼識別データを用いて、１つ以上の問合せを生成し、ルーピングエンジンに送信するように構成される。ルーピングエンジンは、交換機要素から１つ以上の問合せを受信し、所定時間フレーム内における少なくとも１つの呼申込みと関連した呼識別データの発生回数を確認し、発生回数と所定カウントを比較し、比較結果に基づいて、通信ネットワーク内にルーピング状態が存在するか否かを示すメッセージを交換機要素に返送することにより、ルーピング状態を検出するよう構成される。
【００１５】
その他の実施例において、ルーピング状態を終了させるための典型的なシステムは、交換機設備とルーピングエンジンを有する。交換機設備は、交換機要素とルーティングエンジンを有し、交換機要素は、１つ以上の呼申込みを受信し、１つ以上の問合せを生成し、送信するよう構成される。交換機設備と接続されているルーピングエンジンは、問合せを受信し、ルーピング状態を確認し、そして、少なくとも１つのルーピング状態が存在することを示すメッセージをルーティングエンジンに返送するよう構成される。そのような返送メッセージを受信すると、ルーティングエンジンは、代替のルーティングに対して少なくとも１つの呼申込みを解放するように更に構成される。
【図面の簡単な説明】
【００１６】
【図１】呼が確立された時点でルーピング状態を検出するための従来技術システムを示す。
【図２Ａ】通信ネットワーク内のルーピング状態を検出するための典型的な処理のフローチャートを示す。
【図２Ｂ】所定時間フレーム内における特定の呼識別データの発生回数を確認するための典型的な処理のフローチャートを示す。
【図３】通信ネットワーク内のルーピング状態を終了させるための典型的な処理のフローチャートを示す。
【図４】通信ネットワーク内のルーピング状態を検出し、終了させるための典型的なシステムのブロック図を示す。
【発明を実施するための形態】
【００１７】
当然のことではあるが、以下の記載は、図画内の説明のために選択された特定の構成例を参照することを意図するものであり、添付の特許請求の範囲以外で、開示を定義する、又は限定することを意図したものではない。
【００１８】
本発明は、通信ネットワークにおけるルーピング状態を検出し、終了させるための方法とシステムを提供する。特に、以下に記載される方法とシステムは、ルーピング状態が生じた時に（効果的には、リアルタイムにおいて）、それらを検出することができる。その結果、ルーピング状態を、従来技術による遅延と資源の無駄な使用なしに、即座に終了させることができる。更に、以下に記載の方法とシステムは、「疑わしい（suspicious）」呼申込み（例えば、以前にルーピング状態となった被呼（called）／発呼（calling）番号のペア）が処理されることを先制的にブロックしない。その代わり、過去にルーピング状態になった可能性のある呼申込みを含む、全ての呼申込みは、呼ごと（call-by-call）基準で処理され、これにより、通信ネットワーク内の成功率とルーティング効率は最大化される。
【００１９】
図２Ａを見ると、本発明による通信ネットワーク内のルーピング状態を検出するための典型的な処理200を示すフローチャートが示されている。典型的な処理200によれば、呼識別情報を含む呼申込みが、例えば、交換機設備で受信される（202）。この呼識別情報は、例えば、被呼／発呼番号ペアを含むことができる。呼申込みを受信すると（202）、交換機設備は、呼識別情報を使って、問合せ（query）を生成し、交換機設備と接続されるルーピングエンジンに送信する（204）。１つの実施例において、セッション開始プロトコル（SIP）、トランザクション能力応用部（transaction capabilities application part: TCAP）プロトコル、簡易オブジェクト・アクセス・プロトコル（SOAP）に従って、又は通信ネットワーク内での使用に適した任意のその他のプロトコル、標準、若しくは言語に従って構成されたセッション招待メッセージ（session invitation message）の一部として、問合せが生成され、送信される。
【００２０】
問合せに応答して、ルーピングエンジンは、所定の時間期間、又は時間フレーム内に、（呼申込みと関連した）呼識別データが交換機設備に到着した回数（または、発生回数）を確認する（206）。上記他の方法において、ルーピングエンジンは、所定の時間期間内に交換機設備で受信された同一の呼識別データを持っている呼申込みの数を確認する。この所定の時間期間は、「固定窓（fixed window）」（以下で定義する）、「スライディング窓（sliding window）」（以下で定義する）、又は、特定の実施例に適すると思われる任意のその他の適切な時間メトリック（metric）として定義することができ、そして、ユーザによって選択的に設定され、ルーピングエンジン内に格納することができる。
【００２１】
本発明において、「固定窓」は、呼申込みが受信された時に始まり、固定の時間期間の間続く所定の時間期間を言う。従って、例えば、特定の呼識別データを持つ呼申込みが、時間t=0で受信され、固定の時間期間が30秒である場合、時間t=0で開始された時間の初期固定窓は、時間t=0+30sで終わる。時間の初期固定窓が終了すると、その後（即ち、t>0+30）受信された次の呼申込み（同一の識別データを有している）は、次の呼申込みが受信された時に始まり、30秒間続く新たな固定窓を開始させる。
【００２２】
反対に、「スライディング窓」は、呼申込みが受信された時に始まる所定の時間期間を言うが、固定窓と異なり、スライディング窓は、所定期間と等しい時間長の間、（同一の識別データを有する）次の呼申込みが受信されなくなるまで、所定期間により持続的に延長される。例えば、30秒の所定期間を仮定すると、時間t=0で第１の呼申込みが受信された場合、時間のスライディング窓は、当初、t=0+30で終了するように設定される。しかし、時間t=0+30の前に、次の呼申込みが、例えば、時間t=0+5で受信された場合、スライディング窓は、t=0+5から30秒延長され、又は、t=0+35となる。スライディング窓は、このやり方で、30秒間連続して呼申込みが受信されなくなるまで、延長し続ける。従って、上記の例において、時間t=0+5で呼申込みが受信された後、時間t=0+40まで更なる呼申込みが受信されない場合、初期スライディング窓は、時間t=0+35で終了し、新たなスライディング窓が、時間t=0+40で始まる。
【００２３】
当業者には明白であろうが、固定窓とスライディング窓を使用すると、呼申込み発生の回数の大きな違いが確認される。この違いを説明するため、以下に表１を示す。
【表１】
【００２４】
表１において、固定窓とスライディング窓における所定期間は30秒と仮定し、これら窓内での発生回数に対するしきい値を３と仮定した。このため、固定窓またはスライディング窓内における３以上の発生は、失敗（FAIL）状態となる。
【００２５】
まず「固定窓」を見ると、時間t=0における第１の呼申込み発生が、時間t = 0 + 30で終了する所定期間を開始させる。上記のように、新たな固定窓は、時間t=0+30後に受信される（先の発生と同一の識別データを有する）呼申込みがあるまで開始されない。従って、表１に示されたケースにおいて、第２の固定窓は、時間t=0+35で開始し、時間t=0+65まで続く。発生を参照すると、呼申込み発生が、時間t=0、t=0+5、t=0+15で記録されていることになる。３つの発生全ては、第１の固定窓内に入るため、第３の発生（即ち、t=0+15におけるもの）は、失敗状態をもたらす。しかし、時間t=0+35における発生は、パス（PASS）状態を示し、時間t=0+35において、新たな固定窓（窓内で発生は累積される）が開始されたことを示している。
【００２６】
スライディング窓に移ると、時間t=0における呼申込み発生が、30秒の所定機関を開始させている。その他の呼申込みが受信されない場合、この初期スライディング窓は、時間t=0+30で終了する。しかし、時間t=0+5において、第２の呼申込み発生が受信され、これは、スライディング窓の終了時間を５秒延ばす。従って、第２の呼申込み後、スライディング窓の終了時間は、時間t=0+35に延長される。同様に、時間t=0+15で受信される第３の呼申込み発生は、更にスライディング窓を新たな15秒で延長させ、時間t=0+45までとする。スライディング窓は、このやり方により、30秒連続で呼申込みが受信されなくなるまで、延長が続けられる。
【００２７】
スライディング窓の結果の列を見ると、固定窓と同様に、第３の呼申込み発生が失敗状態となっている。しかし、固定窓の結果と異なり、第４、５、６の発生は、全て失敗状態となっている。これは、後に続く呼申込みが受信される度に、スライディング窓が延長され続けたことによる。実際に、第６の呼申込み発生の結果、スライディング窓は、時間t=0+95まで延長されている。第７の呼申込み発生は、時間t=0+100まで受信されていないため、第７の呼申込みは、パス状態となる。
【００２８】
図２Ａに戻ると、ルーピングエンジンは、所定時間期間内における特定の呼識別データの発生回数を確認するため（206）、任意の適切な方法、及び／又は処理を利用することができる。実際に、例えば、そのような１つの適切な処理250が図２Ｂに示されている。典型的な処理250によれば、ルーピングエンジンは、まず、ルーピングエンジンに含まれる、又はその一部であるルーピングデータベースに問い合わせることができる（252）。このルーピングデータベースは、呼識別データ、関連する時間スタンプと時間フレームデータ、及び呼申込みに関連する任意のその他タイプの情報を格納するために利用することができる。選択的には、ルーピングエンジンは、ルーピングデータベースから呼識別データの古い発生を削除するためのクリーンアップスレッド（clean-up thread）を有することもできる。これら古い発生は、例えば、関連する所定時間フレームが完了してしまっている呼識別データを含むことができる。
【００２９】
この問合せステップ252の結果として、ルーピングエンジンは、先の呼申込み発生の回数を確認することができる。そして、今の呼申込みを組み入れて、先の呼申込み発生の回数がインクリメントされる（254）。この最新の呼申込みと関連した時間スタンプは、呼申込み識別データと共に、今後の参照のために、データベースに記録される（256）。
【００３０】
特に、図２Ｂに示されるステップ252〜256の順序は、必須の順序を示すものではなく、所定時間期間内の呼識別データの発生回数を確認するための流れの１例を示している。実際に、この処理250は、例えば、呼識別データを初めに記録し（256）、そしてルーピングデータベースに問い合わせることができる（254）。
【００３１】
再度、図２Ａを参照すると、呼識別データの発生回数が確認されると（206）、ルーピングエンジンは、所定カウントと発生回数を比較し（208）、所定カウントは、例えば、ルーピング状態を示すしきい値を有することができる。この所定カウント、又はしきい値は、ユーザにより設定（及び／又は更新）することができ、ルーピングエンジン内に格納される。所定カウントと発生回数が比較されると（208）、発生回数が所定カウントと一致、又は超過しているかどうかについての決定が行われる（210）。発生回数が所定カウントと一致、又は超過していない（即ち、発生回数が所定カウントより少ない）ことが決定された場合、ルーピングエンジンは、ルーピング状態が存在しないことを示すメッセージを交換機設備に返送する（212）。しかし、発生回数が所定カウントと一致、又は超過していることが決定された場合、ルーピングエンジンは、ルーピング状態が存在することを示すメッセージを交換機設備に返送する（214）。
【００３２】
典型的な実施例によれば、ルーピングエンジンより返送される、ルーピング状態が存在することを示すメッセージは、例えば、交換機識別（switch identification: SWID）及びトランクグループ識別（trunk group identification: TGID）を含む２パラメータコード（two-parameter code）を有することができる。そのようなメッセージは、例えば、ループロック（loop lock）コマンドとして交換機要素により解釈され、次に、交換機要素が、代替のルーティングに対して呼申込みを解放させる。
【００３３】
あるいは、交換機設備に返送されるメッセージは、例えば、300リダイレクト応答メッセージ、又は通信ネットワーク内の通信に適したその他任意の形式のメッセージを有することができる。
【００３４】
図３を見ると、通信ネットワーク内のルーピング状態（検出されている）を終了するための典型的な処理300を説明するフローチャートが示されている。典型的な処理300によれば、呼識別情報を含み、電話番号先に対応付けられている呼申込みは、交換機設備で受信される302。本明細書の実施例によれば、この呼識別データは、例えば、被呼／発呼番号ペアを含むことができる。
【００３５】
呼申込みを受信すると（302）、交換機設備は、ルーピング状態が存在するかを決定するために、ルーピングエンジンに問い合わせる（304）。この問合せは、選択的に、呼識別データを含むことができ、SIP、TCAP、SOAP、又は通信ネットワーク内の通信に適したその他任意のプロトコル、標準、又は言語により設定されるセッション招待メッセージの一部として生成され、ルーピングエンジンに送信される。
【００３６】
選択的に、ルーピングエンジンは、呼識別データ、関連する時間スタンプと時間フレームデータ、及び呼申込みに関連するその他の情報を格納するための（ルーピングエンジンの一部、又はルーピングエンジンとは独立である）ルーピングデータベースを有することができる。更に、ルーピングエンジンは、選択的に、ルーピングデータベースから呼識別データの古い発生を削除するためのクリーンアップスレッドを有することができる。古い発生は、例えば、関連する所定時間が完了してしまっている呼識別データを含むことができる。
【００３７】
問合せ304に応答して、ルーピングエンジンは、ルーピング状態が存在するかを決定することができる（306）。特に、ルーピングエンジンは、そのような決定306を行うための任意の適切な手段を利用することができる。例えば、ルーピングエンジンが上記したようなルーピングデータベースを有する１つの実施例において、ルーピングエンジンは、ルーピング状態を確認するため、図２Ｂに示される典型的な処理350を利用することができる。即ち、ルーピングエンジンは、所定時間フレーム内の（特定の呼識別データの）発生回数を確認するため、ルーピングデータベースに問合せ、現在の呼申込みを組み入れるために発生回数をインクリメントし、呼識別データを時間スタンプと共にルーピングデータベース内に記録する。そして、発生回数が所定時間フレーム（例えば、固定窓、スライディング窓、又はその他任意の時間メトリック）内で所定カウント（又は、しきい値）と一致、又は超過している場合、ルーピングエンジンは、ルーピング状態が実際に存在することを決定することができる（306）。特に、所定カウント、及び／又は所定時間フレームは、要望通りに、ユーザにより設定、及び／又は更新できる。
【００３８】
特に、本発明によるルーピングエンジンは、図２Ｂの処理に限定されない。反対に、任意の適切なアルゴリズムが、ルーピング状態の存在を確認するために、実装され、ルーピングエンジンにより利用される。
【００３９】
ルーピング状態が存在することが決定されると（306）、ルーピングエンジンは、それを示すメッセージを交換機設備に返送する（308）。そのようなメッセージは、例えば、SWID及びTGIDを含む２パラメータコードを有することができ、ループロックコマンドとしてルーティングエンジンにより解釈され、その結果、ルーティングエンジンが代替のルーティングに対して呼申込みを解放する（310）。
【００４０】
図４を参照すると、通信ネットワーク内のルーピング状態を検出し、終了させるための典型的なシステム400が示される。典型的なシステム400は、交換機設備410とルーピングエンジン440を有し、交換機設備410は、交換機要素420とルーティングエンジン430を含み、呼申込みを受信し、呼申込みをルートし、問合せを生成及び送信し、問合せ応答メッセージを処理し、代替のルーティングに対して呼申込みを解放するように構成され、交換機設備410と接続されるルーピングエンジン440は、呼識別データ、関連する所定時間フレームと時間スタンプデータ、発生データ、及び呼申込みに関連するその他任意のデータ又は情報を格納するためのルーピングデータベース450を有する。この典型的なシステム400内のルーピングエンジン440は、問合せ（例えば、交換機設備410からの）を受信及び処理し、ルーピング状態を検出及び確認し、そして応答メッセージを生成して、交換機設備410に送信するよう構成される。
【００４１】
特に、交換機設備410は単一の構成として示されているが、当然のことであるが、設備410は、１以上の要素／装置を有することができ、それらの少なくとも１つは、命令を格納するためのメモリとそれら命令を実行するための少なくとも１つのプロセッサを有し、それら命令の実行は、交換機要素とルーティングエンジンの少なくとも１つに、以下の記載のように機能させる。そのような要素／装置は、サーバ、パソコン、携帯通信デバイス、携帯電話、ページャ、PDA、キオスク、WiFiアクセスポイント、ルータ、機械、設備、ハードウェア、及び／又はその他のコンピュータ装置を含むことができるが、これに制限されるものではない。同様に、ルーピングエンジンは、それ自身で、１つ以上のそのような要素／装置を有することができ、これにより、ルーピングエンジン、及び／又はルーピングデータベースに、更に以下の記載のように機能させる。
【００４２】
実施において、図４のシステム400は、設備410の交換機要素420を介して、呼申込み401を最初に受信することにより、ルーピング状態を検出するよう構成できる。この呼申込み401は、例えば、被呼／発呼番号ペア、及び／又は呼申込み401と関連したその他情報のような、呼申込み401と関連付けられた呼識別データを含むことができる。呼申込み401を受信すると、交換機要素420は、問合せ403を生成して、ルーピングエンジン440に問合せ403を送信する。選択的には、問合せ403は、呼申込み401の識別データを有することができ、例えば、セッション開始プロトコル（SIP）、トランザクション能力応用部（transaction capabilities application part: TCAP）プロトコル、簡易オブジェクト・アクセス・プロトコル（SOAP）に従って、又は通信ネットワーク内の通信に適したその他任意のプロトコル、標準、若しくは言語に従って、セッション招待メッセージの一部として、生成され、送信される。特に、交換機設備410が呼申込み401のルートを試みる前に、この問合せステップは望ましくは実行され、これにより、既に存在するかもしれない任意のルーピング状態を継続させることを回避する。
【００４３】
問合せ401を受信すると、ルーピングエンジン440は、所定時間フレーム内における、呼申込み401と関連した呼識別データの発生回数を確認する。そのため、ルーピングエンジン440は、ルーピングデータベースに以前に格納された（呼申込み401と関連した）発生と時間データを抽出するため、ルーピングデータベース450に問い合せるよう更に構成される。この発生データは、現在の呼申込み401を組み入れてインクリメントされ、そして、現在の呼申込み401の呼識別データは、時間スタンプと共に、今後の参照のために、ルーピングデータベース450に記録される。選択的には、ルーピングエンジン440は、ルーピングエンジン440に、ルーピングデータベース450から呼識別データの古い発生を削除させるクリーンアップスレッドを更に有することができ、古いデータは、関連する所定時間フレームが完了した呼識別データを有する。
【００４４】
発生回数が確認されると、ルーピングエンジン440は、発生回数と所定カウントを比較し、比較結果に基づき、メッセージ405を生成し、交換機要素420に返送する。典型的な実施例では、所定時間フレームと所定カウントの両方は、要望に従い、ユーザにより設定、及び／又は更新され、ルーピングデータベース450を介して格納される。所定時間フレームの場合、そのようなユーザは、上で定義されたような、固定窓、又はスライディング窓として、所定時間フレームを設定できる。
【００４５】
比較に続いて、発生回数が所定カウントと一致、又は超過していることを、ルーピングエンジン440が決定した場合、ルーピング状態が存在することを示すメッセージ405が生成され、交換機設備410に伝えられる。選択的には、そのようなメッセージ405は、例えば、呼407を解放するためのループロック（loop lock）コマンドとして交換機要素420により解釈される、交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有することができる。
【００４６】
しかし、発生回数が所定カウントより少ない場合、メッセージ405は、ルーピング状態が存在しないことを示す。どちらにしても、交換機要素420とルーピングエンジン440が、セッション開始プロトコル（SIP）に従い通信している場合、この返答メッセージ405は、任意に、300リダイレクト要求応答メッセージとして構成することができる。
【００４７】
別の実施例では、典型的なシステム400は、検出済みのルーピング状態を終了させるよう更に構成される。ルーピング状態が存在することを示すメッセージ405を受信すると、（ルーティングエンジン430を介して）交換機設備410は、代替のルーティングに対して呼申込み407を解放するよう更に構成される。メッセージ405が、上記の様に、ループロックコマンドとして解釈できる、交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有する場合、メッセージ405自身が、そのような解放407に対するきっかけとなることができる。そのようなループロックコマンドを解釈すると、交換機要素420は、呼申込みをルートすることを試みるよりむしろ、呼申込み407を解放するようにルーティングエンジン430に指示することができる。
【００４８】
装置と方式について、その特定の形式に関連して記載してきたが、当然のことであるが、添付の特許請求の範囲に記載された本発明の精神と範囲から逸脱することなしに、広範な同等物を、ここで記載された特定の要素と置き換えることができる。
【特許請求の範囲】
【請求項１】
通信ネットワーク内のルーピング状態を検出する方法であって、
交換機要素を有する交換機設備において、呼申込みに関連する呼識別データを有する該呼申込みを受信するステップと、
ルーピング状態を検出するため、前記呼識別データを用いてルーピングエンジンに問合せを行うステップと、
を有し、
前記ルーピングエンジンは、
所定時間フレーム内の前記呼識別データの発生回数を確認し、
前記発生回数と所定カウントを比較し、及び、
前記比較に基づいて、前記通信ネットワーク内にルーピング状態が存在するかを示すメッセージを前記交換機要素に返送する、方法。
【請求項２】
前記発生回数が前記所定カウントと一致する、又は超過する場合、前記メッセージは、ルーピング状態が存在することを示し、
前記発生回数が前記所定カウントより少ない場合、前記メッセージは、ルーピング状態が存在しないことを示す、請求項１に記載の方法。
【請求項３】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、前記所定時間フレーム内の前記呼申込みの呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行う、請求項１に記載の方法。
【請求項４】
前記問合せスッテップは、セッション開始プロトコル（SIP）、トランザクション能力応用部（TCAP）プロトコル、及び簡易オブジェクト・アクセス・プロトコル（SOAP）の１つに従って構成されるセッション招待メッセージの一部として、問合せを生成し、送信するステップを有する、請求項１に記載の方法。
【請求項５】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定され、前記ルーピングエンジン内に格納される、請求項１に記載の方法。
【請求項６】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項１に記載の方法。
【請求項７】
前記交換機要素と前記ルーピングエンジンの間の情報は、SIPを介して交換され、前記ルーピングエンジンにより返送される前記メッセージは、300リダイレクト要求応答メッセージである、請求項４に記載の方法。
【請求項８】
前記メッセージは、ルーピング状態が存在することを示し、前記メッセージは、前記交換機要素によりループロックコマンドとして解釈される交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有し、
前記方法は、前記交換機要素が、代替ルーティングに対して前記呼申込みを解放するステップを更に有する、請求項１に記載の方法。
【請求項９】
前記ルーピングデータベースに問合せを行うと、前記呼識別データを前記呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録するステップと、
前記呼識別データの発生回数をインクリメントするステップと、
を更に有する、請求項３に記載の方法。
【請求項１０】
前記ルーピングエンジンがクリーンアップスレッドを有し、
前記方法は、前記ルーピングデータベースから呼識別データの古い発生を削除するステップを更に有し、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項３に記載の方法。
【請求項１１】
前記呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項１に記載の方法。
【請求項１２】
ルーピング状態を終了させる方法であって、
交換機要素とルーティングエンジンを有する交換機設備において、電話番号に対応付けられた呼に対する呼申込みを受信するステップと、
前記ルーティングエンジンを介して、ルーピング状態を確認するため、ルーピングエンジンに問合せを行うステップと、
を有し、
前記ルーピングエンジンは、ルーピング状態を確認し、該ルーピング状態が存在することを示すメッセージを前記ルーティングエンジンに返送し、
前記ルーティングエンジンは、代替ルーティングに対して前記呼申込みを解放する、方法。
【請求項１３】
ルーピング状態が存在することを示す前記メッセージは、前記ルーティングエンジンにより、ループロックコマンドとして解釈されるSWID及びTGIDを含む２パラメータコードを有する、請求項１２に記載の方法。
【請求項１４】
前記問合せを行うステップは、前記呼申込みに関連する呼識別データを有する問合せを前記ルーピングエンジンに送信するステップを有し、前記問合せは、SIP、TCAP、及びSOAPを含むグループから選択された１つのプロトコルに従い構成されるセッション招待メッセージの一部として送信される、請求項１２に記載の方法。
【請求項１５】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記方法は、所定時間フレーム内の前記呼申込みに関連する前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うことにより、前記ルーピングエンジンがルーピング状態を確認するステップを更に有し、
前記発生回数が所定カウントと一致する、又は超過する場合、前記ルーピングエンジンは、ルーピング状態が存在することを示す前記メッセージを前記ルーティングエンジンに返送する、請求項１４に記載の方法。
【請求項１６】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定される、請求項１５に記載の方法。
【請求項１７】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項１５に記載の方法。
【請求項１８】
前記ルーピングデータベースに問合せを行うと、前記呼識別データを前記呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録するステップと、
前記所定時間フレーム内の呼識別データの発生回数をインクリメントするステップと、
を更に有する、請求項１５に記載の方法。
【請求項１９】
前記ルーピングエンジンがクリーンアップスレッドを有し、
前記方法は、前記ルーピングデータベースから呼識別データの古い発生を削除するステップを更に有し、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項１５に記載の方法。
【請求項２０】
前記呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項１２に記載の方法。
【請求項２１】
通信ネットワーク内のルーピング状態を検出するためのシステムであって、
呼識別データをそれぞれ有する１以上の呼申込みを受信し、該呼識別データを用いて、１以上の問合せを生成し、送信するように構成される交換機要素を有する交換機設備と、
前記交換機要素と接続されるルーピングエンジンと、
を有し、
前記ルーピングエンジンは、前記１以上の問合せを受信し、及び所定時間フレーム内の少なくとも１つの前記呼申込みと関連する呼識別データの発生回数を確認し、前記発生回数と所定カウントを比較し、該比較に基づいて、前記通信ネットワーク内にルーピング状態が存在するかを示すメッセージを前記交換機要素に返送することにより、ルーピング状態を検出するよう構成される、システム。
【請求項２２】
前記発生回数が前記所定カウントと一致する、又は超過する場合、前記メッセージは、ルーピング状態が存在することを示し、
前記発生回数が前記所定カウントより少ない場合、前記メッセージは、ルーピング状態が存在しないことを示す、請求項２１に記載のシステム。
【請求項２３】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、前記所定時間フレーム内の前記少なくとも１つの呼申込みの前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うよう更に構成される、請求項２１に記載のシステム。
【請求項２４】
前記交換機要素は、セッション開始プロトコル（SIP）、トランザクション能力応用部（TCAP）プロトコル、及び簡易オブジェクト・アクセス・プロトコル（SOAP）の１つに従って構成されるセッション招待メッセージの一部として、問合せを生成し、前記ルーピングエンジンに送信するよう更に構成される、請求項２１に記載のシステム。
【請求項２５】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定され、前記ルーピングエンジン内に格納される、請求項２１に記載のシステム。
【請求項２６】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項２１に記載のシステム。
【請求項２７】
情報が、SIPを介して、前記交換機要素と前記ルーピングエンジンの間で交換され、前記ルーピングエンジンにより返送される前記メッセージは、300リダイレクト要求応答メッセージである、請求項２４に記載のシステム。
【請求項２８】
前記メッセージは、ルーピング状態が存在することを示し、前記メッセージは、前記交換機要素によりループロックコマンドとして解釈される交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有し、
前記交換機要素は、前記ループロックコマンドに応答して、代替ルーティングに対して前記少なくとも１つの呼申込みを解放するよう更に構成される、請求項２１に記載のシステム。
【請求項２９】
前記ルーピングエンジンは、前記呼識別データを前記少なくとも１つの呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録し、
前記呼識別データの発生回数をインクリメントするよう更に構成される、請求項２３に記載のシステム。
【請求項３０】
前記ルーピングエンジンがクリーンアップスレッドを有し、該クリーンアップスレッドは、前記ルーピングエンジンに、前記ルーピングデータベースから呼識別データの古い発生を削除させ、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項２３に記載のシステム。
【請求項３１】
前記少なくとも１つの呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項２１に記載のシステム。
【請求項３２】
ルーピング状態を終了させるためのシステムであって、
１以上の呼申込みを受信し、１以上の問合せを生成し、送信するよう構成された交換機要素とルーティングエンジンを有する交換機設備と、
前記交換機設備と接続されて、前記問合せを受信し、ルーピング状態を確認し、少なくとも１つのルーピング状態が存在することを示すメッセージを前記ルーティングエンジンに返送するよう構成されたルーピングエンジンと、
を有し、
前記ルーティングエンジンは、前記ルーピングエンジンからの返送メッセージに応答して、代替ルーティングに対して少なくとも１つの前記呼申込みを解放するよう構成される、システム。
【請求項３３】
前記メッセージはルーピング状態が存在することを示し、前記メッセージは、前記ルーティングエンジンにより、ループロックコマンドとして解釈されるSWID及びTGIDを含む２パラメータコードを有する、請求項３２に記載のシステム。
【請求項３４】
前記ルーティングエンジンは、前記少なくとも１つの呼申込みに関連する呼識別データを有する問合せを生成し、前記問合せを、SIP、TCAP、及びSOAPを含むグループから選択された１つのプロトコルに従い構成されるセッション招待メッセージの一部として、前記ルーピングエンジンに送信するよう更に構成される、請求項３２に記載のシステム。
【請求項３５】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、所定時間フレーム内の前記少なくとも１つの呼申込みに関連する前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うことにより、ルーピング状態を確認し、及び、
前記発生回数が所定カウントと一致する、又は超過する場合、ルーピング状態が存在することを示す前記メッセージを前記ルーティングエンジンに返送するよう構成される、請求項３４に記載のシステム。
【請求項３６】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定される、請求項３５に記載のシステム。
【請求項３７】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項３５に記載のシステム。
【請求項３８】
前記ルーピングエンジンは、前記呼識別データを前記少なくとも１つの呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録し、前記所定時間フレーム内の呼識別データの発生回数をインクリメントするよう更に構成される、請求項３５に記載のシステム。
【請求項３９】
前記ルーピングエンジンがクリーンアップスレッドを有し、該クリーンアップスレッドは、前記ルーピングエンジンに、前記ルーピングデータベースから呼識別データの古い発生を削除させ、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項３５に記載のシステム。
【請求項４０】
前記少なくとも１つの呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項３２に記載のシステム。
【請求項１】
通信ネットワーク内のルーピング状態を検出する方法であって、
交換機要素を有する交換機設備において、呼申込みに関連する呼識別データを有する該呼申込みを受信するステップと、
ルーピング状態を検出するため、前記呼識別データを用いてルーピングエンジンに問合せを行うステップと、
を有し、
前記ルーピングエンジンは、
所定時間フレーム内の前記呼識別データの発生回数を確認し、
前記発生回数と所定カウントを比較し、及び、
前記比較に基づいて、前記通信ネットワーク内にルーピング状態が存在するかを示すメッセージを前記交換機要素に返送する、方法。
【請求項２】
前記発生回数が前記所定カウントと一致する、又は超過する場合、前記メッセージは、ルーピング状態が存在することを示し、
前記発生回数が前記所定カウントより少ない場合、前記メッセージは、ルーピング状態が存在しないことを示す、請求項１に記載の方法。
【請求項３】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、前記所定時間フレーム内の前記呼申込みの呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行う、請求項１に記載の方法。
【請求項４】
前記問合せスッテップは、セッション開始プロトコル（SIP）、トランザクション能力応用部（TCAP）プロトコル、及び簡易オブジェクト・アクセス・プロトコル（SOAP）の１つに従って構成されるセッション招待メッセージの一部として、問合せを生成し、送信するステップを有する、請求項１に記載の方法。
【請求項５】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定され、前記ルーピングエンジン内に格納される、請求項１に記載の方法。
【請求項６】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項１に記載の方法。
【請求項７】
前記交換機要素と前記ルーピングエンジンの間の情報は、SIPを介して交換され、前記ルーピングエンジンにより返送される前記メッセージは、300リダイレクト要求応答メッセージである、請求項４に記載の方法。
【請求項８】
前記メッセージは、ルーピング状態が存在することを示し、前記メッセージは、前記交換機要素によりループロックコマンドとして解釈される交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有し、
前記方法は、前記交換機要素が、代替ルーティングに対して前記呼申込みを解放するステップを更に有する、請求項１に記載の方法。
【請求項９】
前記ルーピングデータベースに問合せを行うと、前記呼識別データを前記呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録するステップと、
前記呼識別データの発生回数をインクリメントするステップと、
を更に有する、請求項３に記載の方法。
【請求項１０】
前記ルーピングエンジンがクリーンアップスレッドを有し、
前記方法は、前記ルーピングデータベースから呼識別データの古い発生を削除するステップを更に有し、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項３に記載の方法。
【請求項１１】
前記呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項１に記載の方法。
【請求項１２】
ルーピング状態を終了させる方法であって、
交換機要素とルーティングエンジンを有する交換機設備において、電話番号に対応付けられた呼に対する呼申込みを受信するステップと、
前記ルーティングエンジンを介して、ルーピング状態を確認するため、ルーピングエンジンに問合せを行うステップと、
を有し、
前記ルーピングエンジンは、ルーピング状態を確認し、該ルーピング状態が存在することを示すメッセージを前記ルーティングエンジンに返送し、
前記ルーティングエンジンは、代替ルーティングに対して前記呼申込みを解放する、方法。
【請求項１３】
ルーピング状態が存在することを示す前記メッセージは、前記ルーティングエンジンにより、ループロックコマンドとして解釈されるSWID及びTGIDを含む２パラメータコードを有する、請求項１２に記載の方法。
【請求項１４】
前記問合せを行うステップは、前記呼申込みに関連する呼識別データを有する問合せを前記ルーピングエンジンに送信するステップを有し、前記問合せは、SIP、TCAP、及びSOAPを含むグループから選択された１つのプロトコルに従い構成されるセッション招待メッセージの一部として送信される、請求項１２に記載の方法。
【請求項１５】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記方法は、所定時間フレーム内の前記呼申込みに関連する前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うことにより、前記ルーピングエンジンがルーピング状態を確認するステップを更に有し、
前記発生回数が所定カウントと一致する、又は超過する場合、前記ルーピングエンジンは、ルーピング状態が存在することを示す前記メッセージを前記ルーティングエンジンに返送する、請求項１４に記載の方法。
【請求項１６】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定される、請求項１５に記載の方法。
【請求項１７】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項１５に記載の方法。
【請求項１８】
前記ルーピングデータベースに問合せを行うと、前記呼識別データを前記呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録するステップと、
前記所定時間フレーム内の呼識別データの発生回数をインクリメントするステップと、
を更に有する、請求項１５に記載の方法。
【請求項１９】
前記ルーピングエンジンがクリーンアップスレッドを有し、
前記方法は、前記ルーピングデータベースから呼識別データの古い発生を削除するステップを更に有し、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項１５に記載の方法。
【請求項２０】
前記呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項１２に記載の方法。
【請求項２１】
通信ネットワーク内のルーピング状態を検出するためのシステムであって、
呼識別データをそれぞれ有する１以上の呼申込みを受信し、該呼識別データを用いて、１以上の問合せを生成し、送信するように構成される交換機要素を有する交換機設備と、
前記交換機要素と接続されるルーピングエンジンと、
を有し、
前記ルーピングエンジンは、前記１以上の問合せを受信し、及び所定時間フレーム内の少なくとも１つの前記呼申込みと関連する呼識別データの発生回数を確認し、前記発生回数と所定カウントを比較し、該比較に基づいて、前記通信ネットワーク内にルーピング状態が存在するかを示すメッセージを前記交換機要素に返送することにより、ルーピング状態を検出するよう構成される、システム。
【請求項２２】
前記発生回数が前記所定カウントと一致する、又は超過する場合、前記メッセージは、ルーピング状態が存在することを示し、
前記発生回数が前記所定カウントより少ない場合、前記メッセージは、ルーピング状態が存在しないことを示す、請求項２１に記載のシステム。
【請求項２３】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、前記所定時間フレーム内の前記少なくとも１つの呼申込みの前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うよう更に構成される、請求項２１に記載のシステム。
【請求項２４】
前記交換機要素は、セッション開始プロトコル（SIP）、トランザクション能力応用部（TCAP）プロトコル、及び簡易オブジェクト・アクセス・プロトコル（SOAP）の１つに従って構成されるセッション招待メッセージの一部として、問合せを生成し、前記ルーピングエンジンに送信するよう更に構成される、請求項２１に記載のシステム。
【請求項２５】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定され、前記ルーピングエンジン内に格納される、請求項２１に記載のシステム。
【請求項２６】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項２１に記載のシステム。
【請求項２７】
情報が、SIPを介して、前記交換機要素と前記ルーピングエンジンの間で交換され、前記ルーピングエンジンにより返送される前記メッセージは、300リダイレクト要求応答メッセージである、請求項２４に記載のシステム。
【請求項２８】
前記メッセージは、ルーピング状態が存在することを示し、前記メッセージは、前記交換機要素によりループロックコマンドとして解釈される交換機識別（SWID）及びトランクグループ識別（TGID）を含む２パラメータコードを有し、
前記交換機要素は、前記ループロックコマンドに応答して、代替ルーティングに対して前記少なくとも１つの呼申込みを解放するよう更に構成される、請求項２１に記載のシステム。
【請求項２９】
前記ルーピングエンジンは、前記呼識別データを前記少なくとも１つの呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録し、
前記呼識別データの発生回数をインクリメントするよう更に構成される、請求項２３に記載のシステム。
【請求項３０】
前記ルーピングエンジンがクリーンアップスレッドを有し、該クリーンアップスレッドは、前記ルーピングエンジンに、前記ルーピングデータベースから呼識別データの古い発生を削除させ、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項２３に記載のシステム。
【請求項３１】
前記少なくとも１つの呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項２１に記載のシステム。
【請求項３２】
ルーピング状態を終了させるためのシステムであって、
１以上の呼申込みを受信し、１以上の問合せを生成し、送信するよう構成された交換機要素とルーティングエンジンを有する交換機設備と、
前記交換機設備と接続されて、前記問合せを受信し、ルーピング状態を確認し、少なくとも１つのルーピング状態が存在することを示すメッセージを前記ルーティングエンジンに返送するよう構成されたルーピングエンジンと、
を有し、
前記ルーティングエンジンは、前記ルーピングエンジンからの返送メッセージに応答して、代替ルーティングに対して少なくとも１つの前記呼申込みを解放するよう構成される、システム。
【請求項３３】
前記メッセージはルーピング状態が存在することを示し、前記メッセージは、前記ルーティングエンジンにより、ループロックコマンドとして解釈されるSWID及びTGIDを含む２パラメータコードを有する、請求項３２に記載のシステム。
【請求項３４】
前記ルーティングエンジンは、前記少なくとも１つの呼申込みに関連する呼識別データを有する問合せを生成し、前記問合せを、SIP、TCAP、及びSOAPを含むグループから選択された１つのプロトコルに従い構成されるセッション招待メッセージの一部として、前記ルーピングエンジンに送信するよう更に構成される、請求項３２に記載のシステム。
【請求項３５】
前記ルーピングエンジンは、呼識別データ、及び関連する時間スタンプと時間フレームデータを格納するルーピングデータベースを有し、前記ルーピングエンジンは、所定時間フレーム内の前記少なくとも１つの呼申込みに関連する前記呼識別データの発生回数を確認するため、前記ルーピングデータベースに問合せを行うことにより、ルーピング状態を確認し、及び、
前記発生回数が所定カウントと一致する、又は超過する場合、ルーピング状態が存在することを示す前記メッセージを前記ルーティングエンジンに返送するよう構成される、請求項３４に記載のシステム。
【請求項３６】
前記所定時間フレーム及び所定カウントの少なくとも１つは、ユーザにより設定される、請求項３５に記載のシステム。
【請求項３７】
前記所定時間フレームは、時間の固定窓と時間のスライディング窓の１つである、請求項３５に記載のシステム。
【請求項３８】
前記ルーピングエンジンは、前記呼識別データを前記少なくとも１つの呼申込みに関連する時間スタンプと共に前記ルーピングデータベースに記録し、前記所定時間フレーム内の呼識別データの発生回数をインクリメントするよう更に構成される、請求項３５に記載のシステム。
【請求項３９】
前記ルーピングエンジンがクリーンアップスレッドを有し、該クリーンアップスレッドは、前記ルーピングエンジンに、前記ルーピングデータベースから呼識別データの古い発生を削除させ、該古い発生は、関連する所定時間フレームが終了してしまった呼識別データを含む、請求項３５に記載のシステム。
【請求項４０】
前記少なくとも１つの呼申込みに関連する前記呼識別データが、被呼／発呼番号ペアを有する、請求項３２に記載のシステム。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【公開番号】特開２０１２−６５３２６（Ｐ２０１２−６５３２６Ａ）
【公開日】平成２４年３月２９日（２０１２．３．２９）
【国際特許分類】
【出願番号】特願２０１１−２０３１５１（Ｐ２０１１−２０３１５１）
【出願日】平成２３年９月１６日（２０１１．９．１６）
【出願人】（５１０１７５６０９）インテレピア，インコーポレイティド (7)
【Ｆターム（参考）】
【公開日】平成２４年３月２９日（２０１２．３．２９）
【国際特許分類】
【出願日】平成２３年９月１６日（２０１１．９．１６）
【出願人】（５１０１７５６０９）インテレピア，インコーポレイティド (7)
【Ｆターム（参考）】
[ Back to top ]