JP5568634B2 - 電話通信アプリケーションサービス - Google Patents

Description

関連出願への相互参照
この出願は、「電話通信アプリケーションサービス」と題された、Maesによって２００９年６月２日に出願された米国仮特許出願番号６１／１８３，４３９に関し、その利益を主張する。あらゆる目的のため、その全開示がここに引用により援用される。

著作権表示
この特許文献の開示の一部は著作権保護の対象となる内容を含む。著作権者は、特許商標庁の特許ファイルまたは記録に現れた際には特許文献または特許開示のいずれによるファクシミリ再現に対しても異議を申立てないが、それ以外のすべてのいかなる著作権も留保する。

発明の背景
ボイスオーバーインターネットプロトコル（ＶｏＩＰ）などの技術の開発および普及により、インターネットなどの電子ネットワーク上で増大した量の電話通信および関連の機能性が利用可能になっている。電話通信アプリケーションは、伝統的な公衆交換電話網（「ＰＳＴＮ」）にとって一般的な機能性を電子ネットワーク上で提供することができる。そのような機能性は、コール転送、ボイスメール、会議通話、コール拒否、電話投票、コールスクリーニング、番号持運び制、料金無料通話およびフリーフォン、先払い通話、特定店舗専用カード通話、仮想プライベートネットワーク（たとえばＰＳＴＮ上のファミリーグループ通話または企業「電話通信」ネットワーク）、セントレックスサービス（仮想構内交換機（ＰＢＸ））、個人番号プラン（番号は電話帳で非公開のまま）、短縮番号および短縮コード、ユニバーサルパーソナル通信サービス（ユニバーサルパーソナル電話番号）、マスコーリングサービス、海外の携帯電話からの局番不要ダイヤル、海外からのシームレスマルチメディアメッセージングサービス（ＭＭＳ）アクセス、料金着信人払い、ホームエリア割引、プレミアム料金通話、コールと関連付けられたさまざまな判断基準に基づくコール配布、ロケーションベースのルーティング、時間ベースのルーティング、比例コール配布（たとえば２つ以上のコールセンターまたは事務所間）、ならびにコールキューイングを含むことができる。

機能性は、業界ではインテリジェントネットワーク（ＩＮ）として公知のものにおいて実現可能である。インテリジェントネットワークはさまざまなプロトコルを用いることができ、ある時はアプリケーション層がインテリジェントネットワークアプリケーション部（ＩＮＡＰ）と称される層状の方策を用い、ある時はトランザクション機能応用部（ＴＣＡＰ）などのより層の数の少ないプロトコルを用いる。ＩＮプロトコルのための１つの基準は、移動電話のための増大した機能を可能にする移動網拡張ロジックに関するカスタマイズされたアプリケーション（ＣＡＭＥＬ）である。Camelアプリケーション部（ＣＡＰ）をＴＣＡＰの上に重ねることができるため、ＴＣＡＰに付加的な機能を追加することができる。

欧州電気通信標準化機構（ＥＴＳＩ）ワイヤラインまたは古いワイヤレスネットワークには以下のプロトコル、すなわち、ＩＮＡＰ、ＩＮＡＰ機能セット１（ＣＳ−１）、INAP CS-1+（Ericsson変形）、およびＳＩＮＡＰ（Siemens変形）を用いる。北米については、Qwest Communications, AT&T, EMBARQ（登録商標）Wireless、およびRogers Communicationsなどの通信会社によって高度インテリジェントネットワーク（ＡＩＮ）がしばしば用いられる。グローバルシステム・フォー・モバイルコミュニケーション（ＧＳＭ（登録商標））およびユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）については、以下のプロトコル、すなわち、CAP v1からv4、INAP CS-1+、およびSINAP 5m/7mを典型的に用いる。ワイヤレス符号分割多重接続（ＣＤＭＡ）／１ｘを用いるネットワークについては、無線インテリジェントネットワーキング（ＷＩＮ）フェーズ１（ＩＳ−７７１）およびＷＩＮフェーズ２（ＩＮ−８２６）をしばしば用いる。メキシコおよびブラジルなどの場所で運用を行なう第２および第３層のオペレータは、十分に能力があるインテリジェントネットワークを未だ有していないことがあり、したがって、それらの地域では統合デジタル通信サービス網ユーザ部（ＩＳＵＰ）および電話ユーザ部（ＴＵＰ）プロトコルも関連がある。

サービス制御ポイント（ＳＣＰ）は典型的に、上記のものおよびネットワークを通したメッセージのルーティングに直接関しない他の機能を実行するのに用いられる。ＳＣＰはネットワークのサービスレベルでの制御を可能にするので、サービスロジックは上記サービスのうち提供される１つに対してプロトコルを駆動することができる。一般的に、サービスロジックはプロトコル特有であり、プロトコル特有の交換の操作として直接に開発され実行される。サービスロジックは１つの特定的なＩＮ（すなわち、十分に規定されたプロトコル）について構築される。統合電話ネットワークでは、これらのサーバはほとんど電話交換における機能として実現されているが、ＳＩＰ（セッション確立プロトコル）プロトコルに基づくインターネットプロトコル（ＩＰ）電話通信ネットワーク、次世代ネットワーク（ＮＧＮ）、およびインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）などのよりオープンなネットワークでは、これらはしばしばサーバを含む別個のコンピュータである。

１つの方策では、ＳＣＰサーバは、コール処理およびルーティング、コール終了、メッセージング、ならびに加入者独立または加入者依存アプリケーションなどのアプリケーションのサービスロジックの実行をサポートする。ＳＣＰは、オペレータが望む挙動、すなわちサービス、を実現するサービスロジックを含む。ロジック処理の間、コールを処理するのに必要とされる付加的なデータおよび能力をサービス制御機能（ＳＣＦ）から入手してもよい。（サービスロジックとしての）ＳＣＰ上で提供されるアプリケーションの例は、地域番号持運び制、料金無料通話ルーティング解決策、会議ブリッジサービス、およびユニファイドメッセージングなどの能力を含む。アプリケーション／電話通信サービスは（着信または発信）コールを連結するサービスによって提供可能である。

電話通信アプリケーション（すなわち、サービス制御ポイント上の電話通信／ＩＮ／ＰＳＴＮサービス）は一般的に、信号通信のみを行なうものと媒体操作に係るものとの２種のうち１つである。前者は地域番号持運び制、料金無料通話ルーティング、およびダイヤルされた番号がルーティング可能なアドレスに変換されなければならない他のサービスなどの機能性を含むルーティング解決策にしばしば関する。媒体操作に係る例は、多くのビジネスプロフェッショナルに馴染みのあるサービスである、会議ブリッジアプリケーション、音声自動応答（ＩＶＲ）などを含む。そのような例のためのコールの段階は以下を含む。ユーザは予め公開された番号に電話をする。ダイヤルされた番号がＩＰアドレスに変換され、アプリケーションサーバの終点を示し、コールがその終点にルーティングされる。アプリケーションサーバはメディアサーバに接続し、メディアサーバに挨拶し、会議番号を集めるように指示する。メディアサーバは会議番号を返し、アプリケーションサーバはメディアサーバに認証番号を集めるプロンプトを行なうよう指示する。集められた数字が正しければ、アプリケーションサーバはメディアサーバにこのコールを特定的な会議ブリッジに移すように言う。

別の例は、サービスがコールまたはメッセージングのための先払いサービスである先払いＳＣＰである。そのようなサービスでは、システムはユーザの加入をチェックして、ユーザの評価および残高も管理する。

しかしながら、そのような方策はＰＳＴＮ版の局面を保持するが、新しい電子環境の利点を十分に活用していない。

発明の簡単な概要
本開示に従う実施形態は、サービス提供プラットフォーム（ＳＤＰ）およびサービス指向アーキテクチャ（ＳＯＡ）ベースの方策の使用を通じて電話通信アプリケーションサービスを提供することに関する。コール転送、コール開始などの別々の機能性を各々が提供する、電話通信機能性を含むがそれに限定されないさまざまな「ビジェット」（すなわちＳＯＡサービス）がアプリケーションと組合されるおよび／またはその中に構成される。ビジェットは、マルチメディアセッションもしくはコール、または複数ユーザ間のコールもしくはセッションの組を処理し、ユーザについての情報にアクセスし、その情報を操作し（たとえば加入させるまたは課金する）、かつユーザ間でメッセージを送るのに用いられる、マルチメディアセッションまたはコール操作とロジックとを提供する。アプリケーション／電話通信サービスは、必要に応じて所望の電話通信機能性／ＩＮを提供するビジェットを構成することによって構築可能である。アプリケーション／電話通信サービスはアプリケーションをデバッグするのにも用いることができる。ビジェットは同時に異種のネットワークに対してサービスを行なう単一のアプリケーションのための機能性を提供することもできる。ただし、コールは任意の媒体種類またはマルチメディアセッションもしくはメッセージングとして解釈されるべきであることにも留意する。これは、映像、映像および音声、映像および／または音声およびデータなどを含むことができる。

