JP5576171B2 - Ｉｍｓアプリケーションサーバー、ｉｍｓネットワーク、コンピュータに統合された方法、コンピュータプログラム - Google Patents

Description

本発明は、ＩＭＳ(インターネットプロトコルマルチメディアサブシステム)技術に関するものであって、特には、複数の異なるアクセスチャネルにアクセス可能なサービスを実現するためのＩＭＳアプリケーションサーバー、ＩＭＳネットワーク、コンピュータに統合された方法、コンピュータプログラムに関するものである。

通信企業や複合企業は、継続的にクライアントへのサービスを向上させる必要がある。同時に、当該企業は、その業務や提供するカスタマーケアサービスをより効率的にするとともに、コストを削減する必要がある。

そのような企業で使用される今日のレガシーネットワーク（legacy network）において、各アクセスチャネル（例えばTDM、IPTV、WEB等）は、ユーザーコンタクト（user contact）を管理するため、それ自身のアプリケーションを要する。各アクセスチャネルのために別のアプリケーションを有するこれらのレガシーネットワークは、垂直技術サイロ（vertical technological silo）とも称される。したがって、これらのサイロにおいて、サービス論理（service logic）が、それぞれのアクセスチャネルで実行される。加えて、サービスが生成される環境は、マルチシステム及びまたはネットワークの端末に散在し得ることから、サービスの生成が複雑になり得る。

したがって、今日のネットワークにおいて存在する技術的制約について対策するため、現在または将来における通信アクセスチャネルにおいて、ケアプロセスやサービスをサポートし、顧客コンタクトの頻度を向上し豊富なものとする必要性がある。

本発明のある側面によれば、複数の異なるアクセスチャネルを介してアクセス可能なサービス、例えば、ＩＰコンタクトセンターサービス、を実行するためのＩＭＳアプリケーションサーバーが提供される。ＩＭＳアプリケーションサーバーは、少なくとも１のサービスを生成するための複数の要素を提供し、前記少なくとも１のサービスをテストしサービス実行レイヤーに展開するサービス生成レイヤーを含み、前記サービス実行レイヤーは、前記少なくとも１のサービスを実行するサービス論理部と、前記少なくとも１のサービスを処理する際に用いられるその他のシステム及び／またはネットワークノードによって提供される少なくとも１の外部サービスへ接続するコミュニケーション部とを有する。

つまり、企業のコンタクトセンターシステムによって提供されるサービスのような、異なるアクセスチャネル（例えば、電話、テレビ、インターネット）からアクセス可能なサービスが、サーバー内で提供される。ここで、当該サーバーを、ＩＭＳアプリケーションサーバーという。つまり、コンタクトセンターシステムが、ＩＭＳアプリケーションサーバーで展開、実行される１以上のサービスに関して提供される。ＩＭＳアプリケーションサーバーは、ＩＭＳネットワークに設置されてもよい。特には、ＩＭＳアプリケーションサーバーは、ＩＭＳネットワークのサービスレイヤーに設置されてもよい。ＩＭＳアプリケーションサーバーは、使用される対応するアクセスデバイスやアクセスチャネルと独立して、ＩＭＳアクセスサーバがホストとして機能するサービスへの統合されたアクセスを提供してもよい。ユーザーからのサービスリクエストへの応答は、それぞれのアクセス装置によって受信されてもよい。

言い換えれば、コンタクトセンターによって提供されるサービスは、ＩＭＳネットワークのサービスであり、ＩＭＳアプリケーションサーバーで実行されてもよい。結果として、サービスは具体的な端末や対応する具体的アクセスネットワークと関連しない。また、サービスへのまたはサービスからのコールフロー(call flow)は、最適化される。ＩＭＳネットワークにおけるＩＭＳアプリケーションサーバーを介して提供されるユーザーとサービスのコミュニケーションはより効率化し、アクセスチャネルや対応する装置から独立となる。したがって、マンマシンインターアクション(man-machine interaction)が、向上する。ユーザーは、提供されるサービスへアクセスするための各アクセス装置やチャネルのための別のシステムやアクセス手段提供するための精神的タスクから解放される。更に、サービスアクセス、サービス実行、サービス展開が容易化され、より効率化される。ＩＭＳで実現可能なサービスを提供することは、より柔軟性があり、具体的ニーズに適応することができる。

ＩＭＳアプリケーションサーバーの構成例は、ＩＰコンタクトセンターＩＭＳアプリケーションサーバー（IP Contact Center (IPCC) IMS application server）である。特に、ＩＰＣＣ ＩＭＳアプリケーションサーバーは、サービス論理を、コール制御（call control）やメディア制御（media control）から解放し、実時間設計（runtime design）、変形、サービス展開への１のサービス生成環境を提供する。

本発明の他の側面によれば、ＩＭＳアプリケーションサーバーは、ＩＭＳネットワークのサービスレイヤーに設置されることを特徴とする。

本発明の他の側面によれば、前記サービスは、前記複数の異なるアクセスチャネルから、独自にアクセス可能であることを特徴とする。

本発明の他の側面によれば、前記サービス生成レイヤーは、ノードライブラリと関連したグラフィカル開発環境（サービスデザイナー（service designer））と、フロー図を用いて前記サービスを設計するためのドラッグドロップ機能(drag-and-drop functionality）と、を有することを特徴とする。

本発明の他の側面によれば、前記サービス論理部は、前記サービスを生成するとともに前記サービスを展開及び／または非展開する前記サービス生成レイヤーと相互に動作し、前記サービスは少なくとも１のコミュニケーション部を介してコミュニケーションされることを特徴とする。

よって、非技術的ユーザーであっても容易にサービスを定義、展開することができる。当該サービスは、その後ＩＭＳアプリケーションサーバーを通じて提供される。

本発明の他の側面によれば、前記複数の異なるアクセスチャネルは、1以上のプロトコル、1以上の物理的接続、及び／又は、有線若しくは無線接続を有してもよい。

本発明の他の側面によれば、前記複数の異なるアクセスチャネルは、１以上のプロトコル（例えば、ISDN, VoiceIP, UMTS, and GPRS)、及び／又は１以上の物理的接続（電話接続、携帯電話接続、インターネット、Ｗｅｂ、ブロードバンドコミュニケーション接続、ＴＶ接続（TV enabled connection））を含むことを特徴とする。なお、当該アクセスチャネルは、無線または有線による接続であってもよい。

本発明の他の側面によれば、前記サービスは、ＩＰコンタクトセンターサービスであることを特徴とする。

本発明の他の側面によれば、前記ＩＭＳアプリケーションサーバーは、ＩＭＳネットワークにおける標準化された要素であってもよい。

本発明の他の一般的側面によれば、ＩＭＳネットワークが提供される。ＩＭＳネットワークは、前記ＩＭＳネットワークの少なくとも１のサービスがサービスレイヤーにおける前記ＩＭＳアプリケーションサーバーにおいて実行されるように、前記ＩＭＳアプリケーションサーバーをホストする機能を有する前記サービスレイヤーと、複数の異なるアクセスチャネルを介して少なくとも１のサービスを送る制御及び伝達レイヤーと、前記複数の異なるチャネルにおいて使用可能な複数の異なるアクセス装置を有するアクセスレイヤーと、を有することを特徴とする。

本発明の他の側面によれば、前記制御及び伝達レイヤーは、更にＳＩＰセッションのための制御及びルーティング機能を提供するとともに、ＩＭＳエンティティとその他のネットワークドメイン間のコミュニケーション（例えば、PSTN, PLMN）を可能とすることを特徴とする。

本発明の他の一般的側面によれば、ＩＭＳアプリケーションサーバーの複数の異なるアクセスチャネルを介してアクセス可能なサービス、例えばＩＰコンタクトセンターサービス、を実行するためのコンピュータ実装方法が提供される。当該コンピュータ実装方法は、少なくとも１のサービスを生成するための複数の要素を提供するとともに、前記少なくとも１のサービスをテストし、前記ＩＭＳアプリケーションサーバーのサービス実行レイヤーに展開し、前記ＩＭＳアプリケーションサーバーにおいて、少なくとも１の複数の異なるアクセスチャネルを通じて前記少なくとも１のサービスの要求を受信し、前記少なくとも１のサービスを実行し、前記少なくとも１のサービスを処理する際に用いられるその他のシステム及び／またはネットワークノードによって提供される少なくとも１の外部サービスへ接続することを特徴とする。

本発明の他の側面によれば、コンピュータ読み取り可能な指示を含むコンピュータプログラムであって、コンピュータ及び／またはコンピュータネットワークシステムにおいてロードまたは作動された際に、前記コンピュータ及び／または前記コンピュータネットワークシステムに上記記載の方法に応じた動作をさせる手段、として機能させるためのプログラムが提供されることを特徴とする。

本明細書に記載の発明は、方法やシステムとして、実現され、または、コンピュータプログラム、有形の情報キャリア、例えばＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ、信号及び／またはデータストリーム、ハードディスクを用いて実現される。そのようなコンピュータプログラムは、データ処理装置に、本明細書に記載された１以上の動作を行わせるよう構成されてもよい。

更に、本明細書に記載の発明は、プロセッサや、プロセッサに接続されたメモリを含むシステムとして実現されてもよい。当該メモリは１以上のプログラムをエンコードし、プロセッサに本明細書に記載された１以上の方法を実行させる。更に、本明細書に記載の発明は、様々なＭＲＩ装置（MRI machine）により実現されてもよい。

下記に、実現例について、例示としての図及び説明により詳細に説明する。その他の特徴は、下記説明、図、及びクレームにより明らかとなる。

