JP5417438B2 - ショートメッセージ配信に対する課金 - Google Patents

Description

本発明は、単一のユーザからの複数のショートメッセージに課金するためのショートメッセージサービスエンティティ、課金エンティティ、方法及びコンピュータプログラムに関する。

ショートメッセージサービス（ＳＭＳ）は、顧客が頻繁に使用する通信事業者の主力サービスの１つである。ＳＭＳは、伝統的に第３世代パートナーシッププロジェクトにより定義されるシグナリングシステム第７（ＳＳ７）アーキテクチャに基づく。現在３ＧＰＰにより標準化されているこのアーキテクチャは、例えばセッション開始プロトコル（ＳＩＰ）シグナリングを使用して、ショートメッセージ（ＳＭ）がインターネットプロトコル（ＩＰ）ベースのネットワークと相互作用できるようにする。ＳＩＰは、１又はそれ以上の参加者との会話を作成し、修正し、終了するためのアプリケーション層制御プロトコルである。これらの会話は、インターネットマルチメディア会議、インターネット通話、及びマルチメディア配信を含むことができる。会話内のメンバは、マルチキャスト、又はユニキャスト関連のメッシュ、或いはこれらの組み合わせを介して通信することができる。ＳＩＰは、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）内のシグナリングプロトコルとして使用される。

３ＧＰＰはまた、オンライン課金サーバ（ＯＣＳ）とＳＭＳルータ又はＩＰ−ＳＭゲートウェイとの間のＤｉａｍｅｔｅｒ（すなわちＩＰプロトコル）ベースのオンライン課金インターフェイス（Ｒｏ）の定義を含む、ＩＰシグナリング及び旧来のＳＭシグナリングの両方のための新たな課金フレームワークも標準化する。現在のところ、Ｒｆインターフェイスに基づくオフライン課金のための方法は標準化されていない。アーキテクチャの選択肢として、ＳＭＳルータは、例えばＳＭサービスセンター（ＳＭＳＣ）又は別個のノードであってもよい。

現在のところ、ＳＭは１つの宛先にしか送信することができない。送信者が、同じメッセージを２以上の宛先（受信者）に送信したいと望む場合には、同じＳＭを再送しなければならない。このような再送信は、加入者自身（保存された送信済みメッセージの再送信）により、又は端末アプリケーションにより起動することができる。端末アプリケーションの場合、送信者が、同報通信したいと望むＳＭに複数の宛先を割り当てる一方で、端末アプリケーションが、受信者ごとに１つのＳＭを実際に発信することにより同報通信を遂行する。この結果、ＳＭＳデータ、シグナリング、及び課金に関しても複数のＳＭＳトラフィックが生じる。

通信事業者は、このような意図的に同報通信されたメッセージを単一のイベントと見なさなければならない。したがって、コアネットワーク並びに課金インフラストラクチャ、すなわち前払い加入者のためのＯＣＳが性能問題に直面する恐れがある。

本出願では、「ユニット」という用語と「手段」という用語を同義語として使用する。例えば、「送信ユニット（３０３）」と「送信手段（３０３）」は同じ意味になる。

本発明は、単一のユーザを出どころとする複数のショートメッセージ（ＳＭ）を配信するための少なくとも１つの要求を検出するステップと、この複数のショートメッセージの受信者に関する情報をシグナリングメッセージに組み合わせるステップと、このシグナリングメッセージを課金機能に送信するステップとを含むショートメッセージサービスエンティティ及び方法を提供することにより上記の問題を解決する。送信は、第３世代パートナシッププロジェクト（３ＧＰＰ）のＲｏ及び／又はＲｆインターフェイスを介してシグナリングメッセージを送信する送信手段により行うことができる。受信者に関する情報は、複数のショートメッセージの受信者の識別情報を含むことができ、組み合わせステップは、複数のショートメッセージの受信者の識別情報を属性値ペア（ＡＶＰ）に含めるステップを含むことができる。受信者の識別情報を含めるステップは、個々のショートメッセージの受信者の識別情報を別個の属性値ペア（ＡＶＰ）に含めて、受信者に配信すべきショートメッセージごとに１回、属性値ペア（ＡＶＰ）がシグナリングメッセージに組み込まれるようにするステップを含むことができる。属性値ペア（ＡＶＰ）は、［受信者アドレス］属性値ペア（ＡＶＰ）を含むことができる。ＳＭＳエンティティ及び方法は、受信者の識別情報を含む属性値ペア（ＡＶＰ）を、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）に組み込むステップをさらに含むことができ、このステップは、例えば、
− 受信者の識別情報を含む個々の属性値ペア（ＡＶＰ）を、受信者を示すための別個のさらなる属性値ペア（ＡＶＰ）に組み込むこと、又は、
− 受信者の識別情報を含む全ての属性値ペア（ＡＶＰ）を、受信者を示すための単一のさらなる属性値ペア（ＡＶＰ）に組み込むこと、又は、
− 上記選択肢の両方の混合、
により行うことができる。

組み込みステップは、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）を［ＳＭＳ情報］属性値ペア（ＡＶＰ）に組み込むステップを含むことができる。

ＳＭＳエンティティ及び方法は、複数のショートメッセージ（ＳＭ）を配信するための少なくとも１つの要求を受信するステップ、及び／又は複数のショートメッセージを通信システム内のさらに先へ中継するステップをさらに含むことができる。中継ステップは、
− 少なくとも１つの配信要求を、この少なくとも１つの配信要求を受信手段が受信したときのものと同じプロトコルに従って中継するステップ、又は、
− 少なくとも１つの配信要求を、この少なくとも１つの要求を複数のショートメッセージを伝達するための別のプロトコルに変換した後に中継するステップ、
を含むことができる。

ＳＭＳエンティティ及び方法は、少なくとも１つの要求のうちの最初の要求を受信した後に、単一のユーザを出どころとするショートメッセージを配信するためのさらなる要求を受信するかどうかをチェックするために所定の時間待機するステップをさらに含むことができ、さらなる要求を受信した場合、前記組み合わせステップが、受信者に関する情報をシグナリングメッセージに組み合わせるステップを含むことができる。

本発明は、単一のユーザを出どころとする複数のショートメッセージを配信することに関する課金要求を受信するステップを含む課金エンティティ及び方法をさらに提供する。この課金要求は、Ｄｉａｍｅｔｅｒプロトコルに従う要求とすることができる。課金エンティティ及び方法は、例えば受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）から受信者の識別情報を含む属性値ペア（ＡＶＰ）を抽出することにより、さらに［ＳＭＳ情報］属性値ペア（ＡＶＰ）から受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）を抽出することにより、個々のショートメッセージ配信の受信者の、各々が別個の［受信者アドレス］属性値ペア（ＡＶＰ）に組み込まれた識別情報を、受信した要求内で抽出するステップを含むことができる。

課金エンティティ及び方法は、単一のユーザを出どころとする前記複数のショートメッセージを配信するための価格を定めるステップを含むことができ、ショートメッセージの数を考慮して、ショートメッセージごとの価格又は全てのショートメッセージを配信するための合計価格が定められる。

さらなる実施形態では、コンピュータプログラムが、コンピュータのメモリにロードされたときに、上記概説した方法の実施形態のうちのいずれかのステップを引き起こすようにされたコード手段を備えることができる。

さらなる実施形態では、通信システムが、上記概説した実施形態のうちのいずれかの課金機能及びショートメッセージサービス（ＳＭＳ）エンティティを備えることができる。

