JP5666020B2 - パケット交換ネットワークを介してアプリケーション発信テキスト・メッセージを配送するための方法および装置 - Google Patents

Description

本発明は、通信の分野に関し、詳細には、アプリケーション発信（ＡＯ：ａｐｐｌｉｃａｔｉｏｎ−ｏｒｉｇｉｎａｔｅｄ）テキスト・メッセージを配送するために使用されるシグナリング・メッセージを相互に関連付けることに関する。

テキスト・メッセージングは、多くのモバイル（またはワイヤレス）ネットワークにおいて、人気の通信モードになっている。テキスト・メッセージングの一例は、ショート・メッセージ・サービス（ＳＭＳ）であり、ＳＭＳは、デバイス間でショート・テキスト・メッセージ（すなわち１６０文字以下）の交換を可能にする、１組の通信プロトコルである。「テキスト・メッセージ」という用語は、従来はＳＭＳを使用して送信されるテキストのみのメッセージを指していたが、画像、動画、音声コンテンツなどのマルチメディア・メッセージを含むように拡張されている。マルチメディア・メッセージは、マルチメディア・メッセージ・サービス（ＭＭＳ）プロトコルを使用して送信することができる。多くの場合、モバイル・ユーザは、通信を行うために、音声通話よりもテキスト・メッセージングを頻繁に使用する。

テキスト・メッセージングは、従来、２人のエンド・ユーザがモバイル・デバイスを用いてテキスト・メッセージを交換するものと考えられていたが、エンド・ユーザとメッセージを交換する自動アプリケーション（すなわち生身の人間ではない）が存在することがある。一例として、外部ショート・メッセージング・エンティティ（ＥＳＭＥ）は、テキスト・メッセージ（例えばＳＭＳ）を送信および／または受信できるアプリケーションを含む、デバイス／サーバである。ＥＳＭＥは、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコル、ユニバーサル・コンピュータ・プロトコル（ＵＣＰ）、ＲＥＳＴｆｕｌ、ＨＴＴＰ、Ｐａｒｌａｙなどのプロトコルを使用して、固定接続を介してネットワークに接続する。ＥＳＭＥの典型的な例は、自動マーケティング・メッセージをモバイル・デバイスに送信するサーバ、テキスト・メッセージを介して投票を処理する投票システムなどである。

テキスト・メッセージを送信するため、アプリケーションは、そのプロトコルのシグナリング・メッセージ内にテキスト・メッセージをカプセル化する。プロトコルは、独自仕様とすることができ、またはＳＭＰＰなど業界内で一般的に使用されるプロトコルとすることができる。アプリケーションによってこのようにして発信されるテキスト・メッセージを、本明細書では、アプリケーション発信（ＡＯ）テキスト・メッセージと呼ぶ。ＡＯテキスト・メッセージが、ＩＰマルチメディア・サブシステム（ＩＭＳ）またはロング・ターム・エボリューション（ＬＴＥ）ネットワークなどの、セッション開始プロトコル（ＳＩＰ）ベースのネットワークに送信される場合、ＡＯテキスト・メッセージは、ゲートウェイを通過する。これは、アプリケーションがＳＩＰインタフェースを有していないことを仮定している。ゲートウェイは、テキスト・メッセージを、アプリケーションによって使用されるシグナリング・プロトコルからＳＩＰ要求（例えば、ＳＩＰ ＭＥＳＳＡＧＥ）に変換し、ＳＩＰ要求を、ＳＩＰベースのネットワークを介して、（受信者と呼ばれる）宛先に転送する。

３ＧＰＰ技術仕様書（ＴＳ）２４．３４１などの、第３世代パートナシップ・プロジェクト（３ＧＰＰおよび３ＧＰＰ２）の技術仕様書において、テキスト・メッセージを、ＳＩＰを使用し、パケット交換ネットワークを介して、どのように交換するかが定義された。これらの仕様の一環として、テキスト・メッセージが受信者に配送された場合、受信者のデバイスは、テキスト・メッセージの配送成功／失敗を報告する返信を行うために、新しいＳＩＰトランザクションを開始する。したがって、受信者のデバイスは、テキスト・メッセージの配送成功／失敗を知らせる新しいＳＩＰ要求をゲートウェイに返信する。

残念ながら、ここで問題となるのが、ＡＯ ＭＴテキスト・メッセージのための複数のＳＩＰトランザクションを効率的に相互に関連付けることである。

３ＧＰＰ技術仕様書（ＴＳ）２４．３４１

本明細書で説明する実施形態は、相互関連ＩＤ（ｃｏｒｒｅｌａｔｉｏｎ ＩＤ）を使用して複数のＳＩＰトランザクションを相互に関連付けることを可能にする。ゲートウェイがアプリケーションによって開始されたテキスト・メッセージを受信した場合、ゲートウェイは、相互関連ＩＤを識別し、相互関連ＩＤをアプリケーションに送信する。ゲートウェイは、テキスト・メッセージを受信者にトランスポートするために使用されるＳＩＰ要求内にも、相互関連ＩＤを埋め込む。受信者のデバイス（ユーザ機器）は、ＳＩＰ要求を受信し、テキスト・メッセージの配送成功／失敗を報告するために、新しいＳＩＰ要求（新しいＳＩＰトランザクション）を開始する。受信者のデバイスは、新しいＳＩＰ要求内に、テキスト・メッセージの配送成功／失敗の通知とともに、相互関連ＩＤを埋め込む。ゲートウェイは、新しいＳＩＰ要求を受信した場合、相互関連ＩＤを探し、相互関連ＩＤに基づいて、新しいＳＩＰ要求を、先行するＳＩＰ要求および元の配送要求と関連付ける。新しいＳＩＰ要求とアプリケーションからの元の配送要求とを相互に関連付けることによって、ゲートウェイは、相互関連ＩＤとテキスト・メッセージについての配送報告とを含む配送応答を、アプリケーションに送信することができる。アプリケーションは、相互関連ＩＤに基づいて、テキスト・メッセージのための最初の配送要求と、テキスト・メッセージの配送報告を有する配送応答とを相互に関連付けることができる。したがって、相互関連ＩＤは、有利なことに、ゲートウェイが、複数のＳＩＰトランザクションを相互に関連付けることを可能にする。相互関連ＩＤは、アプリケーションが、配送要求と配送応答とを相互に関連付けることも可能にして、アプリケーションが、テキスト・メッセージの配送ステータスについて分かるようにする。

一実施形態は、テキスト・メッセージ・アプリケーションと、ＳＩＰを使用するパケット交換ネットワークとの間で、通信を連係（ｉｎｔｅｒｗｏｒｋ）させるテキスト・メッセージ・ゲートウェイを備える。動作中、テキスト・メッセージ・ゲートウェイは、テキスト・メッセージ・アプリケーションから、パケット交換ネットワークによってサービスされているユーザ機器（ＵＥ）を宛先とするアプリケーション発信（ＡＯ）テキスト・メッセージを含む第１の配送要求を受信する。テキスト・メッセージ・ゲートウェイは、ＡＯテキスト・メッセージのための相互関連識別子（ＩＤ）を識別し、相互関連ＩＤを配送応答に挿入し、配送応答をテキスト・メッセージ・アプリケーションに送信する。その後、テキスト・メッセージ・アプリケーションは、相互関連ＩＤを後の使用に備えて保存することができる。テキスト・メッセージ・ゲートウェイは、第１の配送要求を、ＡＯテキスト・メッセージをカプセル化した第１のＳＩＰ要求に変換し、相互関連ＩＤを第１のＳＩＰ要求に挿入し、第１のＳＩＰ要求をＵＥに送信する。

