JPH10247977A - 音声メールシステムおよび音声システム間の通信方法 - Google Patents

Abstract

(57)【要約】 【課題】 種々の機能を持つ音声メール（ＶＭ）・シス
テム間でメッセージの交換を行うことができる音声メー
ル・システム、及び音声メール・システム間で通信する
方法を提供する。 【解決手段】 音声メール・システム間で音声メール・
メッセージを交換する方法が開示されている。当該方法
は、第１及び第２の音声メール・システム間でメッセー
ジ交換セッションを確立するステップを具備している。
各システムで提供される機能に関する情報がシステム間
で交換される。この情報を用いることによって、双方の
システムで共通の機能が判別される。このようにして、
双方のシステムで共通の機能によって使用されるメッセ
ージ・データのみが交換される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、音声メール・シス
テムに係り、特に、システム間で音声メール・メッセー
ジを交換する音声メール・システムおよび音声メール・
システム間の通信方法に関する。

【０００２】

【従来の技術】現在の電話式音声メール（以下、 ＶＭ
とする）システムは、ユーザに対して音声メール・ア
カウント（すなわち 音声メールボックス ）を提供し
ている。メッセージの送信者は、音声メールボックスを
持つ受信者に対して、電話式音声メールを送ることがで
きる。音声メールボックスによれば、送信者は、所望の
受信者に宛てた音声メッセージを、受信者のＶＭシステ
ム上に格納することができる。宛先となった受信者の方
は、送信者からメッセージが送られた後に、これに応答
することができる。

【０００３】メッセージの送信者を分類する場合、受信
者のＶＭシステム上に音声メールボックスを持つ局所的
（ローカル）な送信者と、他のＶＭシステム上に音声メ
ールボックスを持つ遠隔（リモート）の送信者と、さら
にＶＭシステムには接続されないが公衆電話回線に接続
された遠隔（リモート）の送信者とのいずれかに分類す
ることが可能である。

【０００４】昨今のＶＭシステムによれば、局所的（ロ
ーカル）な送信者は、自身のＶＭシステムによって提供
される機能による恩恵を享受しながら、同じＶＭシステ
ム上の他の局所的（ローカル）な受信者宛てにメッセー
ジを作成し送信することができる。例えば、送信者は、
実際の送信行為に先立ってメッセージを作成することが
できる。同様に、局所的（ローカル）な送信者は、メッ
セージに非音声データを組み合わせることができる。例
えば、メッセージ応答要求、テキスト・データ、送信者
識別データ、メッセージ・データの時刻、及び、他のメ
ッセージとリンクするためのデータ（添付）等のような
他のデータをメッセージに含めることができる。

【０００５】遠隔（リモート）の送信者は、典型的に
は、受信者のＶＭシステムからメッセージを送信する訳
ではないので、自身が利用可能なＶＭシステム機能の全
ての恩恵を受けることはできない。ＶＭシステムの中に
は、公衆電話回線を経由して受信者のＶＭシステムをコ
ールする発信者に対して、ＶＭシステム機能の一部分の
利用を可能にしているものもある。送信者が音声メール
ボックスを持つことを必要としないようなＶＭシステム
の機能は、一連の音声指示を通して利用することができ
る。例えば、外部の発信者は、受信者のＶＭシステムを
コールして、受信者に送信するのに先立ってメッセージ
を作成することができる。同様に、外部の発信者は、作
成したメッセージに緊急というマークを付すこともでき
る。このように、メッセージにデータを関連付けること
によって、ＶＭシステムは応答時にメッセージが緊急で
あることを表示することが可能になる。

【０００６】ＶＭシステム間でメッセージ・データと音
声データを含んだメッセージを透過的に交換することが
できるようなＶＭシステムもある。物理的には分離して
いる２又はそれ以上のこのタイプのＶＭシステムを統合
してもよい。各ＶＭシステム上の遠隔（リモート）のユ
ーザは、ＶＭシステムに跨がってメッセージを交換する
ことができるし、統合化されたシステムに跨がってＶＭ
システムの機能の恩恵を受けることもできる。受信者の
メールボックスがあたかも送信者のＶＭシステムの局所
に存在しているかのごとくに、遠隔（リモート）の受信
者に宛てられたメッセージを送信することができる。送
信者及び受信者の各ＶＭシステムによって提供されてい
る機能を実現するために必要なメッセージング・データ
は、ＶＭシステム間で音声データと一緒に交換される。

【０００７】例えば、第１のＶＭシステム上に音声メー
ルボックスを持つ送信者は、第２のシステム上の受信者
に宛てたメッセージを作成し、発送することができる。
送信者は、メッセージにデータの断片を組み合わせるこ
とによって、当該メッセージが緊急であることを示すこ
とができる。送信者は、略語化された識別子を用いて、
送信者ＶＭシステム上の受信者を識別することができ
る。略語化された識別子は内線のようなものであっても
よい。送信者がメッセージを作成し発送してから少し後
に、第１及び第２のＶＭシステムはメッセージ交換セッ
ションを確立する。送信者の音声メッセージは、音声デ
ータとメッセージング・データとからなる第１の形式の
メッセージ・データによって交換される。これらデータ
は、交換セッションの間に、第１のＶＭシステムから第
２のＶＭシステムに送信される。また、第１のＶＭシス
テム上の他のユーザによって発送された他のメッセージ
は、同様に、該セッションの間に交換される。受信者側
のＶＭシステムは、メッセージ・データを受信し、可能
ならば、音声データやこれに関連する全てのメッセージ
ング・データを、受信者のメールボックスの中に格納す
る。次いで、受信者側のＶＭシステムは、受信したメッ
セージを、受信者側のＶＭシステム上で発生した他のメ
ッセージと同じように扱う。このようにして、受信者側
のシステムは、関連するデータを適切に識別して、メッ
セージが緊急である旨が付されていることを受信者に対
して教示できるようになっている。他のメッセージング
・データも同様にして交換してよい。さらに、音声メー
ル・メッセージの受信に応答して生成されたメッセージ
・データを、別の交換セッションの間に発信元のシステ
ムに対して返信してもよい。

【０００８】音声データとメッセージング・データを含
んだメッセージ・データは、標準化されたプロトコルを
用いることによって、ＶＭシステム間で交換することが
できる。このようなプロトコルの１つとして、ＡＭＩＳ
−Ａｎａｌｏｇプロトコル（ＡＭＩＳ−Ａ ）が知られ
ている。ＡＭＩＳ−Ａプロトコルは、数余のＶＭシステ
ム・ベンダに支持されており、ワシントンＤＣに所在す
る情報産業協会によって１９９２年２月に出版された
Ａｕｄｉｏ Ｍｅｓｓａｇｉｎｇ Ｉｎｔｅｒｃｈａｎ
ｇｉｎｇ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＡＭＩＳ）−
ＡｎａｌｏｇＰｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １，
Ｉｓｓｕｅ ２ に記述されている。ＡＭＩＳ−Ａプロ
トコルは、公衆電話回線を用いて交換セッションを確立
することによってメッセージを交換する方法を提供して
いる。該セッションの間、音声メッセージ・データは、
アナログ・フォーマットで送信される。関連するメッセ
ージング・データは、従来の二重トーン多周波数（ Ｄ
ＴＭＦ ：ｄｕａｌｔｏｎｅ ｍｕｌｔｉ ｆｒｅｑｕ
ｅｎｃｙ）シグナルを用いて送信される。