１つの実施形態は、アプリケーション／サービスとしてネットワークベースの電話通信機能を提供するためのプラットフォームに関する。プラットフォームは、少なくとも１つのプロセッサと、動作するように少なくとも１つのプロセッサに結合されるメモリと、少なくとも１つのプロセッサ上で実行する複数のビジェットとを含む。ビジェットは各々、電気通信ネットワークアプリケーションのための再使用可能な機能を有し、複数のビジェットは、ビジェットの機能がアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワーク上で、かつ第２のＡＰＩコールを通して第２のネットワーク上で利用可能であるように、１つよりも多くのネットワーク技術上で実行するように可能化される。

別の実施形態は、アプリケーションサービスとしてネットワークベースの電話通信機能を提供するためのコンピュータで実現される方法に関する。方法は、プロセッサ上で、少なくとも１つのプロセッサ上で複数のビジェットを実行するステップを含み、ビジェットは各々が電気通信ネットワークアプリケーションのための再使用可能な機能を有し、さらに方法は、動作するようにプロセッサに結合されたメモリから、第１のアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワークからビジェットのうち１つにアクセスするステップと、プロセッサを用いて、第２のＡＰＩコールを通して第２のネットワークからビジェットのうち１つにアクセスするステップとを含む。第１および第２のネットワークは異なるプロトコルを利用する。

また他の実施形態は、上述の方法のための命令を用いるまたは記憶する機械読出可能有形記憶媒体に関する。

別の実施形態は、電話通信サービスを実現するためのコンピュータで実現される方法である。方法は、電気通信ネットワークアプリケーションのための再使用可能な機能を有する第１のビジェットをプロセッサ上で実行するステップと、電気通信ネットワークアプリケーションのための再使用可能な機能を有する第２のビジェットをプロセッサ上で実行するステップと、ビジェットが１つのアプリケーションで実行されるようにプロセッサを用いてビジェットを組合せるステップとを含む。方法は、ネットワーク上の電話通信サービスとしての機能を提供するステップをさらに含み、その中で、ビジェットは、各々のビジェットの機能がアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワーク上で、かつ第２のＡＰＩ機能コールを通して第２のネットワーク上で利用可能となるように１つよりも多くのネットワーク技術上で実行するように可能化される。

また別の実施形態は、配備されたシステムにおける電話通信アプリケーションサーバである。配備されたシステムは、電話通信アプリケーションサーバ（ＡＳ）と、動作するように電話通信ＡＳに接続される運営管理ポータルと、動作するように電話通信ＡＳに接続されるオペレータポータルと、動作するように電話通信ＡＳに接続されるエンドユーザポータルとを含む。配備されたシステムは、動作するように電話通信ＡＳに接続される課金機能サーバ、および動作するように電話通信ＡＳに接続されるコール詳細レコード（ＣＤＲ）サーバも含む。電話通信ＡＳは、公衆交換電話網（ＰＳＴＮ）ゲートウェイ、緊急通話センター、課金機能、および合法的盗聴サーバとインターフェイスするように配備される。

本明細書中に開示される発明の本質および利点のさらなる理解は、明細書の残余の部分および添付の図面を参照することによって実現され得る。

本発明に従うさまざまな実施形態を図面を参照して説明する。

１つの実施形態に従って用いることができるサービス提供プラットフォーム（ＳＤＰ）ベースの実現例を図示する図である。 １つの実施形態に従って用いることができるサービス提供プラットフォーム（ＳＤＰ）ベースの実現例を図示する図である。 １つの実施形態に従って用いることができるネットワークリソースおよびゲートウェイに接続するための実現例を図示する図である。 １つの実施形態に従って用いることができるライフサイクル管理インターフェイスに動作するように結合されるイネーブラを図示する図である。 １つの実施形態に従って用いることができるネットワークリソースおよびゲートウェイに接続するための実現例を図示する図である。 １つの実施形態に従って用いることができるネットワークリソースおよびゲートウェイに接続するための実現例を図示する図である。 １つの実施形態に従って用いることができるネットワークリソースおよびゲートウェイに接続するための実現例を図示する図である。 １つの実施形態に従って用いることができる通信およびモビリティサーバの構成要素を図示する図である。 １つの実施形態に従って用いることができるネットワークコネクティビティサーバの構成要素を図示する図である。 １つの実施形態に従って用いることができるオープンサービスアーキテクチャ（ＯＳＡ）アプリケーションサーバ（ＡＳ）の実現例を図示する図である。 １つの実施形態に従うＶｏＩＰアプリケーション用の使用を図示する図である。 １つの実施形態に従う仮想構内交換機（ＰＢＸ）アプリケーション用の使用を図示する図である。 １つの実施形態に従うＩＰマルチメディアサブシステム（ＩＭＳ）と機能性とを統合するための構成要素を図示する図である。 １つの実施形態に従って用いることができるコンピュータネットワークの構成要素を図示する図である。 １つの実施形態に従って用いることができるコンピュータ化装置の構成要素を図示する図である。 ＳＤＰを通したイネーブラおよびアダプタを通して機能性を提供するアプリケーションのビジェットを図示する図である。 本発明に従う、ＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示する図である。 本発明に従うセッションボーダーコントロール（ＳＢＣ）を有する非ＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示する図である。 本発明に従う、セッションボーダーコントロール（ＳＢＣ）を有しない非ＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示する図である。 本発明に従う単一の配備を図示する図である。 本発明に従うクラスタ中の配備を図示する図である。

発明の詳細な説明
さまざまな実施形態に従うシステムおよび方法は、電話通信機能をアプリケーションサービスとして開発し利用するためのプラットフォームを提供することによって、電子ネットワークベースの電話通信システムに対する既存の方策における前述および他の不備を解消する。

１つの実施形態に従う電話通信アプリケーションサービスを提供することに対する方策は、サービス提供プラットフォーム（ＳＤＰ）の使用を通じてサービス指向アーキテクチャ（ＳＯＡ）ベースの方策を実現することによってさまざまなサービスを提供可能であることを活用する。ＳＤＰ実現例は、コール制御機能が実行されるようにするコール制御イネーブラなどの何らかの再使用可能な機能性を提供するさまざまなイネーブラを活用することができ、基礎となるネットワークからこれらの機能を取出す。メディアサーバイネーブラは、会議機能またはストリーミング機能性を導出するなどのメディアサーバ機能性が、機能性が実際にどのように実現されるかとは独立して提供されるようにする。ＳＤＰは、音声対話をアプリケーションに追加する音声アクセスイネーブラなどのイネーブラも含むことができる。

ＳＤＰは絶対に必要というわけではない。というのも、異なるネットワークにわたって構築されるビジェットも好適だからである。また、発明を実行するのにイネーブラの使用が必要というわけではない。この出願では、ＳＤＰおよび／またはイネーブラを有する実施形態に発明を制限するように何ら解釈されてはならない。

しかしながら、さまざまな実施形態に従うシステムおよび方法はこの概念を次のレベルにもっていく。上述の方策はアプリケーションプログラミングインターフェイス（ＡＰＩ）などの構成要素を活用して、２人のユーザもしくはユーザと装置となどの２つの終点間でコールを設定し、または会議通話で５人を接続したりマルチメディアセッションを処理したりコールの通知を受けたりするなどの他の機能を行なうことができる。

代わりに、たとえば、コール、電話通信機能性を含むがそれに限定されない機能などのマルチメディアセッションの「ビジェット」を規定することにより、さまざまな利点が得られる。各々のビジェットは、たとえば、コールまたはマルチメディアセッション転送、コールブロック、緊急コール開始、会議、コール順次着信、メッセージング、課金プロファイルなどの機能を提供することができる。各ビジェットは、ＳＤＰのコール制御イネーブラ上に安置して電話通信機能性または他のマルチメディアセッション機能を提供するコードまたはライトアプリケーションの一部であることができる。これらのビジェットはこのように、セッション操作を提供することができるだけでなく、セッションおよび他のネットワーク（たとえばＩＮ）機能などを処理するのに用いることができるロジックを提供することもできる。ビジェットは、媒体（およびマルチメディア）制御、メッセージング、課金、およびユーザ詳細へのアクセスのためのロジックも提供することができる。

このように、アプリケーションまたはサービスは、これらのビジェットを組合せてマルチメディア、電話通信、および他のＩＮ機能性を提供することができる。たとえば、アプリケーションは、１組のビジェットを利用して通信の発信者（すなわち、ａ）信用保証、ｂ）プロファイル（たとえば、先払いもしくは後払い、法人、ゴールド、通常など）、またはｃ）状態（たとえば、請求書／勘定残高および請求書支払い／精算ステータス）に基づく加入者）を認証し、（たとえば、加入者についてどのサービス、設定、および好みが設定されたかなどの加入プロファイルに基づいて）通信に望まれるタスクを判断することができる。この情報を判断した後、ビジェット中のロジックを用いて、コールをボイスメールまたは会議に入れる、関連の受信者を呼出す、メッセージを送る、サービスに課金する、マルチメディアセッションを開始するなど、通信をどのように処理するかを判断することができる。