別の実施形態では、テキスト・メッセージ・ゲートウェイは、ＵＥから、ＡＯテキスト・メッセージについての配送報告を含む第２のＳＩＰ要求（例えば、別のＳＩＰ ＭＥＳＳＡＧＥ）を受信し、相互関連ＩＤを識別するために第２のＳＩＰ要求を解析し、相互関連ＩＤに基づいて、第２のＳＩＰ要求と、第１のＳＩＰ要求および第１の配送要求とを相互に関連付ける。その後、テキスト・メッセージ・システムは、ＡＯテキスト・メッセージについての配送報告を第２の配送要求に挿入し、相互関連ＩＤを第２の配送要求に挿入し、第２の配送要求をテキスト・メッセージ・アプリケーションに送信する。テキスト・メッセージ・アプリケーションは、配送報告と、ＡＯテキスト・メッセージをＵＥに送信するために最初に使用された第１の配送要求とを相互に関連付けることができる。したがって、ゲートウェイは、ＡＯテキスト・メッセージの配送ステータスを効果的な方法でテキスト・メッセージ・アプリケーションに提供することができ、その結果、アプリケーションは、テキスト・メッセージが受信者によって正常に受信されたかどうかを判定することができる。

別の実施形態では、テキスト・メッセージ・アプリケーションによって使用されるシグナリング・プロトコルは、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコルを含む。したがって、第１の配送要求は、ＳＭＰＰ ｓｕｂｍｉｔ＿ｓｍメッセージを含むことができ、第２の配送要求は、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージを含むことができる。テキスト・メッセージ・ゲートウェイは、相互関連ＩＤを、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージのｒｅｃｃｉｐｔｅｄ＿ｍｅｓｓａｇｅ＿ｉｄフィールドに挿入することができる。

別の実施形態では、テキスト・メッセージ・ゲートウェイは、相互関連ＩＤを、第１のＳＩＰ要求のモバイル・アプリケーション・パート（ＭＡＰ：Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）ＲＰ−メッセージ参照フィールドに挿入することができ、テキスト・メッセージ・ゲートウェイのゲートウェイＩＤを、相互関連ＩＤとともに、ＭＡＰ ＲＰ−メッセージ参照フィールドに挿入することができる。

別の実施形態は、テキスト・メッセージ・アプリケーションとＳＩＰを使用するパケット交換ネットワークとの間で、通信を連係させる方法を含む。方法は、テキスト・メッセージ・アプリケーションから、パケット交換ネットワークによってサービスされているユーザ機器（ＵＥ）を宛先とするアプリケーション発信（ＡＯ）テキスト・メッセージを含む第１の配送要求を受信するステップを含む。方法は、相互関連識別子（ＩＤ）を識別するステップと、相互関連ＩＤを配送応答に挿入するステップと、配送応答をテキスト・メッセージ・アプリケーションに送信するステップとをさらに含む。方法は、第１の配送要求を、ＡＯテキスト・メッセージをカプセル化した第１のＳＩＰ要求に変換するステップと、相互関連ＩＤを第１のＳＩＰ要求に挿入するステップと、第１のＳＩＰ要求をＵＥに送信するステップとをさらに含む。

別の実施形態では、方法は、ＵＥから、ＡＯテキスト・メッセージについての配送報告を含む第２のＳＩＰ要求を受信するステップと、相互関連ＩＤを識別するために第２のＳＩＰ要求を解析するステップと、相互関連ＩＤに基づいて、第２のＳＩＰ要求と、第１のＳＩＰ要求および第１の配送要求とを相互に関連付けるステップとをさらに含む。

別の実施形態では、方法は、配送報告を第２の配送要求に挿入するステップと、相互関連ＩＤを第２の配送要求に挿入するステップと、第２の配送要求をテキスト・メッセージ・アプリケーションに送信するステップであって、それによって、テキスト・メッセージ・アプリケーションが、配送報告と、ＡＯテキスト・メッセージを送信するために最初に使用された第１の配送要求とを相互に関連付けることができるようにする、ステップとをさらに含む。

別の実施形態では、テキスト・メッセージ・アプリケーションによって使用されるシグナリング・プロトコルは、ＳＭＰＰプロトコルを含む。したがって、第１の配送要求は、ＳＭＰＰ ｓｕｂｍｉｔ＿ｓｍメッセージを含むことができ、第２の配送要求は、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージを含むことができる。相互関連ＩＤを第２の配送要求に挿入するステップは、相互関連ＩＤを、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージのｒｅｃｃｉｐｔｅｄ＿ｍｅｓｓａｇｅ＿ｉｄフィールドに挿入するステップを含む。

別の実施形態では、方法は、相互関連ＩＤを、第１のＳＩＰ要求のモバイル・アプリケーション・パート（ＭＡＰ）ＲＰ−メッセージ参照フィールドに挿入するステップと、テキスト・メッセージ・ゲートウェイのゲートウェイＩＤを、相互関連ＩＤとともに、ＭＡＰ ＲＰ−メッセージ参照フィールドに挿入するステップとをさらに含む。

他の例示的な実施形態は、以下で説明されることがある。

本発明のいくつかの実施形態を、添付の図面を参照しながら、もっぱら例として、今から説明する。すべての図面において、同じ参照番号は、同じ要素または同じタイプの要素を表す。

例示的な一実施形態における、通信システムを示す図である。 例示的な一実施形態における、ＡＯテキスト・メッセージを処理する方法を示すフローチャートである。 例示的な一実施形態における、ユーザ機器（ＵＥ）においてＡＯテキスト・メッセージを処理する方法を示すフローチャートである。 例示的な一実施形態における、ＡＯテキスト・メッセージを処理するための図２の方法の追加ステップを示すフローチャートである。 別の例示的な実施形態における、通信システムを示す図である。 例示的な一実施形態における、成功したＳＭＳメッセージの配送を示すメッセージ図である。

図および以下の説明は、本発明の特定の例示的な実施形態について説明している。したがって、本明細書では明示的に説明されても、または示されてもいないが、本発明の原理を具体化し、本発明の範囲内に含まれる様々な構成を、当業者が考案できることが理解されよう。さらに、本明細書で説明される例はいずれも、本発明の原理を理解する助けとなることを意図したものであり、そのような具体的に述べられた例および条件に限定されるものではないと解釈すべきである。結果として、本発明は、以下で説明される特定の実施形態または例に限定されず、特許請求の範囲およびその均等物によって限定される。

図１は、例示的な一実施形態における、通信システム１００を示している。通信システム１００は、パケット交換ネットワーク１２０に結合された１つまたは複数の外部メッセージ・センタ１１０を含む。システム１００は、テキスト・メッセージを、外部メッセージ・センタ１１０から、パケット交換ネットワーク１２０によってサービスされるユーザ機器（ＵＥ）１４０にトランスポートすることができる。外部メッセージ・センタ１１０からパケット交換ネットワーク１２０を介してＵＥ１４０に送信されるテキスト・メッセージは、モバイル着信（ＭＴ：Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｅｄ）テキスト・メッセージと呼ばれる。

