JP2017528071A - 近接サービスに対するオンライン課金 - Google Patents

Abstract

近接サービスに対するオンライン課金を実行するシステムおよび方法。一実施形態は、モバイルネットワーク向けの近接サービスを制御する近接サービス要素である。近接サービス要素は、近接サービスに向けてユーザ機器（ＵＥ）からサービス要求を受信し、近接サービスに関するオンライン課金情報を収集する。近接サービス要素は、オンライン課金情報をオンライン課金要求へとフォーマットし、オンライン課金要求をオンライン課金システムへと送信する。近接サービス要素は、近接サービスについてのクレジット認可結果を含むオンライン課金応答をオンライン課金システムから受信し、近接サービスについてのクレジット認可結果を示すサービス応答をＵＥへと送信する。

Description

本非仮出願は、２０１４年５月９日に出願された米国仮特許出願第６１／９９１，２６９号の優先権を主張するものであり、上記出願の全体が参照により本明細書に組み込まれる。

本発明は、通信システムの分野に関し、より詳細には、近接サービスに対する課金に関する。

近接サービス、または近接に基づくサービスとは、互いが近接しているデバイス（すなわち、ユーザ機器（ＵＥ））間に提供されるサービスのことを指す。近接サービスはデバイスツーデバイス（Ｄ２Ｄ）通信とも呼ばれ、ＵＥが備える無線技術を利用することにより、近接したＵＥ同士がコアネットワークを経由することなく直接的に通信を交わすものである。あるＵＥが別のＵＥと直接通信を確立することが可能であれば、それらは「近接」しているとみなされる。

第３世代パートナーシッププログラム（３ＧＰＰ）では、ロングタームエボリューション（ＬＴＥ）ネットワーク向けの近接サービス（ＰｒｏＳｅ）について定義されている。ＰｒｏＳｅを利用することで、セルラーネットワークのアンダーレイとしてのＤ２Ｄ通信が可能となる。Ｄ２Ｄ通信では、ＵＥはコアネットワーク経由でデータ信号をルーティングする代わりに、セルラーリソースを用いたダイレクトリンク上で相互にデータ信号を送信しあう。よって、Ｄ２Ｄ通信には、進化型パケットコア（ＥＰＣ）などのコアネットワークを介したトラフィックルーティングに代わり、距離の近いＵＥ同士によるトラフィックの直接送信が必要となる。近接状態にあるＵＥ間に直接通信が存在するため、Ｄ２Ｄ通信はインフラを追加することなくＥＰＣネットワークからトラフィックをオフロードする。Ｄ２Ｄ通信はまた、データ転送の高速化や転送遅延の低減、さらにＵＥ内の電力効率を改善することも可能である。

通常、近接サービスには、ダイレクトディスカバリ、直接通信、およびＵＥ−トゥ−ネットワークリレーが含まれる。ダイレクトディスカバリとは、あるＵＥが、近接した他のＵＥを識別するための機能である。直接通信とは、近接したＵＥ同士が、ローカル無線リソースを用いて通信することを可能にする機能である。ＵＥ−トゥ−ネットワークリレーとは、リモートＵＥからネットワークへ、またはネットワークからリモートＵＥへと、ＵＥがトラフィックをリレーすることを可能にする機能である。たとえば、あるＵＥ（リモートＵＥと呼ぶ）がネットワーク用基地局のサービスエリア外であっても、ＵＥ−トゥ−ネットワークリレー機能を用いれば、同リモートＵＥは基地局のサービスエリア内に位置するリレーＵＥに向けて、リレーＵＥとの直接通信によりトラフィックを送信することが可能になる。このリレーＵＥは、ネットワークの基地局と通信することにより、リモートＵＥからネットワークへとトラフィックを転送する。

３ＧＰＰは近接サービスおよび関連アーキテクチャについて定義しているものの、近接サービスに対する課金方法については定義していない。

本明細書に記述される実施形態は、近接サービスに対するオンライン課金メカニズムを提供するものである。モバイルネットワークの近接サービス要素は、近接サービスに対応したＵＥと相互作用する。たとえば、ＵＥは、近接サービスの認可、近接した他のＵＥのディスカバリ開始許可、近接しているとみなされた他のＵＥとの直接通信の開始許可、などを要求するため、近接サービス要素に連絡し得る。近接サービス要素は、近接サービスにかかわるＵＥとのこうした相互作用のうちの１つ以上に応答して課金イベントをトリガするよう構成される課金トリガ機能（ＣＴＦ）を含み、近接サービスに関係する課金情報を収集する。次いで、近接サービス要素は、近接サービスに関するクレジット制御のため、オンライン課金システムに課金情報を提供する。

一実施形態は、モバイルネットワーク向けの近接サービスを制御するよう構成される近接サービス要素を含む。近接サービス要素は、近接サービスに対するサービス要求をＵＥから受信することと、近接サービスに関するオンライン課金情報を収集することと、近接サービスに関するオンライン課金情報をオンライン課金要求へとフォーマットすることと、オンライン課金要求をオンライン課金システム（ＯＣＳ）へと送信することとを行うよう構成される、コントローラを含む。コントローラは、近接サービスについてのクレジット認可結果を含むオンライン課金応答をＯＣＳから受信することと、近接サービスについてのクレジット認可結果を示すサービス応答をＵＥへと送信することとを行うよう構成される。

別の実施形態では、コントローラは、Ｄｉａｍｅｔｅｒ Ｒｏインターフェースを介してオンライン課金システムと通信するよう構成され、近接サービスに関するオンライン課金情報について、Ｄｉａｍｅｔｅｒ Ｒｏインターフェース内に少なくとも１つの属性値ペア（ＡＶＰ）が定義される。

別の実施形態では、あるＡＶＰは、近接サービスの機能を実行するよう設計されるＵＥ上のアプリケーションについてのアプリケーション識別子に関して定義され得て、あるＡＶＰは、ディスカバリ手順においてＵＥによって使用されるアプリケーションコードに関して定義され得る。

別の実施形態では、あるＡＶＰは、近接サービス要素により近接サービスに割り当てられた一意の識別子である課金識別子に関して定義され得る。

別の実施形態では、あるＡＶＰは、第３世代パートナーシッププロジェクト（３ＧＰＰ）により定義されたモデルＡおよびモデルＢから選択される、ディスカバリ手順においてＵＥが使用するディスカバリモデルに関して定義され得る。あるＡＶＰは、ディスカバリモデルに従って、ディスカバリ手順の間にＵＥによって使用される、ディスカバリロールタイプに関して定義され得る。このとき、ディスカバリロールタイプは、モデルＡの場合は、アナウンス、監視、および一致報告（ｍａｔｃｈ ｒｅｐｏｒｔ）の中から選択され、モデルＢの場合は、発見者側と被発見者側のどちらかから選択される。

