JP2005348192A - 端末装置、端末装置の制御方法、および端末装置の制御プログラム - Google Patents

Abstract

【課題】 ＩＰ電話システムにおいて、着呼側が応答しない場合に、良好な操作感で高品質の音声あるいはさらに画像データなどによる用件メッセージを授受できるようにする。
【解決手段】 通信部１１２によりＩＰ電話プロトコルに基づき相手端末を発呼し、発呼した相手端末が応答しないことがＩＰ電話プロトコルから判断される場合、ユーザの通話部１１４の受話器などを用いてユーザの音声（あるいは画像）データを用件メッセージとして蓄積し、この用件メッセージデータをＩＰ電話プロトコルを介して取得した相手端末のメールアドレスに対して、電子メールプロトコルを用いて送信する。
【選択図】 図１

Description

本発明は、ＩＰ電話プロトコルに基づき相手端末を発呼し、相手端末と少なくとも音声通信を行なう端末装置、端末装置の制御方法、および端末装置の制御プログラムに関するものである。

近年、インターネットの普及が世界的に急速に拡大しており、通信料金の著しい低減を図ることができる利点から、インターネット電話（以下ＩＰ電話）が注目を浴びている。インターネット電話で特に現在有力な規格はＳＩＰ（下記の非特許文献１）であり、このような規格によるインターネット電話対応の機器が様々な形で提案されている。また、ＩＰ電話の多くは、もともとテレビ会議のような画像通信技術を流用しており、したがって、ＩＰ電話によれば、動画送受信をともなうビデオ通話（いわゆるＴＶ電話）も当然可能である。

ＩＰ電話技術における重要な課題の１つは、ＰＳＴＮで実施されていた種々の機能を同様に実現し、また、その際、インターネットを用いる利点を生かしてよりよいサービスを実現することにある。

旧来のＰＳＴＮ端末で実施されていた技術の１つに留守録音やボイスメッセージの授受がある。旧来のＰＳＴＮ端末においては、たとえば着信側の端末がメッセージ録音手段に発信側の音声メッセージを録音するような構成が多く用いられていたが、ＩＰ電話技術においては次のような技術が提案されている。

たとえば、ＩＰ電話端末からアナログ一般電話端末を呼び出す際に一般電話端末が不在で着信しない場合、ゲートウェイはＩＰ電話端末からのボイスメールデータを保存し、一定時間経過後に自動ダイヤルで一般電話端末を発呼し、着信した場合にはボイスメールデータを読出し送信するという従来の技術が知られている（下記の特許文献１）。

また、インターネット技術との親和性が高くマルチメディアコミュニケーションの標準技術としてＩＥＴＦが標準化を進めているＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が知られているが、このＳＩＰは、現在のＩＰ電話方式において、発信の際、相手局を特定するために利用されている。ＳＩＰにおいては、ＩＰ電話端末同士で相手の端末を呼び出した結果で応答が無かった場合は、ＩＰ電話のＳＩＰプロトコルにてボイスメールサーバと発呼端末との間でＳＩＰプロトコルにてメディアセッションを確立し、ボイスメールサーバに対して音声メッセージを送付する技術が知られている（下記の非特許文献２）。

