JP2002342205A - 画像通信端末 - Google Patents

Abstract

(57)【要約】 【課題】 画像ファイルをサーバに転送する際に、転送
先URLを記録したサムネイル画像ファイルを生成して装
置内に残しておくことにより、装置内で転送済みファイ
ルの存在を確認することができる画像通信端末を提供す
る。 【解決手段】 所望の画像ファイルを、ネットワーク上
に存在するサーバに転送して保存する画像通信端末であ
って、前記画像ファイルのサムネイル画像データを生成
して保持する手段４，６と、前記ネットワークとの接続
を確立し、前記画像ファイルを任意のサーバに転送する
手段９と、前記画像ファイルの保存場所情報を、前記画
像ファイルのサムネイル画像データに関連付けて保存す
る手段１，１５とを備えたものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、インターネットな
どのネットワーク上のサーバとの通信を行うことが可能
な画像通信端末に関し、特に、画像ファイルをサーバに
転送して保存したり、サーバから受信して再送すること
が可能な画像通信端末に関するものである。

【０００２】

【従来の技術】従来の撮影機能を有する画像通信端末に
おいては、撮影枚数が多くなり、内蔵メモリや外部メモ
リに保存される画像ファイルの数が多くなると、必然的
に各メモリの保存可能容量は少なくなり、いずれは新た
なファイルを生成する容量が無くなってしまう。

【０００３】従って、メモリ内のファイルを消去する
か、外部メモリを交換するか、メモリ内のファイルを装
置以外のメモリに移動する、等の措置を取る必要がある
が、外部メモリを交換するためには複数の外部メモリを
保有しなければならず、また大容量のものは価格的にも
高価である。

【０００４】そこで、例えば特開2001-69384号公報に
は、記録媒体の記憶容量が所定量となると、記録してい
る画像ファイルを自動的に予め加入しているコンピュー
タネットワークのサーバ等に転送させることにより、た
とえ記録媒体の容量が小さく、またスペアの記録媒体を
携帯していない場合であっても、撮影動作を継続して実
行することが可能な電子カメラが提案されている。

【０００５】従来のこの種の撮影機能を有する画像通信
端末について、図７乃至図９とともに説明する。ここ
で、図７は従来の撮影機能を有する画像通信端末を示す
機能ブロック図、図８は従来の撮影機能を有する画像通
信端末における動画像データのヘッダ解析処理を示すフ
ローチャート、図９は従来の撮影機能を有する画像通信
端末における静止画像データのヘッダ解析処理を示すフ
ローチャートである。

【０００６】図７において、画像撮影部１２にて撮影さ
れた画像データは、一度作業メモリ領域４に格納され、
圧縮伸張部６にて圧縮される。圧縮されたデータは、再
度作業メモリ領域４に格納される。ヘッダ処理部５で
は、圧縮されたデータに、撮影条件などを基に、解像度
情報や圧縮情報をヘッダ情報として付加し、作業メモリ
領域４に格納する。

【０００７】ファイルシステム１は、あらかじめユーザ
ーによって設定されているメモリ設定に応じて、内蔵メ
モリ２、もしくは外部メモリ３にファイルとして保存す
る。外部メモリ３は脱着可能であるので、ユーザーの手
により他の撮影装置にて撮影、又はＰＣなどからコピー
して画像を保存しておくこともできる。

【０００８】これら内蔵メモリ２、もしくは外部メモリ
３に保存されているファイルを一覧表示する場合、個々
のファイルのサムネイル画像を表示する。ここで、静止
画ファイルの場合は、そのメイン画像をサムネイル表示
したもの、動画像ファイルの場合は、その先頭フレーム
の画像をサムネイル表示したものが、サムネイル画像で
ある。

【０００９】まず、動画像のサムネイル画像の生成につ
いて説明する。サムネイル表示するファイルに対し、フ
ァイルシステム１は、内蔵メモリ２又は外部メモリ３に
保存されている画像ファイルの先頭フレーム分のデータ
を作業メモリ領域４に格納する。作業メモリ４に格納さ
れたデータは、ヘッダ処理部５に送られる。

【００１０】ここで、図８を参照して、ヘッダ処理部５
での動画像データのヘッダ解析を説明する。作業メモリ
４より送られたデータは、動画像フォーマットであるAS
F形式か否かを判断される。ASF形式ではなかった場合
は、異常ファイルと判断される。

