特許 5753316 テキスト・メッセージングのための、ＲＥＳＴｆｕｌウェブ・サービスとパケット交換ネットワークとの間におけるインターフェース

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5753316

(24)【登録日】2015年5月29日

(45)【発行日】2015年7月22日

(54)【発明の名称】テキスト・メッセージングのための、ＲＥＳＴｆｕｌウェブ・サービスとパケット交換ネットワークとの間におけるインターフェース

(51)【国際特許分類】

   H04W 4/12 20090101AFI20150702BHJP

   H04W 4/18 20090101ALI20150702BHJP

   H04M 3/00 20060101ALI20150702BHJP

   H04M 11/00 20060101ALI20150702BHJP

【ＦＩ】

   H04W4/12

   H04W4/18

   H04M3/00 B

   H04M11/00 302

【請求項の数】10

【全頁数】26

(21)【出願番号】特願2014-515836(P2014-515836)

(86)(22)【出願日】2012年5月23日

(65)【公表番号】特表2014-523151(P2014-523151A)

(43)【公表日】2014年9月8日

(86)【国際出願番号】US2012039052

(87)【国際公開番号】WO2012173752

(87)【国際公開日】20121220

【審査請求日】2014年2月10日

(31)【優先権主張番号】13/160,658

(32)【優先日】2011年6月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】100094112

【弁理士】

【氏名又は名称】岡部 讓

(74)【代理人】

【識別番号】100106183

【弁理士】

【氏名又は名称】吉澤 弘司

(74)【代理人】

【識別番号】100170601

【弁理士】

【氏名又は名称】川崎 孝

(72)【発明者】

【氏名】カイ，イギャン

(72)【発明者】

【氏名】シャンカー，ギャン

【審査官】 松野 吉宏

(56)【参考文献】

【文献】 特開２０１０−１９８３５２（ＪＰ，Ａ）

【文献】 特表２００１−５１９９８２（ＪＰ，Ａ）

【文献】 特開２００４−２８９６０５（ＪＰ，Ａ）

【文献】 特開２００５−２０９１９９（ＪＰ，Ａ）

【文献】 Oracle，Oracle Communications Services Gatekeeper Concepts Guide，E16613-02，米国，Oracle，２０１１年 ４月３０日，Release 5.0，paragraph 1，ＵＲＬ，https://docs.oracle.com/cd/E16625_01/doc.50/e16613.pdf

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

Ｈ０４Ｍ ３／００

Ｈ０４Ｍ １１／００

(57)【特許請求の範囲】

【請求項1】

ウェブ・アプリケーションとパケット交換ネットワークとの間で実行される変換システムであって、
モバイル着信（ＭＴ）テキスト・メッセージを受信者へ送信するためのＲＥＳＴｆｕｌ送信オペレーションをウェブ・アプリケーションから受信するように動作可能であるインターフェースと、
前記ＭＴテキスト・メッセージに関する前記ＲＥＳＴｆｕｌ送信オペレーションを、ＭＡＰ−ＲＰデータをカプセル化している第１のセッション開始プロトコル（ＳＩＰ）要求に変換し、前記ＭＴテキスト・メッセージに関するアドレス・データ及びＳＭＳ本文を前記ＲＥＳＴｆｕｌ送信オペレーションから抽出し、前記アドレス・データを、前記第１のＳＩＰ要求のＭＡＰ ＲＰ−Ｏｒｉｇｉｎａｔｉｎｇ−Ａｄｄｒｅｓｓフィールド及びＭＡＰ ＲＰ−Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓフィールドにマップし、前記ＭＴテキスト・メッセージに関する前記ＳＭＳ本文を、前記第１のＳＩＰ要求のＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれるＴＰＤＵのＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドにマップするように動作可能であるコントローラと、を有する変換システムを含み、
前記インターフェースが、前記受信者への前記ＭＴテキスト・メッセージの配信のために、前記ＭＴテキスト・メッセージに関する前記第１のＳＩＰ要求を前記パケット交換ネットワークへ送信するようにさらに動作可能である、システム。

【請求項2】

前記第１のＳＩＰ要求が、ＳＩＰメッセージである、
請求項１に記載のシステム。

【請求項3】

前記インターフェースが、前記ＭＴテキスト・メッセージに関する配信ステータスを示す第２のＳＩＰ要求を前記パケット交換ネットワークから受信するようにさらに動作可能であり、前記第２のＳＩＰ要求は、前記ＭＡＰ−ＲＰデータをカプセル化しており、
前記コントローラが、前記第２のＳＩＰ要求をＲＥＳＴｆｕｌステータス・オペレーションに変換し、前記受信者へ前記ＭＴテキスト・メッセージの配信ステータスを示すために、前記第２のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドを解析し、前記ＭＴテキスト・メッセージの前記配信ステータスを前記ＲＥＳＴｆｕｌステータス・オペレーション内にカプセル化するようにさらに動作可能であり、
前記インターフェースが、前記ＲＥＳＴｆｕｌステータス・オペレーションを前記ウェブ・アプリケーションへ送信するようにさらに動作可能である、
請求項１に記載のシステム。

【請求項4】

前記インターフェースが、モバイル発信（ＭＯ）テキスト・メッセージに関する第３のＳＩＰ要求を前記パケット交換ネットワークから受信するようにさらに動作可能であり、
前記第３のＳＩＰ要求が、前記ＭＡＰ−ＲＰデータ内に前記ＭＯテキスト・メッセージをカプセル化しており、
前記コントローラが、前記第３のＳＩＰ要求を、ＲＥＳＴｆｕｌ受信オペレーションに変換し、前記第３のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドから前記ＭＯテキスト・メッセージに関するＳＭＳ本文を抽出し、前記ＭＯテキスト・メッセージに関する前記ＳＭＳ本文を前記ＲＥＳＴｆｕｌ受信オペレーション内にカプセル化するようにさらに動作可能であり、
前記インターフェースが、前記ウェブ・アプリケーションのユーザへの前記ＭＯテキスト・メッセージの配信のために、前記ＭＯテキスト・メッセージに関する前記ＲＥＳＴｆｕｌ受信オペレーションを前記ウェブ・アプリケーションへ送信するようにさらに動作可能である、
請求項１に記載のシステム。

【請求項5】

前記インターフェースが、前記ウェブ・アプリケーションの前記ユーザへの前記ＭＯテキスト・メッセージに関する配信ステータスを示すＲＥＳＴｆｕｌステータス・オペレーションを前記ウェブ・アプリケーションから受信するようにさらに動作可能であり、
前記コントローラが、前記ＲＥＳＴｆｕｌステータス・オペレーションを、前記ＭＡＰ−ＲＰデータをカプセル化している第４のＳＩＰ要求に変換し、前記ＲＥＳＴｆｕｌステータス・オペレーションから、前記第４のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドへ、前記配信ステータスをマップするようにさらに動作可能であり、
前記インターフェースが、前記第４のＳＩＰ要求を前記パケット交換ネットワークへ送信するようにさらに動作可能である、
請求項４に記載のシステム。

【請求項6】

ウェブ・アプリケーションとパケット交換ネットワークとの間で実行される変換システムにおいて行われる方法であって、
モバイル着信（ＭＴ）テキスト・メッセージを受信者へ送信するためのＲＥＳＴｆｕｌ送信オペレーションをウェブ・アプリケーションから受信するステップと、
前記ＭＴテキスト・メッセージに関する前記ＲＥＳＴｆｕｌ送信オペレーションを、ＭＡＰ−ＲＰデータをカプセル化している第１のセッション開始プロトコル（ＳＩＰ）要求に変換するステップと、
前記ＭＴテキスト・メッセージに関するアドレス・データ及びＳＭＳ本文を前記ＲＥＳＴｆｕｌ送信オペレーションから抽出するステップと、
前記アドレス・データを、前記第１のＳＩＰ要求のＭＡＰ ＲＰ−Ｏｒｉｇｉｎａｔｉｎｇ−Ａｄｄｒｅｓｓフィールド及びＭＡＰ ＲＰ−Ｄｅｓｔｉｎａｔｉｏｎ−Ａｄｄｒｅｓｓフィールドにマップするステップと、
前記ＭＴテキスト・メッセージに関する前記ＳＭＳ本文を、前記第１のＳＩＰ要求のＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれるＴＰＤＵのＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドにマップするステップと、
前記受信者への前記ＭＴテキスト・メッセージの配信のために、前記ＭＴテキスト・メッセージに関する前記第１のＳＩＰ要求を前記パケット交換ネットワークへ送信するステップと
を含む方法。