本発明の実施形態は、以下の利点のうちの１又はそれ以上をもたらすことができる。
− 同じユーザ／送信者からの複数の配信されたＳＭに関する課金要求をより効果的に課金システムに送信することができる。
− ＳＭＳエンティティが、ＳＭ事前集計エンティティとして機能することができる。すなわち、ＳＭＳエンティティが、所定の数（バケット）のＳＭ課金要求を加入者ごとに収集し、バケットが一杯になると、複数の宛先を含む「収集済み」課金要求をＯＣＳに対して開始することができる。
− アプリケーションが、（例えばＳＭＰＰを使用することにより）ＳＭＳＣに直接アクセスして、複数の宛先を１つの（ＳＭＰＰ）要求に含めて送信できる一方で、ＳＭＳＣが、複数の宛先を含む課金要求を送信することができる。
− アプリケーションにより生成されたＳＭについては、ＳＭ生成ノードからＳＭＰＰ及びＵＣＰなどのＩＰインターフェイスベースの業界標準を介してＳＭＳＣに直接アクセスすることができる。この結果、ＳＭのシグナリング及び課金のためのＩＰトラフィックが増加する。したがって、本発明の態様は、サービスの効率を高めてＩＰトラフィックを低減させる。この結果、最終的にネットワーク通信事業者の資本支出（ＣＡＰＥＸ）及び経常支出（ＯＰＥＸ）が減少するようになる。
− クライアント（ＳＭＳノード）及びサーバ（ＯＣＳ）の両ピアにおけるシグナリング及びＳＭデータの記憶リソースの節約。
− ＯＣＳにおける新たなレーティング特性の使用を通信事業者に提供する。
− ＯＣＳにより制御される過負荷防止及びエラー訂正、例えばアプリケーションによるＳＭの処理中におけるＳＭ宛先数の制限。

本発明に関連するショートメッセージ課金シナリオを示す図である。 本発明に関連するショートメッセージ課金シナリオを示す図である。 本発明に関連するショートメッセージ課金シナリオを示す図である。 本発明の態様を実施するＳＭＳノード及び課金ノードの内部構造及び機能を示す図である。 本発明に関連するネットワークアーキテクチャ例を示す図である。 本発明の実施形態によるＳＭＳノードの処理例を示す図である。 本発明の実施形態による課金システムの処理例を示す図である。

ショートメッセージピアツーピア（ＳＭＰＰ）プロトコルは、ショートメッセージエンティティ、ＳＭルータ、及びメッセージングセンターの間でＳＭを送信するための業界設計プロトコルである。メッセージングエンティティは、例えば、固定ネットワークＳＭＳクライアント、無線アプリケーションプロトコル（ＷＡＰ）プロキシサーバ、電子メールゲートウェイ、又はボイスメールサーバであってもよい。

モバイルアプリケーションパート（ＭＡＰ）は、移動体ネットワークセンターとレジスタとの間のシグナリングに使用される移動体ネットワークのシグナリングシステムの一部である。ＭＡＰは、位置更新、移動局への着呼の呼制御、及びショートメッセージの送信に使用される。

サービスセンター（ＳＣ）（本明細書ではＳＭＳノードとも呼ぶ）は、ＳＭエンティティ（ＳＭＥ）とＭＳ（本明細書ではユーザ機器［ＵＥ］又はユーザとも呼ぶ）との間のショートメッセージの中継、記憶、及び転送に関与する機能である。ＩＰショートメッセージゲートウェイ（ＩＰ−ＳＭ−ＧＷ）は、ＩＰベースのユーザ機器（ＵＥ）とＳＣとの間のプロトコル相互作用に関与する機能である。

ＳＭＳＩＰメッセージは、そのテキスト本文内にＳＭをカプセル化するＳＩＰ即時メッセージである。

ＩＰ−ＳＭ−ＧＷは、ＩＰベースのＵＥとＳＭＳ−ＳＣとの間でショートメッセージを配信するためのプロトコル相互作用を実現する。ＳＭＳベースのユーザへの配信では、ＳＭＳ−ＳＣへメッセージを送信することができ、或いはＩＰベースのＵＥへの配信では、ＳＭＳベースのＵＥのＳＭＳ−ＳＣからメッセージを受信することができる。ＩＰ−ＳＭ−ＧＷの機能は、以下の通りである。
− ＳＭを配信するためのドメイン（回線交換（ＣＳ）、パケット交換（ＰＳ）又はＩＭＳ）を決定すること。
− 従来のＭＡＰプロトコルを使用してＳＭＳ−相互作用（ＩＷ）移動体交換センター（ＭＳＣ）に接続し、このＳＭＳ−ＩＷ ＭＳＣに対し、Ｅ又はＧｄインターフェイスを使用してＭＳＣ又はサービングゲートウェイ交換ノード（ＳＧＳＮ）のように見せること。
− 従来のＭＡＰプロトコルを使用してホーム加入者サーバ（ＨＳＳ）に接続し、ＣＳ／ＰＳにおけるＳＭの終了のためのＭＳＣ／ＳＧＳＮアドレスのアドレスを取得すること。
− ユーザの識別情報間の関連性についての知識を取得して保持すること。
− ＳＭＳユーザのＩＭＳメッセージを受信した際に、ＩＰ−ＳＭ−ＧＷがＳＭＳ内の送信者及び受信者の有効なアドレスを有していることをチェックすること。ＩＰ−ＳＭ−ＧＷは、ＩＭＳメッセージのＳＩＰヘッダから両方の有効なアドレスを取得しなければならない（例えば、送信者はＴＥＬ ＵＲＩの形の有効なｉｄで識別される）。
− 終了手続きでは、ＩＰベースのＵＥのＳＭＳを受信した場合、受信者のアドレスをＭＳＩＳＤＮ／ＩＭＳＩフォーマットからＴＥＬ ＵＲＩフォーマットにマップすることであり、このとき要求に応じてＳＩＰ ＵＲＩのためにさらなるいずれかのマッピングを行うのはＩＭＳコアの役割である。
− ＩＭＳコアのためにアプリケーションサーバ（ＡＳ）として機能すること。
− 受信者にメッセージを配信するのに適したドメインを選択するためのドメイン選択を行って、ＨＳＳからＭＳＣ及び／又はＳＧＳＮアドレスを取得すること。

課金は、電気通信ネットワーク及び関連する課金要素内の機能であり、これにより課金対象者に請求できる（オフライン課金）使用、又は加入者の口座残高から引き落としできる（オンライン課金）使用を特定できるようにするために、課金対象イベントに関する情報を収集し、初期化し、転送し、評価する。

オフライン課金は、提供されるサービスに課金情報がリアルタイムで影響しない課金メカニズムであるのに対し、オンライン課金は、提供されるサービスに課金情報がリアルタイムで影響し得るメカニズムであり、従って課金メカニズムがセッション／サービス制御体と直接やりとりすることが必要となる。

Ｄｉａｍｅｔｅｒ基本プロトコルは、インターネット技術標準化委員会（ＩＥＴＦ）により定義された、ダイアルアップＩＰ及び移動体ＩＰなどのネットワークアクセスサービスに使用される認証、許可、及びアカウンティング（ＡＡＡ）プロトコルである。Ｄｉａｍｅｔｅｒノードは、Ｄｉａｍｅｔｅｒプロトコルを実施するとともに、クライアント、エージェント、又はサーバとして機能するホスト処理である。ＩＭＳオフライン課金のための方法と同様のＲｆインターフェイス方法として、Ｄｉａｍｅｔｅｒアカウンティングを使用してオフライン課金のための課金データの収集を実施することができる。Ｄｉａｍｅｔｅｒアカウンティングアプリケーションは、アカウンティングメッセージ、すなわちアカウンティング要求（ＡＣＲ）メッセージ及びアカウンティング回答（ＡＣＡ）メッセージを使用してセッションのオンライン課金を処理する。Ｄｉａｍｅｔｅｒクレジット制御アプリケーション（ＤＣＣＡ）は、様々なエンドユーザサービスのオンラインクレジット制御を実施するために使用できるＤｉａｍｅｔｅｒプロトコルアプリケーションである。これらのサービスとして、例えば、ネットワークアクセス、ＳＩＰサービス、メッセージングサービス、及びダウンロードサービスを挙げることができる。Ｄｉａｍｅｔｅｒクレジット制御アプリケーションは、クレジット制御メッセージ、すなわちクレジット制御要求（ＣＣＲ）メッセージ及びクレジット制御回答（ＣＣＡ）メッセージを使用してセッションのオンライン課金を処理する。Ｄｉａｍｅｔｅｒクライアントは、ＤｉａｍｅｔｅｒサーバへＣＣＲメッセージを送信し、応答としてＣＣＡメッセージを受信する。３ＧＰＰオンライン課金では、ＩＥＴＦＤｉａｍｅｔｅｒクレジット制御アプリケーションにより定められる基本機能が使用される。基本構造は、例えば課金トリガ機能（ＣＴＦ）などのオンラインクライアントがリソース割り当てを要求して、クレジット制御情報をオンライン課金システム（ＯＣＳ）に報告するようなメカニズムに従う。