【００１１】ASF形式であった場合、解像度情報、エン
コード方式情報などが取り出される。圧縮伸張部６は、
ヘッダ処理部５から得られた解像度情報、エンコード方
式情報を元に、デコード、及びサムネイル表示用に縮小
され、表示メモリ領域７に格納される。

【００１２】次に、静止画のサムネイル画像の生成につ
いて説明する。静止画のサムネイル表示を行う場合、サ
ムネイル表示するファイルに対し、ファイルシステム１
は、内蔵メモリ２又は外部メモリ３に保存されている画
像ファイルのヘッダ分のデータを作業メモリ領域４に格
納する。作業メモリ４に格納されたデータは、ヘッダ処
理部５に送られる。

【００１３】ここで、図９を参照して、ヘッダ処理部５
での静止画像データのヘッダ解析を説明する。作業メモ
リ４より送られたデータは、静止画像フォーマットであ
るJPEG形式か否かを判断される。JPEG形式ではなかった
場合は、異常ファイルと判断される。

【００１４】JPEG形式であった場合、更にEXIF形式か否
かを判断される。EXIF形式である場合は、サムネイル画
像データを保有しているため、解像度情報や画像フォー
マット情報を取り出した後、ファイルシステム１は、そ
のサムネイル画像データを作業メモリ領域４に格納す
る。

【００１５】EXIF形式ではない場合には、サムネイル画
像データが無いため、サムネイル画像は表示できない。
EXIF形式のサムネイルデータを使わず、メイン画像デー
タからサムネイル画像を生成する場合には、ファイルシ
ステム１は全画像データを作業メモリ領域４に格納す
る。

【００１６】EXIF形式か否かによって作業メモリ４に格
納されたそれぞれのデータはヘッダ処理部５により、解
像度情報や画像フォーマット情報などが取り出された
後、圧縮伸張部６によってデコード、及びサムネイル表
示用に縮小され、表示メモリ領域７に格納される。

【００１７】さらに、撮影した画像ファイルをインター
ネット上のサーバに転送する場合について説明する。ユ
ーザーによって選択されたファイルデータは、ファイル
システム１により内蔵メモリ２、もしくは外部メモリ３
より作業メモリ領域４に格納される。また、ユーザーは
ユーザーIF部８より、接続先のサーバ名、ディレクトリ
名、ユーザーID、パスワード等の情報を入力する。

【００１８】通信部９は入力されたURLを受け、あらか
じめ設定されたネットワーク接続用ID、パスワード、接
続先などの情報を用いて、ネットワークに接続し、指定
されたURL（Universal Resource Location）に対して接
続作業を行い、接続を確立した後ファイル転送を行う。
転送が完了したら、通信部９はユーザーIF部８を経由し
て、ユーザーにその旨を通知する。

【００１９】このように、従来の撮影機能を有する画像
通信端末においては、内蔵メモリ２、もしくは外部メモ
リ３に保存されている各画像ファイルに対応するサムネ
イル画像を生成し保持してはいるが、画像ファイルをサ
ーバに転送する際に、特に何らかのデータを残すことも
無く、オリジナルのファイルデータを転送するだけであ
った。

【００２０】一方、従来の画像通信端末において、ネッ
トワーク上のサーバに保存されたファイルを再生する場
合、以下のような各種方法を用いたものが知られてい
る。

【００２１】(１)HTTPを利用したWeb Browse機能を用い
て転送する方法。これは、Web Browserを通して表示さ
れた、該当ファイルへのリンクを選択することで、HTTP
を利用してファイルを転送する方法である。

【００２２】(２)FTPを利用したファイル転送機能を用
いて転送する方法。これは、FTPを利用して該当ファイ
ルの有るサーバにLog inし、該当ファイルを転送する方
法である。

【００２３】(３)SMTP及びPOPを利用したインターネッ
トメール機能を用いて転送する方法。これは、インター
ネットメールにファイルを添付することで、ファイルを
転送する方法である。添付されたメールを受信すること
で、結果的に転送できることになる。

【００２４】

【発明が解決しようとする課題】しかしながら、上述し
た従来の撮影機能付き画像通信端末においては、画像フ
ァイルをサーバに転送した場合、転送後に該転送ファイ
ルを消去してしまうと、装置内にそれらのファイルがあ
った形跡は無くなってしまうため、それらのファイルが
どこにあるのか、もしくはあったかどうかすらわからな
くなってしまう、という問題が生じる。

【００２５】また、上述した従来のファイル転送方法に
おいては、以下のような問題点が存在する。

