JP2015056786A - 制御装置、制御方法及び制御プログラム - Google Patents

Abstract

【課題】着信者のスケジュールに関するプレゼンス情報を発信者へ通知できる制御装置、制御方法及び制御プログラムを提供すること。
【解決手段】ＲＢＴ制御装置１０は、ユーザのスケジュールに基づく第１テキストデータを音声データに変換するテキスト変換部１４と、音声データを、スケジュールの日時条件及びユーザに紐付けられている通話端末４０の識別データと共に記憶するＲＢＴ＿ＤＢ１３と、音声着信通知に応じて着信側の通話端末４０を特定すると、当該通話端末４０に紐付き、かつ、日時条件を満たす音声データを抽出し、発信側の通話端末４０へ送信するＲＢＴ再生部１１と、を備える。
【選択図】図２

Description

本発明は、リングバックトーン（ＲＢＴ）を制御する制御装置、制御方法及び制御プログラムに関する。

音声通話において、着信者のプレゼンス状態を管理し、発信者が着信側のプレゼンス状態を知るためのシステムが実現されている。ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の拡張であるＳＩＭＰＬＥ（ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ）では、このようなプレゼンス状態を管理するための機能が設けられている。また、従来の回線交換システムにおいても、留守番電話といった機能にて同様の作用が実現されている。

ここで，ＳＩＭＰＬＥはＳＩＰベースで構築された交換システム上でのみ有効であるため、既存の回線交換と併用することが難しいといった課題がある。また、留守番電話機能は、発呼からメッセージ再生までの間鳴動し続けるため、利便性が低下するといった課題がある。

これらの課題に対して、発呼中に発信者の耳に流れるＲＢＴにてプレゼンス情報を再生する方法が提案されている。例えば、特許文献１には、電話機に備えられたセンサにより着信者の状態を取得し、この状態を示すテキストデータから音声データを生成してＲＢＴとして発信者に通知するシステムが示されている。

特開２０１１−２５９０７９号公報

しかしながら、特許文献１の方法では、通知できるプレゼンス情報は、センサから取得可能な端末状態に限られるため、通話端末から離れた着信者の状態を発信者へ通知することは難しかった。

本発明は、着信者のスケジュールに関するプレゼンス情報を発信者へ通知できる制御装置、制御方法及び制御プログラムを提供することを目的とする。

本発明に係る制御装置は、ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換部と、前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する第１記憶部と、音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを前記第１記憶部から抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する再生部と、を備える。

前記再生部は、前記音声データを、リングバックトーンと共に、又は当該リングバックトーンに代えて送信してもよい。

前記第１記憶部は、前記スケジュールに基づく第２テキストデータを、前記識別データ及び前記日時条件に紐づけて前記読み上げデータと共に記憶し、前記再生部は、前記第２テキストデータを、さらに前記発信側の通話端末へ送信してもよい。

前記制御装置は、前記発信側の通話端末及び前記着信側の通話端末の組み合わせに対して、前記再生部が送信するデータ種別を特定する種別データを記憶する第２記憶部を備え、前記再生部は、前記種別データに基づいて、前記発信側の通話端末への送信の有無を決定してもよい。

前記第１記憶部は、前記第１テキストデータに基づく読み上げデータを複数種類記憶し、前記再生部は、前記種別データに基づいて、前記発信側の通話端末へ送信する音声データの種類を決定してもよい。

前記制御装置は、通信端末間の架電を制御する複数の中継機器とネットワークを介して接続されてもよい。

本発明に係る制御方法は、ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換ステップと、前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する記憶ステップと、音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する送信ステップと、をコンピュータが実行する。

本発明に係る制御プログラムは、ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換ステップと、前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する記憶ステップと、音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する送信ステップと、をコンピュータに実行させる。

本発明によれば、着信者のスケジュールに関するプレゼンス情報を発信者へ通知できる。