ＳＭＳオンライン課金は、Ｄｉａｍｅｔｅｒクレジット制御アプリケーションを使用し、即時イベント課金（ＩＥＣ）の原理又はユニット予約によるイベント課金（ＥＣＵＲ）を使用することができる。加入者に課金するための課金対象イベントは、ＳＭトランザクションに関連付けられる。３ＧＰＰにより規定されるように、オンライン課金では、ＳＭＳノードが、いわゆるＲｏインターフェイス及びＯＣＳのためのアプリケーションを利用する。Ｒｏ参照点はＤｉａｍｅｔｅｒに基づくものであり、ＳＭＳに必要な全てのオンライン課金機能を対象とする。ＳＭＳノードは、例えば、ＳＭＳルータ、ＩＰ−ＳＭ−ＧＷ、又はこれらの両方とすることができる。

図１は、即時イベント課金（ＩＥＣ）の例を示している。ステップ１１において、ＳＭＳノード１が、いずれのＳＭＳメカニズム（すなわちＳＭＳ又はＳＭＳＩＰ）が動作しているかに応じて、ＳＭ提出（ＳＭ−Ｓｕｂｍｉｔ）又はＭＡＰ転送ＳＭ（ＭＡＰ−Ｆｏｒｗａｒｄ−ＳＭ）を受信する。ステップ１２において、ＳＭＳノード１が、例えばＲｏインターフェイスを介して、ＯＣＳ２に対してユニット引き落とし要求（Ｄｅｂｉｔ Ｕｎｉｔｓ Ｒｅｑｕｅｓｔ）メッセージをトリガする。ステップ１３において、ＯＣＳ２が、受信した要求に基づいて適当なクレジット処理を行う。ステップ１４において、ＯＣＳ２が、ユニット引き落とし応答（Ｄｅｂｉｔ Ｕｎｉｔｓ Ｒｅｓｐｏｎｓｅ）メッセージでＳＭＳノード１に応答する。ステップ１５において、許可された場合、ＳＭＳノード１が、開始手順に適したＳＭ処理を継続する。

図１ａは、オフライン課金システム（ＯＦＣＳ）とともに動作するＳＭＳメカニズムを示している。図１とは対照的に、ここではステップ１２ａにおいて、ＳＭＳノード１が、例えばＲｆインターフェイスを介して課金データ要求メッセージによりＯＦＣＳ２ａをトリガすることができる。ステップ１３ａにおいて、ＯＦＣＳ２ａが、受信した要求に基づいて適当な課金データ収集を行うことができる。ステップ１４ａにおいて、ＯＦＣＳ２ａが、課金データ応答メッセージでＳＭＳノード１に応答することができる。

図１及び図１ａでは、ＯＣＳ２又はＯＤＣＳ２ａから応答を受信する（ステップ１４又は１４ａ）前に、ショートメッセージの転送（ステップ１５）を行うこともできる。

図２は、ユニット予約によるイベント課金（ＥＣＵＲ）の例を示している。ステップ２１において、ＳＭＳノード１が、いずれのＳＭＳメカニズム（すなわちＳＭＳ又はＳＭＳＩＰ）が動作しているかに応じて、着信するＳＭ提出又はＭＡＰ転送ＳＭを受信する。ステップ２２において、ＳＭＳノード１が、ＯＣＳ２に対してユニット予約要求（Ｒｅｓｅｒｖｅ Ｕｎｉｔｓ Ｒｅｑｕｅｓｔ）（開始）メッセージをトリガし、ステップ２３において、ＯＣＳ２が、受信した要求に基づいて適当なクレジット処理を行う。ステップ２４において、ＯＣＳ２が、ユニット予約応答（Ｒｅｓｅｒｖｅ Ｕｎｉｔｓ Ｒｅｓｐｏｎｓｅ）メッセージでＳＭＳノード１に応答する。ステップ２５において、許可された場合、ＳＭＳノード１が、開始手順に適したＳＭ処理を継続する。ステップ２６において、ＳＭトランザクションの受信が正常に確認され、ステップ２７において、ＳＭＳノード１が、ＯＣＳ２に対してユニット予約要求（終了）メッセージをトリガし、成功したイベントトランザクションを報告する。最後にステップ２８において、ＯＣＳ２が、受信した要求に基づいて適当なクレジット処理を行い、ステップ２９において、ＯＣＳ２が、ユニット予約応答メッセージでＳＭＳノード１に応答する。

Ｄｉａｍｅｔｅｒメッセージは、属性値ペア（ＡＶＰ）を含むことができる。ＡＶＰは、属性ヘッダ及び対応する値からなる一般的な値のペアである。属性値ペアは、経路情報、及び認証情報、許可情報、又はアカウンティング情報などの、プロトコルに特化したデータをカプセル化するために使用される。ＡＶＰは、内部にさらなるＡＶＰを含むことができる。

ショートメッセージでは、「ＳＭＳ情報」ＡＶＰが定義される。ＡＶＰは、追加のＳＭＳサービスに特化した情報要素の送信を可能にする。「ＳＭＳ情報」ＡＶＰを、ＳＭＳノードなどの課金トリガ機能（ＣＴＦ）から、請求システムなどの、オフライン課金のための課金データ機能（ＣＤＦ）へ、及びオンライン課金のためのオンライン課金機能（ＯＣＦ）に送信することができる。「ＳＭＳ情報」ＡＶＰは、以下の構造を有する。
ＳＭＳ情報：：＝＜ＡＶＰヘッダ：２０００＞
［ＳＭＳノード］
［クライアントアドレス］
［発信者ＳＣＣＰアドレス］
［受信者ＳＣＣＰアドレス］
［ＳＭＳＣアドレス］
［データ符号化スキーム］
［宛先インターフェイス］
［ＳＭ送出時刻］
［ＳＭメッセージタイプ］
［発信者インターフェイス］
［ＳＭプロトコルＩＤ］
［要求応答経路］
［ＳＭステータス］
［ＳＭユーザデータヘッダ］
［送信済みメッセージ数］

マルチメディアメッセージングサービス（ＭＭＳ）に関しては、メッセージの受信者を識別することを目的として受信者アドレスＡＶＰが定義されている。受信者アドレスＡＶＰは以下の構造を有する。
受信者アドレス：：＝＜ＡＶＰヘッダ：１２０１＞
［アドレスタイプ］
［アドレスデータ］
［アドレスドメイン］
［受取人タイプ］

ＭＭＳの「受信者アドレス」ＡＶＰは、１つのマルチメディアメッセージ（ＭＭ）につき複数回出現することができる。個々の「受信者アドレス」は、マルチメディアメッセージを同報通信すべき１人の受信者（ユーザ）を定義する。ＳＭサービスでは、「受信者アドレス」ＡＶＰの個々のインスタンスが、同一人の異なる識別情報、すなわち移動体加入者国際ＩＳＤＮ番号（ＭＳＩＳＤＮ）及び国際移動体加入者識別情報（ＩＭＳＩ）として定義される。このことは、例えば、加入者（移動体）の番号が移植された結果、異なる料率が適用され得るようになる場合でも加入者を特定するために必要である。

現時点では、ＳＭでは「実際の」宛先が１つしか存在しないことが想定されており、ＳＩＰメッセージも同様に１つの宛先（要求ＵＲＩ）しか含むことができないので、この想定はインスタントメッセージング（ＩＭ）の相互作用にも当てはまる。このＲ−ＵＲＩはグループリストエントリの場合もあるが、それでも１つの宛先であることを保ち、課金インターフェイス上で複数の受信者に分解することはない。

ＳＭＳ Ｒｏインターフェイス課金データは、予め定義されたＭＭＳパラメータ（Ｄｉａｍｅｔｅｒ用語で属性値ペア（ＡＶＰ））を必要に応じて再使用することができる。ＳＭの宛先に関しては、ＳＭＳ情報ＡＶＰ内で複数のインスタンスとして存在し得る受信者アドレスＡＶＰを使用することができる。

