JP2004173284A - 遠隔通信網を介したマルチメディアメッセージの追跡方法と追跡装置 - Google Patents

Abstract

【課題】マルチメディアメッセージの進行時間を測定し、ルーティングの過程でマルチメディアメッセージが受けた改変を検出する。
【解決手段】マルチメディアメッセージ生成モジュールで、オブジェクトフィールド内にマルチメディアメッセージに関する情報を組み込んで作成されたマルチメディアメッセージが、遠隔通信網を介して送信（１０５）され、中継サーバーによって受信（１０６）される。そして、中継サーバーが、宛先フィールドによって、識別された宛先に向けて、オブジェクトフィールドの情報を含むマルチメディアメッセージの受信の第一通知メッセージを作成して伝達（１０６）する。
【選択図】図１

Description

本発明は、電話通信網を介したマルチメディアメッセージの追跡方法と追跡装置に関するものであり、詳細には、モジュラーによる遠隔通信網を介したマルチメディアメッセージの追跡方法と追跡装置する。
発明の分野は、遠隔通信の分野であり、より詳細には、マルチメディアメッセージ、またはＭＭＳメッセージとも呼ばれるマルチメディア内容を有する、メッセージを介した通信の分野に関する。

現状技術において、ＨＴＴＰサーバー上の負荷のシミュレーションを実施することを可能にする方法と装置が既知である。
かかる方法は、ＨＴＴＰサーバーに向けて要求を送信し、ＨＴＴＰサーバーに質問するロボットと呼ばれるプログラムを実行する。
これは、ロボット／クライアントとサーバーだけが関与したクライアントサーバープロセスである。

したがって、サーバーとロボットの間の相互作用がうまく展開しているかを知ることは可能であるが、ＭＭＳ型のマルチメディアメッセージ交換の際に使用される他の通信については一切情報が得られない。
特に、マルチメディアメッセージ伝達時間に関する一切の情報が得られない。
これは、この時間は、クライアントによる送信日付から宛先の受信日付まで測定されるからである。
同様に、かかる解決法では、メッセージのタイプが含まれるデータの種類と量によって変動するため、いかなるタイプのマルチメディアメッセージを喪失したか規定することができず、かかる解決法では、送信したマルチメディアメッセージが正確に受信されたか、すなわち受信したメッセージが送信されたメッセージと同一かどうか知ることもできない。
最後に、現状技術の解決法は、ＨＴＴＰプロトコルによる通信しか対象としていない。
しかし、実際には、マルチメディアメッセージの伝達を可能にする数多くのプロトコルが存在する。

本発明の一つの目的は、マルチメディアメッセージ交換システムの性能を測定することである。
本発明のもう一つの目的は、マルチメディアメッセージ交換システムの交換段階で測定／シミュレーションの道具を利用することである。
本発明のもう一つの目的は、運用段階にあるマルチメディアメッセージ交換システムで、測定を実施することである。
本発明のもう一つの目的は、マルチメディアメッセージの進行時間を測定することである。
本発明のもう一つの目的は、そのルーティングの過程でマルチメディアメッセージが受けた改変を検出することである。

本発明では、それぞれのモジュールが所定の役割を有する、モジュラーによる追跡方法／追跡装置を用いることによって、これらの問題を解決する。
例えば、生成モジュールは、もっとも一般的なものだけを挙げてもＨＴＴＰ、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ、無線アプリケーション手順）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ、電子メール転送簡易手順）、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ、オブジェクトアクセス簡易手順）などのさまざまな通信プロトコルを用いることによって、可変タイプのマルチメディアメッセージを遠隔通信網で生成、送信する。
このような生成モジュールは、多くのクライアントのシミュレーションを行うことが可能である。
もっとも、一般的なクライアントだけを挙げても、オフィスコンピュータ、ポケットコンピュータ、ＰＤＡ、移動電話からマルチメディアメッセージを送信することができる。
作成されたメッセージは、少なくとも本文とサブジェクトフィールドとも呼ばれるオブジェクトフィールドとから成る。
生成モジュールは、作成されたマルチメディアメッセージのタイプに応じてオブジェクトフィールドに情報を与える。
したがって、オブジェクトフィールドには、マルチメディアメッセージの識別子、マルチメディアメッセージの作成送信日付、回収モジュールのための命令コードおよび／またはマルチメディアメッセージのコントロールの総量が含まれる。
生成モジュールは、さらに作成、送信するマルチメディアメッセージに関する情報も分析モジュールに向けて、送信する。

これらの作成、送信されたマルチメディアメッセージは、遠隔通信網を介して通過し、通常マルチメディアメッセージ中継サーバーによって受信され、処理される。
その処理は、メッセージの保存と、受信され保存されたマルチメディアメッセージの宛先への通知メッセージの送信から成る。
この通知メッセージは、少なくとも前記マルチメディアメッセージのオブジェクトフィールドを含んでいる。

この通知メッセージは、傍受モジュールによって傍受され、生成モジュールによって作成されたメッセージでなければ、その宛先に向けての進行を継続させられ、あるいは、反対の場合、マルチメディアメッセージの回収モジュールに向けて送信される。

このとき回収モジュールは、生成モジュールによって作成、送信されたマルチメディアメッセージを回収するために、回収モジュールが中継サーバーに問い合わせることを可能にする情報を知る。
この回収は、回収されたマルチメディアメッセージの健全性に関するもの、および伝達時間に関するものを初めとする情報を入手することを可能にする。
このように得られた情報は、次に送信されたメッセージに関する情報をすでに保有している分析モジュールに伝達される。
送信されたメッセージに関する情報と回収されたメッセージに関する情報の間の相関が、したがって、マルチメディアメッセージ送達機能における遠隔通信網の振る舞いでモデル化する統計を得ることを可能にする。

したがって、この方法／装置は、負荷と耐久性の試験を実現するためにＭＭＳサービスの統合の際に、あるいは、システムの現実の利用率を測定するために用いることができる。
負荷試験は、短時間に需要が多い際、サーバーの挙動を測定する。
耐久性の試験は、長期間にわたってサーバーの挙動を測定する。
また、長期間にわたり非常に需要の多いサーバーの挙動測定のために、負荷と耐久性を組み合わせることも可能である。

したがって、本発明は、遠隔通信網を介したマルチメディアメッセージをモジュラーによる追跡方法であり、該方法は、マルチメディアメッセージと中継サーバーを含み、マルチメディアメッセージは、宛先フィールドとオブジェクトフィールドを含むものである。
・マルチメディアメッセージは、マルチメディアメッセージ生成モジュールにより自動的に作成され、
・生成モジュールは、マルチメディアメッセージのオブジェクトフィールド内に自動作成された、マルチメディアメッセージに関する情報を挿入し、
・作成されたマルチメディアメッセージは、遠隔通信網を介して送信され、
・作成、送信されたマルチメディアメッセージは、中継サーバーによって受信され、
・中継サーバーが、宛先フィールドによって、識別された宛先に向けてマルチメディアメッセージの受信の第一通知メッセージを作成、伝達し、該メッセージは、その内容が少なくともマルチメディアメッセージのオブジェクトフィールドの情報を含むものであることを特徴とする方法を対象とする。

本発明は、また、遠隔通信網を介したマルチメディアメッセージをモジュラーによる追跡方法であり、該方法は、マルチメディアメッセージと中継サーバーを含み、マルチメディアメッセージは、宛先フィールドとオブジェクトフィールドを含むものである。
・傍受モジュールは、マルチメディアメッセージの受信に続いて中継サーバーによって送信された通知メッセージを傍受し、第一の通知メッセージの宛先を規定し、宛先に応じて遠隔通信網内で明白に振る舞うか、あるいは、マルチメディアメッセージの回収モジュール宛てに第二の通知メッセージを送信し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にする少なくとも一つのオブジェクトフィールドを含み、
・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求を作成し、回収モジュールが、中継サーバー宛てに回収要求を送信し、中継サーバーの応答を処理することを特徴とする方法を対象とする。

本発明は、また、マルチメディアメッセージが、宛先フィールドとオブジェクトフィールドを含み、マルチメディアメッセージ中継サーバーを含む遠隔通信網を介してマルチメディアメッセージをモジュラーにより追跡する追跡装置において、
・メッセージを自動的に作成するための生成モジュールと、
・生成モジュールは、自動作成されたマルチメディアメッセージに関する情報をマルチメディアメッセージのオブジェクトフィールド内に挿入する手段を含み、
・生成モジュールが、作成したマルチメディアメッセージを、遠隔通信網を介して送信する手段を含み、
・中継サーバーが、マルチメディアメッセージの第一の受信通知メッセージを作成し、宛先フィールドによって識別された宛先に伝達するための手段を含み、第一の通知メッセージが、その内容が少なくともマルチメディアメッセージのオブジェクトフィールド内の情報を含んでいるオブジェクトフィールドを含み、
・傍受モジュールは、第一の通知メッセージを傍受し、第一の通知メッセージの宛先がどれかを規定し、宛先に応じて遠隔通信網内で明白に振る舞うか、あるいは、マルチメディアメッセージの回収モジュール宛てに第二の通知メッセージを送信し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にする少なくとも一つのオブジェクトフィールドを含み、
・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求を作成するための手段を含み、回収モジュールが、中継サーバー宛てに回収要求を送信する手段も含み、中継サーバーの応答を処理することを特徴とする装置を対象とするものである。