外部メッセージ・センタ１１０は、テキスト・メッセージを生成し、テキスト・メッセージをＵＥ１４０に配送するためにパケット交換ネットワーク１２０に送信することができる、任意のシステム、サーバ、またはデバイスを含む。外部メッセージ・センタ１１０の一例は、ＥＳＭＥである。ＥＳＭＥの典型的な例は、自動マーケティング・メッセージをモバイル・ユーザに送信するシステム、テキスト・メッセージ投票を処理する投票システムなどである。この実施形態では、外部メッセージ・センタ１１０は、テキスト・メッセージを生成し、テキスト・メッセージのパケット交換ネットワーク１２０への送信を開始する、テキスト・メッセージ・アプリケーション１１２を含む。

パケット交換ネットワーク１２０は、ＩＰパケットなどのパケットを使用して通信を交換する、任意のネットワークを含む。パケット交換ネットワーク１２０は、ＩＭＳネットワーク、ＬＴＥネットワーク、または他の任意のＩＰベースのネットワークを含むことができる。パケット交換ネットワーク１２０は、音声および／またはデータサービスをＵＥ１４０に提供するために、ネットワーク要素１２２などの様々な要素を含むことができる。ネットワーク要素１２２のいくつかの例は、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ：Ｓｅｒｖｉｎｇ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）、ＰＤＮゲートウェイ（Ｐ−ＧＷ）などを含む。

通信システム１００は、テキスト・メッセージ・ゲートウェイ１３０も含む。テキスト・メッセージ・ゲートウェイ１３０は、外部メッセージ・センタ１１０とＵＥ１４０および／またはパケット交換ネットワーク１２０内のネットワーク要素１２２との間で、通信を連係させる、任意のシステム、サーバ、またはデバイスを含む。外部メッセージ・センタ１１０内のアプリケーション１１２は、パケット交換ネットワーク１２０におけるメッセージ配送用に使用される、ＳＩＰなどの、プロトコルをサポートしないことがある。したがって、テキスト・メッセージ・ゲートウェイ１３０は、アプリケーション１１２および他の様々なアプリケーションが、Ｐａｒｌａｙ、ＲＥＳＴｆｕｌ、ＬＤＡＰ、ＸＭＬ、およびＳＭＰＰなどの異なるプロトコル（例えばＡＰＩ）で、テキスト・メッセージをパケット交換ネットワーク１２０に送信することを可能にする。例えば、アプリケーション１１２は、ＵＥ１４０を宛先とするテキスト・メッセージを送信する場合、ＲＥＳＴｆｕｌ ＡＰＩを使用して、テキスト・メッセージを送信することができる。テキスト・メッセージ・ゲートウェイ１３０は、ＲＥＳＴｆｕｌプロトコル・メッセージを正規化し、それをＳＩＰ要求に変換することができる。その後、テキスト・メッセージ・ゲートウェイ１３０は、元のテキスト・メッセージを配送するために、ＳＩＰ要求をパケット交換ネットワーク１２０を介してＵＥ１４０に送信することができる。テキスト・メッセージ・ゲートウェイ１３０のいくつかの例は、ＩＭＳネットワーク内のＩＰ−ＳＭ−ＧＷ、またはＬＴＥネットワーク内のＬＴＥ ＳＭＳゲートウェイを含む。

テキスト・メッセージ・ゲートウェイ１３０は、（図１に示されるように）パケット交換ネットワーク１２０の部分とすることができ、またはパケット交換ネットワーク１２０に送信されるメッセージを連係させるために、パケット交換ネットワーク１２０に結合することができる。また、通信システム１００は、より高いトラフィック負荷を処理するため、地理的冗長性（ｇｅｏ−ｒｅｄｕｎｄａｎｃｙ）のためなどに、複数のテキスト・メッセージ・ゲートウェイ１３０を有することもできる。したがって、図１に示されるようなテキスト・メッセージ・ゲートウェイ１３０は、単一のゲートウェイ、またはゲートウェイのクラスタ（例えば、ゲートウェイＡ、ゲートウェイＢ、ゲートウェイＣなど）を表すことができる。

テキスト・メッセージ・ゲートウェイ１３０は、ネットワーク・インタフェース１３２と、制御システム１３４とを含む。ネットワーク・インタフェース１３２は、様々なプロトコルを用いて、外部メッセージ・センタ１１０および他のメッセージ・センタと通信する、任意のデバイスまたはコンポーネントを含む。ネットワーク・インタフェース１３２は、パケット交換ネットワーク１２０内で使用される、ＳＩＰなどのプロトコルを用いて、パケット交換ネットワーク１２０の１つまたは複数の要素１２２と通信することもできる。制御システム１３４は、外部メッセージ・センタ１１０とＵＥ１４０との間で、メッセージを相互に関連付ける、任意のデバイスまたはコンポーネントを含む。

以下の実施形態では、アプリケーション１１２は、ＵＥ１４０を宛先とするテキスト・メッセージを発信する場合、連係のためにテキスト・メッセージをゲートウェイ１３０に送信する。このテキスト・メッセージは、アプリケーション発信（ＡＯ）テキスト・メッセージと呼ばれる。その後、ゲートウェイ１３０は、テキスト・メッセージをＳＩＰ要求に収めて、ＵＥ１４０に送信する。背景として、ＳＩＰ要求または「メソッド」と呼ばれる、ＳＩＰ内で定義された１組のコマンドが存在する。そのようなＳＩＰ要求の１つは、インスタント・メッセージ（ＩＭ）、テキスト・メッセージなどをトランスポートするために使用される、ＳＩＰ ＭＥＳＳＡＧＥである。ＳＩＰは、ＳＩＰ応答と呼ばれる１組のコマンドも定義する。ＳＩＰ応答は、特定のＳＩＰ要求に応答するために使用される。いくつかの共通するＳＩＰ応答は、１ｘｘ、２ｘｘ、３ｘｘ、４ｘｘ、５ｘｘ、および６ｘｘである。

現状では、（テキスト・メッセージをカプセル化した）ＳＩＰ要求がデバイスに送信される場合、受信デバイスは、テキスト・メッセージの配送報告（テキスト・メッセージング肯定応答またはエラー）をＳＩＰ応答に収めて提供しない。受信デバイスは、ＳＩＰ要求自体が受信された旨のＳＩＰ応答（肯定応答）を、ＳＩＰ ２００ ＯＫなどで提供する。しかし、このＳＩＰ応答は、ＳＩＰ要求内のテキスト・メッセージが受信者に正しく配送されたかどうかは示しておらず、ＳＩＰ要求の配送ステータスを示すだけである。ＳＩＰ要求は正しく受信されても、ＳＩＰ要求内のテキスト・メッセージではエラーが発生する、本説明の範囲を超える、様々な理由が存在し得る。３ＧＰＰ仕様では、受信デバイスは、配送ステータスを報告する別個のＳＩＰ要求を送信することによって、テキスト・メッセージの配送報告を提供するための新しいＳＩＰトランザクションを開始する。