【０００９】デジタル・プロトコルも周知ではあるが、
ＤＴＭＦシグナルを含めたアナログ・プロトコルを利用
することによって、従来の音声式電話回線を用いたメッ
セージの交換を可能とすることができる。アナログ・プ
ロトコルによれば、世界の一部の地域では未だ利用可能
となっていないデジタル・モデム相当の回線を必要とし
ない。

【００１０】しかしながら、既存のＡＭＩＳ−Ａプロト
コルは、ほとんど共通に使用されるＶＭシステムの機能
−すなわち、メッセージの送信、受信、返信−しかサポ
ートしていない。ＡＭＩＳ−Ａプロトコルに固執するシ
ステムは、これら最低限の機能を提供することを要求さ
れているだけである。かかるプロトコルやこのプロトコ
ルを用いて実現される通信方法は、昨今のＶＭシステム
では共通となっている多くのＶＭシステム機能をサポー
トしていない。

【００１１】ＡＭＩＳ−Ａプロトコルはプロトコルの拡
張を考慮してはいるが、該プロトコルは、かかる拡張の
性質や実装形態などを全く定義していない。さらに、プ
ロトコルの拡張に伴う困難を全く考慮していない。

【００１２】

【発明が解決しようとする課題】本発明の目的は、種々
の機能を備えたＶＭシステム間でメッセージの交換を行
うための、改良された音声メールシステムおよび音声シ
ステム間の通信方法を提供することにある。

【００１３】

【課題を解決するための手段】本発明のシステム構成お
よび方法によれば、双方の音声メール・システムがサポ
ートする機能によって使用されないデータを送信しない
ことによって、２つの音声メール・システム間でのメッ
セージ交換に必要な総時間を短縮することができるので
有利である。さらに、本発明の構成および方法によれ
ば、双方のシステムがサポートする共通の機能の最大限
のセットが使用するメッセージ・データを交換すること
ができる。これによって、ＶＭシステム間で利用可能な
機能を最大限に活用することができる。

【００１４】本発明の１つの側面によれば、第１及び第
２の音声メール・システム間で音声メール・メッセージ
を交換する方法が提供される。ここで、各音声メール・
メッセージは、メッセージ・データ・フレームからなる
ものとする。この方法は、ａ）第１及び第２のシステム
間でメッセージ交換セッションを確立するステップ、
ｂ）第１のシステムにおいて利用可能な音声メール・シ
ステム機能を表した第１のインジケータを第１のシステ
ムから第２のシステムに送信するステップ、ｃ）第２の
システムにおいて利用可能な音声メール機能を表した第
２のインジケータを第２のシステムから第１のシステム
に送信するステップ、ｄ）第１及び第２のシステムの双
方で利用可能な共通の機能の最大限のセットを第１及び
第２のシステムにおいて判別するステップ、及び、ｅ）
共通の機能セットに含まれる機能によって使用されるメ
ッセージ・データ・フレームのみを交換するステップと
いう各ステップで構成される。

【００１５】本発明の他の側面によれば、第２の音声メ
ール・システムと相互接続するための音声メール・シス
テムが提供される。このシステムは、音声メール・シス
テムと接続して第２の音声メール・システムと通信する
ためのインターフェースと、インターフェースと接続さ
れたプロセッサとを備えている。プロセッサは、インタ
ーフェースを介して第２の音声メール・システムと音声
メール・メッセージを交換するようになっている。さら
に、プロセッサは、ａ）第２の音声メール・システムと
メッセージ交換セッションを確立し、ｂ）当該音声メー
ル・システムにおいて利用可能な音声メール・システム
機能を表した第１のインジケータを第２の音声メール・
システムに送信し、ｃ）第２の音声メールシステムにお
いて利用可能な音声メール機能を表した第２のインジケ
ータを第２の音声メール・システムから受け取り、ｄ）
当該音声メール・システム及び第２の音声メール・シス
テムの双方で利用可能な共通の機能の最大限のセットを
判別し、ｅ）共通の機能のセットに含まれる機能によっ
て使用されるメッセージ・データ・フレームのみを第２
の音声メール・システムと交換するようになっている。

【００１６】

【発明の実施の形態】以下、本発明の好ましい実施形態
について詳細に説明する。

【００１７】図１に本発明の１つの実施例に従ったＶＭ
システムのブロック図を示す。図１のブロック図で図解
しているように、送信側ＶＭシステム１００は、構内交
換機（ｐｒｉｖａｔｅ ｂｒａｎｃｈ ｅｘｃｈａｎｇ
ｅ： ＰＢＸ ）１１０のような電気通信交換機に接続
されている。構内交換機１１０は、交換電話回線網を経
由して、さらに他の受信側ＶＭシステム（図示しない）
に接続されている。ＶＭシステムは、一般公衆電話回線
網（ｐｕｂｌｉｃ ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏ
ｎｅ ｎｅｔｗｏｒｋ： ＰＳＴＮ ）経由で従来の音
声電話回線と相互接続されていてもよいし、あるいは、
私的な回線網経由で音声電話回線と相互接続されていて
もよい。インターフェース１０８は、送信側ＶＭシステ
ム１００をＰＢＸに接続している。

【００１８】ＶＭシステム１００は、ソフトウェアの制
御の下で、中央処理装置（ＣＰＵ）１０２によって統制
される。ＣＰＵ１０２は、プログラム・メモリ１０６、
ストレージ・メモリ１０４、及び、インターフェース１
０８の各々と相互接続されている。プログラム・メモリ
１０６には、プロセッサが読み取り可能な型式のソフト
ウェアが格納されている。このソフトウェアは、ＶＭシ
ステム１００の機能性を包括的に制御するためのもので
あり、本発明に係る方法をＶＭシステム１００中のプロ
セッサに実行せしめるようになっている。ＶＭシステム
１００と相互接続されたＶＭシステム（図示しない）
は、同様に、本発明に係る方法を用いてＶＭシステム１
００と通信するようになっている。

【００１９】このソフトウェアは、ＶＭシステム１００
上の各ユーザに対してアカウントを提供しており、これ
によってユーザはストレージ・メモリ１０４から音声メ
ッセージを受け取り、格納し、取り出すことができる。
同様に、ユーザは、メッセージを作成し、これらメッセ
ージをストレージ・メモリ１０４に格納し、また、これ
ら格納されたメッセージを他の人に送信することができ
る。ユーザはＰＢＸ１１０経由でシステム１００と局所
的（ローカル）に電話接続して、ＣＰＵ１０２とも交信
することができる。

【００２０】ソフトウェアの制御下にあるＶＭシステム
１００と、これに相互接続されたＶＭシステム（図示し
ない）は、ＡＭＩＳ−Ａプロトコルを実装しているの
で、これらＶＭシステム間でメッセージ・データ形式の
音声メッセージを交換することができる。同様に、双方
のＶＭシステムは、ＡＭＩＳ−Ａプロトコルをサポート
した他のＶＭシステムともメッセージ・データを交換す
ることができる。交換されるメッセージ・データは、音
声データと、これに関連するメッセージング・データと
で構成される。メッセージ・データを用いることによっ
て、ソフトウェアは、物理的に別個のＶＭシステム同士
の存在を、各々のシステムのユーザにとって実質上透過
的にすることができる。