しかしながら、ＭＭＳに関しては、受信者アドレスの個々のインスタンスが非同一人であると想定されるのに対し、ＳＭＳでは、個々のインスタンスが同一人の異なる識別情報として定義される。したがって、ＳＭＳ環境において受信者アドレスを異なる宛先のために単純に再使用することは、プロトコル構文が不変であるという理由で不可能である。１つのタイプの受信者アドレス（識別情報）が別のタイプの同じ受信者アドレス（識別情報）に属するかどうか、すなわち、これらの識別情報が同じ受信者の異なる識別情報であるか、それとも実際に異なる受信者の異なる識別情報であるかを識別するための正式な手段は存在しない。

現在の定義で内々に実現できないレーティング入力として受信者リストを（異なる宛先という意味で）使用するための要件も存在する。すなわち、ＳＭ当たりの価格を１つのＳＭの受信者の総数に依存させることができ、例えば１つのＳＭを送信する価格を０．１０ユーロとすることができる一方で、同じＳＭを複数の受信者に送信する場合には、個々の受信者当たりの又は個々の追加の受信者当たりの価格を０．０７ユーロとすることができる。

上記問題を解決する試みは以下の通りである。
・受信者アドレスの使用に関する通信事業者固有の定義及び制約：この場合、例えば、１つの宛先しか存在せず、あらゆる受信者アドレスを異なるＩｄとすること、個々の受信者アドレスを異なる宛先と見なすこと、異なる宛先が存在するが、他の任意に運ばれるＩｄとの関連性がないＭＳＩＳＤＮ（Ｅ．１６４）などの同じタイプで必ずシグナリングすること、などの特定の合意された規則を定義ごとに適用することができ、或いはより複雑な何らかの規則を適用することができる。
・別の選択肢は、受信者アドレスＡＶＰ構造内で既存のＡＶＰを或る種の受信者識別子（又は相関Ｉｄ）として転用することである。すなわち、例えば、受信者アドレス（タイプ＝ＭＳＩＳＤＮ、ＩＤ＝１）、受信者アドレス（タイプ＝ＩＭＳＩ、ＩＤ＝１）、受信者アドレス（タイプ＝ＭＳＩＳＤＮ、ＩＤ＝２）のように宛先ごとに異なる番号を使用する。このような例外的な使用に利用できる唯一のＡＶＰは、受取人タイプ（「ｔｏ」、「ｃｃ」、及び「ｂｃｃ」という３つの異なる値で列挙されるデータタイプ）である。上記の両解決策では完全な柔軟性が得られない。

本発明のある実施形態によれば、１又はそれ以上の［受信者アドレス］ＡＶＰを保持できる新たなグループ化したＡＶＰが提供される。
＊［受信者］／／新たなグループ化したＡＶＰ，複数存在
＊［受信者アドレス］／／既存のＭＭＳ ＡＶＰ，複数存在
［アドレスタイプ］／／既存のサブＡＶＰ

この新たなＡＶＰを以下のように［ＳＭＳ情報］ＡＶＰに組み込むことができる。
ＳＭＳ情報：：＝＜ＡＶＰヘッダ：２０００＞
［ＳＭＳノード］
［クライアントアドレス］
［発信者ＳＣＣＰアドレス］
［受信者ＳＣＣＰアドレス］
［ＳＭＳＣアドレス］
［データ符号化スキーム］
［宛先インターフェイス］
［ＳＭ送出時刻］
［ＳＭメッセージタイプ］
［発信者インターフェイス］
［ＳＭプロトコルＩＤ］
［要求応答経路］
［ＳＭステータス］
［ＳＭユーザデータヘッダ］
［送信済みメッセージ数］
＊［受信者］

本発明のこの態様によれば、本明細書で［受信者］と呼ぶ新たなＡＶＰパラメータを使用するＳＭＳ課金により、無限数の異なる受け手の宛先を処理できるようになる。新たなＡＶＰ（［受信者］）の機能は、ＭＭＳのために定義された１又はそれ以上の［受信者アドレス］ＡＶＰを保持することである。１つの選択肢しか使用してはならないという条件でＭＭＳを再使用しながら、ＳＭＳ情報にこの新たな構造を入れ込むだけで後方互換性を達成することができる。

以下の例では、［受信者アドレス］ＡＶＰに記憶されたＳＭ受信者識別情報をいかにしてにＤｉａｍｅｔｅｒに組み込むことができるかについて説明する。第１の例では、１つの［受信者］ＡＶＰに全ての［受信者アドレス］ＡＶＰを組み込み、さらにこの［受信者］ＡＶＰを、例えばＤｉａｍｅｔｅｒクレジット制御要求（ＣＣＲ）内の［ＳＭＳ情報］ＡＶＰに組み込むことができる。
［ＣＣＲ要求］
−［ＳＭＳ情報］
−−［受信者］
−−−［受信者アドレス］
−−−［受信者アドレス］
−−−［受信者アドレス］

第２の例では、個々の［受信者アドレス］ＡＶＰを別個の［受信者］ＡＶＰに組み込み、その後さらにこれらの［受信者］ＡＶＰを、例えばＤｉａｍｅｔｅｒＣＣＲ内の［ＳＭＳ情報］ＡＶＰに組み込むことができる。
［ＣＣＲ要求］
−［ＳＭＳ情報］
−−［受信者］
−−−［受信者アドレス］
−−［受信者］
−−−［受信者アドレス］
−−［受信者］
−−−［受信者アドレス］

例えば、複数ではあるが全てではない［受信者アドレス］ＡＶＰを１つの［受信者］ＡＶＰに組み込むような他の変形例も可能である。

［ＳＭＳ情報］内のＳＭＳ課金に使用できる構成要素を、３ＧＰＰ仕様書ＴＳ３２．２７４の表に見いだすことができる。新たなＡＶＰをイタリックフォントで示している。
表：ＳＭＳ課金に使用されるＳＭＳ情報

３ＧＰＰ仕様書ＴＳ３２．２９９に以下の定義を導入することができる。
受信者ＡＶＰ

受信者ＡＶＰ（ＡＶＰコード２０ｘｘ）は、グループ化タイプのものであり、メッセージの受信者アドレスのリストを含む。受信者ＡＶＰは以下のＡＢＮＦ文法を有する。
受信者：：＝＜ＡＶＰヘッダ：２０ｘｘ＞
＊［受信者アドレス］

図３は、本発明の態様を実施するＳＭＳノードの機能及び構造例を示している。ＳＭＳノード１は、単一のユーザ／送信者３からの２以上のＳＭを配信するための（単複の）要求を検出できる検出ユニット３０１を備えることができる。ＳＭＳノード１は、複数のショートメッセージの受信者に関する情報を（単一の）シグナリングメッセージに組み合わせるように構成された組み合わせユニット３０２を含むことができる。受信者に関する情報は、ＭＳＩＳＤＮ、Ｅ．１６４番号、又はＩＭＳＩなどの、受信者の識別情報を示すことができる。受信者の識別情報を属性値ペア（ＡＶＰ）に、例えば［受信者アドレス］ＡＶＰに含めるように組み合わせユニット３０２を構成することにより、個々のショートメッセージの受信者の識別情報が別個のＡＶＰに挿入され、この結果、受信者に配信すべきショートメッセージごとに１回、このＡＶＰがシグナリングメッセージに組み込まれるようにすることができる。ＳＭＳノードは、受信者の識別情報を含むＡＶＰを、受信者を示すための少なくとも１つのさらに次のレベルのＡＶＰに組み込むための組み込みユニット３０４を備えることができる。この新たなＡＶＰを例えば［受信者］と呼ぶことができ、このＡＶＰを単一のメッセージ又はＡＶＰ内で複数回繰り返すことができる。組み込みユニット３０４は、受信者を示すためのさらなるＡＶＰを［ＳＭＳ情報］ＡＶＰに組み込むように構成することができ、またこの［ＳＭＳ情報］を、ＯＣＳ２に送信すべきＤｉａｍｅｔｅｒＣＣＲシグナリングメッセージに、及びＯＦＣＳ２ａに送信すべきＤｉａｍｅｔｅｒＡＣＲシグナリングメッセージに含めることができる。

送信ユニット３０３は、組み合わせユニット３０２及び組み込みユニット３０４により部分的に構築されたシグナリングメッセージを課金機能２へ、例えばオンライン課金システム（ＯＣＳ）２又はオフライン課金システム（ＯＦＣＳ）２ａに送信することができる。送信ユニット３０３は、Ｄｉａｍｅｔｅｒプロトコルベースのインターフェイスを介してシグナリングメッセージを送信することができ、また３ＧＰＰにより定義されるＲｏインターフェイスを介して送信することもできる。

