JP2005301468A - サービス提供システムおよびその提供方法 - Google Patents

Abstract

【課題】複数のコミュニケーションを行う観点に基づく一元的な状況管理を実現することができるサービス提供システムおよびその提供方法を提供。
【解決手段】コミュニケーションシステム10は、Webブラウザからの要求をコールアテンプトとして実行し、HTTPプロトコルでこの要求に対するコールアテンプト管理部100を起動させ、連携管理部96および58を介してSIPプロトコルの要求にし、コールアテンプト管理部56で要求に対して処理し、この処理結果の応答を逆の通信経路を辿ってWebブラウザ50に送って、表示させ、サービス代理UA管理部98、連携管理部96および58ならびにサービス代理UA管理部54を順に動作させて、サービス代理UAにより登録し、この手順の逆順序で登録結果をWebシステムに返し、この後、Webシステムから用件を実行して、コールを確立する。
【選択図】図１

Description

本発明は、サービス提供システムおよびその提供方法に関するものであり、本発明のサービス提供システムは、とくに、セッション開始プロトコル（SIP: Session Initiation Protocol）に基づき動作するSIP環境とWeb（World Wide Web）環境のような異なる環境の融合を図ってアプリケーションを相互に連携させて、接続しているクライアントにサービスを提供するシステムに関するものである。また、本発明のサービス提供方法は、たとえば異なる環境で動作するアプリケーションを相互に連携させて、サービスを提供する方法に関し、たとえば、Webブラウザ上から起動したVoIPコミュニケーションの記録をコミュニケーションの目的の達成状況と対応させて管理し、システムがコミュニケーションの実行と目的の達成をサボートするようなコミュニケーションプロセスマネジメント型APの実現に関するものである。

従来、SIPベースのAP（APplication）環境とWebベースのAP環境は融合が図られず、別々のAP環境として実現されてきている。これは、従来のWeb-AP環境が企業の情報システムやISP（Internet Service Provider）が提供する情報提供型のAPサービスの構築に用いられ、一方のSIP-AP環境は電話系サービスの構築に用いられてきたことに依存している。すなわち、それぞれの環境が異なる用途に利用されていたためである。

また、このような異なる通信プロトコルにより実現されるサーバ環境を連携・接続する場合には、プロトコル変換用ゲートウェイを仲介させる方式が一般的に採用されている。プロトコル変換用ゲートウェイには、Web環境のプロトコルであるHTTP（Hyper Text Transfer Protocol）とSIP環境のプロトコルであるSIPの相互接続変換機能を実現するHTTP-SIP変換ゲートウェイが利用されることになる。

RFC3261、インターネット＜URL：http://www.ietf.org/rfc/rfc3261.txt＞ JSR116、インターネット＜URL：http://jcp.org/aboutJava/communityprocess/final/jsr116/index.html＞

ところで、HTTP-SIP変換ゲートウェイは、あらかじめHTTP-SIP変換ゲートウェイ機構に組み込まれる、プロトコル変換規則に従って動作する簡単な機能だけを実現可能にする。しかしながら、たとえば、複数の人が複数のコミュニケーションを一つの目的の下で状況管理する場合、HTTP-SIP変換ゲートウェイを用いた単独のコミュニケーションシステムや変換ゲートウェイで柔軟に実施できないことが知られている。

この実施の困難な例としては、比較的大規模なシステム提案等の案件がこれに対応している。より具体的に説明すると、通常、複数の営業マンやSE（Sales Engineer）が顧客の複数の窓口や担当者とコミュニケーションを行いながら、業務を進展させる場合のシステム提案を考える。この提案の中で、案件成約・システム構築等の目的達成において複数の人間が、営業交渉や技術提案等の複数のコミュニケーションを実施する。この実施には、目的毎にコミュニケーションシステムを構築するとよいことが知られている。

また、目的の達成状況をSIP環境内のデータベース上でプレゼンスに対応させて、実施による状況の変化・変化した状況を通知することが好ましい。しかしながら、このようにシステムを構築すると、システムは長時間HTTPのトランザクションを保留することになる。したがって、例示したシステムは、リソースの有効利用や実際的なアプリケーションとしてのユーザインタフェース実現の観点から適切な実現方法とはなっていないことがわかる。

本発明はこのような従来技術の欠点を解消し、複数のコミュニケーションを行う観点に基づく一元的な状況管理を実現することができるサービス提供システムおよびその提供方法を提供することを目的とする。

本発明は上述の課題を解決するために、異なる通信プロトコルの環境により構築されたシステムに接続するクライアントのそれぞれと情報を通信して、この情報をサービスとして提供するサービス提供システムにおいて、このサービス提供システムは、第１の通信プロトコルに基づいて動作する第１のシステムと、第２の通信プロトコルに基づいて動作する第２のシステムとを備え、第１のシステムは、第２のシステムに送出する情報を第１の通信プロトコルと第２の通信プロトコルにおいて共通に連携させる情報として扱う第３の通信プロトコルに処理し、第２のシステムから供給される第３の通信プロトコルによる情報を第１の通信プロトコルの情報にする第１の連携管理手段と、要求されたサービスインスタンスを第１のシステムのクライアントに見立てて、仮想的にユーザエージェントとして管理し、この管理する情報を操作する第１の代理管理手段と、第１のシステムに接続するクライアントの一つによる発呼から通話目的を達成するまでのオブジェクトのインスタンスをコールアテンプトとし、このコールアテンプトにおける情報を操作管理する第１のコールアテンプト管理手段とを含み、第２のシステムは、第１のシステムに送出する情報を第３の通信プロトコルに処理し、第１のシステムから供給される第３の通信プロトコルによる情報を第２の通信プロトコルの情報にする第２の連携管理手段と、要求されたサービスインスタンスに対して第２のシステムから第１の代理管理手段の対応した機能に仮想的なユーザエージェントによりアクセスし、サービスインスタンスの実行結果を取得する第２の代理管理手段と、第２のシステムから第１のコールアテンプト管理手段の対応した機能にアクセスする第２のコールアテンプト管理手段とを含むことを特徴とする。

本発明のサービス提供システムは、第２のシステムに接続するクライアントからの要求をコールアテンプトとして実行する場合、第２の通信プロトコルでこの要求に対する第２のコールアテンプト管理手段を起動させ、第２の連携管理手段でこの要求を第３の通信プロトコルの要求にして、第１の連携管理手段に送り、第１の連携管理手段で第１の通信プロトコルの要求にし、第１のコールアテンプト管理手段で要求に対する処理を行い、この処理結果の応答を第１のコールアテンプト管理手段、第１の連携管理手段、第２の連携管理手段、第２のコールアテント管理手段を経て要求したクライアントに送って、表示させ、第２の代理管理手段、第２の連携管理手段、第１の連携管理手段および第２の代理管理手段を順に動作させて、登録し、逆の順序で登録結果を第２のシステムに返し、第２のシステムから用件を実行することにより、異種の通信プロトコル間での発呼インスタンスに対応したコールを確立させ、一元的な状況管理を実現させることができる。

また、本発明は上述の課題を解決するために、異なる通信プロトコルの環境により構築されたシステムに接続するクライアントのそれぞれと情報を通信して、この情報をサービスとして提供するサービス提供方法において、この方法は、第１の通信プロトコルに応じて動作する第１のシステムと第２の通信プロトコルに応じて動作する第２のシステムとの間の通信のうち、第１のシステムから送出する情報を第１の通信プロトコルと第２の通信プロトコルにおいて共通に連携させる情報として扱う第３の通信プロトコルに処理して、送出する第１の工程と、第２のシステムに供給される第３の通信プロトコルの情報を第２の通信プロトコルの情報に処理して、送出する第２の工程と、第２のシステムから送出する第２の通信プロトコルの情報を第３の通信プロトコルの情報に処理して、送出する第３の工程と、第１のシステムに供給される第３の通信プロトコルの情報を第１の通信プロトコルの情報に処理して、送出する第４の工程とを含み、第１のシステムに接続するクライアントの一つによる発呼から通話目的を達成するまでのオブジェクトのインスタンスをコールアテンプトとし、第２のシステムのクライアントから通信候補を用件とするコンタクトリストから選択し、この選択した用件に応じたコールアテンプトおよび目的の達成状況を表すステータスに応じてこのステータスを含む第２のシステムから第１のシステムの対応する機能へのアクセスを起動する第１の起動信号を生成する第５の工程と、第１の起動信号にともない第３の工程を起動する第２の起動信号を生成する第６の工程と、第３および第４の工程を順に実行する第７の工程と、第１のシステムにおける対応した機能を起動する第３の起動信号を生成する第８の工程と、第３の起動信号により起動した機能に対応した情報処理を行う第９の工程と、この情報処理に対する応答情報を受けて、この応答情報を含む第１の工程を起動する第４の起動信号を生成する第10の工程と、第１よび第２の工程を順に実行する第11の工程と、第２の起動信号を生成した生成先に応答情報を返す第12の工程と、第１の起動信号を生成した生成先に応答情報を返す第13の工程と、応答信号を加工して、第２のシステムのクライアントに供給し、選択した用件に対して仮想的にユーザエージェントとして代理する代理ユーザエージェントに第３および第４の工程を経てアクセスして、用件に関する情報を登録し、この登録に対する応答を第１および第２の工程により受ける第14の工程と、この登録に対する応答に応じて第２のシステムから第３および第４の工程を経て第１のシステムを起動させて、第１のシステムにおけるクライアント同士の通信を確立する第15の工程とを含むことを特徴とする。

本発明のサービス提供方法は、第２のシステムにてコンタクトリストから選択した用件に応じたコールアテンプトおよびステータスに応じてこのステータスを含む第１および第２の起動信号を生成し、第３および第４の工程を順に実行し、第１のシステムにて第３の起動信号を生成し、第３の起動信号により起動した機能に対応して情報処理し、この情報処理に対する応答情報を含む第４の起動信号を生成し、第１および第２の工程を経て第２のシステムにおけるクライアントに応答情報を返すとともに、第２のシステムから第１のシステムにおける代理ユーザエージェントにアクセスして、用件に関する情報を登録し、登録の完了を第２のシステムに通知した後、第２のシステムから第１のシステムを起動させて、第１のシステムにおけるクライアント同士の通信を確立することにより、Web上から用件を実行して、コミュニケーションプロセスマネジメント型APを実現することができる。

次に添付図面を参照して本発明によるサービス提供システムの実施例を詳細に説明する。

本実施例は、本発明のサービス提供システムをコミュニケーションシステム10に適用した場合である。本発明と直接関係のない部分について図示および説明を省略する。以下の説明で、信号はその現れる接続線の参照番号で指示する。

本実施例のコミュニケーションシステム10は、図２に示すように、SIPシステム12、Webシステム14、SOAP/CORBAネットワーク16、SIPクライアント18およびWebクライアント20を含む。コミュニケーションシステム10は、SIPシステム12およびWebシステム14がSOAP/CORBAネットワーク16により接続されている。SIPシステム12およびWebシステム14は、異なるネットワークドメインに属するネットワーク環境上に配置するとともに、後述するようにSIPシステム12およびWebシステム14のそれぞれが本来有していないWeb環境とSIP環境を補完する機能ブロックを持たせている。これにより、コミュニケーションシステム10は、SIPシステム12、Webシステム14をそれぞれ、１つのサーバ計算機内または同じドメイン内のLAN環境に配置するシステムに対応して一つの環境をそれぞれ、備えている。

