(57)【要約】【課題】ユーザ毎の属性を考慮し最適な発着信ユーザ（接続先）を動的に決定することができる接続先決定方法を提供する。【解決手段】識別情報（SIP URI）を含む複数の属性情報からなる接続先情報を記憶するリポジトリ５１と、接続先を決定する際の契機となる事象を複数の属性情報で定義するドメインオブジェクト５２と、接続先情報と事象情報の属性間の関係を定義するポリシー５３とを用い、入力情報（x=router14）に相当する事象情報をドメインオブジェクト５２から抽出し（Ｓ２０１）、クエリ検索式５４を用いて、リポジトリ５１、ポリシー５３及び抽出された事象情報を検索し（Ｓ２０２）、検索結果からポリシー５３を参照して接続先を特定して出力する（Ｓ２０３〜２０４）。【選択図】図３
2009205265.tif 000002
【特許請求の範囲】
【請求項１】
接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、
接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、
前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段と
を用い、
接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力過程と、
前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力過程で抽出された事象情報を検索する検索過程と、
前記検索過程の検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力過程と
を有していることを特徴とする接続先決定方法。
【請求項２】
前記定義情報に、前記接続先情報と前記事象情報の属性間の関係を前記接続先情報と前記事象情報の抽象型の論理関係によって定義したものが含まれている
ことを特徴とする請求項１に記載の接続先決定方法。
【請求項３】
前記検索式が、前記定義情報記憶手段が記憶する接続先情報の出力内容を定義する定義情報に含まれる要素を含んで構成されている
ことを特徴とする請求項１又は２に記載の接続先決定方法。
【請求項４】
接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、
接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、
前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段と、
接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力手段と、
前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力手段によって抽出された事象情報を検索する検索手段と、
前記検索手段による検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力手段と
を具備することを特徴とする接続先決定装置。
【請求項５】
前記定義情報に、前記接続先情報と前記事象情報の属性間の関係を前記接続先情報と前記事象情報の抽象型の論理関係によって定義したものが含まれている
ことを特徴とする請求項４に記載の接続先決定装置。
【請求項６】
前記検索式が、前記定義情報記憶手段が記憶する接続先情報の出力内容を定義する定義情報に含まれる要素を含んで構成されている
ことを特徴とする請求項４又は５に記載の接続先決定装置。
【請求項７】
接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、
接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、
前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段と、
を備える接続先決定装置のコンピュータを、
接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力手段、
前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力手段によって抽出された事象情報を検索する検索手段、
前記検索手段による検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、たとえばネットワーク上に分散したサービスを構成する要素サービスを連携させてサービスを実行するシステムにおいて連携シナリオを生成する技術を用い、ある事象が発生した場合にこの事象に対応する接続先を動的に決定する際に用いて好適な接続先決定方法及び装置に関する。
【背景技術】
【０００２】
近年、SOA（サービス指向アーキテクチャ）の実現技術の１つとして、サービス連携技術が注目を浴びている。サービスはWSDL（Web Services Description Languageが定めた技術仕様）仕様に基づくWeb（ウェブ）サービスインタフェースやUPnP（Universal Plug and Play）仕様に基づくサービスインタフェースを定義し、SOAP（Simple Object Access Protocol；国際標準化団体W3Cが定めた技術仕様）などによりメッセージ送受を行う機能を提供する。これらインタフェース定義されたサービスを順次若しくは並列的に実行するワークフロー即ち連携シナリオは、シナリオ実行エンジンによって実行される。連携シナリオにおいて参照・呼び出される、前記インタフェース定義されたサービスを本発明ではサービスコンポーネントと呼ぶこととする。
【０００３】
一般にWebサービスを用いた複雑なワークフローを記述するワークフロー記述言語としてはBPEL（Business Process Execution Language）などが用いられる。BPEL記述に基づき、ワークフローを実行するシナリオ実行エンジンはBPELエンジンと呼ばれる。BPELシステムのほかには、シナリオ実行エンジンと要素サービスとの間でインタフェース整合がとれない場合に仲介サービスを発見しこれを含めてサービスを合成する機能を有するシステム（特許文献１）、サービスが提供される同一領域の同等機能を持つ他のサービス要素への動的適応を可能とするシステム（特許文献２）などが存在する。
【０００４】
サービスコンポーネントは、インターネット上のサービスだけでなく、テレコムネットワークのサービスにおいても存在する。テレコムネットワークサービスをサービスコンポーネント化する仕様として、Parley X（Parlay X Web Services Specification, Version 3.0,http://www.parlay.org/en/specifications/pxws.asp）がある。Parley XにおけるThird Party Call Control（3PCC）API（Application Programming Interface）は、SIP UA（Session Initiation Protocol User Agent；発信元や着信先などのcallParticipant(s)）のURI（Uniform Resource Identifier）を表す入力パラメータを持つ。ここでcallParticipant(s)は、3PCC APIで定義されている接続先（通話参加者）を表すpublic  interface（全クラスからアクセスできるインタフェース）のことである。
【０００５】
3PCC APIを応用したサービス例としては、例えばサーバに故障が発生したとき、管理者と保守者担当者との間をConference Call（会議通話）で接続する、といったシナリオが考えられる。この場合、現場の故障設備に詳しい保守担当者の決定を自動化することで、保守費軽減が期待される。このようなシーンでは、発着信ユーザを動的に決定するシステムが必要である。
【０００６】
関連する、従来の発着信者決定方法としては、接続元端末からダイヤル等により指定するもので、接続先端末は発信側により一意に特定されるので、通信網は指定された接続先端末への接続を行うのが最も一般的である。また、より高度な方法としては、フリーダイヤルサービス等において、接続先特定ノード内の登録されている接続先端末から予め定められた手続きに従って選択する方法がある。これにより、接続先端末の状態（使用中等）や接続元端末の発信地域情報（輻輳状態でなかなか発信できない等）によって接続先を変更することができ、実際に接続先を選択することが図られている。また、特許文献３によれば、発信者である接続元端末毎の端末識別番号をカスタマコンピュータに登録する。そして、発信時に、発信者氏名、住所、担当者を含む接続元情報と空塞情報と住所と担当者を含む接続先端末情報を管理するカスタマコンピュータは、端末識別番号をキーとしてカスタマ情報を検索して接続相手先端末を決定する。しかし、特許文献３に記載の方法は、接続元の端末識別番号を決定するために、通信網に接続された端末から、予め定められた接続先番号で接続先を指定して発信を行った場合における着信ユーザの決定方法のみを述べており、そもそも発信者を自動的に決定することはできず、また想定もされていない。
【０００７】
また、市販のPredictive Dialingシステムは、アウトバウンド業務（あるシステムやネットワークから外部に情報を送信する業務のこと）において予め用意された顧客情報ファイル（コールリスト）から、平均応答率、アウトバウンドを扱うエージェントの平均通話時間、フォローアップ操作時間などのパラメータに基づく予測（プレディクティブ）アルゴリズムで、エージェントの応答可能確率を計算の上、システムが自動発信し相手が応答した場合のみエージェントへ接続するダイヤル方式である。ただし、Predictive Dialingシステムで用いられる単なる電話番号リストでは、人に関する属性情報が含まれておらず、動的に発着信者を決定するには不十分である。
【特許文献１】特開２００５−７１０５２号公報
【特許文献２】特開２００５−２５０８４４号公報
【特許文献３】特許３２３９２２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上述した背景に鑑みてなされたものであり、ユーザ毎の属性（例えば設備の詳しさ等）を考慮し最適な発着信ユーザすなわち接続先を動的に決定することができ、また、上記サーバ管理の例に限らず様々な用途（ドメイン）で用いることができるように、汎用的で再利用性の高いシステム構成を構築できるようにする接続先決定方法及び装置並びにそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明は、接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段とを用い、接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力過程と、前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力過程で抽出された事象情報を検索する検索過程と、前記検索過程の検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力過程とを有していることを特徴とする。
【００１０】
また本発明は、前記定義情報に、前記接続先情報と前記事象情報の属性間の関係を前記接続先情報と前記事象情報の抽象型の論理関係によって定義したものが含まれていることを特徴とする。
【００１１】
また本発明は、前記検索式が、前記定義情報記憶手段が記憶する接続先情報の出力内容を定義する定義情報に含まれる要素を含んで構成されていることを特徴とする。
【００１２】
また本発明は、接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段と、接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力手段と、前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力手段によって抽出された事象情報を検索する検索手段と、前記検索手段による検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力手段とを具備することを特徴とする。
【００１３】
また本発明は、前記定義情報に、前記接続先情報と前記事象情報の属性間の関係を前記接続先情報と前記事象情報の抽象型の論理関係によって定義したものが含まれていることを特徴とする。
また本発明は、前記検索式が、前記定義情報記憶手段が記憶する接続先情報の出力内容を定義する定義情報に含まれる要素を含んで構成されていることを特徴とする。
【００１４】
また本発明は、接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段と、接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段と、前記接続先情報と前記事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段と、を備える接続先決定装置のコンピュータを、接続先を決定する際の契機となる事象を示す入力情報を入力するとともに、該入力情報に相当する事象情報を前記事象情報記憶手段から抽出する入力手段、前記入力情報に対応する情報を含む検索式を用いて、前記接続先情報、前記定義情報及び前記入力手段によって抽出された事象情報を検索する検索手段、前記検索手段による検索結果から、前記定義情報記憶手段に記憶されている定義情報を参照して接続先を特定して出力する出力手段として機能させることを特徴とするプログラムである。
【発明の効果】
【００１５】
本発明によれば、接続先を決定する際の契機となる事象を示す入力情報を入力し、その入力情報に相当する事象情報と、接続先の識別情報を含む複数の接続先に関する属性情報からなる接続先情報と、接続先情報と事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報とに対して、その入力情報に対応する情報を含む検索式を用いた検索を行い、その検索結果から定義情報を参照して接続先を特定することで、特定された接続先の識別情報が所定の形式に合わせて出力される。したがって、本発明を用いることによって、接続先を決定する際の契機となる事象（ドメインあるいはイベント）に応じて発着信者を決定することができる。また、本発明は、事象情報（ドメインオブジェクト）と定義情報（ポリシー）と検索式を入れ替えることによって、たとえば通信機器管理や英会話レッスンをはじめ様々な用途（事象；ドメイン）に適用可能であるため、汎用的で再利用性の高い発着信ユーザ決定システムが実現可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明を実施するための最良の実施の形態について図面を参照して説明する。図１は、ネットワーク１０あるいは通信ネットワーク１１あるいは情報ネットワーク１２を介して、ネットワークサービスプラットフォーム１が、サーバ、ルータなどの通信装置を保守監視するサーバ（NWSPFクライアント）７やSIPサーバ８やサービスコンポーネント９と連携するときのネットワーク構成図である。
【００１７】
ネットワークサービスプラットフォーム１は、ネットワーク上に分散したサービスを構成する要素サービス（サービスコンポーネント）を連携させてサービスを実行するシステムにおける基盤となるものであって、サーバなどの１又は複数の端末と、各端末間を接続する通信網、通信回線など通信手段とからなり、端末上で所定のプログラムを実行することで各種サービスを実現する。SIPサーバ８は、ネットワークサービスプラットフォーム１内の通信ネットワーク制御サーバ装置６などと連携し、SIPなどによってIP電話の呼制御などを行うサーバであって、音声電話や、電子メールなどを利用した通信、テレビ電話による通信などの各種通信の接続を制御する。サービスコンポーネント９は、インタフェース定義されたサービスであって、連携シナリオに基づき、ネットワークサービスプラットフォーム１内のサービス合成部３によって順次若しくは並列的に参照・呼び出される。
【００１８】
なお、本実施の形態では、ネットワーク１０には通信装置群１３があり、通信装置群１３の中に例えばルータ１４、サーバ１５などが含まれているとする。保守監視サーバ（NWSPFクライアント）７は、通信装置群１３を保守監視するサーバであり、且つ本実施形態ではネットワークサービスプラットフォーム１にアクセスするクライアントとなる。なお、図１では各構成を１つずつ示しているが、各構成は複数設けることができる。また、通信ネットワーク１１などのネットワークには図示してないSIP UAとなる端末が複数接続されているものとする。
【００１９】
図１において、ネットワーク１０、通信ネットワーク１１、情報ネットワーク１２は、それぞれ任意のネットワーク、通信事業者ネットワーク、インターネット等IP（Internet Protocol）のデータネットワークを想定するのが相応しいが、これに限定するものではない。
【００２０】
また、ネットワークサービスプラットフォーム１内の発着信者決定システム２が、本発明が特徴とする主要な構成である。この実施の形態における発着信者決定システム２は、保守監視サーバ７などのクライアントにおいて所定の事象（たとえば通信装置群１３内の故障あるいは故障発生）が起こった場合に、この事象に対応する接続先として、ユーザ（接続先）毎の属性を考慮して最適な発着信ユーザを動的に決定するシステムである。なお、図１において、発着信者決定システム２は、ネットワークサービスプラットフォーム１の内部に配置されているが、ネットワークサービスプラットフォーム１の外部に配置しても良い。
【００２１】
図１に示す構成例では、ネットワークサービスプラットフォーム１内に、発着信者決定システム２のほか、サービス合成部３、サービスコンポーネントデータベース４、サービスシナリオデータベース５及び通信ネットワーク制御サーバ装置６が設けられている。サービス合成部３は、シナリオ実行エンジンとして機能するものであり、直接あるいは通信ネットワーク制御サーバ装置６を介して、保守監視サーバ７、SIPサーバ８及びサービスコンポーネント９と接続されている。このサービス合成部３と、発信者決定システム２、サービスコンポーネントデータベース４及びサービスシナリオデータベース５が所定の通信手段によって接続されている。
【００２２】
サービスシナリオデータベース５には、図２に示すようなシナリオ２１が１または複数、格納されている。各シナリオ２１には、サービス合成部３が実行する、サービスコンポーネントの呼び出し順序等が記述される。すなわち、図２に示すように、各シナリオ２１には、サービスコンポーネント呼び出し命令２２、発着信番号決定呼び出し命令２３、makeCall（発呼）命令２４などが含まれている。ここで、サービスコンポーネント呼び出し命令２２は、図１のサービスコンポーネント９を呼び出すための命令である。発着信番号決定呼び出し命令２３は、発着信者決定システム２を呼び出すための命令である。そして、makeCall命令２４は、通信ネットワーク制御サーバ装置６に対して呼接続などを指示する命令である。
【００２３】
また、図１のサービスコンポーネントデータベース４には、サービスシナリオデータベース５内のサービスコンポーネント呼び出し命令２２とサービスコンポーネント９の対応、発着信番号決定呼び出し命令２３と発着信者決定システム２の対応、およびmake Ca11命令２４と通信ネットワーク制御サーバ装置６との対応情報が格納されている。
【００２４】
図１のネットワークサービスプラットフォーム１では、図２に示すようなシナリオ２１自身が保守監視サーバ（クライアント）７から呼び出されてスレッドが開始される。そして、サービス合成部３は、はじめにサービスコンポーネント呼び出し命令２２を解釈し、サービスコンポーネント９を実行する。次に、サービス合成部３は、発着信番号決定呼び出し命令２３を解釈し、発着信者決定システム２内の所定の処理を実行する。そして、サービス合成部３は、makeCall命令２４を解釈し、通信ネットワーク制御サーバ装置６内の所定の処理を実行する。
【００２５】
図３に、図１に示した本発明における発着信者決定システム２のシステム構成を示す。発着信者決定システム２は、サーバなどとして構成されていて、そのサーバ内のコンピュータ及びその周辺装置とそのコンピュータで実行されるプログラムとの組み合わせによって実現されている。発着信者決定システム２は、リポジトリ５１、ドメインオブジェクト５２、ポリシー５３及びクリエ検索式５４の各情報を記憶する記憶装置５０と、図１のサービス合成部３から情報を入力する入力処理部６１と、記憶装置５０内の各情報を用いて検索処理を行う検索実行部６２と、検索結果から所定の形式の出力情報（接続先を示す情報）を抽出してサービス合成部３に対して出力する検索結果抽出・出力部６３とを備えている。
【００２６】
リポジトリ５１は、SIP URIなどの接続先の識別情報を含む複数の接続先に関する属性情報を含んで構成される接続先情報を記憶する接続先情報記憶手段として機能するものであり、加入者情報データベースに相当し、１又は複数のユーザ（接続先）の属性（図３のα、β等）を定義する。ユーザの属性の記述形式としては、RDF（Resource Description Framework）を用いることができる。すなわち図４のように、各ユーザを表すユーザ変数（接続先情報）には、ユーザの名前を表すname属性（名前属性）、当該ユーザの管理権限を表すadministrativeLocation属性（管理権限属性）、SIPによる発信元と着信先の識別情報を表すsipuri属性（SIP URI属性）、RDFにおけるrdf:typeプロパティなどが定義されている。定義語rdf:typeは、リソース（この場合はユーザ変数）がどのクラスのメンバ（インスタンス）であるかを示すプロパティである。リポジトリ５１にはたとえば、ユーザ「Alice」（＝name属性）のadministrativeLocation属性の値として「5thfloor」（５階）が、sipuri属性として「sip:alice@company.com」が記述されるとともに、ユーザ「Bob」はNetworkSpecialistクラス（ネットワークスペシャリストクラス）に属し（rdf:typeを用いて記述）、またそのsipuri属性として「sip:bob@company.com」が記述されている。発信元と着信先の識別情報としては、SIP URIのほか、電話番号、電子メールアドレス、所定の端末のIPアドレスなどを用いることができる。
【００２７】
ドメインオブジェクト５２は、接続先を決定する際の契機となる事象を１又は複数の属性情報で定義する事象情報を記憶する事象情報記憶手段として機能するものであり、発着信先を決定するための判断材料となる対象物（事象）を定義する。該定義の記述形式としてはRDFを用いることができる。本実施形態では通信装置故障がドメイン（変域あるいは定義域）すなわち接続先を決定する際の契機となる事象であるとする。この場合、図４のように、ドメインオブジェクト５２には、対象物（対象事象）である通信装置すなわちルータ１４及びサーバ１５に関する属性などの情報（オブジェクト情報）を記述する。ここでは、ルータ１４のクラスが「Router」であり、その個体を識別するための情報であるID（識別符号）属性の値として「router14」、vendor属性（製品販売会社の属性）の値として「ntt」、location属性（位置属性）の値として「5thfloor」と記述する。また、サーバ１５の情報として、クラスが「Server」であることのほか、各属性の値「server15」、「A-Company」、「7thfloor」も同様に記述する。
【００２８】
ポリシー５３は、接続先情報と事象情報の属性間の関係を定義するとともに接続先情報の出力内容を定義する定義情報を記憶する定義情報記憶手段として機能するものであり、ドメインオブジェクト５２とリポジトリ５１の属性の間の関係が満たすべき条件式と、発着信者決定システム２からの接続先情報の出力内容示す条件式とを定義する。また必要に応じて、語彙（オントロジ）も同時に記述することができる。条件式定義の記述形式としては、SWRL（I. Horrocks et al., "SWRL: A Semantic Web Rule Language Combining OWL and RuleML," W3C Document, 2004. 5., http://www.w3.org/Submission/SWRL/）を用いることができ、語彙としてはOWL（Web Ontology Language, http://www.w3.org/TR/owl-features/）を用いることができる。また、本実施の形態においてポリシー５３が記憶する定義情報には、接続先情報と事象情報の属性間の関係を接続先情報と事象情報の抽象型（クラス）の論理関係によって定義した条件式が含まれている。本実施形態では、条件式（ポリシー）をたとえば、
【００２９】
【数１】
2009205265.tif 000003
【００３０】
【数２】
2009205265.tif 000004
【００３１】
のように記述する。（１）式は、接続先情報と事象情報の属性間の関係を定義するものであって、ネットワークスペシャリストクラス（NetworkSpecialist）とルータクラス（Router）の積集合が維持作業可能クラス（Maintainable）を包含することを示している。（２）式は、
発着信者決定システム２からの接続先情報の出力内容を示すものであって、接続先クラス（callParticipants）が発信者クラス（Sender）と受信者クラス（Receiver）の和集合を包含することを示している。
【００３２】
検索式５４は、リポジトリ５１及びドメインオブジェクト５２及びポリシー５３に対するクエリ検索式である。クエリ検索式とは、検索対象となる各情報を管理するデータベースに対する問い合わせ処理の要求を、キーワードとキーワード間の関係を表す論理演算子などの文字列を含んで表したものである。また、本実施形態の検索式５４には、接続先を決定する際の契機となる事象を表すものとして発着信者決定システム２へ入力される情報に対応する情報を含んでいる。クエリ検索式にはSPARQL（SPARQL Protocol and RDF Query Language）を用いることができる。本実施形態では、クエリ検索式としてたとえば、
【００３３】
【数３】
2009205265.tif 000005
【００３４】
および
【００３５】
【数４】
2009205265.tif 000006
と記述する。（３）式を図示したグラフを図６に示す。
【００３６】
すなわち、（３）式は、「SELECT」の次に記述された変数sender（「？」は変数を表す符号）が「WHERE」以下の文字列で示される条件に従って選択されることを示すものである。また、（３）式では、「WHERE」以下の記述に、接続先を決定する際の契機となる事象を表す情報に対応するルータ１４の情報「rouetr14」が含まれている。具体的には（３）式は、ルータ１４の位置（location）における管理権限（administrativeLocation)を持つユーザを発信者（sender）として選ぶことを意味する。また（４）式は、ルータ１４の維持作業が可能（maintainable）であるユーザを着信者（receiver）として選ぶことを意味する。
【００３７】
以下に、図２に示すシナリオ２１と図３のシステム図および図７に示すシーケンスをもとに本実施の形態における手順を説明する。保守監視サーバ（NWSPFクライアント)７は、通信装置群１３に属する通信装置（通信機器）の状態を常に監視しており、ルータ１４に異常が発生したことを検知すると、SOAP（Simple Object Access Protocol）を用いてサービス合成部３にアクセスし、シナリオ２１を実行させる。このSOAPメッセージには、接続先を決定する際の契機となる事象を表す情報である故障したルータ１４のIDすなわち通信装置の個体を識別するための情報を示す「<id>router14</id>」というXML（Extensible Markup Language）タグが含まれている。
【００３８】
サービス合成部３は、シナリオ２１に従い、サービスコンポーネント９を実行する。サービスコンポーネント９は任意のサービスで良い。例えばサービスコンポーネント９が地図サービスであれば、「<id>router14</id>」を入力として受け取り、ID「router14」で識別されるルータ１４の地図上での位置をたとえば保守監視サーバ（NWSPFクライアント)７の画面上に表示する。
【００３９】
次に、サービス合成部３は、シナリオ２１に従い、発着信者決定システム２を実行する。このとき、パラメータとして、「<id>router14</id>」が発着信者決定システム２に受け渡される（以上が図７のＳ１０１に対応する）。
【００４０】
発着信者決定システム２は、「<id>router14</id>」を入力として受け取ると、入力処理部６１において、ドメインオブジェクト５２の中から、「<id>router14<1id>」に相当するオブジェクトインスタンスをXQuery（W3Cで標準化されたXMLデータベースの問い合わせ言語）により検索・抽出する。すなわち、入力処理部６１は、接続先を決定する際の契機となる事象を示す入力情報（この場合「<id>router14</id>」）を入力するとともに、その入力情報に相当する事象情報をドメインオブジェクト５２（事象情報記憶手段）から抽出する入力手段として機能するものである。この場合。入力処理部６１は、検査対象オブジェクトのインスタンスrouter14を入力して、このインスタンスrouter14のクラスRouterのオブジェクトを作成する。XQuery式は以下の通りである。
【００４１】
【数５】
2009205265.tif 000007
【００４２】
このようにして、ルータ１４に関するオブジェクトインスタンス（この場合は、「ntt」、「router14」、「5thfloor」である）を得る（以上が図３および図７のＳ２０１に対応する）。
【００４３】
次に、検索実行部６２は、クエリ検索式５４を用いて、接続先情報（リポジトリ５１の記憶情報）、定義情報（ポリシー５３の記憶情報）及び入力処理部６１で抽出された事象情報（オブジェクト）を検索する検索手段として機能するものである。この場合、検索実行部６２は、発着信者決定システム２の出力である接続先変数callParticipantsを得るために次のような検索処理を行う。上述したクエリ検索式（３）（４）には変数callParticipantsが含まれていない。従って、推論を行ってcallParticipantsを、（３）（４）式に現れる変数に置き換えなければならない。ここでの推論において、検索実行部６２は、ポリシー５３に定義されたポリシー（２）式を参照し、callParticipantsがSenderとReceiverの和集合から成ることから、SenderとReceiverについてそれぞれクエリ検索を行うことを判断する。そして、実際に（３）（４）式にSenderとReceiverが変数として現れることを確認し、リポジトリ５１及びポリシー５３並びに、先にXqueryによって抽出されたルータ１４に関するオブジェクトインスタンスに対して、検索式（３）と（４）によるSPARQL検索を行う。（３）式のSPARQL検索の結果として
【００４４】
【数６】
2009205265.tif 000008
【００４５】
が得られる。すなわち、発信者senderとして、ルータ１４の位置（location）における管理権限（administrative Location）を持つ「Alice」が選ばれる。
【００４６】
同様に、（４）式のSPARQL検索においてポリシー（１）式を適用し、検索結果として
【００４７】
【数７】
2009205265.tif 000009
【００４８】
が得られる。すなわちreceiverとして、ルータ１４の維持作業が可能（maintainable）であるユーザ「Bob」が選ばれる（以上Ｓ２０２）。
【００４９】
次に、検索結果抽出・出力部６３は、検索実行部６２による検索結果から、ポリシー５３（定義情報記憶手段）に記憶されている定義情報を参照して接続先を特定して出力する出力手段として機能するものである。この場合、検索結果抽出・出力部６３は、検索実行結果（５）（６）から、ポリシー５３に適合するユーザ集合を抽出することで、次のように変数callParticipantsを決定する。なお、この検索結果抽出・出力部６３は、シナリオ２１においてmakeCall命令２４（つまり3PCC API実行）の直前に呼出され、発着信ユーザを決定しそのSIP URIを出力するものとして機能するものである。
【００５０】
検索実行部６２によるクエリ検索結果の式（５）（６）には変数callParticipantsの値が含まれていない。従って、検索結果抽出・出力部６３は、推論を行ってcallParticipantsを、（５）（６）式に現れる変数に置き換えなければならない。故に検索結果抽出・出力部６３は、ポリシー（２）を参照し、callParticipantsがSenderとReceiverの和集合から成ることから、（５）（６）からSenderとReceiverの値を特定し、それぞれのSIP URIを抽出する。Senderの場合、以下のXquery式：
【００５１】
【数８】
2009205265.tif 000010
【００５２】
により、「Alice」のSIP URI「<sipuri>sip:alice@company.com</sipuri>」が得られる。同様に、Receiverの場合、以下のXquery式：
【００５３】
【数９】
2009205265.tif 000011
【００５４】
により、「Bob」のSIP URI「<sipuri>sip:bob@company.com(</sipuri>」が得られる（以上Ｓ２０３）。
【００５５】
検索結果抽出・出力部６３は、SIP URIを配列形式すなわち「<xs:element name =“Output” type =“xsd:any URI”maxOccurs =“unbounded”/>」に従うよう、
【００５６】
【数１０】
2009205265.tif 000012
【００５７】
を出力する（以上Ｓ２０４）。
【００５８】
次に、サービス合成部３は、シナリオ２１に従い、発着信者決定システム２の検索結果抽出・出力部６３が出力した結果を、makeCall命令２４に入力することにより、２つのSIP URIの値を、通信ネットワーク制御サーバ装置６に3PCC APIのメッセージパラメータとして受け渡す。通信ネットワーク制御サーバ装置６は、Parlay X（Web Service Specification, http://wwwparlay.org/）のAPIに相当する機能を提供しており、２個以上の個数のSIP URIを入力として受け取ると、これらSIP URIの間を呼接続するよう、SIPサーバ８を制御する。即ち、通信ネットワーク制御サーバ装置６は、「sip:alice@cempany.com」および「sip:bob@cornpany.com」の間で呼接続する（以上Ｓ１０２）。
【００５９】
なお、以上の実施形態の手順では、発着信者決定システム２は発着信者を決定する。しかし、発着信者決定システム２は上記のように２つのSIP URIを出力するだけでなく、３個以上のSIP URIを検索することも可能である。このようなケースは、リポジトリに３名以上のユーザの情報が格納されており、（３）式や（４）式のSPARQL検索結果が複数のユーザを含む場合に生ずる。
【００６０】
また、以上の実施形態では、ドメインオブジェクト５２に故障通信装置（故障監視機器）、SPARQL検索式５４とポリシー５３に発着信者検索・決定条件を記すことによって、故障機器に詳しい管理者・担当者を抽出するサービスに適用したが、これらを入れ替えることによって他のサービスに適用することも容易に可能である。例えば、ドメインオブジェクト５２に英会話レッスンのメニュー、SPARQL検索式５４とポリシー５３には英会話講師と受講者を検索・決定する条件を記すことによって、受講者の能力に応じた英会話レッスンと英会話講師を決定するようなサービスにも応用できる。
【００６１】
本発明を用いることによって、ドメインに応じて発着信者を決定することができる。本発明は、ドメインオブジェクトとポリシーと検索式を入れ替えることによって、上記通信機器管理や英会話レッスンをはじめ様々な用途（ドメイン）に適用可能であるため、汎用的で再利用性の高い発着信ユーザ決定システムが実現可能となる。
【００６２】
なお、本発明の実施の形態は上記のものに限られず、各構成要素や各情報（データ・ファイル）を統合したり、分割したり、さらに分散して配置してそれらの間を通信手段で接続するようにしたりする変更を適宜行うことが可能である。また、本実施形態は、その構成の一部又は全部をコンピュータとコンピュータで実行されるプログラムとを用いて構成することができ、そのプログラムの一部又は全部はコンピュータ読み取り可能な記録媒体又は通信手段を介して配布することが可能である。
【図面の簡単な説明】
【００６３】
【図１】本発明を実施するための最良の実施の形態におけるネットワーク構成図。
【図２】図１の実施の形態における連携シナリオ例を示す図。
【図３】図１の発着信者決定システム２のシステム構成図。
【図４】図３のリポジトリ５１の記述内容を説明するための図。
【図５】図３のドメインオブジェクト５２の記述内容を説明するための図。
【図６】図３のクエリ検索式５４の記述内容を説明するための図。
【図７】図１の実施の形態におけるフローチャート。
【符号の説明】
【００６４】
１  ネットワークサービスプラットフォーム
２  発着信者決定システム
３  サービス合成部
４  サービスコンポーネントデータベース
５    サービスシナリオデータベース
６  通信ネットワーク制御サーバ装置
７  保守監視サーバ（NWSPFクライアント）
８  SIPサーバ
９  サービスコンポーネント
１０  ネットワーク
１１  通信ネットワーク
１２  情報ネットワーク
１３  通信機器群
１４  ルータ
１５  サーバ
２１  シナリオ
２２〜２４  シナリオにおける命令
５０  記憶装置
５１  リポジトリ
５２  ドメインオブジェクト
５３  ポリシー
５４  クエリ検索式
６１  入力処理部
６２  検索実行部
６３  検索結果抽出・出力部
Ｓ１０１〜２０４  処理ステップ番号
【図１】
2009205265.tif 000013
【図２】
2009205265.tif 000014
【図３】
2009205265.tif 000015
【図４】
2009205265.tif 000016
【図５】
2009205265.tif 000017
【図６】
2009205265.tif 000018
【図７】
2009205265.tif 000019