ＩＭＳアプリケーションサーバーによる技術的効果の例を示すブロック図である。 ケアリングプロセスとＩＭＳアプリケーションの使用の例を示すフロー図である。 従来のレガシーコンタクトセンターアーキテクチャを示す。 従来のレガシーネットワークとＩＭＳアプリケーションサーバーの例を含むレガシーネットワークの比較を示す。 ＩＭＳアーキテクチャにおけるＩＭＳアプリケーションサーバーの配置の例を示すブロック図である。 ＩＭＳアーキテクチャにおけるＩＭＳアプリケーションサーバーの配置の更なる例を示すブロック図である。 ＩＭＳアプリケーションサーバーを有するＩＭＳアーキテクチャの要素間の関係の例を示すブロック図である。 ＩＭＳアプリケーションサーバーを有するＩＭＳアーキテクチャにおけるサービスリクエストのフロー図の例を示す。 ＩＭＳアプリケーションサーバーを有するＩＭＳアーキテクチャにおけるサービスリクエストのフロー図の更なる例を示す。 ＩＭＳアプリケーションサーバーのアーキテクチャの例を示すブロック図である。 ＩＭＳアプリケーションサーバーのアーキテクチャの更なる例を示すブロック図である。 ＩＭＳアプリケーションサーバーに含まれるサービス生成レイヤーの一例を示すブロック図である。 ＩＭＳアプリケーションサーバーのサービス生成レイヤーに提供されるサービス生成環境の一例を示すブロック図である。 ＩＭＳアプリケーションサーバーのサービス実行レイヤーのサービス論理要素の一例を示すブロック図である。 ＩＭＳアプリケーションサーバーのサービス実行レイヤーのサービスコミュニケーション要素の一例を示すブロック図である。 ＩＭＳアプリケーションサーバーを通じたサービスリクエストのフローの一例を示す図である。 ＩＭＳアプリケーションサーバーを通じて動作する構成や顧客の例を示す図である。 コンピュータ（ネットワーク）システムの一例のブロック図を示す。

下記に、図面を参照しつつ、本発明の実施例について詳細に説明する。当該実施例は、種々の変形が可能である。特に、実施例の複数の要素は結合され、新たな実施例を形成するための他の実施例として用いられてもよい。

ＩＰマルチメディアサブシステム（IMS）は、インターネットプロトコル（IP）マルチメディアサービスを伝達するための人工的フレームワークである。インターネットとの統合を容易にするために、ＩＭＳは、可能な場所においてできる限り、例えば、セッション確立プロトコル（session initial protocol（SIP））等の特定のプロトコルを使用する。原則として、ＩＭＳはアプリケーションを標準化するものではなく、むしろ無線若しくは有線端末からのマルチメディア及び／又は音声によるアプリケーションのアクセスを援助するものである。即ち、固定化されたモバイル集中フォーム（fixed mobile convergence）を作成する。ＩＭＳは、サービスレイヤーからアクセスネットワーク（つまりアクセスレイヤー）を孤立する水平制御レイヤーによって実現される。論理的見地においては、制御（及び伝達）レイヤーは共通の水平レイヤーであり、サービスはそれ自身の制御機能は有しない。

原則として、ＩＭＳ（インターネットプロトコルマルチメディアサブシステム）ネットワークアーキテクチャは、分配された環境で実現されたソフトウェアやハードウェアシステム、例えばワールドワイドウェブ（WWW、つまりWeb）である。ワールドワイドウェブは、複数の異なる種類のネットワークのための制御機能と１の共通コア（common core）によって実現されるサービスやウェブサービスに基づいたＩＰ（インターネットプロトコル）を伝達するための標準化された方法を提供する。一般に、ＩＭＳアーキテクチャは、サービスレイヤー、伝達及び制御レイヤー、アクセスレイヤーの少なくとも３つのレイヤーによって形成される。サービスレイヤーへのアクセスは、アクセスレイヤー及び伝達及び制御レイヤーを介し、異なるエンドユーザー装置、例えば、電話、ＩＰＴＶ、ワークステーション、パーソナルコンピュータ、モバイル装置、によって用いられる複数の異なるアクセスチャネルからの統合された方法によって、提供される。したがって、ＩＭＳアプリケーションサーバーがアクセス可能な複数の異なるアクセスチャネルは、１以上の異なるプロトコル（例えば、ISDN、VoiceIP、UMTS、及びGPRS）や、１以上の異なる物理的接続（例えば、電話接続、携帯電話接続、インターネット、Ｗｅｂ、ブロードバンド通信線、テレビ接続（TV enabled connection））を含む。なお、アクセスチャネルは無線または有線であってもよい。

ＩＭＳアプリケーションサーバーは、複数の異なるアクセスチャネルを介してアクセス可能なＩＰコンタクトセンターをサポート及び管理する。例えば、ＩＭＳアプリケーションサーバーは、ＩＰコンタクトセンターのための（Web）サービスを提供する。本実施例によれば、ＩＭＳアプリケーションサーバーは、サービスがＩＭＳアーキテクチャのサービスレイヤーで実行されるように、ＩＭＳアーキテクチャのサービスレイヤーに存在する。ＩＭＳアプリケーションサーバーは、ＩＭＳアーキテクチャにおける他のＩＭＳユニットへの明確なインターフェースを有し、標準化されたユニットとして動作するように形成される。

通信企業や複合企業は、ウェブアプリケーションやウェブサービスとして実現される顧客ケアサービスのための継続的な改善と刷新を求める。更に、通信企業や複合企業は、提供する業務やサービスがより効率的となることを求めるとともに、そのようなサービスのためのコストを削減することを求める。図１に示された本実施例におけるＩＭＳアプリケーションサーバーの実装によりいくつかの技術的効果を実現することで、当該目的が達成される。本実施例のＩＭＳアプリケーションサーバーを実装することについての技術的効果は、ホストサービス（hosted services）を含む。ＩＭＳアプリケーションサーバーがホストサービスを含むことにより、特には、外部のシステムやサーバーのための新たなサービスが利用可能となる。例えば、他の（外部の）企業は、本発明のＩＭＳアプリケーションサーバーにアクセスすることで、コンタクトセンター（contact center）サービスが利用できる。本発明のＩＭＳアプリケーションサーバーを実装することによるもう一つの技術的効果は、マルチアクセス（multi-access）を実現できることである。ＩＭＳアプリケーションサーバーがマルチアクセスをサポートできることで、ユーザー（例えば顧客）は、（例えば電話を介した）音声によってだけでなく、異なるメディアを用いてサービスにコンタクトできる。ＩＭＳアプリケーションサーバーは、サービス論理と（アクセス）チャネル管理を分けることにより、当該マルチアクセスをサポートできる。例えば、ＩＭＳアプリケーションサーバーは、複数の異なるアクセスチャネルに対するルーティング（routing）と応答を決定するための（実質的に）同じ（論理的）規則を提供できる。更に、ＩＭＳアプリケーションサーバーは、人工知能的な（intelligent Non-human）（アクセス）チャネルをサポートできる。サービスは、サービス自身で起動し、例えば、提供されるサービスのコストと質を調整する。更に、ＩＭＳアプリケーションサーバーは刷新的なサービスの生成をサポートできる。例えば、非技術的なユーザーであっても、（ソフトウェア）プログラムすることなく、ＩＭＳアプリケーションサーバーに提供されたアプリケーションやサービスを再生成できる。また、ＩＭＳアプリケーションサーバーは、異なるユーザーを異なるグループへセグメント化、分類することにより、または、動的なユーザープロファイル（dynamic user profile）を利用することにより、ユーザーを中心としたケアをサポートできる。いいかえれば、ＩＭＳアプリケーションサーバーのサービス論理が、ユーザーのグループや種類毎に個々のものとされる。

図２は、ＩＭＳアプリケーションサーバー１０にサポートされたケアリングプロセス（caring process）３０の一例のフロー図を示す。ユーザー２０が、ＩＭＳアプリケーションサーバー１０を通じて提供されるサービスに、アクセスチャネル（例えば、電話、テレビ、コンピュータ、携帯装置）を介して、コンタクトした際、ユーザーはユーザーの動的（ユーザー）プロファイル（例えば、ユーザーが利用した少なくとも１のサービス等、ユーザーが興味ある特定のセグメント）に応じて、３１で認証される。ユーザー認証の後、３２で、ＩＭＳアプリケーションサーバー１０のサービスを実行する際のユーザー２０の特定のニーズを考慮するために、ＩＭＳアプリケーションサーバー１０は、自動的にユーザー２０の動的なプロファイルに応じてユーザー２０と相互作用（interaction）する。３３においては、ユーザーに自己対策（self-provision）や保証（assurance）機能を提供するために、ユーザーとオペレーションサポートシステム（OSS）やＩＭＳアプリケーションサーバー１０を通じてコンタクトされた企業のビジネスサポートシステム（BSS）との実時間における相互作用（interaction）に基づいて、ＩＭＳアプリケーションサーバー１０は、ユーザー２０へ自己ケア（self-care）を提供する。自己ケアや、自己対策や保証機能については、ユーザーは、サービスにコンタクトする際やサービスを生成、展開する際、ＩＭＳアプリケーションサーバー１０によって補助される。例えば、ヘルプ機能が提供されることにより補助される。更に、３４と３５で、ユーザー２０は、例えば、コンピュータ電話統合（computer telephony integration（CTI））のような１以上のエージェントルーティングエンジン（agent routing engine）から得られる１つ以上のエージェントが利用可能なデータに応じて配列されルーティング（routing）される。

図３は、１以上の遠距離通信（TLC）や情報技術（IT）によってサポートされるコンタクトセンターサービスのための従来技術におけるレガシーソフトウェアやハードウェアに基づいたアーキテクチャを示す。当該従来におけるシステムは、所有されたＡＰＩや装置ドライバや技術を用いることによって、特定のタスクや機能を実行する。例えば、ユーザー２０は、コンタクトセンター８に、Ｔ１、Ｔ２、またはＥ１コミュニケーションネットワーク等のＴＤＭ（時分割多重）アクセスを用いる構内交換機（PBX）５や、サービスレイヤー２、制御及び伝達レイヤー３やアクセスレイヤー４等を有するＩＭＳネットワーク１を介してアクセスする。このような従来技術におけるコンタクトセンターアーキテクチャは、データセンターに配置され、図３に示されるようなＩＭＳネットワーク（アーキテクチャ）１の一部に形成されるものではない。したがって、従来のコンタクトセンターアーキテクチャにおいては、データセンターへのアクセスリンク（例えば、電話ネットワーク）を介して、コンタクトセンターによって提供されるサービスや機能にアクセスすることが必要となる。アクセスリンクによって提供されるアクセスは、通信量に比例する必要がある。また、アクセスリンクを貸し出すためのコストは高価であることも多い。

