JP6532506B2 - サービスドメイン課金システムおよび方法 - Google Patents

Description

本願は、米国仮出願第６１／８８６，４５８号（２０１３年１０月３日出願、名称「Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ ａｎｄ Ｉｎｔｅｒａｃｔｉｏｎｓ ｗｉｔｈ Ｕｎｄｅｒｌｙｉｎｇ Ｎｅｔｗｏｒｋｓ」）および米国仮出願第６１／８５７，９１２号（２０１３年７月２４日出願、名称「Ｓｅｒｖｉｃｅ Ｄｏｍａｉｎ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ ａｎｄ Ｉｎｔｅｒａｃｔｉｏｎｓ ｗｉｔｈ Ｕｎｄｅｒｌｙｉｎｇ Ｎｅｔｗｏｒｋｓ」）の利益を主張し、参照により本明細書に援用される。

マシンツーマシン（Ｍ２Ｍ）技術は、有線および無線通信システムを使用して、デバイスが互により直接的に通信することを可能にする。Ｍ２Ｍ技術は、一意に識別可能なオブジェクトおよびインターネット等のネットワークを経由して通信するそのようなオブジェクトの仮想表現のシステムである、モノのインターネット（ＩｏＴ）のさらなる実現を可能にする。ＩｏＴは、食料品店内の商品等のさらに日常的な毎日のオブジェクトとの通信を促進し、それによって、そのようなオブジェクトの知識を向上させることによって、費用および無駄を低減させ得る。例えば、店は、在庫にあり得る、または販売された場合がある、オブジェクトと通信するか、またはそこからデータを取得することができることによって、非常に精密な在庫データを維持し得る。Ｍ２Ｍ技術は、誰がサービスに対する料金を請求することができるか、誰がそのようなサービスに対する料金を請求されるべきか、およびどのような動作が有料であるかを決定すること等の新しい課題をサービスに対する料金を請求することに導入する。

本明細書では、基礎的ネットワークと相互作用することができるサービスドメイン課金システムに関連する方法、デバイス、およびシステムが開示される。サービスドメイン課金アーキテクチャは、サービスドメイン課金管理（ＳＤ−ＣＭ）、サービスドメインオンライン課金システム（ＳＤ−ＯＣＳ）、サービスドメインオフライン課金システム（ＳＤ−ＯＦＣＳ）、およびサービスドメイン課金トリガ機能（ＳＤ−ＣＴＦ）を含む、いくつかの論理機能を含み得る。サービスベースの課金タイプが作成され、既存のイベント、セッション、オンライン、およびオフライン課金機構に適用され得る。サービスドメイン課金メッセージは、Ｘ、Ｙ、Ｚ基準点を介して交換され得る。Ｅ基準点が、サービスドメイン請求システムと連動するために使用され得、Ｂ基準点が、サービスドメイン請求システムと基礎的ネットワークの請求システムとの間で使用され得る。

一実施形態は、Ｍ２Ｍネットワークのサービス層内のサービスドメイン課金管理機能においてポリシーを受信することを含む方法である。このポリシーは、関連属性を伴うルールとして定義される。本方法はまた、Ｍ２Ｍネットワークのサービス層内の有料イベントを決定するために、ポリシーを使用することも含む。

Ｍ２Ｍサービスドメインのための例示的な課金システムは、サービスドメインのための課金ポリシーを記憶しているサービスドメイン課金管理機能と、サービスドメイン課金管理機能からサービス要求を受信し、サービスを与える前に要求されたサービスのクレジットをチェックするサービスドメインオンライン課金システムと、サービスドメイン課金管理機能から課金イベントを受信し、サービスドメイン課金データ記録を生成するサービスドメインオフライン課金システムとを含むことができる。

一実施形態は、インフラストラクチャノードにおけるサービスドメイン課金管理機能で、サービスドメインのための課金ポリシーを受信することを含む方法である。本方法は、インフラストラクチャノードにおけるサービスドメイン課金管理機能から、終点ノードにおけるサービスドメイン課金管理機能へ、ポリシーを分配することを含むことができる。

一実施形態は、Ｔｓｐ基準点を介してサービス層内のサービスドメイン課金システムと３ＧＰＰネットワーク内のマシンタイプ通信連動機能（ＭＴＣ−ＩＷＦ）との間で課金情報を転送することを含む方法である。本方法はまた、サービス層内のサービスドメイン課金システムまたは３ＧＰＰネットワーク内のＭＴＣ−ＩＷＦで、転送された課金情報を使用することも含む。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
例えば、本願発明は以下の項目を提供する。
（項目１）
マシンツーマシン（Ｍ２Ｍ）サービスドメインのための課金システムであって、
前記サービスドメインのための課金ポリシーを記憶しているサービスドメイン課金管理機能と、
前記サービスドメイン課金管理機能からサービス要求を受信するサービスドメインオンライン課金システムであって、前記サービスドメインオンライン課金システムは、前記サービスを与える前に前記要求されたサービスのクレジットをチェックする、サービスドメインオンライン課金システムと、
前記サービスドメイン課金管理機能から課金イベントを受信するサービスドメインオフライン課金システムであって、前記サービスドメインオフライン課金システムは、サービスドメイン課金データ記録を生成する、サービスドメインオフライン課金システムと
を備えている、課金システム。
（項目２）
前記サービスドメイン課金管理機能によって構成され、前記サービスドメイン課金管理機能に報告するサービスドメイン課金トリガ機能をさらに備えている、項目１に記載の課金システム。
（項目３）
前記ポリシーは、関連属性を伴うルールとして定義されている、項目１に記載の課金システム。
（項目４）
前記属性のうちの１つは、有料イベントオブジェクトを識別する有料イベント識別子であり、前記有料イベントオブジェクトは、前記Ｍ２Ｍネットワークのサービス層内のイベントを定義する、項目１に記載の課金システム。
（項目５）
マシンツーマシン（Ｍ２Ｍ）ネットワークのサービス層において、
サービスドメイン課金管理機能においてポリシーを受信することであって、前記ポリシーは、関連属性を伴うルールとして定義されている、ことと、
前記ポリシーを使用して、前記Ｍ２Ｍネットワークの前記サービス層内の有料イベントを決定することと
を含む、方法。
（項目６）
前記ポリシーは、アプリケーションから受信される、項目５に記載の方法。
（項目７）
前記属性のうちの１つは、有料イベント識別子である、項目５に記載の方法。
（項目８）
前記有料イベント識別子は、前記Ｍ２Ｍネットワークの前記サービス層内のイベントを定義する追加の属性を伴う有料イベントオブジェクトを識別する、項目６に記載の方法。（項目９）
前記属性は、課金する当事者を識別する発信元識別子と、課金される当事者を示す受信側ＩＤとを含む、項目５に記載の方法。
（項目１０）
前記属性は、前記ルールがアクティブであるかどうかを示すルール状態属性を含む、項目５に記載の方法。
（項目１１）
ルールは、ユニフォームリソースインジケータ（ＵＲＩ）でアドレス可能なリソースである、項目５に記載の方法。
（項目１２）
前記ポリシーは、属性を伴う構成を含み、前記属性は、イベントＩＤ、イベントタイプ、イベント開始、イベント終了、およびデータサイズを含む、項目５に記載の方法。
（項目１３）
前記構成は、課金イベントを作成するために使用される、項目１２に記載の方法。
（項目１４）
前記ポリシーは、サービスベースの課金を定義する、項目５に記載の方法。
（項目１５）
前記サービスドメイン課金管理機能は、構成可能な課金サービスをアプリケーションに提供する、項目５に記載の方法。
（項目１６）
マシンツーマシン（Ｍ２Ｍ）ネットワークのサービス層において、
インフラストラクチャノードにおけるサービスドメイン課金管理機能で、サービスドメインのための課金ポリシーを受信することと、
前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能から、終点ノードにおけるサービスドメイン課金管理機能へ前記ポリシーを分配すること
を含む、方法。
（項目１７）
終点ノードにおける前記サービスドメイン課金管理機能から、前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能へ課金レポートを送信することをさらに含む、項目１６に記載の方法。
（項目１８）
終点ノードにおける前記サービスドメイン課金管理機能から、前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能へクレジットチェックレポートを送信することをさらに含む、項目１６に記載の方法。
（項目１９）
前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能からサービスドメインオンライン課金システムへサービス要求を送信することにより、サービスを与える前に要求されたサービスのクレジットをチェックすることをさらに含む、項目１６に記載の方法。
（項目２０）
前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能からサービスドメインオフライン課金システムへ課金イベントを送信することにより、サービスドメイン課金データを生成することをさらに含む、項目１６に記載の方法。
（項目２１）
３ＧＰＰネットワークと相互作用するサービス層において、
Ｔｓｐ基準点を介して前記サービス層内のサービスドメイン課金システムと前記３ＧＰＰネットワーク内のマシンタイプ通信連動機能（ＭＴＣ−ＩＷＦ）との間で課金情報を転送することと、
前記サービス層内の前記サービスドメイン課金システムまたは前記３ＧＰＰネットワーク内の前記ＭＴＣ−ＩＷＦで、前記転送された課金情報を使用することと
を含む、方法。
（項目２２）
前記サービス層内の前記サービスドメイン課金システムと前記３ＧＰＰネットワーク内のポリシーおよび課金実施機能（ＰＣＥＦ）との間で課金関連ポリシーを転送するために、Ｒｘ基準点が使用される、項目２１に記載の方法。
（項目２３）
前記ＭＴＣ−ＩＷＦは、前記Ｔｓｐ基準点を介して３ＧＰＰ課金情報を前記ＳＤ−ＣＳに送信する、項目２１に記載の方法。
（項目２４）
前記ＳＤ−ＣＳは、前記Ｔｓｐ基準点を介してサービス層課金情報を前記ＭＴＣ−ＩＷＦに送信する、項目２１に記載の方法。
（項目２５）
マシンツーマシン（Ｍ２Ｍ）ネットワークのサービス層において、
ノードにおけるサービスドメイン課金管理機能で、アプリケーションからサービスドメインのための課金ポリシーを受信することと、
前記ノードにおける前記サービスドメイン課金管理機能から、別のノードにおけるサービスドメイン課金管理機能へ前記ポリシーを分配することと
を含む、方法。

