JP2021503264A - 直接発見に対するアプリケーションの許可 - Google Patents

Abstract

直接発見のために、ユーザ装置（ＵＥ）内のアプリケーションを許可するためのシステム、方法、およびソフトウエア。一実施形態では、許可メカニズムは、ＵＥ内のアプリケーションによって送信された、発見要求に対する情報（例えば、アプリケーションＩＤ）を受信する。発見要求に応答して、許可メカニズムは、アプリケーションＩＤにマッピングされたセキュリティパラメータに関する情報をＵＥにチャレンジする。許可メカニズムは、ＵＥから提供された情報に基づいて、アプリケーションが直接発見に対して許可されているかどうかを決定する。

Description

本発明は、通信システムの分野に関するものであり、特に、近接サービス（ｐｒｏｘｉｍｉｔｙ ｓｅｒｖｉｃｅ）に対する直接発見（ｄｉｒｅｃｔ ｄｉｓｃｏｖｅｒｙ）に関するものである。

移動体通信は、主に、基地局と通信し、次にコアネットワークに接続される移動局（すなわち、ユーザ装置（ＵＥ））を伴う。制御プレーンとユーザプレーンのトラフィックは、コアネットワークを通してルーティングされた。近接サービスまたは近接ベースのサービスは、互いに近接しているＵＥ間で提供されるサービスを参照する。近接サービスは、ＵＥの無線技術を利用して、密接な近接のＵＥが、コアネットワークを通さずに直接的に互いに通信を交換できるようにし、これはデバイスツーデバイス（Ｄ２Ｄ）通信とも参照される。

第３世代パートナーシッププログラム（３ＧＰＰ）は、Ｄ２Ｄ通信をセルラネットワークの基礎として可能にする近接サービス（ＰｒｏＳｅ）を定義した。Ｄ２Ｄ通信では、ＵＥは、コアネットワークを通してデータ信号をルーティングする代わりに、セルラリソースを使用して直接リンク上で互いにデータ信号を伝送する。したがって、Ｄ２Ｄ通信は、進化型パケットコア（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）（ＥＰＣ）などのコアネットワーク上でトラフィックをルーティングする代わりに、互いに近くにあるＵＥ間で直接的にトラフィックを伝送することを伴う。密接な近接にあるＵＥ間に直接通信（ｄｉｒｅｃｔ ｃｏｍｍｕｎｉｃａｔｉｏｎ）があるため、Ｄ２Ｄ通信は追加のインフラストラクチャなしでＥＰＣネットワークからトラフィックをオフロードする。また、Ｄ２Ｄ通信は、より高いデータレート、より低い伝送遅延、ＵＥ内でのより良い電力効率を提供する可能性がある。

近接サービスは、一般に、発見、直接通信、およびＵＥ・ツー・ネットワークリレーを含む。発見は、互いに近接しているＵＥを識別するプロシージャである。直接通信は、近接のＵＥがローカル無線リソースを使用して通信できるプロシージャである。ＵＥ・ツー・ネットワークリレーは、ＵＥがリモートＵＥからネットワークへ、またはネットワークからリモートＵＥへトラフィックを中継できるプロシージャである。例えば、ＵＥ（リモートＵＥと参照される）がネットワークのための基地局のカバレッジエリアの外にある場合、ＵＥ・ツー・ネットワークリレープロシージャは、リモートＵＥが中継ＵＥとの直接通信を通して、基地局のカバレッジエリアにある中継ＵＥにトラフィックを伝送することを可能にする。次に、中継ＵＥは、ネットワークの基地局と通信することにより、トラフィックをリモートＵＥからネットワークに転送する。

３ＧＰＰは、発見プロシージャ中にＵＥを許可するためのいくつかのプロシージャを定義した。しかしながら、現在の許可プロシージャは、近接サービスを使用しようとする悪意のあるアプリケーションを検出するには不十分かもしれない。

本明細書に説明される実施形態は、直接発見を要求しているＵＥ上のアプリケーションを許可するためのメカニズムを提供する。ＵＥ上のアプリケーションがＰｒｏＳｅに対して発見要求を送信するとき、本明細書に説明される許可メカニズムは、アプリケーションが直接発見に対して許可されていることを保証するために、強化された発見許可プロシージャを提供する。近接サービスのアプリケーションはアプリケーション識別子（ＩＤ）で区別され、ネットワークオペレータはアプリケーションＩＤに対する１つ以上のセキュリティパラメータを定義できる。本明細書に説明される許可メカニズムは、発見要求で提供されたアプリケーションＩＤに対するセキュリティパラメータに関係する情報を要求するチャレンジメッセージを、ＵＥに送信し、ＵＥによって提供されたチャレンジメッセージへの返答に基づいて、アプリケーションが直接発見に対して許可されているかどうかをアプリケーションＩＤを使用して決定することができる。本明細書に説明される発見許可プロシージャは、有利には、悪意のあるアプリケーションがいつアプリケーションＩＤを偽装して、この悪意のあるアプリケーションからの発見要求が拒否される可能性があるかを決定することができる。

一実施形態は、ＰｒｏＳｅに対する発見許可プロシージャを実行する許可メカニズムを含む。許可メカニズムは、ＵＥ内のアプリケーションによって送信された発見要求に対する情報を受信するように構成された検証コントローラを含む。発見要求は、アプリケーションに対するアプリケーションＩＤを含む。許可メカニズムは、発見許可プロシージャに対する検証ルールを決定するように構成されたルールエンジンをさらに含む。検証コントローラは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥに送信し、セキュリティチャレンジメッセージに応答してＵＥからセキュリティ返答メッセージを受信し、ＵＥによって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出し、セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを、決定するように構成される。検証コントローラは、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているとき、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するように構成されている。

別の実施形態では、検証コントローラは、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するように構成される。

別の実施形態では、許可メカニズムは、セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースをさらに含む。アプリケーションＩＤにマッピングされたセキュリティパラメータは、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む。

別の実施形態では、検証コントローラは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別し、ＵＥによって提供されたチャレンジ値をアプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成される。

別の実施形態では、検証コントローラは、ＵＥに割り当てられたネットワークアドレスを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される。

別の実施形態では、検証コントローラは、公衆陸上移動体ネットワーク（ＰＬＭＮ）コードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される。

別の実施形態では、検証コントローラは、ＵＥのロケーションコードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される。

別の実施形態では、検証コントローラは、アプリケーションにアクセスするために使用されるパスコードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される。

別の実施形態では、許可メカニズムは、ＵＥから発見要求を受信するＰｒｏＳｅ機能において実施される。

別の実施形態では、許可メカニズムは、ＵＥから発見要求を受信するＰｒｏＳｅ機能に通信可能に結合されるＰｒｏＳｅアプリケーションサーバにおいて実施される。

別の実施形態は、ＰｒｏＳｅに対する発見許可プロシージャを実行する方法を含む。方法は、ＵＥ内のアプリケーションによって送信された発見要求に対する情報を受信するステップを含み、発見要求はアプリケーションに対するアプリケーションＩＤを含む。方法は、発見許可プロシージャに対する検証ルールを決定するステップと、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、許可メカニズムからＵＥに送信するステップと、セキュリティチャレンジメッセージに応答して、ＵＥからセキュリティ返答メッセージを受信するステップと、ＵＥによって提供されたセキュリティ返答メッセージからアプリケーションに対するセキュリティパラメータ値を抽出するステップと、セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するステップとを含む。方法は、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているときに、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するステップを含む。

別の実施形態では、方法は、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するステップをさらに含む。

別の実施形態では、方法は、セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースを記憶するステップを含む。アプリケーションＩＤにマッピングされたセキュリティパラメータは、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む。

別の実施形態では、直接発見に対してアプリケーションが許可されているかどうかを決定するステップは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別するステップと、ＵＥによって提供されたチャレンジ値をアプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するステップとを含む。

別の実施形態は、１つ以上のプロセッサによって実行されるプログラムされた命令を具現化する非一時的コンピュータ可読媒体を含み、命令は、プロセッサに、ＰｒｏＳｅに対する発見許可プロシージャを実行する許可メカニズムを実施するように指示する。許可メカニズムは、ＵＥ内のアプリケーションによって送信された発見要求のに対する情報を受信するように構成され、発見要求はアプリケーションに対するアプリケーションＩＤを含む。許可メカニズムは、発見許可プロシージャに対する検証ルールを決定し、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥに送信し、セキュリティチャレンジメッセージに応答して、ＵＥからセキュリティ返答メッセージを受信し、ＵＥによって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するセキュリティパラメータ値を抽出し、セキュリティパラメータに対するチャレンジ値および検証ルール基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成される。許可メカニズムは、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているときに、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するように構成されている。

