JP4268969B2

JP4268969B2 - 無線通信網を介したメディアメッセージアップロード制御方法

Info

Publication number: JP4268969B2
Application number: JP2005518746A
Authority: JP
Inventors: ドンウォンナ; ホンソユン; サンモクソン; ウジョンヤン; サンギュウィ
Original assignee: SK Telecom Co Ltd
Current assignee: SK Telecom Co Ltd
Priority date: 2003-01-20
Filing date: 2004-01-20
Publication date: 2009-05-27
Anticipated expiration: 2024-01-20
Also published as: JP2006515733A; US20060129631A1; WO2004066650A1; TWI242958B; TW200420047A

Description

本発明は，無線通信網を介したメディアメッセージアップロード制御方法に係り，より詳細には，無線通信網を介したメディアデータのアップロードおよびアップロード再開のための通信端末機とサーバとの間で取りかわされるリクエスト（Request）および応答（Response）の数を減らす，無線通信網を介したメディアメッセージアップロード制御方法に関する。

一般に，移動体通信網およびインターネットに接続された無線通信システムでは，移動体通信端末間，または有線電話機と移動体通信端末との音声通話が提供されているとともに，ウェブ（または，ＷＡＰ（Wireless Application Protocol））接続にも適しているネットワーク上の特定サーバと移動体通信端末との間でメディアデータがアップロードまたはダウンロードされている。

また，かかる無線通信システムでは，ＨＴＴＰ１．１（ｒｆｃ２６１６）のプロトコルが，移動体通信端末からインターネット上のサーバにメディアデータをアップロードするために必要とされ，データのアップロードの処理では，リクエストメッセージおよび応答メッセージが，データアップロードの証明のために繰り返し発行される。

移動体通信端末が，無線ネットワーク上のサーバに特定メディアデータをアップロードする場合，移動体通信端末は，ＨＴＴＰ１．１のプロトコルに従ってメディアデータのセグメントをアップロードする度にリクエストメッセージを発生し，サーバでは，これら各リクエストメッセージに対応して応答メッセージを発生することによって，セグメントの連続的なアップロードが遂行される。

しかしながら，このような方法では，メディアデータのセグメントをアップロードする度にリクエストメッセージと応答メッセージとが発行される必要があり，データのアップロード処理中，リクエストメッセージと応答メッセージとが，移動体通信端末とサーバとの間で繰り返し取り交わされるため，データのアップロードが効率的に行われないという問題点があった。

しかも，移動体通信端末から特定サーバへメディアデータをアップロードする中に様々な要因によりアップロードエラーが発生すると，アップロードに失敗したデータをエラー発生地点からアップロードを再開するためには，サーバと移動体通信端末間に，既にアップロードされたデータの有効性検証のためのリクエストメッセージおよび応答メッセージが多く発生し，データアップロード速度および効率が低下する問題につながる。

また，このような無線通信網での移動体通信端末による特定サーバへのデータアップロードにおいては，移動体通信端末から特定サーバに所定のメディアデータをアップロードする途中に接続が解除され，以降そのメディアデータアップロードを再開しようとする場合に，データをどこから追加的にアップロードするかに関する情報がないため，最初からアップロードを始めなければならないという不便さがあった。

また，移動体通信端末から特定サーバへメディアデータをアップロードしている間にデータのアップロードエラーが発生すると，エラー発生地点からデータアップロードを再開することが好ましいにもかかわらず，既にアップロードされたデータと新しくアップロードすべきデータとの区別がし難いため，最初から再びアップロードを始めなければならないという問題点があった。

そこで，本発明は，上記問題に鑑みてなされたものであり，本発明の目的とするところは，メディアデータが，複数個のデータセグメント（または，シーケンス）単位で構成され，アップロードの効率が高まるように，予め定められた数のセグメントのグループ毎にアップロードのために１つのリクエストメッセージと１つの応答メッセージとが発行させる，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

また，本発明の他の目的は，アップロードされたセグメントのシーケンス番号を転送することにより，何らのデータ検証手続を行うことなく，エラーによりアップロードが中断されたメディアデータのアップロードをエラー発生地点から再開できるようにする，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

本発明のさらに他の目的は，通信端末機によりメディアデータのアップロードが取り消される場合，通信端末機とサーバとの間でリクエストメッセージおよび応答メッセージを交換することにより，メディアデータのアップロードを簡便に取り消すことを可能とする，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

本発明のさらに他の目的は，データのアップロードが中断され，後で再開される場合に，メッセージボディが容易に識別され得るようにメッセージボディ（Message Body）に固有の識別子を割り当てる，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

本発明のさらに他の目的は，アップロードエラーが発生した場合，アップロードが既に移動体端末に連続的に供給されたメッセージボディの範囲についてのパラメータを提供することによって，移動体端末が，追加的にアップロードされるメッセージボディの部分を把握しえる，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

本発明のさらに他の目的は，通信端末機とサーバとの間にて，リクエストメッセージおよび応答メッセージを繰り返し交換することなくメディアデータをアップロードすることができる，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

本発明のさらに他の目的は，メディアデータのアップロードがアップロードのエラーにより中断した場合，サーバから供給されるエラーコードに基づいてメディアデータのアップロードを再開することができる，無線通信網を介したメディアメッセージアップロード制御方法を提供することにある。

上記課題を解決するために，本発明によれば，通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，メディアデータのアップロード中にアップロードエラーが生じると，前記アプリケーションサーバがアップロードを再開させるための応答メッセージを通信端末機に転送する第３段階と，前記通信端末機が，アップロードされるセグメントからメディアデータのアップロードを再開する第４段階と，前記メディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを通信端末機に転送する第５段階と，らなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法が提供される。

さらに，上記課題を解決するために，本発明の別の観点によれば，通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，前記メディアデータアップロード中に通信端末機とアプリケーションサーバとの間の接続が切断されると，前記通信端末機が，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージを前記アプリケーションサーバに転送する第３段階と，前記アプリケーションサーバが，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージに応じて，応答メッセージを通信端末機に転送する第４段階と，前記通信端末機が，アップロードさせるセグメントからメディアデータのアップロードを再開する第５段階と，前記メディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第６段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法が提供される。

さらに，上記課題を解決するために，通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送し，前記アプリケーションサーバからの応答メッセージを受信すると，前記メディアデータのアップロードを始める第１段階と，メディアデータのアップロード中にアップロードのエラーが生じると，前記アプリケーションサーバが，応答メッセージを転送する第２段階と，前記通信端末機が，メディアデータのアップロードを再開するためのリクエストメッセージを転送する第３段階と，前記アプリケーションサーバが，前記アップロードを再開するためのリクエストメッセージに応じて，応答メッセージを通信端末機に転送する第４段階と，アプリケーションサーバからの応答メッセージを受信すると，前記通信端末機が前記メディアデータのアップロードを再開する第５段階と，前記再開されたメディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第６段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法が提供される。

通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送し，前記アプリケーションサーバからの応答メッセージを受信すると，メディアデータのアップロードを始める第１段階と，メディアデータのアップロード中に前記通信端末と前記アプリケーションサーバと間の接続が切断されると，前記通信端末機が，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージを前記アプリケーションサーバに転送する第２段階と，前記アプリケーションサーバが，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージに応じて，応答メッセージを前記通信端末機に転送する第３段階と，前記通信端末機が，前記アプリケーションサーバからの応答メッセージを受信すると，アップロードを再開するためのリクエストメッセージを前記アプリケーションサーバに転送する第４段階と，前記アプリケーションサーバが，前記リクエストメッセージに応じて，応答メッセージを前記通信端末機に転送する第５段階と，前記アプリケーションサーバからの応答メッセージを受信すると，前記通信端末機が，メディアデータのアップロードを始める第６段階と，前記再開されたメディアデータのアップロードが終了した後，前記アプリケーションサーバが，前記メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第７段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法が提供される。