図１は、実施形態による、例示的な非限定的課金アーキテクチャを図示する、略図である。 図２は、オンライン課金およびオフライン課金を伴う例示的な３ＧＰＰ ＰＣＣシステムを図示する、略図である。 図３は、Ｒｆ／Ｇａ基準点を使用する、３ＧＰＰオフライン課金システムとの例示的なＭＴＣ−ＩＷＦインターフェースを有する、別の例示的な非限定的アーキテクチャを図示する略図である。 図４は、例示的な非限定的ｏｎｅＭ２Ｍアーキテクチャを図示する略図である。 図５は、いくつかの例示的な論理機能の場所および展開のための例示的なシナリオを含む、例示的な非限定的サービスドメイン課金システム（ＳＤ−ＣＳ）を図示する略図である。 図６Ａは、例示的な課金ポリシー構成プロシージャを図示するフローチャートである。 図６Ｂは、アプリケーションが課金ポリシーをＳＤ−ＣＭに提供する、例示的な課金ポリシー構成プロシージャを図示するフローチャートである。 図７は、例示的なサービスドメインオフライン課金プロシージャを図示する、フローチャートである。 図８Ａおよび８Ｂは、クレジット要求およびクレジット予約のためのプロシージャを含む、オンライン課金のための例示的なプロシージャを図示するフローチャートである。 図８Ａおよび８Ｂは、クレジット要求およびクレジット予約のためのプロシージャを含む、オンライン課金のための例示的なプロシージャを図示するフローチャートである。 図９は、サービスベースの課金のための例示的なプロシージャを図示する、フローチャートである。 図１０は、課金ルールの例示的な非限定的集合を示す略図である。 図１１は、＜ｃｈａｒｇｉｎｇＲｕｌｅ＞リソースのための例示的な非限定的リソース構造を図示する略図である。 図１２は、＜ｃｈａｒｇｉｎｇＣｒｅｄｉｔ＞のための例示的な非限定的リソース構造を図示する略図である。 図１３は、課金構成のための例示的な非限定的リソース構造を図示する略図である。 図１４は、＜ｃｈａｒｇｅａｂｌｅＥｖｅｎｔ＞のための例示的な非限定的リソース構造を図示する略図である。 図１５は、＜ｃｈａｒｇｅａｂｌｅＳｅｒｖｉｃｅ＞のための例示的な非限定的リソース構造を図示する略図である。 図１６は、＜ｓｅｒｖｉｃｅＰｒｏｃｅｄｕｒｅ＞のための例示的な非限定的リソース構造を図示する略図である。 図１７は、Ｚ基準点を介して基礎的３ＧＰＰネットワークと連動し得る、サービスドメイン課金システム（ＳＤ−ＣＳ）を図示する略図である。 図１８Ａおよび１８Ｂは、デバイストリガプロシージャのための課金関連動作上で３ＧＰＰと連動するサービスドメインのための呼び出しフローを図示するフローチャートである。 図１８Ａおよび１８Ｂは、デバイストリガプロシージャのための課金関連動作上で３ＧＰＰと連動するサービスドメインのための呼び出しフローを図示するフローチャートである。 図１９Ａおよび１９Ｂは、ＳＤ−ＣＳと３ＧＰＰ課金システムとの間の相互作用を示す、例示的な信号フローを図示するフローチャートである。 図１９Ａおよび１９Ｂは、ＳＤ−ＣＳと３ＧＰＰ課金システムとの間の相互作用を示す、例示的な信号フローを図示するフローチャートである。 図２０は、ＳＤ−ＣＳが補償仲介（ＣＢ）サービス能力内に常駐する、例示的な非限定的アーキテクチャを図示する略図である。 図２１は、実施形態による、例示的な非限定的アーキテクチャを図示する。 図２２Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図２２Ｂは、図２２Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２２Ｃは、図２２Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２２Ｄは、図２２Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。 図２３Ａ−２３Ｃは、実施形態とともに使用することができる、例示的なインターフェースを図示する略図である。 図２３Ａ−２３Ｃは、実施形態とともに使用することができる、例示的なインターフェースを図示する略図である。 図２３Ａ−２３Ｃは、実施形態とともに使用することができる、例示的なインターフェースを図示する略図である。

Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ（ＥＴＳＩ）アーキテクチャは、Ｍ２Ｍ技術のためのオフライン課金システムを定義する。このアーキテクチャの側面を統合する、いくつかの実施形態では、課金データ記録（ＣＤＲ）の形態の課金情報が、記録された情報から導出され、課金サーバに転送され得る。課金に必要とされる全ての情報は、最初に、記録のために選択され得る。記録されたＭ２ＭイベントとＣＤＲとの間の１対１のマッピングであり得る。

図１は、実施形態による、例示的な非限定的課金アーキテクチャ１００を図示する略図である。そのような実施形態では、Ｍ２Ｍネットワークサービス能力層（ＮＳＣＬ）１０４内に組み込まれた課金機能（ＣＦ）１０２は、Ｃｍ基準点を使用する課金サーバ１０６
との相互作用に対して責任があり得る。ＤｉａｍｅｔｅｒがＣｍ基準点のためのプロトコルとして使用され得る。

図２は、オンライン課金２０２およびオフライン課金２０４ならびに他の関与するエンティティを伴う例示的な３ＧＰＰ ＰＣＣシステム２００を図示する略図である。第３世代パートナーシッププロジェクト（３ＧＰＰ）ポリシーおよび課金制御（ＰＣＣ）システムは、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）（例えば、ＥＰＳ、ＵＭＴＳ、固定、Ｉ−ＷＬＡＮ等）のためのサービス品質（ＱｏＳ）および課金に対して責任があり得る。ＰＣＣアーキテクチャは、それらの間の特定インターフェースとともにいくつかの機能を含み得る。ポリシーおよび課金ルール機能（ＰＣＲＦ）２０６は、ＩＰ−ＣＡＮセッション、ＩＰ−ＣＡＮベアラ、および／またはサービスデータフロー（ＳＤＦ）のためのポリシーおよび課金関連情報を作成することに責任があり得る。３ＧＰＰは、オフライン課金２０４およびオンライン課金２０２の両方をサポートし得る。オフライン課金２０４は、後払い加入者等、課金情報がリアルタイムで提供されるサービスに影響を及ぼさない機構である。反対に、オンライン課金システム（ＯＣＳ）２０２は、リアルタイムでクレジット制御等の課金機能を果たす。これは、典型的には、前払い加入者に対して、ＯＣＳ２０２がリアルタイムでサービス実行に影響することを可能にする。量ベースの課金、時間ベースの課金、複合型の量および時間ベースの課金、イベントベースの課金、および課金なしを含む、種々の課金モデルが３ＧＰＰでサポートされる。

図３は、Ｒｆ／Ｇａ基準点を使用する、３ＧＰＰオフライン課金システムとの例示的なＭＴＣ−ＩＷＦインターフェースを有する、別の例示的な非限定的アーキテクチャ３００を図示する略図である。ＭＴＣ−ＩＷＦ（マシンタイプ通信連動機能）エンティティ３０２は、Ｍ２Ｍサービス能力サーバ３０４にインターフェースで接続する。Ｔｓｐは、制御プレーンインターフェースを提供し得、Ｇｉ／ＳＧｉは、ユーザプレーンインターフェースであり得る。