【請求項7】

前記第１のＳＩＰ要求が、ＳＩＰメッセージである、
請求項６に記載の方法。

【請求項8】

前記ＭＴテキスト・メッセージに関する配信ステータスを示す第２のＳＩＰ要求を前記パケット交換ネットワークから受信するステップであって、前記第２のＳＩＰ要求は、前記ＭＡＰ−ＲＰデータをカプセル化している、ステップと、
前記第２のＳＩＰ要求をＲＥＳＴｆｕｌステータス・オペレーションに変換するステップと、
前記受信者へ前記ＭＴテキスト・メッセージの配信ステータスを示すために、前記第２のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドを解析するステップと、
前記ＭＴテキスト・メッセージの前記配信ステータスを前記ＲＥＳＴｆｕｌステータス・オペレーション内にカプセル化するステップと、
前記ＲＥＳＴｆｕｌステータス・オペレーションを前記ウェブ・アプリケーションへ送信するステップと
をさらに含む、請求項６に記載の方法。

【請求項9】

モバイル発信（ＭＯ）テキスト・メッセージに関する第３のＳＩＰ要求を前記パケット交換ネットワークから受信するステップであって、前記第３のＳＩＰ要求が、前記ＭＡＰ−ＲＰデータ内に前記ＭＯテキスト・メッセージをカプセル化している、ステップと、
前記第３のＳＩＰ要求を、ＲＥＳＴｆｕｌ受信オペレーションに変換するステップと、
前記第３のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドから前記ＭＯテキスト・メッセージに関するＳＭＳ本文を抽出するステップと、
前記ＭＯテキスト・メッセージに関する前記ＳＭＳ本文を前記ＲＥＳＴｆｕｌ受信オペレーション内にカプセル化するステップと、
前記ウェブ・アプリケーションのユーザへの前記ＭＯテキスト・メッセージの配信のために、前記ＭＯテキスト・メッセージに関する前記ＲＥＳＴｆｕｌ受信オペレーションを前記ウェブ・アプリケーションへ送信するステップと
をさらに含む、請求項６に記載の方法。

【請求項10】

前記ウェブ・アプリケーションの前記ユーザへの前記ＭＯテキスト・メッセージに関する配信ステータスを示すＲＥＳＴｆｕｌステータス・オペレーションを前記ウェブ・アプリケーションから受信するステップと、
前記ＲＥＳＴｆｕｌステータス・オペレーションを、前記ＭＡＰ−ＲＰデータをカプセル化している第４のＳＩＰ要求に変換するステップと、
前記ＲＥＳＴｆｕｌステータス・オペレーションから、前記第４のＳＩＰ要求の前記ＭＡＰ ＲＰ−Ｕｓｅｒ−Ｄａｔａフィールドに含まれる前記ＴＰＤＵの前記ＭＡＰ ＴＰ−Ｕｓｅｒ−Ｄａｔａフィールドへ、前記配信ステータスをマップするステップと、
前記第４のＳＩＰ要求を前記パケット交換ネットワークへ送信するステップと
をさらに含む、請求項９に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信の分野に関し、詳細には、テキスト・メッセージングのためにＲＥＳＴｆｕｌウェブ・サービスとパケット交換ネットワークとのインターフェースを取ることに関する。

【背景技術】

【0002】

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

【0003】

テキスト・メッセージングとは、従来より、２つのモバイル・デバイスがテキスト・メッセージをやり取りすることと考えられているが、エンド・ユーザがテキスト・メッセージを送信または受信することを可能にするウェブベースのアプリケーションが存在することができる。たとえば、エンド・ユーザは、テキスト・メッセージを送信／受信するためにサード・パーティーのウェブ・サイトにアクセスすることができる。そのサード・パーティーのウェブ・サイトを通じて、エンド・ユーザは、受信者に向けられたメッセージと、その受信者に関する電話番号とを入力することができる。次いでウェブベースのアプリケーションは、ウェブベースのサービスのために定義されたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用して、テキスト・メッセージに関する送信要求を生成する。別の例においては、いくつかのソーシャル・ネットワーキング・サービス（たとえば、フェイスブック）が、ウェブ・サイトを通じてテキスト・メッセージング動作を提供することができる。ユーザが自分のソーシャル・ネットワーク・アカウントにログインしたときに、そのエンド・ユーザにとって利用可能な１つのオプションは、テキスト・メッセージを送信／受信することであり得る。

【0004】

組織は、テキスト・メッセージを送信／受信する際に使用するためにウェブベースのアプリケーションのための標準的なＡＰＩを定義している。ウェブ・アプリケーションのために使用される１つのＡＰＩが、ＲＥＳＴｆｕｌ ＡＰＩであり、これは、ＲＥＳＴｆｕｌウェブＡＰＩとも呼ばれている。ＲＥＳＴｆｕｌウェブＡＰＩは、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）制約に準拠しながら、ＰＯＳＴ、ＧＥＴ、ＰＵＴ、およびＤＥＬＥＴＥなどのＨＴＴＰメソッドを使用するオペレーションのセットである。

【先行技術文献】

【非特許文献】

【0005】

【非特許文献1】３ＧＰＰ ＴＳ ２３．０４０

【発明の概要】

【発明が解決しようとする課題】

【0006】

残念なことに、ウェブ・サービスのために現在使用されているＲＥＳＴｆｕｌ ＡＰＩは、今日の進化するネットワークのための十分な柔軟性を提供していない。

【課題を解決するための手段】

【0007】

本明細書に記載されている実施形態は、ＲＥＳＴｆｕｌウェブ・サービスとパケット交換ネットワークとのインターフェースを取る、ＡＰＩなどのシステムを提供する。このシステムは、ＳＭＳ／ＭＭＳメッセージングのために、ウェブ・アプリケーションからのＲＥＳＴｆｕｌオペレーションを、パケット交換ネットワークのシグナリング・プロトコルでのメッセージに転換することができる。また、このシステムは、パケット交換ネットワークからのシグナリング・メッセージをＲＥＳＴｆｕｌオペレーションに転換することができる。ＲＥＳＴｆｕｌと、パケット交換ネットワークのシグナリング・プロトコルとの間において変換を行うことによって、ウェブ・アプリケーションと、パケット交換ネットワークとの間において直接テキスト・メッセージがやり取りされることが可能となる。これは、有利なことに、ＩＭＳネットワークまたはＬＴＥネットワークなどの進化するネットワークにおいてどのようにウェブベースのテキスト・メッセージングが実施され得るかを改善する。

【0008】

一実施形態は、ウェブ・アプリケーションからパケット交換ネットワークへのモバイル着信（Mobile Terminated）（ＭＴ）テキスト・メッセージを取り扱うシステムを含む。このシステムは、ＭＴテキスト・メッセージを送信するために使用される、ウェブ・アプリケーションからのＲＥＳＴｆｕｌ送信オペレーションをウェブ・アプリケーションから受信するように動作可能であるインターフェースを含む。このシステムは、ＭＴテキスト・メッセージに関するＲＥＳＴｆｕｌ送信オペレーションを、パケット交換ネットワークにおいて使用されるシグナリング・プロトコルでの送信要求に変換するように動作可能であるコントローラをさらに含む。パケット交換ネットワークにおいて使用されるシグナリング・プロトコルは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＳＭＰＰ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）プロトコル、ＭＡＰ（Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）プロトコルなどであることが可能である。インターフェースは、受信者へのＭＴテキスト・メッセージの配信のために、ＭＴテキスト・メッセージに関する送信要求をパケット交換ネットワークへ送信するようにさらに動作可能である。