ＳＭＳノード１は、２以上のＳＭを配信するための（単複の）要求を受信するための受信ユニット３０５を含むことができる。受信ユニット３０５は、例えば、モバイルアプリケーションパート（ＭＡＰ）、ショートメッセージピアツーピア（ＳＭＰＰ）プロトコル、セッション開始プロトコル（ＳＩＰ）、ショートメッセージオーバーＳＩＰ（ＳＭＳＩＰ）、又はその他のＩＰベースのプロトコルに従って要求を受信することができる。検出ユニット３０１は、受信した要求内で（単複の）ショートメッセージの配信が要求されていることを検出するように構成することができる。

ＳＭＳノード１は、ショートメッセージサービスルータ（ＳＭＳルータ）、インターネットプロトコル−ショートメッセージサービスゲートウェイ（ＩＰ−ＳＭ−ＧＷ）、及び／又はショートメッセージサービスセンター（ＳＭＳＣ）の機能を実施することができる。

ＳＭＳノード１は、ショートメッセージをＳＭＳシステム４０内のさらに先へ中継し、転送し、又は送信するように構成された中継ユニット３０６を備えることができる。中継ユニット３０６は、配信を行うための（単複の）要求を、この（単複の）要求を受信ユニット３０５が受信したときのものと同じプロトコルに従って中継することができ、或いはＳＭを配信するための（単複の）要求を、この（単複の）要求をＳＭを伝達するための別のプロトコルに変換した後に中継することができる。プロトコルの例には、ＭＡＰ、ＳＩＰ、ＳＭＳＩＰ、及びＳＭＰＰがある。

ＳＭＳノード１は待機ユニット３０７を備えることもでき、この待機ユニット３０７は、（単複の）ＳＭを配信するための要求を受信した後に所定の時間待機して、同じ単一のユーザ３を出どころとする、ＳＭを配信するためのさらなる要求を受信するかどうかをチェックするようにされる。待機ユニット３０７はタイマを備えることができ、同じユーザから受信した個々のＳＭ要求の後にこのタイマを再始動して、同じ送信者に関するさらに別の（単複の）ＳＭ要求を受信するかどうかをモニタすることができる。タイマの稼働時にさらなる（単複の）要求を受信した場合、受信者に関する情報をシグナリングメッセージに組み合わせるように組み合わせユニット３０２を構成することができる。中継ユニット３０６による実際のＳＭ配信は、課金の要求を収集するにも関わらず即座に継続することができ、或いは課金関連のタスクが完了するまで、例えば送信ユニット３０３が前払いユーザの信用調査を行うことができるまで中継ユニット３０６によるＳＭ配信を延期することもできる。

図３は、本発明の態様を実現するＯＣＳ２又はＯＦＣＳ２ａなどの課金エンティティ２の機能及び構造も示している。課金エンティティ２は、単一のユーザ３を出どころとする複数のショートメッセージを配信することに関する課金要求、例えば、ＤｉａｍｅｔｅｒＣＣＲなどのユニット引き落とし／予約要求、又はＤｉａｍｅｔｅｒＡＣＲなどの課金データ要求を受信するようにされた受信ユニット３１１を備える。課金エンティティ２は、個々のショートメッセージ配信の受信者の（ＭＳＩＳＤＮ、ＩＭＳＩなどの）識別情報を、受信した要求内で抽出するように構成された抽出ユニット３１２を備えることができる。個々の識別情報を別個の［受信者アドレス］ＡＶＰに組み込むことができる。抽出ユニット３１２は、受信者の識別情報を含むＡＶＰを受信者を示すための少なくとも１つさらなるＡＶＰから抽出することができ、さらにこの少なくとも１つのさらなるＡＶＰを［ＳＭＳ情報］属性値ペア（ＡＶＰ）から抽出することができる。さらに、課金エンティティ２は価格決定ユニット３１３を備えることができ、この価格決定ユニット３１３は、抽出ユニット３１２から抽出情報を受け取り、ユーザ／送信者から配信されたショートメッセージの数を考慮することによりショートメッセージごとの価格、又は全てのショートメッセージを配信するための合計価格を計算する。

上述した全てのユニットは、例えばマイクロプロセッサ及び／又はその他の電気構成要素を使用して、及び／又はソフトウェアにより実装することができる。

課金機能及びＳＭＳエンティティは、スイッチ、ルータ、サーバ、又はデータ送信及び処理タスクをサポートできるその他のハードウェアプラットフォーム又は電子機器内に物理的に実装することができ、或いはその他の既存の装置の構成要素として実装することができる。

次に、ネットワーク４０における複数受信者ＳＭのネットワークアーキテクチャ及び送信例を示す図４を使用して本発明のいくつかの態様について説明する。ＵＥ３は、ＩＭＳ４サービスに加入しているＳＩＰクライアントなどの、ＩＰベースのネットワークへの加入者とすることができる。ＵＥ３は、ＳＩＰ即時メッセージを複数の受信者（ユーザ６、７、８）に送信することができる。線４１で示すように、ＵＥ３は、ＳＩＰメッセージを使用してメッセージをＩＭＳ４に送信することができる。ＳＩＰメッセージのコンテンツは（ＧＭＳ）ＳＭとして処理される。線４２で示すように、ＩＭＳ４は、ネットワーク４０内のさらに先の複数の受信者宛てのＳＭを保持するＳＩＰメッセージを、例えば本発明の態様を実施するＳＭＳノード１に送信することができる。ＩＭＳ４とＳＭＳノード１との間の送信（線４２）は、ＵＥ３とＩＭＳ４との間の送信とは別の（ＳＭＰＰ、ＳＭＳＩＰなどの）プロトコルを通じて行うことができる。しかしながら、ユーザ６、７、及び８に配信すべき複数のＳＭを、依然としてＳＭネットワーク４０内で単一のＩＰベースのメッセージ内に保持することができる。また、ＳＭＳノード１は、これらの全てのＳＭ配信に関する課金要求を単一の課金要求の形で課金システムＯＣＳ２又はＯＦＣＳ２ａに送信することもできる。線４４で示すように、ＳＭＳノード１は、依然として受信者６、７、８宛てのＳＭを単一のメッセージの形で送信することができる。この場合も、ＳＭを伝達するためにインターフェイス４４で使用するプロトコルは、インターフェイス４１及び４２で使用した（単複の）プロトコルと異なるものであってもよい。ＳＭＳノード１は、ＳＭを配信する要求を、例えばＩＰ−ＳＭ−ＧＷ５に送信することができ、最終的にこのＩＰ−ＳＭ−ＧＷ５が、例えばＭＡＰを使用してこのＳＭ要求を複数のＳＭに変換し、これらを線４５で示すようにユーザ６、７、及び８へ１つずつ送信する。ＳＭＳノード１が、ＳＭ要求を複数のＳＭに変換して、これらをユーザ６、７、及び８へ１つずつ送信することもできる。

図５は、本発明のある実施形態による処理例を示している。この処理は、例えばＳＭＳノードにより行うことができる。ステップ５１において、ＳＭを配信するための１又はそれ以上の要求を受信する。ＳＭを複数の受信者に配信するための１つの要求を受信し、この結果最終的にこれらの受信者に複数のＳＭを配信することもでき、或いは各々がＳＭを単一の受信者に配信するためのいくつかの要求を受信し、これらを再びまとめて複数の受信者に複数のＳＭを配信することもでき、或いはこれらの両方を混ぜ合わせることもできる。線５６は、ＳＭ要求を受信した後に、同じユーザからさらなるＳＭ要求を受信するかどうかをしばらく待機できることを示している。ステップ５２において、複数のＳＭ配信要求が同じ発信ユーザ（送信者）に関するものであることが検出される。ステップ５３において、同じユーザを出どころとする個々の（又は少なくとも２以上の）ＳＭに関する情報を単一の課金要求に組み合わせる。この情報は、ＭＳＩＳＤＮ又はＩＭＳＩなどの受信者識別情報とすることができる。ステップ５４において、課金要求が課金システムに送信され、ステップ５５において、（単複の）ＳＭ要求を処理するステップが受信者のために継続される。ステップ５４及び５５は、異なる順序で行うことができる。

