WO2000044136A1

WO2000044136A1 - Mobile terminal and data transmission system

Info

Publication number: WO2000044136A1
Application number: PCT/JP2000/000206
Authority: WO
Inventors: Yoshifumi Yonemoto; Hiromi Wada; Takako Hirose; Atsunobu Kato; Masaharu Nakatsuchi; Koji Chiba
Original assignee: Matsushita Electric Industrial Co., Ltd.; Matsushita Communication Industrial Co., Ltd.; Ntt Mobile Communication Network, Inc.
Priority date: 1999-01-19
Filing date: 2000-01-18
Publication date: 2000-07-27
Also published as: JP3323144B2; EP1061701A1; CN100505701C; JP2000209261A; CN1293851A; EP1061701A4; EP1061701B1

Description

明細移動端末およびデータ伝送方式技術分野

本発明は、移動端末およびデータ伝送方式に関し、特にサーバからデ一夕保存メモリが少ないクライアント（移動端末）へ P U S H型メッセージを配送し得るように構成したものである。背景技術

今日の高度情報化社会における情報通信では、インターネットを介して、ユーザがアクセス先のアドレスを指定することにより、いろいろな情報を即時に取得することが可能となってきた。

クライアントとサーバ間のデータ転送プロトコルとして、 HTTP(Hypertext Tra nsfer Protocol) が広く普及している。

HTTPは、クライアントからの取得要求に対してサーバが応答して、クライアントから要求された情報を通知することにより、ユーザは情報を取得することがでぎる。

また、近年、クライアントから要求の起動をかける P U L L型のサービスだけでなく、情報送信元が任意のタイミングで、クライアントに情報を提供する P U S H型のサービスが見られるようになつてきた。

これにより、クライアントから情報送信要求の起動をかけなくとも、予め取り決めた情報提供元から、提供される情報が発生した時点で即時に情報が提供される o

例えば、特開平 9- 148994号公報に開示されている「データ放送システム及びその端末装置」では、放送データチャンネルを利用して、各種のデジタル信号を送信しており、放送データを受信する受信装置では、リアルタイムに情報を入手することが可能となっている。

しかしながら、携帯電話などのデ一夕保存メモリが比較的少ない携帯端末においては、情報提供元から提供される情報を保存しきれないといった問題が生じる。特に有料のサービス情報や、電子メールなどの重要な情報である場合には、この取りこぼしが問題となる。

上記の課題に鑑み本発明は、デ一夕保存メモリが少ない携帯端末において、情報提供元から提供されるリアルタイムの情報を、確実に受信できる移動端末およびデータ伝送方式を提供することを目的とする。発明の開示

上記課題を解決するために本発明の移動端末は、着信通知を受ける移動端末であって、前記移動端末は、前記着信通知内に含まれるサーバ装置に配送メッセ一ジが有ること示す信号をトリガとし、前記サーバ装置に対して前記配送メッセ一ジ取得要求を行ない、前記配送メッセージ取得要求に基づき前記サーバ装置から送信される前記配送メッセージを受信することを特徴とする。

また、上記課題を解決するために本発明の移動端末は、前記着信通知には、前記配送メッセージの大分類を示す配送メッセージ種別が含まれ、前記移動端末は、前記配送メッセージ種別に基づき、前記サーバ装置に配送メッセ一ジ取得要求を行なうことを特徴とする。

更に，上記課題を解決するために本発明の移動端末は、前記着信通知に基づいて前記配送メッセージ取得要求を行なう際に、前記移動端末は、配送メッセージ保存領域が確保できるか否かを確認した後に、配送メッセージ保存領域を確保できたならば、前記配送メッセージ取得要求を行なうことを特徴とする。

更に、上記課題を解決するために本発明の移動端末は、前記移動端末内に保存されている配送メッセージが、既読であり、かつ保護されていない場合には、新たに受信する配送メッセージにより上書き可能とし、配送メッセージ保存領域を確保できるか否かの判定には、保存領域を確保できると判定することを特徴とする o