別の実施形態では、あるＡＶＰは、一対一、一対多（すなわち一対グループ）、および一対全の中から選択される、直接通信のためにＵＥによって要求される直接通信タイプに関して定義され得る。

別の実施形態では、あるＡＶＰは、一対多または一対全となる通信タイプの場合、ＵＥが送信機と受信機のどちらとして動作するかを示す直接通信モードに関して定義され得る。

別の実施形態では、あるＡＶＰは、一対多となる通信タイプの場合の受信者数に関して定義され得る。

別の実施形態は、モバイルネットワーク向けの近接サービスを制御するよう構成されるモバイルネットワークの近接サービス要素においてオンライン課金を実装するための方法を含む。本方法は、近接サービスに対するサービス要求を（近接サービス要素において）ＵＥから受信することと、近接サービスに関するオンライン課金情報を収集することと、オンライン課金情報をオンライン課金要求へとフォーマットすることと、オンライン課金要求を近接サービス要素からＯＣＳへと送信することとを含む。本方法は、近接サービスについてのクレジット認可結果を含むオンライン課金応答を近接サービス要素においてＯＣＳから受信することと、近接サービスについてのクレジット認可結果を示すサービス応答を近接サービス要素からＵＥへと送信することとをさらに含む。

別の実施形態は、モバイルネットワーク向けの近接サービスを制御する近接サービス要素と通信するよう構成されるＯＣＳを含む。ＯＣＳは、ユーザ機器（ＵＥ）がかかわる近接サービスに関するオンライン課金情報を含むオンライン課金要求を近接サービス要素から受信することと、近接サービスに適用可能な課金ポリシーを識別することと、クレジット認可結果を生成するために課金ポリシーに基づき近接サービスに対しクレジット認可を付与するかどうかを決定することと、近接サービスについてのクレジット認可結果を示すオンライン課金応答を近接サービス要素へと送信することとを行うよう構成される。

上記の概要は、本明細書の態様のいくつかに関する基本的理解を提供するものである。この概要は、本明細書の網羅的概略ではない。かかる概要は、本明細書に重要不可欠な要素を特定するためのものでもなければ、本明細書の個々の実施形態が持つ範囲、または各請求項の範囲を正確に叙述するためのものでもない。その唯一の目的は、以下に示すより詳細な説明の前置きとして、本明細書が持つ概念の一部を簡略化した形式で提示することにある。

本発明に関するいくつかの実施形態を、添付図面を参照しながら、単なる例証として以下に記述する。各図面を通じ、同一の参照番号は、同一要素または同型の要素を表す。

例示的一実施形態における、近接サービスに向けたモバイルネットワークのアーキテクチャを示す図である。 ２つのＵＥ間における直接通信のシナリオを示す図である。 例示的一実施形態における、近接サービスの認可をＯＣＳに要求するための方法を示すフローチャートである。 例示的一実施形態における、ＯＣＳの概略図である。 例示的一実施形態における、近接サービスに対する課金方法を示すフローチャートである。 例示的一実施形態における、近接サービスに対するオンライン課金について示すメッセージ図である。 例示的一実施形態における、近接サービスに対するオンライン課金について示すメッセージ図である。

各図面および以下の記述は、特定の例示的実施形態を示すものである。よって、本明細書に明示的な記述や表示がなくとも、当業者であれば各実施形態の諸原理を具現化し各実施形態の範囲内のものである種々の構成を案出することが可能であることは理解されよう。さらに、本明細書に記述される実施例はすべて、各実施形態の諸原理に対する理解を促進するためのものであり、具体的に述べられた実施例や条件への限定は伴わないものと解釈されたい。つまり、本発明の概念は、以下に記述する特定の実施形態または実施例に限定されない。かかる限定は、請求項およびその均等物によって行われる。

図１は、近接サービスを提供する、モバイルネットワーク１００（たとえば、公衆陸上移動ネットワーク（ＰＬＭＮ））のアーキテクチャを示している。モバイルネットワーク１００にはパケット交換（ＰＳ）コアネットワーク１１０（進化型パケットコア（ＥＰＣ）など）が含まれ、これは無線アクセスネットワーク（ＲＡＮ）１１２を介してＵＥ１２０−１２１との通信を行う。ＲＡＮ１１２の一例として、進化型ＵＭＴＳ地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）が挙げられる。図１には示さないが、ＲＡＮ１１２には、ＵＥ１２０−１２１（およびその他のＵＥ）とＰＳコアネットワーク１１０の間でワイヤレス接続を提供する、複数の基地局（たとえば、ｅＮｏｄｅＢ）が含まれる。ＰＳコアネットワーク１１０には、モビリティ管理エンティティ（ＭＭＥ）、サービングゲートウェイ（Ｓ−ＧＷ）、パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）など、ＵＥ１２０−１２１にサービスを提供するネットワーク要素が１つ以上含まれ得る。また、モバイルネットワーク１００には、自身の加入者に関するプロファイルを格納する、ホーム加入者サーバ（ＨＳＳ）１１４が含まれる。

図１のアーキテクチャは、ローミングを行わないシナリオを示している。しかし、その他のアーキテクチャ（インターＰＬＭＮアーキテクチャ、ローミングアーキテクチャ、ＲＡＮ１１２の代わりにＷＬＡＮがＵＥをカバーする場合のアーキテクチャなど）が、本明細書に記述される実施形態に適用されてもよい。類似のシナリオが３ＧＰＰ ＴＳ２３．３０３（ｖ１２．０．０）に示されており、同文献の全体は参照により本明細書に組み込まれる。

モバイルネットワーク１００にはさらに、近接サービス要素１３０と近接サービス適用サーバ（ＡＳ）１３６が含まれる。近接サービス要素１３０には、近接サービスに必要なネットワーク関連動作に使用される、任意のサーバ、デバイス、装置、または機器（ハードウェアを含む）が含まれる。近接サービス要素１３０は、近接サービスの機能を制御するために、さまざまな役割を果たし得る。たとえば、近接サービス要素１３０は、近接サービスを要求するＵＥの認可やプロビジョニングを行うことができる。近接サービス要素１３０は、近接サービスに向けたディスカバリ手順の開始を要求するＵＥの認可やプロビジョニングを行うことができる。近接サービス要素１３０は、近接サービスに向けた直接通信の開始を要求するＵＥの認可やプロビジョニングを行うことができる。近接サービスＡＳ１３６には、近接サービス提供時に近接サービス要素１３０をサポートする、任意のサーバ、デバイス、装置、または機器（ハードウェアを含む）が含まれる。