第１実施形態に係るＲＢＴ制御システムの構成例を示す図である。 第１実施形態に係るＲＢＴ制御装置の機能構成を示す図である。 第１実施形態に係るスケジュールサーバの機能構成を示す図である。 第１実施形態に係るスケジュール登録画面の例を示す図である。 第１実施形態に係る登録処理を示すシーケンス図である。 第１実施形態に係る再生処理を示すシーケンス図である。 第２実施形態に係るＲＢＴ制御システムの構成例を示す図である。

［第１実施形態］
以下、本発明の第１実施形態について説明する。
本実施形態のＲＢＴ制御システム１は、音声発呼時のＲＢＴにおいて、着信側のスケジュール情報と動的に連動して再生音声を変換するシステムである。

図１は、本実施形態に係るＲＢＴ制御システム１の構成例を示す図である。
ＲＢＴ制御システム１は、ＲＢＴ制御装置１０と、スケジュールサーバ２０と、ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）３０と、通話端末４０とを備える。

ＲＢＴ制御装置１０及びスケジュールサーバ２０は、ＩＰネットワーク２を介して接続される。ＩＰネットワーク２は，ＩＰネットワーク２に接続されている装置から送信される情報の有線又は無線の伝送路である。例えば、ＩＰネットワーク２は、インターネット、衛星通信網等の公衆回線網、あるいはＥｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を含んでもよい。また、ＩＰネットワーク２は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等の専用回線網を含んでもよい。

通話端末４０は、電話４０Ａ、モバイル端末４０Ｂ、ＩＰ電話４０Ｃ、ＩＰモバイル端末４０Ｄ等を含む。
ＰＢＸ３０、電話４０Ａ群及びモバイル端末４０Ｂ群は、回線交換網３を介して接続される。回線交換網３は、ネットワークに接続されている装置から送信される情報の有線又は無線の伝送路である。例えば、回線交換網３は、電話回線又は携帯電話回線等の公衆回線網を含んでもよい。また、回線交換網３は、警察電話網若しくは鉄道電話網等の専用電話回線、又はオフィス用の内線電話回線等を含んでもよい。
さらに、ゲートウェイ５０、ＳＩＰサーバ６０、ＩＰ電話４０Ｃ群、及びＩＰモバイル端末４０Ｄ群と無線通信するＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）は、ＩＰネットワーク２を介して接続される。

これら電話４０Ａ，モバイル端末４０Ｂ，ＩＰ電話４０Ｃ及びＩＰモバイル端末４０Ｄは、ネットワーク通信機能及び通話機能を有する。例えば、モバイル端末４０Ｂは通話機能によりネットワーク越しのＩＰモバイル端末４０Ｄに対して発呼を行い、相手が呼に応じることで通話を実施することができる。
なお、通話端末４０の一例として電話（４０Ａ、４０Ｃ）又はモバイル端末（４０Ｂ、４０Ｄ）を示しているが、ユーザが使用する通話端末４０は上記の例に限定されない。例えば、通話端末４０は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、家庭用ゲーム機、家電機器等の情報処理装置であってもよい。また、通話端末４０は、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）、携帯用音楽再生装置、携帯用映像処理装置、携帯ゲーム機等の携帯端末であってもよい。

ＰＢＸ３０は、複数の構内通話端末を公衆電話回線網に接続して使用するための中継機能を有する。例えば、ＰＢＸ３０は、回線切り替え機、内線集約装置、内線交換機、加入者系呼制御装置、中継系呼制御装置を含んでもよい。ＰＢＸ３０は、電話４０Ａ、モバイル端末４０Ｂ、ＩＰ電話４０Ｃ及びＩＰモバイル端末４０Ｄの間における呼制御を行い、各端末間での通話を可能とする。なお、通話サービスの規模によっては、ＰＢＸ３０は複数存在してもよい。

ゲートウェイ５０は，回線交換用通話端末とＩＰ通話端末とを相互接続するための機能を有し、回線交換網３内の通話端末（４０Ａ、４０Ｂ）とＩＰネットワーク２内の通話端末（４０Ｃ、４０Ｄ）との間での通話を可能とする。ゲートウェイ５０は、相互接続用関門交換機を含んでもよい。