図４は、例示的な非限定的ｏｎｅＭ２Ｍアーキテクチャを図示する略図である。ｏｎｅＭ２Ｍは、アーキテクチャ設計の初期段階にある最近提案された規格である。ｏｎｅＭ２Ｍの中心部分は、複数の共通サービス機能（ＣＳＦ）４０２から成る、共通サービスエンティティ（ＣＳＦ）である。ＣＳＥ内のＣＳＦ４０２は、登録、セキュリティ、課金、データ管理等のサービスであり得る。ＣＳＥは、Ｍ２Ｍ終点ノード（例えば、デバイス）、中間ノード（例えば、ゲートウェイ）、およびインフラストラクチャノード（例えば、ネットワークプラットフォーム）に常駐し得る。ｏｎｅＭ２Ｍは、３つの基準点、すなわち、アプリケーションとＣＳＥとの間のＸ基準点、２つのＣＳＥとの間のＹ基準点、ＣＳＥと基礎的ネットワークとの間のＺ基準点とを定義する。ｏｎｅＭ２Ｍは、基準点名をＸ、Ｙ、およびＺからＭｃａ、Ｍｃｃ、およびＭｃｎに更新している。Ｍｃｃ基準点に適用される動作は、サービスプロバイダドメイン間におけるＭｃｃ’基準点にも適用される。いくつかの例示的なｏｎｅＭ２Ｍ課金要件が、以下の表１で例証される。

Ｍ２Ｍサービスドメイン（本明細書で使用され場合、Ｍ２Ｍサービスプロバイダによって提供されるＭ２Ｍサービスを指し、ＥＴＳＩ Ｍ２Ｍアーキテクチャのサービス能力層（ＳＣＬ）と、ｏｎｅＭ２ＭアーキテクチャのＣＳＥおよびＣＳＦとを含む）では、そのような実施形態ではより複雑な利害関係者および新しい課金シナリオがあるため、新しい課題が課金に提示される。以下の表２は、それらの各々が他者（表２に示されるか、またはそうではないもの）と組み合わせられ得る、サービスドメインにおけるいくつかの例示的な課金シナリオを記載する。

サービスドメインは、課金をサポートするために以下の機能を使用し得る。
−自給自足であり得、かつ基礎的ネットワークから独立し得る、サービスドメイン課金を可能にする効率的な機構およびインターフェース
−集中型課金が所望されるときに基礎的ネットワーク課金システムと相互作用し、それを再利用するサービスドメインを可能にする機構およびインターフェース
−サービスドメインによって使用され得る、オンライン、オフライン、および新しい課金タイプをサポートするサービスドメイン課金機構
上記の機能は、既存の課金システムによって十分に対処されない場合がある。３ＧＰＰ
課金システムは、そのような機能に対処しない場合があり、サービスドメイン課金に適用可能ではない場合がある。ＥＴＳＩ Ｍ２Ｍ課金は、限定された課金機能のみを提供し得る。ＥＴＳＩ Ｍ２Ｍは、ネットワークサービス能力層における単純な情報記録を定義し、オフライン課金のみに対処する。これは、課金ポリシー制御のためのいかなる機構も提供しない。ＥＴＳＩ Ｍ２Ｍはまた、３ＧＰＰ課金を再利用する機構を定義しない場合がある。したがって、ＥＴＳＩ Ｍ２Ｍ課金は、非常に基本的であり、完全なＭ２Ｍ課金システムの要件を満たさない場合がある。ｏｎｅＭ２Ｍは、開発中の新しい規格として、いかなる課金機能およびプロシージャもまだ定義していない。

したがって、本明細書に記載される実施形態によると、１つ以上の基礎的ネットワークと相互作用し得る機構が、サービスドメイン課金システムに使用され得る。より具体的には、論理機能（例えば、ＳＤ−ＣＭ、ＳＤ−ＯＣＳ、ＳＤ−ＯＦＣＳ、およびＳＤ−ＣＴＦ）、それらの機能性、およびそれらの関係を定義する、全体的なサービスドメイン課金アーキテクチャを提供する、実施形態が本明細書で説明される。サービスベースの課金タイプを定義する実施形態、およびサービスドメインとの関連で既存のイベント、セッション、オンライン、および／またはオフライン課金を適用する実施形態も本明細書で説明される。Ｘ、Ｙ、Ｚ基準点にわたるサービスドメイン課金メッセージを定義する、実施形態も本明細書で説明される。さらに、本開示は、サービスドメイン請求システムとインタ−フェースで接続するためのＥ基準点、およびサービスドメイン請求システムと基礎的ネットワークの請求システムとの間のＢ基準点を説明する。本開示はまた、アーキテクチャ、メッセージ、および３ＧＰＰ課金システムとの相互作用も開示する。実施形態はさらに、ＥＴＳＩ Ｍ２Ｍ課金のために記載される。開示された機構をサポートする、定義されたリソース（すなわち、データ）構造およびプロシージャもまた、本明細書に記載される。本明細書で使用される用語は、ｏｎｅＭ２Ｍアーキテクチャ、規格、および関連文書に関連付けられ得るが、本開示された実施形態は、任意のサービスドメイン課金システムに適用され得ることに留意されたい。

種々の課金タイプが、本明細書で説明される実施形態では、サービスドメインでサポートされ得る。各々は、上記の表２で説明される可能な課金シナリオをサポートし得る。オンライン／オフライン課金等の３ＧＰＰ課金で使用される用語は、新しい課金シナリオのためのさらなる融通性をサービスドメインで提供するように、説明された実施形態に従って拡張される機能性とともに、簡単にするために本明細書で使用され得る。サービスベースの課金タイプは、サービスドメイン要件を満たすように本明細書で記載される。

従来のセッションベースおよびイベントベースの課金に加えて、サービスドメインは、固有のサービスベースの課金を提供し得る。ＣＳＥが多くの異なるＣＳＦを含み、「ビッグ」データも管理し得るので、ＣＳＥは、一連の動作、複数の入力、および複数の決定を伴う複合要求を行い得る。そのような要求は、動作の１つ以上のステップよりもむしろサービスによって、要求側が料金を課金されることをもたらし得る。

サービスドメインは、自身のセッションを有し得るか、またはセッションがないこともある。課金との関連で、本明細書で使用されるような「セッション」という用語は、広い範囲を有する。サービスセッションは、特定のサービスプロバイダへの加入者の加入であり得、および／または論理的サービス接続であり得る。加入者は、複数のサービス接続を有し得る。例えば、サービス登録は、終点ノード内のＣＳＥがインフラストラクチャノード内のＣＳＥに登録するとき等に進行中であり得る。そのような登録は、セッションと見なされ得、課金は、登録につき行われ得る。セッションは、一意のサービスセッション識別子（ＩＤ）によって識別され得、加入者ＩＤ、セッション持続時間、サービスセッションＱｏＳ、および／または課金に影響を及ぼし得る他の情報に関連付けられ得る。

サービスドメインイベントとは、データへの動作（例えば、作成、更新、読み出し等）等の非連続的トランザクションを指し得る。

サービスドメイン課金方法は、いくつかの実施形態では、３ＧＰＰにおけるオンラインおよびオフライン課金の概念と同様に、課金がどのようにリアルタイムサービスに影響を及ぼすかに基づいて、オンラインおよびオフライン課金に分割され得る。オフライン課金は、リアルタイムでサービスに影響を及ぼさないこともある。課金トリガ情報は、それが起こるＣＳＦで生成され得る。オフライン課金データを伴う課金レポートは、異なるノードを介してネットワークに渡され、サービスドメインＣＤＲ（ＳＤ−ＣＤＲ）を生成し得る。オンライン課金は、リアルタイムで与えられるサービスに影響を及ぼし得る。サービス要求が、最初に生成され得、サービスが与えられる前に、要求側のクレジットがチェックされ得る。サービスがオンライン課金を使用するか、またはオフライン課金を使用するかは、サービスセッションまたはイベントに基づき得る。例えば、アプリケーションは、サービスドメイン内でデータを作成し、そのデータを読み取ることが、ある料金でのイベントベースのオンライン課金であることを特定し得る。加入者（例えば、ユーザ、アプリケーション）は、オンラインおよびオフライン課金機構の両方の組み合わせを使用することによって課金され得る。

サービスドメイン課金システム（ＳＤ−ＣＳ）は、４つの論理機能から成り得る。図５は、いくつかの例示的な論理機能の場所、および展開のための例示的なシナリオを含む、例示的な非限定的サービスドメイン課金システム（ＳＤ−ＣＳ）を図示する略図である。アーキテクチャ５００の点線は、ノード内の随意的な機能を示す。アーキテクチャ５００は、インフラストラクチャノードにおいて制御を伴う集中型課金システム、および異なるノードにわたる制御を伴う分散型課金システムの両方をサポートし得る。以下では、課金のための機能ならびに呼び出しフローおよびメッセージの特徴が説明される。

サービスドメイン課金管理（ＳＤ−ＣＭ）５０２は、ＳＤ−ＣＳの中心であり得る。ＳＤ−ＣＭ５０２は、ＣＳＥ５０６がサポートする課金ポリシーを含み得る。これは、プロビジョニングおよび／または構成によって課金ポリシーを取得し得る。ポリシーは、サービスプロバイダから取得され得るか、またはアプリケーション５０８もしくは別のＣＳＥ５１０によって構成され得る。ＳＤ−ＣＭ５０２はまた、サービス層における有料イベントの統計に基づいて、そのポリシーを更新し得る。ＳＤ−ＣＭ５０２は、同一のＣＳＥ５０６内の他のＣＳＦとの内部インターフェースを有し得る。ＳＤ−ＣＭ５０２は、有料イベントおよびポリシーに関して他のＣＳＦ５０４を構成し得る。