ＵＥ１２０−１２１には、モバイル端末、モバイルブロードバンドアダプタを備えたラップトップコンピュータなど、エンドユーザが通信のために直接使用する、任意のデバイスが含まれる。ＵＥ１２０−１２１は、近接サービス対応型、つまり、１つ以上の近接サービスに対する要求および関連手順をサポートしているものとみなす。ＵＥ１２０およびＵＥ１２１の各々には、近接サービスを利用／提供するのに使用される、アプリケーション１２２および１２３がそれぞれ含まれる。アプリケーション１２２−１２３は、ローカル音声サービス、マルチメディアコンテンツの共有、ゲーム、グループマルチキャスト、コンテンツアウェアアプリケーション、公共の安全、などのために構成され得る。たとえば、アプリケーション１２２は、ＵＥ１２０がある百貨店に近付いたとき、同アプリケーションを通じて百貨店がＵＥ１２０に直接メッセージを送信することを可能にする、といった形の近接サービスを提供することができる。別の例として、アプリケーション１２２には、別のＵＥとの直接通信を可能にする、ソーシャルネットワークアプリケーション（たとえば、Ｆａｃｅｂｏｏｋ）が含まれてよい。

モバイルネットワーク１００は、近接サービスに対するオンライン課金を実装するため、本実施形態において機能強化される。そのような機能強化の１つとして、近接サービス要素１３０内のコントローラ１３２は、オンライン課金のための課金トリガ機能（ＣＴＦ）１３３を実装する。ＣＴＦは、サービスに対する課金可能イベントを検出し、これらの課金可能イベントに関する情報を対応する課金イベントへとまとめたうえで、この課金イベントをオンライン課金機能（ＯＣＦ）に向け送信するといった、ユーザによって要求された課金可能イベントを認可するためのコンポーネントである。ＣＴＦ１３３は、近接サービスに関連したイベントの時にトリガし、同近接サービスに関する情報を収集し、その情報をＯＣＦへと報告するよう構成される。ＣＴＦ１３３はまた、リソース使用中のリソース使用許可に関する可用性を追跡（「クォータ管理」）することや、ＯＣＦが許可しないか期限切れとなったときにエンドユーザのリソース使用を強制終了することができる。

本実施形態における別の機能強化として、モバイルネットワーク１００にはオンライン課金システム（ＯＣＳ）１４０が含まれるということが挙げられる。ＯＣＳ１４０には、モバイルネットワーク１００において提供される近接サービスへのオンライン課金を実現する、サーバ、デバイス、装置、または機器（ハードウェアを含む）が含まれる。オンライン課金とは課金メカニズムであり、行われるサービスに対し課金情報がリアルタイムで作用し得る。したがって、セッション／サービス制御を伴うこうした課金メカニズムの直接相互作用が必要となる。オンライン課金は２つのタイプ：セッションベースタイプ、またはイベントベースタイプとなり得る。イベントベース課金では、ＣＴＦは単一回オペレーションに関して課金イベントを報告する。セッションベース課金では、ＣＴＦはセッションに関して複数の課金イベントを報告する。課金原理についてのさらなる解説は３ＧＰＰ ＴＳ３２．２４０に記述されており、同文献の全体は参照により本明細書に組み込まれる。

モバイルネットワーク１００におけるさらに別の機能強化として、近接サービス要素１３０とＯＣＳ１４０の間で定義される、インターフェース１５０または参照点の存在が挙げられる。本明細書に記述されるインターフェース１５０により、ある近接サービスに関連したＯＣＳ１４０に向けて、近接サービス要素１３０がオンライン課金情報を提供することが可能になる。たとえば、インターフェース１５０には、Ｄｉａｍｅｔｅｒ Ｒｏインターフェースが含まれ得る。このインターフェースは、近接サービスに関する課金情報用に定義された１つ以上の新たな属性値ペア（ＡＶＰ）を持つことで機能を強化したインターフェースである。

本明細書で論じるオンライン課金原理は、ＵＥがＥ−ＵＴＲＡＮにより、またはＥ−ＵＴＲＡＮをよらずにサービスを提供されるシナリオ、ＵＥがホームＰＬＭＮ（ＨＰＬＭＮ）または訪問先ＰＬＭＮ（ＶＰＬＭＮ）内に位置するシナリオ、ＵＥが直接通信において送信機または受信機として動作するシナリオ、ＵＥが１つまたは複数のＰＬＭＮに属するシナリオ、ＨＰＬＭＮ近接サービス要素から割り当てられたアプリケーションコードを用いたアプリケーションＩＤによってＵＥがグループ化されるシナリオ、などに向けたものとなり得る。

図１に示すアーキテクチャは、近接サービス（ＰｒｏＳｅ）について論じた３ＧＰＰ ＴＳ２３．３０３に記載のアーキテクチャと類似し得る。図１のアーキテクチャは３ＧＰＰ仕様に準拠し得るが、本明細書で論じる概念は、エンドユーザデバイス間での直接通信を可能にする、あらゆる近接サービスに対して適用可能である。

本明細書で論じる近接サービスには、ディスカバリ機能、直接通信（Ｄ２Ｄ）機能、およびＵＥ−トゥ−ネットワークリレー機能が含まれる。ディスカバリとは、別のＵＥと近接したＵＥを識別する処理である。ディスカバリの一種としてダイレクトディスカバリがある。これはＵＥが展開する、自身と距離の近い他のＵＥを発見する処理であり、これら２つのＵＥの機能のみが使用される。たとえば、あるＵＥは、ローカル無線リソースを使用して近くにある他のＵＥの存在を発見することができる。別のタイプのディスカバリ（３ＧＰＰにおいてＥＰＣレベルディスカバリと呼ばれるもの）では、ＵＥの位置を監視し、それらのＵＥにＵＥ同士の近接を通知するため、ネットワーク内のサーバが使用される。

直接通信とは、ネットワークノードを（おそらくはＲＡＮの基地局以外は）一切経由しないチャネルによる無線技術（たとえば、Ｅ−ＵＴＲＡ）を用いたユーザデータプレーンでの送信を通じて行われる、近接した２つ以上のＵＥ間の通信のことをいう。直接通信により、コアネットワーク（ＰＳコアネットワーク１１０など）によるトラフィックのルーティングなしに、ＵＥ同士がローカル無線リソースを使用して直接的に通信することが可能となる。たとえば、ＵＥ同士は、双方が利用可能なＲＡＮ（基地局など）からの無線リソースを通じて、直接的に通信することができる。また、ＵＥ同士は、自身の無線リソースを通じて直接的に通信することも可能である。いずれにせよ、ＵＥ間でやりとりされるトラフィックは、コアネットワークを通じてルーティングされることはなく、ワイヤレスインターフェースを介してＵＥ間で直接送られる。