図６は、本発明のある実施形態による処理例を示している。この処理は、例えば課金ノード（ＯＣＳ／ＯＦＣＳ）により行うことができる。ステップ６１において、単一の発信ユーザ（ＳＭ送信者）に関連する課金要求を、例えばＳＭＳノードから受信する。課金要求は、配信すべき２以上のＳＭに関する情報を含んでいる。ステップ６２において、課金要求のＡＶＰから、配信すべき個々のＳＭの受信者情報（ＭＳＩＳＤＮ、ＩＭＳＩ）を抽出する。ステップ６３において、ショートメッセージの数を考慮して、単一の送信者３を出どころとするショートメッセージを配信するための価格を定めることができる。この価格は、例えば個々のショートメッセージごとに定めることができ、或いは全てのショートメッセージを配信するための合計価格を計算することもできる。

本発明の実施形態における受信者及び宛先は、各個々のＳＭの受信者／宛先であると解釈することができ、すなわち、例えば同じ単一のエンドユーザ（受信者／宛先）に２つのＳＭを配信すべき場合、ＳＭＳノード及びＳＭ配信の点から見れば、このエンドユーザは２人の異なる受信者である。換言すれば、同じ単一のユーザを出どころとする２つのＳＭを同じ単一のユーザ／受信者／宛先に配信すべき場合、この同じ単一のユーザ／受信者／宛先の識別情報が、対応する課金システムに送信される課金メッセージのＡＶＰに２回含まれる。例えば、２つのＳＭを配信すべきことを課金機能に対して明確にするためにこれを行うことができる。

本発明の実施形態では、ユーザの視点から見れば、ショートメッセージ（ＳＭ）をＧＳＭショートメッセージと見なすことができる。しかしながら、ネットワーク内では、ＳＭを他のプロトコルで、伝統的にはＭＡＰで伝達することができるが、ＳＭを配信するための要求も、例えばＳＩＰ、ＳＭＳＩＰ、ＳＭＰＰ、又はＵＣＰなどのその他のプロトコルで伝達することができる。これらのプロトコルは、ＳＭを複数の受信者に配信するための要求の送信をサポートすることができるが、伝統的な（ＭＡＰを含む）ＧＳＭ ＳＭは常に１対１のみのＳＭである。これらのその他のプロトコルは、（ＧＳＭ）ＳＭの配信を要求するために使用されると考えることができる。ＳＭＳノードは、ＳＭを配信するための要求を、例えばＵＥ、ＳＭＳＣ、ＩＰ−ＳＭ ＧＷ、ＭＳＣ、ＳＭＳルータなどから受信することができる。

本発明の態様では、ＳＭＳノードは（ＧＳＭ）ＳＭを受信しないが、例えばＳＩＰメッセージを受信することができる。この場合、ＳＭＳノードは、ＳＩＰメッセージがＳＭを配信するための要求を含むこと、及びＳＩＰメッセージを配信のために複数のＧＳＭ ＳＭに変換すべきであることを認識する。この変換は、ＳＭＳノードにおいて、又は後程ネットワーク内の他の場所で行うことができるが、変換をネットワーク内の他の場所で行ったとしても、ＳＭＳノードは、このような変換が必要であり、従って問題の（単複の）要求が例えばＳＩＰに符号化されていたとしても、これがＳＭを配信するための（単複の）要求であることを検出することができる。

本発明の態様では、ＳＩＰメッセージは、後でＧＳＭ ＳＭとして配信すべきメッセージ（ＳＭ）を含むことができるので、たとえＳＩＰメッセージを受信したとしても、複数のＳＭを配信すべきことがＳＭＳノードにより検出されるということは、ＳＭＳノードがＧＳＭ ＳＭを配信するための要求を検出できることを意味する。したがって、課金システムへのＳＭＳ報告を送信することができる。

本発明の態様では、ＳＭＳオンライン課金及びＳＭＳオフライン課金のためのＤｉａｍｅｔｅｒアプリケーションに複数のＳＭ受信者を組み込むことができる。本発明の態様では、課金要求を、例えばユニット引き落とし要求、ユニット予約要求、又はＤｉａｍｅｔｅｒプロトコルの課金データ要求、或いはその他のタイプの課金関連要求とすることができる。

ここで、本発明のさらなる実施形態について説明する。現在の標準仕様には、１つの移動体発信（ＭＯ）ショートメッセージを複数の宛先に配信するメカニズムについての記載はない。現在では、移動体ユーザがＳＭを複数の宛先へ送りたいと望む場合、ＵＥが宛先（受信者）ごとに１つの複数のＭＯメッセージを生成する。いわゆる加入者ごとの配信リストを管理する別個のアプリケーションを実装してＳＭＳＣに接続することにより、複数宛先ＳＭＳを実現することができる。この配信リストアプリケーションへＭＯ ＳＭを送信した後に、配信リストアプリケーションは、そのローカルデータベース（又は同様のもの）から、ＳＭを誰に送信すべきかを参照することができる。配信リストに関する全ての提供データを管理することは、ほとんどのエンドユーザにとって自明ではない。

本発明のある実施形態では、ＧＳＭネットワーク内のショートメッセージサービス（ＳＭＳ）を拡張して、ＵＥが、無線インターフェイスを介してユーザデータコンテンツを複数回送信することなく、またネットワーク内の配信リストを管理することなく、ＳＭを複数の宛先（受信者）に提出できるようにする。本発明のこの実施形態では、新たなユーザデータヘッダ（ＵＤＨ）情報要素を使用する。この情報要素をユーザデータヘッダ内で符号化して、あらゆる追加の宛先をＳＭＳＣへ転送することができる。ＳＭＳＣは追加の宛先を分離して、これらの宛先の各々にＳＭを配信することができる。ＳＭＳＣはまた、追加の宛先を保持するヘッダ要素を切り離すこともでき、及び／又は必要に応じてショートメッセージを再連結こともできる。

電話クライアントは、配信リストの概念を有することができるが、ＵＥは、宛先ごとに１つの複数のＭＯ ＳＭを依然として提出することができる。本発明の１つの態様では、クライアントが、より高性能な複数宛先処理に切り替えることができる。この場合、全ての追加の宛先アドレスを新たな情報要素Ｉｄ（ＩＥＩ）などの新たな情報要素に符号化してユーザデータヘッダに組み込むことができる。ユーザデータの残りの部分は、通常のＳＭ処理に従って満たすことができ、合計長が単一のＳＭに関して定義された最大長を超える場合にはメッセージを連結することができる。ＳＭを受信する場合、ＳＭＳＣが新たな情報要素ＩＤをチェックすることができる。ユーザデータに組み込まれた情報要素内に追加の宛先が見つかった場合、ＳＭＳＣは、移動体終了（ＭＴ）メッセージの複製を宛先ごとに１つ作成することができる。追加の宛先アドレスから全てのＭＴメッセージを切り離すことができ、また追加の宛先を含む全ての余分なＩＥＩを削除することによりユーザデータ長が短縮されるので、これらのＭＴメッセージを必要に応じて再構築及び再分解することができる。

ＳＭＳＣは、例えば、宛先ごとに提出ログを作成したり、及び／又は場合によっては使用する宛先アドレスの数に従って特別な料率を設定したりなどの、課金に関連する特定のロジックを実行することができる。このロジックを使用して、複数宛先の提出に関する通信事業者のビジネスロジックをサポートすることができる。