コンタクトセンター側８において、提供される機能、アプリケーションやサービスのそれぞれは、特定のシステム７ａ、７ｂ、７ｃ、７ｄに形成される。異なるシステムを、所有されるＣＴＩ（computer telephony integration）リンク６へ形成するためには、アクセスリンク上のプロトコルへのＡＰＩや拡張が必要となり、システムの統合が複雑になる。複雑化のために、機能、アプリケーションやサービスシステムの変形が困難で複雑となり、新たな特徴や能力が遅延する。更に、そのような従来のコンタクトセンター８の形成には、使用されているハードウェアプラットフォームの能力を超えた資源（resource）が必要となる。また、ボードやサーバーの追加は、複雑かつ高価になる。

図４は、図３に示した従来技術におけるコンタクトセンターシステム２００と、本実施例のコンタクトセンターシステム１００を比較するための図である。従来技術におけるコンタクトセンターシステム２００と、本実施例におけるコンタクトセンターシステムの相違の１つは、システム１００が形成されかつ予見される（コミュニケーション）アクセスチャンネルを用いて、ユーザーコンタクトを促進し豊富なものにするために、ＩＭＳネットワークアーキテクチャを用いる点である。これにより、従来技術におけるコンタクトセンターシステム２００の技術的制約に対応することができる。例えば、図４に示すように、従来のコンタクトセンターシステム２００においては、それぞれのアクセスチャネルがそれぞれのサービスやアプリケーション毎に別々に考慮される必要がある。特に、それぞれのアクセスチャネルは、対応するアクセスチャネルを通じて入ってくるユーザーリクエスト（user request）を管理するために、独自に構成されなければならない。これに対して、コンタクトセンターシステム１００においては、異なる複数のアクセスチャネルからのユーザーリクエストを管理するために、１のサービスまたはアプリケーションが必要とされるのみである。言い換えれば、ユーザー要求を処理するために要求される異なる機能のための複数のサービスを含むＩＭＳアプリケーションサーバー１０を提供することにより、ユーザーリクエストは、ユーザーによって使用されるいずれのアクセスチャネルのためであっても、独自に、処理され実行され得る（例えば、処理がチャネルと独立である）。

図５は、サービスレイヤー２、制御及び伝達レイヤー３、アクセスレイヤー４を含むＩＭＳネットワーク（アーキテクチャ）１の一例を示す。ＩＭＳネットワークアーキテクチャは、複数の異なる種類のネットワークのための共通のコア及び伝達手段によって実現されるＩＰに基づいたサービスを伝達するための標準化された手段である。１以上のサービスが、サービスレイヤー２におけるアプリケーションサーバーで実行される。制御及び伝達レイヤー３（即ち、共通のコア及び伝達手段）は、アクセスを制御し、データや情報を１以上のユーザーにより異なるアクセスチャネルを通じてアクセスされるアプリケーションサーバーのサービスへ伝達またはそれらから伝達するための共通の機能を提供する。制御及び伝達レイヤー３によって提供される機能は、それぞれのアプリケーションサーバーやＩＭＳネットワーク１に提供される更なるサービスによって再使用されてもよい。また、制御及び伝達レイヤー３はアクセスに関して独立である。したがって、サービスレイヤー２のアプリケーションサーバーからのサービスは、１以上の種類のアクセスチャネル（またはアクセス技術）を介してユーザーに伝達される。制御及び伝達レイヤー３は、一貫して、有線や無線のコミニケーションアクセスチャネルを通じて、例えば、電話やインターネットプロトコル上の音声（VoIP）、ＴＤＭ、ワークステーション、パーソナルコンピュータ、Ｗｅｂ、ノートパソコン、携帯情報端末、携帯電話に関するコミニケーションチャネル（communication channel）や電話線を通じて、作動する。

図５に示すように、（コンタクトセンターシステムやアプリケーションのための）ＩＭＳアプリケーションサーバー１０は、コンタクトセンターのサービスがＩＭＳネットワーク１におけるサービスとなるように、ＩＭＳネットワーク１におけるサービスレイヤー２に設置され形成される。また、上記サービスはＩＭＳアプリケーションサーバー１０で処理され実行される。結果として、従来技術と異なり、コンタクトセンターサービスは、それぞれのアクセスチャネルに対応する具体的なアプリケーションやシステムに関連しない。ＩＭＳアプリケーションサーバー１０をサービスレイヤー２におけるＩＭＳネットワーク１の一部として提供することにより、コンタクトセンターサービスやあり得る更なるサービスへのコールフロー（call flow）は最適化され、新たなアプリケーションやサービスモデル、例えばホストコンタクトセンターサービス（hosted contact center service）が実現可能となる。

図６は、更なるＩＭＳアプリケーション（アーキテクチャ）１の一例を示す。ＩＭＳアプリケーションサーバー１０は、例えば、少なくとも１のユーザーデータベース９ａやオペレーションサポートシステム（OSS）、ビジネスサポートシステム（BSS）９ｂや、その他１以上のコンタクトセンターのシステムへのアクセスを持つ。ＩＭＳネットワークのサービスレイヤー２にＩＭＳアプリケーションサーバーを提供することにより、１組のビジネス（及び／又は計算）論理が、異なるアクセスチャネルからのユーザーリクエストへの応答を処理し、実行する。更に、ＩＭＳアプリケーションサーバーをＩＭＳネットワークのサービスレイヤー２に提供することによって、１以上の外部アプリケーションサーバー、例えばセッション確立プロトコル（ＳＩＰ）を用いたアプリケーションサーバーが、ＩＭＳアプリケーションサーバー１０を通じて提供されるサービスへの高められた機能（例えば、仮想アシスタントを有するチャットサービス）を提供するためにアクセスされる。更に、複数の異なる種類のマルチメディア資源機能（multimedia resource function）（MRF）が、ＩＭＳアプリケーションサーバー１０に提供され得る。

上記のように、制御及び伝達レイヤー３は、異なるアクセスチャネルを通じて１以上のユーザーからアクセスされるアプリケーションサーバーのサービスへの、または、それらからのデータや情報を伝達しアクセスを制御するための共通の機能を提供する。よって、制御及び伝達レイヤー３は、１以上のアクセスチャネル（またはアクセス技術）を通じて、サービスレイヤー２のアプリケーションから、アクセスレイヤー４におけるユーザーへサービスを提供する。例えば、アクセスレイヤー４は、ユーザーにＩＭＳアプリケーションサーバー１０へのアクセスを提供する様々な領域、例えばＰＬＭＮ、ＰＳＴＮ、ＶｏＩＰ、ＩＭＳを含む。当該領域は、ＮＮＩ（ネットワークネットワークインターフェース）を介した制御及び伝達レイヤー３のインターフェースとして機能し、エージェントサイト（agent site）は、ＵＮＩ（ユーザーネットワークインターフェース）を介した制御及び伝達レイヤー３のインターフェースとして機能する。

図７は、３つのレイヤーにおけるＩＭＳネットワーク１によって提供される１以上の要素や機能とＩＭＳアプリケーションサーバー１０の相互作用の一例を示す。なお、ここで、レイヤー３は、２つのサブレイヤー３ａ、３ｂを含む。サービスレイヤー２は、ＩＭＳアプリケーションサーバー１０を含む１以上のアプリケーションサーバーによって提供される１以上のサービスのホストとして機能するとともに、当該サービスを実行する。制御レイヤー３ａは、ＳＩＰセッションのための制御及びルーティング機能を提供する。更に、制御レイヤー３ａは、例えば、ユーザーやサービス等のＩＭＳユニット間やその他の領域間のコミュニケーションを（例えば、ＰＳＴＮやＰＬＭＮを介して）可能とする。伝達レイヤー３ｂは、制御レイヤー３ａとアクセスレイヤー４に接続される。伝達レイヤー３ｂとアクセスレイヤー４は、サービスレイヤー２に提供されるサービスへのアクセスを可能とするために、１以上のユーザーによって使用される１以上の装置へのＩＰ接続を提供する。

１の実施例においては、制御レイヤー３ａは、後に詳述するホームサブスクライブサーバ（(Home Subscriber Server)（HSS））２１４、サブスクライバーロケーション機能（Subscriber Location Function (SLF)）２２２、プロキシコールセッション制御機能（Proxy-Call Session Control Function）（P-CSCF））２１１、インターロゲイティングコールセッション制御機能（Interrogating-Call Session Control Function（I-CSCF）２１３、サービングコールセッション制御機能（Serving-Call Session Control Function）(S-CSCF)）２１５、メディアリソース機能コントローラー（Media Resource Function Controller(MRFC)）２１６、ブレイクアウトゲートウェイ制御機能（Breakout Gateway Control Function(BGCF)）２２３、メディアゲートウェイコントローラー機能（Media Gateway Controller Function(MGCF)）２２１、及びシグナリングゲートウェイ（Signaling Gateway(SGW)）２２０を含む。伝達レイヤー３ｂは、メディアリソース機能プロセッサ（（Media Resource Function Processor(MRFP)）２１７ 及び メディアゲートウェイ（（Media Gateway(MGW)）２１８を含む。

ＩＰマルチメディアネットワーク（サブシステム）またはＩＭＳネットワーク１は、標準化されたインターフェースによって関連付けられた異なる機能の集合を含んでもよい。これはグループ化した際に１のＩＭＳ（管理）ネットワークを形成する。ＩＭＳネットワーク１において作動する１の機能は、１のノード（ハードウェア機器）にあるわけではない。つまり、１の端末における２の機能は自由に結合され、または、１の機能は２以上の端末に自由に分配できる。それぞれのノードは、また負担のバランスや組織的課題の観点により、１のネットワークにおいて複数回使用されてもよい。