すなわち、本発明の課題を解決するための手段は、次のとおりである。

第１に、遠隔通信網を介したマルチメディアメッセージをモジュラーにより追跡する方法であり、該方法は、マルチメディアメッセージ（３００）と中継サーバー（２０４）とを含み、マルチメディアメッセージは、宛先フィールド（３０３）とオブジェクトフィールド（３０４）を含み、次の特徴を有する方法。
・マルチメディアメッセージは、マルチメディアメッセージ生成モジュール（２０１）により自動的に作成（１０１）される。
・生成モジュールは、マルチメディアメッセージのオブジェクトフィールド内に、自動作成されたマルチメディアメッセージに関する情報（３１１−３１４）を組み込む。
・作成されたマルチメディアメッセージは、遠隔通信網を介して送信（１０５）される。
・作成、送信されたマルチメディアメッセージは、中継サーバーによって受信（１０６）される。
・中継サーバーが、宛先フィールドによって、識別された宛先に向けてマルチメディアメッセージの受信の第一通知メッセージを作成、伝達（１０６）し、該メッセージは、その内容が少なくともマルチメディアメッセージのオブジェクトフィールド（３２４）の情報を含むものである。
第２に、遠隔通信網を介したマルチメディアメッセージをモジュラーにより追跡する方法であり、該方法は、マルチメディアメッセージ（３００）と中継サーバー（２０４）とを含み、マルチメディアメッセージは、宛先フィールド（３０３）とオブジェクトフィールド（３０４）を含み、次の特徴を有する方法。
・傍受モジュール（２０６）は、マルチメディアメッセージ（３００）の受信に続いて中継サーバーによって送信された通知メッセージを傍受（１０７）し、第一の通知メッセージの宛先を規定（１０８）し、宛先に応じて遠隔通信網内で明白に振る舞う（１１１）か、あるいは、マルチメディアメッセージの回収モジュール宛てに第二の通知メッセージを送信（１１０）し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にする少なくとも一つのオブジェクトフィールドを含む。
・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求（３４０）を作成し、中継サーバー宛てに回収要求を送信し、中継サーバーの応答を処理する。
第３に、生成モジュールが、送信したマルチメディアメッセージに関する第一の情報を分析モジュール（２０３）に伝達し、
・回収モジュールが、回収したマルチメディアメッセージに関する第二の情報を分析モジュールに伝達し、
・第一と第二の情報が同じ種類であることを特徴とする、上記第１または２に記載の方法。
第４に、マルチメディアメッセージが、ＭＭＳメッセージであることを特徴とする、上記第１から３のいずれか一つに記載の方法。
第５に、第一の通知メッセージが、ショート・メッセージであることを特徴とする、上記第１から４のいずれか一つに記載の方法。
第６に、回収要求が、ＷＡＰプロトコルを用いて送信されることを特徴とする、上記第２から５のいずれか一つに記載の方法。
第７に、マルチメディアメッセージのオブジェクトフィールドが、日付情報（３１２）を含んでいることを特徴とする、上記第１から６のいずれか一つに記載の方法。
第８に、異なるモジュールが連動されていることを特徴とする、上記第１から７のいずれか一つに記載の方法。
第９に、自動的に作成されたマルチメディアメッセージのオブジェクトフィールドが、自動的に作成されたマルチメディアメッセージの本文に対応するコントロールの総量を有することを特徴とする、上記第１から８のいずれか一つに記載の方法。
第１０に、自動的に作成されたマルチメディアメッセージのオブジェクトフィールドが、自動的に作成されたマルチメディアメッセージの識別情報（３１１）を有することを特徴とする、上記第１から９のいずれか一つに記載の方法。
第１１に、自動的に作成されたマルチメディアメッセージのオブジェクトフィールドが、回収モジュールの振る舞いを定義するための命令コード（３１３）を有することを特徴とする、上記第１から１０のいずれか一つに記載の方法。
第１２に、傍受モジュールが、中継サーバーによって送信されたデータを処理することを特徴とする、上記第１から１１のいずれか一つに記載の方法。
第１３に、傍受モジュールが、遠隔通信網のＳＭＳ−Ｃによって送信されたデータを処理することを特徴とする、上記第１から１２のいずれか一つに記載の方法。
第１４に、マルチメディアメッセージが、内容がサイズおよび／または種類において変動する本文（３０５）を含んでいることを特徴とする、上記第１から１３のいずれか一つに記載の方法。
第１５に、生成モジュールが、所与の周波数でマルチメディアメッセージを送信することを特徴とする、上記第１から１４のいずれか一つに記載の方法。
第１６に、生成モジュールが、所与の時間内にマルチメディアメッセージを送信することを特徴とする、上記第１から１５のいずれか一つに記載の方法。
第１７に、生成モジュールが、異なるプロトコルを介してマルチメディアメッセージを送信することを特徴とする、上記第１から１６のいずれか一つに記載の方法。
第１８に、通知メッセージが、それが対応する中継サーバーによって受信されたマルチメディアメッセージの識別情報（３３５，３４３）を含んでいることを特徴とする、上記第１から１７のいずれか一つに記載の方法。
第１９に、生成モジュールは、サービスプロバイダのサーバー（２０８）と、中継サーバーの間の仲介であり、生成モジュールが、傍受されたマルチメディアメッセージにより、オブジェクトフィールドを修正することを特徴とする、上記第１から１８のいずれか一つに記載の方法。
第２０に、生成モジュールが、シナリオファイルを介してパラメータ設定されることを特徴とする、上記第１から１９のいずれか一つに記載の方法。
第２１に、生成モジュールおよび／または回収モジュールが、マルチプロセス論理構造を有することを特徴とする、上記第１から２０のいずれか一つに記載の方法。
第２２に、マルチメディアメッセージが、宛先フィールドとオブジェクトフィールドを含み、マルチメディアメッセージ中継サーバー（２０４）を含む遠隔通信網を介してマルチメディアメッセージを追跡し、次の特徴を有する、マルチメディアメッセージのモジュラーによる追跡装置。
・メッセージを自動的に作成するための生成モジュール（２０１）を含む。
・生成モジュールは、自動作成されたマルチメディアメッセージに関する情報をマルチメディアメッセージのオブジェクトフィールド内に挿入する手段を含む。
・生成モジュールが、作成したマルチメディアメッセージを、遠隔通信網を介して送信する手段を含む。
・中継サーバーが、マルチメディアメッセージの第一の受信通知メッセージを作成し、宛先フィールドによって識別された宛先に伝達するための手段を含み、第一の通知メッセージが、その内容が少なくともマルチメディアメッセージのオブジェクトフィールド内の情報を含んでいるオブジェクトフィールドを含む。
・傍受モジュール（２０６）は、第一の通知メッセージを傍受し、第一の通知メッセージの宛先がどれかを規定し、宛先に応じて遠隔通信網内で明白に振る舞うか、あるいは、マルチメディアメッセージの回収モジュール（２０２）宛てに第二の通知メッセージを送信し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にする少なくとも一つのオブジェクトフィールドを含む。
・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求を作成するための手段を含み、中継サーバー宛てに回収要求を送信する手段も含み、中継サーバーの応答を処理する。
第２３に、生成モジュールが、生成モジュールによって送信されたマルチメディアメッセージに関する第一の情報を分析モジュール（２０３）に伝達する手段を含み、
・回収モジュールが、回収したマルチメディアメッセージに関する第二の情報を分析モジュールに伝達するための手段を含み、
・第一と第二の情報が同じ性質のものであることを特徴とする、上記第２２に記載の装置。

本発明は、非制限的な例として挙げられた、付属の図面を参照して、下記の説明を読むことによって明らかになるだろう。

図１は、本発明に従った方法の過程の概略図である。
図２ａは、本発明に従った装置のアーキテクチュアの概略図である。
図２ｂは、本発明に従った方法の実施に用いることができる手段の概略図である。
図３は、本発明に従った方法を実施したときに送受信される要求メッセージの構造の概略図である。
図４は、生成モジュールのマルチプロセス機能を示す概略図である。