図２は、２つのＵＥ間における直接通信のシナリオを示している。シナリオ２０１において、基地局２０６は、ＵＥ２１０−２１１と通信状態にある。基地局２０６は、制御プレーン（制御パス、または制御チャネルとも呼ぶ）上でＵＥ２１０−２１１と通信することにより、それらのＵＥとシグナリングメッセージおよび他のタイプの制御メッセージをやりとりする。ＵＥ２１０−２１１は、ローカル無線リソースを使用してユーザデータプレーン（データパス、またはデータチャネルとも呼ぶ）上に直接通信を確立することにより、コアネットワークによるトラフィックのルーティングなしに、互いが直接的に通信することができる。シナリオ２０２においても、基地局２０６は制御プレーン上でＵＥ２１０−２１１と通信して、それらのＵＥとシグナリングメッセージおよび他のタイプの制御メッセージをやりとりする。ＵＥ２１０−２１１は、コアネットワークによるトラフィックのルーティングなしに、基地局２０６を通じてユーザデータプレーン上で直接通信を確立することができる。上記シナリオの各々において、ＵＥ２１０−２１１は互いの間に直接通信を確立する。本明細書では、これをＤ２Ｄ通信とも呼ぶ。

ＵＥ−トゥ−ネットワークリレーとは、あるＵＥが、１つ以上のリモートＵＥに対する「ユニキャスト」サービスへの接続性をサポートするための機能である。リモートＵＥとは、ＲＡＮ（たとえば、Ｅ−ＵＴＲＡＮ）からサービスを提供されず、ＵＥ−トゥ−ネットワークリレーによりネットワークと通信するＵＥを指す。たとえば、リモートＵＥは、たとえＲＡＮのサービスエリア外であったとしても、そのサービスエリア内にある別のＵＥ（リレーＵＥ）を経由してＰＤＮにアクセスすることができる。リレーＵＥは、ＵＥ−トゥ−ネットワークリレーに対応したデバイスとなる。ＵＥ−トゥ−ネットワークリレーにより、サービスエリア内のリレーＵＥを介したネットワークからリモートＵＥへの通信、または、サービスエリア内のリレーＵＥを介したリモートＵＥからネットワークへの通信が可能となる。よって、「ＵＥ−トゥ−ネットワークリレー」という用語は、リモートＵＥからネットワークへの通信、およびネットワークからリモートＵＥへの通信のことを指す。

本実施形態では、ＵＥ１２０は、ＵＥ１２１との直接通信など、ある近接サービスを開始することを望むと仮定する。ＵＥ１２０は、近接サービスの開始時、近接サービス要素１３０に連絡するようプログラムされる。ＵＥ１２０は、近接サービスの認可、近接サービスに関するディスカバリ（たとえば、アナウンス要求、監視要求、または一致報告）の認可、近接サービスに向けた直接通信（たとえば、一対一、一対多、または一対全）の開始認可、などを要求するため、近接サービス要素１３０に連絡し得る。つまり、ＵＥ１２０は、制御プレーン上で、近接サービスに関連した種々の要求を、近接サービス要素１３０へと送信し得る。近接サービス要素１３０は、ＵＥ１２０からの１つ以上の要求に応答してオンライン課金を開始するよう機能強化されたものである。

図３は、例示的一実施形態における、近接サービスの認可をＯＣＳに要求するための方法３００を示すフローチャートである。方法３００の各ステップは、図１の近接サービス要素１３０を基準として説明されるが、当業者であれば、方法３００は他のシステムにおいても実行可能であることは理解されよう。さらに、本明細書に記述されるフローチャートの各ステップは網羅的なものではなく、示されない他のステップが含まれてもよい。また、各ステップの実行順序が置き換えられてもよい。

近接サービス要素１３０内のコントローラ１３２は、ＵＥ１２０から近接サービスに対するサービス要求を受信する（ステップ３０２）。近接サービス要素１３０は、加入者プロファイル、サービスタイプ、時刻（Ｔｉｍｅ ｏｆ Ｄａｙ：ＴｏＤ）などに基づき、ＵＥ１２０のエンドユーザをオンライン課金ユーザとして識別することができる。エンドユーザがオンライン課金にサブスクライブするとき、近接サービス要素１３０内のＣＴＦ１３３は、近接サービスに関連した特定の課金可能イベントの時にトリガするようプログラムされる。つまり、ＣＴＦ１３３は、ＵＥ１２０からのサービス要求を受信するとトリガする。コントローラ１３２は、近接サービスに関連したオンライン課金情報を（ＣＴＦ１３３を通じて）収集する（ステップ３０４）。このオンライン課金情報には、オンライン課金機能が近接サービスに対するクレジット制御の実行に使用し得る、任意の情報が含まれる。オンライン課金情報は、少なくとも部分的に、近接サービスに単独で適用することができる（これは、モバイルネットワーク１００上の通常セッションとは対照的である）。オンライン課金情報の例を挙げれば、モバイル加入者の識別子（ＩＭＳＩなど）、ＰＬＭＮ（モバイルネットワーク１００など）の識別子、要求された機能のタイプ（たとえば、ディスカバリ、直接通信、またはその両方）、ＵＥが使用するダイレクトディスカバリのモデル（モデルＡ、モデルＢなど）、ディスカバリ手順におけるＵＥの役割（アナウンスＵＥ、監視ＵＥ、一致報告など）、ダイレクトディスカバリにおいて使用されるアプリケーションＩＤ、アナウンスＵＥに割り当てられるアプリケーションコード、一致報告において監視ＵＥが報告するアプリケーションコードおよびタイムスタンプ、ＵＥが要求する直接通信のタイプ（一対一、一対多、一対全など）、あるグループにおける参加者の識別子（たとえば、一対多の直接通信の場合）、などをＣＴＦ１３３は収集可能である。近接サービスに向け、同サービスに対する料金表の決定やクレジットの発行に使用可能な所望の情報が収集されてよい。オンライン課金情報については、本明細書の後段で詳述する。

コントローラ１３２は、オンライン課金情報の収集後、その情報をオンライン課金要求へとフォーマットする（ステップ３０６）。オンライン課金要求には、ＯＣＳにサービスの認可を要求するメッセージが含まれる。オンライン課金要求の一例として、Ｄｉａｍｅｔｅｒ Ｒｏクレジット制御要求（ＣＣＲ）が挙げられる。よって、コントローラ１３２は、近接サービスに関連したオンライン課金情報を、ＣＣＲの属性値ペア（ＡＶＰ）へとフォーマットし得る。次いで、コントローラ１３２は、このオンライン課金要求をＯＣＳ１４０へと送信する（ステップ３０８）。

図４は、例示的一実施形態における、ＯＣＳ１４０の概略図である。ＯＣＳ１４０には、オンライン課金機能（ＯＣＦ）４１０を実装するコントローラ４０２と、口座残高管理機能（ＡＢＭＦ）４１２と、レーティング機能（ＲＦ）４１４とが含まれる。ＯＣＦ４１０は、セッションベース課金およびイベントベース課金を制御する機能を表す（たとえば、セッションベース課金機能（ＳＢＣＦ）およびイベントベース課金機能（ＥＢＣＦ））。ＡＢＭＦ４１２は、ＯＣＳ１４０内における加入者の口座残高の場所である。ＲＦ４１４は、ネットワークオペレータが定めた料金表に従って、リソース使用に関する値（ＯＣＦ４１０が受信する課金イベント内に記述される）をＯＣＦ４１０の代わりに決定する。ＯＣＦ４１０は、課金イベントから取得した情報をＲＦ４１４に提供し、引き換えにレーティング出力（金額的なものあるいは金銭的でないもの）を受け取る。ＲＦ４１４は、データ容量に関するレーティング、セッション／接続時間に関するレーティング、サービスイベントに関するレーティング、などを扱うことができる。

