通信サービス提供方法および通信サービス提供システム
【課題】サーバによって提供される通信サービスの効率化を図るための通信サービス提供方法を提供する。
【解決手段】サービスロジック部と部品機能部とにおける制御を分離して、サービスロジック部が必要に応じてサービスパターンで予め決められている部品を呼び出して処理を実行させ、この部品の実行結果を受け取ることで、通信サービスに必要な全処理を行う。
【解決手段】サービスロジック部と部品機能部とにおける制御を分離して、サービスロジック部が必要に応じてサービスパターンで予め決められている部品を呼び出して処理を実行させ、この部品の実行結果を受け取ることで、通信サービスに必要な全処理を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して接続される複数の端末に通信に関するサービスを提供する通信サービス提供サーバにおける通信サービス提供方法および通信サービス提供システムに関する。
【背景技術】
【０００２】
近年、ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ、次世代ネットワーク）において、ネットワークを介して接続される端末に対して、サーバから通信サービスを提供するものが知られている。また、このＮＧＮ上のサービス拡充のために、サーバによる多様な通信サービスの提供が望まれている。
【０００３】
例えば、サーバが複数の異なる通信サービスを提供する場合、通信サービス毎にセッション制御を決定するサービスロジックを複数用意しておき、端末から通信サービスを要求するメッセージが送信されると、この要求に応じた通信サービスのサービスロジックに従ってサーバがセッション制御を実行するものがある（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Java Community Process: SIP Servlet v1.1, Java Specification Requests (JSR) 289 (Aug. 2008)
【非特許文献２】ETSI: Open Service Access (OSA); Parlay X Web Services, Draft ETSI, 202, 504 (Jun. 2007)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、通信サービスを提供するためのサービスロジックを通信サービス毎に実装しなければならず効率が悪いという問題がある。
例えば、２者間のセッション制御を行う場合、発信者側の端末と着信者側の端末とを接続するセッション制御や、通話中の端末同士の接続を切断するセッション制御のような基本的な制御は、異なる通信サービスにおいても実施される頻度が高い。このため、通信サービス毎にサービスロジックを用意すると、複数のサービスロジック間で基本的な制御が重複して記載される可能性も高い。よって、サービスの数の増大することに伴い、サービスロジックの記載量が増加するため、その中の重複部分も多くなる可能性もより高くなり、効率が悪くなるという問題がある。
【０００６】
本発明は、このような課題を鑑みてなされたものであり、その目的は、サーバによって提供される通信サービスの効率化を図るための通信サービス提供方法および通信サービス提供システムを提供することにある。
【課題を解決するための手段】
【０００７】
上述した課題を解決するために、本発明は、少なくとも１つの端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバにおける通信サービス提供方法であって、前記通信サービス提供サーバのサービスロジック部が、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するステップと、前記通信サービス提供サーバの部品管理制御部が、前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成させるステップと、前記通信サービス提供サーバの前記サービス非依存機能部が、前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うステップと、を備えることを特徴とする。
【０００８】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記部品生成に関する情報を送信するステップにおいて、前記サービスロジックで前記サービス非依存機能部から通知を受け取るタイミングを表わす制御復帰ポイント情報が予め決められている場合、当該制御復帰ポイント情報を前記部品生成に関する情報に含めて前記部品管理制御部に送信するステップと、前記通信サービス提供サーバの前記サービス非依存機能部が、前記部品制御情報に従ってメッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わすポイントに到達した場合、前記サービスロジック部に対してメッセージを送信するとともに、前記端末とのメッセージの送受信を中断するステップと、を備えることを特徴とする。
【０００９】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記部品生成に関する情報を送信した後、前記サービス非依存機能部からメッセージを受信した場合、前記サービス非依存機能部による制御を継続するか否か、あるいは終了するか否かの少なくとも一方を判断するステップと、前記サービス非依存機能部による制御を継続すると判断した場合、前記サービス非依存機能部に対して、継続を表わすメッセージを送信するステップと、前記サービス非依存機能部による制御を終了すると判断した場合、前記サービス非依存機能部に対して、前記サービス非依存機能部の削除を表わすメッセージを送信するステップと、を備えることを特徴とする。
【００１０】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、発信側の端末から自端末を識別するための第１の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第１の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第１の端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップとを備えることを特徴とする。
【００１１】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、発信側の端末から、着信側の端末を識別するための第２の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第２の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第２端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップとを備えることを特徴とする。
【００１２】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記サービスロジックで複数の前記サービス非依存機能部による制御処理の実行が予め決められている場合、前記サービスロジックに従って、複数の前記サービス依存機能部を生成することを特徴とする。
【００１３】
また、上述した課題を解決するために、本発明は、少なくとも１つの端末と、この端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバとを含む通信サービス提供システムであって、前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するサービスロジック部と、前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成する部品管理制御部と、前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うサービス非依存機能部とを備えることを特徴とする。
【発明の効果】
【００１４】
この発明によれば、サーバによって提供される通信サービスの効率化を図ることができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に係るサービス提供システムの一例について示す概略図である。
【図２】本実施形態に係る部品機能部の処理動作の一例について説明するためのフローチャートである。
【図３】本実施形態に係るサービスロジック部の処理動作の一例について説明するためのフローチャートである。
【図４】本実施形態に係るサービスロジック部による基本接続パターンのメッセージ送受信の一例を表わすイメージ図である。
【図５】本実施形態に係るサービスロジック部による基本接続パターンにおける状態遷移の一例を表わすイメージ図である。
【図６】本実施形態に係るサービス情報記憶部に記憶されている加入者データの一例を示す参考図である。
【図７】本実施形態に係る部品機能部による接続部品を生成する処理の一例を説明するシーケンスの図である。
【図８】本実施形態に係る部品機能部による切断部品を生成する処理の一例を説明するシーケンスの図である。
【図９】本実施形態に係るサービスロジック部によるガイダンス接続パターンにおける状態遷移の一例を表わすイメージ図である。
【図１０】本実施形態に係る部品機能部による接続部品を生成する処理の他の例を説明するシーケンスの図である。
【図１１】本実施形態に係る部品機能部によるガイダンス生成部品を生成する処理の一例を説明するシーケンスの図である。
【図１２】本実施形態に係るサービスロジック部による網内発呼パターンのメッセージ送受信の一例を表わすイメージ図である。
【図１３】本実施形態に係るサービスロジック部による網内発呼パターンにおける状態遷移の一例を表わすイメージ図である。
【図１４】本実施形態に係るサービス情報記憶部に記憶されている加入者データの他の例を示す参考図である。
【図１５】本実施形態に係る部品機能部による発呼部品を生成する処理の一例を説明するシーケンスの図である。
【図１６】本実施形態に係る部品機能部によるメディア変更部品を生成する処理の一例を説明するシーケンスの図である。
【図１７】本実施形態に係る通信サービス提供サーバを説明するための参考図である。
【図１８】本実施形態に係る部品機能部を説明するための参考図である。
【発明を実施するための形態】
【００１６】
以下、本発明に係る一実施形態について、図面を参照して説明する。
図１は、本実施形態に係るサービス提供システムの一例について示す概略図である。
図１に示す通り、通信サービス提供システムは、通信サービス提供サーバ１００と、この通信サービス提供サーバ１００とネットワークＮＷを介して接続されている複数の端末２００（例えば、２０１、２０２、２０３、・・・、２０ｎ）と、メディアサーバ３００とを備える。
【００１７】
通信サービス提供サーバ１００は、例えばＳＩＰ（ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ）サーバであって、ＩＴＵ−Ｔ勧告Ｙ．２０１２で規定されるＡｐｐｌｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｆｕｎｃｔｉｏｎｓ ａｎｄ Ｓｅｒｖｉｃｅ Ｓｕｐｐｏｒｔ Ｆｕｎｃｔｉｏｎｓ（ ＡＳＦ＆ＳＳＦ ）として、ＮＧＮでのアプリケーションサービスを制御する機能を有する。このＡＳＦ＆ＳＳＦの構成要素のうち、Ａｐｐｌｉｃａｔｉｏｎ ｓｕｐｐｏｒｔ ｆｕｎｃｔｉｏｎａｌ ｅｎｔｉｔｙ（ ＡＳ−ＦＥ ）は、各サービスのサービスロジックを収容あるいは実行する機能要素であり、サービス種別に応じて、呼制御サーバ、プレゼンスサーバ、メッセージングサーバ、カンファレンスサーバ等として機能する。なおＩＴＵ−Ｔ勧告Ｙ．２０１２については、参考文献＜Functional requirements and architecture of the NGN, ITU-T Recommendation Y.2012 (Jul. 2006)＞に詳細に記載されている。
【００１８】
複数の端末２００は、ユーザによって利用される端末装置であって、例えば、電話回線を介して通信サービス提供サーバ１００と接続されている電話機や、無線回線を介して通信サービス提供サーバ１００と接続されている携帯電話機、あるいは、インターネットを介して接続されるコンピュータ等である。
メディアサーバ３００は、音声データ、画像データあるいは動画データ等を記憶しており、通信サービス提供サーバ１００を介して接続された端末装置２００に対して、記憶しているデータを再生する。
【００１９】
また、通信サービス提供サーバ１００は、通信プロトコルスタック１１０と、ＵＡ機能部１２０と、部品機能部１３０と、サービスロジック部１４０と、サービス情報記憶部１５０とを備える。なお、サービスロジック部１４０側をメッセージの送受信の上流、通信プロトコルスタック１１０側をその下流とすると、端末２００から受信したメッセージを、通信プロトコルスタック１１０、ＵＡ機能部１２０、部品機能部１３０、サービスロジック部１４０の順番で、下流から上流に向かって送信することをイベント通知という。また、サービスロジック部１４０から送信されたメッセージを、部品機能部１３０、ＵＡ機能部１２０、通信プロトコルスタック１１０の順番で、上流から下流に向かって送信することをＡＰＩ（ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ ）呼出しという。
【００２０】
通信プロトコルスタック（メッセージ送受信部）１１０は、ネットワークＮＷで用いられるプロトコルのプロトコルスタックとして機能し、例えば、ＳＩＰおよびＨＴＴＰ、ＩＳＵＰ、ＩＮＡＰ、Ｄｉａｍｅｔｅｒ等の各種プロトコルに基づき、メッセージのエンコードおよびデコードを行う。
【００２１】
ＵＡ（ Ｕｓｅｒ Ａｇｅｎｔ ）機能部１２０は、端末間のセッションを確立するため、端末間とのメッセージの送受信を行う。
具体的に説明すると、ＵＡ機能部１２０は、ＵＡ管理制御部１２１を備え、複数のＵＡ、例えば、発ＵＡ１２２、着ＵＡ１２３、発用ＭＳ−ＵＡ１２４、および着用ＭＳ−ＵＡ１２５として機能する。また、ＵＡ機能部１２０は、内部に記憶部１２６を備える。
また、ＵＡ機能部１２０は、部品機能部１３０からメッセージを受け取ると、このメッセージに応じたＵＡのインスタンスを生成する。
【００２２】
ＵＡ管理制御部１２１は、通信プロトコルスタック１１０あるいは部品機能部１３０からメッセージを受け取ると、このメッセージに応じたＵＡのインスタンスを生成する。
また、ＵＡ管理制御部１２１は、複数のＵＡ（発ＵＡ１２２、着ＵＡ１２３、発用ＭＳ−ＵＡ１２４、および着用ＭＳ−ＵＡ１２５）のそれぞれを識別する固有のＵＡ識別番号と、部品機能部１３０によって生成される部品のそれぞれを識別するための固有の部品番号とを対応付けて記憶する記憶部１２６を有している。このＵＡ管理制御部１２１は、この記憶部１２６を参照して、複数のＵＡと複数の部品との間のイベントバスとして、メッセージの送受信を制御する。例えば、ＵＡ管理制御部１２１は、発ＵＡ１２２からメッセージを受信した場合、記憶部１２６を参照して、発ＵＡ１２２から受信したメッセージを、部品が生成されていないならば、部品管理制御部１３１に送信する。なお、部品が生成されているか否かが判断され、部品が生成されている場合、ＵＡ管理制御部１２１は、生成されている部品に対してメッセージを送信する。
さらに、ＵＡ管理制御部１２１は、生成されたＵＡが通信プロトコルスタック１１０から受けたイベント通知に応じた処理を終了した場合、当該ＵＡのインスタンスを削除する。
【００２３】
複数のＵＡは、対向装置ごとの通信プロトコルレベルでの状態管理を行う。つまり、発ＵＡ１２２は発信側の端末と、着ＵＡ１２３は着信側の端末と、発用ＭＳ−ＵＡ１２４は発信側の端末用メディアサーバ（ＭＳ）と、着用ＭＳ−ＵＡ１２５は着信側の端末用メディアサーバ（ＭＳ）と、それぞれＳＩＰ等の通信プロトコルレベルの１セッションの状態管理を行う。
【００２４】
部品機能部１３０は、部品管理制御部１３１および部品１３２として機能し、受信したメッセージと送信するメッセージとが予め決められた組み合わせで対応付けられているメッセージテーブルデータを記憶する記憶部１３３を備える。この部品機能部１３０は、この記憶部１３３を参照して、ＵＡ機能部１２０あるいはサービスロジック部１４０から受信したメッセージに対応するメッセージの送信を行う。
このようにして、部品機能部１３０は、サービスに依存していないメッセージテーブルデータを参照して動作することにより、サービスに依存しないＳＩＰ信号レベルでの２者間のセッション制御を行っている。
例えば、特定のサービスにのみ特化しているサービスロジックを利用して、１つの通信サービスに対して、それぞれ、１つの通信サービスを実行するソフトフェアのブロックを必要とする場合、これらのソフトウェアのブロックは、サービスに依存していることとなる。一方、異なる通信サービスに対して、共通して利用可能なソフトウェアのブロックを通信サービスに応じて呼出し、通信サービスを実行する場合、これらのソフトウェアのブロックは、サービスに依存していないこととなる。
【００２５】
部品管理制御部１３１は、サービスロジック部１４０から受けたＡＰＩ呼出しに応じて、部品１３２のインスタンスを生成する。このＡＰＩ呼出しには、部品生成に関する情報が含まれており、例えば、部品の種類、部品の属性、発信側の端末の番号、着信側の端末の番号、制御復帰ポイント等を表わす情報が含まれている。
部品の種類とは、後述する接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔを表わす。また、部品の属性情報とは、例えば、接続部品に関しては接続方法を表わす情報であり、発信側のダイアログを確立することを要する方法（ ｃｏｎｆｉｒｍｅｄ ｄｉａｌｏｇ ）であること、あるいは、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法（ ｅａｒｌｙ ｄｉａｌｏｇ ）であることを表わす。
また、部品管理制御部１３１は、生成された部品１３２とサービスロジック部１４０との間のイベントバスであって、部品１３２とサービスロジック部１４０との間のメッセージの送受信を行う。
さらに、部品管理制御部１３１は、部品１３２から処理を終了することを表すメッセージを受け付けた場合、サービスロジック部１４０へイベント通知を行い、サービスロジック部１４０のＡＰＩ呼出しに応じて当該部品のインスタンスを削除する。
【００２６】
部品１３２は、部品管理制御部１３１によって生成されることで、例えば、接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔとして機能するものであり、例えば、プログラムのモジュールである。
この部品１３２は、部品毎に予め決められているメッセージテーブルデータを参照して、ＳＩＰ信号レベルでの２者間のセッション制御を行う。このメッセージテーブルデータは、部品１３２の制御内容を表わす部品制御情報であって、受信したメッセージに応じて、部品１３２が送信するメッセージが対応付けられている。
また、部品１３２は、部品管理制御部１３１によって生成された際に、制御復帰タイミングが予め決められている場合、この制御復帰タイミングに合わせて、サービスロジック部１４０に対して制御の復帰を行う。つまり、部品１３２は、制御復帰タイミングとなると、サービスロジック部１４０に対してイベント通知を行う。
さらに、部品１３２は、部品管理制御部１３１によって生成された際に決められているメッセージ送信先に対してメッセージを送信する。なお、このメッセージ送信先は、部品１３２の生成を指示するＡＰＩ呼出しを部品管理制御部１３１に行うサービスロジック部１４０によって決定されるものであり、部品１３２は、サービスロジック部１４０によって決定されたメッセージ送信先にメッセージを送信することができる。
【００２７】
なお、複数の接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔは、上述の通り、それぞれを識別するための部品識別番号を有しており、部品機能部１３０に内蔵された記憶部１３３が、メッセージの送受信を行う部品を表わす部品識別番号と、ＵＡを表わすＵＡ識別番号とを関連付けて記憶する。
【００２８】
サービスロジック部１４０は、通信サービスの制御内容を表わすサービスロジック（すなわち、サービスパターンのプログラム）に従って通信サービスの提供を開始する場合、通信サービスロジックに依存せずに自身の機能を発揮する部品１３２のうちサービスロジックにおいて予め決められている部品１３２を表わす部品生成に関する情報を送信する。
つまり、サービスロジック部１４０は、サービス情報記憶部１５０を参照して、サービスパターンのプログラムを実行することにより、サービスに依存する通信サービス制御を実現するとともに、サービスに依存せずに通信サービス制御を実行する部品１３２に対して制御を指示するためのＡＰＩ呼出しを行う。
具体的に説明すると、サービスロジック部１４０は、サービス情報記憶部１５０を参照して、部品管理制御部１３１からのイベント通知に基づき、サービスパターンを決定する。また、サービスロジック部１４０は、決定されたサービスパターンのプログラムを実行する。
ここで、サービスロジックとは、サービスロジック部１４０によって実行されるサービスパターンのプログラムである。
【００２９】
また、サービスロジック部１４０は、サービスパターンのプログラムに従って、部品のインスタンスの生成、継続、削除を行うことで、サービスに応じた少なくとも２者間のセッション制御を行う。
さらに、サービスロジック部１４０は、部品１３２からの制御の復帰待ち状態において、部品管理制御部１３１を介して部品１３２からイベント通知を受けると、サービスに依存しているサービスパターンの制御を継続する。これにより、サービスに依存せずに通信サービス制御を実行する部品１３２から、サービスに依存する通信サービス制御を実行するサービスロジック部１４０の制御へと切り替わり、制御が復帰される。
【００３０】
また、サービスロジック部１４０は、サービスパターンのプログラムに従って動作することにより、サービスに依存する接続先決定方法の選択を行う。
さらに、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されている情報を参照して、課金サービスやデータ変換等を行う。例えば、発信側の端末２０１の番号または着信側の端末２０２の番号に基づき、加入者に応じた課金情報が予め対応付けられている加入者データを参照することで、端末２０１または端末２０２に課金される通話代を求めることができる。また、発信側の端末２０１がダイヤルした番号が論理番号である場合、サービス情報記憶部１５０を参照して、この論理番号に対応付けられている物理番号を得て、論理番号を物理番号に変換する。
【００３１】
サービス情報記憶部１５０は、各通信サービスを端末に提供するため、サービスロジック部１４０が実行する際に利用する情報を記憶する。このサービス情報記憶部１５０は、例えば、ユーザを識別する識別情報（電話番号、契約番号等）と、このユーザのサービスの契約内容を表わす情報とが対応付けられている加入者データを記憶する。また、このサービス情報記憶部１５０は、発信側の端末２００の電話番号や着信側の端末２００の電話番号等を一次的に記憶する。
【００３２】
次に、図２を用いて、部品機能部１３０の処理動作の一例について説明する。図２は、部品機能部１３０の処理動作の一例について説明するためのフローチャートである。
図２に示す通り、部品管理制御部１３１は、サービスロジック部１４０から部品生成を表わすＡＰＩ呼出しを受けると、このＡＰＩ呼出しに応じた部品１３２を生成する（ステップＳＴ１）。言い換えると、部品管理制御部１３１は、ＡＰＩ呼出しに含まれる部品生成に関する情報（例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報）に応じた部品１３２のプログラムを起動し、実行する。なお、部品１３２は、上記部品生成に関する情報を一時的に部品機能部１３０内の記憶部１３３に記憶しておく。
これにより、ステップＳＴ１で生成された部品１３２は、サービスロジック部１４０の部品生成より以前に端末から通信サービス提供サーバ１００が受信していたメッセージ（例えば、通信を要求するメッセージ）に対応するメッセージをＵＡ機能部１２０に送信する。一方、ＵＡ機能部１２０からメッセージを受信した場合、部品１３２は、このメッセージに対応するメッセージをＵＡ機能部１２０に送信する。すなわち、部品１３２は、ＵＡ機能部１２０に対してメッセージの送受信を行う（ステップＳＴ２）。
そして、ステップＳＴ２において、部品１３２の生成時にサービスロジック部１４０から指定された制御復帰ポイントに表わされているメッセージを、ＵＡ機能部１２０から受信した場合、部品１３２は、復帰タイミングであると判断し（ステップＳＴ３−ＹＥＳ）、ＵＡ機能部１２０から受信したメッセージに対応するメッセージをサービスロジック部１４０にイベント通知する（ステップＳＴ４）。そして、部品１３２は、以降の処理を中断する（ステップＳＴ５）。
【００３３】
その後、サービスロジック部１４０から継続の指示があった場合（ステップＳＴ６−継続）、部品１３２は、ステップＳＴ２において行っていたメッセージ送受信の続きを継続して実行する（ステップＳＴ７）。そして、部品終了のタイミングとなったら（ステップＳＴ８−ＹＥＳ）、部品管理制御部１３１は、部品１３２を削除する（ステップＳＴ９）。一方、ステップＳＴ８において部品終了のタイミングでない場合、ステップＳＴ２に戻る（ステップＳＴ８−ＮＯ）。
また、ステップＳＴ６において、サービスロジック部１４０から部品削除の指示を表わすＡＰＩ呼出しがあった場合（ステップＳＴ６−削除）、部品管理制御部１３１は、部品１３２を削除する（ステップＳＴ９）。
【００３４】
次に、図３を用いて、サービスロジック部１４０の処理動作の一例について説明する。図３は、サービスロジック部１４０の処理動作の一例について説明するためのフローチャートである。
図３に示す通り、サービスロジック部１４０は、部品管理制御部１３１からイベント通知を受けると（ステップＳＴ１１−ＹＥＳ）、このイベント通知に基づき、サービス情報記憶部１５０を参照して、サービスパターンを決定する（ステップＳＴ１２）。
【００３５】
一方、イベント通知がない場合であっても（ステップＳＴ１１−ＮＯ）、予め決められたイベントタイミングを表わす情報がサービス情報記憶部１５０に記憶されている場合、このイベントタイミングを表わす情報に到達したか否かを判断する（ステップＳＴ１３）。そして、イベントタイミングに到達した場合（ステップＳＴ１３−ＹＥＳ）、サービスロジック部１４０は、このイベントタイミングに基づき、サービス情報記憶部１５０を参照してサービスパターンを決定する（ステップＳＴ１４）。
【００３６】
ステップＳＴ１２あるいはステップＳＴ１４においてサービスパターンが決定されると、サービスロジック部１４０は、この決定されたサービスパターンのプログラムを実行する（ステップＳＴ１５）。
つまり、サービスロジック部１４０は、このサービスパターンのプログラムに従って、部品１３２の生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ１６）。なお、この時、サービスロジック部１４０は、サービスパターンのプログラムに従い、部品生成に関する情報（例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報）を作成してＡＰＩ呼出しとともに部品管理制御部１３１に送信する。
【００３７】
一方、ＡＰＩ呼出しに基づき部品管理制御部１３１によって生成された部品１３２は、部品生成に関する情報として、制御復帰ポイントを表わす情報が含まれている場合、対応するメッセージをＵＡ機能部１２０から受信すると、受信したメッセージに対応するメッセージをサービスロジック部１４０にイベント通知する。すなわち、サービスロジック部１４０に制御を復帰させる。
【００３８】
ここで、このサービスロジック部１４０への制御が復帰された場合（ステップＳＴ１７−ＹＥＳ）、すなわち、サービスロジック部１４０が部品管理制御部１３１を介して部品１３２からのイベント通知を受けた場合、サービスロジック部１４０は、部品１３２の動作処理を継続するか否かを判断する（ステップＳＴ１８）。なお、部品１３２の動作処理を継続するか、あるいは終了するかを表わす情報は、サービスパターンにおいて予め決められている。
そして、部品を継続する場合、部品１３２の制御処理の継続指示を表わすＡＰＩ呼出しを行う（ステップＳＴ１９）。その後、部品１３２の終了を表わすイベント通知を受けたか否かを判断し（ステップＳＴ２０）、受けていない場合、さらにサービスロジック部１４０への制御復帰が行われるか否かをステップＳＴ１７に戻って判断する。
【００３９】
一方、ステップＳＴ１８で、サービスパターンのプログラムにおいて、継続の指示でなく（ステップＳＴ１８−ＮＯ）、終了の指示が予め決められていた場合（ステップＳＴ２１）、サービスロジック部１４０は、部品１３２の削除を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ２２）。
そして、サービスパターンのプログラムに従って、サービスロジック部１４０は、さらに部品の生成があるか否かを判断し（ステップＳＴ２３）、さらに部品を生成する場合、ステップＳＴ１６に戻る。
【００４０】
次に、本実施形態に係るサービス提供システムにおいて、それぞれ異なる部品を利用して通信サービスを提供する例について説明する。
【００４１】
［番号変換サービス（基本接続）の例］
はじめに、図４〜８を用いて、発信者により端末２０１を介して呼び出された番号を変換するとともに、発信者の端末２０１と着信者の端末２０２との２者間のセッションを確立するための基本接続パターンについて説明する。
図４は、この基本接続パターンのメッセージ送受信を表わすイメージ図である。図５は、基本接続パターンにおける状態遷移の一例を示す概略図である。
【００４２】
まず、図４に点線で示すような、端末２０１からの接続要求をサービスロジック部１４０に伝達する方法について説明する。
図４に示す通り、例えば発信者によって番号「０１２０−ａａａ−ｂｂｂ」がダイヤルされると、端末２０１は、通信サービス提供サーバ１００に対して通話（接続）を要求するメッセージを送信する。すると、このメッセージは、通信サービス提供サーバ１００の通信プロトコルスタック１１０によって変換され、発ＵＡ１２２に送信される。そして、発ＵＡ１２２は、通信プロトコルスタック１１０から送信されたメッセージに基づくイベント通知をＵＡ管理制御部１２１に行い、次いで、部品管理制御部１３１がこのイベント通知に対応するイベント通知をサービスロジック部１４０に行う。
【００４３】
これにより、サービスロジック部１４０は、図５に示す通り、部品管理制御部１３１から着信通知を表わすイベント通知を受ける（ステップＳＴ１０１）。なお、このイベント通知には、発信者の端末２０１の番号と、着信者の端末２０２の論理番号「０１２０−ａａａ−ｂｂｂ」とが含まれており、サービスロジック部１４０は、受信したイベント通知に関連付けて、端末２０１の番号と端末２０２の番号を、サービス情報記憶部１５０に一時的に記憶しておく。
そして、サービスロジック部１４０は、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データを参照して、着信者の端末２０２の論理番号に対応する物理番号へ番号変換するとともに、サービスパターンを決定する。
【００４４】
具体的に説明すると、サービス情報記憶部１５０には、例えば図６に示すような加入者データαが記憶されている。この加入者データαは、着信側の端末を識別する論理番号（すなわち、契約者番号）と、着信側の端末を識別する物理番号（すなわち、着端末／ＭＳの電話番号）と、サービスパターンと、音声ファイルとが、それぞれ対応付けられた情報である。
物理番号とは、複数の端末の中から当該端末を識別する固有の端末識別情報である。
論理番号とは、物理番号が表わす契約者が特定の通信サービスを受けるため予め決められている番号であって、当該サービスの契約をしている端末を識別する端末識別情報である。ここでは、論理番号は、発信側の端末によってダイヤルされる電話番号であって、メッセージに関連付けられて、発信側の端末から通信サービス提供サーバ１００に送信される。
【００４５】
サービスパターンとは、論理番号と物理番号との組み合わせに従って決められる通信サービスを実現するためのプログラムの種類を表わす。ここでは、サービスパターンとして、基本接続とガイダンス接続が示されている。
音声ファイルは、サービスパターンにおいて音声データを提供することが含まれている場合、この提供される音声データを表わす情報であって、当該サービスパターンと対応付けられている。なお、この音声ファイルの音声データは、ネットワークを介して接続され、通信サービス提供サーバ１００の外部にあるメディアサーバ３００に記憶されている。
【００４６】
なお、ここでは、論理番号と物理番号との組み合わせに応じてサービスパターンが決定される例を説明するが、本発明はこれに限られず、例えば、論理番号あるいは物理番号のいずれか一方とサービスパターンとが対応づけられている加入者データであってもよい。また、この場合、サービスロジック部１４０は、論理番号あるいは物理番号のいずれか一方と対応付けられているサービスパターンを、実行すべきサービスパターンとして決定するものであってもよい。
また、加入者データは、発信者側の端末の電話番号（契約者番号あるいは物理番号）とサービスパターンが対応付けられ、発信者側の端末の電話番号に応じて、サービスパターンが決定されものであってもよい。
例えば、サービスロジック部１４０は、発信側の端末から自端末を識別するための端末識別情報（例えば、電話番号）が関連付けられた通信サービスの提供を要求するメッセージ（例えば、通話要求）を受信した場合、このメッセージに基づき、この発信側の端末が利用可能な通信サービスのサービスロジックと、当該発信側の端末の端末識別情報とを対応付けた加入者データを記憶するサービス情報記憶部１５０を参照して、端末識別情報と対応付けられているサービスロジックに従って、通信サービスの提供を開始するものであってもよい。
【００４７】
図５に戻って、サービスロジック部１４０は、イベント通知に含まれる着信者Ｂの論理番号「０１２０−ａａａ−ｂｂｂ」に基づき、加入者データαを参照して、着信者Ｂの番号を、論理番号「０１２０−ａａａ−ｂｂｂ」と対応付けられている物理番号「０４２２−ｃｃ−ｄｄｄｄ」に変換する。また、サービスロジック部１４０は、この着信者Ｂの論理番号「０１２０−ａａａ−ｂｂｂ」と対応付けられているサービスパターン「基本接続」を、発信者Ａの端末装置２０１からの当該イベント通知に対応するサービスパターンと決定する。
【００４８】
次いで、サービスロジック部１４０は、サービスパターン「基本接続」のプログラムを実行する。
これにより、サービスロジック部１４０は、この「基本接続」のプログラムに従って、接続部品Ｐの部品生成と、切断部品Ｑの部品生成を行う。なお、この「基本接続」のプログラムには、接続部品Ｐの部品の生成および削除処理が終了した後、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。また、この「基本接続」のプログラムには、接続部品Ｐの属性情報として、発信側のダイアログを確立することを要する方法（ ｃｏｎｆｉｒｍｅｄ ｄｉａｌｏｇ ）が、サービスロジック部１４０によって決められている。また、接続部品Ｐの制御復帰ポイントとしては「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」が、切断部品Ｑの制御復帰ポイントとしては、「２００＿ＢＹＥメッセージ受信」が、サービスロジック部１４０によって決められている。
【００４９】
この「基本接続」のプログラムに従って、サービスロジック部１４０は、はじめに接続部品Ｐの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ１０２）。
そして、部品管理制御部１３１によって接続部品Ｐが生成され、接続部品Ｐによって接続処理が実行されると、端末２０１と端末２０２とが接続中という状態になる。これにより、接続部品Ｐの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ１０３）。ここで、接続処理が終了する。続けて、サービスロジック部１４０は、部品管理制御部１３１に対して、接続部品Ｐの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ１０４）。これにより、端末２０１と端末２０２とが通話状態となる。
【００５０】
次いで、例えば端末２０１によって通話中の状態が切断されると、端末２０１は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品管理制御部１３１を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ１０５）。このとき、通信を切断した端末２０１の番号が、イベント通知とともにサービスロジック部１４０に通知される。
【００５１】
そして、サービスロジック部１４０は、この「基本接続」のプログラムに従って、イベント通知に含まれる端末２０１の番号に基づき、サービス情報記憶部１５０を参照して、端末２０１と接続中の状態である端末２０２に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ１０６）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０１と端末２０２とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ１０７）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ１０８）。これにより、端末２０１と端末２０２の通話に関する状態が全てなくなり、空き状態となる。
【００５２】
次に、図７を用いて、サービスロジック部１４０が接続部品Ｐを生成する一例として、図５に示すステップＳＴ１０１〜１０４に相当するシーケンスについて、より詳細に説明する。
図７に示す通り、発信者Ａから番号「０１２０−ａａａ−ｂｂｂ」への通話が要求されると、端末２０１は、ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを、ネットワークＮＷを介して通信サービス提供サーバ１００に送信する（ステップＳＴ１１０）。すると、ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを受信した通信サービス提供サーバ１００の通信プロトコルスタック１１０が、このＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージをＩＮＶＩＴＥメッセージに変換して、部品管理制御部１３１に送信する（ステップＳＴ１１１）。そして、部品管理制御部１３１は、着信通知を表わすイベント通知をサービスロジック部１４０に通知する（ステップＳＴ１１２）。
【００５３】
ここで、サービスロジック部１４０は、上述の通り、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データを参照して、番号を変換するとともに、サービスパターンを決定するものとする。そこで、「基本接続」のプログラムが決定された場合、サービスロジック部１４０は、この「基本接続」のプログラムに従って、はじめに接続部品Ｐを生成する指示をＡＰＩ呼出しする（ステップＳＴ１１３）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「接続部品Ｐ」、属性情報の接続方法「ｃｏｎｆｉｒｅｄ」、制御復帰ポイント「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、属性情報と、制御復帰ポイントと、発信側の端末２０１の番号を発信側番号Ａと、着信側の端末２０２の番号を着信側番号Ｂとを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００５４】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、接続部品Ｐ（ｃｏｎｆｉｒｅｄ）を生成する。生成された接続部品Ｐは、ステップＳＴ１１１においてＵＡ機能部１２０から受け取っていたＩＮＶＩＴＥメッセージに基づき、メッセージテーブルデータを参照して、ＩＮＶＩＴＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ１１４）。
これにより、ＵＡ機能部１２０は着ＵＡ１２３に対してＡＰＩ呼出しを行い、着ＵＡ１２３は、端末２０２に対してＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ１１５）。そして、端末２０２は、着ＵＡ１２３に１００メッセージを送信し（ステップＳＴ１１６）、その後、１８０メッセージも送信する（ステップＳＴ１１７）。
【００５５】
端末２０２から１８０メッセージを受信すると、着ＵＡ１２３は、１８０メッセージを接続部品Ｐに送信する（ステップＳＴ１１８）。そして、接続部品Ｐは、部品管理制御部１３１を介してサービスロジック部１４０にアラート通知を行い（ステップＳＴ１１９）、サービスロジック部１４０に制御を復帰させる。
【００５６】
サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの制御を継続させることを決定し、部品継続メッセージを接続部品Ｐに送信する（ステップＳＴ１２０）。これを受けて、接続部品Ｐは、１８０メッセージを発ＵＡ１２２に送信する（ステップＳＴ１２１）。この発ＵＡ１２２は、端末２０１に１８０メッセージを送信する（ステップＳＴ１２２）。この端末２０１は、ステップＳＴ１２２で受信した１８０メッセージに１００ｒｅｌオプションが付加されていた場合、ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ１２３）。
【００５７】
そして、発ＵＡ１２２は、ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１２４）。ここで、ＰＲＡＣＫメッセージの受信は、接続部品Ｐの制御復帰ポイントとなっていないため、接続部品Ｐは、ＰＲＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１２５）。これにより、着ＵＡ１２３は、ＰＲＡＣＫメッセージを端末２０２に送信する（ステップＳＴ１２６）。この端末２０２は、２００＿ＰＲＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１２７）。
そして、着ＵＡ１２３は、２００＿ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１２８）。ここで、２００＿ＰＲＡＣＫメッセージの受信も、接続部品Ｐの制御復帰ポイントとなっていないため、接続部品Ｐは、２００＿ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ１２９）。この発ＵＡ１２２は、２００＿ＰＲＡＣＫメッセージを端末２０１に送信する（ステップＳＴ１３０）。
端末２０２から２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ｂ）メッセージが着ＵＡ１２３に送信されると（ステップＳＴ１３１）、着ＵＡ１２３は、２００＿ＩＮＶＩＴＥメッセージを接続部品Ｐに送信する（ステップＳＴ１３２）。
そして、接続部品Ｐは、端末２０１から端末２０２の呼び出しが確立されたことを表わす呼確立通知（Ｂ）をサービスロジック部１４０に送信し（ステップＳＴ１３３）、サービスロジック部１４０に制御を復帰させる。
【００５８】
サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの制御を継続させることを決定し、部品継続メッセージを接続部品Ｐに送信する（ステップＳＴ１３４）。これを受けて、接続部品Ｐは、ＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１３５）。この着ＵＡ１２３は、端末２０２にＡＣＫメッセージを送信する（ステップＳＴ１３６）。
また、接続部品Ｐは、２００＿ＩＮＶＩＴＥメッセージを発ＵＡ１２２に送信する（ステップＳＴ１３７）。この発ＵＡ１２２は、２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ｂ）メッセージを端末２０１に送信し（ステップＳＴ１３８）、端末２０２からＡＣＫメッセージを受信する（ステップＳＴ１３９）。次いで、発ＵＡ１２２は、ＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１４０）。
これにより、接続部品Ｐは、部品終了通知をサービスロジック部１４０に通知する（ステップＳＴ１４１）。そして、サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ１４２）。これを受けて、部品管理制御部１３１は、接続部品Ｐを削除する。
以上によって、端末２０１と端末２０２の接続が完了する。
【００５９】
次に、図８を用いて、サービスロジック部１４０が切断部品Ｑを生成する一例として、図５に示すステップＳＴ１０５〜１０８に相当するシーケンスについて、より詳細に説明する。
図８に示す通り、端末２０１と端末２０２は、通話中となっている。この状態において、端末２０１が、発ＵＡ１２２に対してＢＹＥメッセージを送信する（ステップＳＴ１５０）。すると、この発ＵＡ１２２が、ＢＹＥメッセージを部品管理制御部１３１に送信するとともに（ステップＳＴ１５１）、端末２０１に２００＿ＢＹＥメッセージを送信する（ステップＳＴ１５２）。
このＢＹＥメッセージを受信した部品管理制御部１３１は、切断通知（Ａ）を表わすメッセージをサービスロジック部１４０に送信する（ステップＳＴ１５３）。なお、このメッセージには、切断を通知した側の端末として端末２０１を特定する情報（例えば、端末２０１の番号）が関連付けられている。
【００６０】
ここで、上述の通り、既に「基本接続」のプログラムが決定されている場合、サービスロジック部１４０は、この「基本接続」のプログラムに従って、切断部品Ｑを生成する指示をＡＰＩ呼出しする（ステップＳＴ１５４）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「切断部品Ｑ」、制御復帰ポイント「２００＿ＢＹＥメッセージ受信」であるとする。そこで、サービスロジック部１４０は、サービス情報記憶部１５０に一次的に記憶されていた「端末２０１と端末２０２とが通話状態である」ことを表わす情報を読み出し、ステップＳＴ１５３で受信したメッセージに関連付けられている端末２０１と特定する情報に基づき、別の端末２０２を特定する情報を切断する側の端末であることを検出する。
そして、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、切断する側の端末２０２の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００６１】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、切断部品Ｑを生成する。生成された切断部品Ｑは、ステップＳＴ１５１においてＵＡ機能部１２０から受け取っていたＢＹＥメッセージに基づき、メッセージテーブルデータを参照して、ＢＹＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ１５５）。
これにより、ＵＡ機能部１２０は着ＵＡ１２３に対してＡＰＩ呼出しを行い、着ＵＡ１２３は、端末２０２に対してＢＹＥメッセージを送信する（ステップＳＴ１５６）。そして、端末２０２は、着ＵＡ１２３に２００ＢＹＥメッセージを送信する（ステップＳＴ１５７）。
そして、着ＵＡ１２３は、ＵＡ機能部１２０を介して２００＿ＢＹＥメッセージを切断部品Ｑに送信する（ステップＳＴ１５８）。この切断部品Ｑは、部品終了を表わす部品終了通知をサービスロジック部１４０に送信し、サービスロジック部１４０に制御を復帰させる（ステップＳＴ１５９）。
【００６２】
サービスロジック部１４０は、「基本接続」のプログラムに従い、切断部品Ｑの制御を終了させることを決定し、部品削除メッセージを切断部品Ｑに送信する（ステップＳＴ１６０）。
これにより、端末２０１と端末２０２とは通話が切断される。
【００６３】
［番号変換サービス（ガイダンス接続）の例］
次に、図９〜１１を用いて、発信者Ａにより端末２０１を介して呼び出された番号を変換するとともに、発信者Ａの端末２０１と、ガイダンスを再生するメディアサーバ３００との２者間のセッションを確立するためのガイダンス接続パターンについて説明する。
図９は、ガイダンス接続パターンにおける状態遷移の一例を示す概略図である。
【００６４】
図９に示す通り、例えば発信者Ａによって番号「０１２０−ｅｅｅ−ｆｆｆ」がダイヤルされると、端末２０１は、通信サービス提供サーバ１００に対して通話（接続）を要求するメッセージを送信する。すると、このメッセージは、通信サービス提供サーバ１００の通信プロトコルスタック１１０によって変換され、発ＵＡ１２２に送信される。そして、発ＵＡ１２２は、通信プロトコルスタック１１０から送信されたメッセージに基づくイベント通知をＵＡ管理制御部１２１に行い、次いで、部品管理制御部１３１がこのイベント通知に対応するイベント通知をサービスロジック部１４０に行う。
【００６５】
これにより、サービスロジック部１４０は、部品管理制御部１３１から着信通知を表わすイベント通知を受ける（ステップＳＴ２０１）。なお、このイベント通知には、発信者Ａの端末２０１の番号と、ガイダンス再生者ＭＳのメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」とが含まれており、サービスロジック部１４０は、受信したイベント通知に関連付けて、端末２０１の番号とメディアサーバＭＳの番号を、サービス情報記憶部１５０に一時的に記憶しておく。
そして、サービスロジック部１４０は、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データα（図６参照）を参照して、番号を変換するとともに、サービスパターンを決定する。
【００６６】
サービスロジック部１４０は、イベント通知に含まれるメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」に基づき、加入者データαを参照して、着端末側のメディアサーバ３００の番号を、論理番号「０１２０−ｅｅｅ−ｆｆｆ」と対応付けられている物理番号「０３−ｇｇｇｇ−ｈｈｈｈ」に変換する。また、サービスロジック部１４０は、この着端末側のメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」と対応付けられているサービスパターン「ガイダンス接続」を、発信者Ａの端末装置２０１からの当該イベント通知に対応するサービスパターンと決定する。
【００６７】
次いで、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されているサービスパターン「ガイダンス接続」のプログラムを読み出し、実行する。
これにより、サービスロジック部１４０は、この「ガイダンス接続」のプログラムに従って、接続部品Ｐの部品生成と、ガイダンス再生部品Ｒの部品生成と、切断部品Ｑの部品生成とを行う。なお、この「ガイダンス接続」のプログラムには、接続部品Ｐの部品の生成および削除処理が終了した後、ガイダンス再生部品Ｒの部品生成および削除処理を終了し、その後、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。また、この「ガイダンス接続」のプログラムには、接続部品Ｐの属性情報として、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法（ ｅａｒｌｙ ）が、サービスロジック部１４０によって決められている。また、接続部品Ｐの制御復帰ポイントとしては「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」が、ガイダンス再生部品Ｒの制御復帰ポイントとしては「２００＿ＩＮＦＯメッセージ受信」が、切断部品Ｑの制御復帰ポイントとしては「２００＿ＢＹＥメッセージ受信」が、それぞれ、サービスロジック部１４０によって決められている。
なお、この接続部品Ｐは、属性情報を除いて、上述した接続部品Ｐと同様であるため、詳細な説明は省略する。
【００６８】
この「ガイダンス接続」のプログラムに従って、サービスロジック部１４０は、はじめに接続部品Ｐの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ２０２）。なお、ここで、ＡＰＩ呼出しにはガイダンス再生の音声ファイルとして「天気予報」を表わす情報が関連付けられている。
そして、部品管理制御部１３１によって接続部品Ｐが生成され、接続部品Ｐによって接続処理が実行されると、端末２０１とメディアサーバ３００とが接続中という状態になる。これにより、接続部品Ｐの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０３）。ここで、接続処理が終了する。
そして、サービスロジック部１４０は、部品管理制御部１３１に対して、接続部品Ｐの削除を表わすＡＰＩ呼出しを行うとともに、続けて、ガイダンス再生部品Ｒの部品生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ２０４）。これにより、端末２０１とメディアサーバ３００とが通話状態となり、メディアサーバ３００の音声ファイル「天気予報」の音声を再生することで、端末２０１に天気予報のガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０５）。
【００６９】
一方、例えば端末２０１によって通話中の状態が切断されると、端末２０１は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品機能部１３０を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ２０６）。このとき、通信を切断した端末２０１の番号が、イベント通知とともにサービスロジック部１４０に通知される。
【００７０】
そして、サービスロジック部１４０は、この「ガイダンス接続」のプログラムに従って、イベント通知に含まれる端末２０１の番号に基づき、サービス情報記憶部１５０を参照して、端末２０１と接続中の状態であるメディアサーバ３００に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ２０７）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０１とメディアサーバ３００とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０８）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ２０９）。これにより、端末２０１とメディアサーバ３００の通話に関する状態が全てなくなり、空き状態となる。
【００７１】
次に、図１０を用いて、サービスロジック部１４０が接続部品Ｐ（ｅａｒｌｙ）を生成する一例として、図９に示すステップＳＴ２０１〜２０４に相当するシーケンスについて、より詳細に説明する。なお、接続部品Ｐの「ｅａｒｌｙ」は、図７に示す「ｃｏｎｆｉｒｍｅｄ」のステップＳＴ１１０〜１３６まで同様の処理であるため、詳細な説明を省略する。ただし、図７に示すステップＳＴ１１３においては、属性情報として「ｃｏｎｆｉｒｍｅｄ」に代えて「ｅａｒｌｙ」とする点が異なる。
【００７２】
図１０に示す通り、接続部品Ｐが、ＡＣＫメッセージを着ＵＡ１２３に送信し、これによって、この着ＵＡ１２３から端末２０２にＡＣＫメッセージが送信されると、接続部品Ｐは、１８３メッセージをＵＡ機能部１２０に送信する（ステップＳＴ２１０）。このＵＡ機能部１２０は、発ＵＡ１２２を介して端末２０１に１８３（ＳＤＰ−Ｂ）メッセージを送信する（ステップＳＴ２１１）。そして、端末２０１は、ステップＳＴ２１１で受信した１８３メッセージに１００ｒｅｌオプションが付加されていた場合、ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ２１２）。
発ＵＡ１２２は、ＰＲＡＣＫメッセージをＵＡ管理制御部１２１を介して接続部品Ｐに送信する（ステップＳＴ２１３）。接続部品Ｐは、ＰＲＡＣＫメッセージが制御復帰ポイントではないため、ＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５にＰＲＡＣＫメッセージを送信する（ステップＳＴ２１４）。そして、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＰＲＡＣＫメッセージを送信する（ステップＳＴ２１５）。
【００７３】
これを受けて、メディアサーバ３００は、２００＿ＰＲＡＣＫメッセージを着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２１６）。そして、着用ＭＳ−ＵＡ１２５は、ＵＡ管理制御部１２１を介して、２００＿ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ２１７）。この接続部品Ｐは、２００＿ＰＲＡＣＫメッセージをＵＡ管理制御部１２１を介して発ＵＡ１２２に送信する（ステップＳＴ２１８）。これにより、発ＵＡ１２２は、２００＿ＰＲＡＣＫメッセージを端末２０１に送信する（ステップＳＴ２１９）。
これにより、接続部品Ｐが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ２２０）。そして、サービスロジック部１４０は、「ガイダンス接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ２２１）。これを受けて、部品管理制御部１３１は、接続部品Ｐを削除する。
以上によって、端末２０１とメディアサーバ３００の接続が完了し、通話中となる。
【００７４】
次に、図１１を用いて、サービスロジック部１４０がガイダンス再生部品Ｒを生成する一例として、図９に示すステップＳＴ２０４、２０５に相当するシーケンスについて、より詳細に説明する。
図１１に示す通り、サービスロジック部１４０は、「ガイダンス接続」のプログラムに従って、ガイダンス再生部品Ｒを生成する指示をＡＰＩ呼出しする（ステップＳＴ２５１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「ガイダンス再生部品Ｒ」、制御復帰ポイント「２００＿ＩＮＦＯメッセージ受信」、音声ファイル「天気予報」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、ガイダンス再生側のメディアサーバ３００の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００７５】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、ガイダンス再生部品Ｒを生成する。生成されたガイダンス再生部品Ｒは、メッセージテーブルデータを参照して、ＩＮＦＯメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５２）。
これにより、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＩＮＦＯ（発ガイダンス再生指示）メッセージを送信する（ステップＳＴ２５３）。そしてメディアサーバ３００は、２００＿ＩＮＦＯメッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ２５４）。
そして、ＵＡ管理制御部１２１は、２００＿ＩＮＦＯメッセージをガイダンス再生部品Ｒに送信すると（ステップＳＴ２５５）、メディアサーバ３００が音声ファイル「天気予報」を再生し、ガイダンスを端末２０１に流す。
【００７６】
音声ファイルの再生時間が終了すると、メディアサーバ３００は、ＩＮＦＯ（発ガイダンス完了通知）メッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ２５６）。このＵＡ管理制御部１２１は、ＩＮＦＯメッセージをガイダンス再生部品Ｒに送信する（ステップＳＴ２５７）。このガイダンス再生部品Ｒは、２００＿ＩＮＦＯメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５８）。この着用ＭＳ−ＵＡ１２５は、２００＿ＩＮＦＯメッセージをメディアサーバ３００に送信する（ステップＳＴ２５９）。
【００７７】
これにより、ガイダンス再生部品Ｒが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ２６０）。このサービスロジック部１４０は、「ガイダンス接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ２６１）。これを受けて、部品管理制御部１３１は、ガイダンス再生部品Ｒを削除する。
以上によって、端末２０１に対してメディアサーバ３００のガイダンス再生が終了する。
そして、この後、図８を用いて説明したように、切断部品Ｑを作成して削除する処理を行う。
【００７８】
［網内発呼サービス（モーニングコールサービス）の例］
次に、図１２〜１６を用いて、端末２０１に対してメディアサーバ３００に記憶されているモーニングコールの音声データを再生するため、端末２０１とメディアサーバ３００との２者間のセッションを確立するための網内発呼パターンについて説明する。
図１２は、この網内発呼パターンのメッセージ送受信を表わすイメージ図である。
【００７９】
この網内発呼パターンは、まず図１２に実線で示すようにして、サービスロジック部１４０が、発呼部品Ｓを用いて端末２０３およびメディアサーバ３００を呼び出して通話状態とした後に、メディアサーバ３００の音声ファイルをメディア変更部品Ｔを利用して再生する方法である。
【００８０】
ここでは、例えば発信者Ａによって、端末２０３を介して予めモーニングコールを毎日午前７時に、この端末２０３にかけてもらうサービスが設定されているとする。具体的に説明すると、発信者Ａによって、端末２０３を介して、モーニングコールの設定を受け付ける番号がダイヤルされると、端末２０３、通信サービス提供サーバ１００に対して、モーニングコールの設定を要求するメッセージに自身の電話番号を関連付けて送信する。すると、このメッセージは、サービスロジック部１４０に通知され、サービス情報記憶部１５０の加入者データβに記録される。
【００８１】
なお、この加入者データβについて、図１４を用いて説明すると、端末２０３の電話番号（すなわち、契約者番号「０８５２−ｉｉ−ｊｊｊｊ」）と、モーニングコールの設定日時（すなわち、発呼日時「毎日７：００」）と、提供される音声データを表す音声ファイル「モーニングコール」とが、対応付けられている。また、この加入者データβは、サービス情報記憶部１５０に記憶されている。
【００８２】
次に、図１３を参照して、この網内発呼パターンの状態遷移について説明する。図１３は、網内発呼パターンにおける状態遷移の一例を示す概略図である。
図１３に示す通り、サービスロジック部１４０は、加入者データβに基づき、発呼日時「毎日７：００」に到達したか否かを判断する。そして、発呼日時に到達した場合（ステップＳＴ３０１）、サービスロジック部１４０は、この発呼日時と対応付けられているサービスパターン「網内発呼（モーニングコール）」をサービスパターンとして決定する。
【００８３】
次いで、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されているサービスパターン「網内発呼（モーニングコール）」のプログラムを読み出し、実行する。
これにより、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、発呼部品Ｓの部品生成と、メディア変更部品Ｔの部品生成と、切断部品Ｑの部品生成を行う。
なお、この「網内発呼（モーニングコール）」のプログラムには、端末２０３を呼び出すための発呼部品Ｓの部品の生成および削除処理と、メディアサーバ３００を呼び出すための発呼部品Ｓの部品の生成および削除処理とが終了した後、メディア変更部品Ｔの部品の生成および削除処理と、ガイダンス再生部品Ｒの部品の生成および削除処理とを行い、最後に、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。
【００８４】
そして、この「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、はじめに端末２０３を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０２）。
そして、部品管理制御部１３１によって発呼部品Ｓが生成され、発呼部品Ｓによって呼び出し処理が実行されると、端末２０３が読み出され、端末２０３が発呼中となる。すなわち、端末２０３と通信サービス提供サーバ１００とが接続状態となる。
これにより、発呼部品Ｓの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ３０３）。ここで、呼び出し処理が終了する。
【００８５】
続けて、「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、メディアサーバ３００を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０４）。
そして、部品管理制御部１３１によって発呼部品Ｓが生成され、発呼部品Ｓによって呼び出し処理が実行されると、メディアサーバ３００が読み出され、メディアサーバ３００が発呼中となる。すなわち、メディアサーバ３００と通信サービス提供サーバ１００とが接続状態となる。
これにより、発呼部品Ｓの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ３０５）。ここで、呼び出し処理が終了する。
【００８６】
次いで、「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、メディア変更部品Ｔの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０６）。この部品管理制御部１３１によってメディア変更部品Ｔが生成され、メディア変更部品Ｔによってメディア変更処理が実行される（ステップＳＴ３０７）。結果、端末２０３とメディアサーバ３００とが通信サービス提供サーバ１００を介して接続状態となる。
これにより、メディア変更部品Ｔの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、メディア変更部品Ｔの削除を表わすＡＰＩ呼出しを行うとともに、続けて、ガイダンス再生部品Ｒの部品生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ３０８）。これにより、端末２０３とメディアサーバ３００とが通話状態となり、メディアサーバ３００の音声ファイル「モーニングコール」の音声を再生することで、端末２０３にモーニングコールのガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ３０９）。
【００８７】
一方、例えば端末２０３によって通話中の状態が切断されると、端末２０３は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品機能部１３０を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ３１０）。このとき、通信を切断した端末２０３の番号が、イベント通知とともにサービスロジック部１４０に通知される。
あるいは、メディアサーバ３００による音声ファイル「モーニング」の音声データの再生時間が終了することによって、ガイダンス再生の終了を表すメッセージが、通信プロトコルスタック１１０、ＵＡ機能部１２０、および部品機能部１３０を介してサービスロジック部１４０に切断通知を表わすメッセージとしてイベント通知されるものであってもよい。
【００８８】
そして、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、イベント通知に含まれる端末２０３の番号に基づき、サービス情報記憶部１５０を参照して、端末２０３と接続中の状態であるメディアサーバ３００に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３１１）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０３とメディアサーバ３００とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ３１２）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ３１３）。これにより、端末２０３とメディアサーバ３００の通話に関する状態が全てなくなり、空き状態となる。
【００８９】
次に、図１５を用いて、サービスロジック部１４０が発呼部品Ｓを生成する一例として、図１３に示すステップＳＴ３０１〜３０３に相当するシーケンスについて、より詳細に説明する。
図１５に示す通り、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されている加入者データβを参照して、発呼日時に到達したか否かを判断し、発呼日時に到達した場合、サービスパターンとして、「網内発呼（モーニングコール）」を決定する。そして、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、端末２０３を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３２１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「発呼部品Ｓ」、制御復帰ポイント「２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、発信側の端末２０３の番号を発信側番号Ａとを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００９０】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、発呼部品Ｓを生成する。生成された発呼部品Ｓは、メッセージテーブルデータを参照して、ＩＮＶＩＴＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ３２２）。
これにより、ＵＡ機能部１２０は発ＵＡ１２２に対してＡＰＩ呼出しを行い、発ＵＡ１２２は、端末２０３に対してＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３２３）。そして、端末２０３は、発ＵＡ１２２に１００メッセージを送信し（ステップＳＴ３２４）、その後、１８０メッセージも送信する（ステップＳＴ３２５）。
【００９１】
端末２０３から１８０メッセージを受信すると、発ＵＡ１２２は、１８０メッセージを発呼部品Ｓに送信する（ステップＳＴ３２６）。
続けて、端末２０３は、発ＵＡ１２２に２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３２７）。この発ＵＡ１２２は、２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを発呼部品Ｓに送信する（ステップＳＴ３２８）。
これにより、発呼部品Ｓは、部品管理制御部１３１を介してサービスロジック部１４０に呼確立通知（Ａ）を行い（ステップＳＴ３２９）、サービスロジック部１４０に制御を復帰させる。
【００９２】
サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、発呼部品Ｓの制御を継続させることを決定し、部品継続メッセージを発呼部品Ｓに送信する（ステップＳＴ３３０）。これを受けて、発呼部品Ｓは、ＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ３３１）。この着ＵＡ１２３は、端末２０３にＡＣＫメッセージを送信する（ステップＳＴ３３２）。
これにより、発呼部品Ｓは、部品終了通知をサービスロジック部１４０に通知する（ステップＳＴ３３３）。そして、サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、発呼部品Ｓの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ３３４）。これを受けて、部品管理制御部１３１は、発呼部品Ｓを削除する。
以上によって、端末２０３の呼び出しが完了する。
なお、メディアサーバ３００を呼び出すための発呼部品Ｓの生成処理も同様であるため、詳細な説明は省略する。
【００９３】
次に、図１６を用いて、サービスロジック部１４０がメディア変更部品Ｔを生成する一例として、図１３に示すステップＳＴ３０６〜３０８に相当するシーケンスについて、より詳細に説明する。
図１６に示す通り、サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従って、メディア変更部品Ｔを生成する指示をＡＰＩ呼出しする（ステップＳＴ３５１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「メディア変更部品Ｔ」、制御復帰ポイント「メディアサーバ３００からの２００＿ＵＰＤＡＴＥメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、発呼部品Ｓによって呼び出されている端末２０３とメディアサーバ３００の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００９４】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、メディア変更部品Ｔを生成する。生成されたメディア変更部品Ｔは、メッセージテーブルデータを参照して、ＵＰＤＡＴＥメッセージをＵＡ管理制御部１２１を介して発ＵＡ１２２に送信する（ステップＳＴ３５２）。
これにより、発ＵＡ１２２は、端末２０３に対してＵＰＤＡＴＥ（ＳＤＰ−Ｂ）メッセージを送信する（ステップＳＴ３５３）。そして、端末２０３は、２００＿ＵＰＤＡＴＥ（ＳＤＰ−Ｂ）メッセージを発ＵＡ１２２を介してＵＡ管理制御部１２１に送信する（ステップＳＴ３５４）。
【００９５】
そして、ＵＡ管理制御部１２１は、２００＿ＵＰＤＡＴＥメッセージをメディア変更部品Ｔに送信する（ステップＳＴ３５５）。このメディア変更部品Ｔは、受信した２００＿ＵＰＤＡＴＥメッセージがメディアサーバ３００からでなく、端末２０３からであるため、サービスロジック部１４０に制御を復帰させず、ＵＰＤＡＴＥメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５６）。
これにより、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＵＰＤＡＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３５７）。そして、メディアサーバ３００は、２００＿ＵＰＤＡＴＥ（ＳＤＰ−Ａ）メッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ３５８）。
【００９６】
そして、ＵＡ管理制御部１２１は、２００＿ＵＰＤＡＴＥメッセージをメディア変更部品Ｔに送信する（ステップＳＴ３５９）。このメディア変更部品Ｔは、受信した２００＿ＵＰＤＡＴＥメッセージがメディアサーバ３００から受信したメッセージであるため、サービスロジック部１４０に制御を復帰させる。つまり、メディア変更部品Ｔが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ３６０）。このサービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、メディア変更部品Ｔの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ３６１）。これを受けて、部品管理制御部１３１は、メディア変更部品Ｔを削除する。
【００９７】
このように、本実施形態に係る通信サービス提供サーバ１００は、図１７に示す通り、部品１３２とサービスロジック部１４０とが分離されており、部品１３２と複数のＵＡとが、両者のＳＩＰ信号レベルでのイベントのインタワークを行う。
また、部品１３２は、サービスロジック部１４０へのイベント通知（部品中断やサービスロジックへの制御復帰）および、サービスロジック部１４０からのＡＰＩ呼出し受信（部品継続（中断していた部品の再開））等を行う。
【００９８】
また、本実施形態に係る部品機能部１３０は、図１８に示す通り、空きの状態において、サービスロジック部１４０から部品生成のためのＡＰＩ呼出しを受けると、部品管理制御部１３１が、ＡＰＩ呼出しによる部品生成を実行し、部品を生成する。これにより生成された部品は、制御復帰ポイントに到達すると、部品における制御処理を中断して、サービスロジック部１４０にイベント通知をする。
サービスロジック部１４０は、このイベント通知を受けて、部品を継続するか、あるいは削除するかを判断する。このサービスロジック部１４０は、継続する場合、部品管理制御部１３１に部品継続を表わすＡＰＩ呼出しを行い、一方、部品を削除する場合、部品管理制御部１３１に部品削除を表わすＡＰＩ呼出しを行う。
また、部品１３２は、自身の機能を達成すると、部品終了を表わすイベント通知をサービスロジック部１４０に行うと、部品１３２による制御処理が終了中となる。これを受けたサービスロジック部１４０は、部品削除を表わすＡＰＩ呼出しを部品管理制御部１３１に行う。これにより、当該部品１３２は、部品管理制御部１３１によって削除される。
【００９９】
上述の通り、本実施形態に係る通信サービス提供サーバ１００は、サービスロジック部１４０と部品機能部１３０とにおける制御を分離して、サービスロジック部１４０が必要に応じてサービスパターンで予め決められている部品を呼び出して処理を実行させ、この部品の実行結果を受け取ることで、通信サービスに必要な全処理を行うようにした。
言い換えると、サービスロジック部１４０によってサービスパターンが決定されると、決定されたサービスパターンのプログラムが実行され、プログラムに従って少なくとも１つの部品が生成され、部品による処理が終了したら、当該部品を削除するようにした。
これにより、サービスロジック部１４０は、サービスパターンのプログラムを実行することによって、サービスに依存せず、他のサービスとも共通して利用することができる独立のモジュールである部品を実行させることができる。よって、通信サービスの違いに関わらず、共通して利用することができるため、異なる通信サービスにおいて共通する処理は、同じ種類の部品を利用することによって実現することができる。従って、部品に対応する処理をサービスロジック部１４０を制御するプログラムに全て記載する必要がなく、通信サービスを実行するためのサービスロジックの記載量を低減することができる。
【０１００】
また、上述の通り、サービスロジック部１４０と部品機能部１３０との機能を切り離して、部品機能部１３０が、通信プロトコルスタック１１０およびＵＡ機能部１２０を介して端末２００とメッセージの送受信を行うようにした。これにより、サービスロジック部１４０は、通信プロトコルの処理を実行する必要がなくその制御を単純化することができ、通信プロトコル仕様の変更による影響を受けることなく、部品１３２を制御することができる。よって、通信プロトコル仕様の変更による影響が部品１３２に局所化され、通信プロトコル仕様の変更に伴いサービスロジック部１４０を修正する必要がなくなった。
なお、実施形態によらず、サービスロジック部１４０と部品機能部１３０とが切り離されていない場合、通信サービスに応じたサービスロジックを、通信サービス毎に作成しなければならない。よって、このサービスロジックには、サービスロジック部１４０と部品機能部１３０間で生じるイベント通知とＡＰＩ呼出しとを記述し、さらに、部品機能部１３０とＵＡ管理制御部１２１との間に生じるイベント通知とＡＰＩ呼出しとを記述しなければならなかった。しかし、本実施形態では、サービスロジックには、前者のみを記述すればよく、後者は、部品１３２ごとのメッセージテーブルデータを用意すればよい。よって、サービス毎に作成されるサービスロジックにおいて、部品１３２ごとのメッセージテーブルデータに対応する制御の記述が不要となる。
【０１０１】
さらに、上述の通り、サービスロジック部１４０は、予め決められている制御復帰ポイントを関連付けた部品生成に関する情報を部品管理制御部１３１に送信する。そして、この部品生成に関する情報に基づき部品管理制御部１３１によって生成された部品１３２は、制御復帰ポイントにおいて、サービスロジック部１４０に制御を復帰させるようにした。これにより、部品１３２の制御の途中において、サービスロジック部１４０が当該部品１３２の制御を継続するか否か、あるいは終了するか否かを判断することができる。よって、サービスパターンのプログラムにおいて、通信サービス提供サーバ１００の部品１３２として予め決められている制御処理の一部分のみを利用するサービスロジックを作成することが可能となる。
例えば、部品１３２−１の復帰ポイントでその部品１３２−１を削除し、削除した後に他の部品１３２−２の制御処理を起動するようにサービスロジックを作成することによって、既存の部品１３２の制御処理を変更せずに、部品１３２の制御処理を部分的に利用することができる。
【０１０２】
また、上述の構成により、異なる通信サービスにおいて共通する処理内容の重複記載や重複開発を防止することができ、サービスロジックの作成時間や労力、経費等を削減することができる。さらに、部品に対応する処理の内容が単純化され、新規の通信サービスを追加する際に、部品に対応する処理の開発や記述が不要となり、サービスロジックの追記のみで実現することができる。このため、新規な通信サービスの追加時の時間や労力、経費等を削減することができる。
【０１０３】
従って、本実施形態によらない場合、例えば、サービスを提供するための処理をサービス毎に１つのソフトウェアのブロックを実装しない場合、（１）サービスが異なっても共通する処理（例えば、端末間のセッション制御などのためのメッセージ送受信の処理等）が重複する、（２）サービスの状態の管理とセッション制御の状態の管理が処理ブロック内に混在して制御が複雑になる、（３）新規サービスの追加時に開発量が増えるなどの問題があった。本実施形態に係る通信サービス提供サーバ１００は、このような問題を解決することができる。
また、本実施形態によらない場合、ＳＩＰサーブレットコンテナ、ＨＴＴＰサーブレットコンテナ等の従来のアプリケーションサーバ（ＡＳ）のソフトウェア構造は、サービス固有の処理（サービスロジック）を記述する部分に信号プロトコルの処理が混在していたため、サービスロジックの状態数が多く、構造の複雑化を招いていた。その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
また、Ｗｅｂ Ｓｅｒｖｉｃｅｓから呼制御を行うためのＡＰＩとしてＰａｒｌａｙ−Ｘが標準化されている。Ｐａｒｌａｙ−Ｘと通信プロトコルのゲートウェイも従来のＡＳと同様に、その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
【０１０４】
なお、部品１３２は、上述の機能を有する構成に限られず、通信サービスを構成する制御であればよい。また、部品１３２としては、他の通信サービスと共通して利用することができる制御であることが好ましく、例えば、２対地間の安定状態から次の安定状態への遷移毎に分割される単位での制御であることが好ましい。ここで、安全状態とは、空き、呼出中、通話中など、一定期間継続可能な状態を指し、２対地間の安定状態から次の安定状態への遷移とは、例えば、端末２０１から端末２０２への発呼（空き）〜端末２０１・２０２間の通話（通話中）、端末２０１・２０２間の通話（通話中）〜切断（空き）などの状態遷移をいう。
【０１０５】
なお、通信サービス提供サーバ１００等の動作の過程は、コンピュータに実行させるためのプログラムや、このプログラムとしてコンピュータ読み取り可能な記録媒体として利用可能であり、コンピュータシステムが読み出して実行することによって、上記処理が行われる。なお、ここでいう「コンピュータシステム」とは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０１０６】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に記憶したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【０１０７】
１００ 通信サービス提供サーバ
１１０ 通信プロトコルスタック
１２０ ＵＡ機能部
１２１ ＵＡ管理制御部
１２２ 発ＵＡ
１２３ 着ＵＡ
１２４ 発用ＭＳ ＵＡ
１２５ 着用ＭＳ ＵＡ
１３０ 部品機能部
１３１ 部品管理制御部
１３２ 部品（サービス非依存機能部）
１４０ 通信サービス提供サーバ
１５０ サービス情報記憶部
【技術分野】
【０００１】
本発明は、ネットワークを介して接続される複数の端末に通信に関するサービスを提供する通信サービス提供サーバにおける通信サービス提供方法および通信サービス提供システムに関する。
【背景技術】
【０００２】
近年、ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ、次世代ネットワーク）において、ネットワークを介して接続される端末に対して、サーバから通信サービスを提供するものが知られている。また、このＮＧＮ上のサービス拡充のために、サーバによる多様な通信サービスの提供が望まれている。
【０００３】
例えば、サーバが複数の異なる通信サービスを提供する場合、通信サービス毎にセッション制御を決定するサービスロジックを複数用意しておき、端末から通信サービスを要求するメッセージが送信されると、この要求に応じた通信サービスのサービスロジックに従ってサーバがセッション制御を実行するものがある（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Java Community Process: SIP Servlet v1.1, Java Specification Requests (JSR) 289 (Aug. 2008)
【非特許文献２】ETSI: Open Service Access (OSA); Parlay X Web Services, Draft ETSI, 202, 504 (Jun. 2007)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、通信サービスを提供するためのサービスロジックを通信サービス毎に実装しなければならず効率が悪いという問題がある。
例えば、２者間のセッション制御を行う場合、発信者側の端末と着信者側の端末とを接続するセッション制御や、通話中の端末同士の接続を切断するセッション制御のような基本的な制御は、異なる通信サービスにおいても実施される頻度が高い。このため、通信サービス毎にサービスロジックを用意すると、複数のサービスロジック間で基本的な制御が重複して記載される可能性も高い。よって、サービスの数の増大することに伴い、サービスロジックの記載量が増加するため、その中の重複部分も多くなる可能性もより高くなり、効率が悪くなるという問題がある。
【０００６】
本発明は、このような課題を鑑みてなされたものであり、その目的は、サーバによって提供される通信サービスの効率化を図るための通信サービス提供方法および通信サービス提供システムを提供することにある。
【課題を解決するための手段】
【０００７】
上述した課題を解決するために、本発明は、少なくとも１つの端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバにおける通信サービス提供方法であって、前記通信サービス提供サーバのサービスロジック部が、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するステップと、前記通信サービス提供サーバの部品管理制御部が、前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成させるステップと、前記通信サービス提供サーバの前記サービス非依存機能部が、前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うステップと、を備えることを特徴とする。
【０００８】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記部品生成に関する情報を送信するステップにおいて、前記サービスロジックで前記サービス非依存機能部から通知を受け取るタイミングを表わす制御復帰ポイント情報が予め決められている場合、当該制御復帰ポイント情報を前記部品生成に関する情報に含めて前記部品管理制御部に送信するステップと、前記通信サービス提供サーバの前記サービス非依存機能部が、前記部品制御情報に従ってメッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わすポイントに到達した場合、前記サービスロジック部に対してメッセージを送信するとともに、前記端末とのメッセージの送受信を中断するステップと、を備えることを特徴とする。
【０００９】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記部品生成に関する情報を送信した後、前記サービス非依存機能部からメッセージを受信した場合、前記サービス非依存機能部による制御を継続するか否か、あるいは終了するか否かの少なくとも一方を判断するステップと、前記サービス非依存機能部による制御を継続すると判断した場合、前記サービス非依存機能部に対して、継続を表わすメッセージを送信するステップと、前記サービス非依存機能部による制御を終了すると判断した場合、前記サービス非依存機能部に対して、前記サービス非依存機能部の削除を表わすメッセージを送信するステップと、を備えることを特徴とする。
【００１０】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、発信側の端末から自端末を識別するための第１の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第１の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第１の端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップとを備えることを特徴とする。
【００１１】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、発信側の端末から、着信側の端末を識別するための第２の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第２の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第２端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップとを備えることを特徴とする。
【００１２】
本発明は、上記の発明において、前記通信サービス提供サーバのサービスロジック部が、前記サービスロジックで複数の前記サービス非依存機能部による制御処理の実行が予め決められている場合、前記サービスロジックに従って、複数の前記サービス依存機能部を生成することを特徴とする。
【００１３】
また、上述した課題を解決するために、本発明は、少なくとも１つの端末と、この端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバとを含む通信サービス提供システムであって、前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するサービスロジック部と、前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成する部品管理制御部と、前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うサービス非依存機能部とを備えることを特徴とする。
【発明の効果】
【００１４】
この発明によれば、サーバによって提供される通信サービスの効率化を図ることができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に係るサービス提供システムの一例について示す概略図である。
【図２】本実施形態に係る部品機能部の処理動作の一例について説明するためのフローチャートである。
【図３】本実施形態に係るサービスロジック部の処理動作の一例について説明するためのフローチャートである。
【図４】本実施形態に係るサービスロジック部による基本接続パターンのメッセージ送受信の一例を表わすイメージ図である。
【図５】本実施形態に係るサービスロジック部による基本接続パターンにおける状態遷移の一例を表わすイメージ図である。
【図６】本実施形態に係るサービス情報記憶部に記憶されている加入者データの一例を示す参考図である。
【図７】本実施形態に係る部品機能部による接続部品を生成する処理の一例を説明するシーケンスの図である。
【図８】本実施形態に係る部品機能部による切断部品を生成する処理の一例を説明するシーケンスの図である。
【図９】本実施形態に係るサービスロジック部によるガイダンス接続パターンにおける状態遷移の一例を表わすイメージ図である。
【図１０】本実施形態に係る部品機能部による接続部品を生成する処理の他の例を説明するシーケンスの図である。
【図１１】本実施形態に係る部品機能部によるガイダンス生成部品を生成する処理の一例を説明するシーケンスの図である。
【図１２】本実施形態に係るサービスロジック部による網内発呼パターンのメッセージ送受信の一例を表わすイメージ図である。
【図１３】本実施形態に係るサービスロジック部による網内発呼パターンにおける状態遷移の一例を表わすイメージ図である。
【図１４】本実施形態に係るサービス情報記憶部に記憶されている加入者データの他の例を示す参考図である。
【図１５】本実施形態に係る部品機能部による発呼部品を生成する処理の一例を説明するシーケンスの図である。
【図１６】本実施形態に係る部品機能部によるメディア変更部品を生成する処理の一例を説明するシーケンスの図である。
【図１７】本実施形態に係る通信サービス提供サーバを説明するための参考図である。
【図１８】本実施形態に係る部品機能部を説明するための参考図である。
【発明を実施するための形態】
【００１６】
以下、本発明に係る一実施形態について、図面を参照して説明する。
図１は、本実施形態に係るサービス提供システムの一例について示す概略図である。
図１に示す通り、通信サービス提供システムは、通信サービス提供サーバ１００と、この通信サービス提供サーバ１００とネットワークＮＷを介して接続されている複数の端末２００（例えば、２０１、２０２、２０３、・・・、２０ｎ）と、メディアサーバ３００とを備える。
【００１７】
通信サービス提供サーバ１００は、例えばＳＩＰ（ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ）サーバであって、ＩＴＵ−Ｔ勧告Ｙ．２０１２で規定されるＡｐｐｌｉｃａｔｉｏｎ Ｓｕｐｐｏｒｔ Ｆｕｎｃｔｉｏｎｓ ａｎｄ Ｓｅｒｖｉｃｅ Ｓｕｐｐｏｒｔ Ｆｕｎｃｔｉｏｎｓ（ ＡＳＦ＆ＳＳＦ ）として、ＮＧＮでのアプリケーションサービスを制御する機能を有する。このＡＳＦ＆ＳＳＦの構成要素のうち、Ａｐｐｌｉｃａｔｉｏｎ ｓｕｐｐｏｒｔ ｆｕｎｃｔｉｏｎａｌ ｅｎｔｉｔｙ（ ＡＳ−ＦＥ ）は、各サービスのサービスロジックを収容あるいは実行する機能要素であり、サービス種別に応じて、呼制御サーバ、プレゼンスサーバ、メッセージングサーバ、カンファレンスサーバ等として機能する。なおＩＴＵ−Ｔ勧告Ｙ．２０１２については、参考文献＜Functional requirements and architecture of the NGN, ITU-T Recommendation Y.2012 (Jul. 2006)＞に詳細に記載されている。
【００１８】
複数の端末２００は、ユーザによって利用される端末装置であって、例えば、電話回線を介して通信サービス提供サーバ１００と接続されている電話機や、無線回線を介して通信サービス提供サーバ１００と接続されている携帯電話機、あるいは、インターネットを介して接続されるコンピュータ等である。
メディアサーバ３００は、音声データ、画像データあるいは動画データ等を記憶しており、通信サービス提供サーバ１００を介して接続された端末装置２００に対して、記憶しているデータを再生する。
【００１９】
また、通信サービス提供サーバ１００は、通信プロトコルスタック１１０と、ＵＡ機能部１２０と、部品機能部１３０と、サービスロジック部１４０と、サービス情報記憶部１５０とを備える。なお、サービスロジック部１４０側をメッセージの送受信の上流、通信プロトコルスタック１１０側をその下流とすると、端末２００から受信したメッセージを、通信プロトコルスタック１１０、ＵＡ機能部１２０、部品機能部１３０、サービスロジック部１４０の順番で、下流から上流に向かって送信することをイベント通知という。また、サービスロジック部１４０から送信されたメッセージを、部品機能部１３０、ＵＡ機能部１２０、通信プロトコルスタック１１０の順番で、上流から下流に向かって送信することをＡＰＩ（ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ ）呼出しという。
【００２０】
通信プロトコルスタック（メッセージ送受信部）１１０は、ネットワークＮＷで用いられるプロトコルのプロトコルスタックとして機能し、例えば、ＳＩＰおよびＨＴＴＰ、ＩＳＵＰ、ＩＮＡＰ、Ｄｉａｍｅｔｅｒ等の各種プロトコルに基づき、メッセージのエンコードおよびデコードを行う。
【００２１】
ＵＡ（ Ｕｓｅｒ Ａｇｅｎｔ ）機能部１２０は、端末間のセッションを確立するため、端末間とのメッセージの送受信を行う。
具体的に説明すると、ＵＡ機能部１２０は、ＵＡ管理制御部１２１を備え、複数のＵＡ、例えば、発ＵＡ１２２、着ＵＡ１２３、発用ＭＳ−ＵＡ１２４、および着用ＭＳ−ＵＡ１２５として機能する。また、ＵＡ機能部１２０は、内部に記憶部１２６を備える。
また、ＵＡ機能部１２０は、部品機能部１３０からメッセージを受け取ると、このメッセージに応じたＵＡのインスタンスを生成する。
【００２２】
ＵＡ管理制御部１２１は、通信プロトコルスタック１１０あるいは部品機能部１３０からメッセージを受け取ると、このメッセージに応じたＵＡのインスタンスを生成する。
また、ＵＡ管理制御部１２１は、複数のＵＡ（発ＵＡ１２２、着ＵＡ１２３、発用ＭＳ−ＵＡ１２４、および着用ＭＳ−ＵＡ１２５）のそれぞれを識別する固有のＵＡ識別番号と、部品機能部１３０によって生成される部品のそれぞれを識別するための固有の部品番号とを対応付けて記憶する記憶部１２６を有している。このＵＡ管理制御部１２１は、この記憶部１２６を参照して、複数のＵＡと複数の部品との間のイベントバスとして、メッセージの送受信を制御する。例えば、ＵＡ管理制御部１２１は、発ＵＡ１２２からメッセージを受信した場合、記憶部１２６を参照して、発ＵＡ１２２から受信したメッセージを、部品が生成されていないならば、部品管理制御部１３１に送信する。なお、部品が生成されているか否かが判断され、部品が生成されている場合、ＵＡ管理制御部１２１は、生成されている部品に対してメッセージを送信する。
さらに、ＵＡ管理制御部１２１は、生成されたＵＡが通信プロトコルスタック１１０から受けたイベント通知に応じた処理を終了した場合、当該ＵＡのインスタンスを削除する。
【００２３】
複数のＵＡは、対向装置ごとの通信プロトコルレベルでの状態管理を行う。つまり、発ＵＡ１２２は発信側の端末と、着ＵＡ１２３は着信側の端末と、発用ＭＳ−ＵＡ１２４は発信側の端末用メディアサーバ（ＭＳ）と、着用ＭＳ−ＵＡ１２５は着信側の端末用メディアサーバ（ＭＳ）と、それぞれＳＩＰ等の通信プロトコルレベルの１セッションの状態管理を行う。
【００２４】
部品機能部１３０は、部品管理制御部１３１および部品１３２として機能し、受信したメッセージと送信するメッセージとが予め決められた組み合わせで対応付けられているメッセージテーブルデータを記憶する記憶部１３３を備える。この部品機能部１３０は、この記憶部１３３を参照して、ＵＡ機能部１２０あるいはサービスロジック部１４０から受信したメッセージに対応するメッセージの送信を行う。
このようにして、部品機能部１３０は、サービスに依存していないメッセージテーブルデータを参照して動作することにより、サービスに依存しないＳＩＰ信号レベルでの２者間のセッション制御を行っている。
例えば、特定のサービスにのみ特化しているサービスロジックを利用して、１つの通信サービスに対して、それぞれ、１つの通信サービスを実行するソフトフェアのブロックを必要とする場合、これらのソフトウェアのブロックは、サービスに依存していることとなる。一方、異なる通信サービスに対して、共通して利用可能なソフトウェアのブロックを通信サービスに応じて呼出し、通信サービスを実行する場合、これらのソフトウェアのブロックは、サービスに依存していないこととなる。
【００２５】
部品管理制御部１３１は、サービスロジック部１４０から受けたＡＰＩ呼出しに応じて、部品１３２のインスタンスを生成する。このＡＰＩ呼出しには、部品生成に関する情報が含まれており、例えば、部品の種類、部品の属性、発信側の端末の番号、着信側の端末の番号、制御復帰ポイント等を表わす情報が含まれている。
部品の種類とは、後述する接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔを表わす。また、部品の属性情報とは、例えば、接続部品に関しては接続方法を表わす情報であり、発信側のダイアログを確立することを要する方法（ ｃｏｎｆｉｒｍｅｄ ｄｉａｌｏｇ ）であること、あるいは、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法（ ｅａｒｌｙ ｄｉａｌｏｇ ）であることを表わす。
また、部品管理制御部１３１は、生成された部品１３２とサービスロジック部１４０との間のイベントバスであって、部品１３２とサービスロジック部１４０との間のメッセージの送受信を行う。
さらに、部品管理制御部１３１は、部品１３２から処理を終了することを表すメッセージを受け付けた場合、サービスロジック部１４０へイベント通知を行い、サービスロジック部１４０のＡＰＩ呼出しに応じて当該部品のインスタンスを削除する。
【００２６】
部品１３２は、部品管理制御部１３１によって生成されることで、例えば、接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔとして機能するものであり、例えば、プログラムのモジュールである。
この部品１３２は、部品毎に予め決められているメッセージテーブルデータを参照して、ＳＩＰ信号レベルでの２者間のセッション制御を行う。このメッセージテーブルデータは、部品１３２の制御内容を表わす部品制御情報であって、受信したメッセージに応じて、部品１３２が送信するメッセージが対応付けられている。
また、部品１３２は、部品管理制御部１３１によって生成された際に、制御復帰タイミングが予め決められている場合、この制御復帰タイミングに合わせて、サービスロジック部１４０に対して制御の復帰を行う。つまり、部品１３２は、制御復帰タイミングとなると、サービスロジック部１４０に対してイベント通知を行う。
さらに、部品１３２は、部品管理制御部１３１によって生成された際に決められているメッセージ送信先に対してメッセージを送信する。なお、このメッセージ送信先は、部品１３２の生成を指示するＡＰＩ呼出しを部品管理制御部１３１に行うサービスロジック部１４０によって決定されるものであり、部品１３２は、サービスロジック部１４０によって決定されたメッセージ送信先にメッセージを送信することができる。
【００２７】
なお、複数の接続部品Ｐ、切断部品Ｑ、ガイダンス再生部品Ｒ、発呼部品Ｓ、メディア変更部品Ｔは、上述の通り、それぞれを識別するための部品識別番号を有しており、部品機能部１３０に内蔵された記憶部１３３が、メッセージの送受信を行う部品を表わす部品識別番号と、ＵＡを表わすＵＡ識別番号とを関連付けて記憶する。
【００２８】
サービスロジック部１４０は、通信サービスの制御内容を表わすサービスロジック（すなわち、サービスパターンのプログラム）に従って通信サービスの提供を開始する場合、通信サービスロジックに依存せずに自身の機能を発揮する部品１３２のうちサービスロジックにおいて予め決められている部品１３２を表わす部品生成に関する情報を送信する。
つまり、サービスロジック部１４０は、サービス情報記憶部１５０を参照して、サービスパターンのプログラムを実行することにより、サービスに依存する通信サービス制御を実現するとともに、サービスに依存せずに通信サービス制御を実行する部品１３２に対して制御を指示するためのＡＰＩ呼出しを行う。
具体的に説明すると、サービスロジック部１４０は、サービス情報記憶部１５０を参照して、部品管理制御部１３１からのイベント通知に基づき、サービスパターンを決定する。また、サービスロジック部１４０は、決定されたサービスパターンのプログラムを実行する。
ここで、サービスロジックとは、サービスロジック部１４０によって実行されるサービスパターンのプログラムである。
【００２９】
また、サービスロジック部１４０は、サービスパターンのプログラムに従って、部品のインスタンスの生成、継続、削除を行うことで、サービスに応じた少なくとも２者間のセッション制御を行う。
さらに、サービスロジック部１４０は、部品１３２からの制御の復帰待ち状態において、部品管理制御部１３１を介して部品１３２からイベント通知を受けると、サービスに依存しているサービスパターンの制御を継続する。これにより、サービスに依存せずに通信サービス制御を実行する部品１３２から、サービスに依存する通信サービス制御を実行するサービスロジック部１４０の制御へと切り替わり、制御が復帰される。
【００３０】
また、サービスロジック部１４０は、サービスパターンのプログラムに従って動作することにより、サービスに依存する接続先決定方法の選択を行う。
さらに、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されている情報を参照して、課金サービスやデータ変換等を行う。例えば、発信側の端末２０１の番号または着信側の端末２０２の番号に基づき、加入者に応じた課金情報が予め対応付けられている加入者データを参照することで、端末２０１または端末２０２に課金される通話代を求めることができる。また、発信側の端末２０１がダイヤルした番号が論理番号である場合、サービス情報記憶部１５０を参照して、この論理番号に対応付けられている物理番号を得て、論理番号を物理番号に変換する。
【００３１】
サービス情報記憶部１５０は、各通信サービスを端末に提供するため、サービスロジック部１４０が実行する際に利用する情報を記憶する。このサービス情報記憶部１５０は、例えば、ユーザを識別する識別情報（電話番号、契約番号等）と、このユーザのサービスの契約内容を表わす情報とが対応付けられている加入者データを記憶する。また、このサービス情報記憶部１５０は、発信側の端末２００の電話番号や着信側の端末２００の電話番号等を一次的に記憶する。
【００３２】
次に、図２を用いて、部品機能部１３０の処理動作の一例について説明する。図２は、部品機能部１３０の処理動作の一例について説明するためのフローチャートである。
図２に示す通り、部品管理制御部１３１は、サービスロジック部１４０から部品生成を表わすＡＰＩ呼出しを受けると、このＡＰＩ呼出しに応じた部品１３２を生成する（ステップＳＴ１）。言い換えると、部品管理制御部１３１は、ＡＰＩ呼出しに含まれる部品生成に関する情報（例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報）に応じた部品１３２のプログラムを起動し、実行する。なお、部品１３２は、上記部品生成に関する情報を一時的に部品機能部１３０内の記憶部１３３に記憶しておく。
これにより、ステップＳＴ１で生成された部品１３２は、サービスロジック部１４０の部品生成より以前に端末から通信サービス提供サーバ１００が受信していたメッセージ（例えば、通信を要求するメッセージ）に対応するメッセージをＵＡ機能部１２０に送信する。一方、ＵＡ機能部１２０からメッセージを受信した場合、部品１３２は、このメッセージに対応するメッセージをＵＡ機能部１２０に送信する。すなわち、部品１３２は、ＵＡ機能部１２０に対してメッセージの送受信を行う（ステップＳＴ２）。
そして、ステップＳＴ２において、部品１３２の生成時にサービスロジック部１４０から指定された制御復帰ポイントに表わされているメッセージを、ＵＡ機能部１２０から受信した場合、部品１３２は、復帰タイミングであると判断し（ステップＳＴ３−ＹＥＳ）、ＵＡ機能部１２０から受信したメッセージに対応するメッセージをサービスロジック部１４０にイベント通知する（ステップＳＴ４）。そして、部品１３２は、以降の処理を中断する（ステップＳＴ５）。
【００３３】
その後、サービスロジック部１４０から継続の指示があった場合（ステップＳＴ６−継続）、部品１３２は、ステップＳＴ２において行っていたメッセージ送受信の続きを継続して実行する（ステップＳＴ７）。そして、部品終了のタイミングとなったら（ステップＳＴ８−ＹＥＳ）、部品管理制御部１３１は、部品１３２を削除する（ステップＳＴ９）。一方、ステップＳＴ８において部品終了のタイミングでない場合、ステップＳＴ２に戻る（ステップＳＴ８−ＮＯ）。
また、ステップＳＴ６において、サービスロジック部１４０から部品削除の指示を表わすＡＰＩ呼出しがあった場合（ステップＳＴ６−削除）、部品管理制御部１３１は、部品１３２を削除する（ステップＳＴ９）。
【００３４】
次に、図３を用いて、サービスロジック部１４０の処理動作の一例について説明する。図３は、サービスロジック部１４０の処理動作の一例について説明するためのフローチャートである。
図３に示す通り、サービスロジック部１４０は、部品管理制御部１３１からイベント通知を受けると（ステップＳＴ１１−ＹＥＳ）、このイベント通知に基づき、サービス情報記憶部１５０を参照して、サービスパターンを決定する（ステップＳＴ１２）。
【００３５】
一方、イベント通知がない場合であっても（ステップＳＴ１１−ＮＯ）、予め決められたイベントタイミングを表わす情報がサービス情報記憶部１５０に記憶されている場合、このイベントタイミングを表わす情報に到達したか否かを判断する（ステップＳＴ１３）。そして、イベントタイミングに到達した場合（ステップＳＴ１３−ＹＥＳ）、サービスロジック部１４０は、このイベントタイミングに基づき、サービス情報記憶部１５０を参照してサービスパターンを決定する（ステップＳＴ１４）。
【００３６】
ステップＳＴ１２あるいはステップＳＴ１４においてサービスパターンが決定されると、サービスロジック部１４０は、この決定されたサービスパターンのプログラムを実行する（ステップＳＴ１５）。
つまり、サービスロジック部１４０は、このサービスパターンのプログラムに従って、部品１３２の生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ１６）。なお、この時、サービスロジック部１４０は、サービスパターンのプログラムに従い、部品生成に関する情報（例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報）を作成してＡＰＩ呼出しとともに部品管理制御部１３１に送信する。
【００３７】
一方、ＡＰＩ呼出しに基づき部品管理制御部１３１によって生成された部品１３２は、部品生成に関する情報として、制御復帰ポイントを表わす情報が含まれている場合、対応するメッセージをＵＡ機能部１２０から受信すると、受信したメッセージに対応するメッセージをサービスロジック部１４０にイベント通知する。すなわち、サービスロジック部１４０に制御を復帰させる。
【００３８】
ここで、このサービスロジック部１４０への制御が復帰された場合（ステップＳＴ１７−ＹＥＳ）、すなわち、サービスロジック部１４０が部品管理制御部１３１を介して部品１３２からのイベント通知を受けた場合、サービスロジック部１４０は、部品１３２の動作処理を継続するか否かを判断する（ステップＳＴ１８）。なお、部品１３２の動作処理を継続するか、あるいは終了するかを表わす情報は、サービスパターンにおいて予め決められている。
そして、部品を継続する場合、部品１３２の制御処理の継続指示を表わすＡＰＩ呼出しを行う（ステップＳＴ１９）。その後、部品１３２の終了を表わすイベント通知を受けたか否かを判断し（ステップＳＴ２０）、受けていない場合、さらにサービスロジック部１４０への制御復帰が行われるか否かをステップＳＴ１７に戻って判断する。
【００３９】
一方、ステップＳＴ１８で、サービスパターンのプログラムにおいて、継続の指示でなく（ステップＳＴ１８−ＮＯ）、終了の指示が予め決められていた場合（ステップＳＴ２１）、サービスロジック部１４０は、部品１３２の削除を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ２２）。
そして、サービスパターンのプログラムに従って、サービスロジック部１４０は、さらに部品の生成があるか否かを判断し（ステップＳＴ２３）、さらに部品を生成する場合、ステップＳＴ１６に戻る。
【００４０】
次に、本実施形態に係るサービス提供システムにおいて、それぞれ異なる部品を利用して通信サービスを提供する例について説明する。
【００４１】
［番号変換サービス（基本接続）の例］
はじめに、図４〜８を用いて、発信者により端末２０１を介して呼び出された番号を変換するとともに、発信者の端末２０１と着信者の端末２０２との２者間のセッションを確立するための基本接続パターンについて説明する。
図４は、この基本接続パターンのメッセージ送受信を表わすイメージ図である。図５は、基本接続パターンにおける状態遷移の一例を示す概略図である。
【００４２】
まず、図４に点線で示すような、端末２０１からの接続要求をサービスロジック部１４０に伝達する方法について説明する。
図４に示す通り、例えば発信者によって番号「０１２０−ａａａ−ｂｂｂ」がダイヤルされると、端末２０１は、通信サービス提供サーバ１００に対して通話（接続）を要求するメッセージを送信する。すると、このメッセージは、通信サービス提供サーバ１００の通信プロトコルスタック１１０によって変換され、発ＵＡ１２２に送信される。そして、発ＵＡ１２２は、通信プロトコルスタック１１０から送信されたメッセージに基づくイベント通知をＵＡ管理制御部１２１に行い、次いで、部品管理制御部１３１がこのイベント通知に対応するイベント通知をサービスロジック部１４０に行う。
【００４３】
これにより、サービスロジック部１４０は、図５に示す通り、部品管理制御部１３１から着信通知を表わすイベント通知を受ける（ステップＳＴ１０１）。なお、このイベント通知には、発信者の端末２０１の番号と、着信者の端末２０２の論理番号「０１２０−ａａａ−ｂｂｂ」とが含まれており、サービスロジック部１４０は、受信したイベント通知に関連付けて、端末２０１の番号と端末２０２の番号を、サービス情報記憶部１５０に一時的に記憶しておく。
そして、サービスロジック部１４０は、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データを参照して、着信者の端末２０２の論理番号に対応する物理番号へ番号変換するとともに、サービスパターンを決定する。
【００４４】
具体的に説明すると、サービス情報記憶部１５０には、例えば図６に示すような加入者データαが記憶されている。この加入者データαは、着信側の端末を識別する論理番号（すなわち、契約者番号）と、着信側の端末を識別する物理番号（すなわち、着端末／ＭＳの電話番号）と、サービスパターンと、音声ファイルとが、それぞれ対応付けられた情報である。
物理番号とは、複数の端末の中から当該端末を識別する固有の端末識別情報である。
論理番号とは、物理番号が表わす契約者が特定の通信サービスを受けるため予め決められている番号であって、当該サービスの契約をしている端末を識別する端末識別情報である。ここでは、論理番号は、発信側の端末によってダイヤルされる電話番号であって、メッセージに関連付けられて、発信側の端末から通信サービス提供サーバ１００に送信される。
【００４５】
サービスパターンとは、論理番号と物理番号との組み合わせに従って決められる通信サービスを実現するためのプログラムの種類を表わす。ここでは、サービスパターンとして、基本接続とガイダンス接続が示されている。
音声ファイルは、サービスパターンにおいて音声データを提供することが含まれている場合、この提供される音声データを表わす情報であって、当該サービスパターンと対応付けられている。なお、この音声ファイルの音声データは、ネットワークを介して接続され、通信サービス提供サーバ１００の外部にあるメディアサーバ３００に記憶されている。
【００４６】
なお、ここでは、論理番号と物理番号との組み合わせに応じてサービスパターンが決定される例を説明するが、本発明はこれに限られず、例えば、論理番号あるいは物理番号のいずれか一方とサービスパターンとが対応づけられている加入者データであってもよい。また、この場合、サービスロジック部１４０は、論理番号あるいは物理番号のいずれか一方と対応付けられているサービスパターンを、実行すべきサービスパターンとして決定するものであってもよい。
また、加入者データは、発信者側の端末の電話番号（契約者番号あるいは物理番号）とサービスパターンが対応付けられ、発信者側の端末の電話番号に応じて、サービスパターンが決定されものであってもよい。
例えば、サービスロジック部１４０は、発信側の端末から自端末を識別するための端末識別情報（例えば、電話番号）が関連付けられた通信サービスの提供を要求するメッセージ（例えば、通話要求）を受信した場合、このメッセージに基づき、この発信側の端末が利用可能な通信サービスのサービスロジックと、当該発信側の端末の端末識別情報とを対応付けた加入者データを記憶するサービス情報記憶部１５０を参照して、端末識別情報と対応付けられているサービスロジックに従って、通信サービスの提供を開始するものであってもよい。
【００４７】
図５に戻って、サービスロジック部１４０は、イベント通知に含まれる着信者Ｂの論理番号「０１２０−ａａａ−ｂｂｂ」に基づき、加入者データαを参照して、着信者Ｂの番号を、論理番号「０１２０−ａａａ−ｂｂｂ」と対応付けられている物理番号「０４２２−ｃｃ−ｄｄｄｄ」に変換する。また、サービスロジック部１４０は、この着信者Ｂの論理番号「０１２０−ａａａ−ｂｂｂ」と対応付けられているサービスパターン「基本接続」を、発信者Ａの端末装置２０１からの当該イベント通知に対応するサービスパターンと決定する。
【００４８】
次いで、サービスロジック部１４０は、サービスパターン「基本接続」のプログラムを実行する。
これにより、サービスロジック部１４０は、この「基本接続」のプログラムに従って、接続部品Ｐの部品生成と、切断部品Ｑの部品生成を行う。なお、この「基本接続」のプログラムには、接続部品Ｐの部品の生成および削除処理が終了した後、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。また、この「基本接続」のプログラムには、接続部品Ｐの属性情報として、発信側のダイアログを確立することを要する方法（ ｃｏｎｆｉｒｍｅｄ ｄｉａｌｏｇ ）が、サービスロジック部１４０によって決められている。また、接続部品Ｐの制御復帰ポイントとしては「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」が、切断部品Ｑの制御復帰ポイントとしては、「２００＿ＢＹＥメッセージ受信」が、サービスロジック部１４０によって決められている。
【００４９】
この「基本接続」のプログラムに従って、サービスロジック部１４０は、はじめに接続部品Ｐの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ１０２）。
そして、部品管理制御部１３１によって接続部品Ｐが生成され、接続部品Ｐによって接続処理が実行されると、端末２０１と端末２０２とが接続中という状態になる。これにより、接続部品Ｐの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ１０３）。ここで、接続処理が終了する。続けて、サービスロジック部１４０は、部品管理制御部１３１に対して、接続部品Ｐの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ１０４）。これにより、端末２０１と端末２０２とが通話状態となる。
【００５０】
次いで、例えば端末２０１によって通話中の状態が切断されると、端末２０１は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品管理制御部１３１を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ１０５）。このとき、通信を切断した端末２０１の番号が、イベント通知とともにサービスロジック部１４０に通知される。
【００５１】
そして、サービスロジック部１４０は、この「基本接続」のプログラムに従って、イベント通知に含まれる端末２０１の番号に基づき、サービス情報記憶部１５０を参照して、端末２０１と接続中の状態である端末２０２に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ１０６）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０１と端末２０２とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ１０７）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ１０８）。これにより、端末２０１と端末２０２の通話に関する状態が全てなくなり、空き状態となる。
【００５２】
次に、図７を用いて、サービスロジック部１４０が接続部品Ｐを生成する一例として、図５に示すステップＳＴ１０１〜１０４に相当するシーケンスについて、より詳細に説明する。
図７に示す通り、発信者Ａから番号「０１２０−ａａａ−ｂｂｂ」への通話が要求されると、端末２０１は、ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを、ネットワークＮＷを介して通信サービス提供サーバ１００に送信する（ステップＳＴ１１０）。すると、ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを受信した通信サービス提供サーバ１００の通信プロトコルスタック１１０が、このＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージをＩＮＶＩＴＥメッセージに変換して、部品管理制御部１３１に送信する（ステップＳＴ１１１）。そして、部品管理制御部１３１は、着信通知を表わすイベント通知をサービスロジック部１４０に通知する（ステップＳＴ１１２）。
【００５３】
ここで、サービスロジック部１４０は、上述の通り、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データを参照して、番号を変換するとともに、サービスパターンを決定するものとする。そこで、「基本接続」のプログラムが決定された場合、サービスロジック部１４０は、この「基本接続」のプログラムに従って、はじめに接続部品Ｐを生成する指示をＡＰＩ呼出しする（ステップＳＴ１１３）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「接続部品Ｐ」、属性情報の接続方法「ｃｏｎｆｉｒｅｄ」、制御復帰ポイント「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、属性情報と、制御復帰ポイントと、発信側の端末２０１の番号を発信側番号Ａと、着信側の端末２０２の番号を着信側番号Ｂとを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００５４】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、接続部品Ｐ（ｃｏｎｆｉｒｅｄ）を生成する。生成された接続部品Ｐは、ステップＳＴ１１１においてＵＡ機能部１２０から受け取っていたＩＮＶＩＴＥメッセージに基づき、メッセージテーブルデータを参照して、ＩＮＶＩＴＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ１１４）。
これにより、ＵＡ機能部１２０は着ＵＡ１２３に対してＡＰＩ呼出しを行い、着ＵＡ１２３は、端末２０２に対してＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ１１５）。そして、端末２０２は、着ＵＡ１２３に１００メッセージを送信し（ステップＳＴ１１６）、その後、１８０メッセージも送信する（ステップＳＴ１１７）。
【００５５】
端末２０２から１８０メッセージを受信すると、着ＵＡ１２３は、１８０メッセージを接続部品Ｐに送信する（ステップＳＴ１１８）。そして、接続部品Ｐは、部品管理制御部１３１を介してサービスロジック部１４０にアラート通知を行い（ステップＳＴ１１９）、サービスロジック部１４０に制御を復帰させる。
【００５６】
サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの制御を継続させることを決定し、部品継続メッセージを接続部品Ｐに送信する（ステップＳＴ１２０）。これを受けて、接続部品Ｐは、１８０メッセージを発ＵＡ１２２に送信する（ステップＳＴ１２１）。この発ＵＡ１２２は、端末２０１に１８０メッセージを送信する（ステップＳＴ１２２）。この端末２０１は、ステップＳＴ１２２で受信した１８０メッセージに１００ｒｅｌオプションが付加されていた場合、ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ１２３）。
【００５７】
そして、発ＵＡ１２２は、ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１２４）。ここで、ＰＲＡＣＫメッセージの受信は、接続部品Ｐの制御復帰ポイントとなっていないため、接続部品Ｐは、ＰＲＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１２５）。これにより、着ＵＡ１２３は、ＰＲＡＣＫメッセージを端末２０２に送信する（ステップＳＴ１２６）。この端末２０２は、２００＿ＰＲＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１２７）。
そして、着ＵＡ１２３は、２００＿ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１２８）。ここで、２００＿ＰＲＡＣＫメッセージの受信も、接続部品Ｐの制御復帰ポイントとなっていないため、接続部品Ｐは、２００＿ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ１２９）。この発ＵＡ１２２は、２００＿ＰＲＡＣＫメッセージを端末２０１に送信する（ステップＳＴ１３０）。
端末２０２から２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ｂ）メッセージが着ＵＡ１２３に送信されると（ステップＳＴ１３１）、着ＵＡ１２３は、２００＿ＩＮＶＩＴＥメッセージを接続部品Ｐに送信する（ステップＳＴ１３２）。
そして、接続部品Ｐは、端末２０１から端末２０２の呼び出しが確立されたことを表わす呼確立通知（Ｂ）をサービスロジック部１４０に送信し（ステップＳＴ１３３）、サービスロジック部１４０に制御を復帰させる。
【００５８】
サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの制御を継続させることを決定し、部品継続メッセージを接続部品Ｐに送信する（ステップＳＴ１３４）。これを受けて、接続部品Ｐは、ＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ１３５）。この着ＵＡ１２３は、端末２０２にＡＣＫメッセージを送信する（ステップＳＴ１３６）。
また、接続部品Ｐは、２００＿ＩＮＶＩＴＥメッセージを発ＵＡ１２２に送信する（ステップＳＴ１３７）。この発ＵＡ１２２は、２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ｂ）メッセージを端末２０１に送信し（ステップＳＴ１３８）、端末２０２からＡＣＫメッセージを受信する（ステップＳＴ１３９）。次いで、発ＵＡ１２２は、ＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ１４０）。
これにより、接続部品Ｐは、部品終了通知をサービスロジック部１４０に通知する（ステップＳＴ１４１）。そして、サービスロジック部１４０は、「基本接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ１４２）。これを受けて、部品管理制御部１３１は、接続部品Ｐを削除する。
以上によって、端末２０１と端末２０２の接続が完了する。
【００５９】
次に、図８を用いて、サービスロジック部１４０が切断部品Ｑを生成する一例として、図５に示すステップＳＴ１０５〜１０８に相当するシーケンスについて、より詳細に説明する。
図８に示す通り、端末２０１と端末２０２は、通話中となっている。この状態において、端末２０１が、発ＵＡ１２２に対してＢＹＥメッセージを送信する（ステップＳＴ１５０）。すると、この発ＵＡ１２２が、ＢＹＥメッセージを部品管理制御部１３１に送信するとともに（ステップＳＴ１５１）、端末２０１に２００＿ＢＹＥメッセージを送信する（ステップＳＴ１５２）。
このＢＹＥメッセージを受信した部品管理制御部１３１は、切断通知（Ａ）を表わすメッセージをサービスロジック部１４０に送信する（ステップＳＴ１５３）。なお、このメッセージには、切断を通知した側の端末として端末２０１を特定する情報（例えば、端末２０１の番号）が関連付けられている。
【００６０】
ここで、上述の通り、既に「基本接続」のプログラムが決定されている場合、サービスロジック部１４０は、この「基本接続」のプログラムに従って、切断部品Ｑを生成する指示をＡＰＩ呼出しする（ステップＳＴ１５４）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「切断部品Ｑ」、制御復帰ポイント「２００＿ＢＹＥメッセージ受信」であるとする。そこで、サービスロジック部１４０は、サービス情報記憶部１５０に一次的に記憶されていた「端末２０１と端末２０２とが通話状態である」ことを表わす情報を読み出し、ステップＳＴ１５３で受信したメッセージに関連付けられている端末２０１と特定する情報に基づき、別の端末２０２を特定する情報を切断する側の端末であることを検出する。
そして、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、切断する側の端末２０２の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００６１】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、切断部品Ｑを生成する。生成された切断部品Ｑは、ステップＳＴ１５１においてＵＡ機能部１２０から受け取っていたＢＹＥメッセージに基づき、メッセージテーブルデータを参照して、ＢＹＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ１５５）。
これにより、ＵＡ機能部１２０は着ＵＡ１２３に対してＡＰＩ呼出しを行い、着ＵＡ１２３は、端末２０２に対してＢＹＥメッセージを送信する（ステップＳＴ１５６）。そして、端末２０２は、着ＵＡ１２３に２００ＢＹＥメッセージを送信する（ステップＳＴ１５７）。
そして、着ＵＡ１２３は、ＵＡ機能部１２０を介して２００＿ＢＹＥメッセージを切断部品Ｑに送信する（ステップＳＴ１５８）。この切断部品Ｑは、部品終了を表わす部品終了通知をサービスロジック部１４０に送信し、サービスロジック部１４０に制御を復帰させる（ステップＳＴ１５９）。
【００６２】
サービスロジック部１４０は、「基本接続」のプログラムに従い、切断部品Ｑの制御を終了させることを決定し、部品削除メッセージを切断部品Ｑに送信する（ステップＳＴ１６０）。
これにより、端末２０１と端末２０２とは通話が切断される。
【００６３】
［番号変換サービス（ガイダンス接続）の例］
次に、図９〜１１を用いて、発信者Ａにより端末２０１を介して呼び出された番号を変換するとともに、発信者Ａの端末２０１と、ガイダンスを再生するメディアサーバ３００との２者間のセッションを確立するためのガイダンス接続パターンについて説明する。
図９は、ガイダンス接続パターンにおける状態遷移の一例を示す概略図である。
【００６４】
図９に示す通り、例えば発信者Ａによって番号「０１２０−ｅｅｅ−ｆｆｆ」がダイヤルされると、端末２０１は、通信サービス提供サーバ１００に対して通話（接続）を要求するメッセージを送信する。すると、このメッセージは、通信サービス提供サーバ１００の通信プロトコルスタック１１０によって変換され、発ＵＡ１２２に送信される。そして、発ＵＡ１２２は、通信プロトコルスタック１１０から送信されたメッセージに基づくイベント通知をＵＡ管理制御部１２１に行い、次いで、部品管理制御部１３１がこのイベント通知に対応するイベント通知をサービスロジック部１４０に行う。
【００６５】
これにより、サービスロジック部１４０は、部品管理制御部１３１から着信通知を表わすイベント通知を受ける（ステップＳＴ２０１）。なお、このイベント通知には、発信者Ａの端末２０１の番号と、ガイダンス再生者ＭＳのメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」とが含まれており、サービスロジック部１４０は、受信したイベント通知に関連付けて、端末２０１の番号とメディアサーバＭＳの番号を、サービス情報記憶部１５０に一時的に記憶しておく。
そして、サービスロジック部１４０は、このイベント通知に基づき、サービス情報記憶部１５０に記憶されている加入者データα（図６参照）を参照して、番号を変換するとともに、サービスパターンを決定する。
【００６６】
サービスロジック部１４０は、イベント通知に含まれるメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」に基づき、加入者データαを参照して、着端末側のメディアサーバ３００の番号を、論理番号「０１２０−ｅｅｅ−ｆｆｆ」と対応付けられている物理番号「０３−ｇｇｇｇ−ｈｈｈｈ」に変換する。また、サービスロジック部１４０は、この着端末側のメディアサーバ３００の論理番号「０１２０−ｅｅｅ−ｆｆｆ」と対応付けられているサービスパターン「ガイダンス接続」を、発信者Ａの端末装置２０１からの当該イベント通知に対応するサービスパターンと決定する。
【００６７】
次いで、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されているサービスパターン「ガイダンス接続」のプログラムを読み出し、実行する。
これにより、サービスロジック部１４０は、この「ガイダンス接続」のプログラムに従って、接続部品Ｐの部品生成と、ガイダンス再生部品Ｒの部品生成と、切断部品Ｑの部品生成とを行う。なお、この「ガイダンス接続」のプログラムには、接続部品Ｐの部品の生成および削除処理が終了した後、ガイダンス再生部品Ｒの部品生成および削除処理を終了し、その後、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。また、この「ガイダンス接続」のプログラムには、接続部品Ｐの属性情報として、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法（ ｅａｒｌｙ ）が、サービスロジック部１４０によって決められている。また、接続部品Ｐの制御復帰ポイントとしては「１８０メッセージ受信、２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」が、ガイダンス再生部品Ｒの制御復帰ポイントとしては「２００＿ＩＮＦＯメッセージ受信」が、切断部品Ｑの制御復帰ポイントとしては「２００＿ＢＹＥメッセージ受信」が、それぞれ、サービスロジック部１４０によって決められている。
なお、この接続部品Ｐは、属性情報を除いて、上述した接続部品Ｐと同様であるため、詳細な説明は省略する。
【００６８】
この「ガイダンス接続」のプログラムに従って、サービスロジック部１４０は、はじめに接続部品Ｐの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ２０２）。なお、ここで、ＡＰＩ呼出しにはガイダンス再生の音声ファイルとして「天気予報」を表わす情報が関連付けられている。
そして、部品管理制御部１３１によって接続部品Ｐが生成され、接続部品Ｐによって接続処理が実行されると、端末２０１とメディアサーバ３００とが接続中という状態になる。これにより、接続部品Ｐの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０３）。ここで、接続処理が終了する。
そして、サービスロジック部１４０は、部品管理制御部１３１に対して、接続部品Ｐの削除を表わすＡＰＩ呼出しを行うとともに、続けて、ガイダンス再生部品Ｒの部品生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ２０４）。これにより、端末２０１とメディアサーバ３００とが通話状態となり、メディアサーバ３００の音声ファイル「天気予報」の音声を再生することで、端末２０１に天気予報のガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０５）。
【００６９】
一方、例えば端末２０１によって通話中の状態が切断されると、端末２０１は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品機能部１３０を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ２０６）。このとき、通信を切断した端末２０１の番号が、イベント通知とともにサービスロジック部１４０に通知される。
【００７０】
そして、サービスロジック部１４０は、この「ガイダンス接続」のプログラムに従って、イベント通知に含まれる端末２０１の番号に基づき、サービス情報記憶部１５０を参照して、端末２０１と接続中の状態であるメディアサーバ３００に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ２０７）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０１とメディアサーバ３００とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ２０８）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ２０９）。これにより、端末２０１とメディアサーバ３００の通話に関する状態が全てなくなり、空き状態となる。
【００７１】
次に、図１０を用いて、サービスロジック部１４０が接続部品Ｐ（ｅａｒｌｙ）を生成する一例として、図９に示すステップＳＴ２０１〜２０４に相当するシーケンスについて、より詳細に説明する。なお、接続部品Ｐの「ｅａｒｌｙ」は、図７に示す「ｃｏｎｆｉｒｍｅｄ」のステップＳＴ１１０〜１３６まで同様の処理であるため、詳細な説明を省略する。ただし、図７に示すステップＳＴ１１３においては、属性情報として「ｃｏｎｆｉｒｍｅｄ」に代えて「ｅａｒｌｙ」とする点が異なる。
【００７２】
図１０に示す通り、接続部品Ｐが、ＡＣＫメッセージを着ＵＡ１２３に送信し、これによって、この着ＵＡ１２３から端末２０２にＡＣＫメッセージが送信されると、接続部品Ｐは、１８３メッセージをＵＡ機能部１２０に送信する（ステップＳＴ２１０）。このＵＡ機能部１２０は、発ＵＡ１２２を介して端末２０１に１８３（ＳＤＰ−Ｂ）メッセージを送信する（ステップＳＴ２１１）。そして、端末２０１は、ステップＳＴ２１１で受信した１８３メッセージに１００ｒｅｌオプションが付加されていた場合、ＰＲＡＣＫメッセージを発ＵＡ１２２に送信する（ステップＳＴ２１２）。
発ＵＡ１２２は、ＰＲＡＣＫメッセージをＵＡ管理制御部１２１を介して接続部品Ｐに送信する（ステップＳＴ２１３）。接続部品Ｐは、ＰＲＡＣＫメッセージが制御復帰ポイントではないため、ＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５にＰＲＡＣＫメッセージを送信する（ステップＳＴ２１４）。そして、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＰＲＡＣＫメッセージを送信する（ステップＳＴ２１５）。
【００７３】
これを受けて、メディアサーバ３００は、２００＿ＰＲＡＣＫメッセージを着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２１６）。そして、着用ＭＳ−ＵＡ１２５は、ＵＡ管理制御部１２１を介して、２００＿ＰＲＡＣＫメッセージを接続部品Ｐに送信する（ステップＳＴ２１７）。この接続部品Ｐは、２００＿ＰＲＡＣＫメッセージをＵＡ管理制御部１２１を介して発ＵＡ１２２に送信する（ステップＳＴ２１８）。これにより、発ＵＡ１２２は、２００＿ＰＲＡＣＫメッセージを端末２０１に送信する（ステップＳＴ２１９）。
これにより、接続部品Ｐが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ２２０）。そして、サービスロジック部１４０は、「ガイダンス接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ２２１）。これを受けて、部品管理制御部１３１は、接続部品Ｐを削除する。
以上によって、端末２０１とメディアサーバ３００の接続が完了し、通話中となる。
【００７４】
次に、図１１を用いて、サービスロジック部１４０がガイダンス再生部品Ｒを生成する一例として、図９に示すステップＳＴ２０４、２０５に相当するシーケンスについて、より詳細に説明する。
図１１に示す通り、サービスロジック部１４０は、「ガイダンス接続」のプログラムに従って、ガイダンス再生部品Ｒを生成する指示をＡＰＩ呼出しする（ステップＳＴ２５１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「ガイダンス再生部品Ｒ」、制御復帰ポイント「２００＿ＩＮＦＯメッセージ受信」、音声ファイル「天気予報」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、ガイダンス再生側のメディアサーバ３００の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００７５】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、ガイダンス再生部品Ｒを生成する。生成されたガイダンス再生部品Ｒは、メッセージテーブルデータを参照して、ＩＮＦＯメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５２）。
これにより、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＩＮＦＯ（発ガイダンス再生指示）メッセージを送信する（ステップＳＴ２５３）。そしてメディアサーバ３００は、２００＿ＩＮＦＯメッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ２５４）。
そして、ＵＡ管理制御部１２１は、２００＿ＩＮＦＯメッセージをガイダンス再生部品Ｒに送信すると（ステップＳＴ２５５）、メディアサーバ３００が音声ファイル「天気予報」を再生し、ガイダンスを端末２０１に流す。
【００７６】
音声ファイルの再生時間が終了すると、メディアサーバ３００は、ＩＮＦＯ（発ガイダンス完了通知）メッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ２５６）。このＵＡ管理制御部１２１は、ＩＮＦＯメッセージをガイダンス再生部品Ｒに送信する（ステップＳＴ２５７）。このガイダンス再生部品Ｒは、２００＿ＩＮＦＯメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５８）。この着用ＭＳ−ＵＡ１２５は、２００＿ＩＮＦＯメッセージをメディアサーバ３００に送信する（ステップＳＴ２５９）。
【００７７】
これにより、ガイダンス再生部品Ｒが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ２６０）。このサービスロジック部１４０は、「ガイダンス接続」のプログラムに従い、接続部品Ｐの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ２６１）。これを受けて、部品管理制御部１３１は、ガイダンス再生部品Ｒを削除する。
以上によって、端末２０１に対してメディアサーバ３００のガイダンス再生が終了する。
そして、この後、図８を用いて説明したように、切断部品Ｑを作成して削除する処理を行う。
【００７８】
［網内発呼サービス（モーニングコールサービス）の例］
次に、図１２〜１６を用いて、端末２０１に対してメディアサーバ３００に記憶されているモーニングコールの音声データを再生するため、端末２０１とメディアサーバ３００との２者間のセッションを確立するための網内発呼パターンについて説明する。
図１２は、この網内発呼パターンのメッセージ送受信を表わすイメージ図である。
【００７９】
この網内発呼パターンは、まず図１２に実線で示すようにして、サービスロジック部１４０が、発呼部品Ｓを用いて端末２０３およびメディアサーバ３００を呼び出して通話状態とした後に、メディアサーバ３００の音声ファイルをメディア変更部品Ｔを利用して再生する方法である。
【００８０】
ここでは、例えば発信者Ａによって、端末２０３を介して予めモーニングコールを毎日午前７時に、この端末２０３にかけてもらうサービスが設定されているとする。具体的に説明すると、発信者Ａによって、端末２０３を介して、モーニングコールの設定を受け付ける番号がダイヤルされると、端末２０３、通信サービス提供サーバ１００に対して、モーニングコールの設定を要求するメッセージに自身の電話番号を関連付けて送信する。すると、このメッセージは、サービスロジック部１４０に通知され、サービス情報記憶部１５０の加入者データβに記録される。
【００８１】
なお、この加入者データβについて、図１４を用いて説明すると、端末２０３の電話番号（すなわち、契約者番号「０８５２−ｉｉ−ｊｊｊｊ」）と、モーニングコールの設定日時（すなわち、発呼日時「毎日７：００」）と、提供される音声データを表す音声ファイル「モーニングコール」とが、対応付けられている。また、この加入者データβは、サービス情報記憶部１５０に記憶されている。
【００８２】
次に、図１３を参照して、この網内発呼パターンの状態遷移について説明する。図１３は、網内発呼パターンにおける状態遷移の一例を示す概略図である。
図１３に示す通り、サービスロジック部１４０は、加入者データβに基づき、発呼日時「毎日７：００」に到達したか否かを判断する。そして、発呼日時に到達した場合（ステップＳＴ３０１）、サービスロジック部１４０は、この発呼日時と対応付けられているサービスパターン「網内発呼（モーニングコール）」をサービスパターンとして決定する。
【００８３】
次いで、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されているサービスパターン「網内発呼（モーニングコール）」のプログラムを読み出し、実行する。
これにより、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、発呼部品Ｓの部品生成と、メディア変更部品Ｔの部品生成と、切断部品Ｑの部品生成を行う。
なお、この「網内発呼（モーニングコール）」のプログラムには、端末２０３を呼び出すための発呼部品Ｓの部品の生成および削除処理と、メディアサーバ３００を呼び出すための発呼部品Ｓの部品の生成および削除処理とが終了した後、メディア変更部品Ｔの部品の生成および削除処理と、ガイダンス再生部品Ｒの部品の生成および削除処理とを行い、最後に、切断部品Ｑの部品の生成および削除処理を実行することが予め決められている。
【００８４】
そして、この「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、はじめに端末２０３を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０２）。
そして、部品管理制御部１３１によって発呼部品Ｓが生成され、発呼部品Ｓによって呼び出し処理が実行されると、端末２０３が読み出され、端末２０３が発呼中となる。すなわち、端末２０３と通信サービス提供サーバ１００とが接続状態となる。
これにより、発呼部品Ｓの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ３０３）。ここで、呼び出し処理が終了する。
【００８５】
続けて、「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、メディアサーバ３００を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０４）。
そして、部品管理制御部１３１によって発呼部品Ｓが生成され、発呼部品Ｓによって呼び出し処理が実行されると、メディアサーバ３００が読み出され、メディアサーバ３００が発呼中となる。すなわち、メディアサーバ３００と通信サービス提供サーバ１００とが接続状態となる。
これにより、発呼部品Ｓの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了のイベント通知を行う（ステップＳＴ３０５）。ここで、呼び出し処理が終了する。
【００８６】
次いで、「網内発呼（モーニングコール）」のプログラムに従って、サービスロジック部１４０は、メディア変更部品Ｔの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３０６）。この部品管理制御部１３１によってメディア変更部品Ｔが生成され、メディア変更部品Ｔによってメディア変更処理が実行される（ステップＳＴ３０７）。結果、端末２０３とメディアサーバ３００とが通信サービス提供サーバ１００を介して接続状態となる。
これにより、メディア変更部品Ｔの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、メディア変更部品Ｔの削除を表わすＡＰＩ呼出しを行うとともに、続けて、ガイダンス再生部品Ｒの部品生成を表わすＡＰＩ呼出しを部品管理制御部１３１に対して行う（ステップＳＴ３０８）。これにより、端末２０３とメディアサーバ３００とが通話状態となり、メディアサーバ３００の音声ファイル「モーニングコール」の音声を再生することで、端末２０３にモーニングコールのガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ３０９）。
【００８７】
一方、例えば端末２０３によって通話中の状態が切断されると、端末２０３は、切断を通知するメッセージを通信サービス提供サーバ１００に送信する。このメッセージは、通信プロトコルスタック１１０によって変換されて、ＵＡ機能部１２０および部品機能部１３０を介して、サービスロジック部１４０に切断通知を表わすイベント通知がなされる（ステップＳＴ３１０）。このとき、通信を切断した端末２０３の番号が、イベント通知とともにサービスロジック部１４０に通知される。
あるいは、メディアサーバ３００による音声ファイル「モーニング」の音声データの再生時間が終了することによって、ガイダンス再生の終了を表すメッセージが、通信プロトコルスタック１１０、ＵＡ機能部１２０、および部品機能部１３０を介してサービスロジック部１４０に切断通知を表わすメッセージとしてイベント通知されるものであってもよい。
【００８８】
そして、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、イベント通知に含まれる端末２０３の番号に基づき、サービス情報記憶部１５０を参照して、端末２０３と接続中の状態であるメディアサーバ３００に対して切断処理を実行する切断部品Ｑの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３１１）。
この部品管理制御部１３１によって切断部品Ｑが生成され、切断部品Ｑによって切断処理が実行されると、端末２０３とメディアサーバ３００とが切断中の状態となる。これにより、切断部品Ｑの機能が達成されたため、部品管理制御部１３１は、サービスロジック部１４０に対して、部品終了を表わすイベント通知を行う（ステップＳＴ３１２）。ここで、切断処理が終了する。そして、サービスロジック部１４０は、部品管理制御部１３１に対して、切断部品Ｑの削除を表わすＡＰＩ呼出しを行う（ステップＳＴ３１３）。これにより、端末２０３とメディアサーバ３００の通話に関する状態が全てなくなり、空き状態となる。
【００８９】
次に、図１５を用いて、サービスロジック部１４０が発呼部品Ｓを生成する一例として、図１３に示すステップＳＴ３０１〜３０３に相当するシーケンスについて、より詳細に説明する。
図１５に示す通り、サービスロジック部１４０は、サービス情報記憶部１５０に記憶されている加入者データβを参照して、発呼日時に到達したか否かを判断し、発呼日時に到達した場合、サービスパターンとして、「網内発呼（モーニングコール）」を決定する。そして、サービスロジック部１４０は、この「網内発呼（モーニングコール）」のプログラムに従って、端末２０３を呼び出すための発呼部品Ｓの部品生成のＡＰＩ呼出しを、部品管理制御部１３１に対して行う（ステップＳＴ３２１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「発呼部品Ｓ」、制御復帰ポイント「２００＿ＩＮＶＩＴＥメッセージ受信、ＡＣＫメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、発信側の端末２０３の番号を発信側番号Ａとを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００９０】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、発呼部品Ｓを生成する。生成された発呼部品Ｓは、メッセージテーブルデータを参照して、ＩＮＶＩＴＥメッセージをＵＡ機能部１２０に送信する（ステップＳＴ３２２）。
これにより、ＵＡ機能部１２０は発ＵＡ１２２に対してＡＰＩ呼出しを行い、発ＵＡ１２２は、端末２０３に対してＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３２３）。そして、端末２０３は、発ＵＡ１２２に１００メッセージを送信し（ステップＳＴ３２４）、その後、１８０メッセージも送信する（ステップＳＴ３２５）。
【００９１】
端末２０３から１８０メッセージを受信すると、発ＵＡ１２２は、１８０メッセージを発呼部品Ｓに送信する（ステップＳＴ３２６）。
続けて、端末２０３は、発ＵＡ１２２に２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３２７）。この発ＵＡ１２２は、２００＿ＩＮＶＩＴＥ（ＳＤＰ−Ａ）メッセージを発呼部品Ｓに送信する（ステップＳＴ３２８）。
これにより、発呼部品Ｓは、部品管理制御部１３１を介してサービスロジック部１４０に呼確立通知（Ａ）を行い（ステップＳＴ３２９）、サービスロジック部１４０に制御を復帰させる。
【００９２】
サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、発呼部品Ｓの制御を継続させることを決定し、部品継続メッセージを発呼部品Ｓに送信する（ステップＳＴ３３０）。これを受けて、発呼部品Ｓは、ＡＣＫメッセージを着ＵＡ１２３に送信する（ステップＳＴ３３１）。この着ＵＡ１２３は、端末２０３にＡＣＫメッセージを送信する（ステップＳＴ３３２）。
これにより、発呼部品Ｓは、部品終了通知をサービスロジック部１４０に通知する（ステップＳＴ３３３）。そして、サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、発呼部品Ｓの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ３３４）。これを受けて、部品管理制御部１３１は、発呼部品Ｓを削除する。
以上によって、端末２０３の呼び出しが完了する。
なお、メディアサーバ３００を呼び出すための発呼部品Ｓの生成処理も同様であるため、詳細な説明は省略する。
【００９３】
次に、図１６を用いて、サービスロジック部１４０がメディア変更部品Ｔを生成する一例として、図１３に示すステップＳＴ３０６〜３０８に相当するシーケンスについて、より詳細に説明する。
図１６に示す通り、サービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従って、メディア変更部品Ｔを生成する指示をＡＰＩ呼出しする（ステップＳＴ３５１）。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「メディア変更部品Ｔ」、制御復帰ポイント「メディアサーバ３００からの２００＿ＵＰＤＡＴＥメッセージ受信」であるとする。そこで、サービスロジック部１４０は、この部品の種類と、制御復帰ポイントと、発呼部品Ｓによって呼び出されている端末２０３とメディアサーバ３００の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部１３１に対して、この部品生成に関する情報を付与したＡＰＩ呼出しをする。
【００９４】
そして、部品管理制御部１３１は、サービスロジック部１４０から受け取ったＡＰＩ呼出しに含まれる部品生成に関する情報に基づき、メディア変更部品Ｔを生成する。生成されたメディア変更部品Ｔは、メッセージテーブルデータを参照して、ＵＰＤＡＴＥメッセージをＵＡ管理制御部１２１を介して発ＵＡ１２２に送信する（ステップＳＴ３５２）。
これにより、発ＵＡ１２２は、端末２０３に対してＵＰＤＡＴＥ（ＳＤＰ−Ｂ）メッセージを送信する（ステップＳＴ３５３）。そして、端末２０３は、２００＿ＵＰＤＡＴＥ（ＳＤＰ−Ｂ）メッセージを発ＵＡ１２２を介してＵＡ管理制御部１２１に送信する（ステップＳＴ３５４）。
【００９５】
そして、ＵＡ管理制御部１２１は、２００＿ＵＰＤＡＴＥメッセージをメディア変更部品Ｔに送信する（ステップＳＴ３５５）。このメディア変更部品Ｔは、受信した２００＿ＵＰＤＡＴＥメッセージがメディアサーバ３００からでなく、端末２０３からであるため、サービスロジック部１４０に制御を復帰させず、ＵＰＤＡＴＥメッセージをＵＡ管理制御部１２１を介して着用ＭＳ−ＵＡ１２５に送信する（ステップＳＴ２５６）。
これにより、着用ＭＳ−ＵＡ１２５は、メディアサーバ３００に対してＵＰＤＡＴＥ（ＳＤＰ−Ａ）メッセージを送信する（ステップＳＴ３５７）。そして、メディアサーバ３００は、２００＿ＵＰＤＡＴＥ（ＳＤＰ−Ａ）メッセージを着用ＭＳ−ＵＡ１２５を介してＵＡ管理制御部１２１に送信する（ステップＳＴ３５８）。
【００９６】
そして、ＵＡ管理制御部１２１は、２００＿ＵＰＤＡＴＥメッセージをメディア変更部品Ｔに送信する（ステップＳＴ３５９）。このメディア変更部品Ｔは、受信した２００＿ＵＰＤＡＴＥメッセージがメディアサーバ３００から受信したメッセージであるため、サービスロジック部１４０に制御を復帰させる。つまり、メディア変更部品Ｔが自身の機能を達成したため、部品管理制御部１３１は、部品終了を表わす通知をサービスロジック部１４０に送信する（ステップＳＴ３６０）。このサービスロジック部１４０は、「網内発呼（モーニングコール）」のプログラムに従い、メディア変更部品Ｔの削除を決定し、部品削除メッセージを部品管理制御部１３１に送信する（ステップＳＴ３６１）。これを受けて、部品管理制御部１３１は、メディア変更部品Ｔを削除する。
【００９７】
このように、本実施形態に係る通信サービス提供サーバ１００は、図１７に示す通り、部品１３２とサービスロジック部１４０とが分離されており、部品１３２と複数のＵＡとが、両者のＳＩＰ信号レベルでのイベントのインタワークを行う。
また、部品１３２は、サービスロジック部１４０へのイベント通知（部品中断やサービスロジックへの制御復帰）および、サービスロジック部１４０からのＡＰＩ呼出し受信（部品継続（中断していた部品の再開））等を行う。
【００９８】
また、本実施形態に係る部品機能部１３０は、図１８に示す通り、空きの状態において、サービスロジック部１４０から部品生成のためのＡＰＩ呼出しを受けると、部品管理制御部１３１が、ＡＰＩ呼出しによる部品生成を実行し、部品を生成する。これにより生成された部品は、制御復帰ポイントに到達すると、部品における制御処理を中断して、サービスロジック部１４０にイベント通知をする。
サービスロジック部１４０は、このイベント通知を受けて、部品を継続するか、あるいは削除するかを判断する。このサービスロジック部１４０は、継続する場合、部品管理制御部１３１に部品継続を表わすＡＰＩ呼出しを行い、一方、部品を削除する場合、部品管理制御部１３１に部品削除を表わすＡＰＩ呼出しを行う。
また、部品１３２は、自身の機能を達成すると、部品終了を表わすイベント通知をサービスロジック部１４０に行うと、部品１３２による制御処理が終了中となる。これを受けたサービスロジック部１４０は、部品削除を表わすＡＰＩ呼出しを部品管理制御部１３１に行う。これにより、当該部品１３２は、部品管理制御部１３１によって削除される。
【００９９】
上述の通り、本実施形態に係る通信サービス提供サーバ１００は、サービスロジック部１４０と部品機能部１３０とにおける制御を分離して、サービスロジック部１４０が必要に応じてサービスパターンで予め決められている部品を呼び出して処理を実行させ、この部品の実行結果を受け取ることで、通信サービスに必要な全処理を行うようにした。
言い換えると、サービスロジック部１４０によってサービスパターンが決定されると、決定されたサービスパターンのプログラムが実行され、プログラムに従って少なくとも１つの部品が生成され、部品による処理が終了したら、当該部品を削除するようにした。
これにより、サービスロジック部１４０は、サービスパターンのプログラムを実行することによって、サービスに依存せず、他のサービスとも共通して利用することができる独立のモジュールである部品を実行させることができる。よって、通信サービスの違いに関わらず、共通して利用することができるため、異なる通信サービスにおいて共通する処理は、同じ種類の部品を利用することによって実現することができる。従って、部品に対応する処理をサービスロジック部１４０を制御するプログラムに全て記載する必要がなく、通信サービスを実行するためのサービスロジックの記載量を低減することができる。
【０１００】
また、上述の通り、サービスロジック部１４０と部品機能部１３０との機能を切り離して、部品機能部１３０が、通信プロトコルスタック１１０およびＵＡ機能部１２０を介して端末２００とメッセージの送受信を行うようにした。これにより、サービスロジック部１４０は、通信プロトコルの処理を実行する必要がなくその制御を単純化することができ、通信プロトコル仕様の変更による影響を受けることなく、部品１３２を制御することができる。よって、通信プロトコル仕様の変更による影響が部品１３２に局所化され、通信プロトコル仕様の変更に伴いサービスロジック部１４０を修正する必要がなくなった。
なお、実施形態によらず、サービスロジック部１４０と部品機能部１３０とが切り離されていない場合、通信サービスに応じたサービスロジックを、通信サービス毎に作成しなければならない。よって、このサービスロジックには、サービスロジック部１４０と部品機能部１３０間で生じるイベント通知とＡＰＩ呼出しとを記述し、さらに、部品機能部１３０とＵＡ管理制御部１２１との間に生じるイベント通知とＡＰＩ呼出しとを記述しなければならなかった。しかし、本実施形態では、サービスロジックには、前者のみを記述すればよく、後者は、部品１３２ごとのメッセージテーブルデータを用意すればよい。よって、サービス毎に作成されるサービスロジックにおいて、部品１３２ごとのメッセージテーブルデータに対応する制御の記述が不要となる。
【０１０１】
さらに、上述の通り、サービスロジック部１４０は、予め決められている制御復帰ポイントを関連付けた部品生成に関する情報を部品管理制御部１３１に送信する。そして、この部品生成に関する情報に基づき部品管理制御部１３１によって生成された部品１３２は、制御復帰ポイントにおいて、サービスロジック部１４０に制御を復帰させるようにした。これにより、部品１３２の制御の途中において、サービスロジック部１４０が当該部品１３２の制御を継続するか否か、あるいは終了するか否かを判断することができる。よって、サービスパターンのプログラムにおいて、通信サービス提供サーバ１００の部品１３２として予め決められている制御処理の一部分のみを利用するサービスロジックを作成することが可能となる。
例えば、部品１３２−１の復帰ポイントでその部品１３２−１を削除し、削除した後に他の部品１３２−２の制御処理を起動するようにサービスロジックを作成することによって、既存の部品１３２の制御処理を変更せずに、部品１３２の制御処理を部分的に利用することができる。
【０１０２】
また、上述の構成により、異なる通信サービスにおいて共通する処理内容の重複記載や重複開発を防止することができ、サービスロジックの作成時間や労力、経費等を削減することができる。さらに、部品に対応する処理の内容が単純化され、新規の通信サービスを追加する際に、部品に対応する処理の開発や記述が不要となり、サービスロジックの追記のみで実現することができる。このため、新規な通信サービスの追加時の時間や労力、経費等を削減することができる。
【０１０３】
従って、本実施形態によらない場合、例えば、サービスを提供するための処理をサービス毎に１つのソフトウェアのブロックを実装しない場合、（１）サービスが異なっても共通する処理（例えば、端末間のセッション制御などのためのメッセージ送受信の処理等）が重複する、（２）サービスの状態の管理とセッション制御の状態の管理が処理ブロック内に混在して制御が複雑になる、（３）新規サービスの追加時に開発量が増えるなどの問題があった。本実施形態に係る通信サービス提供サーバ１００は、このような問題を解決することができる。
また、本実施形態によらない場合、ＳＩＰサーブレットコンテナ、ＨＴＴＰサーブレットコンテナ等の従来のアプリケーションサーバ（ＡＳ）のソフトウェア構造は、サービス固有の処理（サービスロジック）を記述する部分に信号プロトコルの処理が混在していたため、サービスロジックの状態数が多く、構造の複雑化を招いていた。その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
また、Ｗｅｂ Ｓｅｒｖｉｃｅｓから呼制御を行うためのＡＰＩとしてＰａｒｌａｙ−Ｘが標準化されている。Ｐａｒｌａｙ−Ｘと通信プロトコルのゲートウェイも従来のＡＳと同様に、その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
【０１０４】
なお、部品１３２は、上述の機能を有する構成に限られず、通信サービスを構成する制御であればよい。また、部品１３２としては、他の通信サービスと共通して利用することができる制御であることが好ましく、例えば、２対地間の安定状態から次の安定状態への遷移毎に分割される単位での制御であることが好ましい。ここで、安全状態とは、空き、呼出中、通話中など、一定期間継続可能な状態を指し、２対地間の安定状態から次の安定状態への遷移とは、例えば、端末２０１から端末２０２への発呼（空き）〜端末２０１・２０２間の通話（通話中）、端末２０１・２０２間の通話（通話中）〜切断（空き）などの状態遷移をいう。
【０１０５】
なお、通信サービス提供サーバ１００等の動作の過程は、コンピュータに実行させるためのプログラムや、このプログラムとしてコンピュータ読み取り可能な記録媒体として利用可能であり、コンピュータシステムが読み出して実行することによって、上記処理が行われる。なお、ここでいう「コンピュータシステム」とは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０１０６】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に記憶したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【０１０７】
１００ 通信サービス提供サーバ
１１０ 通信プロトコルスタック
１２０ ＵＡ機能部
１２１ ＵＡ管理制御部
１２２ 発ＵＡ
１２３ 着ＵＡ
１２４ 発用ＭＳ ＵＡ
１２５ 着用ＭＳ ＵＡ
１３０ 部品機能部
１３１ 部品管理制御部
１３２ 部品（サービス非依存機能部）
１４０ 通信サービス提供サーバ
１５０ サービス情報記憶部
【特許請求の範囲】
【請求項１】
少なくとも１つの端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバにおける通信サービス提供方法であって、
前記通信サービス提供サーバのサービスロジック部が、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するステップと、
前記通信サービス提供サーバの部品管理制御部が、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成させるステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うステップと、
を備えることを特徴とする通信サービス提供方法。
【請求項２】
前記通信サービス提供サーバのサービスロジック部が、
前記部品生成に関する情報を送信するステップにおいて、前記サービスロジックで前記サービス非依存機能部から通知を受け取るタイミングを表わす制御復帰ポイント情報が予め決められている場合、当該制御復帰ポイント情報を前記部品生成に関する情報に含めて前記部品管理制御部に送信するステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品制御情報に従ってメッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わすポイントに到達した場合、前記サービスロジック部に対してメッセージを送信するとともに、前記端末とのメッセージの送受信を中断するステップと、
を備えることを特徴とする請求項１に記載の通信サービス提供方法。
【請求項３】
前記通信サービス提供サーバのサービスロジック部が、
前記部品生成に関する情報を送信した後、前記サービス非依存機能部からメッセージを受信した場合、前記サービス非依存機能部による制御を継続するか否か、あるいは終了するか否かの少なくとも一方を判断するステップと、
前記サービス非依存機能部による制御を継続すると判断した場合、前記サービス非依存機能部に対して、継続を表わすメッセージを送信するステップと、
前記サービス非依存機能部による制御を終了すると判断した場合、前記サービス非依存機能部に対して、前記サービス非依存機能部の削除を表わすメッセージを送信するステップと、
を備えることを特徴とする請求項１あるいは２に記載の通信サービス提供方法。
【請求項４】
前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から自端末を識別するための第１の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第１の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第１の端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項１から３のいずれか一項に記載の通信サービス提供方法。
【請求項５】
前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から、着信側の端末を識別するための第２の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第２の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第２端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項１から４のいずれか一項に記載の通信サービス提供方法。
【請求項６】
前記通信サービス提供サーバのサービスロジック部が、
前記サービスロジックで複数の前記サービス非依存機能部による制御処理の実行が予め決められている場合、前記サービスロジックに従って、複数の前記サービス依存機能部を生成することを特徴とする請求項１から５のいずれか一項に記載の通信サービス提供方法。
【請求項７】
少なくとも１つの端末と、この端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバとを含む通信サービス提供システムであって、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するサービスロジック部と、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成する部品管理制御部と、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うサービス非依存機能部と
を備えることを特徴とする通信サービス提供システム。
【請求項１】
少なくとも１つの端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバにおける通信サービス提供方法であって、
前記通信サービス提供サーバのサービスロジック部が、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するステップと、
前記通信サービス提供サーバの部品管理制御部が、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成させるステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うステップと、
を備えることを特徴とする通信サービス提供方法。
【請求項２】
前記通信サービス提供サーバのサービスロジック部が、
前記部品生成に関する情報を送信するステップにおいて、前記サービスロジックで前記サービス非依存機能部から通知を受け取るタイミングを表わす制御復帰ポイント情報が予め決められている場合、当該制御復帰ポイント情報を前記部品生成に関する情報に含めて前記部品管理制御部に送信するステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品制御情報に従ってメッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わすポイントに到達した場合、前記サービスロジック部に対してメッセージを送信するとともに、前記端末とのメッセージの送受信を中断するステップと、
を備えることを特徴とする請求項１に記載の通信サービス提供方法。
【請求項３】
前記通信サービス提供サーバのサービスロジック部が、
前記部品生成に関する情報を送信した後、前記サービス非依存機能部からメッセージを受信した場合、前記サービス非依存機能部による制御を継続するか否か、あるいは終了するか否かの少なくとも一方を判断するステップと、
前記サービス非依存機能部による制御を継続すると判断した場合、前記サービス非依存機能部に対して、継続を表わすメッセージを送信するステップと、
前記サービス非依存機能部による制御を終了すると判断した場合、前記サービス非依存機能部に対して、前記サービス非依存機能部の削除を表わすメッセージを送信するステップと、
を備えることを特徴とする請求項１あるいは２に記載の通信サービス提供方法。
【請求項４】
前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から自端末を識別するための第１の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第１の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第１の端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項１から３のいずれか一項に記載の通信サービス提供方法。
【請求項５】
前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から、着信側の端末を識別するための第２の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第２の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第２端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項１から４のいずれか一項に記載の通信サービス提供方法。
【請求項６】
前記通信サービス提供サーバのサービスロジック部が、
前記サービスロジックで複数の前記サービス非依存機能部による制御処理の実行が予め決められている場合、前記サービスロジックに従って、複数の前記サービス依存機能部を生成することを特徴とする請求項１から５のいずれか一項に記載の通信サービス提供方法。
【請求項７】
少なくとも１つの端末と、この端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバとを含む通信サービス提供システムであって、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報を送信するサービスロジック部と、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成する部品管理制御部と、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うサービス非依存機能部と
を備えることを特徴とする通信サービス提供システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１１−４００００（Ｐ２０１１−４００００Ａ）
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２００９−１８９４６５（Ｐ２００９−１８９４６５）
【出願日】平成２１年８月１８日（２００９．８．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２１年８月１８日（２００９．８．１８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]