【００２６】(１)HTTPを利用したWeb Browse機能を用い
て転送する方法では、転送したいファイルがどのサーバ
のどのディレクトリにあるかという情報（path情報）が
無いと、すぐには転送ができず、該当ファイルへのリン
クを辿ったりする必要がある。

【００２７】また、該当ファイル自身の内容はWeb Brow
serでは視覚的に確認できないため、ファイル名のみで
しか区別がつかない。内容を視覚的にわかるようにする
ためには、HTML記述されたファイルをWeb Browserで見
なければならないし、そのHTMLファイルも作成しなくて
はならない。

【００２８】例えば、www.sharp.co.jpというサーバのs
harpディレクトリにある、picn0001.jpgというファイル
の内容を確認するためには、HTMLファイル中に<img src
= "http://www.sharp.co.jp/sharp/picn0001.jpg"> と
いう記述をする必要がある。仮にファイルが100枚あっ
たら、上記のような記述を100行する必要がある。

【００２９】(２)次に、FTPを利用したファイル転送機
能を用いて転送する方法では、ファイルのあるサーバが
匿名でのログインを許可した匿名FTP（anonymous FTP）
を許可しているかどうかが問題となる。通常のFTPでは
アカウントと、それに対応するパスワードを入力する必
要があるため、アカウントを取得していないユーザーは
FTPでの転送ができない。

【００３０】匿名FTPが許可されている場合は、限られ
た範囲ではあるが、公開されたディレクトリ内のファイ
ルは自由に転送できる。しかしながら、いずれにしても
HTTP時と同様path情報が無いと、すぐには転送ができな
い。また、FTP接続では、該当ファイル自身の内容は視
覚的に確認できないため、ファイル名のみでしか区別を
つけることができない。

【００３１】(３)さらに、SMTP及びPOPを利用したイン
ターネットメール機能を用いて転送する方法では、イン
ターネットメールを受信するという形をとらざるを得な
く、しかもその受信メールにファイルを添付しておく必
要がある。このため、ユーザーの意図するファイルを自
由に転送するのは、不可能に近い。

【００３２】以上より、HTTPを利用する場合は、非常に
わずらわしい準備作業を行った後、画像の内容を確認し
ながら欲しい画像を転送することができるが、FTP、及
びインターネットメールを利用した場合も含め、従来の
方法においては、手軽に画像の内容を確認しながら欲し
い画像を転送することは非常に困難であった。

【００３３】本発明は、上記課題に鑑みてなされたもの
であり、画像ファイルをサーバに転送する際に、転送先
URLを記録したサムネイル画像ファイルを生成して装置
内に残しておくことにより、装置内で転送済みファイル
の存在を確認することができる画像通信端末を提供する
ものである。

【００３４】また、画像ファイルの保存場所情報があら
かじめ埋め込まれているサムネイル静止画像を用いて、
その保存場所情報を認識することにより、必要に応じて
サーバに保存されている画像データをダウンロード或い
はストリーミングを行い再生することができる画像通信
端末を提供するものである。

【００３５】

【課題を解決するための手段】本願の第１の発明は、所
望の画像ファイルを、ネットワーク上に存在するサーバ
に転送して保存する画像通信端末であって、前記画像フ
ァイルのサムネイル画像データを生成して保持する手段
と、前記ネットワークとの接続を確立し、前記画像ファ
イルを任意のサーバに転送する手段と、前記画像ファイ
ルの保存場所情報を、前記画像ファイルのサムネイル画
像データに関連付けて保存する手段とを備えたことを特
徴とする。

【００３６】本願の第２の発明は、前記保存場所情報
が、前記サムネイル画像データのヘッダ部分に記述され
ることを特徴とする。

【００３７】本願の第３の発明は、ネットワーク上に存
在するサーバから、所望の画像ファイルを受信して再生
する画像通信端末であって、前記画像ファイルのサムネ
イル画像データに関連付けて保存された前記画像ファイ
ルの保存場所情報を認識する手段と、前記認識された保
存場所情報に基づいて、前記ネットワークとの接続を確
立し、前記サーバから前記画像ファイルを受信する手段
とを備えたことを特徴とする。

【００３８】本願の第４の発明は、前記サムネイル画像
データに関連付けて保存された前記画像ファイルの保存
場所情報の有無をユーザに通知する手段を備えたことを
特徴とする。

【００３９】本願の第５の発明は、前記保存場所情報に
基づいて、前記ネットワークとの接続を確立させるか否
かを、ユーザに確認するための手段を備えたことを特徴
とする。