また、ＯＣＳ１４０内のコントローラ４０２は、近接サービス用のポリシーデータベース（ＤＢ）４１６を実装する。ポリシーデータベース４１６は、近接サービスに対してオンライン課金がどのように実行されるかを定義する、課金ポリシー（または課金ルール）を格納する。近接サービス用課金ポリシーは、個々の加入者、および／または加入者グループに対し、ＯＣＳ１４０においてプロビジョニングされ得る。課金ポリシーを通じて、近接サービスの認可や異なるレートの適用を、以下の基準の任意の組合せに基づき行うことができる：
− 近接サービスであるか、他のサービス（非近接サービス）であるか
− ディスカバリまたは直接通信を要求した
− ディスカバリロールを要求した（ロールは、モデルＡの場合はアナウンス、監視、または一致報告、モデルＢの場合は発見者側または被発見者側となること、など）
− 直接通信を要求した（一対一、一対多、または一対全）
− 受信者がオンネットワーク、オフネットワーク、または国外であるか
− 受信者数
− アプリケーションＩＤまたはアプリケーションコード
− ＵＥの位置
− ディスカバリにおける範囲クラス
− ホームＰＬＭＮと訪問先ＰＬＭＮのどちらであるか
− １ユーザあたり請求、１イベントあたり請求、定額料金制、および近接サービス有効期間内での継続時間ベース請求のいずれであるか
− ＵＥが「Ｅ−ＵＴＲＡＮによるサービスを受けた」か「Ｅ−ＵＴＲＡＮによるサービスを受けていない」か
− ＵＥに対するサービスのクラス

図５は、例示的一実施形態における、近接サービスに対する課金方法５００を示すフローチャートである。方法５００の各ステップは、図４のＯＣＳ１４０を基準として説明されるが、当業者であれば、方法５００は他のシステムにおいても実行可能であることは理解されよう。

コントローラ４０２は、オンライン課金要求を近接サービス要素１３０から受信する（ステップ５０２）。オンライン課金要求に応答して、コントローラ４０２は、近接サービスに適用可能な課金ポリシーを識別する（ステップ５０４）。この近接サービスは、ＵＥ１２０、またはＵＥ１２０のエンドユーザ／加入者に適用可能なものである。たとえば、コントローラ４０２は、ＵＥ１２０またはそのエンドユーザに割り当てられた加入者ＩＤをオンライン課金要求から識別し、その加入者ＩＤに基づいてポリシーデータベース４１６から課金ポリシーを取得することができる。別の例では、コントローラ４０２は、オンライン課金要求からグループＩＤ識別し、そのグループＩＤに基づいてポリシーデータベース４１６から課金ポリシーを取得し得る。

課金ポリシーの識別後、コントローラ４０２は、その課金ポリシーに基づき、同近接サービスがそのＵＥに対し認可されているかどうかを決定する（ステップ５０６）。近接サービスの認可決定に際し、コントローラ４０２は、オンライン課金要求からのオンライン課金情報および課金ポリシーを処理して、この近接サービスに対しクレジットが認可されているかどうかを決定することができる。たとえば、ＵＥがＨＰＬＭＮではなくＶＰＬＭＮに位置する場合、クレジットは近接サービスに対し認可されないということが、課金ポリシーによって指定されてもよい。また、コントローラ４０２は、オンライン課金情報を処理して、エンドユーザの口座に十分な残高があるかどうかを決定することもできる。たとえば、コントローラ４０２は、ＡＢＭＦ４１２においてエンドユーザの口座残高を識別することができる。ＡＢＭＦ４１２は、ユーザが先立って購入した金額または他のサービスユニットを表すものである。また、コントローラ４０２は、（ＲＦ４１４を通じて）近接サービスに対する料金表を課金ポリシーに基づき識別することもできる。たとえば、課金ポリシーは、ＵＥがＥ−ＵＴＲＡＮのサービスを受けるときの近接サービスに適用される料金表と、それとは異なる、ＵＥがＥ−ＵＴＲＡＮのサービスを受けないときの近接サービスに適用される料金表とを示すことができる。近接サービスのために識別された料金表に基づき、口座残高が十分なものであれば、コントローラ４０２は、（ＯＣＦ４１０を通じて）クレジットがその近接サービスについて認可されたと決定することができる。また、コントローラ４０２は、クレジットが認可された場合に、近接サービスに関するサービスユニットのクォータを供与することもできる。ＯＣＳ１４０における、こうした課金ポリシーに基づく近接サービスの認可決定メカニズムは、クレジット認可と呼ばれる。

次いで、コントローラ４０２は、近接サービスに対するクレジット認可結果を示すオンライン課金応答を、近接サービス要素１３０へと送信する（ステップ５０８）。オンライン課金応答の一例として、Ｄｉａｍｅｔｅｒ Ｒｏクレジット制御返答（ＣＣＡ）が挙げられ、これにはクレジット認可結果を示す１つ以上のＡＶＰが含まれる。本実施形態のクレジット認可結果は、課金ポリシーに基づき近接サービスをＵＥに認可したということ、または、課金ポリシーに基づき近接サービスを拒否したということを示し得る。また、クレジット認可結果は、近接サービスのために供与されたサービスユニットのクォータを示すこともできる。

図３において、近接サービス要素１３０内のコントローラ１３２は、オンライン課金応答をＯＣＳ１４０から受信する（ステップ３１０）。このオンライン課金応答は、課金ポリシーに基づくＯＣＳ１４０からのクレジット認可結果を示すものである。コントローラ１３２は、このクレジット認可結果を示すサービス応答を、ＵＥ１２０に向けて送信する（ステップ３１２）。ＵＥ１２０へのサービス応答は、近接サービスのためにＯＣＳ１４０が供与したクレジットクォータ（認可された場合）、近接サービスに関連付けられたアプリケーションＩＤ、ディスカバリ手順のためのアプリケーションコード、などを示し得る。その後、ＵＥ１２０、ＯＣＳ１４０によって与えられた認可に基づき、動作を続行することができる。

上記実施形態には、近接サービスに対するオンライン課金を有利に可能にする。ＵＥ１２０からの要求を受けて、近接サービス要素がＯＣＳ１４０に向けて課金イベントをトリガするため、このＯＣＳ１４０による、近接サービスに対するクレジット認可の実行が可能となる。以上のことから、ネットワークオペレータは、直接通信、すなわちＤ２Ｄ通信などの近接サービスを利用する加入者のプリペイド口座に課金することが可能となる。