【0009】

別の実施形態においては、このシステムは、パケット交換ネットワークからウェブ・アプリケーションへのモバイル発信（Mobile Originated）（ＭＯ）テキスト・メッセージを取り扱うことができる。インターフェースは、ＭＯテキスト・メッセージに関する送信要求をパケット交換ネットワークから受信するように動作可能である。上述のように、送信要求は、パケット交換ネットワークにおいて使用されるシグナリング・プロトコルでのものである。コントローラは、ＭＯテキスト・メッセージに関する送信要求を、ＭＯテキスト・メッセージをウェブ・アプリケーションへと受信するために使用されるＲＥＳＴｆｕｌ受信オペレーションに変換するようにさらに動作可能である。インターフェースは、ウェブ・アプリケーションのユーザへのＭＯテキスト・メッセージの配信のために、ＭＯテキスト・メッセージに関するＲＥＳＴｆｕｌ受信オペレーションをウェブ・アプリケーションへ送信するようにさらに動作可能である。

【0010】

別の実施形態は、ウェブ・アプリケーションからパケット交換ネットワークへのモバイル着信（ＭＴ）テキスト・メッセージを取り扱う方法を含む。この方法は、モバイル着信（ＭＴ）テキスト・メッセージを送信するためのＲＥＳＴｆｕｌ送信オペレーションをウェブ・アプリケーションから受信するステップと、ＭＴテキスト・メッセージに関するＲＥＳＴｆｕｌ送信オペレーションを、パケット交換ネットワークにおいて使用されるシグナリング・プロトコルに基づく送信要求に変換するステップとを含む。この方法は、受信者へのＭＴテキスト・メッセージの配信のために、ＭＴテキスト・メッセージに関する送信要求をパケット交換ネットワークへ送信するステップをさらに含む。

【0011】

別の実施形態は、パケット交換ネットワークからウェブ・アプリケーションへのモバイル発信（ＭＯ）テキスト・メッセージを取り扱う方法を含む。この方法は、モバイル発信（ＭＯ）テキスト・メッセージに関する送信要求をパケット交換ネットワークから受信するステップであって、ＭＯテキスト・メッセージに関する送信メッセージが、パケット交換ネットワークにおいて使用されるシグナリング・プロトコルに基づいている、ステップを含む。この方法は、ＭＯテキスト・メッセージに関する送信要求を、ＭＯテキスト・メッセージをウェブ・アプリケーションにおいて受信するためのＲＥＳＴｆｕｌ受信オペレーションに変換するステップと、ウェブ・アプリケーションのユーザへのＭＯテキスト・メッセージの配信のために、ＭＯテキスト・メッセージに関するＲＥＳＴｆｕｌ受信オペレーションをウェブ・アプリケーションへ送信するステップとをさらに含む。

【0012】

その他の例示的な実施形態については、以下で説明することができる。

【0013】

次いで、本発明のいくつかの実施形態について、単なる例として、添付の図面を参照して説明する。同じ参照番号は、すべての図面上で同じ要素または同じ種類の要素を表す。

【図面の簡単な説明】

【0014】

【図1】例示的な一実施形態における通信システムを示す図である。

【図2】例示的な一実施形態における、ウェブ・アプリケーションからユーザ機器（ＵＥ）へのＭＴテキスト・メッセージを取り扱う方法を示すフローチャートである。

【図3】例示的な一実施形態における、ＵＥからウェブ・アプリケーションへのＭＯテキスト・メッセージを取り扱う方法を示すフローチャートである。

【図4】例示的な一実施形態における、パケット交換ネットワークからウェブ・アプリケーションへのステータス・メッセージを取り扱う方法を示すフローチャートである。

【図5】例示的な一実施形態における、ウェブ・アプリケーションからパケット交換ネットワークへのＲＥＳＴｆｕｌステータス・オペレーションを取り扱う方法を示すフローチャートである。

【図6】別の例示的な実施形態における通信システムを示す図である。

【図7】例示的な一実施形態における、ＭＴ ＳＭＳメッセージに関するコール・フローを示すメッセージ図である。

【図8】例示的な一実施形態における、ＭＯ ＳＭＳメッセージに関するコール・フローを示すメッセージ図である。

【図9】例示的な一実施形態における、ＭＯ ＳＭＳメッセージに関する別のコール・フローを示すメッセージ図である。

【発明を実施するための形態】

【0015】

図および以下の説明は、本発明の具体的かつ例示的な実施形態を示している。したがって、本明細書において明示的に説明されず、または示されてもいないが、本発明の原理を具体化し、本発明の範囲内に含まれるさまざまなアレンジを当業者なら考案することができるであろう。さらに、本明細書に記載されているあらゆる例は、本発明の原理を理解する際の助けとなるよう意図されており、そのような具体的に挙げられている例および状況に対する限定を伴わないものとして解釈されるべきである。結果として、本発明は、以下で説明されている具体的な実施形態または例には限定されず、特許請求の範囲およびそれらの均等物によって限定される。

【0016】

図１は、例示的な一実施形態における通信システム１００を示している。通信システム１００は、変換システム１２０を通じてパケット交換ネットワーク１３０に結合されているウェブ・アプリケーション１１０を含む。ウェブ・アプリケーション１１０は、ＳＭＳメッセージまたはＭＭＳメッセージなどのテキスト・メッセージを送信および受信するためのウェブベースのサービスの一部である。この実施形態においては、ウェブ・アプリケーション１１０は、テキスト・メッセージを送信および受信するためにＲＥＳＴｆｕｌを使用する。パケット交換ネットワーク１３０は、ＩＰパケットなどのパケットを使用して通信をやり取りする任意のネットワークを含む。パケット交換ネットワーク１３０は、ＩＭＳネットワーク、ＬＴＥネットワーク、またはその他の任意のＩＰベースのネットワークを含むことができる。パケット交換ネットワーク１３０は、音声および／またはデータ・サービスをユーザ機器（ＵＥ）１４０に提供するために、さまざまなネットワーク・ノード（図示せず）を含むことができる。より詳細には、パケット交換ネットワーク１３０のネットワーク・ノードは、テキスト・メッセージング・サービスをＵＥ１４０に提供する。

【0017】

ウェブ・アプリケーション１１０は、変換システム１２０の助けを借りてＵＥ１４０との間でテキスト・メッセージをやり取りすることができる。変換システム１２０は、ＲＥＳＴｆｕｌオペレーションを、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルへ、およびその逆へ転換するように動作する。変換システム１２０は、ウェブ・アプリケーション１１０からの標準化されたオペレーションを、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルへ変換するため、アプリケーション・プログラミング・インターフェース（ＡＰＩ）とみなされることが可能である。この実施形態においては、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＳＭＰＰ（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ）プロトコル、ＭＡＰ（Ｍｏｂｉｌｅ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）プロトコル、または別のプロトコルであることが可能である。

【0018】

変換システム１２０は、インターフェース１２２およびコントローラ１２４を含む。インターフェース１２２は、ＲＥＳＴｆｕｌを使用してウェブ・アプリケーション１１０および／または示されていないその他のウェブ・アプリケーションと通信する任意のデバイスまたはコンポーネントを含む。インターフェース１２２は、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルを通じてパケット交換ネットワーク１３０と通信することもできる。コントローラ１２４は、ＲＥＳＴｆｕｌと、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルとの間においてメッセージを転換する任意のデバイスまたはコンポーネントを含む。

【0019】

ウェブ・アプリケーション１１０のユーザが、ＵＥ１４０に向けられたテキスト・メッセージを作成すると想定されたい。これは、モバイル着信（ＭＴ）またはアプリケーション発信（Application Originated）（ＡＯ）テキスト・メッセージと呼ばれる。これが発生した場合には、ウェブ・アプリケーション１１０は、ＭＴテキスト・メッセージを送信するためのＲＥＳＴｆｕｌオペレーションまたはコマンドを生成する。たとえば、ＭＴテキスト・メッセージを送信するためのＲＥＳＴｆｕｌオペレーションは、ＭＴテキスト・メッセージのために挿入された「ＳｅｎｄＳｍｓ」コマンドを伴うＰＯＳＴオペレーションを含むことができる。ＭＴテキスト・メッセージを送信するためのオペレーションは、本明細書においては一般にＲＥＳＴｆｕｌ送信オペレーションと呼ばれる。次いでウェブ・アプリケーション１１０は、ＲＥＳＴｆｕｌ送信オペレーションを変換システム１２０へ送信する。

【0020】

図２は、例示的な一実施形態における、ウェブ・アプリケーション１１０からＵＥ１４０へのＭＴテキスト・メッセージを取り扱う方法２００を示すフローチャートである。方法２００のステップについては、図１における変換システム１２０を参照して説明するが、本明細書に記載されている方法は、その他のシステムにおいて実行されることも可能であるということを当業者なら理解するであろう。本明細書に記載されているフローチャートのステップは、すべてを含んだものではなく、示されていないその他のステップを含むこともできる。それらのステップは、別の順序で実行されることも可能である。

【0021】

ステップ２０２においては、インターフェース１２２が、ＭＴテキスト・メッセージに関するＲＥＳＴｆｕｌ送信オペレーションをウェブ・アプリケーション１１０から受信する。ステップ２０４においては、コントローラ１２４が、ＲＥＳＴｆｕｌ送信オペレーションを、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルでの送信要求に変換する。たとえば、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルがＳＩＰを含む場合には、コントローラ１２４は、ＲＥＳＴｆｕｌ送信オペレーションを、ＭＴテキスト・メッセージをカプセル化しているＳＩＰ ＭＥＳＳＡＧＥに変換することができる。変換を実行するために、コントローラ１２４は、ＲＥＳＴｆｕｌオペレーションを、パケット交換ネットワーク１３０内で使用されるシグナリング・プロトコルのメソッドにマップするテーブルを格納することができる。このテーブルは、ＲＥＳＴｆｕｌオペレーションからのフィールド（たとえば、ソース・アドレス、終端アドレス、メッセージ・タイプなど）をシグナリング・プロトコルにおけるフィールドにマップすることもできる。コントローラ１２４は、このテーブルを使用して、ウェブ・アプリケーション１１０からのＲＥＳＴｆｕｌ送信オペレーションを送信要求に変換することができる。

【0022】

ステップ２０６においては、インターフェース１２２が、送信要求をパケット交換ネットワーク１３０へ送信し、それによってＭＴテキスト・メッセージは、その意図されている受信者（ＵＥ１４０）へ配信されることが可能になる。パケット交換ネットワーク１３０内の適切なノードが、ＵＥ１４０へのＭＴテキスト・メッセージの配信を、別のプロトコルへの変換を伴うことなく、試みることができる。

【0023】

上述したのと類似のプロセスが、テキスト・メッセージをＵＥ１４０からウェブ・アプリケーション１１０へ配信するために使用される。ＵＥ１４０のエンド・ユーザが、ウェブ・アプリケーション１１０に向けられたテキスト・メッセージを作成すると想定されたい。これは、モバイル発信（ＭＯ）またはアプリケーション着信（Application Terminated）（ＡＴ）テキスト・メッセージと呼ばれる。これが発生した場合には、ＵＥ１４０内のテキスト・メッセージ・アプリケーションが、ＳＩＰ ＭＥＳＳＡＧＥなどのＭＯテキスト・メッセージを送信するために使用されるパケット交換ネットワーク１３０のためのシグナリング・プロトコルでの送信要求を生成する。次いでＵＥ１４０は、その送信要求を変換システム１２０へ送信する。

【0024】

図３は、例示的な一実施形態における、ＵＥ１４０からウェブ・アプリケーション１１０へのＭＯテキスト・メッセージを取り扱う方法３００を示すフローチャートである。ステップ３０２においては、インターフェース１２２が、ＭＯテキスト・メッセージに関する送信要求をＵＥ１４０から受信する。ステップ３０４においては、コントローラ１２４が、その送信要求をＲＥＳＴｆｕｌ受信オペレーションに変換する。ＲＥＳＴｆｕｌ受信オペレーションは、ＭＯテキスト・メッセージを受信するためにウェブ・アプリケーション１１０によって使用されるオペレーションである。たとえば、コントローラ１２４は、その送信要求を、ＭＯテキスト・メッセージのために挿入された「ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ」コマンドを伴うＰＯＳＴオペレーションへと変換することができる。ウェブ・アプリケーション１１０においてＭＯテキスト・メッセージを受信するためのオペレーションは、本明細書においては一般にＲＥＳＴｆｕｌ受信オペレーションと呼ばれる。ステップ３０６においては、インターフェース１２２が、ＲＥＳＴｆｕｌ受信オペレーションをウェブ・アプリケーション１１０へ送信し、それによってＭＯテキスト・メッセージは、ウェブ・アプリケーション１１０へ配信されることが可能になる。次いでウェブ・アプリケーション１１０は、ＲＥＳＴｆｕｌ受信オペレーションを処理して、ＭＯテキスト・メッセージを抽出することができ、テキスト・メッセージをユーザに表示することができる。

【0025】

ＭＴテキスト・メッセージおよびＭＯテキスト・メッセージが、上述の実施形態において説明されているように送信される場合には（図２のステップ２０６を参照されたい）、それらのテキスト・メッセージが成功裏に配信されているかどうかを示すためにやり取りされるさらなるメッセージが存在することが可能である。これらのメッセージは、通知、肯定応答、ステータス・メッセージなどと呼ばれる場合がある。変換システム１２０は、これらのさらなるメッセージを上述と類似の様式で転換することができる。図４〜図５は、テキスト・メッセージ配信に関するステータス情報を搬送するメッセージの変換を示している。図４〜図５に記載されているもの以外にも、ウェブ・アプリケーション１１０と、パケット交換ネットワーク１３０との間においてステータス情報をやり取りするために送信されるさらなるメッセージが存在することが可能である。より詳細なメッセージ図が、図７〜図９において提供されている。

【0026】

パケット交換ネットワーク１３０は、ＭＴテキスト・メッセージに関する送信要求を受信した場合には、ＭＴテキスト・メッセージをＵＥ１４０へ配信するよう試みる。ＭＴテキスト・メッセージの配信が成功または失敗した場合には、パケット交換ネットワーク１３０は、ＭＴテキスト・メッセージの配信に関するステータス情報を含むステータス・メッセージを生成する。そのステータス・メッセージは、パケット交換ネットワーク１３０によって使用されるシグナリング・プロトコルでのものである。たとえば、パケット交換ネットワーク１３０においてＳＩＰが使用されている場合には、そのステータス・メッセージは、ＳＩＰ ＭＥＳＳＡＧＥ、ＳＩＰ ＮＯＴＩＦＹ、またはＳＩＰ ７ｘｘメッセージなどのＳＩＰ応答を含むことができる。次いでパケット交換ネットワーク１３０は、そのステータス・メッセージを変換システム１２０へ送信する。

【0027】

図４は、例示的な一実施形態における、パケット交換ネットワーク１３０からウェブ・アプリケーション１１０へのステータス・メッセージを取り扱う方法４００を示すフローチャートである。ステップ４０２においては、インターフェース１２２が、ＭＴテキスト・メッセージに関するステータス・メッセージをパケット交換ネットワーク１３０から受信する。ステップ４０４においては、コントローラ１２４が、そのステータス・メッセージをＲＥＳＴｆｕｌステータス・オペレーションに変換する。たとえば、ＲＥＳＴｆｕｌステータス・オペレーションは、ステータス情報をカプセル化している挿入された「ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ」コマンドを伴うＰＯＳＴオペレーションを含むことができる。ステップ４０６においては、インターフェース１２２が、ＲＥＳＴｆｕｌステータス・オペレーションをウェブ・アプリケーション１１０へ送信する。次いでウェブ・アプリケーション１１０は、ＲＥＳＴｆｕｌステータス・オペレーションからステータス情報を抽出して、そのステータス情報を要望に応じて処理することができる。