図１に示すように、それぞれの過程または過程群は、モジュールによって実施されるが、それはモジュラー式の方法／装置のためである。
それぞれのモジュールは、果たすべき一つまたは複数の役割を有する。
実際には、図２に示したごとく、それぞれのモジュールは、事実、独立した、サーバー型の機械である。
かかる機械は、マイクロプロセッサと、プログラム保存と作業用のメモリと、遠隔通信網への接続手段とを有している。
この場合、サーバー／モジュールのプログラムメモリは、モジュールの機能を用いることを可能にする命令コードを含んでいる。
さらに、モジュールは、サーバー間の距離に応じて遠隔通信網あるいは局所網を介して通信する。
特記事項がないとき、二つのモジュールは例えば、ＴＣＰ／ＩＰ型のプロトコルを介して相互に通信するものとする。
しかしながら、変型例においては、複数のモジュールに対応する機能が同一のサーバーで実施されることがある。
その意味は、かかるサーバーのメモリは、複数のモジュールの機能に対応する命令コードを有するということである。
この意味で、モジュールは、サーバーの内部装置、バスとメモリを介して通信する。
説明において、一つの作用を一つのモジュールに付与すると、この作用は、実際には命令コードで操作されるマイクロプロセッサによって実現される。
変型例において、それはモジュールの機能の実現を専門とする／専用の構成部品である。

マルチメディアメッセージとは、ＭＭＳ（Ｍｕｌｔｉｍｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）型の伝言を意味する。
ここでＭＭＳサービスとは、マルチメディアメッセージの保存と返送の内部機構を提供する、人の間の通信サービスである。
これらのマルチメディアメッセージは、テキスト、音声（ｍｐ３、ｏｇｇ、ｗａｖその他のフォーマットのファイル形）、静止画または動画（ｊｐｅｇ、ｇｉｆ、ｍｐｅｇ、ｄｉｖｘその他のフォーマットのファイル形）を含むことが可能で、全体はＳＭＩＬ表示言語（Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｇｒａｔｉｏｎ Ｌａｎｇｕａｇｅ、マルチメディア連動統合言語）によって成形される。
しかし、他の成形言語も使用可能であり、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ、ハイパーテキスト標識言語）あるいはカスケーディング・スタイル・シート（ＣＳＳ）は、これらの言語の中でもっとも知られているものである。

これらのマルチメディアメッセージは、送信者と宛先の間で遠隔通信網を通過する。
かかる遠隔通信網は、これらのマルチメディアメッセージの進行を可能にするすべてのインフラストラクチャーを含んでいる。

図１は、マルチメディアメッセージの自動作成と送信の過程１０１を示している。
過程１０１は、マルチメディアメッセージ生成モジュール２０１によって実行される。
生成モジュール２０１の機能は、いくつかの数のフィールドを含むマルチメディアメッセージを作成することである。
図３中のａは、マルチメディアメッセージに含まれるフィールドを図示している。
マルチメディアメッセージ３００は、ヘッダーフィールド３０１を含んでいる。
フィールド３０１は、とりわけ、メッセージ３００の送信者識別フィールド３０２と、メッセージ３００の宛先識別フィールド３０３を含んでいる。
メッセージ３００は、メッセージのオブジェクト、またはサブジェクトフィールド３０４とメッセージの本文フィールド３０５も含んでいる。

過程１０１メッセージ３００の異なるフィールドに情報を与えるための複数のサブ過程を含んでいる。
サブ過程１０２において、生成モジュール２０１は、本文フィールド３０５に情報を付与する。
本文フィールド３０５は、ＳＭＩＬ型の言語によってフォーマットされたマルチメディアメッセージのデータを含んでいる。
使用者によってパラメータ設定された生成モジュールが、メッセージ３００の本文３０５内に呈示されるデータのタイプを規定する。
これらのデータは、テキスト、音声または動画／静止画である。
これらのデータは、実施したい試験に応じて異なる量で呈示される。
一つの媒体だけ、複数のメディア、わずかなデータ、および／または多くのデータを含むマルチメディアメッセージの遠隔通信網の振る舞いを試験することもできる。
本文は、使用者によって手作業で作成されるか、本文になり得るある数の内容を含むライブラリ内で読み取られるか、例えば、サイズパラメータに応じてモジュール２０１によって作成される。
最後の場合、これは本文３０５のたんなる詰め込みになる。
ライブラリを使用する場合、それは、メモリに登録され、生成モジュール２０１からアクセスする。

サブ過程１０２から、サブ過程１０３に移行して、生成モジュール２０１が、マルチメディアメッセージ３００の送信者（ＩＤＥ）と宛先（ＩＤＤ）フィールドに情報を提供する。
これらのフィールドには、人の識別子、もっと正確には、個人と遠隔通信網事業者間に存在する契約が含まれる。
これらの識別子は、ｅメール、電話番号、インターネットアドレス、あるいは遠隔通信網で流通している他の形の識別などの電子識別子である。
以下の説明において、ＩＤＤ識別子は、電話番号であり、ＩＤＥ識別子は、コンピュータによる、あるいはそれぞれ電話機によるマルチメディアメッセージであるかによって、ｅメールアドレス、あるいはそれぞれ電話番号であるものとする。
ＩＤＤおよびＩＤＥ識別子は、あらかじめ定められた識別子一覧の中から生成モジュール２０１によって選択される。
この一覧は、遠隔通信網を通過するマルチメディアメッセージの中で、フィルタリングを実施することを可能にする。
これらのＩＤＤおよびＩＤＥ識別子は、生成モジュール２０１を利用する使用者によって指定されることもできる。

サブ過程１０３から、メッセージ３００のオブジェクトフィールド３０４の作成サブ過程１０４に移行する。
オブジェクトフィールドには、生成モジュール２０１によって生成されたマルチメディアメッセージに関する情報が含まれている。
これらの情報は、メッセージ３００の種類の自然言語による要約ではない。
自然言語とは、フランス語や英語などの言語である。
これらの情報は、自動処理プロセスによって直接、曖昧さなしに用いることができる形式言語である。
これらの言語は、個人によって解読できる文字によって表現されるという事実はここでは何も変えない。
これらの情報は、生成モジュール２０１によって作成されたすべてのものの中からメッセージ３００の識別を可能にするマルチメディアメッセージ識別子である。
この識別子は、フィールド３０４のフィールド３１１内に登録される。
この識別子は、例えば、生成モジュール２０１のカウンタの増加によって得られる。
このとき、それぞれの作成メッセージは、異なる識別子を有する。
このカウンタは、使用者の介入によって、あるいは所定の期間が過ぎたときにリセットすることができる。
かかる識別子は、日付をパラメータとし、識別子の一意性を保証する関数によって作成することもできる。
フィールド３０４内で、フィールド３１１から３１４は、複数の手段で区別することができる。
第一の手段は、それぞれのフィールドに固定サイズを割り当てることである。
第二の手段は、ＸＭＬ統辞法（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅすなわち拡張標識言語）によって、これらのフィールド３１１から３１４を構造化することであり、このときそれぞれのフィールドは、開始標識と閉鎖標識によって限られる。
これら二つの可能性、およびその他の可能性は、明細書に記載のフィールド全体に対して開かれている。

オブジェクトフィールド３０４は、メッセージ３００が作成、送信された日付を示す日付フィールドも含んでいる。
このフィールドは、少なくとも秒単位の解を有し、年、月、日、時と秒で日付を定義できる。
変型例において、作成−送信が行われたミリ秒が付加される。
短期間にわたる試験の場合、年または月の情報を省略することができる。
しかしながら、これらの年と月の情報は、２年間または二ヶ月にまたがる試験の場合は有益である。

オブジェクトフィールド３０４には、マルチメディアメッセージ回収モジュール２０２のための命令コードも含まれる。
このフィールド３１３は、回収モジュール２０２によって解釈される。
かかる命令コードは、例えば、回収モジュールがマルチメディアメッセージを回収する前に経過を待たなければならない潜伏期間である。
別の可能な命令コードは、マルチメディアメッセージを回収しない、である。

オブジェクトフィールド３０４には、コントロールの総量も含まれる。
フィールド２１４には、フィールド３０５のコントロールの総量が含まれる。
コントロールの総量は、サブ過程１０２で規定されたフィールド３０５の中身に応じて生成モジュール２０１によって計算される。

変型例において、フィールド３０４は、フィールド３１１しか含んでいない、それによりメッセージがその宛先まで届いたか否かに関する情報を得ることができる。
フィールド３１２から３１４のそれぞれは、メッセージの進行に関して追加の情報をもたらす。
これらの情報は、主として伝達の時間と完全性である。

サブ過程１０４から、メッセージ３００の送信サブ過程１０５に移行する。
生成モジュール２０１は、マルチメディアメッセージの送信のために公衆によって用いられる機器の作動のシミュレーションを可能にするプロトコルに従ってメッセージ３００を送信する。
この場合の公衆は、マルチメディアメッセージの送信を希望する個人、企業、またはコンテンツプロバイダである。
これらのプロトコルの中からＨＴＴＰ、ＳＭＴＰ、ＳＯＡＰ、ＷＡＰプロトコルを挙げることができるが、ほかにも存在する。
メッセージ３００の送信に使用されるプロトコルは、モジュール２０１を利用する使用者によって設定される。
したがって、モジュール２０１は、これらの異なるプロトコルに従って通信するための手段を備えている。
多数の機器が、これらのプロトコルを介してすでに通信しているため、これらの手段は既知のものである。