【００４０】本願の第６の発明は、前記保存場所情報に
基づいて、前記画像ファイルのサーバからのダウンロー
ドなのか、ストリーミングなのかを判断する手段を備え
たことを特徴とする。

【００４１】

【発明の実施の形態】以下、本発明の画像通信端末の第
１実施形態について、図１及び図２とともに詳細に説明
するが、上記従来例と同一部分には同一符号を付し、そ
の説明は省略する。ここで、図１は本実施形態における
概略構成を示す機能プロック図、図２は本実施形態によ
るサムネイル画像ファイルの構成を示す説明図である。

【００４２】図１において、ユーザーは、ユーザーIF部
８を通じて、サムネイル一覧画面などからサーバに転送
したい画像ファイルを選択する。ユーザーにより選択さ
れたファイルデータは、ファイルシステム１によって内
蔵メモリ２、もしくは外部メモリ３より作業メモリ領域
４に格納される。

【００４３】この際、動画像なら先頭フレームのデー
タ、静止画像なら画像データ分を作業メモリ領域４に格
納する。作業メモリ領域４に格納されたデータは圧縮伸
張部６にてJPEG圧縮され、圧縮されたデータは再度作業
メモリ領域４に格納される。

【００４４】次に、ユーザーは、ユーザーIF部８より、
接続先のサーバ名、ディレクトリ名、ユーザーID、パス
ワード等の情報を入力する。通信部９は、入力されたUR
L（Universal Resource Location）を受け、あらかじめ
設定されていたネットワーク接続用ID、パスワード、接
続先などの情報を用いて、ネットワークに接続し、指定
されたURLに対して接続作業を行い、接続を確立した後
ファイル転送を行う。

【００４５】尚、URLとは、情報の種類、情報を記憶し
ている機器のネットワーク上のロケーション、機器内部
で情報が存在するロケーションの３つを組み合わせた記
法で定義されるものであり、このURLによりネットワー
ク内部の情報のロケーションを一意に指定することがで
きる。

【００４６】転送が完了したら、通信部９はユーザーIF
部８を経由して、保存場所情報として転送先URLをヘッ
ダ処理部１５に伝える。ヘッダ処理部１５では、受け取
った転送先URLをJPEGマーカーのCOM部に埋め込み、作業
メモリ領域４に格納されている圧縮データと結合する。

【００４７】結合されたデータは、ファイルシステム１
によってファイル化され、予めユーザによって設定され
ているメモリ設定に応じて、内蔵メモリ２、若しくは外
部メモリ３に保存される。

【００４８】ここで、図２を参照して、転送先URLのJPE
GマーカーのCOM部への埋め込みについて説明する。図２
に示すように、JPEGファイルは、SOI部２０、COM部２
１、DQT部２２、SOF部２３、DHT部２４、DRI部２５、SO
S部２６、EOI部２７などのJPEGマーカーと呼ばれる識別
子で始まる各ブロックから構成される。ただし、これら
のマーカー部は全て必須項目ではなく、画像中に存在し
なくても構わないマーカー部も有る。

【００４９】COM部２１はコメントマーカー部とも呼ば
れ、コメントを記録できるブロックであり、使用はユー
ザーに任せられている。COM部２１のフォーマットは、
以下のとおりである。

【００５０】ブロックの先頭2バイトがマーカーコード
を示す。ここには、コメントマーカーをあらわすFFFEが
入る。次の2バイトはマーカー部のサイズを示す。次の
バイト以降に書かれるコメントと、サイズ表示領域分の
2バイトを足した量を示している。次のバイト（先頭か
ら5バイト目）以降にコメントが書かれる。

【００５１】本実施形態では、ヘッダ処理部１５に送ら
れた転送先URLを、このCOM部２１に記述する。例えば、
www.sharp.co.jpというサーバのsharpディレクトリにmo
vn001.asfというファイルをHTTP（Hyper Text Transfer
Protocol）を用いて転送した際には、COM部２１には、
先頭２バイトにFFFE、次の２バイトに002A、5バイト目
以降にhttp://www.sharp.co.jp/sharp/movn001.asfと記
述する。

【００５２】以上のように、本実施形態の画像通信端末
においては、ファイル転送後に装置内から該当ファイル
が移動、もしくは消去されて、装置内に存在しない場合
でも、サムネイル画像ファイルが残るため、あたかもオ
リジナルの画像が有るように見せかけることができ、さ
らに該当ファイルの転送保存先も認識することが可能と
なる。

