(57)【要約】【課題】モバイルデバイス上で動作するアプリケーションはそれらを実行しているデバイスの物理的コンテキストを認識していない傾向にある。モバイルネットワークは顧客またはユーザが提供され得るＩＰ接続性をどのように使用し得るかについては、最低限の認識を有し得るにすぎない。デバイスおよび／またはアプリケーション情報の事前構成は、サービスを生じるまで、どのようなサービスかが分からず、事前構成が可能でないことがある。【解決手段】Ｐｒｏｘｉｍｉｔｙサービスなどを提供するシステムおよび方法が開示される。アプリケーションとサーバとの間で一時サービス名が確立され、ＵＥおよび／またはネットワークは、アプリケーションによる後の関与なしに、ならびに／またはアプリケーションについての証明書をネットワークと交換すること、および逆方向の交換を行うことなしに後で当該サービスを実行できる。【選択図】図２
2020054011.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバによって提供されるサービスに対するセッションを開始するための要求を第１のデバイスから前記アプリケーションサーバによって受信し、前記要求は、前記第１のデバイスへの接続性を提供するモバイル無線ネットワークを介して受信され、
前記要求に応答して、前記モバイル無線ネットワーク内のサーバとの通信を前記アプリケーションサーバによって交換し、前記モバイル無線ネットワークを介して前記アプリケーションサーバによって提供される前記サービスに対する前記セッションのためのパラメータを決定し、前記パラメータは前記セッションに対する一時サービス名を含み、前記一時サービス名は前記サービスの特徴を指定している複数のテキスト文字列を含み、
前記セッションを要求している少なくとも前記第１のデバイスに、前記一時サービス名を前記モバイル無線ネットワークを介して、前記アプリケーションサーバによって送り、前記一時サービス名は前記モバイル無線ネットワークを介して前記アプリケーションサーバによって提供される前記サービスに対する前記セッションを開始するために前記第１のデバイスによって使用されること
を含んでいる動作を実行するように構成されたプロセッサを備えたことを特徴とするコンピューティングシステム。
【請求項２】
前記モバイル無線ネットワーク内のサーバとの通信を交換し、前記サービスに対する前記セッションのパラメータを決定することは、
前記モバイル無線ネットワークに前記セッションを開始するための要求を送ることと、
前記一時サービス名を含んでいる前記パラメータに対する前記モバイル無線ネットワークとの合意を確立することと、
前記一時サービス名を受信することと
をさらに含むことを特徴とする請求項１に記載のコンピューティングシステム。
【請求項３】
前記一時サービス名は、前記モバイル無線ネットワーク、プロキシミティサービス（ＰｒｏＳｅ）サーバ、またはデバイスツーデバイス（Ｄ２Ｄ）サーバの少なくとも１つから受信されることを特徴とする請求項２に記載のコンピューティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスインターフェースを個人化および／または調整するためのシステムおよび方法に関する。
【背景技術】
【０００２】
本出願は、その内容が参照により本明細書に組み込まれる、２０１２年４月２７日に出願された米国特許仮出願第６１／６３９５３５号明細書、２０１２年７月１９日に出願された米国特許仮出願第６１／６７３４８５号明細書、および２０１２年１０月１７日に出願された米国特許仮出願第６１／７１５０５３号明細書の利益を主張する。
【０００３】
最近の５年間に、セルラ通信の世界は、セルラ顧客またはユーザが寄せる期待に関して大きな変化を経験した。歴史的には、セルラまたはモバイル通信は、音声通話などの単一の主目的のために提供され、進化してきており、データ接続性は、好ましい拡張機能と見なされていた。そのため、非音声サービスは、「インターネット接続性」の傘の下に一括され、モバイルネットワークは、セルラ顧客またはユーザに関連付けられたデバイスで生じるデータサービスに差別化サービス品質（ＱｏＳ）を提供するうえで重要な機能を有していなかったので、ＱｏＳ差別化は、問題とはならない傾向にあった。
【０００４】
しかしながら、今日では、ワイヤレスおよびモバイルサービスがますます優勢になっているので、音声通話とデータ接続性の両方が、セルラまたはモバイル通信の主目的となった。例えば、セルラ顧客またはユーザは、モバイルネットワークによって接続され得るサードパーティサービスを含む様々なサービスの間でサービス差別化を利用し得る数々のアプリケーションをモバイルデバイス上で実行する傾向にある。そのようなアプリケーションは、モバイルデバイス上で実行し得る、対話型ゲーム、電子書籍リーダアプリケーション、および心拍モニタアプリケーションなどを含むことができ、例えば、コンテンツ配送および／または送信を可能にするため、ならびにリソースをスケジュールまたは使用するためなどに、サービス差別化を使用し得る。さらに、そのようなサービス差別化は、サービスへの加入者のアクセスを可能にするための、使用されたモバイルネットワークリソースの記録をつけるための、ならびにそのようなリソースおよび／またはサービスの料金を請求するための差別化された方法に関連付けることができる。例えば、加入者ではなく、サービスプロバイダにデータ使用の料金を請求し得る。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
デバイス上で動作するそのようなアプリケーションは、通常は「ソケットインターフェース」アプリケーションプログラミングインターフェース（ＡＰＩ）を利用することによって、インターネットプロトコル（ＩＰ）アドレスを用いて互いに通信し得る。そのようなアプリケーションは、アプリケーションアドレスは認識し得るが、残念ながら、それらを実行しているデバイスの物理的コンテキストを認識していない傾向にある。例えば、アプリケーションは、モバイルデバイスに関連付けられたＭＡＣアドレスを認識すること、特定のデバイスに対する他のデバイスの近接性についての情報を認識すること、および使用され得る下層のアクセス制御メカニズムを認識することなどができない。
【０００６】
他方、モバイルネットワークは、デバイス相互の近接性およびデバイスの物理的特性など、そのようなアプリケーションを実行しているデバイスを認識し得るが、顧客またはユーザが提供され得るＩＰ接続性をどのように使用し得るかについては、最低限の認識を有し得るにすぎない。例えば、モバイルネットワークは、ＩＰデータストリームを個々の「アプリケーションフロー」に差別化して分けることはできるとしても、顧客またはユーザおよびその人たちが実行しているアプリケーションに関連付けられ得る、アプリケーション識別情報、プリファレンス、ソーシャルアソシエーション、および他の適切な情報を認識し得ない。現在は、そのような情報（例えば、デバイスおよび／またはアプリケーション情報）は、そのようなモバイルネットワークおよび／またはアプリケーションによる使用のために、事前に構成され得る。そのような情報の事前構成は、汎用的および／または無差別的なサービスなど、いくつかのサービスには役立ち得るが、残念ながら、そのような情報の事前構成は、突然サービスを生じるまで、どのようなサービスかが分からず、事前構成が可能でないことがある、モバイルネットワークおよび／またはアプリケーションにおける個人化および／または調整されたサービスなど、他のサービスには役立たない傾向にある。
【課題を解決するための手段】
【０００７】
デバイスを発見し、および／または差別化されたサービスをアプリケーションサービスの一環として提供することを可能にするためのシステム、方法、および／または技法が開示され得る。例えば、１つのデバイス上のアプリケーションに、ユーザまたは関心サービスを具現した同様のアプリケーションを実行し得る別のデバイスの近接性を認識させ得るように、Ｐｒｏｘｉｍｉｔｙサービスを含む差別化されたサービスなどのサービスを３ＧＰＰネットワークなどのネットワークにおいて定義することについての関心が存在し得る。デバイスが、互いに発見し合うこと、および／またはデバイス上の同様のアプリケーションに関連付けられたセッションを確立すること、もしくはそれに参加することを可能にするために、アプリケーションとネットワークの間で一時サービス名または一時識別子が確立され得、ＵＥおよび／またはネットワークは、おそらくはアプリケーションによるさらなる関与なしに、そのようなサービスを後で実行し得るようになる。加えて、（例えば、オープンＩＤによって定義される）中間識別情報が、アプリケーションがユーザ名をこの中間識別情報に変換し得るように、（例えば、ＭＮＯによって）提供および／または使用され得る。サービスが近接サーバであり得る場合、この識別情報は、ネットワークに提供され得るＤ２Ｄ要求において使用され得る。
【０００８】
「課題を解決するための手段」は、以下の「発明を実施するための形態」においてさらに説明される概念の一部抜粋を簡略化された形式で紹介するために提供された。この「課題を解決するための手段」は、特許請求される本発明の主要な特徴または必須の特徴を識別することを意図しておらず、特許請求される本発明の範囲を限定するために使用されることも意図していない。さらに、特許請求される本発明は、本開示のいずれかの部分で言及されるいずれかまたはすべての不都合を解決するいかなる制限にも限定されない。
【図面の簡単な説明】
【０００９】
本明細書で開示される実施形態についてのより詳細な理解は、添付の図面を併用する、例として与えられた、以下の説明から得ることができる。
【００１０】
【図１Ａ】１または複数の開示される実施形態が実施され得る例示的な通信システムの図である。
【図１Ｂ】図１Ａに示された通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。
【図１Ｃ】図１Ａに示された通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図１Ｄ】図１Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図１Ｅ】図１Ａに示された通信システム内で使用され得る別の例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図２】サードパーティサービスアクセス方法、プロセス、または手順の例示的な実施形態を示す図である。
【図３】ポリシプル方法、プロセス、または手順の例示的な実施形態を示す図である。
【図４】ポリシプッシュ方法、プロセス、または手順の例示的な実施形態を示す図である。
【図５】ＰｒｏＳｅ識別情報機能の例示的な実施形態を示す図である。
【図６】オペレータ間Ｄ２Ｄアーキテクチャの例示的な実施形態を示す図である。
【図７】Ｄ２Ｄサービス登録およびアクセスの例示的な実施形態を示す図である。
【図８】本明細書で説明されるようなＰｒｏＳｅのために使用され得るアーキテクチャの例示的な実施形態を示す図である。
【図９】本明細書で説明されるように使用され得るアーキテクチャの例示的な実施形態を示す図である。
【図１０】ＰｒｏＳｅ実施形態の初期アクティブ化の例示的な実施形態を示す図である。
【図１１】識別情報検証手順または方法の例示的な実施形態を示す図である。
【図１２】（例えば、アプリケーションにログインして、またはログインせずに）ＰｒｏＳｅに登録するための手順または方法の例示的な実施形態を示す図である。
【図１３】発見手順または方法の例示的な実施形態を示す図である。
【図１４】アプリケーションウェイクアップ通知手順または方法の例示的な実施形態を示す図である。
【図１５】デバイスツーデバイス（例えば、Ｄ２Ｄ）接続セットアップ手順または方法の例示的な実施形態を示す図である。
【発明を実施するための形態】
【００１１】
説明的な実施形態についての詳細な説明が、様々な図を参照して今から行われる。この説明は、可能な実施についての詳細な例を提供するが、詳細は例示的なものであり、決して本出願の範囲を限定するものではないことが意図されていることに留意されたい。
【００１２】
近接性発見またはＤ２Ｄリンク確立などのＰｒｏｘｉｍｉｔｙサービスが（例えば、アプリケーションに代わって）アプリケーションサービスの一環として提供されることを可能にするためのシステムおよび／または方法（例えば、それらの様々な実施形態を含む）が開示され得る。例えば、一実施形態では、アプリケーションとＤ２Ｄサーバなどのサーバとの間で一時サービス名または一時識別子が確立され得、ＵＥおよび／またはネットワークは、おそらくはアプリケーションからの関与またはアプリケーションの関与なしに、そのようなサービスを後で実行し得るようになる。加えて、実施形態では、（例えば、オープンＩＤによって定義される）中間識別情報が、アプリケーションがユーザ名をこの中間識別情報に変換し得、ネットワークに提供され得るＤ２Ｄ要求において識別情報を使用し得るように、（例えば、ＭＮＯによって）提供および／または使用され得る。加えて、そのようなシステムおよび方法は、本明細書で説明されるように、差別化サービス品質（ＱｏＳ）をフローに提供し得る。例えば、サービスは、提供および／もしくは使用され得るＤ２Ｄネットワークサービスもしくは調整されたサービスを含むことができ、またはそれらのサービスとすることができる。サービスに基づいて、アプリケーションＱｏＳなどのＱｏＳが、本明細書で説明されるように、差別化され得る。
【００１３】
図１Ａは、１または複数の開示される実施形態が実施され得る例示的な通信システム１００の図を示している。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数のワイヤレスユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にできる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を利用できる。
【００１４】
図１Ａに示されるように、通信システム１００は、（一般にまたは一括してＷＴＲＵ１０２と呼ばれることがある）無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、ならびに他のネットワーク１１２を含むことができるが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄの各々は、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄは、ワイヤレス信号を送信および／または受信するように構成され得、ユーザ機器（ＵＥ）、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家電製品などを含むことができる。
【００１５】
通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含むことができる。基地局１１４ａ、１１４ｂの各々は、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２などの１または複数の通信ネットワークへのアクセスを円滑化するために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄの少なくとも１つとワイヤレスでインターフェース接続するように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局１１４ａおよび／または１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、およびワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂは各々、単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。
【００１６】
基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の部分とすることができ、ＲＡＮ１０３／１０４／１０５は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含むことができる。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と呼ばれることがある特定の地理的領域内で、ワイヤレス信号を送信および／または受信するように構成され得る。セルは、さらにセルセクタに分割され得る。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルのセクタ毎に１つずつ含むことができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用でき、したがって、セルのセクタ毎に複数の送受信機を利用できる。
【００１７】
基地局１１４ａおよび／または１１４ｂは、エアインターフェース１１５／１１６／１１７上で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄの１または複数と通信でき、エアインターフェース１１５／１１６／１１７は、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインターフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立され得る。
【００１８】
より具体的には、上で言及されたように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセス方式を利用できる。例えば、ＲＡＮ１０３／１０４／１０５内の基地局１１４ａ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインターフェース１１５／１１６／１１７を確立できる、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実施できる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含むことができる。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含むことができる。
【００１９】
別の実施形態では、基地局１１４ａ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインターフェース１１５／１１６／１１７を確立できる、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実施できる。
【００２０】
他の実施形態では、基地局１１４ａ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセス用の世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用の高速データレート（ＥＤＧＥ）、およびＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実施できる。
【００２１】
図１Ａの基地局１１４ｂは、例えば、ワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおけるワイヤレス接続性を円滑化するために、任意の適切なＲＡＴを利用できる。一実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実施して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立できる。別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実施して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立できる。また別の実施形態では、基地局１１４ｂ、およびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立できる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有することがある。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介して、インターネット１１０にアクセスする必要がないことがある。
【００２２】
ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信でき、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄの１または複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供でき、および／またはユーザ認証など、高レベルのセキュリティ機能を実行できる。図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的に通信できることが理解されよう。例えば、Ｅ−ＵＴＲＡ無線技術を利用できるＲＡＮ１０３／１０４／１０５に接続するのに加えて、コアネットワーク１０６／１０７／１０９は、ＧＳＭ無線技術を利用する別のＲＡＮ（図示されず）と通信することもできる。
【００２３】
コアネットワーク１０６／１０７／１０９は、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするための、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのためのゲートウェイとしてもサービスできる。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する回路交換電話網を含むことができる。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される有線またはワイヤレス通信ネットワークを含むことができる。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを利用できる１または複数のＲＡＮに接続された、別のコアネットワークを含むことができる。
【００２４】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄは、異なるワイヤレスリンク上で異なるワイヤレスネットワークと通信するための複数の送受信機を含むことができる。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を利用できる基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用できる基地局１１４ｂと通信するように構成され得る。
【００２５】
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図を示している。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８と、送受信機１２０と、送信／受信要素１２２と、スピーカ／マイクロフォン１２４と、キーパッド１２６と、ディスプレイ／タッチパッド１２８と、着脱不能メモリ１３０と、着脱可能メモリ１３２と、電源１３４と、全地球測位システム（ＧＰＳ）チップセット１３６と、他の周辺機器１３８とを含むことができる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができることが理解されよう。また、実施形態は、基地局１１４ａ、１１４ｂ、ならびに／またはとりわけ、送受信機局（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、進化型ホームノードＢ（ｅＮｏｄｅＢ）、ホーム進化型ノードＢ（ＨｅＮＢ）、ホーム進化型ノードＢゲートウェイ、およびプロキシノードなどの、しかし、それらに限定されない、基地局１１４ａ、１１４ｂが表し得るノードが、図１Ｂに示され、本明細書で説明される要素のいくつかまたはすべてを含むことができることを企図している。
【００２６】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／またはＷＴＲＵ１０２がワイヤレス環境で動作することを可能にする他の任意の機能を実行できる。プロセッサ１１８は、送受信機１２０に結合され得、送受信機１２０は、送信／受信要素１２２に結合され得る。図１Ｂは、プロセッサ１１８と送受信機１２０とを別々のコンポーネントとして示しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合され得ることが理解され得よう。
【００２７】
送信／受信要素１２２は、エアインターフェース１１５／１１６／１１７上で、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成され得る。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器とすることができる。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信要素１２２は、ワイヤレス信号の任意の組み合わせを送信および／または受信するように構成され得ることが理解されよう。
【００２８】
加えて、図１Ｂでは、送信／受信要素１２２は単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用できる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１５／１１６／１１７上でワイヤレス信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含むことができる。
【００２９】
送受信機１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成され得る。上で言及されたように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含むことができる。
【００３０】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得、それらからユーザ入力データを受け取ることができる。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２など、任意のタイプの適切なメモリから情報を入手でき、それらにデータを記憶できる。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、ＷＴＲＵ１０２上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ（図示されず）などの上に配置されたメモリから情報を入手でき、それらにデータを記憶できる。
【００３１】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他のコンポーネントへの電力の分配および／または制御を行うように構成され得る。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１または複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含むことができる。
【００３２】
プロセッサ１１８は、ＧＰＳチップセット１３６にも結合され得、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１５／１１６／１１７上で位置情報を受け取ることができ、および／または２つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定できる。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。
【００３３】
プロセッサ１１８は、他の周辺機器１３８にさらに結合され得、他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくはワイヤレス接続性を提供する、１または複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含むことができる。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。
【００３４】
図１Ｃは、実施形態による、ＲＡＮ１０３およびコアネットワーク１０６のシステム図を示している。上で言及されたように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を利用して、エアインターフェース１１５上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信できる。ＲＡＮ１０３は、コアネットワーク１０６とも通信できる。図１Ｃに示されるように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃを含むことができ、ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃは各々、エアインターフェース１１５上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信するための１または複数の送受信機を含むことができる。ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃは各々、ＲＡＮ１０３内の特定のセル（図示されず）に関連付けることができる。ＲＡＮ１０３は、ＲＮＣ１４２ａおよび／または１４２ｂも含むことができる。ＲＡＮ１０３は、実施形態との整合性を保ちながら、任意の数のノードＢおよびＲＮＣを含むことができることが理解されよう。
【００３５】
図１Ｃに示されるように、ノードＢ１４０ａおよび／または１４０ｂは、ＲＮＣ１４２ａと通信できる。加えて、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信できる。ノードＢ１４０ａ、１４０ｂ、および／または１４０ｃは、Ｉｕｂインターフェースを介して、それぞれのＲＮＣ１４２ａ、１４２ｂと通信できる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインターフェースを介して、互いに通信できる。ＲＮＣ１４２ａ、１４２ｂの各々は、それが接続されたそれぞれのノードＢ１４０ａ、１４０ｂ、および／または１４０ｃを制御するように構成され得る。加えて、ＲＮＣ１４２ａ、１４２ｂの各々は、アウタループ電力制御、負荷制御、アドミッションコントロール、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能を実施またはサポートするように構成され得る。
【００３６】
図１Ｃに示されるコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイル交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含むことができる。上記の要素の各々は、コアネットワーク１０６の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なる主体によって所有および／または運営され得ることが理解されよう。
【００３７】
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介して、コアネットワーク１０６内のＭＳＣ１４６に接続され得る。ＭＳＣ１４６は、ＭＧＷ１４４に接続され得る。ＭＳＣ１４６とＭＧＷ１４４は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の陸線通信デバイスの間の通信を円滑化できる。
【００３８】
ＲＡＮ１０３内のＲＮＣ１４２ａは、ＩｕＰＳインターフェースを介して、コアネットワーク１０６内のＳＧＳＮ１４８にも接続され得る。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続され得る。ＳＧＳＮ１４８とＧＧＳＮ１５０は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスの間の通信を円滑化できる。
【００３９】
上で言及されたように、コアネットワーク１０６は、ネットワーク１１２にも接続され得、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含むことができる。
【００４０】
図１Ｄは、実施形態による、ＲＡＮ１０４およびコアネットワーク１０７のシステム図を示している。上で言及されたように、ＲＡＮ１０４は、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信するために、Ｅ−ＵＴＲＡ無線技術を利用できる。ＲＡＮ１０４は、コアネットワーク１０７とも通信できる。
【００４１】
ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃを含むことができるが、ＲＡＮ１０４は、実施形態との整合性を保ちながら、任意の数のｅノードＢを含むことができることが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃは、各々が、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信するための１または複数の送受信機を含むことができる。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃは、ＭＩＭＯ技術を実施できる。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信できる。
【００４２】
ｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々は、特定のセル（図示されず）に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図１Ｄに示されるように、ｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃは、Ｘ２インターフェース上で互いに通信できる。
【００４３】
図１Ｄに示されるコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含むことができる。上記の要素の各々は、コアネットワーク１０７の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なる主体によって所有および／または運営され得ることが理解されよう。
【００４４】
ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々に接続され得、制御ノードとしての役割を果たすことができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのユーザの認証、ベアラアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能も提供できる。
【００４５】
サービングゲートウェイ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、および／または１６０ｃの各々に接続され得る。サービングゲートウェイ１６４は、一般に、ユーザデータパケットのＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃへの／からの経路選択および転送を行うことができる。サービングゲートウェイ１６４は、ｅノードＢ間ハンドオーバ中におけるユーザプレーンのアンカリング（ａｎｃｈｏｒｉｎｇ）、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに利用可能な場合に行う一斉呼出のトリガ、ならびにＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのコンテキストの管理および記憶など、他の機能も実行できる。
【００４６】
サービングゲートウェイ１６４は、ＰＤＮゲートウェイ１６６にも接続され得、ＰＤＮゲートウェイ１６６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスの間の通信を円滑化できる。
【００４７】
コアネットワーク１０７は、他のネットワークとの通信を円滑化できる。例えば、コアネットワーク１０７は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の陸線通信デバイスの間の通信を円滑化できる。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８の間のインターフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができ、またはＩＰゲートウェイと通信できる。加えて、コアネットワーク１０７は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供でき、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含むことができる。
【００４８】
図１Ｅは、実施形態による、ＲＡＮ１０５およびコアネットワーク１０９のシステム図を示している。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を利用して、エアインターフェース１１７上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）とすることができる。以下でさらに説明されるように、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃ、ＲＡＮ１０５、ならびにコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、参照点として定義され得る。
【００４９】
図１Ｅに示されるように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、および／または１８０ｃと、ＡＳＮゲートウェイ１８２とを含むことができるが、ＲＡＮ１０５は、実施形態との整合性を保ちながら、任意の数の基地局とＡＳＮゲートウェイとを含むことができることが理解されよう。基地局１８０ａ、１８０ｂ、および／または１８０ｃは、各々が、ＲＡＮ１０５内の特定のセル（図示されず）に関連付けることができ、各々が、エアインターフェース１１７上でＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと通信するための１または複数の送受信機を含み得る。一実施形態では、基地局１８０ａ、１８０ｂ、および／または１８０ｃは、ＭＩＭＯ技術を実施できる。したがって、基地局１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、ＷＴＲＵ１０２ａからワイヤレス信号を受信できる。基地局１８０ａ、１８０ｂ、および／または１８０ｃは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシ実施などの、モビリティ管理機能も提供できる。ＡＳＮゲートウェイ１８２は、トラフィック集約ポイントとしてサービスでき、ページング、加入者プロファイルのキャッシング、およびコアネットワーク１０９へのルーティングなどを担うことができる。
【００５０】
ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＲＡＮ１０５の間のエアインターフェース１１７は、ＩＥＥＥ８０２．１６仕様を実施する、Ｒ１参照点として定義され得る。加えて、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの各々は、コアネットワーク１０９との論理インターフェース（図示されず）を確立できる。ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとコアネットワーク１０９の間の論理インターフェースは、Ｒ２参照点として定義され得、Ｒ２参照点は、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理のために使用され得る。
【００５１】
基地局１８０ａ、１８０ｂ、および／または１８０ｃの各々の間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間でのデータの転送を円滑化するためのプロトコルを含む、Ｒ８参照点として定義され得る。基地局１８０ａ、１８０ｂ、および／または１８０ｃとＡＳＮゲートウェイ１８２の間の通信リンクは、Ｒ６参照点として定義され得る。Ｒ６参照点は、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃの各々に関連するモビリティイベントに基づいたモビリティ管理を円滑化するためのプロトコルを含むことができる。
【００５２】
図１Ｅに示されるように、ＲＡＮ１０５は、コアネットワーク１０９に接続され得る。ＲＡＮ１０５とコアネットワーク１０９の間の通信リンクは、例えばデータ転送およびモビリティ管理機能を円滑化するためのプロトコルを含む、Ｒ３参照点として定義され得る。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４と、認証認可課金（ＡＡＡ）サーバ１８６と、ゲートウェイ１８８とを含むことができる。上記の要素の各々は、コアネットワーク１０９の部分として示されているが、これらの要素は、どの１つをとっても、コアネットワークオペレータとは異なる主体によって所有および／または運営され得ることが理解されよう。
【００５３】
ＭＩＰ−ＨＡは、ＩＰアドレス管理を担うことができ、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃが、異なるＡＳＮの間で、および／または異なるコアネットワークの間でローミングを行うことを可能にできる。ＭＩＰ−ＨＡ１８４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃとＩＰ対応デバイスの間の通信を円滑化できる。ＡＡＡサーバ１８６は、ユーザ認証、およびユーザサービスのサポートを担うことができる。ゲートウェイ１８８は、他のネットワークとの網間接続を円滑化できる。例えば、ゲートウェイ１８８は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃと従来の陸線通信デバイスの間の通信を円滑化できる。加えて、ゲートウェイ１８８は、ネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃに提供し、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含むことができる。
【００５４】
図１Ｅには示されていないが、ＲＡＮ１０５は、他のＡＳＮに接続され得、コアネットワーク１０９は、他のコアネットワークに接続され得ることが理解されるべきであり、理解され得、および／または理解されよう。ＲＡＮ１０５と他のＡＳＮの間の通信リンクは、Ｒ４参照点として定義され得、Ｒ４参照点は、ＲＡＮ１０５と他のＡＳＮの間で、ＷＴＲＵ１０２ａ、１０２ｂ、および／または１０２ｃのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク１０９と他のコアネットワークの間の通信リンクは、Ｒ５参照として定義され得、Ｒ５参照は、ホームコアネットワークと在圏コアネットワークの間の網間接続を円滑化するためのプロトコルを含むことができる。
【００５５】
上で説明されたように、最近の５年間にわたって、セルラ通信の世界は、セルラ顧客またはユーザが寄せる期待に関して大きな変化を経験した。例えば、歴史的には、セルラまたはモバイル通信は、一般に、音声通話を含む単一の目的のために進化してきており、データ接続性は、好ましい拡張機能と見なされていた。加えて、非音声サービスは、「インターネット接続性」の傘の下に一括される傾向にあり、サービス品質（ＱｏＳ）差別化は、問題とはならない傾向にあり、および／またはモバイルネットワークは、ＷＴＲＵもしくはユーザ機器（ＵＥ）で生じるデータサービスに差別化ＱｏＳを提供するうえで重要な機能を有していない傾向にあった。
【００５６】
しかしながら、今日では、ワイヤレスおよびモバイルサービスが優勢になる傾向にある。例えば、ユーザは、様々なサービスおよび／またはサービス差別化を利用し得る数々のアプリケーションを実行する。例えば、そのようなアプリケーションは、以下のうちの１または複数を含むことができ、すなわち、小グループのプレーヤの間で行われる対話型ゲームは、そのようなプレーヤの間の最適化されたポイントツーポイント接続性を使用すること、またはその恩恵を受けることができ（例えば、これは、そのようなプレーヤが互いに物理的に近接して存在し、性能およびリソース使用を最適化し得る場合に特に言い得る）、電子リーダサービスからダウンロードされる書籍などのユーザダウンロードコンテンツは、迅速に（例えば、出発便に搭乗する前に）ダウンロードされる必要があることがあり、そのため、そのような購入に対しては、ユーザに関連付けられたデバイスへの最適化されたコンテンツ配送をもたらす、「迅速配送」が要求されることがあり、ユーザに関連付けられた心拍モニタは、異常を検出し得、その結果、高優先度のレポートが、ユーザに関連付けられた現在の所在地に物理的に近接した健康管理センタに転送され得る。実施形態では、そのようなサービスは、指定されたユーザのアプリケーションが他の潜在的なユーザの別のアプリケーションから受信し得、および／またはそれに送信し得る情報とすることができ、それは、そのような情報がどのように送信および／または受信され得るかを含む。さらに、そのようなサービスは、（例えば、サービスが自らを発見し得る、および／または発見し得ないことに関する）発見のための近接性情報またはロケーション情報を含む情報の転送を含むことができる。
【００５７】
加えて、モバイルネットワークは、効果的なサービス差別化を可能にし得る機能を有するように進化してきており、または現在も進化し続けている。サービス差別化についてのそのような進化の例は、以下のうちの１または複数を、すなわち、ＱｏＳ最適化のために、バルクオフロードだけではなく、ＷｉＦｉも使用し得ること、互いの範囲内にいるＵＥの間に直接デバイスツーデバイス（Ｄ２Ｄ）接続をセットアップし得ること、ロケーションおよび時刻などのコンテキスト情報に基づいてサービスをカスタマイズし得ること（例えば、送信先エンドポイント）のうちの１または複数を含むことができる。例示的な実施形態では、アプリケーションは、ネットワークがアプリケーションによるネットワークリソースの使用に応じて課金および／または料金請求し得るように、そのようなサービスを差別化し得る。
【００５８】
そのような発展は、モバイルネットワークがアプリケーションに提供し得るＱｏＳが、アプリケーション自体、モバイルサービスおよび／もしくはアプリケーションサービスへのユーザの加入、「オンライン」状態にあり、ユーザに物理的に近接しているユーザの「友人」が存在するか、それとも存在しないか、ならびに／または様々な他のコンテキスト要因に（例えば、著しい程度で、または特定の程度で）依存し得る、未来を指し示すことができる。そのようなアプリケーションに固有の、コンテキストに依存したエクスペリエンスを可能にするために、アプリケーションが提供し得る特定のサービスをサポートし得るアプリケーションサービスプロバイダと、実際の接続性を提供し得るモバイルサービスプロバイダとの間で、新しいタイプの対話が使用され得る。そのような対話の性質は、本明細書で説明され得る。
【００５９】
実施形態では、提供され得る、および／またはユーザによって使用され得る、そのようなサービスおよび／または対話は、いくつかの特徴に従って分類され得る。そのような特徴の第１は、誰がサービスを使用し得るかに関連し得る。そのような実施形態では、サービスは、以下のうちの１または複数を含むことができる３つの広範なカテゴリにグループ化され得、すなわち、それらは、インターネットアクセスを目的とするテザリング（またはカバレージ拡張という密接な関連がある概念）など、誰にでも利用可能であり得る無差別なサービスまたはそのようなタイプのサービス、対話型ゲームおよび／またはオンラインコラボレーションなどの同じサービスを共用し得、事前定義され得る（例えば、既存のＣｏｍｐＮａｍｅ＋Ｃｉｒｃｌｅ）、または他のどのユーザとサービスを共用したいかを指定することによってサービスセットアップ時にユーザによって定義され得る、ユーザの閉鎖的なグループまたは一般に明確に定義された通常は小規模なグループ、ならびに閉鎖的なグループが単一のユーザになるように制限され得る場合に、閉鎖的なグループのサービスの特殊なケースとして扱われ得るサービスのタイプとすることができる、健康管理および購入されたオンラインコンテンツの「迅速」ダウンロードなど、特定のユーザに固有のユーザまたはサービスである。本明細書で説明されるように、「閉鎖的なグループ」のサービスは、「ユーザ固有」のサービスを含むことができる。
【００６０】
そのようなサービスおよび／または対話の第２の特徴は、それらに関連付けられたカスタマイズのレベルとすることができる。そのような実施形態では、サービスは、汎用または調整（例えば、個人化）として差別化され得る。汎用は、各セッションが他の１または複数のセッションと、広い範囲にわたって、同じまたは類似の特徴を有し得る、サービスを含むことができる。例えば、電子書籍ブラウズおよび購入セッション（例えば、ＡｍａｚｏｎのＫｉｎｄｌｅ）は、そのようなセッションを開始し得、非常に長い時間にわたってセッションを維持し得るユーザについて、ほぼ同じ送信先（例えば、Ｋｉｎｄｌｅサーバファーム）およびＱｏＳ使用（例えば、要件）を有し得る。
【００６１】
調整されたサービスは、あらゆるセッションが異なり得る、サービスを含むことができる。例えば、対話型ピアツーピアゲームの各セッションは、異なる場所にいる異なるユーザを含むことができ、接続性を確立するために異なるタイプの最適化を使用し得る。そのようなタイプのサービスは、調整されたサービスとすることができる（例えば、調整と呼ばれることがある）。別の例は、ユーザが購入した書籍の迅速ダウンロードを要求し得る場合とすることができる。ダウンロードは、そのユーザのコンテキスト（例えば、支払った料金、場所、利用可能なネットワーク、およびコンテンツサイズなど）に応じて最適化されなければならないので、電子書籍ダウンロードは、調整されたサービスとすることができる（例えば、調整と呼ばれることがある）。
【００６２】
調整されたサービスの２つの特徴は、そのようなサービスが通常は、閉鎖的なグループ向けであること、および／または短期間であることとすることができる。例えば、汎用「電子書籍」サービスと、「Ｊａｎｅ  Ｄｏｅが彼女の現在地であるＪＦＫ国際空港の１番ターミナルで今から２分以内に「戦争と平和」を１部獲得し得るように設計された電子書籍ダウンロード」は、様々な相違を含むことができる。前者は、長い期間にわたって、複数の場所にいる多くのユーザに対して、基本的に同じであり続け得る。したがって、アプリケーションプロバイダとネットワークオペレータが、このサービスがどのように処理され得るかについてオフラインで「事前ネゴシエート」し、ポリシおよび手順をネットワーク機器およびユーザデバイスに事前プログラムすることが可能であり得る。後者のサービスは、それを使用し得る特定のユーザのために特定の場所においてサービスが使用され得る時間の範囲が狭く、その範囲の外では無意味であり得る。そのようなサービスを事前セットアップしようとする試みは失敗するであろう。したがって、アプリケーションサービスとネットワークオペレータの間の何らかの自発的なリアルタイムオンラインネゴシエーションが使用され得る。そのようなタイプのネゴシエーションは、本明細書で説明され得る。
【００６３】
一例では、アプリケーションサービスプロバイダとモバイルネットワークオペレータの間のネゴシエーションのための調整されたサービスセットアップは、本明細書で説明されるような閉鎖的なグループの調整されたサービスにおいて、ならびに／または同様に無差別的もしくは汎用的なサービスにおいても、定義および／または適用され得る。
【００６４】
加えて、本明細書で説明されるように、アプリケーションサービスに関連付けられたモバイルネットワークサービスは、リアルタイムで生成され、管理され得る。本明細書で開示される実施形態を定式化する場合、モバイルネットワークと想定されるアプリケーションサーバとの間の対話に関して、様々な対話、仮定、または特徴が提供され、および／または使用され得る。例えば、一実施形態では、アプリケーションサーバ（ＡｐｐＳｅ）とモバイルネットワークの間の合理的な対話が提供され得る。そのような対話は、存在し得る、または存在すると仮定され得る、確立されたビジネス関係を使用し得る。加えて、実施形態では、ＵＥまたはモバイルデバイスは、それらがサービス契約を有し得るアプリケーションサーバにアクセスし得るが、モバイルネットワーク（ＭＮ）は、例えば、モバイルオペレータとアプリケーションサーバ（もしくはアプリケーションエンティティサーバ）のオペレータとの間の（例えば、ビジネス関係などの）関係が欠如している（ならびに／または相手に知られているＭＮおよび／もしくはアプリケーションサーバの証明書が欠如している）せいで、そのようなアプリケーションサーバにアクセスし得ないことがある。そのような関係の欠如は、同じ機能を提供するために使用され得る（例えば、ＭＮとアプリケーションサーバの間のアクセスを可能にし得、標準化され得る、または標準化され得ない）（例えば、本明細書で開示される）実施形態および機能をもたらすことができる。
【００６５】
上で説明されたように、（例えば、「ソケットインターフェース」（例えば、アプリケーションプログラミングインターフェース（ＡＰＩ））を使用して、ＩＰアドレスを通して、互いに通信し得るアプリケーションなどの）アプリケーションは、それらを実行しているであろうデバイスの物理的コンテキストを認識するように設計され得ない。例えば、アプリケーションは、デバイスに関連付けられたＭＡＣアドレスを認識すること、特定のデバイスに対する他のデバイスの近接性についての情報を認識すること、および使用または提供され得る下層のアクセス制御メカニズムを認識することなどができない。他方、モバイルネットワークは、ネットワーク内のデバイス、およびそれらの物理的特性を認識し得る（例えば、デバイスの物理的近接性は、モバイルネットワークが当然所有し得る情報のタイプとすることができる）。モバイルネットワークは、ＩＰアドレスをデバイスに割り当てること、および例えば、デバイスが移動するときなど、ＩＰアドレスのシームレスな接続性を保証し、不変性も保証することに責任をもつこともできる。しかしながら、モバイルネットワークは、ユーザが提供され得るＩＰ接続性をどのように使用するかについては最低限の認識を有し得るにすぎない。そのため、モバイルネットワークは、ＩＰデータストリームを個々の「アプリケーションフロー」に差別化して分けることはできるとしても、１または複数のユーザに関連付けられた、アプリケーション識別情報、プリファレンス、およびソーシャルアソシエーションなどを認識し得ない。
【００６６】
加えて、モバイルネットワークは、特定のアプリケーションフローを識別し、それをいくつかのアプリケーションサービスに関連付けることができるが、そのようなフローに、差別化ＱｏＳを提供すべき場合に、どの差別化ＱｏＳを提供すべきかを知り得ない。上で説明されたように、そのような情報は事前構成され得る。しかしながら、そのような情報の事前構成は、突然サービスが生じるまで、サービスについて何も分からないので、事前構成が可能でないことがある、調整されたサービスに対しては機能し得ない（例えば、失敗することがある）。そのため、そのような実施形態において、（例えば、本明細書で説明されるような）方法、技法、またはプロセスが提供され得る。
【００６７】
本明細書では、近接性発見またはＤ２Ｄリンク確立などのＰｒｏｘｉｍｉｔｙサービスが（例えば、アプリケーションに代わって）アプリケーションサービスの一環として提供されることを可能にする、実施形態が開示され得る。
【００６８】
例えば、実施形態（例えば、第１の方法または手順）では、アプリケーションとネットワークまたはＤ２Ｄサーバなどのサーバとの間における一時サービス名の確立を可能にする、アーキテクチャおよび関連する手順が提供され得る。そのような実施形態は、ＵＥおよびネットワークが、おそらくはアプリケーションの直接的な関与なしに、そのようなサービスを後で実行することを可能にし得る。
【００６９】
別の実施形態（例えば、第２の方法または手順）では、アプリケーションは、Ｄ２Ｄサービスの実行中、関与し続け得る。そのような実施形態では、一時サービス名は、使用されなくてよい。代わりに、ＭＮＯによって提供される中間識別情報（例えば、ブートストラップＩＤ（Ｂ−ＴＩＤ）またはオープンＩＤ）が提供および／または使用され得る。そのような実施形態では、アプリケーションは、ユーザ名を中間識別情報に変換し得、その後、ネットワークに送信されるＤ２Ｄ要求において、そのような識別情報を使用し得る。加えて、実施形態によれば、中間識別情報がＵＥ上のアプリケーションに提供され得た場合、アプリケーションは、発見中に関与し続けることを必要としなくてよい。
【００７０】
加えて、両方の実施形態は、相補的とすることができる。例えば、アプリケーションは、（例えば、第１の方法または手順において）Ｄ２Ｄ動作とは独立とすることができ、ＵＥドリブンモデルを可能にするが、アプリケーション内でのＰｒｏｘｉｍｉｔｙサービスのより踏み込んだ統合が、（例えば、第２の方法または手順において）可能にされ得る。さらに、両方の実施形態は、様々な利点を有することができる。例えば、第１の方法または手順は、ユーザが、アプリケーションにログオンせずに、ＰｒｏＳｅに従事することを可能にし得、それは、バッテリ消費とシグナリングにおけるネットワークトラフィックを低減させ、およびアライブメッセージを保つことができる。第２の方法または手順は、アプリケーションが、ＰｒｏＳｅサービスの料金を、また特定のイベントが、例えば、発見の試みおよび発見の成功などの料金を、どのように（例えば、いくら）課され得るかを含む、アプリケーションのリアルタイム制御を可能にし得る。
【００７１】
第１の方法または手順では、Ｄ２Ｄネットワークサービスなどのサービスは、ＱｏＳ差別化のために使用され得る。そのようなサービスは、アプリケーションＱｏＳを差別化するために使用され得る。加えて、実施形態では、例示的なアプリケーションは、ユーザ（または人々）のグループの間でプレーされ得る、対話型ゲーム（例えば、ＧａｍｅＮａｍｅ）を含むことができる。そのようなアプリケーションまたは対話型ゲームでは、グループは、（例えば、目標として）中世の都市国家を建設および／または維持するなどの目標または目的を実行および／または実施し得、ゲームサーバによってシミュレートされ得る攻撃から、それを守り得る。加えて、都市は、参加者の閉鎖的なグループに関連付けることができ、グループどうしは、対話し得ない。実施形態では、グループの一人のプレーヤがオンラインであり、プレーし得ている場合、その都市に関連付けられたセッションは、アクティブであり得る。そのため、ゲームは、プレーヤ間のデータレートを高くし、待ち時間を短くするために、ＱｏＳが高い接続を使用し得、プレーヤが直接無線（Ｄ２Ｄ）リンクを確立し得る場合は、いくつかの機能が可能にされ得る。
【００７２】
実施形態では（例えば、第１の方法または手順を実行する場合）、モバイルネットワーク（ＭＮ）からアプリケーションサーバ（ＡｐｐＳＥ）へのインターフェースが提供および／または使用され得る（例えば、存在し得る）。そのような実施形態では、リアルタイムサービスネゴシエーションは、以下のように提供され得る。アプリケーションサーバは、以下のことを、すなわち、他のアプリケーションユーザを参照するために、またはそれと交信するために、各アプリケーションユーザによって使用され得るサービスおよび識別情報を使用することを許可されたユーザのリスト、コンテキスト固有の情報（例えば、ロケーション制限）などを含む、サービスのＱｏＳ要求または要望、ならびに（例えば、料金が請求され得る）モバイルネットワークプロバイダによるそのようなサービスの提供が行われる適用可能なビジネス期間を知り得、または一般に認識し得る。
【００７３】
加えて、アプリケーションサーバは、新しいサービスを確立するために、モバイルネットワークに要求または要望（例えば、必要）を通知し得る。そうする際、アプリケーションサーバは、サービスのパラメータ（例えば、ＱｏＳ差別化要望（または要求）、ならびに手段およびロケーション制限など）をネゴシエートし得る。加えて、アプリケーションサーバは、どのユーザがサービスの使用を許可され得るかを、ネットワークに分からせることもできる。例えば、アプリケーションサーバは、ＧａｍｅＮａｍｅセッションなどの新しいアプリケーションまたはゲームセッションが開始し得たこと、この特定のセッションがＤ２Ｄリンク上で動作し得る（例えば、それがゲームのＤ２Ｄ機能（例えば、Ｄ２Ｄ限定機能）のためのセッションであり得る）ことを、ネットワークに通知し得る。
【００７４】
実施形態では（例えば、サービスが無差別的でない限り）、（例えば、特定のユーザの）ユーザ識別情報が、（例えば、ＭＮからＡｐｐＳｅへのインターフェースが存在し得る場合）使用されることがあり、または使用されなければならないことがある。例えば、アプリケーションサーバは、開始されたセッションにどのユーザが参加し得るかを、ネットワークに通知しなければならないことがある。その結果、アプリケーションによって使用されるユーザＩＤは、ネットワークによって使用されるユーザＩＤに関連付けることができる。例えば、アプリケーションサーバおよびネットワークプロバイダは、ネットワークプロバイダによって使用されるＩＤを生成すること、および／またはそれを持続的なアプリケーション識別情報（例えば、本明細書で説明されるような、アプリケーションサーバにおけるユーザの識別情報）に関連付けることができる。加えて、アプリケーションおよびモバイルネットワークの両方によって信頼され得る、サードパーティ識別情報プロバイダが使用され得る。オープンＩＤプロトコルは、そのような連合識別情報管理サービスをサポートし得る、プロトコルの例とすることができる。実施形態では、ネットワークプロバイダによって使用され得る識別情報は、２以上のネットワークプロバイダにわたっても使用可能であり得る。例えば、グループ内の１つのユーザは、１つのＭＮＯによってアプリケーションサービスを提供され得、同じグループ内の別のユーザは、別のＭＮＯによってアプリケーションサービスを提供され得、識別情報は、ＭＮＯにわたって一致され得、例えば、アプリケーションサーバにおける、単一の一意的な識別情報まで遡り得る。加えて、実施形態では、そのような識別情報は、オープンな（例えば、無差別的な）発見のためにさえも有益であり得る。例えば、そのような識別情報は、ＵＥまたはユーザによって発見され得るが、依然として識別子を使用すること、または必要とすることがある、商業的な広告のために使用され得る。
【００７５】
アプリケーションサービスとネットワークプロバイダが、新しいサービスの確立についてネゴシエートし得た後、一時サービス名が、与えられたネットワークプロバイダに関連付けられたサービスのために生成され得る。アプリケーションプロバイダは、このサービス名を、この特定のネットワークオペレータを利用し得るユーザの各々に提供し得る。実施形態では、この点では、アプリケーションプロバイダの役割は、限られたものであり得る。例えば、アプリケーションプロバイダは、セッションが変更される必要があり得る（例えば、ユーザがオンラインになり、または退出したために、セッションＱｏＳが再ネゴシエートまたは終了され得る）場合に呼び出され、または使用され得る。それとは別に、新たに生成されたサービスは、事前ネゴシエートされたＱｏＳ（例えば、事前ネゴシエートされたＱｏＳ要求、要望、または必要）を用いる汎用的な「命名された」サービスとして、ネットワークによって扱われ得、ネットワークは、そのようなサービスのための接続性管理を引き継ぎ得る。
【００７６】
本明細書で説明されるように、実施形態では、アプリケーション識別子（ＩＤ）とネットワークＩＤの間のマッピングは、一対一とすることができる。あるいは、実施形態では、単一のネットワーク識別情報と複数のアプリケーション識別情報の間の一対多マッピングが、提供および／または使用され得る。これは、識別情報を維持および更新するために使用され得る、ネットワークシグナリングを節約し得る。このタイプのマッピングを用いて行われる発見は、コンテキストが、発見が行われ得たアプリケーションのうちのどれのものかを一意的に識別し得ないことがある。そのため、手順および／または方法では、発見後に、追加のアクションが提供され得る。例えば、アプリケーションは、そのようなサーバまたはアプリケーションのどれがさらなるアクションを取るべきかを決定するために、それぞれのアプリケーションサーバと交信し得る。加えて、実施形態では、ＵＥは、（例えば、サービスのためのセッションを開始する場合、および／またはそれに参加する場合）安全な通信チャネルを確立し得、その後、互いの間で（例えば、曖昧さが存在し得ない）アプリケーション識別情報を交換し得る。
【００７７】
ネットワークオペレータは、ＵＥおよび他のネットワーク機器が従い得るポリシおよび／または手順において、サービス名を使用し得る。例えば、実施形態では、Ｄ２Ｄサービスを可能にすることは、Ｄ２Ｄを使用するフローのために、ＵＥによって特定の組のＩＰアドレスを使用することを含むことができる。そのような実施形態では、ネットワークは、例えば、特定のセッションに関連付けられたアプリケーション（例えば、ＧａｍｅＮａｍｅアプリケーション）によって開始されたフローが、Ｄ２Ｄ対応ＩＰアドレスおよび送信元ＩＰを使用し得ることを、ＵＥに知らせることができる。
【００７８】
別の例示的な実施形態では（例えば、第１の方法または手順を実行する場合）、ＭＮからアプリケーションサーバ（ＡｐｐＳｅ）へのインターフェースが、提供および／または使用されないことがある（例えば、存在しないことがある）。そのような実施形態では、（例えば、リアルタイムの）サービスネゴシエーションが、以下のように提供され得る。アプリケーションサーバは、以下のことを、例えば、サービスおよびそれらの識別情報を使用することを許可されたユーザのリスト、コンテキスト固有の情報（例えば、ロケーション制限）などを含む、サービスのＱｏＳ要求または要望、ならびに請求を含むモバイルネットワークプロバイダによるそのようなサービスの提供が行われる適用可能なビジネス期間などの、パラメータまたは情報を知ることができ、または一般に認識し得る。
【００７９】
実施形態によれば、モバイルネットワークオペレータ（ＭＮＯ）に登録され得る、ＵＥおよびＷＴＲＵなどのモバイルデバイスは、ＡｐｐＳｅに安全にアクセスし得、それ（例えば、ＡｐｐＳｅ）を用いて、上で説明されたパラメータを確立し得る。これらのパラメータを確立した後、パラメータは、その後、デバイス上に記憶され得る。
【００８０】
加えて、アプリケーションに関連するサービスに関心があり得るＵＥは、ネットワークまたはＭＮＯと交信し得、新しいサービスを要求し得る。サービスタイプおよびパラメータなどの１または複数のパラメータが、（例えば、新しいサービスを要求するために）提供および／または使用され得る。例示的な実施形態では、サービスパラメータは、以下のうちの１または複数を、すなわち、サービスのために交換されるデータの性質（例えば、「ベストエフォート」）、リンクタイプ（例えば、ＰｒｏＳｅ）、それに対するサービスが望まれ得る個人ユーザまたはユーザのグループを示す指示子、およびＵＥが参加することを要望または望み得る既存のサービスの一時名などのうちの１または複数を含むことができる。
【００８１】
本明細書で説明されるように、実施形態では、特定のユーザ識別情報などのユーザ識別情報が、（例えば、ＭＮからＡｐｐＳｅへのインターフェースが存在しないことがある場合に）提供および／または使用され得る。例えば、アプリケーションサーバは、どのユーザが開始されたセッションに参加し得るかを、ＵＥ上に記憶しなければならないことがある。そのため、アプリケーションによって使用され得るユーザＩＤは、ネットワークによって使用され得るユーザＩＤに関連付けることができる。例えば、アプリケーションサーバおよびネットワークプロバイダまたはＭＮＯは、ネットワークプロバイダによって使用され得るＩＤを生成すること、および／またはそれを持続的なアプリケーション識別情報に関連付けることができる。加えて、実施形態では、アプリケーションおよびモバイルネットワークの両方によって信頼され得る、サードパーティ識別情報プロバイダが使用され得る。例示的な実施形態によれば、ネットワークによって使用され得るＩＤとともに、またはそれに加えて、発見されたＵＥによって送信され得る第２のＩＤが存在し得る。２つのＩＤの間のマッピングは、例えば、一対一とすることができ、ネットワークに知られ得る。実施形態では、一時識別情報（例えば、一時サービス名）は、アプリケーション自体によって提供され得、すなわち、アプリケーションサーバは、アプリケーションプロバイダとしての役割に加えて、識別情報プロバイダの機能を引き受け得る。そのような実施形態では、オペレータネットワークとアプリケーションサーバの間で、オープンＩＤプロトコルが依然として順守され得る。
【００８２】
さらに、上で説明されたように、オープンＩＤプロトコルは、（例えば、ＭＮからＡｐｐＳｅへのインターフェースが存在しないことがある場合に）そのような連合識別情報管理サービスをサポートし得る、プロトコルの例とすることができる。実施形態では、ネットワークプロバイダによって使用され得る識別情報は、２以上のネットワークプロバイダにわたって使用可能であるようなものであり得る。例えば、グループ内の１つのユーザは、１つのＭＮＯによってアプリケーションサービスを提供され得、同じグループ内の別のユーザは、別のＭＮＯによってアプリケーションサービスを提供され得、識別情報は、ＭＮＯにわたって一致され得、アプリケーションサーバにおける、単一の一意的な識別情報まで遡り得る。
【００８３】
例示的な実施形態では、ＭＮＯは、アプリケーションの性質を知り得ないが、アプリケーションおよび関連するサービスパラメータへのアクセスがＵＥによって（例えば、直接的に）要求され得るので、それのための一意識別子を知り得る。異なるアプリケーションサーバにわたって一意的なアプリケーション識別子は、以下のうちの１または複数に従って生成され得、すなわち、サービスディレクトリ内に登録されたアプリケーション名を用いて、（例えば、混同を生じる低い確率を残し得るが、アプリケーションＩＤが発見のために使用され得、ＵＥ  ＩＤがそれから推測され得ない場合は、そのような混同の影響は深刻ではあり得ない）長いランダム識別子を使用して、サードパーティからリアルタイムで受信および／または獲得され得るアプリケーションおよび／またはサービス識別情報（例えば、おそらくは、それがＵＥ加入者識別情報を検証し得るのと同時に、オープンＩＤ）を用いて生成され得る。
【００８４】
加えて、識別子が、以下のうちの１または複数を使用して生成され得る。実施形態では、アプリケーション名は、ＵＲＬアドレス、例えば、ａｐｐ−ｓｕｂ−ｔｙｐｅ．ａｐｐ−ｔｙｐｅ＠ｃｏｍｐａｎｙ．ｔｙｐｅ−ｏｆ−ａｐｐに類似した、標準化された方法で登録され得る。例えば、チェスアプリケーションは、以下を、すなわち、ｆａｓｔ−ｃｈｅｓｓ．ｃｈｅｓｓ−ｏｎｌｉｎｅ＠ｃｈｅｓｓ−ｉｓ−ｕｓ．ｇａｍｅｓを登録し得、これは、アプリケーションの一意的な参照または識別子とすることができる。加えて、ランダムなアプリケーション識別子が、アプリケーションによって生成され、ユーザＩＤに追加され得る。そのようなランダムな識別子は、アプリケーション間のユーザＩＤ衝突の確率を小さくし得、より長いユーザＩＤをもたらし得る。別の実施形態では、オペレータがアプリケーションプロバイダに安全に料金を請求することを可能にするために、アプリケーションは、いくつかのソースのいずれかまたは組み合わせから、暗号化されて安全な識別子を獲得し得る。これらの暗号化されて安全な識別子は、偽造または複製することが可能であり得ず、支払いの証拠として使用され得る。例えば、これらの識別子は、サードパーティビジネスエンティティ（例えば、クレジットカード会社、および支払いを示し得るＩＤ）、ならびに／またはモバイルオペレータを含むことができ、ＩＤは、モバイルネットワークとの対話を通して、および／またはそのような対話の外で提供され得る。（例えば、ＭＮとＡｐｐＳｅの間にインターフェースが存在し得ない場合であっても）ＵＥおよびネットワークプロバイダが、新しいサービスの確立をネゴシエートし得た後、一時サービス名が、本明細書で説明されるように、サービスのために生成され得る。サービス識別情報が、本明細書で説明されるように、提供および／または使用され得る。サードパーティから受信または獲得され得るサービス識別情報は、本質的に一意であり得、したがって、ネットワークプロバイダにわたって使用され得る。加えて、他のサービス識別情報も、提供および／または使用され得、ネットワークプロバイダ内で一意であり得る。ＵＥは、一時サービス名を認識し得、それ（および／または他のＵＥの他の一時サービス名）をＡｐｐＳｅに提供し得る。
【００８５】
アプリケーションプロバイダは、このサービス名を１または複数のユーザに提供し得、それらのユーザは、セッションまたは対話またはサービスに参加し得るようになる。上で説明したように、この点では、アプリケーションプロバイダの役割は、限られたものであり得る。例えば、それは、セッションが変更され得る場合（例えば、ユーザがオンラインになり、または退出して、セッションＱｏＳが再ネゴシエートされ得る場合、セッションが終了され得る場合など）に関わらされ、または使用され得る。それとは別に、新たに生成されたサービスは、事前ネゴシエートされたＱｏＳを用いる汎用的な「命名された」サービスとして、ネットワークによって扱われ得、ネットワークは、このサービスのための接続性管理を引き継ぎ得る。
【００８６】
ネットワークオペレータおよびそれのＭＮは、ＵＥおよび他のネットワーク機器が従い得るポリシおよび手順において、サービス名を使用し得る。例えば、実施形態では、Ｄ２Ｄサービスを可能にすることで、Ｄ２Ｄを使用し得るフローのために、特定の組のＩＰアドレスがＵＥによって使用されるようにすることができる。そのような実施形態では、ネットワークは、特定のセッションに関連付けられた、ＧａｍｅＮａｍｅアプリケーションなどの、アプリケーションによって開始されたフローが、Ｄ２Ｄ対応ＩＰアドレスおよび送信元ＩＰを使用し得ることを、ＵＥに知らせ得る。ネットワークは、同じサービスの一部であり得る複数のＵＥからの情報を照合および調整することもでき、ユーザリストおよびポリシなどにおける不一致を管理し得る。
【００８７】
図２は、ネットワークを使用してアプリケーションによって提供されるセッションに参加することを例えば望み得るデバイスを発見するために使用され得る、サードパーティサービスアクセス方法、手順、またはプロセスの例示的な実施形態を示している。図２に示されるように、実施形態では、ＵＥに先在するインターネットプロトコル（ＩＰ）接続性が、ネットワークによって管理され得る。例えば、２０２において、ＩＰベアラが、ＵＥ２０１またはＷＴＲＵ１０２ａ〜ｄなどのＵＥと、ネットワーク２０３または図１Ａ〜図１Ｅで説明されたネットワークなどのネットワークとの間でセットアップされ得る。ＵＥとネットワークまたはそれのネットワークプロバイダとの間の交換も、そのようなＩＰ接続性上のアプリケーションレイヤプロトコルを使用し得る。加えて、ネットワークオペレータとサービスプロバイダの間の通信のためのプロトコルが使用され得る。そのようなプロトコルは、ＨＴＴＰ、ＨＴＭＬ、ＸＭＬ−ＳＯＡＰ、および／または他の任意の適切なプロトコルなどの、１または複数の既存のプロトコルを含むことができる。本明細書で説明されるように、ネットワークとアプリケーションサーバの間の対話を含む、交換のコンテキストが定義され得る。
【００８８】
図２に示されるように、ＵＥは、その後、アプリケーションサーバ２０５などのアプリケーションサーバ、およびそれのサービスプロバイダと交信し得る。例えば、実施形態では、２０４において、ＵＥは、対話型ゲームのセッションを開始すること、またはそれに参加することを求める要求をアプリケーションサーバに送信し得る。要求は、ＵＥが利用可能であり得、ＵＥがアプリケーションサーバによって提供されるセッションまたはサービスに参加することを望んでいることを示す表示をアプリケーションサーバに提供すること、またはそれを含むことができる。要求は、ＵＥ、および／またはそれが参加することを望み得るサービスもしくはセッションについての適切な情報も提供し得る。例えば、要求内のサービスプロバイダが利用可能な情報は、ＵＥによって使用され得るネットワークオペレータを含むことができる。実施形態では、要求を受信した後、サービスプロバイダまたはアプリケーションサーバのアプリケーションプロバイダは、それがネットワークおよびネットワークオペレータ（例えば、ＭＮＯ）との関係を有し得るかどうかを検証し得、関係が存在し得る場合は、サービスがサポートされ、要求が果たされるようになり得る。そのような検証を実行するために、サービスまたはアプリケーションプロバイダは、２０４において受信された要求内の情報に照らして、それが関係を有し得るオペレータのリストをチェックし得、情報がリスト内のオペレータと一致する場合、これを１つのそのようなオペレータとして識別し得る。別の実施形態では、関係が存在し得ない場合であっても、サービスがサポートされ得、Ｄ２Ｄなどのオプションを通してサポートされる拡張ＱｏＳが、ネットワークオペレータとサービスプロバイダの間の協調を提供または可能にするために使用され得る。
【００８９】
本明細書で説明されるように、２０６において、サービス開始およびネゴシエーション手順が、（例えば、ＭＮからＡｐｐＳｅへのインターフェースが存在し得る場合に）実行され得る。例えば、実施形態では、サービスプロバイダが、ＵＥを、ゲームセッションなどのセッション、対話、またはサービスに参加する、ネットワークプロバイダからの最初のＵＥとして識別し得る場合、サービスプロバイダは、２０８において、ネットワークのユーザのための新しいサービスを開始または始動するために、ネットワークに要求を送信し得る。例えば、２０４においてアプリケーションサーバによって受信され得る、セッションに参加することを求めるＵＥの要求に応答して、セッションが開始され得ていない場合は、ＵＥは、２０８において、新しいサービスを開始するようにプロバイダに要求し得る。
【００９０】
その後、２１０において、ネットワークとサービスプロバイダの間のサービスネゴシエーションが後続し得る。サービスネゴシエーションにおいて、セッションおよび／またはサービスのためのパラメータが、アプリケーションサーバとネットワークの間で交換され得る。加えて、アプリケーションサーバは、（例えば、２０４において）要求がそこから受信され得たＵＥがどのようにセッションまたはサービスに加えられ得るかを、ネットワークに知らせること、または伝えることができる。例示的な実施形態では、サービスネゴシエーションは、以下のサービスパラメータのうちの１または複数についての合意を確立または生成することを含むことができ、サービスパラメータは、サービス名（例えば、一時サービス名）、ユーザおよび／もしくはＵＥ識別情報、サービスに関連付けられたデータ通信に対する適切な請求および／もしくは課金のために使用され得る請求および／もしくは課金参照番号、サービスセキュリティパラメータ（例えば、データの保護および認証などがどの程度行われ得なければならないか）、特定のネットワーク接続性要件、例えば、Ｄ２Ｄ使用：＜必須；好ましい；優先されない；可能な場合は避ける；禁止＞、ＷＬＡＮ使用：＜必須；好ましい；優先されない；可能な場合は避ける；禁止＞などを含むサービスＱｏＳ要件、大域的、事前定義されたエリアに限定的、ネットワークサブセット、およびサービスが開始され得る特定のアクセスエリアに限定的などの、ローカライゼーションパラメータ、サービス開始時間および終了時間（例えば、サービスがアクティブであり得る、および／もしくは失効せずに未使用であり続け得る期間）などの、時間制限、ならびに／または他の任意の適切なパラメータである。
【００９１】
例示的な実施形態によれば、アプリケーションサーバまたはそれのプロバイダによって提供されるサービスのためのセッションがすでに開始され得ている（例えば、ＵＥがセッションをすでに開始し得ている）場合、２１０におけるサービスネゴシエーションは、セッションに参加することを要望し得る後続のＵＥのために、再び実行されることを必要としなくてよい。代わりに、後続のＵＥは、上で説明したように、２０４において、セッションへの参加を求める要求をアプリケーションサーバに送信し得、アプリケーションサーバは、サービスネゴシエーションを実行する代わりに、後続のＵＥがセッションに参加する権限を与えられているかどうかを判定し得る。
【００９２】
サービスネゴシエーションを実行した後、および／またはサービスネゴシエーションの最中に、２１２において、サービス名が生成され、ネットワークからアプリケーションサーバに送信され得る。実施形態では、サービスの命名は、一意的であり得る。加えて、実施形態では、サービス名は、本明細書で説明されるように、ユーザ名、もしくはアプリケーションサーバによって提供されるアプリケーションに関連付けられた証明書とは独立であり得、ならびに／またはＵＥおよび／もしくはネットワークに関連付けられたネットワーク識別子とは独立であり得る。例えば、ネットワークおよび／またはアプリケーションサーバは、アプリケーションサーバにログオンするユーザ、またはネットワークにアクセスするＵＥによって使用される実際の証明書を交換することなく、サービス名を使用して、セッションまたはサービスを開始し得る。
【００９３】
例えば、選択された名前は、ネットワークオペレータおよびアプリケーションプロバイダを用いる、アクティブであり得る（または最近アクティブであり得た）多数の他のサービスに対して、一意的であり得る。加えて、実施形態では、名前内のソーシャルネットワーク要素、サービスを生じさせるアプリケーション、およびユーザグループなどの識別も、提供または使用され得る。例えば、新しいＧａｍｅＮａｍｅゲームセッションが、ユーザのグループ（例えば、ＣｏｍｐＮａｍｅ＋ｃｉｒｃｌｅ、サークルのメンバがプレーヤであり得る）に関連付けられ得ると仮定する。結果のセッションは、ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃと命名され得、ここで、ＣｏｍｐＮａｍｅは、サービスを提供するソーシャルネットワークサービスの名前とすることができ、ＧａｍｅＮａｍｅは、Ｐｒｏｘｉｍｉｔｙサービスのための一意名とすることができ、ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺは、閉鎖的なユーザアクセスグループを表すＣｏｍｐＮａｍｅ＋ｃｉｒｃｌｅの名前とすることができ、Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃは、アプリケーションセッションの名前とすることができる。実施形態では、「Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ」は、ランダムに生成された文字列を表し得る。そのようなランダムに生成された文字列は、セッション名の一意性を、これらが生成および破棄されるときに保証するために使用され得る。ランダムに生成された文字列も、衝突の可能性が十分に低くなり得るように、十分に長くすることができる。あるいは、サービス（例えば、アプリケーション）プロバイダとネットワークプロバイダの間の一意的な識別子（例えば、「ＳｅｒｖｉｃｅＮｅｔＩＤ」）は、長期的な関係の一部として、ネットワークとアプリケーションサーバの間でネゴシエートされ得る。加えて、調整された一時セッションが、（例えば、衝突を回避するのに十分な長さであり得る識別子を生成するために）ランダムに生成された文字列をそのようなセッションのための識別子に追加することによって識別され得、および／または十分に増大することを可能にされ得たシーケンス番号が、定められた期間内の繰り返しを回避するために使用され得る。加えて、意味のある一意的なサービス名および／または識別子を保証する他の代替策も使用され得る。本明細書で（例えば、以下で）説明されるように、特定のサービスセッションを識別するために一意名が生成され得る限り、（例えば、形式における特定性のために記述のコンパクト性を犠牲にした）上記のものの１または複数の適切な変形も使用され得る。
【００９４】
実施形態では、一時サービス名およびそれのレジストリが、各名前がアプリケーションにわたって一意的であり得ることを保証するために構成され得る。例えば、上で説明されたように、例えば、Ａ．Ｂ＠Ｃ．Ｄなどのアドレス形式を指定することによって、ＵＲＬ規約または形式を使用して、名前が構成され得る。そのような実施形態では、「Ｄ」は、「．ｇａｍｅ」、「．ｄａｔｅ」、「．ｍｅｅｔ」、または「．ｍａｃｈｉｎｅ」など、アプリケーションのタイプを示すトップドメイン名とすることができる。これらは、固定された意味を有するように業界によって合意され得、または恣意的とすることができる。「Ｃ」は、会社によって使用されるドメイン名とすることができ、すなわち、会社は、（まだ使用され得ていない）任意の名前を使用することを決定し、それを登録し得る。ひとたび登録されると、名前は、別のアプリケーションによって使用され得ない。加えて、オプションとすることができる「Ａ」および「Ｂ」は、アプリケーションに固有とすることができ、登録されることを必要としなくてよく、「サブ」タイプを定義するために使用され得る。加えて、（ｈｔｔｐ：／／ｘｘｘ．ｘｘ／ｚｈｔｊｋ）などの短いＵＲＬ形式は、アプリケーション（ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＣｉｒｃｌｅｘｙｚ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ）のための短いＵＲＬとすることができる。そのような短いＵＲＬは、ドメイン内に登録され得、与えられたドメイン内で、局所的に、動作の範囲内で、および／または大域的に、一意的とすることができる。実施形態では、そのような一意性は、すでに割り当てられた、アプリケーションの記憶された識別情報をチェックすることによって、可能にされ得る。変形として、一意性は、暗号化によって可能にされ得、アプリケーション識別情報は、部分的に、
ＲａｎｄｏｍＡｐｐＩｄ＝ＫＤＦ（固定されたシード，「ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＣｉｒｃｌｅｘｙｚ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ」）
Ａｐｐｌｄ＝ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＲａｎｄｏｍＡｐｐＩｄ
を使用して、導出され得る。
【００９５】
サービス名を生成した後、２１４において、ＵＥサービスアクセスが、ネットワークとアプリケーションサーバの間で交換され得、２１６において、サービス名および他の識別子が、アプリケーションサーバからＵＥに送信され得、ＵＥは、サービス名を使用してセッションに参加し得るようになる（例えば、ＵＥは、特定のユーザとの特定のセッションのための識別子を与えられ得る）。本明細書で説明されるように、Ｄ２Ｄでは、ＵＥは、それが特定のサービス名または識別子を有する特定のセッション内にあり得ること、およびそれが他のＵＥから利用可能であり得ることを、ネットワーク上の他のＵＥにさらに広告し得る。加えて、サービスのためのセッションに参加することを望み得る後続のＵＥが、そうする権限を与えられ得る場合、それらの後続のＵＥがサービスのためのセッションに参加し得るように、それらの後続のＵＥは、２１６において、サービス名を提供され得る（例えば、サービス名が、２１６において、それらのＵＥに送信され得る）。
【００９６】
例えば、サービス名がひとたび定義され得ると（またはそれがすでに存在し得る場合）、サービスプロバイダおよびネットワークプロバイダは、２１４において、任意の適切なプロトコルを使用して、サービスへのＵＥのアクセスをネゴシエートし得る。アクセス制御および／または認可が提供され得るような他の手法となり得る、オープンＩＤまたは（例えば、３ＧＰＰにおける）汎用ブートストラップアーキテクチャ（ＧＢＡ）などの、シングルサインオンソリューションがさらに使用され得る。そのようなプロセスが完了し得た後、または完了し得た場合、サービスプロバイダは、２１６において、所望のサービスセッションに対応し得るネットワークサービス名を用いて、ＵＥに応答し得る。
【００９７】
その後、ＵＥとモバイルネットワークは、（例えば、２１８において）サービス名および関連するパラメータを使用して、特定のサービスのための通信を管理し得る。実施形態では（例えば、サービス名および関連するパラメータを使用して、特定のサービスのための通信を管理するために）、拡張アクセスネットワーク発見および選択機能（ＡＮＤＳＦ）およびそれの概念が使用され得る。ＡＮＤＳＦは、ネットワークが、通信のためにどのアクセスネットワークを使用すべきかをＵＥに知らせ得る、ポリシフレームワークとすることができる。例えば、ＡＮＤＳＦは、システム間ルーティングポリシ（ＩＳＲＰ）を提供し得る。ＡＮＤＳＦ内にすでに存在し得るＩＳＲＰおよびそれの概念は、ポリシが特定のＩＰの５タプルに関連付けられ得るという意味で、そのような仕様が、ＩＰフロー固有であることを可能にし得、または許可し得る。そのようなＡＮＤＳＦおよび／またはＩＳＲＰならびにそれらの概念は、ポリシがアプリケーション名および送信先ドメイン名などによって指定されることを可能にし得、または許可し得る。したがって、例えば、新しい調整されたサービスが定義され得る場合、ＡＮＤＳＦポリシの更新が、そのようなサービスを使用し得るＵＥに提供され得る。実施形態では、更新は、ＵＥが、例えば、名前または送信先ドメインによって関連するアプリケーションを識別することを要求し得、または必要とし得、適切なポリシをＩＰフローに適用し得る。そのような実施形態では、アプリケーションは、提供されるアプリケーションサービスのためにユーザによって使用されるアプリケーションとすることができる。加えて、ポリシは、ネットワークによってネゴシエートされたような、サービスに関連するＱｏＳ仕様を反映し得る。ＵＥへのポリシの提供は、ＵＥが特定のサービス名についてのポリシ更新を要求し得るプル方法によって、またはネットワークが更新をそれを使用し得る１組のＵＥにプッシュし得るプッシュ方法によって行われ得る。実施形態では、特定のサービスを使用し得ないＵＥは、特定のサービスに関連するポリシを単に無視し得る。
【００９８】
加えて、本明細書で説明されるように、ＭＮからＡｐｐＳｅへのインターフェースが存在し得ない場合の、サービスネゴシエーション（例えば、２１０）が提供および／または使用され得る。例えば、ネットワークとアプリケーションプロバイダの間に正式なビジネス協定が存在し得ない、または提供され得ない、実施形態では、ＵＥは、アプリケーションとのサービスネゴシエーションを実行し得、サービス名、ユーザ識別情報、ＱｏＳ、および時間制約などを含む、初期の１組のサービスパラメータに合意し得る。ＵＥは、その後、これらのネゴシエートされたパラメータをネットワークに提供し得る。サービス名から、ネットワークは、ＵＥが新しいサービスを開始しようとしているのか、それとも既存のサービスに参加しようとしているのかを認識または判定し得る。ネットワークは、その後、ポリシを用いて、および（例えば、既存のサービスの場合は）既存の１組のサービスパラメータも用いて、ＵＥによって提供され得るサービス機能（例えば、要件）を調停し得る。例示的な実施形態によれば、ネットワークは、サービスのためのアクセスパラメータの最終決定者とすることができ、それをＵＥに提供し得る。ＵＥは、その後、サービスパラメータの変更について、アプリケーションサーバに通知し得る。例えば、ＵＥを通して、サービスパラメータをネットワークとネゴシエートするアプリケーションの能力は、サービスパラメータを求めるＵＥから出された要求に対するネットワークのサポートに依存し得る。
【００９９】
本明細書で説明されるように、ポリシ管理も提供および／または使用され得る。本明細書で使用され得るポリシプルプロセスまたは方法の例が、図３に示され得る。実施形態では、図３は、図２が停止または終了したところで（例えば、２１６においてサービス名を含むアプリケーションサーバからＵＥへの応答があったときに、および／または２１８においてネットワークサービスアクセスが管理され得るときに）開始し得る。図３に示されるように、ＵＥ２０１などのＵＥは、アプリケーション２０７などの（例えば、プロセスとして動作している）アプリケーション、およびＣＭ２０９などの接続マネージャ（ＣＭ）を含むことができる。
【０１００】
ＣＭは、ＵＥの通信上の必要または要望を自動化および管理するように設計された、一般に使用されるエンティティとすることができる。例えば、ＣＭは、通信のためのエアインターフェース（例えば、セルラまたはＷｉＦｉ）を選択するために使用され得る。それは、サインオンプロセスを自動化するため、エアインターフェース品質測定値を収集するため、および他のタスクのためにも使用され得る。そのため、ＣＭは、ＡＮＤＳＦクライアントなどのポリシクライアントのための自然なロケーションであり得、ポリシクライアントは、そこに配置され得る。
【０１０１】
したがって、ＵＥ上のアプリケーションが、（例えば、２１６において）調整されたサービスの名前をアプリケーションサーバから受信し得る場合、アプリケーションは、２２０において、名前をＣＭに通知（例えば、登録）し得る。ＣＭは、２２２において、そのようなサービス名に関連付けられた、制約、許容、およびパラメータなど（例えば、本明細書で説明される、特定のフローについての制約など）といったポリシを現在有し得るかどうかをチェック（例えば、判定）し得る。（例えば、新しい調整されたサービスの場合がそうであるように）ＣＭがポリシを有し得ない場合、それは、２２４において、アプリケーションサーバと（またはネットワークとさえも）交信して、与えられたサービスのためのポリシを要求し得る。上で説明されたように、ポリシを送信および符号化するためのプロトコルとして、ＡＮＤＳＦが使用され得、ＣＭは、ＡＮＤＳＦポリシのための実施ポイントとすることができる。アプリケーションサーバは、２２６において、ＣＭが記憶するように、（例えば、それとアプリケーションサーバとの先行する対話に基づいて）適切なポリシを返し得る（例えば、送信し得る）。アプリケーションは、その後、２２８において、開始され得る。（例えば、後の時点で）アプリケーションが、（例えば、一般にはソケットインターフェースを介して）そのようなサービスに関連付けられたＩＰフローをオープンし得た場合、ＣＭは、２３０において、そのようなフローを検出し得、適切なポリシを適用し得る。フロー検出は、フローおよび／またはサブフローを検出し得る数々の異なる方法または技法を介して実行され得、適切なポリシは、検出されたフロー、または帯域幅、フローの特性、および検出レベルなどの他のパラメータに基づき得る、任意の適切な基準またはポリシを含むことができる。
【０１０２】
図４は、ポリシが、例えば、（例えば、多数のＵＥへの）ブロードキャストを介して、またはＵＥへの直接的なプッシュを介して、サーバからＵＥにプッシュされ得る、方法または手順の例示的な実施形態を示している。方法または手順は、ＣＭがポリシ更新をアプリケーションサーバに要求し得ないことを除いて、（例えば、図３に示された）プル方法または手順と同様とすることができる。代わりに、ＣＭは、２３２において、アプリケーションサーバからのポリシのプッシュを受信し得る。ポリシのプッシュを受信すると、それ（例えば、ＣＭ）は、２３４において、ポリシ更新を記憶し得る。それを行う際、ＣＭは、例えば、それが認識し得るサービスのためのポリシを記憶するなど、フィルタを適用し得る。したがって、そのような実施形態では、アプリケーションは、（例えば、必要とされる場合）サービス固有のポリシが存在し得ることを保証するために、依然としてサービスをＣＭに事前登録し得る。
【０１０３】
セキュリティに対する考慮も、本明細書で説明されるように、提供および／または使用され得る。例えば、アプリケーション（および／またはＡｐｐＳｅ）とネットワークの間の（ならびにそれとは逆方向の）通信は、（例えば、少なくとも）インテグリティ保護を、および／または（例えば、任意選択で）暗号化を施され得る。加えて、ユーザおよび／または加入者と、シグナリングおよび制御に関し得るアプリケーションとの間で発生し得る通信は、ＴＬＳまたは何らかの形式のアプリケーションレベル保護を介して保護され得る。実施形態では（例えば、任意選択で）、通信は、中間者攻撃、なりすまし攻撃、および仮装攻撃を抑制するために、ＴＬＳなどのチャネルに結び付けられ得る。
【０１０４】
ユーザおよび／または加入者は、（例えば、任意選択で）明示的または暗黙的に認可を提供するように構成され得る。暗黙的な認可は、セッション鍵またはシグナリング鍵の所有を証明することを介して提供され得、一方、明示的な認可は、何らかのパスワード／ＰＩＮ／パスフレーズのユーザ入力、および生体認証または精神的／心理的特徴といったユーザの特徴を介するなどして提供され得る。
【０１０５】
実施形態では、プライバシに対する考慮が提供および／または使用され得る。例えば、提供および／または考察され得る通信の別の態様は、ＵＥ、ユーザ識別情報、およびサービスプライバシなどのプライバシとすることができる。実施形態によれば、ユーザは、その識別情報、ロケーション、物理的近接性、サービス利用可能性、および他のユーザからのニーズまたは要求についてのプライバシを維持することを望み得、または要望し得る。アクセスレイヤにおいて広告され得るサービスが、サービスプロバイダサービスに容易に関連付けられ、または結び付けられ得る場合、ＵＥは、それが秘密にしておきたいことがある情報を、アクセスレイヤにおいて不注意に広告することがあり得る。例えば、ユーザは、その存在を他から秘密にしておきたいことがある。同時に、ＵＥ識別情報も、他のＵＥから秘密にしておき得る。例えば、ＵＥは、「友人」が近くに存在し得る場合、最初に相談されることなく、他のＵＥによって発見されることを望まない、または要望しないことがある。そのため、ＵＥは、その近くのＣｏｍｐＮａｍｅ＋ｃｉｒｃｌｅなどの友人サークルに伝達することを望むとき、または要望するときまで、存在情報を秘密にしておくことを望み得、または要望し得る。したがって、情報を難読化した識別情報が、アプリケーションサーバに伝達され得、アプリケーションサーバは、識別情報を特定のＵＥに関連付けることができ、ＵＥのプライバシ設定を維持し得る。
【０１０６】
プライバシに対処する１つの方法は、一意性およびプライバシを保証し得る、サービスまたはＵＥ識別情報のためのランダム識別子を使用することとすることができる。例えば、一意的なランダム識別子は、提供され得るリストからのランダム選択、アプリケーションサービス名もしくはＵＥ識別情報の暗号学的ハッシュ、および／または他の任意の適切な方法を含む様々な方法で生成され得る。識別情報をさらに難読化するために、識別情報は、頻繁に交換または更新され得、通信のロギングおよび長期観察を通した識別を防止する。そのような実施形態のいずれでも、名前は、一時的であり得、および／またはリアルタイムで動的に定義され得る、一意的なサービス名またはＵＥ識別情報を含むことができる。
【０１０７】
サービス広告の間、プライバシを維持する１つの手段として、一時サービス名が使用および循環され得、実際のサービス名は、やはり同じサービスに加入している他のＵＥによる以外は、発見可能ではない。例えば、サービス名（例えば、ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ）は、秘密の名前として使用され得、または秘密の「マスタサービス鍵」文字列が、それに追加され得、もしくはこのサービスのために別に送信され得る。各ＵＥは、そのような文字列を受信し得、セキュアハッシュなどの安全な導出方法を使用して、一時サービス広告を導出し得る。そのような一時サービス広告は、ＵＥ（および同じサービスに加入する他のＵＥ）によってブロードキャストされ得る。やはりこのサービスの加入者であり得る別のＵＥは、広告された文字列を自らの広告される文字列と照合することによって、実際のサービス名を推測でき得る。しかしながら、サービスに加入していないＵＥは、実際のサービス名を導出でき得ない。
【０１０８】
セキュリティをさらに改善するため、一時ブロードキャストサービス名は、例えば、一時ブロードキャストサービス名を「リフレッシュ」するために、時間またはアプリケーションサーバによってブロードキャストされたノンスを強力な秘密と一緒にハッシュすることによって、時々、新しいサービス名に変更され得る。サービスに加入しているＵＥは、ブロードキャストされた文字列をローカルに導出でき得る文字列と照合することによって、複数の異なる一時サービス名を同じ基礎となるサービスと関連付けることができ得るが、サービスに加入しておらず、「マスタサービス鍵」を所有していないＵＥは、そのようにすることができ得ず、すなわち、２つの一時サービス名を同じサービスに関連付けることができ得ず、したがって、プライバシを提供する。
【０１０９】
一時識別情報（例えば、サービス名もしくは一時サービス名、および／または一時ＵＥ識別情報）を導出するためのシステムおよび／または方法（例えば、メカニズム）が、提供および／または使用され得、それは、例えば、ＫＤＦ（鍵，文字列）の形式の鍵導出関数に基づき得る。鍵は、ＵＥとネットワークの間で共有される秘密とすることができるが、文字列は、鍵導出関数（ＫＤＦ）が使用され得るコンテキストを表し得る。文字列は、ＵＥの識別情報（例えば、永続的な識別情報）（例えば、ＩＭＳＩ）、およびネゴシエーションまたは認証の間に使用され得たランダム変数などを含むことができる（例えば、少なくとも、それらで作成され得る）。加えて、文字列は、「ＰｒｏＳｅ」など、使用（または利用）のコンテキストを記述し得るパラメータを含むことができる（例えば、それらで作成され得る）。
【０１１０】
例示的な実施形態では、ＫＤＦは、ＵＥＴｅｍｐ＝ＨＭＡＣ−ＳＨＡ２５６（ＫｅｙＮ，ＩＭＳＩ｜ＮｏｎｃｅMNO｜ＵＴＦ−８ｅｎｃｏｄｉｎｇ（“ＰｒｏＳｅ”））の形式を取り得、導出される一時的な値または識別情報は、ＫＤＦの出力の先頭の３２ビットとすることができる。ＫｅｙＮは、ＵＥとＭＮＯ／オペレータまたはＰｒｏＳｅサーバとの間で共有される秘密とすることができる。ＩＭＳＩは、ＵＥの識別情報とすることができる。Ｔ−ＩＭＳＩ、Ｂ−ＴＩＤなど、他の導出される、または永続的な識別情報も、ＩＭＳＩの代わりに使用され得る。ＮｏｎｃｅMNOは、ＭＮＯによって生成され得るランダム値とすることができ、またはＵＥ（ＮｏｎｃｅUE）もしくは両方が使用され得、様々な長さを有するが、良好なランダム特性を有する。「ＰｒｏＳｅ」などの形の文字列は、ＵＥＴｅｍｐを導出するために、任意選択で使用され得る。ＵＥＴｅｍｐは、他のパラメータを使用することなく、ＮｏｎｃｅおよびＫｅｙＮなど、２つのパラメータのみを使用することによって導出され得る。実施形態では、ＮｏｎｃｅMNOまたはＮｏｎｃｅUEが、ＵＥ一時識別情報生成プロセスのためのパラメータとして使用され得る。加えて、一時識別情報のサイズは、様々であり得（例えば、実装に委ねることができ）、一時識別情報の一意性を保証するのに適した長さとすることができる。その後、ＵＥのために導出される一時識別情報は、ＵＥｔｅｍｐＩＤ＝（Ｔｅｍｐ）ｂａｓｅ６４＠ｐｒｏｓｅ．ＭＮＯ．ｃｏｍの形式を取り得る。
【０１１１】
同様に、加入者／ユーザのための一時アプリケーション識別情報は、以下のように導出され得、ＵｓｅｒＴｅｍｐ＝ＫＤＦ（ＫＡ，Ｎｏｎｃｅ，ＵＴＦ−８ｅｎｃｏｄｉｎｇ（ＵｓｅｒＩｄｅｎｔｉｔｙ｜“ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ”））、それから導出される一時ユーザ／加入者識別情報は、ＵＳＥＲＴｅｍｐＩＤ＝（ＵＳＥＲＴｅｍｐ）ｂａｓｅ６４＠ａｐｐｌｉｃａｔｉｏｎａｂｃ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅ．ｃｏｍの形式、またはｈｔｔｐ／ａｐｐｌｉｃａｔｉｏｎａｂｃ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅ．ｃｏｍ／（ＵＳＥＲＴｅｍｐ）ｂａｓｅ６４の形式を取り得る。ＫAは、ＵＥとアプリケーションの間で共有される秘密とすることができる。Ｎｏｎｃｅは、ＮｏｎｃｅAPPもしくはＮｏｎｃｅUser、またはＮｏｎｃｅUserとＮｏｎｃｅAPPの両方の組み合わせとすることができる。ＮｏｎｃｅAPPは、アプリケーションによって生成されるランダム値とすることができる。Ｕｓｅｒｌｄｅｎｔｉｔｙは、そのアプリケーションに関連付けられたユーザの識別情報とすることができる。アプリケーション名も、ＵｓｅｒＴｅｍｐを導出するためのパラメータとして含まれ得る。ユーザによって生成されるＮｏｎｃｅUserも、ＵｓｅｒＴｅｍｐ生成プロセスの一部として、任意選択で含まれ得る。Ｕｓｅｒｌｄｅｎｔｉｔｙおよびアプリケーション名（ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＣｉｒｃｌｅｘｙｚ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ）は、任意選択パラメータとすることができる。実施形態では、ＮｏｎｃｅUserまたはＮｏｎｃｅAPPが、一時識別情報生成プロセスの一部として含まれ得る。ＮｏｎｃｅＵｓｅｒおよびＮｏｎｃｅＡｐｐはともに、一時識別情報生成プロセスの一部として含まれ得る。別の実施形態では、ＵｓｅｒＴｅｍｐＩＤおよびＵＥＴｅｍｐＩＤは、（日付および時刻などの）時間成分を周期的に使用して、ＵＥとネットワークまたはアプリケーションの両方によって自己生成され得る。周期性は、登録プロセスの間に合意され得る。これは、ＵＥとネットワークまたはアプリケーションの両方が、エンティティ間でＮｏｎｃｅを伝達する必要性を回避し、したがって、リソースを節約し、待ち時間を改善する。あるいは、Ｎｏｎｃｅは、一時識別情報の初期生成の間に使用され得、その後は、一時識別情報は、Ｎｏｎｃｅを伝達することなく、時間成分を使用して、各エンティティにおいて生成され、またはＮｏｎｃｅは、より低い頻度で使用され得、一方、時間成分は、より高い頻度で使用され得る。例示的な実施形態は、以下のようにすることができ、すなわち、一時識別情報は、毎日、Ｎｏｎｃｅおよび／または時間成分を用いて生成され得、その後は、一時識別情報は、１時間おきに、時間成分のみを使用して、エンティティの各々において生成され得る。新しいＮｏｎｃｅが、翌日に生成され得、そのＮｏｎｃｅおよび時間成分に基づいた新しい一時識別情報が、翌日、１時間おきに生成される。類似の実施形態および／または本明細書で説明される実施形態の変形も使用され得る。
【０１１２】
例示的な実施形態では、一時識別情報は、ネットワークとアプリケーションの間の通信のために使用され得る。アプリケーションは、ネットワークとの通信のために、ＵＳＥＲｔｅｍｐＩＤを使用し得、一方、ネットワークは、アプリケーションと通信するために、ＵＥｔｅｍｐＩＤを使用し得る。ＵＥｔｅｍｐＩＤは、Ｄ２ＤまたはＰｒｏｘｉｍｉｔｙサービス（ＰｒｏＳｅ）のために他のＵＥに広告し、または他のＵＥを発見するために、ＩＭＳＩの代わりに、ＵＥの識別情報として、ＵＥによって使用され得る。アプリケーションおよびネットワークは、その後、２つの一時識別情報のマッピングを実行し得る。あるいは、一時識別情報は、暗号学的な方法（例えば、ＴｅｍｐＩＤ（ｄｏｍａｉｎ２）＝ＫＤＦ（Ｋｅｙ，ＴｅｍｐＩＤ（ｄｏｍａｉｎ１）））で、２つのドメイン（例えば、アプリケーションとネットワーク）を結び付け得る、一意的な一時識別情報を導出するための入力として使用され得る（例えば、それは、これらの一時識別情報を広告し得るＵＥの間の無線通信のために使用され得る）。
【０１１３】
実施形態によれば、ＰｒｏＳｅ識別情報サービス機能（ＰＩＳＦ）は、一時識別情報生成およびマッピングのためのサービスを提供し得る。これらのサービスは、ＭＮＯに結び付けられ得、またはサードパーティサービスとして提供され得る。ＰｒｏＳｅ一時Ｉｄ（ＰｒｏＳｅＩＤ）は、そのようなサービスのために生成され得、またはＰＩＳＦがＭＮＯ内に配置され得る場合、ＵＥＴｅｍｐＩＤはその後、ＰｒｏＳｅＩＤとして使用され得る。ＵＥは、ＰｒｏＳｅＩＤをＰＩＳＦに要求し得、またはあるいは、ＰｒｏＳｅＩＤは、ＰＩＳＦによってＵＥにプッシュされ得る。
【０１１４】
プライバシ要件に基づいて、ＰｒｏＳｅ識別情報は、関連する存続期間を有する一時識別情報とすることができる。新しいＰｒｏＳｅＩＤが、古いＰｒｏＳｅＩＤに関連する存続期間の満了前に、再生成されなければならないことがある。古いＰｒｏＳｅＩＤと新しいＰｒｏＳｅＩＤは、限られた時間の間にマッピングされ得、そのため、発見プロセスの間に、同期問題は存在し得ない。プル手法またはプッシュ手法を使用して、ＵＥは、新しいＰｒｏＳｅＩＤを要求し、または新しいＰｒｏＳｅＩＤをプッシュされる。
【０１１５】
図５は、ＰｒｏＳｅ識別情報機能の例示的な実施形態を示している。図５に示されるように、メッセージ１ａでは、ＵＥ１は、ＰｒｏＳｅＩＤを要求し得、ＰＩＳＦは、メッセージ１ｂに示されるように、新たに生成されたＰｒｏＳｅＩＤを送信し得る。あるいは、ＰＩＳＦは、ＰｒｏＳｅＩＤの存続期間の満了前に、新しいＰｒｏＳｅＩＤを生成し得、要求メッセージ１ａを受信することなく、メッセージ１ｂを使用して、新しいＰｒｏＳｅＩＤをＵＥに送信し得る。実施形態は、ＰＩＳＦが、一時ＰｒｏＳｅＩＤの生成のために必要とされるシード材料を生成し、メッセージ２ａに示されるように、シード材料のみをＵＥに送信することを可能にする。ＮｏｎｃｅProSeが、要求に応答して、ＰＩＳＦによって送信され得、またはＵＥにプッシュされ得、その後、それは、ＰｒｏＳｅＩＤを生成するために、ＵＥおよびＰＩＳＦによって使用され得、ＰｒｏＳｅＩＤ＝（ＫｅｙProSe，ＮｏｎｃｅProSe）であり、ここで、ＫｅｙProSeは、ＵＥとＰＩＳＦの間で共有される秘密とすることができる。あるいは、ＵＥが、ＰｒｏＳｅＩＤを生成するためのシード材料をＰＩＳＦに送信し得、または各エンドで生成され得るＵＥおよびＰＩＳＦの両方からのシード材料が、互いに伝達され、その後、ＰｒｏＳｅＩＤを生成するために、両方のエンティティによって使用され得る。あるいは、ＰｒｏＳｅＩＤは、（日付および時刻などの）時間成分を周期的に使用して、ＵＥとＰＩＳＦの両方によって自己生成され得る。周期性は、登録プロセスの間に合意され得る。これは、ＵＥとＰＩＳＦの両方が、エンティティ間でＮｏｎｃｅを伝達することを回避し、したがって、リソースを節約し、待ち時間を改善することができるようにできる。あるいは、Ｎｏｎｃｅは、ＰｒｏＳｅＩＤの初期生成の間に使用され得、その後は、一時識別情報は、Ｎｏｎｃｅを伝達することなく、時間成分を使用して、ＵＥおよびＰＩＳＦにおいて生成され得、またはＮｏｎｃｅは、より低い頻度で使用され得、一方、時間成分は、より高い頻度で使用され得る。例示的な実施形態は、以下のようにすることができ、すなわち、ＰｒｏＳｅＩＤは、毎日、朝６時に、Ｎｏｎｃｅおよび／または時間成分によって生成され得、その後は、ＰｒｏＳｅＩＤは、１時間おきに、時間成分のみを使用して、エンティティの各々において生成され得る。新しいＮｏｎｃｅが、翌日に生成され得、そのＮｏｎｃｅに基づいた新しいＰｒｏＳｅＩＤが、生成され得、その後、時間成分のみを使用して、ＰｒｏＳｅＩＤが、１時間おきに生成される。類似の実施形態もしくは変形、または本明細書で説明される実施形態もしくは変形の組み合わせも使用され得る。
【０１１６】
ＰｒｏＳｅ発見および／または広告メッセージ３ｂは、ＵＥ１のＰｒｏＳｅＩＤ（ＰｒｏＳｅＩＤ＿１）を搬送し得、同様に、ＵＥ２は、メッセージ３ａで、そのＰｒｏＳｅ識別情報としてＰｒｏＳｅＩＤ＿２を広告し得る。ＰｒｏＳｅ識別情報の搬送に加えて、各発見および／または広告メッセージは、任意選択で、ＰｒｏＳｅ識別情報に関連付けられるサービスクラス（ＣＳ）も搬送し得る。加えて、ＵＥは、２以上のＰｒｏＳｅＩＤに関連付けることができ、各ＰｒｏＳｅＩＤは、アプリケーションまたはサービスのクラスに関連付けることができる。ゲームは、サービスクラスの一例とすることができ、同様に、ソーシャルネットワークは、異なるセキュリティおよびプライバシ要件も有し得る、サービスクラスとすることができる。ＵＥは、ゲームのためのＰｒｏＳｅＩＤ、およびソーシャルネットワークのための別のＰｒｏＳｅＩＤを有し得る。
【０１１７】
ＰＩＳＦは、発見機能も実施し得、それは、ＰｒｏＳｅＩＤの適切なアプリケーションおよびそれぞれの一時アプリケーション識別情報へのマッピングを支援する。ＰＩＳＦは、（例えば、ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅｘｙｚ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ．ＵｓｅｒＴｅｍｐＩＤ１をＰｒｏＳｅＩＤ１にマッピングするなど）複数のアプリケーションを同じだが一意的なＰｒｏＳｅＩＤにマッピングするマネージャとして機能し得る。加えて、ＰＩＳＦは、発見および接続機能を用いて、共通のＰｒｏＳｅ接続性に関心を有する２つのユーザを接続するエンティティとして機能し得る。ＰＩＳＦは、ＰｒｏＳｅユーザのためにフィルタリングおよびデータ収集も実行し得、そのような情報をアプリケーションサーバに報告し得る。ＰＩＳＦは、各ＵＥによって発見されたＰｒｏＳｅＩＤのデータベースも維持し得、プライバシ保護を提供するために、ＰｒｏＳｅＩＤリフレッシュ機能も提供する。また、ＰＩＳＦは、発見データをフィルタリングする場合などに、古いＰｒｏＳｅＩＤと新しいＰｒｏＳｅＩＤの結び付けを可能にし得る。実施形態では、ＰＩＳＦは、その機能のいくつか（例えば、ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅｘｙｚ．Ａｐｐｌｉｃａｔｉｏｎ＿ａｂｃ．ＵｓｅｒＴｅｍｐＩＤ１など、アプリケーションサーバ名のレベルにおけるフィルタリング）をＵＥに委任し得る。ＰＩＳＦは、ＵＥの一時ＰｒｏＳｅＩＤを、ユーザが契約した一時アプリケーション識別情報にマッピングする、識別情報マッピングテーブルを使用し得る。図５に示されるように、マッピングテーブルは、関連するＰｒｏＳｅＩＤ＿１を有するＵＥ１の、関連するアプリケーション一時識別情報ＵｓｅｒＴｅｍｐＩＤ１＿Ａｐｐ１およびＵｓｅｒＴｅｍｐＩＤ２＿Ａｐｐ３との対応付けを含むことができる。同様に、ＰｒｏＳｅＩＤ＿２を有するＵＥ２は、アプリケーション識別情報ＵｓｅｒＴｅｍｐＩＤ２＿Ａｐｐ１およびＵｓｅｒＴｅｍｐＩＤ１＿Ａｐｐ２に関連付けることができる。観察され得るように、ＵＥ１およびＵＥ２はともに、アプリケーションＡｐｐ１との関連付けを有する。ＰｒｏＳｅＩＤ＿１に関連付けられ得るＵＥ１は、ＵＥ２のＰｒｏＳｅＩＤ（ＰｒｏＳｅＩＤ＿２）と、任意選択で、サービスクラス（ＣｏＳ）表示とを含む、ＰｒｏＳｅ発見メッセージ、メッセージ３ａをＵＥ２から受信し得る。同様に、ＵＥ２は、ＵＥのＰｒｏＳｅＩＤ＿２と、任意選択で、ＣｏＳ表示とを含む、発見および／または広告メッセージをＵＥ１から受信し得る。ＵＥは、受信された発見および／または広告メッセージに対して何らかの形のフィルタリングを実行し得、加えて、検出された各ＰｒｏＳｅＩＤについての測定値を検出および収集し、定期的に、またはある時間間隔で、スキャンの実行および検出を行い得、フォールスアラームならびに偽のトリガおよび過渡条件を回避するために、発見データをフィルタリングする。例えば、特定のＰｒｏＳｅＩＤが、ｘ回の連続的なスキャンにおいて発見され得る場合、それが検出されたと見なされ得る。同様に、検出の喪失および報告のため、検出され得るものの変化が、通信帯域幅を制限するために、ＰＩＳＦ機能に送信され得る（例えば、新しいＰｒｏＳｅＩＤが発見され得た、または失われ得た場合、情報がＰＩＳＦに送信され得る）。
【０１１８】
実施形態では、発見メッセージの受信に続いて、ＵＥ１は、アプリケーション識別情報と、ＵＥ２と通信するために起動するアプリケーションとを発見するために、アプリケーション発見要求メッセージ４ａをＰＩＳＦの発見機能に送信し得る。メッセージ４ａは、ＰｒｏＳｅＩＤ＿２を含むことができ、ＵＥ１がＵＥ２から受信した関連するＣｏＳも有することができる。ＵＥ２がＵＥ１から受信し得たＰｒｏＳｅＩＤ＿１と、関連するＣｏＳも含む、ＵＥ２からの同様の要求が、メッセージ４ｂで、ＰＩＳＦの発見機能に送信され得る。メッセージ４ａまたは４ｂのどちらかを受信すれば十分であり得るが、ＰＩＳＦは、アプリケーション発見要求メッセージをＵＥの一方から受信する代わりに、関与する両方のパーティからそれを受信した場合、より高い程度の確かさで、要求について検証でき得る。発見機能は、その後、Ｉｄマッピングテーブルのテーブル検索に基づいて、ＵＥ１とＵＥ２の両方が、互いにＰｒｏＳｅサービスを要求していることを推測し得る。メッセージ４ｃは、ＵＥ１およびＵＥ２の両方のアプリケーション識別情報を獲得するために、発見機能によって使用され得、それらのＰｒｏＳｅＩＤと、任意選択で、ＵＥの各々に関連付けられたＣｏＳも送信され得る。メッセージ４ｃの結果として（例えば、それに応答して）、検索が実行され得、両方のＵＥのＰｒｏＳｅＩＤが、それらが加入しているアプリケーションと比較され得、任意選択で、それらが属するＣｏＳを比較し得る。両方のＵＥが、同じアプリケーションまたはアプリケーションクラスもしくはサービスクラスに関連付けられ、またはそれらに加入し得ている場合、それぞれのアプリケーション識別情報が獲得され得る。発見機能は、また、ＵＥ１とＵＥ２がともにＡｐｐ１に加入し得ていることを発見し得る。発見機能は、メッセージ４ｄを使用して、ＵｓｅｒＴｅｍｐＩＤ２＿Ａｐｐ１をＵＥ１に送信し得、メッセージ４ｅを使用して、ＵｓｅｒＴｅｍｐＩＤ１＿Ａｐｐ１をＵＥ２に送信し得る。あるいは、ＰＩＳＦは、ＵｓｅｒＴｅｍｐＩＤ１＿Ａｐｐ１とＵｓｅｒＴｅｍｐＩＤ２＿Ａｐｐ１の間のサービスを開始するために、メッセージ４ｈを使用して、Ａｐｐ１と直接的に通信し得る。メッセージ４ｄおよび４ｅは、任意選択とすることができ、メッセージ４ｈは、実施され得る。あるいは、メッセージ４ｆが実施され得、その後、Ａｐｐ１は、アプリケーション識別情報ＵｓｅｒＴｅｍｐＩＤ２＿Ａｐｐ１を使用するＵＥ２とのメッセージ４ｉを使用して、サービスおよび認可要求を開始し得る。あるいは、メッセージ４ｇが実施され得、その場合、Ａｐｐ１は、アプリケーション識別情報ＵｓｅｒＴｅｍｐＩＤ１＿Ａｐｐ１を使用するＵＥ１へのメッセージ４ｉを使用して、サービスおよび認可要求を開始する。あるいは、メッセージ４ｄ、４ｅ、４ｆ、および４ｇは、スキップされ得、メッセージ４ｇのみが、ＰＩＳＦ／発見機能によって送信され得る。Ａｐｐ１は、その後、メッセージ４ｉを使用して、認可要求を両方のＵＥに送信することによって、ＵＥのアプリケーション識別情報を使用して、２つのＵＥの間のサービスを開始し得る。あるいは、ＰｒｏＳｅＩＤが一対多アプリケーションＩｄマッピングであり得るために、ＰＩＳＦが正しいアプリケーションを発見でき得ない場合、ＰＩＳＦは、ＵＥが使用したいアプリケーションを決定するために、両方のＵＥが加入しているアプリケーションを尋ねる要求をＵＥに送信し得る。ＰＩＳＦは、また、ＵＥ１とＵＥ２の両方に共通し得るすべてのアプリケーションを起動し得、アプリケーションの各々にＵＥの関連するアプリケーション識別情報を提供し得る。メッセージ４ｄおよび４ｅの一部として、ＵＥ１およびＵＥ２は、誰が接続するかを選択するためにＵＥによって使用され得る、ターゲットＵＥの複数のアプリケーション識別情報を受信し得る。ＰＩＳＦは、それぞれのアプリケーションとの合意に基づいて、ＵＥが選択し得るアプリケーションに優先順位を付け得る。
【０１１９】
実施形態によれば、ＵＥは、アクティブな発見シナリオにおいて、追跡および発見の回数、ひいては、ＵＥリソースへの影響が減少し得るように、関心がある他のＵＥまたはユーザ／加入者の一時識別情報のリストを維持し得る。同様に、ネットワークは、関心があり得るＵＥについての情報をアプリケーションに伝達し得、または統合された方法で伝達し得、それによって、ネットワーク上の負荷を低減する。
【０１２０】
加えて、各ＵＥは、各ＵＥが完全に異なる一時サービス名をブロードキャストし得るように、自らの（ＩＭＳＩまたは他の識別子などの）ＵＥ識別子情報をブロードキャストサービス名に含めることができ得る。同じサービスに属する他のＵＥは、他のＵＥの知られたＴｅｍｐＩＤと「マスタサービス鍵」の組み合わせを使用して、そのようなＵＥが広告し得る一時サービス文字列のリストをローカルで導出し、一致するかどうかブロードキャスト文字列と照合し得る。サービスに加入していないＵＥは、そのような手順を実行でき得ず、したがって、異なるＵＥによってブロードキャストされた異なるサービス識別子が実際は同じサービスを広告していることがあることを理解すらでき得ない。
【０１２１】
実施形態によれば、発見および管理のためのクロスレイヤ通信が提供および／または使用され得る（例えば、最適化され得る）。アプリケーションサーバを介してプレゼンスベースのサービスを提供するために、ＵＥは、それらの識別情報、およびサービス要求または利用可能性を広告し得る。アプリケーションサーバは、プレゼンスサービスを管理し得るエンドポイントであり得るので、ＵＥによって集められた情報は、アプリケーションサーバに伝達され得る。しかしながら、感知される情報、通信の頻度、および参加するＵＥの数などが考察または考慮され得る場合、情報の量は、指数関数的に増加し得る。通信を減らすために、情報は、ＵＥにおいてローカルにフィルタリングされ得、フィルタリングされた情報が、上流方向にアプリケーションサーバに伝達され得る。特定のサービスセッションを識別するための本明細書で説明される階層は、実施形態によるフィルタリング機能の基礎として使用され得る。加えて、そのような属性は、ＵＥにおいて提供されるポリシを通してＵＥにおいてローカルにフィルタリングを提供して、アプリケーションサーバへの通信を減少させるために使用され得る。これらのポリシは、ネットワークレベルのポリシを反映した代理ポリシとすることができ、信頼できる方法で（例えば、適切で安全な保護された信頼できるポリシ実行を介して）、ＵＥ上で忠実に実行され得る。実施形態では、ランダムな一時ＩＤまたは人間が読めるＩＤが、階層的フィルタリングのために使用され得る。前者の場合、一時識別情報から生成される短い文字列が、直接ＵＥ−ＵＥリンクを介して、またはアプリケーションサーバを通して検証される、より長い文字列とともに、ＵＥにおける初期フィルタリングのために使用され得る。後者では、命名規約が、ユーザの階層的な組を暗示し得、各々は、上位層の厳格なサブセットであり得る。
【０１２２】
例えば、上で説明されたＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．Ａｐｐｌｉｃａｔｉｏｎａｂｃ命名例が、ローカルなフィルタリングによる漸進的なトラフィックの削減を提供するために使用され得る。そのような実施形態では、「ＣｏｍｐＮａｍｅ」レベルは、例えば、ＣｏｍｐＮａｍｅによって提供されるもの以外のサービス発見情報をＵＥにおいて分離する、フィルタリングの最低のレベルを提供し得る。「ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ」レベルは、例えば、ＧａｍｅＮａｍｅアプリケーションサービスのＣｏｍｐＮａｍｅによって提供されるもの以外のサービス発見情報をＵＥにおいて分離する、フィルタリングの次のレベルを提供し得る。「ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ」レベルは、例えば、特定のＣｏｍｐＮａｍｅ＋ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺサークルグループのＧａｍｅＮａｍｅアプリケーションサービスのＣｏｍｐＮａｍｅによって提供されるもの以外のサービス発見情報をＵＥにおいて分離する、フィルタリングの次のレベルを提供し得る。「ＣｏｍｐＮａｍｅ．ＧａｍｅＮａｍｅ．ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺ．Ａｐｐｌｉｃａｔｉｏｎａｂｃ」レベルは、例えば、特定のＣｏｍｐＮａｍｅ＋ＣｏｍｐＮａｍｅＧｒｏｕｐＸＹＺグループおよびＡｐｐｌｉｃａｔｉｏｎａｂｃアプリケーションセッションのＧａｍｅＮａｍｅアプリケーションサービスのＣｏｍｐＮａｍｅによって提供されるもの以外のサービス発見情報をＵＥにおいて分離する、フィルタリングの最高のレベルを提供し得る。
【０１２３】
加えて、発見情報は、ハンドオフ動作およびＱｏＳ管理のために使用される無線測定と同様に、さらに調整され得る。例えば、実施され得る測定の頻度、およびこれらの測定がどれほどの頻度でアプリケーションサーバに報告され得るかが、トラフィックを管理するために使用され得る、さらなる手段または情報を提供し得る。
【０１２４】
様々なアプリケーションサービスのための設定に応じて、ＵＥ上で提供されるポリシは、アプリケーションサーバへの発見情報トラフィックの微調整および調整も可能にし得、その結果、依然として高品質のサービスを提供しながら、通信の最適化を可能にし得る。
【０１２５】
別の実施形態によれば、Ｄ２Ｄサービスを用いたサービスアクセスが提供および／または使用され得る。例えば、ネットワークとアプリケーションサーバサービスの間の対話、発見、およびデバイスツーデバイス通信の特定のケースのための登録が、提供および／または使用され得る。そのような実施形態では、そのようなメッセージフローは、Ｄ２Ｄサーバが、新しいコアネットワークノード、および／またはネットワークにおいてＤ２Ｄ関連情報を管理する責任がある機能として導入され得る、上で説明され、図１に示された手順の特定の例と見なされ得る。Ｄ２Ｄサーバは、直接Ｄ２Ｄリンクを使用すること、またはそれから利益を得ることができるサービスおよび／またはアプリケーションについてのサービスアクセスをネゴシエートするために、アプリケーションサーバと対話し得る、コアネットワークエンティティとすることができる。
【０１２６】
（例えば、アプリケーションサーバとのインターフェースが存在し得ない）実施形態では、Ｄ２Ｄサーバは、上で説明されたようなＤ２Ｄ関連情報を受信し、サービスパラメータを決定するために、ＵＥと対話し得る。
【０１２７】
Ｄ２Ｄサーバを有する（例えば、３ＧＰＰの）ＥＰＣアーキテクチャ（例えば、オペレータ間Ｄ２Ｄアーキテクチャ）の例示的な実施形態が、図６に示され得る。そのようなアーキテクチャでは、Ｄ２Ｄサーバは、１つのオペレータ（例えば、ＰＬＭＮ  Ａ）のドメイン内に存在し得るが、別のオペレータ（例えば、ＰＬＭＮ  Ｂ）内のノードからアクセス可能であり得る。加えて、Ｄ２Ｄサーバと、ＭＭＥ、ＨＳＳ、ＰＣＲＦ、およびＡＮＤＳＦなど、ＥＰＣ内の様々な既存のエンティティとの間の新しいインターフェースが、提供および／または使用され得る。実施形態では、そのようなアーキテクチャにおいて、データプレーンは影響を受けずにいることができ、コントロールプレーンへの新しいインターフェースが使用され得る。
【０１２８】
図７は、ＵＥが別のＵＥとのＤ２Ｄセッションに携わる場合の、ＵＥからネットワーク（例えば、３ＧＰＰネットワーク）への接続に関するイベントのシーケンスを説明し得る、呼フローの例示的な実施形態を提供している。図７に示されるように、フローは、３つのセグメントに分割され得る。第１のステージにおいて、ＵＥは、自らをネットワーク（例えば、３ＧＰＰネットワーク）に接続し得る。接続プロセスの一環として、ＵＥは、それらが広告し得るＤ２Ｄデバイス識別子も獲得し得、そのため、他のＵＥは、デバイス発見手順を使用して、それらを見出し得る。接続プロセスの終わりにはユーザは、すでにネットワークに認証され得ており、ネットワークは、対応するユーザがＤ２Ｄサービスを獲得することを許可され得ていることを検証し得ている。Ｄ２Ｄサーバは、ＰＣＲＦおよび／またはＡＮＤＳＦともシグナリングを交換し得る。
【０１２９】
第２のステージ（例えば、サービス登録手順）において、ユーザは、それらが使用または必要とし得るサービスに応じて、自らを１または複数のアプリケーションサーバに登録し得る。サービス要求の一部として、ユーザは、オープンＩＤ、ＧＢＡ、ＳＳＯ、またはそれに関連付けられた他の識別情報を送信し得る。加えて、実施形態では、この要求の一部として、ユーザは、ＰＬＭＮ  ＩＤ、および／またはセルラネットワークに関する他のパラメータも送信し得る。これは、アプリケーションサーバが、ユーザがすでにネットワーク（例えば、３ＧＰＰネットワーク）において認証され得ている事実を利用することを可能にし得、それが、関連するＤ２Ｄサーバと交信することを可能にし得る。アプリケーションサーバおよびＤ２Ｄサーバは、最初にオープンＩＤ、ＳＳＯ、または他のプロトコルを使用して、ユーザを認証し得る。サービス要求は、ＵＥがユニキャストサービスを要求しているか、それともマルチキャストサービスを要求しているかも、アプリケーションサーバに通知し得る。
【０１３０】
その後、アプリケーションサーバは、ユーザによって要求されているサービスによってサポートされるＤ２Ｄ構成を、Ｄ２Ｄサーバに送信し得る。Ｄ２Ｄ構成は、サービスを使用するために必須であり得るＤ２Ｄ動作、任意選択であり得るＤ２Ｄ動作（例えば、ＵＥは、Ｄ２Ｄモードにあるか、それとも基本的なセルラモードにあるかに関わりなく、アプリケーションに参加し得る）、および特定のサービスにおいて許可され得ないＤ２Ｄ動作などを含むことができる（しかし、それらに限定され得ない）。
【０１３１】
加えて、実施形態では、Ｄ２Ｄサーバは、Ｄ２Ｄサービスが使用され得ない場合であっても、アプリケーションサーバとネットワーク（例えば、３ＧＰＰネットワーク）の間の制御インターフェースとして機能し得る。
【０１３２】
Ｄ２Ｄサーバは、アプリケーションサーバから、ＱｏＳなどに関するサービス要件も受信し得、ＨＳＳとの対話によって、特定のＵＥがこれらのサービスを獲得することを許可され得ているかどうかを確認し得る。
【０１３３】
Ｄ２Ｄサーバは、アプリケーションサーバから、Ｄ２Ｄサービス固有のポリシ要件をさらに受信し得、例えば、ＰＣＲＦとの対話によって、ＵＥがこれらのポリシ要件に満足でき得るかどうかを確認し得る。
【０１３４】
実施形態では、確認がアプリケーションサーバに提供され得る。アプリケーションサーバは、その場合、そのようなサービスをネットワーク（例えば、３ＧＰＰネットワーク）内で識別するために使用され得る名前であり得る一時サービス名を、Ｄ２Ｄサーバに提供し得る。（例えば、友人のリストに関して）現在サービスに登録され得ている他のユーザのリストも提供され得る。Ｄ２Ｄサーバは、これら（例えば、リスト）の他に、デバイス発見のためにＵＥによって使用され得るサービス識別情報とそれらに対応するデバイス識別情報との間のマッピングも提供され得る。その後、（例えば、サービス登録プロセスの最終部分として）、ＵＥは、確認をアプリケーションサーバに送信し得る。
【０１３５】
サービス登録が実行され得た後（例えば、両方のＵＥが、上で説明された接続および登録手順を完了し得た後）、図７の最後のシーケンスまたはステージは、ＵＥ１とＵＥ２の間のＤ２Ｄサービスの開始を示している。このフェーズの間に、Ｄ２Ｄ  ＥＰＳおよび無線ベアラが確立され得る。Ｄ２Ｄサーバは、機能の中でもとりわけ、（ＩＰアドレスなどの）ターゲットＭＭＥ識別子情報をソースＭＭＥに提供すること、およびＵＥ能力を調停した後で、許容し得る構成に達することによって、ここでの特定の役割を果たし得る。
【０１３６】
別の実施形態（例えば、第２の実施形態）によれば、ＰｒｏＳｅ制御インターフェース動作は、例えば、オペレータによって提供される識別情報に基づく。そのような実施形態では、ＰｒｏＳｅサーバは、（例えば、第１の実施形態の）Ｄ２Ｄサーバの等価物であり得る。本明細書で使用され得るＰｒｏＳｅアーキテクチャの概要が、図８に示され得る。
【０１３７】
加えて、この実施形態では、ＭＮオペレータによって提供される識別情報（例えば、本明細書で説明される頭字語ＯＰＩ）が、セルラネットワークＵＥ識別情報（例えば、ＴＭＳＩ、ＭＳＩＳＤＮ）とユーザのアプリケーションレイヤユーザ識別情報の間の、識別情報の中間レイヤとして使用され得る。一実施形態によれば、オープンＩＤ（例えば、オープンＩＤプロトコルから導出されるＯＰＩ）が、そのようなＯＰＩの主要な例であり得る。しかしながら、追加の実施形態では、（例えば、それがＰＬＭＮ認証システム（例えば、ＧＢＡ）と統合され得る限り、および「ＯＰＩ識別情報」が、Ｆａｃｅｂｏｏｋログインハンドルなどの「アプリケーションレイヤユーザ識別情報」の代わりに、使用および／または提供され得る場合）リバティアライアンス識別情報連合フレームワーク（Ｌｉｂｅｒｔｙ  Ａｌｌｉａｎｃｅ  Ｉｄｅｎｔｉｔｙ  Ｆｅｄｅｒａｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ）などの別の技術が、代わりに使用され得る。
【０１３８】
複数のアプリケーション識別情報が単一のＯＰＩにマッピングされ得る場合、どのアプリケーションがそれを生じさせたかをそれ自らが決定し得ないという意味で、発見イベント自体が曖昧であり得る。その場合、例えば、以下のうちの１つを含むことができる追加のステージが、提供および／または実行され得る。一実施形態では、グループ内のアプリケーションの各々は、それらのアプリケーションサーバと交信して、どのアプリケーションまたはサーバが発見を生じさせたものであり得るかを確認し得る。別の実施形態では、ＵＥが、セキュアチャネルを確立し得、それらのアプリケーションＩＤを交換して、どのアプリケーションが一致するかを調べ得る。セキュアチャネル鍵は、ＰｒｏＳｅ  ＩＤに基づき得る。そのような方法は、ネットワーク負荷を低減させ得る。別の実施形態では、ＵＥは、それから再構成され得ないアプリケーションＩＤに基づいて、セキュアチャネルを生成し得、そのようなチャネルを使用して、どのアプリケーションが発見を起動し得たかを確認し得る。アプリケーションＩＤが一致しない場合、チャネルは機能し得ず、したがって、発見情報は、合法的なアプリケーションから利用可能であり得る。一実施形態では、そのような方法は、同様に、アプリケーションによって導出されたＩＤとともに使用され得る。
【０１３９】
実施され得るＰｒｏｘｉｍｉｔｙサービスは、近接サーバ（この実施形態ではＰｒｏＳｅサーバ）によってサポートされ得る。ＰｒｏＳｅサーバは、ＨＴＴＰ、ＳＩＰ、または他のプロトコルに基づいたＡＰＩなどのインターフェースを、ＵＥとアプリケーションの両方に提供し得る。加えて、ＰｒｏＳｅサーバとＵＥの間のインターフェースは、（例えば、ＵＥの適切な機密性および認証を保証し得る）ＮＡＳシグナリング上にあり得る。ＰｒｏＳｅサービスを可能にするために、ＵＥは、ＯＰＩ識別情報、アプリケーションＩＤを指定し、おそらくは、アプリケーション固有の構成を追加して、ＰｒｏＳｅサーバに登録し得る。その後、ユーザは、アプリケーションＸにログインし得、他のアプリケーション加入者を発見し、それとデバイスツーデバイス（Ｄ２Ｄ）で通信するために、ＰｒｏＳｅサービスを使用し得る。実施形態によれば、ユーザは、アプリケーションに直ちにログインしないこともあり得るが、依然として他のアプリケーション加入者によって発見可能であり得る。
【０１４０】
識別情報に関して、ＰｒｏＳｅサーバは、（例えば、現在サービスに登録されているユーザのために）ＯＰＩ識別情報とセルラネットワーク識別情報の間のマッピングを維持し得、アプリケーションは、アプリケーションの加入者のために、ＯＰＩ識別情報とアプリケーションレイヤユーザ識別情報（例えば、ユーザ名）の間のマッピングを維持し得る。
【０１４１】
実施形態で説明されるＰｒｏＳｅ機能は、Ｄ２Ｄ通信、近接性発見、および（例えば、ユーザが、ＰｒｏＳｅサービスに登録してはいるが、アプリケーションにログインしていない場合に使用され得る）アプリケーションウェイクアップ通知などを含むことができる。追加のサポート手順は、ＯＰＩ識別情報検証も含むことができる。
【０１４２】
ＰｒｏＳｅサーバは、また、例えば、使用法に最小限の拡張を施した既存のスポンサ付きデータ接続性機能を通して、ＰｒｏＳｅ動作およびＤ２Ｄ通信の料金をアプリケーションプロバイダに請求することをサポートし得る。
【０１４３】
例示的な実施形態では、ユーザは、アプリケーションを使用することを決定し得、それに接続し得、ユーザ名を用いてアカウントを生成し得、加えて、ＰｒｏＳｅサービスのためのユーザ識別を受けるためにＯＰＩ識別情報を入力し得る（例えば、Ａｌｉｃｅ＠ｍｎｏ−ｙ．ｃｏｍがＭＮＯ  Ｙによって提供され得、それは、どのＭＮＯと通信すべきかをアプリケーションにさらに知らせ得る）。アプリケーションは、また、ＯＰＩ識別情報を獲得および／または検証し得、この時点から、Ａｌｉｃｅは、このアプリケーションを通して提供されるＰｒｏＳｅサービスを使用し得る。例示的な実施形態によれば、Ａｌｉｃｅは、ＰｒｏＳｅサーバに登録し、このアプリケーションＰｒｏＳｅサービスをアクティブ化するための、ＯＰＩ識別情報、アプリケーションの名前、および何らかのアプリケーション固有の構成を含めることができ、これは、任意の時点で（例えば、Ａｌｉｃｅがアプリケーションにログインし得ていない場合であっても）実行され得る。アプリケーションは、そのユーザの１つがＰｒｏＳｅサービスに登録した場合、通知され得、および／またはユーザアプリケーション固有の構成を獲得し得る。例えば、Ａｌｉｃｅは、ある１組の友人たちが彼女とともに発見を開始し得ること、および彼女の現在のデバイスがビデオまたは他の機能を有し得ることを指定し得る。
【０１４４】
図９は、本明細書で説明されるようなＯＰＩに基づいて、ＰｒｏＳｅ制御インターフェース動作を提供および／または使用し得る実施形態のためのネットワークアーキテクチャ概要を示している。例えば、ＡＰ  Ｘは、ＭＮＯ  ＹとのＰｒｏＳｅ協調合意を有し得、ＡＰ  Ｘの１組の加入者にＰｒｏＳｅサービスを提供することに、ＡＰ  ＸとＭＮＯ  Ｙは合意し得る。そのような合意は、ＡＳ−Ｘ１／３の場合は直接的とし得、またはＡＸ−Ｘ２の場合は間接的とし得、ＡＳ−Ｘ２は、拡張ＯｎｅＡＰＩゲートウェイなどのＡＰＩゲートウェイと協調し得る（例えば、ＡＰＩゲートウェイは、ＡＳとＰｒｏＳｅサーバの間の相互接続を成立させ得る）。
【０１４５】
加えて、そのような実施形態の変形が、アプリケーションとＰｒｏＳｅサーバの間にインターフェースが存在し得ないケースを可能にするために使用され得、そのような実施形態の変形は、本明細書で（例えば、以下で）説明されるように、ＵＥがカバレージの外に存在する場合のＤ２Ｄ通信、および／または複数のＰｒｏＳｅサーバもしくはＭＮＯが起動され得るケースを扱う拡張を容易にし得る。
【０１４６】
実施形態によれば、オープンＩＤ識別情報が、例えば、中間識別情報レイヤとして、提供および／または使用され得る。例えば、ＭＮＯによって提供されるオープンＩＤ識別情報が、ＵＥ、ＰｒｏＳｅサーバ、およびアプリケーションの間の中間識別情報として、提供および／または使用され得る。加えて、実施形態では、ＭＮと一体化された他の認証方式（例えば、リバティアライアンス）を使用して導出され得る識別情報も使用され得る。
【０１４７】
実施形態で説明されるように、ＵＥは、ＭＳＩＳＤＮまたは仮名を依拠当事者（例えば、一般にＡＳの一部として実施され得るＲＰ）に提供し得、（例えば、０で表されるＣＮ内のＧＢＡ／オープンＩＤノードの一部であり得る）ＮＡＦ／ＯＰは、この情報を認識し、それを３ＧＰＰ識別情報に関連付け得るようになる。加えて、実施形態では、ＮＡＦ／ＯＰは、ＵＳＳ（例えば、提供、定義、および／または使用され得る、ユーザセキュリティ設定またはＧＢＡ  ＵＳＳ）内に記憶され得る、ＩＭＰＩ、ＭＳＩＳＤＮ、または他の識別子を受信し得る。ＵＳＳは、ｆｉｒｓｔｎａｍｅ．ｌａｓｔｎａｍｅ＠ｅｘａｍｐｌｅ．ｃｏｍ、またはｍｙ．ｐｓｅｕｄｏｎｙｍ＠ｅｘａｍｐｌｅ．ｃｏｍなどのユーザＩＤ（ＵＩＤ）を含むことができる。そのため、ＧＢＡとオープンＩＤとの現在の統合は、いくつかのオープンＩＤ識別情報がエンドユーザから利用可能であることを可能にし得る。
【０１４８】
例示的な実施形態では、オペレータは、人間によって生成される仮名または機械によって生成される仮名を含む、新しいＩＤを生成するための技法を提供し得る（例えば、これは、ウェブポータルを通して、またはＵＥがオープンＩＤを使用して新しいアプリケーションにアクセスするときに自動的にトリガされるＵＥ上のローカルアプリケーションを通して行われ、その場合、ユーザは、既存のオープンＩＤを選択し得、またはアプリケーションのために新しいものを生成し得る）。この実施形態では、ローカルアプリケーションは、新しいＩＤを生成して返し得、またＩＤをＨＳＳ内のユーザプロファイルのＵＳＳに記憶し得る、オープンＩＤ識別情報マネージャサービスなどの、ＭＮＯによって提供されるサービスに接続し得る。
【０１４９】
実施形態によれば、ＭＮＯによって提供される識別情報を中間識別情報として使用することは有益であり得、そのため、ＰｒｏＳｅサーバは、この識別情報が加入者に有効に属し得ることを（例えば、ＨＳＳを用いてチェックすることによって）検証し得る。加えて、中間識別情報は、ユーザが、アプリケーションにログインすることなく、ＰｒｏＳｅ検出機能をオンにすることを可能にし得る、存続期間の長い識別情報とすることができる。
【０１５０】
アプリケーションに関連付けられたユーザ識別情報セットの例は、以下の通りであり得、または以下のうちの１もしくは複数を含むことができ、すなわち、それらは、彼女がいくつかの仕事関連または政府関連のアプリケーションとともに使用することを選択した識別情報であり得る、ａｌｉｃｅ．ｓｍｉｔｈ＠ｍｎｏ１．ｃｏｍ、彼女がいくつかの電話関連のアプリケーションとともに使用することを選択した識別情報であり得る、＜ＭＳＩＳＤＮ＞＠ｍｎｏ１．ｃｏｍ、彼女がオンラインファイルホスティングサービスにログオンするために使用し得る、（例えば、要求時にＭＮＯ１によって生成される）ａｂｃ１２３ａｂ１２＠ｍｎｏ１．ｃｏｍ、ならびに彼女がＣｏｍｐＮａｍｅメール、ＣｏｍｐＮａｍｅトーク、および他のＣｏｍｐＮａｍｅアプリケーションにログインするために使用し得る（例えば、ＣｏｍｐＮａｍｅは、これらのアカウントが同じ物理的人物に属し得ることを認識し得ない）、異なるＩＤであり得る、５６７ａｂｃ１２ｄｃ＠ｍｎｏ１．ｃｏｍ、および７８９ｃｄｅ３４ｅｄ＠ｍｎｏ１．ｃｏｍなどである。
【０１５１】
実施形態では、いくつかのアプリケーションプロバイダは、ユーザが２以上のアカウントを有することを不可能にし得る（例えば、ユーザが２以上の異なるアカウントを有することを不可能にし得る）ポリシを有し得る。セルラユーザおよびアプリケーションレイヤユーザ識別情報毎に提供されるＯＰＩ識別情報は、直交であり得、アプリケーションにおけるマッピングを通して関連し得るので、本明細書で開示される実施形態は、そのようなタイプのポリシをサポートし得る。
【０１５２】
加えて（例えば、利用の容易さ対プライバシに関して）、ユーザ関与を最低限に抑えるために、ユーザは、単一のＯＰＩ識別情報をサービスとともに使用し得る。これは、サードパーティが、このユーザの関与を異なるアプリケーションに関連付けることを可能にし得、または可能にさせ得る。（例えば、仕事用に１つ、ゲーム用に１つなど）いくつかのレベルの仮名識別情報が、提供および／または使用され得る（例えば、それによって、少しまたは僅かながら、より安全になり得る）。加えて、ユーザは、アプリケーション毎に１または複数の個別の識別情報を使用することを選択し得る。
【０１５３】
実施形態によれば、（例えば、サービス登録のための）ＵＥ−ＰｒｏＳｅ制御インターフェースが提供および／または使用され得る。例えば、（例えば、近接性発見およびデバイスツーデバイス通信など）アプリケーションＸに関連するＰｒｏＳｅサービスから利益を得ることを要望または望むことがあるユーザは、適切なＯＰＩ識別情報（例えば、アプリケーションＸがＵＥのユーザのアプリケーション識別情報に関連付け得たＯＰＩ識別情報）を使用して、ＰｒｏＳｅサーバに登録し得る。実施形態では（例えば、一般に）、ＵＥが認証され得るように、また提供されたＯＰＩ識別情報が実際にユーザに属し得ること（例えば、それが加入者のプロファイルのＵＳＳに記載され得ていること）を保証するために、ＰｒｏＳｅサーバがＨＳＳと通信し得るように、ＵＥとＰｒｏＳｅサーバの間のＮＡＳシグナリングが使用され得る。代替的な実施形態は、ＵＥとＰｒｏＳｅサーバの間のアプリケーションシグナリング（例えば、ＨＴＴＰＳ）を使用することを含むことができる。この実施形態では、ＧＢＡ／オープンＩＤが統合された手順が、ユーザを適切に認証するために使用され得る。例示的な実施形態によれば、それは安全であり得、また認証されて、ＰｒｏＳｅサーバがＵＥの３ＧＰＰ識別情報などの識別情報を知り得る（例えば、したがって、加入者プロファイルをＨＳＳから獲得し得る）ことを保証し得るので、ＮＡＳシグナリングが提供および／または使用され得る。代替的な実施形態では、ＰｒｏＳｅサーバは、与えられたＯＰＩ識別情報に関連する加入者プロファイルを獲得するために、ＨＳＳに問い合わせ得る。ＰｒｏＳｅサーバがＥＰＳの一部であり得る場合にも、ＮＡＳシグナリングが提供および／または使用され得る。実施形態によれば、ＰｒｏＳｅサーバは、ＥＰＣ内のいくつかの他のエンティティとインターフェース接続し得るので、それは、ＥＰＣの外部ではなく、ＥＰＣの一部と見なされ得る。
【０１５４】
Ｐｒｏｘｉｍｉｔｙサービス機能（例えば、それの便益）への明示的な登録は、ユーザによるＰｒｏＳｅサーバのきめ細かい制御を可能にし得る。例えば、ユーザは、アプリケーションにログインしている場合であっても、（例えば、バッテリ電力を節約するために）いずれかのＰｒｏｘｉｍｉｔｙサービスを止めることを要望または望み得る。ユーザは、どのアプリケーションにおいてＰｒｏｘｉｍｉｔｙサービスを使用することを望みまたは要望するかを選択し得る。１つのアプリケーション内であっても、ユーザは、１つのアプリケーション識別情報を使用する場合はＰｒｏｘｉｍｉｔｙサービスを使用し、別のものを用いる場合は使用しないことを望みまたは要望し得る。加えて、いくつかの協力するアプリケーションに加入するユーザは、これらのアプリケーションの各々において同じ識別情報を使用することから利益を得ることができる。例えば、Ｄ２Ｄビデオアプリケーションなどのアプリケーションは、同じエリアで動作する異なるＰＬＭＮとともに機能し得、ユーザ間でのＰｒｏＳｅ機能の網間接続を可能にすることを決定し得る。
【０１５５】
ＵＥは、ＰｒｏＳｅサーバに認証され得た後、例えば、以下のうちの１または複数を含む、この登録についての１または複数のパラメータを送信し得る。例えば、ＵＥは、アプリケーションが、ＰｒｏＳｅ  ＡＰＩを使用する場合に、それ自体を識別するために使用し得る名前であり得る、ａｐｐ−ｎａｍｅ＠ａｐｐ−ｄｏｍａｉｎ．ｃｏｍなどの、受け入れられたアプリケーションの識別情報を含むこと、または送信することができる。アプリケーションＩＤとともに、ＵＥは、（例えば、発見、およびアプリケーション通知など）このアプリケーションのための認可されたＰｒｏＳｅ機能のリストも含むことができる。
【０１５６】
加えて、アプリケーション固有の構成が、（例えば、ＵＥによって）含まれ、または送信され得る。例えば、アプリケーション固有の構成は、ＰｒｏＳｅサーバに不明瞭なデータであり得、例えば、ＸＭＬドキュメントを含むことができ、またはＸＭＬドキュメントであり得る。ＭＮＯがこの情報にアクセスし得ないことを保証するために、実施形態では、アプリケーション固有の構成は、アプリケーションによって提供される公開鍵を使用して、それを暗号化することによって、秘密にされ得る。加えて、アプリケーションは、この構成を（例えば、ＰｒｏＳｅサーバからの通知を通して）ＰｒｏＳｅサーバから獲得し得る。使用の一例は、発見可能性を、（ソーシャルネットワークアプリケーション内の友人またはサークルなど）限定された１組の他のアプリケーション加入者に限定することとすることができる。使用の別の例は、デバイスの機能（例えば、デバイスがビデオ機能および／または他の機能を有し得るかどうか）についての記述を提供することとすることができる。
【０１５７】
実施形態では、ＵＥ−ＰｒｏＳｅサーバ通信は、（例えば、一般に）ＮＡＳシグナリングを通したものであり得るので、ＰｒｏＳｅサーバは、デバイスの識別情報（例えば、ＴＭＳＩ）を有し得、したがって、どのデバイスが与えられた識別情報とともに登録され得ているかを知り得る。加えて、アプリケーションは、上で説明された、アプリケーション固有の構成を通して伝達され得る、ビデオに対するサポートなど、アプリケーション関連の機能を除いて、それ（例えば、デバイスおよび／または与えられた識別情報）について知り得ず、関心をもち得ない。ＰｒｏＳｅサーバは、ＯＰＩ識別情報に言及する要求を受信し得た場合、デバイスが、与えられたＯＰＩ識別情報を用いて、現在ログオンまたはログインし得ているかどうかをチェックし得る。そのため、ＰｒｏＳｅサーバは、ＯＰＩ識別情報を、加入者（例えば、ＵＳＩＭ上の加入者識別情報によって表されるようなＡｌｉｃｅ）と対応付け、またＰｒｏｘｉｍｉｔｙサービス（例えば、デバイスツーデバイス通信、近接性検出など）を可能にし得る、この識別情報に現在登録されているデバイスと対応付け得る。
【０１５８】
ＵＥ−アプリケーションインターフェース上のユーザ識別情報も、本明細書で説明されるように提供および／または使用され得る。例えば、実施形態では、ＵＥは、例えば、２回（例えば、一度はＯＰＩ識別情報を用いて、一度はアプリケーションレイヤユーザ識別情報を用いて）、アプリケーションに認証され得る。本明細書で説明されるように、これらのレベルの認証は、統合され得、または少なくとも、ユーザに対する影響は、最小化され得る。
【０１５９】
例えば、実施形態（例えば、ケース１）では、アプリケーションプロバイダは、自らのアプリケーションレイヤ認証方式（例えば、ソーシャルネットワークアプリケーションログイン）を使用し得る。このアプリケーションを通してＰｒｏＳｅサービスを使用することを可能にするために、ユーザは、アプリケーションプロファイルにＯＰＩ識別情報をさらに入力することを求められる。この時点から、アプリケーションは、アプリケーションＩＤとＯＰＩ識別情報を対応付け得る。
【０１６０】
別の実施形態（例えば、ケース２）では、アプリケーションプロバイダは、ユーザのＯＰＩ識別情報を通してユーザを認証することを選択し得る。そのような実施形態では、アプリケーションレイヤユーザ識別情報とＯＰＩ識別情報は、同じとすることができ、対応付けは、使用または提供されなくてよい。
【０１６１】
さらに、実施形態（例えば、ケース３）では、アプリケーションプロバイダは、アプリケーションレイヤユーザ識別情報またはＯＰＩ識別情報を通して、ユーザを認証し得る。例えば、Ｆａｃｅｂｏｏｋなどのサービスは、一般にアプリケーションレイヤログインを受け入れ得るが、ＰｒｏＳｅサービスを提供するＭＮＯなど、あるオープンＩＤプロバイダからのオープンＩＤ識別情報も受け入れ得る。ＵＥ上のクライアントアプリケーションまたはエージェントは、したがって、選択されたＯＰＩ識別情報を使用して、アプリケーションにログインし得る。実施形態では、アプリケーションは、（例えば、初回には）既存のアカウントにログインするようにユーザに提案し得、アプリケーションＩＤとＯＰＩ識別情報の間の対応付けを記録し得る。そのため、次回、またはアクセスを試みる場合、アプリケーションは、このアカウントにユーザを自動的にログインさせ得る。
【０１６２】
例示的な実施形態によれば、アプリケーション−ＰｒｏＳｅ制御インターフェースが、本明細書で説明されるように（例えば、サービス要求のために）提供および／または使用され得る。例えば、アプリケーション−ＰｒｏＳｅサーバ制御インターフェースは、直接的なインターフェースとすることができ、または代わりに、ＡＰＩゲートウェイ（例えば、拡張ＯｎｅＡＰＩゲートウェイ）を通して存在し得る。このインターフェースは、Ｐｒｏｘｉｍｉｔｙサービス要求を伝達するために使用され得る。そのような要求は、以下のうちの１または複数を、すなわち、（例えば、本明細書で説明され得る）Ｄ２Ｄ通信、近接性検出、およびアプリケーションウェイクアップ通知などのうちの１または複数を含むことができる。ＵＥがＰｒｏＳｅ機能をアクティブ化し得た場合に通知される、ＯＰＩ識別情報検出および／または登録など、さらなる機能が、このインターフェース上で可能にされ得る。例示的な実施形態によれば、そのような要求でアプリケーションによってＰｒｏＳｅサーバに提供される情報は、以下のうちの１または複数を、すなわち、アプリケーションＩＤ（例えば、ＡＰまたはＭＮＯによって提供され得、ＰｒｏＳｅサービス協調合意の一部として合意され得る識別子）、要求のタイプ（例えば、Ｄ２Ｄ通信、近接性検出、およびアプリケーションウェイクアップ通知など）、本人（例えば、この要求を発したユーザ）のＯＰＩ識別情報、他のユーザ（例えば、Ｄ２Ｄ通信の場合は相手、近接性検出の場合は友人のグループ、およびアプリケーションウェイクアップ通知の場合はなしなど）のＯＰＩ識別情報、ならびにＤ２Ｄ通信上のトラフィックフローを識別し得る何らかのトラフィックフィルタなどのうちの１または複数を含むことができる。
【０１６３】
加えて、実施形態では、アプリケーション−ＰｒｏＳｅ制御インターフェースが、保護されたウェブサービスとして実施され得る。例えば、ゲートウェイが提供および／または使用され得る場合、ゲートウェイの両側で、異なるプロトコルが提供および／または使用され得る。
【０１６４】
請求も、本明細書で説明されたように、提供および／または使用され得る。実施形態では、近接サーバは、請求システム（例えば、一般にＲｆ／Ｍｆ上のオフラインＯＦＣＳ、または一般にＲｏ／Ｍｏ上のオンラインＯＣＳ、ここで、Ｍｏ／Ｍｆは、現在提供および／または使用され得、セキュリティの追加レイヤなどの追加された機能を有するＲｏ／Ｒｆに基づき得る、Ｒｏ／Ｒｆと等価のインターフェースであり得る）と相互接続され得る。
【０１６５】
実施形態では、Ｐｒｏｘｉｍｉｔｙサービス請求の場合、アプリケーションプロバイダは、サービスに対する料金を請求され得、または請求され得た。そのようなモデルを可能にするために、（例えば、有益な概要を含むように現在定義および／または提供され得る）既存のスポンサ付きデータ接続性機能が拡張され得る。今日、それは、ＡＦとＰＣＲＦの間のＲｘインターフェース上で可能にされ得る。ＰＣＲＦは、その後、ベアラをセットアップまたは更新するために、ＰＣＥＦ／ＢＢＥＲＦ（例えば、ＰＤＮゲートウェイ）と通信し得る。ＰＤＮゲートウェイは、請求システムと通信し得る。例えば、それは、アカウンティング記録をＲｆ上でオフライン請求システムに送信し得、または記録され得る使用データをＲｏ上でオンライン請求システムに送信し得る。Ｒｏ／Ｒｆインターフェースは、スポンサ−識別情報ＡＶＰ（例えば、Ｒｘのために定義されるのと同じＡＶＰ）にスポンサ識別情報を設定することをサポートし得る。あるいは、特定の請求鍵が、請求記録をアプリケーションプロバイダに関連付けるために、請求システムによって使用され得る。
【０１６６】
例示的な実施形態によれば、ＰｒｏＳｅサーバは、アプリケーションプロバイダ識別情報をスポンサとしてＲｏ／ＲｆもしくはＭｏ／Ｍｆに渡し得、および／または特定のアプリケーションプロバイダに関連付けられた特定の請求鍵を使用し得る。そのような実施形態は、シグナリング変更を使用し得ないが、（例えば、この新しいスポンサ機能はデータ接続性の他に、請求イベントのためのものであり得るので、またＰＣＥＦまたはＢＢＥＲＦ以外の別のエンティティが機能を利用し得るので）既存のシグナリングの新しい使用を含むことができる。
【０１６７】
加えて、ＰｒｏＳｅサーバは、例えば、Ｒｘ上で、Ｄ２ＤポリシをＰＣＲＦに伝達し得る場合、このセッションがＡＰによって支払われ得ることを仮定して、（例えば、上で説明されたＡＶＰを使用して）スポンサ識別情報も設定し得る。
【０１６８】
そのため、実施形態では、ＰｒｏＳｅ動作の料金をアプリケーションプロバイダに請求ことが、（例えば、ＰｒｏＳｅサービス自体の料金を請求するために）一方の側において、拡張された「スポンサ付きデータ接続性」ＰＣＣ機能を使用するＰｒｏＳｅサーバを有することによって可能にされ得、（例えば、Ｄ２Ｄ接続上のトラフィックの料金を請求するために）他方において、既存の「スポンサ付きデータ接続性」ＰＣＣ機能を使用し得る。
【０１６９】
セキュリティ機能および／または態様も、本明細書で説明されるように提供および／または使用され得る。例えば、実施形態では、ＵＥがＰｒｏＳｅサーバに対して偽のＯＰＩ識別情報を使用するリスクが軽減され得る。本明細書で説明されるように、ＵＥとＰｒｏＳｅサーバの間の通信の方法は、ＮＡＳシグナリングを介したもの、またはＮＡＳシグナリング上のものであり得る。これは、ＵＥが認証され得、通信が保護され得ることを保証し得る。ＰｒｏＳｅサーバは、したがって、ＵＥのセルラネットワーク識別情報（例えば、ＴＭＳＩ）を知り得る。ＰｒｏＳｅサーバは、その後、ＨＳＳから加入者プロファイルを獲得し得、与えられたＯＰＩ識別情報が実際にこのプロファイルのＵＳＳセクションに記載されていることを検証し得る。
【０１７０】
ＵＥ−ＰｒｏＳｅサーバ通信がアプリケーションレイヤ（例えば、ＨＴＴＰＳ）で行われ得る、実施形態では、ＵＥは、ＧＢＡ−リバティアライアンス、オープンＩＤ、および／または他の統合された手順を使用して、ＰｒｏＳｅサーバに認証され得るが、その結果、ＭＮＯが、使用されるＯＰＩ識別情報と、ＵＥ  ３ＧＰＰ識別情報などのＵＥ識別情報との間の結び付きを保証し得るので、ＵＥは、偽のＯＰＩ識別情報を使用し得なくなる。ＰｒｏＳｅサーバは、問い合わせ（例えば、新しい問い合わせ）を使用して、与えられたＯＰＩ識別情報を含み得る加入者プロファイルを獲得することによって、ＨＳＳから加入者プロファイルを獲得し得る。
【０１７１】
加えて、実施形態では、ＵＥがアプリケーションに対して偽のＯＰＩ識別情報を使用するリスクが軽減され得る。例えば、ＵＥがアプリケーションに対して偽のＯＰＩ識別情報を使用するリスクは、本明細書で説明されるオープンＩＤ認証手順の使用を通して軽減され得る。実施形態（例えば、ケース１）では、ＵＥは、ＧＢＡ−リバティアライアンス、オープンＩＤ、および／または他の統合された手順を使用して、アプリケーションサーバを認証し得る。そのような実施形態は、アプリケーションプロバイダがＭＮＯとのサービス協調を有し得る場合に使用され得る。加えて、そのような実施形態では、ＭＮＯは、このＵＥが実際にこの識別情報を保有することを保証し得る。
【０１７２】
別の実施形態（例えば、ケース２）によれば、アプリケーションは、他の認証方式（例えば、サードパーティ識別情報プロバイダからのＯＡｕｔｈもしくはオープンＩＤ、またはアプリケーションレイヤ認証）を使用し得る。Ｐｒｏｘｉｍｉｔｙサービスを使用するために、アプリケーションは、その後、ユーザがＯＰＩ識別情報を入力するための方法（例えば、ウェブフォーム）を提供し得る。アプリケーションは、ＯＰＩ識別情報が有効にエンドユーザに属し得ることを検証するために、（例えば、統合されたＧＢＡまたはオープンＩＤ手順を使用して）認証手順を実行し得る。実施形態では、アプリケーションは、ＧＢＡ／オープンＩＤ手順が使用され得ることを認識し得ない。例えば、アプリケーションは、識別情報プロバイダが、ＰｒｏＳｅサービスを提供し得るＭＮＯであり得ることを知り得る。
【０１７３】
アプリケーションがＰｒｏＳｅサーバに対して偽のＵＥ  ＯＰＩ識別情報を使用するリスクも軽減され得る。例えば、ＭＮＯは、ＡＰが自らの加入者のオープンＩＤを使用し得ることを盲目的に信用し得ない。そのため、実施形態では、ＰｒｏＳｅアプリケーションＡＰＩは、「ｕｓｅｒ＿ｉｄ＿ｖｅｒｉｆｉｃａｔｉｏｎ（ＯＰＩ識別情報）」関数を含むことができ、アプリケーションは、検証されたＯＰＩ識別情報を利用し得る（例えば、１つの未検証のＯＰＩ識別情報を含む要求は拒否され得る）。（例えば、ＭＮＯおよびＡＰが同じエンティティであり得る）いくつかの実施形態では、
これ（例えば、関数）は省略され得る。
【０１７４】
検証ＡＰＩは、（例えば、この時点でアプリケーションとＰｒｏＳｅサーバの両方にログオンし得る）ＵＥの他、アプリケーションにも関与し得る。この手順では、ＰｒｏＳｅは、アプリケーションによって与えられたＯＰＩ識別情報が実際にアプリケーションにログオンし得ることを検証し得る。例えば、ＰｒｏＳｅサーバは、ランダムなトークンをアプリケーションに送信し得る。アプリケーションは、それをＵＥに（例えば、アプリケーションシグナリングを通して）伝達し得る。加えて、ＵＥは、ＰｒｏＳｅサーバに通知するために、ＰｒｏＳｅサーバ−ＵＥ  ＡＰＩ関数「ｕｓｅｒ＿ｉｄ＿ｖｅｒｉｆｉｃａｔｉｏｎ＿ｔｏｋｅｎ（ｕｎｅｎｃｒｙｐｔｅｄ＿ｔｏｋｅｎ）」を通して、トークンを送信し得る。実施形態では、ＵＥは、ＰｒｏＳｅサーバに認証され得、ＰｒｏＳｅサーバは、（例えば、ＵＥが、ＵＥとＰｒｏＳｅサーバの間の安全な認証されたアプリケーションセッション上で、この情報を伝達し得るので）与えられたＯＰＩ識別情報に関連付けられたＵＥが、実際にアプリケーションと通信し得ることを知り得る。ＯＰＩ検証は、一定の期間、有効であり得、および／または手順は、アプリケーションから退出するユーザを考慮して、アプリケーションによって周期的に再実行され得る。識別情報検証手順は、以下でより詳細に説明され得る。
【０１７５】
実施形態によれば、アプリケーションが偽のＡｐｐ  ＩＤを使用して、別のアプリケーションプロバイダに請求を行うリスクが軽減され得る。例えば、アプリケーションＸは、ＰｒｏＳｅサーバに伝達する場合にアプリケーションＹのＩＤを使用して、利用コストを別のアプリケーションプロバイダに転嫁し得る。そのような問題を回避するために、アプリケーションとＰｒｏＳｅサーバの間の安全な接続が提供および／または使用され得る。加えて、ＡＰとＭＮＯの間のＰｒｏＳｅ合意の一環として、ＡＰは、その識別情報（例えば、ドメイン名）をＭＮＯに伝達し得、またはＭＮＯからそれ（例えば、アカウント番号）を獲得し得る。そのような識別情報は、相互接続セットアップ中に、安全に伝達され得る（例えば、それは、信用されたサードパーティ（認証局）によって配送され得る公開鍵証明書によって保証され得る）。
【０１７６】
実施形態では、ユーザセキュリティ設定（ＵＳＳ）増大のリスクが軽減され得る。例えば、ＧＢＡまたはオープンＩＤ統合が使用され得る場合、オープンＩＤ識別情報は、加入者プロファイルのＵＳＳ内に記憶され得る。そのような実施形態では、１つの潜在的な問題は、様々な識別情報が長期間にわたって蓄積され、とめどなく増大するＵＳＳのサイズをもたらすことを含むことができる。そのよう難点を抑制するために、ＭＮＯは、一般に、識別情報の数を制限し得る。例えば、数個の長期識別情報（例えば、＜ＭＳＩＳＤＮ＞＠ｍｎｏ．ｃｏｍ）が、ＭＮＯによってセットアップされ得、ユーザによって変更され得ない。加えて、ユーザは、固定された最大数を超えるこれらのエントリが存在し得ないように、数個の識別情報（例えば、ｆｉｒｓｔ．ｌａｓｔ＠ｍｎｏ．ｃｏｍ）を選択し得、および／または新しい識別情報を生成するために、ユーザは、その後、古いものを削除し得る。
【０１７７】
実施形態では、ＭＮＯは、（例えば、１つの特定のアプリケーションとともに使用される）識別情報をオンデマンドでも生成し得る。これらのエントリは、作成日付または単調増加数と関連付けられ、識別情報（例えば、＜ｒａｎｄｏｍ＞−１２＠ｍｎｏ．ｃｏｍ、＜ａｎｏｔｈｅｒ−ｒａｎｄｏｍ＞−１３＠ｍｎｏ．ｃｏｍなど）の一部とし得、または識別情報とともに記憶され得る。加えて、識別情報の最大数に到達し得た場合、最も以前に生成された識別情報が削除され得る。あるいは、実施形態では、最後に使用された日付−時刻が識別情報とともに記憶され得、最も以前に使用された識別情報が代わりに削除され得る。そのような実施形態では、ユーザは、もはや存在し得ない、または使用され得ない、古い識別情報の再利用を望み得る。新しいＯＰＩ識別情報も生成され得る。そのため、アプリケーションは、特定のアプリケーション識別情報に関連付けられたＯＰＩ識別情報の変更をサポートし得る。
【０１７８】
本明細書で説明されるように、アプリケーションとＰｒｏＳｅサーバの間のインターフェースが存在し得ない場合のサポートが提供され得る。例えば、本明細書で開示される実施形態の１つの特徴は、Ｐｒｏｘｉｍｉｔｙサービスがアプリケーションを通して可能にされ得ることとすることができる。そのような実施形態またはモデルは、（例えば、ＰｒｏＳｅサーバとのインターフェースを有さないサードパーティアプリケーションに関連する）ＰＬＭＮ加入者の各々によってアクセス可能な汎用Ｐｒｏｘｉｍｉｔｙサービスを有することを妨げ得ない。例えば、汎用近接性検出およびＤ２Ｄオーディオ／ビデオ接続サービスが、オペレータによって配備され得、ＭＮＯは、この実施形態では、ＭＮＯ−ＰｒｏＳｅ−アプリケーションなどのアプリケーション（例えば、非ＩＭＳ  ＡＳ）を配備し得る。ＭＮＯ−ＰｒｏＳｅ−アプリケーションは、ＰｒｏＳｅサーバと関連付けることができ、またはＰｒｏＳｅサーバの一部として実施され得る。他の外部的に提供されるアプリケーションは、ＭＮＯとの関係を有し得るが、ＥＰＣへのインターフェースを有し得ない。
【０１７９】
請求の観点からは、アプリケーションがＰｒｏＳｅサーバとのインターフェースを有し得ない場合であっても、アプリケーションは、ＭＮＯとの合意を有し得、または有し得ない。実施形態では、アプリケーションが料金を請求され得、例えば、ＵＥは、アプリケーション識別情報をＰｒｏＳｅサーバに渡し得、ＭＮＯは、（例えば、サードパーティＣＡからのＡｐｐ識別情報、アプリケーションサーバからの認可、ならびにＨＳＳおよび／またはＰｒｏＳｅサーバ内の内部ＰＬＭＮ構成からのチェック認可などの）検証を実行し得る。実施形態では、エンドユーザがサービスの料金を請求され得る。
【０１８０】
加えて、実施形態では、メカニズムの基本原理は、ＵＥが要求をアプリケーションに送信し得、アプリケーションは、要求の様々な行為者のアプリケーションレイヤユーザ識別情報からマッピングされるＯＰＩ識別情報のリストによって（例えば、受け入れられる場合は）応答し得る。アプリケーションは、Ｄ２Ｄ通信のためのトラフィックを識別するフィルタなど、他の情報も追加し得る。ＵＥは、その後、ＭＮＯ−ＰｒｏＳｅ−アプリケーションに、本明細書で（例えば、上で）説明された要求などの要求を送信し得る。
【０１８１】
そのため、Ａｐｐ−ＣＮインターフェースがない実施形態のサポートは、アプリケーションが（例えば、おそらくはＰｒｏＳｅサーバ自体の一部として）ＭＮＯによって配備され得る、本明細書で説明される第２の実施形態の主要な変形の特殊なケースであり得る。主要な相違は、（例えば、ＣＮとのインターフェースを有さない）サードパーティアプリケーションが、ユーザ名をＯＰＩ識別情報と対応付けることができ得、これらのＯＰＩ識別情報を要求時にユーザに提供し得ることとすることができる。実施形態では、サードパーティアプリケーションのユーザ名がＯＰＩ識別情報であり得る場合、対応付けは使用されなくてよい。それ以外の場合、サードパーティアプリケーションは、本明細書で説明されるように、ユーザ名／ＯＰＩ識別情報の対応付けをサポートしなければならない。
【０１８２】
実施形態では、ＵＥがカバレージの外にあり得る場合のサポートも提供され得る。例えば、ＵＥの１または複数がセルラネットワークカバレージの外にあり得る場合、デバイスツーデバイス通信も可能にされ得る。この実施形態では、各ＵＥは、発見の他、Ｄ２Ｄ機能のためにも使用され得る、他の識別情報を認識し得る。さらに、ＵＥは、両立可能なＤ２Ｄ検出構成を有し得る（例えば、一方のＵＥはリスン動作中であり得、他方のＵＥはビーコンの送信を開始し得る）。
【０１８３】
そのような実施形態の方法は、例えば、ＵＥがネットワークカバレージの下にあり得、アプリケーションおよびＰｒｏＳｅサーバに接続され得るときに、あらかじめそのような動作のために、ＵＥを事前構成することを可能にし得る。実施形態では、１つのユーザが、アプリケーションとともに、事前構成手順を開始し得る。アプリケーションは、要求をＰｒｏＳｅサーバに送信し得る。ＰｒｏＳｅサーバは、（例えば、ＯＰＩ識別情報からＵＥ識別情報へのマッピングの後、ＵＥが適切な識別情報とともにＰｒｏＳｅサーバに登録されることを望み得る）要求をＵＥに伝達し得る。この実施形態で説明される典型的な発見またはｄ２ｄ接続とは対照的に、ＰｒｏＳｅサーバは、これらの要求を「遅延」としてマークし得る。加えて、何らかの時刻またはイベント（例えば、「カバレージ外」イベント）における「ユーザ開始」など、１または複数のトリガタイプを、これらの要求に関連付けることができる。
【０１８４】
第１の実施形態に類似する方法では、アプリケーションおよびＰｒｏＳｅサーバは、動作のための一時サービス名を確立し得、本明細書で説明されるものなど（例えば、時間制限およびＱｏＳ要件など）、パラメータをそれに関連付けることができる。そのため、カバレージ外のケースのサポートは、第１の実施形態の拡張として使用または提供され得る。
【０１８５】
ＰｒｏＳｅ機能の初期アクティブ化のための手順または方法が、図１０に示され得る。例えば、図１０に示されるメッセージフローは、ユーザがアプリケーションにログインしたときに実行され得、このアプリケーション内でＰｒｏｘｉｍｉｔｙサービスをオンにし得る、手順または方法を説明し得る。この例では、アプリケーションは、アプリケーションレイヤログインおよびオープンＩＤログインの両方をサポートし得る。実施形態（例えば、ケース１および２）の他、他の実施形態（例えば、ケース）もサポートされ得る。
【０１８６】
加えて、識別情報検証手順もしくは方法が、図１１に示され得、アプリケーションにログインして、もしくはログインせずに、ＰｒｏＳｅに登録するための手順もしくは方法が、図１２に示され得、および／または発見手順もしくは方法が、図１３に示され得る。図１２に示される方法または手順は、ＵＥベースの発見を示し得る。しかしながら、実施形態では、ＭＭＥが、ＵＥから近接性更新を収集し得、この情報に基づいて近接性を検出し得る、ネットワークベースの発見も提供および／または使用され得る。アプリケーションウェイクアップ通知方法または手順が、図１４に示され得、デバイスツーデバイス接続セットアップ手順または方法が、図１５に示され得る。
【０１８７】
本明細書で説明されるように、１または複数の拡張が提供および／または使用され得る。例えば、複数のＰｒｏＳｅサーバが、ロードバランシングおよびフォールバックのために、ＭＮＯによって配備され得る。この実施形態では、ＵＥがＰｒｏＳｅサーバに登録し得た後、このＰｒｏＳｅサーバは、ＤＮＳシステムまたは別のマッピングシステムを使用して、それ自体と、ＵＥによって使用され得る特定のＯＰＩ識別情報とを結び付け得る。異なるＰｒｏＳｅサーバによって扱われるＵＥに対するＰｒｏＳｅサービスが要求され得た場合、これらのサーバは協力し得る。例えば、アプリケーションによって最初に接触が図られ得るＰｒｏＳｅサーバ（例えば、「代理ＰｒｏＳｅサーバ」）は、ＤＮＳを使用して、それが知り得ない識別情報を扱う他のＰｒｏＳｅサーバを見つけ出し、その後、３ＧＰＰ  ＵＥ識別情報などのＵＥ識別情報を、（例えば、ｇｅｔ＿ｕｓｅｒ＿ｐｒｏｆｉｌｅ（ＯＰＩ識別情報，ＡＰ−Ｘ）などの、ＰｒｏＳｅサーバ−ＰｒｏＳｅサーバメッセージを使用して）これらのＰｒｏＳｅサーバに要求し得る。例示的な実施形態では、要求アプリケーションが、ＰｒｏＳｅサーバに登録するときに、エンドユーザによって認可され得た場合、これらのＰｒｏＳｅサーバは、３ＧＰＰ  ＵＥ識別情報などのＵＥ識別情報を提供し得る。
【０１８８】
同様に、異なるＭＮＯによって配備されるＰｒｏＳｅサーバも、３ＧＰＰ  ＵＥ識別情報を交換するために協力し得、代理ＰｒｏＳｅサーバは、ＰｒｏＳｅサービスを可能にするために、異なるコアネットワークのノードと対話し得るようになる。
【０１８９】
（例えば、同じＰＬＭＮ内の、または異なるＰＬＭＮの）複数のＰｒｏＳｅのための拡張は、以下のうちの１または複数を含むことができる。例えば、一実施形態（例えば、拡張）では、２つのＰｒｏＳｅサーバの間のインターフェースが可能にされ得、このインターフェースは、例えば、ＭＮＯがロードバランシングのために２以上のＰｒｏＳｅサーバを配備し得る場合、１つのＭＮＯの内部にあり得る。加えて、このインターフェースは、例えば、２つのＭＮＯがＰｒｏＳｅ協力合意を有し得る場合、これらの２つのＭＮＯの間に存在し得る。
【０１９０】
例示的な実施形態（例えば、拡張）では、ＧｅｔＩｄｅｎｔｉｆｉｅｒなどの、ＰｒｏＳｅサーバ対ＰｒｏＳｅサーバメッセージ（例えば、新しいメッセージ）が提供および／または使用され得る。そのようなメッセージは、ＯＰＩ識別情報、および要求アプリケーションの名前などを含む、１または複数のパラメータを含むことができる。加えて、そのような要求またはメッセージを相手から受信した場合、ＰｒｏＳｅサーバは、現在登録されているＵＥの中からＯＰＩ識別情報を探索し得、以下の情報のうちの１または複数を、すなわち、ＯＰＩ識別情報に関連する３ＧＰＰ識別情報（例えば、ＴＭＳＩ、ＭＳＩＳＤＮ）、およびＰｒｏＳｅ機能などのうちの１または複数を返し得る。そのような実施形態では、アプリケーションは、ＭＮＯ１およびＭＮＯ２の両方とのＰｒｏＳｅ合意を有し得る。そのため、アプリケーションは、ＵＥ２などのＵＥがＰＬＭＮ２などの特定のＰＬＭＮに登録され得ることを通知され得る。この通知は、アプリケーション固有の構成を含むことができ、アプリケーションは、ＭＮＯ１を通して動作を要求する場合に、この構成を考慮し得るようになる。
【０１９１】
実施形態（例えば、拡張）によれば、ＰｒｏＳｅサーバとＯＰＩ識別情報の間のＤＮＳまたはＥＮＵＭマッピング、およびそのための方法が提供および／または使用され得る。例えば、ＵＥがＯＰＩ識別情報をＰｒｏＳｅサーバに登録し得る場合、ＰｒｏＳｅサーバは、ＤＮＳまたはＥＮＵＭシステムのマッピング情報（例えば、ａｌｉｃｅ＠ｍｎｏ１．ｃｏｍに対して、ｐｒｏｓｅサーバｐｒｏｓｅ−ｓｅｒｖｅｒ−１．ｍｎｏ１．ｃｏｍのエイリアスとしてａｌｉｃｅ．ｐｒｏｓｅ．ｍｎｏ１を定義し得る、ＤＮＳ  ＣＮＡＭＥエントリ）をアップロードし得る。
【０１９２】
加えて、ＰｒｏＳｅサーバが、現在このＰｒｏＳｅサーバにログインされていない少なくとも１つのＯＰＩ識別情報（例えば、ｂｏｂ＠ｍｎｏ１．ｃｏｍ、またはｂｏｂ＠ｍｎｏ２．ｃｏｍ）を含む要求を受信した場合、サーバは、以下のうちの１または複数（例えば、手順、または方法、またはアクション）を実行し得る。例えば、識別情報プロバイダが、ＰｒｏＳｅサーバを配備するものと同じＭＮＯであり得る場合、および／またはいくつかのＰｒｏＳｅサーバが、このＭＮＯによって配備され得る場合、ＤＮＳシステムは、ｂｏｂ．ｐｒｏｓｅ．ｍｎｏ１．ｃｏｍについて問い合わせされ得る。回答が得られ得た場合、ＰｒｏＳｅサーバのＢｏｂの３ＧＰＰ識別情報は、返されたＩＰアドレスに（ＧｅｔＩｄｅｎｔｉｆｉｅｒ（）を使用して）要求され得る。回答が得られ得ない場合、このＯＰＩ識別情報は、登録され得ておらず、ローカルポリシに応じて、ＰｒｏＳｅサーバは、元の要求を拒否し得、または可能であれば部分的な処理を継続し得る。加えて、ＭＮＯによって配備されるＰｒｏＳｅサーバが１つしか存在し得ない場合、このＯＰＩ識別情報は、登録され得ていない（例えば、上で説明されたように、拒否され得、または部分的な処理が継続され得る）。実施形態では、識別情報プロバイダが、ＭＮＯ１とのＰｒｏＳｅ協力に合意した別のＭＮＯ２であり得る場合、ＤＮＳシステムは、ｂｏｂ．ｐｒｏｓｅ．ｍｎｏ２．ｃｏｍについて問い合わされ得、応答は、上で説明されたように、処理され得る。
【０１９３】
実施形態によれば、代理ＰｒｏＳｅサーバは、関連するＵＥの３ＧＰＰ識別情報および機能を獲得し得た後、デバイス発見の手順もしくは方法、または他の手順もしくは方法などの動作を継続および開始し得る。
【０１９４】
本明細書では、ＵＥもしくはＷＴＲＵ、ユーザ、またはＵＥ／ユーザという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。
【０１９５】
加えて、本明細書で使用されるＰｒｏＳｅは、地理的および／もしくは物理的に近接するＵＥの発見、ならびに／またはそれらの間の情報交換を表す、Ｐｒｏｘｉｍｉｔｙサービスのことであり得る。同じ名前が、類似しているが必ずしも同じではない機能を表すために、３ＧＰＰによって使用されることがある。また、本明細書では、Ｄ２ＤおよびＰｒｏＳｅという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。例えば、Ｄ２ＤサーバはＰｒｏＳｅサーバを、もしくはＰｒｏＳｅサーバはＤ２Ｄサーバを表し得、および／または一方は他方の機能のサブセットを実施し得る。さらに、本明細書では、一時サービス名および一時識別子ＰｒｏＳｅという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。
【０１９６】
上では特徴および要素が特定の組み合わせで説明されたが、各特徴または要素は、単独で使用され得、または他の特徴および要素との任意の組み合わせで使用され得ることを当業者は理解されよう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施され得る。コンピュータ可読媒体の例は、（有線またはワイヤレス接続上で送信される）電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータのための無線周波数送受信機を実施するために使用され得る。
【図１Ａ】
2020054011.tif 000003
【図１Ｂ】
2020054011.tif 000004
【図１Ｃ】
2020054011.tif 000005
【図１Ｄ】
2020054011.tif 000006
【図１Ｅ】
2020054011.tif 000007
【図２】
2020054011.tif 000008
【図３】
2020054011.tif 000009
【図４】
2020054011.tif 000010
【図５】
2020054011.tif 000011
【図６】
2020054011.tif 000012
【図７】
2020054011.tif 000013
【図８】
2020054011.tif 000014
【図９】
2020054011.tif 000015
【図１０】
2020054011.tif 000016
【図１１】
2020054011.tif 000017
【図１２】
2020054011.tif 000018
【図１３】
2020054011.tif 000019
【図１４】
2020054011.tif 000020
【図１５】
2020054011.tif 000021
【手続補正書】
【提出日】令和2年2月5日(2020.2.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サービスと関連付けられた一時サービス名を受信することであって、前記一時サービス名は、複数の識別子を含む、ことと、
前記受信された一時サービス名がフィルタを満たすと判定することであって、前記フィルタは、関連するサービスを識別するように構成されている、ことと、
前記受信された一時サービス名が前記フィルタを満たすと判定すると、アプリケーションサーバに通知を通信することと、
を含む動作を実行するように構成されたコンピューティングプロセッサを備えたことを特徴とする無線送受信ユニット（ＷＴＲＵ）。
【請求項２】
前記受信された一時サービス名がフィルタを満たすと判定することは、前記受信された一時サービス名の一部が前記フィルタを満たすと判定することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項３】
前記受信された一時サービス名がフィルタを満たすと判定することは、前記複数の識別子のサブセットが前記フィルタを満たすと判定することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項４】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定することは、前記第１のレベルに対応する前記複数の識別子のうちの１つが前記フィルタを満たすと判定することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項５】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定することは、前記第１のレベルに対応する前記複数の識別子の１つ目および前記第２のレベルに対応する前記複数の識別子の２つ目が前記フィルタを満たすと判定することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項６】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定することは、前記第１のレベルに対応する前記複数の識別子の１つ目、前記第２のレベルに対応する前記複数の識別子の２つ目、および前記第３のレベルに対応する前記複数の識別子の３つ目が前記フィルタを満たすと判定することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項７】
アプリケーションサーバに通知を通信することは、前記一時サービス名と関連付けられた前記サービスに加入する要求を通信することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項８】
サービスと関連付けられた一時サービス名を受信することは、第２のＷＴＲＵから前記一時サービス名を受信することを含むことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項９】
前記コンピューティングプロセッサは、ポリシを受信することを含む動作を実行するように更に構成され、
前記受信された一時サービス名が前記フィルタを満たすと判定することは、前記受信された一時サービス名が前記ポリシを満たすと判定することを含む、
ことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項１０】
前記コンピューティングプロセッサは、前記ポリシについての要求を通信することを含む動作を実行するように更に構成されていることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１１】
サービス発見のための方法であって、
第１の無線送受信ユニット（ＷＴＲＵ）が、サービスと関連付けられた一時サービス名を受信するステップであって、前記一時サービス名は、複数の識別子を含む、ステップと、
前記第１のＷＴＲＵが、前記受信された一時サービス名がフィルタを満たすと判定するステップであって、前記フィルタは、関連するサービスを識別するように構成されている、ステップと、
前記第１のＷＴＲＵが、前記受信された一時サービス名が前記フィルタを満たすと判定すると、アプリケーションサーバに通知を通信するステップと、
を備えたことを特徴とする方法。
【請求項１２】
前記受信された一時サービス名がフィルタを満たすと判定するステップは、前記受信された一時サービス名の一部が前記フィルタを満たすと判定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記受信された一時サービス名がフィルタを満たすと判定するステップは、前記複数の識別子のサブセットが前記フィルタを満たすと判定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定するステップは、前記第１のレベルに対応する前記複数の識別子のうちの１つが前記フィルタを満たすと判定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１５】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定するステップは、前記第１のレベルに対応する前記複数の識別子の１つ目および前記第２のレベルに対応する前記複数の識別子の２つ目が前記フィルタを満たすと判定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１６】
前記複数の識別子の各々は、少なくとも第１のレベル、第２のレベル、および第３のレベルを含むレベルの階層におけるレベルに対応し、
前記受信された一時サービス名がフィルタを満たすと判定するステップは、前記第１のレベルに対応する前記複数の識別子の１つ目、前記第２のレベルに対応する前記複数の識別子の２つ目、および前記第３のレベルに対応する前記複数の識別子の３つ目が前記フィルタを満たすと判定するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１７】
アプリケーションサーバに通知を通信するステップは、前記一時サービス名と関連付けられた前記サービスに加入する要求を通信するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１８】
サービスと関連付けられた一時サービス名を受信するステップは、第２のＷＴＲＵから前記一時サービス名を受信するステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１９】
ポリシを受信するステップを更に備え、
前記受信された一時サービス名が前記フィルタを満たすと判定するステップは、前記受信された一時サービス名が前記ポリシを満たすと判定するステップを含む、
ことを特徴とする請求項１１に記載の方法。
【請求項２０】
前記ポリシについての要求を通信するステップを更に備えたことを特徴とする請求項１９に記載の方法。