モジュール２０１の、他のパラメータのうちのいくつかは、毎秒ごとに送信されるマルチメディアメッセージの数であり、また、モジュールがメッセージを送信する期間である。
これらの二つのパラーメータは、負荷と耐久性の試験を実施することを可能にするものである。
一旦、パラメータ設定がなされると、生成モジュール２０１は、一つまたは複数のプロトコルを介して一つまたは複数の宛先に対し、所与の周波数と所定の期間、一つまたは複数のマルチメディアメッセージを送信する。

それが送信するそれぞれのメッセージについてモジュール２０１は、少なくとも、識別子３１１、日付３１２，コード３１３，コントロールの総量３１４，ＩＤＥ、ＩＤＤフィールドの内容３０５と使用プロトコルである、それらのパラメータを知っている。
これらの情報は、結果分析モジュール２０３に伝達される。
これらのデータは、回収モジュール２０２によって収集されたものと相関される。

モジュール２０１の振る舞いを設定するための代替方法は、シナリオを使用することである。
このとき、モジュール２０１は、モジュール２０１のマルチメディアメッセージの作成／送信手段を利用することを可能にするシナリオを解釈するために、命令コードの形で、手段を含む。
かかるシナリオは、例えば、ＸＭＬフォーマットのファイルの形を呈する。
次の形を取ることができる。

Example of a scenario : scenario.xml file
00 <?xml version="1.0" encoding "utf-8">
01 <!DOCTYPE scenario SYSTEM "scenario.dtd">
02 <scenario title="title of scenario"
description="description of the scenario">
03 <title sequence="multiprotocol sequence"
description="sequence during which
multimedia messages are sent according to
several protocols" duration="198">
04 <trafficProfile
05 title="pdt1"
06 frequency="f1"
07 MMSname="mms1"
08 protocol="smtp"
09 retrievalTime="2"
10 />
11 <trafficProfile
12 title="pdt2"
13 frequency="f2"
14 MMSname="mms2"
15 protocol ="wap"
16 retrievalTime="0"
17 />
18 </sequence>
19 <title sequence="monoprotocol sequence"
description="sequence implementing only
one protocol" duration="256">
20 <trafficProfile
21 title="pdt3"
22 frequency="f3"
23 MMSname="mms3"
24 protocol="wap"
25 retrievalTime="1"
26 />
27 </sequence>
28 </scenario>

シナリオファイル．ｘｍｌは、このようにしてモジュール２０１の振る舞いを定義するシナリオの記述を可能にする。
それに続いて、ラインワードの使用は、シナリオファイル．ｘｍｌの行に関連づけられる。
行０１は、使用ＸＭＬ言語のバージョンに依存する標準ヘッダーに対応する。

行０２は、シナリオファイル．ｘｍｌの構文について、解釈プログラムの要求と合致しているかの検査を可能にするために定義ファイルを指定するものである。

ここで、ＸＭＬファイルは、樹木に類似している、すなわち階層のあるオブジェクトの全体にたとえられる。
したがって、シナリオファイル．ｘｍｌは、その開始標識と閉鎖標識の間の、すなわち行０３と２８の間のシナリオを記載する。
シナリオファイル．ｘｍｌは、シナリオオブジェクトを備え、それ自体がシーケンスオブジェクトを含んでいる。
それぞれのシーケンスオブジェクトは、一つまたは複数のトラフィックのプロフィールオブジェクトを含んでいる。
他方で、それぞれのオブジェクトは一つまたは複数のプロパティを有する。

シナリオオブジェクトは、この例では、タイトルおよび記述プロパティを有する。
ここでタイトルは、オブジェクトの識別を可能にし、記述は多少なりとも簡潔にオブジェクトを記載することを可能にする。
この例において、シナリオオブジェクトは、二つのシーケンスオブジェクトを含んでいる。
実際には、シナリオオブジェクトは、任意の数のシーケンスオブジェクトを含んでいる。

シーケンスオブジェクトは、タイトル、記述と時間を含んでいる。
時間は、例えば、秒で表された数である。
変型例において、分、十分の一秒、または一切の秒の分数などの他の単位を用いることができる。
時間は、シーケンスオブジェクトが含んでいるトラフィックのプロフィールオブジェクトの命令をモジュール２０１が実行しなければならない時間を表す。
時間の値が１９８のとき、モジュール２０１は、１９８秒の間に時間の値が１９８であるシーケンスオブジェクトに含まれているトラフィックのプロフィールオブジェクトの命令を実行する。

シナリオン．ｘｍｌの例は、二つのトラフィックのプロフィールオブジェクトを含むシーケンスオブジェクトと、一つのトラフィックのプロフィールオブジェクトを含むシーケンスオブジェクトを示している。
実際には、シーケンスオブジェクトは、任意の数のトラフィックのプロフィールオブジェクトを含む。

トラフィックのプロフィールオブジェクトは、タイトル、周波数、マルチメディアメッセージ名、プロトコルと回収時間を始めとする複数のプロパティを含む。
したがって、トラフィックのプロフィールオブジェクトの解釈は、その構造がマルチメディアメッセージ名で識別されるマルチメディアメッセージの作成をもって成る。
この名前に対応するのが、サイズ、構造、および一つまたは複数のコンテンツタイプである。
周波数は、トラフィックのプロフィールオブジェクトに対応するマルチメディアメッセージが送信されなければならない周波数に対応する。
プロトコルは、トラフィックのプロフィールオブジェクトに対応するマルチメディアメッセージが送信されなければならないプロトコルに対応する。
回収時間は、モジュール２０２に対する命令に対応する。
したがって、回収時間はフィールド３１３の内容の作成に用いられる。

シナリオン．ｘｍｌの例は、二つのメッセージ送信シーケンスの連続に対応する。
その間に、モジュール２０１が、二つのタイプのトラフィックを生成する１９８秒の間の第一のシーケンスである。
第一のトラフィックタイプは、タイトル■ｐｄｔ１■で識別されるトラフィックのプロフィールオブジェ
クトによって記述され、第二のトラフィックタイプはタイトル■ｐｄｔ２■で識別されるトラフィックのプ
ロフィールオブジェクトによって記述される。
第一のトラフィックタイプは、このときプロトコル■ｓｍｔｐ■に従ってメッセージ名■ｍｍｓ１■で識
別される、メッセージの周波数ｆ１での送信に対応する。
第二のトラフィックタイプは、このときプロトコル■ｗａｐ■に従ってメッセージ名■ｍｍｓ２■で識別
される、メッセージの周波数ｆ２での送信に対応する。
あらかじめ記述されたシーケンスオブジェクトの時間が経過すると、それに対応するトラフィックを中断し、ついでシナリオファイル．ｘｍｌの中の次のシーケンスに対応する命令を実行する。
ここでトラフィックは、所与の周波数での所与のメッセージの送信に対応する。
タイトルが■シーケンス モノプロトコル■である次のシーケンスは、ただ一つのトラフィックのプロフ
ィールオブジェクトを有し、後者は第一のシーケンスについて先述のごとく解釈される。

ここから、ラインワードは特記事項なき限り、シナリオファイル．ｘｍｌの一つの行をもはや明示的に参照しない。

したがって、モジュール２０１のパラメータ設定は、ユーザーインターフェイスを介して素早く、あるいは、シナリオファイル．ｘｍｌと等価のコンフィギュレーション・ファイルを介して実施できるユーザーインターフェイスは、プログラム実行前に、あるいはプログラムがそれを必要とするにつれてデータの入力を可能にする。
コンフィギュレーション・ファイルは、その解釈によって一つまたは複数のマルチメディアメッセージがモジュール２０１によって送信される少なくとも一つの命令を含むとき、シナリオファイル．ｘｍｌと等価である。

サブ過程１０５から、中継サーバー２０４によるメッセージの処理過程１０６に移行する。
中継サーバーは、一般的にＭＭＳ−Ｃ、マルチメディアメッセージセンターとも呼ばれる。
モジュール２０１と中継サーバー２０４は、遠隔通信網を介して接続される。
この接続が、ＷＡＰプロトコルを介して実現されたとき、その場合には、モジュール２０１と中継サーバー２０４の間に、モジュール２０１と中継サーバー２０４の間のインターフェイスＷＡＰブリッジ２０５が存在している。
この場合、モジュール２０１は、マルチメディアメッセージを送信する一つまたは複数の移動電話の振る舞いをシミュレーションする。
この場合、モジュール２０１とブリッジ２０５の間の通信は、セルラー網型の遠隔通信網の一部を介して行われる。
この結果は、例えば、モジュール２０１が作成マルチメディアメッセージを送信できるようにＧＳＭ、ＧＰＲＳまたはＵＭＴＳモデムを用いて得られる。

移動電話からマルチメディアメッセージを送信するシミュレーションの観点において、モジュール２０１と２０２は、ブリッジ２０５によって期待される振る舞いの一部または全部をシミュレーションすることができる。
二つの場合が区別される。

