JP2007133869A

JP2007133869A - 端末機とそのメッセージ処理方法

Info

Publication number: JP2007133869A
Application number: JP2006299411A
Authority: JP
Inventors: 範▲そく▼ ▲ぺ▼; Bum Suk Bae
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2005-11-02
Filing date: 2006-11-02
Publication date: 2007-05-31
Anticipated expiration: 2026-11-02
Also published as: CN1960516A; EP1783971B1; JP4884924B2; EP1783971A1; KR100677497B1; US7610043B2; CN1960516B; US20070100951A1

Abstract

【課題】発信側端末機が送信したデータを受信側端末機の応答があった場合に限って受信側端末機に送信するデータ送信システムにおいて、応答を要求するメッセージが受信側端末機に続けて受信されることを防止する。また、リトライメカニズムを適用したマルチメディアメッセージサービス提供システムにおいて、不要な重複通知メッセージを処理する。
【解決手段】マルチメディアメッセージングサービス（ＭＭＳ）をサポートする端末機のメッセージ処理方法において、マルチメディアメッセージの受信通知メッセージをＭＭＳサーバから受信し、該受信通知メッセージが重複通知メッセージである場合は、当該通知メッセージに相応するマルチメディアメッセージがダウンロードされていれば前記受信通知メッセージを削除し、重複通知メッセージでない場合は前記受信通知メッセージに対するレスポンスをＭＭＳサーバに送信する。
【選択図】図２

Description

本発明は、無線通信の端末機におけるメッセージ処理方法に関し、特に、マルチメディアメッセージングサービス（Multimedia messaging service：ＭＭＳ）をサポートする端末機において、重複通知メッセージを処理する方法に関する。

現在、無線端末機の市場では、端末機においてＩＰ処理及びインターネットサービスを制限なく提供できる無線データサービスのために、ＷＡＰ（WIRELESS APPLICATION PROTOCOL）１．ｘ標準が制定されて使用されている。ＷＡＰ方式は、低い帯域幅及び低い仕様の端末機に最適化した単純テキストメニュー方式のサービスを主に提供し、ＧＳＭやＩＳ−４１で利用されるＳＭＳ（SHORT MESSAGE SERVICE）も１００バイト程度の短文テキスト形式のメッセージ送信サービスを行っている。

ＭＭＳは、前記テキストベースのサービス提供から脱皮して、多様な高品質のマルチメディアの通信を可能にしたもので、そのシステムは、ＩＰネットワーク連動及びマルチメディアメッセージ処理のためのＭＭＳプロキシ／リレー（proxy/relay）サーバと、メッセージを保存して管理するサーバと、からなる。ＭＭＳプロキシ／リレーサーバは、現在ＩＰネットワークにおいて行われているメールサービス及びＷＡＰサービスとの連動のために、それぞれＳＭＴＰ（SIMPLE MESSAGE TRANSFER PROTOCOL）及びＨＴＴＰ（HYPER TEXT TRANSFER PROTOCOL）のプロトコルを用いている。また、他のＭＭＳプロキシ／リレーサーバとの連動のためにもＳＭＴＰを用いている。

図７は、従来のＭＭＳプロトコルスタックを示す図である。図７に示すように、ＭＭＳ端末機１０がＷＡＰゲートウェイ２０を介してＭＭＳプロキシ／リレーサーバ（以下、ＭＭＳサーバという）３０と連動するために、ＷＳＰ（WIRELESS SESSION PROTOCOL）とＨＴＴＰが用いられている。また、ＭＭＳサーバ３０は、他のＭＭＳサーバとの連動のために、メールプロトコルとして現在知られているＳＭＴＰを用いる。以下、このようなＭＭＳのサービス過程を説明する。

まず、メッセージ送信者がＳＭＴＰを使用したインターネット経由でマルチメディアファイル添付メールメッセージを送信しようとすると、当該送信側端末機は、対応するメール受信者プロファイルを参照してメールをパーシング（parsing）し、メール内のメディア（テキスト、イメージ）を受信側端末機に最適化して変換する。このときの受信者プロファイルの情報は、受信側端末機の使用に関する情報、すなわち、ＭＭＳサポート可否、解像度、サポート色数、メモリ容量などを含む。

次に、ＭＭＳサーバ３０が、メッセージが到着したことを受信側端末機に通知する。ここのときのＭＭＳサーバ３０は、ＨＴＴＰを用いてＷＡＰＧ／Ｗ（GATEWAY）２０との連動により受信側端末機に通知メッセージ（M-Notification.ind）を送信するか、又は、既存のＳＭＳＣ（SHORT MESSAGE SERVICE CENTER）との連動により文字メッセージ形式で到着を通知できる。これにより送られる通知メッセージは、マルチメディアメッセージが保存されているＵＲＩ（UNIFORM RESOURCE INDICATOR）を含み、そして、通知メッセージの管理のためにスケジューリング法を用いて、送信者の所望の時刻にメッセージを送信できる予約送信方式を用いることもある。

通知メッセージを受信した受信側端末機は、まず、その通知メッセージに対する応答メッセージ（M-Notify resp.ind）を返信することで、該当メッセージの受信、拒絶、又は削除を選択することができる。

受信側端末機がメッセージを受信するときは、ＨＴＴＰＧＥＴ方式で該当メッセージのＵＲＩを利用してＭＭＳサーバにアクセスする。次に、ＭＭＳサーバは、変換メッセージをＨＴＴＰにカプセル化してＷＳＰセッションを介し受信側端末機に送信する。この他に、送信側端末機で作成したマルチメディアメッセージ（M-send.req）をＭＭＳサーバがメールフォーマット又はＭＭＳメッセージに変換し、インターネット又はＭＭＳ対応端末機に送信することも可能である。

以上のような過程を図８に示す。図８は、従来のＭＭＳトランザクションの流れを示すチャートである。マルチメディアメッセージを送信しようとする送信側端末機１１がＭ−Ｓｅｎｄ．ｒｅｑメッセージをＭＭＳサーバ３０に送信すると、ＭＭＳサーバ３０は、これに対する確認のメッセージＭ−Ｓｅｎｄ．ｃｏｎｆを送信側端末機１１に返信すると共に、受信側端末機１２へ、マルチメディアメッセージの到着を通知する通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎを送信する。受信側端末機１２は、通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎに対する応答メッセージＭ−Ｎｏｔｉｆｙｒｅｓｐ．ｉｎｄをＭＭＳサーバ３０に返信するか、マルチメディア要求メッセージＧｅｔＲｅｑの要求によって実際のマルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆを受信することができる。受信側端末機１２がマルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆを受信した場合、それに対する確認のメッセージであるＭ−Ａｃｋｎｏｗｅｄｇｅ．ｉｎｄをＭＭＳサーバ３０に返信する。

その後、ＭＭＳサーバ３０から受信側端末機１２へ該当メッセージが送信されたか否かに関する情報が要求されると、ＭＭＳサーバ３０は、回答のメッセージＭ−Ｄｅｌｉｖｅｒｙ．ｉｎｄを送信側端末機１１に送信する。

現在、前述したようなマルチメディアサービスをサポートするために、ＭＭＳＣＶ（バージョン）１．０のＭＭＳサーバが使用されている。ＭＭＳＣＶ１．０のＭＭＳサーバ３０は、マルチメディアメッセージが到着したことを通知する通知メッセージを受信側端末機１２に送信するために、ＳＭＳプッシュ（PUSH）のみを使用する。このＭＭＳＣＶ１．０のＭＭＳサーバ３０は、通知メッセージが受信側端末機１２に到着しない確率は低いという理由で、通知メッセージが受信側端末機１２に実際に到着したか否かを確認しない。したがって、ＭＭＳＣＶ１．０のＭＭＳサーバ３０は、当該ＭＭＳサーバが送信した通知メッセージが実際には受信側端末機１２に到着していないことがあっても、通知メッセージの再送信を行わないので、メッセージ到着の信頼度が高いとは言えない。そこで最近、メッセージ到着の信頼度を向上させるために、ＭＭＳサーバのバージョンをＭＭＳＣＶ１．０からＭＭＳＣＶ（バージョン）１．Ｘに変更する傾向にある。

ＭＭＳＣＶ１．Ｘは、リトライメカニズム（Retry Mechanism）を使用する。リトライメカニズムは、ＭＭＳサーバの送信した通知メッセージが受信側端末機に到着したことを当該ＭＭＳサーバが確認するまで、リトライ周期で受信側端末機に通知メッセージを送信する。このリトライメカニズムによると、ＭＭＳサーバは、通知メッセージと同一のＵＲＩを有するＨＴＴＰＧＥＴ要求（マルチメディア要求メッセージ）をＭＭＳサーバが受信した場合と、通知メッセージと同一のトランザクションＩＤを有する通知メッセージ応答（応答メッセージ）をＭＭＳサーバが受信した場合と、において、通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎの送信を停止する。

すなわち、図９に示すように、ＭＭＳＣＶ１．０のＭＭＳサーバと、ＭＭＳＣＶ１．ＸのＭＭＳサーバとでは、サービス提供方式が異なるものである。

図９（ａ）は、ＭＭＳＣＶ１．０のＭＭＳサーバ３１と受信側端末機１２との間の通信過程を示す図である。このサーバは、ＳＭＳプッシュを使用して通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄを受信側端末機１２に送信する。ＭＭＳＣＶ１．０のＭＭＳサーバ３１は、リトライメカニズムを使用しないため、通知メッセージを送信するだけで、受信側端末機１２にその通知メッセージが実際に到着したかどうかに関与しない。

これに対して、図９（ｂ）は、ＭＭＳＣＶ１．ＸのＭＭＳサーバ３２と受信側端末機１２との間の通信過程を示す図である。ＭＭＳＣＶ１．Ｘのサーバ３２は、リトライメカニズムを使用して通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄを受信側端末機１２に送信する。従って、ＭＭＳサーバ３２は、端末機に通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄを送信した後、当通知メッセージに対する応答メッセージＮｏｔｉｆｙＲｅｓｐ．ｉｎｄ（あるいはマルチメディア要求メッセージ）を受信するまで、一定のリトライ周期（Retry Period）でＮｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄを受信側端末機１２に送信し続ける。