【００５３】また、転送先URLが埋め込まれたサムネイ
ル画像を用いることにより、装置の内蔵メモリ２もしく
は外部メモリ３の容量を節約することができ、より多く
の画像を撮影することが可能となる。さらに、知人など
の第三者にファイルを渡したい場合も、サムネイル画像
を渡すだけで済むため、データの授受が手軽にできるよ
うになる。

【００５４】尚、上記実施形態では、画像ファイルの保
存場所情報（転送先URL）を、JPEG圧縮したサムネイル
画像データのヘッダに記録して保存したものについて説
明したが、本発明はこれに限らず、サムネイル画像デー
タに関連付けて画像ファイル本体の保存場所情報を保存
しておけば良いことは明らかでである。

【００５５】次に、本発明の画像通信端末の第２実施形
態について、図３乃至図６とともに説明するが、上記従
来例と同一部分には同一符号を付し、その説明は省略す
る。

【００５６】ここで、図３は本実施形態の画像通信端末
の概略構成を示す機能ブロック図、図４は本実施形態に
おける動画像ファイル用のヘッダ解析処理を示すフロー
チャート、図５は本実施形態における静止画像ファイル
用のヘッダ解析処理を示すフローチャート、図６は本実
施形態を用いたシステムの一例を示す説明図である。

【００５７】図３において、図７とともに上述した従来
例と異なるのは、通知手段１０、確認手段１１が追加さ
れた点と、ヘッダ処理部２５内での処理方法がヘッダ処
理部５のそれとは異なる点である。

【００５８】まず、動画像のサムネイル表示を行う場
合、ファイルシステム１は、内蔵メモリ２又は外部メモ
リ３に保存されている画像ファイルの先頭フレーム分の
データを作業メモリ領域４に格納する。作業メモリ４に
格納されたデータは、ヘッダ処理部２５に送られる。

【００５９】ここで、図４を参照して、ヘッダ処理部２
５での動画像データのヘッダ解析を説明する。作業メモ
リ４より送られたデータは、動画像フォーマットである
ASF形式か否かを判断される。ASF形式であった場合、通
常の動画像であるので、解像度情報、エンコード方式情
報などを取り出される。

【００６０】ASF形式ではなかった場合は、サムネイル
静止画像である可能性があるので、静止画像フォーマッ
トであるJPEG形式か否かを判断される。JPEG形式ではな
かった場合は、異常ファイルと判断される。

【００６１】JPEG形式であった場合、更にCOMマーカー
があるか否かを判断される。これは、URL情報がCOMマー
カー部内に書かれているためである。COMマーカーが存
在しない場合は、異常ファイルと判断される。

【００６２】COMマーカーが存在した場合、コメントを
取り出し、URL情報か否かを判断する。URL情報ではない
場合は、異常ファイルと判断される。URL情報であった
場合、URLが埋め込まれたサムネイル静止画像と判断さ
れる。

【００６３】こうして、通常の動画像だった場合は、解
像度情報やエンコード方式情報を取り出して、圧縮伸張
部６に渡される。圧縮伸張部６では、受け取った情報を
基にデコード、及びサムネイル表示用に縮小され、表示
メモリ領域７に格納される。

【００６４】URLが埋め込まれたサムネイル静止画像だ
った場合は、JPEG形式のデータが格納されているので、
ファイルシステム１により、全画像データを作業メモリ
領域４に格納し、ヘッダ処理部２５でURL情報と解像度
情報や画像フォーマット情報を取り出した後、圧縮伸張
部６によってデコード及び、サムネイル表示用に縮小さ
れ、表示メモリ領域７に格納される。

【００６５】URLが埋め込まれたサムネイル静止画像だ
った場合のヘッダ解析は、図５の静止画像に対する解析
と同様になる。

【００６６】また、静止画のサムネイル表示を行う場
合、ファイルシステム１は、内蔵メモリ２又は外部メモ
リ３に保存されている画像ファイルのヘッダ分のデータ
を作業メモリ領域４に格納する。作業メモリ４に格納さ
れたデータは、ヘッダ処理部２５に送られる。

【００６７】ここで、図５を参照して、ヘッダ処理部２
５での静止画像データのヘッダ解析を説明する。作業メ
モリ４より送られたデータは、静止画像フォーマットで
あるJPEG形式か否かを判断される。JPEG形式ではなかっ
た場合は、異常ファイルと判断される。

【００６８】JPEG形式であった場合、更にEXIF形式か否
かを判断される。EXIF形式である場合は、サムネイル画
像データを保有しているため、サムネイル画像データの
解像度情報や画像フォーマット情報を取り出し、EXIF形
式ではない場合には、メイン画像データの解像度情報や
画像フォーマット情報を取り出す。