ＳＤ−ＣＭ５０２は、課金情報のアグリゲータおよびディスパッチャとしての機能を果たし得る。これは、他のＣＳＦ５０４から課金要求およびイベントを受信し得る。ＳＤ−ＣＭ５０２は、要求をサービスドメインオンライン課金システム（ＳＤ−ＯＣＳ）５１２またはサービスドメインオフライン課金システム（ＳＤ−ＯＦＣＳ）５１４のいずれかにディスパッチし得る。ＳＤ−ＣＭ５０２は、ＳＤ−ＯＣＳ５１２および／またはＳＤ−ＯＦＣＳ５１４からの出力を入手し得、ポリシーに基づいて、情報をサービス請求ドメインまたは基礎的ネットワークの課金システムのいずれかに送信し得る。ＳＤ−ＣＭ５０２は、異なるノード（インフラストラクチャノード、中間ノード、および終点ノード等）におけるＳＤ−ＣＳ間の相互作用のためのアンカポイントであり得る。ＳＤ−ＣＭ５０２はまた、ＳＤ−ＣＳが課金関連動作のために基礎的ネットワークとインターフェースで接続し、相互作用するためのアンカポイントであり得る。

サービスドメインオフライン課金システム（ＳＤ−ＯＦＣＳ）５１４は、ＳＤ−ＣＭ５０２からオフライン課金イベントを受信し、ＳＤ−ＣＤＲおよびＳＤ−ＣＤＲファイルを生成し得る。サービスドメインオンライン課金システム（ＳＤ−ＯＣＳ）５１２は、サー
ビス要求を受信し、クレジットをチェックし、サービスを与え得る。ＳＤ−ＯＣＳ５１２は、異なるエンティティのためのクレジット情報を維持することができる。

中間ノードまたは終点ノードは、展開に応じて、ＳＤ−ＯＦＣＳ５１４およびＳＤ−ＯＣＳ５１２の一方または両方を有し得るか、または有していないこともある。インフラストラクチャノード内のＳＤ−ＣＭ５０２が、中間ノード５１０内のＳＤ−ＣＭ５１８、ＳＤ−ＯＦＣＳ５２０、およびＳＤ−ＯＣＳ５２２、ならびに終点ノード５２７内のＳＤ−ＣＭ５２４、ＳＤ−ＯＦＣＳ５２６、およびＳＤ−ＯＣＳ５２８を構成し得るため、ノード間のトラフィックを低減させ、応答時間を増加させるために、課金をローカルで行うことができる。

１つ以上のサービスドメイン課金トリガ機能（ＳＤ−ＣＴＦ）５３０、５３２、および５３４は、図５の小さいボックスで示されるように、ＣＳＦに常駐し得る。いくつかのＣＳＦは、ＳＤ−ＣＴＦ機能を有していないこともある。ＳＤ−ＣＭ５０２は、有料イベントおよびどのようにして報告するかに関して、ＳＤ−ＣＴＦ５３０を構成し得る。

ＳＤ−ＣＳ５０２は、ＹまたはＸ基準点を介して、料金等のその課金関連情報を他のＣＳＥまたはアプリケーションに広告し得る。ＳＤ−ＣＳ５０２は、Ｚ基準点を介して、基礎的ネットワーク内の課金および請求システムを利用し得る。ＳＤ−ＣＳの内部で、ＳＤ−ＯＣＳ５１２およびＳＤ−ＯＦＣＳ５１４は、互に通信し得る。そのような実施形態についてのさらなる詳細が、本明細書で提供される。

サービスドメインは、自身の請求システム５３６を有し得る。インフラストラクチャノード５０６内のＳＤ−ＣＳは、Ｅと称される基準点を介して、サービスドメイン請求システム５３６と通信し得る。Ｅ基準点は、Ｍ２Ｍサービスドメイン（例えば、ＣＳＥ）を、アプリケーションまたは基礎的ネットワークではない外部の側方システムに接続する。請求ドメインは、ＰＡＹＰＡＬ等の第三者アプリケーションであり得る。サービスドメインは、Ｅ基準点を介して、課金および請求情報を請求ドメインと交換し得る。サービスドメイン請求システム５３６はまた、それらが異なるプロバイダに由来し得るので、基礎的システム内の請求システム５４０とともにＢ基準点を有し得る。

終点ノード５２７内にＳＤ−ＣＭがないとき、終点ノードが登録している中間ノード５１０内のＳＤ−ＣＭ５１８またはインフラストラクチャノード５２７内のＳＤ−ＣＭ５０２は、課金のためのプロキシおよびアグリゲータの役割を果たし得る。中間ノード５１０内のそのようなＳＤ−ＣＭ５１８またはインフラストラクチャノード５２７内のＳＤ−ＣＭ５０２は、課金イベントを収集し、終点ノードのための課金ポリシーを記憶し得る。場合によっては、終点ノード５２７内にＳＤ−ＣＴＦもない。終点ノード５２７に関係付けられるトランザクションおよび課金は、中間ノード５１０またはインフラストラクチャノード５０６で捕捉され得る。

図では、インフラストラクチャノード５０６および終点ノード５２７におけるＳＤ−ＣＳによる動作が図示されている。同一の概念およびプロシージャが中間ノード５１０に適用される。例えば、インフラストラクチャノード５０６、中間ノード５１０、および終点ノード５２７内のＳＤ−ＣＳが互に通信するマルチホップ課金動作が可能である。図は、課金イベントが終点ノード５２７で起こり得ることを示すが、課金イベントはまた、中間ノード５１０またはインフラストラクチャノード５０６でも起こり得る。それらがインフラストラクチャノード５０６で起こる場合、インフラストラクチャノードにおけるＳＤ−ＣＳは、課金情報を処理し得る。ＳＤ−ＣＳは、情報を共有するために、課金情報を中間ノード５１０または終点ノード５２７にプッシュすることを選択し得る。

図６Ａは、例示的な課金ポリシー構成プロシージャ６００を図示するフローチャートである。フローは、インフラストラクチャノード５０６内のＳＤ−ＣＭ５０２が課金ポリシーを取得し、他の登録されたＣＳＥ５１０および５２７内で課金機能を構成するときの１つの可能な一般的シナリオを示すことに留意されたい。種々の実施形態によってサポートされ得る、示されていない他のシナリオは、アプリケーション５０８が、Ｘ基準点を介して、自身の特定の課金ポリシーをＳＤ−ＣＭ５０２に提供し得る場合を含む。そのようなポリシーは、異なるノード内のＣＳＥの間で交換および構成され得る。ＣＳＥはまた、異なるアプリケーションの間でポリシーの広告および交換を促進し得る。例えば、アプリストア内のＭ２Ｍアプリが、自身の課金ポリシーをプッシュするためにＸ基準点を使用し得るか、またはサービスドメイン上の既存の課金ポリシーに問い合わせを行い得る。アプリは、料金を収集するエンティティであり得る。種々の実施形態によってサポートされ得る、示されていない別のシナリオは、課金ポリシーがまた、中間ノード５１０および終点ノード５２７から開始されてデータ投入され、インフラストラクチャノード５０６内のＳＤ−ＣＭ５０２によって検証および集約され得る場合であり得る。種々の実施形態によってサポートされ得る、示されていないさらに別のシナリオは、経時的に動的に更新され得る課金ポリシーであり得る。例えば、料金、有料イベント等の変更が更新され得る。そのような更新は、異なるノードにおけるアプリケーションまたはＣＳＥによって開始されることができる。

図６Ｂは、アプリケーションが課金ポリシーをＳＤ−ＣＭに提供する、例示的な課金ポリシー構成プロシージャを図示するフローチャートである。ＳＤ−ＣＭは、１つのアプリケーションによって確立される課金ポリシーを他のアプリケーションに提供することができる。課金ポリシーを構成するアプリケーションは、サービスドメインを介して、有料イベントを収集し、他のアプリケーションに課金することができる。承認された場合、ＳＤ−ＣＭは、課金ポリシーを他のノードに分配することができる。

課金ポリシーの実施例は、サポートされた課金タイプ（例えば、オンライン、オフライン、サービスベース）、課金タイプとの加入者ＩＤおよびアプリケーション／加入者タイプの関連付け（例えば、オンライン、オフライン、サービスベース）、料金との加入者ＩＤ、アプリケーション／加入者タイプ、およびサービスドメイン動作の関連付け、有料イベントのリスト、有料イベント報告パラメータ、ならびにクレジット予約トリガおよび閾値を含む。

図７は、示された実施形態では、終点ノードにＳＤ−ＯＦＣＳがないことが仮定される、例示的なサービスドメインオフライン課金プロシージャ７００を図示するフローチャートである。有料イベントが起こると、ＣＳＦ５４２におけるＳＤ−ＣＴＦ５３４は、イベントを報告する。終点ノード５２７におけるＳＤ−ＣＭ５２４は、これらのレポートをインフラストラクチャノード５０６に送信する前に集約し得る。