本明細書で説明する実施形態は、ＡＯテキスト・メッセージを処理する場合に、ゲートウェイ１３０において複数のＳＩＰトランザクションを相互に関連付けることを可能にする。相互関連付けは、相互関連ＩＤを使用することで可能になり、それについては、図２〜図４においてさらに説明する。

図２は、例示的な一実施形態において、ＡＯテキスト・メッセージを処理する方法２００を示すフローチャートである。方法２００のステップは、図１のテキスト・メッセージ・ゲートウェイ１３０を参照して説明されるが、方法２００が他のネットワークおよびシステムでも実行できることを当業者は理解されよう。本明細書で説明されるフローチャートのステップは、すべてを含むわけではなく、示されていない他のステップを含むことができる。ステップは、代替の順序でも実行することができる。

ステップ２０２において、ネットワーク・インタフェース１３２は、ＡＯテキスト・メッセージを、外部メッセージ・センタ１１０のアプリケーション１１２から受信する。テキスト・メッセージは、おそらくは、Ｐａｒｌａｙ、ＲＥＳＴｆｕｌ、ＬＤＡＰ、ＸＭＬ、またはＳＭＰＰなど、ＳＩＰ以外のプロトコルの配送要求にカプセル化されている。ＳＭＰＰにおける配送要求の一例は、ｓｕｂｍｉｔ＿ｓｍ要求である。アプリケーション１１２は、テキスト・メッセージについての配送受信または配送肯定応答を要求する／必要とすることがあり、これについては、以下でさらに説明する。

ステップ２０４において、制御システム１３４は、テキスト・メッセージのための相互関連識別子（ＩＤ）を識別する。相互関連ＩＤは、テキスト・メッセージの配送に係わるメッセージを相互に関連付けるための、テキスト・メッセージに対して定義された、任意の文字列、整数、または値を含む。制御システム１３４は、テキスト・メッセージの受信に応答して、新しい一意なＩＤを生成することができる。代替として、制御システム１３４は、配送要求内でアプリケーション１１２からテキスト・メッセージとともに受け取ったメッセージＩＤを再使用することができる。

ステップ２０６において、制御システム１３４は、適切なプロトコルで配送応答を生成し、相互関連ＩＤを配送応答に挿入する。例えば、配送要求がＳＭＰＰ ｓｕｂｍｉｔ＿ｓｍ要求である場合、制御システム１３４は、配送応答としてｓｕｂｍｉｔ＿ｒｅｓｐ応答を生成することができる。ステップ２０８において、ネットワーク・インタフェース１３２は、配送応答を、外部メッセージ・センタ１１０のアプリケーション１１２に送信する。その後、アプリケーション１１２は、相互関連ＩＤを識別するために配送応答を解析し、後の使用に備えて相互関連ＩＤを保存することができる。

ステップ２１０において、制御システム１３４は、テキスト・メッセージがＳＩＰ要求にカプセル化される、または埋め込まれるように、配送要求をＳＩＰに変換し、または連係させる。ＳＩＰ要求は、テキスト・メッセージ（例えばＳＭＳメッセージ）をトランスポートする、ＳＩＰ ＭＥＳＳＡＧＥまたは別のタイプのＳＩＰ要求を含むことができる。制御システム１３４は、テキスト・メッセージを、ＳＩＰ要求のＭＡＰ ＲＰ−ＤＡＴＡフィールドに埋め込むことができる。ステップ２１２において、制御システム１３４は、相互関連ＩＤもＳＩＰ要求に挿入し、または埋め込む。例えば、制御システム１３４は、相互関連ＩＤを、ＳＩＰ要求のＭＡＰ ＲＰ−メッセージ参照フィールドに挿入することができる。制御システム１３４は、ゲートウェイ１３０のゲートウェイＩＤを識別し、ゲートウェイＩＤを、相互関連ＩＤとともに、ＳＩＰ要求に挿入する、または埋め込むこともできる。ゲートウェイＩＤは、ゲートウェイ１３０などのテキスト・メッセージ・ゲートウェイを一意に参照する、任意の文字列、整数、または値を含む。パケット交換ネットワーク１２０は、テキスト・メッセージを変換するため、またはアプリケーション１１２からＵＥ１４０に連係させるために使用されるゲートウェイを、冗長性および負荷平衡のために複数有することができる。ゲートウェイＩＤは、ＳＩＰ要求が異なるゲートウェイに到着した場合に、ＳＩＰ要求を相互に関連付けるために利用される。

ステップ２１４において、ネットワーク・インタフェース１３２は、ＳＩＰ要求をＵＥ１４０に配送するためにネットワーク要素１２２に送信する。ＳＩＰ要求を受信すると、ネットワーク要素１２２は、ＳＩＰ要求をＵＥ１４０に配送しようと試みる。

図３は、例示的な一実施形態における、ＵＥにおいてＡＯテキスト・メッセージを処理する方法３００を示すフローチャートである。方法３００のステップは、図１のシステム１００を参照して説明されるが、方法３００が他のネットワーク、システム、およびデバイスでも実行できることを当業者は理解されよう。

ステップ３０２において、ＵＥ１４０は、ＳＩＰ要求をネットワーク要素１２２から受信し、ＳＩＰ要求は、テキスト・メッセージをカプセル化している。ＵＥ１４０は、ＳＩＰ要求の正常受信を知らせるＳＩＰ ２００ ＯＫを、（ネットワーク要素１２２を介して）ゲートウェイ１３０に送信する。ステップ３０４において、ＵＥ１４０は、カプセル化されたテキスト・メッセージについての処理ステータスを決定して、テキスト・メッセージの（肯定応答またはエラー報告フォーマットをとる）配送報告を生成する。テキスト・メッセージの配送報告は、テキスト・メッセージを搬送したＳＩＰ要求の配送についてのステータス（これは２００ ＯＫ、またはＳＩＰ ３ｘｘ、４ｘｘ、５ｘｘ応答を用いて行われる）とは別である。配送報告は、（ＲＰ−ＤＡＴＡなど）テキスト・メッセージの処理の成功または失敗を示す任意の情報を含む。テキスト・メッセージの配送報告を決定するために使用されるプロセスは、本出願の範囲を超えている。しかし、一例では、ＵＥ１４０は、アドレッシング・エラー、フォーマッティング・エラー、または他の任意のタイプのエラーが生じたかどうかを判定するために、テキスト・メッセージのデータを解析することができる。テキスト・メッセージの解析中に、１つまたは複数のエラーが検出された場合、ＵＥ１４０は、テキスト・メッセージの配送が失敗したと判定することができる。テキスト・メッセージの解析中に、エラーが検出されなかった場合、ＵＥ１４０は、テキスト・メッセージの配送が成功したと判定することができる。