・モジュール２０１、または２０２は、ＣＳＤ、ＧＰＳ、ＵＭＴＳ規格またはその他によるものかを問わず、所与のモード遠隔通信網に接続される。
ネットワークに固有のアドレス指定、認証その他の管理は、この場合、遠隔通信網のインフラストラクチャーによって、特にＧＰＲＳ／ＵＭＴＳ規格を使用している場合、ＳＧＳＮ／ＧＧＳＮの名称で知られている機器によって実現される。
このときモジュール２０１は、何の制約もなくＷＡＰプロトコルで、マルチメディアメッセージを送信する。
このときモジュール２０２は、何の制約もなくＷＡＰプロトコル上で、マルチメディアメッセージを受信する。
これは完全なシミュレーションになる。

・モジュール２０１、または２０２は、サーバー／中継２０４に直接、あるいはＴＣＰ／ＩＰプロトコルを介して直接ブリッジ２０５に接続される。
これは、特に中継サーバー２０４、またはブリッジ２０５に組み合わされた中継サーバー２０４のサービス品質を測定したときの性能試験に当てはまる。
この場合、モジュール２０１は、直接接続が中継サーバー２０４またはブリッジ２０５にとってクリアーになるように遠隔通信網の機能を管理する。

このようにモジュール２０１と２０２は、ＷＡＰプロトコルのマルチメディアメッセージの送受信のシミュレーションだけを、あるいは中継サーバー２０４とブリッジ２０５が受信するメッセージの全体のシミュレーションを可能にする。

移動電話、ＰＤＡ、その他のタイプの複数のクライアントによる遠隔通信網の使用をシミュレーションするために、モジュール２０１は、その変型例において、マルチプロセスタイプの論理構造を有する。
マルチプロセスの同義語は、マルチタスクである。
したがって、モジュール２０１は、それぞれのプロセスがマルチメディアメッセージセンターを送信する、したがって、少なくとも一つの過程１０６を実現する役割を有する、複数のプロセスを同時に実行することができる。
実際には、プロセスは、過程１０２から１０４で作成された要素を知っている、したがって、変型例において、プロセスはこれらの過程を実現する。
このとき、それぞれのプロセスは、遠隔通信網のクライアントに同化できる。
この意味で、それぞれのプロセス／クライアントには、遠隔通信網で通信できるように資源が割り当てられる。
これらの資源の一つは、特にＷＡＰプロトコルによる通信の場合、インターネットアドレスである。
モジュール２０１がマルチプロセスである限り、実際には能動プロセスごとに一つの、複数のインターネットアドレスが割り当てられる。
実際には、モジュール２０１があるシナリオのあるシーケンスを解釈するとき、シーケンスオブジェクトがトラフィックのプロフィールオブジェクトを含むのと同じ数だけのプロセスを作成する。
変型例において、それぞれのマルチメディアメッセージは異なるプロセスによって送信される。
この最後の変型例は、遠隔通信網への多数のクライアントの接続のシミュレーションを可能にする。
これによって、多数のマルチメディアメッセージを送信するクライアントをシミュレーションすることをもって成るものとは異なるシミュレーションの実施を可能にする。
ここで、多数とは、一秒間に数十の、さらには百程度のマルチメディアメッセージを送信できることを意味する。
実際には、より大容量が必要なとき、モジュール２０１に含まれるマイクロプロセッサの出力を増加させるか、モジュール２０１のようなモジュールを多数使用することができる。
あるタイプの多数のモジュールの使用は、傍受、回収または分析を問わず、他のモジュールにも拡大できる。

図４は、遠隔通信網の複数のクライアントにかかわる、通信のシミュレーションの際のモジュール２０１のマルチプロセス機能モードを示している。
図４は、モジュール２０１の親プロセスが、遠隔通信網のインフラストラクチャーにリソース割り当て要求４０２を送信し、インターネットアドレスを取得する予備過程４０１を示している。
要求４０２に対して、遠隔通信網は過程４０３を介して、要求４０２に対する応答４０４を送信する。
応答４０４には、親プロセスが使用することができるインターネットアドレスの一覧を含んでいる。
過程４０１から、子プロセスの作成過程４０５に移行する。
子プロセスは、親プロセスと同様に、モジュール２０１によって実行されるプログラムである。
親プロセスの有効期間は、無限、あるいは少なくとも、モジュール２０１の使用者によって設定されたコマンドの実行に等しい有効期間をもつ。
子プロセスは、親プロセスによってそれらに割り当てられた仕事の時間に等しい有効期間を有する。

親プロセスは、ブリッジ２０５に向かって、ＲＡＤＩＵＳ Ａｃｃｏｕｎｔｉｎｇ ＳＴＡＲＴという名前で知られているメッセージ４０６を送信する。
メッセージ４０６は、インターネットアドレスをパラメータとする。
メッセージ４０６は、遠隔通信網のクライアントを識別する電話番号もパラメータとする。
過程４０７において、ブリッジ２０５は、メッセージ４０６を処理して、メッセージ４０６に対する応答４０８を送信する。
このとき、親プロセスは、一方では、マルチメディアメッセージの作成に有効なすべての情報を、他方では、ブリッジ２０５との通信を確立するのに有効なすべての情報を子プロセスに提供することによって、子プロセスを作り出すことができる。
通信のためのこれらの情報は、実際にメッセージ４０６に対する応答の中に含められる。
マルチメディアメッセージ作成のための情報は、モジュール２０１のパラメータ設定を介して得られる。
過程４０９において、子プロセスは、過程１０１について記述した作用を実行する。
過程４０９は、ブリッジ２０５と通信しながら実行され、ブリッジは、過程４１０において適切な作用を実行する。

子プロセスは、マルチメディアメッセージが送信されたときに終了する。
このとき親プロセスは、子プロセスとの通信のために割り当てられたリソースが解放できることをブリッジ２０５に通告するために、ＲＡＤＩＵＳ Ａｃｃｏｕｎｔｉｎｇ ＳＴＡＲＴメッセージを送信する。
ブリッジ２０５は、過程４１２を介して、メッセージ４１１がきちんと処理されたことを意味するメッセージ４１３によって応答する。

動作４０６から４１３は、モジュール２０１のために設定された仕事の実行のために作成すべき子プロセスがあるだけ反復される。
それぞれの子プロセスは、他のものから独立している。
複数の子プロセスが、同時に存在することができる。

モジュール２０２も、同じ方式に従って作動することができる。
ただし、この場合は、過程４０９でマルチメディアメッセージを送信するのではなく、それを回収する。
したがって、過程４０９は、後述の過程１１２と同等である。

このマルチプロセスアーキテクチャは、特異なものではない。
したがって、別の変型例においてラジウスメッセージの管理は、子プロセス自体に任される。
この最後の場合、子プロセスは遠隔通信網のクライアントに完全に同化することができる。
いずれの場合にも、ＷＡＰブリッジとＭＭＳ−Ｃ中継サーバーは、複数のネットワーククライアントとかかわっている。

モジュール２０１、およびまたは２０２の別の変型例は、反復シーケンシャル論理構造である。
すなわち、停止条件が満たされない限り、過程１０１、およびまたは１０２のサブ過程が順次実現される。
かかる停止条件とは、例えば、送信時間、メッセージ数、または同等の条件である。
シーケンス作動モードにおいて、モジュール２０１は、サブ過程１０５を実行した後に、停止条件が満たされない限り、過程１０１の第一のサブ過程で再開する。
もちろん、二つのタイプの論理アーキテクチュアを混合することも可能である。

過程１０６について注意するのは、中継サーバー２０４が、遠隔通信網の標準機器であることである。
この意味において、マルチメディアメッセージを受信するときは標準的に振る舞う。
この振る舞いは、受信したマルチメディアメッセージをそれにＵＲＬＭ識別子を割り当てた後に保存メモリ内に登録することをもって成る。
次に、中継サーバー２０４は、通知メッセージを作成して、マルチメディアメッセージの宛先に送信する。
この宛先は、マルチメディアメッセージのフィールド３０３によって識別される。

中継サーバー２０４によって作成されたメッセージ３２０は、ヘッダー３２１を有し、ヘッダー３２１は、フィールド３０２，３０３と同等の少なくともフィールド３２２と、３２３をそれぞれ備えている。
メッセージ３２０は、フィールド３０４と同一のオブジェクトフィールド３２４も含んでいる。
通知メッセージ３２０は、ＵＲＬＭ識別子の伝達を可能にする識別フィールド３２５も含んでいる。
通知メッセージ３２０は、他の情報、特にこのメッセージをマルチメディアメッセージ受信の通知メッセージとして識別することを可能にする情報を含んでいる。
いったんメッセージ３２０が作成されると、遠隔通信網を介して、通知メッセージの作成を引き起こしたマルチメディアメッセージの宛先に向けて送信される。
第一の通知は、二進で、あるいは宛先の端末のタイプに応じて符号化される。

フィールド３２５は、宛先の端末のタイプに応じて中継サーバー２０４またはブリッジ２０５によって作成される。
実際には、このフィールドは、中継サーバー２０４の対応するマルチメディアメッセージへのアクセスを可能にするＵＲＬを備えている。
実際には、本発明はフィールド３２５の他のデータタイプとも互換性があり、これらのデータタイプのものは、マルチメディアメッセージの識別を可能にする。