以上説明したように，一実施形態によれば，通信端末機が，特定のメディアデータをアプリケーションサーバへアップロードする際，通信端末機は，アプリケーションサーバから応答メッセージを受信するまで，複数個のセグメントにメディアデータを構成することによりメディアデータをアップロードする。これに加えて，メディアデータのアップロードを再開する時には，通信端末機は，セグメントのシーケンス番号に基づいてアップロードを再開する。これにより，データアップロードの速度および効率が向上させることができる。

また，他の実施形態によれば，移動体通信端末が，アプリケーションサーバへメディアデータをアップロードする際，アップロードが中断され，後で再開される場合に，メッセージが容易に識別され得るように，メディアデータのメッセージボディに固有の識別子を割り当てる。また，アップロードにエラーが生じたとき，アプリケーションサーバにより連続的にアップロードされたメッセージボディの範囲についてのパラメータが供給される。これにより，移動体端末が，追加的にアップロードされるメッセージボディの部分を把握しえるという効果が得られる。

以下，添付の図面に基づき，本発明の好適な実施の形態について詳細に説明する。図１は，本発明の好適な実施形態である無線通信網システムの概略構成図である。

無線通信網システムは，移動体通信端末１０，移動体通信網２０，パケットデータサービングノード（Packet Data Serving Node；ＰＤＳＮ）３０，アプリケーションサーバ（MMS Server）４０から構成される。

移動体通信端末１０は，移動体通信網２０および無線インターネットを介してアプリケーションサーバ４０に接続し，ＨＴＴＰ１．１のプロトコルに基づいて，その端末機のメモリに格納された特定のメディアデータをアプリケーションサーバ４０にアップロードするための操作を遂行する。

特定メディアデータをアプリケーションサーバ４０に転送するために，移動体通信端末１０は，メディアデータの所定個数（例えば，Ｋ個）のセグメント（segment）グループのそれぞれに対して，アップロードリクエストメッセージを発行する。すなわち，移動体通信端末１０は，メディアデータのＫ個のセグメント（１セグメントはシーケンスともいう）をアップロードする度にサーバ４０にアップロードリクエストメッセージを転送する。サーバ４０にアップロードリクエストメッセージを転送した後，移動体通信端末１０は，メディアデータのＫ個のセグメントを転送し，アプリケーションサーバ４０からの応答メッセージを待つ。

また，移動体通信端末１０は，様々な通信問題のために，アップロードのプロセスの過程でアップロードエラーが生じると，アプリケーションサーバ４０からの応答メッセージに含まれたシーケンス番号を参照してアップロードの再開を試みる。

また，メディアデータがアップロードされている間に，特定のメディアデータアップロードがユーザにより強制的に中断されると，移動体通信端末１０は，アップロードをキャンセルするためのリクエストメッセージをアプリケーションサーバ４０に転送する。また，アップロードが，意図しない通信エラーにより中断すると，移動体通信端末１０は，内部タイマーを使用することにより前もって発行されたリクエストメッセージに対するアプリケーションサーバ４０からの応答メッセージを受信していない時間を計算することによって，自動的にメディアデータのアップロードを中断する。

移動体通信網２０は，移動体通信端末１０とその他の移動体通信端末または有線電話との間の音声通話を可能にする。移動体通信網２０はまた，移動体通信端末１０からのメディアデータがアプリケーションサーバ４０にアップロードされるようにする無線データ転送経路を設定する機能をもつ。

パケットデータサービングノード３０は，移動体通信網２０と無線インターネットとのインターフェースであり，移動体通信端末１０に／から送信されるパケットのルーティングおよびトンネリングを行い，移動体通信端末１０にＩＰアドレスを割り当てる。

アプリケーションサーバ４０は，移動体通信網２０および無線インターネットを介して移動体通信端末１０に接続し，移動体通信端末１０からＫ個のデータセグメントを受信する度に，ロードリクエストに応じて，移動体通信端末１０に１つの応答メッセージを発行する。

アップロード処理の間に意図しない通信エラーによってアップロードが中断すると，アプリケーションサーバ４０は，アップロードが再開するセグメントのシーケンス番号が含まれた応答メッセージを移動体通信端末１０に送信することによって，失敗したアップロードを正しく再開させる。

メディアデータがアップロードされている間に，ユーザによってアップロードの中断が強いられると，移動体通信端末１０は，アップロード取消リクエストメッセージを発行する。このリクエストに応じて，アプリケーションサーバ４０は，応答メッセージを移動体通信端末１０に転送する。

また，メディアデータがアップロードされている間に，通信エラーによりアップロードが中断され，アプリケーションサーバ４０が，予め定められた所定時間に移動体通信端末１０からいかなるメッセージも受信しない場合，アプリケーションサーバ４０は，アップロード操作が取り消されたと見なし，アップロードされていた一時ファイル（Temporary file）を削除する。

一方，特定のメディアデータをアップロードするとき，移動体通信端末１０は，図２に示すように，コマンド１００，ヘッダ１０２およびメッセージボディ１０４から構成される初期リクエストメッセージを発生する。コマンド１００には，たとえば，“POST/vod_mms HTTP/1.1”のようなＭＭＳ１．０の仕様書の情報と，ＨＴＴＰプロトコルのバージョン情報が含まれている。

ヘッダ１０２には，コンテンツタイプ情報“Contents-Type（例えば，application/vnd.skt.message）”と，メディアデータの総セグメント数“X-Total-Seq（例えば，１０）”，アップロードされたセグメントのシーケンス番号“X-Seq-No（例えば，１）”，アップロードされたメディアデータに割り当てられたメッセージＩＤ“X-Msg-id（例えば，端末機番号およびMIN_MMDDHHMMSS形式のアップロード時間情報）”，アプリケーションサーバ４０から受信した一の承認応答（Ack Response）に対するセグメントの数“X-Ack-Seq（例えば，３）”，バイト単位で与えられるメディアデータのセグメント長“Content-Length（例えば，５１２）”が含まれている。

ここで， “X-Total-Seq”，“X-Ack-Seq”，および“Content-Length”のフィールドは，最初のアップロードに際してのみアプリケーションサーバ４０に転送される。“X-Ack-Seq”フィールドは，アプリケーションサーバ４０による承認されるレセプションの基本単位であり，“Content-Length”フィールドは，バイト単位で表されたセグメント庁を示し，両者とも最初および最後のリクエストメッセージまたは各リクエストメッセージに含まれることができる。

図２において，メッセージボディ１０４には，ＭＭＳ１．０の仕様書のデータのうち，初めの５１２バイトが含まれる。

移動体通信端末１０は，スライディングウィンド（Sliding Window）の概念を用いてメディアデータをアップロードするが，セグメント毎のアップロードに対して必要とされるリクエストメッセージおよび応答メッセージを処理する時間を減らすために，移動体通信端末１０は，アプリケーションサーバ４０にアップロードリクエストメッセージを転送し，その後，アップロードのための承認メッセージを受信するまで特定数のデータセグメント（X-Ack-Seq）をアップロードする。特定数のデータセグメントを受信すると，アプリケーションサーバ４０は，移動体通信端末１０に承認メッセージを転送する。