上記のように、ＭＭＳＣＶ１．ＸがＭＭＳサーバに適用されると、受信側端末機は、ＭＭＳサーバから通知メッセージを確実に受信することができるようになる。しかしながらその一方で、端末機の返信した応答メッセージやマルチメディア要求メッセージ（つまりレスポンス）が損失したような場合、端末機からのレスポンスを受信するまでＭＭＳサーバは続けて通知メッセージを送信するので、マルチメディアメッセージがダウンロードされる前に重複通知メッセージが端末機側に受信されてしまうことがある。すなわち、受信側端末機が多くのジャンクメッセージを受信するという問題が発生する。

また、端末機からのレスポンスが無い限りＭＭＳサーバは通知メッセージを送信し続けるので、タイムラグなどにより、マルチメディアメッセージがダウンロードされた後に重複通知メッセージが受信側に受信される場合がある。この場合、その前の通知メッセージは既に削除されているため、受信側端末機は、重複通知メッセージを新しい通知メッセージとして誤認してしまうことがある。するとユーザは、同一のマルチメディアメッセージに対して重複してコストを支払うことになる。

また、受信側端末機が重複通知メッセージを続けて受信すると、受信側端末機で通知メッセージを受信及び削除する過程を繰り返すために、バッテリの寿命が短縮する。

本発明は、このような問題を解決するために提案されたもので、本発明の目的は、発信側端末機が送信したデータを受信側端末機の応答（承認）があった場合に限って受信側端末機に送信するデータ送信システムにおいて、応答を要求するメッセージが受信側端末機に続けて受信されることを防止できるメッセージ処理方法を提供することにある。

また、本発明の他の目的は、リトライメカニズムを適用したマルチメディアメッセージサービス提供システムにおいて、不要な重複通知メッセージを処理することのできるメッセージ処理方法を提供することにある。

このような目的を達成するために、本発明は、マルチメディアメッセージングサービス（ＭＭＳ）をサポートする端末機のメッセージ処理方法において、マルチメディアメッセージの受信を通知する通知メッセージをＭＭＳサーバから受信する段階と、該受信通知メッセージが重複通知メッセージであるか否かの重複判断を行い、重複通知メッセージである場合は、当該通知メッセージに相応するマルチメディアメッセージがダウンロードされていれば前記受信通知メッセージを削除する段階と、前記重複判断の結果、重複通知メッセージでない場合は前記受信通知メッセージに対するレスポンスをＭＭＳサーバに送信する段階と、を含むことを特徴とする。

また、本発明に係るマルチメディアメッセージングサービス（ＭＭＳ）におけるメッセージ処理方法は、ＭＭＳサーバが、マルチメディアメッセージの受信を通知する第１の通知メッセージを端末機に送信する段階と、前記端末機が、前記第１の通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信する段階と、前記ＭＭＳサーバが、前記レスポンスをリトライ期間（Retry Period）内に受信できない場合に第２の通知メッセージを前記端末機に送信する段階と、前記端末機が、前記マルチメディアメッセージをダウンロードする前に前記第２の通知メッセージを受信した場合に、前記第２の通知メッセージの情報に基づいて前記第１の通知メッセージの情報を更新する段階と、前記端末機が、前記第２の通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信する段階と、を含むことを特徴とする。

また、本発明による端末機は、マルチメディアメッセージの到着を通知する通知メッセージを受信する受信部と、受信した通知メッセージが重複するか否か及び相応するマルチメディアメッセージがダウンロードされたか否かに応じて当該受信通知メッセージの削除及び保存を管理するデータベース管理モジュール、該データベース管理モジュールの指示に従って通知メッセージを保存するデータベース、受信した通知メッセージに対するレスポンスを提供するメッセージ処理モジュールを備えるメモリと、前記受信部及び前記メモリと連動してメッセージを処理するプロセッサと、を含むことを特徴とする。

本発明による端末機は、新しい通知メッセージだけでなく、重複通知メッセージに対してもレスポンスを送信することで、不要な重複メッセージを繰り返して受信することを防止できるという利点を有する。さらに、本発明による端末機は、不要な重複通知メッセージを受信しないため、不要なメッセージを受信して削除する過程を繰り返すことにより発生するバッテリ消耗を防止できる。

また、端末機がマルチメディアメッセージをダウンロードした後、その元になった通知メッセージを削除せずに所定時間保存することにより、マルチメディアメッセージをダウンロードした後、既に保存されていた通知メッセージと同一の通知メッセージを受信した場合、このメッセージが重複通知メッセージであることを端末機で把握することができる。従って、マルチメディアメッセージをダウンロードした後に受信された重複通知メッセージを新しい通知メッセージと誤認することにより同一のマルチメディアメッセージに対して重複課金されるという問題を、解決できる。