更に、上記課題を解決するために本発明の移動端末は、前記配送メッセ一ジ種別にメールが含まれることを特徴とする。

更に、上記課題を解決するために本発明の移動端末は、移動端末とサーバ装置とがネットワークを介してデ一夕の伝送を行なうデータ伝送方式において、前記移動端末が前記サーバ装置から送信された配送メッセージを受信完了したことを示す応答を前記サーバ装置に返すことにより、前記サーバ装置は蓄積していたメッセージを削除することを特徴とする。図面の簡単な説明

図 1は、本発明の実施の形態における受信装置の構成を示す図である。

図 2は、本発明の実施の形態における受信装置の P U S Hメッセージ取得における処理の流れを示す第 1のフローチャートである。

図 3は、本発明の実施の形態における受信装置の P U S Hメッセージ取得における処理の流れを示す第 2のフローチャートである。

図 4は、本発明の実施の形態における受信装置の P U S Hメッセージ取得における処理の流れを示す第 3のフローチャートである。

図 5は、本発明の実施の形態における P U S Hメッセ一ジ着信通知の例を示す図である。

図 6は、本発明の実施の形態における P U S Hメヅセージの取得要求メッセ一ジの例を示す図である。

図 7は、本発明の実施の形態における受信端末が取得する第 1の P U S Hメッセージの例を示す図である。

図 8は、本発明の実施の形態における受信端末が取得する第 2の P U S Hメッセージの例を示す図である。

図 9は、本発明の移動端末とサーバ装置とがネヅトワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図である。発明を実施するための最良の形態

以下に、本発明の実施の形態について図面を用いて詳細に説明する。

図 1は、本発明の実施の形態における移動端末（受信装置）の構成を示す図である。図 1において移動端末である受信装置 1は、携帯電話網においてデ一夕の送受信を行なうデータ送受信手段 101と、受信装置とサーバ装置の間でサーバ装置に蓄積されたコンテンツメヅセージを取得する Webプロトコルである HTTPを処理する Webプロトコル処理手段 102と、受信装置 1が受信した PUSHメヅセージを保存する PUSHメッセージ保存手段 103と、 PUSHメッセージ要求処理手段 104と、 PUSHメッセージ解析処理手段 105と、 PUSHメッセージ管理手段 106とから構成されている。

PUSHメッセージ要求処理手段 104は、データ送受信手段 101が受信した着信通知に含まれる PUSHメッセージに関する内容に基づき、 PUSHメッセージ保存手段 103にメモリの空きの有無を確認し、空きがあれば PUSHメッセージの取得要求を We bプロトコル処理手段 102に対して行なう。

PUSHメッセージ解析処理手段 105は、 PUSHメッセージ要求処理手段 104 により、情報提供元であるサーバ装置に対して要求された PUSHメッセージ取得要求に対して、サーバ装置から返信される PUSHメッセージの解析処理を行なう。

PUSHメッセージ管理手段 106は、 PUSHメッセージ解析処理手段 105が解析した PUSHメヅセージを PUSHメッセージ保存手段 103に保存し、また P USHメッセ一ジ要求処理手段 104から PUSHメッセージの保存メモリに空きが有るか否かの問合せが有った時には、 PUSHメッセージ保存手段 103にメモリの空きが有るか否かをチェックし、 PUSHメッセ一ジ要求処理手段 104に空きの有無結果を通知する。

図 2〜図 4は、本発明の実施の形態における上記受信装置の PUSHメッセ一ジ取得における処理の流れを示すフローチャートである。図 1の受信装置 1のデ一夕送受信手段 101が PUSHメヅセージ着信通知を受信した後の PUSHメヅセージ取得の処理の流れを以下に説明する。

