説明

複数の受信先にマルチメディアメッセージを送信する方法およびシステム

【課題】要求メッセージが複数の受信先に宛てられている場合においても対応可能な、異なるMMS環境間の改良型MMSメッセージングインターフェイスを提供する。
【解決手段】複数の受信先に宛てられたメッセージを受信するステップと、各受信先の状態の表示を決定するステップと、確認応答であって、少なくとも1つの受信先および前記少なくとも1つの受信先の関連する状態を識別する少なくとも1つのメッセージを含む確認応答を送信するステップとを含む。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数の受信先へのメッセージ転送送信に関し、限定するものではないが、特に異なるマルチメディアメッセージングサービス環境におけるマルチメディアメッセージングサービスリレー/サーバ間でのマルチメディアメッセージ転送に関する。
【背景】
【0002】
3GPP TS23.140バージョン6.1.0(またはそれ以降)において、MM4インターフェイスおよびプロトコルセットは、1つのマルチメディアメッセージングサービス環境(MMSE)のマルチメディアメッセージングサービス(MMS)リレー/サーバから、異なるMMSEの別のMMSリレー/サーバへの、複数の受信先を有するメッセージの送信をサポートしている。
【0003】
3GPP TS23.140バージョン6.1.0では、マルチメディアサービスネットワークアーキテクチャ(MMSNA)内において基準点を識別するマルチメディアサービス(MMS)リファレンスアーキテクチャが定義されている。これらの基準点は、MMSリファレンスアーキテクチャにおけるインターフェイスを表す。8つの基準点が定められており、MM1からMM8と呼ばれる。これらの基準点はそれぞれ、MMSユーザエージェントとMMSリレー/サーバとの間、MMSリレーとMMSサーバとの間、MMSリレー/サーバと外部(レガシー)メッセージングシステムとの間、MMSリレーサーバと別のMMSE内にある別のMMSリレーサーバとの間、MMSリレー/サーバとホームロケーションレジスタとの間、MMSリレー/サーバとMMSユーザデータベースとの間、MMSリレー/サーバとMMS VAS(付加価値サービス)アプリケーションとの間、およびMMSリレー/サーバと請求システムとの間のインターフェイスを表す。
【0004】
MMSリレー/サーバと別のMMSE内にある別のMMSリレー/サーバとの間の基準点は、MM4と呼ばれる。
【0005】
3GPP TS23.140バージョン6.1.0は、第1のMMSEにあるMMSリレー/サーバと第2のMMSEにあるMMSリレー/サーバとの間のメッセージ送信をサポートするためのMM4インターフェイスおよびプロトコルセットを定義している。このインターフェイスおよびプロトコルにより、複数の受信先を有する各MMSリレー/サーバ間でのメッセージ送信が可能となる。3GPP TS23.140バージョン6.1.0の前は、MM1基準点によって提供されるインターフェイス、つまり低バンド幅無線インターフェイスにおける複数の受信先を相手にメッセージを送信することが可能であった。しかしながら、通例容量に問題のなかったコアネットワークにおいて、メッセージは各受信先へ個別に転送されていた。
【0006】
3GPP TS23.140バージョン6.1.0では、メッセージは、発信元MMSリレー/サーバから受信先MMSリレー/サーバへのMM4_forward.REQプロトコルデータユニット(PDU)メッセージ内で複数の受信先へ送信される。このメッセージは、メッセージを独自に識別し、すべての受信先に適用できる「メッセージID」情報要素を運搬する。このメッセージは、MMS制御情報およびマルチメディアコンテンツを含む。
【0007】
発信元MMSリレー/サーバは、任意で受信先MMSリレー/サーバにMM4でのメッセージ転送に確認応答するよう要求することができる。次いで、受信先MMSリレー/サーバは、MM4_forward.RES PDUメッセージに応答し、これにより要求の状態が伝えられる。しかしながら、要求メッセージが複数の受信先に宛てられている場合、受信先MMSリレー/サーバは限られた応答メッセージで応答することしかできない。応答メッセージは、そのメッセージに特有のメッセージIDであるが、対象とするいかなる受信先にも特有ではないメッセージIDのみを含む。アドレス指定失敗を引き起こす受信先の表示は、応答メッセージに含まれない。
【0008】
本発明は、改良型メッセージングインターフェイスを提供することを目的とする。特に、本発明の実施形態は、異なるMMS環境間の改良型MMSメッセージングインターフェイスを提供することを目的とする。
【非特許文献1】3GPP TS23.140バージョン6.1.0
【摘要】
【0009】
本発明の一側面において、複数の受信先に宛てられたメッセージを受信するステップと、各受信先の状態の表示を決定するステップと、少なくとも1つの受信先および前記少なくとも1つの受信先の関連する状態を識別する少なくとも1つのメッセージを含む確認応答を送信するステップとを含む、複数の受信先にメッセージを送信する方法が提供される。
【0010】
前記各受信先の状態は、当該受信先への前記メッセージの送信状態を示し得る。前記複数の受信先に宛てられたメッセージを受信するステップは、複数の受信先への前記メッセージの送信要求を受信するステップを含むことができる。複数の受信先への前記メッセージの送信要求は、複数の受信先に宛てられたメッセージの受信に内在し得る。複数の受信先への前記メッセージの送信要求は、複数の受信先に宛てられたメッセージの受信に埋め込まれてよい。
【0011】
前記確認応答は、それぞれ少なくとも1つの受信先を識別しそれぞれ対応する複数の状態のうち1つを含む複数のメッセージを含むことができる。前記確認応答は、受信先の複数のセットおよび対応する複数の状態であって、受信先のセットと関連する状態である各状態を識別する少なくとも1つのメッセージを含んでよい。各セットは、1つ以上の受信先を含んでよい。
【0012】
前記状態は、無効な受信先アドレス、不完全な送信、受け入れられなかったメッセージの内容、または成功した送信のうちの1つを示すことができる。前記状態は、不明な状態を示してよい。
【0013】
前記方法は、不完全な送信を示す確認応答メッセージの受信に応答して、前記確認応答メッセージにおいて識別された少なくとも1つの受信先へ前記メッセージを再送信するステップをさらに含むことができる。
【0014】
少なくとも1つの受信先および前記少なくとも1つの受信先への前記送信の状態を識別する前記少なくとも1つのメッセージは、前記状態が前記識別された受信先のすべてに共通である複数の受信先を識別することができる。
【0015】
前記方法は、メッセージ発信元から前記メッセージの送信要求を受信するステップと、前記メッセージ発信元へ前記確認応答を送信するステップとをさらに含むことができる。
【0016】
前記メッセージ発信元はメールボックスを有してよく、前記確認応答は前記メールボックスへ送信される。前記確認応答は、前記メッセージ発信元に各受信先の配信状況を提供してよい。
【0017】
少なくとも1つのメッセージが、セッション開始プロトコルを使用して送信され得る。前記メッセージはマルチメディアサービスメッセージであってよい。
【0018】
さらなる側面において、本発明は、マルチメディアメッセージを複数の受信先へ送信する方法であって、発信元マルチメディアサービス要素において、異なるマルチメディアサービス環境で記メッセージを複数の受信先へ送信せよとの要求を受信するステップと、前記発信元マルチメディアサービス要素から前記異なるマルチメディアサービス環境の受信先マルチメディアサービス要素へ、前記受信先のIDを含む前記マルチメディアメッセージを送信するステップと、前記受信先マルチメディアサービス要素において各受信先の状態を決定するステップと、前記受信先マルチメディアサービス要素から前記発信元マルチメディアサービス要素への確認応答であって、少なくとも1つの受信先および前記受信先の状態を識別する少なくとも1つのメッセージを含む確認応答を送信するステップとを含む方法を提供する。
【0019】
前記異なるマルチメディアサービス環境の複数の受信先は、前記異なるマルチメディアサービス環境の加入者であってよい。
【0020】
前記異なるマルチメディアサービス環境における複数の受信先への前記メッセージの送信要求は、前記発信元マルチメディアサービス環境の1つ以上の受信先への前記メッセージの送信要求をさらに含んでよい。異なるマルチメディアサービス環境における複数の受信先への前記メッセージの送信要求は、またさらに異なるマルチメディアサービス環境の1つ以上の受信先への前記メッセージの送信要求をさらに含んでよい。
【0021】
前記方法は、不完全な送信状態を示す確認応答メッセージの受信に応答して、前記発信元マルチメディアサービス要素から、異なるマルチメディアサービス環境の受信先マルチメディアサービス要素へ前記マルチメディアメッセージを再送信するステップであって、前記再送信されたメッセージは前記不完全な送信状態に関連する前記受信先を識別するステップをさらに含んでよい。
【0022】
さらなる側面において、本発明は、少なくとも1つの受信先を識別する情報要素を含み、前記メッセージにおける状態が前記少なくとも1つの受信先に当てはまる、3GPP TS23.140準拠のMM4_forward.RESプロトコルデータユニットメッセージ形式を提供することができる。前記情報要素は複数の受信先を識別してよく、前記メッセージにおける状態は前記複数の受信先に当てはまる。
【0023】
またさらなる側面において、本発明は、複数の受信先に宛てられたメッセージを受信する手段と、各受信先の状態の表示を決定する手段と、少なくとも1つの受信先および前記少なくとも1つの受信先の前記関連する状態を識別する少なくとも1つのメッセージを含む確認応答を送信する手段とを含むネットワーク要素を提供する。
【0024】
前記確認応答を送信する手段は、少なくとも1つの受信先を識別する複数のメッセージを送信し、前記複数のメッセージのそれぞれは、対応する複数の状態のうち1つを含むように適応せしめられることができる。
【0025】
さらにもう1つの側面において、本発明は、複数の受信先に宛てられたメッセージを受信する手段と、そのようなメッセージを前記複数の受信先のIDとともに転送する手段と、少なくとも1つの受信先および前記少なくとも1つの受信先の関連する状態を識別する少なくとも1つのメッセージを含む確認応答メッセージを受信する手段とを含むネットワーク要素を提供する。
【0026】
前記ネットワーク要素は、送信失敗に対応する状態に関連するそれらの受信先を識別するそのようなメッセージを再転送する手段をさらに含んでよい。
【0027】
本発明は、発信元マルチメディアサービス要素が、異なるマルチメディアサービス環境における複数の受信先へのメッセージの送信要求を受信する手段と、前記発信元マルチメディアサービス要素から前記異なるマルチメディアサービス環境の受信先マルチメディアサービス要素へ前記マルチメディアメッセージを送信する手段とを有し、前記受信先マルチメディアサービス要素が、各受信先の状態を決定する手段と、前記受信先マルチメディアサービス要素から前記発信元マルチメディアサービス要素へ確認応答を送信する手段とを含み、前記確認応答が少なくとも1つの受信先および前記受信先の状態を識別する少なくとも1つのメッセージを含む、マルチメディアメッセージングシステムをまたさらに提供する。
【0028】
前記マルチメディアサービス要素は、マルチメディアサービスリレー、サーバ、またはリレー/サーバを含んでよい。
【図面の簡単な説明】
【0029】
【図1】異なるマルチメディアサービス環境のインターワーキングを図示している。
【図2】図1の環境に適用される本発明の実施形態におけるメッセージングフローを図示している。
【図3】図2のメッセージングフローに関連する方法段階を図示している。
【実施形態の詳細な説明】
【0030】
以下、添付図面を例として参照し、本発明の実施形態を説明する。
【0031】
本明細書では、特定の用途例を参照することにより本発明を説明する。しかしながら、本発明はそのような用途に限定されるものではない。
【0032】
特に、本発明は、異なるマルチメディアサービス環境間でのマルチメディアサービスメッセージの交換の典型的な実行において説明されている。図1を参照すると、3GPP TS23.140バージョン6.4.0で定義されているように、2つの異なるマルチメディアサービス環境(MMSE)の相互作用の概観が図示されている。
【0033】
図1を参照すると、参照番号104aで示される第1のマルチメディアサービス(MMS)ユーザエージェント(UA)Aは、参照番号102aで示される第1のMMSEサービスプロバイダAの、参照数字106aで示される第1のMMSリレー/サーバAに接続されている。参照番号104bで示される第2のMMSユーザエージェントBは、参照番号102bで示される第2のMMSEサービスプロバイダBの、参照番号106bで示される第2のMMSリレー/サーバBに接続されている。ユーザエージェント104aおよび104bのそれぞれは、インターフェイス接続108aおよび108bをそれぞれ介して各MMSリレー/サーバに接続されている。第1および第2のMMSリレー/サーバ106aおよび106bは、インターフェイス110を介して相互接続している。
【0034】
MMSユーザエージェント104aおよび104bのそれぞれは、ユーザ装置、移動局、またはユーザのためにMMS特有の動作を行う外部機器にあるアプリケーションを構成する。MMSユーザエージェントはMMSEの一部とは見なされない。MMSリレー/サーバ106aおよび106bのそれぞれは、MMS特有のネットワークエンティティ/アプリケーション、またはMMSサービスプロバイダの制御下で動作する要素である。各MMSリレー/サーバはメッセージを転送し、モバイル環境に特有の、またはそれによって要求されるMMSの動作を提供し、MMSに一時的および/または固定の記憶サービスを提供する。
【0035】
MMSリファレンスアーキテクチャは、3GPP TS23.140バージョン6.4.0によって定義されているように、MMSリファレンスアーキテクチャおよび、MM1からMM8で示されるリファレンスアーキテクチャ内の8つのインターフェイスを定義している。図1は、これらの基準点のうち2つを示す。MMSユーザエージェントとMMSリレー/サーバとの間のインターフェイス108aおよび108bは、MMSユーザエージェントとMMSリレー/サーバとの間の基準点である、基準点MM1を表す。基準点MM1は、MMSユーザエージェントからMMSリレー/サーバへマルチメディアメッセージを提出するためや、MMSユーザエージェントにMMSリレー/サーバからマルチメディアメッセージをプルさせるため、MMSリレー/サーバにMMSユーザエージェントへマルチメディアメッセージに関する情報をマルチメディアメッセージ通知の一部としてプッシュさせるため、MMSリレー/サーバとMMSユーザエージェントとの間で配信ポートを交換するために使用される。
【0036】
各サービス環境のMMSリレー/サーバ間のインターフェイス110は、MMSリレーサーバと別のMMSE内にある別のMMSリレー/サーバとの間の基準点である、インターフェイスMM4を表す。基準点MM4によって提供されるインターフェイスは、各MMSリレー/サーバ間でメッセージを転送するために使用される。MMSリレー/サーバ間のインターワーキングは、単純なメール転送プロトコル(Simple Mail Transfer Protocol;SMTP)に基づいている。
【0037】
各MMSリレー/サーバは、その他のMMSEにおいて各MMSリレー/サーバを見つけるための、ピア発見に適している。マルチメディアメッセージ送信において、メッセージを送信している各MMSリレー/サーバは発信元と呼ばれ、メッセージを受信している各MMSリレー/サーバは受信先または宛先と呼ばれる。ピアエンティティの発見に成功後、発信元MMSリレー/サーバは受信先MMSリレー/サーバへマルチメディア要求メッセージを送る。この要求メッセージは、MMS制御情報およびマルチメディアメッセージコンテンツを含む。受信先MMSリレー/サーバは、発信元MMSリレー/サーバがMM4_forward.REQメッセージ内に「確認応答要求」情報要素フィールドセットを有する場合、応答メッセージで応答しなければならない。応答メッセージは、例えば要求の状態を提供する。要求メッセージはMM4_forward.REQメッセージであり、応答メッセージはMM4_forward.RESメッセージである。これらのメッセージは 3GPP TS23.140により定義されるプロトコルデータユニット(PDU)である。
【0038】
本発明は、この実施形態において、以下でさらに説明するように、応答メッセージの適応化を規定する。要求メッセージの適応化は必要ない。
【0039】
本発明のこの実施形態によると、さらなる情報要素がMM4_FORWARD.RESメッセージに含まれる。この情報要素は「受信先」と呼ばれる。しかしながら、情報要素の名称は限定的なものではない。情報要素は、受信先のリストを含む。M4_forward.RESメッセージがMM4_forward.RESメッセージを受けて、複数の受信先に関する集合状態表示を含む場合、MM4_forward.RESメッセージに含まれる受信先のリストは、その集合状態が当てはまる受信先を識別する。MM4_forward.RESメッセージは要求状態値を含み、この要求状態値は当該メッセージにおいて識別されたすべての受信先に当てはまる。
【0040】
本発明のこの実施形態に従って適合されるMM4_forward.RESプロトコルデータユニットメッセージ内の情報要素を、以下の表1で説明する。
【表1】