本実施形態は、ＯＣＳ１４０において、異なる課金モード、すなわち、イベントベース課金（１ステージもしくは２ステージ）またはセッションベース課金をサポートする。１ステージ課金には、即時イベント課金（ＩＥＣ）が含まれる。ＩＥＣでは、ＣＴＦがワンタイムの要求をＯＣＳ１４０へと送信する。この要求に応答して、ＯＣＳ１４０は、クレジットが認可されていれば、エンドユーザの口座から直接引き落としを行うことができる。リソースが使用できなければ、ＣＴＦはＯＣＳ１４０と通信して、エンドユーザの口座に返金することが可能である。２ステージ課金には、ユニット予約によるイベント課金（ＥＣＵＲ）が含まれる。ＥＣＵＲでは、リソース使用のために予約する所望のユニット量を示した要求がＣＴＦによって発行され、ＯＣＳがその量の分だけエンドユーザの口座を封鎖する。サービスが配信されると、ＣＴＦは実際に消費されたユニット量を示す別の要求を発行し、ＯＣＳがエンドユーザの口座から実際の引き落としを行う。セッションベース課金には、ユニット予約によるセッション課金（ＳＣＵＲ）が含まれる。ＳＣＵＲはＥＣＵＲと同様のものだが、予約が複数回発生し得るという違いがある。

上述した各実施形態には、近接サービスに関するオンライン課金情報を近接サービス要素１３０がＯＣＳ１４０へと転送可能であることから、近接サービスに対するオンライン課金を有利に可能とする。オンライン課金情報の内容は、所望のように変更されてよい。一例として、オンライン課金情報には、以下のデータが含まれてよい：
アプリケーションＩＤ
アプリケーションコード
フィルタＩＤ
イベント／セッションＩＤ
課金ＩＤ
ディスカバリモデル（モデルＡまたはモデルＢ）
ディスカバリロールタイプ（アナウンス／監視／一致報告、または発見者側／被発見者側）
直接通信タイプ（一対一、一対多、または一対全）
加入者ＩＤ
加入者モード（送信者側または受信者側）
受信者数
加入者ＰＬＭＮ ＩＤ
機能ＩＤ
加入者位置情報
サービスネットワークタイプ（Ｅ−ＵＴＲＡＮまたは非Ｅ−ＵＴＲＡＮ）
タイムスタンプ

このタイプのオンライン課金情報をＯＣＳ１４０に送信するためにＤｉａｍｅｔｅｒ Ｒｏ参照点（Ｄｉａｍｅｔｅｒ Ｒｏインターフェースとも呼ばれる）に対する新たなＡＶＰを定義することで、オンライン課金情報を転送してもよい。Ｄｉａｍｅｔｅｒ Ｒｏ向けに本明細書で新たに定義する例示的ＡＶＰを以下にいくつか列挙する。

近接サービスに関連付けられたアプリケーションＩＤに関する新たなＡＶＰが定義されてよい。アプリケーションＩＤとは、近接サービスの機能を実行するよう設計された、特定のアプリケーション（たとえば、ＵＥ上で実行されるもの）に対する世界的に一意な識別子である。

近接サービスに関連付けられたアプリケーションコードに関する新たなＡＶＰが定義されてよい。アプリケーションコードとは、ディスカバリ手順においてアナウンスＵＥのために使用されるコードであり、ディスカバリ手順に従事するアナウンスＵＥによって無線インターフェース上で監視ＵＥに送信されるメッセージに含まれるものである。アプリケーションコードは、アプリケーションＩＤ、およびアプリケーションコードに割り当てられた近接サービス要素のＰＬＭＮ ＩＤ（たとえば、モバイルカントリコード（ＭＣＣ）やモバイルネットワークコード（ＭＮＣ））に相当する、一時的識別子によって構成され得る。近接サービス要素は、アナウンスＵＥおよびアプリケーションごとにアプリケーションコードを割り当て、さらに、近接サービス要素とＵＥの両方で動作する、関連付けがなされた有効性タイマの割当ても行う。このＡＶＰは、アプリケーションコードに関連付けられた有効性タイマを示すことも可能である。

近接サービスに関連付けられたフィルタＩＤに関する新たなＡＶＰが定義されてよい。フィルタＩＤはディスカバリ手順において使用されるものであり、ディスカバリ手順の間にＵＥが監視するアプリケーションコードまたはマークを含んでいる。ＵＥは、１つ以上のアプリケーションコードがフィルタと一致したことを検知すると、そのアプリケーションコードを近接サービス要素に報告する。

近接サービスに割り当てられたイベントＩＤまたはセッションＩＤに関する新たなＡＶＰが定義されてよい。

近接サービスに割り当てられた課金ＩＤに関する新たなＡＶＰが定義されてよい。課金ＩＤとは、近接サービスに対する一意の課金識別子である。課金ＩＤは、アプリケーションＩＤ、アプリケーションコード、およびイベント／セッションＩＤを束ねるストリングとなり得る。近接サービス要素は、イベントまたはセッションに課金ＩＤを割り当てる。このイベントまたはセッションに関係する第１のＵＥは、近接サービス要素から課金ＩＤを受信することになる。グループ通信に関わるＵＥは、イベントまたはセッションに関するグループ内の他のＵＥに向けて、課金ＩＤを転送することになる。

ディスカバリ手順の間にＵＥが使用するディスカバリモデルに関する新たなＡＶＰが定義されてよい。たとえば、３ＧＰＰでは、ダイレクトディスカバリに向けた２つのモデルが定義されている（３ＧＰＰ ＴＳ２３．３０３参照）。ひとつ目がモデルＡであり、これは「私はここにいる（Ｉ ａｍ ｈｅｒｅ）」という方法論を用いるものである。「アナウンス」ＵＥが既定のディスカバリ間隔でディスカバリメッセージをブロードキャストし、これらのメッセージに関心がある「監視」ＵＥがそれらを読み取り、かつ処理する。このように、アナウンスＵＥは、自身についての情報をブロードキャストする。ふたつ目はモデルＢであり、これは「誰がいる？（ｗｈｏ ｉｓ ｔｈｅｒｅ？）」または「そこにいる？（ａｒｅ ｙｏｕ ｔｈｅｒｅ？）」という方法論を用いる。「発見者側」ＵＥは、応答を受信したい他のＵＥについての情報を送信する。次いで、この発見者側ＵＥに近接している「被発見者側」ＵＥは、発見者側の要求に関連した情報で応答し得る。このＡＶＰは、ＵＥがディスカバリのためにモデルＡとモデルＢのどちらを使用しているかを示すことができる。

