(57)【特許請求の範囲】
【請求項１】
複数の異なるオペレーティングシステム(OS)のうちの1つで構成されるクライアントデバイス上で提供されるリッチコミュニケーションスイート(RCS)インターフェースを動作させる方法であって、
前記クライアントデバイス上の複数のRCSクライアントアプリケーションの中の所与のRCSクライアントアプリケーションから、所与のRCSアクセスプロトコルによるアプリケーション由来RCSシグナリングを受信するステップであって、前記所与のRCSアクセスプロトコルは、RCSクライアントアプリケーションと、前記複数の異なるOSのいずれかで構成されるクライアントデバイス上で提供される対応するRCSインターフェースとの間の通信のために、プラットフォームから独立して使用されるように構成される、受信するステップと、
前記受信されたアプリケーション由来RCSリソースシグナリングを、前記クライアントデバイスの前記OSのためのOS特有RCSアクセスプロトコルに準拠するOS特有RCSシグナリングに翻訳するステップであって、前記クライアントデバイスの前記OSのための前記OS特有RCSアクセスプロトコルは、前記複数の異なるOSからの1つまたは複数の他のOSによって用いられる1つまたは複数の他のOS特有RCSアクセスプロトコルとは異なる、翻訳するステップと、
前記翻訳済みRCSリソースシグナリングを、前記複数のRCSクライアントアプリケーションにRCSサービスを提供し、かつ前記OS特有RCSアクセスプロトコルに従って対話するように構成される前記クライアントデバイス上の1組のRCSリソースに送達するステップと
を含み、
前記アプリケーション由来RCSシグナリングはOS特有ラッピング内で前記RCSインターフェースに到着し、前記所与のRCSアクセスプロトコルに準拠する前記アプリケーション由来RCSシグナリングを抽出するために、前記OS特有ラッピングは前記RCSインターフェースによってアンラップされる、方法。
【請求項２】
複数の異なるオペレーティングシステム(OS)のうちの1つで構成されるクライアントデバイス上で提供されるリッチコミュニケーションスイート(RCS)インターフェースを動作させる方法であって、
前記クライアントデバイス上の複数のRCSクライアントアプリケーションにRCSサービスを提供するように構成される1組のRCSリソースから、OS特有RCSアクセスプロトコルによるアプリケーション終端RCSシグナリングを受信するステップであって、前記クライアントデバイスの前記OSのための前記OS特有RCSアクセスプロトコルは、前記複数の異なるOSからの1つまたは複数の他のOSによって用いられる1つまたは複数の他のOS特有RCSアクセスプロトコルとは異なる、受信するステップと、
前記受信されたアプリケーション終端RCSリソースシグナリングを所与のRCSアクセスプロトコルに準拠するRCSシグナリングに翻訳するステップであって、前記所与のRCSアクセスプロトコルは、RCSクライアントアプリケーションと、前記複数の異なるOSのいずれかで構成されるクライアントデバイス上で提供される対応するRCSインターフェースとの間の通信のために、プラットフォームから独立して使用されるように構成される、翻訳するステップと、
前記翻訳済みRCSリソースシグナリングを前記クライアントデバイス上の所与のRCSクライアントアプリケーションに送達するステップと
を含み、
前記クライアントデバイスの前記OSは、前記アプリケーション終端RCSシグナリングのラップされたバージョンが前記所与のRCSクライアントアプリケーションに到着するように、前記アプリケーション終端RCSシグナリングにOS特有ラッピングを適用し、前記所与のRCSクライアントアプリケーションは、前記所与のRCSアクセスプロトコルに準拠する前記アプリケーション終端RCSシグナリングを抽出するために、前記アプリケーション終端RCSシグナリングの前記ラップされたバージョンをアンラップするように要求される、方法。
【請求項３】
前記複数の異なるOSは異なるOSタイプおよび/または共通のOSタイプの異なるOSバージョンを含む、請求項1または2に記載の方法。
【請求項４】
前記異なるOSタイプは、ウインドウズ、iOSおよび/またはアンドロイドを含む、請求項3に記載の方法。
【請求項５】
前記共通のOSタイプの前記異なるOSバージョンは、ウインドウズ、iOSおよび/またはアンドロイドOSタイプの異なるバージョンに対応する、請求項4に記載の方法。
【請求項６】
前記所与のRCSアクセスプロトコルは、前記複数の異なるOSのいずれかにおいてプラットフォームから独立して使用されるように構成されるマルチOSプロトコルである、請求項1または2に記載の方法。
【請求項７】
前記アプリケーション終端RCSシグナリングは、
能力発見(CD)サービスを具体化すること、
既存のCDサービスに新たなCDリスナを追加すること、
前記既存のCDサービスから既存のCDリスナを除去すること、
前記既存のCDサービスを終了すること、
新たなインスタントメッセージング(IM)サービスを具体化すること、
既存のIMサービスに新たなIMリスナを追加すること、
前記既存のIMサービスから既存のIMリスナを除去すること、
前記既存のIMサービスを終了すること、
前記既存のIMサービスのための所与のIMを前記所与のRCSクライアントアプリケーションと交換すること、または
前記既存のIMサービスを終了すること
のうちの1つまたは複数に関連付けられる、請求項2に記載の方法。
【請求項８】
前記RCSインターフェースは、プレゼンスまたはオープンモバイルアライアンス(OMA)コンバージドIPメッセージング(CPM)をサポートすることなく、RCSエンハンスト(RCS/E)をサポートするように構成される、請求項1または2に記載の方法。
【請求項９】
前記RCSインターフェースは、プレゼンスおよび/またはオープンモバイルアライアンス(OMA)コンバージドIPメッセージング(CPM)をサポートするように構成される、請求項1または2に記載の方法。
【請求項１０】
前記RCSインターフェースは、分散サービスまたはローカルライブラリとして実施される、請求項1または2に記載の方法。
【請求項１１】
前記RCSインターフェースおよび前記所与のRCSクライアントアプリケーションは、前記クライアントデバイス内の別々の実行可能モジュールとして実現される、請求項1または2に記載の方法。
【請求項１２】
前記RCSインターフェースは、前記所与のRCSクライアントアプリケーションの実行が前記RCSインターフェースとともに生じ、前記受信するステップ、前記翻訳するステップおよび前記送達するステップが、前記RCSインターフェースおよび前記所与のRCSクライアントアプリケーションの共同実行の一部として生じるように、前記所与のRCSクライアントアプリケーション内に埋め込まれる、請求項1または2に記載の方法。
【請求項１３】
複数の異なるオペレーティングシステム(OS)のうちの1つで構成され、リッチコミュニケーションスイート(RCS)インターフェースを提供されるクライアントデバイスであって、
前記クライアントデバイス上の複数のRCSクライアントアプリケーションの中の所与のRCSクライアントアプリケーションから、所与のRCSアクセスプロトコルによるアプリケーション由来RCSシグナリングを受信するための手段であって、前記所与のRCSアクセスプロトコルは、RCSクライアントアプリケーションと、前記複数の異なるOSのいずれかで構成されるクライアントデバイス上で提供される対応するRCSインターフェースとの間の通信のために、プラットフォームから独立して使用されるように構成される、受信するための手段と、
前記受信されたアプリケーション由来RCSリソースシグナリングを、前記クライアントデバイスの前記OSのためのOS特有RCSアクセスプロトコルに準拠するOS特有RCSシグナリングに翻訳するための手段であって、前記クライアントデバイスの前記OSのための前記OS特有RCSアクセスプロトコルは、前記複数の異なるOSからの1つまたは複数の他のOSによって用いられる1つまたは複数の他のOS特有RCSアクセスプロトコルとは異なる、翻訳するための手段と、
前記翻訳済みRCSリソースシグナリングを、前記複数のRCSクライアントアプリケーションにRCSサービスを提供し、かつ前記OS特有RCSアクセスプロトコルに従って対話するように構成される前記クライアントデバイス上の1組のRCSリソースに送達するための手段と
を備え、
前記アプリケーション由来RCSシグナリングはOS特有ラッピング内で前記RCSインターフェースに到着し、前記所与のRCSアクセスプロトコルに準拠する前記アプリケーション由来RCSシグナリングを抽出するために、前記OS特有ラッピングは前記RCSインターフェースによってアンラップされる、クライアントデバイス。
【請求項１４】
複数の異なるオペレーティングシステム(OS)のうちの1つで構成され、リッチコミュニケーションスイート(RCS)インターフェースを提供されるクライアントデバイスであって、
前記クライアントデバイス上の複数のRCSクライアントアプリケーションにRCSサービスを提供するように構成される1組のRCSリソースから、OS特有RCSアクセスプロトコルによるアプリケーション終端RCSシグナリングを受信するための手段であって、前記クライアントデバイスの前記OSのための前記OS特有RCSアクセスプロトコルは、前記複数の異なるOSからの1つまたは複数の他のOSによって用いられる1つまたは複数の他のOS特有RCSアクセスプロトコルとは異なる、受信するための手段と、
前記受信されたアプリケーション終端RCSリソースシグナリングを所与のRCSアクセスプロトコルに準拠するRCSシグナリングに翻訳するための手段であって、前記所与のRCSアクセスプロトコルは、RCSクライアントアプリケーションと、前記複数の異なるOSのいずれかで構成されるクライアントデバイス上で提供される対応するRCSインターフェースとの間の通信のために、プラットフォームから独立して使用されるように構成される、翻訳するための手段と、
前記翻訳済みRCSリソースシグナリングを前記クライアントデバイス上の所与のRCSクライアントアプリケーションに送達するための手段と
を備え、
前記クライアントデバイスの前記OSは、前記アプリケーション終端RCSシグナリングのラップされたバージョンが前記所与のRCSクライアントアプリケーションに到着するように、前記アプリケーション終端RCSシグナリングにOS特有ラッピングを適用し、前記所与のRCSクライアントアプリケーションは、前記所与のRCSアクセスプロトコルに準拠する前記アプリケーション終端RCSシグナリングを抽出するために、前記アプリケーション終端RCSシグナリングの前記ラップされたバージョンをアンラップするように要求される、クライアントデバイス。
【請求項１５】
記憶された命令を含む非一時的コンピュータ可読記録媒体であって、複数の異なるオペレーティングシステム(OS)のうちの1つで構成され、リッチコミュニケーションスイート(RCS)インターフェースを提供されるクライアントデバイスによって実行されるときに、前記クライアントデバイスに請求項1〜12のいずれか一項に記載の方法を実行させる、非一時的コンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
米国特許法第119条に基づく優先権の主張
本特許出願は、2013年1月29日に出願された「CROSS-PLATFORM MODULE THAT IS SHARED BY CLIENT APPLICATIONS FOR ACCESS TO RICH COMMUNICATIONS SUITE RESOURCES ON A CLIENT DEVICE」と題する米国特許出願第61/758,136号に対する優先権を主張し、その特許出願は本発明の譲受人に譲渡されており、その全体を参照することによって本明細書に組み込まれている。
【０００２】
本発明の実施形態は、クライアントデバイス上でリッチコミュニケーションスイート(RCS)機能にアクセスするためにクライアントアプリケーションによって共有されるクロスプラットフォームモジュールに関する。
【背景技術】
【０００３】
ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、第2世代(2G)デジタルワイヤレス電話サービス(暫定の2.5Gおよび2.75Gネットワークを含む)、ならびに第3世代(3G)高速データ/インターネット対応ワイヤレスサービス、および第4世代(4G)サービス(たとえば、長期発展型(LTE)またはWiMax)を含む、様々な世代を通じて発展してきた。現在、セルラーシステムおよびパーソナル通信サービス(PCS)システムを含む、多くの様々なタイプのワイヤレス通信システムが使用されている。知られているセルラーシステムの例は、セルラーAnalog Advanced Mobile Phone System(AMPS)、および、符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時分割多元接続(TDMA)、TDMAのGlobal System for Mobile access(GSM(登録商標))変形に基づくデジタルセルラーシステムなどを含む。
【０００４】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)におけるリッチコミュニケーションスイート(RCS)は、IMSドメインにおいて最近になって開発されたサービスタイプである。RCSは一般的に1組の通信サービスを指しており、その通信サービスによって、クライアントデバイス(たとえば、モバイルデバイスまたは固定デバイス)が、そのアドレスブック内の対象相手の能力をリアルタイムに更新することができ、それゆえ、対象相手のリアルタイム能力に基づいて、ボイスオーバLTE(VoLTE)、ビデオ通話、インスタントメッセージング(IM)、ファイルまたは画像共有などの「リッチコミュニケーション」を可能にする。しかしながら、RCSサービスを実施するために、クライアントアプリケーションによって低レベルオペレーティングシステム(OS)リソースを使用することができるが、各クライアントアプリケーションは通常、クライアントアプリケーションが実行される特定のプラットフォーム上で動作するためにカスタマイズされなければならない。たとえば、アンドロイドOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なアンドロイド特有RCS OSリソースを利用するようにコード化される必要があり、ウインドウズOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なウインドウズ特有RCS OSリソースを利用するようにコード化される必要があり、iOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なiOS特有RCS OSリソースを利用するようにコード化される必要がある、などである。
【発明の概要】
【課題を解決するための手段】
【０００５】
一実施形態では、特定のOSまたはOSバージョンを実行するクライアントデバイスが、リッチコミュニケーションスイート(RCS)インターフェースを設けられる。RCSインターフェースは、RCSクライアントアプリケーションとRCSリソースとの間の対話を仲介する。RCSインターフェースは、RCSプロトコルを用いて、プラットフォームから独立して複数のRCSクライアントアプリケーションと対話し、RCSは、OS特有RCSアクセスプロトコルを用いてOS特有のやり方でRCSリソースと対話する。RCSインターフェースは、RCSプロトコルに準拠するアプリケーション由来RCSシグナリングを、RCSリソースに送達するためのOS特有RCSアクセスプロトコルに翻訳し、RCSインターフェースは同様に、OS特有RCSアクセスプロトコルに準拠するアプリケーション終端シグナリングを、RCSクライアントアプリケーションのうちの1つに送達するためのRCSアクセスプロトコルに翻訳する。
【０００６】
本発明の実施形態およびその付随する利点の多くのより完全な理解は、本発明を限定するためではなく単に例示するために提示される添付の図面とともに考察するときに、以下の詳細な説明を参照することによって、理解が深まるのに応じて容易に得られるであろう。
【図面の簡単な説明】
【０００７】
【図１】本発明の一実施形態によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図２】本発明の一実施形態によるユーザ機器(UE)の例を示す図である。
【図３】本発明の実施形態による、機能を実行するように構成された論理手段を含む通信デバイスを示す図である。
【図４】UEのための従来のRCSリッチコミュニケーションスイート(RCS)アーキテクチャのハイレベル斜視図である。
【図５Ａ】本発明の一実施形態による、UEのためのRCSアーキテクチャのハイレベル斜視図である。
【図５Ｂ】本発明の一実施形態による、アンドロイドRCSアーキテクチャの一例を示す図である。
【図５Ｃ】本発明の一実施形態による、ウインドウズRCSアーキテクチャの一例を示す図である。
【図６Ａ】本発明の一実施形態による、RCSクライアントアプリケーションから、共有RCSインターフェースを介して、関連付けられるUE上のオペレーティングシステム(OS)特有RCSリソースにRCSリソースシグナリングが搬送されるプロセスを示す図である。
【図６Ｂ】本発明の実施形態による、関連付けられるUE上のOS特有RCSリソースから、共有RCSインターフェースを介して、RCSクライアントアプリケーションにRCSリソースシグナリングが搬送されるプロセスを示す図である。
【図７Ａ】本発明の一実施形態による、図6A〜図6BのプロセスのアンドロイドOS特有の実施態様の例を示す図である。
【図７Ｂ】本発明の一実施形態による、図6A〜図6BのプロセスのウインドウズOS特有の実施態様の例を示す図である。
【発明を実施するための形態】
【０００８】
本発明の特定の実施形態を対象とする以下の説明および関連する図面において、本発明の態様が開示される。本発明の範囲から逸脱することなく、代替の実施形態が考案され得る。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素は詳細に説明されないか、または省略される。
【０００９】
「例示的」および/または「例」という用語は、本明細書では「例、事例、または例示としての役割を果たすこと」を意味するために使用される。本明細書で「例示的」および/または「例」として説明されるいかなる実施形態も、必ずしも他の実施形態よりも好ましいか、または有利であると解釈されるべきではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、論じられる特徴、利点または動作モードを含むことを要求しない。
【００１０】
さらに、多くの実施形態が、たとえばコンピューティングデバイスの要素によって実行されることになる一連の動作に関して説明される。本明細書において説明される様々な動作は、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つまたは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行できることは認識されよう。さらに、本明細書において説明されるこれらの一連の動作は、実行されると、関連するプロセッサに本明細書において説明されることになる機能を実行させる対応する1組のコンピュータ命令を記憶している、任意の形のコンピュータ可読記憶媒体内で完全に具現されるものと見なすことができる。したがって、本発明の様々な態様はいくつかの異なる形で具現することができ、そのすべてが、特許請求される主題の範囲内にそのすべてが入ると考えられる。さらに、本明細書において説明される実施形態ごとに、任意のそのような実施形態の対応する形は、本明細書において、たとえば、説明される動作を実行する「ように構成される論理手段」として説明される場合がある。
【００１１】
本明細書においてユーザ機器(UE)と呼ばれるクライアントデバイスは、モバイルであってもまたは固定されていてもよく、無線アクセスネットワーク(RAN)と通信することができる。本明細書において使用されるとき、「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」またはUT、「モバイル端末」、「移動局」、およびそれらの変化形と交換可能に参照される場合がある。一般に、UEは、RANを介してコアネットワークと通信することができ、コアネットワークを通じてインターネットなどの外部ネットワークに接続することができる。当然、UEには、有線アクセスネットワーク、(たとえば、IEEE802.11などに基づく)WiFiネットワークなどの、コアネットワークおよび/またはインターネットに接続する他の機構も考えられる。UEは、限定はしないが、PCカード、コンパクトフラッシュ(登録商標)デバイス、外部または内蔵モデム、あるいはワイヤレスまたは有線の電話などを含むいくつかのタイプのデバイスのうちのいずれかによって具現することができる。UEが信号をRANに送ることができる通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆制御チャネル、アクセスチャネルなど)と呼ばれる。RANが信号をUEに送ることができる通信リンクは、ダウンリンクチャネルまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書において用いられるとき、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指すことができる。
【００１２】
図1は、本発明の一実施形態によるワイヤレス通信システム100のハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100はUE1...Nを含む。UE1...Nは、セルラー電話、携帯情報端末(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含むことができる。たとえば、図1において、UE1...2は発呼側セルラー電話として示され、UE3...5はタッチスクリーンセルラー電話またはスマートフォンとして示され、UE NはデスクトップコンピュータまたはPCとして示されている。
【００１３】
図1を参照すると、UE1...Nは、図1にエアインターフェース104、106、108および/または直接有線接続として示されている物理通信インターフェースまたはレイヤを介してアクセスネットワーク(たとえば、RAN120、アクセスポイント125など)と通信するように構成される。エアインターフェース104および106は、所与のセルラー通信プロトコル(たとえば、CDMA、EVDO、eHRPD、GSM(登録商標)、EDGE、W-CDMA(登録商標)、LTEなど)に準拠することができ、一方、エアインターフェース108はワイヤレスIPプロトコル(たとえば、IEEE802.11)に準拠することができる。RAN120は、エアインターフェース104および106などのエアインターフェースを介してUEをサービングする複数のアクセスポイントを含む。RAN120内のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、Node B、eNode Bなどと呼ぶことができる。これらのアクセスポイントは、地上アクセスポイント(もしくは地上局)または衛星アクセスポイントとすることができる。RAN120は、RAN120によってサービングされるUEとRAN120または異なるRANによってサービングされる他のUEとの間の回線交換(CS)呼を完全にブリッジングすることを含む様々な機能を実行することができ、かつインターネット175などの外部ネットワークとのパケット交換(PS)データの交換を仲介することもできるコアネットワーク140に接続するように構成される。インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上図1には示されていない)を含む。図1において、UE Nはインターネット175に直接接続する(すなわち、WiFiまたは802.11ベースネットワークのイーサネット(登録商標)接続を介するなど、コアネットワーク140から離れている)ように示されている。それによって、インターネット175は、コアネットワーク140を介してUE NとUE1...Nとの間のパケット交換データ通信をブリッジングするように機能することができる。図1には、RAN120から離れているアクセスポイント125も示されている。アクセスポイント125は、コアネットワーク140とは無関係に(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)インターネット175に接続される場合がある。エアインターフェース108は、一例ではIEEE802.11などのローカルワイヤレス接続を介してUE4またはUE5にサービングすることができる。UE Nは、一例において(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータ用の)アクセスポイント125自体に相当することができるモデムまたはルータへの直接接続のような、インターネット175への有線接続を含むデスクトップコンピュータとして示される。
【００１４】
図1を参照すると、サーバ170は、インターネット175、コアネットワーク140、またはその両方に接続されるように示される。サーバ170は、構造的に別々の複数のサーバとして実現することができるか、または代替的には単一のサーバに対応することができる。以下にさらに詳しく説明されるように、サーバ170は、コアネットワーク140および/またはインターネット175を介してサーバ170に接続することのできるUEに対して1つまたは複数の通信サービス(たとえば、Voice-over-Internet Protocol(VolP)セッション、Push-to-Talk(PTT)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなど)をサポートするように、および/またはUEにコンテンツ(たとえば、ウェブページダウンロード)を提供するように構成される。
【００１５】
図2は、本発明の実施形態によるUE(すなわち、クライアントデバイス)の例を示す。図2を参照すると、UE200Aは発呼側電話として示され、UE200Bはタッチスクリーンデバイス(たとえば、スマートフォン、タブレットコンピュータなど)として示される。図2に示されるように、UE200Aの外部ケーシングは、当技術分野で知られているように、数ある構成要素の中でも、アンテナ205A、ディスプレイ210A、少なくとも1つのボタン215A(たとえば、PTTボタン、電源ボタン、音量調節ボタンなど)、キーパッド220Aによって構成される。同様に、UE200Bの外部ケーシングも、当技術分野で知られているように、数ある構成要素の中でも、タッチスクリーンディスプレイ205B、周辺ボタン210B、215B、220B、および225B(たとえば、電力調節ボタン、音量または振動調節ボタン、飛行機モードトグルボタンなど)、少なくとも1つのフロントパネルボタン230B(たとえば、Homeボタン)によって構成される。UE200Bの一部として明示されないが、UE200Bは、限定はしないが、WiFiアンテナ、セルラーアンテナ、衛星位置決めシステム(SPS)アンテナ(たとえば、全地球測位システム(GPS)アンテナ)などを含む、1つもしくは複数の外部アンテナ、および/またはUE200Bの外部ケーシングに内蔵された1つまたは複数の内蔵アンテナを含むことができる。
【００１６】
UE200AおよびUE200BなどのUEの内部構成要素は、異なるハードウェア構成によって具現することができるが、内部ハードウェア構成要素のための基本的なハイレベルUE構成は図2にプラットフォーム202として示されている。プラットフォーム202は、最終的にコアネットワーク140、インターネット175、および/または他のリモートサーバおよびネットワーク(たとえば、アプリケーションサーバ170、ウェブURLなど)から得ることのできるRAN120から送信されたソフトウェアアプリケーション、データ、および/またはコマンドを受信し、実行することができる。また、プラットフォーム202は、ローカルに記憶されたアプリケーションを、RANと対話することなく独立して実行することができる。プラットフォーム202は、特定用途向け集積回路(ASIC)208または他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合される送受信機206を含むことができる。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212内の任意の常駐プログラムとのインターフェースを構成するアプリケーションプログラミングインターフェース(API)210レイヤを実行する。メモリ212は、読取り専用メモリもしくはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通する任意のメモリから構成することができる。プラットフォーム202は、メモリ212内でアクティブに使用されないアプリケーションおよび他のデータを記憶することができるローカルデータベース214も含むことができる。ローカルデータベース214は、一般的にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。
【００１７】
したがって、本発明の一実施形態は、本明細書において説明された機能を実行する能力を含むUE(たとえば、UE200A、UE200Bなど)を含むことができる。当業者によって理解されるように、様々な論理要素は、本明細書において開示される機能を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せにおいて具現される。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協調的に用いて、本明細書において開示される様々な機能をロード、記憶および実行することができ、したがって、これらの機能を実行するための論理手段は様々な要素に分散させることができる。代替的には、機能は1つの個別構成要素に組み込むことができる。したがって、図2のUE200AおよびUE200Bの特徴は単に例示であると見されるべきであり、本発明は図示される特徴または構成に限定されない。
【００１８】
UE200Aおよび/またはUE200BとRAN120との間のワイヤレス通信は、符号分割多元接続(CDMA)、W-CDMA(登録商標)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、GSM(登録商標)、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで用いることができる他のプロトコルのような、様々な技術に基づくことができる。先に論じられ、当該技術分野において知られているように、音声送信、および/またはデータは、様々なネットワークおよび構成を用いてRANからUEに送信することができる。したがって、本明細書において提供される例示は、本発明の実施形態を限定することを意図するものではなく、本発明の実施形態の態様の説明を助けるためのものにすぎない。
【００１９】
図3は、機能を実行するように構成される論理手段を含む通信デバイス300を示す。通信デバイス300は、限定はしないが、UE200Aまたは200B、RAN120の任意の構成要素、コアネットワーク140の任意の構成要素、コアネットワーク140および/またはインターネット175に結合された任意の構成要素(たとえば、サーバ170)などを含む、上記の通信デバイスのうちのいずれかに対応することができる。したがって、通信デバイス300は、図1のワイヤレス通信システム100を介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応することができる。
【００２０】
図3を参照すると、通信デバイス300は、情報を受信および/または送信するように構成される論理手段305を含む。一例では、通信デバイス300がRAN120内のワイヤレス通信デバイス(たとえば、UE200AもしくはUE200B、AP125、BS、Node BまたはeNodeB)に対応する場合には、情報を受信および/または送信するように構成される論理手段305は、ワイヤレス送受信機および関連ハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)のようなワイヤレス通信インターフェース(たとえば、Bluetooth(登録商標)、WiFi、2G、CDMA、W-CDMA(登録商標)、3G、4G、LTEなど)を含むことができる。別の例では、情報を受信および/または送信するように構成される論理手段305は、ワイヤード通信インターフェース(たとえば、それを通してインターネット175にアクセスすることができるシリアル接続、USBまたはファイアワイヤ接続、イーサネット(登録商標)接続など)に対応することができる。したがって、通信デバイス300が、何らかのタイプのネットワークベースのサーバ(たとえば、サーバ170など)に対応する場合には、情報を受信および/または送信するように構成される論理手段305は、一例では、イーサネット(登録商標)プロトコルによってネットワークベースのサーバを他の通信エンティティに接続するイーサネット(登録商標)カードに対応することができる。さらなる一例では、情報を受信および/または送信するように構成される論理手段305は、通信デバイス300が、それによってそのローカル環境を監視することができる感知または測定ハードウェア(たとえば、加速度計、温度センサ、光センサ、ローカルRF信号を監視するためのアンテナなど)を含むことができる。情報を受信および/または送信するように構成される論理手段305は、実行されるときに、情報を受信および/または送信するように構成される論理手段305の関連ハードウェアがその受信および/または送信機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を受信および/または送信するように構成される論理手段305は、ソフトウェアだけに対応するのではなく、情報を受信および/または送信するように構成される論理手段305は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００２１】
図3を参照すると、通信デバイス300は、情報を処理するように構成される論理手段310をさらに含む。一例では、情報を処理するように構成される論理手段310は、少なくともプロセッサを含むことができる。情報を処理するように構成される論理手段310によって実行され得るタイプの処理の例示的な実施態様は、限定はしないが、判断を行うこと、接続を確立すること、異なる情報オプション間で選択を行うこと、データに関係する評価を実行すること、測定動作を実行するために通信デバイス300に結合されたセンサと対話すること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど、異なるプロトコル間で)変換することなどを含む。たとえば、情報を処理するように構成される論理手段310に含まれるプロセッサは、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、ASIC、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタロジック、個別ハードウェア構成要素、または本明細書において説明される機能を実行するように設計されたそれらの任意の組合せに対応することができる。汎用プロセッサはマイクロプロセッサとすることができるが、代替形態では、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることもできる。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実現することもできる。情報を処理するように構成される論理手段310は、実行されるときに、情報を処理するように構成される論理手段310の関連ハードウェアがその処理機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を処理するように構成される論理手段310は、ソフトウェアだけに対応するのではなく、情報を処理するように構成される論理手段310は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００２２】
図3を参照すると、通信デバイス300は、情報を記憶するように構成される論理手段315をさらに含む。一例では、情報を記憶するように構成される論理手段315は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含むことができる。たとえば、情報を記憶するように構成される論理手段315に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当該技術分野において知られている任意の他の形の記憶媒体に対応することができる。情報を記憶するように構成される論理手段315は、実行されるときに、情報を記憶するように構成される論理手段315の関連ハードウェアがその記憶機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を記憶するように構成される論理手段315は、ソフトウェアだけに対応するのではなく、情報を記憶するように構成される論理手段315は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００２３】
図3を参照すると、通信デバイス300は、オプションで、情報を提示するように構成される論理手段320をさらに含む。一例では、情報を提示するように構成される論理手段320は、少なくとも出力デバイスおよび関連ハードウェアを含むことができる。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI(登録商標)のようなビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカー、マイクロフォンジャック、USB、HDMI(登録商標)のようなオーディオ情報を搬送することができるポートなど)、振動デバイス、および/または、情報が出力のためにフォーマットされる際、または通信デバイス300のユーザもしくは操作者によって実際に出力される際の手段となり得る任意の他のデバイスを含み得る。たとえば、通信デバイス300が図2に示されるようなUE200AまたはUE200Bに対応する場合には、情報を提示するように構成される論理手段320は、UE200Aのディスプレイ210AまたはUE200Bのタッチスクリーンディスプレイ205Bを含むことができる。さらなる一例では、情報を提示するように構成される論理手段320は、ローカルユーザを有しないネットワーク通信デバイス(たとえば、ネットワークスイッチ、またはルータ、サーバ170のようなリモートサーバなど)のようないくつかの通信デバイスでは省くことができる。また、情報を提示するように構成される論理手段320は、実行されるときに、情報を提示するように構成される論理手段320の関連ハードウェアがその提示機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を提示するように構成される論理手段320は、ソフトウェアだけに対応するのではなく、情報を提示するように構成される論理手段320は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００２４】
図3を参照すると、通信デバイス300は、オプションで、ローカルユーザ入力を受信するように構成される論理手段325をさらに含む。一例では、ローカルユーザ入力を受信するように構成される論理手段325は、少なくともユーザ入力デバイスおよび関連ハードウェアを含むことができる。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、またはマイクロフォンジャックなど、オーディオ情報を搬送することができるポートなど)、および/または情報がそれによって通信デバイス300のユーザもしくはオペレータから受信され得る任意の他のデバイスを含むことができる。たとえば、通信デバイス300が図2に示されるようなUE200AまたはUE200Bに対応する場合には、ローカルユーザ入力を受信するように構成される論理手段325は、キーパッド220A、ボタン215Aまたは210B〜225Bのうちのいずれか、タッチスクリーンディスプレイ205Bを含むことができる。さらなる一例では、ローカルユーザ入力を受信するように構成される論理手段325は、ローカルユーザを有しないネットワーク通信デバイス(たとえば、ネットワークスイッチ、またはルータ、サーバ170のようなリモートサーバなど)のようないくつかの通信デバイスでは省くことができる。また、ローカルユーザ入力を受信するように構成される論理手段325は、実行されるときに、ローカルユーザ入力を受信するように構成される論理手段325の関連ハードウェアがその入力受信機能を実行できるようにするソフトウェアも含むことができる。しかしながら、ローカルユーザ入力を受信するように構成される論理手段325は、ソフトウェアだけに対応するのではなく、ローカルユーザ入力を受信するように構成される論理手段325は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００２５】
図3を参照すると、305〜325の構成される論理手段は、図3では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理手段がその機能を実行するためのハードウェアおよび/またはソフトウェアは、部分的に重複できることは理解されよう。たとえば、305〜325の構成される論理手段の機能を容易にするために用いられる任意のソフトウェアを、情報を記憶するように構成された論理315に関連する非一時的メモリに記憶することができ、それにより、305〜325の構成される論理手段は各々、その機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成される論理手段315によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成される論理手段のうちの1つに直接関連付けられるハードウェアは、時々、他の構成される論理手段によって借用または使用され得る。たとえば、情報を処理するように構成される論理手段310のプロセッサは、データを、情報を受信および/または送信するように構成される論理手段305によって送信される前に、適切な形式にフォーマットすることができ、それにより、情報を受信および/または送信するように構成される論理手段305は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成される論理手段310に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。
【００２６】
概して、別段に明示的に記載されていない限り、本開示全体にわたって使用される「ように構成される論理手段」という言い回しは、ハードウェアによって少なくとも部分的に実装される実施形態を引き合いに出すことを意図しており、ハードウェアから独立しているソフトウェアだけの実施態様に位置づけることを意図するものではない。様々なブロックにおける構成される論理手段または「ように構成される論理手段」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書において説明される機能を(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実行する能力を指すことは理解されよう。したがって、様々なブロックにおいて示されるような、構成される論理手段または「ように構成される論理手段」は、「論理手段」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるとは限らない。様々なブロック内の論理手段間の他の対話または協働が、以下でより詳細に説明される実施形態の検討から、当業者には明らかになるであろう。
【００２７】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)におけるリッチコミュニケーションスイート(RCS)は、IMSドメインにおいて最近になって開発されたサービスタイプである。RCSは一般的に1組の通信サービスを指しており、その通信サービスによって、クライアントデバイス(たとえば、モバイルデバイスまたは固定デバイス)が、そのアドレスブック内の対象相手の能力をリアルタイムに更新することができ、それゆえ、「リッチコミュニケーション」を可能にする。これは、対象相手のリアルタイム能力に基づく、たとえば、ボイスオーバLTE(VoLTE)、ビデオ通話、インスタントメッセージング(IM)、ファイルまたは画像共有などを含むことができる。
【００２８】
RCSサービスを実施するために、クライアントアプリケーションによって低レベルオペレーティングシステム(OS)リソースを使用することができるが、各クライアントアプリケーションは通常、クライアントアプリケーションが実行される特定のプラットフォーム上で動作するためにカスタマイズされなければならない。たとえば、アンドロイドOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なアンドロイド特有RCS OSリソースを利用するようにコード化される必要があり、ウインドウズOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なウインドウズ特有RCS OSリソースを利用するようにコード化される必要があり、iOSデバイス上で動作するために構成されたクライアントアプリケーションは、その開発者によって、任意の入手可能なiOS特有RCS OSリソースを利用するようにコード化される必要がある、などである。また、OS(たとえば、iOS、アンドロイドなど)の異なるバージョンを有するクライアントデバイス上で動作するために構成されたクライアントアプリケーションは、そのバージョンのために入手可能な任意のOS特有RCS OSリソースを利用するために、その開発者によってコード化される必要がある(たとえば、iOS6およびiOS7は異なるRCSアクセスプロトコルを有する場合があり、iOSがバージョン6からバージョン7に移行するときに、iOS Appsを更新する必要がある)。したがって、本明細書において用いられるときに、「OS特有」は、特定のタイプのOS(他のOSタイプと区別される)への参照として使用することができるか、または代替的には、特定のOSの特定のバージョン(他のOSタイプと、および同じOSタイプの他のバージョンと区別される)への参照として使用することができる。
【００２９】
今日、消費者は、充実した通信の能力および見込みを体験しつつある。ほんの数例であるが、動的に変化するステータスおよびオンライン能力を示すバディリスト、異なるメッセージングオプション、およびコンテンツを追加する可能性を導入したサービスおよびアプリケーションがRCS体験の例である。これらの能力は、デバイスとネットワークとの間のオープンコミュニケーションを用いて、PCとモバイルデバイス(いずれも、本明細書においてUEと呼ぶことができる)の両方において利用可能である。
【００３０】
図4は、UEのための従来のRCSアーキテクチャ400のハイレベル斜視図を示す。図4に示される従来のRCSアーキテクチャ400は、すべてのOSタイプに当てはまり、RCSアーキテクチャ400は、アンドロイドOS、ウインドウズOS、iOS、上記のOSタイプのいずれかの異なるバージョンなどによって構成されるUEにおいて実施することができる。
【００３１】
図4を参照すると、RCSアーキテクチャ400は、UE上のOS特有RCSリソース420に直接アクセスするように構成される複数のクライアントアプリケーション405〜415(またはApp1...N)を含む。言い換えると、App1...Nは、それらのアプリケーションが展開されるUEのOS上のRCSリソースにアクセスするために必要とされる特定のRCSリソースシグナリングを実施するために、それぞれの開発者によって書かれ、テストされたコードを含む。一般的に、RCSリソースがアクセスされるやり方はOSに特有であるので、アンドロイドOSデバイス上のインスタントメッセージングアプリケーションは、ウインドウズOSデバイス上で必要とされるのと同じシグナリングプロトコルを用いてRCSリソースにアクセスすることはできない。OS特有RCSリソース420は、通信インターフェース425(たとえば、WLAN MODEM、セルラーMODEMなど)と対話することができ、その通信インターフェースを通して、RAN120またはAP125が、ネットワーク側のRCSリソースと対話するためにアクセスされ得る。図4に示されるRCSアーキテクチャ400は、少なくとも1つの実施態様においてマルチプロセッサ環境に対応することができ、それにより、処理タスクは、アプリケーションプロセッサと、クライアントデバイスまたはUE上の別のモデムプロセッサとの間で分割される。
【００３２】
図5Aは、本発明の一実施形態による、UEのためのRCSアーキテクチャ500Aのハイレベル斜視図を示す。図5Aに示されるRCSアーキテクチャ500Aは、すべてのOSタイプに当てはまる。結果として、RCSアーキテクチャ500Aは、たとえば、アンドロイドOS、ウインドウズOS、iOS v6.0、iOS v7.0などを含む、様々なOSタイプおよび/またはOSバージョンによって構成されるUE上で実施することができる。他のOSタイプおよび/またはバージョンも利用することができる。
【００３３】
図5Aを参照すると、RCSアーキテクチャ500Aは、OS特有RCSリソース525Aがそこを通してアクセスされる共有RCSインターフェース520Aにアクセスするように構成される複数のクライアントアプリケーション505A〜515A(またはApp1...N)を含む。一例では、共有RCSインターフェース520Aは、共通のプロトコル(「クロスプラットフォームRCSインターフェースプロトコル」)を介してApp1...Nが利用可能である1組のAPIとして実装することができる。共有RCSインターフェースと通信するためにApp1...Nによって用いられるクロスプラットフォームRCSインターフェースプロトコルは、クライアントデバイスのOSタイプ、OSバージョンまたはプラットフォームに関係なく同じとすることができる。したがって、一例では、アンドロイドOSデバイス上で実施するためのインスタントメッセージングアプリケーションを開発する開発者は、iOSデバイスまたはウインドウズOSデバイス上でインスタントメッセージングアプリケーションを実施するために再利用される、RCSアクセスに関連するコードを書くことができる。共有RCSインターフェース520A自体が、App1...Nと共有RCSインターフェース520Aとの間の通信のために、OS特有RCSリソースアクセスプロトコルをクロスプラットフォームRCSインターフェースプロトコルにマッピングするように構成されるので、開発者はこのようにしてクロスプラットフォームコードを生成することができる。したがって、共有RCSインターフェース520Aは、プラットフォーム間で異なるように実施されるが、RCSクライアントアプリケーションのための開発プロセスを簡単にするために、クロスプラットフォームRCSリソースプロトコルは同じに維持される。言い換えると、図4とは異なり、図5AのApp1...Nは、それらのアプリケーションが展開されるUEのOS上のRCSリソースにアクセスするために必要とされる特定のRCSリソースシグナリングプロトコルで、それぞれの開発者によって各々ハードコード化される必要はなく、代わりに、共有RCSインターフェース520Aとの対話を介して共有クロスプラットフォームRCSリソースアクセスプロトコルを用いることができ、低レベルOS特有RCSプロトコル変換のために共有RCSインターフェース520Aに頼ることができる。
【００３４】
図5Aを参照すると、OS特有RCSリソース525Aは、通信インターフェース530A(たとえば、WLAN MODEM、セルラーMODEMなど)と対話することができ、その通信インターフェースを通して、RAN120またはAP125が、ネットワーク側のRCSリソースと対話するためにアクセスされ得る。図5Aに示されるRCSアーキテクチャ500Aは、少なくとも1つの実施態様においてマルチプロセッサ環境に対応することができ、それにより、処理タスクは、アプリケーションプロセッサと、UE上の別のモデムプロセッサとの間で分割される。
【００３５】
いくつかの実施形態によれば、App1...Nは、共有RCSインターフェース520Aに従って動作するために、その動作を支配する特定の規則に従って動作することができる。これらの規則は、以下の1つまたは複数を含むことができる。
・ブートアップ時のApp1...N。
・サービス開始/中止機能は、App1...Nによって制御することはできない。
・すべてのサービスがリスナという概念を有することになる。リスナはそのサービスのためのネットワークレベル通知のためにApp1...Nを更新する。
・すべてのサービスが、セッションおよびセッションリスナという概念を有することになる。
・セッションライフサイクルが、1つのサービスのライフサイクル内に維持される。
・セッションリスナは、App1...Nへのネットワークレベル通知のために用いられる。
・(i)どのPDNを使用すべきか、および(ii)基本構成を得る場所(たとえば、HTTP、SIMまたはデバイス上のハードコード化された不揮発性メモリ)のような、RCSのための共通構成。
【００３６】
さらに、バージョニングが、共有RCSインターフェース520Aにとって重要な役割を果たす場合がある。たとえば、共有RCSインターフェース520Aを構成する第1の1組のAPIがバージョン1として指示される場合がある。バージョン1RCSインターフェースは、RCSエンハンスト(RCS/E)に基づくことができ、プレゼンスまたはオープンモバイルアライアンス(OMA)コンバージドIPメッセージング(CPM)サポートを有しない。共有RCSインターフェース520Aを構成する第2の1組のAPIがバージョン2として指示される場合があり、プレゼンスサポートおよび/またはOMA CPMサポートを伴う。この例では、「実行時」にApp1...Nのうちの1つが、その初期化前に、自らの初期化のためにデバイス上の共有RCSインターフェース520AによりどのAPIセットバージョンがサポートされるかを判断する必要がある場合には、その判断は、サポートされるバージョンセットに関してデバイスに問い合わせることによって達成することができる。「APIセット」のバージョンは、1人のオペレータが異なるRCS特徴、たとえば、X-特徴対Y-特徴の使用を規定する実世界環境も計算に入れることができる。
【００３７】
いくつかのシナリオでは、共有RCSインターフェース520Aのサービス実施態様(たとえば、AIDL520BまたはRCS APIラッパ520C)が、サービスの形でデバイス上で実行されるRCS実施態様とすることができ、任意のアプリケーションがRCS機能を使用/共有することができる。サービス実施態様に対する利点は、共有RCSインターフェース520Aが、サードパーティappであるか、OEM appであるかに関係なく、いつでも複数のクライアントにサービスを提供する準備ができていることである。この特徴によれば、開発者は、デバイスからの既存のIMまたはファイル共有機能を利用することができる。
【００３８】
共有RCSインターフェース520Aの実施態様に関する別のオプションは、ライブラリ実施態様である(サービス実施態様とは対照的である)。サービス実施態様では、アプリケーションおよびサービス通信は、プラットフォームによってサポートされるプロセス間通信(IPC)に基づく。アプリケーションの観点から、共有RCSインターフェース520Aのサービス実施態様はAPI呼出しであるが、実際には、データはコピーされ、ソケットを介して転送されるので、ビデオバッファリングの場合に欠点になる。ビデオバッファは他のAPI呼出しに比べて、サイズが大きい可能性があるので、媒体を伴う実施態様の場合、共有RCSインターフェース520Aのためのライブラリ実施態様を用いることができる。いくつかの事例において、ライブラリ実施態様は通常、分散させることができるサービスとは異なり、ライブラリが自らのシステム内にローカルにロードされることを要求する。
【００３９】
先に論じられたように、共有RCSインターフェース520Aは、Java(登録商標)に基づくアンドロイド、C/COMに基づくウインドウズ、Cに基づくQNX/IOS、同じOSの異なるバージョンのような異なるOSを実行するデバイス上で動作するために構成することができる。共有RCSインターフェース520Aは、個々のクライアントアプリケーションを構成するために開発者が同じアクセスプロトコルを用いることができ、それより、開発者がOS特有RCSリソース525Aとのインターフェースを構成するための低レベルOS要件にかかわる必要がないように、OSタイプおよび/またはOSバージョンごとに構成することができる。
【００４０】
共有RCSインターフェース520Aの動作は、異なるプラットフォーム上でテストすることができる。そのテストは、自動化されたAPI特有テストを用いて、または独立したテストアプリケーションを通して実施することができる。自動化されない場合には、アプリケーションテストは通常、人手による労力であり、デバイスごとに人手によって繰り返す必要がある。各プラットフォーム上でAPIが共有RCSインターフェース520Aをテストするための一連の自動化テストは、開発者の人手による労力を低減するのを助けることができ、夜間に実行中に結果をもたらすことができる。一連の自動化APIテストは、APIの契約を尊重し、クロスプラットフォームRCSリソースアクセスプロトコルに準拠することを証明されるという確信をサードパーティ開発者に与えることになる。一連のAPIテストは、Java(登録商標)に基づくプラットフォームおよびCに基づくプラットフォームのような、共有RCSインターフェース520Aが展開される各関連プラットフォーム上で動作するために設計することができる。また、一連のAPIテストは、任意のデバイスにおけるジョイン認定プロセス(Joyn certification process)のために用いることもできる。
【００４１】
共有RCSインターフェース520AのようなAPIは、一般的に、コンピュータ上のシミュレートされた環境において設計され、その後、実際にテストするために対象となる展開プラットフォームに移される。したがって、各展開プラットフォーム(たとえば、アンドロイド、ウインドウズなど)において共有RCSインターフェース520Aとともに動作させるためのクライアントアプリケーションを開発者がコード化するのを助けるために、開発者にクロスプラットフォームSDKプラグインを提供することができ、それは、共有RCSインターフェース520Aに準拠するために開発者がコードを開発できるようにするのを助けることになる。クロスプラットフォームSDKプラグインを用いて特定のクライアントアプリケーションが開発された後に、そのクライアントアプリケーションを、開発者に対してシームレスに「ジョイン認定」デバイスに移行することができる。
【００４２】
図5B〜図5Cは、図5AのハイレベルRCSアーキテクチャ500AのOS特有の実施態様の例を示す。詳細には、図5Bは本発明の一実施形態によるアンドロイドRCSアーキテクチャ500Bの一例を示し、図5Cは、本発明の一実施形態によるウインドウズRCSアーキテクチャ500Cの一例を示す。
【００４３】
図5Bを参照すると、アンドロイドRCSアーキテクチャ500Bは、アプリケーションプロセッサ505Bによって管理されるリソースと、モデムプロセッサ510Bによって管理されるリソースとに分割されるように示される。アプリケーションプロセッサ側に関して、複数のRCSクライアントアプリケーション515Bが示されており、それらは図5AからのApp1...Nに対応することができる。詳細には、複数のRCSクライアントアプリケーション515Bは、拡張アドレス帳(EAB:Enhanced Address Book)能力発見(CD :Capability Discovery)クライアントアプリケーション、IMクライアントアプリケーション、ファイル共有クライアントアプリケーション、画像共有クライアントアプリケーション、およびビデオ共有クライアントアプリケーションを含むように示される。図5Bにおいて、共有RCSインターフェース520Aは、アンドロイドインターフェース定義言語(AIDL)モジュール520Bに対応し、UE上でLinux(登録商標)プロセスとして実行されるRCSサーバコンポーネントとして特徴付けることができ、AIDLモジュール520Bは、複数のRCSクライアントアプリケーション515Bの各々にアクセス可能である。AIDLモジュール520Bは、Java(登録商標)ネイティブインターフェース(JNI)525Bを介して、アンドロイドOS特有RCSリソース530Bと対話するように構成される。アンドロイドOS特有RCSリソース530Bは、限定はしないが、1組のイネーブラ535Bと、メッセージセッションリレープロトコル(MSRP)モジュール540Bと、能力発見(CD)モジュール545Bと、セッション開始プロトコル(SIP)モジュール550Bと、構成モジュール555Bと、データ/シグナリングトラフィックモジュール560Bとを含む。データ/シグナリングトラフィックモジュール560Bは、図5Aからの通信インターフェース530Aの一部を形成することができ、通信インターフェースはさらに、WLANモデム565Bと、モデムプロセッサ側において実装される、音声およびテレビ電話のためのモデム上のIMS570Bならびに無線アクセス技術(RAT)特有論理手段575Bとを含むことができる。一般的に、上記の構成要素は、LTEシグナリングもしくはデータパス、WLANシグナリングもしくはデータパス、プレゼンス用のXCAP/XDMなどの種々の通信パスを介して互いに対話するように構成される。
【００４４】
図5Cを参照すると、ウインドウズRCSアーキテクチャ500Cが、アプリケーションプロセッサ505Cによって管理されるリソースと、モデムプロセッサ510Cによって管理されるリソースとに分割されるように示される。アプリケーションプロセッサ側に関して、複数のRCSクライアントアプリケーション515Cが示されており、図5AからのApp1....Nに対応することができる。詳細には、複数のRCSクライアントアプリケーション515Cが、EBA(能力発見)クライアントアプリケーションと、IMクライアントアプリケーションと、ファイル共有クライアントアプリケーションと、画像共有クライアントアプリケーションと、ビデオ共有クライアントアプリケーションとを含むように示される。図5Cにおいて共有RCSインターフェース520AはRCS APIラッパモジュール520Cに対応し、RCS APIラッパモジュールは、それぞれのRCSクライアントアプリケーション515CによってAPIとしてアクセスされ得る。それにより、必要に応じて、RCSクライアントアプリケーション515CによってRCS APIラッパモジュール520Cを呼び出して、ウインドウズOS特有RCSリソース530Cとの対話を仲介することができる。ウインドウズOS特有RCSリソース530Cは、限定はしないが、1組のイネーブラ535Cと、メッセージセッションリレープロトコル(MSRP)モジュール540Cと、能力発見モジュール545Cと、セッション開始プロトコル(SIP)モジュール550Cと、構成モジュール555Cと、データ/シグナリングトラフィックモジュール560Cとを含む。データ/シグナリングトラフィックモジュール560Cは、図5Aからの通信インターフェース530Aの一部を形成し、通信インターフェースはさらに、WLANモデム565Cと、モデムプロセッサ側に実装される、音声およびテレビ電話のためのモデム上のIMS570Cならびに無線アクセス技術(RAT)特有論理手段575Cとを含むことができる。一般的に、上記の構成要素は、LTEシグナリングもしくはデータパス、WLANシグナリングもしくはデータパス、プレゼンス用のXCAP/XDMなどの種々の通信パスを介して互いに対話するように構成される。
【００４５】
図6Aは、本発明の一実施形態による、RCSリソースシグナリングが、共有RCSインターフェース520Aを介して、RCSクライアントアプリケーション(「App1」)から、関連するUE(またはクライアントデバイス)上のOS特有RCSリソース525Aまで搬送されるプロセスを示す。図6Aを参照すると、App1が、プラットフォーム間(たとえば、OSタイプ-OSタイプ、同じOSタイプの場合のOSバージョン-OSバージョン)で同じである、クロスプラットフォームRCSリソースアクセスプロトコルを実施するために開発者によってコードを供給されるものと仮定する。600Aにおいて、App1はOS特有RCSリソース525Aにアクセスすることを決める。たとえば、600Aにおいて、App1は、その対象相手の能力を入手すること、および/または自らの能力をその対象相手に告知することを決めることができ、App1は、セッションメンバーシップを変更することを決めるか、またはIMを送ることを決めるIMクライアントアプリケーションとすることができ、App1は、画像、ビデオまたは他のファイルなどを送ることを決める画像共有、ビデオ共有またはファイル共有アプリケーションとすることができる。
【００４６】
図6Aを参照すると、600Aにおいて決定されたRCSリソースアクセスを実施するためにOS特有(または当初からサポートされる)RCSリソースシグナリングを生成する代わりに、App1は、クロスプラットフォームRCSリソースアクセスプロトコル605Aに基づいてRCSリソースシグナリングを構成し、その後、構成済みRCSリソースシグナリングを共有RCSインターフェース520A、610Aに送る。一例において、クライアントデバイス上で実行されるOSは、共有RCSインターフェース520Aと交換されるApp1からのメッセージングを自動的に傍受し、それにOS特有ラッピングを適用するように構成され得る。こうして、610Aにおいて送られた構成済みRCSリソースシグナリングは、オプションで、破線613Aによって図6Aにおいて示されるような、先に言及されたOS特有ラッピングを受ける。理解されるように、これは、610Aにおいて共有RCSインターフェース520Aに実際に到着するシグナリングがOS特有フォーマットを有する可能性があり、クロスプラットフォームRCSリソースアクセスプロトコルに準拠してApp1によって最初にフォーマットされた構成済みRCSリソースシグナリングを抽出するために、共有RCSインターフェース520Aは最初にメッセージを「アンラップする」必要があることを意味する。App1と共有RCSインターフェース520Aとの間のメッセージングに適用される任意のOS特有ラッピングは通常、App1にとってトランスペアレントであるので、App1の開発者によって考慮に入れられる必要はない。これにより、App1の開発者は、共有RCSインターフェース520Aとの対話を介して行われる場合がある任意のOS特有ラッピングと特にかかわることなく、App1がクロスプラットフォームRCSリソースアクセスプロトコルに準拠することを確実にすることに尽力できるようになる。共有RCSインターフェース520Aは、構成済みRCSリソースシグナリングを受信し、構成済みRCSリソースシグナリングをOS特有RCSリソースアクセスプロトコル(すなわち、クライアントデバイスまたはUE上で実行されるOSにおいて当初からサポートされるRCSリソースアクセスプロトコル)に適合するように翻訳(またはマッピング)し(615A)、その後、共有RCSインターフェース520Aは、翻訳済みRCSリソースシグナリングをOS特有RCSリソース525Aに送り、App1のための要求されたアクセスを得る(620A)。一例において、615Aにおいて行われる翻訳またはマッピング動作は、クロスプラットフォームRCSリソース信号を、この特定のクライアントデバイス(またはUE)のための関連するプラットフォーム上で使用される特定のOSによって使用される当初からサポートされるか、またはOS特有のRCSリソース信号にマッピングするように構成されるルックアップテーブルに基づくことができる。OS特有RCSリソース525Aは、そのOS特有、または固有のRCSリソースアクセスプロトコルに一致する翻訳済みRCSリソースシグナリングを受信し、RCSリソース動作を実行する(625A)。625Aにおいて実行されるRCSリソース動作は、アプリケーションサーバ170のような、リモートサーバ(たとえば、プレゼンスサーバ、IMサーバなど)との対話を伴う可能性がある。
【００４７】
図6Aは個々のRCSクライアントアプリケーション(App1など)からのRCSリソースシグナリングが共有RCSインターフェース520Aによっていかに仲介され得るかを示すが、RCSリソースシグナリングは、図6Bに関して以下に説明されるように、OS特有RCSリソース525AからApp1まで流れることもできることは理解されよう。
【００４８】
図6Bは、本発明の一実施形態による、RCSリソースシグナリングが、共有RCSインターフェース520Aを介して、関連するUE(またはクライアントデバイス)上のOS特有RCSリソース525Aから、RCSクライアントアプリケーション(「App1」)まで搬送されるプロセスを示す。図6Bを参照すると、App1が、プラットフォーム間(たとえば、OSタイプ-OSタイプ、同じOSタイプの場合のOSバージョン-OSバージョン)で同じである、クロスプラットフォームRCSリソースアクセスプロトコルを実施するために開発者によってコードを供給されるものと仮定する。600Bにおいて、OS特有RCSリソース525Aは、RCSリソースデータをApp1に送ることに決める。たとえば、600Bにおいて、OS特有RCSリソース525Aは、App1の対象相手のうちの1つまたは複数に関する能力情報を送達することを決めることができ、App1はIMクライアントアプリケーションとすることができ、OS特有RCSリソース525Aは、セッションメンバーシップもしくはステータス情報および/またはIMをApp1に送達することを決めることができ、App1は、画像共有、ビデオ共有またはファイル共有アプリケーションとすることができ、OS特有RCSリソース525Aは、画像、ビデオまたは他のファイルなどをApp1に送達することを決めることができる、などである。
【００４９】
図6Bを参照すると、OS特有RCSリソース525Aは、従来技術と同様に、OS特有(または当初からサポートされる)RCSリソースアクセスプロトコルに従ってRCSリソースデータを搬送するためのRCSリソースシグナリングを生成する(605B)。しかしながら、従来技術とは異なり、OS特有RCSリソース525Aは、RCSリソースシグナリングを、OS特有RCSリソースアクセスプロトコルを解釈するようにカスタムコード化されるRCSクライアントアプリケーションに直接送達する代わりに、RCSリソースシグナリングを共有RCSインターフェース520Aに送達する(610B)。
【００５０】
共有RCSインターフェース520Aは、構成済みRCSリソースシグナリングを受信し、構成済みRCSリソースシグナリングをクロスプラットフォームRCSリソースアクセスプロトコル(すなわち、種々のプラットフォーム上でRCSクライアントアプリケーションと共有RCSインターフェースとの間で用いられるRCSリソースアクセスプロトコル)に適合するように翻訳(またはマッピング)し(615B)、その後、RCSインターフェース520Aは、翻訳済みRCSリソースシグナリングをApp1に送り、RCSリソースデータを送達する(620B)。一例において、クライアントデバイス上で実行されるOSは、共有RCSインターフェース520Aと交換されるApp1からのメッセージングを自動的に傍受し、それにOS特有ラッピングを適用するように構成され得る。こうして、620Bにおいて送られた構成済みRCSリソースシグナリングは、オプションで、破線613Bによって図6Bにおいて示されるような、先に言及されたOS特有ラッピングを受ける。理解されるように、これは、620Bにおいて共有RCSインターフェース520Aに実際に到着するシグナリングがOS特有フォーマットを有する可能性があり、クロスプラットフォームRCSリソースアクセスプロトコルに準拠して共有RCSインターフェース520Aによって最初にフォーマットされた構成済みRCSリソースシグナリングを抽出するために、App1にメッセージを「アンラップする」ように要求することを意味する。App1と共有RCSインターフェース520Aとの間のメッセージングに適用される任意のOS特有ラッピングは通常、App1にとってトランスペアレントであるので、App1の開発者によって考慮に入れられる必要はない。これにより、App1の開発者は、共有RCSインターフェース520Aとの対話を介して行われる場合がある任意のOS特有ラッピング(またはアンラッピング)と特にかかわることなく、App1がクロスプラットフォームRCSリソースアクセスプロトコルに準拠することを確実にすることに尽力できるようになる。一例において、615Bにおいて行われる翻訳またはマッピング動作は、クロスプラットフォームRCSリソース信号を、この特定のクライアントデバイス(またはUE)のための関連するプラットフォーム上で使用される特定のOSによって使用される当初からサポートされるか、またはOS特有のRCSリソース信号にマッピングするように構成されるルックアップテーブルに基づくことができる。
【００５１】
図6A〜図6Bは、それらが実施されるプラットフォーム(またはOS)に関して一般的である例示的な実施態様を示すが、ここで、図6Aおよび/または図6Bのプラットフォーム特有の実施態様の例が提供される。
【００５２】
図7Aは、本発明の一実施形態による、図6A〜図6BのプロセスのアンドロイドOS特有の実施態様の例を示す図である。図7Aを参照すると、共有RCSインターフェース520AはAIDLモジュール520Bに対応し、AIDLモジュール520BがアンドロイドOS特有RCSリソース530Bにアクセスするインターフェースは、JNI525Bを経由する。
【００５３】
図7Aを参照すると、クライアントデバイスが、600AにおいてアンドロイドOS特有RCSリソース530Bを介して能力発見(CD)機能を実施することを決めると仮定する。この仮定の下で、App1は、クロスプラットフォームRCSリソースアクセスプロトコルに従って、CDサービスを具体化するためにCreateCDServiceメッセージをAIDLモジュール520Bに送り(700A)(たとえば、図6Aの610Aと同様)、AIDLモジュール520Bは、クロスプラットフォームCreateCDServiceメッセージをアンドロイドOS特有RCSリソースプロトコルに一致する当初から使用されているCreateCDServiceメッセージに翻訳し、その後、翻訳済みCreateCDServiceメッセージをJNI525Bを介してアンドロイドOS特有RCSリソース530Bに送達する(705A)(たとえば、図6Aの620Aと同様)。また、App1は、クロスプラットフォームgetCDserviceメッセージをAIDLモジュール520Bに送る(708A)。一例において、708AにおけるgetCDserviceメッセージはJNI525Bを通るのに失敗し、それにより、翻訳されず、JNI525Bに転送されない。App1は、クロスプラットフォームRCSリソースアクセスプロトコルに従ってCDサービスに対象相手を追加するためのクロスプラットフォームCDService_AddListenerメッセージをAIDLモジュール520Bに送り(710A)(たとえば、図6Aの610Aと同様)、AIDLモジュール520Bは、クロスプラットフォームCDService_AddListenerメッセージをアンドロイドOS特有RCSリソースプロトコルに一致する当初から使用されているCDService_AddListenerメッセージに翻訳し、その後、翻訳済みCDService_AddListenerメッセージをJNI525Bを介してアンドロイドOS特有RCSリソース530Bに送達する(715A)(たとえば、図6Aの620Aと同様)。
【００５４】
図7Aを参照すると、App1は、クロスプラットフォームRCSリソースアクセスプロトコルに従ってその対象相手(またはリスナ)のうちの1つまたは複数に関するCD情報を要求するためのクロスプラットフォームRequestCDInfoメッセージをAIDLモジュール520Bに送り(720A)(たとえば、図6Aの610Aと同様)、AIDLモジュール520Bは、クロスプラットフォームRequestCDInfoメッセージをアンドロイドOS特有RCSリソースプロトコルに一致する当初から使用されているRequestCDInfoメッセージに翻訳し、その後、翻訳済みRequestCDInfoメッセージをJNI525Bを介してアンドロイドOS特有RCSリソース530Bに送達する(725A)(たとえば、図6Aの620Aと同様)。RequestCDInfoメッセージに応答して、アンドロイドOS特有RCSリソースは、対象相手に関して要求されたCD情報を与える、当初から使用されるCDListener_CDUpdateメッセージをJNI525Bを介してAIDLモジュール520Bに与え(730A)(たとえば、図6Bの610Bと同様)、AIDLモジュール520Bは、固有のRequestCDInfoメッセージをクロスプラットフォームRequestCDInfoメッセージに翻訳し、その後、翻訳済みRequestCDInfoメッセージをApp1に送達する(735A)(たとえば、図6Bの620Bと同様)。
【００５５】
図7Aには明示されないが、700A、708A、710Aおよび/または720AにおいてApp1からAIDLモジュール520Bに送られるクロスプラットフォームメッセージは、OS特有ラッピングでラップされる場合があり、ラッピング内に埋め込まれたクロスプラットフォームメッセージを抽出するために、AIDLモジュール520Bは、入ってくるメッセージを「アンラップ」するように要求される。同様に、図7Aには明示されないが、735AにおいてAIDLモジュール520BからApp1に送られるクロスプラットフォームメッセージは、OS特有ラッピングでラップされる場合があり、ラッピング内に埋め込まれたクロスプラットフォームメッセージを抽出するために、App1は、入ってくるメッセージを「アンラップ」するように要求される。
【００５６】
図7Bは、本発明の一実施形態による、図6A〜図6BのプロセスのウインドウズOS特有の実施態様の例を示す図である。図7Bを参照すると、共有RCSインターフェース525AはRCS APIラッパ520Cに対応し、RCS APIラッパは、クロスプラットフォームRCSリソースシグナリングをウインドウズOSのために当初からサポートされるRCSリソースシグナリングに翻訳するためにRCSクライアントアプリケーション(App1など)によって利用され得る。図7Bにおいて、先に言及されたクロスプラットフォーム/ウインドウズ特有RCSリソースシグナリング翻訳は、RCS APIラッパ520Cを介してApp1実行中に行われ、App1とRCS APIラッパ520Cの両方の図示が、説明のために単一のエンティティにまとめられている。
【００５７】
図7Bを参照すると、クライアントデバイスが、600AにおいてウインドウズOS特有RCSリソース530Bを介して能力発見(CD)機能を実施することを決めると仮定する。この仮定の下で、App1は、RCS APIラッパ520Cの実行とともに、ウインドウズOSのための当初からサポートされるRCSリソースアクセスプロトコルに従ってCDサービスを具体化するために、CreateCDServiceメッセージを構成し、RCSリソース530Cに送る(700B)(たとえば、図6Aの610A〜620Aと同様)。また、App1は、RCS APIラッパ520Cの実行とともに、ウインドウズOSのための当初からサポートされるRCSリソースアクセスプロトコルに従ってCDService_GetCDInfoメッセージを構成し、RCSリソース530Cに送る(705B)(たとえば、図6Aの610A〜620Aと同様)。RCSリソース530CによるCDService_GetCDInfoメッセージの実行は、SIPモジュール550Cの呼出しをトリガし、指定された対象相手の能力を問い合わせるためにリモートデバイスまたはサーバへのメッセージの送信をトリガし(710B)、リモートデバイスまたはサーバは、指定された対象相手の能力を指示する200OKメッセージで応答する(715B)。RCSリソース530Cは、CDLISTENER_CDUPDATEメッセージを介して、それらの能力をApp1に報告する(720B)。この時点で、RCS APIラッパ520Cの助けを借りて、App1は、720Bにおいて受信された固有のウインドウズメッセージを、その後にApp1によって認識可能であるクロスプラットフォームバージョンに翻訳する。
【００５８】
当業者によって理解されるように、すべての潜在的なオペレーティングシステムに関して、および/またはすべての潜在的なRCSリソースシグナリングに関して、図7A〜図7Bに類似の流れ図を提供するのは面倒である。このため、さらなる図の代わりに、異なるオペレーティングシステムの場合のクロスプラットフォームRCSリソースシグナリングとOS特有RCSリソースシグナリングとの間のマッピングを提供する例示的なルックアップテーブルがTable 1(表1)において以下に提供される。Table 1(表1)は、RCSリソースシグナリング変換の包括的なリストであることを意図するものではなく、むしろ、当業者が本発明の実施形態による潜在的な使用事例をより深く理解するのを助けるために提供される。
【００５９】
【表１Ａ】
0006348515.tif 000002
【００６０】
【表１Ｂ】
0006348515.tif 000003
【００６１】
したがって、行「能力発見(CD)サービスを具体化する」に対する列「アンドロイドOS特有RCSリソースシグナリングフロー」に示されるように、AIDLに到着するクロスプラットフォームCreateCDService*メッセージは、AIDLによって、アンドロイドまたはJava(登録商標)フォーマットに一致するCreateCDServiceメッセージにマッピングまたは翻訳され、その後、そのメッセージは、AIDLによって、ウインドウズまたはCに基づくフォーマットに一致するCreateCDServiceメッセージに翻訳することができ(たとえば、アンドロイドが主にLinux(登録商標)OS上のJava(登録商標)である場合でも、Cに基づくプログラムをLinux(登録商標)OS上で実行するために構成することができることから)、その後、AIDLは、アンドロイド特有RCSリソースに送達するためにCに基づくCreateCDServiceメッセージを広め、Cに基づくCreateCDServiceメッセージを、モデムを介してネットワークに送信する。同様に、行「能力発見(CD)サービスを具体化する」に対する列「ウインドウズOS特有RCSリソースシグナリングフロー」に示されるように、RCS APIラッパに到着するクロスプラットフォームCreateCDService*メッセージは、RCS APIラッパによって、ウインドウズまたはCに基づくフォーマットに一致するCreateCDServiceメッセージにマッピングまたは翻訳され、その後、RCS APIラッパは、ウインドウズ特有RCSリソースに送達するためにCに基づくCreateCDServiceメッセージを広め、Cに基づくCreateCDServiceメッセージを、モデムを介してネットワークに送信する。
【００６２】
したがって、Table 1(表1)(上記)からのクロスプラットフォームCreateCDService*は、図6Aのプロセスと同様にマッピングされ、送達され得る。この点において、クロスプラットフォームメッセージCDService_AddListener*、RemoveListenerCD_SERVICE*、DestroyCDService*、CreateIMService*、IMService_AddListerner*およびIMService_RemoveListener*は、これらのメッセージがRCSクライアントアプリケーション(App1など)から生じ、その後、ネットワークに送信するためにOS特有RCSリソースアクセスプロトコルに翻訳されるという意味において類似である。しかしながら、他のタイプのメッセージはアプリケーション終端メッセージに対応し、そのメッセージは、ネットワークから到着し、その後、Table 1(表1)(上記)からのIMSession_SendMessage()*のような、クロスプラットフォームメッセージに翻訳され、それらは、図6Bのプロセスと同様にマッピングされ、送達され得る。
【００６３】
再び、Table 1(表1)(上記)は、限定された1組の例を特徴付けており、他のクロスプラットフォームRCSリソースシグナリングマッピングは、CDまたはIM RCSサービスのためのさらなる信号に関連付けることができるか、またはまったく異なるタイプのRCSサービス(たとえば、イメージシェア、ファイル転送またはファイル共有、構成サービス、ビデオ共有など)に関連付けることができる。
【００６４】
情報および信号が多種多様な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば、上記の説明全体を通して参照される場合があるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表すことができる。
【００６５】
さらに、本明細書において開示される実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実現され得ることを、当業者は理解されよう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、一般的にそれらの機能性に関してこれまで説明されてきた。そのような機能がハードウェアとして実現されるか、またはソフトウェアとして実現されるかは、具体的な適用例およびシステム全体に課される設計制約によって決まる。当業者は、説明された機能を具体的な適用例ごとに様々な方法で実現することができるが、そのような実現の決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
【００６６】
本明細書において開示される実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別のゲートもしくはトランジスタ論理、個別のハードウェアコンポーネント、または本明細書において説明される機能を実行するように設計されているそれらの任意の組合せを用いて実現または実行され得る。汎用プロセッサはマイクロプロセッサとすることができるが、代替形態では、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることもできる。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実現することもできる。
【００６７】
本明細書において開示される実施形態に関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接具現され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替形態では、記憶媒体はプロセッサと一体にすることができる。プロセッサおよび記憶媒体はASIC内に存在することができる。ASICはユーザ端末(たとえば、UE)中に存在することができる。代替形態では、プロセッサおよび記憶媒体は、ユーザ端末内に個別構成要素として存在することができる。
【００６８】
1つまたは複数の例示的な実施形態では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実現され得る。ソフトウェアにおいて実現された場合、それらの機能は、1つまたは複数の命令またはコードとして、コンピュータ可読記録媒体上に記憶されるか、またはコンピュータ可読記録媒体を介して送信され得る。コンピュータ可読記録媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセス可能である任意の入手可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ可読記録媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令またはデータ構造の形態の所望のプログラムコードを搬送または記憶するために用いることができ、コンピュータによってアクセス可能である、任意の他の媒体を含むことができる。また、当然、あらゆる接続がコンピュータ可読記録媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合には、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書において使用されるとき、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生するが、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読記録媒体の範囲内に含めるべきである。
【００６９】
上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく、本明細書において様々な変更および修正が行われ得ることに留意されたい。本明細書において説明された本発明の実施形態による方法クレームの機能、ステップおよび/または動作は、特定の順序で実行される必要はない。さらに、本発明の要素は、単数形で記載または特許請求されている場合があるが、単数形に限定することが明示的に述べられていない限り、複数形が考えられる。
【符号の説明】
【００７０】
100  ワイヤレス通信システム
104  エアインターフェース
106  エアインターフェース
108  エアインターフェース
120  RAN
125  アクセスポイント(AP)
140  コアネットワーク
170  サーバ
175  インターネット
200A  UE
200B  UE
202  プラットフォーム
205A  アンテナ
206  送受信機
208  特定用途向け集積回路(ASIC)
210  アプリケーションプログラミングインターフェース(API)
210A  デバイス
214  ローカルデータベース
215A  ボタン
220A  キーパッド
230A  フロントパネルボタン
300  通信デバイス
305  情報を受信および/または送信するように構成される論理手段
310  情報を処理するように構成される論理手段
315  情報を記憶するように構成される論理手段
320  情報を提示するように構成される論理手段
325  ローカルユーザ入力を受信するように構成される論理手段
400  RCSアーキテクチャ
405  クライアントアプリケーション
410  クライアントアプリケーション
415  クライアントアプリケーション
420  OS特有RCSリソース
500A  RCSアーキテクチャ
500B  アンドロイドRCSアーキテクチャ
500C  ウインドウズRCSアーキテクチャ
505  クライアントアプリケーション
505B  アプリケーションプロセッサ
505C  アプリケーションプロセッサ
510  クライアントアプリケーション
510B  モデムプロセッサ
510C  モデムプロセッサ
515  クライアントアプリケーション
515C  RCSクライアントアプリケーション
520A  共有RCSインターフェース
520B  アンドロイドインターフェース定義言語(AIDL)モジュール
520C  RCS APIラッパモジュール
525A  OS特有RCSリソース
525B  Java(登録商標)ネイティブインターフェース(JNI)
530B  アンドロイドOS特有RCSリソース
530C  ウインドウズOS特有RCSリソース
535B  1組のイネーブラ
535C  1組のイネーブラ
540B  メッセージセッションリレープロトコル(MSRP)モジュール
540C  メッセージセッションリレープロトコル(MSRP)モジュール
545B  能力発見(CD)モジュール
545C  能力発見(CD)モジュール
550B  セッション開始プロトコル(SIP)モジュール
550C  セッション開始プロトコル(SIP)モジュール
555B  構成モジュール
555C  構成モジュール
560B  データ/シグナリングトラフィックモジュール
560C  データ/シグナリングトラフィックモジュール
565B  WLANモデム
565C  WLANモデム
570B  音声およびテレビ電話のためのモデム上のIMS
570C  音声およびテレビ電話のためのモデム上のIMS
575B  無線アクセス技術(RAT)特有モジュール
575C  無線アクセス技術(RAT)特有論理手段
613A  破線
613B  破線
【図１】
0006348515.tif 000004
【図２】
0006348515.tif 000005
【図３】
0006348515.tif 000006
【図４】
0006348515.tif 000007
【図５Ａ】
0006348515.tif 000008
【図５Ｂ】
0006348515.tif 000009
【図５Ｃ】
0006348515.tif 000010
【図６Ａ】
0006348515.tif 000011
【図６Ｂ】
0006348515.tif 000012
【図７Ａ】
0006348515.tif 000013
【図７Ｂ】
0006348515.tif 000014