本構成例において、ＰＢＸ３０とＲＢＴ制御装置１０とは、直接的に接続される構成となっているが、ＰＢＸ３０とＲＢＴ制御装置１０とは、ＩＰネットワーク２を介して接続されてもよい。

図２は、本実施形態に係るＲＢＴ制御装置１０の機能構成を示す図である。
ＲＢＴ制御装置１０は、ＲＢＴ再生部１１（再生部）と、ＲＢＴ管理部１２と、ＲＢＴ＿ＤＢ（データベース）１３（第１記憶部）と、テキスト変換部１４（変換部）と、テキスト登録部１５とを備える。ＲＢＴ制御装置１０の各機能ブロックは、バスを介して接続されている。

ＲＢＴ再生部１１は、着信側のＰＢＸ３０とのインタフェースを持ち、音声データを再生する機能を有する。ＲＢＴ再生部１１は、着呼の際にＰＢＸ３０からユーザＩＤ（例えば、電話番号）を受信して着信側の通話端末４０を特定すると、このユーザＩＤに対応付けられ、かつ、鳴動条件を満たしている音声データをＲＢＴ＿ＤＢ１３から読み出す。ＲＢＴ再生部１１は、読み出した音声データを、通常の呼び出し音であるＲＢＴと共に、又はＲＢＴに代えて再生すべく発信側の通話端末４０へ送信する。

ＲＢＴ管理部１２は，ＰＢＸ３０とのインタフェースを持ち、通話端末４０とユーザＩＤとを対応付ける機能を有する。ＲＢＴ管理部１２は、発呼の際にＰＢＸ３０から受信した発信機情報から対応付けられたユーザＩＤを呼び出す。発信側のＰＢＸ３０と受信側のＰＢＸ３０とが等しい場合には、ＲＢＴ再生部１１により、受信されたユーザＩＤからそれに紐付く音声データの検索を実施する。発信側のＰＢＸ３０と受信側のＰＢＸ３０とが異なる場合には、ユーザＩＤを発信側のＰＢＸ３０から受信側のＰＢＸ３０へと渡す。

ＲＢＴ＿ＤＢ１３は、テキスト変換部１４により変換された音声データが登録される記憶媒体である。例えば、ＲＢＴ＿ＤＢ１３には、ユーザＩＤ（通話端末４０の識別データ）に対応付けて、ユーザのスケジュールの日時条件を含む鳴動条件、及びスケジュールに基づく音声データ等が登録される。

テキスト変換部１４は、テキストデータを読み込み、音声データに変換する機能を有する。テキスト変換部１４は、テキスト登録部１５から受信したユーザのスケジュールに基づくテキストデータ（第１テキストデータ）を音声データに変換し、テキスト登録部１５へ返す。

テキスト登録部１５は、ＩＰネットワーク２とのインタフェースを持ち、ＩＰネットワーク２を介してスケジュールサーバ２０と接続する。テキスト登録部１５は、スケジュールサーバ２０上で管理されるアカウントＩＤとユーザＩＤとを対応付ける機能、及び音声データをＲＢＴ＿ＤＢ１３へ保存する機能を有する。テキスト登録部１５は、スケジュールサーバ２０からスケジュール情報を受信すると、このスケジュール情報の中のテキストデータを、テキスト変換部１４へ転送する。テキスト登録部１５は、テキスト変換部１４での変換処理後、音声データを受信すると、音声データ及び鳴動条件をユーザＩＤと対応付けてＲＢＴ＿ＤＢ１３へ登録する。

図３は、本実施形態に係るスケジュールサーバ２０の機能構成を示す図である。
スケジュールサーバ２０は、アプリケーション部２１と、スケジュール登録部２２と、ＲＢＴ登録部２３とを備える。スケジュールサーバ２０の各機能ブロックは、バスを介して接続されている。

アプリケーション部２１は、スケジュールサーバ２０がスケジューラとして機能するための機能群を有する。例えば、機能群には、スケジュール表示機能、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）機能、カレンダー機能、アドレス帳機能、メモ機能、施設予約機能、電子ファイル保持機能、アカウント管理機能、認証機能等が含まれてもよい。

