JP3833141B2 - サーバ装置及び移動端末からなるデータ伝送システム - Google Patents
サーバ装置及び移動端末からなるデータ伝送システム Download PDFInfo
- Publication number
- JP3833141B2 JP3833141B2 JP2002152509A JP2002152509A JP3833141B2 JP 3833141 B2 JP3833141 B2 JP 3833141B2 JP 2002152509 A JP2002152509 A JP 2002152509A JP 2002152509 A JP2002152509 A JP 2002152509A JP 3833141 B2 JP3833141 B2 JP 3833141B2
- Authority
- JP
- Japan
- Prior art keywords
- push message
- message
- server device
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、サーバ装置及び移動端末からなるデータ伝送システムに関し、特にサーバからデータ保存メモリが少ないクライアント（移動端末）へＰＵＳＨ型メッセージを配送し得るよう構成したものである。
【０００２】
【従来の技術】
今日の高度情報化社会における情報通信では、インターネットを介して、ユーザがアクセス先のアドレスを指定することにより、いろいろな情報を即時に取得することが可能となってきた。
【０００３】
クライアントとサーバ間のデータ転送プロトコルとして、HTTP(Hypertext Transfer Protocol）が広く普及している。
【０００４】
HTTPは、クライアントからの取得要求に対してサーバが応答して、クライアントから要求された情報を通知することにより、ユーザは情報を取得することができる。
【０００５】
また、近年、クライアントから要求の起動をかけるＰＵＬＬ型のサービスだけでなく、情報送信元が任意のタイミングで、クライアントに情報を提供するＰＵＳＨ型のサービスが見られるようになってきた。
【０００６】
これにより、クライアントから情報送信要求の起動をかけなくとも、予め取り決めた情報提供元から、提供される情報が発生した時点で即時に情報が提供される。
【０００７】
例えば、特開平9-148994号公報に開示されている「データ放送システム及びその端末装置」では、放送データチャンネルを利用して、各種のデジタル信号を送信しており、放送データを受信する受信装置では、リアルタイムに情報を入手することが可能となっている。
【０００８】
【発明が解決しようとする課題】
しかしながら、携帯電話などのデータ保存メモリが比較的少ない携帯端末においては、情報提供元から提供される情報を保存しきれないといった問題が生じる。特に有料のサービス情報や、電子メールなどの重要な情報である場合には、この取りこぼしが問題となる。
【０００９】
上記の課題に鑑み本発明は、データ保存メモリが少ない携帯端末において、情報提供元から提供されるリアルタイムの情報を、確実に受信できるサーバ装置及び移動端末からなるデータ伝送システムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記課題を解決するために本発明の請求項１記載の発明は、着信通知を受ける移動端末とサーバ装置とからなるデータ伝送システムであって、前記移動端末は、前記着信通知内に含まれるサーバ装置に配送メッセージが有ること示す信号をトリガとし、前記サーバ装置に対して前記配送メッセージ取得要求を行ない、前記配送メッセージ取得要求に基づき前記サーバ装置は配送メッセージ取得応答を送信し、前記移動端末は前記受信した配送メッセージ取得応答に含まれる次の未取得メッセージの有無を示す指示情報に基づき、次に未取得メッセージがあるならば、配送メッセージ保存領域確保ができるか否かを確認し、前記配送メッセージ保存領域を確保できたならば、前記サーバ装置に次の配送メッセージ取得要求を行ない、前記サーバ装置は前記次の未取得メッセージの配送を行なうことを特徴とする。
【００１６】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を用いて詳細に説明する。図１は、本発明の実施の形態における移動端末（受信装置）の構成を示す図である。
【００１７】
図１において移動端末である受信装置１は、携帯電話網においてデータの送受信を行なうデータ送受信手段101と、受信装置とサーバ装置の間でサーバ装置に蓄積されたコンテンツメッセージを取得するWebプロトコルであるHTTPを処理するＷｅｂプロトコル処理手段102と、受信装置１が受信したＰＵＳＨメッセージを保存するＰＵＳＨメッセージ保存手段103と、ＰＵＳＨメッセージ要求処理手段104と、ＰＵＳＨメッセージ解析処理手段105と、ＰＵＳＨメッセージ管理手段106とから構成されている。
【００１８】
ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101が受信した着信通知に含まれるＰＵＳＨメッセージに関する内容に基づき、ＰＵＳＨメッセージ保存手段103にメモリの空きの有無を確認し、空きがあればＰＵＳＨメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。
【００１９】
ＰＵＳＨメッセージ解析処理手段105は、ＰＵＳＨメッセージ要求処理手段104により、情報提供元であるサーバ装置に対して要求されたＰＵＳＨメッセージ取得要求に対して、サーバ装置から返信されるＰＵＳＨメッセージの解析処理を行なう。
【００２０】
ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105が解析したＰＵＳＨメッセージをＰＵＳＨメッセージ保存手段103に保存し、またＰＵＳＨメッセージ要求処理手段104からＰＵＳＨメッセージの保存メモリに空きが有るか否かの問合せが有った時には、ＰＵＳＨメッセージ保存手段103にメモリの空きが有るか否かをチェックし、ＰＵＳＨメッセージ要求処理手段104に空きの有無結果を通知する。
【００２１】
図２〜図４は、本発明の実施の形態における上記受信装置のＰＵＳＨメッセージ取得における処理の流れを示すフローチャートである。図１の受信装置１のデータ送受信手段101がＰＵＳＨメッセージ着信通知を受信した後のＰＵＳＨメッセージ取得の処理の流れを以下に説明する。
【００２２】
ステップ101：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報にメールが含まれていたならば、ステップ102へ、そうでなければ、図３のステップ201へ進む。
【００２３】
ステップ102：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、メール保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103のメール保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメールメモリ空き状況の結果を通知する。メール保存メモリの空きが有る場合には、ステップ103へ、空きがなければ図３のステップ201へ進む。
【００２４】
ステップ103：ＰＵＳＨメッセージ要求処理手段104は、メールの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットでメール取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ104へ進む。
【００２５】
ステップ104：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、メールの取得が成功したならばステップ105へ、失敗したならば、図３のステップ201へ進む。
【００２６】
ステップ105：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103のメール保存用メモリに受信したメールを保存し、ステップ106へ進む。
【００２７】
ステップ106：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得のメールが有るか否かを示す情報に基づき、サーバに未取得のメールがあるならば、ステップ102へ、未取得のメールがなければ図３のステップ201へ進む。
【００２８】
これ以降、図３のフローチャートに従ってＰＵＳＨメッセージ取得の処理を説明する。
【００２９】
ステップ201：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報に第１の情報サービスメッセージが含まれていたならば、ステップ202へ、そうでなければ、図４のステップ301へ進む。
【００３０】
ステップ202：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、第１の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103の第１の情報サービスメッセージの保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメモリ空き状況の結果を通知する。第１の情報サービスメッセージの保存メモリの空きが有る場合には、ステップ203へ、空きがなければ図４のステップ301へ進む。
【００３１】
ステップ203：ＰＵＳＨメッセージ要求処理手段104は、第１の情報サービスメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで第１の情報サービスメッセージの取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ204へ進む。
【００３２】
ステップ204：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、第１の情報サービスメッセージの取得が成功したならばステップ205へ、失敗したならば、図４のステップ301へ進む。
【００３３】
ステップ205：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103の第１の情報サービスメッセージ保存用メモリに受信した第１の情報サービスメッセージを保存し、ステップ206へ進む。
【００３４】
ステップ206：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるコンテンツタイプの情報により、受信したＰＵＳＨメッセージの本文がHTML（Hypertext Markup Language） であったなら、ステップ207へ、そうでなければステップ210へ進む。
【００３５】
ステップ207：ＰＵＳＨメッセージ解析処理手段105は、HTMLコンテンツの中にイメージデータが挿入されることを示すインラインイメージの情報が検出され、このインラインイメージの情報に示されるイメージデータの取得要求をしていない場合には、ステップ208へ、そうでなければ、ステップ210へ進む。
【００３６】
ステップ208：ＰＵＳＨメッセージ解析処理手段105は、サーバ装置から受信したHTMLコンテンツの中に未取得のイメージデータが有ることをＰＵＳＨメッセージ要求処理手段104に通知する。ＰＵＳＨメッセージ要求処理手段104は、未取得のイメージデータの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102からの依頼されたデータをサーバ装置に送信し、ステップ209へ進む。
【００３７】
ステップ209：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデータの情報を保存してからステップ207へ進み、失敗したならば、受信データの保存をせずにステップ207へ進む。
【００３８】
ステップ210：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得の第１の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第１の情報サービスメッセージがあるならば、ステップ202へ、未取得の第１の情報サービスメッセージがなければ図４のステップ301へ進む。
【００３９】
これ以降、図４のフローチャートに従ってＰＵＳＨメッセージ取得の処理を説明する。
【００４０】
ステップ301：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報に第２の情報サービスメッセージが含まれていたならば、ステップ302へ、そうでなければ、処理を終了する。
【００４１】
ステップ302：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、第２の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103の第２の情報サービスメッセージの保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメモリ空き状況の結果を通知する。第２の情報サービスメッセージの保存メモリの空きが有る場合には、ステップ303へ、空きがなければ処理を終了する。
【００４２】
ステップ303：ＰＵＳＨメッセージ要求処理手段104は、第２の情報サービスメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで第２の情報サービスメッセージの取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ304へ進む。
【００４３】
ステップ304：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、第２の情報サービスメッセージの取得が成功したならばステップ305へ、失敗したならば、処理を終了する。
【００４４】
ステップ305：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103の第２の情報サービスメッセージ保存用メモリに受信した第２の情報サービスメッセージを保存し、ステップ306へ進む。
【００４５】
ステップ306：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるコンテンツタイプの情報により、受信したＰＵＳＨメッセージの本文がHTML（Hypertext Markup Language） であったなら、ステップ307へ、そうでなければステップ310へ進む。
【００４６】
ステップ307：ＰＵＳＨメッセージ解析処理手段105は、HTMLコンテンツの中にイメージデータが挿入されることを示すインラインイメージの情報が検出され、このインラインイメージの情報に示されるイメージデータの取得要求をしていない場合には、ステップ308へ、そうでなければ、ステップ310へ進む。
【００４７】
ステップ308：ＰＵＳＨメッセージ解析処理手段105は、サーバ装置から受信したHTMLコンテンツの中に未取得のイメージデータが有ることをＰＵＳＨメッセージ要求処理手段104に通知する。ＰＵＳＨメッセージ要求処理手段104は、未取得のイメージデータの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ309へ進む。
【００４８】
ステップ309：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデータの情報を保存してからステップ307へ進み、失敗したならば、受信データの保存をせずにステップ307へ進む。
【００４９】
ステップ310：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得の第２の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第２の情報サービスメッセージがあるならば、ステップ302へ、未取得の第２の情報サービスメッセージがなければ処理を終了する。
【００５０】
このように動作する受信装置１が図５のＰＵＳＨメッセージ着信通知を受信した時の具体的な動作を以下に説明する。
【００５１】
図５は、本発明の実施の形態におけるＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージに関する情報の例を示す図である。
【００５２】
ＰＵＳＨメッセージ着信通知は、ＰＵＳＨメッセージの分類を示すＰＵＳＨメッセージ種別情報とサーバ装置のＰＵＳＨメッセージ蓄積許容量満杯であるか否かを示すサーバ蓄積容量情報とから構成される。
【００５３】
本実施形態で示すＰＵＳＨメッセージの種別としては、メールと第１の情報提供サービスメッセージおよび第２の情報提供サービスメッセージとから構成される。そして、「１」がサーバ装置に未取得のＰＵＳＨメッセージが存在することを示し、「０」は、未取得のＰＵＳＨメッセージは存在しないことを示す。
【００５４】
今、ＰＵＳＨメッセージ種別情報は、「０００１」であるので、サーバ装置にある未取得のデータは、メールのみであることが示される。
【００５５】
ＰＵＳＨメッセージ蓄積容量情報は、それぞれのＰＵＳＨメッセージ種別に対応した付随情報である。そして、「１」が、サーバ装置のＰＵＳＨメッセージ蓄積容量が許容量満杯であることを示している。
【００５６】
今、サーバ蓄積容量情報は、「００００」であるのでサーバ装置には、ＰＵＳＨメッセージ蓄積の許容量に至っていないことが示される。
【００５７】
図５で示すＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージに関する情報をデータ送受信手段101が受信したならば、ＰＵＳＨメッセージ要求処理手段104に通知される。ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ着信通知の内容を解析し、サーバに未取得のメールがあると判断する（ステップ101参照）。
【００５８】
ＰＵＳＨメッセージ要求手段104は、ＰＵＳＨメッセージ管理手段106にメールの保存メモリに空きが有るか否かを問い合わせる。ＰＵＳＨメッセージ管理手段106は、メールの保存メモリに空きの有無を確認する。ＰＵＳＨメッセージ保存手段103のメール保存メモリに、すでにメールが満杯であっても、既読であり、かつ保護されていないメールであれば、上書き可能としてメモリに空きがあるものとする。ここで、メールの保存メモリに空きが有ったならば、メールの取得要求を行なう（ステップ103参照）。
【００５９】
ＰＵＳＨメッセージ（メール）取得要求メッセージの具体例を図６に示す。ＰＵＳＨメッセージの取得要求メッセージは、HTTPのリクエストメッセージに従って構成されている。HTTPのリクエストメッセージには、処理の要求内容を示すメソッドと要求先の位置を示すＵＲＬ情報とHTTPのバージョン情報とから構成される。
【００６０】
図６のＰＵＳＨメッセージ（メール）取得要求メッセージでは、処理の要求内容を示すメソッドは「ＧＥＴ」であり、コンテンツの取得要求を示す。ＵＲＬ情報は、要求先のアドレスとＰＵＳＨメッセージの種別と取得要求ＰＵＳＨメッセージＩＤとを含んでいる。ＰＵＳＨメッセージの種別の「e_mes」は、取得要求するＰＵＳＨメッセージがメールであることを示す。取得要求ＰＵＳＨメッセージＩＤは「NXT=」以降の５桁の数字で表される。ただし、「０００００」は、ＰＵＳＨメッセージ取得要求の開始を示すＩＤである。「HTTP/1.0］は、HTTPのバージョンが1.0であることを示している。
【００６１】
図７は、サーバから取得したＰＵＳＨメッセージの第１の具体例であり、これは、HTTPのレスポンスのフォーマットに従っている。
【００６２】
HTTPのレスポンスデータは、レスポンス行とヘッダ部とボディ部である本文とから構成される。一行目は、レスポンス行であり、HTTPバージョン情報とリクエストに対する処理結果のステータスコードとステータスコードに付いての説明文とから構成される。
【００６３】
図７に示す例では、HTTPバージョンは、「HTTP/1.0」よりバージョン1.0であることが示されている。ステータスコード「２００」は、サーバ装置にてリクエストが正常に受付けられて、本文のデータはリクエストに対して有効なデータであることが示されている。「ＯＫ」は、ステータスコードの説明文である。
【００６４】
二行目から、＜ＣＲ＞＜ＬＦ＞（０ｘ０Ｄ，０ｘ０Ａ）で示される空行までが、ヘッダ部であり、「Content-Length」は、本文データのバイト数を示している。
【００６５】
「Content-Type」は、本文データのコンテンツ種別を示し、「text/plain」はプレインテキストであることが示されている。「Ｘ−」で始まるヘッダ情報は、ＰＵＳＨメッセージの取得のために拡張を行なったヘッダ情報である。
【００６６】
「X-EID」は、メールのＩＤを示す。前半部分の「００００１」が取得した本文のデータであるメールのＩＤを示し、後半部分の「００００２」が次にメール取得要求する時のメールＩＤを示す。
【００６７】
「Ｘ−Ｄ］は、日付情報であり、ＰＵＳＨメッセージ（メール）がサーバに到着した時間を示す。「199812171639」は、1998年12月17日16時39分を表す。
【００６８】
「Ｘ−Ｆ］は、メールの送信元アドレスを示す。
【００６９】
図８は、サーバから取得したＰＵＳＨメッセージの第二の具体例である。第一の具体例と同様にHTTPのレスポンスのフォーマットに従っている。ＰＵＳＨメッセージ取得のために拡張を行なったヘッダ情報である「X-EID」は、メールのＩＤを示し、前半部分の「００００２」が取得した本文のデータであるメールのＩＤを示す。後半部分は、次にサーバ装置に対して取得要求するメールのＩＤが示されるが、図８に示す「０００００」の場合には、サーバ装置に蓄積されている未取得のメールが存在しないことを示す。
【００７０】
図９は、本発明の移動端末とサーバ装置とがネットワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図であり、サーバ装置に受信端末１宛のメールが２件が蓄積された場合を例を示す。
【００７１】
サーバ装置は、メール２件のメールＩＤをそれぞれ、００００１と００００２とに割り当てる。サーバ装置は、受信端末１に未取得のＰＵＳＨメッセージ（メール）が蓄積されていることを受信端末１に通知するためにＰＵＳＨメッセージ着信通知を送信する。ここでは、図５に示すＰＵＳＨメッセージ着信通知を受信端末１に送信した例を示す。
【００７２】
受信端末１では、データ送受信手段101により受信した図５に示すＰＵＳＨメッセージ着信通知を基に、ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ種別情報のメールが「１」であるので、サーバ装置に未取得のメールが蓄積されていると判断し、ＰＵＳＨメッセージ管理手段106に対してメール取得のための空きメモリ有無を確認する。ここでは、ＰＵＳＨメッセージ保存手段103にメール取得のための空きメモリが有るものとする。
【００７３】
ＰＵＳＨメッセージ要求処理手段104は、メール取得のための空きメモリが確保できるので、図６に示すＰＵＳＨメッセージ（メール）取得の開始要求をサーバ装置に対して送信する（ステップ103参照）。
【００７４】
ＰＵＳＨメッセージ（メール）取得の開始要求を受けたサーバ装置では、第１のメールを図７に示すＰＵＳＨメッセージとして受信端末１に対して送信する。
【００７５】
「X-EID：００００１／００００２」は、サーバ装置から受信装置１に対して送信される第１のメールがサーバに蓄積したメールＩＤ「００００１」のメールに対応していることを示している。
【００７６】
また、後半部分の「００００２」は、サーバ装置には、未送信のメールが蓄積されていることを示し、次に受信装置１から取得要求する時のＰＵＳＨメッセージ（メール）取得要求のメールＩＤを「００００２」として要求することを指示する指示情報である。
【００７７】
ＰＵＳＨメッセージ（メール)取得応答を受けた受信端末では、ＰＵＳＨメッセージ保存手段103に確保されているメール保存メモリに受信したメールを保存する（ステップ105参照）。
【００７８】
サーバ装置から送信されたデータを受信完了した受信端末１は、データ送受信手段101よりデータ受信完了応答をサーバ装置に対して送信する。
【００７９】
サーバ装置では、受信端末１からのデータ受信完了応答を受信したならば、受信端末１へのメールの送信が完了したものとし、メールボックスのメールＩＤ「００００１」のメールを削除する。
【００８０】
受信端末１では、ＰＵＳＨメッセージ（メール）取得応答に含まれる次に要求すべきメールＩＤが「０００００」ではないので、サーバ装置に未取得のメールが有ると判断する（ステップ106参照）。ここで、再びメール取得のためメール保存メモリの空きの有無を確認する。ここでも、ＰＵＳＨメッセージ保存手段103にメール取得のための空きメモリが有るものとする。
【００８１】
受信端末１は、サーバ装置にＰＵＳＨメッセージ（メール）取得要求「NXT=００００２」を送信する。このＰＵＳＨメッセージ（メール）取得要求を受けたサーバ装置は、メールボックスに蓄積されるメールＩＤ：００００２のメールを図８に示すＰＵＳＨメッセージとして受信端末１に対して送信する。
【００８２】
その際に、サーバ上のメールボックスには、未送信のメールが存在しなくなるので、メールのＩＤ情報を、「X-EID：００００２／０００００」として送信する。
【００８３】
「００００２」は、送信しているメール本文のメールＩＤであり、後半の「０００００」はサーバ装置には、未送信で蓄積されているメールはないことを示している。
【００８４】
このＰＵＳＨメッセージ（メール）取得応答を受信した受信端末では、メールをＰＵＳＨメッセージ保存手段103のメール保存メモリに保存する（ステップ105参照）。
【００８５】
サーバ装置から送信されたデータを受信完了した受信端末１は、データ送受信手段101よりデータ受信完了応答をサーバ装置に対して送信する。
【００８６】
サーバ装置では、受信端末１からのデータ受信完了応答を受信したならば、受信端末１へのメールの送信が完了したものとし、メールボックスのメールＩＤ「００００２」のメールを削除する。
【００８７】
なお、ＰＵＳＨメッセージ管理手段106のＰＵＳＨメッセージの保存メモリに空きの有無の判定において、既読であり、かつ保護されていないＰＵＳＨメッセージであれば、上書き可能としてメモリに空きがあるものとしたが、ユーザ操作によりＰＵＳＨメッセージを削除されない限り、上書きを不可としても良い。
【００８８】
【発明の効果】
以上のように本発明によれば、携帯電話などのデータ保存メモリが比較的少ない携帯端末において、情報提供元から提供される任意のタイミングのＰＵＳＨメッセージを取りこぼすことなく受信できるサーバ装置及び移動端末からなるデータ伝送システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における受信装置の構成を示す図、
【図２】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第１のフローチャート、
【図３】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第２のフローチャート、
【図４】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第３のフローチャート、
【図５】本発明の実施の形態におけるＰＵＳＨメッセージ着信通知の例を示す図、
【図６】本発明の実施の形態におけるＰＵＳＨメッセージの取得要求メッセージの例を示す図、
【図７】本発明の実施の形態における受信端末が取得する第１のＰＵＳＨメッセージの例を示す図、
【図８】本発明の実施の形態における受信端末が取得する第２のＰＵＳＨメッセージの例を示す図、
【図９】本発明の移動端末とサーバ装置とがネットワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図である。
【符号の説明】
１ 受信装置（移動端末）
101 データ送受信手段
102 Ｗｅｂプロトコル処理手段
103 ＰＵＳＨメッセージ保存手段
104 ＰＵＳＨメッセージ要求処理手段
105 ＰＵＳＨメッセージ解析処理手段
106 ＰＵＳＨメッセージ管理手段
【発明の属する技術分野】
本発明は、サーバ装置及び移動端末からなるデータ伝送システムに関し、特にサーバからデータ保存メモリが少ないクライアント（移動端末）へＰＵＳＨ型メッセージを配送し得るよう構成したものである。
【０００２】
【従来の技術】
今日の高度情報化社会における情報通信では、インターネットを介して、ユーザがアクセス先のアドレスを指定することにより、いろいろな情報を即時に取得することが可能となってきた。
【０００３】
クライアントとサーバ間のデータ転送プロトコルとして、HTTP(Hypertext Transfer Protocol）が広く普及している。
【０００４】
HTTPは、クライアントからの取得要求に対してサーバが応答して、クライアントから要求された情報を通知することにより、ユーザは情報を取得することができる。
【０００５】
また、近年、クライアントから要求の起動をかけるＰＵＬＬ型のサービスだけでなく、情報送信元が任意のタイミングで、クライアントに情報を提供するＰＵＳＨ型のサービスが見られるようになってきた。
【０００６】
これにより、クライアントから情報送信要求の起動をかけなくとも、予め取り決めた情報提供元から、提供される情報が発生した時点で即時に情報が提供される。
【０００７】
例えば、特開平9-148994号公報に開示されている「データ放送システム及びその端末装置」では、放送データチャンネルを利用して、各種のデジタル信号を送信しており、放送データを受信する受信装置では、リアルタイムに情報を入手することが可能となっている。
【０００８】
【発明が解決しようとする課題】
しかしながら、携帯電話などのデータ保存メモリが比較的少ない携帯端末においては、情報提供元から提供される情報を保存しきれないといった問題が生じる。特に有料のサービス情報や、電子メールなどの重要な情報である場合には、この取りこぼしが問題となる。
【０００９】
上記の課題に鑑み本発明は、データ保存メモリが少ない携帯端末において、情報提供元から提供されるリアルタイムの情報を、確実に受信できるサーバ装置及び移動端末からなるデータ伝送システムを提供することを目的とする。
【００１０】
【課題を解決するための手段】
上記課題を解決するために本発明の請求項１記載の発明は、着信通知を受ける移動端末とサーバ装置とからなるデータ伝送システムであって、前記移動端末は、前記着信通知内に含まれるサーバ装置に配送メッセージが有ること示す信号をトリガとし、前記サーバ装置に対して前記配送メッセージ取得要求を行ない、前記配送メッセージ取得要求に基づき前記サーバ装置は配送メッセージ取得応答を送信し、前記移動端末は前記受信した配送メッセージ取得応答に含まれる次の未取得メッセージの有無を示す指示情報に基づき、次に未取得メッセージがあるならば、配送メッセージ保存領域確保ができるか否かを確認し、前記配送メッセージ保存領域を確保できたならば、前記サーバ装置に次の配送メッセージ取得要求を行ない、前記サーバ装置は前記次の未取得メッセージの配送を行なうことを特徴とする。
【００１６】
【発明の実施の形態】
以下に、本発明の実施の形態について図面を用いて詳細に説明する。図１は、本発明の実施の形態における移動端末（受信装置）の構成を示す図である。
【００１７】
図１において移動端末である受信装置１は、携帯電話網においてデータの送受信を行なうデータ送受信手段101と、受信装置とサーバ装置の間でサーバ装置に蓄積されたコンテンツメッセージを取得するWebプロトコルであるHTTPを処理するＷｅｂプロトコル処理手段102と、受信装置１が受信したＰＵＳＨメッセージを保存するＰＵＳＨメッセージ保存手段103と、ＰＵＳＨメッセージ要求処理手段104と、ＰＵＳＨメッセージ解析処理手段105と、ＰＵＳＨメッセージ管理手段106とから構成されている。
【００１８】
ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101が受信した着信通知に含まれるＰＵＳＨメッセージに関する内容に基づき、ＰＵＳＨメッセージ保存手段103にメモリの空きの有無を確認し、空きがあればＰＵＳＨメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。
【００１９】
ＰＵＳＨメッセージ解析処理手段105は、ＰＵＳＨメッセージ要求処理手段104により、情報提供元であるサーバ装置に対して要求されたＰＵＳＨメッセージ取得要求に対して、サーバ装置から返信されるＰＵＳＨメッセージの解析処理を行なう。
【００２０】
ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105が解析したＰＵＳＨメッセージをＰＵＳＨメッセージ保存手段103に保存し、またＰＵＳＨメッセージ要求処理手段104からＰＵＳＨメッセージの保存メモリに空きが有るか否かの問合せが有った時には、ＰＵＳＨメッセージ保存手段103にメモリの空きが有るか否かをチェックし、ＰＵＳＨメッセージ要求処理手段104に空きの有無結果を通知する。
【００２１】
図２〜図４は、本発明の実施の形態における上記受信装置のＰＵＳＨメッセージ取得における処理の流れを示すフローチャートである。図１の受信装置１のデータ送受信手段101がＰＵＳＨメッセージ着信通知を受信した後のＰＵＳＨメッセージ取得の処理の流れを以下に説明する。
【００２２】
ステップ101：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報にメールが含まれていたならば、ステップ102へ、そうでなければ、図３のステップ201へ進む。
【００２３】
ステップ102：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、メール保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103のメール保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメールメモリ空き状況の結果を通知する。メール保存メモリの空きが有る場合には、ステップ103へ、空きがなければ図３のステップ201へ進む。
【００２４】
ステップ103：ＰＵＳＨメッセージ要求処理手段104は、メールの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットでメール取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ104へ進む。
【００２５】
ステップ104：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、メールの取得が成功したならばステップ105へ、失敗したならば、図３のステップ201へ進む。
【００２６】
ステップ105：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103のメール保存用メモリに受信したメールを保存し、ステップ106へ進む。
【００２７】
ステップ106：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得のメールが有るか否かを示す情報に基づき、サーバに未取得のメールがあるならば、ステップ102へ、未取得のメールがなければ図３のステップ201へ進む。
【００２８】
これ以降、図３のフローチャートに従ってＰＵＳＨメッセージ取得の処理を説明する。
【００２９】
ステップ201：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報に第１の情報サービスメッセージが含まれていたならば、ステップ202へ、そうでなければ、図４のステップ301へ進む。
【００３０】
ステップ202：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、第１の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103の第１の情報サービスメッセージの保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメモリ空き状況の結果を通知する。第１の情報サービスメッセージの保存メモリの空きが有る場合には、ステップ203へ、空きがなければ図４のステップ301へ進む。
【００３１】
ステップ203：ＰＵＳＨメッセージ要求処理手段104は、第１の情報サービスメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで第１の情報サービスメッセージの取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ204へ進む。
【００３２】
ステップ204：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、第１の情報サービスメッセージの取得が成功したならばステップ205へ、失敗したならば、図４のステップ301へ進む。
【００３３】
ステップ205：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103の第１の情報サービスメッセージ保存用メモリに受信した第１の情報サービスメッセージを保存し、ステップ206へ進む。
【００３４】
ステップ206：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるコンテンツタイプの情報により、受信したＰＵＳＨメッセージの本文がHTML（Hypertext Markup Language） であったなら、ステップ207へ、そうでなければステップ210へ進む。
【００３５】
ステップ207：ＰＵＳＨメッセージ解析処理手段105は、HTMLコンテンツの中にイメージデータが挿入されることを示すインラインイメージの情報が検出され、このインラインイメージの情報に示されるイメージデータの取得要求をしていない場合には、ステップ208へ、そうでなければ、ステップ210へ進む。
【００３６】
ステップ208：ＰＵＳＨメッセージ解析処理手段105は、サーバ装置から受信したHTMLコンテンツの中に未取得のイメージデータが有ることをＰＵＳＨメッセージ要求処理手段104に通知する。ＰＵＳＨメッセージ要求処理手段104は、未取得のイメージデータの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102からの依頼されたデータをサーバ装置に送信し、ステップ209へ進む。
【００３７】
ステップ209：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデータの情報を保存してからステップ207へ進み、失敗したならば、受信データの保存をせずにステップ207へ進む。
【００３８】
ステップ210：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得の第１の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第１の情報サービスメッセージがあるならば、ステップ202へ、未取得の第１の情報サービスメッセージがなければ図４のステップ301へ進む。
【００３９】
これ以降、図４のフローチャートに従ってＰＵＳＨメッセージ取得の処理を説明する。
【００４０】
ステップ301：ＰＵＳＨメッセージ要求処理手段104は、データ送受信手段101から通知されたＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージ種別情報の判定を行なう。ＰＵＳＨメッセージ種別情報に第２の情報サービスメッセージが含まれていたならば、ステップ302へ、そうでなければ、処理を終了する。
【００４１】
ステップ302：ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ管理手段106に、第２の情報サービスメッセージの保存メモリの空きの有無を問い合わせる。ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ保存手段103の第２の情報サービスメッセージの保存メモリの空き状況を確認し、ＰＵＳＨメッセージ要求処理手段104にメモリ空き状況の結果を通知する。第２の情報サービスメッセージの保存メモリの空きが有る場合には、ステップ303へ、空きがなければ処理を終了する。
【００４２】
ステップ303：ＰＵＳＨメッセージ要求処理手段104は、第２の情報サービスメッセージの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで第２の情報サービスメッセージの取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ304へ進む。
【００４３】
ステップ304：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、第２の情報サービスメッセージの取得が成功したならばステップ305へ、失敗したならば、処理を終了する。
【００４４】
ステップ305：ＰＵＳＨメッセージ管理手段106は、ＰＵＳＨメッセージ解析処理手段105の要求に基づき、ＰＵＳＨメッセージ保存手段103の第２の情報サービスメッセージ保存用メモリに受信した第２の情報サービスメッセージを保存し、ステップ306へ進む。
【００４５】
ステップ306：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるコンテンツタイプの情報により、受信したＰＵＳＨメッセージの本文がHTML（Hypertext Markup Language） であったなら、ステップ307へ、そうでなければステップ310へ進む。
【００４６】
ステップ307：ＰＵＳＨメッセージ解析処理手段105は、HTMLコンテンツの中にイメージデータが挿入されることを示すインラインイメージの情報が検出され、このインラインイメージの情報に示されるイメージデータの取得要求をしていない場合には、ステップ308へ、そうでなければ、ステップ310へ進む。
【００４７】
ステップ308：ＰＵＳＨメッセージ解析処理手段105は、サーバ装置から受信したHTMLコンテンツの中に未取得のイメージデータが有ることをＰＵＳＨメッセージ要求処理手段104に通知する。ＰＵＳＨメッセージ要求処理手段104は、未取得のイメージデータの取得要求をＷｅｂプロトコル処理手段102に対して行なう。Ｗｅｂプロトコル処理手段102は、ＰＵＳＨメッセージ要求処理手段104からの要求に基づき、サーバとの間で取り決めたHTTPのフォーマットで取得要求データを作成し、データ送受信手段101にデータ送信依頼する。データ送受信手段101は、Ｗｅｂプロトコル処理手段102から依頼されたデータをサーバ装置に送信し、ステップ309へ進む。
【００４８】
ステップ309：データ送受信手段101は、サーバ装置からデータを受信したならば、Ｗｅｂプロトコル処理手段102に受信したデータを通知する。Ｗｅｂプロトコル処理手段102は、HTTPのフォーマットに従いサーバから応答されたＰＵＳＨメッセージを受信完了したならば、ＰＵＳＨメッセージ解析処理手段105にＰＵＳＨメッセージ受信完了を通知する。ＰＵＳＨメッセージ解析処理手段105は、Ｗｅｂプロトコル処理手段102からのＰＵＳＨメッセージ受信完了通知に基づき、インラインイメージ情報の取得が成功したならば、イメージデータの情報を保存してからステップ307へ進み、失敗したならば、受信データの保存をせずにステップ307へ進む。
【００４９】
ステップ310：ＰＵＳＨメッセージ解析処理手段105は、受信したＰＵＳＨメッセージに含まれるサーバに未取得の第２の情報サービスメッセージが有るか否かを示す情報に基づき、サーバに未取得の第２の情報サービスメッセージがあるならば、ステップ302へ、未取得の第２の情報サービスメッセージがなければ処理を終了する。
【００５０】
このように動作する受信装置１が図５のＰＵＳＨメッセージ着信通知を受信した時の具体的な動作を以下に説明する。
【００５１】
図５は、本発明の実施の形態におけるＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージに関する情報の例を示す図である。
【００５２】
ＰＵＳＨメッセージ着信通知は、ＰＵＳＨメッセージの分類を示すＰＵＳＨメッセージ種別情報とサーバ装置のＰＵＳＨメッセージ蓄積許容量満杯であるか否かを示すサーバ蓄積容量情報とから構成される。
【００５３】
本実施形態で示すＰＵＳＨメッセージの種別としては、メールと第１の情報提供サービスメッセージおよび第２の情報提供サービスメッセージとから構成される。そして、「１」がサーバ装置に未取得のＰＵＳＨメッセージが存在することを示し、「０」は、未取得のＰＵＳＨメッセージは存在しないことを示す。
【００５４】
今、ＰＵＳＨメッセージ種別情報は、「０００１」であるので、サーバ装置にある未取得のデータは、メールのみであることが示される。
【００５５】
ＰＵＳＨメッセージ蓄積容量情報は、それぞれのＰＵＳＨメッセージ種別に対応した付随情報である。そして、「１」が、サーバ装置のＰＵＳＨメッセージ蓄積容量が許容量満杯であることを示している。
【００５６】
今、サーバ蓄積容量情報は、「００００」であるのでサーバ装置には、ＰＵＳＨメッセージ蓄積の許容量に至っていないことが示される。
【００５７】
図５で示すＰＵＳＨメッセージ着信通知に含まれるＰＵＳＨメッセージに関する情報をデータ送受信手段101が受信したならば、ＰＵＳＨメッセージ要求処理手段104に通知される。ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ着信通知の内容を解析し、サーバに未取得のメールがあると判断する（ステップ101参照）。
【００５８】
ＰＵＳＨメッセージ要求手段104は、ＰＵＳＨメッセージ管理手段106にメールの保存メモリに空きが有るか否かを問い合わせる。ＰＵＳＨメッセージ管理手段106は、メールの保存メモリに空きの有無を確認する。ＰＵＳＨメッセージ保存手段103のメール保存メモリに、すでにメールが満杯であっても、既読であり、かつ保護されていないメールであれば、上書き可能としてメモリに空きがあるものとする。ここで、メールの保存メモリに空きが有ったならば、メールの取得要求を行なう（ステップ103参照）。
【００５９】
ＰＵＳＨメッセージ（メール）取得要求メッセージの具体例を図６に示す。ＰＵＳＨメッセージの取得要求メッセージは、HTTPのリクエストメッセージに従って構成されている。HTTPのリクエストメッセージには、処理の要求内容を示すメソッドと要求先の位置を示すＵＲＬ情報とHTTPのバージョン情報とから構成される。
【００６０】
図６のＰＵＳＨメッセージ（メール）取得要求メッセージでは、処理の要求内容を示すメソッドは「ＧＥＴ」であり、コンテンツの取得要求を示す。ＵＲＬ情報は、要求先のアドレスとＰＵＳＨメッセージの種別と取得要求ＰＵＳＨメッセージＩＤとを含んでいる。ＰＵＳＨメッセージの種別の「e_mes」は、取得要求するＰＵＳＨメッセージがメールであることを示す。取得要求ＰＵＳＨメッセージＩＤは「NXT=」以降の５桁の数字で表される。ただし、「０００００」は、ＰＵＳＨメッセージ取得要求の開始を示すＩＤである。「HTTP/1.0］は、HTTPのバージョンが1.0であることを示している。
【００６１】
図７は、サーバから取得したＰＵＳＨメッセージの第１の具体例であり、これは、HTTPのレスポンスのフォーマットに従っている。
【００６２】
HTTPのレスポンスデータは、レスポンス行とヘッダ部とボディ部である本文とから構成される。一行目は、レスポンス行であり、HTTPバージョン情報とリクエストに対する処理結果のステータスコードとステータスコードに付いての説明文とから構成される。
【００６３】
図７に示す例では、HTTPバージョンは、「HTTP/1.0」よりバージョン1.0であることが示されている。ステータスコード「２００」は、サーバ装置にてリクエストが正常に受付けられて、本文のデータはリクエストに対して有効なデータであることが示されている。「ＯＫ」は、ステータスコードの説明文である。
【００６４】
二行目から、＜ＣＲ＞＜ＬＦ＞（０ｘ０Ｄ，０ｘ０Ａ）で示される空行までが、ヘッダ部であり、「Content-Length」は、本文データのバイト数を示している。
【００６５】
「Content-Type」は、本文データのコンテンツ種別を示し、「text/plain」はプレインテキストであることが示されている。「Ｘ−」で始まるヘッダ情報は、ＰＵＳＨメッセージの取得のために拡張を行なったヘッダ情報である。
【００６６】
「X-EID」は、メールのＩＤを示す。前半部分の「００００１」が取得した本文のデータであるメールのＩＤを示し、後半部分の「００００２」が次にメール取得要求する時のメールＩＤを示す。
【００６７】
「Ｘ−Ｄ］は、日付情報であり、ＰＵＳＨメッセージ（メール）がサーバに到着した時間を示す。「199812171639」は、1998年12月17日16時39分を表す。
【００６８】
「Ｘ−Ｆ］は、メールの送信元アドレスを示す。
【００６９】
図８は、サーバから取得したＰＵＳＨメッセージの第二の具体例である。第一の具体例と同様にHTTPのレスポンスのフォーマットに従っている。ＰＵＳＨメッセージ取得のために拡張を行なったヘッダ情報である「X-EID」は、メールのＩＤを示し、前半部分の「００００２」が取得した本文のデータであるメールのＩＤを示す。後半部分は、次にサーバ装置に対して取得要求するメールのＩＤが示されるが、図８に示す「０００００」の場合には、サーバ装置に蓄積されている未取得のメールが存在しないことを示す。
【００７０】
図９は、本発明の移動端末とサーバ装置とがネットワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図であり、サーバ装置に受信端末１宛のメールが２件が蓄積された場合を例を示す。
【００７１】
サーバ装置は、メール２件のメールＩＤをそれぞれ、００００１と００００２とに割り当てる。サーバ装置は、受信端末１に未取得のＰＵＳＨメッセージ（メール）が蓄積されていることを受信端末１に通知するためにＰＵＳＨメッセージ着信通知を送信する。ここでは、図５に示すＰＵＳＨメッセージ着信通知を受信端末１に送信した例を示す。
【００７２】
受信端末１では、データ送受信手段101により受信した図５に示すＰＵＳＨメッセージ着信通知を基に、ＰＵＳＨメッセージ要求処理手段104は、ＰＵＳＨメッセージ種別情報のメールが「１」であるので、サーバ装置に未取得のメールが蓄積されていると判断し、ＰＵＳＨメッセージ管理手段106に対してメール取得のための空きメモリ有無を確認する。ここでは、ＰＵＳＨメッセージ保存手段103にメール取得のための空きメモリが有るものとする。
【００７３】
ＰＵＳＨメッセージ要求処理手段104は、メール取得のための空きメモリが確保できるので、図６に示すＰＵＳＨメッセージ（メール）取得の開始要求をサーバ装置に対して送信する（ステップ103参照）。
【００７４】
ＰＵＳＨメッセージ（メール）取得の開始要求を受けたサーバ装置では、第１のメールを図７に示すＰＵＳＨメッセージとして受信端末１に対して送信する。
【００７５】
「X-EID：００００１／００００２」は、サーバ装置から受信装置１に対して送信される第１のメールがサーバに蓄積したメールＩＤ「００００１」のメールに対応していることを示している。
【００７６】
また、後半部分の「００００２」は、サーバ装置には、未送信のメールが蓄積されていることを示し、次に受信装置１から取得要求する時のＰＵＳＨメッセージ（メール）取得要求のメールＩＤを「００００２」として要求することを指示する指示情報である。
【００７７】
ＰＵＳＨメッセージ（メール)取得応答を受けた受信端末では、ＰＵＳＨメッセージ保存手段103に確保されているメール保存メモリに受信したメールを保存する（ステップ105参照）。
【００７８】
サーバ装置から送信されたデータを受信完了した受信端末１は、データ送受信手段101よりデータ受信完了応答をサーバ装置に対して送信する。
【００７９】
サーバ装置では、受信端末１からのデータ受信完了応答を受信したならば、受信端末１へのメールの送信が完了したものとし、メールボックスのメールＩＤ「００００１」のメールを削除する。
【００８０】
受信端末１では、ＰＵＳＨメッセージ（メール）取得応答に含まれる次に要求すべきメールＩＤが「０００００」ではないので、サーバ装置に未取得のメールが有ると判断する（ステップ106参照）。ここで、再びメール取得のためメール保存メモリの空きの有無を確認する。ここでも、ＰＵＳＨメッセージ保存手段103にメール取得のための空きメモリが有るものとする。
【００８１】
受信端末１は、サーバ装置にＰＵＳＨメッセージ（メール）取得要求「NXT=００００２」を送信する。このＰＵＳＨメッセージ（メール）取得要求を受けたサーバ装置は、メールボックスに蓄積されるメールＩＤ：００００２のメールを図８に示すＰＵＳＨメッセージとして受信端末１に対して送信する。
【００８２】
その際に、サーバ上のメールボックスには、未送信のメールが存在しなくなるので、メールのＩＤ情報を、「X-EID：００００２／０００００」として送信する。
【００８３】
「００００２」は、送信しているメール本文のメールＩＤであり、後半の「０００００」はサーバ装置には、未送信で蓄積されているメールはないことを示している。
【００８４】
このＰＵＳＨメッセージ（メール）取得応答を受信した受信端末では、メールをＰＵＳＨメッセージ保存手段103のメール保存メモリに保存する（ステップ105参照）。
【００８５】
サーバ装置から送信されたデータを受信完了した受信端末１は、データ送受信手段101よりデータ受信完了応答をサーバ装置に対して送信する。
【００８６】
サーバ装置では、受信端末１からのデータ受信完了応答を受信したならば、受信端末１へのメールの送信が完了したものとし、メールボックスのメールＩＤ「００００２」のメールを削除する。
【００８７】
なお、ＰＵＳＨメッセージ管理手段106のＰＵＳＨメッセージの保存メモリに空きの有無の判定において、既読であり、かつ保護されていないＰＵＳＨメッセージであれば、上書き可能としてメモリに空きがあるものとしたが、ユーザ操作によりＰＵＳＨメッセージを削除されない限り、上書きを不可としても良い。
【００８８】
【発明の効果】
以上のように本発明によれば、携帯電話などのデータ保存メモリが比較的少ない携帯端末において、情報提供元から提供される任意のタイミングのＰＵＳＨメッセージを取りこぼすことなく受信できるサーバ装置及び移動端末からなるデータ伝送システムを提供することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における受信装置の構成を示す図、
【図２】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第１のフローチャート、
【図３】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第２のフローチャート、
【図４】本発明の実施の形態における受信装置のＰＵＳＨメッセージ取得における処理の流れを示す第３のフローチャート、
【図５】本発明の実施の形態におけるＰＵＳＨメッセージ着信通知の例を示す図、
【図６】本発明の実施の形態におけるＰＵＳＨメッセージの取得要求メッセージの例を示す図、
【図７】本発明の実施の形態における受信端末が取得する第１のＰＵＳＨメッセージの例を示す図、
【図８】本発明の実施の形態における受信端末が取得する第２のＰＵＳＨメッセージの例を示す図、
【図９】本発明の移動端末とサーバ装置とがネットワークを介してデータの伝送を行なう場合において、受信端末とサーバ装置間の処理を示すシーケンス図である。
【符号の説明】
１ 受信装置（移動端末）
101 データ送受信手段
102 Ｗｅｂプロトコル処理手段
103 ＰＵＳＨメッセージ保存手段
104 ＰＵＳＨメッセージ要求処理手段
105 ＰＵＳＨメッセージ解析処理手段
106 ＰＵＳＨメッセージ管理手段
Claims (1)
- 着信通知を受ける移動端末とサーバ装置とからなるデータ伝送システムであって、前記移動端末は、前記着信通知内に含まれるサーバ装置に配送メッセージが有ること示す信号をトリガとし、前記サーバ装置に対して前記配送メッセージ取得要求を行ない、前記配送メッセージ取得要求に基づき前記サーバ装置は配送メッセージ取得応答を送信し、前記移動端末は前記受信した配送メッセージ取得応答に含まれる次の未取得メッセージの有無を示す指示情報に基づき、次に未取得メッセージがあるならば、配送メッセージ保存領域確保ができるか否かを確認し、前記配送メッセージ保存領域を確保できたならば、前記サーバ装置に次の配送メッセージ取得要求を行ない、前記サーバ装置は前記次の未取得メッセージの配送を行なうことを特徴とするデータ伝送システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002152509A JP3833141B2 (ja) | 2002-05-27 | 2002-05-27 | サーバ装置及び移動端末からなるデータ伝送システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002152509A JP3833141B2 (ja) | 2002-05-27 | 2002-05-27 | サーバ装置及び移動端末からなるデータ伝送システム |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP01035299A Division JP3323144B2 (ja) | 1999-01-19 | 1999-01-19 | 移動端末 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003069646A JP2003069646A (ja) | 2003-03-07 |
| JP2003069646A5 JP2003069646A5 (ja) | 2006-03-09 |
| JP3833141B2 true JP3833141B2 (ja) | 2006-10-11 |
Family
ID=19194787
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002152509A Expired - Lifetime JP3833141B2 (ja) | 2002-05-27 | 2002-05-27 | サーバ装置及び移動端末からなるデータ伝送システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3833141B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4581890B2 (ja) * | 2005-07-26 | 2010-11-17 | ソニー株式会社 | 電子機器、記録制御方法、プログラムおよび記録媒体 |
| KR100695212B1 (ko) | 2006-03-09 | 2007-03-14 | 에스케이 텔레콤주식회사 | 푸쉬 메시지를 자동 저장하는 방법 및 이동통신 단말기 |
| JP6223850B2 (ja) * | 2014-02-07 | 2017-11-01 | 株式会社Ｎｔｔドコモ | 端末制御システム、端末制御サーバ、情報端末、及び端末制御方法 |
-
2002
- 2002-05-27 JP JP2002152509A patent/JP3833141B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003069646A (ja) | 2003-03-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9143382B2 (en) | Automatic download of web content in response to an embedded link in an electronic mail message | |
| EP0950969B1 (en) | Method and system for out-tasking conversions of message attachments | |
| JP3943467B2 (ja) | 中継装置、情報送信装置、および情報送信方法 | |
| US6618747B1 (en) | Electronic communication delivery confirmation and verification system | |
| US7194514B1 (en) | Stripping email attachment from an email message and adding into the email message a link to fetch the attachment | |
| US7171222B2 (en) | Multimedia messaging method and system for transferring multimedia content | |
| US7610043B2 (en) | Duplicate notification message processing method in terminal | |
| US7284160B2 (en) | Error messaging method in HTTP based communication systems | |
| EP1061701B1 (en) | Mobile terminal and data transmission scheme for receiving messages | |
| US20040014468A1 (en) | Mobile system for access to and visualisation of standard internet contents and services | |
| US20060089164A1 (en) | Method and system for transmitting MMS notification message | |
| JP2004509572A (ja) | 移動無線ネットワークにおけるデータ伝送コストアカウント方法 | |
| JP3833141B2 (ja) | サーバ装置及び移動端末からなるデータ伝送システム | |
| JP4252416B2 (ja) | 携帯通信端末、情報提供システム | |
| JP2006135662A (ja) | ファイル転送中継方法とファイル転送中継システム | |
| JP2002328874A (ja) | 電子メールの管理方法と管理装置 | |
| US20050193065A1 (en) | E-mail processing server | |
| US20050014513A1 (en) | Method and a system for data transmission, and a device | |
| EP1058423B1 (en) | Message delivery system | |
| KR100498325B1 (ko) | 단문 메시지 전송 방법 및 시스템 | |
| JP3704019B2 (ja) | 書留め機能を有する電文伝送方法及びその伝送システム | |
| US20040153522A1 (en) | System for delivering message and processing the message on server based on instruction from the client after the message delivering completed | |
| JP3412542B2 (ja) | データ配信方法 | |
| JP2002175253A (ja) | 電子メールの送信・受信システム | |
| AU2008100278A4 (en) | A messaging system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060119 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060418 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060614 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060718 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060718 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090728 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100728 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110728 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110728 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120728 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130728 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130728 Year of fee payment: 7 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313115 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313115 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |