(57)【要約】【課題】音声および／またはマルチメディアメッセージのために大記録容量を備える必要はなく、マルチメディアメッセージ内に情報を挿入したり、マルチメディアメッセージをフィルタにかけたりすることができる手段を提供する。【解決手段】発呼使用者にメッセージ受付メッセージを流す過程（２０２）と、発呼使用者が発信したボイスメッセージをボイスサーバーに記録する過程（２０４）とを有し、記録されたボイスメッセージに対応するファイルと、発呼使用者に対応するマルチメディア情報とを有するマルチメディアメッセージを作成する過程（２０６）と、マルチメディアメッセージを被呼使用者の端末に伝達する過程（２０７）と、ボイスメッセージ及びマルチメディアメッセージを消去する過程（２１５，２１６）とを有する。【選択図】図２
2004129270.tif 000002
【特許請求の範囲】
【請求項１】
　被呼使用者を呼び出す発呼使用者が、ボイスメッセージサーバーに接続することによる、インスタントボイスメッセージを提供する方法において、
　発呼使用者にメッセージ受付メッセージを流す過程と、
　発呼使用者が発信したボイスメッセージを、ボイスサーバーに記録する過程とを有し、
　さらに、記録されたボイスメッセージに対応するファイルと、発呼使用者に対応するマルチメディア情報とを有するマルチメディアメッセージを、作成する過程と、
　マルチメディアメッセージを、被呼使用者の端末に伝達する過程と、
　ボイスメッセージ及びマルチメディアメッセージを消去する過程とを有することを特徴とする、インスタントボイスメッセージング方法。
【請求項２】
　マルチメディアメッセージが作成されたら、ボイスサーバーからボイスメッセージを消去することを特徴とする、請求項１に記載の方法。
【請求項３】
　マルチメディアメッセージが被呼使用者に伝達されたら、該マルチメディアメッセージを消去することを特徴とする、請求項１または請求項２に記載の方法。
【請求項４】
　被呼使用者に宛てられたマルチメディアメッセージを回収するために、被呼使用者がマルチメディア・クライアント端末のパラメータを設定して、マルチメディアメッセージサーバーに問い合わせることを特徴とする、請求項１から請求項３のいずれか一つに記載の方法。
【請求項５】
　マルチメディア・クライアント端末のパラメータを被呼使用者が設定して、このクライアント端末が、作成されたマルチメディアメッセージに対応する入力メッセージを受諾するようにすることを特徴とする、請求項１から請求項４のいずれか一つに記載の方法。
【請求項６】
　マルチメディアメッセージの作成のために、データベースに接続して、マルチメディアメッセージのフォーマッティングのための、被呼使用者に組み合わされた作成プリファランスを取得することを特徴とする、請求項１から請求項５のいずれか一つに記載の方法。
【請求項７】
　マルチメディアメッセージの作成のために、データベースに接続して、発呼使用者に組み合わされた情報を取得し、該情報をマルチメディアメッセージに含めることを特徴とする、請求項１から請求項６のいずれか一つに記載の方法。
【請求項８】
　マルチメディアメッセージが、ＨＴＭＬ型のフォーマッティング言語を用いて作成されることを特徴とする、請求項１から請求項６のいずれか一つに記載の方法。
【請求項９】
　作成されたマルチメディアメッセージが、被呼使用者の識別子を有していることを特徴とする、請求項１から請求項８のいずれか一つに記載の方法。
【請求項１０】
　マルチメディアメッセージの有する情報が、マルチメディアメッセージの読み出し情報メッセージの発信を受取人が要求するためのものであることを特徴とする、請求項１から請求項９のいずれか一つに記載の方法。
【請求項１１】
　ボイスメッセージサーバーに接続された発呼使用者側のボイスメッセージを受信するのに適したボイスメッセージサーバーを有するインスタントボイスメッセージング装置において、
　ボイスメッセージに対応し、かつ、被呼使用者に宛てられたファイルを有するマルチメディアメッセージを作成するのに適した変換サーバーに、ボイスメッセージサーバーが接続され、
　また、装置の使用者に関する情報を有するデータベースサーバーに、変換サーバーとマルチメディアメッセージサーバーが接続されていることを特徴とするインスタントボイスメッセージング装置。
【請求項１２】
　マルチメディアメッセージをマルチメディア・クライアント端末に転送するのに適したマルチメディアメッセージサーバーに、変換サーバーが接続されていることを特徴とする、請求項１１に記載の装置。
【請求項１３】
　マルチメディアメッセージサーバーが、マルチメディアゲートウェイを介してマルチメディア・クライアント端末に接続されていることを特徴とする、請求項１２に記載の装置。
【請求項１４】
　メッセージの宛先使用者によってダウンロードされなかったマルチメディアメッセージを保存するための大容量保存ユニットを、マルチメディアメッセージサーバーが有していることを特徴とする、請求項１１から請求項１３のいずれか一つに記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、インスタントボイスメッセージング方法と、かかる方法を実施するためのインスタントボイスメッセージング装置に関する。
【０００２】
　本発明の分野は、電話とボイスメッセージサービスの分野である。
　本発明の分野は、より詳細には、メッセージサービスに加入している被呼側の使用者が出られないときに発呼使用者のメッセージを受けることを可能にする音声留守番応答機の分野である。
【０００３】
　本発明の一つの目的は、ボイスメッセージが宛てられた使用者が録音後に聴取する際のボイスメッセージをより機能的にすることである。
　本発明の別の目的は、ボイスメッセージをサーバーに保存する必要を回避することである。
　本発明のさらに別の目的は、電話事業者が、ボイスメッセージサービスの提供や管理をできるようにすることである。
【背景技術】
【０００４】
　現状技術において、携帯電話事業者が提供しているようなボイスメッセージサービスが周知である。
　携帯電話事業者への加入者が電話に出られないとき、電話に出られない使用者を呼び出そうとしている発呼使用者は、自動的にボイスボックスに接続される。
　このとき、ボイスボックスは、受付メッセージを流し、その後、発呼使用者はメッセージを録音することができる。
　このボイスボックスへの接続は、固定または携帯を問わず、かならず電話機によって行われる。
【０００５】
　他方で、発呼使用者によって録音されたボイスメッセージは、ボイスボックスを収納した、一般的にボイスサーバーと呼ばれる機器に記録される。
　宛先の加入者がメッセージを聴き、場合によってはそれを消去するまで、ボイスメッセージはこのサーバーに記録されている。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
　現状技術においては、さらに、電話機を使わずに携帯電話ネットワークの加入者にボイスメッセージを残すことは不可能である。
　なぜなら、ボイスボックスは電話番号を介してしか利用できないからである。
【０００７】
　現状技術において、携帯電話事業者がボイスメッセージサービスを実施することは過大な負担でもあるが、その加入者が直接電話に出たくないすべての場合や、その加入者が携帯電話事業者の圏外にいるすべての場合に対応するためには不可欠である。
【課題を解決するための手段】
【０００８】
　本発明においては、ボイスメッセージサーバーにボイスメッセージ変換サーバーを接続することによって、これらの問題を解決する。
　これによって、ボイスメッセージサーバーがボイスメッセージを記録すると直ぐに、それが変換サーバーに転送される。
　ボイスメッセージサーバーは、例えば、ボイスメッセージ受信日、ボイスメッセージを残した人の識別子などのボイスメッセージに関する情報も転送する。
　これらの情報から、変換サーバーが、これらの情報の成形を有するマルチメディアメッセージを作成する。
　この成形は、日付、発信元の情報、およびボイスメッセージ自体を有するＨＴＭＬ、ＸＭＬ、またはその他のフォーマットのファイルの形を取ることができる。
　いったん変換サーバーがこのメッセージを作成すると、それはつぎにＭＭＳ（Ｍｕｌｔｉｍｅｄｉａ　Ｍｅｓｓａｇｉｎｇ　Ｓｅｒｖｉｃｅ）型のメッセージサーバーに転送される。
【０００９】
　一般的に、接続を可能にするために、ＭＭＳサーバーは端末に通知を送る。
　端末はメッセージを直ちに自動的にダウンロードするか、あるいはバッチモードで、端末の所有者の確認に基づくように構成されている。
【００１０】
　例えば、このとき、このタイプのボイスメッセージサービスに加入している使用者は、端末がＭＭＳ型のメッセージを受信できるように自分の端末を構成する。
　このとき、その人の端末は、定期的にＭＭＳサーバーに接続されるか、ＭＭＳサーバー側から入ってくるリクエストを受諾する。
　これによって、端末は、ボイスメッセージを有するマルチメディアメッセージを圧縮ファイルの形で受信することができる。
　圧縮ファイルは、端末使用者があとから利用できるように記録される。
【００１１】
　ボイスメッセージは、変換サーバーが、ボイスメッセージをＭＭＳサーバーに伝達するために回収するまでしかボイスサーバーに保存されない。
　マルチメディアメッセージは、ボイスメッセージが宛てられた使用者の端末に転送されるまでしかＭＭＳサーバーに記録されない。
　したがって、音声および／またはマルチメディアメッセージのために大記録容量を備える必要はない。
　なぜなら、本発明では、それらは、使用者の端末内に保存されるからである。
【００１２】
　くわえて、事業者がＭＭＳサーバーを管理しているので、事業者はマルチメディアメッセージ内に情報を挿入したり、マルチメディアメッセージをフィルタにかけたりすることができる。
【００１３】
　したがって、本発明は、被呼使用者を呼び出す発呼使用者がボイスメッセージサーバーに接続されるインスタントボイスメッセージサービスの方法において、
−発呼使用者にメッセージ受付メッセージを流す過程と、
−発呼使用者が発信したボイスメッセージをボイスサーバーに記録する過程、
を有し、該方法がさらに、
−記録されたボイスメッセージに対応するファイルと発呼使用者に対応するマルチメディア情報とを有するマルチメディアメッセージを作成する過程と、
−マルチメディアメッセージを端末に伝達する過程と、
−ボイスメッセージとマルチメディアメッセージを消去する過程、
を有することを特徴とする方法を対象とする。
　すなわち、本発明の課題を解決するための手段は、次のとおりである。
　第１に、被呼使用者（１０２）を呼び出す発呼（２０１）使用者（１０１）が、ボイスメッセージサーバー（１０５）に接続することによる、インスタントボイスメッセージサービス方法において、
　発呼使用者にメッセージ受付メッセージを流す過程（２０２）と、
　発呼使用者が発信したボイスメッセージを、ボイスサーバーに記録する過程（２０３−２０４）とを有し、
　さらに、記録されたボイスメッセージに対応するファイルと、発呼使用者に対応するマルチメディア情報とを有するマルチメディアメッセージを、作成する過程（２０６）と、
　マルチメディアメッセージを、被呼使用者の端末に伝達する過程（２０７）と、
　ボイスメッセージとマルチメディアメッセージとを消去する過程（２１６，２１５）とを有することを特徴とする、インスタントボイスメッセージサービス方法。
　第２に、マルチメディアメッセージがいったん作成されたら、ボイスサーバーからボイスメッセージを消去する（２１６）ことを特徴とする、上記第１に記載の方法。
　第３に、マルチメディアメッセージがいったん被呼使用者に伝達されたら、該マルチメディアメッセージを消去する（２１５）ことを特徴とする、上記第１または上記第２に記載の方法。
　第４に、被呼使用者に宛てられたマルチメディアメッセージを回収するために、被呼使用者がマルチメディア・クライアント端末のパラメータを設定（２１２）して、マルチメディアメッセージサーバーに問い合わせることを特徴とする、上記第１から上記第３のいずれか一つに記載の方法。
　第５に、マルチメディア・クライアント端末のパラメータを被呼使用者が設定（２１２）して、このクライアント端末が、作成されたマルチメディアメッセージに対応する入力メッセージを受諾するようにすることを特徴とする、上記第１から上記第４のいずれか一つに記載の方法。
　第６に、マルチメディアメッセージの作成のために、データベースに接続（２０８，２１１）して、マルチメディアメッセージのフォーマッティングのための、被呼使用者に組み合わされた作成プリファランスを取得することを特徴とする、上記第１から上記第５のいずれか一つに記載の方法。
　第７に、マルチメディアメッセージの作成のために、データベースに接続（２０８，２１１）して、発呼使用者に組み合わされた情報を取得し、該情報をマルチメディアメッセージに含めることを特徴とする、上記第１から上記第６のいずれか一つに記載の方法。
　第８に、マルチメディアメッセージが、ＨＴＭＬ型のフォーマッティング言語を用いて作成される（２０５）ことを特徴とする、上記第１から上記第６のいずれか一つに記載の方法。
　第９に、作成されたマルチメディアメッセージが、被呼使用者の識別子（１２４Ｃ）を有していることを特徴とする、上記第１から上記第８のいずれか一つに記載の方法。
　第１０に、マルチメディアメッセージの有する情報（１２４Ｅ）が、マルチメディアメッセージの読み出し情報メッセージの発信を受取人が要求するためのものであることを特徴とする、上記第１から上記第９のいずれか一つに記載の方法。
【００１４】
　本発明はまた、ボイスメッセージサーバーに接続された発呼使用者側のボイスメッセージを受信するのに適したボイスメッセージサーバーを有するインスタントボイスメッセージング装置も対象としており、該装置は、ボイスメッセージに対応し、かつ被呼使用者に宛てられたファイルを有するマルチメディアメッセージを作成するのに適した変換サーバーに、ボイスメッセージサーバーが接続されていることを特徴としている。
　また、本発明の課題を解決するための手段は、次のとおりである。
　第１１に、ボイスメッセージサーバーに接続された発呼使用者（１０１）側のボイスメッセージを受信するのに適したボイスメッセージサーバー（１０５）を有するインスタントボイスメッセージング装置において、
　ボイスメッセージに対応し、かつ、被呼使用者（１０２）に宛てられたファイル（１２４Ａ）を有するマルチメディアメッセージを作成するのに適した変換サーバー（１１０）に、ボイスメッセージサーバーが接続され、
　また、装置の使用者に関する情報を有するデータベースサーバー（１１８）に、変換サーバーとマルチメディアメッセージサーバーが接続されていることを特徴とするインスタントボイスメッセージング装置。
　第１２に、マルチメディアメッセージをマルチメディア・クライアント端末に転送するのに適したマルチメディアメッセージサーバー（１２５）に、変換サーバーが接続されていることを特徴とする、上記第１１に記載の装置。
　第１３に、マルチメディアメッセージサーバーが、マルチメディアゲートウェイ（１３１）を介してマルチメディア・クライアント端末に接続されていることを特徴とする、上記第１２に記載の装置。
　第１４に、メッセージの宛先使用者によってダウンロードされなかったマルチメディアメッセージを保存するための大容量保存ユニット（１２８）を、マルチメディアメッセージサーバーが有していることを特徴とする、上記第１１から上記第１３のいずれか一つに記載の装置。
【発明の効果】
【００１５】
　本発明によれば、音声および／またはマルチメディアメッセージのために大記録容量を備える必要はない。
　また、事業者がＭＭＳサーバーを管理しているので、事業者はマルチメディアメッセージ内に情報を挿入したり、マルチメディアメッセージをフィルタにかけたりすることができる。
【発明を実施するための最良の形態】
【００１６】
　本発明は以下の説明を読み、付属の図面を参照することでいっそう良く理解できるだろう。
　図面は説明のためのもので、本発明をいっさい制限するものではない。
　図１は、本発明の方法を実施するための手段の概略図である。
　図２は、本発明による方法の過程を示す概略図である。
　図１に示す携帯電話１０１は、被呼使用者に連絡しようとしている発呼使用者によって、予備過程２０１で使用される機器である。
　図２に示す予備過程２０１において、発呼使用者は、被呼使用者に連絡しようとするために、被呼使用者の識別子を保有している。
　この場合、識別子は電話番号である。
　なお、携帯電話１０１の代わりに、他のいっさいの種類のもの、例えば、パソコン、携帯型コンピュータ、ＰＤＡなどとすることができる。
　識別子もまた、他のいっさいの種類のもの、例えば、ｅメール型の電子アドレス、インスタント・メッセージ型の電子アドレス（例えば、ＩＣＱ）などとすることができる。
【００１７】
　予備過程２０１において、発呼使用者は、被呼使用者の電話番号を押す。
　コールは、既知の仕方で被呼使用者に対して、より詳細には、この場合には、被呼使用者の携帯電話１０２に対して行われる。
　実際、発呼使用者は、ボイスボックスに直接接続しようとし、したがって、このボイスボックスに対応する番号を押すことができる。
　そうでなければ、発呼使用者は、さまざまな理由からボイスボックスに接続されることになるかもしれない。
　もっとも一般的な理由は、被呼使用者が直接連絡を取られることを望まず、その場合に自分の携帯電話１０２を切るか使用不能にしているか、あるいは、被呼使用者が加入している事業者のサービスの圏外にいることである。
　この場合、発呼使用者のコールは、ボイスボックスに向けて直接行われる。
【００１８】
　図１は、携帯電話１０１が、無線接続１４６によって、基地局１０３に接続されることを示している。
　基地局１０３自体は、携帯電話１０１の使用者によって実施されたコールを中継することができる中継可能手段１０４に接続されている。
　この中継可能手段１０４は、例えば、ＧＳＭネットワークおよび／または交換電話ネットワークのインフラである。
　もちろん、例えば、ＵＭＴＳネットワークなどの他のインフラ、あるいは電気通信インフラの他の任意の利用であっても良い。
　したがって、携帯電話１０１は、基地局１０３と中継可能手段１０４を介してボイスメッセージサーバー１０５に接続される。
　ボイスメッセージサーバー１０５は、ボイスメッセージを記録するための手段を有している。
　ボイスメッセージサーバー１０５は、受付メッセージを流す手段も有している。
　流される受付メッセージは、被呼使用者の識別子（電話番号）に依存する。
　実際、周知のごとく、電話ネットワークに加入している使用者は、自分のボイスボックスの受付メッセージを独自に作成することができる。
　したがって、ボイスメッセージサーバー１０５は、模式的に、マイクロプロセッサ１０６、プログラムメモリ１０７および、ボイスメッセージ記憶メモリ１０８を有している。
　ここでは、受付メッセージの保存および選択モードは、説明しない。
　実際には、これらの受付メッセージは、このとき、被呼使用者の識別子によってアドレス指定されたデータベース内に記録されることが可能であり、したがって、被呼使用者に対応する受付メッセージを見いだすのは容易である。
【００１９】
　マイクロプロセッサ１０６、プログラムメモリ１０７、ボイスメッセージ記憶メモリ１０８は、バス１０９によって接続される。
　マイクロプロセッサ１０６は、プログラムメモリ１０７内に記録された命令コードを実行する。
　プログラムメモリ１０７は、ボイスメッセージサーバー１０５のボイスサーバー機能を利用するための命令コードに対応する命令コード対応区域１０７Ａを有している。
　ボイスメッセージサーバー１０５は、中継可能手段１０４に接続するための接続回路１５０も有している。
　この接続回路１５０は、バス１０９と中継可能手段１０４の間のインターフェイスである。
　受付メッセージを流すことは、予備過程２０１に続く受付メッセージ伝達過程２０２に対応する。
　受付メッセージ伝達過程２０２は、通常、被呼使用者に残したいボイスメッセージを作成するために、話し始めて良いことを発呼使用者に示す音響信号の発信で終わる。
　受付メッセージ伝達過程２０２から、ボイスメッセージ発信過程２０３に移行する。
【００２０】
　したがって、ボイスメッセージ発信過程２０３において、発呼使用者が話し、その人が発した音はマイクロプロセッサ１０６によってボイスメッセージ記憶メモリ１０８内に記録される。
　従来の、またボイスメッセージに組み合わされた仕方で、ボイスメッセージサーバー１０５はコール時間ならびにコール者の識別子も記録する。
　発呼使用者は、自分のボイスメッセージを終えたら、電話を切る。
　記録フォーマットは、ボイスメッセージ記憶メモリ１０８のタイプに依存する。
　ボイスメッセージ記憶メモリ１０８は、テープ、ディスクまたはフラッシュメモリとすることができる。
　従来のフォーマットは、ＷＡＶフォーマットである。
【００２１】
　図２において、ボイスメッセージ発信過程２０３に続くのは、ボイスメッセージ記録過程２０４である。
　実際には、ボイスメッセージ発信過程２０３とボイスメッセージ記録過程２０４は同時である。
　なぜなら、ボイスメッセージは、発呼使用者が発するにつれて記録されるからである。
　ボイスメッセージ発信過程２０３とボイスメッセージ記録過程２０４は、したがって、一方の携帯電話１０１、若しくは他方のボイスメッセージサーバー１０５を基準としたときに、同じ日付に実行されることになる。
【００２２】
　ボイスメッセージ記録過程２０４に続くのは、ボイスメッセージ通知過程２０５である。
　この目的のために、プログラムメモリ１０７は、通知命令コードに対応する通知命令コード対応区域１０７Ｂを有している。
　現状技術において、通知は、ボイスメッセージがそのボイスボックスに記録されたことを被呼使用者に知らせるためのメッセージを送信することをもって成る。
　かかるメッセージは、一般的にショートメッセージを介して通知される。
【００２３】
　本発明において、通知メッセージは、変換サーバー１１０に送られる。
　通知メッセージは、少なくとも一つの被呼使用者識別子を有している。
　該通知メッセージは、また、この通知メッセージを、ボイスメッセージサーバー１０５によるボイスコールの受信通知メッセージとして識別することを可能にする情報も有している。
【００２４】
　変換サーバー１１０は、ボイスメッセージサーバー１０５によって記録されたボイスメッセージを、マルチメディアメッセージに変換するための手段を有している。
　変換サーバー１１０は、バス１１３を介してプログラムメモリ１１２に接続されたマイクロプロセッサ１１１を有している。
　変換サーバー１１０は、ボイスメッセージサーバー１０５の接続回路１１５との接続インターフェイス回路１１４も有している。
　接続回路１１５は、バス１０９に接続されている。
　この例では、ボイスメッセージサーバー１０５と変換サーバー１１０を、二つの別個の実体として示した。
　実際には、変換サーバー１１０の手段を、ボイスメッセージサーバー１０５に内蔵することも可能である。
　これは、すなわち、変換サーバー１１０の命令コードが、実際にはプログラムメモリ１０７に記録され、マイクロプロセッサ１０６によって利用されることになる。
【００２５】
　プログラムメモリ１１２は、複数の区域に分割される。
　区域１１２Ａは、ＭＭＴＰプロトコール、すなわちマルチメディアメッセージ転送プロトコールの利用を可能にするが、これは３ＧＰＰグループによってＭＭＳ規格に標準化されたマルチメディアメッセージのための転送プロトコールである。
　３ＧＰＰは、第三世代の携帯電話を標準化する作業部会である
【００２６】
　プログラムメモリ１１２は、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ、すなわち、ハイパーテキストマークアップ言語）、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ、すなわち、拡張マークアップ言語）、または、ＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｇｒａｔｉｏｎ　Ｌａｎｇｕａｇｅ、すなわち、マルチメディア同期統合言語）タイプのデータフォーマッティング言語の使用を可能にする区域１１２Ｂを有している。
　これら二つの言語は、ファイルの定義を可能にし、ファイルはつぎに、これらのファイルに含まれる命令を理解するのに適したプログラムによって読まれる。
　これらの命令は、とくに、テキストと画像を表示し、ボイスファイルを読むことを可能にする。
【００２７】
　区域１１２Ｃは、ボイスメッセージサーバー１０５によって発信された通知を、変換サーバー１１０が管理することを可能にする命令コードを有している。
　区域１１２Ｄは、例えば、ＭＭＳメッセージ型のマルチメディアメッセージの作成を可能にする。
【００２８】
　変換サーバー１１０は、インターネット型ネットワーク１１７とのインターフェイス回路１１６も有している。
　したがって、インターフェイス回路１１６は、インターネット型ネットワーク１１７とバス１１３の間のインターフェイスである。
　インターネット型ネットワーク１１７を介して、変換サーバー１１０は、データベースサーバーであるプロファイルサーバー１１８と通信することができる。
　プロファイルサーバー１１８は、被呼使用者が加入している携帯電話事業者によって管理される。
　プロファイルサーバー１１８は、インターネット型ネットワーク１１７との接続インターフェイス１１９を有している。
　接続インターフェイス１１９は、バス１２０に接続され、バス自体は、マイクロプロセッサ１２１、プログラムメモリ１２２および保存ユニット１２３に接続されている。
　プログラムメモリ１２２は、プロファイルサーバー１１８が使用者のプロフィールに関するリクエストに応答することを可能にする命令コードを有している。
　使用者のプロフィールは、保存ユニット１２３にデータベースの形で記録される。
　このデータベースの一部は、行と列を有する表の形で表すことができる。
　それぞれの行は、このとき使用者に対応し、それぞれの列は、このときこの使用者の特徴に対応する。
　行は、プロファイルとも呼ばれる。
【００２９】
　列１２３Ａは、使用者の識別子を有し、この識別子は、例えば、使用者が加入している事業者によって、使用者に割り当てられた電話番号である。
　列１２３Ｂは、使用者がマルチメディアメッセージオプションに加入しているか、加入していないかを示す情報を有している。
　列１２３Ｃは、使用者の写真を有し、列１２３Ｄは、使用者が受信を希望する、あるいは希望しないマルチメディアメッセージのフォーマッティングに関する情報を含んでいる。
　変型例において、それぞれの行は、電子名刺、すなわちＶＣＡＲＤの形で、使用者の姓と名、そしてまたは使用者のビデオを有することもできる。
　すべてのデータフォーマットが許容される。
【００３０】
　ボイスメッセージ通知過程２０５において、ボイスメッセージサーバー１０５は、変換サーバー１１０に対してメッセージを発信する。
　これは、通知メッセージである。
　このとき、変換サーバー１１０は、保存ユニット１２３に保存されたデータベースにアクセスする。
　このアクセスは、発呼使用者によって呼び出された使用者に対応する列１２３Ｂに関するフィールドの内容を知るために要求する形式で行われる。
　プロファイルサーバー１１８は、この要求に応答する。
　応答は、被呼使用者のプロフィールの全部または一部を有するフレームである。
　この応答フレームは、好適には、列１２３Ｂに対応するフィールドを有している。
　このとき、変換サーバー１１０は、被呼使用者がマルチメディアメッセージを受信するために加入を申し込んだか、あるいはこの加入を申し込んでいないかの情報を保有する。
　被呼使用者が加入を申し込まなかったとき、被呼使用者は現状技術のごとく、単なるＳＭＳによって、ボイスメッセージの到着を通知されるだろう。
　そうでなければ、ボイスメッセージのマルチメディアメッセージへの変換過程であるマルチメディアメッセージ作成過程２０６に移行する。
【００３１】
　マルチメディアメッセージ作成過程２０６において、変換サーバー１１０は、ボイスメッセージサーバー１０５に要求して自分にファイルの形でボイスメッセージを転送してもらう。
　この転送は、例えば、ＦＴＰプロトコールによって、あるいはファイル交換を可能にする他のいっさいのプロトコールによって行うことができる。
　ボイスメッセージサーバー１０５が、ボイスメッセージを、変換サーバー１１０に伝達すると、ボイスメッセージは、ボイスメッセージ消去過程２１６によって、ボイスメッセージサーバー１０５においてボイスメッセージ記憶メモリ１０８から消去される。
　ボイスメッセージサーバー１０５から変換サーバー１１０へのボイスメッセージの伝達の際に、ボイスメッセージサーバー１０５は、ボイスメッセージに伴う情報、すなわちボイスメッセージの記録日とそのメッセージを記録した人の識別子も伝達する。
　大抵の場合、この識別子は電話番号である。
【００３２】
　ボイスメッセージサーバー１０５で、ボイスメッセージのデータは、任意のフォーマットで記録される。
　ついでボイスメッセージは、この任意のフォーマットで変換サーバー１１０に伝達されるが、任意のフォーマットが十分圧縮されていないときは、必要に応じて圧縮されることもある。
　圧縮は、変換サーバー１１０でも、あるいはボイスメッセージサーバー１０５でも起こりえる。
　それはともかく、変換サーバー１１０によってマルチメディアメッセージ内に組み込まれるボイスメッセージは、もっとも知られているものだけを挙げても、ＭＰ３、ＯＧＧまたはＭＰ４タイプの圧縮フォーマットのものである。
【００３３】
　マルチメディアメッセージ作成過程２０６において、変換サーバー１１０は、少なくとも圧縮ボイスメッセージと、被呼使用者の識別子と、発呼使用者の識別子と、ボイスメッセージの記録日を保有している。
　変換サーバー１１０は、メッセージの主題も保有することができる。
　ボイスメッセージを預ける際に、コール者は、メッセージの主題、その重要性、および／または私用、緊急、業務などの性格を表示するオプションを選択することができる。
　これらの情報から、変換サーバー１１０は、これらすべての情報を含む、例えば、ＭＭＳ型の、マルチメディアメッセージを作成することができる。
　ＭＭＳは、標準であり、その規格は３ＧＰＰによって定義されている。
　ＭＭＳとは、Ｍｕｌｔｉｍｅｄｉａ　Ｍｅｓｓａｇｉｎｇ　Ｓｅｒｖｉｃｅ、すなわち、マルチメディアメッセージサービスである。
　これは、マルチメディア成分を有するメッセージおよびテキストを運ぶことを可能にするサービスである。
　もっとも頻繁なマルチメディア成分は、画像、動画と音声である。
【００３４】
　マルチメディアメッセージ作成過程２０６において、変換サーバー１１０は、被呼使用者に宛てられたファイルに関する圧縮ボイスメッセージを有するフィールド１２４Ａと、発呼使用者の識別子を有するフィールド１２４Ｂと、被呼使用者の識別子を有するフィールド１２４Ｃと、ボイスメッセージが記録された日付を有するフィールド１２４Ｄ、また、随意に、マルチメディアメッセージが有する情報として被呼使用者がボイスメッセージをきちんと受領したかを発呼使用者に知らせるメッセージの受信を発呼使用者が希望するかを示すフィールド１２４Ｅとからなるマルチメディアメッセージ１２４を構成する。
　このマルチメディアメッセージ１２４は、いったん構成されると、マルチメディアメッセージサーバー１２５に送られる。
【００３５】
　マルチメディアメッセージサーバー１２５は、被呼使用者が加入している事業者によって管理される。
【００３６】
　マルチメディアメッセージサーバー１２５は、マイクロプロセッサ１２６と、プログラムメモリ１２７と、マルチメディアメッセージの大容量保存ユニット１２８とを有する。
　マイクロプロセッサ１２６、プログラムメモリ１２７、マルチメディアメッセージの大容量保存ユニット１２８は、バス１２９によって接続される。
　マルチメディアメッセージサーバー１２５は、インターネット型ネットワーク１１７とマルチメディアメッセージサーバー１２５との間のインターフェイスの役割を果たす、バス１２９に接続された回路１３０も有している。
　プログラムメモリ１２７は、ＭＭＴＰプロトコールを実施することを可能にする区域１２７Ａを有している。
　区域１２７Ｂは、インターネット型ネットワーク１１７を介してメッセージを発信するために用いられる転送プロトコールであるＴＣＰ／ＩＰプロトコールの利用を可能にする。
　一般的に、ＴＣＰ／ＩＰプロトコールは、変換サーバー１１０とプロファイルサーバー１１８によっても利用される。
【００３７】
　理解の必要上、ネットワークインターフェイスのマテリアルレイヤーの管理に対応する区域１２７Ｃを図示した。
　これによって、マルチメディアメッセージサーバー１２５とマルチメディアメッセージゲートウェイ１３１との間の相互作用がよりよく理解できる。
【００３８】
　プログラムメモリ１２７は、変換サーバー１１０によって作成されたマルチメディアメッセージ１２４の更新に対応する区域１２７Ｄも有している。
【００３９】
　マルチメディアメッセージ作成過程２０６から、マルチメディアメッセージサーバー１２５に対するマルチメディアメッセージ１２４を、変換サーバー１１０によって発信するマルチメディアメッセージ伝達過程２０７に移行する。
【００４０】
　マルチメディアメッセージ１２４は、変換サーバー１１０が、プロファイルサーバー１１８のデーターベースに接続することによる質問過程２０８を介して、もっと細かくフォーマットされることもできる。
　実際、変換サーバー１１０は、プロファイルサーバー１１８に接続して、被呼使用者のプロフィールを、より詳細には列１２３Ｄに係るフィールドの内容を得ることができる。
　ここではその可能性については述べないが、それは、マルチメディアメッセージサーバー１２５によるマルチメディアメッセージの更新についての可能性が記載されるからである。
　ただし、この更新のすべてまたは一部を、変換サーバー１１０のレベルで行うこともできることを知っておかなければならない。
【００４１】
　マルチメディアメッセージ伝達過程２０７の後では、変換サーバー１１０は、もはやマルチメディアメッセージを必要とせず、したがって、マルチメディアメッセージ消去過程２１５でマルチメディアメッセージを消去できる。
　マルチメディアメッセージ伝達過程２０７から、マルチメディアメッセージサーバー１２５によるマルチメディアメッセージ１２４を受信するマルチメディアメッセージ受信過程２０９にも移行する。
【００４２】
　マルチメディアメッセージ受信過程２０９は、ＴＣＰ／ＩＰおよびＭＭＴＰなどのプロトコール・レイヤーを通って、インターネット型ネットワーク１１７を介してメッセージを受信する特徴的過程である。
　いったんメッセージが回収されると、このメッセージ更新過程２１０に移行する。
　メッセージ更新過程２１０では、マルチメディアメッセージサーバー１２５は、マルチメディアメッセージ１２４について記載したすべての情報を保有している。
【００４３】
　これらの情報は、マルチメディアメッセージサーバー１２５が、下記に示したようなメッセージを作成するのを可能にする。
＜ｍｅｓｓａｇｅ＞
　＜ｏｒｉｇｉｎ＞
　＜ｍｓｉｓｄｎ＞０６　１２　３４　５６　７８＜／ｍｓｉｓｄｎ＞
　＜ｒｅａｄＲｅｐｏｒｔ＞１＜／ｒｅａｄＲｅｐｏｒｔ＞
　＜／ｏｒｉｇｉｎ＞
　＜ｐｒｅｓｅｎｔａｔｉｏｎ＞
　＜ｖｏｃ　ｔｙｐｅ＝”ｖｏｉｃｅＣｏｄｉｎｇ”＞０１０１１１０．．．０１０１＜／ｖｏｃ＞
　＜ｉｍｇ　ｔｙｐｅ＝”ｉｍａｇｅＣｏｄｉｎｇ”
ｓｔｙｌｅ＝”ｉｍａｇｅＳｔｙｌｅ＞０１１１１．．０１０１＜／ｉｍｇ＞
　＜ｔｅｘｔ　ｔｙｐｅ＝”tｅｘｔＣｏｄｉｎｇ”　ｓｔｙｌｅ＝”ｔｅｘｔＳｔｙｌｅ”＞ｔｅｘｔ ｔｏ　ｂｅ ｄｉｓｐｌａｙｅｄ＜／ｔｅｘｔ＞
　．．．
　＜／ｐｒｅｓｅｎｔａｔｉｏｎ＞
＜／ｍｅｓｓａｇｅ＞
【００４４】
　この例は、ＸＭＬ型の構文を介するメッセージの成形を示している。
　本発明によるメッセージを伝達するのに適した構文は、ＨＴＭＬまたはＳＭＩＬ型である。
　できるだけ総称的にとどまるために、ここではこれら二つの言語のそれぞれのタグの名前を取り上げない。
　ここでは、それぞれのフィールドは、開始タグ＜ｔａｇ＞と、終了タグ＜／ｔａｇ＞によって定義される。
　ほかの処理法もあり、例えば、それぞれのフィールドが、フィールド長さを符号化する４バイトで始まるように決める仕方もある。
　このようにして、容易に一つのフィールドから次に移行できる。
【００４５】
　したがって、上記の例は、それ自体が、ＭＳＩＳＤＮフィールドと読取報告フィールドに分割される元のフィールドを有するメッセージを示している。
　ＭＳＩＳＤＮフィールドは、発呼使用者の電話番号の定義を可能にし、読取報告フィールドは、自分のボイスメッセージが被呼使用者によってきちんと受け取られたかを発呼使用者に示すメッセージの受領を発呼使用者が希望するかの定義を可能にする。
　ＭＳＩＳＤＮフィールドは、任意の識別子、例えば、発呼使用者のｅメール型の電子アドレスに代えることができる。
【００４６】
　メッセージは、また、それ自体が複数のサブフィールドに分割された紹介フィールドも有することができる。
　これらのサブフィールドは、例えば、ボイスメッセージを記録することを可能にする’ｖｏｃ’フィールド、画像を記録することを可能にする’ｉｍｇ’フィールド、および、テキストを記録することを可能にする’ｔｅｘｔ’フィールドである。
　これら三つのフィールドのそれぞれに、フィールドの内容を符号化するのにどのフォーマットが使用されたかを示すタイプが組み合わされる。
　典型的には、音声の符号化はＭＰ３フォーマットで行うことができ、画像の符号化はＪＰＥＧフォーマットで行うことができ、そしてテキストの符号化は、任意のキャラクタセット、例えば、ＩＳＯ ８８５６ １アルファベットによって行うことができる。
　サブフィールドは、それらがどのように表示されるかを定義するスタイルフィールドを伴うこともできる。
　スタイルは、画面上の位置および／またはそれらが表示される日付、テキストの色あるいは考えられる他のいっさいのフォーマッティングの定義を可能にするパラメータを含んでいる。
　例えば、ＣＳＳの名前でも知られ、Ｗ３Ｃによって標準化されたカスケードスタイルシートに適合するスタイルを考えることができる。
【００４７】
　メッセージ更新過程２１０の間に、マルチメディアメッセージサーバー１２５は、プロファイルサーバー１１８に接続して、データベスへの接続過程２１１で、被呼使用者の識別子に対応する使用者のプロフィールを得ることができる。
　この使用者のプロフィールは、自分の端末から、自分の姓、名、画像、受付ビデオ、受付ボイスメッセージおよび／またはＶＣＡＲＤを有する、プレフォーマットされたＭＭＳメッセージを即時メッセージサービスに送ることによって、使用者によって更新できることが考えられる。
　なぜなら、列１２３Ｄに係るフィールドは、使用者がこれらのボイスメッセージがどのようにフォーマットされるのを希望するかを定義することができるからである。
　列１２３Ｄに係るフィールドは、被呼使用者がボイスメッセージを受け取りたくない使用者の識別フィルタを定義することもできる。
　かかるフィルタは、ブラックリストとも呼ばれる。
【００４８】
　カスタムフォーマッティングの例は、被呼使用者にとっては、ボイスメッセージと同時に、発呼使用者の写真、その姓、その名、および／またはＶＣＡＲＤが自分に伝達されることを希望することであろう。
　発呼使用者もマルチメディアメッセージサーバー１２５を管理する携帯電話事業者に加入しているとき、サーバーはインターネット型ネットワーク１１７を介して保存ユニット１２３のデータベースに問い合わせて、発呼使用者の識別子を検索して列１２３Ｃのフィールドの内容を獲得し、そして、それを被呼使用者のために作成するマルチメディアメッセージの中に含めるだろう。
【００４９】
　メッセージ更新過程２１０において、マルチメディアメッセージサーバー１２５は、作成されたマルチメディアメッセージに、マルチメディアメッセージ１２４を介して受領しなかった情報も付加することができる。
　かかる情報とは、例えば、宣伝メッセージである。
　それは、経過時間の間に受領したボイスメッセージの数を要約する情報のこともある。
【００５０】
　これらの付加情報は、あるいは画像のように、あるいはテキストのように、あるいはボイスメッセージのように挿入されることができる。
【００５１】
　メッセージ更新過程２１０の後、被呼使用者がマルチメディア・クライアント端末である携帯電話１０２のパラメータを設定することによる、マルチメディアメッセージの回収過程２１２に移行する。
【００５２】
　マルチメディアメッセージサーバー１２５は、インターネット型ネットワーク１１７を介してマルチメディアゲートウェイ１３１に接続される。
　マルチメディアゲートウェイ１３１は、インターネット型ネットワーク１１７とマルチメディアゲートウェイ１３１のバス１３３との間のインターフェイス回路１３２を有している。
　マルチメディアゲートウェイ１３１は、マイクロプロセッサ１３４とプログラムメモリ１３５も有している。
【００５３】
　マルチメディアゲートウェイ１３１は、バス１３３と、ネットワークである中継可能手段１０４と同一のネットワーク１３７との間のインターフェイス回路１３６も有している。
　ネットワーク１３７は、他方で、携帯電話１０２との無線接続１３９を成立させることを可能にする基地局１３８に接続されている。
　マルチメディアゲートウェイ１３１の要素は、バス１３３を介して相互接続されている。
【００５４】
　携帯電話１０２は、アンテナ１４０、アンテナ１４０とバス１４２の間のインターフェイス回路１４１を有しており、該バスには、マイクロプロセッサ１４３と、プログラムメモリ１４４と保存メモリ１４５が接続されている。
【００５５】
　図１では、機器について様々なメモリを説明した。
　実際には、これらすべてのメモリは、所与の機器について、唯一かつ同一の構成部品に統一することができる。
【００５６】
　保存メモリ１４５は、携帯電話１０２がマルチメディアメッセージを記録することを可能にする。
　プログラムメモリ１４４は、複数の区域に分割されている。
　その一つの区域１４４Ａは、ＭＭＳ規格に関するプロトコールの利用を可能にする。
　また、他の区域１４４Ｂは、ＳＭＩＬ言語に従ってフォーマットされたマルチメディアメッセージの解釈を可能にする。
【００５７】
　プログラムメモリ１３５は、模式的に、二つの区域に分割される。
　一つの区域は、マルチメディアゲートウェイ１３１がインターネット型ネットワーク１１７と交信するのを可能にする。
　残りの区域は、マルチメディアゲートウェイ１３１がネットワーク１３７と交信するのを可能にする。
　ネットワーク１１７と交信するのを可能にするプログラムメモリ１３５の区域は、ＴＣＰ／ＩＰおよびＭＭＴＰのマテリアルレイヤーを有している。
　マルチメディアゲートウェイ１３１がネットワーク１３７と交信するのを可能にするプログラムメモリ１３５の区域は、ＭＭＴＰのマテリアルレイヤーを有している。
　したがって、マルチメディアゲートウェイ１３１の役割は、マルチメディアメッセージサーバー１２５と携帯電話１０２との間で交換されたメッセージの符合転換を実施することである。
【００５８】
　回収過程２１２については、携帯電話１０２が自らに宛てられたマルチメディアメッセージを回収するために、ＭＭＳ規格によって定められた二つの方法がある。
　一つは、携帯電話１０２の被呼使用者が、自分の端末が定期的にマルチメディアメッセージサーバー１２５に問い合わせるように、その端末である携帯電話１０２のパラメータを設定することである。
　残りの一つは、携帯電話１０２の被呼使用者が、端末がマルチメディアメッセージサーバー１２５から発信された入力メッセージを受諾するように、その端末である携帯電話１０２のパラメータを設定することである。
　入力メッセージは、例えば、ボイスメッセージが預けられたことを通知するＳＭＳである。
　このとき、使用者は、ボイスメッセージを回収しなければならないことがわかる。
　入力メッセージは、変換サーバー１１０が端末内にＭＭＳメッセージを記録することを可能にするＰＵＳＨモードでの作動を介して、ＭＭＳメッセージとすることもできる。
【００５９】
　図の両者の場合において、携帯電話１０２は、受信され、マルチメディアメッセージサーバー１２５によってフォーマットされたままのマルチメディアメッセージを、保存メモリ１４５に記録する。
　この記録の際に、新規ボイスメッセージが保存メモリ１４５内に記録され、聴取できることを、携帯電話１０２が、その使用者に知らせる。
【００６０】
　次に、ボイスメッセージの受領通知過程２１３に移行する。
　回収過程２１２において、マルチメディアメッセージサーバー１２５が、いったんマルチメディアメッセージを携帯電話１０２に伝達すると、マルチメディアメッセージは、大容量保存ユニット１２８のメモリから消去される。
　このとき、マルチメディアメッセージは、携帯電話１０２の保存メモリ１４５の中にしか、存在しない。
【００６１】
　受領通知過程２１３において、携帯電話１０２の使用者、すなわち被呼使用者が保存メモリ１４５を探索して、受信したばかりの新規ボイスメッセージを読み出す。
　被呼使用者がこれらのメッセージの一つを選択すると、このメッセージは区域１４４Ｂの命令コードによって解釈される。
　これによって、一方では携帯電話１０２によってボイスメッセージが流され、他方では携帯電話１０２の画面にマルチメディアメッセージの各種のマルチメディア要素が表示される。
　ＳＭＩＬ言語の利点は、メッセージのマルチメディア要素の視覚表示と聴取などのさまざまな事象を、互いに同期させることが可能になることである。
【００６２】
　マルチメディアメッセージの視覚表示の過程で、携帯電話１０２の被呼使用者は、発呼使用者が自分のメッセージの受領通知を受けることを希望していることを知らされる。
　この場合、被呼使用者は、この受領通知の送付を選択することも、しないこともできる。
　この受領通知は、携帯電話１０２によって自動的に送信されるＳＭＳのショート・メッセージ、あるいは従来のＭＭＳの形を取ることができる。
【００６３】
　このショート・メッセージは、返信過程２１４で携帯電話１０１によって受信される。
　この受領通知メッセージは、例えば、被呼使用者の識別子と、この受領メッセージの発信日付を有する。
【００６４】
　かかる利用には、数多くの利点がある。
　一方では、これらのボイスメッセージの保存は、最終的に、これらのボイスメッセージの宛先の使用者の端末で実現されるので、ボイスメッセージサービスを提供する事業者は、ボイスメッセージの保存の心配をする必要がなくなる。
　他方では、携帯電話事業者は、サービスプロバイダにボイスメッセージの入力ポイントを提供できる。
　なぜなら、マルチメディアメッセージサーバー１２５を管理する事業者の加入者にボイスメッセージサービスを提供するには、プロバイダは、マルチメディアメッセージサーバー１２５と互換性を持つだけで良いからである。
　このようにして、携帯電話事業者は、これらのボイスメッセージの管理を保持するが、なぜなら、ボイスメッセージが、携帯電話事業者のサーバーの一つを経由するからである。
　このようにして、携帯電話事業者は、マルチメディアメッセージの流れの管理と、マルチメディアメッセージの内容の管理の両方を維持する。
　この場合であっても、ボイスサーバーと変換サーバーの利用は、プロバイダーの負担のままである。
【００６５】
　本発明の変型例において、マルチメディアメッセージ作成過程２０６は、ボイスメッセージからテキストフォーマットへの符合変換のサブ過程を有することができる。
　これは、記録されたボイスメッセージに基づいて音声を認識することに他ならない。
　これは、極めて高い圧縮率を可能にする。
　この音声認識は、ボイスメッセージサーバー１０５から実施することもできる。
　この変型例において、認識されたボイスメッセージの復元を考えることもできる。
　これは、テキストファイルから音声を作成することに他ならない。
　このとき、この復元は、携帯電話１０２によって実施されるだろう。
　認識されたボイスメッセージを、テキストとして提示することもできる。
【００６６】
　本発明の変型例において、インターネット型ネットワーク１１７を介して実現された通信の全部または一部を暗号化して機密性を高めることができる。
【００６７】
　本発明による方法は、インスタントボイスメッセージサービスとみなされる、なぜならマルチメディアメッセージは、被呼使用者が介入することなしに、配達が可能になり次第、被呼使用者に配達されるからである。
　より迅速にメッセージを配達することができない限りにおいて、それは即時メッセージサービスとみなされる。
【００６８】
　本発明はもちろんビデオメッセージの受信にも適用され、その場合は明細書の中のボイスメッセージを読み替える。
　この場合、ボイスメッセージサーバー１０５だけが少し違ったものになる、なぜならこのときはボイスメッセージとビデオの記録を可能にしなければならないからである。
【図面の簡単な説明】
【００６９】
【図１】本発明の方法を実施するための手段の概略図である。
【図２】本発明による方法の過程を示す概略図である。
【符号の説明】
【００７０】
１０１　発呼使用者の携帯電話
１０２　被呼使用者の携帯電話
１０３　基地局
１０４　中継可能手段
１０５　ボイスメッセージサーバー
１０６　マイクロプロセッサ
１０７　プログラムメモリ
１０８　ボイスメッセージ記憶メモリ
１０９　バス
１１０　変換サーバー
１１１　マイクロプロセッサ
１１２　プログラムメモリ
１１３　バス
１１４　接続インターフェイス回路
１１５　接続回路
１１６　インターフェイス回路
１１７　インターネット型ネットワーク
１１８　プロファイルサーバー
１１９　接続インターフェイス
１２０　バス
１２１　マイクロプロセッサ
１２２　プログラムメモリ
１２３　保存ユニット
１２４　マルチメディアメッセージ
１２５　マルチメディアメッセージサーバー
１２６　マイクロプロセッサ
１２７　プログラムメモリ
１２８　大容量保存ユニット
１２９　バス
１３０　回路
１３１　マルチメディアゲートウェイ
１３２　インターフェイス回路
１３３　バス
１３４　マイクロプロセッサ
１３５　プログラムメモリ
１３６　インターフェイス回路
１３７　ネットワーク
１３８　基地局
１３９　無線接続
１４０　アンテナ
１４１　インターフェイス回路
１４２　バス
１４３　マイクロプロセッサ
１４４　プログラムメモリ
１４５　保存メモリ
１４６　無線接続
１５０　接続回路
２０１　予備過程
２０２　受付メッセージ伝達過程
２０３　ボイスメッセージ発信過程
２０４　ボイスメッセージ記録過程
２０５　ボイスメッセージ通知過程
２０６　マルチメディアメッセージ作成過程
２０７　マルチメディアメッセージ伝達過程
２０８　質問過程
２０９　マルチメディアメッセージ受信過程
２１０　メッセージ更新過程
２１１　接続過程
２１２　回収過程
２１３　受領通知過程
２１４　返信過程
２１５　マルチメディアメッセージ消去過程
２１６　ボイスメッセージ消去過程
【図１】
2004129270.tif 000003
【図２】
2004129270.tif 000004