本発明の発明者は、ＭＭＳ端末機のメッセージ処理過程が、リトライメカニズムに従うＭＭＳサーバとの通信に適さないことを認識した。

まず、図１を参照して、ＭＭＳ端末機のメッセージ処理方法を説明する。

受信側端末機は、ＭＭＳサーバから通知メッセージを受信する（Ｓ１０１）。前記通知メッセージは、送信側端末機が送信したマルチメディアメッセージがＭＭＳサーバに到着したことを通知するメッセージである。通知メッセージを受信した端末機は、その通知メッセージが重複通知メッセージであるか否かを判断する（Ｓ１０２）。端末機は、マルチメディアメッセージをダウンロードするまで前記通知メッセージをデータベースに保存するため、受信された通知メッセージがデータベースに保存された通知メッセージと重複しているか否かを検索することにより、前記受信された通知メッセージが重複しているか否かを判断できる。

この判断の結果、前記通知メッセージが重複通知メッセージでない場合はデータベースに保存する（Ｓ１０４）。次に、端末機の動作モードが自動モード（Auto Retrieving Mode）であるかディファーモード（Deferred Retrieving Mode）であるかを確認し（Ｓ１０５）、レスポンスを返すことになる。すなわち、端末機が自動モードである場合は、通知メッセージを受信した後、実際のマルチメディアメッセージを要求するマルチメディア要求メッセージＧｅｔＲｅｑをＭＭＳサーバに送信し（Ｓ１０６）、端末機がディファーモードである場合は、通知メッセージを受信した後、通知メッセージを受信したことを通知する応答メッセージＭ−ＮｏｔｉｆｙＲｅｓｐ．ｉｎｄをＭＭＳサーバに送信する（Ｓ１０７）。一方、受信された通知メッセージが重複メッセージである場合はこれを削除する（Ｓ１０３）。

ここで、発明者は、上記メッセージ処理過程で２つの問題を認識した。

第１の問題は、段階Ｓ１０３で発生する。１番目の通知メッセージを受信した端末機がＭＭＳサーバにレスポンスを送信したけれども、そのレスポンスが損失してしまったとき、ＭＭＳサーバは、２番目の通知メッセージを送信する。これに応じる端末機は、段階Ｓ１０３で、重複する通知メッセージを無条件に無視するようになっているため、続けて重複通知メッセージを受信してしまう。すなわち、２番目の通知メッセージに対するレスポンスとして応答メッセージ又はマルチメディア要求メッセージをＭＭＳサーバに送信しなければ重複通知メッセージを防げないが、このような設定にはなっていない。

第２の問題は、段階Ｓ１０２で発生する。重複通知メッセージであるか否かを判断する段階Ｓ１０２で、マルチメディアメッセージをダウンロードした後に重複通知メッセージが受信された場合、その通知メッセージを重複メッセージと判断しないエラーが発生する。これは、端末機が、マルチメディアメッセージをダウンロードした後、保存されていた通知メッセージを削除するために起こる。

これに鑑みて本発明は、リトライメカニズムを使用するＭＭＳサーバからマルチメディアメッセージングサービスの提供を受ける端末機について、通知メッセージ処理方法を改善する。

図２は、本発明による通知メッセージ処理方法を示すフローチャートである。

まず、マルチメディアメッセージングサービスをサポートする端末機がＭＭＳサーバから送信された通知メッセージを受信する（Ｓ２０１）。この通知メッセージは、送信側端末機が送信したマルチメディアメッセージがＭＭＳサーバに到着したことを通知するメッセージである。通知メッセージを受信した端末機は、その通知メッセージが重複した通知メッセージであるか否かを判断する（Ｓ２０２）。全ての通知メッセージはトランザクション識別部（Transaction IDentification：ＴＩＤ）を有しており、ＭＭＳサーバは、一つのマルチメディアメッセージに対して同一のＴＩＤを持つ通知メッセージを送信する。従って、端末機は、受信された通知メッセージのＴＩＤが以前に受信された通知メッセージのＴＩＤと同一である場合、重複メッセージであると判断することができる。

この判断の結果、通知メッセージが新しいマルチメディアメッセージに対する通知メッセージであれば（重複通知メッセージでなければ）、これを保存する（Ｓ２０３）。本実施形態の場合、当該通知メッセージを２４時間、メッセージデータベースに保存する。従来のメッセージ処理方法によると、端末機は、通知メッセージをデータベースに保存した後、その通知メッセージに対応するマルチメディアメッセージがダウンロードされると、これを削除していた。従って、ネットワーク環境に異常があって、マルチメディアメッセージがダウンロードされた後に通知メッセージが受信されるような場合、ダウンロード前に受信されていた通知メッセージは削除されているため、ダウンロード後に受信された通知メッセージが重複メッセージであることを認識することができなかった。本発明では、このような場合に備えて通知メッセージを２４時間保存するように設定している。本例の保存時間は、ネットワーク環境が悪くても通知メッセージが１日以上経過して受信されることはないという経験から、メッセージ通信に予測される最大遅延時間として、２４時間を設定したものである。