明細書の例において、宛先は電話番号によって識別され、したがって、通知メッセージはＳＭＳ（ショート・メッセージ・サービス）とも呼ばれる一つまたは複数の短いメッセージとして送信される。
しかしながら、メッセージ３２０は、ＳＭＰＰ（ピア・トウ・ピア・ショート・メッセージ）またはＵＣＰ（ユニバーサルコンピュータプロトコル）などのプロトコルを介して送信することもできる。

過程１０６から、傍受モジュール２０６による通知メッセージ３２０の傍受過程に移行する。
過程１０７は、過程１０６で送信された通知メッセージごとに実現される。
推奨変型例において、モジュール２０６は、中継サーバー２０４とショート・メッセージセンター機器２０７またはＳＭＳ−Ｃの間で遠隔通信網内に接続される。
ＳＭＳ−Ｃ機器は、ＳＭＳメッセージのその最終宛先への正確な輸送を担当する。

モジュール２０６は、中継サーバー２０４によって送信されたすべての通知メッセージを傍受する。
これによってモジュール２０６は、サブステップ１０８において、この通知メッセージの宛先３２３フィールドの内容を知ることができる。
このフィールドを知ることによって、それがモジュール２０１のマルチメディアメッセージ送信の結果としての通知メッセージであるかを判定することができる。
実際、モジュール２０６は、サブ過程１０３でモジュール２０１によって使用されたアドレス一覧を知っている。
したがって、宛先が、実際はモジュール２０１による架空の宛先であるかを判定するのは容易である。
過程１０７については、実際に中継サーバー２０４によって送信されたメッセージのフィルタリングが行われる。

変型例において、フィルタリングはフィールド３２２で行われる。
別の変型例において、フィルタリングはフィールド３２４で行われる。
その性質の故に、フィールド３２４は、実際には検出の容易な特別な構造を有する。
この構造の検出によって通知メッセージを選別し、モジュール２０１のマルチメディアメッセージ送信の結果としての通知メッセージの判別を可能にする。
言い換えれば、この構造の検出によって通知メッセージの宛先が実際にモジュール２０２であるかを判別できる。

サブ過程１０８から、進路規定サブ過程１０９に移行する。
サブ過程１０８でモジュール２０１のマルチメディアメッセージ送信によるものの中から傍受された通知メッセージの分類が可能になれば、サブ過程１０９から第二の通知メッセージの作成送信サブ過程に１１０に移行する。
そうでなければ、サブ過程１０９から、通知メッセージ３２０が通常の進行を継続する過程１１１に移行する。
この最後の場合、モジュール２０６は、遠隔通信網内でクリアーである。

サブ過程１１０において、モジュール２０２は、第二の通知メッセージ３３０を作成する。
通知メッセージ３３０は、マルチメディアメッセージを回収モジュール２０２に宛てられる。
メッセージ３３０の内容は、回収モジュール２０２が通知メッセージ３２０に対応するマルチメディアメッセージを回収することを可能にする。
したがって、メッセージ３３０には、内容がフィールド３２５の内容と同一である少なくともフィールド３３５が含まれる。
通知メッセージ３３０は、モジュール２０６と２０２の間での通信に使用されたプロトコルに固有のヘッダーも含まれている。
フィール３２４にモジュール２０２の命令コードを含んでいるとき、メッセージ３３０は、同じコードの伝達のためのフィールドも含んでいる。
変型例において、フィールド３２２から３２４の全体または一部は、メッセージ３３０を介して伝達される。
モジュール２０２は、フィールド３２６に通知受信日付を挿入することもできる。
メッセージ３３０は、いったん構成されると、回収モジュール２０２に送信される。

変型例において、モジュール２０６は、ＳＭＳ−Ｃ機器を越えて、遠隔通信網内に位置づけられる。
これは、中継サーバー２０４によって送信された通知メッセージが、最初にＳＭＳ−Ｃ機器によって見られることを意味している。
この場合、モジュール２０６は、通知メッセージの識別子３２３によって接続できる装置のように振る舞う。

ステップ１１１は、通知メッセージ３２０をモジュール２０２によって送信する過程であり、メッセージ３２０は、モジュール２０６によって変化されない。

モジュール２０６は、中継サーバー２０４、ＳＭＳ−Ｃ機器とだけでなく、モジュール２０２とも通信するための手段も備えている。
これらの手段は、インターフェイス回路と、これらのインターフェイス回路のためのパイロット型のプログラムである。
ＳＭＳ−Ｃ機器からは、モジュール２０６は、中継サーバー２０４のように見える。

サブ過程１１０から、回収モジュール２０２による第二の通知３３０の処理過程１１２に移行する。
過程１１２は、モジュール２０６によってモジュール２０２に宛てられたそれぞれの通知メッセージについて実現される。
過程１１２の実行のための、モジュール２０２の論理構造は、マルチプロセスであるか、あるいは反復シーケンシャルである。
これらのアーキテクチュアは、モジュール２０１についてすでに述べた。

過程１１２において、モジュール２０２は、メッセージ３３０に含まれる異なるフィールドから第二の通知メッセージ３３０を抽出する。
過程１１２には、命令コード実行の第一の選択的過程１１３が含まれる。
これは、フィールド３１３の命令コードである。
この命令コードは、モジュール２０２に直ちに、あるいは命令コードに与えられた期限内に、対応するマルチメディアメッセージの回収に着手しなければならない、あるいは、してはならないことを指示することができる。
命令コードは、どのような仕方で、すなわち中継サーバー２０４にコピーを残すか、あるいはコピーを残さずに、対応するマルチメディアメッセージを回収するかを指定することもできる。
これは、可能な命令コードの例に過ぎない。
命令コードが解釈されると、マルチメディアメッセージの回収サブ過程１１４に移行する。

サブ過程１１４と、明細書の例において、モジュール２０２は、通知メッセージ３２０を受信した移動電話がするのと全く同じように振る舞う。
すなわち、モジュール２０２は、ヘッダーフィールド３４１，回収命令コードフィールド３４２と回収されるマルチメディアメッセージの識別フィールド３４３とから成る回収メッセージ３４０を作成する。
実際には、フィールド３４２は、命令コード３１３に対応する。
コード３１３が伝達されなかったとき、コード３４２は、マルチメディアメッセージの回収の単純なコードである。

フィールド３４３は、推奨変型例において、フィールド３３５に対応する。
変型例において、フィールド３４３は、フィールド３２２，３２３，３１２の内容を含んでいて、中継サーバー２０４上のマルチメディアメッセージの指定が可能になる。
実際、送信者、宛先および送信日を知ることによって、中継サーバー２０４のメッセージを見つけることができる。

メッセージ３４０が作成されると、中継サーバー２０４の宛先に送信される。
遠隔通信網の利用条件にできるだけ近い仕方で、メッセージ３４０は、ＷＡＰプロトコルを介して送信される。
モジュール２０２は、このプロトコルによる通信手段を含んでいる。
メッセージ３４０は、例えば、ブリッジ２０５を通過してから、中継サーバー２０４に到達する。

中継サーバー２０４から見ると、メッセージ３４０は、移動電話、または同等の装置から送信される。
したがって、メッセージ３４０は、このタイプの任意のものと同様に処理される。
実際には、中継サーバー２０４は、フィールド３４３の内容に対応するマルチメディアメッセージを自分の保存メモリ内で検索する。
このメッセージが見つかったら、回収のメッセージ／要求３４０を送信した装置宛てにメッセージを送信する。
この目的のために、フィールド３４１は、メッセージ３４０に応答するためのアドレスを含んでいる。
実際には、メッセージ３４０への応答には、少なくともフィールド３０４と３０５が含まれる。
この応答は、メッセージ３００を完全に含めることができる。

サブ過程１１４から、メッセージ３４０への応答処理サブ過程１１５に移行する。
実際には、この処理は、結果のメッセージ３５０の構成をもって成る。
結果メッセージは、マルチメディアメッセージを識別するフィールド３５１を含んでいる。
フィールド３１１に対応するこのフィールドは、発生モジュール２０１によって作成されたフィールド３１１に対応する。
メッセージ３５０は、フィールド３５１によってマルチメディアメッセージの受信通知を受信した日付フィールド３５２も備えている。
変型例において、フィールド３５１は、マルチメディアメッセージに対応する通知を受信した日付と、それが送信された日付の間の差を含んでいる。
この送信日は、フィールド３１２を介して入手できる。
通知受信日は、それが第一の通知メッセージ３２０に含まれているから、あるいはモジュール２０２による第二の通知メッセージ３３０の受信日がモジュール２０６による第一の通知メッセージの受信日と同化できるのでアクセスできる。
もう一つの可能性は、第一の通知を受信してモジュール２０６によって挿入された日付、フィールド３２６を用いることである。