図８Ａおよび８Ｂは、クレジット要求およびクレジット予約のためのプロシージャを含む、オンライン課金のための（必ずしも順次的に示されていない）例示的なプロシージャ８００を図示するフローチャートである。オンライン課金実施形態では、要求側（例えば、アプリケーション、加入者、ＣＳＥ等）は、サービスが与えられる前にサービスの代金を支払うために十分なクレジットを有していなければならない。十分なクレジットがない場合、要求が否定され得る。クレジットの不足および料金等の課金関連情報は、拒否メッセージの中で提供され得る。この拒否は、クレジット予約動作を開始すること、または課金構成メッセージを使用して新しい料金を交渉すること等の他の動作をサービスドメインでトリガし得る。要求側はまた、例えば、２０回にわたって、あるデータの読み出し動作の代金を支払うために十分なクレジットの予約を要求することによって、サービス要求の前にクレジットを予約し得る。

図８は、終点ノード５２７にＳＤ−ＯＣＳがないときの１つの可能なシナリオを図示するにすぎないことに留意されたい。終点ノード５２７にＳＤ−ＯＣＳ５２８があるとき、インフラストラクチャノードにおけるＳＤ−ＯＣＳ５１２は、課金構成メッセージを使用して、特定の要求側のためのクレジット情報および意思決定を、終点ノード５２７におけるＳＤ−ＯＣＳ５２８にプッシュ配信し得る。したがって、そのような実施形態のプロシージャは、より分散型であり、終点ノード５２７で局所化される。終点ノードまたは中間ノード５１０におけるＳＤ−ＯＣＳ５２８は、クレジット情報を同期させ得るように、課金レポートメッセージを使用して、１つ以上のレポートをインフラストラクチャノード５０６におけるＳＤ−ＯＣＳ５１０に送信し得る。

図９は、サービスベースの課金のための例示的なプロシージャ９００を図示する、フローチャートである。図示されるステップは、メッセージが本明細書の他の場所で説明されるため、明確にするために詳細が減らされている。ステップ１では、サービス要求がＣＳＥに到達する。要求を処理し、要求が動作の複数のステップを伴うサービスを目標にしていることを識別する、エンティティを表すために、「ＣＳＦディスパッチャ９０２」が使用され得る。サービスベースの動作のさらなる説明については、表２を参照されたい。ステップ２では、ＣＳＦディスパッチャ９０２が、要求を関連ＣＳＦに分配する。いくつかの動作は、他の要求への応答に依存し得るが、これは、明確にするために図に示されていないことに留意されたい。

ステップ３では、サービスを果たす動作のうちのいくつかが完了され得る。いくつかの動作は、実行されているクレジットチェックに依存し得ることに留意されたい。ステップ４では、ＣＳＦ５４２におけるＳＤ−ＣＴＦ５３４が、オフライン課金のための課金イベントまたはオンライン課金のための課金要求のいずれかをトリガし得る。サービス要求は、オンライン課金およびオフライン課金の両方を伴い得る。ステップ５、６、および７では、終点ノード５２７におけるＳＤ−ＣＭ５２４は、オンライン課金に対するサービス要求およびオフライン課金に対する課金レポートを、インフラストラクチャノード５０６におけるそれぞれのＳＤ−ＯＣＳ５１２およびＳＤ−ＯＦＣＳ５１４にディスパッチし得る。ＳＤ−ＣＭ５２４はまた、要求および応答を集約し得る。プロシージャのうちのいくつかは、他のプロシージャに依存し得る。ステップ８では、他の動作が完了する。ＣＳＦディスパッチャ９０２は、状態を受信し得る。ＣＳＦディスパッチャ９０２はまた、サービスの完了をサービス要求側に通知し得る。

以下の表３は、サービスドメイン課金動作で使用され得るメッセージを記載する。主要情報要素（ＩＥ）が、これらのメッセージの使用を示すために記載され、他のＩＥが、追加の情報を伝えるために含まれ得る。これらのメッセージは、ＲＥＳＴｆｕｌプロトコルまたはベースのプロトコル、もしくはそれに基づく他のプロトコル等の異なるスタイルのプロトコルによってサポートされ得る。本明細書で記載されるようなサービス層課金システムは、ＲＥＳＴｆｕｌアーキテクチャまたは非ＲＥＳＴｆｕｌアーキテクチャを適用し得る。

実施形態では、本明細書で開示される課金機構をサポートするために、データ構造が使用され得る。そのようなデータ構造は、リソースの形態を成し得る。リソースは、ＲＥＳＴｆｕｌアーキテクチャで一意にアドレス可能なオブジェクトであり得る。リソースは、転送され、ＲＥＳＴｆｕｌ動詞（例えば、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ）で操作されることができる、表現を有し得る。リソースは、ユニバーサルリソース識別子（ＵＲＩ）を使用して、一意にアドレス指定され得る。子リソースは、アドレス指定された（すなわち、親）リソースとの包含関係を有する、リソースであり得る。親リソース表現は、サブリソース（すなわち、子リソース）の１つ以上の参照を含
み得る。子リソースの寿命は、親リソースの寿命によって制限され得る。属性は、リソース自体についてのメタデータ等の情報を記憶し得る。

リソースベースのデータ構造は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）または制約されたアプリケーションプロトコル（ＣｏＡＰ）等のプロトコルを使用すること等のＲＥＳＴｆｕｌ動作を行うことをより容易にし得る。しかしながら、そのようなデータ構造は、非ＲＥＳＴｆｕｌプロトコルに適用され得る。リソースは、子リソースおよび属性を含み得る。

定義された構造は、融通性のある拡張可能なサービス層課金機構を可能にする。発信元は、ｃｈａｒｇｅＣｏｎｆｉｇリソースを使用して、受信側への課金ポリシーおよび構成を設定し得る。加えて、発信元は、課金構成およびポリシーに基づいて、異なる課金ルールを設定し得る。これらのルールは、誰（課金するエンティティ）が、何（例えば、オンラインまたはオフライン課金、イベントベース、サービスベース、またはセッションベースの課金等）に基づいて、誰（課金されるエンティティ）に課金するであろうかを示し得る。課金ルールは、システムが異なる粒度を有することを可能にし得る。例えば、課金ルールは、ＣＳＥノードまたはアプリケーション等の論理機能に基づき得る。課金ルールはまた、もしくは代わりに、リソースに基づき得る。例えば、課金ルールは、特定のリソースの全ての読み取り動作に課金したいエンティティに基づき得る。図に示されていないが、全てのリソースは、ベンダ特定の属性／子リソースをサポートするべきである。

図で使用されるように、以下の形状は、例示的な非限定的リソース構造を図示する。
−正方形のボックスは、リソースおよび子リソースに対して使用される
−丸みを帯びた角を伴う正方形のボックスは、属性に対して使用される
−平行四辺形は、リソースの集合に対して使用される
読み取り／書き込みアクセスモードでは、以下の値が仮定され得る。
−読み取り／書き込み（ＲＷ）が、ＣＲＥＡＴＥまたはＵＰＤＡＴＥ動作によって設定され得る
−リソースが作成および／または更新されるときに、読み取り専用（ＲＯ）が、ＣＳＥによって設定され得、そのような属性は、読み取り専用であり得る
−１回書き込み（ＷＯ）が、作成動作時に要求側（すなわち、要求を開始したエンティティ）によって設定され得、その後、そのような属性は、読み取り専用であり得る
図１０は、課金ルール１００２（すなわち、課金ポリシー）の例示的な非限定的集合１０００を示す略図である。ＣＳＥにおけるＳＤ−ＣＭ等のアプリケーション、または別のポリシーサーバ（例えば、第三者ポリシーサーバ）は、課金ルールを作成および更新するように、課金構成メッセージを送信し得る。集合は、＜ｃｈａｒｇｉｎｇＲｕｌｅ＞１００４として示される、ゼロから複数の個々の課金ルールを有し得る。本明細書で使用されるような「ＩＤ」は、一意の識別子を指し得るか、または参照されたリソースの場所を指し示すＵＲＩであり得ることに留意されたい。ＩＤを参照することによって、異なるリソースが効果的に関連付けられ得る。

図１１は、＜ｃｈａｒｇｉｎｇＲｕｌｅ＞リソースのための例示的な非限定的リソース構造１１００を図示する略図である。「共通属性」１１０２とは、リソースの作成時間およびリソースの有効期限等の一般的（すなわち、非課金特定の）属性を指す。アクセス権および加入等の課金と特異的に関連付けられない共通リソースもまた、「共通属性」に含まれ得る。＜ｃｈａｒｇｉｎｇＣｒｅｄｉｔ＞１１０４は、この課金ルールに関連付けられ得るか、または別個のリソースであり得ることに留意されたい。実施形態では、これは、クレジットを有するエンティティに関連付けられ得る。課金ルールに関連付けられる場合、＜ｃｈａｒｇｉｎｇＣｒｅｄｉｔ＞１１０４は、受信側のクレジットを定義し得る。これが分離されたリソースである場合、これがエンティティに関連付けるエンティティＩ
Ｄを含み得るか、またはその親リソースがエンティティＩＤを有する必要があるかのいずれかである。