【0028】

ＭＯテキスト・メッセージに関して、ウェブ・アプリケーション１１０は、そのＭＯテキスト・メッセージの配信に関するステータス情報を生成することができる。ＭＯテキスト・メッセージの配信が成功または失敗した場合には、ウェブ・アプリケーション１１０は、ＭＯテキスト・メッセージに関するステータス情報を含むＲＥＳＴｆｕｌステータス・オペレーションを生成する。ＲＥＳＴｆｕｌステータス・オペレーションは、ステータス情報をカプセル化している挿入された「ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ」コマンドを伴うＰＯＳＴオペレーションを含むことができる。次いでウェブ・アプリケーション１１０は、ＲＥＳＴｆｕｌステータス・オペレーションを変換システム１２０へ送信する。

【0029】

図５は、例示的な一実施形態における、ウェブ・アプリケーション１１０からパケット交換ネットワーク１３０へのＲＥＳＴｆｕｌステータス・オペレーションを取り扱う方法５００を示すフローチャートである。ステップ５０２においては、インターフェース１２２が、ＭＯテキスト・メッセージに関するＲＥＳＴｆｕｌステータス・オペレーションをウェブ・アプリケーション１１０から受信する。ステップ５０４においては、コントローラ１２４が、ＲＥＳＴｆｕｌステータス・オペレーションを、パケット交換ネットワーク１３０のシグナリング・プロトコルでのステータス・メッセージに変換する。たとえば、パケット交換ネットワーク１３０内でＳＩＰが使用される場合には、ステータス・メッセージは、ステータス情報をカプセル化しているＳＩＰ ＭＥＳＳＡＧＥを含むことができる。ステップ５０６においては、インターフェース１２２が、ステータス・メッセージをパケット交換ネットワーク１３０へ送信する。次いでパケット交換ネットワーク１３０は、ステータス・メッセージからステータス情報を抽出して、そのステータス情報を要望に応じて処理することができる。

【0030】

上述したような変換システム１２０は、進化するパケット交換ネットワークにおいてウェブベースのテキスト・メッセージングが実施されることを可能にする。たとえば、変換システム１２０は、ＩＭＳネットワークおよびＬＴＥネットワークにおいてウェブベースのテキスト・メッセージングを実施するために使用されることが可能である。これは、有利なことに、ＩＭＳサービス・プロバイダおよびＬＴＥサービス・プロバイダにとっての収益を増大させることができる。

【実施例】

【0031】

図６は、別の例示的な実施形態における通信システム６００を示している。通信システム６００は、変換システム６２０およびＩＰショート・メッセージ・ゲートウェイ（ＩＰ−ＳＭ−ＧＷ）６３２を通じてＩＭＳネットワーク６３０に結合されているウェブ・アプリケーション６１０を含む。ＩＭＳネットワーク６３０は、ＵＥ６４０にサービス提供するサービングコール・セッション・コントロール・ファンクション（Ｓ−ＣＳＣＦ）６３４を含む。ウェブ・アプリケーション６１０は、テキスト・メッセージを送信／受信するためにＲＥＳＴｆｕｌを使用する。したがって、変換システム６２０は、ＲＥＳＴｆｕｌオペレーションをＩＭＳネットワーク６３０のシグナリング・プロトコルへ、およびその逆へ変換することができる。変換システム６２０は、ＲＥＳＴｆｕｌ ＳＭＳウェブ・サービス（RESTful SMS Web Service）を提供する新たなＡＰＩとみなされることが可能である。ＲＥＳＴｆｕｌ ＳＭＳウェブ・サービスは、ＭＴ ＳＭＳメッセージをパケット交換（ＩＰ）ネットワークへ送信するための、パケット交換ネットワークからＭＯ ＳＭＳメッセージを受信するための、ＭＴ／ＭＯメッセージに関する肯定応答メッセージをパケット交換ネットワークへ／から送信／受信するための、およびメッセージ配信ステータスの通知を非同期的に受信するための、ウェブ・アプリケーション用のオペレーションを提供する。

【0032】

ＲＥＳＴｆｕｌ ＳＭＳウェブ・サービスは、ウェブ・アプリケーション６１０向けの下記のＳＭＳインターフェース／メソッドをサポートする。
− ＳｅｎｄＳｍｓ
− ＧｅｔＳｍｓＤｅｌｉｖｅｒｙＳｔａｔｕｓ
− ＧｅｔＲｅｃｅｉｖｅｄＳｍｓ
− ＳｔａｒｔＳｍｓＮｏｔｉｆｉｃａｔｉｏｎ
− ＳｔｏｐＳｍｓＮｏｔｉｆｉｃａｔｉｏｎ
− ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ
− ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ
それぞれのＲＥＳＴｆｕｌインターフェース／メソッドは、１つのＨＴＴＰバーブ／オペレーションに属する。表１は、３ＧＰＰ ＭＡＰおよびＳＭＰＰ ＰＤＵとのＲＥＳＴｆｕｌプロファイル（RESTful profile）の関係を示している。

【0033】

【表1】

ＡＣＫまたはエラーに関するｍｏ−ＦｏｒｗａｒｄＳＭ−ｒｅｓ／ＳＭＳ−ＳＵＢＭＩＴ
ＡＣＫまたはエラーに関するｍｔ−ＦｏｒｗａｒｄＳＭ−ｒｅｓ／ＳＭＳ−ＤＥＬＩＶＥＲ
＃７ その２００ ＯＫ応答は、ｍｏ−ＦｏｒｗａｒｄＳＭ／ＳＭＳ−ＳＵＢＭＩＴにマップする
＃８ その２００ ＯＫ応答は、ｄｅｌｉｖｅｒ＿ｓｍにマップする

【0034】

ＲＥＳＴｆｕｌ ＳＭＳウェブ・サービスは、ＨＴＴＰバーブのうちのそれぞれのリターン（return）に関するＨＴＴＰステータス・コードをサポートすべきである。これらのステータス・コードは、下記のものを含むが、それらには限定されない。
− ２００ ＯＫ
− ２０２ Ａｃｃｅｐｔｅｄ
− ４００ Ｂａｄ Ｒｅｑｕｅｓｔ
− ４０３ Ｆｏｒｂｉｄｄｅｎ
− ５００ Ｉｎｔｅｒｎａｌ Ｓｅｒｖｅｒ Ｅｒｒｏｒ

【0035】

図７〜図９において示されている例は、ＩＭＳネットワーク６３０がシグナリング・プロトコルとしてＳＩＰを使用している場合に変換システム６２０がウェブ・アプリケーション６１０とＩＭＳネットワーク６３０とのインターフェースをどのように取るかをさらに示している。

【0036】

図７は、例示的な一実施形態における、ＭＴ ＳＭＳメッセージに関するコール・フローを示すメッセージ図である。一例として、ウェブ・アプリケーション６１０のユーザが、ＵＥ６４０に向けられたＭＴ ＳＭＳメッセージを作成すると想定されたい。これが発生した場合には、ウェブ・アプリケーション６１０は、ＭＴ ＳＭＳメッセージを送信するためのＲＥＳＴｆｕｌ送信オペレーションを生成する。この例においては、ＲＥＳＴｆｕｌ送信オペレーションは、ＰＯＳＴオペレーション内に挿入された「ＳｅｎｄＳｍｓ」コマンドを伴うＰＯＳＴオペレーションを含む。ＰＯＳＴオペレーションの一例は、下記のとおりである。
POST /openapi/sms/rest/v1.0/sendsms HTTP/1.1
Authorization: Basic XMVDTdx+
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"SendSMS":[{"sendAddress":"sip:[e-mail]","address":"tel:[phone]","message body":"Hello, Alice","DateTime":"2010-25T15:30:00"}]}
このＰＯＳＴオペレーションは、ＳＭＳメッセージを送信するためのＳｅｎｄＳｍｓコマンドを含む。発信者のアドレスは、[phone]であり、受信者のアドレスは、[phone]であり、ＳＭＳテキスト本文は、「Ｈｅｌｌｏ， Ａｌｉｃｅ」である。ウェブ・アプリケーション６１０は、このＰＯＳＴオペレーションを変換システム６２０へ送信する（矢印７０１を参照されたい）。変換システム６２０は、ＨＴＴＰ ２０２ Ａｃｃｅｐｔｅｄメッセージを用いてウェブ・アプリケーション６１０に応答する（矢印７０２を参照されたい）。