別の実施形態では、許可メカニズムは、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するように構成される。

別の実施形態では、許可メカニズムは、セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースを記憶するように構成される。アプリケーションＩＤにマッピングされたセキュリティパラメータは、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む。

別の実施形態では、許可メカニズムは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別し、ＵＥによって提供されたチャレンジ値を、アプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成される。

別の実施形態では、許可メカニズムは、ＵＥから発見要求を受信するＰｒｏＳｅ機能において実施される。

別の実施形態では、許可メカニズムは、ＵＥから発見要求を受信するＰｒｏＳｅ機能に通信可能に結合されているＰｒｏＳｅアプリケーションサーバにおいて実施される。

別の実施形態は、ＰｒｏＳｅに対する発見許可プロシージャを実行する許可メカニズムを含む。許可メカニズムは、ＵＥ内のアプリケーションによって送信された発見要求に対する情報を受信する手段を含み、発見要求はアプリケーションに対するアプリケーションＩＤを含む。許可メカニズムは、発見許可プロシージャに対する検証ルールを決定する手段を含む。許可メカニズムは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥに送信する手段を含む。許可メカニズムは、セキュリティチャレンジメッセージに応答して、ＵＥからセキュリティ返答メッセージを受信する手段を含む。許可メカニズムは、ＵＥによって提供されるセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出する手段を含む。許可メカニズムは、セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定する手段を含む。許可メカニズムは、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているときに、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可する手段を含む。

上記の発明の概要は、明細書のいくつかの態様についての基本的な理解を提供する。この概要は、明細書の広範な発明の概要ではない。それは、明細書の主要な要素又は重要な要素を特定することも、明細書の特定の実施形態の範囲又はクレームの範囲を明示することも意図されていない。その唯一の目的は、後で提示されるより詳細な説明の前提として、明細書のいくつかの概念を簡略化された形式で提示することである。

本発明のいくつかの実施形態は、ここでは、例としてのみ、添付の図面を参照して説明される。同じ参照番号は、すべての図面で同じ要素または同じタイプの要素を表す。

ＰｒｏＳｅ機構のためのアーキテクチャを示す。 ＵＥに対するサービス事前構成プロシージャを示す。 ＵＥに対するサービス許可プロシージャを示す。 アナウンシングＵＥの発見要求プロシージャを示す。 モニタリングＵＥに対する発見要求プロシージャを示す。 例示的実施形態における近接サービスのためのアーキテクチャを示す。 例示的実施形態における許可メカニズムのブロック図である。 例示的実施形態におけるデータベースを示す。 例示的な実施形態における発見許可プロシージャの実行方法を示すフローチャートである。 例示的実施形態において、アプリケーションが直接発見を許可されているかどうかを決定する方法を示すフローチャートである。 例示的実施形態において、許可メカニズムがＰｒｏＳｅ機能において実施される場合のフロー図である。 例示的な実施形態において、許可メカニズムがＰｒｏＳｅアプリケーションサーバにおいて実施される場合のフロー図である。

図および以下の説明は、特定の例示的な実施形態を示す。したがって、当業者であれば、本明細書に明示的に説明または示されていないが、実施形態の原理を具現化し、実施形態の範囲内に含まれる様々な構成を考案することができることが理解されよう。さらに、本明細書に説明される任意の例は、実施形態の原理を理解するのに役立てることを意図されており、このような具体的に説明された例および条件に限定されないと解釈されるべきである。その結果、発明の概念は、以下に説明される特定の実施形態又は実施例に限定されるものではなく、クレーム及びそれらの同等の物によって制限される。

図１は、ＰｒｏＳｅ機構のためのアーキテクチャ１００を示す。アーキテクチャ１００は、３ＧＰＰ ＴＳ ２３．３０３（バージョン１５．０．０）に説明されているように、公衆陸上移動体ネットワーク（ＰＬＭＮ）における非ローミングシナリオを図示し、これは、本明細書に完全に含まれているかのように参照によって組み込まれる。アーキテクチャ１００は、無線アクセスネットワーク（ＲＡＮ）上でＵＥ１２０−１２１と通信する進化型パケットコア（ＥＰＣ）ネットワーク１１０を含み、無線アクセスネットワーク（ＲＡＮ）は、進化型ＵＭＴＳ地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）１１２として図示されている。図１には示されていないが、Ｅ−ＵＴＲＡＮ１１２は、ＵＥ１２０−１２１（および他のＵＥ）とＥＰＣネットワーク１１０との間にワイヤレス接続を提供する複数の基地局（たとえばｅＮｏｄｅＢ）を含む。ＥＰＣネットワーク１１０は、モビリティマネジメントエンティティ（ＭＭＥ）１１４、Ｓ−ＧＷ１１５、およびＰ−ＧＷ１１６を含む。アーキテクチャ１００はまた、ホーム加入者サーバ（ＨＳＳ）１１７およびセキュアユーザプレーンロケーションプラットフォーム（Ｓｅｃｕｒｅ Ｕｓｅｒ Ｐｌａｎｅ Ｌｏｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ）（ＳＬＰ）１１８を含む。ＨＳＳ１１７は、ＵＥ１２０−１２１のサブスクリプションを加入者プロファイルの形式で格納する。ＳＬＰ１１８は、ＵＥ１２０−１２１のロケーション情報を保持する。

アーキテクチャ１００は、近接サービス（ＰｒｏＳｅ）機能１３０およびＰｒｏＳｅアプリケーションサーバ（ＡＳ）１３２をさらに含む。ＰｒｏＳｅアプリケーションサーバ１３２は、ＥＰＣＰｒｏＳｅユーザーＩＤおよびＰｒｏＳｅ機能ＩＤの格納、およびアプリケーションレイヤーユーザーＩＤおよびＥＰＣＰｒｏＳｅユーザーＩＤのマッピングをサポートする。ＰｒｏＳｅ機能１３０は、ＰｒｏＳｅに必要なネットワーク関係のアクションに使用される論理機能である。ＰｒｏＳｅ機能１３０は、ＰｒｏＳｅの機構ごとに異なった役割を演じる。近接サービスをサポートするＰＬＭＮごとに１つのＰｒｏＳｅ機能１３０が存在する場合がある。ＰｒｏＳｅ機能１３０は、ＰｒｏＳｅ機構に応じてさまざまな役割を実行する３つの主なサブ機能を含む。１つのサブ機能は、直接発見と直接通信とを使用するためのパラメータでＵＥをプロビジョニングするために使用される、直接プロビジョニング機能（ＤＰＦ）である。ＤＰＦは、ＵＥがこの特定のＰＬＭＮで近接サービスの使用を可能にするＰＬＭＮ固有のパラメータを使用して、ＵＥをプロビジョニングする。別のサブ機能は、直接発見ネームマネジメント機能があり、これは、オープンな直接発見が、直接発見で使用されるアプリケーションＩＤとアプリケーションコードとを割り当てて処理するために使用される。このサブ機能は、アプリケーションＩＤとアプリケーションコードの間のマッピングをリストする表を保持する。さらに、このサブ機能は、ＵＥをモニタするためのフィルタを生成する。別のサブ機能はＥＰＣレベルの発見ＰｒｏＳｅ機能であり、これは、ＥＰＣレベルのＰｒｏＳｅ発見、および、ＥＰＣによりアシストされる無線ＬＡＮ直接発見と通信に対して、ＵＥを許可する、および構成する。ＨＳＳ１１７とＰｒｏＳｅ機能１３０の間の参照ポイント（ＰＣ４ａ）は、直接発見および直接通信のためのアクセスをＰＬＭＮごとベースで許可するために、サブスクリプション情報を提供するために使用される。

ＵＥ１２０−１２１はＰｒｏＳｅ使用可能、つまりＰｒｏＳｅ要求と関連プロシージャをサポートしていることを意味する、とみなすことができる。ＰｒｏＳｅ使用可能ＵＥは、非パブリックセーフティＵＥまたはパブリックセーフティＵＥを参照する場合がある。ＵＥ１２０−１２１は、それぞれ、近接サービスへのアクセス／提供に使用されるアプリケーション１２２−１２３を含む。ＵＥ１２０−１２１は以下の機能：ＰＣ３参照ポイント上の、ＵＥとＰｒｏＳｅ機能１３０の間のＰｒｏＳｅ制御情報の交換、ＰＣ５参照ポイント上の、他のＵＥのオープンな、および制限された直接発見のプロシージャ、ＰＣ５参照ポイント上の、１対１または１対多の直接通信のプロシージャ、およびＵＥ・ツー・ネットワークリレーとして作用するプロシージャの、機能をサポートしている。

ここで論じられる近接サービスは以下の機能：発見、直接通信（Ｄ２Ｄ）、およびＵＥ・ツー・ネットワークリレーの機能を含む。発見は、他のＵＥの近接にあるＵＥを識別する処理である。一つのタイプの発見は、直接発見であり、これは、ＵＥによって、その近傍にある他のＵＥを、２つのＵＥの能力のみを使用して発見するために採用される処理である。例えば、一つのＵＥは、その近傍にある他のＵＥの存在を発見するためにローカル無線リソースを使用することができる。別のタイプの発見はＥＰＣレベル発見と参照される処理であり、この処理によって、ＥＰＣネットワーク１１０が２つのＵＥの近接を決定し、それらの近接を通知する。例えば、ＥＰＣネットワーク１１０内のサーバは、ＵＥのロケーションをモニタし、それらの近接をＵＥに通知することができる。

直接通信は、いかなるネットワークノード（場合によってはＲＡＮの基地局以外）も横断しないチャンネルを介する無線技術（例えば、Ｅ−ＵＴＲＡ）を使用するユーザデータプレーン伝送による、近接内の２つ以上のＵＥ間の通信である。直接通信は、ＵＥが、ローカル無線リソースを使用して、ＥＰＣネットワーク１１０などのコアネットワークを通してトラフィックをルーティングすることなく、相互に直接通信することを可能にする。ＵＥは、ＲＡＮから、例えば基地局などから、両方のＵＥに利用可能な無線リソースを通して直接通信することができる。ＵＥは、例えばＰＣ５参照ポイント上でなど、ＵＥ自体の無線リソースを通して直接通信することもできる。どちらの方法でも、ＵＥ間で交換されるトラフィックはコアネットワークを通してルーティングされるのではなく、ワイヤレスインターフェース上でＵＥ間で直接的にルーティングされる。

ＵＥ・ツー・ネットワークリレーは、一つのＵＥが、一つ以上のリモートＵＥに対する「ユニキャスト」サービスへの接続性をサポートする機能を提供する機能である。リモートＵＥは、ＲＡＮ（例えば、Ｅ−ＵＴＲＡＮ）によってサーブされないＵＥを参照し、ＵＥ・ツー・ネットワークリレーを通してパケットデータネットワーク（ＰＤＮ）と通信する。たとえば、リモートＵＥがＲＡＮのカバレッジ外である場合、リモートＵＥは、ＲＡＮのカバレッジ内にある別のＵＥ（中継ＵＥ）を通して依然ＰＤＮにアクセスできる。中継ＵＥは、ＵＥ・ツー・ネットワークリレーのために使用可能なデバイスである。ＵＥ・ツー・ネットワークリレーは、カバレッジ内にある中継ＵＥを介してネットワークからリモートＵＥへ、またはカバレッジ内にある中継ＵＥを介してリモートＵＥからネットワークへの１対１または１対多の通信を可能にする。

図２は、ＵＥ１２０に対するサービス事前構成プロシージャを示す。ホームＰＬＭＮ（ＨＰＬＭＮ）は、ＵＥ１２０が直接発見、直接通信、またはその両方を実行することが許可されているＰＬＭＮのリストに対して、ＵＥ１２０を許可情報で事前構成する。関連するＵＥコンテキストが存在しない場合、ＰｒｏＳｅ機能１３０は、ＨＳＳ１１７から直接発見および／または直接通信に対するサブスクリプション情報を取得する。

近接サービスにアクセスするためには、ＵＥ１２０−１２１（すなわち、非パブリックセーフティＵＥ）は、まず、サービスに対して許可され、構成されなければならない。図３は、ＵＥ１２０に対するサービス許可プロシージャを示す。ＵＥ１２０は、そのＨＰＬＭＮのＰｒｏＳｅ機能１３０から、所与の有効期間と共に、直接発見、直接通信、またはその両方に対するサービス許可を受信する。ＵＥ１２０は、ＵＥ１２０が有効な許可情報を持たないとき、ＵＥがすでに直接発見または直接通信に従事しているが、その登録されたＰＬＭＮを変更したとき、または前の許可が満了したとき、直接発見または直接通信のセットアップを開始する前に、このサービス許可プロシージャを実行する。ＵＥ１２０は、そのＨＰＬＭＮのＰｒｏＳｅ機能１３０を識別するために、ドメインネームサービス（ＤＮＳ）機能（図示せず）と相互作用して、ＰｒｏＳｅ機能１３０を発見することができ、または、ＰｒｏＳｅ機能１３０に対する情報がＵＥ１２０に予めプロビジョニングされていてよい。ＵＥ１２０は、直接発見、直接通信、またはその両方に対する許可要求を、そのＨＰＬＭＮ内のＰｒｏＳｅ機能１３０に伝送する。ＰｒｏＳｅ機能１３０がＵＥ１２０に対するこの情報をまだ有していないと仮定すると、許可要求に応答して、ＰｒｏＳｅ機能１３０は、ＵＥ１２０に関連するサブスクリプション情報（例えば、加入者プロファイル）に対する要求を、ＨＳＳ１１７に伝送する。ＨＳＳ１１７は、近接サービスに関係するＵＥ１２０のサブスクリプション情報（例えば、直接発見および／または直接通信）を識別し、サブスクリプション情報と共にＰｒｏＳｅ機能１３０へ応答を伝送する。次に、ＰｒｏＳｅ機能１３０は、近接サービスの許可情報と共に、ＵＥ１２０へ、許可応答を送信し、これはＵＥ１２０によって格納される。ＵＥ１２０は、ＰｒｏＳｅ機能１３０によって許可されたＰＬＭＮを使用して、直接発見および／または直接通信を実行することができる。

許可とプロビジョニングの後、ＵＥ１２０−１２１は発見要求をＥＰＣネットワーク１１０に送信することがあり、これはＰｒｏＳｅ機能１３０によって処理される。直接発見には、２つのタイプの発見：オープンな、および、制限された、が定義されている。オープンな発見（ｏｐｅｎ ｄｉｓｃｏｖｅｒｙ）においては、発見されるＵＥから明示的なパーミッションが必要とされない。制限された発見（ｒｅｓｔｒｉｃｔｅｄ ｄｉｓｃｏｖｅｒｙ）においては、発見されるＵＥから明示的なパーミッションが必要とされる。３ＧＰＰはまた、２つの可能な直接発見モード：モデルＡとモデルＢを定義した。モデルＡ（「私はここにいる」（“Ｉ ａｍ ｈｅｒｅ”））は、直接発見に参加しているＵＥに対する２つの役割を定義する。１つの役割は、アナウンシングＵＥ（ａｎｎｏｕｎｃｉｎｇ ＵＥ）であり、これは、発見するパーミッションを有する近接のＵＥによって使用され得る特定の情報をアナウンスする。もう一つの役割は、モニタリングＵＥ（ｍｏｎｉｔｏｒｉｎｇ ＵＥ）であり、これはアナウンシングＵＥの近接における関心のある特定の情報をモニタする。このモデルでは、アナウンシングＵＥは、事前定義された発見インターバルで発見メッセージをブロードキャストし、これらのメッセージに関心のあるモニタリングＵＥは、それらを読んで処理する。

モデルＢ（「誰がそこにいるのか／あなたはそこにいるのか」“Ｗｈｏ ｉｓ ｔｈｅｒｅ？”／“Ａｒｅ ｙｏｕ ｔｈｅｒｅ？”）は、制限された発見のタイプが使用されるときに使用され、直接発見に参加しているＵＥの２つの役割を定義する。一つの役割は、発見側ＵＥ（ｄｉｓｃｏｖｅｒｅｒ ＵＥ）であり、これは、それが発見することに関心がある特定の情報を収容する要求を送信する。もう１つの役割は被発見側ＵＥ（ｄｉｓｃｏｖｅｒｅｅ ＵＥ）で、これは、発見側の要求に関係する情報で応答できる。