ステップ 101： PUSHメッセ一ジ要求処理手段 104は、デ一夕送受信手段 101 から通知された PUSHメヅセージ着信通知に含まれる PUSHメッセージ種別情報の判定を行なう。 PUSHメッセージ種別情報にメールが含まれていたならば、ステップ 102へ、そうでなければ、図 3のステップ 201へ進む。ステップ 102 : PUSHメッセージ要求処理手段 104は、 PUSHメッセージ管理手段 106に、メール保存メモリの空きの有無を問い合わせる。 PUSHメッセ —ジ管理手段 106は、 P U S Hメヅセージ保存手段 103のメール保存メモリの空き状況を確認し、 P U S Hメッセージ要求処理手段 104にメールメモリ空き状況の結果を通知する。メール保存メモリの空きが有る場合には、ステップ 103へ、空きがなければ図 3のステツプ 201へ進む。

ステップ 103 : PUSHメヅセージ要求処理手段 104は、メールの取得要求を W ebプロトコル処理手段 102に対して行なう。 Webプロトコル処理手段 102は、 P U S Hメッセージ要求処理手段 104からの要求に基づき、サーバとの間で取り決めた HTTPのフォーマットでメール取得要求デ一夕を作成し、デ一夕送受信手段 101にデ一夕送信依頼する。デ一夕送受信手段 101は、 Webプロトコル処理手段 102から依頼されたデータをサーバ装置に送信し、ステツプ 104へ進む。

ステップ 104：デ一夕送受信手段 101は、サーバ装置からデ一夕を受信したならば、 We bプロトコル処理手段 102に受信したデ一夕を通知する。 Webプロトコル処理手段 102は、 HTTPのフォーマットに従いサーバから応答された PUSH メヅセージを受信完了したならば、 PUSHメッセージ解析処理手段 105に PU SHメッセージ受信完了を通知する。 PUSHメッセージ解析処理手段 105は、 We bプロトコル処理手段 102からの PUSHメッセージ受信完了通知に基づき、メールの取得が成功したならばステップ 105へ、失敗したならば、図 3のステップ 201へ進む。

ステップ 105 : PUSHメッセージ管理手段 106は、 PUSHメッセージ解析処理手段 105の要求に基づき、 PUSHメッセージ保存手段 103のメール保存用メモリに受信したメールを保存し、ステップ 106へ進む。

ステップ 106： PUSHメッセージ解析処理手段 105は、受信した PUSHメッセージに含まれるサーバに未取得のメールが有るか否かを示す情報に基づき、サ —バに未取得のメールがあるならば、ステップ 102へ、未取得のメールがなければ図 3のステツプ 201へ進む。

これ以降、図 3のフローチャートに従って PUSHメッセージ取得の処理を説明する。ステップ 201： PUSHメッセージ要求処理手段 104は、データ送受信手段 101 から通知された PUSHメヅセージ着信通知に含まれる PUSHメヅセージ種別情報の判定を行なう。 PUSHメッセージ種別情報に第 1の情報サービスメッセ —ジが含まれていたならば、ステップ 202へ、そうでなければ、図 4のステップ 3 01へ進む。

ステップ 202： PUSHメッセージ要求処理手段 104は、 PUSHメヅセージ管理手段 106に、第 1の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。 PUSHメッセージ管理手段 106は、 PUSHメッセ一ジ保存手段 103 の第 1の情報サービスメッセージの保存メモリの空き状況を確認し、 PUSHメッセージ要求処理手段 104にメモリ空き状況の結果を通知する。第 1の情報サービスメッセージの保存メモリの空きが有る場合には、ステップ 203へ、空きがなければ図 4のステツプ 301へ進む。

ステツプ 203： P U S Hメッセージ要求処理手段 104は、第 1の情報サービスメッセージの取得要求を We bプロトコル処理手段 102に対して行なう。 Webプロトコル処理手段 102は、 PU SHメッセ一ジ要求処理手段 104からの要求に基づき、サーバとの間で取り决めた HTTPのフォーマツ卜で第 1の情報サービスメッセージの取得要求デ一夕を作成し、デ一夕送受信手段 101にデータ送信依頼する。デ一夕送受信手段 101は、 Webプロトコル処理手段 102から依頼されたデ一夕をサーバ装置に送信し、ステップ 204へ進む。