【0037】

ウェブ・アプリケーション６１０はまた、配信ステータス・レポートを求める要求を変換システム６２０へ送信する。このステータス要求は、ＧＥＴ（ＧｅｔＳｍｓＤｅｌｉｖｅｒｙＳｔａｔｕｓ）オペレーションを含む（矢印７０３を参照されたい）。ＧＥＴオペレーションの一例は、下記のとおりである。
GET /openapi/sms/rest/v1.0/registration/7777/messages HTTP/1.1
Authorization: Basic XMVDTdx+
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatel-lucent.com
Accept application/json
Content-Length: 0
変換システム６２０は、配信情報を含むＨＴＴＰ ２００ ＯＫメッセージを用いてウェブ・アプリケーション６１０に返答する（矢印７０４を参照されたい）。ＨＴＴＰ ２００ ＯＫの一例は、下記のとおりである。
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: (...)
{"DeliveryInformation":[{"address":"tel:[phone]","deliveryStatus": "DeliveredToNetwork"}]}

【0038】

変換システム６２０は、ＰＯＳＴ（ＳｅｎｄＳＭＳ）オペレーションからアドレス・データおよびＳＭＳ本文を抽出し、それを、ＳＭＳメッセージをカプセル化しているＳＩＰ ＭＥＳＳＡＧＥへと変換する。より詳細には、ＭＴ ＳＭＳメッセージは、ＳＩＰ ＭＥＳＳＡＧＥの３ＧＰＰ ＭＡＰ ＲＰ−ＤＡＴＡ（ＭＡＰ ｍｔ−ＦｏｒｗａｒｄＳＭ（ＳＭＳ−ＤＥＬＩＶＥＲ））内に組み込まれる。ＭＴ ＳＭＳメッセージをカプセル化するためにＳＩＰ ＭＥＳＳＡＧＥ内でＭＡＰ ＲＰ−ＤＡＴＡが使用される場合には、そのＲＰ−ＤＡＴＡは、表２において示されているパラメータを有することができる。

【0039】

【表2】

【0040】

ＲＰ−Ｕｓｅｒ Ｄａｔａフィールドが、ＭＴ ＳＭＳメッセージに関するＳＭＳ−ＤＥＬＩＶＥＲ ＴＰＤＵを含む場合には（３ＧＰＰ ＴＳ ２３．０４０を参照されたい）、そのＲＰ−Ｕｓｅｒ Ｄａｔａは、表３において示されているパラメータを有することができる。

【0041】

【表3】

【0042】

ＰＯＳＴオペレーションをＳＩＰ ＭＥＳＳＡＧＥに変換した後に、変換システム６２０は、そのＳＩＰ ＭＥＳＳＡＧＥをＩＰ−ＳＭ−ＧＷ６３２へ送信する（矢印７０５を参照されたい）。そしてＩＰ−ＳＭ−ＧＷ６３２は、そのＳＩＰ ＭＥＳＳＡＧＥをＩＭＳネットワーク６３０のＳ−ＣＳＣＦ６３４へ転送する（矢印７０６を参照されたい）。ＳＭＳメッセージは、既にＳＩＰ ＭＥＳＳＡＧＥ内にカプセル化されているため、ＩＰ−ＳＭ−ＧＷ６３２は、そのメッセージを別のプロトコル（たとえば、ＳＭＰＰ）からＳＩＰに変換する必要はない。次いでＳ−ＣＳＣＦ６３４は、そのＳＩＰ ＭＥＳＳＡＧＥをＵＥ６４０へ配信する（矢印７０７を参照されたい）。ＵＥ６４０は、そのＳＩＰ ＭＥＳＳＡＧＥを成功裏に解析し、ＳＩＰ ２００ ＯＫを用いて変換システム６２０に応答する（矢印７０８〜７１０を参照されたい）。

【0043】

次いでＵＥ６４０は、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＤＡＴＡを解析し、そのＲＰ−ＤＡＴＡが、組み込まれている配信ステータス要求をＴＰ−ＳＲＩ内に含んでいると判定する（表３を参照されたい）。したがって、ＵＥ６４０は、ＳＭＳメッセージを搬送したオリジナルのＳＩＰ ＭＥＳＳＡＧＥに関するステータス情報を含む別のＳＩＰ ＭＥＳＳＡＧＥを変換システム６２０に送信する（矢印７１１〜７１３を参照されたい）。より詳細には、そのステータス情報は、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＡＣＫ内に組み込まれる。ＲＰ−ＡＣＫは、表４において示されているパラメータを有することができる。

【0044】

【表4】

変換システム６２０は、ＳＩＰ ２００ ＯＫを用いてＵＥ６４０に返答する（矢印７１４〜７１６を参照されたい）。

【0045】

ＳＩＰ ＭＥＳＳＡＧＥに関するステータス情報を含むＳＩＰ ＭＥＳＳＡＧＥに応答して、変換システム６２０は、ＵＥ６４０からのＳＩＰ ＭＥＳＳＡＧＥを、ステータス情報をカプセル化しているＲＥＳＴｆｕｌステータス・オペレーションへと変換する。この例におけるＲＥＳＴｆｕｌステータス・オペレーションは、ＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ）である。変換システム６２０は、ＭＡＰ ＲＰ−ＡＣＫからのパラメータをＰＯＳＴオペレーションへとマップする。ＰＯＳＴオペレーションの一例は、下記のとおりである。
POST /openapi/sms/rest/vl.0/receivedsmsnotification HTTP/1.1
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"senderAddress": "tel: [phone]", "smsServiceActivationNumber":
"7777","message":"Hello, Alice", "dateTime":"2010-12-25T16:30:15"}
次いで変換システム６２０は、ＰＯＳＴ（ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ）オペレーションをウェブ・アプリケーション６１０へ送信する（矢印７１７を参照されたい）。ウェブ・アプリケーション６１０は、ＨＴＴＰ ２００ ＯＫを用いて変換システム６２０に応答する（矢印７１８を参照されたい）。

【0046】

ＵＥ６４０は、ＳＩＰ ＭＥＳＳＡＧＥに関するステータス情報を提供することに加えて、ＳＭＳメッセージそのものが成功裏に配信されたかどうかを判定することができる。たとえ、ＳＭＳメッセージをカプセル化しているＳＩＰ ＭＥＳＳＡＧＥがＵＥ６４０において成功裏に受信されたとしても、ＳＭＳメッセージそのものが何らかの形で破損されている場合があり、したがって、そのＳＭＳメッセージが処理されず、エンド・ユーザに表示されることが不可能になる。したがって、ＵＥ６４０は、ＳＭＳメッセージが処理されてエンド・ユーザに提供されたかどうかを判定すること、およびＭＴ ＳＭＳメッセージの配信に関するステータス情報を生成することが可能である。

【0047】

ＵＥ６４０は、ＭＴ ＳＭＳメッセージに関するステータス情報を含む別のＳＩＰ ＭＥＳＳＡＧＥを変換システム６２０へ送信する（矢印７１９〜７２１を参照されたい）。そのステータス情報（配信ステータス・レポート）は、ＳＩＰ ＭＥＳＳＡＧＥ（ＭＡＰ Ｒｅｐｏｒｔ−ＳＭ−Ｄｅｌｉｖｅｒｙ−Ｓｔａｔｕｓ（ＳＭＳ−ＳＴＡＴＵＳ−ＲＥＰＯＲＴ））のＲＰ−ＤＡＴＡ内に組み込まれる。そのＳＩＰ ＭＥＳＳＡＧＥのフォーマットは、そのＳＭＳメッセージに関するオリジナルのＳＩＰ ＭＥＳＳＡＧＥと同じであるが、ＲＰ−ＤＡＴＡ内のＴＰＤＵは、ＴＳ ２３．０４０によって定義されているＳＭＳ−ＳＴＡＴＵＳ−ＲＥＰＯＲＴを含む。ＲＰ−Ｕｓｅｒ Ｄａｔａは、表５において示されているパラメータを有することができる。