SOAP/CORBAネットワーク16は、それぞれ、SIPシステム12とWebシステム14との情報を仲介する役割を担う通信プロトコルを機能させてシステム間をつないでいる。上述した通信プロトコルのうち、SOAP（Simple Object Access Protocol）は、Webサービス間で交換されるメッセージのデータフォーマットやメッセージの処理ルールを規定した通信プロトコルである。SOAP/CORBAネットワーク16は、SOAPを用いた場合、この規定に従ったSOAPメッセージをサービス要求者、サービス提供者およびサービス仲介者が相互にやりとりする。CORBAは、OMG（Object Management Group）が策定した分散オブジェクト技術である。

SIPクライアント18は、SIPサーバ22と接続し、SIP-AP 26が提供する機能を利用するクライアント環境を有している。代表的には、SIPソフトフォン等がある。本実施例では、SIPクライアント端末46および48を用いている。

また、Webクライアント20は、Webサーバ34と接続し、Web-AP 42が提供する機能を利用するようにクライアント環境が完備されている。代表的なWebクライアントには、Webブラウザがある。本実施例では、Webブラウザ50および52を用いている。ここで、Webブラウザ52は保守用である。

さらに、上述したSIPシステム12およびWebシステム14の構成要素それぞれについて簡単に説明する。SIPサーバ22は、エンド・ツー・エンドでやりとりするクライアント-サーバモデルのプロトコルであるSIPに基づいてクライアントの要求に応じて応答するサーバであり、とくに、IETF（International Engineering Task Force）で規定される、たとえばRFC（Request For Comments）3261に準拠したSIPをハンドリング・管理する機能を有している。この管理機能のうち、SIPサーバ22には、一般的に３つのサーバ機能、すなわちSIPプロキシサーバ機能、SIPレジストラサーバ機能およびSIPロケーションサーバ機能が含まれている。第１に、SIPプロキシサーバ機能はクライアントの代理として、SIPメッセージの中継を行う機能である。第２に、SIPレジストラサーバ機能はクライアントの登録を管理する機能である。第３に、SIPロケーションサーバ機能は登録されたクライアントのアドレス情報等を管理する機能を有している。SIPサーバ22は、たとえばSIPクライアント18の構成要素であるSIPクライアント端末46および48に接続され、SIP-APサーバ26から提供される情報、SIPメッセージによりやりとりしている。

SIP-DB 24は、SIPサーバ22が管理する、たとえばユーザ情報およびプレゼンス情報等を相互に関連付けて格納するストレージで、SIPサーバ22に接続され、SIPサーバ22の検索要求に応じて情報を提供する機能を有するものもある。SIP-DB 24においてユーザ情報は、クライアントのアドレス情報や認証に用いる情報である。プレゼンス情報は、クライアントがSIPシステム12に接続されているか否か、クライアントが起動・利用されているか否か、さらに別のクライアントと接続中であるか否か等の情報である。

SIP-APサーバ26は、SIPプロトコルに基づいてSIPサーバ22により管理されるアプリケーションを操作に応じて稼動するサーバである。SIP-APサーバ26は、SIPサーバ22およびSIP-API 28にそれぞれ、接続されている。SIP-API 28は、SIPサーバ22で受信するSIPリクエストをアプリケーションに伝達する機能およびSIPサーバ22ヘのリクエストを発行する機能を有する。SIPリクエストには、セッション確立、確認応答、通話終了およびプレゼンス変更等がある。

SIP-API 28は、SIP-APサーバ26が提供するアプリケーションインタフェースである。SIP-APサーバ26は、SIP-API 28を介してSIP-AP 30に接続されている。SIP-API 28には、代表的なものとして、JCP（Java（商標） Community Process）において標準化作業が進められているSIP Servlet アプリケーションインタフェースがある。

SIP-AP 30は、接続するSIP-API 28により構築され、SIP-APサーバ26上で稼動するアプリケーションである。SIP-AP 30には、たとえばIP電話、インスタントメッセージ、TV（TeleVison）電話、プレゼンスコミュニケーション等がある。

Webアクセッサコンポーネント32は、SIP-AP 30がWebシステム14と連携するコンポーネント群の総称であり、コンポーネントのそれぞれはライブラリソフトウェア部品を表している。したがって、Webアクセッサコンポーネント32は、SIP-AP 30が動作する際に呼び出され、Webシステム14の後述するSIPアクセッサコンポーネント44と交信する際に利用される。Webアクセッサコンポーネント32には、たとえば、図３に示すように、サービス代理UA（User Agent）管理部54、コールアテンプト（Call Attempt: CA）管理部56、連携管理部58およびコンポーネントアプリケーションインタフェース（コンポーネントAPI）60を含む。

さらにWebアクセッサコンポーネント32について図１を参照しながら、説明する。サービス代理UA管理部54は、SIP環境のSIPシステム12内で管理するサービス代理UA情報を操作管理する機能を有している。サービス代理UAは、サービスインスタンスをSIPクライアントに見立てて、見立てたSIPクライアント間で要求と応答を仮想的にやりとりするUAとしてサービスを実現させている。

サービス代理UA管理部54は、以下のような代表的な機能モジュールとして、代理UA生成機能部62、代理UA登録機能部64、代理UA削除機能部66、プレゼンス設定機能部68、メッセージ送信機能部70、代理UA情報編集機能部72および代理UA情報検索機能部74を有する。代理UA生成機能部62、代理UA登録機能部64および代理UA削除機能部66は、それぞれ、サービスインスタンスに対応するUAの生成機能、登録機能および削除機能を有する。プレゼンス設定機能部68はサービスインスタンスに対応するUAのプレゼンス情報を変更する機能を有する。メッセージ送信機能部70はサービスインスタンスに対応するUAから指定のUAにメッセージを送信する機能を持つ。メッセージにはたとえば、テキストストリング等がある。

代理UA情報編集機能部72はサービスインスタンスに対応するUAのユーザ情報を編集する機能を有する。最後に、代理UA情報検索機能部74はサービスインスタンスに対応するUAのユーザ情報を検索する機能を有している。

コールアテンプト管理部56は、SIP環境のSIPシステム12内で管理するコールアテンプト情報を操作管理する機能を有している。目的の達成には、複数のコミュニケーションが繰り返し実行されることになるので、コールアテンプト管理部56では、コミュニケーションの進捗に従って目的達成に向けて状況が変化し、この変化にともない目的達成に向けて状況が進行していく。

具体的に機能を説明する。コールアテンプト管理部56は、発信者がはじめにコンタクトしようと試みた発呼から通話目的の達成までをライフタイムとするオブジェクトのインスタンスをコールアテンプトと呼び、このライフタイムにおけるステータスを管理し、発信者情報、着信者情報およびコールアテンプト履歴情報等の情報と合わせて操作を管理している。ここで、ステータスとは、目的の達成状況に相当する情報を値で表している。ステータスには、たとえば完了、回答待ち、伝言待ちおよび再依頼予定がある。また、コールアテンプト情報とは、CAの発信者情報、着信者情報およびコールアテンプト履歴情報を総称している。

コールアテンプト管理部56は、生成機能部76、削除機能部78、ステータス検索機能部80、ステータス設定機能部82、ステータス変更通知機能部84、ステータス滞留通知機能部86、情報編集機能部88および情報検索機能部90を含む。生成機能部76および削除機能部78は、それぞれ、発信者の発呼インスタンスに対応するCAの生成機能および削除機能を有する。ステータス検索機能部80およびステータス設定機能部82は、それぞれ、発呼インスタンスに対応するCAの通信ステータス情報の検案機能および設定機能を持っている。

ステータス変更通知機能部84は、発信者または着信者の操作によるステータスの変更に応じてたとえば、通話や確認等のステータスの進行に変更を通知する機能を有する。また、ステータス滞留通知機能部86は、たとえば変更に対応するように通知しても、一定時間にステータスの変更がない場合に対応していない旨を通知する機能を有し、この通知により発信者または着信者に対してステータスの変更を喚起して、促進させている。情報編集機能部88および情報検索機能部90は、それぞれ、発呼インスタンスに対応するCAの発信者情報、着信者情報およびコールアテンプト履歴情報の編集機能および検索機能を有する。

コンポーネントAPI 92および94は、図３のコンポーネントAPI 60に含まれ、サービス代理UA管理部54およびコールアテンプト管理部56をSIP-AP 30が利用するためのインタフェースである。

なお、Webアクセッサコンポーネント32は、具体的なSIP-AP 30としてどのような機能を実現するかにより、SIP-AP 30側から組み合せて利用できるものであり、上述したコンポーネント以外にも、用途に応じて随時拡張することが可能である。このコンポーネントの追加・拡張により、Webシステム14との連携のバリエーションも追加・拡張されることになる。

連携管理部58は、Webシステム14内の対応する連携管理部96と連携し、サービス代理UA管理部54やコールアテンプト管理部56に対するWebシステム14側からのアクセスまたはWebシステム14側へのアクセスを行う通信環境を管理する機能を有している。連携管理環境には、たとえば、SOAPやCORBAのプロトコルに対応する環境設定等がある。連携管理部58には、情報を共通の通信プロトコルに変換する機能およびSIPプロトコルに変換する機能がある。

図４に戻って、Webシステム14について説明する。Webサーバ34は、HTTPプロトコルを基にハンドリング・管理するサーバである。Webサーバ34は、Webクライアント20の構成要素であるWebブラウザ50および52に接続されている。また、Webサーバ34は、Web-DB 36およびWeb-APサーバ38と接続してこれらを管理している。

Web-DB 36は、Webサーバ34が管理する情報を格納するストレージであり、Webサーバ34の検索要求に応じて情報を提供する機能を有するものもある。管理する情報には、クライアントの課金情報および利用ログ等がある。

Web-APサーバ38は、常時起動状態にあって、WebプロトコルであるHTTPプロトコルに基づいてWebサーバ34により管理されるアプリケーションを操作に応じて稼動するサーバである。Web-APサーバ38には、たとえば、オープンソースのTOMCAT、BEAシステム社のWebLogic（商標）等が挙げられる。Web-APサーバ38は、Web-API 40を介してWeb-AP 42に接続されている。Web-APサーバ38は、Web-DB 36の情報を基にアプリケーションを動作させてもよい。

Web-API 40は、Web-APサーバ38が提供するアプリケーションインタフェースである。Web-API 40は、代表的なAPIとして、J2EE（Java2 Enterprise Edition）環境で規定されているHTTP Servlet APIやEJB（Enterprise Java（商標） Beans）等がある。Web-API 40は、Web-APサーバ38とWeb-AP 42との情報のやりとりを可能にしている。

Web-AP 42は、接続するWeb-API 40により構築され、Web-APサーバ38上で稼動するWebアプリケーションであり、SIPアクセッサコンポーネント44にも接続されている。Web-AP 42は、たとえば、インターネットショッビングモール、企業ポータルおよびコンテンツ配信等のAPを有している。