このように、電話通信アプリケーションサービスの実現例は、構築ブロックとしてビジェットを利用してビジネス信号通信を行ない、信号通信およびベース信号通信の取出を可能にすることができる。一旦これが提供されると、多様なアプリケーションを構築して、マルチメディアおよびコール転送、コールブロック、コール盗聴などの機能を実行することができる。ビジェットは、必要に応じて、ＳＤＰを用いて本格的な電話通信アプリケーションまたはアプリケーションサービスを提供するように構成可能である。たとえば、現在のユーザ所在情報、ユーザ嗜好などに基づき得るなどの、さまざまな要因に基づいてどこへコールを転送すべきかを判断するＶｏＩＰアプリケーションを作成することができる。別の例では、リアルタイムでまたは予めプログラムされた態様でどこにコールを転送すべきかなどをユーザが決定できるようにする構内交換機（ＰＢＸ）アプリケーションを作成することができる。構成は、Java（登録商標）またはＢＰＥＬ（ビジネスプロセス実行言語）などの任意の適切な技術を用いて達成可能である。これらのビジェットは、新たな電話通信またはマルチメディアアプリケーションまたはアプリケーションサービスを提供するように構成可能である。

このように、１つの実施形態に従う実現例は、電話通信アプリケーションまたはアプリケーションサービスを提供するように構成可能な１組のビジェットを提供する。１組のビジェットは、基礎となるネットワーク（たとえば、ＰＢＸ、ＳＩＰオーバーＩＭＳなど）の技術から取出されて、コール制御能力またはメディアサーバ能力だけでなく、コールの転送、コールについての情報の入手、コールの認証、目標捜し、所在情報のチェック、この情報に基づくコールの方向付けなどの、他のコール関連の機能性を公開することができる。ＰＢＸアプリケーションなどの本格的なアプリケーションは次に異なる個別のビジェットの構成を通して構築可能である。

今日、そのような機能性は、ｃ）ビジェットを構成するＩＴ実務の、ｂ）プロトコルにわたる、ａ）ビジェットの再使用なしに、プロプライエタリ実現例を通して提供されるであろう。機能は、アプリケーションを構築するように自由に構成可能な個別のコール処理ビジェットとしては提示されないであろう。構成されたビジェットの使用は、正しい待ち時間でそのレベルでコールに非常に迅速に反応できることなどの利点を与える。というのも、コールの際にアプリケーションに話しかけることが極めて重要というわけではないからであり、その理由は、ロジックがコールを正しく扱うアプリケーションに代わるものになるからである。

さらに、ＶｏＩＰおよび仮想ＰＢＸアプリケーションなどの多数の既存のアプリケーションは同様の機能性を利用するが、これらのアプリケーションは同じ環境においてすら別個に構築される。そのような方策の結果、コードが二重になり、このためにリソースが無駄になるとともに誤りの可能性が高まってしまう。本明細書中に記載の方策を用いると、コール制御イネーブラなどの構成要素を用いて、たとえばJava（登録商標）またはＢＰＥＬなどの適切な環境でそれらの機能の構成として原始的な機能またはビジェットを用いて所望のアプリケーションを構築することができる。

ＳＩＰ上で提供されるＩＭＳまたはＰＳＴＮ／ＩＮ特徴に如何に統合するか、ならびにＶｏＩＰ、仮想ＰＢＸ、ＳＣＩＭ、ＳＩＰ ＡＳ、所在、ネットワークへのアダプタ、コール制御、メディアサーバ制御、音声アクセス、媒体およびマルチメディアアプリケーション（たとえば、ＩＰＴＶ、映像、ウェブ会議、コールなど）、ならびにメッセージングなどの基本機能を提供する場合にどのように電話通信アプリケーションサービスを提供するかを含む具体的な技術および２つの特定的な局面に焦点を合わせた例示的な実現例を次に説明する。これらの局面は単に例示であり、これらおよび他のタスクを実行するように多数の他の構成要素を用い、置換し、および／または組合せることができることを理解すべきである。明細書および図に照らして当業者に明らかとなるように、これらのうちいくつかを本明細書中のどこかに記載するおよび／または示唆する。

多数のネットワーク（レガシー現在、将来、および変形）上にサービスを配備し、それらを共存させることができるシステムを実現することができる。

たとえば、図１（ａ）および図１（ｂ）は、１つの実施形態に従って用いることができる例示的なサービス提供プラットフォーム（ＳＤＰ）ベースのアーキテクチャ１００を図示する。図１（ａ）の例示的なアーキテクチャ１００では、ＳＤＰは、基礎となるネットワークリソースを取出し、サービス指向アーキテクチャ（ＳＯＡ）に従う横方向の基準に基づくプラットフォームを含む。１つの実施形態では、ＳＤＰは、Java（登録商標）２プラットフォーム企業版（Ｊ２ＥＥ）に基づく横方向ＳＯＡプラットフォームを利用する。ＳＤＰは、Ｊ２ＥＥコンバージドコンテナとしてＳＯＡ ＳＩＰ ＡＳ、ＯＳＡ ＡＳ、および電話通信ＡＳを含む、Java（登録商標）Specification Requests JSR 116/289およびJSR32に基づくコンバージドコンテナを含む。ＳＤＰは、移動体、音声、および他の通信イネーブラも公開する。

図１（ｂ）で、ＳＤＰコンフィギュレーション１５０は、アプリケーションサーバが提供する基礎となるＪ２ＥＥコア上で所望の機能性を実現するように示される。すべての要素およびネットワークにわたって管理される共通のアイデンティティならびにプリンシパルについてのすべてのデータの共通ビューを有することが有用である。サービス提供プラットフォームを提供することに対する基本的な方策は、標準ベースのＩＴ（情報技術）プラットフォーム（たとえばＪ２ＥＥ）で始まり、プラットフォーム通信会社グレードを作り、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）を超えてＳＩＰ、Diameter、およびParlayなどのプロトコルに拡張する。電気通信に関連の重要なプロトコルをサポートするため、たとえば、ＳＤＰは、ＳＩＰ／ＩＳＣ、Diameter、およびParlayコモンオブジェクトリクエストブローカーアーキテクチャ（ＣＯＲＢＡ）のサポートならびにメッセージングゲートウェイへのアダプタを提供することができる。標準的な方策を用いて、たとえばＪＣＡ１．５（Ｊ２ＥＥコネクタアーキテクチャ１．５）を用いて、任意の他のリソースまたはプロトコルへのアダプタを構築することができる。イネーブラは、ネットワークリソースおよび標準上りインターフェイスを取出す再使用可能な構成要素として提供される。次にＩＴ／ＳＯＡを用いて、（たとえば第三者からの）ＳＯＡベースのポリシーおよびビジネスルールを利用して収入発生サービスなどのサービスを提供することができる。次にプラットフォームは、ＳＤＰとシステムおよびサービスとのＳＯＡベースの統合を行なうことができる。第三者コンテンツおよびサービスプロバイダへの公開は、ポリシーを公開し、統合し、これを実施するＳＯＡによって達成可能である。サービスプロバイダ環境を通じてポリシー管理および評価をサポートしかつ合理化するのにもＳＯＡを用いることもできる。

ＳＩＰ、Parlay、またはＩＮプロトコル上で１組のイネーブラを提供し、実現することができる。これらのイネーブラは、たとえば、ＯＭＡ ＳＩＰ／ＳＩＭＰＬＥ所在、ＸＤＭおよびＲＬＳイネーブラ仕様に従う所在イネーブラを含んで、すぐに使えるＩＭＳ所在サーバおよびＳＩＰ／ＳＩＭＰＬＥ所在サーバを提供することができる。これは他のネットワークから所在（たとえばネットワーク所在）を集約し、アプリケーションのための上りParlayＸインターフェイスを提供して、所在ネットワークに参加せずに所在を用いることもできる。拡張可能所在データモデルを用いて、場所データを所在属性としてモデリングすることができる。たとえば、イネーブラは、ＳＩＰ（インターネットおよびＩＭＳ）ならびにParlay上のマルチメディアおよびマルチパーティコール制御を可能にすることができる。ＭＲＦのＭＲＦＣ機能であるメディアサーバ制御イネーブラおよび音声アクセスイネーブラは、多様なvoiceXMLサーバ、ＩＶＲ、アナウンスメントサーバ、およびメディアサーバ（たとえば、MSML、MSCML、MSCP、およびMGCP）を制御することができる。すぐに使うことができないプロトコルはＳＩＰ ＡＳ上にまたはＪＣＡ１．５を用いて構築可能である。

ソフトウェアアプリケーションはコマンドを発行して、統合ユーザプロファイル（ＵＵＰ）に新しいアカウントを作成することができる。ＵＵＰ構成要素は、ワークフローを起動させることができ、これは運用サポートシステム／ビジネスサポートシステム（ＯＳＳ／ＢＳＳ）と対話してＯＳＳ／ＢＳＳ所有のリポジトリ（または複数のリポジトリ）への更新を開始する１つ以上のビジネスプロセスからなってもよい。ＯＳＳ／ＢＳＳリポジトリが一旦更新されると、ＵＵＰは、結果として生じたＯＳＳ／ＢＳＳリポジトリ中の更新がデータハブおよびＵＵＰ（またはＵＵＰによって可視の／集約され得る任意の他のリポジトリ）に反映されるように継続する。ＵＵＰは他のデータリポジトリの仮想ビューであるため、データが更新されるとデフォルトのビューも更新される。これに代えて、データは同期される／リポジトリから複製される。そのような状況で、ＯＳＳ／ＢＳＳリポジトリとＵＵＰとの間のプロセスの自動化が発生する。しかしながらこれが十分に自動化されなければ、ワークフローは、確実にＵＵＰに変更が正しく反映されるように複製をトリガする役割を担ってもよい。アプリケーションが見る最終結果は同じであるが、任意の対応のアクションがワークフローによって扱われる。別の代替策は、ＳＯＡデータ管理能力でデータベース構成要素中のデータを更新するＵＵＰ構成要素を有し、データベース構成要素自体は、ＯＳＳ／ＢＳＳと対話するビジネスプロセスを作成するワークフローをトリガすることができる。