【0041】
本発明のこの実施形態による新規の情報要素、すなわち「受信先」情報要素を除き、表1に示す情報要素はすべて3GPP TS23.140バージョン6.4.0において定義されている。図示されているその他の情報要素には当業者は精通しているものであろうし、そのような情報要素の機能は表1の「説明」欄に記載されている。表1の「存在」欄は、そのような情報要素の存在が任意であるか、必須であるか、または条件付であるかを識別するものである。
【0042】
表1に示すように、「受信先」情報要素の存在は条件付である。例えば、メッセージが単一の受信先に宛てられていた場合、応答に「受信先」情報要素を含むことは事実上余分であり、必要ない。さらに、すべての受信先の要求状態が同一である場合、応答において受信先情報要素は必ずしも必要ではない。しかしながら、いずれの場合においてもやはり受信先情報要素は存在してよい。
【0043】
マルチメディアサービス環境間におけるマルチメディアサービスの信頼できる転送を保証することを目的とした本発明の実施形態の動作については、図2のメッセージフローおよび図3のフロープロセスを参照し、以下でさらに説明する。
【0044】
図2を参照すると、マルチメディアメッセージがMMSリレー/サーバA106aによってMMSリレー/サーバB106bへ送信される例が示されている。このように、MMSリレー/サーバA106aは発信元マルチメディアメッセージングサービスコントローラ(MMSC)であり、MMSリレー/サーバB106bは宛先または受信先MMSCである。
【0045】
ステップ302において、MMS要求は発信元MMSリレー/サーバ106aの回線202で受信される。例では、MMSはa、b、c、d、eと表示されている5つの受信先に送信される。当該技術分野では公知であるように、発信元MMSリレー/サーバ106aは、適切なピアMMSリレー/サーバを識別するための発見プロセスを実行する。このようにして宛先または受信先MMSリレー/サーバ106bは定義される。この例では、簡単にするために5つすべての受信先が同一のMMSE102bに位置している、すなわちMMSリレー/サーバ106bによって制御されているが、実際の実行においては必ずしもそうでない場合がある。発信元MMSリレー/サーバ106aは、MMSリファレンスアーキテクチャの基準点MM1で示される無線インターフェイスにおいてMMSを受信する。
【0046】
ステップ304で示すように、参照番号204で示されるMM4基準点によって提供されるインターフェイスはその後、MMSリレー/サーバ106aによって、5つの受信先のIDを含むMMS要求メッセージ(3GPP TS23.140ではMM4_forward.REQ PDUとして示される)を宛先MMSリレー/サーバ106bへ送信するために使用される。3GPP TS23.140バージョン6.1.0によると、確認応答要求はオプション機能である。しかしながら、本明細書に記載する発明は、確認応答が必須であっても同様に当てはまる。上述したように、MM4インターフェイス204で送信されたメッセージはSMTPメッセージであり、MM4_forward.REQ PDU要求メッセージである。このメッセージは、メッセージを独自に識別する独自の識別子をさらに含む。
【0047】
ステップ306で示すように、受信先MMSリレー/サーバ106bはMM4インターフェイス204で発信元MMSリレー/サーバ106aからのMMS要求メッセージを受信する。
【0048】
受信先MMSリレー/サーバは、MMS要求メッセージ、特にMM4_forward.REQ PDUを受信すると、PDUを受信先に転送しようとする前に各受信先の要求状態コードを決定しなくてはならない。これは当該技術分野では公知であり、受信先との通信に関わる待ち時間のために必要である(例えば、受信先はいつPDUを読み出すかを自身で決定することができる)。受信先はユーザエージェントであることに留意すべきである。
【0049】
各受信先の要求状態コードを決定するため、受信先MMSリレー/サーバはさらに各受信先のユーザエージェントプロファイルを読み出す。これはステップ306でも示されている。ユーザエージェントプロファイルは、3GPP TS23.140バージョン6.1.0で基準点MM6として示されるデータベースから読み出される。
【0050】
ステップ308において、受信先MMSリレー/サーバは、読み出されたMM4_forward.REQ PDUと、データベースから読み出すユーザエージェントプロファイルとの両方を検証する。ユーザエージェントプロファイルは、ユーザエージェント性能および、場合によっては例えばユーザエージェントが禁止されているか否かなど、その他のエージェント特有データの記述を含む。次いで受信先MMSリレー/サーバは各ユーザエージェント(または受信先)について実際のメッセージ(MM4_forward.REQから生成されたMM1_retrieve.RES形式のもの)が問題のユーザエージェントへ転送可能か否かを決定する。そのような決定に従って、ステップ310で示されるように各受信先の状態コードが決定される。
【0051】
3GPP TS23.140バージョン6.4.0により定義されている、考えられる要求状態コードおよびそれらの意味を、下記の表2に提示する。
【表2】