SIPアクセッサコンポーネント44は、Web-AP 42がSIPシステム12と連携するコンポーネント群の総称であり、Web-AP 42が動作する際に呼び出されるライブラリソフトウェアである。SIPアクセッサコンポーネント44は、Web-AP 42がSIPシステム12上のWebアクセッサコンポーネント32と交信する際に利用される。この場合も、Webアクセッサコンポーネント32と同様に、Web-AP 42は、SIP-AP 26と連携してどのような機能を実現するかに応じてWeb-AP 42側から組み合せて利用できるものである。SIPアクセッサコンポーネント44は、用途に応じて随時拡張することが可能で、このコンポーネントの追加・拡張により、SIPシステム12との連携のバリエーションも追加・拡張されることになる。

SIPアクセッサコンポーネント44は、サービス代理UA管理部98、コールアテンプト管理部100、連携管理部96およびコンポーネントAPI 102を含む。サービス代理UA管理部98は、SIP環境のSIPシステム12内で管理するサービス代理UA情報にアクセスするWeb環境のWebシステム14内のコンポーネントである。

さらにサービス代理UA管理部98について図１を用いて説明する。サービス代理UA管理部98は、SIP環境側サービス代理UA管理部54内の各機能部を連携管理部58と連携管理部96との通信によりアクセスする機能部を含む。サービス代理UA管理部98は、代理UA生成アクセス機能部104、代理UA登録アクセス機能部106、代理UA削除アクセス機能部108、プレゼンス設定アクセス機能部110、メッセージ送信アクセス機能部112、代理UA情報編集アクセス機能部114および代理UA情報検索アクセス機能部116をそれぞれ、含む。

代理UA生成アクセス機能部104、代理UA登録アクセス機能部106および代理UA削除アクセス機能部108は、それぞれ、Webシステム14内から、SIPシステム12におけるサービス代理UA管理部54内の代理UA生成機能部62、代理UA登録機能部64および代理UA削除機能部66にアクセスするためのモジュールである。プレゼンス設定アクセス機能部110は、サービスのプレゼンス状態の変更に応じてサービス代理UA管理部98からサービス代理UA管理部54のプレゼンス設定機能部68にアクセスし、代理UAのプレゼンスを変更するモジュールである。プレゼンスの変更結果はSIPサーバ22を介してプレゼンス情報のウォッチャに通知される。

また、メッセージ送信アクセス機能部112は、サービスの経過状況の変化に応じてサービス代理UA管理部98からサービス代理UA管理部54のメッセージ送信機能部70にアクセスし、代理UAのメッセージを作成したり送信したりするモジュールである。メッセージはSIPサーバ22を介して受信側に通知される。

代理UA情報編集アクセス機能部114および代理UA情報検索アクセス機能部116は、それぞれ、Webシステム14からSIPシステム12におけるサービス代理UA管理部54内の代理UA情報編集機能部72および代理UA情報検索機能部74をアクセスするモジュールである。

このようにサービス代理UA管理部98に格納される機能部すべては、それぞれ、SIP環境側サービス代理UA管理部54内の対応する機能部をアクセスすることにより、Web環境側からのアクセスを実現する。

コールアテンプト管理部100は、SIPシステム12内で管理するコールアテンプト情報にアクセスするWebシステム14内のコンポーネントである。コールアテンプト管理部100は、生成アクセス機能部118、削除アクセス機能部120、ステータス検索アクセス機能部122、ステータス設定アクセス機能部124、ステータス変更通知アクセス機能部126、ステータス滞留通知アクセス機能部128、情報編集アクセス機能部130および情報検索アクセス機能部132を含む。

生成アクセス機能部118および削除アクセス機能部120は、Webシステム14からSIPシステム12におけるコールアテンプト管理部56の生成機能部76および削除機能部78にそれぞれ、アクセスする機能を有するモジュールである。ステータス検索アクセス機能部122およびステータス設定アクセス機能部124は、Webシステム14内からSIPシステム12におけるコールアテンプト管理部56のステータス検索機能部80およびステータス設定機能部82にそれぞれ、アクセスする機能を有するモジュールである。

また、ステータス変更通知アクセス機能部126およびステータス滞留通知アクセス機能部128は、Webシステム14からSIPシステム12におけるコールアテンプト管理部56のステータス変更通知機能部84およびステータス滞留通知機能部86にそれぞれ、アクセスする機能を有するモジュールである。さらに、情報編集アクセス機能部130および情報検索アクセス機能部132は、Webシステム14からSIPシステムにおけるコールアテンプト管理部56の情報編集機能部88および情報検索機能部90にそれぞれ、アクセスする機能を有するモジュールである。

連携管理部96は、SIPシステム12内の対応する連携管理部58と連携し、サービス代理UA管理部54およびコールアテンプト管理部56を利用して、SIPシステム12にアクセスまたはWebシステム14側をアクセスさせる機能を有している。この機能は、SIPシステム12の連携管理に対応した通信環境が設定されている。この通信環境には、SOAPやCORBA等の連携管理環境が用いられている。

コンポーネントAPI 102は、Web-AP 42が利用するために配設されている。コンポーネントAPI 102は、図１に示すように、サービス代理UA管理部98とコールアテンプト管理部100に対応してコンポーネントAPI 134および136を、それぞれ含む。

このように構成して、SIPシステム12に構築されるAPとWebシステム14に構築されるAPとを相互に連携させることができ、SIPシステム12およびWebシステム14の融合を図ることができ、リアルタイムな通信により、構築したAPのサービスをユーザに提供することができる。

次にコミュニケーションシステム10の動作について説明する。コミュニケーションシステム10は、従来HTTP-SIP変換ゲートウェイ等を用いた連携方式で問題である複数のコミュニケーションにおける目的達成の観点から一元的な状況の管理とともに、SIP-AP 30とWeb-AP 42の柔軟な連携を可能にする手順を示す。

一般的に、コミュニケーションは、対話者間において通信を確立させて、最終的に通信を切断することで単に完了するものとは限らない。コミュニケーションは目的を有して行われる。すなわち、コミュニケーションは目的を達成することで終了すると言える。目的を達成する観点からみると、コミュニケーションにはいくつかの段階がある。段階のそれぞれを前述したようにステータスと呼ぶ。

コミュニケーションにおけるステータスは、大体、完了、回答待ち、伝言待ちおよび再依頼予定に分類される。完了ステータスは目的が達成されたことを示す。回答待ちステータスは依頼事項が予定されていることを意味する。また、伝言待ちステータスは回答者に依頼事項が伝言者から伝わっていない状態にあることを示している。さらに、再依頼予定ステータスは依頼者からの依頼事項がまだ伝わっていない状態にあることを示す。

実際、頼んだつもりが伝わっていないという状況は、伝言待ちステータスと再依頼予定ステータスの齟齬という状況に相当する。より具体的に、コミュニケーション相手に電子メールは送信したがこの相手が読んでいない状況、伝言メモがおきっぱなしの状況および伝言者が忘れている状況等がある。

コミュニケーションは、最終的に、ステータスが完了となるまで、繰り返し実行される。このステータスの変化をたとえば、あるURL（Uniform Resource Locater）で一元管理し、表示できると、コミュニケーションの目的に対する達成状況をコミュニケーション当事者だけではなく、第三者も視覚的に把握することかできる。この結果、コミュニケーションが確実に実行される。これにより回答忘れや依頼忘れ等のヒューマンエラーを回避できる。また、重要な目的を達成するためのコミュニケーションについて、管理者や監督者はコミュニケーションの進捗や状況を適切にマネジメントすることが可能になり、さらに、管理者や監督者は適宜、適切な指示やヒントを与えることができる。

上述したような基本的な考え方に基づいて図５および図６に示すように、Webシステム14からSIPシステム12にアクセスして、サービス代理UAを生成する動作を順に説明する。図４のWebクライアント20のWebブラウザ50が時刻T10にてWebサーバ34およびWeb-APサーバ38のいずれか一方に“サービス生成”の実行依頼を発行する（Gen._REQ. 140）。発行されるサービス生成依頼に含まれるユーザ情報には、利用者の氏名、住所、年齢およびアドレス情報等の契約に関わる情報およびシステム利用時の認証に用いる情報が含まれている。一般的に、“サービス生成”の実行依頼は、Webブラウザ50上に表示されるWebサーバ34側が提供するGUI（Graphical User Interface）を利用して行われる。

次にWebサーバ34およびWeb-APサーバ42のいずれか一方は、Webブラウザ50から送られた“サービス生成依頼（Gen._REQ. 140）”を基に代理UA生成アクセス機能部104に対する起動信号（Launching）142を生成する。Webサーバ34およびWeb-APサーバ42のいずれか一方は、時刻T12にて生成した起動信号142をサービス代理UA管理部98に供給する。

サービス代理UA管理部98は、起動信号142に基づきコンポーネントAPI 134を利用して、代理UA生成アクセス機能部104を起動する。代理UA生成アクセス機能部104は、連携管理部96を起動させる起動信号144を生成する。起動信号144には、Webシステム14内から、SIPシステム12の代理UA生成機能部62にアクセスする要求情報（Gen._REQ.）が含まれている。代理UA生成アクセス機能部104は、時刻T14にて起動信号144を連携管理部96に出力する。

連携管理部96は、起動信号144を受けて、起動する。連携管理部96は、この起動においてSIPシステム12への情報伝達を行う上で、SOAPおよびCORBA等のいずれか一つを選択し、この選択した通信プロトコルを利用して“アクセス要求”情報を含む代理UA生成アクセス要求（Gen._REQ.）146を生成する。連携管理部96は、ネットワーク16上の別ドメイン内に存在する連携管理部58に代理UA生成アクセス要求146を時刻T16にて供給して通信する。連携管理部58は、連携管理部96から供給される代理UA生成アクセス要求146を受信し、代理UA生成機能部62を起動する起動信号148を生成する。起動信号148には“代理UAアクセス要求”情報が含まれている。連携管理部58は、時刻T18にて起動信号148をサービス代理UA管理部54の代理UA生成機能部62に出力する。

代理UA生成機能部62は、起動信号148を受けて、代理UA生成を行い、さらに起動信号150を生成し、時刻T20にて代理UA登録機能部64に出力する。代理UA登録機能部64は、起動にともない時刻T22にて代理UA情報をSIP-APサーバ26およびSIPサーバ22のいずれかにより管理されるSIP-DB 24に登録する（Registration 152）。

SIP-DB 24は、登録した代理UA情報を基に検索し、検索結果（Result）154を時刻T24にて代理UA生成機能部62に出力する。検索結果は生成SIP-URI（Uniform Resource Identifier）情報である。代理UA生成機能部62は、検索結果を受信し、検索結果を含む起動信号156を生成する。起動信号156は連携管理部58を起動する。サービス代理UA管理部54は、時刻T26にて起動信号156を連携管理部58に出力する。