【0048】

【表5】

変換システム６２０は、ＳＩＰ ２００ ＯＫを用いてＵＥ６４０に返答する（矢印７２２〜７２４を参照されたい）。

【0049】

ＳＭＳメッセージに関するステータス情報を含むＳＩＰ ＭＥＳＳＡＧＥに応答して、変換システム６２０は、ＵＥ６４０からのＳＩＰ ＭＥＳＳＡＧＥを、ステータス情報をカプセル化しているＲＥＳＴｆｕｌステータス・オペレーションへと変換する。この例におけるＲＥＳＴｆｕｌステータス・オペレーションは、ＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ）である。ＰＯＳＴオペレーションの一例は、下記のとおりである。
POST /openapi/sms/rest/v1.0/deliveryreceiptnotification HTTP/1.1
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"requestedID":"123456789","deliveryInformation":{"address: "tel: [phone]", "deliveryStatus":"deliveredToNetwork"}}
次いで変換システム６２０は、ＰＯＳＴオペレーションをウェブ・アプリケーション６１０へ送信する（矢印７２５を参照されたい）。ウェブ・アプリケーション６１０は、ＨＴＴＰ ２００ ＯＫを用いて変換システム６２０に応答する（矢印７２６を参照されたい）。図７が、ＳＭＳ配信において使用されるメッセージングの概観を提供しているが、ＭＴ ＳＭＳメッセージと、その関連付けられているステータス情報とを配信するために使用されるさらなるメッセージングが存在することが可能である。

【0050】

図８は、例示的な一実施形態における、ＭＯ ＳＭＳメッセージに関するコール・フローを示すメッセージ図である。図８は、ＭＯ ＳＭＳメッセージが送信されるときにウェブ・アプリケーション６１０のユーザがオンラインである場合のシナリオを示している。ウェブ・アプリケーション６１０は、変換システム６２０からのＳＭＳメッセージの受信をセットアップするためのＰＯＳＴオペレーション（ＳｔａｒｔＳｍｓＮｏｔｉｆｉｃａｔｉｏｎ）を生成する。ＰＯＳＴオペレーション（ＳｔａｒｔＳｍｓＮｏｔｉｆｉｃａｔｉｏｎ）の一例は、下記のとおりである。
POST /openapi/sms/rest/vl.0/startSmsNotification HTTP/1.1
Authorization: Basic XMVDTdx+
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"smsServiceActivationNumber":"tel:7777","reference": {"endpoint":"http://135.44. 0.88:8080/sms/ReceiptSMSNotification","interfaceName":"smsnotification","correlator":"6666"},"criteria":"a"}
次いでウェブ・アプリケーション６１０は、ＰＯＳＴオペレーションを変換システム６２０へ送信する（矢印８０１を参照されたい）。変換システム６２０は、ＨＴＴＰ ２００ ＯＫを用いてウェブ・アプリケーション６１０に返答する（矢印８０２を参照されたい）。

【0051】

この例においては、ＵＥ６４０のエンド・ユーザが、ウェブ・アプリケーション６１０に向けられたＭＯ ＳＭＳメッセージを作成すると想定されたい。これが発生した場合には、ＵＥ６４０は、ＲＰ−ＤＡＴＡフィールド内にＳＭＳメッセージをカプセル化しているＳＩＰ ＭＥＳＳＡＧＥ（それは、ＭＡＰ ＭＯ−Ｆｏｒｗａｒｄ−ＳＭ（ＳＭＳ−ＳＵＢＭＩＴ）を含む）を生成する。ＲＰ−Ｕｓｅｒ Ｄａｔａフィールドが、ＭＯ ＳＭＳメッセージに関するＳＭＳ−ＳＵＢＭＩＴ ＴＰＤＵを含む場合には（３ＧＰＰ ＴＳ ２３．０４０を参照されたい）、そのＲＰ−Ｕｓｅｒ Ｄａｔａは、表６において示されているパラメータを有することができる。

【0052】

【表6】

【0053】

次いでＵＥ６４０は、ＩＰ−ＳＭ−ＧＷ６３２およびＳ−ＣＳＣＦ６３４を通じてＳＩＰ ＭＥＳＳＡＧＥを変換システム６２０へ送信する（矢印８０３〜８０５を参照されたい）。変換システム６２０は、ＳＩＰ ２００ ＯＫを用いてＵＥ６４０に応答する（矢印８０６〜８０８を参照されたい）。

【0054】

ＳＩＰ ＭＥＳＳＡＧＥを受信した後に、変換システム６２０は、そのＳＩＰ ＭＥＳＳＡＧＥを、ＳＭＳメッセージをカプセル化しているＲＥＳＴｆｕｌ受信オペレーションに変換する。このＲＥＳＴｆｕｌ受信オペレーションは、ＳＭＳメッセージをカプセル化しているＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ）を含む。このＰＯＳＴオペレーションは、ユーザがオンラインであるときにＭＯ ＳＭＳメッセージを受信するためにウェブ・アプリケーション６１０において使用される。ＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ）の一例は、下記のとおりである。
POST /openapi/sms/rest/vl.0/receivedsmsnotification HTTP/1.1
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"senderAddress":"tel: [phone]", "smsServiceAxtivationNumber":"7777","message":"Hello, Bob", "dateTime":"2010-12-25T18:30:15"}
変換システム６２０は、ＰＯＳＴオペレーションをウェブ・アプリケーション６１０へ送信する（矢印８０９を参照されたい）。ウェブ・アプリケーション６１０は、ＨＴＴＰ ２００ ＯＫを用いて変換システム６２０に返答する（矢印８１０を参照されたい）。

【0055】

ＵＥ６４０からのオリジナルのＳＩＰ ＭＥＳＳＡＧＥは、組み込まれている配信ステータス要求をＴＰ−ＳＲＲ内に含んでいた（表６を参照されたい）。したがって、変換システム６２０は、ＭＯ ＳＭＳメッセージに関する配信ステータス・レポートを要求するＧＥＴ（ＧｅｔＳｍｓＤｅｌｉｖｅｒｙＳｔａｔｕｓ）オペレーションを生成する。ＧＥＴオペレーション（ＧｅｔＳｍｓＤｅｌｉｖｅｒｙＳｔａｔｕｓ）の一例は、下記のとおりである。
GET /openapi/sms/rest/v1.0/registration/7777/messages HTTP/1.1
Authorization: Basic XMVDTdx+
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatel-lucent.com
Accept application/json
Content-Length: 0
次いで変換システム６２０は、ＧＥＴオペレーション（ＧｅｔＳｍｓＤｅｌｉｖｅｒｙＳｔａｔｕｓ）をウェブ・アプリケーション６１０へ送信する（矢印８１１を参照されたい）。ウェブ・アプリケーション６１０は、ステータス情報を含むＨＴＴＰ ２００ ＯＫを用いて変換システム６２０に返答する（矢印８１２を参照されたい）。ＨＴＴＰ ２００ ＯＫの一例は、下記のとおりである。
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: (...)
{"DeliveryInformation":[{"address":"tel:[phone]","deliveryStatus": "DeliveredToNetwork"}]}

【0056】

次いでウェブ・アプリケーション６１０は、ＭＯ ＳＭＳメッセージが受信された旨の肯定応答としてＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＲｅｃｅｐｔｉｏｎ）を変換システム６２０へ送信する（矢印８１３を参照されたい）。ＰＯＳＴオペレーションの一例は、下記のとおりである。
POST /openapi/sms/rest/vl.0/receivedsmsnotification HTTP/1.1
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"senderAddress":"te1: [phone]",
"smsServiceActivationNumber":"7777","message":"Hello, Bob",
"dateTime": "2010-12-25T18:30:30"}