ステップ３０６において、ＵＥ１４０は、相互関連ＩＤを識別するために、元のＳＩＰ要求を解析する。ＵＥ１４０は、相互関連ＩＤを見つけるために、ＭＡＰ ＲＰ−メッセージ参照フィールドを解析することができる。その後、ＵＥ１４０は、テキスト・メッセージの配送ステータスを報告するための新しいＳＩＰ要求を生成し、相互関連ＩＤを新しいＳＩＰ要求に挿入する（ステップ３０８および３１０を参照）。新しいＳＩＰ要求は、やはり、テキスト・メッセージ（例えばＳＭＳメッセージ）をトランスポートする、ＳＩＰ ＭＥＳＳＡＧＥまたは別のタイプのＳＩＰ要求を含むことができる。相互関連ＩＤを新しいＳＩＰ要求に挿入するために、ＵＥ１４０は、元のＳＩＰ要求のＭＡＰ ＲＰ−メッセージ参照フィールドを、新しいＳＩＰ要求のＭＡＰ ＲＰ−メッセージ参照フィールドにコピーすることができる。ステップ３１２において、ＵＥ１４０は、テキスト・メッセージの配送報告を新しいＳＩＰ要求に挿入する。例えば、ＵＥ１４０は、新しいＳＩＰ要求において、ＭＡＰ ＲＰ−メッセージ・タイプを、ＲＰ−ＡＣＫまたはＲＰ−ＥＲＲＯＲに設定することができる。ステップ３１４において、ＵＥ１４０は、新しいＳＩＰ要求をネットワーク要素１２２を介してゲートウェイ１３０に送信する。

図４は、例示的な一実施形態における、ＡＯテキスト・メッセージを処理する方法２００の追加ステップを示すフローチャートである。ステップ２１６において、ゲートウェイ１３０のネットワーク・インタフェース１３２（図１を参照）は、ＵＥ１４０によって送信された新しいＳＩＰ要求を受信する。新しいＳＩＰ要求の受信に応答して、ゲートウェイ１３０は、新しいＳＩＰ要求の正常受信を知らせるＳＩＰ ２００ ＯＫを、（ネットワーク要素１２２を介して）ＵＥ１４０に送信する。ステップ２１８において、制御システム１３４は、相互関連ＩＤを識別するために、新しいＳＩＰ要求を解析する。制御システム１３４は、相互関連ＩＤを見つけるために、ＭＡＰ ＲＰ−メッセージ参照フィールドを解析することができる。その後、ステップ２２０において、制御システム１３４は、相互関連ＩＤに基づいて、（テキスト・メッセージをトランスポートした）元のＳＩＰ要求と、（テキスト・メッセージについての配送報告をトランスポートした）新しいＳＩＰ要求とを相互に関連付ける。

制御システム１３４は、２つのＳＩＰ要求と、アプリケーション１１２からの元の配送要求とを相互に関連付けることもできる。相互関連ＩＤに基づいて、ＳＩＰ要求と、アプリケーション１１２からの元の配送要求とを相互に関連付けることによって、制御システム１３４は、アプリケーション１１２に、テキスト・メッセージについての配送報告を提供することができる。そうするために、ステップ２２２において、制御システム１３４は、テキスト・メッセージについての配送報告を、新しい配送要求に挿入する。ＳＭＰＰにおける配送要求の一例は、ｄｅｌｉｖｅｒ＿ｓｍ要求である。ステップ２２４において、制御システム１３４は、相互関連ＩＤを新しい配送要求に挿入する。その後、ステップ２２６において、ネットワーク・インタフェース１３２は、新しい配送要求をアプリケーション１１２に送信する。

したがって、アプリケーション１１２は、相互関連ＩＤに基づいて、テキスト・メッセージのための元の配送要求と、新しい配送要求とを相互に関連付けることができる。したがって、アプリケーション１１２は、新しい配送要求内の配送報告と、元の配送要求内のＡＯテキスト・メッセージとを相互に関連付け、テキスト・メッセージが受信者に正常に配送されたかどうかを判定することができる。相互関連ＩＤは、有利なことに、テキスト・メッセージの配送ステータスを報告する際に、ゲートウェイ１３０が、複数のＳＩＰトランザクションを相互に関連付けることを可能にする。アプリケーション１１２とＵＥ１４０の間でテキスト・メッセージおよび配送報告をトランスポートするために使用される要求のすべてには、共通する相互関連ＩＤが埋め込まれるので、相互関連ＩＤは、ゲートウェイ１３０が、配送報告をアプリケーション１１２に返送することも可能にする。結果として、ＡＯ ＭＴテキスト・メッセージについての配送報告／受信を効果的に提供することができる。

実施例
図５は、別の例示的な実施形態における、通信システム５００を示している。通信システム５００は、複数のワイヤレス通信ネットワークを含み、それらは、この実施形態では、ＣＤＭＡネットワーク５１０、ＩＭＳネットワーク５２０、およびＬＴＥネットワーク５３０として示されている。以下で説明する実施形態は、ＳＩＰメッセージを使用する、ＳＭＳメッセージのＵＥ（例えばモバイル・デバイス）５５０への配送を説明する。

ＣＤＭＡネットワーク５１０は、ホーム・ロケーション・レジスタ（ＨＬＲ）５１２と、モバイル・スイッチング・センタ（ＭＳＣ）５１４と、パケット・データ・ネットワーク・ゲートウェイ（ＰＤＮ−ＧＷ）５１６とを含む。ＨＬＲ５１２は、ＣＤＭＡネットワーク５１０の使用を認可されたＵＥの加入情報および他の詳細（例えば加入者プロファイル）を記憶する、中央加入者データベースである。ＭＳＣ５１４は、ＵＥのためのサービング・ノードであり、ＣＤＭＡネットワーク５１０において音声通話、ＳＭＳ、および他のサービスを処理することを担当する。ＰＤＮ−ＧＷ５１６は、ＣＤＭＡネットワーク５１０とＩＭＳネットワーク５２０などのパケット交換ネットワークとの間でシグナリングを連係させる、ＣＤＭＡネットワーク５１０における任意のノードまたは要素を含む。ＣＤＭＡネットワーク５１０は、基地局、無線ネットワーク・コントローラなど、簡潔にするために示されていない、他のネットワーク要素を含むことができる。

ＩＭＳネットワーク５２０は、プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）５２２と、サービング呼セッション制御機能（Ｓ−ＣＳＣＦ）５２４と、ホーム加入者サーバ（ＨＳＳ）５２６と、パケット・ゲートウェイ（Ｐ−ＧＷ）５２８とを含む。Ｐ−ＣＳＣＦ５２２は、ＩＭＳドメインへのエントリ・ポイントであり、ＩＭＳデバイス用の発信プロキシ・サーバとして機能する。Ｓ−ＣＳＣＦ５２４は、シグナリング・プレーン（ｓｉｇｎａｌｉｎｇ ｐｌａｎｅ）の中央ノードであり、ＩＭＳネットワーク５２０を介してセッションを開始するＩＭＳデバイスのためのセッション制御を実行する。Ｓ−ＣＳＣＦ５２４は、図５には示されていない１つまたは複数のアクセス・ネットワークを介してＩＭＳデバイスと通信する。ＨＳＳ５２６は、加入関連情報（例えば加入者プロファイル）を記憶し、エンド・ユーザの認証および認可を実行し、加入者のロケーションについての情報などを提供する、加入者サーバである。Ｐ−ＧＷ５２８は、外部ネットワークとパケットを交換する、ＩＭＳネットワーク５２０における任意のノードまたは要素を含む。

この実施形態では、ＬＴＥネットワーク５３０の要素は、簡潔にするために示されていない。