連携管理部58は、起動信号156により起動される。連携管理部58は、検索結果の生成SIP-URI情報を回答する上で、SOAPおよびCORBA等のいずれか一つを選択し、この選択した通信プロトコルを利用する。連携管理部58は、この通信プロトコルを用いて“サービス生成依頼”の結果を代理UA生成応答（Gen._RES.）158として連携管理部96と通信する。連携管理部96は、“サービス生成依頼”の結果を受信する。連携管理部96は、この結果を含む応答信号（Response）160を時刻T30にて代理UA生成アクセス機能部104に出力する。代理UA生成アクセス機能部104はサービス代理UA管理部98のコンポーネントAPI 134の実行結果を受信し、時刻T32にてWebサーバ34およびWeb-APサーバ38のいずれか一方に実行結果として応答信号162を出力する。実行結果とは、SIP-DB 24上の検索により得られたユーザ情報のデータ（生成SIP-URI情報）である。

Webサーバ34およびWeb-APサーバ38のいずれか一方は、ユーザ情報の検索結果をWebクライアントが表示可能形式に加工する。表示可能形式には、たとえば、SIP-URI形式がある。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T34にて加工したデータ（Service_INF）164を“サービス生成依頼”したWebブラウザ50に供給する。Webブラウザ50は“サービス生成依頼”の結果を表示する。

次にプレゼンス設定の動作について図７および図８を用いて説明する。図７に示すWebブラウザ50が時刻T40にて“サービスプレゼンス設定”の実行依頼（Set_REQ.）170をプレゼンス設定要求として発行する。この実行依頼はSIP-URIの指定に相当している。“サービスプレゼンス設定”の実行依頼にはユーザ情報が含まれている。ユーザ情報は、利用者の氏名、住所、年齢およびアドレス情報等の契約に関わる情報やシステム利用時に認証する情報を含んでいる。また、サービスプレゼンス設定の依頼情報には、サービスの状態を表す内容も含まれており、状態が指定されている。この状態には、たとえば「実行待ち」、「処理中」、「終了」等があり、プレゼンスとして設定される。一般的に、“サービスプレゼンス設定”におけるこれらの情報設定は、Webブラウザ50上に表示されるWebサーバ34側が提供するGUIを利用して行われる。Webブラウザ50は、Webサーバ34およびWeb-APサーバ38のいずれか一方に“サービスプレゼンス設定”170を供給する。

Webサーバ34およびWeb-APサーバ38のいずれか一方は、供給された“サービスプレゼンス設定”の実行依頼を基に起動信号172を生成する。起動信号172は、時刻T42にてサービス代理UA管理部54に供給される。サービス代理UA管理部54は、起動信号172により内蔵するコンボーネントAPI 134を利用して、プレゼンス設定アクセス機能部110を起動する。プレゼンス設定アクセス機能部110は、プレゼンス設定に関する情報を含む起動信号174を生成し、時刻T44にて連携管理部96に供給する。

連携管理部96は、起動信号174を受信して、起動される。ここで、連携管理部96は、この起動においてSIPシステム12への情報伝達を行う上で、SOAPおよびCORBA等のいずれか一つを選択し、この選択した通信プロトコルを利用して“プレゼンス設定要求”情報を含むプレゼンス設定アクセス要求（Set_REQ.）176を生成する。連携管理部96は、ネットワーク16上の別ドメイン内に存在する連携管理部58にプレゼンス設定アクセス要求176を時刻T46にて供給して通信する。

連携管理部58は、連携管理部96から供給されるプレゼンス設定アクセス要求176を受信し、プレゼンス設定機能部68を起動する起動信号を生成する。起動信号には“プレゼンス設定アクセス要求”情報が含まれている。連携管理部58は、時刻T48にて起動信号178をサービス代理UA管理部54のプレゼンス設定機能部68に出力する。

プレゼンス設定機能部68は、起動信号178を受けて、起動する。この起動によりプレゼンス設定機能部68は、代理UAとして起動信号178に含まれるプレゼンス情報にSIP-DB 24内のプレゼンス情報の設定を変更するようにSIP-DB 24にアクセスする（Change 180）。SIP-DB 24はSIP-APサーバ26およびSIPサーバ22の少なくとも一方により管理されている。

この変更後、図７に示していないが、代理UA情報検索機能部74が起動し、SIP-DB 24に対して検索する。SIP-DB 24は、時刻T52にてプレゼンス情報の検索結果を代理UA情報検索機能部74に出力する（Response 182）。代理UA情報検索機能部74は、供給されたプレゼンス情報の検索結果をプレゼンス設定機能部68に供給する。

ところで、プレゼンス設定機能部68は、SIP-DB 24に登録されたプレゼンス情報の変更をたとえば、SIPソフトフォン46に通知する。この変更通知は、時刻T52以降に行う検索処理のシーケンスであり、検索処理シーケンスは非同期にウォッチャの数だけ実行する（Notify 184a）。

サービス代理UA管埋部54は、時刻T54にて検索結果を含む起動信号184を連携管理部58に供給し、起動する。連携管理部58は、SOAPおよびCORBA等のいずれか一つを利用し、時刻T56にて連携管理部96と通信を行う（Response 186）。連携管理部96は、時刻T58にてサービス代理UA管理部98のプレゼンス設定アクセス機能部110に応答信号188を供給する。応答信号188は、“プレゼンス設定依頼”の結果を含み、通常設定が成功の場合、設定したプレゼンス内容が「実行待ち」のステータスような結果として送信される。また、設定が失敗の場合、応答信号188はNG（No Good）が結果として送信される。

サービス代理UA管理部98におけるプレゼンス設定アクセス機能部110は、時刻T60にてコンポーネントAPI 134の実行結果としてWebサーバ34およびWeb-APサーバ38のいずれかに供給する（Response 190）。この実行結果とは、SIP-DB 24での検索により得られたユーザ情報のデータを示す。Webサーバ32およびWeb-APサーバ36のいずれか一方は、この実行結果を表示できる形式にする。形式には、たとえば、SIP-URI形式がある。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T62にて依頼したWebブラウザ50に“サービスプレゼンス設定依頼”の結果、すなわちサービスプレゼンス（Service_Presence）192を供給し、表示する。

このように動作させることにより、WebブラウザまたはWebクライアントからのプレゼンス設定依頼に対応してSIPシステム12のSIP-DB 24に設定し、SIP-DB 24での設定状況を応答信号として要求したクライアントに容易に提供することができる。

さらに、コミュニケーションシステム10におけるメッセージ送信の動作について図９および図10を参照しながら、簡単に説明する。使用する構成要素はまったく同じで、構成要素それぞれに対する参照符号も同じ番号を用いている。

Webブラウザ50は、時刻T70にて“メッセージ送信”の実行依頼（Send_REQ.）200をWebサーバ34およびWeb-APサーバ38のいずれか一方に発行する。ここで扱うユーザ情報、GUIも先の動作説明と同じである。Webサーバ34およびWeb-APサーバ38のいずれか一方は、受信した“メッセージ送信依頼”（Send_REQ.）200を基に起動信号202を生成し、時刻T72にて起動信号202をメッセージ送信アクセス機能部112に供給する。起動信号202は、コンポーネントAPI 134を利用して、メッセージ送信アクセス機能部112を起動する。

メッセージ送信アクセス機能部112は、時刻T74にて連携管理部96を起動する（Launching 204）。連携管埋部96は、SOAPおよびCORBA等のいずれか一つを利用して、ネットワーク16上の別ドメイン内に存在する連携管理部58と時刻T76にて通信を行う。連携管理部58は、“メッセージ送信依頼”（Send_REQ.）206を受信する。連携管理部58は、時刻T78にてメッセージ送信機能部70を起動する（Launching 208）。

メッセージ送信機能部70は、時刻T80にてSIPクライアントであるSIPソフトフォン46にメッセージ（Message）210を送出し、モニタに表示する。SIPクライアントがメッセージ受信者に対応している。メッセージ送信機能部70は、図示しないがSIPソフトフォン46からメッセージ応答を受信する。メッセージ送信機能部70は、時刻T82にて応答内容を含む起動信号212を連携管理部50に供給し、起動する。

連携管埋部58は、送信結果の応答を送る上でSOAPおよびCORBA等のいずれか一つを利用し、時刻T84にて連携管理部96と通信を行う（Response 214）。連携管理部96は、Webブラウザ50により発行された“メッセージ送信依頼”の結果を受信する。連携管理部96は、時刻T86にて代理UA管理部76のメッセージ送信アクセス機能部88に送信する（Response 216）。

メッセージ送信アクセス機能部112は、供給された“メッセージ送信依頼”の結果を受信し、時刻T88にてコンポーネントAPI 134の実行結果としてWebサーバ34およびWeb-APサーバ38のいずれか一方に出力する（Response 218）。Webサーバ34およびWeb-APサーバ38のいずれか一方は、メッセージ送信依頼の結果を表示できる形式に加工する。形式にはたとえば、SIP-URI形式がある。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T90にてWebブラウザ50に応答信号（Response 220）を供給する。Webブラウザ50は“メッセージ送信依頼”の結果をモニタに表示する。

このように動作させて、代理UA管理部54および98と連携管理部58および96を利用して、Web上のサービスをトラッキングし、メッセージをコミュニケーションシステム10において構成する一方のシステムから他方のシステムに通知することができ、通知結果も送信元に供給することができる。また、長時間HTTPのトランザクションを保留しないことから、リソースの有効利用や実際的なアプリケーションとしてのユーザインタフェース実現が容易に可能となる。

次にコールアテンプト管理におけるコールアテンプト生成、ステータス設定、ステータス変更通知およびステータス滞留通知の動作について順に説明する。

コールアテンプト生成は、図11および図12の動作シーケンスで説明する。Webブラウザ50が目的を達成するようにコミュニケーションを開始する。この開始の前にWebブラウザ50は、時刻T100にてWebサーバ34およびWeb-APサーバ38のいずれか一方にコンタクトリスト要求依頼（List_REQ. 230）を発行する。

コンタクトリスト要求を受信したWebサーバ34およびWeb-APサーバ38のいずれか一方は、要求に応じた応答として時刻T102にて複数の発信候補先からなるコンタクトリストをコミュニケーションすべき候補としてWebブラウザ50に出力する（List_Disp. 232）。この供給によりWebブラウザ50には、Webページ上に供給されたコンタクトリストが表示される。コンクタクトリストには通信先の氏名、電話番号およびプレゼンス等の情報が含まれている。

ユーザは、時刻T104にてWebブラウザ50に表示された特定の項目をコンタクト先として選択する（List_SEL. 234）。これより、発信が実行される。このように一般的に、コミュニケーションは、目的別のWebページから新規用件として発信することで開始となる。

Webサーバ34およびWeb-APサーバ38のいずれかが供給された“コンタクトリスト選択”（List_SEL. 234）の情報を含む起動信号236を生成する。起動信号236は、時刻T106にてコールアテンプト管理部100に出力される.コールアテンプト管理部100は、起動信号236により対応するコンポーネントAPI 136を利用して、生成アクセス機能部118を起動する。

生成アクセス機能部118は連携管理部96に対するコンタクトリスト選択の情報を含む起動信号238を生成する。生成アクセス機能部118は、時刻T108にて起動信号238を連携管理部96に出力する。連携管理部96は、起動信号238を受けて、起動する。