ユーザーは、標準のインターネットプロトコル（IP）を使用する様々な方法で、ＩＭＳネットワークに接続することができる。直接ＩＭＳ端末（Direct IMS terminal）（例えば、携帯電話、パーソナルデジタルアシスタント（PDA）やコンピュータ）は、たとえ別のネットワークや国（訪問ネットワーク）においてローミング（roaming）されている場合であっても、直接ＩＭＳネットワークに登録できる。要件の１つは、それらが、ＩＰｖ６（初期のＩＭＳにおいてはＩＰｖ４）を使用し、セッション確立プロトコルユーザーエージェント（Session Initial Protocol (SIP) user agent）で動作することができることである。固定アクセス（Fixed access）（例えば、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＧＰＲＳ）や無線アクセス（例えば、ＷＬＡＮ、ＷｉＭＡＸ）は全てサポートされる。プレーンな初期の電話サービス（ＰＯＴＳ、初期のアナログ電話）、Ｈ．３２３やＩＭＳに対応していないＶｏＩＰシステムのようなその他の電話システムは、ゲートウェイを介してサポートされる。

ホームサブスクライブサーバー（Home Subscriber Server（HSS））やユーザープロファイルサーバ機能（User Profile Server Function（UPSF））は、実際に要求を扱うＩＭＳネットワーク実態をサポートするマスターユーザーデータベース（master user database）である。それは、サブスクリプションに関する情報（サブスクライバープロファイル（subscriber profile））を含み、ユーザー認証とユーザーの許可を実行し、サブスクライバーの位置とＩＰ情報についての情報を提供する。それは、ＧＳＭホームロケーションレジスタ(GSM Home Location Register（HLR）))や認証センター（Authentication Center (AUC)）に類似する。

サブスクライバーロケーション機能(Subscriber Location Function (SLF))は、複数のＨＳＳが使用される際、ユーザーアドレスをマッピングするために必要となる。ＨＳＳとＳＬＦの両者は、Ｄｉａｍｅｔｅｒプロトコルを介してコミュニケーションを行う。このＤｉａｍｅｔｅｒは、ＡＡＡ（Authentication、 Accounting and Authorization）プロトコルとも称される。通常の３ＧＰＰネットワークはＩＭＳＩ（International Mobile Subscriber Identity）、ＴＭＳＩ（Temporary Mobile Subscriber Identity）、ＩＭＥＩ（International Mobile Equipment Identity）、ＭＳＩＳＤＮ（Mobile Subscriber ISDN Number）のアイデンティティ（identity）を用いる。

ＩＭＳＩは、ＳＩＭに保存される独自の電話識別子である。プライバシーを改善するため、ＴＭＳＩは地理的な位置に応じて生じる。ＩＭＳＩやＴＭＳＩがユーザーの識別に用いられる一方、ＩＭＥＩは、独自の装置識別子であり、電話に応じたものである。ＭＳＩＳＤＮは、ユーザーの電話番号である。

ＩＭＳは、またＩＰマルチメディアプライベートアイデンティティ（IP Multimedia Private Identity (IMPI)）及びＩＰマルチメディアパブリックアイデンティティ（IP Multimedia Public Identity (IMPU)）を要求する。両者は、電話番号やその他の数字の列ではなく、ユニフォームリソース識別子（Uniform Resource Identifiers (URIs)）であって、数字（tel:+1-555-123-4567のようなtel-ＵＲＩ）や、英数字の識別子（sip:john.doe@example.com のようなsip-ＵＲＩ）であってもよい。また、複数のＩＭＰＵやＩＭＰＩであってもよい。ＩＭＰＵは別の電話と共有され、両者は同じ識別子（例えば、ファミリー全体における１の電話番号）に到達する。

ＨＳＳサブスクライバーデータベース（HSS subscriber database）は、ＩＭＰＵ、ＩＭＰＩ、ＩＭＳＩ、ＭＳＩＳＤＮサブスクライバーサービスプロファイル（subscriber service profiles）、サービストリガー（service trigger）、その他の情報を含む。

コールセッションコントロール機能（Call Session Control Function (CSCF)）と呼ばれる、セッション確立プロトコル（Session Inititial Protocol (SIP)）サーバーやプロキシの役割の集合的な役割は、ＩＭＳにおけるＳＩＰ信号パケットを処理するために用いられる。

・プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）は、ＩＭＳ端末のコンタクトの最初のポイントとなるＳＩＰプロキシである。それは、訪問ネットワーク（visited network）（ＩＭＳネットワーク全体）または、（訪問ネットワークがＩＭＳに準拠していない場合）ホームネットワークに位置する。ネットワークによっては、この機能のためにセッションボーダーコントローラー（Session Border Controller）を使用し得る。端末は、そのＰ−ＣＳＣＦをＤＨＣＰとともに発見するか、または、それは（一般パケットラジオサービス（General Packet Radio Service (GPRS)の中の）ＰＤＰコンテクストの中に割り当てられる。
・Ｐ−ＣＳＣＦは、登録中にＩＭＳ端末に割り当てられ、登録期間の間には変化しない。
・Ｐ−ＣＳＣＦは、信号メッセージ上のパスに存在し、全てのメッセージを検査する。
・Ｐ−ＣＳＣＦは、ユーザー認証するとともに、ユーザー端末とＩＰｓｅｃセキュリティアソシエーション（IPsec security association）を構築する。これは、スプーフィング攻撃（spoofing attack）やリプレイ攻撃（replay attacks）を防止し、ユーザーのプライバシーを保護する。その他のノードは、Ｐ-ＣＳＣＦを信頼し、ユーザー認証を再度行う必要はない。
・Ｐ−ＣＳＣＦは、ＳｉｇＣｏｍｐを用いてＳＩＰメッセージを圧縮解凍することができる。これは遅いラジオリンク（radio link）の往復を減少することができる。
・Ｐ−ＣＳＣＦは、メディアプレーンリソース（media plane resource）、例えば、メディアプレーンを介したサービスの質（Qos）を許可するポリシー決定機能（Policy Decision Function (PDF)）を含んでもよい。それは例えばポリシー制御やバンド幅の管理等のために用いられる。ＰＤＦは別の機能であり得る。
・Ｐ−ＣＳＣＦは、課金記録を生じる。

・サービングＣＳＣＦ（Serving-CSCF (S-CSCF)）はシグナリングプレーン（signalling plane）の中心のノードである。サービングＣＳＣＦは、ＳＩＰサーバーであるが、セッション制御も行う。それは、ホームネットワークに常駐する。サービングＣＳＣＦは、ユーザープロファイルをダウンロードまたはアップロードするために、ＨＳＳへのＤｉａｍｅｔｅｒ ＣｘやＤｘインターフェースを使用する。つまり、サービングＣＳＣＦは、ユーザーのローカル記憶手段をもたない。全ての必要な情報はＨＳＳからロードされる。
・Ｓ−ＣＳＣＦは、ＳＩＰ登録（SIP registration）を扱い、ＳＩＰ登録はＳ−ＣＳＣＦに、ユーザー位置（例えば、端末のＩＰアドレス）とＳＩＰアドレスを拘束することを許可する。
・Ｓ−ＣＳＣＦは、全ての信号メッセージのパスにあり、全てのメッセージを検査する。
・Ｓ−ＣＳＣＦは、そのサービスを提供するために、どのアプリケーションサーバーにＳＩＰメッセージを送るかを決定する。
・Ｓ−ＣＳＣＦは、典型的には電子的番号ルックアップ（Electronic Numbering (ENUM) lookup）を用いてルーティングサービス（routing services）を提供する。
・Ｓ−ＣＳＣＦは、ネットワークオペレータのポリシー（policy）を実行する。
・ロード分配（load distribution）や高い利用可能性の理由のためにネットワーク上に複数のＳ−ＣＳＣＦが存在し得る。それは、Ｉ−ＣＳＣＦによって問い合わせられた際に、Ｓ−ＣＳＣＦを割り当てるＨＳＳである。

・インターロゲイティングＣＳＣＦ（Interrogating-CSCF (I-CSCF)）は、管理ドメインの端に配置される別のＳＩＰ機能である。そのＩＰアドレスは、そのドメインのドメインネームシステム（Domain Name System (DNS)）に（ＮＡＰＴＲやＤＮＳ記録のＳＲＶタイプを用いて）公開される。よって、リモートサーバがそれを発見し、ＳＩＰパケットを当該ドメインへフォワードするためのポイント（例えば登録（registering））として用いることができる。Ｉ−ＣＳＣＦは、ユーザー位置を検索するために、Ｄｉａｍｅｔｅｒ Ｃｘインターフェースを用いてＨＳＳに問い合わせる（Ｄｘインターフェースは必要なＨＳＳのみをＩ−ＣＳＣＦからＳＬＦへ位置させるために用いられる）。そして、ＳＩＰ要求の、それが割り当てられたＳ−ＣＳＣＦへの経路を定める。Ｉ−ＣＳＣＦは外部から内部ネットワークをリリース（Release）６まで隠す（ＳＩＰメッセージの一部を保護する）ためにも用いることができる。この場合、それはトポロジーハイディングインターネットワーク（Topology Hiding Inter-network Gateway (THIG)）と称される。次のリリース（Release）７から、この「エントリーポイント」機能はＩ−ＣＳＣＦから除かれ、インターコネクションボーダー制御機能（Interconnection Border Control Function (IBCF)）の一部となる。ＩＢＣＦは、外部ネットワークへのゲートウェイとして用いられ、ＮＡＴ及びファイアウォール機能（ピンホールディング（(pinholding)）を提供する。

アプリケーションサーバー（ＡＳ）はホストとして機能するとともに、サービスを提供し、セッション確立プロトコル（Session Initiation Protocol (SIP)）を用いてＳ−ＣＳＣＦとのインターフェースとして機能する。現在開発されているアプリケーションサーバーの一例は、コールコンティニュイティ機能（call continuity Function (VCC Server)）である。実際のサービスによって、ＡＳはＳＩＰプロキシモード、ＳＩＰ ＵＡ(user
agent)モード、またはＳＩＰ Ｂ２ＢＵＡ(back-to-back user agent)モードで動作する。アプリケーションサーバーは、ホームネットワークまたは外部の第三者ネットワークに設置することができる。ホームネットワークに設置される場合、アプリケーションサーバーは、（ＳＩＰ−ＡＳのための）Ｄｉａｍｅｔｅｒ Ｓｈインターフェースまたは（ＩＭ−ＳＳＦのための）モバイルアプリケーションパート（ＭＡＰ）インターフェースで、ＨＳＳに問い合わせることができる。