送信日と受信日を比較できるために、少なくともモジュール２０１，２０２と２０６のクロックが連動して、三つのモジュールの、同一の日付が同じ瞬間に対応している。
この連動は、例えば、ＮＴＰプロトコル（ネットワーク時間プロトコル）で実現される。
この連動は、日付を得るために三つのモジュールに問い合わせる唯一のクロックを介して得ることもできる。
この連動プロセスは、その実行が時間的に継続し、他の過程の実行と同時である過程１１８に対応する。

変型例において、メッセージ３５０は、メッセージ３４０の送信とメッセージ３４０に対する応答の完全な受信の間に経過した時間を示すことができる時間フィールドも含んでいる。

最後に、結果メッセージ３５０は、コントロールの総量フィールド３５３も含んでいる。
フィールド３５３は、サブステップ１１４で回収されたマルチメディアメッセージのフィールド３０５の内容からモジュール２０２によって計算されたコントロールの総量を含んでいる。
コントロールの総量を計算するためにモジュール２０２によって使用されるアルゴリズムは、フィールド３１４の作成のためにモジュール２０１によって使用されるものと同一である。
変型例においてフィールド３５３は、モジュール２０１と２０２によって出されたコントロールの総量の比較結果を含んでいる。
このとき、結果は、例えば、差があれば０で、コントロールの総量が同一であれば１で表される。
別の変型例においては、フィールド３５３の内容は、サブ過程１１４で回収されたフィールド３０５の内容と同一である。
この場合、フィールド３０５の内容に対してコントロールの総量の計算を行うかは、メッセージ３５０の宛先モジュールに帰属する。

メッセージ３５０が作成されると、結果の送信過程１１６に移行する。
過程１１６においてモジュール２０２は、結果分析モジュール２０３に向けてメッセージ３５０を送信する。
このとき、サブステップ１１６から送信回収統合過程１１７に移行する。

過程１１７は、結果分析モジュール２０３によって実施される。
変型例において、モジュール２０２は、モジュール２０３と統一される。

過程１１７において、フィールド３１１と３５１によって、モジュール２０１によって送信された情報とモジュール２０２によって作成、送信された結果の情報を相関させることができる。
これらの情報は、同じ性質であり、日付であれ、コントロールの総量であれ比較できる。
したがって、本発明によって、下記についての統計を得ることができる。

マルチメディアメッセージの輸送期間、つまりは、マルチメディアメッセージの送信と、中継サーバー２０４から得られるマルチメディアメッセージの受信を示す通知の受信までの間の経過した時間。

中継サーバー２０４で、マルチメディアメッセージを回収するために必要な時間。
モジュール２０１によってマルチメディアメッセージが送信されたにもかかわらず中継サーバー２０４によって送信されなかった通知の数、すなわち、実際、喪失したマルチメディアメッセージの数。
同一のマルチメディアメッセージについて送信された通知数。
送信されたメッセージと比較して改変された受信マルチメディアメッセージの数。
マルチメディアメッセージ送信の際の、失敗の数、すなわち中継サーバー２０４によって拒絶されたマルチメディアメッセージの数。
マルチメディアメッセージの回収の際の、失敗数。
ならびにモジュール２０１と２０２と中継サーバー２０４の間の通信の際の一般的ネットワーク統計。
かかる統計は、特に通信の質を通信の際に喪失し、間違い、再送信されたパケット数で表すものである。

くわえて、本発明によれば、マルチメディアメッセージのサイズ、および／または、マルチメディアメッセージの内容の種類に応じて、マルチメディアメッセージを送信するためにモジュール２０１によって用いられたプロトコルに応じて統計を設定することができる。

本発明の別の利点は、中継サーバー２０４またはＳＭＳ−Ｃなどのネットワークインフラストラクチャーに対する変更を一切行わないことである。

本発明の変型例において、モジュール２０１は、サービスプロバイダのサーバー２０８と中継サーバー２０４の間の仲介である。
かかる変型例において、使用者は、マルチメディアメッセージを作成／送信するためにサーバー２０８に接続する。
これらのメッセージは、モジュール２０１によって傍受され、モジュール２０１は過程１０４について記載したごとく、これらのマルチメディアメッセージのオブジェクトフィールドを変更する。
このように変更されたマルチメディアメッセージのオブジェクトフィールドは、このとき元のオブジェクトフィールドとフィールド３１１から３１４を含んでいる。
変更されたマルチメディアメッセージの回収通知メッセージはモジュール２０６によって傍受され、このとき通知メッセージをモジュール２０２に向けて、およびマルチメディアメッセージの宛先に向けて送信する。
モジュール２０２への送信は、通知メッセージが変更されたマルチメディアメッセージに対応すると認識された場合にしか行われない。
この認識は、オブジェクトフィールドの構造によって行われる。
宛先のための通知メッセージのオブジェクトフィールドからモジュール２０１によって作成された追加データが追い出される。
モジュール２０２は、マルチメディアメッセージを回収するときに、このメッセージがその宛先によって回収できるようにそのコピーを中継サーバー２０４に残す。
この変型例において、分析モジュール２０３は、主たる変型の場合と同様に、同じ情報を保有する。
したがって、本発明によれば、サービスプロバイダによる正確な統計を実施する。

図２ａは、それぞれのモジュールが使用する手段を示している。
同一の符合は同一の要素を示している。

図２ｂは、生成モジュール２０１がその実施のために、マイクロプロセッサ２５１、プログラムメモリ２５２、通信回路２５３と２５４を使用することを示している。
要素２５１から２５４は、バス２５５によって接続されている。
メモリ２５２は、領域２５２ａ−ｄと２５２ｆ内に通信のさまざまなプロトコル実施のための命令コードを、領域２５２ｅ内にモジュール２０１の機能ためのものを含んでいる。
回路２５３は、モジュール２０１が移動電話のふりをすることを可能にする。
モジュール２０１は、モジュール２０１のパラメータ設定ファイルの記録を可能にするシナリオメモリ２５６も備えている。
かかるパラメータ設定ファイルは、シナリオファイル．ｘｍｌと等価である。
メモリ２５６は、バス２５５に接続されている。

実際には、回路２５３と２６３は、ＷＡＰブリッジ２９１と２９２に接続され、それ自体がネットワーク２４０に接続されている。
ネットワーク２４０は、通信の良好な輸送に有益なすべてのインフラストラクチャーを備えている。
ネットワーク２４０は、インターネット型である。
実際には、ブリッジ２９１と２９２は、図２に示すように、唯一かつ同一のブリッジ２０５とすることができる。
一つあるいは二つのブリッジの存在は、実際には、モジュール２０１と２０２の間に存在する物理的距離に依存する。

図２ｂは、回収モジュール２０２が、その実施のために、マイクロプロセッサ２６１、プログラムメモリ２６２、通信回路２６３と２６４を使用することを示している。
要素２６１から２６４は、バス２６５によって接続されている。
メモリ２６２は、領域２６２ａと２６２ｃ内に通信のさまざまなプロトコル実施のための命令コードを、領域２６２ｂ内にモジュール２０２の機能のためのものを含んでいる。
回路２６３は、モジュール２０２が移動電話のふりをすることを可能にする。
回路２６４は、モジュール２０２がネットワーク２４０を介して通信することを可能にする。

図２ｂは、分析モジュール２０３が、その実施のために、マイクロプロセッサ２７１、プログラムメモリ２７２、通信回路２７４を使用することを示している。
要素２７１から２７４はバス２７５によって接続されている。
メモリ２７２は、領域２７２ｂ内に通信のさまざまなプロトコル実施のための命令コードを、領域２７２ａ内にモジュール２０３の機能ためのものを含んでいる。
回路２７４は、モジュール２０３がネットワーク２４０を介して通信することを可能にする。

図２ｂは、中継サーバー２０４がその実施のために、マイクロプロセッサ２４１、プログラムメモリ２４２、通信回路２４４を使用することを示している。
要素２４１から２４４は、バス２４５によって接続されている。
メモリ２４２は、ＭＭＳ−Ｃの機能を実現するための命令コードを含んでいる。回路２４４は、中継サーバー２０４がネットワーク２４０を介して通信することを可能にする。

図２ｂは、分析モジュール２０６がその実施のために、マイクロプロセッサ２８１、プログラムメモリ２８２、通信回路２８４を使用することを示している。
要素２８１から２８４は、バス２８５によって接続されている。
メモリ２８２は、領域２８２ａ−ｃと２８２ｅ内に通信のさまざまなプロトコル実施のための命令コードを、領域２８２ｄ内にモジュール２０６の機能ためのものを含んでいる。
回路２８４は、モジュール２０６がネットワーク２４０を介して通信することを可能にする。

本発明に従った方法の過程の概略図である。 本発明に従った装置のアーキテクチュアの概略図である。 本発明に従った方法の実施に用いることができる手段の概略図である。 本発明に従った方法を実施したときに送受信される要求メッセージの構造の概略図である。 生成モジュールのマルチプロセス機能を示す概略図である。

符号の説明