ここで、連携管理部96は、この起動においてSIPシステム12への情報伝達を行う上で、SOAPおよびCORBA等のいずれか一つを選択し、この選択した通信プロトコルを利用して“コールアテンプト生成依頼”情報を含む要求（CA_Gen._REQ.）240を生成する。連携管理部96は、ネットワーク16上の別ドメイン内に存在する連携管理部58に“コールアテンプト生成依頼”情報を含む要求240を時刻T110にて供給して通信する。

連携管理部58は、コールアテンプト管理部54の生成機能部76に対する起動信号を生成する。連携管理部58は、時刻T112にて起動信号242を生成機能部76に出力する。起動信号242は、コールアテンプト管理部56に対応するコンポーネントAPI 94を利用して、生成機能部76を起動する。生成機能部76は、用件に相当するコールアテンプトのインスタンス（Instance 244）を生成する。生成機能部76は、時刻T114にてSIP-DB 24に生成したインスタンス244を格納する（登録）。SIP-DB 24は、登録に対する応答信号（Response）246を時刻T116にて生成機能部76に出力する。

生成機能部76は、SIP-DB 24からの応答信号246を受信して、コールアテンプト生成の完了を知る。この完了を受けて、生成機能部76は、連携管理部58を起動させる起動信号248を生成する。生成機能部76は、時刻T118にて起動信号248を連携管理部58に出力する。連携管理部58は、起動信号248を受けて、起動する。

連携管理部58は、コールアテンプト管理部100に送信結果を回答するため、SOAPおよびCORBA等のいずれか一つの通信プロトコルを利用する。連携管理部58は、選択した通信プロトコルを用いて、時刻T120にて連携管理部96と通信し、応答信号250を送信する。さらに、連携管理部96は、時刻T122にて連携管理部58との通信により得られた“コールアテンプト生成依頼”の結果（Response）252を生成アクセス機能部118に出力する。

次にコールアテンプト管理部100は生成アクセス機能部118が受信した結果をコンポーネントAPI 94の実行結果として時刻T124にてWebサーバ34およびWeb-APサーバ38のいずれか一方に返す。Webサーバ34およびWeb-APサーバ38のいずれか一方は、該当するコンタクト先が選択されていることが表示できる形式に加工する。加工例には反転表示等がある。

Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T126にて加工した“コンタクトリスト選択”の結果（Result）256をWebブラウザ50に出力する。Webブラウザ50は、供給された結果256を表示する。

この後、前述した代理UA生成の図５に示した動作シーケンスの内、時刻T12〜T32までの一連の動作を継続させる。この後、コミュニケーションの確立に向けて動作させる。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T128にて連携管理部96の起動信号258を生成する。起動信号258は、SIP-APサーバ26およびSIPサーバ22のいずれか一方に“コール確立”させる依頼情報を含んでいる。“コール確立”の依頼情報とは、たとえばコンタクト選択先のSIPクライアント46と利用者のSIPクライアント48の間における“コール確立”要求である。連携管理部96は、時刻T130にて連携管理部58に“コール確立”要求（Contact_REQ.）260を選択した通信プロトコルを用いて供給する。

連携管理部58は、時刻T132にて“コール確立”の依頼情報を含む起動信号262を生成する。連携管理部58は、SIP-APサーバ26およびSIPサーバ22のいずれか一方に起動信号262を時刻T132にて出力する。SIP-APサーバ26およびSIPサーバ22のいずれか一方は、起動信号262を受けて、たとえば3PCC（3rd Party Call Control: 第三者呼制御）の手順を利用して、時刻T134にてコンタククト選択先のSIPクライアント46に呼制御信号（Call_CON.）264を発信する。また、SIP-APサーバ26およびSIPサーバ22のいずれか一方は、同様にして、利用者のSIPクライアント48に呼制御信号266を発信する。結果、SIPクライアント46とSIPクライアント48の間にコールが確立する。

このように動作させて、コミュニケーションシステム10は、発信と同時に用件に相当するコールアテンプトと用件のステータス変化を通知する代理UAを自動生成するとともに、コミュニケーションが確立する。

次にステータス設定コールアテンプト生成の動作について図13および図14を用いて説明する。まず、コミュニケーション中のSIPクライアント48が時刻T140で切断操作をする。これにより、“コール切断（Call_CUT 270）”がSIP-APサーバ26およびSIPサーバ22のいずれか一方に伝わる。SIP-APサーバ26およびSIPサーバ22のいずれか一方は、コミュニケーションの相手であるSIPクライアント46に切断の旨（Call_CUT）272を時刻T142にて伝える。これにより、SIPクライアント46および48はコミュニケーションを終了する。

同時に、SIP-APサーバ26およびSIPサーバ22の一方は、コール終了情報を含む連携管理部58を起動する起動信号274を生成する。SIP-APサーバ26およびSIPサーバ22の一方は、時刻T144にて起動信号274を連携管理部58に出力する。連携管理部58は、時刻T146にて選択した通信プロトコルを用いて連携管理部96にコミュニケーションの終了を伝える（COM._END 276）。連携管理部96は、時刻T148にてWebサーバ34およびWeb-APサーバ38のいずれか一方にコンタクト選択先のSIPクライアント46と利用者のSIPクライアント48との間での“コール終了”を通知する（Notify 278）。

Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T150にてWebブラウザ50に“ステータスの入力画面”のデータ（Disp._DATA）280を供給し、表示する。この表示により、ユーザに用件状況の入力を促進する。ユーザは、直前のコミュニケーションにより目的とする用件はどのような状況に変化したかを入力する。Webブラウザ50は、入力内容（Status_IN）282をWebサーバ34およびWeb-APサーバ38のいずれか一方に出力する。

Webサーバ34およびWeb-APサーバ38のいずれか一方は、送られた“ステータス内容（Status_IN）282”を含む起動信号284を生成する。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T154にて生成した起動信号284をコールアテンプト管理部100に出力する。コールアテンプト管理部100は、内蔵するコンポーネントAPI 136を利用して、ステータス設定アクセス機能部124を起動する。

ステータス設定アクセス機能部124は、連携管理部96に対する起動信号286を生成する。ステータス設定アクセス機能部124は、“ステータス内容”を含む起動信号286を時刻T156にて出力する。連携管理部96は、起動信号286を受けて、起動する。

連携管理部96は、コールアテンプト管理部56に情報（Status_IN）を伝達するため、SOAPおよびCORBA等のいずれかの通信プロトコルを選択する。連携管理部96は、選択した通信プロトコルを利用し、ネットワーク上の別ドメイン内に存在する連携管理部58と時刻T158にて通信する（Status_IN 288）。

連携管理部58は、連携管理部96との通信により、ステータス設定アクセス機能部124で発行された“ステータス内容”を受信する。連携管理部58は、コールアテンプト管理部56内のステータス設定機能部82を起動する起動信号290を生成する。連携管理部58は、起動信号290を時刻T160にてコールアテンプト管理部56に供給する。

ステータス設定機能部82は、時刻T162にて用件に相当するコールアテンプトのステータス値で該当するSIP-DB 24の値を蛮更する指示を出力する（Change 292）。SIP-DB 24は、指示に応じてステータス値を変更する。SIP-DB 24は、ステータス設定機能部82にステータス設定の完了を意味する応答信号294を時刻T164にて出力する。ステータス設定機能部82は、ステータス設定の完了を受信して、連携管理部58の起動信号294を生成する。ステータス設定機能部82は、時刻T166にて連携管理部58に上述した完了情報を含む起動信号294を出力する。

連携管理部58は、起動信号296を受信して、時刻T168にて応答信号298を連携管理部96に供給する。この供給において連携管理部58は、コールアテンプト管埋部100に設定結果を回答するため、SOAPおよびCORBA等のいずれか一つの通信プロトコルを選択し、利用して、連携管理部96と通信している。連携管理部96は、時刻T170にて通信により得られた応答信号300をステータス設定アクセス機能部124に出力する。応答信号300は、ステータス設定アクセス機能部124で発行された“ステータス内容”の設定結果である。

ステータス設定アクセス機能部124は、“ステータス内容”の設定結果を受信して、時刻T172にてコンポーネントAPI 136の実行結果として、Webサーバ34およびWeb-APサーバ38のいずれか一方に返却される（Response 302）。Webサーバ34およびWeb-APサーバ38のいずれか一方は、ユーザが指定したステータスが設定されていることが表示できる形式に加工する。この形式とは、たとえば設定確認メッセージ表示の形式である。Webサーバ34およびWeb-APサーバ38のいずれか一方は、時刻T174にて加工した形式のデータ（Disp._DATA）304を時刻T152での“ステータス入力”の結果としてWebブラウザ50に供給する。Webブラウザ50は、“ステータス入力”の結果を表示する。

コミュニケーションの終了を受けて、コール確立からの統きとして、Webブラウザ50にステータス入力の画面を表示し、コミュニケーションにより目的とする用件がどのような状況に変化したかを入力する。この結果、コールアテンプトのステータスが変更させられ、ユーザは変更結果をWebブラウザ50で知ることができる。

次にステータス変更通知の動作について図15および図16を用いて説明する。まず、用件に関連するユーザは、SIPクライアント46および48を使用して、ステータスの変更を通知するために“ステータス変更通知依頼（Change_REQ. 310, および312）”を時刻T180およびT182にてそれぞれ、SIP-APサーバ26およびSIPサーバ22のいずれか一方に送る。これを受けてSIP-APサーバ26およびSIPサーバ22のいずれか一方は、時刻T184およびT186にてそれぞれ、SIPクライアント46および48を用件に対応する代理UAのプレゼンス通知先としてSIP-DB 24に登録する（Registration 314, および316）。SIP-DB 24は、時刻T188およびT1990にてそれぞれ、登録の結果（Response 318, および320）をSIP-APサーバ26およびSIPサーバ22のいずれか一方に供給する。SIP-APサーバ26およびSIPサーバ22のいずれか一方は、登録の結果322および324をSIPクライアント46および48に“ステータス変更通知依頼”の確認結果としてそれぞれ、送る。

このような通知依頼が行われた後、Webサーバ34およびWeb-APサーバ38の一方は、ステータス設定の動作等により用件の状況が変化する。この状況変化は、コールアテンプトのステータスが変化することである。Webサーバ34およびWeb-APサーバ38の一方は、対応する代理UAのプレゼンスの仕組みを利用して、依頼しているSIPクライアント46および48にステータス変更を通知する。

ステータス変更に際してWebサーバ34およびWeb-APサーバ38の一方は、時刻T196にて変更されたステータスの内容を基にコールアテンプト管埋部100内のコンポーネントAPI 136を利用して、ステータス変更通知アクセス機能部126を起動する起動信号を生成する。Webサーバ34およびWeb-APサーバ38の一方は、生成した起動信号326を時刻T196にて出力する。