・ＳＩＰ ＡＳは特定のシステム用のＩＭＳアプリケーションサーバーである。
・ＩＰマルチメディアサービススイッチング機能（IP Multimedia Service Switching Function (IM-SSF)）は、ＣＡＰ（Camel Application Part）を用いるＣＡＭＥＬ（Customized Applications for Mobile networks Enhanced Logic）をもったＩＭ−ＳＳＦインターフェース（IM-SSF interface）である。
・ＯＳＡ−ＳＣＳ（Open Service Access-Service Capability Server ）は、ＯＳＡフレームワークアプリケーションサーバー（OSA framework Application Server）へのインターフェースである。

メディアリソース機能（Media Resource Function (MRF)）は、例えば、ボイスストリームミキシング（voice stream mixing）等のメディア操作や音調やアナウンスの再生に関するメディアに関連する機能を提供する。

それぞれのＭＲＦは、更に、メディアリソース機能コントローラー（Media Resource Function Controller (MRFC)）及びメディアリソース機能プロセッサ（Media Resource Function Processor (MRFP)）に分けられる。

・ＭＲＦＣは、Ｓ−ＣＳＣＦへのＳＩＰユーザーエージェントとして動作する信号プレーンノードであり、Ｈ．２４８インターフェースを介してＭＲＦＰを制御する。
・ＭＲＦＰは、全てのメディアに関する機能を実行するメディアプレーンノード（media plane node）である。

ＢＧＣＦは、（Breakout Gateway Control Function））は、電話番号に基づくルーティング機能を有するＳＩＰサーバである。これはＩＭＳから、例えば、パブリックスイッチ電話ネットワーク（Public Switched Telephone Network (PSTN)）やパブリックランドモバイルネットワーク（Public land mobile network (PLMN)）等のサーキットスイッチネットワーク（circuit switched network）の中の電話に電話がかけられた際にのみ使用される。

ＰＳＴＮ／ＣＳゲートウェイインターフェース（PSTN/CS gateway interface）は、ＰＳＴＮサーキットスイッチネットワーク（PSTN circuit switched (CS) networks）とのインターフェースとして機能する。信号伝達のために、ＣＳネットワークは、メッセージ伝達部（Message Transfer Part (MTP)）を通じて、ＩＳＤＮユーザー部（ISDN User Part (ISUP) (またはBICC)）を使用する一方、ＩＭＳは、ＩＰを通じて、セッション確立プロトコル（Session Initiation Protocol (SIP)）を使用する。メディアのためには、ＣＳネットワークは、パルスコードモジュレーション（ＰＣＭ）を使用する一方、ＩＭＳは実時間トランスポートプロトコル（Real-Time Transport Protocol (RTP)）を使用する。

・シグナリングゲートウェイ（Signalling Gateway (SGW)）は、ＣＳのシグナリングプレーンとのインターフェースとして機能する。ＳＧＷは、下位のレイヤープロトコルをストリームコントロールトランスミッションプロトコル（Stream Control Transmission Protocol (SCTPつまりan Internet Protocol (IP) protocol)）として、メッセージトランスファーパート（Message Transfer Part (MTPつまり Signalling System 7 (SS7) protocol)）に変換する。ＭＧＣＦからＣＳネットワークへＩＳＤＮユーザー部（ISDN User Part (ISUP)）を伝達するためである。
・メディアゲートウェイコントローラー機能（Media Gateway Controller Function (MGCF)）はＳＩＰとＩＳＵＰとの間のコールコントロールプロトコル変換（call control protocol conversion）を行い、ＳＣＴＰを通じてＳＧＷとのインターフェースとして機能する。
・メディアゲートウェイ（Media Gateway (MGW)）は、ＲＴＰとＰＣＭとの間の変換によって、ＣＳネットワークのメディアプレーンとのインターフェースとして機能する。
また、コーデックが一致しない場合にはコードを変換する（例えば、ＩＭＳはＡＭＲを使用、ＰＳＴＮはＧ．７１１を使用できる場合がある）。

メディアリソース（Media Resources）はメディアプレーン上で動作する要素であり、ＩＭＳコア機能（IMS Core function）、特にメディアサーバ（ＭＳ）やメディアゲートウェイ（ＭＧW）で制御される。

２つの次世代ネットワーキング接続（Next generation Networking Interconnection）がある。

・サービス適応接続（Service oriented Interconnection (SoIx)）は、ＭＧＮドメインの物理的論理的結合であって、キャリア（carrier）やサービスプロバイダ（service provider）が、ＭＧＮ（つまりＩＭＳやＰＥＳ）プラットフォームを通じて制御、（セッションに基づく）信号伝達し、サービスを提供可能とする。これは、定義されたレベルの内部操作性（interoperability）を提供する。例えば、ＩＰ接続（interconnection）を通じた「キャリアグレード（carrier grade）」音声やマルチメディアサービスの場合がある。「定義されたレベルの内部操作性（Defined levels of interoperability）」は、サービス、ＱｏＳ、安全性等に依存する。

・接続対応インターコネクション（Connectivity oriented Interconnection (CoIx)）とは、内部操作性に無関係な簡潔なＩＰ接続性に基づく、キャリアとサービスプロバイダとの物理的論理的結合である。例えば、この形式のＩＰ内部接続は、具体的な端末同士のサービスを関知せず、結果として、具体的なネットワーク実行（service specific network performance）、ＱｏＳ、安全性の要求は必ずしも保証されない。当該定義は、いくつかのサービスが内部操作性の定義されたレベルを提供することを除外するものではない。しかしながら、唯一ＳｏｌｘはＭＧＮ内部操作性に関する要求を十分に満たす。

ＮＧＮ内部接続モード（NGN interconnection mode）は、直接または間接なものである。直接接続とは、いずれの中間ネットワーク領域を介さずに２のネットワーク領域を内部接続することをいう。１のレイヤーにおける間接接続とは、中継ネットワークとして動作する１以上の中間ネットワーク領域とともに、２のネットワーク領域を接続することをいう。中間ネットワーク領域は、２の他のネットワーク領域への中継機能を提供する。異なる内部接続モードは、サービスレイヤー信号を伝達するためやメディア伝達のために用いられる。

オフライン課金は、定期的に（例えば、月末）サービスに対して支払うユーザーに対して実行される。クレジットに基づく課金として知られるオンライン課金は、プリペイドサービス、後払いについての実時間クレジット制御（real-time credit control）に用いられる。両者は同じセッション（session）に適用される。

・オフライン課金においては、セッションで用いられる全てのＳＩＰネットワークエンティティ（P-CSCF, I-CSCF, S-CSCF, BGCF, MRFC, MGCF, AS）は、同じ領域に位置する課金コレクター機能（Charging Collector Function (CCF)）へ会計情報を送るために、Ｄｉａｍｅｔｅｒ Ｒｆ インターフェースを、使用する。ＣＣＦは、全ての情報を集め、その領域の請求システム（billing system (BS)）に送るコール詳細記録（Call Detail Record (CDR)）を作成する。

各セッションは、独自の識別子としてのＩＭＳ課金識別子（IMS Charging Identifier (ICID)）を送る。インターオペレータ識別子（Inter Operator Identifier (IOI)）パラメータはネットワークの開始と終了を定義する。

各ドメインは、各課金ネットワークを有する。異なる領域の請求システム（billing system）は、ローミング課金が適用できるように、情報を交換する。

・オンライン課金については、Ｓ−ＣＳＣＦが、一般のＳＩＰアプリケーションサーバーのように、セッション課金機能（Session Charging Function (SCF)）と対話する。ＳＣＦは、ユーザーがセッション中にクレジットを使い果たした際にセッションを終了するために、Ｓ−ＣＳＣＦを送る。ＡＳとＭＲＦＣは、Ｄｉａｍｅｔｅｒ Ｒｏインターフェースを、イベント課金機能（Event Charging Function (ECF)）について用いる。

・即座のイベント課金（Immediate Event Charging (IEC)）が使用される場合、ＥＣＦによって、クレジットユニットがユーザーアカウント（口座）から引き落とされ、次にＭＲＣＦまたはＡＳがサービスを提供することを許可する。十分なクレジットユニットが利用できない場合には、サービスは許可されない。

・イベント課金ユニット予約（Event Charging with Unit Reservation (ECUR)）が使用される際、ＥＣＦはまずユーザーカウントのいくつかのクレジットユニットを予約し、それからＭＲＦＣまたはＡＳに許可する。サービスが終了した後、使用されたクレジットユニットが報告され、アカウントから引き落とされる。つまり予約されたクレジットユニットはそのとき明らかになる。

図７に示されるアーキテクチャのけるＩＭＳアプリケーションサーバー１０によって提供される少なくとも１のサービスにユーザーがアクセスするコールフローの一例を図８Ａ及び図８Ｂを参照しつつ説明する。

図８Ａは、例えば図２に示されたＩＭＳアクセスチャネル、認証、相互作用やセルフケアサービスを介して、ＩＭＳアプリケーションサーバー１０によって提供される少なくとも１のサービスへのユーザーアクセスを提供するためのＩＭＳアプリケーションサーバー１０のＩＭＳネットワーク（アーキテクチャ）１との相互作用を示す。例えば、ＩＭＳアプリケーションサーバー１０がアクセス可能な複数の異なるアクセスチャネルは、１以上の異なるプロトコル（例えば、ISDN, VoiceIP, UMTS, and GPRS）や１以上の異なる物理的接続（例えば、電話接続、携帯電話接続、ＴＶ接続（TV enabled connections））を有する。なお、アクセスチャネルは有線若しくは無線であってもよい。