すなわち，特定数のデータセグメント（X-Ack-Seq）を受信した後，アプリケーションサーバ４０は，図３に示すように，メッセージ（例えば，ＨＴＴＰ２００ＯＫ）および接続状態（例えば，Keep-Alive）が含まれたStatudライン（Statud Line）１１０を有する承認メッセージを移動体通信端末１０に転送する。

また，移動体通信端末１０からのメディアデータのアップロードが正常終了する場合に，アプリケーションサーバ４０は，図４に示すように，Statudライン，ヘッダ１２０およびメッセージボディ１２２を有する応答メッセージを発行する。Statudラインおよびヘッダ１２０には，メッセージ（例えば，HTTP 200 OK）と，接続状態フィールド（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache），コンテンツタイプフィールド（Content-Type：例えば，text/vnd.wap.mmsheaders），およびメッセージボディ１２２の長さであるコンテンツ長フィールド（Content-Length：例えば，１２３４）が含まれる。

また，メッセージボディ１２２には，メッセージのタイプフィールド（X-Mms-Message-Type：例えば，M-send-conf）と，アップロード結果報告フィールド（X-Mms-Response-Text：例えば，upload O.K.）とが含まれる。ここで，X-Mms-Response-Textフィールドは，移動体通信端末１０により初期化されたアップロードの最終結果を報告するためのもので，テキスト形式からなる。また，メッセージボディ１２２には，アプリケーションサーバ４０からの公開情報が含まれることもできる。

また，通信接続が保持されている状態でアップロードにエラーが生じると，アプリケーションサーバ４０は，図５に示すように，Statudライン１３０，ヘッダ１３２，およびメッセージボディ１３４を含む応答メッセージを生成する。

Statudライン１３０には，メッセージ（例えば，HTTP 600 Incorrect Sequence Number）が含まれ，ヘッダ１３２には，キャッシュ制御フィールド（Cache-Control：例えば，No-Cache）と接続状態フィールド（Connection：例えば，Keep-Alive）とが含まれ，メッセージボディ１３４には，アップロードを再開するセグメントのシーケンス番号（X-Start-Seq-No：例えば，１２３）が含まれる。

メディアデータのアップロード中に接続が切断された場合，移動体通信端末１０は，アップロードが再開されるべきセグメントのシーケンス番号を問い合わせるリクエストメッセージを発行する。図６に示すように，リクエストメッセージは，POST/vod_mms HTTP/1.1のような情報を含むコマンド１４０と，コンテンツタイプフィールド（Content-Type：例えば，application/vnd.skt.message）およびアップロードされるメディアデータに割り付けられたメッセージＩＤ（X-Msg-id：例えば，0114261166_0414232012のようなMIN_MMDDHHMMSS）を含むヘッダ１４２と，を有している。

シーケンス番号を問い合わせるリクエストメッセージを受信すると，アプリケーションサーバ４０は，その問い合わせに対する応答メッセージを発行する。図７に示すように，応答メッセージは，Statudライン１５０とヘッダ１５２とを有している。Statudライン１５０は，メッセージ（例えば，ＨＴＴＰ２００ＯＫ）を含んでいる。ヘッダ１５２は，接続状態フィールド（Connection：例えば，Keep-Alive），キャッシュ制御フィールド（Cache-Control：例えば，No-Cache），およびアップロードが再開されるべきセグメントのシーケンス番号（X-Start-Seq-No：例えば，１２３）を含んでいる。

メディアデータのアップロードが遂行されている間に，そのアップロードがユーザにより中断される場合，移動体通信端末１０は，アップロードの取消をアプリケーションサーバ４０に知らせるためのリクエストメッセージを発行する。図８に示すように，リクエストメッセージは，POST/vod_mms HTTP/1.1のような情報を含むコマンド１６０と，コンテンツタイプフィールド（Content-Type：例えば，application/vnd.skt.message），アップロードされるメディアデータに割り付けられたメッセージＩＤ（X-Msg-id：例えば，MIN_MMDDHHMMSS），およびメッセージ状態フィールド（X-Msg-Status：例えば，Cancel）を有している。

リクエストメッセージを受信すると，アプリケーションサーバ４０は，リクエストに対する応答メッセージを発行する。図９に示すように，応答メッセージは，メッセージ（例えば，HTTP 200 OK）を含むStatudライン１７０と，メッセージ（例えば，HTTP 200 OK），接続状態フィールド（Connection：例えば，Close），およびキャッシュ制御フィールド（Cache-Control：例えば，No-Cache）を含むヘッダ１７２と，を有している。

図１０〜図１４は，本発明の一実施形態にかかるフローチャートを示している。まず，図１０に示されたフローチャートを参照して，メディアデータの正常のアップロード過程について説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ１０）。図２に示すように，リクエストメッセージは，コマンド１００と，メディアデータの総セグメント数（X-Total-Seq），アップロードされるセグメントのシーケンス番号（X-Seq-No，例えば，１）およびメッセージＩＤを含むヘッダ１０２と，メッセージボディ１０４と，を有している。

続いて，移動体通信端末１０は，順に，リクエストメッセージに含まれたX-Ack-Seqフィールドにより特定される個数だけのメディアデータのセグメントをアップロードする（ステップＳ１２）。

このリクエストメッセージにて特定されたＫ個のセグメントを受信すると，アプリケーションサーバ４０は，図３に示すように，Statudライン１１０からなる応答メッセージを移動体通信端末１０に転送する（ステップＳ１４）。

このアプリケーションサーバ４０からの応答メッセージを受信すると，移動体通信端末１０は，メディアデータの次のＫ個のセグメントをアップロードするか否かを判断する（ステップＳ１６）。

次のＫ個のセグメントをアップロードする必要がある場合，メディアデータの全セグメントがアップロードされるまで，ステップＳ１２〜ステップＳ１６が繰り返される。

メディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図４に示すように接続状態，キャッシュ制御，コンテンツタイプ，コンテンツ長を含むStatudラインおよびヘッダ１２０と，データのメッセージタイプおよびテキスト形式のアップロード結果を含むメッセージボディ１２２と，からなる応答メッセージを，移動体通信端末１０に転送する（ステップＳ１８）。

次に，図１１のフローチャートを参照して，アップロードエラーにより中断しているメディアデータのアップロード再開過程について説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ２０）。図２に示すように，リクエストメッセージは，コマンド１００と，メディアデータの総セグメント数（X-Total-Seq），アップロードされるセグメントのシーケンス番号（X-Seq-No，例えば，１）およびメッセージＩＤを含むヘッダ１０２と，メッセージボディ１０４と，を有している。

続いて，移動体通信端末１０は，順に，リクエストメッセージに含まれたX-Ack-Seqフィールドにより特定される個数だけのメディアデータのセグメントをアップロードする（ステップＳ２２）。

通信接続が確立されている状態でアップロードのエラーが発生すると（ステップＳ２４），アプリケーションサーバ４０は，移動体通信端末１０に失敗したアップロードを再開させるために，図５に示したStatudライン１３０，ヘッダ１３２，およびアップロードが再開されるべきセグメントのシーケンス番号を含むメッセージボディ１３４を含む応答メッセージを発行する（ステップＳ２６）。