通信システム５００はまた、ＳＭＳセンタ（ＳＭＳＣ）５４２と、１つまたは複数のショート・メッセージ・ゲートウェイ（ＳＭ−ＧＷ）５４４〜５４５を含み、ＳＭ−ＧＷ５４４〜５４５は、ＬＴＥゲートウェイ、ＩＰショート・メッセージ・ゲートウェイ（ＩＰ−ＳＭ−ＧＷ）、またはＩＰ上でＳＭＳを処理する他の何らかのゲートウェイを含むことができる。ＳＭＳＣ５４２は、ストア・アンド・フォワード（ｓｔｏｒｅ−ａｎｄ−ｆｏｒｗａｒｄ）処理を使用してＳＭＳメッセージを配送する、回線交換ネットワークのための任意のノードを含む。ＳＭ−ＧＷ５４４〜５４５は、ＳＩＰベースのネットワークと、異なるシグナリング・プロトコルを使用するネットワークまたはデバイスとの間で、シグナリングを連係させる、任意のノードを含む。例えば、ネットワークまたはデバイスが、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコルを使用して、ＳＭＳメッセージを交換する場合、ＳＭ−ＧＷ５４４〜５４５は、ＳＭＰＰプロトコル・メッセージのＳＩＰへの連係またはＳＩＰからの連係を行う。通信システム５００は、外部ショート・メッセージ・エンティティ（ＥＳＭＥ）５４６および５４８も含む。ＥＳＭＥは、ＳＭＳメッセージの送信および／または受信に従事するＳＭＳＣ５４２またはＳＭ−ＧＷ５４４〜５４５に接続する外部アプリケーションである。

この実施形態では、ＥＳＭＥ５４８が、ＵＥ５５０を宛先とするＳＭＳメッセージを生成すると仮定する。以下の実施形態では、ＳＩＰ応答において配送ステータスがどのように提供されるかについて説明する。

図６は、例示的な一実施形態における、成功したＳＭＳメッセージの配送を示すメッセージ図である。参考として、この実施形態では、図１のテキスト・メッセージ・ゲートウェイは、ＳＭ−ＧＷ５４４および５４５において実施される。ＥＳＭＥ５４８は、ＵＥ５５０宛てのＳＭＳメッセージを生成した後、ＳＭＰＰプロトコルのｓｕｂｍｉｔ＿ｓｍ要求をフォーマットし、ＳＭＳメッセージをｓｕｂｍｉｔ＿ｓｍ要求にカプセル化する。ＳＭＰＰプロトコルのｓｕｂｍｉｔ＿ｓｍ要求は、ＥＳＭＥ５４８からの配送要求を表す。ここでの１つの仮定は、ＥＳＭＥ５４８がＳＭＰＰプロトコルに対応していることである。対応していない場合は、ＥＳＭＥ５４８とＳＭ−ＧＷ５４４〜５４５との間で、ＳＭＰＰゲートウェイを実施することができる。その後、ＥＳＭＥ５４８は、ｓｕｂｍｉｔ＿ｓｍ要求をＳＭ−ＧＷ５４４に送信する。

ｓｕｂｍｉｔ＿ｓｍ要求に応答して、ＳＭ−ＧＷ５４４は、ＳＭＳメッセージのための相互関連ＩＤを識別する。ＳＭ−ＧＷ５４４は、ｓｕｂｍｉｔ＿ｓｍ要求の受信に応答して、新しい一意なＩＤを生成することができる。代替として、ＳＭ−ＧＷ５４４は、ＥＳＭＥ５４８からのｓｕｂｍｉｔ＿ｓｍ要求内で受け取ったメッセージＩＤを再使用することができる。その後、ＳＭ−ＧＷ５４４は、ｓｕｂｍｉｔ＿ｒｅｓｐ応答を生成し、相互関連ＩＤをｓｕｂｍｉｔ＿ｒｅｓｐ応答に挿入する。その後、ＳＭ−ＧＷ５４４は、相互関連ＩＤ（ＣＯＲＲ ＩＤ）を含むｓｕｂｍｉｔ＿ｒｅｓｐ応答を、ＥＳＭＥ５４８に送信する。ＥＳＭＥ５４８は、ｓｕｂｍｉｔ＿ｒｅｓｐ応答を解析し、相互関連ＩＤを後の使用に備えて保存する。

次に、ＳＭ−ＧＷ５４４は、ダイアメータ・ユーザ・データ要求（ＵＤＲ：Ｕｓｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔ）を使用して、ＵＥ５５０の登録ステータスをＨＳＳ５２６に問い合わせる。ＨＳＳ５２６は、ＵＥ５５０が登録されていると判定し、ＵＥ５５０が登録されていることを示すダイアメータ・ユーザ・データ応答（ＵＤＡ：Ｕｓｅｒ Ｄａｔａ Ａｎｓｗｅｒ）を用いて、ＳＭ−ＧＷ５４４に応答する。その後、ＳＭ−ＧＷ５４４は、ＳＭＳメッセージをカプセル化したＳＩＰ ＭＥＳＳＡＧＥを構成する。ＳＭＳメッセージは、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＤＡＴＡ（例えば、ＲＰ−ＵＳＥＲ ＤＡＴＡフィールド）内に埋め込まれる。ＳＭ−ＧＷ５４４は、相互関連ＩＤおよびＳＭ−ＧＷ５４４のゲートウェイＩＤもＳＩＰ ＭＥＳＳＡＧＥ内に埋め込む。例えば、ＳＭ−ＧＷ５４４は、相互関連ＩＤおよびゲートウェイＩＤを組み合わせ文字列として、ＳＩＰ ＭＥＳＳＡＧＥにカプセル化されたＲＰ−ＤＡＴＡ（例えば、ＲＰ−メッセージ参照フィールド）内に埋め込むことができる。ＳＩＰ ＭＥＳＳＡＧＥヘッダは、以下のように構成することができる。

MESSAGE tel:+19305020103 SIP/2.0
Via: SIP/2.0/UDP 135.1.62.120:5060;branch=z9hG4b
To: tel:+19305020103
From: tel:+19305020106;tag=1 (ESME Address-long code)
Call-ID: 689e5af4451c0170@livemas1
Max-Forwards: 70
CSeq: 1 MESSAGE
Route: LTE GW SIP URI
P-Charging-Vector=icid-value=“PCSF:192.161.1.xxx-xxxxxxxx”
Content-Type: application/vnd.3gpp.sms
Content-Length: xx (Length of Relay Layer Message)
<<Encapsulated RP-DATA(SMS-DELIVER)>>

ＳＩＰ ＭＥＳＳＡＧＥの場合のＲＰ−ＤＡＴＡは、以下のフォーマットをとる。

その後、ＳＭ−ＧＷ５４４は、ＳＩＰメッセージを、ＩＭＳネットワーク５２０内のＳ−ＣＳＣＦ５２４に送信する。今度は、Ｓ−ＣＳＣＦ５２４が、ＳＩＰ ＭＥＳＳＡＧＥをＵＥ５５０に回送し、ＵＥ５５０は、ＳＩＰ ＭＥＳＳＡＧＥを正常に受信する。したがって、ＵＥ５５０は、ＳＩＰ ＭＥＳＳＡＧＥの正常受信を知らせるＳＩＰ ２００ ＯＫを、Ｓ−ＣＳＣＦ５２４に送信する。Ｓ−ＣＳＣＦ５２４は、ＳＩＰ ２００ ＯＫをＳＭ−ＧＷ５４４に転送する。