Ｓ１においては、ユーザー２０は、サービス番号（例えば、ＩＭＳアプリケーションサーバー１０を介して提供されるコンタクトセンターのカスタマーケア番号）に電話する。ユーザーリクエストは、プロキシコールセッション制御機能（proxy-call session control function (P-CSCF)）２１１に送られる。プロキシコールセッション制御機能は、ユーザー要求を、Ｓ２で、サービングセッション制御機能部（serving-call session control function (S-CSCF)）２１２へ送る。Ｓ−ＣＳＣＦ２１２は、ユーザーリクエストを送ったユーザー２０のプロファイルを確認し、その後、Ｓ３において、ユーザーリクエストをインターロゲイティングコールセッション制御機能部（interrogating-call session control function (I-CSCF)）２１３に送る。Ｓ４においては、Ｉ−ＣＳＣＦ２１３は、ホームサブスクライバーサービス部（home subscriber service (HSS)）２１４から、例えばＩＭＳアプリケーションサーバー１０のコンタクトセンターサービスを管理するＳ−ＣＳＣＦ２１５のアドレスを検索する。Ｓ５においては、Ｉ−ＣＳＣＦ２１３は、ユーザーリクエストＳ−ＣＳＣＦ２１５に送る。Ｓ６においては、Ｓ−ＣＳＣＦ２１５は、ユーザーリクエストに対応するユーザー２０のプロファイルを確認し、ユーザーリクエストをＩＭＳアプリケーションサーバー１０に送る。Ｓ７においては、ＩＭＳアプリケーションサーバー１０は、ＩＭＳアプリケーションサーバー１０で要求されるサービスのサービス論理を用いて、マルチメディアリソース機能コントローラー（multimedia resource function controller (MRFC)）２１６を制御または管理する。次に、ユーザーリクエストをＭＲＦＣ２１６へ送る。最後にＳ８において、上記サービス論理に応じて、ＭＲＦＣ２１６は、要求された情報やデータをユーザー２０へ提供するために、ユーザー２０によって使用される装置へのマルチメディアリソース機能プロセッサ（multimedia resource function processor (MRFP)）２１７を介したメディア（アクセス）チャネルを生成する。

図８Ｂは、例えば図２に示すＰＬＭＮ（public land mobile network）アクセスチャネル、認証、相互作用やセルフサービスを介して、ＩＭＳアプリケーションサーバー１０によって提供される少なくとも１のサービスへのユーザーアクセスを提供するためのＩＭＳアプリケーションサーバー１０のＩＭＳネットワーク１との相互作用の一例を示す。

Ｓ１１においては、ユーザー２０はサービス番号（例えば、ＩＭＳアプリケーションサーバー１０を介して提供されるコンタクト線たのカスタマーケア番号）に電話する。ＰＬＭＮネットワークは、ユーザーリクエストがＩＭＳ領域に属することを認識し、Ｓ１２において、シグナリングゲートウェイ機能部（signaling gateway function (SGW)）２２０を介して、メディアゲートウェイ制御機能部（media gateway control function (MGCF)）２２１へユーザーリクエストを送る。Ｓ１３においては、ＭＧＣＦ２２１は、ユーザーリクエストを、インターロゲイティングコールセッション制御機能部（interrogating-call session control function (I-CSCF)）２１３に送る。Ｓ１４においては、Ｉ−ＣＳＣＦ２１３は、ホームサブスクライバーサーバ（home subscriber server (HSS)）１１４からサービング制御機能部（serving-call session control function (S-CSCF)）２１５を検索する。Ｓ１５においては、Ｉ−ＣＳＣＦ２１３は、ＨＳＳ２１４から検索されたアドレスを用いてユーザーリクエストをＳ−ＣＳＣＦ２１５へ送信する。Ｓ−ＣＳＣＦ２１５は、ＩＭＳアプリケーションサーバー１０からコンタクトセンターサービスを管理する。Ｓ１６においては、Ｓ−ＣＳＣＦ２１５は、ユーザーリクエストを送ったユーザー２０のプロファイルを確認し、当該ユーザーリクエストをＩＭＳアプリケーションサーバー１０へ送る。ＩＭＳアプリケーションサーバー１０は、Ｓ１７において、そのビジネスロジックを用いて、Ｓ−ＣＳＣＦ２１５を介し、マルチメディアリソース機能コントローラ（multimedia resource function controller (MRFC)）２１６を管理及び制御し、Ｓ１８においてユーザーリクエストをＭＲＦＣ２１６へ送る。ＩＭＳアプリケーションサーバー１０のビジネス論理に応じて、ＭＲＦＣ２１６は、Ｓ１９でメディアゲートウェイ（media gateway (MGW) ）２１８を用いるメディアチャネルを、ユーザーリクエストへの応答を提供するために、マルチメディアリソース機能プロセッサ（multimedia resource function processor (MRFP)）を介してユーザーによって使用される装置で、生成する。

図９Ａは、ＩＭＳアプリケーションサーバー１０のアーキテクチャの一例を示す。ＩＭＳアプリケーションサーバー１０は、サービス論理レイヤー１２０、コミュニケーションレイヤー１３０、サービス生成レイヤー１４０、データレイヤー１５０、モニタリングレイヤー１６０を有するサービス実行レイヤー１１０を含む。コミュニケーションレイヤー１３０は、１以上のネットワークアダプタインターフェース、例えば、ＭＲＦアダプタ１３１やＩＭＳアダプタ１３３を含む。更に、コミュニケーションレイヤーは、１以上のシステムアダプタ、例えば、ＪＤＢＣ、ＳＯＡＰ、ＣＯＲＢＡ、を含む。ＪＤＢＣ（Java（登録商標） Database Connectivity）は、どのようにクライアントがデータベースにアクセスするかを定義するＪＡＢＡプログラミング言語のためのＡＰＩである。ＪＤＢＣは、データベースにおいて、問い合わせやデータのアップデートのための方法を提供する。ＳＯＡＰ(Simple Object Protocol)は、ネットワークを算出する際のＷＥＢサービスの実装に関する構造化された情報を交換するためのプロトコルの詳細である。ＣＯＲＢＡ(Common Object Requesting Broker Architecture)は、複数の言語で記載され、複数のコンピュータとともに動作するソフトウェア要素を実現するための標準技術である。データレイヤー１５０は、ＩＭＳアプリケーションサーバー１０を通じて提供されるデータや情報を格納するためのサービス格納部を含んでもよい。モニタリングレイヤー１６０は、警告機能、ＩＭＳアプリケーションサーバー１０やＩＭＳアプリケーションサーバー１０によって提供されるサービス監視機能を有する。更に、モニタリングレイヤーは、ユーザー管理やＩＭＳアプリケーションサーバー１０によって提供される少なくとも１のサービスを制御するための管理端末を介したモニタリング機能へのアクセスを提供する。通常のアプリケーションサーバーと比較してＩＭＳアプリケーションサーバー１０特有であるサービス論理レイヤー１２０及びサービス生成レイヤー１４０については、図９Ｂ乃至９Ｆにより詳細に説明する。

図９Ｂは、ＩＭＳアプリケーションサーバー１０の別のアーキテクチャの一例を示す。図９Ｂにおいては、１以上のサービス部１２１乃至１２６を有するサービス論理レイヤー１２０及び１以上のコミュニケーション部（アダプタ）１３１乃至１３３を有するコミュニケーションレイヤー１３０はサービス実行レイヤー１１０に実装される。

サービス生成レイヤー１４０とサービス実行レイヤーについては図９Ｃ乃至９Ｆを用いてより詳細に説明する。

図９Ｃは、ＩＭＳアプリケーションサーバー１０のサービス生成レイヤー１４０の形成の一例を示す。サービス生成レイヤー１４０は、ＩＭＳアプリケーションサーバー１０によってサポートされ得るサービスを設計、テスト、展開するために、ユーザー、開発者、管理者をサポートする。サービス生成レイヤー１４０は、アクセス管理部１４１、サービス設計部１４２、ライフサイクル管理部１４３、サービス管理部１４４を有する。

アクセス管理部１４１は、ＩＭＳアプリケーションサーバー１０でサービスを要求するユーザーのユーザープロファイルやＩＭＳアプリケーションサーバー１０のアカウントを管理する。ＩＭＳアプリケーションサーバー１０を介して提供されるサービス（例えばコンタクトセンターサービス）のユーザーは、１以上のテナント（tenant）を生成する。別のユーザーは、テナントから１以上のグループを生成してもよい。更に、その他のユーザーは、当該グループに属する１以上のユーザーを管理してもよい。更に、アクセス管理部１４１は、ＩＭＳアプリケーションサーバー１０によって提供される１以上のアプリケーションやサービスを設計、管理する際、ユーザーや設計者をサポートする。当該アプリケーションやサービスは、ユーザー、例えば許可者、によって有効化、管理される。

サービス設計部１４２は、アプリケーションやサービスを設計、管理するための環境やグラフィカルユーザーインターフェース（graphical user interface）を含む。サービス設計部１４２は、例えばグラフ構造等のフロー図を用いて、アプリケーションやサービスを提供するための１以上の予め定義されたノードタイプ（node type）やドラッグドロップ機能（drag and drop functionality）を提供する。

ライフサイクル管理部１４３は、サービスやアプリケーションの設計期間、つまりサービスやアプリケーションがＩＭＳアプリケーションサーバー１０のサービス実行レイヤー１１０に展開される前に、アプリケーションやサービスのためのライフサイクル論理を形成する。

サービス管理部１４４は、サービス管理を可能にし、サポートするよう構成され、サービスやアプリケーションの詳細の選択、図の形成、有効化、表示、無効化、削除等を行う。

図９Ｄは、サービス生成レイヤー１４０を用いて新たなサービスやアプリケーションを生成する例を示す。同図に示されるように、サービス生成レイヤー１４０は、技術者でなくともＩＭＳアプリケーションサーバー１０で提供されるサービスやアプリケーションを設計、管理、展開できるユーザーフレンドリーでＷＥＢに基づいたツール（以下、サービス生成環境という）を提供する。例えば、サービス生成環境を用いて、ユーザーは容易にＩＭＳアプリケーションサーバー１０で実現されるコンタクトセンターサービスと相互動作することができる。

図９Ｄに示されるように、サービス生成環境の中で、ＩＭＳアプリケーションサーバー１０でサービスを要求するユーザーとの相互作用のためのサービスやアプリケーションのビジネス論理(business logic)を設計や管理するために、ドラッグドロップ機能はサービス生成レイヤー１４０によってサポートされる。ビジネス論理は、セルフサービスや入ってくるユーザー要求を問い合わせる問い合わせ論理を含む。更に、サービス生成環境は、複数のノードタイプを有する（知的）ノードライブラリ（(intelligent) node library）を提供する。これにより、サービスやアプリケーションとユーザーの相互作用を補助するための入出力データ管理が簡素化される。更に、サービスやアプリケーションのためのビジネス論理は木構造の代わりにグラフ構造を用いて、見えるように生成される。したがって、同じアプリケーションを同じまたは異なるサービスにおいて再度使用することができる。