ステータス変更通知アクセス機能部126は、ステータスの内容を代理UAのプレゼンス内容に置き換えて、サービス代理UA管理部98内のコンポーネントAPI 134を利用して、プレゼンス設定アクセス機能部110を起動する起動信号を生成する。ステータス変更通知アクセス機能部126は、時刻T198にて起動信号328を出力する。この後、図７および図８に示した時刻T44〜T58までの動作が順次行われる。ただし、SIP-DB 24は、それぞれ、SIPクライアント46および48に時刻T51aおよびT51bにて変更を通知する。変更処理は、検索処理シーケンスであり、非同期にウォッチャの数だけ実行する（Notify 184a, および184b）。

その後、プレゼンスによる通知が行われた結果である時刻T58に対応する応答信号188をプレゼンス設定アクセス機能部110に供給するように動作が続く。プレゼンス設定アクセス機能部110は、サービス代理UA管埋部98におけるコンポーネントAPI 134の実行結果としての応答信号330を時刻T200にてステータス変更通知アクセス機能部126に返す。

ステータス変更通知アクセス機能部126は、さらに、コールアテンプト管埋部100のコンポーネントAPI 136における実行結果（Response 332）として、時刻T202にてWebサーバ34およびWeb-APサーバ38の一方に返却する。Webサーバ34およびWeb-APサーバ38の一方は、加工した実行結果（Status_INF.）334を時刻T204にてWebブラウザ50に供給する。Webブラウザ50は、画面に供給された実行結果334を表示する。

このように用件の状況としてコールアテンプトのステータスが変化した場合、Webサーバ34およびWeb-APサーバ38の一方は、対応する代埋UAのプレゼンスの仕組みを利用して、ステータス変更通知を依頼しているSIPクライアント46および48にそれぞれ、ステータス変更を通知する。コールアテンプトのステータス変更は、あらかじめ通知を依頼しているすべてのSIPクライアントに通知される。ただし、依頼していないSIPクライアントには通知されない。

次にステータス滞留通知の動作について図15および図17を用いて説明する。図15に示すように時刻T180〜T194まで同じように動作させる。この動作結果により、SIPクライアント46および48が滞留通知先となる。

ここで、Webサーバ34およびWeb-APサーバ38の一方は、コールアテンプト管理部100のステータス変更通知アクセス機能部126を監視している。Webサーバ34およびWeb-APサーバ38の一方は、ステータス変更通知アクセス機能部126が既定の時間を経過しても変更されない場合、対応する代理UAのプレゼンスの仕組みを利用して、依頼しているSIPクライアント46および48に対してステータス変更を通知する。既定の時間とは、たとえば、１時間等に設定し、ステータス毎にシステムで想定するようにしてもよい。

Webサーバ34およびWeb-APサーバ38の一方が、既定の時間を過ぎて滞留している用件を発見すると、Webサーバ34およびWeb-APサーバ38の一方は、コールアテンプト管理部100内のコンポーネントAPI 136を利用して、ステータス滞留通知アクセス機能部128に対する起動信号340を生成する。Webサーバ34およびWeb-APサーバ38の一方は、生成した起動信号340を時刻T210にてステータス滞留通知アクセス機能部128に出力する。ステータス滞留通知アクセス機能部128は、起動信号340を受けて、起動する。

ステータス滞留通知アクセス機能部128は、滞留しているコールアテンプトに対応する代理UAのプレゼンス内容を滞留の警告メッセージに置き換えて、プレゼンス設定アクセス機能部110を起動させる起動信号342を生成する。警告メッセージには、たとえば“至急対応指示ください”という文宇列等を用いることが好ましい。

ステータス滞留通知アクセス機能部128は、時刻T212にて起動信号342をサービス代理UA管理部98に供給する。サービス代理UA管理部98は、起動信号342を受けて、コンポーネントAPI 134を利用して、起動する。この後、コミュニケーションシステム10は、図７および図８に示した時刻T44〜T58までを順次動作させ、依頼しているSIPクライアント46および48にステータス滞留アラームを通知し、プレゼンスによる通知が行われた結果である時刻T58に対応する応答信号188をプレゼンス設定アクセス機能部110に供給するように動作を継続させる。

プレゼンス設定アクセス機能部110は、サービス代理UA管埋部98におけるコンポーネントAPI 134の実行結果としての応答信号344を時刻T214にてステータス滞留通知アクセス機能部128に返す。

ステータス滞留通知アクセス機能部128は、さらに、コールアテンプト管埋部100のコンポーネントAPI 136における実行結果（Response 346）として、時刻T216にてWebサーバ34およびWeb-APサーバ38の一方に返却する。Webサーバ34およびWeb-APサーバ38の一方は、加工した実行結果（Status_INF.）348を時刻T218にてWebブラウザ50に供給する。Webブラウザ50は、画面に供給された実行結果348を表示する。

このようにステータスが既定の時間を経過しても変更されない場合、Webサーバ34およびWeb-APサーバ38は、対応する代理UAのプレゼンスの仕組みを利用して、依頼しているSIPクライアント46および48にそれぞれ、ステータス滞留アラームを通知することができる。

本実施例のように動作させることにより、Webシステム14上に構築されるAPと、SIPシステム12上に構築されるAPが相互に連携可能となり、WebとVoIPの融合型APの構築・実行・運用が容易に実現され、コールアテンプト管埋部56および100を利用することにより、Web上のコミュニケーション用件を通して複数のコミュニケーションを実行することで、目的達成の観点から一元的な状況管理が実現できる。

また、状況の変化や長時間の滞留をトラッキングし、経過状況に応じてSIPシステム12内のSIP-DB 24上で、プレゼンスを変化させ、通知することができる。これにより、長時間HTTPのトランザクションを保留しないで済むことから、リソースの有効利用や実際的なアプリケーションとしてのユーザインタフェース実現が容易に可能となる。

次に本発明を適用したコミュニケーションシステム10の他の実施例（第１変形例）について図18を参照しながら説明する。本実施例のコミュニケーションシステム10はSIPシステム12とWebシステムとが１つの計算機350上に配置された場合である。ここで、構成要素に関しては、先の実施例と共通する部分に同じ参照符号を付して、説明を省略する。コミュニケーションシステム10は、図18に示すように、同一計算機上のプロセス連携により接続されている。この接続から明らかなように本実施例のコミュニケーションシステム10は、ネットワークの接続を介さない。また、図３および図４に示した連携管理部58および96のそれぞれは、あえて構成要素として配設するのではなく、Webアクセッサコンポーネント32とSIPアクセッサコンポーネント44にそれぞれ、これらと同様に連携管理を行う関数呼出し機能部352により異なるシステム間をつなぐ。関数呼出し機能部352は、たとえば、C言語やC++言語の関数呼出しやJava（商標）言語のメソッドコールを用いたプログラムを配するとよい。動作手順は先の実施例と同じである。

このように構成しても、先の実施例と同様に、Web環境上に構築されるAPとSIP環境上に構築されるAPとを相互に連携することが可能になる。これにより、WebとVoIPの融合型APの構築・実行・運用が容易に実現されることになる。また、本実施例では、単一計算機環境上にシステムを構築することにより、小規模な計算機環境下でのWeb-APとVoIP-APの融合が実現することができる。

次に本発明を適用したコミュニケーションシステム10の他の実施例（第２変形例）について図19および図20を参照しながら説明する。本実施例のコミュニケーションシステム10は、SIPシステム12とFTP（File Transfer Protocol）システム400とが、ネットワーク16により接続されている。ここで、SIPシステム12とFTPシステム400は異なるネットワークドメインに属するネットワーク環境上に配置されている。また、SIPシステム12およびFTPシステム400は、それぞれ最初の実施例と同様に１つのサーバ計算機内または同じドメイン内のLAN環境に配置する構成にしている。

SIPシステム12は、図19に示すように、最初の実施例とまったく同じ構成を用い、同じ参照符号を付して説明を省略する。ただし、本実施例の場合、SIPシステム12におけるアクセッサコンポーネントの機能は、Webアクセッサコンポーネント32とまったく同じであるが、Web対応でなく、FTPであることから、名称をFTPアクセッサコンポーネント402としている。

もう一方のシステムであるFTPシステム400は、FTPサーバ404、FTPデータベース（FTP-DB）406、FTPアプリケーションサーバ（FTP-APサーバ）408、FTPアプリケーションインタフェース（FTP-API）410、FTPアプリケーション（FTP-AP）412、SIPアクセッサコンポーネント414およびFTPクライアント416を含む。以下に、各構成要素について簡単に説明する。

FTPサーバ404はFTPをハンドリング・管埋するサーバである。FTP-DB 406はFTPサーバ404が管理する情報を格納するストレージで、データベースである。格納する情報は、FTPにより転送されたファイル情報等である。FTP-APサーバ408はFTPサーバ404により管理されるファイル転送プロトコル（FTP）を操作するAPを稼動するサーバである。FTP-API 410は、FTP-APサーバ408が提供するAPインタフェースである。FTP-AP 412は、FTP-API 410により構築され、FTP-APサーバ412上で稼動するFTP-APである。APには、たとえば２者間でのピア・ツー・ピア型のファイル交換、ファイル共有等のAPがある。

SIPアクセッサコンポーネント414は、FTP-AP 412がSIPシステム12と連携するコンポーネント群（ソフトウェア部品）の総称である。SIPアクセッサコンポーネント414は、前述したWebシステム14のSIPアクセッサコンポーネント44と同じものである。すなわち、代理UA管理部98、コールアテンプト管理部100、連携管理部96およびコンポーネントAPI 102を含む。各構成要素の機能は、前述した最初の実施例と同じである。

FTPクライアント416はFTPサーバ404と接続し、FTP-AP 412が提供する機能を利用する環境に設定されているクライアントである。FTPクライアント416には複数のFTPクライアント端末418および420を有してもよい。FTPクライアント端末418は、一般的にテキスト表示画面を有し、この画面を通じてファイル転送要求を出し、ファイル転送結果を表示する。

この構成により、異なるシステムにもかかわらず、得られた情報を要求のあったクライアントに提供するアプリケーションを構築することができる。すなわち、FTPシステム400上に構築されるAPとSIPシステム12上に構築されるAPが相互に連携可能となり、FTPとVoIPの融合型APの構築・実行・運用が容易に実現される。この構築により各システムの情報を共有して、スムーズに利用することができるようになる。また、FTPアクセッサコンポーネント402上とSIPアクセッサコンポーネント414上の各種コンポーネントを増設することにより、FTPとVoIPの融合タイプを拡張することができる。実装するSIP-APとFTP-APの種類とともに、このコンポーネントの種類を増やすことにより、様々なFTPとVoIPの融合型APを実現することができる。

次に本実施例のコミュニケーションシステム10におけるステータス変更通知の動作について図15および図21を用いて説明する。ステータス変更通知は、図15に示す時刻T180〜T194の動作に同じ手順で処理されている。この結果、SIPクライアント46および48がステータス変更通知先となる。