一態様として、端末機は、アイドルモード状態で、メッセージデータベースに保存された通知メッセージのうち、受信されてから２４時間経過した通知メッセージの有無を検査して、２４時間経過した通知メッセージを削除する。また、他の態様として、端末機の電源が入ったときに（つまり端末機初期化時）、メッセージデータベースに保存された通知メッセージのうち、受信されてから２４時間経過したメッセージの有無を検査し、２４時間経過した通知メッセージを削除する。

一方、Ｓ２０２の判断の結果、受信された通知メッセージが重複通知メッセージであると判断された場合、相応するマルチメディアメッセージ（ＭＭ）がダウンロードされている否かを確認する（Ｓ２０４）。マルチメディアメッセージがダウンロードされている場合は、重複して受信された通知メッセージはジャンクメッセージに過ぎないので、直ちに削除する（Ｓ２０６）。しかしながら、相応するマルチメディアメッセージが未だダウンロードされていない場合は、メッセージデータベースに保存されている前通知メッセージの情報において受信時間のみを、重複通知メッセージの情報に更新する（Ｓ２０５）。ここで通知メッセージの受信時間のみを更新する理由は、メッセージデータベースに既に保存されているけれども、ユーザがそのマルチメディアメッセージを未だダウンロードして確認していない場合を考慮して、受信された最新のマルチメディアメッセージであることが分かるように、通知メッセージの受信時間のみを変更してこれをユーザに通知するためである。これにより、メッセージデータベースに同一のマルチメディアメッセージが重複して保存されることを防止できる。

段階Ｓ２０２から段階Ｓ２０６のプロセスは、端末機のデータベース管理部で行われる。すなわち、データベース管理部は、１）受信された通知メッセージを、データベースに保存されている通知メッセージと比較して、該受信通知メッセージが重複メッセージであるか否かを判別し、２）重複しない通知メッセージのみをデータベースに保存し、３）重複通知メッセージが受信された場合は、相応のマルチメディアメッセージがダウンロードされているか否かを判別し、４）マルチメディアメッセージがダウンロードされているのに重複通知メッセージが受信されると、これを削除し、５）マルチメディアメッセージがダウンロードされる前に重複通知メッセージが受信されると、前通知メッセージが受信された時間のみを更新するプロセスを行う。

データベース管理部は、受信された通知メッセージが重複メッセージであるか否かに応じて、通知メッセージを異なる方式で処理するが、これとは別途に、端末機は、受信された全ての通知メッセージに対して応答メッセージＭ−ＮｏｔｉＲｅｓｐ．ｉｎｄ又はマルチメディア要求メッセージＧｅｔＲｅｑをＭＭＳサーバに送信する。Ｍ−ＮｏｔｉＲｅｓｐ．ｉｎｄ又はＧｅｔＲｅｑをＭＭＳサーバに送信するプロセス（Ｓ２０７〜Ｓ２０９）は、端末機のメッセージ処理部で行われる。

まず、メッセージ処理部は、端末機が自動モードであるか、ディファーモードであるかを判断する（Ｓ２０７）。端末機は、自動モードである場合、ＭＭＳサーバにマルチメディア要求メッセージＧｅｔＲｅｑを送信し（Ｓ２０８）、ディファーモードである場合、応答メッセージＭ−ＮｏｔｉＲｅｓｐ．ｉｎｄを送信する（Ｓ２０９）。すなわち、端末機は、通知メッセージが受信されると、無条件にＭＭＳサーバへレスポンスとしてＧｅｔＲｅｑ又はＭ−ＮｏｔｉＲｅｓｐ．ｉｎｄを送信するので、ＭＭＳサーバ側において、端末機の通知メッセージ受信を確認できないために同一の通知メッセージを続けて送信することが、なくなる。

これによりＭＭＳサーバにおいては、同一のマルチメディアメッセージに対するＧｅｔＲｅｑ又はＭ−ＮｏｔｉＲｅｓｐ．ｉｎｄを複数受信することがあり得るが、同一のＴＩＤを有するＧｅｔＲｅｑ又はＮｏｔｉＲｅｓｐ．ｉｎｄが受信されるとＭＭＳサーバはこれを削除するため、問題とならない。

図３は、本発明による端末機の構成図であり、図３に示すように、端末機３００は、ＭＭＳサーバと通信する送受信部３１０と、受信されたメッセージの保存及び削除を管理するデータベース管理モジュール３３１、メッセージ送信を制御するメッセージ処理モジュール３３２、及びメッセージが保存されるメッセージデータベース３３３を備えたメモリ３３０と、メモリ３３０及び送受信部３１０と連動するプロセッサ３２０と、を含んで構成される。

送受信部３１０は、マルチメディアメッセージングサービスをサポートするサーバと通信して、通知メッセージＭ−Ｎｏｔｉｆｉｃａｔｉｏｎ．ｉｎｄ及びマルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆなどを受信することができ、通知メッセージに対する応答メッセージＭ−ＮｏｔｉｆｙＲｅｓｐ．ｉｎｄ及びマルチメディアメッセージ要求メッセージＧｅｔＲｅｑなどを送信できる。