【００２１】例えば、ソフトウェアによれば、双方のＶ
Ｍシステム上のユーザのメールボックスを、相互に排他
的なメールボックス番号によって識別することができ
る。関係するシステム上のユーザの番号によれば、各ユ
ーザのメールボックスを３，４又は５桁の省略番号を用
いて識別することができる。

【００２２】第１のシステム上にメールボックスを持つ
ユーザは、第１のシステム上でメッセージを作成し、こ
のメッセージを第２のシステム上のユーザに発送するこ
とによって、第２のシステム上の受信者にメッセージを
送信することができる。その後、これら２つのシステム
を制御するソフトウェアは、ＶＭシステム間でメッセー
ジ交換セッションを確立させる。メッセージ交換セッシ
ョンの間、他のシステム上のユーザに宛てたメッセージ
・データがシステム間で交換される。

【００２３】メッセージ・データは、本発明の１つの側
面に従って拡張されたＡＭＩＳ−Ａプロトコルを用い
て、システム間で交換される。図２には、送信側ＶＭシ
ステム１００から受信側ＶＭシステムへのメッセージ・
データの流れを図解している。

【００２４】データはフレーム形式でシステム間で交換
される。とりわけ、送信側ＶＭシステム１００は、各音
声メッセージについてのメッセージ・データを、複数の
メッセージ・フレームという形式で送信するようになっ
ている。受信側ＶＭシステムは、各フレームを順次受け
取るようになっている。一旦フレームが受信されると、
フレーム中のデータは、受信側ＶＭシステムによって有
効化される。もし、受信されたフレームに問題があれ
ば、受信側ＶＭシステムは、フレームのリセットを要求
する。リセット要求は各フレームにつき都合３回行われ
る。もし、フレームが適切に受信されたならば、受信側
ＶＭシステムは、応答フレームを送信するとともに、次
のデータ・フレームの到着まで待機する。もし、受信側
ＶＭシステムが３回の試行の間にフレームを成功裡に受
信しなかったならば、交換セッションは終了する。

【００２５】図２における各ノードは、データ・フレー
ムを表している。これらデータ・フレームは、ソフトウ
ェアで制御される送信側ＶＭシステム１００によって生
成され若しくは識別され、且つ送信される。音声データ
・フレーム２８は例外として、メッセージ・データは、
ＤＴＭＦトーンに符号化されて送信される。ＤＴＭＦト
ーンは、ＰＢＸ１１０又はインターフェース１０８のい
ずれによって生成されてもよい。受信側ＶＭシステム
は、ＤＴＭＦトーンを受信するとこれを復号化する。音
声データは、格納しておいたアナログ音声信号を再生す
ることによって、アナログ・データとして送信される。
送信されたアナログ信号は、受信側ＶＭシステムで記録
される。

【００２６】メッセージ交換セッションは、初めに、コ
ール開始フレーム１２、セッション開始フレーム１４、
及び、システム番号フレーム１６を送信することによっ
て確立される。コール開始フレーム１２、セッション開
始フレーム１４、及び、システム番号フレーム１６の各
々のフォーマットは、ＡＭＩＳ−Ａセッション終了デー
タ・フレーム１９と同様に、ＡＭＩＳ−Ａプロトコルに
よって定義されている。フレーム１８は、「プロトコル
拡張」フレームと呼ばれている。プロトコル拡張フレー
ム１８のフォーマットは、少なくとも部分的にはＡＭＩ
Ｓ−Ａプロトコルによって定義されている。このフレー
ム１８は、セッション中で残っているデータ・フレーム
のフォーマットがＡＭＩＳ−Ａプロトコルでは定義され
ていないことを、受信側ＶＭシステムに対して教示する
ためのものである。

【００２７】図３には、プロトコル拡張データ・フレー
ム１８のフォーマットを図解している。プロトコル拡張
データ・フレーム１８は、ＶＭシステム間のメッセージ
交換セッション毎に１回だけ送信される。プロトコル拡
張データ・フレーム１８は、４０ａ乃至４０ｈの８個の
フィールドに分割される。各フィールドは、１乃至２０
桁で構成される。

【００２８】フィールド４０ａは、２桁の識別子であ
り、フレーム１８のフレーム長が書き込まれる（但し、
フィールド４０ａを除くものとし、２１乃至３３桁であ
る）。１桁のフィールド４０ｂは、値８を書き込むこと
によって当該フレームがプロトコル拡張フレームである
ことを識別するためのものである。３桁のフィールド４
０ｃは、受信側ＶＭシステムを識別するためのものであ
る。フィールド４０ｄには、５桁の機能ビットマップが
書き込まれる。機能ビットマップについては後述する。
１桁のフィールド４０ｅには、送信側ＶＭシステム１０
０で使用されているソフトウェアのバージョンを識別す
るためのソフトウェア・バージョン番号が書き込まれ
る。交信を行っている２つのＶＭシステムが異なるバー
ジョンのソフトウェアを使用している場合には、これら
ＶＭシステムは早い方のバージョンのソフトウェアがサ
ポートするプロトコルに戻る必要がある。可変長のフィ
ールド４０ｆは、初期化パスワードを格納するためのも
のであり、送信側ＶＭシステム１００によって送信さ
れ、受信側ＶＭシステムによって認証される。１桁のフ
ィールド４０ｇは、 ＃ という文字のＤＴＭＦを常に
格納しており、フィールド４０ｆの終端を示す区切り文
字として働くようになっている。２桁のフィールド４０
ｈには、フレーム１８についての２桁の検査合計が書き
込まれる。この検査合計は、受信側ＶＭシステムで受信
されたフレームの完全性を検証するのに使用される。

【００２９】フレーム１８を受け取ったことに応答し
て、受信側ＶＭシステムは、応答コードを含んだ応答フ
レームを送信する。もし、応答フレームがプロトコル拡
張フレーム１８の不受理を示していれば、該フレームの
フォーマットはＡＭＩＳ−Ａプロトコルで定義されてい
ることになる。多数の応答コード値（ＲＣ値）がサポー
トされている。例えば、ＲＣ３は要求プロトコル中の目
的地ＩＤが正しくないことを示し、ＲＣ４は初期化パス
ワードが無効であることを示し、ＲＣ５は機能ビットマ
ップが無効であることを示す、といった具合である。

【００３０】もし、プロトコル拡張フレーム１８である
と認識されると、受信側ＶＭシステムは、送信側ＶＭシ
ステム１００に対して、プロトコル拡張受理応答フレー
ム（図２には図解していない）を送信する。このフレー
ムのフォーマットは、図４に図解され、包括的な参照番
号３８が付与されている。この明細書で記述される他の
応答フレームとは異なり、プロトコル拡張受理応答フレ
ーム３８はＡＭＩＳ−Ａプロトコルでは定義されていな
いが、このことに格別の意味はない。

【００３１】プロトコル拡張受理応答フレーム３８は、
７個のフィールドからなり、２０桁乃至３０桁で構成さ
れる。２桁のフィールド４２ａには、フィールド４２ａ
を除いた各フレーム３８のフレーム長が書き込まれる。
フィールド４２ｂは、１桁からなり、 ０ という応答
コードを含んでいる。フィールド４２ｃは、５桁のセッ
ション機能ビットマップで構成されるが、これについて
は以下でさらに詳しく記述する。フィールド４２ｄは、
１桁で構成され、受信側システムで使用されているソフ
トウェアのバージョンを示すソフトウェア・バージョン
番号が書き込まれる。可変長のフィールド４２ｅには、
可変長の応答パスワードが書き込まれる。フィールド４
２ｆにはパスワード区切り文字が書き込まれる。最後の
フィールド４２ｇは、２桁で構成され、フレーム３８の
検査合計が書き込まれる。