ディスカバリ手順の間にＵＥが使用するディスカバリロールタイプに関する新たなＡＶＰが定義されてよい。モデルＡでは、ダイレクトディスカバリに参加するＵＥの各ロールが定義される。ロールの１つがアナウンスＵＥであり、その場合のＵＥは、発見許可を有する近接したＵＥによって使用され得る、特定の情報をアナウンスする。別のロールとして監視ＵＥがあり、その場合のＵＥは、アナウンスＵＥに近接した関心のある特定の情報を監視する。もう１つのロールが「一致報告」である。ディスカバリフィルタに一致するアプリケーションコードが、そのアプリケーションコードに対応するローカルに格納済みのアプリケーションＩＤを持たない場合、監視ＵＥにより、一致報告は使用される。よって、モデルＡのもとでは、このＡＶＰは、ＵＥがアナウンス、監視、または一致報告としてのロールを要求しているかどうかについて示すことができる。同じくモデルＢも、ダイレクトディスカバリに参加するＵＥについて、２つのロールを定義する。一方のロールは発見者側ＵＥであり、その場合のＵＥは、自身が発見に関心のある特定の情報を含む要求を送信する。他方のロールは被発見者側ＵＥであり、その場合、要求メッセージを受信したＵＥは、発見者側の要求に関連した何らかの情報を用いて応答可能である。よって、モデルＢのもとでは、このＡＶＰは、ＵＥが発見者側ＵＥと被発見者側ＵＥのどちらであるかについて示すことができる。

直接通信のためにＵＥが要求または使用する直接通信タイプに関する新たなＡＶＰが定義されてよい。直接通信タイプの例として、一対一、一対多（または一対グループ）、および一対全が挙げられる。一対一とは、２つのＵＥ間での直接通信であり、通信のベアラは双方向性のものとなる。所与のベアラの無線レイヤに渡されるＩＰパケットは、関連付けられたＬ２宛先アドレスを用いて、物理レイヤによって送信されることになる。同一ベアラの無線レイヤから引き渡されたＩＰパケットは、同一のレイヤ２宛先に向けた無線通信（Ｏｖｅｒ−Ｔｈｅ−Ａｉｒ）で受信されたものとなる。一対多とは、マルチキャスト通信であり、発信元ＵＥは、レイヤ２グループＩＤを宛先レイヤ２ＩＤとして使用することにより、ＩＰマルチキャストアドレスに向けてＩＰデータを送信する。受信側ＵＥは、一対多直接通信を受信するため、割り当てられた無線リソースをリスンする。受信側ＵＥは、宛先レイヤ２ＩＤに含まれるレイヤ２グループＩＤに基づき、受信したパケットをフィルタ出力する。そのパケットは、グループＩＤと一致する場合、上位レイヤへと配信される。ユーザプレーンのパケットはＩＰスタックへと配信され、そこでグループＩＤマルチキャストアドレスに基づき、フィルタリングを施される。一対全とは、直接通信であり、その場合のＵＥは、許可を持つ近接したすべてのＵＥに向け、通信をブロードキャストする。

近接サービスにかかわるＵＥの直接通信のモードに関する新たなＡＶＰが定義されてよい。一対多通信または一対全通信の場合、ＵＥは、発信元（すなわち送信側）ＵＥまたは受信側ＵＥとなり得る。換言すれば、このＵＥは、１つ以上のＵＥに向けてパケットを送信しているか、または別のＵＥが送信するパケットをリスンしているかのどちらかである。このＡＶＰは、ある直接通信について、ＵＥが送信側ＵＥと受信側ＵＥのどちらであるかを示すものである。

一対多通信の受信者数に関する新たなＡＶＰが定義されてよい。

上述したものとは異なる、任意のオンライン課金情報に関する新たなＡＶＰが定義されてよい。

例
図６は、例示的一実施形態における、近接サービスに対するオンライン課金について示すメッセージ図である。まず、ＵＥ１２０が、近接サービスの認可要求を、近接サービス要素１３０へと送信する。この認可要求には、近接サービスのアプリケーションＩＤ、ＵＥ ＩＤ、またはＵＥ１２０に関する、もしくはＵＥ１２０が要求する近接サービスに関する他の情報が含まれ得る。ＵＥ１２０は、有効時間を伴う、ダイレクトディスカバリおよび／または直接通信のためのサービス認可を、（自身のＨＰＬＭＮの）近接サービス要素１３０から取得する。サービス認可に関する手順は、ＵＥ１２０がすでにダイレクトディスカバリまたは直接通信に携わっており、その登録済みＰＬＭＮを変更する場合、もしくは、サービス認可がもはや無効となっている場合、ダイレクトディスカバリまたは直接通信のセットアップ開始に先立って実行される。認可要求に応答して、近接サービス要素１３０は、ＵＥ１２０が要求している近接サービスに関するオンライン課金情報を（自身のＣＴＦ１３３を通じて）収集する。次いで、近接サービス要素１３０は、このオンライン課金情報を、Ｄｉａｍｅｔｅｒ Ｒｏ ＣＣＲへとフォーマットする。このＤｉａｍｅｔｅｒ Ｒｏ ＣＣＲには、新たに定義されたＡＶＰ、すなわち、アプリケーションＩＤ、アプリケーションコード、フィルタＩＤ、イベント／セッションＩＤ、課金ＩＤ、ディスカバリモデル、ディスカバリロールタイプ、直接通信タイプ、加入者モード、および受信者数のうち、少なくとも１つ以上が含まれる。その後、近接サービス要素１３０は、このＣＣＲをＯＣＳ１４０へと送信する。

ＣＣＲに応答して、ＯＣＳ１４０は、課金ポリシーに基づき、その近接サービスに対してクレジットが認可されるかどうかを決定する。たとえば、加入者の口座に近接サービスへの支払いに十分な残高があれば、ＯＣＳ１４０は、その近接サービスに対してクレジットが認可されると決定し、ＵＥ１２０へのクレジットクォータを決定することができる。口座に近接サービスへの支払いに足る残高がなければ、ＯＣＳ１４０は、その近接サービスに対してクレジットは認可されないと決定し得る。ＯＣＳ１４０は、クレジット認可結果を伴うＤｉａｍｅｔｅｒ Ｒｏクレジット制御返答（ＣＣＡ）を、近接サービス要素１３０へと返す。ＣＣＡには、クレジット認可結果を示す、新たに定義された１つ以上のＡＶＰが含まれ得る。

ＣＣＡに応答して、近接サービス要素１３０は、クレジット認可結果（すなわち、認可または拒絶／失敗）を伴う認可応答を、ＵＥ１２０へと送信する。ＯＣＳ１４０によってクレジットが授与されれば、ＵＥ１２０は近接サービスを開始することができる。