ＵＥ５５０はまた、ＳＭＳメッセージが正常に配送されたかどうかかを判定するために、ＳＩＰ ＭＥＳＳＡＧＥ内のＳＭＳメッセージ（ＲＰ−ＤＡＴＡ）を解析しようと試みる。この実施形態では、ＳＭＳが正常に配送されたと仮定する。ＵＥ５５０は、結果的に、ＳＭＳメッセージの配送が成功したと判定し、以下のようにして、配送成功をＳＭ−ＧＷ５４４に通知する。ＵＥ５５０は、新しいＳＩＰトランザクションのための新しいＳＩＰ ＭＥＳＳＡＧＥを生成し、相互関連ＩＤおよびゲートウェイＩＤを、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＡＣＫ（ＲＰ−メッセージ参照フィールド）内に埋め込む。原則的に、ＵＥ５５０は、ＲＰ−メッセージ参照フィールドを、受信したＳＩＰメッセージから新しいＳＩＰメッセージにコピーする。ＵＥ５５０は、配送報告も新しいＳＩＰ ＭＥＳＳＡＧＥに挿入する。その後、ＵＥ５５０は、新しいＳＩＰ ＭＥＳＳＡＧＥをＳ−ＣＳＣＦ５２４に送信する。新しいＳＩＰ ＭＥＳＳＡＧＥは、以下のようになり得る。

MESSAGE tel:+19305020103 SIP/2.0
Via: SIP/2.0/UDP 135.1.30.70:5080;branch=z9hG4bK287482662-1402101
Max-Forwards: 70
From: <sip:+19305020106@verizon.net; user=phone; lr>;tag=pctUA_287482662
To: LTE GW SIP URI
Call-ID: 287482662-1402079
CSeq: I MESSAGE
Route: LTE GW SIP URI
P-Asserted-Identity: <sip:+19305020106@somedomain.com>
P-Asserted-Identity: <tel:+19305020106>
Content-Type: application/vnd.3gpp.sms
Content-Length: xx (Length of Relay Layer Message)
<<Encapsulated RP-ACK(SMS-DELIVER-REPORT Message)>>

新しいＳＩＰ ＭＥＳＳＡＧＥの場合のＲＰ−ＤＡＴＡは、以下のフォーマットをとる。

Ｓ−ＣＳＣＦ５２４は、新しいＳＩＰメッセージからＶＩＰアドレスを解決し、ＳＩＰ ＭＥＳＳＡＧＥをＳＭ−ＧＷ５４５に回送し、ＳＭ−ＧＷ５４５は、新しいＳＩＰメッセージを正常に受信する。したがって、ＳＭ−ＧＷ５４５は、新しいＳＩＰメッセージの正常受信を知らせるＳＩＰ ２００ ＯＫを、Ｓ−ＣＳＣＦ５２４に送信する。Ｓ−ＣＳＣＦ５２４は、ＳＩＰ ２００ ＯＫをＵＥ５５０に転送する。

新しいＳＩＰ ＭＥＳＳＡＧＥを受信した後、ＳＭ−ＧＷ５４５は、相互関連ＩＤを識別するために、ＳＩＰ ＭＥＳＳＡＧＥ内のＲＰ−ＡＣＫ、およびＲＰ−メッセージ参照フィールドを解析する。ＳＭ−ＧＷ５４５は、ＳＭ−ＧＷ５４４のためのゲートウェイＩＤに基づいて、先のＲＰ−ＤＡＴＡメッセージがＳＭ−ＧＷ５４４によって送信されたことを発見する。したがって、ＳＭ−ＧＷ５４５は、新しいＳＩＰ要求と、ＥＳＭＥ５４８からの元のＳＩＰ要求および元のＳＭＰＰ要求とを相互に関連付ける。ＳＭＳメッセージのためのすべてのペイロード・データは完備しているので、ＳＭ−ＧＷ５４５は、相互関連ＩＤおよび配送報告を含むＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍ要求を、ＥＳＭＥ５４８に送信する。ＳＭ−ＧＷ５４５は、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍ要求内のｒｅｃｅｉｐｔｅｄ＿ｍｅｓｓａｇｅ＿ｉｄが相互関連ＩＤになるように設定する。ＳＭ−ＧＷ５４５はまた、ＳＭ−ＧＷ５４４にトランザクションについて通知する。ＳＭ−ＧＷ５４４は、トランザクション・データをデータベース内に保存する。

ＥＳＭＥ５４８は、ＳＭ−ＧＷ５４５からｄｅｌｉｖｅｒ＿ｓｍ要求を受信する。この要求は、２つのＳＩＰ ＭＥＳＳＡＧＥが異なるＳＩＰトランザクションであったのと同様に、別個のＳＭＰＰトランザクションである。しかし、ＥＳＭＥ５４８は、相互関連ＩＤに基づいて、ｄｅｌｉｖｅｒ＿ｓｍ要求とｓｕｂｍｉｔ＿ｓｍ要求とを相互に関連付けることができる。したがって、ＳＭ−ＧＷ５４５は、ｄｅｌｉｖｅｒ＿ｓｍ要求に挿入されるステータス情報に基づいて、ＳＭＳメッセージのための配送報告を識別することができる。したがって、ＥＳＭＥ５４８は、有利なことに、配送ステータス情報と、送信されたＳＭＳメッセージとを相互に関連付けることができる。ＳＭ−ＧＷ５４４が、ＳＭＰＰからのＳＭＳメッセージをＳＩＰに変換した場合でも、ＥＳＭＥ５４８は、ＳＭＳメッセージのための配送ステータス情報を受信することができる。

図に示された、または本明細書で説明された様々な要素はいずれも、ハードウェア、ソフトウェア、ファームウェア、またはこれらの何らかの組み合わせとして実施することができる。例えば、ある要素は、専用ハードウェアとして実施することができる。専用ハードウェア要素は、「プロセッサ」、「コントローラ」と呼ばれることがあり、または何らかの類似の用語で呼ばれることがある。機能は、プロセッサによって提供される場合、単一の専用プロセッサによって、単一の共用プロセッサによって、またはいくつかは共用されてもよい複数の個別プロセッサによって提供することができる。さらに、「プロセッサ」または「コントローラ」という用語が明示的に使用されていても、それが、ソフトウェアを実行可能なハードウェアを排他的に指しているとは解釈すべきでなく、限定することなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ）もしくは他の回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、ソフトウェアを記憶するためのリード・オンリ・メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、不揮発性ストレージ、ロジック、または他の何らかの物理的ハードウェア・コンポーネントもしくはモジュールを暗黙的に含むことができる。

また、ある要素は、プロセッサまたはコンピュータによって実行可能な命令として実施することができ、プロセッサまたはコンピュータが、その要素の機能を実行する。命令のいくつかの例は、ソフトウェア、プログラム・コード、およびファームウェアである。命令は、プロセッサによって実行されたときに、プロセッサに指令を出して、要素の機能を実行させるように働く。命令は、プロセッサによって読み取り可能な記憶デバイスに記憶することができる。記憶デバイスのいくつかの例は、デジタルもしくはソリッド・ステート・メモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハード・ドライブ、または光学的に読み取り可能なデジタル・データ記憶媒体である。