２０１ マルチメディアメッセージ生成モジュール
２０２ マルチメディアメッセージ回収モジュール
２０３ 結果分析モジュール
２０４ 中継サーバー
２０５ ブリッジ
２０６ モジュール
２０７ メッセージセンター機器
２０８ サーバー
２１４ フィールド
２４０ ネットワーク
２４１ マイクロプロセッサ
２４２ プログラムメモリ
２４４ 通信回路
２４５ バス
２５１ マイクロプロセッサ
２５２ プログラムメモリ
２５３ 通信回路
２５５ バス
２５６ シナリオメモリ
２６１ マイクロプロセッサ
２６２ プログラムメモリ
２６３ 通信回路
２６４ 回路
２６５ バス
２７１ マイクロプロセッサ
２７２ プログラムメモリ
２７４ 通信回路
２７５ バス
２８１ マイクロプロセッサ
２８２ プログラムメモリ
２８４ 通信回路
２８５ バス
２９１ ブリッジ
３００ マルチメディアメッセージ
３０１ ヘッダーフィールド
３０２ 送信者識別フィールド
３０３ 宛先識別フィールド
３０４ フィールド
３０５ フィールド
３０５ 本文フィールド

３１１ 識別子
３１２ 日付情報
３１３ 命令コード
３１４ フィールド
３２０ 通知メッセージ
３２１ ヘッダー
３２２ フィールド
３２３ 宛先
３２４ オブジェクトフィールド
３２５ 識別フィールド
３２６ フィールド
３３０ 通知メッセージ
３３５ フィールド
３４０ 回収メッセージ
３４１ ヘッダーフィールド
３４２ 回収命令コードフィールド
３４３ 識別フィールド
３５０ 結果メッセージ
３５１ フィールド
３５２ 日付フィールド
３５３ コントロールの総量フィールド
４０１ 予備過程
４０２ 要求
４０３ 割り当て
４０４ 応答
４０５ 作成過程
４０６ メッセージ
４０７ 過程
４０８ 応答
４０９ 過程
４１０ 過程
４１１ メッセージ
４１２ 過程
４１３ メッセージ

Claims (23)

1. 遠隔通信網を介したマルチメディアメッセージのモジュラーによる追跡方法であり、該方法は、マルチメディアメッセージと中継サーバーとを含み、マルチメディアメッセージは、宛先フィールドとオブジェクトフィールドを含み、次の特徴を有する方法。
   ・マルチメディアメッセージは、マルチメディアメッセージ生成モジュールにより作成される。
   ・生成モジュールは、マルチメディアメッセージのオブジェクトフィールド内に、作成されたマルチメディアメッセージに関する情報を組み込む。
   ・作成されたマルチメディアメッセージは、遠隔通信網を介して送信される。
   ・送信されたマルチメディアメッセージは、中継サーバーによって受信される。
   ・中継サーバーが、宛先フィールドによって、識別された宛先に向けてマルチメディアメッセージの受信の第一通知メッセージを作成、伝達し、該メッセージは、マルチメディアメッセージのオブジェクトフィールドの情報を含むものである。
2. 遠隔通信網を介したマルチメディアメッセージのモジュラーによる追跡方法であり、該方法は、マルチメディアメッセージと中継サーバーとを含み、マルチメディアメッセージは、宛先フィールドとオブジェクトフィールドを含み、次の特徴を有する方法。
   ・傍受モジュールは、マルチメディアメッセージの受信に続いて中継サーバーによって送信された通知メッセージを傍受し、第一の通知メッセージの宛先を規定し、宛先に応じて遠隔通信網内で振る舞うか、あるいは、マルチメディアメッセージの回収モジュール宛てに第二の通知メッセージを送信し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にするオブジェクトフィールドを含む。
   ・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求を作成し、中継サーバー宛てに回収要求を送信し、中継サーバーの応答を処理する。
3. ・生成モジュールが、送信したマルチメディアメッセージに関する第一の情報を分析モジュール（２０３）に伝達し、
   ・回収モジュールが、回収したマルチメディアメッセージに関する第二の情報を分析モジュールに伝達し、
   ・第一と第二の情報が同じ種類であることを特徴とする、請求項１または２に記載の方法。
4. マルチメディアメッセージが、ＭＭＳメッセージであることを特徴とする、請求項１から３のいずれか一つに記載の方法。
5. 第一の通知メッセージが、ショート・メッセージであることを特徴とする、請求項１から４のいずれか一つに記載の方法。
6. 回収要求が、ＷＡＰプロトコルを用いて送信されることを特徴とする、請求項２から５のいずれか一つに記載の方法。
7. マルチメディアメッセージのオブジェクトフィールドが、日付情報を含んでいることを特徴とする、請求項１から６のいずれか一つに記載の方法。
8. 異なるモジュールが連動されていることを特徴とする、請求項１から７のいずれか一つに記載の方法。
9. 作成されたマルチメディアメッセージのオブジェクトフィールドが、作成されたマルチメディアメッセージの本文に対応するコントロールの総量を有することを特徴とする、請求項１から８のいずれか一つに記載の方法。
10. 作成されたマルチメディアメッセージのオブジェクトフィールドが、作成されたマルチメディアメッセージの識別情報を有することを特徴とする、請求項１から９のいずれか一つに記載の方法。
11. 自動的に作成されたマルチメディアメッセージのオブジェクトフィールドが、回収モジュールの振る舞いを定義するための命令コードを有することを特徴とする、請求項１から１０のいずれか一つに記載の方法。
12. 傍受モジュールが、中継サーバーによって送信されたデータを処理することを特徴とする、請求項１から１１のいずれか一つに記載の方法。
13. 傍受モジュールが、遠隔通信網のＳＭＳ−Ｃによって送信されたデータを処理することを特徴とする、請求項１から１２のいずれか一つに記載の方法。
14. マルチメディアメッセージが、内容がサイズおよび／または種類において変動する本文を含んでいることを特徴とする、請求項１から１３のいずれか一つに記載の方法。
15. 生成モジュールが、所定の周波数でマルチメディアメッセージを送信することを特徴とする、請求項１から１４のいずれか一つに記載の方法。
16. 生成モジュールが、所定の時間内にマルチメディアメッセージを送信することを特徴とする、請求項１から１５のいずれか一つに記載の方法。
17. 生成モジュールが、異なるプロトコルを介してマルチメディアメッセージを送信することを特徴とする、請求項１から１６のいずれか一つに記載の方法。
18. 通知メッセージが、それが対応する中継サーバーによって受信されたマルチメディアメッセージの識別情報を含んでいることを特徴とする、請求項１から１７のいずれか一つに記載の方法。
19. 生成モジュールは、サービスプロバイダのサーバーと、中継サーバーの間の仲介であり、生成モジュールが、傍受されたマルチメディアメッセージにより、オブジェクトフィールドを修正することを特徴とする、請求項１から１８のいずれか一つに記載の方法。
20. 生成モジュールが、シナリオファイルを介してパラメータ設定されることを特徴とする、請求項１から１９のいずれか一つに記載の方法。
21. 生成モジュールおよび／または回収モジュールが、マルチプロセス論理構造を有することを特徴とする、請求項１から２０のいずれか一つに記載の方法。
22. マルチメディアメッセージが、宛先フィールドとオブジェクトフィールドを含み、マルチメディアメッセージ中継サーバーを含む遠隔通信網を介してマルチメディアメッセージをモジュラーにより追跡し、次の特徴を有する、モジュラーによるマルチメディアメッセージの追跡装置。
    ・メッセージを作成するための生成モジュールを含む。
    ・生成モジュールは、作成されたマルチメディアメッセージに関する情報をマルチメディアメッセージのオブジェクトフィールド内に挿入する手段を含む。
    ・生成モジュールが、作成したマルチメディアメッセージを、遠隔通信網を介して送信する手段を含む。
    ・中継サーバーが、マルチメディアメッセージの第一の受信通知メッセージを作成し、宛先フィールドによって識別された宛先に伝達するための手段を含み、第一の通知メッセージが、その内容が少なくともマルチメディアメッセージのオブジェクトフィールド内の情報を含んでいるオブジェクトフィールドを含む。
    ・傍受モジュールは、第一の通知メッセージを傍受し、第一の通知メッセージの宛先を規定し、宛先に応じて遠隔通信網内で明白に振る舞うか、あるいは、マルチメディアメッセージの回収モジュール宛てに第二の通知メッセージを送信し、第二の通知メッセージは、その内容が第一の通知メッセージに対応するマルチメディアメッセージの識別を可能にするオブジェクトフィールドを含む。
    ・回収モジュールが、第二の通知メッセージに対応するマルチメディアメッセージを回収するために回収要求を作成するための手段を含み、中継サーバー宛てに回収要求を送信する手段も含み、中継サーバーの応答を処理する。
23. ・生成モジュールが、生成モジュールによって送信されたマルチメディアメッセージに関する第一の情報を分析モジュールに伝達する手段を含み、
    ・回収モジュールが、回収したマルチメディアメッセージに関する第二の情報を分析モジュールに伝達するための手段を含み、
    ・第一と第二の情報が同じ性質のものであることを特徴とする、請求項２２に記載の装置。

Images