【0057】

変換システム６２０は、ＨＴＴＰ ２００ ＯＫを用いてウェブ・アプリケーション６１０に返答する（矢印８１４を参照されたい）。

【0058】

ウェブ・アプリケーション６１０からステータス情報を入手した後に、変換システム６２０は、下記のように、そのステータス情報をＩＭＳネットワーク６３０および／またはＵＥ６４０に提供する。ウェブ・アプリケーション６１０からのＰＯＳＴオペレーション（矢印８１３を参照されたい）は、ＭＯ ＳＭＳメッセージに関する配信ステータス・レポートを含んでいた。したがって、変換システム６２０は、ＰＯＳＴオペレーションを、ステータス情報を含むＳＩＰ ＭＥＳＳＡＧＥに変換する。この時点でのステータス情報は、ＭＯ ＳＭＳメッセージを搬送したオリジナルのＳＩＰ ＭＥＳＳＡＧＥに関するものである。変換システム６２０は、そのステータス情報をＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＡＣＫ内に組み込み、そのステータス情報を伴うＳＩＰ ＭＥＳＳＡＧＥをＵＥ６４０へ送信する（矢印８１５〜８１７を参照されたい）。ＵＥ６４０は、ＳＩＰ ２００ ＯＫを用いて変換システム６２０に返答する（矢印８１８〜８２０を参照されたい）。

【0059】

ＵＥ６４０が、ＭＯ ＳＭＳメッセージに関する配信ステータス・レポートを要求したため、ウェブ・アプリケーション６１０はまた、ＭＯ ＳＭＳメッセージがユーザへ成功裏に配信されたかどうかを判定する。ＭＯ ＳＭＳメッセージがユーザへ成功裏に配信された場合には、ウェブ・アプリケーション６１０は、ＭＯ ＳＭＳメッセージに関するステータス情報（すなわち、配信レシート）を生成し、そのステータス情報をＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ）内に挿入する。ＰＯＳＴオペレーションの一例は、下記のとおりである。
POST /openapi/sms/rest/vl.0/deliveryreceiptnotification HTTP/1.1
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatle-lucent.com
Content-Type: application/json
Content-Length: (...)
{"requestedlD":"123456789","deliveryInformation":{"address: "tel:
[phone]","deliveryStatus":"deliveredToNetwork"}}
次いでウェブ・アプリケーション６１０は、ＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ）を変換システム６２０へ送信する（矢印８２１を参照されたい）。変換システム６２０は、ＨＴＴＰ ２００ ＯＫを用いてウェブ・アプリケーション６１０に返答する（矢印８２２を参照されたい）。

【0060】

変換システム６２０は、ＰＯＳＴオペレーション（ＮｏｔｉｆｙＳｍｓＤｅｌｉｖｅｒｙＲｅｃｅｉｐｔ）要求を、ＭＯ ＳＭＳメッセージに関するステータス情報を含むＳＩＰ ＭＥＳＳＡＧＥに変換する。そのステータス情報は、ＭＡＰ Ｒｅｐｏｒｔ−ＳＭ−Ｄｅｌｉｖｅｒｙ−Ｓｔａｔｕｓ（ＳＭＳ−ＳＴＡＴＵＳ−ＲＥＰＯＲＴ）内など、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＤＡＴＡ／Ｓｔａｔｕｓ内に組み込まれる。次いで変換システム６２０は、ＩＰ−ＳＭ−ＧＷ６３２およびＳ−ＣＳＣＦ６３４を通じてＳＩＰ ＭＥＳＳＡＧＥをＵＥ６４０へ送信する（矢印８２３〜８２５を参照されたい）。ＵＥ６４０は、ＳＩＰ ２００ ＯＫを用いて変換システム６２０に返答する（矢印８２６〜８２８を参照されたい）。図８が、ＳＭＳ配信において使用されるメッセージングの概観を提供しているが、ＭＯ ＳＭＳメッセージと、その関連付けられているステータス情報とを配信するために使用されるさらなるメッセージングが存在することが可能である。

【0061】

図９は、例示的な一実施形態における、ＭＯ ＳＭＳメッセージに関する別のコール・フローを示すメッセージ図である。図９は、ＭＯ ＳＭＳメッセージが送信されるときにウェブ・アプリケーション６１０のユーザがオフラインである場合のシナリオを示している。図９におけるコール・フローは、ＭＯ ＳＭＳメッセージをカプセル化しているＳＩＰ ＭＥＳＳＡＧＥをＵＥ６４０が変換システム６２０に送信するところでは、図８と類似している（矢印９０３〜９０５を参照されたい）。その時点ではウェブ・アプリケーション６１０のユーザがオフラインであるため、変換システム６２０は、ＭＯ ＳＭＳメッセージを格納する。変換システム６２０は、ＩＰ−ＳＭ−ＧＷ６３２およびＳ−ＣＳＣＦ６３４を通じて、ステータス情報を含むＳＩＰ ＭＥＳＳＡＧＥをＵＥ６４０へ送信する（矢印９１０〜９１２を参照されたい）。この時点でのステータス情報は、ＭＯ ＳＭＳメッセージを搬送したオリジナルのＳＩＰ ＭＥＳＳＡＧＥに関するものであり、ＳＩＰ ＭＥＳＳＡＧＥのＲＰ−ＡＣＫ内に組み込まれている。ＵＥ６４０は、ＳＩＰ ２００ ＯＫを用いて変換システム６２０に返答する（矢印９１３〜９１５を参照されたい）。

【0062】

ユーザがウェブ・アプリケーション６１０にログインしたときに、ウェブ・アプリケーション６１０は、そのユーザのために格納されているＭＯ ＳＭＳメッセージ（がある場合には、それらのＭＯ ＳＭＳメッセージ）を取り出すためのＧＥＴ（ＧｅｔＲｅｃｅｉｖｅｄＳｍｓ）オペレーションを生成する。ＧＥＴオペレーション（ＧｅｔＲｅｃｅｉｖｅｄＳｍｓ）の一例は、下記のとおりである。
GET /openapi/sms/rest/v1.0/registration/7777/messages HTTP/1.1
Authorization: Basic XMVDTdx+
X-Partner-Id: [e-mail]
X-Service-Id: APP123@ACP123
Host: acp.alcatel-lucent.com
Accept application/json
Content-Length: 0
次いでウェブ・アプリケーション６１０は、ＧＥＴオペレーションを変換システム６２０へ送信する（矢印９１６を参照されたい）。変換システム６２０は、ユーザのために格納されているＭＯ ＳＭＳメッセージを識別し、その格納されているＭＯ ＳＭＳメッセージをウェブ・アプリケーション６１０のためのＲＥＳＴｆｕｌ受信オペレーションへと変換する。この例においては、ＲＥＳＴｆｕｌ受信オペレーションは、ＭＯ ＳＭＳメッセージをカプセル化しているＨＴＴＰ ２００ ＯＫである。ＨＴＴＰ ２００ ＯＫの一例は、下記のとおりである。
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: (...)
{"receivedSMS":[{"sendAddress":"tel:[phone]","smsServiceActivation
Number":"7777","message body":"Hello, Bob","DateTime":" 2010-12-25T18:30:30"}]}
次いで変換システム６２０は、ＨＴＴＰ ２００ ＯＫをウェブ・アプリケーション６１０へ送信する（矢印９１７を参照されたい）。そして図９におけるコール・フローは、図８の場合のようにＭＯテキスト・メッセージに関するステータス情報をＵＥ６４０に提供し続ける（矢印９１８〜９２５を参照されたい）。

【0063】

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

【0064】

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

【0065】

本明細書においては、具体的な実施形態が説明されたが、本発明の範囲は、それらの具体的な実施形態には限定されない。本発明の範囲は、添付の特許請求の範囲およびそれらのあらゆる均等物によって画定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】