移動体通信端末１０は，中断されたアップロードを再開するか否かをユーザに問い合わせる（ステップＳ２８）。ユーザにより承認されると，移動体通信端末１０は，アプリケーションサーバ４０からの応答メッセージに含まれたシーケンス番号を参照してアップロードを再開する（ステップＳ３０）。

再開されたメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図４に示すように，接続状態，キャッシュ制御，コンテンツタイプ，コンテンツ長を含むStatudラインおよびヘッダ１２０と，データのメッセージタイプおよびテキスト形式のアップロード結果を含むメッセージボディ１２２とからなる応答メッセージを，移動体通信端末１０に転送する（ステップＳ３２）。

一方，ステップＳ２８で，データのアップロード再開がユーザにより認可されなかった場合，移動体通信端末１０は，メディアデータのアップロードを直ちに終了する（ステップＳ３４）。

次に，図１２のフローチャートを参照して通信接続が再確立された場合におけるメディアデータのアップロード再開過程について詳細に説明する。

移動体通信端末１０は，順に，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ１０）。図２に示すように，リクエストメッセージは，コマンド１００と，メディアデータの総セグメント数（X-Total-Seq），アップロードされるセグメントのシーケンス番号（X-Seq-No，例えば，１）およびメッセージＩＤを含むヘッダ１０２と，メッセージボディ１０４と，を有している（ステップＳ４０）。

続いて，移動体通信端末１０は，リクエストメッセージに含まれたX-Ack-Seqフィールドにより特定される個数だけのメディアデータのセグメントをアップロードする（ステップＳ４２）。

移動体通信端末１０とアプリケーションサーバ４０との通信接続が切断され，その結果，アップロードエラーが発生すると（ステップＳ４４），移動体通信端末１０は，アップロードが再開されるべきセグメントのシーケンス番号を問い合わせるリクエストメッセージを，アプリケーションサーバ４０に転送する（ステップＳ４６）。リクエストメッセージは，図６に示すように，コマンド１４０と，コンテンツタイプおよびデータのメッセージＩＤを含むヘッダ１４２を有している。

シーケンス番号を問い合わせるリクエストメッセージを受信すると，アプリケーションサーバ４０は，その問い合わせに対する応答メッセージを発生する（ステップＳ４８）。応答メッセージは，図７に示すように，Statudライン１５０，接続状態，キャッシュ制御およびアップロードが再開されるべきシーケンス番号を含むヘッダ１５２を有している。

移動体通信端末１０は，アプリケーションサーバ４０からの応答メッセージに含まれたシーケンス番号を参照してアップロードを再開する（ステップＳ５０）。

再開されたメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図４に示すように，接続状態，キャッシュ制御，コンテンツタイプ，コンテンツ長を含むStatudラインおよびヘッダ１２０と，データのメッセージタイプおよびテキスト形式のアップデート結果を含むメッセージボディ１２２とからなる応答メッセージを，移動体通信端末１０に転送する（ステップＳ５２）。

次に，図１３のフローチャートを参照してアップロードの強制終了時にアップロードされた一時ファイルを処理する過程について詳細に説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ６０）。図２に示すように，リクエストメッセージは，コマンド１００と，メディアデータの総セグメント数（X-Total-Seq），アップロードされるセグメントのシーケンス番号（X-Seq-No，例えば，１）およびメッセージＩＤを含むヘッダ１０２と，メッセージボディ１０４と，を有している。

続いて，移動体通信端末１０は，順に，リクエストメッセージに含まれたX-Ack-Seqフィールドにより特定される個数だけのメディアデータのセグメントをアップロードする（ステップＳ６２）。

このリクエストメッセージにて特定されたＫ個のセグメントを受信すると，アプリケーションサーバ４０は，図３に示すようにStatudライン１１０を含む応答メッセージを，移動体通信端末１０に転送する（ステップＳ６４）。

アップロードが，移動体通信端末１０のエラーにより中断され（ステップＳ６６），アプリケーションサーバ４０が，予め定められた所定時間に移動体通信端末１０からいかなるメッセージも受信しない場合，アプリケーションサーバ４０は，移動体通信端末１０がアップロードを取消したものと結論付け（ステップＳ６８），今まで受信した一時ファイルを削除する（ステップＳ７０）。このときに，アプリケーションサーバ４０では，応答メッセージを発行しない。

一方，移動体通信端末１０は，予め設定された所定時間にアプリケーションサーバ４０から応答メッセージを受信しないと，アップロードを自動的に取り消す（ステップＳ７２）。

次に，図１４のフローチャートを参照してアップロードの取消過程について詳細に説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ８０）。図２に示すように，リクエストメッセージは，コマンド１００と，メディアデータの総セグメント数（X-Total-Seq），アップロードされるセグメントのシーケンス番号（X-Seq-No，例えば，１）およびメッセージＩＤを含むヘッダ１０２と，メッセージボディ１０４と，を有している。

続いて，移動体通信端末１０は，順に，リクエストメッセージに含まれたX-Ack-Seqフィールドにより特定される個数だけのメディアデータのセグメントをアップロードする（ステップＳ８２）。

このリクエストメッセージにて特定されたＫ個のセグメントを受信すると，アプリケーションサーバ４０は，図３に示すように，Statudライン１１０からなる応答メッセージを，移動体通信端末１０に転送する（ステップＳ８４）。

メディアデータがアップロードされている間に，アップロードが移動体通信端末１０のユーザにより中断されると（ステップＳ８６），移動体通信端末１０は，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ８８）。リクエストメッセージは，図８に示すように，コマンド１６０と，コンテンツタイプ，メッセージＩＤおよびメッセージ状態が含まれたヘッダ１６２と，を有している。

このリクエストメッセージを受信すると，アプリケーションサーバ４０は，リクエストに対して，図９に示すように，Statudライン１７０と，接続状態およびキャッシュ制御を含むヘッダ１７２と，を有する応答メッセージを発行する（ステップＳ９０）。

次に，添付の図面を参照して，本発明の他の実施の形態について詳細に説明する。ただし，本実施の形態の説明において，図１に示す本発明の一実施の形態による無線通信網システムの構成要素と同一の構成要素には同一の参照符号を付すものとする。

移動体通信端末１０は，移動体通信網２０および無線インターネットを介してアプリケーションサーバ４０に接続し，ＨＴＴＰ１．１プロトコルのＰＯＳＴおよびＨＥＡＤ（または，ＧＥＴ）方式に基づいて，そのメモリに格納された特定メディアデータをアプリケーションサーバ４０にアップロードするとともに，中断または失敗したアップロードを再開する動作を行う。

特定のメディアデータをアップロードするためのリクエストメッセージを生成するとき，移動体通信端末１０は，メッセージのヘッダ（Header）に，メッセージボディの固有識別子を割り当て，これにより，メディアデータのアップロードが再開される場合，既にアップロードされた一部分のメッセージボディと，アップロードする残りのメッセージボディとをアプリケーションサーバ４０が一致確認できるようにする。

また，メディアデータのアップロード中に様々な通信問題によりアップロードエラーが発生すると，移動体通信端末１０は，アプリケーションサーバ４０に既にアップロードされたメディアデータ部分が存在するか否かを，メッセージボディの固有識別子を使用して検査し，可能な場合にはアップロードを再開する。

アプリケーションサーバ４０は，移動体通信網２０および無線インターネットを介して移動体通信端末１０に接続し，アップロードリクエストに対して，移動体通信端末１０に中断しているメディアデータのアップロード再開を許可する応答メッセージを発行する。

