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