図９ＥはＩＭＳアプリケーションサーバー１０のサービス実行レイヤー１１０におけるコミュニケーション部（レイヤー）の構成の一例を示す。コミュニケーション部（レイヤー）１３０は、ＩＭＳアプリケーションサーバー１０と外部装置、外部ＯＳ(operation support)、ＢＳ(business support)システム、ＩＭＳネットワークの管理部を管理するための管理部のサービス間のコミュニケーションをサポートするアダプタ１３１、１３２、１３３を有する。

１の実施例においては、サービス実行レイヤー１１０のコミュニケーション部（レイヤー）１３０は、マルチメディアリソース機能（multimedia resource function (MRF)）アダプタ１３１１、コールセッション制御機能（call session control function (CSCF)）アダプタ１３２、知的ネットワーク管理センター（intelligent network management center (IMC)）を有する。ＭＲＦアダプタ１３１は、例えば、ＩＭＳアプリケーションサーバー１０とＭＲＦ間でＶｘｍｌファイルを交換することにより、ｈｔｔｐコミュニケーションをサポートする。ＣＳＣＦアダプタ１３２は、セッション確立プロトコル（session initiation protocol (SIP)）コミュニケーションをサポートし、ＩＭＣアダプタ１３３はＳＮＭＰコミュニケーションをサポートする。

ＭＲＦアダプタは例えば、アナウンスや、メディアコード変換、会議の実行といった補助、適応に関する側面のために使用される。

ＣＳＣＦアダプタは、サブスクライバーを処理する責任を有するＩＭＳエンティティであって、アプリケーションサーバーは、ＳＩＰメッセージの形式がいずれであるか要求する。具体的要求に応じて、要求を処理する際１以上のＣＳＣＦ、例えば、Ｐ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦが使用される。

ＩＭＣアダプタはＳＮＭＰ(simple network management protocol)に適合させるために用いられる。ＳＮＭＰは、ＴＣＰ／ＩＰ(Transmission Control Protocol/Internet Protocol)スイートの一部であって、ＩＰゲートウェイやその他のネットワーク機能を制御管理するために用いられる。

図９Ｆは、ＩＭＳアプリケーションサーバー１０のサービス実行レイヤー１１０におけるサービス論理部１２１乃至１２６の形成の一例を示す。サービス論理部１２１乃至１２６はサービス生成レイヤーで設計されたサービスやアプリケーションを実行する。（フロー）図は、ＭＲＦアダプタ１３１へ提供されるＶＸＭＬ(Voice XML)ファイルを介して管理される。

サービス実行レイヤー１１０は、構成の一例として、展開管理部１２１、ブロック作成ライブラリ１２２、ルールエンジン部１２３、セッション管理部１２４、キャッシュ部１２５、監視管理部１２６を有する。展開管理部１２１は、サービスの展開や除去、サービスのバージョンを管理する。ブロック作成ライブラリ部１２２は、Ｊａｖａ（登録商標）ライブラリ格納部として形成され、ノードタイプについての動作をサポートする。ブロック作成ライブラリ部は、サービス生成レイヤー１４０におけるサービスの設計やサービス論理レイヤー１２０におけるサービスの実行に用いられる。ルールエンジン部１２３は、サービスを実行するためのルールを有する。セッション管理部１２４は、サービスの実行期間、Ｅ２Ｅ（enterprise-to-enterprise）セッションを管理する。セッション管理部１２４は、セッション処理部及びサービス管理部を含んでもよい。セッション処理部はセッションのセットアップやセッションを終了し、時間切れを管理してもよい。サービス管理部は、セッション処理部やルールエンジン部１２３上で動作してもよいし、実行されるサービスのための処理論理に形成されてもよい。キャッシュ部１２５は、セッション情報を有するキャッシュシステムである。監視管理部１２６は、システムの欠陥や処理データを外部のサーバーへ提供し警告を処理する。

図１０は、ＩＰＴＶを用いてサービスを要求するためにＩＭＳアプリケーションサーバー１０へユーザーがコンタクトする際におけるＩＭＳアプリケーションサーバー１０の使用例の一例を示す。Ｓ２１でＩＰＴＶを介して、ユーザー２０は、ＩＭＳアプリケーションサーバー１０にコンタクトする。例えば、購入したビデオオンデマンドサービスの質が悪いとクレームする。Ｓ２２及びＳ２３においては、ビデオオンデマンドサービスの質がまず、要求され、それから確認される。Ｓ２４及びＳ２５においては、ＩＭＳアプリケーションサーバー１０は、質の悪いビデオオンデマンドサービスに関するコストを除くように要求する。最後に、Ｓ２６において、ユーザー２０は、ユーザー２０のＩＰＴＶ装置へ、当該ユーザー要求への応答を送ることにより、当該分析について報告され、Ｓ２７において、ユーザーに返金される。

図１１は、顧客が企業であって、コンタクトセンターサービスにかかる遠距離通信サービスを提供するプロバイダーのためのＩＭＳアプリケーションサーバー１０の実装の一例を示す。ＩＭＳアプリケーションサーバー１０は複数のサービスのホストとして機能する。例えば、それぞれの遠距離通信ビジネス部は、自身のサービスつまり対応するサービス論理を設計する各サービス生成環境を有する。

当該サービスは、次に外部の顧客へサービスを提供、販売するのに用いられる。外部の顧客は、（実質的に）遠距離通信ビジネス部と独立した対応するサービス論理を用いて、自身のサービスを設計、展開する。さらに、それぞれの顧客は、そのブランドに応じて加工された別のサービス生成環境を提供される。

結果として、遠隔通信部によって生成展開された以前から存在するサービスは顧客によって生成されたサービスに影響を与えない。

図１２を参照して、本発明を実装するためのシステムの一例を示す。当該システムは、従来技術におけるコンピュータ環境４２０（例えばパーソナルコンピュータ）の形式における汎用的なコンピュータ装置であって、処理部４２２、システムメモリ４２４、システムバス４２６を有する。また、当該システムは、様々なシステム要素、例えばシステムメモリ４２４乃至処理部４２２に接続される。処理部４２２は、システムメモリ４２４にアクセスすることにより、算術、論理、制御動作を行う。システムメモリ４２４は、処理部４２２とともに使用される情報や指示を格納する。システムメモリ４２４は、例えば、ＲＡＭ（random access memory）４２８やＲＯＭ（read only memory）４３０のような揮発性や不揮発性メモリを有してもよい。例えば起動時にコンピュータ環境（パーソナルコンピュータ）４２０内の要素間における情報伝達を補助する基本的なルーチンを含むＢＩＯＳ（basic input/output system）は、ＲＯＭ４３０に格納される。システムバス４２６は、様々なバスアーキテクチャを使用するメモリバスやメモリコントローラー、周辺バス、ローカルバスを含む様々な種類のバス構造であり得る。

コンピュータ環境（パーソナルコンピュータ）４２０は、ハードディスク（図示なし）の読み込み書き込みを行うためのハードディスクドライブ４３２、着脱可能なディスク４３６の読み込み書き込みを行うための外部ディスクドライブ４３４を含んでもよい。着脱可能なディスク４３６は、磁気ディスクドライブのための磁気ディスクや、光学式ディスクドライブのための光学式ディスク、例えばＣＤ ＲＯＭである。ハードディスクドライブ４３２及び外部ディスクドライブ４３４は、ハードディスクドライブインターフェース４３８や外部ディスクドライブインターフェースによって、それぞれシステムバス４２６に接続される。当該ドライブやそれらのコンピュータ記録媒体は、コンピュータ環境（パーソナルコンピュータ）４２０のコンピュータ読み取り可能な指示や、データ構造やプログラムモジュールやその他のデータ不揮発性の記憶を提供する。データ構造は、上記で詳述した複数の異なるアクセスチャネルを通じてアクセス可能なサービスを実行するためにコンピュータに実装された方法、サーバー、ネットワーク、コンピュータプログラム製品の実装のための関係するデータを含む。関係するデータは、例えば、関係また目的データベース（relational or object database）のような、データベースに格納される。

上記で示した環境の一例においては、ハードディスク（図示なし）及び外部ディスクを用いているが、コンピュータによってアクセス可能なデータを格納できるその他の種類のコンピュータ読み取り可能な記録媒体、例えば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ、リードオンリーメモリ等を当該動作環境において用いてもよい。

オペ―レーティングシステム（図示なし）、１以上のアプリケーションプログラム、その他のプログラムモジュール（図示なし）、プログラムデータ４４６を含む複数のプログラムモジュールは、ハードディスクや、外部ディスク、ＲＯＭ４３０、ＲＡＭ４２８、に格納され得る。アプリケーションプログラム４４４は、図１乃至図１０において詳述した機能の少なくとも一部を含んでもよい。

ユーザーは、下記のように、入力装置、例えばキーボード４４８やマウス４５０を用いてコマンドや情報をパーソナルコンピュータ４２０に入力する。その他の入力装置（図示なし）、マイクロフォン（またはその他のセンサ）、ジョイスティック、ゲームパッド、スキャナー等を用いてもよい。これらの入力装置は、システムバス４２６に接続されたシリアルポートインターフェース４５２を介して、処理部４２２へ接続されるか、または、その他のインターフェース、例えば、パラレルポートインターフェース４５４、ゲームパッド、ユニバーサルシリアルバス（ＵＳＢ）によって集約されてもよい。更に、情報は、プリンタ４５６を用いて印刷されてもよい。プリンタ４５６及びその他のパラレル入出力装置はパラレルポートインターフェース４５４を通じて処理部４２２へ接続される。モニター４５８やその他の種類の表示部も、例えばビデオ入出力４６０等のインターフェースを介して、システムバス４２６に接続される。モニターに加えて、コンピュータ環境４２０は、その他の周辺出力装置（図示なし）、例えば、スピーカーやその他のオーディオ出力を含んでもよい。