【００３２】図５には、フィールド４０ｄに書き込まれ
て送信される機能ビットマップのフォーマットを図解し
ている。図示の通り、各機能ビットマップは、包括的な
参照番号４４が付与されているが、４６ａ乃至４６ｐの
１６個の論理要素で構成される。これら論理要素の各々
は、１又は０の値をとることによって、送信側ＶＭシス
テム、受信側ＶＭシステム、及び、そのソフトウェアに
よってサポートされている各１つのＶＭシステム機能の
サポートを示すようになっている。後の記述で判るよう
に、送信側、受信側のいずれか一方のシステムにおける
ソフトウェアは、潜在的に利用可能な機能の全て又はそ
の一部を提供するか、あるいはいずれも提供しないよう
に構成されている。

【００３３】例えば、各ＶＭシステムは、記録されたア
ナログ音声メッセージとともに、テキスト・データを送
信する機能をサポートしてもよい（以下、「テキスト・
プロパゲーション」と呼ぶ）。テキスト・データは、送
信者の名前、受信者の名前、及び、メッセージの件名の
各々に対応するＡＳＣＩＩ符号化文字を含んでいてもよ
い。ＶＭシステムと通信状態にある他のコンピュータ上
のアプリケーション（例えばＮｏｒｔｅｌ（商標）のＡ
ＣＣＥＳＳ（商標）アプリケーション）は、このような
テキスト・データを用いることができる。

【００３４】同様に、各ＶＭシステムは、遠隔（リモー
ト）のユーザについての送信情報（ＲＶＵ（Ｒｅｍｏｔ
ｅ Ｖｏｉｃｅ Ｕｓｅｒ）プロパゲーション ）をサ
ポートしてもよい。例えば、メッセージの一部として送
信者のテキスト名（但し、ＡＳＣＩＩコードで）を、あ
る１つのＶＭシステムから他方のＶＭシステムへ送信し
てもよい。同様に、口頭形式の送信者の名前をメッセー
ジと一緒に送信してもよい。受信側ＶＭシステムは、送
信者についての情報を局所的（ローカル）なデータベー
スに加えてもよいし、この情報を後になって使用しても
よい。

【００３５】さらに、各ＶＭシステムは、受信したメッ
セージを自身のＶＭシスムテ上の全てのユーザに同報通
信する機能（ ネットワーク・ブロードキャスト ）を
サポートしてもよい。

【００３６】本発明の好ましい実施形態では、これら上
述した機能、すなわちテキスト・プロパゲーション、Ｒ
ＶＵプロパゲーション、及び、ネットワーク・ブロード
キャストの各サポートの有無は、図５に図解しているよ
うに、送信側ＶＭシステム若しくは受信側ＶＭシステム
の機能ビットマップ中の該当する各１つのビットによっ
て表示されるようになっている。本発明の好ましい実施
形態では、これら３つの機能の全てが利用可能となって
いる。しかしながら、これら各機能のサポートの有無は
選択的であってもよい。もし、ある機能がサポートされ
ていれば、該当するシステム機能ビットマップには１と
いうビット値が書き込まれるであろう。ビット値の設定
は、各ＶＭシステムを制御するソフトウェアによって行
われる。

【００３７】本発明の好ましい実施形態では、図示の通
り、エントリ４６ａはテキスト・プロパゲーションのサ
ポートの有無を示し、エントリ４６ｂはＲＶＵプロパゲ
ーションのサポートの有無を示し、４６ｃはネットワー
ク・ブロードキャストのサポートの有無を示すようにな
っている。残余のエントリ４６ｄ乃至４６ｐは未使用で
あるが、他の機能のサポートの有無を表示してもよい。
必要に応じて機能ビットマップを１７ビット以上に拡張
することは容易である、ということを理解されたい。

【００３８】ここで、送信側ＶＭシステム１００はＲＶ
Ｕプロパゲーション及びテキスト・プロパゲーションの
各機能をサポートするが、受信側ＶＭシステムはテキス
ト・プロパゲーション機能のみをサポートすると仮定す
る。この場合、送信側ＶＭシステム１００の機能ビット
マップは００００００００００００００１１となる一
方、受信側ＶＭシステムのそれは００００００００００
０００００１となるであろう。但し、これらビットマッ
プは、１６ビット２進数値であるものとする。

【００３９】送信側のＶＭシステム機能ビットマップ
は、０から２¹⁶−１までの１０進数値に変換される。結
果として得られた１０進数値は、フィールド４０ｄに書
き込まれて、５桁のＤＴＭＦとして送信側ＶＭシステム
１００によって送信される。この例では、００００３と
いう値がフィールド４０ｄに書き込まれて送信される。
受信側のシステムは、フィールド４０ｄの値を受け取っ
たことに応答して、この値と自身の機能ビットマップと
の間で、各ビット毎に論理積をとる。かくして得られた
ビットマップを、以下、セッション・ビットマップと呼
ぶ。セッション・ビットマップを表した５桁のＤＴＭＦ
値は、受信側ＶＭシステムから送信側ＶＭシステム１０
０に返信される。このようにして、この例のシステム・
システムでは、得られた０００００００００００００１
というセッション・ビットマップ、若しくは００００１
という１０進数値が送信側ＶＭシステム１００に返信さ
れる。この例のシステム・ビットマップは、双方のシス
テムでサポートされる機能はテキスト・プロパゲーショ
ンのみということを示している。

【００４０】送信側及び受信側双方のＶＭシステムにお
けるソフトウェアは、システムの双方がサポートしてい
ない機能しか必要としないような不要なデータを交換し
たりしないようになっている。双方のシステムがサポー
トとするか否かは、システム機能ビットマップに反映さ
れている。このことによって、セッションの間、特にＤ
ＴＭＦトーンやアナログ音声信号を用いてメッセージ・
データを交換しているときには、メッセージの交換に要
する総時間を顕著に減少することができる。さらに、送
信側ＶＭシステム又は受信側ＶＭシステムのいずれか一
方が追加機能を提供するように更新された場合には、更
新されたＶＭシステムは、機能ビットマップを適切に活
用することによって、旧態のシステムとの後方互換性を
保証することができる。

【００４１】プロトコル拡張フレーム１８とプロトコル
拡張受理応答フレーム３８が交換された後は、双方のシ
ステムで共通な機能が確定しており、且つ、拡張メッセ
ージ交換セッションが確立されている。この拡張メッセ
ージ交換セッションの間、１又はそれ以上のメッセージ
が交換される。これらメッセージの各々には、メッセー
ジング・データと、可能ならば音声データが含まれる。

【００４２】送信側ＶＭシステム１００はプロトコル拡
張受理応答フレーム３８を受け取ってもこれに対する応
答フレームを送信しないが、このことに格別の意味な
い。その代わり、送信側ＶＭシステム１００は、プロト
コル拡張受理応答フレーム３８が有効に受理された場合
のみ、メッセージ詳細フレーム２０を送信するようにな
っている。