メモリ３３０は、データベース管理モジュール３３１、メッセージ処理モジュール３３２、及びメッセージデータベース３３３を含み、データベース管理モジュール３３１及びメッセージ処理モジュール３３２は、プロセッサ３２０で実行可能な命令を持つ。

データベース管理モジュール３３１は、受信された通知メッセージが重複通知メッセージであるか否かを判断する段階と、重複通知メッセージでない場合、メッセージデータベース３３３に保存する段階と、重複通知メッセージである場合、相応するマルチメディアメッセージがダウンロードされているか否かを判断する段階と、相応のマルチメディアメッセージがダウンロードされている場合、当該受信通知メッセージを削除する段階と、相応のマルチメディアメッセージがダウンロードされていない場合、当該受信通知メッセージと重複する前通知メッセージの受信時間を更新する段階と、を実行する命令を持つ。

データベース管理モジュール３３１は、受信された通知メッセージが重複通知メッセージであるか否かを判断するために、該受信通知メッセージと同一のＴＩＤを有するメッセージがメッセージデータベース３３３に保存されているか否かを検索する。受信通知メッセージと同一のＴＩＤを有するメッセージが検出されると、当該受信通知メッセージは重複メッセージである。また、データベース管理モジュール３３１は、アイドルモードのとき又は電源が入ったときにメッセージデータベース３３３を検索し、受信してから２４時間以上経過したメッセージを削除する。この２４時間のメッセージ保管期間は、ネットワーク環境が劣悪な場合もメッセージが２４時間以内に到着するという経験から設定された時間であり、適宜変更可能である。

メッセージ処理モジュール３３２は、端末機が自動モードであるかディファーモードであるかを判断する段階と、自動モードである場合、ＭＭ要求メッセージＧｅｔＲｅｑを送信する段階と、ディファーモードである場合、応答メッセージＭ−ＮｏｔｉｆｙＲｅｓｐ．ｉｎｄを送信する段階と、を実行する命令を持つ。メッセージ処理モジュール３３２は、受信された通知メッセージが重複通知メッセージであるか否かを判断しないため、全ての通知メッセージに対してＭＭＳサーバへレスポンスする。

以下、図４〜図６を参照して、自動モードの端末機が重複通知メッセージを受信する場合のメッセージ処理方法について説明する。

図４は、重複通知メッセージが受信される第１シナリオ及びメッセージ処理方法を示す図である。

送信側端末機（図示せず）からマルチメディアメッセージを受信したＭＭＳサーバ１００は、第１の通知メッセージＮｏｔｉ（M-Notification.ind）１を受信側端末機２００に送信する（Ｓ３０１）。これに応じて受信側端末機２００が、第１のマルチメディア要求メッセージＧｅｔＲｅｑ１をＭＭＳサーバ１００に送信する（Ｓ３０２）。しかしながら、そのＧｅｔＲｅｑ１が損失してしまい、ＭＭＳサーバ１００に到着しないままリトライ期間が経過すると、ＭＭＳサーバ１００は、再び第２の通知メッセージＮｏｔｉ２を受信側端末機２００に送信する（Ｓ３０３）。Ｎｏｔｉ２を受信した受信側端末機２００は、これと重複する前通知メッセージ（つまり第１の通知メッセージ）の受信時間を更新し（Ｓ３０４）、ＭＭＳサーバ１００に第２のマルチメディア要求メッセージＧｅｔＲｅｑ２を送信する（Ｓ３０５）。

受信側端末機２００がＭＭＳサーバ１００にＭＭ要求メッセージＧｅｔＲｅｑ１を送信したけれども、ＭＭＳサーバ１００でこれを受信できずにいるので、重複通知メッセージであるという理由で受信側端末機２００がＧｅｔＲｅｑ２をＭＭＳサーバ１００に送信しなければ、ＭＭＳサーバ１００は続けて重複通知メッセージを発信し、受信側端末機２００はこれを受信することになる。従って、受信側端末機２００は、重複通知メッセージに対してもＧｅｔＲｅｑを送信する。

図５は、重複通知メッセージが受信される第２シナリオ及びメッセージ処理方法を示す図である。

受信側端末機２００がＭＭＳサーバ１００から第１の通知メッセージＮｏｔｉ１を受信すると（Ｓ４０１）、受信側端末機２００は、第１のＭＭ要求メッセージＧｅｔＲｅｑ１をＭＭＳサーバ１００に送信する（Ｓ４０２）。ＭＭＳサーバ１００は、Ｎｏｔｉ１を送信した後、リトライ期間中にＧｅｔＲｅｑ１を受信できなかったため、第２の通知メッセージＮｏｔｉ２を送信している（Ｓ４０３）。受信側端末機２００は、重複通知メッセージＮｏｔｉ２を受信したのが、マルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆを受信する前であるため、当該受信通知メッセージと重複する前通知メッセージ（第１の通知メッセージ）の受信時間のみを更新する（Ｓ４０４）。そして、受信側端末機２００は、ＭＭＳサーバ１００にマルチメディア要求メッセージを再び送信する（Ｓ４０５）。これにより、ＭＭＳサーバ１００にはＭＭ要求メッセージが重複して届くことになるが、ＭＭＳサーバ１００がＴＩＤの比較により重複するマルチメディア要求メッセージを無視するため、問題とならない。つまり、受信側端末機２００には、ＧｅｔＲｅｑ１に応じたマルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆのみが提供される（Ｓ４０６）。

