(57)【要約】マルチユーザマルチメディアメッセージサービスの効率性を高めるための方法、装置及びコンピュータプログラムが開示される。マルチメディアメッセージは送信側ユーザ装置から送信側サーバへ送信され、さらに宛先の受信側ユーザ装置が関連づけされた１つ又は複数の受信側サーバへ送信される。１つ又は複数の受信側サーバは、マルチメディアメッセージを受信側ユーザ装置へ分配するためのマルチメディア配信及び／又は、各々が受信側ユーザ装置の１つにおけるマルチメディアメッセージの個別伝送状況の表示を含む状態メッセージを、受信側ユーザ装置から受信し、この表示をマルチメディアメッセージの伝送状態を表すレポートに集計し、そのレポートを送信側サーバへ送信することにより、マルチメディアメッセージの伝送状態の改良されたレポーティングを実行する。
2005532714.tif 000002
【特許請求の範囲】
【請求項１】
送信側ユーザ装置から受信側ユーザ装置へマルチメディアメッセージを効率的に伝送するための方法であって、
前記マルチメディアメッセージ及び前記受信側ユーザ装置のアドレス表示を含む第１のメッセージを前記送信側ユーザ装置から送信側サーバへ送信するステップと、
前記受信側ユーザ装置が関連づけされた受信側サーバを、前記アドレスの前記表示に基づいて特定するステップと、
前記第１のメッセージを前記受信側サーバへ送信するステップと、
前記アドレスの表示に基づいて前記受信側ユーザ装置を特定するステップと、
前記受信側ユーザ装置への前記マルチメディアメッセージのマルチキャスト配信を実行するステップとを有することを特徴とする方法。
【請求項２】
前記マルチキャスト配信の実行ステップが、
マルチキャストアドレスを割り当てるステップと、
前記マルチキャストアドレスを前記受信側ユーザ装置へ送信するステップと、
マルチキャスト伝送に適したオブジェクトへ前記マルチメディアメッセージを埋め込むステップと、
前記受信側ユーザ装置により、前記オブジェクトを受信するための準備を行うステップと、
前記受信側ユーザ装置により、前記マルチキャストアドレスに従ったマルチキャストグループの結合を行うステップと、
前記受信側ユーザ装置へ、前記オブジェクトを前記マルチキャスト伝送を介して送信するステップを含むことを特徴とする請求項１記載の方法。
【請求項３】
前記マルチキャスト配信の実行ステップが、受信側ユーザ装置の数に基づくことを特徴とする請求項１又は請求項２記載の方法。
【請求項４】
前記受信側ユーザ装置が、前記マルチキャストアドレスとともに、誤り保護方法の説明、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、前記マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を受信することを特徴とする請求項２又は請求項３記載の方法。
【請求項５】
前記送信側サーバ及び前記受信側サーバの少なくとも１つは、前記アドレス表示から前記受信側ユーザ装置の前記アドレスを解決することを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
前記受信側ユーザ装置が、前記アドレス表示に基づいて特定される、１つより多い受信側サーバに関連づけられ、前記第１のメッセージが前記１つより多い受信側サーバに送信されるとともに、前記１つより多い受信側サーバの各々が、自らに関連付けられた受信側ユーザ装置を特定し、前記マルチメディアメッセージの、自らに関連付けられた受信側ユーザ装置へのマルチキャスト配信を実行することを特徴とする請求項１乃至請求項５のいずれか１項に記載の方法。
【請求項７】
送信側ユーザ装置から受信側ユーザ装置へ、マルチメディアメッセージの伝送状態を効率的にレポートするための方法であって、
送信側サーバからのマルチメディアメッセージを受信側サーバで受信するステップと、
前記マルチメディアメッセージを、受信側サーバから、当該受信側サーバに関連づけされた、宛先の前記受信側ユーザ装置へ送信するステップと、
前記受信側ユーザ装置の１つにおける、前記マルチメディアメッセージの個別の伝送状態の表示を含む状態メッセージを受信するステップと、
前記表示を、前記マルチメディアメッセージの前記伝送状態を表す１つのレポートに集計するステップと、
前記レポートを前記送信側サーバへ送信するステップとを有することを特徴とする方法。
【請求項８】
前記個別の伝送状態の表示の少なくとも１つが、前記マルチメディアメッセージに関する通知の確認応答、前記マルチメディアメッセージの配信の確認応答及び、前記マルチメディアメッセージの読了の確認応答の少なくとも１つを含むことを特徴とする請求項７記載の方法。
【請求項９】
前記送信側サーバが、前記マルチメディアメッセージを送信側ユーザ装置から受信することを特徴とする請求項７又は請求項８記載の方法。
【請求項１０】
前記表示が、前記送信側ユーザ装置、前記送信側サーバ及び前記受信側サーバを含むグループの少なくとも１つのエンティティから送信される要求に従って編集され、前記編集された表示が集計されることを特徴とする請求項７乃至請求項９のいずれか１項に記載の方法。
【請求項１１】
前記要求が変更可能であるか、１つ又は複数の要求が前記要求に追加可能であることを特徴とする請求項１０記載の方法。
【請求項１２】
ある時間間隔内に受信される前記状態メッセージが前記レポートに用いられることを特徴とする請求項７乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
１つ又は複数の前記表示は、前記受信側ユーザ装置の１つ又は複数のアドレスに関連することが可能であり、前記レポートは前記伝送状態に関する前記１つ又は複数のアドレスを含むことを特徴とする請求項７乃至請求項１２のいずれか１項に記載の方法。
【請求項１４】
前記レポートが統計的及び／又は課金目的で処理されることを特徴とする請求項７乃至請求項１３のいずれか１項に記載の方法。
【請求項１５】
前記受信側ユーザ装置が複数の受信側サーバに関連づけされ、前記送信側サーバは前記マルチメディアメッセージを前記複数の受信側サーバへ送信するとともに、各々が前記複数の受信側サーバの各々に関する前記マルチメディアメッセージの伝送状態を表す複数のレポートを受信し、さらに前記送信側サーバは、前記複数のレポートを、前記マルチメディアメッセージの前記伝送状態を表す１つの別レポートに集計することを特徴とする請求項７乃至請求項１４のいずれか１項に記載の方法。
【請求項１６】
前記送信側ユーザ装置が、送信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項１乃至請求項１５のいずれか１項に記載の方法。
【請求項１７】
前記受信側ユーザ装置の各々が、受信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項１乃至請求項１６のいずれか１項に記載の方法。
【請求項１８】
前記送信側サーバが、送信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項１乃至請求項１７のいずれか１項に記載の方法。
【請求項１９】
前記受信側サーバが、受信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項１乃至請求項１８のいずれか１項に記載の方法。
【請求項２０】
マルチメディアメッセージを受信側ユーザ装置へ効率的に伝送するための受信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
マルチメディアメッセージ及び受信側ユーザ装置のアドレス表示を含む第１のメッセージを受信し、前記アドレス表示に基づいて前記受信側ユーザ装置を特定し、前記マルチキャストメッセージの前記受信側ユーザ装置へのマルチキャスト配信を実行するように適合されるとともに、マルチキャストアドレスを割り当て、前記マルチキャストアドレスを前記受信側ユーザ装置へ送信し、前記マルチメディアメッセージをマルチキャスト伝送に適したオブジェクトへ埋め込み、前記オブジェクトを前記マルチキャスト伝送を介して前記受信側ユーザ装置へ送信するように適合されることを特徴とする受信側サーバ。
【請求項２１】
受信側ユーザ装置の数に基づいて前記マルチキャスト配信を実行するように適合されることを特徴とする請求項２０記載の受信側サーバ。
【請求項２２】
前記マルチキャストアドレスとともに、誤り保護方法の記述、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を送信するように適合されることを特徴とする請求項２０又は請求項２１記載の受信側サーバ。
【請求項２３】
前記アドレス表示から前記受信側ユーザ装置のアドレスを解決するように適合されることを特徴とする請求項２０乃至請求項２０のいずれか１項に記載の受信側サーバ。
【請求項２４】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための受信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
送信側サーバから前記マルチメディアメッセージを受信し、前記マルチメディアメッセージを、前記受信側サーバに関連づけされた宛先の受信側ユーザ装置へ送信し、それぞれが前記受信側ユーザ装置の１つにおける個別の前記マルチメディアメッセージの伝送状態の表示を含む状態メッセージを受信するように適合されるとともに、前記表示を前記マルチメディアメッセージの前記伝送状態を表す１つのレポートに集計し、前記レポートを前記送信側サーバへ送信するように適合されることを特徴とする受信側サーバ。
【請求項２５】
送信側ユーザ装置、前記送信側サーバ及び前記受信側サーバを含むグループの少なくとも１つのエンティティから送信される要求に従って前記表示を編集し、前記編集した表示を集計するように適合されることを特徴とする請求項２４記載の受信側サーバ。
【請求項２６】
前記要求を変更し、前記変更された要求に従って前記表示を編集するか、１つ又は複数の要求を追加し、当該追加された１つ又は複数の要求に従って前記表示を編集するように適合されることを特徴とする請求項２４又は請求項２５記載の受信側サーバ。
【請求項２７】
ある時間間隔内に受信される前記状態メッセージを前記レポートに用いるように適合されることを特徴とする請求項２４乃至請求項２６のいずれか１項に記載の受信側サーバ。
【請求項２８】
１つ又は複数の前記表示を前記受信側ユーザ装置の１つ又は複数のアドレスに関連させ、前記レポートにおける前記伝送状態に前記１つ又は複数のアドレスを関連づけるように適合されることを特徴とする請求項２４乃至請求項２７のいずれか１項に記載の受信側サーバ。
【請求項２９】
前記レポートを統計的及び／又は課金目的で処理するように適合されることを特徴とする請求項２４乃至請求項２８のいずれか１項に記載の受信側サーバ。
【請求項３０】
受信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項２０乃至請求項２９のいずれか１項に記載の受信サーバ。
【請求項３１】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
前記マルチメディアメッセージを、宛先の前記受信側ユーザ装置が関連づけされた複数の受信側サーバに送信し、前記複数の受信側サーバから、レポートの送信側である個々の受信側サーバに関する前記マルチメディアメッセージの前記伝送状態を表すレポートを受信し、受信した複数の前記レポートを、前記マルチメディアメッセージの前記伝送状態を表す別のレポートに集計する様に適合されることを特徴とする送信側サーバ。
【請求項３２】
前記マルチメディアメッセージが送信側ユーザ装置から受信され、前記送信側サーバが前記別のレポートを前記送信側ユーザ装置へ送信するように適合されることを特徴とする請求項３１記載の送信側サーバ。
【請求項３３】
要求に従って編集する、要求を変更する、及び要求を付加する、を含むグループからの少なくとも１つを実行するように適合されることを特徴とする請求項３１又は請求項３２記載の送信側サーバ。
【請求項３４】
前記レポート及び前記別のレポートの少なくとも１つを、統計的及び／又は課金目的で処理するように適合されることを特徴とする請求項３１乃至請求項３３のいずれか１項に記載の送信側サーバ。
【請求項３５】
送信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項３１乃至請求項３４のいずれか１項に記載の送信側サーバ。
【請求項３６】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側ユーザ装置であって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
編集のための１つ又は複数の表示に従い、集計的な方法によって前記伝送状態を求めるための前記編集のための１つ又は複数の表示を含むレポート要求を、前記送信側ユーザ装置のユーザによる選択に従って生成するように適合されるとともに、前記要求と前記マルチメディアメッセージを送信側サーバへ送信し、前記要求に従って前記送信側サーバから、前記集計的な方法によって求められた伝送状態を含む前記レポートを受信するように適合されることを特徴とする送信側ユーザ装置。
【請求項３７】
送信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項３６記載の送信側ユーザ装置。
【請求項３８】
受信側サーバの処理ユニットに読み込み可能なコンピュータプログラムであって、請求項１から請求項１９のいずれかに係る方法の、前記受信側サーバに関するステップを実行するように適合されたコードを含むことを特徴とするコンピュータプログラム。
【請求項３９】
送信側サーバの処理ユニットに読み込み可能なコンピュータプログラムであって、請求項１から請求項１９のいずれかに係る方法の、前記送信側サーバに関するステップを実行するように適合されたコードを含むことを特徴とするコンピュータプログラム。
【請求項４０】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための、送信側ユーザ装置の処理ユニットに読み込み可能なコンピュータプログラムであって、
編集のための１つ又は複数の表示に従い、集計的な方法によって前記伝送状態を求めるための、前記編集のための１つ又は複数の表示を含むレポート要求を、前記送信側ユーザ装置のユーザによる選択に従って生成するように適合されたコードと、前記要求と前記マルチメディアメッセージの、送信側サーバへの送信を達成するように適合されたコードと、前記送信側サーバから受信したレポートであって、前記集計的な方法によって求められた前記伝送状態を含むレポートを、前記要求に従って処理するように適合されたコードとを含むことを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は移動通信ネットワークに関し、特にマルチユーザマルチメディアメッセージサービスを最適化するための方法及び装置に関する。
【背景技術】
【０００２】
ショートメッセージサービス（ＳＭＳ）は、ＧＳＭ(Global System for Mobile communication)第２世代（２Ｇ）システムにおいてユーザに大きく受け入れられている。ＳＭＳでは、例えばインターネットコンピュータ端末から携帯電話へ、又はある携帯電話から別の携帯電話へ、ＧＳＭ端末を用いた非リアルタイムテキスト伝送の実行が可能である。この、非リアルタイムテキスト伝送のための使いやすいサービスは、非リアルタイムマルチメディアメッセージサービス（ＭＭＳ）によって、２．５世代及び第３世代（３Ｇ）移動システムにおいても引き継がれるべきである。ＭＭＳにより、新しいコンテンツ形式が普及した際にサポートすることを可能にしながら、ユーザは例えばテキスト、画像、音声、ビデオといった現在利用可能な数々なメディア形式すべてを利用するマルチメディアメッセージ（ＭＭ）の送受信が可能である。
【０００３】
蓄積伝送ＭＭとも呼ばれる非リアルタイムＭＭは、リアルタイムに伝送される必要なしに装置間で伝送可能なマルチメディアプレゼンテーションにおける、１つかそれより多い異なるメディア要素の組み合わせである。非リアルタイムマルチメディアメッセージサービスは、携帯電話に対する要求の高まりに伴って、現在及び将来のマルチメディアメッセージサービスのサポートが可能であるべきであるとともに、マルチメディアコミュニティにおいてなされた進歩を十分に利用すべきである。
【０００４】
３ＧＰＰ(3rd Generation Partnership Project)技術仕様22.140 V.4.2.0 (2002-03)及び３ＧＰＰ技術仕様23.140 V.4.6.0 (2002-03)は、ＭＭＳについての標準規格策定の現状を記述する。送信側から受信側へＭＭを送信するため、以下の手順を用いることができる。ユーザエージェント（ＵＡ）、すなわち送信側のユーザ装置（ＵＥ）又は送信側のＵＥに取り付け可能な装置に存在するアプリケーションは、マルチメディアコンテンツ及び受信側のアドレスを含むＭＭを送信側ＭＭＳリレー／サーバ（Ｒ／Ｓ）へ送信する。送信側ＭＭＳ Ｒ／ＳはＭＭコンテンツを受信側ＭＭＳ Ｒ／Ｓへ転送し、受信側ＭＭＳ Ｒ／Ｓは続いて受信側のＵＥに存在するＵＡに通知する。この通知はＭＭを含まないが、実際のＭＭへの参照を含んでいる。ＭＭ通知は受信側ＭＭＳ ＵＡによって受信側ＭＭＳ Ｒ／Ｓへ確認応答がなされ、その後ＭＭは受信側ＭＭＳ ＵＡによって読み出し可能となる。受信側のＵＡによるＭＭの読み出し(retrieval)及び読了(reading)は、受信側ＭＭＳ Ｒ／Ｓに確認応答される。ＭＭの配達レポートは元のＭＭ、受信側アドレス、タイムスタンプ及び受信側ＭＭＳ Ｒ／Ｓで生成可能な配達状況を含み、送信側ＭＭＳ Ｒ／Ｓへ送信される。送信側ＭＭＳ Ｒ／Ｓは、例えばＭＭの配達を送信側ＭＭＳ ＵＡに知らせるため、配達レポートを送信側ＭＭＳ ＵＡへ送信することが可能である。ＭＭが受信側で読了された際に受信側ＭＭＳ Ｒ／Ｓで生成される読了確認レポート(read reply report)についても、同様の手順である。
【０００５】
１つの送信側ＵＡから、複数の受信側ＭＭＳ ＵＡにＭＭを送信することが可能である。別の一方法は、ＭＭを複数の受信側ＭＭＳ ＵＡに宛て、送信側ＭＭＳ ＵＡでＭＭの複製を実行することである。別の代替方法は、ＭＭと複数の受信側ＭＭＳ ＵＡのアドレスを送信側ＭＭＳ ＵＡから送信側ＭＭＳ Ｒ／Ｓへ送信することである。ＭＭの複製は、受信側ＭＭＳ ＵＡが同一の受信側ＭＭＳ Ｒ／Ｓによって受け持たれている場合であっても、送信側ＭＭＳ Ｒ／Ｓで実行される。複製されたＭＭを１つ又は複数の受信側ＭＭＳ Ｒ／Ｓに送信し、受信側ＭＭＳ Ｒ／ＳがＭＭの読み出しのための通知を受信側ＭＭＳ ＵＡに通知することについては、この手順は上述したように継続する。いずれの方法も、複数の受信者への電子メール配達と類似である。受信者の全リストを含ませて複数の電子メールが各受信者に送信されるか、majordomoのようなリストサーバが用いられる。リストサーバは１つ又は複数のグループに登録されたユーザのアドレスのリストを維持する。各グループはグループアドレスによって識別可能である。グループの１つへ宛てられた電子メールは、対応するグループアドレスを含み、このグループアドレスと、対応するリストに基づき、リストサーバは対応するユーザアドレスを読み出すことができる。電子メールのコピーは対応するユーザアドレスの各々に送信される。
【０００６】
この手順はあまり効率的でない。ＭＭが複数の受信側ＭＭＳ ＵＡに配信する場合、通知及びその後受信側ＭＭＳ ＵＡにトリガされる読み出しシーケンスが制限となる。多くの受信側ＵＡが同一ＭＭについての通知を受ける場合、受信側ＭＭＳ ＵＡのすべて又はかなりの部分が、その通知受信直後にＭＭの読み出しを開始する可能性がかなり高いと考えられる。この状況において、受信側ＭＭＳ Ｒ／Ｓは、ＭＭの読み出しを要求する受信側ＭＭＳ ＵＡ毎に、ＭＭを含んだ読み出しのためのメッセージを送信し、それは受信側ＭＭＳ Ｒ／Ｓを高負荷状態とするとともに、ネットワークの輻輳、特に受信側ＭＭＳ Ｒ／Ｓ及び受信側ＭＭＳ ＵＡ間の少なく高価な無線ネットワークでの輻輳をも引き起こしかねない。加えて、ＭＭを受信した受信側ＭＭＳ ＵＳ及びＭＭを読んだ受信側ＭＭＳ ＵＡからそれぞれ送信される、読み出しの確認応答又は読了応答(read reply)は、それら受信側ＵＡと同じ数の配信又は応答レポートの生成を行わせる。このレポートは送信側ＭＭＳ Ｒ／Ｓ及び送信側ＭＭＳ ＵＡにも送信することが可能であり、それらエンティティ間のネットワークの輻輳及びそれら自身のエンティティの過負荷を引き起こす。
【０００７】
いわゆるMM1_提出.REQメッセージはアドレスを有し、送信側ＭＭＳ ＵＡから送信側ＭＭＳ Ｒ／Ｓへ送信されるＭＭは、配送レポート、応答課金(reply charging)及び読了レポートが要求されているかどうかを表すフラグを含む。しかし、これらのフラグは、送信側ＭＭＳ ＵＡがどのようにレポートを受信することを希望するかについての詳細な指定を持たない、単純な「はい／いいえ」フラグである。特に、現時点では、受信側ＭＭＳ ＵＡによる受信側ＭＭＳ Ｒ／Ｓへの確認応答及び読了応答メッセージによってトリガされる、送信側ＭＭ Ｒ／Ｓ及び送信側ＭＭＳ ＵＡへの配信レポート及び読了応答レポートの総量を制御する方法が存在しない。特に複数の受信側が存在する場合、確認応答及びレポート、確認応答及びレポートを伝送するために必要なメッセージングの総量は、関与するネットワークエンティティの高負荷を引き起こす可能性があり、結果として過負荷状態や性能の低下などを引き起こす。
【０００８】
【非特許文献１】３ＧＰＰ技術仕様22.140 V.4.2.0 (2002-03)
【非特許文献２】３ＧＰＰ技術仕様23.140 V.4.6.0 (2002-03)
【発明の開示】
【０００９】
本発明の目的は、マルチメディアメッセージの配信及び／又はレポートに関してマルチメディアメッセージサービスの効率を向上させる方法、装置及びコンピュータプログラムに関する。
【００１０】
この目的は請求項１及び請求項７に記載の方法によって達成される。さらに、本発明は請求項２０、２４及び３１記載のサーバ、請求項３６記載のユーザ装置及び請求項３８、３９及び４０記載のコンピュータプログラムにおいて実施される。好適な実施形態は他の請求項に記載される。
【００１１】
マルチメディアメッセージを送信側ユーザ装置から受信側ユーザ装置へ効率的に伝送するための方法が開示される。この方法はいくつかのステップを含む。最初のステップでは、第１のメッセージが送信側ユーザ装置から送信側サーバに送られる。第１のメッセージはマルチメディアメッセージ及び受信側ユーザ装置のアドレス表示を有する。アドレス表示は、例えば受信側ユーザ装置のグループアドレス、受信側ユーザ装置のアドレスを含むリスト、又はそれらの組み合わせである。
【００１２】
２番目のステップでは、受信側ユーザ装置のアドレス表示に基づき、受信側ユーザ装置に関連する受信側サーバの特定が実行される。このステップはグループアドレスの解決を含んでもよい。２番目のステップでは、受信側ユーザ装置のアドレス表示に基づき、受信側ユーザ装置に関連する受信側サーバを特定する。続くステップで、例えばグループアドレスを個々の受信側ユーザ装置のアドレスへ解決することにより、アドレス表示に基づいて受信側ユーザ装置を特定する。さらに、受信側ユーザ装置へ、マルチメディアメッセージのマルチキャスト配信が実施される。
【００１３】
この方法は、受信側ユーザ装置へのマルチメディアメッセージのマルチキャスト配信が行われるという事実により、受信側ユーザ装置へのマルチメディアメッセージ配信に関してマルチメディアメッセージサービスの効率を向上させる。マルチメディアメッセージを受信側ユーザ装置へ配信するためのメッセージング及び処理労力が削減されるため、マルチキャストによるマルチメディアメッセージの伝送はユニキャスト伝送よりも有利である。ユニキャスト伝送の場合、受信側サーバは個々の受信側ユーザ装置へ個別のメッセージを送信しなければならない。マルチキャストによれば、マルチメディアメッセージは受信側サーバから、配信される受信側ユーザ装置の近くで複製可能な１つのメッセージによって送信可能であり、そのため受信側サーバのメッセージング及び処理労力のみならず、受信側サーバとマルチキャスト配信する受信側ユーザ装置との間で使用されうるネットワークエンティティをも削減する。複数のアドレスを示すための１つ又は複数のグループアドレスの利用は、効率をさらに向上させる。特に多数の受信側をグループアドレス指定すると、メッセージ中に多くのアドレスを送信しなくてすむため、個別アドレスのリストと比較して好ましい。１つ又は複数のグループアドレスを用いると、第１のメッセージはより短くすることが可能となり、ネットワーク負荷及び第１のメッセージを取り扱うエンティティの処理労力を削減することが可能となる。
【００１４】
マルチキャスト配信は、マルチキャストアドレスの割り当て、マルチキャストアドレスの受信側ユーザ装置への送信、マルチキャスト伝送に適したオブジェクトへのマルチメディアメッセージの埋め込み、このオブジェクトを受信するための、受信側ユーザ装置による準備、受信側ユーザ装置による、マルチキャストアドレスに従ったマルチキャストグループの結合、及び受信側ユーザ装置への、マルチキャスト伝送を介したオブジェクトの送信、の各ステップを含みうる。結合ステップは準備ステップの一部として、あるいは別個に実行することができる。
【００１５】
好適な実施形態によれば、マルチキャスト配信の実行は、例えば受信側ユーザ装置の数が閾値を超えたことをチェックし、受信側サーバにマルチメディアメッセージのマルチキャスト配信を行わせることにより、受信側ユーザ装置の数に基づくことが可能である。
【００１６】
別の好適な実施形態によれば、受信側ユーザ装置は、マルチキャストアドレスとともに、誤り保護方式の記述、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を受信することができる。
【００１７】
他の好適な実施形態によれば、送信側サーバ及び受信側サーバの少なくとも１つは、アドレス表示から受信側ユーザ装置のアドレスを解決することが可能である。アドレスの解決はアドレス表示にグループアドレスが用いられる際に必要である。解決はサーバの一方又は、サーバに代わって解決サービスを提供する他のエンティティで実行することができる。
【００１８】
受信側ユーザ装置は、アドレス表示に基づいて特定される、１つより多い受信側サーバに関連づけられてもよい。この場合、第１のメッセージは１つより多い受信側サーバへ送信されうる。特定される１つより多い受信側サーバの各々は、関連づけされた受信側ユーザ装置を、例えば第１のメッセージに含まれるアドレス表示に基づいて特定することができる。さらに、第１のメッセージを受信した、特定された受信側サーバの各々は、自分に関連付けられた受信側ユーザ装置へ、マルチメディアメッセージのマルチキャスト配信を実行可能である。
【００１９】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状況を効率的にレポートするための方法が開示される。この方法はいくつかのステップを含む。最初のステップでは、送信側サーバからのマルチメディアメッセージが受信側サーバで受信される。受信側サーバは、マルチメディアメッセージが宛てられた受信側ユーザ装置及び、自らに関連づけされた受信側ユーザ装置を特定することができる。次のステップで、マルチメディアメッセージは、受信側サーバから、その受信側サーバに関連づけされた、宛先の受信側ユーザ装置へ送信されることが可能となる。続くステップで、例えばグループアドレスを個々の受信側ユーザ装置のアドレスへ解決することにより、アドレス表示に基づいて受信側ユーザ装置を特定する。個々の伝送状態の表示例は、マルチメディアメッセージに関する通知の確認応答(acknowledgement)、マルチメディアメッセージの配信の確認応答及び、マルチメディアメッセージの読了の確認応答を含むグループからの少なくとも１つを含む。受信された表示は、マルチメディアメッセージの伝送状態を表すレポート、例えば受信側ユーザ装置から受信した配信及び読了確認応答を含むレポートに、ある集計的な方法(aggregated way)により集計することができる。さらに、レポートは送信側サーバへ送信されることも可能である。
【００２０】
この方法は、複数の受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状況のレポーティングに関し、マルチメディアメッセージサービスの効率を向上させる。集計的な方法による情報のレポーティングは、宛先の受信側ユーザ装置の個別伝送状態を含む個々のメッセージを送信することによりレポーティングを実行するよりもずっと効率的である。集計されたレポーティングのためのメッセージはより少なくてよいので、最先端(state of the art)の方法に比べ、ネットワーク負荷を低減し、受信側サーバ及び送信側サーバの処理労力を削減することができる。さらに、一般に集計的な方法によるレポーティングは、個別の情報と比較し、伝送状態についてのより適切な概要を提供し、伝送状態のより早い解析を可能とする。
【００２１】
マルチメディアメッセージは送信側ユーザ装置から受信することができる。送信側サーバが受信したレポートは、送信側ユーザ装置にマルチメディアメッセージの伝送状態をレポーティングするため、送信側ユーザ装置へ送信することができる。
【００２２】
好ましい実施形態によれば、表示は要求に従って編集(compile)される。この要求は例えば、送信側ユーザ装置、送信側サーバ及び受信側サーバを含むグループの少なくとも１つのエンティティから送信することができる。編集された表示は、本発明に従って集計される。要求は、受信側サーバ及び／又は送信側サーバにより変更可能であるか、１つ又は複数の要求を付加されうる。
【００２３】
好ましい実施形態によれば、ある時間間隔内に受信される状態メッセージがレポートに用いられる。確認応答のような状態メッセージを所定時間間隔内で集計することで、レポーティングに長時間を費やすことを回避できる。
【００２４】
他の好適な実施形態によれば、１つ又は複数の表示は、受信側ユーザ装置の１つ又は複数のアドレスに関連することが可能であり、レポートは伝送状態に関する１つ又は複数のアドレスを含む。マルチメディアメッセージの伝送状態に関する１つ又は複数のアドレスをレポートすることで、例えばマルチメディアメッセージをまだ受信していない受信側ユーザ装置へそのマルチメディアメッセージをもう一度送信可能とするために利用可能な情報を提供することができる。
【００２５】
他の好適な実施形態によれば、レポートは統計目的及び／又は課金目的で処理されうる。
【００２６】
受信側ユーザ装置は、１つ又は複数の受信側サーバに関連づけされることができる。この場合、送信側サーバはマルチメディアメッセージを複数の受信側サーバへ送信することができ、かつ、各々が個々の受信側サーバに関するマルチメディアメッセージの伝送状態を表す複数のレポートを受信することができる。マルチメディアメッセージの伝送状態をレポートするために、送信側サーバは、複数のレポートをマルチメディアメッセージの伝送状態を表す１つの別のレポートにまとめることができる。
【００２７】
送信側ユーザ装置は、送信側マルチメディアメッセージサービスユーザエージェントを有することができる。送信側ユーザ装置は、送信側ユーザ装置に関する範囲で方法のステップを実行するためのマルチメディアメッセージサービスへのアクセスを有する、携帯電話やサーバのようなユーザ装置であってよい。
【００２８】
受信側ユーザ装置の各々は、受信側マルチメディアメッセージサービスユーザエージェントを有することができる。同様に、受信側ユーザ装置は、受信側ユーザ装置に関する範囲で方法のステップを実行するためのマルチメディアメッセージサービスへのアクセスを有する、携帯電話やサーバのようなユーザ装置であってよい。
【００２９】
送信側サーバは送信側マルチメディアメッセージサービスリレーサーバであってよく、受信側サーバは受信側マルチメディアメッセージサービスリレーサーバであってよい。これらは同時に、又は一方のみが満たされてもよい。送信側サーバ及び、１つ又は複数の受信側サーバは、個別の、あるいは１つ又は複数の共通プラットフォーム上で実現されてよい。
【００３０】
マルチメディアメッセージを送信側ユーザ装置から受信側ユーザ装置へ効率的に伝送するための方法、及び複数の受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態に関する情報を効率的にレポートするための方法の１つ又は複数のステップは、組み合わせ可能である。この組み合わせは、マルチキャスト及び改善されたレポーティングの両方に関するメッセージング並びに処理労力を削減し、マルチメディアメッセージサービスの利点としての効率をさらに向上させる。
【００３１】
本発明は以下さらに詳しく説明する、受信側サーバ、送信側サーバ及び送信側ユーザ装置のような装置において実施される。
【００３２】
マルチメディアメッセージを受信側ユーザ装置へ効率的に伝送するための受信側サーバが開示される。受信側サーバはメッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージ及び情報を処理する処理ユニットとを有する。受信ユニットは、マルチメディアメッセージ及び受信側ユーザ装置のアドレス表示を有する第１のメッセージを受信するように適合される。処理ユニットは、アドレス表示に基づいて受信側ユーザ装置を特定するように適合される。さらに、受信側サーバは、マルチメディアメッセージの複数の受信側ユーザ装置へのマルチキャスト配信を実行するように適合され、処理ユニットはマルチキャストアドレスの割り当てを実行するように適合され、送信ユニットはマルチキャストアドレスを受信側ユーザ装置へ送信するように適合され、処理ユニットはマルチメディアメッセージをマルチキャスト伝送に適したオブジェクトへ埋め込むように適合され、送信ユニットは、オブジェクトをマルチキャスト伝送を介して受信側ユーザ装置へ送信するように適合される。
【００３３】
好適な実施形態によれば、受信側サーバの処理ユニットは、マルチキャスト配信の実行を、例えば受信側ユーザ装置の数が閾値を超えた際にマルチキャスト配信についての適切な決定を行うことにより、受信側ユーザ装置の数に基づいて行うように適合されうる。
【００３４】
受信側サーバは、マルチキャストアドレスとともに、誤り保護方法の記述、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を送信するように適合されうる。
【００３５】
受信側サーバの処理ユニットは、アドレス表示から受信側ユーザ装置のアドレスを解決するように適合されうる。
【００３６】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための受信側サーバが開示される。受信側サーバはメッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージ及び情報を処理する処理ユニットとを有する。受信ユニットは送信側サーバからマルチメディアメッセージを受信するように適合される。送信ユニットはマルチメディアメッセージを、その受信側サーバに関連づけされた、宛先の受信側ユーザ装置へ送信するように適合される。受信ユニットは、それぞれが受信側ユーザ装置の１つにおける、個別のマルチメディアメッセージの伝送状態の表示を含む状態メッセージを受信するように適合される。処理ユニットはその表示をマルチメディアメッセージの伝送状態を表すレポートに集計する様に適合される。さらに、送信ユニットはそのレポートを送信側サーバへ送信するように適合される。
【００３７】
受信側サーバの好適な実施形態によれば、処理ユニットは例えば、送信側ユーザ装置、送信側サーバ及び受信側サーバを含むグループの少なくとも１つのエンティティから送信される要求に従って表示を編集し、編集した表示を集計するように適合されうる。
【００３８】
受信側サーバの処理ユニットは、要求を変更し、変更された要求に従って表示を編集するように適合されうる。さらに、あるいは代わりに、処理ユニットは、１つ又は複数の要求を付加し、付加された１つ又は複数の要求に従って表示を編集するように適合されうる。
【００３９】
別の好ましい実施形態によれば、受信側サーバの処理ユニットは、ある時間間隔内に受信される状態メッセージをレポートに用いるように適合されうる。
【００４０】
他の好適な実施形態によれば、受信側サーバの処理ユニットは、１つ又は複数の表示を受信側ユーザ装置の１つ又は複数のアドレスに関連させ、レポートにおける伝送状態に１つ又は複数のアドレスを関連づけるように適合されうる。
【００４１】
他の好適な実施形態によれば、受信側サーバの処理ユニットは、レポートを統計目的及び／又は課金目的で処理するように適合されうる。
【００４２】
上述した、マルチメディアメッセージを送信側ユーザ装置から受信側ユーザ装置へ効率的に伝送するための、及び複数の受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための、受信側サーバの１つ又は複数の機能は、好ましくは組み合わせ可能である。そして、組み合わせられた機能を有する受信側サーバが、本発明によるマルチキャスト配信及び改良されたレポーティングを実行するように適合されるという事実により、マルチメディアメッセージサービスの効率をさらに向上させる。
【００４３】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側サーバが開示される。送信側サーバはメッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージ及び情報を処理する処理ユニットとを有する。送信ユニットはマルチメディアメッセージを、宛先の受信側ユーザ装置が関連づけされた複数の受信側サーバに送信するように適合される。受信ユニットは複数の受信側サーバからレポートを受信するように適合される。受信されたレポートの各々は、そのレポートを送信した個々の受信側サーバに関するマルチメディアメッセージの伝送状態を表す。処理ユニットは受信した複数のレポートを、マルチメディアメッセージの伝送状態を表す別のレポートに集計する様に適合される。
【００４４】
マルチメディアメッセージは、送信側ユーザ装置から受信することが可能であり、送信側サーバの送信ユニットは、別のレポートを送信側ユーザ装置へ送信するように適合されうる。
【００４５】
送信側サーバの処理ユニットは、受信したレポートを要求に従って編集する、要求を変更する、及び要求を付加する、を含むグループからの少なくとも１つを実行するように適合されうる。
【００４６】
好ましくは送信側サーバの処理ユニットは、レポートの少なくとも１つを、統計目的及び／又は課金目的で処理するように適合されうる。
【００４７】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側ユーザ装置が開示される。送信側ユーザ装置はメッセージを受信する受信ユニットと、メッセージを送信する送信ユニットと、メッセージ及び情報を処理する処理ユニットとを有する。処理ユニットは送信側ユーザ装置のユーザによる選択に従って、レポート要求を生成するように適合される。要求は、編集のための１つ又は複数の表示に従い、集計的な方法(aggregated way)によって伝送状態を求めるために、編集のための１つ又は複数の表示を含む。送信ユニットは、その要求とマルチメディアメッセージを送信側サーバへ送信するように適合される。さらに、受信ユニットはその要求に従って送信側サーバからレポートを受信するように適合される。受信されたレポートは求められた伝送状態、すなわち１つ又は複数の表示に従い、集計的な方法で編集された伝送状態を含む。
【００４８】
ここで提案する方法はまた、その方法のステップを実行するためのコンピュータプログラムにおいて実現することができる。このコンピュータプログラムは上述した方法を実施するためのソフトウェアコード部分を含む。そのコンピュータプログラムの１つ又は複数は、１つ又は複数のコンピュータ読み取り可能な記録媒体上に格納可能である。コンピュータ読み取り可能な記録媒体は、ユーザ装置やサーバのような装置内部の固定記憶装置又は書き換え可能な記憶装置であってもよいし、外部に位置していてもよい。１つ又は複数のコンピュータプログラムは、例えばケーブル又は無線リンクを介し、信号列として装置に転送されうる。
【００４９】
受信側サーバの処理ユニットへ読み込み可能なコンピュータプログラムが開示される。このコンピュータプログラムは、請求項１から１９のいずれかに係る方法の、受信側サーバに関する任意のステップを実行するように適合されたコードを含む。
【００５０】
送信側サーバの処理ユニットへ読み込み可能なコンピュータプログラムが開示される。このコンピュータプログラムは、請求項１から１９のいずれかに係る方法の、送信側サーバに関する任意のステップを実行するように適合されたコードを含む。
【００５１】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするためのコンピュータプログラムが開示される。このコンピュータプログラムは、例えば送信側マルチメディアメッセージサービスユーザエージェントを有する、送信側ユーザ装置の処理ユニットへ読み込むことができる。このコンピュータプログラムは、編集のための１つ又は複数の表示に従い、集計的な方法によって伝送状態を求めるための、編集のための１つ又は複数の表示を含むレポート要求を、送信側ユーザ装置のユーザによる選択に従って生成するように適合されたコードと、要求と前記マルチメディアメッセージの、送信側サーバへの送信を達成するように適合されたコードと、送信側サーバから受信したレポートであって、集計的な方法によって求められた伝送状態を含むレポートを、要求に従って処理するように適合されたコードとを含む。
以下、図面を参照して、本発明の詳細な実施形態を説明する。
【発明を実施するための最良の形態】
【００５２】
図１は、ＭＭを配信するためのマルチキャスト伝送技術を用いる、最適化されたＭＭＳのための第１の実施形態を示す。マルチキャスト伝送効率を得るため、ＭＭは好ましくは多数の受信側へ宛てられる。より多くの受信側グループへのＭＭを特定するための方法には様々なものがある。この方法は、個別のアドレス（例えば電話番号）の代わりに、グループアドレスに基づいている。例としては、電子メール配信リスト、majordomoリスト又は、ＭＭ又はＭＭを搬送するメッセージ中の専用表示によるものがある。最も効率的なのは、例えば複数の受信側が同一の地理的範囲に存在する場合に共通無線チャネルを用いることなど、何らかの配信最適化である。
【００５３】
グループアドレス又はグループ名のようなグループＩＤは、複数の受信側ＭＭＳ Ｒ／Ｓに関連づけされたユーザのグループを、MM1_提出.REQメッセージＭ１００が送信側ＭＭＳ ＵＡ１００から送信側ＭＭＳ Ｒ／Ｓ１０１へ送信される際に、送信側ＭＭＳ Ｒ／Ｓ１０１へ示すため、MM1_提出.REQメッセージＭ１００に含ませることができる。 以下、グループアドレス及びグループＩＤはグループを識別するための同義語として用いる。グループアドレスは、送信側ＭＭＳ ＵＡ１００を備えるＵＥのユーザにより入力されることができる。従って、グループアドレス指定及びマルチメディアメッセージの送信機構を利用することで、エンドユーザは最先端のＭＭソリューションで必要な、個々のアドレスをすべて入力する労力から解放されるため、ユーザにとって簡単で便利な方法を提供することができる。代わりに、複数の受信側のアドレスをMM1_提出.REQメッセージＭ１００に入力してもよい。
【００５４】
MM1_提出.REQメッセージＭ１００はさらに複数の受信側に対するＭＭを含む。MM1_提出.REQメッセージＭ１００の受信は、送信側ＭＭＳ Ｒ／Ｓ１０１から送信側ＭＭＳ ＵＡ１００へ、例えばMM1_提出.RESメッセージＭ１０１により確認応答されてもよい。送信側ＭＭＳ Ｒ／Ｓ１０１は、受信側ＭＭＳ Ｒ／Ｓ１０２を識別し、ＭＭ及びグループアドレスを受信側ＭＭＳ Ｒ／Ｓ１０２へMM4_転送.REQメッセージＭ１０２を送信する。このメッセージの受信は、受信側ＭＭＳ Ｒ／Ｓ１０２により送信側ＭＭＳ Ｒ／Ｓ１０１へMM4_転送.RESメッセージＭ１０３を介して確認応答されてもよい。受信側ＭＭＳ Ｒ／Ｓ１０２がグループＭＭ、すなわちグループアドレスを伴うＭＭを取り扱えない場合、送信側ＭＭＳ Ｒ／Ｓ１０１が受信側ＭＭＳ ＵＡのアドレスを解決し、ＭＭ及びそのアドレスをMM4_転送.REQメッセージＭ１０２によって受信側ＭＭＳ Ｒ／Ｓ１０２へ転送することができ、それによって下位互換性を確保する。同様に、MM4_転送.REQメッセージＭ１０２の受信は、受信側ＭＭＳ Ｒ／Ｓ１０２により送信側ＭＭＳ Ｒ／Ｓ１０１へMM4_転送.RESメッセージＭ１０３を介して確認応答されてもよい。受信側ＭＭＳ ＵＡが複数の受信側ＭＭＳ Ｒ／Ｓによって受け持たれている場合、対応するMM4_転送.REQメッセージ及びMM4_転送.RESメッセージが、複数の受信側ＭＭＳ Ｒ／Ｓへ、また複数の受信側ＭＭＳ Ｒ／Ｓから、それぞれ送信されてよい。好ましくは、送信側ＭＭＳ Ｒ／Ｓ１０１は、受信側ＭＭＳ ＵＡが関連づけされている１つ又は複数の受信側ＭＭＳ Ｒ／Ｓを、MM1_提出.REQメッセージＭ１００のアドレスフィールドから識別し、ＭＭのコピー及び１つ又は複数のグループアドレスを、１つ又は複数の受信側ＭＭＳ Ｒ／Ｓの各々へ送信する。
【００５５】
１つ又は複数の受信側ＭＭＳ Ｒ／Ｓの各々は、その受信側グループアドレスを、受信側ＭＭＳ ＵＡの個々のアドレスへ解決することができる。個々の受信者アドレスを解決する２つの代替方法が存在する。まず１つは、複数又は１つのグループアドレスを個々のアドレスに解決するグループ解決サーバをネットワーク中で利用可能とすることである。ＭＭに関連付けられたグループアドレスのほか、グループアドレスからアドレスを解決するため、解決サーバ、例えばグループアドレスに従ってアドレスを解決し、アドレスを１つ又は複数の受信側ＭＭＳ Ｒ／Ｓへ配信するmajordomoリストサーバ、のアドレスを、表示(indication)によって受信側ＭＭＳ Ｒ／Ｓに示してもよい。もう１つの代替方法は、ＭＭ又はＭＭを有する１つ又は複数のメッセージが、グループアドレスのほかに受信者のリストを含むことである。グループアドレスは異なるグループを区別するため、またグループＭＭを示すために用いられる。これはまた、追加のグループサーバを回避する。大きなユーザグループ、例えば１００００の受信側ＭＭＳ ＵＡについては、１つ又は複数の受信側ＭＭＳ ＵＡでアドレス解決を行うことが好ましい。そうすることにより、受信側ＭＭＳ ＵＡの多くのアドレスを送信側ＭＭＳ Ｒ／Ｓから１つ又は複数のＭＭＳ Ｒ／Ｓへ送信することを回避し、短いメッセージによるネットワーク負荷及び送信側及び受信側ＭＭＳ Ｒ／Ｓでの処理労力を低減する。
【００５６】
受信側ＵＡへの効率的なＭＭの配信を提供するため、マルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）マルチキャストモードが用いられる。ＭＢＭＳは現在３ＧＰＰにおいて標準化され、TS 22.146及びTR 23.846に規定される（３ＧＰＰ  TS 22.146 V5.2.0(2002-03)及び３ＧＰＰ TR 23.846 0.3.0 (2002-01)をそれぞれ参照）。ＭＭＳ配信に基づくマルチキャストを提供するため、受信側ＭＭＳ Ｒ／Ｓ１０２はマルチキャストアドレスを割り当てる。インターネットプロトコル（ＩＰ）マルチキャストアドレスは、ただ１つの代わりに、インタフェースのグループ全体を識別する。グループ管理には、ＩＰｖ４の場合にはインターネットグループマルチキャストプロトコル（ＩＧＭＰ）(IETF RFC2236参照）が、ＩＰｖ６の場合にはマルチキャストリスナディスカバリ（ＭＬＤ）(IETF RFC2710参照）が用いられる。パケットのただ１つのコピーが送信され、かつそのパケットは受信者の近くで複製されるため、ＩＰデータグラムの効率的な伝送が可能である。
【００５７】
ＭＭはオブジェクトに埋め込まれ、ユーザデータグラムプロトコル（ＵＤＰ）伝送プロトコルを用いて受信側ＭＭＳ ＵＡへプッシュされる。”埋め込み”処理は、マルチキャストデータ配信のためのＭＭをさらに転送するため、以下に説明するようにトランスポートプロトコルの利用を必要とする。この処理は大きなＭＭの、より小さな部分への分割を含みうる。さらに、あるいは代替方法として、この処理は、誤り訂正及び誤り検出のため、冗長性の付加を含むことができる。この処理は地上波ディジタルビデオ放送(Digital Video Broadcasting-Terrestic: DVB-T)のような放送配信のためのウェブページの準備に非常に似ている。信頼性を向上させるため、DVB-Tにおけるウェブページにはデータカルーセル手法が用いられ、この手法はＭＭのマルチキャスト配信に同様に適用可能である。他の、マルチキャスト伝送に適したプロトコルの例は、ＢＴＦＴＰ(Broadcast Trivial File Transfer Protocol)がある。
【００５８】
この、ＭＭを含んだオブジェクトは、以下の説明において”プッシュオブジェクト”と呼ぶことがある。プッシュオブジェクトを受信しない全ての受信側ＭＭＳ ＵＡは、図２とともにより詳細に説明するように、最新技術による手順を用いることで、受信側ＭＭＳ Ｒ／Ｓ１０２からＭＭを読み出すことができる。
【００５９】
図１ではただ１つの受信側ＭＭＳ ＵＡ１０３のみを示したが、図２はより拡張して複数の受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎ，２０ｍを示す。従って、図１及び図２の両方に関連するステップは、並行して参照及び説明される。加えて、図２は、３つの主な時間期間ＴＰ１，ＴＰ２，ＴＰ３に再分割されたタイムスケールを開示している。最初の開始期間は、受信側ＭＭＳ Ｒ／Ｓ１０２から受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎへのMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４及び、引き続く受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎから受信側ＭＭＳ Ｒ／Ｓ１０２へのMM1_通知.RESメッセージＭ１０５，Ｍ２０５，Ｍ２０５ｎによるMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎの受信確認応答によって与えられることができる。
【００６０】
マルチキャストアドレスは、受信側ＭＭＳＲ／Ｓ１０２から受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎへ送信されるMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎに含まれる。受信側ＭＭＳ ＵＡ２０ｍへのMM1_通知.REQメッセージは図２の開始時間期間ＴＰ１に示されていない。オンラインでない移動端末が存在したり、伝送が妨害されたりするため、必ずしも全ての受信側ＭＭＳ ＵＡがMM1_通知.REQメッセージを受信するとは限らない。例えば図２によれば、受信側ＭＭＳ ＵＡ２０ｍを備える移動端末は、自分宛に送信されたMM1_通知.REQメッセージの受信に失敗しているかもしれない。受信側ＭＭＳ ＵＡへのMM1_通知.REQメッセージの送信は、その受信側ＭＭＳ ＵＡを備えるＵＥがオフラインである場合には実行されなくてもよい。
【００６１】
マルチキャストアドレス及びポートを含むMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎは、以下のオプションにより拡張することができる。最初のオプションは誤り保護方式の利用である。１つ又は複数の誤り保護方式の記述を、MM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎに含ませてよい。マルチキャストプッシュオブジェクトを破損から保護するためのいくつかの方法が存在する。
【００６２】
例えば、実際のオブジェクトにワード誤りの識別や訂正を可能とする冗長性を付加するイレイジャー符号(Erasure Codes)（例えばリードソロモン符号）を用いることができる。ワードは１ビットでも、例えば１バイトのように複数のバイトであってもよい。ディジタルファウンテン(DigitalFountain)（J.W.Byers, M.Luby, M.Mitzenmacher, A.Regeによる論文、”A Digital Fountain Approach to Reliable Distribution of Bulk Data” in Proc. ACM SIGCOMM'98, 1998年9月、参照）機構もまた、ディジタルオブジェクトに冗長性を付加する。 オブジェクトの周期的な伝送に、カルーセル又はブロードキャストディスク(Carousels or Broadcast Disks)を用いることができる。あるワード又は一部が不足している場合、受信側ＭＭＳ ＵＡは次のサイクルまで待つ。このシナリオではサイクル数に制限がある。ＭＭＳを誤りからより一層保護するため、上述の手法、機構の組み合わせを適用することもできる。
【００６３】
図２において、２番目の時間期間ＴＰ２では、受信側ＭＭＳ ＵＡがマルチキャストグループを結合し、ＭＭ受信のために自分自身の準備を行い、ＭＭの受信及び、受信確認応答することが示されている。従って、MM1_通知メッセージを拡張するためのさらなるオプションは、プッシュオブジェクトがマルチキャストチャネル上を伝送される時間期間ＴＰ２のようなタイムウィンドウの表示(indication)である。プッシュオブジェクトはマルチキャストグループに対して無限時間伝送されるわけではない。データカルーセル又はブロードキャストディスクによる周期的な繰り返しが可能であるため、タイムウィンドウは１つのプッシュオブジェクトが伝送される期間に限定されない。タイムウィンドウの例としての時間期間ＴＰ２は、伝送開始時刻及び同一のＭＭが配信される回数によって表されてもよいし、伝送の開始及び終了時刻によって表されてもよい。
【００６４】
さらに、盗聴に対して保護するため、MM1_通知メッセージにトランザクションキーを含ませることで拡張してもよい。このような通知メッセージがユニキャストベアラを介して伝送される場合、ＭＭが受信側ＭＭＳ ＵＡに配信されるチャネル及び伝送開始時刻の表示のような単純な機構で十分であろう。表示以外のコンテンツを暗号化してもよい。復号鍵は、通知メッセージ、すなわち図２によればMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎを介して送信することが可能である。必要に応じ、ディジタル権利(digital rights)情報、例えば権利オブジェクトを、通知メッセージ内もしくはそれ自身のコンテンツとともに、マルチキャストトランスポートを介して配信することができる。
【００６５】
拡張のさらなる例には、顧客に一層便利な表示を行うために、課金情報、個々のユニフォームリソースロケータ（ＵＲＬ）／ユニファイドリソースインジケータ（ＵＲＩ）、例えば信頼性は向上する反面、より高価になる可能性があるが、ＭＭＳコンテンツ検索、及び（マルチキャストアドレスに結合された）グループに対する論理名がある。論理名の例を説明する。典型的なマルチキャストアドレスは224.2.4.3である。このグループはグランプリ関連情報に用いられているかもしれない。その場合、論理名”グランプリ”が、ＩＰアドレス224.2.4.3に関連付けられるであろう。マルチキャスト伝送に用いられる伝送チャネルはマルチキャストグループによって、従ってマルチキャストアドレスによって記述される。開始時間期間ＴＰ１内でMM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎを受信した受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎは、処理Ｐ２００，Ｐ２０４，Ｐ２０ｎにおいてマルチキャストグループを結合するとともに、処理Ｐ２００，Ｐ２０４，Ｐ２０ｎにおいてプッシュオブジェクトを受信するための準備を行う。MM1_通知.REQメッセージに含まれるマルチキャストアドレスに基づいて、マルチキャストグループを結合することができる。受信側ＭＭＳ ＵＡは、ＩＧＭＰ又はＭＬＤメッセージのようなメッセージを、マルチキャストＭＭ配信に適したＭＢＭＳベアラのようなベアラを制御する、関門ＧＰＲＳサポートノード（ＧＧＳＮ）のようなエンティティへ送信することにより、マルチキャストグループを結合することができる。本実施形態によれば、受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎは、処理Ｐ２００，Ｐ２０４，Ｐ２０ｎでマルチキャストグループを結合するため、例えばＩＧＭＰ又はＭＬＤメッセージであるメッセージＭＣ１，ＭＣ２，ＭＣ３をＧＧＳＮ（図２には不図示）へ送信する。プッシュオブジェクトの受信準備のため、例えばプッシュオブジェクトを受信するためのチャネルを調整することができる。代わりに、あるいはさらに、暗号化、コーデック、及び／又はビットレートを適応可能である。さらに、ＭＭを受信のＵＥで格納又は処理するためにメモリを確保してもよい。
【００６６】
MM1_通知.REQメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎの受信は、MM1_通知.RESメッセージＭ１０５，Ｍ２０５，Ｍ２０５ｎにより、受信側ＭＭＳ Ｒ／Ｓ１０２へ確認応答されてもよい。マルチキャストデータ配信を介し、プッシュオブジェクトＭ２０６は受信側ＭＭＳ ＵＡ１０３，２０４，２０ｎへ伝送される。正確な受信の確立を高めるため、上述のようにプッシュオブジェクトはデータカルーセルを用いて何回か送信されてもよい。
【００６７】
プッシュオブジェクトの受信は、MM1_確認.REQメッセージＭ１０８，Ｍ２０８，Ｍ２０８ｎにより確認応答されることができる。
【００６８】
例えばプッシュウィンドウを逃したか、伝送上の問題によりプッシュオブジェクト又はMM1_通知.REQメッセージＭ１０４を受信し損なった受信側ＭＭＳ ＵＡ、又はオフラインの受信側ＭＭＳ ＵＡに対しては、最新技術による読み出し(retrieval)手順をＭＭの読み出しに用いることができる。図２によれば、例えばオフラインである受信側ＭＭＳ ＵＡ２０ｍは、再び通信可能となる時間期間ＴＰ３においてMM1_通知.REQメッセージＭ２０４ｍにより通知を受けることが可能である。ＭＭＳ ＵＡ２０ｍは通知メッセージＭ２０４ｍの受信を、MM1_通知.RESメッセージＭ２０５により確認応答することが可能であり、引き続きＭＭを受信側ＭＭＳ Ｒ／Ｓ１０２から読み出すことができる。代わりに、マルチキャスト配信を繰り返すことが可能であり、これはより多くの受信側ＭＭＳ ＵＡが最初のMM1_通知.REQメッセージを受信できなかった場合に好ましく行われる。
【００６９】
マルチメディアメッセージの伝送状態のレポートと、このレポートの確認応答は、図１に示すように、MM1_確認.REQメッセージＭ１０８、MM4_配信_レポート.REQメッセージＭ１０９、MM4_配信_レポート.RESメッセージＭ１１０、MM1_配信_レポート.REQメッセージＭ１１１、MM1_読了_応答_受領.REQメッセージＭ１１２、MM1_読了_応答_レポート.REQメッセージＭ１１３、MM1_読了_応答_レポート.RESメッセージＭ１１４、及びMM1_読了_応答_送信.REQメッセージＭ１１５により、最新の技術に従って実行することができる。あるいは、図３とともにより詳細に説明するように、レポート集計を用いる、より効率的なレポーティングに従って実行することができる。
【００７０】
説明する手順は、単独の受信側ＭＭＳ ＵＡに対しては図１に示すようにして適用することが可能である。しかし、複数の受信側ＭＭＳ ＵＡについて、向上した効率が得られる。ＭＭＳを提供する移動通信システムのオペレータは、ＭＭマルチキャスト配信を、閾値を超える数の受信側ＭＭＳ ＵＡに制限することができる。閾値に満たない数の受信側ＭＭＳ ＵＡのグループについては、ＭＭのユニキャスト伝送を適用することができる。閾値を超える数の受信側ＭＭＳ ＵＡについては、効率を向上させるためマルチキャストＭＭ伝送を適用する。
【００７１】
プッシュオブジェクトの伝送は、MM1_通知.REQメッセージの伝送直後に実行することができる。必要に応じ、ＭＭを受信側ＭＭＳ ＵＡへ送信するためにトリガイベントを用いることができる。MM1_通知.RESメッセージの送信による、通知メッセージの受信の確認応答が全て戻ってくるまでに時間がかかるような非常に大きなグループの場合、時刻のようなトリガイベントを好適に適用することができる 時刻イベントはまた、受信側ＭＭ ＵＡ ＵＥにおいて、MM1_通知.RESメッセージを受信側ＭＭＳ Ｒ／Ｓへ戻す前に異なる無作為な時間を生成することを可能とするためにも用いることができる。異なる時間にプッシュオブジェクトを送信すると、特に受信側ＭＭＳ ＵＡが同じ地理的領域に高密度で存在する場合、例えば同一無線ネットワークコントローラ（ＲＮＣ）に接続されている場合又は同一セル内に存在する場合に、ネットワーク負荷を低減するであろう。受信側ＭＭＳ Ｒ／ＳはMM1_通知.REQメッセージの伝送及び受信側ＭＭＳ ＵＡによるプッシュオブジェクトの受信準備Ｐ２００に時間を考慮するため、タイマを用いることができる。代わりに、プッシュオブジェクトをMM1_通知.REQメッセージの受信に応じて送信することもできる。
【００７２】
MM1_通知.REQメッセージの受信成功は、MM1_通知.RESメッセージにより受信側ＭＭＳ Ｒ／Ｓ１０２に通知することができる。受信側ＭＭＳ Ｒ／Ｓ１０２は、MM1_通知.RESメッセージの受信数が閾値を超えた後でプッシュオブジェクトを送信してもよい。また、複数の受信側ＭＭＳ ＵＡへのＭＭＳマルチキャスト配信に、複数の受信側ＭＭＳ Ｒ／Ｓが関与してもよい。複数の受信側ＭＭＳ Ｒ／Ｓを有するシステムの例を図５に示す。
【００７３】
同様の原理を無線アプリケーションプロトコル（ＷＡＰ）プッシュに適用することができる。ＷＡＰプッシュでは、まずサービス表示が例えばＳＭＳを介して伝送される。
【００７４】
ＷＡＰオーバ・ザ・エア（ＯＴＡ）仕様（www.wapforum.orgを参照）は、いわゆる”サービス表示(Service Indications)”を規定する（www.wapforum.orgから入手可能な、”サービス表示”、2001年7月31日バージョン、WAP-167-Servicelnd-20010731-a.pdfを参照）。この仕様には、サービスを表示するショートメッセージ及びユニバーサルリソースＩＤ（ＵＲＩ）が含まれている。受信後、移動デバイスはＵＲＩにより表示されるサービスを開始するか、後に延期することができる。例えば、移動デバイスはサービスをより新しい電話機のＷＡＰセクションに従い、プッシュインボックス(Push Inbox)へ入れることができる。本発明はさらに蓄積転送技術、例えばＳＭＳ又は拡張メッセージサービス（ＥＭＳ）にも適用可能である。
【００７５】
グループ管理又はグループ解決手順の一部はＭＭＳ付加価値サービスプロバイダ（ＶＡＳＰ）において実施可能である。ＭＭＳ ＶＡＳＰは送信側ＭＭＳ Ｒ／Ｓに、ＭＭが大きなグループに送信されるか、そうでないかを表示するために用いることができる。送信側ＭＭＳ Ｒ／Ｓはこの情報をＭＭの配信前に考慮してもよい。
【００７６】
図３は、確認応答及びレポートの取り扱いが改善されたＭＭＳの例を示す。ＭＭは、送信側ＭＭＳ ＵＡ３００から、複数の受信側ＭＭＳ ＵＡへ、最新技術によるユニキャスト伝送か、本発明が提案する、図１及び図２とともに説明されたＭＭＳマルチキャスト配信機構を介して送信されうる。図３では、ユニキャスト機構が示される。簡単のため、１つの受信側ＭＭＳ Ｒ／Ｓ３０２及び１つの受信側ＭＭＳ ＵＡ３０３のみが図示されているが、これらは１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ及び１つ又は複数の受信側ＭＭＳ ＵＡをそれぞれ典型的に表している。受信側ＭＭＳ Ｒ／Ｓあたり複数の受信側ＭＭＳ ＵＡへのＭＭについては、複数の受信側ＭＭＳ ＵＡと受信側ＭＭＳ Ｒ／Ｓとの間のメッセージ数が増加する（例えば、メッセージＭ３０４−Ｍ３０８，Ｍ３１２）。複数の受信側ＭＭＳ Ｒ／Ｓが関与する場合、送信側ＭＭＳ Ｒ／Ｓ３０１と複数の受信側ＭＭＳ Ｒ／Ｓ３０２との間のメッセージ（例えば、メッセージＭ３０２，Ｍ３０３，Ｍ３０９，Ｍ３１０，Ｍ３１３，Ｍ３１４）の数は、関与するＭＭＳ Ｒ／Ｓの数につれて増加する。複数の受信側ＭＭＳ Ｒ／Ｓの場合、同様の増加は、処理Ｐ３０２，Ｐ３０３，Ｐ３０５についても生じる。
【００７７】
配信、応答課金(reply charging)及び／又は読了応答レポート(read-reply reports)を制御するための機構は、送信側ＭＭＳ Ｒ／Ｓ３０１及び／又は受信側ＭＭＳ Ｒ／Ｓ３０２に提供される。この機構は、どの種類の、またどのように送信側ＭＭＳ ＵＡ３００が配信、応答課金及び／又は読了応答レポートの１つ又は複数を受信しようとしているかを表示するため、好ましくは送信側ＭＭＳ ＵＡ３００にも提供される。以下、まず送信側ＭＭＳ ＵＡ３００から送信側ＭＭＳ Ｒ／Ｓ３０１への表示を説明する。そして、確認応答及び上述したレポートの処理について説明する。
【００７８】
受信側ＵＡ３０３が複数である場合、送信側ＵＡ３００から送信側ＭＭＳ Ｒ／Ｓ３０１へ送信されるMM1_提出.REQメッセージＭ３００中の配信レポート、応答課金及び読了応答表示は、単純なイエス／ノー又は”読了”／”読まずに削除”表示から、以下に示すような詳細を含むように拡張される。
・例えば、受信側ＭＭＳ ＵＡのアドレス又はＩＤを送信側ＭＭＳ ＵＡへ通知することで要求された個々の受信側ＭＭＳ ＵＡの情報、
・所定時間内にいくつの、あるいは何パーセントの受信側ＭＭＳ ＵＡがメッセージを受信したかという必要な情報、
・要求された集計レポート、
・要求された、課金／料金情報。
【００７９】
要求されたレポートのための表示の組み合わせもまた利用可能である。好ましくは、送信側ＭＭＳ ＵＡのユーザが、例えば課金情報が補足された集計レポートの要求を示す表示を選択することにより、要求される集計レポートの形式を選択可能であり、そしてこの要求を送信側ＭＭＳ Ｒ／Ｓへ例えばMM1_提出.REQメッセージＭ３００によって送信可能である。この選択は、入力／出力ユニットを通じて行われてもよい。送信側ＭＭＳ ＵＡが配信レポート、読了応答及び応答課金を表示可能な詳細が増えると、エンドユーザの利便性が改善されるほか、より効率的な伝送方法が提供される。
【００８０】
送信側ＭＭＳ Ｒ／Ｓ３０１は要求を、送信側ＭＭＳ ＵＡ３００からのものとして、MM4_転送.REQメッセージＭ３０２により受信元ＭＭＳ Ｒ／Ｓ３０２へ送信してもよい。送信側ＭＭＳ Ｒ／Ｓ３０１はまた、処理Ｐ３０１において、送信側ＭＭＳ ＵＡ３００の要求を変更し、変更された要求を受信側ＭＭＳ Ｒ／Ｓ３０２へ送信してもよい。さらに、あるいは代わりに、送信側ＭＭＳ Ｒ／Ｓは例えば自らの統計目的又は課金／請求目的のために、１つ又は複数の要求を追加することができ、追加された要求を受信側ＭＭＳ Ｒ／Ｓ３０２に送信する。変更及び／又は追加された要求は、好ましくはMM4_転送.REQメッセージＭ３０２により送信される。
【００８１】
このような、変更された、又は付加された要求は以下のものを含む。
・所定時間内にいくつの、あるいは何パーセントの受信側がメッセージを受信したかという要求された情報、
・物理的な位置と、受信側ネットワークに関する情報。受信側ネットワーク及び／又は物理的な位置は、課金又は統計的な目的のために使用することが可能である。１つ又は複数の受信側ネットワークへの実距離又は、受信側ＭＭＳ Ｒ／Ｓ又はＵＡが同じネットワーク内にあるかどうかという事実は、課金及び統計的な目的のために使用することができる。
【００８２】
送信側ＭＭＳ Ｒ／Ｓ３０１は表示を格納可能であるとともに、引き続く手順において返送されるレポートの経過を追うことができる。また、要求されたように送信側ＭＭＳ ＵＡ３００へ通知することができる。さらに、送信側ＭＭＳ Ｒ／Ｓ３０１は自らの目的のために、情報を追跡することができる。送信側ＭＭＳ Ｒ／Ｓ３０１における情報の利用の例としては、新しいマルチユーザ課金モデルがある。このモデルでは、例えば送信側ＭＭＳ ＵＡ３００への課金が、受信側の数又は実際の配信速度に依存する。上述した、配信、応答課金及び／又は読了応答レポートを制御するための要求は、例えば図５に示すように、受信側ＭＭＳ ＵＡが異なる受信側ＭＭＳ Ｒ／Ｓに接続されている場合、送信側ＭＭＳ ＵＡ３００から、送信側ＭＭＳ Ｒ／Ｓ３０１を介して複数の受信側ＭＭＳ Ｒ／Ｓへ伝播されうる。この場合、送信側ＭＭＳ Ｒ／Ｓ３０１は受信側ＭＭＳ ＵＡのアドレスを解決可能であるとともに、関与する受信側ＭＭＳ Ｒ／Ｓごとに受信側ＭＭＳ ＵＡを配信する。ＭＭ及び上述した要求を受信側ＭＭＳ Ｒ／Ｓへ、関与する受信側ＭＭＳ Ｒ／Ｓあたり１つのMM4_転送.REQメッセージを用いて送信するため、複数のMM4_転送.REQメッセージを用いることが可能である。
【００８３】
伝播した要求を受信すると、１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ３０２は、送信側ＭＭＳ Ｒ／Ｓ３０１及び／又は送信側ＭＭＳ ＵＡ３００へ配信するように要求されたレポーティング形式に関する情報を格納可能となる。１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ３０２は、１つ又は複数の受信側ＭＭＳ ＵＡ３０３にＭＭを通知する前に、例えば自らの統計目的または課金／請求目的のために、処理Ｐ３０２により要求を追加するか、処理Ｐ３０２により受信した要求を変更することができる。
【００８４】
受信側ＭＭＳ ＵＡ３０３へのＭＭの配信は、MM1_通知.REQメッセージＭ３０４、MM1_通知.RESメッセージＭ３０５、MM1_読み出し.REQメッセージＭ３０５、及びMM1_読み出し.RESメッセージＭ３０５を介して、またＭＭが複数の受信側ＭＭＳ ＵＡへ配信される場合には類似のさらなるメッセージを用いて達成可能である。１つ又は複数の受信側ＭＭＳ ＵＡへの配信はまた、図１及び図２とともに説明したように、ＭＭＳマルチキャストを介しても達成することができる。この方法は、例えば、関与する受信側ＭＭＳ Ｒ／Ｓあたりのユーザグループが多い場合に好ましい。
【００８５】
対応するMM1_確認応答.REQメッセージＭ３０８を受信側ＭＭＳ ＵＡ３０３から受信すると、１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ３０２は処理Ｐ３０３により、送信側ＭＭＳ Ｒ／Ｓ３０１からの要求に従って情報を編集(compile)可能となる。編集において、確認応答、すなわち１つ又は複数の受信側ＭＭＳ ＵＡ３０３からのMM1_確認応答.REQメッセージＭ３０８を登録可能である。１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ３０２から受信したMM1_通知.RESメッセージＭ３０４の数から受信側ＭＭＳ ＵＡ３０３の総数を、といったように、ＭＭ配信処理から更なる情報を推論することができる。受信側ＭＭＳ ＵＡ３０３のアドレスの知見から、通知された受信側ＭＭＳ ＵＡのうち、その通知を受信したものとそうでないものが解析されてもよい。また、どの受信側ＭＭＳ ＵＡがＭＭ受信の確認応答をし、またしていないかを照合してもよい。どの受信側ＭＭＳ ＵＡがＭＭを読了したかを表す読了_応答_受信側.REQメッセージＭ３１２の１つ又は複数に対しても、同様の解析がなされてもよい。
【００８６】
このＭＭに対して受信された、全ての配信又は受信の確認応答、すなわちMM1_確認応答.REQメッセージＭ３０８及び読了_応答_受信側.REQメッセージＭ３１２が１つのMM4_配信_レポート.REQメッセージ及びMM4_読了_応答_レポート.REQメッセージにおいて送信側ＭＭＳ Ｒ／Ｓ３０１へレポートされないよう、１つ又は複数の受信側ＭＭＳ Ｒ／Ｓ３０２は配信又は受信の確認応答を１つ又は２，３の配信又は読了−応答レポートに集計することができる。
【００８７】
集計されたレポートは、ＭＭの配信及び／又は読了を確認応答した受信側ＭＭＳ ＵＡの量またはパーセンテージを含んでもよい。代わりに、あるいは追加して、このレポートは、ＭＭの配信及び／又は読了を確認応答していない受信側ＭＭＳ ＵＡの総数を含んでもよい。配信及び／又は読了を確認応答している、あるいはしていない受信側ＭＭＳ ＵＡのアドレスの表示を得ることは、送信側ＭＭＳ ＵＡ３００にとって有用であろう。そのため、受信側ＭＭＳ ＵＡのアドレスを、確認応答について集計された情報へリンクさせてもよい。レポート応答に長時間を要することのないよう、受信側ＭＭＳ Ｒ／Ｓは所定の時間間隔内に確認応答を集めることができる。この場合、確認応答は登録され、また時間間隔と一致した場合にレポートするため、編集される。この時間間隔内に受信されない確認応答は、廃棄されるか、さらなるレポートに用いられるであろう。受信側ＭＭＳ Ｒ／Ｓに内蔵された、もしくは受信側ＭＭＳ Ｒ／Ｓからアクセス可能なタイマを、確認応答の登録を行うための上述の時間間隔を開始するため及び登録を時間間隔に従って中止するために用いることができる。タイマの開始は、メッセージＭ３０４又はメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎの１つ又は複数のようなMM1_通知.REQメッセージや、マルチキャスト配信（図１及び図２のメッセージＭ１０６、Ｍ２０６）によってトリガされてもよい。集計されたＭＭＳレポートのため、MM1_通知.REQメッセージで受信側ＭＭＳ ＵＡへ送信することの可能なトランザクションＩＤを用いて、ＭＭの配信及び読了について受信された確認応答をＭＭに関連付けてもよい。
【００８８】
配信及び読了の確認応答の情報を含む集計レポートの例を、表Ａに示す。このレポートはＭＭ識別子（ＭＤ ＩＤ）を含んでいる。さらに、レポートは宛先の受信側ＭＭＳ ＵＡの総数、すなわちマルチキャストグループのようなグループの場合にＭＭが配信されるべき受信側ＭＭＳ ＵＡの数を特定している。宛先の受信側ＭＭＳ ＵＡの総数はグループ内の受信側ＭＭＳ ＵＡの数となる。代わりに、受信側ＭＭＳ ＵＡの総数は送信側ＭＭＳ ＵＡのユーザが選択した、ＭＭが配信されるべきアドレスの数を特定してもよい。通知された受信側ＭＭＳ ＵＡの総数は、例えば、通知された受信側ＭＭＳ ＵＡから送信されたMM1_通知.RESメッセージ（例えばメッセージＭ１０５，Ｍ２０５，Ｍ２０５ｎ，Ｍ３０５）を計数することにより求めることができる。代わりに、受信側ＭＭＳ ＵＡへのMM1_通知.RESメッセージ（例えばメッセージＭ１０４，Ｍ２０４，Ｍ２０４ｎ，Ｍ３０４）を計数してもよい。同様に、ＭＭを受信した受信側ＭＭＳ ＵＡの総数を、ＭＭを受信した受信側ＭＭＳ ＵＡからのMM1_確認応答.REQメッセージ（例えばメッセージＭ１０８，Ｍ２０８，Ｍ２０８ｎ，Ｍ３０８）や、対応する配信メッセージ（例えばメッセージＭ１０６，Ｍ３０７）を計数することで求めることができる。ＭＭを読了した受信側ＭＭＳ ＵＡの総数は、例えばＭＭの読了を確認するために受信側ＭＭＳ ＵＡから送信されるMM1_読了_応答_受信側.REQメッセージ（例えばＭ１１２，Ｍ３１２）を計数することによって求めることができる。
【００８９】
【表１】
2005532714.tif 000003
【００９０】
受信側ＭＭＳ ＵＡから送信される、上述のメッセージを用いて個々の総数を求めることにより、確認応答された、すなわち確認された情報がレポート生成に用いられるという利点がある。受信側ＭＭＳ ＵＡへのメッセージを計数することで、より迅速なレポート生成が達成できるであろうこと、また受信側ＭＭＳ ＵＡからの確認応答メッセージを省略(skip)することができるであろうこと等の利点がある。
【００９１】
受信側ＭＭＳ ＵＡのアドレスに関する情報を含む個々の確認応答メッセージを相互に関連付けることで、通知を受け取れなかった受信側ＭＭＳ ＵＡ、ＭＭの配信を確認応答していない受信側ＭＭＳ ＵＡ及び／又はＭＭの読了を確認応答していない受信側ＭＭＳ ＵＡのアドレスに関する情報を見いだすことができる。
【００９２】
配信時間、MM1_確認応答.REQ受信や、MM1_読了_応答_受信側.REQ受信のための時間間隔のような、指定されてもよい更なる情報は、個々の確認応答メッセージ集計間隔をレポートの読者に示す。
【００９３】
【表２】
2005532714.tif 000004
【００９４】
１つ又は複数の受信側ＭＭＳ Ｒ／Ｓが送信側ＭＭＳ Ｒ／Ｓと異なるネットワークに位置している場合には、ネットワークＩＤのような情報をレポートに追加してもよい。１つ又は複数の受信側ＭＭＳ Ｒ／Ｓは集計されたレポートを送信側ＭＭＳ Ｒ／Ｓへ送信し、好ましくは送信側ＭＭＳ Ｒ／Ｓは受信したレポートを、配信及び／又は読了レポートが送信側ＭＭＳ ＵＡ３００へ送信される前に、編集及びさらに集計する。編集及びさらなる集計の例は、表Ｂ、Ｃ及びＤに見いだすことができる。
【００９５】
表Ｂ、Ｃ及びＤから、編集及び集計によりレポートをますます圧縮可能であることが理解できる。さらに、レポート中の情報の選択及び／又は更なる処理が可能である。例えば、送信側ＭＭＳ ＵＡのユーザには、関与した受信側ＭＭＳ Ｒ／ＳのＩＤを提供する必要はないであろう。そのため、この情報は送信側ＭＭＳ ＵＡへのレポート中では省略される。
【００９６】
配信及び読了−応答レポートの集計は、同一のＭＭに複数の受信側がある場合、対応する状態のより適切な概況を送信側ＭＭＳ ＵＡ及びリレー／サーバの両方に提供する。この集計制御機構は、例えば送信側及び受信側ＭＭＳ リレー／サーバが、本発明による１つ又は複数のレポートにおける適切なエントリを解析することによって、ＭＭを受信及び／又は読了する受信側ＭＭＳ ＵＡの数を知ることができるように構成されているため、例えばＭＭを受信した宛先の数及び／又はＭＭを読了した宛先の数を、そのＭＭを送信したユーザの課金に考慮することができる、より洗練されたグループＭＭＳ課金を可能とする。送信側ＭＭＳ ＵＡのユーザの課金は、例えば課金サーバのような他のエンティティによって、本発明によるレポートの１つ又は複数に基づいて実行されてもよい。送信側ＭＭＳ ＵＡ又は送信側ＭＭＳ ＵＡのユーザは、例えば、ＭＭを逃した（例えば受信していない）１つ又は複数のＵＡへのＭＭ伝送を開始するため、本発明による、編集及び集計された１つ又は複数のレポートによって提供される情報を解析することができる。
【００９７】
例えば、より少ない数のメッセージでＭＭの受信及び／又は読了をレポートすることが可能であることにより、伝送資源がより効率的に用いられるので、送信側ＭＭＳ ＵＡの課金額も少なくなる。従って、集計を用いた応答−課金はオペレータの差別化が可能なサービスである。応答−課金の場合、送信側ＭＭＳ ＵＡが応答メッセージに対する支払いを行う。応答−メッセージの場合、受信側ＭＭＳ Ｒ／Ｓ及び送信側ＭＭＳ Ｒ／Ｓがその応答を１つの集約応答−メッセージに編集することができる。例えば、イエス／ノーのみ、又は１／２が有効な回答である場合、送信側又は受信側ＭＭＳ Ｒ／Ｓは、イエスかノー、又は１か２を表すグループ応答メッセージを、応答した受信側ＭＭＳ ＵＡの数又はパーセントとともに編集することができる。
【００９８】
最新の技術によれば、もし全ての宛先ＭＭＳ ＵＡがＭＭの配信及び読了を確認応答する場合には、複数の受信側ＭＭＳ ＵＡへのＭＭ配信について、最大で同数の配信レポート及び同数の読了応答という可能性がある。本発明によれば、送信側ＭＭＳ ＵＡへのただ１つのレポートだけが必要である。受信側ＭＭＳ ＵＡが１つの受信側ＭＭＳ Ｒ／Ｓによって受け持たれている場合、受信側ＭＭＳ Ｒ／Ｓから送信側ＭＭＳ Ｒ／Ｓへはただ１つのレポートのみが必要である。宛先の受信側ＭＭＳ ＵＡが異なる受信側ＭＭＳ Ｒ／Ｓに属している場合、各受信側ＭＭＳ Ｒ／Ｓはレポートを送信側ＭＭＳ Ｒ／Ｓへ送信することができる。そのため、複数の受信側ＵＡが１つの受信側ＭＭＳ Ｒ／Ｓによって受け持たれている場合と比較して、レポートの数が若干増加する。受信側ＭＭＳ ＵＡ又は、関与する受信側ＭＭＳ Ｒ／Ｓの数と無関係ないかなる場合においても、送信側ＭＭＳ ＵＡはただ１つの集計されたレポートを受信することを保証することが可能である。
【００９９】
本発明が提案する方法の柔軟性により、送信側ＭＭＳ ＵＡはさらに複数のレポートの提供を受けることができる。例えば、送信側は所定時間間隔内、例えばＭＭの配信後数分以内、にＭＭを受信した受信側ＵＡの総数を提示する最初のレポートを受け取り、その後、例えばＭＭ配信から数時間後に、ＭＭを読了したユーザの総数を示す２番目のレポートを受け取る。
【０１００】
本発明が提案する方法の有効性を例を用いて説明する。ある送信側が、３つの受信側ＭＭＳ Ｒ／Ｓに割り当てられた１０，０００の受信側ＵＡにＭＭを送信する。最新技術によれば、最大１０，０００の配信レポート及び最大１０，０００の読了レポートが生成され、受信側ＭＭＳ Ｒ／Ｓから送信側Ｒ／Ｓへ伝送される。そして、送信側Ｒ／Ｓは最大１０，０００の配信レポートと、最大１０，０００の読了レポートを送信側ＭＭＳ ＵＡへ転送する。総計で最大４０，０００のレポートメッセージが送信される。加えて、MM4_配信_レポート.REQメッセージ及びMM4_読了_応答_レポート.REQメッセージの受信を確認応答するための確認応答メッセージ、すなわちMM4_配信_レポート.RESメッセージ及びMM4_読了_応答_レポート.RESメッセージのそれぞれが、確認応答メッセージの各形式に対して最大で１０，０００に達する。３ＧＰＰ技術仕様23.140 V4.6.0(2002-03)に記述される手順に従って関与するエンティティにより、総計６０，０００のメッセージが生成、伝送及び処理されねばならない。本発明に従って提案される方法によれば、配信及び読了情報を有する、受信側ＭＭＳ Ｒ／Ｓから送信側ＭＭＳ Ｒ／Ｓへの最小で３つのレポートが必要であり、送信側ＭＭＳ ＵＡへはただ１つのレポートのみが必要であるに過ぎない。総計で、わずか４レポートが必要であるに過ぎない。レポートの受信を確認応答するための３メッセージ、すなわち送信側ＭＭＳ Ｒ／Ｓから３つの受信側ＭＭＳ Ｒ・Ｓｐへ送信される３つの確認応答メッセージを追加し、メッセージの総数は７であり、最新技術による方法による６０，０００のメッセージと比較して非常に少ない。
【０１０１】
任意数の受信側ＭＭＳ ＵＡ及び任意数の受信側ＭＭＳ Ｒ／Ｓに対し、従来技術及び本発明によって必要とされるメッセージ数は、以下のようにして算出可能である。
受信側ＭＭＳ ＵＡの総数：  Ｎ
Ｎの受信側ＭＭＳ ＵＡを受け持つ受信側ＭＭＳ Ｒ／Ｓの数：  Ｍ
従来技術によるメッセージの最大数：  ６×Ｎ
本発明によるメッセージの最小数：  ２×Ｍ＋１
【０１０２】
従来技術によるメッセージの最大数を計算するため、全ての宛先受信側ＭＭＳ ＵＡが配信及び読了を応答確認したものと仮定している。MM4_配信_レポート.REQメッセージ、MM4_配信_レポート.RESメッセージ、MM1_配信_レポート.REQメッセージ、MM4_読了_応答_レポート.REQメッセージ、MM4_読了_応答_レポート.RESメッセージ及びMM1_読了_応答_送信側.REQメッセージのみが、従来技術に従った計算に考慮されている。
【０１０３】
本発明によるメッセージの最小数を計算するため、配信及び読了応答情報は１つのレポートに集計されているものと仮定している。すなわち、メッセージＭ３０９及びＭ３１３に含まれる情報は１つのレポートに結合され、さらにメッセージＭ３１０及びＭ３１４も結合する。加えて、本発明によるメッセージの最小数を計算するために、メッセージＭ３１１及びＭ３１５が結合されている。しかし、異なるレポートの結合は、ただ１つの受信側ＭＭＳ ＵＡのみが宛先となる場合であっても、一層の効果を保証する。いかなる場合であっても、本発明を用いることで、配信及び読了についてのレポート数を受信側ＭＭＳ ＵＡの数から切り離すことが可能である。
【０１０４】
図４は、典型的な装置及び装置間の接続とともにマルチキャストＭＭ配信を示す図である。ＭＭは第１のエンティティＮ４００からサービスネットワークＮ４０１、コアネットワークＮ４０２及び無線アクセスネットワークＮ４０３、効率的に共用チャネルを介して、ここでは移動電話及びスマートフォンとして図示される、複数の受信側ＵＡ Ｎ４１０，Ｎ４２０，Ｎ４３０へ送信される。最初のエンティティＮ４００は送信側ＭＭＳ ＵＡ、送信側ＭＭＳ Ｒ／Ｓ又は受信側ＭＭＳ Ｒ／Ｓであってよい。複数の宛先アドレスではなく、１つのグループアドレスを用いることで、特に乏しい無線インタフェース資源の効率的及び効果的な利用を可能とする。
【０１０５】
図５は、本発明を実施するためのＭＭＳシステムの典型的な実施形態を示す図である。システムは、複数の受信側ＭＭＳ Ｒ／Ｓ Ｓ２０，Ｓ３０，Ｓ４０によって受け持ちされる複数の受信側ＭＭＳ ＵＡ Ｄ０２−Ｄ０８を備える。ネットワーク要素が１つのアドミニストレーションの制御下にある場合、ＭＭＳＥ Ｅ１００−Ｅ４００によって示されているように、ＭＭＳシステムに対してＭＭＳ環境（ＭＭＳＥ）という表現が用いられることがある。本例によれば、複数の受信側ＭＭＳ ＵＡ Ｄ０２−Ｄ０８は受信側ＭＭＳ Ｒ／Ｓ Ｓ２０，Ｓ３０，Ｓ４０に、無線アクセスネットワークＲＡ０２，ＲＡ０３，ＲＡ０４によってアタッチされている。ＭＭは送信側ＭＭＳ ＵＡ Ｄ０１から、第１の無線アクセスネットワークＲＡ０１を介して送信側ＭＭＳ Ｒ／Ｓ Ｓ１０へ送信可能である。好ましいレポートは送信側ＭＭＳ ＵＡ Ｄ０１により送信側ＭＭＳ Ｒ／Ｓ Ｓ１０へ通知されるであろう。ＭＭは受信側ＭＭＳ Ｒ／Ｓ Ｓ２０−Ｓ４０へ分配されることができ、またマルチキャストを介して受信側ＭＭＳ ＵＡ Ｄ０２−Ｄ０８へ配信されることができる。本発明によれば、ＭＭ配信に対して好ましくはマルチキャスト伝送が用いられる。しかし、例えばＭＭ配信に関与する１つ又は複数の構成要素がマルチキャストの能力を持っていない場合や、受信側ＭＭＳ Ｒ／Ｓあたりの受信側ＭＭＳ ＵＡの数が所定の閾値未満である場合には、ユニキャスト伝送もまた可能である。さらに、マルチキャストとユニキャストの組み合わせも可能であり、例えば受信側ＭＭＳ ＵＡ Ｄ０２−Ｄ０７に対してはマルチキャスト配信を、受信側ＭＭＳ ＵＡ Ｄ０８に対してはユニキャスト配信するといったことができる。
【０１０６】
受信側ＭＭＳ ＵＡ Ｄ０２−Ｄ０８からのMM1_確認応答.REQメッセージやMM1_読了_応答_受信側.REQメッセージ等の確認応答は、受信側ＭＭＳ Ｒ／Ｓ Ｓ２０，Ｓ３０，Ｓ４０によってレポートに編集及び集計され、送信側ＭＭＳ Ｒ／Ｓ Ｓ１０へ伝送される。送信側ＭＭＳ Ｒ／Ｓ Ｓ１０は好ましくは受信側ＭＭＳ Ｒ／Ｓ Ｓ２０，Ｓ３０，Ｓ４０からのレポートをさらに編集及び集計する。そしてようやく、送信側ＭＭＳ ＵＡ Ｄ０１のユーザ又はＭＭＳを提供するオペレータの設定(preference)に従って、ＭＭに関するレポートが送信側ＭＭＳ ＵＡ Ｄ０１へ送信可能となる。オペレータによる設定は、変更及び追加機能によって設定することが可能である。
【０１０７】
要約すれば、ＭＭＳを提供する電気通信ネットワークのオペレータ及びＭＭＳのユーザ双方が、本発明による一層の効率性から利益を享受する。受信側ＭＭＳ Ｒ／Ｓの高い処理負荷及び、特に無線ネットワークにおいて負担の大きな莫大なメッセージ労力を、効率的なマルチキャスト配信及び、レポートの編集及び集計により最小化することが可能である。この種のネットワーク資源の節約は、ＭＭＳのための費用を直接削減することが可能であり、ＭＭＳをより一層普及させるための一助となる。別の重要な側面は、集計されたレポートが、最新技術と同様に１つのメッセージによりレポートする方法と比べ、一般にはよりユーザフレンドリーであるということである。本発明は、例えば、汎用パケット無線システム（ＧＰＲＳ）及び汎用移動電気通信システム（ＵＭＴＳ）標準に従う２Ｇ、２．５Ｇ及び３Ｇ電気通信システムにおいて使用されるように適合されることが可能である。
【０１０８】
上述の実施形態及び以下の用語集は、本発明を限定するものではなく、例示として解されるべきものであり、特許請求の範囲と同等の意味及び範囲内に含まれる変形は本発明に含まれるべきものである。
【０１０９】
用語集
エンティティ：
送信側ＭＭＳ ＵＡ    １００，３００，Ｄ０１
送信側ＭＭＳ Ｒ／Ｓ    １０１，３０１，Ｓ１０
受信側ＭＭＳ Ｒ／Ｓ    １０２，３０２，Ｓ２０，Ｓ３０，Ｓ４０
受信側ＭＭＳ ＵＡ    １０３，２０４，２０ｎ，２０ｍ，Ｄ０２−Ｄ０８
【０１１０】
メッセージ：
MM1_提出.REQメッセージ    Ｍ１００，Ｍ３００
MM1_提出.RESメッセージ    Ｍ１０１，Ｍ３０１
MM4_転送.REQメッセージ    Ｍ１０２，Ｍ３０２
MM4_転送.RESメッセージ    Ｍ１０３，Ｍ３０３
MM1_通知.REQメッセージ    Ｍ１０４，Ｍ２０４，Ｍ２０４ｎ，Ｍ２０４ｍ，Ｍ３０４
MM1_通知.RESメッセージ    Ｍ１０５，Ｍ２０５，Ｍ２０５ｎ，Ｍ２０５ｍ，Ｍ３０５
マルチキャストデータ配信メッセージ    Ｍ１０６
ＩＧＭＰ又はＭＬＤメッセージ    ＭＣ１，ＭＣ２，ＭＣ３
MM1_読み出し.REQメッセージ    Ｍ３０６
MM1_読み出し.RESメッセージ    Ｍ３０７
MM1_確認応答.REQメッセージ    Ｍ１０８，Ｍ２０８，Ｍ２０８ｎ，Ｍ３０８
MM4_配信_レポート.REQメッセージ    Ｍ１０９，Ｍ３０９
MMM4_配信_レポート.RESメッセージ    Ｍ１１０，Ｍ３１０
MM1_配信_レポート.RESメッセージ    Ｍ１１１，Ｍ３１１
MM1_読了_応答_受信側.REQメッセージ    Ｍ１１２，Ｍ３１２
MM1_読了_応答_レポート.REQメッセージ    Ｍ１１３，Ｍ３１３
MM1_読了_応答_レポート.RESメッセージ    Ｍ１１４，Ｍ３１４
MM1_読了_応答_送信側.REQメッセージ    Ｍ１１５，Ｍ３１５
【図面の簡単な説明】
【０１１１】
【図１】マルチキャストを介したＭＭ配信のためのメッセージフローを示す図である。
【図２】複数の受信側ＭＭＳ ＵＡへのマルチキャストＭＭ配信のためのメッセージフローを示す図である。
【図３】最適化された確認応答及びレポーティングを用いるＭＭＳのためのメッセージフローを示す図である。
【図４】マルチキャストＭＭ配信を提供するための、単純化されたシステムを示す図である。
【図５】ＭＭＳシステムの代表的な実施形態を示す図である。
【図１】
2005532714.tif 000005
【図２】
2005532714.tif 000006
【図３】
2005532714.tif 000007
【図４】
2005532714.tif 000008
【図５】
2005532714.tif 000009
【手続補正書】
【提出日】平成16年6月14日(2004.6.14)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信側ユーザ装置から受信側ユーザ装置へマルチメディアメッセージを効率的に伝送するための方法であって、
前記マルチメディアメッセージ及び前記受信側ユーザ装置のアドレス表示を含む第１のメッセージを前記送信側ユーザ装置から送信側サーバへ送信するステップと、
前記受信側ユーザ装置が関連づけされた受信側サーバを、前記アドレスの前記表示に基づいて特定するステップと、
前記第１のメッセージを前記受信側サーバへ送信するステップと、
前記アドレスの表示に基づいて前記受信側ユーザ装置を特定するステップと、
前記受信側ユーザ装置への前記マルチメディアメッセージのマルチキャスト配信を、
ｉ．マルチキャストアドレスを割り当てるステップと、
ｉｉ．前記マルチキャストアドレスを前記受信側ユーザ装置へ送信するステップと、
ｉｉｉ．マルチキャスト伝送に適したオブジェクトへ前記マルチメディアメッセージを埋め込むステップと、
ｉｖ．前記受信側ユーザ装置により、前記オブジェクトを受信するための準備を行うステップと、
ｖ．前記受信側ユーザ装置により、前記マルチキャストアドレスに従ったマルチキャストグループの結合を行うステップと、
ｖｉ．前記受信側ユーザ装置へ、前記オブジェクトを前記マルチキャスト伝送を介して送信するステップ、
によって実行するステップとを有することを特徴とする方法。
【請求項２】
前記マルチキャスト配信の実行ステップが、受信側ユーザ装置の数に基づくことを特徴とする請求項１記載の方法。
【請求項３】
前記受信側ユーザ装置が、前記マルチキャストアドレスとともに、誤り保護方法の説明、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、前記マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を受信することを特徴とする請求項１又は請求項２記載の方法。
【請求項４】
前記送信側サーバ及び前記受信側サーバの少なくとも１つは、前記アドレス表示から前記受信側ユーザ装置の前記アドレスを解決することを特徴とする請求項１乃至請求項３のいずれか１項に記載の方法。
【請求項５】
前記受信側ユーザ装置が、前記アドレス表示に基づいて特定される、１つより多い受信側サーバに関連づけられ、前記第１のメッセージが前記１つより多い受信側サーバに送信されるとともに、前記１つより多い受信側サーバの各々が、自らに関連付けられた受信側ユーザ装置を特定し、前記マルチメディアメッセージの、自らに関連付けられた受信側ユーザ装置へのマルチキャスト配信を実行することを特徴とする請求項１乃至請求項４のいずれか１項に記載の方法。
【請求項６】
送信側ユーザ装置から受信側ユーザ装置へ、マルチメディアメッセージの伝送状態を効率的にレポートするための方法であって、
送信側サーバからのマルチメディアメッセージを受信側サーバで受信するステップと、
前記マルチメディアメッセージを、受信側サーバから、当該受信側サーバに関連づけされた、宛先の前記受信側ユーザ装置へ送信するステップと、
前記受信側ユーザ装置の１つにおける、前記マルチメディアメッセージの個別の伝送状態の表示を含む状態メッセージを受信するステップと、
前記表示を、前記マルチメディアメッセージの前記伝送状態を表す１つのレポートに集計するステップと、
前記レポートを前記送信側サーバへ送信するステップとを有することを特徴とする方法。
【請求項７】
前記個別の伝送状態の表示の少なくとも１つが、前記マルチメディアメッセージに関する通知の確認応答、前記マルチメディアメッセージの配信の確認応答及び、前記マルチメディアメッセージの読了の確認応答の少なくとも１つを含むことを特徴とする請求項６記載の方法。
【請求項８】
前記送信側サーバが、前記マルチメディアメッセージを送信側ユーザ装置から受信することを特徴とする請求項６又は請求項７記載の方法。
【請求項９】
前記表示が、前記送信側ユーザ装置、前記送信側サーバ及び前記受信側サーバを含むグループの少なくとも１つのエンティティから送信される要求に従って編集され、前記編集された表示が集計されることを特徴とする請求項６乃至請求項８のいずれか１項に記載の方法。
【請求項１０】
前記要求が変更可能であるか、１つ又は複数の要求が前記要求に追加可能であることを特徴とする請求項９記載の方法。
【請求項１１】
ある時間間隔内に受信される前記状態メッセージが前記レポートに用いられることを特徴とする請求項６乃至請求項１０のいずれか１項に記載の方法。
【請求項１２】
１つ又は複数の前記表示は、前記受信側ユーザ装置の１つ又は複数のアドレスに関連することが可能であり、前記レポートは前記伝送状態に関する前記１つ又は複数のアドレスを含むことを特徴とする請求項６乃至請求項１１のいずれか１項に記載の方法。
【請求項１３】
前記レポートが統計的及び／又は課金目的で処理されることを特徴とする請求項６乃至請求項１２のいずれか１項に記載の方法。
【請求項１４】
前記受信側ユーザ装置が複数の受信側サーバに関連づけされ、前記送信側サーバは前記マルチメディアメッセージを前記複数の受信側サーバへ送信するとともに、各々が前記複数の受信側サーバの各々に関する前記マルチメディアメッセージの伝送状態を表す複数のレポートを受信し、さらに前記送信側サーバは、前記複数のレポートを、前記マルチメディアメッセージの前記伝送状態を表す１つの別レポートに集計することを特徴とする請求項６乃至請求項１３のいずれか１項に記載の方法。
【請求項１５】
前記送信側ユーザ装置が、送信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項１乃至請求項１４のいずれか１項に記載の方法。
【請求項１６】
前記受信側ユーザ装置の各々が、受信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項１乃至請求項１５のいずれか１項に記載の方法。
【請求項１７】
前記送信側サーバが、送信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項１乃至請求項１６のいずれか１項に記載の方法。
【請求項１８】
前記受信側サーバが、受信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項１乃至請求項１７のいずれか１項に記載の方法。
【請求項１９】
請求項６乃至請求項１８のいずれか１項に記載の方法のステップをさらに有することを特徴とする請求項１乃至請求項５のいずれか１項に記載の方法。
【請求項２０】
マルチメディアメッセージを受信側ユーザ装置へ効率的に伝送するための受信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
マルチメディアメッセージ及び受信側ユーザ装置のアドレス表示を含む第１のメッセージを受信し、前記アドレス表示に基づいて前記受信側ユーザ装置を特定し、前記マルチキャストメッセージの前記受信側ユーザ装置へのマルチキャスト配信を実行するように適合されるとともに、マルチキャストアドレスを割り当て、前記マルチメディアメッセージをマルチキャスト伝送に適したオブジェクトへ埋め込み、前記マルチキャストアドレスをマルチキャストグループへ結合するとともに、前記オブジェクトの受信の準備を行うために通知メッセージにより前記受信側ユーザ装置へ送信し、前記オブジェクトを前記マルチキャスト伝送を介して前記受信側ユーザ装置へ送信するように適合されることを特徴とする受信側サーバ。
【請求項２１】
受信側ユーザ装置の数に基づいて前記マルチキャスト配信を実行するように適合されることを特徴とする請求項２０記載の受信側サーバ。
【請求項２２】
前記マルチキャストアドレスとともに、誤り保護方法の記述、タイムウィンドウ、トランザクションキー、課金情報、ユニフォームリソースロケータ、ユニフォームリソースインジケータ、マルチキャストアドレスと結合されたマルチキャストグループの論理名、伝送開始時刻、及び伝送数を含むグループからの少なくとも１つの項目を送信するように適合されることを特徴とする請求項２０又は請求項２１記載の受信側サーバ。
【請求項２３】
前記アドレス表示から前記受信側ユーザ装置のアドレスを解決するように適合されることを特徴とする請求項２０乃至請求項２０のいずれか１項に記載の受信側サーバ。
【請求項２４】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための受信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
送信側サーバから前記マルチメディアメッセージを受信し、前記マルチメディアメッセージを、前記受信側サーバに関連づけされた宛先の受信側ユーザ装置へ送信し、それぞれが前記受信側ユーザ装置の１つにおける個別の前記マルチメディアメッセージの伝送状態の表示を含む状態メッセージを受信するように適合されるとともに、前記表示を前記マルチメディアメッセージの前記伝送状態を表す１つのレポートに集計し、前記レポートを前記送信側サーバへ送信するように適合されることを特徴とする受信側サーバ。
【請求項２５】
送信側ユーザ装置、前記送信側サーバ及び前記受信側サーバを含むグループの少なくとも１つのエンティティから送信される要求に従って前記表示を編集し、前記編集した表示を集計するように適合されることを特徴とする請求項２４記載の受信側サーバ。
【請求項２６】
前記要求を変更し、前記変更された要求に従って前記表示を編集するか、１つ又は複数の要求を追加し、当該追加された１つ又は複数の要求に従って前記表示を編集するように適合されることを特徴とする請求項２４又は請求項２５記載の受信側サーバ。
【請求項２７】
ある時間間隔内に受信される前記状態メッセージを前記レポートに用いるように適合されることを特徴とする請求項２４乃至請求項２６のいずれか１項に記載の受信側サーバ。
【請求項２８】
１つ又は複数の前記表示を前記受信側ユーザ装置の１つ又は複数のアドレスに関連させ、前記レポートにおける前記伝送状態に前記１つ又は複数のアドレスを関連づけるように適合されることを特徴とする請求項２４乃至請求項２７のいずれか１項に記載の受信側サーバ。
【請求項２９】
前記レポートを統計的及び／又は課金目的で処理するように適合されることを特徴とする請求項２４乃至請求項２８のいずれか１項に記載の受信側サーバ。
【請求項３０】
受信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項２０乃至請求項２９のいずれか１項に記載の受信サーバ。
【請求項３１】
請求項２４乃至請求項３０のいずれか１項に記載の受信側サーバの機能をさらに有することを特徴とする請求項２０乃至請求項２３のいずれか１項に記載の受信側サーバ。
【請求項３２】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側サーバであって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
前記マルチメディアメッセージを、宛先の前記受信側ユーザ装置が関連づけされた複数の受信側サーバに送信し、前記複数の受信側サーバから、レポートの送信側である個々の受信側サーバに関する前記マルチメディアメッセージの前記伝送状態を表すレポートを受信し、受信した複数の前記レポートを、前記マルチメディアメッセージの前記伝送状態を表す別のレポートに集計する様に適合されることを特徴とする送信側サーバ。
【請求項３３】
前記マルチメディアメッセージが送信側ユーザ装置から受信され、前記送信側サーバが前記別のレポートを前記送信側ユーザ装置へ送信するように適合されることを特徴とする請求項３２記載の送信側サーバ。
【請求項３４】
要求に従って編集する、要求を変更する、及び要求を付加する、を含むグループからの少なくとも１つを実行するように適合されることを特徴とする請求項３２又は請求項３３記載の送信側サーバ。
【請求項３５】
前記レポート及び前記別のレポートの少なくとも１つを、統計的及び／又は課金目的で処理するように適合されることを特徴とする請求項３２乃至請求項３４のいずれか１項に記載の送信側サーバ。
【請求項３６】
送信側マルチメディアメッセージサービスリレーサーバであることを特徴とする請求項３２乃至請求項３５のいずれか１項に記載の送信側サーバ。
【請求項３７】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための送信側ユーザ装置であって、
メッセージを受信する受信ユニットと、
メッセージを送信する送信ユニットと、
メッセージ及び情報を処理する処理ユニットとを有し、
編集のための１つ又は複数の表示に従い、集計的な方法によって前記伝送状態を求めるための前記編集のための１つ又は複数の表示を含むレポート要求を、前記送信側ユーザ装置のユーザによる選択に従って生成するように適合されるとともに、前記要求と前記マルチメディアメッセージを送信側サーバへ送信し、前記要求に従って前記送信側サーバから、前記集計的な方法によって求められた伝送状態を含む前記レポートを受信するように適合されることを特徴とする送信側ユーザ装置。
【請求項３８】
送信側マルチメディアメッセージサービスユーザエージェントを有することを特徴とする請求項３７記載の送信側ユーザ装置。
【請求項３９】
受信側サーバの処理ユニットに読み込み可能なコンピュータプログラムであって、請求項１から請求項１９のいずれかに係る方法の、前記受信側サーバに関するステップを実行するように適合されたコードを含むことを特徴とするコンピュータプログラム。
【請求項４０】
送信側サーバの処理ユニットに読み込み可能なコンピュータプログラムであって、請求項１から請求項１９のいずれかに係る方法の、前記送信側サーバに関するステップを実行するように適合されたコードを含むことを特徴とするコンピュータプログラム。
【請求項４１】
受信側ユーザ装置へ宛てられたマルチメディアメッセージの伝送状態を効率的にレポートするための、送信側ユーザ装置の処理ユニットに読み込み可能なコンピュータプログラムであって、
編集のための１つ又は複数の表示に従い、集計的な方法によって前記伝送状態を求めるための、前記編集のための１つ又は複数の表示を含むレポート要求を、前記送信側ユーザ装置のユーザによる選択に従って生成するように適合されたコードと、前記要求と前記マルチメディアメッセージの、送信側サーバへの送信を達成するように適合されたコードと、前記送信側サーバから受信したレポートであって、前記集計的な方法によって求められた前記伝送状態を含むレポートを、前記要求に従って処理するように適合されたコードとを含むことを特徴とするコンピュータプログラム。


【国際調査報告】
2005532714.tif 000010
2005532714.tif 000011
2005532714.tif 000012
2005532714.tif 000013
2005532714.tif 000014