【００４３】各メッセージは、メッセージ詳細フレーム
２０によって識別される。このフレーム２０は、各メッ
セージにおいて、送信側ＶＭシステム１００から受信側
ＶＭシステムに転送される最初のフレームである。メッ
セージ詳細フレーム２０は、図６に図解するようなフォ
ーマットを有している。各メッセージ詳細フレーム２０
は、４８ａ乃至４８ｎの１４個のフィールドで構成さ
れ、２４乃至８０桁のフレーム長を有し、ＤＴＭＦトー
ンとして送信される。これらフィールドの中には２桁の
フィールド４８ａが含まれる。フィールド４８ａには、
フィールド４８ａ自体の桁数を除いたフレーム２０の総
フレーム長が書き込まれる。２桁の機能コード・フィー
ルド４８ｂには、フレームのタイプが書き込まれる。６
３という値をフィールド４８ｂに書き込むことによっ
て、当該フレームがメッセージ詳細データ・フレーム２
０であることを明示するようになっている。さらに、メ
ッセージ・タイプ・フィールド４８ｃには、送信される
メッセージのタイプ（すなわち、現メッセージが正規メ
ッセージ、受信確認メッセージ、又は、後述するような
非配達通知（ ＮＤＮ ：ｎｏｎ−ｄｅｌｉｖｅｒｙ−
ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージのいずれである
か）が書き込まれる。２桁のメッセージ本体長フィール
ド４８ｄには、送信される現メッセージの音声部分の長
さが書き込まれるが（但し、音声を含む場合）、その長
さは分単位表示にして００から９９分である。後の記述
で明らかになるように、受信確認メッセージや転送メッ
セージについては、この本体長はゼロとなるであろう。
フィールド４８ｅは、１桁のメッセージ・タグであり、
現メッセージが通常、プライベート、緊急、又は、プラ
イベートで且つ緊急のいずれとして扱われるべきかを示
すためのものである。４８ｆ乃至４８ｋのフィールド
は、１２桁を含み、メッセージを送信したときの日付と
時刻が書き込まれる。フィールド４８ｌには、最大２９
文字で符号化して５８桁となるＡＳＣＩＩメッセージ・
テキストの件名を書き込むためのものである。フィール
ド４８ｍに書き込まれた単一桁のＤＴＭＦ区切り文字
（ ＃ ）は、ＡＳＣＩＩ件名フィールド４８ｌの終端
を示すためのものである。最後に、２桁の検査合計はフ
ィールド４８ｈに書き込まれて送信される。

【００４４】セッション機能ビットマップに従って確立
されたセッションにおいてテキスト・プロパゲーション
機能がアクティブでないときには、フィールド４８ｌ中
のテキスト・データは全く送信されない。その代わり、
フィールド４８ｋの直後には、フィールド４８ｍに書き
込まれた区切り文字が続くことになる。

【００４５】受信側ＶＭシステムは、一旦フレーム２０
を受け取ると、応答コードを含む応答フレームを送信側
ＶＭシステム１００に返信することによって、このメッ
セージに対する受信確認を行うようになっている。この
リターン・コードには多数の値が用意さている。例え
ば、リターン・コード値ＲＣ２は、フィールド４８ｆ乃
至４８ｋに書き込まれたデータが無効であることを示
す。また、値ＲＣ３は、フィールド４８ｃに書き込まれ
たメッセージ・タイプが無効であることを示す。また、
値ＲＣ４は、フィールド４８ｌに書き込まれた件名が無
効であることを示す。

【００４６】一旦、メッセージ識別フレーム２０が送信
され、且つ、成功裡に受信確認されると、現在のメッセ
ージの送信者についての情報を提供するための送信者情
報フレーム２２が受信側ＶＭシステムに送信される（図
２を参照のこと）。送信者は、典型的には、送信側ＶＭ
システム１００上でアカウントを持ったユーザである。
図７には、送信者情報フレーム２２のフォーマットを図
解している。送信者情報フレーム２２は、５０ａ乃至５
０ｉからなる１０個のフィールドを含んだ１３乃至６７
桁で構成される。

【００４７】フレーム２２の最初のフィールド、すなわ
ちフィールド５０ａには、フレーム２２のフレーム長が
桁数で書き込まれる。２桁のフィールド５０ｂは、６０
という値を持つことによって、このフレームが送信者情
報データ・フレームであることを明示するようになって
いる。フィールド５０ｃは、送信者を受信側システム上
に居る遠隔（リモート）的な音声ユーザ（ ＲＶＵ ）
として取り扱うべきかどうかを示すためのものである。
もしフィールド５０ｃの値がゼロでなければ、メッセー
ジの送信者を受信側システム上のＲＶＵとして取り扱う
べきである。特に、このフィールドに１が書き込まれて
いるときには、例えば５０ｈ（後述）に書き込まれてい
るような送信者についての情報を、受信側ＶＭシステム
上の遠隔（リモート）ユーザ・データベースに書き加え
るべきことが示されている。また、このフィールド中に
１より大きな値が書き込まれていることは、送信者の名
前の口頭バージョンが現メッセージの一部としてこれか
ら送信されるであろうことを示している。フィールド５
０ｄには、送信者のアドレス・タイプが書き込まれる。
フィールド５０ｅには、送信者についての消費者位置番
号が書き込まれる。ここで言う消費者位置番号は、ノー
テルのネットワーク・メッセージ・システム（ ＮＭＳ
）製品でサポートされている。もし、送信側ＶＭがこ
のフィールドを使用しない場合には、値ゼロが書き込ま
れるであろう。フィールド５０ｆは、送信者の音声メー
ルボックス・アドレスを書き込むための、２乃至１８桁
からなる可変長フィールドである。フィールド５０ｆの
後には、フィールド５０ｇに書き込まれた区切り文字
（ＤＴＭＦで ＃ ）が続くようになっている。フィー
ルド５０ｈは、送信者名をＡＳＣＩＩ形式に符号化した
バージョンを書き込むためのものであり、最大３８桁で
ある。フィールド５０ｈは可変長なので、フィールドｈ
の終端を示すための区切り文字フィールド５０ｉが設け
られている。最後に、フィールド５０ｊには、フレーム
２２の２桁の検査合計が書き込まれる。

【００４８】フィールド４２ｃに書き込まれたセッショ
ン機能ビットマップに従って確立されたセッションにお
いてテキスト・プロパゲーション機能がサポートされて
いないならば、フィールド５０ｈ中のテキスト・データ
は全く送信されない。その代わり、フィールド５０ｇの
直後には、フィールド５０ｉに書き込まれた区切り文字
が続くことになる。同様に、ＲＶＵプロパゲーション機
能がサポートされていない場合には、フィールド５０ｃ
には値 ０ が書き込まれるであろう。

【００４９】受信者ＶＭは、送信者情報フレーム２２に
応答して、応答コードを含んだ応答フレームを送信する
ことによって、送信者情報フレーム２２を適切に受理し
たことを示すようになっている。応答コードとして多数
の値が用意されている。例えば、応答コードＲＣ２は、
アドレス・タイプが無効であることを示す。また、ＲＣ
３は、ＮＭＳ位置コードが受信者ＶＭシステムのデータ
ベース中で定義されたいずれの送信側ＶＭシステムの位
置コードとも一致しないことを示す。また、ＲＣ４は、
送信者のテキスト名が無効と思われることを示す。ま
た、ＲＣ５は、受信側のＶＭが送信者をＲＶＵとして追
加するか又は更新するという問題に直面していることを
示す。