以下の表４は、課金ルールを定義するために使用され得る、例示的な属性を記載する。ここに記載される「ＩＤ」は、数値ＩＤ等の一意のＩＤ、または関連リソースを指し示す一意にアドレス可能なＵＲＩであり得る。

図１２は、＜ｃｈａｒｇｉｎｇＣｒｅｄｉｔ＞１１０４のための例示的な非限定的リソース構造１２００を図示する略図である。以下の表５は、＜ｃｈａｒｇｉｎｇＣｒｅｄｉｔ＞１１０４のためのいくつかの例示的な属性を記載する。

図１３は、課金構成のための例示的な非限定的リソース構造１３００を図示する略図である。この構造を使用して、有料イベント、有料サービス、料金、および課金記録フォーム等の課金構成およびポリシーが記憶され得る。また、ｃｈａｒｇｉｎｇＣｏｎｆｉｇと呼ぶこともできる、＜ｃｈａｒｇｉｎｇＣｏｎｆｉｇ＞リソース１３０２のための集合があり得る。この集合は、＜ｃｈａｒｇｉｎｇＣｏｎｆｉｇ＞リソース１３０２で構成され得る。以下の表６は、ｃｈａｒｇｉｎｇＣｏｎｆｉｇのためのいくつかの例示的な属性（子リソース）を記載する。

図１４は、＜ｃｈａｒｇｅａｂｌｅＥｖｅｎｔ＞１４０２のための例示的な非限定的リソース構造１４００を図示する略図である。以下の表７は、＜ｃｈａｒｇｅａｂｌｅＥｖｅｎｔ＞のためのいくつかの例示的な属性を記載する。

一実施形態は、マルチステッププロセスと見なすことができる。ステップ１は、図１３に示されるように、イベントベース、サービスベース、加入ベース等のどのようなサービス層課金タイプがサポートされるかという構成であり得る。ｏｎｅＭ２Ｍは、現在、イベントベースの課金のみをサポートする。

ステップ２は、有料イベントのためのポリシーを構成することであり得る。各有料イベントは、図１４に示されるデータ構造の１つのインスタンスを有する。例えば、ステップ２では、エンティティは、「ＲＥＴＲＩＥＶＡＬ」として「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ」に基づいて有料イベントを定義することができる。各ＲＥＴＲＩＥＶＡＬ動作について、これは、有料イベントをトリガするべきであり、例えば、ｅｖｅｎｔＩＤ＝００１である。エンティティはまた、ｔｒａｎｓａｃｔｉｏｎＴｙｐｅおよび期間の両方に基づいて、別の有料イベントを定義することもできる。例えば、これは、「ｔｒａｎｓａｃｔｉｏｎＴｙｐｅ＝ＲＥＴＲＩＥＶＡＬ、およびｅｖｅｎｔＳｔａｒｔ＝１２ｐｍ、ｅｖｅｎｔＥｎｄ＝２０ｐｍ、ｅｖｅｎｔＩＤ＝００２」を定義することができる。したがって、イベント００２については、有料イベントは、両方の条件が満たされるときのみ起こり、すなわち、有料イベントは、午前１０時〜午後８時のＲＥＴＲＩＥＶＡＬ動作のみに起こる。このデータ構造では、誰が誰に課金しているかを特定しない（これはステップ３で行われる）ことに留意されたい。我々はポリシーを定義するのみであるため、ステップ３で多くの異なるシナリオを定義するために、これらのポリシーを使用することができる。

ステップ３は、図１１に示されるデータ構造を使用して、ステップ２で定義される有料イベントに基づいて特定のシナリオを定義することができる。ここで、これは誰が誰に課金しているかを定義する。例えば、ステップ２で定義されるイベント００１については、エンティティは、１つは、イベント００１を使用してＣＳＥ１がＡＥ１に課金し、１つは、イベント００１を使用してＡＥ１がＡＥ２に課金する、２つのシナリオを定義することができる。次いで、イベント００２については、これは、特定のシナリオのセットを有することができ、例えば、ＣＳＥ１がイベント００１を使用してＡＥ１に課金し、ＡＥ２がイベント００２を使用してＡＥ１に課金する。展開では、ステップ２で設定されるポリシーに基づいて定義される、これらのシナリオの多くがあり得る。

図１５は、＜ｃｈａｒｇｅａｂｌｅＳｅｒｖｉｃｅ＞１５０２のための例示的な非限定
的リソース構造１５００を図示する略図である。以下の表８は、＜ｃｈａｒｇｅａｂｌｅＳｅｒｖｉｃｅ＞のためのいくつかの例示的な属性を記載する。

図１６は、＜ｓｅｒｖｉｃｅＰｒｏｃｅｄｕｒｅ＞１６０２のための例示的な非限定的リソース構造１６００を図示する略図である。実施形態では、＜ｓｅｒｖｉｃｅＰｒｏｃｅｄｕｒｅ＞リソース１６０２は、サービスを果たすために必要とされる動作を特定し得る。サービス要求発信元は、サービスプロシージャを定義できない場合があることに留意されたい。サービスプロシージャは、サービスを提供することに関与するエンティティを決定し得る、ＣＳＥによって定義され得る。以下の表９は、＜ｓｅｒｖｉｃｅＰｒｏｃｅｄｕｒｅ＞１６０２のためのいくつかの例示的な属性を記載する。

ｃｈａｒｇｉｎｇＲａｔｅ収集リソースは、有料イベントまたはサービスに対して課金されるべき料金を定義し得る。サービスプロバイダは、料金をサービスエンティティにポストすることを選択し得る。ｃｈａｒｇｉｎｇＲａｔｅリソースは、特定の有料イベント、加入者、サービス等を料金に関連付け得る。料金は、特定の時間等、他の要因に対して特定的であり得る。料金は、以前のトランザクションに基づいて動的に増加または減少させられ得る。

ＣｈａｒｇｉｎｇＲｅｃｏｒｄｓは、定義された＜ｃｈａｒｇｉｎｇＲｅｃｏｒｄＦｏ
ｒｍ＞に基づいて作成され得る。各＜ｃｈａｒｇｉｎｇＲｅｃｏｒｄＦｏｒｍ＞は、特定の課金記録形式を定義し得る。ＣｈａｒｇｉｎｇＲｅｃｏｒｄｓは、作成されるインスタンスであり得る。

図１７は、Ｚ基準点を介して基礎的３ＧＰＰネットワークとインタ−フェースで接続する、サービスドメイン課金システム（ＳＤ−ＣＳ）１７０２を図示する略図である。Ｚ基準点のためのＳＤ−ＣＳ１７０２内のアンカポイントは、ＳＤ−ＣＭ機能である。課金関連動作に関して、Ｚ基準点は、図１７の例示的な非限定的アーキテクチャ１７００で示されるようなＴｓｐ、Ｇｉ／ＳＧｉ、およびＲｘ基準点を介することを含む、異なる方法で実現され得る。Ｔｓｐは、ＳＣＳ１７０６（サービスドメイン）とＭＴＣ−ＩＷＦ１７０４との間の制御プレーンインターフェースである。Ｇｉ／ＳＧｉは、ＳＣＳ１７０６とＰＧＷ１７０８との間のユーザプレーンインターフェースである。Ｒｘは、アプリケーション機能（ＡＦ）とＰＣＲＦ１７１０との間のインターフェースである。３ＧＰＰは、ＡＦが第三者アプリケーションサーバであり得ることを特定する。

より分断された実施形態では、サービスドメインおよび３ＧＰＰドメインは、ＣＤＲを交換し、ＣＤＲを統合し、集中型請求情報を再生し得る。より統合された実施形態では、サービスドメインおよび３ＧＰＰドメインは、課金ポリシー情報を交換し、１つのドメイン内で課金を行い得る。以下に、３ＧＰＰ課金および請求システムと連動するＳＤ−ＣＳ１７０２を伴う、シナリオのうちのいくつかが記載される。
１． ３ＧＰＰ課金のみ：ＳＤ−ＣＴＦがＳＤ有料イベントを収集し、イベントを３ＧＰＰ課金システムに渡す。
２． ３ＧＰＰ支援型課金：ＳＤ−ＣＴＦがＳＤ有料イベントを収集し、ＳＤ−ＯＦＣＳがＣＤＲを生成して、ＣＤＲを３ＧＰＰ課金システムに渡す。３ＧＰＰ課金システムがＳＤ−ＣＤＲを３ＧＰＰ ＣＤＲに統合する。
３． ３ＧＰＰ支援型請求：ＳＤ−ＣＴＦがＳＤ有料イベントを収集し、ＳＤ−ＯＦＣＳがＣＤＲを生成して、ＣＤＲファイルを作成する。ＳＤ−ＣＤＲファイルは、Ｔｓｐ基準点を介してＳＤ−ＣＳ機能から３ＧＰＰ ＭＴＣ−ＩＷＦ１７０４に転送される。３ＧＰＰ課金システムがＳＤ−ＣＤＲファイルおよび３ＧＰＰ ＣＤＲファイルを統合し、それらを３ＧＰＰ請求ドメインに渡す。
４． ＳＤ独立型請求：ＳＤが、ＳＤ−ＣＤＲファイルを処理するためにその独立請求システムを使用する。ＳＤ請求システムは、３ＧＰＰ請求ドメインと情報を交換し得る。
５． ＳＤのみの請求：ＳＤが、３ＧＰＰ課金システムから課金情報を得て、３ＧＰＰドメインおよびサービスドメインの両方のための集中型請求を生成する。