スケジュール登録部２２は、スケジュールに関わる情報をスケジューラに登録する機能を有する。登録される情報は、例えば、日時、用件、行き先、繰り返し条件、登録者、登録日、公開範囲、ＲＢＴを変更するか否か、ＲＢＴ用テキストデータ等を含む。スケジュール登録部２２は、利用者のスケジュール登録要求に従い、アプリケーション部２１に対してスケジュールの登録処理を実行させる。登録するスケジュールをＲＢＴに反映したい場合には、アプリケーション部２１を経由して、登録要求がＲＢＴ登録部２３へ送信される。

ＲＢＴ登録部２３は，ＲＢＴ制御装置１０とのインタフェースを持ち、ＩＰネットワーク２を介してＲＢＴ制御装置１０と接続する。ＲＢＴ登録部２３は、アプリケーション部２１からＲＢＴの登録要求を受信した際に、スケジュールの登録内容からテキストデータを生成し、日時情報及びアカウントＩＤと共に、ＲＢＴ制御装置１０内のテキスト登録部１５へ送信する。

図４は、本実施形態に係るスケジュール登録部２２により表示されるスケジュール登録画面の例を示す図である。
ＵＩ画面にはスケジューラに登録される時刻、行き先、用件、繰り返し条件、ＲＢＴを変更するか否か、ＲＢＴ用テキストデータ等の情報が表示されている。スケジュール登録部２２は、この登録ページを表示し、空欄及びチェックボックスに情報が入力された後に送信ボタンが押されたことに応じて、アプリケーション部２１により当該情報をスケジューラに登録させる。

また、「ＲＢＴを変更するか否か」の項目では、ブール代数（「ｔｒｕｅ」又は「ｆａｌｓｅ」）を選択することができる。利用者は本項目にて「ｔｒｕｅ」（Ｙｅｓのチェックボックス）を選択することで、ＲＢＴ制御装置１０により音声データ及び鳴動条件を生成することができる。

ＲＢＴ制御装置１０に登録される鳴動条件は、例えば、項目に該当する具体的な情報が、数値であれば演算子等を用いて、文字列であれば定数（””で囲んだ文字列）に変換して、それぞれ記述される。変換された要素は、項目の並び順の通りにカンマで結合され、条件式を構成する。
例えば、「ＲＢＴ用テキストデータ」の項目では、「西３Ｆ会議室にて打ち合わせ」が入力されている。このテキストデータがダブルコーテーションにより定数に変換され、条件式の要素を構成する。また、「ＲＢＴ用テキストデータ」が省略された場合には、条件式の要素は「””」となり、「時刻」、「行き先」及び「用件」の項目からＲＢＴ用テキストデータが動的に生成される。

「時刻」、「行き先」、「用件」の項目でも同様である。例えば、「時刻」項目に「１４：００」及び「１８：００」がそれぞれ入力されている。これらは、時間範囲演算子（［ｆｒｏｍ，ｔｏ］）を用いて、例えば「［１４００，１８００］」と表現される。

「条件」の項目では、登録するスケジュールの月日単位での範囲が指定される。範囲は、月単位、日単位及び曜日単位にてそれぞれ指定することができる。また、ハイフンを用いることで連続的な範囲を指定すること、及びワイルドカード「＊」により周期的な範囲を指定することができる。
例えば、「月」の項目に「７」が、「日」の項目に「６−９」が、「週」の項目に「＊」がそれぞれ入力されている。これらは、「７月の６日から９日までの間で毎曜日」を示す。このように、利用者は、一度きりのスケジュールの場合には、当該項目で固定数値を指定し、連続的に指定する場合には数値の間をハイフンで埋める、又はワイルドカードを用いて周期的に指定できる。

これらのルールに従って、スケジュールデータから鳴動条件は、例えば「”西３Ｆ会議室にて打ち合わせ”，［１４００，１８００］，”西３Ｆ会議室”，”打ち合わせ”，７，６−９，＊」のように生成される。