【００５０】送信者情報フレーム２２を送信した後、送
信側ＶＭシステム１００は、音声フレーム２８又は受信
者情報フレーム２４のうちのいずれか一方を送信する。
送信するフレームのタイプは、送信者の名前を口頭で言
ったメッセージを表した音声データが送信されるかどう
かに依存する。このことは、送信者情報フレーム２２の
フィールド５０ｃに値２が書き込まれたかどうかで示さ
れる。もし、送信者の名前が送付されるのであれば、フ
レーム２８中のオーディオ・データ（すなわち「再生／
記録音声」）が送信側ＶＭシステム１００によって再生
される。受信側ＶＭシステムはこれを記録する。メッセ
ージの終端は、ＤＴＭＦトーン ＊ で区切られる。も
し、予期したメッセージ長（これはフレーム４８ｄに書
き込まれている）より前に区切り文字がないならば、受
信側ＶＭシステムはこれをエラーとして検出する。後の
記載で明らかになるように、もし、セッションに対して
ＲＶＵプロパゲーションがサポートされていないことを
フィールド４２ｃ中のセッション機能ビットマップが示
していれば、口頭の名前は一切送信されない。

【００５１】口頭で言った送信者名を含んだ音声フレー
ム２８が送信された後（若しくは、送信者の口頭で言っ
た名前が全く送信されなかった場合は、メッセージ識別
子フレームの直後）、受信者情報フレーム２４が送信さ
れる。

【００５２】図８には、このフレーム２４のフォーマッ
トが図解されている。受信者情報フレーム２４は、１０
個のフィールド５２ａ乃至５２ｉで構成され、１５乃至
６４桁のデータからなる。２桁のフィールド５２ａに
は、フレーム２４のフレーム長が書き込まれる。２桁の
フィールド５２ｂは、値６１又は６２を書き込むことに
よって、当該フレーム２４が受信者情報フレームである
ことを明示するようになっている。２桁のフレーム５２
ｃには、アドレス・タイプが書き込まれる。３桁のフレ
ーム５２ｄには、場所識別子が書き込まれる（但し、０
０１から５００までの間）。２桁のフィールド５２ｅに
は、受信側ＶＭシステムのＮＭＳ位置番号（但し、００
から５９までの間）が書き込まれる。もし、受信側ＶＭ
システムがＮＭＳをサポートしていないならば、この値
は常に００となるであろう。可変長のフィールド５２ｆ
には、受信者の音声メールボックス番号が書き込まれ
る。このメールボックス番号は、２乃至１８桁である。
メールボックス番号の後には、フィールド５２ｇに書き
込まれた区切り文字（ＤＴＭＦで ＃ ）が続く。その
後に、ＤＴＭＦに符号化された受信者名のＡＳＣＩＩ表
示をフィールド５２ｈに書き込んで送信してもよい。フ
ィールド５２ｈも可変長フィールドであり、０から３８
までの値をとる。フィールド５２ｈの後には、フィール
ド５２ｉに書き込まれた区切り文字（ＤＴＭＦで ＃
）が続く。最後に、フィールド５２ｊには、フレーム
２４についての２桁の検査合計が書き込まれる。

【００５３】受信者情報フレーム２４を受け取った後、
受信側ＶＭシステムは、再び、応答コードを含んだ応答
フレームを送信側ＶＭシステム１００に送信する。応答
コードは、フィールド５２ｃに書き込まれたアドレスが
無効であること（ＲＣ２）、ＮＭＳコードがフィールド
５２ｄに書き込まれた受信側ＶＭシステムと一致しない
こと（ＲＣ３）、又は、フィールド５２ｈに書き込まれ
た受信者名が無効であることなどを示すことができる。

【００５４】図２に図示しているように、受信者情報フ
レーム２４の後には、別の受信者情報フレーム２４、再
生／記録音声フレーム２８、添付情報フレーム３０、又
は、タイム・スタンプ・フレーム２６のいずれかが続く
ようになっている。各メッセージについての受信者情報
フレーム２４の数は、受信側ＶＭシステム上で同一のメ
ッセージの送信を意図された受信者の数に依存する。各
受信者は、個々の受信者情報フレーム２４によって識別
される。フィールド５２ｂに値６２を書き込むことによ
って、メッセージについての最後の受信者情報フレーム
２４であることが識別される。それ以外の全ての受信者
情報フレーム２４は、フィールド５２ｂに値６２を書き
込むことで識別される。

【００５５】図９には、タイム・スタンプ・フレーム２
６のフォーマットが図解されている。タイム・スタンプ
・フレーム２６は、９個のフィールド５４ａ乃至５４ｉ
からなり、１６桁のフレーム長を有している。フィール
ド５４ａにはフレーム長が書き込まれる。２桁のフィー
ルド５４ｂは、値６５を書き込むことによって、当該フ
レームがタイム・スタンプであることを示すようになっ
ている。フィールド５４ｃ乃至５４ｈは、当該メッセー
ジが最初に送信されたときの日、月、年、時、分、秒を
表示するためのものである。例えば複数の添付がある場
合のように、複数のメッセージがタイム・スタンプに関
連する場合には、フィールド５４ｃ乃至５４ｈは、最初
の関連するメッセージが最初に送信された時刻を表すよ
うになっている。これらのフィールドの後に、２桁の検
査合計を書き込んだフィールド５４ｉが続く。

【００５６】タイム・スタンプ・フレーム２６に応答し
て、応答コードを含んだ応答フレームが再び受信者から
送信者に送信される。この応答コードは、単に日付が無
効（すなわちＲＣ２）か有効かを示すだけである。

【００５７】図２に図解しているように、タイム・スタ
ンプ・フレーム２６が送信された後、ＮＤＮ受信者情報
フレーム３２、添付情報フレーム３０、又は、メッセー
ジ終了フレーム３４が送信される。

【００５８】図１０には、ＮＤＮ受信者情報フレーム３
２のフォーマットが図解されている。ＮＤＮ受信者情報
フレーム３２は、先行して送信されたメッセージ、すな
わち受信側ＶＭシステムによって送信側ＶＭシステム１
００に先行して送信されたメッセージが配達されていな
いことを示すためのものである。実際には、メッセージ
に非配達通知（ ＮＤＮ ）が付された上で、受信側Ｖ
Ｍシステムに返信されるようになっている。フレーム３
２は、７個のフィールド５６ａ乃至５６ｇを持った１１
乃至１７桁のデータで構成される。２桁のフィールド５
６ａには、フレーム３２のフレーム長が書き込まれる。
２桁のフィールド５６ｂは、値６６又は６７を書き込む
ことによって、当該フレームがＮＤＮ受信者情報フレー
ムであることを明示するためのものである。６６という
機能コードは、ＮＤＮが送信すべき幾つかのメッセージ
のうちの１つであることを示す。メッセージの返信が意
図されたが配達はされなかった受信側ＶＭシステム上の
各ユーザには、１つのＮＤＮが送信される。フィールド
５６ｂに書き込まれる６７という機能コードは、１又は
それ以上のＮＤＮフレームのうちの最後のフレームであ
ることを示す。２桁のフィールド５６ｃには、アドレス
・タイプが書き込まれる。２桁のフィールド５６ｄに
は、ＮＭＳ位置番号が書き込まれる。可変長フィールド
５６ｅは、受信者メールボックス番号を示すためのもの
であり、２乃至１８桁を有している。フィールド５６ｆ
には、フィールド５６ｅに書き込まれたメールボックス
番号の終端を示すための区切り文字（ＤＴＭＦで ＃
）が書き込まれる。上述と同様に、２桁のフィールド
５６ｇには、フレーム３２の検査合計が書き込まれる。

