(57)【要約】【課題】互いに異なる通信仕様を有するセッション制御サーバとＴＴＳサーバ間の連携を取る処理を、コストを抑制して実現する。【解決手段】セッション制御サーバ（サーバ）１４が電話機１１の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをＡＰＬ１５ａとして保有するＡＰＬサーバ（サーバ）１５から取得する際に、連携装置４０が呼制御シナリオの内容を読み取る。連携装置４０は、読取内容からサーバ１４とＴＴＳサーバ（サーバ）１７との接続が必要と認識すると、サーバ１５からの音声データ取得のリクエストを含む情報を、各サーバ１４，１５，１７間で相互に通信可能な通信仕様に変換する。変換後のリクエストはテキストデータと共にサーバ１７へ送信され、サーバ１７でテキストデータが変換された音声データが、サーバ１４により受信側の電話機１２へ送信される構成とする。【選択図】図１
2017163434.tif 000002
【特許請求の範囲】
【請求項１】
電話機間の呼制御を行う第１サーバであるＡＰＩ提供サーバと、外部から入力されるテキストデータを音声データに変換する第２サーバであるＡＰＩ提供サーバとが異なる通信仕様を有する際に、各ＡＰＩ提供サーバ間の連携を行うＡＰＩ提供サーバの連携装置であって、
前記第１サーバが電話機の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをアプリケーションとして保有する第３サーバから取得する際に、当該呼制御シナリオの内容を読み取り、前記第１サーバと前記第２サーバとの接続の必要性を判定する読込部と、
前記接続が必要と判定された際に、前記第３サーバからの音声データ取得のリクエストを含む情報を、前記第１サーバ、前記第２サーバ及び当該第３サーバの間で相互に通信可能な通信仕様となるように変換する変換部と、
前記変換されたリクエストを前記呼制御シナリオ中のテキストデータと共に前記第２サーバへ送信し、この送信に応じて当該第２サーバで前記テキストデータが変換された音声データを受信して保存する送受信部とを備え、
前記保存された前記音声データは、前記第１サーバにより前記呼制御シナリオに基づき取得後、受信側の電話機へ送信される
ことを特徴とするＡＰＩ提供サーバの連携装置。
【請求項２】
前記第１サーバ、前記第２サーバ及び前記第３サーバの各々異なる通信仕様を統一化するルールを記載したルール情報を外部から取得して記憶する記憶部を更に備え、
前記変換部は、前記記憶部に記憶されたルール情報のルールに従い、前記第１〜第３サーバ間で相互に信号を送受信するための通信仕様を統一化する変換処理を行う
ことを特徴とする請求項１に記載のＡＰＩ提供サーバの連携装置。
【請求項３】
電話機間の呼制御を行う第１サーバであるＡＰＩ提供サーバと、外部から入力されるテキストデータを音声データに変換する第２サーバであるＡＰＩ提供サーバとが異なる通信仕様を有する際に、各ＡＰＩ提供サーバ間の連携を行う連携装置によるＡＰＩ提供サーバの連携方法であって、
前記連携装置は、
前記第１サーバが電話機の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをアプリケーションとして保有する第３サーバから取得する際に、当該呼制御シナリオの内容を読み取り、前記第１サーバと前記第２サーバとの接続の必要性を判定するステップと、
前記接続が必要と判定された際に、前記第３サーバからの音声データ取得のリクエストを含む情報を、前記第１サーバ、前記第２サーバ及び当該第３サーバの間で相互に通信可能な通信仕様となるように変換するステップと、
前記変換されたリクエストを前記呼制御シナリオ中のテキストデータと共に前記第２サーバへ送信し、この送信に応じて当該第２サーバで前記テキストデータが変換された音声データを受信して保存するステップと、
前記保存された前記音声データが、前記第１サーバにより前記呼制御シナリオに基づき取得後、受信側の電話機へ送信されるステップと
を実行することを特徴とするＡＰＩ提供サーバの連携方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、互いに異なる通信仕様を有するＡＰＩ提供サーバとしてのセッション制御サーバとＴＴＳ(Text To Speech)サーバ間の連携を行うＡＰＩ提供サーバの連携装置及びＡＰＩ提供サーバの連携方法に関する。
【背景技術】
【０００２】
ＶｏＩＰ(Voice over Internet Protocol)技術を用いたＩＰ電話システムでは、通話者の電話機間のセッション確立や変更等を行うための呼制御を行うＳＩＰ(Session Initiation Protocol)プロトコルや、音声、動画などのデータストリームをリアルタイムに送受信するためのＲＴＰ(Real-time Transport Protocol)プロトコルが広く用いられる。ここでは、呼制御や音声、動画等のデータストリーム送受信を行うサーバをセッション制御サーバという。セッション制御サーバは、電話機の発信時に受け付けた呼をどのように処理するか、具体的には、どこにガイダンスを流すか、転送するか、着信するか等の呼制御情報と、電話機へ流す音声に変換される文章が記載されたテキストデータとを含む呼制御シナリオ（シナリオともいう）を、アプリケーション（以下、ＡＰＬ）から取得する機能を持つことを前提とする。
【０００３】
入力されたテキストデータをテキスト認識システムで認識し、人工の音声へ変換・合成をしてテキストを読み上げる機能をＴＴＳという。ＴＴＳを用いることにより、人間の音声を録音する必要がないため、例えば文字を読むことが困難な人に対して音声読み上げといったような、柔軟な音声出力が可能となる。このＴＴＳ機能を持つサーバをＴＴＳサーバという。
【０００４】
セッション制御サーバやＴＴＳサーバ等の様々な機能を提供するサーバは、サービス開発の際のプログラミングを効率的に行なう観点から、シンプルな機能単位でプログラミングのためのリソースを提供するインタフェースを持つことが望ましい。このインタフェースとして、ＡＰＩ(Application Programming Interface)が挙げられる。ＡＰＬサーバから任意のサーバに対してＡＰＩリクエストを送信することで、そのリクエストのＡＰＩで定義された機能を利用することが可能となる。例えば、ＡＰＬサーバからセッション制御サーバに対して、発呼ＡＰＩリクエストを送信すると、セッション制御サーバは、任意の発信者と受信者間の音声通話や映像によるビデオ通話を行う。なお、その音声通話やビデオ通話を行う発信者と受信者を通話者という。また、セッション制御サーバとＴＴＳサーバの双方は、各々異なるＡＰＩの仕様（通信仕様）を有するが、双方ともＡＰＩ提供サーバに包括される。
【０００５】
ところで、電話機能をＡＰＩとして提供するシステムとして、特許文献１に記載の次に説明する技術がある。まず、アプリケーションサーバが、クライアントから受信したリクエストの認証処理又はセッション処理を行い、リクエストがＡＰＩサーバへのアクセスを要求している際に、認証処理結果又はセッション処理結果をリクエストに付随させてＡＰＩサーバに送信する。次に、ＡＰＩサーバが、アプリケーションサーバから受信したリクエストに付随されている認証処理結果又はセッション処理結果に基づいて、当該受信したリクエストを処理するようになっている。
このように上記技術では、アプリケーションサーバはＡＰＩサーバと連携することが可能である。このアプリケーションサーバは、言い換えればＡＰＩ提供サーバとしてのセッション制御サーバであるが、セッション制御サーバにおいては、クライアントとしての電話機間の音声通話を可能とする呼制御を行うことが一般的に行なわれている。しかしながら、セッション制御サーバがテキストを音声に変換するＴＴＳサーバと連携して呼制御を行うことは、特許文献１では考慮されていない。
【０００６】
そこで、セッション制御サーバとＴＴＳサーバ間で連携してテキストデータ、音声データを遣り取りする技術としては、次の第１及び第２連携方法がある。
【０００７】
第１連携方法は、ＡＰＩ提供サーバとしてのセッション制御サーバとＴＴＳサーバ間を専用インタフェースを介して連携する方法である。この方法を、図５に示すＡＰＩ提供システム１０を参照して説明する。ＡＰＩ提供システム１０は、発信者の電話機１１と、受信者の電話機１２とが電話網１３を介してセッション制御サーバ（サーバ）１４に接続され、当該サーバ１４が、インターネット等のネットワークを介してＡＰＬサーバ１５に接続されると共に、専用インタフェース１６を介してＴＴＳサーバ１７に接続されて構成されている。
【０００８】
発信者の電話機１１から矢印Ｙ１１で示すように発呼があり、この呼をセッション制御サーバ１４が受け付けると、当該サーバ１４は矢印Ｙ１２で示すように、ＡＰＬサーバ１５にアクセスし、当該ＡＰＬサーバ１５上のＡＰＬ１５ａから発呼受信時の呼を制御するための呼制御シナリオを取得する。このシナリオを取得したセッション制御サーバ１４は、上記呼に応じた呼制御シナリオ中のテキストデータを矢印Ｙ１４で示すように専用インタフェース１６を介してＴＴＳサーバ１７へ送信する。この際、専用インタフェース１６は、セッション制御サーバ１４の通信仕様をＴＴＳサーバ１７に合わせる処理を行う。
【０００９】
ＴＴＳサーバ１７は、受信したテキストデータを音声データに変換して矢印Ｙ１５で示すように専用インタフェース１６を介してセッション制御サーバ１４へ返信する。セッション制御サーバ１４は、その音声データを受信して矢印Ｙ１６で示すように、音声データによる音声を受信者の電話機１２へ送信する。これによって受信者が音声を聞くことができる。
【００１０】
次に、第２連携方法は、セッション制御サーバとＴＴＳサーバ間をＡＰＬサーバを介して連携する方法である。この方法を、図６に示すＡＰＩ提供システム２０を参照して説明する。
【００１１】
まず、上述した第１連携方法と同様に矢印Ｙ１１〜Ｙ１３で示すように、発信者の発呼時の呼に応じてセッション制御サーバ１４がＡＰＬ１５ａから呼制御シナリオを取得する。このシナリオを取得したサーバ１４は、上記呼に応じたテキストデータを矢印Ｙ２１で示すようにＡＰＬサーバ１５へ送信する。ＡＰＬサーバ１５のＡＰＬ１５ａは、受信したテキストデータを矢印Ｙ２２で示すようにＴＴＳサーバ１７へ送信する。
【００１２】
ＴＴＳサーバ１７は、受信したテキストデータを音声データに変換して矢印２３で示すようにＡＰＬサーバ１５へ返信する。ＡＰＬサーバ１５のＡＰＬ１５ａは、その音声データを受信して矢印Ｙ２４で示すようにセッション制御サーバ１４へ送信し、当該サーバ１４は矢印Ｙ２５で示すように、音声データによる音声を受信者の電話機１２へ送信する。これによって受信者が音声を聞くことができる。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１０−１４６１６９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
しかし、上述した第１連携方法は、セッション制御サーバ１４とＴＴＳサーバ１７間に専用インタフェース１６を介在する必要がある。専用インタフェース１６は、一方のサーバの通信仕様を他方のサーバに合わせる処理を行うので、他方のサーバが複数あって各々の仕様が異なる場合、異なる仕様のサーバ毎に専用インタフェースが必要となる。このため、開発費等が発生して開発コストが高くなる問題がある。
【００１５】
第２連携方法は、ＡＰＬを開発するＡＰＬ開発者が、セッション制御サーバ１４及びＴＴＳサーバ１７を連携させる機能をＡＰＬに具備させる必要がある。具体的には、ＡＰＬサーバ１５に、テキストデータ及び音声データを格納するファイルサーバ機能を持つ必要がある。このため、ＡＰＬサーバ１５においてコード量の増加が生じるのでＡＰＬ開発者にとって手間が掛かり、開発コストが高くなる問題がある。
【００１６】
本発明は、このような事情に鑑みてなされたものであり、互いに異なる通信仕様を有するセッション制御サーバとＴＴＳサーバ間の連携を取る処理を、コストを抑制して実現することができるＡＰＩ提供サーバの連携装置及びＡＰＩ提供サーバの連携方法を提供することを課題とする。
【課題を解決するための手段】
【００１７】
上記課題を解決するための手段として、請求項１に係る発明は、電話機間の呼制御を行う第１サーバであるＡＰＩ提供サーバと、外部から入力されるテキストデータを音声データに変換する第２サーバであるＡＰＩ提供サーバとが異なる通信仕様を有する際に、各ＡＰＩ提供サーバ間の連携を行うＡＰＩ提供サーバの連携装置であって、前記第１サーバが電話機の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをアプリケーションとして保有する第３サーバから取得する際に、当該呼制御シナリオの内容を読み取り、前記第１サーバと前記第２サーバとの接続の必要性を判定する読込部と、前記接続が必要と判定された際に、前記第３サーバからの音声データ取得のリクエストを含む情報を、前記第１サーバ、前記第２サーバ及び当該第３サーバの間で相互に通信可能な通信仕様となるように変換する変換部と、前記変換されたリクエストを前記呼制御シナリオ中のテキストデータと共に前記第２サーバへ送信し、この送信に応じて当該第２サーバで前記テキストデータが変換された音声データを受信して保存する送受信部とを備え、前記保存された前記音声データは、前記第１サーバにより前記呼制御シナリオに基づき取得後、受信側の電話機へ送信されることを特徴とするＡＰＩ提供サーバの連携装置である。
【００１８】
請求項３に係る発明は、電話機間の呼制御を行う第１サーバであるＡＰＩ提供サーバと、外部から入力されるテキストデータを音声データに変換する第２サーバであるＡＰＩ提供サーバとが異なる通信仕様を有する際に、各ＡＰＩ提供サーバ間の連携を行う連携装置によるＡＰＩ提供サーバの連携方法であって、前記連携装置は、前記第１サーバが電話機の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをアプリケーションとして保有する第３サーバから取得する際に、当該呼制御シナリオの内容を読み取り、前記第１サーバと前記第２サーバとの接続の必要性を判定するステップと、前記接続が必要と判定された際に、前記第３サーバからの音声データ取得のリクエストを含む情報を、前記第１サーバ、前記第２サーバ及び当該第３サーバの間で相互に通信可能な通信仕様となるように変換するステップと、前記変換されたリクエストを前記呼制御シナリオ中のテキストデータと共に前記第２サーバへ送信し、この送信に応じて当該第２サーバで前記テキストデータが変換された音声データを受信して保存するステップと、前記保存された前記音声データが、前記第１サーバにより前記呼制御シナリオに基づき取得後、受信側の電話機へ送信されるステップとを実行することを特徴とするＡＰＩ提供サーバの連携方法である。
【００１９】
請求項１の構成及び請求項３の方法によれば、第１サーバが電話機間の呼制御を行う際に、連携装置で第１サーバ、第２サーバ及び第３サーバの間で相互に通信可能な通信仕様となるように変換される。これによって、第１サーバは第２サーバでテキストデータが変換された音声データを、受信側の電話機に音声として流すことができる。この発明構成では、ＡＰＩ提供サーバとしての第１及び第２サーバの通信仕様を、連携装置で相互に変換して通信可能とするので、従来のように異なる仕様のサーバ毎に専用インタフェースが必要となることが無くなる。言い換えれば、専用インタフェースが不要となる。また、アプリケーションサーバとしての第３サーバにおいて、テキストデータ及び音声データを格納するファイルサーバ機能を持つ必要が無くなるので、第３サーバにおいてコード量の増加が生じて開発コストが高くなることが無くなる。従って、本発明によれば、互いに異なる通信仕様を有する第１サーバとしてのセッション制御サーバと、第２サーバとしてのＴＴＳサーバとの間の連携を取る処理を、コストを抑制して実現することができる。
【００２０】
請求項２に係る発明は、前記第１サーバ、前記第２サーバ及び前記第３サーバの各々異なる通信仕様を統一化するルールを記載したルール情報を外部から取得して記憶する記憶部を更に備え、前記変換部は、前記記憶部に記憶されたルール情報のルールに従い、前記第１〜第３サーバ間で相互に信号を送受信するための通信仕様を統一化する変換処理を行うことを特徴とする請求項１に記載のＡＰＩ提供サーバの連携装置である。
【００２１】
この構成によれば、第１〜第３サーバの通信仕様が各々異なっていても、連携装置でルールに従って第１〜第３サーバの通信仕様の差分が吸収されて統一化されるので、第１〜第３サーバ間で相互に信号を送受信することができる。第１〜第３サーバ以外にサーバが増設されても、増設サーバに対する変換ルールの情報を記憶部にルール情報として外部から書き込んで記憶することができる。このため、増設サーバの通信仕様を他のサーバに合わせて容易に統一化することができる。
【発明の効果】
【００２２】
本発明によれば、互いに異なる通信仕様を有するセッション制御サーバとＴＴＳサーバ間の連携を取る処理を、コストを抑制して実現するＡＰＩ提供サーバの連携装置及びＡＰＩ提供サーバの連携方法を提供することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の実施形態に係るＡＰＩ提供サーバの連携装置を有するＡＰＩ提供システムの構成を示すブロック図である。
【図２】連携装置の構成を示すブロック図である。
【図３】本実施形態のＡＰＩ提供サーバの連携装置によるセッション制御サーバ及びＴＴＳサーバの連携動作を説明する第１のフローチャートである。
【図４】本実施形態のＡＰＩ提供サーバの連携装置によるセッション制御サーバ及びＴＴＳサーバの連携動作を説明する第２のフローチャートである。
【図５】従来の専用インタフェースを用いたＡＰＩ提供システムの構成を示すブロック図である。
【図６】従来のＡＰＩ提供システムの構成を示すブロック図である。
【発明を実施するための形態】
【００２４】
以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係るＡＰＩ提供サーバの連携装置を有するＡＰＩ提供システムの構成を示すブロック図である。
図１に示すＡＰＩ提供システム（システム）３０の特徴は、連携装置４０を用いた点にあり、セッション制御サーバ１４が連携装置４０を介して、異なるＡＰＩ仕様（通信仕様）のＴＴＳサーバ１７と連携し、発信者と受信者の電話機１１，１２間の音声通話の呼制御を行う。
【００２５】
なお、セッション制御サーバ１４、後述のＡＰＬサーバ１５及びＴＴＳサーバ１７は、単にサーバ１４，１５，１７とも称す。また、セッション制御サーバ１４は請求項記載の第１サーバを構成し、ＴＴＳサーバ１７は請求項記載の第２サーバ、ＡＰＬサーバ１５は請求項記載の第３サーバを構成する。
【００２６】
このシステム３０は、発信者と受信者の電話機１１，１２が電話網１３を介してセッション制御サーバ１４に接続され、当該サーバ１４が、連携装置４０を介してＡＰＬサーバ１５及びＴＴＳサーバ１７に接続されて構成されている。各サーバ１４，１５，１７及び連携装置４０は、インターネット１８を介して接続されている。
【００２７】
セッション制御サーバ１４は、電話機１１から受け付けた呼をどのように処理するか、具体的にはどこにガイダンスを流すか、転送するか、着信するか等の呼制御情報と、電話機へ流す音声に変換される文章が記載されたテキストデータとを含む呼制御シナリオを、ＡＰＬサーバ１５のＡＰＬ（アプリケーション）１５ａから取得する機能を有する。つまり、ＡＰＬサーバ１５は、上記呼に応じた呼制御シナリオを生成するＡＰＬ１５ａを備える。
【００２８】
ＴＴＳサーバ１７は、外部から入力されたテキストデータをテキスト認識システムで認識し、人工の音声へ変換・合成を行ってテキストを音声として発音可能な音声データに変換する機能を有し、この音声データを出力する。
【００２９】
連携装置４０は、電話機１１の発呼時の呼を受け付けたセッション制御サーバ１４が、ＡＰＬサーバ１５のＡＰＬ１５ａから呼制御シナリオを取得する途中経路で、このシナリオを読み取り、セッション制御サーバ１４とＴＴＳサーバ１７と連携させて音声を受信者の電話機１２へ流すための処理を行う。
【００３０】
連携装置４０は、図２に示すように、ＡＰＩ受付部４１と、シナリオ読込部４２と、ＡＰＩ変換部４３と、ＡＰＩ送受信部４４と、ファイル保存部４５と、ルーチング情報記憶部４６と、ＡＰＩ変換ルール記憶部４７と、設定受付部４８とを備えて構成されている。なお、ルーチング情報記憶部４６及びＡＰＩ変換ルール記憶部４７は、単に記憶部４６，４７とも称す。また、ＡＰＩ受付部４１及びシナリオ読込部４２は、請求項記載の読込部を構成する。ＡＰＩ変換部４３、ルーチング情報記憶部４６及びＡＰＩ変換ルール記憶部４７は、請求項記載の変換部を構成する。ＡＰＩ送受信部４４及びファイル保存部４５は、請求項記載の送受信部を構成する。
【００３１】
また、ＡＰＩ送受信部４４に接続されるＡＰＩ提供サーバ５１は、各々異なるＡＰＩ仕様の複数のＡＰＩ提供サーバであり、本実施形態ではセッション制御サーバ１４及びＴＴＳサーバ１７である。また、ＡＰＩ受付部４１に接続されるＡＰＩ利用サーバ５２は、本実施形態ではＡＰＬサーバ１５である。但し、ＡＰＩ利用サーバ５２としては、ＴＴＳサーバ１７やセッション制御サーバ１４等も含まれる。更に、設定受付部４８に接続される設定入力装置５３は、パーソナルコンピュータ等の演算処理端末機である。
【００３２】
設定受付部４８は、設定入力装置５３から入力されるＡＰＩ変換ルール情報（後述）やルーチング情報（後述）等の設定情報を受け付けて各記憶部４６，４７へ記憶する。つまり、記憶部４６はルーチング情報を記憶し、記憶部４７はＡＰＩ変換ルール情報を記憶する。
【００３３】
ＡＰＩ変換ルール情報は、ＡＰＩ仕様、言い換えればＡＰＩの書き方が各々異なるセッション制御サーバ１４及びＴＴＳサーバ１７のＡＰＩ仕様を統一化するルールを記載した情報である。
ルーチング情報は、ＡＰＩ仕様に沿って送信されるリクエスト等の情報の宛先アドレス｛ＵＲＬ(Uniform Resource Locator)｝を示す情報である。言い換えれば、ルーチング情報は、セッション制御サーバ１４やＴＴＳサーバ１７等のＵＲＬを示すものである。
【００３４】
ＡＰＩ受付部４１は、ＡＰＩ利用サーバ５２としてのＡＰＬサーバ１５（図１）から送信されて来る呼制御シナリオを受け取り、シナリオ読込部４２及びＡＰＩ変換部４３へ出力する。つまり、図１に矢印Ｙ３１で示すように、発信者の電話機１１からの発呼時の呼を受け付けたセッション制御サーバ１４が、矢印Ｙ３２，Ｙ３３で示すように、ＡＰＬサーバ１５のＡＰＬ１５ａから呼制御シナリオを取得する際に、連携装置４０内のポイントＰ１で示すにようにＡＰＩ受付部４１（図２）が呼制御シナリオを受け取る。これと並行して、図２に示すように、ＡＰＩ受付部４１で受け付けられた呼制御シナリオは、ＡＰＩ変換部４３を介してＡＰＩ送受信部４４からＡＰＩ提供サーバ５１としてのセッション制御サーバ１４へ送信される。
【００３５】
シナリオ読込部４２は、呼制御シナリオの記載内容を読み取り、セッション制御サーバ１４とＴＴＳサーバ１７とを音声接続する必要が有るか否かの必要性を認識（判定）し、この結果をＡＰＩ変換部４３へ出力する。
【００３６】
ＡＰＩ変換部４３は、シナリオ読込部４２で音声接続の必要性が認識された際に、各記憶部４７，４６から呼制御シナリオに応じたＡＰＩ変換ルール情報及びルーチング情報を読み込む。そして、ＡＰＩ変換部４３は、ＡＰＬサーバ１５から呼制御シナリオと共に送信される音声データ取得のリクエストを含む情報を、ＡＰＩ変換ルール情報のルールに従ってＴＴＳサーバ１７及びセッション制御サーバ１４のインタフェースに合うように変換する。この変換では、セッション制御サーバ１４、ＡＰＬサーバ１５及びＴＴＳサーバ１７の通信仕様（ＡＰＩ仕様）が統一化され、各サーバ１４，１５，１７間で通信情報が相互に通信可能となる。更に、ＡＰＩ変換部４３は、その変換されたリクエストにルーチング情報である宛先のＵＲＬを付けて、呼制御シナリオ中のテキストデータと共にＡＰＩ送受信部４４へ出力する。
【００３７】
ＡＰＩ送受信部４４は、音声データ取得のリクエストをテキストデータと共に、宛先のＵＲＬのＡＰＩ提供サーバ５１としてのＴＴＳサーバ１７（図１）へ送信する。また、ＡＰＩ送受信部４４は、ＴＴＳサーバ１７において音声データ取得のリクエストに基づきテキストデータが変換された音声データを受信してファイル保存部４５に保存する。ファイル保存部４５は、音声データをファイル形式でＵＲＬ等に対応付けて保存する。また、ＡＰＩ送受信部４４は、同音声データのＵＲＬをセッション制御サーバ１４へ通知する。
【００３８】
ファイル保存部４５に保存された音声データは、セッション制御サーバ１４がＡＰＬサーバ１５から取得した呼制御シナリオと上記通知されたＵＲＬに基づいて読み出し、音声として受信者の電話機１２へ送信する（流す）。
【００３９】
＜実施形態の動作＞
次に、ＡＰＩ提供サーバの連携装置４０によるセッション制御サーバ１４及びＴＴＳサーバ１７の連携動作を、図３及び図４に示すフローチャートを参照して説明する。但し、図２に示す設定入力装置５３から入力された所定のＡＰＩ変換ルール情報が設定受付部４８を介して記憶部４７に記憶され、同入力された各サーバ１４，１５，１７（図１）及び連携装置４０の各々のＵＲＬであるルーチング情報が設定受付部４８を介して記憶部４６に記憶されているとする。
【００４０】
図３のステップＳ１において、図１に示す発信者の電話機１１から受信者の電話機１２に対して、矢印Ｙ３１で示すように発呼が行なわれたとする。ステップＳ２において、その発呼時の呼をセッション制御サーバ１４が受け付けると、当該サーバ１４は矢印Ｙ３２で示すように、ＡＰＬサーバ１５のＡＰＬ１５ａに、上記呼に応じた呼制御シナリオを取得する要求を行う。この要求によりステップＳ３において、ＡＰＬサーバ１５はＡＰＬ１５ａから上記呼を制御するための呼制御シナリオを生成し、矢印Ｙ３３で示すように連携装置４０を介してセッション制御サーバ１４へ向けて送信する。
【００４１】
この送信途中で、ステップＳ４において、連携装置４０のＡＰＩ受付部４１は、呼制御シナリオを受け取ってシナリオ読込部４２へ出力し、これと並行して同呼制御シナリオをセッション制御サーバ１４へ送信する。この送信は、ＡＰＩ変換部４３及びＡＰＩ送受信部４４を介して行なわれる。
【００４２】
ステップＳ５において、シナリオ読込部４２は、呼制御シナリオの記載内容を読み取り、ステップＳ６において、セッション制御サーバ１４とＴＴＳサーバ１７との音声接続の必要性を認識する。ステップＳ７において、シナリオ読込部４２は、音声接続する必要が有るか否かを判定する。
【００４３】
この結果、音声接続の必要が無い（Ｎｏ）と判定された場合は、受信側に音声を流す呼制御の処理を終了する。一方、音声接続の必要が有る（Ｙｅｓ）と認識された場合、ステップＳ８において、ＡＰＩ変換部４３が、ＡＰＬサーバ１５からの音声データ取得のリクエストを含む情報を、記憶部４７から読み出したＡＰＩ変換ルール情報のルールに従ってＴＴＳサーバ１７及びセッション制御サーバ１４のインタフェースに合うように変換する。この変換では、セッション制御サーバ１４、ＡＰＬサーバ１５及びＴＴＳサーバ１７のＡＰＩ仕様が統一化され、各サーバ１４，１５，１７間で通信情報が相互に通信可能となる。
【００４４】
更に、図４のステップＳ９において、ＡＰＩ変換部４３は、そのＴＴＳサーバ１７のＵＲＬを記憶部４６から取得し、上記ステップＳ８で変換されたリクエストに宛先のＵＲＬを付けて、呼制御シナリオ中のテキストデータと共にＡＰＩ送受信部４４へ出力する。
【００４５】
ステップＳ１０において、ＡＰＩ送受信部４４は、矢印Ｙ３４（図１）で示すように、音声データ取得のリクエストをテキストデータと共に、宛先ＵＲＬのＴＴＳサーバ１７へ送信する。ステップＳ１１において、ＴＴＳサーバ１７は、音声データ取得のリクエストに基づきテキストデータを音声データに変換し、この変換した音声データを矢印Ｙ３５で示すように連携装置４０のＡＰＩ送受信部４４へ返信する。
【００４６】
ステップＳ１２において、ＡＰＩ送受信部４４は、その返信されてきた音声データをファイル保存部４５にＵＲＬを対応付けて保存すると共に、同音声データのＵＲＬを矢印Ｙ３６で示すようにセッション制御サーバ１４へ通知する。
【００４７】
ステップＳ１３において、セッション制御サーバ１４は、ＡＰＬサーバ１５から取得した呼制御シナリオ及び上記ステップＳ１２で通知されたＵＲＬに基づき、矢印Ｙ３７，Ｙ３８で示すように、ファイル保存部４５に保存された音声データを取得する。更に、セッション制御サーバ１４は、ステップＳ１４において、その取得した音声データに応じた音声を、矢印Ｙ３９で示すように受信者の電話機１２へ流す。これによって受信者が発信者の発呼に応じた音声を聞くことができる。
【００４８】
＜実施形態の効果＞
以上説明したように、本実施形態のＡＰＩ提供サーバの連携装置４０を、次のような特徴構成とした。連携装置４０は、各々異なる通信仕様（ＡＰＩ仕様）を有し、電話機１１，１２間の呼制御を行う第１サーバとしてのセッション制御サーバ１４と、外部から入力されるテキストデータを音声として発音可能な音声データに変換する第２サーバとしてのＴＴＳサーバ１７との連携を取る処理を実行する。
【００４９】
（１）セッション制御サーバ１４が電話機１１の発呼時の呼に応じて、呼制御の情報及びテキストデータを含む呼制御シナリオをアプリケーション（ＡＰＬ１５ａ）として保有するＡＰＬサーバ１５から取得する際に、ＡＰＩ受付部４１が呼制御シナリオを受け付けた後、シナリオ読込部４２が呼制御シナリオの内容を読み取る。この読取内容に応じて、ＡＰＩ変換部４３が、セッション制御サーバ１４とＴＴＳサーバ１７との接続の必要性を判定する。ここで、接続が必要と判定された際に、ＡＰＩ変換部４３が、ＡＰＬサーバ１５からの音声データ取得のリクエストを含む情報を、セッション制御サーバ１４、ＴＴＳサーバ１７及び当該ＡＰＬサーバ１５の間で相互に通信可能な通信仕様となるように変換する。ＡＰＩ送受信部４４は、その変換されたリクエストを呼制御シナリオ中のテキストデータと共にＴＴＳサーバ１７へ送信する。更にＡＰＩ送受信部４４は、その送信に応じてＴＴＳサーバ１７でテキストデータが変換された音声データを受信してファイル保存部４５に保存する。この保存された音声データは、セッション制御サーバ１４により呼制御シナリオに基づき取得後、音声に変換されて受信側の電話機１２へ送信される。
【００５０】
この構成によれば、セッション制御サーバ１４が電話機１１，１２間の呼制御を行う際に、連携装置４０でセッション制御サーバ１４、ＴＴＳサーバ１７及びＡＰＬサーバ１５の間で相互に通信可能な通信仕様となるように変換される。これによって、セッション制御サーバ１４はＴＴＳサーバ１７でテキストデータが変換された音声データを、受信側の電話機１２に音声として流すことができる。
【００５１】
この構成では、ＡＰＩ提供サーバとしてのセッション制御サーバ１４、ＴＴＳサーバ１７及びＡＰＬサーバ１５の通信仕様を、連携装置４０で相互に変換して通信可能とするので、従来のように異なる仕様のサーバ毎に専用インタフェースが必要となることが無くなる。言い換えれば、専用インタフェースが不要となる。また、アプリケーションサーバとしてのＡＰＬサーバ１５において、テキストデータ及び音声データを格納するファイルサーバ機能を持つ必要が無くなるので、ＡＰＬサーバ１５においてコード量の増加が生じて開発コストが高くなることが無くなる。従って、本構成によれば、互いに異なる通信仕様を有する、セッション制御サーバ１４とＴＴＳサーバ１７との間の連携を取る処理を、コストを抑制して実現することができる。
【００５２】
（２）セッション制御サーバ１４、ＴＴＳサーバ１７及びＡＰＬサーバ１５の各々異なる通信仕様を統一化するルールを記載したルール情報を、外部の設定入力装置５３から読み書き自在に記憶する記憶部４７を更に備える。ＡＰＩ変換部４３は、記憶部４７に記憶されたルール情報のルールに従い、各サーバ１４，１７，１５間で相互に信号を送受信するための通信仕様の差分が吸収されて統一化する変換処理を行う。
【００５３】
この構成によれば、各サーバ１４，１７，１５の通信仕様が各々異なっていても、連携装置４０でルールに従って各サーバ１４，１７，１５の通信仕様が統一化される。このため、各サーバ１４，１７，１５間で相互に信号を送受信することができる。各サーバ１４，１７，１５以外にＡＰＩ提供サーバが増設されても、増設サーバに対する変換ルールの情報を記憶部４７にルール情報として外部の設定入力装置５３から書き込んで記憶することができる。このため、増設サーバの通信仕様を既設サーバ１４，１７，１５に合わせて容易に統一化することができる。
【００５４】
その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
【符号の説明】
【００５５】
１１，１２  電話機
１４  セッション制御サーバ（第１サーバ）
１５  ＡＰＬサーバ（第３サーバ）
１５ａ  ＡＰＬ（アプリケーション）
１７  ＴＴＳサーバ（第２サーバ）
３０  ＡＰＩ提供システム
４０  連携装置
４１  ＡＰＩ受付部
４２  シナリオ読込部
４３  ＡＰＩ変換部
４４  ＡＰＩ送受信部
４５  ファイル保存部
４６  ルーチング情報記憶部
４７  ＡＰＩ変換ルール記憶部
４８  設定受付部
５１  ＡＰＩ提供サーバ
５２  ＡＰＩ利用サーバ
５３  設定入力装置
【図１】
2017163434.tif 000003
【図２】
2017163434.tif 000004
【図３】
2017163434.tif 000005
【図４】
2017163434.tif 000006
【図５】
2017163434.tif 000007
【図６】
2017163434.tif 000008