次に、ＲＢＴ制御システム１における処理の流れについて説明する。
図５は、本実施形態に係るＲＢＴ制御装置１０が音声データを記憶するための登録処理を示すシーケンス図である。

まず、利用者がスケジュール登録を行うと、スケジュール登録部２２からアプリケーション部２１へスケジュールの登録要求が送信される（ステップＳ１）。
このスケジュール登録要求を受けて、アプリケーション部２１は、スケジュールの登録処理を実行する（ステップＳ２）。ここで、通常のスケジュール登録の場合には、登録応答がスケジュール登録部２２に返信されることで処理が終了する。一方、スケジュール登録と連動して、ＲＢＴの登録が希望された場合には、以下のステップが実行される。

アプリケーション部２１は、ＲＢＴ登録要求を受けて、ＲＢＴ登録部２３に対してこのＲＢＴ登録要求を転送する（ステップＳ３）。この際、アカウントＩＤ、及び日時等、少なくともスケジュール情報の一部をＲＢＴ登録部２３へ送信する。このとき送信される情報には、少なくともアカウントＩＤ及び日時が含まれる。ＲＢＴ用テキストデータが存在すれば、これも一緒に送信されるが、存在しない場合には、用件及び行き先等のスケジュール情報が送信される。

ＲＢＴ登録部２３は、アプリケーション部２１から受信したスケジュール情報から、ＲＢＴの代替又は重畳される音源となるテキストデータを生成する（ステップＳ４）。ＲＢＴ用テキストデータが存在すれば、ＲＢＴ登録部２３は、このＲＢＴ用テキストデータをそのまま、あるいは更に日時情報（例えば、「１４時から１８時まで」）等を加えてテキストデータとして用い、存在しなければ、日時、要件、行き先等からテキストデータを生成する。ＲＢＴ登録部２３は、生成したテキストデータを、アカウントＩＤ及び日時情報と共に、ＩＰネットワーク２を介してＲＢＴ制御装置１０内のテキスト登録部１５へ送信する（ステップＳ５）。

テキスト登録部１５は、テキストデータを音声データに変換するために、テキストデータをテキスト変換部１４へ送信する（ステップＳ６）。テキスト変換部１４は、受け取ったテキストデータを音声データに変換し（ステップＳ７）、テキスト登録部１５へ提供する（ステップＳ８）。
続いて、テキスト登録部１５は、前述のように、日時情報を用いて、鳴動条件の生成処理を実行する（ステップＳ９）。

テキスト登録部１５は、アカウントＩＤに紐付くユーザＩＤを取得した後、ユーザＩＤ、鳴動条件及び音声データと共に、ＲＢＴ＿ＤＢ１３へ保存要求を送信する（ステップＳ１０）。
そして、ＲＢＴ＿ＤＢ１３においてユーザＩＤに紐付けて、鳴動条件及び音声データの保存処理が行われると（ステップＳ１１）、処理応答がテキスト登録部１５へ、続いてＲＢＴ登録部２３、アプリケーション部２１、スケジュール登録部２２へ順次返信され（ステップＳ１２〜Ｓ１５）、処理が終了する。

図６は、本実施形態に係るＲＢＴの再生処理を示すシーケンス図である。
まず、発信機（発信者側の通話端末４０）が着信機（着信者側の通話端末４０）と通話することを目的として、ＰＢＸ３０に対して呼接続要求を送信する（ステップＳ２１）。ここで、ＰＢＸ３０は複数存在し、発信側と着信側とで利用するＰＢＸ３０が異なることとする。

発信側ＰＢＸ３０は、発信機からの呼接続要求を受けて、発信機のユーザＩＤを識別するためにＲＢＴ管理部１２へユーザＩＤの取得要求を送信する（ステップＳ２２）。ＲＢＴ管理部１２は、呼接続要求に含まれる発信機器情報から、それに紐付いたユーザＩＤを呼び出し、発信側ＰＢＸ３０へ返す（ステップＳ２３）。