【0052】
ステップ308での検証の結果のようにすべての状態コードが可能なわけではない。場合によっては各受信先について決定可能な、本発明の実施形態によるこれらの状態コードについて、以下でさらに説明する。
【0053】
「OK」状態コードは、メッセージが「そのままで」または受信先MMSリレー/サーバによりコンテンツ適応が行われた後に受信先に配信可能であることを示す。
【0054】
「Error−sending−address−unresolved」状態コードは、特定の受信先(ユーザエージェント)が受信先MMSリレー/サーバの加入者でないことを示す。
【0055】
「Error−content−not−accepted」状態コードは、特定の受信先(ユーザエージェント)がメッセージのコンテンツを受け入れられないことを示す。
【0056】
「Error−network−problem」状態コードは、受信先MMSリレー/サーバが容量過負荷のため対応する要求を受け入れられないことを示す。この状態は、おそらく、単一メッセージに対して許容される受信先の最大数に限度を設定できるMMSリレー/サーバから、受信先(ユーザエージェント)ごとに与えられるであろう。また、この状態は、おそらく受信先の一部が実際に一時的に過負荷または利用不可能なアプリケーション(ハンドセットの代わりに)である場合に発生するであろう。
【0057】
表2に記載されたその他のコードで上述しなかったものは、エンティティとしてMM4_forward.REQ PDUに適用され、個別の受信先(ユーザエージェント)には適用されず、したがって本発明の実施形態には関係しない。しかしながら、新規の状態コードが3GPP TS23.140の改訂版に導入されることがあり、それらの一部が受信先特有である場合がある。
【0058】
状態決定ステップの後、ステップ312において、メッセージは受信先MMSリレー/サーバによって、標準技術によって送信が可能な受信先へ転送されることができる。
【0059】
宛先または受信先MMSリレー/サーバ106bは、受信先a、b、c、d、eそれぞれへのMMSメッセージの送信を個別に処理する。これは、図2で各信号206aから206eにより図示されている。これらの信号206aから206eは、受信先MMSリレー/サーバ106bにおけるMMSの処理を個別に説明している。しかしながら、図2に示すように、メッセージは必ずしもすべての受信先へうまく配信されるわけではない。
【0060】
決定された状態による個別の受信先へのこれらのメッセージの送信は、当該技術分野においては公知であることに留意すべきである。本発明は、MM1基準点.により提供されたインターフェイスにおいて送信されたメッセージへのいかなる適応をも提案するものではない。しかしながら、本発明が将来においてMM1基準点.により提供されたインターフェイスへの任意の変更および任意の新規メッセージの作成をサポートすることが想定される。
【0061】
受信先の状態が決定された後いつでもメッセージを送信するためにステップ312が発生する場合があり、図3におけるステップ312の発生順序を守る必要はないことに留意すべきである。
【0062】
ステップ310で各受信先の状態コードを決定後、ステップ314において受信先MMSリレー/サーバは共通状態コードに従って受信先を分類する。したがって、宛先または受信先MMSリレー/サーバ106bは、状態コードと様々な受信先とを照合する。次いで受信先はすべて特定のカテゴリに従って分類される。したがって、例えば「OK」状態コードを有する各受信先は一緒に分類される等である。
【0063】
その後、ステップ316で表されるように、宛先または受信先MMSリレー/サーバ106bは、複数の確認応答メッセージを発信元MMSリレー/サーバへ送り返すのだが、ここで確認応答メッセージの数は、個別の受信先に関連すると識別された状態コードのタイプの数に対応している。したがって、例えば受信先すべてが「OK」状態コードを有する場合、発信元MMSリレー/サーバ106aには単一の確認応答を送り返すことができる。
【0064】
上記の例において、第1の確認応答メッセージは、受信先aとbを識別し、状態が「OK」であることを示す信号210として送信される。第2の確認応答メッセージは、受信先bとeを識別し、送信状態が過渡故障であることを識別する信号212として送り返される。第3の確認応答メッセージは、受信先cを識別し、無効なアドレスが提供されたことを示す信号214として送信される。各確認応答メッセージは、MM4基準点により提供されるインターフェイスにおいてMM4_forward.RES PDUメッセージとして送信される。
【0065】
発信元MMSリレー/サーバによるこれらのメッセージの受信は、ステップ318で示される。
【0066】
次いで発信元MMSリレー/サーバ106aは、ステップ320において、受信先MMSリレー/サーバから受信した確認応答メッセージに応答して講じるべき更なるアクションを決定する。したがって、発信元MMSリレー/サーバはこれらの確認応答メッセージを分析する。例えば、確認応答メッセージが過渡故障またはエラーにより送信が失敗したことを示す場合、発信元MMSリレー/サーバ106aは、好ましくは過渡故障に関連する受信先を識別するMMSリレー/サーバ106bへMMSを再送信する。上記の表2を参照すると、「Error−sending−address−unresolved」状態コードの場合、再送信を試みても無益である。「Error−content−not−accepted」状態コードの場合、発信元MMSリレー/サーバは、すべてのユーザエージェントがサポートし再送信を試みるべきメッセージコンテンツを定義しているOMA適合仕様に応じてPDUコンテンツをダウングレードするコンテンツ適応を行うことができる。「Error−network−problem」状態コードの場合、適当な間隔(一般に、発信元MMSリレー/サーバの設定可能な属性である間隔)をおいた後、PDU適応化なしに再送信を試みてよい。
【0067】
図2に示す例において、受信先bおよびeを識別する信号216は、宛先MMSリレー/サーバ106bへ送信される。
【0068】
図3のフローチャートを参照すると、受信先MMSリレー/サーバから受信した確認応答を分析した後、発信元MMSリレー/サーバは、いずれの再送信も適切であったか否かを決定する(ステップ322)。適切でない場合、MM4基準点におけるアクティビティはステップ324で終了する。再送信が適切である場合、次いで発信元MMSリレー/サーバは、ステップ326において、再送信に関連する受信先のための新規のMMS要求メッセージを作成し、受信先MMSリレー/サーバへ送信する。その後、ステップ306から320を繰り返す。
【0069】
宛先MMSリレー/サーバ106bは、受信先bおよびeそれぞれへのメッセージの再送信を再度処理する。これは、図2で各信号218bおよび218eにより図示されている。
【0070】
この際、宛先MMSリレー/サーバ106bは、受信先bおよびeについて「OK」状態コードを決定する。これは、信号220bおよび220eの送信で図示される。受信先bおよびeを識別し、状態が「OK」であることを示す、信号222で示されるようなさらなる確認応答メッセージがMMSリレー/サーバ106aに返される。
【0071】
MMSシステムアーキテクチャには、発信元MMSユーザエージェントによって制御される公知の分離配信レポートコンセプトが存在することに留意すべきである。発信元MMSユーザエージェントは、MMSメッセージにおいて、MMSの配信成功後にMMSユーザエージェントへ配信される配信レポートを要求することができる。このMMS配信レポート機能は、上述の確認応答機構を使用しないため、本発明の範囲外である。しかしながら、上述した原理は、その他の通信システムにおいて、複数の受信先に宛てられたメッセージの状態表示(確認応答)をメッセージ発信元に提供するために使用することができる。
【0072】
MMSリレー/サーバは、発信元MMSとして機能する場合、個別の受信先のためのメッセージ再送信を扱うためにいくつかの適応化がされねばならない。しかしながら、過渡故障後のメッセージの再送信はMMSリレー/サーバの典型的な失敗である。上記の発明をサポートするのにさらに必要な機能性は、MM4_forward.REQ PDUのどの受信先がそれらに関連する過渡故障を有するかを判断することと、この受信先のセットに対してのみ再送信することだけである。
【0073】
本発明は好都合にも、メッセージが配信された、または配信されなかった特定の受信先を発信元MMSリレー/サーバが識別できるようにする。発信元MMSコントローラはメッセージを送信したユーザの請求に関与するので、発信元MMSコントローラが送信されたメッセージの状態を知り、失敗した受信先に対してメッセージを再送信すべきか否かについての決定に関して制御を有することは好都合である。
【0074】
本発明はMMS環境の文脈で説明されている。しかしながら、本発明はそのような環境に限定されるものではなく、より広範に適用可能である。本発明は、メッセージが複数の受信先に宛てて送信され、そのような受信先および当該受信先へのメッセージの配信に関連する状態のうち少なくとも1つを識別する確認応答を返すことが可能な、いかなるアーキテクチャまたはネットワークにも当てはまる。
【0075】
上述のMMS実施形態において、複数の状態コードに対応する複数の応答メッセージは、発信元MMSリレー/サーバへ送信されてよい。しかしながら、状態コードおよび関連する受信先を提供する代替の技術が提供される場合がある。例えば、2つのMMSリレー/サーバ間で転送されるメッセージの量を最小化するための代替案として、1つの応答メッセージ(例えば、MM4_forward.RES PDUメッセージ)は、いくつかの状態コードおよび各状態表示に関わる個別の受信先情報要素を識別することができる。さらなる代替においては、リスト内の同一番号の状態が対応するリスト内の同一番号を持つ受信先に当てはまるように、MM4_forward.RESメッセージ内の状態コード(エラー)および受信先を列挙することが可能な場合がある。しかしながら、下位互換性の問題が生じる場合があるため、このアプローチは理想的ではない。さらに、(現行の「要求状態」ヘッダを使用しない)2つの新規のヘッダ―つまり、一方は受信先のリスト、他方は状態値のリスト―を提供することが可能な場合がある。
【0076】
一部の通信システムにおいて、メッセージ配信またはメッセージがすべての受信先へ配信可能か否かの決定には、ネットワークまたは受信先側の何らかの理由(例えば、ネットワーク障害、端末が圏外にある、受信先のメールボックスが一杯である等)のために比較的長い時間を要することがある。そのような場合、部分的な応答を対応する状態表示とともに、メッセージ配信が成功した、または直ちにエラーが発生した受信先へ送信することができる。残りの受信先への最終応答は、後で各個別の配信状況がわかる時に送信することができる。さらに、一部の通信システムでは、コアネットワーク要素間だけでなく、複数の受信先へのメッセージ発信元となる実際のエンドユーザへも、状態表示を持つ確認応答メッセージが配信されるかもしれない。特に、発信元端末がモバイル機器である場合、低バンド幅の無線インターフェイス上で唯一の集合的な確認応答を転送するのがより効果的である。確認応答メッセージは、通常の受信メッセージとしてユーザに見なされるか、あるいは、各受信先または複数の受信先ごとの配信状況を示すことによって、送信されたメッセージの状態表示をユーザに提供するための配信レポートとして使用できる。
【0077】
本発明の技術のさらなる実行例は、セッション開始プロトコル(Session Initiation Protocol;SIP)またはインスタントメッセージング(IM)に関連するものである。SIPでは、いわゆるSIPエクスプローラコンセプトに関連するIETF(インターネットエンジニアリングタスクフォース、www.ietf.org)における、アクティブな作業項目が存在する。SIPエクスプローラメッセージの例は、単一のユーザから例えばサーバへ送信された要求である。このメッセージはその後、直ちにまたは所定の時期に、サーバから複数のさらなるユーザへ送信される。上述したような本発明の原理によると、複数のユーザへ送信された各メッセージはサーバへ確認応答メッセージを返すことができ、このようにしてサーバは発信元ユーザへ各ユーザのメッセージ送信状態を返すことができる。ネットワークから受信したその他の信号またはエラーメッセージから、受信先の状態表示を抽出することも可能である。さらに、ネットワークまたはユーザからいかなる種類の応答も受信しない場合、当該受信先の配信状況は、例えば一定時間の後に、不明と設定されてもよい。
【0078】
本発明は、特にMMS環境およびMMS環境間通信のような、特定の、限定的でない例に関連して説明されている。当業者には、本発明はそのような環境に限定されるものではなく、より広範に適用できる使用法を有することが理解されるであろう。本発明の範囲は、添付の特許請求の範囲によって定義される。