図２は、ポリシーエンフォーサ（ＰＥ）ならびにウェブサービスおよび他のバインディング（たとえば、標準的な上りインターフェイス）などの構成要素の使用を通じて、任意のドメイン（ＳＰ、端末）がどのようにＳＤＰベースの実現例２００を用いてオペレータ、端末、サービスプロバイダなどの中のリソースに接続できるかを図示する。ポリシーエンフォーサ２０２は、ＳＤＰを通してすべてのメッセージに関するポリシー（条件とアクションとの任意の組合せ）を実施するとともに、ファクタビジネスルールを適用するおよびＳＯＡ編成を実施するなどの機能を実行することができる。ドメイン２０４内外のアプリケーションまたは他のリソースは、ＳＤＰの構成要素を通してこれらのリソースを活用することができる。というのも、ＳＤＰは、ドメイン「内側」のアプリケーションと、ドメイン「外側」の第三者または他のアプリケーションとの間の対話を規定することができるからである。ＳＤＰは、以上論じたようなさまざまなイネーブラなどの構成要素２０６、ならびに／または以下に論じる所望の固有の機能性を有する再使用可能なおよび／もしくは構成可能な構成要素であり得るParlayＸもしくはParlayＡＰＩ構成要素を含むことができる。構成要素２０６は次に、ＩＭＳおよび非ＩＭＳリソースならびにParlay／ＯＳＡリソース（ＧＷ／ＦＷ／ＳＣＳｓ）および非Parlay／ＯＳＡリソースなどのリソースと通信して、異なるネットワーク上の実現例が共存できるようにすることができる。イネーブラと同じレベルでParlay構成要素を用いてこうしてＳＩＰ上で実現し、ＯＳＡ ＡＳを形成することができる。

図３は、図２のＳＤＰ実現例とともに用いることができるイネーブラ３００の例を図示する。この例では、イネーブラ３００は、コール制御、所在、メッセージング、課金、メディアサーバ制御、音声アクセス、統合ユーザプロファイル（ＵＵＰ）の提供、リソース管理などの有用な固有の機能を公開することができる再使用可能なおよび／または構成可能なＪ２ＥＥ（Sun Microsystems, Inc.から入手可能なJava（登録商標）２企業版）オブジェクトである。イネーブラは、たとえばJava（登録商標）および／またはウェブサービスのための標準化上りＡＰＩを利用することができ、ネットワークおよびプラットフォーム要素へのアダプタを介してリソースを取出して、予測可能な低い待ち時間および高いスループットのためのレシピを、ＳＩＰまたはＪＣＡ１．５などのネットワーク取出、プラットフォーム抽出、および標準技術に与えることができる。イネーブラは、永続性、高い利用可能性、管理、ロギングを提供することができる、イネーブラフレームワーク３０２または共通の機能性の組の一部でもあり得る、またはこれに基づき得る。

イネーブラおよびイネーブラフレームワークは、電話通信アプリケーションサービスの提供、第三者および／または第三者ゲートウェイへのウェブサービスの公開の提供、ならびに通信会社グレードＢＰＥＬ／ＳＯＡなどの機能性を含む、ＢＰＥＬにおけるポリシー適用および編成の実現例の提供に対するＳＤＰベースの方策を通じてＳＯＡの使用を提供することができる。イネーブラフレームワークは、ルールまたはポリシー（ＰＤＰ）の使用、ならびにＢＡＭおよびStudioなどの技術：ＳＣＥ（サービス作成環境）を提供することもできる。イネーブラフレームワークの使用は、ＢＰＥＬ、ルールエンジン、Oracleウェブサービスマネージャ（ＯＷＳＭ）などを利用するようにＳＯＡベースのアーキテクチャ上で実現可能な、OSE PE、OMA PEEM、IETF PDP/PEP、3PGW、または加入者ＧＷポリシーなどのさまざまなポリシーを適用可能にすることもできる。ＢＰＥＬだけでなく、さまざまな他のルール、スクリプトなども含む任意のプロセス実行言語を用いることができる。イネーブラは、ＯＳＳ／ＢＳＳ／ＳＤＰ統合を与えることもでき、ＷＳ、ＥＳＢ、ＳＯＡなどの機能性を与える。

以上論じたように、そのような方策は、ＩＭＳおよびレガシーネットワークなどのネットワークとの統合を与える。図４は、１つの実施形態に従う１つのそのような実現例の例４００を図示する。この例では、上述のようなＳＤＰを利用するサービス層でのアプリケーションおよびイネーブラは、本明細書中のどこかで論じるようなアダプタまたは統合フレームワーク４１０を通して、ＩＭＳリソース４０４、ＳＩＰリソース４０６、およびレガシーまたは他のネットワークリソース４０８などのリソースにアクセスすることができる。フレームワーク４１０は、ＳＩＰリソースにアクセスするＳＩＰアプリケーションサービス、および（Parlay、（ＩＮプロトコルへの）ＪＣＡなどを用いる）他のネットワークリソースにアクセスするＯＳＡアプリケーションサービスを含むことができ、ＳＩＰ ＡＳおよびＯＳＡ ＡＳの両方を用いて、たとえばＳ−ＣＳＣＦなどのＩＭＳリソースにアクセスすることができる。そのような実現例は、新たなまたは付加的なネットワークへのスムーズな移行とともに、ネットワークにわたるリソースの共存を提供する。そのような実現例はネットワーク取出を介した収束も提供することができ、任意のネットワーク上のサービスならびにＳＰドメインを通したアイデンティティ管理および真の収束のための共有統合ＯＳＳ／ＢＳＳを可能にする。

図５のスタック５００に図示されるように、ＳＤＰを使用することにより、ＳＯＡベースの実現例をネットワーク技術および／またはベンダーから独立した電話通信ＡＳに用いることができるようになる。見られるように、ＰＳＴＮ、ワイヤレス、およびＩＰネットワーク構成要素などのさまざまなネットワーク構成要素およびゲートウェイ５０２が存在できる。ネットワークおよびゲートウェイ層５０４は、さまざまな構成要素およびゲートウェイと通信するため、ネットワークアダプタ層５０６と組合せて（または同じ層の一部として）用いることができる。アプリケーションミドルウェア５０８は、ネットワークアダプタ層５０６を利用して、ビジネスルールおよび特定的なネットワークとは独立した開発、配備、実行、および管理などの機能を提供することができる。次にＳＯＡインフラストラクチャおよびビジネスルールは、ミドルウェア層の上の層５１０として提供可能であり、ＰＥ、ルール、編成、ＷＳＧＷ（ＷＳゲートウェイ）などの機能を含むビジネスルールおよびＳＯＡの適用を提供する。

図６は、１つの実施形態に従う、ＩＭＳ、ＮＧＮ、インターネット、およびレガシーネットワークの構成要素などのネットワーク構成要素およびゲートウェイ６０２との統合を提供するのに用いることができる層状実現例の別の例６００を図示する。この例では、ネットワーク構成要素およびゲートウェイ６０２は、ネットワークおよびゲートウェイ層６０４の構成要素（たとえば、メディアゲートウェイ、ＧＧＳＮ、ＳＧＳＮ）とともに、ＩＰトランスポートプレーンを形成する。ＩＰトランスポートプレーン上に制御プレーン６０６を形成することができ、制御プレーンは、S-CSCF、I-CSCF、P-CSCF、HSS、HLR、および本明細書中のどこかで論じるような他の構成要素を含むミドルウェアおよびアダプタを含む。次に、ＳＯＡ構成要素などの構成要素、ＶｏＩＰおよびＰＢＸアプリケーションなどのアプリケーション、イネーブラフレームワーク、ならびに図２に関して説明されたものなどの他の構成要素を含むことができる「サービス」プレーン６０８の一部として、制御プレーン上にＳＤＰを配備することができる。

図６のサービスプレーンはＳＩＰサーブレットコンテナも含み、プロキシ、レジストラ、および場所特定機能性などの機能性を提供する。図７は、１つの実施形態に従って用いることができるそのようなＳＩＰコンテナのための例示的なアーキテクチャ７００の例を図示する。そのような実現例を用いて１つの実施形態で通信およびモビリティサーバを提供することができ、これを用いて、電話、携帯電話、ＰＤＡなどの装置上で電話通信ＡＳを提供することができる。アーキテクチャは、多数のＳＩＰインフラストラクチャイネーブラ７０２を含んで示される。１つのそのようなイネーブラは、ＳＩＰ／ＳＩＭＰＬＥ、所在、ＸＤＭ、ＲＬＳ、および集約などの所在情報を提供するための所在イネーブラである。他のイネーブラは、ＳＩＰルーティングのためのプロキシ、現在のユーザ情報に公開アドレスをマッピングするためのレジストライネーブラ、現在のユーザＳＩＰネットワーク場所を判断するための場所特定イネーブラ、アプリケーションルータなどを含むことができる。アーキテクチャは、たとえば、ＳＩＰおよびＨＴＴＰサーブレットがアプリケーションオブジェクトを介してセッション状態を共有できるようにするアプリケーションセッション構成要素７０４も含む。アーキテクチャは、ＨＴＴＰ、ＳＩＰ、ならびに必要に応じて目標ネットワークおよびゲートウェイ構成要素のための他のプロトコルのためのコンテナおよびプロトコル構成要素も含むことができる。