発信側ＰＢＸ３０は、ＲＢＴ管理部１２からユーザＩＤを受けて、新たにユーザＩＤを付与した呼接続要求を着信側ＰＢＸ３０へ転送し（ステップＳ２４）、着信側ＰＢＸ３０から応答を受ける（ステップＳ２５）。
着信側ＰＢＸ３０は、該当する着信機に対して呼び出しを行う（ステップＳ２６）。着信側ＰＢＸ３０は、着信機から応答信号を取得すると（ステップＳ２７）、着信機を鳴動させると共に（ステップＳ２８）、ＲＢＴ再生部１１に対して接続要求を行い（ステップＳ２９）、応答を受ける（ステップＳ３０）。

ＲＢＴ再生部１１は，接続要求を受けて、着信機のユーザＩＤに対応する音声データをＲＢＴ＿ＤＢ１３より読み出す（ステップＳ３１〜Ｓ３２）。発信機が着信機を呼び出している状態において、ＲＢＴ再生部１１は、読みだした音声データを発信機のＲＢＴとして再生する（ステップＳ３３）。

着信者が鳴動している着信機に反応して呼を解放すると（ステップＳ３４）、ＲＢＴ再生部１１から着信機、発信側ＰＢＸ３０、発信機と順に応答し（ステップＳ３５〜Ｓ３７）、発信機と着信機との間で通話セッションが確立される（ステップＳ３８）。
通話セッションは、発信機又は着信機のいずれか（この例では発信機）からの呼解放により終了する。例えば、この例の場合、発信機から発信側ＰＢＸ３０、着信側ＰＢＸ３０、着信機へ呼解放信号がリレーし（ステップＳ３９〜Ｓ４１）、通話関する一連の処理が終了する。

本実施形態によれば、ＲＢＴ制御装置１０は、発信機から着信機の通話呼び出し中に、着信者のスケジュールから変換された音声データをＲＢＴとして発信機で再生させるので、着信者のスケジュールに関するプレゼンス情報を発信者へ即座に通知できる。
さらに、音声データは、発信者に対する通常のＲＢＴに代えて、又は重畳して再生されるので、ＲＢＴ制御装置１０は、発信者に応じて適宜、スケジュールの通知方法を切り替えられる。
この結果、発信者へ通知されるプレゼンス情報の幅が広がり、利便性が向上する。

ＲＢＴとして再生される音声データは、着信者の設定したスケジュールに関わる情報であるため、発信者は、着信機を鳴動させて呼び出している最中に、着信者の現在の状況を把握することができる。したがって、例えば、着信者が応答できない状況下において無駄に鳴動させることなく呼を切断することが可能となる。また、発信者は、着信者の状況が把握できるため、切断後に再度発信したり、着信者のスケジュールを確認したりする等の手間が削減される。

ＲＢＴ制御システム１は、既存の回線交換システム上で実現可能であるため、ＳＩＰに対応していない従来の通話端末４０においても、発信者は、着信者のスケジュール情報を即座に、かつ、容易に知ることができる。

なお、本実施形態では、ＲＢＴ制御装置１０がＰＢＸ３０と直接に接続される構成を例に説明したが、ＲＢＴ制御装置１０の配置は、これには限られない。例えば、ＲＢＴ制御装置１０は、ＩＰネットワーク２を介してＰＢＸ３０と接続されてもよい。
また、回線交換網３内の通話端末４０がなくＰＢＸ３０が使用されない場合、ＲＢＴ制御装置１０は、ＩＰネットワーク２を介してＳＩＰサーバ６０からユーザＩＤ等の各種情報を取得してもよい。

［第２実施形態］
以下、本発明の第２実施形態について説明する。
近年、架電機能をＷｅｂから制御することが可能となっている。例えば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用してアクセス可能な架電ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍａｂｌｅ Ｉｎｔｅｒｆａｃｅ）がある。このＡＰＩを用いることで、ソフトウェア開発者が自社のＷｅｂサービスＡＰＩを利用して、通話又はテキストメッセージの送受信に関わる処理プログラムすることが可能となる。
本実施形態では、このような架電ＡＰＩが利用される。