【００６９】これらの情報を取り出した後、COMマーカ
ーがあるか否かを判断される。これは、URL情報はCOMマ
ーカー部内に書かれているためである。COMマーカーが
存在しない場合は、通常の静止画像ファイルと判断され
る。

【００７０】COMマーカーが存在する場合、コメントを
取り出し、URL情報か否かを判断する。URL情報ではない
場合は、通常の静止画像ファイルと判断される。URL情
報であった場合、URLが埋め込まれたサムネイル静止画
像と判断される。

【００７１】埋め込まれたURLがストリーミングデータ
なのか、ダウンロードデータなのかは、次のように判断
する。尚、静止画像は常にダウンロードデータであるの
で、ストリーミングデータは動画像のみが対象とされ
る。

【００７２】抽出されたURLに記述されている対象ファ
イルは、ヘッダ処理部２５にて、拡張子により静止画像
か動画像か判断される。この拡張子が.asxであった場合
は、ストリーミングデータと判断される。ASXファイル
は、ASFファイルをストリーミング再生するための記述
ファイルである。

【００７３】圧縮伸張部６では、こうしてヘッダ解析で
得られた情報を基にデコード、及びサムネイル表示用に
縮小され、表示メモリ領域７に格納される。

【００７４】これ以降は、静止画像、動画像ともに共通
の処理となる。ヘッダ処理部２５により、URLが抽出さ
れた場合、ユーザーIF（インターフェイス）部８はユー
ザーに対し、該当画像はサムネイル画像情報のみで、画
像ファイル本体はサーバーに保存されている旨の通知
を、通知手段１０を通じて行う。

【００７５】この通知は、例えばサムネイル画像にアイ
コンを表示する、或いはメッセージを表示する、或いは
LEDの点灯・点滅などで示す、或いはBeep音を鳴らす、
などの手段を用いて実現することができる。

【００７６】次に、サムネイル画像の一覧表示の状態か
らメイン画像を再生する際に、URLが埋め込まれたファ
イルをユーザーが選択した場合について説明する。

【００７７】画像選択手段（図示せず）によって選択さ
れたファイルは、一覧表示時にヘッダ処理部２５にてUR
Lが埋め込まれているか否かが分かるので、URLが埋め込
まれたサムネイル画像が選択された場合には、ユーザー
IF部８は通知手段１０を通じて、ユーザに対してネット
ワーク上のサーバーとの通信を行うことを通知する。

【００７８】通知手段１０により通知を受けたユーザー
は、確認手段１１を通じて通信を開始するか否かを入力
する。確認手段１１を通じてユーザーから了解が得られ
た場合には、通信部９はヘッダ処理部２５にて抽出され
たURLに対して通信を開始する。

【００７９】この時、抽出されたURLがストリーミング
であった場合には、ASXファイルに記述されているASFフ
ァイルをストリーミング再生する必要があるため、一度
対象のASXファイルをダウンロードする。ASXファイルは
次のように記述されている。

【００８０】例えば、www.sharp.co.jpというサーバのs
harpディレクトリにある、movn004.asfというファイル
をストリーミング再生させるためのASXファイルは、 ＜ＡＳＸversion = "3.0＞ ＜Entry＞ ＜Ref href = " HYPERLINK "http://www.sharp.co.jp/s
harp/movn004.asf" http://www.sharp.co.jp/sharp/mov
n004.asf"/＞ ＜/Entry＞ ＜/ＡＳＸ＞ と記述されている。

【００８１】ヘッダ処理部２５は、上記の記述からASF
ファイルの存在を示すURL、 HYPERLINK "http://www.sh
arp.co.jp/sharp/movn004.asf" http://www.sharp.co.j
p/sharp/movn004.asfを抽出し、通信部９を通じて通信
を行う。ストリーミング再生は、データを転送しなが
ら、再生を行わなくてはいけないため、転送データを作
業メモリ領域４に一時格納する。ある程度のデータ量が
転送されたら、ヘッダ処理部２５にて解像度情報やエン
コード方式情報を取り出し、圧縮伸張部６に渡して、デ
コードを行う。

【００８２】デコードされたデータは、表示メモリ領域
７に渡され、再生が行われる。ただし、これらの動作中
も転送データは随時、作業メモリ領域４に格納されてい
る。