もし，データアップロード中に意図しない通信エラーによりデータアップロードが中断されるか，または，移動体通信端末１０がユーザにより取り消されたアップロードの再開を試みる場合，アプリケーションサーバ４０は，アップロードの失敗またはアップロード取消以前にうまくアップロードされているメッセージボディの範囲を含む応答メッセージを，移動体通信端末１０に転送し，中断されたデータアップロードが再開されるようにする。

特定のメディアデータをアップロードする場合，移動体通信端末１０は，図１５に示すように，コマンド２００，ヘッダ２０２およびメッセージボディ２０４を有するリクエストメッセージを発行する。コマンド２００には，POST/vod_mms HTTP/1.1のようなＭＭＳ１.０の仕様書の情報とＨＴＴＰプロトコルのバージョン情報とが含まれている。

ヘッダ２０２には，使用言語に関する情報（Accept-Language：例えば，en，ko）と，ユーザ・エージェント（User-Agent：例えば，SKT/XXX200），ホスト名（Host：例えば，‘vmms．ドメイン名’），バイト（byte）数で与えられるコンテンツ長（Content-Length：例えば，１５００），アップロードされるメッセージボディの識別子（X-Upload-Etag：例えば，端末機番号および0114261166_0414232012のようなMIN_MMDDHHMMSS形式のアップロード時間情報），コンテンツタイプ情報（Content-Type：例えば，multipart/mixed;boundary=Next_Part12Ab38cGH）が含まれている。

図１５において，メッセージボディ２０４は，ＭＭＳ１．０の仕様書のメッセージボディフォーマットにしたがって６４バイト以内に定義され，メッセージ内で固有（Unique）でなければならない。

また，ユーザにより中断されたメディアデータアップロードを再開するために，移動体通信端末１０は，アプリケーションサーバ４０に再び接続し，図１６に示すように，コマンド（例えば，GET/vod_mms HTTP/1.1）２１０とヘッダ２１２とを有するリクエストメッセージを発行する。ヘッダ２１２は，使用言語（Accept-Language：例えば，ko），ユーザ・エージェント（User-Agent：例えば，SKT/XXX200），ホスト名（Host：例えば，‘vmms.ドメイン名’），および既にアップロードされたメッセージボディ（Upload-ETag）部分が存在するか否かを判断するための情報（X-Upload-If-Match，例えば，端末機番号および0114261166_0414232012のようなMIN_MMDDHHMMSS形式のアップロード時間情報），を有している。

このリクエストメッセージを受信すると，アプリケーションサーバ４０は，前にアップロードされた部分が存在すると，追加的にアップロードされるべきメッセージボディの範囲を含む応答メッセージを発行し，前にアップロードされた部分が存在しないと，例えば‘503 Service Unavailable’のようなメッセージを含む応答メッセージを発行する。

移動体通信端末１０は，アプリケーションサーバ４０からの応答メッセージに応じてリクエストメッセージを発行する。図１７に示すように，リクエストメッセージは，コマンド２２０，ヘッダ２２２およびメッセージボディ２２４を有する。コマンド２２０には，POST/vod_mms HTTP/1.1のようなＭＭＳ１．０仕様書の情報，およびＨＴＴＰプロトコルのバージョン情報が含まれている。

ヘッダ２２２には，使用言語情報（Accept-Language：例えば，en，ko），ユーザ・エージェント情報（User-Agent：例えば，SKT/XXX200），ホスト名（Host，例えば，‘vmms.ドメイン名’），バイト（byte）数で与えられるコンテンツ長（Contents-Length：例えば，５００），アップロード操作の再開動作時にアップロードされるコンテンツ範囲（X-Upload-Content-Range：例えば，1001-1500/1500（ここで，1500は全データの大きさ），再アップロードされるメッセージボディの識別子（X-Upload-Etag：例えば，端末機番号および0114261166_0414232012のようなMIN_MMDDHHMMSS形式のアップロード時間情報），コンテンツタイプ情報（Content-Type，例えば，multipart/mixed;boundary=Next_Part12Ab38cGH）が含まれている。

また，メッセージボディ２２６には，ＭＭＳ１．０仕様書のメッセージボディフォーマットにしたがって追加的にアップロードされるデータが含まれる。

移動体通信端末１０からのメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図１８に示すように，Statudライン（Statud Line）２３０，メッセージヘッダ２３２およびメッセージボディ２３６を含む応答メッセージを発行する。

Statudライン２３０には，HTTP/1.1 OKのようなメッセージが含まれており，メッセージヘッダ２３２には，日付情報（Date，例えば，Sun,08 Apr 18:46:12 GMT），サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態情報（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御情報（Cache-Control：例えば，No-Cache），コンテンツタイプフィールド（Content-Type：例えば，text/vnd.wap.mmsheaders），メッセージボディＩＤ（X-Upload-Etag：例えば，端末機番号およびMIN_MMDDHHMMSS形式のアップロード時間情報），およびメッセージボディ長であるコンテンツ長フィールド（Content-Length：例えば，５０）が含まれる。

また，メッセージボディ２３６には，メッセージのタイプフィールド（X-Mms-Message-Type：例えば，M-send-conf）と，アップロード結果報告フィールド（X-Mms-Response-Text：例えば，upload O.K.）が含まれる。X-Mms-Response-Textフィールドは，移動体通信端末１０によるアップロードの最終結果を報告するためのもので，テキスト形式である。また，メッセージボディ２３６は，アプリケーションサーバ４０からの公開情報を含むこともできる。

メディアデータがアップロードされている間に，アプリケーションサーバ４０によりアップロードエラーが発生すると，アプリケーションサーバ４０は，図１９に示すように，Statudライン２４０，メッセージヘッダ２４２，およびメッセージボディ２４６を含む応答メッセージを発行する。

Statudライン２４０には，メッセージ（例えば，HTTP/1.1 500 Internal Server Error）が含まれ，メッセージヘッダ２４２には，日付情報（Date：例えば，Sun,08 Apr 18:46:12 GMT）と，サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態フィールド（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache）が含まれる。

一方，メディアデータがアップロードされている間に，移動体通信端末１０によりデータのアップロードエラーが生じた場合，アプリケーションサーバ４０は，図２０に示すように，Statudライン２５０，メッセージヘッダ２５２およびメッセージボディ２５６を含む応答メッセージを発行する。

Statudライン２５０には，メッセージ（例えば，HTTP/1.1 400 Bad Request）が含まれ，メッセージヘッダ２５２には，日付情報（Date：例えば，Sun,08 Apr 18:46:12 GMT），サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態フィールド（Connection：例えば，Close），およびアップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache）が含まれる。

どこからアップロードが再開されるべきかを問い合わせるリクエストメッセージを受信すると，アプリケーションサーバ４０は，既にメディアデータの一部がアップロードされている場合には，図２１に示すように，Statudライン２６０，メッセージヘッダ２６２およびメッセージボディ２６６を含む応答メッセージを発生する。

Statudライン２６０にはメッセージ（例えば，HTTP/1.1[SP]200[SP]OK[CRLF]）が含まれ，メッセージヘッダ２６２には，日付情報（Date：例えば，Sun,08 Apr 18:46:12 GMT），サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態フィールド（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache），コンテンツタイプフィールド（Content-Type：例えば，text/vnd.wap.mmsheaders），メッセージボディＩＤ（X-Upload-ETag：例えば，MIN_MMDDHHMMSS），およびアップロードエラー以前にうまくアップロードされたコンテンツの範囲（X-Upload-Range：例えば，1-1000/1500）が含まれる。