図４は、アナウンシングＵＥ１２０（非ローミング、オープンな発見）の発見要求プロシージャを示す。ＵＥ１２０は、そのＨＰＬＭＮに対応するアプリケーションＩＤのデータ構造で構成される。ＵＥ１２０がそのＨＰＬＭＮにおいてアナウンスすることを許可されている場合、ＵＥ１２０は、発見要求をＰｒｏＳｅ機能１３０に送信する。発見要求は、ＰｒｏＳｅアプリケーションＩＤ、ＵＥ識別、アナウンスコマンド、アプリケーションＩＤ、発見エントリＩＤ、［要求されたタイマ］、［アプリケーションレベルコンテナ］、および［ＰＣ５＿ｔｅｃｈ］を含む。ＰｒｏＳｅアプリケーションＩＤは、ＵＥが何のアナウンスに関心をもっているかを示す。ＵＥ識別は、国際移動体加入者識別番号（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）（ＩＭＳＩ）に設定される。アプリケーションＩＤは、発見要求の伝送をトリガしたＵＥアプリケーションの一意の識別子を表す。発見エントリＩＤは、これが新しい要求であるかどうかを示す。要求されたタイマは任意選択のパラメータであり、ＵＥがＰｒｏＳｅ機能１３０から受信することを期待するＰｒｏＳｅアプリケーションコードに関連する有効性タイマの長さを示す。ＰＣ５＿ｔｅｃｈは、ＵＥ１２０がアナウンスメントのために使用したいＰＣ５無線テクノロジ（Ｅ−ＵＴＲＡ、ＷＬＡＮなど）を示す任意選択のパラメータである。ＰｒｏＳｅ機能１３０は、アプリケーションＩＤで表されるアプリケーションの許可をチェックする。関連するＵＥコンテキストがない場合、ＰｒｏＳｅ機能１３０は、発見に対するＵＥ１２０の許可に関してＨＳＳ１１７とチェックし、ＵＥ１２０に対するサブスクリプションパラメータを収容する、ＵＥ１２０に対する新しいコンテキストを作成する。

ＵＥ１２０が、アプリケーションレベルコンテナを含めることによるアプリケーションにより制御された拡張（ａｐｐｌｉｃａｔｉｏｎ−ｃｏｎｔｒｏｌｌｅｄ ｅｘｔｅｎｓｉｏｎ）を望むことを示した場合、ＰｒｏＳｅ機能１３０は、許可要求（ＰｒｏＳｅアプリケーションＩＤ、要求タイプ、アプリケーションレベルコンテナ、可能にされたサフィックスの数）をＰｒｏＳｅアプリケーションサーバ１３２に送信する。要求タイプは「アプリケーションにより制御された拡張でのオープンな発見／アナウンス」に設定される。可能にされたサフィックスの数は、ＰｒｏＳｅアプリケーションサーバ１３２がＵＥ１２０に割り当てることができるＰｒｏＳｅ制限コードサフィックスの数を示す。ＰｒｏＳｅ機能１３０は、アプリケーションＩＤに基づいてＰｒｏＳｅアプリケーションサーバ１３２のロケーションを特定する。ＰｒｏＳｅアプリケーションサーバ１３２は、「アプリケーションにより制御された拡張でのオープンな発見／アナウンス ａｃｋ」に設定された応答タイプで、ＰｒｏＳｅ機能１３０に許可応答（応答タイプ、ＰｒｏＳｅアプリケーションコードサフィックスプール）を返す。ＰｒｏＳｅアプリケーションコードサフィックスプールは、ＰｒｏＳｅアプリケーションサーバ１３２によって割り当てられたサフィックスを収容する。

発見要求が許可された場合、ＰｒｏＳｅ機能１３０は、ＵＥ１２０が、発見要求に収容されるＰｒｏＳｅアプリケーションＩＤ（例えば、ＵＥ１２０がアナウンスを許可されている）を使用することが許可されているかどうかをチェックする。ＵＥ１２０がＰｒｏＳｅアプリケーションＩＤを使用することを許可されている場合、ＰｒｏＳｅ機能１３０は、発見応答でＵＥ１２０に応答する。発見応答は、ＰｒｏＳｅアプリケーションコード、有効性タイマ、発見エントリＩＤ、および［ＰＣ５＿ｔｅｃｈ］を含み、ＰｒｏＳｅアプリケーションコードは、ＰｒｏＳｅ機能１３０によって提供され、発見要求に収容されていたＰｒｏＳｅアプリケーションＩＤに対応する（つまり、ＰＬＭＮＩＤとアプリケーションＩＤに対する一時的ＩＤから成る）。有効性タイマは、このＰｒｏＳｅアプリケーションコードが有効な期間はどれくらいかを示す。ＰｒｏＳｅ機能１３０は、有効性タイマを割り当てるとき、要求されたタイマパラメータを、ＵＥ１２０によって提供された場合、考慮に入れる。ＵＥ１２０は、有効性タイマの期間、およびＨＰＬＭＮに残っている場合、このＰｒｏＳｅアプリケーションコードをアナウンスすることを許可される。有効性タイマが期限切れになるか、またはＵＥ１２０が登録されたＰＬＭＮを変更すると、ＵＥ１２０は新しいＰｒｏＳｅアプリケーションコードを要求する。任意選択のＰＣ５＿ｔｅｃｈパラメータは、割り当てられたＰｒｏＳｅアプリケーションコードに使用されることが許可されているＰＣ５無線テクノロジを示す。ＵＥ１２０は、発見応答を受信した後、発見メッセージおよびＰｒｏＳｅアプリケーションコードを用いてＰＣ５上でアナウンスするように構成される。

図５は、モニタリングＵＥ１２１（非ローミング、オープンな発見）に対する発見要求プロシージャを示す。ＵＥ１２１は、そのＰＬＭＮに対応するＰｒｏＳｅアプリケーションＩＤのデータ構造で構成される。ＵＥ１２１が少なくとも１つのＰＬＭＮにおいてモニタすることを許可される場合、ＵＥ１２１は、発見要求をＰｒｏＳｅ機能１３０に送信する。モニタリングＵＥからの発見要求は、コマンドが「モニタ」に設定されることを除いて、上で説明されたような同様の情報を含むことができる。ＰｒｏＳｅアプリケーションＩＤは、ＵＥ１２１が、何をモニタリングすることに関心があるかを示し、ＰＬＭＮのデータ構造のサブセットから成る。アプリケーションＩＤは、発見要求メッセージの伝送をトリガしたアプリケーションの一意の識別子を表す。ＰｒｏＳｅ機能１３０は、アプリケーションＩＤで表されるアプリケーションの許可をチェックする。関連するＵＥコンテキストがない場合、ＰｒｏＳｅ機能１３０は、発見に対するＵＥ１２１の許可に関してＨＳＳ１１７とチェックし、ＵＥ１２０に対するサブスクリプションパラメータを収容する、ＵＥ１２１に対する新しいコンテキストを作成する。

ＵＥ１２１が、アプリケーションレベルコンテナを含めることによるアプリケーションにより制御された拡張を望むことを示した場合、ＰｒｏＳｅ機能１３０は、アプリケーションＩＤによって示されるＰｒｏＳｅアプリケーションサーバ１３２に許可要求（ＰｒｏＳｅアプリケーションＩＤ、要求タイプ、アプリケーションレベルコンテナ）を送信する。要求タイプは、「アプリケーションにより制御された拡張でのオープンな発見／モニタ」に設定される。ＰｒｏＳｅアプリケーションサーバ１３２は、「アプリケーションにより制御された拡張でのオープンな発見／モニタ ａｃｋ」に設定された応答タイプで、ＰｒｏＳｅ機能１３０に許可応答（応答タイプ、ＰｒｏＳｅアプリケーションＩＤに対応するＰｒｏＳｅアプリケーションコードサフィックスのためのマスク）を返す。

発見要求が許可されると、ＰｒｏＳｅ機能１３０は発見応答でＵＥ１２１に応答する。発見応答は、発見フィルター、発見エントリＩＤ、および［ＰＣ５＿ｔｅｃｈ］を含む。発見フィルターの生存時間（ＴＴＬ）は、発見フィルターが有効な期間はどれくらいかを示す。アプリケーションにより制御された拡張が使用されている場合、発見フィルターのＰｒｏＳｅアプリケーションコードはＰｒｏＳｅアプリケーションコードプレフィックスに置き換えられる。ＰｒｏＳｅアプリケーションコードに加えて、発見フィルターは、ＰｒｏＳｅアプリケーションコードサーバ１３２から取得されたＰｒｏＳｅサフィックスのためのマスクを収容する場合がある。ＵＥ１２１は、サフィックス部分のための追加のマスクおよび値を加えることができる。ＵＥ１２１は、発見応答を受信した後、ＰＣ５上で、ＰｒｏＳｅのために使用されるＰＬＭＮによって許可され、構成された無線リソース内の発見フィルターを使用して、アプリケーションコードをモニタするように構成される。発見フィルタに対応するＴＴＬが期限切れになった場合（ＵＥ１２１がＴＴＬの期間内に対応する発見要求をリフレッシュしていないため）、ＰｒｏＳｅ機能１３０は、その発見フィルタに関係するエントリをＵＥコンテキストから除去する。

制限された発見、ローミング、モデルＢなどの他の発見プロシージャは、３ＧＰＰＰ ＴＳ２３．３０３に説明されている。

上記の発見プロシージャで明らかなように、ＰｒｏＳｅ機能１３０は、ＨＳＳ１１７に問い合わせることによって、端末のあるタイプの許可を実行する。ＨＳＳ１１７はＵＥに対するサブスクリプションパラメータで応答し、ＰｒｏＳｅ機能１３０はこのアプリケーションが発見を許可されているかどうかを決定する。しかし、１つの課題は、ＵＥや他のデバイスが発見要求内のアプリケーションＩＤを偽装できることである。ＨＳＳ１１７内の加入者プロファイルは、ＰｒｏＳｅに対して許可されたＵＥ内に存在するすべてのＰｒｏＳｅアプリケーションを示すとは限らない。したがって、ＵＥが加入者プロファイルに従ってＰｒｏＳｅに対して許可されていても、１つ以上のアプリケーションがこのＵＥによって悪意を持って使用される可能性がある。偽装されたアプリケーションＩＤから保護するには、ＨＳＳ１１７を使用する許可プロシージャでは不十分である。

この問題および他の関連する問題を解決するために、許可メカニズムが採用されて、ＰｒｏＳｅなどの近接サービスの偽装アプリケーションＩＤを検出する。ここで「ＰｒｏＳｅ」という用語を使用する場合、３ＧＰＰまたは他の近接サービスによって説明されている近接サービスを参照する場合がある。図６は、例示的実施形態における近接サービスのためのアーキテクチャ６００を示す。アーキテクチャ６００は、図１に示すアーキテクチャ１００と同様の要素および参照ポイントを有することができる。アーキテクチャ６００は、４Ｇ（例えば、ＬＴＥ）または次世代ネットワーク（例えば、５Ｇ）のために実施されてもよい。

アーキテクチャ６００は、非ローミングシナリオのためにＰＬＭＮ６１０を含むが、ローミングまたはＰＬＭＮ間アーキテクチャのためにより多くのＰＬＭＮが含まれてもよい。ＰＬＭＮ６１０は、ＵＥ６２０のホームＰＬＭＮであり、互いに通信可能に結合されたＰｒｏＳｅ機能６１２、ＰｒｏＳｅアプリケーションサーバ６１４、およびＨＳＳ６１６を含む。図６には示されていないが、ＰＬＭＮ６１０は、コアネットワークと、１つ以上の基地局（例えばｅＮｏｄｅＢ）を含むＲＡＮとを含んでもよい。ＵＥ６２０は、近接サービスに対して使用可能な非パブリックセーフティＵＥであり、直接発見および／または直接通信を要求するように構成された近接サービス（例えば、ＰｒｏＳｅ）アプリケーション６２２を含む。

ＰＬＭＮ６１０はまた、許可メカニズム６３０を含む。許可メカニズム６３０は、直接発見に対してＵＥ上のアプリケーションを許可するように構成されたシステム、装置、デバイス、ネットワーク要素などを含む。許可メカニズム６３０は、発見要求を開始したアプリケーションが直接発見を許可されていることを確認するために、発見要求に応答して、拡張されたまたは追加の許可プロシージャを提供する。前述したように、従来のＰｒｏＳｅ機能は、ＨＳＳに問い合わせることによって、発見要求に応答して何らかの発見許可プロシージャを実行する。ただし、アプリケーションが、アプリケーションのアプリケーションＩＤを悪意を持って偽装するときは、これらの発見許可プロシージャでは不十分なことがある。したがって、許可メカニズム６３０は、ＵＥにチャレンジすることによって強化されたまたは追加の許可プロシージャを提供するが、これは以下でさらに詳しく説明される。

許可メカニズム６３０は、ＰＬＭＮ６１０の要素として図６に概略的に示されている。許可メカニズム６３０は、ＰＬＭＮ６１０内のシステムの一部であるので、ＵＥ６２０、ＰｒｏＳｅ機能６１２、ＰｒｏＳｅアプリケーションサーバ６１４、および／またはＨＳＳ６１６と通信することができるＰＬＭＮ６１０内のスタンドアロン要素であってもよい。代替として、許可メカニズム６３０はＰｒｏＳｅ機能６１２において実施されてもよい。別の代替例では、許可メカニズム６３０は、ＰｒｏＳｅアプリケーションサーバ６１４において実施されてもよい。

図７は、例示的実施形態における許可メカニズム６３０のブロック図である。許可メカニズム６３０は、インターフェースコンポーネント７０２、１つ以上のプロセッサ７０４、およびメモリ７０６を含む。インターフェースコンポーネント７０２は、様々な要素と通信するように構成されたハードウエアコンポーネントである。例えば、インターフェースコンポーネント７０２は、ＵＥ６２０、ＰｒｏＳｅ機能６１２、ＰｒｏＳｅアプリケーションサーバ６１４、および／またはＨＳＳ６１６と通信するように構成されてもよい。プロセッサ７０４は、許可メカニズム６３０の機能を提供する内部回路、ロジック、ハードウエア等を表す。メモリ７０６は、データ、命令、アプリケーション等のためのコンピュータ可読記憶媒体（例えば、ＲＯＭまたはフラッシュメモリ）であり、プロセッサ７０４によってアクセス可能である。許可メカニズム６３０は、図７に具体的に図示されていない他の様々なコンポーネントを含んでもよい。

プロセッサ７０４は、ルールエンジン７１０および検証コントローラ７１２を実施する。ルールエンジン７１０は、アプリケーションが直接発見に対して許可されているかどうかを決定するために使用される検証ルール７１４を生成、識別、または決定するように構成される。検証コントローラ７１２は、検証ルール７１４に基づいて、アプリケーションが直接発見に対して許可されているかどうかを決定するように構成される。プロセッサ７０４は、直接発見に対してアプリケーションを許可するための他のコンポーネントを実装することができる。

この実施形態では、メモリ７０６は、アプリケーションＩＤにマッピングされたセキュリティパラメータでプロビジョニングされたデ−タベ−ス７２０を記憶するように構成される。データベース７２０は、許可メカニズム６３０のためのローカルデータベースを備えてもよく、またはインターフェースコンポーネント７０２を通してなど、許可メカニズム６３０によってアクセス可能なネットワークデータベースを備えてもよい。図８は、例示的実施形態におけるデータベース７２０を示す。データベース７２０は、アプリケーションＩＤ８１１−８１３のためのレコード８０１−８０３を格納するが、より多くのアプリケーションＩＤのためのレコードが格納されてもよい。それぞれのレコード８０１−８０３は、１つ以上のセキュリティパラメータ８２０の組にアプリケーションＩＤ８１１−８１３をマッピングする。セキュリティパラメータは、ＵＥまたはアプリケーションを検証または認証する特性またはプロパティーを含む。セキュリティパラメータ８２０は、その関連するアプリケーションＩＤ８１１−８１３について許可される１つ以上の値（例えば、コード、ラベル、数量など）を含む。たとえば、レコード８０１はアプリケーションＩＤ８１１にプロビジョニングされ、アプリケーションＩＤ８１１はセキュリティパラメータ８２０にマッピングされている。セキュリティパラメータ８２０は、ＵＥ識別、ネットワークアドレス、ＰＬＭＮコード、ロケーションコード、パスコード、ＵＥカテゴリタイプ、および発見タイプを含むが、他のセキュリティパラメータを含んでもよい。それぞれのセキュリティパラメータは、アプリケーションＩＤ８１１用にプロビジョニングされた１つ以上の許可された値を含む。例えば、ＵＥ識別パラメータは、１つ以上のＩＭＳＩのような、アプリケーションＩＤ８１１に対する承認されたＵＥ識別（または範囲）を示す１つ以上の値を含む。ネットワークアドレスパラメータは、１つ以上のトランスポート層（例えば、ＩＰ）アドレスのような、アプリケーションＩＤ８１１に対する承認されたネットワークアドレスを示す１つ以上の値を含む。ＰＬＭＮコードパラメータは、アプリケーションＩＤ８１１の承認されたＰＬＭＮコードを示す１つ以上の値を含む。ロケーションコードパラメータは、アプリケーションＩＤ８１１に対する承認されたロケーションコードを示す一つ以上の値を含む。パスコードパラメータは、アプリケーションへのアクセスに使用されるアプリケーションＩＤ８１１の承認されたパスコードまたはパスワードを示す１つ以上の値を含む。ＵＥカテゴリタイプパラメータは、ＣＡＴ１−ＣＡＴ８、ＬＴＥＣａｔ−Ｍ１（ｅＭＴＣ）、Ｃａｔ−ＮＢ１（ＮＢ−ＩｏＴ）などの、アプリケーションＩＤ８１１に対する承認されたＵＥカテゴリタイプを示す１つ以上の値を含む。発見タイプパラメータは、モデルＡ（オープンな、または制限された）、モデルＡのためのアナウンス役割、モデルＡのためのモニタ役割、モデルＢ、モデルＢのための発見タイプ／モード等、アプリケーションＩＤ８１１の承認された発見タイプを示す１つまたは複数の値を含む。必要に応じて、追加のセキュリティパラメータと関連する値をプロビジョニングすることができる。

図６において、ＵＥ６２０は、図２に示すようなサービス事前構成プロシージャと、図３に示すようなサービス許可プロシージャとを実行してもよい。この時点で、ＵＥ６２０内のアプリケーション６２２は、発見要求プロシージャを開始したい場合がある。したがって、アプリケーション６２２は、発見要求をＰｒｏＳｅ機能６１２に送信する（図４−５参照）。発見要求は、ＰｒｏＳｅアプリケーションＩＤ、ＵＥ識別、コマンド、アプリケーションＩＤ、発見エントリＩＤ、［要求されたタイマ］、［アプリケーションレベルコンテナ］、および［ＰＣ５＿ｔｅｃｈ］のような、上で説明されたような類似の情報を含むことができる。次に、許可メカニズム６３０は、図９にさらに詳述されるように、発見許可プロシージャを実行する。

図９は、例示的実施形態における発見許可プロシージャを実行する方法９００を示すフローチャートである。方法９００のステップは、図７の許可メカニズム６３０を参照して説明されるが、当業者であれば、他のデバイスで方法９００が実行されてもよいことが理解されるであろう。ここに説明されるフローチャートのステップはすべてを包含するものではなく、図示されていない他のステップを含んでもよく、ステップは代替の順序で実行されてもよい。

検証コントローラ７１２は、インターフェースコンポーネント７０２などを通して、ＵＥ６２０内のアプリケーション６２２によってＰｒｏＳｅ機能６１２に送信された発見要求に対する情報を受信する（ステップ９０２）。許可メカニズム６３０がＰｒｏＳｅ機能６１２において実施される場合、検証コントローラ７１２は、アプリケーション６２２によって送信された実際の発見要求を受信する可能性がある。許可メカニズム６３０がスタンドアロン要素であるか、またはＰｒｏＳｅアプリケーションサーバ６１４において実施されてる場合、検証コントローラ７１２は、許可要求など、ＰｒｏＳｅ機能６１２から発見要求に対する情報を受信してもよい。発見要求に対する情報は、少なくともアプリケーション６２２のアプリケーションＩＤを含む。

ルールエンジン７１０は、発見許可プロシージャに対する検証ルール７１４を決定する（ステップ９０４）。検証ルール７１４は、発見要求を開始するＵＥ上のアプリケーションを検証する任意のルールを含む。検証ルール７１４は、ネットワークアドレスチェックを含むことができる。このルールは、ＵＥに割り当てられたダイナミックネットワークアドレス（例えば、ＩＰアドレス）を、アプリケーションＩＤに対して承認されている（ホワイトリスト）または承認されていない（ブラックリスト）ネットワークアドレスの範囲と比較してもよい。検証ルール７１４はＰＬＭＮコードチェックを含むことができ、これは、アプリケーションによる直接発見がＰＬＭＮ（ＵＥがアタッチされている）において可能か否かを検証する。検証ルール７１４は、アプリケーション／ＵＥによって提供されたパスコード（またはパスワード）がアプリケーションの承認されたパスコードとマッチするかどうかを検証するアプリケーションパスコードチェックを含むことができる。検証ルール７１４は、ネットワーク（ＰＬＭＮ）センシティビティチェックを含むことができる。このルールは、一部のネットワークがアプリケーションの直接発見を制限される可能性があるため、アナウンシングＵＥからのアプリケーションＩＤがセキュアなネットワーク（ホームまたはフォーリン）に属しているかどうかを検証する。検証ルール７１４は、ネットワークトラフィック量チェックを含んでもよい。このルールは、悪意のあるアプリケーションが著しいトラフィック量を生成する可能性があるため、アプリケーションＩＤに関連するトラフィック量（すなわち、特定の送信機およびトランシーバエンティティアドレスのいずれかまたは両方）がしきい値を超えるかどうかを決定する。しきい値が超えられると、アプリケーションの発見要求が拒否される場合がある。トラフィック量がしきい値を下回っている場合は、発見要求が許可される場合がある。検証ルール７１４は、ＣＡＴ１−ＣＡＴ８、ＬＴＥＣａｔ−Ｍ１（ｅＭＴＣ）、Ｃａｔ−ＮＢ１（ＮＢ−ＩｏＴ）などのＵＥカテゴリタイプがアプリケーションに対して許可されているかどうかを検証するＵＥカテゴリタイプチェックを含むことができる。検証ルール７１４は、ＰｒｏＳｅ発見タイプチェックを含むことができ、これは、アプリケーションが、特定の発見タイプ、例えば、モデルＡ（オープンな、または制限された）、モデルＡのためのアナウンス役割、モデルＡのためのモニタ役割、モデルＢ、モデルＢ発見タイプ／モード等について可能とされるか否かを検証する。検証ルール７１４は、ＵＥのロケーションチェックを含み、これは、ＵＥのロケーションコードがアプリケーションＩＤの承認されたロケーションコードとマッチするかどうかを検証する。検証ルール７１４は、時刻、曜日などに基づいて発見要求が可能とされるかどうかを検証する時刻チェックを含むことができる。他の検証ルール７１４は、所望により定義することができる。

発見許可プロシージャのために、検証コントローラ７１２は、インターフェースコンポーネント７０２などを通して、アプリケーションＩＤにマッピングされた１つまたは複数のセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥ６２０に送信する（ステップ９０６）。ＵＥ６２０は、セキュリティのために使用され得る情報を格納することができ、セキュリティチャレンジメッセージは、ＵＥ６２０がこの情報で応答することを要求することができる。セキュリティチャレンジメッセージは、アプリケーション６２２が発見要求をＰｒｏＳｅ機能６１２に送信した後、ＵＥ６２０に送信される別個のメッセージである。セキュリティチャレンジメッセージは、図８に示すように、アプリケーションＩＤにマッピングされた１つ以上のセキュリティパラメータに対するチャレンジ値を要求してもよい。例えば、セキュリティチャレンジメッセージは、ＵＥ６２０に静的または動的に割り当てられるネットワークアドレス、ＵＥ６２０に対するＨＰＬＭＮに対するＰＬＭＮコード、またはＵＥ６２０がアタッチされている訪問／ローカルＰＬＭＮ、ＵＥ６２０に対するロケーションコード、アプリケーション６２２にアクセスするために使用されるパスコード、ＵＥ６２０に対するＵＥカテゴリタイプなどのチャレンジ値を要求することができる。

検証コントローラ７１２がＵＥ６２０からセキュリティ返答メッセージを受信しない場合、検証コントローラ７１２は、拒否インディケータを生成して、アプリケーション６２２によって送信された発見要求を拒否する（ステップ９０８）。検証コントローラ７１２が、インターフェースコンポーネント７０２などを通してＵＥ６２０からセキュリティ返答メッセージを受信した場合、検証コントローラ７１２は、ＵＥ６２０によって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出する（ステップ９１０）。検証コントローラ７１２はまた、発見要求から、ＨＳＳ６１６または他のネットワークのエンティティから、セキュリティパラメータの値を獲得することができる。次に、検証コントローラ７１２は、セキュリティパラメータおよび検証ルール７１４のチャレンジ値（および任意選択で他の値）に基づいて、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されているかどうかを決定する（ステップ９１２）。アプリケーション６２２が許可されているかどうかを決定する１つの方法（例えば、方法９００のステップ９１２）は、図１０に提供される。