【００８３】また、抽出されたURLがダウンロードであ
った場合は、ファイルデータを全て転送し、ファイルシ
ステム１によりファイル化する。この時、サムネイル表
示用静止画ファイルが装置内に残っていると、該当サム
ネイル表示用静止画ファイルを再度再生選択した場合
に、もう一度ダウンロードしてしまうことが考えられ
る。これは、通信費用の無駄遣いになってしまう上に、
装置内に全く同じファイルが複数存在することになり、
メディアの容量の無駄遣いになってしまう。

【００８４】これを防ぐために、ダウンロードが成功し
た際には、該当サムネイル表示用静止画ファイルを消去
する、或いは該当サムネイル表示用静止画ファイル内の
コメント欄を書き替える、或いは装置内のファイル管理
テーブルでダウンロードしたことを記録しておき、通知
手段１０を通じて既にダウンロード済みであることをユ
ーザーに通知する、などの多重ダウンロード防止策を施
す必要があり、かつ、防止策の実行の有無はユーザーが
任意に選択できるようにしておくと、より使い勝手を向
上させることができる。

【００８５】次に、当該装置とサーバとの通信の流れ
を、図６を用いて説明する。画像通信端末３０にて、選
択された画像にURLが埋め込まれていた場合、表示部に
メッセージ３４を表示する。確認手段１１よりユーザー
からの通信要求があった場合、通信部９を通じて、イン
ターネット３１に接続しているサーバ３２、３３と通信
を行う。

【００８６】メッセージ３４にあるように、該当ファイ
ルはwww.sharp.co.jp HYPERLINK http://www.sharp.co.
jp に有り、HTTPを用いて通信を行うことになる。通信
部９はサーバ３２（www.sharp.co.jp）に対し、ファイ
ル転送要求を出し、サーバ３２はその要求を受けて応答
し、picturesディレクトリのimg#0001.jpgを画像通信端
末３０に対して転送する。

【００８７】通信部９を通じてサーバ３２から受け取っ
たデータは、作業メモリ領域４に格納された後、ファイ
ルシステム１によって内蔵メモリ２もしくは外部メモリ
３に保存される。尚、埋め込まれていたURLが、ftp://f
tp.sharp.co.jp/pictures/img#0002.jpg だった場合
は、通信部９はサーバ３３（ftp.sharp.co.jp）に対しF
TPを用いて通信を行うことになる。

【００８８】以上のように、本実施形態の画像通信端末
においては、ネットワーク上に存在するサーバに保存さ
れたファイルに対し、あたかも当該装置内にファイルが
有るように見せかけることができ、必要に応じてデータ
転送することで、非常に手軽にファイルの転送ができる
ようになる。

【００８９】このような、URLが埋め込まれたサムネイ
ル静止画像を友人などの他者に渡すことで、ファイルデ
ータ全てを渡す必要がなくなり、手軽にデータの受け渡
しができるようになる。また、電子カタログとしても利
用することが可能であり、ユーザーが興味を持った商品
についての詳細なデータを、煩わしい手間をかけること
なく、簡単に手許にダウンロードすることが可能とな
る。

【００９０】尚、上記実施形態では、画像ファイルの保
存場所情報（転送先URL）が、JPEG圧縮したサムネイル
画像データのヘッダに記録して保存されたものについて
説明したが、本発明はこれに限らず、サムネイル画像デ
ータに関連付けて画像ファイル本体の保存場所情報を保
存してあれば良いことは明らかでである。

【００９１】また、上記第１及び第２実施形態では、画
像撮影機能を有する画像通信端末について説明したが、
本発明はこれに限らず、画像撮影機能を持たない、単に
所望の画像ファイルをサーバに転送して保存することが
可能な端末、或いは、サーバに保存されている画像ファ
イルを受信して再生することが可能な端末であっても良
いことは言うまでもない。

【００９２】

【発明の効果】本発明の画像通信端末によれば、画像フ
ァイルをサーバに転送した後、装置内から該当ファイル
が移動、もしくは消去されて、装置内に存在しない場合
でも、サムネイル画像データを残すため、あたかもオリ
ジナルの画像が有るように見せかけることができ、さら
にそのファイル転送先も認識することが可能となる。

【００９３】また、保存場所情報が埋め込まれたサムネ
イル画像データを用いることで、装置の内蔵メモリもし
くは外部メモリの容量を節約することができ、より多く
の画像を撮影することが可能となる。さらに、知人など
の第三者にファイルを渡したい場合も、サムネイル画像
を渡すだけですむため、データの授受が手軽に出来るよ
うになる。