本開示された実施形態は、サービスドメインに関連し、３ＧＰＰドメインへの影響は、必要に応じてのみ説明される。本明細書で開示されるいくつかの動作は、２つ以上の基準点上で行われ得ることに留意されたい。メッセージおよび異なる基準点へのそれらの適用可能性の例示的なリストが、表３の中で提供されている。

いくつかの実施形態は、Ｔｓｐインターフェースを利用する。そのような実施形態では、サービスドメインおよび３ＧＰＰドメインは、課金情報を交換し得る。課金情報は、３ＧＰＰで定義されるＴｓｐ基準点を介してＣＤＲまたはＣＤＲファイルの形態で搬送され得る。そのようなシナリオは、以下を含み得る。
１． ＭＴＣ−ＩＷＦ１７０４が、ＳＤ−ＣＳ１７０２からサービスドメイン課金情報をプルする。
２． ＭＴＣ−ＩＷＦ１７０４が、３ＧＰＰドメイン課金情報をＳＤ−ＣＳ１７０２にプッシュする。
３． ＳＤ−ＣＳ１７０２が、ＭＴＣ−ＩＷＦ１７０４から３ＧＰＰドメイン課金情報をプルする。
４． ＳＤ−ＣＳ１７０２が、サービスドメイン課金情報をＭＴＣ−ＩＷＦ１７０４にプッシュする。

交換がＳＣＳ１７０６によって開始される場合、それがプッシュである場合、ＳＤ−ＣＳ１７０２は、ＣＤＲ転送要求メッセージのペイロードにＳＤ−ＣＤＲファイルを含み得る。３ＧＰＰ ＭＴＣ−ＩＷＦ１７０４は、単純に要求に応答し得るか、または応答メッセージに３ＧＰＰ ＣＤＲファイルを含み得る。３ＧＰＰが交換を開始した場合、類似動作が反対の方向で使用され得る。サービスドメインおよび３ＧＰＰドメインはまた、Ｔｓｐを介して課金関連ポリシーも交換し得る。

いくつかの実施形態は、Ｒｘインターフェースを利用する。そのような実施形態では、Ｒｘ基準点は、サービスドメインおよび３ＧＰＰドメインが課金関連ポリシーを交換するために使用され得る。ＳＣＳ１７０６は、３ＧＰＰトラフィックイベントについての通知に加入し得る。例えば、ＳＣＳ１７０６は、ＩＰセッションが閉鎖された、またはＵＥが異なるアクセス技術にハンドオーバーしたという通知を受信し得、ＳＣＳ１７０６におけるＣＳＥは、サービスドメイン動作をトリガするための措置を講じ得る。サービスドメインおよび３ＧＰＰドメインは、セッションベースの課金のために、Ｒｘを介してセッション関連情報を交換し得る。

いくつかの実施形態は、Ｇｉ／ＳＧｉインターフェースを利用する。そのような実施形態では、サービスドメイン動作が３ＧＰＰにおけるユーザプレーントラフィックであるため、サービスドメインは、サービスドメイン動作（データ作成、読み出し等）とともにサービスドメイン課金情報を含み、Ｇｉ／ＳＧｉを介して情報を３ＧＰＰドメインに送信し得る。ポリシーおよび課金実施機能（ＰＣＥＦ）１７１４は、情報を処理し、３ＧＰＰで課金を行い得る。

図１８Ａおよび１８Ｂは、ＳＣＳ開始型デバイストリガのためのシナリオを示す、例示的な信号フロー１８００を図示するフローチャートである。そのような実施形態では、そのサービスドメインは、課金関連動作において３ＧＰＰと連動し得る。図１８の太い線は、３ＧＰＰにおける動作およびメッセージを示す。ステップ１では、ネットワークアプリケーション１８０２が、ＭＴＣデバイスからデータを読み出す要求を送信し得る。ステップ２では、要求を受信すると、（３ＧＰＰではＳＣＳ１８０４として知られている）インフラストラクチャノード内のＣＳＥは、終点ノード（ＭＴＣ）１８０６内のＣＳＥが登録されているかどうか、およびそのオンライン状態をチェックする。図示した信号フローでは、ＭＴＣ１８０６は、オフラインである。ＳＣＳは、デバイスをトリガすることを決定する。ステップ３−９は、ＭＴＣデバイス１８０６をトリガする３ＧＰＰプロシージャを説明する。ステップ１０−１２では、ＭＴＣデバイス１８０６がオンラインであり、状態がインフラストラクチャノードで更新される。ステップ１３−１７では、ＳＤ−ＣＴＦが、課金イベントを捕捉し、課金報告メッセージをＳＤ−ＣＳ１８０８に送信する。ＳＤ−ＣＳ１８０８は、全てのＣＳＦから課金イベントを受信するため、これらのＳＤ−ＣＤＲを統合してＳＤ−ＣＤＲファイルを生成し得る。３ＧＰＰおよびサービスドメインは、同一のＭＴＣデバイス１８０６に対して両方のドメインにおけるＣＤＲを関連付けるために、ＩＭＳＩとサービスドメインＩＤ（加入ＩＤ等）とを相関させる必要がある。ステップ１８−１９では、サービスドメインおよび３ＧＰＰドメインが、Ｔｓｐ基準点を介してＣＤＲまたはＣＤＲファイルを交換し得る。ステップ２０−２１では、ＭＴＣ１８０６がオンラインに戻る任意の時点で、ネットワークアプリケーションからのデータ読み出し要求が行われ得る、サービスドメイン特定のＳＤ−ＣＤＲが、この動作のために生成され得る。このＣＤＲは、３ＧＰＰ課金システムと交換される場合もあり、されない場合もある。

図１９Ａおよび１９Ｂは、ＳＤ−ＣＳ１９０２と３ＧＰＰ課金システムとの間の相互作
用を示す、例示的な信号フロー１９００を図示するフローチャートである。この図に示されるプロシージャ、および本明細書で説明される任意の図に示されるプロシージャは、それぞれの図に示される順序で起こる必要はない。そのような相互作用は、３ＧＰＰとサービスドメインとの間で、より統合された課金を提供し得る。

ステップ１−４で、実施形態では、３ＧＰＰ課金システムがＳＤ−ＣＳ１９０２を制御し得る。３ＧＰＰ課金ポリシーエンティティＰＣＲＦ１９０４は、Ｒｘ基準点を介してＳＤ−ＣＳ１９０２のための課金ポリシー構成を送信し得る。ＳＤ−ＣＳ１９０２は、３ＧＰＰ課金システムからの入力に基づいて、その課金ポリシーを構成し得る。ステップ５−８では、ＭＴＣ−ＩＷＦ１９０６が、Ｔｓｐ基準点を介して３ＧＰＰ課金情報をＳＤ−ＣＳ１９０２に送信し得る。例えば、ＭＴＣ−ＩＷＦ１９０６は、３ＧＰＰ加入者情報を有し得、ＳＤ−ＣＳ１９０２は、３ＧＰＰ ＩＤをサービスドメインＩＤに関連付け得る。ステップ９−１２では、ＰＣＲＦ１９０４が、セッション状態等の３ＧＰＰ課金関連情報をＳＤ−ＣＳ１９０２に渡し得る。ＳＤ−ＣＳ１９０２は、そのポリシーに従って措置を講じ得る。例えば、ＳＤ−ＣＳ１９０２は、３ＧＰＰセッションが別のアクセス技術にハンドオーバーされた場合、異なる料金を適用し得る。ステップ１３−１５で、いくつかの実施形態では、ＳＤ−ＣＳ１９０２が、ユーザプレーン基準点Ｇｉ／ＳＧｉを介するＰＣＥＦ１９０８へのサービスドメイン動作メッセージ内にサービスドメイン課金情報を添付し得る。課金は、ＰＣＥＦ１９０８で行われ得る、情報は、ユーザプレーンを介してＳＤ−ＣＳ１９０２に返送され得る。

以下の表１０は、３ＧＰＰドメインとサービスドメインとの間で交換され得る、課金に関係付けられる例示的なメッセージを記載する。

図２０は、ＳＤ−ＣＳが補償仲介（ＣＢ）サービス能力内に常駐する、例示的な非限定的アーキテクチャ２０００を図示する略図である。図は、ネットワーク事例を示す。デバイスおよびゲートウェイに対して、サービス能力層は、ＳＤ−ＣＳを含まないことも、ＳＤ−ＣＳのサブセットを含むこともある。ゲートウェイ補償仲介（ＧＣＢ）およびデバイス補償仲介（ＤＣＢ）は、ＳＤ−ＣＴＦのみ、またはＳＤ−ＣＴＦおよびＳＤ−ＣＭを含み得る。図２１は、異なるノード内のＳＤ−ＣＳを示す、例示的な非限定的アーキテクチャ２１００を図示する。