図７は、本実施形態に係るＲＢＴ制御システム１ａの構成例を示す図である。
ＲＢＴ制御システム１ａは、第１実施形態と異なり、ＲＢＴ制御装置１０がＩＰネットワーク２を介してＰＢＸ３０と接続する。呼制御機能がＨＴＴＰアクセス可能であるため、この構成によりＲＢＴ制御装置１０のＰＢＸ３０への依存度が低くなる。

さらに、ＲＢＴ制御システム１ａは、架電制御装置８０を備える。ＲＢＴ制御装置１０、スケジュールサーバ２０及び架電制御装置８０は、ＩＰネットワーク２を介してそれぞれ接続される。

架電制御装置８０は、Ｗｅｂを介して呼を制御する機能を有し、第三者に対してこの機能を公開する。この機能は、例えば、Ｔｗｉｌｉｏ（登録商標）のようにＲＥＳＴ形式を用いて架電ＡＰＩとして公開するものであってもよいし、ＳＯＡＰ形式を用いて公開するものであってもよい。このような架電ＡＰＩにより、架電制御装置８０は、ＩＰネットワーク２上に公開されたＷｅｂリソースから通話端末４０への通信を可能にする。
また、架電制御装置８０は、通話端末４０を、架電制御装置８０がＩＰネットワーク２上に公開したＷｅｂリソースへ接続させるための機能を有する。架電制御装置８０は、例えば、Ｗｅｂリソースに対して仮想電話番号を発行し、この番号に対する発着信を通話端末４０に紐付ける。これにより、通話端末４０からＷｅｂリソースへの通信を可能にする。

以上、本発明の実施形態について説明したが、本発明は前述した実施形態に限るものではない。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

ＲＢＴ＿ＤＢ１３は、スケジュールに基づく第２テキストデータを、ユーザＩＤ及び鳴動条件に紐づけて音声データと共に記憶してもよい。第２テキストデータは、前述の音声データに変換される前の第１のテキストデータと同一であってもよいし、より詳細なスケジュールを示すデータであってもよい。この場合、ＲＢＴ再生部１１は、音声データと共に、又は音声データの代わりに、第２テキストデータを、発信側の通話端末４０へ送信する。
これにより、ＲＢＴ制御装置１０は、テキストの表示機能を有する通話端末４０に対して、音声に加えてテキストにより着信者のプレゼンス情報を通知できる。

また、ＲＢＴ＿ＤＢ１３は、発信側の通話端末４０及び着信側の通話端末４０の組み合わせに対して、ＲＢＴ制御装置１０が送信するデータ種別を特定する種別データを記憶してもよい（第２記憶部）。この場合、ＲＢＴ再生部１１は、種別データに基づいて、発信側の通話端末４０への送信の有無を決定する。
これにより、ＲＢＴ制御装置１０は、例えば、テキスト表示機能のない通話端末４０へは音声データのみを、表示機能のある通話端末４０へは音声データ及びテキストデータを送信したり、音声又はテキストのいずれかを送信すべきでない相手又はグループに対して送信を制限したり、通知情報を適宜設定できる。

さらに、ＲＢＴ＿ＤＢ１３は、スケジュールに基づく音声データ又はテキストデータを複数種類記憶してもよい。この場合、ＲＢＴ再生部１１は、前述の通話端末４０の組み合わせに対して設定された種別データに基づいて、発信側の通話端末４０への送信する音声データ又はテキストデータの種類を決定する。
これにより、ＲＢＴ制御装置１０は、例えば、グループ内に向けてはグループ外に向けたＲＢＴに比べてより詳細なスケジュールを通知できる。また、ＲＢＴ制御装置１０は、内線に対してはスケジュールに基づく音声データで通知し、外線に対しては従来のＲＢＴで通知してもよい。

また、ＲＢＴ制御装置１０は、ＳＩＰサーバ６０が有するプレゼンス情報等を受信し、音声又はテキストデータとして更に送信してもよい。これにより、ＲＢＴ制御装置１０は、ＳＩＰに対応していない通話端末４０に対して、より多くの情報を提供できる。

