(57)【要約】【課題】記録した高画質動画の送受信が未遂に終わることを極力防止でき、受信側での正確な再生が期待できる通信端末装置を提供する。【解決手段】ユーザにより動画再生操作が行われると、撮像部１０３は撮像を開始し、撮像で得られた画像データに基づく動画データが記憶部１０４のバッファに蓄積される。制御部１０２は、バッファに蓄積された動画データを新規にオープンした画像ファイルに書き込む。制御部１０２は、画像ファイルの容量が制限容量に達した場合、当該画像ファイルをクローズし、新規に画像ファイルをオープンする。そして、オープンした画像ファイルに動画データを書き込む。制御部１０２は、生成した画像ファイル毎の情報（画像ファイル情報）を作成し、画像管理テーブル２０２にエントリする。制御部１０２は、画像ファイルを複数生成した際、各画像ファイルの再生順番を示す情報を画像管理テーブル２０２に格納する。【選択図】図２
2011160234.tif 000002
【特許請求の範囲】
【請求項１】
被写体を撮像する撮像手段と、
電子メール送受信手段と、
ユーザの操作を受け付ける操作手段と、
前記撮像手段による撮像の結果得られた動画データを蓄積する動画データ蓄積手段と、
電子メール送信時における最大送信可能容量が設定された容量制限情報を記憶する容量制限情報記憶手段と、
前記操作手段がユーザからの動画記録指示操作を受け付けると、新規に画像ファイルをオープンし、前記動画データ蓄積手段に蓄積された動画データを前記画像ファイルに書き込む動画データ書込手段と、
前記画像ファイルを記憶する画像記憶手段と、
前記画像記憶手段に記憶された前記画像ファイルの容量を監視する画像ファイル容量監視手段と、
該画像ファイル容量監視手段の監視結果に基づいて、前記画像ファイルの容量が前記最大送信可能容量に達したか否かを判定する容量判定手段と、
一の動画に係る画像ファイルが複数生成された際に、各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報を生成し、前記画像記憶手段に格納する関連画像ファイル情報生成手段と、を備え、
前記動画データ書込手段は、前記容量判定手段により、前記画像ファイルの容量が前記最大送信可能容量に達したと判定された場合、当該画像ファイルをクローズすると共に、新規に画像ファイルをオープンし、該オープンした画像ファイルに前記動画データ蓄積手段に蓄積された動画データを書き込む、
ことを特徴とする通信端末装置。
【請求項２】
前記容量制限情報には、通信先を示す情報がさらに設定されており、前記容量制限情報記憶手段には、通信先毎に異なる複数の容量制限情報が記憶され、
前記容量判定手段は、所定の条件に基づいて選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行う、
ことを特徴とする請求項１に記載の通信端末装置。
【請求項３】
前記容量判定手段は、電子メールの通信履歴を参照して、所定期間内で電子メール送受信の頻度が最も高い通信先を選択し、該選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行う、
ことを特徴とする請求項２に記載の通信端末装置。
【請求項４】
前記容量判定手段は、電子メールの通信履歴を参照して、最も近時に電子メールの送受信を行った通信先を選択し、該選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行う、
ことを特徴とする請求項２に記載の通信端末装置。
【請求項５】
前記操作手段がユーザからの動画送信指示操作を受け付けると、前記関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得する送信対象画像ファイル取得手段と、
当該動画に係る画像ファイルが複数存在する場合に、前記関連画像ファイル情報に基づいた送信画像管理情報を生成する送信画像管理情報生成手段と、をさらに備え、
前記電子メール送受信手段は、前記送信対象画像ファイル取得手段が前記画像ファイルを取得する度に、当該画像ファイルのみを添付した電子メールを前記指定された宛先に送信し、当該動画に係る画像ファイルが複数存在する場合には、前記生成された送信画像管理情報を電子メールを用いて当該宛先に送信する、
ことを特徴とする請求項１乃至４の何れか１項に記載の通信端末装置。
【請求項６】
前記操作手段がユーザからの動画送信指示操作を受け付けると、ユーザが指定した宛先に、ユーザが指定した動画に係る画像ファイルの送信が可能か否かを判定する送信可能判定手段をさらに備え、
該送信可能判定手段が送信可能と判定した場合に限り、当該動画に係る画像ファイルが当該宛先に送信される、
ことを特徴とする請求項５に記載の通信端末装置。
【請求項７】
前記電子メール送受信手段は、前記送信画像管理情報を電子メールに添付して前記宛先に送信する、
ことを特徴とする請求項５又は６に記載の通信端末装置。
【請求項８】
前記電子メール送受信手段は、前記画像ファイルが添付された少なくとも何れかの電子メールのヘッダ部に前記送信画像管理情報を格納する、
ことを特徴とする請求項５又は６に記載の通信端末装置。
【請求項９】
ユーザの操作を受け付ける操作手段と、
複数の画像ファイルと、前記各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報と、を記憶する画像記憶手段と、
前記操作手段がユーザからの動画再生指示操作を受け付けると、前記関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得する再生対象画像ファイル取得手段と、
該再生対象画像ファイル取得手段が取得した画像ファイルを順次再生する再生手段と、を備える、
ことを特徴とする通信端末装置。
【請求項１０】
コンピュータに、
操作手段がユーザからの動画記録指示操作を受け付けると、撮像手段による撮像を開始させるステップと、
前記撮像の結果得られた動画データを動画データ蓄積手段に蓄積するステップと、
新規に画像ファイルをオープンし、前記動画データ蓄積手段に蓄積された動画データを前記画像ファイルに書き込むステップと、
前記画像ファイルの容量を監視するステップと、
前記監視の結果に基づいて、前記画像ファイルの容量が電子メール送信時における最大送信可能容量に達したか否かを判定するステップと、
前記画像ファイルの容量が前記最大送信可能容量に達したと判定された場合、当該画像ファイルをクローズすると共に、新規に画像ファイルをオープンし、該オープンした画像ファイルに前記動画データ蓄積手段に蓄積された動画データを書き込むステップと、
一の動画に係る画像ファイルが複数生成された際に、各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報を生成するステップと、
を実行させるためのプログラム。
【請求項１１】
コンピュータに、
操作手段がユーザからの動画再生指示操作を受け付けると、画像記憶手段に記憶されている複数の画像ファイルそれぞれの再生順番を示す情報を格納した関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得するステップと、
前記取得された画像ファイルを再生手段に順次再生させるステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信端末装置における動画の処理技術に関する。
【背景技術】
【０００２】
近年、動画記録機能を備えた携帯電話等の通信端末装置は、広く浸透している。また、昨今の撮像技術や映像符号化技術の進歩により、通信端末装置において高画質な動画を記録可能とするための種々の技術が提案されている（例えば、特許文献１等）。
【０００３】
通信端末装置で記録した動画の利用は様々であり、当該通信端末装置での再生のみならず、他の通信端末装置で再生できるように、電子メール（以下、単に「メール」と称する。）に添付して、当該他の通信端末装置に送信するケースも少なくない。これに関連し、特許文献２には、宛先の受信可能容量と自端末のメール送信可能容量から最適な容量のメールを送信するメール機能付き携帯通信端末が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−２６７０２０号公報
【特許文献２】特開２００６−８５２２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
高画質な動画とは、言い換えるならば、ビットあたりの符号量が大きい画像である。即ち、同じ時間記録した高画質な動画と低画質な動画とを比較すると、高画質な動画の方がファイル容量は大きくなる。
【０００６】
また、特許文献２に示すように、一般に、メールの送信及び受信には容量の制限がある。したがって、高画質の動画ファイルをメールに添付して送受信処理を行う場合、ファイル容量が大きいため、送受信容量の制限に抵触してしまい、動画ファイルを確実に送受信できないおそれがある。そうなると、受信側の通信端末装置では、元の動画を正確に再生することができない。
【０００７】
本発明は、上記実情に鑑みてなされたものであり、記録した高画質動画の送受信が未遂に終わることを極力防止でき、受信側での正確な再生が期待できる通信端末装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、本発明の第１の観点に係る通信端末装置は、
被写体を撮像する撮像手段と、
電子メール送受信手段と、
ユーザの操作を受け付ける操作手段と、
前記撮像手段による撮像の結果得られた動画データを蓄積する動画データ蓄積手段と、
電子メール送信時における最大送信可能容量が設定された容量制限情報を記憶する容量制限情報記憶手段と、
前記操作手段がユーザからの動画記録指示操作を受け付けると、新規に画像ファイルをオープンし、前記動画データ蓄積手段に蓄積された動画データを前記画像ファイルに書き込む動画データ書込手段と、
前記画像ファイルを記憶する画像記憶手段と、
前記画像記憶手段に記憶された前記画像ファイルの容量を監視する画像ファイル容量監視手段と、
該画像ファイル容量監視手段の監視結果に基づいて、前記画像ファイルの容量が前記最大送信可能容量に達したか否かを判定する容量判定手段と、
一の動画に係る画像ファイルが複数生成された際に、各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報を生成し、前記画像記憶手段に格納する関連画像ファイル情報生成手段と、を備え、
前記動画データ書込手段は、前記容量判定手段により、前記画像ファイルの容量が前記最大送信可能容量に達したと判定された場合、当該画像ファイルをクローズすると共に、新規に画像ファイルをオープンし、該オープンした画像ファイルに前記動画データ蓄積手段に蓄積された動画データを書き込む、ことを特徴とする。
【０００９】
上記第１の観点に係る通信端末装置において、
前記容量制限情報には、通信先を示す情報がさらに設定されており、前記容量制限情報記憶手段には、通信先毎に異なる複数の容量制限情報が記憶され、
前記容量判定手段は、所定の条件に基づいて選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行ってもよい。
【００１０】
上記の場合、前記容量判定手段は、電子メールの通信履歴を参照して、所定期間内で電子メール送受信の頻度が最も高い通信先を選択し、該選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行ってもよい。
【００１１】
あるいは、前記容量判定手段は、電子メールの通信履歴を参照して、最も近時に電子メールの送受信を行った通信先を選択し、該選択した通信先に対応する前記最大送信可能容量を用いて、前記判定を行ってもよい。
【００１２】
また、上記第１の観点に係る通信端末装置において、
前記操作手段がユーザからの動画送信指示操作を受け付けると、前記関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得する送信対象画像ファイル取得手段と、
当該動画に係る画像ファイルが複数存在する場合に、前記関連画像ファイル情報に基づいた送信画像管理情報を生成する送信画像管理情報生成手段と、をさらに備え、
前記電子メール送受信手段は、前記送信対象画像ファイル取得手段が前記画像ファイルを取得する度に、当該画像ファイルのみを添付した電子メールを前記指定された宛先に送信し、当該動画に係る画像ファイルが複数存在する場合には、前記生成された送信画像管理情報を電子メールを用いて当該宛先に送信する、ようにしてもよい。
【００１３】
上記の場合、前記操作手段がユーザからの動画送信指示操作を受け付けると、ユーザが指定した宛先に、ユーザが指定した動画に係る画像ファイルの送信が可能か否かを判定する送信可能判定手段をさらに備え、
該送信可能判定手段が送信可能と判定した場合に限り、当該動画に係る画像ファイルが当該宛先に送信される、ようにしてもよい。
【００１４】
また、前記電子メール送受信手段は、前記送信画像管理情報を電子メールに添付して前記宛先に送信してもよい。
【００１５】
あるいは、前記電子メール送受信手段は、前記画像ファイルが添付された少なくとも何れかの電子メールのヘッダ部に前記送信画像管理情報を格納してもよい。
【００１６】
本発明の第２の観点に係る通信端末装置は、
ユーザの操作を受け付ける操作手段と、
複数の画像ファイルと、前記各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報と、を記憶する画像記憶手段と、
前記操作手段がユーザからの動画再生指示操作を受け付けると、前記関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得する再生対象画像ファイル取得手段と、
該再生対象画像ファイル取得手段が取得した画像ファイルを順次再生する再生手段と、を備える、ことを特徴とする。
【００１７】
本発明の第３の観点に係るプログラムは、
コンピュータに、
操作手段がユーザからの動画記録指示操作を受け付けると、撮像手段による撮像を開始させるステップと、
前記撮像の結果得られた動画データを動画データ蓄積手段に蓄積するステップと、
新規に画像ファイルをオープンし、前記動画データ蓄積手段に蓄積された動画データを前記画像ファイルに書き込むステップと、
前記画像ファイルの容量を監視するステップと、
前記監視の結果に基づいて、前記画像ファイルの容量が電子メール送信時における最大送信可能容量に達したか否かを判定するステップと、
前記画像ファイルの容量が前記最大送信可能容量に達したと判定された場合、当該画像ファイルをクローズすると共に、新規に画像ファイルをオープンし、該オープンした画像ファイルに前記動画データ蓄積手段に蓄積された動画データを書き込むステップと、
一の動画に係る画像ファイルが複数生成された際に、各画像ファイルの再生順番を示す情報を格納した関連画像ファイル情報を生成するステップと、を実行させることを特徴とする。
【００１８】
本発明の第４の観点に係るプログラムは、
コンピュータに、
操作手段がユーザからの動画再生指示操作を受け付けると、画像記憶手段に記憶されている複数の画像ファイルそれぞれの再生順番を示す情報を格納した関連画像ファイル情報に基づいて、前記画像記憶手段からユーザが指定した一の動画に係る画像ファイルを順次取得するステップと、
前記取得された画像ファイルを再生手段に順次再生させるステップと、を実行させることを特徴とする。
【発明の効果】
【００１９】
本発明によれば、記録した高画質動画の送受信が未遂に終わることを極力防止でき、受信側での正確な再生が期待できる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係る通信端末装置の外観図である。
【図２】図１の通信端末装置の内部構成を示すブロック図である。
【図３】容量制限テーブルの一例を示す図である。
【図４】画像管理テーブルの一例を示す図である。
【図５】動画記録処理の手順を示すフローチャートである。
【図６】記録処理の手順を示すフローチャートである。
【図７】バッファへの動画データの蓄積について説明するための図である。
【図８】画像ファイルへの動画データの書き込みについて説明するための図である。
【図９】画像ファイルの切り替えについて説明するための図である。
【図１０】画像ファイル送信処理の手順を示すフローチャートである。
【図１１】関連画像ファイル送信処理の手順を示すフローチャートである。
【図１２】画像ファイル送信前の表示画面例を示す図である。
【図１３】画像ファイル送信中の表示画面例を示す図である。
【図１４】動画再生処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００２１】
以下、本発明の一実施形態について図面を参照して詳細に説明する。
【００２２】
図１は、本実施形態に係る通信端末装置１０の外観を示す図であり、図２は、この通信端末装置１０の内部構成を示すブロック図である。通信端末装置１０は、例えば、携帯電話である。なお、本発明に係る通信端末装置をＰＨＳ（Personal Handy-phone System）、ＰＤＡ（Personal Digital Assistant）、ＰＣ（Personal Computer）等で具現化してもよい。
【００２３】
通信端末装置１０は、操作部１０１と、制御部１０２と、撮像部１０３と、記憶部１０４と、画像容量監視部１０５と、通信部１０６と、表示部１０７と、音声処理部１０８と、多重／分離部１０９と、外部メモリドライバ１１０と、外部メモリＩ／Ｆ部１１１と、を備える。
【００２４】
操作部１０１は、各種のキーボタン等から構成され、ユーザからの操作入力を受け付け、受け付けた操作入力に係る信号を制御部１０２に送出する。操作部１０１は、ユーザから、例えば、当該通信端末装置１０の電源ＯＮ／ＯＦＦ操作、電話番号の入力やメール本文作成のための入力操作、被写体の撮像に係る操作等を受け付ける。
【００２５】
制御部１０２は、ＣＰＵ（Central Processing Unit）、主記憶装置等で構成され（何れも図示せず）、通信端末装置１０の各部を制御すると共に、記憶部１０４に記憶されている各種プログラムに基づいて、動画の記録や再生、電子メール（以下、単に「メール」と称する。）の作成や送信等、後述する各処理を実行する。なお、本実施形態において、制御部１０２は、動画データ書込手段、容量判定手段、関連画像ファイル情報生成手段、送信対象画像ファイル取得手段、送信画像管理情報生成手段、送信可能判定手段、再生対象画像ファイル取得手段、再生手段としての機能を担う。
【００２６】
撮像部１０３は、ＣＣＤ（Charge Coupled Device）やＡ／Ｄコンバータ等から構成され、被写体を撮像して得られた画像を光信号からアナログ電気信号に変換すると共に、アナログ電気信号をデジタル信号に変換する。例えば、撮像部１０３は、被写体である人物の顔や景色、文字等を撮像し、その結果得られた画像を制御部１０２で扱えるデジタル信号（画像データ）に変換する。制御部１０２は、撮像部１０３からの画像データを必要に応じて表示部１０７に出力する。
【００２７】
表示部１０７は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro-Luminescence）ディスプレイ等の表示デバイスで構成され、撮像部１０３により撮像された画像等を表示する。また、表示部１０７は、ユーザが通信端末装置１０の機能を利用するために必要な各種の情報（例えば、電源状態、電波強度、電池残量、サーバ接続状態等の動作状態、未読メールの有無、入力した電話番号や着信時の発呼者の電話番号、送受信メールの内容、動画及び静止画、インターネット接続時におけるＷｅｂ画面等の受信データ等）を表示する。
【００２８】
ユーザは、通信端末装置１０で動画を記録する際、表示部１０７に表示された画像をモニタしながら、所望のタイミングで、例えば、操作部１０１が備える所定のキーボタンを押下することで、動画記録開始操作を行う。なお、表示部１０７は、メインとサブの２つ、もしくはそれ以上の表示デバイスで構成されてもよい。
【００２９】
記憶部１０４は、例えば、フラッシュメモリ等の読み書き可能な不揮発性の半導体メモリで構成され、撮像部１０３によって得られたり、あるいは、他の通信端末装置との通信等により取得した画像ファイル、容量制限テーブル２０１、画像管理テーブル２０２を記憶する。また、記憶部１０４は、通信端末装置１０で扱うその他の各種データ、メーラ（電子メールクライアント）等のアプリケーションソフトウェア、本発明特有の機能を実現するためのプログラム等も記憶する。
【００３０】
容量制限テーブル２０１は、図３に示すように、容量制限ＩＤと、処理種別と、通信先と、制限容量と、が対応付けられた容量制限情報がエントリされたデータテーブルである。「処理種別」は、容量の制限を受ける処理内容が送信又は受信の何れであるかを示し、「通信先」は、通信相手を特定する情報（本実施形態では、ドメイン名）を示す。
【００３１】
「制限容量」は、処理種別や通信相手毎に制限を設けた容量（データサイズ）を示す。具体的には、処理種別が受信の場合は、通信端末装置１０が１回の通信で受信可能な最大のデータサイズを示している。また、処理種別が送信の場合は、当該通信相手に、１回の通信で送信可能な最大のデータサイズを示している。
【００３２】
図３の例では、処理種別が受信の際の制限容量は、通信相手によらず３ＭＢであることを示している。一方、送信の際の制限容量は、通信相手により異なり、ドメイン名が「＠ａｂｃ．ｃｏｍ」の場合には１ＭＢ、ドメイン名が「＠ｄｅｆ．ｃｏｍ」の場合には３ＭＢ、ドメイン名が「＠ｇｈｉ．ｃｏｍ」の場合には２ＭＢであることを示している。
【００３３】
容量制限テーブル２０１は、初期状態（出荷状態）では、１レコード（容量制限ＩＤ“Ｌ＿０１”の容量制限情報）のみがエントリされている。そして、新たな通信先とメールの送受信が行われると、当該通信先についての容量制限情報が制御部１０２によって自動的にエントリされる。なお、ユーザが、操作部１０１を介して、新たな通信先の容量制限情報をエントリしてもよいし、エントリされた容量制限情報を更新できるようにしてもよい。
【００３４】
なお、容量制限情報には、上記以外にも様々な項目が含まれていてもよい。例えば、通信相手のユーザが使用する通信端末装置の種別を示す項目等が含まれていてもよい。
【００３５】
画像管理テーブル２０２は、記憶部１０４に記憶している画像ファイルを適切に管理するための情報である。画像管理テーブル２０２は、画像ファイルに対して何らかの処理、例えば、記録、コピー、削除、再生、送信等を行う際に参照される。画像管理テーブル２０２は、画像ファイルの記録時に記憶部１０４に存在していなければ新規に作成され、既に存在している場合には内容が更新される。
【００３６】
画像管理テーブル２０２は、図４に示すように、画像ＩＤと、ファイル名と、ビットレートと、記録時間と、ファイル容量と、関連ファイルと、が対応付けられた画像ファイル情報がエントリされたデータテーブルである。図４の例では、先頭にエントリされた画像ファイル情報において、画像ＩＤ“Ｉ＿０１”が付与されており、ファイル名が“ＭＩｍｇ０００１．ｍｐ４”であることが示されている。そして、この画像ファイルは、記録時間が３秒間で、ビットレートが１Ｍｂｐｓであり、その容量が３ＭＢであることが示されている。さらに、この画像ファイルは、画像ＩＤ“Ｉ＿０２”及び画像ＩＤ“Ｉ＿０３”の各画像ファイルと関連があることが示されている。
【００３７】
「関連ファイル」には、記録した一連の動画が複数の画像ファイルに分割されて格納された場合に、関連する他の画像ファイルの情報が格納される。具体的には、関連する他の画像ファイルの画像ＩＤが格納される。図４の例では、動画を記録中に、画像ＩＤ“Ｉ＿０１”の画像ファイルの容量が制限容量（３ＭＢ）に到達し、以後の動画データが、画像ＩＤ“Ｉ＿０２”の画像ファイルに格納されたことが判る。そして、さらに、画像ＩＤ“Ｉ＿０２”の画像ファイルの容量も３ＭＢに到達したため、以後の動画データが、画像ＩＤ“Ｉ＿０３”の画像ファイルに格納されたことが判る。
【００３８】
即ち、画像ＩＤ“Ｉ＿０１”の画像ファイルと画像ＩＤ“Ｉ＿０２”及び画像ＩＤ“Ｉ＿０３”の各画像ファイルは、ファイルこそ異なるが、一連の動画を構成する画像ファイルである。したがって、これらの画像ファイルは、三つで一つの動画として扱うべきである。その扱い方の詳細については後述する。
【００３９】
図２に戻り、外部メモリＩ／Ｆ部１１１は、ｍｉｃｒｏＳＤカードやＵＳＢ（Universal Serial Bus）メモリ等の外部メモリ１１２と接続するためのハードウェアインタフェースであり、外部メモリドライバ１１０は、外部メモリＩ／Ｆ部１１１の制御を行う。例えば、多くの画像ファイルが記憶部１０４に格納された場合、記憶部１０４の空き容量が不足する可能性がある。そのため、本実施形態の通信端末装置１０は、外部メモリＩ／Ｆ部１１１及び外部メモリドライバ１１０を備えることで、外部メモリ１１２に画像ファイルを記録し、あるいは、外部メモリ１１２に記憶されている画像ファイルを読み出すことができるようにしている。なお、ユーザの操作中に外部メモリ１１２が脱落することがないように、外部メモリＩ／Ｆ部１１１は、通信端末装置１０の筐体側面に設けられていることが望ましい。
【００４０】
画像容量監視部１０５は、動画記録時に動作し、記憶部１０４のバッファ(図示せず)にリアルタイムで蓄積されて行く動画データの容量や画像ファイルの容量を監視し、その結果を制御部１０２に通知する。
【００４１】
音声処理部１０８は、音声入出力端子１１３から入力された音声データを圧縮して音声圧縮データを生成し、生成した音声圧縮データを多重／分離部１０９に供給する。また、音声処理部１０８は、多重／分離部１０９から供給された音声圧縮データを伸張して音声データに復元し、復元した音声データを音声入出力端子１１３から出力する。
【００４２】
多重／分離部１０９は、撮像部１０３によって得られた画像データを圧縮して映像圧縮データを生成し、生成した映像圧縮データと、音声処理部１０８が生成した音声圧縮データを多重化して動画データ（ストリームデータ）を生成する。また、多重／分離部１０９は、記憶部１０４や外部メモリ１１２から画像ファイルを読み出して、読み出した画像ファイルに格納されている動画データを映像圧縮データと音声圧縮データに分離する。そして、分離した映像圧縮データを伸張して映像データに復元し、復元した映像データを表示部１０７に供給すると共に、分離した音声圧縮データを音声処理部１０８に供給する。
【００４３】
通信部１０６は、アンテナ１１４等を備え、携帯電話における所定の通信方式にて、他の通信端末装置や情報処理装置とデータの送受を行う。また、通信部１０６は、基地局、ロケーションサーバ、ＧＰＳ(Global Positioning System)衛星等とデータの送受を行い、通信端末装置１０の位置座標（経度、緯度）等を取得する。また、通信部１０６は、通信端末装置１０がインターネットにアクセスするための通信処理等も行う。なお、通信部１０６は、例えば、ＣＤＭＡ（Code Division Multiple Access）、ＥＶ−ＤＯ（Evolution Data Only）、無線ＬＡＮ等の複数の通信方式を利用した通信が可能となるように構成してもよい。
【００４４】
画像容量監視部１０５、音声処理部１０８、多重／分離部１０９、外部メモリドライバ１１０の各機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）等、専用の回路にてハードウェア的に実現されるようにしてもよいし、制御部１０２が記憶部１０４等に記憶されているプログラムを実行することによる論理的処理で実現されるようにしてもよい。
【００４５】
続いて、以上のように構成された通信端末装置１０が実行する動画記録処理について、図５のフローチャートを参照して説明する。
【００４６】
動画記録処理は、ユーザによって、操作部１０１を介した動画記録開始操作が行われることで開始される。具体的には、ユーザは、例えば、表示部１０７に表示されるメニュー画面から「カメラ」→「動画記録」等の項目を選択することで動画記録処理を開始させることができる。なお、ショートカットキー等、特定のキーボタンが押下されることで、即座に動画記録処理が開始されるようにしてもよい。
【００４７】
制御部１０２は、ユーザによる動画記録開始操作の入力に応答して、動画記録処理を開始するための準備処理（記録準備処理）を実行する（ステップＳ１０１）。制御部１０２は、記録準備処理として、例えば、動画記録に必要な各種デバイスの初期化、動画データを蓄積する記憶部１０４のバッファ（キャッシュ）の初期化、記憶部１０４の空き容量の調査やビットレートの設定等の処理を実行する。また、空き容量とビットレートに基づいて、動画記録可能時間を算出し、算出した動画記録可能時間を表示部１０７に表示する等の処理も行う。
【００４８】
上記の動画記録準備処理の結果に基づき、制御部１０２は、動画記録が可能であるか否かを判定する(ステップＳ１０２)。動画記録が不可能な場合とは、例えば、記憶部１０４に新たな画像ファイルを記録するための空き容量がない、動画記録に欠かせないデバイスが何らかのトラブルで利用できない等の状態が該当する。このように動画記録が不可能な場合（ステップＳ１０２；ＮＯ）、制御部１０２は、表示部１０７に「メモリがいっぱいで動画記録ができません。」等のエラーメッセージを表示する等して、ユーザに動画記録ができない旨を報知する（ステップＳ１０３）。その際、ユーザの使い勝手を考慮して、「動画を記録するには不要なデータを削除して下さい。」等、エラーへの対処に関するメッセージを表示してもよい。
【００４９】
動画記録が可能な場合（ステップＳ１０２；ＹＥＳ)、制御部１０２は、ユーザによって、記録開始決定操作が行われた否かを判定する（ステップＳ１０４）。例えば、ユーザは、撮像部１０３によって撮像され、表示部１０７に表示される映像を見ながら、当該通信端末装置１０の高さや傾き、被写体との距離等を調整し、好みのタイミングで所定のキーやアイコンを操作することで、記録開始決定操作を行う。
【００５０】
ユーザによって、記録開始決定操作が行われると（ステップＳ１０４；ＹＥＳ）、制御部１０２は、各デバイスの状態を記録準備状態から記録開始状態へと変更する等の制御を行い、多重／分離部１０９により生成された動画データを記憶部１０４のバッファに蓄積して行くと共に、後述する記録処理を実行する（ステップＳ１０５）。図７はバッファに動画データを蓄積している様子の一例を図示したものである。ここで、１秒あたりどれだけのデータ量が格納されるかは、記録開始時に設定したビットレートによって異なり、ビットレートが高いほど１秒あたりにバッファに格納されるデータ量は多くなる。図７の詳細は後述する。
【００５１】
しかる後、ユーザから動画記録を終了するための操作（動画記録終了操作）等が行われると、ステップＳ１０５の記録処理は終了し、制御部１０２は、当該記録処理で生成した画像ファイルについての情報（画像ファイル情報）を画像管理テーブル２０２に追加する(ステップＳ１０６)。この際、画像管理テーブル２０２が記憶部１０４に存在しない場合は、制御部１０２は、画像管理テーブル２０２を新規作成後、新たに生成した画像ファイルについての情報を書き込む。以上で動画記録処理は終了する。
【００５２】
続いて、記録処理(ステップＳ１０５)の詳細について、図６のフローチャートを参照して説明する。
【００５３】
記録処理が開始されると、制御部１０２は、記憶部１０４から容量制限テーブル２０１を取得する(ステップＳ２０１)。次に、制御部１０２は送信予定先を決定する（ステップＳ２０２）。送信予定先とは、この記録処理で記録した動画に係る画像ファイルを送信する予定の通信先を意味する。本実施形態では、制御部１０２は、メールの通信履歴から、所定期間内でメール送受信の頻度が最も高い通信先を送信予定先として決定する。頻度が同一の通信先が複数存在し、何れかの制限容量に相違がある場合には、最も近時にメールの送受信を行った通信先を送信予定先として決定してもよいし、予めユーザが設定した通信先毎の優先度に従って、何れかの通信先を送信予定先として決定してもよい。
【００５４】
続いて、制御部１０２は、容量制限テーブル２０１を参照して、決定した送信予定先に対応する制限容量を取得する（ステップＳ２０３）。図３の例では、決定した送信予定先のドメインが“＠ｄｅｆ．ｃｏｍ”である場合には、送信の制限容量は３ＭＢとなる。
【００５５】
なお、未だメールの送受信を行っておらず、メールの通信履歴が０の場合、制御部１０２は、ステップＳ２０２の処理をスキップし、ステップＳ２０３の処理とは、別の方法で制限容量を取得する。例えば、出荷時等に予め設定された値やユーザが任意に設定した値を制限容量としてもよいし、処理種別が“受信”の場合の制限容量（図３では、３ＭＢ）と同一にしてもよい。あるいは、容量制限テーブル２０１において、実際に通信が行われる前に、ユーザによって事前に通信先毎の制限容量が設定されている場合には、その中で最も小さい値や、それらの平均値を送信の制限容量としてもよい。
【００５６】
続いて、制御部１０２は、動画を記録する画像ファイルの名称を決定する(ステップＳ２０４)。画像ファイルの名称は、予め定めた命名規則に従って決定する。制御部１０２は、例えば、通信端末装置１０毎やメーカ毎に予め決められた独自の命名規則や、通信端末装置１０間での再生互換性を確保するための統一命名規則等に従って画像ファイル名を決定する。本例では、新規にオープンする画像ファイル名を“ＭＩｍｇ０００１．ｍｐ４”として説明する。
【００５７】
制御部１０２は、画像ファイル（ＭＩｍｇ０００１．ｍｐ４）を新規オープンし、当該画像ファイルをデータ書き込み可能な状態にする(ステップＳ２０５)。
【００５８】
制御部１０２は、記録処理を継続するか否かを判定する（ステップＳ２０６）。具体的には、ユーザによって、動画記録終了操作が行われた否かを判定する。ユーザによって、動画記録終了操作が行われた場合（ステップＳ２０６；ＮＯ）、制御部１０２は、動画データのバッファへの蓄積を停止すると共に、その時点でバッファに蓄積されていた未書き込みの動画データを画像ファイル（例えば、ＭＩｍｇ０００１．ｍｐ４）に書き込む(ステップＳ２０７)。未書き込みの動画データを全て画像ファイルに書き込むと、制御部１０２は、オープンしていた画像ファイルをクローズし(ステップＳ２０８)、本処理（記録処理）を終了する。
【００５９】
一方、動画記録終了操作が行われていない場合（ステップＳ２０６；ＹＥＳ）、制御部１０２は、画像容量監視部１０５の監視結果に基づいて、バッファに蓄積した動画データのデータ量が予め設定した閾値に達しているか否かを判定する(ステップＳ２０９)。ここでの閾値（図７参照）は、蓄積した動画データをファイルに書き込むか否かを判定する際に使用するパラメータであり、制御部１０２は、動画データを閾値に達するまでバッファに蓄積させてから画像ファイルに書き込むように制御する。例えば、バッファの容量が２ＭＢ、閾値を１ＭＢとした場合、バッファに蓄積した動画データのデータ量が１ＭＢ以上になると、蓄積した動画データが画像ファイルに書き込まれる。
【００６０】
上記判定の結果、蓄積した動画データのデータ量が閾値に達している場合（ステップＳ２０９；ＹＥＳ）、制御部１０２は、当該動画データを画像ファイル（例えば、ＭＩｍｇ０００１．ｍｐ４）に書き込み（ステップＳ２１０）、閾値に達していない場合（ステップＳ２０９；ＮＯ）、ステップＳ２０６からの処理を繰り返す。
【００６１】
このように制御するのは、バッファに格納された動画データを逐次、画像ファイルに書き込むよりも、ある程度まで動画データを蓄積してから一定量毎に画像ファイルに書き込む方が、制御部１０２の発する命令数が少なく済み、処理負荷が低減され、処理の効率化、高速化が図れるからである。また、画像ファイルを記録する記録媒体(フラッシュメモリ、ハードディスクドライブ、各種のメモリカード等)やファイルシステムによっては、例えば、３２ＫＢの倍数のデータは効率良く高速に書き込める等の特徴を有するものがあり、この点を考慮しても、ある程度データを蓄積してからファイルに書き込む方が好ましいといえる。もちろん、このような制御は必ずしも必要ではなく、バッファに格納された動画データを逐次、画像ファイルに書き込むように制御してもよい。また、閾値はバッファ容量（例えば、２ＭＢ）以下であれば、任意の値が設定可能である。
【００６２】
図８は、バッファから画像ファイルへの書き込みを概念的に示した図である。図８では、蓄積した動画データのデータ量が閾値にまで到達したため、動画データが、順次、画像ファイル(ここでは、“ＭＩｍｇ０００１．ｍｐ４”)へ書き込まれて行く様子が示されている。ここで、画像ファイルへの書き込み単位は、上述した記録媒体毎に設定された書き込み効率の良い値を選択して採用するのが好ましい。
【００６３】
また、画像ファイルへの書き込み中、画像容量監視部１０５は、画像ファイルの容量を監視し、その結果に基づいて、制御部１０２は、画像ファイルの容量が、ステップＳ２０３で取得した制限容量に到達したか否かを判定する(ステップＳ２１１)。本例では、容量制限を３ＭＢとしているため、制御部１０２は、画像ファイルの容量が３ＭＢに到達したか否かを判定する。もしくは、バッファから画像ファイルへと書き込んだサイズが３ＭＢに到達したか否か等を判定してもよい。
【００６４】
上記判定の結果、制限容量に到達していない場合（ステップＳ２１１；ＮＯ）、ステップＳ２０６からの処理が繰り返し実行される。
【００６５】
一方、画像ファイルの容量が制限容量に到達した場合（ステップＳ２１１；ＹＥＳ）、当該画像ファイル(例えば、“ＭＩｍｇ０００１．ｍｐ４”)をクローズする(ステップＳ２１２)。そして、制御部１０２は、記録処理を継続するため、新たに画像ファイルをオープンする(ステップＳ２１３)。本例では、この画像ファイルのファイル名を“ＭＩｍｇ０００２．ｍｐ４”とする。新たな画像ファイルをオープン後、ステップＳ２０６からの処理が繰り返し実行される。図９には、バッファに蓄積された動画データを画像ファイル“ＭＩｍｇ０００１．ｍｐ４”に書き込み中に、画像ファイル“ＭＩｍｇ０００１．ｍｐ４”の容量が制限容量（ここでは、３ＭＢ）に到達したため、バッファに蓄積された残りの動画データを、新たにオープンした画像ファイル“ＭＩｍｇ０００２．ｍｐ４”に書き込む様子が示されている。
【００６６】
以降、ユーザによって動画記録終了操作が行われない限り（ステップＳ２０６；ＹＥＳ）、上記処理が繰り返し実行される。例えば、記録処理が継続した結果、“ＭＩｍｇ０００２．ｍｐ４”の容量が３ＭＢに到達すると（ステップＳ２１１；ＹＥＳ）、制御部１０２は、“ＭＩｍｇ０００２．ｍｐ４”をクローズし（ステップＳ２１２）、画像ファイル“ＭＩｍｇ０００３．ｍｐ４”を新規オープンし（ステップＳ２１３）、バッファに蓄積された動画データを“ＭＩｍｇ０００３．ｍｐ４”に書き込む（ステップＳ２１０）。
【００６７】
以上の記録処理が終了すると、上述したように、制御部１０２は、画像管理テーブル２０２を更新する（図５のステップＳ１０６）。例えば、当該動画記録時において、画像管理テーブル２０２が記憶部１０４に存在しない場合、制御部１０２は、画像管理テーブル２０２を新規作成後、新たに生成した画像ファイル（例えば、“ＭＩｍｇ０００１．ｍｐ４”、“ＭＩｍｇ０００２．ｍｐ４”及び“ＭＩｍｇ０００３．ｍｐ４”）についての情報（画像ファイル情報）を書き込む（図４参照）。
【００６８】
以上のようにして、動画を高画質で記録する際においても、メール送信時の容量制限に抵触しない画像ファイルを生成することができる。
【００６９】
続いて、上述の動画記録処理で生成した画像ファイルをメールに添付して送信する際の処理（画像ファイル送信処理）について、図１０及び図１１のフローチャートを参照して説明する。
【００７０】
ユーザは、メニュー画面から「メール」→「新規作成」等の項目を選択することで画像ファイル送信処理を開始させることができる。あるいは、ショートカットキー等、予め定義された特定のキーを押下することで、即座に画像ファイル送信処理が開始されるようにしてもよい。特に、本実施形態では、通常のメール送信とは異なり、動画を添付するメールの送信、さらには複数の画像ファイルで構成される一つの動画を送信する処理であるため、専用のショートカットキー等を設けると、通常のメール送信と明確に差別化ができ、ユーザの混乱を防ぐことができて便利である。かかる指示が入力されると、制御部１０２は、画像ファイル送信処理を開始する。
【００７１】
制御部１０２は、メールの送信先（宛先）の指定をユーザから受け付ける（ステップＳ３０１）。次に、制御部１０２は、添付する画像ファイルの指定をユーザから受け付ける（ステップＳ３０２）。例えば、制御部１０２は、記憶部１０４に保存している各画像ファイルについて、そのファイル名の一覧や、サムネイル等を表示部１０７に表示する。ユーザは、表示された添付候補の中から、メールに添付したい画像ファイルを選択する。図１２の（ａ）は、画像ファイル選択後における表示部１０７の表示画面の一例である。
【００７２】
制御部１０２は、ユーザが指定した画像ファイルが、当該宛先に送信可能か否かを判定する（ステップＳ３０３）。具体的には、制御部１０２は、画像管理テーブル２０２を参照して、ユーザが指定した画像ファイルのファイル容量を取得し、このファイル容量が、容量制限テーブル２０１で示される当該宛先（通信先）の制限容量以下であるか否かを判定する。その結果、送信不可、即ち、ユーザが指定した画像ファイルのファイル容量が当該宛先の制限容量を超えている場合（ステップＳ３０３；ＮＯ）、制御部１０２は、表示部１０７にエラーメッセージを表示し（ステップＳ３０４）、本処理（画像ファイル送信処理）を終了する。
【００７３】
一方、送信可能、即ち、ユーザが指定した画像ファイルのファイル容量が当該宛先の制限容量以下の場合（ステップＳ３０３；ＹＥＳ）、制御部１０２は、画像管理テーブル２０２を参照して、当該画像ファイルと関連する他の画像ファイルが存在するか否かを判定する（ステップＳ３０５）、関連する画像ファイルが存在しない場合（ステップＳ３０５；ＮＯ）、制御部１０２は、当該画像ファイルを添付したメールを当該宛先に送信し（ステップＳ３０６）、本処理を終了する。なお、メールの件名と本文は、必要に応じて、ユーザにより操作部１０１を介して入力されているものとする。
【００７４】
一方、関連する画像ファイルが存在する場合（ステップＳ３０５；ＹＥＳ）、制御部１０２は、関連画像ファイル送信処理を実行する（ステップＳ３０７）。なお、制御部１０２は、関連画像ファイル送信処理を実行する前に、図１２（ｂ）に示すように、関連する画像ファイルの一覧を表示部１０７に表示して、ユーザに提示してもよい。さらには、図１２（ｃ）に示すように、関連する画像ファイルも送信するか否かをユーザに確認してもよい。この場合、ユーザにより“いいえ”が選択されると、制御部１０２は、ステップＳ３０２で受け付けた画像ファイルのみを添付したメールを送信すればよい。
【００７５】
図１１は、関連画像ファイル送信処理の手順を示すフローチャートである。制御部１０２は、送信対象の画像ファイルを記憶部１０４から取得する（ステップＳ４０１）。ここで、当該関連画像ファイル送信処理の開始直後においては、図１０のステップＳ３０２で受け付けたユーザの指定した画像ファイルが送信対象の画像ファイルとなる。送信対象の画像ファイルを取得すると、制御部１０２は、当該画像ファイルを添付したメールを、図１０のステップＳ３０１で受け付けたユーザの指定した宛先に送信する（ステップＳ４０２）。
【００７６】
次に、制御部１０２は、未送信の画像ファイルが存在するか否かを判定する（ステップＳ４０３）。未送信の画像ファイルが存在する場合（ステップＳ４０３；ＹＥＳ）、制御部１０２は、次の送信対象の画像ファイルを記憶部１０４から取得する（ステップＳ４０１）、この際、未送信の画像ファイルが複数存在する場合、制御部１０２は、画像ＩＤが若い方から順に（即ち、昇順）、送信対象の画像ファイルとして取得する。そして、制御部１０２は、当該画像ファイルを添付したメールを当該宛先に送信する（ステップＳ４０２）。
【００７７】
未送信の画像ファイルが存在しない場合（ステップＳ４０３；ＮＯ）、送信した各画像ファイルについての画像ファイル情報を送信画像管理情報として送信し（ステップＳ４０４）、本処理（関連画像ファイル送信処理）を終了する。例えば、ユーザにより、画像ファイル“ＭＩｍｇ０００１．ｍｐ４”が選択された場合、上記の関連画像ファイル送信処理により、“ＭＩｍｇ０００１．ｍｐ４”→“ＭＩｍｇ０００２．ｍｐ４”→“ＭＩｍｇ０００３．ｍｐ４”が順次、相手先（例えば、“＠ｄｅｆ．ｃｏｍ”）に送信される。そして、その場合の送信画像管理情報は、図４に示す画像管理テーブル２０２の内容と同様になる。なお、送信画像管理情報の内容に限定はなく、送信した各画像ファイルの再生順番を示す情報が少なくとも含まれていればよい。
【００７８】
なお、送信画像管理情報の送信態様は様々である。例えば、本例の如く、全ての画像ファイルの送信後ではなく、画像ファイルの送信に先んじて送信してもよい。あるいは、画像ファイルと別個に送信するのではなく、何れかの画像ファイルを送信する際、当該メールのヘッダ部に、送信画像管理情報を埋め込むようにしても構わないし、各画像ファイルの送信毎に、その画像ファイルのみに対応する送信画像管理情報（即ち、画像ファイル情報）を当該ヘッダ部に埋め込むようにしてもよい。あるいは、画像ファイルに格納されている動画データのヘッダ部に送信画像管理情報を埋め込んでも構わない。
【００７９】
図１３は、上記の関連画像ファイル送信処理の実行中に表示部１０７で表示される画面の一例である。図１３(ａ)は、ステップＳ４０２において、最初の画像ファイル（例えば、“ＭＩｍｇ０００１．ｍｐ４”）を添付したメールを送信しているときの表示画面例を示す図である。図１３(ａ)において、画面中央のプログレスバーはメール送信の進行状況を示している。本例では、このプログレスバーは、“ＭＩｍｇ０００１．ｍｐ４”を添付したメールの送信状況ではなく、“ＭＩｍｇ０００１．ｍｐ４”及びそれに関連する画像ファイル全体の送信状況を示すものである。即ち、例えば、“ＭＩｍｇ０００１．ｍｐ４”を添付したメール１、“ＭＩｍｇ０００２．ｍｐ４”を添付したメール２、“ＭＩｍｇ０００３．ｍｐ４”を添付したメール３という、３通のメールを送信するときのトータルの進行状況を示している。
【００８０】
図１３（ａ)は、全３通のうちの１通目のメール（上記のメール１）を送信中の表示例であるため、プログレスバーは１００％の１／３である３３％を示している。また、図１３(ｂ)は、２通目のメール（上記のメール２）を送信中の表示例であるため、プログレスバーは１００％の２／３である６７％を示している。
【００８１】
続いて、記憶部１０４に保存している画像ファイルを再生する処理（動画再生処理）について説明する。図１４は、動画再生処理の手順を示すフローチャートである。動画再生処理は、ユーザによって、操作部１０１を介した動画再生操作が行われることで開始される。具体的には、ユーザは、例えば、表示部１０７に表示されるメニュー画面から「カメラ」→「動画再生」等の項目を選択することで動画再生処理を開始させることができる。なお、ショートカットキー等、特定のキーボタンが押下されることで、即座に動画再生処理が開始されるようにしてもよい。
【００８２】
制御部１０２は、ユーザによる動画再生操作の入力に応答して、動画再生のための準備処理（再生準備処理）を実行する（ステップＳ５０１）。制御部１０２は、再生準備処理として、例えば、動画再生に必要な各種デバイスの初期化、表示部１０７の表示を動画再生用の表示に切り替える等の処理を行う。
【００８３】
上記の再生準備処理の結果に基づき、制御部１０２は、動画再生が可能であるか否かを判定する(ステップＳ５０２)。動画再生が不可能な場合とは、例えば、記憶部１０４に画像ファイルが存在しない、動画再生に欠かせないデバイスが何らかのトラブルで利用できない等の状態が該当する。このように動画再生が不可能な場合（ステップＳ５０２；ＮＯ）は、制御部１０２は、表示部１０７に「動画再生ができません。」等のエラーメッセージを表示する等して、ユーザに動画再生ができない旨を報知する（ステップＳ５０３）。
【００８４】
動画再生が可能な場合（ステップＳ５０２；ＹＥＳ)、制御部１０２は、再生を所望する画像ファイルの指定をユーザから受け付ける（ステップＳ５０４）。例えば、制御部１０２は、記憶部１０４に保存している各画像ファイルについて、そのファイル名の一覧や、サムネイル等を表示部１０７に表示する。ユーザは、表示された再生候補の中から、再生を所望する画像ファイルを選択する。なお、上述したステップＳ５０２における判定処理を、ユーザが再生を所望する画像ファイルを選択した後に行っても構わない。例えば、ユーザが選択した画像ファイルが記録中のトラブルによって再生できないことや、外部メモリ１１２に記録されている画像ファイルが通信端末装置１０ではサポートしないフォーマットであるために再生できないこと等が起こり得るためである。
【００８５】
ユーザから再生する画像ファイルの指定を受け付けると、制御部１０２は、各デバイスの状態を再生準備状態から再生開始状態へと変更する等の制御を行う。
【００８６】
制御部１０２は、記憶部１０４に記憶されている画像管理テーブル２０２を読み出して、参照し、ユーザが選択した画像ファイルについての画像ファイル情報を取得する（ステップＳ５０５）。そして、制御部１０２は、ユーザが選択した画像ファイル（例えば、ＭＩｍｇ０００１．ｍｐ４）を多重／分離部１０９を制御すること等によって再生する（ステップＳ５０６）。この際、制御部１０２は、取得した画像ファイル情報の内容に基づいて再生制御を行う。
【００８７】
制御部１０２は、再生が画像ファイルの終端まで達すると、未再生の画像ファイルが存在するか否かを判定する（ステップＳ５０７）。より詳細には、制御部１０２は、当該画像ファイルの後に再生すべき画像ファイルが存在するか否かを判定する。具体的には、制御部１０２は、ステップＳ５０５で取得した画像ファイル情報の「関連ファイル」項目を参照して、設定されている画像ＩＤを調べる。そして、当該画像ファイルの画像ＩＤより昇順で進んだ画像ＩＤが存在する場合には、未再生の画像ファイルが存在すると判定する。
【００８８】
上記判定の結果、未再生の画像ファイルが存在しない場合（ステップＳ５０７；ＮＯ）、制御部１０２は、動画再生処理を終了する。一方、未再生の画像ファイルが存在する場合（ステップＳ５０７；ＹＥＳ）、制御部１０２は、画像管理テーブル２０２から、次の画像ＩＤに対応する画像ファイル情報を検索し、次に再生する画像ファイル（例えば、ＭＩｍｇ０００２．ｍｐ４）を決定する（ステップＳ５０８）。そして、制御部１０２は、当該画像ファイルを再生する（ステップＳ５０６）。
【００８９】
以降、ステップＳ５０７の判定でＮＯとなるまで、上述した処理が繰り返し実行される。その結果、例えば、“ＭＩｍｇ０００１．ｍｐ４”→“ＭＩｍｇ０００２．ｍｐ４”→“ＭＩｍｇ０００３．ｍｐ４”の順番で画像ファイルが再生される。
【００９０】
このように、上述の動画再生処理によって、ユーザによって選択された画像ファイルと、それに関連する１又は複数の画像ファイルとを連続的に再生することができる。
【００９１】
以上説明したように、本発明の通信端末装置によれば、動画記録の際、画像ファイルを送信する予定の宛先（通信先）におけるメール受信の制限容量を考慮して、動画データを格納する画像ファイルの容量を決定する。したがって、記録した動画に係る画像ファイルを確実に通信相手に送信することができる。
【００９２】
また、動画記録時において、一連の動画が複数の画像ファイルに分割されて格納された場合には、これらの画像ファイルの関連を示す情報を生成し、管理するため、本発明の通信端末装置で動画再生する際には、これらの画像ファイルを正しい順番で再生することができ、記録した動画を正確に再生することができる。また、他の通信端末装置等に画像ファイルを送信する際には、画像ファイルの関連を示す情報も併せて送信するため、受信側の通信端末装置等においても問題なく動画再生することができる。
【００９３】
なお、本発明は、上記実施形態に限定されず、本発明の要旨を逸脱しない範囲での種々の変更は勿論可能である。
【００９４】
例えば、メールの容量は、厳密には、添付する画像ファイル等の容量だけでなく、メール本文の文字数等も影響するが、この点に関しては、例えば、容量制限テーブル２０１（図３参照）に設定する各容量制限情報の制限容量において、予め、想定されるメール本文の容量を差し引いておけばよい。例えば、送信の制限容量が３ＭＢであり、予測されるメール本文の容量が最大０．１ＭＢである場合、容量制限テーブル２０１に設定する当該制限容量を２．９ＭＢ以下にすればよい。メール本文の最大容量は、例えば、入力可能な文字数を制限すること等により、ほぼ正確な値が予測可能である。この場合、関連する画像ファイルを送信する際に使用する件名や本文を定型化しておくと、さらに予測精度が向上する。
【００９５】
また、上記実施形態の通信端末装置１０が実行したプログラムを、既存の携帯電話等に適用することで、当該携帯電話等を本発明に係る通信端末装置として機能させることも可能である。
【００９６】
このようなプログラムの配布方法は任意であり、例えば、ＣＤ−ＲＯＭ（Compact Disk Read-Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＭＯ（Magneto Optical Disk）、メモリカード等のコンピュータで読み取り可能な記録媒体に格納して配布してもよいし、携帯電話網やインターネット等の通信ネットワークを介して配布してもよい。
【００９７】
また、上記実施形態の通信端末装置１０から送信された画像ファイル及び送信画像管理情報を受信した他の通信端末装置等は、通信端末装置１０と同等の機能を備えている必要はない。即ち、受信した送信画像管理情報に基づいて、受信した画像ファイルを再生できる機能を少なくとも備えていればよい。また、通信端末装置１０は、画像ファイルの送信の際、動画再生処理用のプログラムも併せて、宛先の通信端末装置等に送信する仕様にしてもよい。
【符号の説明】
【００９８】
１０…通信端末装置、１０１…操作部、１０２…制御部、１０３…撮像部、１０４…記憶部、１０５…画像容量監視部、１０６…通信部、１０７…表示部、１０８…音声処理部、１０９…多重／分離部、１１０…外部メモリドライバ部、１１１…外部メモリＩ／Ｆ部、１１２…外部メモリ、１１３…音声入出力端子、２０１…容量制限テーブル、２０２…画像管理テーブル
【図１】
2011160234.tif 000003
【図２】
2011160234.tif 000004
【図３】
2011160234.tif 000005
【図４】
2011160234.tif 000006
【図５】
2011160234.tif 000007
【図６】
2011160234.tif 000008
【図７】
2011160234.tif 000009
【図８】
2011160234.tif 000010
【図９】
2011160234.tif 000011
【図１０】
2011160234.tif 000012
【図１１】
2011160234.tif 000013
【図１２】
2011160234.tif 000014
【図１３】
2011160234.tif 000015
【図１４】
2011160234.tif 000016