図１０は、例示的実施形態において、アプリケーション６２２が直接発見を許可されているかどうかを決定する方法１０００を示すフローチャートである。検証コントローラ７１２は、データベース７２０にアクセスして、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別する（ステップ１００２）。次に、検証コントローラ７１２は、ＵＥ６２０によって提供されたチャレンジ値をアプリケーションＩＤに対する許可された値と比較して、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されているかどうかを決定する（ステップ１００４）。例えば、ＵＥ６２０によって提供されたチャレンジ値のいずれも、アプリケーションＩＤのための許可された値とマッチしない場合、検証コントローラ７１２は、アプリケーション６２２は、アプリケーションＩＤを使用する直接発見に対して許可されていないと決定する（ステップ１００６）。ＵＥ６２０によって提供される１つ以上のチャレンジ値が、アプリケーションＩＤに対する許可された値とマッチするとき、検証コントローラ７１２は、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていることを決定してもよい（ステップ１００８）。チャレンジ値と、アプリケーション６２２を許可するために要求される許可された値との間のマッチの数は、ネットワークオペレータによってプロビジョニングされるネットワークポリシーに依存する可能性がある。

方法１０００の一例として、検証ルール７１４の１つは、ネットワークアドレスチェックであってもよく、ここで、検証コントローラ７１２は、セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたネットワークアドレスを、アプリケーションＩＤに対する１つ以上の承認されたネットワークアドレスと比較する。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたネットワークアドレスが、アプリケーションＩＤに対する承認されたネットワークアドレスとマッチしない場合、検証コントローラ７１２は、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていないと決定してもよい。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されるネットワークアドレスが、アプリケーションＩＤに対する承認されたネットワークアドレスとマッチする場合、検証コントローラ７１２は、（適用可能な場合には）他の検証ルール７１４に応じて、アプリケーション６２２がアプリケーションＩＤを使用する直接発見について許可されていると決定してもよい。

検証ルール７１４の別の１つは、パスコードチェックであってもよく、ここで、検証コントローラ７１２は、セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたパスコードを、アプリケーションＩＤに対する１つ以上の承認されたパスコードと比較する。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたパスコードが、アプリケーションＩＤに対する承認されたパスコードとマッチしない場合、検証コントローラ７１２は、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていないと決定してもよい。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたパスコードがアプリケーションＩＤに対する承認されたパスコードとマッチする場合、検証コントローラ７１２は、（適用可能な場合には）他の検証ルール７１４に応じて、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていると決定してもよい。

検証ルール７１４の別の１つは、ロケーションコードチェックであってもよく、ここで、検証コントローラ７１２は、セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されるロケーションコードを、アプリケーションＩＤに対する１つ以上の承認されたロケーションコードと比較する。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されたロケーションコードが、アプリケーションＩＤの承認されたロケーションコードとマッチしない場合、検証コントローラ７１２は、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていないと決定してもよい。たとえば、アプリケーションＩＤがブラジルの国コードに関連付けられているが、ＵＥ６２０が米国のロケーションコードを提供している場合、検証コントローラ７１２は、アプリケーション６２２がアプリケーションＩＤを使用する直接発見を許可されていないと決定する。セキュリティ返答メッセージ内の、ＵＥ６２０によって提供されるロケーションコードが、アプリケーションＩＤに対する承認されたロケーションコードとマッチする場合、検証コントローラ７１２は、（適用可能な場合）他の検証ルール７１４に応じて、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されていると決定してもよい。

アプリケーションＩＤを使用する直接発見に対してアプリケーション６２２が許可されていないとき、検証コントローラ７１２は、拒否インディケータを生成して、アプリケーション６２２によって送信された発見要求を拒否する（ステップ９０８）。検証コントローラ７１２は、インターフェースコンポーネント７０２などを通して、ＰｒｏＳｅ機能６１２に拒否インディケータを提供することができ、その後、それは、発見要求が拒否されたことを示す情報と共に発見応答を送信することによって発見要求を拒否することができる。アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されている場合、検証コントローラ７１２は、検証インディケータを生成して、アプリケーション６２２によって送信された発見要求を許可する（ステップ９１４）。検証コントローラ７１２は、インターフェースコンポーネント７０２などを通して、ＰｒｏＳｅ機能６１２に検証インディケータを提供することができる。アプリケーション６２２が検証コントローラ７１２によって許可されると、ＰｒｏＳｅ機能６１２は、発見要求プロシージャを続行し、図４−５に示されるように、ＵＥ６２０に発見応答を送信することができ、または、さらなる許可プロシージャ（例えば、ＨＳＳ６１６に問い合わせる）を実行することができる。発見応答は、アプリケーションコード（アナウンシングのため）、モニタリングのための発見フィルター、または、ＵＥ６２０／アプリケーション６２２がアプリケーションＩＤを使用して直接発見を実行することを可能にする他の情報を含むことができる。

許可メカニズム６３０は、発見要求に応答して、アプリケーションＩＤの追加のレベルの検証を提供する。技術的利点の１つは、アプリケーションが、アプリケーションＩＤを偽装し、ＰｒｏＳｅ機能によって発見プロシージャのパーミッションを付与されることがより困難であることである。したがって、ネットワーク内の近接サービスは許可されたアプリケーションによって利用され、悪意のあるアプリケーションはブロックされる。

上で説明されたように、許可メカニズム６３０は、ＰｒｏＳｅ機能６１２において実施されることができる。図１１は、例示的な実施形態において、許可メカニズム６３０がＰｒｏＳｅ機能６１２において実施される場合のフロー図である。ＵＥ６２０は（アプリケーション６２２を通して）ＰｒｏＳｅ機能６１２に発見要求を送信する。発見要求は、ＰｒｏＳｅアプリケーションＩＤ、ＵＥ識別、コマンドタイプ（アナウンシング、モニタリングなど）、発見エントリＩＤ、アプリケーションＩＤなどを含む。次に、ＰｒｏＳｅ機能６１２が（許可メカニズム６３０を通して）発見許可プロシージャを開始する。ＰｒｏＳｅ機能６１２は、１つ以上のセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥ６２０に送信する。ＰｒｏＳｅ機能６１２は、ＵＥ６２０からセキュリティ返答メッセージを受信し、ＵＥ６２０によって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出する。次に、ＰｒｏＳｅ機能６１２は、セキュリティパラメータおよび検証ルール７１４のチャレンジ値（および任意選択で他の値）に基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーション６２２が許可されているかどうかを決定する。アプリケーションＩＤを使用する直接発見をアプリケーション６２２が許可されていない場合、ＰｒｏＳｅ機能６１２はアプリケーション６２２によって送信された発見要求を拒否する。アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されている場合、ＰｒｏＳｅ機能６１２は、直接発見に対する情報（例えば、アプリケーションコード、発見フィルターなど）をもつ発見応答をＵＥ６２０に送信する。ＰｒｏＳｅ機能６１２はまた、承認されたアプリケーションＩＤに関連する１つ以上のセキュリティパラメータ（および承認された値）を、発見応答のＰｒｏＳｅアプリケーションコードのサフィックスプール（およびアプリケーションコード／マスクに反映されることもある）に含めることができる。