最適化された配信リスト機能が存在しないことにより、ニュースの配信又はその他の配信はサービスプロバイダ又は取るに足らない使用に限定され続けてきた。本発明のこの実施形態をＳＭＳに対して実現することにより、通信事業者は、１対多のメッセージングのためのベアラとしてＳＭＳの使用を推進することができる。ユーザは、自身の配信リストを自ら管理することができ、通信事業者はＳＭＳＣにおいて何も提供する必要がない。ＳＭＳクライアント又は統合メッセージングクライアントのＵＥに更新を提供することにより、この機能をエンドユーザにとって非常に使い勝手の良いものにすることができる。エンドユーザは、ＭＭＳ及び電子メールにより既に複数宛先メッセージングのことを知っているので、ＳＭＳに複数宛先メッセージングのためのサポートを追加することにより、通信事業者が、収益をもたらす安定したＳＭＳベアラに基づいて商売を続ける役に立つことができる。また、全てのベアラが複数の宛先メッセージング機能をサポートしていなければ、クライアントは、メッセージがテキストしか含んでいなくてもＭＭＳに切り替える必要があり得るため、全てのベアラが複数の宛先メッセージング機能をサポートする場合、統合メッセージングクライアントの導入をよりスムーズにすることもできる。エンドユーザにとっては、この機能により、例えば送信者がフットボールチームのメンバ、学校のクラスのメンバなどの人々のグループに１０〜３０通のＳＭを一斉に提出したいと望む場合、現在では端末に依存して恐らくは手動で個別に行われている「同報通信」メッセージの配信を安価かつ高速で行えるようになる。１つのＭＯメッセージを送信することにより使用する無線インターフェイス及びＳＳ７シグナリングリソースは、複数のＭＯ ＳＭを個々の宛先に１つずつ別個に送信することと比較した場合に少なくて済むので、サービスプロバイダはこの機能をより安価に提供することができる。

この機能は、ＵＥクライアントの実施構成及びＳＭＳＣの両方の変更を必要とする場合がある。１対多の分解を別個の外部アプリケーションによって処理させることにより、ＳＭＳＣによるこの機能の採用を促進することができる。ＵＥを、別のＳＭＳＣアドレス（又はプロトコル識別子（ＰＩＤ））を使用してこのアプリケーションをサポートするＳＭＳＣに経路を強制するように構成することができる。

ＳＭのユーザデータヘッダは、異なる要素を含むことができる。これらの要素のいくつかは、サービスセンター（ＳＣ）固有のものであってもよい。本発明の態様を実現するために、これらの要素は、移動体加入者国際総合サービスデジタルネットワーク（ＩＳＤＮ）番号（ＭＳＩＳＤＮ）を含むことができる。本発明のこの実施形態に従ってユーザデータヘッダ情報要素ＩＤを標準化することにより、ＳＭＳＣと、このバージョンのＳＭＳ標準をサポートするハンドセットとの間の相互運用を可能にすることができる。

本発明のこの実施形態は、移動体端末のユーザがショートメッセージ（ＳＭ）の少なくとも１人の追加の受信者を選択できるようにする、ユーザデータヘッダ（ＵＤＨ）を含むショートメッセージ（ＳＭ）を提出するためのメッセージングクライアントと、この少なくとも１人の追加の受信者の少なくとも１つのアドレスをショートメッセージ（ＳＭ）のユーザデータヘッダ（ＵＤＨ）内で符号化するためのエンコーダとを備えた移動体端末を提供することにより実現することができる。ユーザが少なくとも１人の追加の受信者を選択するステップは、配信リストを選択するステップを含むことができる。ショートメッセージ（ＳＭ）を送信するための送信者を導入することができる。

さらに、本発明の実施形態は、ユーザがショートメッセージ（ＳＭ）の少なくとも１人の追加の受信者を選択できるようにし、この少なくとも１人の追加の受信者の少なくとも１つのアドレスをショートメッセージ（ＳＭ）のユーザデータヘッダ（ＵＤＨ）内で符号化するためのエンコーダを備えた、ユーザデータヘッダ（ＵＤＨ）を含むショートメッセージ（ＳＭ）を提出するためのメッセージングクライアントを提供することにより実現することもできる。ユーザが少なくとも１人の追加の受信者を選択するステップは、配信リストを選択するステップを含むことができる。

さらに、本発明の実施形態は、ショートメッセージ（ＳＭ）を受信するための受信機と、追加の宛先を含む情報要素がユーザデータヘッダ（ＵＤＨ）内で見つかるかどうかをチェックするためのチェッカと、移動体終了（ＭＴ）メッセージの複製を宛先ごとに１つ作成するための作成器とを備えたショートメッセージサービスセンター（ＳＭＳＣ）を提供することにより実現することもできる。また、ＳＭＳＣは、
− 移動体終了（ＭＴ）メッセージの追加の宛先アドレスを切り離すための切り離し器、及び／又は、
− ユーザデータヘッダを再構築及び／又は再分解するための再構築器、及び／又は、
− 宛先アドレスの数に従って特別な料率を設定するための料率ユニット、
のうちの１又はそれ以上を備えることができる。

上述した課金機能及びＳＭＳノードの機能は、コード手段によりソフトウェアとして実装することができ、またコンピュータのメモリにロードすることができる。

４０ ＳＭＳシステム
４１〜４５ メッセージ送信

Claims (33)

1. 単一のユーザを出どころとし複数の受信者に向けた複数のショートメッセージ（ＳＭ）を配信するための少なくとも１つの要求を検出するための検出手段と、
   前記複数のショートメッセージの前記複数の受信者に関する情報をシグナリングメッセージに組み合わせるための組み合わせ手段と、
   前記シグナリングメッセージを課金機能に送信するための送信手段と、
   を備えることを特徴とするショートメッセージサービス（ＳＭＳ）エンティティ。
2. 前記送信手段が、前記シグナリングメッセージをＤｉａｍｅｔｅｒプロトコルベースのインターフェイスを介して送信するように構成される、
   ことを特徴とする請求項１に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
3. 前記送信手段が、前記シグナリングメッセージをオンライン課金システム（ＯＣＳ）及び／又はオフライン課金システム（ＯＦＣＳ）に送信するように構成され、及び／又は前記課金要求が、ユニット引き落とし要求、ユニット予約要求、又は課金データ要求のうちの１つを含む、
   ことを特徴とする請求項１又は請求項２に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
4. 前記送信手段が、前記シグナリングメッセージを、第３世代パートナーシッププロジェクト（３ＧＰＰ）のＲｏ及び／又はＲｆインターフェイスを介して送信するように構成される、
   ことを特徴とする請求項１から請求項３のいずれかに記載のショートメッセージサービス（ＳＭＳ）エンティティ。
5. 前記受信者に関する前記情報が、前記複数のショートメッセージの前記受信者の識別情報を含み、前記組み合わせ手段が、前記複数のショートメッセージの前記受信者の前記識別情報を属性値ペア（ＡＶＰ）に含めるように構成される、
   ことを特徴とする請求項１から請求項４のいずれかに記載のショートメッセージサービス（ＳＭＳ）エンティティ。
6. 前記受信者の前記識別情報を含めるステップが、個々のショートメッセージの前記受信者の前記識別情報を別個の属性値ペア（ＡＶＰ）に含めて、該属性値ペア（ＡＶＰ）が、受信者に配信すべきショートメッセージごとに１回前記シグナリングメッセージに組み込まれるようにするステップを含む、
   ことを特徴とする請求項５に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
7. 前記属性値ペア（ＡＶＰ）が、［受信者アドレス］属性値ペア（ＡＶＰ）を含む、
   ことを特徴とする請求項５又は請求項６に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
8. 前記受信者の前記識別情報を含む前記属性値ペア（ＡＶＰ）を、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）に組み込むための手段をさらに備え、前記組み込みステップが、
   前記受信者の前記識別情報を含む個々の属性値ペア（ＡＶＰ）を、前記受信者を示すための別個のさらなる属性値ペア（ＡＶＰ）に組み込むステップ、又は、
   前記受信者の前記識別情報を含む全ての前記属性値ペア（ＡＶＰ）を、前記受信者を示すための単一のさらなる属性値ペア（ＡＶＰ）に組み込むステップ、又は、
   上記の選択肢の両方の混合、
   のうちの少なくとも１つを含むことを特徴とする請求項６又は請求項７に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
9. 前記組み込むための手段が、前記受信者を示すための前記少なくとも１つのさらなる属性値ペア（ＡＶＰ）を、［ＳＭＳ情報］属性値ペア（ＡＶＰ）に組み込むように構成される、
   ことを特徴とする請求項８に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
10. ショートメッセージサービスルータ（ＳＭＳルータ）、インターネットプロトコル−ショートメッセージサービスゲートウェイ（ＩＰ−ＳＭ−ＧＷ）、及びショートメッセージサービスセンター（ＳＭＳＣ）のうちの少なくとも１つを備える、
    ことを特徴とする請求項１から請求項９のいずれかに記載のショートメッセージサービス（ＳＭＳ）エンティティ。
