JP5081912B2 - ディレクトリサービススキーマを使用した電話呼経路指定の管理 - Google Patents

ディレクトリサービススキーマを使用した電話呼経路指定の管理 Download PDF

Info

Publication number
JP5081912B2
JP5081912B2 JP2009520825A JP2009520825A JP5081912B2 JP 5081912 B2 JP5081912 B2 JP 5081912B2 JP 2009520825 A JP2009520825 A JP 2009520825A JP 2009520825 A JP2009520825 A JP 2009520825A JP 5081912 B2 JP5081912 B2 JP 5081912B2
Authority
JP
Japan
Prior art keywords
routing
call
usage
rules
policy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2009520825A
Other languages
English (en)
Other versions
JP2009545208A (ja
Inventor
ワイ．マキシモ ルイ
エー．クヌッドソン ダン
エイデルマン バディム
セカラン マヘンドラ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2009545208A publication Critical patent/JP2009545208A/ja
Application granted granted Critical
Publication of JP5081912B2 publication Critical patent/JP5081912B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/304—Route determination for signalling traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/64—Distributing or queueing
    • H04Q3/66—Traffic distributors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13138—Least cost routing, LCR
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway

Description

本発明は、電話呼経路指定の管理に関する。
ローカルに、地域的に、全国的に、かつ国際的にまで、複数の地理的ロケーションに渡る企業の拡大は、情報管理リソースに余分な負担をかける。エンタープライズネットワークは、ＩＰベースおよび電話ベースの通信を支持して、これらのロケーションを相互接続する手段を提供する。ＩＰシステムおよび電話システムの管理は共に、業界において競争力のある姿勢を維持する企業において、重要な役割を果たす。
多数の会社は、ＰＢＸ（構内交換機）電話システムを採用して、従業員、カスタマーおよび／またはベンダーの間の多数の呼を管理する。典型的には、ＰＢＸは、個々のシステムレベルにおける構成を必要とする可能性がある。よって、電話システムのアドミニストレータが会社のＰＢＸのロケーションの各々に必要とされ、あるいは、そうでない場合、構成およびトラブルシューティングを比較的都合のよい方法で行うことができるように、そのエリア内のシステムに割り当てられる。この制限は、複数の別々のシステム管理を管理するために余分なリソースを要するだけでなく、会社が、会社の電話通信を扱うために、いくつかのＰＢＸを含む可能性のあるエンタープライズネットワークを有するとき、技術管理のためのコストを増大させる。また、企業が国際的であることは、拡大する世界経済において増える傾向にあり、そのとき、電話通信システムの完全性を維持することは極めて重要になり得る。機器の故障、ハードウェア／ソフトウェア更新プロセス、および／または、オフラインにすること（offline function）はすべて、会社の最終損益に影響を及ぼす可能性がある。したがって、大企業の環境において、または、そのような管理責任を外注するより小さい会社でさえ、システムの問題に対処するために、職員による２４時間監督管理を必要とする可能性がある。
さらに、企業のロケーションが異なる国々にある場合には、例えば、ＶｏＩＰ（ボイスオーバーＩＰ）呼が、インターネットなど、グローバル通信ネットワークから、ローカルまたは公衆交換電話網（またはＰＳＴＮ）へトラバースするとき、各国が異なる規制順守制約を有する可能性がある。ＶｏＩＰテレフォニーシステムは、互いに依存しあう複数の部分からなる動的システムである。ゲートウェイがダウンするか、あるいはシステムから除去されるとき、呼が失われることを防止するために、電話経路指定ルールは動的に更新されなければならない。また、ＶｏＩＰ製品およびソリューションをこれらの国々で販売するために、国内規制の順守が厳密に監視かつフォローされなければならない。加えて、電話システムおよびネットワークを駆動するハードウェアおよび／またはソフトウェアの設計における見込みは言うまでもなく、変化する規制は、対応が困難かつ複雑になる可能性がある。よって、電話システム動作を効率的に管理するための能力は、会社の成功または失敗に著しい影響を及ぼす可能性がある。
以下は、開示されたイノベーションのいくつかの態様の基本的理解を提供するために、簡単な概要を提示する。この概要は広範な概観ではなく、重要／重大な要素を識別するように、あるいは、その範囲を線引きするように意図されない。その唯一の目的は、いくつかの概念を簡単な形式で、後に提示されるより詳細な説明の前置きとして提示することである。
開示されたアーキテクチャは、複数の電話システム（例えば、エンタープライズシステムに関連付けられた）での電話管理ハードウェアおよび／またはソフトウェアを効率的に扱うためのメカニズムを提供する。これは、呼管理のためのディレクトリサービススキーマの実装によって実現される。ディレクトリサービスは、ユーザーがいずれかのオブジェクト（例えば、ユーザー、システム、リソースおよびサービス）を、オブジェクト属性のうちの１つまたは複数に基づいて、その属性にマッチするオブジェクトのリストを得るためにディレクトリをクエリすることによって、発見することを可能にする。このスキーマを修正して、新しいタイプのオブジェクトまたはオブジェクトプロパティを実装することができる。
開示されたアーキテクチャの利用は、アドミニストレータがもはや、個々の各電話システム（例えば、ＰＢＸ（構内交換機））において経路指定ルールを指定することを必要とされないことを意味する。また、フィールドおよびレコードからなるデータベーステーブルを使用してルールを表すのではなく、これらのルールはクラスのインスタンスとして表される。アドミニストレータが定義することができる使用テーブルを使用することによって、これはアドミニストレータに、様々なシナリオについて電話経路を作成するための柔軟性を可能にする。例えば、アドミニストレータがシステムからゲートウェイを除去するか、あるいは使用ポリシーを削除するとき、識別名（ＤＮ）を使用して、電話経路指定ルールを自動的に更新することができる。すなわち、ある（ディレクトリサービスを実行中の）サーバーで変更されたルールは、ネットワーク上の他のディレクトリサービスサーバーへ自動的に伝播（あるいは、レプリケート）される。よって、呼が「デッド」ゲートウェイへ行くことを防止しながら、電話経路の完全性が維持される。
それを支持して、本明細書で開示され、特許請求の範囲に記載されるものは、呼管理を容易にする、コンピュータに実装されたシステムである。このシステムは、ディレクトリサービススキーマを生成するためのスキーマコンポーネント、および、ディレクトリサービススキーマによって定義された呼経路指定ルールに従って電話呼を経路指定する呼経路指定コンポーネントを含む。ルールが処理されて、経路指定コンポーネントに、電話通信フレームワーク（例えば、ＰＳＴＮ（公衆交換電話網）、セルラーネットワーク）を介して、呼を経路指定させる。さらに別の例では、呼経路指定コンポーネントは、ＶｏＩＰ（ボイスオーバーＩＰ）通信システムとインターフェイスすることを含む、電話通信フレームワークを介して、呼を経路指定する。
さらにもう１つの代替実装では、確率論的および／または統計ベースの解析を採用して、自動的に行われることをユーザーが望むアクションを予知あるいは推測する、マシン学習および推論（ｍａｃｈｉｎｅ ｌｅａｒｎｉｎｇ ａｎｄ ｒｅａｓｏｎｉｎｇ）コンポーネントが採用される。
前述および関連の目的の実施に対して、開示されたイノベーションのある例示的態様が、以下の説明および付属の図面に関連して本明細書で説明される。これらの態様は、本明細書で開示された原理を採用することができる様々な方法の少数を示すが、そのようなすべての態様およびそれらの均等物を含むように意図される。他の利点および新規の特徴は、図面と共に考慮されるとき、以下の詳細な説明から明らかになるであろう。
呼管理を容易にする、コンピュータに実装されたシステムを例示する図である。 開示されたアーキテクチャによる、呼を管理する方法を例示する図である。 呼を管理するためのエンタープライズ呼管理システムを例示する図である。 ディレクトリサービスにおいて採用することができる１つの例示的なＡＰＩのセットのテーブルを例示する図である。 短くて、ユーザーフレンドリな名前文字列を使用して使用属性を定義するための、例示的属性テーブルを例示する図である。 １人または複数のユーザーを、図５において定義された使用属性のポリシーに関連付けるための、例示的ユーザーテーブルを例示する図である。 例示的経路指定テーブルを例示する図である。 経路指定ルールを使用した呼処理および経路指定の方法を例示する図である。 ユーザーポリシーと組み合わせて経路指定ルールを使用する、呼処理および経路指定の代替方法を例示する図である。 経路指定ルールにおいて呼宛先番号範囲および／またはパターンを採用する方法を例示する図である。 呼経路指定のためのポリシーを利用する方法を例示する図である。 ディレクトリサービス呼管理システムにおけるクラス変更を更新する方法を例示する図である。 １つまたは複数の機能の自動化を容易にするマシン学習および推論コンポーネントを採用する、代替システムを例示する図である。 ゲートウェイ通信を管理するための仲介ゲートウェイを採用する、代替システムを例示する図である。 開示された呼経路指定アーキテクチャによる、分散ディレクトリサービスおよびルールクラス／属性定義のための１つの例示的スキーマを例示する図である。 アドミニストレータ（またはユーザー）対話に、開示された呼ディレクトリサービスの様々な機能を提供するための、例示的通信プログラムＵＩを例示する図である。 メディアゲートウェイを構成するための中間ウィザードウィンドウを例示する図である。 プロビジョンウィザードの追加のプロビジョニングウィンドウを例示する図である。 エントリ（またはルール）のアドミニストレータ制御を容易にする一連のウィンドウを例示する図である。 図１９のウィンドウのＰｈｏｎｅｓタブを選択するときに提示されるＵＩを例示する図である。
図１９のウィンドウのＧａｔｅｗａｙｓタブを選択するときに提示されるＵＩを例示する図である。 開示されたアーキテクチャによるディレクトリサービスおよび呼経路指定ルールを実行するように動作可能なコンピュータ（またはサーバー）のブロック図を例示する図である。 開示されたアーキテクチャによる呼管理のためのディレクトリサービスをサポートする、例示的コンピューティング環境の概略ブロック図を例示する図である。
ここで、本イノベーションが図面を参照して説明される。図面において、類似の参照番号は全体を通じて類似の要素を示すために使用される。以下の説明では、説明のため、その完全な理解を提供するために多数の特定の詳細が述べられる。しかし、本イノベーションをこれらの特定の詳細なしに実施することができることは、明らかであろう。他の場合、周知の構造およびデバイスは、その説明を容易にするために、ブロック図の形式において図示される。
開示されたアーキテクチャは、複数の電話システム（例えば、エンタープライズシステムに関連付けられた）で電話管理ハードウェアおよび／またはソフトウェアを効率的に扱うためのメカニズムを提供する。これは、呼管理のためのディレクトリサービススキーマの実装によって実現される。ディレクトリサービスは、ユーザーがいずれかのオブジェクト（例えば、ユーザー、システム、リソースおよびサービス）を、オブジェクト属性のうち１つまたは複数に基づいて、その属性にマッチするオブジェクトのリストを得るためにディレクトリをクエリすることによって、発見することを可能にする。１つの実装では、ディレクトリサービスは、スキーマによって定義されたルールを採用する。このスキーマは、単一の修正可能かつ拡張可能なスキーマである。このスキーマは、ディレクトリサービスオブジェクトのための構造要件を提供するオブジェクトおよびルールのセットである。このスキーマを修正して、新しいタイプのオブジェクトまたはオブジェクトプロパティを実装することができる。一実施例のオブジェクトを、その名前、ロケーション、ポート、および他の所望の情報を識別する属性（またはプロパティ）を有する、ネットワークゲートウェイとすることができる。
スキーマは、オブジェクトクラス（例えば、ユーザーおよびゲートウェイ）を互いに区別するために利用される。スキーマ情報は、アドミニストレータが属性をオブジェクトクラスに追加すること、および、いかなるドメインコントローラ（ディレクトリサービスを実行中の、他のロケーションにおけるサーバー）をも再起動することなく、クラスを、ネットワークを介して他のサーバーに分散させることを可能にする。各オブジェクトは、識別名（ＤＮ）と呼ばれるＬＤＡＰ（ライトウェイトディレクトリアクセスプロトコル）の属性により、一意に識別される。
分散ディレクトリシステムを活用することによって、経路指定ルール（例えば、最小コスト経路指定（ＬＣＲ）ルール）を一度作成し、影響を受けるすべてのシステムに一律に適用することができる。ＬＣＲルールは、例えば、企業が、ビジネスプロセスに影響を及ぼすことなく、最も費用対効果の高い経路（パス）を介して、呼をインテリジェントに経路指定することを可能にする。例えば、ユーザープロファイル、料金表、ネットワーク可用性、回線品質、地理的変動、メッセージサイズ、および信号品質に関係付けられた優先順位に基づいて、呼を経路指定するために使用可能ないずれかのタイプのメディアおよび技術を使用するために、例えば、音声サービスプラットフォームを実装することができる。
開示されたアーキテクチャの利用は、アドミニストレータがもはや、個々の各電話システム（例えば、ＰＢＸ（構内交換機））において経路指定ルールを指定することを必要とされないことを意味する。また、フィールドおよびレコードからなるデータベーステーブルを使用してルールを表すのではなく、これらのルールはクラスのインスタンスとして表される。アドミニストレータが定義することができる使用テーブルを使用することによって、これはアドミニストレータに、様々なシナリオについて電話経路を作成するための柔軟性を可能にする。例えば、アドミニストレータがシステムからゲートウェイを除去するか、あるいは使用ポリシーを削除するとき、ＤＮを使用して、電話経路指定ルールを自動的に更新することができる。すなわち、（ディレクトリサービスを実行中の）あるサーバーで変更されたルールは、ネットワーク上の他のディレクトリサービスサーバーへ自動的に伝播（あるいは、レプリケート）される。よって、電話経路の完全性は、呼が「デッド」ゲートウェイへ行くことを防止することを維持している。
最初に図面を参照すると、図１は、呼管理を容易にする、コンピュータに実装されたシステム１００を例示する。システム１００は、分散ディレクトリサービス１０４を提供するためのサービスコンポーネント１０２、および、呼経路指定ルール１１０に従って電話呼１０８（例えば、固定呼、セルラー呼、ＶｏＩＰ呼、．．．）を経路指定する呼経路指定コンポーネント１０６を含む。ルール１１０は、スキーマコンポーネント１１２を使用して生成することができる、ディレクトリサービススキーマ１１３によって定義される。ルール１１０を処理して、経路指定コンポーネント１０６に、電話通信フレームワーク１１４（例えば、ＰＳＴＮ（公衆交換電話網）、セルラーネットワーク）を介して、呼１０８を経路指定させる。さらにもう１つの実施例では、呼経路指定コンポーネント１０６は、ＶｏＩＰ（ボイスオーバーＩＰ）通信のためのＩＰネットワーク（例えば、インターネット）とインターフェイスすることを含む、電話通信フレームワーク１１４を介して、呼１０８を経路指定する。
呼経路指定ルール１１０は、例えば、発呼（ｏｒｉｇｉｎａｔｉｎｇ ｃａｌｌ）（例えば、エンタープライズの）が、ＶｏＩＰになる可能性のある、よりよい経路を介して経路指定される発信呼（ｏｕｔｇｏｉｎｇ ｃａｌｌ）に処理されるようにする、最小コスト経路指定（ＬＣＲ）処理を含むことができる。他のルールには、限定されないが、時刻、曜日、リクエストされたサービス品質などが含まれる可能性がある。したがって、ルール１１０の１つまたは複数は、（例えば、ＰＳＴＮおよびローカルＰＳＴＮインフラストラクチャなど、ＩＰネットワークと電話ネットワークの間のインターフェイスを提供する）呼経路指定のためのゲートウェイ（図示せず）を識別するようになる。
ルール１１０は、スキーマ１１３において、例えば、オブジェクト、オブジェクトクラス、および、クラスのインスタンスによって定義される。加えて、１つまたは複数の使用ポリシー１１６を、ユーザー、または、ユーザーのグループ毎に作成することができる。１つの実装では、ルール１１０およびポリシー１１６を組み合わせて処理して、どのように呼が経路指定されるべきであるか（例えば、ＶｏＩＰ対ＰＳＴＮ）、および、そもそも呼が経路指定されるべきであるかどうかを決定することができる。例えば、使用ポリシーが、ユーザーにＶｏＩＰ呼経路指定が許可されないことを示す場合、ネットワークがそのときＶｏＩＰについて呼の処理を扱うことができる場合があるとしても、ユーザーの呼は、ＶｏＩＰでは経路指定されないようになる。代替実装では、ルール１１０は、ポリシー１１６から独立した呼経路指定について処理される。
ディレクトリサービスが採用されることを考えるならば、サービスコンポーネント１０２（例えば、ディレクトリサービスサーバー）は、サーバー通信フレームワーク１１８（例えば、インターネットなど、ＩＰフレームワーク）を介して、他の互換性のあるディレクトリサービスコンポーネントとインターフェイスする。また、ＶｏＩＰが採用されるとき、電話通信フレームワーク１１４の態様は、サーバー通信ネットワーク１１８と直接インターフェイスして、呼の成立を容易にすることができることを理解されたい。さらに、ケーブルおよび／または衛星テレビシステムもまた、電話およびサーバー通信フレームワーク（１１４および１１８）を介した呼通信のために採用することができる。
１つの例示的実装では、要件ではないが、システム１００は、マイクロソフト社による製品であるアクティブディレクトリ（商標）など、分散ディレクトリシステムを採用する。アクティブディレクトリは、ＬＤＡＰに準拠してインターネットのドメインネームシステム（ＤＮＳ）を基礎とする、拡張階層ディレクトリサービスである。例えば、ワークグループにウェブサイトのようなドメインネームを割り当てることができ、いかなるＬＤＡＰ準拠のクライアントもそれへのアクセスを得ることができる。加えて、ディレクトリサービスは、異種エンタープライズネットワークとしての機能を果たし、他のサードパーティディレクトリサービスを包含することができる。
開示されたアーキテクチャは、ＤＮを使用して、自動的に同期されたポリシー、使用定義、ゲートウェイおよび経路の間の依存関係を維持することができる。例えば、アドミニストレータがネットワークデバイス（例えば、ＶｏＩＰゲートウェイ）をシステムからデコミッション（ｄｅｃｏｍｍｉｓｓｉｏｎｓ）する場合、この情報は自動的に経路指定ルールに伝播する。次いで、このネットワークエンティティ（例えば、ゲートウェイ）を参照するルールは、そのステータスを反映するように更新される。アドミニストレータが既存の使用定義をリネームする場合、ルールおよびポリシーは新しい使用名を自動的に参照し、よって、アドミニストレータによるいかなる追加の労力もなしに、システム（例えば、ＶｏＩＰ）の完全性が維持される。ルールは、クラス、および、クラスのインスタンスによって表される。
ハードウェアは、オフラインになり、オンラインに復帰することができる。ゲートウェイは、例えば、経路から参照されるか、あるいは、経路から参照されない可能性がある。しかし、ゲートウェイが経路によって参照されるからといって、ゲートウェイがオンラインであるという意味ではない。したがって、ロジックを、静的デバイス状態（デバイスがオンラインであるかオフラインであるか）、ならびに、動的変化（作業中のデバイスの状態のアクティブな変化）を扱うために提供することができる。静的状態には、デバイスがどのようにディレクトリサービスにおいて表されるかが含まれる可能性がある。動的状態は、作業中のデバイスから、そのデバイスに対してあることを行うようにというリクエストに基づいて受信される、リアルタイムフィードバックである。
例えば、ＶｏＩＰシステムでは、このシステムの構築に含まれた複数のサーバーがある可能性があるので、あらゆるサーバーが一律に同じ経路指定ロジックにより構成されるべきである。開示されたディレクトリサービスを活用して、電話経路ルールをパブリッシュすることによって、このサービスにサブスクライブしたあらゆるサーバーは、これらのルールへの更新（アドミニストレータによって行うことができる）を自動的に得る。構成可能な使用テーブルを使用することによって、アドミニストレータは、システムの設計ロジックを過度に複雑にすることなく、それらのビジネスニーズを満たすことができる経路指定ルールを構成するための柔軟性を有する。
図２は、開示されたアーキテクチャによる、呼を管理する方法を例示する。説明を簡単にするために、本明細書で、例えば、フローチャートまたはフロー図の形式において図示される１つまたは複数の方法は、一連の動作として図示かつ説明されるが、本イノベーションは動作の順序によって限定されず、いくつかの動作は、本イノベーションによれば、本明細書で図示かつ説明されたものとは異なる順序で、かつ／または、他の動作と同時に起こってもよいことを理解されたい。例えば、ある方法を、別法として、状態図においてなど、一連の相関状態またはイベントとして表すことができることは、当業者には理解されよう。また、本イノベーションによる方法を実装するために、すべての例示された動作が必要とされるとは限らない場合がある。
２００で、呼経路指定システムの電話経路指定データは、クラスのインスタンスから構成された１つまたは複数のルールとして表される。２０２で、１つまたは複数のルールが呼経路指定システムの呼経路指定テーブルに格納される。２０４で、１つまたは複数のルールが、発呼に基づいた処理のためにエクスポーズされる。２０６で、呼が、呼ネットワークを介して、１つまたは複数のルールに書かれた経路指定データに基づいて、経路指定される。
ここで図３を参照すると、呼を管理するためのエンタープライズ呼管理システム３００が例示される。この特定の実装では、システム３００は、ディレクトリサービスのために構成された複数のサーバー（サーバー１、サーバー２、．．．、サーバーＮと示され、ただし、Ｎは正の整数である）を含む。例えば、第１のサーバー３０２は、呼経路指定コンポーネント１０６（呼１０８の処理用）およびローカル電話通信フレームワーク１１４に関連付けられる。第１のサーバー３０２は、ディレクトリサービス１０４、少なくともその経路指定ルールを格納する経路指定テーブル３０４、スキーマ１１３、および使用ポリシー１１６を含む。同様に、第２のサーバー３０６は、呼経路指定コンポーネント３０８（呼３１０の処理用）およびローカル電話通信フレームワーク３１２に関連付けられる。第２のサーバー３０６は、ディレクトリサービス１０４、その経路指定ルールを格納する経路指定テーブル３０４、スキーマ１１３（オプションによる）、および使用ポリシー１１６を含む。最後に、Ｎ番目のサーバー３１４は、呼経路指定コンポーネント３１６（呼３１８の処理用）およびローカル電話通信フレームワーク３２０に関連付けられる。Ｎ番目のサーバー３１４は、ディレクトリサービス１０４、その経路指定ルールを格納する経路指定テーブル３０４、スキーマ１１３（オプションによる）、および使用ポリシー１１６を含む。
図示のように、サーバー（３０２、３０６、．．．、３１４）は、コーポレートエンタープライズのための呼経路指定管理のサポートにおいて提供される。サーバー（３０２、３０６、．．．、３１４）は、ＩＰネットワーク３２２（例えば、ＬＡＮ、ＭＡＮ（メトロポリタンエリアネットワーク）、ＷＡＮ（広域ネットワーク）、インターネット）を介して、サービス、ルール、ルールテーブル、およびポリシーの同期化を行うことができるように通信する。各サーバー（３０２、３０６、．．．、３１４）におけるサービス、ルール、ポリシーおよびスキーマの各々の例示は、これらの各々が、ディレクトリサービスアーキテクチャによって、いかなるサーバーからもアクセス可能であることを表すように意図されることを理解されたい。例えば、第１のサーバー３０２を含む、企業本部のロケーションにおけるアドミニストレータは、そのロケーションにおけるスキーマ１１３、ルールの経路指定テーブル３０４、および使用ポリシー１１６を開発することができる。その後、この情報が、データ同期化の一部として、他のエンタープライズサーバー（３０６、．．．、３１４）に伝播され、企業サーバー３０２が故障する場合、残りのサーバー（３０６、．．．、３１４）が、例えば、経路指定テーブルおよびポリシーの最新データに基づいて呼管理を維持することができるようになる。代替実装では、ルールテーブル３０４および／またはポリシー１１６を、関連付けられた経路指定コンポーネント１０６に格納することができる。
ディレクトリサービス１０４は、オブジェクトクラス（例えば、２つ）を論理的に表し、呼経路指定プロセスの管理を容易にするために定義される、１つまたは複数のＡＰＩ（アプリケーションプログラムインターフェイス）３２４を含むことができる。ＡＰＩ３２４は、以下でより詳細に説明される。
データベーステーブル（フィールドおよびレコードからなる）を使用して、呼経路指定ルールを経路指定テーブル３０４（例えば、ＬＣＲ（最小コスト経路指定）ルール）において表すのではなく、ルールはクラスのインスタンス、この場合はディレクトリサービスのクラスオブジェクトとして表される。従来のＰＢＸシステムでは、例えば、経路指定ルールは個々の各ＰＢＸシステム上で指定されなければならない。反対に、開示されたアーキテクチャの分散ディレクトリサービス１０４を活用することによって、経路指定ルールを一度作成し、すべての他の互換性のある、かつ同様に構成された呼管理のためのサーバーに、一律に適用することができる。
分散ディレクトリサービス（例えば、サービス１０４）は、ネットワーク変化または障害の都合の良い考慮および対処を容易にする。ルールは、すべてのエンタープライズサーバーシステムにとってグローバルである。ルールを１つの場所に格納することができ、その場所へのアクセスは、すべての他のエンタープライズシステムによって提供される。例えば、ネットワークアドミニストレータがシステムからゲートウェイを除去するか、あるいは使用データを削除するとき、ＤＮを使用することによって、電話経路指定ルールを自動的かつ／または動的に更新することができる。よって、呼管理システム３００の完全性は、非アクティブ化あるいはデコミッションされたゲートウェイへ呼が経路指定されることを防止することによって、維持される。また、アドミニストレータが定義することができる使用テーブルを使用することによって、これはアドミニストレータに、様々な代替経路指定接続のための電話経路（または経路指定ルール）を作成する柔軟な能力を可能にする。
電話呼がその宛先に達するために、呼は最も適切なネットワークエンティティ（例えば、ゲートウェイ）へ経路指定されるべきである。どのように呼を（例えば、ＬＣＲによって）経路指定することが最良かを決定するためのロジックを、アドミニストレータによって手動で構成することができるルール経路指定テーブル３０４において定義することができる。これらのルールをデータベースレコードとしてエクスポーズするのではなく、ルールは１つまたは複数のクラスのインスタンスとしてエクスポーズされる。
１つの実装では、ルールは、宛先電話番号の範囲および／またはパターンを含む。電話呼が出されるとき、サービス（またはサーバー）３０２は、どのルールが宛先番号にマッチするかを決定する。１つより多くのマッチがある場合、サーバー３０２は、ポリシー１１６のうち１つの使用フィールドに基づいて、発呼者がどのルールを使用することが許可されるかを決定する。別の実装では、ポリシー処理を、ポリシー情報におけるパターンマッチに従うようにすることができる。ユーザーのポリシーが電話経路指定ルールに割り当てられた使用にマッチする場合、呼はその経路を介するように指定される。
さらに、経路指定および／またはポリシー処理が、ブール論理を採用するルールを含むことは、本アーキテクチャの企図内である。例えば、「このポリシーは、毎日午前５時〜午後５時の時間の間でのみ処理されるようになる」というルールを開発することができる。別の実施例は、経路指定ルールおよびポリシーを組み合わせて、「ユーザーＡは、木曜、午後６時と真夜中の時間の間に、経路Ｆを介して経路指定される」とする。言い換えれば、論理的には、「ルールＦおよびポリシーＣ」を実行する。ロジックを採用して、ユーザーのアイデンティティ、ユーザーロケーション、時刻、ＱｏＳ（サービスの品質）、ユーザープリファレンス、優先順位、システムプロパティの費用対効果解析などを考慮することができる。このような能力は、例えば、ベンダーおよびカスタマーがそれら自身のシステム構成をカスタマイズすることができる、より直観的な実装を容易にする。
別の実装は、呼のブロッキングを容易にする。よって、ある電話番号（例えば、１−９００の番号）へのアクセスをブロックするポリシーを開発することができる。別の実施例は、あるタイプの情報のみを、所与の経路を介して経路指定する。例えば、解析によって学習かつ推論されるように、ある経路が経時的に別の経路より信頼性が高いことが分かり、通信中の情報（例えば、チーフエグゼクティブ）が他の情報よりも重要であると見なされる場合、この接続をこのユーザーにとって使用可能にするポリシーを採用することができる。これらはしかし、ディレクトリサービススキーマ開発および実装によって提供される柔軟性のわずかな例でしかない。
図４は、ディレクトリサービスにおいて採用することができるＡＰＩの１つの例示的セットのテーブルを例示する。ＡＰＩ（例えば、ＷＭＩ（ウィンドウズ（登録商標）マネジメントインストゥルメンテーション（ｗｉｎｄｏｗｓ ｍａｎａｇｅｍｅｎｔ ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）））は、開示された呼管理システムの管理を容易にするために定義される。これらのＡＰＩは、論理的に２つのクラスを表す。例えば、MSFT_SIPPhoneRouteSettingクラスのインスタンスは、経路指定ルールをオブジェクト指向クラスとして表す。別の実施例では、MSFT_SIPPhoneRouteUsageDataクラスのインスタンスは、使用属性をオブジェクト指向クラスとして表す。
第１のプロパティ（設定番号Ｃ１により識別される）は、経路指定ルールインスタンスＩＤ（例えば、MSFT_SIPPhoneRouteSetting::InstanceID）である。有効値もデフォルト値も規定されない。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、それは決して使用可能ではない。代替シナリオでは、このプロパティは、エクスポーズされるために使用可能である。第２のプロパティ（設定番号Ｃ２により識別される）は、１つまたは複数のゲートウェイ（例えば、ＳＩＰ（セッション開始プロトコルゲートウェイ））経路指定ルールインスタンスＩＤに提供される電話番号範囲またはパターン（例えば、MSFT_SIPPhoneRouteSetting::TargetPhoneNumbers）である。一実施例では、有効値には、１０２４文字までのユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、このプロパティはエクスポーズされるために使用可能である。対象電話番号を正規表現、または、単一の正規表現として演算子「｜」によって区切って、共にチェーンすることができる。
第３のプロパティ（設定番号Ｃ３により識別される）は、経路指定するためのゲートウェイのリスト（例えば、MSFT_SIPPhoneRouteSetting::GatewayList）である。一実施例では、有効値には、最大２５６文字の完全修飾ドメインネームおよびポート情報のユニコード文字列配列（FQDN:PORT）が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
第４のプロパティ（設定番号Ｃ４により識別される）は、電話経路使用データ（例えば、MSFT_SIPPhoneRouteSetting::PhoneUsage）である。一実施例では、有効値には、配列MSFT_SIPPhoneRouteUsageDatsa::UsageDNs）が含まれる可能性がある。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
第５のプロパティ（設定番号Ｃ５により識別される）は、電話経路記述（例えば、MSFT_SIPPhoneRouteSetting::Description）である。一実施例では、有効値には、最大１０２４文字のユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
第６のプロパティ（設定番号Ｃ６により識別される）は、電話経路フレンドリ名（例えば、MSFT_SIPPhoneRouteSetting::Name）である。一実施例では、有効値には、最大１０２４文字のユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、それは決して使用可能ではない。代替シナリオでは、このプロパティは、エクスポーズされるために使用可能である。この値は一意であるべきである。
第７のプロパティ（設定番号Ｃ７により識別される）は、マッチした電話番号を、キャリアコード挿入のために異なる番号へ変換すること、ダイヤル可能フォーマットへの変換などのための電話経路設定変換（例えば、MSFT_SIPPhoneRouteSetting::Translation）である。一実施例では、有効値には、最大１０２４文字のユニコード文字列が含まれる可能性がある。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、それは常に使用可能である可能性がある。
第８のプロパティ（設定番号Ｃ８により識別される）は、電話使用インスタンスＩＤ（例えば、MSFT_SIPPhoneRouteUsageData::InstanceID）である。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、それは決して使用可能ではない。代替シナリオでは、このプロパティは、エクスポーズされるために使用可能である。
第９のプロパティ（設定番号Ｃ９により識別される）は、オブジェクトの識別名（例えば、MSFT_SIPPhoneRouteUsageData::UsageＤＮ）である。有効値には、識別名が含まれる。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、１つの実装では、それは決して使用可能ではない。代替シナリオでは、このプロパティは、エクスポーズされるために使用可能である。
第１０のプロパティ（設定番号Ｃ１０により識別される）は、使用属性名（例えば、MSFT_SIPPhoneRouteUsageData::Attribute）である。一実施例では、有効値には、最大２５６文字のユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
第１１のプロパティ（設定番号Ｃ１１により識別される）は、使用記述（例えば、MSFT_SIPPhoneRouteUsageData::Description）である。一実施例では、有効値には、最大１０２４文字のユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
第１２のプロパティ（設定番号Ｃ１２により識別される）は、カスタムビジネスロジックを使用（例えば、時刻、サービスの品質、．．．）にアタッチするための使用アタッチメント（例えば、MSFT_SIPPhoneRouteUsageData::Attach）である。一実施例では、有効値には、最大１０２４文字のユニコード文字列が含まれる可能性がある。このプロパティのデフォルト値はヌルである。ユーザーインターフェイスを介してユーザーにエクスポーズされることに関して、このプロパティは、エクスポーズされるために使用可能である。
このテーブルは、定義することができるプロパティのタイプの一実施例でしかなく、網羅的なリストではないことに留意されたい。加えて、有効値を、大文字と小文字を区別するフォーマットについて開発することもできることに留意されたい。
図５は、短縮ユーザーフレンドリ名文字列を使用して使用属性を定義するための、例示的属性テーブルを例示する。ここでは、コーポレートエンタープライズの３つの市（市１、市２および市３）が、関連付けられた常勤者（ＦＴＥ）、および、非常勤または臨時従業員属性記述と共に定義される。加えて、ローカルおよび長距離コストが、１つまたは複数のドル記号「＄」として表されて、ドル記号に関連付けられた相対コストが示される。
１つの実装では、１つまたは複数の使用属性が順序付けされ、定義されて、単一のユーザーまたは複数のユーザーである可能性のあるユーザーカテゴリに割り当てられるポリシーが形成されることに留意されたい。別の実装では、各ユーザーに直接、使用属性（ここでは、複数の属性が使用される）の順序付きセットを割り当てることができる。どちらの実装も、アドミニストレータの判断により、開示されたディレクトリサービスアーキテクチャにおいて採用することができることを理解されたい。
図６は、１人または複数のユーザーを、図５において定義された使用属性のポリシーに関連付けるための、例示的ユーザーテーブルを例示する。このテーブルは、２つの列、すなわち、単一のユーザーおよび／またはユーザーのグループである可能性のある、ユーザーのカテゴリをリストするユーザー列、および、単一の使用属性または複数の順序付き使用属性として、ポリシーをリストするポリシー列を含む。単一の属性はポリシーを定義することができ、複数の順序付き属性もまたポリシーを定義することができる。この環境のあらゆるユーザーおよび／またはユーザーのグループを、１つまたは複数の使用属性に従って定義されるような使用許可を表すポリシー（例えば、MSFT_SIPGlobalUCPolicyData::PhoneUsage）に関連付けることができる。ポリシーは、所定の方法で順序付けされた１つまたは複数の使用属性を含む。よって、アドミニストレータは、ユーザーポリシーを構成して、所望の順序における呼経路指定を容易にすることができる。
例えば、ＣＩＴＹ１＼ＤＯＭＡＩＮ ＵＳＥＲＳグループにおけるＣＩＴＹ１ドメインユーザーは、そのグループのユーザーのすべての呼をローカルにＣＩＴＹ１のローカルキャリアへ経路指定するための、単一のＣＩＴＹ１使用属性を有するポリシーに関連付けられる。第２のグループについて図示するように、第２の市であるＣＩＴＹ２のユーザーのグループであるＣＩＴＹ２＼ＤＯＭＡＩＮ ＵＳＥＲＳグループにおけるユーザーを、実行の優先順位について順序付け（例えば、左から右へ）された、１つより多くの使用属性を有するポリシーに関連付けることができる。例えば、このポリシーの第１の使用属性（ＬＯＣＡＬと示される）は、最初に、宛先電話番号を使用して、この市（ＣＩＴＹ２）内でローカルに呼経路指定を試みるように動作する。呼がＬＯＣＡＬ使用属性に従ってローカルに経路指定されなければ、このポリシーの２番目に低い優先順位の使用属性（ＬＯＮＧ−ＤＩＳＴＡＮＣＥと示される）が実行されて、呼が長距離として経路指定されるようになる。なお、さらに、呼が第２の使用属性に従って長距離で経路指定されなければ、このポリシーのさらに低い優先順位の第３の使用属性（ＣＩＴＹ２と示される）が実行されて、呼が、ＣＩＴＹ２として識別された経路（事実上、発呼者にとってローカルのデフォルト経路）へ経路指定される。よって、複数の使用属性を、ユーザーポリシーにおいて実行または処理について優先順位付けすることができる。
同様に、第２の市（ＣＩＴＹ２と示される）におけるすべてのエグゼクティブを、ＥＸＥＣＵＴＩＶＥＳグループにグループ化し、複数の優先順位付き使用属性、すなわち、ＬＯＣＡＬ、ＬＯＮＧ−ＤＩＳＴＡＮＣＥ、ＣＩＴＹ２およびＣＩＴＹ３のポリシーに割り当てることができる。他の単一および複数の使用属性ポリシーを、図示のように、他の市について割り当てることができる。
図７は、例示的経路指定テーブルを例示する。この実施例では、このテーブルは、経路、電話番号パターン（または範囲）、使用属性、および次のホップのための列を含む。例えば、第１の経路（ＣＩＴＹ１−ＡＬＬ）は、宛先電話番号のすべての文字列の文字においてマッチング動作を行うために、ワイルドカード文字（＊）を使用して、第１の市（ＣＩＴＹ１）に関連付けられる。使用属性は、図５の属性テーブルにおいて定義されるように、ＣＩＴＹ１を採用した。ゲートウェイのための次のホップ情報（Ｃｉｔｙ１−ｇｗ．ｃｏｒｐ．１２３．ｃｏｍ：Ｐｏｒｔ）は、現行のルーターまたはゲートウェイの発信ポート（ＰＯＲＴ）を通じて達することができる、次のゲートウェイデバイスのアドレスおよびポートを定義する。他の複数の実施例が図示される。
動作においては、発呼者の宛先電話が受信され、経路指定テーブルにリストされたパターン（または範囲）に対して処理されて、１つまたは複数のマッチする経路指定ルールが発見される。マッチしたルールのうち、次に、マッチしたルールの使用属性が、ユーザー、または、発呼者がメンバーであるユーザーのグループの、ポリシーに割り当てられた使用属性と比較される。例えば、発呼者がＣＩＴＹ１＼ＤＯＭＡＩＮ ＵＳＥＲＳグループのメンバーとして定義される場合、マッチしたルールの使用属性が、そのグループに関連付けられたポリシーの単一の使用属性ＣＩＴＹ１と比較されるようになる。図を見ると分かるように、発呼者の宛先電話番号が経路指定テーブルの第１のルール（ＣＩＴＹ１−ＡＬＬ）にマッチする場合、そのルールの使用属性は、発呼者がメンバーであるグループのためのポリシーの使用属性にマッチする。よって、宛先番号およびユーザーポリシーの両方においてマッチがある。したがって、呼は、その経路指定ルールの「次のホップ」列にリストされたゲートウェイへ経路指定されるようになる。よって、最良の経路を、アドミニストレータによって定義されたように選択することができる。呼は次いで、通信フレームワーク（例えば、ＰＳＴＮ（公衆交換電話網）、セルラーネットワーク、ＶｏＩＰ（ボイスオーバーＩＰ）ネットワーク、．．．）を介して、呼宛先システムへ経路指定される。
別の実施例では、同じ発呼者が、ＣＩＴＹ２−ＬＯＣＡＬというラベル付きの第２のルールのための番号パターンにマッチする宛先電話番号を使用して、呼を行うことを考察する。発呼者は、呼がＣＩＴＹ１使用属性に従って行われることのみを許可するポリシーを有する、ＣＩＴＹ１￥ＤＯＭＡＩＮ ＵＳＥＲＳグループのメンバーであるので、ルール使用属性と発呼者ポリシー属性の間にマッチはない。したがって、発呼者は、呼を行うことを防止される。
図８は、経路指定ルールを使用した呼処理および経路指定の方法を例示する。８００で、経路指定ルールのテーブルがサーバー上に格納される。上に示したように、ルールはディレクトリサービススキーマにおいて、１つまたは複数のクラスの１つまたは複数のインスタンスとして定義される。８０２で、呼が宛先電話番号を有して受信される。８０４で、呼宛先番号がルールのテーブルに対して処理されて、マッチする宛先番号を有するルールが発見される（番号の範囲またはパターンにおいて発見されるように）。８０６で、マッチする宛先番号を有する、マッチするルールが処理される。８０８で、マッチするルールに基づいて、呼が、対応するゲートウェイ（または、呼ネットワークインターフェイス機器）へ経路指定される。
ここで図９を参照すると、ユーザー使用ポリシーと組み合わせて経路指定ルールを使用した、呼処理および経路指定の代替方法が例示される。９００で、経路指定ルールがディレクトリサービスサーバー上の経路指定テーブルに格納される。このルールは、クラス、および、それらのクラスのインスタンスから構成される。９０２で、呼が、関連付けられた呼宛先番号を有して、処理のために受信される。９０４で、呼を、マッチする宛先番号のための経路指定テーブルルールに対して処理することによって、呼処理が開始される。マッチが発見されない場合、呼は失敗する。９０６で、次いで、マッチが、そのユーザー（または、そのユーザーがメンバーである呼グループ）に関連付けられた１つまたは複数のポリシーに対して処理される。９０８で、グループの１つまたは複数のポリシーによって定義された使用許可が、マッチした電話経路指定ルールの使用属性と比較される。９１０で、結果として生じる経路（または、複数の経路）が選択かつ処理されて、呼が、ルールの属性とポリシーの間のマッチに基づいて、対応する呼ゲートウェイシステムへ経路指定される。
複数のルールおよびポリシーマッチが発生し、システムが、どの経路を介して呼を経路指定するかについての決定を行う結果となる可能性があることは、本アーキテクチャの企図内である。例えば、電話番号マッチおよび使用属性マッチがある１つの実装では、選択された経路を、選択された経路がアルファベット順で最初の経路である、アルファベット順の経路名に従うようにすることができる。この問題の別の解決法を、マッチングプロセスにおいて利用されているデータを解析し、より具体的であるデータに基づいて経路を選択することとすることができる。これを、例えば、解析および決定処理のために所望の情報を構文解析する、表現パーサーを使用して実施することができる。
複数のゲートウェイを経路のために採用することができることも理解されたい。よって、ゲートウェイの選択を、例えば、ラウンドロビンなど、いかなる数の方法にも従うようにすることができる。別の複数のゲートウェイ選択実装では、重み付け値をゲートウェイに適用することができる。例えば、あるゲートウェイは１０個の呼をサポートすることができるが、より大きい容量のものは４０個の呼を同時にサポートする。よって、より大きい容量のゲートウェイには４／５の重み付けが与えられ、より多くの呼が、より小さい容量のゲートウェイ（１／５で重み付けされる）よりも大きいゲートウェイへ経路指定されるようになる。
図１０は、経路指定ルールにおいて呼宛先番号範囲および／またはパターンを採用する方法を例示する。１０００で、経路指定ルールを、１つまたは複数の使用属性に基づいて、クラスの１つまたは複数のインスタンスとして生成するためのディレクトリサービススキーマを使用して、電話ルール生成プロセスが開始される。１００２で、使用属性が、様々なタイプの使用について定義かつ記述される。１００４で、ユーザーカテゴリが定義され、企業ユーザーがユーザーカテゴリに割り当てられる。１００６で、ユーザーポリシーが、１つまたは複数の使用属性を使用して生成され、各ユーザーカテゴリ（ユーザーおよび／またはユーザーのグループ）に割り当てられる。１００８で、電話番号の範囲および／またはパターンが、ルールに含められる。１０１０で、１つまたは複数のゲートウェイが電話ルールに割り当てられる。次いで１０１２で、ルール生成が完了し、ルールが経路指定テーブルに格納される。
図１１は、呼経路指定のためのポリシーを利用する方法を例示する。１１００で、経路指定ルールを、１つまたは複数の使用属性に基づいて、クラスの１つまたは複数のインスタンスとして生成するためのディレクトリサービススキーマを使用する、電話ルール生成プロセスが開始される。１１０２で、使用属性が、様々なタイプの使用について定義かつ記述される。１１０４で、ユーザーカテゴリが定義され、ユーザーがユーザーカテゴリに割り当てられる。１１０６で、ユーザーポリシーが、１つまたは複数の使用属性を使用して生成され、１つまたは複数のポリシーが各ユーザーカテゴリ（ユーザーおよび／またはユーザーのグループ）に割り当てられる。１１０８で、ユーザーポリシー生成プロセスが完了され、経路名、経路記述、使用属性によって定義された１つまたは複数の使用、１つまたは複数のゲートウェイ、および、１つまたは複数の対象（または宛先）電話番号を含む、経路指定ルールが生成される。１１１０で、電話番号が受信され、経路指定ルールに対して処理されて、１つまたは複数のマッチするルールが発見される。次いで、マッチするルールが、発呼者がメンバーであるユーザーカテゴリのポリシーに対して処理される。１１１２で、使用属性におけるマッチが得られる場合、流れは１１１４へ行き、１１１４で、呼がこのルールのゲートウェイに接続される。マッチする使用属性がない場合、流れは１１１２から１１１６へ行き、１１１６で、呼が失敗となり、流れが戻って次の電話番号を処理する。
図１２は、ディレクトリサービス呼管理システムにおけるクラス変更を更新する方法を例示する。１２００で、分散ディレクトリ電話システム（またはサーバー）が、電話呼経路指定のために受信かつ実装される。１２０２で、使用データ（属性）が生成され、ユーザーカテゴリに関連付けられる。１２０４で、ポリシーが生成され、各ユーザーカテゴリに割り当てられる。１２０６で、経路および経路指定ルールが、電話番号パターン／範囲、および、１つまたは複数の使用属性に基づいて、クラスの１つまたは複数のインスタンスとして生成される。１２０８で、ＤＮが採用されて、レガシー呼システムとインターフェイスする呼管理システムのクラスに渡って変化が自動的に維持される。
例えば、異なる地理的ロケーションに渡って分散した大会社は、類似の設計および能力、または、異なる設計、モデルなどさえも有する、その会社のための呼を処理するいくつかの呼管理システムを実装している可能性がある。各ロケーションで、ルールを（クラスのインスタンスとして）採用する、本明細書に記載したディレクトリサービスを実装して、ローカル呼管理システムとインターフェイスすることができる。よって、ディレクトリサービスを、多数の企業ロケーションに渡って分散させることができ、これらの多数の企業ロケーションは互いに通信し合い、最新のルール、使用許可、ポリシー、テーブルなどを維持する。したがって、１つのシステムエンティティにおける変化（例えば、故障したゲートウェイ）を、新しいルールとして表し、ＤＮを使用することによって、すべてのサービスロケーションに伝播することができる。
より拡張的な実装では、開示された分散ディレクトリサービスおよびルールを、国際的な設定において実装することができる。各国が異なる規制要件を有する可能性があり、これらの規制が変更されることを考えると、頻繁に規制に対応させることは、新しい規制が有効になるとき、ソフトウェアへの更新を必要とする可能性の高い、複雑な経路指定ロジックの結果となり得る。MSFT_SIPPhoneRouteUsageDataクラスによって表された使用テーブルを使用することによって、例えば、アドミニストレータは、新しい使用を作成し既存の経路を新しい使用に更新することによって、これらの変更を順守することができる。
図１３は、１つまたは複数の機能の自動化を容易にするマシン学習および推論コンポーネント（ＭＬＲ）１３０２を採用する、代替システム１３００を例示する。開示されたアーキテクチャは、（例えば、選択に関連して）その様々な態様を実行するための様々なＭＬＲベースのスキームを採用することができる。例えば、複数のルールのうち、どのルールがそのように選択するかを決定するためのプロセスを、自動分類子システムおよびプロセスを介して容易にすることができる。また、ディレクトリサービス１０４がいくつかのロケーションに分散され、各ロケーションが、経路指定ルール１１０の関連付けられたテーブルを有することにより、分類子を採用して、例えば、どのロケーションが他のロケーションの前に再生成または更新のために選択されるようになるかを決定することができる。
分類子は、入力属性ベクトル、ｘ＝（ｘ１，ｘ２，ｘ３，ｘ４，ｘｎ）を、クラスラベルであるクラス（ｘ）にマップする関数である。分類子はまた、入力がクラスに属する、すなわち、ｆ（ｘ）＝信頼性（クラス（ｘ））である、信頼性を出力することもできる。このような分類は、確率論的および／または他の統計的解析（例えば、１人または複数の人々にとっての期待値を最大にするために、解析ユーティリティおよびコストの考慮に入るもの）を採用して、自動的に行われることをユーザーが望むアクションを予知あるいは推測することができる。
本明細書で使用されるように、「推測すること」および「推測」という語は一般に、システム、環境、および／またはユーザーの状態を、イベントおよび／またはデータを介して取り込まれるような観察のセットから、推論あるいは推測するプロセスを指す。推測は、特定のコンテキストまたはアクションを識別するために採用されることが可能であり、あるいは、例えば、状態に渡る確率分布を生成することができる。推測を確率論的に、すなわち、データおよびイベントの考察に基づいた、関心のある状態に渡る確率分布の計算にすることができる。推測はまた、より高レベルのイベントをイベントおよび／またはデータのセットから構成するために採用される技術を指すこともある。このような推測は、観察されたイベントおよび／または格納されたイベントデータのセットから、これらのイベントが時間的に近接近して相関するかどうかに関わらず、かつ、イベントおよびデータが１つのイベントおよびデータソースから来るか、いくつかのイベントおよびデータソースから来るかに関わらず、新しいイベントまたはアクションを構成する結果となる。
サポートベクトルマシン（ＳＶＭ）は、採用することができる分類子の一例である。ＳＶＭは、トリガー入力イベントを非トリガーイベントから最適な方法で分ける、可能な入力の空間における超曲面を発見することによって、動作する。直観的には、これは分類に、トレーニングデータに近いが同一ではないテストデータを補正させる。他の有向および無向モデル分類手法には、例えば、様々な形式の統計的回帰、ナイーブベイズ、ベイジアンネットワーク、デシジョンツリー、ニューラルネットワーク、ファジー理論モデルが含まれ、異なるパターンの独立性を表す他の統計的分類モデルを採用することができる。本明細書で使用される分類はまた、ランクおよび／または優先順位を割り当てるために使用される方法をも含む。
本明細書から容易に理解されるように、本アーキテクチャは、明示的にトレーニングされ（例えば、汎用トレーニングデータを介して）、ならびに、暗黙的にトレーニングされる（例えば、ユーザービヘイビアの観察、外部からの情報の受信を介して）、分類子を採用することができる。例えば、ＳＶＭは、分類子コンストラクタおよび機能選択モジュール内で学習またはトレーニングフェーズを介して構成される。よって、所定の基準に従って、いくつかの関数を自動的に学習し、行うために、分類子を採用することができる。
この実装では、ＭＬＲコンポーネント１３０２は、サービスコンポーネント１０２とインターフェイスして、アドミニストレータおよび／または他のハードウェア／ソフトウェアシステムによるディレクトリサービスアクティビティを監視することができる。例えば、経路指定ルール１１０、ルールテーブルアクティビティ、およびポリシー１１６の処理だけでなく、スキーマアクティビティをも監視、学習、かつ推論することができる。
ＭＬＲコンポーネント１３０２はまた、経路指定コンポーネント１０６とインターフェイスして、例えば、概して、ＡＰＩ３２４の使用、ルールテーブルへの変更および更新、経路指定ルール（インスタンスおよびクラス）との対話、ディレクトリサービスのアクティビティに関係付けられた経路指定プロセス、および、経路指定コンポーネント１０６の全体的なアクティビティおよびプロセスを監視かつ解析することもできる。
加えて、ＭＬＲコンポーネント１３０２は、サーバー通信フレームワーク１１８とインターフェイスして、フレームワークアクティビティおよびプロセス（例えば、ホップ、帯域幅、ネットワークステータス、他のＤＳサーバーステータス、．．．）、ならびにゲートウェイシステムを監視、学習、かつ推論することができる。
図１４は、ゲートウェイ通信を管理するための仲介ゲートウェイ１４０２を採用する、代替システム１４００を例示する。仲介ゲートウェイは、例えば、ＳＩＰ正規化、セキュアな制御およびデータチャネル、改良されたコーデック、および付加価値コンポーネントを提供することができる抽象である。仲介ゲートウェイ１４０２の存在は、カスタマーが、開示された分散サービスアーキテクチャにアップグレードしながら、それらの既存のハードウェア投資を活用することを可能にすることができる。仲介ゲートウェイ１４０２は、あるタイプのゲートウェイ（例えば、承認されたゲートウェイ）を介した経路指定を可能にするが、その動作が信頼できない可能性のある別のタイプのゲートウェイ（例えば、レガシーゲートウェイ）を介した経路指定を拒否することによって、呼経路指定の制御を容易にする。したがって、スキーマ１１３を採用して、採用されたゲートウェイのタイプに基づいて、経路指定管理のためのルールを生成することができる。加えて、ＭＬＲコンポーネント１３０２を採用して、さらに、仲介ゲートウェイアクティビティを監視し、ならびに、仲介ゲートウェイアクティビティを学習かつ推論することができる。
図１５は、開示された呼経路指定アーキテクチャによる、分散ディレクトリサービスおよびルールクラス／属性定義のための１つの例示的スキーマを例示する。図示のように、使用、経路、ポリシー、および仲介ゲートウェイという、４つのオブジェクトが提供される。使用オブジェクト（msRTCSIP-RouteUsagesと示される）は、クラスmsRTPSIP-RouteUsage、ならびに、属性定義msRTPSIP-RouteUsageAttributeおよびmsRTPSIP-Descriptionに関連付けられる。
経路オブジェクト（msRTCSIP-PhoneRoutesと示される）は、クラスmsRTPSIP-PhoneRoute、ならびに、定義msRTPSIP-PhoneRouteName、msRTPSIP-TargetPhoneNumbers、msRTPSIP-Gateways、msRTPSIP-PhoneUsage、msRTPSIP-Description、およびmsRTPSIP-PhoneRouteDataに関連付けられる。
ポリシーオブジェクト（msRTCSIP-Policiesと示される）は、クラスmsRTPSIP-GlobalUserPolicy、ならびに、定義msRTPSIP-PolicyType、msRTPSIP-PolicyContent、およびmsRTPSIP-PolicyDataに関連付けられる。
ゲートウェイオブジェクト（msRTCSIP-TrustedMediationGatewaysと示される）は、クラスmsRTPSIP-TrustedMediationGateway、ならびに、定義msRTPSIP-TrustedMediationGatewayFQDN、msRTPSIP-TrustedMediationGatewayType、msRTPSIP-TrustedServerVersion、およびmsRTPSIP-TrustedMediationGatewayDataに関連付けられる。
１つの実装では、スキーマが固定され、ローカル企業アドミニストレータがいかなる方法でもスキーマを変更することができないようにする。別の実装では、スキーマをベンダーによって、購入またはサブスクライブする会社のために、その会社によるアクセスおよびアドミニストレーションを制限して、カスタマイズすることができる。さらにもう１つの実装では、購入またはサブスクライブする会社のアドミニストレータに、それら自体のスキーマを作成するため、かつ／または、ベンダーによって提供されたデフォルトスキーマを修正するために、完全アクセスが与えられる。
図１６〜２１は、開示されたアーキテクチャによる、ディレクトリサービスと対話し、呼経路指定を管理するための、ユーザーインターフェイス（ＵＩ）の一連のスクリーンショットを示す。情報をユーザーに表示するある方法が、スクリーンショットなど、ある図に関して図示かつ説明されるが、様々な他の代替物を採用することができることは、当業者には理解されよう。「スクリーン」、「スクリーンショット」、「ウィンドウ」、「サブウィンドウ」および「ページ」という語は、本明細書で全体的に入れ替え可能に使用される。ページまたはスクリーンは、表示記述として、グラフィカルユーザーインターフェイスとして、あるいは、（例えば、パーソナルコンピュータ、ＰＤＡ、携帯電話、または他の適切なデバイスであるかに関わらず）情報をスクリーン上に示す他の方法によって、格納かつ／または送信され、ただし、ページ上に表示されるレイアウトおよび情報またはコンテンツは、メモリ、データベース、または別のストレージファシリティに格納される。
図１６は、アドミニストレータ（またはユーザー）対話に、開示された呼ディレクトリサービスの様々な機能を提供するための、例示的通信プログラムＵＩ１６００を例示する。例えば、アドミニストレータは、呼経路指定ルールを構成するためのフローティングメニュー１６０２を（例えば、ＵＩを介して提示された電話経路オブジェクト上での右クリック選択によって）エクスポーズすることによって、呼経路指定をプロビジョニングするためのウィザードにアクセスすることができる。Ａｄｄ選択を選択することによって、ウィザードが起動し、ようこそウィンドウ１６０４を提示する。ＵＩ１６００はまた、以前に入力されたエントリ１６０６の管理、ならびに、新しい電話経路指定エントリの作成をも可能にする。既存のエントリを管理するために、エントリ１６０６の１つについて別のフローティングメニュー１６０８を提示させることによって、構成ウィンドウ（図１９に図示）にアクセスすることができる。例えば、Ｚｕｒｉｃｈ ｄｉａｌｉｎｇエントリをハイライトし、右クリックすることによって、メニュー１６０８は、そのエントリを管理するための選択を提示する。エントリ１６０６は、使用可能なフィールド（例えば、名前、対象電話番号、ゲートウェイ、．．．）のいずれか１つによってソート可能である。図１９に関連する説明は、エントリ管理についてのさらなる詳細を提供する。
ここで図１７を見ると、ウィザードのようこそウィンドウ１６０４から、アドミニストレータがメディアゲートウェイを構成することを可能にする中間ウィザードウィンドウ１７００が開く。アドミニストレータは、ＦＱＤＮデータおよび関連付けられたポートを入力することによって、ゲートウェイへの発信接続を構成することができる。完全修飾ドメインネームは、ドメインネームシステム（ＤＮＳ）ツリー階層におけるノードの位置を指定する、曖昧でないドメインネームである。ＦＱＤＮを通常のドメインネームと区別するため、末尾のピリオドが追加される。ＦＱＤＮは、通常のドメインネームとは、その完全性によって異なる。
図１８は、プロビジョンウィザードの追加のプロビジョニングウィンドウを例示する。例えば、第２の中間ウィンドウ１８００は、図１６のウィンドウ１６００において選択されたゲートウェイへ経路指定するように、通信サーバーを構成することを容易にする。アドミニストレータは、電話番号範囲および／またはパターンの割り当てのためのゲートウェイ（例えば、Ｇａｔｅｗａｙ１）の選択を可能にする、トップの選択を行うことができる。割り当てを行った後、ウィザードは終了する。
別法として、アドミニストレータが新しい番号範囲を定義するために、下部選択を行う場合、第３の中間ウィザードウィンドウ１８０２が開く。Ａｄｄ機能を選択することによって、第４のウィンドウ１８０４が開いて、範囲データ、パターンデータ、および重み付けデータの直接アドミニストレータ入力を可能にする。
図１９は、エントリ（またはルール）のアドミニストレータ制御を容易にする一連のウィンドウを例示する。アドミニストレータがＤｅｌｅｔｅオプションをフローティングメニュー１６０８から選択するとき、アドミニストレータに削除機能を確認するようにプロンプトする、プロンプトウィンドウ１９００が開く。
アドミニストレータがメニュー１６０８のＰｒｏｐｅｒｔｉｅｓオプションを選択する場合、新しい経路指定エントリの作成用のタブ選択（例えば、Ｇｅｎｅｒａｌ、Ｐｈｏｎｅｓ、および、Ｇａｔｅｗａｙｓ）を可能にする、ウィンドウ１９０２が開く。Ｇｅｎｅｒａｌタブは、名前、記述および使用情報のエントリ用のフィールドを含む、入力および／または選択サブウィンドウ１９０４をエクスポーズする。アドミニストレータは、電話経路エントリを作成するとき、少なくとも１つまたは複数の属性を指定することができることに留意されたい。サブウィンドウ１９０４のＡｄｄボタンを選択することによって、アドミニストレータが電話経路エントリについて指定するために１つまたは複数の電話属性を選択することを可能にする、電話属性ウィンドウ１９０６が提示される。属性を、使用テーブルにおいて定義されたものにすることができる。
図２０は、図１９のウィンドウ１９０２のＰｈｏｎｅｓタブを選択するときに提示されるＵＩを例示する。Ｐｈｏｎｅｓタブは、電話経路のための対象電話番号の指定を容易にする、入力および／または選択サブウィンドウ２０００をエクスポーズする。サブウィンドウ２０００のＡｄｄボタンまたはＥｄｉｔボタンを選択することによって、Ａｄｄ／Ｅｄｉｔウィンドウ２００２が開き、アドミニストレータが、例えば、電話番号の範囲を定義する正規表現を入力することによって、対象電話番号を管理することを可能にする。
図２１は、図１９のウィンドウ１９０２のＧａｔｅｗａｙｓタブを選択するときに提示されるＵＩを例示する。Ｇａｔｅｗａｙｓタブは、電話経路のための対象電話番号の指定を容易にする、入力および／または選択サブウィンドウ２１００をエクスポーズする。アドミニストレータは、電話経路を作成するとき、１つまたは複数のゲートウェイを指定することができる。サブウィンドウ２１００のＡｄｄボタンまたはＥｄｉｔボタンを選択することによって、アドミニストレータが、例えば、ゲートウェイを管理することを可能にする、Ａｄｄ／Ｅｄｉｔウィンドウ２１０２が開く。ウィンドウ２１０２は、アドミニストレータがドロップダウンメニュー２１０４からゲートウェイＦＱＤＮデータを、およびポートデータを指定することを可能にする。ドロップダウンメニュー２１０４は、ディレクトリサービスからアクセスすることができる、信頼できる仲介ゲートウェイオブジェクトの、事前にポピュレートされたリストである。アドミニストレータがゲートウェイＦＱＤＮをドロップダウンメニュー２１０４から選択した後、ポートフィールドを、仲介サーバーにおいて作成された各インスタンスに属するリスニングポートのリストにより、事前にポピュレートすることができる。
カスタマー（またはベンダー）がそれら自身の目的またはアプリケーションのためにＵＩをカスタマイズすることを可能にすることによって、ＵＩにおいて柔軟性を提供することができることは、本アーキテクチャの企図内である。具体的には、ベンダーが、それら自身のダイアログボックス、表示ルールおよび使用ポリシーを開発かつ採用することを可能にすることができる。加えて、例えば、呼管理およびＵＩカスタマイゼーションのサポートにおいて、機能またはプロセスを自動化するために、スクリプトを書いて実行することができる（実行可能ファイルだけでなく）。さらに、ユーザーに、例えば、それら自身のロジックをポリシーの背後で採用する能力を提供することができる。ＤＬＬ（ダイナミックリンクライブラリ）を、呼管理のためのそれら自身の述語論理の実行のために、開発かつ採用することができる。
この応用例で使用されるように、「コンポーネント」および「システム」という語は、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアである、コンピュータ関連エンティティを指すように意図される。例えば、コンポーネントは、限定されないが、プロセッサ上で実行するプロセス、プロセッサ、ハードディスクドライブ、複数のストレージドライブ（光学および／または磁気ストレージメディアの）、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および／またはコンピュータである可能性がある。例示として、サーバー上で実行するアプリケーションおよびサーバーは共にコンポーネントである可能性がある。１つまたは複数のコンポーネントがプロセスおよび／または実行のスレッド内に存在することができ、コンポーネントは１つのコンピュータ上でローカライズされるか、かつ／または、２つ以上のコンピュータの間で分散される可能性がある。ネットワーク（例えば、セルラー、ＰＳＴＮ）に渡る呼経路指定を容易にする呼ネットワークおよびネットワークエンティティだけでなく、サーバー、サービス、および、電話管理システム（例えば、ＰＢＸ、ＶｏＩＰ）およびネットワークに関しても、コンポーネントは、オブジェクトを格納し、電話呼および呼関連情報を受信、処理、かつ経路指定するために提供された、ソフトウェアおよび／またはハードウェアである可能性がある。
ここで図２２を参照すると、開示されたアーキテクチャによるディレクトリサービスおよび呼経路指定ルールを実行するように動作可能なコンピュータ（またはサーバー）のブロック図が例示される。その様々な態様のための追加の状況を提供するために、図２２および以下の考察は、本イノベーションの様々な態様を実装することができる、適切なコンピューティング環境２２００の簡単な概要を提供するように意図される。上記の説明は、全体的に、１つまたは複数のコンピュータ上で実行する場合のあるコンピュータ実行可能命令との関連におけるものであるが、本イノベーションをまた、他のプログラムモジュールと組み合わせて、かつ／または、ハードウェアおよびソフトウェアの組み合わせとして実装することもできることは、当業者には理解されよう。
一般に、プログラムモジュールには、特定のタスクを行い、あるいは、特定の抽象データ型を実装する、ルーチン、プログラム、コンポーネント、データ構造などが含まれる。また、本発明の方法を他のコンピュータシステム構成により実施することができ、これらの構成には、シングルプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびに、パーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースまたはプログラマブルなコンシューマエレクトロニクスなどが含まれ、その各々を１つまたは複数の関連付けられたデバイスと動作可能に結合することができることは、当業者には理解されよう。
本イノベーションの例示の態様はまた、分散コンピューティング環境で実施されてもよく、この環境では、あるタスクが、通信ネットワークを通じてリンクされるリモート処理デバイスによって行われる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのメモリストレージデバイス内に位置することができる。
コンピュータは典型的には、様々なコンピュータ可読メディアを含む。コンピュータ可読メディアは、コンピュータによってアクセスすることができるいかなる使用可能なメディアである可能性もあり、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアが共に含まれる。例として、限定ではなく、コンピュータ可読メディアは、コンピュータストレージメディアおよび通信メディアを備えることができる。コンピュータストレージメディアには、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなど、情報のストレージのためのいずれかの方法または技術において実装された、揮発性および不揮発性、リムーバブルおよび非リムーバブルメディアが共に含まれる。コンピュータストレージメディアには、限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または、所望の情報を格納するために使用することができ、コンピュータによってアクセスすることができる他のいかなるメディアもが含まれる。
図２２を再度参照すると、様々な態様を実装するための例示的環境２２００は、コンピュータ２２０２を含み、コンピュータ２２０２は、処理ユニット２２０４、システムメモリ２２０６およびシステムバス２２０８を含む。システムバス２２０８は、限定されないが、システムメモリ２２０６を含むシステムコンポーネントを、処理ユニット２２０４に結合する。処理ユニット２２０４を、様々な市販のプロセッサのいずれかにすることができる。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャもまた、処理ユニット２２０４として採用してもよい。
システムバス２２０８を、様々な市販のバスアーキテクチャのいずれかを使用する、メモリバス（メモリコントローラの有無に関わらず）、周辺バスおよびローカルバスにさらに相互接続する場合のある、いくつかのタイプのバス構造のいずれかにすることができる。システムメモリ２２０６は、読み取りメモリ（ＲＯＭ）２２１０およびランダムアクセスメモリ（ＲＡＭ）２２１２を含む。基本入出力システム（ＢＩＯＳ）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなど、不揮発性メモリ２２１０に格納され、そのＢＩＯＳは、起動中など、コンピュータ２２０２内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含む。ＲＡＭ２２１２はまた、データをキャッシュするための、静的ＲＡＭなど、高速ＲＡＭを含むこともできる。
コンピュータ２２０２はさらに、内部ハードディスクドライブ（ＨＤＤ）２２１４（例えば、ＥＩＤＥ、ＳＡＴＡ）を含み、その内部ハードディスクドライブ２２１４はまた、適切な筐体（図示せず）、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）２２１６（例えば、リムーバブルディスケット２２１８から読み取るか、あるいはリムーバブルディスケット２２１８へ書き込むため）、および光ディスクドライブ２２２０（例えば、ＣＤ−ＲＯＭディスク２２２２を読み取るか、あるいは、ＤＶＤなど、他の大容量光メディアから読み取るか、あるいは他の大容量光メディアへ書き込むため）における外部使用のために構成されてもよい。ハードディスクドライブ２２１４、磁気ディスクドライブ２２１６、および光ディスクドライブ２２２０を、それぞれ、ハードディスクドライブインターフェイス２２２４、磁気ディスクドライブインターフェイス２２２６、および光ドライブインターフェイス２２２８によって、システムバス２２０８に接続することができる。外部ドライブ実装用のインターフェイス２２２４は、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ １３９４インターフェイス技術のうち、少なくとも１つまたは両方を含む。他の外部ドライブ接続技術は、本イノベーションの企図内である。
ドライブおよびそれらの関連付けられたコンピュータ可読メディアは、データ、データ構造、コンピュータ実行可能命令などの不揮発性ストレージを提供する。コンピュータ２２０２では、ドライブおよびメディアは、適切なデジタルフォーマットにおけるいかなるデータのストレージにも対応する。上記のコンピュータ可読メディアの説明は、ＨＤＤ、リムーバブル磁気ディスケット、および、ＣＤまたはＤＶＤなど、リムーバブル光メディアを指すが、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなど、コンピュータによって可読である他のタイプのメディアもまた例示的オペレーティング環境内で使用してもよいこと、および、さらに、このようないかなるメディアも、開示されたイノベーションの方法を行うためのコンピュータ実行可能命令を含んでよいことは、当業者には理解されたい。
いくつかのプログラムモジュールをドライブおよびＲＡＭ２２１２に格納することができ、これらのプログラムモジュールには、オペレーティングシステム２２３０、１つまたは複数のアプリケーションプログラム２２３２、他のプログラムモジュール２２３４、およびプログラムデータ２２３６が含まれる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータの全部または一部をまた、ＲＡＭ２２１２にキャッシュすることもできる。本イノベーションを、様々な市販のオペレーティングシステム、または、オペレーティングシステムの組み合わせにより、実装することができることを理解されたい。
ユーザーはコマンドおよび情報をコンピュータ２２０２へ、１つまたは複数のワイヤード／ワイヤレス入力デバイス、例えば、キーボード２２３８、および、マウス２２４０など、ポインティングデバイスを通じて入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、赤外線リモコン、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどが含まれる場合がある。これらおよび他の入力デバイスはしばしば処理ユニット２２０４へ、システムバス２２０８に結合される入力デバイスインターフェイス２２４２を通じて接続されるが、パラレルポート、ＩＥＥＥ １３９４シリアルポート、ゲームポート、ＵＳＢポート、赤外線インターフェイスなど、他のインターフェイスによって接続することができる。
モニタ２２４４または他のタイプの表示デバイスもまたシステムバス２２０８へ、ビデオアダプタ２２４６など、インターフェイスを介して接続される。モニタ２２４４に加えて、コンピュータは典型的には、スピーカ、プリンタなど、他の周辺出力デバイス（図示せず）を含む。
コンピュータ２２０２はネットワーク環境において、リモートコンピュータ２２４８など、１つまたは複数のリモートコンピュータへのワイヤードおよび／またはワイヤレス通信を介した論理接続を使用して動作してもよい。リモートコンピュータ２２４８は、ワークステーション、サーバーコンピュータ、ルーター、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースのエンターテインメント機器、ピアデバイスまたは他の共通ネットワークノードである可能性があり、典型的には、コンピュータ２２０２に関連して上述した要素の多数またはすべてを含むが、簡潔にするため、メモリ／ストレージデバイス２２５０のみが例示される。図示の論理接続には、ローカルエリアネットワーク（ＬＡＮ）２２５２、および／または、より大規模なネットワーク、例えば、広域ネットワーク（ＷＡＮ）２２５４へのワイヤード／ワイヤレスコネクティビティが含まれる。このようなＬＡＮおよびＷＡＮネットワーキング環境は、オフィスおよび会社において一般的であり、そのすべてがグローバル通信ネットワーク、例えば、インターネットに接続する場合がある、イントラネットなど、エンタープライズワイドなコンピュータネットワークを容易にする。
ＬＡＮネットワーキング環境において使用されるとき、コンピュータ２２０２はローカルネットワーク２２５２へ、ワイヤードおよび／またはワイヤレス通信ネットワークインターフェイスまたはアダプタ２２５６を通じて接続される。アダプタ２２５６は、ＬＡＮ２２５２へのワイヤードまたはワイヤレス通信を容易にする場合があり、ＬＡＮ２２５２もまた、ワイヤレスアダプタ２２５６と通信するためにその上に配置されたワイヤレスアクセスポイントを含む場合がある。
ＷＡＮネットワーキング環境において使用されるとき、コンピュータ２２０２はモデム２２５８を含むことができ、あるいは、ＷＡＮ２２５４上の通信サーバーに接続され、あるいは、インターネット経由など、ＷＡＮ２２５４を介して通信を確立するための他の手段を有する。モデム２２５８は内部または外部であり、かつ、ワイヤードまたはワイヤレスデバイスである可能性があり、システムバス２２０８へ、シリアルポートインターフェイス２２４２を介して接続される。ネットワーク環境では、コンピュータ２２０２に関連して示したプログラムモジュールまたはその一部を、リモートメモリ／ストレージデバイス２２５０に格納することができる。図示のネットワーク接続は例示的であり、複数のコンピュータの間で通信リンクを確立する他の手段を使用することができることは理解されよう。
コンピュータ２２０２は、ワイヤレス通信において動作可能に配置されたいかなるワイヤレスデバイスまたはエンティティ、例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、ワイヤレスに検出可能なタグに関連付けられた機器またはロケーション（例えば、キオスク、新聞売店、手洗所）のいずれかの部分、および電話とも、通信するように動作可能である。これには、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）ワイヤレス技術が含まれる。よって、通信を、従来のネットワーク、または、単に少なくとも２つのデバイスの間のアドホック通信と同様に、事前定義された構造にすることができる。
Ｗｉ−Ｆｉ、すなわち、Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙは、ワイヤなしに、家庭のソファー、ホテルの部屋のベッド、または仕事中の会議室から、インターネットへの接続を可能にする。Ｗｉ−Ｆｉは、このようなデバイス、例えば、コンピュータがデータを屋内および屋外で、基地局の範囲内のいかなる場所でも送受信することを可能にする、携帯電話において使用されるものに類似のワイヤレス技術である。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ ８０２．１１ｘ（ａ、ｂ、ｇなど）と呼ばれる無線技術を使用して、セキュアで、信頼性のある、高速なワイヤレスコネクティビティを提供する。Ｗｉ−Ｆｉネットワークを使用して、複数のコンピュータを互いに、インターネットへ、かつワイヤードネットワーク（ＩＥＥＥ ８０２．３またはイーサネット（登録商標）を使用する）へ、接続することができる。
ここで図２３を参照すると、開示されたアーキテクチャによる呼管理のためのディレクトリサービスをサポートする、例示的コンピューティング環境２３００の概略ブロック図が例示される。システム２３００は、１つまたは複数のクライアント２３０２を含む。クライアント２３０２を、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）にすることができる。クライアント２３０２は、例えば、本イノベーションを採用することによって、クッキーおよび／または関連付けられたコンテキスト情報を収容することができる。
システム２３００はまた、１つまたは複数のサーバー２３０４をも含む。サーバー２３０４もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）にすることができる。サーバー２３０４は、例えば、アーキテクチャを採用することによって、変換を行うためのスレッドを収容することができる。クライアント２３０２とサーバー２３０４の間の１つの可能な通信を、２つ以上のコンピュータプロセスの間で送信されるように適合されたデータパケットの形式にすることができる。データパケットは、例えば、クッキーおよび／または関連付けられたコンテキスト情報を含んでもよい。システム２３００は、クライアント２３０２とサーバー２３０４の間の通信を容易にするために採用することができる、通信フレームワーク２３０６（例えば、インターネットなど、グローバル通信ネットワーク）を含む。
通信を、ワイヤード（光ファイバを含む）および／またはワイヤレス技術を介して、容易にすることができる。クライアント２３０２は、クライアント２３０２にとってローカルな情報（例えば、クッキーおよび／または関連付けられたコンテキスト情報）を格納するために採用することができる、１つまたは複数のクライアントデータストア２３０８に動作可能に接続される。同様に、サーバー２３０４は、サーバー２３０４にとってローカルな情報を格納するために採用することができる、１つまたは複数のサーバーデータストア２３１０に動作可能に接続される。
上述されたものには、開示されたイノベーションの実施例が含まれる。言うまでもなく、コンポーネントおよび／または方法のあらゆる考えられる組み合わせを説明することは可能ではないが、多数のさらなる組み合わせおよび置換が可能であることは、当業者には理解されよう。したがって、本イノベーションは、付属の特許請求の範囲の精神および範囲内に入るすべてのこのような変更、修正および変形形態を包含するように意図される。さらに、「含む」という語が詳細な説明または特許請求の範囲において使用される範囲で、このような語は、「備える」という語が、特許請求の範囲内の前後を接続させる語として採用されるときに解釈される際の「備える」と同様に、包含的であるように意図される。

Claims (18)

  1. 呼管理を行うための、コンピュータに実装されたシステムであって、
    ディレクトリサービススキーマ及び前記ディレクトリサービススキーマによって定義された１又は複数の使用属性のポリシーを生成するためのスキーマコンポーネントと、
    前記ディレクトリサービススキーマによってクラスのインスタンスとして定義された経路指定ルールに従って、発呼者の宛先電話番号を有する電話呼を経路指定する呼経路指定コンポーネントであって、前記経路指定ルールは、前記宛先電話番号の範囲および／またはパターンと、ポリシー処理のための使用属性とを含み、前記発呼者の宛先電話番号にマッチする前記経路指定ルールが発見され、当該マッチした経路指定ルールの使用属性と前記発呼者がメンバーであるグループに割り当てられたポリシーの使用属性とを比較し、当該比較の結果、前記マッチした経路指定ルールの使用属性と前記ポリシーの使用属性とがマッチしたとき、前記マッチした経路指定ルールに基づいて前記電話呼が経路指定される、呼経路指定コンポーネントと
    を備えることを特徴とするシステム。
  2. 前記クラスの前記インスタンスは、前記経路指定ルールをオブジェクト指向クラスとして表すことを特徴とする請求項１に記載のシステム。
  3. 前記ディレクトリサービススキーマによって定義された前記経路指定ルールは、最小コスト経路指定ルールであることを特徴とする請求項１に記載のシステム。
  4. 前記ディレクトリサービススキーマは、前記経路指定ルールに含まれた電話番号の範囲またはパターンに基づいた、前記経路指定ルールのテーブルの検索を行うために使用されることを特徴とする請求項１に記載のシステム。
  5. 前記ディレクトリサービススキーマは、文字列マッチに基づいた、前記経路指定ルールのマッチングを行うために使用されることを特徴とする請求項１に記載のシステム。
  6. 前記ディレクトリサービススキーマは、経路使用、呼経路、ポリシー、および仲介ゲートウェイのうち、少なくとも１つを定義することを特徴とする請求項１に記載のシステム。
  7. 呼管理に関係付けられたディレクトリサービス機能性をエクスポーズする、ユーザーインターフェイスをさらに備えることを特徴とする請求項１に記載のシステム。
  8. 確率論的および／または統計的ベースの解析を採用して、自動的に行われることをユーザーが望むアクションを予知あるいは推測する、マシン学習および推論コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
  9. それを介して前記呼が経路指定されるようになる経路を制御するための仲介コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
  10. 呼を管理する、コンピュータに実装された方法であって、
    ディレクトリサービススキーマ及び前記ディレクトリサービススキーマによって定義された１又は複数の使用属性のポリシーを生成するステップと、
    前記ディレクトリサービススキーマによってクラスのインスタンスとして定義された１つまたは複数の経路指定ルールを経路指定テーブルに格納するステップであって、前記１つまたは複数の経路指定ルールは、宛先電話番号の範囲および／またはパターン、ポリシー処理のための使用属性、および、ゲートウェイアドレスを含む、ステップと、
    発呼者の宛先電話番号を有する呼を受信するステップと、
    前記発呼者の宛先電話番号にマッチする前記経路指定ルールを発見するステップと、
    当該マッチした経路指定ルールの使用属性と前記発呼者がメンバーであるグループに割り当てられたポリシーの使用属性とを比較するステップと、
    当該比較の結果、前記マッチした経路指定ルールの使用属性と前記ポリシーの使用属性とがマッチしたとき、前記マッチした経路指定ルールに基づいて、呼ネットワークを介して、前記呼を経路指定するステップと
    を備えることを特徴とする方法。
  11. 前記マッチした経路指定ルールの使用属性が前記ポリシーの使用属性にマッチするとき、前記呼を接続するステップと、
    前記マッチした経路指定ルールの前記使用属性が前記ポリシーの使用属性にマッチしないとき、前記呼を失敗とするステップと
    をさらに備えることを特徴とする請求項１０に記載の方法。
  12. 前記１つまたは複数の経路指定ルールにおける変化に基づいて、前記１つまたは複数の経路指定ルールを第１のディレクトリサービスコンポーネントから第２のディレクトリサービスコンポーネントへ伝播するステップをさらに備えることを特徴とする請求項１０に記載の方法。
  13. ポリシーデータを、前記ディレクトリサービススキーマにおいて定義された１つまたは複数の使用属性として表すステップをさらに備えることを特徴とする請求項１０に記載の方法。
  14. 前記経路指定ルールおよび使用データを、前記ディレクトリサービススキーマにおいて、クラス、および、クラスのインスタンスとして定義するステップをさらに備えることを特徴とする請求項１３に記載の方法。
  15. 前記ディレクトリサービススキーマにおいて定義された前記クラスに渡って、リンクの完全性を自動的に維持するために、識別名を利用するステップをさらに備えることを特徴とする請求項１０に記載の方法。
  16. 前記１つまたは複数の経路指定ルールのカスタマイゼーションのための使用テーブルを提供するステップをさらに備えることを特徴とする請求項１０に記載の方法。
  17. 前記呼を、前記ディレクトリサービススキーマにおけるクラスによって指定されたゲートウェイへ経路指定するステップをさらに備えることを特徴とする請求項１０に記載の方法。
  18. 呼管理のためのコンピュータ実行可能システムであって、
    ディレクトリサービススキーマ及び前記ディレクトリサービススキーマによって定義された１又は複数の使用属性のポリシーを生成するためのコンピュータに実装された手段と、
    前記ディレクトリサービススキーマによってクラスのインスタンスとして定義された１つまたは複数の経路指定ルールを経路指定テーブルに格納するためのコンピュータに実装された手段であって、前記１つまたは複数の経路指定ルールは、宛先電話番号の範囲および／またはパターンと、ポリシー処理のための使用属性とを含む、手段と、
    発呼者の宛先電話番号を有する呼を受信するためのコンピュータに実装された手段と、
    前記発呼者の宛先電話番号にマッチする前記経路指定ルールを発見するためのコンピュータに実装された手段と、
    当該マッチした経路指定ルールの使用属性と前記発呼者がメンバーであるグループに割り当てられたポリシーの使用属性とを比較するためのコンピュータに実装された手段と、
    当該比較の結果、前記マッチした経路指定ルールの使用属性と前記ポリシーの使用属性とがマッチしたとき、前記マッチした経路指定ルールに基づいて、呼ネットワークを介して、前記呼を経路指定するためのコンピュータに実装された手段と
    を備えたことを特徴とするシステム。
JP2009520825A 2006-07-20 2007-07-18 ディレクトリサービススキーマを使用した電話呼経路指定の管理 Active JP5081912B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/489,831 US7831034B2 (en) 2006-07-20 2006-07-20 Management of telephone call routing using a directory services schema
US11/489,831 2006-07-20
PCT/US2007/016332 WO2008011082A2 (en) 2006-07-20 2007-07-18 Management of telephone call routing using a directory services schema

Publications (2)

Publication Number Publication Date
JP2009545208A JP2009545208A (ja) 2009-12-17
JP5081912B2 true JP5081912B2 (ja) 2012-11-28

Family

ID=38957360

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009520825A Active JP5081912B2 (ja) 2006-07-20 2007-07-18 ディレクトリサービススキーマを使用した電話呼経路指定の管理

Country Status (7)

Country Link
US (1) US7831034B2 (ja)
EP (1) EP2044760A4 (ja)
JP (1) JP5081912B2 (ja)
KR (1) KR20090032079A (ja)
CN (1) CN101491071B (ja)
IL (1) IL195967A0 (ja)
WO (1) WO2008011082A2 (ja)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7779091B2 (en) 2005-12-19 2010-08-17 Vmware, Inc. Method and system for providing virtualized application workspaces
US8935429B2 (en) 2006-12-19 2015-01-13 Vmware, Inc. Automatically determining which remote applications a user or group is entitled to access based on entitlement specifications and providing remote application access to the remote applications
US9549064B2 (en) * 2006-08-28 2017-01-17 Tp Lab Inc. System and method to customize a telephone
US7827132B2 (en) * 2006-09-14 2010-11-02 International Business Machines Corporation Peer based event conversion
US7889719B2 (en) * 2006-11-29 2011-02-15 Sap Ag Method and apparatus for communication channel switch
US8233492B1 (en) * 2007-03-27 2012-07-31 Cisco Technology, Inc. Voice gateway failure decoder
US8792118B2 (en) * 2007-09-26 2014-07-29 Ringcentral Inc. User interfaces and methods to provision electronic facsimiles
US20090086278A1 (en) * 2007-09-27 2009-04-02 Ringcentral, Inc. Electronic facsimile delivery systems and methods
US8838082B2 (en) * 2008-11-26 2014-09-16 Ringcentral, Inc. Centralized status server for call management of location-aware mobile devices
US8275110B2 (en) 2007-09-28 2012-09-25 Ringcentral, Inc. Active call filtering, screening and dispatching
US8600391B2 (en) * 2008-11-24 2013-12-03 Ringcentral, Inc. Call management for location-aware mobile devices
US8670545B2 (en) * 2007-09-28 2014-03-11 Ringcentral, Inc. Inbound call identification and management
US8537687B2 (en) * 2008-04-03 2013-09-17 Verizon Patent And Licensing Inc. Least cost routing
US8780383B2 (en) 2008-11-25 2014-07-15 Ringcentral, Inc. Authenticated facsimile transmission from mobile devices
US9824071B2 (en) * 2008-12-03 2017-11-21 Microsoft Technology Licensing, Llc Viewing messages and message attachments in different languages
DE102008063369B4 (de) * 2008-12-30 2016-12-15 Erco Gmbh Leuchte und Modulsystem für Leuchten
US8880725B2 (en) * 2010-05-26 2014-11-04 Microsoft Corporation Continuous replication for session initiation protocol based communication systems
JP5672385B2 (ja) * 2011-07-19 2015-02-18 日本電気株式会社 伝送システム、ルーティング制御装置および通信装置、並びにルーティング制御方法および通信方法
CN103179033A (zh) * 2011-12-23 2013-06-26 阳光凯讯(北京)科技有限公司 一种网间呼叫路由自动生成方法
JP6046893B2 (ja) * 2011-12-26 2016-12-21 任天堂株式会社 通信システム、通信端末、情報処理方法およびプログラム
CN104221322B (zh) * 2012-04-09 2018-08-28 英特尔公司 用于呼叫控制设备之间的动态电话分机同步的系统及方法
KR20160097313A (ko) * 2013-12-11 2016-08-17 콘티넨탈 테베스 아게 운트 코. 오하게 차량용 통신 시스템의 보안 게이트웨이를 동작시키기 위한 방법
CN106649402A (zh) * 2015-11-03 2017-05-10 阿里巴巴集团控股有限公司 一种规则发布系统、方法及装置
US9912783B2 (en) * 2016-01-29 2018-03-06 Veritas Technologies Llc Securing internal services in a distributed environment
CN108737522B (zh) * 2018-05-09 2021-07-20 中兴通讯股份有限公司 一种消息的处理方法、装置和系统
EP3928497A1 (en) * 2019-02-22 2021-12-29 Shubharanjan Dasgupta Multi-access edge computing based visibility network
US20210004832A1 (en) 2019-07-05 2021-01-07 Talkdesk, Inc. System and method for escalation using agent assist within a cloud-based contact center
US11328205B2 (en) 2019-08-23 2022-05-10 Talkdesk, Inc. Generating featureless service provider matches
US20210117882A1 (en) 2019-10-16 2021-04-22 Talkdesk, Inc Systems and methods for workforce management system deployment
US20210136220A1 (en) 2019-10-31 2021-05-06 Talkdesk, Inc. Monitoring and listening tools across omni-channel inputs in a graphically interactive voice response system
US11736615B2 (en) 2020-01-16 2023-08-22 Talkdesk, Inc. Method, apparatus, and computer-readable medium for managing concurrent communications in a networked call center
CN112291142B (zh) * 2020-10-26 2022-10-18 浙江百应科技有限公司 一种基于智能路由的云通讯方法、系统
US11611598B2 (en) * 2021-01-29 2023-03-21 Zoom Video Communications, Inc. Outbound call routing in an integrated voice and video platform
US11245790B1 (en) * 2021-01-29 2022-02-08 Zoom Video Communications, Inc. Inbound call routing in an integrated voice and video platform
US20220311862A1 (en) * 2021-03-25 2022-09-29 G.S. CONSULTING & RESEARCH CORRENET LTD (an Israeli limited liability company) Improved control of communication services management
US11677875B2 (en) 2021-07-02 2023-06-13 Talkdesk Inc. Method and apparatus for automated quality management of communication records
US11856140B2 (en) 2022-03-07 2023-12-26 Talkdesk, Inc. Predictive communications system
US11736616B1 (en) 2022-05-27 2023-08-22 Talkdesk, Inc. Method and apparatus for automatically taking action based on the content of call center communications
US11971908B2 (en) 2022-06-17 2024-04-30 Talkdesk, Inc. Method and apparatus for detecting anomalies in communication data
US11943391B1 (en) 2022-12-13 2024-03-26 Talkdesk, Inc. Method and apparatus for routing communications within a contact center

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5029196A (en) * 1988-07-11 1991-07-02 Dytel Corporation Automated call screening
CA2124379C (en) 1993-06-25 1998-10-27 Thomas F. La Porta Distributed processing architecture for control of broadband and narrowband communications networks
CN1147325A (zh) * 1994-02-28 1997-04-09 英国电讯有限公司 通信网络中的服务分配
CA2153281C (en) * 1994-07-08 2000-05-16 Ronald Schwartz Mediated access to an intelligent network
SE504050C2 (sv) * 1995-02-28 1996-10-28 Ericsson Telefon Ab L M Nätanordning och förfarande för att i ett kommunikationssystem koppla upp en förbindelse mellan två punkter genom utnyttjande av ett antal förbindelseobjekt
US6909708B1 (en) * 1996-11-18 2005-06-21 Mci Communications Corporation System, method and article of manufacture for a communication system architecture including video conferencing
US6000031A (en) * 1997-05-01 1999-12-07 At&T Corp Method and system for collecting and authenticating updates to a network-based directory service
EP1021757A1 (en) * 1997-07-25 2000-07-26 Starvox, Inc. Apparatus and method for integrated voice gateway
US6539077B1 (en) * 1998-06-05 2003-03-25 Netnumber.Com, Inc. Method and apparatus for correlating a unique identifier, such as a PSTN telephone number, to an internet address to enable communications over the internet
US7339934B2 (en) * 2001-04-06 2008-03-04 Level 3 Communications, Llc Alternate routing of voice communication in a packet-based network
JP4098977B2 (ja) * 2001-11-02 2008-06-11 ソフトバンク株式会社 構内通信システム、構内通信方法及び構内回線交換機
US7720794B2 (en) * 2003-08-05 2010-05-18 International Business Machines Corporation Identifying resource and data instances in management systems
US7697506B2 (en) * 2003-08-29 2010-04-13 Microsoft Corporation System and method for enhanced computer telephony integration and interaction
US7831679B2 (en) * 2003-10-15 2010-11-09 Microsoft Corporation Guiding sensing and preferences for context-sensitive services
US20060004729A1 (en) * 2004-06-30 2006-01-05 Reactivity, Inc. Accelerated schema-based validation
US7298833B2 (en) * 2004-09-29 2007-11-20 Avaya Integrated Cabinet Solutions, Inc. Wireless device to manage cross-network telecommunication services
US9137115B2 (en) * 2004-12-06 2015-09-15 Bmc Software, Inc. System and method for resource reconciliation in an enterprise management system
US20060217112A1 (en) * 2005-03-23 2006-09-28 Richard Mo System And Method For A Virtual Mobile Network
US20070192823A1 (en) * 2006-02-09 2007-08-16 Novell, Inc. Policy administration and provisioning

Also Published As

Publication number Publication date
IL195967A0 (en) 2009-09-01
EP2044760A2 (en) 2009-04-08
US7831034B2 (en) 2010-11-09
WO2008011082A3 (en) 2008-03-13
KR20090032079A (ko) 2009-03-31
CN101491071B (zh) 2013-03-27
WO2008011082A2 (en) 2008-01-24
CN101491071A (zh) 2009-07-22
JP2009545208A (ja) 2009-12-17
EP2044760A4 (en) 2012-10-24
US20080043976A1 (en) 2008-02-21

Similar Documents

Publication Publication Date Title
JP5081912B2 (ja) ディレクトリサービススキーマを使用した電話呼経路指定の管理
US6539425B1 (en) Policy-enabled communications networks
KR100467401B1 (ko) 통신망에 연관된 엔티티를 위한 엔티티 프로파일을생성하기 위해 구성 파라미터의 계층을 조직하고 결합하는방법 및 시스템
JP5221151B2 (ja) ネットワークにおけるプロセス構成
US8290954B2 (en) Resource name reconciliation in a configuration database
US20190220274A1 (en) Systems and methods for tracking configuration file changes
US5826239A (en) Distributed workflow resource management system and method
US7895176B2 (en) Entry group tags
TW202026901A (zh) 在網路路由環境中的獨立資料儲存空間
US20030154404A1 (en) Policy engine for modular generation of policy for a flat, per-device database
US20120203835A1 (en) Distributed routing table interface
US20080005623A1 (en) System and method for model-based user interface using transformation nodes
US7844912B2 (en) System and method using transformation nodes with enhancement layers
WO1995017063A1 (en) Object-oriented secured communications system
US8463852B2 (en) Groupware portlets for integrating a portal with groupware systems
JP2001344200A (ja) ユーザプロファイルデータ管理方法
WO1995017064A1 (en) Object-oriented distributed communications directory service
JP2002259643A (ja) ビジネスプロセス制御プログラム
US20220086193A1 (en) Automation of cloud network security policy analysis and deployment
US20200186432A1 (en) System and method for automating the discovery process
JP4265413B2 (ja) 仮想私設組織に対するポリシの実施システム及びその方法
US8559415B2 (en) Method and apparatus for facilitating telecommunication network selection
EP1599054A2 (en) Method and system for administering configuration information in a private branch exchange switch
US20220086280A1 (en) Integrated customer information user interface
US20090063505A1 (en) Selective chaining of LDAP directory servers

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100525

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120131

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120426

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120803

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120903

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150907

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5081912

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250