コンピュータ環境４２０は、その他の電子機器、例えば、コンピュータ、電話（有線または無線）、ＰＤＡ（personal digital assistant）、テレビ等とコミニケーションできるように形成されてもよい。コミュニケーションのためには、コンピュータ環境４２０は、１以上の電子機器への接続されるネットワーク環境において動作する。図１２は、リモートコンピュータ４６２とネットワークを形成したコンピュータ環境を示す。リモートコンピュータ４６２は、別のコンピュータ環境、例えばサーバー、ルータ、ネットワークＰＣ、ピア装置、またはその他の共通ネットワークノードであり、コンピュータ環境４２０の上記した多くのまたは全ての要素を含み得る。図１２に示す論理接続は、ＬＡＮ（local area network）４６４やＷＡＮ（wide area network）４６６である。当該ネットワーク環境は、オフィスや、企業コンピュータネットワーク（enterprise-wide computer networks）、イントラネットやインターネット等の一般的なものである。

ＬＡＮネットワーク環境で用いられる際には、コンピュータ環境４２０はネットワークＩ／Ｏ４６８を介してＬＡＮ４６４に接続される。ＷＡＮネットワーク環境に用いられる際には、コンピュータ環境４２０は、モデム４７０やその他のＷＡＮ４６６を介したコミュニケーション形成手段を含む。コンピュータ環境４２０内部または外部のモデム４７０は、シリアルポートインターフェース４５２を介してシステムバス４２６に接続される。ネットワーク環境において、コンピュータ環境４２０に対して示されたプログラムモジュールまたはその一部は、リモートコンピュータまたはリモートコンピュータ４６２へアクセス可能なリモートメモリ格納装置に格納される。更に、複数の異なるアクセスチャネル方法を介してアクセス可能なサービスを実行するためのアプリケーション（上記に詳述）に関するその他のデータは、リモートコンピュータ４６２に存在してもよいし、リモートコンピュータ４６２を介してアクセス可能であってもよい。当該データは、例えば目的または関係データベースに格納される。上記に示したネットワーク接続は例示であって、電子機器間のコミュニケーションリンクを形成するその他の手段が用いられてもよい。

上記のコンピュータシステムは、複数の異なるアクセスチャネルを通じてアクセス可能なサービスを処理するための方法を実装するために用いられるコンピュータシステムの形式の一例を示したものにすぎない。

１ ＩＭＳネットワーク、２ サービスレイヤー、３ 制御及び伝達レイヤー、３ａ 制御レイヤー、３ｂ 伝達レイヤー、４ アクセスレイヤー、５ ＰＢＸサーバー、６ ＣＴＩ、７ａ−７ｄ 具体的システム、８ 制御センターシステム、９ａ ユーザーデータベース、９ｂ ＯＳＳ／ＢＳＳシステム、１０ ＩＭＳアプリケーションサーバー、１１ ＳＩＰＡｓ、２０ ユーザー、３０ ケアリングプロセス、３１ ユーザー認証、３２ ユーザー相互動作、３３ セルフケア、３４ エージェントルーティング、３５ エージェントコンタクト、１００ コンタクトセンターシステム、１１０ サービス実行レイヤー、１２０ サービス論理レイヤー、１２１ 展開管理部、１２２ ブロック形成ライブラリ、１２３ ルールエンジン部、１２４ セッション管理部、１２５ キャッシュ部、１２６ 監視管理部、１３０ コミュニケーションレイヤー、１３１ ＭＲＦアダプタ、１３２ ＣＳＣＦアダプタ、１３３ ＩＭＣアダプタ、１４０ サービス生成レイヤー、１４１ アクセス管理部、１４２ サービス設計部、１４３ ライフサイクル管理部、１４４ サービス管理部、１５０ データレイヤー、１６０ 監視レイヤー、２００ 従来のコンタクトセンターシステム、２１１ Ｐ−ＣＳＣＦモジュール、２１２ Ｓ−ＣＳＣＦモジュール、２１３ Ｉ−ＣＳＣＦモジュール、２１４ ＨＳＳモジュール、２１５ Ｓ−ＣＳＣＦモジュール、２１６ ＭＲＦＣモジュール、２１７ ＭＲＦＰモジュール、２１８ ＭＧＷモジュール、２１９ ＭＳＣモジュール、２２０ ＳＧＷモジュール、２２１ ＭＧＣＦモジュール、２２２ ＳＬＦモジュール、２２３ ＢＧＣＦモジュール、４２０ コンピュータ環境、４２２ 処理部、４２４ システムメモリ、４２６ システムバス、４２８ ＲＡＭ、４３０ ＲＯＭ、４３２ ハードディスクドライブ、４３４ 外部ディスクドライブ、４３６ 着脱可能ディスク、４３８ ハードディスクドライブインターフェース、４４０ 外部ディスクドライブインターフェース、４４４ アプリケーションプログラム、４４６ プログラムデータ、４４８ キーボード、４５０ マウス、４５２ シリアルポートインターフェース、４５４ パラレルポートインターフェース、４５６ プリンタ、４５８ モニター、４６０ ビデオ入出力、４６２ リモートコンピュータ、４６４ ＬＡＮ、４６６ ＷＡＮ、４６８ ネットワークＩ／Ｏ、４７０ モデム。

Claims (13)

1. 複数の異なるアクセスチャネルを介してアクセス可能なサービスを実行するためのＩＭＳアプリケーションサーバーであって、
   少なくとも１のサービスを生成するための複数の要素を提供し、前記少なくとも１のサービスをテストしサービス実行レイヤーに展開するサービス生成レイヤーを含み、
   前記サービス実行レイヤーは、
   前記少なくとも１のサービスを実行するサービス論理部と、
   前記少なくとも１のサービスを処理する際に用いられるその他のシステム及び／またはネットワークノードによって提供される少なくとも１の外部サービスへ接続するコミュニケーション部と、を有し、
   前記サービス生成レイヤーは、ノードライブラリと関連したグラフィカル開発環境と、
   グラフ構造を用いて、前記少なくとも１のサービスと異なるサービスにおいて、前記異なるサービスと同じアプリケーションを再度使用する前記少なくとも１のサービス、のビジネス論理を設計するためのドラッグドロップ機能と、
   を有することを特徴とするＩＭＳアプリケーションサーバー。
2. ＩＭＳアプリケーションサーバーは、ＩＭＳネットワークのサービスレイヤーに設置されることを特徴とする請求項１記載のＩＭＳアプリケーションサーバー。
3. 前記サービスは、前記複数の異なるアクセスチャネルから、独自にアクセス可能であることを特徴とする請求項１または２記載のＩＭＳアプリケーションサーバー。
4. 前記サービス論理部は、前記サービスを生成するとともに前記サービスを展開及び／または非展開する前記サービス生成レイヤーと相互に動作し、前記サービスは少なくとも１のコミュニケーション部を介してコミュニケーションされることを特徴とする請求項１乃至３のいずれかの請求項に記載のＩＭＳアプリケーションサーバー。
5. 前記複数の異なるアクセスチャネルは、１以上のプロトコル、１以上の物理的接続、及び／又は、無線または有線による接続を含むことを特徴とする請求項１乃至４のいずれかの請求項に記載のＩＭＳアプリケーションサーバー。
6. 前記サービスは、ＩＰコンタクトセンターサービスであることを特徴とする請求項１乃至５のいずれかの請求項に記載のＩＭＳアプリケーションサーバー。
7. ＩＭＳネットワークであって、
   前記ＩＭＳネットワークの少なくとも１のサービスがサービスレイヤーにおける請求項１乃至６のいずれかの請求項に記載のＩＭＳアプリケーションサーバーにおいて実行されるように、前記ＩＭＳアプリケーションサーバーをホストする機能を有する前記サービスレイヤーと、
   複数の異なるアクセスチャネルを介して少なくとも１のサービスを送る制御及び伝達レイヤーと、
   前記複数の異なるチャネルにおいて使用可能な複数の異なるアクセス装置を有するアクセスレイヤーと、
   を有することを特徴とするＩＭＳネットワーク。
8. ＩＭＳアプリケーションサーバーの複数の異なるアクセスチャネルを介してアクセス可能なサービスを実行するための方法であって、
   少なくとも１のサービスを生成するための複数の要素を提供するとともに、前記少なくとも１のサービスをテストし、前記ＩＭＳアプリケーションサーバーのサービス実行レイヤーに展開し、
   前記ＩＭＳアプリケーションサーバーにおいて、少なくとも１の複数の異なるアクセスチャネルを通じて前記少なくとも１のサービスの要求を受信し、
   前記少なくとも１のサービスを実行し、
   前記少なくとも１のサービスを処理する際に用いられるその他のシステム及び／またはネットワークノードによって提供される少なくとも１の外部サービスへ接続し、
   ノードライブラリと関連したグラフィカル開発環境と、グラフ構造を用いて、前記少なくとも１のサービスと異なるサービスにおいて、前記異なるサービスと同じアプリケーションを再度使用する前記少なくとも１のサービス、のビジネス論理を設計するためのドラッグドロップ機能と、を提供することを特徴とする方法。
9. 前記アプリケーションサーバーは、ＩＭＳネットワークのサービスレイヤーに設置されることを特徴とする請求項８記載の方法。
10. 前記サービスは、前記複数の異なるアクセスチャネルから、独自にアクセス可能であることを特徴とする請求項８または９記載の方法。
11. 前記複数の異なるアクセスチャネルは、１以上のプロトコル、１以上の物理的接続、及び／又は、無線または有線による接続を含むことを特徴とする請求項８乃至１０のいずれかに記載の方法。
12. 前記サービスは、ＩＰコンタクトセンターサービスであることを特徴とする請求項８乃至１１のいずれかに記載の方法。
13. コンピュータ読み取り可能な指示を含むコンピュータプログラムであって、コンピュータ及び／またはコンピュータネットワークシステムにおいてロードまたは作動された際に、前記コンピュータ及び／または前記コンピュータネットワークシステムに請求項８乃至１０のいずれかに記載の方法に応じた動作をさせる手段、
    として機能させるためのプログラム。