11. 前記複数のショートメッセージ（ＳＭ）を配信するための前記少なくとも１つの要求を受信するための手段と、
    前記複数のショートメッセージを通信システム内のさらに先へ中継するための手段と、をさらに備え、前記中継ステップが、
    前記少なくとも１つの配信要求を、該少なくとも１つの配信要求が受信手段により受信されたときのものと同じプロトコルに従って中継するステップ、又は、
    前記少なくとも１つの配信要求を、該少なくとも１つの要求を前記複数のショートメッセージを伝達するための別のプロトコルに変換した後に中継するステップ、
    を含むことを特徴とする請求項１から請求項１０のいずれかに記載のショートメッセージサービス（ＳＭＳ）エンティティ。
12. 前記少なくとも１つの要求のうちの最初の要求を受信した後に、前記単一のユーザを出どころとする、ショートメッセージを配信するためのさらなる要求を受信するかどうかをチェックするために所定の時間待機するための手段をさらに備え、前記さらなる要求を受信した場合、前記組み合わせ手段が、受信者に関する前記情報を前記シグナリングメッセージに組み合わせるように構成される、
    ことを特徴とする請求項１０又は請求項１１に記載のショートメッセージサービス（ＳＭＳ）エンティティ。
13. 単一のユーザを出どころとし複数の受信者に向けた複数のショートメッセージを配信することに関し、前記複数のショートメッセージの前記複数の受信者に関する情報を含む課金要求を受信するための手段を備える、
    ことを特徴とする課金エンティティ。
14. 前記課金要求がＤｉａｍｅｔｅｒプロトコルに従う要求を含み、前記課金エンティティが、個々のショートメッセージ配信の受信者の、各々が別個の［受信者アドレス］属性値ペア（ＡＶＰ）に組み込まれた識別情報を、前記受信した要求内で抽出するための手段を備える、
    ことを特徴とする請求項１３に記載の課金エンティティ。
15. 前記抽出ステップが、前記受信者の前記識別情報を含む前記属性値ペア（ＡＶＰ）を、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）から抽出するステップをさらに含む、
    ことを特徴とする請求項１４に記載の課金エンティティ。
16. 前記抽出ステップが、前記受信者を示すための前記少なくとも１つのさらなる属性値ペア（ＡＶＰ）を［ＳＭＳ情報］属性値ペア（ＡＶＰ）から抽出するステップをさらに含む、
    ことを特徴とする請求項１５に記載の課金エンティティ。
17. 前記単一のユーザを出どころとする前記複数のショートメッセージを配信するための価格を定めるための価格決定手段をさらに備え、ショートメッセージの数を考慮して、ショートメッセージごとの価格又は全ての前記ショートメッセージを配信するための合計価格が定められる、
    ことを特徴とする請求項１３から請求項１６のいずれかに記載の課金エンティティ。
18. 前記課金要求が、ユニット引き落とし要求、ユニット予約要求、又は課金データ要求のうちの１つを含む、
    ことを特徴とする請求項１３から請求項１７のいずれかに記載の課金エンティティ。
19. 単一のユーザを出どころとし複数の受信者に向けた複数のショートメッセージ（ＳＭ）を配信するための少なくとも１つの要求を検出するステップと、
    前記複数のショートメッセージの前記複数の受信者に関する情報をシグナリングメッセージに組み合わせるステップと、
    前記シグナリングメッセージを課金機能に送信するステップと、
    を含むことを特徴とするショートメッセージ課金方法。
20. 前記受信者に関する前記情報が、前記複数のショートメッセージの前記受信者の識別情報を含み、前記組み合わせステップが、前記複数のショートメッセージの前記受信者の前記識別情報を属性値ペア（ＡＶＰ）に含めるステップを含む、
    ことを特徴とする請求項１９に記載の方法。
21. 前記受信者の前記識別情報を含めるステップが、個々のショートメッセージの前記受信者の前記識別情報を別個の属性値ペア（ＡＶＰ）に含めて、前記属性値ペア（ＡＶＰ）が、受信者に配信すべきショートメッセージごとに１回前記シグナリングメッセージに組み込まれるようにするステップを含む、
    ことを特徴とする請求項２０に記載の方法。
22. 前記属性値ペア（ＡＶＰ）が、［受信者アドレス］属性値ペア（ＡＶＰ）を含む、
    ことを特徴とする請求項２１に記載の方法。
23. 前記受信者の前記識別情報を含む前記属性値ペア（ＡＶＰ）を、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）に組み込むステップをさらに含み、該組み込みステップが、
    前記受信者の前記識別情報を含む個々の属性値ペア（ＡＶＰ）を、前記受信者を示すための別個のさらなる属性値ペア（ＡＶＰ）に組み込むステップ、又は、
    前記受信者の前記識別情報を含む全ての前記属性値ペア（ＡＶＰ）を、前記受信者を示すための単一のさらなる属性値ペア（ＡＶＰ）に組み込むステップ、又は、
    上記の選択肢の両方の混合、
    のうちの少なくとも１つを含むことを特徴とする請求項２１又は請求項２２に記載の方法。
24. 前記組み込みステップが、前記受信者を示すための前記少なくとも１つのさらなる属性値ペア（ＡＶＰ）を［ＳＭＳ情報］属性値ペア（ＡＶＰ）に組み込むステップを含む、
    ことを特徴とする請求項２３に記載の方法。
25. 前記複数のショートメッセージを通信システム内のさらに先へ中継するステップをさらに含み、該中継ステップが、
    前記少なくとも１つの配信要求を、該少なくとも１つの配信要求が受信手段により受信されたときのものと同じプロトコルに従って中継するステップ、又は、
    前記少なくとも１つの配信要求を、該少なくとも１つの要求を前記複数のショートメッセージを伝達するための別のプロトコルに変換した後に中継するステップ、
    を含むことを特徴とする請求項１９から請求項２４のいずれかに記載の方法。
26. 前記少なくとも１つの要求のうちの最初の要求を受信した後に、前記単一のユーザを出どころとする、ショートメッセージを配信するためのさらなる要求を受信するかどうかをチェックするために所定の時間待機するステップをさらに含み、前記さらなる要求を受信した場合、前記組み合わせステップが、受信者に関する前記情報を前記シグナリングメッセージに組み合わせるステップを含む、
    ことを特徴とする請求項１９から請求項２５のいずれかに記載の方法。
27. 単一のユーザを出どころとし複数の受信者に向けた複数のショートメッセージを配信することに関し、前記複数のショートメッセージの前記複数の受信者に関する情報を含む課金要求を受信するステップを含む、
    ことを特徴とするショートメッセージ課金方法。
28. 前記課金要求がＤｉａｍｅｔｅｒプロトコルに従う要求を含み、前記方法が、個々のショートメッセージ配信の受信者の、各々が別個の［受信者アドレス］属性値ペア（ＡＶＰ）に組み込まれた識別情報を、前記受信した要求内で抽出するステップを含む、
    ことを特徴とする請求項２７に記載の方法。
29. 前記抽出ステップが、前記受信者の前記識別情報を含む前記属性値ペア（ＡＶＰ）を、受信者を示すための少なくとも１つのさらなる属性値ペア（ＡＶＰ）から抽出するステップをさらに含む、
    ことを特徴とする請求項２８に記載の方法。
30. 前記抽出ステップが、前記受信者を示すための前記少なくとも１つのさらなる属性値ペア（ＡＶＰ）を［ＳＭＳ情報］属性値ペア（ＡＶＰ）から抽出するステップをさらに含む、
    ことを特徴とする請求項２８に記載の方法。
31. 前記単一のユーザを出どころとする前記複数のショートメッセージを配信するための価格を定めるステップをさらに含み、ショートメッセージの数を考慮して、ショートメッセージごとの価格又は全ての前記ショートメッセージを配信するための合計価格が定められる、
    ことを特徴とする請求項２７から請求項３０のいずれかに記載の方法。
32. コンピュータのメモリにロードされたときに、請求項１９から請求項３１のいずれか１項に記載のステップを引き起こすようにされたコード手段を備える、
    ことを特徴とするコンピュータプログラム。
33. 請求項１３から請求項１８のいずれかに記載の課金機能と、請求項１から請求項１２のいずれかに記載のショートメッセージサービス（ＳＭＳ）エンティティとを備える、
    ことを特徴とする通信システム。

Images