第２シナリオの場合、原則的には、重複通知メッセージを受信した受信側端末機２００がＭＭＳサーバ１００に第２のＭＭ要求メッセージＧｅｔＲｅｑ２を送信する必要はない。しかしながら、ＧｅｔＲｅｑ１が損失したためにＭＭＳサーバ１００が重複通知メッセージを送信したのか、それとも、ＧｅｔＲｅｑ１が予想時間より遅く（リトライ期間が経過して）到着したためにＭＭＳサーバ１００が重複通知メッセージを送信したのか、受信側端末機２００では分からない。したがって、受信側端末機２００は、Ｎｏｔｉ２を受信すると、無条件にマルチメディア要求メッセージをＭＭＳサーバ１００に送信する。すなわち、受信側端末機２００は、第１シナリオと第２シナリオを同様に取り扱う。

図６は、重複通知メッセージが受信される第３シナリオ及びメッセージ処理方法を示す図である。

受信側端末機２００が第１の通知メッセージＮｏｔｉ１を受信すると（Ｓ５０１）、ＭＭ要求メッセージＧｅｔＲｅｑ１をＭＭＳサーバに送信する（Ｓ５０２）。しかしながら、リトライ期間中にＧｅｔＲｅｑ１を受信できなかったのでＭＭＳサーバ１００は、再び通知メッセージＮｏｔｉ２を受信側端末機２００に送信する（Ｓ５０３）。その次に、ＭＭＳサーバ１００がＧｅｔＲｅｑ１を受信しているので、マルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆが受信側端末機２００に送信されている（Ｓ５０４）。

このときの受信側端末機２００は、マルチメディアメッセージＭ−ｒｅｔｒｉｅｖｅ．ｃｏｎｆを受信した後に重複通知メッセージＮｏｔｉ２を受信することになり、この場合は、重複通知メッセージＮｏｔｉ２を保存せずに直ちに削除する（Ｓ５０５）。マルチメディアメッセージがダウンロードされた後もＮｏｔｉ１が削除されないため、Ｎｏｔｉ２が重複通知メッセージであることを把握することができる。

受信側端末機２００が、マルチメディアメッセージをダウンロードした後に重複通知メッセージを受信した場合、ＭＭ要求メッセージＧｅｔＲｅｑを送信する必要はないが、この場合でもＧｅｔＲｅｑを送信するようにしてもよい。これは、重複ＭＭ要求メッセージを受信した場合のＭＭＳサーバ１００がこれを直ちに削除し、同一のマルチメディアメッセージを送信しないようになっているからである。

リトライメカニズムを使用するＭＭＳサーバと通信する端末機のメッセージ処理方法を示すフローチャート。本発明による端末機の通知メッセージ処理方法を示すフローチャート。本発明による端末機の要部構成図。本発明によるメッセージ処理方法において重複通知メッセージが受信される第１シナリオを示すタイムチャート。本発明によるメッセージ処理方法において重複通知メッセージが受信される第２シナリオを示すタイムチャート。本発明によるメッセージ処理方法において重複通知メッセージが受信される第３シナリオを示すタイムチャート。従来のＭＭＳプロトコルスタックを示す図。従来のＭＭＳトランザクションの流れを示すタイムチャート。ＭＭＳＣＶ１．０のＭＭＳサーバ及びＭＭＳＣＶ１．ＸのＭＭＳサーバのサービス提供方式を示すタイムチャート。

Claims