ステップ 204：データ送受信手段 101は、サーバ装置からデ一夕を受信したならば、 We bプロトコル処理手段 102に受信したデ一夕を通知する。 Webプロトコル処理手段 102は、 HTTPのフォーマツ卜に従いサーバから応答された PUSH メッセージを受信完了したならば、 PUSHメッセージ解析処理手段 105に PU SHメッセージ受信完了を通知する。 PUSHメッセージ解析処理手段 105は、 We bプロトコル処理手段 102からの PU SHメッセージ受信完了通知に基づき、第 1の情報サ一ビスメッセージの取得が成功したならばステップ 205へ、失敗したならば、図 4のステップ 301へ進む。

ステップ 205 : PUSHメッセージ管理手段 106は、 PUSHメッセ一ジ解析処理手段 105の要求に基づき、 PUSHメッセ一ジ保存手段 103の第 1の情報サ一ビスメッセージ保存用メモリに受信した第 1の情報サービスメッセージを保存し、ステップ 206へ進む。

ステップ 206： PUSHメッセージ解析処理手段 105は、受信した PUSHメヅセージに含まれるコンテンツタイプの情報により、受信した PUSHメッセージの本文が HTML (Hypertext Markup Language) であったなら、ステップ 207へ、そうでなければステツプ 210へ進む。

ステップ 207 : PUSHメッセージ解析処理手段 105は、 HTMLコンテンツの中にイメージデ一夕が挿入されることを示すィンラインイメージの情報が検出され、このィンラインイメージの情報に示されるイメージデ一夕の取得要求をしていない場合には、ステップ 208へ、そうでなければ、ステップ 210へ進む。

ステップ 208 : PUSHメッセージ解析処理手段 105は、サーバ装置から受信した HTMLコンテンッの中に未取得のィメ一ジデ一夕が有ることを P U S Hメッセ一ジ要求処理手段 104に通知する。 PUSHメッセージ要求処理手段 104は、未取得のイメージデ一夕の取得要求を We bプロトコル処理手段 102に対して行なう。 We bプロトコル処理手段 102は、 P U S Hメッセ一ジ要求処理手段 104からの要求に基づき、サーバとの間で取り決めた HTTPのフォ一マツトで取得要求デ一夕を作成し、データ送受信手段 101にデ一夕送信依頼する。データ送受信手段 101は、 We bプロトコル処理手段 102からの依頼されたデ一夕をサーバ装置に送信し、ステップ 209へ進む。

ステップ 209：デ一夕送受信手段 101は、サーバ装置からデ一夕を受信したならば、 We bプロトコル処理手段 102に受信したデ一夕を通知する。 Webプロトコル処理手段 102は、 HTTPのフォーマヅトに従いサーバから応答された PUSH メッセージを受信完了したならば、 PUSHメッセージ解析処理手段 105に PU SHメッセージ受信完了を通知する。 PUSHメッセージ解析処理手段 105は、 We bプロトコル処理手段 102からの PUSHメッセージ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデ一夕の情報を保存してからステップ 207へ進み、失敗したならば、受信デ一夕の保存をせずにステップ 207へ進む。

ステツプ 210：： P U S Hメヅセージ解析処理手段 105は、受信した P U S Hメッセージに含まれるサーバに未取得の第 1の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第 1の情報サ一ビスメヅセージがあるならば、ステツプ 202へ、未取得の第 1の情報サービスメッセージがなければ図 4 のステップ 301へ進む。

これ以降、図 4のフローチャートに従って PUSHメッセージ取得の処理を説明する。

ステップ 301： PUSHメッセージ要求処理手段 104は、データ送受信手段 101 から通知された PUSHメッセージ着信通知に含まれる PUSHメッセージ種別情報の判定を行なう。 PUSHメッセージ種別情報に第 2の情報サービスメッセージが含まれていたならば、ステップ 302へ、そうでなければ、処理を終了する ο

ステップ 302 : PUSHメッセージ要求処理手段 104は、 PUSHメッセージ管理手段 106に、第 2の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。 PUSHメッセージ管理手段 106は、 PUSHメッセージ保存手段 103 の第 2の情報サービスメッセージの保存メモリの空き状況を確認し、 PUSHメッセージ要求処理手段 104にメモリ空き状況の結果を通知する。第 2の情報サ一ビスメッセージの保存メモリの空きが有る場合には、ステップ 303へ、空きがなければ処理を終了する。