また、動画通信、特にテレビ会議の技術においては、時間的、場所的な制約を緩和すると共に、テレビ会議に参加しない者に情報を容易に提供する技術が知られている。たとえば、テレビ会議装置のメール処理部は、音声と映像信号から映像のメールを作成し、ユーザの指示にしたがって、メール処理部はメールから音声信号と映像信号を復元して音声出力装置と映像出力装置に出力する。また、ユーザの不在登録により、メール処理部の転送先情報処理部は転送情報表を作成して転送先を登録し、メッセージ変換処理部はメッセージ復元処理部または電話・ＦＡＸ用処理部から受けたファイルを転送先情報処理部から通知されたファイルのタイプに変換する。このようにして、転送先で受信可能なメッセージを作成して転送するといった構成が提案されている（下記の特許文献２）。
特開2001-309040号公報 特開2000-115738号公報 ＩＴＵ−Ｔ勧告 Ｈ．３２３(http://www.itu.int/) IETF - RFC3261, RFC3262, RFC3263, RFC3264, RFC3265, RFC3515 (http://www.ietf.org/)

上記特許文献１に記載されるような従来構成において、被呼側端末はアナログ回線の電話端末であるため、端末が位置的に固定されている可能性が大きいため音声メッセージを受け取ることができる場所的な制約が発生し、また、音声メッセージを被呼側が受信するタイミングはゲートウェイの管理に依存しているため被呼側が通話中等の事情で着呼を受け付けない期間であれば音声メッセージを受け取ることができないことがある、などの問題があった。

また、ＳＩＰプロトコル（非特許文献２）により種々提案されている標準的なボイスメッセージの送信方法は、ＩＰ電話端末が使用する網の接続パターンにおいて距離、ルータ段数、トラヒック、パケット損失等の理由により回線品質が良好ではない場合でも、そのような通話品質が低い状態で敢えて端末とボイスメッセージサーバ間でメディアセッションを確立して発呼側の音声をリアルタイムにボイスメッセージサーバに伝送し、保存させる構成を用いているので、音声品質の高いボイスメッセージの作成が行なえないことがある。この構成はボイスメッセージを受け取る被呼端末においても言え、被呼側端末においては品質が低下したサーバ上のボイスメッセージを、さらに回線品質の低下した状況で被呼端末が聞く可能性があり、ボイスメッセージサービスの音声品質が低下する可能性が懸念される。また、ボイスメッセージを被呼端末が受け取る方法としてもＳＩＰプロトコルを用いることになり、ＳＩＰプロトコルに対応していないかあるいはＩＰ電話サービスのアカウントを保有していないたとえばＰＣや移動体端末にてボイスメッセージの再生を行なうことができない不自由さがある。

また、動画通信に関する特許文献２に記載されるような従来構成はテレビ会議システムを前提としており、音声と映像のファイルを遠隔地に送付できる構成ではあるが、これを拡大解釈して電話端末として考えたとしても、相手を電話により呼び出し、相手が不在であった場合には相手に対してファイルを転送する手順は人間の判断に依存した上で行なうこととなり、端末装置の利便性を向上させる構成としては最適化されていない問題がある。

本発明の課題は、上記の問題に鑑み、音声あるいはさらに画像データの送受信を行なうＩＰ電話システムにおいて、留守などの事情により着呼側が応答しない場合に、旧来の留守番電話のような操作感を損なうことなく、また高価な端末を用いる必要なく、高品質の音声あるいはさらに画像データなどによる用件メッセージを授受できるようにすることにある。

上記課題を解決するため、本発明においては、ＩＰ電話プロトコルに基づき相手端末を発呼し、相手端末と少なくとも音声通信を行なう端末装置、端末装置の制御方法、および端末装置の制御プログラムにおいて、ＩＰ電話プロトコルに基づき相手端末を発呼するＩＰ電話発呼シーケンスを実行し、発呼した相手端末が応答しないことがＩＰ電話プロトコルから判断される場合、ユーザの用件メッセージを蓄積し、前記相手端末のメールアドレスに対して、前記用件メッセージデータを電子メールプロトコルを用いて送信する構成を採用した。

前記用件メッセージデータとしては、ユーザの音声データあるいは画像データを入力して用いることができる。

上記構成によれば、音声あるいはさらに画像データの送受信を行なうＩＰ電話システムにおいて、留守などの事情により着呼側が応答しない場合に、旧来の留守番電話のような操作感を損なうことなく、また高価な端末を用いる必要なく、高品質の音声あるいはさらに画像データなどによる用件メッセージを授受できる、という優れた効果がある。

以下に、図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。ただし、この実施の形態に記載されている構成要素の相対配置、表示画面等は、特に特定的な記載がない限りは、この発明の範囲をそれらのみに限定する趣旨のものではない。

本実施例では、ＶｏＩＰによる発呼を行なったが相手端末が応答しなかった場合に音声メッセージを用件メッセージとして電子メール送信する端末装置の構成例を示す。

図１は本発明を採用したＩＰ電話対応の端末装置の構成を示している。図示の端末装置は、電話機や画像通信／入出力機能などを含むＭＦＰ、あるいは移動体通信端末（携帯電話など）などの製品として構成することができる。

図１において符号１０１は装置全体を制御するための中央演算処理部（ＣＰＵ）、１０２はプログラムおよびデータを記憶するＲＯＭ、１０３はＣＰＵワークデータ、コーデックワークエリア、メールデータ、ＨＴＭＬデータ、表示用データ、記録用データ、その他のデータなどを記憶する記憶部（ＤＲＡＭ）、１０４は個人データ、電話帳データ、また各種の装置定数を保存しておくバックアップ用のデータを格納する不揮発性ＲＡＭ（ＳＲＡＭ）である。

符号１０５はセンサ群で、電話機としての受話器の状態を検出するセンサ、記録紙サイズの検出センサ、読み取り原稿巾のセンサ、原稿ありなしのセンサなどが含まれる。

符号１０６は、各種操作キーなどから構成される操作部１０８とともに電話端末のＵＩを実現するとともに、受信したコンテンツデータ、装置の状態などをカラー表示する表示部である。表示部１０６および操作部１０８の構成例については図４で詳述する。

符号１０７はコーデック（以下ＣＯＤＥＣ）で、本実施例では少なくとも音声データの符号化・復号化を行なえるものとする。ＣＯＤＥＣ１０７はあるいはさらにカラーやモノクロ画像データ（静止画および後述の実施例におけるような動画）の符号化・復号化を行なえるよう構成されていてもよい。

本実施例の端末装置は、画像通信機能を有しており、符号１０９および１１１で示した画像入出力のためのブロックを有する。ブロック１０９は読取部でカラーやモノクロ原稿のスキャンを行なうためＣＣＤやＣＩＳのような読取素子と原稿搬送部などの機構から構成される。ブロック１１１は受信した画像やテキストを記録するプリンタ機能を有する記録部で、電子写真方式やインクジェット方式など、任意の記録方式に基づき構成される。なお、この画像通信機能は本実施例では必ずしも必要なく、端末装置を移動体通信端末（携帯電話など）として構成する場合は省略できる。

符号１１２は回線１１３を接続し外部と通信を行なうための通信部である。本実施例では少なくとも通信部１１２によりインターネット接続および該ネットワーク接続を経由したＩＰ通信を行なえるものとする。あるいはさらに、通信部１１２を介してＰＳＴＮ（一般公衆電話回線）経由の通話／画像通信を行なえるようになっていてもよい。上記の通信を行なえるものであれば通信部１１２の細部の構成は任意である。インターネット接続はＰＳＴＮ（ＩＳＤＮなどを含む）経由、ＡＤＳＬやＦＴＴＨなどのブロードバンド回線経由により行なうことができ、このようなインターネット接続のために、通信部１１２には各種通信回線に対応したモデムやルータなどが必要となる。あるいは、この種のモデムやルータは外部のものを用い、端末装置にはこれらのネットワーク機器に接続するためのＬＡＮ（ＣＳＭＡ／ＣＤ（たとえばＥｔｈｅｒｎｅｔ（商標名））インターフェースのみを設けておくだけでもよい。また、インターネット通信およびＰＳＴＮ通信は同一の通信回線（たとえばＩＳＤＮなど）を用いて行なうようになっていてもよく、またインターネット通信およびＰＳＴＮ通信のためにそれぞれ異なる回線が用いられるようになっていてもよい。もちろん、回線ないしネットワークとの接続方式は無線接続などを利用した移動体通信方式などを採用してもよく、その場合通信部１１２には当該方式に対応する回線／ネットワークインターフェースを組み込む。

符号１１４は通話部であり、電話機としての受話器やスピーカ、マイクなどのデバイスを含み使用ユーザとの音声ＭＭＩを実現するためのブロックである。

以上に説明した図１の各ブロックはシステムバス１１０を介して相互に接続されている。

図２は、表示部１０６の回路構成を示している。表示部１０６は、表示データを記憶するＶＲＡＭ２００と、ＶＲＡＭ２００の内容をドットマトリクスＬＣＤ２０２に出力させるためのＬＣＤドライバ２０１とを含む。

図３は記憶部を構成するＤＲＡＭ１０３の内部構成を示すメモリマップであり、ＤＲＡＭ１０３はそれぞれＣＰＵ１０１のワークエリアとして使われるＣＰＵワークエリア１０３１、符号化・復号化を行なう際にワークエリアとして使用するコーデックワークエリア１０３２、メールのデータを記憶するメールデータ格納エリア１０３３、受信したＨＴＭＬデータを記憶するＨＴＭＬデータ格納エリア１０３４、表示データを記憶する表示用データ格納エリア１０３５、プリントデータを記憶する記録用データ格納エリア１０３６、および、その他のデータを記憶したり動作上のワークエリアとして使用するためのその他のデータ格納エリア１０３７から構成される。

図４は図１の表示部１０６および操作部１０８の部分の外観構成を示している。符号２０２は上記の表示部１０６を構成するＬＣＤである。操作部１０８は電話番号などを入力するためのテンキー４０２、機能設定などに用いるメニューキー４０３、種々の情報入力に用いるための４つのファンクションキー４０４、および設定入力キーであるセットキー４０５と、表示部１０６（ＬＣＤ２０２）のカーソル移動などに用いる左右上下方向キー４０６を含む。

図５は図１の端末装置がインターネットを含むネットワーク経由で通信する場合のネットワーク構成を概念的に示している。

図５において、端末（Ａ）５０３および端末（Ｂ）５０４はインターネット５００にＩＰ接続されている。このうち、少なくとも発呼側の端末（Ａ）５０３は図１の端末装置から構成されるものとし、ＩＰ接続には上述の通信部１１２が用いられる。

ＳＩＰ／ｐｒｏｘｙサーバ５０１はインターネット上に接続されており、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サービスを提供する。ＳＩＰ／ｐｒｏｘｙサーバ５０１はインターネット上でリアルタイムな呼制御を行なうための信号プロトコルであるＳＩＰ制御を行なう。前述のようにＳＩＰはプロトコル拡張性や他のインターネットサービスとの親和性も高いという特徴がある。特に電話サービスとしては、ＳＩＰ／ｐｒｏｘｙサーバ５０１はＲＦＣ３２６１に規定されているＳＩＰシグナリングの制御、ユーザー登録・認証、ユーザー管理などを行なう。

メールサーバ５０２はＩＰ接続によってインターネット５００に接続されており、ＲＦＣ８２１で規定されているＳＭＴＰ／ＰＯＰ３の機能を有し、メールの管理を行なうためのサーバの構成を有する。通常、メールサーバ５０２はインターネットサービスプロバイダやネットワークを運営する企業などにより設置される。

また、ＥＮＵＭ ＤＮＳサーバ５０５もＩＰ接続によってインターネット５００に接続されており、エンドユーザの電話番号と異種通信のアドレス情報等の関連付けが行なわれたレジストラが含まれる。たとえば発呼の際、所定のプロトコルに基づきＥＮＵＭ ＤＮＳサーバ５０５にアクセスすることにより電話番号から相手端末のＩＰアドレスやメールアドレスを求める（解決する）ことができる。なお、ＥＮＵＭサービスとＤＮＳサービスは必ずしも図示の例のように単一のサーバ（５０５）により提供する必要はない。

図５の端末Ａおよび端末Ｂ（５０３、５０４）は、ともにインターネット５００上のＩＰ電話サービスのアカウントを有しており、インターネット上に接続されているＳＩＰ／ｐｒｏｘｙサーバ５０１に接続を行なうことができる端末であり、ＩＰ電話サービスのエンドポイントのユーザエージェントとして機能することができる。

さらに本実施例では端末Ａ、端末Ｂともにインターネット上のメールサービスのアカウントを有しており、メールサーバ５０２に対してＳＭＴＰ／ＰＯＰ３により接続しメール送受信サービスを利用することができるものとする。

図６はＩＰ電話の発着呼の際に用いられる一般的なＳＩＰのセッションのシーケンスを示している。ここでは端末Ａが端末Ｂを発呼する場合の通信の様子を示している。図６（あるいは後述の図７）のＳＩＰメッセージの詳細は前述のＳＩＰ関連の各ＲＦＣに記載されている。

まず、ＩＰ電話サービスのエンドポイントである端末ＡはＩＮＶＩＴＥ（ステップＳ６０１）をＳＩＰ／Ｐｒｏｘｙサーバへ送信する。ＳＩＰ／Ｐｒｏｘｙサーバ５０１がこのＩＮＶＩＴＥを受信するとＩＮＶＩＴＥメッセージに含まれるデータから端末Ａが発呼しようとする発呼先アドレスを特定し、エンドポイントである端末ＢへＩＮＶＩＴＥ（ステップＳ６０２）を送信する。

次に、ＳＩＰ／Ｐｒｏｘｙサーバ５０１は端末Ａに対して１００Ｔｒｙｉｎｇ（ステップＳ６０３：「１００」はＴｒｙｉｎｇメッセージを示す識別ないしはリザルトコードである。以下の他のメッセージも同様）を送信する。

そして、端末Ｂから１００Ｒｉｎｇｉｎｇ（ステップＳ６０４）がＳＩＰ／Ｐｒｏｘｙサーバ５０１へレスポンスとして戻ってくると、１８０Ｒｉｎｇｉｎｇ（ステップＳ６０５）として端末Ａへと送信する。この時点で端末Ａは端末Ｂを呼び出し状態となっており、通常の端末の仕様あるいは制御状態においては端末Ａでは呼び出し中のリングバックトーンが通話部１１４から送出され、端末Ｂでは電話の呼び出し音が鳴動して着信状態となっている。

次に、端末Ｂが着信に対して応答を行なうと、端末Ｂは２００ＯＫ（ステップＳ６０６）を送出し、ＳＩＰ／Ｐｒｏｘｙサーバ５０１を介して発呼側エンドポイントの端末Ａへ２００ＯＫ（ステップＳ６０７）が送信される。端末Ａはこれに対するレスポンスとしてＡＣＫ（ステップＳ６０８）を送信すると、ＳＩＰ／Ｐｒｏｘｙサーバ５０１を介して着呼側エンドポイントの端末ＢへＡＣＫ（ステップＳ６０９）が送信される。

これらのシーケンスに続いて、メディアセッション（ステップＳ６１０）が開始されエンドポイント間で通話状態となる。メディアセッションにおいては、下位層においてフロー制御・送達確認を行なわないＵＤＰを使用し、その上位層についてはたとえばＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）／ＲＴＣＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が用いられ符号化された音声データ通信が行なわれる。音声データの符号化・復号化には、Ｇ．７１１、Ｇ．７２６、Ｇ．７２９などの規定された方式があり、使用帯域によって適当な符号化・復号化方式が選択される。

通話が終了する場合は、通話のメディアセッションを終了するシーケンスとして、端末ＡからＢＹＥ／ＯＫがＳＩＰ／Ｐｒｏｘｙサーバ５０１に発信され、さらに同メッセージが端末Ｂへと発信される。これにより端末Ａと端末Ｂの通話が終了する（ステップＳ６１１〜Ｓ６１４）。

図７は、本実施例において端末Ｂが留守などの事情で端末Ａの発呼に応答しなかった場合のシーケンスを示している。

図７のステップＳ７０１〜Ｓ７０６は図６のステップＳ６０１〜Ｓ６０５とほぼ同様の発呼シーケンスで、まず端末ＡからＩＮＶＩＴＥ（ステップＳ７０１）をＳＩＰ／Ｐｒｏｘｙサーバ５０１に送信する。

ＳＩＰ／Ｐｒｏｘｙサーバ５０１がそれを受信しさらに、ＩＮＶＩＴＥ（ステップＳ７０２）を端末Ｂに対して送信する。次にＳＩＰ／Ｐｒｏｘｙサーバ５０１は１００Ｔｒｙｉｎｇ（ステップＳ７０３）を端末Ａに送信する。端末ＢはＩＮＶＩＴＥを受け、１００Ｔｒｙｉｎｇ（ステップＳ７０４）、続いて１８０Ｒｉｎｇｉｎｇ（ステップＳ７０５）をＳＩＰ／Ｐｒｏｘｙサーバ５０１に送信する。次にＳＩＰ／Ｐｒｏｘｙサーバ５０１は端末Ａに１８０ Ｒｉｎｇｉｎｇ（ステップＳ７０６）を端末Ａへと送信し、この時点で端末Ａが端末Ｂを呼び出している状態となる。

図７では端末Ｂが留守などの事情で端末Ａの発呼に応答していない。この時、端末Ｂはユーザを呼び出すために着信音等の報知手段にて呼び出しを行なうが、端末Ｂ側の使用者が電話に応答しない場合、そのことを端末Ｂ自体がタイムアウトで判断する。あるいは他の手段として端末Ｂが留守と判断する他の方法として、端末Ｂが留守番電話モード等の設定になっている場合にも端末Ａの発呼に対して応答しないと端末Ｂ自身が判断しても良い。

いずれにしてもこのように端末Ｂの使用者が電話で応答しない場合は、端末Ｂは３０２Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（ステップＳ７０７）をＳＩＰ／Ｐｒｏｘｙサーバ５０１経由で端末Ａに送信する。本実施例では、このリダイレクトレスポンスのＣｏｎｔａｃｔヘッダに端末Ｂがメール受信可能なメールサーバ（たとえば図５のメールサーバ５０２）のコンタクトＵＲＩを含めて送信する。このＣｏｎｔａｃｔヘッダを参照することにより、端末Ａは後ほどボイスメッセージを送信する宛先を取得することができる。

そしてＳＩＰ／Ｐｒｏｘｙサーバ５０１は端末Ｂに対してＡＣＫ（ステップＳ７０８）を送信し、続いて３０２Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（ステップＳ７０９）を端末Ａへ送信する。端末Ａはこれを受けてＡＣＫ（ステップＳ７１０）をＳＩＰ／Ｐｒｏｘｙサーバ５０１に送信する。

この後、端末Ａではボイスメッセージの作成（ステップＳ７１１）を行なう。

端末Ａでは３０２Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（ステップＳ７０９）をＳＩＰ／Ｐｒｏｘｙサーバ５０１を経由して発呼先のエンドポイントである端末Ｂから受信すると、発呼先がダイヤルに対して応答していないと判断し、続いてボイスメッセージの作成（ステップＳ７１１）を行なう。

ボイスメッセージの作成は、従来のアナログ回線の電話機にて相手の電話機が留守番電話応答している場合に、受話器に対して発呼者がメッセージを録音する要領と同じ操作感で行なえるようにする。

メッセージ録音に際しては、端末Ａにおいて、図１の通話部１１４に含まれる受話器によって操作者の音声が入力され、ＣＯＤＥＣ１０７にて音声符号化をする。音声符号化ではＤＲＡＭ１０３内のコーデックワークエリア１０３２を符号化ワーク領域として使用する。そして音声符号化されたデータは一旦、ＤＲＡＭ１０３内のメールデータ格納エリア１０３７に音声ファイルとして格納する。

なお、ここでは用件メッセージを音声として扱いメッセージデータの作成を行なう例を示したが、それとは別の方法として発呼者の音声を音声認識して文字情報に変換して発呼者のメッセージを文字情報のメールとしてメッセージデータの作成を行なっても良い。音声認識に関しては公知の技術であるので詳細な説明は割愛するが、その場合でも図７のボイスメッセージの作成（ステップＳ７１１）でメールとして送信できるフォーマットに変換を行なうフローに変わりはない。

文字情報に変換してボイスメッセージを送信する場合のメリットとしては、相手端末が音声を復号化して再生する手段を有さなくても文字情報として相手にメッセージを伝えることができる。

また、相手端末が文字情報を音声合成によって再び音声情報として聞く機能を有する場合は、発信側の端末から受信側の端末に用件メッセージを文字情報という形式で送信することによって情報伝達経路上のデータ量を小さくしトラフィックを減少できる効果を有し、さらに送信先の相手端末内では音声のデータと比較して小さなメモリサイズにてボイスメッセージを保有できるという効果を有することが可能となる。

次に、ボイスメッセージの作成が終わると、図７において端末Ａはｔｅｌｎｅｔでメールサーバ５０２のＴＣＰ２５番ポート（ＳＭＴＰポート）に接続する（ステップＳ７１２）。メールサーバ５０２とのコネクションが成立するとメールサーバ５０２からＣｏｎｎｅｃｔが返信され、ｔｅｌｎｅｔでの接続状態となる。

次にメールデータ格納エリアに格納されたボイスメッセージの音声ファイルをメールサーバ５０２に送信する（ステップＳ７１４）。音声ファイルはＳＭＴＰで規定されたフォーマット、たとえばＭＩＭＥフォーマットによりエンコードされ電子メールテキスト内に添付される。

図５の説明で示した通り、端末Ａ、端末Ｂともにインターネット上のメールサービスのアカウントを有しており、図５においてのメールサーバ５０２に対してＳＭＴＰ／ＰＯＰ３により接続しメール送受信が可能であり、前記ボイスメッセージを送信する相手先のアドレスに関しても、ＥＮＵＭ ＤＮＳサーバ５０５にアクセスすることにより相手電話番号に関連付けられたメールアドレスを求めることが可能となっている。メールデータとして作成されたボイスメッセージはこのようにして求めたメールアドレスを宛先として送信を行なうものである。

なお、前記のＥＮＵＭ ＤＮＳサーバにアクセスして相手のメールアドレスを取得する方法とは別の方法として、あらかじめ相手のメールアドレスを電話番号と関連付けて自機内メモリに保持しておき、電話を発信する際の電話番号からこの自機内のメールアドレスを取得して送信宛先として送信を行なう方法でも良い。この際の前記あらかじめ相手のメールアドレスを電話番号と関連付けて自機内メモリに保持しておく手法に関しては従来のファクスや携帯電話等の電話帳登録の構成と同等であるため公知な内容にあたるため説明は割愛する。

相手端末のメールアドレスに対して電子メールテキストの送受信が成功すると、メールサーバ５０２からＯＫが返信される（ステップＳ７１５）。ここでは音声データをＵＤＰ／ＩＰベースのメディアセッションではなく、ＴＣＰ／ＩＰベースでのサービスで音声データを送信するようにしているため、音声データは欠落や歪みを生じることなく、符号化された時と同じ状態で確実に送信することができ、したがって音声品質を確保することが可能となる。

次に端末Ａはｑｕｉｔ（ステップＳ７１６）を送信してメールサーバ５０２とのＳＭＴＰ接続を切断する。メールサーバ５０２からＣｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅｄ（ステップＳ７１７）のレスポンスを受信するとメール送信は完了する。

図８は図６の通常発着呼、および図７の相手不在時のシーケンスを実行するため図１の端末装置（上記の端末Ａ）が行なう通信制御の様子を示している。図８はダイヤル発信スタートから通話が終了するまでのフローを示しており、図示の手順は図１のＣＰＵ１０１の制御プログラムとしてたとえばＲＯＭ１０２などに格納しておく。

図８のステップＳ８０１でダイヤル発信をスタートすると、ステップＳ８０２においてＩＰ電話の呼接続を成立させるべくＳＩＰの呼制御に入る。ＳＩＰの呼制御に関しては図６〜図７に示した通りである。

図７のように端末Ａが３０２Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（ステップＳ７０９）を受信し、ＳＩＰ呼制御にて相手端末が応答しなかったと判断される場合は、ステップＳ８０３にて相手端末応答がＮＯであると判断し、留守メッセージ作成ＵＩ（ステップＳ８０５）へと遷移する。

また、図６のように端末Ａが２００ＯＫ（ステップＳ６０７）を受信し、着呼側が応答したと判断した場合には、ＹＥＳに分岐しステップＳ８０４の通話中ＵＩへ遷移する。この場合はステップＳ８０４において着呼側との間でメディアセッションを生成し、ＶｏＩＰによる通話を行なわせる。

ステップＳ８０３の判断がＮＯでステップＳ８０５の留守メッセージ作成ＵＩへ遷移した場合は次のような処理を行なう。

ステップＳ８０５の留守メッセージ作成ＵＩでは、端末装置（端末Ａ）の表示部１０６および操作部１０８を用いて発呼者が音声メッセージを作成するための操作を行なわせる。留守メッセージ作成ＵＩの具体例（主に画面表示）については後述する。

ステップＳ８０６では、操作部１０８のユーザ操作の状態を調べる（後述のユーザーインターフェースを参照）ことにより留守メッセージ録音を中止するかどうかを判断し、留守メッセージ録音を中止する場合はステップＳ８１０へ遷移して通話終了となる。メッセージ作成を続行する場合は、ステップＳ８０７にて音声録音と符号化を行なう。音声の入力に関しては図１の通話部１１４の受話器によって操作者の音声を入力し、ＣＯＤＥＣ１０７により音声符号化をする。音声符号化されたデータは一旦、ＤＲＡＭ１０３に音声ファイルとして格納され、さらにステップＳ８０８でメール送信可能な電子メールフォーマットに変換される。この電子メールフォーマットは前述のようにＭＩＭＥ形式の規定にしたがって行ない、音声データは添付ファイルとして電子メールテキストに添付する。ステップＳ８０９では電子メールテキストにフォーマットされたデータをＳＭＴＰプロトコルを用いてメールサーバ５０２に送信する。電子メールテキストの送信が終了すると、ダイヤル発信スタートからの操作シーケンスを終了する。

図９は図８のステップＳ８０５における上記の留守メッセージ作成において表示部１０６および操作部１０８を用いて実施するユーザーインターフェースの一例を示している。図９は、この操作シーケンスのうち、相手端末が応答しない場合の表示からボイスメッセージを送信するまでの表示画面を示している。

ＳＩＰの呼制御において相手端末が応答しなかった場合の初期画面としては、図９の画面９０１のように相手端末が無応答であることを示すため画面中央部に「呼び出しましたが応答がありません」という文字列表示を行なう。また、この画面９０１では、上記文字列表示の下部に相手略称、相手電話番号、相手のメールアドレス等を表示している。この相手端末に関する情報は、ＳＩＰ／Ｐｒｏｘｙサーバ５０１を介してＲＦＣ２９１６に規定されているＥＮＵＭ情報から取得することが可能であり、ＳＩＰ呼制御においてユーザエージェントである端末がサーバから取得することができる。なお、この画面９０１で表示すべき情報は上記に限らずたとえば相手端末に関する他の任意の情報を表示することができる。また、画面９０１の下部には進行中の発呼（あるいは自動的に起動される再発呼も含んでよい）の中止を指示するためのボタン９０１ａを表示している。ボタン９０１ａは、左右上下方向キー４０６などにより選択し、セットキー４０５により確定入力を行なうような方式で操作（または表示部１０６がタッチパネル方式であれば直接入力したり、あるいはマウスなどのポインティングデバイスで操作する）する（後述の他のボタンも同様）。

画面９０１に続いて、所定時間の経過（あるいは操作部１０８の所定の操作）に応じて画面９０２へと遷移し、この画面からユーザに音声メッセージの録音を開始させる。ここでは、画面中央部に「続けて音声メッセージ録音を開始します」および「ピーという発信音の後にメッセージを録音してください」という趣旨の文字列表示を行ない、ユーザに対して音声メッセージ録音のタイミングを報知する。また、画面９０２の下部には、ボタン９０２ａ、９０２ｂ、９０２ｃが配置されている。ボタン９０２ａはボタン９０１ａと同様のダイヤル中止ボタン、ボタン９０２ｂは録音の中止ボタン、ボタン９０２ｃは録音終了タイミングを指示するためのボタンである。

録音が終了（所定録音時間の計時終了か、あるいはボタン９０２ｃの操作により指示される）すると画面９０３に遷移し、録音したボイスメッセージを上述のようにして電子メールとして相手端末へ送信することを表示する。画面９０３の下部には、当該電子メールの送信を中止させるためのボタン９０３ａが配置されている。

以上のように、発呼した相手が応答しなかった場合に図９のようなユーザーインターフェースを用いて音声メッセージを録音し、電子メールで送信することができ、従来のアナログ回線の留守番電話と同等ないしそれ以上の操作感で、ＩＰ電話の留守番電話の一形態であるＵＩを好適に実現することができる。

以上のように、本実施例によればＩＰ電話システムにおいて相手端末が応答しなかった場合、従来のアナログ回線の留守番電話の操作感を損なうことのない好適な操作性を実現することが可能となる。また、たとえＩＰ電話のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）が低い状況に置かれている端末においても、一旦音声メッセージを符号化してメール形式で送信する構成を採用しているため、データ欠落がない状態で音声を相手端末へ送信することが可能であり、したがってネットワークとの接続に移動体通信方式などを用いている場合でも音声品質を低下させることなく留守録メッセージを相手端末に伝達できるテレフォニーアプリケーションとして非常に有利な構成を提供することができる。

以上の実施例１では、ＶｏＩＰによる発呼を行なったが相手端末が応答しなかった場合に用件メッセージとして音声メッセージを電子メール送信するようにしたが、本実施例では用件メッセージとしてビデオメッセージを電子メール送信する例を示す。

以下の実施例では、図面は実施例１と同様の様式のものを用い、また、実施例１と同一ないし相当する部材には同一（または類似）の参照符号を用い、その詳細な説明は省略するものとする。なお、本実施例において、実施例１と対応する図面が無い場合は、本実施例の構成と矛盾しない範囲で実施例１において対応する図面に示した構成を利用できる。

図１０は実施例１の図１に相当し、本発明を採用した端末装置の構成を示している。図１０で図１と異なるのは、動画（あるいは静止画）撮影のためにＣＣＤ１１５が追加されている点、および図１のＣＯＤＥＣ１０７が動画の符号化・復号化を行なうＭＰＥＧ４ＣＯＤＥＣ１１６に置き換えられている点である。ＣＣＤ１１５は、特に本端末装置をテレビ電話として使用する目的で、後述のようにユーザの動画映像を撮影できるよう配置される。

その他のブロックについては、実施例１の図１に関する説明におけるのと同様に構成される。また、表示部１０６廻りの制御系の構成は図２と同様である。

図１１は実施例１の図３に対応し、ＤＲＡＭ１０３の内部構成を示したメモリマップであり、図３と異なるのは図３のコーデックワークエリア１０３２がＭＰＥＧ４の符号化・復合化を行なう際にワークエリアとして使用するＭＰＥＧ４のコーデックワークエリア１０３８に置換されている点である。その他の構成は図３と同等である。

図１２は実施例１の図４に対応し、表示部１０６および操作部１０８の部分の外観構成を示している。図４との相違は、図１に示したＣＣＤ１１５がＬＣＤ２０２の上部に設けられている点である。ＣＣＤ１１５はユーザの顔や上半身部分を撮影できるように、ユーザ方向に撮影レンズを向けることができるよう配置される（チルトやパンが可能なように回動支持される構成でもよい）。

本実施例において図１０に示した端末装置は、実施例１と同様に図５のようなＳＩＰ／ｐｒｏｘｙサーバ５０１、メールサーバ５０２、ＥＮＵＭ ＤＮＳサーバ５０５が配置されたネットワーク構成で使用することができる。本実施例においても少なくとも発呼側の端末（Ａ）５０３は図１０の端末装置から構成されるものとし、ＩＰ接続には上述の通信部１１２が用いられる。

本実施例においても、ＩＰ電話発着呼はＳＩＰを利用して制御する。通常時のＩＰ電話発着呼シーケンスは図６に示した通りであるが、相手が不在などの理由で無応答の場合の電話発着呼シーケンスは図１３のように行なう。

この図１３は実施例１の図７のシーケンスに相当するものである。図７との相違は、相手が無応答の場合に行なう図３のステップＳ７１１で行なうボイスメッセージの作成がステップＳ７１８のビデオメッセージ作成に置換されている点である。その他のシーケンスは図７と同一参照符号で示した通りであり、図７のものと変らない。

図１４は実施例１の図８に相当し、図６の通常発着呼、および図１３の相手不在時のシーケンスを実行するため図１０の端末装置（上記の端末Ａ）が行なう通信制御の様子を示している。図１４はダイヤル発信スタートから通話が終了するまでのフローを示しており、図示の手順は図１のＣＰＵ１０１の制御プログラムとしてたとえばＲＯＭ１０２などに格納しておく。

図１４では図８で用いられていた８００番台のステップ番号を１８００番台にそれぞれ置き換えている。図８との比較から明らかなように、図８と異なるのはステップＳ１８０５〜Ｓ１８０９で音声メッセージのかわりにビデオメッセージを電子メールで送信する点である。ステップＳ１８０１〜Ｓ１８０３の発呼、およびステップＳ１８０４の通話（ただし、音声通話のみならず、この通話ではＣＣＤ１１５で撮影したユーザの画像を交換しつつ行なういわゆるテレビ電話の通話を行なってもよい）は図８と同様に制御される。以下では、図１４のステップＳ１８０５〜Ｓ１８０９のビデオメッセージ作成および電子メールによる送信につき説明する。

ステップＳ１８０５のビデオ（留守）メッセージ作成ＵＩへの遷移は相手端末が不在などの理由で無応答であり、ステップＳ１８０３の判断がＮＯとなった場合に行なわれる。

ステップＳ１８０５のビデオメッセージ作成ＵＩでは、端末装置（端末Ａ）の表示部１０６、操作部１０８、およびＣＣＤ１１５を用いて発呼者がビデオ（留守）メッセージを作成するための操作を行なわせる。ビデオ（留守）メッセージ作成ＵＩの具体例（主に画面表示）については後述する。

ステップＳ１８０６では、操作部１０８のユーザ操作の状態を調べる（後述のユーザーインターフェースを参照）ことによりビデオ（留守）メッセージ録音を中止するかどうかを判断し、ビデオ（留守）メッセージ録音を中止する場合はステップＳ１８１０へ遷移して通話終了となる。メッセージ作成を続行する場合は、ステップＳ１８０７にてメッセージ録画と符号化を行なう。画像入力は図１／図１２のＣＣＤ１１５により、また、音声入力は図１の通話部１１４の受話器によって操作者の音声を入力することにより行なう。入力された画像および音声はＭＰＥＧ４ＣＯＤＥＣ１１６によりＭＰＥＧ４の動画フォーマットに符号化される。

符号化されたデータは一旦、ＤＲＡＭ１０３にビデオデータファイルとして格納され、さらにステップＳ１８０８でメール送信可能な電子メールフォーマットに変換される。この電子メールフォーマットは前述のようにＭＩＭＥ形式の規定にしたがって行ない、ビデオデータは添付ファイルとして電子メールテキストに添付する。ステップＳ１８０９では電子メールテキストにフォーマットされたデータをＳＭＴＰプロトコルを用いてメールサーバ５０２に送信する。電子メールテキストの送信が終了すると、ダイヤル発信スタートからの操作シーケンスを終了する。

図１５は実施例１の図９に対応し、上記のビデオ（留守）メッセージ作成（ステップＳ１８０５）において表示部１０６、操作部１０８、およびＣＣＤ１１５を用いて実施するユーザーインターフェースの一例を示している。図１５は、この操作シーケンスのうち、相手端末が応答しない場合の表示からボイスメッセージを送信するまでの表示画面を示している。

ＳＩＰの呼制御において相手端末が応答しなかった場合の初期画面としては、図１５の画面１９０１のように相手端末が無応答であることを示すため画面中央部に「呼び出しましたが応答がありません」という文字列表示を行なう。また、この画面１９０１では、上記文字列表示の下部に相手略称、相手電話番号、相手のメールアドレス等を表示している。この相手端末に関する情報は、ＳＩＰ／Ｐｒｏｘｙサーバ５０１を介してＲＦＣ２９１６に規定されているＥＮＵＭ情報から取得することが可能であり、ＳＩＰ呼制御においてユーザエージェントである端末がサーバから取得することができる。図９の場合と同様に、この画面１９０１で表示すべき情報は上記に限らずたとえば相手端末に関する他の任意の情報を表示することができる。また、画面１９０１の下部には進行中の発呼（あるいは自動的に起動される再発呼も含んでよい）の中止を指示するためのボタン１９０１ａを表示している。このボタン１９０１ａあるいは後述の他のボタンの操作方式については、実施例１で述べたのと同様の構成を用いることができる。

画面１９０１に続いて、所定時間の経過（あるいは操作部１０８の所定の操作）に応じて画面１９０２に遷移してビデオメッセージの録画を開始するための準備画面を数秒間表示（図１５の画面１９０２は録画開始３秒前の状態を示している）させ、ユーザに録画の準備期間を与えた後、さらに画面１９０３へ遷移し、ビデオメッセージの録画を開始する。なお、画面１９０２の下部にはボタン１９０１ａと同様の発呼処理全体を中止するためのボタン１９０２ａと、録画を中止するためのボタン１９０２ｂを配置する。

画面１９０３では「ビデオメッセージ録画中」という旨の表示あるいはさらに適当な報知音等を発生することによりユーザに対してビデオメッセージ録画のタイミングを報知し、以後、ＣＣＤ１１５を用いてユーザの顔ないし上半身部分近傍の動画映像を撮影するとともに、通話部１１４の受話器などを用いて音声を入力する。なお、画面１９０３の下部には発呼処理を中止するためのボタン１９０３ａと、録画を中止するためのボタン１９０３ｂ、および録画の終了タイミングを指示するためのボタン１９０３ｂを配置する。

ビデオメッセージ録画が終了（所定録音時間の計時終了か、あるいはボタン１９０３ｃの操作により指示される）すると画面１９０４に遷移し、録画したビデオ（留守）メッセージを上述のようにして電子メールとして相手端末へ送信することを表示する。画面１９０４の下部には、当該電子メールの送信を中止させるためのボタン１９０４ａが配置されている。

以上のように、本実施例によれば、発呼した相手が応答しなかった場合に図１５のようなユーザーインターフェースを用いてビデオ（留守）メッセージを録音し、電子メールで送信することができ、従来のアナログ回線の留守番電話と同等またはそれ以上の操作感で、動画映像でのコミュニケーションを行うことができる。

本実施例においても、ＣＣＤなどを搭載し動画映像でのコミュニケーションを行うことが可能なＩＰ電話端末のシステムにおいて、相手端末が応答しなかった場合、従来のアナログ回線の留守番電話の操作感を損なうことがなく、好適な操作性を実現するメッセージ伝達を行うことが可能となる。また、ＩＰ電話のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）が低い状況に置かれている端末においても、一旦ビデオメッセージを符号化してメール形式で送信する構成を採用しているため、データ欠落がない状態で音声と動画を相手端末へ送信することが可能であり、したがってネットワークとの接続に移動体通信方式などを用いている場合でも音声品質を低下させることなく留守録メッセージを相手端末に伝達できるテレフォニーアプリケーションとして非常に有利な構成を提供することができる。

以上の各実施例で示したように、相手端末が無応答の場合、電子メールで音声メッセージや画像メッセージを用件メッセージとして送信する構成によれば、高品質の用件メッセージを相手端末に送信でき、また、各実施例で示したようなユーザーインターフェースを用いることにより、発呼側の端末装置で旧来の留守番電話と同等あるいはそれ以上の良好な操作性を得ることができる。以上の実施例では用件メッセージとして音声または動画データを電子メール送信する構成を示したが、無応答の不在の相手端末に送信すべき用件メッセージは、任意のマルチメディアメッセージで良い。たとえば、実施例２のような音声を含む動画データのかわりに動画データのみ、あるいは静止画または静止画とユーザ音声の組合せを電子メールで送信したり、あるいは音声データに任意の楽曲データ（ＭＩＤＩデータやデジタル化された音楽データ）を含めるようにしてもよい。

本発明の端末装置は、電話機や画像通信／入出力機能などを含むＭＦＰ、あるいは移動体通信端末（携帯電話など）などの製品として構成することができる。本発明の画像通信手順を実施するためのソフトウェアは、ＲＯＭ（あるいはＨＤＤなど）などの記憶媒体にあらかじめ出荷時から実装しておく他、ネットワーク経由でこれらの装置に導入し、また、アップデートを行なうよう構成することができる。

本発明を採用した端末装置のハードウェア構成を示したブロック図である（実施例１）。 図１の装置の表示部の構成を示したブロック図である。 図１の記憶部を構成するＤＲＡＭの構成を示したブロック図である。 図１の装置の操作部の構成を示した外観図である。 本発明を採用した端末装置がインターネット網に接続された形態を示した概要図である。 通話を行なう場合の標準的なＳＩＰ呼制御シーケンスを示したシーケンス図である。 本発明を採用した端末装置とネットワーク上の各機器による制御シーケンスを示したシーケンス図である。 本発明による発呼側端末（端末Ａ）の制御手順を示したフローチャート図である。 本発明による発呼側端末（端末Ａ）のＵＩ表示画面の一例を示した説明図である。 本発明を採用した端末装置の異なるハードウェア構成を示したブロック図である（実施例２）。 図１０の記憶部を構成するＤＲＡＭの構成を示したブロック図である。 図１０の装置の操作部の構成を示した外観図である。 本発明を採用した端末装置とネットワーク上の各機器による制御シーケンスを示したシーケンス図である。 本発明による発呼側端末（端末Ａ）の制御手順を示したフローチャート図である。 本発明による発呼側端末（端末Ａ）のＵＩ表示画面の一例を示した説明図である。

符号の説明

１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＤＲＡＭ
１０４ ＳＲＡＭ
１０５ センサ群
１０６ 表示部
１０７ ＣＯＤＥＣ
１０８ 操作部
１０９ 読取部
１１０ システムバス
１１１ 記録部
１１２ 通信部
１１３ 回線
１１５ ＣＣＤ

Claims (21)

1. ＩＰ電話プロトコルに基づき相手端末を発呼し、相手端末と少なくとも音声通信を行なう端末装置において、
   ＩＰ電話プロトコルに基づき相手端末を発呼するＩＰ電話発呼シーケンスを実行する手段と、
   発呼した相手端末が応答しないことがＩＰ電話プロトコルから判断される場合、ユーザの用件メッセージを蓄積する手段と、
   前記相手端末のメールアドレスに対して、前記用件メッセージデータを電子メールプロトコルを用いて送信する手段と、を有することを特徴とする端末装置。
2. 前記相手端末のメールアドレスは、前記ＩＰ電話プロトコルを介して取得することを特徴とする請求項１に記載の端末装置。
3. 前記相手端末のメールアドレスは、相手端末番号に関連付けて前記端末装置内メモリに保持しておいたメールアドレスを使用することを特徴とする請求項１に記載の端末装置。
4. 前記用件メッセージデータがユーザの音声データを含むことを特徴とする請求項１乃至３いずれか１項記載の端末装置。
5. 前記用件メッセージデータがユーザの映像を蓄積した画像データを含むことを特徴とする請求項１乃至３いずれか１項記載の端末装置。
6. 前記用件メッセージデータは前記ユーザのメッセージを音声認識して文字情報に変換した用件メッセージデータを含むことを特徴とする請求項１乃至３いずれか１項記載の端末装置。
7. ユーザの所定操作に応じて実行中の前記ＩＰ電話発呼シーケンスないし用件メッセージ蓄積の処理を中止させることを特徴とする請求項１乃至６いずれか１項記載の端末装置。
8. ＩＰ電話プロトコルに基づき相手端末を発呼し、相手端末と少なくとも音声通信を行なう端末装置の制御方法において、
   ＩＰ電話プロトコルに基づき相手端末を発呼するＩＰ電話発呼シーケンスを実行する制御過程と、
   発呼した相手端末が応答しないことがＩＰ電話プロトコルから判断される場合、ユーザの用件メッセージを蓄積する制御過程と、
   前記相手端末のメールアドレスに対して、前記用件メッセージデータを電子メールプロトコルを用いて送信する制御過程と、を含むことを特徴とする端末装置の制御方法。
9. 前記相手端末のメールアドレスは、前記ＩＰ電話プロトコルを介して取得することを特徴とする請求項８に記載の端末装置の制御方法。
10. 前記相手端末のメールアドレスは、相手端末番号に関連付けて端末内メモリに保持しておいたメールアドレスを使用することを特徴とする請求項８に記載の端末装置の制御方法。
11. 前記用件メッセージデータがユーザの音声データを含むことを特徴とする請求項８乃至１０いずれか１項記載の端末装置の制御方法。
12. 前記用件メッセージデータがユーザの映像を蓄積した画像データを含むことを特徴とする請求項８乃至１０いずれか１項記載の端末装置の制御方法。
13. 前記用件メッセージデータは前記ユーザのメッセージを音声認識して文字情報に変換した用件メッセージデータを含むことを特徴とする請求項８乃至１０いずれか１項記載の端末装置の制御方法。
14. ユーザの所定操作に応じて実行中の前記ＩＰ電話発呼シーケンスないし用件メッセージ蓄積の処理を中止させることを特徴とする請求項８乃至１３いずれか１項記載の端末装置の制御方法。
15. ＩＰ電話プロトコルに基づき相手端末を発呼し、相手端末と少なくとも音声通信を行なう端末装置の制御プログラムにおいて、
    ＩＰ電話プロトコルに基づき相手端末を発呼するＩＰ電話発呼シーケンスを実行する制御過程と、
    発呼した相手端末が応答しないことがＩＰ電話プロトコルから判断される場合、ユーザの用件メッセージを蓄積する制御過程と、
    前記相手端末のメールアドレスに対して、前記用件メッセージデータを電子メールプロトコルを用いて送信する制御過程と、を含むことを特徴とする端末装置の制御プログラム。
16. 前記相手端末のメールアドレスは、前記ＩＰ電話プロトコルを介して取得することを特徴とする請求項１５に記載の端末装置の制御プログラム。
17. 前記相手端末のメールアドレスは、相手端末番号に関連付けて端末内メモリに保持しておいたメールアドレスを使用することを特徴とする請求項１５に記載の端末装置の制御プログラム。
18. 前記用件メッセージデータがユーザの音声データを含むことを特徴とする請求項１５乃至１７いずれか１項記載の端末装置の制御プログラム。
19. 前記用件メッセージデータがユーザの映像を蓄積した画像データを含むことを特徴とする請求項１５乃至１７いずれか１項記載の端末装置の制御プログラム。
20. 前記用件メッセージデータは前記ユーザのメッセージを音声認識して文字情報に変換した用件メッセージデータを含むことを特徴とする請求項１５乃至１７いずれか１項記載の端末装置の制御プログラム。
21. ユーザの所定操作に応じて実行中の前記ＩＰ電話発呼シーケンスないし用件メッセージ蓄積の処理を中止させることを特徴とする請求項１５乃至２０いずれか１項記載の端末装置の制御プログラム。

Images