以下の表１１は、一実施形態による、ＥＴＳＩ Ｍ２Ｍ課金システムによってサポートされ得る、例示的で非限定的な潜在的課金イベントを記載する。

図２３Ａ−２３Ｃは、サービスドメイン課金システムおよび方法の実施形態とともに使用することができる、インターフェースを示す略図である。インターフェースは、サービスドメイン課金システムおよび方法の実施形態の動作を表示および／または制御するために使用することができる、グラフィカルユーザインターフェース等のユーザインターフェースであり得る。

図２３Ａは、デバイスサーバまたはゲートウェイに関連付けられる有料イベント１および有料イベント２等の有料イベントを示す、一実施形態の例示的なユーザインターフェース２３０２を示す略図である。

図２３Ｂは、有料記録および関連情報要素を示す、一実施形態の例示的なユーザインターフェース２３０４を示す略図である。

図２３Ｃは、ノード間で交換されるメッセージ等のＡＰＩ情報を示す、一実施形態の例示的なユーザインターフェース２３０６を示す略図である。

インターフェース２３０２、２３０４、および２３０６等のインターフェースは、上記で議論されるサービスドメイン課金システムに関係付けられる情報を視認するために使用することができる。インターフェース２３０２、２３０４、および２３０６等のインターフェースはまた、上記で議論されるサービスドメイン課金システムに関係付けられるデータを構成および設定するために使用することもできる。例えば、そのようなインターフェースは、システムのための課金関連値を設定するために使用することができる。

図２２Ａは、１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴの構成要素ならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示された実施形態の機能性を実装するために使用することができ、サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の機能性および論理エンティティを含むことができる。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、あるいは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、複数のアクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図２２Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインとは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインとは、通常はＭ２Ｍゲートウェイの後ろにある、エリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じてＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイ
ス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービスプラットフォーム２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

図２２Ｂを参照すると、フィールドドメイン内の図示したＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、ならびにＭ２Ｍ端末デバイス１８および通信ネットワーク１２のためのサービスを提供する。通信ネットワーク１２は、開示された実施形態の機能性を実装するために使用することができ、キャピラリデバイス課金機能性と、サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の論理エンティティとを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２２Ｃおよび２２Ｄで図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／計算／記憶ファーム等）、または同等物によって実装され得る。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。図示したＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および基礎的通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

図２２Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよび垂直線が活用することができる、サービス配信能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。本願の接続方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および基礎的ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得る、サービス層を使用する。ＥＴＳＩ
Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上でホストすることができる、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、キャピラリデバイスと相互作用するアプリケーションを含み得、したがって、キャピラリデバイス課金のための開示されたシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示された課金システムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および基礎的ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を画定する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を画定する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、アプリケーション特定のノード）上でホストすることができる、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰ
ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他の構成要素またはモジュールとして具現化されようと、サービス層は、ネットワーク内の１つ以上の独立型サーバ、コンピュータ、または他のコンピュータデバイスもしくはノード上のいずれかで実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、またはそのようなネットワークの１つ以上の既存のサーバ、コンピュータ、もしくはノードの一部としてのいずれかで実装され得る。実施例として、サービス層またはその構成要素は、以下で説明される図２２Ｃまたは図２２Ｄで図示される一般アーキテクチャを有する、サーバ、コンピュータ、またはデバイス上で作動する
ソフトウェアの形態で実装され得る。

さらに、サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の本開示の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。

図２２Ｃは、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る、例示的デバイス３０の系統図である。デバイス３０は、サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の論理エンティティを実行するか、または含むことができる。デバイス３０は、図２２Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であり得る。図２２Ｃに示されるように、デバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。デバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本デバイスは、キャピラリデバイス課金のための開示されたシステムおよび方法、または他の開示された課金システムおよび方法を使用および／または実装する、デバイスであり得る。

プロセッサ３２は、汎用プロセッサ、特殊用途プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、１つ以上の特定用途向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプおよび数の集積回路（ＩＣ）、状態機械等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはデバイス３０が無線環境で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結され得る。図２２Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップに一緒に組み込まれ得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行い得る。

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、および／またはＭ２Ｍサービスプラットフォーム２２から信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークおよび無線インターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成され得
る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２２Ｃで描写されているが、デバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、デバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、デバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を変調するように構成され得る。上記のように、デバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、デバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のデバイス３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。

プロセッサ３０は、電源４８から電力を受け取り得、デバイス３０内の他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、デバイス３０に電力供給するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、Ｍ２Ｍデバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成され得る、ＧＰＳチップセット５０に連結され得る。デバイス３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線あるいは無線接続を提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図２２Ｄは、例えば、図２２Ａおよび２２ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピュータシステ
ム９０は、サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の論理エンティティを実行するか、または含むことができる。コンピュータシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、キャピラリデバイス課金のための開示されたシステムおよび方法、または他の開示された課金システムおよび方法の種々の実施形態で使用されるデータを受信、生成、および処理し得る。

動作中、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送経路であるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピュータシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータライン、アドレスを送信するためのアドレスライン、ならびに割り込みを送信するため、およびシステムバスを動作するための制御ラインを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。

システムバス８０に連結されているメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２および読み取り専用メモリ（ＲＯＭ）９３を含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正することができない、記憶されたデータを含む。ＲＡＭ８２に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られ、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを分離し、ユーザプロセスからシステムプロセスを分離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピュータシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子構成要素を含む。

さらに、コンピュータシステム９０は、図２２Ａおよび２２Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。実施形態では、ネットワークアダプタ９７は、キャピラリデバイス課金のための種々の開示されたシステムおよび方法、または他の開示された課金システムおよび方法によって使用されるデータを受信および伝送し得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。そのような命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等の機械によって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装する。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。サービスドメイン課金システム、ＳＤ−ＣＭ５０２、ＳＤ−ＯＣＳ５１２、ＳＤ−ＯＦＣＳ５１４、ＳＤ−ＣＴＦ５３０、ならびにインターフェース２３０２、２３０４、および２３０６等のユーザインターフェースを生じさせる論理等の論理エンティティは、コンピュータ実行可能命令の形態で具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、もしくは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

図で図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用すること、および任意の組み込まれた方法を行うことを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを目的としている。

Claims (14)

1. マシンツーマシン（Ｍ２Ｍ）ネットワークのサービス層において、
   前記サービス層におけるサービスドメイン課金管理機能において課金ポリシーを受信することであって、前記課金ポリシーは、関連属性を伴うルールとして定義されており、前記属性は、前記ルールがアクティブであるかどうかを示すルール状態属性と、有料イベント識別子とを含み、前記課金ポリシーは、ＣＲＥＡＴＥ、ＲＥＴＲＩＥＶＥ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ（ＣＲＵＤ）操作を用いて構成可能なリソース内に記憶されている、ことと、
   前記課金ポリシーを使用して、前記Ｍ２Ｍネットワークの前記サービス層内の有料イベントを決定することと
   を含む、方法。
2. 前記課金ポリシーは、アプリケーションから受信される、請求項１に記載の方法。
3. 前記有料イベント識別子は、前記Ｍ２Ｍネットワークの前記サービス層内のイベントを定義する追加の属性を伴う有料イベントオブジェクトを識別する、請求項２に記載の方法。
4. 前記属性は、課金する当事者を識別する発信元識別子と、課金される当事者を示す受信側ＩＤとを含む、請求項１に記載の方法。
5. ルールは、ユニフォームリソースインジケータ（ＵＲＩ）でアドレス可能なリソースである、請求項１に記載の方法。
6. 前記課金ポリシーは、属性を伴う構成を含み、前記属性は、イベントＩＤ、イベントタイプ、イベント開始、イベント終了、およびデータサイズを含む、請求項１に記載の方法。
7. 前記構成は、課金イベントを作成するために使用される、請求項６に記載の方法。
8. 前記課金ポリシーは、サービスベースの課金を定義する、請求項１に記載の方法。
9. 前記サービスドメイン課金管理機能は、構成可能な課金サービスをアプリケーションに提供する、請求項１に記載の方法。
10. 前記サービスドメイン課金管理機能は、インフラストラクチャノードにあり、前記方法は、
    前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能から、終点ノードにおけるサービスドメイン課金管理機能へ前記課金ポリシーを分配すること
    をさらに含む、請求項１に記載の方法。
11. 終点ノードにおける前記サービスドメイン課金管理機能から、前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能へ課金レポートを送信することをさらに含む、請求項１０に記載の方法。
12. 終点ノードにおける前記サービスドメイン課金管理機能から、前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能へクレジットチェックレポートを送信することをさらに含む、請求項１０に記載の方法。
13. 前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能からサービスドメインオンライン課金システムへサービス要求を送信することにより、サービスを与える前に要求されたサービスのクレジットをチェックすることをさらに含む、請求項１０に記載の方法。
14. 前記インフラストラクチャノードにおける前記サービスドメイン課金管理機能からサービスドメインオフライン課金システムへ課金イベントを送信することにより、サービスドメイン課金データを生成することをさらに含む、請求項１０に記載の方法。

Images