【特許請求の範囲】
【請求項1】
発信側リレー/サーバから送信された要求であって、複数の受信先に宛てられた要求を、受信側リレー/サーバで受信すること;
前記複数の受信先のアドレスが有効であるか否かを判断することであって、前記判断することは、前記アドレスが解決できるか否かを判断することを含む、前記判断すること;
前記受信側リレー/サーバが、前記要求を前記受信先のそれぞれに配信しようとする前に、前記判断に基づいて、各受信先に関する前記要求の状態を決定すること、ただし前記状態は、該受信先のアドレスが有効であるか否かを示すものである、前記決定すること;
前記受信側リレー/サーバが、前記複数の受信先のうち少なくとも1つの受信先および該少なくとも1つの受信先に関する前記状態を識別する応答を、前記発信側リレー/サーバへ送信すること;
を含む、方法。
【請求項2】
各受信先に関する前記要求の前記状態を前記決定することが、前記要求が各受信先へ送信されることができるか否かを決定することを含む、請求項1に記載の方法。
【請求項3】
各受信先に関する前記要求の前記状態を前記決定することが、前記受信先のユーザプロファイルデータを検証することを含む、請求項1に記載の方法。
【請求項4】
前記決定された、各受信先に関する前記要求の前記状態が、該受信先への前記要求の送信状態を示す、請求項1に記載の方法。
【請求項5】
複数の受信先に宛てられた前記要求を前記受信することが、前記複数の受信先への前記要求の送信要求を受信することを含む、請求項1から4のいずれかに記載の方法。
【請求項6】
前記応答が、それぞれ少なくとも1つの受信先を識別すると共に該識別される受信先に関する前記要求の前記状態を格納する、複数の応答を含む、請求項1から5のいずれかに記載の方法。
【請求項7】
前記複数の受信先が複数のセットに分けられ、前記応答は、前記受信先のセットのいずれかと、該受信先のセットに対応する前記要求の前記状態とを識別する少なくとも1つの応答を含む、請求項1から5のいずれかに記載の方法。
【請求項8】
前記受信先のセットが1つ以上の受信先を含む、請求項7に記載の方法。
【請求項9】
前記決定された、前記要求の前記状態が、不完全な送信、受け入れられなかったメッセージの内容、または成功した送信のうちの1つを示す、請求項1から8のいずれかに記載の方法。
【請求項10】
前記応答が、複数の受信先を識別すると共に、前記決定された前記要求の前記状態が前記識別された受信先のすべてに共通であることを示す、請求項1から9のいずれかに記載の方法。
【請求項11】
前記要求の発信元がメールボックスを有し、前記応答が前記メールボックスへ送信される、請求項1から10のいずれかに記載の方法。
【請求項12】
前記応答が、前記要求の発信元に複数の受信先の配信状況を提供する、請求項1から11のいずれかに記載の方法。
【請求項13】
前記要求または前記応答の少なくともいずれかにセッション開始プロトコルを使用する、請求項1から12のいずれかに記載の方法。
【請求項14】
前記要求または前記応答の少なくともいずれかはマルチメディアサービスメッセージである、請求項1から13のいずれかに記載の方法。
【請求項15】
前記受信先に関する前記要求の状態を前記決定することは、メッセージ通知の一部として、前記受信先のそれぞれに前記要求についての情報をプッシュしようと試みる前に各受信先の前記状態を決定することを含む、請求項1から14のいずれかに記載の方法。
【請求項16】
前記応答は、3GPP TS23.140準拠のMM4_forward.RESプロトコルデータユニットメッセージである、請求項1から15のいずれかに記載の方法。
【請求項17】
発信側リレー/サーバから送信された要求であって、複数の受信先に宛てられた要求を受信する手段と、
前記複数の受信先のアドレスが有効であるか否かを判断する手段であって、前記判断する手段は、前記アドレスが解決できるか否かを判断する手段を含む、前記判断する手段と、
前記要求を前記受信先のそれぞれに配信しようとする前に、前記判断に基づいて、各受信先に関する前記要求の状態を決定する手段、ただし前記状態は、該受信先のアドレスが有効であるか否かを示すものである、前記決定する手段と、
前記複数の受信先のうち少なくとも1つの受信先および該少なくとも1つの受信先に関する前記状態を識別する応答を、前記発信側リレー/サーバへ送信する手段と、
を含むネットワーク要素。
【請求項18】
前記送信手段が、少なくとも1つの受信先を識別する複数のメッセージであって、それぞれ対応する複数の状態のうち1つを含む複数のメッセージを送信するように構成される、請求項17に記載のネットワーク要素。
【請求項19】
前記受信先に関する前記要求の状態を決定する手段は、要求通知の一部として前記受信先のそれぞれに前記要求についての情報をプッシュしようと試みる前に、前記受信先に関する前記要求の状態を決定するように構成される、請求項17又は18に記載のネットワーク要素。
【請求項20】
前記応答は、3GPP TS23.140準拠のMM4_forward.RESプロトコルデータユニットメッセージである、請求項17から19のいずれかに記載のネットワーク要素。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate


【公開番号】特開2012−39610(P2012−39610A)
【公開日】平成24年2月23日(2012.2.23)
【国際特許分類】
【出願番号】特願2011−169762(P2011−169762)
【出願日】平成23年8月3日(2011.8.3)
【分割の表示】特願2006−551951(P2006−551951)の分割
【原出願日】平成17年2月3日(2005.2.3)
【出願人】(398012616)ノキア コーポレイション (1,359)
【Fターム(参考)】