ＲＢＴ制御装置１０は、ＲＢＴとして再生すべきテキストを音声データに変換した後に、変換後の音声データをＲＢＴ＿ＤＢ１３に記憶することとしたが、これには限られない。音声データに変換される前のテキストデータ、又は変換後の音声データのいずれか一方を、読み上げデータとして記憶してもよい。読み上げデータとしてテキストデータが記憶された場合には、ＲＢＴ再生部１１によりテキストデータが抽出された後に、テキスト変換部１４により音声データに変換される。

前述の実施形態においてシステム構成を例示したが、通話端末４０が接続されるネットワーク構成、並びにネットワーク内のＲＢＴ制御装置１０及びスケジュールサーバ２０の配置は、これらには限られない。ＲＢＴ制御装置１０とスケジュールサーバ２０とは、互いに通信可能に接続され、かつ、ＲＢＴ制御装置１０は、発呼に応じて発信機及び着信機を特定して音声データ又はテキストデータを発信機へ送信可能な構成であればよい。

ＲＢＴ制御装置１０による制御方法は、ソフトウェアにより実現される。ソフトウェアによって実現される場合には、このソフトウェアを構成するプログラムが、情報処理装置（コンピュータ）にインストールされる。また、これらのプログラムは、ＣＤ−ＲＯＭのようなリムーバブルメディアに記録されてユーザに配布されてもよいし、ネットワークを介してユーザのコンピュータにダウンロードされることにより配布されてもよい。

１、１ａ ＲＢＴ制御システム
２ ＩＰネットワーク
３ 回線交換網
１０ ＲＢＴ制御装置
１１ ＲＢＴ再生部
１２ ＲＢＴ管理部
１３ ＲＢＴ＿ＤＢ
１４ テキスト変換部
１５ テキスト登録部
２０ スケジュールサーバ
２１ アプリケーション部
２２ スケジュール登録部
２３ ＲＢＴ登録部
３０ ＰＢＸ
４０ 通話端末
５０ ゲートウェイ
６０ ＳＩＰサーバ
８０ 架電制御装置

Claims (8)

1. ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換部と、
   前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する第１記憶部と、
   音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを前記第１記憶部から抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する再生部と、を備える制御装置。
2. 前記再生部は、前記音声データを、リングバックトーンと共に、又は当該リングバックトーンに代えて送信する請求項１に記載の制御装置。
3. 前記第１記憶部は、前記スケジュールに基づく第２テキストデータを、前記識別データ及び前記日時条件に紐づけて前記読み上げデータと共に記憶し、
   前記再生部は、前記第２テキストデータを、さらに前記発信側の通話端末へ送信する請求項１又は請求項２に記載の制御装置。
4. 前記発信側の通話端末及び前記着信側の通話端末の組み合わせに対して、前記再生部が送信するデータ種別を特定する種別データを記憶する第２記憶部を備え、
   前記再生部は、前記種別データに基づいて、前記発信側の通話端末への送信の有無を決定する請求項１から請求項３のいずれかに記載の制御装置。
5. 前記第１記憶部は、前記第１テキストデータに基づく読み上げデータを複数種類記憶し、
   前記再生部は、前記種別データに基づいて、前記発信側の通話端末へ送信する音声データの種類を決定する請求項４に記載の制御装置。
6. 通信端末間の架電を制御する複数の中継機器とネットワークを介して接続される請求項１から請求項５のいずれかに記載の制御装置。
7. ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換ステップと、
   前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する記憶ステップと、
   音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する送信ステップと、をコンピュータが実行する制御方法。
8. ユーザのスケジュールに基づく第１テキストデータを音声データに変換する変換ステップと、
   前記第１テキストデータ又は前記音声データを含む読み上げデータを、前記スケジュールの日時条件及び前記ユーザに紐付けられている通話端末の識別データと共に記憶する記憶ステップと、
   音声着信通知に応じて着信側の通話端末を特定すると、当該通話端末に紐付き、かつ、日時条件を満たす読み上げデータを抽出し、当該読み上げデータから変換された音声データを発信側の通話端末へ送信する送信ステップと、をコンピュータに実行させるための制御プログラム。

Images