【００５９】ＮＤＮ受信者情報フレーム３２に対する応
答フレームが、受信側ＶＭシステムから送信側ＶＭシス
テム１００に送信される。この応答フレームには応答コ
ードが含まれる。応答コードは、ＮＭＳコードのアドレ
ス・タイプが無効であること（ＲＣ２又はＲＣ３）や、
ＮＤＮフレームが有効に受け取られたことなどを示すこ
とができる。

【００６０】別のメッセージに添付されている１つのメ
ッセージを配達するために、添付情報フレーム３０が使
用される。これは、２つのＶＭシステム間における単一
のメッセージ交換の一部として行われる。図１１には、
添付情報フレーム３０のフォーマットが図解されてい
る。添付情報フレーム３０は、６桁からなり、４個のフ
ィールド５８ａ乃至５８ｄを含んでいる。２桁のフィー
ルド５８ａには、フレーム３０のフレーム長０６が書き
込まれる。２桁のフィールド５８ｂは、機能コード６４
を書き込むことで、当該フレームが添付情報フレームで
あることを示すようになっている。２桁のフレーム５８
ｃは、添付された音声の長さを分単位で示すようになっ
ている。２桁のフィールド５８ｄには、当該添付情報フ
レーム３０の検査合計が書き込まれる。

【００６１】図２で示すように、ＮＤＮフレーム３２の
後（但し、未配達の添付の場合）、タイム・スタンプ・
フレーム２６の後、先行する添付フレーム３０の後（但
し、複数の添付が転送されている場合）、音声フレーム
２８の後（但し、送信者が別のメッセージに添付した場
合）、又は、受信者情報フレーム２４の直後に、添付情
報フレーム３０を送信することができる。添付情報フレ
ーム３０の後には、音声フレーム２８、又は、現添付に
音声メッセージが関連していない場合には別の添付フレ
ーム３０が続く。添付フレーム３０を受け取った後、受
信側システムは応答フレームを送信するようになってい
る。

【００６２】メッセージが完全に転送されると、メッセ
ージ終了フレーム３４が転送される。このメッセージ終
了フレームのフォーマットは、ＡＭＩＳ−Ａプロトコル
で定義されている。

【００６３】その後、さらにメッセージ詳細フレーム２
０で開始するフレームを送信してもよい。メッセージ転
送が完結した後は、ＡＭＩＳ−Ａプロトコルに従って、
セッション終了フレーム３６も送信される。

【００６４】例えば動作中に、送信側ＶＭシステム１０
０と受信側システムによって、セッション機能ビットマ
ップを含んだ拡張セッションが確立されてもよい。メッ
セージ詳細フレーム２０を送信することによって拡張セ
ッションが初期化された後に、ＶＭシステム１００は正
規のメッセージを送信してもよい。その後に、送信者情
報フレーム２２、送信者名を含んだ音声フレーム２８
（但し、ＲＶＵプロパゲーションがサポートされている
場合）、１又はそれ以上の受信者情報フレーム２４、音
声フレーム２８、及び、メッセージ終了フレーム３４が
順次続くことになっている。

【００６５】同様に、送信側ＶＭシステム１００は、メ
ッセージ詳細フレーム２２を送信することによって、１
又はそれ以上の添付を含んだメッセージを交換セッショ
ンの一部として送信してもよい（但し、ＲＶＵプロパゲ
ーションがない場合）。その後には、１又はそれ以上の
受信者情報フレーム２４、音声フレーム２８、１又はそ
れ以上の添付フレーム３０と音声フレーム２８の集合、
及び、メッセージ終了フレーム３４が順次続くことにな
っている。

【００６６】勿論、上述したように、この動作例におけ
る各フレームは、受信側ＶＭシステムが送信する応答フ
レームによって受信確認されるであろう。

【００６７】上述では、セッション機能ビットマップの
使用は、ＶＭシステムにおけるテキスト・プロパゲーシ
ョン、ネットワーク同報通信、及び、ＲＶＵプロパゲー
ションの各機能のサポートの識別に限定されているが、
セッション機能ビットマップを他の数余の音声メール・
システム機能に使用することが容易であるという点を充
分理解されたい。例えば、添付やＮＤＮメッセージのサ
ポートを識別するために機能ビットマップを使用するこ
とができる。同様に、セッションの開始時に全てのセッ
ション・ビットマップを交換することが好ましいが、必
要に応じてセッションの間に交換することもできるであ
ろう。図面とともに説明してきたように、機能の有無は
セッション機能ビットマップによって示される。機能の
有無によって、ＶＭシステム間でどのフレームを転送す
るか、あるいは、フレーム中のどのフィールドを転送す
るかを決定できるので、柔軟性に大変富んでいる。かか
る柔軟性は、とりわけ、ここでは開示していない異なる
種々の機能を提供するシステム間でのメッセージ交換を
可能にする点で価値がある。

【００６８】本発明は本明細書で記述された実施形態に
限定されない、ということを充分理解されたい。本明細
書は、本発明を実現する上で好適な実施形態を単に図面
とともに解説したものである。本明細書中に開示された
実施例についての形態、要素部品の配置、および動作に
おけるステップの詳細や動作の順序等についての各種の
修正は、容易に想到されるであろう。むしろ、特許請求
の範囲で定義されているように、本発明の要旨の範囲内
でのかかる修正は本発明に包含されると把握されたい。

【００６９】

【発明の効果】以上詳記したように、本発明の音声メー
ル・システムおよび音声メール・システム間の通信方法
によれば、種々の機能を持つＶＭシステム間においてメ
ッセージの交換を行うことが可能となり、優れた音声メ
ール・システム、及び、音声メール・システム間通信方
法を提供することができる。

【００７０】また、本発明の音声メール・システムおよ
び音声メール・システム間の通信方法によれば、双方の
システムがサポートする機能によって使用されないデー
タを送信しないことによって、２つのシステム間でのメ
ッセージ交換に必要な総時間を短縮することができるの
で有利である。

【００７１】さらに、本発明の音声メール・システムお
よび音声メール・システム間の通信方法によれば、双方
のシステムがサポートする共通の機能の最大限のセット
が使用するメッセージ・データを交換することができ
る。これによって、ＶＭシステム間で利用可能な機能を
最大限に活用することができる。

【図面の簡単な説明】

【図１】 本発明の１つの実施例に従った音声メール・
システムのブロック図である。

【図２】 送信側音声メール・システムから受信側音声
メール・システムに交換される、本発明の１つの実施例
に従ったメッセージ・データ・フレームを示した図であ
る。

【図３】 図２で図解されたデータ・フレームのフォー
マットを示した図である。

【図４】 受信側音声メール・システムから送信側音声
メール・システムに送信される、本発明の１つの実施例
に従ったデータ・フレームのフォーマットを示した図で
ある。

【図５】 本発明の１つの実施例に従って使用される機
能ビットマップのフォーマットを示した図である。

【図６】 図２で図解されたデータ・フレームのフォー
マットを示した図であり、より具体的には、メッセージ
詳細フレーム２０のフォーマットを示した図である。