ステップ 303 : PUSHメッセ一ジ要求処理手段 104は、第 2の情報サービスメッセージの取得要求を We bプロトコル処理手段 102に対して行なう。 Webプ口トコル処理手段 102は、 PUSHメッセージ要求処理手段 104からの要求に基づき、サーバとの間で取り決めた HTTPのフォーマヅトで第 2の情報サービスメッセージの取得要求デ一夕を作成し、デ一夕送受信手段 101にデ一夕送信依頼する。デ一夕送受信手段 101は、 Webプロトコル処理手段 102から依頼されたデータをサーバ装置に送信し、ステップ 304へ進む。

ステップ 304：データ送受信手段 101は、サーバ装置からデ一夕を受信したならば、 We bプロトコル処理手段 102に受信したデ一夕を通知する。 Webプロトコル処理手段 102は、 HTTPのフォーマツ卜に従いサーバから応答された PUSH メヅセージを受信完了したならば、 PUSHメヅセージ解析処理手段 105に PU SHメヅセージ受信完了を通知する。 PUSHメッセージ解析処理手段 105は、 W e bプロトコル処理手段 102からの PUSHメッセージ受信完了通知に基づき、第 2の情報サービスメッセージの取得が成功したならばステップ 305へ、失敗したならば、処理を終了する。

ステップ 305： PUSHメッセージ管理手段 106は、 PUSHメッセージ解析処理手段 105の要求に基づき、 P U S Hメッセージ保存手段 103の第 2の情報サ一ビスメッセージ保存用メモリに受信した第 2の情報サービスメッセ一ジを保存し、ステップ 306へ進む。

ステップ 306： PUSHメヅセージ解析処理手段 105は、受信した PUSHメッセージに含まれるコンテンツタイプの情報により、受信した PUSHメッセージの本文が HTML (Hypertext Markup Language) であったなら、ステップ 307へ、そうでなければステツプ 310へ進む。

ステップ 307 : PUSHメッセ一ジ解析処理手段 105は、 HTMLコンテンツの中にイメージデータが挿入されることを示すィンラインイメージの情報が検出され、このィンラインイメージの情報に示されるイメージデ一夕の取得要求をしていない場合には、ステップ 308へ、そうでなければ、ステップ 310へ進む。

ステップ 308 : PUSHメッセ一ジ解析処理手段 105は、サーバ装置から受信した HTMLコンテンツの中に未取得のイメージデ一夕が有ることを PU SHメヅセ一ジ要求処理手段 104に通知する。 PUSHメッセージ要求処理手段 104は、未取得のイメージデータの取得要求を Webプロトコル処理手段 102に対して行なう。 Webプロトコル処理手段 102は、 PUSHメッセージ要求処理手段 104からの要求に基づき、サーバとの間で取り決めた HTTPのフォーマツトで取得要求デ一夕を作成し、データ送受信手段 101にデータ送信依頼する。データ送受信手段 101は、 Webプロトコル処理手段 102から依頼されたデータをサーバ装置に送信し、ステップ 309へ進む。

ステップ 309：デ一夕送受信手段 101は、サーバ装置からデータを受信したならば、 We bプロトコル処理手段 102に受信したデ一夕を通知する。 Webプロトコル処理手段 102は、 HTTPのフォーマツトに従いサーバから応答された PUSH メッセージを受信完了したならば、 PUSHメッセージ解析処理手段 105に PU S Hメッセージ受信完了を通知する。 PUSHメッセ一ジ解析処理手段 105は、 W e bプロトコル処理手段 102からの PUSHメッセ一ジ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデ一夕の情報を保存してからステップ 307へ進み、失敗したならば、受信データの保存をせずにステツプ 307へ進む。

ステヅプ 310： P U S Hメッセージ解析処理手段 105は、受信した P U S Hメヅセージに含まれるサーバに未取得の第 2の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第 2の情報サ一ビスメッセージがあるならば、ステツプ 302へ、未取得の第 2の情報サービスメッセ一ジがなければ処理を終了する。