図１２は、例示的実施形態において、許可メカニズム６３０がＰｒｏＳｅアプリケーションサーバ６１４において実施されるときのフロー図である。ＵＥ６２０は（アプリケーション６２２を通して）、ＰｒｏＳｅ機能６１２に発見要求を送信する。発見要求は、ＰｒｏＳｅアプリケーションＩＤ、ＵＥ識別、コマンドタイプ（アナウンシング、モニタリングなど）、発見エントリＩＤ、アプリケーションＩＤなどを含む。ネットワークポリシーに基づいて、ＰｒｏＳｅ機能６１２が発見要求に応答して、ＰｒｏＳｅアプリケーションサーバ６１４がアプリケーションＩＤを検証することを要求する。こうして、ＰｒｏＳｅ機能６１２は、ＰｒｏＳｅアプリケーションサーバ６１４に許可要求を送信する。ＰｒｏＳｅ機能６１２は、ＰｒｏＳｅアプリケーションサーバ６１４へのアプリケーションレベルコンテナ内に関連パラメータとアプリケーション６２２に対するアプリケーションＩＤとを含める。次に、ＰｒｏＳｅアプリケーションサーバ６１４は（許可メカニズム６３０を通して）発見許可プロシージャを開始する。ＰｒｏＳｅアプリケーションサーバ６１４は、ＰｒｏＳｅ機能６１２にセキュリティチャレンジメッセージを送信し、これは、１つ以上のセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥ６２０に転送する。ＰｒｏＳｅアプリケーションサーバ６１４は、代わりに、セキュリティチャレンジメッセージを直接的にＵＥ６２０に送ることができる。ＰｒｏＳｅ機能６１２は、ＵＥ６２０からセキュリティ返答メッセージを受信し、セキュリティ返答メッセージをＰｒｏＳｅアプリケーションサーバ６１４に転送する。ＰｒｏＳｅアプリケーションサーバ６１４は、ＵＥ６２０によって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出する。次に、ＰｒｏＳｅアプリケーションサーバ６１４は、セキュリティパラメータおよび検証ルール７１４のチャレンジ値（および任意選択で他の値）に基づいて、アプリケーション６２２がアプリケーションＩＤを使用する直接発見に対して許可されているかどうかを決定する。アプリケーション６２２が、アプリケーションＩＤを使用する直接発見を許可されていない場合、ＰｒｏＳｅアプリケーションサーバ６１４は、アプリケーション６２２によって送信された発見要求を拒否する拒否インディケータと共にＰｒｏＳｅ機能６１２に許可応答を送信する。アプリケーション６２２が、アプリケーションＩＤを使用する直接発見を許可されている場合、ＰｒｏＳｅアプリケーションサーバ６１４は、アプリケーション６２２によって送信された発見要求を許可する検証インディケータと共に、ＰｒｏＳｅ機能６１２に許可応答を送信する。次に、ＰｒｏＳｅ機能６１２は、検証／拒否インディケータに基づいて、発見応答をＵＥ６２０に送信する。ＰｒｏＳｅ機能６１２はまた、承認されたアプリケーションＩＤに関連する１つ以上のセキュリティパラメータ（および承認された値）を、発見応答のＰｒｏＳｅアプリケーションコードのサフィックスプール（およびアプリケーションコード／マスクに反映されることもある）に含めることができる。

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

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

特定の実施形態が本明細書に説明されたが、開示の範囲はそれらの特定の実施形態に限定されない。開示の範囲は、以下のクレームおよびそれらに同等なものによって定義される。

Claims (20)

1. システムであって、
   近接サービス（ＰｒｏＳｅ）に対する発見許可プロシージャを実行する許可メカニズムを備え、許可メカニズムは、
   ユーザ装置（ＵＥ）内のアプリケーションによって送信された発見要求に対する情報を受信するように構成された検証コントローラと、
   発見許可プロシージャに対する検証ルールを決定するように構成されたルールエンジンとを備え、発見要求は、アプリケーションに対する識別子（ＩＤ）を含んでおり、
   検証コントローラは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥに送信し、セキュリティチャレンジメッセージに応答してＵＥからセキュリティ返答メッセージを受信し、ＵＥによって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出し、セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成され、
   アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているときに、検証コントローラは、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するように構成される、
   システム。
2. アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、検証コントローラが、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するように構成される、請求項１に記載のシステム。
3. 許可メカニズムが、セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースをさらに備え、アプリケーションＩＤにマッピングされたセキュリティパラメータが、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む、請求項１に記載のシステム。
4. 検証コントローラが、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別し、ＵＥによって提供されたチャレンジ値を、アプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成される、請求項３に記載のシステム。
5. 検証コントローラが、ＵＥに割り当てられたネットワークアドレスを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される、請求項１に記載のシステム。
6. 検証コントローラが、公衆陸上移動体ネットワーク（ＰＬＭＮ）コードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される、請求項１に記載のシステム。
7. 検証コントローラが、ＵＥのロケーションコードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される、請求項１に記載のシステム。
8. 検証コントローラが、アプリケーションにアクセスするために使用されるパスコードを要求するセキュリティチャレンジメッセージを、ＵＥに送信するように構成される、請求項１に記載のシステム。
9. 許可メカニズムが、ＵＥから発見要求を受信するＰｒｏＳｅ機能において実施される、請求項１に記載のシステム。
10. 許可メカニズムが、ＵＥから発見要求を受信するＰｒｏＳｅ機能に通信可能に結合されたＰｒｏＳｅアプリケーションサーバにおいて実施される、請求項１に記載のシステム。
11. 近接サービス（ＰｒｏＳｅ）に対する発見許可プロシージャを実行する方法であって、方法は、
    許可メカニズムにおいて、ユーザ装置（ＵＥ）内のアプリケーションによって送信された発見要求に対する情報を受信するステップであって、発見要求はアプリケーションに対するアプリケーション識別子（ＩＤ）を含む、ステップと、
    許可メカニズムにおいて、発見許可プロシージャに対する検証ルールを決定するステップと、
    アプリケーションＩＤにマッピングされたセキュリティパラメータに対するチャレンジ値を要求するセキュリティチャレンジメッセージを、許可メカニズムからＵＥに送信するステップと、
    許可メカニズムにおいて、セキュリティチャレンジメッセージに応答して、セキュリティ返答メッセージをＵＥから受信するステップと、
    許可メカニズムにおいて、ＵＥによって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出するステップと、
    セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用した直接発見に対してアプリケーションが許可されているかどうかを決定するステップと、
    アプリケーションＩＤを使用した直接発見に対してアプリケーションが許可されているときに、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するステップと
    を含む、方法。
12. アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するステップをさらに含む、請求項１１に記載の方法。
13. セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースを記憶するステップをさらに含み、アプリケーションＩＤにマッピングされたセキュリティパラメータは、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む、請求項１１に記載の方法。
14. 直接発見に対してアプリケーションが許可されているかどうかを決定するステップが、
    アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別するステップと、
    ＵＥによって提供されたチャレンジ値をアプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用した直接発見に対してアプリケーションが許可されているかどうかを決定するステップと
    を含む、請求項１３に記載の方法。
15. １つ以上のプロセッサによって実行されるプログラムされた命令を具現化する非一時的なコンピュータ可読媒体であって、命令は、プロセッサに、近接サービス（ＰｒｏＳｅ）に対する発見許可プロシージャを実行する許可メカニズムを実施するように指示し、
    許可メカニズムは、ユーザ装置（ＵＥ）内のアプリケーションによって送信された発見要求に対する情報を受信するように構成され、発見要求は、アプリケーションに対するアプリケーション識別子（ＩＤ）を含み、
    許可メカニズムは、発見プロシージャに対する検証ルールを決定するように構成され、
    許可メカニズムは、アプリケーションＩＤにマッピングされたセキュリティパラメータに対するセキュリティチャレンジ値を要求するセキュリティチャレンジメッセージを、ＵＥに送信し、セキュリティチャレンジメッセージに応答して、ＵＥからセキュリティ返答メッセージを受信し、ＵＥによって提供されたセキュリティ返答メッセージからセキュリティパラメータに対するチャレンジ値を抽出し、セキュリティパラメータに対するチャレンジ値および検証ルールに基づいて、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成され、
    アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているとき、許可メカニズムは、検証インディケータを生成して、アプリケーションによって送信された発見要求を許可するように構成される、コンピュータ可読媒体。
16. アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されていないときに、許可メカニズムが、拒否インディケータを生成して、アプリケーションによって送信された発見要求を拒否するように構成される、請求項１５に記載のコンピュータ可読媒体。
17. 許可メカニズムが、セキュリティパラメータをアプリケーションＩＤにマッピングするデータベースを記憶するように構成され、
    アプリケーションＩＤにマッピングされたセキュリティパラメータが、アプリケーションＩＤに対してプロビジョニングされた許可された値を含む、請求項１５に記載のコンピュータ可読媒体。
18. 許可メカニズムが、アプリケーションＩＤにマッピングされたセキュリティパラメータに対する許可された値を識別し、ＵＥによって提供されたチャレンジ値を、アプリケーションＩＤに対してプロビジョニングされた許可された値と比較して、アプリケーションＩＤを使用する直接発見に対してアプリケーションが許可されているかどうかを決定するように構成される、請求項１７に記載のコンピュータ可読媒体。
19. 許可メカニズムが、ＵＥから発見要求を受信するＰｒｏＳｅ機能において実施される、請求項１５に記載のコンピュータ可読媒体。
20. 許可メカニズムが、ＵＥから発見要求を受信するＰｒｏＳｅ機能に通信可能に結合されたＰｒｏＳｅアプリケーションサーバにおいて実施される、請求項１５に記載のコンピュータ可読媒体。

Images