１つの実施形態では、図７のＳＩＰコンテナは、収束アプリケーションサポート（たとえばクリック・トゥ・コール）、radiusサポート（たとえば特化されたログインモジュール）、ならびに統合されたＡＡＡデータベースおよびＮＡＴのためのセッショントラバーサルユーティリティ（ＳＴＵＮ）サポートを提供するＪＳＲ−１１６またはＪＳＲ−２８９準拠コンテナである。コンテナは、番号変換のためのＥＮＵＭ（Ｅ．１６４番号マッピング）データベースとの統合のためのサポートを与えることもできる。コンテナは、Diameter（Ｓｈ、Ｒｏ、Ｒｆ、…）と互換性があり得、Linux（登録商標）、SUN、Solaris、ＨＰＵＸ、ＡＩＸ、ウインドウズ（登録商標）などのプラットフォームにわたる利用可能性を提供することができる。

１つの実施形態でのそのような通信およびモビリティサーバは、スケーラブルプロキシレジストラおよびＶｏＩＰアプリケーションのための場所特定サービス、ならびにリブランディング可能ＶｏＩＰ／映像／ＩＭクライアントのためのサポートを提供することができる。サーバは、ＩＭＳの準備ができている、ＩＭＳ ＳＩＰアプリケーションサーバおよび／またはＩＭＳ所在サーバとして配備され得ることもできる。所在サーバはＳＩＰ／ＳＩＭＰＬＥ準拠であり得、ＸＤＭ（ＸＭＬ文書管理）、ＲＬＳ（リソースリストサーバ）、および所在集約サポートを提供することができる。所在サーバはＯＭＡ（オープンモバイルアライアンス）およびＩＭＳ準拠であることもできる。

図８は、図７に関して記載されたのと同様のアーキテクチャ８００を図示するが、この場合は、１つの実施形態に従うネットワークコネクティビティサーバ実現例またはＯＳＡ ＡＳ目標アーキテクチャを提供する。この例では、課金、メッセージング、メディアサーバ制御、および音声アクセスイネーブラを含むさまざまな他のイネーブラ８０２を設けるが、所望により他のさまざまな組合せを提供することができる。所在イネーブラを用いて、Parlayを介してＨＬＲからユーザステータスとしてネットワーク所在を公開することができる。マルチパーティコール制御イネーブラは、Parlay、ＳＩＰ、およびその他のために用いることができる。たとえば、Parlay5.1Java（登録商標）実現およびParlayX2.1WSを含むことができるＯＳＡ ＡＳ構成要素を設けることができる。ＯＳＡ ＡＳはレガシーおよびＩＭＳ互換性を提供することもでき、Parlayゲートウェイ登録を管理しかつ維持することができる。ＪＣＡ１．５アダプタ、ならびにParlayゲートウェイ（Corba）および他のネットワークリソースへのParlayＪＣＡアダプタなどの多数のアダプタも含むことができる。

そのようなネットワークコネクティビティサーバにより、今日のネットワーク上で実行される次世代ネットワーキング（ＮＧＮ）アプリケーションを開発できるようになり、レガシーからＩＭＳ／ＩＰへのスムーズなサービスの移行を与える。ネットワーク適合化層を含めることにより、任意のリソースに拡張可能なParlayゲートウェイへのＪＣＡ１．５ベースの接続性が提供され、Parlay／ParlayＸ実現ＡＰＩを用い、かつＪＣＡ１．５およびＳＩＰ上で働くＪ２ＥＥ中のＯＳＡ ＡＳが提供される。層はマルチアプリケーションサーバサポートおよび高性能も提供する。たとえば、図９は、１つの実施形態に従う図８のＯＳＡ ＡＳ構成要素９００の実現例の図を図示し、これはParlay5.1Java（登録商標）実現（Ｊ２ＥＥローカル）およびParlayX2.1WSに厳密に従う。そのような実現例のイネーブラがParlayＪＲ／Ｘと上りインターフェイスを共有し得る一方で、イネーブラは本明細書中のどこかで論じるように単にParlay構成要素以上のものであることができる。

論じたように、そのような方策を用いて、多数の異なるアプリケーションおよび技術によって利用可能な電話アプリケーションサービスを提供することができる。１つの例では、さまざまな実施形態に従って実現例を活用するＶｏＩＰアプリケーションを提供することができる。たとえば、図１０は、ＶｏＩＰアプリケーション１００４のためのインターフェイス１００２が、オペレータなどのユーザがシステムにアクセスしこれを利用できるようにしてソフトＶｏＩＰ／映像クライアント、ターミナルアダプタ、および第三者ソフトクライアントなどの装置と通信できるように示される例１０００を図示する。そのようなＶｏＩＰアプリケーションはビジェットの選択肢を構成して、音声通話、映像通話、オーディオメッセージングを含むインスタントメッセージング、コール履歴、カスタム所在加入および公開、所在ポリシー管理、複数アカウント管理、連絡先リスト管理、カスタムインストーラ、ブランディングされたスキンおよびテーマ、ならびにＧ．７１１、Ｇ．７２９、Ｈ．２６１、およびＨ．２６３を含む高品質オーディオおよびビデオコーデックなどの機能を提供することができる。ＶｏＩＰアプリケーションはＳＤＰ上で拡張可能でもあり得、所在およびインスタントメッセージング（たとえば、所在＋ＶｏＩＰ／映像、所在＋ＶｏＩＰ＋映像ＳＩＰ−Ｘ１０との相互運用、および所在＋ＶｏＩＰ＋ＰＳＴＮ上の終端（通話終了））などの機能を提供する。そのようなアプリケーションは、入呼、ＳＭＳ終了、ＳＭＳ開始、２つの呼出音、映像メール、呼出音、場所に基づくＲＢＴなどの機能性を提供することもできる。そのようなＶｏＩＰアプリケーションは、Ｊ２ＥＥなどの業界標準プラットフォーム上に構築されてコモディティハードウェア上で実行される、合法的盗聴、クラス５特徴、ＰＳＴＮおよびボイスメールルーティング、コール転送、発呼者プライバシーおよび／もしくはアイデンティティ、着信および発信コール禁止、ＰＳＴＮプレフィックス、ＥＮＵＭルーティング、アドレス変換、地域番号ルーティング、緊急サービスルーティング、ＡＣＲ／ＤＣＲ（規制特徴）、ならびに合法的盗聴（ＣＡＬＥＡおよび同様のもの）などの特徴を含むことができる。

図１１は別の例に従う実現例１１００を図示し、ここでは電話通信ＡＳを介して仮想ＰＢＸ機能性を提供する。そのようなアプリケーションは、たとえば企業ユーザにＩＰベースのおよびホスティングされたＰＢＸサービスを提供することができる。そのようなアプリケーションは、ビジェットの選択肢を構成してＪ２ＥＥなどの業界標準プラットフォーム上に構築され、コモディティハードウェア上で実行され、サービスのカスタマイズを提供する、アテンダント待ち行列、順次着信グループ、自動アテンダント、交換台クライアント、加入者自己運営管理、ブランディング、加入者利用可能性管理、インターフェイス提供、およびレポート作成などの機能性を提供することができる。

イネーブラまたはアプリケーションなどのプラットフォームによって公開されるさまざまな特徴は、ＳＯＡまたはＳＯＡ ＳＣＩＭを用いて組合せ可能である。ＳＯＡ ＳＣＩＭベースの方策において、使用またはＳＤＰは、「Ｓ−ＣＳＣＦの中」または「ネットワーク中」またはＳＩＰ ＡＳ限定が他のイネーブラとのサービスレベル文脈／構成を欠いている他の方策を与える。サービスレベル固有のＳＣＩＭ機能は、メッセージ上でルーティングするアプリケーション、（ＳＩＰのみのための）ＳＩＰサーブレット構成、イネーブラのＳＯＡ構成、アプリケーション構築ブロックもしくはアプリケーション、および／またはサービス層中のアプリケーションディスパッチとして提供可能である。このように、サービスは、ＳＯＡ ＳＣＩＭまたはアプリケーションディスパッチを用いて組合せることによって「呼べば応じる状態で」適用可能である。