図７は、例示的一実施形態における、近接サービスに対するオンライン課金について示す別のメッセージ図である。まず、ＵＥ１２０が、近接サービスに向けたディスカバリ要求を、近接サービス要素１３０へと送信する。このディスカバリ要求には、近接サービスのアプリケーションＩＤ、ＵＥ ＩＤ、アナウンスＵＥとしてのロールに関するコマンド、などが含まれ得る。関連するＵＥコンテキストがなければ、近接サービス要素１３０は、クレジット認可のため、Ｄｉａｍｅｔｅｒ Ｒｏ ＣＣＲをＯＣＳ１４０へと送信する。ＣＣＲに関するＡＶＰにより、ＵＥ ＩＤがＵＥサブスクリプションを識別する、ディスカバリのためのコマンドが「アナウンス」用に設定される、アプリケーションＩＤが近接サービスを開始するアプリケーションを示す、アプリケーションコードがディスカバリに使用されるコードを示す、有効性タイマがアプリケーションコードの有効時間を示す。ＯＣＳ１４０は、課金ポリシーに基づき、ディスカバリ要求がＵＥ１２０に対し認可されるかどうかを決定する。次いで、ＯＣＳ１４０は、Ｄｉａｍｅｔｅｒ Ｒｏ ＣＣＡにより、クレジット認可結果を近接サービス要素１３０へと返す。ディスカバリ要求が認可されれば、近接サービス要素１３０は、アプリケーションコードや有効性タイマなどを含むディスカバリ応答を用いて、ＵＥ１２０に応答する。その後、ＵＥ１２０は、近接サービス要素１３０が認可し構成した無線リソースを用いてアプリケーションコードをアナウンスすることにより、ディスカバリ手順を開始することができる。ディスカバリ要求が認可されなければ、近接サービス要素１３０は、失敗結果を示すディスカバリ応答を用いて、ＵＥ１２０に応答する。

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

また、ある要素が、その機能を遂行するプロセッサまたはコンピュータによって実行可能な命令として実装されてもよい。命令の例として、ソフトウェア、プログラムコード、およびファームウェアが挙げられる。こうした命令は、プロセッサによる実行時に、同プロセッサに指示を出し、当該要素の機能を遂行するよう動作可能なものである。かかる命令は、プロセッサが読取り可能なストレージデバイスに記憶され得る。ストレージデバイスの例として、デジタルメモリもしくはソリッドステートメモリ、磁気記憶媒体（磁気ディスク、磁気テープなど）、ハードドライブ、または光学的に読取り可能なデジタルデータ記憶媒体が挙げられる。

本明細書では、特定の実施形態について記述したが、本開示の範囲はそれらに限定されるものではない。本開示の範囲は、続く各請求項、およびその均等物によって定義される。

Claims (10)

1. 近接サービスに対するサービス要求をユーザ機器（ＵＥ）から受信することと、近接サービスに関するオンライン課金情報を収集することと、近接サービスに関するオンライン課金情報をオンライン課金要求へとフォーマットすることと、オンライン課金要求をオンライン課金システムへと送信することとを行うよう構成されるコントローラ
   を備える、モバイルネットワーク向けの近接サービスを制御するよう構成される近接サービス要素であって、
   コントローラは、近接サービスについてのクレジット認可結果を含むオンライン課金応答をオンライン課金システムから受信することと、近接サービスについてのクレジット認可結果を示すサービス応答をＵＥへと送信することとを行うよう構成される、近接サービス要素
   を備える、装置。
2. コントローラは、Ｄｉａｍｅｔｅｒ Ｒｏインターフェースを介してオンライン課金システムと通信するよう構成され、
   近接サービスに関するオンライン課金情報について、Ｄｉａｍｅｔｅｒ Ｒｏインターフェース内に少なくとも１つの属性値ペア（ＡＶＰ）が定義される、
   請求項１に記載の装置。
3. 少なくとも１つのＡＶＰは、
   近接サービスの機能を実行するよう設計されるＵＥ上のアプリケーションについてのアプリケーション識別子に関して定義されるＡＶＰと、
   ディスカバリ手順においてＵＥによって使用されるアプリケーションコードに関して定義されるＡＶＰと
   を含む、請求項２に記載の装置。
4. 少なくとも１つのＡＶＰは、
   近接サービス要素により近接サービスに割り当てられた一意の識別子である課金識別子に関して定義されるＡＶＰ
   を含む、請求項２に記載の装置。
5. 少なくとも１つのＡＶＰは、
   一対一、一対多、または一対全の中から選択される、直接通信のためにＵＥによって要求される直接通信タイプに関して定義されるＡＶＰと、
   一対多または一対全となる通信タイプの場合、ＵＥが送信機と受信機のどちらとして動作するかを示す直接通信モードに関して定義されるＡＶＰと、
   一対多となる通信タイプの場合の受信者数に関して定義されるＡＶＰと
   を含む、請求項２に記載の装置。
6. モバイルネットワーク向けの近接サービスを制御するよう構成されるモバイルネットワークの近接サービス要素においてオンライン課金を実装するための方法であって、
   近接サービス要素により、近接サービスに対するサービス要求をユーザ機器（ＵＥ）から受信することと、
   近接サービス要素により、近接サービスに関するオンライン課金情報を収集することと、
   近接サービス要素により、オンライン課金情報をオンライン課金要求へとフォーマットすることと、
   オンライン課金要求を近接サービス要素からオンライン課金システムへと送信することと、
   近接サービスについてのクレジット認可結果を含むオンライン課金応答をオンライン課金システムから近接サービス要素内に受信することと、
   近接サービスについてのクレジット認可結果を示すサービス応答を近接サービス要素からＵＥへと送信することと
   を含む、方法。
7. 近接サービス要素は、Ｄｉａｍｅｔｅｒ Ｒｏインターフェースを介してオンライン課金システムと通信し、
   近接サービスに関するオンライン課金情報について、Ｄｉａｍｅｔｅｒ Ｒｏインターフェース内に少なくとも１つの属性値ペア（ＡＶＰ）が定義される、
   請求項６に記載の方法。
8. 少なくとも１つのＡＶＰは、
   近接サービスの機能を実行するよう設計されるＵＥ上のアプリケーションについてのアプリケーション識別子に関して定義されるＡＶＰと、
   ディスカバリ手順においてＵＥによって使用されるアプリケーションコードに関して定義されるＡＶＰと
   を含む、請求項７に記載の方法。
9. 少なくとも１つのＡＶＰは、
   近接サービス要素により近接サービスに割り当てられた一意の識別子である課金識別子に関して定義されるＡＶＰ
   を含む、請求項７に記載の方法。
10. 少なくとも１つのＡＶＰは、
    一対一、一対多、または一対全の中から選択される、直接通信のためにＵＥによって要求される直接通信タイプに関して定義されるＡＶＰと、
    一対多となる通信タイプの場合、ＵＥが送信機と受信機のどちらとして動作するかを示す直接通信モードに関して定義されるＡＶＰと、
    一対多となる通信タイプの場合の受信者数に関して定義されるＡＶＰと
    を含む、請求項７に記載の方法。

Images