(57)【要約】【課題】発側および着側の双方の間で通話内容のテキストを一致させること。【解決手段】一実施形態に係る呼制御システムは音声テキスト化サービスを実行可能である。呼制御システムは、発信者と着信者との双方が音声テキスト化サービスの利用者である場合に、発信端末に対応する発側メディア処理装置と着信端末に対応する着側メディア処理装置とのうちの一方を共通のメディア処理装置として機能させる制御部を備える。共通のメディア処理装置は音声認識エンジンと接続する。共通のメディア処理装置は、発側音声を音声認識エンジンに入力することで発側テキストを取得し、発側テキストを発信端末および着信端末の双方に向けて送信する。共通のメディア処理装置は、着側音声を音声認識エンジンに入力することで着側テキストを取得し、着側テキストを発信端末および着信端末の双方に向けて送信する。【選択図】図２
2020088818.tif 000002
【特許請求の範囲】
【請求項１】
発信端末と着信端末との間で伝送される通話をテキストに変換する音声テキスト化サービスを実行可能な呼制御システムであって、
前記発信端末を利用する発信者と前記着信端末を利用する着信者との双方が前記音声テキスト化サービスの利用者である場合に、前記発信端末に対応する発側メディア処理装置と前記着信端末に対応する着側メディア処理装置とのうちの一方を共通のメディア処理装置として機能させる制御部を備え、
前記共通のメディア処理装置が、前記発信者または前記着信者の音声をテキストに変換する音声認識エンジンと接続し、
前記共通のメディア処理装置が、
前記発信端末から送信された前記発信者の発側音声を前記音声認識エンジンに入力することで発側テキストを取得し、
前記発側テキストを前記発信端末および前記着信端末の双方に向けて送信し、
前記着信端末から送信された前記着信者の着側音声を前記音声認識エンジンに入力することで着側テキストを取得し、
前記着側テキストを前記発信端末および前記着信端末の双方に向けて送信する、
呼制御システム。
【請求項２】
前記制御部が前記発側メディア処理装置を前記共通のメディア処理装置として機能させる、
請求項１に記載の呼制御システム。
【請求項３】
前記制御部が、
前記発側メディア処理装置を一意に特定する発側メディア装置ＩＤを前記着側メディア処理装置に向けて送信し、
前記発側メディア装置ＩＤを受信した前記着側メディア処理装置から、前記着側メディア処理装置を一意に特定する着側メディア装置ＩＤを受信し、
前記着側メディア装置ＩＤの受信に応答して、前記発側メディア処理装置を前記共通のメディア処理装置として機能させる、
請求項２に記載の呼制御システム。
【請求項４】
前記発側メディア処理装置が、前記発側テキストまたは前記着側テキストを前記発信端末に送信する発側Ｗｅｂサーバと接続し、
前記着側メディア処理装置が、前記発側テキストまたは前記着側テキストを前記着信端末に送信する着側Ｗｅｂサーバと接続し、
前記呼制御システムが、前記発側Ｗｅｂサーバを一意に特定する発側エンドポイントと、前記着側Ｗｅｂサーバを一意に特定する着側エンドポイントとを含むセッション情報を記憶するデータベースをさらに備え、
前記共通のメディア処理装置が、
前記セッション情報の前記発側エンドポイントおよび前記着側エンドポイントを取得し、
前記発側エンドポイントに基づいて、前記発側テキストまたは前記着側テキストを前記発側Ｗｅｂサーバに送信することで、前記発側テキストまたは前記着側テキストを前記発信端末に向けて送信し、
前記着側エンドポイントに基づいて、前記発側テキストまたは前記着側テキストを前記着側Ｗｅｂサーバに送信することで、前記発側テキストまたは前記着側テキストを前記着信端末に向けて送信する、
請求項２または３に記載の呼制御システム。
【請求項５】
前記制御部が、ユーザが前記音声テキスト化サービスの利用に同意することを示す同意信号が前記発信端末および前記着信端末の双方から送信されたことに応答して、音声テキストをどの通信端末に送信するかを示す認識方向を双方向に設定し、
前記共通のメディア処理装置が、前記認識方向が双方向であることに応答して、前記発側テキストまたは前記着側テキストを前記発側Ｗｅｂサーバおよび前記着側Ｗｅｂサーバの双方に向けて送信する、
請求項４に記載の呼制御システム。
【請求項６】
前記共通のメディア処理装置が、前記発側テキストおよび前記着側テキストのそれぞれについて、発話者が前記発信者および前記着信者のどちらであるかを示す発話種別をさらに前記発側Ｗｅｂサーバおよび前記着側Ｗｅｂサーバの双方に送信する、
請求項４または５に記載の呼制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示の一側面は呼制御システムに関する。
【背景技術】
【０００２】
端末間で伝送される通話の内容をテキストに変換して少なくとも一方の端末にそのテキストを表示する技術が知られている。例えば、特許文献１には、第１の端末から入力された音声信号を音声認識し、音声認識結果の読み情報を生成し、少なくとも読み情報を、第１の端末の通話相手である第２の端末に表示させる電話システムが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−６６８６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記の電話システムは、一方の話者の発話をテキストに変換して該テキストを他方の話者の電話機に伝送するので、この仕組みは一方向のテキスト変換である。一方の話者の発話を双方の話者が視認する場面を実現するための手段として、発側および着側の双方に音声認識サーバを設置することが考えられる。しかし、音声認識エンジンへの接続が発側と着側との間で異なると音声認識の結果が異なってしまう可能性があり、その結果、一つの発話を表すテキストが発側と着側とで異なる可能性がある。そのため、発側および着側の双方の間で通話内容のテキストを一致させることが望まれている。
【課題を解決するための手段】
【０００５】
本開示の一側面に係る呼制御システムは、発信端末と着信端末との間で伝送される通話をテキストに変換する音声テキスト化サービスを実行可能である。呼制御システムは、発信端末を利用する発信者と着信端末を利用する着信者との双方が音声テキスト化サービスの利用者である場合に、発信端末に対応する発側メディア処理装置と着信端末に対応する着側メディア処理装置とのうちの一方を共通のメディア処理装置として機能させる制御部を備える。共通のメディア処理装置は、発信者または着信者の音声をテキストに変換する音声認識エンジンと接続する。共通のメディア処理装置は、発信端末から送信された発信者の発側音声を音声認識エンジンに入力することで発側テキストを取得し、発側テキストを発信端末および着信端末の双方に向けて送信する。共通のメディア処理装置は、着信端末から送信された着信者の着側音声を音声認識エンジンに入力することで着側テキストを取得し、着側テキストを発信端末および着信端末の双方に向けて送信する。
【０００６】
このような側面においては、発信者および着信者の双方が音声認識サービスの利用者である場合に、発信者および着信者の双方の音声が共通のメディア処理装置を介してテキストに変換され、そのテキストが発信端末および着信端末の双方に送信される。発側および着側の双方について、共通のメディア処理装置が用いられるので、発側および着側の双方の間で通話内容のテキストを一致させることができる。
【発明の効果】
【０００７】
本開示の一側面によれば、発側および着側の双方の間で通話内容のテキストを一致させることができる。
【図面の簡単な説明】
【０００８】
【図１】実施形態に係る呼制御システムの全体構成の一例を示す図である。
【図２】実施形態に係るいくつかの通信制御装置の機能構成の一例を示す図である。
【図３】実施形態に係る呼制御システムの動作の一例を示すシーケンス図である。
【図４】実施形態に係る呼制御システムの動作の一例を示すシーケンス図である。
【図５】実施形態に係る呼制御システムの動作の一例を示すシーケンス図である。
【図６】実施形態に係る呼制御システムの動作の一例を示すシーケンス図である。
【図７】実施形態に係る通信制御装置に用いられるコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【０００９】
以下、添付図面を参照しながら本開示での実施形態を詳細に説明する。なお、図面の説明において同一または同等の要素には同一の符号を付し、重複する説明を省略する。
【００１０】
呼制御システムは、発信端末と着信端末との間の呼および通話を制御するコンピュータシステムである。呼とは発信端末と着信端末との間で一時的に占有される通信経路のことをいう。発信端末とは最初に呼接続を要求する通信端末のことをいい、着信端末とはその呼接続要求に応答する通信端末のことをいう。これら二つの通信端末間で呼が確立されることで、発信者（発信端末のユーザ）および着信者（着信端末のユーザ）は会話することができる。通話とは、発信端末と着信端末との間で送受信される音声を意味し、また、発信端末と着信端末との間での音声の送受信も意味する。
【００１１】
本実施形態では、呼制御システムは、発信端末と着信端末との間の通話をテキストに変換して、変換されたテキストを発信端末および着信端末の少なくとも一方に表示させる音声テキスト化サービス（これは音声認識サービスともいう。）を実行する。本開示では、変換されたテキストを音声テキストともいう。
【００１２】
図１は実施形態に係る呼制御システム１の全体構成を示す図である。呼制御システム１は、発信端末３１が在圏する発側ネットワーク２１と、着信端末３２が在圏する着側ネットワーク２２と、発側ネットワーク２１および着側ネットワーク２２を接続するコアネットワーク１０とを備える。呼制御システム１では、複数の装置および端末の間で制御信号が伝送されることで呼（通信経路）が確立され、音声を示すデータ信号がその呼を介して伝送されることで、通話が可能になる。
【００１３】
発信端末３１および着信端末３２はいずれも、通話機能を有する通信端末である。発信端末３１および着信端末３２のそれぞれは固定端末でもよいし携帯端末でもよい。発信端末３１および着信端末３２の例として、携帯電話機、スマートフォン、タブレット端末、ウェアラブル端末、またはパーソナルコンピュータが挙げられるが、端末の種類はこれらに限定されない。発信端末３１と着信端末３２とで端末の種類が同じでもよいし異なってもよい。
【００１４】
発側ネットワーク２１および着側ネットワーク２２はいずれも、端末が直接に接続するアクセスネットワークである。アクセスネットワークの構成は限定されない。例えば、アクセスネットワークは任意の無線ネットワークまたは有線ネットワークであってもよい。発側ネットワーク２１と着側ネットワーク２２との間でアクセスネットワークの種類（プロトコル）が同じでもよいし異なってもよい。
【００１５】
コアネットワーク１０は、呼制御システム１の中核を成すネットワークであり、様々な通信制御装置を備える。本実施形態では、コアネットワーク１０はＩＭＳネットワークであるとする。ＩＭＳネットワークは、通信プロトコルとしてＳＩＰを用い、データ通信だけでなく音声または動画のリアルタイム通信を実現するマルチメディアサービスを提供できるネットワークである。ＩＭＳネットワークでは、呼セッション制御機能（ＣＳＣＦ：Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）、アプリケーションサーバ（ＡＳ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）、ゲートウェイ、加入者管理機能（ＨＳＳ：Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）などの複数の通信制御装置により呼が処理される。ＣＳＣＦは、呼またはセッションを設定したり、予め定められたサービスを起動したりする呼制御装置である。アプリケーションサーバは、予め定められた付加サービス（例えば、音声テキスト化サービス）を実行したり、その付加サービスの実行の可否を判定したりする装置である。ゲートウェイは、アクセスネットワークとコアネットワークとを接続する装置である。ＨＳＳはユーザのプロファイル（加入者情報）を記憶する装置（データベース）である。
【００１６】
本実施形態では、コアネットワーク１０は、ＭＣＥ（Ｍｅｄｉａ  Ｃｏｍｐｏｓｉｔｉｏｎ  Ｅｎａｂｌｅｒ）およびＳＭＳ−ＧＷ（ＳＭＳゲートウェイ）という２種類の通信制御装置をさらに備える。ＭＣＥは通話の付加機能を提供するメディア処理装置である。ＳＭＳ−ＧＷは、コアネットワークと他のネットワークとを接続するゲートウェイの一種であり、ショートメッセージサービス（ＳＭＳ）を提供する装置である。
【００１７】
図１は、付加サービスを伴う呼の制御に特に関連する通信制御装置を示し、具体的には、発側ＣＳＣＦ１１、着側ＣＳＣＦ１２、発側ＡＳ１３、着側ＡＳ１４、発側ＭＣＥ１５、着側ＭＣＥ１６、発側ＳＭＳ−ＧＷ１７、および着側ＳＭＳ−ＧＷ１８を示す。
【００１８】
発側ＣＳＣＦ１１および着側ＣＳＣＦ１２はいずれも、発信端末３１と着信端末３２とを通信接続するための呼制御を実行する。発側ＣＳＣＦ１１と着側ＣＳＣＦ１２との間で制御信号およびデータ信号（例えば音声データ）が送受信されることで、発側と着側とが相互に接続される。発側ＡＳ１３は発側のアプリケーションサーバであり、着側ＡＳ１４は着側のアプリケーションサーバである。発側ＭＣＥ１５は発側のメディア処理装置であり、着側ＭＣＥ１６は着側のメディア処理装置である。発側ＳＭＳ−ＧＷ１７は発側のＳＭＳゲートウェイであり、着側ＳＭＳ−ＧＷ１８は着側のＳＭＳゲートウェイである。
【００１９】
図１はさらに発側Ｗｅｂサーバ４１、着側Ｗｅｂサーバ４２、および音声認識エンジン４３を示す。発側Ｗｅｂサーバ４１および音声認識エンジン４３は、発信端末３１に音声テキスト化サービスを提供する発側サービス基盤を構成する。着側Ｗｅｂサーバ４２および音声認識エンジン４３は、着信端末３２に音声テキスト化サービスを提供する着側サービス基盤を構成する。音声認識エンジン４３は、発側および着側の双方により用いられる共通のコンピュータであり、音声認識を用いて音声をテキストに変換する。発側および着側のサービス基盤はいずれも、コアネットワーク１０とは別の通信ネットワーク内に設けられる。発側Ｗｅｂサーバ４１は、発信端末３１、発側ＡＳ１３、および発側ＭＣＥ１５のそれぞれとデータ通信を実行することができる。着側Ｗｅｂサーバ４２は、着信端末３２、着側ＡＳ１４、および着側ＭＣＥ１６のそれぞれとデータ通信を実行することができる。音声認識エンジン４３は発側ＭＣＥ１５および着側ＭＣＥ１６のそれぞれとデータ通信を実行することができる。発信端末３１は発側Ｗｅｂサーバ４１と接続することで音声テキスト化サービスを発信者に提供することができる。着信端末３２は着側Ｗｅｂサーバ４２と接続することで音声テキスト化サービスを着信者に提供することができる。
【００２０】
本実施形態では、コアネットワーク１０はセッションデータベース（セッションＤＢ）１９をさらに備える。セッションデータベース１９は、音声テキスト化サービスを伴う呼（セッション）に関するセッション情報を記憶する装置（記憶部）であり、発側および着側の双方により用いられる共通のデータベースである。セッションデータベース１９は発側ＡＳ１３および着側ＡＳ１４にアクセスされ得る。
【００２１】
例えば、一つの呼に対応するセッション情報は、セッションＩＤ、発側補助セッションＩＤ、着側補助セッションＩＤ、発信端末３１の加入者番号、着信端末３２の加入者番号、発側エンドポイント、着側エンドポイント、および認識方向というデータ項目群を含んでもよい。セッションＩＤは呼（セッション）を一意に特定する識別子である。補助セッションＩＤは、コアネットワーク１０の外側に位置するＷｅｂサーバでも呼を一意に特定できるように用意される識別子である。発側補助セッションＩＤは発側Ｗｅｂサーバ４１のために用いられ、着側補助セッションＩＤは着側Ｗｅｂサーバ４２のために用いられる。エンドポイントはＷｅｂサーバを一意に特定する識別子である。発側エンドポイントは発側Ｗｅｂサーバ４１を一意に特定し、着側エンドポイントは着側Ｗｅｂサーバ４２を一意に特定する。認識方向は、音声テキストをどの通信端末に送信するかを示す情報である。
【００２２】
セッション情報のデータ構造は限定されず、任意の方針で設計されてよい。例えば、セッション情報は発側のレコードと着側のレコードとを互いに関連付けることで表現されてもよい。あるいは、セッション情報は、発側および着側の双方のデータ項目が１レコードに統合されることで表現されてもよい。
【００２３】
図１に示す各装置は、少なくとも一つのコンピュータを用いて構成される。複数のコンピュータが用いられる場合には、これらのコンピュータが通信ネットワークを介して相互に接続することで、論理的に一つの装置が構築される。
【００２４】
呼制御システム１の特徴の一つは、発信者および着信者の双方が音声テキスト化サービスを利用する場合に、発側および着側のいずれか一方が、発信者および着信者の双方の音声をテキストに変換する点にある。図１に示すように音声認識エンジン４３が発側と着側とで共通であったとしても、その音声認識エンジン４３への接続が発側と着側との間で異なると音声認識の結果が異なってしまう可能性がある。例えば、或る一つの発話が発側ＭＣＥ１５から音声認識エンジン４３に入力された場合と、同じ発話が着側ＭＣＥ１６から音声認識エンジン４３に入力された場合とで、音声テキストが異なる可能性がある。発側および着側の双方の間で通話内容のテキストを一致させるために、呼制御システム１では、発側ＭＣＥ１５および着側ＭＣＥ１６のうちの一方のみが共通のメディア処理装置として機能する。この共通のメディア処理装置は、発信者および着信者の双方の音声を音声認識エンジン４３に送信し、音声テキストを発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２の双方に送信する。図１は、この仕組みに関連する接続５１，５２も示す。接続５１は一つの呼（セッション）において発側ＭＣＥ１５が共通のメディア処理装置として機能する場合に用いられ、接続５２は一つの呼（セッション）において着側ＭＣＥ１６が共通のメディア処理装置として機能する場合に用いられる。
【００２５】
図２は、アプリケーションサーバの機能構成の一例を示す図である。発側ＡＳ１３は機能要素としてサービス制御部１３１、セッション制御部１３２、およびサービスシナリオ部１３３を備える。サービス制御部１３１は発側ＣＳＣＦ１１との間でデータを送受信する機能要素である。セッション制御部１３２は発側ＭＣＥ１５との間でデータを送受信する機能要素である。サービスシナリオ部１３３は発側ＳＭＳ−ＧＷ１７および発側Ｗｅｂサーバ４１のそれぞれとの間でデータを送受信する機能要素である。発側ＭＣＥ１５が発側および着側のそれぞれの音声を処理する場合には、サービスシナリオ部１３３は着側Ｗｅｂサーバ４２との間でもデータを送受信する可能性があり、図２における接続６１はその通信を示す。
【００２６】
着側ＡＳ１４は機能要素としてサービス制御部１４１、セッション制御部１４２、およびサービスシナリオ部１４３を備える。サービス制御部１４１は着側ＣＳＣＦ１２との間でデータを送受信する機能要素である。セッション制御部１４２は着側ＭＣＥ１６との間でデータを送受信する機能要素である。サービスシナリオ部１４３は着側ＳＭＳ−ＧＷ１８および着側Ｗｅｂサーバ４２のそれぞれとの間でデータを送受信する機能要素である。着側ＭＣＥ１６が発側および着側のそれぞれの音声を処理する場合には、サービスシナリオ部１４３は発側Ｗｅｂサーバ４１との間でもデータを送受信する可能性があり、図２における接続６２はその通信を示す。
【００２７】
発側ＡＳ１３および着側ＡＳ１４はいずれも、発信者および着信者の双方が音声テキスト化サービスを利用する場合に、発側ＭＣＥ１５および着側ＭＣＥ１６のうちの一方を共通のメディア処理装置として機能させる制御部を備える。発側ＡＳ１３では、サービス制御部１３１、セッション制御部１３２、およびサービスシナリオ部１３３の少なくとも一つがその制御部に相当する。着側ＡＳ１４では、サービス制御部１４１、セッション制御部１４２、およびサービスシナリオ部１４３の少なくとも一つがその制御部に相当する。
【００２８】
本実施形態では発側ＭＣＥ１５が双方の音声を処理する例を説明する。したがって、図１に示す接続５１と図２に示す接続６１とが利用される。しかし、本開示はその例に限定されるものではなく、着側ＭＣＥ１６が双方の音声を処理してもよい。
【００２９】
図３〜図６を参照しながら、本実施形態に係る呼制御システム１の動作の例を説明する。図３〜図６はいずれも呼制御システム１の動作の一例を示すシーケンス図である。図３は呼を確立する処理の例を示す。図４および図５は音声テキスト化サービスを起動する処理の例を示す。図６は音声テキストを通信端末上に表示する処理の例を示す。理解を容易にするために、図３〜図６では、通話および音声テキスト化サービスの制御に特に関係する構成要素、処理、およびデータ信号に限って示す。
【００３０】
まず、図３を参照しながら、呼を確立する処理の例を処理フローＳ１として説明する。
【００３１】
ステップＳ１０１では、発信端末３１が発信者の発信操作に応じてＩＮＶＩＴＥメッセージを送信し、発側ＡＳ１３がそのＩＮＶＩＴＥメッセージを受信する。ＩＮＶＩＴＥメッセージは、発信端末３１と着信端末３２との間に呼（セッション）を確立するために伝送される制御信号（呼確立要求信号）である。このＩＮＶＩＴＥメッセージは発側ネットワーク２１を経由してコアネットワーク１０に入る。コアネットワーク１０では、発側ＣＳＣＦ１１がそのＩＮＶＩＴＥメッセージを発側ＡＳ１３に転送する。
【００３２】
ステップＳ１０２では、サービス制御部１３１がそのＩＮＶＩＴＥメッセージに応答して発信端末３１（発信者）のために音声テキスト化サービスを起動する。サービス制御部１３１は加入者管理機能にアクセスして発信者の加入者情報を参照し、発信者が音声テキスト化サービスを契約しているか否かを判定する。発信者が音声テキスト化サービスを契約している場合に、サービス制御部１３１はサービスを起動する。本実施形態では、発信者が音声テキスト化サービスの契約者であることを前提とする。サービスの起動に関連して、サービス制御部１３１、セッション制御部１３２、およびサービスシナリオ部１３３は連携して、これから確立する呼のセッションＩＤと、発側補助セッションＩＤと、発信端末３１の加入者番号と、着信端末３２の加入者番号とを含むセッション情報をセッションデータベース１９に格納する。
【００３３】
ステップＳ１０３では、サービスシナリオ部１３３が発側ＳＭＳ−ＧＷ１７にプッシュ通知を送信し、ステップＳ１０４では、発側ＳＭＳ−ＧＷ１７がそのプッシュ通知に応答して発信端末３１にプッシュ要求を送信する。サービスシナリオ部１３３は、サービス制御部１３１からの指示に応答してユーザプロファイルにアクセスして発信者のユーザ情報を参照し、音声テキスト化サービスの契約状態を判定する。発信者に音声テキスト化サービスを提供できる場合に、サービスシナリオ部１３３はプッシュ通知を送信する。本実施形態では、発信者が音声テキスト化サービスを享受する資格を有することを前提とする。プッシュ要求は、発信端末３１が発側Ｗｅｂサーバ４１から音声テキスト化サービスを受けるために必要な情報（例えば、発信端末３１のデバイストークン、および発側補助セッションＩＤ）を含み、プッシュ通知は、そのプッシュ要求を構成する情報の少なくとも一部を含む。
【００３４】
ステップＳ１０５では、セッション制御部１３２が発側ＭＣＥ１５との接続のためにＩＮＶＩＴＥメッセージを発側ＭＣＥ１５に送信する。発側ＭＣＥ１５はそのＩＮＶＩＴＥメッセージに応答して音声テキスト化サービスのための処理を実行した後に、ステップＳ１０６において２００＿ＯＫメッセージを送信する。２００＿ＯＫメッセージは、ＩＮＶＩＴＥメッセージに対応する処理が正常に実行されたことを示す応答信号である。すなわち、２００＿ＯＫメッセージはＩＮＶＩＴＥメッセージに対応する成功応答信号である。
【００３５】
ステップＳ１０７では、サービス制御部１３１が着側ＡＳ１４に向けてＩＮＶＩＴＥメッセージを送信する。サービス制御部１３１は、ＩＮＶＩＴＥメッセージのヘッダ情報に、発側ＭＣＥ１５を一意に特定するための識別子である発側メディア装置ＩＤと、発側で音声テキスト化サービスが実行されることを示す発側サービス情報とを付加する。そして、サービス制御部１３１は発側メディア装置ＩＤおよび発側サービス情報を含むＩＮＶＩＴＥメッセージを送信する。このＩＮＶＩＴＥメッセージは発側ＣＳＣＦ１１および着側ＣＳＣＦ１２を経由して着側ＡＳ１４に到達する。
【００３６】
ステップＳ１０８では、サービス制御部１４１が発側ＡＳ１３からのＩＮＶＩＴＥメッセージに応答して着信端末３２（着信者）のために音声テキスト化サービスを起動する。サービス制御部１４１は加入者管理機能にアクセスして着信者の加入者情報を参照し、着信者が音声テキスト化サービスを契約しているか否かを判定する。着信者が音声テキスト化サービスを契約している場合に、サービス制御部１４１はサービスを起動する。本実施形態では、着信者が音声テキスト化サービスの契約者であることを前提とする。サービスの起動に関連して、サービス制御部１４１、セッション制御部１４２、およびサービスシナリオ部１４３は連携して、これから確立する呼の着側補助セッションＩＤをセッションデータベース１９内の対応するセッション情報に書き込む。
【００３７】
ステップＳ１０９では、サービスシナリオ部１４３が着側ＳＭＳ−ＧＷ１８にプッシュ通知を送信し、ステップＳ１１０では、着側ＳＭＳ−ＧＷ１８がそのプッシュ通知に応答して着信端末３２にプッシュ要求を送信する。サービスシナリオ部１４３は、サービス制御部１４１からの指示に応答してユーザプロファイルにアクセスして着信者のユーザ情報を参照し、音声テキスト化サービスの契約状態を判定する。着信者に音声テキスト化サービスを提供できる場合に、サービスシナリオ部１４３はプッシュ通知を送信する。本実施形態では、着信者が音声テキスト化サービスを享受する資格を有することを前提とする。プッシュ要求は、着信端末３２が着側Ｗｅｂサーバ４２から音声テキスト化サービスを受けるために必要な情報（例えば、着信端末３２のデバイストークン、および着側補助セッションＩＤ）を含み、プッシュ通知は、そのプッシュ要求を構成する情報の少なくとも一部を含む。
【００３８】
ステップＳ１１１では、セッション制御部１４２が着側ＭＣＥ１６との接続のためにＩＮＶＩＴＥメッセージを着側ＭＣＥ１６に送信する。着側ＭＣＥ１６はそのＩＮＶＩＴＥメッセージに応答して音声テキスト化サービスのための処理を実行する。着側ＭＣＥ１６はＩＮＶＩＴＥメッセージ内の発側メディア装置ＩＤおよび発側サービス情報を参照することで、発側で音声テキスト化サービスが実行されることと、発側ＭＣＥ１５がそのサービスを実行することとを認識する。この認識に基づいて、着側ＭＣＥ１６は音声データを音声認識エンジン４３に提供しない。ただし、着側ＭＣＥ１６と着側ＡＳ１４との間の接続は、呼が切断されるまで維持される。ステップＳ１１２では、着側ＭＣＥ１６が２００＿ＯＫメッセージを着側ＡＳ１４に送信する。
【００３９】
ステップＳ１１３では、サービス制御部１４１がＩＮＶＩＴＥメッセージを着信端末３２に向けて送信する。ＩＮＶＩＴＥメッセージは着側ＡＳ１４から着側ＣＳＣＦ１２に送られ、着側ＣＳＣＦ１２から着側ネットワーク２２を経由して着信端末３２に送信される。着信端末３２がそのＩＮＶＩＴＥメッセージを受信することで、着信端末３２に対する呼出処理が完了する。
【００４０】
ステップＳ１１４では、着信者が電話に出たことに応答して、着信端末３２が２００＿ＯＫメッセージを送信し、この２００＿ＯＫメッセージが着側ネットワーク２２および着側ＣＳＣＦ１２を経由して着側ＡＳ１４に到達する。
【００４１】
ステップＳ１１５では、着側ＡＳ１４のサービス制御部１４１、セッション制御部１４２、およびサービスシナリオ部１４３のそれぞれがそのメッセージを処理し、最後にサービス制御部１４１が２００＿ＯＫメッセージを発側ＡＳ１３に向けて送信する。サービス制御部１４１は、２００＿ＯＫメッセージのヘッダ情報に、着側ＭＣＥ１６を一意に特定するための識別子である着側メディア装置ＩＤと、着側で音声テキスト化サービスが実行されることを示す着側サービス情報とを付加する。そして、サービス制御部１４１は着側メディア装置ＩＤおよび着側サービス情報を含む２００＿ＯＫメッセージを送信する。この２００＿ＯＫメッセージは着側ＣＳＣＦ１２および発側ＣＳＣＦ１１を経由して発側ＡＳ１３に到達する。
【００４２】
ステップＳ１１６では、セッション制御部１３２がその２００＿ＯＫメッセージを発側ＭＣＥ１５に送信する。発側ＭＣＥ１５はその２００＿ＯＫメッセージ内の着側メディア装置ＩＤおよび着側サービス情報を参照することで、着側でも音声テキスト化サービスが実行されることを認識する。この認識に基づいて、発側ＭＣＥ１５は発信端末３１からの音声データと着信端末３２からの音声データとを音声認識エンジン４３に提供する。このように、発側ＡＳ１３は発側ＭＣＥ１５を共通のメディア処理装置として機能させる。ステップＳ１１７では、発側ＭＣＥ１５が２００＿ＯＫメッセージを発側ＡＳ１３に返し、ステップＳ１１８では、発側ＡＳ１３がその２００＿ＯＫメッセージを発信端末３１に向けて送信する。２００＿ＯＫメッセージは発側ＣＳＣＦ１１および発側ネットワーク２１を経由して発信端末３１に到達する。
【００４３】
ステップＳ１１９では、発信端末３１が２００＿ＯＫメッセージを受信することで、発信端末３１と着信端末３２との間に、データ信号を伝送するためのＵ−Ｐｌａｎｅ（ユーザ・プレイン）のバスが確立される。すなわち、発信端末３１と着信端末３２との間に呼が確立される。この結果、発信端末３１と着信端末３２との間で通話が可能になる。
【００４４】
次に、図４を参照しながら、音声テキスト化サービスを起動する処理の例を処理フローＳ２として説明する。この例は、通信端末での音声テキスト化サービスの開始のタイミングが発信端末３１と着信端末３２との間で同じかまたはほぼ同じ場合を示す。
【００４５】
ステップＳ２０１では、発信端末３１が音声テキスト化サービスのためのアプリケーションプログラムを起動するために接続要求を発側Ｗｅｂサーバ４１に送信する。接続要求は発信端末３１と発側Ｗｅｂサーバ４１との間に通信接続を確立するためのデータ信号であり、プッシュ要求により提供された情報の少なくとも一部（例えば、発信端末３１のデバイストークン、および発側補助セッションＩＤ）を含む。
【００４６】
ステップＳ２０２では、発側Ｗｅｂサーバ４１と発側ＡＳ１３のサービスシナリオ部１３３との間で、発信者を認証するための処理が実行される。発側Ｗｅｂサーバ４１は、接続要求により提供された情報の少なくとも一部（例えば、発信端末３１のデバイストークン）を含む認証要求を発側ＡＳ１３に送信する。サービスシナリオ部１３３はその認証要求に応答して認証処理を実行する。例えば、サービスシナリオ部１３３はデバイストークンが有効か否かを検査する。サービスシナリオ部１３３はその処理結果を発側Ｗｅｂサーバ４１に送信する。本実施形態では、発信者が認証されることを前提とする。
【００４７】
ステップＳ２０３では、発信端末３１が音声テキスト化サービスのためのアプリケーションプログラムを起動させて起動信号を発側Ｗｅｂサーバ４１に送信する。起動信号はそのアプリケーションプログラムを実行するためのデータ信号である。
【００４８】
ステップＳ２０４では、発側Ｗｅｂサーバ４１がその起動信号に応答して発側ＡＳ１３にイベント通知を送信する。このイベント通知は発側エンドポイントおよび発側補助セッションＩＤを含む。
【００４９】
ステップＳ２０５では、発側ＡＳ１３のサービスシナリオ部１３３が発側エンドポイントをセッションデータベース１９に登録する。サービスシナリオ部１３３は、発側補助セッションＩＤに対応するセッション情報に発側エンドポイントを書き込む。この登録処理により、現在確立されている呼（セッション）での音声テキストを発側Ｗｅｂサーバ４１経由で発信端末３１に送信することが可能になる。
【００５０】
着側でもステップＳ２０１〜Ｓ２０５と同様の処理が実行される。その同様の処理をステップＳ２１１〜Ｓ２１５として示す。
【００５１】
ステップＳ２１１では、着信端末３２が音声テキスト化サービスのためのアプリケーションプログラムを起動するために接続要求を着側Ｗｅｂサーバ４２に送信する。接続要求は、プッシュ要求により提供された情報の少なくとも一部（例えば、着信端末３２のデバイストークン、および着側補助セッションＩＤ）を含む。
【００５２】
ステップＳ２１２では、着側Ｗｅｂサーバ４２と着側ＡＳ１４のサービスシナリオ部１４３との間で、発信者を認証するための処理が実行される。本実施形態では、着信者も認証されることを前提とする。
【００５３】
ステップＳ２１３では、着信端末３２が音声テキスト化サービスのためのアプリケーションプログラムを起動させて起動信号を着側Ｗｅｂサーバ４２に送信する。
【００５４】
ステップＳ２１４では、着側Ｗｅｂサーバ４２がその起動信号に応答して着側ＡＳ１４にイベント通知を送信する。このイベント通知は着側エンドポイントおよび着側補助セッションＩＤを含む。
【００５５】
ステップＳ２１５では、着側ＡＳ１４のサービスシナリオ部１４３が着側エンドポイントをセッションデータベース１９に登録する。サービスシナリオ部１４３は、着側補助セッションＩＤに対応するレコードに着側エンドポイントを書き込む。この登録処理により、現在確立されている呼（セッション）での音声テキストを着側Ｗｅｂサーバ４２経由で着信端末３２に送信することが可能になる。
【００５６】
発側では、ステップＳ２０５の後にステップＳ２０６，Ｓ２０７が実行される。ステップＳ２０６では、発信端末３１が、発信者が音声テキスト化サービスの利用に同意することを示す同意信号を発側Ｗｅｂサーバ４１に送信する。ステップＳ２０７では、発側Ｗｅｂサーバ４１がその同意信号に応答して発側ＡＳ１３にイベント通知を送信する。このイベント通知は発信者の同意を示す。これらの同意信号およびイベント通知はいずれも発側補助セッションＩＤを含む。
【００５７】
着側では、ステップＳ２１５の後にステップＳ２１６，Ｓ２１７が実行される。ステップＳ２１６では、着信端末３２が、着信者が音声テキスト化サービスの利用に同意することを示す同意信号を着側Ｗｅｂサーバ４２に送信する。ステップＳ２１７では、着側Ｗｅｂサーバ４２がその同意信号に応答して発側ＡＳ１３に向けてイベント通知を送信する。このイベント通知は着信者の同意を示す。これらの同意信号およびイベント通知はいずれも着側補助セッションＩＤを含む。
【００５８】
ステップＳ２０８では、サービスシナリオ部１３３が、ステップＳ２０７，Ｓ２１７での二つのイベント通知に基づいて、確立された呼に対応するセッション情報の認識方向を「双方向」に設定する。具体的には、サービスシナリオ部１３３はセッションデータベース１９にアクセスして、発側または着側の補助セッションＩＤに対応するセッション情報を特定し、このセッション情報の認識方向を「双方向」に設定する。このように、サービスシナリオ部１３３は、発信端末３１および着信端末３２の双方から同意信号が送信されたことに応答して認識方向を「双方向」に設定する。この結果、ステップＳ２２０で示すように、発着側の双方で音声テキスト化サービスが実行される。
【００５９】
次に、図５を参照しながら、音声テキスト化サービスを起動する処理の別の例を処理フローＳ２Ａとして説明する。この例は、通信端末での音声テキスト化サービスの開始のタイミングが発信端末３１と着信端末３２との間で異なる場合を示し、より具体的には、着信端末３２が発信端末３１よりも後に音声テキスト化サービスを開始する場合を示す。
【００６０】
処理フローＳ２Ａでも処理フローＳ２と同様に、発側ではステップＳ２０１〜Ｓ２０７が実行される。音声テキスト化サービスのアプリケーションプログラムの起動に関する処理のタイミングが発側と着側とである程度大きく異なる場合には、発側ではステップＳ２０７の後にステップＳ２０８Ａが実行される。このステップＳ２０８Ａでは、サービスシナリオ部１３３が、ステップＳ２０７でのイベント通知に基づいて、確立された呼に対応するセッション情報（発側補助セッションＩＤに対応するセッション情報）の認識方向を「発側」に設定する。この結果、ステップＳ２２１に示すように、発信端末３１でのみ音声テキスト化サービスが実行される。
【００６１】
ステップＳ２２１の後に、着側でステップＳ２１１〜Ｓ２１７が実行されると、発側ではステップＳ２０８Ｂが実行される。このステップＳ２０８Ｂでは、サービスシナリオ部１３３が、ステップＳ２１７でのイベント通知に基づいて、確立された呼に対応するセッション情報（着側補助セッションＩＤに対応するセッション情報）の認識方向を「発側」から「双方向」に更新する。このように、サービスシナリオ部１３３は、発信端末３１および着信端末３２の双方から同意信号が送信されたことに応答して認識方向を「双方向」に設定する。この結果、ステップＳ２２２で示すように、発着側の双方で音声テキスト化サービスが実行可能になる。ステップＳ２２２は処理フローＳ２におけるステップＳ２２０と同じである。
【００６２】
次に、図６を参照しながら、音声テキストを通信端末上に表示する処理の例を処理フローＳ３として説明する。処理フローＳ３は、発着側の双方で音声テキスト化サービスが実行可能になったこと（すなわち、ステップＳ２２０またはＳ２２２）を前提とする。
【００６３】
ステップＳ３０１〜Ｓ３０９は、着信者の音声（着側音声）をテキストに変換して、その音声テキストを発信端末３１および着信端末３２の双方に表示にする処理を示す。
【００６４】
ステップＳ３０１では、着信端末３２から送信された音声データ（着側音声）が着側ネットワーク２２を介してコアネットワーク１０に送られ、着側ＣＳＣＦ１２、発側ＣＳＣＦ１１、発側ＡＳ１３などの通信制御装置を経由して発側ＭＣＥ１５に送信される。ステップＳ３０２では発側ＭＣＥ１５がその音声データを音声認識エンジン４３に送信する。ステップＳ３０３では、音声認識エンジン４３がその音声データに対して音声認識を実行することで着側音声をテキストに変換し、その音声テキストを発側ＭＣＥ１５に送信する。この音声テキストは着側テキストに相当する。
【００６５】
ステップＳ３０４では、発側ＭＣＥ１５が、その音声テキストと、発話者が誰であるかを示す発話種別とを含む認識結果を発側Ｗｅｂサーバ４１に送信する。音声テキストは着側音声を示すので、このステップで送信される認識結果では、発話種別は着側を示す。ステップＳ３０５では、発側ＭＣＥ１５がその認識結果を着側Ｗｅｂサーバ４２にも送信する。発側ＭＣＥ１５は発側ＡＳ１３を介して現在の呼に対応するセッション情報をセッションデータベース１９から取得する。セッション情報の認識方向が「双方向」であることに応答して、発側ＭＣＥ１５はそのセッション情報から発側エンドポイントおよび着側エンドポイントを取得する。発側ＭＣＥ１５はこれらのエンドポイントにより認識結果の送信先（すなわち、発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２）を取得することができる。このように、発側ＭＣＥ１５は、認識方向が「双方向」であることに応答して着側テキストを発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２の双方に向けて送信する。
【００６６】
ステップＳ３０６では、発側Ｗｅｂサーバ４１が発信端末３１に認識結果を送信する。発側Ｗｅｂサーバ４１は、認識結果に含まれる発話種別が着側であることに基づいて、音声テキストが通話相手のものとして発信端末３１上に表示されるように、音声テキストを含むデータを生成する。
【００６７】
ステップＳ３０７では、発信端末３１がそのデータに基づいて、音声テキストを着信者（通話相手）のものとして画面上に表示する。これにより、発信者は相手が話した内容を視覚的に認識できる。
【００６８】
ステップＳ３０８では、着側Ｗｅｂサーバ４２が着信端末３２に認識結果を送信する。着側Ｗｅｂサーバ４２は、認識結果に含まれる発話種別が着側であることに基づいて、音声テキストが着信者自身のものとして着信端末３２上に表示されるように、音声テキストを含むデータを生成する。
【００６９】
ステップＳ３０９では、着信端末３２がそのデータに基づいて、音声テキストを着信者自身のものとして画面上に表示する。これにより、着信者は自分の発話を視覚的に認識できる。
【００７０】
ステップＳ３１０〜Ｓ３１８は、発信者の音声（発側音声）をテキストに変換して、その音声テキストを発信端末３１および着信端末３２の双方に表示にする処理を示す。
【００７１】
ステップＳ３１０では、発信端末３１から送信された音声データ（発側音声）が発側ネットワーク２１を介してコアネットワーク１０に送られ、発側ＣＳＣＦ１１および発側ＡＳ１３を経由して発側ＭＣＥ１５に送信される。ステップＳ３１１では発側ＭＣＥ１５がその音声データを音声認識エンジン４３に送信する。ステップＳ３１２では、音声認識エンジン４３がその音声データに対して音声認識を実行することで発側音声をテキストに変換し、その音声テキストを発側ＭＣＥ１５に送信する。この音声テキストは発側テキストに相当する。
【００７２】
ステップＳ３１３では、発側ＭＣＥ１５が、その音声テキストと、発話者が誰であるかを示す発話種別とを含む認識結果を発側Ｗｅｂサーバ４１に送信する。音声テキストは発側音声を示すので、このステップで送信される認識結果では、発話種別は発側を示す。ステップＳ３１４では、発側ＭＣＥ１５がその認識結果を着側Ｗｅｂサーバ４２にも送信する。発側ＭＣＥ１５は発側ＡＳ１３を介して、現在の呼に対応するセッション情報をセッションデータベース１９から取得する。セッション情報の認識方向が「双方向」であることに応答して、発側ＭＣＥ１５はそのセッション情報から発側エンドポイントおよび着側エンドポイントを取得し、これにより発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２を特定できる。このように、発側ＭＣＥ１５は、認識方向が「双方向」であることに応答して発側テキストを発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２の双方に向けて送信する。
【００７３】
ステップＳ３１５では、発側Ｗｅｂサーバ４１が発信端末３１に認識結果を送信する。発側Ｗｅｂサーバ４１は、認識結果に含まれる発話種別が発側であることに基づいて、音声テキストが発信者自身のものとして発信端末３１上に表示されるように、音声テキストを含むデータを生成する。
【００７４】
ステップＳ３１６では、発信端末３１がそのデータに基づいて、音声テキストを発信者自身のものとして画面上に表示する。これにより、発信者は自分の発話を視覚的に認識できる。
【００７５】
ステップＳ３１７では、着側Ｗｅｂサーバ４２が着信端末３２に認識結果を送信する。着側Ｗｅｂサーバ４２は、認識結果に含まれる発話種別が発側であることに基づいて、音声テキストが通話相手のものとして着信端末３２上に表示されるように、音声テキストを含むデータを生成する。
【００７６】
ステップＳ３１８では、着信端末３２がそのデータに基づいて、音声テキストを発信者（通話相手）のものとして画面上に表示する。これにより、着信者は相手が話した内容を視覚的に認識できる。
【００７７】
このように、双方のＷｅｂサーバは発話種別に基づいて音声テキストの表示態様を設定する。音声テキストを発話者自身または通話相手のものとして表示する手法は何ら限定されず、任意の手法が採用されてよい。Ｗｅｂサーバは発話種別に応じて音声テキストの表示位置（たとえば、音声テキストの吹き出しの表示位置）を変えてもよい。例えば、Ｗｅｂサーバは、発話者自身の音声テキストが右側（一方の側の一例）に表示され、通話相手の音声テキストが左側（他方の側の一例）に表示されるように表示態様を制御してもよい。あるいは、Ｗｅｂサーバは発話種別に応じて、音声テキストのフォントを変えてもよいし、吹き出しの形状または背景色を変えてもよい。
【００７８】
発話種別に基づく音声テキストの表示態様の設定は発信端末３１および着信端末３２で実行されてもよい。具体的には、発側Ｗｅｂサーバ４１および着側Ｗｅｂサーバ４２のそれぞれが、音声テキストと共に発話種別も、対応する通信端末に送信することで、該通信端末にその発話種別に基づいて音声テキストの表示態様を設定させてもよい。この仕組みによっても、発信端末３１および着信端末３２のそれぞれは、表示位置、フォント、吹き出しの形状または背景色などの表示態様を設定することができる。
【００７９】
本実施形態ではコアネットワーク１０がＩＭＳネットワークであるが、本開示に係る呼制御システムは任意の種類のコアネットワークに適用されてもよい。これに関連して、本開示に係る呼制御システムはＳＩＰ以外の通信プロトコルを用いてもよい。
【００８０】
発側ＡＳ１３に実装される機能要素の少なくとも一部は、発側ＡＳ１３以外の通信制御装置に実装されてもよい。同様に、着側ＡＳ１４に実装される機能要素の少なくとも一部は、着側ＡＳ１４以外の通信制御装置に実装されてもよい。
【００８１】
上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
【００８２】
機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting  unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。
【００８３】
例えば、本開示の一実施の形態における通信制御装置は、本開示の処理を行うコンピュータとして機能してもよい。図７は、その通信制御装置として機能するコンピュータ１００のハードウェア構成の一例を示す図である。コンピュータ１００は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含んでもよい。
【００８４】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。通信制御装置のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【００８５】
通信制御装置における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、メモリ１００２及びストレージ１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
【００８６】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central  Processing  Unit）によって構成されてもよい。
【００８７】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール、データなどを、ストレージ１００３及び通信装置１００４の少なくとも一方からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、通信制御装置の各機能要素は、メモリ１００２に格納され、プロセッサ１００１において動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。
【００８８】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read  Only  Memory）、ＥＰＲＯＭ（Erasable  Programmable  ＲＯＭ）、ＥＥＰＲＯＭ（Electrically  Erasable  Programmable  ＲＯＭ）、ＲＡＭ（Random  Access  Memory）などの少なくとも１つによって構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本開示の一実施の形態に係る方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【００８９】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact  Disc  ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つによって構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及びストレージ１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。
【００９０】
通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency  Division  Duplex）及び時分割複信（ＴＤＤ：Time  Division  Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。
【００９１】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【００９２】
また、プロセッサ１００１、メモリ１００２などの各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
【００９３】
また、コンピュータ１００は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital  Signal  Processor）、ＡＳＩＣ（Application  Specific  Integrated  Circuit）、ＰＬＤ（Programmable  Logic  Device）、ＦＰＧＡ（Field  Programmable  Gate  Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。
【００９４】
以上説明したように、本開示の一側面に係る呼制御システムは、発信端末と着信端末との間で伝送される通話をテキストに変換する音声テキスト化サービスを実行可能である。呼制御システムは、発信端末を利用する発信者と着信端末を利用する着信者との双方が音声テキスト化サービスの利用者である場合に、発信端末に対応する発側メディア処理装置と着信端末に対応する着側メディア処理装置とのうちの一方を共通のメディア処理装置として機能させる制御部を備える。共通のメディア処理装置は、発信者または着信者の音声をテキストに変換する音声認識エンジンと接続する。共通のメディア処理装置は、発信端末から送信された発信者の発側音声を音声認識エンジンに入力することで発側テキストを取得し、発側テキストを発信端末および着信端末の双方に向けて送信する。共通のメディア処理装置は、着信端末から送信された着信者の着側音声を音声認識エンジンに入力することで着側テキストを取得し、着側テキストを発信端末および着信端末の双方に向けて送信する。
【００９５】
このような側面においては、発信者および着信者の双方が音声認識サービスの利用者である場合に、発信者および着信者の双方の音声が共通のメディア処理装置を介してテキストに変換され、そのテキストが発信端末および着信端末の双方に送信される。発側および着側の双方について、共通のメディア処理装置が用いられるので、発側および着側の双方の間で通話内容のテキストを一致させることができる。
【００９６】
また、発側メディア処理装置と着側メディア処理装置の双方を用いるのではなく、そのうちの一方が用いられるので、音声テキスト化サービスを実行するために用いられるハードウェア資源および利用ライセンス数の少なくとも一方を節約することができる。また、音声テキスト化サービスに関連するメッセージ（例えばガイダンス）を、共通のメディア処理装置から発信端末および着信端末の双方に送信することも可能になる。
【００９７】
他の側面に係る呼制御システムでは、制御部が発側メディア処理装置を共通のメディア処理装置として機能させてもよい。或る同一種類の処理が実行されるタイミングは着側よりも発側の方が早い。したがって、発側メディア処理装置を共通のメディア処理装置として用いることで、音声テキスト化サービスに関連する処理を早く開始することができ、その分、音声テキスト化サービスをより早くユーザに提供することが可能になる。
【００９８】
他の側面に係る呼制御システムでは、制御部が、発側メディア処理装置を一意に特定する発側メディア装置ＩＤを着側メディア処理装置に向けて送信し、発側メディア装置ＩＤを受信した着側メディア処理装置から、着側メディア処理装置を一意に特定する着側メディア装置ＩＤを受信し、着側メディア装置ＩＤの受信に応答して、発側メディア処理装置を共通のメディア処理装置として機能させてもよい。発側および着側の双方のメディア処理装置の識別子を取得することで共通のメディア処理装置を確実に機能させることができる。
【００９９】
他の側面に係る呼制御システムでは、発側メディア処理装置が、発側テキストまたは着側テキストを発信端末に送信する発側Ｗｅｂサーバと接続し、着側メディア処理装置が、発側テキストまたは着側テキストを着信端末に送信する着側Ｗｅｂサーバと接続してもよい。呼制御システムは、発側Ｗｅｂサーバを一意に特定する発側エンドポイントと、着側Ｗｅｂサーバを一意に特定する着側エンドポイントとを含むセッション情報を記憶するデータベースをさらに備えてもよい。共通のメディア処理装置は、セッション情報の発側エンドポイントおよび着側エンドポイントを取得し、発側エンドポイントに基づいて、発側テキストまたは着側テキストを発側Ｗｅｂサーバに送信することで、発側テキストまたは着側テキストを発信端末に向けて送信し、着側エンドポイントに基づいて、発側テキストまたは着側テキストを着側Ｗｅｂサーバに送信することで、発側テキストまたは着側テキストを着信端末に向けて送信してもよい。そのエンドポイントを参照することで、テキストを送信すべきＷｅｂサーバを特定することができる。
【０１００】
他の側面に係る呼制御システムでは、制御部が、ユーザが音声テキスト化サービスの利用に同意することを示す同意信号が発信端末および着信端末の双方から送信されたことに応答して、音声テキストをどの通信端末に送信するかを示す認識方向を双方向に設定し、共通のメディア処理装置が、認識方向が双方向であることに応答して、発側テキストまたは着側テキストを発側Ｗｅｂサーバおよび着側Ｗｅｂサーバの双方に向けて送信してもよい。ユーザの同意に応じて認識方向を設定することで、発信者および着信者の双方が音声テキスト化サービスを希望する場合にのみその双方にテキストを送信することが可能になる。
【０１０１】
他の側面に係る呼制御システムでは、共通のメディア処理装置が、発側テキストおよび着側テキストのそれぞれについて、発話者が発信者および着信者のどちらであるかを示す発話種別をさらに発側Ｗｅｂサーバおよび着側Ｗｅｂサーバの双方に送信してもよい。この発話種別がＷｅｂサーバに提供されることで、Ｗｅｂサーバは発話者の種類に応じてテキストを処理することができる。
【０１０２】
他の側面に係る呼制御システムでは、発側Ｗｅｂサーバは、発話種別が発信者を示す場合には、発信端末上で発側テキストが発話者自身の音声テキストとして表示されるように発側テキストの表示態様を設定し、発話種別が着信者を示す場合には、発信端末上で着側テキストが通話相手の音声テキストとして表示されるように着側テキストの表示態様を設定してもよい。着側Ｗｅｂサーバは、発話種別が発信者を示す場合には、着信端末上で発側テキストが通話相手の音声テキストとして表示されるように発側テキストの表示態様を設定し、発話種別が着信者を示す場合には、着信端末上で着側テキストが発話者自身の音声テキストとして表示されるように着側テキストの表示態様を設定してもよい。
【０１０３】
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示態様を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる表示態様で表示し、このことは、音声テキスト化サービスのユーザインタフェースの改善に寄与し得る。
【０１０４】
他の側面に係る呼制御システムでは、発側Ｗｅｂサーバは、発話種別が発信者を示す場合には、発信端末上で発側テキストが発話者自身の音声テキストとして表示されるように発側テキストを発信端末上の第１の側に表示させ、発話種別が着信者を示す場合には、発信端末上で着側テキストが通話相手の音声テキストとして表示されるように着側テキストを発信端末上の第２の側に表示させてもよい。着側Ｗｅｂサーバは、発話種別が発信者を示す場合には、着信端末上で発側テキストが通話相手の音声テキストとして表示されるように発側テキストを着信端末上の第１の側に表示させ、発話種別が着信者を示す場合には、着信端末上で着側テキストが発話者自身の音声テキストとして表示されるように着側テキストを着信端末上の第２の側に表示させてもよい。
【０１０５】
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示位置を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる側に表示するので、発信者および着信者のそれぞれに、自分の発話と相手の発話とを分かり易く示すことができる。
【０１０６】
他の側面に係る呼制御システムでは、発側Ｗｅｂサーバが、発話種別を発側テキストまたは着側テキストと共に発信端末に送信することで、発信端末に発話種別に基づいて発側テキストまたは着側テキストの表示態様を設定させ、着側Ｗｅｂサーバが、発話種別を発側テキストまたは着側テキストと共に着信端末に送信することで、着信端末に発話種別に基づいて発側テキストまたは着側テキストの表示態様を設定させてもよい。
【０１０７】
発側および着側のそれぞれで、発話種別に応じて上記のようにテキストの表示態様を設定することで、通信端末の利用者と発話者との関係に応じてテキストを表示することができる。通信端末は自機のユーザの音声テキストと通話相手の音声テキストとを互いに異なる表示態様で表示し、このことは、音声テキスト化サービスのユーザインタフェースの改善に寄与し得る。
【０１０８】
以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。
【０１０９】
情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink  Control  Information）、ＵＣＩ（Uplink  Control  Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio  Resource  Control）シグナリング、ＭＡＣ（Medium  Access  Control）シグナリング、報知情報（ＭＩＢ（Master  Information  Block）、ＳＩＢ（System  Information  Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC  Connection  Setup）メッセージ、ＲＲＣ接続再構成（RRC  Connection  Reconfiguration）メッセージなどであってもよい。
【０１１０】
本開示において説明した各態様／実施形態は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ（4th  generation  mobile  communication  system）、５Ｇ（5th  generation  mobile  communication  system）、ＦＲＡ（Future  Radio  Access）、ＮＲ（new  Radio）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ（登録商標））、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、ＬＴＥ及びＬＴＥ−Ａの少なくとも一方と５Ｇとの組み合わせ等）適用されてもよい。
【０１１１】
本開示において説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１１２】
本開示において基地局によって行われるとした特定動作は、場合によってはその上位ノード（upper  node）によって行われることもある。基地局を有する１つ又は複数のネットワークノード（network  nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局及び基地局以外の他のネットワークノード（例えば、ＭＭＥ又はＳ−ＧＷなどが考えられるが、これらに限られない）の少なくとも１つによって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥ及びＳ−ＧＷ）であってもよい。
【０１１３】
情報等は、上位レイヤ（又は下位レイヤ）から下位レイヤ（又は上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。
【０１１４】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【０１１５】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【０１１６】
本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１１７】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
【０１１８】
また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital  Subscriber  Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。
【０１１９】
本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１２０】
なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ：Component  Carrier）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。
【０１２１】
本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
【０１２２】
また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。
【０１２３】
上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。
【０１２４】
本開示においては、「基地局（ＢＳ：Base  Station）」、「無線基地局」、「固定局（fixed  station）」、「ＮｏｄｅＢ」、「ｅＮｏｄｅＢ（ｅＮＢ）」、「ｇＮｏｄｅＢ（ｇＮＢ）」、「アクセスポイント（access  point）」、「送信ポイント（transmission  point）」、「受信ポイント（reception  point）、「送受信ポイント（transmission/reception  point）」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。
【０１２５】
基地局は、１つ又は複数（例えば、３つ）のセルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局（ＲＲＨ：Ｒｅｍｏｔｅ  Ｒａｄｉｏ  Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」又は「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部又は全体を指す。
【０１２６】
本開示においては、「移動局（ＭＳ：Mobile  Station）」、「ユーザ端末（user  terminal）」、「ユーザ装置（ＵＥ：User  Equipment）」、「端末」などの用語は、互換的に使用され得る。
【０１２７】
移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。
【０１２８】
基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型又は無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのＩｏＴ（Internet  of  Things）機器であってもよい。
【０１２９】
また、本開示における基地局は、ユーザ端末で読み替えてもよい。例えば、基地局及びユーザ端末間の通信を、複数のユーザ端末間の通信（例えば、Ｄ２Ｄ（Device-to-Device）、Ｖ２Ｘ（Vehicle-to-Everything）などと呼ばれてもよい）に置き換えた構成について、本開示の各態様／実施形態を適用してもよい。この場合、基地局が有する機能をユーザ端末が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言（例えば、「サイド（side）」）で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネルで読み替えられてもよい。
【０１３０】
同様に、本開示におけるユーザ端末は、基地局で読み替えてもよい。この場合、ユーザ端末が有する機能を基地局が有する構成としてもよい。
【０１３１】
本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking  up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。
【０１３２】
「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。
【０１３３】
本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１３４】
本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
【０１３５】
本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。
【０１３６】
本開示において、例えば、英語でのa,  an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。
【０１３７】
本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。
【符号の説明】
【０１３８】
１…呼制御システム、１０…コアネットワーク、１１…発側ＣＳＣＦ、１２…着側ＣＳＣＦ、１３…発側ＡＳ、１４…着側ＡＳ、１５…発側ＭＣＥ（発側メディア処理装置）、１６…着側ＭＣＥ（着側メディア処理装置）、１７…発側ＳＭＳ−ＧＷ、１８…着側ＳＭＳ−ＧＷ、１９…セッションデータベース、２１…発側ネットワーク、２２…着側ネットワーク、３１…発信端末、３２…着信端末、４１…発側Ｗｅｂサーバ、４２…着側Ｗｅｂサーバ、４３…音声認識エンジン、１３１，１４１…サービス制御部、１３２，１４２…セッション制御部、１３３，１４３…サービスシナリオ部。
【図１】
2020088818.tif 000003
【図２】
2020088818.tif 000004
【図３】
2020088818.tif 000005
【図４】
2020088818.tif 000006
【図５】
2020088818.tif 000007
【図６】
2020088818.tif 000008
【図７】
2020088818.tif 000009