図１２の例１２００で図示するように、１つの実施形態では、ＩＭＳとのそのような機能性の統合が達成される。図では、もし電話通信ＡＳが実行するならば、ＯＣＭＳ（Oracle（登録商標）通信およびモビリティサーバ）はＳＤＰである。そのような実現例はアプリケーションディスパッチおよびレジストラ／場所特定複製を有するＶｏＩＰ／ＶＰＢＸドメインを提供することができる。そのような配備はＳ−ＣＳＣＦへの第三者登録を提供することもできる。すべての場合、Ｓ−ＣＳＣＦは今回、メッセージ経路上にＳＩＰ ＡＳを含める（すなわち電話通信サービスとして）ことを識別する。そのような配備とともにＶｏＩＰを用いると、たとえばＪ２ＥＥで電話通信ＡＳが提供され、コール（ＳＣＩＭ）＋ＶＰＢＸ、アダプタ（ＪＣＡ１．５）、またはネットワークＧＷ（たとえばＰＩＭＧ）上にディスパッチされたＶｏＩＰサービスが提供され、Ｊ２ＥＥ構成要素として、ＮＧＮ、レガシーリソース、（ＩＰ）−ＰＢＸおよび（ＩＰ）セントレックス、ならびにカスタム特徴に統合するようになる。統合の方法は、ＩＭＳへの非ＩＭＳ ＳＩＰアプリケーションの、またはＩＭＳおよびレガシー（ＰＳＴＮ／ＩＮ）ネットワークへの、ＳＤＰ上で（すなわちイネーブラを介して）電話通信サービスを提供するアプリケーションの、統合を可能にするために、比較的「包括的」にできる。なぜなら、サービスはネットワークから取出されるからである。アプリケーションはユーザデータへのアクセスも必要とするかもしれないが、これは、１つの実施形態では、すべての加入者データの仮想ビューを与える、以上で論じた統合ユーザ提供（ＵＵＰ）を用いて達成可能である。

図１６から図２０は、本発明に従うアプリケーションサーバを有するさまざまな実施形態を図示する。図１６はＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示し、図１７はセッションボーダーコントロール（ＳＢＣ）を有する非ＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示し、かつ図１８はセッションボーダーコントロール（ＳＢＣ）を有しない非ＩＭＳ中の電話通信／テレコムアプリケーションサーバを図示する。図１９は単一の配備を図示し、図２０はクラスタの配備を図示する。これらのＩＭＳおよび非ＩＭＳオプションおよび配備の考察を例としてのみ提示する。

上記説明に従って、１組のビジェットを（以下に論じる）動作環境でさまざまなプログラミングモデル上に構築することができる。各々のビジェットは、典型的な他の電話通信機能のサポートに必要とされる基本機能を表わす。それらはたとえば以下のとおりである。

１） ２者間でコールを作成する。
２） ２者間での（作成されたまたは既存の）コールを終了させる。

３） （作成されたまたは既存の）コールの各々のレッグを修正する。
４） コールの通知を処理するおよび別の者に向けるまたは終了させる。

５） メディアサーバセッションを作成して２者より多くをコールに混合する。
６） メディアセッションにコールを加える。

７） メディアセッションからコールを除く。
８） コールを処理する（たとえば、消音、消音解除、変換、保留）。

９） メディアセッションを管理する（たとえば、誰が話す番か、消音、ＤＴＭＦ処理）。

１０） 対話管理（たとえば、ＤＴＭＦ対話／認識または対話認識）をコールまたはメディアセッションに与える。

１１） コールを待ち行列に入れる。
１２） コール待ち行列を管理する。

１３） 番号を変換する。
１４） 短いコードを手渡す。

１５） 緊急コールをルーティングする。
１６） （着信／発信）コールを禁止する。

１７） インスタントメッセージング。
１８） 発呼者回線識別制限および発呼者プライバシーを可能化する。

１９） 発呼者回線識別提示を可能化する。
２０） 匿名のコールを拒否する。

２１） 迂回されたコールを拒否する。
２２） コール転送を可能化する。

ａ．話中
ｂ．応答なし
ｃ．無条件
ｄ．到達不能
２３） コール記録を可能化する。

２４） コールの（合法的）盗聴を可能化する。
２５） コールの着信音を可能化する。

２６） コールの呼出音を鳴らす。
２７） ユーザプロファイルにアクセスする。

２８） ユーザ所在にアクセスする。
２９） ボイスメール機能を可能化する。

３０） コール／イベントの課金を開始する。
３１） コールイベントの課金を委託する。

ａ．先払い
ｂ．後払い
３２） コールの課金を停止する。

３３） 課金／勘定残高通知を得る。
３４） 残高をチェックする。

３５） コール詳細レコード（ＣＤＲ）生成を可能化する。
３６） 課金額をとっておく。

３７） メッセージを送る。
３８） メッセージをルーティングする。

３９） メッセージを変換する。
４０） プライベートコールネットワーク（ＶＰＮ）を可能化する。

４１） 発呼者ＩＤを得る。
４２） ユーザ／ユーザ機器のための継続中の発呼者ＩＤを得る。

４３） ネットワーク／ネットワーク機器を選択する。
４４） ネットワーク／ネットワーク機器を発見する。

４５） 一意な加入者番号を可能化する。
実施形態では、上記ビジェット中の機能を再使用可能な構成要素（たとえば、ＳＩＰサーブレットまたはＳＯＡサービスコールイネーブラ）として実現する。機能をＳＩＰサーブレット上またはＩＮ上で実現することもできる。

次に、（コードロジックで、またはランタイムで予めコンパイルされ得るＢＰＥＬのようなビジネスプロセスを介して）ビジェットが構成される。

会議通話ＶｐＢＸまたは電話通信クラス５（たとえば住宅用ＶｏＩＰ）などのアプリケーションは、以下の例示的なビジェットなどのビジェットの組合せとして構築可能である。

１．会議
ａ．コールが受信される。

ｂ．コールが対話管理を介して処理される。
ｃ．第１のコールがメディアセッションを作成してもよい。

ｄ．対話によって他の認証されたコールが送られ、次にメディアセッションに追加される。

ｅ．メディアセッションは、混合、消音、およびＤＴＭＦ処理を実現する。
２．ＶＰＢＸ、ＩＰ−ＰＢＸ
ａ．コールが受信される。

ｂ．コールが待ち行列に入れられる。
ｃ．管理者に待ち行列が通知される。

ｄ．管理者が待ち行列を管理し、コールを再方向付けする。
ｅ．必要に応じてコールが再方向付けされる。

ｆ．ＶＰＰＮ／番号変換／ボイスメール／対話管理を追加可能である。
３．住宅用電話通信
ａ．クラス５サービスが記載のビジェットによってカバーされる。

４．ネットワーク相互作用／セッションボーダーコントロールが、
ａ．着信コール
ｂ．コール処理に向けること、および
ｃ．（別のネットワークで）コールを生成すること、を制御するものとして見られる。

先行技術に勝る本実施例のいくつかの利点は、（１）ほぼすべてのネットワーク技術に対して同じビジェットを使用可能であること、（２）ビジェットのＩＴ／ＳＯＡ開発をＩＴプラットフォーム（たとえばＪＥＥ）上で行なえること、かつ（３）ＩＴツール（たとえばＢＰＥＬスタジオ）を介してビジェットのＩＴ／ＳＯＡ構成が存在できることである。

図１５は、イネーブラおよび異なるネットワークへのアダプタを用いる、ＳＤＰを通したイネーブラおよびアダプタを通じて機能性を提供するアプリケーションのビジェットを図示する。１個から任意のＮ個のビジェットをアプリケーションが用いることができるまたはその中に組入れることができる。アプリケーションは、ビジェットをともに組合せ、統合し、またはそうでない場合は構成することができる。ビジェットの構成は、たとえばウェブサービスビジネスプロセス実行言語（ＷＳ−ＢＰＥＬ）などのスクリプト／ロジックで実現可能である。ビジェットはイネーブラを通してサービス提供プラットフォーム（ＳＤＰ）／ＭＷに接続可能である。イネーブラは、基礎となるネットワーク、ＯＳＳ／ＳＢＳ、またはＩＴリソースを駆動する１つ以上のアダプタを有することができる。ＳＤＰ／ＭＷ内で直接にプロトコルを公開することにのみイネーブラを用いることも可能である。第２のビジェットはイネーブラとも通信可能であり、必要に応じて同じアダプタを用いることができる。ビジェットは異なるネットワーク上で機能を用いなければならないまたは混合しなければならない可能性がある。その場合、異なるアダプタ／イネーブラインスタンスが関わってもよい。たとえば、ビジェットは、そのためにどのイネーブラインスタンスを用いるべきかを判断して、タスクまたは１組のタスクを、特定的なネットワーク上で（たとえば、コールが発信されたネットワーク上で、コールが向かっているネットワーク上で、または加入者が関連付けられている場所で）行なう（たとえばサービスを提供する）ことがある。これは、とりわけ、正しいイネーブラインスタンスおよび／またはゲートウェイを選択することによってコールのレッグを作成することができるネットワークの選択である。ゲートウェイは１つのネットワークから別のネットワークへ媒体を転送することができるものであり得る。ビジェットは、セッション確立プロトコル（ＳＩＰ）アプリケーションサーバ（ＡＳ）を用いるものを含む複数のイネーブラとも通信可能である。他のＡＳ環境も、ＩＮ、Parlay、および他のプロトコルを用いるものなど、ＳＤＰを通じてサービス提供を受けることもできる。

いくつかのビジェットはどのイネーブラにも接続されないことがあるが、内部使用のためにアプリケーション中に含まれてもよい。隣接するビジェットは、内部機能およびアプリケーションのためのプロセスを提供することができる。ビジェットは、アプリケーションに有用な機能を実現する再使用可能な構成要素である。いくつかのビジェットは、本当は発呼するイネーブラではないが、別個の再使用可能な種類のアプリケーションモジュールである待ち行列を管理するウェブまたはメッセージ駆動インターフェイスのようなものを提供してもよい。