本明細書では特定の実施形態について説明したが、本発明の範囲は、それらの特定の実施形態に限定されない。本発明の範囲は、以下の特許請求の範囲およびその任意の均等物によって確定される。

Claims (10)

1. テキスト・メッセージ・アプリケーションとセッション開始プロトコル（ＳＩＰ）を使用するパケット交換ネットワークとの間で、通信を連係させるように構成されたテキスト・メッセージ・ゲートウェイを備え、
   該テキスト・メッセージ・ゲートウェイが、該テキスト・メッセージ・アプリケーションから、該パケット交換ネットワークによってサービスされているユーザ機器（ＵＥ）を宛先とするアプリケーション発信（ＡＯ）テキスト・メッセージを含む第１の配送要求を受信し、該ＡＯテキスト・メッセージを一意に参照する相互関連識別子（ＩＤ）を生成し、該ＡＯテキスト・メッセージを一意に参照する該相互関連識別子（ＩＤ）を、配送応答に挿入し、該配送応答を該テキスト・メッセージ・アプリケーションに送信するようにさらに構成され、
   該テキスト・メッセージ・ゲートウェイが、該第１の配送要求を、該ＡＯテキスト・メッセージをカプセル化した第１のＳＩＰ要求に変換し、該ＡＯテキスト・メッセージを一意に参照する該相互関連識別子（ＩＤ）を、該第１のＳＩＰ要求に挿入し、該第１のＳＩＰ要求を該ＵＥに送信するようにさらに構成される、システム。
   
2. 請求項１に記載のシステムにおいて、
   該テキスト・メッセージ・ゲートウェイが、該ＵＥから、該ＡＯテキスト・メッセージについての配送報告を含む第２のＳＩＰ要求を受信し、該相互関連ＩＤを識別するために該第２のＳＩＰ要求を解析し、該相互関連ＩＤに基づいて、該第２のＳＩＰ要求と、該第１のＳＩＰ要求及び該第１の配送要求の少なくとも一方とを相互に関連付けるようにさらに構成される、システム。
   
3. 請求項２に記載のシステムにおいて、
   該テキスト・メッセージ・ゲートウェイが、該配送報告を第２の配送要求に挿入し、該相互関連ＩＤを該第２の配送要求に挿入し、該第２の配送要求を該テキスト・メッセージ・アプリケーションに送信するようにさらに構成され、それによって、該テキスト・メッセージ・アプリケーションが、該配送報告と、該ＡＯテキスト・メッセージを送信するために最初に使用された該第１の配送要求とを相互に関連付けることができるようにする、システム。
   
4. 請求項３に記載のシステムにおいて、
   該テキスト・メッセージ・アプリケーションによって使用されるシグナリング・プロトコルが、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコルを含み、
   該第１の配送要求が、ＳＭＰＰ ｓｕｂｍｉｔ＿ｓｍメッセージを含み、
   該第２の配送要求が、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージを含み、
   該テキスト・メッセージ・ゲートウェイが、該相互関連ＩＤを、該ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージのｒｅｃｃｉｐｔｅｄ＿ｍｅｓｓａｇｅ＿ｉｄフィールドに挿入するようにさらに構成される、システム。
   
5. 請求項１に記載のシステムにおいて、
   該テキスト・メッセージ・ゲートウェイが、該相互関連ＩＤを、該第１のＳＩＰ要求のモバイル・アプリケーション・パート（ＭＡＰ）ＲＰ−メッセージ参照フィールドに挿入するようにさらに構成され、
   該テキスト・メッセージ・ゲートウェイが、該テキスト・メッセージ・ゲートウェイのゲートウェイＩＤを、該相互関連ＩＤとともに、該ＭＡＰ ＲＰ−メッセージ参照フィールドに挿入するようにさらに構成される、システム。
   
6. テキスト・メッセージ・アプリケーションから、セッション開始プロトコル（ＳＩＰ）を使用するパケット交換ネットワークによってサービスされているユーザ機器（ＵＥ）を宛先とするアプリケーション発信（ＡＯ）テキスト・メッセージを含む第１の配送要求を受信するステップと、
   該ＡＯテキスト・メッセージを一意に参照する相互関連識別子（ＩＤ）を生成するステップと、
   該ＡＯテキスト・メッセージを一意に参照する該相互関連識別子（ＩＤ）を、配送応答に挿入するステップと、
   該配送応答を該テキスト・メッセージ・アプリケーションに送信するステップと、
   該第１の配送要求を、該ＡＯテキスト・メッセージをカプセル化した第１のＳＩＰ要求に変換するステップと、
   該ＡＯテキスト・メッセージを一意に参照する該相互関連識別子（ＩＤ）を、該第１のＳＩＰ要求に挿入するステップと、
   該第１のＳＩＰ要求を該ＵＥに送信するステップと、を含む方法。
   
7. 請求項６に記載の方法において、
   該ＵＥから、該ＡＯテキスト・メッセージについての配送報告を含む第２のＳＩＰ要求を受信するステップと、
   該相互関連ＩＤを識別するために該第２のＳＩＰ要求を解析するステップと、
   該相互関連ＩＤに基づいて、該第２のＳＩＰ要求と、該第１のＳＩＰ要求及び該第１の配送要求とを相互に関連付けるステップと、をさらに含む、方法。
   
8. 請求項７に記載の方法において、
   該配送報告を第２の配送要求に挿入するステップと、
   該相互関連ＩＤを該第２の配送要求に挿入するステップと、
   該第２の配送要求を該テキスト・メッセージ・アプリケーションに送信するステップであって、それによって、該テキスト・メッセージ・アプリケーションが、該配送報告と、該ＡＯテキスト・メッセージを送信するために最初に使用された該第１の配送要求とを相互に関連付けることができるようにする、ステップと、をさらに含む、方法。
   
9. 請求項８に記載の方法において、
   該テキスト・メッセージ・アプリケーションによって使用されるシグナリング・プロトコルが、ショート・メッセージ・ピアツーピア（ＳＭＰＰ）プロトコルを含み、
   該第１の配送要求が、ＳＭＰＰ ｓｕｂｍｉｔ＿ｓｍメッセージを含み、
   該第２の配送要求が、ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージを含み、
   該相互関連ＩＤを、該第２の配送要求に挿入する該ステップが、該相互関連ＩＤを、該ＳＭＰＰ ｄｅｌｉｖｅｒ＿ｓｍメッセージのｒｅｃｃｉｐｔｅｄ＿ｍｅｓｓａｇｅ＿ｉｄフィールドに挿入するステップを含む、方法。
   
10. 請求項６に記載の方法において、
    該相互関連ＩＤを、該第１のＳＩＰ要求のモバイル・アプリケーション・パート（ＭＡＰ）ＲＰ−メッセージ参照フィールドに挿入するステップと、
    テキスト・メッセージ・ゲートウェイのゲートウェイＩＤを、該相互関連ＩＤとともに、該ＭＡＰ ＲＰ−メッセージ参照フィールドに挿入するステップと、をさらに含む、方法。

Images