FTPクライアント418が、時刻T220にて“ファイル転送依頼”（Trans._REQ.）422を発行する。ここで、ファイル内容はコールアテンプトの新たなステータス内容になる。FTPサーバ404およびFTP-APサーバ408のいずれか一方は、受け取った“ファイル転送依頼”422を基にファイル転送を実行する。この実行後、FTPサーバ404およびFTP-APサーバ408のいずれか一方は、転送されたファイルの内容からステータスを変更するコールアテンプトの識別子および新たなステータス内容を読み取る。FTPサーバ404およびFTP-APサーバ408のいずれか一方は、ステータス変更通知アクセス機能部126を起動する起動信号424を生成する。FTPサーバ404およびFTP-APサーバ408のいずれか一方は、時刻T222にて起動信号424をコールアテンプト管理部100に供給する。起動信号424には、読み取ったコールアテンプトの識別子および新たなステータス内容の情報が含まれている。コールアテンプト管理部100は、図１に示したコンポーネントAPI 136を利用して、ステータス変更通知アクセス機能部126を起動する。

ステータス変更通知アクセス機能部126は、ステータスの内容を代理UAのプレゼンス内容に置き換える。ステータス変更通知アクセス機能部126は、置き換えたプレゼンス内容を含むサービス代理UA管理部98のプレゼンス設定アクセス機能部110を起動する起動信号426を生成する。ステータス変更通知アクセス機能部126は、時刻T224にて生成した起動信号426をサービス代理UA管理部98に供給する。サービス代理UA管理部98は、起動信号426を受信して、コンポーネントAPI 134を利用して、プレゼンス設定アクセスモジュールを起動する。

この後、図７および図８にて示したと同様に時刻T44〜T58までと同じ手順で処理する。本実施例では、WebをFTPと読み替えることより時刻T44〜T58までの処理がより明確になるであろう。この後、プレゼンスによる通知が行われた結果を時刻T226〜T230まで動作が続く。

プレゼンス設定アクセス機能部110は、時刻T226にてコンポーネントAPI 134の実行結果としてステータス変更通知アクセス機能部126にステータス通知結果（Response）を返却する。ステータス変更通知アクセス機能部126は、時刻T228にてコンポーネントAPI 136の実行結果として、FTPサーバ404およびFTP-APサーバ408のいずれか一方にステータス通知結果（Response）430を返す。FTPサーバ404およびFTP-APサーバ408のいずれか一方は、ステータス通知結果をFTPクライアント端末が表示可能形式に加工する。表示可能形式には、たとえば、SIP-URI形式がある。FTPサーバ404およびFTP-APサーバ408は、時刻T230にて加工したデータ（Status_INF）432を“ファイル転送依頼”したFTPクライアント端末418に供給する。FTPクライアント端末418は“ファイル転送依頼”の結果を表示する。

このように動作させることにより、FTPクライアント端末418からのファイル転送を機にファイル内容をステータス変更するコールアテンプトの識別子および新たなステータス内容として扱い、ファイル転送によるファイル更新によりコールアテンプトのステータスが変化し、FTPサーバ404およびFTP-APサーバ408のいずれか一方は、対応する代理UAのプレゼンスの仕組みを利用して、依頼しているSIPクライアント46および48にステータス変更を通知することができ、処理結果をFTPクライアント端末418に表示することによりユーザはステータスの変更処理した結果を知ることができる。

ただし、コールアテンプトのステータス変更があらかじめ通知を依頼しているすべてのSIPクライアントだけに通知されることは言うまでもない。

このようにFTPシステム400上に構築されるAPと、SIPシステム12上に構築されるAPが相互に連携可能となり、FTPとVoIPの融合型APの構築・実行・運用が容易に実現されることになる。本実施例は、FTPアクセッサコンポーネント402上とSIPアクセッサコンポーネント414上とに各種コンポーネントを増設することにより、FTPとVoIPの融合タイプを拡張することが可能となる。また、実装するSIP-AP 30とFTP-AP 412の２種類とともに、これらのコンポーネントの種類を増やすことにより、様々なFTPとVoIPの融合型APの実現が可能となる。本実施例は、ステータスの変更通知の手順を説明したが、この例だけに限定されるものでなく、この他のコールアテンプト管理部100が有するアクセス機能を実現できることは言うまでもない。

なお、融合は、VoIP-AP（SIP-AP）とWeb-APやVoIP-AP（SIP-AP）とFTP-APに限定されるものでなく、様々な異なるプロトコル間の融合に適用することも可能である。

以上のように構成することにより、Webシステム14に接続するWebブラウザ50からの要求をコールアテンプトとして実行する場合、HTTPプロトコルでこの要求に対するコールアテンプト管理部100を起動させ、連携管理部96でこの要求をSOAP/CORBAのプロトコルの要求にして、連携管理部58に送り、連携管理部58でSIP通信プロトコルの要求にし、コールアテンプト管理部56で要求に対する処理を行い、この処理結果の応答をコールアテンプト管理部56、連携管理部58、連携管理部96、コールアテント管理部100を経て要求したWebブラウザ50に送って、表示させ、サービス代理UA管理部98、連携管理部96、連携管理部58およびサービス代理UA管理部54を順に動作させて、登録し、逆の順序で登録結果をWebシステム14に返し、この後、Webシステム14から用件を実行して、異種の通信プロトコル間での発呼インスタンスに対応したコールを確立させることにより、目的達成の観点から一元的な状況管理を実現し、長時間HTTPのトランザクションを保留しなくて済むことから、リソースの有効利用、実際的なアプリケーションとしてのユーザインタフェースを容易に実現することができる。

コールアテンプト管理部56は、発呼のインスタンスに対応するコールアテンプトの生成、削除、情報編集および情報検索、ならびにステータスの検索、設定、変更通知およびステータス滞留通知の機能をそれぞれ含み、コールアテンプト管理部100は、コールアテンプト管理部56のそれぞれにアクセスする機能をそれぞれ含むことにより、用件が完了するまでのステータスを、たとえばWeb上から管理することができる。

SIPとHTTPプロトコルやSIPとFTPプロトコルに対して共通に扱えるプロトコルにSOAPおよびCORBAのいずれかを用いることにより、異なるシステム環境のシステム間であっても、情報を通信させることができる。

コミュニケーションシステム10は、SIPシステム12とWebシステム14を同一の計算機内に収容することにより、システム構成を小規模にすることができる。また、連携管理部58および96の機能を所定の関数コールに持たせることにより、連携管理部58および96をそれぞれの構成要素として実装せずに済むことから、装置の小型化に寄与する。SIPシステム12とWebシステム14またはSIPシステム12とFTPシステム400との間にネットワークを介在させることにより、各システムを分散して配置することができ、コミュニケーションシステム10の配置に柔軟性を持たせることができる。

SIPシステム12とWebシステム14ならびにSIPシステム12とFTPシステム400とをそれぞれコンピュータで構成し、このコミュニケーションシステム10を機能させるプログラムは、サービス代理UA管理部54、コールアテンプト管理部56および連携管理部58、ならびにサービス代理UA管理部98、コールアテンプト管理部100および連携管理部96として機能させることことにより、システム構成をより一層小型することができ、構成の追加や削減、バージョンアップ等の要求に対しても柔軟に対応することができる。

また、本発明のサービス提供方法によれば、Webシステム14にてコンタクトリストから選択した用件に応じたコールアテンプトおよびステータスに応じてこのステータスを含む起動信号236および238を順に生成し、連携管理処理（第３および第４の工程）を順に実行し、SIPシステム12にて起動信号242を生成し、起動信号242により起動した機能に対応して情報処理し、この情報処理に対する応答情報246を含む起動信号248を生成し、連携管理処理（第１および第２の工程）を経てWebシステム14におけるWebブラウザ50に応答情報246を返すとともに、Webシステム14からSIPシステム12におけるサービス代理UA管理部54の代理ユーザエージェントにアクセスして、用件に関する情報を登録し、登録の完了をWebシステム14に通知した後、Webシステム14からSIPシステム12を起動させて、SIPシステム12におけるSIPクライアント46および48の通信を確立することにより、Web上から用件を実行して、コミュニケーションプロセスマネジメント型APを実現することができ、長時間HTTPのトランザクションを保留しなくて済むことから、リソースの有効利用することができる。

サービス提供方法は、通信終了にともないSIPシステム12からWebシステム14にステータスの変化を供給して、Webシステム14にてコールアテンプトのステータスの設定にアクセスする機能を起動し、連携管理処理（第３および第４の工程）を経てSIPシステム12におけるコールアテンプトのステータスの設定機能を起動し、このステータスを変更後、この変更の応答信号294を連携管理処理（第１および第２の工程）を経てWebシステム14に供給し、変更の応答信号294をWebシステム14のWebブラウザ50に送って、表示することにより、Web上でSIPクライアントのステータス変更を知ることができる。

また、サービス提供方法は、ステータスの変化に応じてSIPシステム12におけるコールアテンプトのステータスの変更通知する機能およびWebシステム14におけるコールアテンプトのステータスの変更通知にアクセスする機能のいずれか一方を起動させて、さらに、この起動に応じて代理UAにおけるプレゼンスの設定機能およびこのプレゼンスの設定機能へのアクセス機能を起動して、SIPシステム12に接続するあらかじめ依頼のあったSIPクライアント46および48にステータスの変更を通知して、ステータスの変更をWebの画面で知ることができる。

さらに、サービス提供方法は、ステータスが所定の時間を経過しても同じ場合、SIPシステムにおけるコールアテンプトのステータスの滞留通知する機能および第２のシステムにおけるコールアテンプトのステータスの滞留通知にアクセスする機能のいずれか一方を起動させて、さらに、この起動に応じて代理UAにおけるプレゼンスの設定機能およびこのプレゼンスの設定機能へのアクセス機能を起動して、SIPシステム12に接続するあらかじめ依頼のあったSIPクライアント46および48にステータスの変更を通知することで、迅速な対応を促すことができる。

コールアテンプトは、SIPシステム12にて接続するクライアントの発呼インスタンスに対する生成、削除、情報編集および情報検索、ならびにステータスの検索、設定、変更通知およびステータスの滞留に応じた滞留の通知を行う機能を用件に応じてそれぞれ、動作させ、Webシステム14にてSIPシステム12が有する機能を用件に応じてそれぞれ、アクセスさせることにより、実際的なアプリケーションとしてのユーザインタフェースを容易に実現することができる。

SIPとHTTPプロトコルやSIPとFTPプロトコルに対して共通に扱えるプロトコルにSOAPおよびCORBAのいずれかを用いることにより、異なるシステム環境のシステム間であっても、情報を通信させることができる。