マルチメディアメッセージングサービス（ＭＭＳ）をサポートする端末機のメッセージ処理方法において、
マルチメディアメッセージの受信を通知する通知メッセージをＭＭＳサーバから受信する段階と、
該受信通知メッセージが重複通知メッセージであるか否かの重複判断を行い、重複通知メッセージである場合、当該通知メッセージに相応するマルチメディアメッセージがダウンロードされていれば前記受信通知メッセージを削除する段階と、
前記重複判断の結果、重複通知メッセージでない場合、前記受信通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信する段階と、
を含むことを特徴とする端末機のメッセージ処理方法。
前記受信通知メッセージを削除する段階において、前記受信通知メッセージの削除と共に、当該受信通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信することを特徴とする請求項１に記載の端末機のメッセージ処理方法。
前記受信通知メッセージを削除する段階において、当該通知メッセージに相応するマルチメディアメッセージがダウンロードされていなければ、前記受信通知メッセージと重複する前通知メッセージの受信時間を更新することを特徴とする請求項１に記載の端末機のメッセージ処理方法。
前記重複判断の結果、重複通知メッセージでない場合、前記受信通知メッセージを一定期間保存する段階をさらに含むことを特徴とする請求項１に記載の端末機のメッセージ処理方法。
前記一定期間として、メッセージ通信に予測される最大遅延時間を設定し、
該最大遅延時間を経過した保存メッセージを削除する段階をさらに含むことを特徴とする請求項４に記載の端末機のメッセージ処理方法。
前記保存メッセージを削除する段階を、アイドルモードで実行することを特徴とする請求項５に記載の端末機のメッセージ処理方法。
前記保存メッセージを削除する段階を、端末機初期化時に実行することを特徴とする請求項５に記載の端末機のメッセージ処理方法。
前記重複判断の結果、重複通知メッセージでない場合、メッセージ通信に予測される最大遅延時間を保存期間として、前記受信通知メッセージを保存する段階をさらに含むことを特徴とする請求項１に記載の端末機のメッセージ処理方法。
前記重複判断において、前記受信通知メッセージのトランザクション識別部（ＴＩＤ）を、当該受信通知メッセージの前に受信済みの通知メッセージのトランザクション識別部と比較することで、重複判断することを特徴とする請求項１に記載の端末機のメッセージ処理方法。
マルチメディアメッセージングサービス（ＭＭＳ）におけるメッセージ処理方法において、
ＭＭＳサーバが、マルチメディアメッセージの受信を通知する第１の通知メッセージを端末機に送信する段階と、
前記端末機が、前記第１の通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信する段階と、
前記ＭＭＳサーバが、前記レスポンスをリトライ期間内に受信できない場合に第２の通知メッセージを前記端末機に送信する段階と、
前記端末機が、前記マルチメディアメッセージをダウンロードする前に前記第２の通知メッセージを受信した場合に、前記第２の通知メッセージの情報に基づいて前記第１の通知メッセージの情報を更新する段階と、
前記端末機が、前記第２の通知メッセージに対するレスポンスを前記ＭＭＳサーバに送信する段階と、
を含むことを特徴とするメッセージ処理方法。
前記端末機が前記第１の通知メッセージの情報を更新する段階において、前記第１の通知メッセージの受信時間を前記第２の通知メッセージの受信時間に更新することを特徴とする請求項１０に記載のメッセージ処理方法。
前記第２の通知メッセージに対するレスポンスは、前記端末機が自動モードである場合、マルチメディアメッセージを要求するマルチメディア要求メッセージであることを特徴とする請求項１０に記載のメッセージ処理方法。
前記第２の通知メッセージに対するレスポンスは、前記端末機がディファーモードである場合、当該通知メッセージに対する受信確認の応答メッセージであることを特徴とする請求項１０に記載のメッセージ処理方法。
前記端末機が、前記第１の通知メッセージを、メッセージ通信に予測される最大遅延時間保存する段階をさらに含むことを特徴とする請求項１０に記載のメッセージ処理方法。
前記端末機が、前記マルチメディアメッセージをダウンロードした後に前記第２の通知メッセージを受信した場合に、当該第２の通知メッセージを削除する段階をさらに含むことを特徴とする請求項１０に記載のメッセージ処理方法。
マルチメディアメッセージの到着を通知する通知メッセージを受信する受信部と、
受信した通知メッセージが重複するか否か及び相応するマルチメディアメッセージがダウンロードされたか否かに応じて当該受信通知メッセージの削除及び保存を管理するデータベース管理モジュール、該データベース管理モジュールの指示に従って通知メッセージを保存するデータベース、受信した通知メッセージに対するレスポンスを提供するメッセージ処理モジュールを備えるメモリと、
前記受信部及び前記メモリと連動してメッセージを処理するプロセッサと、
を含んで構成されることを特徴とするマルチメディアメッセージングサービスをサポートする端末機。
前記データベース管理モジュールは、受信した通知メッセージが重複通知メッセージである場合、
相応するマルチメディアメッセージがダウンロードされていれば、当該受信通知メッセージを削除する段階と、
相応するマルチメディアメッセージがダウンロードされていなければ、当該受信通知メッセージと重複する前通知メッセージの情報を、前記受信通知メッセージの情報に更新する段階と、
を前記プロセッサに実行させる命令を持つことを特徴とする請求項１６に記載のマルチメディアメッセージングサービスをサポートする端末機。
前記データベース管理モジュールは、受信した通知メッセージが重複通知メッセージでない場合、当該受信通知メッセージを前記データベースに保存する段階を、前記プロセッサに実行させる命令を持つことを特徴とする請求項１６に記載のマルチメディアメッセージングサービスをサポートする端末機。
前記データベース管理モジュールは、受信した通知メッセージと同一のトランザクション識別部を有する通知メッセージが前記データベースに保存されている場合に、重複通知メッセージが受信されたと判断する段階を、前記プロセッサに実行させる命令を持つことを特徴とする請求項１６に記載のマルチメディアメッセージングサービスをサポートする端末機。
前記メッセージ処理モジュールは、受信した通知メッセージが重複通知メッセージであるか否かに関係なく、当該受信通知メッセージに対するレスポンスを発信する段階を、前記プロセッサに実行させる命令を持つことを特徴とする請求項１６に記載のマルチメディアメッセージングサービスをサポートする端末機。