アプリケーションは、要素を統合するＢＰＥＬまたは他のスクリプト／ロジックコードを利用するビジェットの構成であり得る。ビジェットは、アプリケーションの一部として後端で電話通信サービス、請求書サービス、および他の機能性を提供するように混合され、一致され得る。特定のネットワークからビジェットおよび機能性を分離することにより、同じアプリケーションを、変更せずに他のネットワーク上で使用できるようにすることができる。

ある実施形態では、同時に２つ以上のネットワーク上でアプリケーションを使用する。１つのネットワークはローカルエリアネットワークであり得、別のものは公衆交換電話網（ＰＳＴＮ）であり得る。同時に異種のネットワークの両方でアプリケーションがサービス提供するので、アプリケーションは各ネットワーク上で同じ振舞いをする。ユーザがアプリケーションを使用しながら１つのネットワークから別のネットワークへ切換わる場合、アプリケーションは、応答を速めるため、同じメモリ状態、キャッシュページ、および他の後端サーバ効率メカニズムを用いることができる。

アプリケーションが同時に複数の異種のネットワークに対して働く実施形態では、技術者は、より容易にトラブルシューティングを行ない、問題をデバッグすることができるかもしれない。ある者は１つのネットワーク上でアプリケーションの機能をテストし、次に他のネットワークで同じ機能をテストすることができる。問題の同じ症状が起こる場合、技術者は問題をアプリケーションに絞り込むことができる。２つのネットワーク上で症状が異なる場合、技術者は、アプリケーションではなくネットワークに問題を絞る。このトラブルシューティングも自動化されて、問題の大まかな境界と、ネットワーク上またはアプリケーション中で異常が起こっているか否かとを判断することができる。

動作環境
図１３は、さまざまな実施形態が実現され得る例示的な動作環境の構成要素を図示するブロック図である。システム１３００は、専用アプリケーション、ウェブブラウザなどのクライアントを動作するのに用いることができる、１つ以上のユーザコンピュータ、計算装置、または処理装置１３１２、１３１４、１３１６、１３１８を含むことができる。ユーザコンピュータ１３１２、１３１４、１３１６、１３１８は、（単に例示のために、標準的なオペレーティングシステムを実行するパーソナルコンピュータおよび／もしくはラップトップコンピュータを含む）汎用パーソナルコンピュータ、（移動体ソフトウェアを実行し、インターネット、電子メール、ＳＭＳ、ブラックベリー、もしくは他の通信プロトコルで可能化される）携帯電話もしくはＰＤＡ、および／または（限定されることなくさまざまなＧＮＵ／Linux（登録商標）オペレーティングシステムを含む）さまざまな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸ（登録商標）のようなオペレーティングシステムのうち任意のものを実行するワークステーションコンピュータであり得る。これらのユーザコンピュータ１３１２、１３１４、１３１６、１３１８は、１つ以上の開発システム、データベースクライアントおよび／またはサーバアプリケーション、ならびにウェブブラウザアプリケーションを含むさまざまなアプリケーションの任意のものも有してもよい。これに代えて、ユーザコンピュータ１３１２、１３１４、１３１６、１３１８は、ネットワーク（たとえば後述されるネットワーク１３１０）を介して通信するおよび／またはウェブページもしくは他の種類の電子文書を表示しかつナビゲートすることができる、シンクライアントコンピュータ、インターネット可能化ゲームシステム、および／またはパーソナルメッセージング装置などの任意の他の電子装置であってもよい。例示的なシステム１３００が４つのユーザコンピュータとともに示されるが、任意の数のユーザコンピュータがサポートされてもよい。

大部分の実施形態では、システム１３００は、何らかの種類のネットワーク１３１０を含む。ネットワークは、限定されることなくＴＣＰ／ＩＰ、ＳＭＡ、ＩＰＸ、AppleTalkなどを含むさまざまな市販のプロトコルのうち任意のものを用いてデータ通信をサポートすることができる、当業者には馴染みのある任意の種類のネットワークであってもよく、任意の種類であり得る。単に例示のため、ネットワーク１３１０は、イーサネット（登録商標）ネットワーク、トークンリングネットワークなどのローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク、限定されることなく仮想プライベートネットワーク（「ＶＰＮ」）を含む仮想ネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網（「ＰＳＴＮ」）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、技術分野で公知のＩＥＥＥ８０２．１１プロトコル群、ＧＲＰＳ、ＧＳＭ（登録商標）、ＵＭＴＳ、ＥＤＧＥ、２Ｇ、２．５Ｇ、３Ｇ、４Ｇ、Wimax、WiFi、ＣＤＭＡ２０００、ＷＣＤＭＡ、ブルートゥースプロトコル、および／もしくは任意の他のワイヤレスプロトコル）、ならびに／またはこれらおよび／もしくは他のネットワークの任意の組合せであり得る。

システムは、汎用コンピュータ、（単に例示のために、ＰＣサーバ、ＵＮＩＸ（登録商標）サーバ、中型サーバ、メインフレームコンピュータラック搭載サーバなどを含む）特化されたサーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な配置および／もしくは組合せであり得る１つ以上のサーバコンピュータ１３０２、１３０４、１３０６も含んでもよい。サーバのうち１つ以上（たとえば１３０６）は、ビジネスアプリケーション、ウェブサーバ、アプリケーションサーバなどのアプリケーションの実行専用であってもよい。そのようなサーバは、ユーザコンピュータ１３１２、１３１４、１３１６、１３１８から要求を処理するように用いられてもよい。アプリケーションは、サーバ１３０２、１３０４、１３０６のリソースへのアクセスを制御するための任意の数のアプリケーションを含むこともできる。

ウェブサーバは、以上論じたもののうち任意のものを含むオペレーティングシステムおよび任意の市販のサーバオペレーティングシステムを実行することができる。ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データベースサーバ、Java（登録商標）サーバ、ビジネスアプリケーションなどを含むさまざまなサーバアプリケーションおよび／または中間層アプリケーションのうち任意のものも実行することができる。サーバは、ユーザコンピュータ１３１２、１３１４、１３１６、１３１８に応答してプログラムまたはスクリプトを実行することが可能であり得る１つ以上のコンピュータであってもよい。一例として、サーバは１つ以上のウェブアプリケーションを実行してもよい。ウェブアプリケーションは、Java（登録商標）、Ｃ、Ｃ♯、もしくはＣ＋＋などの任意のプログラミング言語、ならびに／またはPerl、Python、もしくはTCLなどの任意のスクリプト言語、ならびに任意のプログラミング／スクリプト言語の組合せで書かれた１つ以上のスクリプトまたはプログラムとして実現されてもよい。サーバは、ユーザコンピュータ１３１２、１３１４、１３１６、１３１８上で実行するデータベースクライアントからの要求を処理することができる、Oracle（登録商標）、Microsoft（登録商標）、Sybase（登録商標）、ＩＢＭ（登録商標）などから市販されているものを限定されることなく含むデータベースサーバも含んでもよい。

システム１３００は、１つ以上のデータベース１３２０も含んでもよい。データベース１３２０はさまざまな場所に常駐してもよい。例示として、データベース１３２０は、コンピュータ１３０２、１３０４、１３０６、１３１２、１３１４、１３１６、１３１８のうち１つ以上にローカルな（および／またはその中に常駐する）記憶媒体上に常駐してもよい。これに代えて、これは、コンピュータ１３０２、１３０４、１３０６、１３１２、１３１４、１３１６、１３１８のうちいずれかもしくはすべてから遠隔であってもよく、および／またはこれらのうち１つ以上と（たとえばネットワーク１３１０を介して）通信してもよい。特定の組の実施形態では、データベース１３２０は、当業者には馴染みのある記憶領域ネットワーク（「ＳＡＮ」）に常駐してもよい。同様に、コンピュータ１３０２、１３０４、１３０６、１３１２、１３１４、１３１６、１３１８に帰属される機能を果たすための任意の必要なファイルを適宜それぞれのコンピュータ上にローカルにおよび／または遠隔に記憶してもよい。１組の実施形態では、データベース１３２０は、ＳＱＬフォーマットされたコマンドに応答してデータを記憶し、更新し、検索するように適合される、Oracle 10gなどのリレーショナルデータベースであってもよい。

図１４は、さまざまな実施形態が実現され得る例示的なコンピュータシステム１４００を図示する。システム１４００は、上述のコンピュータシステムのうち任意のものを実現するように用いられてもよい。コンピュータシステム１４００は、バス１４２４を介して電気的に結合されてもよいハードウェア要素を含んで示される。ハードウェア要素は、１つ以上の中央処理装置（ＣＰＵ）１４０２、１つ以上の入力装置１４０４（たとえば、マウス、キーボードなど）、および１つ以上の出力装置１４０６（たとえば、表示装置、プリンタなど）を含んでもよい。コンピュータシステム１４００は１つ以上の記憶装置１４０８も含んでもよい。例示として、記憶装置１４０８は、プログラマブルでフラッシュ更新可能などであり得る、ランダムアクセスメモリ（「ＲＡＭ」）および／または読出専用メモリ（「ＲＯＭ」）などのディスクドライブ、光学記憶装置、固体記憶装置などの装置を含むことができる。