本発明のサービス提供システムを適用したコミュニケーションシステムにおけるアクセッサコンポーネントの構成例を示すブロック図である。 図１のコミュニケーションシステムにおける概略的な構成例を示すブロック図である。 図２のコミュニケーションシステムにおけるSIP環境の構成例を示す概略的なブロック図である。 図２のコミュニケーションシステムにおけるWeb環境の構成例を示す概略的なブロック図である。 図１に示したコミュニケーションシステムにおけるサービス生成依頼に対する動作手順を説明するシーケンスチャートである。 図５に続く動作シーケンスチャートである。 図１に示したコミュニケーションシステムにおけるプレゼンス設定に対する動作手順を説明するシーケンスチャートである。 図７に続く動作シーケンスチャートである。 図１に示したコミュニケーションシステムにおけるメッセージ送信に対する動作手順を説明するシーケンスチャートである。 図９に続く動作シーケンスチャートである。 図１に示したコミュニケーションシステムにおけるコールアテンプトによるコール確立までの動作手順を説明するシーケンスチャートである。 図11に続く動作シーケンスチャートである。 図１に示したコミュニケーションシステムにおけるコールアテンプトによるステータス設定の動作手順を説明するシーケンスチャートである。 図13に続く動作シーケンスチャートである。 図１に示したコミュニケーションシステムにおけるコールアテンプトによるステータス変更通知の動作手順を説明するシーケンスチャートである。 図15に続く動作シーケンスチャートである。 図15における処理からステータスが滞留した場合、コールアテンプトによるステータス滞留通知の動作手順を説明するシーケンスチャートである。 図２のコミュニケーションシステムにおける他の実施例の概略的な構成を示すブロック図である。 図２のコミュニケーションシステムにおける他の実施例のうち、SIP環境の構成例を示す概略的なブロック図である。 図２のコミュニケーションシステムにおける他の実施例のうち、FTP環境の構成例を示す概略的なブロック図である。 図15の処理に続くFTP環境におけるコールアテンプトによるステータス変更通知の動作手順を説明するシーケンスチャートである。

符号の説明

10 コミュニケーションシステム
12 SIPシステム
14 Webシステム
16 SOAP/CORBAネットワーク
18 SIPクライアント
20 Webクライアント
22 SIPサーバ
24 SIP-DB
26 SIP-APサーバ
32 Webアクセッサコンポーネント
34 Webサーバ
36 Web-DB
38 Web-APサーバ
44 SIPアクセッサコンポーネント
54, 98 サービス代理UA管理部
56, 100 コールアテンプト管理部
58, 96 連携管理部
60, 102 コンポーネントAPI

Claims (14)

1. 異なる通信プロトコルの環境により構築されたシステムに接続するクライアントのそれぞれと情報を通信して、該情報をサービスとして提供するサービス提供システムにおいて、該サービス提供システムは、
   第１の通信プロトコルに基づいて動作する第１のシステムと、
   第２の通信プロトコルに基づいて動作する第２のシステムとを備え、
   第１のシステムは、第２のシステムに送出する情報を第１の通信プロトコルと第２の通信プロトコルにおいて共通に連携させる情報として扱う第３の通信プロトコルに処理し、第２のシステムから供給される第３の通信プロトコルによる情報を第１の通信プロトコルの情報にする第１の連携管理手段と、
   要求されたサービスインスタンスを第１のシステムのクライアントに見立てて、仮想的にユーザエージェントとして管理し、該管理する情報を操作する第１の代理管理手段と、
   第１のシステムに接続するクライアントの一つによる発呼から通話目的を達成するまでのオブジェクトのインスタンスをコールアテンプトとし、該コールアテンプトにおける情報を操作管理する第１のコールアテンプト管理手段とを含み、
   第２のシステムは、第１のシステムに送出する情報を第３の通信プロトコルに処理し、第１のシステムから供給される第３の通信プロトコルによる情報を第２の通信プロトコルの情報にする第２の連携管理手段と、
   前記要求されたサービスインスタンスに対して第２のシステムから第１の代理管理手段の対応した機能に仮想的なユーザエージェントによりアクセスし、前記サービスインスタンスの実行結果を取得する第２の代理管理手段と、
   第２のシステムから第１のコールアテンプト管理手段の対応した機能にアクセスする第２のコールアテンプト管理手段とを含むことを特徴とするサービス提供システム。
2. 請求項１に記載のサービス提供システムにおいて、第１のコールアテンプト管理手段は、前記発呼のインスタンスに対応するコールアテンプトの生成、削除、情報編集および情報検索、ならびに目的の達成状況を表すステータスの検索、設定、変更通知および所定時間以上にわたる前記ステータスの滞留に応じて滞留を通知する機能をそれぞれ含み、
   第２のコールアテンプト管理手段は、第１のコールアテンプト管理手段のそれぞれにアクセスする機能をそれぞれ含むことを特徴とするサービス提供システム。
3. 請求項１または２に記載のサービス提供システムにおいて、第１の通信プロトコルはセッション開始プロトコルであり、第２の通信プロトコルはハイパテキスト転送プロトコルであり、第３の通信プロトコルは第１および第２の通信プロトコルでともに扱えるSOAPおよびCORBAのいずれかの通信プロトコルを用いることを特徴とするサービス提供システム。
4. 請求項１または２に記載のサービス提供システムにおいて、第１の通信プロトコルはセッション開始プロトコルであり、第２の通信プロトコルはファイル転送プロトコルであり、第３の通信プロトコルは第１および第２の通信プロトコルでともに扱えるSOAPおよびCORBAのいずれかの通信プロトコルを用いることを特徴とするサービス提供システム。
5. 請求項１ないし４のいずれか一項に記載のサービス提供システムにおいて、該サービスシステムは、第１のシステムおよび第２のシステムが同一の計算機内に収容されていることを特徴とするサービス提供システム。
6. 請求項５に記載のサービス提供システムにおいて、該サービス提供システムは、第１の連携管理手段および第２の連携管理手段の機能を所定の関数コールに持たせることを特徴とするサービス提供システム。
7. 請求項１ないし４のいずれか一項に記載のサービス提供システムにおいて、該サービス提供システムは、第１のシステムと第２のシステムとの間にネットワークが介在することを特徴とするサービス提供システム。
8. 請求項１ないし６のいずれか一項に記載のサービス提供システムを機能させるプログラムにおいて、第１のシステムおよび第２のシステムのそれぞれはコンピュータであり、該プログラムは、第１のシステムにおける第１の代理管理手段、第１のコールアテンプト管理手段および第１の連携管理手段、ならびに第２のシステムにおける第２の代理管理手段、第２のコールアテンプト管理手段および第２の連携管理手段として機能させることを特徴とするプログラム。
9. 異なる通信プロトコルの環境により構築されたシステムに接続するクライアントのそれぞれと情報を通信して、該情報をサービスとして提供するサービス提供方法において、該方法は、
   第１の通信プロトコルに応じて動作する第１のシステムと第２の通信プロトコルに応じて動作する第２のシステムとの間の通信のうち、第１のシステムから送出する情報を第１の通信プロトコルと第２の通信プロトコルにおいて共通に連携させる情報として扱う第３の通信プロトコルに処理して、送出する第１の工程と、
   第２のシステムに供給される第３の通信プロトコルの情報を第２の通信プロトコルの情報に処理して、送出する第２の工程と、
   第２のシステムから送出する第２の通信プロトコルの情報を第３の通信プロトコルの情報に処理して、送出する第３の工程と、
   第１のシステムに供給される第３の通信プロトコルの情報を第１の通信プロトコルの情報に処理して、送出する第４の工程とを含み、
   第１のシステムに接続するクライアントの一つによる発呼から通話目的を達成するまでのオブジェクトのインスタンスをコールアテンプトとし、第２のシステムのクライアントから通信候補を用件とするコンタクトリストから選択し、該選択した用件に応じた前記コールアテンプトおよび目的の達成状況を表すステータスに応じて該ステータスを含む第２のシステムから第１のシステムの対応する機能へのアクセスを起動する第１の起動信号を生成する第５の工程と、
   第１の起動信号にともない第３の工程を起動する第２の起動信号を生成する第６の工程と、
   第３および第４の工程を順に実行する第７の工程と、
   第１のシステムにおける対応した機能を起動する第３の起動信号を生成する第８の工程と、
   第３の起動信号により起動した機能に対応した情報処理を行う第９の工程と、
   該情報処理に対する応答情報を受けて、該応答情報を含む第１の工程を起動する第４の起動信号を生成する第10の工程と、
   第１よび第２の工程を順に実行する第11の工程と、
   第２の起動信号を生成した生成先に前記応答情報を返す第12の工程と、
   第１の起動信号を生成した生成先に前記応答情報を返す第13の工程と、
   前記応答信号を加工して、第２のシステムのクライアントに供給し、前記選択した用件に対して仮想的にユーザエージェントとして代理する代理ユーザエージェントに第３および第４の工程を経てアクセスして、前記用件に関する情報を登録し、該登録に対する応答を第１および第２の工程により受ける第14の工程と、
   該登録に対する応答に応じて第２のシステムから第３および第４の工程を経て第１のシステムを起動させて、第１のシステムにおけるクライアント同士の通信を確立する第15の工程とを含むことを特徴とするサービス提供方法。
10. 請求項９に記載の方法において、該方法は、通信終了にともない第１のシステムから第２のシステムに前記ステータスの変化を供給して、第２のシステムにて前記コールアテンプトの前記ステータスの設定にアクセスする機能を起動し、第３および第４の工程を経て第１のシステムにおける前記コールアテンプトの前記ステータスの設定機能を起動し、該ステータスを変更後、該変更の応答信号を第１および第２の工程を経て第２のシステムに供給し、前記変更の応答信号を第２のシステムのクライアントに送って、表示することを特徴とするサービス提供システム。
11. 請求項９に記載の方法において、該方法は、前記ステータスの変化に応じて第１のシステムにおける前記コールアテンプトの前記ステータスの変更通知する機能および第２のシステムにおける前記コールアテンプトの前記ステータスの変更通知にアクセスする機能のいずれか一方を起動させて、
    さらに、該起動に応じて前記代理ユーザエージェントにおけるプレゼンスの設定機能および該プレゼンスの設定機能へのアクセス機能のいずれかを起動して、第１のシステムに接続するあらかじめ依頼のあったクライアントに前記ステータスの変更を通知することを特徴とするサービス提供方法。
12. 請求項９に記載の方法において、該方法は、前記ステータスが所定の時間を経過しても同じ場合、第１のシステムにおける前記コールアテンプトの前記ステータスの滞留通知する機能および第２のシステムにおける前記コールアテンプトの前記ステータスの滞留通知にアクセスする機能のいずれか一方を起動させて、
    さらに、該起動に応じて前記代理ユーザエージェントにおけるプレゼンスの設定機能および該プレゼンスの設定機能へのアクセス機能のいずれかを起動して、第１のシステムに接続するあらかじめ依頼のあったクライアントに前記ステータスの変更を通知することを特徴とするサービス提供方法。
13. 請求項９ないし12のいずれか一項に記載の方法において、前記コールアテンプトは、第１のシステムにて接続するクライアントの発呼インスタンスに対する生成、削除、情報編集および情報検索、ならびに前記ステータスの検索、設定、変更通知および前記ステータスの滞留に応じた滞留の通知を行う機能を前記用件に応じてそれぞれ、動作させ、
    第２のシステムにて第１のシステムが有する機能を前記用件に応じてそれぞれ、アクセスさせることを特徴とするサービス提供方法。
14. 請求項９ないし13に記載の方法において、第１の通信プロトコルはセッション開始プロトコルであり、第２の通信プロトコルはハイパテキスト転送プロトコルおよびファイル転送プロトコルのいずれか一方であり、第３の通信プロトコルは第１および第２の通信プロトコルでともに扱えるSOAPおよびCORBAのいずれかの通信プロトコルを用いることを特徴とするサービス提供方法。

Images