【図７】 図２で図解された種々のデータ・フレームの
うちの１つのフォーマットを示した図であり、より具体
的には、送信者情報フレーム２２のフォーマットを示し
た図である。

【図８】 図２で図解された種々のデータ・フレームの
うちの１つのフォーマットを示した図であり、より具体
的には、受信者情報フレーム２４のフォーマットを示し
た図である。

【図９】 図２で図解された種々のデータ・フレームの
うちの１つのフォーマットを示した図であり、より具体
的には、タイム・スタンプ・フレーム２６のフォーマッ
トを示した図である。

【図１０】 図２で図解された種々のデータ・フレーム
のうちの１つのフォーマットを示した図であり、より具
体的には、ＮＤＮ（非配達通知）受信者情報フレーム３
２のフォーマットを示した図である。

【図１１】 図２で図解された種々のデータ・フレーム
のうちの１つのフォーマットを示した図であり、より具
体的には、添付情報フレーム３０のフォーマットを示し
た図である。

【符号の説明】

１００…送信側音声メール・（ＶＭ）システム、１０２
…ＣＰＵ、１０４…ストレージ・メモリ、１０６…プロ
グラム・メモリ、１０８…ＰＢＸインターフェース及び
ＤＴＭＦ発生器、１１０…構内交換機（ＰＢＸ）

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ゲイリー・ロングスター カナダ、エル２エヌ、１アール５、オンタ リオ州、セント・キャサリンズ、リンウェ ル・ドライブ 48 (72)発明者 ジャヌズ・マーザック カナダ、エル８ジェイ、１エイチ・ゼッ ト、オンタリオ州、ストニー・クリーク、 エレクトラ・コート ９ (72)発明者 マービン・ドクルツ カナダ、エル４ケー、３ジェイ６、オンタ リオ州、コンコード、マリタ・プレイス 34 (72)発明者 ブライアン・オリバー カナダ、エル４ジー、６ピー８、オンタリ オ州、オーロラ、コベント・クレッセント 213

Claims (13)

【特許請求の範囲】
1. 【請求項１】 メッセージ・データ・フレームからなる
   音声メール・メッセージを第１及び第２の音声メール・
   システム間で交換する方法であって、 ａ）前記第１及び第２のシステム間でメッセージ交換セ
   ッションを確立するステップと、 ｂ）前記第１のシステムにおいて利用可能な音声メール
   ・システム機能を表した第１のインジケータを前記第１
   のシステムから前記第２のシステムに送信するステップ
   と、 ｃ）前記第２のシステムにおいて利用可能な音声メール
   機能を表した第２のインジケータを前記第２のシステム
   から前記第１のシステムに送信するステップと、 ｄ）前記第１及び第２のシステムの双方で利用可能な共
   通の機能の最大限のセットを前記第１及び第２のシステ
   ムにおいて判別するステップと、ｅ）前記共通の機能セ
   ットに含まれる機能によって使用されるメッセージ・デ
   ータ・フレームのみを交換するステップとを具備するこ
   とを特徴とする音声メール・システム間の通信方法。
2. 【請求項２】 さらに、前記第１のシステムでサポート
   される機能を表した第１のシステム・ビットマップを前
   記第１のシステムにおいて形成するステップを含み、前
   記第１のシステム・ビットマップは複数のビットで構成
   され、各ビットは前記第１のシステムでサポートされる
   機能を表していることを特徴とする請求項１に記載の音
   声メール・システム間の通信方法。
3. 【請求項３】 さらに、前記第２のシステムでサポート
   される機能を表した第２のシステム・ビットマップを前
   記第２のシステムにおいて形成するステップを含み、前
   記第２のシステム・ビットマップは複数のビットで構成
   され、各ビットは前記第２のシステムでサポートされる
   機能を表していることを特徴とする請求項２に記載の音
   声メール・システム間の通信方法。
4. 【請求項４】 ステップｄは前記第１及び第２のシステ
   ム・ビットマップ中のビット同士の論理的な積を求める
   ステップで構成されることを特徴とする請求項３に記載
   の音声メール・システム間の通信方法。
5. 【請求項５】 ステップｂは前記第１のシステム・ビッ
   トマップを送信するステップで構成されることを特徴と
   する請求項３に記載の音声メール・システム間の通信方
   法。
6. 【請求項６】 ステップｃは、前記第２のシステムにお
   いて、前記第１及び第２のシステム・ビットマップ中の
   ビット同士の論理的な積を求めることによってセッショ
   ン・ビットマップを形成するステップと、前記セッショ
   ン・ビットマップを前記第２のシステムから前記第１の
   システムに送信するステップとで構成されることを特徴
   とする請求項５に記載の音声メール・システム間の通信
   方法。
7. 【請求項７】 前記メッセージ・データの一部はＤＴＭ
   Ｆトーンを用いて転送されることを特徴とする請求項６
   に記載の音声メール・システム間の通信方法。
8. 【請求項８】 前記第１のシステム・ビットマップは第
   １の１０進数ビットマップに変換され、前記第１の１０
   進数ビットマップはＤＴＭＦトーンを用いて送信される
   ことを特徴とする請求項７に記載の音声メール・システ
   ム間の通信方法。
9. 【請求項９】 前記セッション・ビットマップは、１０
   進数セッション・ビットマップに変換され、前記１０進
   数セッション・ビットマップはＤＴＭＦトーンを用いて
   送信されることを特徴とする請求項８に記載の音声メー
   ル・システム間の通信方法。
10. 【請求項１０】 第２の音声メール・システムと相互接
    続するための音声メール・システムであって、前記第２
    の音声メール・システムと通信するために前記音声メー
    ル・システムを接続せしめるためのインターフェース
    と、前記インターフェースに接続されたプロセッサを具
    備し、前記プロセッサは、前記インターフェースを介し
    て前記第２の音声メール・システムと音声メール・メッ
    セージを交換するようになっているとともに、 ａ）前記第２の音声メール・システムとメッセージ交換
    セッションを確立し、 ｂ）前記音声メール・システムにおいて利用可能な音声
    メール・システム機能を表した第１のインジケータを送
    信し、 ｃ）前記第２の音声メール・システムにおいて利用可能
    な音声メール機能を表した第２のインジケータを前記第
    ２の音声メール・システムから受信し、 ｄ）前記音声メール・システム及び前記第２の音声メー
    ル・システムの双方で利用可能な共通の機能の最大限の
    セットを判別し、 ｅ）前記共通の機能セットに含まれる機能によって使用
    されるメッセージ・データ・フレームのみを前記第２の
    音声メール・システムと交換するようになっていること
    を特徴とする音声メール・システム。
11. 【請求項１１】 前記プロセッサは、さらに、前記音声
    メール・システムでサポートされる機能を表した第１の
    システム・ビットマップを形成するようになっており、
    前記第１のシステム・ビットマップは複数のビットで構
    成され、各ビットは前記音声メール・システムでサポー
    トされる機能を表し、前記第１のインジケータは前記シ
    ステム・ビットマップから形成されることを特徴とする
    請求項１０に記載の音声メール・システム。
12. 【請求項１２】 前記インターフェースは、さらに、前
    記第２の音声メール・システムと通信するためのＤＴＭ
    Ｆトーン発生器を具備することを特徴とする請求項１０
    に記載の音声メール・システム。
13. 【請求項１３】 前記インターフェースはＤＴＭＦトー
    ン発生器と接続されていることを特徴とする請求項１０
    に記載の音声メール・システム。