コンピュータシステム１４００はさらに、コンピュータ読出可能記憶媒体リーダ１４１２、通信システム１４１４（たとえば、モデム、ネットワークカード（無線または有線）、赤外線通信装置など）、ならびに上述のようなＲＡＭおよびＲＯＭ装置を含み得るワーキングメモリ１４１８を含んでもよい。いくつかの実施形態では、コンピュータシステム１４００は、デジタル信号プロセッサＤＳＰ、特殊用途プロセッサなどを含むことができる処理加速ユニット１４１６も含んでもよい。

コンピュータ読出可能記憶媒体リーダ１４１２は、コンピュータ読出可能情報を一時的および／またはより永続的に内蔵し、記憶し、送信し、かつ検索する記憶媒体に加えて、遠隔の、ローカルの、固定された、および／または取外し可能な記憶装置を（オプションで記憶装置１４０８と組合せて）ともに包括的に表わすコンピュータ読出可能記憶媒体１４１０にさらに接続可能である。通信システム１４１４は、システム１４００に対してネットワークおよび／または上述の任意の他のコンピュータとデータが交換されるのを許してもよい。

コンピュータシステム１４００は、オペレーティングシステム１４２０および／または（クライアントアプリケーション、ウェブブラウザ、ミドル層アプリケーション、ＲＤＢＭＳなどであり得る）アプリケーションプログラムなどの他のコード１４２２を含むワーキングメモリ１４１８内に現在位置するように示されるソフトウェア要素も含んでもよい。コンピュータシステム１４００の代替的実施形態は、上述のものからの数多くの変形を有してもよいことを認めるべきである。たとえば、カスタマイズされたハードウェアも用いてもよく、および／または特定の要素がハードウェア、（アプレットなどのポータブルソフトウェアを含む）ソフトウェア、またはその両者において実現されてもよい。さらに、ネットワーク入力／出力装置などの他の計算装置への接続が用いられてもよい。

コードまたはコードの部分を内蔵するための記憶媒体およびコンピュータ読出可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、データ信号、データ伝送、または所望の情報を記憶するもしくは伝送するのに用いることができ、コンピュータによってアクセス可能な任意の他の媒体を含む、コンピュータ読出可能命令、データ構造、プログラムモジュール、または他のデータなどの、情報の記憶および／または伝送のための任意の方法または技術において実現される、揮発性および不揮発性、取外し可能および取外し不可能媒体などの、しかしこれらに限定されない記憶媒体および通信媒体を含む、公知のまたは技術分野で用いられている任意の適切な媒体を含むことができる。本明細書中に与えられた開示および教示に基づいて、当業者はさまざまな実施形態を実現する他の態様および／または方法を認めるであろう。

したがって、明細書および図面は制限的な意味というよりはむしろ例示的な意味でみなされるべきである。しかしながら、請求項に述べるような発明のより広い精神および範囲から逸脱することなく、さまざまな修正および変更がなされてもよいことが明らかであろう。

Claims (19)

1. アプリケーションサービスとしてネットワークベースのマルチメディア機能を提供するためのプラットフォームであって、
   少なくとも１つのプロセッサと、
   前記少なくとも１つのプロセッサに動作するように結合されるメモリと、
   前記少なくとも１つのプロセッサ上で実行する複数のビジェットとを含み、前記ビジェットは各々が電気通信ネットワークアプリケーションのための再使用可能な機能を有し、
   前記複数のビジェットは１つよりも多くのネットワーク技術上で実行するように可能化され、これによりビジェットの機能はアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワーク上で、かつ第２のＡＰＩ機能コールを通して第２のネットワーク上で利用可能である、プラットフォーム。
2. 前記プラットフォームはサービス提供プラットフォーム（ＳＤＰ）を含む、請求項１に記載のプラットフォーム。
3. 前記ＳＤＰは音声対話が可能化されるように音声アクセスイネーブラを含む、請求項２に記載のプラットフォーム。
4. 各ビジェット上の前記再使用可能な機能はサービス指向アーキテクチャ（ＳＯＡ）ベースの方策に適合する、請求項２に記載のプラットフォーム。
5. ビジェットの構成をさらに含み、前記構成はネイティブコードロジックを用いて可能化される、請求項１に記載のプラットフォーム。
6. ビジェットの構成をさらに含み、前記構成はウェブサービスビジネスプロセス実行言語（ＷＳ−ＢＰＥＬ）を用いたワークフローを通したものである、請求項１に記載のプラットフォーム。
7. 前記ビジェットのうち１つは、２者間でのコールを作成することおよび２者間でのコールを終了させることからなる群から選択される再使用可能な機能を有する、請求項１に記載のプラットフォーム。
8. 前記ビジェットのうち１つは、マルチメディアセッションにおいてレッグを修正すること、マルチメディアセッション通知を処理すること、マルチメディアセッションを転送すること、マルチメディアセッションを第三者に方向付けること、およびマルチメディアセッションを終了することからなる群から選択される再使用可能な機能を有する、請求項１に記載のプラットフォーム。
9. 前記ビジェットのうち１つは、マルチメディアセッションを終了させること、複数のマルチメディアセッションを混合すること、マルチメディアセッションを適合させること、およびマルチメディアセッションに対する対話管理を実現することからなる群から選択される再使用可能な機能を有する、請求項１に記載のプラットフォーム。
10. 前記ビジェットのうち１つは、２者よりも多くがコールにおいて通信することができるようにメディアサーバセッションを作成すること、コールをメディアセッションに加えること、コールをメディアセッションから除くこと、および前記メディアサーバセッションにおいて消音を管理することからなる群から選択される再使用可能な機能を有する、請求項１に記載のプラットフォーム。
11. 前記ビジェットのうち１つは、媒体処理、音声および対話処理、コールを待ち行列に入れること、コールを管理すること、緊急コールルーティング、コールの禁止、インスタントメッセージング、メッセージを変換すること、発呼者回線識別制限、発呼者回線識別提示、匿名のコールの拒否、迂回されたコールの拒否、コール記録、ボイスメール、コールの合法的盗聴、着信音選択、呼出音選択、コールの課金開始、コールの課金委託、コールの課金停止、勘定残高情報を獲得すること、発呼者ＩＤを得ること、継続中のコールについてのユーザ機器のコールＩＤを得ること、電気通信ネットワークを発見すること、および一意な加入者番号を入手することからなる群から選択される再使用可能な機能を有する、請求項１に記載のプラットフォーム。
12. 命令を示す情報を具体化する機械読出可能記憶媒体であって、前記命令は、１つ以上の機械に、
    少なくとも１つのプロセッサ上で、各々が電気通信ネットワークアプリケーションのための再使用可能な機能を有する複数のビジェットを実行する動作と、
    第１のアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワークから前記ビジェットのうち１つにアクセスする動作と、
    第２のＡＰＩコールを通して第２のネットワークから前記ビジェットのうち１つにアクセスする動作とを行なわせ、
    前記第１および第２のネットワークは異なるプロトコルを利用する、機械読出可能記憶媒体。
13. アプリケーションサービスとしてネットワークベースの電話通信機能を提供するためのコンピュータで実現される方法であって、
    少なくとも１つのプロセッサ上で複数のビジェットをプロセッサ上で実行するステップを含み、前記ビジェットは各々が電気通信ネットワークアプリケーションのための再使用可能な機能を有し、さらに
    動作するように前記プロセッサに結合されるメモリから、第１のアプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワークから前記ビジェットのうち１つにアクセスするステップと、
    前記プロセッサを用いて、第２のＡＰＩコールを通して第２のネットワークから前記ビジェットのうち１つにアクセスするステップとを含み、
    前記第１および第２のネットワークは異なるプロトコルを利用する、方法。
14. 電話通信サービスを実現するためのコンピュータで実現される方法であって、
    電気通信ネットワークアプリケーションのための再使用可能な機能を有する第１のビジェットをプロセッサ上で実行するステップと、
    前記電気通信ネットワークアプリケーションのための再使用可能な機能を有する第２のビジェットを前記プロセッサ上で実行するステップと、
    前記プロセッサを用いて、前記ビジェットが１つのアプリケーションで実行されるように前記ビジェットを組合せるステップと、
    前記機能をネットワーク上の電話通信サービスとして提供するステップとを含み、
    前記ビジェットは、各々のビジェットの機能が、アプリケーションプログラミングインターフェイス（ＡＰＩ）機能コールを通して第１のネットワーク上で、かつ第２のＡＰＩ機能コールを通して第２のネットワーク上で利用可能となるように１つよりも多くのネットワーク技術上で実行するように可能化される、方法。
15. 前記電話通信サービスは、レガシーインテリジェントネットワークサービス、新しいサービス、ボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービス、仮想構内交換機サービス、および会議からなる群から選択される、請求項１４に記載の方法。
16. 前記ビジェットはイネーブラを用いる、請求項１４に記載の方法。
17. 前記第１のビジェットは前記第１のビジェットが実行されるネットワークを選択する、請求項１４に記載の方法。
18. 前記ビジェットはビジネスプロセス実行言語（ＢＰＥＬ）を用いて構成されている、請求項１４に記載の方法。
19. 請求項１４から１８のいずれかに記載の方法をコンピュータに実行させるためのプログラム。