一方，どこからアップロードが再開されるべきか問い合わせるリクエストメッセージを受信すると，アプリケーションサーバ４０は，メディアデータの既にアップロードされた部分がサーバに存在しない場合，図２２に示すように，Statudライン２７０，メッセージヘッダ２７２およびメッセージボディ２７６を含む応答メッセージを発行する。

Statudライン２７０には，メッセージ（例えば，HTTP/1.1 503 Service Unavailable）が含まれ，メッセージヘッダ２７２には，日付情報（Date：例えば，Sun,08 Apr 18:46:12 GMT），サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態フィールド（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache），コンテンツタイプフィールド（Content-Type：例えば，text/vnd.wap.mmsheaders），メッセージボディＩＤ（X-Upload-ETag：例えば，MIN_MMDDHHMMSS），アップロードエラー以前にアップロードに成功したコンテンツの範囲（X-Upload-Range：例えば，1-1000/1500）が含まれる。

一方，移動体通信端末１０から再開されたメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図２３に示すように，Statudライン２８０，メッセージヘッダ２８２およびメッセージボディ２８６を含む応答メッセージを発行する。

Statudライン２８０には，メッセージ（例えば，HTTP/1.1 206 Partial Content）が含まれ，メッセージヘッダ２８２には，日付情報（Date：例えば，Sun,08 Apr 18:46:12 GMT），サーバ情報（Server：例えば，video MMSC（Unix(登録商標））），接続状態フィールド（Connection：例えば，Close），アップロードされるデータの一時ファイルの制御状態を表すキャッシュ制御フィールド（Cache-Control：例えば，No-Cache），コンテンツタイプフィールド（Content-Type：例えば，text/vnd.wap.mmsheaders），メッセージボディＩＤ（X-Upload-ETag：例えば，MIN_MMDDHHMMSS），およびメッセージボディ長であるコンテンツ長フィールド（Content-Length：例えば，５０）が含まれる。

また，メッセージボディ２８６には，メッセージタイプフィールド（X-Mms-Message-Type：例えば，M-send-conf）およびアップロードされた結果報告フィールド（X-Mms-Response-Text：例えば，upload O.K.）が含まれる。X-Mms-Response-Texフィールドは，移動体通信端末１０によるアップロードの最終結果を報告するためのもので，テキスト形式である。また，メッセージボディ２８６は，アプリケーションサーバ４０からの公開情報を含むこともできる。

本発明の他の実施の形態による動作について，図２４および図２５のフローチャートを参照して説明する。まず，図２４のフローチャートを参照して，アップロードエラーにより中断されたメディアデータのアップロードを再開する過程について説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ１００）。図１５に示すように，リクエストメッセージは，コマンド２００と，ヘッダ２０２，メッセージボディ２０４と，を有している。

このリクエストメッセージを受信すると，アプリケーションサーバ４０は，応答メッセージを移動体通信端末１０に転送し（ステップＳ１０２），この応答メッセージを受信すると，移動体通信端末１０は，メディアデータのメッセージボディ２０４のアップロードを始める（ステップＳ１０４）。

移動体通信端末１０とアプリケーションサーバ４０は，メディアデータアップロード中に，メッセージボディの識別子を含むリクエストメッセージとそれに対する応答メッセージを繰り返し交換する。

この状態で，移動体通信端末１０またはアプリケーションサーバ４０により生じたエラーのためにメディアデータのアップロードが失敗すると（ステップＳ１０６），アプリケーションサーバ４０は，図１９に示すようにStatudライン２４０と，接続状態およびキャッシュ制御の情報を含むメッセージヘッダ２４２と，メッセージボディ２４６とを有する応答メッセージを，移動体通信端末１０に転送する（ステップＳ１０８）。

その後，移動体通信端末１０は，図１７に示すように，追加的にアップロードすべきコンテンツ長，追加的にアップロードすべきコンテンツの範囲，メッセージボディ識別子，およびコンテンツタイプを含むリクエストメッセージを，アプリケーションサーバ４０に転送する（ステップＳ１１０）。

移動体通信端末１０からリクエストメッセージを受信すると，アプリケーションサーバ４０は，図２１に示すように，メッセージボディ識別子と既にアップロードされたデータの範囲とを含む応答メッセージを，移動体通信端末１０に転送する（ステップＳ１１２）。

移動体通信端末１０が，アプリケーションサーバ４０からの応答メッセージを受信すると，追加的にアップロードされる必要があるメディアデータの部分のアップロードが始まる（ステップＳ１１４）。

このように再開されたメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図２３に示すように，Statudライン２８０，メッセージヘッダ２８２，およびアップロード結果報告が含まれたメッセージボディ２８６を有する応答メッセージを，移動体通信端末１０に転送する（ステップＳ１１６）。

次に，図２５のフローチャートを参照して，切断された接続により中断されたメディアデータのアップロードを再開する過程について説明する。

移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０（または，無線インターネット）を介してアプリケーションサーバ４０に接続した状態で，特定のメディアデータをアップロードするために，リクエストメッセージをアプリケーションサーバ４０に転送する（ステップＳ１２０）。図１５に示すように，リクエストメッセージは，コマンド２００と，ヘッダ２０２，メッセージボディ２０４と，を有している。ヘッダ２０２は，メッセージボディ２０４の固有識別子を含んでいる。

このリクエストメッセージを受信すると，アプリケーションサーバ４０は，応答メッセージを移動体通信端末１０に転送し（ステップＳ１２２），この応答メッセージを受信すると，移動体通信端末１０は，メディアデータのメッセージボディ２０４のアップロードを始める（ステップＳ１２４）。

移動体通信端末１０とアプリケーションサーバ４０は，メディアデータアップロード中に，メッセージボディの固有識別子を含むリクエストメッセージとそれに対する応答メッセージを繰り返し交換する。

移動体通信端末１０のユーザが，移動体通信端末１０とアプリケーションサーバ４０との接続を切断し（ステップＳ１２６），その後，移動体通信端末１０とアプリケーションサーバ４０との接続が再確立される（ステップＳ１２８）。

メディアデータの不完全なアップロードを再開するために，移動体通信端末１０は，どこからアップロードを再開すべきかを問い合わせるリクエストメッセージを発行する。図１６に示すように，リクエストメッセージは，既にアップロードされたメッセージボディ部分がアプリケーションサーバ４０に存在するか否かを問い合わせるための情報を含んでいる（ステップＳ１３０）。

このリクエストメッセージを移動体通信端末１０から受信すると，アプリケーションサーバ４０は，図２１または図２２に示すように，Statudライン，既にアップロードされたデータの範囲を含むメッセージヘッダ，およびメッセージボディを有する応答メッセージを発行する（ステップＳ１３２）。

この応答メッセージを受信すると，移動体通信端末１０は，それから，図１７に示すように，コマンド２２０と，追加的にアップロードされるコンテンツ長および追加的にアップロードされるコンテンツ範囲を含むヘッダ２２２とを有し，取り消されたアップデートを再開するためのリクエストメッセージをアプリケーションサーバ４０に転送する。

移動体通信端末１０がアプリケーションサーバ４０からの応答メッセージを受信すると，追加的にアップロードを必要とするメディアデータの部分のアップロードが始まる（ステップＳ１３４）。

再開されたメディアデータのアップロードが正常終了すると，アプリケーションサーバ４０は，図２３に示すように，Statudライン２８０，メッセージヘッダ２８２，およびアップロード結果報告が含まれたメッセージボディ２８６を有する応答メッセージを，移動体通信端末１０に転送する（ステップＳ１３６）。

次に，添付の図面を参照して，本発明のさらに他の実施の形態について説明する。なお，図１に示す本発明の一実施の形態による無線通信網システムの構成要素と同一の構成要素には同一の参照符号を付すものとする。

ＴＣＰプロトコルを使用した無線データ通信では，マルチメディアデータを転送するアプリケーション層は，データ転送の安全性を保障するために，パケット化したデータの送受信時ごとにデータ検証を行う必要がない。

本発明のさらに他の実施の形態ではＴＣＰプロトコルを採用し，したがって，移動体通信端末は，所定個数のセグメントがアップロードされる度にアプリケーションサーバからの応答メッセージを受信することなくメディアデータのみをアプリケーションサーバにアップロードする。

移動体通信端末とアプリケーションサーバとは，１つのリクエストメッセージおよび１つの応答メッセージのみを交換することにより，移動体通信端末とアプリケーションサーバとの間のトラフィックを効果的に減少させることができる。

アップロードにエラーが生じた場合には，アプリケーションサーバは，あらかじめ定められたエラーコードを移動体通信端末に転送し，このエラーコードを受信すると，移動体通信端末は，あらかじめ定められた方式でデータアップロードを再開する。

すなわち，移動体通信端末１０は，移動体通信網２０およびＰＤＳＮ３０を介してアプリケーションサーバ４０に接続され，アプリケーションサーバ４０からの応答メッセージを受信することなく，内部メモリに格納された特定メディアデータを，持続的にアップロードする。

メディアデータのアップロード中にたとえ予期されたアップロードエラーが生じても，移動体通信端末１０は，アプリケーションサーバ４０へデータのアップロードを続ける。

また，移動体通信端末１０が，アプリケーションサーバ４０から予め定義されたエラーコードを受信した場合，移動体通信端末１０は，予め定められた方式（例えば，全データのアップロードまたは特定位置からデータのアップロード）でデータのアップロードを再実行する。

アプリケーションサーバ４０は，移動体通信網２０およびＰＤＳＮ３０を介して移動体通信端末１０に接続され，応答メッセージを発行することなく，移動体通信端末１０から送信されたメディアデータを受信し続ける。

データアップロード中にアップロードエラーが生じると，アプリケーションサーバ４０は，移動体通信端末１０は，予め定められた方式でデータアップロードを再び試みることができるように，予め定義されたエラーコードを移動体通信端末１０に転送する。

以上に説明した本発明は，前述した実施の形態および添付の図面により限定されるものでなく，本発明の技術的思想を逸脱しない範囲内で様々な置換，変形および変更が可能であることは，本発明の属する技術分野で通常の知識を持つ者にとっては明らかであるだろう。

本発明の好ましい一実施の形態である無線通信網システムの概略構成図である。本発明の好ましい一実施の形態によってメディアデータアップロードのための初期リクエストメッセージの構成を示す図である。本発明の好ましい一実施の形態によって特定数のセグメントを受信した後アプリケーションサーバにより発行された応答メッセージの構成を示す図である。本発明の好ましい一実施の形態によってメディアアップロードが正常終了したときに発行される応答メッセージの構成を示す図である。本発明の好ましい一実施の形態によって接続が確立された状態でアップロードにエラーが生じた場合に発行される応答メッセージの構成を示す図である。本発明の好ましい一実施の形態によって接続が制限された場合に追加にアップロードされるべきセグメントのシーケンス番号を問い合わせるリクエストメッセージの構成を示す図である。本発明の好ましい一実施の形態によってシーケンス番号の問い合わせに対する応答メッセージの構成を示す図である。本発明の好ましい一実施の形態によってアップロードの取消による転送失敗を知らせるためのリクエストメッセージの構成を示す図である。本発明の好ましい一実施の形態によってアップロード取消に対する応答メッセージの構成を示す図である。本発明の一実施の形態によるメディアデータの正常アップロード過程を説明するフローチャートである。本発明の一実施の形態によるアップロードエラー発生時に中断していたメディアデータのアップロードを再開する過程を説明するフローチャートである。本発明の一実施の形態による通信接続が再確立された時にメディアデータのアップロードを再開する過程を説明するフローチャートである。本発明の一実施の形態によるアップロードの強制終了時に，アップロードされた一時ファイルを処理する過程を説明するフローチャートである。本発明の一実施の形態によるメディアデータのアップロード取消過程を説明するフローチャートである。本発明の好ましい他の実施の形態によってメディアデータをアップロードするためのリクエストメッセージの構成を示す図である。本発明の好ましい他の実施の形態によって通信接続が再確立されるとき，アップロード再開が可能かどうかを問い合わせるリクエストメッセージの構成を示す図である。本発明の好ましい他の実施の形態によってメディアデータのアップロード再開に対するリクエストメッセージの構成を示す図である。本発明の好ましい他の実施の形態によってデータのアップロード終了のための応答メッセージの構成を示す図である。本発明の好ましい他の実施の形態によってサーバエラーが発生した場合の応答メッセージの構成を示す図である。本発明の好ましい他の実施の形態によって移動体通信端末によりエラーが発生した場合の応答メッセージの構成を示す図である。本発明の好ましい他の実施の形態によって既にアップロードされたデータ部分がサーバに存在し，データのアップロードを再開する場合に発行される応答メッセージの構成を示す図である。本発明の好ましい他の実施の形態によって既にアップロードされたデータ部分がサーバに存在せず，データのアップロードを再開すべき場合に発行される応答メッセージの構成を示す図である。本発明の好ましい他の実施の形態によって再開されたアップロードがうまく終了した時に発行される応答メッセージの構成を示す図である。本発明の他の実施の形態によるアップロードエラーにより中断されたアップロードを再開する過程を説明するフローチャートである。本発明の他の実施の形態によるユーザにより中断されたメディアデータのアップロードを再開する過程を説明するフローチャートである。

Claims

通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，
前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，
メディアデータのアップロード中にアップロードエラーが生じると，前記アプリケーションサーバがアップロードを再開させるための応答メッセージを通信端末機に転送する第３段階と，
前記通信端末機が，アップロードされるセグメントからメディアデータのアップロードを再開する第４段階と，
前記メディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを通信端末機に転送する第５段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
前記第１段階で，前記通信端末機により送信されたリクエストメッセージは，アップロードされるメディアデータの総セグメント数，アップロードされるセグメントのシーケンス番号，メディアデータのメッセージＩＤ，前記アプリケーションサーバから承認応答を受けるセグメント数，およびアップロードされるセグメントのバイト数の情報を含むことを特徴とする請求項１に記載された方法。
前記第１段階で，前記リクエストメッセージに含まれたメディアデータのメッセージＩＤは，通信端末機に固有の識別子および転送時間に対応することを特徴とする請求項２に記載された方法。
前記第１段階で，前記アップロードされるメディアデータの総セグメント数および前記アップロードされるセグメントのシーケンス番号は，最初のリクエストメッセージにのみ含まれ，アップロードされるセグメントのバイト数は，最初および最後のリクエストメッセージにのみ含まれることを特徴とする請求項２に記載された方法。
前記第３段階で，前記アプリケーションサーバからの応答メッセージは，アップロードが再開されるセグメントのシーケンス番号の情報を含むことを特徴とする請求項２に記載された方法。
通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，
前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，
前記メディアデータアップロード中に通信端末機とアプリケーションサーバとの間の接続が切断されると，前記通信端末機が，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージを前記アプリケーションサーバに転送する第３段階と，
前記アプリケーションサーバが，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージに応じて，応答メッセージを通信端末機に転送する第４段階と，
前記通信端末機が，アップロードさせるセグメントからメディアデータのアップロードを再開する第５段階と，
前記メディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第６段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
前記第１段階で，前記通信端末機により送信されたリクエストメッセージは，アップロードされるメディアデータの総セグメント数と，アップロードされるセグメントのシーケンス番号，メディアデータのメッセージＩＤ，前記アプリケーションサーバから承認応答を受けるセグメント数，およびアップロードされるセグメントのバイト数の情報を含むことを特徴とする請求項６に記載された方法。
前記第１段階で，前記リクエストメッセージに含まれたメディアデータのメッセージＩＤは，通信端末機に固有の識別子および転送時間に対応することを特徴とする請求項７に記載された方法。
前記第１段階で，前記アップロードされるメディアデータの総セグメント数および前記アップロードされるセグメントのシーケンス番号は，最初のリクエストメッセージにのみ含まれ，アップロードされるセグメントのバイト数は，最初および最後のリクエストメッセージにのみ含まれることを特徴とする請求項７に記載された方法。
前記第３段階で，前記通信端末機により前記アップロードをどこから再開するかを問い合わせるリクエストメッセージには，再アップロードされるメディアデータのメッセージＩＤが含まれることを特徴とする請求項７に記載された方法。
前記第４段階で，前記アプリケーションサーバからの応答メッセージには，アップロードが再開されるセグメントのシーケンス番号の情報が含まれることを特徴とする請求項１０に記載された方法。
通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，
前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，
前記メディアデータのアップロード中にアップロードが取り消されると，通信端末機が，前記メディアデータのアップロード取消のためのリクエストメッセージを転送する第３段階と，
前記アップロード取消のためのリクエストメッセージを受信すると，前記アプリケーションサーバが，応答メッセージを転送する第４段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
前記第３段階で，前記メディアデータのアップロード取消のためのリクエストメッセージには，アップロードが取り消されるメディアデータのメッセージＩＤおよびメディアデータのメッセージ状態が含まれることを特徴とする請求項１２に記載された方法。
通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送する第１段階と，
前記通信端末機が，アプリケーションサーバからの応答メッセージを受信するまでメディアデータを複数個のセグメントに区分してアップロードする第２段階と，
前記アプリケーションサーバが，前記通信端末機からのメッセージを受信しない継続した時間を計算する第３段階と，
前記継続時間が制限を越えると，前記アプリケーションサーバが前記メディアデータのアップロードの取消と見なし，アップロードされたデータの一時ファイルを削除する第４段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送し，前記アプリケーションサーバからの応答メッセージを受信すると，前記メディアデータのアップロードを始める第１段階と，
メディアデータのアップロード中にアップロードのエラーが生じると，前記アプリケーションサーバが，応答メッセージを転送する第２段階と，
前記通信端末機が，メディアデータのアップロードを再開するためのリクエストメッセージを転送する第３段階と，
前記アプリケーションサーバが，前記アップロードを再開するためのリクエストメッセージに応じて，応答メッセージを通信端末機に転送する第４段階と，
アプリケーションサーバからの応答メッセージを受信すると，前記通信端末機が前記メディアデータのアップロードを再開する第５段階と，
前記再開されたメディアデータのアップロードが終了すると，前記アプリケーションサーバが，メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第６段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
前記第１段階で，前記通信端末機により送信されるリクエストメッセージは，メディアデータのコンテンツ，メディアデータのメッセージボディの固有識別子，およびコンテンツタイプの情報を含むことを特徴とする請求項１５に記載された方法。
前記第１段階で，前記リクエストメッセージに含まれる固有識別子は，前記通信端末機の固有識別子および転送時間に該当することを特徴とする請求項１６に記載された方法。
第３段階で，前記メディアデータのアップロードを再開するためのリクエストメッセージは，追加的にアップロードされるメディアデータのコンテンツ長と，追加的にアップロードされるデータの範囲，およびアップロードが再開されるメディアデータのメッセージボディの固有識別子を含むことを特徴とする請求項１６に記載された方法。
前記第６段階で，前記メディアデータの再開されたアップロードについての応答メッセージは，前記メディアデータのメッセージボディの固有識別子，およびアップロード結果報告に関するテキスト情報を含むことを特徴とする請求項１６に記載された方法。
通信端末機が，無線通信網を通じてアプリケーションサーバにメディアデータのアップロードのためのリクエストメッセージを転送し，前記アプリケーションサーバからの応答メッセージを受信すると，メディアデータのアップロードを始める第１段階と，
メディアデータのアップロード中に前記通信端末機と前記アプリケーションサーバと間の接続が切断されると，前記通信端末機が，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージを前記アプリケーションサーバに転送する第２段階と，
前記アプリケーションサーバが，前記アップロードをどこから再開するかを問い合わせるリクエストメッセージに応じて，応答メッセージを前記通信端末機に転送する第３段階と，
前記通信端末機が，前記アプリケーションサーバからの応答メッセージを受信すると，アップロードを再開するためのリクエストメッセージを前記アプリケーションサーバに転送する第４段階と，
前記アプリケーションサーバが，前記リクエストメッセージに応じて，応答メッセージを前記通信端末機に転送する第５段階と，
前記アプリケーションサーバからの応答メッセージを受信すると，前記通信端末機が，メディアデータのアップロードを始める第６段階と，
前記再開されたメディアデータのアップロードが終了した後，前記アプリケーションサーバが，前記メディアデータのアップロードの正常終了を示す応答メッセージを前記通信端末機に転送する第７段階と，からなることを特徴とする，無線通信網を介したメディアメッセージアップロード制御方法。
前記第１段階で，前記通信端末機により送信されるリクエストメッセージは，メディアデータのコンテンツ，メディアデータのメッセージボディの固有識別子およびコンテンツタイプの情報を含むことを特徴とする請求項２０に記載された方法。
前記第１段階で，前記リクエストメッセージに含まれる固有識別子は，前記通信端末機の固有識別子および転送時間に該当することを特徴とする請求項２１に記載された方法。
前記第２段階で，前記アップロードをどこから再開するかを問い合わせるためのリクエストメッセージは，前もってアップロードされたメッセージボディの部分が，前記アプリケーションサーバに存在するか否かを確認するためのヘッダフィールドデータマッチ情報を含むことを特徴とする請求項２１に記載された方法。
前記第３段階で，前記アップロードをどこから再開するかを問い合わせるためのリクエストメッセージに対する応答メッセージは，アップロードが再開されたメディアデータのメッセージボディの固有識別子，および既にアップロードされているデータの範囲の情報を含むことを特徴とする請求項２３に記載された方法。
前記第４段階で，前記メディアデータのアップロードを再開するためのリクエストメッセージは，追加的にアップロードされるメディアデータのコンテンツ長と，追加的にアップロードされるデータの範囲，およびアップロードが再開されるメディアデータのメッセージボディの固有識別子を含むことを特徴とする請求項２４に記載された方法。
前記第７段階で，前記メディアデータの再開されたアップロードについての応答メッセージは，前記メディアデータのメッセージボディの固有識別子，およびアップロード結果報告に関するテキスト情報を含むことを特徴とする請求項２１に記載された方法。