【００９４】本発明の画像通信端末によれば、ネットワ
ーク上に存在するサーバに保存されたファイルに対し、
サムネイル画像を用いて、必要に応じデータ転送を指示
することが可能であり、非常に手軽にファイルの転送が
できるようになる。

【００９５】また、保存先URLが埋め込まれたサムネイ
ル画像データを友人などの他者に渡すことで、ファイル
データ全てを渡す必要がなくなり、手軽にデータの受け
渡しができるようになる。さらに、電子カタログとして
も利用することが可能であり、ユーザーが興味を持った
商品についての詳細なデータを、煩わしい手間をかける
ことなく、簡単に手許にダウンロードすることができる
ようになる。

【図面の簡単な説明】

【図１】本発明の画像通信端末の第１実施形態における
概略構成を示す機能プロック図である。

【図２】本発明の画像通信端末の第１実施形態によるサ
ムネイル画像ファイルの構成を示す説明図である。

【図３】本発明の画像通信端末の第２実施形態における
概略構成を示す機能プロック図である。

【図４】本発明の画像通信端末の第２実施形態における
動画像ファイル用のヘッダ解析処理を示すフローチャー
トである。

【図５】本発明の画像通信端末の第２実施形態における
静止画像ファイル用のヘッダ解析処理を示すフローチャ
ートである。

【図６】本発明の画像通信端末の第２実施形態を用いた
システムの一例を示す説明図である。

【図７】従来の画像通信端末の概略構成を示す機能プロ
ック図である。

【図８】従来の画像通信端末における動画像ファイル用
のヘッダ解析処理を示すフローチャートである。

【図９】従来の画像通信端末における静止画像ファイル
用のヘッダ解析処理を示すフローチャートである。

【符号の説明】 １ ファイルシステム部 ２ 内蔵メモリ ３ 外部メモリ ４ 作業メモリ領域 ６ 圧縮伸張部 ７ 表示メモリ領域 ８ ユーザーIF部 ９ 通信部 １０ 通知手段 １１ 確認手段 １２ 画像撮影部 １５、２５ ヘッダ処理部 ２０ SOI部 ２１ COM部 ２２ DQT部 ２３ SOF部 ２４ DHT部 ２５ DRI部 ２６ SOS部 ２７ EOI部 ３０ 画像通信端末 ３１ インターネット ３２ サーバ（www.sharp.co.jp） ３３ サーバ（ftp.sharp.co.jp） ３４ 画像通信端末の表示部のメッセージ例

Claims (6)

【特許請求の範囲】
1. 【請求項１】 所望の画像ファイルを、ネットワーク上
   に存在するサーバに転送して保存する画像通信端末であ
   って、 前記画像ファイルのサムネイル画像データを生成して保
   持する手段と、 前記ネットワークとの接続を確立し、前記画像ファイル
   を任意のサーバに転送する手段と、 前記画像ファイルの保存場所情報を、前記画像ファイル
   のサムネイル画像データに関連付けて保存する手段とを
   備えたことを特徴とする画像通信端末。
2. 【請求項２】 前記請求項１に記載の画像通信端末にお
   いて、 前記保存場所情報は、前記サムネイル画像データのヘッ
   ダ部分に記述されることを特徴とする画像通信端末。
3. 【請求項３】 ネットワーク上に存在するサーバから、
   所望の画像ファイルを受信して再生する画像通信端末で
   あって、 前記画像ファイルのサムネイル画像データに関連付けて
   保存された前記画像ファイルの保存場所情報を認識する
   手段と、 前記認識された保存場所情報に基づいて、前記ネットワ
   ークとの接続を確立し、前記サーバから前記画像ファイ
   ルを受信する手段とを備えたことを特徴とする画像通信
   端末。
4. 【請求項４】 前記請求項３に記載の画像通信端末にお
   いて、 前記サムネイル画像データに関連付けて保存された前記
   画像ファイルの保存場所情報の有無をユーザに通知する
   手段を備えたことを特徴とする画像通信端末。
5. 【請求項５】 前記請求項３又は４に記載の画像通信端
   末において、 前記保存場所情報に基づいて、前記ネットワークとの接
   続を確立させるか否かを、ユーザに確認するための手段
   を備えたことを特徴とする画像通信端末。
6. 【請求項６】 前記請求項３乃至５のいずれかに記載の
   画像通信端末において、 前記保存場所情報に基づいて、前記画像ファイルのサー
   バからのダウンロードなのか、ストリーミングなのかを
   判断する手段を備えたことを特徴とする画像通信端末。