このように動作する受信装置 1が図 5の P U S Hメッセ一ジ着信通知を受信した時の具体的な動作を以下に説明する。

図 5は、本発明の実施の形態における P U S Hメッセージ着信通知に含まれる PUSHメッセージに関する情報の例を示す図である。

PUSHメッセ一ジ着信通知は、 PUSHメッセージの分類を示す PUSHメッセージ種別情報とサーバ装置の P U S Hメッセージ蓄積許容量満杯であるか否かを示すサーバ蓄積容量情報とから構成される。

本実施形態で示す P U S Hメッセージの種別としては、メールと第 1の情報提供サービスメッセージおよび第 2の情報提供サービスメッセージとから構成される。そして、「1」がサーバ装置に未取得の PUSHメッセージが存在することを示し、「0」は、未取得の PUSHメヅセ一ジは存在しないことを示す。今、 PUSHメッセージ種別情報は、「0001」であるので、サーバ装置にある未取得のデータは、メールのみであることが示される。

PUSHメッセ一ジ蓄積容量情報は、それそれの PUSHメッセージ種別に対応した付随情報である。そして、「1」が、サーバ装置の PUSHメッセージ蓄積容量が許容量満杯であることを示している。

今、サーバ蓄積容量情報は、「0000」であるのでサーバ装置には、 PUS Hメッセ一ジ蓄積の許容量に至つていないことが示される。

図 5で示す PUSHメッセージ着信通知に含まれる PUSHメッセージに関する情報をデータ送受信手段 101が受信したならば、 PUSHメッセージ要求処理手段 104に通知される。 PUSHメッセ一ジ要求処理手段 104は、 PUSHメヅセ —ジ着信通知の内容を解析し、サーバに未取得のメールがあると判断する（ステップ 101参照）。 .

PUSHメッセ一ジ要求手段 104は、 PUSHメッセージ管理手段 106にメールの保存メモリに空きが有るか否かを問い合わせる。 P U S Hメッセージ管理手段 106は、メールの保存メモリに空きの有無を確認する。 PUSHメッセージ保存手段 103のメール保存メモリに、すでにメールが満杯であっても、既読であり、かつ保護されていないメールであれば、上書き可能としてメモリに空きがあるものとする。ここで、メールの保存メモリに空きが有ったならば、メールの取得要求を行なう（ステップ 103参照）

PUSHメッセージ（メール）取得要求メッセ一ジの具体例を図 6に示す。 PUSHメヅセージの取得要求メッセージは、 HTTPのリクエストメヅセージに従つて構成されている。 HTTPのリクエストメッセージには、処理の要求内容を示すメソッドと要求先の位置を示す URL情報と HTTPのバージョン情報とから構成される。

図 6の PUSHメッセージ（メール）取得要求メッセージでは、処理の要求内容を示すメソッドは「GET」であり、コンテンツの取得要求を示す。 URL情報は、要求先のァドレスと PUSHメッセージの種別と取得要求 PUSHメッセ —ジ IDとを含んでいる。 PUSHメッセージの種別の「e—mes」は、取得要求する PUSHメヅセージがメールであることを示す。取得要求 PUSHメッセ一ジ IDは「NXT=」以降の 5桁の数字で表される。ただし、「00000」は、 P U S Hメヅセージ取得要求の開始を示す I Dである。「HTTP/1.0] は、 HTTPのバ一ジョンが 1.0であることを示している。

図 7は、サーバから取得した PUSHメッセージの第 1の具体例であり、これは、 HTTPのレスポンスのフォ一マツトに従っている。

HTTPのレスポンスデータは、レスポンス行とヘッダ部とボディ部である本文とから構成される。一行目は、レスポンス行であり、 HTTPバ一ジョン情報とリクェストに対する処理結果のステ一タスコ一ドとステータスコードに付いての説明文とから構成される。

