パケット通信ネットワークで音声メッセージをテキストメッセージの形式でダビングする方法
本発明は、テキストメッセージの形式で音声メッセージをダビングする方法に関する。前記メッセージは、音声メッセージを送信するために送信プロトコルを使用するチャネルが使用されるパケットモードディジタルデータ送信ネットワークを介して、音声サービス構成要素が端末に送信する。本発明によると、送信制御プロトコルは、前記送信プロトコルに関連付けるとともに、テキストメッセージを、前記送信制御プロトコルを使用するチャネル内で前記端末に送信する。本発明は、パケット交換通信ネットワーク上の対話型通信に好適である。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は、テキストメッセージの形式で音声メッセージをダビングする方法に関する。
【０００２】
本発明は、固定線または無線パケット交換通信ネットワーク上の対話型音声通信の分野、またはより一般的には、パケットモードでディジタルデータを送信する任意のネットワークに、特に好ましい応用を見出す。
【０００３】
この分野には、「Ａｕｄｉｏｔｅｌ」の拡張、または、例えば、ＶｏＩＰ電話のようなディジタル電話の交換電話ネットワークで公知の同様サービスを代表する会話型音声応答機のような、ユーザの要求により情報を供給する自動サービスが存在する。
【０００４】
それにもかかわらず、本発明は、明白に特定された数を介して、直接にアクセス可能である音声サーバと、ユーザの端末との間の交換のみに限定されるのではなく、音声サーバによって初期化された通信システムを介してユーザが転送可能な音声サービス構成要素の交換に対して同様に拡張することを指摘すべきである。
【０００５】
本発明の目的は、音声サービス構成要素で送信される音声メッセージを、テキストメッセージの形式でコピー可能にすることであり、前記テキストメッセージは、通常音声メッセージの受信と同時に、ユーザの端末のディスプレイ上に現れるテキストミニメッセージである。前記端末は、任意の形式でもよいが、ハンズフリー機能を具備する端末、ビデオフォン端末等、及びより一般には、ユーザがテキストメッセージを読むのと同一の時間に音声メッセージを聞くことを可能にする端末に、本発明は好ましい応用を見出すことを理解する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＶｏＩＰ通信の分野では、例えば、テキストメッセージ及び関連付けた音声メッセージを同時に表示する問題に適用可能である方法が公知である。
【０００７】
第１ソリューションは、呼を設定する場合に、テキストデータを送信するための追加メディアチャネルを交渉することである。リアルタイム転送するプロトコル（ＲＴＰ-ＲＦＣ３３５０）の環境では、テキストデータは、ドキュメント「ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒ Ｔｅｘｔ Ｃｏｎｖｅｒｓａｔｉｏｎ」（ＲＦＣ−２７９３）で定義された標準ペイロードに適合可能である。
【０００８】
第２ソリューションは、信号経路にテキストデータを挿入することで、信号プロトコルのデータ搬送が可能であることを使用することである。セッション開始プロトコル（ＳＩＰ）に適用可能であるこの技術の１つの実施例は、米国特許第６，７５７，７３２号で説明されている。
【０００９】
しかしながら、それらの公知のダビング方法は、多くの欠点を具備する。
【００１０】
テキストデータを搬送する追加メディアストリームを生成するソリューションでは、種々の送信形式のために複数のデータセッションを管理可能にするための端末及び音声サービス構成要素が要求される。さらに、メディアストリームを１つのみ通過させる代わりに、２つのメディアストリーム通過を許可するように、ファイアウォールのようなネットワーク構成要素を構成する必要がある。最後に、関連付けた音声メッセージが表示されるのと同一の時間にテキストコピーを表示するために、同期化手段を構成する必要がある。このことは、主メッセージを構成する音声サンプルに関連するタイムスタンプのような時間情報と関連付けて、音声サービス構成要素内にテキストデータを格納することを要求しうる。
【００１１】
第２ソリューションでは、必然的に、テキストデータを信号経路で搬送するとともに、このようにして、呼設定メッセージでネットワーク内に設定した経路を辿る必要がある。アーキテクチャの観点からは、呼の管理を扱う信号それ自体を、呼のコンテンツ、即ちテキストデータそれ自体と混合することに留意する。このことは、このソリューションが比較的複雑であることを自然に示唆する。何故ならば、このソリューションは、同一の状態オートマトン内でコンテンツと管理アクションとを混合するからである。さらに、この方法は、選択された信号プロトコル（Ｈ．３２３，ＳＩＰ，ＭＧＣＰ等）に密接に依存しているとともに、従って、１つの信号形式に従う実施は、他の信号形式に拡張することは不可能である。最後に、メディアデータは信号装置を通過しないので、メディアデータは、より直接的な経路をとるため、必然的にメッセージ表示の同期化問題につながる、テキストと音声データとの間に変動する搬送遅延時間に関する問題が予想されることも強調すべきである。
【課題を解決するための手段】
【００１２】
このように、本発明によって解決する技術的問題は、テキストメッセージの形式で音声メッセージをダビングする方法を提案することであり、前記メッセージは、音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用するパケットモードディジタルデータ送信ネットワーク上で音声サービス構成要素を介して、端末に送信する。この方法は実際に、テキストメッセージを搬送する信号経路の仕様を越える使用を回避するとともに、またテキストメッセージのみに対する専用の追加メディアストリームの開始を回避する。
【００１３】
本発明によると、上記の技術的問題に対するソリューションでは、送信制御プロトコルが前記送信プロトコルに関連付けられ、前記送信制御チャネル上で、前記テキストメッセージを端末に送信する。
【００１４】
従って、本発明の方法では、新規メディアストリームチャネルを開始する必要なくテキストメッセージを転送し、テキストメッセージは、音声メッセージと同一の経路を使用し、特に、この追加チャネルの通過を許可するようなファイアウォールの再構成を回避することが明白である。さらに、本発明が提案するソリューションは、使用される信号プロトコルに非依存であるとともに、１つの信号プロトコルからもう１つの信号プロトコルに切り換えることすら可能である。
【００１５】
本発明によると、前記通信プロトコルは、データパケットの形式で、前記データパケットのタイムスタンプを伴って、ディジタルストリームを搬送するように設計された、リアルタイムトランスポートプロトコル（ＲＴＰ）である。ＲＴＰ送信チャネルが設定された場合に、リアルタイム搬送制御プロトコル（ＲＴＣＰ）である送信制御プロトコルを搬送するための第２チャネルを同様に設定する。本発明は、このＲＴＣＰチャネルを、以下で説明するような実際的な条件の下でテキストメッセージを搬送するために使用する。
【００１６】
本発明の好ましい実施形態では、前記端末は、初期化段階の間に、前記端末がコピーテキストメッセージを受信可能であるという効果を得るように、前記音声サービス構成要素に通知メッセージを送信するように動作する。この特徴は、音声サービス構成要素が通信している端末が、コピーテキストメッセージを受信するとともに処理することが可能であることを、前記音声サービス構成要素に通知する。この実施では、前記音声サービス構成要素は、前記音声サービス構成要素が前記端末から通知メッセージを受信した場合のみコピーテキストメッセージを送信する。
【００１７】
本発明は、同様に、ネットワーク内での通知メッセージの欠損が、ダビング中断に導かないことを保証するために、前記通知メッセージを周期的に送信するように構成する。
【００１８】
音声サービス構成要素の観点からは、通知メッセージを受信すると即座に本発明のダビング方法を動作するとともに、次いで後続の通知メッセージを単に無視する。このようにして、前記サーバは、通知メッセージが、未だ受信されていないならば、待機状態にとどまる。それにもかかわらず、前記サーバは、音声メッセージを送信開始するが、前記サーバは通知メッセージを受信するまでテキストメッセージを送信しない。もし、前記端末が、通知メッセージを送信することによって処理を開始しないならば、呼の間には、一切テキストダビングが発生しない。
【００１９】
かわりに、本発明では、前記端末によるコピーテキストメッセージの受信時に、前記通知メッセージの周期的な送信を中断することを提案する。従って、有用でなくなった通知メッセージの送信を停止することによって、帯域幅を節約することが可能である。それにもかかわらず、前記呼が、１つの音声サービス構成要素から、もう一つの音声サービス構成要素に転送された場合にシステムの全構成要素に対する通知を維持するために、通知メッセージの周期的な送信を推奨する。
【００２０】
本発明の実施では、前記音声メッセージ及び前記関連付けるテキストメッセージは、同時に送信される。テキストメッセージの送信が、関連付けた音声メッセージの送信に先行しない限り、送信する音声及びテキストパケットを、次いで同時に送信しても良いのが好ましい。そのような場合には、テキストパケットを最初に送信し、即座に音声パケットが続く。この送信モードの利点は、この送信モードによって、前記端末が音声メッセージの前にテキストメッセージを検討可能にするとなるとともに、従って音声メッセージの受信の作用として、いつテキストメッセージを表示するか判定することが可能なことである。
【００２１】
この環境では、本発明が開示するように、もし所与の遅延期間だけテキストメッセージの送信が関連付けた音声メッセージの送信に先行するならば、音声及びテキストメッセージの受信器での同期を改善しうる。
【００２２】
本発明の方法を、ネットワーク内でのメッセージの欠損時にも、より高信頼にするために、関連付けた音声メッセージの送信の間にテキストメッセージを周期的に送信する準備をする。これによって、いくつかのテキストメッセージが失われても、前記端末がすくなくとも１つのテキストメッセージを受信することを保証する。
【００２３】
最後に、本発明のダビング方法の特に好ましい１つの実施では、コピーテキストメッセージの受信時に、前記端末が前記音声サービス構成要素に受信通知メッセージを送信する。この特徴が、メッセージ同期化に関係する問題及びメッセージ欠損に対して、如何に完全に満足すべきソリューションを構成するのか詳細に以下で説明する。
【００２４】
同様に、この段階では、本発明によると、音声メッセージは、受信通知メッセージの受信時に音声サービス構成要素によって送信するという事実によって、メッセージ同期化を確保していることを指摘する。
【００２５】
同様に、本発明が開示するように、受信通知メッセージを受信するまで前記音声サービス構成要素が前記テキストメッセージを周期的に再送信するならば、メッセージ欠損の可能性も考慮される。
【００２６】
本発明は同様に、通知メッセージを送信する手段を具備する点で注目すべき端末に関連する。
【００２７】
前記端末は、受信通知メッセージを送信する手段を具備する点でさらに注目すべきである。
【００２８】
本発明は同様に、前記端末の通知メッセージの受信時にコピーテキストメッセージを送信する手段を具備する点で注目すべきである音声サービス構成要素に関連する。
【００２９】
前記音声サービス構成要素は、前記端末からの受信通知メッセージの受信時に音声メッセージを送信する手段を具備する点でさらに注目すべきである。
【００３０】
前記音声サービス構成要素は、前記端末から受信通知メッセージを受信するまでコピーテキストメッセージを再送信する手段を具備する点でさらに注目すべきである。
【発明を実施するための最良の形態】
【００３１】
添付図面を参照する非限定的な実施例によって構成される以下の説明は、何が本発明を構成するか、かつ如何に本発明を実際に変形しうるかを明瞭に説明する。
【００３２】
図１から４までは、音声サービス構成要素ＳＥＲＶが端末ＴＲに送信する音声メッセージを、テキストメッセージの形式でダビングする方法に関連する。テキストメッセージは、説明の残り部分では、ＴＥＸＴと示される。
【００３３】
パケット交換ネットワーク内で、音声メッセージを送信プロトコルのチャネル上で搬送する。当該プロトコルは、例えば、上記で言及されたリアルタイムトランスポートプロトコル（ＲＴＰ）であっても良い。
【００３４】
メッセージＴＥＸＴと、通知メッセージＮＯＴＩＦ及び受信通知メッセージＡＣＫのような、コピー処理に関連付ける他のメッセージは、ＲＴＰプロトコル内で、ＲＴＣＰという送信制御チャネル上で搬送する。
【００３５】
この制御チャネル上で交換するメッセージは、次の通りである（ＲＦＣ−３５５０を参照）。
【００３６】
メッセージＳＤＥＳ（Ｓｏｕｒｃｅ ＤＥＳｃｒｉｐｔｉｏｎ） メディアストリームデータソースを特定するとともに特徴づける情報を具備する。
【００３７】
メッセージＳＲ（Ｓｅｎｄｅｒ Ｒｅｑｕｅｓｔ） ストリームのサービス品質を調節するために、ソース又は送信器で確立するとともに、受信器又受信器で処理する統計的データを具備する。
【００３８】
メッセージＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ） 各受信器によって確立するとともに、対応する送信器によって、前記送信器の送信を調節するために処理する統計的データを具備する。
【００３９】
メッセージＡＰＰ（ＡＰＰｌｉｃａｔｉｏｎ） アプリケーションレベル制御情報を搬送するために、通信アプリケーションによって使用しうる相補的メッセージ。
【００４０】
メッセージＢＹＥ 通信セッションを離れるソースが送信するメッセージ。
【００４１】
本発明のダビング方法は、ＮＯＴＩＦ、ＴＥＸＴ及びメッセージＡＣＫを送信するためにメッセージＡＰＰを使用する。
【００４２】
図５から７までは、ＡＰＰパケット内でこれらのメッセージをコーディングする実施例を示している。
【００４３】
図１の図は、標準動作の間における本発明の方法の段階を示している。
【００４４】
それぞれ呼設定及びメディアチャネル開始に導く予備的動作であるＣＯＭＳＥＴＵＰ及びＣＨＡＮＯＰについては、ここでは詳細に説明しない。これらの動作は、ＶｏＩＰ信号動作の一部である。これらの動作は、ＶｏＩＰ信号プロトコル（Ｈ．３２３，ＳＩＰ，ＭＧＣＰ等）の一部であるとともに、前記プロトコル自体は本発明自体とは関係なく公知である。
【００４５】
呼及びメディアチャネルが設定されると、端末ＴＲは、前記端末がコピーメッセージを表示可能であることを指示するメッセージＮＯＴＩＦを具備するＲＴＣＰメッセージであるＡＰＰを音声サービス構成要素ＳＥＲＶに送信する。
【００４６】
次いで音声サービス構成要素ＳＥＲＶが音声メッセージを送信する前に、音声サービス構成要素ＳＥＲＶは、表示すべきコピーメッセージのテキストを具備するＲＴＣＰ-メッセージであるＡＰＰ ＴＥＸＴを端末ＴＲに送信する。
【００４７】
このメッセージＴＥＸＴを受信すると、前記メッセージＴＥＸＴが正しく受信されたことを前記構成要素ＳＥＲＶに示す受信通知メッセージＡＣＫを具備するＲＴＣＰメッセージであるＡＰＰを、音声サービス構成要素ＳＥＲＶに送信することで、端末ＴＲが応答する。
【００４８】
前記音声サービス構成要素がこのメッセージＡＣＫを受信した後に、音声サービス構成要素ＳＥＲＶは音声メッセージを送信可能になる。前記音声メッセージを、次いで、端末ＴＲで採用されている表示方針に従って、端末ＴＲによって端末受信するコピーテキストメッセージと同期させる。端末ＴＲは、関連付けた音声メッセージの受信を待つことなく、テキストメッセージを受信すると同時に前記テキストメッセージを表示する、又は、前記音声メッセージの受信と同時に前記テキストメッセージを表示するために前記音声メッセージを受信するまで前記テキストメッセージを保持することを決定可能である。
【００４９】
メッセージ同期化の管理を改善するために、参照機構を構成することが可能である。端末ＴＲが表示する各テキストメッセージに対して、音声サービス構成要素ＳＥＲＶは、次のテキストメッセージのために修正されるとともに、対応するメッセージＡＣＫ内で端末ＴＲが繰り返す識別子を定義する。この識別子は、各テキストメッセージを送信した、又は表示すべき異なるテキストメッセージを送信した場合に、前記サーバがインクリメントしても良い。そのような場合には、メッセージＴＥＸＴが欠損したとき、再送信するメッセージＴＥＸＴは、今までどおり同一の識別子を具備する。
【００５０】
図２は、メッセージＮＯＴＩＦの周期的に再送信する機構を示している。最初のメッセージＮＯＴＩＦを送信した後に、端末ＴＲは、タイムアウトＴｅｍｐ１を調節する。タイムアウトが終了した場合に、端末ＴＲは、メッセージＮＯＴＩＦを再度送信するとともに、新規タイムアウトＴｅｍｐ１等を開始する。このようにして、もしメッセージＮＯＴＩＦが失われたとしても、それにもかかわらず、音声サービス構成要素ＳＥＲＶは、端末ＴＲがコピーテキストメッセージを処理可能であることを通知される。この再送信機構は、比較的低信頼のトランスポートプロトコルを使用する場合に特に有用である。既に上記で説明したように、メッセージＮＯＴＩＦの繰り返しは、音声サービス構成要素ＳＥＲＶからの最初のメッセージＴＥＸＴの受信によって停止しても良く、このことは、帯域幅を節約するという利点を具備するが、起こりうる呼の転送鎖で、メッセージＮＯＴＩＦ内に具備する情報の送信を中断するという欠点を具備する。
【００５１】
図３は、コピーテキストメッセージＴＥＸＴの欠損を回避するために構成する機構を示している。音声サービス構成要素ＳＥＲＶが、最初のメッセージＴＥＸＴを送信するときに、前記音声サービス構成要素は、タイムアウトＴｅｍｐ２を初期化する。もし、このタイムアウトが終了したときに、前記音声サービス構成要素が前記メッセージＴＥＸＴに対応する受信通知メッセージＡＣＫを受信していなければ、前記音声サービス構成要素は、同一のメッセージＴＥＸＴを再送信するとともに、タイムアウトＴｅｍｐ２を再開する。続いて、もし前記音声サービス構成要素がメッセージＡＣＫを受信したら、前記音声サービス構成要素はこのタイムアウトＴｅｍｐ２を停止するとともに、メッセージＴＥＸＴに関連付けた音声メッセージを送信開始する。
【００５２】
かわりに、音声サービス構成要素ＳＥＲＶは、メッセージＴＥＸＴを送信するとともに、同時にメディアストリームの送信を開始しても良い。そのような場合には、前記メディアストリームと前記メディアストリームのテキストコピーとの間の同期化は、あまり洗練されていないが、受信通知メッセージＡＣＫの使用はもはや要求されないので、処理はより簡単になる。
【００５３】
もし音声サービス構成要素ＳＥＲＶが、メッセージＴＥＸＴを送信するとともに、受信通知の受信を待つことなく、遅延時間の後に前記音声メッセージを送信開始するならば、この変形例は改善されうる。そのような場合には、同期化はより洗練されるが、それでも処理はより簡単である。
【００５４】
図４は、受信通知メッセージＡＣＫの欠損を回避するために構成する機構を示している。メッセージＴＥＸＴの欠損とともに、もし端末ＲＴＣＰが返信したメッセージＡＣＫが音声サービス構成要素ＳＥＲＶに到達しないならば、タイムアウトＴｅｍｐ２と同一の継続期間を具備しても良いタイムアウトＴｅｍｐの後に、前記音声サービス構成要素はＲＴＣＰメッセージであるＡＰＰ ＴＥＸＴを再送信する。前記機構は、音声サービス構成要素ＳＥＲＶがメッセージＡＣＫを受信するまで、実行を継続し、そこで音声サービス構成要素ＳＥＲＶは、音声メッセージを送信する。
【００５５】
この構成では、メッセージＡＣＫが欠損したときに、端末ＴＲは、メッセージＡＣＫが前記端末に到達する前に、前記テキストメッセージを表示しても良い。前記遅延の大きさの程度は、おそらくはユーザが悩ましい時間差を認知しないようなものである。実際、ダビングサービスは、高度に洗練された情報同期化は必要とはせず、例えば、視聴覚字幕の同期化と類似の動作を必要とするに過ぎない。
【００５６】
一般的に述べると、再送信間隔の最適化は、ＲＴＰ交信の両端の構成要素が、ＲＴＣＰメッセージＳＲ及びＲＲを利用してネットワーク内の推定ラウンドトリップタイムを計算可能である事実をベースとしても良いことに留意する。当該推定は、テキスト及びメッセージＡＣＫの再送信期間を決定するのに使用しても良い。
【図面の簡単な説明】
【００５７】
【図１】図１は、本発明のダビング方法実行の間に、端末と音声サーバ構成要素との間の交信を示している図である。
【図２】図２は、通知メッセージを繰り返ししている図１のダイヤグラムを表す。
【図３】図３は、テキストメッセージを欠損している図１のダイヤグラムを表す。
【図４】図４は、受信通知メッセージを欠損している図１のダイヤグラムを表す。
【図５】図５は、ＲＴＣＰパケットＡＰＰ内のメッセージＮＯＴＩＦのコーディング実施例である。
【図６】図６は、ＲＴＣＰパケットＡＰＰ内のメッセージＴＥＸＴのコーディング実施例である。
【図７】図７は、ＲＴＣＰパケットＡＰＰ内のメッセージＡＣＫのコーディング実施例である。
【符号の説明】
【００５８】
ＮＯＴＩＦ メッセージＮＯＴＩＦ
ＴＥＸＴ メッセージＴＥＸＴ
ＡＣＫ メッセージＡＣＫ
【背景技術】
【０００１】
本発明は、テキストメッセージの形式で音声メッセージをダビングする方法に関する。
【０００２】
本発明は、固定線または無線パケット交換通信ネットワーク上の対話型音声通信の分野、またはより一般的には、パケットモードでディジタルデータを送信する任意のネットワークに、特に好ましい応用を見出す。
【０００３】
この分野には、「Ａｕｄｉｏｔｅｌ」の拡張、または、例えば、ＶｏＩＰ電話のようなディジタル電話の交換電話ネットワークで公知の同様サービスを代表する会話型音声応答機のような、ユーザの要求により情報を供給する自動サービスが存在する。
【０００４】
それにもかかわらず、本発明は、明白に特定された数を介して、直接にアクセス可能である音声サーバと、ユーザの端末との間の交換のみに限定されるのではなく、音声サーバによって初期化された通信システムを介してユーザが転送可能な音声サービス構成要素の交換に対して同様に拡張することを指摘すべきである。
【０００５】
本発明の目的は、音声サービス構成要素で送信される音声メッセージを、テキストメッセージの形式でコピー可能にすることであり、前記テキストメッセージは、通常音声メッセージの受信と同時に、ユーザの端末のディスプレイ上に現れるテキストミニメッセージである。前記端末は、任意の形式でもよいが、ハンズフリー機能を具備する端末、ビデオフォン端末等、及びより一般には、ユーザがテキストメッセージを読むのと同一の時間に音声メッセージを聞くことを可能にする端末に、本発明は好ましい応用を見出すことを理解する。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＶｏＩＰ通信の分野では、例えば、テキストメッセージ及び関連付けた音声メッセージを同時に表示する問題に適用可能である方法が公知である。
【０００７】
第１ソリューションは、呼を設定する場合に、テキストデータを送信するための追加メディアチャネルを交渉することである。リアルタイム転送するプロトコル（ＲＴＰ-ＲＦＣ３３５０）の環境では、テキストデータは、ドキュメント「ＲＴＰ Ｐａｙｌｏａｄ Ｆｏｒ Ｔｅｘｔ Ｃｏｎｖｅｒｓａｔｉｏｎ」（ＲＦＣ−２７９３）で定義された標準ペイロードに適合可能である。
【０００８】
第２ソリューションは、信号経路にテキストデータを挿入することで、信号プロトコルのデータ搬送が可能であることを使用することである。セッション開始プロトコル（ＳＩＰ）に適用可能であるこの技術の１つの実施例は、米国特許第６，７５７，７３２号で説明されている。
【０００９】
しかしながら、それらの公知のダビング方法は、多くの欠点を具備する。
【００１０】
テキストデータを搬送する追加メディアストリームを生成するソリューションでは、種々の送信形式のために複数のデータセッションを管理可能にするための端末及び音声サービス構成要素が要求される。さらに、メディアストリームを１つのみ通過させる代わりに、２つのメディアストリーム通過を許可するように、ファイアウォールのようなネットワーク構成要素を構成する必要がある。最後に、関連付けた音声メッセージが表示されるのと同一の時間にテキストコピーを表示するために、同期化手段を構成する必要がある。このことは、主メッセージを構成する音声サンプルに関連するタイムスタンプのような時間情報と関連付けて、音声サービス構成要素内にテキストデータを格納することを要求しうる。
【００１１】
第２ソリューションでは、必然的に、テキストデータを信号経路で搬送するとともに、このようにして、呼設定メッセージでネットワーク内に設定した経路を辿る必要がある。アーキテクチャの観点からは、呼の管理を扱う信号それ自体を、呼のコンテンツ、即ちテキストデータそれ自体と混合することに留意する。このことは、このソリューションが比較的複雑であることを自然に示唆する。何故ならば、このソリューションは、同一の状態オートマトン内でコンテンツと管理アクションとを混合するからである。さらに、この方法は、選択された信号プロトコル（Ｈ．３２３，ＳＩＰ，ＭＧＣＰ等）に密接に依存しているとともに、従って、１つの信号形式に従う実施は、他の信号形式に拡張することは不可能である。最後に、メディアデータは信号装置を通過しないので、メディアデータは、より直接的な経路をとるため、必然的にメッセージ表示の同期化問題につながる、テキストと音声データとの間に変動する搬送遅延時間に関する問題が予想されることも強調すべきである。
【課題を解決するための手段】
【００１２】
このように、本発明によって解決する技術的問題は、テキストメッセージの形式で音声メッセージをダビングする方法を提案することであり、前記メッセージは、音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用するパケットモードディジタルデータ送信ネットワーク上で音声サービス構成要素を介して、端末に送信する。この方法は実際に、テキストメッセージを搬送する信号経路の仕様を越える使用を回避するとともに、またテキストメッセージのみに対する専用の追加メディアストリームの開始を回避する。
【００１３】
本発明によると、上記の技術的問題に対するソリューションでは、送信制御プロトコルが前記送信プロトコルに関連付けられ、前記送信制御チャネル上で、前記テキストメッセージを端末に送信する。
【００１４】
従って、本発明の方法では、新規メディアストリームチャネルを開始する必要なくテキストメッセージを転送し、テキストメッセージは、音声メッセージと同一の経路を使用し、特に、この追加チャネルの通過を許可するようなファイアウォールの再構成を回避することが明白である。さらに、本発明が提案するソリューションは、使用される信号プロトコルに非依存であるとともに、１つの信号プロトコルからもう１つの信号プロトコルに切り換えることすら可能である。
【００１５】
本発明によると、前記通信プロトコルは、データパケットの形式で、前記データパケットのタイムスタンプを伴って、ディジタルストリームを搬送するように設計された、リアルタイムトランスポートプロトコル（ＲＴＰ）である。ＲＴＰ送信チャネルが設定された場合に、リアルタイム搬送制御プロトコル（ＲＴＣＰ）である送信制御プロトコルを搬送するための第２チャネルを同様に設定する。本発明は、このＲＴＣＰチャネルを、以下で説明するような実際的な条件の下でテキストメッセージを搬送するために使用する。
【００１６】
本発明の好ましい実施形態では、前記端末は、初期化段階の間に、前記端末がコピーテキストメッセージを受信可能であるという効果を得るように、前記音声サービス構成要素に通知メッセージを送信するように動作する。この特徴は、音声サービス構成要素が通信している端末が、コピーテキストメッセージを受信するとともに処理することが可能であることを、前記音声サービス構成要素に通知する。この実施では、前記音声サービス構成要素は、前記音声サービス構成要素が前記端末から通知メッセージを受信した場合のみコピーテキストメッセージを送信する。
【００１７】
本発明は、同様に、ネットワーク内での通知メッセージの欠損が、ダビング中断に導かないことを保証するために、前記通知メッセージを周期的に送信するように構成する。
【００１８】
音声サービス構成要素の観点からは、通知メッセージを受信すると即座に本発明のダビング方法を動作するとともに、次いで後続の通知メッセージを単に無視する。このようにして、前記サーバは、通知メッセージが、未だ受信されていないならば、待機状態にとどまる。それにもかかわらず、前記サーバは、音声メッセージを送信開始するが、前記サーバは通知メッセージを受信するまでテキストメッセージを送信しない。もし、前記端末が、通知メッセージを送信することによって処理を開始しないならば、呼の間には、一切テキストダビングが発生しない。
【００１９】
かわりに、本発明では、前記端末によるコピーテキストメッセージの受信時に、前記通知メッセージの周期的な送信を中断することを提案する。従って、有用でなくなった通知メッセージの送信を停止することによって、帯域幅を節約することが可能である。それにもかかわらず、前記呼が、１つの音声サービス構成要素から、もう一つの音声サービス構成要素に転送された場合にシステムの全構成要素に対する通知を維持するために、通知メッセージの周期的な送信を推奨する。
【００２０】
本発明の実施では、前記音声メッセージ及び前記関連付けるテキストメッセージは、同時に送信される。テキストメッセージの送信が、関連付けた音声メッセージの送信に先行しない限り、送信する音声及びテキストパケットを、次いで同時に送信しても良いのが好ましい。そのような場合には、テキストパケットを最初に送信し、即座に音声パケットが続く。この送信モードの利点は、この送信モードによって、前記端末が音声メッセージの前にテキストメッセージを検討可能にするとなるとともに、従って音声メッセージの受信の作用として、いつテキストメッセージを表示するか判定することが可能なことである。
【００２１】
この環境では、本発明が開示するように、もし所与の遅延期間だけテキストメッセージの送信が関連付けた音声メッセージの送信に先行するならば、音声及びテキストメッセージの受信器での同期を改善しうる。
【００２２】
本発明の方法を、ネットワーク内でのメッセージの欠損時にも、より高信頼にするために、関連付けた音声メッセージの送信の間にテキストメッセージを周期的に送信する準備をする。これによって、いくつかのテキストメッセージが失われても、前記端末がすくなくとも１つのテキストメッセージを受信することを保証する。
【００２３】
最後に、本発明のダビング方法の特に好ましい１つの実施では、コピーテキストメッセージの受信時に、前記端末が前記音声サービス構成要素に受信通知メッセージを送信する。この特徴が、メッセージ同期化に関係する問題及びメッセージ欠損に対して、如何に完全に満足すべきソリューションを構成するのか詳細に以下で説明する。
【００２４】
同様に、この段階では、本発明によると、音声メッセージは、受信通知メッセージの受信時に音声サービス構成要素によって送信するという事実によって、メッセージ同期化を確保していることを指摘する。
【００２５】
同様に、本発明が開示するように、受信通知メッセージを受信するまで前記音声サービス構成要素が前記テキストメッセージを周期的に再送信するならば、メッセージ欠損の可能性も考慮される。
【００２６】
本発明は同様に、通知メッセージを送信する手段を具備する点で注目すべき端末に関連する。
【００２７】
前記端末は、受信通知メッセージを送信する手段を具備する点でさらに注目すべきである。
【００２８】
本発明は同様に、前記端末の通知メッセージの受信時にコピーテキストメッセージを送信する手段を具備する点で注目すべきである音声サービス構成要素に関連する。
【００２９】
前記音声サービス構成要素は、前記端末からの受信通知メッセージの受信時に音声メッセージを送信する手段を具備する点でさらに注目すべきである。
【００３０】
前記音声サービス構成要素は、前記端末から受信通知メッセージを受信するまでコピーテキストメッセージを再送信する手段を具備する点でさらに注目すべきである。
【発明を実施するための最良の形態】
【００３１】
添付図面を参照する非限定的な実施例によって構成される以下の説明は、何が本発明を構成するか、かつ如何に本発明を実際に変形しうるかを明瞭に説明する。
【００３２】
図１から４までは、音声サービス構成要素ＳＥＲＶが端末ＴＲに送信する音声メッセージを、テキストメッセージの形式でダビングする方法に関連する。テキストメッセージは、説明の残り部分では、ＴＥＸＴと示される。
【００３３】
パケット交換ネットワーク内で、音声メッセージを送信プロトコルのチャネル上で搬送する。当該プロトコルは、例えば、上記で言及されたリアルタイムトランスポートプロトコル（ＲＴＰ）であっても良い。
【００３４】
メッセージＴＥＸＴと、通知メッセージＮＯＴＩＦ及び受信通知メッセージＡＣＫのような、コピー処理に関連付ける他のメッセージは、ＲＴＰプロトコル内で、ＲＴＣＰという送信制御チャネル上で搬送する。
【００３５】
この制御チャネル上で交換するメッセージは、次の通りである（ＲＦＣ−３５５０を参照）。
【００３６】
メッセージＳＤＥＳ（Ｓｏｕｒｃｅ ＤＥＳｃｒｉｐｔｉｏｎ） メディアストリームデータソースを特定するとともに特徴づける情報を具備する。
【００３７】
メッセージＳＲ（Ｓｅｎｄｅｒ Ｒｅｑｕｅｓｔ） ストリームのサービス品質を調節するために、ソース又は送信器で確立するとともに、受信器又受信器で処理する統計的データを具備する。
【００３８】
メッセージＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ） 各受信器によって確立するとともに、対応する送信器によって、前記送信器の送信を調節するために処理する統計的データを具備する。
【００３９】
メッセージＡＰＰ（ＡＰＰｌｉｃａｔｉｏｎ） アプリケーションレベル制御情報を搬送するために、通信アプリケーションによって使用しうる相補的メッセージ。
【００４０】
メッセージＢＹＥ 通信セッションを離れるソースが送信するメッセージ。
【００４１】
本発明のダビング方法は、ＮＯＴＩＦ、ＴＥＸＴ及びメッセージＡＣＫを送信するためにメッセージＡＰＰを使用する。
【００４２】
図５から７までは、ＡＰＰパケット内でこれらのメッセージをコーディングする実施例を示している。
【００４３】
図１の図は、標準動作の間における本発明の方法の段階を示している。
【００４４】
それぞれ呼設定及びメディアチャネル開始に導く予備的動作であるＣＯＭＳＥＴＵＰ及びＣＨＡＮＯＰについては、ここでは詳細に説明しない。これらの動作は、ＶｏＩＰ信号動作の一部である。これらの動作は、ＶｏＩＰ信号プロトコル（Ｈ．３２３，ＳＩＰ，ＭＧＣＰ等）の一部であるとともに、前記プロトコル自体は本発明自体とは関係なく公知である。
【００４５】
呼及びメディアチャネルが設定されると、端末ＴＲは、前記端末がコピーメッセージを表示可能であることを指示するメッセージＮＯＴＩＦを具備するＲＴＣＰメッセージであるＡＰＰを音声サービス構成要素ＳＥＲＶに送信する。
【００４６】
次いで音声サービス構成要素ＳＥＲＶが音声メッセージを送信する前に、音声サービス構成要素ＳＥＲＶは、表示すべきコピーメッセージのテキストを具備するＲＴＣＰ-メッセージであるＡＰＰ ＴＥＸＴを端末ＴＲに送信する。
【００４７】
このメッセージＴＥＸＴを受信すると、前記メッセージＴＥＸＴが正しく受信されたことを前記構成要素ＳＥＲＶに示す受信通知メッセージＡＣＫを具備するＲＴＣＰメッセージであるＡＰＰを、音声サービス構成要素ＳＥＲＶに送信することで、端末ＴＲが応答する。
【００４８】
前記音声サービス構成要素がこのメッセージＡＣＫを受信した後に、音声サービス構成要素ＳＥＲＶは音声メッセージを送信可能になる。前記音声メッセージを、次いで、端末ＴＲで採用されている表示方針に従って、端末ＴＲによって端末受信するコピーテキストメッセージと同期させる。端末ＴＲは、関連付けた音声メッセージの受信を待つことなく、テキストメッセージを受信すると同時に前記テキストメッセージを表示する、又は、前記音声メッセージの受信と同時に前記テキストメッセージを表示するために前記音声メッセージを受信するまで前記テキストメッセージを保持することを決定可能である。
【００４９】
メッセージ同期化の管理を改善するために、参照機構を構成することが可能である。端末ＴＲが表示する各テキストメッセージに対して、音声サービス構成要素ＳＥＲＶは、次のテキストメッセージのために修正されるとともに、対応するメッセージＡＣＫ内で端末ＴＲが繰り返す識別子を定義する。この識別子は、各テキストメッセージを送信した、又は表示すべき異なるテキストメッセージを送信した場合に、前記サーバがインクリメントしても良い。そのような場合には、メッセージＴＥＸＴが欠損したとき、再送信するメッセージＴＥＸＴは、今までどおり同一の識別子を具備する。
【００５０】
図２は、メッセージＮＯＴＩＦの周期的に再送信する機構を示している。最初のメッセージＮＯＴＩＦを送信した後に、端末ＴＲは、タイムアウトＴｅｍｐ１を調節する。タイムアウトが終了した場合に、端末ＴＲは、メッセージＮＯＴＩＦを再度送信するとともに、新規タイムアウトＴｅｍｐ１等を開始する。このようにして、もしメッセージＮＯＴＩＦが失われたとしても、それにもかかわらず、音声サービス構成要素ＳＥＲＶは、端末ＴＲがコピーテキストメッセージを処理可能であることを通知される。この再送信機構は、比較的低信頼のトランスポートプロトコルを使用する場合に特に有用である。既に上記で説明したように、メッセージＮＯＴＩＦの繰り返しは、音声サービス構成要素ＳＥＲＶからの最初のメッセージＴＥＸＴの受信によって停止しても良く、このことは、帯域幅を節約するという利点を具備するが、起こりうる呼の転送鎖で、メッセージＮＯＴＩＦ内に具備する情報の送信を中断するという欠点を具備する。
【００５１】
図３は、コピーテキストメッセージＴＥＸＴの欠損を回避するために構成する機構を示している。音声サービス構成要素ＳＥＲＶが、最初のメッセージＴＥＸＴを送信するときに、前記音声サービス構成要素は、タイムアウトＴｅｍｐ２を初期化する。もし、このタイムアウトが終了したときに、前記音声サービス構成要素が前記メッセージＴＥＸＴに対応する受信通知メッセージＡＣＫを受信していなければ、前記音声サービス構成要素は、同一のメッセージＴＥＸＴを再送信するとともに、タイムアウトＴｅｍｐ２を再開する。続いて、もし前記音声サービス構成要素がメッセージＡＣＫを受信したら、前記音声サービス構成要素はこのタイムアウトＴｅｍｐ２を停止するとともに、メッセージＴＥＸＴに関連付けた音声メッセージを送信開始する。
【００５２】
かわりに、音声サービス構成要素ＳＥＲＶは、メッセージＴＥＸＴを送信するとともに、同時にメディアストリームの送信を開始しても良い。そのような場合には、前記メディアストリームと前記メディアストリームのテキストコピーとの間の同期化は、あまり洗練されていないが、受信通知メッセージＡＣＫの使用はもはや要求されないので、処理はより簡単になる。
【００５３】
もし音声サービス構成要素ＳＥＲＶが、メッセージＴＥＸＴを送信するとともに、受信通知の受信を待つことなく、遅延時間の後に前記音声メッセージを送信開始するならば、この変形例は改善されうる。そのような場合には、同期化はより洗練されるが、それでも処理はより簡単である。
【００５４】
図４は、受信通知メッセージＡＣＫの欠損を回避するために構成する機構を示している。メッセージＴＥＸＴの欠損とともに、もし端末ＲＴＣＰが返信したメッセージＡＣＫが音声サービス構成要素ＳＥＲＶに到達しないならば、タイムアウトＴｅｍｐ２と同一の継続期間を具備しても良いタイムアウトＴｅｍｐの後に、前記音声サービス構成要素はＲＴＣＰメッセージであるＡＰＰ ＴＥＸＴを再送信する。前記機構は、音声サービス構成要素ＳＥＲＶがメッセージＡＣＫを受信するまで、実行を継続し、そこで音声サービス構成要素ＳＥＲＶは、音声メッセージを送信する。
【００５５】
この構成では、メッセージＡＣＫが欠損したときに、端末ＴＲは、メッセージＡＣＫが前記端末に到達する前に、前記テキストメッセージを表示しても良い。前記遅延の大きさの程度は、おそらくはユーザが悩ましい時間差を認知しないようなものである。実際、ダビングサービスは、高度に洗練された情報同期化は必要とはせず、例えば、視聴覚字幕の同期化と類似の動作を必要とするに過ぎない。
【００５６】
一般的に述べると、再送信間隔の最適化は、ＲＴＰ交信の両端の構成要素が、ＲＴＣＰメッセージＳＲ及びＲＲを利用してネットワーク内の推定ラウンドトリップタイムを計算可能である事実をベースとしても良いことに留意する。当該推定は、テキスト及びメッセージＡＣＫの再送信期間を決定するのに使用しても良い。
【図面の簡単な説明】
【００５７】
【図１】図１は、本発明のダビング方法実行の間に、端末と音声サーバ構成要素との間の交信を示している図である。
【図２】図２は、通知メッセージを繰り返ししている図１のダイヤグラムを表す。
【図３】図３は、テキストメッセージを欠損している図１のダイヤグラムを表す。
【図４】図４は、受信通知メッセージを欠損している図１のダイヤグラムを表す。
【図５】図５は、ＲＴＣＰパケットＡＰＰ内のメッセージＮＯＴＩＦのコーディング実施例である。
【図６】図６は、ＲＴＣＰパケットＡＰＰ内のメッセージＴＥＸＴのコーディング実施例である。
【図７】図７は、ＲＴＣＰパケットＡＰＰ内のメッセージＡＣＫのコーディング実施例である。
【符号の説明】
【００５８】
ＮＯＴＩＦ メッセージＮＯＴＩＦ
ＴＥＸＴ メッセージＴＥＸＴ
ＡＣＫ メッセージＡＣＫ
【特許請求の範囲】
【請求項１】
テキストメッセージの形式で音声メッセージをダビングする方法であり、音声サービス構成要素がパケットモードディジタルデータ送信ネットワーク上で端末に前記メッセージを送信し、音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用する方法において、
送信制御プロトコルを、前記送信プロトコルに関連付けて、前記テキストメッセージ（ＴＥＸＴ）を、送信制御チャネル上で前記端末に送信することを特徴とする方法。
【請求項２】
初期化段階の間に、前記端末は、前記音声サービス構成要素に、前記端末がコピーテキストメッセージ（ＴＥＸＴ）を受信可能であることを通知するためのメッセージ（ＮＯＴＩＦ）を送信することを特徴とする請求項１に記載の方法。
【請求項３】
前記通知メッセージ（ＮＯＴＩＦ）が周期的に送信されることを特徴とする請求項２に記載の方法。
【請求項４】
前記前記通知メッセージ（ＮＯＴＩＦ）の周期的な送信は、前記端末によってコピーテキストメッセージ（ＴＥＸＴ）が受信されると中断されることを特徴とする請求項３に記載の方法。
【請求項５】
前記音声メッセージ及び前記関連付けるテキストメッセージ（ＴＥＸＴ）は、同時に送信されることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
テキストメッセージ（ＴＥＸＴ）の送信は、関連付けた音声メッセージの送信に先行することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項７】
テキストメッセージ（ＴＥＸＴ）の送信は、所与の遅延時間だけ、関連付けた音声メッセージの送信に先行することを特徴とする請求項６に記載の方法。
【請求項８】
テキストメッセージ（ＴＥＸＴ）は、関連付けた音声メッセージの送信の間、周期的に送信されることを特徴とする請求項５に記載の方法。
【請求項９】
前記端末は、コピーテキストメッセージ（ＴＥＸＴ）の受信時に、前記音声サービス構成要素に受信通知メッセージ（ＡＣＫ）を送信することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項１０】
前記音声サービス構成要素は、受信通知メッセージ（ＡＣＫ）の受信時に音声メッセージを送信することを特徴とする請求項９に記載の方法。
【請求項１１】
前記音声サービス構成要素は、受信通知メッセージ（ＡＣＫ）が受信されるまで、周期的に（Ｔ２）前記テキストメッセージ（ＴＥＸＴ）を再送信することを特徴とする請求項９又は請求項１０に記載の方法。
【請求項１２】
前記送信プロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）であることを特徴とする請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
前記通知メッセージと、前記コピーテキストメッセージと、前記受信通知メッセージとは、前記リアルタイムトランスポートプロトコル（ＲＴＰ）に関連付けるリアルタイム送信制御プロトコル（ＲＴＣＰ）のメッセージＡＰＰで送信されることを特徴とする請求項１２に記載の方法。
【請求項１４】
請求項２〜８のいずれか１項に記載の方法を実施するときに、通知メッセージを送信する手段を具備することを特徴とする端末。
【請求項１５】
請求項９〜１１のいずれか１項に記載の方法を実施するときに受信通知メッセージを送信する手段を具備することを特徴とする請求項１４に記載の端末。
【請求項１６】
パケットモードディジタルデータ送信ネットワーク上の端末にテキストメッセージでコピーした音声メッセージを送信するように構成され、 音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用し、送信制御プロトコルを前記送信プロトコルに関連付ける音声サービス構成要素において、前記テキストメッセージ（ＴＥＸＴ）を、送信制御チャネル上で前記端末に送信する手段を具備することを特徴とする音声サービス構成要素。
【請求項１７】
請求項２〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの通知メッセージの受信時に、コピーテキストメッセージを送信する手段を具備することを特徴とする請求項１６に記載の音声サービス構成要素。
【請求項１８】
請求項１０〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの受信通知メッセージの受信時に、音声メッセージを送信する手段を具備することを特徴とする請求項１６又は請求項１７に記載の音声サービス構成要素。
【請求項１９】
請求項１１〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの受信通知メッセージを受信するまで、コピーテキストメッセージを再送信する手段を具備することを特徴とする請求項１８に記載の音声サービス構成要素。
【請求項１】
テキストメッセージの形式で音声メッセージをダビングする方法であり、音声サービス構成要素がパケットモードディジタルデータ送信ネットワーク上で端末に前記メッセージを送信し、音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用する方法において、
送信制御プロトコルを、前記送信プロトコルに関連付けて、前記テキストメッセージ（ＴＥＸＴ）を、送信制御チャネル上で前記端末に送信することを特徴とする方法。
【請求項２】
初期化段階の間に、前記端末は、前記音声サービス構成要素に、前記端末がコピーテキストメッセージ（ＴＥＸＴ）を受信可能であることを通知するためのメッセージ（ＮＯＴＩＦ）を送信することを特徴とする請求項１に記載の方法。
【請求項３】
前記通知メッセージ（ＮＯＴＩＦ）が周期的に送信されることを特徴とする請求項２に記載の方法。
【請求項４】
前記前記通知メッセージ（ＮＯＴＩＦ）の周期的な送信は、前記端末によってコピーテキストメッセージ（ＴＥＸＴ）が受信されると中断されることを特徴とする請求項３に記載の方法。
【請求項５】
前記音声メッセージ及び前記関連付けるテキストメッセージ（ＴＥＸＴ）は、同時に送信されることを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項６】
テキストメッセージ（ＴＥＸＴ）の送信は、関連付けた音声メッセージの送信に先行することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項７】
テキストメッセージ（ＴＥＸＴ）の送信は、所与の遅延時間だけ、関連付けた音声メッセージの送信に先行することを特徴とする請求項６に記載の方法。
【請求項８】
テキストメッセージ（ＴＥＸＴ）は、関連付けた音声メッセージの送信の間、周期的に送信されることを特徴とする請求項５に記載の方法。
【請求項９】
前記端末は、コピーテキストメッセージ（ＴＥＸＴ）の受信時に、前記音声サービス構成要素に受信通知メッセージ（ＡＣＫ）を送信することを特徴とする請求項１〜４のいずれか１項に記載の方法。
【請求項１０】
前記音声サービス構成要素は、受信通知メッセージ（ＡＣＫ）の受信時に音声メッセージを送信することを特徴とする請求項９に記載の方法。
【請求項１１】
前記音声サービス構成要素は、受信通知メッセージ（ＡＣＫ）が受信されるまで、周期的に（Ｔ２）前記テキストメッセージ（ＴＥＸＴ）を再送信することを特徴とする請求項９又は請求項１０に記載の方法。
【請求項１２】
前記送信プロトコルは、リアルタイムトランスポートプロトコル（ＲＴＰ）であることを特徴とする請求項１〜１１のいずれか１項に記載の方法。
【請求項１３】
前記通知メッセージと、前記コピーテキストメッセージと、前記受信通知メッセージとは、前記リアルタイムトランスポートプロトコル（ＲＴＰ）に関連付けるリアルタイム送信制御プロトコル（ＲＴＣＰ）のメッセージＡＰＰで送信されることを特徴とする請求項１２に記載の方法。
【請求項１４】
請求項２〜８のいずれか１項に記載の方法を実施するときに、通知メッセージを送信する手段を具備することを特徴とする端末。
【請求項１５】
請求項９〜１１のいずれか１項に記載の方法を実施するときに受信通知メッセージを送信する手段を具備することを特徴とする請求項１４に記載の端末。
【請求項１６】
パケットモードディジタルデータ送信ネットワーク上の端末にテキストメッセージでコピーした音声メッセージを送信するように構成され、 音声メッセージを送信するために送信プロトコルを搬送するチャネルを使用し、送信制御プロトコルを前記送信プロトコルに関連付ける音声サービス構成要素において、前記テキストメッセージ（ＴＥＸＴ）を、送信制御チャネル上で前記端末に送信する手段を具備することを特徴とする音声サービス構成要素。
【請求項１７】
請求項２〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの通知メッセージの受信時に、コピーテキストメッセージを送信する手段を具備することを特徴とする請求項１６に記載の音声サービス構成要素。
【請求項１８】
請求項１０〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの受信通知メッセージの受信時に、音声メッセージを送信する手段を具備することを特徴とする請求項１６又は請求項１７に記載の音声サービス構成要素。
【請求項１９】
請求項１１〜１３のいずれか１項に記載の方法を実施するときに、前記端末からの受信通知メッセージを受信するまで、コピーテキストメッセージを再送信する手段を具備することを特徴とする請求項１８に記載の音声サービス構成要素。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００８−５３８２６９（Ｐ２００８−５３８２６９Ａ）
【公表日】平成２０年１０月１６日（２００８．１０．１６）
【国際特許分類】
【出願番号】特願２００８−５０３５６２（Ｐ２００８−５０３５６２）
【出願日】平成１８年３月３０日（２００６．３．３０）
【国際出願番号】ＰＣＴ／ＦＲ２００６／０５０２７７
【国際公開番号】ＷＯ２００６／１０３３７４
【国際公開日】平成１８年１０月５日（２００６．１０．５）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
【公表日】平成２０年１０月１６日（２００８．１０．１６）
【国際特許分類】
【出願日】平成１８年３月３０日（２００６．３．３０）
【国際出願番号】ＰＣＴ／ＦＲ２００６／０５０２７７
【国際公開番号】ＷＯ２００６／１０３３７４
【国際公開日】平成１８年１０月５日（２００６．１０．５）
【出願人】（５９１０３４１５４）フランス テレコム (290)
【Ｆターム（参考）】
[ Back to top ]