図 7に示す例では、 HTTPバージョンは、「HTTP/1.0」よりバージョン 1.0であることが示されている。ステータスコード「200」は、サーバ装置にてリクェス卜が正常に受付けられて、本文のデータはリクエストに対して有効なデ一夕であることが示されている。「OK」は、ステータスコードの説明文である。二行目から、 <CR〉<LF> (OxOD, Ox OA) で示される空行までが、ヘッダ部であり、「Content-Length」は、本文データのバイト数を示している rContent-Typejは、本文データのコンテンツ種別を示し、「text/plain」はプレインテキストであることが示されている。「X—」で始まるへヅダ情報は、 PUSHメッセ一ジの取得のために拡張を行なつたへッダ情報である。

「X-EID」は、メールの IDを示す。前半部分の「00001」が取得した本文のデ一夕であるメールの I Dを示し、後半部分の「00002」が次にメール取得要求する時のメール I Dを示す。

「X— D] は、日付情報であり、 PUSHメッセージ（メール）がサーバに到着した時間を示す。「199812171639」は、 1998年 12月 17日 16時 39分を表す。

「X— F] は、メールの送信元アドレスを示す。

図 8は、サーバから取得した PUSHメッセージの第二の具体例である。第一の具体例と同様に HTTPのレスポンスのフォーマツトに従っている。 PUSH メッセージ取得のために拡張を行なったヘッダ情報である「X-EID」は、メールの I Dを示し、前半部分の「00002」が取得した本文のデ一夕であるメールの IDを示す。後半部分は、次にサーバ装置に対して取得要求するメールの ID が示されるが、図 8に示す「00000」の場合には、サーバ装置に蓄積されている未取得のメールが存在しないことを示す。

図 9は、本発明の移動端末とサーバ装置とがネットワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図であり、サーバ装置に受信装置 1宛のメールが 2件が蓄積された場合を例を示す。サーバ装置は、メール 2件のメール I Dをそれぞれ、 00001と 00002 とに割り当てる。サーバ装置は、受信装置 1に未取得の PUSHメッセ一ジ（メ —ル）が蓄積されていることを受信装置 1に通知するために PUSHメッセージ着信通知を送信する。ここでは、図 5に示す PUSHメッセージ着信通知を受信装置 1に送信した例を示す。

受信装置 1では、データ送受信手段 101により受信した図 5に示す P U S Hメヅセージ着信通知を基に、 PUSHメッセージ要求処理手段 104は、 PUSHメヅセージ種別情報のメールが「1」であるので、サーバ装置に未取得のメールが蓄積されていると判断し、 PUSHメッセージ管理手段 106に対してメール取得のための空きメモリ有無を確認する。ここでは、 PUSHメッセージ保存手段 10 3にメール取得のための空きメモリが有るものとする。

PUSHメッセ一ジ要求処理手段 104は、メール取得のための空きメモリが確保できるので、図 6に示す PUSHメッセージ（メール）取得の開始要求をサ一バ装置に対して送信する（ステップ 103参照）。

PUSHメッセージ（メール）取得の開始要求を受けたサーバ装置では、第 1 のメールを図 7に示す P U S Hメッセージとして受信装置 1に対して送信する。

「X- EID : 00001/00002」は、サーバ装置から受信装置 1に対して送信される第 1のメールがサーバに蓄積したメール I D 「00001」のメールに対応していることを示している。

また、後半部分の「00002」は、サーバ装置には、未送信のメールが蓄積されていることを示し、次に受信装置 1から取得要求する時の PUSHメッセ一ジ（メール）取得要求のメール I Dを「00002j として要求することを指示する指示情報である。

PUSHメッセージ（メール）取得応答を受けた受信端末では、 PUSHメヅセージ保存手段 103に確保されているメ一ル保存メモリに受信したメールを保存する（ステップ 105参照）。

サーバ装置から送信されたデータを受信完了した受信装置 1は、デ一夕送受信手段 101よりデータ受信完了応答をサーバ装置に対して送信する。

サーバ装置では、受信装置 1からのデータ受信完了応答を受信したならば、受信装置 1へのメールの送信が完了したものとし、メールボックスのメール I D 「 00001 I のメールを削除する。受信装置 1では、 PUSHメッセ一ジ（メール）取得応答に含まれる次に要求すべきメ一ル IDが「00000」ではないので、サーバ装置に未取得のメールが有ると判断する（ステップ 106参照）。ここで、再びメール取得のためメール保存メモリの空きの有無を確認する。ここでも、 PUSHメッセージ保存手段 10 3にメール取得のための空きメモリが有るものとする。

受信装置 1は、サーバ装置に PUSHメッセ一ジ（メール）取得要求「NXT=0 0002」を送信する。この PUSHメッセージ（メール）取得要求を受けたサ —バ装置は、メールボックスに蓄積されるメール I D： 00002のメールを図 8に示す P U S Hメッセージとして受信装置 1に対して送信する。

その際に、サーバ上のメールボックスには、未送信のメールが存在しなくなるので、メールの I D情報を、「X- EID： 00002/00000」として送信する。

「00002」は、送信しているメール本文のメール I Dであり、後半の「0 0000」はサーバ装置には、未送信で蓄積されているメールはないことを示している。

この PUSHメッセージ（メール）取得応答を受信した受信端末では、メールを P U S Hメッセージ保存手段 103のメ一ル保存メモリに保存する（ステツプ 105 参照）。

サーバ装置から送信されたデ一夕を受信完了した受信装置 1は、デ一夕送受信手段 101よりデ一夕受信完了応答をサーバ装置に対して送信する。

サーバ装置では、受信装置 1からのデ一夕受信完了応答を受信したならば、受信装置 1へのメールの送信が完了したものとし、メールボックスのメール I D 「 00002」のメールを削除する。

なお、 PUSHメッセージ管理手段 106の PUSHメヅセージの保存メモリに空きの有無の判定において、既読であり、かつ保護されていない PUSHメッセージであれば、上書き可能としてメモリに空きがあるものとしたが、ユーザ操作により PUSHメッセージを削除されない限り、上書きを不可としても良い。産業上の利用可能性以上のように本発明によれば、携帯電話などのデ一夕保存メモリが比較的少ない携帯端末において、情報提供元から提供される任意のタイミングの PUSHメッセージを取りこぼすことなく受信できる移動端末およびデータ伝送方式を提供することができる。

Claims

請求の範囲

1 . 着信通知を受ける移動端末であって、前記移動端末は、前記着信通知内に含まれるサーバ装置に前記移動端末宛ての配送メッセージが蓄積されていること示す信号をトリガとし、前記サーバ装置に対して前記配送メッセージ取得要求を行ない、前記配送メッセージ取得要求に基づき前記サーバ装置から送信される前記配送メッセージを受信することを特徴とする移動端末。

2 . 前記着信通知には、前記配送メッセージの大分類を示す配送メッセージ種別が含まれ、前記移動端末は、前記配送メッセージ種別に基づき、前記サーバ装置に配送メッセージ取得要求を行なうようにする請求項 1記載の移動端末。

3 . 前記着信通知に基づいて前記配送メッセージ取得要求を行なう際に、前記移動端末は、配送メッセージ保存領域が確保できるか否かを確認した後に、配送メッセージ保存領域を確保できたならば、前記配送メッセージ取得要求を行なうようにする請求項 1記載の移動端末。

4 . 前記移動端末内に保存されている配送メッセージが、既読であり、かつ保護されていない場合には、新たに受信する配送メッセージにより上書き可能とし、配送メッセージ保存領域を確保できるか否かの判定には、保存領域を確保できると判定する前記請求項 3記載の移動端末。

5 . 前記配送メッセージ種別にメールが含まれる請求項 2記載の移動端末。

6 . 移動端末とサーバ装置とがネットワークを介してデ一夕の伝送を行なうデ —夕伝送方式において、前記移動端末が前記サーバ装置から送信された配送メッセージを受信完了したことを示す応答を前記サーバ装置に返すことにより、前記サーバ装置は蓄積していたメッセージを削除することを特徴とするデ一夕伝送方式。